EP2079207A1 - Verfahren und vorrichtung zur verarbeitung von benachrichtigungsmeldungen - Google Patents

Verfahren und vorrichtung zur verarbeitung von benachrichtigungsmeldungen Download PDF

Info

Publication number
EP2079207A1
EP2079207A1 EP07846097A EP07846097A EP2079207A1 EP 2079207 A1 EP2079207 A1 EP 2079207A1 EP 07846097 A EP07846097 A EP 07846097A EP 07846097 A EP07846097 A EP 07846097A EP 2079207 A1 EP2079207 A1 EP 2079207A1
Authority
EP
European Patent Office
Prior art keywords
action
information
notification message
field
client
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
EP07846097A
Other languages
English (en)
French (fr)
Other versions
EP2079207A4 (de
Inventor
Qin Zhao
Kepeng Li
Xiaoqian Chai
Hui Zhao
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
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
Publication of EP2079207A1 publication Critical patent/EP2079207A1/de
Publication of EP2079207A4 publication Critical patent/EP2079207A4/de
Ceased legal-status Critical Current

Links

Images

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 invention relates generally to the field of communication, and more particularly, to a method and device for Notification message processing in the field of data synchronization technology.
  • Data Synchronization is very important in data transmission.
  • DS technology relates to data synchronization between mobile devices and network servers. Synchronized data include telephone directories, address books, schedules, short messages and mails, etc.
  • a notification mechanism is provided for the server to deliver Notification messages to terminal devices.
  • Terminal devices initiate session connections with servers according to information such as SessionID (Session Identifier) and ServerID (Server Identifier) in Notification messages.
  • Delivery of Notification messages may be performed by means of short messages, Over-the-Air Technology PUSH (OTA PUSH), etc.
  • OTA PUSH Over-the-Air Technology PUSH
  • FIG. 1 A flowchart for the current management of a session between a DS server and a DS client is shown in Fig. 1 .
  • the DS server delivers a Notification message to the DS client, to request a session connection.
  • the DS client initiates a session connection with the DS server, and sends authentication information and device information of the DS client to the DS server.
  • the authentication information and device information is included in a Package #1 message of the management session.
  • the DS server sends a Package #1 message to the DS client, and in the Package #1 message an initialization package for the session action is carried.
  • subsequent session actions are performed by means of Package #3-Package #4 messages, as illustrated in step 140.
  • Fig. 2 The format of the existing DS Notification message is illustrated in Fig. 2 .
  • the format of the notification-body of the DS Notification message is illustrated in Fig. 3 .
  • the field “num-syncs” indicates the number of synchronization actions.
  • the field “future-use” is reserved for future extension.
  • the fields “sync1" through “syncN” indicate a number of specific synchronization actions.
  • the field “sync-type” indicates the type of the synchronization.
  • the field “content-type” indicates the type of the content of the database to be synchronized.
  • the field “server-URI-length” indicates the length of the field “server-URI”.
  • the field “server-URI” is used to store the name of the server database to be synchronized. It is apparent from above that the DS Notification message indicates the type of synchronization, the database to be synchronized, etc.
  • the resource of the over-the-air interface is not used efficiently.
  • the Client and the Server have already been authenticated in the transport layer, and it is not necessary for the client to report authentication information again. If the client reports authentication information once again, the resource of the over-the-air interface is wasted. Or the Client and the Server have already been authenticated in the transport layer, but it is still required by the server that the client should report authentication information and authentication should be performed in the application layer, before the management/synchronization session may be setup. At this moment, if the client does not report authentication information, the server returns an error message of "without authentication information of the client", and it is necessary for the client to report the authentication information once again.
  • 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 types of synchronization such as slow-synchronization, fast-synchronization and refresh-synchronization are very old.
  • the two parties which request synchronization may selectively send data information and data fingerprint information by analyzing the data modification information and database information of the other party. For example, if the synchronization direction specified by the server is two-way, the client does not initiate a one-way synchronization. But in the case that the client cannot select an appropriate synchronization mechanism, session efficiency may be lowered.
  • the embodiments of the invention provide a method and apparatus for Notification message processing, with which, network resources can be saved and session efficiency can be increased.
  • An embodiment of the invention provides a method for Notification message processing.
  • the method includes: receiving, from a Data Synchronization (DS) server, a Notification message for trigging the establishment of a session connection, the Notification message carrying instruction information for instructing a DS client to perform at least one action; and performing by the DS client a corresponding action according to the instruction information carried in the Notification message.
  • DS Data Synchronization
  • An embodiment of the invention provides a Data Synchronization (DS) client.
  • the DS client includes: a receiving module, adapted to receive, from a Data Synchronization (DS) server, a Notification message for trigging the establishment of a session connection, the Notification message carrying instruction information for instructing the DS client to perform at least one action; an parsing module, adapted to analyze the Notification message received by the receiving module to obtain the instruction information; and a processing module, adapted to perform a corresponding action according to the instruction information analyzed by the parsing module from the Notification message.
  • DS Data Synchronization
  • the DS client includes: a receiving module, adapted to receive, from a Data Synchronization (DS) server, a Notification message for trigging the establishment of a session connection, the Notification message carrying instruction information for instructing the DS client to perform at least one action; an parsing module, adapted to analyze the Notification message received by the receiving module to obtain the instruction information; and a
  • An embodiment of the invention provides a Data Synchronization (DS) server.
  • the server includes: a generating module adapted to generate a Notification message for trigging the establishment of a session connection, the Notification message carrying instruction information for instructing a DS client to perform at least one action; and a sending module adapted to send the Notification message generated by the generating module to the DS client.
  • a generating module adapted to generate a Notification message for trigging the establishment of a session connection, the Notification message carrying instruction information for instructing a DS client to perform at least one action
  • a sending module adapted to send the Notification message generated by the generating module to the DS client.
  • the DS client receives, from a Data Synchronization (DS) server, a Notification message for trigging the establishment of a session connection.
  • the Notification message carries instruction information for instructing the DS client to perform at least one action.
  • the DS client performs a corresponding action according to the instruction information carried in the Notification message. Because the DS client can learn what action the DS server requires the DS client to perform, and the manner for performing the action, by the Notification message for trigging the establishment of a session connection, the plurality of interactions between the DS client and the DS server caused due to the action manner does not meet the requirement of the server can be prevented; thus network resources are saved, and the session efficiency is increased.
  • DS Data Synchronization
  • Fig. 1 is a flowchart illustrating the management of the session between a DS server and a DS client in the conventional art
  • Fig. 2 is a diagram illustrating the format of the DS Notification message in the conventional art
  • Fig. 3 is a diagram illustrating the format of the notification-body of the DS Notification message in the conventional art
  • Fig. 4 is a diagram illustrating the format of the Notification message in various embodiments of the present invention.
  • Fig. 5 is a flowchart illustrating the method for the processing of the Notification message in the first embodiment of the present invention
  • Fig. 6 is a diagram illustrating the format of the Notification message in the first embodiment of the present invention.
  • Fig. 7 is a diagram illustrating the format of the Notification message carrying two Action fields in the second embodiment of the present invention.
  • Fig. 8 is a diagram illustrating the Action field carrying an action instruction for empty session initiation in the second embodiment of the present invention.
  • Fig. 9 is a flowchart illustrating the method for the processing of the Notification message in the second embodiment of the present invention.
  • Fig. 10 is a diagram illustrating the Action field carrying an action instruction for reporting authentication information in the second embodiment of the present invention.
  • Fig. 11 is a diagram illustrating the Action field carrying an action instruction for reporting device information in the second embodiment of the present invention.
  • Fig. 12 is a flowchart illustrating the method for the processing of the Notification message in the third embodiment of the present invention.
  • Fig. 13 is a flowchart illustrating the method for the processing of the Notification message in the fifth embodiment of the present invention.
  • the message body of the Notification message includes: a field of number of actions (num-actions field) sized 4 bits, for carrying the number N of actions which the DS client is instructed to perform; a field of future-use reserved for extension; N fields of action (Action fields), each field of action is for carrying an instruction for a corresponding action; and a field of vendor-specific reserved for extension.
  • a field of number of actions sized 4 bits, for carrying the number N of actions which the DS client is instructed to perform
  • a field of future-use reserved for extension N fields of action (Action fields), each field of action is for carrying an instruction for a corresponding action
  • a field of vendor-specific reserved for extension a field of vendor-specific reserved for extension.
  • each action field carries action instructions for corresponding actions.
  • Each action field includes: a field of action type (Action-type field), a field of action specific information (Action-specific field), a field of information length (information-length field) and a field of information (information field).
  • Action-type field a field of action type
  • Action-specific field a field of action specific information
  • An information-length field a field of information length
  • information field a field of information
  • the action type may be synchronization, reporting authentication information, reporting device information, session information indication, or empty session initiation.
  • the value of the Action-type field in the Action field is 0000, it is indicated that an action instruction for reporting authentication information is carried in the Action field; when the value of the Action-type field in the Action field is 0001, it is indicated that an action instruction for reporting device information is carried in the Action field; when the value of the Action-type field in the Action field is 0010, it is indicated that an action instruction for session information indication is carried in the Action field; when the value of the Action-type field in the Action field is 0011, it is indicated that an action instruction for empty session initiation is carried in the Action field; when the value of the Action-type field in the Action field is 0100 it is indicated that an action instruction for performing synchronization is carried in the Action field.
  • the embodiment relates to a method for Notification message processing.
  • a description is presented taking the following case as an example: an Action field instructing the DS client to perform synchronization is carried in the message body of the Notification message, and the DS client initiates a synchronization session according to the Action field.
  • the flowchart is shown in Fig. 5 .
  • step 510 the DS server generates a Notification message, and the Notification message carries instruction information for instructing the DS client to perform a synchronization action.
  • the value of the num-actions field in the message body is 1, only an Actions field is included which carries an action instruction for synchronization.
  • the value of the Action-type field in the Actions field is 0100 (for the above mentioned case); carried in the Action-specific field is parameter information related to synchronization actions; carried in the information field is a synchronized database identifier, such as a Uniform Resource Identifier (URI) of the database; carried in the information-length field is 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: a Direction field, a Behavior field, an ID-Valid field, a Log-Valid field, a Content-type field, such as illustrated in Fig. 6 .
  • the fields are each described below.
  • the Direction field is used to indicate the direction of synchronization, the length of which is 2*BIT, which is described specifically below:
  • the Behavior field is used to indicate the synchronization behavior, such as refresh or preserve the data at the server/client side, the length of which is 1*BIT, which is described specifically below:
  • the ID-Valid field is used to indicate whether the identifier information (ID) of the data entry at the server side is valid, the length of which is 1*BIT, which is specifically described below:
  • the damage of database may cause the identifier information invalid, which imposes an influence upon the selection of the mechanism of the two parties. For example, if the identifier information of the server is invalid, after the initiation of session by the client, the server may request the client to send its fingerprint first, and the server determines which data already exist in the server side according to the fingerprint, and which data do not exist in the server side, after that, the server instructs the client to send the data which is needed to be sent.
  • the Log-Valid field is used to indicate whether the change log at the server side is valid, the length of which is 1*BIT, which is specifically described below:
  • the log is used to record the change of the database and the change of the data entries at the DS server side. If the log is invalid, the DS server is not able to tell the DS client which of its data entries have been changed. This imposes an influence upon the selection of the synchronization mechanism of the two parties.
  • the Content-type field is used to indicate the data type in the database, such as a type of vcard, or a type of email, the length of which is 23*BIT.
  • the Behavior field and the Direction field may be designed to be in the Action-type field.
  • the ⁇ data-sync> field is 0 means the type of action is data synchronization; otherwise, the type of action is another one.
  • the DS server delivers the generated Notification message to the DS client.
  • the DS server may deliver the generated Notification message as illustrated in Fig. 6 to the DS client, by the way of OTA PUSH or the Session Initiation Protocol (SIP) PUSH or short messages.
  • IP Session Initiation Protocol
  • the DS client analyzes the received Notification message, and selects a synchronization mechanism. Specifically, the DS client obtains the action instruction for synchronization carried in the Action field in the message, by analyzing the received Notification message, and selects an appropriate synchronization mechanism according to the action instruction.
  • the selection of synchronization mechanism includes one of the selection of synchronization direction, the selection of synchronization data, and the selection of synchronization behavior, or any combination of them.
  • the selection of synchronization data includes: whether to send all the data entries; whether only to send the modified data entries.
  • the selection of synchronization behavior includes: whether to send data fingerprint information, whether to require the other party to compare the data entries, whether to require the other party to overwrite its stored data entries using the received data entries.
  • the DS client should select to send data fingerprint information, or select to send all data. Or if the DS server modifies many data entries, the DS client should select two-way synchronization or DS server one-way synchronization, and data fingerprint information should be sent, in order to prevent conflict between the modifications of the data entries of the two parties. Practically, there are also many other cases which are not illustrated here one by one.
  • step 540 the DS client initiates a synchronization session with the DS server using the selected synchronization mechanism.
  • the Notification message carries an action instruction for performing synchronization. Therefore, the DS client is enabled to select corresponding synchronization mechanism according to this information, the number of session interactions for the selection of synchronization mechanism is decreased and the efficiency of session is increased.
  • the second embodiment of the invention provides a method for Notification message processing.
  • the second embodiment is approximately similar to the first embodiment. the difference between them is: in the first embodiment, the Notification message only indicates that the DS client should perform a synchronization, but in the second embodiment, the Notification message indicates not only that the DS client should perform a synchronization, but also that the DS client should perform other actions.
  • the DS server carries not only an Action field instructing the DS client to perform synchronization, but also an Action field instructing the DS client to perform an action of session information indication, as shown in Fig. 7 .
  • the Action1 field carries an action instruction for performing synchronization action, which is precisely the same as the Action1 field in the first embodiment, and is not described here.
  • the Action2 field will be described specifically below.
  • the value of the Action-type field in the Action2 field (such as 0010) indicates what the Action field carries is an action instruction for session information indication, what the information field carries is the content of the session information, and what the information-length field carries is the content length of the session information.
  • the session information in the information field may be displayed to the user in the format of displayable text, such as, "You have a new Email.”
  • a synchronization session is initiated, and the new email on the server is synchronized to the DS client. Because the information of the Action-specific field in the Action2 field is not needed when the action of session information indication is performed by the DS client, the DS client may ignore the analysis of the Action-specific field.
  • the Notification message may also carry an Action field instructing the DS client to initiate an empty session action.
  • the DS client After the DS client obtained the Action field by analysis, it may learn from the value of the Action-type field in the Action field that the DS server expects the DS client to initiate an empty session. If it is assumed that the value of the Action-type field is 0011, it is indicated that what the Action field carries is an action instruction for empty session initiation, the Action field is shown in Fig. 8 .
  • the DS server may negotiate with the DS client for data synchronization or device capability. For example, after the empty session is setup, if the DS server needs the device information of the DS client, the device information may be obtained by sending a Get command:
  • the DS client may ignore the analysis of the Action-specific field.
  • the Notification message may carry only one Action field, or a plurality of Action fields.
  • the Action field carried may be an action instruction for synchronization action, an action instruction for empty session initiation, or an action instruction for session information indication. Furthermore, it may be an action instruction for reporting authentication information or device information. Carrying an action instruction for reporting authentication information or device information in the Action field will be described in the description of the third embodiment below.
  • the third embodiment of the invention involves a method for Notification message processing.
  • the message body of the Notification message carries an Action field for instructing the DS client to report authentication information, and an Action filed for instructing the DS client to report device information.
  • the DS client reports authentication information and device information according to the two Action fields.
  • the specific flowchart is shown in Fig. 9 .
  • the DS server In step 910, the DS server generates a Notification message for trigging the establishment of a session connection.
  • the message carries action instructions for reporting authentication information and device information.
  • the way the Action field carries the action instruction for reporting authentication information is shown in Fig. 10 .
  • the value of the Action-type in the Actions field indicates what the present Action field carries is an action instruction for reporting authentication information; what the information field carries is the authentication mechanism which the authentication information (which the client is asked to report) belongs to, such as an auth-basic authentication mechanism, an auth-MD5 authentication mechanism, an SHA-256 authentication mechanism, an SHA-1 authentication mechanism, or an authentication mechanism of not specified mechanism; what the information-length field carries is the length of the authentication mechanism in the information field.
  • the information-length field and the information field are described below.
  • the way the Action field carries the action instruction for reporting device information is illustrated in Fig. 11 .
  • the value of the Action-type field in the Actions field (such as 0001) indicates what the Action field carries is an action instruction for reporting device information; what the Action-specific field carries is a reporting manner of the device information, such as reporting the complete device information, reporting the updated device information, reporting empty device information, or reporting the identifier of device information database; what the information field carries is the information about the location in the DS client where the device information is stored; what the information-length field carries is the length of the location information in the information field.
  • the description of the Action-specific field, the information-length field and the information field is as follows.
  • the ⁇ information> field indicates the storage location of the device information in the DS client. For example, the DS server asks the DS client to report all the device information, then the ⁇ Action-Specific> field is ⁇ completed>, and the ⁇ information> field is ./.../devinf. If the DS server asks the DS client to report the updated device information, the ⁇ Action-Specific> field is ⁇ updated>, and the ⁇ information> field is ./.../devinf/datastore/CTCAP, which indicates the update information under the CTCAP element.
  • the specification of a part of the device information may be represented with hierarchical URI, such as ./.../devinf/datastore/SyncCap, which indicates the DS client is required to report the device information under the SyncCap element.
  • hierarchical URI such as ./.../devinf/datastore/SyncCap
  • the DS client is required to report the device information under the SyncCap element.
  • the DS client is required by the DS server to report the information of the DataStore with ⁇ DisplayName> being "addressbook", it may be specified with the following URI:
  • ⁇ CTCap> being "text/x-vcard” in DataStore with ⁇ DisplayName> being "addressbook”
  • URI Uniform Resource Identifier
  • the DS server delivers the generated Notification message containing the two Action fields to the DS client.
  • the DS server may deliver the generated Notification message containing two Action fields to the DS client, by means of OTA PUSH (or SIP PUSH) or short messages, to request a session connection.
  • the DS client analyzes the received Notification message, to generate a message which complies with the requirements to initiate a session connection; the message for initiating a session connection is a Package #1 message.
  • the DS client analyzes the Action field carried in the Notification message, and decides how the authentication information and the device information are reported in the following Package #1 message, according to the action instruction for reporting authentication information and the action instruction for reporting device information carried respectively in the two Action fields.
  • Step 940 the DS client sends the generated Package #1 message to the DS server.
  • Steps 950 and 960 are the same as steps 130 and 140 respectively, and the description of which will not be repeated here.
  • the DS client may learn the specific manner of reporting authentication information and device information required by the DS server by means of Notification message, such as the mechanism of the reported authentication information, and the manner of reporting the device information. Therefore, the plurality of interactions between the DS client and the DS server, caused by the inconsistency between the reporting manner of the authentication information and device information and the requirement of the DS server, may be prevented, and network resources may be saved. Pratically, in actual applications, in the Notification message, it may also be possible that only the action instruction for reporting authentication information or reporting device information is carried.
  • Steps 1210 through 1250 are the same as steps 910 through 950 respectively, and the description of which will not be repeated. Because in the present embodiment, the DS server does not specify the authentication mechanism, the DS client will search locally the parameter configuration Management Object for the node with authentication type of AAuthPref. If the node exists and has been assigned a value, the authentication information is reported in the authentication method indicated by the value. If the node does not exist, or the node exists but is not assigned a value, safety authentication is performed in a default authentication method.
  • the default authentication method is to report the authentication information with the authentication mechanism being "auth-basic" in the Package #1 message, the authentication information with the authentication mechanism being "auth-basic" will be carried in the Package #1 message generated by the DS client.
  • the authentication in the default authentication method is successful, in other words, a status code indicating the successful authentication is carried in the Package #2 message sent from the DS server to the DS client.
  • step 1260 after the DS client learns that the authentication is successful according to the received Package #2 message, the default authentication method is recorded, in order for the authentication method to be used in the following authentication, which may increase the probability of successful authentication.
  • the default authentication method is recorded, in order for the authentication method to be used in the following authentication, which may increase the probability of successful authentication.
  • the default authentication method is recorded in the node with authentication type of AAuthPref for specifying the authentication method.
  • the authentication method in which the authentication information with the authentication mechanism for reporting being "auth-basic", is used as the value of the AAuthPref node, and is recorded in the AAuthPref node.
  • the default authentication method is recorded in the node in the parameter configuration Management Object, which node is extended and is related with authentication.
  • a node related to authentication is extended with in the parameter configuration Management Object, and the authentication method for reporting authentication information with authentication mechanism being "auth-basic" is recorded in the extended node.
  • Step 1270 is the same as step 960, and its description will not be repeated here.
  • the DS client may reply with confirmation information to the DS server, indicating that the Notification message is received successfully, after which, the instructed action is performed. Or, in certain special cases, the DS client returns only a confirmation message, without performing the action instructed by the DS server. For example, the authentication by the DS client of the Digest in the Notification message delivered by the DS server is not successful, the DS client is busy and not able to perform the action instructed by the DS server, or the user refuses to perform the action instructed by the DS server, etc. In these cases, the DS client may reply for the Notification message with receiving status information.
  • new authentication information ⁇ NextNonce> may be carried for the DS server to be used when Notification message is delivered by the DS server next time.
  • the DS client may also send status code information to the DS server, in order to indicate status, such as authentication failure, client busy, refused by the user, etc., as illustrated in table 1.
  • the DS client may reply for the Notification message.
  • An example of the message is as follows.
  • the DS server may not reply once more for this message.
  • the DS client is actually terminal equipment. If the DS client does not have the function of receiving Notification messages, the DS client has to receive Notification messages via a Notification client.
  • the Notification client relies on the service implementation. For example, if the Notification message is sent by means of OTA PUSH concerning the service realization, the Notification client is an OTA PUSH client; if the Notification message is sent by means of short messages, the Notification client is a short message client.
  • the DS server does not have the function of sending Notification messages, the DS server has to send Notification messages via a Notification server.
  • the value of the num-actions field indicates the number of actions the DS client is required by the DS server to perform. For example, if the value of the num-actions field is 1, it is indicated that the DS client is required to perform one action. The type of the action and the specific action instruction are carried in one Action field. If the value of the num-actions field is 2, it is indicated that the DS client is required to perform two actions. The types of the two actions and the specific action instructions are carried in two Action fields, respectively. But in practice, the DS client may be instructed to perform an action of empty session initiation by setting the value of the num-actions field to be 0. In that case, the Notification message may not carry an Action field.
  • the Action-specific field in the Action field is actually of no use, the filed may be omitted in practice. In other words, if certain fields in the Action field are not used, the fields may be omitted.
  • the fifth embodiment of the invention involves a system for Notification message processing, as shown in Fig. 13 , which include a DS client 131 and a DS server 132.
  • the DS server 132 includes: a generating module 21 adapted to generate a Notification message for triggering the establishment of a session connection, the Notification message carrying instruction information for instructing the DS client to perform at least one action; a sending module 22 adapted to send the Notification message generated by the generating module to the DS client.
  • the DS client 131 includes: a receiving module 11 adapted to receive, from a DS server, a Notification message for triggering the establishment of a session connection; an analyzing module 12 adapted to analyze the Notification message received by the receiving module 11; and a processing module 13 adapted to perform a corresponding action according to the instruction information obtained by the parsing module 12 from the Notification message.
  • the action the client is instructed to perform is one of or any combination of: synchronization; reporting authentication information; reporting device information; session information indication; or empty session initiation.
  • the DS client may learn the actions and the specific manners for performing the actions which the DS client is expected by the DS server to perform via Notification messages, the plurality of interactions between the client and the server caused due to the manner of performing actions does not meet the requirement of the server may be prevented, network resources are saved and session efficiency is increased.
  • the Notification message carries an action instruction for performing synchronization; the DS client may be configured to select respective synchronization mechanism according to the information, thus the number of session interactions of selecting the synchronization mechanism is decreased and the session efficiency is increased.
  • the DS client may be configured to learn from the Notification message the specific manner of reporting authentication information and/or device information required by the DS server, such as the mechanism of reporting the authentication information, and the manner of reporting device information.
  • the plurality of interactions between the DS client and the DS server caused due to the manner of reporting authentication information and device information does not meet the requirement of the DS server may be prevented, thus network resources are saved.
  • the num-actions field corresponds to the num-syncs field in Fig. 3
  • the Action field corresponds to the sync field in Fig. 3
  • the future-use field and the vendor-specific field are also retained. Therefore, an embodiment of the invention may be configured to be compatible with the conventional art, without modifying the structure of the Notification message in the conventional art too much.

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)
EP07846097A 2007-05-30 2007-12-19 Verfahren und vorrichtung zur verarbeitung von benachrichtigungsmeldungen Ceased EP2079207A4 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN200710108398.0 2007-05-30
CN2007101375550A CN101316221B (zh) 2007-05-30 2007-08-07 通知消息处理方法及设备
PCT/CN2007/071271 WO2008144992A1 (en) 2007-05-30 2007-12-19 A method and device for processing the notification message

Publications (2)

Publication Number Publication Date
EP2079207A1 true EP2079207A1 (de) 2009-07-15
EP2079207A4 EP2079207A4 (de) 2009-12-02

Family

ID=40074558

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07846097A Ceased EP2079207A4 (de) 2007-05-30 2007-12-19 Verfahren und vorrichtung zur verarbeitung von benachrichtigungsmeldungen

Country Status (5)

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

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105208177A (zh) * 2015-09-14 2015-12-30 小米科技有限责任公司 通讯录更新方法、装置及终端

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2087719B1 (de) * 2006-11-15 2018-03-07 Orange Verfahren und system mit mehreren koordinierten zugriffsmöglichkeiten auf nachrichten
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
CN105389123A (zh) * 2015-10-16 2016-03-09 浪潮(北京)电子信息产业有限公司 一种基于双控制器的存储管理方法及系统
CN109495532A (zh) * 2017-09-13 2019-03-19 北京京东尚科信息技术有限公司 客户端更新方法和装置
BR112021011218A2 (pt) 2018-12-13 2021-08-24 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Método para processamento de mensagem de assinatura, e aparelho para processar mensagem de assinatura
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 华控清交信息科技(北京)有限公司 一种任务处理方法、装置和用于任务处理的装置
US12086232B2 (en) * 2021-03-18 2024-09-10 Lenovo (Singapore) Pte. Ltd. Apparatus, method, and program product for selecting an authentication medium

Family Cites Families (9)

* 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
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
US7765316B1 (en) * 2000-10-10 2010-07-27 Intel Corporation Scheduling the uploading of information from a client to a server
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
FI20041634A0 (fi) * 2004-12-20 2004-12-20 Nokia Corp Tarjontaistunnon muodostaminen kommunikaatiojärjestelmässä
CN1805450A (zh) * 2005-01-10 2006-07-19 华为技术有限公司 在域名系统dns机制中实现服务器与客户端数据同步的方法
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 华为技术有限公司 一种协商设备信息的系统、方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105208177A (zh) * 2015-09-14 2015-12-30 小米科技有限责任公司 通讯录更新方法、装置及终端
CN105208177B (zh) * 2015-09-14 2019-02-12 小米科技有限责任公司 通讯录更新方法及装置

Also Published As

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

Similar Documents

Publication Publication Date Title
EP2079207A1 (de) Verfahren und vorrichtung zur verarbeitung von benachrichtigungsmeldungen
EP2091210B1 (de) Nachrichtenverarbeitungsverfahren sowie system, server und endgerät dafür
US11394752B2 (en) Dedicated user priority message
US20100287253A1 (en) Method, apparatus, and system for data synchronization
US8671156B2 (en) Method and apparatus for providing communication history
US20090187622A1 (en) Method, system and apparatus for data synchronization
US20080072043A1 (en) Device management system and method of controlling the same
US20140032493A1 (en) Method, apparatus and system for synchronizing contact information
EP2081318B1 (de) Verfahren und vorrichtung zur initiierung einer sitzungsverbindung
CN101516131A (zh) 一种数据同步的方法、系统和装置
CN101102311A (zh) 一种协商数据同步机制的方法、客户端及系统
WO2015011158A1 (en) User friendly names for stored cpm conversation histories
WO2009115025A1 (zh) 一种xml文档操作方法及xdms
CN101631142A (zh) Sip服务器以及通信系统
CN107786607B (zh) 一种消息重传方法、消息重传服务器及用户设备
CN117097744B (zh) 信息同步方法、受控设备、控制设备及电子设备
US20120066293A1 (en) Data relay system, relay device, and computer readable medium
EP4132053A1 (de) Netzwerkschichtverbindungsverfahren, endgerät und computerlesbares speichermedium
EP1843540B1 (de) Verfahren und Vorrichtung für das Aktualisieren der kryptographischen Schlüssel in einem mobilen Kommunikationsgerät
CN102117298B (zh) Xml文档管理方法及服务器
WO2008071847A1 (en) Managing presence service information in communications system

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20090409

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

A4 Supplementary search report drawn up and despatched

Effective date: 20091103

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 29/08 20060101AFI20091028BHEP

Ipc: H04L 12/58 20060101ALI20091028BHEP

17Q First examination report despatched

Effective date: 20100910

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20120624