Network printing system

The present invention generally relates to a printer interface for use in a network print context and a print server particularly suitable for HTTP-based network printing.

[0002] By using a print server based on HTTP, a plurality of Internet clients can perform Internet communication with one or a plurality of document processing devices. The print server architecture enables internet communication regardless of whether one or more document processing devices have an embedded HTTP server.

[0003] US Pat. No. 5,220,674 discloses a local area print server that works in concert with a plurality of clients and printers to facilitate communication between the client and the printer. The server includes various subsystems, such as state collection subsystems, which maintain a wide range of state information that is virtually relevant to all subsystems with which the server communicates. The state collection subsystem has a notification function that sends reports of changes in the printing system state or events to the appropriate network components inside and outside the local print server that are interested in knowing them.

[0004] In the increasingly popular World Wide Web (WWW), the Hypertext Markup Language (html) specifies the display of information on a "client" computer, and the Hypertext Transfer Protocol (http) A neutral method is provided for the transfer of information from a "server" computer to a "client" computer using the TCP / IP network protocol. Its neutral scheme is of particular importance, in which the transfer and display of information does not depend on the client computer operating system or processor configuration, but only on the capabilities of the "browser" that follows the protocol. Such software is now widely available for most computers. The information transferred and displayed to the client includes both pre-defined static information and dynamic information calculated at the time the client requests the server. Publicly available server software often includes a common gateway interface (CGI), which allows the server to call software programs that allow user-specific parameters to be passed. The output of this software program will be transferred to the client computer and displayed there.

[0005] The print and document processor can use html and http as interfaces for control and state. These machines benefit greatly from such use for several reasons. That is, first, the development cost is relatively low and the development period is relatively short. The reason is that the mechanism can be used by a large number of clients and is often referred to as the client display software (often referred to as the "user interface" or UI) for each operating system and processor used by that client. ) Is not required to be written. Second, it is easy to form a multilingual interface by storing information in multiple languages on the server, which allows the server to be accessed simultaneously in multiple languages by different clients. It will be possible. Third, improve or change the functionality of the print or document processor without the inconvenience of the vendor developing new client display software and the inconvenience of the client installing the new software on any client computer for each of these improvements. , Can be executed.

[0006] [Problems to be Solved by the Invention] In a network printing system as disclosed in US Pat. No. 5,220,674, a considerable number of operation requests (for example, inquiries) are made one or more with a predetermined client. To determine the information selected for a given print subsystem, such as the machine settings for a given print subsystem or the state of that print subsystem, that passes between the print subsystems. Most preferably, these queries are processed by the HTTP context. The reason is that such a context is neutral throughout the changing specification document processing platform. However, this advantage of the neutral state is considered to be underutilized in the prior art. For example, Hewlett-Packard "HP" is believed to provide a configuration in which multiple clients communicate with multiple document processors through a server. However, in order to use a server with this device, the device needs to have a specific card owned by HP. Some document processors include embedded HTTP servers, others do not include embedded HTTP servers, but a proxy server that has the ability to host Internet operations between these document processors is provided. Is desirable.

Moreover, in a typical proxy server, the application layer communicates with a connectivity layer that can forward operation requests between the client and the document processor. Some client / server based software facilitates a connectivity layer called middleware that penetrates the interface. During operation, the middleware contains multiple modules, each module facilitating the transfer of operation requests between the client and one or more target devices. For example, one module is a Microsoft (Misrosoft) -based client and document center (Documet Center is Xerox. Facilitates the transfer of inquiries to and from printers under Coep.). In one prior art schema, operational requests are received from the client via the application layer, and a set of parameters corresponding to the request is generated by the application layer. In one example, the request can be verified by searching for values related to the selected machine settings of the target document processor. Therefore, the required settings are sent to the connectivity layer, which in turn gets the values specified by the application layer.

This method of setting parameters using the application layer raises issues with the author of the application code, which is that the author is not the most familiar with the current parameters associated with the corresponding goal. There are cases. On the other hand, these write codes for the connectivity layer are usually very closely related to the parameters associated with the target document processor. Therefore, it is desirable to provide a system in which the responsibility for retrieving values associated with a given document processor is transferred from the application layer to the connectivity layer, i.e. the middleware layer.

[Means for Solving the Problems] According to the present invention, a printing system in which one or more clients communicate with a plurality of printers via a print server having an architecture characterized by a plurality of layers. Is provided. In practice, one of multiple layers receives a request from one of multiple clients, and the request specifies an operation that needs to be performed on one of multiple printers. The printing system comprises an application layer, which communicates with one of the multiple layers and generates commands (imperative expressions) based on the requests received by one of the multiple layers. The communication interface includes a first connectivity module and a second connectivity module, the first connectivity module communicates with the first printer among the plurality of printers, and the second connectivity module communicates with the second printer among the plurality of printers. In addition, the routing interface communicates with both the application layer and the communication interface, directs an imperative expression regarding a selected one of the first connectivity module and the second connectivity module, and is included in the first and second connectivity modules. The one selected in uses an imperative to perform at least some of the operations specified for one of multiple printers.

[0010] FIG. 1 is a diagram showing a digital copier in a format suitable for use in a preferred embodiment. As shown in the figure, the system includes a document feeder 1 and an operation (or display) panel 2. When the desired conditions are input to the operation panel 2, the document feeder 1 conveys the document to a predetermined reading position on the image reading device 3, and after the reading of the document is completed, the document is taken out from the reading position. The image reading device 3 illuminates the document brought into the reading position. The resulting reflections from the document are converted into a corresponding electrical signal, or image signal, by a solid-state image sensor, such as a CCD (charge-coupled device) image sensor. The image forming apparatus 4 forms an image represented by an image signal on plain paper or thermal paper by electronic copying, heat sensitivity, thermal transfer, inkjet, or a similar conventional system.

[0011] When the paper is supplied from the paper cassette 7 to the image forming unit 4, the forming unit 4 forms an image on one side of the paper. The double-sided copying unit 5 is assembled so that the paper on which the image is printed on one side is inverted and supplied to the image forming unit 4 again. As a result, an image is formed on the opposite side of the paper, and double-sided copying is completed. The double-sided copying section 5 is usually designed to immediately resupply the paper, or to continuously resupply the sequentially deposited paper from the bottom paper to the top paper. The paper discharged from the image forming unit 4 or the double-sided copying paper is classified by the output device 6 according to the page order or page by page.

[0012] Normally, the application 8 shares a document feeder 1, an operation panel 2, an image reading device 3, an image forming unit 4, a double-sided copying unit 5, an output device 6, and a paper cassette 7, which are incorporated into a copying machine system. It is a resource that can be used. Applications include copier applications, printer (IOT) applications, facsimile (Fax) applications, and other applications, as described below. Further, the digital copier system is connected to the network by a conventional network connection 9.

[0013] FIG. 2 is a diagram showing a multifunctional, network adaptive printing system represented by reference numeral 10. The printing system 10 includes a printing machine 12 that operates by being connected to a network service module 14. The printing press 12 includes an electronic subsystem 16, which is called a video control module (VCM) and is connected to the scanner 18 and the printer 20. In one example, the VCM16 regulates the behavior of scanners and printers with a digital copy structure, an example of which is disclosed in US Pat. No. 5,579,447 by Salgado. In a digital copy structure, a scanner 18 (also called an image input terminal (IIT)) uses a CCD full-width array to read an image of the original document and convert the collected analog video signal into a digital signal. The image processing system associated with the scanner 18 (not shown) then performs signal correction, etc., converts the corrected signal into a multi-level signal (eg, a binary signal), and compresses the multi-level signal. However, preferably, the same thing is stored in electronic pre-verification (not shown).

[0014] Referring to FIG. 2, the printer 20 (also referred to as an image output terminal (IOT)) preferably comprises an electrostatic photographic print engine. In one example, the print engine has a multi-pitch belt (not shown), which is an imaging such as a synchronous source (eg, a laser raster output scanner) or an asynchronous source (eg, an LED print bar). Written by the source. In the print context, multi-level image data is read from the EPC memory and at the same time the imaging source is started and stopped according to the image data to form a latent image on the photoreceiver. The latent image is then developed, for example, using a hybrid jump development method and transferred to a print medium sheet. When the resulting print is fixed, it is converted into a double-sided or single-sided output. It will be appreciated by those skilled in the art that printers of formats other than electrostatic photographic printing engines can be assumed without changing the underlying concepts of the embodiments of the present invention. For example, the printing system 10 can be embodied using a thermal inkjet or ionographic printer.

[0015] The network service module 14 will be described in more detail with reference to FIG. As will be appreciated by those skilled in the art, the architecture of network service modules is similar to that of known "PC clones". In particular, in one example, controller 44 is from Sun Microsystems. It is a SPARC processor format manufactured by Microsystems, Inc.) and is connected to the standard S bus 72. In the embodiment shown in FIG. 3, a host memory 74, preferably in the form of DRAM, and an SCIS disk drive 76 are connected to and operated on the S bus 72. Although not shown in Figure 3, the storage or I / O device is connected to the S bus by a suitable interface chip. Further, as shown in FIG. 3, the S bus is connected to the network 78 by the appropriate network interface 80. In one example, the network interface includes all hardware and software required to associate the hardware / software components of controller 44 with the hardware / software components of network 78. For example, in order to interface various protocols between the network service module 14 and the network 78, the network interface includes Netware (registered trademark) manufactured by Novell Corp., among other software. be able to.

[0016] In one example, network 78 includes a client such as workstation 82 with an emitter or driver 84. At the time of operation, the user can generate a job containing a plurality of electronic pages and a set of processing instructions. The job is then transformed by the emitter into a representation written in a page description language such as PostScript. The job is then transferred to controller 44, where the job is interpreted by the decomposer provided by Adobe Corporation.

[0017] FIG. 4 is a block diagram showing the network controller schematically shown in FIG. 3 in more detail. In the embodiment shown in FIG. 4, the client 100 (each client as shown as workstation 82 and emitter 84 in FIG. 3) is LPD (protocol for UNIX), Novell network protocol, AppleTalk and DCS (Document Centre). It is composed of various protocols (protocols for Xerox digital copiers known as "System"). Therefore, each client preferably has a "browsing" function and accesses the WWW by the browsing function. Therefore, it is possible to communicate with, for example, an HTTP server at various locations. In one example, a given client uses a browser obtained from either Netscape (2.01 or higher) or Microsoft (eg, nashville (a registered trademark of Microsoft)). The client communicates with the network server or electronic subsystem (ESS) 14 via the Connectivity Service (CS) 102. As shown in Figure 4, the electronic subsystem is specific to two parts: the microkernel 104 (particularly the microkernel partial abstract model that maps to a model based on DPA ISO 10175 / POSIX IEEE 1003.7) and the application. The subsystem 106 is provided.

[0018] Normally, a network, i.e., a print submission connecting two points, begins at the protocol service level of the (CS) subsystem. Each protocol service watches a connection indicator with a known socket. When the protocol service receives the connection indicator, the protocol service submits the job request to the connectivity core. The connectivity core translates this request into a DPA compatible format and forwards it to DM subsystem 108. Once the job subsystem is authorized, the protocol service can submit one or more documents. Document submissions are accomplished by sending document requests and I / O descriptors to the connectivity core. Document submissions are also converted and transferred to the DM subsystem.

After the document is received, the protocol service receives the data from the underlying protocol stack and begins writing the data to the I / O descriptor. This data is read by the consumer on the other side of the I / O descriptor or spooled somewhere in the system. When the remote client indicates that there is no more data, the I / O descriptor is closed and signaled to end this particular document. After all the documents have been received, a job termination request is sent from the protocol service to the connectivity core, which forwards this request to the DM. Finally, this request is completed by the system and the protocol service frees resources associated with all jobs.

[0020] Typically, the query is directed from the client (FIG. 4) to the printing press 12, and in one embodiment, it is processed by using an HTTP server 107 that operates with the DM subsystem 108. In a preferred embodiment, the structure and functionality of the HTTP server is on proxy server 107A (FIG. 5), the details of which proxy server will be described below. Although the embodiments shown in FIGS. 4 and 5 include an HTTP server, those skilled in the art should understand that embodiments using other server formats are conceivable. That is, either server 107 or 107A does not change the intended purpose of the preferred embodiment in the network between the client and the document processor (as technically the term "browsing" is conceivable). It can be any type of server that facilitates browsing.

[0021] The microkernel has a document management (DM) subsystem that performs most of the DPA / POSIX server functions. The DM subsystem checks the validity of user requests, queues requests, spools document data, schedules jobs for devices, and collects and preserves state information. The DM subsystem extends the DPA / POSIX server in some aspects because the DM subsystem can be configured to handle scanning jobs (for filling or faxing) and copying jobs. The DM prepares for document sniffing, spooling, and scheduling services. Service providers such as Document Processing 110 can record their services for DM.

Document processing (DP) includes image frame storage (IFS) and examples of at least one producer and comprises a microkernel. The DP processes the document into an image (full framebuffer or raster scan bandwidth, depending on the microkernel configuration). Image frame storage assigns producers to consumers.

In essence, the microkernel 104 can be thought of as a common electronic subsystem, while subsystem 106 can be thought of as an application-specific electronic subsystem. That is, the microkernel 104 contains the basic building blocks of the print server, while subsystem 106 is required with the microkernel 104 to provide the video control module 16 with the desired level of maneuverability. Includes all software components. In particular, the agent that completely filters all commands / requests coming out of the microkernel 104 is indicated by reference numeral 114. Essentially, the agent acts as a "key" to the common electronic subsystem, facilitating the handling of all remote resources. The agent works with other services such as print service 116 and diagnostics 118 to assist in the operation of the video control module.

[0024] Agent 114 communicates with the electronic subsystem queue utility 120 and, in particular, preserves the composite queue. The functions of agents and electronic subsystem queue utilities can be combined, but are shown separately in the modularized model herein. The electronic subsystem queue utility is also contacted for scan-to-file processing 122, which facilitates filing of previously scanned documents about the network and billing / authorization / authentication service (AAA) 124. become. Billing / authorization / authentication services are allowed to perform certain actions, especially those that are required to be performed by remote clients. In one example, the billing / authorization / authentication service is Xerox's DocuSP. 1.0 Embodied by software in a format recognized by print servers. Obviously, the billing / authorization / authentication service facilitates a preferred embodiment that prevents unwanted interference by unauthorized system users with respect to one or more queued jobs. Moreover, apparently, the electronic subsystem queue utility 120 can be used to obtain a host of information other than queue information. For example, utility 120 can be used to obtain machine configuration information (such as machine settings) and state information related to subsystems / processes other than queues.

[0025] Describe the aspect of the printing press 12 shown in FIG. 4, the copying service 128 is contacted by the electronic subsystem queue utility 120 and the video control module queue utility 130. The copy service, in one example, is located on controller 44 (FIG. 3) and performs functions comparable to document management 108 on the copier side. In particular, the copy service monitors the development and fax jobs of the copy and the management of the video control module. The video control module queue utility 130 communicates with the mark service 132 and the appropriate user interface 134 and collects the queue-related data obtained from them. The functions of the user interface and the video control module queue utility can be combined, but these functions are shown separately in Figure 4 as a modular model.

[0026] For example, in the case of Xerox's Document Center 35 digital copier, the mark service is associated with the printer 20 (FIGS. 2 and 3) and the video control module queue is associated with the user interface. As those skilled in the art will understand, both mark services and user interfaces are important components in developing and video control module queue maintenance. For example, the status of the video control queue is constantly changing as a result of mark service activity, but a significant amount of control is manifested on the video control module queue as a function of communication with the user interface.

[0027] Further, with reference to FIG. 4, the HTTP server 107 further includes a common gateway interface (CGI) represented by reference numeral 140. As mentioned above, the common gateway interface 140 can, with the use of appropriate software, send output to the client 100 corresponding to the parameters provided by the user. In particular, in practice, the client user generates a query (including a set of parameters), which requests output from a remote network system such as printing system 12. In one example, the request may be made for information about the order of jobs in the queue or the current settings of the printing system. As will be appreciated by those skilled in the art, inquiries are directed to a wide range of information related to printing systems, and remote network systems that receive inquiries include systems other than printing systems, for example remote network systems are independent. It may be equipped with a type scanning device.

[0028] Regarding FIG. 5, the proxy server enables the client 100 to connect to and communicate with the document processing devices 200-1 (for example, the printing system 12), 200-2, ... 200-N, and the proxy server. Includes the following important components:

That is, it includes an HTTP server 201, an application layer 202, a device (device) data cache and a device / user database 204, a routing interface 206, and a communication interface 208.

[0030] In an exemplary embodiment, the HTTP server 201 includes a Microsoft Internet information server (internet informationServer (IIS) is a registered trademark used by Microsoft in connection with web services. Application Layer 202 is Microsoft's Internet Server Applications (Internet Server Applications (ISAs) is a registered trademark used by Microsoft in connection with web services), and filters (eg,). , Print handlers, requests for information handlers, and data update handlers). The Internet server application is a dynamic link library (DLL), and the DLL becomes a load on the address space of the Internet information server in response to a client request. The actions taken on demand occur in the Internet server application.

[0031] In an exemplary embodiment, the device data cache and device / user database 204 (hereinafter referred to as the "database" for simplicity) are all relevant relevance servers obtained from the device (device) 200 by the proxy server. Memorize information. The stored information is, in particular, a list of devices 200, the current job queue for each device, the current job state for each device, the current site that can be set for each device, and the driver for each device (single or). Includes (s) and criteria for the appropriate strings and bitmaps that need to be displayed on the client for each device.

The routing interface 206 preferably comprises an application programmable interface, which, in one example, includes three subsystems, namely a data supply application, a data acquisition application, and a device installation tool. Preferably, the data supply application (1) modifies the site configurable values on a particular device and (2) issues job management commands to the particular device. Further, the data acquisition daemon initializes the communication interface 208 and collects, for example, device, job status, and site configurable information from the communication interface 208 for each registered device. The daemon then transfers and stores such information in the database. Finally, the device installation tool corresponds to adding or removing devices in response to client requests, as described in detail below.

A communication interface is a set of software programs primarily intended to provide connectivity between a client and a device. In other words, the primary purpose of the communication interface is to provide communication between the document processor and the database of the proxy server. In fact, the communication interface acts as a liaison between the data acquisition daemon and the support device of the customer's network. The communication interface remembers how to collect and report various device states, job states, and site configurable data by means of C ++ objects and their member functions. In one example, the communication interface comprises a software module and controls communication between the database and the device. Thus, a given module can be adapted to perform the function of a single device or the entire family of devices.

As can be seen from the figure, the underlying concepts of the system disclosed in FIG. 4 can be used to embody the communication interface shown in FIG. 5, provided by Xerox. This is another mode interface that exists in the document center system 35 (Document Centre System is a registered trademark of Xerox Co., Ltd.). The following is an overview of the communication interface, including middleware layer components, network abstraction layer components, infrastructure layer components, and other protocols.

【0035】<u style="single">Middleware layer component</u>This layer embodies the basic abstract of a physical network and provides an object representation of all supporting network entities, including network neighbors, queues, file servers, and at least one of printers and multifunction devices. In addition, this layer translates abstracts into a number of different network operating systems, including Novell, SNMP, and RPC.

【0036】<u style="single">Network abstract layer object</u>This service provides an interface to network abstract libraries and is embodied as a set of C ++ objects.

【0037】<u style="single">Infrastructure layer component</u>This layer provides low-level network connectivity for one or more families of document processing platforms.

【0038】<u style="single">Other protocol support</u>The protocols used to facilitate the usability of the components described above are TCP / IP, Netware (Netware is a registered trademark used by Novell, Inc. in connection with network operating systems. Includes), and LAN Manager.

The possible data flow scenarios selected for the system shown in FIG. 5 are shown below (the numbers in parentheses indicate their position in FIG. 5).

[0040] Normally, the database acts as a cache for all relevant device information.

[0041] -The client receives information from the database through the database.

The database is transferred and stored via the communication interface by the data supply and acquisition daemon and by the device installation tool.

【0043】<u style="single">Client request for information from the server</u>Regarding device status, job status, and currently site configurable values: -In each case, the client requests a URL (web page) for a particular device of a particular type (1).

-The HTTP server calls the appropriate function of the application layer (2).

The function requests a home page (for a device type) and related data (for a particular device) from a database (3), and the function returns that data (10).

The application layer searches for the appropriate web page, plugs it into the data, and returns the page to the client (11, 12).

The ISA searches for the appropriate web page, inserts it into the data, and returns the page to the client (11, 12).

【0048】<u style="single">Client upload of information to proxy server</u><u style="single">(Device / Job management directive)</u>Regarding the site configurable values and job management commands that change: -In each case, the client sends the data and its purpose to the HTTP server (1).

-The HTTP server calls the appropriate function of the application layer (2).

The application layer function modifies the appropriate call (s) in the database (3).

An attempt to change a value in the database triggers a data supply function call (4), and the data supply function call changes the value via the communication interface on the appropriate device (5, 6). ).

When the data is updated on the appropriate device, the database completes the modification of the data.

【0053】<u style="single">Proxy request for information from the device</u>Regarding device state changes, job state changes, and currently site configurable values, device additions and deletions: -The data acquisition daemon registers a device with a communication interface (13) (a new device appears as a system administrator and a proxy server. Add a print queue to).

The middleware then begins to acquire the current device state / job for the device (7) and return it to the data acquisition daemon (8).

-The data acquisition daemon stores the updated data in the database (9).

[0056] -When the data in the database is about to change, the database calls a function of the application layer, updates the data by the function, and sends it to an appropriate client.

【0057】<u style="single">Device installation</u>The user defines a new device by specifying an arbitrary name, device IP address, and device type. The LPR port and queue associated with the device are automatically prepared on the HTTP server.

The new device is then listed in the database for display on the client (16).

-Also, the new device is registered by the communication interface to access the database (15).

[0060] With reference to FIGS. 6 (A) and 6 (B), advantageous embodiments of preferred embodiments will be described. In the relatively unfavorable embodiment shown in (A), the application layer must generate a detailed request, eg, a request for obtaining a device related to information. That is, in these states where the client wants information about one machine setting of device 200 (FIG. 5), the application relates to the machine value setting that the client seeks in the embodiment shown in FIG. 6 (A). A communication interface 208 with a detailed list is provided. The detailed list is then sent to the appropriate module (CIS) in the communication interface, which sends the list queue or command to the corresponding device for which the client request value is provided. For modules, each device in the disclosed system is represented as an instance of a C ++ class, where each class represents the type of device. That is, one class corresponds to one type of device (eg, printing system), another class corresponds to another type of device (eg, stand-alone imaging device), and so on. As can be understood from the above, this relatively unsuitable technique is a single write code because the application layer has relatively important knowledge of the various machine settings associated with the particular device for which information is retrieved. Needs.

[0061] In contrast, in the preferred technique shown in FIG. 6 (B), the application receives a request from the client and translates the request into a function call with arguments. In practice, as is clear from the discussion below, by calling information, the routing interface 206 communicates to the communication interface what information the client wants in a simple way. In particular, most functions and their arguments are available to the appropriate module of the communication interface, which module has which value needs to be provided to a particular device, or which behavior is a particular device. Determine if it needs to be taken with respect to. As you can see, this greatly reduces the amount of commands that the application layer needs to provide.

By using the underlying structures / functions of the communication layer, the interface to each device is the underlying structure / function that the device needs to access, regardless of the type of device. Regardless, it looks the same for the application layer.

[0063] The list of function calls used by the proxy server is illustrated below.<img file="JP4119002B2_D0001.tif" />FIG. 7 is a diagram illustrating an overview of how the above-mentioned call or command is used. First, in step 214, the request is executed from client 100 (FIG. 5) to proxy server 107A, and the request is read at application layer 202. Following the execution of the function call, the application layer examines database 204 (step 216) to determine what information exists about the device and when to transfer and store that information to the database. Preferably, the information in the database is "labeled data", so in certain environments, client requests for information address such requests without calling communication interface 208. Can be done. For example, in one possible situation, relatively recent machine configuration information is provided from the database to the client by a direct response to such a request without calling a communication interface. For the sake of clarity, it is assumed in the following that any information or operation regarding the device 200 is performed by calling a communication interface having a routing interface 206 that responds directly to the client's request.

[0064] In step 218, the request makes a decision as to whether to seek device installation, i.e. device addition. Assuming that additions are required, in step 220 an inspection is performed to determine if the equipment that needs to be added is already listed in the database. If the device is listed in the database, i.e. if the device is already installed, then in step 222 an error message is issued (ie, the error message is replied to the client seeking the installation). ). If not installed, in step 224 an additional function call is entered by the name of the device that needs to be added. The routing interface 206 (preferably API) then adds a new device by means of the communication interface 208 according to the procedure described below (step 226).

[0065] If no request is made to add a new device, in step 230 a decision is made as to whether the device needs to be removed. Assuming that the device needs to be removed or removed, in step 232 a decision is made as to whether the device is listed in database 204. If there is no device in the database that needs to be removed, then in step 234 an error message is issued (ie, the error message is replied to the client seeking the installation). If present in the database, in step 236 the removal function call is entered by the name of the device that needs to be removed. The routing interface or API 206 then removes the designated device by communication interface 208 according to the procedure described below (step 238).

Assuming no installation is required, in step 242 a decision is made to determine if an acquisition operation is required. To provide the acquisition operation, the acquisition function is provided by the appropriate application layer (step 244) and its corresponding arguments are written according to the procedure described below. Next, according to the method of step 246, API 206 embodies the acquisition operation required by the communication interface. On the other hand, when a configuration operation is required (see step 248), a configuration function is then provided by the application layer (step 250) and its corresponding arguments are written according to the techniques described below. API 206 then embodies the configuration operation required by the communication interface according to the method of step 252. In any case, the state of operation initiated by the embodiment shown in FIG. 7 is returned to the client requesting the action via the "state" block.

[0067] The following commands / calls are embodied by selected components of server 107A, which components are hereinafter referred to as "interfaces".

【0068】<u style="single">Job management command</u>Allows the user to issue commands for jobs recognized by the interface in the window NT queue, or on the destination device's hard disk, if any. For the calling program, there is no difference depending on whether the job is on the server queue or on the device. The call is the same.

【0069】<u style="single">Status command</u>Allows the user to obtain current information about a particular device or jobs scheduled for a particular device.

【0070】<u style="single">Configuration command</u>Is in the non-volatile memory of the device and is currently used to acquire and set various values that define the configuration of the device.

【0071】<u style="single">Disclosure of installation commands</u>A number of aspects of the disclosed embodiments will be understood by those skilled in the art.

First, a proxy server that optimizes code generation is provided. In particular, by arranging the application programming interface (API) downstream of the application layer and upstream of the communication interface, the burden of generating code at the application layer is minimized without increasing the burden of generating code at the communication layer. Is made. In essence, by using APIs wisely, code generation is intelligently distributed between the application layer and the communication interface.

[0073] As a result of the use of the API, the request or "call" from the application layer to the communication layer becomes very simple. Preferably, in order to obtain information from a given device or perform operations on a given device, the application layer only needs to provide an API containing function calls with appropriate arguments. The API then sends a function call to the subsystem of the communication interface for proper processing.

Second, the proxy server can be used with all categories of document processing devices in the Internet context, and no document processing device needs to be specifically adapted for Internet use. Therefore, all devices can be used with a particular adapter card, even though they have at least one of the HTTP servers. Therefore, proxy servers can easily source equipment from different manufacturers with completely different designs.

Finally, the proxy server uses the database in a way that minimizes the time required to obtain device-related information requested by one or more clients. In particular, time-characterized information is periodically stored in the database by APIs and communication interfaces. If the information is requested by the client and the information is current enough when the application accesses the database, the information is provided to the requesting client without having to call an API or communication interface.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a perspective view showing a digital copier connected to a network that meets the corresponding information requirements.

FIG. 2 is a block diagram showing a multifunction network adaptive printing machine.

FIG. 3 is a block diagram showing a network controller for the printing press shown in FIG.

FIG. 4 is a block diagram showing a network controller shown in FIG. 3 in more detail.

FIG. 5 is a block diagram showing a state in which a plurality of clients are connected by an HTTP proxy server so as to be able to communicate with a plurality of document processing devices (for example, a printer).

FIG. 6A is a block diagram showing an unfavorable relationship between the routing interface and the communication interface shown in FIG. 5, and FIG. 6B is a block diagram showing a preferable relationship between the routing interface and the communication interface shown in FIG. It is a block diagram which shows.

FIG. 7 is a flow chart showing a method of executing an operation related to one or more document processing devices by using various function calls.

[Code description] 1 Document feeder, 2 Operation (or display) panel, 3 Image reader, 4 Image forming unit, 5 Image copying unit, 6 Output device, 7 Paper cassette, 8 Applications, 9 Network connection, 12 Printer , 14 Network Services Module (Electronic Subsystem), 16 Video Control Module (Electronic Subsystem), 18 Scanner, 20 Printer, 44 Controller, 72 Standard S Bus, 74 Host Memory, 76 SCI Disk Drive, 78 Network, 80 Network Interfaces, 82 workstations, 84 emitters or drivers, 100 clients, 102 connectivity services, 104 microkernels, 106 application-specific subsystems, 107 HTTP servers, 107A proxy servers, 108 document management subsystems, 110 document processing, 114 agents, 116 Print Service, 118 Diagnostics, 120 Electronic Subsystem Query Utility, 122 Scan to Filter Processing, 124 Billing / Authorization / Authentication Service, 128 Copy Service, 130 Video Control Module Queue Utility, 132 Mark Service, 134 User Interface, 140 Common Gateway Interface, 200-1, -2, -N Document Processor, 201 HTTP Server, 202 Application layer, 204 device data cache and device / user interface (database), 206 routing interface, 208 communication interface.