專利名稱：面向多播業(yè)務(wù)的oma drm移動(dòng)流媒體版權(quán)管理系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及面向多播業(yè)務(wù)的移動(dòng)流媒體數(shù)字版權(quán)管理系統(tǒng)，主要是在兼容OMA (開(kāi)放移 動(dòng)聯(lián)盟)制定的DRM2.0標(biāo)準(zhǔn)的基礎(chǔ)上，采用多層加密、視頻水印認(rèn)證、邏輯分組等機(jī)制， 提供針對(duì)移動(dòng)多播流媒體業(yè)務(wù)的數(shù)字版權(quán)管理功能。
背景技術(shù)：
流媒體具有邊下載、邊播放的特征，無(wú)需用戶完整下載媒體數(shù)據(jù)，顯著降低了用戶播放 等待時(shí)間，移動(dòng)流媒體業(yè)務(wù)已經(jīng)成為移動(dòng)運(yùn)營(yíng)商最為重要的增值數(shù)據(jù)業(yè)務(wù)之一。多播作為傳 輸流媒體數(shù)據(jù)的一種重要方式，具有節(jié)省網(wǎng)絡(luò)帶寬等優(yōu)點(diǎn)，能夠以更低的成本支持成千上萬(wàn) 個(gè)用戶，己經(jīng)成為流媒體業(yè)務(wù)的主要應(yīng)用模式之一。
對(duì)移動(dòng)流媒體內(nèi)容的版權(quán)保護(hù)，確保媒體內(nèi)容在移動(dòng)互聯(lián)網(wǎng)的合法傳播，保護(hù)移動(dòng)視頻 內(nèi)容提供商和移動(dòng)運(yùn)營(yíng)商的合法利益，己成為第三代移動(dòng)通信實(shí)施和業(yè)務(wù)開(kāi)展中主要關(guān)注的 問(wèn)題。
OMA組織先后制定了 DRM1.0標(biāo)準(zhǔn)和DRM2.0標(biāo)準(zhǔn)。其中DRM 2.0規(guī)范作為較為完 善的移動(dòng)數(shù)字版權(quán)管理解決方案已成為近期國(guó)內(nèi)外針對(duì)移動(dòng)設(shè)備最主要的數(shù)字版權(quán)管理解決 方案。OMADRM2.0規(guī)范簡(jiǎn)單描述了流媒體應(yīng)用場(chǎng)景，與其他流媒體版權(quán)管理解決方案類似， 未明確給出針對(duì)多播流媒體業(yè)務(wù)的解決方案，默認(rèn)采用在流媒體多播傳輸過(guò)程中使用唯一不 變的內(nèi)容加密密鑰，存在著在較長(zhǎng)的流媒體傳輸時(shí)間段內(nèi)密鑰可能被多個(gè)多播接收者共享的 嚴(yán)重安全問(wèn)題。其他采用多層加密體系的內(nèi)容保護(hù)方案如條件接收主要考慮了廣播式或單播 式業(yè)務(wù)，無(wú)法直接應(yīng)用于多播業(yè)務(wù)。

發(fā)明內(nèi)容
本發(fā)明的目的在于針對(duì)需要進(jìn)行版權(quán)管理和內(nèi)容保護(hù)的移動(dòng)多播流媒體業(yè)務(wù)，提出一
種完全兼容OMADRM 2.0標(biāo)準(zhǔn)，增強(qiáng)了內(nèi)容保護(hù)能力和安全性的數(shù)字版權(quán)管理系統(tǒng)，并提 供了對(duì)流媒體內(nèi)容和密鑰信息在多播傳輸過(guò)程是否遭到攻擊進(jìn)行檢査的功能。
實(shí)現(xiàn)本發(fā)明目的的技術(shù)解決方案為面向多播業(yè)務(wù)的OMADRM移動(dòng)流媒體版權(quán)管理系 統(tǒng)，該系統(tǒng)由服務(wù)器端和多個(gè)客戶端組成。服務(wù)器端主要由內(nèi)容分發(fā)服務(wù)器和版權(quán)分發(fā)服務(wù) 器構(gòu)成，為支持多播流媒體業(yè)務(wù)，將內(nèi)容分發(fā)服務(wù)器分為Web服務(wù)器、流媒體服務(wù)器和數(shù)據(jù) 打包服務(wù)器三個(gè)邏輯子系統(tǒng)，而將版權(quán)分發(fā)服務(wù)器分為密鑰管理、版權(quán)對(duì)象生成和ROAP協(xié)議服務(wù)器三個(gè)邏輯子系統(tǒng)。
該解決方案的基本思想是完全基于OMA DRM 2.0規(guī)范，采用針對(duì)多播流媒體業(yè)務(wù)的二 層時(shí)變加密機(jī)制(變換周期20秒)，利用視頻水印認(rèn)證技術(shù)攜帶二次加密內(nèi)容密鑰的數(shù)字摘 要，達(dá)到對(duì)多播傳輸?shù)耐暾院驼_性進(jìn)行驗(yàn)證的目的。為減少傳輸二次加密內(nèi)容密鑰消耗 的帶寬，提出邏輯分組機(jī)制，將多個(gè)多播接收者分成最多20個(gè)邏輯組。
典型的應(yīng)用場(chǎng)景和交互流程由以下步驟組成(如圖1所示)
1) 內(nèi)容分發(fā)服務(wù)器CI中的流媒體服務(wù)器向Web服務(wù)器和版權(quán)分發(fā)服務(wù)器RI傳遞多播流 標(biāo)記，并指明該流僅支持多播傳輸模式(箭頭l所示)；
2) 客戶端瀏覽Web服務(wù)器，與Web服務(wù)器交互下載感興趣的多播流標(biāo)記，同時(shí)可以選 擇合適的支付方式(箭頭2所示)；
3) 客戶端從多播流標(biāo)記中獲取對(duì)應(yīng)版權(quán)分發(fā)服務(wù)器的地址，并通過(guò)版權(quán)對(duì)象獲取協(xié)議 ROAP向該服務(wù)器注冊(cè)并請(qǐng)求版權(quán)對(duì)象(箭頭3所示)；
4) 版權(quán)分發(fā)服務(wù)器RI中的ROAP協(xié)議服務(wù)器向密鑰管理模塊和版權(quán)對(duì)象生成器傳遞用 戶及其訂購(gòu)信息(箭頭4所示)；
5) 版權(quán)分發(fā)服務(wù)器R1中的密鑰管理模塊為此多播媒體流產(chǎn)生對(duì)應(yīng)的20個(gè)內(nèi)容加密二層 密鑰，每個(gè)分別對(duì)應(yīng)一個(gè)邏輯組，并將20個(gè)密鑰發(fā)布給CI的數(shù)據(jù)打包服務(wù)器和RI的版權(quán)對(duì) 象生成模塊(箭頭5所示)；
6) 版權(quán)分發(fā)服務(wù)器RI中的版權(quán)對(duì)象生成模塊為第一個(gè)訂購(gòu)多播流的用戶生成包含第1 邏輯組對(duì)應(yīng)的內(nèi)容加密二層密鑰的版權(quán)對(duì)象，分配該用戶到第1個(gè)邏輯組，并將版權(quán)對(duì)象和 用戶所屬邏輯組編號(hào)發(fā)布給ROAP協(xié)議服務(wù)器(箭頭6所示)；
7) 版權(quán)分發(fā)服務(wù)器RI中的ROAP協(xié)議服務(wù)器基于ROAP協(xié)議向客戶端發(fā)送包含版權(quán)對(duì) 象的響應(yīng)，并通知該用戶，其邏輯組編號(hào)為第l個(gè)(箭頭7所示)；
8) 客戶端存儲(chǔ)收到的版權(quán)對(duì)象及邏輯組標(biāo)號(hào)，然后向流媒體服務(wù)器請(qǐng)求流媒體數(shù)據(jù)(箭 頭8所示)；
9) 內(nèi)容分發(fā)服務(wù)器CI中的數(shù)據(jù)打包服務(wù)器采用后面即將給出的水印嵌入、內(nèi)容時(shí)變加 密和PDCF打包處理過(guò)程，對(duì)多播媒體數(shù)據(jù)進(jìn)行處理后，傳遞給流媒體服務(wù)器(箭頭9所示)；
10) 流媒體服務(wù)器向客戶端以多播流化傳輸方式發(fā)送加密打包后的媒體數(shù)據(jù)，客戶端根 據(jù)后面即將給出的PDCF解封包、內(nèi)容解密和水印提取處理過(guò)程進(jìn)行相應(yīng)的處理(箭頭0所 示)。
以上為首個(gè)客戶端加入多播業(yè)務(wù)流的處理流程，以下是其后其它客戶端加入多播業(yè)務(wù)流的系統(tǒng)處理流程，這是本發(fā)明的核心內(nèi)容之一。
11) 客戶端瀏覽Web服務(wù)器，與Web服務(wù)器交互下載感興趣的多播流標(biāo)記，同時(shí)可以選 擇合適的支付方式(箭頭ll所示)；
12) 客戶端從多播流標(biāo)記中獲取對(duì)應(yīng)RI的地址，并通過(guò)版權(quán)對(duì)象獲取協(xié)議ROAP向該服 務(wù)器注冊(cè)并請(qǐng)求版權(quán)對(duì)象(箭頭12所示)；
13) ROAP協(xié)議服務(wù)器向密鑰管理模塊和版權(quán)對(duì)象生成器傳遞用戶及其訂購(gòu)信息(箭頭 13所示)；
14) 版權(quán)對(duì)象生成模塊執(zhí)行后面給出的多播用戶邏輯分組機(jī)制，為該客戶端分配合適的 邏輯組，生成包含該邏輯組對(duì)應(yīng)的內(nèi)容加密二層密鑰的版權(quán)對(duì)象，并將版權(quán)對(duì)象和用戶所屬 邏輯組編號(hào)發(fā)布給ROAP協(xié)議服務(wù)器(箭頭M所示)；
15) ROAP協(xié)議服務(wù)器基于ROAP協(xié)議向客戶端發(fā)送包含版權(quán)對(duì)象的響應(yīng)，并通知該用 戶其對(duì)應(yīng)的邏輯組編號(hào)(箭頭15所示)；。
16) 客戶端申請(qǐng)加入對(duì)應(yīng)的多播業(yè)務(wù)流，并根據(jù)后面即將給出的PDCF解封包、內(nèi)容解 密和水印提取處理過(guò)程進(jìn)行相應(yīng)的處理(箭頭16所示)。


圖1系統(tǒng)處理流程
圖2服務(wù)器端多播用戶分組處理過(guò)程
圖3服務(wù)器端媒體數(shù)據(jù)加密打包過(guò)程
圖4客戶端媒體數(shù)據(jù)解封包解密過(guò)程
圖5水印序列結(jié)構(gòu)
圖6 二次加密多播內(nèi)容密鑰序列
圖7水印嵌入過(guò)程
圖8水印提取過(guò)程
圖9水印移除過(guò)程
具體實(shí)施例方式
1)服務(wù)器端多播用戶邏輯分組處理過(guò)程
多播用戶的邏輯分組處理是本發(fā)明的核心內(nèi)容之一，通過(guò)邏輯分組機(jī)制，避免為每個(gè)多 播用戶分配不同的內(nèi)容加密二層密鑰，降低了傳輸多個(gè)二次加密后的內(nèi)容密鑰及其摘要所產(chǎn) 生的帶寬消耗，提供了對(duì)大量多播用戶的有效支持。而有效的邏輯分組策略對(duì)有效防止多個(gè) 多播接收者共享內(nèi)容加密密鑰具有非常關(guān)鍵的作用。具體處理過(guò)程(見(jiàn)附圖2)如下-① 服務(wù)器獲取新加入用戶的信息，如果當(dāng)前多播接收者的個(gè)數(shù)小于20個(gè)，則將該多播 接收者分配到一個(gè)沒(méi)有其他多播接收者的邏輯組；否則轉(zhuǎn)到步驟2;
② 根據(jù)數(shù)據(jù)庫(kù)中的多播接收者對(duì)應(yīng)的用戶信息，盡可能將地理位置等特征具有顯著差別 的用戶分配在同一個(gè)邏輯組，以有效防止同一邏輯組內(nèi)的多個(gè)用戶間進(jìn)行內(nèi)容加密密 鑰的共享。
需要指出的是，對(duì)于目前的移動(dòng)運(yùn)營(yíng)商/增值服務(wù)商來(lái)說(shuō)，通常獲取移動(dòng)用戶的某些特征 信息是比較方便的，這為上述策略的實(shí)現(xiàn)提供了基礎(chǔ)。
2) 服務(wù)器端媒體數(shù)據(jù)加密打包過(guò)程
數(shù)據(jù)打包服務(wù)器對(duì)水印嵌入、媒體數(shù)據(jù)的加密和PDCF打包的處理過(guò)程為(見(jiàn)附圖3):
① 每隔20秒生成一個(gè)新的128位內(nèi)容密鑰，基于RI指定的20個(gè)內(nèi)容加密二層密鑰采 用128位的AES加密算法對(duì)內(nèi)容密鑰進(jìn)行加密，形成20個(gè)長(zhǎng)度為128位二次加密后 的內(nèi)容密鑰(箭頭l所示)；
② 采用MD5算法對(duì)20個(gè)長(zhǎng)度為128位二次加密后的內(nèi)容密鑰進(jìn)行摘要運(yùn)算，形成一個(gè) 128位二次加密后密鑰的摘要(箭頭2所示)；
③ 按照?qǐng)D5所示的結(jié)構(gòu)，基于128位二次加密后密鑰的摘要產(chǎn)生136位的水印序列結(jié)構(gòu)， 其中8位起始標(biāo)識(shí)為0xA7 (主要用于水印信息的起始位置同步)，然后采用水印嵌入 算法將水印序列嵌入到原始媒體數(shù)據(jù)內(nèi)(箭頭3所示)；
④ 使用當(dāng)前的內(nèi)容加密密鑰，對(duì)加入水印后的媒體數(shù)據(jù)進(jìn)行128位AES加密，生成加 密后的媒體數(shù)據(jù)(箭頭4所示)；
◎?qū)?0個(gè)長(zhǎng)度為128位二次加密后的內(nèi)容密鑰組成如圖6所示的比特序列，并與加密 后的媒體數(shù)據(jù)一起封裝在PDCF數(shù)據(jù)包中，形成可以流化傳輸?shù)拿襟w數(shù)據(jù)(箭頭5所 示)。
水印嵌入算法采用簡(jiǎn)單的可移除水印機(jī)制， 一方面可以起到多播傳輸認(rèn)證和數(shù)字簽名的 作用，另一方面便于在接收端去除水印，消除嵌入水印對(duì)媒體質(zhì)量的負(fù)面影響。具體處理過(guò) 程如圖7所示
① 從原始音視頻媒體數(shù)據(jù)中的視頻數(shù)據(jù)中提取出運(yùn)動(dòng)矢量(箭頭1所示)；
② 將運(yùn)動(dòng)矢量的水平分量值乘以2，使其最低有效位LSB為O (箭頭2所示)；
③ 將水印序列按比特次序順序放置在各個(gè)運(yùn)動(dòng)矢量水平分量的LSB，產(chǎn)生含水印信息的 音視頻數(shù)據(jù)(箭頭3所示)。
3) 客戶端媒體數(shù)據(jù)解封包解密過(guò)程客戶端對(duì)PDCF解封裝、媒體數(shù)據(jù)解密、水印提取和移除的處理過(guò)程為(見(jiàn)附圖4):
① 客戶端在收到版權(quán)對(duì)象后，進(jìn)行解析，獲得長(zhǎng)度為128比特的內(nèi)容加密二層密鑰(箭 頭1所示)；
② 從收到的加密打包媒體數(shù)據(jù)中通過(guò)PDCF格式解析分離出20組長(zhǎng)度為128比特的二 次加密后的內(nèi)容密鑰(如果存在的話)和加密的媒體數(shù)據(jù)(箭頭2所示)；
③ 客戶端根據(jù)本地存儲(chǔ)的邏輯組編號(hào)，從20組長(zhǎng)度為128比特的二次加密后的內(nèi)容密 鑰提取出所屬邏輯組對(duì)應(yīng)的、二次加密后的內(nèi)容密鑰(箭頭3所示)；
④ 利用內(nèi)容加密二層密鑰對(duì)所屬邏輯組對(duì)應(yīng)的、二次加密后的內(nèi)容密鑰進(jìn)行AES解密獲 得128位的內(nèi)容解密密鑰(箭頭4所示)；
⑤ 利用上一步獲得的內(nèi)容解密密鑰對(duì)加密的媒體數(shù)據(jù)進(jìn)行解密，獲取攜帶水印信息的媒 體數(shù)據(jù)(箭頭5所示)；
進(jìn)行水印提取和移除操作，獲取對(duì)應(yīng)的原始媒體數(shù)據(jù)和包含密鑰摘要的水印序列(箭
頭6所示)；
⑦ 采用MD5算法對(duì)20組長(zhǎng)度為128比特的二次加密后的內(nèi)容密鑰進(jìn)行摘要運(yùn)算，得到 本地計(jì)算出的摘要(箭頭7所示)；
⑧ 將水印序列中的摘要與本地計(jì)算的摘要值進(jìn)行比較，如果兩者相同，則對(duì)原始媒體數(shù) 據(jù)進(jìn)行解碼和播放；否則停止以后20秒之內(nèi)的多媒體內(nèi)容播放，以保證多播傳輸過(guò) 程中數(shù)據(jù)的完整性和正確性(箭頭8所示)。
水印提取操作的具體處理過(guò)程如圖8所示
① 從含水印信息的音視頻數(shù)據(jù)的視頻數(shù)據(jù)中提取出運(yùn)動(dòng)矢量(箭頭l所示)；
② 按順序獲取運(yùn)動(dòng)矢量水平分量的LSB作為水印序列的1個(gè)比特，多個(gè)比特形成客戶端 本地提取出的水印序列(箭頭2所示)。
水印移除操作的具體處理過(guò)程如圖9所示
① 從含水印信息的音視頻數(shù)據(jù)的視頻數(shù)據(jù)中提取出運(yùn)動(dòng)矢量(箭頭l所示)；
② 將運(yùn)動(dòng)矢量水平分量值除以2，并舍去小數(shù)部分，恢復(fù)為原始的運(yùn)動(dòng)矢量值，獲得原 始的音視頻媒體數(shù)據(jù)(箭頭2所示)。
本發(fā)明的主要特點(diǎn)
本發(fā)明的面向多播業(yè)務(wù)的OMA DRM移動(dòng)流媒體版權(quán)管理系統(tǒng)提供了 OMA DRM2.0標(biāo) 準(zhǔn)和其它時(shí)變內(nèi)容加密方案如條件接收系統(tǒng)涉及較少的針對(duì)多播業(yè)務(wù)的版權(quán)管理和內(nèi)容保護(hù) 解決方案，其顯著優(yōu)點(diǎn)是1) 相對(duì)于OMA DRM2.0規(guī)范和其它時(shí)變內(nèi)容加密方案如條件接收，提供了完全兼容 OMADRM2.0標(biāo)準(zhǔn)、針對(duì)多播業(yè)務(wù)、較為完整的解決方案，為移動(dòng)多播流媒體業(yè)務(wù)在第三代 移動(dòng)通信系統(tǒng)中廣泛應(yīng)用提供了內(nèi)容保護(hù)方面的技術(shù)支撐；
2) 提出了多播接收者邏輯分組策略，降低了傳輸多個(gè)二次加密后的內(nèi)容密鑰的帶寬消 耗，提供了對(duì)大量并發(fā)多播用戶的有效支持。充分利用已有移動(dòng)用戶信息，有效防止同一邏 輯組內(nèi)的多個(gè)多播接收者共享內(nèi)容加密密鑰；
3) 采用MD5摘要算法和視頻水印認(rèn)證技術(shù)，提供了對(duì)多播傳輸過(guò)程中數(shù)據(jù)完整性和正 確性的有效驗(yàn)證；
4) 本系統(tǒng)將可移除水印序列嵌入到原始視頻數(shù)據(jù)的運(yùn)動(dòng)矢量中，服務(wù)器與客戶端的水印 相關(guān)操作復(fù)雜度低，能夠廣泛應(yīng)用于多種視頻壓縮標(biāo)準(zhǔn)如MPEG-l/2/4、 H.263和H.264，具 有較高的通用性，并消除了水印嵌入可能造成的視頻質(zhì)量下降。
權(quán)利要求
1、一個(gè)面向多播業(yè)務(wù)的OMA DRM移動(dòng)流媒體版權(quán)管理系統(tǒng)，其特征在于在完全兼容OMADRM 2.0標(biāo)準(zhǔn)基礎(chǔ)上，采用多播接收者邏輯分組機(jī)制，將多播接收者分配到不同的邏輯組中；版權(quán)分發(fā)服務(wù)器RI為一個(gè)多播媒體流分配與邏輯組數(shù)相同的多個(gè)二層密鑰，并為申請(qǐng)加入多播媒體流的DRM客戶端分配指定的邏輯組編號(hào)及該邏輯組對(duì)應(yīng)的二層密鑰；內(nèi)容分發(fā)服務(wù)器CI使用時(shí)變的內(nèi)容加密密鑰對(duì)多播流媒體數(shù)據(jù)進(jìn)行加密，并使用RI指定的多個(gè)二層密鑰對(duì)內(nèi)容密鑰分別進(jìn)行加密后與加密后的媒體數(shù)據(jù)一起放在PDCF包中傳輸，彌補(bǔ)了目前OMA DRM2.0標(biāo)準(zhǔn)尚無(wú)針對(duì)多播流媒體業(yè)務(wù)的解決方案的不足，增強(qiáng)流媒體版權(quán)管理系統(tǒng)的多播內(nèi)容安全性。
2、 根據(jù)權(quán)利l所述的面向多播業(yè)務(wù)的二層內(nèi)容加密和多播接收者邏輯分組機(jī)制，其特征 是多播接收者加入多播業(yè)務(wù)的交互流程。
3、 根據(jù)權(quán)利l所述的多播接收者邏輯分組機(jī)制，其特征是版權(quán)分發(fā)服務(wù)器對(duì)申請(qǐng)加入 多播業(yè)務(wù)的用戶進(jìn)行邏輯分組的處理流程。
4、 根據(jù)權(quán)利l所述的面向多播業(yè)務(wù)的二層內(nèi)容加密機(jī)制，其特征是使用MD5數(shù)字摘要 算法對(duì)多個(gè)二層密鑰對(duì)內(nèi)容密鑰加密后形成的多個(gè)二次加密內(nèi)容密鑰進(jìn)行摘要運(yùn)算，并通過(guò) 可移除水印技術(shù)將摘要信息嵌入到多媒體的視頻數(shù)據(jù)中，保證多個(gè)二次加密內(nèi)容密鑰在多播 傳輸過(guò)程中的完整性和正確性，完成流媒體多播傳輸?shù)恼J(rèn)證。
5、 根據(jù)權(quán)利4所述的攜帶二次加密內(nèi)容密鑰的數(shù)字摘要的可移除水印機(jī)制，其特征是 基于運(yùn)動(dòng)矢量、具有較高通用性的可移除視頻水印的嵌入和提取及移除方法。
全文摘要
本發(fā)明涉及面向多播業(yè)務(wù)的移動(dòng)流媒體數(shù)字版權(quán)管理系統(tǒng)，兼容OMA DRM 2.0標(biāo)準(zhǔn)，采用了多層加密、視頻水印認(rèn)證、邏輯分組等機(jī)制。服務(wù)器端多播用戶邏輯分組機(jī)制和客戶端加入多播業(yè)務(wù)流的系統(tǒng)處理流程是其關(guān)鍵內(nèi)容。其優(yōu)點(diǎn)是1)兼容OMA DRM 2.0，為移動(dòng)多播流媒體業(yè)務(wù)在第三代移動(dòng)通信系統(tǒng)中的廣泛應(yīng)用提供了內(nèi)容保護(hù)方面的解決方案；2)提出了多播接收者邏輯分組策略，降低了傳輸多個(gè)二次加密后的內(nèi)容密鑰的帶寬消耗，提供了對(duì)大并發(fā)用戶的支持；3)采用MD5摘要算法和視頻水印認(rèn)證技術(shù)，提供了對(duì)多播傳輸過(guò)程中數(shù)據(jù)完整性和正確性的驗(yàn)證；4)將可移除水印序列嵌入到原始視頻數(shù)據(jù)的運(yùn)動(dòng)矢量中，水印相關(guān)操作復(fù)雜度低，并消除了水印嵌入可能造成的視頻質(zhì)量下降。
文檔編號(hào)H04L12/56GK101567779SQ20081010464
公開(kāi)日2009年10月28日 申請(qǐng)日期2008年4月22日 優(yōu)先權(quán)日2008年4月22日
發(fā)明者鄭 姚, 鋒 張, 張寶賢, 壯 趙, 雪 高, 奎 黃 申請(qǐng)人:北京銀易通網(wǎng)絡(luò)科技有限公司