Methods and apparatus for enabling context sharing

FIELD OF THE INVENTION

0001The present invention relates to techniques for managing context among software applications in a networked environment.

BACKGROUND OF THE INVENTION

0002There exist commercial endeavors in which a plurality of computer application programs share a set of entities or subjects which are common to the application programs. For example, in the field of medicine, multiple different application programs may be used to store and manage different types of a data about the same patient. One application program may be used to store and manage clinical information about the patient, such as the patient's medical history, another application program may store and manage financial information about the patient, such as billing and insurance coverage information, while another application program may be used to store scheduling information, such as the date and time of the patient's scheduled future visits.

0003As another example, in the field of law, multiple different application programs may be used to store and manage information about the same client or case. A docketing application program may be used to store and manage information about upcoming deadlines and tasks to be performed with respect to the client or case, a billing application program may be used to store and manage information regarding the amount of attorney time spent on that client or case and the amounts charged to a particular client or for a particular case, and a document management application program may be used to store and manage documents created for a particular client or case.

0004Although a medical patient or a legal client or case are illustrative examples of entities or subjects that may be common to multiple different application programs, there are many other entities or subjects about which multiple different application programs may store different information. For example, the identity of a user of multiple different application programs is an example of a subject that is common to multiple application programs.

0005Data which describes a given entity or subject, and which is used commonly by a plurality of applications, is referred to herein as a “context” defined by that subject, and may be shared by two or more applications.

0006To access information about a particular entity or subject (e.g., a particular patient or legal case) from multiple different application programs, a user typically must individually sign in to each application program, and enter information into each application program that identifies the particular entity in which the user is interested. The desirability of managing context so that a user need not individually sign in to multiple different application programs and repeatedly enter the data describing the subject of interest into each of these application programs has been recognized. Examples of these techniques include single sign on (SSO) systems (i.e., wherein a user logs in to a single network-based resource and is automatically given access to other authorized network-based resources). As another example, a standard for context management, known as the Health Level 7 (HL7) context management specification, was published in 1999 by the Clinical Context Object Workgroup (CCOW). The CCOW standard defines a context management architecture (CMA) and processes for managing information describing a subject across a range of clinical and other healthcare-related applications. Examples of subjects that may define contexts shared by multiple different applications include a patient, a patient encounter, clinical provider, observation, insurer, and other subjects or entities.

0007Some of the application programs that may share context may be programs that are installed on the user's computer, some of the application programs may be web-based application programs that are hosted on a web server (which may be either inside or outside of the user's corporate network) and are accessed via web browser on the user's computer, and some of the application programs may be application programs hosted on a remote application server (e.g., a Citrix MetaFrame server, a Windows Terminal Server, or the like) that are emulated on the user's computer using an emulation client.

0008As mentioned above, a number of different techniques have been developed to enable two or more application programs to share context, such that a user need not individually sign in to each application program and/or need not separately enter information into each application program identifying a subject or entity of interest. For example, some of these techniques are designed to enable a user to enter sign on information only one time and, as a result, automatically be signed into multiple different application programs. Other of these techniques are designed to enable a user to enter or change context information in one of multiple different application programs and have each of the other application programs automatically change their context in the same way, without the user having to enter the context in each of those application programs. As an example in the medical field, upon detecting a user bringing up information about a patient in a clinical records application program (e.g., by entering information identifying the patient of interest into the application program), context sharing techniques may automatically change the context of the billing application program and the appointment scheduling application to the context defined by that particular patient.

0009One of these prior art techniques for context management is referred to herein as the “context-conforming application” technique. As this name implies, each application program is built or modified to conform to a context sharing technique that enables it to communicate with a central context manager, provide its context changes to the central manager, and receive context change updates in other application programs from the context manager.

0010As mentioned above, the CCOW standard is a known standard for context management. Among other features, the CCOW standard defines interfaces for inter-process communication, including communication between applications and a software-based module which coordinates the modification of data across applications (the “context manager”). One embodiment of a context manager is described in commonly-assigned U.S. patent application Ser. No. 09/545,396, which is incorporated herein by reference in its entirety.

0011The interfaces (“technology mappings”) defined by CCOW provide for communication between the context manager and various “styles” of applications, including those which follow the Microsoft Common Object Model (COM) and Hypertext Transport Protocol (HTTP) conventions, among others. For example, for a COM-based application, the CCOW standard specifies COM interfaces which allow the COM-based application to exchange data and parameters with the context manager when using a CCOW compliant context management system. The interfaces may be programmed to process COM-based data and parameters provided by the context manager and context participant applications to support the context management functions.

0012<figref idrefs="DRAWINGS">FIG. 1</figref> depicts an exemplary context management system, in which a context manager <b>230</b> manages context for two context participant applications <b>210</b> and <b>220</b>. Applications <b>210</b> and <b>220</b> may execute on the same or separate computers, and the computer(s) may be the same or separate from a computer on which context manager <b>230</b> executes. Communication between the processes may be enabled via any of numerous combinations of protocols and physical communications devices or components. For example, when the applications <b>210</b>, <b>220</b> and/or the context manager <b>230</b> execute on the different computers interconnected by a network (e.g., a local area network), the TCP/IP protocol may be employed.

0013According to the CCOW standard, communication between the applications in a context and the context manager is facilitated through the use of context participant (CP) interfaces for the applications and a set of context manager (CM) interfaces for the context manager. Each of the CP and CM interfaces may comprise any of numerous suitable components for enabling inter-process communication. For example, each of the CP and CM interfaces is integrated in an associated application and provides a “plug” which enables communication with the application (e.g., CP interfaces <b>217</b>, <b>227</b> may be implemented within applications <b>210</b>, <b>220</b> respectively, and CM interface <b>235</b> may be implemented in an application program executing on the computer on which the context manager <b>230</b> executes). In the illustrative system of <figref idrefs="DRAWINGS">FIG. 1</figref>, the applications <b>210</b>, <b>220</b> have CP interfaces <b>217</b>, <b>227</b>, respectively, associated with them.

0014Context participant (CP) interfaces <b>217</b> and <b>227</b>, respectively, receive communications from context manager <b>230</b> on behalf of applications <b>210</b>, <b>220</b>. Applications <b>210</b>, <b>220</b> may receive communications from the context manager <b>230</b> in a format and style commensurate with the CCOW standard (e.g., as COM messages or HTTP encoded messages over TCP/IP). In the embodiment shown, the communications pass through code portions <b>214</b> and <b>224</b> associated with the applications. CP interfaces <b>217</b>, <b>227</b> may alternatively be incorporated directly into applications <b>210</b>, <b>220</b> as described above, and directly pass communications thereto.

0015Context manager (CM) interface <b>235</b> receives communications from applications <b>210</b> and <b>220</b> and forwards those communications to the context manager <b>230</b>.

0016As mentioned above, each of applications <b>210</b> and <b>220</b> includes a series of programmed routines integrated with the respective application code to perform context management support functions as defined by the CCOW standard. For example, applications <b>210</b> and <b>220</b> include code portions enabling communication with the context manager. Specifically, within application <b>210</b>, code portion <b>212</b> defines messages sent to the CM interface <b>235</b>, and code portion <b>214</b> implements the CP interface <b>217</b>. Similarly, application <b>220</b> includes code portions <b>222</b> and <b>224</b> that, respectively, perform the same functions as code portions <b>212</b> and <b>214</b>.

0017When a user of one of the applications (e.g., application <b>210</b>) desires to switch the context by changing the data for a subject (e.g., switching from one patient to another), the application sends a request to the context manager <b>230</b> (via CM interface <b>235</b>). The requesting application is referred to as an “instigator” of the requested change in the context.

0018When the context manager receives a request to change a subject of the context, context manager <b>230</b> surveys the other applications in the context (e.g., application <b>220</b>), to determine whether the switch is acceptable to them. The context manager <b>230</b> performs the survey by sending a request to the other applications (e.g., application <b>220</b>) via their associated CP interfaces. The other applications in the context may determine whether the subject change is acceptable or conditionally acceptable. While rules defining the acceptability of a subject change may be customized for specific applications and contexts, an example of a situation where a requested change may be conditionally acceptable is if data relating to the existing subject has not yet been written to permanent memory on the computer on which the application executes. In this example, the other application may respond to the survey by alerting the instigator that the data could be lost if a change proceeded. The surveyed applications respond to the survey by transmitting messages back to the context manager <b>230</b> describing their reactions to the requested change.

0019According to the CCOW standard, the context manager <b>230</b> communicates the results of the survey to the instigator application, and a user thereof examines the results and determines how to proceed. There are a range of options that the user can select, including canceling the requested change, executing the requested change, or removing the instigator application from the shared context. Any of these options can be selected by the user irrespective of the results of the survey. For example, if one or more of the surveyed applications indicates that the requested change is unacceptable to it, the instigator application may nevertheless force the context change, or alternatively, may simply remove itself from the shared context so that the instigator application can implement whatever changes it desires without impacting the other applications in the context. After the user decides how to proceed with the requested change, a call is made by the instigator application to the context manager <b>230</b> informing the context manager of the change decision. The context manager then makes one or more calls to publish the change decision by notifying the other applications in the context of the decision.

0020The above-discussed techniques rely upon context-conforming (also referred to as context-enabled) applications that have the capability to perform the above-described operations to enable their participation in sharing context. A technique referred to as “bridging” has been used for applications that do not conform to the CCOW standard. In this technique, the CM and CP interfaces are custom coded to be able to send data to and receive data from an application that is not context-enabled. Thus, these CM and CP interfaces may serve as a “bridge” that manipulates the application (e.g., by simulating mouse clicks and other user input). The bridging technique relies on software installed on the client machine to manipulate the application to change context or to notify the context manager when a change in an application's context is detected. In many cases, the software that is installed on the client is an interpreter that interprets executes a bridge script. Thus, the bridge may be thought of as a script that is executed by an engine or interpreter that is installed on the client. In some cases, rather than being implemented as a script, a bridge is implemented as hard-coded software that executes on the client. As used herein, “installed software” refers to non-transient executable software code that is stored in non-volatile memory within the client computer. One example of the above-discussed bridging technique is described in detail in pending U.S. patent application Ser. No. 10/632,673, which is hereby incorporated by reference in its entirety.

0021<figref idrefs="DRAWINGS">FIG. 2</figref> is a diagram of an illustrative system in that provides context-sharing among a plurality of different application programs. In the illustrative system of <figref idrefs="DRAWINGS">FIG. 2</figref>, a desktop <b>300</b> (which may be executed on a single computer) executes three basic types of applications i.e., a locally installed and executing application (e.g., a COM-based application) <b>310</b>, a browser <b>330</b> for a web-based application executing on a web server <b>500</b>, and an emulation client <b>340</b> (e.g., a Citrix Independent Computing Architecture (ICA) client) emulating an application executing on a remote application server (i.e., a Citrix MetaFrame server) <b>600</b>. Desktop <b>300</b> also includes a COM adapter <b>320</b> to facilitate communication between applications that employ different communication protocols (e.g., application <b>310</b> which uses COM-based standards for communication and application <b>530</b> on web server <b>500</b> that uses web-based protocols). In the embodiment shown, COM adapter <b>320</b> translates COM-based communication from application <b>310</b> to HTTP-based communication, and translates HTTP-based communication to COM-based communication for receipt by application <b>310</b>.

0022Browser <b>330</b> communicates with a web server <b>500</b> via a network <b>700</b>. Web server <b>500</b> executes a web-based context participant application <b>530</b>. The illustrated desktop <b>300</b> also executes a emulation client <b>340</b>, which is in communication with a remote application server <b>600</b> to initiate a session <b>610</b> within which one or more context participant applications may execute.

0023Context server <b>400</b> executes multiple context manager sessions <b>410</b>A-C. In the example depicted in <figref idrefs="DRAWINGS">FIG. 2</figref>, context manager session <b>410</b>A manages context for all the applications represented, including COM-based application <b>310</b>, web-based application <b>530</b>, and the remote application <b>615</b>. To communicate with COM-based application <b>310</b>, context manager session <b>410</b>A transmits messages to COM adapter <b>320</b> via CP interface <b>375</b>, and receives messages from COM adapter <b>320</b> via CM interface <b>420</b>. To communicate with web application <b>530</b>, context manager session <b>410</b>A transmits messages to web server <b>500</b> via CP interface <b>510</b> and receives messages from web server <b>500</b> via CM interface <b>420</b>. Finally, to communicate with the remote application <b>615</b>, context manager session <b>410</b>A transmits messages to COM adapter <b>617</b> executing on remote application server <b>600</b> via CP interface <b>640</b>, and receives messages from COM adapter <b>617</b> via CM interface <b>420</b>.

0024When a web application participates in a context, it is the application (e.g., application <b>530</b> in <figref idrefs="DRAWINGS">FIG. 2</figref>) executing on the web server that is the context participant, rather than the browser. Typically, when a change to the context is executed, the context manager publishes the change decision to the applications in the context. However, in the case of a web application, when the change in context occurs, the change takes place in the application <b>530</b> on the web server <b>500</b>. However, because the web server does not initiate communication with the browser, the browser <b>330</b> may not be automatically made aware of the change, such that the representation of the state of the application <b>530</b> on the desktop <b>300</b> may be inaccurate. Thus, in the example of <figref idrefs="DRAWINGS">FIG. 2</figref>, a listener <b>335</b> is employed to assist in instructing the browser <b>330</b> to request updated information from its corresponding web server <b>500</b> when a change has been made to the web application <b>530</b> executing thereon. Listener <b>335</b> provides an interface (e.g., a CCOW interface) that the instigator application (i.e. the application that initiated the change in context) can contact to inform it that a change in the context has been made, so that the listener <b>335</b> can instruct the browser <b>330</b> to go back to the web server <b>500</b> for an update. When the context manager (e.g., session <b>410</b>A) returns the survey information to the instigator application relating to a requested change, the context manager also provides a list of URLs (corresponding to the listeners for any web-based applications in the context) to the instigator application, instructing the instigator application to contact (or “touch”) those URLs to inform them that the context has been updated. When the instigator application is another application executing on the same desktop <b>300</b> as the browser <b>330</b> (e.g., the COM-based application <b>310</b>), the instigator application can directly (e.g., through the COM adapter <b>320</b>) contact the listener <b>335</b>, as the URL for the listener <b>335</b> will be accessible from within the desktop.

0025In addition, the desktop <b>300</b> also includes a Context Management Registry (CMR) interface that the desktop can query to determine the identity (e.g., find the URL for) of a context manager to manage a context. In the embodiment of the invention illustrated in <figref idrefs="DRAWINGS">FIG. 2</figref>, the CMR interface <b>352</b> is implemented by a locator <b>350</b> provided on the desktop <b>300</b>, with the CMR interface <b>352</b> being a plug into the locator <b>350</b>. The CMR interface <b>352</b> can be queried by the COM-based application <b>310</b> (via the COM adapter <b>320</b>) or the browser <b>330</b> to request the identity of the appropriate context manager (e.g., one of the context manager sessions <b>410</b>A-C). When a context is initially being established (such that no context manager has been assigned to it), the locator <b>350</b> uses a URL provided in the CMR interface <b>352</b> to contact the context management server (e.g., context server <b>400</b>) to initiate a context session. The communication from the locator <b>350</b> to the context server is directed to a location service (LS)(having a plug <b>421</b>) that forms part of a context system <b>423</b> that manages the multiple context manager sessions <b>410</b>A-C. Thus, this communication goes through a private interface, rather than through the CM interface <b>420</b> for any context manager session. When the locator <b>350</b> contacts the location service of the context system <b>423</b> to request a new context manager session, the context system <b>423</b> initiates a new context manager session <b>410</b>A-C and returns to the locator <b>350</b> a URL that uniquely identifies the CM interface <b>420</b> for the new context manager session.

0026In the system of <figref idrefs="DRAWINGS">FIG. 2</figref>, a number of different software components are installed on the desktop <b>300</b>. For example, a listener <b>375</b> for browser <b>330</b> is installed to notify the browser of changes in context, a COM adapter <b>330</b> is installed to notify listener <b>375</b> of changes in context, and a locator <b>350</b> is installed to enable the desktop to locate the context server <b>400</b>. In addition, a context manager (CM) interface <b>420</b> is used to receive notifications of change in context from the web server and a context participant (CP) interface <b>510</b> is used to notify the context manager of changes. CM <b>420</b> and CP <b>510</b>, or portions thereof that perform bridging, may also be installed on desktop <b>300</b>. In addition, the application executing on the web server must be modified to conform to the CCOW standard.

0027As an alternative, rather than using a web-based application program that conforms to the CCOW standard, a bridging can be used. For example, a bridge may execute on desktop <b>300</b> to interact with the browser and communicate with the context manager.

0028Another known technique for providing single sign-on functionality for web-based application programs is referred to herein as “browser redirection.” While this technique provides SSO functionality, it does not enable ongoing context management/sharing, once a user is logged in. In this technique, when a web browser requests a sign on page from a web server to access a web-based application, the web server determines if the user is logged in. If the user is not logged in, the browser is redirected to a login server. The user provides his or her sign on information to the login server and, upon verifying that the sign on information is correct, provides a token (e.g., in the form of a unique identifier or encrypted data) on a redirect URL that is passed to the user's browser. The user's browser is then redirected to the web server hosting the web-based application that the user is attempting to access and the web server retrieves the token from the URL. The web server then uses the token to verify the user's identity (e.g., by communicating with the login server or a separate policy server), determine if the user is permitted to access the application hosted on the web server, and automatically sign the user into the application. Thus, once the token has been established, the user may access the web-based application or other web-based applications that accept the token without having to enter sign on information. This technique requires that the web-based application program be modified and additional software be installed on the web server to be able to recognize the token, verify the user's identity, and determine whether the user is permitted to access the application program.

0029Another known technique for providing single sign-on functionality for web-based application programs, without otherwise enabling the sharing of context between these application programs is referred to herein as “proxy sign on.” In this technique, an organization's domain name service (DNS) server is configured to map the domain names of web-based applications to a proxy server. The proxy server forwards requests from the user's browser to the web server hosting the application, receives the requested web page, and determines whether any of the requested web pages are login pages. If a login page is recognized, the proxy server, in a manner that is transparent to the user and the user's browser, determines if the user is already authenticated. If the user has not been authenticated then a separate login page is returned to the user's browser. The user enters his or her credentials in the login page and the proxy server validates the user's identity. Once the user has been authenticated, the proxy server retrieves the user's sign-in information for the original web page from a database or single sign-on server, and submits the sign-in information to the web server. Once the user is logged in, the proxy server simply passes requests from the browser to the web server and returns the responses from the web server to the browser and does not interact with the application.

0030This technique works with web-based application programs that allow login by simple submission of sign on information, but may be difficult to use with other application programs. That is, for example, some web-based application programs include code (e.g., JavaScript code) in a login page that must be run in the user's browser in order for the user to successfully sign in. Such code may, for example, apply a cryptographic hashing function to the user's password before it is returned to the web server. The proxy server would not be able to successfully sign in to such an application program because it merely provides the user's sign on information to the web server without executing the code that hashes the sign in information before it is submitted. Moreover, this technique presents additional challenges when the session between the web browser and the web server is encrypted (e.g., using transport layer security (TLS), secure sockets layer (SSL), or another encryption protocol). That is, when the web pages sent from the web server to the browser are encrypted, the proxy server may be unable to determine whether a web page is a login page and may be unable to submit the user's login information in encrypted form.

SUMMARY OF THE INVENTION

0031One embodiment is directed to a method of processing at least one web page of a web-based application program hosted by at least one web server. The method comprises acts of: receiving a request for the at least one web page from a web browser executing on a client computer; obtaining the at least one web page of the web-based application program in response to the request; transforming the at least one web page by inserting, in the at least one web page, software code that is not a part of the web-based application program, to generate a modified web page, wherein the software code, when executed by the web browser on the client, augments the functionality of the at least one web page; and forwarding the modified web page to the web browser. Another embodiment is directed to at least one computer readable medium encoded with computer instructions that, when executed by a computer having a processor for executing computer instructions, perform the above-described method,

0032A further embodiment is directed to a computer comprising: at least one I/O port for receiving incoming communications and sending outgoing communications; and at least one controller that: receives, from a web browser executing on a client computer separate from the computer, a request for at least one web page of a web-based application program hosted by at least one web server; obtains the at least one web page of the web-based application program in response to the request; transforms the at least one web page by inserting, in the at least one web page, software code that is not a part of the web-based application program, to generate a modified web page, wherein the software code, when executed by the web browser on the client computer, augments the functionality of the at least one web page; and forwarding the modified web page to the web browser.

BRIEF DESCRIPTION OF THE DRAWINGS

0033<figref idrefs="DRAWINGS">FIG. 1</figref> is a block diagram of a known implementation of a context manager and a plurality of context participant application;

0034<figref idrefs="DRAWINGS">FIG. 2</figref> is a block diagram of a prior art system that provides context sharing among different types of applications accessed via desktop;

0035<figref idrefs="DRAWINGS">FIG. 3</figref> is a block diagram of an illustrative computer system in which some embodiments may be implemented;

0036<figref idrefs="DRAWINGS">FIGS. 4A-4D</figref> show a flow chart of an illustrative process for enabling single sign on functionality among web-based application programs, in accordance with some embodiments; and

0037<figref idrefs="DRAWINGS">FIG. 5</figref> is a flow chart of an illustrative process for enabling context sharing between web-based application programs, in accordance with some embodiments.

DETAILED DESCRIPTION

0038The inventors have appreciated that, while the above-discussed techniques provide single sign-on functionality and/or other forms of context sharing between application programs, each of these techniques either requires software be installed on the client machine to operate, requires that the application programs that participate in sharing context be programmed to be context-enabled applications, or only works with certain types of application programs.

0039For example, some of these techniques, such as the “context-conforming application” technique and the “browser redirection” technique work only with application programs that are programmed to be context-enabled. The inventors have appreciated that these techniques are disadvantageous because there may be application programs that users desire to use, but that are unable to support SSO functionality or other context sharing functionality because they were not programmed to do so.

0040In addition, some of these techniques, such as the “browser redirection” technique, and the “proxy sign on” technique provide some single sign on functionality, but do not otherwise enable application programs to share context. Further, the “proxy sign on” technique works only with web-based applications in which login is accomplished via simple submission of login information (e.g., via a blind post), and does not work with applications in which the sign on page must be rendered in a user's browser in order successfully log in.

0041Some of the above-discussed techniques, such as the “bridging” technique and the “standard-conforming application” technique, require that software be installed on the user's computer to enable single sign-on and/or other types of context sharing functionality. The inventors have appreciated that it may be desirable in some circumstances to allow one or more application programs to participate in sharing context without having any software installed on the computer to enable or facilitate true context sharing. For example, the inventors have appreciated that software installed a user's machine consumes storage space on the user's machine and consumes processing resources when this software is executing. In addition, the inventors have appreciated that requiring that this software be installed on the user's computer limits the ability of the user to access web-based application programs from other computers and still enjoy the context sharing functionality.

0042That is, one of the benefits of using web-based applications instead of traditional client-server applications is that the web based applications typically may be accessed from any suitable computer that has Internet access and a web browser, without the user having to install an application on his or her computer. Thus, the inventors have appreciated that because some of the existing context-sharing techniques described above (e.g., the “bridging” and “context-conforming application” techniques) require that software be installed and configured on each computer on which the user wishes to use the context sharing functionality, the computers from which a user can access these web-based applications and enjoy context-sharing functionality are limited to those on which the required software is installed and configured.

0043Thus, the inventors have appreciated that it would be desirable to provide context sharing functionality for a web-based application program without requiring that this application program be programmed to be context-enabled and without requiring that software that enables or otherwise supports context sharing be installed on the user's computer.

0044To this end, the inventors have developed a technique involving inserting software code into a web page that enables and/or facilitates SSO and/or other types of context sharing for a web-based application. The inventors have appreciated that this technique for inserting software code into web page has broader applicability than facilitating context-sharing, and thus the invention is not limited to use of this technique for enabling and/or facilitating SSO or other types of context sharing for a web-based application.

0045Thus, some of the embodiments are directed to augmenting the functionality of a web page by inserting software code into the web page. In some embodiments, the software code that is inserted into the web page may enable SSO functionality for web-based application programs. In other embodiments, the software code that is inserted into the web page may provide other types of context sharing for a web-based application program. In other embodiments, the software code that is inserted into the web page may provide enable both SSO functionality and other types of context sharing for web-based applications.

0046In some embodiments, a technique for providing SSO functionality and/or other context-sharing functionality for a web-based application program may be provided that does not require that the application program be programmed to be a context-enabled application program. In some embodiments, a technique for providing SSO functionality and/or other context-sharing functionality for a web-based application program may be provided that does not require that software facilitating the context-sharing functionality be installed and/or configured on the user's computer.

0047In some embodiments, when a web browser requests a web page that forms part of a web-based application program, code is inserted into the web page, prior to the web page being received by the browser, that augments the functionality of the web page. The inserted code may provide any functionality, as the invention is not limited in this respect.

0048In some embodiments, the inserted code may enable and/or facilitate context sharing. This may be accomplished in any of a number of ways, as embodiments of the invention are not limited to any particular implementation technique.

0049<figref idrefs="DRAWINGS">FIG. 3</figref> shows an illustrative context management system <b>700</b> in which aspects of some embodiments of the invention may be implemented. <figref idrefs="DRAWINGS">FIG. 3</figref> shows a user's computer <b>701</b> which executes a web browser application <b>703</b>. The user may wish to access a first web-based application program <b>717</b> hosted on a web server <b>705</b> and a second web based application program <b>719</b> hosted on the same or a different web server (e.g., web server <b>707</b>). Context management system <b>700</b> comprises a domain name service (DNS) proxy <b>709</b>, a web proxy <b>711</b>, a context-sharing server <b>713</b>, and a user repository <b>715</b>.

0050DNS proxy <b>709</b> enables redirection to web proxy <b>711</b> of requests from browser <b>703</b> that are intended for a web server hosting an application for which context-sharing functionality is being provided. DNS is a known type of service that maps human-readable names to IP addresses of web servers. For example, DNS may map the name “sentillion.com” to the IP address of a server. Thus, when a user inputs a name (e.g., sentillion.com) into a web browser, the browser determines the IP address of the server that the user is attempting to access by sending a request to the known address of a DNS server that indicates the name and receiving a response from the DNS server that indicates the corresponding IP address.

0051DNS proxy <b>709</b> intercepts DNS requests from browser <b>703</b> to a DNS server. When it identifies a request for a domain that matches a URL pattern of an application for which context-sharing functionality is being provided by the context management system <b>700</b>, the DNS proxy responds with the IP address of web proxy <b>711</b>. If there is no match, the DNS proxy forwards the request to a true DNS server. Thus, for DNS requests for application programs for which context-sharing functionality is being provided by the context management system <b>700</b>, the response from DNS proxy <b>709</b> causes the browser to send requests to web proxy <b>711</b>, rather than the web server that actually hosts the application.

0052It should be appreciated that using a DNS proxy, such as DNS proxy <b>709</b>, to intercept DNS request from the browser is one example of a technique by which requests from browser <b>703</b> that are intended for a web-based application may be redirected to web proxy <b>711</b>. The invention is not limited to this particular technique, as any other suitable technique may be used. For example, in some embodiments, rather than using a DNS proxy, a true DNS server may simply be reconfigured to map names of application programs for which context-sharing functionality is being provided to the IP address of the web proxy, rather than the IP address of the web server hosting the application. In other embodiments, the web browser may simply be configured to use a proxy, such that the browser sends requests to the IP address of the web proxy, rather than the IP address of the server hosting the requested pages.

0053Web proxy <b>711</b> receives redirected requests from browser <b>703</b> and forwards these requests to the web server hosting the web-based application that the browser is attempting to access. As such, the web server returns the requested web pages to web proxy <b>711</b>, rather than to workstation <b>701</b> on which browser <b>703</b> executes. When web proxy <b>711</b> receives a requested web page from the web server, it may transform the web page by inserting code into the web page that alters and/or augments the functionality of the web page. The web proxy may then forward the transformed web page to the browser on workstation <b>701</b>. This causes the web browser to, in addition to rendering the web page and executing any code included by the web application program, also execute any code inserted by web proxy <b>711</b>.

0054Web proxy <b>711</b> may insert software code into a web page in any suitable way. For example, in other embodiments, the software code may be directly inserted into the text of the web page. In some embodiments, a URL at which the software code is located may be inserted into the text of the web page, causing the browser to retrieve the software code from the location specified by the URL (e.g., context-sharing server <b>713</b> or any other suitable location). In some embodiments, some of the software code may be directly inserted into the text of the web page and some may be inserted by specifying the URL at which the software code is inserted. In the examples described herein, the software code is inserted by web proxy <b>711</b>. However, the invention is not limited in this respect, as any suitable entity may insert desired code into the web page.

0055Any type of software code that the browser is capable of executing may be inserted, as the invention is not limited in this respect. For example, in some embodiments, the software code may be a client side script, which may be written in the JavaScript language or another client-side scripting language, but any other suitable technique may be used.

0056The software code that is inserted into a web page may add any suitable functionality to the web page or may alter the functionality of the web page in any suitable way, as the invention is not limited in this respect. In some embodiments, the functionality that the added software code provides may enable the web based application to share context (e.g., by enabling SSO, by sharing context in any of the ways discussed above, or in any other way). This may be accomplished by facilitating communication between the browser and the server <b>713</b> or in any other suitable way, as the invention is not limited in this respect.

0057DNS proxy server <b>709</b>, web proxy <b>711</b>, and context sharing server <b>713</b> may be implemented in any suitable way, as the invention is not limited in this respect. In some embodiments, each may be implemented as a software component that executes on one or more general purpose computers, each having one or more hardware processors that execute the software components stored thereon and at least one hardware storage device (e.g., one or more volatile memory devices and/or one or more non-volatile memory devices) that stores the software component. In some embodiments, DNS proxy server <b>709</b>, web proxy <b>711</b>, and context sharing server <b>713</b> may each operate on a separate general purpose computer(s) or processor(s), while in other embodiments all of these components may operate on the same general purpose computer(s) or processor(s). In still other embodiments, some of these components may operate on the same computer, while another operates on a separate computer. Similarly, user repository <b>715</b> may be stored in physical memory on the same computer on which context sharing server <b>713</b> operates or on a different computer. Likewise, computer <b>701</b> may be a general purpose computer having one or more hardware processors that execute browser <b>703</b> and one or more hardware memory devices that store the browser code. For example, computer <b>701</b> may be a workstation or any other type of computer capable of executing a browser, including, for example, a handheld computer (e.g., a personal data assistant) or mobile phone.

0058<figref idrefs="DRAWINGS">FIGS. 4A-4D</figref> show a flow chart of an illustrative process <b>800</b> by which context management system <b>700</b> may transform a web page by inserting code into the web page to enable the web based application to share context when the web based application may have no native ability to do so, and without requiring that context-sharing software be installed on the user's computer. In process <b>800</b>, the nature of the context sharing relates to SSO, but it should be appreciated that this just an example of one type of context that may be shared, and the invention is not limited to sharing this or any other particular type of context.

0059In the example of <figref idrefs="DRAWINGS">FIGS. 4A-4D</figref>, the single sign on functionality facilitated by process <b>800</b> enables a user to provide a single set of authentication credentials (e.g., username and password) and then be automatically signed in to any password protected application program for which single sign on functionality is provided, even if the user has a separate set of authentication credentials for each application and even if the credentials for each or some particular application programs differ from the user's single sign on credentials.

0060Process <b>800</b> begins at act <b>801</b>, where the system receives the URL of a web page as a result of computer <b>701</b> using browser <b>703</b> to navigate to the web page by entering the URL for the web page. The process then continues to act <b>803</b>, where browser <b>703</b> sends a DNS request for the domain name specified in the URL. The process next continues to act <b>805</b>, where DNS proxy <b>709</b> intercepts this DNS request, and then to act <b>807</b>, where DNS proxy <b>709</b> determines whether the domain name in the request corresponds to a web-based application program for which context sharing (e.g., single-sign on) functionality is being provided. If it is determined that the request does not correspond to such a web-based application program, the process continues to act <b>809</b>, where DNS proxy <b>709</b> forwards the request to a true DNS server and the process ends.

0061In some embodiments, in which the only context sharing functionality that is being provided is single sign on functionality, only browser requests for the log-in pages of web-based applications need be redirected to the web proxy, and the context-sharing engine may only be inserted into these log-in web pages. In such situations, at act <b>807</b>, if the requested web page is not the log-in page for an application, the process continues to act <b>809</b>.

0062If it is determined, at act <b>807</b>, that the request does correspond to such a web-based application program, the process continues to act <b>811</b>, where DNS proxy <b>709</b> returns the IP address of web proxy <b>711</b> to browser <b>703</b> in response to the DNS request.

0063The process next continues to act <b>813</b>, where the browser sends a request for the URL to the IP address specified by the DNS proxy (i.e., the IP address of web proxy <b>711</b>), and then act <b>815</b> where the web proxy forwards the request for the URL to the true web server. The process next continues to act <b>817</b>, where the web proxy receives the requested web page from the true web server, transforms the web page by inserting code into the web page that enables the context sharing functionality not natively present (e.g., single sign on functionality), and forwards the transformed web page to the web browser. This inserted code can be thought of as a context-sharing engine that serves as an interface between the browser and context-sharing server <b>713</b> to enable single sign on functionality. The nature of the code that provides the context sharing capability (e.g., SSO functionality) can take any form, as the aspects of the invention described herein are not limited in this respect. For example, the inserted code can enable performance of any of the functions of context sharing software conventionally installed on a client machine and and/or natively programmed into a web-based application or remotely executing application.

0064The process next continues to act <b>819</b>, where the web browser renders the transformed web page by sending requests for the content of the web page (e.g., images) and executing the code in the web page (e.g., JavaScript). Among the code executed by the browser is the code that was inserted into the web page by the web proxy (i.e., the context-sharing engine code). The browser's execution of the context-sharing engine causes the process to continue to act <b>821</b>, where the context-sharing engine determines whether the web page is a login web page for the application (e.g., if the web page has a username and password field), and, if it is, sends a communication to context sharing server <b>713</b> to determine if the user of workstation <b>701</b> has authenticated for single sign on purposes (i.e., has provided his or her single sign on credentials to the context-sharing server). The process then continues to act <b>823</b>, where context sharing server <b>713</b> determines if the user has authenticated. This may be done in any suitable way, as the invention is not limited in this respect. For example, in some embodiments, context sharing server <b>713</b> may track whether someone from workstation <b>701</b> has previously authenticated and is logged in for single sign on purposes. This may be done in any suitable way, as the invention is not limited in this respect.

0065For example, in some embodiments, when a user logs in for single sign on purposes, the context sharing server may internally create a session for that user and associate that session with a cookie that is sent to the user's web browser. The context sharing server, at act <b>823</b>, may determine that the user has an open single sign on session (and has therefore already authenticated and logged in) by determining whether the user's browser has stored the cookie.

0066Once a session is established, the context sharing server may manage the session to control when sessions are maintained, when sessions are terminated, and when sessions are locked.

0067For instance, if a user is logged into two different web-based application programs (e.g., application program A and application program B) that are sharing context and is using two different browser windows to access these application programs, the user may spend some time accessing application program A, without accessing application program B. The inventors have appreciated that, because application program B does not receive any access requests from the user's browser during the time that the user is accessing application program A, application program B may automatically log the user out.

0068Thus, in some embodiments, the context sharing server employs a keep-alive technique by which keeps a user from automatically being logged out of application programs that are not being accessed by the user while the user is accessing a different application program. This may be accomplished in any suitable way, as the invention is not limited in this respect.

0069In some embodiments, the context-sharing engine in a browser window may have a timer that causes the context-sharing engine to periodically (e.g., every two minutes) send a request to the application program. Thus, even if a user does not access a web page for a period of time (e.g., two minutes), then the context-sharing engine executing in that web page sends an access request to the application program to simulate user activity so that, from the point of view of the application program, the user is still accessing the application program. Thus, because the application program believes the user is still accessing the application program, the application program does not automatically log out the user.

0070In some embodiments, the context sharing server may provide a locking technique, whereby when a user has not accessed any of the web-based application programs that are participating in a context sharing session and to which the user is logged in for a period of time, each of the browser windows may be locked. User interactions with each web-based application program may be monitored, and if there have been no user interactions with any of the web-based application programs for some period of time (e.g., fifteen minutes), the context sharing server may send a communication to the context-sharing engine in each of the user's browser windows being used to access the application programs to lock the browser windows. The context-sharing engine may “gray out” or otherwise disable the browser window, but may keep the user logged into each of the application programs using the keep-alive technique discussed above. The context-sharing engine executing in each browser window may prompt the user for his or her SSO sign on credentials before unlocking the application.

0071The context sharing server may determine that the user has not accessed any of the web-based application programs for the period of time in any suitable way, as the invention is not limited in this respect. For example, in some embodiments, the proxy server (or a filter executing on the web server of the application program) can identify access requests sent from the user's browser(s) to the application program and differentiate these requests from the access requests automatically generated by the context-sharing engine for keep-alive purposes. The proxy server (or filter executing on the web server) may notify the context-sharing server whether the user is active and/or has not accessed the application program for a given period of time. If none of the application programs participating in the context sharing session have been accessed for the period of time, then the context-sharing server may notify each context-sharing engine to lock its browser window.

0072In some embodiments, the context-sharing engine in each browser, rather than the proxy server or filter executing on the web server, may determine whether the user is actively accessing the corresponding application program and may notify the context-sharing server of the user's activity or inactivity. This may be done in any suitable way. For example, the context-sharing engine may monitor the user's mouse and/or keyboard activity, and may periodically notify the context-sharing engine of user activity or lack thereof.

0073In some embodiments, in addition to or instead of providing locking based on inactivity, the context-sharing engine in each browser window may include code that causes a locking button to be displayed on the web page that, when selected by the user, causes the browser windows for all application programs participating in the context session to be locked, or provide for a hotkey combination (e.g., CTRL+L), that when input by the user via a keyboard causes each browser window to be locked.

0074Context sharing server <b>713</b> may log a user out of single sign on in any suitable way. In some embodiments, when a user closes all browser windows referencing the cookie received from the context sharing server, the cookie may be deleted and the user's session on the context sharing server may eventually time out from inactivity. Alternatively, in some embodiments, the user may explicitly request a log out via his or her web browser and, in response, context sharing server <b>713</b> may end the user's session.

0075Ending the user's session on context sharing server <b>713</b> may communicate to the context-sharing engine in the user's browser that the user has been logged out of single sign on. This may be done in any suitable way. For example, when the code is inserted at act <b>817</b>, one of the items that is inserted may be an instruction to send a request to context sharing server <b>713</b> for an indication that the session associated with the cookie in the browser is still valid. If the context sharing server <b>713</b> has ended the session, then it would respond to this request by indicating that the session is no longer valid and that the user is logged out of single sign on. The code inserted into the browser (i.e., the context-sharing engine) may respond to this indication in any suitable way. For example, the context engine may log the user out of all application to which the user is logged in, or may only prevent the user from logging into to new applications without re-authenticating.

0076In some embodiments, a user may be automatically logged out of single sign on if the user has been inactive for a threshold period of time. For example, the context-sharing engine may detect that the user has been inactive for a period of time exceeding a threshold, and may, in response, send a communication to context sharing server <b>713</b> to end the user's single sign on session.

0077If the context sharing server determines that the user has not yet authenticated, the process continues to act <b>825</b>, where the context sharing server sends a communication to the context-sharing engine indicating that the user has not authenticated. The process then continues to act <b>827</b>, where the context-sharing engine displays a window asking the user if he or she wants to authenticate for single sign on purposes. If the user selects no, the process ends. If the user selects yes, the process continues to act <b>829</b>, where the context-sharing engine redirects the browser to an SSO login page. The SSO login page may be hosted on any suitable server, as the invention is not limited in this respect. In some embodiments, the SSO login page may be hosted on context sharing server <b>713</b>.

0078The process then continues to act <b>831</b>, where the user enters his or her SSO authentication information in the SSO login page, submits this information to context-sharing server <b>713</b>, and context sharing server <b>713</b> verifies that this information is correct. Context-sharing server <b>713</b> may verify the user's authentication information in any suitable way, as the invention is not limited in this respect. For example, in some embodiments, the context sharing server may determine whether the user-supplied authentication information matches authentication information for the user stored in user repository <b>715</b> or in an external LDAP server. If context sharing server <b>713</b> determines that the SSO credentials provided by the user are not valid (e.g., the user has supplied an incorrect password and/or username), then the user may be prompted to re-enter his or her SSO authentication information or the user's browser may be redirected to the web page that was initially being accessed without SSO functionality being enabled.

0079Once the user-supplied authentication information has been verified, the process continues to <b>833</b>, where the context sharing server sets a cookie in the browser and directs the browser to re-request the web page (i.e., the page that the browser was initially attempting to access) from the web server hosting the web application via the web proxy. This causes the process to return to act <b>813</b>, and proceed, as before, through acts <b>813</b>, <b>815</b>, <b>817</b>, <b>819</b>, and <b>821</b>, to act <b>823</b>.

0080At act <b>823</b>, the context sharing server determines if the user has authenticated. Because the cookie that was set in act <b>833</b> is now present, context sharing server <b>713</b> access the cookie, determines that there is an open context session for that user, and may conclude from this that the user has already authenticated for SSO purposes. The process continues to act <b>835</b>. If, prior to the expiration of the cookie set in act <b>833</b>, the user subsequently attempts to access another web-based application program for which single sign on functionality is provided, steps <b>825</b>-<b>833</b> of process <b>800</b> need not be repeated because, at act <b>823</b>, the context sharing server will recognize the cookie and determine that the user has already authenticated for single sign in purposes, and the process will continue to act <b>835</b>, bypassing acts <b>825</b>-<b>833</b>.

0081At act <b>835</b>, the context-sharing engine executing in the browser sends a request to the context sharing server for the user's credentials (e.g., username and password) for the web-based application that the user is attempting to access from the context sharing server. The process then continues to act <b>837</b>, where the context sharing server determines if there are credentials for that particular user stored in user repository <b>715</b>.

0082If it is determined that there are user credentials stored in the repository, the process continues to act <b>839</b>, where the context sharing server returns these credentials to the context-sharing engine, and the context-sharing engine automatically enters them into the web page and submits the web page to the web server hosting the application, via web proxy <b>711</b>.

0083The process then continues to act <b>840</b>, where it is determined in the log-in was successful (i.e., if the supplied credentials were valid). If the log-in was successful, the process continues to act <b>841</b>, where the web-based application program attempts to log the user in and returns a response to the web proxy server.

0084Some application programs may include in the response a session cookie that may be used by the application program in future requests from the browser to track state. The process then continues to act <b>843</b>, where the web proxy returns the web server's response to the browser, including any session cookie that was provided by the web server, and the process ends.

0085If, at act <b>837</b>, the context sharing server determines that it does not have the user's credentials for the application program that the user is attempting to access, the process continues to act <b>845</b>, where the context sharing server notifies the context-sharing engine in the browser that no credentials were found. The process then continues to act <b>847</b>, where the user may enter his or her credentials for that particular application into the web page and submit the form to the web server. In some embodiments, the context-sharing engine may optionally modify the web page to notify the user that the credentials that the user is entering, in addition to being sent to the web server, will be sent to the context sharing server for storage and future use. This may be done in any suitable way, as the invention is not limited in this respect. For example, in some embodiments, the context-sharing engine may cause a watermark (e.g., a watermark that reads “single sign on” or any other suitable watermark) to be displayed in the input fields in which the user inputs his or her credentials.

0086The process then continues to act <b>849</b>, where the context-sharing engine detects submission of the user's credentials, and sends the credentials to the context-sharing server which may store them in the user repository for future user. The process next continues to act <b>851</b>, where the browser submits the page with user's credentials to the web server, via the web proxy. The process then continues to acts <b>840</b>, <b>841</b>, and <b>843</b>, as discussed above, and then ends.

0087If, at act <b>840</b>, it is determined that the log-in was not successful, the process continues to act <b>847</b>, where the user can re-enter his or her credentials. In some embodiments, if the number of times that the user supplies incorrect credentials exceeds some threshold (e.g., five times), the process may end, and the user may not be permitted to log in to the application.

0088In the example of <figref idrefs="DRAWINGS">FIGS. 4A-4D</figref>, a proxy agent is used to intercept DNS requests from a user's browser and redirect the browser to the web proxy, which inserts the context-sharing engine code into the requested web page. However, the invention is not limited in this respect, as in some embodiments a DNS proxy and web proxy need not be used. For example, in some embodiments, the web server hosting the web-based application program may include an agent (referred to as a filter or ISAPI filter) that is configured to intercept web pages of the web-based application program, insert context-sharing engine code into these web pages, and forward the web pages to the browser.

0089As discussed above, in some embodiments, the code inserted into a web page by web proxy <b>711</b> (or by an agent executing on the web server) may, instead of or in addition to enabling single sign on functionality, enable the sharing of other types of context between a web based application and one or more other application programs of any type. This may be done in any suitable way, as the invention is not limited in this respect.

0090For example, in some embodiments, a user may desire to access two separate web-based application programs using two separate instances (e.g., windows) of web browsers running on the same computer. As used herein, each browser window in which a web page may be displayed may be considered a separate web browser. Thus, separate instances of the same web browser or separate tabs within a single instance of a web browser may be considered separate web browsers.

0091In the example of <figref idrefs="DRAWINGS">FIG. 3</figref>, a user may wish to access web-based application program <b>717</b> via a first browser <b>703</b> on workstation <b>701</b> and simultaneously access web-based application program <b>719</b> via a second browser (not depicted) on workstation <b>701</b>. If the user decides to change some aspect of a context of application program <b>717</b> shared with application <b>719</b>, it may be desirable to have web-based application program <b>719</b> change to the same context, and have that change reflected in the second web browser.

0092For example, if application program <b>717</b> is an application program for storing and managing clinical medical records of patients and application program <b>719</b> is medical billing program, a user may sign in to each application program using two separate browsers on workstation <b>701</b>. If the user brings up the record of a particular patient in application program <b>717</b> via a first web browser, it may be desired to cause application program <b>719</b> to display the billing records for that same patient in the second browser.

0093As another example, if application program <b>717</b> is a first search engine (e.g., Google) and application program <b>719</b> is a second search engine (e.g., Live Search), an a user provides a particular search query (e.g., “dog grooming,” “LCD televisions,” a stock ticker symbol, or any other suitable search query) to application program <b>717</b> and receives search results from that application via the first browser, it may be desirable to cause application program <b>719</b> to also change context to that search query and display the results of that search query in the second browser. Numerous other types of context sharing also can be performed, as the invention is not limited in this respect.

0094Context sharing between web-based application programs may be accomplished in any suitable way, as the invention is not limited in this respect. <figref idrefs="DRAWINGS">FIG. 5</figref> shows an illustrative process <b>900</b> for enabling context sharing between web-based application programs for use in some embodiments.

0095In the example of <figref idrefs="DRAWINGS">FIG. 5</figref>, requests from a browser to a web-based application for which context-sharing functionality is being provided are redirected to a web proxy using any of the techniques described above (including, for example, DNS proxying) or any other suitable technique.

0096The process begins at act <b>901</b>, where web proxy <b>711</b> receives a web page that forms a part of a web-based application (e.g., application program <b>717</b>) and that was requested by browser <b>701</b>, transforms the web page by inserting code into it, and forwards the transformed web page to browser <b>701</b>. Web proxy <b>711</b> may insert code into the web page in any suitable way, including any of the ways discussed above or other suitable ways. The code that is inserted in the web page by web proxy <b>711</b> may be thought of as a context-sharing engine that enables context sharing functionality by sending updates in the change of context of the web-based application being accessed by the browser in which the engine is running to the context-sharing server and/or receiving updates in changes of context in other web-based applications from the context sharing server. Thus, in some embodiments, the code that is inserted into the web page may enable performance of any of the functionality of context sharing software conventionally installed on a client computer and/or natively programmed into a remotely executing application program.

0097The process continues to act <b>903</b>, where the context-sharing engine determines if there has been a change in context in the web-based application being accessed by the browser in which it is running The context-sharing engine may determine if there has been a change in context in the web-based application program in any suitable way, as the invention is not limited in this respect. For example, in some embodiments, the context-sharing engine may determine that a change in context has occurred when the user, via his or her web browser, submits to the web server (e.g., via the web proxy) a request that would change the context of the application. For example, if a user decides to change the context of application program <b>717</b> to a new patient and sends a request to application program <b>717</b> to change context to that patient, the context-sharing engine may detect submission of this request and determine that a change in context has occurred. As another example, the context-sharing engine may detect a change in context is the user changes information on a web page. For example, when the user using a search engine, the context sharing engine may detect a change in context if the user performs a new search.

0098In some embodiments, when the context-sharing engine detects a change that may be considered a change in context, it may prompt the user as to whether the user wishes to initiate a change in context before initiating the change in context.

0099If the context-sharing engine determines that a change in context has occurred, the process continues to act <b>905</b>, where context sharing engine sends a communication to context-sharing server <b>713</b>, notifying the context-sharing server of the change in context and informing it of the new context.

0100When the context-sharing server is apprised of the new change in context, it may notify the context-sharing engines associated with other application programs that share context with application program <b>717</b> (which may be, for example, executing in other browsers on workstation <b>701</b>) of the change in context. The context sharing server may notify the context-sharing engines of the change in context in any suitable way. For example, each context-sharing engine may periodically poll the context-sharing server to determine whether there is a change in context, and request the appropriate web page or take any other suitable action in response to any such change.

0101The process then returns to act <b>901</b>, where the proxy server receives the web page from the web server that is provided in response to the user's request to change context, inserts code into this web page, and forwards the transformed web page to the browser.

0102If, at act <b>903</b>, the context sharing engine does not detect any change in context in the web-based application program, the process continues to act <b>904</b>, where the context-sharing engine waits for a change in context, and then to act <b>907</b>, where the engine determines if any notifications have been received from context-sharing server <b>713</b> relating to changes in context in other web-based application programs with which context is being shared. If no such notifications have been received, the process returns to act <b>903</b>. If a notification has been received, the process continues to act <b>909</b>, where the context sharing engine causes the web browser to send, via the web proxy, a request to the web server on which its associated web-based application program is being hosted to change context to the new context. The process then returns to act <b>901</b>, where the web page provided by the web server in response to the change in context is received.

0103The embodiments discussed above describe context sharing among a plurality of web-based applications. However, the invention is not limited to sharing context among web-based applications as, in some embodiments, context may be shared between web-based application programs and non-web-based application programs that are executing on a remote computer but are being displayed on the end user's computer, such as application programs executed on remote application server (e.g., a Citrix server) that are emulated on the user's computer using an emulation client and/or locally installed applications executing on the user's computer.

0104A remote application executing on a remote application server that is emulated on the user's computer using an emulation client may participate in a context-sharing session with web-based applications in any suitable way, as the invention is not limited in this respect. U.S. patent application Ser. No. 10/632,690, which is hereby incorporated by reference in its entirety, describes a technique by which a remote application that is emulated on a user's desktop may communicate, via one or more context-sharing software components installed on the remote application server, with a context sharing server and may participate in a context sharing session with other applications.

0105In some embodiments, such a remote application may join an existing context session in which a web-based application program participates. For example, a user may access remote application that is emulated on the user's desktop via a web portal that is hosted on a web server. The web portal may include a web page with hyperlinks (e.g., URLs) that a user may select to access remote applications that can be emulated on the user's desktop. Selecting one of the hyperlinks causes the emulation client for the remote application to be launched on the user's desktop and causes the web server to create connection information that the emulation client may use to connect to the remote application server. In order for the emulated application to participate in the context session managed by the context-sharing engine, the proxy server, web server agent, and/or context sharing engine may inject a token into the connection information that is used to connect to the remote application server.

0106The emulation client uses this connection information to connect to the remote application server, and the one or more context-sharing software components installed on the remote application server intercepts the connection request from the emulation client, extracts the token information identifying the context session from the request, and uses this information in one or more communications with the context server to participate in the existing context session.

0107The examples above describe injecting code into a web page to augment the functionality of the web page to coordinate sharing of context and session management across multiple different web-based application programs. However, the invention is not limited in this respect, as the code injected into a web page may add any suitable functionality. For example, a first medical application that provides information about lab results for a patient may not provide a function to allow a user to navigate to a second medical application that provides medical prescription order and processing functionality. Thus, in some embodiments, the code injected into a web page can augment an application by providing a button, web link, or some other interface that allows a user to navigate to a different application program. In the example above, code may be injected into the web page of the first application program that inserts a button that enables a user to navigate to the second web application. When the button is selected, the second application may be launched in a separate browser window and the user may be automatically logged in using the single sign on techniques discussed above. In addition, the second application may be automatically tuned to the patient context of the first application using the context sharing techniques discussed above. This simplifies the user interaction because the user does not have to open a separate browser window for the second application, navigate to the second application, authenticate and log in to the second application, and then change the second application to the desired patient context.

0108In the examples above, code is injected into a web page of a web-based application program by a web proxy server that “intercepts” requests from a web browser to the server on which the web-based application program executes. However, the invention is not limited in this respect, as code (e.g., the context-sharing engine discussed above) may be inserted into a web page in any suitable way, as the invention is not limited in this respect.

0109For example, in some embodiments, the code that is inserted into a web page may be inserted by the web server that hosts the web-based application. For example, some web servers allow a filter or other plug-in to identify and modify requests and/or responses to requests passing through the web server. Such a filter or plug-in may be used to insert the code into the web pages of application programs for which context sharing functionality is being provided.

0110In some embodiments, the web-based application program itself may be modified to include the code (e.g., context-sharing engine discussed above) that provides context-sharing functionality. In such embodiments, the web pages generated by the application program would include the context-sharing code and additional code would not need to be inserted by a proxy server or web server.

0111The above-described embodiments of the present invention can be implemented in any of numerous ways. For example, the embodiments may be implemented using hardware, software or a combination thereof. When implemented in software, the software code can be executed on any suitable processor or collection of processors, whether provided in a single computer or distributed among multiple computers. It should be appreciated that any component or collection of components that perform the functions described above can be generically considered as one or more controllers that control the above-discussed functions. The one or more controllers can be implemented in numerous ways, such as with dedicated hardware, or with general purpose hardware (e.g., one or more processors) that is programmed using microcode or software to perform the functions recited above.

0112In this respect, it should be appreciated that one implementation of the embodiments of the present invention comprises at least one computer-readable storage medium (e.g., a computer memory, a floppy disk, a compact disk, a tape, and/or other tangible storage media.) encoded with a computer program (i.e., a plurality of instructions), which, when executed on a processor, performs the above-discussed functions of the embodiments of the present invention. The computer-readable medium can be transportable such that the program stored thereon can be loaded onto any computer system resource to implement the aspects of the present invention discussed herein. In addition, it should be appreciated that the reference to a computer program which, when executed, performs the above-discussed functions, is not limited to an application program running on a host computer. Rather, the term computer program is used herein in a generic sense to reference any type of computer code (e.g., software or microcode) that can be employed to program a processor to implement the above-discussed aspects of the present invention.

0113It should be appreciated that in accordance with several embodiments of the present invention wherein processes are implemented in a computer readable medium, the computer implemented processes may, during the course of their execution, receive input manually (e.g., from a user), in the manners described above.

0114Having described several embodiments of the invention in detail, various modifications and improvements will readily occur to those skilled in the art. Such modifications and improvements are intended to be within the spirit and scope of the invention. Accordingly, the foregoing description is by way of example only, and is not intended as limiting. The invention is limited only as defined by the following claims and the equivalents thereto.