專利名稱：發(fā)送即時(shí)消息的方法和設(shè)備的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及即時(shí)消息業(yè)務(wù)，具體而言，涉及發(fā)送即時(shí)消息的方法和設(shè)備。
背景技術(shù)：
IP多媒體子系統(tǒng)(IMS，IP Multimedia Subsystem)是第三代合作伙伴計(jì)劃(3GPP)提出的提供IP多媒體業(yè)務(wù)的子系統(tǒng)，其主要網(wǎng)元包括呼叫會(huì)話控制功能實(shí)體(CSCF，Call Session ControlFunction)、支持業(yè)務(wù)提供的應(yīng)用服務(wù)器(AS，Appliation Server)等。消息(Messaging)業(yè)務(wù)是IMS所支持的一種業(yè)務(wù)類型，允許在IMS用戶之間發(fā)送和接收消息，消息的大小在技術(shù)上沒(méi)有限制。
Messaging業(yè)務(wù)提供的主要功能包括用戶可以通過(guò)消息應(yīng)用服務(wù)器(Messaging AS)發(fā)送多媒體即時(shí)消息以及通過(guò)Messaging AS接收其他用戶發(fā)來(lái)的多媒體即時(shí)消息，多媒體即時(shí)消息的內(nèi)容可以包括文本、圖像、音頻或視頻。
就Messaging業(yè)務(wù)而言，要實(shí)現(xiàn)在用戶之間發(fā)送、接收即時(shí)消息，其涉及到的設(shè)備包括用戶終端(UE，User Equipment)、網(wǎng)絡(luò)代理和Messaging AS等，其中網(wǎng)絡(luò)代理通常是指代理CSCF(P-CSCF，ProxyCSCF)、服務(wù)CSCF(S-CSCF，Serving CSCF)甚至查詢CSCF(I-CSCF，Interrogating CSCF)等功能實(shí)體，這些設(shè)備的組網(wǎng)示意圖在

圖1中示出。下面將進(jìn)行簡(jiǎn)要描述。
如圖1所示，UE首先連接到基站，然后通過(guò)分組數(shù)據(jù)服務(wù)節(jié)點(diǎn)(PDSN，Packet Data Serving Node)接入到IMS域。在IMS域，控制信令是通過(guò)會(huì)話初始協(xié)議(SIP，Session Initiation Protocol)傳送的，數(shù)據(jù)流可以通過(guò)SIP協(xié)議或消息會(huì)話中繼協(xié)議(MSRP，Message Session Relay Protocol)傳輸。P-CSCF為SIP信令的入口，負(fù)責(zé)與UE進(jìn)行交互。S-CSCF為控制服務(wù)器，負(fù)責(zé)觸發(fā)到具體的AS，例如Messaging AS，以及發(fā)送給接收方的S-CSCF。Messaging AS負(fù)責(zé)處理具體的消息，可以接收SIP和MSRP消息。
發(fā)送請(qǐng)求的流程大致如下當(dāng)UE想發(fā)送一個(gè)請(qǐng)求時(shí)，發(fā)送方UE通過(guò)基站及PDSN接入到IMS的P-CSCF。P-CSCF把請(qǐng)求轉(zhuǎn)發(fā)給S-CSCF，S-CSCF再把請(qǐng)求發(fā)送給Messaging AS。Messaging AS對(duì)請(qǐng)求處理完畢后，又把請(qǐng)求返回給S-CSCF。S-CSCF再把請(qǐng)求發(fā)給接收方所在域的S-CSCF。接收方S-CSCF也是先觸發(fā)給接收方的Messaging AS，收到處理完畢的請(qǐng)求后再發(fā)送給接收方UE。
Messaging AS的內(nèi)部結(jié)構(gòu)圖如圖2所示。其中，SIP協(xié)議適配器負(fù)責(zé)發(fā)送/接收SIP消息并上報(bào)給消息控制單元；msrp協(xié)議適配器負(fù)責(zé)接收/發(fā)送MSRP消息并上報(bào)給消息控制單元；和，消息控制單元負(fù)責(zé)消息的處理及保存。
就即時(shí)消息的接收而言，目前一般可通過(guò)兩種方式實(shí)現(xiàn)。
在其中一種方式中，服務(wù)器通過(guò)SIP MESSAGE把一條消息完整地發(fā)給UE，如圖3所示。具體信令流程為1.第1至2步，服務(wù)器發(fā)送SIP MESSAGE消息給UE，消息包含所有消息體；以及，2.第3至4步，UE返回接收消息應(yīng)答。
在另一種方式中，服務(wù)器通過(guò)SIP INVITE和MSRP SEND把一條消息完整地發(fā)給UE，如圖4所示。具體信令流程為1.第1至2步，服務(wù)器發(fā)送SIP INVITE給UE，請(qǐng)求與UE建立MSRP鏈接；2.第3至4步，UE返回應(yīng)答給服務(wù)器，返回與服務(wù)器建立MSRP鏈接的應(yīng)答；3.第5至6步，服務(wù)器返回確認(rèn)信息給UE；4.第7步，服務(wù)器與UE之間的MSRP鏈接建立好后，通過(guò)MSRPSEND發(fā)送消息體給UE；5.第8步，UE返回接收MSRP SEND消息的應(yīng)答；6.第9至10步，服務(wù)器發(fā)送SIP BYE給用戶，通知UE結(jié)束SIP會(huì)話及斷開(kāi)MSRP鏈接；以及，7.第11至12步，UE返回接收SIP BYE應(yīng)答。
需要說(shuō)明的是，為簡(jiǎn)化起見(jiàn)，在圖3和圖4中均未示出發(fā)送方的流程，并省略了基站、PDSN及P-CSCF等。
由于3G網(wǎng)絡(luò)的帶寬增加，而且可以與互聯(lián)網(wǎng)進(jìn)行消息互通，所以它能接收的消息大小在理論上是沒(méi)有限制的。相對(duì)而言，用戶終端，如手機(jī)，的容量就顯得較為有限，因而形成了瓶頸。此外，不同的用戶終端，如手機(jī)，容量差異很大。如果用戶A的手機(jī)容量大，用戶B的手機(jī)容量小，那么由用戶A發(fā)送給用戶B的即時(shí)消息的大小很可能超出用戶B的手機(jī)容量。在這種情況下，用戶B可能會(huì)由于手機(jī)容量限制而一直無(wú)法接收到來(lái)自用戶A的即時(shí)消息。這樣，即時(shí)消息經(jīng)過(guò)多個(gè)節(jié)點(diǎn)后，卻因?yàn)榻邮辗浇K端的容量有限而最終發(fā)送失敗，既影響了用戶的業(yè)務(wù)體驗(yàn)，又白白占用了網(wǎng)絡(luò)資源。

發(fā)明內(nèi)容
本發(fā)明的目的在于提供克服上述缺陷的即時(shí)消息發(fā)送方法和設(shè)備。
根據(jù)本發(fā)明的第一方面，提供一種服務(wù)器發(fā)送即時(shí)消息給終端的方法，所述即時(shí)消息包括至少一個(gè)消息體，所述終端具有消息接收閾值，該方法包括步驟將即時(shí)消息的大小與消息接收閾值比較；以及，在即時(shí)消息的大小比消息接收閾值大的情況下，通過(guò)將所述至少一個(gè)消息體中的至少一部分消息體的每一個(gè)分別替換為一個(gè)新消息體，改造即時(shí)消息使即時(shí)消息的大小不超過(guò)消息接收閾值，并分別存儲(chǔ)所述至少一部分消息體的內(nèi)容，每個(gè)所述新消息體包括對(duì)應(yīng)于原消息體的消息體標(biāo)識(shí)；和，發(fā)送改造后的即時(shí)消息給終端。
根據(jù)本發(fā)明的第二方面，提供一種服務(wù)器，用于發(fā)送即時(shí)消息給終端，所述服務(wù)器和所述終端通過(guò)網(wǎng)絡(luò)相連，所述即時(shí)消息包括至少一個(gè)消息體，所述終端具有消息接收閾值，該服務(wù)器包括將即時(shí)消息的大小與消息接收閾值比較的比較裝置；與比較裝置相連的改造裝置，在即時(shí)消息的大小比消息接收閾值大的情況下、通過(guò)將所述至少一個(gè)消息體中的至少一部分消息體的每一個(gè)分別替換為一個(gè)新消息體改造即時(shí)消息使即時(shí)消息的大小不超過(guò)消息接收閾值，每個(gè)所述新消息體包括對(duì)應(yīng)于原消息體的消息體標(biāo)識(shí)；與改造裝置相連的消息存儲(chǔ)單元，用于存儲(chǔ)所述至少一部分消息體的內(nèi)容；和，與改造裝置相連的、發(fā)送改造后的即時(shí)消息給終端的裝置。
根據(jù)本發(fā)明的第三方面，提供一種即時(shí)消息發(fā)送系統(tǒng)，包括終端和如第二方面所述的服務(wù)器。
利用本發(fā)明，終端用戶可以根據(jù)接收到的即時(shí)消息了解到該消息總共包括哪些消息體、分別對(duì)應(yīng)于這些消息體中至少一部分消息體的每一個(gè)的替換消息體、以及有時(shí)可能會(huì)有的其余一部分消息體的完整內(nèi)容。對(duì)于那些由替換消息體代替的消息體，終端用戶不能直接獲取其具體內(nèi)容。當(dāng)終端用戶希望獲取其中某個(gè)消息體的具體內(nèi)容時(shí)，可通過(guò)UE發(fā)送攜帶對(duì)應(yīng)于該消息體的消息體標(biāo)識(shí)的請(qǐng)求給服務(wù)器來(lái)獲取。若消息體的大小超出UE的容量，終端用戶可通過(guò)訪問(wèn)服務(wù)器網(wǎng)頁(yè)、并輸入對(duì)應(yīng)于該消息體的消息體標(biāo)識(shí)來(lái)獲取消息體。當(dāng)用戶看完某個(gè)消息體的內(nèi)容后，可以在UE上面單獨(dú)刪除該消息體的內(nèi)容。
這樣，用戶可以選擇性地獲取消息體的內(nèi)容，加強(qiáng)了用戶的業(yè)務(wù)體驗(yàn)，增強(qiáng)了Messaging AS的可服務(wù)性，能更好地適應(yīng)用戶需求。對(duì)運(yùn)營(yíng)商而言，減少了消息發(fā)送失敗的可能性，提高了網(wǎng)絡(luò)資源的利用率。此外，通過(guò)利用本發(fā)明，容量較小的UE可以分多次接收超過(guò)其容量的即時(shí)消息，減小了UE的容量對(duì)即時(shí)消息大小的限制。
附圖簡(jiǎn)述下面將結(jié)合附圖詳細(xì)描述本發(fā)明，其中圖1示出了現(xiàn)有技術(shù)的一種提供Messaging業(yè)務(wù)的典型組網(wǎng)圖；圖2示出了圖1中Messaging AS的內(nèi)部結(jié)構(gòu)示意圖；圖3示出了現(xiàn)有技術(shù)的利用SIP MESSAGE請(qǐng)求完整地發(fā)送即時(shí)消息給終端的信令流程；圖4示出了現(xiàn)有技術(shù)的利用SIP INVITE和MRSP SEND請(qǐng)求完整地發(fā)送即時(shí)消息給終端的信令流程；圖5是一個(gè)即時(shí)消息的結(jié)構(gòu)示意圖；圖6是根據(jù)本發(fā)明的一個(gè)實(shí)施方案將圖5中的即時(shí)消息所包含的消息體分別用一個(gè)新消息體替換后得到的即時(shí)消息的結(jié)構(gòu)示意圖；圖7示出了根據(jù)本發(fā)明的一個(gè)實(shí)施方案的、利用SIP MESSAGE和XML配置訪問(wèn)協(xié)議(XCAP，XML Configuration Access Protocol)請(qǐng)求發(fā)送即時(shí)消息并提供消息體內(nèi)容給終端的信令流程；圖8示出了根據(jù)本發(fā)明的另一個(gè)實(shí)施方案的、利用SIP INVITE、MSRP SEND及XCAP請(qǐng)求發(fā)送即時(shí)消息并提供消息體內(nèi)容給終端的信令流程；圖9示出了根據(jù)本發(fā)明的一個(gè)實(shí)施方案的、通過(guò)瀏覽器訪問(wèn)服務(wù)器網(wǎng)頁(yè)獲取消息體的信令流程；圖10示出了用于本發(fā)明的一個(gè)實(shí)施方案的、提供Messaging業(yè)務(wù)的組網(wǎng)示意圖；圖11示出了圖10中的Messaging AS的內(nèi)部結(jié)構(gòu)示意圖；圖12是一個(gè)實(shí)際即時(shí)消息的示例；以及，圖13是根據(jù)本發(fā)明的一個(gè)實(shí)施方案將圖12中的即時(shí)消息所包含的消息體分別用一個(gè)新消息體替換后得到的即時(shí)消息。
具體實(shí)施例方式
本發(fā)明的方案是以終端為IMS Messaging業(yè)務(wù)用戶為前提提出的。
服務(wù)器接收到來(lái)自發(fā)送方的即時(shí)消息后，首先將即時(shí)消息與終端的消息接收閾值進(jìn)行比較。其中，來(lái)自發(fā)送方的即時(shí)消息可以具有一個(gè)或多個(gè)消息體，它們可以MIME格式的形式存在。每個(gè)消息體的類型可以是文本、圖像、音頻或視頻等。終端的消息接收閾值可在用戶開(kāi)通Messaging業(yè)務(wù)時(shí)由Messaging AS(以下簡(jiǎn)稱服務(wù)器)默認(rèn)設(shè)置或由用戶自定義設(shè)置，并存儲(chǔ)在服務(wù)器中。優(yōu)選地，終端的消息接收閾值等于終端能接收的最大接收消息大小。
對(duì)于大小未超過(guò)消息接收閾值的即時(shí)消息，服務(wù)器以現(xiàn)有技術(shù)的方式發(fā)送即時(shí)消息。如前所述，一種方式是服務(wù)器通過(guò)SIP MESSAGE把一條消息完整地發(fā)給用戶，如圖3所示。另一種方式是服務(wù)器通過(guò)SIP INVITE和MSRP SEND把一條消息完整地發(fā)給用戶，如圖4所示。
對(duì)于大小超過(guò)消息接收閾值的即時(shí)消息，服務(wù)器將對(duì)即時(shí)消息進(jìn)行改造將即時(shí)消息所包含的消息體中的至少一部分消息體的每一個(gè)分別替換為一個(gè)新消息體以使即時(shí)消息的大小不超過(guò)消息接收閾值，將所述至少一部分消息體的每一個(gè)的內(nèi)容分別拆分出來(lái)并存儲(chǔ)到例如服務(wù)器的消息存儲(chǔ)單元中。
至于是對(duì)即時(shí)消息的全部消息體進(jìn)行拆分還是僅對(duì)一部分消息體進(jìn)行拆分，可由用戶預(yù)先設(shè)置。當(dāng)用戶設(shè)置為全部拆分時(shí)，把即時(shí)消息的全部消息體的內(nèi)容分別拆分出來(lái)。當(dāng)用戶設(shè)置為部分拆分時(shí)，優(yōu)選地基于一定的優(yōu)先級(jí)順序?qū)磿r(shí)消息進(jìn)行改造，例如，先拆分出并用一個(gè)新消息體替換優(yōu)先級(jí)最高的消息體、再拆分出并用另一個(gè)新消息體替換優(yōu)先級(jí)次高的消息體、依此進(jìn)行直至即時(shí)消息的大小減至小于或等于消息接收閾值。在一個(gè)實(shí)施方案中，服務(wù)器根據(jù)不同消息體類型，即文本、聲音、圖像或視頻，賦予不同消息體不同的優(yōu)先級(jí)。例如，消息體的優(yōu)先級(jí)從高到低依次為文本、聲音、圖像、視頻。在該實(shí)施方案的一個(gè)特定實(shí)施例中，對(duì)于類型相同的消息體，根據(jù)消息體大小確定優(yōu)先級(jí)順序，例如，賦予較大的消息體較高的優(yōu)先級(jí)，賦予較小的消息體較低的優(yōu)先級(jí)。在另一實(shí)施方案中，服務(wù)器根據(jù)不同消息體大小賦予不同消息體不同的優(yōu)先級(jí)。例如，賦予最大的消息體最高的優(yōu)先級(jí)，賦予次大的消息體次高的優(yōu)先級(jí)，依此進(jìn)行。在該實(shí)施方案的一個(gè)特定實(shí)施例中，對(duì)于大小相同的消息體，根據(jù)消息體類型確定優(yōu)先級(jí)順序，例如，消息體的優(yōu)先級(jí)從高到低依次為文本、聲音、圖像、視頻。
可替換地，即時(shí)消息中消息體的拆分方式也可由服務(wù)器默認(rèn)設(shè)置。
根據(jù)本發(fā)明，每個(gè)被拆分出的消息體(原消息體)對(duì)應(yīng)于一個(gè)用于替換該消息體的新消息體，該新消息體可以是XML格式的，其包括對(duì)應(yīng)于原消息體的消息體標(biāo)識(shí)。優(yōu)選地，該新消息體還包括原消息體的描述信息(在此意義上，為敘述方便，在下文中新消息體也被稱為描述信息消息體)。優(yōu)選地，所述描述信息可包括消息體名字和/或消息體大小。例如，原消息體的格式為消息體類型原消息體的類型說(shuō)明信息消息體內(nèi)容原消息體的具體內(nèi)容對(duì)應(yīng)的描述信息消息體格式可為消息體類型擴(kuò)展類型說(shuō)明信息消息體內(nèi)容描述信息消息體的內(nèi)容在一個(gè)實(shí)施例中，“擴(kuò)展類型說(shuō)明信息”為固定值“application/bodydescMsg+xml”，“描述信息消息體的內(nèi)容”為< xml version="1.0" >
<item>
<name>消息體名字</name>
<size>消息體大小</size>
<ID>消息體ID</ID>
</item>
其中的“消息體名字”可取自原消息體中的名字字段，例如，我的全家福.jpg、我的留言.wav等等；如果原消息體中沒(méi)有名字，則服務(wù)器自動(dòng)生成一個(gè)名字，例如未知文件1、未知文件2等等，作為“消息體名字”?！跋Ⅲw大小”可根據(jù)原消息體的大小計(jì)算得到?！跋ⅢwID”可在服務(wù)器存儲(chǔ)拆分出來(lái)的、原消息體的內(nèi)容時(shí)由服務(wù)器生成，通過(guò)這個(gè)ID服務(wù)器可以唯一確定原消息體。
根據(jù)本發(fā)明，將即時(shí)消息所包含的消息體中的至少一部分消息體的每一個(gè)分別替換為一個(gè)描述信息消息體，圖5和圖6一般性地示出了這一過(guò)程。應(yīng)該指出的是，圖6中的“消息體1的描述信息”、…、“消息體4的描述信息”包括了對(duì)應(yīng)于相應(yīng)原消息體的消息體標(biāo)識(shí)。
對(duì)即時(shí)消息進(jìn)行改造后，服務(wù)器將改造后得到的新即時(shí)消息發(fā)送給終端。這可通過(guò)SIP MESSAGE或者通過(guò)SIP INVITE和MSRP SEND來(lái)實(shí)現(xiàn)。
該新即時(shí)消息有兩種可能情形。一種情形是，該消息中的所有消息體都被替換成了描述信息消息體；另一種情形是該消息中的一部分消息體被替換成了描述信息消息體，另一部分消息體未被替換因而可直接獲得其具體內(nèi)容。無(wú)論是哪種情形，終端接收到該新即時(shí)消息后，對(duì)于那些被替換為描述信息消息體的消息體，終端用戶不能直接獲取其具體內(nèi)容。當(dāng)用戶希望獲取其中某個(gè)消息體的具體內(nèi)容時(shí)，可通過(guò)UE例如手機(jī)發(fā)送攜帶對(duì)應(yīng)于該消息體的消息體標(biāo)識(shí)的XCAP請(qǐng)求給服務(wù)器來(lái)獲取。一般來(lái)說(shuō)，描述信息消息體包括消息體名字和/或消息體大小。在這種情況下，終端用戶優(yōu)選地根據(jù)該消息體名字和/或消息體大小確定希望獲取的消息體。
圖7示出了根據(jù)本發(fā)明的一個(gè)實(shí)施方案的、利用SIP MESSAGE和XCAP請(qǐng)求發(fā)送即時(shí)消息并提供消息體內(nèi)容給終端的信令流程，具體如下1.第1至2步，服務(wù)器發(fā)送SIP MESSAGE消息給UE，其中至少一部分消息體的每一個(gè)分別被替換為一個(gè)XML格式的描述信息消息體；2.第3至4步，UE返回接收消息應(yīng)答；3.第5步，UE發(fā)出獲取一個(gè)消息體的XCAP請(qǐng)求，該XCAP請(qǐng)求包括對(duì)應(yīng)于該消息體的消息體標(biāo)識(shí)；以及，
4.第6步，服務(wù)器返回該消息體的內(nèi)容給終端。
根據(jù)具體情況，第5至6步可重復(fù)多次。
圖8示出了根據(jù)本發(fā)明的另一個(gè)實(shí)施方案的、利用SIP INVITE、MSRP SEND及XCAP請(qǐng)求發(fā)送即時(shí)消息并提供消息體內(nèi)容給終端的信令流程，具體如下1.第1至2步，服務(wù)器發(fā)送SIP INVITE給UE，請(qǐng)求與UE建立MSRP鏈接；2.第3至4步，UE返回應(yīng)答給服務(wù)器，返回與服務(wù)器建立MSRP鏈接的應(yīng)答；3.第5至6步，服務(wù)器返回確認(rèn)信息給UE；4.第7步，服務(wù)器與UE之間的MSRP鏈接建立好后，通過(guò)MSRP SEND發(fā)送消息體給UE；5.第8步，UE返回接收MSRP SEND消息的應(yīng)答；6.第9至10步，服務(wù)器發(fā)送SIP BYE給用戶，通知UE結(jié)束SIP會(huì)話及斷開(kāi)MSRP鏈接；7.第11至12步，UE返回接收SIP BYE應(yīng)答；8.第13步，UE發(fā)出獲取一個(gè)消息體的XCAP請(qǐng)求，該XCAP請(qǐng)求包括對(duì)應(yīng)于該消息體的消息體標(biāo)識(shí)；以及，9.第14步，服務(wù)器返回該消息體的內(nèi)容給終端。
根據(jù)具體情況，第13至14步可重復(fù)多次。
若要獲取的消息體的大小超出了UE的容量，終端用戶可通過(guò)HTTP協(xié)議登入服務(wù)器PROTAL來(lái)獲取，圖9對(duì)該過(guò)程進(jìn)行了圖解。用PC機(jī)中的瀏覽器訪問(wèn)服務(wù)器網(wǎng)址從而進(jìn)入服務(wù)器首頁(yè)；輸入用戶名、密碼等進(jìn)入用戶界面頁(yè)；輸入對(duì)應(yīng)于該消息體的消息體標(biāo)識(shí)獲取消息體。
當(dāng)用戶看完某個(gè)消息體的內(nèi)容后，可以在UE上面單獨(dú)刪除該消息體的內(nèi)容。
用于本發(fā)明的用戶終端可以是手機(jī)、PC機(jī)或具有通信功能的其它電子設(shè)備。
圖10示出了用于本發(fā)明的一個(gè)實(shí)施方案的、提供Messaging業(yè)務(wù)的組網(wǎng)示意圖，其中UE可通過(guò)發(fā)送XCAP請(qǐng)求與Messaging AS進(jìn)行交互。因而，相比圖1中示出的現(xiàn)有技術(shù)的組網(wǎng)圖，圖10中的Messaging AS應(yīng)能處理XCAP請(qǐng)求。圖11示出了圖10中Messaging AS的內(nèi)部結(jié)構(gòu)示意圖?？砂l(fā)現(xiàn)，相對(duì)圖2所示的現(xiàn)有技術(shù)的MessagingAS而言，本發(fā)明的Messaging AS添加了消息存儲(chǔ)單元、XCAP協(xié)議適配器及用戶PORTAL。其中，消息存儲(chǔ)單元負(fù)責(zé)存儲(chǔ)拆分出來(lái)的消息體，XCAP協(xié)議適配器及用戶PORTAL負(fù)責(zé)到消息存儲(chǔ)單元獲取消息體供提供給終端。
最后，給出根據(jù)本發(fā)明的一個(gè)實(shí)施方案發(fā)送即時(shí)消息的具體例子，以便更直觀地了解本發(fā)明。用戶A發(fā)送一條具有多個(gè)消息體的即時(shí)消息給用戶B，假定該即時(shí)消息的大小大于用戶B的終端最大接收消息大小。用戶A發(fā)送的即時(shí)消息如圖12所示(為簡(jiǎn)化，與本發(fā)明的方案無(wú)關(guān)的消息頭部簡(jiǎn)略示出)。服務(wù)器利用本發(fā)明的一個(gè)實(shí)施方案發(fā)送給用戶B的消息如圖13所示。如果用戶B希望獲取某個(gè)特定消息體，可發(fā)出如下請(qǐng)求GEThttp://ap.huawei.com/services/fetchMsgBody/users/sip:user1@huawei.com/Messaging/～～/Messaging/message[@ID=“MsgBody32fa84b447fU2”]HTTP/1.1Host:ap.huawei.com相應(yīng)地，服務(wù)器返回的應(yīng)答的例子如下(忽略部分與本發(fā)明的方案無(wú)關(guān)的頭字段)HTTP/1.1 200 OKContent-Type:Application/XMLContent-Length:342< xml version=”1.0” >
<MsgBody MsgID=”MsgBody32fa84b447fU2”>
<Content-Type>
audio/x-wav</Content-Type>
<Content-Transfer-Encoding>
base64</Content-Transfer-Encoding>
<Content-Disposition filename="body3.wav">
attachment</Content-Disposition>
<body>
Uk1GR1ScAgBXQVZFZm10IBAAAAABAAIAI1YAAIhYAQAEApHjP4VhDQf1Acr8tfwMoGhYa6fV</body>
</MsgBody>
盡管上面描述了本發(fā)明的實(shí)施方式，但顯然所述實(shí)施方式可以多種方式進(jìn)行改變。例如，拆分出來(lái)的消息體的內(nèi)容可存儲(chǔ)在不同于服務(wù)器的裝置中，描述信息消息體可以不是XML格式的，用戶可通過(guò)除XCAP以外的其他協(xié)議從服務(wù)器獲取特定消息體的內(nèi)容等。因而，本發(fā)明的范圍不應(yīng)該由示例實(shí)施方案確定，而應(yīng)該由那些會(huì)被允許的權(quán)利要求及它們的法定等同物確定。
權(quán)利要求
1.服務(wù)器發(fā)送即時(shí)消息給終端的方法，所述即時(shí)消息包括至少一個(gè)消息體，所述終端具有消息接收閾值，該方法包括步驟a.將即時(shí)消息的大小與消息接收閾值比較；以及，在即時(shí)消息的大小比消息接收閾值大的情況下，b.通過(guò)將所述至少一個(gè)消息體中的至少一部分消息體的每一個(gè)分別替換為一個(gè)新消息體，改造即時(shí)消息使即時(shí)消息的大小不超過(guò)消息接收閾值，分別存儲(chǔ)所述至少一部分消息體的內(nèi)容，每個(gè)所述新消息體包括對(duì)應(yīng)于原消息體的消息體標(biāo)識(shí)；c.發(fā)送改造后的即時(shí)消息給終端。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括在接收到來(lái)自終端的消息體標(biāo)識(shí)時(shí)，將與所述消息體標(biāo)識(shí)對(duì)應(yīng)的原消息體的內(nèi)容發(fā)送給終端的步驟。
3.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述消息體標(biāo)識(shí)是通過(guò)XCAP請(qǐng)求發(fā)送的。
4.根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括當(dāng)終端用戶訪問(wèn)服務(wù)器網(wǎng)頁(yè)并且輸入消息體標(biāo)識(shí)時(shí)，將與所述消息體標(biāo)識(shí)對(duì)應(yīng)的原消息體的內(nèi)容提供給終端的步驟。
5.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述步驟c是通過(guò)SIP MESSAGE或通過(guò)SIP INVITE和MSRP SEND實(shí)現(xiàn)的。
6.根據(jù)權(quán)利要求1所述的方法，其特征在于，包括根據(jù)不同消息體類型賦予不同消息體不同的優(yōu)先級(jí)的步驟，并且所述步驟b的所述改造基于消息體的優(yōu)先級(jí)進(jìn)行。
7.根據(jù)權(quán)利要求6所述的方法，其特征在于，所述消息體類型包括文本、圖像、音頻和視頻中的一個(gè)或多個(gè)。
8.根據(jù)權(quán)利要求1所述的方法，其特征在于，包括根據(jù)不同消息體大小賦予不同消息體不同的優(yōu)先級(jí)的步驟，并且所述步驟b的所述改造基于消息體的優(yōu)先級(jí)進(jìn)行。
9.根據(jù)權(quán)利要求1所述的方法，其特征在于，每個(gè)所述新消息體還包括原消息體的描述信息。
10.根據(jù)權(quán)利要求9所述的方法，其特征在于，所述描述信息包括消息體名字和/或消息體大小。
11.一種服務(wù)器，用于發(fā)送即時(shí)消息給終端，所述服務(wù)器和所述終端通過(guò)網(wǎng)絡(luò)相連，所述即時(shí)消息包括至少一個(gè)消息體，所述終端具有消息接收閾值，該服務(wù)器包括將即時(shí)消息的大小與消息接收閾值比較的比較裝置；與比較裝置相連的改造裝置，在即時(shí)消息的大小比消息接收閾值大的情況下、通過(guò)將所述至少一個(gè)消息體中的至少一部分消息體的每一個(gè)分別替換為一個(gè)新消息體改造即時(shí)消息使即時(shí)消息的大小不超過(guò)消息接收閾值，每個(gè)所述新消息體包括對(duì)應(yīng)于原消息體的消息體標(biāo)識(shí)；與改造裝置相連的消息存儲(chǔ)單元，用于存儲(chǔ)所述至少一部分消息體的內(nèi)容；和，與改造裝置相連的、發(fā)送改造后的即時(shí)消息給終端的裝置。
12.根據(jù)權(quán)利要求11所述的服務(wù)器，其特征在于，還包括與消息存儲(chǔ)單元相連的、在接收到來(lái)自終端的消息體標(biāo)識(shí)時(shí)將與所述消息體標(biāo)識(shí)對(duì)應(yīng)的原消息體的內(nèi)容發(fā)送給終端的裝置。
13.根據(jù)權(quán)利要求12所述的服務(wù)器，其特征在于，所述消息體標(biāo)識(shí)是通過(guò)XCAP請(qǐng)求發(fā)送的。
14.根據(jù)權(quán)利要求11所述的服務(wù)器，其特征在于，還包括與消息存儲(chǔ)單元相連的、當(dāng)終端用戶訪問(wèn)服務(wù)器網(wǎng)頁(yè)并且輸入消息體標(biāo)識(shí)時(shí)將與所述消息體標(biāo)識(shí)對(duì)應(yīng)的原消息體的內(nèi)容提供給終端的裝置。
15.根據(jù)權(quán)利要求11所述的服務(wù)器，其特征在于，所述發(fā)送改造后的即時(shí)消息給終端的裝置通過(guò)SIP MESSAGE或通過(guò)SIP INVITE和MSRP SEND發(fā)送。
16.根據(jù)權(quán)利要求11所述的服務(wù)器，其特征在于，所述改造裝置根據(jù)不同消息體類型賦予不同消息體不同的優(yōu)先級(jí)，并基于消息體的優(yōu)先級(jí)改造即時(shí)消息。
17.根據(jù)權(quán)利要求16所述的服務(wù)器，其特征在于，所述消息體類型包括文本、圖像、音頻和視頻中的一個(gè)或多個(gè)。
18.根據(jù)權(quán)利要求11所述的服務(wù)器，其特征在于，所述改造裝置根據(jù)不同消息體大小賦予不同消息體不同的優(yōu)先級(jí)，并基于消息體的優(yōu)先級(jí)改造即時(shí)消息。
19.根據(jù)權(quán)利要求11所述的服務(wù)器，其特征在于，每個(gè)所述新消息體還包括原消息體的描述信息。
20.根據(jù)權(quán)利要求19所述的服務(wù)器，其特征在于，所述描述信息包括消息體名字和/或消息體大小。
21.一種即時(shí)消息發(fā)送系統(tǒng)，包括終端和根據(jù)權(quán)利要求11-20中任一權(quán)利要求所述的服務(wù)器。
22.根據(jù)權(quán)利要求21所述的系統(tǒng)，其特征在于，所述終端是手機(jī)或PC機(jī)。
全文摘要
提供了一種服務(wù)器發(fā)送即時(shí)消息給終端的方法，所述即時(shí)消息包括至少一個(gè)消息體，所述終端具有消息接收閾值，該方法包括將即時(shí)消息的大小與消息接收閾值比較；以及，在即時(shí)消息的大小比消息接收閾值大的情況下，通過(guò)將所述至少一個(gè)消息體中的至少一部分消息體的每一個(gè)分別替換為一個(gè)新消息體，改造即時(shí)消息使即時(shí)消息的大小不超過(guò)消息接收閾值，并分別存儲(chǔ)所述至少一部分消息體的內(nèi)容，每個(gè)所述新消息體包括對(duì)應(yīng)于原消息體的消息體標(biāo)識(shí)；和，發(fā)送改造后的即時(shí)消息給終端。終端用戶接收到即時(shí)消息后，可以選擇性地通過(guò)消息體標(biāo)識(shí)獲取原消息體的內(nèi)容。利用本發(fā)明，可加強(qiáng)用戶的業(yè)務(wù)體驗(yàn)，提高網(wǎng)絡(luò)資源的利用率，減小終端容量對(duì)即時(shí)消息大小的限制。
文檔編號(hào)H04L29/06GK1859321SQ20051012086
公開(kāi)日2006年11月8日 申請(qǐng)日期2005年12月15日 優(yōu)先權(quán)日2005年12月15日
發(fā)明者王林 申請(qǐng)人:華為技術(shù)有限公司