HK1181137B - External service application discovery method - Google Patents

Description

Discovery method of external service application

Technical Field

The invention relates to a service application, in particular to a discovery method of the service application.

Background

Businesses typically maintain various types of documents stored in different locations for different purposes. In many cases, such documents are created and stored in accordance with a variety of different software applications and storage systems. For example, a document may be generated using a word processing application, a spreadsheet application, a presentation application, an annotation application, a graphical design application, a photography application, and the like. The generated data can be stored via various storage systemsIncluding one or more content servers for storing documents of various types, servers for storing documents as attachments to electronic mail items (e-mails), storage systems for storing documents as attachments to meetings, Customer Relationship Management (CRM) systems for storing documents as attachments to primary or customer data, general document storage for storing documents for daily use, and/or special document storage (e.g., from Documentum corporation) for specialized very specified requirements)。

Accessing and working with these various types of documents typically requires that the appropriate software for each document type be available to the user. A typical enterprise scenario contemplates that everyone who needs to access documents or work with them will have the appropriate software installed locally on the computing device they use on a daily basis. This is a viable approach when everyone has access to the same set and version of applications. However, in many situations, an enterprise may not load a given software application onto a user's computing device when multiple users may only use the given software application occasionally. One way to remedy this problem is to convert the document into a "published" format that is easily viewable but not easily editable. Another way to provide access to various document types without the need to locally install the necessary software packages is to provide viewing and editing functionality inherently within the content server, or to provide direct integration between the content server and a dedicated system for viewing and editing the supported documents; however, enterprises are often reluctant to integrate such functionality with their content servers, fearing that such integration of additional functionality may reduce processing capacity and power used by similar critical tasks, increase downtime, and/or complicate management of their content servers. Furthermore, resources (e.g., time, effort, and development, procurement, and deployment associated with expenses) invested into a dedicated system are unlikely to be transferred to another platform.

It is with respect to these and other considerations that the present invention has been made.

Disclosure of Invention

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

According to embodiments, an external service application discovery process interfaces one or more hosts with one or more service applications that allow a user of a client computing device to work with files via a general-purpose client application (i.e., a web browser). The development platform interface (shared communication protocol) allows the host to communicate with external application servers regardless of the host's native communication protocol. The external application server describes the functionality provided by the service application and how to invoke the functionality through the external service application discovery process described by the provisioning of the open platform interface. The host selectively makes the functionality provided by the service application available to the user based on the implementation level of the development platform interface and the conventions of the external service application discovery process understood by the host.

Integration with an external application server is the responsibility of the host to do so through a process called discovery, during which the host learns of the functions supported by the external application server. The host is not required to have any knowledge of the availability or functionality of the external application server prior to discovery. To participate in discovery of an external application server, the host must understand the open platform interface and the discovery conventions associated with the open platform interface. The behavior of the host changes based on the availability and functionality of the external application server.

The external service application discovery process is initiated by the host by providing a location of a discovery data source containing information describing the functionality of the external application server. The discovery data is maintained by an external application server and provided to the host in response or in a discovery document. After obtaining the location of the discovery data, the host issues a discovery request to the discovery data source. The discovery data source, upon receiving the discovery request, provides a response containing discovery data describing the functions supported by the external application server (i.e., the attributes of the external application server). The discovery data is formatted according to the conventions of the open platform interface and contains information specified by the conventions. The host consumes the discovery data returned by the discovery data source. After consuming the discovery data, the host stores information about actions supported by the service application for the associated file type. After the external service application discovery process is completed, the behavior of the host becomes integrating the advertised functionality of the service applications supported by the host.

Drawings

Further features, aspects, and benefits of the present invention will become better understood with regard to the following detailed description, appended claims, and accompanying drawings where the elements are not to scale to more clearly show the details, in which like reference numerals refer to like elements in the several views, and wherein:

FIG. 1 illustrates a block diagram of an enterprise network including a host and an external application server for practicing one embodiment of an external services application discovery process;

FIG. 2 illustrates a flow diagram of an external application service discovery process between a host and an external application server;

FIG. 3 is a simplified block diagram of a computing device that may be used to implement embodiments of the present invention;

FIGS. 4A and 4B are simplified block diagrams of mobile computing devices that may be used to implement embodiments of the present invention; and

FIG. 5 is a simplified block diagram of a distributed computing system in which embodiments of the present invention may be implemented.

Detailed Description

An external service application discovery process for connecting a host with an external application server is described herein and illustrated in the accompanying drawings. The external service application discovery process connects one or more hosts with one or more service applications that allow users of client computing devices to work with files on a network via a general-purpose client application in communication with the hosts. The development platform interface, which is a shared communication protocol, allows external application servers to interact with the host regardless of the host's native communication protocol. The external application server describes the functionality provided by the service application and how to invoke the functionality through the external service application discovery process described by the provisioning of the open platform interface. The host selectively makes the functionality provided by the service application available to the user based on the implementation level of the development platform interface and the conventions of the external service application discovery process understood by the host.

Fig. 1 illustrates one embodiment of an exemplary enterprise network 100 including one or more hosts 102 and one or more external application servers 104. User 106 accesses host 102 using web browser 108 from client computing device 110. Host 102 is most generally a content server that stores documents in document storage system 126 and manages permissions for users 106. Generally, the host 102 runs a host application 112 that provides a host user interface 114 that handles the normal functions of the host 102. At least some of the general functionality of the host 102 includes providing the user 106 with access to a stored document 116, the document 116 being contained in the content store 126 and intended to be viewed and/or edited using the supported application. The host 102 also provides a common platform for making services of the external application server 104 available to the user 106. The external application server 104 provides a browser-based web application that allows the user 106 to interact with documents available through the host. The open platform interface defines and directs document operations between the host 102 and the external application server 104. Host 102 also implements endpoints 120 that receive communications from external application servers. While the host 102 initializes the scenario of the service including the external application server 104, the host 102 does not call the external application server 104. Instead, the external application server 104 exposes the supported functionality to operate with callbacks for the supported document types.

The external application servers 104 run one or more web-based service applications 118 that enable the user 106 to access, view, edit, and optionally perform other operations with respect to content (i.e., files or documents), and perform folder (i.e., directory) management from the client computing device 110 over the network, without requiring local installation of the appropriate applications needed to work with the particular document type. The operation and output of the external application server 104 is not specific to the host 102 that invokes the functionality of the external application server 104. Each service application 118 typically runs as a service on an external application server 104. The external application server 104 is integrated with the host 102 using an open platform interface and a set of conventions for open platform interfaces. The external application server 104 provides the necessary operations and functions to work with documents of the selected file type. The external application server 104 is host agnostic. In other words, the operation and/or output of the external application server 104 is not specific to the host 102 that facilitates access to the services of the external application server 104. Examples of service applications 118 that process various document types include online (i.e., web-based) partners of standard (i.e., locally installed) applications for working with word processing documents, spreadsheets, presentations, and annotations.

The operations provided by each service application 118 are typically specific to the selected file type or to folder management. The core operation provided by the external application server 104 is viewing and editing a document. In various embodiments, the service application 118 provides one or more additional operations including, but not limited to, reformatting documents for viewing on a mobile device, creating new documents, converting documents, embedding documents, and broadcasting documents from the perspective of the external application server 104, broadcast and embedding being a particular interactive user stream. In the case of a broadcast, the external application server 104 displays the document on the plurality of client computing devices 110 and, in one embodiment, tracks the current page viewed at each of the plurality of client computing devices 110. Host 102 manages document uploads, broadcast originations, and rich client entry points. In another embodiment of a broadcast operation, page tracking is handled by the host 102.

The operations supported by each service application 118 are accessed through one or more service application portal URLs. Each service application entry URL serves as an entry point to the external application server 104 for a particular operation for a particular document type. In general, each service application portal URL includes an address of an external application server and specifies a task (e.g., an embedded edit using a spreadsheet application), required data associated with the task, i.e., a metadata URL for the document and an access token authorizing access, and any optional parameters specific to the task. When the user 106 selects an operation for a document, the host 102 generates a service application portal URL for the operation for the document selected by the user. In particular, the external application home page 122 generates URL parameters for use with the service application 118. The parameters generated by the external application home page 122 include, but are not limited to, an access token and a source URL. The source URL is the URL that the service application 118 uses to access the host endpoint 120 and the document. The access token is a token that is unique to a user/object pair that is used by host endpoint 120 to authenticate user 106 and authorize access to documents and/or service applications 118. In various embodiments, an access token is calculated based on the user identifier, the timestamp, and the document identifier, and encrypted with a password known to the host 102 (e.g., stored in a host configuration database).

Service application entry points are handled by wrappers provided by the host 102. The wrapper provided by the host 102 is a framework or environment that displays the output of the external application server 104 and accepts input from the client computing device 110 that allows the user 106 to interact with the document using the functionality provided by the service application 118. In one embodiment, the wrapper includes an external application home page 122 and/or an application frame 124. As an example, one embodiment of the host 102 generated external application home page 122 is a single page that hosts all service application pages in a web page container, such as an inline frame (iFrame) that uses an edge-by-edge layout. The external application home page 122 itself has no user interface. Alternative implementations of the external application home page may include other web page containers and layouts for the user interface described above or in the alternative.

The amount of embedded information may result in a long and cumbersome service application portal URL. Additionally, including an access token that will expire makes the service application portal URL vulnerable. The wrapper compensates for the cumbersome and fragile nature of the service application portal URL by providing support for bookmark and link sharing. In other words, the URL of the external application homepage is bookmarkable and shareable. The application frame 124 points to the service application portal URL and the external application home page 122 optionally presents a host frame and navigation controls.

The background task of the external application server 104 is accomplished in a manner similar to user interaction, but utilizes hidden frames in a browser-displayed page displayed by the client computing device 110 to navigate to the service application portal URL and load a script, applet, or other set of instructions (e.g., JavaScript) that drives the task, provides retry logic, and allows the final state to be notified by navigating parent frames. In one embodiment, the background task is used for host-directed document conversion.

When a service application performs a file-level operation, it makes a request to the host endpoint 120 using an open platform interface. The host endpoint 120 is a web service that understands requests made using an open platform interface. Various embodiments of the host endpoint 120 are implemented as REST-based web services. In some embodiments, communications with host endpoint 120 are handled exclusively through a secure transport protocol (e.g., HTTPS) in order to protect the authentication token and file content. In one embodiment, the host endpoint URL is created by appending the location of the host endpoint web service to the host URL.

External application servers 104 provide the necessary functionality to access, edit, view, and otherwise manipulate or work with various document types. In the described embodiment, external application server 104 does not include the complexity and overhead associated with network access, user authentication, file storage, network and file security, and other administrative tasks that are typically handled by other servers in the network and are typically dedicated to a particular enterprise. Ignoring these features and focusing external application servers on processing document operations through an open platform interface allows the external application server 104 to be used in a wide variety of enterprise network scenarios. It should be understood that an external application server 104 performing as described herein and assuming additional roles and responsibilities typically handled by other servers on the enterprise network falls within the scope and spirit of the invention.

The host 102 is an online server application that can be accessed over a network using a general-purpose client application, such as a web browser. The services provided by the external application server 104 are consumed by the host 102 and made available to the client computing device 110. When attached to the external application server 104, the host 102 becomes aware of each service application 118 and functionality supported by the external application server 104. Examples of suitable host systems include, but are not limited to, mail systems that allow web-based access (e.g., Microsoft exchange)) Unified communications system (e.g., IBM LotusMicrosoftAnd) And content and/or document management systems (e.g., IBM LotusAnd Microsoft)。

The host 102 has a variety of responsibilities that facilitate interactions between the client computing device 110 and the external application server 104. The host 102 stores the user's data and initializes the scenario including the external application server 104. The host 102 implements a wrapper for displaying user interface pages hosted by each service application 118. In addition, the host 102 implements and exposes a host endpoint 120 for receiving communications from the external application server 104. The host endpoint 120 is a web service that understands requests made using an open platform interface. The host 102 also provides file operations for the service application 118 through requests made using the open platform interface. Other responsibilities of the host 102 include handling access control to documents at the user level and license enforcement for the external application server 104. In one embodiment, the host 102 handles access control by generating an access token (i.e., authorization element) that will expire, which is passed to the external application server 104 to authorize the requested operation.

Integration with an external application server is another responsibility of the host through a process called discovery, during which the host learns of the functions supported by the external application server. The host is not required to have any knowledge of the availability or functionality of the external application server prior to discovery. It is only necessary that the host understand the open platform interface used by the external application server. The behavior of the host changes based on the availability and functionality of the external application server.

The configuration, functionality, implementation level of the open platform interface and the adherence of the host 102 to the open platform interface's conventions determine the functionality of the external application servers available to the end user. If the host is unable to fully implement the open platform interface or does not meet the requirements of a certain function of the external application server, the function is not available to the user. In particular, if the host does not disclose support for a particular function, the service application suppresses any features that require the unsupported function. For example, when a host cannot save an updated copy of a file, the service application should not allow the user to edit the document. Furthermore, administrative control over access to the connected service application is optionally available through configuration of the host.

The host manages the permissions of the service applications provided by the external application server. The host checks the permissions while it checks the user's permissions for the file. To perform a selected operation on a document, a user must have both the appropriate permissions to perform the operation on the file and valid permissions to use the associated service application. The host reports the results of the permit and permit checks to the external application server. In addition, the host optionally checks to see if access to a particular document type supported by the service application is blocked via administrative controls configured in the host. The host cannot save or retrieve the blocked document type.

In various embodiments, the host checks for permission before invoking the default action in response to clicking on the file type associated with the service application. If the user does not have the appropriate permissions for the service application associated with the default click operation, the host will not attempt to execute the command (i.e., invoke the operation). In other embodiments, the host will not attempt to execute commands that the user lacks their appropriate permissions or commands for the document type that is blocked.

In various embodiments, the host also checks for permissions when generating dynamic user interface controls (such as a context menu) for accessing functionality provided by an external application server. Dynamic user interface controls typically provide a user with a list of operations that are available for that document type. If the user does not have the appropriate permissions for the service application associated with the operation for the document type, the host does not display the command in the dynamic user interface control. In other embodiments, the dynamic user interface control does not show commands that the user lacks their appropriate permissions or commands related to the document type that is blocked.

In various embodiments, basic functionality such as view operations are available without permission, while advanced functionality such as editing and transformation operations require permission. In one embodiment, use of the service application is permitted on a user-by-user or machine-by-machine basis. In another embodiment, the use of the service application is limited by the number of available concurrent licenses. In yet another embodiment involving multiple service applications, a single license applies to all service applications provided using a single external application server. In another embodiment, a license for each service application is required.

As previously described, the host is a content server where the host provides document storage. In an alternative embodiment, the host is configured to provide access to documents stored outside the host (e.g., stored in a network file system or on a storage device attached to a network). In an alternative embodiment, the external application server is configured to request documents stored in any accessible content server or file storage system that accepts and understands file operation requests made with the development platform interface.

The web server provides online access to the host and service applications. An external application server is most responsive when it has exclusive access to the web server. Communication delays caused by shared use of web servers are more likely to make the experience less positive for the end user. A shared web server may be acceptable in some cases where other applications sharing the web server have low bandwidth requirements, are accessed infrequently, and/or transfer small amounts of data. In one embodiment, the host and/or external application server use the services of a separate web server. In another embodiment, the external application server integrates a web server. In yet another embodiment, the host integrates a web server for use by external application servers.

An open platform interface for communication between the host and external application servers allows interaction with documents and uses the access token as an authorization/authentication mechanism.

The open platform interface is both extensible and provides support for cross-version interface communications. The basic data transfer mechanism of the open platform interface facilitates cross-platform communication. In various embodiments, the underlying data is conveyed in a JavaScript Object Notification (JSON) body, although it should be recognized that other human and/or machine readable data exchange formats fall within the scope and spirit of the present invention. The open platform interface also adheres to service oriented architecture principles used by some application boundary interfaces such as Windows Communication Foundation (WCF) "ignore you unexpected (ignore you't expect)" and "use default values for data you expect but not get (use default values for data you expect but not get" t get "used by some application boundary interfaces. The semantics of "default values used by the open platform interface necessarily lead to acceptable behavior" help maintain functionality in the world that is highly across versions. This semantics is particularly useful in maintaining functionality between SkyDrive, Hotmail, and the production and integration environments of external application servers.

The main extensibility mechanisms of open platform interfaces are declaration, implementation, and consumption through function sets (e.g., Cobalt, CoAuth, locking, updating). The core open platform interface contains only methods for obtaining metadata associated with a document, and methods for obtaining document data. All other methods supported by the host are declared within the document metadata and returned as a list of supported function sets. Each function set is declared by a string and promises to implement a set of methods supported by the open platform interface. The open interface defines the name of the function set and the associated method promised by the function set. The set of functions that a host can use to implement is limited by the conventions of the open platform interface. In other words, the open platform interface does not provide a mechanism to attempt to discover a completely generic approach similar to that provided by Simple Object Access Protocol (SOAP) metadata exchange. The open platform interface is easily extended by declaring new sets of functionality.

To provide access to the service application, the host 102 must be aware of the availability and functionality provided by the external application server 104. The external service application discovery process allows the host 102 to be aware of available external application servers without requiring an administrator to manually configure the host 102. During the external service application discovery process, the host 102 knows the file formats and open platform interface verbs supported by the external application server 104.

Fig. 2 shows a flow diagram of an external service application discovery process 200 for connecting a host 102 with an external application server 104. The external service application discovery process 200 is initiated by the host by providing a location of a discovery data source 202, the discovery data source 202 containing information describing the functionality of the external application server 104. In the illustrated embodiment, the discovery data is contained in a discovery profile maintained by the external application server 104, and the discovery data source 202 is a discovery endpoint of the external application server 104 addressed by a discovery URL (e.g., domain name). In the illustrated embodiment, the host 102 accepts an external application server location via the configuration user interface 204 of the host and generates a discovery URL 206. In one embodiment, the discovery endpoint has a fixed location relative to the location of the external application server 104, and the host 102 generates the discovery URL by appending the location (e.g., relative path) of the discovery endpoint to the location of the external application server 104. In another embodiment, the administrator must specify the complete discovery URL 206. Alternatively, the discovery data consumed by the host is not provided by the service application server. In contrast, the discovery data source 202 is a file (i.e., a discovery profile) provided by an administrator, and the location of the discovery data source 202 provided to the host 102 is the location of the file.

After obtaining the discovery URL, the host 102 issues a discovery request 208 to the discovery endpoint. In one embodiment, the discovery request 208 is an HTTP GET request for a discovery URL. The discovery endpoint provides the host 102 with the ability to connect with the discovery service 210. The discovery service 210, upon receiving the discovery request 208, responds with a discovery response message 212 containing discovery data 214, the discovery data 214 describing functionality provided by the service application running on the external application server. Discovery data 214 is formatted according to the conventions of the open platform interface and contains information specified by the conventions. In one embodiment, the discovery response message 212 does not contain any HTML in the message body. Instead, the body contains discovery data described in a host-understood XML format. In various embodiments, the discovery data contains information such as an identifier of the service application, a description of the service application, a file extension, an operation (i.e., an action) associated with the file extension, any open platform interface implementation requirements (e.g., a set of functions) of the host, a location of the service application responsible for processing the operation, and/or a mime type of the document associated with the file extension.

The host 102 consumes the discovery data 214 returned by the discovery service 210. After consuming the discovery data 214, the host 102 stores information about the actions supported by the service application (i.e., registers the service application) for the associated file type in the host configuration store 216. After the external service application discovery process 200 is completed, the behavior of the host becomes the supported functionality of the integrated service application.

Discovery data content and structure are specified by an open platform interface. The core data for discovery includes an action identifier, a file type associated with the action, and a source URL for invoking the action. Optional discovery data includes a service application identifier, a requirement for host support action, a folder/directory identifier, a network area identifier, default click behavior, a target extension identifier, and a certification identifier. The action identifier is defined by the conventions of the open platform interface and defines the operations that are allowed for a particular file type. Examples of action identifiers include view, edit new, move view, move handler, embed view, render (render broadcast), join (join broadcast), convert. The file type describes the type of file to which the action is applied. In one embodiment, the file type is specified by a file extension. The source URL specifies input data for determining an absolute URL of an external application server that performs an action for matching a file type. The service application identifier is a human and machine readable identifier (e.g., a string value) that identifies a support application (e.g., "Microsoft Excel Web App") for the service application. The network region identifier describes a particular parameter (e.g., source URL) for an action when invoked from a particular network region. The service application identifier and network area identifier are used to group file type/operation pairs and provide a meaningful way of presenting available service applications in the host configuration user interface. The folder/directory identifier is used with or in place of a file type for a particular action to identify the object of the action. The default click behavior specifies actions to be invoked by the host when the user selects a file type supported by the service application without selecting specific actions through the user interface. The target extension identifier specifies a file type of the target file for the conversion action. In one embodiment, the target extension identifier is specified by a file extension.

The registration associates the file types supported by each service application 118, the operations supported by the external application server 104 for each supported file type, and the URL of the computing device in the external application server that invoked the operation for each supported file type. In other words, when the host 102 connects to the external application server 104, the external application server 104 returns a list of pairs of file types and operations along with the URL for invoking the operation for that file type. The parameters needed in the URL are defined by the open platform interface.

During discovery, the host chooses to take advantage of or ignore the respective action based on the conventions it understands at that time. In one embodiment, host 102 verifies that it supports the requirements for the operation before registering the paired file type and operation. If the host 102 does not support the operation and/or does not meet the hosting requirements, then no pair of file types and operations are registered. In particular, in some embodiments, the host uses a "requirements" attribute that specifies open platform interface implementation requirements for filtering out actions that the host cannot support. In other words, if the host does not recognize or understand all of the fields listed in the "Requirements" attribute values, or chooses a convention that does not support an open platform interface, the host does not register (i.e., implement) the paired file types and operations, and does not provide this functionality to the user.

The source URL uses parameters that generate a valid service application entry URL associated with each action. For actions, the service application portal URL parameter is specified by a convention in the open platform interface. Some parameters are necessary while others are optional. In one exemplary embodiment, the necessary parameters are bounded by square brackets ("[" and "]"), while the optional parameters are bounded by sharp brackets ("<" and ">). If the host does not understand a necessary parameter, the host does not register the action. Conversely, if the optional parameters are not understood, the host may select a registration action. In this case, the functionality associated with the optional parameter is simply lost, but the host is still able to provide as many actions as the host understands. This behavior provides the basis for cross-version compatibility between open platform interfaces of different versions. Even though the upgrade to the service application server provides new functionality, the host can continue to work with the upgraded service application server. The host simply continues to provide support for functions it understands and ignores any functions it does not understand. Examples of optional parameters include the language of the user interface, the language of the user interface of the object, whether to embed a presentation frame, whether to allow a presentation participant to independently switch slides, and whether to show thumbnails of the slides.

The host is typically accessible from various network regions. A network region is typically described by whether it is inside or outside the network and whether transport layer security is used. To fully describe the functionality of an external application server to a host, one embodiment of discovery data describes file type/operation pairs for one or more possible zone configurations by a network zone identifier. For example, to work with hosts accessible through extranets (e.g., the internet) and intranets (e.g., corporate lans), one embodiment of the discovery data describes each file type/operation pair with a service application URL for internal use and a service application URL for external use. Similarly, one embodiment of discovery data describes file type/operation pairs using a service application URL for use with an open network protocol (e.g., HTTP) and a secure network protocol (e.g., HTTPs) that hosts that allow access using secure and unsecure network protocols. Another embodiment of discovery data uses service application URLs for each combination of internal/external and secure/insecure uses (e.g., internal-http, external-http, internal-https, external-https) to describe each file type/operation pair. In some embodiments, the discovery contract provides a fallback position to a lower security zone when the host is not configured for a secure network. In other words, if the host is not configured with a secure network protocol, the service application URL designated as using the secure network protocol is modified and registered using the corresponding open network protocol. Thus, the functionality of the service application server is made available to the user, but the benefits of secure network protocols are lacking.

For simplicity, one embodiment of the external service application discovery process associates the service application with all zones configured in the host by default and sets the host endpoint allow list to allow all zones. Management control of the integration between the service application and the various zones is available through certain hosts. In various embodiments, integration is disabled at the service application server level (i.e., enabling or disabling all service applications provided by the service application server) or at the service application level (i.e., selectively enabling or disabling service applications). When integration with the service application server/service application is disabled, the host does not list operations or attempt to execute commands in the dynamic user interface control.

Optionally, the discovery data provided to the host includes cryptographic key information specific to the service application server. The cryptographic key information provides a mechanism for the host through which authentication requests are actually made by the service application server. When the request reaches the host endpoint, the host optionally uses the cryptographic key information to validate the cryptographic signature of the request. If the cryptographic signature cannot be validated, the host ignores the request.

In various embodiments, the host implements error checking during the external service application discovery process. In one embodiment, if the URL is found to be incomplete, the host generates a notification. In another embodiment, the host generates a notification if the external application server is not responding or cannot be located. In yet another embodiment, the host generates a notification if the response is found to be incomplete. In another embodiment, in the event of a conflict (i.e., if an external application server attempts to register a file type that has already been registered), the host generates a notification and does not register the service application.

In one embodiment, discovery occurs only upon initiation by an administrator, so the host and service application server do not automatically become aware of any changes to the supported functionality of each other. In an alternative embodiment, the discovery process provides an automated mechanism for updating supported functions once the host and service application server are connected. In various embodiments of an automated discovery update process, updates are provided on a periodic basis (e.g., scheduled polling) or in real-time (e.g., push notifications). Further, various embodiments of the automated discovery update process are implemented on the host side (e.g., periodically repeating the discovery process) or on the service application server side (e.g., the discovery service notifies the host of changes).

The inclusion of an external application server provides host-independent document processing services. This eliminates the need to add new components or substantially modify the configuration of the working host supporting the external application server. By not modifying the operation or adding new components to the working host, the potential for violating the working configuration or requiring significant downtime of the host is minimized. This also allows external application servers to be upgraded, modified, added, or removed without requiring reconfiguration of the host. This is particularly beneficial because new versions and updates of document processing applications tend to occur much more frequently than updates of the core services of the imaging host. In other words, the enterprise is relieved from the downtime, risk, and burden of modifying the host solely for the purpose of utilizing improvements to existing document processing applications, for the purpose of adding newly developed or newly required document processing applications, or for the purpose of removing outdated or obsolete document processing applications.

The embodiments and functions described herein may operate via any number of computing systems, such as the host 102, and external application servers 104, and client devices 110 described above with reference to FIG. 1, including wired and wireless computing systems, mobile computing systems (e.g., mobile phones, tablet or pad type computers, laptop computers, etc.). Further, the embodiments and functions described herein may operate on a distributed system (e.g., a cloud-based computing system), where application functions, memory, data storage and retrieval, and various processing functions may operate remotely from each other over a distributed computing network such as the internet or an intranet. Various types of user interfaces and information may be displayed via an onboard computing device display or via a remote display unit associated with one or more computing devices. For example, various types of user interfaces and information may be displayed and interacted with on a wall surface on which various types of user interfaces and information are projected. Interactions with many computing systems that may be used to implement embodiments of the present invention include: keystroke input, touch screen input, voice or other audio input, gesture input (where an associated computing device is equipped with detection (e.g., camera) functionality for capturing and interpreting user gestures for controlling functions of the computing device), and the like. Figures 3 through 5 and the associated description provide a discussion of various operating environments in which embodiments of the invention may be implemented. However, the devices and systems shown and discussed with respect to fig. 3 through 5 are for purposes of example and are not limiting of the vast number of computing device configurations that may be used to implement embodiments of the invention described herein.

FIG. 3 is a block diagram illustrating example physical components of a computing device 300 that may be used to implement embodiments of the present invention. The computing device components described below may be suitable for the computing devices described above, such as host 102, external application server 104, and client computing device 110. In a basic configuration, computing device 300 may include at least one processing unit 302 and system memory 304. Depending on the configuration and type of computing device, system memory 304 may include, but is not limited to, volatile (e.g., Random Access Memory (RAM)), non-volatile (e.g., read-only memory (ROM)), flash memory, or any combination. The system memory 304 may include an operating system 305 and one or more programming modules 306, the programming modules 306 adapted to run applications 320 such as client applications (e.g., user agent/web browser 108) or server applications (e.g., host application 112 or service application 118). Operating system 305 may be suitable for controlling the operation of computing device 300, for example. Furthermore, embodiments of the invention may be practiced in conjunction with a graphics library, other operating systems, or any other application program and is not limited to any particular application or system. This basic configuration is illustrated in fig. 3 by those components within dashed line 308.

Computing device 300 may have additional features or functionality. For example, computing device 300 may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in FIG. 3 by removable storage 309 and non-removable storage 310.

As mentioned above, a number of program modules and data files may be stored in system memory 304, including operating system 305. When executed on processing unit 302, programming modules 306 may perform various processes including, for example, one or more of the steps of external service application discovery process 200. The above process is one example, and processing unit 302 may perform other processes. Other programming modules that may be used in accordance with embodiments of the present invention may include email and contacts applications, word processing applications, spreadsheet applications, database applications, slide presentation applications, drawing or computer-aided applications, and the like.

Generally, program modules may include routines, programs, components, data structures, and other types of structures that may perform particular tasks or that may implement particular abstract data types in accordance with embodiments of the invention. Moreover, embodiments of the invention may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. Embodiments of the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

Furthermore, embodiments of the invention may be practiced in a circuit comprising discrete electronic elements, packaged or integrated electronic chips containing logic gates, a circuit utilizing a microprocessor, or on a single chip containing electronic elements or microprocessors. Embodiments of the invention may be implemented, for example, by a system on a chip (SOC), in which each or many of the components shown in fig. 3 may be integrated onto a single integrated circuit. Such SOC devices may include one or more processing units, graphics units, communication units, system virtualization units, and various application functions, all integrated (or "burned") onto a chip substrate as a single integrated circuit. When operating through an SOC, the functionality of server application 320 or a client application may be implemented through application-specific logic integrated with other components of computing device 300 on a single integrated circuit (chip). Embodiments of the invention may also be practiced using other technologies capable of performing logical operations such as, for example, AND, OR, AND NOT, including but NOT limited to mechanical, optical, fluidic, AND quantum technologies. In addition, embodiments of the invention may be practiced in a general purpose computer or any other circuits or systems.

For example, embodiments of the invention may be implemented as a computer process (method), a computing system, or as an article of manufacture such as a computer program product or computer readable media. The computer program product may be a computer storage media readable by a computer system and encoding a computer program of instructions for executing a computer process.

The term computer readable media as used herein may include computer storage media. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. System memory 304, removable storage 309 and non-removable storage 310 are all examples of computer storage media (i.e., memory storage). Computer storage media may include, but is not limited to, RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store information and which can be accessed by computing device 300. Any such computer storage media may be part of device 300. Computing device 300 may also have input device(s) 312 such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) 314 such as a display, speakers, printer, etc. may also be included. The above devices are examples, and other devices may be used.

The term computer readable media as used herein may also include communication media. Communication media may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" may describe a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, Radio Frequency (RF), infrared and other wireless media. Computing device 300 may include communication connections 316 that allow communication with other computing devices 318. Examples of suitable communication connections 316 include, but are not limited to, RF transmitter, receiver, and/or transceiver circuitry; universal Serial Bus (USB), parallel or serial ports, and other connections suitable for use with the appropriate computer-readable media.

Fig. 4A and 4B illustrate a suitable mobile computing environment, such as a mobile phone 400, a smart phone, a tablet personal computer, a laptop computer, etc., that can be used to implement embodiments of the present invention. Referring to FIG. 4A, an example mobile computing device 400 for implementing embodiments is shown. In a basic configuration, the mobile computing device 400 is a handheld computer having both input elements and output elements. The input elements may include a touch screen display 405 and input buttons 410 that allow a user to input information into the mobile computing device 400. The mobile computing device 400 may also incorporate an optional side input element 415 that allows further user input. Optional side input element 415 may be a rotary switch, a button, or any other type of manual input element. In alternative embodiments, mobile computing device 400 may incorporate more or fewer input elements. For example, in some embodiments, the display 405 may not be a touch screen. In yet another alternative embodiment, the mobile computing device is a portable telephone system, such as a cellular telephone having a display 405 and input buttons 410. The mobile computing device 400 may also include an optional keypad 435. Optional keypad 435 may be a physical keypad or a "soft" keypad generated on the touch screen display.

The mobile computing device 400 incorporates an output element, such as a display 405 that may display a Graphical User Interface (GUI). Other output elements include LED light 420 and speaker 425. Additionally, the mobile computing device 400 may contain a vibration module (not shown) that causes the mobile computing device 400 to vibrate to notify the user of the event. In yet another embodiment, the mobile computing device 400 may incorporate a headphone jack (not shown) for providing another means of providing an output signal.

Although described herein in connection with a mobile computing device 400, the invention can, in alternative embodiments, be used in connection with any number of computer systems, such as in a desktop environment, laptop or notebook computer systems, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Embodiments of the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network in a distributed computing environment; programs may be located in both local and remote memory storage devices. In summary, any computer system having multiple environmental sensors, multiple output elements providing notifications to a user, and multiple notification event types may incorporate embodiments of the present invention.

FIG. 4B is a block diagram illustrating components of a mobile computing device, such as the computing device shown in FIG. 4A, used in one embodiment. That is, mobile computing device 400 may incorporate system 402 to implement certain embodiments. For example, system 402 may be used to implement a "smart phone" that may run one or more applications similar to those of a desktop or notebook computer, such as browser, email, calendaring, instant messaging, and media player applications. In certain embodiments, system 402 is integrated as a computing device, such as an integrated Personal Digital Assistant (PDA) and wireless telephone.

One or more application programs 466 may be loaded into memory 462 and executed on or in association with operating system 464. Examples of application programs include phone dialer programs, email programs, PIM (personal information management) programs, word processing programs, spreadsheet programs, internet browser programs, messaging programs, and so forth. System 402 also includes non-volatile storage 468 within memory 462. Non-volatile storage 468 may be used to store persistent information that is not lost when system 402 is powered down. Applications 466 may use and store information in non-volatile storage 468, such as e-mail or other messages used by an e-mail application. A synchronization application (not shown) also resides on system 402 and is programmed to interact with a corresponding synchronization application resident on a host computer to keep the information stored in non-volatile storage 468 synchronized with corresponding information stored on the host computer. As should be appreciated, other applications may be loaded into memory 462 and run on device 400, including the various client and server applications described herein.

The system 402 has a power supply 470 that may be implemented as one or more batteries. The power supply 470 may also include an external power source, such as an AC adapter or a powered docking cradle that supplements or recharges the batteries.

The system 402 may also include a radio 472 that performs the function of transmitting and receiving radio frequency communications. Radio 472 facilitates wireless connectivity between system 402 and the "outside world" through a communications carrier or service provider. Transmissions to and from the radio 472 are under the control of the operating system 464. In other words, communications received by the radio 472 may be disseminated to the application programs 466 by the operating system 464, and vice versa.

Radio 472 allows system 402 to communicate with other computing devices, such as over a network. Radio 472 is one example of communication media. Communication media may typically be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. The term "computer-readable media" as used herein includes both storage media and communication media.

This embodiment of system 402 is shown with two types of notification output devices: a Light Emitting Diode (LED)420 that may be used to provide visual notifications and an audio interface 474 that may be used with the speaker 425 to provide audio notifications. These devices may be directly coupled to the power supply 470 so that when activated, they remain on for a duration dictated by the notification mechanism even though the processor 460 and other components might shut down in order to conserve battery power. The LED 420 may be programmed to remain on indefinitely until the user takes action to indicate the powered-on status of the device. The audio interface 474 is used to provide audible signals to and receive audible signals from the user. For example, in addition to being coupled to the speaker 425, the audio interface 474 may also be coupled to a microphone to receive audible input, such as to facilitate a telephone conversation. According to embodiments of the invention, the microphone may also act as an audio sensor to facilitate control of notifications, as will be described below. System 402 may further include a video interface 476 that allows operation of on-board camera 430 to record still images, video streams, and the like.

The mobile computing device implementation system 402 may have additional features or functionality. For example, the device may also include additional data storage devices (removable and/or non-removable) such as, magnetic disks, optical disks, or tape. Such additional storage is illustrated in fig. 4B by storage 468. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data.

The data/information generated or captured by device 400 and stored via system 402 may be stored locally on device 400 as described above, or the data may be stored on any number of storage media accessible by the device via radio 472 or via a wired connection between device 400 and a separate computing device associated with device 400, such as a server computer in a distributed computing network, e.g., the internet. As should be appreciated, such data/information may be accessed via the device 400, via the radio 472, or via a distributed computing network. Similarly, such data/information may be readily transferred between computing devices for storage and use in accordance with known data/information transfer and storage means, including email and collaborative data/information sharing systems.

FIG. 5 illustrates a system architecture for providing a browser application 108, a host application 112, and/or a service application 118 as described above to one or more client devices. Content opened, interacted with, or edited in association with the host application 112 and/or the service application 118 may be stored in different communication channels or other storage types. For example, various documents may be stored using directory services 522, web portals 524, mailbox services 526, instant messaging stores 528, and social networking sites 530. As described above, the host application 112 and/or the service application 118 may use any of these types of systems or the like for allowing data utilization. Server 520 may provide host application 112 and/or service application 118 for clients. As one example, server 520 may be a web server that provides host application 112 and/or service application 118 over the web. Server 520 may provide host application 112 and/or service application 118 on the web to clients over network 515. Examples of clients that may access the host 102 include a computing device 300, which may include any general purpose personal computer 110a, a tablet computing device 110b, and/or a mobile computing device 110c such as a smartphone. Any of these devices may obtain content from storage 516.

Embodiments of the present invention are described above with reference to block diagrams and/or operational illustrations of methods, systems, and computer program products according to embodiments of the invention, for example. The functions/acts noted in the blocks may occur out of the order noted in any flowchart. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved.

While specific embodiments of the invention have been described, other embodiments are possible. In addition, although embodiments of the present invention have been described as being associated with data stored in memory and other storage media, data may also be stored on or read from other types of computer-readable media, such as secondary storage devices (like hard disks, floppy disks, or a CD-ROM), a carrier wave from the Internet, or other forms of RAM or ROM. In addition, steps of the disclosed methods may be modified in any manner, including by reordering steps and/or inserting or deleting steps, without departing from the invention.

In various embodiments, the types of networks used for communication between the computing devices making up the present invention include, but are not limited to, the Internet, intranets, Wide Area Networks (WANs), Local Area Networks (LANs), and Virtual Private Networks (VPNs). In the present application, a network includes an enterprise network and a network (i.e., a client network) that a client computing device uses to access the enterprise network. In one embodiment, the client network is part of an enterprise network. In another embodiment, the client network is a separate network that accesses the enterprise network through an externally available entry point (e.g., gateway, remote access protocol, or public or private internet address).

The description and illustrations of one or more embodiments provided herein are not intended to limit or restrict the scope of the invention as claimed in any way. The embodiments, examples, and details provided in this application are considered sufficient to convey ownership, and enable others to make and use the best mode of the claimed invention. The claimed invention should not be construed as limited to any embodiments, examples, or details provided in this application. Whether shown and described in combination or separately, the various features (structural and methodological) are intended to be selectively included or omitted to produce an embodiment having a particular set of features. Given the description and illustration of the present application, one skilled in the art can envision alternative embodiments that fall within the spirit of the broader aspects of the claimed invention and the general inventive concepts embodied in the present application without departing from the broader scope.

Claims (10)

1. A method of host discovery of an external application server running a service application that allows a user to interact with documents of a selected file type, the method comprising the steps of:

initiating a discovery request from the host for information about a service application server;

receiving a discovery response at the host, the discovery response comprising:

information identifying a name of the service application hosted by the service application server;

information describing actions available to be performed by the service application on the selected file type; and

information describing a requirement of the host to support the action;

parsing the discovery response at the host to learn about the action provided by the service application of the external application server; and

when it is determined that the host supports the action based on the information describing the requirements of the host to support the action, an association between the action and the selected file type is registered to integrate the action associated with the selected file type into a plurality of actions associated with the service application and made available by the host.

2. The method of claim 1, wherein the action comprises at least an action identifier associated with the action, a file type identifier associated with the action, and an address of the service application server running the service application.

3. The method of claim 2, wherein the step of parsing the discovery response further comprises the step of determining that the action is not supported by the host when the action identifier is not understood by the host.

4. The method of claim 2, wherein the action further comprises a requirement parameter associated with the action, the requirement parameter specifying a set of functions necessary for the host to support the action.

5. The method of claim 4, wherein the step of parsing the discovery response further comprises the step of determining that the host does not support the action when the host lacks at least one function specified in the set of functions.

6. The method of claim 2, wherein the information further comprises at least one of: a service application identifier associated with the action, a network area identifier associated with the action, a folder/directory identifier associated with the action, and a target file type identifier associated with the action.

7. The method of claim 1, wherein the discovery response further comprises an attestation identifier that is a public key known to the service application server and associated with a private key known to the service application server.

8. The method of claim 1, wherein the step of initiating a discovery request further comprises the step of specifying a discovery source for the discovery request, the discovery source selected from the group consisting of a discovery service and a file identified by a file location, the discovery service having an endpoint specified by a uniform resource locator.

9. A method for allowing a host computer to become aware of a server running a software program that allows a user to work with a document through a web browser, the method comprising the steps of:

at the host computer, information is queried about a server running a software program that allows a user to work with the document,

at a host computer, receiving information comprising:

information identifying a name of the software program hosted by the server;

information describing a plurality of actions associated with the software program, the actions defining a manner in which the software program allows the user to work with the document;

information specifying a name of a manner of working with the document, a file type supported by the manner of working with the document, and an address that, when selected by a user, makes the software program aware of using the manner of working with the document; and

information describing requirements of the host computer to support the manner of working with the document;

at the host computer, completing reading the information to understand the manner in which the software program allows the user to work with the document;

at the host computer, determining whether the host computer identifies a name of a manner of working with the document and satisfies the requirements for supporting the manner of working with the document; and

at the host computer, configuring the host computer to associate the file type and the address with a manner of working with the document when the name is recognized by the host computer, to integrate the manner of working with the document of the file type into a plurality of manners allowed by the software program and made available by the host to work with the document.

10. A method for host discovery of an external application server running a service application that allows a user to interact with documents of a selected file type, the method comprising the steps of:

defining a set of known action identifiers understood and supported by an open platform interface implemented by the host;

initiating a discovery request from the host for information about a service application server;

receiving, at the host, a discovery response comprising:

information identifying a name of the service application hosted by the service application server;

information describing an action performable by the service application for the selected file type and a credential identifier associated with the service application server, the action including an action identifier associated with the action, a file type identifier associated with the action, and an address of the service application server running the service application; and

a requirement parameter associated with the action, the requirement parameter specifying a set of functions necessary for the host to support the action;

parsing the response at the host to learn the action provided by the service application of the external application server;

ignoring the action when the host does not support the action because the host lacks at least one function specified in the set of functions or the action identifier does not match any of the known action identifiers from the set of known action identifiers; and

when the host supports the action, an association between the action and the file type is registered to integrate the action associated with the selected file type into a plurality of actions associated with the service application and made available by the host.