CN101316221B - 通知消息处理方法及设备 - Google Patents

通知消息处理方法及设备 Download PDF

Info

Publication number
CN101316221B
CN101316221B CN2007101375550A CN200710137555A CN101316221B CN 101316221 B CN101316221 B CN 101316221B CN 2007101375550 A CN2007101375550 A CN 2007101375550A CN 200710137555 A CN200710137555 A CN 200710137555A CN 101316221 B CN101316221 B CN 101316221B
Authority
CN
China
Prior art keywords
field
information
notification message
client
carry
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.)
Active
Application number
CN2007101375550A
Other languages
English (en)
Other versions
CN101316221A (zh
Inventor
赵琴
李克鹏
柴晓前
赵晖
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 Device Co Ltd
Original Assignee
Huawei Device 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 Device Co Ltd filed Critical Huawei Device Co Ltd
Priority to CN2007101375550A priority Critical patent/CN101316221B/zh
Priority to EP07846097A priority patent/EP2079207A4/en
Priority to PCT/CN2007/071271 priority patent/WO2008144992A1/zh
Priority to JP2009535552A priority patent/JP4943512B2/ja
Publication of CN101316221A publication Critical patent/CN101316221A/zh
Priority to US12/420,343 priority patent/US20100011070A1/en
Application granted granted Critical
Publication of CN101316221B publication Critical patent/CN101316221B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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

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)

Abstract

本发明涉及通信领域，公开了一种通知消息处理方法及设备，使得能够节省网络资源，提高会话效率。本发明中，接收来自DS服务器的触发建立会话连接的通知消息，该通知消息中携带用于指示DS客户端执行至少一个操作的指示信息。DS客户端根据该通知消息中携带的指示信息，执行相应的操作。指示DS客户端执行的操作可以为以下之一或其任意组合：同步操作、认证信息上报操作、设备信息上报操作、会话信息显示操作、或空会话发起操作。

Description

通知消息处理方法及设备
技术领域
本发明涉及通信领域，特别涉及数据同步技术。
背景技术
随着现代通信技术在人类工作和生活中扮演着日益重要的角色，人们对数据传输的质量提出了越来越高的要求，其中数据同步(DataSynchronization，简称“DS”)是一个十分重要的指标。DS技术，是指移动设备与网络服务器之间保持数据同步，同步的数据包括电话本、通讯录、日程、短信、邮件等。
在现有的DS消息中，提供了一种通知(Notification)机制，用于服务器下发Notification(通知)消息给终端设备，终端设备根据Notification里的SessionID(会话ID)、ServerID(服务ID)等信息发起与服务器的会话连接。Notification消息的下发可以通过短消息、OTA PUSH(空中下载推)等方式。
目前，DS服务器与DS客户端之间进行的会话管理流程如图1所示。在步骤110中，DS服务器向DS客户端下发Notification消息，请求会话连接。接着，在步骤120中，DS客户端向DS服务器发起会话连接，发送该DS客户端的认证信息、设备信息给该DS服务器，该设备信息、认证信息包括在管理会话的Package#1(包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>/<background>/       ；‘用户交互模式’
                          <informative>/<user-interaction>；
<not-specified>::＝“00”                        ；‘非特定’
<background>::＝“01”                           ；‘后台模式’
<informative>::＝“10”                          ；‘提示模式’
<user-interaction>::＝“11”                     ；‘确认模式’
<initiator>::＝<client>/<server>                 ；‘会话发起方’
<client>::＝“0”                                ；‘客户端发起’
<server>::＝“1”                                ；‘服务器发起’
<future-use>::＝27*BIT                           ；‘留作扩展’
<sessionid>::＝16*BIT                            ；‘会话标识’
<length-identifier>::＝8*BIT                     ；‘服务器标识的长度’
<server-identifier>::＝<length-identifier>*CHAR  ；‘服务器标识’
<vendor-specific>::＝n*BIT                       ；‘留作扩展’
在DS中的进一步对Notification消息的notification-body进行了扩展，扩展部分的格式如图3所示。其中，字段“num-syncs”表明有几个同步操作，字段“future-use”留作以后扩展，字段“sync1”，字段“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服务器的多次交互，从而节省了网络资源，提高了会话效率。
附图说明
图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-specifc”字段)、信息长度字段(“information-length”字段)，、信息字段(“information”字段)。每个操作字段中各字段的说明如下：
    <Action-type>::＝4*BIT            ；‘用于携带操作所属的操作类型’
    <Action-specifc>::＝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-specifc”字段携带的是与同步操作相关的参数信息；“information”字段携带的是同步的数据库标识，如数据库的统一资源标识(Uniform Resource Identifier，简称“URI”)；“information-length”字段携带的是“information”字段的长度，如数据库URI的长度。
其中，“Action-specifc”字段进一步包括如下字段：“Direction”字段，“Refresh”字段，“ID-Valid”字段，“Log-Valid”字段，“Content-type”字段，如图6所示。下面分别对各字段进行介绍。
“Direction”字段用于指示同步方向，长度为2*BIT，具体说明如下：
    <Direction>::＝<Not-specified>/<from-server>/<from-client>/<two-way> ；‘方
向信息’
    <Not-specified>::＝’00’                    ；’非特定’
    <from-server>::＝’01’                      ；’从服务器，单向’
    <from-client>::＝’10’                      ；’从客户端，单向’
    <two-way>::＝’11’                        ；’双向’
    “Refresh”字段用于指示数据的刷新情况，比如是清除还是保存服务器端
/客户端数据，长度为1*BIT，其具体说明如下：
    <Refresh>::＝<preserve>/<clear>            ；‘刷新信息’
    <preserve>::＝‘0’                        ；‘保存’
    <clear>::＝‘1’                           ；‘清除’
通过该“Refresh”字段和“Direction”字段的结合使用，可以确定刷新哪一方的数据。例如，<Direction>＝01，<Refresh>＝1，表明是由服务器单方发起的数据同步会话，则同步后，刷新客户端的数据。
“ID-Valid”字段用于指示服务器端数据条目的标识信息(ID)是否有效，长度为1*BIT。其具体说明如下：
<ID-Valid>::＝<valid>/<invalid>             ；’ID有效性’
<valid>::＝’1’                            ；’ID有效’
<invalid>::＝’0’                          ；’ID无效’
需要说明的是，DS服务器端必须维护双方标识信息的映射表，如果由于数据库损坏等，导致标识信息无效，将影响双方的同步机制的选择。
“Log-Valid”字段用于指示服务器端的修改日志是否有效，长度为1*BIT。其具体说明如下：
<log-valid>::＝<valid>/<invalid>            ；’日志有效性’
<valid>::＝’1’                            ；’日志有效’
<invalid>::＝’0’                          ；’日志无效’
日志是用于记录DS服务器端数据库、数据条目的改变情况的，如果日志无效，DS服务器将无法告知DS客户端，自身的哪些数据条目被改变了。这将影响双方的同步机制的选择。
“Content-type”字段用于指示数据库中的数据类型，比如是vcard类型还是email类型，长度为23*BIT。
接着，在步骤520中，DS服务器将生成的Notification消息，下发给DS客户端。具体地说，该DS服务器可以通过OTA PUSH(或会话发起协议(SessionInitation Protocol，简称“SIP”)PUSH)的方式或短消息的方式，将生成的如图6所示的Notification消息，下发给DS客户端。
接着，在步骤530中，DS客户端解析收到的Notification消息，选择同步机制。具体地说，DS客户端通过对收到的Notification消息进行解析，得到该消息中的“Action”字段携带的用于同步的操作指示，并根据该操作指示选择合适的同步机制。
其中，对同步机制的选择包括以下之一或其任意组合：对同步方向的选择、对同步数据的选择，对同步行为的选择。
其中，同步数据的选择包括：是否发送全部数据项、是否只发送修改的数据项。
同步行为的选择包括：是否发送数据指纹信息、是否需要对方比较数据项、是否需要对方用接收的数据项覆盖自身存储的数据项。
下面通过几个举例，对DS客户端根据“Action”字段中携带的操作指示，选择合适的同步机制进行简单说明。
比如说，如果DS服务器指定的同步方向为单向，且决定方向为DS服务器，则DS客户端应该选择单向同步。或者，如果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所示。“Action1”字段携带进行同步操作的操作指示，与第一实施方式中的“Action1”字段完全相同，在此不再赘述。下面对“Action2”字段进行具体说明。
“Action2”字段内的“Action-type”字段的值(如0010)，表示本“Action”字段携带的是显示会话信息的操作指示；“information”字段携带的是会话信息的内容，“information-length”字段携带的是会话信息的内容长度。
DS客户端从Notification消息中解析出该“Action2”字段后，可以将“information”字段中的会话信息，以可显示文本的方式显示给用户，比如：“您有新的Email，请查收。”并且，发起一个同步会话，将服务器上的新邮件同步到本DS客户端。由于DS客户端执行会话信息显示操作时，并不需要“Action2”字段内的“Action-specifc”字段的信息，因此该DS客户端可以忽略对该“Action-specifc”字段的解析。
当然，DS客户端从Notification消息中解析出“Action1”字段后，同样需要根据“Action1”字段携带的同步操作的操作指示发起会话同步，该过程已在第一实施方式中进行了说明，在此不再赘述。
另外，在该Notification消息中也可以携带用于指示DS客户端发起空会话操作的“Action”字段，DS客户端解析出该“Action”字段后，通过该“Action”字段中的“Action-type”字段值，可以获知DS服务器期望本DS客户端发起一个空会话。假定“Action-type”字段的值为0011时，表示本“Action”字段携带的发起空会话的操作指示，则该“Action”字段如图8所示。
基于DS客户端发起的空会话，DS服务器可以与DS客户端进行数据同步或设备能力协商。比如说，在空会话建立后，如果DS服务器需要DS客户端的设备信息，可以通过发一个Get命令获取：
<Get>
  <CmdID>1</CmdID>
  <Item>
    <Target>
        <LocURI>./DevInfo</LocURI>
      </Target>
  </Item>
    </Get>
由于DS客户端执行发起空会话的操作时，并不需要“Action2”字段内的“Action-specifc”字段的信息，因此该DS客户端可以忽略对该“Action-specifc”字段的解析。
不难发现，实际上是通过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-1>/<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-specifc”字段携带的是设备信息的上报方式，如是上报完整的设备信息，或是上报更新的设备信息，或是上报空的设备信息，或是上报设备信息数据库标识；“information”字段携带的是设备信息在DS客户端中存储的位置信息；“information-length”字段携带的是“information”字段中位置信息的长度。对“Action-specifc”字段、“information-length”字段和“information”字段的说明如下：
    <Action-specifc>::＝<completed>/<updated>/<null>/URI    ；‘设备信息上
报方式’
    <completed>::＝’00’                         ；’完整的设备信息’
    <updated>::＝’01’                           ；’更新的设备信息’
    <null>::＝’10’                              ；’设备信息为空’
    <URI>::＝’11’                               ；’设备信息数据库标识’
    <information-length>::＝8*BIT                 ；‘设备信息位置链接字段长度’
    <information>::＝<information-length>*CHAR    ；’设备信息的位置链接’
当<Action-Specific>::＝<URI>时，指示的是要求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客户端需要上报SyncCap元素下的设备信息。当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中<CTCap>为”text/x-vcard”的信息，可以使用下面的URI来指定：./DevInf/DataStore[DisplayName＝“addressbook”]/CTCap[CTType＝“text/x-vcard。
如果用于比较的不是元素，而是属性，则使用Element的方式，比如：./DevInf/DataStore[DisplayName＝“addressbook”]。
在步骤920中，该DS服务器将生成的包含这2个“Action”字段的Notification消息，下发给DS客户端。具体地说，该DS服务器可以通过OTA PUSH(或SIPPUSH)的方式或短消息的方式，将生成的包含2个“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所示。
  状态码   意义
  501   DS客户端成功接收。
  502   认证失败。
  503   版本不匹配。
  504   格式错误。
  505   DS服务器标识不存在
  506   用户拒绝
  507   DS客户端忙
  508   非特定错误。
  507～520   留作扩展。
         表1
比如说，DS客户端可以在包1消息中对Notification消息进行回复，消息实例为：
<SyncML>
   <SyncHdr>
          …
          </SyncHdr>
          <SyncBody>
            <Status>
                <CmdID>1</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’>ZG9iZWhhdmUNCg＝＝</NextNonce>
                  </Meta>
                </Chal>
                <Data>506</Data>；表明用户拒绝会话
           </Status>
           …
        </SyncBody>
    </SyncML>
DS服务器可以不对此消息再次进行回复。
值得一提的是，在上述各实施方式中，DS客户端即为终端设备，如果该DS客户端不具备接收Notifcation消息的功能，则该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-specifc”字段并没有实质的意义，因此在实际应用中可以省略掉该字段。也就是说，如果“Action”字段中的某些字段并没有被用到，则这些字段可以被省略掉。
本发明的第五实施方式涉及一种Notification消息处理***，如图13所示，包含DS客户端，和DS服务器。
在DS服务器中包括：生成模块，用于生成触发建立会话连接的Notification消息，该消息中携带用于指示DS客户端执行至少一个操作的指示信息；和发送模块，用于将该生成模块生成的Notification消息，发送给DS客户端。
在DS客户端中包括：接收模块，用于接收来自DS服务器的触发建立会话连接的Notification消息；解析模块，用于解析该接收模块收到的Notification消息；和处理模块，用于根据该解析模块从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 (6)

1.一种通知消息处理方法，其特征在于，包含以下步骤：
接收来自数据同步DS服务器的触发建立会话连接的通知消息，该通知消息中携带用于指示DS客户端执行至少一个操作的指示信息，所述操作是以下至少一种：会话信息显示操作、空会话发起操作；
根据所述通知消息中携带的指示信息，执行相应的操作；
所述通知消息的消息体中包括：
操作个数字段，用于携带指示所述DS客户端执行的操作个数；
操作字段，用于携带相应操作的操作指示；
所述操作字段中包括：
操作类型字段，用于携带操作所属的操作类型；
操作相关信息字段，用于携带与操作相关的参数信息；
信息字段，用于携带执行操作时所需的信息；
信息长度字段，用于携带所述信息字段的长度；
在接收所述通知消息的步骤之后，所述执行相应的操作的步骤之前，还包括以下步骤：
所述DS客户端根据当前状态，判断是否需要根据所述通知消息中携带的指示信息，执行相应的操作，如果判定需要，则执行所述相应的操作；如果判定不需要，则向所述DS服务器回复确认消息，表示拒绝执行所述相应的操作，所述确认消息携带拒绝执行的原因：所述拒绝执行的原因是客户端忙或认证失败或用户拒绝。
2.根据权利要求1所述的通知消息处理方法，其特征在于，
所述操作类型字段中携带的操作类型，为会话信息显示操作的类型；
所述信息字段携带的执行操作时所需的信息，为所述会话信息的内容。
3.根据权利要求1所述的通知消息处理方法，其特征在于，
所述操作类型字段中携带的操作类型，为空会话发起操作的类型。
4.根据权利要求1所述的通知消息处理方法，其特征在于，所述指示DS客户端执行的操作为空会话发起操作；
所述通知消息的消息体中携带操作个数字段，将该操作个数字段的值设置为“0”。
5.一种DS客户端，其特征在于，包括：
接收模块，用于接收来自DS服务器的触发建立会话连接的通知消息，该通知消息中携带用于指示DS客户端执行至少一个操作的指示信息，所述操作是以下至少一种：会话信息显示操作、空会话发起操作；该通知消息的消息体中包括：操作个数字段，用于携带指示所述DS客户端执行的操作个数；操作字段，用于携带相应操作的操作指示；所述操作字段中包括：操作类型字段，用于携带操作所属的操作类型；操作相关信息字段，用于携带与操作相关的参数信息；信息字段，用于携带执行操作时所需的信息；信息长度字段，用于携带所述信息字段的长度；
解析模块，用于解析所述接收模块收到的所述通知消息；
处理模块，用于根据所述DS客户端当前状态，判断是否需要根据所述通知消息中携带的指示信息，执行相应的操作，如果判定需要，则执行所述相应的操作；如果判定不需要，则向所述DS服务器回复确认消息，表示拒绝执行所述相应的操作，所述确认消息携带拒绝执行的原因：所述拒绝执行的原因是客户端忙或认证失败或用户拒绝。
6.一种DS服务器，其特征在于，包括：
生成模块，用于生成触发建立会话连接的通知消息，该通知消息中携带用于指示DS客户端执行至少一个操作的指示信息，所述操作是以下至少一种：会话信息显示操作、空会话发起操作；该通知消息的消息体中包括：操作个数字段，用于携带指示所述DS客户端执行的操作个数；操作字段，用于携带相应操作的操作指示，所述操作字段中包括：操作类型字段，用于携带操作所属的操作类型；操作相关信息字段，用于携带与操作相关的参数信息；信息字段，用于携带执行操作时所需的信息；信息长度字段，用于携带所述信息字段的长度；
发送模块，用于将所述生成模块生成的通知消息，发送给所述DS客户端，以使所述DS客户端根据当前状态，判断是否需要根据所述通知消息中携带的指示信息，执行相应的操作，如果判定需要，则执行所述相应的操作；如果判定不需要，则向所述DS服务器回复确认消息，表示拒绝执行所述相应的操作，所述确认消息携带拒绝执行的原因：所述拒绝执行的原因是客户端忙或认证失败或用户拒绝。
CN2007101375550A 2007-05-30 2007-08-07 通知消息处理方法及设备 Active CN101316221B (zh)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN2007101375550A CN101316221B (zh) 2007-05-30 2007-08-07 通知消息处理方法及设备
EP07846097A EP2079207A4 (en) 2007-05-30 2007-12-19 METHOD AND DEVICE FOR PROCESSING NOTIFICATION MESSAGES
PCT/CN2007/071271 WO2008144992A1 (fr) 2007-05-30 2007-12-19 Procédé et dispositif pour traiter un message de notification
JP2009535552A JP4943512B2 (ja) 2007-05-30 2007-12-19 通知メッセージ処理方法および装置
US12/420,343 US20100011070A1 (en) 2007-05-30 2009-04-08 Method and device for notification message processing

Applications Claiming Priority (3)

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 通知消息处理方法及设备

Publications (2)

Publication Number Publication Date
CN101316221A CN101316221A (zh) 2008-12-03
CN101316221B true CN101316221B (zh) 2012-04-04

Family

ID=40074558

Family Applications (1)

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

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)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102890631A (zh) * 2012-09-13 2013-01-23 新浪网技术(中国)有限公司 基于持久化消息队列传输消息的方法及消息传输装置

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008059158A1 (fr) * 2006-11-15 2008-05-22 France Telecom Procede et systeme de telecommunication offrant une pluralite de moyens d'acces mutuellement coherents a une base de messages
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
JP6785236B2 (ja) * 2015-02-20 2020-11-18 ビザ インターナショナル サービス アソシエーション モバイルデバイスとリーダとの間の非接触データ交換
CN105208177B (zh) * 2015-09-14 2019-02-12 小米科技有限责任公司 通讯录更新方法及装置
CN105389123A (zh) * 2015-10-16 2016-03-09 浪潮(北京)电子信息产业有限公司 一种基于双控制器的存储管理方法及***
CN109495532A (zh) * 2017-09-13 2019-03-19 北京京东尚科信息技术有限公司 客户端更新方法和装置
WO2020118633A1 (zh) 2018-12-13 2020-06-18 Oppo广东移动通信有限公司 订阅消息的处理方法、装置、计算机设备和存储介质
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
US11055314B1 (en) 2018-12-31 2021-07-06 Facebook, Inc. Techniques for a database-driven messaging user interface
CN112187854B (zh) * 2020-08-18 2023-10-20 华控清交信息科技(北京)有限公司 一种任务处理方法、装置和用于任务处理的装置

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 华为技术有限公司 一种协商设备信息的***、方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
中国通信标准化协会.《移动互联网可移动终端数据同步技术要求 第2部分：数据同步协议（报批稿）》.《移动互联网可移动终端数据同步技术要求 第2部分：数据同步协议（报批稿）》.2007, *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102890631A (zh) * 2012-09-13 2013-01-23 新浪网技术(中国)有限公司 基于持久化消息队列传输消息的方法及消息传输装置
CN102890631B (zh) * 2012-09-13 2016-12-07 新浪网技术(中国)有限公司 基于持久化消息队列传输消息的方法及消息传输装置

Also Published As

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

Similar Documents

Publication Publication Date Title
CN101316221B (zh) 通知消息处理方法及设备
CN101313495B (zh) 数据同步方法、***及装置
CN1729468B (zh) 数据同步
CN101316226B (zh) 一种获取资源的方法、装置及***
US8051186B2 (en) Method for device capability negotiation, method, system and device for synchronization
CN101080056B (zh) 一种移动终端的网络浏览器收藏夹的管理方法及***
CA2622835C (en) Email server for processing a threshold number of email jobs for a given user and related methods
US20200142908A1 (en) Database synchronization
CN101227379B (zh) 一种实现数据同步的***和方法
KR20070014188A (ko) 모바일 디바이스들 내의 데이터를 업데이트하는 방법,디바이스 및 소프트웨어
US20110055154A1 (en) Dual-synchronisation method for a mobile electronic device
CN103067478A (zh) 一种传输联系人信息的方法及装置、***
US20050198179A1 (en) Management of message stores
CN107870982A (zh) 数据处理方法、***和计算机可读存储介质
CN101895579A (zh) 通讯录同步方法和***
CN101340286B (zh) 会话连接发起方法及设备
CN101309453B (zh) 用于使无线事务中的消息相关联的***和方法
CN101317408B (zh) 通过互联网提供异步通信的方法和***
CN110069506A (zh) 业务数据的维护方法、装置及服务器
US20100205266A1 (en) Appearance package management method, system and device
CN102598735B (zh) 建立应用会话的方法、设备和相应通知
EP1650674A1 (en) System and method for integrating continous synchronization on a host handheld device
CN101083800A (zh) 一种实现多媒体信息存储的方法、***及装置
CN101374161A (zh) 网络地址簿的实现方法和网络地址簿服务器
CN101626572B (zh) 一种传输设备管理业务的鉴权信息的方法及***

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20171121

Address after: Metro Songshan Lake high tech Industrial Development Zone, Guangdong Province, Dongguan City Road 523808 No. 2 South Factory (1) project B2 -5 production workshop

Patentee after: HUAWEI terminal (Dongguan) Co., Ltd.

Address before: 518129 Longgang District, Guangdong, Bantian HUAWEI base B District, building 2, building No.

Patentee before: Huawei Device Co., Ltd.

CP01 Change in the name or title of a patent holder
CP01 Change in the name or title of a patent holder

Address after: 523808 Southern Factory Building (Phase I) Project B2 Production Plant-5, New Town Avenue, Songshan Lake High-tech Industrial Development Zone, Dongguan City, Guangdong Province

Patentee after: Huawei Device Co., Ltd.

Address before: 523808 Southern Factory Building (Phase I) Project B2 Production Plant-5, New Town Avenue, Songshan Lake High-tech Industrial Development Zone, Dongguan City, Guangdong Province

Patentee before: HUAWEI terminal (Dongguan) Co., Ltd.