本發(fā)明涉及通信技術領域,特別是涉及一種富媒體通信方法、系統(tǒng)及服務器。
背景技術:
隨著通信技術的革新,已經(jīng)進入移動通信的4g(the4thgenerationmobilecommunicationtechnology,第四代移動通信技術)時代。網(wǎng)絡帶寬以成百上千的速度增長,能夠提供更多信息量的快速傳遞和更豐富的業(yè)務體驗,多媒體內(nèi)容代替文本信息、視頻通話、個人社交呈現(xiàn)等特點,都已成為技術發(fā)展的新趨勢。
rcs(richcommunicationsuit,富媒體通信)是由gsma(globalsystemformobilecommunicationsassembly,gsm協(xié)會)基于現(xiàn)有的技術標準和規(guī)范,通過迭代、敏捷的方法來實現(xiàn)的統(tǒng)一功能集、實現(xiàn)指導,涵蓋了即時消息、文件傳輸、群聊、網(wǎng)絡地址簿、消息存儲、社交信息的發(fā)布和呈現(xiàn)等業(yè)務功能。
rcs是部署在ims(ipmultimediasubsystem,ip多媒體子系統(tǒng))之上的一種典型業(yè)務,ims是3gpp為移動網(wǎng)絡定義的一種ip化的網(wǎng)絡結構,同時支持固網(wǎng)接入和移動接入,目前全球各運營商的網(wǎng)絡都在向ims網(wǎng)絡演進。
受rcs標準協(xié)議限制,當前rcs解決方案中,服務器接收到發(fā)送方用戶發(fā)送的富媒體消息,然后由服務器將富媒體消息發(fā)送給接收方用戶。但是,當接收方用戶離線、網(wǎng)絡側故障或接收方用戶為非rcs用戶等情況下,服務器無法向接收方用戶發(fā)送富媒體消息,而且,服務器無法告知發(fā)送方用戶富媒體消息下發(fā)失敗的狀態(tài),即此種應用場景下,發(fā)送方無法獲知富媒體消息的發(fā)送狀態(tài)。
技術實現(xiàn)要素:
本發(fā)明實施例中提供了一種富媒體通信方法、系統(tǒng)及服務器,以解決現(xiàn)有技術中在接收方用戶離線、網(wǎng)絡側故障或接收方用戶為非rcs用戶的情況下,發(fā)送方用戶無法獲知富媒體消息發(fā)送狀態(tài)的問題。
為了解決上述技術問題,本發(fā)明實施例公開了如下技術方案:
第一方面,本發(fā)明實施例提供一種富媒體通信方法,包括:服務器接收第一客戶端發(fā)送給第二客戶端的第一富媒體消息;所述服務器檢測所述服務器與所述第二客戶端之間是否能通信;當所述服務器與所述第二客戶端之間無法通信時,所述服務器生成第一通知消息,所述第一通知消息攜帶通信失敗原因;所述服務器向所述第一客戶端發(fā)送所述第一通知消息, 以使所述第一客戶端展示所述第一通知消息。
本實施例提供的富媒體通信方法,當服務器與第二客戶端無法通信時,服務器生成第一通知消息,并發(fā)送給第一客戶端。第一客戶端解析第一通知消息后獲知第一富媒體消息下發(fā)失敗的原因。進一步,發(fā)送方用戶可以根據(jù)消息下發(fā)失敗的原因采用其它方式處理,從而增強用戶體驗。
結合第一方面,在第一方面的第一種可能的實現(xiàn)方式中,當所述服務器與所述第二客戶端之間無法通信時,所述服務器生成第一通知消息,包括:當所述服務器無法與所述第二客戶端通信時,所述服務器獲取所述服務器與所述第二客戶端的通信失敗原因;所述服務器根據(jù)所述通信失敗原因生成所述第一通知消息。
結合第一方面,在第一方面的第二種可能的實現(xiàn)方式中,所述方法還包括:當所述服務器與所述第二客戶端之間能夠通信時,所述服務器將所述第一富媒體消息發(fā)送給所述第二客戶端;所述服務器獲取第二通知消息,所述第二通知消息用于表征所述第二客戶端接收所述第一富媒體消息的接收狀態(tài),且攜帶由所述第二客戶端對應用戶設定的擴展信息;所述服務器將所述第二通知消息發(fā)送給所述第一客戶端,以使所述第一客戶端展示所述擴展信息。
結合第一方面,在第一方面的第三種可能的實現(xiàn)方式中,所述服務器獲取第二通知消息,包括:所述服務器接收所述第二客戶端發(fā)送的第二通知消息,所述第二通知消息由所述第二客戶端發(fā)送并攜帶所述擴展信息。
結合第一方面,在第一方面的第四種可能的實現(xiàn)方式中,所述服務器獲取第二通知消息,包括:所述服務器接收所述第二客戶端發(fā)送的接收狀態(tài)信息,所述接收狀態(tài)信息包括成功接收狀態(tài)和已讀取狀態(tài);所述服務器獲取擴展信息,并根據(jù)所述接收狀態(tài)信息和所述擴展信息生成所述第二通知消息。
第二方面,本發(fā)明實施例提供了一種服務器,包括:接收器、處理器和發(fā)送器;所述接收器,用于接收第一客戶端發(fā)送給第二客戶端的第一富媒體消息;所述處理器,用于檢測所述服務器與所述第二客戶端之間是否能通信;當所述服務器與所述第二客戶端之間無法通信時,生成第一通知消息,所述第一通知消息攜帶通信失敗原因;所述發(fā)送器,用于向所述第一客戶端發(fā)送所述第一通知消息,以使所述第一客戶端展示所述第一通知消息。
結合第二方面,在第二方面的第一種可能的實現(xiàn)方式中,所述處理器生成第一通知消息時,具體用于:當所述服務器無法與所述第二客戶端通信時,獲取所述服務器與所述第二客戶端的通信失敗原因;根據(jù)所述通信失敗原因生成所述第一通知消息。
結合第二方面,在第二方面的第二種可能的實現(xiàn)方式中,所述發(fā)送器,還用于當所述服務器與所述第二客戶端之間能夠通信時,所述服務器將所述第一富媒體消息發(fā)送給所述第二 客戶端;所述處理器,還用于獲取第二通知消息,所述第二通知消息用于表征所述第二客戶端接收所述第一富媒體消息的接收狀態(tài),且攜帶由所述第二客戶端對應用戶設定的擴展信息;所述發(fā)送器,還用于將所述第二通知消息發(fā)送給所述第一客戶端,以使所述第一客戶端展示所述擴展信息。
結合第二方面,在第二方面的第三種可能的實現(xiàn)方式中,所述處理器用于獲取第二通知消息時,具體用于:獲取所述接收器接收到的所述第二客戶端發(fā)送的第二通知消息,所述第二通知消息由所述第二客戶端發(fā)送并攜帶所述擴展信息。
結合第二方面,在第二方面的第四種可能的實現(xiàn)方式中,所述處理器用于獲取第二通知消息時,具體用于:通過所述接收器接收所述第二客戶端發(fā)送的接收狀態(tài)信息,所述接收狀態(tài)信息包括成功接收狀態(tài)和已讀取狀態(tài);獲取擴展信息,并根據(jù)所述接收狀態(tài)信息和所述擴展信息生成所述第二通知消息。
本發(fā)明實施例的第三方面,提供一種富媒體通信系統(tǒng),包括第一客戶端、第二客戶端和服務器;所述第一客戶端,用于向所述第二客戶端發(fā)送第一富媒體消息;所述服務器,用于接收第一客戶端發(fā)送給第二客戶端的第一富媒體消息;檢測所述服務器與所述第二客戶端之間是否能通信;當所述服務器與所述第二客戶端之間無法通信時,生成第一通知消息并發(fā)送給所述第一客戶端,所述第一通知消息攜帶通信失敗原因;所述第一客戶端,還用于展示所述第一通知消息。
由以上技術方案可見,本發(fā)明實施例提供的富媒體通信方法,服務器接收到第一客戶端發(fā)送的第一富媒體消息后,檢測自身與第二客戶端之間能否通信;如果無法通信,則由服務器生成第一通知消息,并發(fā)送給第一客戶端,第一客戶端解析第一通知消息后獲知第一富媒體消息下發(fā)失敗的原因。進一步,發(fā)送方用戶可以根據(jù)消息下發(fā)失敗的原因采用其它方式處理,從而增強用戶體驗。
附圖說明
為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術中的技術方案,下面將對實施例或現(xiàn)有技術描述中所需要使用的附圖作簡單地介紹,顯而易見地,對于本領域普通技術人員而言,在不付出創(chuàng)造性勞動性的前提下,還可以根據(jù)這些附圖獲得其他的附圖。
圖1為本發(fā)明實施例一種富媒體通信系統(tǒng)架構示意圖;
圖2為本發(fā)明實施例一種富媒體通信方法的流程示意圖;
圖3為本發(fā)明實施例另一種富媒體通信方法的流程示意圖;
圖4為本發(fā)明實施例另一種富媒體通信方法的流程示意圖;
圖5為本發(fā)明實施例又一種富媒體通信方法的流程示意圖;
圖6為本發(fā)明實施例一種服務器的框圖。
具體實施方式
為了使本技術領域的人員更好地理解本發(fā)明中的技術方案,下面將結合本發(fā)明實施例中的附圖,對本發(fā)明實施例中的技術方案進行清楚、完整地描述,顯然,所描述的實施例僅僅是本發(fā)明一部分實施例,而不是全部的實施例。基于本發(fā)明中的實施例,本領域普通技術人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例,都應當屬于本發(fā)明保護的范圍。
參見圖1,為本發(fā)明實施例一種富媒體通信系統(tǒng)構架示意圖,該富媒體通信系統(tǒng)包括服務器110、至少一個第一客戶端120和第二客戶端130。
本實施例中,第一客戶端120和第二客戶端130中一個客戶端作為發(fā)送方客戶端,另一個客戶端作為接收方客戶端。第一客戶端和第二客戶端均可以是移動終端(例如,手機)上安裝的app(application,應用程序),例如,短信息app。兩個客戶端之間傳輸?shù)母幻襟w消息通過服務器110轉發(fā)。例如,第一客戶端120向第二客戶端130發(fā)送一富媒體消息時,第一客戶端120向服務器110發(fā)送富媒體消息,然后,由服務器110向第二客戶端130轉發(fā)該富媒體消息。
參見圖1和圖2,其中,圖2為本發(fā)明實施例提供的一種富媒體通信方法的流程示意圖,該方法應用于服務器中,如圖2所示,該方法可以包括:
s110,服務器接收第一客戶端發(fā)送給第二客戶端的第一富媒體消息。
在本發(fā)明的一些實施例中,第一富媒體消息的類型可以包括文本、圖片、語音、視頻、地理位置、電子名片、二維碼等。
本實施例中,第一客戶端為發(fā)送方客戶端,第二客戶端為接收方客戶端。服務器為各種應用服務器,例如,rcsas(applicationserver,應用服務器)、mmtel(multimediatelephony,多媒體電話)as等。rcsas為用戶提供各種即時消息業(yè)務功能,例如,點對點聊天、群聊、文件傳輸、內(nèi)容分享等。
s120,服務器檢測所述服務器與所述第二客戶端之間能否通信。
服務器接收到第一客戶端發(fā)送的第一富媒體消息后檢測自身能否與第二客戶端進行通信。服務器向第二客戶端發(fā)送連接請求,如果接收到第二客戶端返回的連接響應消息則建立服務器與第二客戶端之間的msrp(messagesessionrelayprotocol,會話中繼協(xié)議)連接。如果未接收到第二客戶端返回的連接響應消息,則確定服務器與第二客戶端之間通信失敗。
s130,當服務器與第二客戶端之間無法通信時,服務器生成第一通知消息,所述第一通知消息攜帶通信失敗原因。
如果服務器與第二客戶端之間無法通信,則由服務器生成第一通知消息,而且,該第一通知消息攜帶通信失敗原因。
例如,第一富媒體消息是im(instantmessage,即時消息)消息時,第一通知消息可以是imdn(instantmessagedispositionnotification,即時消息處理通知)消息,通信失敗原因可以包含在imdn消息的消息內(nèi)容字段中。其中,消息內(nèi)容字段內(nèi)的信息可以是xml(extensiblemarkuplanguage,可擴展標記語言)格式。
例如,通信失敗原因可以是用戶離線、網(wǎng)絡故障或非rcs用戶等。
s140,服務器向所述第一客戶端發(fā)送第一通知消息,以使第一客戶端展示所述第一通知消息。
服務器將生成的第一通知消息發(fā)送給第一客戶端,第一客戶端解析第一通知消息獲得第一富媒體消息下發(fā)失敗的原因,即服務器與第二客戶端通信失敗原因。
本實施例提供的富媒體通信方法,服務器接收到第一客戶端發(fā)送的第一富媒體消息后,檢測自身與第二客戶端之間能否通信;如果無法通信,則由服務器生成第一通知消息,并發(fā)送給第一客戶端,第一客戶端解析第一通知消息后獲知第一富媒體消息下發(fā)失敗的原因。進一步,發(fā)送方用戶可以根據(jù)消息下發(fā)失敗的原因采用其它方式處理,從而增強用戶體驗。
參見圖3,為本發(fā)明實施例提供的另一種富媒體通信方法的流程圖,該方法應用于圖1所示的富媒體通信系統(tǒng)中,本實施例中第一富媒體消息是im消息如圖3所示,該方法可以包括:
s210,第一客戶端檢測到用戶發(fā)送給第二客戶端的im消息,向服務器發(fā)送第一連接請求;第一連接請求攜帶第二客戶端對應用戶的賬戶信息。
本實施例中,第一客戶端是指第一客戶端內(nèi)安裝的用于進行富媒體通信的app,app檢測到用戶發(fā)送給另一個用戶的im消息后,向服務器發(fā)送第一連接請求,第一連接請求用于請求建立第一客戶端與服務器之間的通信連接,例如,msrp連接。
而且,該第一連接請求攜帶接收該im消息的賬戶信息。
s220,服務器根據(jù)第一連接請求建立服務器與第一客戶端之間的通信連接。
例如,該通信連接可以是msrp連接。
s230,服務器向第二客戶端發(fā)送第二連接請求。
該第二連接請求用于請求建立服務器與第二客戶端之間的通信連接,例如,msrp連接。
此外,本實施例并不限定s220與s230的執(zhí)行順序,兩個步驟可以同時執(zhí)行,或者,先 執(zhí)行s230,再執(zhí)行s220。
s240,第一客戶端通過自身與服務器之間的通信連接發(fā)送im消息。
s250,當服務器無法與第二客戶端建立通信連接時,獲取通信失敗原因。
例如,第二客戶端對應用戶離線、網(wǎng)絡側故障或非rcs用戶等應用場景下,服務器與第二客戶端之間無法通信。對應的,通信失敗原因可以是用戶離線、網(wǎng)絡故障或非rcs用戶。
s260,服務器根據(jù)通信失敗原因生成第一imdn消息。該第一imdn消息攜帶服務器與第二客戶端的通信失敗原因。
s270,服務器將第一imdn消息發(fā)送給第一客戶端。
s280,第一客戶端解析第一imdn消息獲得所述通信失敗原因,并向用戶展示所述通信失敗原因。
本實施例提供的富媒體通信方法,第一客戶端向第二客戶端發(fā)送im消息時,當服務器無法將im消息下發(fā)給第二客戶端時,獲取服務器下發(fā)im消息失敗的原因,并生成相應的imdn消息,該imdn消息中攜帶im消息下發(fā)失敗的具體原因,然后發(fā)送給第一客戶端。第一客戶端解析該imdn消息后獲知im消息未成功送達第二客戶端,以及具體的失敗原因。進一步,第一客戶端對應用戶可以根據(jù)失敗原因采用其它方式處理,增強用戶體驗。
參見圖4,為本發(fā)明實施例另一種富媒體通信方法的流程圖,如圖4所示,該方法包括s210~s340,其中,s210~s240請參見圖3所示實施例中的相應內(nèi)容,此處不再贅述;s310~s340如下:
s310,當服務器與第二客戶端成功建立通信連接后,將im消息發(fā)送給第二客戶端。
s320,第二客戶端生成第二imdn消息并發(fā)送給服務器,該第二imdn消息攜帶im消息接收狀態(tài)信息和預先設定的擴展信息。
接收方通過imdn消息向發(fā)送方傳達im消息的接收狀態(tài)信息,例如,該接收狀態(tài)信息可以包括已送達或消息已讀等狀態(tài)。當?shù)诙蛻舳顺晒邮読m消息后,會生成已送達的狀態(tài)信息;接著,如果第二客戶端對應的用戶已經(jīng)讀取該im消息,則會生成消息已讀的狀態(tài)信息。
擴展信息可以由第二客戶端對應用戶自由設定,用戶可以設定個性化的內(nèi)容,例如,“正在休假中,急事請電話聯(lián)系”等。
s330,服務器將接收到的第二imdn消息發(fā)送給第一客戶端。
s340,第一客戶端解析所述第二imdn消息獲得所述擴展信息,并展示所述擴展信息。
本實施例提供的富媒體通信方法,第一客戶端向第二客戶端發(fā)送im消息,當im消息成功送達第二客戶端時,第二客戶端可以生成相應的imdn消息,并在imdn消息中攜帶個性化內(nèi)容的擴展信息,從而豐富了imdn消息攜帶的內(nèi)容。同時,與單獨發(fā)送擴展信息相比,直接 將擴展信息攜帶于imdn消息中,不需要再次進行消息交互,因此,減少了網(wǎng)絡消息交互占用的流量。
參見圖5,為本發(fā)明實施例又一種富媒體通信方法的流程圖,如圖5所示,該方法包括s210~s450,其中,s210~s240請參見圖3所示實施例中的相應內(nèi)容,此處不再贅述;s410~s450如下:
s410,當服務器與第二客戶端成功建立通信連接后,將im消息發(fā)送給第二客戶端。
s420,第二客戶端生成第三imdn消息,該第三imdn消息攜帶im消息的接收狀態(tài)信息。
該接收狀態(tài)信息可以包括已送達或消息已讀等狀態(tài)。
s430,服務器接收第三imdn消息,并在該第三imdn消息中插入預先獲得的擴展信息,得到第四imdn消息。
該擴展信息可以由服務器設定,或者,也可以由接收方用戶設定并上傳給服務器。
s440,服務器將第四imdn消息發(fā)送給第一客戶端。
s450,第一客戶端解析所述第四imdn消息獲得所述擴展信息,并展示所述擴展信息。
本實施例提供的富媒體通信方法,第一客戶端向第二客戶端發(fā)送im消息,當im消息成功送達第二客戶端時,第二客戶端可以生成相應的imdn消息并發(fā)送給服務器。服務器可以在imdn消息中插入個性化內(nèi)容的擴展信息,從而豐富了imdn消息攜帶的內(nèi)容。擴展信息可以由服務器設定或第二客戶端對應用戶設定,提高了設定擴展信息的靈活性。同時,與單獨發(fā)送擴展信息相比,直接將擴展信息攜帶于imdn消息中,不需要再次進行消息交互,因此,減少了網(wǎng)絡消息交互占用的流量。
與本發(fā)明提供的富媒體通信方法實施例相對應,本發(fā)明還提供了一種用于實現(xiàn)富媒體通信的服務器的實施例。
參見圖6,為本發(fā)明實施例一種服務器的框圖,如圖6所示,該服務器可以包括:接收器110、處理器120和發(fā)送器130。
接收器110,用于接收第一客戶端發(fā)送給第二客戶端的第一富媒體消息。
第一客戶端與第二客戶端之間通過該服務器進行富媒體通信。本實施例中,第一客戶端是發(fā)送方,第二客戶端是接收方,第一客戶端首先將第一富媒體消息發(fā)送給服務器,然后,由服務器再將第一富媒體發(fā)送給第二客戶端。
處理器120,用于檢測服務器與第二客戶端之間是否能通信,當所述服務器與所述第二客戶端之間無法通信時,生成第一通知消息,所述第一通知消息攜帶通信失敗原因。
當檢測到無法與第二客戶端正常通信時,生成第一通知消息,并且第一通知消息中攜帶 通信失敗原因。如果第一富媒體消息是im消息,則第一通知消息是imdn消息。例如,通信失敗原因可以是用戶離線、網(wǎng)絡故障或非rcs用戶等。
在本發(fā)明的一些實施例中,處理器120生成第一通知消息時具體用于:當所述服務器無法與第二客戶端通信時,獲取服務器與所述第二客戶端的通信失敗原因;根據(jù)通信失敗原因生成第一通知消息。
發(fā)送器130,用于向所述第一客戶端發(fā)送所述第一通知消息,以使所述第一客戶端展示所述第一通知消息。
處理器120生成的第一通知消息經(jīng)過發(fā)送器130發(fā)送給第一客戶端,第一客戶端向用戶展示該第一通知消息,從而使用戶獲知發(fā)送給第二客戶端的第一富媒體消息的發(fā)送狀態(tài)。
本實施例提供的服務器,接收到第一客戶端發(fā)送的第一富媒體消息后,檢測自身與第二客戶端之間能否通信;如果無法通信,則由服務器生成第一通知消息,并發(fā)送給第一客戶端,第一客戶端解析第一通知消息后獲知第一富媒體消息下發(fā)失敗的原因。進一步,發(fā)送方用戶可以根據(jù)消息下發(fā)失敗的原因采用其它方式處理,從而增強用戶體驗。
在本發(fā)明的另一些實施例中,圖6所示實施例中的服務器在能夠與第二客戶端進行通信的應用場景下,還可以向第一客戶端發(fā)送擴展信息,該擴展信息為第二客戶端設定的個性信息,例如,“正在休假中,急事請電話聯(lián)系”。
本實施例中,當處理器120檢測到服務器能夠與第二客戶端進行通信時,由發(fā)送器130將第一富媒體消息發(fā)送給第二客戶端。同時,處理器120獲取第二通知消息,該第二通知消息攜帶第二客戶端對應用戶設定的擴展信息。然后,由發(fā)送器130將第二通知消息發(fā)送給第一客戶端,從而使第一客戶端向用戶展示擴展信息。
在本發(fā)明的一些實施例中,可以由第二客戶端在接收到第一富媒體消息后,生成第二通知消息,并發(fā)送給服務器。服務器內(nèi)的接收器110接收到第二通知消息后,提供給處理器120,處理器120將第二通知消息提供給發(fā)送器130,由發(fā)送器130將第二通知消息發(fā)送給第一客戶端。
在本發(fā)明的另一些實施例中,可以由服務器生成第二通知消息。當?shù)诙蛻舳私邮盏降谝桓幻襟w消息后,生成相應的接收狀態(tài)信息并提供給服務器。服務器內(nèi)的處理器根據(jù)接收到的接收狀態(tài)信息及第二客戶端對應用戶預先設定的擴展信息,處理器120根據(jù)接收狀態(tài)信息和擴展信息生成第二通知消息,并通過發(fā)送器130發(fā)送給第一客戶端,第一客戶端接收到第二通知消息后確定第二客戶端接收到第一富媒體消息,而且,能夠獲取第二通知消息攜帶的擴展信息。
本實施例提供的服務器,第一客戶端通過服務器向第二客戶端發(fā)送第一富媒體消息,當 第一富媒體消息成功送達第二客戶端時,服務器可以獲取第二通知消息,第二通知消息中攜帶個性化內(nèi)容的擴展信息,從而豐富了第二通知消息攜帶的內(nèi)容。同時,與單獨發(fā)送擴展信息相比,直接將擴展信息攜帶于第二通知消息中,不需要再次進行消息交互,因此,減少了網(wǎng)絡消息交互占用的流量。
本發(fā)明實施例還提供了一種富媒體通信系統(tǒng),該通信系統(tǒng)包括第一客戶端、第二客戶端和服務器。本實施例中,第一客戶端為發(fā)送端,第二客戶端為接收端,第一客戶端向第二客戶端發(fā)送第一富媒體消息。具體的,第一客戶端向第二客戶端發(fā)送第一富媒體消息時,先將第一富媒體消息發(fā)送給服務器,服務器檢測自身與第二客戶端之間是否能夠通信,如果服務器與第二客戶端無法通信,則由服務器生成第一通知消息,該第一通知消息攜帶服務器與第二客戶端通信失敗的通信失敗原因。并將第一通知消息發(fā)送給第一客戶端,第一客戶端向用戶展示第一通知消息,以使用戶獲知第一富媒體消息發(fā)送失敗的原因。
本說明書中的各個實施例均采用遞進的方式描述,各個實施例之間相同相似的部分互相參見即可,每個實施例重點說明的都是與其他實施例的不同之處。尤其,對于裝置或系統(tǒng)實施例而言,由于其基本相似于方法實施例,所以描述得比較簡單,相關之處參見方法實施例的部分說明即可。以上所描述的裝置及系統(tǒng)實施例僅僅是示意性的,其中所述作為分離部件說明的單元可以是或者也可以不是物理上分開的,作為單元顯示的部件可以是或者也可以不是物理單元,即可以位于一個地方,或者也可以分布到多個網(wǎng)絡單元上??梢愿鶕?jù)實際的需要選擇其中的部分或者全部模塊來實現(xiàn)本實施例方案的目的。本領域普通技術人員在不付出創(chuàng)造性勞動的情況下,即可以理解并實施。
以上所述僅是本發(fā)明的具體實施方式,應當指出,對于本技術領域的普通技術人員來說,在不脫離本發(fā)明原理的前提下,還可以做出若干改進和潤飾,這些改進和潤飾也應視為本發(fā)明的保護范圍。