KR20060068986A - Network control method and network apparatus for exchanging buddy list information among different presence systems - Google Patents

Abstract

The present invention relates to a network control method and a network device. In particular, the present invention relates to a network control method and a network control device capable of exchanging friend list information between heterogeneous presence systems.

The present invention includes a first presence client including a first XCAP client module, a second XCAP client module, and a method for providing communication information using the first protocol to provide status information of friends to the first presence client. A first presence server, a second presence client including a third XCAP client module, and a fourth XCAP client module are included, and communication is performed using a second protocol to provide status information of friends to the second presence client. And a second presence server configured to perform XCAP communication with the first to fourth XCAP client modules, to provide a friend list according to their requests, and to store and manage a friend list. do.

Presence, friend list registration, friend list management server, SIP

Description

Network control method and network device for exchanging friend list information between heterogeneous presence systems {NETWORK CONTROL METHOD AND NETWORK APPARATUS FOR EXCHANGING BUDDY LIST INFORMATION AMONG DIFFERENT PRESENCE SYSTEMS}

1 is a diagram illustrating a network device according to the prior art for providing instant messaging and presence services.

FIG. 2 is a network device according to an embodiment of the present invention comprising a first presence system providing a SIP-based first presence service and a second presence system providing a second presence service using its own protocol. It shows the schematic diagram of.

FIG. 3 is a diagram for describing in detail an XML Configuration Access Protocol (XCAP) as a protocol that can use a friend list for exchange. XCAP is a protocol under development in the Internet Engineering Task Force (IETF).

4 is a diagram showing an example of information on a user and a server of a network device according to an embodiment of the present invention;

FIG. 5 is a diagram illustrating an example of detailed operations of the network apparatus when a user and a server are determined as shown in FIG. 4.

The present invention relates to a network control method and a network device. In particular, the present invention relates to a network control method and a network control device capable of exchanging friend list information between heterogeneous presence systems.

IMPP (Instant Message and Presence Protocol) services have been developed and provided by domestic and foreign companies that allow multiple users to access each other to check the status information of the other party and to communicate with each other such as instant message exchange and file transfer. Here, the status information may include, for example, information about whether a specific user is online or offline, whether the specific user has the possibility of communication, instant messaging, voice on IP (VoIP), mobile phone, email, game, etc. It may include information on whether there is a willingness to communicate using the communication capability, whether there is communication capability (capability) such as voice mail capability, video capability, and mobility. Representative examples of IMMP services include MSN Messenger and ICQ Messenger. In addition, many service providers have developed their own instant messaging and presence services. A user of IMPP service can register as a member and register friend list with a service provider. In order to register a friend list, a friend listed in the friend list must already be registered as a member of the service provider. When the first user registers the second user as a friend, a notification is sent to the second user that a request to register as a friend has been received, and whether or not the presence service will be provided or rejected to the first user at the will of the second user. Is determined. If the second user allows a friend to be added, services such as instant message and file transfer and internet phone service may be provided to the two users.

Session Initiation Protocol (SIP) technology is used as a communication protocol for establishing and deleting a connection between a user of a presence service and a presence server in an Internet environment. SIP is a technology under development in the IETF that provides the communications capabilities required for instant messaging and presence services, including Internet Telephony. An example of a SIP-based presence service is MSN Messenger. In contrast, ICQ messenger provides a presence service using its own protocol rather than SIP.

1 is a diagram illustrating a network device according to the prior art for providing instant messaging and presence services.

Referring to FIG. 1, a network device according to the related art includes a first presence system 100 in which a first service provider provides a presence service, and a second presence system 200 in which a second service provider provides a presence service. ). The first presence system 100 includes a first presence server 110 and a plurality of first presence clients 120. The first presence server 110 and the first presence client 120 exchange state information through SIP-based communication. The first presence server 110 constructs and manages its own database for managing a friend list used in the first presence system 100. The second presence system 200 includes a second presence server 210 and a plurality of second presence clients 220. The second presence server 210 and the second presence client 220 exchange state information using a body protocol. The second presence server 210 constructs and manages its own database for managing a friend list used in the second presence system 200.

Such a network device providing a presence service according to the prior art has a problem in that interoperability between heterogeneous presence systems is not secured. That is, when one user wants to use the presence service, there is a problem in that the presence service can be used only for users registered with the same service provider. This generally occurs because one service provider only manages user information registered to it, and does not receive or manage user information registered to other service providers. In summary, the presence service according to the related art has a disadvantage that a user who uses the presence service must register a friend list differently through an interface provided by each service provider. For example, to register, add or delete a friend list of MSN Messenger, you need to register through the user interface provided by MSN Messenger. To register, add or delete a friend list in ICQ Messenger, you can also use ICQ Messenger program. There is a problem that you need to install and manage your friends list through the user interface.

Accordingly, an object of the present invention is to provide a network control method and a network device capable of exchanging friend list information between different service providers, that is, heterogeneous presence systems.

As a technical means for achieving the above object, a first aspect of the present invention comprises a first presence client including a first XCAP client module, a second XCAP client module, by performing communication using the first protocol A first presence server providing status information of friends to the first presence client, a second presence client including a third XCAP client module, and a fourth XCAP client module, and communicating using a second protocol. And a second presence server for providing status information of friends to the second presence client, and performing XCAP communication with the first to fourth XCAP client modules, and providing a friend list according to their requests. Provides a network device including an XCAP server for storing and managing lists.

A second aspect of the present invention provides a method of providing a communication system comprising: (a) a first presence client registering a friend list with an XCAP server via a first XCAP client module; and (b) the first presence client communicating using a first protocol. Transmitting a subscription message to a first presence server to establish a connection, (c) the first presence server obtaining the friend list from the XCAP server through a second XCAP client module, and (d) the first presence server provides a network control method comprising retrieving status information of friends included in the friend list and transferring the status information of the friends to the first presence client.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. However, embodiments of the present invention may be modified in various forms, and the scope of the present invention should not be construed as being limited by the embodiments described below. Embodiments of the present invention are provided to more fully explain the present invention to those skilled in the art.

2 illustrates a first presence system 300 providing a SIP-based first presence service and a second presence system 400 providing a second presence service using its own protocol. A configuration diagram of a network device according to an embodiment is shown.

Referring to FIG. 2, the network device includes a first presence system 300, a second presence system 400, and an XCAP server 510 managing a friend list. The first presence system 300 includes a first presence server 310 on which the XCAP client module 520 is mounted, and a plurality of first presence clients 320 on which the XCAP client module 520 is mounted. The second presence system 400 includes a second presence server 410 on which the XCAP client module 520 is mounted, and a plurality of second presence clients 420 on which the XCAP client module 520 is mounted.

The SIP-based first presence client 320 notifies the first presence server 310 of its own status information, and also requests the first presence server 310 of friends' status information and the first presence server. Receiving the status information of the friends from the 310 to determine the current status of the friends and can talk to each other through the instant messaging service with friends online. The SIP-based first presence server 310 requests the list of friends requested by the first presence client 320 to the XCAP server 510 through its XCAP client module 520 and is sent in response. It is responsible for requesting the status information of each friend based on the list of and passing the collected status information of the friends to the first presence client (320).

The second presence server 410 and the second presence client 420 operate in the same manner as the first presence server 310 and the first presence client 320, except that the protocol is a SIP-based protocol. The difference is that other protocols, for example, use their own.

The XCAP client module 520 receives the friend list of the presence clients 320 and 420 by using a graphical user interface (GUI), and registers the received friend list to the XCAP server 510 using the HTTP protocol. It also provides the ability to import, delete and add a list of registered friends. The XCAP server 510 provides a friend list requested from the presence client 320 or 420 or the presence server 310 or 410, or registers a friend list, receives a request for adding or deleting a friend, and performs a corresponding service. Provides whether the service request succeeded or failed.

As an interworking mechanism between the SIP-based first presence system 300 and the XCAP systems 510 and 520, the mechanism for registering and importing a friend list is as follows.

(1-1) The first presence client 320 establishes a connection with the first presence server 310 to receive the presence service.

(1-2) When the setting is completed, the first presence client 320 drives its own XCAP client module 520 through the GUI to register a friend list and inputs a list of friends who want to know the status information. The input list of friends may be a list of friends of the first presence service (e-mail type) or a list of friends of the second presence service (ID type). These lists may be registered separately or mixed together depending on the service.

(1-3) The XCAP client module 520 connects to the XCAP server 510 managing the friend list with the HTTP PUT method to register the input friend list.

(1-4) The XCAP server 510 managing the friend list stores the list of friends received from the first presence client 310 in an internal database managed by the user.

(1-5) The first presence client 510 transmits a subscribe message to the first presence server 520 in order to know status information of friends.

(1-6) The first presence server 520 uses its XCAP client module 510 to obtain a friend list specified by the user before requesting status information of the friends specified by the first presence client 510. Receive a list of friends through the HTTP GET method.

(1-7) The first presence server 310, which has obtained a friend list including address information of registered friends, obtains the status information of each friend through a database managed by itself based on this information. 1 Send a message to the presence client 320 and receives a Notify message in response.

FIG. 3 is a diagram for describing in detail an XML Configuration Access Protocol (XCAP) as a protocol that can use a friend list for exchange. XCAP is a protocol under development in the Internet Engineering Task Force (IETF).

Referring to FIG. 3, the XCAP is a protocol that allows the client 520 to read, write, and modify application configuration Extensible Markup Language (XML) data stored in the server 510. Hypertext Transfer Protocol (HTTP) is used to handle XML data documents. In addition, for this purpose, XCAP provides a method of mapping an XML document, an element, an attribute, and the like into an HTTP uniform resource identifier (URI). Examples of HTTP methods include the PUT method, the DELETE method, and the GET method. The PUT method is a method for requesting registration and addition of a friend list, the DELETE method is a method for requesting a friend deletion, and the GET method is a method for requesting a friend list.

The XCAP protocol can be used for many applications and can be used not only to manage friend lists in presence services, but also when building conference application systems on the Internet. It can also be used to fetch a list and send a request to attend a meeting during a conference.

4 is a diagram showing an example of information on a user and a server of a network device according to an embodiment of the present invention;

Referring to FIG. 4, User1 and User2 are registered as a user based on a SIP-based first presence server, and User3 and User4 are registered as a user to a second presence server. In addition, the user of the first service is represented by the location information by the email address, the user of the second service is represented by the location information by the ID. 4, the location address of each server is represented. In addition, the conference information that users want to participate is assumed to be conference@etri.re.kr.

FIG. 5 is a diagram illustrating an example of detailed operations of the network apparatus when a user and a server are determined as shown in FIG. 4.

Referring to FIG. 5, the friend list registration method of the SIP-based first presence client 320 equipped with the XCAP client module 520 is as follows.

(2-1) User1 of the first presence client 320 logs in and sends a message of HTTP PUT "Friend" to the XCAP server 510 to register his friend list, thereby creating a new room called "Friend." The XCAP server 510 transmits that the "Friend" room is well made to the XCAP client 520 of User 1 through the "200 OK" message (S11). At this time, the request transmitted from the XCAP client module 510 of User1 to the XCAP server 510 is as follows.

PUT

http://xcap.example.com/services/resource-lists/users/bill/fr.xml HTTP / 1.1

Content-Type: application / resource-lists + xml

<resource-lists xmlns = "urn: ietf: params: xml: ns: resource-lists">

<list name = "friends">

</ list>

The response from the XCAP server 510 to the XCAP client module 510 of User1 is as follows.

HTTP / 1.1 200 OK

Etag: "wwhha"

Content-Type: application / resource-lists + xml

(2-2) User1 transmits a registration message to register his friend list to XCAP server 510 in a room called "Friend" and receives "200 OK" from XCAP server 510 that the registration is successful ( S11). At this time, the request transmitted from the XCAP client module 510 of User1 to the XCAP server 510 is as follows.

PUT

http://xcap.example.com/services/resource-lists/users/bill/fr.xml

/ ~~ / resource-lists / list% 5b @ name =% 22friends% 22% 5d / entry HTTP / 1.1

Content-Type: application / xcap-el + xml

<entry uri = "First Service Messenger Friend1@example.com">

<display-name> Bob Jones </ display-name>

</ entry>

<entry uri = "Second Service Messenger Friend 2@example.com">

<display-name> Bob Jones </ display-name>

</ entry>

The response from the XCAP server 510 to the XCAP client module 510 of User1 is as follows.

HTTP / 1.1 200 OK

Etag: "wwhha"

Content-Type: application / resource-lists + xml

(2-3) When the friend list registration is completed, User1 transmits a SIP SUBSCRIBE message to the first presence server 310 to request the presence information of his friends, and the first presence based on the SIP. The server 310 establishes a connection with the first presence server 310 by delivering a "200 OK" message (S21). At this time, the request transmitted from User1 to the first presence server 310 is as follows.

SUBSCRIBE sip: pres@sip.etri.re.kr SIP1.0

From: sip: user1@sip.etri.re.kr

To: sip: pres@sip.etri.re.kr

(2-4) The first presence server 310 brings the user list of the user1 to the XCAP server 510 using the HTTP GET message to obtain the friend list of the user1 (S31).

At this time, the request transmitted from the XCAP client module 520 of the first presence server 310 to the XCAP server 510 is as follows.

GET

http://xcap.example.com/ user 1 "Friend"

(2-5) The XCAP server 510 transmits the friend list of User1 to the SIP-based first presence server 310 as a "200 OK" message (S31). The response transmitted from the XCAP server 510 to the XCAP client module 520 of the first presence server 310 is as follows.

HTTP / 1.1 200 OK

Etag: "wwhha"

Content-Type: application / resource-lists + xml

<entry uri = "First Service Messenger Friend1@example.com">

<display-name> Bob Jones </ display-name>

</ entry>

<entry uri = "Second Service Messenger Friend 2@example.com">

<display-name> Bob Jones </ display-name>

</ entry>

(2-6) The SIP-based first presence server 310 retrieves the friend's status information based on the friend list received from the XCAP server 510 and delivers the friend's status through the SIP NOTIFY message. Presence service is made by delivering "200 OK" in the sense of well received (S21). The message transmitted to User1 in the SIP-based first presence server 310 is as follows.

NOTIFY sip: pres@sip.etri.re.kr SIP1.0

From: pres@sip.etri.re.kr

To: sip: sip: user1@sip.etri.re.kr

Referring to FIG. 5, in a state where User1 receives state information of registered friends from the first presence server 310, the second presence client 420 based on a protocol based on the XCAP client module 520 is installed. User1 accesses to add friend list as follows.

(3-1) User1 accessing the second presence client 420 uses the XCAP client module 520 of his / her own to obtain a friend list registered in the SIP-based first presence client 320. The connection request is made using the message to the XCAP server 510, and the XCAP server 510 transmits a list of friends registered on the SIP base as "200 OK" in response (S31). At this time, the request message transmitted from the XCAP client module 520 of User1 to the XCAP server 510 is as follows.

GET

http://xcap.example.com/ user 1 "Friend"

The response message transmitted from the XCAP server 510 to the XCAP client module 520 of User1 is as follows.

HTTP / 1.1 200 OK

Etag: "wwhha"

Content-Type: application / resource-lists + xml

<entry uri = "First Service Messenger Friend1@example.com">

<display-name> Bob Jones </ display-name>

</ entry>

<entry uri = "Second Service Messenger Friend 2@example.com">

<display-name> Bob Jones </ display-name>

</ entry>

(3-2) This User1 adds a friend list to the XCAP server 510 with his XCAP client module 520, this time to add a friend list of the first presence service in the second presence client 420. In order to transmit the HTTP PUT message, the XCAP server 510 transmits the message "200 OK" that the friend list has been added (S51). The request message transmitted from the XCAP client module 520 of User1 to the XCAP server 510 is as follows.

PUT

http://xcap.example.com/services/resource-lists/users/bill/fr.xml

/ ~~ / resource-lists / list% 5b @ name =% 22friends% 22% 5d / entry HTTP / 1.1

Content-Type: application / xcap-el + xml

<entry uri = "First Service Messenger Friend3@example.com">

<display-name> Bob Jones </ display-name>

</ entry>

(3-3) The XCAP server 510 transmits a NOTIFY message to the SIP-based first presence server 310 that the friend list of User1 has been added (S41). The message transmitted from the XCAP server 510 to the SIP-based first presence server 310 is as follows.

Notify

Body

     <user> Add 1st service messenger friend </ user>

(3-4) The SIP-based first presence server 310 transmits "200 OK" to the XCAP server 510, meaning that the NOTIFY for the friend list is well received (S41).

(3-5) The SIP-based first presence server 310 provides status information of the newly added friend 3 to the first presence client 320 of User1 (S21). The message provided from the SIP-based first presence server 310 to the first presence client 320 of User1 is as follows.

NOTIFY sip: pres@sip.etri.re.kr SIP1.0

From: pres@sip.etri.re.kr

To: sip: sip: user1@sip.etri.re.kr

<user> Friend 3's status information (online) <user>

(3-6) The first presence client 320 of User1 transmits a "200 OK" message to the SIP-based presence server 310 in the sense that the status information of the friend 3 is well received (S21).

Although the technical spirit of the present invention has been described in detail according to the above preferred embodiment, it should be noted that the above-described embodiment is for the purpose of description and not of limitation. In addition, it will be understood by those skilled in the art that various modifications are possible within the scope of the technical idea of the present invention.

The network device and the network control method according to the present invention can freely register, add and delete their friends list even if a user who is subscribed to a heterogeneous presence system logs in from any system and the information is transmitted to the presence server in real time The advantage is that it can provide updated status information of friends. The present invention has the advantage that it is possible to induce the activation of the presence service by freely managing its own friend list in any presence system by using a common communication protocol away from the current list of friend list management in the localized presence system.

Claims (10)

A first presence client comprising a first XCAP client module; A first presence server including a second XCAP client module, the first presence server configured to perform communication using a first protocol to provide status information of friends to the first presence client; A second presence client comprising a third XCAP client module; A second presence server including a fourth XCAP client module, and performing communication using a second protocol to provide status information of friends to the second presence client; And And an XCAP server that performs XCAP communication with the first to fourth XCAP client modules, provides a friend list according to their request, and stores and manages the friend list. The method of claim 1, And the first presence client informs the first presence server of its status information. The method of claim 1, And the first presence client requests status information of friends from the first presence server and receives status information of friends from the first presence server. The method of claim 1, The first presence server requests the list of friends to request the list of friends when the first presence client requests status information of the friends through the second XCAP client module, and the list of friends transmitted in response. Requesting status information from each friend based on the received information, and transmitting the collected status information of the friends to the first presence client. The method according to any one of claims 1 to 4, The XCAP client module performs at least one of registering a friend list to the XCAP server, deleting a friend list from the XCAP server, adding a friend list to the XCAP server and reading a friend list from the XCAP server using the HTTP protocol. Characterized in that the network device. (a) the first presence client registering a friend list with the XCAP server through the first XCAP client module; (b) the first presence client communicating using a first protocol to deliver a subscription message to the first presence server to establish a connection; (c) the first presence server fetching the friend list from the XCAP server via a second XCAP client module; And (d) the first presence server searching for the status information of the friends included in the friend list and transmitting the status information of the friends to the first presence client. The method of claim 6, before step (a) and (e) creating a virtual room in which the first presence client can register the friend list with the XCAP server through the first XCAP client module. The method of claim 6, (f) the second presence client fetching the friend list from the XCAP server via a third XCAP client module; And (g) the second presence client further comprises adding a new friend list to the friend list to the XCAP server through the third XCAP client module. The method of claim 8, (h) the XCAP server notifying the first presence server through the second XCAP client module that a new friend list has been added to the friend list; And (i) the first presence server further includes transmitting status information of the added new friends to the first presence client. The method of claim 8 or 9, And the second presence client communicates with the second presence server using a second protocol.

Images