專利名稱：彩信處理方法及多媒體消息中心的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，具體而言，涉及一種彩信處理方法及多 媒體消息中心。
背景技術(shù)：
多々某體消息業(yè)務(wù)(Multimedia Messaging Service,簡-爾為MMS ) 也稱為彩信中心，是一種能夠在終端(該終端可以是手機(jī))和手機(jī) 之間以及手機(jī)和應(yīng)用之間傳送多々某體內(nèi)容的消息服務(wù)，例如，手機(jī) 和Email服務(wù)器。多媒體消息業(yè)務(wù)按照用戶歸屬的運(yùn)營商及所在的 區(qū)i或進(jìn)4亍劃分，由用戶歸屬的多々某體消息中心(Multimedia Messaging Service Center,簡稱為MMSC )為用戶4是供多士某體消息 業(yè)務(wù)。月良務(wù)才是供商(Service Provider, SP )是指移動互聯(lián)網(wǎng)應(yīng)用月l務(wù) 的直接提供者，負(fù)責(zé)根據(jù)用戶的要求開發(fā)和提供適合手機(jī)用戶使用 的月良務(wù)。通常SP具有電信運(yùn)營商接入通道為用戶提供服務(wù)。凄t字版斗又(Digital Rights Management,簡稱為DRM )力口密保 護(hù)技術(shù)，指的是出版者用來控制被保護(hù)對象的使用權(quán)的 一 些技術(shù)， 這些技術(shù)保護(hù)的有數(shù)位化內(nèi)容(例如，軟件、音樂、電影)以及硬件， 處理數(shù)字化產(chǎn)品的某個實(shí)例的使用限制，保護(hù)其不被盜版使用。DRM服務(wù)器(DRM Server)主要具有4受一又i青求、計(jì)費(fèi)通知、 域管理等功能，實(shí)現(xiàn)與業(yè)務(wù)引擎之間授權(quán)請求和計(jì)費(fèi)通知消息的交互。DRM代理(DRM Agent)位于終端上，用于管理終端上媒體對 象的授權(quán)許可的實(shí)體。關(guān)于DRM的發(fā)送方法有以下幾種禁止4爭發(fā)，在DRM消息 中僅包含一個媒體對象而無版權(quán)對象，在這種情況下，媒體對象采用 一套缺省設(shè)置的版權(quán)；組合發(fā)送，版權(quán)對象和受保護(hù)的媒體內(nèi)容在 一個消息中一起,皮遞交；分別發(fā)送，受^f呆護(hù)內(nèi)容和版4又對象可以不 同的傳送才幾制發(fā)送。由于DRM信息的特殊性，現(xiàn)有的多媒體消息中心無法處理帶 有DRM信息的彩信。針對相關(guān)技術(shù)中MMSC無法處理帶DRM信息的彩信的問題， 目前尚未沖是出有效的解決方案。發(fā)明內(nèi)容針對相關(guān)4支術(shù)中MMSC無法處理帶DRM信息的彩信的問題而 提出本發(fā)明，為此，本發(fā)明的主要目的在于提供一種改進(jìn)的彩信處 理方案，以解決上述問題。為了實(shí)現(xiàn)上述目的，根據(jù)本發(fā)明的一個方面，提供了一種彩信 處J里方法。根據(jù)本發(fā)明的彩信處理方法包括多媒體消息中心接收來自發(fā) 送方的彩信，并在確定彩信中包括數(shù)字版權(quán)之后，通過數(shù)字版權(quán)服 務(wù)器進(jìn)行鑒權(quán)；在鑒權(quán)成功之后，多媒體消息中心接收來自接收方的用于獲取彩信的獲取請求消息，并判斷接收方是否支持?jǐn)?shù)字版權(quán)的保護(hù)方式；多々某體消息中心在接收方支持?jǐn)?shù)字版權(quán)的保護(hù)方式的情況下向接收方發(fā)送彩信。優(yōu)選地，多媒體消息中心判斷接收方是否支持?jǐn)?shù)字版權(quán)的保護(hù)方式包括多媒體消息中心從獲取請求消息中獲取接收方的終端的類型，根據(jù)預(yù)先配置的終端類型與該類型的終端是否支持?jǐn)?shù)字版權(quán) 的保護(hù)方式的對應(yīng)關(guān)系，判斷的接收方的終端是否支持?jǐn)?shù)字版一又的保護(hù)方式，其中，數(shù)字版權(quán)能力的集合包括每種類型的終端支持 的數(shù)字版權(quán)的保護(hù)方式。優(yōu)選地，在多媒體消息中心接收來自接收方的獲取請求消息之 前，上述方法還包括多媒體消息中心向接收方下發(fā)通告消息；接 收方在接收到通告消息后，向多媒體消息中心發(fā)送獲取請求消息。優(yōu)選地，通過數(shù)字版權(quán)服務(wù)器進(jìn)行鑒權(quán)包括多媒體消息中心 向數(shù)字版權(quán)服務(wù)器發(fā)送鑒權(quán)請求消息；數(shù)字版權(quán)服務(wù)器對數(shù)字版權(quán) 進(jìn)行鑒權(quán)。優(yōu)選地，在確定彩信中包括數(shù)字版權(quán)之后，上述方法還包括 多媒體消息中心獲取并保存數(shù)字版權(quán)的信息，其中，數(shù)字版權(quán)的信 息包括數(shù)字版權(quán)的4呆護(hù)方式。優(yōu)選地，在多i某體消息中心接收來自彩信之前，上述方法還包 括發(fā)送方向多々某體消息中心發(fā)送彩信，其中，彩信的內(nèi)容類型字 段中數(shù)字版權(quán)的保護(hù)方式。優(yōu)選地，在多媒體消息中心向接收方發(fā)送獲取響應(yīng)消息之后， 上述方法還包括多媒體消息中心向數(shù)字版權(quán)服務(wù)器發(fā)送用于的消 息，其中，消息用于指示彩信發(fā)送成功。優(yōu)選地，在接收方不支持?jǐn)?shù)字版權(quán)的保護(hù)方式的情況下，上述
方法還包括多媒體消息中心向接收方發(fā)送失敗的響應(yīng)消息，并且不向4妄收方發(fā)送彩信。
為了實(shí)現(xiàn)上述目的，才艮據(jù)本發(fā)明的另一方面，提供了一種多々某體消息中心。
根據(jù)本發(fā)明的多々某體消息中心包括第一接收模塊，用于接收來自發(fā)送方的彩信；鑒權(quán)模塊，用于在確定彩信中包括數(shù)字版權(quán)之后，通過數(shù)字版權(quán)服務(wù)器進(jìn)行鑒權(quán)；第二接收模塊，用于在鑒權(quán)成功之后接收來自接收方的用于獲取彩信的獲取請求消息；判斷模塊，用于判斷接收方是否支持?jǐn)?shù)字版權(quán)的保護(hù)方式；發(fā)送模塊，用于在接收方支持?jǐn)?shù)字版權(quán)的保護(hù)方式的情況下向接收方發(fā)送彩信。
優(yōu)選地，上述多々某體消息中心還包括配置沖莫塊，用于配置的數(shù)字版權(quán)能力的集合，其中，數(shù)字版權(quán)能力的集合包括每種類型的終端支持的數(shù)字版權(quán)的保護(hù)方式；判斷模塊具體用于根據(jù)數(shù)字版權(quán)能力的集合判斷作為接收方的終端是否支持?jǐn)?shù)字版權(quán)的保護(hù)方式。
通過本發(fā)明，采用MMSC對彩信中DRM的保護(hù)方式與4妻收方DRM的能力進(jìn)行判斷后，對彩信進(jìn)行相關(guān)處理，解決了相關(guān)技術(shù)中MMSC無法處理帶DRM信息的彩信的問題，使彩信中心有處理DRM信息以及判斷終端手機(jī)是否支持DRM的能力，實(shí)現(xiàn)了 DRM版權(quán)信息通過彩信系統(tǒng)進(jìn)行收發(fā)，從而為多媒體消息中心的應(yīng)用提供更廣闊的空間。


此處所說明的附圖用來提供對本發(fā)明的進(jìn)一步理解，構(gòu)成本申請的一部分，本發(fā)明的示意性實(shí)施例及其說明用于解釋本發(fā)明，并
不構(gòu)成對本發(fā)明的不當(dāng)限定。在附圖中
圖1是根據(jù)本發(fā)明實(shí)施例的彩信處理方法的流程圖
圖2是根據(jù)本發(fā)明實(shí)施例的MMSC處理含有DRM的彩信具體的流禾呈圖3是才艮據(jù)本發(fā)明實(shí)施例的DRM能力的定義的示意圖；圖4是根據(jù)本發(fā)明實(shí)施例的MMSC的結(jié)構(gòu)框圖；圖5是根據(jù)本發(fā)明實(shí)施例的MMSC具體的結(jié)構(gòu)框圖。
具體實(shí)施方式
功能概述
考慮到相關(guān)4支術(shù)中MMSC無法處理帶DRM信息的彩信的問題，本發(fā)明實(shí)施例提供了一種彩信處理方案，該方案處理原則如下MMSC接收來自發(fā)送方的多媒體信息，該多媒體信息即彩信，并在確定彩信中包括DRM之后，通過DRM服務(wù)器(Server )進(jìn)行鑒權(quán)；在鑒權(quán)成功之后，MMSC接收來自接收方的用于獲取彩信的獲取請求消息，并判斷接收方是否支持DRM的保護(hù)方式；MMSC在4妻收方支持DRM的4呆護(hù)方式的情況下向4妻收方發(fā)送彩信。
需要說明的是，在不沖突的情況下，本申請中的實(shí)施例及實(shí)施例中的特征可以相互組合。下面將參考附圖并結(jié)合實(shí)施例來詳細(xì)i兌明本發(fā)明。在以下實(shí)施例中，在附圖的流程圖示出的步艱《可以在諸如一組計(jì)算機(jī)可執(zhí)行指令的計(jì)算機(jī)系統(tǒng)中執(zhí)行，并且，雖然在流程圖中示
出了邏輯順序，但是在某些情況下，可以以不同于此處的順序執(zhí)行所示出或描述的步艱《。
方法實(shí)施例
才艮據(jù)本發(fā)明的實(shí)施例，^是供了一種彩信處理方法，圖1是才艮據(jù)本發(fā)明實(shí)施例的彩信處理方法的流程圖，如圖1所示，該流程包括:
如下步艱《S102至步-驟S106:
步驟S102, MMSC接收來自發(fā)送方的多媒體信息(MultimediaMessaging,簡稱為MM )，該多媒體信息即彩信，并在確定彩信中包4舌DRM之后，通過DRM Server進(jìn)4亍鑒片又。
步驟S104,在鑒權(quán)成功之后，MMSC接收來自接收方的用于獲取彩信的獲取請求消息，并判斷接收方是否支持DRM的保護(hù)方式。
步驟S106, MMSC在接收方支持DRM的保護(hù)方式的情況下向接收方發(fā)送彩信。
下面結(jié)合上述步驟S102至步驟S106對本實(shí)施例中從發(fā)送方發(fā)送彩信到接收方接收到該彩信的全部過程進(jìn)行詳細(xì)的說明。
步-紫S201, MMSC預(yù)先配置DRM能力的集合，其中，DRM能力的集合包括每種類型的終端支持的DRM的保護(hù)方式。
步驟S202，發(fā)送方(例如，終端包括手才幾、SP)向MMSC發(fā)送一條包含DRM信息的彩信。步驟S203, MMSC接收來自發(fā)送方的彩信，確認(rèn)是一條包含DRM信息的彩信，在MMSC保存DRM的信息之后，其中，DRM的信息包括DRM的保護(hù)方式，通過DRM Server對該DRM進(jìn)4亍鑒—又，具體包4舌MMSC向DRM Server發(fā)送鑒權(quán)請求消息；DRMServer對D畫進(jìn)行鑒權(quán)。
步驟S204，在MMSC接收至)J DRM Server發(fā)送的鑒4又成功的響應(yīng)后，MMSC向4妾收方下發(fā)通告消息。
步驟S205,接收方在接收到通告消息后，向MMSC發(fā)送獲取請求消息，用于獲取上述彩信。其中，接收方的終端類型會i 武值在獲取請求消息中的用戶-代理(user-Agent)字^殳上，MMC在4妄收到該獲取i青求消息后，通過7于該消息進(jìn)4于解石馬,人而獲4f user-Agent的值，進(jìn)而得到4妾收方的終端類型。需要說明的，每種終端都有自己的終端類型，并通過終端本地的編碼才莫塊將終端類型寫入所發(fā)送的消息中。
步驟S206, MMCS查詢終端能力集(即，能力的集合)并才艮據(jù)該能力集判斷作為接收方的終端是否支持否支持DRM及支持DRM的級另ij, 乂人而確i人該手才幾是否可以正常4妄收DRM信息，其中，DRM的級別根據(jù)DRM的保護(hù)方式來劃分，例如，禁止轉(zhuǎn)發(fā)、組合發(fā)送、分別發(fā)送等。
步驟S207， MMSC在接收方支持DRM的保護(hù)方式的情況下向4妄收方發(fā)送上述彩4言，并向4妄收方發(fā)送成功的響應(yīng)消息。
步驟S208,MMSC給發(fā)送方回投遞才艮告消息，并向DRM Server發(fā)送用于的消息，其中，消息用于指示彩信發(fā)送成功。
步驟S209,在接收方不支持DRM的保護(hù)方式的情況下，方MMSC向接收方發(fā)送失敗的響應(yīng)消息，并且不向接收方發(fā)送彩信。為了更詳細(xì)的說明本實(shí)施例，下面分別從幾個方面對本實(shí)施例進(jìn)行說明。
方面一
MMSC需要識別終端是否支持DRM,識別彩信中的格式是否包含DRM內(nèi)容，圖3是根據(jù)本發(fā)明實(shí)施例的DRM能力的定義的示意圖，如圖3所示，可以將終端的DRM能力分為5個級別不支持DRM、支持DRM1.0禁止轉(zhuǎn)發(fā)、支持DRM1.0組合發(fā)送、支持DRM1.0分別發(fā)送、支持DRM2.0。其中，可以通過在MMSC上靜態(tài)配置終端的DRM能力集來確認(rèn)每個終端支持什么級別的DRM信息，即，在MMSC保存全部或大部分型號的終端都分別支持的DRM的級別；還可以通過動態(tài)獲取到DRM能力集，例如，可以通過運(yùn)營商的綜合業(yè)務(wù)管理平臺來獲取。運(yùn)營商的綜合業(yè)務(wù)管理平臺上存放著所有終端類型的數(shù)據(jù)(此數(shù)據(jù)隨著業(yè)務(wù)的開展慢慢4臾集積累，運(yùn)營商的綜合業(yè)務(wù)管理平臺遇到不識別的終端時，在發(fā)送業(yè)務(wù)的同時就會記錄該終端等相關(guān)信息)，該信息以特定的可擴(kuò)展標(biāo)i己語言(Extensible Markup Language,簡稱為XML )形式存方欠在綜合業(yè)務(wù)管理平臺的月良務(wù)器上。MMSC會間隔一端時間(例如，每小時)就下載該信息，然后寫入自己的終端能力集數(shù)據(jù)庫中，獲取的信息中就包括終端型號及該型號對應(yīng)所支持的DRM能力。
彩信中心根據(jù)MM中的內(nèi)容類型字段(Content-Type )來識別內(nèi)容的 DRM 的4呆4戶方式。Content-Type:application/vnd.oma.drm.message, 為禁止壽爭發(fā)或者纟且合發(fā)送、Content-Type:application/vnd.oma.drm.content為分另'J發(fā)送。
方面二只能把跟終端能力相匹配的DRM保護(hù)內(nèi)容發(fā)送到終端上，例
如
不能將任何DRM內(nèi)容發(fā)送到不支持DRM保護(hù)的終端上；
只支持DRMl.O禁止轉(zhuǎn)發(fā)的終端，只能4妄受禁止轉(zhuǎn)發(fā)的DRM 內(nèi)容；
支持DRM1.0組合發(fā)送的終端，可接受禁止轉(zhuǎn)發(fā)、組合發(fā)送的 D脂內(nèi)容；
支持DRM1.0分別發(fā)送的終端，可接受禁止轉(zhuǎn)發(fā)、組合發(fā)送、 分別發(fā)送的DRM內(nèi)容；
支持DRM2.0的鄉(xiāng)冬端，可4妾受所有的DRM內(nèi)容。
方面三
為了保證DRM的安全性，還需要進(jìn)行以下的相關(guān)處理
不能通過外部4妻口轉(zhuǎn)發(fā)任何"禁止轉(zhuǎn)發(fā)"或者"組合發(fā)送"的 MM元素；
不能存儲任何"禁止轉(zhuǎn)發(fā)"或者"組合發(fā)送"的MM元素到用 戶可及的網(wǎng)絡(luò)存^f諸器上；
不能修改任何"禁止轉(zhuǎn)發(fā)"或者"組合發(fā)送"的MM元素的頭 部信息；
接受所有4妄口上"分別發(fā)送"的保護(hù)內(nèi)容。 下面將結(jié)合實(shí)例對本發(fā)明實(shí)施例的實(shí)現(xiàn)過程進(jìn)行詳細(xì)描述。的;克禾呈圖，如圖2所示，該流禾呈包括如下步-驟
步驟1，發(fā)送方(手機(jī)或sp)向彩信中心提交帶有DRM4言息
的彩信。
步驟2，彩信中心(MMSC) 4企查該彩信(MM)中是否包含 受DRM保護(hù)的元素，例如，是否有禁止轉(zhuǎn)發(fā)、組合發(fā)送、分別發(fā) 送的DRM元素，如果有，貝'J MMSC需要i己錄該MM中包含的內(nèi) 容才各式(即，保護(hù)方式)，該信息可以記錄到凄t據(jù)庫中。
步驟3,在MMSC確認(rèn)是該彩信一條包含DRM的彩信消息之 后，向DRM Server發(fā)送鑒權(quán)請求消息。
步驟4， MMSC接收到DRM Server的鑒斥又成功響應(yīng)消息之后， 向4妻4欠方的鄉(xiāng)冬端，例:^，手才幾，下發(fā)通告消息。
步驟5,接收方接收到通告消息之后向MMSC發(fā)送獲取:清求消 息，用于獲耳又該彩信。
步驟6, MMSC接收到手機(jī)的獲取請求消息之后，根據(jù)本次獲 取的MM中是否包含DRM元素以及查詢目的終端能力集來決定如 何回復(fù)獲取響應(yīng)消息。如果MM中沒有DRM元素，則按照普通流 程下發(fā)；如果終端支持禁止轉(zhuǎn)發(fā)、組合發(fā)送、分別發(fā)送的能力的部 分或者全部，則MMSC判斷本MM中的內(nèi)容是否跟終端能力匹酉己， 在完全匹配的情況下，向終端返回成功的響應(yīng)消息，將該彩信發(fā)送 纟合4妻收方，如果不匹配則發(fā)送失敗的響應(yīng)消息，以保i正不會將DRM 保護(hù)的內(nèi)容發(fā)送到不支持DRM的終端上。
步驟7，經(jīng)過步驟6的判斷，MMSC向接收方發(fā)送相應(yīng)的獲取 響應(yīng)消息。步驟8，獲取響應(yīng)下發(fā)成功，則向發(fā)送方發(fā)送才殳遞報告消息。
步驟9， MMSC向DRM Server發(fā)送成功通知請求消息，以通 知彩信發(fā)送成功。
步艱《10， DRM Server向MMSC發(fā)送成功通知請求響應(yīng)消息， 流程結(jié)束。
裝置實(shí)施例
根據(jù)本發(fā)明的實(shí)施例，提供了一種MMSC,圖4是根據(jù)本發(fā)明 實(shí)施例的MMSC的結(jié)構(gòu)框圖，如圖4所示，該裝置包括第一4妾收 模塊42、鑒權(quán)模塊44、第二接收模塊46、判斷模塊48、發(fā)送才莫塊 40,下面對該結(jié)構(gòu)進(jìn)4于詳細(xì)的i兌明。
第一接收模塊42,用于接收來自發(fā)送方的彩信；鑒權(quán)模塊44 連接至第一接收模塊42,用于在確定彩信中包括DRM之后，通過 DRM Server進(jìn)行鑒權(quán)；第二接收模塊46連接至鑒權(quán)模塊44，用于 在鑒權(quán)成功之后接收來自接收方的用于獲取彩信的獲取請求消息； 判斷模塊48連接至第二接收模塊46,用于判斷接收方是否支持 DRM的保護(hù)方式；發(fā)送模塊40連接至判斷模塊48,用于在4妻收方 支持DRM的保護(hù)方式的情況下向接收方發(fā)送彩信。
圖5是根據(jù)本發(fā)明實(shí)施例的MMSC具體的結(jié)構(gòu)框圖，如圖5 所示，該MMSC還包括配置才莫塊52，該才莫塊用于配置的DRM能 力的集合，其中，DRM能力的集合包括每種類型的終端支持的 DRM的Y呆護(hù)方式。
判斷模塊48具體用于根據(jù)DRM能力的集合判斷作為接收方的 纟冬端是否支持DRM的^f呆護(hù)方式。綜上所述，本發(fā)明的上述實(shí)施例通過查詢獲得手機(jī)終端能力信
息，判斷手一幾是否支持DRM功能，編碼處理凄t字;l反權(quán)信息，乂人而 實(shí)現(xiàn)終端用戶通過彩信中心以彩信的形式來自由獲取所需要的帶有 版權(quán)信息的圖片，音頻等信息。本發(fā)明的上述實(shí)施例只需要在利用現(xiàn) 有彩信基本流程的基礎(chǔ)上，簡單的進(jìn)行改造，就可以實(shí)現(xiàn)。
顯然，本領(lǐng)域的技術(shù)人員應(yīng)該明白，上述的本發(fā)明的各才莫塊或 各步驟可以用通用的計(jì)算裝置來實(shí)現(xiàn)，它們可以集中在單個的i十算 裝置上，或者分布在多個計(jì)算裝置所組成的網(wǎng)絡(luò)上，可選地，它們 可以用計(jì)算裝置可4丸;f亍的程序代^碼來實(shí)現(xiàn)，從而，可以將它們存4諸
在存儲裝置中由計(jì)算裝置來執(zhí)行，或者將它們分別制作成各個集成
電路模塊，或者將它們中的多個模塊或步驟制作成單個集成電游，模
塊來實(shí)現(xiàn)。這樣，本發(fā)明不限制于任何特定的^^件和軟件結(jié)合。
以上所述僅為本發(fā)明的優(yōu)選實(shí)施例而已，并不用于限制本發(fā)明， 對于本領(lǐng)域的技術(shù)人員來說，本發(fā)明可以有各種更改和變化。凡在 本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進(jìn)等， 均應(yīng)包含在本發(fā)明的 <呆護(hù)范圍之內(nèi)。
權(quán)利要求
1.一種彩信處理方法，其特征在于，包括多媒體消息中心接收來自發(fā)送方的彩信，并在確定所述彩信中包括數(shù)字版權(quán)之后，通過數(shù)字版權(quán)服務(wù)器進(jìn)行鑒權(quán)；在鑒權(quán)成功之后，所述多媒體消息中心接收來自接收方的用于獲取所述彩信的獲取請求消息，并判斷所述接收方是否支持所述數(shù)字版權(quán)的保護(hù)方式；所述多媒體消息中心在所述接收方支持所述數(shù)字版權(quán)的保護(hù)方式的情況下向所述接收方發(fā)送所述彩信。
2. 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述多J 某體消息中 心判斷所述4妄收方是否支持所述ft字版權(quán)的保護(hù)方式包括所述多媒體消息中心從所述獲取請求消息中獲取所述接 收方的纟冬端的類型，才艮據(jù)預(yù)先配置的終端類型與該類型的纟冬端 是否支持lt字版權(quán)的保護(hù)方式的對應(yīng)關(guān)系，判斷所述的4姿收方 的終端是否支持所述數(shù)字版權(quán)的保護(hù)方式，其中，所述數(shù)字版 權(quán)能力的集合包括每種類型的終端支持的數(shù)字版權(quán)的保護(hù)方 式。
3. 根據(jù)權(quán)利要求1所述的方法，其特征在于，在所述多媒體消息 中心4妻收來自"l妻收方的所述獲取^青求消息之前，所述方法還包 括所述多媒體消息中心向所述接收方下發(fā)通告消息；所述接收方在接收到所述通告消息后，向所述多媒體消息 中心發(fā)送所述獲取請求消息。
4. 4艮據(jù)權(quán)利要求1所述的方法，其特4正在于，通過所述凄丈字X反^又服務(wù)器進(jìn)行鑒權(quán)包括所述多媒體消息中心向所述數(shù)字版權(quán)服務(wù)器發(fā)送鑒權(quán)請 求消息；所述數(shù)字版權(quán)服務(wù)器對所述數(shù)字版權(quán)進(jìn)行鑒權(quán)。
5. 根據(jù)權(quán)利要求1所述的方法，其特征在于，在確定所述彩信中 包括所述數(shù)字版權(quán)之后，所述方法還包括所述多媒體消息中心獲取并保存所述數(shù)字版權(quán)的信息，其 中，所述數(shù)字版權(quán)的信息包括所述數(shù)字版權(quán)的保護(hù)方式。
6. 根據(jù)權(quán)利要求5所述的方法，其特征在于，在所述多媒體消息 中心接收來自所述彩信之前，所述方法還包括所述發(fā)送方向所述多媒體消息中心發(fā)送所述彩信，其中， 所述彩信的內(nèi)容類型字段中所述凄t字版4又的保護(hù)方式。
7. 才艮據(jù)權(quán)利要求1至6中任一項(xiàng)所述的方法，其特4i在于，在所 述多媒體消息中心向所述接收方發(fā)送所述獲取響應(yīng)消息之后， 所述方法還包括所述多々某體消息中心向所述凄t字版^J良務(wù)器發(fā)送用于的 消息，其中，所述消息用于指示所述彩信發(fā)送成功。
8. 根據(jù)權(quán)利要求1至6中任一項(xiàng)所述的方法，其特征在于，在所 述接收方不支持所述lt字版纟又的保護(hù)方式的情況下，所述方法 還包括所述多媒體消息中心向所述接收方發(fā)送失敗的響應(yīng)消息， 并且不向所述4妻收方發(fā)送所述彩信。
9. 一種多J 某體消息中心，其特征在于，包括第一接收才莫塊，用于接收來自發(fā)送方的彩信；鑒權(quán)模塊，用于在確定所述彩信中包括數(shù)字版權(quán)之后，通 過數(shù)字版權(quán)服務(wù)器進(jìn)行鑒權(quán)；第二接收模塊，用于在鑒權(quán)成功之后接收來自接收方的用 于獲取所述彩信的獲取請求消息；判斷模塊，用于判斷所述接收方是否支持所述數(shù)字版權(quán)的 保護(hù)方式；發(fā)送模塊，用于在所述接收方支持所述數(shù)字版權(quán)的保護(hù)方 式的情況下向所述接收方發(fā)送所述彩信。
10. 根據(jù)權(quán)利要求9所述的多媒體消息中心，其特征在于，還包括配置模塊，用于配置的數(shù)字版權(quán)能力的集合，其中，所述 數(shù)字版權(quán)能力的集合包括每種類型的終端支持的數(shù)字版權(quán)的 保護(hù)方式；所述判斷才莫塊具體用于根據(jù)所述數(shù)字版權(quán)能力的集合判 斷作為所述接收方的終端是否支持所述數(shù)字版權(quán)的保護(hù)方式。
全文摘要
本發(fā)明公開了一種彩信處理方法及多媒體消息中心，該方法包括多媒體消息中心接收來自發(fā)送方的彩信，并在確定彩信中包括數(shù)字版權(quán)之后，通過數(shù)字版權(quán)服務(wù)器進(jìn)行鑒權(quán)；在鑒權(quán)成功之后，多媒體消息中心接收來自接收方的用于獲取彩信的獲取請求消息，并判斷接收方是否支持?jǐn)?shù)字版權(quán)的保護(hù)方式；多媒體消息中心在接收方支持?jǐn)?shù)字版權(quán)的保護(hù)方式的情況下向接收方發(fā)送彩信。通過本發(fā)明使彩信中心有處理DRM信息以及判斷終端手機(jī)是否支持DRM的能力，實(shí)現(xiàn)了DRM版權(quán)信息通過彩信系統(tǒng)進(jìn)行收發(fā)。
文檔編號H04W4/12GK101631288SQ20091016629
公開日2010年1月20日 申請日期2009年8月18日 優(yōu)先權(quán)日2009年8月18日
發(fā)明者丹 李 申請人:中興通訊股份有限公司