Subclass 838	Subclass 839	Subclass 840
Imitating real life object

System for accessing digital imaging devices

6986108

Abstract

There is provided asystem and architecture for accessing and communicating with digital image devices. The system is provided in the form of software components that are platform independent for the development of software for managing or controlling digital image devices. The software components are easily integrated with existing development tools, have native functionality, and can be implemented independently of Common Information Model or Simple Network Management Protocol architectures.

Claims

What is claimed is:

1. A common object model based interface for digital imaging devices comprising:

a plurality of common object sets, each object set including a plurality of common objects, each common object in a given set being adapted to associate a uniform function in a unique, corresponding software development environment of a plurality thereof, thereby associating a uniform programming language interface for each object function in each software development environment; wherein

each common object includes a corresponding programming language object adapted for its corresponding software development environment, which adaptation includes instantiation with native terms and abstractions associated with the corresponding programming language and software development environment; and wherein

each programming language interface is adapted for data communication and behavior invocation between the corresponding software development environment and a selected, associated digital imaging device.

2. The common object model based interface for digital imaging devices of claim 1, wherein the software development environment is a general purpose programming environment.

3. The common object model based interface for digital imaging devices of claim 2, wherein the uniform function is one of the group consisting of copying, scanning, faxing and printing.

4. The common object model based interface for digital imaging devices of claim 3, wherein the selected digital imaging device is a multifunction peripheral device.

5. A system for communicating with a digital imaging device including a common object model based interface, the system comprising:

means adapted for receiving data associated with a first software development environment;

means adapted for associating at least one common object associated with the data from the first software development environment with a uniform function in the first software development environment;

means adapted for associating an uniform programming interface for the at least one object in the first software development environment, wherein the uniform function is associated with the uniform programming interface;

programming language object means adapted for instantiating the at least one object in the first software development environment with native data representative of a second development environment, wherein the second development environment is unique from the first development environment, and wherein the uniform function of the first software development environment is instantiated into a uniform function of the second software development environment; and

data communications means adapted for communicating behavior invocation between the first software development environment and the second development environment, wherein the second development environment corresponds to an operating language of a selected digital imaging device.

6. The system of claim 5, wherein the selected digital imaging device is communicatively coupled to a network.

7. The system of claim 5, wherein the first software development environment is a general purpose programming environment and the second software development environment is a device-specific programming environment.

8. The system of claim 7, wherein the uniform function is one of the group consisting of copying, scanning, faxing and printing.

9. The system of claim 8, wherein the selected digital imaging device is a multifunction peripheral device.

Description

BACKGROUND OF THE INVENTION

This invention pertains generally to digital imaging devices and the communication therewith, and more particularly to devices and architecture for customizing and interfacing with digital imaging devices.

Digital imaging devices ("DID") are complex machines that require network administration attention. Such devices include simple printers and fax machines as well as multi-functional peripherals ("MFP"). In order to manage most DIDs on a network, administrators make use of either a Common Information Model ("CIM") or a Simple Networking Management Protocol ("SNMP"). Both architectures provide an almost universal and platform independent mechanism to access and interface with digital imaging devices. For each DID, the Original Equipment Manufacturer ("OEM") creates a description of device management information relating to CIM and SNMP networks. Such management information generally includes textual binary descriptors that describe the nature of the device, the management capabilities of the device, the names of the objects native to the device, the types of actions the device can perform, etc. Value-added resellers ("VAR"), OEMs, or vendors then utilize the device management information to access and control the DIDs and to create software for managing the DIDs.

Due to the nature of the essentially universal solutions provided by the use of CIM and SNMP, both CIM and SNMP are extraordinarily complex. Consequently, there are only a handful of software applications that support these standards, which although popular, are insufficient to address the needs of OEMs and VARs. Additionally, the costs associated with developing the necessary descriptors, testing, and integrating DIDs with device management software are significant. Furthermore, most software applications that work with CIM or SNMP to manage DIDs contain Graphical User Interfaces ("GUI") created by a VARs, OEMs, or vendors. The DID management GUIs are often not easily modifiable, and generally incorporate the software creator's corporate identification and style preferences.

In any given network, there are a number of DIDs. The DIDs may all be of the same brand or be from the same vendor, or they may represent a variety of different vendors, all of

In any given network, there are a number of DIDs. The DIDs may all be of the same brand or be from the same vendor, or they may represent a variety of different vendors, all of which utilize different management software and different GUIs. Even multiple devices from the same vendor may utilize different management software. Therefore, in order for network administrators to control the DIDs throughout a network, they must either use a number of different software packages or create their own software package. Using multiple packages presents a number of obvious problems such as inefficiency and an inconsistent look and feel of the software throughout the network. Creating new software packages for controlling DIDs is problematic because of the complexity of the CIM and SNMP models. It would therefore be preferable if VARs, network administrators, and even end users were able to create their own DID management programs or integrate DID management capabilities into their existing programs and network management tools.

SUMMARY OF THE INVENTION

It is therefore an object of the present invention to provide an improved method of communicating with digital imaging devices. According to the present invention, there is provided asystem for communicating with digital image devices comprising a language binding software component for receiving information from a software application and a plurality of digital image device software components comprising a plurality of packages and classes for receiving information from the language binding software component and selectively communicating with a digital imaging device in response to the information received from the language binding software component.

Also according to the present invention, there is provided an object model for a component based system for communicating with digital image devices, the object model comprising a first level primary package having a plurality of subpackages, each subpackage having a plurality of classes configured for specific communication with a digital imaging device. The primary package suitably comprises a subpackage having classes configured for communication relative to digital imaging device settings, a subpackage having classes configured for communication relative to the types of jobs the digital imaging device is to perform, a subpackage having classes configured for communication relative to the handling of images, and a subpackage having classes configured for communication relative to network information, protocols and settings.

DESCRIPTION OF THE FIGURES

FIG. 1 is a representation of the present invention within a network system;

FIG. 2 is a diagram generally representing a primary component package of one embodiment of the present invention and its relation to various first level packages;

FIG. 3 is a diagram showing the details of one embodiment of an address book component package and its relation to the primary component package;

FIG. 4 is a diagram showing the details of one embodiment of a device handling component package and its relation to the primary component package;

FIG. 5 is a diagram showing the details of one embodiment of an image handling component package and its relation to the primary component package;

FIG. 6 is a diagram showing the details of one embodiment of a job handling component package and its relation to the primary component package;

FIG. 7 is a diagram showing the details of one embodiment of a log entry component package and its relation to the primary component package;

FIG. 8 is a diagram showing the details of one embodiment of a maintenance handling component package and its relation to the primary component package;

FIG. 9 is a diagram showing the details of one embodiment of a networking component package and its relation to the primary component package;

FIG. 10 is a diagram showing the details of one embodiment of a security component package and its relation to the primary component package;

FIG. 11 is a class diagram representing a primary package in a presently preferred embodiment of the invention;

FIG. 12 is a class diagram representing an address book package in a presently preferred embodiment of the invention;

FIG. 13 is a class diagram representing a devices package in a presently preferred embodiment of the invention;

FIG. 14 is a class diagram representing a logical devices package in a presently preferred embodiment of the invention;

FIG. 15 is a class diagram representing a physical devices package in a presently preferred embodiment of the invention;

FIG. 16 is a class diagram representing a filters package in a presently preferred embodiment of the invention;

FIG. 17 is a class diagram representing an address book filters package in a presently preferred embodiment of the invention;

FIG. 18 is a class diagram representing an image handlers filters package in a presently preferred embodiment of the invention;

FIG. 19 is a class diagram representing a job log filters package in a presently preferred embodiment of the invention;

FIG. 20 is a class diagram representing an image handlers package in a presently preferred embodiment of the invention;

FIG. 21 is a class diagram representing a jobs package in a presently preferred embodiment of the invention;

FIG. 22 is a class diagram representing a logs package in a presently preferred embodiment of the invention;

FIG. 23 is a class diagram representing a message logs package in a presently preferred embodiment of the invention;

FIG. 24 is a class diagram representing a maintenance package in a presently preferred embodiment of the invention; and

FIG. 25 is a class diagram representing a network package in a presently preferred embodiment of the invention.

FIG. 26 is a class diagram representing a security package in a presently preferred embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention provides a solution for software developers desiring to create new DID management software or integrate DID management capability into existing software programs. The invention described herein presents a solution that has all the benefits of Object-Oriented ("OO") data representation, scalability and implementation-independence of CIM and SNMP while providing a simple organizational structure and familiar development environment. The invention provides, as part of one embodiment, a component-based development environment wherein Software Components ("SC") are utilized to manage DIDs.

A Software Component is any piece of pre-written code that defines interfaces that can be called to provide the functionality that the component encapsulates. SCs are typically packaged in "industry standard" ways so that they are callable from multiple languages, or from multiple environments. SCs are units of independent deployment that have no persistent state. As such, SCs provide seamless integration with existing development tools, such Forte for Java or Microsoft Visual Studio. The SCs are suitably used out-of-the-box, or extended and specialized by developers as desired. This simplicity and flexibility allows a developer to focus on the business logic of an application, rather than focusing on methods for communicating and managing DID objects. It should be noted that the SCs of the present invention are suitably designed for any language binding, such as Common Object Request Broker Architecture ("CORBA"), .NET, COM, DCOM, C++, ActiveX, etc.

In a presently preferred embodiment, invention utilizes the Java 2 platform, which is a freely distributed software development and runtime platform manufactured by Sun Microsystems, available for virtually any commercial Operating Systems ("OS"). This platform guarantees "write once, run anywhere" functionality, which detaches the implementation from the underlying OS environment. The invention employs Programming Language Bindings ("PLB"), which greatly contribute to seamless integration with a native Software Development Environment ("SDE"). Because of the PLB of the present invention, software developers are able to use Data Objects ("DO") directly within the developer's SDE while using a language of the developer's choice, as opposed to learning how to interact with yet another object management system and interface.

The present invention utilizes Java Beans ("JB"), which represent classes, properties, methods and events. It should be noted that while JB are a particular type of software component, any type of component is suitably used. The description of the Object Model ("OM") as described herein is specific to a JB implementation; however, the OM itself, classes, packages and their relationships are suitably implemented through any language bindings. Therefore, any changes to the OM necessitated due to changing language bindings are within the scope of the present invention. The following description provides details about package contents and class containment in Unified Modeling Language ("UML") notation.

Turning now to FIG. 1, a diagram depicting an embodiment of the present invention as it relates to a network system is provided. The gray components represent components of the present invention. According to FIG. 1, a network system 100 comprising server(s) and client(s) is shown. The network 100 is illustrative of a LAN or WAN environment in which the devices connected to the network 100 are in communication with or communicatively coupled to one another. The network itself is suitably comprised of physical and transport layers such as illustrated by a myriad of conventional data transport mechanisms such Ethernet, Token-Ring™, 802.11(b), or other wire-based or wireless data communication mechanisms as will be apparent to one of ordinary skill in the art.

The network suitably comprises at least one server, a representative one of which is illustrated by Server 118. The Server 118 suitably comprises a server side logic component 120, a script engine component 122 and a language binding component 124. The Server 118 is suitably any Server for accommodating selective query support, selective data access, data archiving, and like as will be appreciated to one of ordinary skill in the art. One or more Clients, such as representative Thin Clients 102 and 104, are in data communication with the Server 118. Thus, a data path between one or more Servers, such as that illustrated by Server 118, is in shared data communication with one or more Clients, such as Thin Clients 102 and 104. Thin Clients 102 and 104 are suitably simple client programs or hardware devices that rely on a server for the majority of their functionality.

Thin Clients 102 and 104 suitably communicate with Server 118 through a Client/Server Protocol. When the Server 118 is a web server, the communication protocol is suitably Hypertext Transfer Protocol ("HTTP"). The Thin Clients 102 and 104 and Server 118 are suitably on opposite sides of an Internet/Intranet Boundary 132. In addition, the Server 118 and Internet/Intranet Boundary 132 are suitably on opposite sides of a Controller Boundary 134. As such, the Server components suitably exist on a Controller. Thin Clients 102 and 104 also suitably communicate with Business Objects components 114, which are suitably located on the opposite side of the Internet/Intranet Boundary 132 and on the same side of a Controller Boundary 134 as Thin Clients 102 and 104. The Business Object components 114 then suitably communicate across a Controller Boundary 134 with a CORBA Interface Definition Language ("IDL") Binding component 126. The Language Binding component 124 then suitably communicates with a Software Developer Kit ("SDK") Application Programming Interface ("API") 128.

The Server 118 preferably comprises a Server Side Logic component 120, a Script Engine component 122, and a Language Binding component 124. The Server Side Logic component 120 suitably communicates with the Script Engine component 122 and with the Language Binding component 124. The Script Engine component suitably communicates with the Language Binding component 124. The Language Binding component 124 suitably communicates with a SDK API 128.

A Thick Client 106 suitably resides on the same side of the Internet/Intranet Boundary 132 as do the Thin Clients 102 and 104 and suitably communicates with an Interface Bridge component 112 also residing on the same side of the Internet/Intranet Boundary 132. The Thick Client 106 suitably employs a specific Object Model ("OM"), such as DCOM. The Interface Bridge 112 then accepts the DCOM information from the Thick Client 106 and communicates with a CORBA IDL Binding component 126 across both an Internet/Intranet Boundary 132 and a Controller Boundary 134.

Business Application components 108 also suitably reside on the same side of the Internet/Intranet Boundary 132 as do the Thin Clients 102 and 104 and suitably communicates in one instance directly with a CORBA IDL Binding component 126 across both an Internet/Intranet Boundary 132 and a Controller Boundary 134. In another instance, the Business Application components 108 suitably communicates with a Local Language Binding component 110 without crossing the Internet/Intranet Boundary 132. The Local Language Binding component 110 then communicates with a CORBA IDL Binding component 126 across both an Internet/Intranet Boundary 132 and a Controller Boundary 134.

Controller Application components also suitably communicate with a SDK API 128 directly and with CORBA IDL Binding component 126. The CORBA IDL Binding component 126 then communicates with the SDK API 128. The SDK API 128 then communicates with Device Components 130.

The OM structure of the present invention is represented as a set of SCs, otherwise referenced herein as JBs, distributed across a set of packages and classes. Within a main package are subpackages and classes. A package is suitably defined as a named general-purpose mechanism for organizing model elements, including, for instance, classes, use cases, diagrams, and/or other packages, into groups. A package is purely conceptual: it does not exist at run time. A class is suitably defined as a named description of a set of objects that share the same attributes, operations, relationships, and semantics. These objects suitably represent either real-world things or conceptual things.

Turning now to FIG. 2, the general tree structure of the OM 200, including packages and classes is shown. The OM 200 of the present invention comprises Primary package 300 that comprises a number of packages. The AddressBook package 400 is suitably related to Primary package 300 through the Primary-AddressBook Relationship 210. The Devices package 500 is suitably related to Primary package 300 through the Primary-Devices Relationship 220. The Logs package 1000 is suitably related to Primary package 300 through the Primary-Logs Relationship 230. The Maintenance package 1200 is suitably related to Primary package 300 through the Primary-Maintenance Relationship 240. The Jobs package 900 is suitably related to Primary package 300 through the Primary-Jobs Relationship 250. The Network package 1300 is suitably related to Primary package 300 through the Primary-Network Relationship 260. The ImageHandlers package 800 is suitably related to Primary package 300 through the Primary-ImageHandlers Relationship 270 and the Security package 1400 is suitably related to Primary package 300 through the Primary-Security Relationship 280. The Primary package 300 suitably comprises the related packages. A list of the elements of Primary package 300 is shown in Table 1.

TABLE 1

Structure of Primary Package

	Element	Type

	Base	Class
	MaintainableComponent	Class
	PrimaryException	Class
	AddressBook	Package
	ImageHandlers	Package
	Logs	Package
	Network	Package
	Devices	Package
	Jobs	Package
	Maintenance	Package
	Security	Package

Turning now to FIG. 3, a diagram is provided showing the classes of Primary package 300 and AddressBook package 400. Primary package 300 comprises three classes: Base 302, MaintainableComponent 304, and PrimaryException 306. The Base class 302 is the base class for all SCs used in the packages subordinate to Primary package 300. Base class 302 is suitably a specialization of java.lang.Object and implements java.io.Serializable. The functionality of Base class 302 is detailed in Table 2.

TABLE 2

Base Class Functions and Descriptions

Function	Description

public Base getRootObject( )	Retrieves the root object, that is,
	the object that contains all other objects
	within its life scope.
	Generally, this is a subclass
	of LogicalDevice

The MaintainableComponent class 304 is an abstraction for a component that is suitably maintained by the user. It is suitably a specialization of Base class 302. The functionality of the MaintainableComponent class 304 is detailed in Table 3.

TABLE 3

MaintainableComponent Class Functions and Descriptions

Function	Description

public void Backup(String	Backs up this component given a target
toURL)	URL. Existing files on the target URL
	will be replaced
	Throws: PrimaryException
	Parameter doc:
	Incremental - TRUE to perform
	incremental operation
	fromURL - URL to restore from
public String getCategory( )
public String
getDescription( )
public String getFiles( )
public Locale getLocale( )
public String getName( )
public int getSize( )
public String getVersion( )
public void Restore(String	Restore component from a URL
fromURL, boolean	Parameter doc:
incremental)	Incremental - TRUE to perform
	incremental operation
	fromURL - URL to restore from

The PrimaryException class 306 is the base class for all exceptions. It is suitably a specialization of java.lang.Exception. The functionality of PrimaryException class 306 is detailed in Table 4.

TABLE 4

PrimaryException Class Functions

	Function

	public int get ErrorCode( )
	public String getErrorDesc( )

Turning now to FIG. 3, a diagram is provided showing the classes of Primary package 300 and structure of the AddressBook package 400. The AddressBook package 400 is related to Primary package 300 through the Primary-AddressBook Relationship 210. The AddressBook package 400 comprises a number of classes. Its structure is detailed in Table 5.

TABLE 5

Structure of AddressBook Package

	Element	Type

	ABEntry	Class
	ABGroup	Class
	AddressBook	Class
	DirectoryService	Class
	EntryQuery	Class
	GroupQuery	Class
	LDAPService	Class
	Query	Class

The ABEntry class 402 suitably represents a single entry in an Address Book. It is suitably a specialization of Base class 302. The functionality of the ABEntry 402 class is detailed in Table 6.

TABLE 6

ABEntry Class Functions and Descriptions

Function	Description

public void	Add this entry to the address book
AddToAddressBook(ABGroup	possibly belonging to a group.
group)
public String getEmail( )
public String getFirst( )
public String getLast( )

The ABGroup 404 class suitably represents an Address Book group. It is suitably a specialization of Base class 302. The functionality of the ABGroup 404 class is detailed in Table 7.

TABLE 7

ABGroup Class Functions

	Function

	public String getComment( )
	public ABEntry getEntries( )
	public String getName( )
	public ABGroup getSubGroups( )

The AddressBook class 406 suitably represents an address book, which is suitably a collection of entries, groups and directory services. The AddressBook class 406 is suitably a specialization of Base class 302. The functionality of the AddressBook class 406 is detailed in Table 8.

TABLE 8

AddressBook Class Functions and Descriptions

Function	Description

public EntryQuery	Query entries using specified directory service
CreateEntryQuery(DirectoryService service,	based on partial first, last and email.
String last, String first, String email)	Parameter doc:
	first - partial first name
	last - partial last name
	email - partial email address
public GroupQuery	Create query for groups using specified directory
CreateGroupQuery(DirectoryService service,	service and partial group name.
String grpName)	Parameter doc:
	service - directory service to use; NULL to
	search address book itself
	grpName - partial group name
public MaintainableComponent getData( )
public DirectoryService getDirServices( )
public ABGroup getPrimaryGroup( )
public MaintainableComponent getSettings( )
public void setData(MaintainableComponent
data)
public void
setSettings(MaintainableComponent settings)

The DirectoryService class 408 is suitably an abstract representation of a name lookup service or directory service. It is suitably a specialization of Base class 302. The functionality of the DirectoryService class 408 is detailed in Table 9.

TABLE 9

DirectoryService Class Functions

	Function

	public String getName( )

The EntryQuery class 410 is suitably a representation of a query for address book entries. It is suitably a specialization of Query class 416. The functionality of the EntryQuery class 410 is detailed in Table 10.

TABLE 10

EntryQuery Class Functions and Descriptions

Function	Description

public ABEntry GetNextPage( )	Retrieve the next page of entries.
	Throws: PrimaryException

The GroupQuery 412 class is suitably a representation of a query for address book groups. It is suitably a specialization of Query class 416. The functionality of the GroupQuery class 412 is detailed in Table 11.

TABLE 11

GroupQuery Class Functions and Descriptions

Function	Description

public ABGroup GetNextPage( )	Retrieve the next page of groups.
	Throws: PrimaryException

The LDAPService class 414 is suitably a specialization of DirectoryService class 408 for the LDAP protocol. The functionality of the LDAPService class 414 is detailed in Table 12.

TABLE 12

LDAPService Class Functions

	Function

	public String getLDAPserver( )
	public int getMaxPageEntries( )
	public int getMaxReturnedEntries( )
	public String getPassword( )
	public int getPortNo( )
	public String getSearchBase( )
	public int getSearchTimeout( )
	public String getUser( )
	public boolean isSecure( )

The Query class 416 is suitably a representation of a query for address book groups or individual entries. It is suitably a specialization of Base class 302. The functionality of the Query class is detailed in Table 13.

TABLE 13

Query Class Functions and Descriptions

Function	Description

public void Close( )	Close query.
	Throws: PrimaryException
public int getPageCount( )
public int getRecCount( )
public void Open( )	Open or execute query.
	Throws: PrimaryException
public void setPageCount(int pageCount)
public void setRecCount(int recCount)

Turning now to FIG. 4, a diagram is provided showing the classes of Primary package 300 and structure of the Devices package 500. The Devices package 500 is related to Primary package 300 through the Primary-Devices Relationship 220. The Devices package 500 comprises a number of classes and subpackages. Its structure is detailed in Table 14.

TABLE 14

Structure of Devices Package

	Element	Type

	Counter	Class
	Department	Class
	DeviceStateChangedListener	Class
	Logical	Package
	Physical	Package

The Counter class 502 is suitably a representation of a single job and page counter. It is suitably a specialization of Base class 302. The functionality of the Counter class 502 is detailed in Table 15.

TABLE 15

Counter Class Functions and Descriptions

Function	Description

public int getJobs( )
public String getLastResetTime( )
public int getPages( )
public void Reset( )	Resets the counts kept in that object.
	For example, if filtering by Depart-
	ment is active, the filtering operation
	will apply only to that department.
	Throws: PrimaryException

The Department class 504 is suitably a representation of a department. It is an abstraction used to account for resource usage. Each department is suitably assigned a unique identification. In corporate environments, departments often correspond to business subdivisions. The Department class 504 is suitably a specialization of Base class 302. Its functionality is detailed in Table 16.

TABLE 16

Department Class Functions

	Function

	public int getDeptCode( )
	public String getDeptName( )
	public Counter getTotal( )
	public boolean isMaster( )
	public void setDeptCode(int deptCode)
	public void setDeptName(String deptName)

The DeviceStateChangedListener class 506 is suitably the base class for "device changed state" events. It is suitably a specialization of Base class 302 and suitably implements java.util.EventListener. The functionality of the DeviceStateChangedListener class 506 is detailed in Table 17.

TABLE 17

DeviceStateChangedListener

Class Functions and Descriptions

Function	Description

public void	Called when
LogicalDeviceStateChanged(LogicalDevice device)	logical device
	changed state.
public void
PhysicalDeviceStateChanged(PhysicalDevice device)

The Logical subpackage 600 is related to Devices package 500 through the Devices-Logical Relationship 510. The Logical subpackage 600 comprises a number of classes. Its structure is detailed in Table 18.

TABLE 18

Structure of Logical Subpackage

	Element	Type

	Alert	Class
	Cassette	Class
	EventRecipient	Class
	JobChangedListener	Class
	JobFilterSettings	Class
	JobListChangedListener	Class
	LogicalController	Class
	LogicalControllerSettings	Class
	LogicalDevice	Class
	LogicalDeviceMaintainer	Class
	LogicalFax	Class
	LogicalPrinter	Class
	LogicalScanner	Class
	RawJobSettings	Class
	RemoteLogicalController	Class

The Alert class 602 is suitably a generic device alert. Alerts suitably originate from logical devices and Alert objects are preferably read-only. The Alert class 602 is suitably a specialization of Base class 302. Its functionality is detailed in Table 19.

TABLE 19

Alert Class Functions and Descriptions

Function	Description

public String getDescription( )	Retrieves the description of the alert

The Cassette class 604 suitably represents a single paper cassette of a DID. The Cassette class 604 is suitably a specialization of Base class 302. Its functionality is detailed in Table 20.

TABLE 20

Cassette Class Functions and Descriptions

Function	Description

public int getCapacity( )	Retrieves capacity of
	the cassette.
public String getName( )	Retrieves the unique
	name of the cassette.
public String getPaperSize( )	Retrieves paper size
	currently loaded in the
	cassette.
public String getPaperType( )	Retrieves the paper type
	(logo, hole-punched, etc.)
	of the casette
public String getStatus( )	Retrieves the status of the
	cassette.
public void setPaperType(String paperType)

The EventRecipient class 606 suitably represents a single event recipient. The EventRecipient class 606 is suitably a specialization of Base class 302. Its functionality is detailed in Table 21.

TABLE 21

EventRecipient Class Functions and Descriptions

Function	Description

public String getEmail( )	Retrieve the email
	address of the recipient.
public String getEventNames( )
public void setEmail(String email)
public void setEventNames(String eventNames)

The JobChangedListener class 608 is suitably an abstract base class for job change events listeners. The JobChangedListener class 608 is suitably a specialization of Base class 302 and suitably implements java.util.EventsListener. Its functionality is detailed in Table 22.

TABLE 22

JobChangedListener Class Functions and Descriptions

Function	Description

public void JobChanged(Job job)	Called when a job has changed.
	The argument identifies the particular
	job that has changed.

The JobFilterSettings class 610 is suitably a representation of settings for a job or a log filter. The JobFilterSettings class 610 is suitably a specialization of Base class 302. Objects of this class are suitably used to specify how jobs and logs are filtered and sorted prior to their retrieval. Preferably, the JobFilterSettings class 610 comprises a JobFilterValues innerclass 650 for representing objects that contain filter values for fields in a job or job log.

The JobFilterValues innerclass 650 is related to Devices package 500 through the JobFilterSettings-JobFilterValues Relationship 660. Sort numbers and order numbers are suitably represented by the JobFilterValues innerclass 650. Sort numbers are preferably assigned as positive integers when indicating ascending and negative integers when indicating descending sorts. The absolute values of the sort numbers represent the relative sort order of different fields. Order numbers are also suitably assigned so that a determination can be made whether a particular field value should be retrieved and, if the order is important, the order in which the fields will be returned. The functionality of the JobFilterSettings class 610 and the JobFilterValues innerclass 650 are detailed in Table 23 and Table 24, respectively.

TABLE 23

JobFilterSettings Class Functions

	Function

	public int getProperty( )
	public String getTypes( )
	public boolean isIncludeInvalid( )
	public boolean isInvalidOnly( )
	public String getTypes( )
	public boolean isIncludeInvalid( )
	public boolean isInvalidOnly( )
	public int getDocument( )
	public int getId( )
	public int getOwner( )
	public int getPages( )
	public int getSize( )
	public int getStatus( )
	public int getTime( )
	public int getType( )
	public void setDocument(int document)
	public void setId(int id)
	public void setOwner(int owner)
	public void setPages(int pages)
	public void setSize(int size)
	public void setStatus(int status)
	public void setTime(int time)
	public void setType(int type)
	public void setIncludeInvalid(boolean includeInvalid)
	public void setInvalidOnly(boolean invalidOnly)
	public void setProperty(int property)
	public void setTypes(String types)

TABLE 24

JobFilterValues Class Functions

	Function

	public JobFilterSettings.JobFilterValues getOrder( )
	public JobFilterSettings.JobFilterValues getSort( )

The JobListChangedListener class 612 is suitably a base class for job list change events. The JobListChangedListener class 612 is suitably a specialization of Base class 302 and suitably implements java.util.EventsListener. Its functionality is detailed in Table 25.

TABLE 25

JobListChangedListener Class Functions and Descriptions

Function	Description

public void JobListChanged(String	Called when the job list has changed.
jobType)	The argument contains the type
	of job list that has changed.

The LogicalController class 614 is suitably a representation of a logical device controller, preferably a logical device that controls other logical devices, such as a logical printer or logical scanner. The LogicalController class 614 is suitably a specialization of LogicalDevice class 618. Its functionality is detailed in Table 26.

TABLE 26

LogicalController Class Functions and Descriptions

Function	Description

public synchronized void
addJobChangedListener(JobChanged
Listener listener)
public synchronized void
addJobListChangedListener(JobListChangedListener
listener)
public static LogicalController	Binds to the LogicalController object to which the
BindToThisController( )	server is associated.
	Return doc: The logical controller
public AddressBook
getAddressBook( )
public Agent getAgents( )
public Alert getAlerts( )
public LogicalFax getFax( )
public Job getJobs( )
public HouseKeeper getKeeper( )
public LogEntry getLogs( )
public LogicalDeviceMaintainer
getMaintainer( )
public MessageEntry getMessages( )
public NetworkConfiguration
getNetConfig( )
public LogicalPrinter getPrinter( )
public LogicalScanner getScanner( )
public SecurityManager
getSecurityManager( )
public LogicalControllerSettings
getSettings( )
public boolean IsOnline( )	Returns the "online" state of the controller.
	Return doc:
	Current state of the controller.
public RemoteLogicalController	Locate devices from a range of IP addresses, controller
LocateDevices(int[] IPfrom, int[]	and network protocol types.
IPto, String controllerTypes, String	Parameter doc:
protocols)	IPfrom - the beginning IP address
	IPto - the ending IP address controller
	Types - type names for the controllers to be located
	protocols - network protocol names to be used for
	location
	Return doc:
	Array of RemoteLogicalController objects -- one for
	each distinct device found
public RemoteLogicalController	Locates devices on a particular subnet by specifying
LocateDevices(String	controller and network protocol types.
controllerTypes, String protocols,	Return doc:
int[] subnet)	Array of RemoteLogicalController objects -- one for
	each distinct device found.
	Parameter doc:
	controllerTypes - array of strings containing the type
	names of the controllers to be located.
	protocols - array of network protocol names to be used
	for location
	subnet - array of integers indicating the subnet to be
	used for location; if null controller's subnet is used
public synchronized void
removeJobChangedListener(JobChangedListener
listener)
public synchronized void
removeJobListChangedListener(JobListChangedListener
listener)
public void Restart(boolean bSoft)	Restarts the controller.
	Parameter doc:
	bSoft - TRUE to perform software restart; FALSE to
	reboot completely.
public void
setNetConfig(NetworkConfiguration
netConfig)
public boolean SetOnline(boolean	Sets the controller's online state.
newState)	Return doc:
	The previous "online" state.
public void ShutDown( )	Shuts down the controller.

The LogicalControllerSettings class 616 is suitably a representation of the settings of a logical controller. Preferably, the controller has a set of constants that change only when the controller software is upgraded. The LogicalControllerSettings class 616 is suitably a specialization of Base class 302. Its functionality is detailed in Table 27.

TABLE 27

LogicalControllerSettings Class Functions and Descriptions

Function	Description

public String getBIOSdate( )
public String getBIOSid( )
public String getContactName( )
public String getContactPhone( )
public String getControllerType( )
public String getCPUType( )
public String getDriverVersion( )
public Date getJavaDate( )
public Locale getLocale( )
public String getMessage( )
public String getName( )
public String getOSVersion( )
public String getSoftwareVersion( )
public String getStatus( )
public String GetTaggedValue(String	Retrieves a tagged value by name.
name)	Throws:
	PrimaryException
	Return doc:
	tagged value
	Parameter doc:
	name -- name of the value to get
public String getTime( )
public int getUTCOffset( )
public boolean isDeptCodeEnabled( )
public boolean
isDeptCodeEnforcement( )
public void setContactName(String
contactName)
public void setContactPhone(String
contactPhone)
public void
setDeptCodeEnforcement(boolean
deptCodeEnforcement)
public void setJavaDate(Date
javaDate)
public void setLocale(Locale locale)
public void setMessage(String
message)
public void SetTaggedValue(String	Sets the tagged value.
name, String val)
	Throws:
	PrimaryException
	Parameter doc:
	name -- name of the value to set
	val -- value to set
public void setTime(String time)
public void setUTCOffset(int
UTCOffset)

The LogicalDevice 618 class is suitably an abstract class representation a logical device. Logical devices are components of physical devices, which are actual devices that have physical form, i.e. those devices which one can walk up to and use. Each physical device preferably contains at least one logical device, while MFPs contain more than one logical device. The LogicalDevice class 618 is suitably a specialization of Base class 302. Its functionality is detailed in Table 28.

TABLE 28

LogicalDevice Class Functions and Descriptions

Function	Description

public void AddDepartment(int	Adds a new department to the list.
deptCode, String deptName)	Parameter doc:
	deptCode - the new department's code
	deptName - new department's name
public synchronized void
addDeviceStateChangedListener(DeviceStateChangedListener
listener)
public void	Adds an event recipient to the current list of recipients.
AddEventRecipient(EventRecipient	Parameter doc:
newRecipient)	newRecipient - the new event recipient.
public void DeleteDepartment(int	Deletes existing department from the list.
deptCode)	Throws: PrimaryException
	Parameter doc:
	deptCode - the new department's code
public static String	Static method to retrieve all the possible event names.
getAllEventNames( )	Return doc:
	Event names list (localized)
public Department getCountFilter( )
public Department getDepartments( )
public PhysicalDevice getDevice( )
public EventRecipient
getEventRecipients( )
public String getFirmwareVersion( )
public JobFilterSettings getJobFilter( )
public JobFilterSettings
getLogFilter( )
public Counter getTotal( )
public synchronized void
removeDeviceStateChangedListener(DeviceStateChangedListener
listener)
public void	Removes an event recipient from the current list of
RemoveEventRecipient(EventRecipient	recipients.
recipient)	Parameter doc:
	recipient - the existing event recipient.
public void
setCountFilter(Department countFilter)
public void
setjobFilter(JobFilterSettings jobFilter)
public void
setLogFilter(JobFilterSettings logFilter)

The LogicalDeviceMaintainer class 620 is closely related to LogicalController class 614. It suitably encapsulates the behavior and semantics associated with the maintenance of the LogicalController class 614. The LogicalDeviceMaintainer class 620 is suitably a specialization of Base class 302. Its functionality is detailed in Table 29.

TABLE 29

LogicalDeviceMaintainer Class Functions and Descriptions

Function	Description

public void ClearJobLog(String	Clears job log.
timeEarliest)	Parameter doc:
	timeEarliest - earliest time to be left any entries earlier
	than that time will be cleared
	NULL - all
public void ClearMessageLog(String	Clears message log.
timeEarliest)	Parameter doc:
	timeEarliest - earliest time to be left in; any entries
	earlier than that time will be cleared
	NULL - all
public void ExportCounters(String	Export the counter information. If filtering Department
format, String exportURL)	is active, that will export information only for that
	department.
	Parameter doc:
	format - format name: "CSV" or "TSV"
	exportURL - URL to store the exported file
public void ExportJobLog(String	Export job log into a specific format file on the network.
jobTypes, String jobStatuses, String	Throws: PrimaryException
timeFrom, String timeTo, String	Parameter doc:
format, String exportURL)	jobTypes - names of thejob types to export; NULL - all
	jobStatuses - job statuses for log entries to be exported;
	NULL - all
	timeTo - end time for job log entries
	timeFrom - start time for job log entries
	format - format name: "CSV" or "TSV"
	exportURL - URL to store the export file
public void	Exports message log into a particular format network
ExportMessageLog(String jobTypes,	file.
String timeFrom, String timeTo,	Throws: PrimaryException
String format, String exportURL)	Parameter doc:
	jobTypes - names of thejob types to export; NULL - all
	timeFrom - start time for job log entries
	timeTo - end time for job log entries
	format - format name: "CSV" or "TSV"
	exportURL - network path to store the export file

The LogicalFax class 622 is designed to represent a fax machine device. The LogicalFax class 622 is suitably a specialization of LogicalDevice class 618. Its functionality is detailed in Table 30.

TABLE 30

LogicalFax Class Functions

	Function

	public String getCSID( )
	public Counter getInCounter( )
	public RoutedFaxJob[] getInJobs( )
	public RoutedFaxLogEntry getInLogs( )
	public LogicalDeviceMaintainer getInMaintainer( )
	public RoutedFaxMessageEntry getInMessages( )
	public MailBox getMailboxes( )
	public int getNumRetries( )
	public Counter getOutCounter( )
	public OutboundFaxJob getOutJobs( )
	public OutboundFaxLogEntry getOutLogs( )
	public LogicalDeviceMaintainer getOutMaintainer( )
	public FaxMessageEntry getOutMessages( )
	public int getRetryTimeOut( )
	public String getTSID( )

The LogicalPrinter class 624 is designed to represent a printer or printing device. The LogicalPrinter class 624 is suitably a specialization of LogicalDevice class 618. Its functionality is detailed in Table 31.

TABLE 31

LogicalPrinter Class Functions and Descriptions

Function	Description

public int getAutoContinueTimeOut( )
public Cassette getCassettes( )
public int getDaysToKeepPrJobs( )
public String getIFaxTray( )
public PrintJob getJobs( )
public PrintLogEntry getLogs( )
public LogicalDeviceMaintainer getMaintainer( )
public PrintMessageEntry getMessages( )
public int getPCLFontNum( )
public float getPCLFontPitch( )
public int getPCLFontSize( )
public String getPunchUnitType( )
public RawJobSettings getRawJobSettings( )
public String getSorterPriority( )
public String getStaplerType( )
public String getStitchType( )
public boolean isAutoContinueOn( )
public boolean isIFaxDuplex( )
public boolean isPrintStartupPage( )
public void PrintDeviceConfig( )	Prints logical device
	configuration sheet.
public void PrintPCLFonts( )	Prints PCL fonts
	available on the
	logical device.
public void PrintPSFonts( )	Prints PostScript fonts
	available on the
	logical device.
public void setAutoContinueOn(boolean
autoContinueOn)
public void setAutoContinueTimeOut(int
autoContinueTimeOut)
public void setDaysToKeepPrJobs(int
daysToKeepPrJobs)
public void setIFaxDuplex(boolean IFaxDuplex)
public void setIFaxTray(String IFaxTray)
public void setPCLFontNum(int PCLFontNum)
public void setPCLFontPitch(float PCLFontPitch)
public void setPCLFontSize(int PCLFontSize)
public void setPrintStartupPage(boolean
printStartupPage)
public void setSorterPriority(String sorterPriority)

The LogicalScanner class 626 is designed to represent a scanner. The LogicalScanner class 626 is suitably a specialization of the LogicalDevice class 618. Its functionality is detailed in Table 32.

TABLE 32

LogicalScanner Class Functions

	Function

	public ScanJob getJobs( )
	public ScanLogEntry getLogs( )
	public LogicalDeviceMaintainer getMaintainer( )
	public ScanMessageEntry getMessages( )
	public ScanTemplateGroup getScanTemplateGroups( )

The RawJobSettings class 628 is an abstraction of the configuration parameters for RAW jobs, which are PDL-based jobs with no PJL commands. The RawJobSettings class 628 is suitably a specialization of the Base class 302. Its functionality is detailed in Table 33.

TABLE 33

RawJobSettings Class Functions

	Function

	public String getRawDfltOrient( )
	public String getRawDfltPaperSize( )
	public String getRawDfltPaperType( )
	public String getRawDfltTray( )
	public boolean isRawDfltStaplingOn( )
	public boolean isRawDuplexPrint( )
	public void setRawDfltOrient(String rawDfltOrient)
	public void setRawDfltPaperSize(String rawDfltPaperSize)
	public void setRawDfltPaperType(String rawDfltPaperType)
	public void setRawDfltStaplingOn(boolean rawDfltStaplingOn)
	public void setRawDfltTray(String rawDfltTray)
	public void setRawDuplexPrint(boolean rawDuplexPrint)

The RemoteLogicalController class 630 is an abstraction of a remote logical controller. This class is useful when locating controllers other than the controller currently being utilized. The RemoteLogicalController class 630 is suitably a specialization of the Base class 302. Its functionality is detailed in Table 34.

TABLE 34

RemoteLogicalController Class Functions

	Function

	public int[] getIP( )
	public int[] getIPX( )
	public String getNSname( )
	public String getType( )

The Physical subpackage 700 is related to Devices package 500 through the Devices-Physical Relationship 520. The Physical subpackage 700 comprises a number of classes. Its structure is detailed in Table 35.

TABLE 35

Structure of Physical Subpackage

	Element	Type

	Copier	Class
	GLSeries	Class
	PhysicalDevice	Class
	SCSeries	Class

The Copier class 702 is an abstraction designed to represent a copier machine. The Copier class 702 is suitably a specialization of PhysicalDevice class 706. Its functionality is detailed in Table 36.

TABLE 36

Copier Class Functions

	Function

	public int getAutoClearTimeOut( )
	public String getAutoDuplex( )
	public int getAutoPowerOff( )
	public int getAutoPowerSave( )
	public String getDateFormat( )
	public int getMaxCopies( )
	public LogicalPrinter getPrinter( )
	public String getPrinterDSIVersion( )
	public String getRomVersion( )
	public LogicalScanner getScanner( )
	public String getScannerROMVersion( )
	public void setAutoClearTimeOut(int autoClearTimeOut)
	public void setAutoDuplex(String autoDuplex)
	public void setAutoPowerOff(int autoPowerOff)
	public void setAutoPowerSave(int autoPowerSave)
	public void setDateFormat(String dateFormat)
	public void setMaxCopies(int maxCopies)
	public void setPrinterDSIVersion(String printerDSIVersion)

It should be noted that an abstraction designed to represent any specific device is suitably added to the Physical subpackage 700. As such, the Physical subpackage is suitably expandable to include classes for any DID device in the world. One such specific device series is the GLSeries device. The GLSeries class 704 is an abstraction designed to represent a GLSeries device. The GLSeries class 704 is suitably a specialization of PhysicalDevice class 706. Its functionality is detailed in Table 37.

TABLE 37

GLSeries Class Functions

	Function

	public LogicalController getController( )

Similarly, the SCSeries class 708 is an abstraction designed to represent an SCSeries device controller. The SCSeries class 708 is suitably a specialization of PhysicalDevice class 706. Its functionality is detailed in Table 38.

TABLE 38

SCSeries Class Functions

	Function

	public LogicalController getController( )
	public Copier getCopier( )

The PhysicalDevice class 706 is an abstraction designed to represent a physical device, which is an actual device that has physical form, i.e. those devices which one can walk up to and use. The PhysicalDevice class 706 is suitably a specialization of Base class 302. Its functionality is detailed in Table 39.

TABLE 39

PhysicalDevice Class Functions

Function

public synchronized void

addDeviceStateChangedListener(DeviceStateChangedListener listener)

public Department getCountFilter( )

public LogicalDevice getDevices( )

public String getFirmwareVersion( )

public String getLocation( )

public String getManufacturer( )

public String getModel( )

public String getName( )

public Counter getTotal( )

public synchronized void

removeDeviceStateChangedListener(DeviceStateChangedListener

listener)

public void setCountFilter(Department countFilter)

public void setLocation(String location)

Turning now to FIG. 5, a diagram is provided showing the classes of Primary package 300 and structure of the ImageHandlers package 800. The ImageHandlers package 800 is related to Primary package 300 through the Primary-ImageHandlers Relationship 270. The ImageHandlers package 800 comprises a number of classes. Its structure is detailed in Table 40.

TABLE 40

Structure of ImageHandlers Package

	Element	Type

	Copier	Class
	Agent	Class
	EmailAgent	Class
	FaxEmailAgent	Class
	FileAgent	Class
	iFaxAgent	Class
	InboundEmailAgent	Class
	MailBox	Class
	OutboundEmailAgent	Class
	RasterImageHandler	Class
	ScanAgent	Class
	ScanTemplate	Class
	ScanTemplateGroup	Class
	StorageAgent	Class
	StoredFaxAgent	Class
	StoredJobAgent	Class
	StoredScanAgent	Class
	TWAINAgent	Class

The Agent class 802 is an abstraction designed to represent a generic image processing unit. The Agent class 802 is suitably a specialization of MaintainableComponent class 304. Its functionality is detailed in Table 41.

TABLE 41

Agent Class Functions

	Function

	public String getFileFormat( )
	public void setFileFormat(String fileFormat)

The EmailAgent class 804 is an abstraction designed to represent a generic email processing unit. The EmailAgent class 804 is suitably a specialization of Agent class 802. Its functionality is detailed in Table 42.

TABLE 42

EmailAgent Class Functions

	Function

	public int getMaxFragment( )
	public int getMaxSize( )
	public void setMaxFragment(int maxFragment)
	public void setMaxSize(int maxSize)

The FaxEmailAgent class 806 is designed to handle scan-to-iFax requests. The FaxEmailAgent class 806 is suitably a specialization of OutboundEmailAgent class 816.

The FileAgent class 808 designed to handle requests for storage of information into a file share sysetem. The FileAgent class 808 is suitably a specialization of StorageAgent class 826. Its functionality is detailed in Table 43.

TABLE 43

FileAgent Class Functions

	Function

	public String getUser( )
	public void setPassword(String password)
	public void setUser(String user)

The iFaxAgent class 810 designed to represent iFax-to-print Agent. The iFaxAgent class 810 is suitably a specialization of InboundEmailAgent class 812. Its functionality is detailed in Table 44.

TABLE 44

iFaxAgent Class Functions

	Function

	public String getErrorEmail( )
	public String getPrintMode( )
	public boolean isPrintError( )
	public boolean isSendEmailOnError( )
	public void setErrorEmail(String errorEmail)
	public void setPrintError(boolean printError)
	public void setPrintMode(String printMode)
	public void setSendEmailOnError(boolean sendEmailOnError)

The InboundEmailAgent class 812 is an abstraction designed to represent a generic inbound image processing email Agent. The InboundEmailAgent class 812 is suitably a specialization of EmailAgent class 804. Its functionality is detailed in Table 45.

TABLE 45

InboundEmailAgent Class Functions

	Function

	public String getMailDomain( )
	public int getPollRate( )
	public int getPOPport( )
	public String getPOPServer( )
	public int getSMTPport( )
	public String getSMTPServer( )
	public String getUser( )
	public void setMailDomain(String mailDomain)
	public void setPassword(String password)
	public void setPollRate(int pollRate)
	public void setPOPport(int POPport)
	public void setPOPServer(String POPServer)
	public void setSMTPport(int SMTPport)
	public void setSMTPServer(String SMTPServer)
	public void setUser(String user)

The MailBox class 814 is designed to store inbound receipts prior to their being handled by an agent. For example, after being received, the inbound faxes are stored in the mailbox prior to being handled by an agent. The MailBox class 814 is suitably a specialization of RasterImageHandler class 818. Its functionality is detailed in Table 46.

TABLE 46

Mailbox Class Functions

	Function

	public int getNo( )
	public void setNo(int no)
	public void setPassword(String password)

The OutboundEmailAgent class 816 is an abstraction designed to represent a generic outbound image processing email Agent. The OutboundEmailAgent class 816 is suitably a specialization of EmailAgent class 804. Its functionality is detailed in Table 47.

TABLE 47

OutboundEmailAgent Class Functions

	Function

	public String getBodyText( )
	public String getFromAddress( )
	public String getFromName( )
	public String getSubject( )
	public String getToAddress( )
	public String getToName( )
	public void setBodyText(String bodyText)
	public void setFromAddress(String fromAddress)
	public void setFromName(String fromName)
	public void setSubject(String subject)
	public void setToAddress(String toAddress)
	public void setToName(String toName)

The RasterImageHandler class 818 is an abstraction designed to represent a generic raster image processing handler. The RasterImageHandler class 818 is suitably a specialization of MaintainableComponent class 304. Its functionality is detailed in Table 48.

TABLE 48

RasterImageHandler Class Functions

	Function

	public Agent getAgent( )
	public Counter getCounter( )
	public int getDeptCode( )
	public String getDescription( )
	public String getName( )
	public String getNotificationDest( )
	public String getOwner( )
	public boolean isNotifyOnError( )
	public boolean isNotifyOnJob( )
	public void setAgent(Agent agent)
	public void setDeptCode(int deptCode)
	public void setDescription(String description)
	public void setName(String name)
	public void setNotificationDest(String notificationDest)
	public void setNotifyOnError(boolean notifyOnError)
	public void setNotifyOnJob(boolean notifyOnJob)
	public void setOwner(String owner)

The ScanAgent class 820 is designed to handle scan-to-file requests. The ScanAgent class 820 is suitably a specialization of InboundEmailAgent class 812.

The ScanTemplate class 822 is a specialization of RasterImageHandler class 818 designed to process scans. The ScanTemplate class 822 is suitably a specialization of RasterImageHandler class 818. Its functionality is detailed in Table 49.

TABLE 49

ScanTemplate Class Functions

	Function

	public ScanAgent getAgent( )
	public String getDocType( )
	public int getExposure( )
	public FileStorage getFileStorageArea( )
	public int getIcon( )
	public String getOriginalSize( )
	public ScanTemplateGroup getParentGroup( )
	public int getResolution( )
	public int getRotation( )
	public boolean isDuplex( )
	public void setDocType(String docType)
	public void setDuplex(boolean duplex)
	public void setExposure(int exposure)
	public void setFileStorageArea(FileStorage fileStorageArea)
	public void setIcon(int icon)
	public void setOriginalSize(String originalSize)
	public void setParentGroup(ScanTemplateGroup parentGroup)
	public void setResolution(int resolution)
	public void setRotation(int rotation)

The ScanTemplateGroup class 824 is a representation of a collection of scan templates. The ScanTemplateGroup class 824 is suitably a specialization of MaintainableComponent class 304. Its functionality is detailed in Table 50.

TABLE 50

ScanTemplateGroup Class Functions

	Function

	public Counter getCounter( )
	public String getDfltEmail( )
	public String getName( )
	public int getNo( )
	public String getOwner( )
	public ScanTemplate getTemplates( )
	public void setDfltEmail(String dfltEmail)
	public void setName(String name)
	public void setNo(int no)
	public void setOwner(String owner)
	public void setPassword(String password)
	public void setTemplates(ScanTemplate templates)

The StorageAgent class 826 is an abstract class representing a generic storage-based agent for processing inbound images, which are suitably scanned images. The StorageAgent class 826 is suitably a specialization of Agent class 802. Its functionality is detailed in Table 51.

TABLE 51

StorageAgent Class Functions

Function

public int getAutoDeleteDays( )

public FileStorage getDestFileStorageArea( )

public FileStorage getDfltFileStorageArea( )

public String getFileNameTemplate( )

public boolean isLocalStorage( )

public void setAutoDeleteDays(int autoDeleteDays)

public void setDestFileStorageArea(FileStorage destFileStorageArea)

public void setDfltFileStorageArea(FileStorage dfltFileStorageArea)

public void setFileNameTemplate(String fileNameTemplate)

public void setLocalStorage(boolean localStorage)

The StoredFaxAgent class 828 is designed to represent an agent for handling stored fax requests. The StoredFaxAgent class 828 is suitably a specialization of StorageJobAgent class 830.

The StoredJobAgent class 830 is an abstract class representing an agent for storing jobs. The StoredJobAgent class 830 is suitably a specialization of StorageAgent class 826. Its functionality is detailed in Table 52.

TABLE 52

StoredFaxAgent Class Functions

	Function

	public String getFolderType( )
	public void setFolderType(String folderType)

The StoredScanAgent class 832 is designed to represent an agent for handling stored scan requests. The StoredScanAgent class 832 is suitably a specialization of StoredJobAgent class 830.

The TWAINAgent class 834 is designed to represent an agent for handling requests for storage into a file share for subsequent TWAIN acquisition. The TWAINAgent class 834 is suitably a specialization of StorageAgent class 826.

Turning now to FIG. 6, a diagram is provided showing the classes of Primary package 300 and structure of the Jobs package 900. The Jobs package 900 is related to Primary package 300 through the Primary-Jobs Relationship 250. The Jobs package 900 comprises a number of classes. Its structure is detailed in Table 53.

TABLE 53

Structure of Jobs Package

	Element	Type

	InboundJob	Class
	Job	Class
	OutboundFaxJob	Class
	OutboundJob	Class
	PrintJob	Class
	PrivatePrintJob	Class
	ProofPrintJob	Class
	RAWPrintJob	Class
	RoutedFaxJob	Class
	ScanJob	Class
	ScheduledFaxJob	Class
	ScheduledPrintJob	Class
	StoredFaxJob	Class
	StoredlnboundJob	Class
	StoredPrintJob	Class
	StoredScanJob	Class

The InboundJob class 902 is an abstract class representing inbound jobs. Inbound jobs are those jobs for which devices receive raster image data. Examples of inbound jobs are incoming faxes and scan jobs. The InboundJob class 902 is suitably a specialization of Job class 904. Its functionality is detailed in Table 54.

TABLE 54

InboundJob Class Functions

	Function

	public Agent getAgent( )
	public String getDetailedStatus( )

The Job class 904 is an abstract class representing a generic job, which is a rudimentary unit of work for a digital imaging device. The Job class 904 is suitably a specialization of Base class 302. Its functionality is detailed in Table 55.

TABLE 55

Job Class Functions and Descriptions

Function	Description

public void Delete( )	Deletes the job from the queue.
	Note: The Job object suitably
	continues to be valid until all
	references to it are released;
	the "status" field suitably
	indicates that the Job has been
	deleted.
public int getDeptCode( )
public int getID( )
public int getPages( )
public String getStatus( )
public String getTime( )
public void setDeptCode(int deptCode)

The OutboundFaxJob class 906 represents an outbound fax job, i.e. a PC-Fax job. Outbound fax jobs are suitably jobs awaiting immediate transmission. The OutboundFaxJob class 906 is suitably a specialization of OutboundJob class 908. Its functionality is detailed in Table 56.

TABLE 56

OutboundFaxJob Class Functions and Descriptions

Function	Description

public static String getJobType( )	Static method that returns the job
	type for Outbound Fax jobs.
public String getOriginalJobType( )

The OutboundJob class 908 is an abstract class representing an outbound job that represents an outbound fax job, i.e. a PC-Fax job. The OutboundJob class 908 is suitably a specialization of Job class 904. Its functionality is detailed in Table 57.

TABLE 57

OutboundJob Class Functions and Descriptions

Function	Description

public String getDocumentName( )
public String getOwner( )
public int getSize( )
public void ReleaseForProcessing( )	Releases the job for further proc-
	essing in case this job is invalid.
	Throws: PrimaryException

The PrintJob class 910 represents a generic print job. The PrintJob class 910 is suitably a specialization of OutboundJob class 908. Its functionality is detailed in Table 58.

TABLE 58

PrintJob Class Functions and Descriptions

Function	Description

public static String getJobType( )	Static method that returns the job
	type for regular Print jobs.
public String getOriginalJobType( )

The PrivatePrintJob class 912 represents a private print job, which is suitably a print job that must be manually released from a device console. The PrivatePrintJob class 912 is suitably a specialization of PrintJob class 910. Its functionality is detailed in Table 59.

TABLE 59

PrivatePrintJob Class Functions and Descriptions

Function	Description

public static String getJobType( )	Static method that returns the
	job type for private Print
	jobs.
public void setPassword(String password)

The ProofPrintJob class 914 represents a proof-print job. The ProofPrintJob class 914 is suitably a specialization of PrintJob class 910. Its functionality is detailed in Table 60.

TABLE 60

ProofPrintJob Class Functions and Descriptions

Function	Description

public static String getJobType( )	Static method that returns the
	job type for Proof Print jobs.
public int getNoCopies( )
public void Release( )	Releases the job immediately.
	Throws: PrimaryException
public void setNoCopies(int noCopies)

The RAWPrintJob class 916 represents a RAW job, which is a job that contains no PJL commands. The RAWPrintJob 916 class is suitably a specialization of PrintJob class 910. Its functionality is detailed in Table 61.

TABLE 61

RAWPrintJob Class Functions and Descriptions

Function	Description

public static String getJobType( )	Static method that returns the job
	type for RAW Print jobs.
public RawJobSettings
getRawJobSettings( )
public void
setRawJobSettings(RawJobSettings
rawJobSettings)

The RoutedFaxJob class 918 represents an inbound fax job that is being routed to a recipient on the network. The RoutedFaxJob class 918 is suitably a specialization of InboundJob class 902. Its functionality is detailed in Table 62.

TABLE 62

RoutedFaxJob Class Functions and Descriptions

Function	Description

public static String getJobType( )	Static method that returns the job
	type for routed fax jobs.
public MailBox getMailbox( )

The ScanJob class 920 represents a scan job. Scan jobs are suitably initiated by a user manually wherein a user inserts paper and selects a scan option. The ScanJob class 920 is suitably a specialization of InboundJob class 902. Its functionality is detailed in Table 63.

TABLE 63

ScanJob Class Functions and Descriptions

Function	Description

public ScanTemplateGroup getGroup( )
public static String getJobType( )	Static method that returns the
	job type for scan jobs.
public ScanTemplate getTemplate( )

The ScheduledFaxJob class 922 represents a fax job scheduled for future transmission. The ScheduledFaxJob class 922 is suitably a specialization of OutboundFaxJob class 906. Its functionality is detailed in Table 64.

TABLE 64

ScheduledFaxJob Class Functions and Descriptions

Function	Description

public static String getJobType( )	Static method that returns the
	job type for scheduled fax jobs.
public String getReleaseTime( )
public void Release( )	Releases the job immediately.
	Throws: PrimaryException
public void
setReleaseTime(String releaseTime)

The ScheduledPrintJob class 924 represents a print job scheduled for future transmission. The ScheduledPrintJob class 924 is suitably a specialization of PrintJob class 910. Its functionality is detailed in Table 65.

TABLE 65

ScheduledPrintJob Class Functions and Descriptions

Function	Description

public static String getJobType( )	Static method that returns the job
	type for Scheduled Print jobs.
public String getReleaseTime( )
public void Release( )	Releases the job immediately.
	Throws: PrimaryException
public void
setReleaseTime(String releaseTime)

The StoredFaxJob class 926 represents stored fax jobs. The StoredFaxJob class 926 is suitably a specialization of StoredInboundJob class 928. Its functionality is detailed in Table 66.

TABLE 66

StoredFaxJob Class Functions and Descriptions

Function	Description

public static String getJobType( )	Static method that returns the job
	type for stored fax jobs.

The StoredInboundJob class 928 is an abstract class representing stored inbound jobs. The StoredInboundJob class 928 is suitably a specialization of InboundJob class 902. Its functionality is detailed in Table 67.

TABLE 67

StoredInboundJob Class Functions and Descriptions

Function	Description

public static String getJobType( )	Static method that returns the
	job type for stored inbound jobs.

The StoredPrintJob class 930 is an abstract class representing a single stored job, which is a job on a device for future printing and/or proofing. The StoredPrintJob class 930 is suitably a specialization of OutboundJob class 908. Its functionality is detailed in Table 68.

TABLE 68

StoredPrintJob Class Functions and Descriptions

Function	Description

public String getFolderName( )
public String getFolderType( )
public static String getJobType( )	Static method that returns the job
	type for stored jobs.
public void setFolderName(String
folderName)

The StoredScanJob class 932 represents stored scan jobs. The StoredScanJob class 932 is suitably a specialization of StoredInboundJob class 928. Its functionality is detailed in Table 69.

TABLE 69

StoredScanJob Class Functions and Descriptions

Function	Description

public static String getJobType( )	Static method that returns the job
	type for stored scan jobs.

Turning now to FIG. 7, a diagram is provided showing the classes of Primary package 300 and structure of the Logs package 1000. The Logs package 1000 is related to Primary package 300 through the Primary-Logs Relationship 230. The Logs package 1000 comprises a number of classes and a subpackage. Its structure is detailed in Table 70.

TABLE 70

Structure of Logs Package

	Element	Type

	InboundJobLogEntry	Class
	LogEntry	Class
	OutboundFaxLogEntry	Class
	OutboundJobLogEntry	Class
	PrintLogEntry	Class
	RoutedFaxLogEntry	Class
	ScanLogEntry	Class
	Messages	Package

The InboundJobLogEntry class 1002 is an abstract class representing a log entry for an incoming job. The InboundJobLogEntry class 1002 is suitably a specialization of LogEntry class 1004. Its functionality is detailed in Table 71.

TABLE 71

InboundJobLogEntry Class Functions

	Function

	public Agent getAgent( )
	public String getDetailedStatus( )

The LogEntry class 1004 is an abstract class representing a generic job log entry. The LogEntry class 1004 is suitably a specialization of Base class 302. Its functionality is detailed in Table 72.

TABLE 72

LogEntry Class Functions

	Function

	public int getDeptCode( )
	public int getID( )
	public int getPages( )
	public int getSize( )
	public String getStatus( )
	public String getTime( )
	public void setDeptCode(int deptCode)

The OutboundFaxLogEntry class 1006 represents a log entry for all kinds of fax jobs. The OutboundFaxLogEntry class 1006 is suitably a specialization of OutboundJobLogEntry class 1008.

The OutboundJobLogEntry class 1008 is an abstract class representing a log entry for an outgoing job. The OutboundJobLogEntry class 1008 is suitably a specialization of LogEntry class 1004. Its functionality is detailed in Table 73.

TABLE 73

OutboundJobLogEntry Class Functions

	Function

	public String getDocumentName( )
	public String getOriginalJobType( )
	public String getOwner( )

The PrintLogEntry class 1010 represents a log entry for all kinds of print jobs. The PrintLogEntry class 1010 is suitably a specialization of OutboundJobLogEntry class 1008.

The RoutedFaxLogEntry class 1012 represents a log entry for an inbound routed fax job. The RoutedFaxLogEntry class 1012 is suitably a specialization of InboundJobLogEntry class 1002. Its functionality is detailed in Table 74.

TABLE 74

RoutedFaxLogEntry Class Functions

	Function

	public String getBoxNo( )

The ScanLogEntry class 1014 represents a log entry for an inbound scan job. The ScanLogEntry class 1014 is suitably a specialization of InboundJobLogEntry class 1002. Its functionality is detailed in Table 75.

TABLE 75

ScanLogEntry Class Functions

	Function

	public String getGroup( )
	public String getTemplate( )

The Message subpackage 1100 is related to Logs package 1000 through the Logs-Messages Relationship 1050. The Message subpackage 1100 comprises a number of classes. Its structure is detailed in Table 76.

TABLE 76

Structure of Messages Subpackage

	Element	Type

	FaxMessageEntry	Class
	MessageEntry	Class
	PrintMessageEntry	Class
	RoutedFaxMessageEntry	Class
	ScanMessageEntry	Class

The FaxMessageEntry class 1102 is an abstract class representing a fax message entry. The FaxMessageEntry class 1102 is suitably a specialization of MessageEntry class 1104. Its functionality is detailed in Table 77.

TABLE 77

FaxMessageEntry Class Functions

	Function

	public static String getComponentName( )

The MessageEntry class 1104 is an abstract class representing a generic message log entry. The MessageEntry class 1104 is suitably a specialization of Base class 302. Its functionality is detailed in Table 78.

TABLE 78

MessageEntry Class Functions

	Function

	public String getComponent( )
	public String getDescription( )
	public int getID( )
	public String getSeverity( )
	public String getTime( )

The PrintMessageEntry class 1106 is an abstract class for printing message log entries. The PrintMessageEntry class 1106 is suitably a specialization of MessageEntry class 1104. Its functionality is detailed in Table 78.

TABLE 78

PrintMessageEntry Class Functions

	Function

	public static String getComponentName( )

The RoutedFaxMessageEntry class 1108 represents a message entry for a routed fax job. The RoutedFaxMessageEntry class 1108 is suitably a specialization of MessageEntry class 1104. Its functionality is detailed in Table 79.

TABLE 79

RoutedFaxMessageEntry Class Functions

	Function

	public static String getComponentName( )
	public String getDetailedStatus( )

The ScanMessageEntry class 1110 represents a message entry for a scan job. The ScanMessageEntry class 1110 is suitably a specialization of MessageEntry class 1104. Its functionality is detailed in Table 80.

TABLE 80

ScanMessageEntry Class Functions

	Function

	public static String getComponentName( )
	public String getDetailedStatus( )

Turning now to FIG. 8, a diagram is provided showing the classes of Primary package 300 and structure of the Maintenance package 1200. The Maintenance package 1200 is related to Primary package 300 through the Primary-Maintenance Relationship 240. The Maintenance package 1200 comprises a number of classes. Its structure is detailed in Table 81.

TABLE 81

Structure of Maintenance Package

	Element	Type

	FileStorage	Class
	HouseKeeper	Class
	LoadableComponent	Class
	RemoteComponent	Class
	UpgradeRecord	Class

The FileStorage class 1202 is an abstract class representing the file storage associated with a device. The file storage is suitably maintained by the device itself or elsewhere on a network. The FileStorage class 1202 is suitably a specialization of Base class 302. Its functionality is detailed in Table 82.

TABLE 82

FileStorage Class Functions and Descriptions

Function	Description

public void Clear( )	Remove all components
	(files) in the area.
	Throws:
	PrimaryException
public String getDescription( )
public int getFreeDiskSpace( )
public String getName( )
public String getURL( )
public void setDescription(String description)
public void setName(String name)
public void setURL(String URL)

The HouseKeeper class 1204 is an abstract class for providing general maintenance functionality. The HouseKeeper class 1204 is suitably designed in the form of a utility class and is suitably a specialization of Base class 302. Its functionality is detailed in Table 83.

TABLE 83

HouseKeeper Class Functions and Descriptions

Function	Description

public FileStorage	Creates a storage area by unique name.
CreateStorageArea(String name,