JP2011034563A - Print system - Google Patents

Abstract

【Task】
The method and apparatus according to the present invention are provided for printing on a printing device.
[Solution]
A print driver executing on the client device receives print device capability data identifying a plurality of functions and options currently supported by the print device from the print device. The print driver generates a second version from the first version of the DEVMODE data structure. A portion of the DEVMODE data structure is described in XML and indicates a particular print function and one or more options for the particular print function indicated in the print device capability data. A user interface may be generated based on this second version. A third version of the DEVMODE data structure has been generated to indicate that the particular print function option has been selected. Based on the third version of the DEVMODE data structure, the print driver generates a print job ticket.
[Selection] Figure 5

Description

  The present invention generally relates to printing systems. More particularly, the present invention relates to printing on a printing device.

The approaches described in this section show approaches that can be implemented, but are not necessarily approaches that have been previously devised or implemented. Thus, unless otherwise stated, any approach described in this section should not be considered prior art solely by what is described in this section.
[Web service]

  The World Wide Web Consortium (W3C) is an international consortium that develops standards for the World Wide Web. The W3C defines a “web service” as a software system designed to support machine-to-machine interoperable interaction over a network. This definition covers many different systems but has a common usage. This specification is used for a service using an XML (Extensible Markup Language) envelope in a SOAP (Simple Object Access Protocol) format, and a service having an interface described using WSDL (Web Services Description Language). Web services allow devices and applications to communicate in one or more networks without any human intervention. At the same time, humans can communicate with such devices and applications over one or more networks using the same integrated protocol (eg, Hyper Text Protocol (HTTP)).

  The specifications that define web services are intentionally modular. And as a result, there is no single document that defines all web services. Instead, depending on the situation and technology, there are several core specifications to complement this. Common core specifications include SOAP, WSDL, WS-Discovery, WS-MetadataExchange, WS-Addressing, and WS-Security. Different specifications define different tasks and functions.

  SOAP is an XML-based, extensible message envelope format that is compatible with important protocols (eg, HTTP and Simple Mail Transfer Protocol (SMTP)). Using XML, SOAP defines how a message must be formatted. This formats the messages so that their recipients (devices and applications) can interpret the messages. SOAP can be used, for example, to execute remote procedure calls.

WSDL is an XML format that describes a web service interface. This then defines the details of the interface that binds to a particular protocol. WSDL is typically used to generate server and client code and for configuration.
[WSD device]

  A device that hosts one or more web services also implements the Devices Profile for Web Services (DPWS) specification. This type of device is called Web Service for Devices (WSD). Examples of WSD devices include, but are not limited to, scanners, printers, copiers, fax machines, archive processing devices, and multifunction peripherals (MFPs). A multi-function peripheral (MFP) provides multiple services (eg, print, copy, and scan services).

  DPWS defines a minimal set of implementation constraints to enable secure web service message transmission, discovery, description, and events at the device. The DPWS specification defines the following architecture in which devices provide two types of services: hosting services and hosted services. Hosting services are directly associated with devices and play an important role in the device discovery process. Hosted services are largely functional and rely on hosting devices for discovery.

DPWS is based on the following core web service standards: WSDL 1.1, XML Schema, SOAP 1.2, WS-Addressing, and WS-Metadata Exchange, WS-Transfer, WS-Policy, WS-Security, WS -Further have Discovery and WS-Eventing. A device that implements one or more web service standards is referred to herein as a web service enabled device.
[Service specifications]

Some web services meet specific service specifications. A service specification (eg, WSD Print Service specification) describes a minimal set of APIs that a web service must implement in order to comply with that service specification. For example, the WSD print service specification defines:
(A) a set of operations that the print web service can handle (eg, described in a WSDL file), and (b) events generated by the print web service.
The WSD scanner service specification defines:
(A) a set of operations that the scan web service can handle, and (b) events generated by the scan web service.

Service specifications may be standardized by W3C or other web service standardization organizations (eg, Oasis for the Advancement of Structured Information Standard).
[Print to print device]

  When a user wants to print an electronic document on a print device, the print subsystem of the user's client device processes the application data generated by the application program and generates print data. The print data includes all information necessary for printing the electronic document by the printing device. For example, a user creates an electronic document using a word processing application on a PC. The user then selects a print option for the word processing application and requests that the electronic document be printed on a particular printer. The print subsystem on the PC processes this request by processing the application data generated by the word processing application to generate print data in a format supported by the particular printer. The print subsystem then sends the print data to the specific printer. Typically, print data is sent to the print device as part of a print job recognized by the print device.

Conventionally, in order to generate print data, a print driver specific to a target print device is used. That is, each print driver converts the print data into a format supported by the target print device. Therefore, in order for a client device to print correctly on a specific printing device, the client device needs to have a print driver for the specific printing device installed. One challenge with this approach is that the print driver must be up-to-date for the intended printing device. When the configuration of the printing device is changed, a new print driver must be generated and distributed to a large number of users. Print device manufacturers attempt to provide the latest print drivers available on their website for download. However, many users do not know to check the manufacturer's website for the latest drivers. Furthermore, many print drivers must be digitally authenticated by the company that develops the operating system or by the print device manufacturer. And this can be time consuming and expensive. Any change to the print driver usually requires digital re-authentication.
[DEVMODE]

  DEVMODE is a basic data structure used by the Windows® spool system to process print data. DEVMODE includes device settings (chosen by the user and / or set as default settings) as part of print job processing. In order to create a print job from a Windows application, a user interface is presented to the user so that the user can select various options related to the many features currently supported on a particular printing device. The application saves the user's selection in the DEVMODE structure. The application then sends a DEVMODE structure to the print driver for the particular printing device. The print driver interprets the DEVMODE settings and renders the print data in a format that is accepted by the particular printing device.

  The conventional DEVMODE structure is a static binary data structure that is hard-coded within the print driver. When a new device function is plugged in (or added) to a print device (or web service compatible print device), and this new device function is not defined in the corresponding print driver, the new device The function cannot be used when printing. This is because the DEVMODE size cannot be automatically expanded because the print driver includes new functions.

[Overview]
The present technology is provided for printing on a printing device. In particular, the print device may be a web service compatible print device or a normal print device as long as it can provide print device capability data described below. A web service compatible print device is preferred, but not limited to this. In an embodiment, a print driver running on a client device receives print device capability data identifying a plurality of the latest features and options supported by the web service capable print device from the web service capable print device. To do. In response to receiving the print device capability data, the print driver generates a second version of the DEVMODE data structure from the first version of the DEVMODE data structure. The first version shows a first plurality of features previously supported by the web service enabled printing device. The second version shows a second plurality of functions that are most recently supported on a web service enabled printing device. The first plurality of functions are different from the second plurality of functions. The first part of the second version of the data is described in a binary format, and the second part of the second version is described in XML. This second part shows a particular print function and one or more options for the particular print function indicated in the print device capability data. The user interface is generated based on the second version of the DEVMODE data structure. In response to the one or more user selections, a specific third version of the DEVMODE data structure is generated indicating that an option has been selected for each function of the second set of functions. The The print driver may then generate a print job ticket based at least on the third version of the DEVMODE data structure. The print driver transmits print data and a print job ticket to the web service compatible print device.

  The present invention has been described by way of illustration and not limitation. In the accompanying drawings, the same reference numerals relate to similar elements.

  This approach allows for a dynamically synchronized DEVMODE structure that reflects the latest features and options of a printing device, particularly preferably a web service enabled printing device. Any time a device function is changed, the print driver will be notified whenever an event is generated, for example when a new device function is added or removed. Is possible. Thus, the user can always initiate a print job based on the latest features supported by the web service enabled printing device. Another effect is that the dynamic part of the DEVMODE structure can be read by the application program. If the dynamic part of the DEVMODE structure is not readable (eg if the dynamic part is in binary format), the application program cannot read and properly interpret any new device capabilities indicated in the dynamic part. I can't. For example, if a new drilling punch function is added to the printing device, and this new function is mapped to binary number 30, what the binary number 30 indicates by the application program? Since it is not known, the application program may not be able to demonstrate a new drilling punch function.

6 is a flowchart illustrating an approach for printing to a printing device in one embodiment of the invention. FIG. 3 is a block diagram illustrating the configuration of printing according to an embodiment of the present invention.

FIG. 6 is a block diagram illustrating different parts of a DEVMODE data structure.

FIG. 4 is a block diagram illustrating the relationship between printer description data and a DEVMODE data structure in one embodiment of the present invention.

FIG. 4 is a block diagram illustrating how a DEVMODE data structure is updated in one embodiment of the present invention.

4 is a flowchart illustrating at least two scenarios where a DEVMODE data structure is created or updated in one embodiment of the present invention.

FIG. 3 is a block diagram illustrating a user interface based on a novel device function in one embodiment of the present invention.

FIG. 6 is a sequence diagram illustrating a method for updating a DEVMODE data structure based on new device capabilities and corresponding options in one embodiment of the present invention.

FIG. 6 is a block diagram that illustrates a computer system upon which an embodiment of the invention may be implemented.

[Detailed description]
In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough interpretation of the present invention. It will be apparent that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

I. Overview II. Print system architecture III. Generation of printer description data IV. DEVMODE data structure Update of DEVMODE VI. Implementation mechanism Overview

  An approach is provided for printing to a web service enabled printing device. The print driver creates (or updates) the DEVMODE structure based on a new set of functions specified in the print device capability data read from the web service capable print device, for example, using the WSD communication protocol. New functions and options are stored as XML data in specific sub-parts of the DEVMODE structure. The application program may later access the DEVMODE structure and modify that copy of the DEVMODE structure to indicate which functions and options the user has chosen. This modified DEVMODE structure is carried over to the print driver, which generates a print job ticket based at least on the modified DEVMODE structure. The print driver sends a print job ticket and print data to a web service enabled print device for processing. Embodiments include a print driver that is subscribed to receive an event (generated by a web service enabled print device) that signals when a change in installed features and options has occurred. The print driver is configured to update the DEVMODE structure in response to this type of event.

  This approach allows for a dynamically synchronized DEVMODE structure that reflects the latest features and options of web service enabled printing devices. Any time a device function is changed, the print driver will be notified whenever an event is generated, for example when a new device function is added or removed. Is possible. Thus, the user can always initiate a print job based on the latest features supported by the web service enabled printing device. Another effect is that the dynamic part of the DEVMODE structure can be read by the application program. If the dynamic part of the DEVMODE structure is not readable (eg if the dynamic part is in binary format), the application program cannot read and properly interpret any new device capabilities indicated in the dynamic part. I can't. For example, if a new drilling punch function is added to the printing device, and this new function is mapped to binary number 30, what the binary number 30 indicates by the application program? Since it is not known, the application program may not be able to demonstrate a new drilling punch function.

  FIG. 1 is a flowchart illustrating an approach for printing on a printing device in one embodiment of the invention. In step 102, the print driver is executed at the client device and receives print device capability data from the web service enabled print device. The print device capability data identifies a plurality of functions and options currently supported by the web service enabled print device.

  In step 104, the print driver generates, in XML, a DEVMODE data structure indicating the specific device function indicated by the print device capability data. The DEVMODE data structure may be generated based at least on the print device capability data or on the printer description data (details will be described later). The print driver generates printer description data based at least on the print device capability data.

  In step 106, a user interface is generated based on at least the DEVMODE data structure. The user interface shows the functions and options currently supported by the web service enabled print device. The print driver or application program generates a user interface.

  In step 108, a job setting (or default setting) version of the DEVMODE structure is generated by the application program or print driver. The job setting version of the DEVMODE structure indicates which functions and options have been selected. The selected functions and options may be default selections and / or selections from the user.

  In step 110, the print driver generates print data and a print job ticket based at least on the DEVMODE structure of the job setting version.

In step 112, the print driver sends the print data and the print job ticket to a web service enabled print device for processing.
II. Print system architecture

  FIG. 2 is a block diagram illustrating a print configuration 200. The print configuration 200 includes a client device 202 and a web service enabled print device 204. These are connected for communication by a network 206. Network 206 may be implemented by any of the media or mechanisms that provide for the exchange of data between client device 202 and web service enabled print device 204. Examples of network 206 include a local area network (LAN), a wide area network (WAN), a network such as Ethernet or the Internet, or one or more terrestrial, satellite, and wireless links. However, the present invention is not limited to this.

  The web service compatible print device 204 includes a web service compatible print service 208. The client device 202 includes a user interface 210, an application program 212, a print driver installation application 214, a print driver 216 (including a user interface (UI) module, and a rendering module 220), a port monitor, and web services. A device (WSD) application program interface (API) module 222, a spooler 224, and a storage device 226. The storage 226 stores print device capability data 228, print data 230, and a print job ticket 232. The storage device also includes a print driver storage device 234 and a registry 236 that stores printer description data 238 and a default print ticket 240. Each of these elements is briefly described below and then described in detail.

  The user interface 210 is a mechanism and / or medium that presents information to the user and allows user input. Application program 212 may be any type of program that prints data. Examples of application program 212 include, but are not limited to, word processing programs, spreadsheet programs, e-mail clients, and the like. For illustration purposes, one application program 212 is shown in FIG. The client device 202 may have any number of application programs.

  The print driver installation application 214 executes installation of the print driver 216. This may include installing any data or files necessary for the print driver 216. The installation of print driver 216 may include data and / or files from other sources and locations. This depends on the implementation or on the implementation of the configuration requested by the operating system.

  The print driver 216 interacts with the application program 212 to generate print data for printing on the web service enabled print device 204. The UI module 218 generates graphical user interface data. This provides a user with a graphical user interface via user interface 210 when processed by application program 212. This allows the user to select the functions and options to be used when printing a particular electronic document. The rendering module 220 processes application data generated by the application program 212 and generates print data. This is a printed version of an electronic document that reflects print data printed by the web service enabled print device 204 when processed by the web service compatible print device 204. The print driver 216 performs various other functions that are described in further detail below.

  The port monitor and WSD API module 222 allows communication between the print driver 216 and the web service enabled print device 204. For example, the WSD API module 222 may be installed on a custom port. The print driver 216 communicates with the WSD API module 222 via a custom port. The port monitor and WSD API module 222 communicates with the web service enabled print device 204. Accordingly, the port monitor and WSD API module 222 can convert client-side instructions (eg, BiDi function calls) into a SOAP request in the form of a SOAP envelope, and can also print web services enabled prints in the form of a SOAP envelope. XML information can be obtained from the SOAP response received from the device 204 and a BiDi function call response can be generated. The port monitor and WSD API module 222 sends a SOAP request to the port associated with the web service enabled print service 208.

  The print device capability data 228 is data that specifies the latest functions and options of the web service-compatible print device 204 (that is, allowable values for each function). Examples of the print device function include, but are not limited to, a paper tray, double-sided printing, stapling, binding punching, and the like. Each function has one or more options (ie values). Some functions may include only two options. For example, the duplex printing unit has two options, such as “Installed” or “NotInstalled”. There are many other functions (for example, paper size) such as “A4”, “legal”, “81/2 × 11”, and the like. The print device capability data 228 stored on the client device 202 may include print device capability data for any number of web service enabled print devices.

  The print data 230 is data generated by the print driver 216. At least based on application data generated by the application program 212. The application program 212, when processed by the web service enabled print device 204, produces a printed version of the electronic document indicated by the print data 230 to be printed. The print job ticket 232 identifies one or more parameters that indicate how the print data 230 is processed by the web service enabled print device 204. The print data 230 may include data for multiple print jobs. The print job ticket 232 may include a plurality of print job tickets.

  The print driver storage device 234 includes one or more print drivers used by the client device to print on the printing device. The registry 236 is an area of the storage device 226 for storing the printer description data 238, the default print ticket 240, and the DEVMODE data structure 242 (hereinafter referred to as “DEVMODE structure 242”). Registry 236 may be a protected area of storage device 226 that is managed by the operating system on client device 202. The default print ticket 240 includes data indicating default options for functions supported by the web service enabled print device 204. The default print ticket 240 may include a default print ticket for any number of printing devices. Similarly, DEVMODE structure 242 may include any number of print device PDEVMODE data structures.

The print driver 216 generates printer description data 238 based on at least the print device capability data 228. The printer description data 238 identifies display data for one or more functions and options currently supported by the web service enabled print device 204. Print driver 216 uses printer description data 238 to generate graphical user interface data and to generate print data 230 and / or print job ticket 232.
III. Generation of printer description data

  As previously described herein, the UI module 218 is configured to generate printer description data 238 and store it in the registry 236 and receive a default print ticket received from the WSD print device 204. Configured to save. Printer description data 238 is used by the UI module 218 to generate GUI data. When the GUI data is processed by the application program 212, it causes a GUI on the user interface 210. The user interface 210 displays the functions and options supported by the WSD print device 204 and allows the user to select functions and options to use when printing a particular electronic document.

  In general, the process for generating the printer description data 238 includes information from the print device capability data 228 for the WSD print device 204 and the core provided as part of the basic installed print driver. Including combining data from the mapping data.

  According to one embodiment of the invention, UI module 218 examines print device capability data 228 and identifies the print device capabilities identified therein. For each function of the print device capability data 228, the UI module 218 identifies whether the function is defined in the core mapping data. The core mapping data includes PDLKeywords and rcNameIDs, which are for a standard set of print device functions and options. If a specific function of the print device capability data 228 is defined in the core mapping data, the UI module 218 reads from the core mapping file the PDLkeyWord value for the specific function and each corresponding option, and the rcNameID. The value is read and the PDLkeyWord value and the rcNameID value of the printer description data 238 are stored. The PDLkeyWord value provides a mapping between a function or option terminology interpreted by the print driver 216 and a term interpreted by the WSD print service 208 for the same function or option. The rcNameID value indicates the name of a character variable (resource ID) including a function or option character string. This character string is included in the GUI data generated by the UI module 218 and is given to the application program 212. Consider the following example. Assume that the print device capability data 228 includes a function named “InputTray4”. Assume further that this function is defined in the core mapping data as shown in Table 1 below.

  As indicated in Table 1, the function InputTray4 has two options including “Installed” and “NotInstalled”. This function and each option both have a specific PDLKeyword value and a specific rcNameID value. The UI module 218 reads it and stores it in the printer description data.

  If a particular function of the print device capability data 228 is not defined in the core mapping file, this particular function is usually a new function. In this state, the UI module 218 uses the function name of the particular function from the print device capability data 228 to generate the PDLkeyWord value for the printer description data 238. In addition, the UI module 218 includes DisplayName values for specific functions of the printer description data 238. To provide multiple language support, multiple DisplayName values may be included in the printer description data 238 for each function and / or option. The display name value is included in the GUI data generated by the UI module 218 and provided to the application program 212. Referring to the previous example, assume that a function named “InputTray4” is not defined in the core mapping data. Assume further that this function is defined in the print device capability data 228 as shown in Table 2 below.

As indicated in Table 2, there is no PDLKeyword value or rcNameID value included in the definition of the function of InputTray4 in the print device capability data 228 here. In this example, the function name “InputTray4” is stored in the printer description data 238 as the PDLKeyword value. The UI module 218 also reads the DisplayName value for each function and each option, and stores the DisplayName value in the printer description data 238.
IV. DEVMODE data structure

  FIG. 3 is a block diagram illustrating different portions of the DEVMODE structure 242 in accordance with one embodiment of the present invention. The DEVMODE structure 242 includes two public parts 310 and 320 and a private part 330. Portion 310 is common to all print drivers for client devices defined by Microsoft and using the Microsoft operating system. Portion 310 includes data indicating device functions that are common to many printing devices. Portion 320 shows the device capabilities defined in the Generic Printer Description (GPD) file (required by the Microsoft UNIDRV driver and provided by the manufacturer) and has a specific type (eg, all provided by the manufacturer) Data common to all printing devices of the on-demand printing system (ODPS). The Microsoft UNIDRV driver manages part 320. The data in portions 310 and 320 is stored in a binary format. Also, the data in portions 310 and 320 are static with respect to device function and are not expandable. For example, any device function that is added to the web service enabled print device 204 cannot be added to either the portion 310 or 320. Further, if (a) the device function is shown in either portion 310 or 320, and (b) is subsequently unavailable to the web service enabled print device 204, then either of portions 310 and 320 The part is also not updatable to indicate that the device function is not available.

Portion 330 includes data indicating one or more device functions supported by the corresponding printing device. The device functions shown in portion 330 are not shown in either portion 310 or 320. UI module 218 manages portion 330. The data of the part 330 is stored as XML data. For example, if the print device capability data 228 indicates a function and options for drilling and this is not defined in either part 310 or part 320, the user selects the hole function "Hole Punch" If so, the portion 330 is updated to include XML data that provides support for the drilling function. One example of this XML data is as follows:
<DeviceFeature Value = "HolePunch">
<FeatureOption Value = "Left2"/>
</ DeviceFeature>

  If the device function shown in portion 330 becomes unavailable on the web service enabled print device 204, the portion 330 is updated with the device feature removed or the device feature is not currently available Updated to show that

  FIG. 4 is a block diagram showing the relationship between the printer description data 238 and the DEVMODE structure 242 in one embodiment of the present invention. The DEVMODE structure 242 is generated from the web service compatible print device 204 based on at least the print device capability data 228 or the printer description data 238. As shown in FIG. 4, the printer description data 238 has a new device function called “HolePunch” that is not defined in either 310 or 320 portion. This new device capability includes at least three options. That is, “OFF”, “Left2”, and “Right2”. The “Left2” and “Right2” options indicate the number and location of the holes. After user selection (or default selection), the modified DEVMODE structure 242 indicates that the value of the selected new device function “HolePunch” is “OFF”.

  FIG. 4 represents one of two approaches for implementing DEVMODE structure 242 (ie, generating an option selected version). In the first approach (as described above), the UI module 218 generates graphical user interface data based on the printer description data 238. The graphical user interface data, when processed by the application program 212, provides the user with a graphical user interface on the user interface 210 to select the functions and options used in printing the electronic document. Application program 212 saves the user's selection (and any defaults) in DEVMODE structure 242 to generate a job setting version of DEVMODE structure 242.

In the second approach (not shown in FIG. 4), application program 212 accesses DEVMODE structure 242 to generate a GUI on user interface 210 that is shown to the user making the request. The application program 212 may access the DEVMODE structure 242 directly or indirectly by making a request to the DEVMODE structure 242 from the print driver 216. The application program 212 saves the user (and / or default) selection in the DEVMODE structure 242 to create a job settings version. The application program 212 passes the job setting version of the DEVMODE structure 242 to the print driver 216 for further processing.
V. DEVMODE update

  FIG. 5 is a block diagram illustrating how the DEVMODE data structure is updated according to one embodiment of the present invention. In step 1, the web service enabled print device 204 generates an event indicating a change in print function or option. This may include deleting, adding or changing print functions or options. The port monitor and WSD API module 222 has reserved to receive this event and receives this event. For example, the port monitor and WSD API module 222 may receive the event notification in the form of a SOAP message that identifies the event.

  In step 2, the port monitor and WSD API module 222 receives the event notification and notifies the spooler 224. In step 3, the spooler 224 notifies the print driver 216. In step 4, the print driver 216 sends (via the spooler 224 of step 5) a request to the port monitor and WSD API module 222 for the device capabilities of the web service capable print device 204. The request may be implemented, for example, by a call to a SendRecvBiDiData function that includes a request for device capability data for the web service enabled print device 204. In this state, the SendRecvBiDiData function calls the port monitor and WSD API module 222.

  In step 6, the port monitor and WSD API module 222 generates a SOAP request based on at least the request received from the print driver 216 in the form of a SOAP envelope and forwards the SOAP request to the web service enabled print device 204. To do.

  In step 7, the web service enabled print device 204 generates a SOAP response (in the form of a SOAP envelope) containing the device capabilities data of the web service enabled print device 204 and sends it to the port monitor and WSD API module 222. The device capability data of the web service enabled print device 204 identifies functions and options currently supported by the web service enabled print device 204. Depending on the particular implementation, the device capability data in the SOAP response may include all or any portion of the device capability data available to the web service enabled print device 204. For example, the device capability data read in response to the event notification may include all of the device capability data available to the web service compatible print device 204. Alternatively, only device capability data corresponding to changes in functionality or options may be read from the web service enabled print device 204. In addition, device capability data may be read using any number of SOAP requests and responses. The SOAP response may also include a default print ticket that specifies default options for the web service enabled print device 204.

  In step 8, the port monitor and WSD API module 222 sends a response including the device capability data of the web service enabled print device 204 to the print driver 216 (via the spooler 224 of step 9). In this case, the port monitor and WSD API module 222 may extract XML information from the SOAP response and generate a response including the extracted information. If the request is implemented using a SendRecvBiDiData function call, the response to the function call includes device capability data from the web service enabled print device 204.

  In step 10, the DEVMODE generation module 219 generates a DEVMODE structure 242 based at least on the printer description data 238 generated from the device capability data read from the web service compatible print device 204. The DEVMODE generation module 219 also stores the DEVMODE structure 242 in the registry 236 as described earlier in this specification. Alternatively, the DEVMODE generation module 219 may update the existing DEVMODE structure 242 to reflect changes in functionality and / or options supported by the web services enabled print device 204.

  In embodiments where the DEVMODE generation module 219 updates an existing DEVMODE structure, the particular print function (eg, punching) indicated by the printer description data 238 is defined in the public portion of the DEVMODE structure 242. If not, the private portion of DEVMODE structure 242 may be updated to indicate that particular print function.

  In step 11, the application program 212 makes a request for the DEVMODE structure 242 to the print driver 216. In step 12, the print driver 216 retrieves the DEVMODE structure 242 from the registry 236 and sends the DEVMODE structure 242 to the application program 212. The application program 212 generates a GUI in the user interface 210 so that the user can see the features and options supported by the web service enabled print device 204. In step 13, the application program 212 generates an option selected version of the DEVMODE structure 242 based on the user's (and / or any default) selection and print data to the print driver 216 and the DEVMODE structure 242. Send option selection version. The print driver 216 generates a print job ticket based on the option selection version.

  Alternatively, in connection with steps 11-13, the application program 212 requests the print driver 216 to generate a GUI. In response, the UI module 218 generates a GUI based on the DEVMODE structure 242. The user selects one or more function options displayed on the GUI. The UI module 218 stores the user's (and any default) selection in an optional selection version of the DEVMODE structure 242. The print driver 216 then generates a print job ticket based on the option selection version. In this scenario, the option selection version is the job setting version of the DEVMODE structure 242.

  In a related embodiment, the option-selected version of DEVMODE structure 242 is the default setting version of DEVMODE structure 242. For example, whenever a user creates a print job, the user wants to see a particular setting. Thus, the user selects a particular function and option, and this selection is saved as the default setting of the DEVMODE structure 242. Thereafter, when the user creates a print job, the application program 212 or the UI module 218 generates a user interface indicating default settings based on the default setting version of the DEVMODE structure 242.

  FIG. 6 is a flowchart illustrating at least two scenarios in which a DEVMODE structure 242 is created or updated in accordance with one embodiment of the present invention. In step 610, the new function is plugged in (or added) to the web service enabled print device 204. The process proceeds to step 620 or step 630. At step 620, the print driver 216 is installed on the client device 202. In step 630, the web service enabled print device 204 generates a device capability change event and sends the event to the client device 202. The process proceeds to step 640 from either step 620 or 630. In step 640, the print driver 216 retrieves the print device capability data 228 from the web service enabled print device 204. In step 650, print driver 216 (or DEVMODE generation module 219) generates or updates DEVMODE structure 242 based on the set of functions and options indicated in print device capability data 228. Accordingly, the print driver 216 responds to the installed print driver or generates the latest version of the DEVMODE structure 242 in response to the device function change event.

  FIG. 7 is a block diagram illustrating a user interface 700 based on a novel device function, according to one embodiment of the present invention. Each device function is usually associated with multiple options. One of them is selected for the function of the print job. In this example, the new device function is “HolePunch”. It is depicted as “Punch” in the UI 700. The various options associated with this new device function are “OFF”, “Left2”, “Top2”, “Right2”, “Left3”, “Top3”, “Right3” and “Left4”.

  FIG. 8 is a sequence diagram representing a method for updating DEVMODE structure 242 based on a new device capability and corresponding options, according to one embodiment of the present invention. In step 1, the web service enabled print device 204 generates an event indicating a change in print function or option. This may include deleting, adding or changing device capabilities or options. The port monitor and WSD API module 222 has reserved to receive this event and receives the event. For example, the port monitor and WSD API module 222 may receive the event notification in the form of a SOAP message that identifies the event.

  In step 2, the port monitor and WSD API module 222 receives the event notification and notifies the spooler 224. In step 3, the spooler 224 notifies the UI module 218. In step 4, the UI module 218 sends a request to the port monitor and WSD API module 222 (via the spooler 224 of step 5) for the device capabilities of the web service enabled print device 204. The request may be implemented, for example, by a call to the SendRecvBiDiData function that includes a request for device capability data for the web service enabled print device 204. In this state, the SendRecvBiDiData function sends a call to the port monitor and WSD API module 222.

  In step 6, the port monitor and WSD API module 222 generates a SOAP request in the form of a SOAP envelope based on at least the request received from the UI module 218 and forwards the SOAP request to the web service enabled print device 204. .

  In step 7, the web service enabled print device 204 generates a SOAP response that includes the device capabilities data of the web service enabled print device 204 (in the form of a SOAP envelope) and sends it to the port monitor and WSD API module 222. The device capability data of the web service enabled print device 204 identifies one or more functions and options currently supported by the web service enabled print device 204. Depending on the particular implementation, the device capability data in the SOAP response may include any part or all of the device capability data available to the web service enabled print device 204. For example, the device capability data read in response to the event notification may include all of the device capability data available to the web service compatible print device 204. Alternatively, only device capability data corresponding to changes in functionality or options may be read from the web service enabled print device 204. In addition, device capability data may be read using any number of SOAP requests and responses.

  In step 8, the port monitor and WSD API module 222 sends a response including the device capability data of the web service enabled print device 204 to the UI module 218 (via the spooler 224 of step 9). This may include the port monitor and WSD API module 222 extracting XML information from the SOAP response and generating a response that includes the extracted information. In situations where the request is implemented using the SendRecvBiDiData function call, the response to the function call includes device capability data from the web service enabled print device 204.

  In step 10, the UI module 218 generates the printer description data 238 for the web service enabled print device 204, as previously described herein, and stores the printer description data 238 in the registry 236. save. Alternatively, the UI module 218 updates the existing printer description data of the web service enabled print device 204 to reflect changes in functionality and / or options made to the web service enabled print device 204. Also good.

  In step 11, the DEVMODE generation module 219 generates a new DEVMODE structure 242 (or updates an existing DEVMODE structure 242 based at least on new, deleted, or changed functions).

In step 12, the application program 212 requests a DEVMODE structure 242 from the print driver 216. A user interface is then generated based on the new (or updated) DEVMODE structure 242.
VI. Implementation mechanism

  According to one embodiment, the techniques described herein are implemented by one or more special purpose computing devices. A special purpose computing device is a hardwired device that implements the technology, or a digital electronic device (eg, one or more application specific integrated circuits (ASICs) or fields permanently programmed to implement the technology) Programmable gate arrays (FPGAs)). Alternatively, it may include one or more general purpose hardware processors programmed to perform the techniques in accordance with program instructions stored in firmware, memory, other storage devices, or combinations thereof. This type of special purpose computing device may also be combined with custom hardwired logic, ASICs or FPGAs, including custom programming, to accomplish this technology. This special purpose computing device may be a desktop computer system, portable computer system, portable device, network device or any other device that incorporates hardwired and / or program logic to implement the present technology.

  For example, FIG. 9 is a block diagram that illustrates a computer system 900 upon which an embodiment of the invention may be implemented. Computer system 900 includes a bus 902 or other communication mechanism for communicating information, and a hardware processor 904 for processing information coupled to bus 902. The hardware processor 904 may be a general-purpose microprocessor, for example.

  Computer system 900 also includes main memory 906. For example, a random access memory (RAM) or other dynamic storage device connected to bus 902 for storing information and instructions executed by processor 904. Main memory 906 may also be used to store temporary numeric variables or other intermediate information during execution of instructions executed by processor 904. When such instructions are stored on a storage medium accessible by processor 904, computer system 900 becomes a customized special purpose machine for performing the operations specified by the instructions.

  Computer system 900 further includes a read only memory (ROM) 908 or other static storage device connected to bus 902 for storing static information and instructions for processor 904. A storage device 910 (eg, a magnetic disk or optical disk) is installed and connected to the bus 902 for storing information and instructions.

  The computer system 900 may be connected via a bus 902 to a display device 912 (eg, a cathode ray tube (CRT)) for displaying information to a computer user. Input device 914 includes alphanumeric characters and other keys and is connected to bus 902 for communicating information and instruction selections to processor 904. Other types of user input devices include cursor controls 916, such as a mouse, trackball or cursor direction keys. These are for communicating direction information and command selections to the processor 904 and for controlling cursor movement on the display device 912. This input device typically has two degrees of freedom in two axes. With the first axis (eg, x) and the second axis (eg, y), the device can locate the plane.

  Computer system 900 may implement the techniques described herein using customized hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic. These are combined with a computer system, and the computer system 900 is programmed as a special purpose machine. According to one embodiment, the techniques herein are performed by computer system 900 in response to processor 904 executing one or more sequences of one or more instructions stored in main memory 906. This type of instruction may be read into the main memory 906 from another storage medium (for example, the storage device 910). By executing the sequence of instructions stored in the main memory 906, the processor 904, in an alternative embodiment for performing the process steps described herein, is a hardwired circuit as an alternative to software instructions. Or a combination thereof.

  The term “storage medium” as used herein refers to any medium that stores data and / or instructions that cause a device to perform a specific operation. This type of storage medium may include non-volatile media and / or volatile media. Non-volatile media includes, for example, optical or magnetic disks (eg, storage device 910). Volatile media includes dynamic memory (eg, main memory 906). The usual forms of storage media are, for example, floppy disks, flexible disks, hard disks, solid state drives, magnetic tape, any other magnetic data storage medium, CD-ROM, any other optical data storage medium, hole Any physical media having a pattern, RAM, PROM, EPROM, FLASH-EPROM, NVRAM, or any other memory chip or cartridge is included.

  The storage medium is distinguished from the transmission medium, but may be used in conjunction with the transmission medium. Transmission media contributes to transferring information between storage media. For example, transmission media include coaxial cable, copper wire, and optical fiber. And the conducting wire which has the bus 902 is included. Transmission media can also take the form of acoustic or light waves. For example, it can take the form generated between radio waves and infrared data communications.

  Various forms of media can cause processor 904 to execute one or more sequences of one or more instructions. For example, the instructions may initially be stored on a remote computer magnetic disk or solid state drive. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem in proximity to computer system 900 can receive data on the telephone line and can use an infrared transmitter to convert the data to an infrared signal. The infrared detector can receive the data on the infrared signal and an appropriate circuit can send the data to the bus 902. Bus 902 carries data to main memory 906, from which processor 904 reads and executes instructions. The instructions received by main memory 906 may optionally be stored on storage device 910 either before or after execution by processor 904.

  Computer system 900 also includes a communication interface 918 connected to bus 902. Communication interface 918 connects to network link 920 to provide bi-directional data communication. Network link 920 is connected to local network 922. For example, communication interface 918 may be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem that provides a data communication connection to a corresponding telephone line. As another example, communication interface 918 may be a local area network (LAN) card that provides a data communication connection to a compatible LAN. A radio link may also be implemented. In any type of implementation, the communication interface 918 carries a digital data stream that includes various forms of information such as electrical, electromagnetic, and optical signals.

  Network link 920 typically provides data communication over one or more networks to other data devices. For example, the network link 920 may provide a connection via the local network 922 to the host computer 924. Alternatively, a connection may be provided to a data device operating by an Internet service provider (ISP) 926. ISP 926 provides data communication services through a global packet data communication network. This is now commonly called the Internet 928. Local network 922 and Internet 928 both carry digital data streams using electrical, electromagnetic, and optical signals. Signals from various networks, as well as signals on network link 920 and via communication interface 918 are examples of transmission media for transmitting and receiving digital data to and from computer system 900.

  Computer system 900 can send messages and receive data via network, network link 920, and communication interface 918. This includes program code. In the Internet example, the server 930 can send the requested code for the application program via the Internet 928, ISP 926, local network 922, and communication interface 918.

  The received code may be received as is and executed by processor 904 and / or stored in storage device 910 or other non-volatile storage for later execution.

  In the foregoing specification, description has been made with reference to specific details that may vary from implementation to implementation. Thus, the only indication of what is the invention, and the invention intended by the applicant, is based on a set of claims issued from this application. This includes subsequent corrections. Any explicit definitions of terms contained in a claim shall have their meanings as used in the claims. Hence, no limitation, element, property, function, advantage, or attribute that is not expressly specified shall limit the scope of the claims in any way. The specification and drawings are, therefore, exemplary and are not to be construed as limiting.

900 Computer system 902 Bus 904 Processor 906 Main memory 908 ROM
910 Storage device 912 Display device 914 Input device 916 Cursor control 918 Communication interface 920 Network link 922 Local network 924 Host computer 928 Internet 930 Server

US Patent Application No. 12 / 399,884 (filed March 6, 2009)

Claims (14)

A computer-implemented method for printing on a printing device, comprising:
A print driver executing at the client device and receiving from the print device print device capability data identifying a plurality of functions and options currently supported by the print device;
Responsive to receiving the print device capability data, the print driver generating a second version of the DEVMODE data structure that is different from the first version of the DEVMODE data structure;
The first version indicates a first plurality of functions previously supported by the printing device;
The second version indicates a second plurality of functions currently supported by the printing device;
The first plurality of functions is different from the second plurality of functions;
The data of the first part of the second version is shown in a binary format and the data of the second part of the second version is shown in XML;
The computer-implemented method, wherein the second portion indicates a particular print function and one or more options for the particular print function indicated in the print device capability data. Generating a user interface based on the second version of the DEVMODE data structure;
Responsive to one or more user selections, generates a third version of a DEVMODE data structure indicating that an option has been selected for each function of the second set of functions. Steps and;
The computer-implemented method according to claim 1, further comprising: The step of generating the user interface includes:
(A) the print driver generating the user interface; or (b) an application program requests the DEVMODE data structure from the print driver and the print driver from the DEVMODE data structure. Generating the user interface after receiving the second version;
The computer-implemented method of claim 2, comprising at least one of the following: The print driver (a) generates a print job ticket based on at least the third version of the DEVMODE data structure; and (b) sends the print data and the print job ticket to the printing device. A step of making it possible; or
Generating a user interface based at least on the third version of the DEVMODE data structure;
The computer-implemented method according to claim 1, further comprising: The steps of receiving the print device capability data include:
Responsive to the print driver receiving an event notification message from the print device indicating a change related to the print device and complying with a web service event specification; and receiving the event notification message; The print driver sending a request message to the printing device requesting one or more printing functions supported by the printing device;
The computer-implemented method of claim 1, which is activated in response to   The computer-implemented method of claim 1, wherein the step of receiving the print device capability data is initiated in response to installation of the print driver by the client device. The first plurality of functions includes a first specific function not included in the second plurality of functions; or
The second plurality of functions includes a second specific function that is not included in the first plurality of functions.
The computer-implemented method according to claim 1.   The program which makes a computer perform the method as described in any one of Claims 1 thru | or 7. An apparatus for printing on a printing device,
A print driver receives print device capability data that is executed at the client device and identifies a plurality of functions and options currently supported by the print device;
In response to receiving the print device capability data, the print driver generates a second version of the DEVMODE data structure that is different from the first version of the DEVMODE data structure;
The first version indicates a first plurality of functions previously supported by the printing device;
The second version indicates a second plurality of functions currently supported by the printing device;
The first plurality of functions is different from the second plurality of functions;
The second version of the first part of the data is shown in binary format and the second version of the second part of the data is shown in XML;
The apparatus wherein the second portion indicates a particular print function and one or more options for the particular print function indicated in the print device capability data. The apparatus of claim 9, comprising:
Generating a user interface based on the second version of the DEVMODE data structure;
Responsive to one or more user selections, generates a third version of a DEVMODE data structure indicating that an option has been selected for each function of the second set of functions. ,apparatus. The apparatus of claim 10, comprising:
When generating the user interface:
(A) a process in which the print driver generates the user interface; or (b) an application program requests the DEVMODE data structure from the print driver and the print driver sends the DEVMODE data structure. Processing to generate the user interface after receiving version 2;
An apparatus that performs at least one of the processes. The apparatus of claim 10, comprising:
The print driver (a) generates a print job ticket based on at least the third version of the DEVMODE data structure; and (b) sends the print data and the print job ticket to the printing device. Processing to make it possible; or
Generating a user interface based at least on the third version of the DEVMODE data structure;
Further perform the device. The apparatus of claim 9, comprising:
The process of receiving the print device capability data is:
In response to the step of receiving an event notification message from the print device, indicating a change related to the print device, and complying with a web service event specification; and receiving the event notification message; A process in which the print driver sends a request message requesting one or more print functions supported by the print device to the print device;
A device that is activated in response to   The apparatus according to claim 9, wherein a process for receiving the print device capability data is activated in response to installation of the print driver by the client device.

Images