專利名稱：快捷回復(fù)方法及其系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及移動通信網(wǎng)絡(luò)及英特(Internet)網(wǎng)絡(luò)上開展的消息業(yè)務(wù)， 具體涉及實現(xiàn)快捷回復(fù)的方法、系統(tǒng)、快捷回復(fù)服務(wù)器和客戶端。
背景技術(shù)：
目前，在移動通信網(wǎng)絡(luò)、Internet網(wǎng)絡(luò)上都開展有消息業(yè)務(wù)。移動通信 網(wǎng)絡(luò)一般包括第二代移動通信系統(tǒng)(2G)網(wǎng)絡(luò)、第三代移動通信系統(tǒng)(3G) 網(wǎng)絡(luò)、2G向3G過渡的2.5G網(wǎng)絡(luò)，以及多媒體子域等。
消息業(yè)務(wù)是個人對個人、個人對群組的消息類數(shù)據(jù)業(yè)務(wù)。例如手機之間 的短消息交互，Internet上各用戶終端之間的即時消息交互等。在消息交互 過程中，會有一些消息內(nèi)容經(jīng)常被使用到。如果每次都要輸入這些常用消息， 顯然使得操作不夠簡便。
以短消息通信系統(tǒng)實現(xiàn)的短消息業(yè)務(wù)為例，在現(xiàn)有的短消息系統(tǒng)中，用 戶終端提供了存儲常用消息的功能，用戶可以在用戶終端預(yù)先設(shè)置一些自己 的常用消息，稱為快捷回復(fù)(QA, Quick Answer )消息。用戶在編輯短消 息時，可以直接選擇預(yù)先設(shè)置的快捷回復(fù)消息，作為短消息內(nèi)容發(fā)送出去。 建立快捷回復(fù)，并采用快捷回復(fù)消息作為消息內(nèi)容的操作叫做快捷回復(fù)。這 樣減少了用戶的輸入，為用戶使用常用消息提供了方便。
但是，在上述現(xiàn)有的消息通信系統(tǒng)中，用戶所設(shè)置的快捷回復(fù)消息是存 儲在終端中的，所以用戶無法在不同的終端上方便的使用屬于該用戶的相同 快捷回復(fù)消息。用戶在一個終端上快捷回復(fù)消息進行了增加或刪除的搡作， 如果該用戶希望在其它終端上使用其更新過的最新快捷回復(fù)消息，則需要在 其它終端上再執(zhí)行一次相同的增加或刪除操作，操作過程重復(fù)、繁瑣。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明實施例的第一個目的在于提供一種快捷回復(fù)方法，使 用戶在不同終端使用相同的快捷回復(fù)消息。
本發(fā)明實施例的第二個目的在于提供一種快捷回復(fù)系統(tǒng)，使用戶在不同 終端使用相同的快捷回復(fù)消息。
本發(fā)明實施例的第三個目的在于提供一種快捷回復(fù)服務(wù)器，使用戶在不 同終端使用相同的快捷回復(fù)消息。
本發(fā)明實施例的第四個目的在于提供一種快捷回復(fù)客戶端，使用戶在不 同終端使用相同的快捷回復(fù)消息。
為達到上述目的的第一個方面，本發(fā)明提供了一種快捷回復(fù)方法，該方法包括
在快捷回復(fù)QA服務(wù)器中設(shè)置快捷回復(fù)消息；
客戶端向QA服務(wù)器發(fā)起消息獲取請求；
QA服務(wù)器根據(jù)所述消息獲取請求，向該客戶端返回快捷回復(fù)消息；
客戶端從返回的快捷回復(fù)消息中選取預(yù)發(fā)送的快捷回復(fù)消息，并向接收端 發(fā)送。
為達到上述目的的第二個方面，本發(fā)明提供了一種快捷回復(fù)系統(tǒng)，該系 統(tǒng)包括客戶端和QA服務(wù)器。
其中，所述客戶端，用于向所述QA服務(wù)器發(fā)起消息獲取請求；接收所述 QA服務(wù)器返回的快捷回復(fù)消息；并向接收端發(fā)送從所述返回的快捷回復(fù)消息 中選擇的預(yù)發(fā)送的快捷回復(fù)消息。
所述QA服務(wù)器，存儲快捷回復(fù)消息，用于根據(jù)接收自所述客戶端的消 息獲取請求，向所述客戶端返回快捷回復(fù)消息。
為達到上述目的的第三個方面，本發(fā)明提供了一種快捷回復(fù)服務(wù)器，該服 務(wù)器包括服務(wù)器QA處理模塊和服務(wù)器存儲模塊；
所述服務(wù)器存儲模塊，與所述服務(wù)器QA處理模塊相連，用于存儲快捷回
復(fù)消息；
所述服務(wù)器QA處理模塊，用于接收客戶端發(fā)起的消息獲取請求，根據(jù)該消息獲取請求從所述服務(wù)器存儲模塊中獲取對應(yīng)的快捷回復(fù)消息，返回給 所述客戶端。
為達到上述目的的第四個方面，本發(fā)明提供了一種快捷回復(fù)客戶端，該客戶端包括QA獲取模塊和客戶端QA處理模塊；
所述QA獲取模塊，用于向QA服務(wù)器發(fā)起消息獲取請求；接收所述QA 服務(wù)器返回的快捷回復(fù)消息，并發(fā)送給所述客戶端QA處理模塊；
所述客戶端QA處理模塊，用于從接收自所述QA獲取模塊的所述返回的 快捷回復(fù)消息中，選擇預(yù)發(fā)送的快捷回復(fù)消息，向接收端發(fā)送。
與現(xiàn)有技術(shù)相比，本發(fā)明所提供的實現(xiàn)快捷回復(fù)的方法、系統(tǒng)、快捷回 復(fù)服務(wù)器和客戶端，將快捷回復(fù)消息存儲在服務(wù)器上，當用戶需要快捷回復(fù) 時，可以從服務(wù)器上獲取該用戶的快捷回復(fù)消息，而并不是現(xiàn)有技術(shù)中從終 端上獲取快捷回復(fù)消息。由于快捷回復(fù)消息是存儲在服務(wù)器上，即使用戶在 一個終端上更新了快捷回復(fù)消息，該用戶仍可以在不進行重復(fù)操作的情況 下，通過其它終端從服務(wù)器上獲取其更新的最新快捷回復(fù)消息。因此實現(xiàn)了 用戶在不同的終端上可以方便的使用相同的快捷回復(fù)消息。


圖1為本發(fā)明實施例快捷回復(fù)方法的方法流程圖。
圖2為本發(fā)明實施例快捷回復(fù)系統(tǒng)的組成框圖。
圖3為本發(fā)明實施例快捷回復(fù)系統(tǒng)的第一較佳實施例的組成框圖。
圖4為本發(fā)明第 一較佳實施例第 一種實現(xiàn)快捷回復(fù)方法的方法流程圖。
圖5為本發(fā)明第 一較佳實施例第二種實現(xiàn)快捷回復(fù)方法的方法流程圖。
圖6為本發(fā)明實施例采用XCAP實現(xiàn)快捷回復(fù)消息獲取的方法流程圖。
圖7為本發(fā)明實施例采用XCAP實現(xiàn)快捷回復(fù)消息創(chuàng)建的方法流程圖。
圖8為本發(fā)明實施例采用XCAP實現(xiàn)快捷回復(fù)消息修改的方法流程圖。
圖9為本發(fā)明實施例采用XCAP實現(xiàn)快捷回復(fù)消息刪除的方法流程圖。
圖10為本發(fā)明實施例快捷回復(fù)系統(tǒng)第二較佳實施例的組成框圖。
圖11為本發(fā)明第二較佳實施例第一種實現(xiàn)快捷回復(fù)方法的方法流程圖。
圖12為本發(fā)明第二較佳實施例第二種實現(xiàn)快捷回復(fù)方法的方法流程圖。
圖13為本發(fā)明實施例采用SIP實現(xiàn)快捷回復(fù)消息獲取的方法流程圖。
圖14為本發(fā)明實施例采用SIP實現(xiàn)快捷回復(fù)消息創(chuàng)建的方法流程圖。
圖15為本發(fā)明實施例采用SIP實現(xiàn)快捷回復(fù)消息修改的方法流程圖。
圖16為本發(fā)明實施例釆用SIP實現(xiàn)快捷回復(fù)消息刪除的方法流程圖。
具體實施例方式
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚明白，下面結(jié)合實施例和 附圖，對本發(fā)明進一步詳細說明。
本發(fā)明實施例的核心思想為預(yù)先在QA服務(wù)器中設(shè)置快捷回復(fù)消息，當 客戶端向QA服務(wù)器發(fā)起消息獲取請求后，QA服務(wù)器根據(jù)該消息獲取請求， 返回快捷回復(fù)消息?？蛻舳藦姆祷氐目旖莼貜?fù)消息中選擇預(yù)發(fā)送的快捷回復(fù) 消息，并向接收端發(fā)送。
QA服務(wù)器是保存有快捷回復(fù)消息的資源管理服務(wù)器。在即時消息通信 系統(tǒng)中，該QA服務(wù)器可以采用實現(xiàn)即時消息業(yè)務(wù)的服務(wù)器實現(xiàn)。在短消息 通信系統(tǒng)中，該QA服務(wù)器可以采用實現(xiàn)短消息業(yè)務(wù)的服務(wù)器實現(xiàn)。以基于 初始會話協(xié)議/即時消息和現(xiàn)場支持擴展會話協(xié)議(SIP/SIMPLE)的消息系 統(tǒng)為例，該QA服務(wù)器可以采用即時消息擴展標簽語言文檔管理(IM XDM ) 服務(wù)器實現(xiàn)，也可以采用即時消息初始會話協(xié)議(IMSIP)服務(wù)器實現(xiàn)。QA 服務(wù)器也可以作為一個模塊單獨設(shè)置在SIP/SIMPLE消息系統(tǒng)的IM服務(wù)器 中，或者作為一個服務(wù)器單獨設(shè)置在SIP/SIMPLE系統(tǒng)中，只要實現(xiàn)快捷回 復(fù)消息的資源相關(guān)處理和管理即可。
QA服務(wù)器中存儲的快捷回復(fù)消息可以根據(jù)不同用戶分別存儲，有利于 不同用戶在獲取快捷回復(fù)消息時只獲取屬于自己的快捷回復(fù)消息。也可以將 所有快捷回復(fù)消息不分用戶的存儲。
上述本發(fā)明實施例方案適用于移動通信網(wǎng)絡(luò)和Internet網(wǎng)絡(luò)中的各種短 消息系統(tǒng)和即時消息(IM)系統(tǒng)。其實現(xiàn)快捷回復(fù)的原理相同。下面以在 移動通信網(wǎng)絡(luò)中使用本發(fā)明實施例實現(xiàn)快捷回復(fù)為例進行說明。其中，快捷 回復(fù)消息為短消息，且在QA服務(wù)器中根據(jù)不同用戶分別存儲。
基于上述核心思想，圖1示出了本發(fā)明實施例實現(xiàn)快捷回復(fù)方法的方法 流程圖。如圖l所示，該方法具體包括以下步驟
步驟101,用戶在QA服務(wù)器上創(chuàng)建該用戶的快捷回復(fù)消息。
本步驟中，用戶可以通過多次創(chuàng)建來添加快捷回復(fù)消息。
步驟102,用戶通過客戶端向QA服務(wù)器發(fā)起消息獲取請求。
本步驟中，客戶端發(fā)起的消息獲取請求可以是主動獲取也可以是被動獲 取。主動獲取是用戶需要更新本地快捷回復(fù)消息時，在用戶命令的控制下， 向QA服務(wù)器發(fā)起消息獲取請求。被動獲取是客戶端在用戶每次需要使用快 捷回復(fù)消息時都向QA服務(wù)器發(fā)起消息獲取請求，保證使用的快捷回復(fù)消息 為最新。或者客戶端可以周期性的向QA服務(wù)器發(fā)起消息獲取請求。
步驟103, QA服務(wù)器根據(jù)客戶端發(fā)來的消息獲取請求，向客戶端返回 該用戶的快捷回復(fù)消息。
客戶端在接到QA服務(wù)器返回的快捷回復(fù)消息后，可以保存、或不保存 所獲取的快捷回復(fù)消息。如果保存則以后可以直接使用客戶端上保存的快捷 回復(fù)消息，如果不保存則需要每次進行快捷回復(fù)時，都向QA服務(wù)器申請快 捷回復(fù)消息。
步驟104，用戶通過客戶端，從返回的快捷回復(fù)消息中選取所需的快捷 回復(fù)消息向接收端發(fā)送。
本步驟中，快捷回復(fù)消息的發(fā)送方式有兩種。第一種是將快捷回復(fù)消息 的真實內(nèi)容包含在消息體中進行發(fā)送；第二種是在發(fā)送端和發(fā)送端歸屬服務(wù)
器之間只發(fā)送快捷回復(fù)消息的消息標識(ID),發(fā)送端歸屬服務(wù)器收到消息ID后再從QA服務(wù)器獲取快捷回復(fù)消息的具體內(nèi)容，把包含快捷回復(fù)消息 具體內(nèi)容的消息體發(fā)送給接收端。采用發(fā)送消息ID的方式，可以有效的減 少發(fā)送端和發(fā)送端服務(wù)器之間的網(wǎng)絡(luò)負載，大大提高發(fā)送較大快捷回復(fù)消息 時的效率。
QA服務(wù)器存儲的快捷回復(fù)消息可以包括消息ID和消息內(nèi)容(Text)。 消息ID是一條快捷回復(fù)消息的唯一標識。消息內(nèi)容是快捷回復(fù)消息的具體 內(nèi)容。快捷回復(fù)消息還可以包括消息類型(Type )和消息描述(Description ) 等屬性信息。Description可以用來描述一些體積比較大的快捷回復(fù)消息，相 當于關(guān)鍵字，這樣用戶在客戶端使用快捷回復(fù)消息時，可以不瀏覽快捷回復(fù) 消息具體內(nèi)容，而根據(jù)Description屬性來選擇所需的快捷回復(fù)消息。Text 是快捷回復(fù)消息的具體內(nèi)容。但對于一些多媒體消息來說，由于消息體積較 大，因此Text屬性中只存儲具體快捷回復(fù)消息的消息鏈接，如統(tǒng)一資源地 址(URL)。
本發(fā)明實施例還能夠?qū)崿F(xiàn)對QA服務(wù)器上快捷回復(fù)消息的管理?？蛻舳?向QA服務(wù)器發(fā)送管理信息，QA服務(wù)器根據(jù)該管理信息對其存儲的各用戶 快捷回復(fù)消息進行管理操作，再向客戶端返回管理處理響應(yīng)消息，然后客戶 端根據(jù)該管理處理響應(yīng)消息更新本地快捷回復(fù)消息。管理操作包括對QA服 務(wù)器上快捷回復(fù)消息的添加、修改和刪除。
A、當管理信息為創(chuàng)建信息時，創(chuàng)建信息包括用戶創(chuàng)建的新快捷回復(fù)消 息。該新快捷回復(fù)消息不包括消息ID,消息ID是QA服務(wù)器為快捷回復(fù)消 息創(chuàng)建的。
客戶端將新快捷回復(fù)消息發(fā)送給QA服務(wù)器后，QA服務(wù)器為新快捷回復(fù)消息創(chuàng)建消息ID,再將消息ID返回給客戶端?？蛻舳丝梢詫⒃撓D和新快捷回復(fù)消息的消息內(nèi)容一起保存。消息ID包含在管理處理響應(yīng)消息中，同時表示創(chuàng)建成功。
在多次創(chuàng)建快捷回復(fù)消息時，QA服務(wù)器返回的消息可能有延時，因此QA服務(wù)器返回的消息ID及客戶端創(chuàng)建的消息內(nèi)容的對應(yīng)關(guān)系可能發(fā)生混 亂，因此在QA服務(wù)器返回的消息中，可以同時攜帶新快捷回復(fù)消息的消息 內(nèi)容和消息ID。
B、 當管理信息為修改信息時，修改信息包括修改后快捷回復(fù)消息的消 息內(nèi)容和消息ID。
客戶端將修改后快捷回復(fù)消息的消息內(nèi)容和消息ID發(fā)送給QA服務(wù)器， QA服務(wù)器修改其存儲的快捷回復(fù)消息，再向客戶端返回管理處理響應(yīng)消息。 當管理處理響應(yīng)消息表示修改成功，客戶端更新本地快捷回復(fù)消息。
C、 當管理信息為刪除信息時，刪除信息包括預(yù)刪除快捷回復(fù)消息的消 息ID。
客戶端將預(yù)刪除快捷回復(fù)消息的消息ID發(fā)送給QA服務(wù)器，QA服務(wù) 器將該消息ID對應(yīng)的快捷回復(fù)消息刪除，并返回管理處理響應(yīng)消息。當管 理處理響應(yīng)消息表示刪除成功，由客戶端更新本地快捷回復(fù)消息。
為實現(xiàn)本發(fā)明實施例提供的快捷回復(fù)方法，本發(fā)明實施例還提供了 一種 快捷回復(fù)系統(tǒng)。圖2示出了本發(fā)明實施例快捷回復(fù)系統(tǒng)的組成框圖。參見圖 2,該快捷回復(fù)系統(tǒng)包括客戶端和QA服務(wù)器。
其中，客戶端，用于向QA服務(wù)器發(fā)起用戶的消息獲取請求；接收QA 服務(wù)器返回的快捷回復(fù)消息。之后，客戶端從返回的快捷回復(fù)消息中選擇的 預(yù)發(fā)送的快捷回復(fù)消息，并向接收端發(fā)送。
QA服務(wù)器，存儲各用戶的快捷回復(fù)消息，用于根據(jù)用戶的消息獲取請 求，向客戶端返回該用戶的快捷回復(fù)消息。
為了實現(xiàn)對QA服務(wù)器存儲的各用戶的快捷回復(fù)消息的管理，QA服務(wù) 器還要根據(jù)客戶端發(fā)來的管理信息對其存儲的快捷回復(fù)消息進行管理操作， 并返回管理處理響應(yīng)消息?？蛻舳烁鶕?jù)該管理處理響應(yīng)消息更新本地快捷回復(fù)消息。
在移動通信網(wǎng)絡(luò)中， 一般采用基于SIP/SIMPLE的消息系統(tǒng)實現(xiàn)即時消 息通信。在基于SIP/SIMPLE的消息系統(tǒng)中，可以采用擴展標簽語言配置訪問協(xié)議(XCAP)或者會話初始協(xié)議(SIP)實現(xiàn)快捷回復(fù)消息的獲取、創(chuàng)建、 修改或者刪除。在具體實現(xiàn)消息的發(fā)送和接收時，根據(jù)采用的消息傳輸協(xié)議 不同，消息發(fā)送和接收的過程略有所區(qū)別。以下舉較佳實施例，分別對本發(fā) 明實施例采用不同協(xié)議的具體實現(xiàn)進行舉例說明。
第一較佳實施例
在基于SIP/SIMPLE的消息系統(tǒng)中，可以采用XCAP或者SIP實現(xiàn)快捷 回復(fù)消息的獲取或者管理。本實施例中，快捷回復(fù)消息的獲取、創(chuàng)建、修改 或者刪除都采用XCAP,采用該方式發(fā)送的管理信息可以采用XCAP所定義 的GET、 PUT和DELETE等命令，接收到該類命令并成功完成相關(guān)操作的 設(shè)備返回HTTP 200 OK響應(yīng)，該響應(yīng)中可以包含具體的信息內(nèi)容。
圖3為本發(fā)明快捷回復(fù)系統(tǒng)第一較佳實施例的組成框圖。如圖3所示， 該系統(tǒng)包括擴展標簽語言文檔管理(XDM)客戶端310和IM XDM服務(wù) 器300。
其中，XDM客戶端310,用于將向用戶發(fā)起的消息獲取請求或管理信 息發(fā)送給IM XDM服務(wù)器300,接收IM XDM服務(wù)器300返回的該用戶所 有的快捷回復(fù)消息或者管理處理響應(yīng)消息。當接收到IM XDM服務(wù)器返回 的該用戶的快捷回復(fù)消息后，XDM客戶端從中選取一條，向接收端發(fā)送。 XDM客戶端310發(fā)送的消息獲取請求和管理信息都為XCAP請求的形式。 本實施例中，XDM客戶端310作為快捷回復(fù)系統(tǒng)中的客戶端，是用戶終端 中的一個模塊。
XDM客戶端310具體包括QA獲取模塊313和QA處理模塊311。
其中，QA獲取模塊313，用于向IMXDM服務(wù)器300發(fā)起用戶的消息
獲取請求，并接收IM XDM服務(wù)器300返回的該用戶的所有快捷回復(fù)消息，
并傳送給QA處理模塊311。
QA處理模塊311，從QA獲取模塊313發(fā)來的該用戶的所有快捷回復(fù)
消息中選取一條，向接收端發(fā)送。該模塊還用于向IM XDM服務(wù)器300發(fā)送管理信息，接收IM XDM服務(wù)器3 00返回的管理處理響應(yīng)消息。
如果XDM客戶端310并非每次進行快捷回復(fù)時都從服務(wù)器獲取快捷回 復(fù)消息，則XDM客戶端310還包括QA存儲模塊312。該QA存儲模塊312, 與QA處理模塊311相連，用于存儲使用該XDM客戶端的用戶的快捷回復(fù) 消息。當QA處理模塊311，接收到QA獲取模塊313發(fā)來的快捷回復(fù)消息 后，可以將該快捷回復(fù)消息存儲在該QA存儲模塊312中，以備以后使用。 當QA處理模塊311,接收到IMXDM服務(wù)器300返回的管理處理響應(yīng)信息 后，根據(jù)該管理處理響應(yīng)信息更新本地快捷回復(fù)消息。該XDM客戶端中的 快捷回復(fù)消息是以擴展標簽語言(XML)文檔的形式存儲的。
IMXDM服務(wù)器330，作為QA服務(wù)器，存儲有各用戶的快捷回復(fù)消息； 用于根據(jù)接收的用戶的消息獲取請求將該用戶的快捷回復(fù)消息返回給XDM 客戶端310;或者根據(jù)接收自XDM客戶端310的管理信息，對其存儲的快 捷回復(fù)消息進行管理。IM XDM服務(wù)器300中的快捷回復(fù)消息也是以XML 文檔的形式存儲的。因此，XDM客戶端310與IMXDM服務(wù)器300之間采 用XCAP實現(xiàn)信息交互。
該IM XDM服務(wù)器330可以采用本發(fā)明提供的快捷回復(fù)服務(wù)器的組成 結(jié)構(gòu)。IMXDM服務(wù)器330包括QA處理模塊301和QA存儲模塊302。其 中QA存儲模塊302,與QA處理模塊301相連，用于存儲各用戶快捷回復(fù) 消息；QA處理模塊301，用于根據(jù)接收自XDM客戶端310的消息獲取請 求或者管理信息，對QA存儲模塊302中的快捷回復(fù)消息進行相應(yīng)的處理。
IM XDM服務(wù)器330為了完成其它即時消息業(yè)務(wù)，還包括IM XDM業(yè) 務(wù)處理模塊，用于處理除快捷回復(fù)以外的即時消息業(yè)務(wù)。該模塊未在圖3中 示出。如果QA服務(wù)器采用其它業(yè)務(wù)服務(wù)器實現(xiàn)，該QA服務(wù)器可以包括該 業(yè)務(wù)服務(wù)器處理原業(yè)務(wù)的模塊，例如，該模塊可以是短消息業(yè)務(wù)處理模塊， IM SIP業(yè)務(wù)處理模塊，多媒體消息業(yè)務(wù)處理模塊等等。
XDM客戶端與IM XDM服務(wù)器之間成功的信息傳輸都是借助聚合代理 的路由功能完成的。聚合代理還可以根據(jù)客戶端發(fā)送的消息，進行用戶身份鑒別。
本實施例的快捷回復(fù)系統(tǒng)采用XML文檔的方式將快捷回復(fù)消息存儲在 IMXDM服務(wù)器中。下面給出快捷回復(fù)消息XML文檔的XMLSchema語法架構(gòu)定義。
<!— The root element: qa-set —>
<xs:element name="qa-set">
<xs: comp lexType〉
<xs:sequence maxOccurs="unbounded">
<xs:element name="qa" type—'qaType" minOccurs="0" maxOccurs="imbounded7>
</xs:sequenc6〉
<xs:attribute name-"uri" type-"xs:anyURI" use="required"/>
</xs:complexType>
</xs:elemcnt>
<xs:complexType name="qaType">
<xs:scquence〉
<xs:element name="id" type="xs:string" minOccurs-"l" maxOccurs='TV>
<xs:dement name="type="xs:string" minOccurs="l" maxOccurs="17>
<xs:element name="description" type="xs:string" minOccurs-"l" maxOccurs="17>
<xs:element name="text" type="xs:string" minOccurs="l" maxOccurs="r/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unboimded7>
</xs:sequcnce>
</xs:complexType>
其中，qa-set為快捷回復(fù)消息集合，即根元素。其uri屬性指明該快捷 回復(fù)消息的所有者，即使用用戶。qa代表用戶的一個快捷回復(fù)消息，具有消 息ID、消息類型(Type)、消息描述(Description)和消息內(nèi)容(Text)屬 性。大的多媒體消息不存儲在XML文檔中，消息內(nèi)容中也不存放真正的快 捷回復(fù)消息的內(nèi)容，僅僅存儲一個URL，通過URL可以獲取真正的消息內(nèi)
采用XCAP作為消息傳輸方式，在傳輸普通消息時，可以采用SIP或者 消息會話中繼協(xié)議(MSRP),但是傳輸體積較大的消息時，只能采用MSRP 協(xié)議，通過建立會話(Session)實現(xiàn)?？蛻舳撕头?wù)器、服務(wù)器和服務(wù)器之 間的消息都要通過會話初始協(xié)議/網(wǎng)際協(xié)議核(SIP/IP Core )進行傳輸，在以下的敘述都省略了 SIP/IP Core的敘述。
圖4為本發(fā)明第一較佳實施例第 一種實現(xiàn)快捷回復(fù)方法的方法流程圖。 該方法是XDM客戶端A獲取并選擇快捷回復(fù)消息，并發(fā)送給客戶端B的第 一種具體實現(xiàn)過程。在發(fā)送過程中，采用直接發(fā)送快捷回復(fù)消息的消息內(nèi)容 方式。參見圖4,該方法包括以下步驟
步驟401,用戶想要使用快捷回復(fù)消息時，通過XDM客戶端A發(fā)送 XCAP GET到IM XDM服務(wù)器。XCAP GET為消息獲取請求。
步驟402， IM XDM服務(wù)器收到XCAP GET后，返回HTTP 200 OK, 并且在HTTP 200 OK中攜帶發(fā)起請求的用戶的所有快捷回復(fù)消息。
步驟403， XDM客戶端A接收到快捷回復(fù)消息，用戶選擇一條所需的 快捷回復(fù)消息。
步驟404， XDM客戶端A采用SIP MESSAGE或者MSRP SEND,將用 戶選擇的快捷回復(fù)消息發(fā)送到歸屬服務(wù)器A。 SIP MESSAGE消息是基于SIP 協(xié)議的信息發(fā)送消息，MSRP SEND消息是基于MSRP的信息發(fā)送消息。發(fā) 送的SIP MESSAGE或者MSRP SEND攜帶快捷回復(fù)消息的消息內(nèi)容，即 Text。歸屬服務(wù)器A是XDM客戶端A的歸屬服務(wù)器；歸屬服務(wù)器B是客 戶端B的歸屬服務(wù)器。
步驟405,歸屬服務(wù)器A轉(zhuǎn)發(fā)從XDM客戶端A接收的SIP MESSAGE 或者MSRP SEND消息到歸屬服務(wù)器B。
步驟406,歸屬服務(wù)器B轉(zhuǎn)發(fā)從歸屬服務(wù)器B接收的SIP MESSAGE或 者MSRP SEND消息到客戶端B。
步驟407，客戶端B接收來自歸屬服務(wù)器B的SIP MESSAGE或者MSRP SEND消息后，返回SIP 200 OK/MSRP 200 OK響應(yīng)到歸屬服務(wù)器B。
步驟408,歸屬服務(wù)器B轉(zhuǎn)發(fā)從客戶端B接收的SIP 200 OK/MSRP 200 OK響應(yīng)到歸屬服務(wù)器A。
步驟409,歸屬服務(wù)器A轉(zhuǎn)發(fā)從歸屬服務(wù)器B接收的SIP 200 OK/MSRP 200 OK響應(yīng)到XDM客戶端A。
以上就完成了 一次快捷回復(fù)。消息的發(fā)送采用SIP MESSAGE或者 MSRPSEND都可以，具體采用哪種方式取決于原有會話所采用的方式，與 原有會話保持一致即可。相應(yīng)的2000K也要與發(fā)送消息的方式一致。但當 采用SIP MESSAGE時，SIP MESSAGE中不能直接攜帶較大的快捷回復(fù)消 息，必須建立會話，采用MSRP SEND發(fā)送較大的快捷回復(fù)消息。
圖5為本發(fā)明第一較佳實施例第二種實現(xiàn)快捷回復(fù)方法的方法流程圖。 該方法是XDM客戶端A獲取并選擇快捷回復(fù)消息，并發(fā)送給客戶端B的第 二種具體實現(xiàn)過程。在發(fā)送過程中，采用SIP MESSAGE的方法直接發(fā)送快 捷回復(fù)消息的消息內(nèi)容，該快捷回復(fù)消息體比較大，因此需要建立Session。 參見圖5,該方法包括以下步驟
步驟501,用戶想要使用快捷回復(fù)消息時，通過XDM客戶端A向IM XDM服務(wù)器發(fā)送XCAP GET。 XCAP PUT是基于XCAP的信息獲取命令， 本實施例中，采用XCAP GET作為消息獲取請求。
步驟502, IM XDM服務(wù)器收到XCAP GET后，返回HTTP 200 OK， 并且在HTTP 200 OK中攜帶發(fā)起請求的用戶的所有快捷回復(fù)消息。
步驟503, XDM客戶端A接收到快捷回復(fù)消息，用戶選擇一條所需的 快捷回復(fù)消息。由于消息比較大，使用SIP MESSAGE發(fā)送不了 ，所以以下 需要建立Session使用MSRP SEND進行發(fā)送。
步驟504- 512，建立XDM客戶端A到客戶端B的Session。
具體包括，XDM客戶端A發(fā)送邀請消息SIP INVITE到歸屬服務(wù)器A 進行Session的建立，歸屬服務(wù)器A將該SIP INVITE轉(zhuǎn)發(fā)到歸屬服務(wù)器B， 歸屬服務(wù)器B將該SIP INVITE轉(zhuǎn)發(fā)到客戶端B?？蛻舳薆接收到SIP INVITE 后，發(fā)送SIP200 OK響應(yīng)到歸屬服務(wù)器B,歸屬服務(wù)器B將SIP 200 OK響 應(yīng)轉(zhuǎn)發(fā)到歸屬服務(wù)器A,歸屬服務(wù)器A將SIP 200 OK響應(yīng)轉(zhuǎn)發(fā)到XDM客 戶端A。 XDM客戶端A接收到SIP 200 OK后，發(fā)送ACK到歸屬服務(wù)器A, 歸屬服務(wù)器A轉(zhuǎn)發(fā)ACK到歸屬服務(wù)器B，歸屬服務(wù)器B轉(zhuǎn)發(fā)ACK到客戶 端B。自此，Session建立成功。
步驟513-518， XDM客戶端A采用MSRP SEND將攜帶消息內(nèi)容的快 捷回復(fù)消息發(fā)送給客戶端B。
具體包括，XDM客戶端A采用MSRP SEND將攜帶消息內(nèi)容的快捷回 復(fù)消息發(fā)送給歸屬服務(wù)器A，歸屬服務(wù)器A轉(zhuǎn)發(fā)MSRP SEND到歸屬服務(wù)器 B，歸屬服務(wù)器B轉(zhuǎn)發(fā)MSRP SEND到客戶端B;客戶端B接收到MSRP SEND 后，發(fā)送MSRP 200 OK響應(yīng)到歸屬服務(wù)器B，歸屬服務(wù)器B轉(zhuǎn)發(fā)MSRP 200 OK響應(yīng)到歸屬服務(wù)器A,歸屬服務(wù)器A轉(zhuǎn)發(fā)MSRP 200 OK響應(yīng)到XDM客 戶端A。自此，證明MSRP SEND發(fā)送成功。
步驟519 ~ 524，終止XDM客戶端A到客戶端B的Session。
具體包括，XDM客戶端A發(fā)送終止消息SIPBYE到歸屬服務(wù)器A,歸 屬服務(wù)器A轉(zhuǎn)發(fā)SIP BYE轉(zhuǎn)發(fā)到歸屬服務(wù)器B，歸屬服務(wù)器B轉(zhuǎn)發(fā)SIP BYE 到客戶端B;客戶端B接收到SIPBYE后，發(fā)送SIP 200 OK響應(yīng)到歸屬服 務(wù)器B,歸屬服務(wù)器B將SIP 200 OK響應(yīng)轉(zhuǎn)發(fā)到歸屬服務(wù)器A,歸屬服務(wù) 器A將SIP200 OK響應(yīng)轉(zhuǎn)發(fā)到XDM客戶端A。自此，Session被終止。
以上就完成了一次快捷回復(fù)。
在采用XCAP的快捷回復(fù)獲取時，由于快捷回復(fù)消息是存儲在作為QA 服務(wù)器的IM XDM服務(wù)器中的，所以客戶端在使用快捷回復(fù)消息時需要先 從IM XDM服務(wù)器端獲取快捷回復(fù)消息的具體內(nèi)容，如圖4中的步驟401 和圖5中的步驟501。圖6示出了采用XCAP實現(xiàn)快捷回復(fù)消息獲取的方法 流程圖。如圖6所示，其具體實現(xiàn)步驟如下
步驟601, XDM客戶端向聚合代理單元發(fā)送用戶的XCAP GET請求。
XCAP GET請求是采用XCAP協(xié)議的消息獲取請求，該XCAP GET請 求包括用戶ID。該用戶ID表示XCAP GET請求要求獲取哪個用戶的快捷回 復(fù)消息。因為，快捷回復(fù)消息在XML文檔中是對應(yīng)不同用戶分別存儲的。
步驟602,聚合代理單元對XCAP GET請求進行用戶身份鑒別。這一步 是可選的。
步驟603,聚合代理單元轉(zhuǎn)發(fā)XCAP GET請求到存儲快捷回復(fù)消息的IMXDM服務(wù)器。
步驟604, IM XDM服務(wù)器收到XCAP GET請求后，根據(jù)XCAP GET 請求所攜帶的用戶ID,獲取該用戶的快捷回復(fù)消息。
步驟605, IMXDM服務(wù)器向聚合代理單元返回攜帶該用戶所有快捷回 復(fù)消息的HTTP 200 OK響應(yīng)。
HTTP 200 OK響應(yīng)中攜帶了該用戶的所有快捷回復(fù)消息的具體內(nèi)容。 該用戶的快捷回復(fù)消息可能是一條或者一條以上?？旖莼貜?fù)消息的具體內(nèi)容 包括消息標識(ID)、消息類型(Type)、消息描述(Description)和消息 內(nèi)容(Text)屬性。
步驟606,聚合代理單元轉(zhuǎn)發(fā)HTTP 200 OK響應(yīng)給XDM客戶端。
步驟607, XDM客戶端存儲快捷回復(fù)消息。本步驟是可選的，如果客 戶端在每次使用和發(fā)送快捷回復(fù)消息時都要從IM XDM服務(wù)器獲取用戶的 快捷回復(fù)消息，則不需要執(zhí)行本步驟的存儲。
上述XC AP GET請求的例子如下
GET http://xcap.example.com/Quick-Answer/users/sip:sriram@example.com/QADoc HTTP/1.1
其中，sip:sriram@example.com為用戶ID。
HTTP 200 OK響應(yīng)消息的例子如下
HTTP/1.1 200 OK Etag: "cdcdcdcd，，
Content-Type: message/qanswer
< xml version="1.0" encoding="UTF-8" >
<qa-set uri="sip:sriram@example.com">
<qa>
<id>QA76587efdky761 </id>
<type>Text</type>
<description> I'm fine!</description>
<text>l，m fine how are you</text>
</qa〉
……
</qa-set>
其中，QA76587efdky761為消息ID, Text為消息類型，I'm fine!為消息描述，I'm fine how are you為消息內(nèi)容。如杲該用戶有一條以上的快捷回復(fù) 消息，則IMXDM服務(wù)器給客戶端回復(fù)的HTTP 200 OK中包含多條快捷回 復(fù)消息，由qa分隔。
用戶還可以通過對XDM客戶端的操作，實現(xiàn)對存儲在IM XDM服務(wù)器 的快捷回復(fù)消息的管理。管理包括對快捷回復(fù)消息的創(chuàng)建，修改和刪除。其 中創(chuàng)建消息可以是在IM XDM服務(wù)器中還沒有快捷回復(fù)消息的情況下創(chuàng)建 新快捷回復(fù)消息，也可以是在IM XDM服務(wù)器存儲的快捷回復(fù)消息基礎(chǔ)上 添加更多的快捷回復(fù)消息。
圖7示出了采用XCAP實現(xiàn)快捷回復(fù)消息創(chuàng)建的方法流程圖。如圖7 所示，其具體實現(xiàn)步驟如下
步驟700，用戶通過XDM客戶端編輯創(chuàng)建一條新快捷回復(fù)消息。
步驟701, XDM客戶端向聚合代理單元發(fā)送攜帶新快捷回復(fù)消息的 XCAP PUT請求。XCAP PUT是基于XCAP的信息發(fā)送命令。XCAP PUT請求是采用XCAP協(xié)議的快捷回復(fù)消息創(chuàng)建請求。本實施 例中，該XCAPPUT請求包括用戶ID和新快捷回復(fù)消息的具體內(nèi)容。由于 IM XDM服務(wù)器對快捷回復(fù)消息資源進行統(tǒng) 一 管理，因此消息ID由IM XDM 服務(wù)器為新快捷回復(fù)消息創(chuàng)建。
步驟702，聚合代理單元對XCAP PUT請求進行用戶身份鑒別。這一步 是可選的。
步驟703,聚合代理單元轉(zhuǎn)發(fā)XCAP PUT請求到存儲快捷回復(fù)消息的IM XDM服務(wù)器。
步驟704， IM XDM服務(wù)器收到XCAP PUT請求后，為新的快捷回復(fù)消 息創(chuàng)建一個消息ID,并將消息ID和接收的快捷回復(fù)的具體內(nèi)容一起更新到 快捷回復(fù)消息存儲文檔中，即XML文檔。其中，根據(jù)用戶ID確定新快捷回復(fù)消息存放的位置。
步驟705, IMXDM服務(wù)器向聚合代理單元返回攜帶新快捷回復(fù)消息的 消息ID的HTTP 200 OK響應(yīng)。該HTTP 200 OK響應(yīng)為管理處理響應(yīng)消息。
步驟706,聚合代理單元轉(zhuǎn)發(fā)HTTP 200 OK響應(yīng)給XDM客戶端。
步驟707， XDM客戶端更新本地的快捷回復(fù)消息。即在本地添加創(chuàng)建 的新快捷回復(fù)消息及其消息ID。
本步驟是可選擇，如果不包括本步驟，則在需要使用快捷回復(fù)消息時， 必須先從IM XDM服務(wù)器中獲取快捷回復(fù)消息。
上述XC AP PUT消息的例子如下
PUT http:〃xcap.example,com/(5uick-Answer/users/sip:sriram@example.com/QADoc/qa-set HTTP/1.1
Content-Type: message/qanswer Content-Length:(...)
<qa>
<type>Text</type> <description>Busy</description> <text>Busy now Will talk later</text>
<—>
步驟704更新前的XML文檔的例子如下
< xml version-"l.O" encoding="UTF-8" > <qa-set uriysip:sriram⑨example.com"〉
<qa〉
<id>QA76587efdky761 </id〉 <type〉Text</type>
<description> I，m fine !</description> <text>I，m fine how are you</text> </qa>
</qa-set>
步驟704更新后的XML文檔的例子如下:
< xml version＝" 1.0" encoding="UTF-8" > <qa-set uri="sip:sriram@example.com"> <qa>
<id>QA76587efdky761</id>
<type〉Text</type〉 <description> I，m fine !</description> <text>I，m fine how are you</text>
<qs>
<id>QA76587efdky763</id>
<type>Text</type>
<description> Busy</description>
<text>Busy now W川talk later</text>
</qa>
......
</qa-set>
IM XDM服務(wù)器返回HTTP 200 OK消息的例子如下
HTTP/1.1 200 OK
Etag: "cdcdcdce"
Content-Type: message/qanswer
<id>QA76587efdky763</id>
其中，QA76587efdky763為本實施例創(chuàng)建的新快捷回復(fù)消息的消息ID。
圖8示出了采用XCAP實現(xiàn)快捷回復(fù)消息修改的方法流程圖。如圖8 所示，其具體實現(xiàn)步驟如下
步驟800，用戶通過XDM客戶端選擇并修改一條快捷回復(fù)消息。如果 XDM客戶端存儲有快捷回復(fù)消息則可以從中選取 一 條快捷回復(fù)消息并修 改，如果沒有存儲，則需要從QA服務(wù)器獲取快捷回復(fù)消息，再從中選取一 條快捷回復(fù)消息并修改。
步驟801, XDM客戶端向聚合代理單元發(fā)送攜帶修改后快捷回復(fù)消息 的消息內(nèi)容及其消息ID的XCAP PUT請求。
本步驟中的XCAP PUT請求是采用XCAP協(xié)議的快捷回復(fù)消息修改請 求。雖然與創(chuàng)建請求一樣，修改請求也使用了 XCAP PUT請求命令，但是 該XCAP PUT請求命令中不僅攜帶有用戶ID和修改后快捷回復(fù)消息的具體 內(nèi)容，還攜帶有修改后快捷回復(fù)消息的消息ID。
步驟802,聚合代理單元對XCAP PUT請求進行用戶身份鑒別。這一步 是可選的。
步驟803，聚合代理單元轉(zhuǎn)發(fā)XCAP PUT請求到存儲快捷回復(fù)消息的IM XDM服務(wù)器。
步驟804, IM XDM服務(wù)器收到XCAP PUT請求后，修改消息ID所指向的快捷回復(fù)消息具體內(nèi)容。修改所用的值是修改后快捷回復(fù)消息的消息內(nèi)
步驟805, IM XDM服務(wù)器向聚合代理單元返回HTTP 200 OK響應(yīng)。 該HTTP 200 OK響應(yīng)表示f務(wù)改成功，是管理處理響應(yīng)消息。
步驟806,聚合代理單元轉(zhuǎn)發(fā)HTTP 200 OK響應(yīng)給XDM客戶端。
步驟807, XDM客戶端更新本地的快捷回復(fù)消息。 上述作為消息修改請求的XCAP PUT消息的例子如下
PUT http:〃xcap.example.com/Quick-Answer/users/sip:sriram@example.com/QADoc /qaset/qa[id= QA76587efdky761 ] HTTP/1.1
Content-Type: message/qanswer
Content-Length:(...)
<id>QA76587e ky76i</id>
<type〉Text</type>
<description> Greeting </description>
<text>How are you </text>
其中，id= QA76587efdky761為所要修改快捷回復(fù)消息的消息ID。
步驟804修改前的XML文檔的例子如下
< xml versioiv="l,0" encoding="UTF-8" > <qa-set uri="sip:sriram@example.com">
<qa>
<id>QA76587efdky761</id>
<type>Text</type>
<description〉 I'm fine !</description>
<text>I，m fine how are you</text>
</qa>
</qa-set>
步驟804修改后的XML文檔的例子如下:
< xml version-" 1.0" encoding="UTF-8" >
<qa-set uri="sip:sriram@example.com">
<qa>
<id>QA76587efdky761</id>
<type>Text</type〉
<description〉 Greeting</description>
<text>How are you </text〉
</qa> ......
</qa-set>
IM XDM月l務(wù)器返回HTTP 200 OK消息的例子如下
HTTP/1.1 200 OK
Etag: "cdcdcdce"
圖9示出了采用XCAP實現(xiàn)快捷回復(fù)消息刪除的方法流程圖。如圖9 所示，其具體實現(xiàn)步驟如下
步驟900,用戶通過XDM客戶端選擇一條預(yù)刪除快捷回復(fù)消息。如果 XDM客戶端存儲有快捷回復(fù)消息則可以從中選取一條快捷回復(fù)消息作為預(yù) 刪除快捷回復(fù)消息；如果沒有存儲，則需要從QA服務(wù)器獲取快捷回復(fù)消息， 再從中選取 一 條預(yù)刪除快捷回復(fù)消息。
步驟90l, XDM客戶端向聚合代理單元發(fā)送攜帶預(yù)刪除快捷回復(fù)消息 的消息ID的XCAP DELETE請求。XCAP DELETE是基于XCAP的信息刪 除命令。
本步驟中的XCAP DELETE請求是采用XCAP協(xié)議的快捷回復(fù)消息刪 除請求。
步驟902,聚合代理單元對XCAP DELETE請求進行用戶身份鑒別。這 一步是可選的。
步驟903,聚合代理單元轉(zhuǎn)發(fā)XCAP DELETE請求到存儲快捷回復(fù)消息 的IM XDM服務(wù)器。
步驟904， IM XDM服務(wù)器收到XCAP DELETE請求后，將XML文檔 中XCAP DELETE攜帶的消息ID對應(yīng)的快捷回復(fù)消息刪除。
步驟905， IM XDM服務(wù)器向聚合代理單元返回HTTP 200 OK響應(yīng)。 該HTTP 200 OK響應(yīng)表示刪除成功。
步驟906,聚合代理單元轉(zhuǎn)發(fā)HTTP 200 OK響應(yīng)給XDM客戶端。
步驟907， XDM客戶端更新本地的快捷回復(fù)消息，即在本地將預(yù)刪除 快捷回復(fù)消息刪除掉。上述作為消息修改請求的XC AP DELET消息的例子如下
DELETE
/Quick-Answer/users/sip:sriram@example.com/QADoc/~ /qa-set/qa[id=QA76587efdky763] HTTP/1.1
其中，id=QA76587efdky763為所要刪除的快捷回復(fù)消息。
步驟904刪除消息ID為QA76587efdky763的快捷回復(fù)消息前的XML 文檔的例子如下
< xml version:'11.0" encoding="UTF-8" >
<qa-set uri="sip:sriram@example.com">
<qa>
<id〉QA76587efdky761 </id〉
<type>Text</type>
<description> Greeting!</description>
<text〉How are you </text>
</qa>
<qa〉
<id>QA76587efdky763</id>
<type>Text</type>
<description〉Busy</description>
<text>Busy now Will talk later</text>
</qa>
</qa-set>
步驟904刪除消息ID為QA76587efdky763的快捷回復(fù)消息后的XML 文檔的例子如下
< xml version-"l.O'' encoding="UTF-8" >
<qa-set uri="sip:sriram@example,com">
<id>QA76587efdky761 </id>
<type>Text</type〉
<description〉 Greeting!</description>
<text>How are you </text〉
</qa>.....
</qa-set〉
IM XDM服務(wù)器返回HTTP 200 OK消息的例子如下:HTTP/1.1 200 OK Etag: "cdcdcdce'，
第二較佳實施例
當采取發(fā)送快捷回復(fù)消息的消息ID方式時，客戶端將快捷回復(fù)消息的 消息ID發(fā)送給客戶端所屬的歸屬服務(wù)器，該歸屬服務(wù)器根據(jù)消息ID從QA 服務(wù)器獲取對應(yīng)的快捷回復(fù)消息的具體內(nèi)容，再發(fā)送給接收端。因此需要在 本發(fā)明實施例的快捷回復(fù)系統(tǒng)中添加QA查詢模塊，用于接收到客戶端發(fā)送 的消息ID后，根據(jù)消息ID從QA服務(wù)器中查找對應(yīng)的消息內(nèi)容，然后再發(fā) 送消息內(nèi)容給接收端的歸屬服務(wù)器。該QA查詢模塊可以設(shè)置在發(fā)送端的歸 屬服務(wù)器中，也可以設(shè)置在其他服務(wù)器中，或者單獨設(shè)置。
圖10為本發(fā)明實施例快捷回復(fù)系統(tǒng)第二較佳實施例的組成框圖。該系 統(tǒng)包括XDM客戶端1010、 IMXDM服務(wù)器1000和QA查詢模塊1021。
該快捷回復(fù)系統(tǒng)與第 一較佳實施例的快捷回復(fù)系統(tǒng)相似，不同之處在 于，本實施例的快捷回復(fù)系統(tǒng)增加了 QA查詢模塊1020。該QA查詢模塊 1020設(shè)置在XDM客戶端的歸屬服務(wù)器A1020中，用于接收XDM客戶端 1010發(fā)來的消息ID,并從QA存儲模塊1002中查找出該消息ID對應(yīng)的快 捷回復(fù)消息的消息內(nèi)容，將該快捷回復(fù)消息的消息內(nèi)容代替消息ID，封裝 成新消息，經(jīng)由歸屬服務(wù)器B發(fā)送給客戶端B。
歸屬服務(wù)器A發(fā)送給歸屬服務(wù)器B的消息如果攜帶的快捷回復(fù)消息比 較小，則可以直接采用SIP MESSAGE或者MSRP SEND消息發(fā)送。如果快 捷回復(fù)消息比較大，可以采用MSRP SEND直接發(fā)送，或者在采用SIP MESSAGE時，在歸屬服務(wù)器A和接收端的客戶端B之間建立Session,實 現(xiàn)消息的順利傳輸。
圖11為本發(fā)明第二較佳實施例第一種實現(xiàn)快捷回復(fù)方法的方法流程 圖。該方法是XDM客戶端A實現(xiàn)快捷回復(fù)，并發(fā)送給客戶端B的第一種具 體實現(xiàn)過程。在發(fā)送過程中，采用發(fā)送快捷回復(fù)消息的消息ID的方式。該方法使用于通過MSRP SEND消息發(fā)送快捷回復(fù)消息，或者通過SIP MESSAGE發(fā)送比較小的快捷回復(fù)消息。參見圖11,該方法包括以下步驟
步驟11O1，用戶想要使用快捷回復(fù)消息時，通過XDM客戶端A發(fā)送 XCAP GET到IM XDM服務(wù)器。XCAP GET為消息獲取請求。
步驟1102, IM XDM服務(wù)器收到XCAP GET后，發(fā)送HTTP 200 OK, 并且在HTTP 200 OK中攜帶發(fā)起請求的用戶的所有快捷回復(fù)消息。
步驟1103, XDM客戶端A接收到用戶的快捷回復(fù)消息，用戶選擇一條 所需的快捷回復(fù)消息。
步驟1104, XDM客戶端A采用SIP MESSAGE或者MSRP SEND,將 用戶選擇的快捷回復(fù)消息發(fā)送到歸屬服務(wù)器A。發(fā)送的SIP MESSAGE或者 MSRP SEND攜帶快捷回復(fù)消息的消息ID。
步驟1105，歸屬服務(wù)器A收到攜帶消息ID的SIP MESSAGE/MSRP SEND后，從IM XDM服務(wù)器中查找該消息ID對應(yīng)的快捷回復(fù)消息的消息 內(nèi)容，并消息ID轉(zhuǎn)換成快捷回復(fù)消息的消息內(nèi)容，重新封裝后發(fā)送給歸屬 服務(wù)器B。假設(shè)消息ID為QA76sadefd123456的快捷回復(fù)消息對應(yīng)具體內(nèi)容 為 一張JPEG格式的圖片，則以MSRP SEND消息為例的轉(zhuǎn)換舉例如下
轉(zhuǎn)換前的MSRP SEND消息包括以下內(nèi)容，
MSRP a786hjs2 SENDTo-Path: msrp:〃 B.ServerB.com: 12763/kjhd37s2s2;tcp From-Path: msrp:〃 A.ServerA.com:7654/jshA7we;tcp Message-ID: 87652Content-Type: multipart/mixed; boundary="boundary42" —boundaryJ2Content-Type: message/QAJD <id> QA76sadefdl23456</^> —boundary42 Content-Type: text/plain Hey Bob, are you there —boundary42 .......a786hjs2$
轉(zhuǎn)換后的MSRP SEND消息包括以下內(nèi)容， MSRP a786hjs2 SENDTo-Path: msrp:〃 B.ServerB.com:12763/kjhd37s2s2;tcp From-Path: msrp:〃 A.ServerA.com:7654/jshA7we;tcp Message-ID: 87652Content-Type: multipart/mixed; boundary="boundary42" —boundary42
Content-Type: image/jpeg
......binary JPEG image.
—boundary42 Content-Type: text/plain
Hey Bob, are you there —boundary42
.......a786s2S
SIP MESSAGE消息的內(nèi)容與MSRP SEND消息類似。
步驟1106,歸屬服務(wù)器A向歸屬服務(wù)器B發(fā)送攜帶快捷回復(fù)消息的消 息內(nèi)容的SIP MESSAGE消息或者MSRP SEND消息。
步驟1107,歸屬服務(wù)器B轉(zhuǎn)發(fā)攜帶快捷回復(fù)消息的消息內(nèi)容的SIP MESSAGE消息或者MSRP SEND消息到客戶端B。
步驟1108,客戶端B返回SIP 200 OK/MSRP 200 OK響應(yīng)到歸屬服務(wù) 器B。
步驟1109，歸屬服務(wù)器B轉(zhuǎn)發(fā)SIP 200 OK/MSRP 200 OK響應(yīng)到歸屬 服務(wù)器A。
步驟1110,歸屬服務(wù)器A轉(zhuǎn)發(fā)SIP 200 OK/MSRP 200 OK響應(yīng)到XDM客戶端A。
以上就完成了一次快捷回復(fù)。消息發(fā)送采用SIP MESSAGE或者MSRP SEND都可以，具體采用哪種方式取決于原有會話所采用的方式，與原有會 話保持一致即可。相應(yīng)的，200 0K也要與發(fā)送消息采用的方式一致。
圖12為本發(fā)明第二較佳實施例第二種實現(xiàn)快捷回復(fù)方法的方法流程 圖。該方法是XDM客戶端A獲取和選取快捷回復(fù)消息，并發(fā)送給客戶端B 的第二種具體實現(xiàn)過程。在發(fā)送過程中，采用SIP MESSAGE消息攜帶快捷 回復(fù)消息的消息ID,且該消息ID對應(yīng)的快捷回復(fù)消息具體內(nèi)容比較大，因 此需要建立Session。參見圖12，該方法包括以下步驟
步驟1201，用戶想要使用快捷回復(fù)消息時，通過XDM客戶端A向IM XDM月良務(wù)器發(fā)送XCAP GET。
步驟1202, IM XDM服務(wù)器收到XCAP GET后，返回HTTP 200 OK， 并且在HTTP 200 OK中攜帶發(fā)起請求的用戶的所有快捷回復(fù)消息。
步驟1203, XDM客戶端A接收到快捷回復(fù)消息，用戶選擇一條所需的 快捷回復(fù)消息。
步驟1204, XDM客戶端A將用戶選擇的快捷回復(fù)消息的消息ID攜帶在SIP MESSAGE消息中，發(fā)送給歸屬服務(wù)器A。
步驟1205,歸屬服務(wù)器A根據(jù)從IMXDM服務(wù)器接收的SIP MESSAGE消息所攜帶的消息ID，查找出該消息ID對應(yīng)的快捷回復(fù)消息的消息內(nèi)容。 并發(fā)現(xiàn)該快捷回復(fù)消息的消息內(nèi)容比較大，使用SIP MESSAGE發(fā)送不了 ， 所以以下需要建立Session使用MSRP進行發(fā)送。
步驟1206 ~ 1211,建立歸屬服務(wù)器A到客戶端B的Session。具體包括，歸屬服務(wù)器A發(fā)送邀請消息SIP INVITE到歸屬服務(wù)器B進 行Session的建立，歸屬服務(wù)器B將該SIP INVITE轉(zhuǎn)發(fā)到客戶端B?？蛻舳?B接收到SIP INVITE后，發(fā)送SIP 200 OK響應(yīng)到歸屬服務(wù)器B，歸屬服務(wù) 器B將SIP 200 OK響應(yīng)轉(zhuǎn)發(fā)到歸屬服務(wù)器A。歸屬服務(wù)器A接收到SIP 200 OK后，發(fā)送ACK到歸屬服務(wù)器B，歸屬服務(wù)器B轉(zhuǎn)發(fā)ACK到客戶端B。 自jt匕，Session建立成功。
步驟1212,歸屬服務(wù)器A根據(jù)步驟1204接收的SIP MESSAGE消息中的消息ID,從IM XDM服務(wù)器中查找到對應(yīng)的快捷回復(fù)消息的消息內(nèi)容， 將消息內(nèi)容代替消息ID。
步驟1213 ~ 1216,歸屬服務(wù)器A采用MSRP SEND將快捷回復(fù)消息的消息內(nèi)容發(fā)送給客戶端B。
具體包括，歸屬服務(wù)器A將攜帶快捷回復(fù)消息的消息內(nèi)容的MSRP SEND發(fā)送給歸屬服務(wù)器B,歸屬服務(wù)器B轉(zhuǎn)發(fā)MSRP SEND到客戶端B; 客戶端B接收到MSRP SEND后，發(fā)送MSRP 200 OK響應(yīng)到歸屬服務(wù)器B, 歸屬服務(wù)器B轉(zhuǎn)發(fā)MSRP 200 OK響應(yīng)到歸屬服務(wù)器A。
步驟1217 ~ 1220,終止歸屬服務(wù)器A到客戶端B的Session。 具體包括，歸屬服務(wù)器A發(fā)送終止消息SIP BYE到歸屬服務(wù)器B,歸 屬服務(wù)器B轉(zhuǎn)發(fā)SIPBYE到客戶端B;客戶端B接收到SIP BYE后，發(fā)送SIP 200 OK響應(yīng)到歸屬服務(wù)器B,歸屬服務(wù)器B將SIP 200 OK響應(yīng)轉(zhuǎn)發(fā)到 歸屬服務(wù)器A。自此，Session被終止。
步驟1221,歸屬服務(wù)器A向客戶端A發(fā)送SIP200 OK響應(yīng)。
以上就完成了一次快捷回復(fù)。
第三較佳實施例
上述第一和第二較佳實施例都是采用XCAP實現(xiàn)快捷回復(fù)消息的獲取 和管理的。還可以采用SIP信令的方式實現(xiàn)。在這種方式下，快捷回復(fù)消息 可以以任何方式存儲于QA服務(wù)器中，例如數(shù)據(jù)庫、文件等方式。快捷回復(fù) 消息對應(yīng)不同用戶分別存儲，快捷回復(fù)消息的消息ID與消息內(nèi)容——對應(yīng)。 QA服務(wù)器可以采用IMSIP服務(wù)器實現(xiàn)；QA服務(wù)器也可以釆用IM XDM服 務(wù)器，此時快捷回復(fù)消息存儲在XML文件中。QA服務(wù)器包括必要的服務(wù)器的QA處理模塊和QA存儲模塊，這兩個模塊的功能與圖3示出的第一較佳實施例快捷回復(fù)系統(tǒng)中相應(yīng)模塊的功能相同。為了完成其它即時消息業(yè) 務(wù)，QA服務(wù)器還包括IMSIP業(yè)務(wù)處理模塊，用于處理除快捷回復(fù)以外的即 時消息業(yè)務(wù)。
客戶端也不必使用專門的XDM客戶端，該客戶端包括必要的客戶端的 QA獲取模塊和QA處理模塊，如果需要存儲用戶的快捷回復(fù)消息，則還包 括客戶端的QA存儲模塊?？蛻舳说腝A獲取模塊、QA處理模塊和QA存 儲模塊的功能與圖3示出的第一較佳實施例快捷回復(fù)系統(tǒng)中相應(yīng)模塊的功 能相同。與第一較佳實施例的快捷回復(fù)系統(tǒng)的不同之處在于，用戶的快捷回 復(fù)消息存儲在客戶端QA存儲模塊中的存儲格式不限制一定是XML文件格式。
與上述兩個較佳實施例實現(xiàn)本發(fā)明快捷回復(fù)方法的具體過程相比，不同 之處僅在于，本實施例客戶端從QA服務(wù)器獲取用戶的所有快捷回復(fù)消息時 是采用SIP信令的方式。后續(xù)的客戶端從獲取的所有快捷回復(fù)消息中選擇快捷回復(fù)消息并發(fā)送給接收端的方法與前述方法相同，也包括直接發(fā)送快捷回復(fù)消息的消息內(nèi)容，或者發(fā)送快捷回復(fù)消息的消息ID。當所發(fā)送的快捷回復(fù)消息的具體內(nèi)容比較大，且采用SIP MESSAGE消息時，也需要建立 Session。
圖13為采用SIP實現(xiàn)快捷回復(fù)消息獲取的方法流程圖。如圖13所示， 其具體實現(xiàn)步驟如下
步驟1300,客戶端向QA服務(wù)器發(fā)送攜帶消息獲取請求的SIP MESSAGE,請求獲取對應(yīng)用戶的快捷回復(fù)消息。
步驟130L QA服務(wù)器返回SIP200 OK。
步驟1302, QA服務(wù)器查找對應(yīng)用戶的快捷回復(fù)消息。
步驟1303, QA服務(wù)器將對應(yīng)用戶的快捷回復(fù)消息攜帶在SIP MESSAGE 中發(fā)送給客戶端。此時SIP MESSAGE的內(nèi)容是管理處理響應(yīng)消息。
步驟1304,客戶端收到SIP MESSAGE消息后，發(fā)送SIP 200 OK響應(yīng) 到QA服務(wù)器。
步驟1305,客戶端將收到快捷回復(fù)消息存儲。
在步驟1300中，QA服務(wù)器也可以對用戶的每個快捷回復(fù)消息都采用 一個SIP MESSAGE發(fā)送，則客戶端在接收到每個SIP MESSAGE后都要發(fā) 送SIP 200 OK響應(yīng)到QA服務(wù)器。因次，步驟1304和步驟1305要重復(fù)執(zhí) 行多次，直到該用戶的所有快捷回復(fù)消息都全部發(fā)送給客戶端。
圖14示出了采用SIP實現(xiàn)快捷回復(fù)消息創(chuàng)建的方法流程圖。如圖14所 示，其具體實現(xiàn)步驟如下
步驟1401,用戶通過客戶端編輯創(chuàng)建一條新快捷回復(fù)消息。
步驟1402 ~ 1403,客戶端采用SIP MESSAGE將用戶創(chuàng)建的快捷回復(fù)消 息發(fā)送到QA服務(wù)器。QA服務(wù)器返回SIP 200 OK。
步驟1404, QA服務(wù)器為收到的新快捷回復(fù)消息創(chuàng)建一個消息ID，并將新快捷回復(fù)消息及其消息ID存儲在QA服務(wù)器的QA存儲單元中。
步驟1405 ~ 1406, QA服務(wù)器通過SIP MESSAGE將新快捷回復(fù)消息及 其消息ID發(fā)送到客戶端，客戶端返回SIP 200 OK。此處的SIP MESSAGE為管理處理響應(yīng)消息。
步驟1407,客戶端更新本地對應(yīng)的快捷回復(fù)消息。將新快捷回復(fù)消息 及其消息ID添加到客戶端。
圖15示出了采用SIP實現(xiàn)快捷回復(fù)消息^修改的方法流程圖。如圖15所 示，其具體實現(xiàn)步驟如下
步驟1500，用戶通過客戶端選擇一個要修改的快捷回復(fù)消息，并進行 修改。
步驟1501,客戶端將修改的快捷回復(fù)消息及其消息ID通過SIP MESSAGE發(fā)送給QA服務(wù)器。
步驟1502， QA服務(wù)器根據(jù)接收到的修改的快捷回復(fù)消息及其消息ID, 對存儲在QA服務(wù)器對應(yīng)的快捷回復(fù)消息進行修改。
本步驟中，QA服務(wù)器根據(jù)消息ID查找到對應(yīng)的快捷回復(fù)消息，并根 據(jù)消息內(nèi)容對存儲的快捷回復(fù)消息的消息內(nèi)容進行修改。
步驟1503, QA服務(wù)器向客戶端發(fā)送SIP 200 OK。 SIP 200 OK為管理 處理響應(yīng)信息，表示^務(wù)改成功。
步驟1504,客戶端更新本地對應(yīng)的快捷回復(fù)消息。
圖16示出了采用SIP實現(xiàn)快捷回復(fù)消息刪除的方法流程圖。如圖16所 示，其具體實現(xiàn)步驟如下
步驟1600，用戶通過客戶端選擇一條預(yù)刪除快捷回復(fù)消息。
步驟1601 - 1602，客戶端向DELETE Bin發(fā)送攜帶預(yù)刪除快捷回復(fù)消 息的消息ID的SIP REFER, DELETE Bin返回SIP 200 OK。
刪除快捷回復(fù)消息要通過DELETE Bin間接實現(xiàn)對QA服務(wù)器中的快捷 回復(fù)消息的刪除。SIP REFER消息的具體可以設(shè)置為SIP REFER消息中 Request - URI屬性為DELETE@hostname ， Refer-To屬性為預(yù)刪除快捷回復(fù) 消息的消息ID, Method屬性為INVITE。因此，這里的SIPREFER作為基 于SIP的信息刪除命令。
步驟1603 - 1605, DELETE Bin根據(jù)消息ID刪除QA服務(wù)器中對應(yīng)的
快捷回復(fù)消息。
本步驟具體包括，DELETE Bin發(fā)送SIP INVITE到QA服務(wù)器。該SIP INVITE消息的會話描述協(xié)議(SDP)的媒體方式屬性設(shè)為"recvonly" 。 QA 服務(wù)器根據(jù)SIP INVITE將消息ID對應(yīng)的快捷回復(fù)消息刪除后，返回SIP 200 OK,表示刪除成功。DELETE Bin再向QA服務(wù)器發(fā)送ACK響應(yīng)消息。
步驟1607~ 1607，終止QA服務(wù)器于DELETE Bin之間建立的Session。 具體包括，QA服務(wù)器向DELELTE Bin發(fā)送SIP BYE, DELETE Bin返回SIP 200 OK。
步驟1608，客戶端更新本地快捷回復(fù)消息。該步驟也可以在步驟1602 之后，步驟1603之前執(zhí)行。
如果客戶端發(fā)送的SIP REFER含有隱含定閱信息，則步驟1603之前進 一步包括DELETE Bin向客戶端發(fā)送SIP NOTIFY,客戶端返回SIP 200 OK 響應(yīng)的步驟1605和步驟1607之后也要包括同樣的步驟。
需要說明的是，客戶端和QA服務(wù)器之間的信息交互都需要經(jīng)過SIP Core。
由以上所述可以看出，本發(fā)明實施例所提供的快捷回復(fù)方法、系統(tǒng)、快 捷回復(fù)服務(wù)器和客戶端，能夠使用戶在不同終端上方便的使用相同的屬于自 己的快捷回復(fù)消息，避免了用戶在每個終端上都要進行設(shè)置相同快捷回復(fù)消 息的重復(fù)操作。如果用戶在一個終端上對QA服務(wù)器上的快捷回復(fù)消息進行 了添加或修改，那么該用戶在另外不同的終端上仍然可以使用其最后更新過 的快捷回復(fù)消息。
另外，在發(fā)送比較大的快捷回復(fù)消息時，發(fā)送端可以只發(fā)送消息ID, 發(fā)送端歸屬服務(wù)器把該消息ID轉(zhuǎn)換成消息內(nèi)容，再發(fā)送給接收端，這樣有 效的減少了發(fā)送端和發(fā)送端歸屬服務(wù)器之間的網(wǎng)絡(luò)負載，大大提高了發(fā)送較大快捷回復(fù)消息的效率。
綜上所述，以上僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的 保護范圍。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改
進等，均應(yīng)包含在本發(fā)明的保護范圍之內(nèi)。
權(quán)利要求
1、一種快捷回復(fù)方法，其特征在于，該方法包括在快捷回復(fù)QA服務(wù)器中設(shè)置快捷回復(fù)消息；客戶端向QA服務(wù)器發(fā)起消息獲取請求；QA服務(wù)器根據(jù)所述消息獲取請求，向該客戶端返回快捷回復(fù)消息；客戶端從返回的快捷回復(fù)消息中選取預(yù)發(fā)送的快捷回復(fù)消息，并向接收端發(fā)送。
2、 如權(quán)利要求l所述的方法，其特征在于， 所述消息獲取請求包括用戶標識ID;所述QA服務(wù)器根據(jù)消息獲取請求向客戶端返回快捷回復(fù)消息包括所述 QA服務(wù)器根據(jù)所述用戶ID,獲取存儲的與所述用戶ID對應(yīng)的快捷回復(fù)消息， 并向所述客戶端返回所述對應(yīng)的快捷回復(fù)消息。
3、 如權(quán)利要求l所述的方法，其特征在于，所述向客戶端返回快捷回復(fù)消 息之后，該方法進一步包括所述客戶端在本地保存返回的快捷回復(fù)消息。
4、 如權(quán)利要求l所述的方法，其特征在于，客戶端發(fā)送的所述預(yù)發(fā)送的快 捷回復(fù)消息包括該預(yù)發(fā)送的快捷回復(fù)消息的消息內(nèi)容；客戶端向接收端發(fā)送所述預(yù)發(fā)送的快捷回復(fù)消息之后，該方法進一步包括 客戶端的歸屬服務(wù)器接收到所述消息內(nèi)容后轉(zhuǎn)發(fā)給所述接收端。
5、 如權(quán)利要求l所述的方法，其特征在于，客戶端發(fā)送的所述預(yù)發(fā)送的快捷回復(fù)消息包括該預(yù)發(fā)送的快捷回復(fù)消息的 消息ID;客戶端向接收端發(fā)送所述預(yù)發(fā)送的快捷回復(fù)消息之后，該方法進一步包括 客戶端的歸屬服務(wù)器接收到所述消息ID后，根據(jù)所述消息ID從QA服務(wù)器獲取所述消息ID對應(yīng)的消息內(nèi)容，將所述消息內(nèi)容發(fā)送給所述接收端。
6、 如權(quán)利要求l所述的方法，其特征在于，該方法進一步包括 客戶端向QA服務(wù)器發(fā)送管理信息；所述QA服務(wù)器根據(jù)所述管理信息，管理其存儲的快捷回復(fù)消息。
7、 如權(quán)利要求3所述的方法，其特征在于，該方法進一步包括 客戶端向QA服務(wù)器發(fā)送管理信息；所述QA服務(wù)器根據(jù)所述管理信息，管理其存儲的快捷回復(fù)消息； 所述QA服務(wù)器向所述客戶端返回管理處理響應(yīng)信息； 所述客戶端^^艮據(jù)所述管理處理響應(yīng)信息，更新本地快捷回復(fù)消息。
8、 如權(quán)利要求6或7所述的方法，其特征在于，當所述管理信息為創(chuàng)建信 息時，該創(chuàng)建信息包括客戶端創(chuàng)建的新快捷回復(fù)消息的消息內(nèi)容；所述客戶端向QA服務(wù)器發(fā)送管理信息；QA服務(wù)器根據(jù)該管理信息管理其存儲的快捷回復(fù)消息包括客戶端將所述新快捷回復(fù)消息的消息內(nèi)容發(fā)送給QA服務(wù)器；所述QA服務(wù)器為該新快捷回復(fù)消息建立消息ID,并存儲所述新快捷回復(fù)消息的消息內(nèi)容和消息ID。
9、 如權(quán)利要求6或7所述的方法，其特征在于，當所述管理信息為修改信 息時，該修改信息包括攜帶消息ID的修改后快捷回復(fù)消息；所述客戶端向QA服務(wù)器發(fā)送管理信息；QA服務(wù)器根據(jù)該管理信息管理其存儲的快捷回復(fù)消息包括客戶端將所述攜帶消息ID的修改后快捷回復(fù)消息發(fā)送給QA服務(wù)器； 所述QA服務(wù)器根據(jù)所述攜帶消息ID的修改后快捷回復(fù)消息，修改該消息ID對應(yīng)的快捷回復(fù)消息。
10、 如權(quán)利要求6或7所述的方法，其特征在于，當所述管理信息為刪除 信息時，該刪除信息包括預(yù)刪除快捷回復(fù)消息的消息ID;所述客戶端向QA服務(wù)器發(fā)送管理信息；QA服務(wù)器根據(jù)該管理信息管理其存儲的快捷回復(fù)消息包括客戶端選擇預(yù)刪除的快捷回復(fù)消息，將該預(yù)刪除快捷回復(fù)消息的消息ID發(fā) 送給QA服務(wù)器； 所述QA服務(wù)器根據(jù)所述預(yù)刪除快捷回復(fù)消息的消息ID,刪除對應(yīng)的快捷 回復(fù)消息。
11、 如權(quán)利要求1所述的方法，其特征在于，所述快捷回復(fù)消息為短消息 或即時消息。
12、 如權(quán)利要求6所述的方法，其特征在于，所述客戶端采用會話初始協(xié) 議SIP向所述QA服務(wù)器發(fā)送所述消息獲取請求和所述管理信息。
13、 如權(quán)利要求6所述的方法，其特征在于，所述客戶端采用擴展標簽語 言配置訪問協(xié)議XCAP向所述QA服務(wù)器發(fā)送所述消息獲取請求和所述管理信 白、
14、 一種快捷回復(fù)系統(tǒng)，其特征在于，該系統(tǒng)包括客戶端和QA服務(wù)器； 所述客戶端，用于向所述QA服務(wù)器發(fā)起消息獲取請求；接收所述QA服務(wù)器返回的快捷回復(fù)消息；并向接收端發(fā)送從所述返回的快捷回復(fù)消息中選擇 的預(yù)發(fā)送的快捷回復(fù)消息；所述QA服務(wù)器，存儲快捷回復(fù)消息，用于根據(jù)接收自所述客戶端的消息 獲取請求，向所述客戶端返回快捷回復(fù)消息。
15、 如權(quán)利要求14所述的系統(tǒng)，其特征在于，所述預(yù)發(fā)送的快捷回復(fù)消息 包括該預(yù)發(fā)送的快捷回復(fù)消息的消息ID;該系統(tǒng)進一步包括QA查詢模塊，用于接收所述客戶端發(fā)送的所述預(yù)發(fā)送 的快捷回復(fù)消息的消息ID,根據(jù)該消息ID從所述QA服務(wù)器中查找出對應(yīng)的 快捷回復(fù)消息的消息內(nèi)容，再將該快捷回復(fù)消息的消息內(nèi)容發(fā)送給接收端。
16、 如權(quán)利要求14或15所述的系統(tǒng)，其特征在于，所述客戶端進一步用 于，向所述QA服務(wù)器發(fā)送管理信息；根據(jù)所述QA服務(wù)器返回的管理處理響 應(yīng)信息更新本地快捷回復(fù)消息。
17、 如權(quán)利要求14或15所述的系統(tǒng)，其特征在于，所述QA服務(wù)器進一步用于，根據(jù)所述客戶端發(fā)來的管理信息，管理其存儲的快捷回復(fù)消息。
18、 一種快捷回復(fù)服務(wù)器，其特征在于，該服務(wù)器包括服務(wù)器QA處理模 塊和服務(wù)器存儲模塊；所述服務(wù)器存儲模塊，與所述服務(wù)器QA處理模塊相連，用于存儲快捷回 復(fù)消息；所述服務(wù)器QA處理模塊，用于接收客戶端發(fā)起的消息獲取請求，根據(jù)該 消息獲取請求從所述服務(wù)器存儲模塊中獲取對應(yīng)的快捷回復(fù)消息，返回給所述 客戶端。
19、 如權(quán)利要求18所述的服務(wù)器，其特征在于，該服務(wù)器進一步包括業(yè)務(wù) 處理模塊，用于處理非快捷回復(fù)的即時消息業(yè)務(wù)。
20、 如權(quán)利要求19所述的服務(wù)器，其特征在于，所述業(yè)務(wù)處理模塊為短消 息業(yè)務(wù)處理模塊、即時消息擴展標簽語言文檔管理IMXDM業(yè)務(wù)處理模塊或即 時消息會話初始協(xié)議IM SIP業(yè)務(wù)處理模塊。
21、 如權(quán)利要求18所述的服務(wù)器，其特征在于，所述服務(wù)器QA處理模塊 進一步用于，根據(jù)客戶端發(fā)來的管理信息，管理所述服務(wù)器存儲模塊中的快捷 回復(fù)消息。
22、 一種快捷回復(fù)客戶端，其特征在于，該客戶端包括QA獲取模塊和 客戶端QA處理模塊；所述QA獲取模塊，用于向QA服務(wù)器發(fā)起消息獲取請求；接收所述QA 服務(wù)器返回的快捷回復(fù)消息，并發(fā)送給所述客戶端QA處理模塊；所述客戶端QA處理模塊，用于從接收自所述QA獲取模塊的所述返回的 快捷回復(fù)消息中，選擇預(yù)發(fā)送的快捷回復(fù)消息，向接收端發(fā)送。
23、 如權(quán)利要求22所述的客戶端，其特征在于，該客戶端進一步包括客戶 端存儲模塊，與所述客戶端QA處理模塊相連，用于存儲快捷回復(fù)消息；所述客戶端QA處理模塊進一步用于，將接收自所述QA獲取模塊的所述 返回的快捷回復(fù)消息存儲在所述客戶端存儲模塊。
24、 如權(quán)利要求23所述的客戶端，其特征在于，所述客戶端QA處理模塊 進一步用于，向QA服務(wù)器發(fā)送管理信息；根據(jù)所述QA服務(wù)器返回的管理處 理響應(yīng)信息更新本地快捷回復(fù)消息。
全文摘要
本發(fā)明公開了一種快捷回復(fù)方法，該方法包括，在快捷回復(fù)QA服務(wù)器中設(shè)置快捷回復(fù)消息；當客戶端向QA服務(wù)器發(fā)起消息獲取請求后，QA服務(wù)器根據(jù)接收的消息獲取請求，向該客戶端返回快捷回復(fù)消息，客戶端從返回的快捷回復(fù)消息中選取預(yù)發(fā)送的快捷回復(fù)消息，并向接收端發(fā)送。使用本發(fā)明能夠?qū)崿F(xiàn)用戶在不同終端上使用相同的快捷回復(fù)消息。本發(fā)明還公開了快捷回復(fù)系統(tǒng)、快捷回復(fù)服務(wù)器和客戶端，能夠保證用戶在不同終端上使用相同的快捷回復(fù)消息，避免了用戶在不同終端上都要進行相同的增加或刪除快捷回復(fù)消息操作，降低了操作的復(fù)雜程度。
文檔編號H04W4/12GK101202953SQ20061016801
公開日2008年6月18日 申請日期2006年12月15日 優(yōu)先權(quán)日2006年12月15日
發(fā)明者淵 包, 牟倫建, 迪潘書·高塔姆 申請人:華為技術(shù)有限公司