Title of Invention	METHOD AND SYSTEM FOR CONTENT LEVEL REACTIVE AUTHORIZATION FOR CONTENTS REQUESTED BY A WATCHER
Abstract	The present invention relates to the field of Session Initiation Protocol (SIP) based Presence Applications. In particular, the invention proposes reactive authorization based on content requested by a watcher. Presentity may want to protect some part of PUBLISHed presence information and disseminate the information only after authorizing the watchers who request for the information. Content level reactive authorization may be achieved by using a static mechanism or a dynamic mechanism. In, the static mechanism, the presentity modifies the Presence Authorization Rules document (present in the Presence XDM server) to include information that requires his authorization, when requested by a watcher. The identity of the watchers and the protected content may be informed to the presentity by extending the format of watcher information to include information about the protected content requested by the watcher. A 'watcher' element tag is extended to contain any number of 'requested-content' element tags. The 'requestedcontent' element tags include element tags from the presence information which are marked as protected by the presentity. After knowing the details of the watchers and the content they have requested, the presentity has to perform XCAP operations to authorize the watchers and the content. Alternatively, a new event package named "presence.watchercontent" may be created to inform the presentity about the identity of the watchers and the protected content. In the dynamic mechanism, no modifications to the Presence Authorization Rules document are required. The presentity, while publishing the presence information, publishes details of the content that require reactive authorization and the identity of the watchers who have requested for the content.

Title of Invention

METHOD AND SYSTEM FOR CONTENT LEVEL REACTIVE AUTHORIZATION FOR CONTENTS REQUESTED BY A WATCHER

Abstract

The present invention relates to the field of Session Initiation Protocol (SIP) based Presence Applications. In particular, the invention proposes reactive authorization based on content requested by a watcher. Presentity may want to protect some part of PUBLISHed presence information and disseminate the information only after authorizing the watchers who request for the information. Content level reactive authorization may be achieved by using a static mechanism or a dynamic mechanism. In, the static mechanism, the presentity modifies the Presence Authorization Rules document (present in the Presence XDM server) to include information that requires his authorization, when requested by a watcher. The identity of the watchers and the protected content may be informed to the presentity by extending the format of watcher information to include information about the protected content requested by the watcher. A 'watcher' element tag is extended to contain any number of 'requested-content' element tags. The 'requestedcontent' element tags include element tags from the presence information which are marked as protected by the presentity. After knowing the details of the watchers and the content they have requested, the presentity has to perform XCAP operations to authorize the watchers and the content. Alternatively, a new event package named "presence.watchercontent" may be created to inform the presentity about the identity of the watchers and the protected content. In the dynamic mechanism, no modifications to the Presence Authorization Rules document are required. The presentity, while publishing the presence information, publishes details of the content that require reactive authorization and the identity of the watchers who have requested for the content.

Full Text	We Claim: 1. A method for content level reactive authorization comprising the steps of: the presentity modifying the Presence Authorization Rules document present in the Presence XDM server to include information that requires authorization, when requested by a watcher; informing the identity of the watcher and the protected content to the presentity by extending the format of watcher information to include information about the protected content requested by the watcher; the presentity performing XCAP operations to authorize the watchers and the content, after knowing the details of the watchers and the content they have requested. 2. The method as claimed in claim 1 wherein a watcher element tag is extended to contain any number of 'requested-content' element tags. 3. The method as claimed in claim 2 wherein the requested-content element tags include element tags from the presence information which are marked as protected by the presentity. 4. The method as claimed in claim 1 further comprising the steps of creating an event package to inform the presentity about the identity of the watchers and the protected content. 5. A method for content level reactive authorization utilizing a dynamic mechanism, where, the presentity, while publishing the presence information, publishes details of the content that require reactive authorization and the identity of the watchers who have requested for the content. 6. A system for content level reactive authorization comprising: the presentity modifying the Presence Authorization Rules document present in the Presence XDM server to include information that requires authorization, when requested by a watcher; and means for informing the identity of the watcher and the protected content to the presentity by extending the format of watcher information to include information about the protected content requested by the watcher; where the presentity performs XCAP operations to authorize the watchers and the content, after knowing the details of the watchers and the content they have requested. 7. The system as claimed in claim 6 wherein a watcher element tag is extended to contain any number of 'requested-content' element tags. 8. The system as claimed in claim 7 wherein the requested-content element tags include element tags from the presence information which are marked as protected by the presentity. 9. The system as claimed in claim 1 further comprises an event package created to inform the presentity about the identity of the watchers and the protected content. 10. A system for content level reactive authorization utilizing a dynamic mechanism, where the presentity, while publishing the presence information, publishes details of the content that require reactive authorization and the identity of the watchers who have requested for the content. 11. A method for content level reactive authorization substantially described particularly with reference to the accompanying drawings. 12. A system for content level reactive authorization substantially described particularly with reference to the accompanying drawings. FIELD OF THE INVENTION The present invention, in general, relates to the field of SIP based presence applications as defined by the OMA specifications. The invention proposes reactive authorization based on content requested by a watcher. More particularly the present invention relates to method and system for content level reactive authorization. DESCRIPTION OF RELATED ART In the currently existing mechanism, by using the Presence Authorization Policies the Presentity can tell the Presence Server who are authorized to watch his/ her Presence Information and, if authorized to watch, what part of his/her Presence Information they can see. Such Presentity's Presence Authorization Policies are represented as Presence Authorization Rule XML document and stored in Presence XML Document Management Server (XDMS). The Presence Authorization Rule consists of two parts; Subscription Authorization Rule that determines who is authorized to subscribe to the Presentity's Presence Information, and Presence Content Rule that determines which contents of the Presentity's Presence Information are authorized to be delivered to the subscribing Watcher. The following Table 1 shows the example of the Presence Authorization Rule. In this example, the rule specifies that the user with the URI of either "tel:+43012345678" or "sip:[email protected]" is allowed to subscribe the Presentity's Presence Information, and the subscribed user with the URI of either "tel:+43012345678" or "sip:[email protected]" is allowed to be provided with the 'PoC' service, 'willingness', and 'status-icon' related presence attributes. I Table 1. Example Presence Authorization Rule document When a Presence Server receives a SUBSCRIBE request on a Presentity's Presence Information from a Watcher, the Presence Server fetches the Presentity's Presence Authorization Rules from Presence XDMS, and uses it to authorize the Watcher with regards to subscription request and the parts of Presence Information to be delivered. The Presence Server keeps synchronized with the Presence XDMS by "xcap-diff event package subscription such that the changes in the Presentity's Presence Authorization Rules could be instantly reflected in the Presence Server's handling of the Presence Information requests and delivery. This is called as Proactive Presence Authohzation as the Presence Server can perform authorization for itself based on the predescribed static rules (i.e., Presence Authorization Rules in Presence XDMS) and without the need of direct interaction with Presentity. Also, the Reactive Presence Authorization, where the Presence Server authorizes the Watcher's subscription requests to the Presentity's Presence Information per the Presentity's reaction on those, can be achieved by the following procedure: Firstly, the Presentity needs to subscribe for "presence, winfo" event package to Presence Server. Upon this event subscription, the Presence Server notifies the Presentity of the current status of Watcher lists and their corresponding subscription states. With this information, the Presentity can identify which Watcher is 'pending' subscription state and, if the Presentity wants to allow the Watcher to see his Presence Information, the Presentity revises the Presence Authorization Rule in Presence XDMS as such. Such modifications of the rules are notified to the Presence Server and then the Presence Server applies those updated Presence Authorization Rules to handle the 'pending' subscription requests from the Watchers. The example flows of how the current reactive Presence Authorization mechanism works are shown in Figure 1 and the steps involved are discussed in the followings. The following describes each step in the Figure 1: Note: Presence Server subscribing for changes to Presence Authorization Rule documents stored in Presence XDMS is omitted from the above Figure 1 for simplicity. 1. The Presentity wishing to know the list of watchers who are subscribed for his/her Presence Information sends a SIP SUBSCRIBE request to SIP/IP core subscribing for "presence.winfo" event package. 2. The SIP/IP core forwards the request to the Presence Server of Presentity's domain. 3. The Presence Server processes the received SIP SUBSCRIBE and upon successful processing sends 200 OK responses to SIP/IP Core. 4. The SIP/IP core forwards the 200 OK responses to the Presentity. 5. The Presence Server sends SIP NOTIFY request containing the details of Watchers to the SIP/IP core. 6. The SIP/IP core forwards the SIP NOTIFY request to the Presentity. 7. The Presentity sends the 200 OK responses for the SIP NOTIFY request. 8. The SIP/IP core forwards the 200 OK responses to the Presence Server. 9. Watcher wishing to subscribe for Presence Information of the Presentity sends a SIP SUBSCRIBE request to the SIP/IP Core. 10. The SIP/IP Core forwards the SIP SUBSCRIBE to the Presence Server. 11. The Presence Server processes the received SIP SUBSCRIBE and finds out that the Watcher is not authorized to subscribe for Presentity's Presence Information and hence acknowledges the SIP SUBSCRIBE with "202 Accepted" responses. 12. The SIP/IP Core forwards the "202 Accepted" responses to the Watcher. 13. As soon as the PS sends a SIP 202 Accepted response to accept the subscription, it sends a SIP NOTIFY request as mandated by [RFC3265]. At this time, the Presence Information to be delivered to the Watcher may be not available yet as the Watcher has not yet been authorized to see the Presentity's Presence Information. As such, a "dummy" SIP NOTIFY request can be sent, with a valid neutral or empty Presence Information and a valid Subscription-State header field (set to "pending") for the time being. 14. The SIP/IP Core forwards the SIP NOTIFY request with the "dummy" Presence Information to the Watcher. 15. The Watcher sends 200 OK responses to the received SIP NOTIFY request. 16. The SIP/IP Core forwards 200 OK responses to the Presence Server. 17. The Presence Server sends a SIP NOTIFY request to the Presentity which contains the detailed lists of the Watchers who have subscribed for Presentity's Presence Information and the state of the subscription which is "pending" in this case. 18. The SIP/IP Core forwards the SIP NOTIFY request to the Presentity. 19. The Presentity acknowledges the SIP NOTIFY request with 200 OK responses. 20. The SIP/IP Core forwards the 200 OK responses to the Presence Server. 21. After getting to know the Watcher's identity who is 'pending' subscription state, the Presentity wishes to authorize the Watcher to view his/her Presence Information and hence the Presentity does the XCAP operations (RFC 4825, "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)") to change the Presence Authorization Rule document to authorize the Watcher. Note: For brevity sake the details of XCAP operations and the details of Presence Server getting to know the changes in the Presence Authorization Rules in Presence XDMS are not shown. 22. The Presence Server authorizes the Watcher per the updated Presence Authorization Rule and issues another SIP NOTIFY containing the valid Presence Information which he/she is authorized to view per the updated Presence Authorization Rule. 23. The SIP/IP Core forwards the SIP NOTIFY to the Watcher. 24. The Watcher sends 200 OK responses for SIP NOTIFY request. 25. The SIP/IP Core forwards the 200 OK responses to the Presence Server. LIMITATIONS In the current mechanism, the base is the Proactive Presence Authorization mechanism based on the static rule named "Presence Authorization Rule" in Presence XDMS. The Reactive Presence Authorization can be achieved by the indirect way where the Presentity subscribes "presence.winfo" event package, identifies the pending subscription request from Watchers by getting notification, of "presence.winfo" event, updating the static rule of "Presence Authorization Rule" in Presence XDMS, then the Presence Server gets notified of such changes in the rules and applies it to the pending subscriptions. With the current presence authorization mechanism, the following limitations are observed: A) In the current mechanism, the above Reactive Presence Authorization applies only to the Watcher's subscription request, i.e., it is only about whether to allow a presence subscription request or not. In other words, the authorization for the requested contents of presence information is not possible. As such, there's no way to reactively authorize the Watcher's requested contents. This results in the situation where: once the requested presence contents by Watcher have not been allowed by the Presence Authorization Rule, those contents keep persistently blocked to be delivered to the Watcher until the Presentity somehow voluntarily revises the Presence Content Rule of Presence Authorization Rule in Presence XDMS to allow the blocked contents to the Watcher. B) In the current mechanism, there's no way for Presentity to specify the conditions when the Presence Server to request to Presentity for the Reactive Presence Authorization. C) In the current mechanism, the Reactive Presence Authorization can be achieved only by revising the persistent static rule of "Presence Authorization Rule" in Presence XDMS. So, it is not possible for Presentity to perform one-time authorization which is valid only for the Watcher's active subscription duration, without affecting the static "Presence Authorization Rule" in Presence XDMS. D) In the current mechanism, the Reactive Presence Authorization can be achieved only by indirect manner, i.e., there's no way for Presence Server to directly request the Presentity for the Reactive Presence Authorization on Watcher's request, without using the "presence.winfo" event notification, to get the on-the-fly Reactive Presence Authorization from the Presentity. This invention proposes the system and method that can tackle the above limitations of the current presence authorization mechanism. SUMMARY OF THE INVENTION In the purpose to cope with the above limitations of the existing arts, this invention proposes new systems and methods for the "Content-level Reactive Presence Authorization" wherein the Presentity would be able to reactively authorize the Watcher requested contents of the Presentity's Presence Information. For this Content-level Reactive Presence Authorization, this invention proposes new systems and methods where the Presence Server is able to convey to the Presentity on the states of the Watcher's requested contents of the Presence Information. Also, this invention proposes the systems and methods where the Presentity can specify the conditions when the Presence Server to trigger such Content-level Reactive Presence Authorization. Further, this invention proposes the systems and methods where the Presentity can achieve "Dynamic Reactive Presence Authorization" without the need to modify the static Presence Authorization Rule in Presence XDMS, but by directly delivering the reactive authorization to the Presence Server. Also, this invention proposes the systems and methods where the Presence Server can directly request the Presentity for the Reactive Presence Authorization without the help of "presence.winfo" event package, so that the Presence Server can get the instant response from the Presentity on the Reactive Presence Authorization. Accordingly the invention explains a method for content level reactive authorization comprising the steps of: the presentity modifying the Presence Authorization Rules document present in the Presence XDM server to include information that requires authorization, when requested by a watcher; informing the identity of the watcher and the protected content to the presentity by extending the format of watcher information to include information about the protected content requested by the watcher; and the presentity performing XCAP operations to authorize the watchers and the content, after knowing the details of the watchers and the content they have requested. Accordingly the invention explains a system for content level reactive authorization comprising: the presentity modifying the Presence Authorization Rules document present in the Presence XDM server to include information that requires authorization, when requested by a watcher; and means for informing the identity of the watcher and the protected content to the presentity by extending the format of watcher information to include information about the protected content requested by the watcher; and where the presentity performs XCAP operations to authorize the watchers and the content, after knowing the details of the watchers and the content they have requested. BRIEF DESCRIPTION OF ACCOMPANYING FIGURES Figure 1 depicts presence information example flows for reactive presence authorisation per the existing methods. Figure 2 depicts the overall logical flow for content level reactive authorization as proposed by this invention. Figure 3 depicts conveying the identity of the watchers and the protected contents to Presentity using the method "extending the format of watcher information. Figure 4 depicts conveying the identity of the Watchers and the protected contents using the "presence.winfo.content" event package. Figure 5 depicts Presentity's issuing PUBLISH request on "presauth" event package to deliver the volatile Presence Authorization Rule to Presence Server. Figure 6 depicts Presence Server pushing DETAILED DESCRIPTION The main object of the present invention is to enable the Presentities to protect the contents of the PUBLISHed Presence Information in more delicate manner. For this purpose, this invention proposes the systems and methods for the "Content-level Reactive Presence Authorization", wherein the Presentity would be able to reactively authorize the Watcher requested contents of the Presentity's Presence Information. Referring to Figure 2 it shows the overall logical flows involved in the content level reactive authorisation as proposed by this invention and the steps are described as below. Note: For the sake of brevity SIP/IP core is not shown in the figure 2. 1. Watcher subscribes to the Presence Information of Presentity. Watcher can specifically request for the interested Presence Information by including the "application/simple-filter+xml" in the body of the SIP SUBSCRIBE request. 2. Presence Server on receiving the SIP SUBSCRIBE request applies the Presence Authorisation rules corresponding to the Watcher. 4. If the Presence Server founds any of the presence contents requested by the Watcher is not allowed per the Presence Authorization rule, Presence Server marks those as "protected content" and then delivers those protected contents to the Presentity. 5. The Presentity receives the details of the Protected contents requested by the Watcher. 6. If the Presentity is willing to deliver those protected contents to the Watcher, it updates its Presence Authorization to allow those protected contents, for the watcher. This can be done by modifiing the Presence Authorisation rules stored in the Presence XDMS or by directly ordering the Presence Server as such. 7. The Presence Server can learn the changes made to the Presence Authorisation. 8. If the Watcher has been authorised for any of the protected contents the Presence Server sends those protected Presence Information to the Watcher. This invention proposes tha the Content-level Reactive Presence Authorization can be achieved in the following two ways: 1. Static Mechanism 2. Dynamic Mechanism 1. Static Mechanism- In this method the Presentity has to modify the Presence Authorization Rules document to include the information about which part of the PUBLISHed Presence Information is private that requires Reactive Presence Authorization and to what Watchers. The changes are static i.e. the modification gets stored in the Presence XDM and persistent across the Sessions. In this method the Presentity, after knowing the details of watchers and the content they have requested, has to do XCAP operation to modify the Presence Authorization Rule in Presence XDMS to authorize the watchers and the requested contents. In order to achieve this Content-level Reactive Presence Authorization by the static manner, the following mechanisms are required: i. Presentity specifying the conditions for Presence Server to trigger the Content- level Reactive Presence Authorization for protected contents; ii. Conveying the identity of the Watchers and the protected contents to Presentity; iii. Presentity performing the Content-level Reactive Presence Authorization by modifying Presence Authorization Rule. However, it should be noted that This invention does not mandate that the Presence Server should perform reactive content authorisation only if the Presentity specified for it to happen as described in the above step i). The Presence Server can by default perform Reactive Presence Content Authorisation even if the Presentity has not specified the conditions for Reactive Presence Content Authorisation. 1.1 Presentity specifying the conditions for Presence Server to trigger the Reactive Presence Authorization for protected contents Approach 1 This invention proposes to extend the existing Presence Authorization Rule document such that Presentity can also specify the conditions for Presence Server to trigger the Content-level Reactive Presence Authorization on the protected contents in case there are some Watchers who has requested those. In order for this, this invention proposes to extend the "actions" element in Presence Authorization Rule to contain the "protected-content-handling" element ,the value of which specifies what the Presence Server need to do when the Watcher has requested the protected contents, i.e., when the Watcher requested more contents than allowed in . For backward compatibility, the default value should be "ignore", where those request on protected contents will be ignored and not be delivered to Watcher. Other value could be. "confirm" that initiates Reactive Presence Authorization to the Presentity as proposed by this invention. The following Presence Authorization Rule document as shown in Table 2 specifies the Presentity's predefined permissions on the Presentity's Presence Information requests by the Watcher "sip:[email protected]". Per this invention, this Presence Authorization Rule is extended to contain the conditions for the Content-level Reactive Presence Authorization by the "protected-content- handling" action element with its value set as "confirm". Table 2. Example Presence Authorization Rule with the conditions to trigger the Content-level Reactive Presence Authorization - Approach 1. The following Table 3 is the schema definition for the extension to Presence Authorization Rule for the conditions for the Content-level Reactive Presence Authorization as described in this section. Table 3. Schema definition for element to specify the conditions to trigger the Content-level Reactive Presence Authorization - Approach 1. Approach 2 Alternatively, as showed in the following example below, the Presentity can specify the content information that always needs Content-level Reactive Presence Authorization. E.g., for the request for location information related Presence Information, Presentity always wants to authorize it reactively. This rule cannot occur with the above Approach 1), and will be described per presence attributes. So, in this approach, other requests for the protected contents will be ignored as it has been.The following Table 4 is an example of this rule. Note the changes in condition and action. So, in this case, only the request for "geopriv" presence attributes per RFC 4119 will be asked to Presentity for the Content-level Reactive Presence Authorization, while the requests for all other protected contents being ignored. Table 4. Example Presence Authorization Rule with the conditions to trigger the Content-level Reactive Presence Authorization - Approach 2. The following Table 5 is the schema definition for the above extension to Presence Authorization Rule per Approach2. Note that only the "handling-geopriv" element for the handling on the requests for 'geopriv' presence attributes is defined in the following. The elements for other presence attributes can be defined in similar way: Table 5. Schema definition for element to specify the conditions to trigger the Content-level Reactive Presence Authorization - Approach 2. 1.2 Conveying the identity of the Watchers and the protected contents to Presentity In order to achieve the Content-level Reactive Presence Authorization the Presentity should know the identity of the Watchers who are requesting for protected part of Presence Information and what part of protected content they are interested in. Currently the Presentity can be aware of Watchers who are interested in his/her Presence Information by subscribing to Watcher information event package (RFC 3857, "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)") but what content they are interested remains unknown to the Presentity. This invention requires the Presentity to know what part of the protected Presence Information the Watcher is interested in. This can be achieved in the following ways: Extending the format of Watcher Information (RFC 3858) to include the information about the protected contents of the Presence Information that the Watcher is interested in; Creation of new Event Package, e.g., named "presence.winfo.content" to convey the information about the protected contents of the Presence Information that the Watcher is interested in. 1.2.1 Extending the format of Watcher Information Currently the Presentity can learn about the list of Watchers who have subscribed for his/her Presence Information by subscribing to the "presence.winfo" event package (RFC 3858). But with this mechanism the Presentity cannot know what content is requested by the Watchers. In order to achieve the Content-level Reactive Presence Authorization there is a need that Presentity must be aware of what content is requested by which Watcher. It becomes very difficult to convey all the contents that are requested by the Watcher. Instead it is enough if the Presentity knows about the Watchers who have requested to view the part of Presence Information which is marked protected by the Presentity in the Presence Authorization policy document in Presence XDMS. In order to convey this kind of information to Presentity, this invention proposes to extend the schema defined for Watcher Information Format (RFC 3858) to include the details of the protected Presence Information if any, requested by any Watcher. There can be two approaches to extend the upresence.winfo" event package as described in the following. Approach 1 In this approach the root element "watcherinfo" of the Watcher information document as described in RFC 3858 is extended to contain "watcher-contents- list" element which carries the details of the contents requested by each Watchers and their identity, "watcher-contents-list" element contains "ns- bindings" element to specify the namespace bindings for the Presence Information, "ns-bindings" element contains any number of "ns-binding" elements. The format of "ns-bindings" and "ns-binding" elements are similar to the format as described in RFC 4661. "watcher-contents-list" element contains any number of "watcher-contents" elements to carry the details of Watchers and the Presence Information they have requested. The "watcher-contents" element must have an attribute named "watcher" whose value is URI of the Watcher and also this element contains any number of "content" elements and each "element carries the details and the state of the part of the Presence Information which the Watcher has requested. There are two attributes associated with the "content" element, both of which must be present: Status: The status of the authorization for the content described by "content" element whose value could be "pending". Type: Its value should be "xpath" to tell that the value of the "content" element is an XML element. The following Table 6 is an example of Watcher information extension for a Presentity sip:[email protected] which uses the format described as above in Approachl There are two watchers, userA and userB, whose URI is "sip:[email protected]" and "sip:[email protected]", respectively. The Watchers have requested to view the Presentities mood, activities and place-type information and the same are marked as private by the Presentity for the Watchers userA and userB. The Presentity comes to know about this through the NOTIFY request on the "presence.winfo" Watcher information event as extended by the above approach I. If the Presentity is willing to authorize the Presentity will XCAP operation to modify the Presence Authorization document to allow to Watchers those contents that they have requested. Table 6. Example Watcher Information extension - Approach 1 The following Table 7 is the schema definition for the extension part of Watcher information described in Approach 1: Table 7. Schema for Watcher Information extension - Approach 1 Approach 2 This approach purposes to reuse the approach used in Presence Authorization Rule per draft-ietf-simple-presence-rules to express the requested content, where the presence attributes are expressed like , etc. Here in this approach the root element "watcherinfo" of the Watcher information document as described in RFC 3858 is extended to contain "watcher-contents-list" element which carries the details of the contents requested by each Watchers and their identity, "watcher-contents-list" element contains any number of "watcher-contents" elements to carry the details of Watchers and the part of the Presence Information they have requested. The "watcher-contents" element must have an attribute named "watcher" whose value j is URI of the Watcher. The "watcher-contents" element can have presence information data format elements as described in the draft-ietf-simple-presence- rules. As the requested contents have been represented in the unit of presence information data format which is the same way that the Presence Content Rule in Presence Authorization Rule uses to express the allowed contents in element, the Presentity would be able to easily update the Presence Content Rule per the Approach 2. The following Table 8 is an example of Watcher information extension for a Presentity sip:[email protected] which per the above Approach 2. This example contains the same Watcher information as the example in Table 6, but is coded per the above Approach 2. Table 8. Example Watcher Information extension - Approach 2 The following Table 9 is the schema definition for the format of Watcher information extension described in Approach 2. Table 9. Schema for Watcher Information extension - Approach 2 The Figure 3 shows the example flow to convey the identity of the Watchers and the protected contents to Presentity by utilizing Watcher Information extension as proposed in this section. The following describes each step in Figure 3: 1. The Presentity wishing to know the list of Watchers who are subscribed for his/her Presence Information and to know the contents they have requested for sends a SIP SUBSCRIBE request to SIP/IP core subscribing for the extended "presence.winfo" event package per this invention. 2. The SIP/IP core forwards the request to the Presence Server of Presentity's domain. 3. The Presence Server processes the received SIP SUBSCRIBE and upon successful processing sends 200 OK responses to SIP/IP Core. 4. The SIP/IP core forwards the 200 OK responses to the Presentity. 5. Presence Server sends the SIP NOTIFY request containing the details of the Watchers who are subscribed for Presentity's Presence Information and what contents they have requested as proposed by this invention. The format of the contents sent in SIP NOTIFY request can be either formats as described in the two approaches of section 1.2.1 6. SIP/IP Core forwards the SIP NOTIFY request to the Presentity. 7. Presentity sends 200 OK responses. 8. SIP/IP Core forwards the 200 OK response to the Presence Server, 1.2.2 Creation of new event package to convey the identity of the Watchers and the protected contents to Presentity 1. RFC 3265 defines a generic framework for subscription to and notifications of events related to SIP systems. As an alternate method to 1.2.1, this invention defines a new event package to convey the details of Watchers and the protected content they have requested. The name of the new package is "presence.winfo.content". The functionality of the framework is similar to the one described in RFC 3265 and the NOTIFY message carries the XML document which contains the details of the Watchers and the protected contents they requested. 2. The format of the XML content is same as the one described in the previous section 1.2.1 as the extension to the Watcher Information format. The extension part to the existing Watcher information document which is described in the two approaches of the section 1.2.1 is re-used here and they act as an independent format. 3. The following Table 10 is the example SIP SUBSCRIBE request on "presence.winfo.content" event package. Here, the Presentity "sip:[email protected]" subscribes to his own "presence.winfo.content" event. Table 10. Example SUBSCRIBE request on "presence.winfo.content" event package. As response to the above example SUBSCRIBE request in Table 10, The following Table 11 is the example SIP NOTIFY request on "presence.winfo.content" event package to the Presentity "sip:[email protected]", with the details of the content requested by the Watchers and their identity being embedded as the content of this NOTIFY request. The content reuses the same format as described in the Approach 1 in the section 1.2.1. The content type for this information is "application/watcherinfo- content+xml". With this information, the Presentity "sip:[email protected]" can learn about the following information: • The Watcher "sip:[email protected]" has requested the Presence Information of the Presentity. Among the requested parts of the Presence Information, the requests for "activities", "mood", "place-type" presence attributes have not been allowed per the presence Presentity's Presence Content Rule in Presence XDMS. • The Watcher "sip: [email protected]" has requested the Presence Information of the Presentity. Among the requested parts of the Presence Information, the request for the "location- info" presence attribute? has not been allowed per the present Presentity's Presence Content Rule in Presence XDMS. Based on this information, the Presentity may want to modify his present Presence Content Rule in Presence XDMS to selectively allow the requested contents to the Watchers. Table 11. Example NOTIFY request on "presence.winfo.content" event package with the contents per the Approach 1 in section 1.2.1. As response to the above example SUBSCRIBE request in Table 10, the following fable 12 shows the example SIP NOTIFY request on "presence.winfo.content" event package to the Presentity "sip:[email protected]" with the contents per the Approach 2 in section 1.2.1. The content delivers the same information as the above Table 11, but reuses the format as described in the Approach 2 in the section 1.2.1. Table 12. Example NOTIFY request on "presence.winfo.content" event package with the contents per the Approach 2 in section 1.2.1. The Figure 4 shows the example flow to convey the identity of the Watchers and the protected contents to Presentity by using the new event package of "presence.winfo.content" as proposed in this section. Following are steps involved in Figure 4. 1. The Presentity wishing to know the details of the contents requested by the Watchers who are subscribed for his/her Presence Information sends a SIP SUBSCRIBE request to SIP/IP core subscribing for "presence.winfo.content" event package per this invention. 2. The SIP/IP core forwards the request to the Presence Server of Presentity's domain. 3. The Presence Server processes the received SIP SUBSCRIBE and upon successful processing sends 200 OK responses to SIP/IP Core. 4. The SIP/IP core forwards the 200 OK responses to the Presentity. 5. Presence Server sends the SIP NOTIFY request containing the details of the Watchers who are subscribed for Presentity's Presence Information and what content they have requested as proposed by this invention. The format of the content sent in SIP NOTIFY request can be either of format described in the two approaches of section 1.2.2 6. SIP/IP Core forwards the SIP NOTIFY request to the Presentity. 7. Presentity sends 200 OK responses. 8. SIP/IP Core forwards the 200 OK response to the Presence Server, 1.2.3 Using multipart/mixed content type to convey the protected contents requested by Watchers This approach proposes to use the "multipart/mixed" content type as described in [RFC2387] inorder to aggregate the Watcher Information and the protected contents requested by the watchers. In this format the root document contains the watcher information document as described in RFC 3858 and the remaining part contains the details of the protected contents requested by each watchers. The remaining part of the "multipart/mixed" content types contains the details of the protected content by each of the watcher. The format of this document could be any of the following: 1. Format explained in Approach 1 of the section 1.2.1 of this document [see Table 7] 2. Format explained in Approach 2 of the section 1.2.1 of this document [see Table 9] 3. Event Notification Filtering document as described in RFC 4661 with the extensions explained in section 1.2.3.1 of this document. 1.2.3.1 Re-using Event Notification Filter document This invention proposes to re-use the Event Notification Filtering document for conveying the details of the protected contents requested by the watchers to the Presentity with the clarifications as descibed below. Clarifications: The Presence Server of the Presentity domain figures out the protected contents if any, requested by the watchers, by applying the corresponsing presence authorisation rules and also the Event notification filter requested by the watcher. If a particular watcher has requested for any protected contents of the presentity the Presence Server constructs the Filter document using the element and sets the "uri" attribute of the element to the URI of the watcher. Presence of any other attributes other than "uri" should be ignored by the presentity. Usage of and elements are discouraged. This way the Presence Server constructs filter document for all the watchers who have requested for the protected contents and aggregate all the information as "multipart/mixed" content type arid send in the notification of watcher information subscription. If not the "uri" attribute, the element could be extended with any other new attribute to carry the identity of the watcher. The PS can make sure that it conveys all the namespace bindings to the Presentity when it aggregates the filters from all the watchers. Table 13 shows an example NOTIFY containing the multipart/mixed content type wherein one part contains the watcher information and the other part contains the filter document which is aggregation of protected content requested by the watchers. ' w 1 Table 13: Example for conveying the protected contents requested by watchers to the Presentity using "multipart/mixed" content type. 1.2.4 Using Content Indirection Mechanism These inventions propose one another mechanism for conveying the details of protected contents requested by the watchers and their identities to the presentity by making use of content indirection mechanism as explained in RFC4483. In order to achieve the content indirection, this invention proposes that the Presence Server stores the status of the protected contents within it or some other place like content server in the format of separate MIME as described in the above section 1.2.2 and 1.2.3, then delivers the URI of the stored information to the presentity by extending the content of the Watcher Information notification as following: Either the or the element of the Watcher Information format (RFC 3858) can be extended to contain a new element or a new attribute to carry the uri of the indirected content. The presentity on receiving the uri of the indirected content and it can retrieve the status of the protected contents to perform the reactive authorization on those.Table 14 shows an example of using content indirection mechanism to convey the status of Table 14: Conveying protected content status using content indirection 1.2.5 Watcher Preferences for Receiving Notifications According to RFC 4661, Watcher use the filter element to trigger the content delivery when the presence element it identifies has been added to the presence information document being filtered. This invention further proposes to utilize the filter element for reactive content authorization such that the presence element specified in the filter element indicates the watcher's explicit request to receive the specified element. Therefore, the Presence Server on receiving the filter with element in it can interpret it in the following way: a) .lf the Presence Information elements listed in the element are already authorised to the Watcher it can include those elements as a part of the initial NOTIFY and send it to watcher. b) . If the Presence Information elements listed in the element are not authorised to the Watcher it can include only those elements as a part of the protected contents which would be sent to the Presentity for reactive authorisation.In this case the Presence Server can withhold the initial NOTIFY request for a specific period of time which allows some time for the Presentity to modify the Presence Authorisation rules to allow the specified content for the watcher. If no authorisation happens within a specific period of time the Presence Server sends the initial NOTIFY request with the presence contents as allowed to the Watcher. Table 15 shows an example of the Event Notification Filter Document which carries the Watcher Preferences of receiving Notifications using element. -a- Table 15: Watcher Preferences of Receiving Notifications by using element 1.3 Presentity performing Reactive Presence Authorization by modifying Presence Authorization Rule in Presence XDMS Upon receiving the above information on the Watcher's requests for the protected content of the Presence Information per the mechanisms described in the above section 1.1 and 1.2, Presentity may elect to perform the Content-level Reactive Presence Authorization to selectively authorize the Watcher's requests on the protected contents of the Presentity's Presence information. The Presentity can achieve this Content-level Reactive Presence Authorization by modifying as such, the Presence Content Rule in the Presentity's Presence Authorization Rule in Presence XDMS, using the XCAP operations. Then, these changes in Presence Content Rule in the Presence Authorization Rule will be notified to Presence Server, and then the Presence Server applies this updated Presence Content Rule to authorize the Watcher's requests on the protected contents of the Presentity's Presence Information and deliver those to the requesting Watcher. 2. Dynamic Mechanism In the previous section 1 this invention discussed about "Static Mechanism" for achieving the Content-level Reactive Presence Authorization. This invention further proposes another dimension to achieve Content-level Reactive Presence Authorization in dynamic manner, which is called "Dynamic Mechanism" or "Direct Mechanism". The "Static Mechanism" in section 1 requires the Presentity to update the static Presence Authorization Rule in Presence XDMS to perform the Content-level Reactive Presence Authorization. As such, the Content-level Reactive Presence Authorization per the "Static Mechanism" in section 1 exists persistently and continues to be applied to the future requests from the Watchers. Compared to the "Static Mechanism"-, this "Dynamic Mechanism" does not require any modification to the existing Presence Authorization Rule document to perform the Content-level Reactive Presence Authorization, but with the "Dynamic Mechanism" the Presentity sends the Content-level Reactive Presence Authorization directly to the Presence Server. As such, the Content-level Reactive Presence Authorization using the "Dynamic Mechanism" does hold only for the Watcher's pending or active subscription duration. Further, this invention proposes that this "Dynamic Mechanism" for the Content- level Reactive Presence Authorization can also be applied for the Reactive Presence Authorization of subscription as well as that of contents. In other words, this "Dynamic Mechanism" for Reactive Presence Authorization can be applied for both Subscription Authorization Rule and Content Authorization Rule. (Note that the Presence Authorization Rule consists of Subscription Authorization Rule and Content Authorization Rule.) As such, this invention calls the "Dynamic Mechanism" as the "Dynamic Reactive Presence Authorization". With the Dynamic Reactive Presence Authorization, this invention proposes that the Presence Authorization Rule in Presence Server that the Presence Server uses to authorize the presence requests from Watchers is the composite view of the following two parts of the Presence Authorization Rule: • Static Presence Authorization Rule that is based on the Presence Authorization Rule document in Presence XDMS; • Volatile Presence Authorization Rule set directly by the Presentity. As mentioned above, the volatile part of the Presence Authorization Rule in Presence Server holds during Watcher's pending or active subscription duration. So, the same Presence Authorization Rule in Presence Server will be applied for re-SUBSCRIBE request. Also, the same Presence Authorization Rule in Presence Server will be applied for every SIP NOTIFY to the Watcher. But, it should be noted that, upon termination of the Watcher's current active subscription, the volatile part of Presence Authorization Rule in Presence Server will disappear. To achieve the Dynamic Reactive Presence Authorization this invention proposes the following steps: 1. Presentity specrfing the conditions for Presence Server to trigger the Reactive Presence Authorization for protected contents. This can be achieved per the mechanisms proposed in section 1.1; 2. Conveying the identity of the Watchers and the protected contents to Presentity. This can be achieved per the mechanisms proposed in section 1.2; 3. Presentity performing Reactive Presence Authorization by sending the authorization directly to Presence Server. Alternatively, this invention proposes that Presence Server directly asks Presentity for Reactive Presence Authorization, then Presentity responses directly to the Presence Server with the Reactive Presence Authorization. 2.1 Presentity performing Reactive Presence Authorization directly to Presence Server As described in the above section 1. this invention proposes that Presence Server have the composite view of Presence Authorization Rule by composing the static Presence Authorization Rule from Presence XDMS and the volatile Presence Authorization Rule that comes directly from Presentity. This invention proposes to denote the volatile Presence Authorization Rule as the new event package called "presauth". Upon the information on the Watcher's requests for the Presentity's Presence Information, the Presentity may elect to authorize the Watcher's request just for one time rather than in persistent manner. This invention proposes that the Presentity that wants such volatile Presence Authorization issue the PUBLISH request for the "presauth" event package to Presence Server. The body of such PUBLISH requests carries the "volatile" Presence Authorization Rule. The content type for this body can be "application/presauth+xml". Upon receiving this PUBLISH request on "presauth" event package with Presence Authorization Rule from Presentity, the Presence Server will compose this "volatile" Presence Authorization Rule with the static Presence Authorization Rule from Presence XDMS. When composing, the "volatile" rule will take precedence over the "static" rule in case that those rules collide. For easy composition with static Presence Authorization Rule, the content of "dynamic" Presence Authorization Rule can have the same format as the static Presence Authorization Rule. The Presence Server can wait for some specific period of time to receive the dynamic authorisation rule. If no rule is received from the Presentity within the specified time the Presence Server can apply the static authorisation rule. As this is a new event package, Presentity can also use SIP event SUBCRIBE/NOTIFY (RFC 3857) to get synchronized with the "volatile" Presence Authorization Rule in Presence Server. The following Table 16 shows the example PUBLISH requests on the "presauth" event package with the body containing the "volatile" Presence Authorization Rule as proposed by this invention, which Presentity of "sip:[email protected]" sends to Presence Server. V Table 16. Example PUBLISH request on "presauth" event package with the volatile Presence Authorization Ruje in the body. The following Figure 5 shows the example flows where Presentity issues PUBLISH request on "presauth" event package to deliver the volatile Presence Authorization Rule to Presence Server. Following steps describe the steps in Figure 5: 1. The Presentity in order to get to know the details of the Watchers' requests for presence subscription and the contents of the Presentity's Presence Information they have requested would send SIP SUBSCRIBE subscribing for "presence.winfo" event package with extensions proposed in this invention (section 1.2.1) or for "presence.winfo.content" event package as described in the section 1.2.2. 2. Watcher sends SIP SUBSCRIBE to subscribe for the Presence Information of the Presentity. But, this Watcher is not yet authorized by Presentity based on the static Presence Authorization Rule in Presence XDMS. 3. The Presence Server sends a SIP NOTIFY request on either "presence.winfo" event package with extensions by this invention or "presence.winfo.content" event package. This SIP NOTIFY request carries the details of the Watcher lists and their requests for the protected contents as proposed by this invention. 4. Presentity wishing to authorize the Watcher just for one time rather than persistently sends the SIP PUBLISH request on "presauth" event package to Presence Server with its body containing the volatile Presence Authorization Rule as proposed by this invention. 5. The Presence Server sends SIP NOTIFY request to the Watcher which contains the valid Presence Information which he/she is reactively authorized to view. 2.2 Presence Server directly asking Presentity for Reactive Presence Authorization This invention further proposes an alternative method for the Presentity getting to know the details of the Watchers' requests for presence subscriptions and the protected contents they have requested, wherein: Presence Server directly delivers the status of Watchers' requests, asking for Presentity to perform the Reactive Presence Authorization. In the previous methods the Presentity have to subscribe for the information on Watcher requested contents by using the methods described in the section 1.2 of this document. But here in this alternative method there is no need for the Presentity to do subscribe for Watcher content information; instead, the Presence Server directly pushes the information to the Presentity, directly asking for Presentity's Reactive Presence Authorization. For this method, this invention proposes to utilize the SIP MESSAGE or other appropriate SIP methods. The content type of the SIP MESSAGE could be "application/reactive-auth+xml" and the format of the document carried in the SIP MESSAGE would be similar to the format describe in the section 1.2 of this document. Upon receiving this information from Presence Server, Presentity can respond to the Presence Server with the Reactive Presence Authorization as previously described methods in this invention. Other steps like specifying the conditions for Presence Server to trigger the Reactive Presence Authorization for protected contents and Presentity performing Reactive Presence Authorization directly to Presence Server remains the same for this alternative method. The Presence Server can wait for some specific period of time to receive the dynamic authorisation rule. If no rule is received from the Presentity within the specified time the Presence Server can apply the static authorisation rule. The following Figure 6 shows the example flows of this alternate methods. Compared to the above Figure 5, the only difference is that: instead of using the "presence.winfo" or "presence.winfo.content" event package, the Presence Server pushes the information on the Watcher's requests for subscription and the protected contents of the Presentity's Presence Information using the SIP MESSAGE method with this information in the body.

Full Text

We Claim:
1. A method for content level reactive authorization comprising the steps of:
the presentity modifying the Presence Authorization Rules document present in the Presence XDM server to include information that requires authorization, when requested by a watcher;
informing the identity of the watcher and the protected content to the presentity by extending the format of watcher information to include information about the protected content requested by the watcher;
the presentity performing XCAP operations to authorize the watchers and the content, after knowing the details of the watchers and the content they have requested.
2. The method as claimed in claim 1 wherein a watcher element tag is extended to contain any number of 'requested-content' element tags.
3. The method as claimed in claim 2 wherein the requested-content element tags include element tags from the presence information which are marked as protected by the presentity.
4. The method as claimed in claim 1 further comprising the steps of creating an event package to inform the presentity about the identity of the watchers and the protected content.
5. A method for content level reactive authorization utilizing a dynamic mechanism, where, the presentity, while publishing the presence information, publishes details of the content that require reactive authorization and the identity of the watchers who have requested for the content.
6. A system for content level reactive authorization comprising:
the presentity modifying the Presence Authorization Rules document present in the Presence XDM server to include information that requires authorization, when requested by a watcher; and
means for informing the identity of the watcher and the protected content to the presentity by extending the format of watcher information to include information about the protected content requested by the watcher;
where the presentity performs XCAP operations to authorize the watchers and the content, after knowing the details of the watchers and the content they have requested.
7. The system as claimed in claim 6 wherein a watcher element tag is extended to contain any number of 'requested-content' element tags.
8. The system as claimed in claim 7 wherein the requested-content element tags include element tags from the presence information which are marked as protected by the presentity.
9. The system as claimed in claim 1 further comprises an event package created to inform the presentity about the identity of the watchers and the protected content.
10. A system for content level reactive authorization utilizing a dynamic mechanism, where the presentity, while publishing the presence information, publishes details of the content that require reactive authorization and the identity of the watchers who have requested for the content.
11. A method for content level reactive authorization substantially described particularly with reference to the accompanying drawings.
12. A system for content level reactive authorization substantially described particularly with reference to the accompanying drawings.

FIELD OF THE INVENTION
The present invention, in general, relates to the field of SIP based presence applications as defined by the OMA specifications. The invention proposes reactive authorization based on content requested by a watcher. More particularly the present invention relates to method and system for content level reactive authorization.
DESCRIPTION OF RELATED ART
In the currently existing mechanism, by using the Presence Authorization Policies the Presentity can tell the Presence Server who are authorized to watch his/ her Presence Information and, if authorized to watch, what part of his/her Presence Information they can see. Such Presentity's Presence Authorization Policies are represented as Presence Authorization Rule XML document and stored in Presence XML Document Management Server (XDMS). The Presence Authorization Rule consists of two parts; Subscription Authorization Rule that determines who is authorized to subscribe to the Presentity's Presence Information, and Presence Content Rule that determines which contents of the Presentity's Presence Information are authorized to be delivered to the subscribing Watcher.
The following Table 1 shows the example of the Presence Authorization Rule. In this example, the rule specifies that the user with the URI of either "tel:+43012345678" or "sip:[email protected]" is allowed to subscribe the Presentity's Presence Information, and the subscribed user with the URI of either "tel:+43012345678" or "sip:[email protected]" is allowed to be provided with the 'PoC' service, 'willingness', and 'status-icon' related presence attributes.
I
Table 1. Example Presence Authorization Rule document
When a Presence Server receives a SUBSCRIBE request on a Presentity's Presence Information from a Watcher, the Presence Server fetches the Presentity's Presence Authorization Rules from Presence XDMS, and uses it to authorize the Watcher with regards to subscription request and the parts of Presence Information to be delivered. The Presence Server keeps synchronized with the Presence XDMS by "xcap-diff event package subscription such that the changes in the Presentity's Presence Authorization Rules could be instantly reflected in the Presence Server's handling of the Presence Information requests and delivery. This is called as Proactive Presence Authohzation as the Presence Server can perform authorization for itself based on the predescribed static rules (i.e., Presence Authorization Rules in Presence XDMS) and without the need of direct interaction with Presentity.
Also, the Reactive Presence Authorization, where the Presence Server authorizes the Watcher's subscription requests to the Presentity's Presence Information per the Presentity's reaction on those, can be achieved by the following procedure: Firstly, the Presentity needs to subscribe for "presence, winfo" event package to Presence Server. Upon this event subscription, the Presence Server notifies the Presentity of the current status of Watcher lists and their corresponding subscription states. With this information, the Presentity can identify which Watcher is 'pending' subscription state and, if the Presentity wants to allow the Watcher to see his Presence Information, the Presentity revises the Presence Authorization Rule in Presence XDMS as such. Such modifications of the rules are notified to the Presence Server and then the Presence Server applies those updated Presence Authorization Rules to handle the 'pending' subscription requests from the Watchers. The example flows of how the current reactive Presence Authorization mechanism works are shown in Figure 1 and the steps involved are discussed in the followings.
The following describes each step in the Figure 1:
Note: Presence Server subscribing for changes to Presence Authorization Rule documents stored in Presence XDMS is omitted from the above Figure 1 for simplicity.
1. The Presentity wishing to know the list of watchers who are subscribed for his/her Presence Information sends a SIP SUBSCRIBE request to SIP/IP core subscribing for "presence.winfo" event package.
2. The SIP/IP core forwards the request to the Presence Server of Presentity's domain.
3. The Presence Server processes the received SIP SUBSCRIBE and upon successful processing sends 200 OK responses to SIP/IP Core.
4. The SIP/IP core forwards the 200 OK responses to the Presentity.
5. The Presence Server sends SIP NOTIFY request containing the details of Watchers to the SIP/IP core.
6. The SIP/IP core forwards the SIP NOTIFY request to the Presentity.
7. The Presentity sends the 200 OK responses for the SIP NOTIFY request.
8. The SIP/IP core forwards the 200 OK responses to the Presence Server.
9. Watcher wishing to subscribe for Presence Information of the Presentity sends a SIP SUBSCRIBE request to the SIP/IP Core.
10. The SIP/IP Core forwards the SIP SUBSCRIBE to the Presence Server.
11. The Presence Server processes the received SIP SUBSCRIBE and finds out that the Watcher is not authorized to subscribe for Presentity's Presence Information and hence acknowledges the SIP SUBSCRIBE with "202 Accepted" responses.
12. The SIP/IP Core forwards the "202 Accepted" responses to the Watcher.
13. As soon as the PS sends a SIP 202 Accepted response to accept the subscription, it sends a SIP NOTIFY request as mandated by [RFC3265]. At this time, the Presence Information to be delivered to the Watcher may be not available yet as the Watcher has not yet been authorized to see the Presentity's Presence Information. As such, a "dummy" SIP NOTIFY request can be sent, with a valid neutral or empty Presence Information and a valid Subscription-State header field (set to "pending") for the time being.
14. The SIP/IP Core forwards the SIP NOTIFY request with the "dummy" Presence Information to the Watcher.
15. The Watcher sends 200 OK responses to the received SIP NOTIFY request.
16. The SIP/IP Core forwards 200 OK responses to the Presence Server.
17. The Presence Server sends a SIP NOTIFY request to the Presentity which contains the detailed lists of the Watchers who have subscribed for Presentity's Presence Information and the state of the subscription which is "pending" in this case.
18. The SIP/IP Core forwards the SIP NOTIFY request to the Presentity.
19. The Presentity acknowledges the SIP NOTIFY request with 200 OK responses.
20. The SIP/IP Core forwards the 200 OK responses to the Presence Server.
21. After getting to know the Watcher's identity who is 'pending' subscription state, the Presentity wishes to authorize the Watcher to view his/her Presence Information and hence the Presentity does the XCAP operations (RFC 4825, "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)") to change the Presence Authorization Rule document to authorize the Watcher.
Note: For brevity sake the details of XCAP operations and the details of Presence Server getting to know the changes in the Presence Authorization Rules in Presence XDMS are not shown.
22. The Presence Server authorizes the Watcher per the updated Presence Authorization Rule and issues another SIP NOTIFY containing the valid Presence Information which he/she is authorized to view per the updated Presence Authorization Rule.
23. The SIP/IP Core forwards the SIP NOTIFY to the Watcher.
24. The Watcher sends 200 OK responses for SIP NOTIFY request.
25. The SIP/IP Core forwards the 200 OK responses to the Presence Server.
LIMITATIONS
In the current mechanism, the base is the Proactive Presence Authorization mechanism based on the static rule named "Presence Authorization Rule" in Presence XDMS. The Reactive Presence Authorization can be achieved by the indirect way where the Presentity subscribes "presence.winfo" event package, identifies the pending subscription request from Watchers by getting notification, of "presence.winfo" event, updating the static rule of "Presence Authorization Rule" in Presence XDMS, then the Presence Server gets notified of such changes in the rules and applies it to the pending subscriptions.
With the current presence authorization mechanism, the following limitations are observed:
A) In the current mechanism, the above Reactive Presence Authorization applies only to the Watcher's subscription request, i.e., it is only about whether to allow a presence subscription request or not. In other words, the authorization for the requested contents of presence information is not possible. As such, there's no way to reactively authorize the Watcher's requested contents. This results in the situation where: once the requested presence contents by Watcher have not been allowed by the Presence Authorization Rule, those contents keep persistently blocked to be delivered to the Watcher until the Presentity somehow voluntarily revises the Presence Content Rule of Presence Authorization Rule in Presence XDMS to allow the blocked contents to the Watcher.
B) In the current mechanism, there's no way for Presentity to specify the conditions when the Presence Server to request to Presentity for the Reactive Presence Authorization.
C) In the current mechanism, the Reactive Presence Authorization can be achieved only by revising the persistent static rule of "Presence Authorization Rule" in Presence XDMS. So, it is not possible for Presentity to perform one-time
authorization which is valid only for the Watcher's active subscription duration, without affecting the static "Presence Authorization Rule" in Presence XDMS.
D) In the current mechanism, the Reactive Presence Authorization can be achieved only by indirect manner, i.e., there's no way for Presence Server to directly request the Presentity for the Reactive Presence Authorization on Watcher's request, without using the "presence.winfo" event notification, to get the on-the-fly Reactive Presence Authorization from the Presentity.
This invention proposes the system and method that can tackle the above limitations of the current presence authorization mechanism.
SUMMARY OF THE INVENTION
In the purpose to cope with the above limitations of the existing arts, this invention proposes new systems and methods for the "Content-level Reactive Presence Authorization" wherein the Presentity would be able to reactively authorize the Watcher requested contents of the Presentity's Presence Information. For this Content-level Reactive Presence Authorization, this invention proposes new systems and methods where the Presence Server is able to convey to the Presentity on the states of the Watcher's requested contents of the Presence Information. Also, this invention proposes the systems and methods where the Presentity can specify the conditions when the Presence Server to trigger such Content-level Reactive Presence Authorization.
Further, this invention proposes the systems and methods where the Presentity can achieve "Dynamic Reactive Presence Authorization" without the need to modify the static Presence Authorization Rule in Presence XDMS, but by directly delivering the reactive authorization to the Presence Server. Also, this invention proposes the systems and methods where the Presence Server can directly request the Presentity for the Reactive Presence Authorization without the help of "presence.winfo" event package, so that the Presence Server can get the instant response from the Presentity on the Reactive Presence Authorization.
Accordingly the invention explains a method for content level reactive authorization comprising the steps of:
the presentity modifying the Presence Authorization Rules document present in the Presence XDM server to include information that requires authorization, when requested by a watcher;
informing the identity of the watcher and the protected content to the presentity by extending the format of watcher information to include information about the protected content requested by the watcher; and
the presentity performing XCAP operations to authorize the watchers and the content, after knowing the details of the watchers and the content they have requested.
Accordingly the invention explains a system for content level reactive authorization comprising:
the presentity modifying the Presence Authorization Rules document present in the Presence XDM server to include information that requires authorization, when requested by a watcher; and
means for informing the identity of the watcher and the protected content to the presentity by extending the format of watcher information to include information about the protected content requested by the watcher; and
where the presentity performs XCAP operations to authorize the watchers and the content, after knowing the details of the watchers and the content they have requested.
BRIEF DESCRIPTION OF ACCOMPANYING FIGURES
Figure 1 depicts presence information example flows for reactive presence authorisation per the existing methods.
Figure 2 depicts the overall logical flow for content level reactive authorization as proposed by this invention.
Figure 3 depicts conveying the identity of the watchers and the protected contents to Presentity using the method "extending the format of watcher information.
Figure 4 depicts conveying the identity of the Watchers and the protected contents using the "presence.winfo.content" event package.
Figure 5 depicts Presentity's issuing PUBLISH request on "presauth" event package to deliver the volatile Presence Authorization Rule to Presence Server.
Figure 6 depicts Presence Server pushing
DETAILED DESCRIPTION
The main object of the present invention is to enable the Presentities to protect the contents of the PUBLISHed Presence Information in more delicate manner. For this purpose, this invention proposes the systems and methods for the "Content-level Reactive Presence Authorization", wherein the Presentity would be able to reactively authorize the Watcher requested contents of the Presentity's Presence Information.
Referring to Figure 2 it shows the overall logical flows involved in the content level reactive authorisation as proposed by this invention and the steps are described as below.
Note: For the sake of brevity SIP/IP core is not shown in the figure 2.
1. Watcher subscribes to the Presence Information of Presentity. Watcher can specifically request for the interested Presence Information by including the "application/simple-filter+xml" in the body of the SIP SUBSCRIBE request.
2. Presence Server on receiving the SIP SUBSCRIBE request applies the Presence Authorisation rules corresponding to the Watcher.
4. If the Presence Server founds any of the presence contents requested by the Watcher is not allowed per the Presence Authorization rule, Presence Server marks those as "protected content" and then delivers those protected contents to the Presentity.
5. The Presentity receives the details of the Protected contents requested by the Watcher.
6. If the Presentity is willing to deliver those protected contents to the Watcher, it updates its Presence Authorization to allow those protected contents, for the watcher. This can be done by modifiing the Presence Authorisation rules stored in the Presence XDMS or by directly ordering the Presence Server as such.
7. The Presence Server can learn the changes made to the Presence Authorisation.
8. If the Watcher has been authorised for any of the protected contents the Presence Server sends those protected Presence Information to the Watcher.
This invention proposes tha the Content-level Reactive Presence Authorization can be achieved in the following two ways:
1. Static Mechanism
2. Dynamic Mechanism
1. Static Mechanism- In this method the Presentity has to modify the Presence Authorization Rules document to include the information about which part of the PUBLISHed Presence Information is private that requires Reactive Presence Authorization and to what Watchers. The changes are static i.e. the modification gets stored in the Presence XDM and persistent across the Sessions. In this method the Presentity, after knowing the details of watchers and the content they have requested, has to do XCAP operation to modify the Presence Authorization Rule in Presence XDMS to authorize the watchers and the requested contents.
In order to achieve this Content-level Reactive Presence Authorization by the static manner, the following mechanisms are required:
i. Presentity specifying the conditions for Presence Server to trigger the Content- level Reactive Presence Authorization for protected contents;
ii. Conveying the identity of the Watchers and the protected contents to Presentity;
iii. Presentity performing the Content-level Reactive Presence Authorization by modifying Presence Authorization Rule.
However, it should be noted that This invention does not mandate that the Presence Server should perform reactive content authorisation only if the Presentity specified for it to happen as described in the above step i). The Presence Server can by default perform Reactive Presence Content Authorisation even if the Presentity has not specified the conditions for Reactive Presence Content Authorisation.
1.1 Presentity specifying the conditions for Presence Server to trigger the Reactive Presence Authorization for protected contents
Approach 1
This invention proposes to extend the existing Presence Authorization Rule document such that Presentity can also specify the conditions for Presence Server to trigger the Content-level Reactive Presence Authorization on the protected contents in case there are some Watchers who has requested those. In order for this, this invention proposes to extend the "actions" element in Presence Authorization Rule to contain the "protected-content-handling" element ,the value of which specifies what the Presence Server need to do when the Watcher has requested the protected contents, i.e., when the Watcher requested more contents than allowed in .
For backward compatibility, the default value should be "ignore", where those request on protected contents will be ignored and not be delivered to Watcher.
Other value could be. "confirm" that initiates Reactive Presence Authorization to the Presentity as proposed by this invention.
The following Presence Authorization Rule document as shown in Table 2 specifies the Presentity's predefined permissions on the Presentity's Presence Information requests by the Watcher "sip:[email protected]". Per this invention, this Presence Authorization Rule is extended to contain the conditions for the Content-level Reactive Presence Authorization by the "protected-content- handling" action element with its value set as "confirm".

Table 2. Example Presence Authorization Rule with the conditions to trigger the Content-level Reactive Presence Authorization - Approach 1.
The following Table 3 is the schema definition for the extension to Presence Authorization Rule for the conditions for the Content-level Reactive Presence Authorization as described in this section.

Table 3. Schema definition for element to specify the conditions to trigger the Content-level Reactive Presence Authorization - Approach 1.
Approach 2
Alternatively, as showed in the following example below, the Presentity can specify the content information that always needs Content-level Reactive Presence Authorization. E.g., for the request for location information related Presence Information, Presentity always wants to authorize it reactively. This rule cannot occur with the above Approach 1), and will be described per presence attributes. So, in this approach, other requests for the protected contents will be ignored as it has been.The following Table 4 is an example of this rule. Note the changes in condition and action. So, in this case, only the request for "geopriv" presence attributes per RFC 4119 will be asked to Presentity for the Content-level Reactive Presence Authorization, while the requests for all other protected contents being ignored.

Table 4. Example Presence Authorization Rule with the conditions to trigger the Content-level Reactive Presence Authorization - Approach 2.
The following Table 5 is the schema definition for the above extension to Presence Authorization Rule per Approach2. Note that only the "handling-geopriv" element for the handling on the requests for 'geopriv' presence attributes is defined in the following. The elements for other presence attributes can be defined in similar way:

Table 5. Schema definition for element to specify the conditions to trigger the Content-level Reactive Presence Authorization - Approach 2.
1.2 Conveying the identity of the Watchers and the protected contents to Presentity
In order to achieve the Content-level Reactive Presence Authorization the Presentity should know the identity of the Watchers who are requesting for protected part of Presence Information and what part of protected content they are interested in. Currently the Presentity can be aware of Watchers who are interested in his/her Presence Information by subscribing to Watcher information event package (RFC 3857, "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)") but what content they are interested
remains unknown to the Presentity. This invention requires the Presentity to know what part of the protected Presence Information the Watcher is interested in. This can be achieved in the following ways:
Extending the format of Watcher Information (RFC 3858) to include the information about the protected contents of the Presence Information that the Watcher is interested in;
Creation of new Event Package, e.g., named "presence.winfo.content" to convey the information about the protected contents of the Presence Information that the Watcher is interested in.
1.2.1 Extending the format of Watcher Information
Currently the Presentity can learn about the list of Watchers who have subscribed for his/her Presence Information by subscribing to the "presence.winfo" event package (RFC 3858). But with this mechanism the Presentity cannot know what content is requested by the Watchers. In order to achieve the Content-level Reactive Presence Authorization there is a need that Presentity must be aware of what content is requested by which Watcher.
It becomes very difficult to convey all the contents that are requested by the Watcher. Instead it is enough if the Presentity knows about the Watchers who have requested to view the part of Presence Information which is marked protected by the Presentity in the Presence Authorization policy document in Presence XDMS. In order to convey this kind of information to Presentity, this invention proposes to extend the schema defined for Watcher Information Format (RFC 3858) to include the details of the protected Presence Information if any, requested by any Watcher.
There can be two approaches to extend the upresence.winfo" event package as described in the following.
Approach 1
In this approach the root element "watcherinfo" of the Watcher information document as described in RFC 3858 is extended to contain "watcher-contents- list" element which carries the details of the contents requested by each Watchers and their identity, "watcher-contents-list" element contains "ns- bindings" element to specify the namespace bindings for the Presence Information, "ns-bindings" element contains any number of "ns-binding" elements. The format of "ns-bindings" and "ns-binding" elements are similar to the format as described in RFC 4661. "watcher-contents-list" element contains any number of "watcher-contents" elements to carry the details of Watchers and the Presence Information they have requested. The "watcher-contents" element must have an attribute named "watcher" whose value is URI of the Watcher and also this element contains any number of "content" elements and each "element carries the details and the state of the part of the Presence Information which the Watcher has requested. There are two attributes associated with the "content" element, both of which must be present:
Status: The status of the authorization for the content described by "content" element whose value could be "pending".
Type: Its value should be "xpath" to tell that the value of the "content" element is an XML element.
The following Table 6 is an example of Watcher information extension for a Presentity sip:[email protected] which uses the format described as above in Approachl There are two watchers, userA and userB, whose URI is "sip:[email protected]" and "sip:[email protected]", respectively. The Watchers have requested to view the Presentities mood, activities and place-type information and the same are marked as private by the Presentity for the Watchers userA and userB. The Presentity comes to know about this through the NOTIFY request on the "presence.winfo" Watcher information event as extended by the above approach I. If the Presentity is willing to authorize the Presentity will
XCAP operation to modify the Presence Authorization document to allow to Watchers those contents that they have requested.

Table 6. Example Watcher Information extension - Approach 1
The following Table 7 is the schema definition for the extension part of Watcher information described in Approach 1:

Table 7. Schema for Watcher Information extension - Approach 1 Approach 2
This approach purposes to reuse the approach used in Presence Authorization Rule per draft-ietf-simple-presence-rules to express the requested content, where the presence attributes are expressed like , etc. Here in this approach the root element "watcherinfo" of the Watcher information document as described in RFC 3858 is extended to contain "watcher-contents-list" element which carries the details of the contents
requested by each Watchers and their identity, "watcher-contents-list" element contains any number of "watcher-contents" elements to carry the details of Watchers and the part of the Presence Information they have requested. The "watcher-contents" element must have an attribute named "watcher" whose value j
is URI of the Watcher. The "watcher-contents" element can have presence information data format elements as described in the draft-ietf-simple-presence- rules. As the requested contents have been represented in the unit of presence information data format which is the same way that the Presence Content Rule in Presence Authorization Rule uses to express the allowed contents in element, the Presentity would be able to easily update the Presence Content Rule per the Approach 2.
The following Table 8 is an example of Watcher information extension for a Presentity sip:[email protected] which per the above Approach 2. This example contains the same Watcher information as the example in Table 6, but is coded per the above Approach 2.

Table 8. Example Watcher Information extension - Approach 2
The following Table 9 is the schema definition for the format of Watcher information extension described in Approach 2.

Table 9. Schema for Watcher Information extension - Approach 2
The Figure 3 shows the example flow to convey the identity of the Watchers and
the protected contents to Presentity by utilizing Watcher Information extension as
proposed in this section.
The following describes each step in Figure 3:
1. The Presentity wishing to know the list of Watchers who are subscribed for his/her Presence Information and to know the contents they have requested for sends a SIP SUBSCRIBE request to SIP/IP core subscribing for the extended "presence.winfo" event package per this invention.
2. The SIP/IP core forwards the request to the Presence Server of Presentity's domain.
3. The Presence Server processes the received SIP SUBSCRIBE and upon successful processing sends 200 OK responses to SIP/IP Core.
4. The SIP/IP core forwards the 200 OK responses to the Presentity.
5. Presence Server sends the SIP NOTIFY request containing the details of the Watchers who are subscribed for Presentity's Presence Information and what contents they have requested as proposed by this invention. The format of the contents sent in SIP NOTIFY request can be either formats as described in the two approaches of section 1.2.1
6. SIP/IP Core forwards the SIP NOTIFY request to the Presentity.
7. Presentity sends 200 OK responses.
8. SIP/IP Core forwards the 200 OK response to the Presence Server,
1.2.2 Creation of new event package to convey the identity of the Watchers and the protected contents to Presentity
1. RFC 3265 defines a generic framework for subscription to and notifications of events related to SIP systems. As an alternate method to 1.2.1, this invention defines a new event package to convey the details of Watchers and the protected content they have requested. The name of the new package is "presence.winfo.content". The functionality of the framework is similar to the one described in RFC 3265 and the NOTIFY message carries the XML document which contains the details of the Watchers and the protected contents they requested.
2. The format of the XML content is same as the one described in the previous section 1.2.1 as the extension to the Watcher Information format. The extension part to the existing Watcher information document which is described in the two approaches of the section 1.2.1 is re-used here and they act as an independent format.
3. The following Table 10 is the example SIP SUBSCRIBE request on "presence.winfo.content" event package. Here, the Presentity "sip:[email protected]" subscribes to his own "presence.winfo.content" event.
Table 10. Example SUBSCRIBE request on "presence.winfo.content" event package.
As response to the above example SUBSCRIBE request in Table 10, The following Table 11 is the example SIP NOTIFY request on "presence.winfo.content" event package to the Presentity "sip:[email protected]", with the details of the content requested by the Watchers and their identity being embedded as the content of this NOTIFY request. The content reuses the same format as described in the Approach 1 in the section 1.2.1. The content type for this information is "application/watcherinfo- content+xml".
With this information, the Presentity "sip:[email protected]" can learn about the following information:
• The Watcher "sip:[email protected]" has requested the Presence Information of the Presentity. Among the requested parts of the Presence Information, the requests for "activities", "mood", "place-type" presence attributes have not been allowed per the presence Presentity's Presence Content Rule in Presence XDMS.
• The Watcher "sip: [email protected]" has requested the Presence Information of the Presentity. Among the requested parts of the Presence Information, the request for the "location- info" presence attribute? has not been allowed per the present Presentity's Presence Content Rule in Presence XDMS.
Based on this information, the Presentity may want to modify his present Presence Content Rule in Presence XDMS to selectively allow the requested contents to the Watchers.

Table 11. Example NOTIFY request on "presence.winfo.content" event package with the contents per the Approach 1 in section 1.2.1.
As response to the above example SUBSCRIBE request in Table 10, the
following fable 12 shows the example SIP NOTIFY request on "presence.winfo.content" event package to the Presentity "sip:[email protected]" with the contents per the Approach 2 in section 1.2.1. The content delivers the same information as the above Table 11, but reuses the format as described in the Approach 2 in the section 1.2.1.

Table 12. Example NOTIFY request on "presence.winfo.content" event package with the contents per the Approach 2 in section 1.2.1.
The Figure 4 shows the example flow to convey the identity of the Watchers and the protected contents to Presentity by using the new event package of "presence.winfo.content" as proposed in this section.
Following are steps involved in Figure 4.
1. The Presentity wishing to know the details of the contents requested by the Watchers who are subscribed for his/her Presence Information sends a SIP SUBSCRIBE request to SIP/IP core subscribing for "presence.winfo.content" event package per this invention.
2. The SIP/IP core forwards the request to the Presence Server of Presentity's domain.
3. The Presence Server processes the received SIP SUBSCRIBE and upon successful processing sends 200 OK responses to SIP/IP Core.
4. The SIP/IP core forwards the 200 OK responses to the Presentity.
5. Presence Server sends the SIP NOTIFY request containing the details of the Watchers who are subscribed for Presentity's Presence Information and what content they have requested as proposed by this invention. The format of the content sent in SIP NOTIFY request can be either of format described in the two approaches of section 1.2.2
6. SIP/IP Core forwards the SIP NOTIFY request to the Presentity.
7. Presentity sends 200 OK responses.
8. SIP/IP Core forwards the 200 OK response to the Presence Server,
1.2.3 Using multipart/mixed content type to convey the protected contents requested by Watchers
This approach proposes to use the "multipart/mixed" content type as described in [RFC2387] inorder to aggregate the Watcher Information and the protected contents requested by the watchers. In this format the root document contains the watcher information document as described in RFC 3858 and the remaining
part contains the details of the protected contents requested by each watchers. The remaining part of the "multipart/mixed" content types contains the details of the protected content by each of the watcher. The format of this document could be any of the following: 1. Format explained in Approach 1 of the section 1.2.1 of this document [see Table 7]
2. Format explained in Approach 2 of the section 1.2.1 of this document [see Table 9]
3. Event Notification Filtering document as described in RFC 4661 with the extensions explained in section 1.2.3.1 of this document.
1.2.3.1 Re-using Event Notification Filter document
This invention proposes to re-use the Event Notification Filtering document for conveying the details of the protected contents requested by the watchers to the Presentity with the clarifications as descibed below. Clarifications:
The Presence Server of the Presentity domain figures out the protected contents if any, requested by the watchers, by applying the corresponsing presence authorisation rules and also the Event notification filter requested by the watcher. If a particular watcher has requested for any protected contents of the presentity the Presence Server constructs the Filter document using the element and sets the "uri" attribute of the element to the URI of the watcher. Presence of any other attributes other than "uri" should be ignored by the presentity. Usage of and elements are discouraged. This way the Presence Server constructs filter document for all the watchers who have requested for the protected contents and aggregate all the information as "multipart/mixed" content type arid send in the notification of watcher information subscription. If not the "uri" attribute, the element could be extended with any other new attribute to carry the identity of the watcher. The PS can make sure that it conveys all the namespace bindings to the Presentity when it aggregates the filters from all the watchers.
Table 13 shows an example NOTIFY containing the multipart/mixed content type
wherein one part contains the watcher information and the other part contains the filter document which is aggregation of protected content requested by the watchers.
' w
1

Table 13: Example for conveying the protected contents requested by watchers to the Presentity using "multipart/mixed" content type.
1.2.4 Using Content Indirection Mechanism
These inventions propose one another mechanism for conveying the details of protected contents requested by the watchers and their identities to the presentity by making use of content indirection mechanism as explained in RFC4483. In order to achieve the content indirection, this invention proposes that the Presence Server stores the status of the protected contents within it or some other place like content server in the format of separate MIME as described in the above section 1.2.2 and 1.2.3, then delivers the URI of the stored information to the presentity by extending the content of the Watcher Information notification as following:
Either the or the element of the Watcher Information format (RFC 3858) can be extended to contain a new element or a new attribute to carry the uri of the indirected content. The presentity on receiving the uri of the indirected content and it can retrieve the status of the protected contents to perform the reactive authorization on those.Table 14 shows an example of using content indirection mechanism to convey the status of

Table 14: Conveying protected content status using content indirection
1.2.5 Watcher Preferences for Receiving Notifications According to RFC 4661, Watcher use the filter element to trigger the content delivery when the presence element it identifies has been added to the presence information document being filtered.
This invention further proposes to utilize the filter element for reactive content authorization such that the presence element specified in the filter element indicates the watcher's explicit request to receive the specified element. Therefore, the Presence Server on receiving the filter with element in it can interpret it in the following way:
a) .lf the Presence Information elements listed in the element are already authorised to the Watcher it can include those elements as a part of the initial NOTIFY and send it to watcher.
b) . If the Presence Information elements listed in the element are not authorised to the Watcher it can include only those elements as a part of the protected contents which would be sent to the Presentity for reactive authorisation.In this case the Presence Server can withhold the initial NOTIFY request for a specific period of time which allows some time for the Presentity to modify the Presence Authorisation rules to allow the specified content for the watcher. If no authorisation happens within a specific period of time the Presence Server sends the initial NOTIFY request with the presence contents as allowed to the Watcher.
Table 15 shows an example of the Event Notification Filter Document which carries the Watcher Preferences of receiving Notifications using element.
-a-

Table 15: Watcher Preferences of Receiving Notifications by using element
1.3 Presentity performing Reactive Presence Authorization by modifying Presence Authorization Rule in Presence XDMS
Upon receiving the above information on the Watcher's requests for the protected content of the Presence Information per the mechanisms described in the above section 1.1 and 1.2, Presentity may elect to perform the Content-level Reactive Presence Authorization to selectively authorize the Watcher's requests on the protected contents of the Presentity's Presence information. The Presentity can achieve this Content-level Reactive Presence Authorization by modifying as such, the Presence Content Rule in the Presentity's Presence Authorization Rule in Presence XDMS, using the XCAP operations. Then, these changes in Presence Content Rule in the Presence Authorization Rule will be
notified to Presence Server, and then the Presence Server applies this updated Presence Content Rule to authorize the Watcher's requests on the protected contents of the Presentity's Presence Information and deliver those to the requesting Watcher.
2. Dynamic Mechanism
In the previous section 1 this invention discussed about "Static Mechanism" for achieving the Content-level Reactive Presence Authorization. This invention further proposes another dimension to achieve Content-level Reactive Presence Authorization in dynamic manner, which is called "Dynamic Mechanism" or "Direct Mechanism".
The "Static Mechanism" in section 1 requires the Presentity to update the static Presence Authorization Rule in Presence XDMS to perform the Content-level Reactive Presence Authorization. As such, the Content-level Reactive Presence Authorization per the "Static Mechanism" in section 1 exists persistently and continues to be applied to the future requests from the Watchers.
Compared to the "Static Mechanism"-, this "Dynamic Mechanism" does not require any modification to the existing Presence Authorization Rule document to perform the Content-level Reactive Presence Authorization, but with the "Dynamic Mechanism" the Presentity sends the Content-level Reactive Presence Authorization directly to the Presence Server. As such, the Content-level Reactive Presence Authorization using the "Dynamic Mechanism" does hold only for the Watcher's pending or active subscription duration.
Further, this invention proposes that this "Dynamic Mechanism" for the Content- level Reactive Presence Authorization can also be applied for the Reactive Presence Authorization of subscription as well as that of contents. In other words, this "Dynamic Mechanism" for Reactive Presence Authorization can be applied for both Subscription Authorization Rule and Content Authorization Rule. (Note
that the Presence Authorization Rule consists of Subscription Authorization Rule and Content Authorization Rule.) As such, this invention calls the "Dynamic Mechanism" as the "Dynamic Reactive Presence Authorization".
With the Dynamic Reactive Presence Authorization, this invention proposes that the Presence Authorization Rule in Presence Server that the Presence Server uses to authorize the presence requests from Watchers is the composite view of the following two parts of the Presence Authorization Rule:
• Static Presence Authorization Rule that is based on the Presence Authorization Rule document in Presence XDMS;
• Volatile Presence Authorization Rule set directly by the Presentity.
As mentioned above, the volatile part of the Presence Authorization Rule in Presence Server holds during Watcher's pending or active subscription duration. So, the same Presence Authorization Rule in Presence Server will be applied for re-SUBSCRIBE request. Also, the same Presence Authorization Rule in Presence Server will be applied for every SIP NOTIFY to the Watcher. But, it should be noted that, upon termination of the Watcher's current active subscription, the volatile part of Presence Authorization Rule in Presence Server will disappear.
To achieve the Dynamic Reactive Presence Authorization this invention proposes the following steps:
1. Presentity specrfing the conditions for Presence Server to trigger the Reactive Presence Authorization for protected contents. This can be achieved per the mechanisms proposed in section 1.1;
2. Conveying the identity of the Watchers and the protected contents to Presentity. This can be achieved per the mechanisms proposed in section 1.2;
3. Presentity performing Reactive Presence Authorization by sending the authorization directly to Presence Server.
Alternatively, this invention proposes that Presence Server directly asks Presentity for Reactive Presence Authorization, then Presentity responses directly to the Presence Server with the Reactive Presence Authorization.
2.1 Presentity performing Reactive Presence Authorization directly to Presence Server
As described in the above section 1. this invention proposes that Presence Server have the composite view of Presence Authorization Rule by composing the static Presence Authorization Rule from Presence XDMS and the volatile Presence Authorization Rule that comes directly from Presentity. This invention proposes to denote the volatile Presence Authorization Rule as the new event package called "presauth".
Upon the information on the Watcher's requests for the Presentity's Presence Information, the Presentity may elect to authorize the Watcher's request just for one time rather than in persistent manner. This invention proposes that the Presentity that wants such volatile Presence Authorization issue the PUBLISH request for the "presauth" event package to Presence Server. The body of such PUBLISH requests carries the "volatile" Presence Authorization Rule. The content type for this body can be "application/presauth+xml".
Upon receiving this PUBLISH request on "presauth" event package with Presence Authorization Rule from Presentity, the Presence Server will compose this "volatile" Presence Authorization Rule with the static Presence Authorization Rule from Presence XDMS. When composing, the "volatile" rule will take precedence over the "static" rule in case that those rules collide. For easy composition with static Presence Authorization Rule, the content of "dynamic" Presence Authorization Rule can have the same format as the static Presence Authorization Rule. The Presence Server can wait for some specific period of time to receive the dynamic authorisation rule. If no rule is received from the Presentity within the specified time the Presence Server can apply the static
authorisation rule.
As this is a new event package, Presentity can also use SIP event SUBCRIBE/NOTIFY (RFC 3857) to get synchronized with the "volatile" Presence Authorization Rule in Presence Server.
The following Table 16 shows the example PUBLISH requests on the "presauth" event package with the body containing the "volatile" Presence Authorization Rule as proposed by this invention, which Presentity of "sip:[email protected]" sends to Presence Server.
V

Table 16. Example PUBLISH request on "presauth" event package with the volatile Presence Authorization Ruje in the body.
The following Figure 5 shows the example flows where Presentity issues PUBLISH request on "presauth" event package to deliver the volatile Presence Authorization Rule to Presence Server.
Following steps describe the steps in Figure 5:
1. The Presentity in order to get to know the details of the Watchers' requests for presence subscription and the contents of the Presentity's Presence Information they have requested would send SIP SUBSCRIBE subscribing for "presence.winfo" event package with extensions proposed in this invention (section 1.2.1) or for "presence.winfo.content" event package as described in the section 1.2.2.
2. Watcher sends SIP SUBSCRIBE to subscribe for the Presence Information of the Presentity. But, this Watcher is not yet authorized by Presentity based on the static Presence Authorization Rule in Presence XDMS.
3. The Presence Server sends a SIP NOTIFY request on either "presence.winfo" event package with extensions by this invention or "presence.winfo.content" event package. This SIP NOTIFY request carries the details of the Watcher lists and their requests for the protected contents as proposed by this invention.
4. Presentity wishing to authorize the Watcher just for one time rather than persistently sends the SIP PUBLISH request on "presauth" event package to Presence Server with its body containing the volatile Presence Authorization Rule as proposed by this invention.
5. The Presence Server sends SIP NOTIFY request to the Watcher which contains the valid Presence Information which he/she is reactively authorized to view.
2.2 Presence Server directly asking Presentity for Reactive Presence Authorization
This invention further proposes an alternative method for the Presentity getting to know the details of the Watchers' requests for presence subscriptions and the protected contents they have requested, wherein: Presence Server directly delivers the status of Watchers' requests, asking for Presentity to perform the Reactive Presence Authorization.
In the previous methods the Presentity have to subscribe for the information on Watcher requested contents by using the methods described in the section 1.2 of this document.
But here in this alternative method there is no need for the Presentity to do subscribe for Watcher content information; instead, the Presence Server directly pushes the information to the Presentity, directly asking for Presentity's Reactive Presence Authorization.
For this method, this invention proposes to utilize the SIP MESSAGE or other appropriate SIP methods. The content type of the SIP MESSAGE could be "application/reactive-auth+xml" and the format of the document carried in the SIP MESSAGE would be similar to the format describe in the section 1.2 of this document.
Upon receiving this information from Presence Server, Presentity can respond to the Presence Server with the Reactive Presence Authorization as previously described methods in this invention.
Other steps like specifying the conditions for Presence Server to trigger the Reactive Presence Authorization for protected contents and Presentity
performing Reactive Presence Authorization directly to Presence Server remains the same for this alternative method. The Presence Server can wait for some specific period of time to receive the dynamic authorisation rule. If no rule is received from the Presentity within the specified time the Presence Server can apply the static authorisation rule.
The following Figure 6 shows the example flows of this alternate methods. Compared to the above Figure 5, the only difference is that: instead of using the "presence.winfo" or "presence.winfo.content" event package, the Presence Server pushes the information on the Watcher's requests for subscription and the protected contents of the Presentity's Presence Information using the SIP MESSAGE method with this information in the body.

Documents:

1192-CHE-2007 FORM-13 12-12-2013.pdf

1192-CHE-2007 ABSTRACT.pdf

1192-CHE-2007 AMENDED CLAIMS 03-11-2014.pdf

1192-CHE-2007 AMENDED CLAIMS 26-08-2014.pdf

1192-CHE-2007 AMENDED PAGES OF SPECIFICATION 26-08-2014.pdf

1192-CHE-2007 CLAIMS.pdf

1192-CHE-2007 CORRESPONDENCE OTHERS.pdf

1192-CHE-2007 DESCRIPTION (COMPLETE).pdf

1192-CHE-2007 DRAWINGS.pdf

1192-CHE-2007 EXAMINATION REPORT REPLY RECEIVED 03-11-2014.pdf

1192-CHE-2007 EXAMINATION REPORT REPLY RECEIVED 26-08-2014.pdf

1192-CHE-2007 FORM-1 26-08-2014.pdf

1192-CHE-2007 FORM-13. 03-11-2014.pdf

1192-CHE-2007 FORM-18.pdf

1192-CHE-2007 FORM-3 26-08-2014.pdf

1192-CHE-2007 FORM-5.pdf

1192-CHE-2007 OTHER PATENT DOCUMENT 26-08-2014.pdf

1192-CHE-2007 OTHER PATENT DOCUMENT 1 26-08-2014.pdf

1192-CHE-2007 POWER OF ATTORNEY 03-11-2014.pdf

1192-CHE-2007 POWER OF ATTORNEY 26-08-2014.pdf

1192-CHE-2007 FORM-13 17-12-2013.pdf

1192-che-2007_correspondence-others.pdf

1192-che-2007_discreiptionprovisional..pdf

1192-che-2007_drawings.pdf

1192-che-2007_form1.pdf

1192-che-2007_form26.pdf

« Previous Patent

Next Patent »

Patent Number

263771

Indian Patent Application Number

1192/CHE/2007

PG Journal Number

47/2014

Publication Date

21-Nov-2014

Grant Date

19-Nov-2014

Date of Filing

08-Jun-2007

Name of Patentee

SAMSUNG R&D INSTITUTE INDIA-BANGALORE PRIVATE LIMITED

Applicant Address

#2870 ORION BUILDING BAGMANE CONSTELLATION BUSINESS PARK OUTER RING ROAD DODDANEKUNDI CIRCLE MARATHAHALLI POST BANGALORE 560037

Inventors:

#	Inventor's Name	Inventor's Address
1	MAYURESH MADHUKAR PATIL	SAMSUNG INDIA SOFTWARE OPERTIONS PVT LTD BAGMANE LAKEVIEW, BLOCK 'B',NO.66/1, BAGMANE TECH PARK, CV RAMAN NAGAR, BYRASANDRA,BANGALORE-560093, KARNATAKA,INDIA
2	PATIL MAYURESH MADHUKAR	SAMSUNG INDIA SOFTWARE OPERTIONS PVT LTD BAGMANE LAKEVIEW, BLOCK 'B',NO.66/1, BAGMANE TECH PARK, CV RAMAN NAGAR, BYRASANDRA,BANGALORE-560093, KARNATAKA,INDIA
3	JAE KWON OH	SAMSUNG INDIA SOFTWARE OPERTIONS PVT LTD BAGMANE LAKEVIEW, BLOCK 'B',NO.66/1, BAGMANE TECH PARK, CV RAMAN NAGAR, BYRASANDRA,BANGALORE-560093, KARNATAKA,INDIA

PCT International Classification Number

H04L12/56

PCT International Application Number

N/A

PCT International Filing date

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1			NA