通信終端配置文件的同步系統和方法
【專利摘要】通信終端配置文件的同步系統和方法，該系統包括如下模塊：推送平臺客戶端，其發動更新配置請求；推送平臺服務器，其發送更新配置應答。該方法包括如下步驟：客戶端發動更新配置請求；服務器端發送更新配置應答。
【專利說明】通信終端配置文件的同步系統和方法
【技術領域】
[0001] 本申請涉及一種通信終端配置文件的同步系統和方法，屬于通信網絡的同步機 制，屬于數字信息傳輸領域。
【背景技術】
[0002] 目前，隨著通信終端在通信網絡中的廣泛應用，尤其是移動網絡中通信終端的廣 泛使用，使得通信終端的配置文件如何及時更新成為非常重要的技術問題。
[0003] 為了實現通信終端配置文件的及時更新，現有技術中主要存在兩種思路。一是通 過通信信息本身的優化，二是通過通信機制本身的優化。
[0004] 第一種思路在于，通過通信信息本身的優化實現通信終端配置文件的及時更新。 這一思路是本領域中較少采用的一種方式。采用這一思路的最新現有技術主要表現為LG 電子株式會社公開的KR20090065417A號韓國專利申請。該專利申請系一種在移動通信系 統中生成和傳送數據的方法，其將0FDM信號配置為至少兩個子信號，然后通過多個載波信 道(例如時分多路模式下的信道和頻分多路模式下的信道)進行傳輸。也就是說，基于0FDM 信號生成的多個子信號通過同步信道加以傳送，從而是實現配置文件的高效更新。然而，顯 然上述方式借助于通信信息本身的優化，加重了通信網絡的通信負擔。
[0005] 第二種思路在于，通過通信機制本身的優化實現通信終端配置文件的及時更新。 這一思路是本領域中較多采用的一種方式。例如，華為科技有限公司提出的W02010031347 號國際專利申請公開了一種多播單頻網絡中信息同步的機制，其設置主網絡控制器和從屬 網絡控制器，主網絡控制器用于將多播單頻網絡配置信息傳送到每個從屬網絡控制器，從 而實現主網絡控制器和從屬網絡控制器的同步，滿足了多播單頻網絡空中接口切換和軟切 換的需要。也就是說，通過主網絡控制器和從屬網絡控制器的設置，提高同步效率。
[0006] 然而，上述方式顯然較大地增加了通信負擔，并且增加了通信網絡的管理難度。為 了較高效率實現通信終端與服務器的數據同步，中興公司提出的W02011082632A號國際專 利申請公開了一種配置信息的發布機制，其中當P2P網絡中的配置信息得以改變的時候， 配置文件服務器向計算機網絡中的引導節點（bootstrap node)發布改變的配置信息，然后 由引導節點向其他非引導節點的通信終端轉發該配置信息。通過這種方式，使得P2P網絡 中的通信終端的配置信息能夠與服務器端的配置信息實時同步。類似地，US2011026704A 號美國專利申請則公開了一種基于網絡配置信息實現用戶群的管理的方法，其中用戶配 置信息存儲于服務器，服務器用于維護和管理上述用戶配置信息，并且啟動相應的用戶識 另IJ。上述方式均以服務器作為配置信息更新的主動方，較大地增加了服務器的負擔。同時， CN1956452A公開了一種實現數據同步的方法，應用于客戶端和服務器之間，該方法包括： 客戶端和服務器中的任一端發送第一同步命令至二者中的另一端；其在發送第一同步命令 之前，客戶端和服務器確定待同步目錄；所述第一同步命令的接收端在收到第一同步命令 之后，按接收到的第一同步命令，對所確定的待同步目錄進行數據同步。其僅僅給出了客戶 端發布同步命令的方式，但是并未對于同步機制本身的效率提高提出可行性思路。
[0007] 現有的方案是每次推送平臺服務器上的信息有變化，都要求客戶端來同步信息。 具體過程參見如說明書附圖1所示。應用配置信息的更新，由第三方應用提供商在發布新 應用，或者更新應用版本的時候，向推送服務器發起。推送平臺服務器在獲得更新的配置信 息后，將更新通知推送到移動終端上的推送平臺客戶端。上述推送通過二進制短信或者IP 連接等方式實現。之后，移動平臺客戶端建立新的IP連接或者使用已有的和推送平臺的連 接，向推送平臺服務器發起更新配置請求。最后，推送平臺服務器將更新的內容下發給推送 平臺客戶端。至此，整個更新過程結束。直到下次配置信息有更新，這里描述的更新過程， 再從頭開始。
[0008] 如圖1所描述的應用配置文件的同步過程主要有兩個缺點：一方面，同步動作過 于頻繁，尤其是那些關于非活躍狀態的應用（用戶很少使用的應用）的信息變更引起的同 步，造成用戶網絡流量的流失和浪費。頻繁的同步也會消耗更多的電量，降低用戶體驗。另 一方面，推送服務器并發壓力大，也就是說，在推送服務器上的應用配置信息更新后，需要 下發大量的更新通知，之后，所有得到通知的推送平臺客戶端會同時向推送平臺服務器發 起更新請求。
[0009] 綜上所述，如何實現高效地通信終端配置文件同步，并且同時降低網絡通信負擔 和服務器信息處理負擔，成為本領域需要解決的技術問題。
【發明內容】
[0010] 為了解決上述技術問題，尤其是存在第三方應用的情況下高效實現通信終端配置 文件的同步，使得第三方應用的廠商提供給推送平臺服務器的關于第三方應用信息不斷更 新，在推送平臺服務器和推送平臺客戶端之間進行同步。從而，在推送平臺服務器上面的存 儲的應用配置信息被更新后，在推送平臺客戶端存儲的配置信息及時進行相應的更新。并 且，在同步過程中有效降低服務器的計算負擔和網絡的通信負擔。也就是說，本發明所要解 決的技術問題是，存在第三方應用的情況下高效實現通信終端配置文件的同步，并且在同 步過程中有效降低服務器的計算負擔和網絡的通信負擔。
[0011] 為了解決上述技術問題，本專利申請提出一種通信終端配置文件的同步系統和方 法。具體內容包括：
[0012] 一種通信終端配置文件同步系統，其包括，推送平臺客戶端，其發動更新配置請 求；推送平臺服務器，其發送更新配置應答。
[0013] 進一步，在該通信終端配置文件同步系統中，當客戶端首次啟動或者客戶端應用 配置文件有所損壞并且無法確定由哪些配置文件所致時，客戶端發送全同步更新配置請 求；當客戶端首次啟動或者客戶端應用配置文件有所損壞并且無法確定由哪些配置文件所 致時，服務器端發送全同步更新配置應答。
[0014] 進一步，在該通信終端配置文件同步系統中，每隔一段時間，客戶端發送部分同步 更新配置請求；每隔一段時間服務器端發送部分同步更新配置應答。
[0015] 進一步，在該通信終端配置文件同步系統中，當客戶端應用配置文件有所損壞并 且可以確定由哪些配置文件所致時，客戶端發送部分同步更新配置請求；當客戶端應用配 置文件有所損壞并且可以確定由哪些配置文件所致時，服務器端發送部分同步更新配置應 答。
[0016] 進一步，在該通信終端配置文件同步系統中，推送平臺服務器會將應用配置的最 新版本信息包裹在推送消息的消息頭中，推送平臺客戶端收到消息后，將消息頭中對應的 應用配置版本與存儲在終端上的應用配置的版本信息進行比較，如果后者已經過期，則向 推送服務器發起對該應用的配置信息的更新請求。
[0017] 相應地，本發明還提供一種通信終端配置文件的同步方法，其特征在于，客戶端發 動更新配置請求；服務器端發送更新配置應答。
[0018] 進一步，在通信終端配置文件同步方法中，當客戶端首次啟動時，客戶端發送全同 步更新配置請求；當客戶端首次啟動時，服務器端發送全同步更新配置應答。
[0019] 進一步，在通信終端配置文件同步方法中，當客戶端應用配置文件有所損壞并且 無法確定由哪些配置文件所致時，客戶端發送全同步更新配置請求；當客戶端應用配置文 件有所損壞并且無法確定由哪些配置文件所致時，服務器端發送全同步更新配置應答。
[0020] 進一步，在通信終端配置文件同步方法中，每隔一段時間，客戶端發送部分同步更 新配置請求；每隔一段時間服務器端發送部分同步更新配置應答。
[0021] 進一步，在通信終端配置文件同步方法中，當客戶端應用配置文件有所損壞并且 可以確定由哪些配置文件所致時，客戶端發送部分同步更新配置請求；當客戶端應用配置 文件有所損壞并且可以確定由哪些配置文件所致時，服務器端發送部分同步更新配置應 答。
[0022] 進一步，在通信終端配置文件同步方法中，推送平臺服務器會將應用配置的最新 版本信息包裹在推送消息的消息頭中。推送平臺客戶端收到消息后，將消息頭中對應的應 用配置版本與存儲在終端上的應用配置的版本信息進行比較，如果后者已經過期，則向推 送服務器發起對該應用的配置信息的更新請求。
[0023] 本發明的附加方面和優點將在下面的描述中部分給出，部分將從下面的描述中變 得明顯，或通過本發明的實踐了解到。
【專利附圖】
【附圖說明】
[0024] 本發明的上述和/或附加的方面和優點從結合下面附圖對實施例的描述中將變 得明顯和容易理解，其中 ：
[0025] 圖1是通信終端配置文件同步的現有技術思路圖；
[0026] 圖2是推送平臺結構原理圖；
[0027] 圖3是通信終端配置文件同步的原理圖；
[0028] 圖4是通信終端配置文件配置的效果圖。
【具體實施方式】
[0029] 圖1是通信終端配置文件同步的現有技術思路圖。其中，應用配置信息的更新，由 第三方應用提供商在發布新應用，或者更新應用版本的時候，向推送服務器發起。推送平臺 服務器在獲得更新的配置信息后，將更新通知推送到移動終端上的推送平臺客戶端。移動 平臺向推送平臺服務器發起更新配置請求，推送平臺服務器將更新的內容下發給推送平臺 客戶端。每次更新配置，則循環執行上述過程。由此導致同步動作過于頻繁和同步負擔較 重。
[0030] 如圖2所示，為了向移動終端的第三方應用提供消息推送，設立推送平臺。推送平 臺包括推送平臺服務器和推送平臺客戶端。推送平臺建立第三方應用服務器到第三方應用 客戶端的消息推送通道，將第三方應用服務器的消息，經過推送平臺，推送到第三方應用的 客戶端。當第三方應用廠商發布基于各個移動終端操作系統（比如，Android，iOS，WP等） 的應用或者更新應用版本時，要向推送平臺提供一些關于應用的一些信息(例如但不限于 應用的版本號、運行環境、名稱、圖標等)，推送平臺需要把這些信息傳遞到終端的推送平臺 客戶端，推送平臺客戶端以配置文件的形式保存這些信息，這些文件就是終端配置文件(或 簡稱為配置文件)。推送平臺客戶端使用配置文件提供的應用信息，來傳遞推送消息到第三 方應用客戶端和針對應用實現推送消息的個性化。
[0031] 首先，我們將推送平臺服務器與推送平臺客戶端的配置信息同步過程的發起者， 由推送平臺服務器，改為推送平臺客戶端。通信流程的示例之一如圖3所示。也就是說，在 本申請所公開的通信終端配置文件同步系統中，推送平臺客戶端發動更新配置請求；推送 平臺服務器發送更新配置應答。在本申請所公開的通信終端配置文件的同步方法中，主要 包括以下步驟：客戶端發動更新配置請求；服務器端發送更新配置應答。
[0032] 同時，本申請定義了三種同步方法：全同步（full synchronization):推送平臺 客戶端需要更新全部應用的配置信息；部分同步（partial synchronization):推送平臺 客戶端需要更新部分應用的配置信息；單同步（lazy synchronization):推送平臺客戶端 需要更新某一應用的配置信息。
[0033] 三種同步方法的具體實現方式如下：
[0034] 全同步中，推送平臺客戶端安裝后，首次被啟動時，推送平臺客戶端沒有任何應用 配置信息。在這種情況下，客戶端需要向服務器索取全部應用的配置信息。另一個需要實 行全同步的場景是，存儲在移動終端上的應用的配置文件有損壞的情況下（比如被用戶刪 除或者存儲介質損壞)，并且不能確定是由哪些應用的配置文件引起的。
[0035] 部分同步中，每隔一段時間（時間間隔可以由用戶設定，或使用默認值，比如一 天)，推送平臺客戶端需要向服務器索取部分應用的配置信息。應用的選取，可以由用戶選 取不同的策略（比如，在近三天內，有過推送消息的應用）。另一個需要實行部分同步的場景 是，存儲在移動終端上的應用的配置文件有損壞的情況下（比如被用戶刪除或者存儲介質 損壞)，并且可以確定是由哪些應用的配置文件引起的，可以啟動部分同步的工作機制。
[0036] 單同步中，第三方應用服務器委托推送平臺服務器發送消息后，推送平臺服務器 會將該應用配置的最新版本信息，包裹在推送消息的消息頭中。推送平臺客戶端收到消息 后，將消息頭中對應的應用配置版本與存儲在終端上的應用配置的版本信息進行比較，如 果后者已經過期，則向推送服務器發起對該應用的配置信息的更新請求。
[0037] 推送平臺客戶端與推送平臺服務器的應用配置同步，通過移動運營商提供的移動 網絡(例如GPRS，EDGE等）或者無線網絡（WIFI)通訊。通訊協議可以基于超文本傳輸協議 (HTTP協議）。協議示例如下：
[0038] 請求：
[0039]
【權利要求】
1. 一種通信終端配置文件同步系統，其包括， 推送平臺客戶端，其發動更新配置請求； 推送平臺服務器，其發送更新配置應答。
2. 如權利要求1所述的通信終端配置文件同步系統，其特征在于：當客戶端首次啟動 或者客戶端應用配置文件有所損壞并且無法確定由哪些配置文件所致時，客戶端發送全同 步更新配置請求； 當客戶端首次啟動或者客戶端應用配置文件有所損壞并且無法確定由哪些配置文件 所致時，服務器端發送全同步更新配置應答。
3. 如權利要求1或2之一所述的通信終端配置文件同步系統，其特征在于：每隔一段 時間，客戶端發送部分同步更新配置請求； 每隔一段時間服務器端發送部分同步更新配置應答。
4. 如權利要求1或2之一所述的通信終端配置文件同步系統，其特征在于：當客戶端 應用配置文件有所損壞并且可以確定由哪些配置文件所致時，客戶端發送部分同步更新配 置請求； 當客戶端應用配置文件有所損壞并且可以確定由哪些配置文件所致時，服務器端發送 部分同步更新配置應答。
5. 如權利要求1或2之一所述的通信終端配置文件同步系統，其特征在于，推送平臺服 務器會將應用配置的最新版本信息包裹在推送消息的消息頭中，推送平臺客戶端收到消息 后，將消息頭中對應的應用配置版本與存儲在終端上的應用配置的版本信息進行比較，如 果后者已經過期，則向推送服務器發起對該應用的配置信息的更新請求。
6. -種通信終端配置文件的同步方法，其特征在于， 客戶端發動更新配置請求； 服務器端發送更新配置應答。
7. 如權利要求6所述的通信終端配置文件同步方法，其特征在于： 當客戶端首次啟動時，客戶端發送全同步更新配置請求； 當客戶端首次啟動時，服務器端發送全同步更新配置應答。
8. 如權利要求6所述的通信終端配置文件同步方法，其特征在于： 當客戶端應用配置文件有所損壞并且無法確定由哪些配置文件所致時，客戶端發送全 同步更新配置請求； 當客戶端應用配置文件有所損壞并且無法確定由哪些配置文件所致時，服務器端發送 全同步更新配置應答。
9. 如權利要求6-8任一項所述的通信終端配置文件同步方法，其特征在于： 每隔一段時間，客戶端發送部分同步更新配置請求； 每隔一段時間服務器端發送部分同步更新配置應答。
10. 如權利要求6-8任一項所述的通信終端配置文件同步方法，其特征在于： 當客戶端應用配置文件有所損壞并且可以確定由哪些配置文件所致時，客戶端發送部 分同步更新配置請求； 當客戶端應用配置文件有所損壞并且可以確定由哪些配置文件所致時，服務器端發送 部分同步更新配置應答。
11. 如權利要求6-8任一項所述的通信終端配置文件同步方法，其特征在于：推送平臺 服務器會將應用配置的最新版本信息包裹在推送消息的消息頭中。
12. 如權利要求11所述的通信終端配置文件同步方法，其特征在于：推送平臺客戶端 收到消息后，將消息頭中對應的應用配置版本與存儲在終端上的應用配置的版本信息進行 比較，如果后者已經過期，則向推送服務器發起對該應用的配置信息的更新請求。
【文檔編號】H04L29/08GK104125249SQ201310145575
【公開日】2014年10月29日 申請日期:2013年4月24日 優先權日:2013年4月24日
【發明者】劉宏凱 申請人:北京遠方環宇通訊技術有限責任公司