JP2005523489A - Output management system and method enabling access to private network resources - Google Patents

Abstract

A system and method for managing output such as printing, faxing, and e-mail on various types of computer networks In one aspect, the system and method allows access to print and / or document resources located on a private network behind the firewall (61, 62, 63, 64). Establish a pass-through communication link between system components located across the firewall. Using the user interface provided by the system, the source data and the output device that prints this source data can be selected, either or both of which may be behind the firewall. Thereafter, the source data is retrieved and transferred to the print service (PS1) that renders the output image data according to the source data and the selected output device (D1). The output image data is then submitted to the output device and physically rendered. Access to private resources is achieved with a pass-through communication link. In addition, the system can print documents by reference.

Description

Related applications

  This application has a 35 U.S. S. C. Copending provisional application 60 / 314,412 entitled "METHOD AND APPARATUS FOR WIRELESS DOCUMENT PRINTING, VIEWING AND SHARING" filed on August 22, 2001 and claimed in accordance with §119 (e) No. 60 / 351,754, filed on Jan. 23, 2002, entitled “METHOD AND SYSTEM FOR PRINTING AND FORMATTING DOCUMENTS AND OUTPUT RESOURCE MANAGEMENT FROM MOBILE DEVICES”. 35 U.S. S. C. Co-pending non-provisional application No. 10 / 098,832 and “March 21, 2002,” filed on March 13, 2002, claimed in accordance with §120, entitled “UNIVERSAL PRINTING AND DOCUMENT IMAGEING SYSTEM AND METHOD” Based on co-pending non-provisional application 10 / 104,528 entitled “METHOD AND SYSTEM TO PRINT VIA E-MAIL” filed on the same day. In addition, the specification and drawings of each co-pending non-provisional application are fully incorporated herein by reference.

  The field of the invention relates generally to network printing environments, and more specifically, but not exclusively, to mobile network printing environments and output request management.

  In a traditional printing environment, a user operating a computer that is interconnected via a closed computer network, such as a local area network (LAN), can view a document generated by an application running on that computer. Submit to draw on an output device connected to the network, such as a printer or plotter. In today's rapidly developing mobile business environment, such limited printing solutions are no longer satisfactory. Traditional printing technology has certainly evolved with the goal of outputting high resolution, excellent print quality, and color documents at high speed, but neglected to develop a printing technology suitable for today's mobile workers. It was.

  In today's mobile business environment, there are many scenarios where developers of traditional printing environments have not thought about or dealt with printing. For example, consider the following situation. Can a business developer submit the necessary contracts stored on his company's home network to a printer in the partner's network while preparing to talk about commerce at the partner's office? Can sales representatives on a business trip easily print presentation slides on a nearby printer without having the documents of their presentation slides at hand? Can a Bluetooth handset user enter the room, know that there is a Bluetooth-enabled printer, and print a document with a nearby printer, even if the printer is not Bluetooth-enabled? Can instant messaging users print a document by dragging and dropping the document to a fellow printer list? Will investors be able to print the necessary documents at the headquarters using only their mobile phone while at the airport? It would be convenient to provide a printing solution for these situations and provide other similar scenarios.

  In accordance with aspects of the present invention, a system and method for managing the output of printing, faxing, e-mail, etc. on various types of computer networks is disclosed. In one aspect, the present systems and methods allow access to printing and / or document resources located on a private network behind a firewall. Establish a communication link through the firewall between system components located on both sides of the firewall. Renderable data supplied by the system to a source device, such as a wired computer or wireless device, is provided for rendering a user interface on the source device. Using this user interface, the source data and the output device that prints the source data can be selected, either or both of which may be behind the firewall. After selection, the source data is retrieved (possibly from a private network) and transferred to a print service that renders the output image data according to the source data and the selected output device. The output image data is submitted to the output device and physically rendered. Use pass-through communication links to access private resources. In addition, the system can print documents by reference.

  Many of the foregoing aspects of the invention and resulting advantages thereof will be understood by reference to the following detailed description, taken in conjunction with the accompanying drawings, wherein like reference numerals refer to like parts throughout the drawings, unless otherwise specified. It will be obvious because it is easy to understand.

  Here, an embodiment of an output management system and method for implementing a printing solution for mobile users and landline users is described. In the following description, numerous specific details are set forth, such as example architecture implementations, in order to provide a thorough understanding of embodiments of the present invention. However, one of ordinary skill in the art appreciates that the present invention can be practiced without one or more of the specific details, or with other methods, components, materials, or the like. Will do. In other instances, well-known structures, materials, or operations have not been shown or described in detail to avoid obscuring aspects of the invention.

  Reference throughout this specification to “one embodiment” or “an embodiment” includes at least one embodiment of the invention that includes the particular function, structure, or characteristic described in connection with that embodiment. It is. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular functions, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

  The following terms and their definitions are frequently used throughout the following description.

  Source data: Source data refers to documents or media that can be retrieved and output to a device. Supported input data formats include, but are not limited to, most of the types supported by document processors (eg, PDF, PostScript, Microsoft Word, ASCII text, etc.), Web URL links, email, and There is an email attachment.

  Remote store: A remote store includes a local area network (LAN) or a remote location on the Internet where source data is stored. Remote stores include, but are not limited to, FTP content servers, NFS file servers, PCNFS file servers, and web servers.

  Local source: A local source includes source data stored on the same user device as the issuer of the print request. Therefore, when printing from a local source, the source data must be uploaded from the user's device to the output management system for processing.

Remote source : A remote source contains source data stored on a remote store.

Originating device : A wireless or wired device from which a user submits a job request.

Output device : The output device comprises an apparatus that obtains output image data from the system and converts it to a specific format for display or recording. Supported output devices include, but are not limited to, printers, fax machines, remote document repositories, and email destinations. These output devices can be located on the LAN, but can also be located on external networks, including networks accessible to the general public, such as the Internet and private networks.

Job request : A job request is a request that a user submits to be processed by the system and sent to an output device.

Job status : This is the status of the job request indicating the current progress of the request processing. This is a mechanism to help the user understand the status of job requests and help the system administrator manage them.

Print by Reference (PBR) : In this job processing method, the system must retrieve source data from a remote source, not from a local source.

Delayed printing : Defined as delaying the output of processed job requests and the final stage of job processing when the destination output device is currently unavailable.

User database : A system database used to track each user's system configuration settings.

Server : A computer running software that is accessible over the network.

Web server : Hypertext Markup Language (HTML) file using Hypertext Transmission Protocol (HTTP) or Secure HTTP (HTTPS) between the client computer and the server computer, and a common gateway interface (CGI) A software program running on a computer or server that communicates with a client computer that transmits data and data files.

Windows® printer : In the Microsoft Windows operating system, a “printer” is defined as a combination of a printer driver, a print processor, a language monitor, and a port monitor.

Spool file : A printer language file created by the MS Windows printer driver. The contents of this file can be sent directly to the printer for printing.

Internet Printing Protocol (IPP) : An HTTP-like protocol for sending spool files to printers connected over the network and for obtaining print job status from printers connected over the network.

Line Printer Remote (LPR) : A protocol for submitting spooled files to networked printers.

Zone : A network that surrounds an autonomous output management system. A zone usually contains a logical representation of a network domain.

  Using the various embodiments of the invention described herein, a wireless or wired user can retrieve source data from a local or remote source and send that source data to a destination. A request can be made to output to a selected output device, also called an output device or destination output device. In general, the output device can be on the same network as the originating device (that is, the device from which the output request is issued) and, often, it is a different network, such as a network that is not normally accessible to the originating device. It can also be placed on a network.

  At the top, the operations and functions of the embodiments of the output management system of the present invention described herein are: Message Center (MC), Print Service (PS), Remote Desktop Client (RDC), Wireless It is available through users of the four main components of the data access point (WDAP). Actual implementations typically use various combinations of these components, depending on the specific requirements of the implementation.

  The message center is the heart of the system. Interfacing with the rest of the system components so that the entire system functions properly. As shown in FIG. 1, in one embodiment, the message center MCn has 12 main tasks: component registration and deregistration 10, job request reception 12, job request processing 14, job output scheduling and queues. Ing 16, job output status monitoring 18, peer message center interaction 20, route level message center interaction 22, remote desktop client management 24, print service management 26, wireless data access point management 28 , User profile management 30 and user interface management 32 are executed.

  The print service component handles the drawing and printing of job requests. As shown in FIG. 2, in one embodiment, the print service PSn has “draw output image” 34, “store output image in repository” 36, “send output image to local device” 38, Execute print service tasks such as “Send Job Output Status to Message Center” 40, “Local Output Device Management” 42.

  A remote desktop client component can be used to connect remote devices to the entire system. As shown in FIG. 3, in one embodiment, the remote desktop client RDCn has three main tasks: “Register and deregister output device” 44, “Receive output request from message center”. 46, "Return job output status to message center" 48 is executed.

  Utilizing the wireless data access point component, wireless users can connect to the system using standard wireless protocols such as Bluetooth, IEEE 802.11. The message center can also manage resource mapping for wireless access. As shown in FIG. 4, in one embodiment, WDAPn has five main tasks: “component registration and deregistration” 50, “receive device connection request” 52, “from the user's wireless device” “Relay Request” 54, “Relay System Response to User's Wireless Device” 56, “Record Output Device Geographic Relationship” 58.

  In summary, in each aspect of the invention of the output management system embodiments described herein, 1) device resource management, 2) device resource discovery, 3) job request management, 4) job request scheduling. 5) Job request monitoring, 6) User profile management, 7) User mobile sign-in operations. In the following, an overview of each aspect is briefly described along with the details described using the system embodiments described below.

Device resource management The system manages device resources so that output devices can be identified easily and quickly. In one embodiment, these devices are divided into physical output devices and logical output devices. Physical output devices include, but are not limited to, printers, fax machines, copiers, and the like. Logical output devices include, but are not limited to, file servers, print servers, FTP repositories, and e-mail destinations. A list of related operations is shown below.

Use hierarchical root message centers, public and private device classifications to facilitate resource management and sharing : The system uses a database to record the relationship of each message center. The message center ID (MCID) of the root message center is equal to 0, and all other message center MCID values are non-zero positive integers. Information identifying the zones and network addresses of other message centers is maintained in the root message center table. The local message center needs to register with the root message center and announce resource sharing public resource information. All private device resources are considered private and cannot be shared outside the zone in which they are located.

Device management using local and remote client registration mechanisms : The associated print service registers the connected output device with the message center, and similarly, the associated remote desktop client uses its directly connected output device. Register with the message center. To view these output devices, use the corresponding print service or remote desktop client. Depending on the specific security requirements of the implementation, it is advisable to use encryption for print services and remote desktop clients in the system to ensure data security and data integrity, if necessary. It appears to be.

Device management using the World Wide Web and mobile device interface : The system includes a set of management interfaces along with a simple mobile management interface for device management.

Remote device installation using a centralized driver store : After registering an output device, the corresponding driver must be installed in the print service associated with the output device. The message center provides an array of commonly used drivers in the driver store so that the device does not have to transfer drivers to the print service component. However, if the driver is not currently available from the MC driver store, the driver can be transferred to the driver store and then installed on the print service.

Device Resource Discovery In this book, a user can specify an output device in a mobile computing environment. As described in detail below, in one embodiment, Bluetooth and IEEE 802.11 technologies are used for device discovery. Also, by using this, a device that does not support Bluetooth can be operated as if it were a Bluetooth device through a Bluetooth device emulator. A list of related operations is shown below.

Output device discovery and message center registration via Bluetooth connection : running an agent on a wireless data access point (WDAP) to interface with the message center to obtain output device information Is done by. In addition, the agent maintains an output device information database that runs on the WDAP in cooperation with the message center.

Local generic output device availability announcement to Bluetooth clients via Bluetooth gateway : Deploying an optional Bluetooth gateway allows the message center to manage information received via WDAP. When connecting to a network through a registered WDAP, this information, including output device availability, is announced to wireless users. For mobile users, this information is updated by the system as the user moves through the network and connects to a different WDAP.

Output device discovery and registration through 802.11 gateways : Wireless data access point (WDAP) to interface with the message center to obtain output device information in the same way as used for Bluetooth connections ) By running the agent on top.

Output device availability announcement via IP broadcast : An optional 802.11 gateway is deployed in the system to allow the message center to manage information received through WDAP. When entering the network through registered WDAP, this information, including output device availability, is announced to 802.11 authenticated users. This information is updated by the system when the user moves through the network and connects to a different WDAP.

Local output device availability announcement via instant messaging interface : Remote desktop clients can be extended to support device management through the instant messaging (IM) protocol (eg, AOL Instant Messaging, Yahoo Messaging, MSN messaging, ICQ, etc.). The messaging concept is to allow the user's output resources to be seen and shared by other messenger users (eg, peers). For example, with this feature, an IM user can simply drag and drop files to a shared device that is on the peer's output device list, and the output corresponding to those files can be placed on a device that the peer can easily access. Can be output.

Default output device assignment based on output resource discovery : There are two types of default output devices, one is a static default output device and the other is a dynamic default output device. Users can change the static default output device by modifying their profile settings via a graphical user interface (GUI). However, only the system updates the dynamic default output device when a user accesses the system using a mobile device. In any case, the user can turn off dynamic override in a way that modifies the user's profile settings, or always specifies an output device destination.

Job request management In this system, a request queue is implemented to manage job requests. A list of related operations is shown below.

Managing job requests to output devices using a remote desktop client : Job requests to destination output devices are channeled through the remote desktop client. This RDC allows the output device to retrieve the output data and send the status back to the message center. With the same RDC, cryptography can be implemented to protect the output data exchanged between the message center and the RDC.

Job submission via instant messaging interface : remote desktop clients can be modified to support job submission through instant messaging protocols (eg, AOL instant messaging, Yahoo messaging, MSN messaging, ICQ etc.). Using this mechanism, the user can drag and drop the file to a device on the fellow shared output device list. Thereafter, the mate receives output data from the device. The modified RDC needs to register with the message center (eg, AOL owned, Yahoo owned, company owned, or root MC). If successful, the output management interface on the instant messaging UI is displayed. If the user's buddies are also running an RDC that has been reworked for that instant messaging tool, the user's resource information is transferred to the connected buddies through the instant messaging protocol. You can drag and drop documents to a user's fellow shared output device.

Receiving job print requests via the instant messaging interface : The remote desktop client can be modified to support job reception through the instant messaging protocol. When the sender drags and drops the output data to a device on the recipient's shared output device list, the job request is sent to the recipient's RDC and printed. The modified RDC needs to be registered with the message center as before. If successful, the output management interface on the instant messaging UI is displayed. If the user's buddies are also running an RDC that has been reworked for their instant messaging tool, the user's resource information is transferred to the connected buddies through the instant messaging protocol. The user can receive job requests from other registered users.

Interfacing with multimedia messaging systems : Message centers can deploy inbound and outbound gateways that interface with most multimedia messaging systems. This deployment allows generic multimedia clients to communicate with output management system driven clients to exchange information and request output to shared devices and destinations.

Job submission via Bluetooth connection to a general purpose output device : WDAP with a Bluetooth device emulator allows the user to access the system submission interface through a Bluetooth connection. When requested, information regarding availability of output devices, including Bluetooth and general purpose output devices, is returned to the user. The user can then send output to the selected destination output device through a Bluetooth connection.

Job request drawing by dedicated server : In this system, the print service is used as a dedicated job drawing server. This eliminates the need to install device drivers that are not needed on the client machine. Remote desktop clients can output jobs drawn thousands of miles away to a local device and vice versa.

Personal and business job request classification : The current corporate printing environment does not distinguish between personal print job requests and business requests. In contrast, the system implements a method for classifying job requests, tags the requests in a database, and retains information for accounting purposes. Thus, the accounting department can charge the department or employee based on the job characteristics defined in the job request.

Guest printing support : The system can be configured to support guest printing. This is done through a guest job submission interface hosted in the message center. This interface does not enforce user profile validation, but rather allows only limited access to public output resources. Administrators can configure the message center to still support dynamic default printers for guest printing.

E-mail / job request support : This system accepts an e-mail with or without an attached file as a general job request. These requests can be processed with or without attachments to multiple output channels.

Document Preview : The system supports document preview so that the user can visually check (eg, whether the document version is correct) before issuing the final output request. . Using this document preview feature, the user can quickly display images as dithered thumbnails and display other files in plain text format with page references preserved. Spreadsheet software also has both vertical and horizontal navigation functions. Further, since the relationship between pages of the original document is maintained in the preview document, the user can preview the document with random access.

The job request scheduling system implements a request queue to manage job requests. A list of related operations is shown below.

Delayed job scheduling : When a job request enters the message center, a job queue entry is inserted into the message center database to hold enough information to perform job processing. If the destination output device is not available, the system keeps the entry in the queue and reschedules it for submission later when the output device becomes available (uses an administrator-configurable delay value). )

Output using a file reference in a job spooling factory : The system renders an output image using a print service. Since the print service and message center are generally not co-located on the same host machine, the drawing data needs to be transferred from the print service to the message center for final processing. For efficiency, the print service stores the rendered image in a shared spooling factory (ie, repository) and returns an image reference to the message center. The message center then uses this reference to output the data to the destination.

Secure output through firewall : Since the system is modular in design, the configuration of each component can be customized. Administrators can install a firewall to protect the system. Remote desktop clients have the ability to interface with the message center when the firewall is properly configured. This allows the document to be printed through the firewall.

Job request monitoring This system implements the job status monitoring function via the job queue queue log tracking function. A list of related operations is shown below.

Job status monitoring through job persistent state tracking using database updates : The message center maintains a persistent state for each job request. When a job output request is sent, the table update handler monitors the job status to determine whether the output request is complete. If completed, update the database and return the status to the user.

Job output status report via WAP push : When the job request is completed, the job status in the database is updated. Thereafter, if the job originator is a WAP client, the message center notifies the user of completion through the WAP push.

Job output status report via HTTP browser update : When the job request is completed, the job status in the database is updated. The message center then notifies the user that it has completed. In the HTTP job submit client, the job status is updated by automatic browser update until the status is marked complete.

Output creation This system implements a print service for output creation. The following is a list of related operations performed by the print service.

Dynamic selection of output rendering applications based on input file format and configurable system settings : Applications used to render output file images can be prioritized based on the format of the input file. The priority order can be adjusted by changing the system configuration setting.

Use of third party applications for output file image rendering : The system can also use third party applications for rendering of output images.

Support for multiple output rendering algorithms : The system uses different methods to generate the output image, depending on the specific characteristics of the input document. You can use background services with printing tools and printer drivers, use foreground keystroke simulation with application control handlers, and use translators to draw.

Multiple output channel support : The system includes, but is not limited to, printing to printer channels, sending faxes to fax recipients, previewing output images on the originating device, and sending output to email destinations. Support multiple output channels. If the e-mail destination output channel is selected, the document can be included in the body of the e-mail or sent as an attachment.

Window handlers that increase overall system reliability : The system uses window handlers to handle the various pop-up dialog boxes that appear when using the foreground output drawing option. As a result, the system can be operated in a completely unattended state for a long time.

User Profile Management Using this system, users can manage personal profiles using the web or mobile device interface. A list of related operations is shown below.

User profile management and dynamic updates via web and mobile device interfaces : User profiles are created and maintained by the message center used to store subscription information. Users can change their configuration settings using the WEB (HTML) or WAP (WML) interface, if necessary. Furthermore, if the user is currently accessing a system in the user's home network using a mobile device, the system automatically updates the user's dynamic default printer.

Support for user profile multiple billing records : The user profile includes multiple billing IDs for the system to tag different types of billing. For example, a user can have both a personal print account and a business print account. This allows the organization to incorporate the output management system into the billing system relatively easily.

User Mobile Sign-In With this system, a user can sign on to a local network via a wireless data access point (WDAP). Thereafter, the local shared resource becomes available to the user. A list of related operations is shown below.

User authentication by verifying query results from a mobile device : The system searches the unique identifier of the query results to see if it is valid against the user's profile. A customized greeting can then be sent based on the user's identity.

Allow access to system resources by mobile users : With the wireless data access point component, wireless users can access the network over a wireless connection (eg, Bluetooth, 802.11). . WDAP also supports dynamic default printer management.

System Configuration Example A simple system configuration example 59 is shown in FIG. In this example, the system is deployed in two zones, zone 0 and zone 1, and is linked by communication via the Internet 60. Zone 0 includes a root message center MC0 that manages all shared public output resources. Zone 0 can also contain an optional firewall 61. Zone 1 includes two message centers MC1, MC2. The message center MC1 is located behind the internal firewall 62 and is private. The message center MC2 is located in a network DMZ (demilitarized zone) between the firewalls 63 and 64 and is public. The printer service PS1 is also public, and so is the remote desktop client RDC1. Both output devices D1 and D2 are public.

  In FIG. 5 and the following system configuration diagram, the solid line indicates that there is a direct link between connected entities, and the dashed line indicates that the entity connection is not a direct link but a logical association (eg, registration). It is based on. For example, output device D1 is directly linked to print service PS1 via direct link 66, and output device D2 is logically associated with remote desktop client RDC1, as indicated by logical association 68. ing.

  In some configurations, a port on the firewall is provided so that the user can access the message center MC2 and the message center MC2 can access the print service PS1, remote desktop client RDC1, and output devices D1, D2. 80 (for example, for handling CGI calls by Apache Web Services) and port 5190 (for instant messaging and system communication ports) need to be opened. If SSL (Secure Socket Layer) is required, the firewall further needs to open port 443. Note that the wireless data access point WDAP1 is located behind the internal firewall 60 for security reasons and blocks external wireless users from the internal network.

  A more complex system configuration example 70 is shown in FIG. In this example, the system has three zones, zone 0, zone 1, and zone 2. Zone 0 includes a root message center MC0 that manages all shared public output resources. Zone 1 and zone 2 are private zones and can contain both public and private resources. Zone 1 has one public message center MC1, two private printing services PS1, PS2, two private WDAPs (WDAP1, WDAP2), one public remote desktop client RDC2, and two private It includes output devices D2, D3 and one public output device D4. Zone 2 includes two public message centers MC2, MC3, two private printing services PS3, PS4, two private WDAPs (WDAP1, WDAP2), one private remote desktop client RDC5, three It includes three public remote desktop clients RDC3, RDC4, RDC6, three private output devices D6, D8, D9 and three public output devices D5, D7, D10. In the zone 0, there is a public message center MC0 in which three message centers (MC1, MC2, MC3) are registered. It also includes a registered remote desktop client (RDC1). Private resources within each zone (eg, output devices D2, D3, D8 and remote desktop client RDC5) are not shared outside the zone. The message center that manages public resources is registered with the root message center MC0 so that it can be accessed via public requests.

  Message center MC0 is a root-level message center that includes a reference to a registered public message center. After the system is installed, the enterprise message center (MC1, MC2) needs to register with the root message center. If you need to manage a large number of public resources, you can have multiple root message centers in your configuration. In such a case, in one embodiment, the root MC is represented by a hierarchical tree. In general, the organization of the root message center in such an implementation is very flexible. Using geographic layout to illustrate one classification method, the lowest level of the tree hierarchy corresponds to a particular region (eg, California, Minnesota, Taiwan, Guangdong Province), with the second from the bottom At the level, some of the regional MCs are grouped into larger regional MCs (eg, US MC, China MC), and at the upper level of the hierarchy, there are also some of the second level MCs from the bottom Can be grouped into larger regional MCs (eg, America, Asia, Europe), and finally this hierarchy will cause the master MC to represent the entire domain. A similar approach can be applied to companies, individuals and governments to set up a message center hierarchy.

  Registered message centers can query the root message center for public output resources. In one embodiment, the search can be based on RDC parameters, i.e., the client's name, the client's zip code, or the state in which the client is located. This search can also be based on zone descriptors or zone types. Further, the search for device resources can be based on device resource names or device resource descriptions. When the zone 0 root level message center receives the search request, it returns the identifier of the record found in its database. Subsequent search runs use these identifiers as modifiers to return more extensive information.

  Returning to FIG. 1, the details of the message center component will be described. The remote desktop client and print service register their output resources in a message center that allows access to those services through the component registration and deregistration component 10. When executing the registration process, the output resource type (eg, printer, plotter, etc.) is determined by the corresponding type definition data. The message center collects these output resources and registers public output resources with the root level message center. The root message center can create a record for each registered public output device with sufficient information, and other message centers can remotely access resources using the data contained in the record as a corresponding reference Like that.

  If the output device needs to be separated from the message center, send a deregistration request to the message center. In response, the message center unregisters the output device from the root message center. If the output device is a public resource, the corresponding shared record in the root message center database is also deleted.

  In the job request reception task 12, the message center can receive a job request. In one embodiment, the message center employs an Apache web server that executes a set of CGI scripts that can be invoked to submit a job request. The CGI script adds the print job to the message center system job queue. Once the job queue entry is created, the job submission is considered complete.

  After the job request is submitted, the processing of the request is executed by the job request processing task 14. When a job request enters the system, the message center collects source data through a remote source reference on the remote store, or the submitter sends a local source to the message center. The message center then identifies the print service and renders the output image file corresponding to the source data and destination output device.

  After the output image file is created, the print service returns a file reference to the message center, which then calls the corresponding RDC to send the rendered image to the output device. If the RDC or destination device is not available, the print request is delayed. The system will then attempt to resend the print request to the RDC as defined by the configurable retry duration. These operations are handled by job output scheduling and queuing task 16.

  After the job output request is sent to the output device, the job status is returned to the message center via the job output status monitoring task 18. The message center updates the status and notifies the user of the current job output status. In one current implementation, the system supports DOCUMENT_DONE, INPUT_PENDING, RESOURCE_WAIT, IN_PROGRESS, COMPLETE, CANCEL_BY_USER, and ERROR as job states.

  Following the Peer Message Center Interaction Task 20, the system architecture can provide message center peer-to-peer communication for various operations. Information exchange between peer message centers includes zone 0 lookup queries, document path selection requests, document print requests, and status replies.

Two examples of message center interactions are shown in FIGS. The example of FIG. 7 illustrates how a user requests a public device to connect to his home message center in preparation for a subsequent request to the public device. The query procedure proceeds as follows.
1. User (U1) submits a public device connection request to the user's home message center (MC1). This public device (D2) happens to be a root message center connection device.
2. The user's home message center (MC1) sends a query regarding access to the output device to the root message center (MC0).
3. The route message center (MC0) specifies a route to the designated output device and sends a connection request to the remote desktop client (RDC1).
4). The remote desktop client (RDC1) connects to the user's home MC (MC1), where a connection is established.

The example shown in FIG. 8 corresponds to a peer-to-peer message center request and the procedure is as follows.
1. User (U1) submits a public device connection request to the user's home message center (MC1). This public device (D2) happens to be registered with another peer message center (MC2).
2. The user's home message center (MC1) sends a query to the root MC (MC0).
3. The route message center (MC0) specifies a route to the designated device and transmits a connection request to the destination message center (MC2).
4). The destination message center (MC2) accepts the inquiry from the root message center (MC0) and sends a response back to the root message center (MC0).
5. The route message center (MC0) receives the “OK” response and sends the route information to the user's home message center (MC1).
6). The destination message center (MC2) connects to the user's home MC (MC1), where the connection is established.

  The root level message center interaction task 22 facilitates sharing of public output resources through the concept of a root level message center. The root level message center has the advantage of having a central location for fast lookup of public resources. To support such mechanisms, non-root level message centers interact with root level message centers to announce public resources and, if necessary, other users' public resources. You also need to run a query on

  By utilizing a remote desktop client, the message center can send a job request to an output device. It can also be used to configure the entire system so that security risks are reduced. For example, an internal RDC can be set up for a secure output device and an external RDC can be set up for a public output device. These operations are handled by the remote desktop client management task 24.

  The message center can be connected to multiple printing services. This idea is to use a plurality of print services as a set instead of a single print service in order to increase the management efficiency of the output device. Because these print services are important components for generating output images, the message center maintains a very close relationship with these print services. These exchanges are processed by the print service management task 26.

  In order to support wireless devices such as Bluetooth and 802.11 enabled devices, the system deploys one or more wireless data access points. Each WDAP contains a set of descriptions and information and requires management at the corresponding message center. For example, the dynamic default output device for each wireless data access point is maintained by the corresponding MC of the WDAP. These operations are handled by the wireless data access point management task 28.

  The message center maintains a login authentication user profile and some default service settings, as indicated by the user profile management task 30. For example, a static default printer and a dynamic default printer for each user are defined in the user's profile. Users can modify their profiles via a standard web interface or device interface.

  User interface management task 32 handles the various user interfaces provided in the system. The “consumer” user interface is used not only for account management by the user, but also for exercising service requests. In one embodiment, the consumer interface provides one segment for home users and another segment for guest users. The guest user interface allows limited access to system resources under certain conditions for security reasons. The system also has an administrative user interface for debugging and maintenance, and for setting up various system components and parameters.

  The print service performs the five main tasks shown in FIG. When the print service receives a job drawing request in the output image drawing task 34, an internal component called a driverless print (DP) server collects the source data and places the data in the DP server queue. The DP server then calls the DPS print module to identify the appropriate driver and generate an output image. The DPS print module places the output image in the internal output queue and returns control to the DP server. Details of these operations are described in detail below.

  When the DPS print module returns control to the DP server, the DP server calls the status monitor module. If the destination device is not locally connected to the print service, the status monitor writes the output image to the shared repository according to task 36. Thereafter, the control right is returned to the DP server. If the destination device is a locally attached device, the status monitor sends the output image to the device according to task 38. Thereafter, the control right is returned to the DP server. Task 40 causes the job status to be sent back to the message center after the status monitor returns the job status to the DP server. Using the local output device management task 42, the print service can support locally connected output devices. This handles device registration and deregistration with the message center.

  Referring to FIG. 3, the remote desktop client can manage the device's connection to the message center via device registration and deregistration tasks 44. To register, send a device registration request to establish an association with the message center. To unregister, send a device deregistration request and delete the association from the message center.

  The remote desktop client receives a job output request from the message center with reference to the output image file according to task 46. This retrieves the output image file and sends it to the destination output device. If the reference is not used, the message center sends the output data directly to the remote desktop client. After job output is complete, the remote desktop client notifies the message center of job output status updates and user contact based on task 48.

  Referring to FIG. 4, it can be seen that each wireless data access point performs the following main tasks: The wireless data access point needs to be registered with the message center and linked to the system, which is handled through a component registration and deregistration task 50. WDAP registration is intended to inform the message center of the WDAP default output device (ie, the closest output device). This allows the message center to determine the mobile user's dynamic default printer. To delete the association, task 50 sends a deregistration request to the same message center.

  Accessing a wired network from a wireless device requires an access point that receives the request and converts the request from a wireless packet to a landline packet. The WDAP server is the system's data access point. Task 52 causes the non-cellular device's wireless request to enter the system through the wireless data access point.

  When the wireless data access point receives the connection request, it converts the request into an IP packet according to task 54 and transmits the IP packet to the destination defined by the request. In return, the system response is processed at task 56. As the user moves from a first location close to the first WDAP to a second location close to the second WDAP, the system returns another set of device information to the user via the second WDAP. Therefore, one of the important roles of WDAP is to plan in detail the default output device and allow it to communicate with the message center to dynamically generate device information according to the output device geographic relationship recording task 58. is there.

  As mentioned above, the system can operate the system as if it were a Bluetooth-enabled device, even if it is not a Bluetooth device, using an optional Bluetooth gateway and Bluetooth device emulation. it can. If necessary, a Bluetooth gateway function can be incorporated into the wireless data access point to reduce hardware costs, as described below.

Operation Theory This section describes the flow of request data as well as the common operations of the system. Here are some highlights of system features and requirements:
1. All users are associated with a home message center.
2. The system can enforce security between two message centers, security between the message center and the print service, and security between the message center and the RDC.
3. In the Message Center, resource access can be controlled by home users and guest (visitor) users.
4). Each WDAP is associated with a configurable default printer.
5. When accessing the system via WDAP, if the user specifies dynamic system override permission in his profile, the user's default printer is changed based on the WDAP to which the user is currently connected.
6). The guest user interface can be implemented in a message center that supports visitor printing within the zone. Such an interface does not require user registration or profile creation. Therefore, it does not support static default printer printing. However, in the system, the visitor can perform dynamic default printer printing, and the user can specify the destination printer as an option.

  The system employs a modular architecture design and an extensible database schema, so advanced security schemes can be implemented. First, in user authentication, the subscriber database includes a user profile that is used to verify against user login data entered into the system via a supported access device. . If this verification fails, a record is stored in the system for later reference or investigation and the login request is rejected. In addition, the message center can implement public key infrastructure support for higher level client and server authentication. Second, with data encryption support, each module can implement encryption to protect the content data. Encryption can be enforced from file store to message center, message center to print service, print service to output repository, and output repository to RDC. Third, under a non-repudiation implementation, the system assigns each subscriber a unique ID. When a user submits a request to the system, the user's ID and time stamp are tagged as a tag immediately upon the request. If this is a job submission request, a replica is generated in the system and logged and archived for later reference and billing.

  In addition to the security implementation described above, another advantage of the modular distributed architecture is that the administrator can customize security settings based on the specific needs of each organization. For example, a virtual private network (VPN) can be used to link a shared file server to a message center. Similarly, VPN can be implemented between a message center and a remote desktop client. The system architecture supports both software and hardware VPN configurations. The overall system configuration can include support for public key infrastructure, providing authentication and certification, protecting data integrity and data privacy, and satisfying non-repudiation requirements.

  A flow diagram illustrating the exchange of information between the RDC and the message center in accordance with the RDC client registration request is shown in FIG. The RDC sends a session packet to the message center and initiates the client registration process. In one embodiment, the session packet includes a client descriptor string, client type, first name, middle name, last name, address 1, address 2, city, state, zip code, USERID, protected PASSWORD , Various parameters for defining clients on the message center, such as EMAIL values. If successful, a client identifier (CID) is returned to the RDC.

  A flowchart corresponding to the RDC printer registration request is shown in FIG. Like the previous process, the RDC sends a session packet to the message center and initiates the printer registration process. The packet includes data identifying the client at the message center and provides the status of the resource requested to register (eg, output device). If successful, a printer resource identifier (PID) is returned to the RDC.

  The remote desktop client needs to register with the MC in order to access other public resources and make the resources available. A flow diagram corresponding to the RDC submitting the device resource definition to the message center is shown in FIG. The RDC sends a device resource definition packet to the message center so that the device resource is defined in the message center. In general, this information includes the device name, device type, device descriptor, and device status.

  If a client wants to access a remote public device, it must first identify the device via a public device query. This operation requires the home message center to send a query to the root message center for a list of available public devices, as shown in the flowchart of FIG. The message center then determines whether such a public device is supported in the zone. That is, the home message center needs to identify registered printing services that support such public devices. In response to the query, a list of available public devices is returned to the requester. If support for the registered print service for the public device is not found, the unsupported public device is not described in the list.

  13 and 14 show a flow diagram and component interaction diagram corresponding to a print by reference (PBR) job request issued by a user in the home domain to an output device directly connected to a print service in the home domain. (For example, U1 → D2 or U1 → D3 in FIG. 6). Under a PBR job request, the user can print a document 72 stored on the remote store 74 (ie, a remote source) with the target destination printer, and the remotely stored document or destination printer. Can be selected by the user interface 76.

  A flowchart of processing corresponding to a non-PBR job request is shown in FIG. In this case, all operations are similar to PBR job requests, except that the source data is uploaded from the user's device to the message center and does not retrieve the remote source.

  FIGS. 16 and 17 respectively show a process flow diagram and component interaction diagram corresponding to a PBR job request submitted by a user in the home domain to a local printer connected to a remote desktop client in the home domain. (For example, U1 → D4 in FIG. 6). In this case, the output image is rendered by the print service and then stored in the output repository 78 as the output image file 80. A print request is then sent to the appropriate RDC (eg, RDC2), where it retrieves the output image file from the repository, submits it to the output device (eg, D4), and physically renders it. After completion, a print completion notification is sent back to the user via the message center and displayed on the user interface 76.

  18 and 19 are a process flow diagram and component interaction corresponding to a PBR job request submitted by a user in the home domain (eg, Zone 1) and printed on the root message center public output device (D1). The figure is shown. This process begins with using the UI to activate the user interface 76 to perform a public device query. In essence, this query returns a list of available public devices. Optionally, the user can select a known public device, and the query performs a task to confirm that the device is available for public access. When a user submits a query to his home message center (MC1), the MC forwards the query to the root MC. The root MC then checks the database for all available printers for that user (based on user authentication information sent with the query and a configured list of the user's favorite printers). A local print service is identified along with the output device path to the home message center. The public device information is then sent back to the user who can select the public output device and submit the print job request to the home MC.

  After receiving the print job request, the home MC searches for the document to be printed (in this case, since the document is a local source, it is sent from the source device to the MC), and the document is sent together with the drawing request to the destination print service. To (PS1). Next, the print service draws the output image of the document and stores it in the output repository 78. Thereafter, a notification that drawing is complete is sent back from the PS to the home MC, where the home MC retrieves drawing data (eg, output image file 80) from the output repository and sends the print request along with the output image data to the destination. To the remote desktop client (RDC1). Further, the RDC transmits the output image data to the destination output device (DC1), after which the hard copy output is drawn, and a print completion notification is returned to the RDC. Then, a print completion notification is transferred to the user and returned via the root MC and home MC.

Message Center Access Mechanisms There are generally three types of mechanisms for accessing the home message center. In other words, wired network connection, wireless network connection, and wireless web cellular connection (as used herein, cellular connection is implemented via a cell-based infrastructure including cellular and PSC networks). Included wireless connection). For example, users of wireless web-enabled devices, including cellular phone 100, PDA 102, and interactive pager 104 (eg, a Blackberry device), can operate multiple cellular towers 106 and cellular service provider network operations. • The message center MCn can be accessed via a cellular network including the center 108.

  In the United States, wireless Internet (ie, wireless Web) access is typically achieved using a wireless application protocol (WAP) that works with WAP-enabled devices. In Asia, wireless Internet access is generally implemented using the i-mode® protocol. To access data using the i-mode protocol, the wireless device must be an i-mode device or be capable of both i-mode and WAP connections. Other less commonly used protocols are also used around the world. In the embodiment shown in FIG. 20, this wireless web connection can also be used via a WAP gateway 110 hosted by a WAP gateway server 112. Optionally, other types of wireless Web gateways such as i-mode gateways can be used depending on the functionality provided by the wireless service provider.

  WAP-enabled devices can access data from various Internet sites that provide content designed to be used by such devices. This data is generally distributed to devices as wireless markup language (WML) data, as described below. WML was thought to effectively use limited browsing capabilities in view of the low-resolution displays and limited navigation capabilities available on today's handheld devices such as wireless phones, PDAs, and pocket PCs. Includes special markup languages. WML includes HDML (Handheld Device Markup Language) and can trace its roots to XML (Extensible Markup Language). It also includes a meta language that supports user-defined extensions.

  A WAP-enabled device may access various websites that provide wireless Internet content via a WAP gateway (such as WAP gateway 110) implemented using one or more WAP gateway servers 112. it can. In general, each WAP gateway is operated by various service providers in the region that support wireless Internet access, but service providers can share WAP gateway functionality. That is, the WAP gateway server uses HTML (Hypertext Markup Language) data retrieved via HTTP (Hypertext Transport Protocol) from a wireless Web site (wireless Web content is not directly encoded with WML). Run various software modules and / or applications with functionality that facilitates interaction with WAP-enabled devices, including converting to WML. These functions include a WAP encoder that converts HTML data to WML, a script compiler, and a protocol adapter.

  In order to create wireless Internet content, a Web site typically has to create a text-only version or a version that does not use images or animations for all or some of the pages of the site. At present, only a few Internet websites offer wireless Internet content, but such sites are expected to grow exponentially as more people purchase WAP-enabled devices. . The main reason for preparing such text-only content or content that does not use images or videos is that the resolution of the display screen of a WAP-compatible device is generally very low, and the typical wireless data transfer rate is the network over the landline It is considerably slower than the data transfer rate available via Some of the current wireless Internet content includes HTML that must be converted to WML by the WAP gateway, but there are many websites that already supply WML-encoded data directly to the WAP gateway. Please note that.

  Referring to FIG. 20, a normal WAP session proceeds as follows. A user operating a WAP-enabled device such as PDA 102 opens a “mini browser” (the WAP client for that session) and then sends a wireless signal 114 through the wireless modem of PDA 102 searching for WAP services. . In response, the user establishes a connection with a service provider with a wireless internet access subscription service contract via the nearby cellular tower 106. The user then selects the website that he / she wishes to display by entering the URL of the website through the UI provided by the mini-browser (as shown by the mini-browser UI 107). Thereafter, a request to access the site is transmitted from the PDA 102 to the WAP gateway 110. The WAP gateway server 112 retrieves information corresponding to the URL from the Web site via HTTP as HTML data in this case, and encodes the HTML data into WML (Wireless Markup Language). As mentioned above, some Internet sites do not require HTML-WML encoding because the data may already be in WML format.

  According to one embodiment of the present invention, each message center MCn is a host for one or more respective URLs via the Web server 113 as described below. As indicated by the HTML data 114 and the WML data 116, the URL data hosted by the Web server 113 is transferred from the message center to the WAP gateway via a communication network such as the Internet 60 or a private network. . WML data is then transmitted from the WAP gateway server 112 to the PDA 102 via the cellular tower 106. Similar to traditional browsing methods, the user can browse various pages on the site by activating the appropriate UI component displayed to the user via the mini-browser, thereby As a response to the exchange of information, the same process as described above is executed, and the content corresponding to the one selected by the user is displayed.

  In addition to wireless web access, linked to the user device via a direct landline connection, or a communication link that includes a combination of a landline network and a wireless network (eg, 802.11b), or a Bluetooth radio link The message center can be accessed via the landline network. For example, a user of a personal computer (PC) 118 or laptop 120 can access the message center MCn via a direct network connection (eg, a LAN connection) to the message center or a WAN connection such as the Internet. Both of these network connections are indicated by computer network 122. In one embodiment, a user can access services provided by the system through a set of web pages 126 through a browser-based user interface 124, as described below.

  In general, the user interface is similar to that of a link that further includes an 802.11 (also referred to as WiFi) connection. For example, in a typical 802.11 implementation, a WiFi enabled user device, such as PDA 128 of FIG. 20, is connected to a wired network (eg, network 122) via WDAP 130. WDAP controls all communications from WiFi enabled devices, while making the device appear to the network as if it had a normal client connection. Thus, from an operational point of view, the wired client and the WiFi client appear to be the same to the message center.

  In addition, the system allows Bluetooth connected clients to print to the selected output device, but using a different mechanism. Based on this mechanism, it is necessary to implement a Bluetooth emulator so that a Bluetooth-compatible source device such as cellular 132 can be thought of when communicating directly with a Bluetooth device, and to make changes to the built-in Bluetooth user interface 133 of the source device There is no. For example, suppose a user wants to print to a non-Bluetooth capable printing / fax device. In this case, a Bluetooth printer / fax emulator is implemented that allows the front-end agent to communicate with nearby wireless data access points. In one embodiment, a Bluetooth device emulator can be incorporated into the WDAP. This is indicated by the WDAP + Bluetooth device emulator 134. Optionally, the Bluetooth device emulator can be an independent device linked to and communicating with the network 122. In general, the Bluetooth device emulator uses the corresponding output device information retrieved from the message center to generate the necessary Bluetooth device information (eg, print or fax profile), and the profile was retrieved from the message center. Created on the fly using resource information. Thus, in one embodiment, the emulator also includes a back-end communication channel that is employed to interface with the message center (via built-in or nearby WDAP). When a Bluetooth enabled device connects to the system at a different access point, the corresponding emulator responds with profile information specific to that access point.

  This system allows non-Bluetooth enabled devices to behave as if they are Bluetooth enabled devices through similar Bluetooth device emulation as defined by Bluetooth Basic Printing or Fax Profile Interoperability Specification. It has become a simple and cost-effective way for enterprises to manage non-wireless technology devices in computing environments. These operations are transparent to both the user and the destination device. In addition, resources such as legacy devices are currently managed by the message center, so companies do not need to modify, replace, or even upgrade these legacy devices.

  Furthermore, the “print by reference” function of the output management system can be extended to a Bluetooth-compatible source device. For example, in one embodiment, WML content that renders a WAP interface, described below, can be provided to a Bluetooth enabled device that includes a WAP mini-browser 107A designed for WAP on the Bluetooth service. Such devices are likely to become commonplace in the near future. With such a configuration, a Bluetooth device user can interact with the system in substantially the same way as a wireless Web user by supplying the same WML content to the Bluetooth device via a WDAP + Bluetooth device emulator. .

Default device discovery (WiFi)
The system introduces the concept of static and dynamic default settings so that it can properly accommodate mobile computing protocols. For example, the message center implements default device configuration options in the user's profile. Taking a printer as an example, there are two types of default printers for each user: a static default printer and a dynamic default printer. The former is selected when the user accesses the system through a wired connection (eg, PC 118), and the latter is selected when the user accesses the system through a wireless connection (eg, Bluetooth, 802.11, etc.). . Perhaps the user does not have much opportunity to send output to his office printer when using the mobile station at the user's client site. It is quite practical and affordable to automatically switch the default settings using the access method. However, for flexibility, there is an option for the user to disable the dynamic default printer override function through profile configuration.

  FIG. 21 is a schematic diagram detailing the operations used to determine a dynamic default printer when a user submits a job via WDAP. First, the user of the wireless device 128 enters the system with a wireless connection with the wireless data access point WDAP2. In the example shown in the figure, it is assumed that the user submits a PBR job request. In response, WDAP2 relays the PBR job request to the message center. The message center retrieves source data from the file store 136 corresponding to the PBR job request. The message center finds that the request is from WDAP2, checks its device database, and finds that the dynamic default printer associated with WDAP2 is the output device D1 associated with print service PS1. know. Therefore, a drawing request is transmitted to PS1. PS1 renders the job request and then sends the output image data to the output device D1. The output device D1 completes the job output and notifies the PS1 of the completion of the task. PS1 then informs the message center. The message center sends a response to WDAP 2 to inform the user that the job request has been successfully completed. WDAP2 then relays the response to the user's device.

Default device discovery (Bluetooth)
In the following cases illustrated in FIGS. 22A and 22B, WDAP1 and WDAP2 are networked except that they each include a Bluetooth device emulator, as indicated by WDAP + Bluetooth device emulator device 138, 140, respectively. The configuration is substantially the same. In both cases, the process begins with the user of the Bluetooth enabled source device 132 requesting an initialization communication with another Bluetooth enabled device. In these examples, the source device's Bluetooth signal is received by the WDAP2 + Bluetooth device emulator device 140, thereby establishing a communication link with the Bluetooth source device.

  At this point, the basic types of interfaces that can be used by the system to communicate with Bluetooth enabled device users and users include basic Bluetooth UI (eg, Bluetooth UI 133) and advanced Bluetooth UI (eg, Bluetooth mini-browser UI). 107 WAP). In the basic Bluetooth UI, the emulator operates as a simulated Bluetooth enabled output device or a plurality of such output devices. In the advanced Bluetooth UI, the emulator serves as a bridge for supplying WAP content to a Bluetooth-enabled device via WAP over Bluetooth.

  Assume that a basic Bluetooth UI is provided. This case is illustrated in FIG. 22A. In this case, after establishing the Bluetooth link, the user searches for a Bluetooth-compatible output device (or the user initializes the Bluetooth link using the output device search function). In response, the emulator connects to the root message center (directly or indirectly) and retrieves information related to the output device near the WDAP that facilitates the exchange of information. Because this type of information is stored in the message center database, the MC can return Bluetooth emulation parameters 141 to emulators corresponding to various output devices that can be used via WDAP. In an optional embodiment, the emulator requires the user to authenticate (or identify the user by some other means, for example using a unique device identifier) and provide a list of output devices specific to that user. Can send. The emulator then emulates the available output devices so that it assumes that the Bluetooth enabled source device is actually communicating directly with one or more corresponding Bluetooth enabled output devices. For example, if the available output devices include two types of laser printers and a text printer, the emulator performs Bluetooth device emulation for all three printers. If only one device can be used, that device becomes the default output device. The user then selects an output device via the Bluetooth UI and uploads the source data to the emulator as if uploading directly to the Bluetooth enabled output device. The emulator then forwards the source data to the message center where it invokes the appropriate print service to generate output image data and submit it to the selected output device for rendering.

  According to the example shown in FIG. 22B, a user can access the system via WAP over a Bluetooth service hosted by a message center. Initially, a Bluetooth connection between the Bluetooth enabled source device and the emulator is established as described above. The emulator then contacts the message center to supply WML content and begin drawing the user interface via WAP with the Bluetooth mini-browser 107A, which allows the user to retrieve source files from the file store 136. Data can be selected and an output device (D1) can be selected. All remaining operations proceed in substantially the same manner as described above for the PBR example of FIG.

  In one embodiment, the system includes an optional configuration that employs a Bluetooth gateway 142. This gateway allows the message center to communicate with the Bluetooth device emulator. The Bluetooth gateway further tracks the mapping between the device and the wireless data access point and synchronizes the map with the message center. Such a mapping is calculated using input from a device emulator or by network sniffing.

System Connection Topology FIG. 23 shows a system connection topology schematic diagram 150 representing various connection paths and types of connections that can occur in a typical implementation of an output management system. A solid line indicates a permanent connection, and a wavy line indicates a temporary connection. For component communication, the first rule is that the PS and RDC always initiate a connection to the message center. According to the second rule for peer-to-peer message center communication, this connection is always initiated from a secure network to a less secure network (eg, from a private network to a DMZ). , Zone 1 DMZ to zone 0 DMZ, etc.). If both rules are applicable, the first rule takes precedence.

  In 150 of FIG. 23, zone 0, located in the middle of the figure, is a root message center MC0 that includes a central repository for all MCs to announce and share their public resources (eg, output devices). including. Therefore, the components in zone 0 are preferably located in the DMZ to accept incoming connection requests that use the appropriate degree of security protection. Zone 1 and zone 2 are located on both sides of zone 0 and include two independent networks, each with a fully protected security (ie, private network portion) and DMZ portion. The MCs (MC12, MC22) in the DMZ of zones 1 and 2 manage public and sharable sources and are therefore referred to as “public” MCs. MCs in private subnets behind internal corporate firewalls 152, 154 (respectively MC21, M11) manage private resources and are therefore referred to as “private” MCs.

The following is a table of component deployment location maps showing where the components reside according to one embodiment of the present invention. “Public network” refers to a network without a firewall protection function that is directly connected to the Internet. Usually accepts all incoming connection requests. “DMZ” refers to a private network that is protected with restrictions. Normally, incoming connection requests are accepted when patched through several well-known ports. “Private network” refers to a network with strong firewall protection. Usually, most if not all incoming connection requests are blocked. Location within the private network suggests that incoming connection requests are blocked, and therefore resources can be used by using a proxy (eg, DMZ MC or root MC) to bridge job requests. It becomes easy to share. MC and PS should not be deployed in public networks for obvious security reasons. The root message center (eg, MC0) cannot be deployed on a private network because it needs to provide at least limited public access so that the public MC can register. Although RDC can be placed in a public network to allow sharing of a wide range of resources, it is not recommended.

The table of the component deployment position classification map for explaining the component deployment position 150 in FIG. 23 is shown below.

  Tables 3 to 6 below show a set of MC network connection maps describing communication methods between components including connection type, connection initiator, and data transfer type. For performance reasons, persistent connections are preferably only used for control message exchanges (eg resource queries, resource registration), while temporary connections are both control message exchanges and non-control message exchanges. In other words, it can be used for source file data transfer and drawing output image data transfer. Even if persistent connections are available, support for temporary connections is implied. The type of data transfer is either “by buffer” or “by reference”. Even if "by reference" transfers are available, "buffer" transfer support is implicitly included. Transfer by reference may not be an option that can be used if the sender's file store is not visible to the recipient. In such a case, the data is directed to the destination resource with an appropriate MC.

The following table corresponds to the network connection map in the MC0 zone. This table describes how to communicate with other components in the same zone as the root MC. Since it is in zone 0, “private” MC and PS cannot be used.

Below, except for inter-zone communication, the same MC0 inter-zone / network connection map as in Table 3 above is shown. This table describes the communication method between the root MC and other components in a different zone.

The following is an intra-MC zone network connection map that is not zone 0. This table describes how the non-zone 0 message center communicates with other components in the same zone.

Below, except for the case of inter-zone communication, a non-zone 0 MC zone / network connection map similar to the above table is shown. This table describes a method of communication between an MC that is not zone 0 and other components in a different zone.

  In general, the components in the system communicate using a network message protocol. For example, there is an RDC network message protocol for communicating between a remote desktop client and a message center server. In one embodiment, the connection between the RDC and the MC server is initiated by a socket connection from the RDC to the port 5190 on the MC server. These socket connections are persistent for the duration of the session. A session is defined as a connection interaction between a client and a server. Most of the sessions are basically stationary between the client and server unless there is a print job destined for the remote printer associated with the client. When a session starts, the client sends a number of session parameters to the client to establish a connection session.

Types of data transfer supported This section briefly describes how job request data is processed and transferred to each component. The basic job request process flow can be summarized in the following operations. 1) Upload the input file data to the message center, 2) The MC identifies the appropriate print service for rendering the output image based on the identified destination output device, and 3) The MC PS Or the PS accesses the file by reference, 4) the PS renders the output image, 5) the PS forwards the output image to the MC, or stores the output image in a common repository, 6) The MC sends the output data to the RDC or causes the RDC to access the file by reference to the common repository. Depending on the actual job request source and destination, the staging MC may need to bridge the data transmission. There are two types of transfer, “by reference” and “by buffer”. In general, transfers by reference appear to be more efficient than transfers by buffer (because there is less file schooling), but from different components located in different parts of the network due to security constraints (eg firewalls) This may not be possible if the mutual references cannot be confirmed. In such a case, transfer by buffer is the only option for data transmission. The following table defines the types of data transfer.

MC (DMZ) -RDC (public) in the zone . The purpose of this type of communication is to send a print request from a DMZ MC to a device connected to an RDC in a public network registered with the same MC in the same DMZ in the same zone. For example, MC12 → RDC14 transfer.

  Referring to the flow diagram of FIG. 24, the process begins at block 160 where the user connects to the user's home message center and performs a login operation. At block 162, the user submits a print request via the user interface corresponding to the originating device with which the user is connecting to the system. If the print request corresponds to print by reference (PBR), the MC is designated via the UI at block 164 and includes source data (eg, containing source data) from a remote store informed by the PBR request. Upload input file). If the print request corresponds to a non-PBR request (ie, the source data to be printed is located at the originating device), the MC uploads the source data from the device through a buffer at block 166.

  Next, the MC identifies an appropriate print service and sends a job drawing request at block 168. In general, a suitable print service corresponds to a PS that is in the same zone as the destination output device and provides print service support for specific characteristics of the destination output device and source data (eg, driver support for the output device). And provide an application that can be executed to generate image output data corresponding to the source data). If the request is PBR, the MC sends a reference to the print service at block 170 that identifies the storage location of the input file on the network. If the request is not PBR, the MC sends the input file to the PS via a buffer at block 172. After retrieving or receiving the input file, at block 174, the print service generates output image data (output image file).

  If the repository is used, the PS stores the output image file in the repository at block 176 and transfers the output image to the MC by reference at block 178. In this case, the output image data is stored in a file in the repository, and transfer by reference means that the PS sends the path, file name, and network location of the output image file to the MC. If the repository is not used, the PS transfers the output image to the MC through a buffer at block 180.

  At this time, at block 182, the MC identifies an appropriate remote desktop client to receive the output image. This is typically done through a database lookout based on the destination output device and identifies an RDC that can be used to submit the output image to the destination output device. The MC then sends the output image by reference to the identified RDC at block 184. After receiving this reference, the RDC retrieves the output image and, at block 186, submits to the output device and renders with the output device. When information is obtained that the job has been successfully printed, the MC sends a notification back to the user to inform the user that the print job has been printed successfully. In short, at block 188, the process can be expressed as (UBR, UBB) → (DBR, DBB) → (TBR, TBB) → PBB.

MC (DMZ) -RDC (DMZ) in the zone . The purpose of this type of communication is to send a print request from a message center located in the DMZ to a device connected to an RDC in the same DMZ registered with the same MC in the same zone as that MC. (For example, MC12 → RDC13). The corresponding simple notation is (UBR, UBB) → (DBR, DBB) → (TBR, TBB) → (PBR, PBB).

MC (DMZ) -RDC (private) in the zone . The purpose of this type of communication is to send a print request from a DMZ MC to a device connected to an RDC in a private network registered with the same MC in the same zone (eg, MC12 → RDC12). . The corresponding simple notation is (UBR, UBB) → (DBR, DBB) → (TBR, TBB) → (PBR, PBB).

In-zone MC (private)-RDC (public) . The purpose of this type of communication is to send a print request from a private MC to a device connected to an RDC in the public network registered with other MCs in the DMZ in the same zone (eg, MC11 → RDC14). The corresponding simple notation is (UBR, UBB) → (DBR, DBB) → (TBR, TBB) → SBB → PBB.

In-zone MC (private) -RDC (DMZ) . The purpose of this type of communication is to send a print request from a private MC to a device connected to an RDC in the DMZ registered with another MC in the same DMZ in the same zone (eg, MC11 → RDC13). The corresponding notation is (UBR, UBB) → (DBR, DBB) → (TBR, TBB) → SBB → (PBR, PBB).

In-zone MC (private)-RDC (private) . The purpose of this type of communication is to send a print request from a private MC to a device connected to an RDC in the private network registered with the same MC in the same zone (eg, MC11 → RDC11). . The corresponding simple notation is (UBR, UBB) → (DBR, DBB) → (TBR, TBB) → (PBR, PBB).

MC between zones (DMZ)-RDC (public) . The purpose of this type of communication is to send a print request from a DMZ MC to a device connected to an RDC in the public network that is registered with other MCs in the external DMZ from different zones (eg, MC12 → RDC24). A corresponding simple notation is (UBR, UBB) → (DBR, DBB) → (TBR, TBB) → PBB.

Interzone MC (DMZ) -RDC (DMZ) . The purpose of this type of communication is to send print requests to devices connected to RDCs in different DMZs registered in other MCs in the same external DMZ from different zones (eg, MC12 → RDC23). A corresponding simple notation is (UBR, UBB) → (DBR, DBB) → (TBR, TBB) → PBB.

Interzone MC (DMZ) -RDC (private) . The purpose of this type of communication is to send a print request from a DMZ MC to a device connected to an RDC in a private network registered in another MC in a different DMZ from a different zone (eg, MC12 → RDC22). A corresponding simple notation is (UBR, UBB) → (DBR, DBB) → (TBR, TBB) → PBB.

Interzone MC (private)-RDC (public) . The purpose of this type of communication is to send a print request from a private MC to a device connected to an RDC in a public network registered with another MC in a different DMZ from a different zone (eg, MC11 → RDC24). The corresponding simple notation is (UBR, UBB) → (DBR, DBB) → (TBR, TBB) → SBB → PBB.

Interzone MC (private) -RDC (DMZ) . The purpose of this type of communication is to send a print request from a private MC to a device connected to an RDC in the DMZ registered in another MC in the same external DMZ from a different zone (eg, MC11 → RDC23). The corresponding simple notation is (UBR, UBB) → (DBR, DBB) → (TBR, TBB) → SBB → PBB.

MC between zones (private)-RDC (private) . The purpose of this type of communication is to send print requests from private MCs to devices connected to RDCs in different private networks registered in other MCs in different external DMZs from different zones. (For example, MC11 → RDC22). The corresponding simple notation is (UBR, UBB) → (DBR, DBB) → (TBR, TBB) → SBB → PBB.

System Hardware Multi-Layer Architecture In one embodiment, a four-tier architecture design is used to implement the system, as shown by multi-layer architecture 200 of FIG. The first layer of this architecture includes a web server farm (WSF) 202, the second layer includes a message center farm (MCF) 204, and the third layer includes a print service server farm (PSSF) 206. The fourth layer includes a database server farm (DBSF). Below, each layer is demonstrated.

Tier 1 Web server farm (WSF) . This layer consists of a load balancer (LB) 208 and a web server farm 202. The load balancer receives incoming requests and distributes them to one of the web servers in the web server farm. Since Web servers share the same URL, the user only has to remember one URL to access the system. The distribution of requests depends on the configuration of the load balancer 208. The load balancer handles Web server location and request dispatch. The assigned web server executes the script locally and invokes a common database access interface to the corresponding database server farm, thereby enabling NFS (Network File System) or SAN (Storage Area Network) ) Update the database 210 stored in the device 212. In addition, the load balancer can send a warning message to the administrator to indicate that an error has occurred in the web server farm.

Tier 2 Message Center Farm (MCF) . The message center farm contains two running copies of the message center software component. One includes a primary MC 214 running in processing mode, and the other includes a secondary MC 216 running in standby mode. The primary MC always responds first to incoming requests. If the primary MC does not respond, the secondary MC switches to processing mode and processes the request. A warning message is then sent to the system administrator to indicate that there is an error. This failover switch is performed automatically without human intervention. When the problem is solved and the primary MC comes back online, the secondary MC automatically returns to the standby mode and informs the primary MC of the takeover.

  The system supports automatic failover switches by implementing a “heartbeat check” between the primary MC and the secondary MC. For this implementation, each MC is equipped with two Ethernet interfaces and one serial port. All four Ethernet interfaces are connected within the same subnet and the serial ports are connected to each other. After installation, the MC is assigned the same floating IP address of one of the Ethernet interfaces (floating interface) and a different static IP address of the other interface (static interface). The primary MC activates both Ethernet interfaces at system startup. However, the secondary MC only launches a static interface to avoid conflicts. The secondary MC checks whether the primary MC is available by sending a test packet over the static interface. If the floating interface of the primary MC is not reachable, as a guarantee, check again using the serial port to which the secondary MC is locally connected to find out the details of the problem. Next, the secondary MC brings up the floating interface, processes the incoming request, and sends a warning message to the system administrator. In the meantime, the heartbeat inspection is continued to detect whether or not the primary MC has been restored. When the primary MC comes back online, the secondary MC stops the floating interface and sends a request to the primary MC to bring up the floating interface. In order to confirm that the secondary MC is always in the standby state, the primary MC performs the same check on the secondary MC. However, if there is a problem with the secondary MC, a warning message is sent to the administrator. Just send it to. The heartbeat check continues as long as the system is up and running. Set heartbeat intervals to fine-tune system reliability and performance.

Layer 3 Print Service Server Farm (PSSF) . This layer consists of a load balancer 218 and a print service server farm 206. The load balancer receives incoming requests from the message center farm 204 and distributes them to one of the print service servers in the PSSF 206. The MCF always accesses the print service using the same destination IP. The distribution of requests depends on the configuration of the load balancer 218. The load balancer handles the print service server location and request dispatch. The assigned print service server processes the rendering request, stores output image data in the shared NFS or SAN device if necessary, and then sends the result back to the MCF. In addition, the load balancer can send a warning message to the administrator to indicate that an error has occurred in the print service server farm.

Tier 4 database server farm (DBSF) . This layer consists of two database server farms, including a message center database server farm (MCDSF) 220 and a print services database server farm (PSDSF) 222. These server farms are connected to NFS servers or storage area network (SAN) servers 224 and 226, respectively, and host the databases 228 and 230, respectively.

  The database server farms implement each other's heartbeat checks in the same manner as described above for the tier 2 message center farm. However, some advanced commercial database systems incorporate server failover switches. In such a case, the reliability can be maintained even if the “server farm heartbeat survey” is not implemented.

Scalability . Creating more running instances in tier 1 and tier 3 can expand the entire system. Even with an optional load balancer in Tier 2, the system can be fully expanded. In such a case, the heartbeat check mechanism is not necessary because the load balancer can be assigned the role of ensuring the accessibility to each component.

Security . Adopting a modular architecture design and an extensible database schema, you can implement advanced security. First, for user authentication, the subscriber database includes a user profile that is used to verify that user login to the system is valid when performed through a supported device. If this verification fails, a record is stored in the system for later reference or investigation and the login request is rejected. In addition, the message center can implement public key infrastructure support for higher levels of client and server authentication. Second, with data encryption support, each module can implement encryption to protect the content data. Encryption can be done from the file store to the message center, from the message center to the print service, from the print service to the output image repository, and from the file image repository to the RDC. Certainly, too much encryption can degrade overall performance, and insufficient encryption can endanger user data. Third, in a non-rejection implementation, the system assigns each subscriber a unique ID. When a user submits a request to the system, the user's ID and time stamp are tagged as a tag as soon as the request is submitted. If this is a job submission request, a replica is generated in the system and logged and archived for later reference and billing.

  In addition to the security implementation described above, another advantage of the modular distributed architecture of the system is that the administrator can customize security settings based on organizational needs. For example, a virtual private network (VPN) can be implemented as a standard setup between a shared file server and a message center. Similarly, VPN can be implemented between a message center and a remote desktop client. The system architecture supports both software and hardware VPN configurations. The entire system can provide a public key infrastructure, provide authentication and certification, protect data integrity and data privacy, and meet non-repudiation requirements.

Message Center The Message Center provides public access (eg, over the Internet) and includes one or more network connection servers that implement an RDBMS (relational database management system) database. . Referring to FIG. 26, in one embodiment, the message center MCn is hosted by a UNIX server 232. In general, various server classes can be used as message center hosts, such as servers running operating systems such as UNIX, Microsoft Windows Server, and Linux. The server is preferably implemented as a redundant component such as a RAID 5 disk subsystem and high availability hardware.

  Message center MCn includes an RDBMS database 228 in which data relating to the operation of the message center and other system components is stored. In general, the host of the RDBMS database is SQL RDBMS database software, such as Oracle (for example, 8i or 9i), Microsoft (for example, SQL Server 7 or 2000), IBM (DB2), Informix, Sybase, etc. Vendors are selling. The current implementation uses a MySQL RDBMS that utilizes network socket connections and PERL and C programming APIs. Optionally, the host of database 228 may be a non-SQL RDBMS.

  Each message center further comprises various software modules that handle the tasks described above with reference to FIG. These include message handler 234, table update handler 236, table maintenance operation 238, and print service communication channel 240. In addition, the message center includes a web server component for interfacing with web traffic. In one embodiment, an Apache web server is used with PHP4 server and SSL server extensions and associated CGI applications to support remote server maintenance and management as well as print service communication operations.

  Message handler 234 runs as a service bound to a specific network port (eg, system port 5190). Remote desktop clients are connected to the message center using this port and maintain a persistent connection for the duration of the session. Communication between the message center and the RDC is connection-oriented, and each session consists of a specific phase using a network message protocol. Communication between the message center and the remote desktop client begins when the RDC initiates the session startup process and is either unexpectedly disconnected (the network connection is lost or the RDC host machine (eg PC) shuts down) Or when an RDC application abnormally terminates and an error occurs in the RDC) or when the RDC initiates a session termination process.

  The table update handler (TUH) 236 consists of a set of database methods written in the native API of the RDBMS system (for example, in the case of the MySQL RDBMS implementation, an API of C language or PERL language is used, and an Oracle For RDBMS implementations, use PSQL stored procedures). The methods in this module consist of functions for modifying the resource status of the remote printer, functions for adding, deleting, and modifying the wireless subscriber profile, updating the print service job queue management table, and various other functions.

  The Table Maintenance Operations (TMO) module 238 generates a series of individual database operations that generate logs and reports, periodically purge the tables, and perform maintenance functions necessary to resolve database table problems. Is provided. Some of these functions are performed ad hoc, while other functions are scheduled to be performed periodically, for example, hourly, daily, or weekly. Some functions of this module are available through the CGI interface (or SSL) on port 80.

  Print service communication channel 240 implements a message channel for access to the message center by the print service component. Using this channel, the print service in the system can connect to the message center and update the job queue management status. In one embodiment, this channel is implemented by a message center port 80 or SSL port and the API with messaging functionality includes a CGI script.

Database Schema In general, the Message Center RDBMS schema consists of three separate databases, such as Remote Printer Resource Management (RPRM) Database 242, Job Print Queue Management (JPQM) Database 244, and Wireless Subscriber (SUB) Database 246. including. The RPRM database includes tables related to printer resource registries, RDC processes, and printer asset management. The JPQM database includes a table related to submitting print jobs processed by the print service. The wireless subscriber database includes tables related to wireless subscribers.

SUB database table
Subscriber table . This table contains specific information about the wireless subscribers in the system. The subscriber fills in the fields in this table in a one-time registration procedure. The field corresponding to the description beginning with “HTTP_X_UP_DEVCAP” contains the value of the device function returned from the wireless device in the HTTP GET header defining some functions of the wireless device. The SUB_NO field describes a unique subscriber number associated with the cellular number entered by the subscriber during registration and is used to identify the subscriber for all sessions. The index field SUB_ID is unique for each record, and is used to reference (that is, link) a NETWORK_SITES and a PRINTERS table described later.

Network site table . This table includes a plurality of fields that define network sites added by the subscriber, and also includes login information for each site.

Printer resource table . This table contains several fields of information needed to define printer resources for a particular subscriber.

RPRM database table master printer resource table. In this table, the remote printer resource configuration and status information of the entire system are described for each print resource registered on a specific message center.

Zone descriptor table . This table defines the parameters of the zones defined in the system-wide network. Records in this table are referenced by zone identifier (ZID) values. The ZONE_DESC descriptor, the ZONE_TYPE, and the STATUS fields describe the characteristics of the zone.

Message Center Table (MCT) . This table contains information used to reference the message center in the system. These processes are identified by a message center identifier (MCID), and the value is a unique value that affects the entire system. Note that for all PUBLIC resources, there is a master message center that is always referenced with an MCID equal to 0, and the MCID value for all other message centers is a non-zero positive number. The MCT includes information identifying the message center ZONE and network address. Note that the master message center's ZONE identifier (ZID) is equal to 0, and all other message center MCID values are non-zero positive values.

Client descriptor table . This table defines individual clients related to remote printer resources. Records in this table are referenced by a client identifier (CID). Client attributes are defined in the CLIENT_DESC, CLIENT_TYPE, name and address fields. The information stored in this table is generated when performing the registration process when an individual installs desktop client software or installs on a PC behind a corporate firewall. The print job queue information includes a CID identifier that associates the client process with the job to be printed.

Job print queue management database table
Print service table . In this table, registered printing services installed in the network are described. Records in this table are referenced by MPID identifiers. (In the current implementation, the print service servers are called “MAGICPRINT” ™ servers, and therefore use the identifier name MPID. These print servers are referred to in this specification as driverless Also called Print Server (DPS).) Define attributes for each print service using name descriptor, IP address, status, and server descriptor string fields. Note that it is entered for each type of driver on the print service server. For a particular locally located server, the ZID identifier is used to reference the associated zone.

Print queue table . This table manages network printer queues. Each record in this table represents a single print job referenced by a QID identifier. The overall system design facilitates the delayed print job function and tracks job queue entry and exit dates and times with the QDATE and DQDATE fields. Most of the identifiers in this table are copied from this table to the JOB queue log table after the print job is processed. The DRIVERDESC string is referenced by the type of printer driver used to process the document and the PID identifier, and defines the remote printer resource associated with the desktop client referenced by the CID identifier Is included.

JOB queue LOG table . The job queue LOG table includes information for recording a processed print job in a log. Jobs in this log are referred to by JOB log ID (JID) values. Fields are transferred from this print queue table to this table. The print service server is referred to by the MPID identifier. The client used to print the job is referenced by a CID identifier. The remote printer resource associated with the CID is referenced by the PID identifier. Further, a JOB owner descriptor character string is described to identify the sender of the print job.

  A detailed description of one embodiment of the software components used for the print service PSn is shown in FIG. The software components are logically divided into four groups including a setup component 300, a message center communication interface 301, a domain processing component 302, and a management component 304. Each of these components further includes one or more software applications, scripts, components, and / or modules. The setup component 300 includes a print setup module 306 and an account wizard module 308. Message center communication interface 301 includes a print server to message center communication channel 310. The document processing component 302 includes a CGI script 311, a driverless print server component 312, a port monitor 314, a status monitor 316, and a preview module 318. The administrator component 304 includes a system monitor 320, a management (control panel) web page 322, an automatic extension module 324, and an automatic update module 326.

  In one embodiment, the printer setup module 306 includes a Microsoft (MS) Windows application that is executed by a system administrator to change the configuration of the Windows printer used in the system. This application can be used to convert an existing printer, install a new printer, or delete a printer. In converting an existing printer, the existing printer is installed and the operation provided by the MS Windows port monitor is replaced by the port monitor 314. Using port monitor 314, the spool file is manipulated by the DPS system so that status monitor 316 can send the spool file to the selected destination output device.

  The print setup module 306 can also be used to install a new printer with an appropriate printer device driver. For example, an administrator can set up a PostScript printer by using the printer's PostScript printer description (PPD) file, installing the Adobe PostScript ™ driver, and using it in the DPS system. If the administrator can prepare the PDD, the setup module installs the PostScript driver and configures it for use in the DPS system. In other cases, the administrator provides the appropriate printer device driver software for the new printer. The printer setup module 306 can also be used to delete a printer. In such cases, the Windows port monitor can be restored as the system port monitor, or the DPS server support for the selected printer can be completely removed.

  The account wizard module 308 applies security to a set of administrative web pages 322 so that the administrator can log in and determine the set of web pages that can be accessed. In one embodiment, the system implements three types of management levels: monitor, manager, and management level. In one embodiment, the account wizard creates these three groups as MS Windows user groups. In addition, the account wizard creates MS Windows user accounts and places them in one of the administrative user groups. In one embodiment, the account wizard module 308 is an MS Windows application.

  By using the communication channel 310 from the print service to the message center, communication can occur between the print service and the message center. Communication includes print service registration and deregistration, job drawing request, job print request, device registration and deregistration, device status query, and the like.

  A detailed description of the CGI script 311 is shown in FIG. A “cancel print job” CGI script 328 is used to delete the print job request from the system. From the administrative web page 322, a script can be invoked for any print job that has been submitted to the system and whose spooled file has not yet been sent to the printer. You can also call this script from the message center.

  The auto-extension configuration CGI script 329 searches for installed applications on the print service host, finds document types that can be supported by the found application, and can execute print job requests for the found file types. Configure the print service. By transferring this information to the message center, the resource configuration information can be updated. The system update CGI script 330 is used to compare installed system components with the latest available components, download new components (if applicable), and install them on the PS host.

  The print request CGI script 331 receives source data (eg, a document file, graphic image file, or URL) from the message center as input and creates a print job request that is processed by the print service. The job queue CGI script 332 reads the print job request queue from the system and returns the list to the caller of the script (eg, MC). The “Preview CGI” CGI script 333 receives a document file, graphic image file, or URL from the message center, and creates a print job request on the system in the same manner as the print request CGI script. However, when the preview CGI script is invoked, the system converts the document, image, or web page into a form that can be displayed on the originating device's user interface rather than sent to a printer for printing. The preview CGI script can be called again for a document, image, or web page to instruct the system to send the previewed item to the selected output device.

  The reset CGI script 334 closes the system application and starts again. This script is used by the system administrator as a last resort to clear a program error if it occurs. The status CGI script 335 displays a management Web page 322 indicating the progress status of the print job request.

  The components implemented by the driverless print server 312 are shown in FIG. The driverless print server is the main software component used by the print service. This is an application that runs on a print service host (ie, a server computer) that accepts job requests, queues the requests, and directs the printing process of the document, image, or URL from the request to the final print including. The driverless print server component includes a file type configuration list 336, a browser print component 337, an auxiliary application print component 338, a shell extended print component 339, a print preview component 340, a job request server component 341, and job processing. There are a component 342, a window processing component 343, and a job status component 344.

  The file type configuration list 336 is maintained by the driverless print server. The configuration list describes, for each file type, the extension and the method used to print the file type. If the auxiliary application printing component 338 provides a printing method, the list includes the path to the application used for printing, the menu command that the application uses for printing, and the menu that the application uses to close the application. -Commands are included.

  The browser print component 337 includes one of three methods used by the driverless print server to generate output image data. In one embodiment, this component uses an application programming interface (API) provided by a Microsoft Internet Explorer (IE) web browser. The component uses the IE API to run the browser within the driverless print server application window. To print the URL, the driverless print server loads the web page into the window using a provided navigation programming interface. After the page is loaded, the component instantiates the print operation using the IE that provides the print programming interface.

  If the IE browser instance on the DPS server computer is configured to use a browser plug-in that corresponds to the type of document or image file requested, use this method to・ Files can be printed. For example, consider an IE plug-in for Adobe Acrobat ™. The extension of the Adobe Acrobat document file is PDF. If the Acrobat plug-in is installed on the server computer, the IE navigation programming interface can load the PDF file into the IE and the IE print programming interface can print the file.

  The auxiliary application printing component 338 provides another method used by the driverless print server to generate output image data. This component uses the file type configuration list 336 to find the application associated with that file extension, loads the file into the application, executes the application's print menu command, and after the print operation is complete, Close. The combination of file type composition list and auxiliary application printing method allows the system administrator to add support for additional documents or image types by installing the application on the server machine and editing the file type composition list be able to.

  The shell extended printing component 339 comprises a third method that the driverless print server uses for printing. This component prints using the MS Windows Shell Extensions programming interface. The MS Windows Shell Extensions interface is a feature of the operating system that allows a user to print a document type using commands sent to an application that supports that document type. If the application supports the Shell Extension interface, it loads the document, prints it, and automatically closes it. The combination of file type configuration list and shell extended printing method allows the system administrator to add support for additional documents or image types by installing the application on the server machine and editing the file type configuration list 336 can do.

  The print preview component 340 converts the requested document, image, or URL of the print job into a document format file so that the consumer user can display an example of the requested document, image, or URL. This component operates in cooperation with the preview CGI script 333. One of the conversions performed by the driverless print server relates to the Adobe Acrobat document format. By using the print preview component, the driverless print server creates a spool file in the same way as it creates a spool file for printing. However, instead of sending the spooled file to the status monitor 316 for sending to an output device or repository, it executes the spooled file through the Adobe Acrobat Distiller application that converts the document to Acrobat PDF format. This conversion requires the printer driver to be an Adobe PostScript driver. The driverless print server holds the spool file created by the preview process so that when the consumer user wants to print the document, the DPS simply sends the spool file to the status monitor 316 Just send the spooled file to the printer and print it.

  The job request server component 341 receives a print job request from the print request CGI script 331, and queues it for processing. The job processing component 342 manages the print job request from when it is inserted into the job queue until when the output image data spool file is generated. This component reads queued job requests, determines one of three printing methods to use for printing, submits a document, image, or URL to the determined printing method, and Process the run and submit the spooled file to the status monitor for storage. At each stage of the output image generation process, the status is tracked, and if the status CGI script 335 can be called, the status is made available from the call.

  The window processing component 343 is used to perform reliable printing. Many applications display message boxes and / or dialog boxes during the printing process to provide information to and collect information from users requesting printing services. Supporting automatic processing of print requests requires a mechanism that responds to message boxes or dialog boxes when they are displayed in the application used to print the request. This mechanism is provided by the window processing component 343. The driverless print server monitors the server for message boxes and dialog boxes that are displayed during the printing process. When a new message box or dialog box is displayed, the windowing component reads the information, compares it with a known message or known statement, and follows the programmed logic for the message box or dialog box Close. Details of the window processing component will be described below with reference to FIG.

  A job status component 344 is provided to maintain a memory mapped file for all jobs in each driverless print server queue. Periodically, job status information is written to a memory-mapped file so that the status CGI script can read the status of the job request.

  The port monitor includes standard components within the MS Windows printing subsystem. The port monitor receives spooled data from the printer driver via the printing subsystem. A conventional boat monitor is given a role of receiving spooled data from a printer driver and delivering it to a printer. In the driverless print server, the port monitor module 314 (FIG. 27) writes the spooled data to a file. When the entire spooled file is written to the file, the port monitor module 314 sends a message to the driverless print server with the name and location of the spooled file.

  The status monitor 316 includes an application that runs on the server computer. It performs multiple functions, but is primarily responsible for sending spooled files to the printer. After receiving the message indicating the spool file location from the port monitor 314, the driverless print server transmits the spool file location, the spool file destination printer URL, and the spool file to the printer. A message indicating the protocol information is sent to the status monitor 316. The status monitor 316 creates a queue for each requested printer URL. Since the printer can only receive one spool file at a time, it serializes the transmission of the spool file. The status monitor 316 can create and maintain multiple queues simultaneously.

  After the output image is successfully generated, the status monitor 316 informs the driverless printer server with a message that the job is complete. The job history is updated and the job is deleted from the driverless print server queue. The status monitor 316 can be configured to send messages to external components when and / or after generating the output image. For example, it can be used to notify the message center that initiated the print job that the output image corresponding to the print job is complete.

  The system monitor component 320 includes an application that monitors all other print service components, checks for errors, and monitors for incoming specific requests. When a print job request arrives from the print request CGI script 331, if the driverless print server application is not operating, the print request CGI script activates the driverless print server to the system monitor 320. And request to process the print job request. The system monitor 320 periodically sends a message to the driverless print server to obtain the status of the program and the print job in the queue. When the system monitor detects an error, it tries to resolve this problem.

  The system monitor 320 can also be used to download and install newer print service system components. Collect the version numbers of all components in the system and send them to the system's update website. In the update Web site, when returning with information about whether newer components are available, these components are retrieved and installed in the system. The system monitor accepts an update request from the menu or from the “update system” CGI script 330.

  On the management Web page 322, an administrative user can execute remote configuration and monitoring of the system. Security functions are used to prevent consumer users from accessing these web pages.

  When a file is submitted for output image generation, the driverless print server opens an application corresponding to the file type of the file. For example, the file extension is. If it is doc, the MS Word application is generally opened. The application then opens the file and uses the built-in print command to send the submitted file to the selected printer. On the extension web page (not shown), in the row (entry) that lists the file type information (in the "Extension" column) and the file type (in the "Application Name" column) The corresponding software application is displayed. Each entry also has an extension priority level (defines the order in which file types with the same extension are evaluated to determine the appropriate application for the submitted file) and stores OS registry information about the application. The registry location that identifies the destination, the default path of the application, the executable name of the application, and the internal code for printing the application and closing the application are displayed. The administrator can activate the “Add New Entry” button to add a new file type, which is used to display the web page (shown in the figure) with the corresponding edit control in each column of the previous web page. Not draw). Users can also update file types and edit existing file types.

  Driverless print servers are installed on the server computer used to print files of each file type listed in the extension table using the extension table corresponding to the file type value. Determine which application is running. Furthermore, the location of the executable file of the print service server computer is determined using the information contained in this table. In one embodiment, an extension table and various other configurations and print job data are maintained in the database. Typically, the database is hosted on the same machine that hosts the DPS software, but those skilled in the art will appreciate that a different machine can be used as the database host.

Print Request Processing A data flow diagram illustrating the data flow and operations performed by the print service DPS system software component in response to the print request is shown in FIG. Initially, the user of the originating device 350 connects to the system, selects source data to print from either a local store or a remote store, and selects an output device to print the source data in the manner described above. . This information, including user input 352, is received and processed by the corresponding message center to generate print job 353. In general, a print job includes source data or a reference to the source data and identifies whether the output image generated by the print service is stored in a repository or directly submitted to an output device. The print job is first processed by the print request CGI script 331, whereby tmpdoc. Including the print parameters and other data corresponding to the print job. A dpsn document 354 is generated. Then, tmpdoc. The dpsn document is sent to the job queue 356 by the print request CGI script. In one embodiment, the job queue includes a first-in first-out (FIFO) type job queue. Optionally, other types of job queues can be used, as will be understood by those skilled in the art. As described above, job queue operations are performed by the job processing component 342.

  Job requests submitted by the job queue are processed by the print service. tmpdoc. Parse the dpsn file and retrieve the print job parameters corresponding to the print request stored in the document file 360, each request being processed by block 358. For example, the analyzed information includes printer selection, number of copies, consumer user ID, document name, message center submitting a print job, and the like. Some print job parameters are stored in the DPS database 361.

  At decision block 362, it is determined what type of document was requested to be printed, eg, an application file, an image, or a URL of a web page. If the document relates to a viewable document, such as a web page, image, or PDF file, the logic flow enters block 364 where the web page, image, or PDF document is passed to the driverless print server browser. Loaded through. Otherwise, the logic flow enters block 366, where a document and a suitable auxiliary application that can be used to print the document are loaded. For example, if the document contains an MS Excel spreadsheet, an instance of the MS Excel application is loaded with the Excel document. At block 368, an internal command is generated that simulates a user requesting a print operation requesting that a URL, image, or document be printed by either the browser or an auxiliary application. For example, most applications have a “File” → “Print” menu option that launches the application's printing process.

In response to an internal application or browser print request, various print and document information is internally passed to the operating system component that handles the printer operation. As described above, in one embodiment, the driverless print server operates in an MS Windows OS environment. Thus, this environment is a graphical device that communicates with the printer device driver 372 corresponding to the selected printer that generates the appropriate printer (ie, output device) data that is sent to the target printer 374 to generate the output document. It comprises an OS printing subsystem 369 that includes an interface (GDI) component 370. The printer data is processed internally by the MS Windows print spooler component 376 that outputs the print spool file received by the port monitor 314. In the example shown in the figure, it is assumed that the destination output device D _DEST includes a PostScript printer. Therefore, the port monitor 314 outputs a PostScript file 378.

  While the above operations are in progress, the user of the originating device 350 can choose to preview the simulated printed output of the document, image, or web page before printing the source document. At decision block 380, it is determined whether the user has made a request to preview the printer output. If the answer is “yes” (TRUE), in one embodiment, an instance of Adobe Acrobat Distiller 382 is launched and used to generate an Adobe Portable Document Format (PDF) document 384. The PDF document is processed by the preview CGI script 333 and sent back to the originating device 350 via the message center MCn, where it is rendered by the Adobe PDF plug-in on the browser running on the originating device. The rendered display (not shown) is a preview of what the printed document will look like, and a laser interface for the consumer user to choose whether to print or cancel the document (UI) control.

If the consumer user wants to print the document, a print notification is sent back to the message center MCn where it is processed by the preview CGI script 333. In response to the receipt of the print notification, the preview CGI script 333 activates the status monitor 316 and sends the print document 378 to either the destination output device D _DEST or the output repository 78 according to the output image data transmission destination. Submit to Along with this event, the job history information in the DPS database 361 is updated. Further, after the output image is printed, a print completion notification 380 is sent back to the status monitor 316 where the notification is forwarded as a job status message 381 to the message center MCn.

If the print preview option has not been selected by the consumer user, the answer to decision block 382 is “no” (FALSE), the status monitor 316 is launched, and the print document 378 is sent to the destination output device D _DEST or output. Submitted to repository 78. During the printing process, the status monitor 116 monitors the progress of the process and updates the DPS database 361. Use status CGI script 335 to retrieve progress information from the database, as indicated by job status message 381, generate appropriate HTML, and send it back to the message center that submitted the corresponding print job. To supply the print status information to the message center.

  In one embodiment, the driverless print server supports direct printing of printer files. For example, if the print job file includes a printer file, it can be printed directly if it corresponds to the printer file type of the destination output device. For example, a PostScript file can be output to a PostScript printer. Similarly, printer files for other types of printers can be created in advance by selecting the “Save to File” option in the printing process. If the decision block 362 determines that the file is a printer file, the logic proceeds to block 367 where the printer file (shown as printer file 367) is sent directly to the Windows print spooler 376. Is done.

  If the output image is stored in the output repository 78 instead of being sent to the output device, the status monitor 316 may send a job status message 381 as indicated by the output image file reference 386. Use to send a message to the message center MCn indicating that the output image file corresponding to the print job is stored in the repository along with the name and location of the output image file.

  Details of the internal operation of the driverless print server software 46 are shown in FIG. As before, the consumer user operating the originating device 350 may receive source data (eg, document, image, etc.) via a user interface appropriate for the originating device (eg, mini-browser UI 107 or browser UI 124). Request printing of file or web page). In response to activating the “Print Now” button on the appropriate UI page, the user input data is processed by the print request CGI script 331 and tmpdoc. A dpsn document 354 is created. The print request CGI script further pipes a message containing the print request to the new job pipe server 390 and stores the message in the message queue 392. For each print request message, the message queue handler 394 displays the corresponding tmpdox. The corresponding thread that parses the dpsn document 354 is activated, generates a document file 360, and submits the print request to the job queue 356.

  As shown in Start Job Queue Loop block 396 and End Job Queue Loop block 397, the following operations and logic displayed between these loop ends are performed on the print job: The First, at block 398, the next job is retrieved from the job queue 356. At decision block 400, it is determined what type of document the print job corresponds to. If the document is an application file, the logic proceeds to decision block 402 where it is determined what type of file type should be used as the printing method. If the file requires an auxiliary application (eg, MS Word, MS Excel, AutoCAD, etc.), the logic proceeds to block 366 where the document and the appropriate auxiliary application are loaded as described above. When the file is loaded into the auxiliary application, a file print command is generated internally in block 368, submitting the file as before, and leaving it for printing by the OS.

  Next, at decision block 404, it is determined whether a “done” message has been received from the port monitor 314. This determination is performed periodically or by a software interrupt mechanism until a “complete” message is received. Thereafter, the status monitor 316 is activated at block 406 to send the print document 378 to the target printer 374 and the job history data in the DPS database 386 is updated as before.

  Returning to decision blocks 400 and 402, the document type is a web page or printing directly by a driverless print server computer without an auxiliary application (eg, PDF document or various types of image files). If the file type can be, the logic proceeds to block 364 where the browser on the DPS computer navigates to the URL of the web page or uses the browser in some other way to convert the PDF or image file. indicate. Once rendered, the remaining printing operations are performed in the manner described above, starting at block 368. As described above, if the document type is a printer file, the document is sent directly to the Windows print spooler 376.

  A flow diagram illustrating the logic and operations performed by the window processing component 343 is shown in FIG. A windowing thread is activated at the beginning of decision block 362 immediately after the print action is invoked at block 368, as shown in start block 450 of FIG. As mentioned above, various dialog boxes and messages that can be triggered when using the windowing component to load an application, load a document into the application, initiate a print action, during the printing process, etc. • Process the box.

  Returning to the flow diagram of FIG. 32, the window processing thread determines whether there are more desktop windows that should be examined in block 452 after activation. Such a window typically comprises a dialog box and a message box. If there are no more windows to examine, the thread terminates as shown in thread termination block 454. If there are more windows to examine, the logic proceeds to block 456 to obtain window information for a window. To obtain window information on the MS Windows operating system, execute the appropriate Windows API call.

  Next, at decision block 458, it is determined whether the window is a child window of the drawing application (ie, whether it was created by an auxiliary application or browser). If the decision is “no”, the window does not respond to the drawing application and the logic proceeds to decision block 452 to evaluate the next window. If the answer to decision block 458 is “yes” (TRUE), the logic proceeds to block 460 where the text and control buttons of the window are examined.

  If the text matches the standard message string as determined by decision block 462, the logic proceeds to block 464 where a "close window" command is provided internally and the user "closes" on the window. Emulates the action of activating the "close window" icon in the "button" or window frame. Thereafter, the logic returns to decision block 452 to process the next window.

  If the text does not match the standard message string, the answer to decision block 462 is “no” (FALSE) and the logic proceeds to decision block 466 where the text is stored in the windowing table 470 in the DPS database 386. It is determined whether or not it matches the MessageText value of the corresponding entry list. If there is a matching value, logic proceeds to block 468 where the data in the matching MessageText value row is retrieved and the table command is issued by issuing a corresponding message to the Windows API based on the parameters given by the data. Execute. For example, a normal entry list row 472 is displayed at the top of FIG. The row stores information related to the Windows API, including MessageID, Wparam, and Lparam values. Using these parameters, the corresponding API is called to perform the intended operation to process the window. When the table command is executed, or if the answer to decision block 466 is “no” (FALSE), the logic returns to decision block 452 to begin processing the next window.

User Account Setup Referring to FIGS. 33-37, the system includes various user interface screens, where the user sets up his account and configures various parameters such as network, printer, fax, contact, etc. be able to. As described above, these UI screens typically include an HTML-based web page that allows wired and wireless network access, and a WAP-based card for devices that access the system via the cellular infrastructure. A setup process involving multiple operations is displayed on the web page 500 of FIG. These operations include a setup start operation 502, a file server access setup operation 504, a favorite printer setup 506, a fax setup operation 508, a contact list setup operation 510, and a setup end operation 512. is there. Prior to setting up the various parameters that can be used through these operations, the user has registered with the system using a standard user authentication scheme with a username and personal identification number PIN.

  A user logs into the system and initiates the setup process by navigating to either an account setup screen or a settings screen. Multiple navigation methods can be used to access various screens, including content described below. During the setup operation, the user determines parameters for one or more file servers that want to access the source data from subsequent user sessions. Web page 500 allows a user to define server names (ie, aliases) and corresponding server addresses in edit boxes 514, 516. The user also enters an account name and password in edit boxes 518 and 520, respectively, and enters a confirmation password in edit box 522. Finally, the user selects a file server type from pull-down list 524. Once all parameters have been entered, the user activates the “ADD SERVER NOW” button 526 and the web page returns the parameters to the message center hosting the web page. These parameters are then stored in a network site table in the message center database 228.

  FIG. 34 illustrates a Web page 500A showing how to display the Web page 500 after the user has added a plurality of servers. As shown in server name column 528, the user can name the server, but the name can be any name (within reasonable length limits, such as up to 32 characters). The network site table refers to the subscriber table via the SUB_ID foreign key and uses the proxy primary key (SITE_ID), so even if multiple users use the same server name such as myServer and home_network, it is confusing Will not cause. However, the server that can be seen by the user is only the server that the user has already registered.

  The user can use either an IP address (eg, 200.222.219.218) or a domain name (eg, ftp.prsip.com) as shown in the host address column 530. Host) address can be identified. The file server type column 532 displays a list of server types of servers added by the user. To make changes to these parameters, an “EDIT” button 534 is activated, and to delete a server, a “REMOVE” button 536 is used.

  After the user has set up his server, the user activates the “NEXT>” button 538, as shown in the web page 540 of FIG. 35, and sets the setup process to the favorite printer setup operation. Go to 506. At this time, two options for selecting a printer (that is, an output device) are displayed to the user. Activating the “SELECT” button 542 allows the user to search for printers in a pre-configured print list, and activating the “SEARCH” button 544 allows one user to search. Alternatively, the printer can be searched via a plurality of input parameters. In general, a pre-configured print list is configured by an administrator with respect to a company or company where the user works through another management Web page group that can only be used by the administrator. The user is presented with a list of printers from which the user can select one or more printers as “favorite” printers.

  When the “SEARCH” button 544 is activated, a web page 546 is provided to the user. In this Web page, a plurality of edit boxes that can be selected by the user for inputting search information are prepared. A "by city" edit box 458, a "by state" edit box 550, and a "by zip code" edit box 552. , “By business” edit box 554, “by printer / nickname” edit box 556, “by printer manufacture” edit box 558, “by printer model” edit box 560, and the like. In response to activating the “SEARCH NOW” button 562, the system will identify a registered printer that can be used by the user and that meets the user's search criteria. Try. For example, an exemplary set of three printers returns the value Washington entered in the “by state” edit box 550 in response to the search criteria. It can then be added to the user's printer list by selecting the printers in the returned list and checking the check box 564 corresponding to each row in the list. Next, the user activates a “FINISHED” button 566 to save the selected printer and return the user to the Web page 540 (A). At this time, the printer already selected in the favorite printer list 568 is displayed on the Web page. The user can delete the printer from the list using the activate button 570 if necessary.

  After the user adds the printer to his favorite list, the user activates the “NEXT>” button 572 and advances the setup process to fax setup operation 508. This takes the user to a series of fax setup web pages (not shown). Using these pages, the user can select a default outgoing fax and configure the cover of the facsimile. The user may then use a set of contact list setup pages (not shown) to select and add contact information when performing the contact list setup operation 510. it can. Using contact information, users can send documents and faxes to people on the contact list with relative ease.

WAP UI Example As described above, in one embodiment, a wireless web-enabled device can be used to access the system via the WAP gateway 110 (FIG. 20). The WAP interface includes a "set of cards" that are similar to HTML-based web pages except that they are encoded in WML and contain significantly less data. In addition, WAP cards are designed to be navigated with a minimal user interface. Referring to the legend of FIG. 38, various WAP cards and operational details corresponding to an example WAP-based user interface are shown in FIGS. 39-52. In one embodiment, a set of CGI scripts are used to automatically generate a WAP card.

  Referring to FIGS. 39 and 40, the user accesses the system with a WAP-compatible device as follows. First, the user accesses his wireless internet gateway in the manner described above. The user then enters the system URL either directly or through a stored link (ie, a favorite link, etc.). A splash screen 600 corresponding to the WAP card 1 is displayed to the user. In the first part of the login, the system identifies the wireless device (eg, using a cellular number or other unique identifier) and a subscriber table in the message center database 228 via a database query 601. Try to find information corresponding to the device using. If the device is recognized, the user has already registered the device with the system. Therefore, a login screen 602 corresponding to the WAP card 2 is displayed to the user. Based on the information already entered in the subscriber table, the user's first name (or other identifier) is displayed on the screen and the user is prompted to enter their PIN. If the entered PIN matches the stored PIN, the user logs into the system. If they do not match, a screen 604 requesting the user to re-enter the PIN is displayed. If the PIN entry fails again, a screen 606 is displayed asking the user whether he wants to send the PIN to the user via email.

  If the user's wireless device is new to the system, the result of the database query 601 is Null and the logic proceeds to the initial input screen 606 where the user enters a username and PIN. If the entered PIN is invalid, a screen 610 prompting the user to enter a new PIN is displayed on the device. If the PIN can be normally input, a confirmation screen 612 is displayed to the user. Referring to FIG. 40, when a user name and PIN are entered, the database query 613 is configured with a subscriber table to retrieve the user's email address. If the user is a new user or no email address is found, the user is requested to enter an email address via screen 614. If an existing user email address is found, the new device's subscriber table entry is updated via database query 616. Alternatively, when a new username, PIN, and email address are entered, a new subscriber record is inserted into the subscriber table via database query 618.

  After the user is verified, database query 622 is used to determine if the user has an already configured network site. If the user has already configured the network site, the logic proceeds to execute the CGI script 3 as detailed in FIG. 41, otherwise the logic is the navigation shown in FIG. Jump to position 5.

  Referring to FIG. 41, in response to the execution of the CGI script 3, a site selection screen 624 is displayed to the user, which places the source data corresponding to the document that the user wants to print. Network sites can be selected. If necessary, the user can also select a new network site setting, in which case the logic jumps to the navigation location 5.

  When the network site is selected, the execution of the CGI script 4 is started, and the network navigation screens 626, 628, and 630 shown in FIG. 42 are generated. Using these screens, the user can navigate the network site and browse the document file that the user wants to print. After the user selects a document, the CGI script 3 is used to generate a screen 632 that displays the network site name and the document file name. In addition, this screen allows the user to select the type of output the user desires via print, fax, and email options 634.

  Referring to FIG. 43, after jumping to the navigation position 5, a setup screen 636 is displayed to the user. Using this screen, users can set up various favorites, including network sites and printers, and determine fax and email information. When the network site option is selected, the user proceeds to the add file server screen 638 where the user can enter a URL in a manner similar to that described above for adding a new network site via web page 500. Alternatively, a new network site can be added by supplying an IP address, username and password. As before, the username and password are related to the particular network being added. After selecting to add to the network site, a confirmation screen 640 is displayed to the user. After the user chooses to add a network site using the “OK” option, the CGI script 9 is executed and entered data via the database query 642 as shown in FIG. Is stored in the network site table, where a screen 644 confirming that the server has been added is rendered on the user's device.

  In response to the selection of the fax option on screen 636, the user is presented with an add fax screen 646 that allows the user to enter a new fax by specifying a name and fax number. After the user selects add fax data, a confirmation screen 647 is displayed and after selecting the OK option, CGI script 11 is executed and faxed via database query 648 as shown in FIG. / Insert a new record into the email table (FET). Thereafter, a screen 650 confirming that the fax data has been added is displayed to the user.

  Similarly, in response to selecting an email option from screen 636, an add email screen 652 is displayed to the user, where the user enters an email name (ie, alias) and email address. Further, when selecting to add new e-mail information, a confirmation screen 653 is displayed. After accepting with the OK option, the CGI script 12 is executed and a new record is inserted into the FET table via the database query 654 as shown in FIG. Thereafter, a screen 656 confirming that the e-mail data has been added is displayed to the user.

  As shown in FIG. 45, in response to selecting the printer option on screen 636, an add printer screen 658 is displayed to the user, where the user refers to Web pages 540, 546 and displays the top page. The printer to be added can be selected by the same search condition as described in the above. After the user chooses to add a printer from the returned selection list, a confirmation screen 660 is displayed, and after selecting the OK option, a new record is inserted into the printer table via database query 662. Thereafter, a screen 664 for confirming that a new printer has been added is displayed to the user.

  Returning to screen 632 of FIG. 41, after selecting a document file, print the document to the selected printer, fax the document to the selected fax machine (with the fax number of the machine), print, The document can be sent via email to a selected email recipient using fax, email option 634. When the print option is activated, the CGI script 13 is activated and the printer selection screen 666 shown in FIG. 48 is generated. On this screen, the user can select one printer from a plurality of printers already added to the user's favorite printer list. After selecting a printer in the list, a configuration screen 668 identifying the document to be printed and the selected printer is displayed to the user. When the OK option is activated, the CGI script 16 is executed as shown in FIG. In accordance with the print request, the corresponding print job is entered into the print queue table via the database query 670 and a job queue confirmation screen 672 is displayed to the user. After the print job is queued, it is processed by the appropriate combination of message center, RDC, and print service, and the document is printed on the selected printer as described above.

  When the FAX option on the screen 632 is activated, the CGI script 14 is activated and a FAX selection screen 674 shown in FIG. 49 is generated. In this screen, the user can select one of several faxes already added to the user's favorite fax list or enter the number of a fax machine that has not been set up in the fax list. Can do. When the user selects to input the latter number, a screen 676 is displayed, and the number can be input there. When the OK option on screen 676 is selected or a preconfigured fax on screen 674 is selected, a confirmation screen 676 is rendered. Selecting the OK option executes the CGI script 16 where the fax job information is inserted into the fax / email queue table via the database query 678 in this case. After the fax job is queued, it is processed by the appropriate message center, which generates fax data that corresponds to the document in a manner somewhat similar to how the print service processes the document for printing. And sent to the destination fax machine based on the fax number.

  The processing of the email request proceeds in a manner similar to a fax request. This process begins by activating the e-mail option on screen 632 and CGI script 15 is activated, as shown in FIG. The CGI script first generates an email selection screen 682 where the user selects an email address and sends the document to a configured list of the user's favorite email recipients, or still You can enter a new email address for someone who is not configured. If the user chooses to manually enter an email address that is not in the list, a screen 684 is displayed where the address can be entered. When the OK option on screen 684 is selected or a preconfigured email recipient on screen 682 is selected, a confirmation screen 686 is rendered. Selecting the OK option executes the CGI script 16 where email job information is inserted into the fax / email queue table via a database query 678 in this case. After the email job is queued, it is processed by the appropriate message center to generate an email message with the selected document file attached, from the recipient's email address or screen 684. Sent to the entered e-mail address. Optionally, the content of the document can be included in the body of the email. Details of the e-mail generation are described in US copending patent application xxxxxxx entitled “METHOD AND SYSTEM TO PRINT VIA E-MAIL” filed on March 21, 2002, which All documents and drawings are incorporated herein by reference.

  Returning to screen 606 of FIG. 39, in response to a request for the user to send his / her PIN by email, the system searches the message center database 228 for the user's PIN and identifies the user by name. An email is automatically generated that identifies and includes the PIN and sends the email back to the user at the email address that the user has already registered. Thereafter, as shown in FIG. 52, the CGI script 17 is executed. If the e-mail message is successfully sent, a screen 688 identifying such is drawn. If an error occurs in the transmission of the e-mail address, an error message corresponding to the screen 690 is drawn.

Document Preview Navigation One of the optional output methods for job requests is document preview. Because the display capabilities are generally limited (eg, small screen, non-standard aspect ratio, low pixel resolution), generate a preview of how the document will look when rendered on the output device It's a tricky job rather than an important thing to do. Furthermore, the required response time of the preview request is considerably stricter than that of the print request. Output management systems address these challenges in two directions. For image files, create dithered thumbnails and adjust the final output size to fit the vertical and horizontal dimensions without losing aspect ratio. For non-image files, convert the file to plain text format without losing the relationship between pages, divide each page into a series of cards, link these cards together by reference, and page navigation vertically Be able to do in both directions and directions.

  The display 700 of FIG. 53 illustrates how this conversion is performed. This process begins with the original image 702. In the first row, a thumbnail 704 is output based on the display capability of the palm device 706, and in the second row, a thumbnail 708 smaller than that is output corresponding to a considerably low resolution of the screen of the cellular 710. . Note that cellular thumbnails do not cover the entire screen to preserve the aspect ratio.

  Display 712 in FIG. 54 describes the text document display conversion process. As described above, the text pages of the output document are divided into WAP cards based on the text flow. For example, the first 256 bytes of the page are converted to the first card (label “1”), the next 256 bytes are converted to the second card, and so on. The image in the original text page is replaced with an image link in the card, as indicated by image link 714 and preview image 716, respectively, to indicate its placement in the original context. The user can use these links to preview images generated based on the image display conversion mechanism described above. This layout can be used not only to page up and down, but also to navigate to another page. Since page relationships are preserved, the user can also preview those pages with random access.

  In addition to sequential text documents, the system can also preview spreadsheet-type documents, as shown in display 718 of FIG. The difference between a regular (ie sequential text) document and a spreadsheet preview is that the spreadsheet preview must preserve the physical layout. Therefore, a spreadsheet preview must be created within both the vertical and horizontal dimensions. The example of FIG. 55 is a two-page spreadsheet document that is converted into two 9-card preview pages, each containing two or more links (if applicable) to navigate to other pages. It corresponds to. For example, the first card 720 includes a “right” link 722 to the card 724 and a “down” link 726 to the card 728. It also has links to navigate between pages. Since page relationships are preserved, the user can also preview those pages with random access.

Instant Messaging Integration With instant messaging technology quickly spreading and becoming generally accepted, instant messaging has become a huge system that connects users. With instant messaging, users can send text message exchanges, chats, image or voice greetings with friends and family in a simple and realistic way. However, since it was originally designed for text exchange, it was generally not allowed to share information or resources. Therefore, the output management system may intervene to make up for the shortage.

  Using this system, instant messaging users can share their resources with peers. Resources are not limited to their type, connectivity (internal or external, network or local), or execution platform as long as the devices are shared on the network. Resources include files, floppy and compact disk drives, and network file systems (ie, co-star file directories). If the user announces that the shared resource is available, their sources will be visible to their peers. Friends download a file from another person's local directory at the push of a button, drag and drop the file onto another person's floppy or compact disk, and click the drive link to another person's local Remote desktop client is enabled with no significant repetitive system administration, except to display the drive directory and deploy the output management system only once in the instant messaging operations domain Just have your users run the instant messaging tools they have.

  To perform resource sharing within an instant messaging domain, an instant messaging client must have remote desktop client functionality. Using a remote desktop client, client machines can announce shared resources by registering with the message center. When registration is complete, the client machine can send and receive sharing resources. To increase performance, instant messaging operators preferably install a dedicated message center to manage their clients instead of relying on the root message center.

  A display 729 illustrating an example implementation of instant messenger is shown in FIG. In this example, the two public message centers MC1, MC2 are each located in an instant messaging (IM) operating network 730 with an embedded print service. These message centers are registered with the zone 0 root message center MC0. Each instant messaging client 732 user runs a remote desktop client on the same host and is registered with one of the message centers in the IM operator network 730. In this configuration, all instant messaging client users can access each other's shared resources without querying the root message center. If necessary, the IM network operator can install more message centers and expand the system to improve performance.

  The described system utilizes the new architecture of device-shared Microsoft Windows. For example, when using a printer driver, a Windows shared printer device driver can be distributed to other hosts through a remote desktop client when requested. After downloading and installing the printer driver, the user can access another person's printer as a shared network device. For this reason, the concept of device sharing in Windows is expanded to a wider range. The network in this configuration extends to the entire instant messaging network instead of the LAN. The instant messaging user can then output the document to each other shared device as if it were connected to the same LAN while the remote desktop client was doing all the work.

Integration of multimedia messaging services Until recently, wireless computing was still limited to text-based applications because wireless devices typically had low network bandwidth and lack of processing power. Recently, some carriers have introduced support for a wide range of services such as WAP applications. Although the initial response was not great, it was thought that most wireless carriers would provide services that users would want to experience. This requires higher network bandwidth, more capable hardware, and more powerful devices. Thanks to the efforts of carriers, infrastructure providers, and device manufacturers, the era of “3G” (third generation) wireless communication has arrived.

  Many mobile device manufacturers have begun work on developing 3G services such as video clips, MP3, slide shows, and video conferencing. These fall into the general category of multimedia wireless solutions. The system architecture complements such multimedia and mobile computing environments by providing a common platform for multimedia output management. FIG. 57 shows a display 734 corresponding to a multimedia integrated system called Multimedia Messaging Service (MMS) being developed by Nokia, one of the industry leaders.

  In this example, inbound gateway 736 and outbound gateway 738 are both deployed to be connected to MMSC and message center MC1 in output management network 740. The inbound gateway receives mobile originated MMS requests from the MMS enabled device 742, translates the requests, sends them to the message center MC1, for further processing. Typical requests include saving movie clips to a shared file server, outputting picture images to a color laser printer, or sending MP3 audio messages to the aforementioned output management system driven instant messaging. Relay to client. The outbound MMS gateway receives a general request addressed to the MMS device from the output management client. This translates the request and sends it to the Multimedia Messaging Service Center (MMSC) 744 for delivery in conformance with the MMS format. The system can support efficient resource sharing between the MMS-enabled message center and the client using an optional root message center in the MMS operations network 746. In one embodiment, hardware costs can be minimized by placing the inbound and outbound gateways in the same location (ie, the same device as the host). In this architecture, an output management system is used as a bridge to take advantage of MMS services to non-MMS clients. The general concept of multimedia messaging service integration can be applied to any kind of multimedia service by simply modifying the incoming interface of the inbound gateway and the outgoing interface of the outbound gateway. The rest of the output management system is unchanged.

Document access / printing behind a firewall using a secure CGI / VPI proxy As mentioned above, this system allows users to access documents and documents located on a private network behind a firewall. Resources including output devices can be accessed. In previous architectures, this functionality was achieved using a persistent communication channel between message channels over the firewall. Referring to FIG. 58, another way in which this can be done is via a CGI / VPN proxy user. As illustrated in the figure, the various users of the system can be routed through the CGI VPN proxy 752 located in the DMZ 754 to route public users' communication from the public network (eg, the Internet 60). An interface 750 can be configured. The CGI VPN then selects a communication path through the VPN switch 756 with secure passthrough through the firewall 758 that provides security protection between the DMZ 754 and the private intranet 760. Next, the VPN switch sets an inbound communication path to the message center MC1 arranged in the intranet 760. In addition, three private resources including a print service PS1, a file store FS1, and an output device D1 are also arranged in the intranet.

  According to the described architecture, public users are able to traverse a VPN link between a publicly accessible user interface (ie Web and WAP UI) and a message center located within the private network. Access to private resources. If the security of the Web and WAP UI is protected using, for example, user authentication and optional encryption techniques, only authorized users can access the VPN link, and thus the security of the firewall 756 Function is maintained. Furthermore, since a secure CGI / VPN proxy is used, hacking into the private network through the proxy is virtually eliminated.

  This implementation expands the functionality of the system and eliminates the need for a publicly accessible message center. For example, companies want to be able to find and print documents stored on one or more private enterprise networks when sales representatives are away from headquarters. . By combining a CGI / VPN proxy and a private MC, these sales representatives can access the file store in the private enterprise network, and any documents stored in the file store can be registered with the private MC. Can be printed to any output device.

  As another method for accessing a private MC through a VPN switch, there is a method using a J2ME (Java (registered trademark) 2 Micro Edition) + VPN compatible device 762. Such devices are currently under development, but will be available soon in the near future. In essence, the J2ME + VPN enabled device incorporates a VPN client that allows the device to communicate directly with the VPN switch without a VPN proxy user, as shown in FIG.

  Printing to resources on private networks without MC

  As shown in FIGS. 59A and 59B, the system can be configured to print to an output device located on a private network that does not include a message center. For example, in configuration 764 shown in FIG. 59A, message center MC1 is located in DMZ 754 and destination printer D1 is located in a suitable private intranet 760 that is separated from DMZ by firewall 758. Has been. In this configuration, a persistent connection 764 is set up between the remote desktop client RDC1 and the message center MC1 that are located with the private intranet.

  During the setup operation, the remote desktop client RDC1 initializes communication with the message center MC1 and opens a communication link corresponding to persistent communication 766 with the message center. The RDC then sends data to the message center MC1 to identify the output device connected to it (in this case, output device (D1)). This information is stored in the RPRM database 242 of the message center MC1.

  An example print operation corresponding to configuration 764 proceeds as follows. Initially, the user of the originating device, such as cellular 768, connects to the message center MC1 via the UI 750. The user selects, via the UI, a remote source document to be printed, for example, stored on the file store FS1 disposed in the DMZ 754. Optionally, documents can be retrieved from other DMZs or private networks (not shown) depending on other MC configurations and other file store locations. Of course, the user can also select and print a local source document stored on the originating device.

  After selecting the document, the user selects the output device. In this case, the output device D1 is selected. After confirming the print request, the print service PS retrieves the source document from the file store or, if the document is a local resource, sends it to the print service. The MC further sends information identifying the device capabilities of the selected output device to the PS. The print service then generates output image data corresponding to the source document and the selected output device and places the output image data as an output image file in a repository (eg, in file store FS1). Stored). Thereafter, the PS notifies the message center MC1 that the job has been completed along with a reference to the output image file. The message center then retrieves the output image file and forwards it to the remote desktop client RDC1 via persistent connection 766. After receiving the image data file, the RDC submits it to the output device D1 for rendering. After completion, the RDC sends a notification to the message center MC1 via the persistent connection 766, after which the MC updates the UI 750 to notify the user that the print job is complete.

  Another configuration 770 that provides the same end result is shown in FIG. 59B. In this example, all components are the same as in FIG. 59A except that a VPN switch 756 and VCN clients 722, 774 are added. In this example, the message center MC1 and the remote desktop client RDC1 communicate via the VPN channel 776. By using the VPN channel, the security level of the private intranet 760 can be increased.

  In the foregoing description and accompanying drawings, embodiments of the present invention have been disclosed that implement the operations of the software provided by the MS Windows operating system component. This is not meant to be limiting as the principles and teachings of the present invention are applicable to implementations where other operating systems are used, such as UNIX-based operating systems and LINUX-based operating systems. For example, various UNIX and LINUX operating systems are supported by OS kernel components that provide similar operations to the MS Windows print support components described above (eg, Windows GDI, print spooler, printer drivers, etc.) A graphical user interface, an application API, and a printing function.

Example Server Computer System Referring to FIG. 60, a generally conventional computer server 800 is described, but is suitable for use in connection with practicing the present invention. Can be used for DPS server computers and Web server computers used to perform Web server operations. Examples of computer systems that may be suitable for these purposes include computer servers running Microsoft Windows, UNIX-based, and LINUX-based operating systems.

  Computer server 800 is typically deployed with suitable integrated circuits including one or more processors 804 and memory (eg, DIMMs or SIMMs) as is well known to those skilled in the art. A chassis 802 on which a motherboard (not shown) is mounted is provided. The monitor 808 is provided for displaying software programs executed by the computer server and graphics and text generated by the program modules. Mouse 810 (or other pointing device) can be connected to the serial port (or bus port or USB port) on the back of chassis 802, and the signal from mouse 810 is transmitted to the motherboard, thereby A software program or module running on the computer controls the cursor on the display and selects text, menu options, and graphic components to be displayed on the monitor 808. In addition, a keyboard 812 is coupled to the motherboard so that a user can enter text and commands that affect the execution of software programs running on the computer. The computer server 800 further incorporates a network interface card (NIC) 814 or equivalent circuit in the motherboard that allows the server to send and receive data over the network 816.

  The file system storage according to the present invention includes a plurality of hard disks 818 housed in the chassis 802 and / or an external disk accessible via a SCSI card 822 or an equivalent SCSI circuit incorporated in the motherboard. It can be implemented via a plurality of hard disks housed in the array 820. Optionally, the disk array 820 can be accessed using a Fiber Channel link using an appropriate Fiber Channel interface card (not shown) or embedded circuitry.

  The computer server 800 may generally include a compact disk read only memory (CD-ROM) drive 824, into which the CD-ROM is inserted to read executable files and data on the disk, and the memory 806 and / Or can be transferred to storage on hard disk 818. Similarly, a floppy drive 826 can be provided for such purposes. Other mass memory storage devices such as optical recording media or DVD drives can also be provided. Machine language instructions including software programs, components, and modules that cause processor 804 to perform the operations of the present invention described above are typically distributed on floppy disk 828 or CD-ROM 830 (or other memory medium). Or stored on one or more hard disks 818 and loaded into memory 806 when executed by processor 804. Optionally, machine language instructions can also be loaded as a carrier file via network 816. As noted above, embodiments of the present invention may be implemented in some form of processing core (such as a CPU of a computer), or may be implemented on or in a machine-readable medium by some other method. It can be used as an implemented software program or used to support the software program. A machine-readable medium comprises a mechanism for storing or transmitting information in a form readable by a machine (eg, a computer). For example, machine-readable media can include read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage, flash memory devices, and the like. In addition, machine-readable media may include a propagated signal (eg, a carrier wave, an infrared signal, a digital signal, etc.), such as an electrical, optical, acoustic, or other type of propagated signal.

  Accordingly, embodiments of the present invention may be implemented in some form of processing core (such as a computer CPU) or software implemented or implemented on or in a machine-readable medium by some other method. Can be used as a program or to support the software program. A machine-readable medium comprises a mechanism for storing or transmitting information in a form readable by a machine (eg, a computer). For example, machine-readable media can include read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage, flash memory devices, and the like. In addition, machine-readable media may include a propagated signal (eg, a carrier wave, an infrared signal, a digital signal, etc.), such as an electrical, optical, acoustic, or other type of propagated signal.

  The above description of the figure embodiments of the invention, including the content of the abstract, is not intended to be exhaustive or intended to limit the invention to the precise form disclosed. While specific embodiments of the invention and examples thereof are intended to be illustrative herein, various equivalent modifications are possible within the scope of the invention, as will be appreciated by those skilled in the art. It is.

  These modifications can be made to the invention in light of the above description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims. Rather, the scope of the present invention is fully determined by the claims to be construed in accordance with established principles of claim interpretation.

FIG. 6 is a block schematic diagram illustrating various tasks performed by a message center (MC). FIG. 6 is a block schematic diagram illustrating various tasks performed by a print service (PS). FIG. 6 is a block schematic diagram illustrating various tasks performed by a remote desktop client (RDC). FIG. 6 is a block schematic diagram illustrating various tasks performed by a wireless data access point (WDAP). It is the schematic which illustrates the example of a simple output management system implementation. It is the schematic which illustrates the example of a more complicated output management system implementation. FIG. 2 is a schematic diagram illustrating the exchange of information between a root message center and a message center connected to a private network. FIG. 6 is a schematic diagram illustrating a setup operation used to establish a peer-to-peer message center connection. 6 is a flowchart illustrating the exchange of information between the RDC and the message center in accordance with the RDC client registration request. 6 is a flowchart corresponding to an RDC printer registration request. FIG. 5 is a flow diagram corresponding to RDC submitting device resource definitions to a message center. Figure 5 is a flow diagram of a public device query sent to the root message center via the home message center. FIG. 6 is a flow diagram corresponding to a print by reference (PBR) job request issued by a user in a home domain to an output device directly connected to a print service in the home domain. It is a figure which shows the exchange of the information of the component corresponding to the PBR job request | requirement of FIG. FIG. 6 is a flow diagram corresponding to a non-PBR job request issued by a user in a home domain to an output device that is directly connected to a print service in the home domain. FIG. 5 is a flow diagram corresponding to a PBR job request submitted by a user in a home domain to a local printer connected to a remote desktop client in the home domain. It is a figure which shows the exchange of the information of the component corresponding to the PBR job request of FIG. FIG. 6 is a flow diagram corresponding to a PBR job request submitted by a user in a home domain (eg, Zone 1) and printed on a root message center public output device (D1). It is a figure which shows the exchange of the information of the component corresponding to the PBR job request of FIG. FIG. 2 is a schematic diagram illustrating three main access mechanisms for exchanging information with a message center in the system. FIG. 6 is a schematic diagram illustrating operations used to determine a dynamic default printer when a user submits a job request via WDAP. FIG. 4 is a schematic diagram illustrating operations used to determine a dynamic default printer when a Bluetooth enabled source device user submits a job request via WDAP including a Bluetooth device emulator. FIG. 2 is a schematic diagram of a system connection topology representing various connection paths and connection types that can occur in a typical implementation of an output management system. FIG. 7 is a flow diagram illustrating operations performed when processing a job request processed through an in-zone, message center, and public RDC. FIG. 4 is a schematic block diagram corresponding to a four-tier architecture according to one embodiment of the invention. FIG. 3 is a block schematic diagram illustrating a corresponding database schema used to implement the operations provided by various software modules and message centers. FIG. 2 is a block schematic diagram illustrating various software components implemented by a print service. FIG. 2 is a block schematic diagram illustrating various CGI scripts used by a print service. FIG. 2 is a block schematic diagram illustrating various software components implemented by a driver print server. FIG. 3 is a schematic diagram illustrating an exemplary data flow process corresponding to a print request submitted to a print service. FIG. 4 is a combined schematic and flow diagram illustrating other operations and logic implemented by driverless print server software for a print service. FIG. 6 is a flow diagram and schematic illustrating the operations and logic used by the window processing component to handle various dialog boxes and message boxes that are invoked when processing a print job. 1 is a web-based user interface (UI) that a user can use to set up file server access through an output management system. FIG. FIG. 34 is a diagram of the web-based UI of FIG. 33 after setup to allow access to multiple file servers. FIG. 6 is a web-based UI that a user can use to set up a list of favorite printers. FIG. 2 is a diagram of a web-based UI that a user can use to search for printers already configured by a system administrator. FIG. 36 is a diagram of the web-based UI of FIG. 35 after adding multiple printers to the list of favorite printers. FIG. 53 is a legend corresponding to the detailed content of the WAP-based user interface of FIGS. FIG. 4 is a first part of a WAP UI flow diagram corresponding to a subscriber login process. FIG. 40 is a second part of the WAP UI flowchart of FIG. 39. FIG. CGI script subOutputIndex. It is a flowchart of WAP UI corresponding to pl. 6 is a flow diagram of a WAP UI corresponding to a set of cards that enable retrieval of documents to be output by network navigation. Figure 5 is a flow diagram of a WAP UI corresponding to adding a network site, fax machine, email address. A WAP UI used to notify a user that a network site has been added to the user's network site list. FIG. 6 is a WAP UI flowchart corresponding to adding a new printer to a list of favorite printers. A WAP UI used to notify a user that a fax machine has been added to the user's fax list. A WAP UI used to notify a user that an email name has been added to the user's contact list. FIG. 5 is a flow diagram of a WAP UI corresponding to confirmation of a selected document and output device. FIG. 5 is a flow diagram of a WAP UI corresponding to adding a new fax to a user's favorite fax list. 4 is a flow diagram of a WAP UI corresponding to adding a new email contact to a user's contact list. FIG. 5 is a flow diagram of a WAP UI corresponding to inserting a print job, a fax job, and an email job into a corresponding job queue. 4 is a WAP UI flow diagram showing whether a PIN has been successfully sent to a user via email as a response to a user's send request. FIG. 6 illustrates a method for converting an original document image into thumbnails of various sizes for previewing the document on a device using a low resolution screen. FIG. 3 is a schematic diagram illustrating a method of previewing how a document is displayed when a partial portion of a text-based document is viewed and output to a selected output device. It is the schematic which shows the method of previewing how a document is displayed when browsing the partial part of the document of spreadsheet software, and outputting to the selected output device. 1 is a schematic diagram illustrating a method for extending the architecture principle of an output management system to support resource sharing via an instant messaging service. FIG. FIG. 2 is a schematic diagram illustrating a method of using a system via a multimedia messaging enabled device. 1 is a schematic diagram illustrating how a CGI VPN proxy is implemented to enhance the security of a private network that includes resources used by the system. FIG. 1 is a schematic diagram illustrating a first configuration that allows access to an output device located on a private network that does not include a message center. FIG. FIG. 6 is a schematic diagram illustrating a second configuration that allows access to an output device located on a private network that does not include a message center. 1 is a schematic diagram of an example computer server used as a host for various components of a system, including a message center and a printing service.

Claims (67)

A method for printing on a private network behind a firewall from a source device outside the firewall,
Establishing a pass-through communication link through the firewall between the output management system component located behind the firewall and the output management system component outside the firewall;
Providing drawable data to the originating device, thereby rendering the user interface on the originating device;
Allowing the user to select the source data to print through the user interface;
Allowing the user to select the output device on the private network to which the source data is printed;
Retrieving the source data from the store;
Rendering the output image data corresponding to the source data and the selected output device;
Sending output image data from an output management system component outside the firewall to an output management system component located behind the firewall;
Submitting output image data to an output device from an output management system component located behind the firewall and physically rendering with the output device.   The method of claim 1, wherein each output management system component located outside and behind the firewall comprises a message center component with other component management functions within the output management system.   In addition, it uses a pass-through communication link that identifies one or more output devices located behind the firewall that can be accessed through an output management system component located behind the firewall, The method of claim 1 including transmitting data from a power management system component located behind to a power management system component outside the firewall.   The method of claim 1, wherein the output management system component located outside the firewall includes a server component and the output management system component located behind the firewall includes a client component.   The method of claim 1, wherein the pass-through communication link comprises a virtual private network (VPN) link.   The method of claim 1, wherein the originating device comprises a web-enabled wireless device.   The method of claim 1, wherein the source device comprises a Bluetooth enabled device.   The method of claim 1, wherein the store comprises a local store on the originating device.   The method of claim 1, wherein the store comprises a remote store located at a location remote from the wireless device.   The method of claim 9, wherein the remote store is located on a private network. Using print services,
An operation to determine the file type of the source data;
Operations to determine suitable applications to load through the print server and generate output image data; and
The method of claim 1, wherein the output image data is generated by performing an operation that initiates a print action that combines the application and the print subsystem to generate output image data.   The method of claim 1, further comprising providing print preview data to the wireless device that includes a simulated representation of the rendered output generated by the output device when drawing on the user interface. A method of printing on a private network behind a firewall from a source device outside the firewall,
Establishing a pass-through communication link through the firewall between the output management system component located behind the firewall and the output management system component outside the firewall;
Providing drawable data to the originating device, thereby rendering the user interface on the originating device;
Allowing the user to select the source data to print through the user interface;
Allowing the user to select the output device on the private network to which the source data is printed;
Transferring source data or a reference to that data from an output management system component located outside the firewall to an output management system component located behind the firewall;
Rendering the output image data corresponding to the source data and the selected output device;
Submitting output image data to an output device and physically rendering with the output device.   14. The method of claim 13, wherein each output management system component located outside and behind the firewall includes a message center component with other component management functions within the output management system.   In addition, it uses a pass-through communication link that identifies one or more output devices located behind the firewall that can be accessed through an output management system component located behind the firewall, 14. The method of claim 13, comprising transmitting data from a power management system component located behind to a power management system component outside the firewall.   The output management system component located inside the firewall includes a server component, and submitting the output image data to the output device includes providing the output image data to the client, the output image data 14. The method of claim 13, wherein the client submits the output image data to the output image device for rendering as a response to receiving.   The method of claim 13, wherein the originating device comprises a web-enabled wireless device.   The method of claim 13, wherein the source device comprises a Bluetooth enabled device.   The source data includes documents stored on the originating device, and further includes receiving source data from the originating device at an output management system component outside the firewall. The method described in 1.   The method of claim 13, wherein the source data is stored in a remote store and further includes retrieving the source data from the remote store.   21. The method of claim 20, wherein the remote store is located on a private network and the source data is retrieved from a location identified by reference to the source data.   The method of claim 13, further comprising providing job status information to a user via a user interface. Using print services,
An operation to determine the file type of the source data;
Operations to determine suitable applications to load through the print server and generate output image data; and
14. The method of claim 13, wherein the output image data is generated by performing an operation that initiates a print action that combines the application and the print subsystem to generate output image data.   The method of claim 13, further comprising providing print preview data to the wireless device that includes a simulated representation of the rendered output generated by the output device when drawing on the user interface. A method of printing on a private network behind a firewall from a source device outside the firewall,
Establishing a communication link comprising a virtual private network (VPN) tunnel through the firewall between the originating device and a power management system component located behind the firewall;
Providing drawable data to the originating device, thereby rendering the user interface on the originating device;
Allowing the user to select the source data to print through the user interface;
Allowing the user to select the output device on the private network to which the source data is printed;
Forwarding source data or a reference to that data from a source device over a VPN tunnel to an output management system component located behind the firewall;
Rendering the output image data corresponding to the source data and the selected output device;
Submitting output image data to an output device and physically rendering with the output device.   The user interface includes multiple interactive web pages, and the VPN tunnel is facilitated by a common gateway interface (CGI) VPN proxy located outside the firewall in combination with a VPN switch located on the firewall. 26. The method of claim 25, wherein the method can be used.   26. The source device of claim 25, wherein the source device comprises a VPN-enabled device, and the VPN tunnel can be smoothly used by a client-side component running on the VPN-enabled device and a VPN switch located at the firewall. Method.   The output management system component located behind the firewall includes a server component, and submitting the output image data to the output device includes providing the output image data to the client, and the output image 26. The method of claim 25, wherein in response to receiving data, the client submits the output image data to the output image device for rendering.   26. The method of claim 25, wherein the originating device comprises a web enabled wireless device.   26. The method of claim 25, wherein the source device comprises a Bluetooth enabled device.   The source data includes documents stored on the source device, and the output management system component behind the firewall can receive source data from the source device over the VPN tunnel. 26. The method of claim 25 comprising.   32. The method of claim 31, wherein the source data is stored in a remote store and further includes retrieving the source data from the remote store.   The method of claim 32, wherein the remote store is located on a private network and the source data is retrieved from a location identified by reference to the source data.   26. The method of claim 25, further comprising providing job status information to a user via a user interface. Using print services,
An operation to determine the file type of the source data;
Operations to determine suitable applications to load through the print server and generate output image data; and
26. The method of claim 25, wherein the output image data is generated by performing an operation that initiates a print action that combines the application and the print subsystem to generate output image data.   26. The method of claim 25, further comprising providing print preview data to the wireless device that includes a simulated representation of the rendered output generated by the output device when drawing on the user interface. An output management system that allows printing from a source device located outside a firewall to a destination output device connected to a private network deployed behind the firewall,
A print service that generates output image data corresponding to the input source data and destination output device;
A message center located outside the firewall and linked to communicate with a print service,
Provides drawable data, thereby drawing a user interface (UI) on a source device that is linked to operate in communication with the web server component, and the user selects source data to draw A web server component that allows a job request to render source data on the destination output device,
A message center comprising a client side component deployed on a private network and linked to communicate with the message center via a link through a firewall;
The Message Center further manages job requests received from the Web server component, and in response to the reception,
Select a route to send selected source data or a reference to that data to the print service,
An output management system comprising a system management component that controls distribution of output image data generated by a print service to a destination printer.   38. The output management system of claim 37, wherein the client side component further performs an operation of registering with the message center an output device accessible through the service.   38. The output management system of claim 37, wherein the link through the firewall between the client side component and the message center includes a persistent connection.   38. The output management system of claim 37, further comprising an output repository capable of storing output image data before submitting to the output device.   38. The output management system of claim 37, wherein the user interface includes a wireless web user interface accessible via a wireless web enabled device.   38. The power management system of claim 37, further comprising a wireless data access point (WDAP) linked to communicate with a message center.   43. The output management system of claim 42, further comprising a Bluetooth device emulator coupled to operate with WDAP, wherein the system can be accessed with a Bluetooth enabled wireless device.   44. The power management system of claim 43, wherein the user interface is provided using WAP (Wireless Application Protocol) over Bluetooth protocol. Printing service
An operation to determine the file type of the source data;
Operations to determine suitable applications to load through the print server and generate output image data; and
38. The output management system of claim 37, wherein output image data is generated by performing an operation that initiates a print action that combines the application and the print subsystem to generate output image data.   The output management system according to claim 37, wherein the user can further select an output device on which the source data is drawn by a user interface.   38. The output management system of claim 37, further comprising a database server in which user profiles and system resource information are stored.   By using the user interface, the user can select and / or specify one or more favorite output devices from output devices accessible via the output management system, selected by the user, and 48. The output management system of claim 47, wherein data relating to the designated output device is stored by the database server.   The message center includes a root message center and the client side component includes a second message center and is nested below the root message center in the message center hierarchy. 37. The output management system according to 37.   38. The output management system according to claim 37, wherein the print service is deployed behind a firewall.   38. The output management system of claim 37, wherein the print service and client side component are hosted by a single machine.   The print service is deployed outside the firewall and the client-side component includes a remote desktop client that receives image output damage via the message center, and submits the image output damage to the destination output device for rendering Item 38. The output management system according to Item 37.   38. The output management of claim 37, further wherein the print service provides the wireless device with print preview data that includes a simulated representation of the rendered output generated by the output device when drawing on the user interface. system. An output management system that allows printing from a source device located outside a firewall to a destination output device connected to a private network deployed behind the firewall,
A print service that generates output image data corresponding to the input source data and destination output device;
A message center located inside the firewall and linked to communicate with the print service,
Providing drawable data, thereby rendering a user interface (UI) on a source device that is linked to operate in communication with a web server component via a secure link; A web server component that selects source data to render and allows a job request to render source data on the destination output device to be submitted;
A system management component that manages job requests received from the Web server component, and as a response to the reception,
Select a route to send selected source data or a reference to that data to the print service,
An output management system comprising a message center that controls distribution of output image data generated by a print service to a destination printer.   54. The output of claim 53, further comprising a virtual private network (VPN) switch deployed with the firewall, wherein the VPN encoded data can pass through the firewall and the data can be received by the message center. Management system.   In addition, it has a common gateway interface (CGI) VPN proxy deployed outside the firewall, which encodes data received from non-VPN source devices via the user interface into VPN encoded data, thereby 20. The output management system of claim 19, wherein the output management system implements a secure connection between a non-VPN enabled wireless device and a message center.   The output management system of claim 1, wherein the output device is deployed on a private network that is not directly accessible by the wireless device. An output management system,
Provide drawable data, thereby drawing a user interface (UI) on a source device that is linked to operate in communication with at least one web server, which allows the user to draw A web server layer including at least one web server executing software configured to select source data to be submitted and to submit a job request to render the source data to a destination output device;
A print service layer comprising at least one print service server that executes software for executing a print service that generates input image data corresponding to an input source data and an output device that renders the input source data;
Manage job requests and respond to them
Select a route to send selected source data or a reference to that data to the print service layer,
A message center layer comprising at least one message center server running software configured to manage submission of output image data generated by a print service to a destination output device for rendering ,
An output management system in which at least one server from servers in the print service layer and the message service layer is located behind a firewall on a private network.   58. The output management of claim 57, further comprising a database layer including at least one database server that hosts at least one database, wherein the database layer stores system data including system management and job request data. system.   59. The output management system of claim 58, wherein the database layer includes a message center database in which system management and job request data is stored and a print service database in which data related to the print service is stored.   58. The output management system of claim 57, wherein the database layer further comprises an output image store capable of storing output image data prior to submission to the destination output device.   The output management system according to claim 57, wherein the Web server layer includes a plurality of Web servers, and further includes a load balancer that distributes the load of incoming connections among the plurality of Web servers.   58. The output management system according to claim 57, wherein the print service layer includes a plurality of print service servers as hosts, and further includes a load balancer that distributes a load of an incoming print service request among the plurality of Web servers.   In addition, with a remote desktop client linked to communicate with the message center layer, the output image data is sent to the destination output device specified by the output device submit command received from the message center layer. The output management system according to claim 57, wherein the output management system is supplied.   58. The output management system of claim 57, wherein the user interface includes a wireless web user interface accessible via a wireless web enabled device. Printing service
An operation to determine the file type of the source data;
Operations to determine suitable applications to load through the print server and generate output image data; and
58. The output management system of claim 57, wherein the output management data is generated by executing an operation that initiates a print action that combines the application and the print subsystem to generate output image data.   58. The output of claim 57, further wherein the print service provides the wireless device with print preview data that includes a simulated representation of the rendered output generated by the destination output device when drawing on the user interface. Management system.

Images