Approach for providing service workflows through devices

An approach for providing service workflows through devices includes a service server determining that a service is available for a particular device. In response to determining that the service is available for the particular device, the service server obtains, from the particular device, service information that specifies, for the service, at least one or more processes that implement the service on the particular device, one or more parameters for the one or more processes and one or more user interfaces for the one or more processes. The service server generates, based upon the service information, a service application that implements the service. The service server receives, from a client device, a request to use the service for the particular device and in response, the service server provides to the client device the service application that implements the service.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to U.S. patent application Ser. No. 13/560,994,filed Jul. 28, 2012, which is a continuation-in-part application of U.S. patent application Ser. No. 13/333,454, filed Dec. 21, 2011, the entire contents all of which are hereby incorporated by reference as if fully set forth herein for all purposes.

FIELD

Embodiments relate to network service management and, more particularly, to retrieving information about multiple network services and integrating that information in a user-friendly way to end-users in order to use one or more of the network services.

BACKGROUND

Due to the Internet and Web technologies, the number of network services has been growing rapidly. Most users, after discovering a network service (e.g., a translation service) with which they are satisfied, will return to that service whenever they have a need for that particular service. However, such a one-application-per-service model has become cumbersome for users as there are thousands of services available on the Internet. Keeping tracking of all the available network services is difficult for even experienced Web users.

Furthermore, if there are multiple network services that provide a similar service and a user desires to use one of them, then the user must individually examine each network service separately and remember (or record) all the features and options provided by each in order to compare the network services and determine which network service to use. Also, each network service provides its own user interface (UI), with which the user must become familiar.

Additionally, some network services require a client-side program, such as a driver or other third party software, to execute on a client device in order for a user to utilize the network services. Thus, a user might have to manually install, into the local operating system of the user's device, a driver or third party application program for each network service, assuming that a driver or third party application program is available for each network service.

SUMMARY

An approach for providing service workflows through devices includes a service server determining that a service is available for a particular device. In response to determining that the service is available for the particular device, the service server obtains, from the particular device, service information that specifies, for the service, at least one or more processes that implement the service on the particular device, one or more parameters for the one or more processes and one or more user interfaces for the one or more processes. The service server generates, based upon the service information, a service application that implements the service. The service server receives, from a client device, a request to use the service for the particular device and in response to receiving, from the client device, the request to use the service for the particular device, the service server providing to the client device the service application that implements the service. The approach may be implemented by instructions stored on one or more computer-readable media, by one or more devices, or by one or more computer-implemented methods.

DETAILED DESCRIPTION

GENERAL OVERVIEW

Embodiments include an integrated service feature gathering and selection system. In an embodiment, a single, combined UI for managing multiple network services is presented. In an embodiment, an application program system dynamically queries and updates itself (e.g., automatically or upon being requested) with all connected network service information across mobile or business network environments. The application program system simplifies the process of multi-service management and provides a straight-forward user experience under complicated network environments.

In an embodiment, an application program enables a computer operating system (OS) to manage multiple network services in dynamic environments. Network services can be connected via a local Ethernet network or via a remote network through internet protocol. An OS might assign a unique port for each connected network service and provide APIs for data communication. The application program provides a unified, feature-oriented UI for multiple network services and automatically selects a network service according to a user's selections.

In a related embodiment, a client device executes a browser that requests a unified, feature-oriented UI for multiple network services and automatically selects a network service according to the user's selections.

Service Feature Gathering and Selection System

FIG. 1is a block diagram that depicts an example service feature gathering and selection system100, according to an embodiment. System100comprises a service server110, an integrated service client112, network services120A-E, network122, local connection124, unified service UIs130A-C, and client devices140A-C.

Service server110is a network device that comprises one or more processors and memory and that is communicatively coupled to network services120A-E and client devices140A-C. Service server110communicates with network service120A via network122and communicates with network services120B-E and user client130A-C via a local connection124. Examples of network122include, without limitation, a Wide Area Network (WAN), the Internet, or one or more terrestrial, satellite or wireless links. Examples of local connection124include, without limitation, a Local Area Network (LAN), Ethernet, or one or more terrestrial, satellite or wireless links.

Service server110receives service capabilities data from network services120A-E. Services capabilities data is data that specifies a network service's currently supported features and options, i.e., allowed values for each feature, of network services120A-E. Because the number and type of network services120A-E are virtually limitless, examples of network service features are similarly virtually limitless. In the print context, example features include paper size, orientation, duplex, print quality, color, etc. Each feature has one or more options, i.e., values. For example, duplex unit has two options, such as “Installed” or “Not Installed.” Other features, for example, paper size, may have many options, e.g., “A4”, “legal”, “8½×11”, etc.

Embodiments are not limited to any particular technique for communicating between service server110and network services120A-E in order for service server110to obtain service capabilities data about network services120A-E. For example, such communication might be achieved through Simple Network Management Protocol (SNMP) or Web Services for Devices (WSD) technologies. Recent development of WSD technologies on a network provides opportunities for more advanced device management (e.g., relative to SNMP). Such development allows any network service to report its full service capabilities during the establishment of a connection between the network service and another network service, such as a network server. Thus, service server110might communicate with network service120A using one communications protocol (in order to receive service capabilities data and, optionally, send service jobs or requests) and might communicate with network service120B using a different communications protocol.

Service server110may automatically detect one of network services120A-E, whether the detection is initiated by service server110or the network services themselves. Additionally or alternatively, service server110may be notified of one or more of network services120A-E by an administrator. Upon detection, service server110queries the detected network service (local or remote) for information about the network service including, but not limited to, service features and options and other capabilities supported by the network service.

Based on the service capabilities data, service server110generates integrated service client112. Service server110then sends integrated service client112to one or more of client devices140A-C. Additionally or alternatively, service server110sends the service capabilities data to one or more of client devices140A-C that (already) execute an integrated service client at the time service server110receives the service capabilities data. Such “already-existing” integrated service clients are automatically updated to include the new service capabilities data.

The functionality of service server110may be implemented using stored program logic, in a special-purpose computer or loaded from one or more non-transitory media into the memory of a general-purpose computer and then executed.

Client devices140A-C may be implemented as any type of client device. Examples of client devices140A-C include, without limitation, personal or laptop computers, workstations, tablet computers, cellular telephony devices such as cell phones, personal digital assistants (PDAs), etc.

Service server110builds an information database and creates various data structures (e.g., an XML file) for integrated service client112. Such data structures may be accessed by UI components of integrated service client112when client112displays an integrated UI to a user of one of client devices140A-C.

After integrated service client112is received by and installed at client devices140A-C, service client112displays an integrated UI that contains features from multiple network services (e.g., network services120A-E). Some features on the UI are automatically enabled or disabled based on a feature set a user has previously selected and whether any network services can support the selected feature set. Based on the feature set of the user's selection, service client112's UI determines which network service will be used, and then saves the feature set to a destination service job ticket. A rendering component of service client112sends a service job to a network service (e.g., network service120C) defined in the service ticket.

The service job ticket is in a form that is recognizable by the target network service. For example, if the network service is a web site, then the service job ticket may be a Uniform Resource Location (URL) that includes parameters and/or other URL components that identify or correspond to selected features and options. In response to receiving the generated URL, the network service provides content (e.g., a web page) that the client device displays in a web browser or a separate application that is dedicated to the network service.

In a related embodiment, instead of generating and sending an integrated service client112to each client device140, service server110provides a web service that client devices140A-C access, for example, via a web browser or a dedicated application. In this way, integrated service client112would not have been updated whenever a new network service is discovered or an additional feature is supported by a known network service.

Service Client Components

FIG. 2is a block diagram that depicts example components of a service server210and of an integrated service client230, according to an embodiment. Service server210may be the same server as service server110. Service server210includes service information databases212A-C, one for each of network services220A-C. Thus, service information database212A contains information about network service220A, service information database212B contains information about network service220B, and so forth. Although depicted as separate databases212A-C, databases212A-C may be stored on the same storage device (not depicted).

According toFIG. 2, service server210communicates with network service220A and220C using Web Services Discovery in order for service server210to retrieve information (including features and options) about network service220A and220C. Web Service Discovery is one example of a standard discovery protocol that service server210and network service220A and220C implement, or at least a version thereof. Also, service server210communicates with network service220B using SNMP (or Simple Network Management Protocol).

InFIG. 2, integrated service client230executes on a client device and includes four components: integrated UI module232, update module234, service query and presenting module236, and target service ticket management module238. Integrated UI module232generates a user interface (UI) and causes the UI to be displayed on a screen of the client device upon which integrated service client230is installed. Update module234is responsible for obtaining information from service server210about one or more network service that service server210discovers after integrated service client230is installed on the client device.

Service query and presenting module236receives feature selections (whether user selected, default, or a combination of both), determines which network service of multiple network services to use, and generates a service job that reflects the feature selections and, optionally, one or more documents. Service query and presenting module236passes the service job to integrated target service ticket management module238. The service job is reflected in the service request. The format of the service request varies depending on the type of network service and/or the communications protocol required to communicate with the selected network service. For example, if the network service is a web site, then the service request may be reflected in an HTTP request message. If the network service is a web service, then the service request may be reflected in a SOAP message.

Integrated service port management module238is responsible for sending the service job to the appropriate network service. Integrated service port management module238may implement one or multiple communication protocols in order to send the service job to the appropriate network service. For example, service client230might send one service job to a first network service identified in service client230via Web Services Device port and service client230might send one service job to a second network service identified in service client230via a TCP/IP port.

Network Service Information Data Flow

FIG. 3is a block diagram that depicts a data flow of network service information from multiple network services310A-D to a service server320, according to an embodiment. Service server320may be the same server as service server210and/or service server110. Each network service310sends a set of service information to service server320. For example, network service310A sends service information set312A to service server320, network service310B sends service information set312B to service server320, and so forth. Network services310A-D may communicate with service server320using one of communication methods, such as USB (or Universal Serial Bus), wireless TCP, and wired TCP, or the Internet. AlthoughFIG. 3depicts four network services310A-D, other embodiments may include more or fewer network services.

Service server320receives service information sets312A-D and, in an embodiment, applies one or more filter criteria to service information sets312A-D. The one or more filter criteria may be used to identify which network services are not allowed to be used (or “seen”) by client devices that are connected to service server320. In this embodiment, service server320compares the one or more filter criteria to one or more attributes of a network service (e.g.,310A), which are reflected in a service information set (e.g.,312A) received from that network service. Example filter criteria include whether the network service supports a certain security policy or any security, whether the network service supports a particular page description language (PDL), or whether the network service is from a particular domain or subdomain. Additionally or alternatively, one or more filter criteria includes a list of network services that are allowed to be used by client devices that are connected with service server320(e.g., a “white” list) or a list of network services that are not allowed to be used by client devices that are connected to service server320(e.g., a “black” list).

The one or more filter criteria may be established by a company administrator, or an administrator that is authorized by a business entity that owns and/or manages service server320.

If a network service is not “filtered out” after the filter stage, then service server320stores the service information set of that network service in a service feature database322. The data stored therein is referred to as the server generic service description data (or “Server GSDD”). The Server GSDD, on a server when a client device is connecting to a corporate domain network, or on the client device when the client device is disconnected from a corporate domain network, defines information on all network services (whether connected or not connected) that are available for all users of that client device.

In an embodiment, service information sets of network services that are “filtered” out after the filter stage are stored separate from the Server GSDD. Such storage may be on the same storage device that stores on the Server GSDD or on a different storage device. Such service information sets may be maintained if, for example, the one or more filter criteria are later changed or updated, for example through user input. In such a scenario, the “excluded” service information sets may be evaluated again based on the updated filter criteria. Such a re-evaluation might be triggered based on the changing of the one or more filter criteria. One or more of the excluded service information sets might then pass the filter stage and end up being stored as part of the Server GSDD.

In an embodiment, the Server GSDD may be filtered based on one or more additional filter criteria. Such additional criteria may be established by a client administrator, who may be the same or different than the administrator that defines the filter criteria referenced above. Examples of such additional filter criteria include those criteria described previously and whether a particular user is allowed to use a particular network service, which may be determined in multiple ways, such as a pre-defined list of network services that the particular user is allowed to use. The service information sets of network services that are not “filtered out” by this additional filter criteria are referred to as “Client GSDD.” Client GSDD324is a subset of the Server GSDD and defines information on all network services (whether connected or not) that are available for a particular user. Thus, each client device that is communicatively coupled to (or registered with) service server320might receive a different Client GSDD. For example, the Server GSDD may include information only about network services310A-C and not network service310D. Afterward, Client GSDD324for one client device might include information only about network services310A-B while Client GSDD324for another client device might include information only about network services310A and310C.

The Client GSDD324of a particular user becomes part of an integrated service client (whether generated by service server320or another entity) that is installed on a client device of the particular user. Alternatively, in a non-client scenario, client GSDD324is stored for each client device. If multiple client devices are associated with the same network services, then a single client GSDD may be associated with the multiple client devices.

In an embodiment, the Client GSDD324is filtered by one or more filter criteria that are defined by the associated user. For example, the associated user might indicate that s/he only wants to see information about network services that are of a particular type (e.g., educational, entertainment), that are free, and that provide video content. Whichever service information sets satisfy the filter criteria defined by the user will be part of a “UI GSDD”326. The UI GSDD326for a particular user defines information on all connected network services that are available for the particular user. The UI GSDD326may be updated in real-time as the particular user makes selections about what characteristics or attributes a set of network services must have in order to be candidate network services for service jobs that are initiated by the particular user.

“Adding” a New Network Service to a Service Server

A network service is “added” to a service server when a service server obtains details about the network service, such as an address (e.g., IP or MAC) of the network service, communication protocol(s) that the network service supports, and set of features and options that the network service supports.

FIG. 4is a flow diagram that depicts a process400for adding a connected network service to a service server, according to an embodiment. At step410, a user provides, to service server, input about a new network service. Such input might include a network IP, an Internet IP or a MAC address of the network service. The network service may be local to (i.e., on the same network as) or remote to (i.e., not on the same network as) the service server.

Alternatively, step410comprises the service server automatically detecting the new network service. Such automatic detection may be achieved in multiple ways. For example, upon the new network service entering the network, the new network service implements a Web Services Discovery specification by transmitting a HELLO multicast message to devices on the network. The service server receives the HELLO message, responds with a message that identifies the service server. If both the service server and the new network service implement a Web Services Metadata Exchange specification, then the service server sends a metadata request message to the new network service in order to retrieve information about how to request certain information about the new network service, such as capabilities data.

At step415, the service server sends a request to query the new network service for certain information, such as capabilities data of the network service, any security protocols the network service supports, etc.

At step420, it is determined whether a log-in is required. If so, then process400proceeds to step425where a log-in screen is displayed and user credential information is saved, after which process400proceeds to step430. If a log-in is not required, then process400proceeds to step430, where the service server queries the service information of the new network service.

At step435, the service server applies an administrative policy to at least some of the information retrieved from the network service. The administrative policy may indicate that the network service must support a certain type of secured connection and that the network service appears on trusted service provider list.

At step440, the service server determines, based on the administrative policy, whether the network service should be added to the Server GSDD. If not, then process400proceeds to step445, where the service server causes a message to be displayed that indicates that the “add” operation is denied. If the service server determines that the network service should be added to the Server GSDD, then process400proceeds to step450.

At step450, the service server builds the Server GSDD database. This step may comprise adding the retrieved information about the new network service to the Server GSDD database.

At step455, the service server uses another policy to determine whether the new network service should be added to a client GSDD. The other policy may be defined by a client administrator and determines whether a client device is able to “see” certain network services. If the result of step455is in the negative, then process400proceeds to a point prior to step410, indicating that further input regarding a new network service is required to proceed. If the result of step455is in the affirmative, then process400proceeds to step460.

At step460, the service server rebuilds a Client GSDD. This step may comprise adding the retrieved information about the new network service to an existing Client GSDD.

At step465, the service server sends the retrieved information to an operating system of a client device that executes a service client. At step470, the operating system updates the service client based on the retrieved information. Alternatively, a user might decide to update the service client at a later time.

Creating User Interface Data

FIG. 5is a sequence diagram that depicts a process500for creating user interface data, according to an embodiment.

At step1, a service server520sends one or more queries to network service510in order to receive information about network service510, including capabilities of network service510. One or more techniques may be used to send the one or more queries, including, but not limited to, a WS Discovery query, OS network API, etc.

At step2, network service510sends, to service server520, the information that service server520requested.

At step3, service server520checks one or more company or domain administrative policies and builds (or rebuilds) a Server GSDD based on the retrieved information.

At step4, service server520checks a client policy and builds (or rebuilds), based on the retrieved information, a Client GSDD for each user that is authorized to use network service510.

At step5, service server520sends the retrieved information to one or more service clients530via, for example, an OS of each client device of the one or more corresponding client devices. An OS, in turn, notifies a client update module that is part of the service client530.

At step6, service client530rebuilds an existing UI GSDD.

At step7, service client530updates the client's UI to reflect the one or more features of the new network service510. If a client UI module of service client530is already processing a job, then service client might include adequate solutions to ensure that the new UI update does not affect existing service jobs.

FIG. 6is a block diagram that depicts example generic service description data for each of a server, a client, and a user interface, according to an embodiment.FIG. 6depicts an example Server Database (or GSDD)610, an example Client Database620, and an example Client UI Database630. Although databases610-630are in an XML format, embodiments are not limited to GSDDs in an XML format. Alternative formats are possible.

In this example, each of databases610-630include the same information of a network service, such as attributes of the network service (e.g., name, IP address, payment type, category type, connection type, ID, etc.) and capabilities data that includes three feature options. Also, each of databases610-630includes a different value for the ServiceData Value. Specifically, Server Database610indicates “Server level” as the value for the ServiceData Value, Client Database620indicates “Client Level” as the value for the ServiceData Value, and Client UI Database630indicates “UI level” as the value for the ServiceDataValue.

Example Service Client User Interface

FIG. 7is a block diagram that depicts an example user interface700, according to an embodiment. User interface700may be generated by a UI module of a service client. Alternatively, user interface700is provided by a web server hosted by service server110. A web browser on a client device may request user interface700from the web server over a network. Alternatively, a client device executes a non-browser application (e.g., a “smartphone” application) that requests user interface700from service server110over network. Regardless of how user interface700is displayed on a client device, the data used to populate user interface700may originate from a UI GSDD.

User interface700comprises four parts or regions: service selection filter preference710, a service feature/option list720, a service provider list730, and a service feature set740.

Service selection filter preference710defines service attributes/characteristics that are used to exclude some network services that a user does not intend to use. The service preferences of a network service (such as the type of connection or name of service provider) are not related to the actual service(s) that the network service provides. In contrast, service features/options are related to what a network service provides.

For example, a user may select “IP List Approved by Company” from the “Connection” preference as a filter, which causes only service providers that are listed on the “IP List” to be displayed as possible service providers in service provider list730. If one or more service providers are excluded as a result of that user selection, then service feature/option list720may be dynamically updated to reflect the new (updated) set of potential service providers.

In the depicted example, the service preferences are that the network service may have any type of connection, may have any type of security, may have any type of log-in credentials, must be from the Spelling Translation and/or Child Education categories, may be any service provider, and must be a free service. However, if the “Any Services” filter preference is selected, then user interface700may be dynamically updated to list all network services in service provider list730(unless some features/options are already selected in service feature/option list720) and all possible service features/options in service feature/option list720.

Service feature/option list720lists multiple (or all) features and options supported by a set of one or more network services that are determined based on a set of selection preferences selected by a user (and/or by default). In an embodiment, each time a user changes a feature or option from service feature/option list720, the resulting set of features is validated by a service client against the capabilities of potential network services (e.g., those indicated in a Client GSDD). If a network service does not support the resulting set of features, then all of that network service's features are disabled in service feature/option list720. However, if there is a network service that does support the resulting set of features, then all of that network service's features are enabled in service feature/option list720.

In this example, service feature/option list720divides service features into five main types: Grade, Academic, Activities, Tutoring, and Event Service. The feature Academic is selected along with the option “Book.” Also, the feature Tutoring is selected along with the option “Learn to Read.”

Service provider list730lists one or more (or all) network services that are within a set of possible destination network services after the user's preferences are defined in service selection filter preference710and service features are selected in service feature/option list720. In the depicted example, five network services are listed in service provider list730. In other words, the five listed network services are identified, from among a larger set of service providers, as satisfying all the selected (whether user-selected and/or default-selected) requirements.

In an embodiment, selection of one of the network services listed in service provider list730causes a web browser to be directed to that network service. In an embodiment, the request for the network service includes one or more features/options that were selected from service feature/option list720. For example, for a web service, an HTTP request is generated that includes one or more parameters that correspond to one or more of the selected features/options. In this way, a user may be presented with the exact information that the user is seeking without requiring the user to further select one or more features/options (at the selected network service) that the user already selected in user interface700.

Service feature set740lists all the features and options provided by the service providers listed in service provider list730. The features and options listed in service feature set740may decrease if the number of service providers listed in service provider list730decreases (e.g., due to a selection in service selection filter preference710or in service feature/option list720). Conversely, the features and options listed in service feature set740may increase if the number of service providers listed in service provider list730increases (e.g., due to a selection in service selection filter preference710or in service feature/option list720).

User interface700also includes five buttons: Add Service button750, Delete Service button760, Auto Detection button770, Customize Selection button780, and Update from Provider button790. In an embodiment, one or more of these buttons are only displayed to an administrator, or a user with administrator rights, not any end-user. Selection of Add Service button750allows a user (or administrator) to manually add a new network service, for example, to a Service GSDD or a Client GSDD. Selection of Delete Service button760allows a user (or administrator) to manually delete a network service, for example, from a Service GSDD or a Client GSDD. Selection of Auto Detection button770causes a service client or a service server to send a HELLO message on a certain (e.g., local) network. The type of messages that may be sent is communication protocol dependent. Selection of Customize Selection button780allows a user (or administrator) to update (e.g., add or remove) service selection filter preference710. Selection of Update from Provider button790causes a service client or a service server to require one or more network services, for example, that are listed in a Service GSDD or a Client GSDD.

Changing a Selection Filter Preference

FIG. 8is a flow diagram that depicts a process800for a user changing a filter preference, according to an embodiment. Process800may be performed by one or more components or modules of a service client, such as service update module234depicted inFIG. 2. Alternatively, process800may be performed by a service server, such as service server220inFIG. 2. Thus, while process800is described from the perspective of a client application, embodiments are not so limited.

At step810, a user changes a UI selection preference. Examples of UI selection preferences include, but are not limited to, location (e.g., URL or IP address), security information, and fee-based service. The user might change the UI selection preference through a UI generated by a service client. As a result of performing step810, the service client might delete all UI GSDD and rebuild it using the following process. Alternatively, the service client might delete, from a UI GSDD one at a time, only information about a network service that the service client determines should not be included in the UI GSDD based on the user's selection preference.

At step820, the service client identifies a network service indicated in a Client GSDD to which the service client has access. The Client GSDD may be stored on the same client device that executes the service client.

At step830, the service client determines whether the network service identified in step820should be displayed in a user interface that a user uses to select features and options for a particular service job. This determination may be made by comparing the current set of selection preferences with attributes/characteristics of the identified network service or by comparing just the changed preference with such attributes/characteristics. If step830results in the negative, then process800proceeds to step840, where information about the identified network service is not included in (e.g., deleted from) the UI GSDD. If step830results in the affirmative, then process800proceeds to step850.

At step850, the service client adds the network service's capabilities (i.e., features and options) into a UI GSDD, from which the service client eventually generates a user interface.

At step860, the service client determines whether information about each network service indicated in the Client GSDD has been analyzed. If not, then process800proceeds to step820. Otherwise, process800proceeds to step870.

At step870, the service client causes all (or many) features and options indicated in the updated UI GSDD to be re-displayed on the client. Only the features and options of network services that are identified in the UI GSDD are displayed. Thus, information about any network services that were not included in the UI GSDD in step850is not displayed to a user of a client device that executes the service client.

At step880, one or more applications that are currently using this service client are notified, e.g., by the service client.

The selection of features and options under an integrated service client approach is different compared to other service clients. To support multiple devices in one user interface, the integrated service client should ensure that every feature set selection by a user is supported by at least one network service. Constraints to features are applied according to service support by any services. In other words, if none of the network services indicated in a UI GSDD supports a particular feature, then that particular feature appears disabled.

FIG. 9is a flow diagram that depicts a process900for a user changing a feature/option on a user interface (UI) of a service client, according to an embodiment. Process900may be performed by one or more components or modules of a service client, such as integrated client UI module232depicted inFIG. 2. Alternatively, process900may be performed by a service server, such as service server220inFIG. 2. Thus, while process900is described from the perspective of a client application, embodiments are not so limited.

At step910, the UI receives, from a user, input that indicates a change in a feature or option. Examples of a change include selecting the “Field Trips” option in the Activities feature of user interface700.

At step920, the service client identifies a network service indicated in a Client GSDD. If there are more than one network service identified in the Client GSDD, then the service client might “loop through” each identified network service. In other words, steps920-960will be performed for each identified network service.

At step930, the service client determines whether the network service identified in step920supports the feature/option selected in step910. If not, then process900proceeds to step940. If so, then process900proceeds to step950.

At step940, the service client disables all features of the network service identified in step920if the network service does not support the feature/option set previously selected by user.

At step950, the service client enables all features for this network service in the UI if the feature set previously selected by user is supported by the network service.

At step960, the service client determines whether all network services have been identified in the Client GSDD. If not, then process900proceeds to step920to identify another network service. Otherwise, process900proceeds to step970.

At step970, for each feature enabled/disabled in the UI, the service client enables or disables that feature in a UI GSDD. Thus, if feature1is enabled in the UI, then the service client enables feature1in the UI GSDD. Conversely, if feature2is disabled in the UI, then the service client disables feature2in the UI GSDD.

Confirm UI Selection

FIG. 10is a flow diagram that depicts a process1000for validating user selections of features of options, according to an embodiment. Process1000may be performed by a service client, such as integrated service client112. Process1000may be performed by one or more components or modules of a service client, such as service query and presenting module236and target service ticket management module238depicted inFIG. 2. Alternatively, process1000may be performed by a service server, such as service server220inFIG. 2. Thus, while process1000is described from the perspective of a client application, embodiments are not so limited.

At step1010, a service client receives, from a user, input that indicates confirmation of the features and options selected for a service job. The input may be the user selecting an “OK” button. This step may be performed by a UI module of the service client, such as UI module232of service client230ofFIG. 2.

At step1020, the service client identifies all features and options that are selected for the service job. Some of the features and options may have been selected by the user while other features and options may have been default selections. Such default selections may have been established in code of the service client and/or established by the user in a previous service selection session. For example, a prior service job includes a set of features and options and those features and options are default selections (as indicated in the client's UI) for the current service job, i.e., before the user has viewed the UI.

At step1030, the service client validates the selected features and options of the service job. For example, if a user selects an feature/option that is not supported by any network service, then the service client may inform the user to change the value before sending a service request to a selected network service.

At step1040, the service client determines whether more than one network service supports the set of selected features and options. If not, then at step1050, the service client selects the one network service. Otherwise, process1000proceeds to step1060.

At step1060, the service client selects a particular network service among the multiple network services that are capable of processing the service job according to the selected set of features and options. This selection may be based on determining which of the multiple network services is free, which provides the most secured connection, which does not require log-in credentials, or any other factor, such as which network service was added most recently, or which network service has the best reputation according to some standard.

At step1070, the service client generates a service job ticket based on the selected features and options.

At step1080, the service client sends the service job ticket to a query and presenting module of the service client, such as service query and presenting module236of service client230ofFIG. 2. The query and presenting module may be implemented as a single module or as multiple modules that each might perform a different type of querying and presenting. Like step1010, steps1020-1080may be performed by a UI module of the service client, such as UI module232of service client230ofFIG. 2. The rendering module converts (1) document data received from and generated by an application (e.g., a Microsoft Word) executing on the client device into (2) print data that the network service is configured to be able to process. The service client might automatically detect the PDL supported by the destination network service and render the job accordingly. For example, the service client might identify an appropriate sub-module that is configured to perform the rendering that is appropriate for the destination network service and cause that sub-module to process the document data to produce the print data in the appropriate format. As another example, the rendering module of the service client might render the service job into a universal format, such as a Bitmap image.

At step1090, the service client sends the service job, which includes the job ticket and the rendered print data, to the network service selected in step1050or step1060. This step may be performed by a port management module of the service client, such as integrated service port management module338ofFIG. 3.

Service Ticket Creation

FIG. 11is a flow diagram that depicts an example of how a service ticket1130is created, according to an embodiment. In this example, services1112-1116are print services. One of the features of each of services1112-1116is output format. Each of services1112-1116supports a different set of options for the output format feature. In the depicted example, service1112supports printing to PCL6, Open XPS, TIFF, PostScript, Bitmap, and JPEG while service1116supports printing to PCL6, TIFF, PDF, Bitmap, and JPEG.

The options supported by each of services1112-1116may be reflected in a UI GSDD, from which is generated integrated UI1120. Integrated UI1120may be generated by a service client application executing on a client device or may be provided, over a network, from a service server that executes remote relative to the client device that displays integrated UI1120.

In the depicted example, integrated UI1120displays 11 different options for the output format feature. A user selects “Open XPS” displayed in the drop down menu of integrated UI1120. Based on this selection (and one or more other selections), service ticket1130is generated.

Service ticket1130may be generated by a service client executing on a client device or by a service server executing on a device that is remote relative to the client device that displays integrated UI1120. Service ticket1130indicates that “Service 2” (or service1114) was selected and that the output format is Open XPS.

Adding a Service Provider to a Service Server

FIG. 12is a diagram that depicts an example process1200for adding a service provider to a service server, according to an embodiment. In this example, process1200begins by a user (or, more specifically, an administrator) selecting an Add Service button1210, which may be the same as Add Service button750displayed in user interface700. Selection of Add Service button1210causes a window1220to be displayed that includes three text fields: a service provider URL text field, a User ID text field, and a Password text field. Window1220also includes an option for the client application that provides window1220to remember a password that a user enters in the Password text field. Upon entering of the required information, window1230is displayed.

Window1230includes service attribute information1232, feature set1234, an Add to Collection button1236, and a Discard button1238. Service attribute information1232indicates a URL address of a particular service, an IP address of the particular service, the security type of the particular service, the connection type of the particular service, and the category of the particular service. Feature set1234indicates at least four features of the particular service: an Event Service feature, an Academic feature, a Tutoring feature, and a Shopping feature. Each feature is associated with multiple options, such as Birthday Celebration, Event Party, and Graduate Celebration for the Event Service feature.

Selection of Add to Collection button1236causes the particular service to be added to a database, such as a Service GSDD or a Client GSDD. Selection of Discard button1238causes window1230to disappear and, thus, prevents the particular service from being added to the database.

In the depicted example, Add to Collection button1236is selected, which causes window1240to be displayed. Window1240indicates that the particular service, described in window1230, was added. Window1240includes two buttons: an OK button1242and a Cancel button1244. Selection of OK button1242causes a user interface (such as user interface700) to be updated immediately and, optionally, a UI GSDD to be updated immediately. Selection of Cancel button1244causes the user interface to be updated later, rather than immediately.

After window1240is displayed, window1250is displayed (e.g., in response to selection of OK button1242). Window1250displays a user interface, similar to user interface700. The user interface may include information about the particular service added during process1200.

Implementation Mechanisms

For example,FIG. 13is a block diagram that depicts a computer system1300upon which an embodiment may be implemented. Computer system1300includes a bus1302or other communication mechanism for communicating information, and a hardware processor1304coupled with bus1302for processing information. Hardware processor1304may be, for example, a general purpose microprocessor.

Computer system1300also includes a main memory1306, such as a random access memory (RAM) or other dynamic storage device, coupled to bus1302for storing information and instructions to be executed by processor1304. Main memory1306also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor1304. Such instructions, when stored in non-transitory storage media accessible to processor1304, render computer system1300into a special-purpose machine that is customized to perform the operations specified in the instructions.

Computer system1300further includes a read only memory (ROM)1308or other static storage device coupled to bus1302for storing static information and instructions for processor1304. A storage device1310, such as a magnetic disk or optical disk, is provided and coupled to bus1302for storing information and instructions.

Computer system1300may be coupled via bus1302to a display1312, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device1314, including alphanumeric and other keys, is coupled to bus1302for communicating information and command selections to processor1304. Another type of user input device is cursor control1316, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor1304and for controlling cursor movement on display1312. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.

Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor1304for execution. For example, the instructions may initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system1300can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus1302. Bus1302carries the data to main memory1306, from which processor1304retrieves and executes the instructions. The instructions received by main memory1306may optionally be stored on storage device1310either before or after execution by processor1304.

Computer system1300also includes a communication interface1318coupled to bus1302. Communication interface1318provides a two-way data communication coupling to a network link1320that is connected to a local network1322. For example, communication interface1318may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface1318may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface1318sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

Network link1320typically provides data communication through one or more networks to other data devices. For example, network link1320may provide a connection through local network1322to a host computer1324or to data equipment operated by an Internet Service Provider (ISP)1326. ISP1326in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet”1328. Local network1322and Internet1328both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link1320and through communication interface1318, which carry the digital data to and from computer system1300, are example forms of transmission media.

Computer system1300can send messages and receive data, including program code, through the network(s), network link1320and communication interface1318. In the Internet example, a server1330might transmit a requested code for an application program through Internet1328, ISP1326, local network1322and communication interface1318.

The received code may be executed by processor1304as it is received, and/or stored in storage device1310, or other non-volatile storage for later execution.

Providing Service Workflows Through Devices

In some situations, users to not have access to all services currently offered by devices. This may occur for a variety of reasons. For example, when a device is initially placed into service, service applications may not be available for all of the services supported by the device. Users often rely upon third parties to develop service applications and service applications are not always immediately available for new service and/or new devices. Some basic device services, e.g., printing, scanning, faxing, etc., are often supported by standard service applications, but non-standard services often require special service applications. As another example, new services may be added to a device currently in service and service applications may not be available for the new services.

An approach is provided for providing service workflows through devices. The approach automatically generates and provides service applications for devices. A service server determines that a service is available for a particular network device. The service may be a new service or an existing service. The service server may make this determination in a variety of ways. For example, the service server may be notified that the new service is available for the particular network device, either by the particular network device or by another source. As another example, the service server may query the particular network device to determine that the service is available for the particular network device.

In response to determining that the service is available for the particular network device, the service server obtains service information from the particular network device. The service information defines, for the service, at least one or more user interface attributes, one or more service parameters and service logic. The service server generates, based upon the service information, a service application that implements the service. The service application allows a user to use the service available for the device. The service server may receive, from a client device, a request to use the service for the particular device. In response to the request, the service server provides to the client device the service application that implements the service. This approach provides users access to services on devices that the users may not otherwise be able to access.

FIG. 14is a block diagram that depicts and arrangement1400on which the approach for providing service workflows through devices may be implemented. Starting with1402, an original equipment manufacturer (OEM) designs services that are provided to the OEM service distributor, which in turn provides the service to local devices1404, as Service1, Service2and Service3, respectively. Service information for Service1, Service2and Service3is provided to a service server1408via local connections, local network connections and other networks, such as the Internet. The service server1408generates and makes available service applications1410, which include a Remote Service Application (App)1, a local device Service App1, a local Service App2and local device Service App3. The service applications1410allow user access to the Service1, Service2and Service3on local devices1402. Service server1408may be implemented, for example, by computer hardware and computer software, or any combination of computer hardware and computer software. In addition, service server1408may be implemented on any client device, intermediary device, or even on local devices1404, depending upon a particular implementation.

FIG. 15is a diagram1500that depicts example components of a device service. In this example, the device supports two services, Service1and Service2and includes process logic to implement Service1and Service2. Service1includes two processes, Process1and Process2, implemented by process logic. Process1includes two sub-processes, Sub-Process1and Sub-Process2, implemented by process logic. Sub-Process1has a corresponding user interface (UI), from which parameters are received and provided to a function. The function outputs parameters that are provided as an input to Sub-Process2. Sub-Process2has a corresponding user interface (UI), from which parameters are received and provided to a function. The function outputs parameters that are provided as an input to Process2. Process2includes two sub-processes, Sub-Process1and Sub-Process2, implemented by process logic. Sub-Process1has a corresponding user interface (UI), from which parameters are received and provided to a function. The function outputs parameters that are provided as an input to Sub-Process2. Sub-Process2has a corresponding user interface (UI), from which parameters are received and provided to a function. Service2includes one process, Process1.

FIG. 16is a block diagram1600that depicts device service workflows. In this example, a device supports two services, Service1and Service2. Service1and Service2each include logic for three processes, namely, Process1Logic, Process2Logic and Process3Logic. The process logic implements a UI for each procedure that provides parameters to the process logic. More specifically, Procedure1UI provides parameters to Process1Logic, Procedure2UI provides parameters to Process2Logic and Procedure3UI provides parameters to Process3Logic. In addition, the process logic provides outputs that are used as inputs for a next procedure. Process1Logic provides outputs that are used as inputs to the Procedure2UI, Process2Logic provides outputs that are used as inputs to the Procedure3UI and Process3Logic provides outputs that are used as inputs to another procedure (not depicted).

FIG. 17is a block diagram1700that depicts an example service workflow for a Multi-Function Peripheral (MFP). MFPs are devices that support two or more functions, implemented by one or more services. For example, an MFP may support printing, copying, faxing, or any combination thereof. In this example, the MFP supports two services, Copy and Fax. The Copy service includes a Scan process and a Print process. The Scan process includes two sub-processes that include a Set Scan Source sub-process and a Scan Target sub process. The Set Scan Source sub-process handles parameters for scanning a document and the Scan Target sub process handles parameters for a target device to receive the scan data. The Set Scan Source sub-process implements a UI that provides parameters to a function. The function outputs parameters to the Scan Target sub-process. The Scan Target sub-process receives the parameters output by the function of the Set Scan Source sub-process and implements a UI that provides parameters to a function. The Print process includes two sub-processes that include a Document Parameters sub-process and a Target Parameters sub process. The Document Parameters sub-process implements a UI that provides parameters to a function. The function outputs parameters to the Target Parameters sub-process. The Target Parameters sub-process receives the parameters output by the function of the Document Parameters sub-process and implements a UI that provides parameters to a function. The Fax service includes a Document Parameters process and a Target Parameters process. The Document Parameters process handles parameters related to the document to be faxed and the Target Parameters process handles parameters related to the target device that is to receive the fax.

FIG. 18is a block diagram1800that depicts an example service workflow for a name card printing service. In this example, the name card printing service includes a Data Acquire process and a Print process. The Data Acquire process includes a Data Input sub-process and a Scanned Image sub-process. The Data Acquire process supports data input via a markup language, such as XML, drag & drop, or manual input to a UI that outputs parameters to a function. The Scanned Image process implements a UI that outputs parameters to a function. The Print process includes a Document Parameters Configuration sub-process that implements a UI that receives parameters from the function implemented by the Data Input sub-process and parameters from the Scanned Image function. The UI outputs parameters to a Print sub-process.

FIG. 19is a block diagram1900that depicts a process for generating for a device a service application, also referred to herein as a device virtual service. In Step0, a service is made available to a device. For example an OEM Service Distribution Center may update the firmware or install software onto a device1404to make the service available to the device1404. The example inFIG. 19is depicted and described in the context of adding a new service to a device, but the approach is not limited to this context and is applicable to upgrading existing services or to existing services that may not have been previously known to the service server1408.

In Step1, the service server1408determines that the service is available and requests service information for the service from the device1404. For example, the device1404may notify the service server1408of the existence of the service, or the service server1408may query the device1404to learn about the existence of the service. The service server1408may request the service information from the device1404using various queries, API calls, etc. In Step2, the device1404provides the service information for the service, for example in response to the queries from the service server. Thus, in the current approach, devices are configured to provide their service information to a service server. The service information is described in more detail hereinafter.

In Step3, the service server1408generates a service application for the service, based at least upon the service information obtained for the service. The service application is also referred to herein as a device virtual service. The device virtual service is implemented as a client application that includes all of the functionality necessary for a client device to use the service. In Step4, the device server1408deploys the device virtual service to a client device. This may include, for example, the device server1408supplying one or more files, including an executable program, to a client device. In Step5, the device virtual service starts on the client device and presents a UI. In Step6, a user interacts with the device virtual service UI. In Step7, the user of the device virtual service enters values, selects features or changes workflow procedures on the device virtual service UI. For example, a user may select particular functions and provide parameter values to be used by the selected functions. In Step8, the device virtual service UI provides the data to the device virtual service. In Step9, the device virtual service generates, validates and provides data to the device1404. The data includes all of the information that is necessary for the service on the device to implement the request made by the user via the device virtual service UI.

Service Information

The service information for a service may include various types of information that may vary depending upon a particular implementation and the approaches described herein are not limited to any particular service information. For example, the service information may include service UI information, service process information, service parameter information, process workflow information and process workflow logic. Service information may be implemented in various forms that may vary depending upon a particular implementation and the approaches described herein are not limited to service information in any particular form. For example, service information may be represented by data contained in one or more data files, a markup language, such as XML, or by programming language statements. The service UI information is information that defines or that can be used to create a device virtual service UI. The service process information indicates one or more processes that implement the service. The service parameter information indicates parameters used by the processes. The process workflow information indicates a starting process, a sequence of processes, if more than one process is involved, and error handling, for example how the workflow proceeds if a process encounters an error. The process workflow logic implements the processes. For example, the process workflow logic may include decision logic for the processes implement the service.

FIG. 20depicts example service UI information in the form of XML statements2000. The XML statements allow the service server1408to generate a service application that implements the UI as depicted by the GUI2010ofFIG. 20.

Table I below contains a schema description of a device service in the form of XML statements that describe a device service and its corresponding processes and workflows.

Table II below contains an example name card printing service that may be implemented on a device. The name card printing service includes two processes: name card data acquire and name card print. Table II contains example XML statements that define the name card printing service and its two constituent processes. In the XML statements, the name card data acquire process is specified as “NameCardDataAcquire” and the name card print process is specified as “NameCardPrint”.

Upon invocation of the name card printing service, the first process “NameCardDataAcquire” is started and the page “DataInputPage” of the process's UI module “ManualInputModule” is displayed to allow a user to enter name card information. During data entry, the “NameCardDataAcquire” process invokes a validation module “NameCard_Information_Valid” to validate the entered data. After the user has finished entering data, the “NameCardDataAcquire” process invokes the next process “NameCard_Print”, as specified by the <NextProcess> tag. The “NameCardDataAcquire” process invokes passes, as output, “NameCard_Information” to the “NameCard_Print” process, as indicated by the <Output> tag.

Once the second process, name card print, has started, the page “DocumentConfigUIPage” of the process's UI module “DocumentConfigUIPage” is displayed to allow a user to specify property values of the target printer, such as paper size, text fonts, etc. After the user has finished entering the property values, the process generates its final data into a service XML job ticket named “NameCard_JobTicket”, as specified by the <Output> tag. The name card print process also validates the XML job ticket by invoking a validation module named “NameCard_JobTicket_Valid”, as indicated by the <ServiceLogicRules> tag. The XML job ticket is then sent to the device for processing.

Adding Services

Services may be added at any time to the service server1408.FIG. 21is a flow diagram2100that depicts adding a service to the service server1408. In step2102, a service becomes available for a device, such as one of devices1404. Service server1408may be notified about the service from the device1404, or by querying the device1404. In step2104, the service server1408attempts to obtain service information for the service, for example, by querying a service provider or the device1404. In step2106, a determination is made whether authentication is required. If so, then in step2108, authentication information, e.g., user ID, password, etc., is obtained and verified. For example, a user may be queried to enter a user ID and password via a GUI. If, in step2108, the authentication is successful, or if in step2106, no authentication is required, then in step2110, the service server1408obtains the service information for the service. For example, the service server1408may obtain the service information from a service provider that provided the service, or from the device1404.

In step2112, a determination is made whether the service should be added to the service server1408. This determination may be made using a variety of techniques, depending upon a particular implementation. For example, a policy may for a particular business organization or domain may be used to determine whether the service should be added to the service server1408. One example policy is that only services included on a trusted service provider list are added. Another example policy is that only services where the service information can be obtained via a secure connection are added to the service server1408. As service may be filtered, for example, based upon the name of a provider, an embedded certification, a service category, a security level of a service, etc. Business organizations may establish filter policies to determine whether a service should be added to a service server. If a determination is made in step2112that the service is not to be added to the service server, then in step2114, a notification is provided that the service cannot be added to the service server. For example, a message may be displayed indicating that the service cannot be added to the service server because doing so would violate a particular policy. If a determination is made in step2112that the service is to be added to the service server, then in step2116, the service server1408generates a service application for the service based upon the service information. For example, the service server1408examines and/or parses the service information for the service to generate a service application that implements the processes that implement the service.

In step2118, a determination is made whether the service should be made available to the user. This determination may be made, for example, by applying a policy or filter for a particular user. For example, a determination may be made that the service should be made available to the particular user if the service is in a user-selected category, or is on the particular user's approved service list, or if a personnel credential is established. Thus, service applications generated by the service server1408may be made available on a per-user basis. If the service should not be made available to the particular user, then the service is not made available to the particular user and the process continues to step2102. If, in step2118, a determination is made that the service should be made available to the particular user, then in step2120, data is updated to reflect that the service is available to the particular user. This may include, for example, updating a database maintained by the service server1408. In addition, in step2122, the service server notifies the client device that the service is available and in step2124, a service client application executing on the client device is updated to make the service available to the particular user.

FIG. 22is a block diagram2200that depicts an example service information data flow. A set of devices2202each supports and provides any number of services. In the present example, for purposes of explanation only, each device2202is depicted inFIG. 22and described herein as supporting one service, identified as Service1, Service2, Service3and Service4, respectively. Each device2202provides service information2204to a service server2206for the services that they support and provide. Thus, Device1provides to service server2206Service Information1for Service1. Similarly, Device2provides to service server2206Service Information2for Service2, Device3provides to service server2206Service Information3for Service3and Device4provides to service server2206Service Information4for Service4. Service server2206is not limited to obtaining service information from devices and service server2206may obtain service information from other locations, for example, service providers. Example service information2208includes, without limitation, information that defines or specifies a service UI, one or more service processes, one or more service parameters, process workflow and workflow logic. Devices2202may provide their service information2204to service server2206via various communications links. Example communications links include, without limitation, direct communications links, wired links, such as a USB connection, wired networks, wireless networks, or any combination thereof. Devices2202may also provide their service information2204to service server2206via other methods, for example, via portable media, such as a flash drive, memory stick, etc.

The service server2206includes a service application generator2210that generates service applications based upon service information. In the present example, service server2206generates four service applications, Service Application1, Service Application2, Service Application3and Service Application4that correspond, respectively, to Service1, Service2, Service3and Service4. Filtering2212may be applied to control the service applications that are made available to one or more devices. For example, a business organization may apply filtering2210based upon a company policy to control the service applications that are made available. An example policy is that a service application must be included on a trusted service provider list or that the service application is obtained over a secure connection. Filtering2214may be applied to control the combined service applications, and therefore the services, that are made available to a particular client device. Further filtering2216may be applied to control the service applications that are made available to a particular user to provide a personalized service set for a user's client device UI. Thus, the distribution of client applications generated by service server2206may be managed at the business organization level, the client device level, or the user level.

Generating Service Applications

FIG. 23depicts and arrangement2300for providing service workflows through devices according to one embodiment. In this example, arrangement2300includes a device2302, a service server2304and a client device2306. Device2302may be any type of device. Examples of device2302include, without limitation, a printer, a copier, a facsimile machine, an MFP, etc. In the present example, device2302implements one or more services, e.g., Service1, Service2. . . . Service n. Service server2304includes a service application generator2308, a service information retriever2310and a service updater2312. Service server2304may include various other elements that may vary depending upon a particular implementation. For example, service server2304may include local storage for storing service information retrieved from devices or other sources, generated service applications, etc. This may include service information databases, as previously described herein.

The various elements of service server2304, including service application generator2308, service information retriever2310and service updater2312may be implemented by computer hardware elements, computer software, or any combination of computer hardware elements and computer software, depending upon a particular implementation. Service information retriever2310is configured to retrieve service information from devices or service providers, for example using queries. Service information retriever2310may also cause the retrieved service information to be stored on service server2304. Service application generator2308is configured to generate service applications for client devices. In the example depicted inFIG. 23, service application generator2308generates and installs on client device2306service applications that are identified as “Generated Service App1”, “Generated Service App2” and “Generated Service App3”. Service application generator2308generates service applications based upon service information for the services. Each service application may implement one or more services, depicted inFIG. 23as Service1, Service2. . . Service n. Each service application implements a UI, parameter management and logic for the corresponding services.

Service client modules2314are generated by service server2304based upon service information for the corresponding services and execute on client devices. The service client modules2314exchange service parameters, data and workflow logic with the generated service applications on client device2306. Each service client module2314includes a client UI module2316, a process data validation module2318and a target service ticket management module2320. The client UI module2316generates a UI and causes the UI to be displayed on a display of the client device upon which the service client module2314is installed. The process data validation module2318validates process data used by the service. Target service ticket management module2320generates service tickets for the client device upon which the service client module2314is installed.

Service updater2312is configured to determine that services, or updated services, are available for devices. Service updater2312may be notified by devices or service providers that services are available. Alternatively, service updater2312may query devices or service providers to determine whether services are available.

Accessing Service Applications

FIG. 24is a block diagram that depicts an environment2400for generating service tickets. An integrated service application UI2402provides access to a plurality of services2404that are supported by device service applications2406. Each of the services2404is implemented by a service client module, for example as depicted inFIG. 23. The integrated service application UI204may be generated by the service server1408that also determines a device to provide the requested services.

For example,FIG. 25is a block diagram that depicts a print server2500upon which an embodiment may be implemented. Print server2500includes a bus2502or other communication mechanism for communicating information, and a hardware CPU2504coupled with bus2502for processing information. Hardware CPU2504may be, for example, a general purpose microprocessor.

Print server2500also includes a RAM memory2506, such as a random access memory (RAM) or other dynamic storage device, coupled to bus2502for storing information and instructions to be executed by CPU2504. RAM memory2506also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by CPU2504. Such instructions, when stored in non-transitory storage media accessible to CPU2504, render print server2500into a special-purpose machine that is customized to perform the operations specified in the instructions.

Print server2500further includes a read only memory (ROM)2508or other static storage device coupled to bus2502for storing static information and instructions for CPU2504. A storage2510, such as a magnetic disk or optical disk, is provided and coupled to bus2502for storing information and instructions.

Print server2500may be coupled via bus2502to a display2512, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device2514, including alphanumeric and other keys, is coupled to bus2502for communicating information and command selections to CPU2504. Another type of user input device is cursor control2516, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to CPU2504and for controlling cursor movement on display2512. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.

Print server2500may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes or programs print server2500to be a special-purpose machine. According to one embodiment, the techniques herein are performed by print server2500in response to CPU2504executing one or more sequences of one or more instructions contained in RAM memory2506. Such instructions may be read into RAM memory2506from another storage medium, such as storage2510. Execution of the sequences of instructions contained in RAM memory2506causes CPU2504to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.

Various forms of media may be involved in carrying one or more sequences of one or more instructions to CPU2504for execution. For example, the instructions may initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to print server2500can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus2502. Bus2502carries the data to RAM memory2506, from which CPU2504retrieves and executes the instructions. The instructions received by RAM memory2506may optionally be stored on storage2510either before or after execution by CPU2504.

Print server2500also includes a communication interface2518coupled to bus2502. Communication interface2518provides a two-way data communication coupling to a network link2520that is connected to a local network or Internet2522. For example, communication interface2518may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface2518may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface2518sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

Network link2520typically provides data communication through one or more networks to other data devices. For example, network link2520may provide a connection to a service2530through a local network or Internet2522, a wired network2526and a wired network2528. Print server2500can send messages and receive data, including program code, through these networks and communication interface2518.