專(zhuān)利名稱(chēng)：用于發(fā)送消息的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種用于在通信網(wǎng)絡(luò)中發(fā)送消息的方法。
背景技術(shù)：
第三代合作組織項(xiàng)目(3GPP)目前討論了在通信網(wǎng)絡(luò)中作為一個(gè)網(wǎng)絡(luò)單元的多媒體消息業(yè)務(wù)中心(MMSC)的問(wèn)題，例如，在通用分組無(wú)線(xiàn)電系統(tǒng)(GPRS)和通用移動(dòng)通信系統(tǒng)(UMTS)中的使用。遺憾的是，大部分問(wèn)題仍不確定，如終端能力和用戶(hù)簡(jiǎn)表的管理。
從技術(shù)的觀(guān)點(diǎn)來(lái)看，多媒體消息業(yè)務(wù)中心的功能提供了一種部分工作于存儲(chǔ)和轉(zhuǎn)發(fā)模式的非實(shí)時(shí)業(yè)務(wù)。另外，多媒體消息利用例如GPRS空中接口發(fā)送，而且消息的內(nèi)容可以是文本、圖像、語(yǔ)音、視頻片段等，或上述內(nèi)容的任意組合。例如，利用這種多媒體消息業(yè)務(wù)這些內(nèi)容可以從一個(gè)移動(dòng)臺(tái)發(fā)送到另一移動(dòng)臺(tái)。
根據(jù)多媒體消息的業(yè)務(wù)描述，消息的內(nèi)容和長(zhǎng)度在理論上不受限制。然而，由于存在各種不同類(lèi)型的終端(例如，移動(dòng)臺(tái))，網(wǎng)絡(luò)中出現(xiàn)了這些終端的多種不同能力。因此，每個(gè)這些終端不可避免地造成其特定的限制和制約，尤其是在處理多媒體消息的能力上。
例如，可用的存儲(chǔ)容量受限，而且不同終端之間存在差異，因此，不是所有的終端都能接收所有可能的內(nèi)容。此外，單個(gè)終端的能力也可能動(dòng)態(tài)變化，例如，如果終端已經(jīng)接收和存儲(chǔ)了一條消息，那么剩余的存儲(chǔ)空間將減小。類(lèi)似地，終端可以與類(lèi)似膝上型計(jì)算機(jī)等的其他設(shè)備連接或斷開(kāi)。
此外，除了由終端能力造成的制約外，用戶(hù)可能希望創(chuàng)建或修正其自身的用戶(hù)簡(jiǎn)表，從而也將導(dǎo)致特別的限制。例如，用戶(hù)可能希望使某些類(lèi)型的多媒體消息存儲(chǔ)于多媒體消息業(yè)務(wù)中心，轉(zhuǎn)發(fā)到一個(gè)因特網(wǎng)地址或被丟棄。這些用戶(hù)定義的限制可基于例如，多媒體消息的大小、內(nèi)容-類(lèi)型或發(fā)送人。
從前述可以看出，這將出現(xiàn)新的問(wèn)題，即，由于缺乏接收、存儲(chǔ)、處理或顯示多媒體消息的能力，某些部分的多媒體消息或甚至整個(gè)消息將不受接收終端的控制。由此，不受控地發(fā)送多媒體消息將造成終端出現(xiàn)嚴(yán)重的問(wèn)題直至系統(tǒng)故障，這可能導(dǎo)致至少部分喪失終端功能，從而中斷通信。

發(fā)明內(nèi)容
因此，本發(fā)明的一個(gè)目的是，提供一種用于在包括至少一個(gè)終端和一個(gè)消息發(fā)送功能的通信網(wǎng)絡(luò)中發(fā)送消息的方法，而且該方法沒(méi)有上述缺陷。
根據(jù)本發(fā)明，這個(gè)目的是通過(guò)一種用于在包括至少一個(gè)終端和一種消息發(fā)送功能的通信網(wǎng)絡(luò)中發(fā)送消息的方法實(shí)現(xiàn)的，所述方法包括步驟一旦出現(xiàn)一個(gè)預(yù)定條件，就從所述終端提交涉及該終端能力和當(dāng)前用戶(hù)簡(jiǎn)表的信息到所述消息發(fā)送功能；所述消息發(fā)送功能根據(jù)所述信息確定如何為所述終端處理所述消息發(fā)送功能接收的消息；以及所述消息發(fā)送功能根據(jù)所述確定步驟的結(jié)果處理所述消息。
此外，該目的是通過(guò)一種用于在包括至少一個(gè)終端和一個(gè)消息發(fā)送功能的通信網(wǎng)絡(luò)中發(fā)送消息的方法實(shí)現(xiàn)的，所述方法包括步驟所述消息發(fā)送功能為所述終端接收消息；從所述消息發(fā)送功能發(fā)送一個(gè)關(guān)于出現(xiàn)所述消息的通知到所述終端；所述終端根據(jù)其能力和當(dāng)前用戶(hù)簡(jiǎn)表確定如何處理所述接收消息；所述終端應(yīng)答所述消息發(fā)送功能發(fā)送的通知，同時(shí)根據(jù)所述確定步驟的結(jié)果下達(dá)指令；以及所述消息發(fā)送功能根據(jù)所述指令處理所述消息。
此外，本發(fā)明提出了一種消息發(fā)送功能設(shè)備，包括用于接收消息和信息的接收裝置；用于處理接收的信息數(shù)據(jù)和消息的處理裝置；存儲(chǔ)裝置；用于分別發(fā)送信息和消息到所述終端的發(fā)送裝置。
另外，本發(fā)明還還提出了一種終端設(shè)備，包括用于接收消息和信息的接收裝置；用于處理接收的信息數(shù)據(jù)和消息的處理裝置；存儲(chǔ)裝置；用于分別發(fā)送信息和消息到所述終端的發(fā)送裝置。
對(duì)本發(fā)明的進(jìn)一步改進(jìn)在相應(yīng)的所附權(quán)利要求書(shū)中陳述。
因此，本發(fā)明的一個(gè)優(yōu)點(diǎn)在于，對(duì)消息的處理是基于接收終端的能力和對(duì)應(yīng)用戶(hù)的用戶(hù)簡(jiǎn)表。因此，能相應(yīng)地處理每條消息和這條消息的每部分?？傊?，不再可能出現(xiàn)終端故障或者功能喪失，而且根據(jù)本發(fā)明的方法還為用戶(hù)靈活和自由地加入網(wǎng)絡(luò)提供了更大的余地。


下面通過(guò)參考附圖舉例詳細(xì)描述本發(fā)明的優(yōu)選實(shí)施例。
圖1示出了根據(jù)本發(fā)明的第一實(shí)施例，在多媒體消息業(yè)務(wù)中心和接收終端之間發(fā)送多媒體消息的基本信令序列的原理圖；圖2示出了根據(jù)本發(fā)明的第二個(gè)實(shí)施例，在多媒體消息業(yè)務(wù)中心接收到一個(gè)新的移動(dòng)臺(tái)終接的多媒體消息后，實(shí)現(xiàn)的一個(gè)功能例子的流程圖；以及圖3示出了根據(jù)本發(fā)明的第二個(gè)實(shí)施例，在終端接收到MMSNotify消息后，實(shí)現(xiàn)的一個(gè)功能例子的另一流程圖。
具體實(shí)現(xiàn)方式根據(jù)本發(fā)明，根據(jù)類(lèi)似移動(dòng)臺(tái)的接收終端的能力和用戶(hù)簡(jiǎn)表，處理多媒體消息的提交作為在通信網(wǎng)絡(luò)中發(fā)送的一種消息例子。如何處理該提交的決定基于多媒體消息的內(nèi)容、大小和類(lèi)型，終端的能力以及與所述終端相關(guān)的用戶(hù)的用戶(hù)簡(jiǎn)表被相應(yīng)的判決裝置獲得的情況。
對(duì)要發(fā)送的這些消息的處理將在該通信網(wǎng)絡(luò)的另一元素，即實(shí)現(xiàn)消息發(fā)送功能的網(wǎng)絡(luò)設(shè)備中執(zhí)行。在下面對(duì)本發(fā)明的優(yōu)選實(shí)施例的描述中，將通過(guò)參考該多媒體消息服務(wù)中心的例子作為實(shí)現(xiàn)消息發(fā)送功能的這種網(wǎng)絡(luò)設(shè)備，以及通過(guò)參考多媒體消息的例子作為發(fā)送消息來(lái)描述。然而，應(yīng)注意，這些例子決不是限制。即，單一媒體消息也可以發(fā)送，而且消息發(fā)送功能無(wú)需在單個(gè)網(wǎng)絡(luò)設(shè)備(如多媒體消息服務(wù)中心)中實(shí)現(xiàn)，而是也可以為分發(fā)功能。
對(duì)于上面提到的判決，為說(shuō)明起見(jiàn)，多媒體消息可以認(rèn)為是多媒體消息業(yè)務(wù)中心始發(fā)的，而終端能力和用戶(hù)簡(jiǎn)表可以認(rèn)為是一個(gè)相應(yīng)的終端所固有的。因此，信息必須以任何一種方式發(fā)送以便能判決。
此外，為方便起見(jiàn)，如果判決是自動(dòng)的并且根據(jù)終端和用戶(hù)提供的參數(shù)優(yōu)化也是可以理解的。然而，這并不是本發(fā)明的前提。
由于多媒體消息可具有一定的格式，多個(gè)部分(段)，不同內(nèi)容(文本、圖像、語(yǔ)音、視頻等等)，不同大小或發(fā)送人識(shí)別，顯然，這取決于接收終端的能力和當(dāng)前定義的用戶(hù)簡(jiǎn)表，終端是否能接收、顯示或處理這些多媒體消息，以及取決于用戶(hù)是否希望這樣做。
因此，關(guān)于如何處理這些多媒體消息的判決結(jié)果可以是，應(yīng)全部、部分或經(jīng)修正后發(fā)送，應(yīng)丟棄，存儲(chǔ)于多媒體消息業(yè)務(wù)中心，或應(yīng)轉(zhuǎn)發(fā)到例如一個(gè)因特網(wǎng)郵件地址。前面提到，不自動(dòng)判決，而是請(qǐng)示用戶(hù)如何做，這在一般情況下還是在特殊情況下，當(dāng)然都是可能的。此外，由于在多媒體消息業(yè)務(wù)中心估計(jì)沒(méi)有無(wú)限的內(nèi)存空間提供使用，在多媒體消息業(yè)務(wù)中心存儲(chǔ)多媒體消息將在大部分情況下被限制到一定的時(shí)間周期(因此，在清除存儲(chǔ)的消息之前，MMSC可以通過(guò)一個(gè)相應(yīng)的通告通知用戶(hù)該時(shí)間周期終止)。如果只應(yīng)發(fā)送部分多媒體消息，未被發(fā)送部分也可以被存儲(chǔ)、轉(zhuǎn)發(fā)或丟棄。修正多媒體消息的情況通?？赡苁菍⒍嗝襟w消息從一種格式轉(zhuǎn)換為另一種格式，但對(duì)數(shù)據(jù)進(jìn)行壓縮或其他形式的處理通過(guò)上述表述也應(yīng)能理解。結(jié)果，不像這樣劃分的多媒體消息可通過(guò)這種處理分段。對(duì)于如何處理提交多媒體消息的幾種可能性，判決結(jié)果也可能最終是上述各項(xiàng)的各種組合。
除此之外，如果多媒體消息業(yè)務(wù)中心被指定為通用分組無(wú)線(xiàn)電和通用移動(dòng)通信系統(tǒng)的一個(gè)新的網(wǎng)絡(luò)單元，那么，數(shù)據(jù)發(fā)送將很有可能通過(guò)使用根據(jù)所述系統(tǒng)的相應(yīng)的其他網(wǎng)絡(luò)單元在協(xié)議數(shù)據(jù)單元非實(shí)時(shí)執(zhí)行，為清晰起見(jiàn)，在本發(fā)明的描述中這些其他網(wǎng)絡(luò)單元被忽略。
第一個(gè)實(shí)施例根據(jù)本發(fā)明的第一個(gè)實(shí)施例，涉及選擇發(fā)送多媒體消息的判決在多媒體消息業(yè)務(wù)中心(MMSC)執(zhí)行。這種方案的基本觀(guān)點(diǎn)在于，接收到一個(gè)新的多媒體消息后，多媒體消息業(yè)務(wù)中心能立刻決定必須選擇哪種發(fā)送類(lèi)型。換句話(huà)說(shuō)，多媒體消息業(yè)務(wù)中心用作終端的預(yù)過(guò)濾器。
為提供這種功能，終端能力和當(dāng)前用戶(hù)簡(jiǎn)表必須存儲(chǔ)于多媒體消息業(yè)務(wù)中心。此外，這種信息必須在一定條件下刷新。如果這些信息(終端能力和用戶(hù)簡(jiǎn)表)以及傳遞的多媒體消息業(yè)務(wù)中心從不改變，信息必須提交并且存儲(chǔ)一次，而且不會(huì)被刷新。當(dāng)然，這些先決條件幾乎不會(huì)滿(mǎn)足。因此，初始信息和刷新的信息必須提交給多媒體消息業(yè)務(wù)中心以便保持該中心存儲(chǔ)的信息有效。
這些信息可以包括所述終端的顯示類(lèi)型、所述終端的鍵盤(pán)類(lèi)型、所述終端支持的編解碼電路、所述終端的存儲(chǔ)器大小、所述終端與其他設(shè)備的電連接、連接所述終端等的外部附件，當(dāng)然還包括當(dāng)前用戶(hù)簡(jiǎn)表。
當(dāng)從終端提交信息給多媒體消息業(yè)務(wù)中心時(shí)有幾種可能的條件，而且刷新的可能性并不僅限制為一種條件。然而，刷新應(yīng)聯(lián)系刷新的必要性，或至少聯(lián)系提交該信息與必須提交的其他數(shù)據(jù)(可以是這兩個(gè)網(wǎng)絡(luò)單元之間的任何信令序列)的可能性，以避免業(yè)務(wù)干擾。因此，當(dāng)終端啟動(dòng)其信令序列以提交信息時(shí)的條件是預(yù)定的。這個(gè)條件可以是所述終端登錄所述網(wǎng)絡(luò)，所述終端的連接條件改變，語(yǔ)境激活或語(yǔ)境條件改變，用戶(hù)簡(jiǎn)表產(chǎn)生或修正，終端始發(fā)的業(yè)務(wù)或終端終接的業(yè)務(wù)，所述多媒體消息業(yè)務(wù)中心的請(qǐng)求，所述多媒體消息業(yè)務(wù)中心通知所述終端一個(gè)新的多媒體消息的出現(xiàn)和/或內(nèi)容，等等。
參考圖1，通過(guò)一旦預(yù)定的語(yǔ)境條件激活就提交信息的例子，示意了提交關(guān)于終端能力和當(dāng)前用戶(hù)簡(jiǎn)表信息的信令序列。
因此，在第一步驟S11，諸如移動(dòng)臺(tái)的終端MS通過(guò)一個(gè)支持節(jié)點(diǎn)SN請(qǐng)求語(yǔ)境激活多媒體消息業(yè)務(wù)中心MMSC。利用這個(gè)語(yǔ)境激活請(qǐng)求，終端MS同時(shí)提交其能力CAP和當(dāng)前用戶(hù)簡(jiǎn)表UP。根據(jù)GPRS或UMTS的當(dāng)前網(wǎng)絡(luò)例子，圖1所示的整個(gè)信令可利用協(xié)議數(shù)據(jù)單元PDU發(fā)生。
這個(gè)發(fā)送完成后，多媒體消息業(yè)務(wù)中心MMSC存儲(chǔ)該終端MS的用戶(hù)簡(jiǎn)表UP。由于多媒體消息業(yè)務(wù)中心的能力限制，可能或必須在終端MS的能力CAP范圍內(nèi)調(diào)整終端MS的用戶(hù)簡(jiǎn)表UP。然而，用戶(hù)可以禁止這種修正其優(yōu)選用戶(hù)簡(jiǎn)表。用戶(hù)簡(jiǎn)表UP的存儲(chǔ)和其最終處理在步驟S12執(zhí)行。
在第三步驟S13，從多媒體消息業(yè)務(wù)中心MMSC通過(guò)支持節(jié)點(diǎn)SN至少提交該語(yǔ)境激活的確認(rèn)到終端MS。
然而，如果用于終端MS的多媒體消息MM當(dāng)前出現(xiàn)在多媒體消息業(yè)務(wù)中心MMSC，那么在步驟S13之前將為步驟S14，其中這個(gè)多媒體消息MM根據(jù)存儲(chǔ)于多媒體消息業(yè)務(wù)中心MMSC中的用戶(hù)簡(jiǎn)表UP處理。對(duì)多媒體消息MM的處理對(duì)應(yīng)基于目前存儲(chǔ)于多媒體消息業(yè)務(wù)中心MMSC的終端MS能力CAP和用戶(hù)簡(jiǎn)表UP的判決過(guò)程的結(jié)果。這種判決過(guò)程的可能結(jié)果在上面詳細(xì)討論，而且再次提到，根據(jù)第一個(gè)實(shí)施例，這種判決是由多媒體消息業(yè)務(wù)中心MMSC執(zhí)行的。
根據(jù)這種判決結(jié)果，處理多媒體消息MM可能要求處理多媒體消息MM的數(shù)據(jù)(例如在經(jīng)修正后發(fā)送或部分發(fā)送的情況下)或不要求這種處理，這在上面已經(jīng)提到。在任何情況下，如果至少部分多媒體消息MM必須提交給終端MS，這將在步驟S13與提交語(yǔ)境激活確認(rèn)一起執(zhí)行。
前面提到，圖1描繪的例子僅提供用于示意，而且第一個(gè)實(shí)施例并不限制為這個(gè)例子。由此，本領(lǐng)域的技術(shù)人員完全知道，根據(jù)上述的第一個(gè)實(shí)施例，使圖1所示的過(guò)程分別適應(yīng)于其他可能性。
第二個(gè)實(shí)施例除了根據(jù)第一個(gè)實(shí)施例的技術(shù)解決方案，還有其他可選方案用于僅在終端方維持終端能力和用戶(hù)簡(jiǎn)表信息，由此終端做出選擇發(fā)送多媒體消息的判定。
因此，第二個(gè)實(shí)施例的基本觀(guān)點(diǎn)在于，終端能力和用戶(hù)簡(jiǎn)表信息存儲(chǔ)于終端，例如終端設(shè)備，或在移動(dòng)終端的情況下，存儲(chǔ)于SIM，或存儲(chǔ)于兩者中。由此，發(fā)送多媒體消息的決定在終端做出。
現(xiàn)在參考圖2和圖3描述根據(jù)第二個(gè)實(shí)施例的多媒體消息業(yè)務(wù)中心和終端的功能。
圖2示意了根據(jù)這個(gè)實(shí)施例，一旦接收到一個(gè)新的移動(dòng)臺(tái)終接的多媒體消息MM，多媒體消息業(yè)務(wù)中心MMSC的功能例子。由此可見(jiàn)，多媒體消息業(yè)務(wù)中心MMSC在接收到一個(gè)新的多媒體消息MM(步驟S20)后，在步驟S21自動(dòng)發(fā)送一個(gè)特殊控制消息MMSNotify到終端MS。MMSNotify消息包含有關(guān)實(shí)際的多媒體消息MM的信息，如該消息的總體尺寸、內(nèi)容、內(nèi)容類(lèi)型、可讀描述，等等。
根據(jù)存儲(chǔ)的有關(guān)終端能力CAP和其當(dāng)前用戶(hù)簡(jiǎn)表UP的信息，終端MS現(xiàn)在處理MMSNotify消息中包含的信息，由此決定如何處理多媒體消息MM。根據(jù)這個(gè)判決過(guò)程，終端MS發(fā)送一個(gè)相應(yīng)的應(yīng)答消息到多媒體消息業(yè)務(wù)中心MMSC，該消息在步驟S22被多媒體消息業(yè)務(wù)中心MMSC接收。這個(gè)過(guò)程通過(guò)圖3中的例子示意，下面將對(duì)此進(jìn)行描述。
應(yīng)注意，本發(fā)明并不限制發(fā)送MMSNotify消息的裝置為終端MS。例如，多媒體消息業(yè)務(wù)中心MMSC也可以發(fā)送MMSNotify消息作為一種特殊的SMS消息，該消息接著被終端MS分析，或多媒體消息業(yè)務(wù)中心MMSC可利用多媒體消息業(yè)務(wù)專(zhuān)用的一種特定承載(例如，控制信道)。
無(wú)論如何，根據(jù)第二個(gè)實(shí)施例用于分別交換消息和信息的信令序列基于下面的原理。一接收到MMSNotify消息，終端MS提交MSResultRequest消息作為應(yīng)答，該消息在步驟S22被多媒體消息業(yè)務(wù)中心MMSC接收。然而，由于判決過(guò)程的結(jié)果不同，可能的MMSResultRequest消息互不相同。因此，MMSResultRequest消息可以是例如，MMSDeliverReq，MMSStoreReq，MMSForwardReq或MMSDiscardReq。
因此，在步驟S23，多媒體消息業(yè)務(wù)中心MMSC檢查終端MS的應(yīng)答是否為MMSStoreReq消息，如果為“yes”，則多媒體消息MM在步驟S26存儲(chǔ)于多媒體消息業(yè)務(wù)中心。如果為“no”，則該過(guò)程繼續(xù)進(jìn)行到步驟S24，以檢查應(yīng)答是否為MMSDeliverReq消息。
如果MMSDeliverReq消息被終端MS應(yīng)答，該過(guò)程進(jìn)行到步驟S27，其中多媒體消息業(yè)務(wù)中心MMSC檢查MMSDeliverReq消息，多媒體消息應(yīng)被部分發(fā)送還是全部發(fā)送。圖2所示的步驟S29表示發(fā)送部分多媒體消息MM到終端MS的情形，其后是上面提到的步驟S26，其中至少未被發(fā)送的部分多媒體消息MM被存儲(chǔ)于多媒體消息業(yè)務(wù)中心MMSC。與此相反，步驟S210表示發(fā)送全部多媒體消息MM到多媒體消息業(yè)務(wù)中心MMSC的情形，其后是步驟S211，其中在發(fā)送后從多媒體消息業(yè)務(wù)中心MMSC去除這個(gè)多媒體消息MM。
如果MMSDeliverReq消息沒(méi)有被終端MS應(yīng)答，那么在該過(guò)程的步驟S25檢查MMSForwardReq消息是否被應(yīng)答。如果沒(méi)有被應(yīng)答，假設(shè)出現(xiàn)MMSDiscardReq消息，而且根據(jù)步驟S211多媒體消息MM從多媒體消息業(yè)務(wù)中心MMSC去除。如果出現(xiàn)MMSForwardReq消息，多媒體消息MM在步驟S211被從多媒體消息業(yè)務(wù)中心MMSC去除前，在步驟S28首先轉(zhuǎn)發(fā)到由MMSForwardReq消息給定的目的地。
現(xiàn)在參考圖3描述根據(jù)圖2的步驟S21，在步驟S30接收到MMSNotify消息后終端MS的功能。
具體來(lái)說(shuō)，終端MS在步驟S31檢查其能力CAP和用戶(hù)簡(jiǎn)表UP，之后是對(duì)應(yīng)的判決步驟S32-S35。從圖3可看出，將決策權(quán)交與用戶(hù)的選擇包含作為對(duì)應(yīng)于步驟S32的一個(gè)選項(xiàng)。如果設(shè)置用戶(hù)簡(jiǎn)表UP以便用戶(hù)應(yīng)對(duì)發(fā)送多媒體消息MM做出判決，那么用戶(hù)輸入的結(jié)果被進(jìn)一步傳送到步驟S33-S35。如果該判決是自動(dòng)執(zhí)行，根據(jù)本發(fā)明的第二個(gè)實(shí)施例，終端MS根據(jù)其用戶(hù)簡(jiǎn)表UP和能力CAP決定如何處理多媒體消息業(yè)務(wù)中心MMSC中出現(xiàn)的多媒體消息MM。不管怎樣，在這種情況下結(jié)果也將進(jìn)一步送至步驟S33-S35。
上面討論了終端MS如何決定發(fā)送多媒體消息MM的幾種選擇，而且其中一些選擇在圖3示意作為示例。即，在步驟S33終端檢查結(jié)果是否為部分或全部恢復(fù)多媒體消息MM，如果正是這樣，在接下來(lái)的步驟S37中，MMSDeliverReq消息被發(fā)送到多媒體消息業(yè)務(wù)中心MMSC。如果多媒體消息MM不應(yīng)被恢復(fù)，但在步驟S34檢測(cè)結(jié)果為應(yīng)轉(zhuǎn)發(fā)消息MM，那么在下面的步驟S38發(fā)送MMSForwardReq消息到多媒體消息業(yè)務(wù)中心MMSC。如果結(jié)果不是轉(zhuǎn)發(fā)該消息，該過(guò)程進(jìn)行到步驟S35，以檢查結(jié)果是否為使多媒體消息MM存儲(chǔ)于多媒體消息業(yè)務(wù)中心MMSC。如果結(jié)果為T(mén)RUE，接下來(lái)的步驟S39包括發(fā)送MMSStoreReq消息到多媒體消息業(yè)務(wù)中心MMSC，如果結(jié)果不是TRUE，下面的步驟S40包括發(fā)送MMSDiscardReq消息到多媒體消息業(yè)務(wù)中心MMSC，這是假設(shè)上述為判決過(guò)程的結(jié)果。
在任何情況下，所有步驟S37-S40后都跟隨步驟S41，在步驟S41中，再一次檢測(cè)用戶(hù)簡(jiǎn)表，以確定用戶(hù)在步驟S42是否應(yīng)接收到關(guān)于出現(xiàn)多媒體消息MM以及可能有關(guān)對(duì)其執(zhí)行的處理的適當(dāng)通知。在這兩種情況下，流程結(jié)束直到接收到另一MMSNotify消息。
上面提到，根據(jù)圖3的其中一個(gè)步驟S37-S40，終端MS發(fā)送的應(yīng)答消息在圖2的步驟S22被多媒體消息業(yè)務(wù)中心MMSC接收。此外，這個(gè)應(yīng)答消息都包含多媒體消息業(yè)務(wù)中心MMSC根據(jù)終端始發(fā)的發(fā)送多媒體消息MM決定而作用所需的所有信息。
還應(yīng)注意，圖2和圖3描繪的例子并不限制本發(fā)明，而且上面已經(jīng)詳細(xì)陳述了發(fā)送多媒體消息的選擇范圍。根據(jù)本發(fā)明，沿著上面陳述的描述思路，可以很容易地對(duì)圖2和圖3的流程圖作進(jìn)一步的精煉和改進(jìn)。
作為第二個(gè)實(shí)施例的另一個(gè)可選方案，終端和多媒體消息業(yè)務(wù)中心之間的信令可以利用單個(gè)請(qǐng)求-應(yīng)答消息對(duì)實(shí)現(xiàn)。換句話(huà)說(shuō)，終端總是能用MMSNotifyReply消息應(yīng)答MMSNotify消息。在這種情況下，通過(guò)在所述MMSNotifyReply消息中為每部分多媒體消息分配一個(gè)控制標(biāo)志(例如，用2bits表示)可以實(shí)現(xiàn)終端和多媒體消息業(yè)務(wù)中心的預(yù)期功能。如果該標(biāo)志的值被發(fā)送、存儲(chǔ)、轉(zhuǎn)發(fā)或丟棄，該終端能利用一個(gè)簡(jiǎn)單的應(yīng)答消息通知多媒體消息業(yè)務(wù)中心如何處理每部分多媒體消息。
這種技術(shù)解決方案能提供更為靈活的功能。例如，很明顯，根據(jù)這個(gè)可選方案，能利用一個(gè)應(yīng)答消息命令多媒體消息業(yè)務(wù)中心將每部分多媒體消息與其它部分獨(dú)立、區(qū)別對(duì)待，以便某些部分可以發(fā)送到終端，而某些部分可以轉(zhuǎn)發(fā)到一個(gè)因特網(wǎng)郵件地址，等等。
然而，這是假定多媒體消息各部分明確定義，而且多媒體消息業(yè)務(wù)中心能處理分隔的每部分多媒體消息。
根據(jù)第二個(gè)實(shí)施例，還具有下述優(yōu)點(diǎn)終端能力和用戶(hù)簡(jiǎn)表信息不必在多媒體消息業(yè)務(wù)中心維護(hù)，由此不會(huì)浪費(fèi)多媒體消息業(yè)務(wù)中心的存儲(chǔ)和處理能力，而是留作其他目的。
此外，信息不必在每次出現(xiàn)預(yù)定條件都發(fā)送以保持存儲(chǔ)于多媒體消息業(yè)務(wù)中心的信息有效。因此，在終端和多媒體消息業(yè)務(wù)中心之間不會(huì)引起額外的信令。總之，可以確保信息總是最新，而且由于刷新信令不會(huì)造成業(yè)務(wù)干擾。
另外，在多媒體消息業(yè)務(wù)中心不必執(zhí)行額外的處理。由于可以預(yù)期，根據(jù)第二個(gè)實(shí)施例，多媒體消息業(yè)務(wù)中心的結(jié)構(gòu)可以保持在一個(gè)較低的難度級(jí)別，即多媒體消息業(yè)務(wù)中心的實(shí)現(xiàn)變得更為簡(jiǎn)單，而且其性能要求降低，這可能就是為什么優(yōu)選這個(gè)實(shí)施例的原因。
如上所述，本發(fā)明提出了一種用于在包括至少一個(gè)終端和一個(gè)消息發(fā)送功能的通信網(wǎng)絡(luò)中發(fā)送消息的方法，所述方法包括步驟所述消息發(fā)送功能MMSC為所述終端MS接收消息MM；從所述消息發(fā)送功能MMSC發(fā)送關(guān)于出現(xiàn)所述消息MM的通知MMSNotify到所述終端MS；所述終端MS根據(jù)其能力CAP和當(dāng)前用戶(hù)簡(jiǎn)表UP決定如何處理所述接收消息MM；所述終端MS應(yīng)答所述消息發(fā)送功能MMSC發(fā)送的通知，同時(shí)根據(jù)所述確定步驟的結(jié)果下達(dá)指令；以及所述消息發(fā)送功能MMSC根據(jù)所述指令處理所述消息MM。
應(yīng)理解的是，上面的描述和附圖僅用于通過(guò)舉例示意本發(fā)明。因此本發(fā)明的優(yōu)選實(shí)施例可以在所附權(quán)利要求書(shū)的范圍內(nèi)改變。
權(quán)利要求
1.一種用于在包括至少一個(gè)終端和一個(gè)消息發(fā)送功能的通信網(wǎng)絡(luò)中發(fā)送消息的方法，所述方法包括步驟一旦出現(xiàn)一個(gè)預(yù)定條件，就從所述終端(MS)提交涉及終端(MS)能力(CAP)和其當(dāng)前用戶(hù)簡(jiǎn)表(UP)的信息到所述消息發(fā)送功能(MMSC)；所述消息發(fā)送功能(MMSC)根據(jù)所述信息確定如何為所述終端(MS)處理所述消息發(fā)送功能(MMSC)接收的消息(MM)；以及所述消息發(fā)送功能(MMSC)根據(jù)所述確定步驟的結(jié)果處理所述消息(MM)。
2.根據(jù)權(quán)利要求1的方法，還包括在所述消息發(fā)送功能(MMSC)存儲(chǔ)所述信息的步驟。
3.根據(jù)權(quán)利要求1的方法，其中所述確定步驟的結(jié)果至少存在于所述終端(MS)的所述消息(MM)被全部、部分發(fā)送或是經(jīng)修正后發(fā)送到所述終端(MS)，所述消息(MM)被丟棄，所述消息(MM)被轉(zhuǎn)發(fā)到另一終端，或所述消息(MM)被存儲(chǔ)于所述消息發(fā)送功能(MMSC)。
4.根據(jù)權(quán)利要求1的方法，其中所述預(yù)定條件為下面事件中的至少一個(gè)所述終端(MS)登錄所述網(wǎng)絡(luò)，所述終端(MS)的連接條件改變，語(yǔ)境激活或語(yǔ)境條件的改變，用戶(hù)簡(jiǎn)表(UP)創(chuàng)建或用戶(hù)簡(jiǎn)表(UP)修正，終端始發(fā)的業(yè)務(wù)或終端終接的業(yè)務(wù)，所述消息發(fā)送功能(MMSC)的請(qǐng)求，所述消息發(fā)送功能(MMSC)通知所述終端(MS)出現(xiàn)一個(gè)新消息(MM)，以及所述消息發(fā)送功能(MMSC)通知所述終端(MS)一個(gè)新消息(MM)的內(nèi)容、類(lèi)型和大小。
5.根據(jù)權(quán)利要求1的方法，其中涉及所述終端(MS)的所述能力(CAP)的所述信息包括下面的至少一個(gè)所述終端(MS)的顯示類(lèi)型，所述終端(MS)的鍵盤(pán)類(lèi)型，所述終端(MS)支持的編解碼電路，所述終端(MS)的存儲(chǔ)器大小，所述終端(MS)與其他設(shè)備的電連接，連接所述終端(MS)的外部附件，或當(dāng)前用戶(hù)簡(jiǎn)表(UP)。
6.一種用于在包括至少一個(gè)終端和一個(gè)消息發(fā)送功能的通信網(wǎng)絡(luò)中發(fā)送消息的方法，所述方法包括步驟所述消息發(fā)送功能(MMSC)為所述終端(MS)接收消息(MM)；從所述消息發(fā)送功能(MMSC)發(fā)送關(guān)于出現(xiàn)所述消息(MM)的通知(MMSNotify)到所述終端(MS)；所述終端(MS)根據(jù)其能力(CAP)和當(dāng)前用戶(hù)簡(jiǎn)表(UP)，確定如何處理所述接收消息(MM)；所述終端(MS)應(yīng)答所述消息發(fā)送功能(MMSC)發(fā)送的通知，同時(shí)根據(jù)所述確定步驟的結(jié)果下達(dá)指令；以及所述消息發(fā)送功能(MMSC)根據(jù)所述指令來(lái)處理所述消息(MM)。
7.根據(jù)權(quán)利要求6的方法，其中所述確定步驟的結(jié)果至少存在于所述終端(MS)的所述消息(MM)被全部、部分發(fā)送或經(jīng)修正后發(fā)送到所述終端(MS)，所述消息(MM)被丟棄，所述消息(MM)被轉(zhuǎn)發(fā)到另一終端，或所述消息(MM)被存儲(chǔ)于所述消息發(fā)送功能(MMSC)。
8.根據(jù)權(quán)利要求6的方法，其中從所述消息發(fā)送功能(MMSC)發(fā)送到所述終端(MS)的關(guān)于出現(xiàn)所述消息(MM)的所述通知(MMSNotify)還通知所述消息(MM)的至少內(nèi)容、類(lèi)型和大小。
9.根據(jù)權(quán)利要求8的方法，其中所述終端(MS)在信令過(guò)程中通過(guò)發(fā)送一個(gè)包含所述消息(MM)每個(gè)部分的控制標(biāo)志的通知應(yīng)答消息來(lái)應(yīng)答所述消息發(fā)送功能(MMSC)，而所述控制標(biāo)志的值可以被發(fā)送、修正、存儲(chǔ)、轉(zhuǎn)發(fā)或丟棄。
10.根據(jù)權(quán)利要求6的方法，其中所述確定步驟包括所述終端(MS)請(qǐng)示用戶(hù)如何處理消息(MM)以及用戶(hù)輸入的表示所述確定步驟結(jié)果的輸入。
11.一種消息發(fā)送功能設(shè)備，包括用于接收消息(MM)和信息的接收裝置；用于處理接收信息數(shù)據(jù)和消息(MM)的處理裝置；存儲(chǔ)裝置；用于分別發(fā)送信息和消息(MM)到所述終端(MS)的發(fā)送裝置。
12.一種終端設(shè)備，包括用于接收消息(MM)和信息的接收裝置；用于處理接收信息數(shù)據(jù)和消息(MM)的處理裝置；存儲(chǔ)裝置；用于分別發(fā)送信息和消息(MM)到所述終端(MS)的發(fā)送裝置。
全文摘要
本發(fā)明提出了一種用于在包括至少一個(gè)終端和一個(gè)消息發(fā)送功能的通信網(wǎng)絡(luò)中發(fā)送消息的方法,所述方法包括步驟:所述消息發(fā)送功能(MMSC)為所述終端(MS)接收消息;從所述消息發(fā)送功能(MMSC)發(fā)送關(guān)于出現(xiàn)所述消息(MM)的通知(MMSNotify)到所述終端(MS);所述終端(MS)根據(jù)其能力(CAP)和當(dāng)前用戶(hù)簡(jiǎn)表(UP)確定如何處理所述接收消息(MM);所述終端(MS)應(yīng)答所述消息發(fā)送功能(MMSC)發(fā)送的通知,同時(shí)根據(jù)所述確定步驟的結(jié)果下達(dá)指令;以及所述消息發(fā)送功能(MMSC)根據(jù)所述指令處理所述消息(MM)。
文檔編號(hào)H04L12/58GK1348650SQ99816578
公開(kāi)日2002年5月8日 申請(qǐng)日期1999年4月19日 優(yōu)先權(quán)日1999年4月19日
發(fā)明者邁克爾·羅克, 加科·塞萬(wàn)托, 阿迪·穆霍寧 申請(qǐng)人:諾基亞網(wǎng)絡(luò)有限公司