KR20120040625A - Apparatus and method for providing contact status based on converged address book service - Google Patents

Abstract

PURPOSE: An address state providing apparatus based on an integrated address service and method thereof are provided to grasp the usage state of a CAB(Converged Address Book) service by acquiring the capability of an opponent through a CAB server. CONSTITUTION: A contact sharing function unit(12) searches the contact state of a receiver from an address XDMS(XML Document Management Server)(15). The contact sharing function unit of a CAB server(11) transmits an HTTP option request to a caller side cross network proxy server(16). A push proxy gateway(20) transmits a PAP(Printer Access Protocol) push response message to a push generator(19). A confirmation message is transmitted to the CAB server through the caller side cross network proxy server.

Description

Apparatus and method for providing address status based on integrated address book service {APPARATUS AND METHOD FOR PROVIDING CONTACT STATUS BASED ON CONVERGED ADDRESS BOOK SERVICE}

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a converged address book (CAB), and more particularly, to an apparatus and method for providing an address state based on an integrated address book service.

Mobile communication has greatly changed and changed everyday life in accordance with the universalization of its dissemination in terms of being able to supply and exchange necessary information anytime and anywhere due to its portability. Communication technologies currently supported by mobile communication can be divided into voice communication, messaging service, and wireless Internet service.

Among the important technical requirements for messaging services are to make it easier to send messages to multiple recipients and to update address information changes about recipients more quickly and accurately. For this reason, integrated management of address book is necessary for messaging service. According to this need, CAB service has been proposed.

In the SIP / IP (Session Initiation Protocol / Internet Protocol) core network, the CAB (Converged Address Book) service stores the address information available from various terminals, and makes this information accessible to any device, anytime, anywhere. It is a single network based address book service that synchronizes address information. This CAB service is provided for the purpose of improving the user's experience and function with the address book by storing a single network address book in the network.

In order to provide CAB users with the main functions of CAB service smoothly, basically, it is necessary to provide contact status that distinguishes existing users from CAB users. In CAB service, it is common to use the function of mutual CAB service among CAB service subscribers. However, even though the receiver owns a terminal capable of subscribing to the CAB service, there may be a case in which the subscriber does not subscribe to the CAB service or temporarily stops the CAB service. In this case, there may be a failure in using the CAB service smoothly between CAB users. Therefore, there is a need to ensure that the main functions of the CAB service are smoothly provided by identifying and managing the use of the other party's CAB service.

Accordingly, the present invention provides an apparatus and method for providing a smooth CAB service by identifying and managing the use of the other party's CAB service.

According to an aspect of the present invention, there is provided a method for providing a contact state based on an integrated address book service, the method comprising: generating a status request message for obtaining a contact status of a receiving client; Transmitting the generated status request message to a push generator for transmitting to a push framework; and based on the generated status request message, the push generator generates a push message for requesting the expected capability of the receiving client. Acquiring support information of an integrated address book service of the receiving client from the push proxy gateway according to delivery to a push proxy gateway; and obtaining a contact state of the receiving client based on the obtained support information; It is characterized by.

In addition, the present invention, in the device for providing a contact state based on the integrated address book service, generating a status request message for obtaining the contact status of the receiving client, the push to generate the push-side push content to the push framework The generated status request message is transmitted to a generation unit, and the push generation unit generates a push message for the request of the expected capability of the receiving client based on the generated status request message and delivers the push message to the push proxy gateway. A control unit which obtains support information of the integrated address book service of the receiving client from a proxy gateway, obtains a contact state of the receiving client based on the obtained support information, and a transceiver which transmits the generated status request message; Characterized by The.

According to the present invention, the registered terminals of the user acquires the counterpart capability by the CAB server to determine whether the CAB service is used, and thus the CAB server can smoothly perform the CAB main service.

In addition, according to the present invention, since the other party does not require an unnecessary process of proceeding to cancel the contact subscription again after checking the contact status according to the contact subscription, there is an advantage that the CAB service can be performed more quickly. In addition, both the sending and receiving clients do not need additional resources of separate management for contact subscription, thereby avoiding waste of resources, power, and memory. In addition, the main functions of the CAB service can be smoothly provided, which allows the CAB service to be easily and quickly selected according to the user's intention.

1 is a block diagram of a CAB system used in the present invention,
2 is a diagram illustrating signal transmission and reception for acquiring a contact state according to a first embodiment of the present invention;
3 is a diagram illustrating signal transmission and reception for obtaining a contact state according to a second embodiment of the present invention;
4 is a diagram illustrating signal transmission and reception for acquiring a contact state according to a third embodiment of the present invention.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. It is to be noted that the same elements among the drawings are denoted by the same reference numerals whenever possible. In addition, detailed descriptions of well-known functions and configurations that may unnecessarily obscure the subject matter of the present invention will be omitted.

In the following description will be presented a representative embodiment in the present invention for achieving the above technical problem. Also, for the convenience of description of the present invention, names of entities defined in the Converged Address Book (CAB) of the Open Mobile Alliance (OMA), which is a standard organization of applications of the mobile terminal, will be used. The present invention is not limited thereto, and is applicable to systems having a similar technical background.

The present invention proposes a method for providing a smooth CAB service. To this end, the present invention checks the other party (capability) through the push enabler to obtain the contact status in the CAB server, and the process of obtaining the other party's capabilities by informing the presence or absence of the support of the CAB service through the confirmation process Is done. As such, by identifying and managing the use of the other party's CAB service, it is possible to provide a smooth CAB service.

Hereinafter, a system for providing a CAB service according to the present invention will be described with reference to FIG. 1. The system according to the present invention is largely composed of a CAB client 10, a CAB server 11, a CAB XML Document Management Server (XDMS) 13, a push enabler 18, and the like.

The CAB client 10 communicates with the CAB server 11 on the terminal and synchronizes CAB user authentication, personal contact information (hereinafter referred to as 'PCC') with the integrated address book stored in the network store, and the CAB user's It is responsible for transmitting requirements, such as address subscriptions, address lookups, address sharing, interaction with existing address books or management of user preferences, to the CAB server 11.

The CAB server 11 is a major network component in the CAB structure, and is responsible for receiving and processing CAB user requests from the CAB client 10. The main functions of the CAB server 11 serve to reflect CAB client mutual authentication, storage of CAB addresses, address information synchronization, address information update from address subscription functions, and the like in the address book.

The CAB server 11 includes a control unit and a transceiver. First, the controller generates a request message for acquiring a contact status of a receiving client, and transmits the generated status request message to the push generating unit 19, and the push generating unit 19 predicts the expected capability of the receiving client. By generating a push message for the request of the request to the push proxy gateway 20 to obtain the support information of the integrated address book service of the receiving client from the push proxy gateway 20, based on the support information The contact state of the client is obtained, and the contact state obtained through this process is stored in the calling address book XDMS 15.

The transceiver transmits the generated status request message under the control of the controller.

It is a network component that reflects address sharing / sharing and user preference / policy.The main functions are CAB user affinity and policy CAB user affinity XML document retrieval from XDMS, address subscription receiving CAB user's subscription request. Function, applying personal preferences of data received through address subscription and reflecting to address book, maintaining subscription status information, address sharing function to share PCC or integrated address book, and linking with existing address book system or interface with external enablers Interworking Function (Interworking Function) that exposes.

The CAB XDMS (13) that manages the user's data includes a CAB AB App (Address Book Application) Usage (15) that stores the integrated address book and contact state to distinguish existing and CAB users, and a CAB UP that stores the user's preferences. User (Preference Application) App (22), CAB Personal Contact Card Application (PC App) Usage (23) that stores PCC information, and CAB FH App (Feature Handler Application) Usage (14) which manages CAB service requests and responses. Others include XDMC for accessing various App Usage functions, and SIP / IP core network for routing messages with entities in external domains.

The PUSH enabler 18 serves to support the contact subscription function, which is one of the main functions of the CAB service. This PUSH enabler 18 is used to perform address subscription in an environment where the CAB client does not support SIP. The PUSH enabler 18 includes a push generator 19 and a push proxy gateway (PPG) 20. The push generator 19 generates a push content and delivers the push content to the push framework so that the receiving client can receive the push content. Here, the push framework refers to all components of the PUSH enabler 18 necessary for delivering push content to the receiving client B 21, including the push proxy gateway 20. The push proxy gateway 20 is responsible for managing client information, such as the capabilities of the receiving client.

Cross Network Proxy (16, 17) serves to enable the originating CAB client to connect to the receiving CAB client.

Hereinafter, a method in which the CAB server 11 can smoothly perform a CAB function by checking the capability of the other party in the CAB server 11 and identifying and managing the use of a CAN service according to an embodiment of the present invention. Shall be. To this end, in the first and second embodiments of the present invention, the originating CAB client checks the capability of the receiver by using HTTP OPTIONS and PAP push message by the CAB server 11 when sharing a contact, and based on this, This is done by identifying the use. In addition, the third embodiment of the present invention relates to the use of HTTP OPTIONS and PAP ccq messages. In this case, the contact sharing is one of the CAB services, and the contact sharing information is not limited only to the implementation of the contact sharing function, but may also be used for other CAB services, for example, address subscription or address search.

In addition, the CAB address sharing method in the following embodiments of the present invention may be performed between users of the same domain or between different domains. The sharing of CAB addresses between the same domain and between different domains may have some differences in message routing from origination to reception, but the overall nature of the CAB address sharing method does not change. Accordingly, embodiments of the present invention deal with a method of acquiring a contact status when sharing a CAB address between CAB users in different domains, which is a more general case.

First, in the first embodiment of the present invention, after the sender sends an HTTP OPTIONS request message for determining the receiver capability, the receiver converts the HTTP OPTIONS request message into a PAP push message using a PUSH enabler, and then pushes the push. Sending to the proxy gateway (PPG) 20 to obtain the capability of the receiving end. Here, the PAP push message includes an attribute for requesting a message processing status report and an expected capability of a receiving client including a CAB service feature tag in a Push-Accept-Contact attribute.

Hereinafter, a first embodiment of the present invention as described above will be described with reference to FIG.

Referring to FIG. 2, the originating CAB client A 10 transmits an XML Configuration Access Protocol (XCAP) request for contact sharing in step 200 to a CAB FH App (Feature Handler Application) Usage 14, which is a feature handler XDMS. . Correspondingly, the feature handler XDMS 14 adds a reference to the receiving contact address and shared data from the XCAP request to the CAB feature handler.

In step 205, the feature handler XDMS 14 notifies the contact sharing function unit 12 of the CAB server 11 of the document change of the CAB feature handler. Here, the feature handler XDMS 14 may obtain the change information in the CAB feature handler by separately checking whether the contact sharing function 12 stores the address sharing request message separately from notifying the document change.

In step 210, the contact sharing function unit 12 is based on the address of the recipient CAB AB App. Retrieve the recipient's contact status from Usage 15. If the address book XDMS 15 fails to obtain the contact status, it is notified to the contact sharing function 12 of the CAB server 11 in step 215.

Then, the contact sharing function unit 12 of the CAB server 11 generates an HTTP OPTIONS request for obtaining the contact status of the receiver in step 220 and transmits it to the calling party's cross network proxy 16. At this time, it is necessary to include an 'accept-contact' header in the HTTP OPTIONS request to confirm whether the receiver supports the CAB service. The format of the HTTP OPTIONS request may be expressed as shown in Table 1 below, but the format is not limited thereto.

The HTTP OPTIONS request as shown in Table 1 is routed to the receiving cross network proxy 17 in step 225, and the receiving cross network proxy 17 transmits to the push generator 19 in step 230.

When the push generator 19 receives the HTTP OPTIONS request, the push generator 19 determines whether to include an 'accept-contact' header in the HTTP OPTIONS request. If this header is included, it is determined that the receiver is requesting the receiver's ability to confirm whether the receiver supports CAB service. Accordingly, the push generator 19 generates a push message for requesting the expected capability of the receiving client in step 235 and transmits the push message to the push proxy gateway 23. Here, when the push generation unit 19 gives the push proxy gateway 20 a list that is expected to be provided by the receiving side CAB client B 21 through the request process of the expected capability, the CAB from the push proxy gateway 20. The client B 21 receives the initial registered information.

Specifically, the push generator 19 may generate a PAP push message having an expected capability of the receiving client including a CAB service feature tag in the 'Push-Accept-Contact' attribute and an attribute for requesting a message processing status report. Send to push proxy gateway 20. The format of this PAP push message may be expressed as shown in Table 2 below, but the format is not limited thereto.

In Table 2, the '<push-message ~ / push-message> tag indicates a request to inform the receiving party of whether or not to receive the received message. In other words, this tag represents an attribute that requests message processing status reporting.

In addition, in Table 2, the '<prf: Push-Accept-Contact ~ / prf: Push-Accept-Contact> tag represents a request of whether the CAB service can be allowed to the receiver. That is, this tag represents an attribute for confirming whether or not the CAB service is supported.

Meanwhile, in step 202, the push proxy gateway 20 registers the client capability for the CAB client B 21, which is the receiving side for the CAB service. When the push proxy gateway 20 receives the PAP push message, the push proxy gateway 20 transmits the PAP push response message including the process completion status report of the PAP push message to the push generator 19 in step 240. The PAP push response message is a 1000 OK message indicating initial acceptance, and the format of the PAP push response message can be represented as shown in Table 3 below, and the format thereof is not limited thereto.

In Table 2, "completed" indicates that the confirmation of the received message is completed, and "The request succeed" indicates that the CAB service is possible.

When the push generator 19 receives the PAP push response message as shown in Table 3 above, the push generator 19 receives a 200 OK message informing the permission of the CAB service based on the push response message in step 245. It forwards to the originating domain via the network proxy 17. By doing so, the CAB server 11 integrates the CAB client B 21 from the push proxy gateway 20 that manages the information of the CAB client B 21 in response to sending an HTTP OPTIONS request for obtaining the contact status. Support information of the address book service is provided through the push generator 19.

Accordingly, the 200 OK message informing the permission of the CAB service in steps 250 and 255 is forwarded to the CAB server 11 via the outgoing cross network proxy 16. Here, the 200 OK message has an 'Accept-Contact' header including a CAB service tag associated with CAB service support of the receiving side CAB client B 21, the format is as shown in Table 4 below, and the format thereof is limited thereto. It doesn't work.

Meanwhile, in step 255, the 200 OK message is transmitted to the contact sharing function unit 12 in the CAB server 11, which performs the XDM forward-based contact sharing as in step 260. Specifically, the contact sharing function unit 12 determines that the receiving party is a CAB service user based on the 200 OK message, and generates an XDCP (XML Document Command Protocol) request including a reference of an address to be shared. Then, when the contact sharing function unit 12 sends the XDCP request to the address book XDMS 15, the address book XDMS 15 obtains an address corresponding to the reference of the address to be shared and temporarily stores it. The contact sharing function 12 then generates and sends an XDM forward request containing a document link to the stored address to the recipient address book XDMS. As such, when the CAB server 11 is provided with the supporting information of the integrated address book service of the CAB client B 21, the CAB server 11 can know, for example, the address of the receiving client based on this, and thus the actual CAB client B ( A contact state for 21) is obtained.

In addition, the contact sharing function unit 12 of the CAB server 11 stores the contact state of the receiver acquired according to the user's preference in the address book XDMS 15 in step 265. The address book XDMS 15 then stores it and responds with a 200 OK in step 270. Accordingly, the CAB server 11 notifies the CAB client A 10 of the change of contact status in step 275. 'Server Alert Notification' is used for this notification. Then, the CAB server 11 performs the address book update of the CAB client A 10 in step 280. In FIG. 2, steps 265 to 280 are preferably performed after step 260, but may be performed between steps 255 and 260 immediately after acquiring a contact state of the receiver for data accuracy.

According to the first embodiment of the present invention as described above, even if the receiving side is a non-SIP device and does not support the SIP / IP core, it is possible to identify and share the contact state. That is, contact sharing, which is one of the main functions of the CAB service, between the SIP device and the non-SIP device is enabled.

Meanwhile, in the second embodiment of the present invention, as in the first embodiment of the present invention, the sender sends an HTTP OPTIONS request message for determining the receiver capability, and then the receiver uses the PUSH enabler to send the HTTP OPTIONS request message. Is converted into a PAP push message and then sent to a push proxy gateway (PPG) 20 to obtain the capability of the receiving side. However, the PAP push message according to the second embodiment of the present invention may include 'ppg-' for requesting the expected capability and result notification of the receiving client including the CAB service feature tag in the 'Push-Accept-Contact' attribute. Contains the notify-requested-to 'attribute.

Hereinafter, a second embodiment of the present invention as described above will be described with reference to FIG.

Referring to FIG. 3, steps 300 to 330 of FIG. 3 are the same as operations of 200 to 230 of FIG. 2, and steps 350 to 380 are the same as operations of 250 to 280 of FIG. 2. The detailed description thereof will be omitted.

According to the second embodiment of the present invention, when the push generator 19 receives the HTTP OPTIONS request for obtaining the contact status in step 330, the CAB service feature tag in the 'Push-Accept-Contact' attribute in step 332. A PAP push message having a 'ppg-notify-requested-to' attribute for requesting an expected capability and a result notification of a receiving client including a is generated and transmitted to the push proxy gateway 20. The format of the PAP push message is shown in Table 5 below, but the format is not limited thereto.

In Table 5, 'ppg-notify-requested-to' indicates a request for a result notification from the receiving side CAB client B 21, and 'Push-Accept-Contact' indicates a request whether the CAB service can be allowed. .

When receiving the PAP push message, the push proxy gateway 20 generates a PAP push response message and transmits it to the push generator 19 in step 334. At this time, the PAP push response message is 1000 OK, which means initial acceptance, and simply serves to inform whether or not the PAP push message is received. In addition, the push proxy gateway 20 delivers the PAP push message received in step 336 to the CAB client B 21. In the first embodiment of the present invention, the push proxy gateway 20 informs whether the CAB service is available instead of the CAB client B 21. However, in the second embodiment of the present invention, the CAB client B 21 directly displays its capabilities. The difference is that it checks whether the CAB service is available.

Therefore, when the CAB client B 21 receives the PAP push message, it analyzes the 'ppg-notify-requested-to' attribute in the PAP push message and confirms its capability. The confirmation from this CAB client B 21 is forwarded to the push proxy gateway 20 in step 338.

When the push proxy gateway 20 receives the confirmation, the push proxy gateway 20 generates a PAP result notification message for the capability and transmits the result to the push generator 19 in step 340. This PAP result notification message is a message indicating that a request for processing has been accepted. The format is shown in Table 6 below, and the format is not limited thereto.

Upon receiving the PAP result notification message as shown in Table 6 above, the push generator 19 transmits the result notification response to the push proxy gateway 20 in step 342. The push generator 19 then delivers a 200 OK message informing the originating domain of the CAB service based on the PAP result notification message to the originating domain via the receiving cross network proxy 17.

Meanwhile, in the third embodiment of the present invention, after the sender sends an HTTP OPTIONS request message for determining the receiver capability, the receiver converts the HTTP OPTIONS request message into a PAP ccq message using a PUSH enabler, and then pushes the message. Sending to the proxy gateway (PPG) 20 to obtain the capability of the receiving end. As described above, the third embodiment of the present invention uses the PAP ccq message instead of the PAP push message. In the case of using the PAP push message, an expected list may be provided based on the information on the pre-registered client capability. However, in the case of using the PAP ccq message, the entire information on the pre-registered client capability is provided.

Hereinafter, a third embodiment of the present invention as described above will be described with reference to FIG.

Referring to FIG. 4, steps 400 to 430 of FIG. 4 are the same as operations 200 to 230 of FIG. 2, and steps 450 to 480 are the same as operations 250 to 280 of FIG. 2. The detailed description thereof will be omitted.

According to the third embodiment of the present invention, when the push generator 19 receives the HTTP OPTIONS request for obtaining the contact status in step 330, the push generator 19 determines that the client capability confirmation request for CAB service support is performed. Accordingly, the push generator 19 generates a PAP ccq message, which is a request for confirming the receiving client capability, in step 435 and transmits the PAP ccq message to the push proxy gateway 20. The format of the PAP ccq message is shown in Table 7 below, but the format is not limited thereto.

When receiving the PAP ccq message as shown in Table 7, the push proxy gateway 20 checks the client capability registered in advance by the CAB client B 21 in step 402. Then, the push proxy gateway 20 generates a ccq response message for the client capability in step 440 and delivers it to the push generator 19. The format of such a ccq response message is shown in Table 8 below, and the format thereof is not limited thereto.

When receiving the ccq response message as shown in Table 8, the push generation unit 19 generates a 200 OK message informing the permission of the CAB service based on this in step 445, and receives the originating domain through the receiving cross-network proxy 17. To pass. This ccq response message can be seen that the CAB service can be supported as well as the entire information registered in advance.

On the other hand, in the CAB service, the use of the function of the mutual CAB service among the CAB service subscribers is common. However, even if the receiving party has a terminal that can subscribe to CAB service, if the CAB service is not subscribed or the CAB service is temporarily disabled, the following method is proposed to receive contact status information for the receiving party. May be In this case, there is a method of inviting the CAB service from the calling party to the receiving party. To this end, the calling party sends a predefined message to the receiving party through the messaging enabler to subscribe to the CAB service or request the resumption of the CAB service. This method may be implemented when contact status information between users of the same domain may be provided.

As described above, according to the present invention, it is possible to obtain a contact state between a SIP device and a non-SIP device user, thereby providing a continuous CAB service.

Claims (13)

In the method for providing a contact state based on the integrated address book service,
Generating a status request message for obtaining a contact status of a receiving client;
Transmitting the generated status request message to a push generator that generates push-side push content and delivers it to the push framework;
Based on the generated status request message, the push generator generates a push message for requesting the expected capability of the receiving client and delivers the push message to the push proxy gateway, thereby providing an integrated address book service of the receiving client. The process of obtaining support information;
And obtaining a contact status of the receiving client based on the obtained assistance information.
The method of claim 1, wherein the status request message for obtaining the contact status is:
Method for providing a contact status based on the integrated address book service, characterized in that the HTTP OPTIONS message.
The method of claim 1, wherein the generated status request message,
And converting the PAP push message into the push proxy gateway through the push generator.
The method of claim 3, wherein the PAP push message,
And a processing status report on the generated status request message and an attribute for requesting an expected capability of the receiving client.
The method of claim 1,
Storing the obtained contact state after acquiring a contact state of the receiving client;
Notifying a calling client of the change of the contact state;
And updating the address book of the originating client.
The method of claim 1, wherein the generated status request message,
And converting the PAP ccq message into the push proxy gateway through the push generation unit.
The method of claim 1,
And receiving an XML Configuration Access Protocol (XCAP) request for contact sharing from an originating client.
An apparatus for providing a contact status based on an integrated address book service, the apparatus comprising:
Generates a status request message for obtaining a contact status of a receiving client, transmits the generated status request message to a push generator that generates and transmits the received push content to the push framework, and based on the generated status request message. As the push generation unit generates a push message for requesting the expected capability of the receiving side client and delivers the push message to the push proxy gateway, it acquires support information of the integrated address book service of the receiving side client from the push proxy gateway, A control unit for obtaining a contact state of the receiving client based on the received support information;
Apparatus for providing a contact status based on the integrated address book service, characterized in that it comprises a transceiver for transmitting the generated status request message.
The method of claim 8, wherein the status request message for obtaining the contact status includes:
Apparatus for providing a contact status based on the integrated address book service, characterized in that the HTTP OPTIONS message.
The method of claim 8, wherein the generated status request message,
And converting the PAP push message into the push proxy gateway through the push generation unit.
The method of claim 10, wherein the PAP push message,
And a processing status report on the generated status request message and an attribute requesting an expected capability of the receiving client.
The method of claim 8, wherein the control unit,
After acquiring the contact state of the receiving client, storing the obtained contact state in an originating address book XDMS (XML Document Management Server), notifying the calling client of the change of the contact state, and then Apparatus for providing a contact status based on the integrated address book service, characterized in that for updating the address book.
The method of claim 8, wherein the generated status request message,
And converting the PAP ccq message into the push proxy gateway through the push generation unit.

Images