KR101635906B1 - Method for providing the communication history - Google Patents

Abstract

The present invention relates to providing a communication history of a terminal in a SIP / IP core network. When a user using a plurality of terminals requests a communication history subscription of a terminal to a server, The communication history information related to the plurality of terminals is transmitted to any one of a plurality of terminals whenever the communication history is newly registered, and the terminal, which has received the communication history information, And can request and receive the presence information of the counterpart terminal.

Description

METHOD FOR PROVIDING THE COMMUNICATION HISTORY [0002]

The present invention relates to an integrated address book service of a Session Initiation Protocol / Internet Protocol (SIP) / IP network core network, and more particularly, to a method and apparatus for managing a communication history of a mobile terminal using a unified address book service.

In the SIP / IP core network, a Converged Address Book (CAB) stores address information available in various terminals owned by a user, makes this information accessible to any device, anywhere, any device, Is a single network-based address book service.

1, a CAB client 100, a CAB server 120, a contact control server 130, an XML Document Management Server (XDMS) 140, and the like are provided in the OMA CAB group. do.

The CAB client 100 communicates with the CAB server 120 on the terminal and performs CAB user authentication, personal contact information (PCC) synchronization with the integrated address book stored in the network repository, For example, an address subscription, an address search, an address sharing, an interaction with an existing address book, or a management of a user's preference, to the CAB server 120. The CAB server 130 is a main network component in the CAB structure, and receives a CAB user's request from the CAB client 100 to process the request. The main functions of the CAB server 120 include the CAB client mutual authentication, the storage of the CAB address, the synchronization of the address information, and the update of the address information from the address subscription function. The contact control server 130 is a network component that reflects the address subscription / sharing / conversion and the user's preference / policy. The main functions are CAB user preference and CAB user preference XML document retrieval from the policy XDMS, The ability to subscribe to an address to receive a request, to apply personal preferences of the data received through address subscriptions and to reflect in the address book, to maintain subscription status information, to share addresses that share PCC or Unified Address Book, or to associate with an existing address book system or to an external enabler And an interworking function that exposes the interface. CAB XDMS for storing integrated address book, CAB user preference / policy XDMS for storing user preference and policy, Contact Status XDMS for distinguishing existing user and CAB user, XDMS 140 for managing user data, A contact-sharing XDMS (Contact Share XDMS) that stores contacts shared with others, and a PCC XDMS that stores PCC information. In addition, there are XDMS for accessing various XDMS functions, and SIP / IP core network for message routing with entities of external domains.

An example of communication between a receiver and a caller having a plurality of terminals will be described with reference to FIG. 2 is an illustration showing that a caller communicates with a recipient having multiple terminals in a CAB service. 2, a receiving-side user A having a plurality of terminals accepts a communication request from the calling-side user B 240 entering his / her first terminal # 1 200 and establishes an audio session (steps 201, 203 , Step 205). Here, user B 240 may be configured as a group. After accomplishing the intended purpose (call, text, messenger, etc.) between the sender and the receiver, the user A ends the session with the user B 240 (steps 207 and 209). The communication history for the current communication is left in the terminals of the first terminal # 1 200 and the terminal B 240 of the user A according to the end of the session (step 215-a, step 215-b). However, in the current CAB service, when the second terminal # 2 220 of the user A requests opening of the session to the user B 240, the communication history remaining in the first terminal # 1 200 of the user A is stored in the second The user A does not communicate with the user B 240 using the communication history smoothly in step 217 because the terminal # 2 220 does not know it. Furthermore, if the contact of the user B 240 is not stored in the CAB address book, the user A can not communicate with the user B 240 because the communication history of the first terminal # 1 200 is not confirmed.

When a recipient having a plurality of terminals attempts to communicate with a sender to another terminal after communicating with a sender using a specific terminal, the recipient can not communicate with the sender without confirming the communication history with the original sender And the current CAB service does not provide information on the current CAB service, which is a great obstacle to smooth communication of users having a plurality of terminals. Therefore, it is urgent to integrally manage the communication history existing in a plurality of terminals in the CAB service.

In order to solve the above-described problems, the present invention provides a method for allowing a user using a plurality of terminals to smoothly communicate with a desired recipient through an integrated communication history for the plurality of terminals.

In addition, by providing unified communication history in the integrated address book system, it is possible to easily and quickly transmit and receive CAB services according to the selection of a plurality of terminal users by eliminating the inconvenience of sporadic use of individual terminal communication history to users having multiple terminals Method and apparatus.

According to another aspect of the present invention, there is provided a method of providing a communication history of a terminal in a communication system, the method comprising: requesting a communication history subscription to a server; and transmitting communication history information of all terminals registered corresponding to the user of the terminal And receiving and storing the data from the server.

Requesting presence information for at least one communication partner terminal included in the communication history information, and receiving presence information for the at least one communication partner terminal.

Transmitting the new communication history to the server when the terminal performs communication with an arbitrary terminal and a new communication history is generated; and receiving and storing the communication history information including the new communication history from the server .

Through the system and method proposed in the present invention, when a registered terminal of a sender requests a communication history subscription request, a notification is received each time a communication history is generated for each terminal, By providing a communication history including presence information at a terminal other than the terminal, continuous communication with active group members can be performed, thereby improving the user experience.

1 is a diagram illustrating a general SIP based CAB (Converged Address Book) system structure,
2 is a diagram illustrating a signal transmission / reception for storing a communication history between a recipient having a plurality of terminals and a group caller,
FIG. 3A and FIG. 3B are diagrams illustrating signal transmission / reception for group talk by sharing a communication history including presence-based SIP information proposed in the present invention; FIG.
4 is a diagram illustrating a process of managing a communication history according to another embodiment of the present invention;
FIG. 5 is a flowchart generalizing the FIG. 3; FIG.

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

The present invention stores address information and communication history in a SIP / IP core network so that it can be used by a plurality of terminals possessed by a single user, and can access this information to any device, anywhere, any device, Converged Address Book (CAB) service, which is a single network-based address book service, is used by a user using a plurality of terminals to integrate and manage address information and communication history in each terminal And a method of providing convenience of call continuity in a group call using a communication history by providing presence information to the user.

In the present invention, the communication history included as a function of the CAB enabler refers to a record relating to all communications that have occurred in the terminal, and includes a list of existing transmission and reception calls, and is used for each call type (transmission, reception, (SMS, MMS, SIM / SIM, PoC / CPM / CAB, etc.), etc., for example, a voice call, a video call, a group call, And a communication record according to an address storage location such as a terminal address, a USIM address, and an external memory address.

The present invention proposes the following for the continuity of history between terminals through the provision of communication history including presence information among communication parties. More specifically, when the terminals registered among the communication parties request the integrated communication history subscription request, a notification is received each time a communication history is generated for each terminal. The user notifies the communication history including the presence information at another terminal, By receiving, it is possible to communicate continuously with active group members, thereby improving the user experience.

Currently, Unified Messaging Service (CPM) and PoC service can store session history information and media in a repository called Message & Media Storage and PoC Box, respectively. However, each has a problem that the record may not be stored because it depends on the preference of the user and the policy of the provider. In addition, since the contents of the session history are limited to the SIP header information, it is relatively insufficient in terms of diversity and usefulness compared to the communication history information provided by the current terminal.

It is necessary to overcome the limitation of the information of the session history and to manage the communication history information separately existing in each terminal. To this end, according to the present invention, a communication history subscription of a registered terminal is requested and changed information is received, so that the communication history between terminals can be managed, presence information is transmitted to the communication history, We want users to have continuous communication through communication history. This is explained in more detail below.

According to the present invention, the CAB client 100 can perform the function of subscription / management / synchronization of the communication history. And the CAB server 120 will serve to store / synchronize / update the communication history in connection with the present invention. In addition, the XDMS 140 may additionally include a communication history XDMS (Communication History XDMS) that stores a user's communication history.

In FIG. 3A and FIG. 3B, the user A having two or more terminals sends a group call (User B, User C, and User D) to the first terminal # 1 200 through the invitation of the group call And then performs a group call with one of the group members active in the presence information via the updated communication history to the terminal of the second terminal # 2 (220) of the user A.

3A and 3B show a communication history providing method including the presence information proposed in the present invention. The caller using a plurality of terminals requests subscription of a communication history updated to the second # 2 terminal 220 of the user A among the two terminals in use by the caller in order to smoothly perform the group call later (Steps 3210, 3211, 3213, 3215, and 3217). The CAB XDMS 280 notifies the second communication terminal # 2 of the user A of the existing communication history that has been stored in association with the user A (step 3219, step 3221, step 3223, step 3225, 3225). There will also be no notification if there is no communication history changed until the subscription request expires in the future.

Thereafter, when there is a group call between the user A and the user B and the group call ends, the communication history will be generated (step 3230-a, step 3230-b), and the first terminal 200 of the user A and the CAB server The communication history generated through the Data Synchronization (Step 3231) between the mobile communication terminal 200 and the mobile communication terminal 260 will be stored in the CAB XDMS 280 (steps 3233, 3233, 3235, 3237 and 3239). Therefore, the CAB XDMS 280 confirms the authorization to subscribe to the changed communication history and notifies the second terminal # 2 220 of the user A (steps 3241, 3243, 3245, and 3247) . The user A tries to request the second terminal # 2 220 of the user A to reopen the existing group call based on the communication history information of the group call in the first terminal # 1 200 in step 3250. At this time, if the presence of the group members is provided, the connection / holdability of the group call connection can be secured, which will greatly improve the user's experience. The sender (user A) obtains the resource list from the communication history and sends a presence subscription request message to the presence server 350 having a filter for making a presence subscription request for the active resource (step 3251, step 3253 Step 3255, step 3257). The resource list is a list of communication partners included in the communication history.

Presence server 350 confirms the rights of the caller and notifies presence information only to the active resource (user B / user C) in the resource list (steps 3259, 3261, 3263, and 3265). Therefore, the caller who has obtained the presence information of the group circle (user A / user B / user C) active among the group members who participated in the existing group call is notified to the second terminal # 2 220 of the user A by the user B, (Steps 3267 and 3269). After the end of the group call, the communication history information is stored in the CAB XDMS 280 as before (steps 3271, 3273, 3275, and 3277).

The method of synchronizing the communication history data between the terminal and the server according to the present invention may be a synchronization process as shown in FIG. 4 in addition to the synchronization process shown in FIG. Figure 4 illustrates the process of synchronizing communication history data using XCAP patch operations (RFC 5261) via non-SIP based subscription binding.

In FIG. 4, a non-SIP based subscription binding is set in the CAB XDMS 280 using the XCAP PUT, and the established user preference is confirmed and the updated communication history is notified to the corresponding terminal.

First, in step 3301, the user sets a subscription request to the user preference in order to receive updated information on the communication history of the registered terminal, with respect to the second terminal # 2 220 of the user A. Thereafter, when the user A proceeds the group call to the first terminal # 1 200 thereof (step 3303), the communication history generated using the XCAP PUT is stored in the CAB XDMS 280 (step 3305-a, step 3305-b , 3307, 3309). At this time, it is possible to perform non-SIP notification for synchronization of communication history data by simultaneously transmitting the necessity of synchronization to another terminal through the non-SIP based subscription binding and that the communication history has been changed. The CAB XDMS 280 receiving the XCAP PUT notifies the subscription function unit 370 that the status of the communication history has been changed (steps 3311 and 3313), and the subscription function unit 370, which has received the notification, And checks the registered terminal of the user who needs to be notified for synchronization (step 3315). The subscription function unit 370 confirms that the second terminal # 2 220 of the user A has set the communication history subscription function and only the updated communication history using the XCAP patch operations is transmitted to the second terminal # 2 220 of the user. (Steps 3317, 3319, 3321, and 3323). Thus, the second terminal # 2 220 of the user A can request the re-opening of the existing group call, and the group call can proceed again based on the presence information of the existing participants as in FIG. 3 (step 3325).

As can be seen from the signal flow charts of FIGS. 3 and 4, by receiving the integrated communication history information on the terminal in the caller side, the problem that the communication history of the received call in one terminal can not be acquired And can also greatly improve the continuity of communication by receiving the communication history information including the presence information about the communication history information.

Table 1 to Table 5 show the message format for each step with respect to the signal flow diagram of FIG.

Table 1 shows an example of a message that the second terminal # 2 220 of the user A sends to the CAB XDMS 280 to request the subscription of the updated communication history (step 3211). In order to receive the updated XML document, "xcap-diff" is used as an event package and a new format for defining a communication history proposed in the present invention is requested as a content-type. The following XML document shows a URI for subscribing to the communication history of user A stored in the communication history storage unit.

SUBSCRIBEsip: alice.cafe@example.com; auid = org.openmobilealliance.comm_histories SIP / 2.0
Via: SIP / 2.0 / UDP [5555 :: aaa: bbb: ccc: ddd]: 1357; comp = sigcomp; branch = z9hG4bKnashds7
Max-Forwards: 70
Route: <sip: pcscf1.visited1.net: 7531; lr; comp = sigcomp>, <sip: orig@scscf1.home1.net; lr>
From: <sip: alice2.cafe@example.com>; tag = 31415
To: <sip: alice.cafe@example.com>
Event: xcap-diff
Call-ID: b89rjhnedlrfjflslj40a222
CSeq: 85 SUBSCRIBE
P-Preferred-Identity: "Alice2 Cafe"<sip:Alice2.cafe@example.com>
Privacy: none
Expires: 600000
Accept: application / xcap-diff + xml
Contact: <sip: [5555 :: aaa: bbb: ccc: ddd]: 1357; comp = sigcomp>
Content-Type: application / communication-histories + xml
Content-Length: ..

<? xml version = "1.0" encoding = "UTF-8"?>
<communication-history xmlns = "urn: ietf: params: xml: ns: communication-histories">
<list>
<entry uri = "org.openmobilealliance.comm_histories / user
s / sip: alice. / communication_histories "/>
</ list>
</ communication-history>

Table 2 shows an example of storing the communication history newly created by the first terminal # 1 200 of the user A who has performed the group call with the user B in the CAB XDMS 280 in step 3233. The list to which the created communication history belongs is the receiving group call and the reference address of the communication history is "SIP: 112233@comm_historyserver.example.com ". The sender is a user B 240 and below it is a connection type (contact type_ "home", "office", "abroad", etc.), a contact number, a date time, a call time, The participants of the group call are listed. The example of Table 2 shows a basic type of communication history, and more rich communication history information may be provided depending on the terminal.

PUT / org.openmobilealliance.communication-histories / users / sip: alice.cafe@example.com/communication_histories.xml HTTP / 1.1
Host: xcap.example.com
...
Content-Type: application / communication-histories + xml
Content-Length: (...)

<? xml version = "1.0" encoding = "UTF-8"?>
<communication-histories xmlns = "urn: ietf: params: xml: ns: communication-histories">
<communication_histories>
<history list = "incoming_group_call" history_reference = "sip: 112233 @ comm_historyserver.example.com">
<entry name = "Bob">
<contact type = "home"> 031-111-2222 </ contact>
<datetime> 2008-01-10T19: 20: 49 + 09: 00 </ datetime>
<calltime> 00:04:30 </ calltime>
<participants>
<entry name = "Jane" uri = "sip: jane@example.com"/>
<entry name = "Tom" uri = "sip: tom@example.com"/>
</ entry>
</ history>
</ communication_histories>

Table 3 shows a message for notifying the newly stored communication history according to the subscription request of the second terminal # 2 220 of the user A (step 3241). CAB XDMS 280 sends a new entry of "sip: 112233@comm_historyserver.example.com" to the terminal.

NOTIFY sip: [5555 :: aaa: bbb: ccc: ddd]: 1357; comp = sigcomp SIP / 2.0
Via: SIP / 2.0 / UDP cabxdms1.home1.net; branch = z9hG4bK332b23.1
Max-Forwards: 70
Route: <sip: scscf1.home1.net; lr>, <sip: pcscf1.visited1.net: 7531; lr; comp = sigcomp>
From: <sip: alice.cafe@example.com>; tag = 31415
To: <sip: alice2.cafe@example.com>; tag = 151170
Call-ID: b89rjhnedlrfjflslj40a222
CSeq: 112 NOTIFY
Subscription-State: active; expires = 600000
Event: xcap-diff
Content-Type: application / xcap-diff + xml
Contact: <sip: cabxdms1.home1.net>
Content-Length: (...)

<? xml version = "1.0" encoding = "UTF-8"?>
xcap-root = "http: // xcap-diff" xmlns: och = "urn: ietf: params: xml-ns: communication-histories" .example.com ">
<document previous-etag = "7ahggs" sel = "org.openmobilealliance.comm_histories / user
s / sip: alice.cafe@example.com/communication_histories "
new-etag = "ffds66a">
<change-log>
<add sel = "och: group / och: communication_histories / l: list">
<och: entry och: uri = "sip: 112233@comm_historyserver.example.com">
</ add>
</ change-log>
</ document>
</ xcap-diff>

Table 4 shows an example of a message in which the user A requests subscription of presence using the resource list from the communication history as a filter to resume an existing group call to the second terminal # 2 220 (step 3251). The second terminal # 2 220 of the user A requests the first terminal # 1 200 and the user B / user C / user D 240 of the user A, respectively, with presence information.

SUBSCRIBE sip: alice.cafe@example.com; auid = org.openmobilealliance.presence SIP / 2.0
Via: SIP / 2.0 / UDP [5555 :: aaa: bbb: ccc: ddd]: 1357; comp = sigcomp; branch = z9hG4bKnashds7
Max-Forwards: 70
Route: <sip: pcscf1.visited1.net: 7531; lr; comp = sigcomp>, <sip: orig@scscf1.home1.net; lr>
From: <sip: alice2.cafe@example.com>; tag = 31415
To: <sip: alice.cafe@example.com>
Call-ID: 32432udfidfjmk342
Cseq: 1 SUBSCRIBE
P-Preferred-Identity: "Alice2 Cafe"<sip:Alice2.cafe@example.com>
Expires: 3600
Accept: multipart / related
Accept: application / rlmi + xml
Event: Presence
Contact: sip: alice2.cafe@example.com
Content-Type: application / simple-filter + xml
Content-Length: (...)
<? xml version = "1.0" encoding = "UTF-8"?>
<filter-set xmlns = "urn: ietf: params: xml: ns: simple-filter">
<ns-binding prefix = "pidf" urn = "urn: ietf: params: xml: ns: pidf"/>
<filter id = "123" uri = "sip: alice1.cafe@example.com">
<what>
<include type = "xpath">
// pidf: tuple / pidf: status [pidf: basic = "open"] / pidf: basic
</ include>
</ what>
</ filter>
<filter id = "124" uri = "sip: bob@example.com">
<what>
<include type = "xpath">
// pidf: tuple / pidf: status [pidf: basic = "open"] / pidf: basic
</ include>
</ what>
</ filter>
<filter id = "125" uri = "sip: jane@example.com">
<what>
<include type = "xpath">
// pidf: tuple / pidf: status [pidf: basic = "open"] / pidf: basic
</ include>
</ what>
</ filter>
<filter id = "126" uri = "sip: tom@example.com">
<what>
<include type = "xpath">
// pidf: tuple / pidf: status [pidf: basic = "open"] / pidf: basic
</ include>
</ what>
</ filter>
</ filter-set>

Table 5 is a message for notifying the presence information to which the filter for the status of the resource list, which is the result information according to the request of Table 4, is applied (Step 3259). As shown in the message, it can be seen that the user B and the user C are in the "online" state. Based on this information, user A may attempt to make a group call to the corresponding recipients at the second terminal # 2 220.

NOTIFY sip: [5555 :: aaa: bbb: ccc: ddd]: 1357; comp = sigcomp SIP / 2.0
Via: SIP / 2.0 / UDP cabxdms1.home1.net; branch = z9hG4bK332b23.1
Max-Forwards: 70
Route: <sip: scscf1.home1.net; lr>, <sip: pcscf1.visited1.net: 7531; lr; comp = sigcomp>
From: <sip: alice.cafe@example.com>; tag = 31415
To: <sip: alice2.cafe@example.com>; tag = 151170
Call-ID: b89rjhnedlrfjflslj40a222
CSeq: 112 NOTIFY
Subscription-State: active; expires = 600000
Event: Presence
Contact: sip: alice.cafe@example.com
Content-Type: application / pidf + xml
Content-Length: (...)
<? xml version = "1.0" encoding = "UTF-8"?>
<presence xmlns = "urn: ietf: params: xml: ns: pidf"
entity = "sip: alice@example.com">
<tuple id = "123">
<status>
<basic> closed </ basic>
</ status>
</ tuple>
<tuple id = "124">
<status>
<basic> open </ basic>
</ status>
</ tuple>
<tuple id = "125">
<status>
<basic> closed </ basic>
</ status>
</ tuple>
<tuple id = "126">
<status>
<basic> open </ basic>
</ status>
</ tuple>
</ presence>

The message format for the main steps is shown in Table 6 and Table 7 for the example of notifying the updated communication history through the XCAP patch operations of FIG. 4 (Step 3307).

In the message of Table 6, the generated communication history needs to be synchronized (sync = active) and stored in the CAB XDMS 280, thereby indicating to the CAB XDMS 280 that synchronization to another registered terminal is required (status = update) send.

PUT /org.openmobilealliance.communication-histories/users/sip:alice.cafe@example.com/communication_histories.xml HTTP / 1.1
Host: xcap.example.com

Content-Type: application / communication-histories + xml
Content-Length: ()

<? xml version = "1.0" encoding = "UTF-8"?>
<communication-histories xmlns = "urn: ietf: params: xml: ns: communication-histories">
<communication_histories status = "update" sync = "active">
<history id = a111 list = "incoming_group_call" history_reference = sip: 112233@comm_historyserver.example.com>
<entry name = "Bob">
<contact type = "home"> 031-111-2222 </ contact>
<datetime> 2008-01-10T19: 20: 49 + 09: 00 </ datetime>
<calltime> 00:04:30 </ calltime>
<participants>
<entry name = Jane uri = sip: jane@example.com/>
<entry name = Tom uri = sip: tom@example.com/>
</ entry>
</ history>
</ communication_histories>

Table 7 shows the communication history updated by the subscription function unit 350 through the XCAP patch operations from the user preference XDMS of the user A, which confirms that the second terminal # 2 220 of the user A requested the communication history subscription, # 2 220 in step 3319. In step 3319,

PUT /org.openmobilealliance.communication-histories/users/sip:alice2.cafe@example.com/communication_histories.xml HTTP / 1.1
Host: xcap.example.com

Content-Type: application / communication-histories + xml
Content-Length: ()

<? xml version = "1.0" encoding = "UTF-8"?>
<p: communication-histories xmlns = "urn: ietf: params: xml: ns: communication-histories">
<p: add sel = "communication-histories / history [@ id = 'a111'] type = @ list> incoming_group_call </ p: add>
<p: add sel = "communication-histories / history [@ id = 'a111'] type = @ history_reference> sip: 112233@comm_historyserver.example.com </ p: add>
<p: add sel = "communication-histories / history [@ id = 'a111']>
<entry name = "Bob">
<contact type = "home"> 031-111-2222 </ contact>
<datetime> 2008-01-10T19: 20: 49 + 09: 00 </ datetime>
<calltime> 00:04:30 </ calltime>
<participants>
<entry name = Jane uri = sip: jane@example.com/>
<entry name = Tom uri = sip: tom@example.com/>
</ entry>
</ p: add>
</ p: communication_histories>

As shown in FIG. 5, a process of integrating and managing the call history existing in each terminal using a plurality of terminals and providing presence information to the users is summarized in FIG.

The user A requests subscription for the communication history to the second terminal # 2 220 and receives notification of the subscription for the communication history in step 403. The user A receives the group call of the user B from the first terminal # 1 200 and performs the group call communication with the user C and the user D in step 405. As the group call is terminated, the first terminal # 1 200 of the user A stores the communication history generated in its communication history XDMS using OMA SyncML and XCAP PUT (Step 407). The second terminal # 2 220 of the user A receives the updated communication history information from the CAB XDMS 280 according to the existing subscription request (step 409). The user A retries the group call using the communication history to the second terminal # 2 220 as necessary (step 411). In this case, it is determined whether to request the presence information of the group circle that has performed the existing group call (step 413). If the presence information is not requested, the user A requests a simple group call using the communication history information (step 423). When requesting the presence information, the user A determines whether to request the filtered presence information (step 415). When requesting the filtered presence information for the group circle, the user A requests filtered information about the presence of the specific group circle (SUBSCRIBE (Event: presence, with filter) in step 417. In step 417, If the presence information is not requested, the user A requests presence information about the entire group source (SUBSCRIBE) in step 419. The user A is notified of the requested information about the presence of the group member in step 421. The user A notifies (INVITE) (step 423) a group call with the group members that are active based on the presence information of the group member.

When a group call is retried using the communication history, a user using a plurality of terminals can not only talk with active group members but also can share the communication history with other terminal There are advantages.

While the present invention has been described in connection with what is presently considered to be practical exemplary embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. Therefore, the scope of the present invention should not be limited by the described embodiments but should be determined by the equivalents of the claims and the claims.

100: CAB client 120: CAB server
130: contact control server 140: XDMS server

Claims (23)

A method for a first terminal to conduct a call,
Transmitting a registration request to a server for receiving a communication history;
Transmitting a subscription request for a communication history of a user of the first terminal to the server;
Receiving communication history information for all terminals associated with a user of the first terminal from a server;
Storing the communication history information in a memory;
Determining whether to request presence information about one or more second terminals to the server as filtered presence information;
Requesting the presence information about the one or more second terminals among the group members included in the communication history information to the server as the filtered presence information when requesting the filtered presence information;
Receiving the filtered presence information from the server;
And proceeding with a call with at least one of the one or more second terminals based on the filtered presence information. The method according to claim 1,
Wherein the communication history information includes a communication history for all terminals associated with a user of the first terminal,
Wherein the communication history comprises at least one of a call type, a communication type, and a messaging service type. 3. The method of claim 2,
Wherein the call type includes at least one of an outgoing call, an incoming call, an absence, and a rejected call,
The communication type includes at least one of a voice call, a video call, a group call and a messaging service,
Wherein the messaging service type includes at least one of SMS, MMS, SIMLPE IM, PoC, CPM, and CAB,
Wherein the communication history information further includes at least one of an address of a corresponding terminal, a USIM address, and an address of an external memory. The method according to claim 1,
Further comprising the step of requesting and notifying the server of the presence information of all the group members when the first terminal desires not to request the filtered presence information. The method according to claim 1,
Further comprising the step of requesting the server for presence information for one or more third terminals of all the group members. The method according to claim 1,
And displaying at least a part of the communication history information of all terminals related to the user according to the request of the user. delete The method of claim 1,
An event package for receiving an updated XML document, and a content type (Content-Type) for defining an updated XML document as the communication history. The method of claim 1, wherein the requesting of presence information for the one or more second terminals comprises:
And sending a presence subscription request message to the server. The method according to claim 1,
Transmitting the new communication history to the server when the first terminal communicates with at least one of the one or more second terminals to generate a new communication history;
Receiving communication history information including the new communication history from the server;
And storing the communication history information including the new communication history. 1. A method for managing communication history for one or more terminals in a server,
Receiving a registration request from a first terminal for receiving a communication history in the first terminal;
A receiving terminal for receiving at least a part of communication history information for all terminals related to a user of the first terminal,
Receiving a subscription request for a communication history of all terminals related to the user from the first terminal;
Transmitting communication history information for all terminals associated with the user to the first terminal;
Receiving presence information about one or more second terminals among all group members included in the communication history information as filtered presence information from the first terminal;
And transmitting the filtered presence information to the first terminal,
Wherein the first terminal proceeds with a call with at least one of the one or more second terminals based on the filtered presence information. 12. The method of claim 11,
Wherein the communication history information includes a communication history for all terminals associated with a user of the first terminal,
Wherein the communication history comprises at least one of a call type, a communication type, and a messaging service type. 13. The method of claim 12,
Wherein the call type includes at least one of an outgoing call, an incoming call, an absence, and a rejected call,
Wherein the communication type comprises at least one of a voice call, a video call, a group call and a messaging service,
Wherein the messaging service type includes at least one of SMS, MMS, SIMLPE IM, PoC, CPM, and CAB,
Wherein the communication history information further includes at least one of an address of a corresponding terminal, a USIM address, and an address of an external memory. 12. The method of claim 11,
And transmitting the presence information for all the group members to the first terminal when the first terminal requests the presence information for all the group members as the unfiltered presence information Lt; / RTI &gt; 12. The method of claim 11,
Receiving a newly generated communication history from the first terminal;
And transmitting the communication history information including the newly generated communication history to the first terminal. 1. A first terminal comprising a memory,
The first terminal transmits a registration request for receiving a communication history to a server, transmits a subscription request for a communication history of a user of the first terminal to the server, Receives the communication history information for the first terminals from the server and stores the received information in the memory, determines whether to request the presence information about one or more second terminals to the server as the filtered presence information, Requests presence information on the one or more second terminals among all group members included in the communication history information to the server as the filtered presence information and transmits the presence information to the server Based on the filtered presence information, and transmits at least one of the one or more second terminals The first terminal, characterized in that with a call in progress. 17. The method of claim 16,
Wherein the communication history information includes a communication history for all terminals associated with a user of the first terminal,
Wherein the communication history includes at least one of a communication type, a communication type, and a messaging service type. 18. The method of claim 17,
Wherein the call type includes at least one of an outgoing call, an incoming call, an absence, and a rejected call,
Wherein the communication type comprises at least one of a voice call, a video call, a group call and a messaging service,
Wherein the messaging service type includes at least one of SMS, MMS, SIMLPE IM, PoC, CPM, and CAB,
Wherein the communication history information further includes at least one of an address of a corresponding terminal, a USIM address, and an address of an external memory. 17. The method of claim 16,
And requests presence information on all the group members to be requested to the server when the user desires not to request the filtered presence information. 19. The terminal of claim 18,
When the new communication history is generated by communicating with at least one of the one or more second terminals, transmitting the new communication history to the server, receiving communication history information including the new communication history from the server The first terminal being characterized by: 17. The method of claim 16,
To the server, presence information for one or more third terminals of all the group members. 17. The method of claim 16,
And displays the communication history information according to the request of the user. delete

Images