WO2008144992A1 - Procédé et dispositif pour traiter un message de notification - Google Patents

Procédé et dispositif pour traiter un message de notification Download PDF

Info

Publication number
WO2008144992A1
WO2008144992A1 PCT/CN2007/071271 CN2007071271W WO2008144992A1 WO 2008144992 A1 WO2008144992 A1 WO 2008144992A1 CN 2007071271 W CN2007071271 W CN 2007071271W WO 2008144992 A1 WO2008144992 A1 WO 2008144992A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
notification message
client
field
synchronization
Prior art date
Application number
PCT/CN2007/071271
Other languages
English (en)
French (fr)
Inventor
Qin Zhao
Kepeng Li
Xiaoqian Chai
Hui Zhao
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to JP2009535552A priority Critical patent/JP4943512B2/ja
Priority to EP07846097A priority patent/EP2079207A4/en
Publication of WO2008144992A1 publication Critical patent/WO2008144992A1/zh
Priority to US12/420,343 priority patent/US20100011070A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/142—Managing session states for stateless protocols; Signalling session states; State transitions; Keeping-state mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/224—Monitoring or handling of messages providing notification on incoming messages, e.g. pushed notifications of received messages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding

Definitions

  • the present invention relates to the field of communications, and in particular, to a method and a device for processing a notification message in a data synchronization technology.
  • Data Synchronization is a very important one. index. DS technology refers to maintaining data synchronization between mobile devices and web servers. Synchronized data includes phonebooks, contacts, calendars, text messages, emails, and so on.
  • a notification mechanism is provided for the server to send a notification.
  • the (notification) message is sent to the terminal device, and the terminal device initiates a session connection with the server according to the SessionID (session identifier), Server1D (service identifier), and the like in the notification.
  • Notification messages can be sent via SMS, OTA PUSH (Over-the-Air Technology PUSH, etc.).
  • the session management process between the DS server and the DS client is shown in Figure 1.
  • the DS server sends a Notification message to the DS client to request a session connection.
  • the DS client initiates a session connection to the DS server, and sends authentication information and device information of the DS client to the DS server.
  • the device information and the authentication information are included in the management session Package # l (Package 1).
  • the DS server sends a Package #1 message to the DS client, where the message carries an initialization packet for performing a session operation.
  • the subsequent session operation is performed through the Package #3 ⁇ Package#4 message, as shown in step 140.
  • ⁇ length-identifier>:: 8*BIT ; 'The length of the server ID' ⁇ server-identifier> :: ⁇ length-identifier>*CHA ; 'Server ID'
  • the format of the notification-body of the DS Notification message is shown in Figure 3.
  • the field “num-syncs” indicates that there are several synchronization operations, the field “future-use” is reserved for future expansion, the field “syncl”, the field “syncN” is a specific multiple synchronization operation, and the field “sync-type” is Synchronization type
  • the field “content-type” indicates the content type of the database to be synchronized
  • the field “server-URI-length” indicates the length of the field "server-URI”
  • the "server-URI” field is used to store the server to be synchronized.
  • the name of the database It can be seen that the DS notification message indicates the type of synchronization, the database to be synchronized, and the like.
  • the inventors of the present invention have found that at least the problem of waste of air interface resources exists in the current session management mechanism.
  • the client and the server have passed the transport layer authentication, and the client does not need to report the authentication information.
  • the client and the server have passed the transport layer authentication, but the server still needs the client to report the authentication information and perform the application layer authentication to establish a management/synchronization session.
  • the server will return a "missing client authentication information" error message.
  • the client needs to report the authentication information again, and interacts with the server one more time, resulting in waste of air interface resources.
  • the server does not require the client to report complete device information, but the client sends complete device information to the server, resulting in waste of air interface resources.
  • the type of synchronization initiated by the client after receiving the Notification message is selected according to the unilateral data modification information of the client, and the synchronization type (such as slow synchronization, fast synchronization, refresh synchronization, etc.) ) is also very old.
  • both parties requiring synchronization can selectively transmit data information and data fingerprint information by analyzing the data modification information of the other party and the information of the database. For example, if the server specifies a synchronization direction that is bidirectional, the client will not initiate one-way synchronization. In the case that the client cannot select a suitable synchronization mechanism, the session efficiency will be reduced.
  • the client cannot accurately know the operation that the server expects the client to perform, and the specific execution manner, which may cause multiple interactions between the client and the server, which wastes the air interface. Resources, reducing session efficiency.
  • the embodiments of the present invention provide a method and a device for processing a notification message, which can save network resources and improve session efficiency.
  • An embodiment of the present invention provides a method for processing a notification message, including:
  • the DS client performs the corresponding operation according to the indication information carried in the notification message.
  • An embodiment of the present invention further provides a DS client, including:
  • a receiving module configured to receive a notification message that is triggered by the DS server to establish a session connection, where the notification message carries indication information for instructing the DS client to perform at least one operation;
  • a parsing module configured to parse the notification message received by the receiving module, and obtain an indication message
  • the processing module is configured to perform a corresponding operation according to the indication information parsed by the parsing module from the notification message.
  • An embodiment of the present invention further provides a DS server, including:
  • a generating module configured to generate a notification message that triggers establishing a session connection, where the notification message carries indication information for instructing the DS client to perform at least one operation
  • the sending module is configured to send the notification message generated by the generating module to the DS client.
  • the DS client receives a notification message from the DS server that triggers the establishment of a session connection, and the notification message carries indication information for instructing the DS client to perform at least one operation.
  • the DS client performs the corresponding operation according to the indication information carried in the notification message. Since the DS client can learn the operation that the DS server expects the DS client to perform by triggering the notification message of establishing the session connection, and the manner of execution, it can avoid the DS client caused by the way the operation is performed does not meet the server requirements. Multiple interactions between the endpoint and the DS server save network resources and improve session efficiency.
  • FIG. 1 is a flow chart of session management between a DS server and a DS client in the prior art
  • FIG. 2 is a schematic diagram of a DS notification message format in the prior art
  • FIG. 3 is a schematic diagram of a format of a notification-body of a DS notification message in the prior art
  • FIG. 4 is a schematic diagram of a format of a Notification message according to various embodiments of the present invention.
  • FIG. 5 is a flowchart of a Notification message processing method according to a first embodiment of the present invention
  • FIG. 6 is a schematic diagram of a Notification message format according to a first embodiment of the present invention
  • FIG. 7 is a diagram of carrying two "Actions" according to a second embodiment of the present invention. "The format of the notification message of the field;
  • FIG. 8 is a schematic diagram of an "Action" field carrying an operation indication for initiating a null session according to a second embodiment of the present invention.
  • FIG. 9 is a flowchart of a method for processing a Notification message according to a second embodiment of the present invention.
  • FIG. 10 is an operation instruction for carrying report authentication information according to a second embodiment of the present invention.
  • FIG. 11 is a schematic diagram of an "Action" field of an operation indication carrying a reporting device information according to a second embodiment of the present invention.
  • FIG. 12 is a flowchart of a method for processing a Notification message according to a third embodiment of the present invention.
  • FIG. 13 is a schematic diagram showing the structure of a Notification message processing system according to a fifth embodiment of the present invention.
  • the notification message that triggers the establishment of the session connection is extended to the format shown in FIG. 4, and the notification message carries the indication information for instructing the DS client to perform at least one operation.
  • the message body of the Notification message includes: a 4-bit operation number field ("num-actions” field), which is used to carry the number of operations indicated by the DS client, and is reserved for expansion. "future-use” field; N action fields ("Action” field), each action field is used to carry an operation indication of the corresponding operation; and a "vendor-specific” field reserved for extension. It is not difficult to find that the Notification message structure in the embodiment of the present invention is very similar to the Notification message structure in the prior art (as shown in FIG. 3), and the "num-actions" field is equivalent to the "num-syncs" field in FIG.
  • the "Action” field is equivalent to the “sync” field in Figure 3, as well as the "future-use” field and the "vendor-specific” field. Since there is no need to make major changes to the prior art Notification message structure, embodiments of the present invention can be made to be more compatible with the prior art.
  • each action field is: an action type field ("Action-type” field), an action related information field ("Action-specific” field), an information length field ("information-length” field), and an information field (" Information” field).
  • Action-type field An action type field
  • Action-specific field An action related information field
  • information length field An information length field
  • Information field An information field
  • ⁇ Action-type>:: 4*BIT ; 'used to carry the type of operation the operation belongs to'
  • the operation type may be a type of the synchronization operation, a type of the authentication information reporting operation, a type of the device information reporting operation, a type of the session information display operation, or a type of the null session initiation operation.
  • the operation field carries an operation instruction for reporting device information; when the value of the "Action-type” field in the operation field is 0010, it indicates that the operation field carries an operation instruction for displaying session information; when the operation field is "Action-"
  • the value of the type" field is 0011, it indicates that the operation field carries an operation indication for initiating a null session; when the value of the "Action-type” field in the operation field is 0100 When it is indicated, the operation field carries an operation indication for performing synchronization.
  • the present embodiment relates to a notification message processing method.
  • an "Action" field indicating that the DS client performs a synchronization operation is carried in the message body of the Notification message.
  • the DS client uses the "Action" field to initiate a synchronization session as an example. The specific process is shown in Figure 5.
  • step 510 the DS server generates a Notification message, and carries an indication message indicating that the DS client performs the synchronization operation.
  • the value of the "num-actions" field in the message body is 1 and only one "Actions” field is included. Carry an indication of the operation to synchronize.
  • the "Action-type” field value in the "Actions” field is 0100 (for the above case); the "Action-specific” field carries the parameter information related to the synchronization operation; the "information” field carries the synchronized database identifier. For example, the Uniform Resource Identifier ("URI") of the database; the "information-length” field carries the length of the "information” field, such as the length of the database URI.
  • URI Uniform Resource Identifier
  • the “Action-specific” field further includes the following fields: “Direction” field, "Behavior” field, "ID-Valid” field, “Log-Valid” field, "Content-type” field, as shown in Figure 6. The fields are described below.
  • the "Direction” field is used to indicate the direction of synchronization.
  • the "Behavior” field is used to indicate the synchronization behavior, such as clearing or saving the server/client data, the length is 1 *BIT, which is described as follows:
  • the "ID-Valid" field is used to indicate whether the identification information (ID) of the server-side data entry is valid and has a length of 1 * BIT. Its specific description is as follows:
  • the identification information is invalid due to database corruption, etc., it will affect the selection of the synchronization mechanism of both parties. For example, if the identification information of the server is invalid, after the client initiates the session, the server will ask the client to send the fingerprint first, and then the server determines which data server exists and which data does not exist according to the fingerprint, and then instructs the client to send and send. The data.
  • the "Log-Valid" field is used to indicate whether the server-side modification log is valid and has a length of 1 * BIT. Its specific description is as follows:
  • the "Content-type” field is used to indicate the type of data in the database, such as vcard type or email type, and the length is 23*BIT.
  • the "Behavior" field and the "Direction” field can be designed in
  • the DS server sends the generated Notification message to the DS client.
  • the DS server may send the generated Notification message as shown in FIG. 6 to the DS client through the OTAPUSH or the Session Initiation Protocol ("SIP") PUSH or the short message. end.
  • SIP Session Initiation Protocol
  • the DS client parses the received Notification message and selects a synchronization mechanism. Specifically, the DS client parses the received Notification message to obtain an operation indication for synchronization carried in the "Action" field in the message, and selects a suitable synchronization mechanism according to the operation instruction.
  • the selection of the synchronization mechanism includes one of the following or any combination thereof: selection of the synchronization direction, selection of the synchronization data, and selection of the synchronization behavior.
  • the selection of the synchronization data includes: whether to send all data items, whether to send only the modified data items.
  • the selection of the synchronization behavior includes whether to send the data fingerprint information, whether the other party needs to compare the data items, and whether the other party needs to overwrite the data items stored by the other party with the received data items.
  • the DS client selects an appropriate synchronization mechanism according to the operation instructions carried in the "Action" field for a brief description.
  • the DS client should choose to send data fingerprint information or select to send all data. Or, if the DS server changes more data items, the DS client should select two-way synchronization or DS server one-way synchronization, and should send data fingerprint information to avoid conflicts between the two parties. Of course, there are many other situations, no longer here - enumeration.
  • step 540 the DS client initiates a synchronization session to the DS server using the selected synchronization mechanism.
  • a second embodiment of the present invention relates to a Notification message processing method.
  • the present embodiment is substantially the same as the first embodiment. The difference is that, in the first embodiment, the Notification message only indicates that the DS client performs the synchronization operation. In this embodiment, the Notification message not only indicates that the DS client performs the synchronization operation, but also instructs the DS client to perform other operations.
  • the DS server not only carries the "Action” field for instructing the DS client to perform the synchronization operation, but also carries the “Action” field for instructing the DS client to perform the session information display operation, as shown in the figure. 7 is shown.
  • the “Actionl” field carries the operation indication of the synchronization operation, which is exactly the same as the "Actionl” in the first embodiment, and will not be described here.
  • the “Action2" field is specifically described below.
  • the value of the "Action-type" field in the "Action2" field indicates that the "Action” field carries the operation indication for displaying the session information; the "information” field carries the content of the session information, "information- The length” field carries the content length of the session information.
  • the DS client After parsing the "Action2" field from the Notification message, the DS client can display the session information in the "information" field to the user in a displayable manner, for example: “You have a new email, please check it. "And, initiate a synchronization session to synchronize the new mail on the server to the DS client. Since the DS client performs the session information display operation, the information of the "Action-specific" field in the "Action2" field is not required. Therefore the DS client can ignore the parsing of the "Action-specific" field.
  • the DS client parses the "Actionl" from the Notification message. After the field, the session synchronization needs to be initiated according to the operation action of the synchronization operation carried by the field. This process has been described in the first embodiment. , will not repeat them here.
  • the "Action" field for instructing the DS client to initiate a null session operation may also be carried in the Notification message, and the DS client parses the “Action” field, and then passes the "Action-type” in the "Action” field. "Field value, you can know that the DS server expects this DS client to initiate a null session. Assuming that the value of the "Action-type” field is 0011, indicating the operation instruction of the empty session carried by the "Action” field, the "Action” field is as shown in FIG.
  • the DS server can perform data synchronization or device capability negotiation with the DS client. For example, after the null session is established, if the DS server needs the device information of the DS client, you can obtain it by issuing a Get command: ⁇ Get>
  • the DS client Since the DS client does not need the information of the "Action-specific" field in the "Action2" field when performing a null session, the DS client can ignore the parsing of the "Action-specific" field.
  • the "Field” can also carry multiple "Action” fields.
  • the "Action” field carried can be an operation indication for the synchronization operation, an operation indication for initiating a null session, or an operation indication for displaying the session information, or even It is an operation instruction for reporting authentication information or device information.
  • the operation instruction for reporting the authentication information or the device information by the "Action” field will be described in the following third embodiment.
  • a third embodiment of the present invention relates to a notification message processing method.
  • the message body of the notification message carries an "Action" field indicating that the DS client reports the authentication information, and the DS client reports the device information. "Action" field.
  • the DS client reports the authentication information and device information based on the two "Action” fields. The specific process is shown in Figure 9.
  • step 910 the DS server generates a notification message that triggers the establishment of a session connection, and the message carries an operation indication for reporting the authentication information and the device information.
  • the value of the "Action-type" field in the "Actions” field indicates that the "Action” field carries the operation indication for reporting the authentication information; the “information” field carries the authentication information that the client is required to report.
  • Authentication mechanism such as "auth-basic” authentication mechanism, or “auth-MD5" authentication mechanism, or “SHA-256” authentication mechanism, or “SHA-1” authentication mechanism, or non-specific mechanism Authentication mechanism; the "information-length” field carries the length of the authentication mechanism in the "information” field.
  • the description of the "information-length” field and the "information” field is as follows:
  • ⁇ information >:: ⁇ auth-basic>/ ⁇ auth-MD5>/ ⁇ SHA-256>/ ⁇ SHA-l>/ ⁇ not specified ;'Authentication mechanism
  • the DS server does not do the authentication mechanism.
  • the DS client can perform authentication according to the authentication mode specified by the authentication type "AAuthPref value" on the parameter configuration management object in the DS standard or the authentication method used in the last successful session.
  • the operation instruction of carrying the device information in the "Action” field is as shown in FIG. 11, and the value of the "Action-type” field in the "Actions” field (such as 0001) indicates that the "Action” field carries An operation instruction for reporting device information; the "Action-specific” field carries the device information reporting method, such as reporting complete device information, or reporting updated device information, or reporting empty device information, or reporting device information.
  • the "information” field carries the location information stored by the device information in the DS client;
  • the "information-length” field carries the length of the location information in the "information” field. Description of the "Action-specific” field, the "information-length” field, and the "information” field:
  • Action-specific > :: ⁇ completed>/ ⁇ updated>/ ⁇ null>/URI ; 'Device information escalation method'
  • ⁇ information-length >:: ; 'Device information location link field length' ⁇ information >:: ⁇ information-length >*CHAR ; 'Location link of device information,
  • the URI link indicating that the DS client device information is stored on the DS client is instructed, and then the DS server accesses the device that obtains the DS client according to the address. Information, which saves air interface resources.
  • the ⁇ inquiry> field indicates the location where device information is stored on the DS client. For example, if the DS server requires the DS client to report all device information, the ⁇ Action-Specific> field is ⁇ complete> and the ⁇ information> field is ./.../devinf. The DS server requires the DS client to report the updated device information.
  • the ⁇ Action-Specific> field is ⁇ updated >, and the ⁇ information > field is . /.../devinf/datastore/CTCAP, which means the update information under the CTCAP element.
  • a hierarchical URI such as ./.../devinf/datastore/SyncCap, which means that the DS client needs to report the device information under the SyncCa element.
  • a matching condition in the URI When there are multiple elements with the same name on the DS client, they can be represented by a matching condition in the URI.
  • the DS server expects the DS client to report ⁇ DisplayName> to "addressbook"
  • the DataStore information can be specified using the following URI:
  • step 920 the DS server will generate the fields containing the two "Action" fields.
  • the notification message is sent to the DS client.
  • the DS server can send the generated Notification message containing two "Action" fields to the DS client to request a session connection by means of an OTA PUSH (or SIP PUSH) or a short message.
  • OTA PUSH or SIP PUSH
  • step 930 the DS client parses the received Notification message to generate a message that initiates a session connection, and the message that initiates the session connection is a Package #1 message.
  • the DS client parses the "Action" field carried in the Notification message, and determines the subsequent package according to an operation instruction for reporting the authentication information carried in the two "Action” fields, and an operation instruction for reporting the device information. #1 How to report authentication information and device information in the message.
  • step 940 the DS client sends the generated Package #1 message to the DS server.
  • Step 950 and step 960 are the same as step 130 and step 140, respectively, and are not described herein again.
  • the DS client can learn the specific manner of reporting the authentication information and the device information required by the DS server through the Notification message, the mechanism to which the authentication information belongs as described above, and the manner in which the device information is reported. Therefore, it can be avoided that the DS client and the DS server are caused by the reporting method of the authentication information and the device information not meeting the requirements of the DS server. Multiple interactions, saving network resources.
  • the operation instruction for reporting the authentication information or reporting the device information may be carried in the Notification message.
  • a fourth embodiment of the present invention relates to a Notification message processing method.
  • the DS server does not specifically define the authentication mechanism. Therefore, the DS client searches the parameter configuration management object locally for the authentication type "AAuthPref node. If the node has a value and the node has a value, The authentication information is reported according to the authentication mode indicated by the value; if there is no such node, or if the node has no value, the security authentication is performed according to the default authentication mode. For example, the default authentication mode is in the Package # 1 message.
  • the DS client will carry the authentication information of the authentication mechanism "auth-basic" in the generated Package #1 message.
  • the default authentication is performed.
  • the mode authentication succeeds. That is, the Package # 2 message sent by the DS server to the DS client carries the authentication success status code.
  • step 1260 after the DS client learns that the authentication is successful according to the received Package #2 message, the default authentication mode is recorded.
  • the probability of successful authentication is improved. Specifically, there are two ways to record:
  • the default authentication mode is recorded in the authentication type "AAuthPref" node for specifying the authentication mode.
  • the authentication method of the authentication information with the authentication mechanism "auth-basic" is reported as the "AAuthPref node”.
  • the value of the record is recorded in the "AAuthPref" node.
  • Step 1270 is the same as step 960, and details are not described herein again.
  • the DS client may reply the acknowledgment message to the DS server, indicating that the notification message is successfully received, and then performing the indicated operation. Or, in some special cases, the DS client may not perform the instructions indicated by the DS server. Action, but just return a confirmation message. For example, the "Digest" authentication in the Notification message sent by the DS client to the DS server fails; or the DS client is busy, not suitable for performing the instruction of the DS server; or the user refuses, does not want to perform the instruction operation of the DS server. and many more. In these cases, the DS client can reply to the Notification message and reply to receive status information.
  • the DS client can carry the new authentication information ⁇ NextNonce ⁇ DS server, which is used when the DS server sends the Notification message next time.
  • the DS client can also carry the status code information to the DS server to indicate the status.
  • Information such as authentication failure, client busy, user rejection, etc., as shown in Table 1.
  • the DS client can reply to the Notification message in the packet 1 message.
  • the message instance is:
  • the DS server may not reply to this message again.
  • the DS client is a terminal device. If the DS client does not have the function of receiving a notification message, the DS client needs to receive the notification message through the Notification client.
  • the Notification client depends on the service implementation. For example, if the notification is sent through the OTA PUSH in the service implementation, the Notification client will be the OTA PUSH client; if it is sent by short message, The Notification client will be a short message client.
  • the DS server does not have the function of sending a Notification message, the DS server needs to send a Notification message through the Notification Server.
  • the value of the "num-actions" field indicates the number of operations that the DS server requires the DS client to perform. For example, if the value of the "num-actions" field is 1, it indicates Require the DS client to perform 1 operation, the type of operation and specific operation instructions It is carried by an "Action” field. If the value of the "num-actions” field is 2, it means that the DS client is required to perform 2 operations. The types of these two operations and the specific operation instructions are respectively passed through 2 "Actions". The field is carried. However, in an actual application, the DS client may be instructed to perform a null session by setting the value of the "num-actions" field to 0.
  • the "Action” field may not be carried in the Notification message.
  • the "Action-specific" field in the "Action” field since for some operations, such as the session information display operation, the "Action-specific" field in the "Action” field has no substantial meaning, the field can be omitted in practical applications. That is, if some of the fields in the "Action” field are not used, they can be omitted.
  • a fifth embodiment of the present invention relates to a Notification message processing system, as shown in FIG. 13, including a DS client 131 and a DS server 132.
  • the DS server 132 includes: a generating module 21, configured to generate a Notification message that triggers establishing a session connection, where the message carries indication information for instructing the DS client to perform at least one operation; and a sending module 22, configured to use the generating module The generated Notification message is sent to the DS client.
  • the DS client 131 includes: a receiving module 11 configured to receive a Notification message from the DS server that triggers the establishment of a session connection; a parsing module 12, configured to parse the Notification message received by the receiving module 11, and a processing module 13 configured to The parsing module 12 performs the corresponding operation from the indication information parsed in the Notification message.
  • the operation performed by the client is one or any combination of the following: a synchronization operation, an authentication information reporting operation, a device information reporting operation, a session information display operation, or a null session initiation operation.
  • the DS client can learn through the Notification message that the DS server expects the operation performed by the DS client and the specific execution manner, the manner in which the operation is performed may be avoided. Server requirements, resulting in multiple interactions between the client and the server, thereby saving network resources and improving session efficiency.
  • the notification message carries an operation indication for performing synchronization, which enables the DS client to select a corresponding synchronization mechanism according to the information, thereby reducing the synchronization mechanism selection. Session interaction improves session efficiency.
  • the DS client can learn the specific manner of reporting the authentication information and/or the device information required by the DS server through the Notification message.
  • the mechanism to which the information belongs, and the method used to report the device information Therefore, it is possible to avoid multiple interactions between the DS client and the DS server due to the failure of the authentication information and the device information reporting method to meet the requirements of the DS server, thereby saving network resources.
  • the embodiment of the present invention can be better compatible with the prior art without major changes to the prior art Notification message structure.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

通知消息处理方法及设备
本申请要求于 2007 年 5 月 30 日提交中国专利局、 申请号为 200710108398.0、 发明名称为"会话连接、 同步会话发起方法及设备"的中国专 利申请的优先权， 要求于 2007 年 8 月 7 日提交中国专利局、 申请号为 200710137555.0、 发明名称为"通知消息处理方法及设备，，的中国专利申请的优 先权， 其全部内容通过引用结合在本申请中。
技术领域
本发明涉及通信领域，特别涉及数据同步技术中一种通知消息处理方法及 设备。
背景技术
随着现代通信技术在人类工作和生活中扮演着日益重要的角色，人们对数 据传输的质量提出了越来越高的要求， 其中数据同步（Data Synchronization, 简称" DS" )是一个十分重要的指标。 DS技术是指移动设备与网络服务器之间 保持数据同步， 同步的数据包括电话本、 通讯录、 日程、 短信、 邮件等。
在现有的 DS消息中， 提供了一种通知机制， 用于服务器下发 Notification
(通知）消息给终端设备， 终端设备根据 Notification中的 SessionID (会话标 识）、 ServerlD (服务标识）等信息发起与服务器的会话连接。 Notification 消 息的下发可以通过短消息、 OTA PUSH ( Over-the- Air Technology PUSH, 空中 下载推送）等方式。
目前， DS服务器与 DS客户端之间进行的会话管理流程如图 1所示。 在 步骤 110中， DS服务器向 DS客户端下发 Notification消息， 请求会话连接。 接着， 在步骤 120中， DS客户端向 DS服务器发起会话连接， 发送该 DS客户 端的认证信息、 设备信息给该 DS服务器， 该设备信息、 认证信息包括在管理 会话的 Package # l (包 1 ) 消息中。 接着， 在步骤 130中， 该 DS服务器向该 DS客户端发送 Package # 1消息，在该消息中携带用于进行会话操作的初始化 包。然后，通过 Package # 3 ~ Package#4消息进行后续的会话操作，如步骤 140 所示。
现有的 DS的 Notification消息格式如图 2所示。
对 Notification消息头中的各字段的解释如下： <digest> ::= 128*BIT (比特） ；' MD5摘要值'
<version>：: = 10*BIT ； '版本信息'
<ui-mode> ::= <not-specified> I <background> I ；'用户交互模式'
<informative> I <user-interaction>；
<not-specified> ::= "00" ；'非特定'
<background>：: = "01" ；'后台模式'
<informative>：: = "10" ；'提示模式'
<user-interaction> ::= "11" ；'确认模式 '
<initiator> ::= <client> I <server> ； '会话发起方 ' <client> ::= "0" ；'客户端发起，
<server> ::= "1" ； '服务器发起'
<future-use>：: = 27*BIT ； '留作扩展，
<sessionid> ::= 16*BIT ；'会话标识'
<length-identifier>：: = 8*BIT ；'服务器标识的长度' <server-identifier> ::= <length-identifier>*CHA ；'服务器标识'
<vendor-specific> ::= n*BIT ；'留作扩展'
DS Notification消息的 notification-body的格式如图 3所示。 其中， 字段 "num-syncs"表明有几个同步操作， 字段" future-use"留作以后扩展， 字段 "syncl", 字段" syncN"是具体的多个同步操作， 字段" sync-type"为同步类型， 字段" content-type"表明要同步的数据库的内容类型， 字段" server-URI-length" 表明字段" server-URI"的长度， 该" server-URI"字段用于存放要同步的服务器的 数据库名。 由此可见， 在 DS的 Notification消息里表明了同步的类型、待同步的 数据库等信息。
然而， 本发明的发明人发现， 目前的会话管理机制中至少存在空口资源浪 费的问题。 比如说， 客户端与服务器已经通过了传输层认证， 客户端无需再上 报认证信息。此时，如果客户端再上报认证信息则是对空口资源的浪费。或者， 客户端与服务器已经通过了传输层认证，但是服务器仍然需要客户端上报认证 信息， 进行应用层认证， 才能建立管理 /同步会话。 此时， 如果客户端没有上 报认证信息， 则服务器会返回客户端一个 "缺少客户端认证信息"的错误消息， 客户端需要再一次的上报认证信息， 多了一次与服务器的交互， 导致了空口资 源的浪费。 或者， 服务器不需要客户端上报完整的设备信息， 但客户端却向服 务器发送了完整的设备信息， 导致了空口资源的浪费等。
另外， 在目前的现有技术中， 客户端收到 Notification消息后发起的同步的 类型是根据客户端单方面的数据修改信息来选择的，而且同步类型（如慢同步、 快同步、 刷新同步等）也很陈旧。 在智能同步中， 要求同步的双方能通过分析 对方的数据修改信息及数据库的信息来选择性的发送数据信息及数据指紋信 息。 比如， 如果服务器指定的同步方向为双向， 客户端就不会发起单向同步。 而在客户端无法选择合适的同步机制的情况下， 将会导致会话效率的降低。
由此可见， 由于在目前的现有技术中，客户端无法确切的获知服务器期望 本客户端执行的操作， 以及具体执行的方式， 因此可能会导致客户端与服务器 的多次交互， 浪费了空口资源， 降低了会话效率。
发明内容
本发明实施方式提供一种通知消息处理方法及设备，使得能够节省网络资 源， 并能够提高会话效率。
本发明的实施方式提供了一种通知消息处理方法， 包括：
接收来自数据同步 DS服务器的触发建立会话连接的通知消息， 该通知消 息中携带用于指示 DS客户端执行至少一个操作的指示信息；
DS客户端根据通知消息中携带的指示信息， 执行对应的操作。
本发明的实施方式还提供了一种 DS客户端， 包括：
接收模块， 用于接收来自 DS服务器的触发建立会话连接的通知消息， 该 通知消息中携带用于指示 DS客户端执行至少一个操作的指示信息；
解析模块， 用于解析接收模块收到的通知消息， 得到指示消息；
处理模块， 用于根据解析模块从通知消息中解析出的指示信息，执行对应 的操作。
本发明的实施方式还提供了一种 DS服务器， 包括：
生成模块， 用于生成触发建立会话连接的通知消息， 该通知消息中携带用 于指示 DS客户端执行至少一个操作的指示信息；
发送模块， 用于将生成模块生成的通知消息， 发送给 DS客户端。 本发明实施方式中， DS客户端接收来自 DS服务器的触发建立会话连接 的通知消息， 该通知消息中携带用于指示 DS客户端执行至少一个操作的指示 信息。 DS客户端根据该通知消息中携带的指示信息， 执行相应的操作。 由于 DS客户端能够通过触发建立会话连接的通知消息了解到 DS服务器期望本 DS 客户端执行的操作， 以及具体执行的方式， 因此可避免由于执行操作的方式不 符合服务器要求， 而造成的 DS客户端与 DS服务器的多次交互， 从而节省了 网络资源， 提高了会话效率。
附图说明
图 1是现有技术中 DS服务器与 DS客户端之间进行的会话管理流程图； 图 2是现有技术中 DS Notification消息格式示意图；
图 3是现有技术中 DS Notification消息的 notification-body的格式示意图； 图 4是根据本发明各实施方式的 Notification消息格式示意图；
图 5是根据本发明第一实施方式的 Notification消息处理方法流程图； 图 6是根据本发明第一实施方式的 Notification消息格式示意图； 图 7是根据本发明第二实施方式的携带两个" Action"字段的 Notification消 息格式示意图；
图 8是根据本发明第二实施方式的携带发起空会话的操作指示的" Action" 字段示意图；
图 9是根据本发明第二实施方式的 Notification消息处理方法流程图； 图 10 是根据本发明第二实施方式的携带上报认证信息的操作指示的
"Action"字段示意图；
图 11 是根据本发明第二实施方式的携带上报设备信息的操作指示的 "Action"字段示意图；
图 12是根据本发明第三实施方式的 Notification消息处理方法流程图； 图 13是根据本发明第五实施方式的 Notification消息处理***的结构示意 图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚， 下面将结合附图对本发明 的实施方式作进一步地详细描述。 在本发明的各实施方式中，通过将触发建立会话连接的 Notification消息， 扩展为如图 4所示的格式，在该 Notification消息中携带用于指示 DS客户端执 行至少一个操作的指示信息。
具体地说， 在该 Notification消息的消息体中包括： 长度为 4比特的操作 个数字段（ "num-actions"字段 ), 用于携带指示 DS客户端执行的操作个数 N; 留作扩展的" future-use"字段； N个操作字段（ "Action"字段）， 每个操作字段用 于携带相应操作的操作指示；以及留作扩展的" vendor-specific"字段。不难发现， 本发明实施方式中的 Notification消息结构与现有技术中的 Notification消息结 构 （如图 3所示）十分类似， "num-actions"字段相当于图 3 中的" num-syncs" 字段， "Action"字段相当于图 3 中的" sync"字段， 同样保留了" future-use"字段 和" vendor-specific"字段。 由于并不需对现有技术中的 Notification消息结构作 较大改动， 因此可使得本发明的实施方式能够与现有技术较好地兼容。
各操作字段携带相应操作的操作指示的方式如下：
在每个操作字段中包括： 操作类型字段（"Action-type"字段）、 操作相关 信息字段（ "Action-specific"字段）、信息长度字段（ "information- length"字段），、 信息字段（ "information"字段）。 每个操作字段中各字段的说明如下：
<Action-type>：: = 4*BIT ； '用于携带操作所属的操作类型'
<Action-specific>：: = 28*BIT ； '用于携带与操作相关的参数信息' information -length>： := 8*BIT ； '用于携带" information"字段的长度' <information> ::= <information-length>* CHAR ； '用于携带执行操作 时所需的信息'
其中， 操作类型可以是同步操作的类型、 认证信息上报操作的类型、 设备 信息上报操作的类型、 会话信息显示操作的类型、 或空会话发起操作的类型。 比如说， 当操作字段中 "Action-type"字段的值为 0000 时， 表示该操作字段携 带的是上报认证信息的操作指示； 当操作字段中 "Action-type"字段的值为 0001 时， 表示该操作字段携带的是上报设备信息的操作指示； 当操作字段中 "Action-type"字段的值为 0010 时， 表示该操作字段携带的是显示会话信息的 操作指示； 当操作字段中 "Action-type"字段的值为 0011 时， 表示该操作字段 携带的是发起空会话的操作指示； 当操作字段中 "Action-type"字段的值为 0100 时， 表示该操作字段携带的是进行同步的操作指示。
下面对本发明的第一实施方式进行说明，本实施方式涉及一种 Notification 消息处理方法， 在本实施方式中， 以在 Notification消息的消息体中携带一个 指示 DS客户端进行同步操作的" Action"字段， DS客户端根据该" Action"字段 发起同步会话为例进行说明， 具体流程如图 5所示。
在步骤 510中， DS服务器生成 Notification消息， 并在该消息中携带指示 DS客户端进行同步操作的指示信息。
具体地说，由于本实施方式中通过 Notification消息指示 DS客户端执行的 操作只有进行同步这一个操作， 因此， 消息体中的" num-actions"字段值为 1 , 只包含一个" Actions"字段， 携带进行同步的操作指示。 该" Actions"字段内的 "Action-type"字段值为 0100 (针对上述案例）； "Action-specific"字段携带的是 与同步操作相关的参数信息； "information"字段携带的是同步的数据库标识， 如数据库的统一资源标识 （ Uniform Resource Identifier , 简称 "URI" )； "information- length"字段携带的是" information"字段的长度， 如数据库 URI的 长度。
其中， "Action-specific"字段进一步包括如下字段： "Direction"字段， "Behavior" 字段， "ID- Valid"字段， "Log- Valid"字段， "Content-type"字段， 如 图 6所示。 下面分别对各字段进行介绍。
"Direction"字段用于指示同步方向， 长度为 2*BIT, 具体说明如下： <Direction>：： =<No-way>/ <from- server>/ <from-client>/ <two-way> ； '方向 信息'
<No-way>::='00' ；，无方向'
<from-server>::='01 ' ；，从服务器， 单向'
<from-client>::=' 10' ；，从客户端， 单向'
<two-way>::=' ll ' ；'双向'
"Behavior "字段用于指示同步行为，比如是清除还是保存服务器端 /客户端 的数据， 长度为 1 *BIT, 其具体说明如下：
<Behavior>: :=<Preserve>/<Refresh> ；'同步行为 '
<Preserve>::='0' ； '保存' <Refresh>：: = ' 1 ' ；'刷新' 通过该 "Behavior"字段和 "Direction"字段的结合使用， 可以确定同步类型。 例如， <Direction> = 01 , <Behavior> = 1 , 表明是由服务器单方发起的数据同 步会话， 则同步后， 刷新客户端的数据。
"ID- Valid"字段用于指示服务器端数据条目的标识信息 ( ID )是否有效， 长度为 1 *BIT。 其具体说明如下：
<ID-Valid>: :=<valid>/<invalid> ;'ID有效性 '
<valid>::=' l ' ;'ID有效'
<invalid>::='0' ;'ID无效' 需要说明的是， DS服务器端需要维护双方标识信息的映射表。
如果由于数据库损坏等， 导致标识信息无效，将影响双方的同步机制的选 择。 比如， 如果服务器的标识信息无效， 在客户端发起会话后， 服务器会要求 客户端先发送指紋， 然后服务器根据指紋确定哪些数据服务器端已经存在，哪 些数据还不存在， 再指示客户端发送需要发送的数据。
"Log- Valid"字段用于指示服务器端的修改日志是否有效， 长度为 1 *BIT。 其具体说明如下：
<log-valid>：： =<valid>/<invalid> ；，日志有效性 '
<valid>::=T ；，日志有效'
<invalid>::='0' ； '日志无效' 日志是用于记录 DS服务器端数据库、 数据条目的改变情况的， 如果曰志 无效， DS服务器将无法告知 DS客户端， 自身的哪些数据条目被改变了。 这 将影响双方的同步机制的选择。
"Content-type"字段用于指示数据库中的数据类型， 比如是 vcard类型还是 email类型， 长度为 23*BIT。
还有一种实施方式是， "Behavior"字段和 "Direction"字段可以设计在
<Action-type>字段中。
<action-type>::=<data-sync><direction><behaviour>
； 'Action Type Information^ *ΒΙΤ' <data-sync>： := "0" ； 'Data Sync,l *ΒΙΤ' <data-sync>字段如果为 0, 表示操作类型为数据同步， 否则， 操作类型为 其他。
"Behavior"字段和 "Direction"字段与前面介绍的一样。
接着， 在步骤 520中， DS服务器将生成的 Notification消息， 下发给 DS 客户端。具体地说，该 DS服务器可以通过 OTAPUSH或会话发起协议（ Session Initation Protocol , 简称" SIP" ) PUSH的方式或短消息的方式， 将生成的如图 6 所示的 Notification消息， 下发给 DS客户端。
接着， 在步骤 530中， DS客户端解析收到的 Notification消息， 选择同步 机制。 具体地说， DS客户端通过对收到的 Notification消息进行解析， 得到该 消息中的" Action"字段携带的用于同步的操作指示， 并根据该操作指示选择合 适的同步机制。
其中，对同步机制的选择包括以下之一或其任意组合：对同步方向的选择、 对同步数据的选择， 对同步行为的选择。
其中， 同步数据的选择包括： 是否发送全部数据项、 是否只发送修改的数 据项。
同步行为的选择包括：是否发送数据指紋信息、是否需要对方比较数据项、 是否需要对方用接收的数据项覆盖自身存储的数据项。
下面通过几个举例， 对 DS客户端根据" Action"字段中携带的操作指示， 选择合适的同步机制进行简单说明。
比如说， 如果 DS服务器的 ID映射表无效， 因此即使 DS客户端发送数据项 的标识， DS服务器也无法识别， 所以， DS客户端应该选择发送数据指紋信息、 或选择发送全部数据。 或者， 如果 DS服务器改变的数据项较多， 则 DS客户端 应选择双向同步或 DS服务器单向同步， 同时应发送数据指紋信息， 以避免双 方的数据项修改冲突。 当然， 还有其它许多情况， 在此不再——列举。
接着，在步骤 540中， DS客户端使用选择的同步机制向 DS服务器发起同步 会话。
不难发现， 由于在本实施方式中， 在 Notification消息中携带了用于进行 同步的操作指示，因此可使得 DS客户端能够根据此信息选择相应的同步机制， 从而减少了同步机制选择的会话交互， 提高了会话效率。 本发明的第二实施方式涉及一种 Notification消息处理方法， 本实施方式 与第一实施方式大致相同， 其区别在于， 在第一实施方式中， 该 Notification 消息仅指示了 DS客户端进行同步操作， 而在本实施方式中， 该 Notification 消息不仅指示了 DS客户端进行同步操作，还指示该 DS客户端进行其它操作。
比如说， DS服务器在生成的 Notification消息中， 不仅携带用于指示 DS 客户端进行同步操作的" Action"字段， 还携带用于指示 DS客户端进行会话信 息显示操作的 "Action"字段， 如图 7所示。 "Actionl"字段携带进行同步操作的 操作指示， 与第一实施方式中的 "Actionl'，字段完全相同， 在此不再赘述。 下面 对" Action2"字段进行具体说明。
"Action2"字段内的" Action-type"字段的值（如 0010 ), 表示本 "Action"字 段携带的是显示会话信息的操作指示； "information"字段携带的是会话信息的 内容， "information-length"字段携带的是会话信息的内容长度。
DS 客户端从 Notification 消息中解析出该" Action2，，字段后， 可以将 "information"字段中的会话信息， 以可显示文本的方式显示给用户， 比如： "您 有新的 Email, 请查收。 "并且， 发起一个同步会话， 将服务器上的新邮件同步 到本 DS客户端。由于 DS客户端执行会话信息显示操作时，并不需要" Action2" 字段内的" Action-specific"字段的信息， 因此该 DS 客户端可以忽略对该 "Action-specific"字段的解析。
当然， DS客户端从 Notification消息中解析出 "Actionl'，字段后， 同样需要 根据该 "Actionl'，字段携带的同步操作的操作指示发起会话同步，该过程已在第 一实施方式中进行了说明， 在此不再赘述。
另外，在该 Notification消息中也可以携带用于指示 DS客户端发起空会话 操作的 "Action"字段， DS 客户端解析出该" Action"字段后， 通过该 "Action"字 段中的 "Action-type"字段值， 可以获知 DS服务器期望本 DS客户端发起一个 空会话。 假定" Action-type"字段的值为 0011时， 表示本 "Action"字段携带的发 起空会话的操作指示， 则该" Action"字段如图 8所示。
基于 DS客户端发起的空会话， DS服务器可以与 DS客户端进行数据同步 或设备能力协商。 比如说， 在空会话建立后， 如果 DS服务器需要 DS客户端 的设备信息， 可以通过发一个 Get命令获取： <Get>
<CmdID>K/CmdID>
<Item>
<Target>
<LocURI>./DevInfo</LocURI>
</Target>
</Item>
</Get>
由于 DS 客户端执行发起空会话的操作时， 并不需要" Action2"字段内的 "Action-specific"字段的信息， 因此该 DS客户端可以忽略对该" Action-specific" 字段的解析。
不难发现， 实际上是通过 Notification消息中的各" Action"字段实现对 DS 客户端的操作指示，而各" Action"字段之间是完全独立的，因此，在 Notification 消息中可以只携带一个" Action"字段， 也可以携带多个" Action"字段， 携带的 "Action"字段可以是对同步操作的操作指示， 或是对发起空会话的操作指示， 或是对显示会话信息的操作指示，甚至可以是上报认证信息或设备信息的操作 指示。 通过" Action"字段携带上报认证信息或设备信息的操作指示， 将在下面 的第三实施方式中进行说明。
本发明的第三实施方式涉及一种 Notification消息处理方法， 在本实施方 式中， 在 Notification 消息的消息体内携带指示 DS 客户端上报认证信息的 "Action"字段， 和指示 DS客户端上报设备信息的" Action"字段。 DS客户端根 据这两个" Action"字段， 上报认证信息和设备信息， 具体流程如图 9所示。
在步骤 910中， DS服务器生成触发建立会话连接的 Notification消息， 该 消息中携带上报认证信息和设备信息的操作指示。
在" Action"字段中携带上报认证信息的操作指示的方式如图 10 所示， 该
"Actions"字段内的" Action-type"字段的值（如 0000 ),表示本 "Action"字段携带 的是上报认证信息的操作指示； "information"字段携带的是要求客户端上报的 认证信息所属的认证机制，如是" auth-basic"认证机制，或是" auth-MD5"认证 机制， 或是" SHA-256"认证机制， 或是" SHA-1 "认证机制， 或是非特定机制的 认证机制； "information-length"字段携带的是" information"字段中认证机制的长 度。 对" information-length"字段和 "information"字段的说明如下：
< information-length >： := 8*BIT ； '认证机制的长度'
< information >：: =<auth-basic>/<auth-MD5>/<SHA-256>/<SHA-l>/<not specified ；'认证机制，
<auth-basic > ；'基本认证机制'
< auth-MD5> ;'MD5认证机制 '
< SHA-256> ；' SHA-256认证机制 '
< SHA-1> ；' SHA-1认证机制 ' <not specified ；'非特定认证机制 ' 需要说明的是， 当 < information >·· :=<not specified^† , 说明 DS服务器对 认证机制不做特殊的规定， DS客户端可以根据 DS标准中参数配置管理对象 上的认证类型 "AAuthPref值指定的认证方式或上次成功的会话所使用的认证 方式进行认证。
在" Action"字段中携带上报设备信息的操作指示的方式如图 11 所示， 该 "Actions"字段内的" Action-type"字段的值（如 0001 ),表示本 "Action"字段携带 的是上报设备信息的操作指示； "Action-specific"字段携带的是设备信息的上报 方式， 如是上报完整的设备信息， 或是上报更新的设备信息， 或是上报空的设 备信息， 或是上报设备信息数据库标识； "information"字段携带的是设备信息 在 DS 客户端中存储的位置信息； "information-length"字段携带的是 "information"字段中位置信息的 长度。 对 "Action-specific"字段、 "information-length"字段和 "information"字段的说明 口下：
< Action-specific > ::=<completed>/<updated>/<null>/URI ； '设备信息 上报方式'
< completed > ::= '00' ；'完整的设备信息'
<updated > ::=，01， ；'更新的设备信息'
<null>::=' 10' ；'设备信息为空'
<URI>::=' 11 ' ；'设备信息数据库标识'
< information-length >：： ； '设备信息位置链接字段长度' < information >::= < information-length >*CHAR ；'设备信息的位置链 接，
当< Action-Specific >::=<111 1>时， 指示的是要求 DS客户端上才艮存储该 DS客户端设备信息的 URI链接， 然后 DS服务器根据这个地址去访问获取该 DS客户端的设备信息， 这样可以节省空口资源。
< information >字段指示了设备信息在 DS客户端上存储的位置。 比如说， DS服务器要求 DS客户端上报全部的设备信息， 则< Action-Specific >字段为 < completed >, < information >字段为 ./.../devinf。 DS服务器要求 DS客户端上报 更新的设备信息，则< Action-Specific >字段为 < updated >, < information >字段 为. /.../devinf/datastore/CTCAP, 即表示 CTCAP元素下的更新信息。 对于部分 设备信 息 的 指 定 ， 可 以 使用 层 次化 的 URI 来表示 ， 比 如 ./.../devinf/datastore/SyncCap,即表示 DS客户端需要上报 SyncCa 元素下的 设备信息。 当 DS客户端上有多个同名元素时， 可以在 URI中携带匹配条件来 表示。
比如： DS客户端上有多个 DataStore元素， 且 DataStore下有多个 CTCap 元素：
<DataStore>
<DisplayName> addressbook </DisplayName>
<SourceRef ... </SourceRef
<CTCap>
<CTType> syncml:filtertype-cgi </CTType>
</CTCap>
<CTCap>
<CTType> text/x-vcard </CTType>
</CTCap>
</DataStore> <DataStore>
<DisplayName> Email </DisplayName>
</DataStore>
则 DS 服务器希望 DS 客户端上报 <DisplayName>为"addressbook"的
DataStore的信息， 可以使用下面的 URI来指定：
./DevInf/DataStore [DisplayName="addressbook"]。
进一步， 如果 DS 服务器希望 DS 客户端上报 <DisplayName> 为 "addressbook"的 DataStore中 <。1。& >为 "text/x-vcard"的信息，可以使用下面 的 URI来指定：
./DevInf/DataStore[DisplayName="addressbook"]/CTCap[CTType="text/x-vc ard。
如果用于比较的不是元素， 而是属性， 则使用 Element 的方式， 比 ^口： ./DevInf/DataStore[@DisplayName="addressbook"]。
在步骤 920 中， 该 DS 服务器将生成的包含这两个 "Action"字段的
Notification消息， 下发给 DS客户端。 具体地说， 该 DS服务器可以通过 OTA PUSH (或 SIP PUSH ) 的方式或短消息的方式， 将生成的包含两个" Action" 字段的 Notification消息， 下发给 DS客户端， 请求会话连接。
接着， 在步骤 930中， DS客户端解析收到的 Notification消息， 生成符合 要求的发起会话连接的消息， 该发起会话连接的消息即为 Package # 1消息。
具体地说， DS客户端解析携带在 Notification消息中的" Action"字段， 根 据在两个" Action"字段分别携带的上报认证信息的操作指示， 和上报设备信息 的操作指示， 决定在随后的 Package # 1消息中如何上报认证信息和设备信息。
接着， 在步骤 940中， DS客户端将生成的 Package # 1消息发送给 DS服 务器。 步骤 950和步骤 960分别与步骤 130和步骤 140相同， 在此不再赘述。
由于在本实施方式中， DS客户端能够通过 Notification消息了解到 DS服 务器要求的上报认证信息和设备信息的具体方式，如上报的认证信息所属的机 制、 以及上报设备信息时所使用的方式等。 因此可避免由于认证信息和设备信 息的上报方式不符合 DS服务器的要求， 而造成的 DS客户端与 DS服务器的 多次交互， 从而节省了网络资源。 当然， 在实际应用中， 也可以在 Notification 消息中只携带上报认证信息或上报设备信息的操作指示。
本发明的第四实施方式涉及一种 Notification消息处理方法， 本实施方式 在第三实施方式的基础上， 进一步增加了当 DS服务器对认证机制不做特殊的 规定， 即< information >::=<not specified>时， DS客户端的具体操作。
具体流程如图 12所示，步骤 1210至步骤 1250分别与步骤 910至步骤 950 相同， 在此不再赘述。 由于本实施方式中， DS服务器对认证机制不做特殊的 规定， 因此， DS 客户端会在本地查找参数配置管理对象上是否有认证类型 "AAuthPref节点， 如果有该节点并且该节点有值， 则根据该值指示的认证方 式上报认证信息； 如果没有该节点， 或者有该节点但该节点无值， 则按默认的 认证方式进行安全认证。 比如说， 默认的认证方式是在 Package # 1 消息中上 报认证机制为 "auth-basic"的认证信息， 那么， DS客户端将在生成的 Package # 1消息中携带认证机制为 "auth-basic"的认证信息。 在本实施方式中， 以默认 的认证方式认证成功， 也就是说， DS服务器向 DS客户端发送的 Package # 2 消息中， 携带表示认证成功状态码。
接着， 在步骤 1260中， 当 DS客户端根据收到的 Package # 2消息， 获知 认证成功后，记录该默认的认证方式。以便在之后的认证中，使用该认证方式， 从而提高了认证成功的概率。 具体地说， 可以有两种记录方式：
( 1 )将默认的认证方式记录在用于指定认证方式的认证类型 "AAuthPref ' 节点中。针对上述案例， 即是将上报认证机制为" auth-basic"的认证信息的认证 方式作为 "AAuthPref节点的值， 记录在该" AAuthPref'节点中。
( 2 )将默认的认证方式记录在参数配置管理对象中扩展的与认证相关的 节点中。 针对上述案例， 在参数配置管理对象中扩展一个与认证相关的节点， 将上报认证机制为 "auth-basic"的认证信息的认证方式， 记录在该扩展的节点 中。
接着， 进入步骤 1270 , 步骤 1270与步骤 960相同， 在此不再赘述。
另外， 当 DS客户端接收到 DS服务器的 Notification消息时， DS客户端 可以向 DS服务器回复确认信息， 表明成功接收到通知消息， 再执行所指示的 操作。 或是， 在某些特殊情况下， DS客户端可能不执行 DS服务器所指示的 操作， 而只是返回一个确认消息。 比如说， DS 客户端对 DS 服务器下发的 Notification消息中的" Digest"认证失败； 或者是 DS客户端忙， 不适合执行 DS 服务器的指示操作； 或者是用户拒绝， 不想执行 DS服务器的指示操作等等。 在这些情况下， DS客户端可以对 Notification消息进行回复， 回复接收状态信 息。
在回复消息中， DS客户端可以携带新的认证信息 <NextNonce^^ DS服务 器， 作为 DS服务器下次下发 Notification消息时使用， DS客户端也可以携带 状态码信息给 DS服务器， 用于指示状态信息， 比如认证失败、 客户端忙、 用 户拒绝等， 如表 1所示。
Figure imgf000017_0001
表 1
比如说， DS客户端可以在包 1消息中对 Notification消息进行回复， 消息 实例为：
<SyncML>
<SyncHdr>
</SyncHdr>
<SyncBody>
<Status>
<CmdID>K/CmdID> <CmdRef 0</CmdRef
<MsgRef 0</MsgRef ； 指明是对 Notification消息的回复 <Chal> ； 新的认证信息
<Meta>
<Type xmlns= ' syncml： metinf ' >syncml： auth-md5</Type>
<Format xmlns= ' syncml： metinf >b64</Format>
<NextNonce
xmlns= ' syncml： metinf >ZG9iZWhhdmU Cg==</NextNonce>
</Meta>
</Chal>
<Data> 506 </Data> ； 表明用户拒绝会话
</Status>
</SyncBody>
</SyncML>
DS服务器可以不对此消息再次进行回复。
值得一提的是， 在上述各实施方式中， DS客户端即为终端设备， 如果该 DS 客户端不具备接收 Notification 消息的功能， 则该 DS 客户端需要通过 Notification客户端接收 Notification消息。 Notification客户端要依赖于业务实 现， 比如说， 如果在业务实现上， 是通过 OTA PUSH方式发送 Notification消 息的， 则该 Notification客户端将是 OTA PUSH客户端； 如果是釆用短消息发 送， 则该 Notification客户端将是短消息客户端。 类似地， 如果 DS服务器不具 备发送 Notification消息的功能， 则该 DS服务器需要通过 Notification服务器 发送 Notification消息。
需要说明的是， 在上述各实施方式中， "num-actions"字段的值表示 DS服 务器要求 DS客户端执行的操作个数， 比如说， 如果" num-actions"字段的值为 1 , 则表示要求 DS客户端执行 1个操作， 该操作的类型以及具体的操作指示 通过 1个" Action"字段携带， 如果" num-actions"字段的值为 2 , 则表示要求 DS 客户端执行 2个操作， 这两个操作的类型以及具体的操作指示分别通过 2个 "Action"字段携带。 但在实际应用中， 还可以通过将 "num-actions"字段的值设 置为 0, 来指示 DS客户端执行发起空会话的操作， 此时， 在 Notification消息 中可以不携带 "Action"字段。 另外， 由于对于某些操作而言， 如会话信息显示 操作， "Action"字段中的" Action-specific"字段并没有实质的意义， 因此在实际 应用中可以省略掉该字段。也就是说，如果" Action" 字段中的某些字段并没有 被用到， 则这些字段可以被省略掉。
本发明的第五实施方式涉及一种 Notification消息处理***，如图 13所示， 包含 DS客户端 131和 DS服务器 132。
在 DS服务器 132中包括： 生成模块 21 , 用于生成触发建立会话连接的 Notification消息，该消息中携带用于指示 DS客户端执行至少一个操作的指示 信息； 发送模块 22, 用于将该生成模块生成的 Notification消息， 发送给 DS 客户端。
在 DS客户端 131中包括： 接收模块 11 , 用于接收来自 DS服务器的触发 建立会话连接的 Notification消息； 解析模块 12,用于解析接收模块 11收到的 Notification消息； 处理模块 13 , 用于根据解析模块 12从 Notification消息中 解析出的指示信息， 执行相应的操作。 其中， 指示客户端执行的操作为以下之 一或其任意组合： 同步操作、 认证信息上报操作、 设备信息上报操作、 会话信 息显示操作、 或空会话发起操作。
DS服务器通过 Notification消息携带各操作的操作指示的方式，如图 4所 示， 在此不再赘述。 各" Action"字段如何携带相应操作的操作指示， 也已在上 述各实施方式中作了详细说明， 在此不再赘述。
综上所述， 在本发明的实施方式中， 由于 DS客户端能够通过 Notification 消息了解到 DS服务器期望本 DS客户端执行的操作、 以及具体执行的方式， 因此可避免由于执行操作的方式不符合服务器要求，而造成的客户端与服务器 的多次交互， 从而节省了网络资源， 提高了会话效率。
比如说， 在 Notification消息中携带了用于进行同步的操作指示， 可使得 DS客户端能够根据此信息选择相应的同步机制， 从而减少了同步机制选择的 会话交互， 提高了会话效率。
如果在 Notification 消息中携带了上报认证信息和 /或设备信息的操作指 示，可使得 DS客户端能够通过 Notification消息了解到 DS服务器要求的上报 认证信息和 /或设备信息的具体方式， 如上报的认证信息所属的机制、 以及上 报设备信息时所使用的方式等。因此可避免由于认证信息和设备信息的上报方 式不符合 DS服务器的要求， 而造成的 DS客户端与 DS服务器的多次交互， 从而节省了网络资源。
而且， 由于本发明实施方式中的 Notification 消息结构与现有技术中的 Notification消息结构 （如图 3所示）十分类似， "num-actions"字段相当于图 3 中的" num-syncs"字段， "Action"字段相当于图 3中的" sync"字段， 同样保留了 "future-use"字段和 "vendor-specific"字段。因此不需对现有技术中的 Notification 消息结构作较大改动， 即可使得本发明的实施方式能够与现有技术较好地兼 容。
虽然通过参照本发明的某些优选实施方式，已经对本发明进行了图示和描 述，但本领域的普通技术人员应该明白， 可以在形式上和细节上对其作各种改 变， 而不偏离本发明的精神和范围。

Claims

权 利 要 求
1. 一种通知消息处理方法， 其特征在于， 包括：
接收来自数据同步 DS服务器的触发建立会话连接的通知消息， 该通知消 息中携带用于指示 DS客户端执行至少一个操作的指示信息；
根据所述通知消息中携带的指示信息， 执行对应的操作。
2. 根据权利要求 1所述通知消息处理方法， 其特征在于， 所述指示客户 端执行的操作是以下至少一种：
同步操作、 认证信息上报操作、 设备信息上报操作、 会话信息显示操作、 空会话发起操作。
3. 根据权利要求 1所述的通知消息处理方法， 其特征在于， 所述通知消 息的消息体中包括：
操作个数字段， 用于携带指示所述客户端执行的操作个数；
操作字段， 用于携带相应操作的操作指示。
4. 根据权利要求 3所述的通知消息处理方法， 其特征在于， 所述操作字 段中包括：
操作类型字段， 用于携带操作所属的操作类型；
操作相关信息字段， 用于携带与操作相关的参数信息；
信息字段， 用于携带执行操作时所需的信息；
信息长度字段， 用于携带所述信息字段的长度。
5. 根据权利要求 4所述的通知消息处理方法， 其特征在于，
所述操作类型字段中携带的操作类型， 为同步操作的类型；
所述信息字段携带的执行操作时所需的信息， 为同步的数据库标识； 所述操作相关信息字段携带的与操作相关的参数信息，为与同步操作相关 的参数信息；
所述执行所述指示信息指示的操作包括：
根据所述与同步操作相关的参数信息选择同步机制；
使用所选择的同步机制向所述 DS服务器发起同步会话。
6. 根据权利要求 5所述的通知消息处理方法， 其特征在于， 所述的参数 信息包括以下至少一种信息： 用于指示同步方向的信息、用于指示同步行为的信息、用于指示服务器端 数据条目的标识信息是否有效的信息、用于指示服务器端的修改日志是否有效 的信息、 用于指示数据库中的数据类型的信息。
7. 根据权利要求 5所述的通知消息处理方法， 其特征在于， 所述根据与 同步操作相关的参数信息选择同步机制包括：根据与同步操作相关的参数信息 选择同步方向、 选择发送同步数据、 选择同步行为中的至少一种；
所述选择同步方向包括， 选择同步方向为从服务器单向、 从客户端单向、 双向或无方向；
所述选择发送同步数据包括，选择发送全部数据项或选择只发送修改的数 据项；
所述选择同步行为包括， 选择是否发送数据指紋信息、选择是否需要对方 比较数据项， 或选择是否需要对方用接收的数据项刷新自身存储的数据项。
8. 根据权利要求 4所述的通知消息处理方法， 其特征在于，
所述操作类型字段中携带的操作类型， 为认证信息上报操作的类型； 所述信息字段携带的执行操作时所需的信息，包括要求所述客户端上报的 认证信息所属的认证机制。
9. 根据权利要求 4所述的通知消息处理方法， 其特征在于，
所述操作类型字段中携带的操作类型， 为设备信息上报操作的类型； 所述信息字段携带的执行操作时所需的信息，包括所述设备信息在所述客 户端中存储的位置信息；
所述操作相关信息字段携带的与操作相关的参数信息，包括所述设备信息 的上报方式。
10. 根据权利要求 9所述的通知消息处理方法， 其特征在于， 所述信息字 段携带的执行操作时所需的信息还包括： 条件匹配信息， 用于指示所述客户端 上报符合条件的部分设备信息。
11. 根据权利要求 4所述的通知消息处理方法， 其特征在于，
所述操作类型字段中携带的操作类型， 为会话信息显示操作的类型； 所述信息字段携带的执行操作时所需的信息， 为所述会话信息的内容。
12. 根据权利要求 4所述的通知消息处理方法， 其特征在于， 所述操作类型字段中携带的操作类型， 为空会话发起操作的类型。
13. 根据权利要求 1 所述的通知消息处理方法， 其特征在于， 所述指示 DS客户端执行的操作为空会话发起操作；
所述通知消息的消息体中携带操作个数字段，并且该操作个数字段的值为 "0"。
14. 根据权利要求 1所述的通知消息处理方法， 其特征在于， 在所述执行 对应的操作之前， 还包括：
根据当前状态， 判断是否需要根据所述通知消息中携带的指示信息，执行 对应的操作， 如果需要， 则执行对应的操作； 如果不需要， 则向所述 DS服务 器回复确认消息， 表示拒绝执行所述对应的操作。
15. 根据权利要求 14所述的通知消息处理方法， 其特征在于， 所述确认 消息携带以下拒绝执行的原因之一： 客户端忙、 认证失败、 用户拒绝。
16. 根据权利要求 1所述的通知消息处理方法， 其特征在于， 在所述接收 通知消息之后， 所述执行对应的操作之前， 还包括：
向所述 DS服务器回复确认消息， 表示成功接收到所述通知消息。
17. 根据权利要求 14或 16所述的通知消息处理方法， 其特征在于， 所述 方法还包括：
在所述确认消息中上报新的认证信息。
18. 一种 DS客户端， 其特征在于， 包括：
接收模块， 用于接收来自 DS服务器的触发建立会话连接的通知消息， 该 通知消息中携带用于指示 DS客户端执行至少一个操作的指示信息；
解析模块， 用于解析所述接收模块收到的所述通知消息， 得到指示消息； 处理模块， 用于根据所述解析模块从所述通知消息中解析出的指示信息， 执行对应的操作。
19. 根据权利要求 18所述的 DS客户端， 其特征在于， 所述指示客户端 执行的操作是以下至少一种：
同步操作、 认证信息上报操作、 设备信息上报操作、 会话信息显示操作、 空会话发起操作。
20. 一种 DS服务器， 其特征在于， 包括： 生成模块， 用于生成触发建立会话连接的通知消息， 该通知消息中携带用 于指示 DS客户端执行至少一个操作的指示信息；
发送模块， 用于将所述生成模块生成的通知消息， 发送给 DS客户端。
21. 根据权利要求 20所述的 DS服务器， 其特征在于， 所述指示客户端 执行的操作是以下至少一种：
同步操作、 认证信息上报操作、 设备信息上报操作、 会话信息显示操作、 空会话发起操作。
PCT/CN2007/071271 2007-05-30 2007-12-19 Procédé et dispositif pour traiter un message de notification WO2008144992A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2009535552A JP4943512B2 (ja) 2007-05-30 2007-12-19 通知メッセージ処理方法および装置
EP07846097A EP2079207A4 (en) 2007-05-30 2007-12-19 METHOD AND DEVICE FOR PROCESSING NOTIFICATION MESSAGES
US12/420,343 US20100011070A1 (en) 2007-05-30 2009-04-08 Method and device for notification message processing

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN200710108398.0 2007-05-30
CN200710108398.0 2007-05-30
CN2007101375550A CN101316221B (zh) 2007-05-30 2007-08-07 通知消息处理方法及设备
CN200710137555.0 2007-08-07

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/420,343 Continuation US20100011070A1 (en) 2007-05-30 2009-04-08 Method and device for notification message processing

Publications (1)

Publication Number Publication Date
WO2008144992A1 true WO2008144992A1 (fr) 2008-12-04

Family

ID=40074558

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2007/071271 WO2008144992A1 (fr) 2007-05-30 2007-12-19 Procédé et dispositif pour traiter un message de notification

Country Status (5)

Country Link
US (1) US20100011070A1 (zh)
EP (1) EP2079207A4 (zh)
JP (1) JP4943512B2 (zh)
CN (1) CN101316221B (zh)
WO (1) WO2008144992A1 (zh)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9451093B2 (en) * 2006-11-15 2016-09-20 France Telecom Telecommunication method and system offering a plurality of mutually consistent means for access to a message base
JP2009015572A (ja) * 2007-07-04 2009-01-22 Nec Corp セキュリティシステム、端末、情報配信方法およびプログラム
CN103200553B (zh) * 2012-01-04 2018-05-08 中兴通讯股份有限公司 响应触发信息的方法、***和mtc用户设备
US9800532B2 (en) * 2012-06-04 2017-10-24 International Business Machines Corporation Intelligent presentation of multiple proximate audible alerts
CN102890631B (zh) * 2012-09-13 2016-12-07 新浪网技术(中国)有限公司 基于持久化消息队列传输消息的方法及消息传输装置
US10103781B2 (en) * 2015-02-20 2018-10-16 Visa International Service Association Contactless data exchange between mobile devices and readers involving value information not necessary to perform a transaction
CN105208177B (zh) * 2015-09-14 2019-02-12 小米科技有限责任公司 通讯录更新方法及装置
CN105389123A (zh) * 2015-10-16 2016-03-09 浪潮(北京)电子信息产业有限公司 一种基于双控制器的存储管理方法及***
CN109495532A (zh) * 2017-09-13 2019-03-19 北京京东尚科信息技术有限公司 客户端更新方法和装置
CN116319985A (zh) 2018-12-13 2023-06-23 Oppo广东移动通信有限公司 代理订阅方法、装置、计算机设备和存储介质
US11055314B1 (en) 2018-12-31 2021-07-06 Facebook, Inc. Techniques for a database-driven messaging user interface
US10979500B1 (en) * 2018-12-31 2021-04-13 Facebook, Inc. Techniques for directive-based messaging synchronization
US10855761B1 (en) 2018-12-31 2020-12-01 Facebook, Inc. Techniques for in-place directive execution
US11025576B1 (en) 2018-12-31 2021-06-01 Facebook, Inc. Techniques for backend-specific cursor tracking
CN112187854B (zh) * 2020-08-18 2023-10-20 华控清交信息科技(北京)有限公司 一种任务处理方法、装置和用于任务处理的装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6584491B1 (en) * 1999-06-25 2003-06-24 Cisco Technology, Inc. Arrangement for monitoring a progress of a message flowing through a distributed multiprocess system
CN1528070A (zh) * 2000-10-10 2004-09-08 ض� 在一个由链接到远程客户端的中央服务器构成的网络中管理远程客户端的方法和***
WO2006067261A1 (en) * 2004-12-20 2006-06-29 Nokia Corporation Establishing a push session in a communication system
CN1805450A (zh) * 2005-01-10 2006-07-19 华为技术有限公司 在域名***dns机制中实现服务器与客户端数据同步的方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6289382B1 (en) * 1999-08-31 2001-09-11 Andersen Consulting, Llp System, method and article of manufacture for a globally addressable interface in a communication services patterns environment
JP4588271B2 (ja) * 2001-09-18 2010-11-24 富士通株式会社 データ同期システム、データ同期方法、データセンタ及びクライアント端末
US7155521B2 (en) * 2001-10-09 2006-12-26 Nokia Corporation Starting a session in a synchronization system
US20070027971A1 (en) * 2005-07-26 2007-02-01 Sunil Marolia Device management network with notifications comprising multiple choice prompts
CN100531212C (zh) * 2006-01-21 2009-08-19 华为技术有限公司 一种协商设备信息的***、方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6584491B1 (en) * 1999-06-25 2003-06-24 Cisco Technology, Inc. Arrangement for monitoring a progress of a message flowing through a distributed multiprocess system
CN1528070A (zh) * 2000-10-10 2004-09-08 ض� 在一个由链接到远程客户端的中央服务器构成的网络中管理远程客户端的方法和***
WO2006067261A1 (en) * 2004-12-20 2006-06-29 Nokia Corporation Establishing a push session in a communication system
CN1805450A (zh) * 2005-01-10 2006-07-19 华为技术有限公司 在域名***dns机制中实现服务器与客户端数据同步的方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"SynchML Data Sync Protocol Candidate Version 1.2", OPEN MOBILE ALLIANCE, 1 June 2004 (2004-06-01)
See also references of EP2079207A4

Also Published As

Publication number Publication date
EP2079207A4 (en) 2009-12-02
EP2079207A1 (en) 2009-07-15
JP2010509813A (ja) 2010-03-25
JP4943512B2 (ja) 2012-05-30
CN101316221B (zh) 2012-04-04
CN101316221A (zh) 2008-12-03
US20100011070A1 (en) 2010-01-14

Similar Documents

Publication Publication Date Title
WO2008144992A1 (fr) Procédé et dispositif pour traiter un message de notification
JP4465638B2 (ja) プロキシ・サーバ、通信システム、通信方法及びプログラム
US8612527B2 (en) Automatic notification system and process
US8051186B2 (en) Method for device capability negotiation, method, system and device for synchronization
KR101011216B1 (ko) 데이터 동기
KR100690764B1 (ko) 아이엠피에스 클라이언트의 상태정보 동기화 방법
US8671156B2 (en) Method and apparatus for providing communication history
US20100241764A1 (en) Method and apparatus for synchronizing data
EP1783954A1 (en) System and method for discovering network resources
WO2009074035A1 (fr) Système, appareil et procédé de transmission de fichiers
US20100287253A1 (en) Method, apparatus, and system for data synchronization
US20050246421A1 (en) System and method for discovering and publishing of presence information on a network
KR20070015838A (ko) 네트워크상의 존재 정보를 발견하고 공개하도록 지시되는사용자 인터페이스를 위한 시스템 및 방법
CN101355524A (zh) 一种消息处理方法、***、服务器和终端
WO2008040248A1 (fr) Procédé et système de transmission de courrier électronique et serveur de courrier électronique poussé
WO2011113372A1 (zh) 多群组操作同步的方法、***和群组服务器
WO2010133035A1 (zh) 点到多点推送消息处理方法、***及服务器
WO2010028571A1 (zh) 大数据对象的传输方法、传输***及发送设备和接收设备
JP2016517664A (ja) モバイルデバイスにマルチメディア情報を配信するためのシステム及び方法
US20220312156A1 (en) Method and apparatus for multicast service session operation and communications device
WO2009111965A1 (zh) 一种数据同步的方法、设备及***
WO2009103212A1 (zh) 一种数据同步的方法、***和装置
WO2008145047A1 (en) Method and device for initiating the session connection
CN110771117B (zh) 一种采用面向id的网络的会话层通信
WO2009115025A1 (zh) 一种xml文档操作方法及xdms

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07846097

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2007846097

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2009535552

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE