專利名稱：一種多終端時(shí)業(yè)務(wù)消息處理方法、系統(tǒng)和裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及移動通信技術(shù)領(lǐng)域，特別是涉及一種多終端時(shí)業(yè)務(wù)消息處理 方法、系統(tǒng)和裝置。
背景技術(shù)：
Push技術(shù)是一種基于客戶服務(wù)器機(jī)制，由服務(wù)器主動將信息發(fā)往客戶端
的技術(shù)，Push技術(shù)應(yīng)用于移動增值業(yè)務(wù)，能夠方便地實(shí)現(xiàn)相關(guān)內(nèi)容的及時(shí)傳 送和用戶的快捷獲取。Push是一個內(nèi)容分發(fā)的機(jī)制，采用客戶/服務(wù)器模式的 工作方式，要求服務(wù)器不需要客戶端發(fā)出具體請求就將所需要的內(nèi)容進(jìn)行分 發(fā)。如圖1所示，為現(xiàn)有技術(shù)Push業(yè)務(wù)的示意圖，它由服務(wù)器發(fā)起，允許Push 消息產(chǎn)生者(PI)向Push代理網(wǎng)關(guān)(PPG)推送信息和傳輸指令進(jìn)一步傳輸 Push內(nèi)容到用戶的技術(shù)。結(jié)構(gòu)由三部分組成Push代理網(wǎng)關(guān)(PPG)、 Push發(fā) 起者(PI)、終端。PPG采用PAP協(xié)議從Push服務(wù)器上獲取消息，再通過 Push-OTA協(xié)議將內(nèi)容發(fā)送給WAP用戶。Push發(fā)起者(PI)發(fā)送push內(nèi)容和 傳遞命令給push代理網(wǎng)關(guān)(PPG )，然后PPG根據(jù)傳遞命令把push內(nèi)容給終 端。
如圖2所示，為現(xiàn)有技術(shù)中SIP Push業(yè)務(wù)的示意圖，SIP( Session Initiation Protocol,會話初始協(xié)議)Push業(yè)務(wù)就是OMA Push OTA over SIP,即通過將 PUSH OTA ( Over The Air,空中協(xié)議)內(nèi)容封裝在SIP消息當(dāng)中，利用現(xiàn)有 的SIP/IP核心網(wǎng)絡(luò)進(jìn)行傳送。SIP是用來在兩個或多個參與者間建立多媒體 會話的應(yīng)用層協(xié)議。Push發(fā)送代理(PPG)和接收代理(Client)作為SIP/IP 核心網(wǎng)的接口點(diǎn)。在SIP Push工作中SIP能提供的功能有用戶的可到達(dá)性， 用戶的可用性，用戶的能力，會話建立和會話管理。
SIP/IP核心網(wǎng)提供了豐富的端到端的媒體會話，及客戶端與服務(wù)器的會 話。它包含有SIP網(wǎng)關(guān)和注冊服務(wù)器，可以提供為SIP客戶端和業(yè)務(wù)的鑒權(quán)和授權(quán)接入業(yè)務(wù)，也可提供SIP注冊和路由功能。Push發(fā)送代理和Push接收 代理功能上是向SIP/IP Core的接口點(diǎn)。
基于SIP的事件訂閱(SUBSCRIBE)機(jī)制或SIP事件框架，定義了允許 在訂閱過程中異步事件的通知。在初始注冊后，Push接收代理應(yīng)發(fā)送一個 SUBSCRIBE請求到Push發(fā)送代理，如果Push接收代理需要為一個特定的 Push業(yè)務(wù)訂閱Push事件，例如傳遞客戶能力信息或訂閱特定事件。Push發(fā)送 代理和Push接收代理應(yīng)支持SUBSCRIBE和NOTIFY方法。特別是Push接 收代理為一些特定的Push內(nèi)容應(yīng)支持訂閱功能，并且應(yīng)支持Push內(nèi)容的接收。 Push發(fā)送代理應(yīng)支持通知功能來接收從Push接收代理訂閱請求和發(fā)送Push 信息到接收代理。
用戶標(biāo)識(User ID)為^^共用戶身^f分。為了^f吏用網(wǎng)絡(luò)， 一個用戶^皮分配 到一個或多個公共用戶身份。當(dāng)用戶請求與其他用戶通信時(shí)，用戶將使用公 共用戶身份。 一個用戶可以有不同的外形，每一個都包含了不同的公共用戶 身份。公共用戶身份的格式采用的通過一等級化的SIP統(tǒng)一資源標(biāo)識(URI)來 標(biāo)識。它通過諸如用戶電話號碼或主機(jī)名等元素來構(gòu)造(例如 SIP:user@company.com )。因?yàn)樗cEMAIL地址的相似性，SIP URLs容易于 用戶的EMAIL地址關(guān)耳關(guān)。
然而當(dāng)一個用戶有多個終端時(shí)，例如電腦，2G終端，3G終端等，每個 終端將被分配到一個設(shè)備識別(DeviceID),是由歸屬網(wǎng)絡(luò)分配，這個身份用 來確定每個終端在一個網(wǎng)絡(luò)中的唯一性。舉例來說，設(shè)備識別被用來鑒定、 授權(quán)、管理。
Push接受代理可以通過發(fā)送Subscribe請求來建立一個內(nèi)容更新訂閱和 宣布可用的應(yīng)用和版本，通過使用"appid"參數(shù)。
Push接收代理只訂閱一個應(yīng)用appl為多々某體彩信(MMS)業(yè)務(wù)時(shí)， SUBSCRIBE sip:user-aor@example.com SIP/2.0
Event:ua曙profile: profile-type=oma-app;appid="+g.oma.iari.push.mms.ua"; 如Push 4妄收代理訂閱多個應(yīng)用app 1, app2， app3 SUBSCRIBE sip:user-aor@example.com SIP/2.0Event: ua-profile; profile-type=oma-app; appid="appl, app2， app3，，； 如果Push接收代理訂閱了多個應(yīng)用appl,app2，app3,但是Push發(fā)送代 理只支持appl和app2，那么Push發(fā)送代理返回的通知NOTIFY請求將只包 含appl和app2兩個參數(shù)，指示只有這兩個業(yè)務(wù)被訂閱成功。 SUBSCRIBE
Event: ua-profile;profile-type=oma-app; appid="app 1 ，app2,app3，，； NOTIFY
Event: ua-profile;profile-type=oma-app; appid="app 1 ，app2";
多媒體彩信通知業(yè)務(wù)為用戶可以訂閱多媒體彩信業(yè)務(wù)，當(dāng)Push發(fā)送代理 有發(fā)送到該終端的多媒體彩信業(yè)務(wù)時(shí)，將向終端發(fā)送彩信通知，通知用戶有 一條彩信，可以去Push發(fā)送代理取回該條彩信。多媒體彩信的取回，可以通 過用戶設(shè)置由終端進(jìn)行自動取回，存儲在終端，待用戶方便時(shí)查看；也可以 由用戶接到彩信通知后，在方便的時(shí)候自己取回。
目前SIP Push業(yè)務(wù)中同一個用戶可以同時(shí)有多個終端，例如，用戶同時(shí) 有2G手機(jī)，3G手機(jī)，臺式電腦，筆記本等終端，在Push發(fā)送代理上存方丈有 該用戶的公共身份識別，來標(biāo)識該用戶，也會有各個終端的i殳備地址，用來 識別每個終端來發(fā)送到達(dá)各個設(shè)備的呼叫或消息。也將有每個終端訂閱了何 種業(yè)務(wù)，當(dāng)有該終端的訂閱的業(yè)務(wù)到來時(shí)，所有終端都可以收到訂閱的業(yè)務(wù)。 訂閱的業(yè)務(wù)可以有多媒體彩信業(yè)務(wù)，短消息業(yè)務(wù)，郵件通知，設(shè)備管理等。 那么會有這樣一個場景，當(dāng)Push發(fā)送代理通過SIP/IP核心網(wǎng)發(fā)送一個多々某體 彩信消息給用戶時(shí)，用戶的每個訂閱了多媒體彩信的終端將都收到這條多媒 體彩信消息的通知。
如圖3所示，為現(xiàn)有技術(shù)中用戶存在多個終端時(shí)的多々某體彩信通信流程 圖，當(dāng)一個用戶同時(shí)有第一終端，第二終端，第三終端三個設(shè)備，MMSC為 多々某體彩信中心(PI), Push發(fā)送代理為PPG。包括以下步驟
步驟S301， MMSC有發(fā)向該用戶的多4某體彩信通知，則向Push發(fā)送代 理發(fā)送多媒體彩信通知。Push發(fā)送代理接收到該彩信通知后，發(fā)現(xiàn)該用戶有 三個終端，分別向三個終端轉(zhuǎn)發(fā)此通知。步驟S302,用戶設(shè)置自動獲取通知的彩信，則三個終端分別向MMSC Push發(fā)送代理發(fā)出HTTP GET請求，請求取回該多媒體彩信。
步驟S303,當(dāng)Push發(fā)送代理接收到第 一終端發(fā)出的請求后，發(fā)送HTTP 200 0K響應(yīng)，攜帶多媒體彩信，發(fā)送給第一終端。
步驟S304， MMSC Push發(fā)送代理對于已經(jīng)取回的多4某體彩信，進(jìn)行刪除， 不再保留，則第二終端和第三終端接收到MMSC返回的HTTP4xx錯誤響應(yīng)。 其中，多i某體彩信的通知也可以由SIP/IP核心網(wǎng)完成轉(zhuǎn)發(fā)給三個終端的過程。
在實(shí)現(xiàn)本發(fā)明實(shí)施例過程中，發(fā)明人發(fā)現(xiàn)現(xiàn)有技術(shù)中至少存在如下問題 用戶的每個終端都收到同樣的彩信通知，首先會造成資源浪費(fèi)，增加網(wǎng)絡(luò)傳
輸?shù)呢?fù)載；同時(shí)，用戶反復(fù)的接收相同的信息，也會對用戶造成困擾。更重 要的是對于多媒體彩信服務(wù)中心來說，不知道用戶當(dāng)前有多少終端，發(fā)出一 份通知后，會由Push發(fā)送代理或SIP/IP核心網(wǎng)處轉(zhuǎn)發(fā)給每一個該用戶的終端。 如果用戶設(shè)置為自動到Push發(fā)送代理提取多媒體彩信，那么只有一個終端可 以成功將多媒體彩信取回，而其他終端的取回請求將失敗，或由多媒體彩信 服務(wù)中心提示所要取回的消息不存在，或返回已取回等消息，因此也會影響
到用戶的體驗(yàn)度。

發(fā)明內(nèi)容
本發(fā)明實(shí)施例要解決的問題是提供一種多終端時(shí)業(yè)務(wù)消息處理方法、系 統(tǒng)和裝置，解決現(xiàn)有技術(shù)中Push發(fā)送代理給每個用戶標(biāo)識相同的終端都發(fā)送 業(yè)務(wù)消息，而造成資源浪費(fèi)，增加網(wǎng)絡(luò)傳輸?shù)呢?fù)載及影響用戶體驗(yàn)度的缺陷。
為達(dá)到上述目的，本發(fā)明實(shí)施例一方面提出一種多終端時(shí)業(yè)務(wù)消息處理 方法，包括以下步驟接收終端發(fā)送的請求消息，所述請求消息攜帶有所述 終端的請求信息；根據(jù)所述請求信息向所述終端發(fā)送業(yè)務(wù)消息。
另一方面，本發(fā)明實(shí)施例還提供了一種多終端時(shí)業(yè)務(wù)消息處理系統(tǒng)，包 括Push發(fā)送代理和至少兩個具有相同用戶標(biāo)識的終端，所述終端，用于向 所述Push發(fā)送代理發(fā)送請求消息，所述請求消息攜帶有所述終端的請求信 息；所述Push發(fā)送代理，用于接收所述終端發(fā)送的請求消息，并根據(jù)所述請求信息向所述終端發(fā)送業(yè)務(wù)消息。
再一方面，本發(fā)明實(shí)施例還提供了一種Push發(fā)送代理，包括訂閱請求接
收模塊和處理模塊，所述訂閱請求接收模塊，用于接收終端發(fā)送訂閱請求，
所述訂閱請求攜帶有所述終端的請求信息；所述處理模塊，用于在業(yè)務(wù)到來 時(shí)，根據(jù)所述請求信息向所述終端發(fā)送業(yè)務(wù)消息。
本發(fā)明實(shí)施例的技術(shù)方案具有以下優(yōu)點(diǎn)，因?yàn)椴捎肞ush發(fā)送代理根據(jù)終 端發(fā)送的請求信息選擇只向一個終端發(fā)送相應(yīng)的業(yè)務(wù)消息，而不是向所有 終端都發(fā)送業(yè)務(wù)消息，從而避免同一用戶的多個終端反復(fù)接收到相同的業(yè) 務(wù)消息，避免資源浪費(fèi)。


圖1為現(xiàn)有技術(shù)Push業(yè)務(wù)的示意圖2為現(xiàn)有技術(shù)中SIP Push業(yè)務(wù)的示意圖3為現(xiàn)有技術(shù)中用戶存在多個終端時(shí)的多i某體彩信通信流程圖4為本發(fā)明實(shí)施例一發(fā)送業(yè)務(wù)訂閱請求的流程圖5為本發(fā)明實(shí)施例一用戶發(fā)送SUBSCRIBE訂閱請求數(shù)據(jù)示意圖6為本發(fā)明實(shí)施例一的200 OK消息示意圖7為本發(fā)明實(shí)施例一的訂閱激活指示示意圖8為本發(fā)明實(shí)施例一的第二終端的請求示意圖9為本發(fā)明實(shí)施例一的可選步驟的流程圖10為本發(fā)明實(shí)施例二在SUBSCRIBE消息中只訂閱 一個業(yè)務(wù)時(shí)命令 傳輸?shù)牧鞒虉D11為本發(fā)明實(shí)施例二用戶發(fā)送SUBSCRIBE訂閱請求消息示意圖； 圖12為本發(fā)明實(shí)施例中對MMS業(yè)務(wù)的訂閱進(jìn)行激活示意圖； 圖13為本發(fā)明實(shí)施例第二終端進(jìn)行訂閱示意圖； 圖14為本發(fā)明實(shí)施例二的訂閱激活業(yè)務(wù)示意圖15為本發(fā)明實(shí)施例三當(dāng)在SUBSCIBE消息中指定訂閱多個業(yè)務(wù)時(shí) 的流程圖；圖16為本發(fā)明實(shí)施例三第一終端向Push發(fā)送代理發(fā)送SUBSCRIBE
訂閱請求示意圖17為本發(fā)明實(shí)施例三的激活指示示意圖18為本發(fā)明實(shí)施例三第二終端進(jìn)行訂閱示意圖19為本發(fā)明實(shí)施例三第二終端業(yè)務(wù)訂閱激活示意圖20為本發(fā)明實(shí)施例四的Push發(fā)送代理選擇優(yōu)先級設(shè)備接受業(yè)務(wù)的
流程圖21為本發(fā)明實(shí)施例四用戶發(fā)送SUBSCRIBE訂閱請求消息示意圖； 圖22為本發(fā)明實(shí)施例四的200 OK消息示意圖； 圖23為本發(fā)明實(shí)施例四的業(yè)務(wù)訂閱激活示意圖24為本發(fā)明實(shí)施例五的終端以HTTP方式發(fā)送給Push發(fā)送代理業(yè)務(wù) 請求的流程圖25為本發(fā)明實(shí)施例多終端時(shí)業(yè)務(wù)消息處理系統(tǒng)結(jié)構(gòu)圖。
具體實(shí)施例方式
下面結(jié)合附圖和實(shí)施例，對本發(fā)明的具體實(shí)施方式
作進(jìn)一步詳細(xì)描述 本發(fā)明實(shí)施例主要解決Push中多終端消息的接收問題，針對該問題本 發(fā)明實(shí)施例提出了多種解決方法。如SIP Push需要支持在訂閱過程中，對 某些特定的業(yè)務(wù)只有一個終端可以進(jìn)行訂閱或訂閱時(shí)對特定業(yè)務(wù)設(shè)置優(yōu)先 級。這樣，當(dāng)Push發(fā)送代理有發(fā)送給該用戶的特定業(yè)務(wù)時(shí)，只有一個終端 將接收到該消息，而不是所有設(shè)備。這樣既可以避免網(wǎng)絡(luò)資源的浪費(fèi)，也 可以避免用戶的多個終端反復(fù)接收到相同消息的到來，特別可以避免因相 同消息的到來影響其他業(yè)務(wù)的正常接收。對于某些特定業(yè)務(wù)，其具體實(shí)現(xiàn) 方法可以為以下幾種方式
1.在訂閱過程中，同一用戶的所有終端中，只有一個終端可以對某項(xiàng) 業(yè)務(wù)進(jìn)行訂閱。即當(dāng)前終端訂閱了某項(xiàng)業(yè)務(wù)后，該用戶的其他終端發(fā)起同 樣業(yè)務(wù)的訂閱時(shí)，Push發(fā)送代理將通知該終端此業(yè)務(wù)已經(jīng)訂閱，不能再次 進(jìn)行訂閱。2. 當(dāng)?shù)谝唤K端訂閱某業(yè)務(wù)成功后，向其他終端發(fā)送該業(yè)務(wù)已經(jīng)被訂閱 的通知，避免重復(fù)訂閱來達(dá)到只有一個終端可以訂閱某項(xiàng)業(yè)務(wù)的目的。
3. 所有終端都可以對某項(xiàng)業(yè)務(wù)進(jìn)行訂閱，但在訂閱過程中，終端完成 優(yōu)先級設(shè)置，優(yōu)先級的策略設(shè)置在Push發(fā)送代理上進(jìn)行存儲，由Push發(fā) 送代理進(jìn)行消息分發(fā)的控制。所以當(dāng)有此業(yè)務(wù)到來時(shí)，只有一個終端首先 接收到業(yè)務(wù)的消息，其他終端不會同時(shí)接收。
4. 所有終端都可以對某項(xiàng)業(yè)務(wù)進(jìn)行訂閱，由Push發(fā)送代理選擇優(yōu)先 級設(shè)置根據(jù)網(wǎng)絡(luò)側(cè)情況，選擇某一個終端，發(fā)送業(yè)務(wù)消息，其他終端不會 同時(shí)接收。
5. 用戶、終端或訂閱的業(yè)務(wù)信心可以分別通過注冊或/和訂閱請求發(fā) 送到Push發(fā)送代理。
下面就針對上述方式對本發(fā)明實(shí)施例以訂閱消息進(jìn)4亍詳細(xì)描述。
如圖4所示，為本發(fā)明實(shí)施例一發(fā)送業(yè)務(wù)訂閱請求的流程圖，第一終 端，第二終端，分別為同一用戶的兩個不同設(shè)備，在本實(shí)施例中只有一個 終端可以對某項(xiàng)業(yè)務(wù)進(jìn)行訂閱。即當(dāng)前終端訂閱了某項(xiàng)業(yè)務(wù)后，該用戶的 其他終端發(fā)起同樣的業(yè)務(wù)請求的訂閱時(shí)，Push發(fā)送代理將通知該終端已經(jīng) 訂閱，不能在進(jìn)行訂閱。用來區(qū)分用戶不同終端的可以是IMSI,私有用戶 標(biāo)識Private User Identity,全局可路由用戶代理GRUU,或多個聯(lián)系地址 Multiple contact information 、 IP地址、電話號碼或設(shè)備號等。具體步驟為
步驟S401 ，本實(shí)施例中以用戶john.doe@homel.net為例，用戶 john.doe@homel.net的第一終端向Push發(fā)送代理發(fā)送SUBSCRIBE訂閱請 求，并攜帶其用戶標(biāo)識、Device ID和應(yīng)用標(biāo)識，訂閱了 MMS業(yè)務(wù)。
如圖5所示，為本發(fā)明實(shí)施例一用戶發(fā)送SUBSCRIBE訂閱請求數(shù)據(jù) 示意圖，其中，首先Push發(fā)送代理進(jìn)行對用戶的用戶標(biāo)識,Device ID,應(yīng) 用標(biāo)識進(jìn)4亍識別，在識別通過后，第一終端向Push發(fā)送4戈理發(fā)動訂閱MMS 業(yè)務(wù)請求，請求通過后，將Device ID寫入數(shù)據(jù)庫，此Device ID可以用 于區(qū)分不同的終端。
步驟S402,在"uajrofile，，事件包的SIP訂閱請求4妾收到以后，Push發(fā)送代理完成必要的關(guān)于發(fā)起者的身份鑒權(quán)檢查，根據(jù)本地規(guī)則判定是否 有允許訂閱(允許用戶從它的當(dāng)前設(shè)備訂閱)。如果鑒權(quán)成功，它創(chuàng)建一個
"uajrofile"事件包的訂閱對話，提供由"Event，，頭域參數(shù)識別數(shù)據(jù)變化的 方法，然后返回200 0K到訂閱者。該步驟200OK示意圖如圖6所示。
步驟S403, Push發(fā)送代理產(chǎn)生和發(fā)送一個初始的SIP NOTIFY包含 一個空的主體，其中指示業(yè)務(wù)訂閱已經(jīng)激活。如圖7所示，為本發(fā)明實(shí)施 例一的訂閱激活指示示意圖。要使用戶終端訂閱的MMS業(yè)務(wù)生效，須在 此步驟中對MMS業(yè)務(wù)的訂閱激活。
步驟S404, Push接收代理響應(yīng)200 OK。
當(dāng)Push發(fā)送代理接受到業(yè)務(wù)消息到來時(shí)，Push發(fā)送代理向剛才發(fā)送 過來業(yè)務(wù)請求的終端以發(fā)送一個SIP NOTIFY i會求的方式來提交一個Push內(nèi)容。
步驟S405,用戶的第二終端以john.doe@homel.net的公共用戶身份， 但不同的Device ID向Push發(fā)送代理發(fā)送訂閱MMS業(yè)務(wù)請求。如圖8所 示，為本發(fā)明實(shí)施例一的第二終端的請求示意圖，本步驟與步驟S401區(qū) 別在于使用的設(shè)備不同，既Device ID不同，通過Device ID就可以區(qū)分并 識別出發(fā)送的設(shè)備。
步驟S406 , Push發(fā)送代理發(fā)現(xiàn)用戶的公共用戶身份也為 john.doe@homel.net,訂閱的業(yè)務(wù)也為MMS,此用戶已經(jīng)使用其它設(shè)備訂 閱過MMS業(yè)務(wù)，返回4XX響應(yīng)，提示用戶改業(yè)務(wù)已經(jīng)訂閱成功，不可以 再次訂閱。
由于此用戶的第一終端設(shè)備已經(jīng)向此Push發(fā)送代理訂閱過MMS業(yè) 務(wù)，故PUSH發(fā)送代理判斷出該用戶已經(jīng)訂閱過了 MMS業(yè)務(wù)，于是給用 戶的第二終端返回4XX的信息。
在本發(fā)明實(shí)施例中，可以有一個可選的步驟，即在第一終端訂閱成功 后，Push發(fā)送代理向注冊的所有終端發(fā)送NOTIFY消息，提示此業(yè)務(wù)已經(jīng) 被訂閱成功，不需要再次訂閱。其他終端的地址信息可以在每個終端注冊 時(shí)，在Push發(fā)送代理或SIP/IP核心網(wǎng)中有存儲和與該用戶進(jìn)行綁定，可以實(shí)現(xiàn)將消息通知給該用戶的所有終端。
如圖9所示為本發(fā)明實(shí)施例一的可選步驟的流程圖。具體步驟如下
步驟S901,用戶(john.doe@homel.net)的第一終端向Push發(fā)送代理 發(fā)送SUBSCRIBE訂閱請求，并攜帶其用戶標(biāo)識,Device ID,和應(yīng)用標(biāo)識， 訂閱了 MMS業(yè)務(wù)。
步驟S卯2，在"uajrofile"事件包的SIP訂閱請求接收到以后，Push 發(fā)送代理完成必要的關(guān)于發(fā)起者的身份鑒權(quán)檢查，根據(jù)本地規(guī)則判定是否 有允許訂閱(允許用戶從它的當(dāng)前設(shè)備訂閱)。如果鑒權(quán)成功，它創(chuàng)建一個 "uajrofile"事件包的訂閱對話，提供由"Event"頭域參數(shù)識別數(shù)據(jù)變化的 方法，然后返回200 OK到訂閱者。
步驟S903， Push發(fā)送代理產(chǎn)生和發(fā)送一個初始的SIP NOTIFY包含 一個空的主體，其中指示業(yè)務(wù)訂閱已經(jīng)激活。
步驟S卯4， Push接收代理響應(yīng)200 OK。
步驟S905, Push發(fā)送代理向其他終端發(fā)送NOTIFY消息，在NOTIFY 消息頭域或體中攜帶消息，通知該用戶的其它終端MMS業(yè)務(wù)已經(jīng)有第一 終端訂閱成功，提示其他終端不要進(jìn)行再次訂閱。
步驟S906,其他終端返回200 0K消息，提示接受請求。
在本發(fā)明實(shí)施例中，由于SIPPush在訂閱過程中，某些特定的業(yè)務(wù)只 能有一個終端進(jìn)行訂閱，同本實(shí)施例解決了這個問題，這樣可以當(dāng)Push 發(fā)送代理有發(fā)送給該用戶特定業(yè)務(wù)的時(shí)，只有這個終端才能接收到這個消 息，并不時(shí)所有的設(shè)備，避免了網(wǎng)絡(luò)的浪費(fèi)。
實(shí)施例二
如圖10所示，為本發(fā)明實(shí)施例二在SUNSCRIBE消息中只訂閱 一個業(yè) 務(wù)時(shí)命令傳輸?shù)牧鞒虉D。本實(shí)施例給出用戶第一終端，第二終端，分別為 同一用戶的兩個不同設(shè)備。當(dāng)?shù)谝唤K端在發(fā)送業(yè)務(wù)的訂閱請求到Push發(fā) 送代理時(shí)，用公共用戶標(biāo)識身份和私有用戶身份識別，同時(shí)攜帶一個優(yōu)先 級參數(shù)Qvalue,指示Push發(fā)送代理對于訂閱的業(yè)務(wù)，優(yōu)先向優(yōu)先級高的 發(fā)送，如果成功發(fā)送，則不向第二終端發(fā)送，如果失敗，繼續(xù)向下一優(yōu)先級終端發(fā)送。
業(yè)務(wù)的實(shí)現(xiàn)是由終端在發(fā)送SUBSCRIBE消息時(shí)，主動向Push發(fā)送代 理提交一個優(yōu)先級的名單，通過這種設(shè)置后，將只有用戶希望的一個終端 優(yōu)先收到業(yè)務(wù)消息。Qvalue參數(shù)值越高，表明所給位置的相對重要性越高， 取值范圍可以在0至1之間。
用來區(qū)分用戶不同終端的可以是IMSI,私有用戶標(biāo)識Private用戶標(biāo) 識entity,全局可路由用戶代理GRUU,或多個聯(lián)系地址Multiple contact information, IP地址、電話號碼或設(shè)備號等。本實(shí)施例一共有兩種方案， 當(dāng)在SUBSCRIBE消息中指訂閱一個業(yè)務(wù)，即只有一個應(yīng)用標(biāo)識時(shí)具體步 驟為
步驟S1001,用戶(john.doe@homel.net)的第一終端向Push發(fā)送代 理發(fā)送SUBSCRIBE訂閱請求，并攜帶其用戶標(biāo)識,Device ID, Qvalue參數(shù)， 以及一個應(yīng)用標(biāo)識，訂閱MMS業(yè)務(wù)。消息中告知Push發(fā)送代理該用戶的 此終端為希望接收到MMS業(yè)務(wù)的最高優(yōu)先級終端，則當(dāng)有業(yè)務(wù)到來時(shí)， 優(yōu)先發(fā)給此終端。如圖ll所示，為本發(fā)明實(shí)施例二用戶發(fā)送SUBSCRIBE 訂閱請求消息示意圖。首先進(jìn)行用戶的識別，然后進(jìn)行訂閱MMS業(yè)務(wù)， 最后在CONTACT:處設(shè)置了優(yōu)先級，本實(shí)施例中設(shè)置的優(yōu)先級為0.7 (Contact: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp= sigcomp>;q=0.7) 通過此優(yōu)先級設(shè)置可進(jìn)行選擇性的發(fā)送。
步驟S1002,在圖10中的"uajrofile"事件包的SIP訂閱請求接收到以 后，Push發(fā)送代理完成必要的關(guān)于發(fā)起者的身份鑒權(quán)檢查，根據(jù)本地規(guī)則 判定是否有允許訂閱(允許用戶從它的當(dāng)前設(shè)備訂閱)。如果鑒權(quán)成功，它 創(chuàng)建一個"uaj(rofile"事件包的訂閱對話，提供由"Event"頭域參數(shù)識別數(shù) 據(jù)變化的方法，然后返回200 OK到訂閱者。
步驟S1003, Push發(fā)送代理產(chǎn)生和發(fā)送一個初始的SIP NOTIFY包含 一個空的主體，其中指示業(yè)務(wù)訂閱已經(jīng)激活。也可以在Contact頭域中， 通知該終端其它終端的優(yōu)先級信息。如圖12所示，為本發(fā)明實(shí)施例二對 MMS業(yè)務(wù)的訂閱進(jìn)行激活示意圖。步驟S1004, Push接收代理響應(yīng)200 OK。
這樣當(dāng)Push發(fā)送代理有發(fā)向業(yè)務(wù)消息到來時(shí)，可以在訂閱對話中， Push發(fā)送代理通過向Push接收代理發(fā)送一個SIP NOTIFY請求的方式提 交一個Push內(nèi)容。
步驟S1005，第二終端也可對MMS業(yè)務(wù)進(jìn)行訂閱，向Push發(fā)送代理 發(fā)送SUBSCRIBE訂閱請求，并攜帶其用戶標(biāo)識,Device ID, Qvalue參數(shù)， 以及一個應(yīng)用標(biāo)識，訂閱MMS業(yè)務(wù)。消息中告知Push發(fā)送代理該用戶的 此終端為希望接收到MMS業(yè)務(wù)的次高優(yōu)先級終端。則當(dāng)有業(yè)務(wù)到來時(shí)， 如果第一終端不能正常接收，第二優(yōu)先級發(fā)給此終端。如圖13所示，為本 發(fā)明實(shí)施例第二終端進(jìn)行訂閱示意圖，在第二終端中也設(shè)置了優(yōu)先權(quán)， (Contact: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp>;q=0.6 ), 本實(shí) 施例中設(shè)置的優(yōu)先權(quán)為0.6,由于第二終端的優(yōu)先權(quán)低于第一終端，故當(dāng)?shù)?一終端不能正常接收時(shí)，則選擇第二優(yōu)先級終端發(fā)送信息。
步驟S1006,在"uajrofile"事件包的SIP訂閱請求接收到以后，Push 發(fā)送代理完成必要的關(guān)于發(fā)起者的身份鑒權(quán)檢查，根據(jù)本地規(guī)則判定是否 有允許訂閱(允許用戶從它的當(dāng)前設(shè)備訂閱)。如果鑒權(quán)成功，它創(chuàng)建一個 "uajrofile"事件包的訂閱對話，提供由"Event，，頭域參數(shù)識別數(shù)據(jù)變化的 方法，然后返回200 OK到訂閱者。
步驟S1007, Push發(fā)送代理產(chǎn)生和發(fā)送一個初始的SIP NOTIFY包含 一個空的主體，其中指示業(yè)務(wù)訂閱已經(jīng)激活。如圖14所示，為本發(fā)明實(shí)施 例二的訂閱激活業(yè)務(wù)示意圖，步驟將MMS業(yè)務(wù)的訂閱激活，也在可以在 Contact頭域中，通知該終端其他終端的優(yōu)先級信息。
步驟S1008, Push接收代理響應(yīng)200 OK。
如圖15所示，為本發(fā)明實(shí)施例三當(dāng)在SUBSCIBE消息中指定訂閱多 個業(yè)務(wù)時(shí)的流程圖，且在該實(shí)施例中存在多個應(yīng)用標(biāo)識，其中以用戶 john.doe@homel.net舉例進(jìn)行^兌明，具體步驟為
步驟S1501,用戶john.doe@homel.net的第一終端向Push發(fā)送代理發(fā) 送SUBSCRIBE訂閱請求，并攜帶其用戶標(biāo)識,Device ID, Qvalue參數(shù)，以及多個應(yīng)用標(biāo)識，訂閱多個業(yè)務(wù)。消息中告知Push發(fā)送代理該用戶的此終 端為希望接收到Appl業(yè)務(wù)的最高優(yōu)先級終端，則當(dāng)有業(yè)務(wù)到來時(shí)，優(yōu)先 發(fā)給此終端。App2為此終端第二優(yōu)先級接收的業(yè)務(wù)，App3為此終端第三 優(yōu)先級希望接收的業(yè)務(wù)。如圖16所示，為本發(fā)明實(shí)施例三第一終端向Push 發(fā)送代理發(fā)送SUBSCRIBE訂閱請求示意圖，在APP字節(jié)^爻存在了 3個不 同的優(yōu)先級值，appid="appl;q=0.7, app2;q=0.6, app3; q=0.5,優(yōu)先級由高到 低排列，Push發(fā)送代理會通過優(yōu)先級知道該終端最想接收那種業(yè)務(wù)，Push 發(fā)送代理就會將優(yōu)先級高的業(yè)務(wù)給該終端發(fā)送，待高優(yōu)先級業(yè)務(wù)發(fā)送完畢 后，在進(jìn)行較低優(yōu)先級業(yè)務(wù)的發(fā)送。
步驟S1502,在"uajrofile"事件包的SIP訂閱請求接收到以后，Push 發(fā)送代理完成必要的關(guān)于發(fā)起者的身份鑒權(quán)檢查，根據(jù)本地規(guī)則判定是否 有允許訂閱(允許用戶從它的當(dāng)前設(shè)備訂閱)。如果鑒權(quán)成功，它創(chuàng)建一個 "uajrofile"事件包的訂閱對話，提供由"Event"頭域參數(shù)識別數(shù)據(jù)變化的 方法，然后返回200 OK到訂閱者。
步驟S1503, Push發(fā)送代理產(chǎn)生和發(fā)送一個初始的SIP NOTIFY包含 一個空的主體，其中指示業(yè)務(wù)訂閱已經(jīng)激活。如圖17所示，為本發(fā)明實(shí)施 例三激活指示示意圖，在消息中可以通知第 一終端每種業(yè)務(wù)的訂閱是否已 經(jīng)激活。
步驟S1504, Push接收代理響應(yīng)200 OK。當(dāng)Push發(fā)送代理接到到業(yè) 務(wù)消息時(shí)，可以在訂閱的對話中，Push發(fā)送代理通過Push 4妄受代理發(fā)送 一個SIP NOTIFY請求的方式來提交一個PUSH內(nèi)容。
步驟S1505,第二終端向Push發(fā)送代理發(fā)送SUBSCRIBE訂閱請求， 并攜帶其用戶標(biāo)識,Device ID, Qvalue參數(shù)，以及多個應(yīng)用標(biāo)識，訂閱多 個業(yè)務(wù)。消息中告知Push發(fā)送代理該用戶的此終端為希望4妄收到app2業(yè) 務(wù)的最高優(yōu)先級終端，則當(dāng)有業(yè)務(wù)到來時(shí)，優(yōu)先發(fā)給此終端。Appl為此終 端第二優(yōu)先級接收的業(yè)務(wù)，app3為此終端第三優(yōu)先級希望接收的業(yè)務(wù)。如 圖18所示，為本發(fā)明實(shí)施例三第二終端進(jìn)行訂閱示意圖，首先進(jìn)行用戶的 識別在用戶ID, Device ID, Qvalue參數(shù)通過后，把需要訂閱的業(yè)務(wù)分別寫入優(yōu)先級，本實(shí)施例中APP2的優(yōu)先級最高為0.7，最后寫入設(shè)備的ID, 該步驟中設(shè)備終端為第二終端。
步驟S1506,在"uaj)rofile"事件包的SIP訂閱請求接收到以后，Push 發(fā)送代理完成必要的關(guān)于第二終端的身份鑒權(quán)檢查，根據(jù)本地規(guī)則判定是 否有允許訂閱(允許用戶從它的當(dāng)前設(shè)備訂閱)。如果鑒權(quán)成功，它創(chuàng)建一 個"uajrofile"事件包的訂閱對話，提供由"Event"頭域參數(shù)識別數(shù)據(jù)變化 的方法，然后返回200 OK到訂閱者。
步驟S1507, Push發(fā)送代理產(chǎn)生和發(fā)送一個初始的SIP NOTIFY包含 一個空的主體，其中指示業(yè)務(wù)訂閱已經(jīng)激活。也可以在Contact頭域中， 通知該終端其它終端的優(yōu)先級信息。如圖19所示，為本發(fā)明實(shí)施例三第二 終端業(yè)務(wù)訂閱激活示意圖。如果需要通知第二終端其他終端的優(yōu)先級信息 的話，可以在Contact前部加入其他終端優(yōu)先級的信息。
步驟SI508, Push接收代理響應(yīng)200 OK。
在本實(shí)施例中，通過設(shè)置了優(yōu)先級，當(dāng)對某項(xiàng)業(yè)務(wù)訂閱時(shí)，高優(yōu)先級 的終端如果不能接受，則可以轉(zhuǎn)到低優(yōu)先級的終端進(jìn)行接受，不會出現(xiàn)同 時(shí)接受的情況，可以避免用戶的多個終端反復(fù)接收到相同的消息，特別可 以避免因相同消息的到來影響其他業(yè)務(wù)的正常接收。
如圖20所示，為本發(fā)明實(shí)施例四的Push發(fā)送代理選擇優(yōu)先級設(shè)備接受 業(yè)務(wù)的流程圖，本實(shí)施例給出用戶的所有終端都可以進(jìn)行相同業(yè)務(wù)的訂閱。 由Push發(fā)送代理選擇優(yōu)先級設(shè)置根據(jù)網(wǎng)絡(luò)側(cè)情況，選擇某一個終端，發(fā)送業(yè) 務(wù)消息，其他終端不會同時(shí)接收。用戶的所有終端可以通過發(fā)送業(yè)務(wù)的訂閱 請求到Push發(fā)送代理時(shí)，用公共用戶標(biāo)識身份，同時(shí)攜帶私有用戶身份識別， 可以為Contact地址。Push發(fā)送代理將返回響應(yīng)，指示為用戶的所有終端開通 訂閱的業(yè)務(wù)。用來區(qū)分用戶不同終端的可以是IMSI,私有用戶標(biāo)識Private User Identity,全局可路由用戶代理GRUU,或多個聯(lián)系地址Multiple contact information IP地址、電話號碼或設(shè)備號等。本實(shí)施例具體步驟如下
步驟 S2001 , 本實(shí)施例以用戶 john.doe@homel.net 為例， john.doe@homel.net的第 一終端向Push發(fā)送代理發(fā)送SUBSCRIBE訂閱請求，并攜帶其用戶標(biāo)識、Device ID和應(yīng)用標(biāo)識，訂閱了 MMS業(yè)務(wù)。如圖21所 示，為本發(fā)明實(shí)施例四用戶發(fā)送SUBSCRIBE訂閱請求消息示意圖。首先 進(jìn)行用戶的識別，用戶標(biāo)識認(rèn)證正確后進(jìn)行MMS業(yè)務(wù)的訂閱，最后加上終端 Device ID,代表此終端已經(jīng)訂閱過此業(yè)務(wù)。
步驟S2002,在"uajrofile"事件包的SIP訂閱請求接收到以后，Push發(fā) 送代理完成必要的關(guān)于發(fā)起者的身份鑒權(quán)檢查，根據(jù)本地規(guī)則判定是否有允 許訂閱(允許用戶從它的當(dāng)前設(shè)備訂閱)。如果鑒權(quán)成功，它創(chuàng)建一個 "uajrofile"事件包的訂閱對話，提供由"Event"頭域參數(shù)識別數(shù)據(jù)變化的方 法，然后返回200 0K到訂閱者。如圖22所示，為本發(fā)明實(shí)施例四的200 OK 示意圖。
步驟S2003, Push發(fā)送代理產(chǎn)生和發(fā)送一個初始的SIP NOTIFY包含一 個空的主體，其中指示業(yè)務(wù)訂閱已經(jīng)激活。如圖23所示，為本發(fā)明實(shí)施例四 的業(yè)務(wù)訂閱激活示意圖。
步驟S2004,這樣當(dāng)Push發(fā)送代理有發(fā)向業(yè)務(wù)消息到來時(shí)，可以在訂閱 對話中，Push發(fā)送代理通過向Push接收代理發(fā)送一個SIP NOTIFY請求的方 式4是交一個Push內(nèi)容。
步驟S2005-S2008，為第二終端向Push發(fā)送代理訂閱MMS業(yè)務(wù)的過程， 首先進(jìn)行用戶的ID檢測，在進(jìn)行MMS業(yè)務(wù)的訂閱，然后寫入設(shè)備的ID,最 后對MMS業(yè)務(wù)的訂閱進(jìn)行激活。
步驟S2009,當(dāng)有發(fā)往該用戶的MMS消息時(shí)，Push發(fā)送代理根據(jù)設(shè)定 的判斷情況進(jìn)行判斷，選^^該用戶的最佳的終端向其發(fā)送業(yè)務(wù)消息。布支設(shè)最 佳終端為第一終端。
由于Push發(fā)送代理可以自動判斷終端設(shè)備的優(yōu)越性，判斷的條件為設(shè)備 的優(yōu)先級，該優(yōu)先級一般由網(wǎng)絡(luò)質(zhì)量來判斷，Push發(fā)送代理可以選擇網(wǎng)絡(luò)質(zhì) 量較好的終端設(shè)備給用戶提供較好的業(yè)務(wù)信息服務(wù)。本實(shí)施例中以第 一終端 做為較優(yōu)終端給用戶提供業(yè)務(wù)信息服務(wù)。
步驟S2010,通過NOTIFY消息，向第一終端發(fā)送業(yè)務(wù)消息。
步驟S2011,第一終端返回200ok消息，指示消息接受成功。如圖24所示，為本發(fā)明實(shí)施例五的終端以HTTP方式發(fā)送給Push發(fā)送 代理業(yè)務(wù)請求的流程圖。如果終端通過向Push發(fā)送代理發(fā)送請求，告知Push 發(fā)送代理接受某些業(yè)務(wù)所希望使用的終端，在本實(shí)施例方案二中這個終端以 HTTP的方式向Push發(fā)送代理發(fā)送終端設(shè)置的接受業(yè)務(wù)的優(yōu)先級列表。具體 步驟如下
52401, 用戶使用第一終端設(shè)置一個接收業(yè)務(wù)的優(yōu)先級列表。 該優(yōu)先級列表可以指示該終端首先希望接收各種業(yè)務(wù)，在實(shí)施例三的方
案二中以MMS業(yè)務(wù)為例，既第一終端希望接受MMS業(yè)務(wù)。
52402, Push發(fā)送代理返回200 0K消息，提示終端接收到策略列表。
52403, 用戶使用第二終端設(shè)置一個接收業(yè)務(wù)的優(yōu)先級列表， 在本實(shí)施例中與第一終端一樣，第二終端可以指示該終端首先希望接收
郵件通知業(yè)務(wù)。
52404, Push發(fā)送代理返回200 0K消息，提示終端接收到策略列表。 本實(shí)施例通過設(shè)置設(shè)備終端的優(yōu)先級或是HTTP方式的接受業(yè)務(wù)優(yōu)先級
列表，通過服務(wù)來根據(jù)網(wǎng)絡(luò)情況選擇優(yōu)先級設(shè)置較高的終端來給客戶提供較 優(yōu)先的業(yè)務(wù)信息服務(wù)，并且發(fā)送業(yè)務(wù)時(shí)，其他終端不會同時(shí)接收，從而提高 了服務(wù)的質(zhì)量，減少了不比要的數(shù)據(jù)傳輸。
如圖25所示，為本發(fā)明實(shí)施例多終端時(shí)業(yè)務(wù)消息處理系統(tǒng)結(jié)構(gòu)圖，該 系統(tǒng)包括Push發(fā)送代理1和至少兩個具有相同用戶標(biāo)識的終端2,終端2用 于向Push發(fā)送代理1發(fā)送訂閱請求，其中該訂閱請求攜帶有終端2的請求 信息；Push發(fā)送代理1用于接收終端2發(fā)送的訂閱請求，并根據(jù)請求信息向 終端2發(fā)送業(yè)務(wù)消息。其中，請求信息包括用戶標(biāo)識、Device ID和應(yīng)用 標(biāo)識。
其中，Push發(fā)送代理1包括消息請求接收模塊11和處理才莫塊12,消息 請求接收4莫塊11用于接收終端2發(fā)送訂閱請求，訂閱請求攜帶有終端2的 請求信息；處理模塊12用于在業(yè)務(wù)到來時(shí)，根據(jù)請求信息向終端2發(fā)送業(yè) 務(wù)消息。
其中，處理模塊12包括判斷子模塊121、訂閱指示發(fā)送子模塊122和業(yè)務(wù)消息發(fā)送子模塊123，判斷子模塊121用于根據(jù)所述請求信息用戶標(biāo)識和 應(yīng)用標(biāo)識判斷終端2申請的業(yè)務(wù)是否已有相同用戶標(biāo)識的終端申請；訂閱指 示發(fā)送子模塊122用于在判斷子模塊121判斷沒有相同用戶標(biāo)識的終端申請 時(shí)，向終端2發(fā)送業(yè)務(wù)訂閱激活指示；業(yè)務(wù)消息發(fā)送子模塊123用于在業(yè)務(wù) 到來時(shí)，向終端2發(fā)送業(yè)務(wù)消息。
其中，處理模塊12還包括提示響應(yīng)返回子模塊124用于在判斷子模塊 122判斷有相同用戶標(biāo)識的終端申請時(shí)，向終端2返回提示響應(yīng)，提示終端 2所述業(yè)務(wù)已經(jīng)被訂閱。
其中，處理模塊12還包括提示消息發(fā)送子模塊125，用于在訂閱指示發(fā) 送子模塊123向終端2發(fā)送業(yè)務(wù)訂閱激活指示之后，向與終端2有相同用戶 標(biāo)識其他終端發(fā)送提示NOTIFY消息，提示其他終端不要進(jìn)行再次訂閱。
其中，處理模塊12包括優(yōu)先級判斷子模塊126，用于根據(jù)終端2上報(bào)的 相應(yīng)的業(yè)務(wù)優(yōu)先級判斷是否向終端2發(fā)送所述業(yè)務(wù)消息，如果判斷發(fā)送則通 知業(yè)務(wù)消息發(fā)送子模塊124向終端2發(fā)送業(yè)務(wù)消息。
其中，處理模塊12包括網(wǎng)絡(luò)側(cè)配置保存子模塊127和最佳終端判斷子 模塊128,網(wǎng)絡(luò)側(cè)配置保存子模塊127用于保存網(wǎng)絡(luò)側(cè)配置；最佳終端判 斷子模塊128用于根據(jù)網(wǎng)絡(luò)側(cè)配置保存子模塊127保存的網(wǎng)絡(luò)側(cè)配置和終 端2的Device ID判斷終端2是否為最佳終端，在判斷終端2為最佳終端時(shí) 通知所述業(yè)務(wù)消息發(fā)送子模塊124向終端2發(fā)送業(yè)務(wù)消息。
其中，處理模塊12包括策略列表接收子模塊129和策略判斷子模塊130, 策略列表接收子模塊129用于接收終端2發(fā)送的HTTP Post策略列表，HTTP Post策略列表為終端2接收業(yè)務(wù)的優(yōu)先級列表；策略判斷子模塊130，用于在 業(yè)務(wù)到來時(shí)，根據(jù)所述HTTP Post策略列表選擇優(yōu)先級最高的終端發(fā)送業(yè)務(wù) 消息。
其中，用戶標(biāo)識可以為任何識別用戶的標(biāo)識，例如SIP URI或TEL URL 侈'H口， SIPURI可以為sip:a@example.com.，或sip: 1234567890@example . com.。 TEL URI可以為tel: 1-123-456-7890。例如，私有用戶標(biāo)識可以為 usemame@example.com。通過上述本發(fā)明實(shí)施例能夠解決Push中多終端消息的接收問題，當(dāng)同 一個用戶存在多個終端時(shí)，會根據(jù)終端上報(bào)的訂閱請求，及訂閱請求攜帶的 終端請求信息選擇一個終端，在業(yè)務(wù)到來時(shí)只向該選擇的終端發(fā)送業(yè)務(wù)消 息，從而避免向用戶的所有終端都發(fā)送業(yè)務(wù)消息，這樣既能夠避免網(wǎng)絡(luò)資 源的浪費(fèi)和用戶的多個終端反復(fù)接收到相同消息的到來，還能夠避免因相同 消息的到來影響終端其他業(yè)務(wù)的正常接收。
通過以上的實(shí)施方式的描述，本領(lǐng)域的技術(shù)人員可以清楚地了解到本 發(fā)明可借助軟件加必需的通用硬件平臺的方式來實(shí)現(xiàn)，當(dāng)然也可以通過硬 件，但很多情況下前者是更佳的實(shí)施方式?；谶@樣的理解，本發(fā)明的技 術(shù)方案本質(zhì)上或者說對現(xiàn)有技術(shù)做出貢獻(xiàn)的部分可以以軟件產(chǎn)品的形式體 現(xiàn)出來，該計(jì)算機(jī)軟件產(chǎn)品存儲在一個存儲介質(zhì)中，包括若千指令用以使 得一臺計(jì)算機(jī)設(shè)備(可以是個人計(jì)算機(jī)，服務(wù)器，或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行 本發(fā)明各個實(shí)施例所述的方法。
以上所述僅是本發(fā)明的優(yōu)選實(shí)施方式，應(yīng)當(dāng)指出，對于本技術(shù)領(lǐng)域的 普通技術(shù)人員來說，在不脫離本發(fā)明原理的前提下，還可以做出若干改進(jìn)
和潤飾，這些改進(jìn)和潤飾也應(yīng)^L為本發(fā)明的保護(hù)范圍。
權(quán)利要求
1、一種多終端時(shí)業(yè)務(wù)消息處理方法，其特征在于，包括以下步驟接收終端發(fā)送的請求消息，所述請求消息攜帶有所述終端的請求信息；根據(jù)所述請求信息向所述終端發(fā)送業(yè)務(wù)消息。
2、 如權(quán)利要求1所述多終端時(shí)業(yè)務(wù)消息處理方法，其特征在于，所述 的請求消息包括訂閱請求消息和/或注冊請求消息。
3、 如權(quán)利要求1所述多終端時(shí)業(yè)務(wù)消息處理方法，其特征在于，所述請 求信息包括用戶標(biāo)識、Device ID和應(yīng)用標(biāo)識中的 一種或多種。
4、 如權(quán)利要求3所述多終端時(shí)業(yè)務(wù)消息處理方法，其特征在于，所述根 據(jù)請求信息向所述終端發(fā)送業(yè)務(wù)消息具體為根據(jù)所述請求信息用戶標(biāo)識和應(yīng)用標(biāo)識判斷所述終端申請的業(yè)務(wù)是否已 有相同用戶標(biāo)識的終端申請；如果沒有相同用戶標(biāo)識的終端申請，則向所述終端發(fā)送業(yè)務(wù)訂閱激活指 示，并在業(yè)務(wù)到來時(shí)向所述終端發(fā)送業(yè)務(wù)消息。
5、 如權(quán)利要求4所述多終端時(shí)業(yè)務(wù)消息處理方法，其特征在于，還包括 如果有相同用戶標(biāo)識的終端申請，則向所述終端發(fā)送提示消息，提示所述終端所述業(yè)務(wù)已經(jīng)被訂閱。
6、 如權(quán)利要求4所述多終端時(shí)業(yè)務(wù)消息處理方法，其特征在于，在所述 向終端發(fā)送業(yè)務(wù)訂閱激活指示之后，還包括向與所述終端有相同用戶標(biāo)識其他終端發(fā)送提示消息，提示其他終端。
7、 如權(quán)利要求3所述多終端時(shí)業(yè)務(wù)消息處理方法，其特征在于，所述請 求信息還包括優(yōu)先級，才艮據(jù)所述請求信息向所述終端發(fā)送業(yè)務(wù)消息具體為 向所述終端發(fā)送業(yè)務(wù)訂閱激活指示；在業(yè)務(wù)到來時(shí)，根據(jù)所述終端上報(bào)的相應(yīng)的優(yōu)先級判斷是否向所述終端 發(fā)送所述業(yè)務(wù)消息。
8、 如權(quán)利要求7所述多終端時(shí)業(yè)務(wù)消息處理方法，其特征在于，還包括: 優(yōu)先向上"f艮的所述業(yè)務(wù)優(yōu)先級最高的終端發(fā)送所述業(yè)務(wù)消息。
9、 如權(quán)利要求8所述多終端時(shí)業(yè)務(wù)消息處理方法，其特征在于，還包括 在向所述優(yōu)先級最高的終端發(fā)送失敗后，向優(yōu)先級次最高的終端發(fā)送所述業(yè)務(wù)消息。
10、 如權(quán)利要求7所述多終端時(shí)業(yè)務(wù)消息處理方法，其特征在于，還包括所述請求信息包括申請的多種業(yè)務(wù)和對應(yīng)的優(yōu)先級。
11、 如權(quán)利要求3所述多終端時(shí)業(yè)務(wù)消息處理方法，其特征在于，所述 根據(jù)請求信息向所述終端發(fā)送業(yè)務(wù)消息具體為向所述終端發(fā)送業(yè)務(wù)訂閱激活指示；在業(yè)務(wù)到來時(shí)，根據(jù)所述終端的Device ID及網(wǎng)絡(luò)側(cè)配置判斷所述終端 是否為最佳終端，只向所述最佳終端發(fā)送所述業(yè)務(wù)消息。
12、 如權(quán)利要求3所述多終端時(shí)業(yè)務(wù)消息處理方法，其特征在于，還包括所述終端向Push發(fā)送代理發(fā)送策略列表，所述策略列表為所述終端接收業(yè)務(wù)的優(yōu)先級列表；所述根據(jù)所述請求信息向所述終端發(fā)送業(yè)務(wù)消息具體為所述Push發(fā)送代理根據(jù)所述用戶標(biāo)識和應(yīng)用標(biāo)識及所述策略列表判斷是否向所述終端發(fā)送所述業(yè)務(wù)消息。
13、 如權(quán)利要求3所述多終端時(shí)業(yè)務(wù)消息處理方法，其特征在于，所 述Device ID為國際移動用戶標(biāo)識IMSI、私有用戶標(biāo)識Private User Identity、全局可路由用戶代理GRUU、多個聯(lián)系地址Multiple contact information, IPi也址、電"i舌號石馬或i殳備號。
14、 一種多終端時(shí)業(yè)務(wù)消息處理系統(tǒng)，其特征在于，包括Push發(fā)送代理 和至少兩個具有相同用戶標(biāo)識的終端，所述終端，用于向所述Push發(fā)送代理發(fā)送請求消息，所述請求消息攜 帶有所述終端的請求信息；所述Push發(fā)送代理，用于接收所述終端發(fā)送的請求消息，并才艮據(jù)所述 請求信息向所述終端發(fā)送業(yè)務(wù)消息。
15、 如權(quán)利要求14所述多終端時(shí)業(yè)務(wù)消息處理系統(tǒng)，其特征在于，所 述請求信息包括用戶標(biāo)識、Device ID、和應(yīng)用標(biāo)識中的一種或多種。
16、 一種Push發(fā)送代理，其特征在于，包括消息請求接收模塊和處理模塊，所述消息請求接收才莫塊，用于接收終端發(fā)送請求消息，所述請求消息攜 帶有所述終端的請求信息；所述處理模塊，用于在業(yè)務(wù)到來時(shí)，根據(jù)所述請求信息向所述終端發(fā)送 業(yè)務(wù)消息。
17、 如權(quán)利要求16所述Push發(fā)送代理，其特征在于，所述處理才莫塊包 括判斷子模塊、訂閱指示發(fā)送子模塊和業(yè)務(wù)消息發(fā)送子模塊，所述判斷子模塊，用于根據(jù)所述請求信息用戶標(biāo)識和應(yīng)用標(biāo)識判斷所述 終端申請的業(yè)務(wù)是否已有相同用戶標(biāo)識的終端申請；所述訂閱指示發(fā)送子模塊，用于在所述判斷子模塊判斷沒有相同用戶標(biāo) 識的終端申請時(shí)，向所述終端發(fā)送業(yè)務(wù)訂閱激活指示；所述業(yè)務(wù)消息發(fā)送子模塊，用于在業(yè)務(wù)到來時(shí)，向所述終端發(fā)送業(yè)務(wù)消臺
18、 如權(quán)利要求17所述Push發(fā)送代理，其特征在于，所述處理模塊還 包括提示響應(yīng)返回子模塊，用于在所述判斷子模塊判斷有相同用戶標(biāo)識的終 端申請時(shí)，向所述終端返回提示響應(yīng)，提示所述終端所述業(yè)務(wù)已經(jīng)被訂閱。
19、 如權(quán)利要求17所述Push發(fā)送代理，其特征在于，所述處理模塊還 包括提示消息發(fā)送子模塊，用于在所迷訂閱指示發(fā)送子模塊向所述終端發(fā)送 業(yè)務(wù)訂閱激活指示之后，向與所述終端有相同用戶標(biāo)識其他終端發(fā)送提示消 息，提示其他終端不要進(jìn)行再次訂閱。
20、 如權(quán)利要求16所述Push發(fā)送代理，其特征在于，所述處理一莫塊包 括優(yōu)先級判斷子模塊，用于根據(jù)所述終端上報(bào)的相應(yīng)的業(yè)務(wù)優(yōu)先級判斷是否 向所述終端發(fā)送所述業(yè)務(wù)消息，如果判斷發(fā)送則通知所述業(yè)務(wù)消息發(fā)送子 模塊向所述終端發(fā)送業(yè)務(wù)消息。
21、 如權(quán)利要求16所述Push發(fā)送代理，其特征在于，所述處理模塊包括網(wǎng)絡(luò)側(cè)配置保存子模塊和最佳終端判斷子模塊，所述網(wǎng)絡(luò)側(cè)配置保存子模塊，用于保存網(wǎng)絡(luò)側(cè)配置；所述最佳終端判斷子模塊，用于根據(jù)所述網(wǎng)絡(luò)側(cè)配置保存子模塊保存 的網(wǎng)絡(luò)側(cè)配置和所述終端的Device ID判斷所述終端是否為最佳終端，在判 斷所述終端為最佳終端時(shí)通知所述發(fā)送子模塊向所述終端發(fā)送業(yè)務(wù)消息。
22、如權(quán)利要求16所述Push發(fā)送代理，其特征在于，所述處理模塊包 括策略列表接收子模塊和策略判斷子模塊，所述策略列表接收子模塊，用于接收終端發(fā)送的策略列表，所述策略列 表為所述終端接收業(yè)務(wù)的優(yōu)先級列表；所述策略判斷子模塊，用于在業(yè)務(wù)到來時(shí)，根據(jù)所述策略列表選擇優(yōu)先 級最高的終端發(fā)送業(yè)務(wù)消息。
全文摘要
本發(fā)明公開了一種多終端時(shí)業(yè)務(wù)消息處理方法，包括以下步驟接收終端發(fā)送的請求消息，所述請求消息攜帶有所述終端的請求信息；根據(jù)所述請求信息向所述終端發(fā)送業(yè)務(wù)消息。當(dāng)同一個用戶存在多個終端時(shí)，Push發(fā)送代理會根據(jù)終端上報(bào)的訂閱請求及訂閱請求攜帶的終端請求信息選擇一個終端，在業(yè)務(wù)到來時(shí)只向該選擇的終端發(fā)送業(yè)務(wù)消息，從而避免向用戶的所有終端都發(fā)送業(yè)務(wù)消息。
文檔編號H04L12/18GK101437202SQ20071016942
公開日2009年5月20日 申請日期2007年11月13日 優(yōu)先權(quán)日2007年11月13日
發(fā)明者張惠萍, 健 楊, 浩 王, 雷 王, 范姝男, 挺 董, 陳國喬 申請人:華為技術(shù)有限公司