KR101378217B1 - System and method for providing rls notification rule for multiple presentities - Google Patents

Abstract

The present invention proposes a system and method that allows a user to specify a choice as to when and how RLS should issue a NOTIFY request. As a result, optimize presence notifications by avoiding unnecessary and sometimes annoying notifications. This is possible by allowing the user to specify RLS notification rule criteria in the initial SIP SUBSCRIBE. Accordingly, the present invention supports the watcher to specify a filter in the SIP SUBSCRIBE. In addition, the present invention dictates the behavior of the expected RLS when such RLS notification criteria rules exist in the SIP SUBSCRIBE.

RLS, Notification, Rules, Presence, Presentity

Description

SYSTEM AND METHOD FOR PROVIDING RLS NOTIFICATION Criteria FOR MULTIPLE PRESENTATIONS {SYSTEM AND METHOD FOR PROVIDING RLS NOTIFICATION RULE FOR MULTIPLE PRESENTITIES}

The present invention relates generally to mobile communications. The present invention is a Session Initiation Protocol, such as Instant Messaging, Push to talk over Cellular, Converged IP Messaging, and any other future application that uses presence services. For various OMA development applications. The present invention relates to an application that subscribes to and receives notifications about presence information. More specifically, the present invention relates to a Responsive List Server (RLS) notification criterion for multiple presentations.

The presence system architecture helps other users share the presence information of any user. Presence information is basically information related to a user, for example, presence information related to a specific application such as the user's current location, the user's contact information, and the user's availability of Instant Messaging (IM). . In the current technology level, a user must subscribe to the presence information of another user in order to receive the presence information of another user. The requested user then authorizes the requesting user to receive his presence information. The presence server object maintains the presence subscription of the requesting user and stores the presence information of the requesting user. If the presence information of the requested user is changed, the presence server immediately sends a notification to the subscribed / requested user for the period of validity of the subscription. In this case, another user / requested user whose presence information is of interest is called a presence, and a user / requested user who subscribes to and receives the presence information is called a watcher. A watcher is basically a user who is authorized to view the presence information of another user. SIP SUBSCRIBE and SIP NOTIFY methods are used for subscription and notification.

There are many presence attributes that a watcher can subscribe to, but the watcher may not be interested in all the presence information of the presentity. Accordingly, by specifying a filter, the watcher can receive only the necessary presence information. These presence information filter criteria are defined in IEFT Draft IETF RFC 4660 "Function Description of Event Notification Filtering". Filters run on the presence server of the presentity.

In addition, a user who registers with the presence service may subscribe to the presence information of the presentity of an individual or a group. When subscribing to the presence information of a group's presentity, SIP SUBSCRIBE is responsible for enumerating the presenter's collection of resources, as defined in IETF RFC 4662, "Extended Session Initiation Protocol (SIP) Event Notification for Resource Lists". It may consist of a URI list, or a URI list as defined in the IETF draft draft-ietf-sip-uri-list-subscribe "Subscribing to a Resource List with Requests in Session Initiation Protocol (SIP)".

Notifications may be delivered to individual watchers or collected from the group's presence through a Resource List Server (RLS). The URI-listing service is such a SIP as defined in IEFT draft draft-ietf-sipping-uri-services "Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) -Listing Service". It will handle SUBSCRIBE and SIP NOTIFY. If present, it prescribes the presence server's behavior to run on the presence server's presence server to generate notifications to the RLS.

At the current technology level of the uri-list service, the watcher receives complex notifications about the group's presence from the RLS. This composite notification from the RLS includes a collection of notifications from each of the group's presentities. There is no association between a notification received from one user and a notification received from another user.

Hereinafter, an operation procedure for the above case will be described with reference to FIGS. 1 and 2.

For example, consider the case where Adam wants to invite Bill, Joe, and Ted to a meeting, and they both think they should attend the meeting. Adam sends a request to join, including how to send a notification only when both Bill and Joe and Ted's presence information are "OPEN."

Bill and Ted's presence information is "CLOSED" and Joe's presence information is "OPEN". Referring to Fig. 1, Bill 50, the presentity, subscribes to the same operator service as Adam 10, a watcher belonging to the home network. On the other hand, the presence Joe 60 and Ted 70 subscribe to the services of other operators belonging to the remote network.

1 and 2, the client 10 of the watcher Adam, in step 100, filters a single list presence subscription request (according to draft-ietf-sip-uri-list-subscribe) according to IETF RFC 4660. ) Is sent to the Resource List Server (hereinafter referred to as RLS) 20. Here, SUBSCRIBE is used for subscription request. The list includes a request to join Bill and Joe and Ted, and the filter criteria stipulate that a notification be sent when Bill and Joe and Ted's presence information is "OPEN".

Accordingly, the RLS 20 transmits the subscription request including the filter in Presence-Server-A 30 and Presence-Server-B 30 in steps 105 and 110. The following description is provided to Presence-Server-B) 40. Then, the Presence-Server-A 30 receives the PUBLISH from the bill 50 in step 115 and monitors the presence information of the bill 50. The Presence-Server-A 30 filters the presence information if necessary in step 120 and then sends a notification only when Bill 50 changes its presence to "OPEN" in step 125. Here, NOTIFY is used for notification. Similarly, the Presence-Server-B 40 monitors the presence information of the Joe 60 after receiving the PUBLISH from the Joe 60 in step 130. The Presence-Server-B 40 filters the presence information if necessary in step 135, and immediately sends a notification to the RSL 20 in step 140 if the presence information of the group 60 is "OPEN". Accordingly, the RLS 20 combines the notification in step 145 and transmits the notification to the adam 10 in step 150 (after considering the notification speed, etc.) so that the Adam 10 knows that the group 60 is "OPEN." . In the case of Ted 70, the Presence-Server-B 40 receives the PUBLISH from the Ted 70 at step 155 to monitor the presence information of the Ted 70, and filters the presence information if necessary at step 160. After that, Ted 70 sends a notification in step 165 only when he changes his presence to "OPEN." Accordingly, the RLS 20 sends a notification to the Adam 10 in step 170.

In this way, Adam will receive Bill, Joe, and Ted's "OPEN" presence information through multiple notifications. In order to satisfy the above use case, Adam must directly monitor whether the arriving notifications meet the requirement that both Bill, Joe and Ted should be "OPEN". Accordingly, Adam 10 monitors the multiple notifications in step 175. Then, if the presence information for both Bill, Joe, and Ted is "OPEN," Adam invites them to the meeting.

However, if one user subscribes to the presence information of the group's presentity, he or she may only want to be notified of the presence of the other user rather than receiving information gathered from that presentity set. In other words, the user may want to select and specify when and how the RLS will generate notifications. Current technology does not allow for such use cases.

In addition, in the case of subscribing to the presence information of the presentity of the group, if a notification is received every time the presence information is changed from a plurality of users, it may cause a large load. In addition, every time a notification is received, the presence notification needs to be optimized by avoiding unnecessary and sometimes annoying notifications.

However, once the watcher receives the presence information from the group's presence, the client must then evaluate the current use cases for which the client must evaluate the user-specified notification criteria (stored in the client) before presenting the presence information to the user. Technology may also be implemented by client implementations. However, the authors do not know such a client implementation.

Accordingly, the present invention provides a system and method that allows a user to specify a choice as to when and how RLS should issue a NOTIFY request.

In order to achieve the above, the present invention provides a method for providing a resource list server (RLS) notification criterion for multiple presentations, wherein the RLS receives a subscription request for requesting presence information of group presentations from a watcher. Determining whether the RLS notification criteria stored by the RLS are satisfied after the RLS forwards the subscription request to the presenters of the group and is informed of the presence information from the presenters of the group. And when the RLS satisfies the RLS notification criteria, integrating the informed presence information and transmitting the combined presence information to the watcher.

In addition, the present invention is a system for providing a resource list server (RLS) notification criteria for multiple presenting, the watcher for transmitting a subscription request for requesting the presence information of the group's presentations, and the group's presentations If the presence information of the group is notified after forwarding the subscription request to the network, it is determined whether the stored RLS notification criteria are satisfied, and when the RLS notification criteria are satisfied, the notified presence And RLS for integrating the information and transmitting the information to the watcher.

The present invention has the advantage of optimizing the notification by allowing the user to specify when and how the RLS should generate the notification. In addition, the present invention not only provides a good user experience but also provides the advantage of reducing service costs.

The present invention proposes a system and method that allows a user to specify a choice as to when and how RLS should issue a NOTIFY request. As a result, optimize presence notifications by avoiding unnecessary and sometimes annoying notifications. This is possible by allowing the user to specify RLS notification criteria in the initial SIP SUBSCRIBE. Accordingly, the present invention supports the watcher to specify a filter in the SIP SUBSCRIBE. In addition, the present invention dictates the behavior of the expected RLS when such RLS notification criteria are present in the SIP SUBSCRIBE.

RLS  Notification standard:

Allows the user to specify RLS notification criteria in the initial SIP SUBSCRIBE, which may include a list of URIs in a format as specified in "draft-ieft-sip-uri-list-subscribe" or as specified in RFC 4662. It may include a URI of a URI list as present. The format of the RLS notification criterion (hereinafter referred to as rls-notification-rule) may be defined by a content type and may be, for example, "application / rls-notification-rule". The criteria depend on the "operation type". The operation type can be divided into “ALL”, “ATLEAST”, “ATMOST”, “EQUALS” and others. An exemplary format of the operation types is described below.

First, an exemplary format when the operation type is "ALL" is shown in Table 1 below.

<operation type = "ALL">
<list>
:
:
</ list>
</ operation>

The example of Table 1 above means that the watcher is interested in the notification only when the notification is received from all of the users of the list determined in the criteria according to the operation type.

In addition, an exemplary format when the operation type is "ATLEAST" is shown in Table 2 below.

<operation type = "ATLEAST" number = "x">
<list>
:
:
</ list>
</ operation>

The example in Table 2 above means that the watcher is interested in the notification only when "x" or more notifications are received from the users in the list defined by the reference.

In addition, an exemplary format when the operation type is "ATMOST" is shown in Table 3 below.

<operation type = "ATMOST" number = "x">
<list>
:
:
</ list>
</ operation>

The example in Table 3 above means that the watcher is interested in the notification only when "x" or less notifications have been received from the list of users defined in the standard.

In addition, an exemplary format when the operation type is "EQUALS" is shown in Table 4 below.

<operation type = "EQUALS" number = "x">
<list>
:
:
</ list>
</ operation>

The example in Table 4 above means that the watcher is interested in the notification only when x notifications are received from the users in the list defined by the standard.

In the example of Tables 1 to 4 above, the <list> element is optional in all the notification criteria described above, and if this element is not present, the operation is applied to all the presentities mentioned in the resource list.

The present invention does not limit the RLS notification criteria to the above-described operation type, and the RLS notification criteria may include any user definition for controlling the RLS notification.

RLS Save notification criteria:

When a URI-list receives a SIP SUBSCRIBE request that includes a rls-notification-rule, the URI list service creates a subscription according to RFC 4662 and receives a change in resources in the created dialog. The rls-notification-rule is associated with the dialog and is stored by the UIR listing service.

RLS Assess notifications based on criteria:

When a presence notification is received from multiple resources, the URI list service evaluates the notification according to the rls-notification-rule, and delivers the presence notification to the watcher only in the case of successful evaluation. Otherwise, no notification will be sent to the watcher.

Hereinafter, an operation sequence according to the present invention will be described with reference to FIG. 3 in relation to the use case considered in the present invention. In FIG. 3, it is assumed that the presence information of Bill and Ted is "CLOSED", and the presence information of Joe is "OPEN". Bill also subscribes to the same service operator as Adam, while Joe and Ted are subscribed to other service operators.

Referring to FIG. 3, in step 300, Adam 10 includes a single list presence subscription request (according to draft-ietf-sip-uri-list-subscribe) and a filter (according to IETF RFC 4660). The list includes a request to join Bill 50 and Joe and Ted 60 & 70.

The filter criteria stipulate the notification when Bill 50 and Joe and Ted 60 & 70's presence information is "OPEN". Adam 10 also rls-notification-rule instructing RLS 20 to send a notification to Adam 10 only if it has received presence information from both Bill 50 and Joe and Ted 60 & 70. To define.

The RLS 20 determines whether there is a rls-notification-rule in step 305 and stores it, and then, in steps 310 and 315, the RLS 20 stores a subscription request including a filter in the service operators, that is, the Presence-Server-A 30 and the Presence. Forward to Server-B 40. At this time, since the rls-notification-rule is valid only for the RLS 20, the rls-notification-rule is excluded from the subscription request sent to the Presence-Server-A 30 and the Presence-Server-B 40.

The Presence-Server-A 30 receives the PUBLISH from the Bill 50 in step 320 and monitors the presence information of the Bill 50. In step 325, the Presence-Server-A 30 filters the presence information if necessary, and Bill then displays his own presence. The notification is sent in step 330 only when the legend is changed to "OPEN". NOTIFY is used for this notification.

Similarly, Presence-Server-B 40 monitors the presence information of Joe and Ted 60 & 70. Accordingly, the Presence-Server-B 40 receives the PUBLISH from the pair 60 in step 335 and filters the presence information as needed in step 340. Since the presence information of the pair 60 is "OPEN", the notification for the presence information of the pair 60 from the Presence-Server-B 40 is immediately transmitted to the RSL 20 in step 345. In step 350, the RLS 20 checks whether the RLS notification criterion is satisfied. However, since the presence information of Ted 70 is not yet "OPEN", the notification is not made because the RLS notification criteria are not satisfied.

Since the RLS 20 receives the notification from Bill 50 and Joe 60 but has not received the presence information from Ted 70, the stored rls-notification-rule is not satisfied. Thus, RLS 20 suspends delivering the notification to Adam 10 until it receives presence information from ted 70.

In the case of Ted 70, the Presence-Server-B 40 receives the PUBLISH from the Ted 70 in step 355 to monitor the presence information of the Ted 70. Accordingly, if the Presence-Server-B 40 filters the presence information when necessary in step 360, and the Ted 70 changes its presence to "OPEN", the notification is sent to the RLS 20 in step 365.

By doing so, the RLS 20 receives the presence information of the ted 70. Accordingly, the RLS 20 determines whether the rls-notification-rule is satisfied in step 370. Since the RLS 20 received the presence information from both Bill 50 and Joe and Ted (60 & 70), the rls-notification-rule is satisfied, so the RLS 20 is notified of the integrated notification in step 375. Send to (10).

Adam 10 thus receives a single notification from RLS 20 on Bill 50 and Joe and Ted 60's " OPEN " presence information. Since the presence information of both Bill 50 and Joe and Ted 60 & 70 is "OPEN", Adam 10 invites them to the meeting.

In order to achieve this, the present invention proposes to make the following changes to the current technology.

First, in case of SIP SUBSCRIBE, the user can define rls-notification-rule in SIP SUBSCRIBE body including subscription to resources listed in SIP, which is sent to RLS or URI list service. In addition, in case of RLS server or URI list service, it plays an additional role of storing rls-notification-rule, and also plays a role of evaluating rls-notification-rule by monitoring presence information arriving from group's presentity. .

Step 1: Change in SIP SUBSCRIBE

An example of how the SIP SUBSCRIBE request is expressed when the conditional criteria is included is shown in Table 5 below.

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 = ie4hbb8t
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

--boundary1
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>
--boundary1--

Content-Type: application / simple-filter + xml

<? xml version = "1.0" encoding = "UTF-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>
<changed from = "CLOSED" to = "OPEN">
/ pidf: presence / pidf: tuple / pidf: status / pidf: basic
</ changed>
</ trigger>
</ filter>
</ filter-set>
--boundary1

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 type = "AND">
<list>
<entry uri = "sip: bill@example.com"/>
<entry uri = "sip: joe@example.org"/>
<entry uri = "sip: ted@example.org"/>
</ list>
</ operation>
</ trigger>
</ rule>
</ rule-set>
--boundary1
-

Step 2: RLS  Changing the Role of the Server or URI List Service

Upon receiving a SIP SUBSCRIBE request with a URI-list containing rls-notification-rule, the URI listing service creates a subscription according to RFC 4662 and receives a change in resources in the created dialog. RLS notification criteria are associated with the dialog and are stored by the UIR listing service. Upon receiving presence notifications from multiple resources, the URI listing service evaluates RLS notifications based on the rls-notification-rule, and forwards the presence notifications to the watchers only in the case of successful evaluations.

In the following description, one of the methods of applying the present invention will be described for illustrative purposes, and the present invention may be applied to other methods.

First, according to the present invention RLS  The notification criteria are as follows.

The watcher may establish some conditions for controlling the triggering of notifications when subscribing to a presence list. Using the RLS notification criteria, the watcher may designate a point in time at which the presence information of the presentity of the group is to be received from the RLS. Whenever a watcher wants to set some criteria while subscribing to a presence list, it may send a SIP SUBSCRIBE request according to IETF RFC 3265 "Sire Initiation Protocol (SIP) -Specific Event Notification" as detailed below. .

If the watcher wants to send the IETF RFC 4660 "functional description of event notification filtering" and RLS notification criteria, include the "multipart / related" value in the content-type header to indicate "application / simple-filter + xml" and " application / vnd.oma / rls-notification-rules + xml "content type. The XML format for specifying the RLS notification criteria has a structure as shown in Table 6 below. That is, Table 6 below defines the XML schema.

<? xml version = "1.0" encoding = "UTF-8"?>
<xs: schema xmlns = "urn: oma: xml: prs: pidf: rls-notification-rule"
xmlns: xs = "http://www.w3.org/2001/XMLSchema"
targetNamespace = "urn: oma: xml: prs: pidf: rls-notification-rule"
elementFormDefault = "qualified">
<xs: import namespace = "http://www.w3.org/XML/1998/namespace" schemaLocation = "http://www.w3.org/2001/xml.xsd"/>
<xs: annotation>
<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: complexType name = "NSBinding">
<xs: attribute name = "prefix" type = "xs: string" use = "required"/>
<xs: attribute name = "urn" type = "xs: anyURI" 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: sequence>
<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]->
<xs: attribute name = "type" type = "xs: string" use = "required"/>
<xs: complexType>
<xs: schema>

In addition, according to the present invention RLS  The notification criteria are structured and described below. Semantics Follow.

The root element <rule-set> may contain any other attribute for extensibility purposes, may contain <ns-bindings> containing namespace bindings, and contains conditions for delivering RLS notifications. Contains one or more <rule-set> elements.

The <ns-bindings> element also contains one or more <ns-binding> elements, each of which contains a binding between the prefix and the namespace in the "prefix" and "namespace" attributes, respectively. This attribute is used to represent a list of URIs to which the condition should apply using the format of the resource-list as described in [RFC4826].

In addition, the <rule> element contains an "id" attribute containing the unique ID of the condition, and does not include or include a <trigger> element containing an action type that triggers an RLS notification. This can include any other element from another namespace.

In addition, the <trigger> element may or may not include an <operation> element containing the operation type to be applied, and may include any other element from another namespace for extensibility purposes.

The <operation> element also contains a "type" attribute that specifies how to apply the triggers for the URIs listed as child elements, and contains a URI of the resource as described in [RFC4826]. It can contain no list> elements or more, and can contain any other elements from other namespaces for extensibility purposes.

An example of an event notification filter based on the RLS notification criteria is shown in Table 7 below.

--boundary1--

Content-Type: application / simple-filter + xml

<? xml version = "1.0" encoding = "UTF-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>
<changed from = "CLOSED" to = "OPEN">
/ pidf: presence / pidf: tuple / pidf: status / pidf: basic
</ changed>
</ trigger>
</ filter>
</ filter-set>

--boundary1

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>
<operation type = "AND">
<rl: list>
<rl: entry uri = "sip: bill@example.com"/>
<rl: entry uri = "sip: joe@example.org"/>
<rl: entry uri = "sip: ted@example.org"/>
</ rl: list>
</ operation>
</ trigger>
</ rule>
</ rule-set>
--boundary1--

Meanwhile, the processing of the RLS notification criteria in the RLS is as follows. RLS may support the RLS notification criteria that Watcher has specified in SIP SUBSCRIBE requests for presence lists.

When RLS receives a SUBSCRIBE request for a Presence List with RLS notification criteria, it follows the procedure below.

First, RLS supports the content-type "application / vnd.oma.rls-notification-rules + xml" as described in Table 6 above. In addition, when the RLS receives the SIP SUBSCRIBE request along with the RLS notification criteria, the RLS evaluates the included conditions and stores the RLS notification criteria. Since the RLS notification criteria are then valid only for this RLS, the RLS does not include the RLS notification criteria in the SIP SUBSCRIBE request to the Presence-Server. The RLS then buffers the notification received from the list of presentities and delivers it to the watcher if the prescribed conditions are met.

1 is a view showing objects associated with a use case considered in the present invention,

2 is a flow chart of the prior art for the use case considered in the present invention,

3 is a flow chart of the present invention for use cases contemplated by the present invention.

Claims (10)

A method for providing resource list server (RLS) notification criteria for multiple presentations, the method comprising: Receiving, by the RLS, a subscription request for requesting presence information of at least one presentity including notification criteria set by the watcher; Receiving, by the RLS, the presence request from the at least one presentity after forwarding the subscription request to the at least one presentity; When the presence information is received, the RLS determining whether a notification criterion set by the watcher is satisfied; And when the RLS satisfies the notification criterion, integrating the presence information and transmitting the presence information to the watcher. The method of claim 1, Determining, by the RLS, whether the subscription request includes a notification standard set by the watcher; And if the notification criteria is included, further comprising the RLS storing the notification criteria. The method of claim 1, Transmitting, by the RLS, the subscription request to corresponding service operators to which the at least one presentity is subscribed; Transmitting, by the corresponding service operators, the subscription request to the at least one presentity; Receiving, by the corresponding service operators, presence information from the at least one presentity; If there is a presence of the presence information is changed among the at least one presentation, the RLS further comprises the step of receiving a notification from the service operator to provide the RLS notification criteria for multiple presentations Way. The method of claim 1, And the subscription request uses SUBSCRIBE, and the notification uses NOTIFY. According to claim 1, The operation type of the notification criteria, Notification from all of the presenters of the list determined by the watcher, a predetermined number or more notifications from the presenters of the list determined by the watcher, a predetermined number or less notifications from the presentations of the list determined by the watcher and the list determined by the watcher The method for providing the RLS notification criteria for multiple presentations, characterized in that it is divided according to the case where a certain number of notifications are received from the presentities of the. A system for providing resource list server (RLS) notification criteria for multiple presentations, A watcher for transmitting a subscription request for requesting presence information of at least one presentity including notification criteria set by the watcher; If the presence information is notified from the at least one presentity after forwarding the subscription request to the at least one presentity, it is determined whether a notification standard set by the watcher is satisfied, and when the notification criterion is satisfied. And an RLS for integrating the presence information and transmitting the RLS to the watcher. The method of claim 6, wherein the RLS, And determining the notification criteria set by the washer in the subscription request, and if the notification criteria are included, storing the notification criteria. 7. The apparatus of claim 6, further comprising one or more corresponding service operators to which the at least one presenter subscribes, When the corresponding service operators receive the subscription request from the RLS, the service operators transmit the subscription request to the presenters subscribed to them, receive the presence information from the subscribed presentities, and the presence of the presentities. And a notification to the RLS if there is a presentity whose information is changed. The method according to claim 6, Wherein the subscription request uses SUBSCRIBE, and the notification uses NOTIFY. The method of claim 6, wherein the operation type of the notification criteria, Notification from all of the presenters of the list determined by the watcher, a predetermined number or more notifications from the presenters of the list determined by the watcher, a predetermined number or less notifications from the presentations of the list determined by the watcher and the list determined by the watcher The system for providing RLS notification criteria for multiple presentations, characterized in that divided according to the case of receiving a predetermined number of notifications from the presentities.

Images