Context service system

The present system aggregates information from a plurality of different context sources. The present system also makes that aggregated information available to requesting components by abstracting it into a generalized form. Thus, the developer of a context-aware application need only know how to interact with the context service of the present invention, rather than knowing how to interact with each and every one of the context sources.

BACKGROUND OF THE INVENTION

The present invention relates to context information. More specifically, the present invention relates to a system which aggregates and abstracts context information from a plurality of different sources and makes it available to requesting applications.

The mobile business space is a business environment in which employees, contractors or other users communicate with one another using mobile devices, such as cellular telephones, palmtop computers, laptop computers, personal digital assistances (PDAs) etc. In such a business environment, contextual information can be critically important in running a business in an efficient manner, and in a manner which is satisfactory to the customers of the business.

However, building business software and computing solutions to satisfy the needs of this business environment is challenging, expensive, and time consuming. The following scenario illustrates some of the challenges associated with this business environment. Assume that a television repair company conducts business by sending technicians to customer sites to fix problems with the customers' televisions. All customer calls are directed through a central call center. A dispatcher receives a call at the call center from a customer whose television has suddenly stopped displaying color. The customer insists that a technician make a call the same day in order to address the problem. In order to assign an appropriate technician to service the customer's call, the dispatcher would desirably know which technician is most qualified, which one has time in his or her schedule to service the customer's call today, which technician is the most affordable, given the previous constraints, and which technician is the closest to the customer. In other words, the dispatcher would desirably know the context associated with the technicians prior to assigning a technician to the customer's call.

However, all of this information currently comes from a wide variety of different sources, which are not easily accessed and obtained. In order to access this wide variety of different sources, a developer must have knowledge of each of the systems which provide different portions of the desired information, know how to interact with those systems, and know how to obtain the relevant information from those systems. This can be quite difficult since the context data sources can vary widely including, by way of example, user personnel files, calendaring or scheduling programs, geographic location devices, cellular networks, mobile devices, etc.

SUMMARY OF THE INVENTION

The present system aggregates information from a plurality of different context sources. The present system also makes that aggregated information available to requesting components by abstracting it into a generalized form. Thus, the developer of a context-aware application need only know how to interact with the context service of the present invention, rather than knowing how to interact with each and every one of the context sources.

In one embodiment, the present invention includes a context data store that stores context data aggregated from the plurality of sources. A context service interface is provided which exposes methods that can be called to add context data to the data store and retrieve context data from the data store.

In one embodiment, a find service is provided which receives a request to retrieve context data and invokes the methods on the context service interface to retrieve the desired data. A data provider service can also be provided to receive context data from the plurality of sources and invoke methods on the context service interface to add or update the context data in the data store based on the context data received.

Appendix A illustrates a number of classes in an exemplary class library.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The present invention deals with context information. More specifically, the present invention deals with a system for abstracting and aggregating context information from a variety of sources and making it available to requesting components. However, prior to discussing the present invention in greater deal, one embodiment of an illustrative computing environment for the present invention will be discussed.

It should be noted that the present invention can be carried out on a computer system such as that described with respect toFIG. 1. However, the present invention can be carried out on a server, a computer devoted to message handling, or on a distributed system in which different portions of the present invention are carried out on different parts of the distributed computing system.

The discussion of the present invention refers to “context data” or “context information”. For purposes of the present discussion, these terms mean any or all of the following information or similar information:

information that identifies a person (such as user name, user id, address, company, etc. . . . ), business attributes of the person (such as title, billing rate, level of training, expertise, teams the person belongs to, identifying information for those teams, etc. . . . ), the ways to contact the person (such as cellular telephone number#, e-mail address, telephone number, pager number, etc. . . . ), the person's preferences (such as desired hours of availability, preferred devices to use during various hours of the day, etc. . . . ), the devices used by the person and how those devices are set up (such as device id, device description, applications installed on the device, operating system on the device, memory available, etc. . . . ), the person's schedule and contact list, etc. . . . .

FIG. 2illustrates a block diagram of one embodiment of a context system200. In the embodiment illustrated inFIG. 2, system200includes context data store202, context service interface204, data provider service206and find service208.

FIG. 2illustrates that interface204and services206and208are connected through a network210, such as a local or wide area network.FIG. 2also shows that context service interface204includes a security layer212(discussed in greater detail below) and that context service interface204(which can be implemented as objects in one or more class libraries) exposes a plurality of interfaces214that have methods which can be invoked by data provider service206and find service208through network210.

In addition,FIG. 2shows that context service system200is connected to a requesting application220which, in the embodiment illustrated, requests context information from data store202.FIG. 2also shows system200connected to a plurality of different data sources222and224. The two data sources222and224which are illustrated are a calendar or scheduling application and a cellular network. Of course, it will be appreciated that a wide variety of other data sources can be connected to system200as well, such as a global positioning system (GPS) location system, application metadata system, a provisioning system, etc.FIG. 2also illustrates that system200is configured to receive device registration information226, user registration information228, schedule information230, and location information232. Further,FIG. 2illustrates optional class libraries234and236which can be instantiated, as described below.

System200aggregates context information from sources222-224, as well as from devices and users and abstracts that information into a generalized form which is stored in context data store202. In one embodiment interface204aggregates the information through data provider service206. A requesting application220, which will illustratively be a context-aware application that makes use of such context information, can request the aggregated and abstracted context information. In one embodiment, requesting application220requests the context information in context data store through find service208.

FIG. 3is a flow diagram which illustrates one embodiment for adding context data to data store202. In the embodiment illustrated byFIG. 3, context data store202is illustratively a database that stores information represented by objects. The objects are accessed through context service interface204. Thus, data store202can be a data store which stores information in terms of objects, or a relational database in which queries to the database are converted from an object referenced query to a relational database query by interface204. In any case, interface204is configured to execute queries against data store202to obtain the information therein.

FIG. 3illustrates how a user who wishes to obtain a mobile device registers with system200, and how the device is registered with system200as well. First, the user provides user registration information228to data provider service206. This is illustrated by block300inFIG. 3. In one embodiment, the user simply contacts an administrator of system200and provides an amount of user identification information sufficient to create a user object. The user object can include a user ID, which is a global unique identifier that uniquely identifies a user in the system, and may be assigned by the system or an administrator in the system. The user object can also include a user name which is a unique user name within the domain of the user and may also be chosen by the user, or assigned by the administrator or the system. The user object also illustratively includes the user's first name, the user's last name, the user's email address, the user's domain name (such as the company name), if applicable, and an indication as to whether the user is mobile enabled.

The indication as to whether the user is mobile enabled indicates whether the user is a mobile user in the company. For example, this field may be set to true if a user is allowed to submit mobile sales orders. Otherwise the field is set to false. Of course, the User object can include other information or different information. For instance, the user can provide user preferences, such as the times of day that the user wishes to be contacted on different devices that are registered under the user's name. By way of example, the user may wish to be contacted by cellular telephone during the morning hours and by electronic mail on the user's laptop in the afternoon hours.

Once this user registration information is received, it is provided to data provider service206. Data provider service206generates a User object in a standard format. In one embodiment, the user registration information228is provided to data provider service206as a standard document (such as an XML document). Data provider service206then arranges the data into the standard User object form. Generating the User object is illustrated by block302inFIG. 3. Data provider service206then invokes one of methods214on interface204, through network210, in order to employ interface204to store the newly created User object in context data store202. This is indicated by block304inFIG. 3.

Once the User object has been created and stored, the device which the user wishes to use is then customized for the user. This is illustrated by block306inFIG. 3. In one illustrative embodiment, the system administrator or provisioning department of the company that has deployed system200simply obtains the device requested by the user and then accesses the User object to customize the device for the user. For example, if the device which has been requested is a cellular telephone, customizing the device may include programming the cellular telephone with the user ID and user name.

Once the device has been customized for the user, the device provides device registration information226to data provider206. This is indicated by block308inFIG. 3. The device registration information can include, for example, a device name which may be a user-friendly name for the device, a device ID which is a unique value and may be generated by system200, a user ID which is the identifier for the owner or user of the device, a device type (such as cellular telephone, laptop, palmtop, etc.), an identification of the processor on the device, an identification of the screen size of the device (such as horizontal and vertical screen dimensions), an identification of the manufacturer of the device, and an indicator of the radio capabilities of the device (such as whether the device includes capabilities for GPS, GPRS, CDMA, 802.11, etc.). The device registration226information can also include an indication of the particular operating system running on the device, the version of the operating system running on the device, the physical address of the mobile device (which may be an IP address or for a cellular phone, its telephone number), the amount of random access memory on the device, etc.

Once data provider service206receives device registration information226, it forms a Device object which represents the device registration information226. This is indicated by block310inFIG. 3. Data provider service206then invokes a method214on interface204through network210, in order to store the Device object in context data store202. This is indicated by block312inFIG. 3.

Data provider service206can also receive information from a variety of other sources. For instance,FIG. 2illustrates that data provider service206receives schedule information230from data source222which is a calendar application. In that example, once a user has been registered in system200by receipt of user registration information228, associated calendar or schedule information230can be provided for that user. Schedule information230can include, for example, the normal working hours of the identified user, appointments scheduled for the identified user, as well as vacations or other times that a user may be unavailable. As with the user and device registration information, data provider service206forms a Schedule object and invokes methods214on interface204to store data represented by that object in context data store202.

Another example of a data source which provides context information to system200, and which is illustrated inFIG. 2, is a cellular network224. Cellular network224includes a cellular telephone314, a tower316for a first cell site (cell site A) and a tower318for a second cell site (cell site B). Cellular network224is already implemented with location capability that provides location information indicative of a generalized location of cellular telephone314(such as which cell site it is currently located in). In one embodiment, once cellular telephone314has registered by providing device registration information226, cellular network224is queried to obtain location information232that is associated with the specific cellular telephone314that has registered with system200. The location information may illustratively include a device ID which identifies the cellular telephone314(or other device) for which the location is being tracked, the country that the device is located in, the state that the device is located in, the city that the device is located in, and the XY coordinates (in terms of longitude and latitude) where the device is located. Data provider, service206again generates a Location object representing the location information and invokes methods214to store information represented by the Location object in context data store202.

While a number of context data sources are illustrated inFIG. 2, it will be appreciated that any number of additional or different data sources can be provided as well. For example, if the device which has been registered includes a GPS receiver, then GPS location can be provided instead of location information232from cellular network224. In addition, the device can provide information relating to the cellular carrier it uses as well as the roaming charges which are charged by that carrier. In addition, applications which reside on the device that has been registered can provide application metadata which includes the name and version of the application, the size of the application, etc.

In addition, a company may provide context information related to the organization of the company. For instance, a Team object may be included which identifies teams, a leader of each team and the name of each team. Similarly, team members may be identified by an object which correlates a team identifier with a user identifier. Many other sources of context data can be provided as well.

It should also be noted that information can be provided from the data sources to interface204in a variety of different ways. For instance, where data provider service206is implemented as a web service, the data source simply needs to provide a web address for contact service interface204along with the location of an XML document which contains the context information being submitted by the data source. In that embodiment, data provider service206retrieves the XML document and invokes the proper interface214to have context service interface204store information represented by an object generated based on the XML document in context data store202.

In another embodiment, however, the methods of interacting with context data store202are implemented in class libraries. The data sources, if they have access to the class libraries, can instantiate objects from the class libraries and call the methods on the instantiated objects themselves. As illustrated inFIG. 2, class libraries236can be accessed by the data sources and objects in those classes can be instantiated and used to provide data to context data store202.

Not only can data be provided to context data store202by data sources, but it can be retrieved from context data store202by a requesting application220.FIG. 4is a flow diagram illustrating one embodiment in which requesting application220requests data from context data store202. First, the requesting application220identifies a need for retrieving context information. In such an embodiment, requesting application220can illustratively be a context-aware application which makes decisions and generates messages and other outputs based on context. Thus, requesting application220has identified a need for a certain item of context information. This is indicated by block350inFIG. 4.

Requesting application220then invokes find service208by calling the appropriate web service method. Again, requesting application220simply provides the web address of context service interface204, along with a location in which requesting application220desires to receive the XML document containing the context information requested. In that embodiment, find service208returns the XML document containing the requested context information to the specified location for access by requesting application220. Calling the web service method is indicated by block352inFIG. 4and the find service returning the XML document with the desired context information is indicated by block354inFIG. 4.

Of course, as with providing data to context data store202, requesting applications202can (if they have access to class libraries234) simply instantiate objects which implement the context service interface204and directly invoke the methods on those objects. This is indicated in greater detail in the flow diagram ofFIG. 5. First, requesting application220identifies a need to retrieve context information. This is indicated by block356inFIG. 5. Requesting application220then accesses class libraries234and instantiates desired objects. This is indicated by block358. Finally, requesting application220invokes desired methods on the instantiated objects to retrieve desired context information from context data store202. This is indicated by block360.

In accordance with yet another embodiment, it should be noted that requesting application220can access data in context data store202directly using database queries. For example, if data store202is implemented as a structured query language (SQL) database, then, so long as requesting application220is provided with access to data store202, it can directly retrieve context information from data store202using SQL queries. Similarly, if the data sources are given direct access to data store202, they can add information to data store202directly using SQL queries.

The class libraries discussed herein and used to implement interface204can take a wide variety of different forms. One illustrative embodiment of a number of the classes in an exemplary class library are set out in appendix A hereto. However, it should be noted that the classes discussed therein are exemplary only and any number of additional or different classes can be used as well.

Illustratively, all accesses to the context information through interface204are subjected to a security policy implemented by security layer212. In one embodiment, security layer212is a rules-based security layer. Security layer212thus enforces access restriction and any other security measures implemented in the rules. Therefore, users are only allowed to access context information for which they are authorized by layer212. The rules can implement security in various levels. For example, some users may be provided with complete access to all context information. Other users may be provided with no access to context information. Still other users may be provided with read only access, or read only access to some of the context information and read/write access to other context information. Of course, other or different security measures can be implemented as well.

FIG. 6is a block diagram of another embodiment of the present invention in which the context service system is implemented in a client/server environment.FIG. 6illustrates system200discussed with respect toFIG. 2on a server400.FIG. 6also includes a local system402, which includes the same components as system200except that they are located on client404. Thus, system402includes local cache406, local context service interface408, local data provider service410and local find service412.FIG. 6also shows requesting application220, network210, and data sources which are collectively designated by numeral420.

A number of operations will now be described in order to better illustrate the operation of the system shown inFIG. 6. In one illustrative operation, requesting application220requests local find service412to retrieve and return desired context information. In this embodiment, the desired context information is stored in cache406. Therefore, local find service412invokes the appropriate method on interface408and retrieves the desired context information and returns it to requesting application220.

In another operation, the information is not located in cache406. In that embodiment, requesting application220provides local find service412with a request to retrieve the desired context information. Local find service412invokes the method on interface408to retrieve the desired information, and a null value (or other value) indicating that the information does not exist in cache406is returned. In that case, local find service412accesses find service208in system200through network210. Find service208invokes the appropriate method on interface204to retrieve the data from data store202. The data is retrieved and provided from find service208back to local find service412which returns it to requesting application220. Local find service412then invokes an appropriate method on interface408to add the requested context information to cache406.

In order to add context information, data source420first provides the context information to local data provider service410. Local data provider service410then provides the information through network210to data provider service206in system200. Data provider service206, in turn, invokes an appropriate method on interface204to add the context information to context data store202. This is confirmed back to local data provider service410. Local data provider service410then invokes an appropriate method on interface408to add the context information to cache406and this is also confirmed to local data provider service410.

It can thus be seen that the present invention helps to reduce information overload to developers and applications by filtering the information according to what is relevant in a current context. It does this by allowing a developer to write applications that are context aware and therefore reduce context information requested to that which is necessary. Similarly, the present invention provides a single place for obtaining all information related to context. The invention functions as an aggregator and abstractor for different providers of context information. Thus, it offers a simple object-oriented programming model to access contextual information so that the developer only needs to learn a single set of semantics instead of one corresponding to each source of context information. By implementing a security layer, the present invention enables custom authorization schemes to address privacy concerns. Similarly, by providing developers with access to the data store directly through SQL queries, developers can customize the service to their needs and performance requirements.

Using the present system, the scenario discussed in the background section can be greatly enhanced. For example, assume that the dispatcher receives a call from a customer that the television is broken (such as fails to display color) and that the customer wishes a technician to attend to the problem today. The dispatcher can simply select an “assign technician” function on a context aware application. This results in a technician being assigned to the job based on several factors considered by the function, such as, current location of the technician, the level of expertise of the technician, and the technician's schedule for the day. All of this information is obtained from the context service component and incorporated into the function of the context-aware application. The dispatcher then assigns the identified technician to the job. The identified technician's schedule is automatically updated with the new job and a message is sent to the technician's mobile telephone informing him of the change in schedule. The technician also receives directions to the new customer site on his mobile device. The technician arrives at the site, completes the job and sends a message back to the call center stating that the job has been completed. This entire scenario is enabled because the application can obtain context information from a central location which has aggregated and abstracted the context information for access by the application.

Of course, a wide variety of other applications can be written using the present context service. For instance, a mobile worker can subscribe to traffic updates on a cellular telephone, to receive those updates everyday from 5-6 PM when traffic is heavy. However, when the worker is out of town for the day, the application realizes this because it is contained in the context information provided by the context service (such as through the Schedule object). Therefore, the application detects that the worker is not in a local area and hence the traffic report is not sent.

Similarly, assume that a worker has identified as a preferred mobile device a personal digital assistant. Assume also that another person attempts to send the worker a message that is quite large, but not very urgent. The context-aware application detects this (again by retrieving context information from the present context service). The message is thus sent to the worker's desk-top computer so that the worker will receive it when he or she returns to the office at the end of the day. This can of course be accomplished by having the worker set up a preference as to which device should receive messages, based on message size.

These are but a few exemplary scenarios that can be addressed by context aware applications using the context service of the present invention. Of course, these are illustrative scenarios only, provided to illustrate some uses and operations of the present invention, and countless others can be supported by the present invention.