Patent Grant
9077584
This application claims priority to Indian Patent Application Serial No. 1364/CHE/2006 filed Aug. 1, 2006; to Korean Patent Application Serial No. 10-2007-0077317 filed Aug. 1, 2007; and to International Application PCT/KR2007/003711 filed Aug. 1, 2007; the contents of each of which are incorporated herein by reference.
The present invention relates generally to the field of mobile communication, and more particularly to OMA (Open Mobile Alliance)-developed applications over SIP (Session Initiation Protocol), such as instant messaging (IM), push to talk over cellular (PoC) and any other future applications. In other words, this invention relates to those applications where service settings provided by a user are published to, stored and executed by an application server. More specially, this invention relates to a system and method for managing a user preference profile.
While providing various services, service providers allow users to choose their preferences to customize the behaviours of applications according to their needs and situations. Currently, the PoC application developed by OMA allows users to configure service settings like Incoming Session Barring, Answer Mode, Incoming Instant Personal Alert Barring, Simultaneous PoC Session Support Settings, etc. Also, the SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) IM application developed by OMA defines service settings like Incoming Session Barring, Incoming IM Pager Mode Barring, Delivery of Deferred Messages, etc. New applications under development also have similar service settings. A user makes use of his/her client application to indicate his preferences to respective application servers. Some applications of the prior art are identified as will be described below:
As an example,
A flow diagram showing a process of publishing service settings by a user is illustrated in
SIP PUBLISH is a method used for publishing service settings onto an application server via an SIP interface. Usually, service setting publication occurs after each registration, and also occurs as and when a user wants to update/refresh his service settings (S210). The application server 111, 121 stores such user preferences and executes as and when applicable (S230).
The aforementioned prior art has the following limitations:
The object of the present invention is to provide a system and method for storing and managing various application service settings at a shared location, thereby reducing the complexity of service setting maintenance and the number of service setting publications onto an application server. The present invention also provides an operation in which the application server performs service settings by using existing interfaces when storing the service settings at the shared location. The present invention need not define any new interface to overcome weaknesses identified in the relevant prior art.
In order to solve the aforementioned technical problem, the present invention provides a system for managing a user preference profile, the system including: a plurality of application clients; a plurality of application servers corresponding to the plurality of application clients; and a shared server for storing and managing user preference profiles for respective applications, wherein the application clients selectively activate the user preference profiles stored in the shared server and provide the selectively activated user preference profiles to the application servers.
Also, the present invention provides a method of managing a user preference profile, the method including the steps of: creating a plurality of user preference profiles, each corresponding to each application, by a plurality of application clients; storing the created user preference profiles in a shared server; selectively activating the stored user preference profiles; and providing the selectively activated user preference profiles to corresponding application servers.
[Mode for Invention]
With an increase in the number of services using various applications, each of which requires some service settings to be indicated by user preferences, the service settings are stored in application servers in a distributed manner. The invention proposes to aggregate such service settings at a common location like a shared user profile XDMS (XML Document Management Server). Also, when a user enables any one of instances of those pre-configured service settings, all the conforming service settings in the profile instance can be activated at the same time in each corresponding server.
As illustrated in
As an example,
For logical and simplicity reasons in explaining this invention, the shared profile XDMS is considered a location for storing aggregated service settings, but they may be stored in any such similar entity.
This invention proposes a new schema for multiple profiles and aggregating various service settings. For simplicity, it is assumed that the schema provides details considering the settings possible as identified in the existing art. The schema can be extended to accommodate potential future services and also changes to the service settings of already existing services. The content type may be called as “application/user-preference-profile”. There are two possible approaches for active profile indication:
A generic user preferences profile format for active profile indication by a flag is presented below in Table 1:
A generic user preferences profile format for active profile indication by an attribute is presented below in Table 2:
A user can create profiles with names like Home Profile, Office Profile, Travel Profile, Sleep Profile, Outdoor Profile, Meeting Profile and the like, each of which contains service settings of various services, such as Incoming Session Barring, Incoming Instant Personal Alert Barring, Incoming IM Pager Mode Barring, etc. and user preference values for the respective settings.
The protocol used for creating a user preferences profile onto the XDMS is as illustrated in
An example of a generic user preferences profile with active profile indication by a flag is presented below in Table 3:
An example of a generic user preferences profile with active profile indication by an attribute is presented below in Table 4:
The user may want to read current preferences indicated by him/her earlier, from various user preference profiles. The invention proposes to use an XCAP GET operation for retrieving the profile as illustrated in
An example of the user's retrieving a user preferences profile is presented below in Table 5:
The user may want to change a user preference profile already stored on the XDMS in any one of the following procedures:
The invention proposes to use XCAP GET and XCAP PUT methods for performing any one of the above-specified operations as requested by the user (S610, S620, S630). These operation is illustrated in
A user may want to indicate an active profile out of various user preference profiles stored in the XDMS 360. The invention proposes two methods of performing the operation for “activating a profile”:
When the active profile is indicated as a flag or attribute value, as in method 1, there are two ways for an application server to come to know about an activated user preference profile:
The way for an application server to subscribe to XML document changes to a user preferences profile (method 1.1) is as follows:
The application server needs to SUBSCRIBE for any changes to an XML document user preferences profile.
Subsequently, SUBSCRIBE and NOTIFY will be seen as described in below examples.
An example of SUBSCRIBE and NOTIFY with active profile indication by an attribute is presented below in Table 6:
An example of SUBSCRIBE and NOTIFY with active profile indication by an attribute is presented below in Table 7:
The way for an XDM Server to publish the activated profile to a corresponding application server (method 1.2) is as follows:
In this method, as soon as the user modifies the user preference profile XML document, the XDM Server sends SIP PUBLISH containing the active profile and also the contents of the active profile to the application server. The sequence of operations are as illustrated in an example of
As an alternative, this method proposes to use the SIP PUBLISH method for indicating the application server about the active profile. A difference when compared to the prior art is that the user will publish only active profile name setting when he/she registers through SIP REGISTER or whenever he/she wants to change the active profile. SIP PUBLISH is generated with the following clarifications:
Application Server Identifier: for example, PoC or IM or CPM identifier
Event: new event package “preference-settings”
Body: contains a target profile to be activated and its URL stored in the user preference XDMS.
New event package “preference-settings”:
The name of the new event package can be named as “preference-settings”. This value may appear in the event header field present in SIP PUBLISH.
Body contents for SIP PUBLISH with event “preference-settings”:
The body of an SIP PUBLISH request contains a preference-setting document in an “application/preferences-settings+xml” data format. This preference-setting document describes preferences-related settings of a user. The format of the preference-setting document identified with the MIME type “application/preferences-settings+xml” is defined with an example below:
A user preference-setting document begins with the root element tag <preferences-settings>. It consists of a <target-profile> element including the following attributes:
On receiving publication of active-profile indication, the application server fetches user preferences of the activated profile from the XDM Server. The method of fetching active profile contents is to obtain them via the XCAP GET method or to subscribe for document changes to the active profile through the SIP SUBSCRIBE method. The application server locally stores indication of the active profile and also user preference contents for those service settings for future execution purposes. The application server is now aware of the user preference profile and therefore will execute those settings as in the existing prior art. The sequence of operations are illustrated in
If the application server 311, 321 needs to be aware of any changes to the user preferences of any user preference profile, then the application server 311, 321 needs to subscribe for any changes to the XML document user preferences profile. In this way, the application server 311, 321 is almost instantly aware of the changes made by the user via SIP NOTIFY.
The whole invention can be summarized with flows explained below in connection with
FIG. 10—Summary of Inventive Method 1:
Create/Update User Preferences Profile:
A user's multiple service profiles are consolidated in one place of a “user preference XDMS” (S1010).
1. The user can create or modify his user preference profile with an XCAP PUT request originating from his client to the user preferences XDMS.
2. The user preference XDMS creates/updates the user preference profile if the request is from an authenticated user.
3. The user preferences XDMS processes the XCAP PUT request, and acknowledges to the client for a result thereof.
Activate User Preference Profile:
Each user preference profile in the user preference XDMS has an “activation flag”, and the user can activate a particular profile by setting this flag to TRUE (S1020).
4. The user can set the “activation flag” in his user preference profile (user preference profile created as explained in step 1) with an XCAP PUT request originating from his client to the user preference XDMS.
5. The user preferences XDMS is aware of the profile name that the user wants an application server to use.
6. The user preference XDMS processes the XCAP PUT request, and acknowledges to the client for a result thereof.
Post Activation of User Preference Profile:
Delivery of the activated profile to the application server is achieved by the application server's subscribing to the activated profile document changes. Updating of the activated profile will also be delivered to the application server using the subscribed event (S1030).
7. Upon activation of the user preference profile, the user preference XDMS notifies the pertinent part of the activated user preference profile to each application server, as will be explained in below steps.
8. Since the application server keeps the subscription to the “activation flag” changes, it can be notified of the activated user preference profile. In order to do so, the application server originates a SIP SUBSCRIBE request to the user preference XDMS with the following clarifications:
Event: xcap-diff
Target Document: user preference profile document
Filter Description: if the ‘activation flag’ is set, the pertinent part of the corresponding user preference profile should be notified.
9. The user preference XDMS processes the SIP SUBSCRIBE request, and acknowledges to the application server for a result thereof.
10. The user preference XDMS originates a notification of the activated user preference profile contained in SIP NOTIFY to the application server with the following clarifications:
Event: xcap-diff
Body: part of activated user preference profile pertinent to corresponding application server.
11. The application server processes the SIP NOTIFY request, and acknowledges to the user preferences XDMS for a result thereof.
FIG. 11—Summary of Inventive Method 2:
Create/Update User Preference Profile:
A user's multiple service profiles are consolidated in one place of a “user Preference XDMS” (S1110).
1 to 3. Same as steps 1 to 3 explained in chapter “Summary of Inventive Method 1”.
Activate User Preference Profile:
Each service profile in the user preference XDMS has an “activation flag”, and the user can activate a particular profile by setting this flag to TRUE (S1120).
4 to 6. Same as steps 4 to 6 explained in chapter “Summary of Inventive Method 1”.
Post Activation of User Preference Profile:
The user preference XDMS will notify or deliver the part of the activated profile pertinent to the application server to that application server by using SIP PUBLISH to a service setting-related event package. Updating of the activated profile will also be delivered to the application server by using SIP PUBLISH (S1130).
7. Same as step 7 explained in chapter “Summary of inventive Method 1”.
8. The user preference XDMS originates an SIP PUBLISH request containing that part of the active profile to the application server with the following clarifications:
Event: application server's event for service setting, e.g. “poc-settings”
Application Server Identifier: e.g., media feature tag
Body: contains pertinent part of activated user preference profile
9. The application server processes acknowledges to the user preferences XDMS for the SIP PUBLISH request.
FIG. 12—Summary of Inventive Method 3:
Create/Update User Preference Profile:
A user's multiple service profiles are consolidated in one place of a “user preference XDMS” (S1210).
1 to 3. Same as steps 1 to 3 explained in chapter “Summary of Inventive Method 1”.
Activate User Preference Profile:
The user activates the user preference profile per application by using SIP PUBLISH. The contents of the SIP PUBLISH may be the pointer to a target user preference profile to be activated, which resides in the user preferences XDMS (e.g., Home profile, Office profile). A new event may be needed for this, e.g., “preference-settings” (S1220, S1240).
4. The user can indicate his choice of the user preference profile to be activated (user preference profile created as explained in step 1) from his client to the application server in an SIP PUBLISH request with the following clarifications:
Application Server Identifier: e.g., PoC or IM or CPM identifier
Event: new event “preference-settings”
Body: contains target profile to be activated with its URL in user preference XDMS
5. The application server processes the SIP PUBLISH request, and acknowledges to the client for a result thereof.
Post Activation of User Preferences Profile:
6. The application server then fetches the contents of the activated user preference profile from the user preference XDMS by using either an XCAP GET request or an SIP SUBSCRIBE request (S1230, S1250).
6.1. Using XCAP GET request: in order to receive the contents of the activated user preference profile from the user preferences XDMS, the application server originates the XCAP GET to the URL of the target user preference profile to be activated, which it has come to know through the SIP PUBLISH in step 4.
The 200 OK response from the user preference XDMS to the application server contains user preferences fetched from the activated user preference profile.
6.2. Using SIP SUBSCRIBE Request: the application server subscribes to the user preference profile in the XDM server, which the user requests it to activate, by using the SIP PUBLISH in step 4. Then, the application server is notified of the contents of the activated user preference profile and any updates thereof. Thus, the application server originates an SIP SUBSCRIBE request to the user preference XDMS with the following clarifications
Event: xcap-diff
Target Document: user preference profile document
Filter Description: “active profile name”, which pertinent part of corresponding profile should be notified.
Followed by steps 9 to 11 as explained in chapter “Summary of Inventive Method 1”.
More automation may be provided to scheduled activating of profiles, life time of an active profile, etc.
Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be affected therein by one skilled in the art without departing from the scope or spirit of the invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 1364/CHE/2006 | Aug 2006 | IN | national |
| 10-2007-0077317 | Aug 2007 | KR | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/KR2007/003711 | 8/1/2007 | WO | 00 | 2/2/2009 |
| Publishing Document | Publishing Date | Country | Kind |
|---|---|---|---|
| WO2008/016263 | 2/7/2008 | WO | A |
| Number | Name | Date | Kind |
|---|---|---|---|
| 6490587 | Easty et al. | Dec 2002 | B2 |
| 6757729 | Devarakonda et al. | Jun 2004 | B1 |
| 7010292 | Jerbi et al. | Mar 2006 | B2 |
| 7068189 | Brescia | Jun 2006 | B2 |
| 7849154 | Grecco et al. | Dec 2010 | B2 |
| 8028077 | Gaya et al. | Sep 2011 | B1 |
| 20010037407 | Dragulev et al. | Nov 2001 | A1 |
| 20010047349 | Easty et al. | Nov 2001 | A1 |
| 20020049751 | Chen et al. | Apr 2002 | A1 |
| 20030182361 | Jensen et al. | Sep 2003 | A1 |
| 20040122896 | Gourraud | Jun 2004 | A1 |
| 20040202117 | Wilson et al. | Oct 2004 | A1 |
| 20040249910 | Jerbi et al. | Dec 2004 | A1 |
| 20040255031 | Nomura et al. | Dec 2004 | A1 |
| 20050021784 | Prehofer | Jan 2005 | A1 |
| 20050114493 | Mandato et al. | May 2005 | A1 |
| 20060053208 | Laurila et al. | Mar 2006 | A1 |
| 20060235981 | Westman et al. | Oct 2006 | A1 |
| 20070073892 | Laurila et al. | Mar 2007 | A1 |
| 20070088670 | Laurila | Apr 2007 | A1 |
| 20070127505 | Laurila et al. | Jun 2007 | A1 |
| 20070136422 | Ohtani et al. | Jun 2007 | A1 |
| 20070136475 | Leppisaari et al. | Jun 2007 | A1 |
| 20080004007 | Kallio | Jan 2008 | A1 |
| Number | Date | Country |
|---|---|---|
| 1552148 | Dec 2004 | CN |
| 2003-032721 | Jan 2003 | JP |
| 2005-505195 | Feb 2005 | JP |
| 2006-512640 | Apr 2006 | JP |
| 2008-512911 | Apr 2008 | JP |
| 1020010091276 | Oct 2001 | KR |
| 1020040037192 | May 2004 | KR |
| 1020040044657 | May 2004 | KR |
| WO 03103271 | Dec 2003 | WO |
| WO 2006051159 | May 2006 | WO |
| WO 2006075873 | Jul 2006 | WO |
| Entry |
|---|
| XML Document Management Architecture; Candidate Version 1.0—Jun. 28, 2005. |
| Korean Office Action dated Jan. 29, 2015 issued in counterpart application No. 10-2004-0035292. |
| Number | Date | Country | |
|---|---|---|---|
| 20090193329 A1 | Jul 2009 | US |
