專利名稱：統(tǒng)一資源標識符索引的信息的處理方法及裝置的制作方法
技術領域：
本發(fā)明實施例涉及通信技術領域，特別涉及統(tǒng)一資源標識符(Uniform Resource Identify，簡稱URI)索引的信息的處理方法及裝置。
背景技術：
內(nèi)容分發(fā)網(wǎng)絡(Content Delivery Network，簡稱CDN)系統(tǒng)中的內(nèi)容分發(fā)技術包 括兩種方式一種為主動式即推送(PUSH)分發(fā)技術；另一種為被動式即主動請求(PULL) 分發(fā)技術。推送分發(fā)技術是一種建立在客戶服務器上的機制，就是由服務器主動將信息發(fā) 往客戶端的技術；主動請求分發(fā)技術是由客戶端主動請求信息的技術。推送框架主要包括 推送發(fā)起者(PUSH hitiator，簡稱PI)、推送代理網(wǎng)關(PUSH Proxy Gateway，簡稱PPG)和 客戶端(推送客戶端)三個部分；主動請求框架主要包括內(nèi)容服務器和客戶端(請求客戶 端)兩個部分。上述兩種分發(fā)技術中的客戶端都可以通過兩種方式獲取信息一種為直接 獲取信息，另一種為先獲取索引的信息的URI，再根據(jù)該URI獲取信息。在實現(xiàn)本發(fā)明過程中，發(fā)明人發(fā)現(xiàn)現(xiàn)有技術中的后一種獲取方式至少存在如下問 題客戶端根據(jù)索引的信息的URI獲取到的信息的可用性無法得到保證，導致了客戶端頻 繁接收到無用的垃圾信息，從而造成了網(wǎng)絡資源的浪費。

發(fā)明內(nèi)容
本發(fā)明實施例提供URI索引的信息的處理方法及裝置，避免客戶端接收到無用的 垃圾信息，節(jié)省網(wǎng)絡資源。本發(fā)明實施例提供一種URI索引的信息的處理方法，包括接收攜帶有URI的請求消息；獲取所述URI索引的信息；驗證所述URI索引的信息的相關屬性信息；根據(jù)所述驗證的結(jié)果，進行相關處理。本發(fā)明實施例提供另一種URI索引的信息的處理方法，包括接收攜帶有URI和獲取所述URI索引的信息的時間指示信息的請求消息；根據(jù)所述時間指示信息，獲取所述URI索引的信息；向推送客戶端發(fā)送所述URI索引的信息。本發(fā)明實施例提供再一種URI索引的信息的處理方法，包括接收攜帶有URI的請求消息；若存在至少兩個推送客戶端，獲取所述URI索引的信息；向所述至少兩個推送客戶端發(fā)送所述URI索引的信息。本發(fā)明實施例提供一種URI索引的信息的處理裝置，包括第一接收模塊，用于接收攜帶有URI的請求消息；第一獲取模塊，用于獲取所述URI索引的信息；
第一驗證模塊，用于驗證所述URI索引的信息的相關屬性信息；處理模塊，用于根據(jù)所述驗證的結(jié)果，進行相關處理。本發(fā)明實施例提供一種推送發(fā)起者，包括第一發(fā)送模塊，用于發(fā)送攜帶有URI和 獲取所述URI索引的信息的時間指示信息的請求消息，以供推送服務器或推送客戶端根據(jù) 所述時間指示信息，獲取所述URI索引的信息。本發(fā)明實施例提供一種推送服務器，包括第二接收模塊，用于接收攜帶有U RI和獲取所述URI索引的信息的時間指示信息 的請求消息；第二獲取模塊，用于根據(jù)所述時間指示信息，獲取所述URI索引的信息；第二發(fā)送模塊，用于向推送客戶端發(fā)送所述URI索引的信息。本發(fā)明實施例提供一種推送客戶端，包括第三接收模塊，用于接收攜帶有URI和獲取所述URI索引的信息的時間指示信息 的請求消息；第三獲取模塊，用于根據(jù)所述時間指示信息，獲取所述URI索引的信息。本發(fā)明實施例提供另一種推送服務器，包括第四接收模塊，用于接收攜帶有URI的請求消息；第四獲取模塊，用于若存在至少兩個推送客戶端，獲取所述URI索引的信息；第三發(fā)送模塊，用于向所述至少兩個推送客戶端發(fā)送所述URI索引的信息。由上述技術方案可知，本發(fā)明實施例獲取到請求消息中所攜帶的URI索引的信息 之后，通過對該URI索引的信息的相關屬性信息進行驗證，使得可以根據(jù)驗證的結(jié)果進行 相關處理，能夠避免客戶端接收到無用的垃圾信息信息，從而節(jié)省了網(wǎng)絡資源。


為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術中的技術方案，下面將對實施例或現(xiàn) 有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本 發(fā)明的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以 根據(jù)這些附圖獲得其他的附圖。圖1為本發(fā)明實施例一提供的一種URI索引的信息的處理方法的流程示意圖；圖2為本發(fā)明實施例二提供的一種URI索引的信息的處理方法的流程示意圖；圖3為本發(fā)明實施例三提供的一種URI索引的信息的處理方法的流程示意圖；圖4為本發(fā)明實施例四提供的另一種URI索引的信息的處理方法的流程示意圖；圖5為本發(fā)明實施例五提供的再一種URI索引的信息的處理方法的流程示意圖；圖6為本發(fā)明實施例六提供的一種URI索引的信息的處理裝置的結(jié)構示意圖；圖7為本發(fā)明實施例七提供的一種URI索引的信息的處理裝置的結(jié)構示意圖；圖8為本發(fā)明實施例八提供的一種URI索引的信息的處理系統(tǒng)的結(jié)構示意圖；圖9為本發(fā)明實施例九提供的一種推送發(fā)起者的結(jié)構示意圖；圖10為本發(fā)明實施例十提供的一種推送服務器的結(jié)構示意圖；圖11為本發(fā)明實施例十一提供的另一種URI索引的信息的處理系統(tǒng)的結(jié)構示意 圖12為本發(fā)明實施例十二提供的一種推送客戶端的結(jié)構示意圖；圖13為本發(fā)明實施例十三提供的再一種URI索引的信息的處理系統(tǒng)的結(jié)構示意 圖；圖14為本發(fā)明實施例十四提供的另一種推送服務器的結(jié)構示意圖；圖15為本發(fā)明實施例十五提供的又一種URI索引的信息的處理系統(tǒng)的結(jié)構示意 圖。
具體實施例方式下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完 整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；?本發(fā)明中的實施例，本領域普通技術人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他 實施例，都屬于本發(fā)明保護的范圍。圖1為本發(fā)明實施例一提供的一種URI索引的信息的處理方法的流程示意圖，如 圖1所示，本實施例的URI索引的信息的處理方法可以包括以下步驟步驟101、接收攜帶有URI的請求消息；步驟102、獲取上述URI索引的信息；步驟103、驗證上述URI索引的信息的相關屬性信息；步驟104、根據(jù)上述驗證的結(jié)果，進行相關處理。其中的URI可以是單獨一個URI，還可以是嵌入在網(wǎng)頁頁面中的URI ；URI索引的 信息的相關屬性信息可以包括URI索引的信息的安全性、URI索引的信息所屬的類別(例 如教育、18歲以上、娛樂、新聞等)、與URI索引的信息匹配的能力信息(例如支持的版本 信息、網(wǎng)絡信息、軟硬件信息、顯示能力信息等)等信息。本實施例的步驟104中，若通過該URI索引的信息的相關屬性信息的驗證，則可以 向客戶端發(fā)送該URI和/或該URI索引的信息，或者進一步發(fā)送驗證通過的結(jié)果信息；若未 通過該URI索引的信息的相關屬性信息的驗證，則可以向客戶端發(fā)送至少以下一種信息 驗證未通過的結(jié)果信息；該URI和驗證未通過的結(jié)果信息；該URI、經(jīng)過過濾后的該URI索 引的信息和驗證未通過的結(jié)果信息。本實施例可以適用于CDN系統(tǒng)中的任何一種內(nèi)容分發(fā)技術對于推送分發(fā)技術 來說，步驟101中所接收到的請求消息是PI發(fā)送的Push消息；對于主動請求分發(fā)技術來 說，步驟101中所接收到的請求消息是客戶端(主動請求客戶端)發(fā)送的超文本傳輸協(xié)議 (Hyper Text Transfer Protocol，簡稱 HTTP)消息、會話初始協(xié)議 Cession Initiation Protocol，簡稱SIP)消息、短消息等消息。其中主動請求客戶端可以是請求URI索引的信 息的客戶端，還可以是請求對未知URI索引的信息進行驗證的客戶端。本實施例中，獲取到請求消息中所攜帶的URI索引的信息之后，通過對該URI索引 的信息的相關屬性信息進行驗證，使得可以根據(jù)驗證的結(jié)果進行相關處理，能夠避免客戶 端遭受病毒攻擊，從而防止了客戶端的操作系統(tǒng)的損壞和客戶端用戶的個人信息的泄露， 以及能夠避免客戶端接收到無用的垃圾信息和無法顯示的信息，從而節(jié)省了網(wǎng)絡資源。需要說明的是本實施例中的步驟102和/或步驟103的執(zhí)行主體可以是推送框 架中現(xiàn)有的PPG，還可以是推送框架或主動請求框架中新增加的一個驗證服務器，主要完成URI索引的信息的獲取和/或URI索引的信息的驗證，和/或完成相應處理功能的服務器。圖2為本發(fā)明實施例二提供的一種URI索引的信息的處理方法的流程示意圖，本 實施例的URI索引的信息的處理方法是基于推送分發(fā)技術實現(xiàn)的，如圖2所示，本實施例的 URI索引的信息的處理方法可以包括以下步驟步驟201、PI通過推送接入?yún)f(xié)議(Push Access Protocol，簡稱PAP)向PPG發(fā)送 攜帶有URI的推送消息；步驟202、PPG接收上述攜帶有URI的推送消息，根據(jù)預設策略，判斷是否需要對上 述URI索引的信息的相關屬性信息進行驗證，如果不需要驗證，則執(zhí)行步驟203 ；如果需要 驗證，則執(zhí)行步驟204;其中的預設策略可以包括一個允許PPG完成驗證URI索引的信息的相關屬性信 息的指示信息，上述預設策略可以是客戶端在注冊或簽約業(yè)務過程中在PPG上設置的， 還可以是網(wǎng)絡運營商預先在PPG上設置的。具體地，客戶端可以通過注冊或簽約業(yè)務過 程中的消息攜帶該指示信息，例如擴展HTTP選項(HTTP OPTIONS)的響應消息、SIP注 冊(SIP REGISTER)消息、SIP 選項(SIP OPTIONS)消息、SIP 訂閱(SIP SUBSCRIBE)消 息等消息的頭域或者在上述消息的消息體中直接攜帶，例如可以通過擴展頭域“URI驗 證” (“URI-Validation”)，當取值為“需要” (“Required”)時，指示PPG需要對上述URI 索引的信息的相關屬性信息進行驗證；還可以通過擴展頭域“URI驗證類型”，指示PPG需要 對屬于該頭域取值所表示的URI類型的URI索引的信息的相關屬性信息進行驗證，例如非 白名單PI發(fā)送的URI、發(fā)給某個特定應用(例如彩信客戶端、郵件客戶端等)的URI等?？蛇x地，客戶端用戶還可以選擇撥打相應的客服電話、網(wǎng)上簽約等方式對上述預 設策略進行設置。203、PPG通過空中協(xié)議(Over The Air，簡稱OTA)向客戶端發(fā)送上述攜帶有URI 的推送消息，以供客戶端執(zhí)行現(xiàn)有流程中獲取該URI索引的信息，此處不再贅述；可替換地，當步驟202中PPG判斷出不需要對上述URI索引的信息的相關屬性信 息進行驗證時，PPG可以不執(zhí)行步驟203，而是根據(jù)預設策略，進一步判斷是否需要獲取上 述URI索引的信息。若判斷出需要獲取上述URI索引的信息，則與內(nèi)容服務器進行交互，獲 取上述URI索引的信息。根據(jù)獲取URI索引的信息的內(nèi)容大小、客戶端的設置、客戶端的 能力信息、和/或網(wǎng)絡情況，并向客戶端發(fā)送上述URI索引的信息，選擇適當?shù)某休d方式， 將所獲取的上述URI索引的信息發(fā)送給客戶端，例如會話初始協(xié)議(Session Initiation Protocol，簡稱 SIP)、超文本傳輸協(xié)議(Hyper Text Transfer Protocol，簡稱 HTTP)、短消 息業(yè)務(Short Messaging Service，簡稱SMS)等承載方式。204、PPG與內(nèi)容服務器進行交互，獲取上述URI索引的信息；其中的內(nèi)容服務器可以為PI，還可以為第三方的內(nèi)容源。本步驟中，在PPG與內(nèi) 容服務器進行交互的過程中，內(nèi)容服務器可能需要執(zhí)行鑒權認證過程，即內(nèi)容服務器需要 獲取到客戶端用戶的授權信息、鑒權信息(密鑰)等權限信息之后，才可以向PPG提供上述 URI索引的信息。類似地，上述權限信息可以像上述PPG上設置的預設策略一樣，由客戶端在注冊 或簽約業(yè)務過程中在PPG上設置。若PPG上沒有預先設置客戶端的權限信息，PPG則需要 通過授權請求消息向客戶端獲取權限信息，PPG將獲取到的權限信息提供給內(nèi)容服務器，內(nèi)容服務器對該權限信息鑒權通過之后，才能向PPG提供上述URI索引的信息，由于考慮了當 PPG上沒有預先設置獲取上述URI所需的客戶端用戶的權限信息時，需要克服因此不能獲 得URI索引的信息的技術困難，提供了獲得客戶端用戶授權或預制授權信息的發(fā)明思想， 使得能夠解決權限問題，從而帶來了更好用戶體驗。205、PPG驗證所獲取到的上述URI索引的信息的相關屬性信息；其中的上述URI索引的信息的相關屬性信息可以包括URI索引的信息的安全性、 URI索引的信息所屬的類別(例如教育、18歲以上、性別、娛樂、新聞等類別)、與URI索弓丨 的信息匹配的能力信息等信息。具體地，PPG可以驗證上述URI索引的信息的安全性，具體 方法可以參照有關信息的安全性檢驗的相關技術，此處不再贅述；PPG也可以驗證上述URI 索引的信息所屬的類別是否與客戶端用戶的偏好信息相匹配；PPG還可以驗證上述URI索 引的信息是否與客戶端的能力信息相匹配。需要說明的是上述驗證可以單獨驗證，也可以 任意組合起來共同驗證，具體驗證方式可以有多種組合，此處不再贅述。步驟206、PPG根據(jù)上述驗證的結(jié)果，進行相關處理。具體地，本步驟中，PPG可以根據(jù)上述步驟202中客戶端在注冊或簽約業(yè)務過 程中在PPG上設置的或網(wǎng)絡運營商在PPG上設置的預設策略，進行相關處理。其中的預 設策略可以包括一個若通過驗證則指示PPG完成驗證URI索引的信息的相關屬性信息 之后，向客戶端發(fā)送具體內(nèi)容的指示信息。例如可以通過擴展相關消息的頭域“傳遞方 式”(“Deliver-Method”)，當取值為“URI”時，指示PPG向客戶端發(fā)送上述URI ；當取值為 “內(nèi)容” ("Content")時，指示PPG向客戶端發(fā)送上述URI索引的信息。進一步地，上述預設策略還可以進一步包括一個指示PPG完成驗證URI索引的信 息的相關屬性信息之后，是否需要向客戶端發(fā)送驗證結(jié)果的結(jié)果信息。例如可以通過擴展 相關消息的頭域“傳遞驗證結(jié)果”(“Deliver-Validation-Result”)，當取值為“是”(“Yes”) 時，指示PPG需要向客戶端發(fā)送驗證結(jié)果；當取值為“否”(“No”)時，指示PPG不需要向客 戶端發(fā)送驗證結(jié)果。本步驟中，若PPG驗證上述URI索引的信息為安全信息，即通過上述URI索引的信 息的相關屬性信息的驗證，PPG則可以根據(jù)上述預設策略，向客戶端發(fā)送上述URI和/或上 述URI索引的信息，或者進一步再發(fā)送驗證通過的結(jié)果信息；若PPG驗證上述URI索引的信 息為不安全信息，即未通過上述URI索引的信息的相關屬性信息的驗證，PPG則可以根據(jù)上 述預設策略，刪除上述URI索引的信息，并判斷是否向客戶端發(fā)送驗證未通過的結(jié)果信息， 或者刪除或修改上述URI索引的信息中不安全的部分，進一步再發(fā)送上述URI和/或經(jīng)過 過濾(刪除或修改)后的上述URI索引的信息，并判斷是否向客戶端發(fā)送驗證未通過的結(jié) 果fe息。本步驟中，若PPG驗證上述URI索引的信息所屬的類別與客戶端用戶的偏好信息 相匹配，即通過上述URI索引的信息的相關屬性信息的驗證，PPG則可以根據(jù)上述預設策 略，向客戶端發(fā)送上述URI和/或上述URI索引的信息，或者進一步再發(fā)送驗證通過的結(jié)果 信息；若PPG驗證上述URI索引的信息所屬的類別與客戶端用戶的偏好信息不匹配，即未 通過上述URI索引的信息的相關屬性信息的驗證，PPG則可以根據(jù)上述預設策略，刪除上述 URI索引的信息，并判斷是否向客戶端發(fā)送驗證未通過的結(jié)果信息，或者進一步再發(fā)送上述 URI。
本步驟中，若PPG驗證上述URI索引的信息與客戶端的能力信息相匹配，即通過上 述URI索引的信息的相關屬性信息的驗證，PPG則可以根據(jù)上述預設策略，向客戶端發(fā)送上 述URI和/或上述URI索引的信息，或者進一步再發(fā)送驗證通過的結(jié)果信息；本步驟中，若 PPG驗證上述URI索引的信息與客戶端的能力信息不匹配，即未通過上述URI索引的信息的 相關屬性信息的驗證，PPG則可以根據(jù)上述預設策略，刪除上述URI索引的信息，并判斷是 否向客戶端發(fā)送驗證未通過的結(jié)果信息，或者轉(zhuǎn)換上述URI索引的信息成為與客戶端的能 力信息相匹配的信息，進一步再發(fā)送上述URI和/或經(jīng)過轉(zhuǎn)換后的與客戶端的能力信息相 匹配的上述URI索引的信息，并判斷是否向客戶端發(fā)送驗證未通過的結(jié)果信息?？蛇x地，在步驟204之前，PPG還可以對上述URI的安全性進行驗證，例如與不良 URI的數(shù)據(jù)庫進行匹配，若通過上述URI的安全性的驗證，則進一步再與內(nèi)容服務器進行交 互，獲取所述URI索引的信息；若未通過上述URI的安全性的驗證，則執(zhí)行類似步驟206的 操作，即PPG則可以根據(jù)上述預設策略，判斷是否向客戶端發(fā)送驗證未通過的結(jié)果信息，或 者進一步再發(fā)送上述URI。具體地，本實施例中PPG向客戶端發(fā)送的驗證結(jié)果的結(jié)果信息可以至少包括以下 一種"URI鑒權”(“URI-Authentication”)，取值指示該URI是否為可信任的網(wǎng)址；"URI 鑒權的數(shù)目，，(“URI-Authentication-Number”)，取值指示完成 URI 驗證的 數(shù)目；“內(nèi)容驗證”(“Content-Validation”)，取值指示該URI索引的信息經(jīng)過驗證，是 否為安全信息；“內(nèi)容類型”(“Content-Type”)，取值指示該U RI索引的信息包含的內(nèi)容類型， 例如文本、圖片、音頻、視頻等內(nèi)容類型；“內(nèi)容處理”(“Content-Processing”)，取值指示該URI索引的信息是否經(jīng)過PPG 的處理，例如過濾(刪除、修改)、轉(zhuǎn)換等；“內(nèi)容處理的次數(shù)” (“Content-Processing-Number”)，取值指示該URI索引的信 息經(jīng)過PPG的處理次數(shù)，例如過濾了多少個部分；“內(nèi)容告警”(“Content-Warning”)，取值指示該URI索引的信息是否被懷疑有安全隱患；“內(nèi)容配置文件”(“Content-Profile”)，取值指示該URI索引的信息的配置信息， 例如此URI內(nèi)容為教育、18歲以上、性別、娛樂、新聞等類別，客戶端用戶還可以根據(jù)此信 息選擇是否取回該URI索引的信息；"URI取回”(“URI-Retrieve”)，取值指示該URI索引的信息是否成功取回；"URI取回失敗原因”(“URI-Retrieve-Fail-Reason”)，取值指示該URI索引的信 息未成功取回的原因。本實施例中，步驟202中若PPG上沒有設置預設策略，可替換地，PPG還可以直接 執(zhí)行步驟203中的現(xiàn)有流程中通過空中協(xié)議(Over The Air，簡稱OTA)向客戶端發(fā)送上述 攜帶有URI的推送消息的步驟，客戶端接收到該推送消息之后，可以在對應的響應消息中 攜帶有一驗證指示信息，例如URI-Validati0n-hdicat0r，以指示PPG需要對所述URI索 引的信息的相關屬性信息進行驗證。
本實施例中，若步驟204中的PPG無法獲取上述URI索引的信息，例如PPG沒有獲 取到權限信息，沒有通過內(nèi)容服務器的鑒權認證過程，PPG則可以將操作結(jié)果封裝在上述推 送消息中，一同發(fā)送給客戶端?？蛻舳丝梢酝ㄟ^判斷，進一步自行取回該URI索引的信息， 或者向PPG發(fā)送權限信息，由PPG依次執(zhí)行上述步驟204、步驟205和步驟206。本實施例中，在推送分發(fā)技術中，PPG獲取到推送消息中所攜帶的URI索引的信息 之后，通過對該URI索引的信息的相關屬性信息進行驗證，使得PPG可以根據(jù)驗證的結(jié)果 進行相關處理，能夠避免客戶端遭受病毒攻擊，從而防止了客戶端的操作系統(tǒng)的損壞和客 戶端用戶的個人信息的泄露，以及能夠避免客戶端接收到無用的垃圾信息和無法顯示的信 息，從而節(jié)省了網(wǎng)絡資源。進一步地，本實施例步驟206中，還可以根據(jù)客戶端、運營商等預先在PPG上的 設置的預設策略，向客戶端發(fā)送具體內(nèi)容，例如PPG可以在驗證結(jié)束之后，立即向客戶端 發(fā)送具體內(nèi)容；PPG還可以在驗證結(jié)束之后，先緩存將要發(fā)送的具體內(nèi)容，在預定時刻到達 時，再向客戶端發(fā)送具體內(nèi)容。PPG采用先緩存的方式，可以避免客戶端不斷接收到URI和 /或URI索引的信息和/或驗證的結(jié)果信息，甚至不斷根據(jù)URI進行獲取其索引的信息的操 作，使得客戶端用戶不會被上述信息頻繁打擾，從而節(jié)省了客戶端操作和緩存的資源。需要說明的是本實施例中，獲取上述URI索引的信息、以及驗證所獲取到的上述 URI索引的信息的相關屬性信息的操作可以由PPG執(zhí)行，還可以通過PPG與外部服務器建 立接口，交由外部服務器執(zhí)行。例如可以由PPG獲取上述URI索引的信息，交由外部服務 器驗證其相關屬性信息；還可以將上述URI傳遞給外部服務器，由外部服務器獲取上述URI 索引的信息、以及驗證其相關屬性信息，并將獲取到的通過驗證的上述URI索引的信息和/ 或驗證結(jié)果的結(jié)果信息。圖3為本發(fā)明實施例三提供的一種URI索引的信息的處理方法的流程示意圖，本 實施例的URI索引的信息的處理方法是基于主動請求分發(fā)技術實現(xiàn)的，如圖3所示，本實施 例的URI索引的信息的處理方法可以包括以下步驟步驟301、客戶端獲取URI ；本步驟中，客戶端獲取到URI的途徑有很多種，例如可以從消息發(fā)送服務器獲 取，還可以在瀏覽網(wǎng)頁的過程中獲取等，此處不再一一舉例。步驟302、客戶端根據(jù)預設策略，判斷是否需要對上述URI索引的信息的相關屬性 信息進行驗證，如果不需要驗證，則執(zhí)行步驟303 ；如果需要驗證，則執(zhí)行步驟304 ；步驟303、客戶端執(zhí)行現(xiàn)有流程中的與內(nèi)容服務器進行交互，獲取上述URI索引的 信息，此處不再贅述；步驟304、客戶端向驗證服務器發(fā)送攜帶有上述URI的驗證請求消息，上述驗證請 求消息中攜帶有驗證指示信息(URI-Validation-hdicator)，以指示驗證服務器需要對所 述URI索引的信息的相關屬性信息進行驗證；本步驟中，客戶端可以將驗證指示信息攜帶在HTTP消息、SIP消息、短消息等消息 的消息頭域、消息值域或消息體中。可選地，本步驟中的驗證請求消息也可以不攜帶上述驗證指示信息，通過在驗證 服務器上設置相應的預設策略，也可以指示驗證服務器在接收到攜帶有上述URI的驗證 請求消息之后，判斷出需要對所述URI索引的信息的相關屬性信息進行驗證，并執(zhí)行步驟305。步驟305、驗證服務器與內(nèi)容服務器進行交互，獲取上述URI索引的信息；本步驟中，在驗證服務器與內(nèi)容服務器進行交互的過程中，內(nèi)容服務器可能需要 執(zhí)行鑒權認證過程，即內(nèi)容服務器需要獲取到客戶端的授權信息、鑒權信息(密鑰)等權限 信息之后，才可以向驗證服務器提供上述URI索引的信息。類似地，上述權限信息可以像上述PPG上設置的預設策略一樣，由客戶端在注冊 或簽約業(yè)務過程中在驗證服務器上設置。若驗證服務器上沒有預先設置客戶端的權限信 息，驗證服務器則需要通過授權請求消息向客戶端獲取權限信息，驗證服務器將獲取到的 權限信息提供給內(nèi)容服務器，內(nèi)容服務器對該權限信息鑒權通過之后，才能向驗證服務器 提供上述URI索引的信息。步驟306、驗證服務器驗證所獲取到的上述U RI索引的信息的相關屬性信息；其中的上述URI索引的信息的相關屬性信息可以包括URI索引的信息的安全性、 URI索引的信息所屬的類別(例如教育、18歲以上、性別、娛樂、新聞等類別)、與URI索弓丨 的信息匹配的能力信息等信息。具體地，驗證服務器可以驗證上述URI索引的信息的安全 性，具體方法可以參照有關信息的安全性檢驗的相關技術，此處不再贅述；驗證服務器也可 以驗證上述URI索引的信息所屬的類別是否與客戶端用戶的偏好信息相匹配；驗證服務器 還可以驗證上述URI索引的信息是否與客戶端的能力信息相匹配。需要說明的是上述驗 證可以單獨驗證，也可以任意組合起來共同驗證，具體驗證方式可以有多種組合，此處不再 贅述。步驟307、驗證服務器根據(jù)上述驗證的結(jié)果，進行相關處理。具體地，本步驟中，驗證服務器可以根據(jù)客戶端在注冊或簽約業(yè)務過程中在驗證 服務器上設置的預設策略，進行相關處理。其中的預設策略可以包括一個若通過驗證則指 示驗證服務器完成驗證URI索引的信息的相關屬性信息之后，向客戶端發(fā)送具體內(nèi)容的指 示信息。例如可以通過擴展相關消息的頭域“傳遞方式”(“Deliver-Method”)，當取值為 “URI”時，指示驗證服務器向客戶端發(fā)送上述URI ；當取值為“內(nèi)容”(“Content”)時，指示 驗證服務器向客戶端發(fā)送上述URI索引的信息。進一步地，上述預設策略還可以進一步包括一個指示驗證服務器完成驗證URI索 引的信息的相關屬性信息之后，是否需要向客戶端發(fā)送驗證結(jié)果的結(jié)果信息。例如可以 通過擴展相關消息的頭域“傳遞驗證結(jié)果”(“Deliver-Validation-Result”)，當取值為 “是”(“Yes”)時，指示驗證服務器需要向客戶端發(fā)送驗證結(jié)果；當取值為“否”(“No”)時， 指示驗證服務器不需要向客戶端發(fā)送驗證結(jié)果。本步驟中，若驗證服務器驗證上述URI索引的信息為安全信息，即通過上述URI索 引的信息的相關屬性信息的驗證，驗證服務器則可以根據(jù)上述預設策略，向客戶端發(fā)送上 述URI和/或上述URI索引的信息，或者進一步再發(fā)送驗證通過的結(jié)果信息；若驗證服務器 驗證上述URI索引的信息為不安全信息，即未通過上述URI索引的信息的相關屬性信息的 驗證，驗證服務器則可以根據(jù)上述預設策略，刪除上述URI索引的信息，并判斷是否向客戶 端發(fā)送驗證未通過的結(jié)果信息，或者刪除或修改上述URI索引的信息中不安全的部分，進 一步再發(fā)送上述URI和/或經(jīng)過過濾(刪除或修改)后的上述URI索引的信息，并判斷是 否向客戶端發(fā)送驗證未通過的結(jié)果信息。
本步驟中，若驗證服務器驗證上述URI索引的信息所屬的類別與客戶端用戶的偏 好信息相匹配，即通過上述URI索引的信息的相關屬性信息的驗證，驗證服務器則可以根 據(jù)上述預設策略，向客戶端發(fā)送上述URI和/或上述URI索引的信息，或者進一步再發(fā)送驗 證通過的結(jié)果信息；若驗證服務器驗證上述URI索引的信息所屬的類別與客戶端用戶的偏 好信息不匹配，即未通過上述URI索引的信息的相關屬性信息的驗證，驗證服務器則可以 根據(jù)上述預設策略，刪除上述URI索引的信息，并判斷是否向客戶端發(fā)送驗證未通過的結(jié) 果信息，或者進一步再發(fā)送上述URI。本步驟中，若驗證服務器驗證上述URI索引的信息與客戶端的能力信息相匹配， 即通過上述URI索引的信息的相關屬性信息的驗證，驗證服務器則可以根據(jù)上述預設策 略，向客戶端發(fā)送上述URI和/或上述URI索引的信息，或者進一步再發(fā)送驗證通過的結(jié)果 信息；本步驟中，若驗證服務器驗證上述URI索引的信息與客戶端的能力信息不匹配，即未 通過上述URI索引的信息的相關屬性信息的驗證，驗證服務器則可以根據(jù)上述預設策略， 刪除上述URI索引的信息，并判斷是否向客戶端發(fā)送驗證未通過的結(jié)果信息，或者轉(zhuǎn)換上 述URI索引的信息成為與客戶端的能力信息相匹配的信息，進一步再發(fā)送上述URI和/或 經(jīng)過轉(zhuǎn)換后的與客戶端的能力信息相匹配的上述URI索引的信息，并判斷是否向客戶端發(fā) 送驗證未通過的結(jié)果信息?？蛇x地，在步驟305之前，驗證服務器還可以對上述URI的安全性進行驗證，例如 與不良URI的數(shù)據(jù)庫進行匹配，若通過上述URI的安全性的驗證，則進一步再與內(nèi)容服務器 進行交互，獲取所述URI索引的信息；若未通過上述URI的安全性的驗證，則執(zhí)行類似步驟 206的操作，即驗證服務器則可以根據(jù)上述預設策略，判斷是否向客戶端發(fā)送驗證未通過的 結(jié)果信息，或者進一步再發(fā)送上述URI。具體地，本實施例中驗證服務器向客戶端發(fā)送的驗證結(jié)果的結(jié)果信息可以至少包 括以下一種"URI鑒權”(“URI-Authentication”)，取值指示該URI是否為可信任的網(wǎng)址；"URI 鑒權的數(shù)目，，(“URI-Authentication-Number”)，取值指示完成 URI 驗證的 數(shù)目；“內(nèi)容驗證” (“Content-Validation”)，取值指示該URI索引的信息經(jīng)過驗證，是 否為安全信息；“內(nèi)容類型”(“Content-Type”)，取值指示該URI索引的信息包含的內(nèi)容類型，例 如文本、圖片、音頻、視頻等內(nèi)容類型；“內(nèi)容處理”(“Content-Processing”)，取值指示該URI索引的信息是否經(jīng)過驗 證服務器的處理，例如過濾(刪除、修改)、轉(zhuǎn)換等；“內(nèi)容處理的次數(shù)” (“Content-Processing-Number”)，取值指示該URI索引的信 息經(jīng)過驗證服務器的處理次數(shù)，例如過濾了多少個部分；“內(nèi)容告警”(“Content-Warning”)，取值指示該URI索引的信息是否被懷疑有安全隱患；“內(nèi)容配置文件”(“Content-Profile”)，取值指示該URI索引的信息的配置信息， 例如此URI內(nèi)容為教育、18歲以上、性別、娛樂、新聞等類別，客戶端用戶還可以根據(jù)此信 息選擇是否取回該URI索引的信息；
"URI取回”(“URI-Retrieve”)，取值指示該URI索引的信息是否成功取回；"URI取回失敗原因”(“URI-Retrieve-Fail-Reason”)，取值指示該URI索引的信 息未成功取回的原因。本實施例中，若步驟305中的驗證服務器無法獲取上述URI索引的信息，例如驗 證服務器沒有獲取到權限信息，沒有通過內(nèi)容服務器的鑒權認證過程，驗證服務器則可以 將操作結(jié)果封裝在上述推送消息中，一同發(fā)送給客戶端?？蛻舳丝梢酝ㄟ^判斷，進一步自行 取回該URI索引的信息，或者向驗證服務器發(fā)送權限信息，由驗證服務器依次執(zhí)行上述步 驟305、步驟306和步驟307。本實施例中，在主動請求分發(fā)技術中，驗證服務器獲取到驗證請求消息中所攜帶 的URI索引的信息之后，通過對該URI索引的信息的相關屬性信息進行驗證，使得驗證服務 器可以根據(jù)驗證的結(jié)果進行相關處理，能夠避免客戶端遭受病毒攻擊，從而防止了客戶端 的操作系統(tǒng)的損壞和客戶端用戶的個人信息的泄露，以及能夠避免客戶端接收到無用的垃 圾信息和無法顯示的信息，從而節(jié)省了網(wǎng)絡資源。進一步地，本實施例步驟307中，還可以根據(jù)客戶端、運營商等預先在驗證服務器 上的設置的預設策略，向客戶端發(fā)送具體內(nèi)容，例如驗證服務器可以在驗證結(jié)束之后，立 即向客戶端發(fā)送具體內(nèi)容；驗證服務器還可以在驗證結(jié)束之后，先緩存將要發(fā)送的具體內(nèi) 容，在預定時刻到達時，再向客戶端發(fā)送具體內(nèi)容。驗證服務器采用先緩存的方式，可以避 免客戶端不斷接收到URI和/或URI索引的信息和/或驗證的結(jié)果信息，甚至不斷根據(jù)URI 進行獲取其索引的信息的操作，使得客戶端用戶不會被上述信息頻繁打擾，從而節(jié)省了客 戶端操作和緩存的資源?？商鎿Q地，本實施例的步驟302中，客戶端對“是否需要對上述URI索引的信息的 相關屬性信息進行驗證”還可以不進行判斷，直接向驗證服務器發(fā)送攜帶有上述URI的請求 消息，由驗證服務器根據(jù)預設策略，判斷“是否需要對上述URI索引的信息的相關屬性信息 進行驗證”。如果不需要驗證，執(zhí)行正常流程，客戶端直接獲取上述URI索引的信息；如果需 要驗證，驗證服務器則與內(nèi)容服務器進行交互，獲取并驗證上述URI索引的信息。需要說明的是本實施例中，獲取上述URI索引的信息、以及驗證所獲取到的上述 URI索引的信息的相關屬性信息的操作可以由一個單獨的具有驗證功能的物理實體即驗證 服務器執(zhí)行，還可以由運行在代理、網(wǎng)關、業(yè)務服務器等服務器上的具有驗證功能的單元只 執(zhí)行。圖4為本發(fā)明實施例四提供的另一種URI索引的信息的處理方法的流程示意圖， 本實施例的URI索引的信息的處理方法是基于推送分發(fā)技術實現(xiàn)的，如圖4所示，本實施例 的URI索引的信息的處理方法可以包括以下步驟步驟401、PPG接收攜帶有URI和獲取上述URI索引的信息的時間指示信息的請求 消息；其中的URI可以是單獨一個URI，還可以是嵌入在網(wǎng)頁頁面中的URI。本實施例 可以適用于⑶N系統(tǒng)中的推送分發(fā)技術，其中，PPG接收到的請求消息是PI所發(fā)送的推送 消息。具體地，上述推送消息可以攜帶一個指示信息和時間信息指示信息用于指示PPG 是否需要定期取回該URI索引的信息，發(fā)送給客戶端；時間信息用于指示PPG取回該URI 索引的信息的時間周期(時刻)。其中的指示信息可以通過擴展PAP的消息(即推送消息)實現(xiàn)，例如擴展頭域“取回指示”(“X-Wap-Retrieval-Indicatior”)，當取值為“取 回”(“Retrieval”)或“是”(“Yes”)時，指示PPG需要定期取回該URI索引的信息；當取 值為“發(fā)送” ("Send")或“否” (“No”)時，指示PPG不需要取回該URI索引的信息，直接 將該攜帶有URI的請求消息發(fā)送給客戶端。類似地，其中的時間信息也可以通過擴展PAP的 消息(即推送消息)實現(xiàn)，例如擴展頭域“取回間隔” ("X-ffap-Retrieval-Interval"), 取值指示PPG取回該URI索引的信息的時間間隔，例如若取值為3600s，則指示PPG每隔 3600s向PI獲取一次此URI索引的信息。進一步地，本實施例中的上述請求消息還可以攜帶有有效時間信息，用于指示PPG 根據(jù)上述時間指示信息取回該URI索引的信息的有效時間范圍，可以通過擴展PAP的消息 (即推送消息)實現(xiàn)，例如擴展頭域“失效” (“Expire”)，取值指示PPG停止取回該URI 索引的信息的時刻。本實施例中步驟401之后，PI還可以接收到PPG根據(jù)上述攜帶有URI的請求消息 所返回的響應消息。步驟402、PPG根據(jù)上述時間指示信息，獲取上述URI索引的信息；步驟403、PPG根據(jù)預先設置的預設策略，向客戶端發(fā)送上述URI索引的信息。本步驟中，PPG根據(jù)上述時間指示信息定期取回該URI索引的信息之后，還可以根 據(jù)客戶端、運營商等預先在PPG上的設置的預設策略，向客戶端發(fā)送該URI索引的信息，節(jié) 省了客戶端由于不斷獲取并存儲URI索引的信息所耗費的電量。例如PPG定期取回該URI 索引的信息之后，立即向客戶端發(fā)送；PPG定期取回該URI索引的信息之后，先緩存該URI 索引的信息，在預定時刻到達時，向客戶端發(fā)送。可選地，本發(fā)明實施例中，PPG還可以不解析上述PI所發(fā)送的攜帶有URI的請求 消息，直接將其發(fā)送給客戶端，由客戶端進行相應的操作，此處不再贅述。本實施例中，通過PI發(fā)送的攜帶有URI和獲取上述URI索引的信息的時間指示信 息的請求消息，以及PPG根據(jù)上述時間指示信息獲取上述URI索引的信息，可以使得PI無 需重復發(fā)送索引定時更新信息的URI，能夠避免PPG和客戶端重復接收到上索引定時更新 信息的URI，從而節(jié)省了網(wǎng)絡資源。本實施例中，在PPG獲取到上述URI索引的信息之后，以及向客戶端發(fā)送之前，還 可以執(zhí)行上述本發(fā)明實施例一和上述本發(fā)明實施例二中的有關驗證所獲取到的上述URI 索引的信息的相關屬性信息以及后續(xù)操作，具體可以參見上述本發(fā)明實施例一和上述本發(fā) 明實施例二，此處不再贅述。需要說明的是本實施例中，完成上述獲取以及向客戶端發(fā)送上述URI索引的信 息操作的實體不局限于PPG，其他能夠完成此功能的推送服務器或通過擴展接口、功能模塊 等完成相同功能的推送服務器都在保護范圍內(nèi)。圖5為本發(fā)明實施例五提供的再一種URI索引的信息的處理方法的流程示意圖， 本實施例的URI索引的信息的處理方法是基于推送分發(fā)技術實現(xiàn)的，如圖5所示，本實施例 的URI索引的信息的處理方法可以包括以下步驟步驟501、PPG接收攜帶有URI的請求消息；其中的URI可以是單獨一個URI，還可以是嵌入在網(wǎng)頁頁面中的URI。本實施例可 以適用于⑶N系統(tǒng)中的推送分發(fā)技術，其中，PPG所接收到的請求消息是PI消息。步驟502、若存在至少兩個客戶端，PPG則獲取上述URI索引的信息；其中對于是否存在多個(至少兩個客戶端)客戶端的判斷可以采用現(xiàn)有技術中 PPG對客戶端的判斷方法，此處不再贅述。
進一步地，本實施例中，PPG在獲取上述URI索引的信息之前還可以進一步對客戶 端的具體數(shù)目進行判斷，若判斷出客戶端的數(shù)目超過預設閾值，PPG則與內(nèi)容服務器進行交 互，獲取上述URI索引的信息，否則，仍然執(zhí)行現(xiàn)有流程中向客戶端發(fā)送攜帶有URI的請求 消息。其中的預設閾值可以由PI預先在PPG上設置，可以通過擴展PAP的消息(即推送消 息)實現(xiàn)，例如擴展頭域“最大目標取回”(“X-Wap-Maxtarget-Retrieval”)，取值指示 PPG需要取回該URI索引的信息時的最大客戶端的數(shù)目。步驟503、PPG向上述客戶端發(fā)送上述URI索引的信息。本步驟中，PPG可以根據(jù)獲取URI索引的信息的內(nèi)容大小、客戶端的設置、客 戶端的能力信息、和/或網(wǎng)絡情況，選擇適當?shù)某休d方式，將所獲取的上述URI索引的 信息發(fā)送給客戶端，例如廣播信道、組播信道、單播等方式，具體包括多媒體廣播組 播業(yè)務(Multimedia Broadcast/Multicast Service，簡稱 MBMS)、移動寬帶數(shù)字廣播 (Broadcasting)業(yè)務、小區(qū)廣播業(yè)務(Cell Broadcast Service，簡稱CBS)、會話初始協(xié) Χ (Session Initiation Protocol，簡稱 SIP)、超文本傳輸協(xié)議(Hyper Text Transfer ftOtocol，簡稱HTTP)等承載方式。本實施例中，通過PPG判斷出存在至少兩個客戶端時，獲取到請求消息中所攜帶 的URI索引的信息發(fā)送給客戶端，能夠避免多個客戶端同時根據(jù)該URI向內(nèi)容服務器請求 獲取索引的信息，從而防止了網(wǎng)絡的擁塞，提高了信息獲取的效率。本實施例中，在PPG獲取到上述URI索引的信息之后，以及向目標客戶端發(fā)送之 前，還可以執(zhí)行上述本發(fā)明實施例一和上述本發(fā)明實施例二中的有關驗證所獲取到的上述 URI索引的信息的相關屬性信息以及后續(xù)操作，具體可以參見上述本發(fā)明實施例一和上述 本發(fā)明實施例二，此處不再贅述。需要說明的是本實施例中，完成上述獲取以及向客戶端發(fā)送上述URI索引的信 息操作的實體不局限于PPG，其他能夠完成此功能的推送服務器或通過擴展接口、功能模塊 等完成相同功能的推送服務器都在保護范圍內(nèi)。需要說明的是對于前述的各方法實施例，為了簡單描述，故將其都表述為一系列 的動作組合，但是本領域技術人員應該知悉，本發(fā)明并不受所描述的動作順序的限制，因為 依據(jù)本發(fā)明，某些步驟可以采用其他順序或者同時進行。其次，本領域技術人員也應該知 悉，說明書中所描述的實施例均屬于優(yōu)選實施例，所涉及的動作和模塊并不一定是本發(fā)明 所必須的。在上述實施例中，對各個實施例的描述都各有側(cè)重，某個實施例中沒有詳述的部 分，可以參見其他實施例的相關描述。圖6為本發(fā)明實施例六提供的一種URI索引的信息的處理裝置的結(jié)構示意圖，如 圖6所示，本實施例的URI索引的信息的處理裝置可以包括第一接收模塊61、第一獲取模塊 62、第一驗證模塊63和處理模塊64。其中，第一接收模塊61接收攜帶有URI的請求消息， 第一獲取模塊62獲取上述URI索引的信息，第一驗證模塊63驗證第一獲取模塊62所獲取的上述URI索引的信息的相關屬性信息，處理模塊64根據(jù)第一驗證模塊63進行的上述驗 證的結(jié)果，進行相關處理。其中的URI可以是單獨一個URI，還可以是嵌入在網(wǎng)頁頁面中的 URI。上述本發(fā)明實施例二中設備PPG、本發(fā)明實施例三中設備驗證服務器的功能均可 以由本發(fā)明實施例提供的URI索引的信息的處理裝置實現(xiàn)。本實施例可以適用于⑶N系統(tǒng)中的任何一種內(nèi)容分發(fā)技術對于推送分發(fā)技術來 說，第一接收模塊61可以包括第一接收單元611，用于接收PI所發(fā)送的攜帶有URI的Push 消息；對于主動請求分發(fā)技術來說，第一接收模塊61可以包括第二接收單元612，用于接收 客戶端(主動請求客戶端)所發(fā)送的攜帶有URI的HTTP消息、SIP消息、短消息等消息。需要說明的是在推送分發(fā)技術中，本實施例提供的URI索引的信息的處理裝置 可以是PPG，還可以是通過接口與PPG通信的外部服務器；在主動請求分發(fā)技術中，本實施 例提供的URI索引的信息的處理裝置可以為一個單獨的具有驗證功能的物理實體即驗證 服務器，還可以為運行在代理、網(wǎng)關、業(yè)務服務器等服務器上的具有驗證功能的單元。其中，第一驗證模塊63所驗證的URI索引的信息的相關屬性信息可以包括URI索 引的信息的安全性、URI索引的信息所屬的類別(例如教育、18歲以上、娛樂、新聞等)、與 URI索引的信息匹配的能力信息(例如支持的版本信息、網(wǎng)絡信息、軟硬件信息、顯示能力 信息等)等信息。若通過第一驗證模塊63進行的上述驗證，處理模塊64則可以向客戶端 發(fā)送該URI和/或該URI索引的信息，或者進一步發(fā)送驗證通過的結(jié)果信息；若未通過第一 驗證模塊63進行的上述驗證，處理模塊64則可以向客戶端發(fā)送至少以下一種信息驗證未 通過的結(jié)果信息；該URI和驗證未通過的結(jié)果信息；該URI、經(jīng)過過濾后的該URI索引的信 息和驗證未通過的結(jié)果信息。其中，驗證的結(jié)果信息的具體內(nèi)容可以參考本發(fā)明實施例二 和本發(fā)明實施例三中的相關內(nèi)容，此處不再贅述。本實施例中，第一獲取模塊獲取到請求消息中所攜帶的URI索引的信息之后，通 過第一驗證模塊對該URI索引的信息的相關屬性信息進行驗證，使得處理模塊可以根據(jù)驗 證的結(jié)果進行相關處理，能夠避免客戶端遭受病毒攻擊，從而防止了客戶端的操作系統(tǒng)的 損壞和客戶端用戶的個人信息的泄露，以及能夠避免客戶端接收到無用的垃圾信息和無法 顯示的信息，從而節(jié)省了網(wǎng)絡資源。圖7為本發(fā)明實施例七提供的一種URI索引的信息的處理裝置的結(jié)構示意圖，本 實施例的URI索引的信息的處理裝置是基于推送分發(fā)技術實現(xiàn)的，如圖7所示，與上一實施 例相比，本實施例的URI索引的信息的處理裝置還可以進一步包括判斷模塊71，用于判斷 是否需要對上述URI索引的信息的相關屬性信息進行驗證，若判斷為是，第一獲取模塊62 則獲取上述URI索引的信息。具體的判斷方法可以參考本發(fā)明實施例二和本發(fā)明實施例三 中的相關內(nèi)容，此處不再贅述。進一步地，本實施例的URI索引的信息的處理裝置還可以進一步包括第二驗證模 塊72，用于驗證上述URI的安全性，若通過第二驗證模塊72進行的上述驗證，第一獲取模 塊62則獲取上述URI索引的信息。具體的驗證方法可以參考本發(fā)明實施例二和本發(fā)明實 施例三中的相關內(nèi)容，此處不再贅述。進一步地，在第一獲取模塊62與內(nèi)容服務器進行交互以獲取上述URI索引的信息 的過程中，內(nèi)容服務器可能需要執(zhí)行鑒權認證過程，即內(nèi)容服務器需要獲取到客戶端用戶的授權信息、鑒權信息(密鑰)等權限信息之后，才可以向PPG提供上述URI索引的信息。 因此，本實施例的URI索引的信息的處理裝置還可以進一步包括權限模塊73，用于向推送 客戶端或主動請求客戶端獲取權限信息，第一獲取模塊62則可以根據(jù)上述權限信息獲取 上述URI索引的信息。具體的獲取權限信息方法可以參考本發(fā)明實施例二和本發(fā)明實施例 三中的相關內(nèi)容，此處不再贅述。圖8為本發(fā)明實施例八提供的一種URI索引的信息的處理系統(tǒng)的結(jié)構示意圖，如 圖8所示，本實施例的URI索引的信息的處理系統(tǒng)可以包括處理服務器81，用于接收攜帶 有URI的請求消息，獲取上述URI索引的信息，驗證上述URI索引的信息的相關屬性信息， 以及根據(jù)上述驗證的結(jié)果，進行相關處理。上述本發(fā)明實施例一的方法、以及本發(fā)明實施例二中設備PPG、本發(fā)明實施例三中 設備驗證服務器的功能均可以由本發(fā)明實施例提供的URI索引的信息的處理系統(tǒng)中的處 理服務器81實現(xiàn)，相關內(nèi)容可以參考本發(fā)明實施例一、本發(fā)明實施例二和本發(fā)明實施例三 中的相關內(nèi)容，此處不再贅述。處理服務器81可以為上述本發(fā)明實施例六或本發(fā)明實施例 七提供的URI索引的信息的處理裝置。本實施例可以適用于CDN系統(tǒng)中的任何一種內(nèi)容分發(fā)技術對于推送分發(fā)技術來 說，處理服務器81所接收到的請求消息是PI(圖中未示出)發(fā)送的Push消息；對于主動請 求分發(fā)技術來說，處理服務器81所接收到的請求消息是主動請求客戶端(圖中未示出)發(fā) 送的HTTP消息、SIP消息、短消息等消息。需要說明的是在推送分發(fā)技術中，本實施例提供的URI索引的信息的處理系統(tǒng) 中的處理服務器81可以是PPG，還可以是通過接口與PPG通信的外部服務器；在主動請求 分發(fā)技術中，本實施例提供的URI索引的信息的處理系統(tǒng)中的處理服務器81可以為一個單 獨的具有驗證功能的物理實體即驗證服務器，還可以為運行在代理、網(wǎng)關、業(yè)務服務器等服 務器上的具有驗證功能的單元。本實施例中，處理服務器獲取到請求消息中所攜帶的URI索引的信息之后，通過 對該URI索引的信息的相關屬性信息進行驗證，使得處理服務器可以根據(jù)驗證的結(jié)果進行 相關處理，能夠避免客戶端遭受病毒攻擊，從而防止了客戶端的操作系統(tǒng)的損壞和客戶端 用戶的個人信息的泄露，以及能夠避免客戶端接收到無用的垃圾信息和無法顯示的信息， 從而節(jié)省了網(wǎng)絡資源。圖9為本發(fā)明實施例九提供的一種推送發(fā)起者的結(jié)構示意圖，本實施例的推送發(fā) 起者是基于推送分發(fā)技術實現(xiàn)的，如圖9所示，本實施例的推送發(fā)起者可以包括第一發(fā)送 模塊91，用于發(fā)送攜帶有URI和獲取上述URI索引的信息的時間指示信息的請求消息，以供 推送服務器或推送客戶端根據(jù)上述時間指示信息，獲取上述URI索引的信息。其中的URI 可以是單獨一個URI，還可以是嵌入在網(wǎng)頁頁面中的URI。上述本發(fā)明實施例四中設備PI的功能可以由本發(fā)明實施例提供的推送發(fā)起者實 現(xiàn)。本實施例可以適用于⑶N系統(tǒng)中的推送分發(fā)技術，其中，第一發(fā)送模塊91所發(fā)送 的請求消息是推送消息。上述推送消息的具體形式可以參考本發(fā)明實施例四中的相關內(nèi) 容，此處不再贅述。本實施例中，通過第一發(fā)送模塊發(fā)送的攜帶有URI和獲取上述URI索引的信息的時間指示信息的請求消息，可以使得推送服務器根據(jù)上述時間指示信息獲取上述URI索引 的信息，使得PI無需重復發(fā)送索引定時更新信息的URI，能夠避免PPG和客戶端重復接收到 上索引定時更新信息的URI，從而節(jié)省了網(wǎng)絡資源。圖10為本發(fā)明實施例十提供的一種推送服務器的結(jié)構示意圖，本實施例的推送 服務器是基于推送分發(fā)技術實現(xiàn)的，如圖10所示，本實施例的推送服務器可以包括第二接 收模塊1001、第二獲取模塊1002和第二發(fā)送模塊1003。其中，第二接收模塊1001接收攜 帶有URI和獲取上述URI索引的信息的時間指示信息的請求消息，第二獲取模塊1002根據(jù) 上述請求消息中的時間指示信息，獲取上述URI索引的信息，第二發(fā)送模塊1003向推送客 戶端發(fā)送第二獲取模塊1002所獲取的上述URI索引的信息。上述本發(fā)明實施例四中設備PPG的功能可以由本發(fā)明實施例提供的推送服務器 實現(xiàn)。本實施例可以適用于⑶N系統(tǒng)中的推送分發(fā)技術，其中，第二接收模塊1001所接 收到的請求消息是PI發(fā)送的推送消息。上述推送消息的具體形式可以參考本發(fā)明實施例 四中的相關內(nèi)容，此處不再贅述。需要說明的是本實施例提供的推送服務器可以是PPG，還可以是通過接口與PPG 通信的外部服務器。本實施例中，通過第二接收模塊接收到的PI發(fā)送的攜帶有URI和獲取上述URI索 引的信息的時間指示信息的請求消息，可以使得第二獲取模塊根據(jù)上述時間指示信息獲取 上述URI索引的信息，使得PI無需重復發(fā)送索引定時更新信息的URI，能夠避免PPG和推送 客戶端重復接收到上索引定時更新信息的URI，從而節(jié)省了網(wǎng)絡資源。圖11為本發(fā)明實施例十一提供的另一種URI索引的信息的處理系統(tǒng)的結(jié)構示意 圖，本實施例的URI索引的信息的處理系統(tǒng)是基于推送分發(fā)技術實現(xiàn)的，如圖11所示，本實 施例的URI索引的信息的處理系統(tǒng)可以包括第一推送發(fā)起者1101、第一推送服務器1102和 第一推送客戶端1103。其中，第一推送發(fā)起者1101發(fā)送攜帶有URI和獲取上述URI索引的 信息的時間指示信息的請求消息，第一推送服務器1102接收第一推送發(fā)起者1101所發(fā)送 的上述請求消息，根據(jù)上述時間指示信息，獲取上述URI索引的信息，以及發(fā)送上述URI索 引的信息，第一推送客戶端1103接收第一推送服務器1102所發(fā)送的上述URI索引的信息。上述本發(fā)明實施例四中設備PPG的功能可以由本發(fā)明實施例提供的URI索引的信 息的處理系統(tǒng)中的第一推送服務器1102實現(xiàn)，相關內(nèi)容可以參考本發(fā)明實施例四中的相 關內(nèi)容，此處不再贅述。第一推送服務器1102可以為上述本發(fā)明實施例十提供的推送服務ο需要說明的是本實施例提供的URI索引的信息的處理系統(tǒng)中的第一推送服務器 1102可以是PPG，還可以是通過接口與PPG通信的外部服務器。本實施例中，通過第一推送發(fā)起者發(fā)送攜帶有URI和獲取上述URI索引的信息的 時間指示信息的請求消息，以及第一推送服務器根據(jù)上述時間指示信息獲取上述URI索引 的信息，可以使得第一推送發(fā)起者無需重復發(fā)送索引定時更新信息的URI，能夠避免PPG和 第一推送客戶端重復接收到上索引定時更新信息的URI，從而節(jié)省了網(wǎng)絡資源。圖12為本發(fā)明實施例十二提供的一種推送客戶端的結(jié)構示意圖，本實施例的推 送客戶端是基于推送分發(fā)技術實現(xiàn)的，如圖12所示，本實施例的推送客戶端可以包括第三接收模塊1201和第三獲取模塊1202。其中，第三接收模塊1201接收攜帶有URI和獲取上 述URI索引的信息的時間指示信息的請求消息，第三獲取模塊1202根據(jù)上述時間指示信 息，獲取上述URI索引的信息。上述本發(fā)明實施例四中設備客戶端的功能可以由本發(fā)明實施例提供的推送客戶 端實現(xiàn)。本實施例可以適用于⑶N系統(tǒng)中的推送分發(fā)技術，其中，第三接收模塊1201所接 收到的請求消息是PI發(fā)送的推送消息。上述推送消息的具體形式可以參考本發(fā)明實施例 四中的相關內(nèi)容，此處不再贅述。本實施例中，通過第三接收模塊接收到的PI發(fā)送的攜帶有URI和獲取上述URI索 引的信息的時間指示信息的請求消息，可以使得第三獲取模塊根據(jù)上述時間指示信息獲取 上述URI索引的信息，使得PI無需重復發(fā)送索引定時更新信息的URI，能夠避免PPG和推送 客戶端重復接收到上索引定時更新信息的URI，從而節(jié)省了網(wǎng)絡資源。圖13為本發(fā)明實施例十三提供的再一種URI索引的信息的處理系統(tǒng)的結(jié)構示意 圖，本實施例的URI索引的信息的處理系統(tǒng)是基于推送分發(fā)技術實現(xiàn)的，如圖13所示，本實 施例的URI索引的信息的處理系統(tǒng)可以包括第二推送發(fā)起者1301、第二推送服務器1302和 第二推送客戶端1303。其中，第二推送發(fā)起者1301發(fā)送攜帶有URI和獲取上述URI索引的 信息的時間指示信息的請求消息，第二推送服務器1302接收第二推送發(fā)起者1301所發(fā)送 的上述請求消息，并轉(zhuǎn)發(fā)上述請求消息，第二推送客戶端1303接收第二推送服務器1302所 轉(zhuǎn)發(fā)的上述請求消息，根據(jù)上述時間指示信息，獲取上述URI索引的信息。上述本發(fā)明實施例四中設備客戶端的功能可以由本發(fā)明實施例提供的URI索引 的信息的處理系統(tǒng)中的第二推送客戶端1303實現(xiàn)，相關內(nèi)容可以參考本發(fā)明實施例四中 的相關內(nèi)容，此處不再贅述。第二推送客戶端1303可以為上述本發(fā)明實施例十二提供的推 送客戶端。本實施例中，通過第二推送發(fā)起者發(fā)送攜帶有URI和獲取上述URI索引的信息的 時間指示信息的請求消息，并由第二推送服務器轉(zhuǎn)發(fā)上述請求消息，以及第二推送客戶端 根據(jù)上述時間指示信息獲取上述URI索引的信息，可以使得第二推送發(fā)起者無需重復發(fā)送 索引定時更新信息的URI，能夠避免PPG和第二推送客戶端重復接收到上索引定時更新信 息的URI，從而節(jié)省了網(wǎng)絡資源。圖14為本發(fā)明實施例十四提供的另一種推送服務器的結(jié)構示意圖，本實施例的 推送服務器是基于推送分發(fā)技術實現(xiàn)的，如圖14所示，本實施例的推送服務器可以包括第 四接收模塊1401、第四獲取模塊1402和第三發(fā)送模塊1403。其中，第四接收模塊1401接 收攜帶有URI的請求消息，若存在至少兩個推送客戶端，第四獲取模塊1402則獲取上述URI 索引的信息，第三發(fā)送模塊1403向上述至少兩個推送客戶端發(fā)送第四獲取模塊1402所獲 取的上述URI索引的信息。上述本發(fā)明實施例五中設備PPG的功能可以由本發(fā)明實施例提供的推送服務器 實現(xiàn)。本實施例可以適用于⑶N系統(tǒng)中的推送分發(fā)技術，其中，第四接收模塊1401所接 收到的請求消息是PI發(fā)送的推送消息。上述推送消息的具體形式可以參考本發(fā)明實施例 五中的相關內(nèi)容，此處不再贅述。
需要說明的是本實施例提供的推送服務器可以是PPG，還可以是通過接口與PPG 通信的外部服務器。本實施例中，通過第四獲取模塊判斷出存在至少兩個推送客戶端時，獲取到請求 消息中所攜帶的URI索引的信息，并由第三發(fā)送模塊發(fā)送給推送客戶端，能夠避免多個推 送客戶端同時根據(jù)該URI向內(nèi)容服務器請求獲取索引的信息，從而防止了網(wǎng)絡的擁塞，提 高了信息獲取的效率。進一步地，本實施例中，第四獲取模塊1402還可以進一步對推送客戶端的具體數(shù) 目進行判斷，若判斷出存在至少兩個推送客戶端之后，進一步判斷出推送客戶端的數(shù)目超 過預設閾值，第四獲取模塊1402則獲取上述URI索引的信息。圖15為本發(fā)明實施例十五提供的又一種URI索引的信息的處理系統(tǒng)的結(jié)構示意 圖，本實施例的URI索引的信息的處理系統(tǒng)是基于推送分發(fā)技術實現(xiàn)的，如圖15所示，本實 施例的URI索引的信息的處理系統(tǒng)可以包括第三推送發(fā)起者1501、第三推送服務器1502 和第三推送客戶端1503。其中，第三推送發(fā)起者1501發(fā)送攜帶有URI的請求消息，第三推 送服務器1502接收第三推送發(fā)起者1501所發(fā)送的上述攜帶有URI的請求消息，若存在至 少兩個第三推送客戶端1503，獲取上述URI索引的信息，向上述至少兩個第三推送客戶端 1503發(fā)送上述URI索引的信息，第三推送客戶端1503接收第三推送服務器1502所發(fā)送的 上述URI索引的信息。上述本發(fā)明實施例五中設備PPG的功能可以由本發(fā)明實施例提供的URI索引的信 息的處理系統(tǒng)中的第三推送服務器1502實現(xiàn)，相關內(nèi)容可以參考本發(fā)明實施例五中的相 關內(nèi)容，此處不再贅述。第三推送服務器1502可以為上述本發(fā)明實施例十四提供的推送服 務器。需要說明的是本實施例提供的URI索引的信息的處理系統(tǒng)中的第三推送服務器 1502可以是PPG，還可以是通過接口與PPG通信的外部服務器。本實施例中，通過第三推送服務器判斷出存在至少兩個推送客戶端時，獲取到請 求消息中所攜帶的URI索引的信息發(fā)送給第三推送客戶端，能夠避免多個第三推送客戶端 同時根據(jù)該URI向內(nèi)容服務器請求獲取索引的信息，從而防止了網(wǎng)絡的擁塞，提高了信息 獲取的效率。本領域普通技術人員可以理解實現(xiàn)上述方法實施例的全部或部分步驟可以通過 程序指令相關的硬件來完成，前述的程序可以存儲于一計算機可讀取存儲介質(zhì)中，該程序 在執(zhí)行時，執(zhí)行包括上述方法實施例的步驟；而前述的存儲介質(zhì)包括R0M、RAM、磁碟或者 光盤等各種可以存儲程序代碼的介質(zhì)。最后應說明的是以上實施例僅用以說明本發(fā)明的技術方案，而非對其限制；盡 管參照前述實施例對本發(fā)明進行了詳細的說明，本領域的普通技術人員應當理解其依然 可以對前述各實施例所記載的技術方案進行修改，或者對其中部分技術特征進行等同替 換；而這些修改或者替換，并不使相應技術方案的本質(zhì)脫離本發(fā)明各實施例技術方案的精 神和范圍。
權利要求
1.一種統(tǒng)一資源標識符URI索引的信息的處理方法，其特征在于，包括 接收攜帶有URI的請求消息；獲取所述URI索引的信息； 驗證所述URI索引的信息的相關屬性信息； 根據(jù)所述驗證的結(jié)果，進行相關處理。
2.根據(jù)權利要求1所述的方法，其特征在于，所述接收攜帶有URI的請求消息包括 接收推送發(fā)起者所發(fā)送的攜帶有URI的請求消息；或者接收主動請求客戶端所發(fā)送的攜帶有URI的請求消息。
3.根據(jù)權利要求1或2所述的方法，其特征在于，所述接收攜帶有URI的請求消息之 后，獲取所述URI索引的信息之前還包括根據(jù)預設策略，判斷出需要對所述URI索引的信息的相關屬性信息進行驗證；或者 向推送客戶端發(fā)送所述攜帶有URI的請求消息，根據(jù)接收到的所述推送客戶端根據(jù)所 述請求消息返回的驗證指示信息，判斷出需要對所述URI索引的信息的相關屬性信息進行 驗證；或者根據(jù)所述攜帶有URI的請求消息中攜帶的驗證指示信息，判斷出需要對所述URI索引 的信息的相關屬性信息進行驗證。
4.根據(jù)權利要求1或2所述的方法，其特征在于，所述獲取所述URI索引的信息包括 驗證所述URI的安全性，若通過所述URI的安全性的驗證，則獲取所述URI索引的信息；或者向推送客戶端或主動請求客戶端獲取權限信息，根據(jù)所述權限信息獲取所述URI索引 的信息。
5.根據(jù)權利要求1或2所述的方法，其特征在于，所述驗證所述URI索引的信息的相關 屬性信息至少包括以下一種驗證所述URI索引的信息的安全性；驗證所述URI索引的信息所屬的類別是否與推送客戶端用戶或主動請求客戶端用戶 的偏好信息相匹配；或驗證所述URI索引的信息是否與推送客戶端或主動請求客戶端的能力信息相匹配。
6.根據(jù)權利要求1或2所述的方法，其特征在于，所述根據(jù)所述驗證的結(jié)果，進行相關 處理包括若通過所述URI索引的信息的相關屬性信息的驗證，向推送客戶端或主動請求客戶端 發(fā)送至少以下一種信息 所述URI ；所述URI索引的信息；所述URI和所述驗證通過的結(jié)果信息；或所述URI索引的信息和所述驗證通過的結(jié)果信息；若未通過所述URI索引的信息的相關屬性信息的驗證，向推送客戶端或主動請求客戶 端發(fā)送至少以下一種信息所述驗證未通過的結(jié)果信息； 所述URI和所述驗證未通過的結(jié)果信息；或所述URI、經(jīng)過過濾或轉(zhuǎn)換后的所述URI索引的信息和所述驗證未通過的結(jié)果信息。
7.根據(jù)權利要求6所述的方法，其特征在于，所述若通過所述URI索引的信息的相關屬性信息的驗證，向推送客戶端或主動請求客 戶端發(fā)送至少以下一種信息包括若通過所述URI索引的信息的相關屬性信息的驗證，立即向推送客戶端或主動請求客 戶端發(fā)送至少以下一種信息；或者若通過所述URI索引的信息的相關屬性信息的驗證，緩存至少以下一種信息，在預定 時刻到達時，向推送客戶端或主動請求客戶端發(fā)送至少以下一種信息；所述若未通過所述URI索引的信息的相關屬性信息的驗證，向推送客戶端或主動請求 客戶端發(fā)送至少以下一種信息包括若未通過所述URI索引的信息的相關屬性信息的驗證，立即向推送客戶端或主動請求 客戶端發(fā)送至少以下一種信息；或者若未通過所述URI索引的信息的相關屬性信息的驗證，緩存至少以下一種信息，在預 定時刻到達時，向推送客戶端或主動請求客戶端發(fā)送至少以下一種信息。
8.一種統(tǒng)一資源標識符URI索引的信息的處理方法，其特征在于，包括 接收攜帶有URI和獲取所述URI索引的信息的時間指示信息的請求消息； 根據(jù)所述時間指示信息，獲取所述URI索引的信息；向推送客戶端發(fā)送所述URI索引的信息。
9.根據(jù)權利要求8所述的方法，其特征在于，所述向推送客戶端發(fā)送所述URI索引的信 息包括立即向推送客戶端發(fā)送所述URI索引的信息；或者緩存所述URI索引的信息，在預定時刻到達時，向推送客戶端發(fā)送所述URI索引的信肩、ο
10.根據(jù)權利要求8或9所述的方法，其特征在于，所述請求消息中所攜帶的URI和獲 取所述URI索引的信息的時間指示信息是由推送發(fā)起者生成的，以供推送服務器或推送客 戶端根據(jù)所述時間指示信息，獲取所述URI索引的信息。
11.一種統(tǒng)一資源標識符URI索引的信息的處理方法，其特征在于，包括 接收攜帶有URI的請求消息；若存在至少兩個推送客戶端，獲取所述URI索引的信息； 向所述至少兩個推送客戶端發(fā)送所述URI索引的信息。
12.根據(jù)權利要求11所述的方法，其特征在于，所述若存在至少兩個推送客戶端，獲取 所述URI索引的信息包括若存在至少兩個推送客戶端，且推送客戶端的數(shù)目超過預設閾 值，獲取所述URI索引的信息。
13.根據(jù)權利要求11或12所述的方法，其特征在于，所述向所述至少兩個推送客戶端 發(fā)送所述URI索引的信息包括選擇承載方式，所述承載方式包括至少以下一種承載方式多媒體廣播組播服務承載 方式、移動寬帶數(shù)字廣播多播業(yè)務承載方式、小區(qū)廣播業(yè)務承載方式、會話初始協(xié)議承載方 式、超文本傳輸協(xié)議承載方式；利用所述承載方式向所述至少兩個推送客戶端發(fā)送所述URI索引的信息。
14.一種統(tǒng)一資源標識符URI索引的信息的處理裝置，其特征在于，包括 第一接收模塊，用于接收攜帶有URI的請求消息；第一獲取模塊，用于獲取所述URI索引的信息； 第一驗證模塊，用于驗證所述URI索引的信息的相關屬性信息； 處理模塊，用于根據(jù)所述驗證的結(jié)果，進行相關處理。
15.根據(jù)權利要求14所述的裝置，其特征在于，所述第一接收模塊至少包括以下一種 單元第一接收單元，用于接收推送發(fā)起者所發(fā)送的攜帶有URI的請求消息； 第二接收單元，用于接收主動請求客戶端所發(fā)送的攜帶有URI的請求消息。
16.根據(jù)權利要求14或15所述的裝置，其特征在于，還包括以下至少一種模塊判斷模塊，用于判斷是否需要對所述URI索引的信息的相關屬性信息進行驗證，若判 斷為是，所述第一獲取模塊則獲取所述URI索引的信息；第二驗證模塊，用于驗證所述URI的安全性，若通過所述驗證，所述第一獲取模塊則獲 取所述URI索引的信息；權限模塊，用于向推送客戶端或主動請求客戶端獲取權限信息，所述第一獲取模塊具 體用于根據(jù)所述權限信息獲取所述URI索引的信息。
17.—種推送發(fā)起者，其特征在于，包括第一發(fā)送模塊，用于發(fā)送攜帶有URI和獲取所 述URI索引的信息的時間指示信息的請求消息，以供推送服務器或推送客戶端根據(jù)所述時 間指示信息，獲取所述URI索引的信息。
18.—種推送服務器，其特征在于，包括第二接收模塊，用于接收攜帶有URI和獲取所述URI索引的信息的時間指示信息的請 求消息；第二獲取模塊，用于根據(jù)所述時間指示信息，獲取所述URI索引的信息； 第二發(fā)送模塊，用于向推送客戶端發(fā)送所述URI索引的信息。
19.一種推送客戶端，其特征在于，包括第三接收模塊，用于接收攜帶有URI和獲取所述URI索引的信息的時間指示信息的請 求消息；第三獲取模塊，用于根據(jù)所述時間指示信息，獲取所述URI索引的信息。
20.一種推送服務器，其特征在于，包括第四接收模塊，用于接收攜帶有URI的請求消息；第四獲取模塊，用于若存在至少兩個推送客戶端，獲取所述URI索引的信息； 第三發(fā)送模塊，用于向所述至少兩個推送客戶端發(fā)送所述URI索引的信息。
全文摘要
本發(fā)明實施例涉及統(tǒng)一資源標識符索引的信息的處理方法及裝置，其中一種方法包括接收攜帶有URI的請求消息；獲取所述URI索引的信息；驗證所述URI索引的信息的相關屬性信息；根據(jù)所述驗證的結(jié)果，進行相關處理。本發(fā)明實施例獲取到請求消息中所攜帶的URI索引的信息之后，通過對該URI索引的信息的相關屬性信息進行驗證，使得可以根據(jù)驗證的結(jié)果進行相關處理，能夠避免客戶端接收到無用的垃圾信息，從而節(jié)省了網(wǎng)絡資源。
文檔編號H04L29/08GK102045323SQ200910235358
公開日2011年5月4日 申請日期2009年10月9日 優(yōu)先權日2009年10月9日
發(fā)明者楊健, 王雷, 范姝男 申請人:華為終端有限公司