專利名稱：一種部署客戶端應用的終端、系統(tǒng)及方法
技術領域：
本發(fā)明涉及通信領域，特別涉及一種在移動終端上部署客戶端應用 的終端、系統(tǒng)及方法。
背景技術：
目前，移動終端上移動通信業(yè)務主要通過使用各個操作系統(tǒng)平臺所
提供的應用編程接口 ( API )進行開發(fā)。由于各個操作系統(tǒng)平臺差異性很 大，因此一個應用或業(yè)務需要針對不同的操作系統(tǒng)平臺開發(fā)多個版本。 以中國移動的飛信手機客戶端為例，截至2008年1月，中國移動的飛信 手才幾客戶端，已經(jīng)有173款，覆蓋Java、 Windows Mobile、 Symbian等 平臺，但仍僅支持銷售市場上30%左右的終端?？蛻舳藨玫拈_發(fā)基于 各個平臺提供的應用編程接口。因此，應用程序?qū)Σ僮飨到y(tǒng)平臺的依賴 性非常大，而且用戶界面開發(fā)比較復雜，難度較大。 傳統(tǒng)的應用程序框架
主流的移動終端智能搮:作系統(tǒng)，如Symbian, Windows Mobile或者 Linux, —般會為開發(fā)者提供SDK API,應用控件，開發(fā)者可以使用這些 API,控件開發(fā)各種應用。但是，這些API、控件都是依賴于操作系統(tǒng)， 也就是說開發(fā)者需要根據(jù)不同的操作系統(tǒng)為 一個應用開發(fā)不同的版本。
下面以目前主流手機智能平臺之一Symbian S60為例，簡單介紹基
于該平臺的應用程序框架。
如圖1所示，S60應用程序的運行依賴于大量的操作系統(tǒng)組件，例 如屏幕繪圖和應用程序數(shù)據(jù)持久性等，使用操作系統(tǒng)的窗口服務器或者 文件服務器。
應用程序框架由一套核心類組成，這些類是所有應用程序框架的基 礎。這些類組成了所有應用程序的架構(gòu)，并且它們也封裝了應用程序和 所需OS服務器之間的相互作用。
5第一層包含兩個基本組件AppArc和C0NE。 AppArc代表"應用 程序架構(gòu)"，這些類提供了基本的應用程序結(jié)構(gòu)、將系統(tǒng)信息提交到應用 程序的機制，以及使用文件服務器持久化數(shù)據(jù)。CONE是控制環(huán)境的縮寫， 在這個組件中的類提供用于處理用戶輸入并創(chuàng)建用戶界面的機制- -這 些類主要用于和窗口服務器進行交互。這一層中的許多類都是抽象類， 僅僅定義了一個API的接口。
第二層Uikon組件這是具有豐富功能、非抽象框架類的一般性 設備無關實現(xiàn)，并且提供了一個在所有symbian OS上公用的UI庫層。 一些具體的UI控件(比如列表框和滾動條等)都可以在該層創(chuàng)建，這些 控件有時也被稱為Eikon控件。
第三層由Avkon類組成，這些類提供了核心的S60 UI功能，例如 菜單支持。
第四層針對應用程序的層，設計自己的應用程序，添加自定義應 用程序?qū)崿F(xiàn)。
因此，對于應用程序而言，無論是用戶界面還是應用功能的實現(xiàn)， 都緊密依賴于操作系統(tǒng)。
現(xiàn)有移動終端上客戶端應用實現(xiàn)方法的缺點
(1) 客戶端應用中的用戶界面和業(yè)務功能模塊緊耦合，如果需要更 新用戶界面，則需要開發(fā)者重新修改、編譯代碼，用戶需要下載、升級 和安裝整個新的客戶端軟件，復雜度高，難度大；
(2) 同一客戶端應用需要針對不同的操作系統(tǒng)開發(fā)單獨的版本，開 發(fā)成本高、難度大；客戶端應用的用戶界面的實現(xiàn)依賴于操作系統(tǒng)平臺；
(3 )各個客戶端應用直接相對獨立，各自提供的能力不能靈活復用； (4 )開發(fā)者根據(jù)移動終端操作系統(tǒng)平臺所提供的應用編程接口進行 用戶界面開發(fā)，客戶端應用的用戶界面開發(fā)復雜
發(fā)明內(nèi)容
、、 、門 、、"、 、乂 ，、、 n 、人
操作系統(tǒng)平臺，用戶界面和業(yè)務功能模塊緊耦合，如果需要更新用戶界 面，開發(fā)者需要重新修改、編譯代碼，用戶需要下載、升級和安裝整個 新的客戶端軟件的問題，提供一種部署客戶端應用的終端、系統(tǒng)和方法，以實現(xiàn)用戶界面開發(fā)簡單、降低開發(fā)成本。
本發(fā)明的目的是針對現(xiàn)有技術中各個客戶端應用相對獨立、各自提供的能力不能靈活應用的缺陷，提供一種在移動終端上部署客戶端應用的終端、系統(tǒng)和方法，以實現(xiàn)在移動終端上快速部署、更新應用。
為了實現(xiàn)以上目的，本發(fā)明提供了一種部署客戶端應用的方法，包
括以下步驟將界面客戶端存儲于內(nèi)容管理器中；將應用模塊動態(tài)加載于應用插件容器中；內(nèi)容管理器與應用插件容器相互獨立。
在上述的技術方案中，包括將內(nèi)容管理器和應用插件容器設置于內(nèi)部服務器中；內(nèi)容管理器中存儲的界面客戶端通過瀏覽器呈現(xiàn)；將請求處理器和應用模塊管理器設置于內(nèi)部服務器中。
在上述的技術方案中，界面客戶端包括Web網(wǎng)頁形式的應用用戶界面客戶端、應用管理界面客戶端和/或與網(wǎng)絡側(cè)應用服務器同步部署在內(nèi)部服務器的應用模塊的應用界面客戶端。
在上述的技術方案中，瀏覽器通過HTTP協(xié)議與內(nèi)部服務器進行通信。
在上述的技術方案中，應用模塊的動態(tài)加載包括在可執(zhí)行文件啟動時由系統(tǒng)程序自動加載；和/或在可執(zhí)行程序中手動通過操作系統(tǒng)加載器的系統(tǒng)接口進行加載。
在上述的技術方案中，界面客戶端采用Web、 Widget或Flash技術通過瀏覽器實現(xiàn)跨平臺的界面呈現(xiàn)。
本發(fā)明還提供了一種部署客戶端應用的終端，包括內(nèi)容管理器，用于存儲各種形式的界面客戶端，界面客戶端通過瀏覽器呈現(xiàn)；應用插件容器，用于支持具體應用模塊的動態(tài)加載，對接收的訪問請求進行解析、處理，將訪問請求的處理結(jié)果返回至請求處理器；內(nèi)容管理器與所述應用插件容器相互獨立。
在上述的技術方案中，內(nèi)容管理器和應用插件容器設置于內(nèi)部服務器中，所述內(nèi)部服務器還包括請求處理器和應用模塊管理器請求處理器，用于監(jiān)聽訪問請求，分發(fā)接收到的訪問請求，并將所述訪問請求的處理結(jié)果返回至所述界面客戶端；應用模塊管理器，用于對具體的應用模塊進行加載、升級及工作狀態(tài)查詢。在上述的技術方案中，請求處理器包括守護進程模塊，用于接收用戶的訪問請求；請求分發(fā)器，用于對接收到的訪問請求進行解析，將解析后的訪問請求分發(fā)到對應的內(nèi)容管理器或應用插件容器。
在上述的技術方案中，請求分發(fā)器包括判斷子模塊，用于判斷訪問請求的類型，包括用戶界面訪問請求或應用邏輯處理訪問請求；分發(fā)子模塊，用于將用戶界面訪問請求分發(fā)到內(nèi)容管理器進行后續(xù)處理，并接收對應的處理結(jié)果；將應用邏輯處理訪問請求分發(fā)到應用插件容器的具體應用模塊，并接收對應應用模塊的處理結(jié)果。
本發(fā)明還提供了 一種部署客戶端應用的系統(tǒng)，包括上述任一終端，還包括與終端通信的應用服務器，用于將應用服務器內(nèi)的服務推送至終端的內(nèi)部服務器。
本發(fā)明提供的終端、系統(tǒng)和方法，有效的解決了上述現(xiàn)有技術中存在的問題，實現(xiàn)了內(nèi)容管理器和應用插件容器的分離，并設置于內(nèi)部服務器中；客戶端應用的用戶界面實現(xiàn)與才喿作系統(tǒng)無關，同時提供了標準的訪問接口，為技術融合作了準備。


圖l是背景技術中S60應用程序框架圖；圖2是本發(fā)明實施例一部署客戶端應用方法的流程圖；圖3是本發(fā)明實施例二部署客戶端應用的終端架構(gòu)圖；圖4是本發(fā)明實施例二部署客戶端應用的終端中的應用插件容器示意圖5是本發(fā)明實施例二部署客戶端應用的所述終端系統(tǒng)模塊數(shù)據(jù)流向圖。
具體實施例方式
下面結(jié)合附圖，對本發(fā)明的具體實施方式
進行詳細描述。
如圖1所示，本發(fā)明實施例一公開了一種部署客戶端應用的方法，
具體包括以下步驟
步驟S102,將界面客戶端存儲于內(nèi)容管理器中，界面客戶端采用
Web、 Widget或Flash等技術通過瀏覽器呈現(xiàn)給用戶，界面客戶端包括Web網(wǎng)頁形式的應用用戶界面客戶端、應用管理界面客戶端、與網(wǎng)絡側(cè)應用服務器同步部署在內(nèi)部服務器應用模塊的應用界面客戶端等。
步驟S104，將應用模塊動態(tài)加載于應用插件容器中，應用插件容器是一個集成第三方應用/業(yè)務能力的容器，支持應用能力模塊的動態(tài)加載。系統(tǒng)定義一套標準的插件接口，用戶可以按照標準插件接口開發(fā)、加載應用能力模塊。
步驟S106,內(nèi)容管理器和應用插件容器相互獨立設置于內(nèi)部服務器中，內(nèi)部服務器通過HTTP協(xié)議與瀏覽器進行通信。
對應用模塊的動態(tài)加載包括兩種方式在可執(zhí)行文件啟動時由系統(tǒng)程序自動加載和在可執(zhí)行程序中手動通過操作系統(tǒng)加載器的系統(tǒng)接口進行加載，下面對內(nèi)部服務器中應用模塊的動態(tài)加載進行介紹
1)應用模塊的動態(tài)加載原理
內(nèi)部服務器中應用模塊的動態(tài)加載原理是利用了動態(tài)共享對象(DSO， Dynamic Shared Objects)的動態(tài)連4矣、力口載的的沖幾制，乂人而可以在運行時將編譯成特殊格式的代碼加載到一個可執(zhí)行程序的地址空間。
加載的方法通常有兩種其一是在可執(zhí)行文件啟動時由系統(tǒng)程序Id. so自動加載；其二是在可執(zhí)行程序中手動地通過操作系統(tǒng)加載器的系統(tǒng)接口執(zhí)行系統(tǒng)調(diào)用dlopen () /d 1 sym ()進行加載。
我們以第 一種方法為例進行闡述。
按第一種方法，DSO通常被稱為共享庫(shared 1 ibraries)或者DSO庫(DSO libraries) ， ^f吏用1 ibfoo. so或1 ibfoo. so. 1. 2的文件名，存卡者在系統(tǒng)目錄中(假設是/usr/lib),并在編譯安裝時使用連接器參數(shù)-lfoo建立了指向可執(zhí)行程序的連接。通過設置連接器參數(shù)-R或者環(huán)境變量LD-LIBRARY—PATH ，庫中硬編碼了可執(zhí)行文件的路徑，使操作系統(tǒng)加載器能夠在可執(zhí)行程序啟動時定位到位于/usr/lib目錄中的libfoo. so ,以解析可執(zhí)行文件中尚未解析的位于DSO中的符號。
用庫)，也不會有后繼的解析動作?？蓤?zhí)行文件無須自己作任何動作以使用DS0中的符號，而完全由Unix加載器代辦(事實上，調(diào)用ld.so的代碼是被連入每個可執(zhí)行文件的非靜態(tài)運行時啟動代碼的一部分)。動態(tài)加
載公共庫代碼的優(yōu)點是明顯的只需要在系統(tǒng)庫libc. so中存儲一次庫代碼，從而為每個程序節(jié)省了磁盤存儲空間。2)應用模塊的動態(tài)加載過程
a) 將應用模塊編譯成為動態(tài)鏈接庫；
b) 將動態(tài)鏈接庫部署到指定的功能模塊目錄中；
c) 更新指定的部署文件(httpd. conf);
d) 如果服務器正在運行，通過LoadModule命令，發(fā)送信號HUP或者AP_SIG—GRACEFUL給服務器，服務器收到該信號后，將重新加載模塊，而不需要重新啟動服務器。
本發(fā)明實施例一提供了 一種部署客戶端應用方法，使得設置于內(nèi)部服務器中的內(nèi)容管理器和應用插件容器相互獨立設置，使相同界面客戶端開發(fā)一次就可以在不同操作系統(tǒng)的通信終端上使用，且界面可以動態(tài)、實時更新。
本發(fā)明實施例二的部署客戶端應用的終端，可以包括移動終端和固定終端等，在本具體實施方式
中，以移動終端為例加以說明。
在本發(fā)明實施例二中，如圖3所示，部署客戶端應用的移動終端包括瀏覽器l、內(nèi)容管理器7和應用插件容器8，內(nèi)容管理器7和應用插件容器8設置于內(nèi)部服務器2中，內(nèi)容管理器7存儲Web網(wǎng)頁形式的應用用戶界面客戶端、應用管理界面客戶端等，同時負責存儲與網(wǎng)絡側(cè)的應用服務器同步部署在內(nèi)部服務器應用模塊的應用界面客戶端。
應用插件容器8是一個集成第三方應用/業(yè)務能力的容器，支持應用模塊的動態(tài)加載，例如包括第一應用模塊9和第二應用模塊10等應用模塊，每個應用模塊對應一個具體的應用，例如本地搜索應用、飛信、Pushmail (郵件推送)等，如圖4所示。系統(tǒng)定義一套標準的插件接口 ，用戶可以按照標準插件接口開發(fā)、加載應用模塊。
內(nèi)部服務器2還包括請求處理器3和應用模塊管理器6,請求處理器3包括守護進程模塊4和請求分發(fā)器5,請求分發(fā)器5包括判斷子模塊11和分發(fā)子模塊12。
請求處理器3負責監(jiān)聽訪問請求，處理后返回結(jié)果；首先守護進程模塊4負責接收HTTP訪問請求，請求分發(fā)器5將HTTP訪問請求解析后分發(fā)到相應的應用模塊；當應用模塊處理HTTP訪問請求并產(chǎn)生結(jié)果后，請求處理器3通過用戶界面客戶端將結(jié)果返回給請求者。具體地，判斷子模塊11用于判斷HTTP訪問請求的類型，包括用戶界面訪問請求、應用邏輯處理訪問請求；分發(fā)子模塊12用于將應用邏輯處理訪問請求分發(fā)到應用插件容器8的具體應用模塊，由某個具體的應用插件處理，同時分發(fā)子模塊12接收對應應用模塊的處理結(jié)果；并將用戶界面訪問請求分發(fā)到內(nèi)容管理器7進行后續(xù)處理，并接收對應的處理結(jié)果。
應用模塊管理器6負責管理應用模塊的加載、卸載、模塊升級、模塊工作狀態(tài)查詢等功能，用戶可以通過瀏覽器1以HTTP協(xié)議的方式訪問并使用應用模塊管理器6的功能。
圖5為本發(fā)明實施例二終端系統(tǒng)模塊數(shù)據(jù)流向圖，表明了本發(fā)明實施例二終端內(nèi)部服務器中各個模塊間的交互，交互過程如下
1)瀏覽器向內(nèi)部服務器發(fā)起HTTP請求。
2 )內(nèi)部服務器中的守護進程模塊接收HTTP請求后，由請求分發(fā)器
解析并分發(fā)請求給相應處理模塊處理。
3) 如果是請求用戶界面，則該HTTP請求由內(nèi)容管理器處理
a) 如果該HTTP請求是程序啟動后的第一次請求，內(nèi)容管理器將訪問網(wǎng)絡側(cè)的應用服務器，查看該應用是否有該用戶的界面更新，如果有，將更新內(nèi)容管理器中存儲的用戶界面；否則，返回內(nèi)容管理器；
b) 如果該HTTP請求不是程序啟動后的第一次請求，內(nèi)容管理器通過請求分發(fā)器和守護進程模塊以HTTP協(xié)議的方式將內(nèi)容管理器中的用戶界面返回給瀏覽器，通過瀏覽器將統(tǒng)一的用戶界面客戶端呈現(xiàn)給用戶。
4) 如果不是請求用戶界面，是請求應用邏輯處理，則該HTTP請求由應用插件容器中相應的應用模塊處理
a) 應用模塊根據(jù)該HTTP請求進行解析、處理；
b) 將應用模塊的處理結(jié)果返回給瀏覽器，通過瀏覽器將處理結(jié)果呈現(xiàn)給用戶。
下面以部署飛信客戶端應用為例，闡述本發(fā)明實施例二一種移動終端在實際應用中的使用流程。如果用戶希望在移動終端上安裝飛信客戶端應用，可以通過以下步
驟實現(xiàn)
(1) 啟動移動終端上的內(nèi)部服務器；
(2) 啟動瀏覽器訪問內(nèi)部服務器上的管理界面，如http:〃127. 0. 0. l/appmgt/，可以在管理界面上完成應用才莫塊的查看、下載、安裝等 操作；
(3) 查看目前哪些應用模塊可供下載；
(4) 根據(jù)用戶的移動終端型號，選擇相應的飛信客戶端應用模塊， 點擊"下載"按鈕；
(5) 下載完畢后，點擊"安裝該應用"按鈕，飛信客戶端應用將被 加載到內(nèi)部服務器中。
(6 )飛信客戶端應用安裝完成后，用戶通過瀏覽器訪問 http: 〃127. 0. 0. l/fetion/進入飛信登陸界面，登陸后就可以使用飛信 客戶端應用功能。例如，查看好友在線狀態(tài)，好友使用的彩鈴，好友現(xiàn) 在的所在位置，發(fā)送/接收及時消息等。
(7 )如果移動運營商希望更新用戶終端上飛信的界面，可以在飛信 服務器上部署新的飛信界面，則在用戶下一次如(6)所述登陸飛信時， 呈現(xiàn)給用戶的即是更新后的用戶界面。
為了增強用戶體驗，用戶也可以通過類似的操作流程，從網(wǎng)絡側(cè)業(yè) 務應用平臺下載、安裝Widget引擎和飛信Widget,這樣用戶可以通過該 Widget使用飛信客戶端功能。
假設本發(fā)明實施例二使用移動終端的操作系統(tǒng)是Symbian,如果在 Windows Mobi le操作系統(tǒng)的移動終端上也準備實現(xiàn)實施例二，在內(nèi)部服 務器安裝Windows Mobile版本的操作系統(tǒng)，在應用插件容器中安裝 Windows Mobile版本的應用模塊后，即可使用，瀏覽器中的用戶界面客 戶端無需做任何修改，呈現(xiàn)給用戶的仍是統(tǒng)一的用戶界面。
本發(fā)明實施例二提供了 一種移動終端，包括兩個相互獨立的內(nèi)容管 理器和應用插件容器，用戶在使用過程中，可以根據(jù)自己的需要，選擇 更新/升級用戶界面客戶端。用戶界面客戶端開發(fā)簡單，其實現(xiàn)與操作平 臺無關，即只需開發(fā)一次，則該用戶界面客戶端就可以用于各個移動終
12端平臺。本發(fā)明還開放了移動終端上應用模塊的能力，提供標準的訪問 接口，為未來的融合應用做了技術準備。
本發(fā)明實施例三中，提供了一種部署客戶端應用的系統(tǒng)，包括實施 例二中提到的任一移動終端，還包括應用于網(wǎng)絡側(cè)的應用服務器，應用
服務器與移動終端進行通信，用于將所述應用服務器內(nèi)的服務推送至所 述終端的內(nèi)部服務器。
以上公開的僅為本發(fā)明的幾個具體實施例，但是，本發(fā)明并非局限 于此，任何本領域的技術人員能思之的變化都應落入本發(fā)明的保護范圍。
權利要求
1、一種部署客戶端應用的方法，其特征在于，包括以下步驟將界面客戶端存儲于內(nèi)容管理器中；將應用模塊動態(tài)加載于應用插件容器中；所述內(nèi)容管理器與所述應用插件容器相互獨立。
2、 如權利要求1所述部署客戶端應用的方法，其特征在于，包括 將所述內(nèi)容管理器和應用插件容器設置于內(nèi)部服務器中；所述內(nèi)容管理器中存儲的界面客戶端通過瀏覽器呈現(xiàn)； 將請求處理器和應用模塊管理器設置于所述內(nèi)部服務器中。
3、 如權利要求1所述部署客戶端應用的方法，其特征在于，所述界 面客戶端包括Web網(wǎng)頁形式的應用用戶界面客戶端、應用管理界面客戶端和/或與 網(wǎng)絡側(cè)應用服務器同步部署在內(nèi)部服務器的應用模塊的應用界面客戶端。
4、 如權利要求2所述部署客戶端應用的方法，其特征在于，所述瀏 覽器通過HTTP協(xié)議與所述內(nèi)部服務器進行通信。
5、 如權利要求1所述部署客戶端應用的方法，其特征在于，所述應 用模塊的動態(tài)加載包括在可扭J亍文件啟動時由系統(tǒng)程序自動加載；和/或 在可執(zhí)行程序中手動通過操作系統(tǒng)加載器的系統(tǒng)接口進行加載。
6、 如權利要求2所述部署客戶端應用的方法，其特征在于，所述界 面客戶端采用Web、 Widget或Flash技術通過所述瀏覽器實現(xiàn)跨平臺的 界面呈現(xiàn)。
7、 一種部署客戶端應用的終端，其特征在于，包括內(nèi)容管理器，用于存儲各種形式的界面客戶端，所述界面客戶端通過瀏覽器呈現(xiàn)；應用插件容器，用于支持具體應用模塊的動態(tài)加載，對接收的訪問 請求進行解析、處理，將訪問請求的處理結(jié)果返回至請求處理器； 所述內(nèi)容管理器與所述應用插件容器相互獨立。
8、 如權利要求7所述部署客戶端應用的終端，其特征在于，所述內(nèi) 容管理器和應用插件容器設置于內(nèi)部服務器中，所述內(nèi)部服務器還包括 請求處理器和應用模塊管理器所述請求處理器，用于監(jiān)聽訪問請求，分發(fā)接收到的訪問請求，并 將所述訪問請求的處理結(jié)果返回至所述界面客戶端；所述應用模塊管理器，用于對具體的所述應用模塊進行加載、升級 及工作狀態(tài)查詢。
9、 如權利要求8所述部署客戶端應用的終端，其特征在于，所述請 求處理器包括守護進程模塊，用于接收用戶的訪問請求；請求分發(fā)器，用于對接收到的所述訪問請求進行解析，將解析后的 所述訪問請求分發(fā)到對應的內(nèi)容管理器或應用插件容器。
10、 如權利要求9所述部署客戶端應用的終端，其特征在于，所述 請求分發(fā)器包括判斷子模塊，用于判斷所述訪問請求的類型，包括用戶界面訪問請 求或應用邏輯處理訪問請求；分發(fā)子模塊，用于將所述用戶界面訪問請求分發(fā)到所述內(nèi)容管理器 進行后續(xù)處理，并接收對應的處理結(jié)果；將應用邏輯處理訪問請求分發(fā) 到所述應用插件容器的具體應用模塊，并接收對應應用模塊的處理結(jié)果。
11、 一種包括上述權利要求7至IO任一終端的系統(tǒng)，其特征在于， 還包括與所述終端通信的應用服務器，用于將所述應用服務器內(nèi)的服務推 送至所述終端的內(nèi)部服務器。
全文摘要
本發(fā)明公開了一種部署客戶端應用的終端、系統(tǒng)和方法，主要應用于通信領域，本發(fā)明的部署客戶端應用方法包括以下步驟將界面客戶端存儲于內(nèi)容管理器中；將應用模塊動態(tài)加載于應用插件容器中；內(nèi)容管理器與應用插件容器相互獨立。本發(fā)明的部署客戶端應用終端與上述方法相對應。本發(fā)明的系統(tǒng)包括終端和應用于網(wǎng)絡側(cè)的應用服務器。本發(fā)明提供的終端、系統(tǒng)和方法，實現(xiàn)了內(nèi)容管理器和應用插件容器的分離，并設置于內(nèi)部服務器中；客戶端應用的用戶界面實現(xiàn)與操作系統(tǒng)無關，同時提供了標準的訪問接口，為技術融合作了準備。
文檔編號G06F9/44GK101667115SQ200810119529
公開日2010年3月10日 申請日期2008年9月2日 優(yōu)先權日2008年9月2日
發(fā)明者川 于, 睿 侯, 侯清富, 鑫 張, 朱春梅, 程寶平 申請人:中國移動通信集團公司