WO2008134972A1

WO2008134972A1 - Method, system and server for realizing list information synchronization

Info

Publication number: WO2008134972A1
Application number: PCT/CN2008/070837
Authority: WO
Inventors: Guojun Xu
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2007-04-29
Filing date: 2008-04-28
Publication date: 2008-11-13
Also published as: CN101296507A; CN101296507B

Abstract

The embodiments of the present invention disclose a method and system for realizing list information synchronization. In which the first list information storage server obtains the change of the list information in the second list information storage server; updates the list information in its own storage synchronously according to the change of the list information in the second list information storage server. The embodiments of the present invention disclose a server for realizing list information synchronization at the same time, which includes: an updating module and a list information storage module. The list information storage module is used to store the list information of the appointed account number, and the updating module is used to update the list information in the list information storage module synchronously according to the change of the list information of the corresponding account number when obtaining the change of the list information of the corresponding account number of the appointed account number. By using the method, system and server in the present invention, the synchronous updating of the list information of the corresponding account number between the different message systems or between the same message systems could be realized.

Description

Method and system for realizing list information synchronization and server

The present invention relates to mobile communication technologies, and in particular, to a method and system for implementing list information synchronization and a server.

Background technique

A message service is a personal-to-individual, or personal-to-group message-based mobile data service based on a presence service. The message services specified in the Open Mobile Alliance (OMA), The 3rd Generation Partnership Project (3GPP), and the international standards such as 3GPP2 include: Based on the Session Initiation Protocol (SIP) ) messaging services and non-SIP based messaging services.

Among them, SIP-based messaging services, such as instant messaging and instant messaging using SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE)

( Instant Messenger, IM), push to talk over cellular (PoC), and Converged IP Messaging (CPM), mainly for IP Multimedia Subsystem (IMS) A generation of networks. Non-SIP based messaging services, such as Wireless Village (WV) services, email (Email) services, multimedia messaging

(Multimedia Messaging Service, MMS) and Short Message Service (SMS) are mainly used in traditional communication networks.

In the prior art, a system for processing a SIP message service is called a SIP message system, and the system uses SIP as a signaling bearer. Between each user of the SIP message system, such as the SIMPLE IM server

(Server), PoC Server, or CPM Server, etc. implement message interaction. A system that handles non-SIP message-based services is called a non-SIP message system, and the system uses non-SIP as the signaling. Messages are communicated between users of non-SIP messaging systems through, for example, WV Server, Email Server, or MMS Server.

Currently, the SIP message system generally provides users with a unified list information storage on the network side. For example, messaging systems such as IM, PoC, and CPM all share a shared list (share list), a share group (share group), and a share policy (share policy) in shared XML Document Management (SHARE XDM). ) and list information such as sharing personal information (share profile). Instead of SIP messaging systems, messaging systems such as MMS, SMS, and EMAIL do not provide users with uniform list information on the network side, except for Instant Messaging and Presence Services (IMS) messaging systems. List information such as contact list, grou, and public profile is stored in the IMPS message system server for the user.

Whether it is a SIP message system or a non-SIP message system, the list information can be updated as needed. The following is an example of updating the contact list by the IMPS message system and the IMS message system, respectively, to describe the manner in which the non-SIP message system and the SIP message system update the list information.

Figure la to Figure If shows the update of the contact list of the existing IMPS message system. The diagrams la, lb, lc, and Id are diagrams for the client to acquire, create, delete, and manage the contact list:

In Figure la, the client sends a Get List Request to the server, and the server replies to the client to obtain a contact list response (Get List Response), and if there is an error, returns a status information;

In Figure lb, the client sends a Create List Request to the server, and the server replies to the client to create a contact list response (Create List Response), and if there is an error, returns status information;

In the figure lc, the client sends a Delete list Request to the server, and the server returns the operation status (Status) to the client;

In Figure 1 d, the client sends a Manage Manage Request Request (List Manage Request) to the server, including adding, deleting, and changing the name of the contact list. The server replies to the client with a Manage Manage Response (List Manage Response). Figure le and Figure If are the schematic diagrams of the client ordering the service to the server and the server sending the event notification to the client:

In the picture le, the client sends a subscription notification request (Subscription Notification Request) to the server, and the corresponding event is ordered, such as a change of the contact list, and the server replies to the client with a Status message;

In Figure If the server sends an event notification (Notification Request) to the client according to the client's order, for example, notifying the client of the current contact list change, the client replies to the server with a Status message.

Figure 2 is a schematic diagram of the share list update of the existing IMS message system. As shown in Figure 2, the following steps are included:

Step 201: The XDM client creates a share list in the Shared XDM Server (XDMS) via the Hypertext Transfer Protocol Settings (HTTP PUT) command.

Step 202: The Shared XDMS sends a 201 Created message to the XDM client.

Step 203: The XDM client adds contact information to the newly created share list through the HTTP PUT command.

Step 204: The Shared XDMS sends a 200 OK message to the XDM client.

Step 205: The XDM client obtains the contact information from the created share list through the HTTP Get (GET) command.

Step 206: The Shared XDMS sends a 200 OK message to the XDM client.

Step 207: The XDM client deletes the specified contact information from the created share list by using the HTTP DELETE command.

Step 208: The Shared XDMS sends a 200 OK message to the XDM client.

In the above IMPS message system and IMS message system update process, in addition to the operation of the system user, the IMPS message system also supports adding SIP user type contact information such as IMS in its contact list; similarly, the IMS message system also supports The contact list of non-SIP user types such as IMPS is added to the share list. Usually, each piece of information in the contact list of the IMPS message system contains information such as the name, display name, and uniform resource identifier (URI), and IMS. The information contained in the share list of the message system is the same.

Considering the current technology development, existing non-SIP messaging systems and SIP messaging systems will coexist for a long time to come. In this way, when a message user uses different message services through multiple terminals, or opens multiple services on the same terminal, the list information of the user may not be consistent when using multiple clients of different services. For example: When a user uses a terminal that supports IMPS, the list information on the terminal is changed. Then, when the user uses another terminal that can support IMS, the list information must be changed again to ensure the current list. The information is up to date.

Similarly, if there are multiple accounts in the same message system, if the user modifies the list information of an account, if the user uses other accounts, he or she wants the current account to maintain the same list as the previous account. Information, you also need to change the list information of the current account. In short, whether it is a different message system or the same message system, in the prior art, when updating the different list information for the same user, if one of the list information changes, then when using another list information, it is necessary to correspondingly Re-update. In this way, when users use different message systems or use different accounts of the same message system, it is necessary to continually update the different list information, resulting in a poor user experience. Summary of the invention

In view of this, the main purpose of the embodiments of the present invention is to provide a method for implementing synchronization of list information, which can implement synchronous update of different list information in different message systems or the same message system.

Another object of the embodiments of the present invention is to provide a system for implementing list information synchronization, which can implement synchronous update of different list information in different message systems or the same message system.

A third object of the embodiments of the present invention is to provide a server that implements synchronization of list information, and the server can implement synchronization update of different list information in different message systems or the same message system.

To achieve the above objective, the technical solution of the embodiment of the present invention is implemented as follows:

A method for implementing synchronization of list information, the method comprising the following steps: The first list information storage server learns that the list information in the second list information storage server changes;

The list information stored by itself is updated in synchronization according to the change of the list information in the second list information storage server.

A system for implementing synchronization of list information, the system comprising: a first list information storage server and a second list information storage server, wherein

The first list information storage server and the second list information storage server are configured to synchronously update the list information stored by the peer server when the list information of the opposite server is changed.

A server for implementing synchronization of list information, the server comprising: an update module and a list information storage module;

The list information storage module is configured to store list information of a specified account;

And the updating module is configured to synchronously update the list information in the list information storage module according to the change of the corresponding account list information when the corresponding account list information of the specified account is changed.

It can be seen that, by using the technical solution of the embodiment of the present invention, for two servers respectively storing list information of corresponding accounts, when the list information on one of the servers changes, another server can synchronously update according to the changed list information. List information stored by itself. In this way, regardless of whether the two servers are located in different message systems or in the same message system, the list information can be updated synchronously.

DRAWINGS

Figure la to Figure If is a schematic diagram of the contact list update of the existing IMPS message system;

2 is a schematic diagram of a share list update of an existing IMS message system;

3 is a flow chart of an embodiment of a method of the present invention;

4a and FIG. 4b are schematic diagrams showing a service change notification event ordering manner between a server and a server according to an embodiment of the present invention; 5 is a flowchart of a method for implementing synchronization of list information according to the present invention; FIG. 6 is a flowchart of a method for implementing synchronization of list information according to the present invention;

FIG. 流程图 is a flowchart of an embodiment of a method for implementing list information synchronization according to the present invention;

8 is a schematic structural diagram of a system embodiment for implementing list information synchronization according to the present invention;

FIG. 9 is a schematic structural diagram of a server for implementing list information synchronization according to the present invention; FIG.

FIG. 10 is a schematic structural diagram of an embodiment of a server for implementing list information synchronization according to the present invention; FIG.

FIG. 11 is a schematic structural diagram of an embodiment of a server for implementing list information synchronization according to the present invention; FIG.

Figure 12 is a block diagram showing the structure of an embodiment of a server for realizing list information synchronization according to the present invention.

BEST MODE FOR CARRYING OUT THE INVENTION The present invention will be further described in detail below with reference to the drawings and embodiments.

In the embodiment of the present invention, when it is known that the list information of the counterpart server changes, the first list information storage server or the second list information storage server synchronously updates the list information stored by itself according to the change of the counterpart server list information.

The list information of the corresponding account that needs to be synchronously updated is specified in the first list information storage server and the second list information storage server in advance. In other words, it is necessary to first specify which two account list information needs to be updated synchronously. The pre-assignment method mentioned here may be: carrying a corresponding request account that needs to be synchronized when the client sends an order request command to the server, indicating that the server needs to synchronize the list information; or, through other networks, the corresponding account that the technology needs to synchronize may be implemented. The information is saved on the corresponding server.

In this way, when the list information of the corresponding account is changed, the first list information storage server or the second list information storage server synchronously updates the list information of the corresponding account according to the change of the corresponding account list information.

The first list information storage server and the second list information storage server may be located in two different In the message system, it can also be located in the same message system. Moreover, whether it is located in the same message system, to achieve synchronous update of the list information of the corresponding account, several different ways can be adopted.

It is assumed that the first list information storage server (hereinafter referred to as the first server) is located in the non-SIP message system, such as the IMPS message system; the second list information storage server (hereinafter referred to as the second server) is located in the SIP message system, such as the IMS message system. in. Then, to achieve synchronous update of the list information of the corresponding accounts in the two servers, there are three ways:

(1) How to order the event change notification event:

The first server and the second server pre-order the list information change notification event of the corresponding account to the other party; thus, when the list information of the designated account on any one of the two servers changes, the list information update notification is sent to the other party; the first server or The second server updates the notification information of the corresponding account according to the received list information update notification.

Because the two servers are respectively located in the non-SIP message system and the SIP message system, an Inter-working Function (IFF) needs to be set between the first server and the second server for the first server. The protocol that interacts with the second server performs protocol conversion.

The specific implementation includes: the first server sends an order notification request to the IWF; the IWF converts the order notification request into a SIP order request, and sends the request to the second server; or the second server sends a SIP order request to the IWF; the IWF orders the SIP The request is converted to an order notification request and sent to the first server. Correspondingly, when the list information of the specified account stored by itself changes: the first server sends a notification request to the IWF; the IWF converts the notification request into a SIP notification request, and sends the request to the second server; The SIP notification request updates the list information of the corresponding account; or, the second server sends a SIP notification request to the IWF; the IWF converts the SIP notification request into a notification request, and sends the request to the first server; the first server updates according to the notification request List information of its own corresponding account.

(2) Proactively notify the other party of the way the server's own list information changes:

When the list information of the corresponding account in the first server or the second server changes, the first server or the second server actively sends a list information update notification to the other party; the second server or the first server updates the notification according to the received list information, Update the list information of its corresponding account.

Similarly, in the synchronous update mode, it is also required to set a between the first server and the second server.

IWF.

In this way, the specific implementation of the synchronous update mode includes: the first server sends an update list to the IWF. The information request is: the IWF converts the update list information request into a release command, and sends the request to the second server; the second server updates the list information of the corresponding account according to the release command. Or, the second server is

The IWF sends a publish command; the IWF converts the issue command into an update list information request, and sends the request to the first server; the first server requests to update the list information of the corresponding account according to the received update list information.

(3) Send a request to the other party to obtain the change of the other party's list information:

The first server or the second server requests the other party to list information of the corresponding account; correspondingly, the second server or the first server sends back the list information of the corresponding account to the other party; the first server or the second server updates itself according to the received list information. Corresponding to the list information of the account. The first server and the second server may periodically request list information from the other party.

IWF.

In this way, the specific implementation of the synchronous update mode includes: the first server sends a list information acquisition request to the IWF; the IWF converts the list information acquisition request into an HTTP list information acquisition request, and sends the request to the second server; or the second server The IWF sends an HTTP list information acquisition request; the IWF converts the HTTP list information acquisition request into a list information acquisition request, and sends the request to the first server. Correspondingly, the first server or the second server sends back the list information to the other party: the second server sends a response message to the IWF; the IWF converts the response message into a list information acquisition response, and sends the response message to the first server; The list information obtains a response, and updates the list information of the corresponding account; or, the first server sends a list information acquisition response to the IWF; the IWF converts the list information acquisition response into a response message, and sends the response message to the second server; The response message updates the list information of the corresponding account.

In the synchronous update mode, an interface based on the XML Configuration Access Protocol (XCAP) is supported between the IWF and the second server.

If the first server and the second server are located in the same message system, for example, both in the IMS message system or the IMPS message system, to implement synchronous update of the list information of the corresponding accounts in the two servers, the following three methods are also available:

(1) How to order the event change notification event:

The first server and the second server pre-order the list information change notification event of the corresponding account to the other party; thus, when the list information of the specified account on any one of the two servers changes, Sending a list information update notification to the other party; the first server or the second server updates the list information of the corresponding account according to the received list information update notification.

The first server or the second server requests the other party's list information of the corresponding account; the second server or the first server sends back the list information of the corresponding account to the other party; the first server or the second server updates the corresponding account of the account according to the received list information. List information.

In the synchronous update mode, the first server or the second server may be list information that periodically requests the corresponding account from the other party.

It should be noted that, in the case that the first server and the second server are in the same system, if the first server and the second server are the same server, the first server/second server will automatically update the list information of the corresponding account. .

In addition, whether the two servers are located in different messaging systems or the two servers are in the same messaging system, if the list information of the corresponding accounts in the two servers does not contain the same items, only the same item content needs to be updated synchronously, for different parts. Even if a change has occurred, no update is required.

The present invention will be further described in detail below by way of specific embodiments:

3 is a flow chart of a first preferred embodiment of the method of the present invention. In this embodiment, it is assumed that the IMPS client has previously ordered the contact list and group change notification events on the IMPS server, and the IM client also pre-orders the share list and share group change notification events on the Share XDMS. The general client subscribes to the IMPS server. The contact list change does not support the function of having a share list or contact list with an account that synchronizes other system accounts. This command can be extended to carry the parameters of the synchronization destination account. After receiving the command, the server can order the share list change event to the XDM server of the destination account server according to the command. The client can also set the destination account to be synchronized on the server through the service management window.

As shown in FIG. 3, this embodiment includes the following steps:

Steps 301 ~ 302: IMPS subscribes to the change notification event to the Share XDMS via the IWF.

In this step, IMPS uses the subscribe notification request command. The IWF has ordered a change notification event to Share XDMS. As shown in FIG. 4a and FIG. 4b, it is a schematic diagram of a service change notification event ordering manner between the server and the server, wherein FIG. 4a and FIG. 4b respectively request the server to subscribe to the change notification event to the providing server, and provide the server to the request server. A schematic diagram of a loopback event notification. In this step, the IMPS subscribes to the change notification event to the Share XDMS using the subscribe notification request command shown in Figure 4a.

After receiving the order notification request from the IMPS server, the IWF converts the non-SIP based change notification event ordering request into a SIP-based ordering request according to the protocol conversion technology, and sends it to the Share XDMS _0.

The role of the IWF appearing in the subsequent process is basically the same as this step, and it plays a role in protocol conversion, and will not be described again.

Steps 303 ~ 305: The Share XDMS authenticates and sends an event notification to the IMPS server through the IWF.

In this step, the Share XDMS authenticates the change notification event ordering request received from the IMPS server. After the authentication is passed, the Share XDMS sends an event notification to the IMPS server through the IWF.

For the case where the IMPS server sends an order request to the Share XDMS through the subscribe notification request command in steps 301-302, in this step, the IWF uses the notification request command as shown in FIG. 4b to send an event notification to the IMPS server.

Step 306: The IMPS server sends an event notification to the IMPS client.

Step 307: The IM client notifies the Share XDMS to update the list information.

In this step, when the list information of the IM client changes, or the IM client updates the list information through the XDM client, the IM client notifies the Share XDMS to update the list information.

Steps 308 ~ 309: The Share XDMS sends an event notification to the IMPS server through the IWF.

The Share XDMS updates its own list information and sends an event notification to the IMPS server through the IWF to notify the IMPS server of the changed list information.

Step 310: The IMPS server sends an event notification to the IMPS client.

After receiving the event notification sent by the IWF, the IMPS server updates the list information saved by itself and sends an event notification to the IMPS client.

Figure 5 is a flow chart of a second preferred embodiment of the method of the present invention. In this embodiment, it is assumed that the IMPS client has previously subscribed the contact list and group change notification events on the IMPS server, and the IM client also pre-orders the share list and share group change notification events on the Share XDMS. As shown in FIG. 5, this embodiment includes the following steps:

Steps 501 ~ 502: The Share XDMS subscribes to the change notification event to the IMPS server via the IWF. In this step, Share XDMS subscribes to change notification events to IMPS via IWF, such as contact list and group change notification events.

Steps 503 ~ 505: The IMPS server authenticates and sends an event notification to the Share XDMS via the IWF.

Step 506: The IMPS client notifies the IMPS server to update the list information.

Steps 507 ~ 508: The IMPS server sends an event notification to the Share XDMS via the IWF. Step 509: The Share XDMS sends an event notification to the IM client.

In this embodiment, a part of the command is also required to be expanded, and the specific commands and the expansion are the same as those in the embodiment shown in FIG. 3, and details are not described herein again.

It should be noted that when different systems have different URI types under the same user name, the user can choose whether to overwrite the original URI with a new URI, and delete only the same user URI entry of the same user when deleting.

In the two embodiments shown in FIG. 3 and FIG. 5, two servers of different message systems learn the change of the other party's list information by ordering the change notification event of the other party, and synchronously update the stored information according to the change of the other party's list information. Corresponding to the list information of the user or the specified user.

The list information update mechanism can also be applied in the same message system, such as the IMPS message system or the IMS message system, in the synchronous update of the list information corresponding to different accounts belonging to different operators of the same user or different users, the specific implementation manner and the figure 3 is similar to the implementation of the two embodiments shown in FIG. That is, the server corresponding to each account subscribes to the change notification event of the server corresponding to the other account; when the list information on a certain server changes, the other server that has ordered the change notification event is notified, and the other servers update the stored information accordingly. List information.

Figure 6 is a flow chart of a third preferred embodiment of the method of the present invention. In this figure, two different processes are drawn together, showing how the IMPS client's contact list has changed how it is synchronized to the IM client and how the IM client's share list changes are synchronized to the IMPS client. In this embodiment, it is assumed that the IMPS client has previously subscribed the contact list and group change notification events on the IMPS server, and the IM client also pre-orders the share list and share group change notification events on the Share XDMS. As shown in FIG. 6, this embodiment includes the following steps:

Step 601: The IMPS client notifies the IMPS server to update the list information. Step 602: The IMPS server sends an update contact list request (Update contact list request) command to the IWF.

The IMPS server changes the corresponding list information according to the requirements of the IMPS client and sends an Update contact list request command to the IWF.

Since there is no Publish command in the IMPS message system in the prior art, in this step, a new command Update contact list request needs to be constructed to notify the IWF of the change of the list information on the IMPS server. .

Step 603: The IWF sends a Publish command to the Share XDMS.

The IWF converts the Update contact list request command received from the IMPS server into a Publish command and sends it to the Share XDMS. The Share XDMS updates the corresponding list information stored by itself.

Step 604: The Share XDMS sends an event notification to the IM client.

Step 605: The IM client notifies the Share XDMS to update the list information.

Step 606: The Share XDMS sends a Publish command to the IWF.

Share XDMS uses the Publish command to notify changes to its list information to the IMPS server via the IWF.

Step 607: The IWF sends an Update contact list request command to the IMPS server.

The IWF converts the Publish command received from Share XDMS into an Update contact list request command and sends it to the IMPS server.

Step 608: The IMPS server sends an event notification to the IMPS client.

In this embodiment, the two servers of different message systems notify the other party by issuing a command when the respective list information changes according to a preset mechanism, so that the other server can update its own list information in time, thereby enabling the two servers. The list information is kept in sync.

The list information update mechanism can also be applied in the same message system, such as the IMPS message system or the IMS message system, in the synchronous update of the list information corresponding to different accounts belonging to different operators of the same user or different users, the specific implementation manner and the figure The implementation of the embodiment shown in Figure 6 is similar.

Figure 7 is a flow chart of a fourth preferred embodiment of the method of the present invention. As shown in Figure 7, the following steps are included:

Step 701: The Share XDMS sends an HTTP Get Contact list command to the IWF to request to obtain list information on the IMPS server.

In this step, the function of the IWF needs to be extended to enable the function of the XDM Client. That is, an XCAP-based interface is supported between the IWF and the Share XDMS.

Step 702: The IWF sends a Get Contact list Request command to the IMPS server. Send to the IMPS server.

Step 703: The IMPS server sends a List Contact Get Response (Get Contact list Response) command to the IWF.

The Get Contact list Response command carries the list information obtained by the Share XDMS request. Step 704: The IWF sends a 200 OK message to the Share XDMS.

The 200 OK message carries the list information requested by the Share XDMS, and the Share XDMS updates the list information stored by itself according to the 200 OK message.

Step 705: The IMPS server sends a Get Contact list Request command to the IWF.

Step 706: The IWF sends an HTTP Get Contact list command to the Share XDMS.

Step 707: The Share XDMS sends a 200 OK message back to the IWF.

The 200 OK message carries the list information requested by the IMPS server.

Step 708: The IWF sends a Get Contact list Response command to the IMPS server.

The IWF converts the 200 OK message into a Get Contact list Response command and sends it to the IMPS server. The Get Contact list Response command carries the list information requested by the IMPS server, and the IMPS server updates its own list information according to the Get Contact list Response command.

In this embodiment, the two servers of different message systems obtain the list information of the other party by sending a request to each other, and update the self list information according to the obtained list information of the other party. The way in which requests are sent between the two servers mentioned here can be sent periodically.

The list information update mechanism can be similarly applied in the same message system, such as the IMPS message system or the IMS message system, in the synchronous update of the list information corresponding to different accounts belonging to different operators of the same user or different users, the specific implementation manner and the figure The implementation of the embodiment shown in FIG. 7 is similar and will not be described again.

It should be noted that the above describes only the manner in which the list information on the two servers is synchronously updated, but the present invention is not limited to the synchronous update of the two servers. It should be readily apparent to those skilled in the art that the implementation of synchronous updating of list information on multiple servers is nothing more than an extension of the manner described herein.

Based on the above method, FIG. 8 is a schematic structural view of a preferred embodiment of the system of the present invention. As shown in Figure 8, The system includes: a first list information storage server 801 and a second list information storage server 802. The first list information storage server 801 and the second list information storage server 802 are configured to synchronously update the list information stored by the other server when the list information of the counterpart server is changed.

If the first list information storage server 801 is located in the non-SIP message system and the second list information storage server 802 is located in the SIP message system, the system further includes: an IWF 803 for the first list information storage server 801 and the second list. The information storage server 802 forwards commands between the two, and according to the command, the receiver forwards the commands for protocol conversion.

The above SIP message system may be an IMS message system, and the non-SIP message system may be an IMPS message system.

The first list information storage server and the second list information storage server may also be located in the same message system, such as an IMS message system or an IMPS message system.

9 is a schematic structural diagram of a server of the present invention, as shown in FIG. 9, the server includes an update module 901 and a list information storage module 902;

a list information storage module 902, configured to store list information of a specified account;

The update module 901 is configured to synchronously update the list information in the list information storage module 902 according to the change of the corresponding account list information when the corresponding account list information of the designated account is changed.

FIG. 10 is a schematic structural diagram of a first preferred embodiment of a server according to the present invention. As shown in FIG. 10, the server includes: an ordering module 1001, a notification module 1002, an update module 1003, and a list information storage module 1004.

The ordering module 1001 is configured to order a list of the corresponding account information change notification event to the server where the corresponding account list information is located;

The notification module 1002 is configured to receive an order request from the server where the corresponding account list information is located, and send a list information update notification to the server corresponding to the account list information when the list information in the list information storage module 1004 changes;

The update module 1003 is configured to receive a list information update notification from the server where the corresponding account list information is located, and update the list information in the list information storage module 1004 according to the list information update notification.

The list information storage module 1004 is configured to store list information of the specified account.

Figure 11 is a block diagram showing the structure of a second preferred embodiment of the server of the present invention. As shown in Figure 11, The server includes: a notification module 1101, an update module 1102, and a list information storage module 1103. The notification module 1101 is configured to: when the list information in the list information storage module 1103 changes, send a list information update notification to the server where the corresponding account list information is located;

The update module 1102 is configured to receive a list information update notification from the server where the corresponding account list information is located, and update the notification information according to the list information, and synchronously update the list information in the list information storage module 1103;

The list information storage module 1103 is configured to store list information of the specified account.

Figure 12 is a block diagram showing the structure of a third preferred embodiment of the server of the present invention. As shown in FIG. 12, the server includes: a requesting module 1201, a sending module 1202, an updating module 1203, and a list information storage module 1204.

The requesting module 1201 is configured to request, by the server where the corresponding account list information is located, list information of the corresponding account;

The sending module 1202 is configured to receive a list information request from the server where the corresponding account list information is located, and send back the list information in the list information storage module 1204 to the server where the corresponding account list information is located;

The update module 1203 is configured to receive the list information of the corresponding account sent back from the server where the corresponding account list information is located, and update the list information in the list information storage module 1204 according to the list information of the corresponding account;

The list information storage module 1204 is configured to store list information of the specified account.

Through the description of the above embodiments, those skilled in the art can understand that all or part of the steps in implementing the above embodiments may be completed by a program instructing related hardware, and the program may be stored in a computer (may be A personal computer, a server, or a network device, etc., can read a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, or the like.

It can be seen that, by using the technical solution of the embodiment of the present invention, for two servers respectively storing list information of corresponding accounts, when the list information on one of the servers changes, another server can synchronously update according to the changed list information. List information stored by itself. In this way, whether the two servers are located in different message systems or in the same message system can synchronously update the list information of the corresponding account, thereby enriching the message service performance of the message system subscribers.

In summary, the above is only a preferred embodiment of the present invention, and is not intended to limit the present invention. Range of protection. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and scope of the present invention are intended to be included within the scope of the present invention.

Claims

Rights request

A method for implementing synchronization of list information, the method comprising the steps of: the first list information storage server learns that the list information in the second list information storage server changes;

2. The method according to claim 1, further comprising:

List information of a corresponding account that needs to be synchronously updated is preset in the first list information storage server or the second list information storage server;

When the first list information storage server learns that the list information of the corresponding account on the second list information storage server changes, the list information of the corresponding account is updated synchronously according to the change of the corresponding account list information.

The method according to claim 2, wherein the step of the first list information storage server learning that the list information of the corresponding account on the second list information storage server is changed is:

And receiving, by the second list information storage server, a list information update notification sent to the first list information storage server when the list information of the corresponding account changes.

The method according to claim 3, further comprising: before the step of the first list information storage server learning that the list information of the corresponding account on the second list information storage server is changed, further comprising:

The first list information storage server subscribes to the list information change notification event of the corresponding account to the second list information storage server in advance.

The method according to claim 2, wherein the step of the first list information storage server to learn that the list information of the corresponding account on the second list information storage server changes is:

The first list information storage server requests list information of the corresponding account from the second list information storage server; and receives list information of the corresponding account returned by the second list information storage server.

6. The method according to claim 5, wherein the first list information storage service The requesting, by the second list information storage server, the list information of the corresponding account is periodic.

The method according to claim 1, wherein the method further comprises: if the items included in the list information of the corresponding account are not identical, only the same item content is updated synchronously.

The method according to any one of claims 1 to 7, characterized in that

The first list information storage server is located in an initial session protocol SIP message system, and the second list information storage server is located in a non-SIP message system;

Alternatively, the first list information storage server is located in a non-SIP message system, and the second list information storage server is located in a SIP message system.

The method according to claim 8, wherein the first list information storage server and the second list information storage server perform information interaction through a network interconnection function entity IWF, and the IWF will receive the first The information of the list information storage server or the second list information storage server is converted into a SIP protocol format and transmitted to the other party.

The method according to any one of claims 1 to 7, wherein the first list information storage server and the second list information storage server are located in the same message system.

11. A system for implementing synchronization of list information, the system comprising: a first list information storage server and a second list information storage server, wherein

The first list information storage server is configured to synchronously update the list information stored by itself according to the change of the list information in the second list information storage server when the list information of the second list information storage server is changed.

12. The system of claim 11 wherein:

The first list information storage server is located in the non-SIP message system, and the second list information storage server is located in the SIP message system; or the first list information storage server is located in the SIP message system, and the second list is The information storage server is located in a non-SIP message system;

The system further includes:

The IWF is configured to forward a command between the first list information storage server and the second list information storage server, and perform protocol conversion on the forwarding command according to the command recipient.

13. The system according to claim 12, wherein the SIP message system is an IP Multimedia Subsystem IMS message system, and the non-SIP message system is an instant message and a presence service IMPS message system.

14. The system according to claim 11, wherein the first list information storage server and the second list information storage server are located in the same message system.

The system according to claim 14, wherein the same message system is an IMS message system or an IMPS message system.

A server for implementing synchronization of list information, wherein the server comprises: a updating module and a list information storage module;

The server according to claim 16, wherein the server further comprises: an ordering module and a notification module;

The ordering module is configured to order a list information change notification event of the corresponding account to the server where the corresponding account list information is located;

The notification module is configured to receive an order request from a server where the corresponding account list information is located, and send a list information update notification to the server where the corresponding account list information is located when the list information in the list information storage module changes;

The update module, when receiving the list information update notification from the server where the corresponding account list information is located, synchronously updates the list information in the list information storage module according to the list information update notification.

The server according to claim 16, wherein the server further comprises: a notification module;

The notification module is configured to send a list information update notification to the server where the corresponding account list information is located when the list information in the list information storage module changes;

The server according to claim 16, wherein the server further includes: a requesting module and a sending module;

The requesting module is configured to request a list of corresponding accounts from a server where the corresponding account list information is located Information

The sending module is configured to receive a list information request from the server where the corresponding account list information is located, and send back the list information in the list information storage module to the server where the corresponding account list information is located;

The update module, when receiving the list information of the corresponding account returned by the server where the corresponding account list information is sent, synchronously updates the list information in the list information storage module according to the list information of the corresponding account.