WO2008041830A1

WO2008041830A1 - System and method for providing rls notification rule for multiple presentities

Info

Publication number: WO2008041830A1
Application number: PCT/KR2007/004853
Authority: WO
Inventors: Jae-Kwon Oh; Basavaraj Jayawant Pattan
Original assignee: Samsung Electronics Co., Ltd.
Priority date: 2006-10-03
Filing date: 2007-10-04
Publication date: 2008-04-10
Also published as: KR101378217B1; WO2008041830A8; KR20080031141A

Abstract

Disclosed are a system and method for allowing a user to specify the choice of how and when RLS has to generate NOTIFY requests. As a result, it becomes possible to optimize the presence notifications by avoiding unnecessary and sometimes annoying notifications. This is possible by allowing a user to specify RLS notification rule in the initial SIP SUBSCRIBE. Therefore, the present invention allows the Watcher to specify filters in SIP SUBSCRIBE. The present invention further indicates the expected behavior of an RLS when such RLS notification rules exist in SIP SUBSCRIBE.

Description

SYSTEM AND METHOD FOR PROVIDING RLS NOTIFICATION RULE

FOR MULTIPLE PRESENTITIES

Field of the Invention

The present invention in general relates to mobile communication. The present invention relates to various OMA developed applications over SIP (Session Initiation Protocol), such as Instant Messaging, Push to talk over Cellular, Converged IP Messaging and any other future applications that utilize presence service. The present invention relates to those applications which subscribe to and receive notifications about presence information. More particularly, this invention relates to an RLS (Resource List Server) notification rule for multiple presentities.

Description of the Related Art

Presence system architecture helps to share the presence information of any user to other users. The presence information is basically the information related to the user, like current location of the user, contact information of the user and application specific presence information, such as if the user is available for IM (Instant Message) etc. Currently, the user has to subscribe to the presence information of other users in order to receive presence information of other users. Then, the requested user authorizes reception of his presence information by the requesting user. The presence server entity maintains the presence subscription of the requesting user and also stores the presence information of the requested user. As soon as presence information of the requested user changes, the presence server sends the notifications to the subscribing/requesting user during the period when the subscription is still valid. Here, the other user / requested user whose presence information is of concern is called the Presentity, and the user / requesting user who subscribes to and receives the presence information is called the Watcher. The Watchers are basically users who are authorized to watch the presence information of another user. The SIP SUBSCIBE and SIP NOTIFY methods are used for subscribing and notifying.

There are numerous presence attributes to which a Watcher can subscribe, but the Watcher may not be interested in all the presence information of a Presentity. By specifying filters, the Watcher is able to receive only required presence notifications. These filter rules are defined in the IETF draft draft-IETF RFC 4660 "Functional Description of Event Notification Filtering." The filters are executed at the Presence Server of the Presentity.

Also, a User registered to Presence Service can subscribe to presence information of an individual or a group of presentities. For subscribing to presence information of a set of presentities, SIP SUBSCRIBE will specify the URI of the resource list that lists the group of presentities as specified in IETF RFC 4662 "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", or will consist of a URI list as specified in IETF draft draft-ietf- sip-uri-list-subscribe "Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)". The notifications are delivered to the Watcher either regarding an individual or aggregated from a group of presentities through the Resource List Server (RLS). URI-list service will handle such SIP SUBSCRIBE and SIP NOTIFY as specified in IETF draft draft-ietf-sipping-uri- services "Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services." The filters, if they exist, are executed at the Presence Server of the Presentity and specify the behavior of Presence Server for notification generation to RLS.

In the current art of the uri-list service, a Watcher receives composite notification for a group of presentities from RLS. Such composite notification from the RLS contains a group of notifications respectively from a set of presentities. There is no association of the notifications received from one user with another user.

Hereinafter, the sequence of the operations of the above case will be explained with reference to Figures 1 and 2. For example, consider the case that Adam wants to invite Bill, Joe and Ted to a conference, and thinks everyone's presence in the conference is a must. So, Adam sends a subscription request containing a rule, to send notifications only when all three Bill, Joe and Ted's presence information are "OPEN."

At present, Bill's and Ted's presence information are "CLOSED," and Joe's presence information is "OPEN." Referring to Figures 1 and 2, Bill 50 has a service subscription with the same operator as to which Adam 10 has a service subscription, whereas Joe 60 and Ted 70 has service subscriptions with another operator.

Referring to Figures 1 and 2, Adam's Client 10 sends a single list presence subscription request (complying to draft-ietf-sip-uri-list-subscribe) to the RLS (Resource List Server) 20 containing a filter (complying to IETF RFC 4660) at step 100. Here, SUBSCRIBE is used for subscription requests. The list contains the subscription requests to Bill, Joe and Ted, and the filter rule specifies to send notifications when Bill, Joe and Ted's presence information are "OPEN."

So, the RLS 20 spawns the subscription requests containing the filter to Presence-Server-A (PA-S) 30 and Presence- S erver-B (PA-B) 40 at steps 105 and 110. At step 115, Presence-Server-A 30 is then provided with PUBLISH from Bill 50 and monitors the presence information of Bill 50. Presence-Server-A 30, if required, filters the presence information at step 120, and then sends notifications only when Bill 50 changes his presence to "OPEN" at step 125. Here, NOTIFY is used for the notifications. In a similar way, at step 130, Presence-Server-B 40 is provides with PUBLISH from Joe 60, and then monitors the presence information of Joe 60. At step 135, Presence-Server-B 40, if required, filters the presence information, and then Presence-Server-B 40 immediately sends notifications to the RSL 20 at step 140 if the presence information of Joe is "OPEN." Therefore, the RLS 20 combines notifications at step 145 and sends the notification to Adam 10 (with consideration of notification speed, etc.), thereby allowing Adam 10 to be aware that Joe 60 is "OPEN." For Ted 70, Presence-Server-B 40 is provided with PUBLISH from Ted 70 and then monitors the presence information of Ted 70 at step 155. At step 160, Presence- Server-B 40, if required, filters the presence information, and then sends a notification at step 165 only when Ted 70 changes his presence to "OPEN." Therefore, RLS 20 sends the notification to Adam 10 at step 170.

In this way, Adam may receive Bill's, Joe's, and Ted's "OPEN" presence information in multiple notifications. In order to meet the use case, Adam has to monitor manually if the arrived notifications meet his requirement that all of Bill, Joe and Ted should be "OPEN." Thus, Adam 10 monitors the multiple notifications at step 175. Then, when all of Bill's, Joe's and Ted's presence information are "OPEN," Adam invites them to the conference.

Technical Objects

However, when a User subscribes to presence information of a group of presentities, he may want to receive notifications only relative to other user's presence, rather than aggregated presence information from a set of presentities. In other words, a user has a choice of specifying how and when the RLS has to generate notifications. The current art does not permit for such use cases.

Also, overload may be caused if the User receives notifications from a number of users whenever the presence information changes while the User subscribes to the presence information. Further, it is an unnecessary and annoying task for the Watcher to receive every notification. Therefore, it is necessary to optimize the presence notifications by avoiding the unnecessary and annoying notifications.

Once the Watcher, however, receives presence information from a group of presentities, the Client has to evaluate against the notification rule set by the User (stored in Client) before presenting the presence information to the User. But, authors are not aware of such client implementations. Technical Solutions

Accordingly, the present invention has been made to solve the above- mentioned problems occurring in the prior art, and the present invention provides a system and method for allowing a user to specify the choice of how and when the RLS has to generate NOTIFY requests.

Effects of the Invention

This invention allows a user to specify how and when the RLS has to generate notifications, thereby optimizing notifications. In addition, this invention provides good user experience and reduces service cost.

Brief Description of the Drawings

The above and other aspects, features and advantages of the present invention will be more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

Figure 1 illustrates the entities involved for the use case considered in this invention;

Figure 2 illustrates the flow for current art for the use case considered in this invention; and

Figure 3 illustrates the flow for invention for the use case considered in this invention.

Best mode for carrying out the Invention

Hereinafter, exemplary embodiments of the present invention will be described with reference to the accompanying drawings. In the following description of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear.

The present invention provides a system and method for allowing a user to specify the choice of how and when the RLS has to generate NOTIFY requests. As a result, it becomes possible to optimize the presence notifications by avoiding unnecessary and sometimes annoying notifications. This is possible by allowing user to specify RLS notification rule in the initial SIP SUBSCRIBE. Therefore, the present invention allows the Watcher to specify filters in SIP SUBSCRIBE. The present invention further indicates the expected behavior of RLS when such RLS notification rules exist in SIP SUBSCRIBE.

RLS Notification Rule:

A user is allowed to specify RLS Notification Rule in the initial SIP SUBSCRIBE, which can also contains either the URI list in the format as specified in "draft-ietf-sip-uri-list-subscribe", or the URI of the URI list as specified in RFC 4662. The format of the RLS Notification Rule (from now on referred as rls-notification-rule throughout the invention) can be defined by content type, for example, "application/rls-notification-rule." The rules differ based on the "operation type." The operation type could be divided into "ALL", "ATLEAST", "ATMOST", "EQUALS", and any other.

Example formats for the operation types identified above are as given below.

First, an example format for the operation type "ALL" is shown in table 1 below. TABLE l

</list> </operation>

Table 1 means that the Watcher is interested in notifications only when all the notifications are received from the list of users specified in the rule. Also, an example format for the operation type "ATLEAST" is shown in table 2 below.

TABLE 2

</list>

</operation>

Table 2 means that the Watcher is interested in notifications only when at- least "x" number of notifications are received from the list of users specified in the rule.

Also, an example format for the operation type "ATMOST" is shown in table 3 below. TABLE 3

</list> </operation>

Table 3 means that the Watcher is interested in notifications only when at- most "x" number of notifications are received from the list of users specified in the rule.

Also, an example format for the operation type "EQUALS" is shown in table 4 below. TABLE 4 <operation type="EQUALS" number="x"> <list>

</list> </operation>

Table 4 means that the Watcher is interested in notifications only when "x" number of notifications are received from the list of users mentioned in the rule.

In tables 1 to 4, <list> element is optional in all the notification rules specified above, and if not present, then the operation is applied to all the presentities mentioned in resource-lists.

The invention does not restrict the RLS Notification Rules to the above mentioned operation types, but also the RLS Notification Rules can contain any user directives that control the RLS notification.

RLS stores the Notification Rule:

On reception of a SIP SUBSCRIBE request with a URI-list containing rls-notification-rule, the URI List Service will comply with RFC 4662 for creating the subscription and receiving the changes in the resources within the created dialog. The rls-notification-rule is associated with the dialog and is stored by the URI List Service.

RLS verifies Notifications against Rule:

On receiving the presence notifications from multiple resources, the URI List Service evaluates the notifications against the rls-notification-rule and only for successful evaluation are the presence notifications delivered to the Watcher. Otherwise, the notification is not sent to the Watcher. Hereinafter, referring to Figure 3, the sequence of operations for the use case considered in this invention can be explained as below.

It is assumed in Figure 3 that Bill's and Ted's presence information are "CLOSED," but Joe's presence information is "OPEN." It is also assumed that Bill has a service subscription to the operator where Adam has service subscription, and Joe and Ted have service subscriptions with another operator.

Referring to Figure 3, Adam 10 sends a single list presence subscription request (complying to draft-ietf-sip-uri-list-subscribe) to the RLS 20 containing a filter (complying to IETF RFC 4660) at step 300. The list contains the subscription requests for Bill 50, Joe and Ted 60 and 70.

The filter rule specifies to send notifications when presence information of Bill 50, Joe and Ted 60 and 70 are "OPEN." Additionally Adam 10 specifies an rls-notification-rule that instructs the RLS to send the notifications to Adam 10 only when the RLS 20 receives all presence information from Bill 50, Joe and Ted 60 and 70.

The RLS 20 determines if there is rls-notification-rule at step 305, and then spawns the subscription request containing the filter to Presence-Server-A 30 and Presence-Server-B 40 at steps 310 and 315. Here, the rls-notification-rule is excluded from the subscription request, as it is only valid for the RLS 20.

Presence-Server-A 30 is provided with PUBLISH from Bill 50 at step 320 and monitors the presence information of Bill 50. Presence-Server-A 30, if required, filters the presence information at step 325, and then sends notification to the RLS 20 only when Bill 50 changes his presence to "OPEN" at step 330. NOTIFY is used for this notification.

Similarly, Presence- Server-B 40 monitors the presence information of Joe and Ted 60 and 70. Accordingly, Presence-Server-B 40 is provided with PUBLISH from Joe 60 at step 335, and then, if required, filters the presence information at step 340. Since the presence information of Joe 60 is "OPEN," notification for the presence information of Joe is sent immediately from Presence-Server-B 40 to RLS 20. However, as the presence information of Ted 70 is not "OPEN" yet, and thus does not suffice the rls-notifϊcation-rule, it is not notified yet.

Although the RLS 20 has received notifications from Bill 50 and Joe 60 by now, it does not satisfy the rls-notification-rule as the presence information from Ted 70 has not been received yet. As such, the RLS 20 holds up the delivery of notifications to Adam 10 until it receives one from Ted 70.

For Ted, Presence-Server-B 40 is provided with PUBLISH from Ted 70 at step 355 and monitors the presence information of Ted 70. Accordingly, Presence- Server-B 4, if required, filters the presence information at step 360, and then sends the notification to the RLS when Ted changes his presence to "OPEN" at step 365.

In this way, RLS can receive the presence information of Ted 70. Accordingly, the RLS 20 determines if the rls-notification-rule is met at step 370. As the RLS 20 has presence information of all of Bill's, Joe's, and Ted's, the rls- notification-rule is now met and thus RLS 20 sends the composite notification to Adam 10.

Accordingly, Adam 10 receives Bill, Joe and Ted's "OPEN" presence information in a single notification from RLS 20. As all of Bill, Joe and Ted's presence information is "OPEN," Adam 10 invites them to the conference.

In order to achieve this, in the present invention the following changes to the current art are suggested.

First, in the case of SIP SUBSCRIBE, a User is allowed to specify rls- notification-rule in the SIP SUBSCRIBE body containing subscription to a list of resources in SIP which is being sent to the RLS or URI List Service. The RLS server or URJ List Service performs the additional role of the storing rls- notification-rule and also of monitoring presence information arriving from a group of presentities and evaluating the rls-notification-rule. STEP 1: Changes in SIP SUBSCRIBE

An example illustrating how a SIP SUBSCRIBE request appears when a conditional rule is included with it is shown table 5 below. TABLE 5

SUBSCRIBE sip:rls@example.com SIP/2.0

Via: SIP/2.0/TCP terminal. example.com;branch=z9hG4bKwYb6QREiCL Max-Forwards: 70 To: RLS <sip:rls@example.com> From: <sip:adam@example.com>;tag=ie4hbbδt Call-ID: cdB34qLToC@terminal.example.com CSeq: 1 SUBSCRIBE Contact: <sip:terminal. example. com> Event: presence Expires: 7200

Require: recipient-list-subscribe Supported: eventlist Accept: application/cpim-pidf+xml Accept: application/rlmi+xml Accept: multipart/related Accept: multipart/signed Accept: multipart/encrypted

Content-Type: multipart/mixed;boundary="boundary1 " Content-Length: xxx

-boundaryl

Content-Type: application/resource-lists+xml

Content-Disposition: recipient-list

<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns:xsi="http://www. w3.org/2001/XMLSchema- instance">

<list>

<entry uri="sip:bill@example.com" /> <entry uri="sip:joe@example.org" /> <entry uri="sip:ted@example.org" /> </list> </resource-lists> -boundaryi-

Content-Type: application/simple-filter+xml

<?xml version="1.0" encoding="UTF-8"?> <filter-set xmlns="um:ietf:params:xml:ns:simple-filter"> <ns-bindings>

<ns-binding prefix="pidf urn="urn:ietf:params:xml:ns:pidf'/> </ns-bindings> <filter id="123"> <trigger> <changed from="CLOSED" to="OPEN">

/pidf:presence/pidf:tuple/pidf:status/pidf: basic </changed> </trigger> </filter> </filter-set> -boundary 1 —

Content-Type: application/rls-notification-rule+xml

<?xml version="1.0" encoding="UTF-8"?> <rule~set xmlns= "urn:ietf:params:xml:ns:rls-notification-rule "> <rule id="123"> <trigger>

</operation> </trigger> </rule>

</rule-set>

-boundary 1—

STEP 2: Changes in role of RLS server or URI List Service

Upon reception of a SIP SUBSCRIBE request with a URI-list containing an rls-notification-rule, the URI List Service will comply with RFC 4662 for creating the subscription and receiving the changes in the resources within the created dialog. The RLS notification rule is associated with the dialog and is stored by the URI List Service. Upon receiving the presence notifications from multiple resources, the URI List Service evaluates the RLS notification against the rls-notification-rule, and only for successful evaluation are the presence notifications delivered to the Watcher.

The description below explains one of the ways to apply of this invention for illustration purposes only and there may be several other ways to apply this invention.

First, RLS Notification Rules according to this invention are as follows.

A Watcher, when subscribing to a presence list, may be able to set some conditions to control the triggers of notifications. With the RLS Notification Rules, the Watcher can specify when it is intended to receive Presence Information of a group of presentities from RLS. Whenever the Watcher wants to set some rules while subscribing to a Presence List, he/she can send a SIP SUBSCRIBE request according to IETF RFC 3265 "Session Initiation Protocol (SΙP)-Specific Event Notification" with the following clarifications.

If the Watcher wants to send Event Notification Filtering Rules IETF RFC 4660 "Functional Description of Event Notification Filtering" and RLS Notification Rules, he/she can include value "multipart/related" in the Content- Type header in order to aggregate "application/simple-filter+xml" and "application/vnd.oma.rls-notification-rules+xml" content types.

The XML format for specifying RLS Notification Rules conform to the schema described in table 6 below.

TABLE 6

<?xml version="1 . 0" encoding="UTF-8 " ?>

<xs : documentation xml :lang="en">Schema Definition for RLS Notification Condition. </xs :documentation> </xs : annotation>

<xs: element name="rule-set" type="RuleSetType"/> <xs:complexType name="RuleSetType"> <xs : sequence>

<xs: element name="ns-bindings" type="NSBindings" minOccurs="0"/> <xs: element name="rule" type="RuleType" maxOccurs="unbounded"/> </xs :sequence> </xs : complexType>

<xs:complexType name="NSBindings"> <xs:sequence>

<xs: element name="ns-binding" type="NSBinding" maxOccurs="unbounded"/> </xs:sequence>

</xs : complexType>

<xs:attribute name="urn" type="xs:anyDRI" use="required"/> </xs : complexType> <xs : complexType name="RuleType">

<xs:sequence>

<xs: element name="trigger" type="triggerType" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence> </xs : complexType> <xs: complexType name="triggerType">

<xs: element name="operation" type="operationType" minOccurs="0" maxOccurs="unbounded"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurS="unbounded"/>

</xs:sequence> </xs : complexType>

<xs : complexType name="operationType"> <! — Includes elements <list> and <entry> whose format is similar as described in [RFC4826] —>

Also, the RLS Notification Rules conform to the structure and semantics as described below.

The root element <rule-set> can include any other attribute for the purposes of extensibility, can include a <ns-bindings> element that contains the namespace bindings, and includes one or more <rule-set > elements that contain the conditions for RLS notification delivery.

Also, The <ns-bindings> element includes one or more <ns-binding> elements, each of which contains the binding between the prefix and the namespace in a "prefix" attribute and a "namespace" attribute, respectively. This is used to express the list of URIs for whom the condition has to be applied using the format of resource-list as described in [RFC4826]. The <rule> element includes an "id" attribute that contains the unique identification for the condition, includes zero or more <trigger> elements that contains the operation types which trigger the RLS notifications, and can include any other elements from other namespaces for the purposes of extensibility.

The <trigger> element includes zero or more <operation> elements, each of which contains the operation type to be applied, and can include any other elements from other namespaces for the purposes of extensibility.

The <operation> element includes a "type" attribute that specifies how to apply the trigger for the URIs listed as child elements, can include zero or one <list> elements that contains the URIs of resources as described in [RFC4826], and can include any other elements from other namespaces for the purposes of extensibility.

The following table 7 is an example of Event Notification Filter along with the RLS Notification Rules. TABLE 7

--boundary1—

Content-Type : application/simple-filter+xml

<?xml version="1.0" encoding="ϋTF-8"?>

<filter-set xmlns="urn: ietf :params :xml :ns : simple-filter"> <ns-bindings>

<ns-binding prefix="pidf" urn="urn:ietf :params :xml :ns :pidf"/> </ns-bindings> <filter id="123"> <trigger>

/pidf : presence/pidf : tuple/pidf : status/pidf :basic </changed> </trigger> </filter> </filter-set>

—boundaryl— Content-Type: application/ vnd.oma. rls-notification-rule+xml

<?xml version="1.0" encoding="UTF-8"?>

<rule-set xmlns="urn:ietf :params:xml:ns:rls-notification-rule"> <ns-bindings>

<ns-binding prefix="rl" urn= "urn:ietf :params :xml :ns :resource-lists"/> </ns-bindings> <rule id="123"> <trigger>

<rl:entry uri="sip:bill@example .com" /> <rl:entry uri="sip: joeSexample .org" /> <rl:entry uri="sip: tedSexample .org" /> </rl:list> </operation> </trigger> </rule> </rule-set> -boundaryl—

Meanwhile, handling of the RLS Notification Rules in the RLS is as follows. The RLS can support RLS Notification Rules set by the Watcher in the SIP SUBSCRIBE request to a Presence List. The RLS, on receiving the SUBSCRIBE request to a presence list with RLS Notification Rules, follows the procedures as below.

First, the RLS supports the Content-Type "application/vnd.oma.rls- notification-rules+xml" as described in table 6.

Upon receiving the SIP SUBSCRIBE request with the RLS Notification Rules, the RLS validates the embedded conditions and stores the RLS Notification Rules. Then, the RLS does not include the RLS notification rules to the SIP SUBSCRIBE requests since the RLS Notification Rules is only valid for the RLS.

Thereafter, RLS buffers the received notifications from the list of presentities and deliver them to the Watcher when the specified conditions are met.

Claims

What is claimed is:

1. A method for providing RLS (Resource List Server) Notification Rule for multiple presentities, comprising the steps of: a watcher sending subscription requests for requesting presence information of a group of presentities; an RLS delivering the subscription requests to the group of the presentities and receiving notifications about corresponding presence information from the group of the presentities; the RLS determining if stored RLS Notification Rules are met; and the RLS composing the notified presence information when the RLS Notification Rules are met and sending the composite presence information to the watcher.

2. The method for providing RLS Notification Rule for multiple presentities as claimed in claim 1 , further comprising the steps of: the RLS determining if RLS Notification Rules specified by the watcher are included in the subscription requests; and the RLS storing the specified RLS Notification Rules when the specified RLS Notification Rules are included in the subscription requests.

3. The method for providing RLS Notification Rule for multiple presentities as claimed in claim 1 , further comprising the steps of: the RLS sending the subscription requests to operators of corresponding services to which the group of the presentities is subscribing; the operators of the corresponding services sending the subscription requests to the group of the presentities; the operators of the corresponding services being provided with presence information from the group of the presentities; and the operators of the corresponding services sending notification to the RLS when there are presentities of which presence information is changed in the group of the presentities.

4. The method for providing RLS Notification Rule for multiple presentities as claimed in claim 1, wherein the subscription requests use SUBSCRIBE, and the notifications use NOTIFY.

5. The method for providing RLS Notification Rule for multiple presentities as claimed in claim 1, wherein operation types of the RLS Notification Rules are divided into cases of receiving notifications from all presentities of a list specified by the watcher, more than a predetermined number of notifications from presentities of a list specified by the watcher, less than a predetermined number of notifications from presentities of a list specified by the watcher, and a predetermined number of notifications from presentities of a list specified by the watcher.

6. A system for providing RLS (Resource List Server) Notification Rule for multiple presentities, comprising: a watcher operable to send subscription requests for requesting presence information of a group of presentities; an RLS operable to deliver the subscription requests to the group of the presentities, to receive corresponding presence information from the group of the presentities, to determine if the stored RLS Notification Rules are met by the corresponding presence information, to compose the notified presence information when the RLS Notification Rules are met, and to send the composite presence information to the watcher.

7. The system for providing RLS Notification Rule for multiple presentities as claimed in claim 6, wherein the RLS is further operable to determine if RLS Notification Rules specified by the watcher are included in the subscription requests, and to store the RLS Notification Rules when the RLS Notification Rules are included in the subscription requests.

8. The system for providing RLS Notification Rule for multiple presentities as claimed in claim 6, further comprising one or more operators having presentities of the group who are subscribing thereto, the one or more operators sending the subscription requests to the presentities of the group who are subscribing thereto when the subscription requests is received from the RLS, being provided with presence information from the group of the presentities, and sending notifications to the RLS when there are presentities of which presence information is changed in the group of the presentities.

9. The system for providing RLS Notification Rule for multiple presentities as claimed in claim 6, wherein the subscription requests use SUBSCRIBE, and the notifications use NOTIFY.

10. The system for providing RLS Notification Rule for multiple presentities as claimed in claim 6, wherein operation types of the RLS Notification Rules are divided into cases of receiving notifications from all presentities of a list specified by the watcher, more than a predetermined number of notifications from presentities of a list specified by the watcher, less than a predetermined number of notifications from presentities of a list specified by the watcher, and a predetermined number of notifications from presentities of a list specified by the watcher.