Method and System for Distributed Processing of Applications on Host and Peripheral Devices

The present invention relates generally to peripheral device architecture and, more specifically, to a method and system for the distributed execution of applications among host computer systems and peripheral devices.

A portion of the disclosure of this patent document including Appendix I, The JAVA.sup.1 Virtual Machine Specification and Appendix I thereto, contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the U.S. Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.

Network computing has grown at a phenomenal rate over the last decade. In a network computing environment, a user has access to the computing power of multiple computers located on a network. Sun Microsystems Inc., a leader in network computing has even gone as far as developing a marketing campaign around the slogan "The Network Is the Computer".TM. to emphasize the commercial success of this growing segment of the computing market. Recently, this slogan has become reality as millions of users have tapped the computing resources available from the thousands of computers on private intranets, the Internet and the World Wide Web.

Many individuals and organizations in the computer and communications industries tout the Internet as the fastest growing market on the planet. In the 1990s, the number of users of the Internet appears to be growing exponentially with no end in sight. In June of 1995, an estimated 6,642,000 hosts were connected to the Internet; this represented an increase from an estimated 4,852,000 hosts in January, 1995. The number of hosts appears to be growing at around 75% per year. Among the hosts, there were approximately 120,000 networks and over 27,000 web servers. The number of web servers appears to be approximately doubling every 53 days.

In July 1995, with over 1,000,000 active Internet users, over 12,505 usenet news groups, and over 10,000,000 usenet readers, the Internet appears to be destined to explode into a very large market for a wide variety of information and multimedia services.

In addition, to the public carrier network or Internet, many corporations and other businesses are shifting their internal information systems onto an intranet as a way of more effectively sharing information within a corporate or private network. The basic infrastructure for an intranet is an internal network connecting servers and desktops, which may or may not be connected to the Internet through a firewall. These intranets provide services to desktops via standard open network protocols which are well established in the industry. Intranets provide many benefits to the enterprises which employ them, such as simplified internal information management and improved internal communication using the browser paradigm. Integrating Internet technologies with a company's enterprise infrastructure and legacy systems also leverages existing technology investment for the party employing an intranet. As discussed above, intranets and the Internet are closely related, with intranets being used for internal and secure communications within the business and the Internet being used for external transactions between the business and the outside world. For the purposes of this document, the term "network" includes both the Internet and intranets. However, the distinction between the Internet and an intranet should be borne in mind where applicable.

In 1990, programmers at Sun Microsystems wrote a universal programming language. This language was eventually named the JAVA programming language. (JAVA is a trademark of Sun Microsystems of Mountain View, Calif.) The JAVA programming language resulted from programming efforts which initially were intended to be coded in the C++ programming language;

therefore, the JAVA programming language has many commonalities with the C++ programming language. However, the JAVA programming language is a simple, object-oriented, distributed, interpreted, yet high performance, robust, yet safe, secure, dynamic, architecture neutral, portable, and multi-threaded language.

The JAVA programming language has emerged as the programming language of choice for the Internet as many large hardware and software companies have licensed it from Sun Microsystems. The JAVA programming language and environment is designed to solve a number of problems in modem programming practice. The JAVA programming language omits many rarely used, poorly understood, and confusing features of the C++ programming language. These omitted features primarily consist of operator overloading, multiple inheritance, and extensive automatic coercions. The JAVA programming language includes automatic garbage collection that simplifies the task of programming because it is no longer necessary to allocate and free memory as in the C++ programming language. The JAVA programming language restricts the use of pointers as defined in the C++ programming language, and instead has true arrays in which array bounds are explicitly checked, thereby eliminating vulnerability to many viruses and nasty bugs. The JAVA programming language includes objective-C interfaces and specific exception handlers.

The JAVA programming language has an extensive library of routines for coping easily with TCP/IP protocol (Transmission Control Protocol based on Internet protocol), HTTP (Hypertext Transfer Protocol) and FTP (File Transfer Protocol). The JAVA programming language is intended to be used in networked/distributed environments. The JAVA programming language enabled the construction of virus-free, tamper-free systems. The authentication techniques are based on public-key encryption.

These networked/distributed applications written in "write once run everywhere" programming languages such as JAVA need peripheral devices which operate under the same paradigm. Applications executed in a networked/distributed environment should also be able to interface with a wide variety of peripheral devices in an orthogonal and simple to use fashion. For example, users should be able to execute different application programs on multiple heterogeneous platforms and then print output from these applications on a variety of printer devices without concern over: device drivers; printer capabilities; or executing preprocessing data conversion routines.

Further, networked peripheral devices should be just as available for distributed processing as networked computers. For example, if a printer is attached to an intranet or the Internet, a user should be able to print a job remotely from work or home as long as a communication signal can be established between the user's remote computing device and the printer device. Likewise, the user should be able to execute applications and access other peripheral devices such as digital image capture devices, telecommunication devices, display devices, or even a sound generation device in a similar fashion. Essentially, the user should be able to use a peripheral device based on the needs of an application and not the availability of a particular device driver. For example, a desktop publishing application should be able to take pictures from different digital cameras located all over the world. If these digital cameras are coupled to the users computer over a network, the user should be able to select the camera which has a desired image and not be limited to the cameras compatible with his or her particular hardware platform. Essentially, a remote user should have the same amount of control over the camera's operation as a user would holding the camera. The user should then be able to display this image on a screen, print the image out on a printer, or deliver the image to a host computer. The image should even be compatible with devices such as a facsimile machine or digital based television such as HDTV (high definition television).

Moreover, peripheral device manufacturers and application developers should be able to develop products which work together for several types of peripheral devices and a wide range of operating environments. The peripheral device manufacturer should provide a predetermined set of functionalities capable of accessing the various features of the particular peripheral device. These finctionalities should be robust and easy to use so that people can rely on the technology for a long period of time. On the application development side, software developers should be able to make abstract calls to certain predetermined function calls without concern for the actual peculiarities of the underlying peripheral device. For example, a single printer management application should be able to manage and configure a wide range of printers, from a number of different manufacturers using a single GUI (graphical user interface) application. This would enable a user to select the printer device best suited for the print job rather than the printer compatible with the loaded device drivers.

Unfortunately, at present users do not have the luxury of using a peripheral device on a network unless their computer has the device driver required by the specific application and peripheral device combinations because the existing systems use a device driver to convert information generated by the application into a format a peripheral device can use. Typically, the driver receives data from the application, formats the data in a manner acceptable to the peripheral device, sends the data over the appropriate communication channel, and then provides the user with status of the job. Developing device drivers is complex because the peripheral device and the particular application are typically not developed using a standard interface. The device driver must be written to conform to the hardware specifications of the peripheral device. For example, obtaining status on a printer requires that the driver must interpret low level signals sent over the hardware interface. If the hardware is modified or changes, the device driver must also be modified accordingly.

It follows that developing device drivers or upgrades to the device drivers is an expensive and challenging project for most peripheral device manufacturers. In some cases, developing the device drivers can be a more daunting task than developing the peripheral device itself. For example, the peripheral device manufacturer must develop a different device driver for each different application, hardware platform, operating system, and sometimes also for each of the different versions associated with these different categories. This takes a significant amount of research and development. Later, the peripheral device manufacturer must support each driver released and provide updates to the drivers as problems are fixed.

In many ways, the success of a peripheral device can depend a great deal on the quality of the device drivers. A serious mistake or flaw in a device driver developed for a new operating environment or application can often cause the peripheral device to fail or produce less than optimal results. This results in wide spread customer dissatisfaction with a peripheral device even though the device is capable of producing higher quality results or output. For example, a printer capable of high resolution printing such as 1200 dpi may work suboptimal with an old or defective driver by falling back to a lower resolution such as 300 dpi. A user may return the printer because of the apparent defect or low quality even though the problem is with the driver and not the printer.

Setting up and administering peripheral devices is also difficult in a heterogeneous environment since so many devices have different capabilities and diagnostic conditions. In many cases, each different peripheral device comes with stand-alone diagnostic application and drivers which must be installed on each machine that interacts with the device. These various diagnostic tools are typically proprietary and communicate with each peripheral device based on proprietary predetermined hardware signals. The interpretation of these signals is left up to logic contained within each diagnostic software application and varies from device to device. For example, a hardware signal generated from one printer device may indicate that the printer is "out of paper" while the same signal transmitted to a second printer device may cause the printer and host computer to crash or "lock-up". Accordingly, the proprietary nature of current peripheral device architecture designs makes it infeasible to use a single application to manage a large heterogeneous collection of peripheral devices.

Several companies have attempted to solve incompatibilities between peripheral devices by creating several different page description layout (PDL) languages. Unfortunately, PDL languages do not properly address all the shortfalls associated with controlling peripheral devices. Even though, these page description languages organize the layout of page information in a programmatic manner they do not allow general purpose processing. For example, PostScript, PCL, Adobe Acrobat, Adobe PrintGear, Microsoft Graphics Device Interface, and Apple QuickDraw are all different PDL language variations which describe how data should be placed on the page but do not enable the printer to perform general purpose operations. Further, existing PDL languages are generally too complex and limited to develop important applications such as conversion routines to convert between different image formats such as between TIFF, GIF, and JPEG. Essentially, these PDL languages only simplify the portion of printing which deals with page layout on a printer but do not simplify all the problems associated with peripheral device compatibility.

PDL languages are also unsuccessful in increasing peripheral device compatibility because no particular PDL language has been widely accepted. This has caused the peripheral market to become fragmented among different standards such as PCL (printer control language) and PostScript. Ironically, this has caused device driver development to become even more complex as the peripheral device manufacturers and users must deal with more, not less, device drivers and options. Under the current technology, this means that users can be required to load more device drivers in order to match the personality of the printer (e.g. PostScript, PCL) and the application being used. Accordingly, the various PDL languages being used have actually made peripheral device control and management more complex.

What is needed is a peripheral device architecture which integrates software applications with the peripheral device hardware in a uniform manner. Applications written to work with one brand and make of peripheral device should also be able to function with another brand and make of a peripheral device without loading new drivers, new software, or new versions. Users should be able to use a wide range of peripheral devices and distribute processing over an intranet or the Internet to the peripheral devices most appropriate for the application. Further, status and diagnostics should be readily available on a single application from a wide range of peripheral devices.

According to principles of the invention, a distributed data processing system having a host computer coupled by way of a network to one or more peripheral devices is presented. In part, this distributed data processing system has advantages over current technologies because executables running on a host device can also be downloaded and executed on a target peripheral device. A virtual machine instruction processor located in the host machine and the peripheral device run the same instruction set and therefore facilitate the sharing of executables. This capability opens up robust communication between the peripheral device and the host machine and sophisticated peripheral device management and administration. Of course, in a large business organization this also results in lower total cost of operation and ownership because peripheral devices can be managed more easily and more efficiently. Essentially people can be use peripheral devices more easily than before and be more productive as a result. In view of these characteristics, a distributed data processing system based on peripheral devices with embedded virtual machine instruction processors presents attractive price for performance characteristics, if not the best overall performance, as compared with current peripheral architecture solutions.

In one embodiment of the invention, the distributed data processing system includes a peripheral database, a number of host computers each including a first virtual machine instruction processor capable of executing one or more virtual machine instructions, and a number of peripheral devices each having a second virtual machine instruction processor capable of executing one or more virtual machine instructions. The host computers and the peripheral devices are typically coupled together by a communications network. In this embodiment, the peripheral database is coupled to the network and contains information concerning the capabilities for each of the peripheral devices coupled to the network. In addition to the first virtual machine processor, the host computer also generally includes a first network interface coupled to the network suitable for bi-directional transmission of data from the host computer to the network. Typically, bi-direction transmission of data includes status information on the host computer and the peripheral device on the network. A storage device coupled to the host computer is generally used to store an application which requires use of a peripheral device and is composed of one or more virtual machine instructions. The system also includes a determination mechanism typically embedded in the application which queries the peripheral database based upon a predetermined criteria and selects which peripheral device should execute the application. Once the determination mechanism embedded in the application selects the proper peripheral device, a download mechanism, also coupled to the first network interface, transfers data and, optionally, a portion of the application to the selected peripheral devices for execution. In an alternative embodiment, the download mechanism only downloads data into the selected peripheral device whereupon an existing application in the selected peripheral device operates on the data.

Another embodiment of the invention provides a method for using the distributed data processing system above to distribute the processing of an application between a host computer and one or more peripheral devices coupled to a network. Initially, the method collects information concerning the capabilities for each of the one or more peripheral devices coupled to the network. This information can be stored in a single area on the network, such as a database, or may be distributed in several areas on the network such as in each peripheral device. Next, the method executes an application composed of one or more virtual instructions on a host computer having a virtual machine instruction processor. The application typically has a predetermined criteria for one or more peripheral devices. This predetermined criteria is then used by the method to query the information collected concerning the capabilities for each of the one or more peripheral devices. The query results are then used to select which peripheral device should execute the application. In one embodiment, the method then transfers data and at least a portion of the application to the selected peripheral device. Typically, this application then executes on the selected peripheral device using the transferred data. Further, a bidirectional communication between the selected peripheral device and the host computer is established. This bidirectional communication facilitates the transmitting and receiving of information associated with the selected peripheral device and the host computer. This information can be useful in obtaining additional status or control over the peripheral device and the host computer.

FIG. 1 illustrates a computer network for practicing one embodiment of the present invention.

FIG. 2 is block diagram illustrating further details of a processing unit used in a peripheral device such as a printer.

FIG. 3. is a flow chart illustrating the general steps used by one embodiment of the present invention to distribute processing of an application between a host computer and one or more peripheral devices.

FIG. 4. is a flow chart illustrating the general steps used by an alternative embodiment of the present invention to distribute processing of an application between a host computer and one or more peripheral devices.

FIG. 1 illustrates a computer network 100 for practicing one embodiment of the present invention. Computer network 100 includes at least one host computer system such as a host computer 102A coupled to one or more peripheral devices such as a printer 102B, an image capture device such as a camera 102C, a telecommunication device such as a telephone 102D, an image display device such as an HDTV television 102E, an image input device such as a scanner 102F, and a sound generator device such as a stereo 102G. In addition, computer network 100 includes a peripheral database 110 for storing a profile of the capabilities for each of the one or more peripheral devices coupled to the network. In a typical implementation, host computer 102A and the one or more peripheral devices 102B-102G are capable of unicast (i.e. point-to-point) or multicast communications over the network using a common network communication mechanism such as the TCP/IP protocol running under an operating system such as JAVA/OS, Apple Macintosh Operating System, OS/9, OS/2, UNIX, MVS, VM, DOS, or even a Microsoft Windows based operating system. As will be apparent from the discussion below, having a virtual machine instruction processor embedded in a peripheral device is one novel aspect of the present invention which facilitates distributed processing on many peripheral devices in a heterogeneous computing environment.

In accordance with the principles of the present invention, host computer 102A and peripheral devices 102B-102G include a processing unit 106A-106G respectively. Typically, each processing unit 106A-106G implements a virtual machine instruction processor 108 for processing virtual machine instructions. For clarity, other elements in processing unit 106A-106G discussed below and illustrated in FIG. 2 have been omitted in FIG. 1.

It should be understood that virtual machine instruction processor 108 need not be identical in each processing unit 106A-106G as long the instructions executed on each virtual machine instruction processor are compatible based on a virtual machine instruction specification such as the "JAVA Virtual Machine Specification" included in Appendix I. In one embodiment, all instructions executed on host computer 102A and peripheral devices 102B-102G are executed on one or more virtual machine instruction processors 108. Thus, on this type of system the operating system and the applications include virtual machine instructions rather than proprietary or native processor instructions. Alternatively, in another embodiment, one or more virtual machine instruction processors 108 can be used as co-processors in conjunction with proprietary instruction processors such the Intel Pentium and x86 processors, the Sun SPARC and UltraSPARC processors, Motorola 68000, and PowerPC processors where virtual machine instruction processor 108 executes portions of the applications and operating system which use virtual machine instructions and the proprietary instruction processor executes the remainder of instructions not using virtual machine instructions.

In general, the combination of a virtual machine instruction processor embedded in a peripheral device facilitates a level of distributed computing between peripheral devices and host computers which was previously unavailable in the art. This novel design enables the sharing of resources and the distribution of processing not only between two host computers coupled to a network but between peripheral devices and host computers as well. To illustrate some of these efficiencies and benefits, a more detailed discussion below provides one method for distributing the processing of an application between a host computer and one or more peripheral devices.

Referring to FIG. 2, a block diagram illustrates further details for processing unit 106B as used in a peripheral device such as printer 102B (FIG. 1) coupled to computer network 100. Processing unit 106B in FIG. 2 includes a primary network interface 212, a secondary network interface 211, a virtual machine instruction processor 214, a primary storage 216, a secondary storage 218, a peripheral engine interface 220, a proprietary processor unit 222 and an input-output interface 224 which facilitates communication between these aforementioned elements. In this context, peripheral engine interface 220 couples processing units such as processing unit 106B to a core engine central to the functioning of the peripheral device. For example, the core engine in a printer is considered a print engine while the core engine in a television could be the CRT (cathode ray tube) and all the supporting circuitry needed to generate an image on the CRT. Details on the specific core engine used to operate each peripheral device is not essential to embodiments of the present invention and is beyond the scope of the present discussion.

Primary network interface 212 is typically used to couple processing unit 106B (FIG. 2) to network 100 (FIG. 1) and facilitate communication between a peripheral device such as printer 102B (FIG. 1) and other peripheral devices or host computers on network 100 (FIG. 1). Optionally, a secondary network interface 211 couples processing unit 106B (FIG. 2) to a second network (not shown) and facilitates communication between the particular peripheral device and other peripheral devices or host computers coupled to a second network (not shown). Those skilled in the art will understand that primary network interface 212 or secondary network interface 211 can also be coupled to a router device (not shown) or switch device (not shown) in which case the corresponding peripheral device can communicate with a multitude of networks, host computers, and other peripheral devices. Further, those skilled in the art will appreciate that primary network interface 212 and secondary network interface 211 can include both serial and parallel technologies typically used to couple peripheral devices to networks including Ethernet, X.25, SCSI (small computer systems interface), SDLC, HDLC, IEEE 1394 ("FireWire"), IEEE 1284 (Enhanced Communication Port--ECP), and other high speed low-latency communication technologies. Selecting the appropriate communication link will depend on the price-performance required as well as compatibility requirements for the overall design.

In operation, virtual machine instruction processor 214 in FIG. 2 is used in a peripheral device such as printer 102B (FIG. 1) to fetch virtual machine instructions from primary storage 216 through input-output interface 224. After retrieving the virtual machine instructions, virtual machine instruction processor 214 then executes the instructions. Executing these computer instructions enables virtual machine instruction processor 214 to retrieve data or write data to primary storage 216, display information on one or more computer display devices (not shown), receive command signals from one or more input devices (not shown), or transmit the appropriate signals through peripheral engine interface 220 causing a peripheral device to operate. These virtual machine instructions can also retrieve data or write data to secondary storage 218, host computer 102A (FIG. 1), or other peripheral devices coupled to network 100 (FIG. 1). Those skilled in the art will understand that primary storage 216 and secondary storage 218 can include any type of computer storage including, without limitation, randomly accessible memory (RAM), read-only-memory (ROM), application specific integrated circuits (ASIC) and storage devices which include magnetic and optical storage media such as CD-ROM. Preferably, virtual machine instruction processor 214 implements the JAVA virtual machine as specified in the "Java Virtual Machine Specification" in Appendix I. In one embodiment, virtual machine instruction processor 214 includes any of the JAVA based processors developed and marketed by Sun Microsystems, Inc. or JAVA compatible processors developed by other companies. For information on virtual machine instruction processors see U.S. patent application Ser. No. 08/788,807, entitled "A HARDWARE VIRTUAL MACHINE INSTRUCTION PROCESSOR" naming Marc Tremblay and James Michael O'Connor as inventors, assigned to the assignee of this application, and filed on Jan. 23, 1997 with Attorney Docket No. P2044, still pending which is incorporated herein by reference in its entirety. Virtual machine instruction processor 214 can also be any of the SPARC or UltraSPARC compatible processors also available from Sun Microsystems, Inc. of Mountain View, California and other companies. Alternatively, virtual machine instruction processor 214 can be based on the PowerPC processor available from Motorola of Schaumburg, Ill., any of the Pentium or x86 compatible processors available from the Intel Corporation or other corporations such as AMD, and Cyrix, or any other proprietary processor capable of executing virtual machine instructions.

Optionally, proprietary processor 222 can be used in conjunction with virtual machine instruction processor 214 as a coprocessor for certain specialized compute intensive virtual machine instructions relating to areas such as graphics, floating point, and digital signal processing. Proprietary processor 222 can also be used as a secondary processor for running instructions which are not virtual machine instructions. In this latter capacity, proprietary processor 222 can be used to execute local processing peculiar to the local peripheral device and not suitable for distributing for execution to other host computers or peripheral devices coupled to the network. This can include the execution of memory management units, multitasking queueing operations, or any other operations typically associated with a runtime environment, an operating system, or more specifically, a kernel. For example, if proprietary processor is assisting virtual machine instruction processor 214 as a coprocessor, instructions can flow directly from virtual machine instruction processor 214 and if proprietary processor 222 is not directly assisting virtual machine instruction processor 214, then proprietary processor 222 can act as a secondary processor wherein instructions can flow from primary storage 216 via input-output interface 224.

Referring to FIG. 2, primary storage 216 includes a peripheral API 228 (application programming interface), an executable computer program 226, and optionally an operating system 230 for managing resources on the peripheral device or host computer. In one embodiment, peripheral API 228 utilizes an object-oriented, highly extensible programming language called JAVA which is developed and marketed by Sun Microsystems Inc. This peripheral API enables executable computer programs 226 to access functionality associated with a peripheral device such as printer 102B using hardware independent and architecturally neutral system calls. These system calls correspond to specific virtual machine instructions which execute on virtual machine instruction processor 214 in the form of bytecodes and cause the peripheral device to operate in a specified manner. This is one important aspect of the present invention which provides features and capabilities previously unavailable in the art.

Using peripheral API 228, an application can request functionality from a peripheral device without knowing the specifics of how the particular device operates. Essentially, the peripheral device invokes certain predetermined system calls in peripheral API 228 which in turn invokes virtual machine instructions on the virtual machine instruction processor and causes the peripheral device to operate. This benefits application developers because a single application using peripheral API 228 can run on a variety of different devices without recompiling or including special drivers or libraries. It also benefits users because they can use many devices on the network without reloading or reconfiguring their systems. Further, this also benefits the peripheral device manufacturers because the peripheral device becomes compatible with a larger number of applications. Each time a new peripheral device is developed the manufacturer need only port peripheral API 228, written in JAVA, to the to the particular peripheral device. This obviates the need to support different device drivers for each application and/or operating system combination. Further details on peripheral API 228 are discussed below.

Depending on the resources and complexity of the peripheral device, operating system 230 can be relatively simple or very complex. Typically, operating system 230 includes networking protocol stacks such as TCP/IP, X.25, SNA, or portions of network operating systems such as NetWare.RTM..sup.1 for controlling the transmission and receipt of data and executable programs over the network. Operation system 230 can also be responsible for swapping executable computer program 226 in primary storage 216 or secondary storage 218 for execution by virtual machine instruction processor 214. Accordingly, in one embodiment, operating system 230 is the JAVA OS operating system which can be executed on virtual machine instruction processor 214 and processes JAVA language instructions most efficiently. Alternatively, operating system 230 can include the Solaris operating system, the Internetworking Operating System (IOS) used in CISCO router devices, DOS, Windows NT, Windows 95, or any other operating system capable of managing resources and processing requests associated with a particular peripheral device or host computer.

In general, those skilled in the art will understand that the principles discussed above and associated with processing unit 106B (FIG. 1) as used in a printer 102B can also be applied to other peripheral devices such as peripheral devices 102C-102F as well as any other peripheral device used in a distributed computing environment.

A. Peripheral API

In accordance with the present invention, peripheral API 228 (FIG. 2) is used by executable computer program 226 as an interface to virtual machine instruction processor 214 which then drives a peripheral device such as peripheral devices 102C-102G (FIG. 1) discussed above. These APIs take advantage of the fact that applications typically perform the same imaging and multimedia operations over a wide range of peripheral devices. For example, an application which prints to a printer may also want to print to a FAX device or to multiple display screens located in different geographic locations.

Using a virtual machine instruction set to implement peripheral API 228 provides additional benefits because the same code can be executed on many different peripheral devices without recompilation. For example, applications which make calls to peripheral API 228 using JAVA can interface with different peripheral devices because the processor is either a JAVA processor or implements the JAVA virtual machine. To drive a peripheral device, the application need only download the application or applet into the virtual machine instruction processor located on the peripheral device.

The virtual machine instructions used to implement peripheral API 228 are also beneficial because processing of the jobs can be distributed or relocated on different host computers or peripheral devices. For example, using peripheral API 228 described below enables a first peripheral device to request a second peripheral device (not shown) to process data and return the image for further processing on the first peripheral device. Therefore, well written applications can perform peripheral operations in parallel and improve the effective performance of a given peripheral device.

An exemplary embodiment of peripheral API 228 has been provided below which is well suited for printer devices and digital camera devices. In this embodiment, peripheral API 228 includes the following categories: 1) text handling; 2) font handling; 3) image processing; 4) 2d & 3d graphics processing; 5) color processing; 6) matrix handling; 7) device handling; 8) connection handling; 9) administration; 10) job handling; and 11) connectivity with other digital devices. Those skilled in the art will understand that these general concepts and techniques are not limited solely to printer devices and the like and can be used directly or indirectly to develop peripheral APIs for devices not explicitly mentioned herein.

Text handling and Font handling

In most peripheral devices, a significant portion of the information being input, output, or manipulated by the peripheral device is text. This category of routines deals with the manipulation of text by changing the size of the text, the style of the text, and also allows for operations on the rotation of the text using a TextMatrix() routine. For example, an application which wants to change the text font to italic on a printer device will call the TextStyle() routine with a "Italic" argument in the parameter list. This instruction will be executed by the virtual machine processor in the peripheral device which will cause the correct font to be downloaded over the network or off a local storage device and used for printing.

The FontLocation(fontID) and FontLoad(virtual.sub.-- location) are particularly interesting system calls because they enable an application to direct the printer to download a font from a remote location rather than downloading the font directly from the host computer running the application. These functions can result in significant cost and time savings. For example, a host computer printing a job can download into the printer the URL location of a particular font located on the World Wide Web which is to be used in a given document. This saves storage space because only a few central repositories of fonts need be located on a given network and actual font data is not replicated on each host system in a network. Instead, each reference to a given font is downloaded from a server containing hundreds and thousands of fonts. The user experiences improved performance because fonts are downloaded by the peripheral device and not the host computer.

Another interesting system call is ReadThirdPartyFont(fontID) which allows the peripheral device to process fonts provided by a third party vendor and not supported in the native peripheral API. For example, a font designer using PCL fonts may provide an applet which processes PCL fonts for use in a particular application. This applet would be downloaded into the peripheral device from an appropriate place on the network when the application requires PCL fonts. This system call provides flexibility in which fonts are used by a peripheral device and allows the personality of the peripheral device to be configured dynamically.

In one embodiment, the following API routines can be used to manipulate text on a peripheral device.

1) Text Handling

1.1) Text Matrix Selection

1.1.1) TextSize(x,y)

1.1.2) TextStyle(type)

1.1.3) TextMatrix(matrix

1.2) text positioning

1.2.1) TextMove(x,y)

1.3) text output

1.3.1) Textoutput(string)

2) Font Handling

2.1)Type 1

3.1.1) ReadType1Font(fontID)

2.2) TrueType

3.2.1) ReadTrueTypeFont(fontID)

2.3) font location

3.3.1) FontLocation(fontID)

2.4) font selection

3.4.1) FontSelect(fontID)

3.4.2) FontPurge(fontID)

2.5) font download from URL/Server

3.5.1) FontQuerv(fontID)

Query font with server if none is in printer

3.5.2) FontLoad(virtual location)

2.6) Third-party font process

3.5.1) ReadThirdPartyFont(fontID)

NOTE: this will be subsituted by third party vendor Image Processing

The other information typically processed by a peripheral device displaying or processing visual information is images. These images are typically digitized into pixels and when displayed have different colors, textures, and other visual features. Often, they come in many compression and encoding formats such as GIF, TIFF,JPEG, HTML, or Adobe Acrobat. In one embodiment, several system calls allow the peripheral device to convert between these different compression and encoding formats. The user can also request that the peripheral device add certain background patterns to the image generated by a peripheral device using the Pattern Selection system calls. Further, the user can also request the peripheral device to perform sophisticated image manipulation using the Image Operation set of system calls. The user can even request a peripheral device such as a digital camera only detect certain objects by using sophisticated image analysis routines as described in the Image Analysis and Recognition system calls. In general, this set of APIs enables a user to perform intense image processing routines on a remote peripheral device and off-load processing on the host computer. Accordingly, in one embodiment, the following routines could be used to perform various image processing tasks.

3) Image Processing

3.1) Pattern Selection

3.1.1) PatternSelect(patternID)

3.1.2) PatternLoad(patternID)

3.1.3) PatternLocation(patternID)

3.1.4) PatternPurge(patternID)

3.2) Transparancy mode

3.2.1) SourceTransparancySelect()

3.2.2) PatternTransparancySelect()

3.2.3) CompositeSelect()

3.3) Image Operation

3.3.1) ImageScale()

2.3.2) ImageRotate()

3.3.3) Imageoutput()

3.3.4) ImageTranslate()

3.3.5) Image Clipping()

3.4) Image Filtering

3.4.1) JPEGFilter()

3.4.2) GIFFilter()

3.4.3) CCITTFilter()

3.4.4) LZWFilter()

3.4.5) RunLengthFilter()

3.4.6) TIFFFilter()

3.4.7) ThirdPartyFilter()

3.5) Image Anaylses & Recoginition

3.5.1) ImageAnaylese()

3.5.2) ImageRecoginition()

3.5.3) ImageSharpen

3.5.4) ImageEnhance()

3.5.5) ImageEdgeDetect()

3.5.6) ImageEmboss()

3.5.7) ImageConvert()

3.6) image block transfer (for fast image process)

3.6.1) ImageBitBlt()

2d & 3d graphics processing

With the increase in high-end simulations and games, most applications display images having 2-D and 3-D attributes. Often these routines are most difficult to implement because the human eye must be tricked into believing objects on a 2-D screen have 3-D attributes. This requires a great deal of control over the graphic processing routines. Further, it would be advantageous if processing required by these routines are off-loaded to the peripheral device thus freeing up processing on the host computer. For example, users playing a virtual reality game on a system having numerous display terminals could download the graphical rendering routines into each display terminal thus distributing the 3-D graphics processing load from the host machine. Further, a user wishing to capture a particular scene during the virtual reality game could download the particular scene to a printer device having a virtual instruction processor which would then process the information and print out the 3-D scene as desired.

The 3D Graphics system calls are particularly interesting because they allow the peripheral device to perform a 2D to 3D conversion. In the past, the host computers converted 3D graphics into 2D images and transferred the resulting bit maps onto the peripheral devices such as a printer. Using 3D Graphics calls enables the host processor to request that the peripheral device perform these conversions instead. This allows the host processor to transfer 3D graphics to the printer directly without the 3D to 2D conversion.

In one embodiment, the following routines can be used to control 2D and 3D graphics: processing on peripheral devices:

4.1) line attribute

2d & 3d graphics processing

4.1.1) LineWidth()

4.1.2) LineType()

4.1.3) LineEnds()

4.1.4) LineJoins()

4.1.5) LineMiterLimit()

4.2) path operation

4.2.1) BezierPath()

4.2.2) LinePath()

4.2.3) ArcPath()

4.2.4) RectanglePath

4.2.5) ClosePath()

4.2.6) NewPath()

4.2.7) AddPath()

4.3) clip operation

4.3.1) ClipSelect

4.3.2) SetClipPath

4.3.3) ClipPath

4.3.4) EOClipPath

4.4) filling and stroking

4.4.1) FillPath

4.4.2) StrokePath

4.4.3) EOFillPath()

4.4.4) StrokeAdjust()

4.4.5) DrawLine

4.4.6) DrawRect

4.4.7) DrawCircle

4.4.8) DrawArc

4.4.9) FillRect

4.4.10) FillCircle

4.4.11) FillArc

4.5) 3D graphics

4.5.1) GradientTypeSelect

4.5.2) GradientFill

4.5.3) TBD

Color Processing

Color processing is another important feature in peripheral devices because it directly affects the realism or aesthetic appeal of the output. Different color processing routines can render images more quickly than others and also have better resolution and visual acuity. Also, color matching heuristics are used to ensure the colors which appear on one peripheral device, such as a display terminal, closely match the same colors which appear on another peripheral device, such as a color printer. If these color processing applications are written in a virtual machine instruction language such as JAVA and used in embodiments of the present invention, many peripheral devices can take advantage of the available features.

The ThirdPartyColorManagementSelect system call is an interesting feature which enables a user or application to install different color management heuristics. This feature allows the user to select the color matching technique which works best for the particular peripheral device and image being rendered. This allows the user or application to take advantage of newer and improved color matching techniques as they are developed and improves on the prior art techniques where the color matching techniques were hardcoded into firmware of the peripheral device.

Accordingly, the following API is one embodiment for providing these functions to a color peripheral device.

5) color processing

5.1) color setting

5.1.1) CurrentColor

5.1.2) SetColor

5.2) color space

5.2.1) ColorSpaceSelect

5.2.2) ColorSpaceConversion

5.3) color management

5.3.2) ThirdPartyColorManagementSelect

TBD

5.4) screen selection

5.4.1) DitherSelect

5.4.2) HalftoneSelect

TBD

Matrix Operations

Image processing and image enhancement is also another important area of peripheral device management and usage. These types of functions enable the user to manipulate the data using matrices and modify some characteristic of the appearance. The Global Matrix Settings set the default behavior for all pages, text, and images used on a particular peripheral device. In contrast, the Matrix Operations are used to perform individual operations on different pieces of image data. In some cases, the matrix may be used to create a special effect and make the end result look surrealistic or fabricated. In other cases, the matrices can be used to improve the accuracy of an image and make it look more real. Matrices can also be used to perform rotations of an image for printing an image in landscape mode as well as portrait mode. The following is one embodiment of the system calls and functions useful in matrix operations.

6.1) Global Matrix Settings

6.1.1) SetPageMatrix

6.1.2) SetTextMatrix

6.1.3) SetImageMatrix

6.2) Matrix Operations

6.2.1) Transform()

6.2.2) InverseMatrix()

6.2.3) ConcatMatirx()

6.2.4) RotateMatrix()

6.2.5) ScaleMatrix()

6.2.6) TranslateMatrix()

Device Handling

The Device Handling system calls provide a general interface for changing the operating characteristics of a peripheral device without knowing specific information about the device. In the past, a user or application could not modify the operation of a peripheral device without having special knowledge of the peripheral devices operation. Moreover, it was difficult to change the operation of a peripheral device between jobs. Accordingly, these APIs deal with configuring a peripheral device to operate in a specific manner and perform certain functions. The "Query" set of functions below allow the application running on the host computer to determine what the capabilities of the device are directly. This is then used to set the device accordingly. For example, the NUpQuery() system call can be used to determine how many pages the printer can print on single page. The result from this query helps the application provide the user with the appropriate type of options for printing.

The SendPage() and SendPageAddress() are particularly interesting system calls because they allow one peripheral device to distribute processing to one or more other peripheral devices. Essentially, the SendPage() system call instructs the peripheral device processing a request to send the output, typically a bit map, to another host as indicated by the SendPageAddress(). This can be useful in providing peripheral device output previews such as printer preview actually calculated on the target peripheral device. If the peripheral device is an expensive color printer, this can save resources because the color printer will only generate a bit map and send the results back to a host processor for review by a user rather than actually printing the image.

7.1) duplex

7.1.1) DuplexSelect()

7.1.2) DuplexQuery()

7.1.3) TumbleSelection()

7.2) page size

7.2.1) PageSelect()

7.2.2) PageQuery()

7.3) n-up

7.3.1) NUpSelect()

7.3.2) NUpQuery()

7.4) orientation

7.4.1) PageOrientation()

7.4.2) GlobalPageMatrix()

7.5) staple

7.5.1) StapleSelect

7.5.2) StapleQuery()

7.6) collateral

7.6.1) CollateralSelect p2 7.6.2) CollateralQuery

7.7) binding

7.7.1) BindingSelect

7.7.2) BindingQuery

7.8) page-wise operations

7.8.1) Pagelnvert()

7.8.2) PageRotate()

7.8.3) PageFlip()

7.8.4) PageTiling()

7.8.5) PageOutputFormat

7.8.6) PrintPage()

7.8.7) ErasePage()

7.8.8) SendPage()

7.8.9) SendPageAddress()

7.9) paper tray select

7.9.1) TraySelect

7.9.2) TrayQuery

7.9.3) TrayStatusQuery

7.10) copy number

7.10.1) SetCopyNumber()

Connection Handling

Connection handling allows for the application to determine which protocols a peripheral supports and the type of communication the peripheral device uses to function. For example, the ProtocolSupport() system call can be used to determine whether the peripheral device supports TCP/IP communications.

8.1) status query

8.1.1) ProtocolSupport()

8.1.2) IOSupport()

8.2) network management

8.2.1) NetworkSupport()

8.2.2) NameDirectoryServerAddress()

Administration

Peripheral devices provide some of the most difficult tasks in managing a computer network. Many times printers will fail to work because a device driver attempting to change the personality or attributes of a printer fails and causes the printer to jam. In other instances, the user can not use a printer because the requested printer is out of paper and no one is aware of it. Embodiments of the present invention provide a method for peripheral devices to communicate status information to users, system administrators, and peripheral device management routines which facilitate effective peripheral device administration.

The Firm Ware Update system calls include several interesting routines which enable a peripheral device to obtain the latest firmware updates. In one embodiment, these routines cause the peripheral device to download the latest firmware updates at a predetermined time interval over a URL location on the World Wide Web. Alternatively, the manufacturer can "push" the firmware updated onto the peripheral device over the Internet or over an intranet when the firmware is released. Either model improves peripheral device administration by making sure the peripheral devices have the latest firmware upgrades.

9.1) setup

9.1.1) DefaultServer()

9.1.2) GeographLocation()

9.1.3) SetupDate()

9.1.4) SysAdminAddress()

9.1.5) PrinterCapability()

9.1.6) PaperPrinted()

9.1.7) BootServerAddr()

9.1.3) SetupLog()

9.2) registration

9.2.1) Owner()

9.2.2) WhoAmI()/PrinterName()

9.2.3) MyIpAddress()

9.2.4) MyEtherAddress()

9.2.5) MyFileServerAddress()

9.2.6) MyWebURL()

9.2.7) RegisterationLog()

9.3) firmware update

9.3.1) FirewareVersion

9.3.2) LatestUpdateDate

9.3.3) FirmwareSourceURL()

9.3.4) UpdateNow()

9.3.5) UpdateOnDate()

9.3.6) UpdateLog()

9.4) supports

9.4.1) HardwareSupportAddr

9.4.2) SoftwareSupportAddr

9.4.3) ServiceSupportAddr

9.4.4) SupplySupportAddr

9.4.4.1) TonerSupplyAddr()

9.4.4.2) PaperSupplyAddr()

9.4.5) SupportLog()

9.5) security

9.5.1) SysAdminPassword

9.5.2) ServicePassword

9.5.3) LoginSessionLog()

9.5.4) Signature()

Job Handling

Job handling system calls include routines which allow the peripheral devices to manage their jobs and decide how the jobs should be processed. These routines off-load some of the processing associated with queueing jobs on the host machine and allows the host to process other more imminent tasks such as running an application. Instead, these routines enable each individual peripheral device to manage their own queue and request a new job when the peripheral device becomes available. Essentially, peripheral devices can operate autonomously instead of relying on a queue on the host device. In one embodiment, each peripheral device has a queue managed on the individual peripheral device and does not require the host computer to manage the processing of jobs. An alternative embodiment, uses the host computers to store jobs in a queue but allows the peripheral device to request jobs from the queue and otherwise manage the queueing process.

The Job Process system calls provided below are particularly interesting because they allow peripheral devices to redistribute jobs over multiple peripheral devices and host computers. Specifically, the JobSplitInParallel allows a requesting peripheral device to delegate processing of a job to multiple peripheral devices or host computers. Typically, the peripheral devices and host computers assist the requesting peripheral device process data as needed for the particular peripheral device to operate. For example, a printer peripheral device can print a large document much more quickly with the JobSplitInParallel system call which uses multiple printers and host devices to calculate the bit maps for the document and then have the resulting bit maps sent back. Further, the printer can also use a system call such as JobSplitInColor to send the color portion or portions of a print job to color printers while the black and white or non-color portion of the print job is printed on a black and white printer. This saves expensive color printer toner and supplies and increases the overall speed of printing a color and black and white document.

The JobPreProcess system call and JobPostProcess system call are also interesting routines because they allow the printer to determine if the particular job should be sent to a different peripheral device. For example, the JobPreProcess system call can be used to query other peripheral devices and send a job to another peripheral device before the peripheral device begins processing. Typically, the user or application will be given a predetermined time period to approve or disapprove of this transfer before it occurs. Similarly, the JobPostProcess system call operates similarly except that the job is sent after processing has begun on the peripheral device. This routine also allows a peripheral job to be re-routed to a different peripheral device and started over again.

10.1) Job Status

10.1.1) JobCreationTime()

10.1.2) JobStatus()

10.1.3) JobAssistantAddr()

10.1.3) JobOwnerAddress()

10.1.5) JobProcessTime()

10.1.6) JobBillingInfo()

10.1.7) JobAlert()

10.2) job information

10.2.4) JobFormat()

10.2.5) JobLocation()

10.2.6) JobLoad()

10.2.7) JobPreProcess()

10.2.8) JobPostProcess()

10.2.9) JobLog()

10.3) job process

10.3.1) JobProcessPartners()

10.3.2) JobForwardAddress()

10.3.3) JobSplitInParallel()

10.3.4) JobSplitlnColor()

10.3.5) JobReroutelnError()

Connectivity with other Digital Devices

These set of system calls are useful in integrating the output from one type of peripheral device with the input of another peripheral device and vice-versa.

11.1) Digital Camera

11.1.1) GetPicture()

11.1.2) SetCameraPictureFormat()

11.1.3) SendPicture()

11.1.4) SendAddress()

11.1.5) InitializeCamera()

11.1.6) SetupCamera

11.2) Scanner

11.2.1) ScanPicture()

11.2.2) SetScanPictureFormat()

11.2.3) SendPicture()

11.2.4) SendAddress()

11.2.5) InitializeScanner()

11.2.6) SetupScanner

11.3) FAX

11.3.1) GetFileFormat()

11.3.2) GetFile()

11.3.3) SendFile()

11.3.4) SendAddress()

11.3.5) InitializeFax()

11.3.6) SetupFax

B. Method for Distributed Processing on Host and peripheral Devices

Referring to FIG. 3., a flow chart diagram illustrates the general steps used by one embodiment of the present invention to distribute processing of an application between a host computer and one or more peripheral devices. This technique is advantageous because it suggests a peripheral device for use by a user or application based upon a predetermined set of characteristics. For example, a user or application can automatically locate a printer device based on print speed and print capacity rather than the name of the printer. Initially, this process assumes that each peripheral device coupled to the network executes a POST (power on self test) or equivalent application which upon boot up time inserts into peripheral database 110 (FIG. 1) information concerning the capabilities of the particular peripheral device. Typically, the POST application would be a JAVA application which queries the functions available on the peripheral device and reports capabilities and status to the peripheral database 110. Those skilled in the art will understand that peripheral database 110 can be centrally located as illustrated in FIG. 1 or can be distributed over many smaller databases located on the network or even within each of the peripheral devices. Accordingly, references to querying the peripheral database can be unicast (i.e. point-to-point) requests to a central peripheral database or can be broadcast or multicast (many-to-many) requests to each of the smaller databases located on the network.

The process typically begins when a user initiates execution of an application in which a portion of the application requests operation of a peripheral device. In accordance with principles of the present invention these instructions are usually virtual machine instructions generated using the JAVA programming language. At step 302 in FIG. 3, the application uses a predetermined selection criteria to query the peripheral database 110 (FIG. 1) and determine which peripheral device is best suited for performing the desired peripheral operation. Processing transfers from step 302 to step 304, where the method automatically selects a peripheral device for performing the requested job based upon the predetermined selection criteria. In one embodiment, step 304 will provide the user with a prioritized list of peripheral devices and prompt the user to decide which peripheral device should be used. If the user does not respond within a predetermined time period, the peripheral device will automatically operate on the highest priority peripheral device. For example, assume that three printers are coupled to the network and are capable of low-resolution color, high resolution black and white, and high-resolution color printing. An application or user selects a high-resolution color printer in an application running on a host computer. This causes the method to query the peripheral database, determine where the high-resolution color printer is located and then request the high-resolution color printer to perform the operation. However, if the color printer selected is unable to perform the operation, due to lack of resources such as toner or paper, the printer will then download a response application back to the requesting host machine requesting the user or application to select a different set of criteria for printing the job. In response, the user or application can then select the high-resolution black and white printer to print the job instead.

Next, once an appropriate peripheral device is selected, processing transfers from step 304 to step 306 where the portion of the application concerned with using the functions associated with the peripheral device is downloaded into the peripheral device. This application is then executed on the virtual machine instruction processor embedded in the peripheral device. Typically, the data will be transferred to the selected peripheral device along with a portion of the application consisting of virtual machine instructions. In an alternative embodiment, the application is already stored in the peripheral device and step 306 only downloads the data for the peripheral device to operate. In one embodiment, these virtual machine instructions can instruct the peripheral device to perform necessary conversions, image processing routines, font changes, or any other operations necessary for operating on the data before it is suitable for operation by the peripheral device. In one embodiment, the peripheral device is a "thin client" which includes only the minimum hardware and software necessary to execute JAVA applications. The downloading step discussed above then provides the code necessary for the peripheral device to operate. For example, assume a JAVA based printer initially only includes a JAVA virtual machine instruction processor and a JAVA/OS capable of executing JAVA applets or applications. Accordingly, to print, postscript step 306 would download a PostScript interpreter applet and data into the JAVA printer. Similarly, to print FAX information, step 306 downloads the appropriate CCITT group FAX routine and data into the JAVA printer. Essentially, step 306 enables the JAVA printer to operate on different types of data by dynamically reconfiguring the printer with different printing personalities as needed by the particular application.

Processing then continues from step 306 to step 308 where the peripheral device application executes on the peripheral device. Typically, the virtual machine instructions associated with the application are executed at step 308. After a predetermined time period passes, determination step 310 determines if the application executing on the peripheral device is complete. If the application executes to completion, processing transfers from step 310 to the end and the process is complete. However, if for some reason the peripheral device has not completed execution, these instructions can be delegated for execution on another host machine or other peripheral device.

Accordingly, processing transfers from step 310 to step 312 if the processing on the peripheral device is not complete. Initially, step 312 establishes a bidirectional communication between the selected peripheral device and the host computer for transmitting and receiving real-time information generated while the peripheral device is operating. In one embodiment, this is accomplished using object oriented features of the JAVA programming language which allow for socket based communication protocols over TCP/IP to take place between a host computer and a peripheral device coupled to a network. Unlike prior art solutions, the bi-directional communication link of the present invention allows enhanced administration and managing of peripheral devices with a reduced amount of overhead and down time. Many typical causes of a peripheral device failing to operate or going down, such as out of paper or toner low, could be anticipated, reported, and corrected before they cause a major impact on a group of users. Further, in one embodiment, the status information provided at step 312 is used to determine if processing should be distributed on several peripheral devices or host computers.

Essentially, the decision on whether to migrate the remainder of the application to another peripheral device occurs at determination step 314. In one embodiment, a peripheral device decides to use the processing power of another machine to perform certain functions in parallel and speed up the peripheral device processing. For example, a high-resolution color printer may need to perform some image enhancements on an image before printing the output. This color printer may delegate these calculation intensive routines to a host computer on the network while the color printer is laying out the format of the page. This type of flexible distributed processing is a powerful feature of the present invention.

In an alternative embodiment, the user can determine whether the peripheral device should migrate to another peripheral device or host computer. Typically, the application executing on the peripheral device prompts the user to make this determination. If the user decides not to migrate the application to one or more peripheral devices, processing continues on the same device and control passes from step 314 to step 308. This approach can take longer because only one processor is used for processing the output or input. Alternatively, the user may decide to migrate the peripheral application to one or more different devices. If this latter choice is made, processing would transfer from step 314 to step 302 where the above steps 302 through 312 would be repeated. This would potentially reduce the time it takes to perform the particular operation on the peripheral device. For example, a user can print a large job which includes color drawings by distributing the print job over a number of different printers. The black and white pages can be sent to one or more high speed black and white printers while the color print job is sent to a relatively slow color printer. This arrangement overlaps the color printing with the black and white printing and decreases the time to print the job. It also conserves resources by reserving the more expensive colors and pigments used on the color printer for color printing rather than printing black and white.

Referring to FIG. 4., a flow chart illustrates the general steps used by an alternative embodiment of the present invention to distribute processing of an application between a host computer and one or more peripheral devices. This technique is similar to the previous technique discussed above and illustrated in FIG. 3 except that the user or application requests a specific peripheral device which is located nearby or well known to the user. Like the previous technique discussed above, processing can be distributed on one or more peripheral devices or host computers.

Initially, the process illustrated in FIG. 4 assumes that each peripheral device coupled to the network executes a POST (power on self test) or equivalent application which upon boot up time inserts into peripheral database 110 (FIG. 1) information concerning the capabilities of the particular peripheral device. Typically, the POST application would be a JAVA application which queries the functions available on the peripheral device and reports capabilities and status to the peripheral database 110. This operates similar to the technique discussed above.

This process typically begins when a user initiates execution of an application in which a portion of the application requests operation of a peripheral device. In accordance with principles of the present invention these instructions are usually virtual machine instructions generated using the JAVA programming language. At step 402 in FIG. 4, the user selects a specific peripheral device by name to perform the given operation. Processing transfers from step 402 to step 404, where the method then selects and configures the peripheral device to perform the requested operation. In one embodiment, this step will attempt to configure the peripheral device at the best possible settings under the circumstances and notify the user or application accordingly. For example, if the user requests 3000 dpi from a 1200 dpi printer device, step 404 will set the requested peripheral device to 1200 dpi and notify the user that a lower setting is being used. If the user does not respond within a predetermined time period, the peripheral device will assume the user is happy with the modification.

Next, once an appropriate peripheral device is selected and configured, processing transfers from step 404 to step 406 where the portion of the application concerned with using the functions associated with the peripheral device is downloaded into the peripheral device. This application is then executed on the virtual machine instruction processor 108 (FIG. 1) embedded in the peripheral device. Typically, the data will be transferred to the selected peripheral device along with a portion of the application consisting of virtual machine instructions. In an alternative embodiment, the application required for operating the peripheral device is already downloaded into the peripheral device and step 406 need only download the data for the peripheral device to operate. Step 406 operates in a manner similar to step 306 in FIG. 3 discussed above.

Processing then continues from step 406 to step 408 where the peripheral device application executes on the peripheral device. Typically, the virtual machine instructions associated with the application are executed at step 408. After a predetermined time period, determination step 410 determines if the application executing on the peripheral device is complete. If the application executes to completion, processing transfers from step 410 to the end and the process is complete. However, if for some reason the peripheral device has not completed execution, these instructions can be transferred to another host machine or other peripheral device.

Accordingly, processing transfers from step 410 to step 412 if the processing on the peripheral device is not complete. Initially, step 412 establishes a bidirectional communication between the selected peripheral device and the host computer for transmitting and receiving real-time information generated while the peripheral device is operating. Step 412 operates in a manner similar to step 312 in FIG. 3 discussed above.

Essentially, the decision on whether to migrate the remainder of the application to another peripheral device occurs at determination step 414 in FIG. 4. Like step 314 in FIG. 3 discussed above, if the user or application decides not to migrate the processing to one or more peripheral devices, processing continues on the same device and control passes from step 414 to step 408. Alternatively, the user or application may decide to migrate the peripheral application to one or more different devices. If this latter choice is made, processing transfers from step 414 to step 416 where a predetermined selection criteria is used to query peripheral database 10 (FIG. 1) and determine which peripheral device is best suited for performing the desired peripheral operation. Processing then transfers from step 416 to step 402, where the method automatically selects a peripheral device for performing the requested job based upon the predetermined selection criteria. In one embodiment, this step will provide the user with a prioritized list of peripheral devices and prompt the user to decide which peripheral device should be used. If the user does not respond within a predetermined time period, the peripheral device will automatically operate using the highest priority peripheral device.

C. Exemplary Applications for Distributed Processing on Host and peripheral Devices

Using systems designed in accordance with the present invention, numerous applications previously unavailable in the art can be developed which simplify peripheral device operation and management. These peripheral device applications automatically adapt to most networks, hosts, or peripheral devices because, in part, each device is capable of executing the same set of virtual instructions. Large complex drivers used to convert data formats and drive hardware signals on a peripheral device are replaced with general purpose virtual machine instruction applications written in languages such as JAVA. Typically, these general purpose virtual machine instruction applications are self-contained and therefore can be executed on almost any peripheral device or host device on the network for processing. For example, a user who wants to print a particular graphic format file such as a JPEG file on a printer does not have to use a driver to convert the JPEG file into the format prescribed by the printer such as PostScript. Instead, the application used to print the particular graphic file will down load an application, or applet, into the printer for printing JPEG along with the data to be printed. The printer will then execute the JPEG applet and print the file on the printer.

Moreover, applications developed using embodiments of the present invention perform load distribution based on the requirements of each application. These applications are not limited to the processing power available on either a host computer or a peripheral device but can distribute the load between many host computers and peripheral devices. A portion of the processing suitable for the host computer, such as extensive floating point calculations, can be performed on the host computer while relatively straightforward conversion routines can be performed on one or more peripheral devices. For example, a user having a large print job can use a printing application to distribute portions of the print job to different printers in a printer pool without reconfiguring the printers or reloading special device drivers. Instead, the applications will query the peripheral device database to determine the number of printers available and then download a printing applet and the corresponding data into the various printers. Essentially, this dynamically distributes a print job for parallelized printing. For efficiency, the application can also detect which pages of a print job are color and send them to a slower, higher resolution color printer while sending the black and white portions of the file to higher speed, lower resolution black and white printers. These techniques have increased economic efficiencies and relieve the user from tedious configuration details.

Peripheral device management and diagnosis applications can also exploit the novel features provided in systems of the present invention. For example, self-administered peripheral devices can be developed which reduce the need for extensive service and monitoring by administrative personnel. At a predetermined time period, an application running on a host computer can download applications, or applets, into each peripheral device and gather very detailed information on the peripheral device operation. The peripheral device, such as a printer, can execute the applet and determine what areas of the peripheral device need repair or are close to being depleted. Next, the peripheral device can establish a bi-directional communication link to provide status on the peripheral device. If the peripheral device is a printer, this information may include information on the amount of paper available, amount of toner, time remaining before a service, or cleaning. Using this information, the application running on the host can determine which peripheral device should be used and which peripheral device should not be used. In another aspect, these applications are advantageous because a single vendor can develop one application which interoperates with all peripheral devices having a virtual machine instruction processor and adhering to teachings provided by the present invention.

Systems of the present invention also facilitate the development of applications which allow remote administration and use of printers over a network or other bidirectional communication mechanism. In one embodiment, a remote administration application includes a skelatal remote administration applet located on a host computer and a series of smaller control applets located on each peripheral device. Typically, the control applet is developed by the peripheral device manufacturer. The control applets located on each peripheral device are capable of controlling the peripheral device they are stored on and can be plugged into the skelatal remote administration application on demand when a particular peripheral device must be configured or checked. This modular approach to managing peripheral devices allows for access to the features of each peripheral device without requiring the loading of different proprietary software applications. In operation, the remote administration application downloads virtual machine instruction applet over a network connection into the peripheral device which requests the peripheral device's control applet. Upon execution in the peripheral device, the downloaded virtual machine instruction applet then instructs the peripheral device to locate and return the control applet within the peripheral device which understands the operation of the device. The control applet is then plugged into the skeletal remote administration application and enables a person to manage the particular peripheral device. In one embodiment, the remote administration application is a JAVA enabled brouser running the JAVA virtual machine and the applets downloaded from the peripheral device are written in JAVA virtual machine instruction bytecodes. Essentially, almost any peripheral device can be managed from almost any location on a network because the control applet is retrieved from the peripheral device on demand. Further, the skeletal remote administration application can be used on almost any host computer because the host computer and peripheral devices run compatible virtual machine instructions.

Applications developed using systems of the present invention also facilitate peripheral devices which are self-configuring and capable of performing automatic upgrading/updating. In this application, a peripheral device registers a peripheral profile with a peripheral database when the device is attached to the network and performs a power on self-test (POST). After POST, an applet stored in non-volatile memory (NVRAM) or other storage medium of the peripheral device requests a configuration applet from the peripheral database. In response, the peripheral database downloads an applet of virtual machine instructions which automatically configures the peripheral device to work in a predetermined manner. For example, an applet could be downloaded into a printer peripheral device which causes the printer device to use a TimesRoman font, print landscape, and use papers initially from tray 1. This self-configuring option would speed up initial printer configuration significantly and allow for printer devices to be relocated on a network with minimal impact on the user community.

Further, in another embodiment of the present invention a peripheral device checks a host computer over the Internet or an intranet at a predetermined time interval, for example once a month, for updates and software upgrades. If an upgrade exists, the peripheral device automatically downloads the upgrade and begins executing it. Alternatively, the peripheral device downloads a notification applet to the appropriate personnel on the host computer requesting that the upgrade or update be made. Upgrading or updating the peripheral device in this instance is user initiated and not automatic. For example, assume the manufacturer of a digital camera having a virtual machine processor discovers a better method for dithering and interpolating pixels in the digital camera which improves the visual acuity and resolution of the camera output by 10%-50%. On the first of each month, the digital camera contacts the manufacturer's web site on the Internet and checks for upgrades. When the digital camera discovers the upgrade, the camera establishes a bi-directional communication with an application on the web site verifying serial numbers and warranty information thus authorizing the upgrade. Next, the camera receives the upgrade in the form of an application having virtual machine instructions and begins executing the instructions immediately. Further, if the method is in the public domain, almost any digital camera having a virtual machine instruction processor could engage in a similar process and download the upgrade and therefore take advantage of the new discovery as well. This technique is a significant improvement over current techniques in which the user must manually load upgrades or must obtain and install a new PROM into the peripheral device.

In yet another embodiment, peripheral devices are coupled together directly to process information and do not require intervention by a host computer or similar central processing device. For example, a printer device having a virtual machine instruction processor is coupled directly to a digital camera without using a host computer. This allows the camera to take pictures and print them directly on the printer. Specifically, the camera captures the image data in digital form and then downloads the virtual machine instruction application for printing the particular data format, such as PostScript, along with the actual image data into the printer. The printer would then execute the virtual machine instruction application and use the data to print the information out.

While specific embodiments have been described herein for purposes of illustration, various modifications may be made without departing from the spirit and scope of the invention. Those skilled in the art understand that the present invention can be implemented using a variety of different networking protocols and is not limited to computer systems coupled to a network using the TCPIP protocol. Alternative embodiments substantially similar to the embodiments discussed above could be implemented except that the network protocol would be SNA, Appletalk, IPX, X.25, SLIP, or PPP. Those skilled in the art understand that computer systems running TCP/IP can also communicate with other computer systems running other diverse network protocols such as SNA (Systems Network Architecture), IPX, Appletalk, or X.25. Furthermore, another alternative embodiment substantially similar to the embodiment discussed above could be implemented except that the virtual machine processor is simulated using a processor executing a proprietary instruction set such as the x86 architectures by Intel, Inc. of Sunnyvale, or the PowerPC architecture by Motorola of Schaumburg Illinois. Yet another alternative embodiment substantially similar to the embodiments discussed above could be implemented except that they operate in an environment using virtual machine instructions other than the JAVA language and environment. Accordingly, the invention is not limited to the above described embodiments, but instead is defined by the appended claims in light of their full scope of equivalents. ##SPC1##