專利名稱：實現(xiàn)問答業(yè)務的方法、客戶端和服務器的制作方法
技術領域：
本發(fā)明涉及即時通信領域，尤其涉及基于即時消息和呈現(xiàn)業(yè)務實現(xiàn)問答 業(yè)務的方法、客戶端和服務器。
背景技術：
目前在線問答業(yè)務已經在各個國家廣泛開展，大型的問答網站有百度 "知道"、新浪"愛問"、雅虎"知識堂"及博學吧等。這類網站往往采用 注冊積分制度，注冊成為會員后，便能參與提出自己的問題或者為發(fā)問用戶 解答問題，如果回答出色還能獲得積分。在這些問答網站中，除了能針對自 己的問題尋求其他用戶的解答外，也能看到別人的問題和答案是什么。問答 業(yè)務正是對搜索引擎的一種補充，因為有些問題很難用搜索引擎直接獲得答 案，人工解決問題是永遠無法用機器完全替代的。
然而這些問答網站中的用戶之間往往互不相識，用戶提供答案的動力主 要是可以獲得積分，然后可以利用積分獎勵來使自己的問題得到盡快的解 答。實際上在朋友之間是更愿意互相幫助的，而且有些問題也更適合熟悉的 人如同事、同學等進行解答。目前人們以即時消息互相進行通信的方式越來 越流行，即時通信工具除了即時消息外同時還提供好友管理以及顯示好友的 呈現(xiàn)信息等功能，已經成為承載現(xiàn)代人際關系社會網絡的最理想工具。如果 可以基于即時通信工具來實現(xiàn)問答業(yè)務，將是對目前以問答網站為主的問答 業(yè)務的一個重大提升和補充。
一般的即時通信工具可以分為三部分，包括即時消息、呈現(xiàn)信息、好友 管理。很多即時通信工具還實現(xiàn)了即時消息與短消息/多媒體消息的互通， 以及支持語音、視頻等多媒體通信，甚至還可以和傳統(tǒng)的電話互通。而即時通信工具中通過好友管理所建立的人際關系網絡，則是其最有價值最值得發(fā) 掘利用的信息。
發(fā)明內容
本發(fā)明實施例提出了一種實現(xiàn)問答業(yè)務的方法，使用戶可以基于廣泛使 用的即時通信工具提出問題并獲得回答。
本發(fā)明實施例還提出了一種即時通信客戶端，用戶使用該客戶端即可提 出問題并獲得回答。
本發(fā)明實施例還提出了 一種即時通信服務器，可以提供基于即時消息和 呈現(xiàn)業(yè)務的問答業(yè)務。
本發(fā)明實施例還提出了另外 一種實現(xiàn)問答業(yè)務的方法，使用戶可以基于 廣泛使用的即時通信工具提出問題并獲得回答。
本發(fā)明實施例提出的技術方案如下
一種實現(xiàn)問答業(yè)務的方法，該方法包括步驟
第 一客戶端將問題信息包含在呈現(xiàn)信息中進行發(fā)布；
第二客戶端獲得包含問題信息的呈現(xiàn)信息；
第二客戶端將答案信息通過即時消息發(fā)送給第 一客戶端；
第一客戶端將所接收到的答案和對應的問題一起顯示出來。
一種即時通信客戶端，所述客戶端包括
問題呈現(xiàn)信息設置模塊，用于接收問題的輸入，并將問題信息包含在呈 現(xiàn)信息中進行發(fā)布；
答案即時消息發(fā)送模塊，用于從呈現(xiàn)信息中提取問題信息，并接收答案 的輸入，然后將答案信息通過即時消息發(fā)送；
問題和答案顯示模塊，用于將即時消息中的答案以及對應的問題顯示出來。
一種即時通信服務器，所述服務器包括呈現(xiàn)信息處理模塊，用于接收包含問題信息的呈現(xiàn)信息，并將其進行分
發(fā)；
即時消息處理模塊，用于接收包含答案信息的即時消息，并將其進行轉發(fā)。
一種實現(xiàn)問答業(yè)務的方法，該方法包括步驟 接收包含問題信息的呈現(xiàn)信息并進行分發(fā)； 接收包含答案信息的即時消息并進行轉發(fā)。
本發(fā)明的有益效果如下
本發(fā)明實施例通過在呈現(xiàn)信息中發(fā)布問題信息，用即時消息發(fā)送答案信 息，巧妙得利用即時通信中的呈現(xiàn)業(yè)務和即時消息來實現(xiàn)問答業(yè)務，充分使 用了用戶在通信網絡尤其是即時通信系統(tǒng)中已形成的人際關系社會網絡數 據信息，而且不必群發(fā)消息主動向眾多好友征詢問題的答案，避免了用戶為 獲得答案而要發(fā)送大量消息，而眾多好友也可以免受騷擾。另外還提供了問 題的轉發(fā)機制，使問題可以在用戶的人際關系網絡中廣泛傳播，問題獲得解 答的幾率大大提高，并且問題的答案還可以通過即時消息發(fā)送給初始提出問 題者或者其他也關注該問題的轉發(fā)者，從而使除提問者之外的更多人也可以 獲得問題的答案。
圖1為本發(fā)明實施例實現(xiàn)問答業(yè)務的方法基本流程圖； 圖2為本發(fā)明實施例即時通信客戶端的結構示意圖。
具體實施例方式
參照圖1,該圖是本發(fā)明實施例實現(xiàn)問答業(yè)務的基本流程圖，包括如下步驟
步驟IOI、第一客戶端將問題信息作為呈現(xiàn)信息進行發(fā)布。第一客戶端 即提出問題者對應的客戶端，包含問題信息的呈現(xiàn)信息可以直接分別發(fā)送給 訂閱其呈現(xiàn)信息的其他客戶端，也可以先發(fā)布到呈現(xiàn)服務器再由其進行分 發(fā)。為了實施簡單，可以在呈現(xiàn)信息中只包含一條問題信息。
步驟102、第二客戶端獲得包含問題信息的呈現(xiàn)信息。第二客戶端訂閱 了提出問題者即第 一客戶端的呈現(xiàn)信息，第二客戶端一般為第 一客戶端好友 列表中的用戶的客戶端。如果用戶不希望收到問題信息，則可以在訂閱呈現(xiàn) 信息時將問題信息過濾掉。
步驟103、第二客戶端將答案信息通過即時消息發(fā)送給第一客戶端。第 二客戶端將用戶輸入的答案信息包含在內容類型為答案的即時消息體中，發(fā) 送給第一客戶端。
步驟104、第一客戶端將所接收到的答案信息和對應的問題信息一起顯 示出來。第一客戶端在收到即時消息后，檢測到其內容類型為答案，則將即 時消息其中的答案信息和對應的問題信息一起呈現(xiàn)給用戶。
值得注意的是，即使呈現(xiàn)信息中只包含一條問題信息，也最好為問題信 息設置一個本地唯一的問題標識，第二客戶端發(fā)送包含答案信息的即時消息 時也帶上相應的問題標識，這樣第 一 客戶端可以明確無誤的匹配問題信息和 答案信息。否則有可能第一客戶端在收到第二客戶端的答案信息時，其當前 的問題信息已不再是第二客戶端所看到的問題信息了 ，從而產生匹配錯誤。 當然另外一種方案就是在第二客戶端發(fā)送包含答案信息的即時消息時，可以
直接從呈現(xiàn)信息中獲取問題信息，第二客戶端發(fā)送答案信息和對應問題信息 的即時消息給第一客戶端。這樣雖然簡單，但消息內容增加了冗余的問題信 息，而且不利于第一客戶端對問題信息和答案信息做進一步的自動處理，如 在用戶接受答案后，客戶端無法自動清除已經被解決的問題信息，需要用戶 手動進行處理。第 一實施例中基于互聯(lián)網工程組IETF (Internet Engineering Task Force ) 的SIP (Session Initiation Protocol)協(xié)議的即時消息和呈現(xiàn)業(yè)務規(guī)范來實現(xiàn) 問答業(yè)務(Question and Answer)?？梢詫l(fā)布問題呈現(xiàn)信息的客戶端稱為 呈現(xiàn)體客戶端，訂閱問題呈現(xiàn)信息的客戶端稱為觀察者客戶端。當然實際中 一個用戶的客戶端可以同時既發(fā)布自己的呈現(xiàn)信息又會訂閱其他人的呈現(xiàn) 信息。此處所說的客戶端同時具有呈現(xiàn)業(yè)務和即時消息業(yè)務的客戶端功能。
首先擴展目前的呈現(xiàn)信息，增加問題信息，如在目前的人物元素 〈person〉中增力。問題子元素，其內容舉例如下
<person〉
<question-list〉
〈questionid-"qls34r"〉誰能買到10月1號的火車票〈/question〉
<question id二"q2f27h"〉張三的電話是多少〈/question〉
</question-list〉 </person>
其中〈person〉元素包含一個問題列表子元素〈question-list〉，該問題列表 子元素包含一個或多個問題元素如<question>,每個問題元素具有一個標識 屬性如"id",唯一標識一個問題。問題元素的值則可以包含問題的具體文 字信息。
另外對每個問題還可以對應設置有效期，其值可以是絕對時間，如 "2007-1 l-06T12:10:00Z，，，代表該問題的截止有效時間，當過了有效時間 之后則問題失效。服務器可以自動清除呈現(xiàn)信息中失效的問題信息，觀察者 客戶端也可以不再顯示失效的問題呈現(xiàn)信息。
有時候提問者希望盡快獲得答案，則可以在問題呈現(xiàn)信息中設置緊急標 志，當觀察者客戶端獲得具有緊急標志的問題呈現(xiàn)信息時，對該問題呈現(xiàn)信 息可進行醒目模式顯示，如在提問者頭像圖標旁邊顯示紅色或閃爍的問號， 或者"SOS"圖標等方式表示提問者有緊急需要解答的問題。以下舉例描述包含有效期和緊急標志的問題呈現(xiàn)信息
〈question id="q2f27h" until="2007-l l-06T12:10:00Z" urgent="true" > 張三的電話是多少〈/question〉
其中問題元素的有效期屬性"until"中包含問題截止的有效時間，緊急 標志屬性"urgent"置為真"true"表示為緊急問題。
呈現(xiàn)體客戶端將問題信息包含在呈現(xiàn)信息事件包中發(fā)布，具體的可以采 用SIP的發(fā)布PUBLISH方法。PUBLISH的消息部分內容舉例如下
PUBLISH sip:usera@example.com SIP/2.0
Everit: presence
Content-Type: application/pidf+xml
<person>
<question-list〉
〈question id-"q3t82z"〉百草園附近有沒有茶館〈/question〉 </question-list> </person>
為了簡明起見，PUBLISH的消息頭和消息體的內容做了一些省略。其 中頭字段Event中的"presence"指示所發(fā)布的內容為呈現(xiàn)信息，呈現(xiàn)信息 內容的類型Content-Type具體為"application/pidf+xml"格式。另外通常呈 現(xiàn)信息還包括業(yè)務和設備信息，即一個或多個〈tuple〉和〈device〉元素。具體 可參見RFC 4779 ( A Data Model for Presence )等IETF SIMPLE工作組的標 準規(guī)范。
呈現(xiàn)服務器將包含問題信息的呈現(xiàn)信息通過SIP通知方法NOTIFY發(fā)送 給觀察者。觀察者的客戶端上可以顯示收到的問題信息，具體的顯示方法可 以在好友列表窗口對應用戶的旁邊顯示一個問號圖標，當鼠標停留在該問號 圖標上后，可以用一個浮動窗口顯示該用戶的問題信息。如果一個觀察者要回答一個問題，可以用鼠標單擊該問號圖標，觀察者的客戶端獲取呈現(xiàn)信息 中的問題標識，并彈出一個窗口提示輸入答案信息，然后將輸入的答案信息
和對應的問題標識一起用SIP的MESSAGE方法發(fā)送給提出該問題的用戶。 MESSAGE方法的部分消息內容舉例如下
MESSAGE sip:usera@example.com SIP/2.0
Content-Type: application/answer+xml
<answer question-id="q2f27h">
張三的電話是28787351 </answer>
其中部分內容進行了省略，在MESSAGE方法的消息中包含內容類型為 答案如"application/answer+xml"的消息體，消息體內容可以包含一個答案 元素如〈answer〉，該答案元素還可以包含一個問題標識屬性如"question-id"， 答案元素的值包含答案的相關文字信息。
接收到該MESSAGE消息的客戶端檢測到該即時消息的內容類型為答 案類型，則根據MESSAGE消息體中的問題標識獲取呈現(xiàn)信息中對應的問 題，然后同時將呈現(xiàn)信息中的問題信息和MESSAGE消息體中對應的答案信 息一起顯示出來。
用戶的客戶端可以根據問題和答案的對應關系記錄問題和相應的 一個 或多個答案， 一個問題可以對應多個答案。這些問答歷史記錄可以供用戶以 后查閱，或者轉發(fā)給其他的用戶。
對于一些問題，用戶希望在有答案時能立即通知自己，但當用戶不在線 時，無法獲得即時消息。用戶可以對單個問題設置是否實時通知，具體的可 在即時消息服務器設置問題標識和對應的手機號碼，當即時消息服務器接收 到即時消息如MESSAGE消息，其中的問題標識與用戶所設置的相同，并且 當前用戶不在線，則將消息中的文本內容即答案內容通過SMPP (短消息點對點協(xié)議)等協(xié)議經短消息中心或通過MM7接口協(xié)議經多媒體消息中心轉 發(fā)給用戶所設置的手機號碼。
為了充分利用已有的問答網站，在問題呈現(xiàn)信息被發(fā)布到呈現(xiàn)服務器 后，呈現(xiàn)服務器也可以自動將問題信息提交到問答網站。為了避免重復問題， 可以禁止發(fā)布轉發(fā)的問題到問答網站。而網站中對該問題的答案信息也自動 包含在即時消息中發(fā)送給提問者。另外呈現(xiàn)服務器還可以將問題信息提交到 用戶對應的博客Blog網站中，這樣用戶的博客頁面上可以顯示類似"我的 問題"的標簽頁，將用戶所提過的問題集中顯示在這里。
對于問答網站已有的問題，如果用戶在網站登錄后瀏覽時對一個問題感 興趣，但目前網站還沒有答案，則可以點擊問題網頁上的一個按鈕，指示將 該問題設置到自己的呈現(xiàn)信息中。具體的問答網站在接收到用戶的超文本傳 輸協(xié)議HTTP ( HyperText Transfer Protocol)設置請求后，問答網站作為用 戶的呈現(xiàn)信息源將問題信息作為呈現(xiàn)信息發(fā)布到用戶歸屬的呈現(xiàn)服務器中， 呈現(xiàn)服務器將該問題信息與用戶發(fā)布的其他呈現(xiàn)信息進行合成，然后分發(fā)給 訂閱者。用戶一般在問答網站注冊有自己的地址標識，通常電子郵件地址可 以同時作為問答網站、即時消息和呈現(xiàn)業(yè)務的登錄賬戶標識。
考慮到社區(qū)交友網站本質上可以提供即時通信工具所具有的好友列表 即人際關系網絡，如Facebook、 Myspace、校內網和中國緣等網站，也可以 在這些網站中提供問答業(yè)務應用?？梢栽诰W站的個人信息資料中設置問題信 息，用戶在網站中瀏覽其他用戶的個人信息時可以看到問題信息。然后可以 通過網站的網頁對問題提供答案。提出問題的用戶可以查詢自己問題的狀態(tài) 以及對應的答案。這種基于人際關系網絡的問答業(yè)務，可以不必使用復雜的 積分制度來激勵用戶回答問題，充分利用了用戶在通信網絡中已經形成的人 際關系數據信息。
當然本發(fā)明的技術方案也可以結合一些激勵機制，如常用的懸賞提問機 制和答題積分機制等。如果實現(xiàn)問答業(yè)務的系統(tǒng)中支持虛擬貨幣或虛擬物品，還可以直接利用虛擬貨幣或虛擬物品代替積分獎勵。如提問者在獲得答 案后，可以向提供答案的用戶贈送一定數量的虛擬貨幣或者虛擬物品作為答 謝。
第二實施例中，提供了一種方法使用戶的問題在更大范圍進行傳播。一 個用戶的呈現(xiàn)信息通常只有自己的好友才能看到，而一個普通用戶一般也不 會有超過兩百個好友，而與用戶同時在線的好友一般更少，平均不會超過一 百個。實際上知道問題的人越多，用戶獲得答案的機會就越大，因此最好能
讓更多的人看到問題信息。本實施例中，當一個用戶A的客戶端發(fā)布了問 題呈現(xiàn)信息后，訂閱了其呈現(xiàn)信息的好友B的客戶端獲得了問題呈現(xiàn)信息 后，可以將其問題呈現(xiàn)信息作為自己的呈現(xiàn)信息進行發(fā)布，當然在B的客戶 端發(fā)布的問題呈現(xiàn)信息中除了問題外還包括問題初始提出人以及原始的問 題標識等信息。舉例如下 <person>
<question-list>
<question id="pl4ts9">
〈description〉百草園附近有沒有茶館々description〉 <original-asker qid="q3t82z"〉sip:usera@example,com
</original-asker>
</question>
<question id="p25sd3">
〈description〉南山區(qū)哪個超市肉菜比較新鮮〈/description〉 </question> </question-list> </person>
其中在B的問題列表中包含兩個問題元素， 一個是用戶A的問題，在 子元素問題描述〈description〉中包含問題的描述信息，在另 一個子元素初始 提問者<original-asker>中包含初始的提出問題的用戶標識如"sip:usera@example.com"和初始的問題標識如"qid"。用戶標識一4殳采用 SIP URI (統(tǒng)一資源標識符)，其中還可以包括顯示名或昵稱，如"Alice <sip:usera@example.com>"。另外一個是用戶B自己的問題，只包含一個 〈description〉子元素。兩個問題元素的問題標識屬性值是由B的客戶端生成 的，每個問題標識保證在B的問題集中唯一即可。即使與另一個用戶如A 初始的問題標識相同也沒關系。
客戶端可以缺省的設置自動將好友的問題也作為自己的問題進行發(fā)布。 但是可以限制自己問題的總數上限如10個，以避免問題數過多。當問題總 數達到上限，用戶希望發(fā)布自己的問題信息時，則可以用自己的問題替換已 有的好友的問題。還可以進一步設置是否自動將好友轉發(fā)的問題也作為自己 的問題進行發(fā)布，如上例中包含〈original-asker〉信息的問題則不是用戶B自 己提出的問題，用戶B的好友C的客戶端可以設置對這種用戶B轉發(fā)的問 題是否繼續(xù)進行轉發(fā)。如果用戶C繼續(xù)進行轉發(fā)時，則其客戶端發(fā)布的該問 題對應的初始提出問題的用戶標識仍舊是用戶 A的標識如 "sip:usera@example.com，，，而不是用戶B的標識。如此，即{吏經過多次轉 發(fā)傳播之后，最終提供答復信息的客戶端仍舊可以據此將答復消息直接發(fā)送 到初始提出問題的用戶那里。另外〈original-asker〉中的信息還可以避免問題 的重復循環(huán)轉發(fā)，用戶之間的關系網絡是交錯重疊的，如果一個客戶端根據 一個要轉發(fā)的問題信息中的初始提出問題的用戶標識和問題標識是一個自 己已經發(fā)布過的問題，則不再進行重復轉發(fā)。通過本實施例中的方法，可見 問題可以沿著用戶的人際關系網絡進行大范圍的轉發(fā)傳播。
如果一個用戶刪除了自己所發(fā)布的呈現(xiàn)信息中一個問題信息，則呈現(xiàn)服 務器向其好友即訂閱者發(fā)送的包含呈現(xiàn)信息更新通知中也會去掉相應的問 題信息，然后如果好友的客戶端轉發(fā)過該問題，則此時會取消對該問題的轉 發(fā)。
最初提出問題的用戶可能除了獲得答案外還希望同時獲得認識提供答案的人的人際關系路徑?？蛻舳丝梢詫栴}的轉發(fā)路徑也作為呈現(xiàn)信息發(fā)
布，按次序依次將轉發(fā)的用戶標識放在路徑元素〈via〉中，對應的問題標識 放在該元素的問題標識屬性中如"qid"。例如上述例子中如果用戶B的好 友C繼續(xù)對問題進行轉發(fā)時，其問題呈現(xiàn)信息內容舉例如下 <question id="p41rlt">
〈description〉百草園附近有;殳有茶4官〈/description〉 <via qid="q3t82z">sip:usera@example.com</via> <via qid="pl4ts9">sip:userb@example.com</via> </question>
其中路徑元素〈via〉從上到下依次排列，最上面的路徑節(jié)點元素<^3〉中 包含初始提出的問題用戶標識。每個客戶端在轉發(fā)一個問題信息時，都要將 前一個發(fā)布該問題信息的用戶標識填充到問題信息的〈via〉元素中。為了避 免問題被過度轉發(fā)，則可以設置一個轉發(fā)次數上限，具體的可以根據〈via5 元素的數量進行限制，如當客戶端或服務器發(fā)現(xiàn)問題信息中的〈via〉元素達 到了上限，如達到了3個，則不再對該問題信息進行轉發(fā)傳播。
如果用戶C的好友D要提供答案，則其客戶端將答案信息包含在SIP MESSAGE請求中，并且還可以包括從呈現(xiàn)信息中獲取的問題的傳播路徑信 息。該MESSAGE消息可以只發(fā)送給初始提出問題的用戶A，也可以同時發(fā) 送給轉發(fā)過該問題的所有用戶。舉例如下
MESSAGE sip:usera@example.com SIP/2.0
From: sip:userd@example.com
Content-Type: application/answer+xml
<answcr〉
〈description〉百草園明軒茶社，電話28780808</description〉 <via qid="q3t82z">sip:usera@example.com</via> <via qid="pl4ts9">sip:userb@example.com</via〉 <via qid="p41rlt">sip:userc@example.com</via></answer>
則用戶A (或B、 C等)的客戶端收到該消息后，除了根據〈via〉元素中 自己的用戶標識對應的問題標識顯示對應的問題信息和該答案消息中 〈description〉元素中的答案信息外，還可以顯示用戶D是依據什么人際關系 路徑獲得該問題的，如用戶A的客戶端可以顯示路徑
sip:usera@example.com - > sip:userb@example.com —〉
sip:userc@example.com - 〉 sip:userd@example.com
其中路徑最后 一 跳的用戶標識"sip:userd@example.com ，，是從 MESSAGE請求的From頭字段中獲得的。
第三實施例中，考慮到用戶提出的問題可能會比較復雜，如詢問一個圖 片或視頻的信息，或者咨詢對一篇文章的評論，顯然圖片、視頻和大篇幅的 文章都不適合直接放在呈現(xiàn)信息中。本實施例中則通過僅在呈現(xiàn)信息中放置 問題的標題和相關內容的超鏈接地址URL (統(tǒng)一資源定位符)來實現(xiàn)復雜 問題的發(fā)布。具體的，當用戶客戶端發(fā)布一個問題呈現(xiàn)信息時，輸入問題標 題和相關內容(如圖片、視頻等文件)，其中相關內容部分被客戶端上載到 服務器側，服務器存儲后并分配一個URL地址返回給客戶端，客戶端將問 題標題和該URL地址作為問題呈現(xiàn)信息發(fā)布。內容舉例如下
〈question id=" 123456"〉
〈title〉這張照片是哪個地方的風景々title〉 <url>http:〃www.example.com/usera/qwe213yui456.htm</url>
</question〉
其中標題元素〈title〉中包含問題的標題信息，而地址元素<111*1>中包含相 應內容的URL地址信息。觀察者客戶端則可以通過該問題信息中的超鏈接 URL地址獲取完整的問題內容。另外在問題的轉發(fā)傳播中，該URL信息也同樣被復制轉發(fā)。
另一方面，答案信息也可能會比較復雜，而不是簡單短小的文字信息。 這時也可以同樣進行類似處理，即客戶端先將答案信息上載到服務器，然后
服務器返回一個答案內容的鏈接URL地址，客戶端再將該URL地址發(fā)送給 提出問題的用戶即可。
在以上幾個實施例中，對于問題呈現(xiàn)信息的訪問權限，由于用戶目的是 希望獲得答案，因此可以不必限制對問題呈現(xiàn)信息的訂閱。即使不是好友， 或者在隱身狀態(tài)等都提供用戶的問題呈現(xiàn)信息。另外回答該問題的即時消息 在任何情況下也都不必阻止，如具體的即時消息服務器在檢測到一個即時消 息中包含的是一個答案類型的消息體時，即使用戶設置了阻止非好友即陌生 人的即時消息，并且該即時消息是來自一個陌生人的，則對于該即時消息服 務器也可以不進行阻止。
在陌生人在搜索用戶時也可以看到用戶的問題信息，通過回復用戶的問 題結識新朋友。如在增加即時消息好友時， 一般要進行驗證，這時可以獲取 用戶A的問題信息，B在請求加A為好友時，在B的客戶端顯示A的問題 信息，并提示B輸入問題的答案，問題信息和答案隨加好友的請求一起發(fā)送 給用戶A的客戶端。用戶A的客戶端在顯示該請求時，可以同時顯示問題 及答案信息。隨后用戶A可以根據答案情況確定是否允許該請求。
有一些問題可能更適合限定在某個群組或某些具體用戶中發(fā)布，如"誰 知道同事李四的手機號碼"，則可以只在同事群組中發(fā)布。具體的，客戶端 選中一個群組或一些好友后，然后發(fā)布問題信息，則該問題呈現(xiàn)信息的訂閱 權限只限定在所選定的群組和好友。其對應的呈現(xiàn)授權規(guī)則(Presence Authorization Rules )內容舉例如下
<ruleset><rule id="a"> <conditions>
<identity〉<many domain="huawei.com"〉</identity> </conditions><actions><sub-handlhig>allow</sub-handliiig〉</actioiis> <transformations>
<provide-question-list>
<question-id>q3t82z</question-id> </provide-question-list > </transformations> </rule></mleset>
其中該授權規(guī)則集(ruleset)中包含一項規(guī)則(rule )，在條件(conditions ) 元素中指定了授j又用戶的歸屬域(domain )如"huawei.com",而在動作 (actions)元素中指定授權動作為"允許"(allow),而在變換元素 (transformations)中指定所允許提供的問題的標識如"q3t82z"。該呈現(xiàn)授 權規(guī)則可以由發(fā)布問題呈現(xiàn)信息的客戶端通過XCAP (Extensible Markup Language Configuration Access Protocol)十辦i義進4亍i殳置。當 一個7見察者i丁閱 該用戶的呈現(xiàn)信息時，呈現(xiàn)服務器根據授權規(guī)則檢測觀察者是否滿足條件， 即歸屬域是否為"huawei.com"，如果是才向其提供對應的問題信息，包含在 通知消息中發(fā)送，否則不提供。
如果好友等其他用戶也對答案也感興趣，則其客戶端可以向初始提出問 題的用戶發(fā)送一條即時消息，指示自己關注該問題，如果有答案則希望也提 供給自己。該指示關注問題的即時消息部分內容舉例如下
MESSAGE sip:usera@example.com SIP/2.0
Content-Type: application/focus-question+xml
<focus qid="q3t82z"/>
該消息體中包含一個〈focus〉元素，其屬性值為所關注的問題標識。在
經過原提問用戶的確認同意后，在原提問用戶的客戶端生成關注問題記錄，
當原提問用戶獲得答案時，則將答案信息通過MESSAGE方法發(fā)送給關注該問題的其他用戶。
客戶端在收到答案信息后，也可以將答案信息作為呈現(xiàn)信息進行發(fā)布，
同時包含問題和答案的呈現(xiàn)信息舉例如下
<question id="p9tr3r2">
〈description〉從龍崗到蛇口坐什么公交車</description〉 <answer id="l" by="sip:userc@example.com">338路〈/answer〉
</question〉
其中答案元素〈answei^可以有一個或多個，每個答案元素有標識屬性如 "id",該標識在父元素〈question〉內部是唯一的，另外回答者屬性〈by〉包 含提供答案者的用戶標識。
第四實施例中，對于答案內容較多，或希望多次交互提供答案時，也可 以采用MSRP ( Message Session Relay Protocol)協(xié)議，具體協(xié)議可參見IETF 的標準RFC4975?；赟IP MESSAGE的即時消息可以稱為尋呼模式(page mode)的即時消息，類似于短消息。而基于MSRP的即時消息則可以稱為 會話模式的即時消息。具體的，欲提供答案的客戶端采用SIP INVITE方法 向提出問題者請求建立MSRP會話，其中在INVITE請求的SDP ( Session Description Protocol)消息體中的MSRP媒體對應的屬性中包含問題標識。 INVITE請求的部分內容舉例如下
INVITE sip:usera@example.com
m=message 7777 TCP/MSRP * a=accept-types: text/plain
a=path:msrp:〃userbpc.example.com:7777/iau39soe2843z;tcp a=question:p9tr3r2
其中屬性問題"question"的值為問題標識如"p9tr3r2"。初始提出問 題的用戶客戶端收到該SIP INVITE請求后，從SDP消息體中獲取到問題標識，并將問題標識對應的呈現(xiàn)信息中的問題信息顯示給該用戶，用戶同意進
行通信則客戶端返回200 OK響應給INVITE的發(fā)起者。在MSRP會話建立 之后，提供答案的客戶端可以用MSRP的SEND命令發(fā)送消息內容文本， 對于大的文件內容，可以利用其分塊傳送機制分多次發(fā)送。另外雙方可以利 用建立的MSRP會話進行交互，所有的交互消息記錄都與對應的問題標識相 關聯(lián)，即可以將交互消息記錄作為該問題的答案信息。
如果一個與問題相關聯(lián)的MSRP會話進行中，有另外一方也向提出問題 者發(fā)起一個相同問題的建立MSRP的INVITE請求，即SDP中問題"question" 中的問題標識相同，則提出問題者客戶端將新的一方也加入到已有的MSRP 會話中，可以在200 OK響應消息中的SDP中使用與已有的MSRP會話的路 徑和端口參凄t即可。
另外在SDP媒體屬性中的問題信息也可以包括問題，如
a-question:p9tr3r2;誰能借我1萬元？
如果提供答案的用戶希望通過語音或視頻的方式提供答案，如問題是 "誰能演示一下國標舞？"，則提供答案的用戶客戶端發(fā)起一個多媒體會話 請求，如用SIP INVITE發(fā)起一個RTP語音和4見頻的會話請求，與上述的 MSRP會話類似，在SDP的媒體屬性"a"中設置問題指示即可。通過識別 該問題指示，接收該請求的客戶端可以對該與問題相關的多媒體會話自動進 行錄制。多媒體會話也可以看作是一種會話模式的即時消息。
第五實施例中通過采用XCAP協(xié)議來發(fā)布問題呈現(xiàn)信息。因為用SIP PUBLISH發(fā)布的呈現(xiàn)信息一般都有有效期，客戶端必須進行不斷的刷新才 可以，如果客戶端離線時，SIP PUBLISH所發(fā)布的呈現(xiàn)信息就會失效，呈現(xiàn) 服務器會將失效的呈現(xiàn)信息清除。而問題信息在用戶離線時也可以向其他用 戶提供，這樣可以增加獲得答案機會，因為其他用戶可能未必會和提出問題 的用戶同時在線。因此本實施例中，通過XCAP協(xié)議發(fā)布相對靜態(tài)的問題呈 現(xiàn)信息，具體的發(fā)布命令即HTTP PUT內容舉例如下PUT /pidf-manipulation/users/sip:someone@example.com/index/
—/presence/person%5b@id='x8eg92n'%5d/question HTTP/1.1
If-Match: "xyz"
Host: xcap.example.com
Content-Type: application/xcap-el+xml
〈question〉深圳的房價有沒有開始跌?。?</question>
本實施例中假設呈現(xiàn)信息<person>中包含一 個〈question〉元素，該元素 包含問題描述文本。該PUT命令請求行中的XCAP地址包含用戶呈現(xiàn)信息 的問題元素的節(jié)點路徑。該PUT消息體中包含問題元素〈question〉的具體內 容。通過XCAP PUT所發(fā)布的問題呈現(xiàn)信息，由于沒有有效期的限制，呈 現(xiàn)服務器即使在用戶客戶端沒有刷新甚至離線時，仍舊將該問題呈現(xiàn)信息作 為有效的呈現(xiàn)信息。
第六實施例中基于XMPP ( The Extensible Messaging and Presence Protocol)協(xié)議實現(xiàn)問答業(yè)務。首先用戶發(fā)布問題信息，其XML格式的發(fā)布
消息部分內容舉例如下 <iq type='set'
from='usera@example.com/ca486eba-0f9a-lldc-8835-000bcd821bfb' id='publishl'> <pubsub xmlns='http:〃jabber.org/protocol/pubsub'〉 〈publish node='http:〃j abber.org/protocol/question'〉 <item〉
<question xmlns='http:〃jabber.org/protocol/question' xml:lang='en'> Where is Tom </question></item> </publish〉 </pubsub> </iq〉
其中在〈publish〉元素的節(jié)點node屬性中指示發(fā)布的是問題(question) 節(jié)點。在項目〈item〉元素中用問題〈question〉子元素包含具體的問題，另外 該問題元素還可以包含語言屬性，指示具體的語言種類如英語或中文等。項 目〈item〉元素中可以有多個問題〈question〉子元素，但每個問題〈question〉 子元素的語言屬性必須不同，即 一個項目〈item〉元素中所有問題〈question〉 子元素應當是一個問題的不同語言的實例。這樣一個用戶 一個時刻最多只有 一個問題，在有答案消息返回時可以與問題簡單的進行匹配。如果收到答案 消息時，用戶當前的呈現(xiàn)信息中沒有問題信息，則匹配最近所發(fā)布的呈現(xiàn)信 息中的問題。
然后該問題信息通過XMPP協(xié)議的〈messag〉消息被傳送給所有的訂閱 者。消息內容舉例如下
from='usera@example.com' to='userb@example.com'〉 <event xmlns='http:〃jabber.org/protocol/pubsub#event'> <items node='http:〃jabber.org/protocol/question'〉 <item id='b5ac48d0-0f9c-lldc-8754-001143d5d5db'〉 <question xmlns='http:〃jabber.org/protocol/question' xml:lang='en'> Where is Tom </question> </item> </items></event> </message〉
其他用戶客戶端返回答案信息時，也可以用XMPP協(xié)議的〈message〉消 息發(fā)送。舉例如下
<message to='usera@example.com'
from='userb@example.com' xml:lang='en，> <body〉Answer: Where is Tom </body〉 <answer xmlns='http:〃j abber.org/protocol/answer'>
Tom is in the gym. </answer> </message〉
其中為了避免答案和當時的問題可能出現(xiàn)不匹配的問題，提供答案的客 戶端可以在<1 0(1乂>元素中包含對應的問題，最好在問題描述之前增加一個前 綴如"Answer:"，以此來指示該消息是對該問題的 一個答案。并在答案 〈answer〉元素中包含答案文本。這樣即使該答案與用戶當前的問題不匹配， 用戶仍可從〈body〉元素中的內容看到該答案消息對應的問題。
本領域普通技術人員可以理解實現(xiàn)上述實施例方法中的全部或部分步 驟是可以通過程序來指令相關的硬件完成，所述的程序可以存儲于一種計算 機可讀存儲介質中，該程序在執(zhí)行時，當位于問題提出方時包括如下步驟
將問題信息包含在呈現(xiàn)信息中進行發(fā)布；
將所接收到的答案和對應的問題一起顯示出來。
當位于答案提供方時包括如下步驟
獲得包含問題信息的呈現(xiàn)信息；
將答案信息通過即時消息發(fā)送。
上述提到的存儲介質可以是只讀存儲器，磁盤或光盤等。如圖2所示，提供問答業(yè)務的即時通信客戶端可以包括問題呈現(xiàn)信息 設置模塊，用于接收問題的輸入，并將問題信息包含在呈現(xiàn)信息中進行發(fā)布； 答案即時消息發(fā)送模塊，用于從呈現(xiàn)信息中提取問題信息，并接收答案的輸 入，然后將答案信息通過即時消息發(fā)送；問題和答案顯示模塊，用于將即時 消息中的答案以及對應的問題顯示出來。為將模塊間的關系描述清楚，圖2 中有兩個即時通信客戶端A和B，組成結構是一樣的，兩個客戶端之間經過 通信網絡相互連接進行通信，呈現(xiàn)服務器等都位于通信網絡中。即時通信客 戶端A的問題呈現(xiàn)信息設置模塊所發(fā)布的呈現(xiàn)信息經通信網絡傳送到即時 通信客戶端B,由客戶端B的答案即時消息發(fā)送模塊從呈現(xiàn)信息中提取問題 信息。即時通信客戶端A的問題和答案顯示模塊接收來自客戶端B的答案 即時消息發(fā)送模塊所發(fā)送的答案。
即時通信客戶端還可以包括問題呈現(xiàn)信息轉發(fā)模塊，用于從所獲取的呈 現(xiàn)信息中提取問題信息，并將提取的問題信息包含在自己的呈現(xiàn)信息中進行 發(fā)布。還可以包括靜態(tài)問題呈現(xiàn)信息設置模塊，用于接收問題的輸入，并將 問題信息通過XCAP協(xié)議發(fā)布到服務器。還可以包括問答會話模塊，用于建 立并進行與問題相關聯(lián)的會話。如通過SIP INVITE發(fā)起MSRP或RTP會話， 上述實施例已有詳細描述，此處不再贅述。雙方的即時通信客戶端通過問答 會話模塊進行與問題相關聯(lián)的會話，該模塊還可以將會話過程記錄下來，會 話記錄作為與對應問題相關聯(lián)的答案。
即時通信服務器可以包括呈現(xiàn)信息處理模塊，用于接收包含問題信息 的呈現(xiàn)信息，并將其進行分發(fā)；即時消息處理模塊，用于接收包含答案信息 的即時消息，并將其進行轉發(fā)。這兩個模塊物理上也可以位于不同的服務器 中，如分別位于呈現(xiàn)服務器和即時消息服務器，以提高處理能力。
發(fā)明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權利要 求及其等同技術的范圍之內，則本發(fā)明也意圖包含這些改動和變型在內。
權利要求
1、一種實現(xiàn)問答業(yè)務的方法，其特征在于，該方法包括步驟第一客戶端將問題信息包含在呈現(xiàn)信息中進行發(fā)布；第二客戶端獲得包含問題信息的呈現(xiàn)信息；第二客戶端將答案信息通過即時消息發(fā)送給第一客戶端；第一客戶端將所接收到的答案和對應的問題一起顯示出來。
2、 根據權利要求1所述的方法，其特征在于，在第一客戶端將問題信息包 含在呈現(xiàn)信息中進行發(fā)布后，第三客戶端獲得第一客戶端所發(fā)布的包含問題信 息的呈現(xiàn)信息，然后將其中的問題包含在自己的呈現(xiàn)信息中進行發(fā)布；第二客戶端從第三客戶端獲得第一客戶端的問題信息。
3、 根據權利要求2所述的方法，其特征在于，第三客戶端將第一客戶端的 用戶標識、問題標識與問題一起包含在自己的呈現(xiàn)信息中進行發(fā)布；根據所述的用戶標識第二客戶端將答案以及所述的問題標識或問題發(fā)送給 第一客戶端。
4、 根據權利要求3所述的方法，其特征在于，第二客戶端還將問題的轉發(fā) 傳播路徑一起發(fā)送給第 一客戶端。
5、 根據權利要求1所述的方法，其特征在于，在第一客戶端將問題信息包 含在呈現(xiàn)信息中進行發(fā)布后，所述的問題經過了至少兩次的轉發(fā)傳播后由第二 客戶端獲得；第二客戶端將答案信息通過即時消息發(fā)送給第一客戶端或轉發(fā)路徑節(jié)點的 客戶端，同時即時消息中還包括問題的轉發(fā)傳播路徑信息。
6、 根據權利要求5所述的方法，其特征在于，轉發(fā)傳播路徑上的一個節(jié)點 客戶端向第 一客戶端發(fā)送包含關注所述問題指示的即時消息；第一客戶端在獲得答案后，將所述答案發(fā)送給所述節(jié)點客戶端。
7、 根據權利要求1所述的方法，其特征在于，第一客戶端發(fā)布的所述問 題信息中包括問題標識；第二客戶端發(fā)送的即時消息中答案信息包括對應的問題標識； 第 一客戶端根據所接收到的即時消息中答案信息中的問題標識匹配對應的 問題，然后將答案和對應的問題一起顯示出來。
8、 根據權利要求7所述的方法，其特征在于，所述的答案信息包含在即時 消息的內容類型為答案的消息體中；當第 一客戶端檢測到所接收到的即時消息中包含內容類型為答案的消息體 時，從所述即時消息中獲取問題標識，然后根據問題標識從本地的呈現(xiàn)信息中 獲取對應的問題。
9、 才艮據權利要求1所述的方法，其特征在于，第二客戶端將答案信息通過 即時消息發(fā)送給第 一客戶端時，還將從呈現(xiàn)信息中獲取的對應的問題信息也和 答案信息一起通過即時消息發(fā)送給第 一客戶端。
10、 根據權利要求1所述的方法，其特征在于，第一客戶端在接收到答案 后，將答案信息也包含在呈現(xiàn)信息中進行發(fā)布。
11、 根據權利要求1所述的方法，其特征在于，問題或答案被提交到服務 器，僅將服務器返回的地址包含在所述的答案信息或問題信息中。
12、 根據權利要求1所述的方法，其特征在于，第一客戶端將問題信息作 為靜態(tài)的呈現(xiàn)信息進行發(fā)布。
13、 根據權利要求1所述的方法，其特征在于，第二客戶端將答案信息通 過會話模式的即時消息發(fā)送給第 一客戶端。
14、 根據權利要求13所述的方法，其特征在于，第二客戶端將問題信息包 含在會話初始協(xié)議請求的SDP內容的屬性中。
15、 根據權利要求1所述的方法，其特征在于，在第一客戶端將問題信息 包含在呈現(xiàn)信息中進行發(fā)布之后，第一客戶端或呈現(xiàn)服務器將問題信息發(fā)布到 問答網站或博客網站。
16、 根據權利要求1所述的方法，其特征在于，第一客戶端發(fā)布的所述問 題信息中包括的問題數量最多為 一個；第 一客戶端檢測到所接收到的即時消息中內容類型為答案類型時，則將所 述即時消息中的答案和第 一客戶端最近所發(fā)布的呈現(xiàn)信息中的問題一起顯示出來。
17、 根據權利要求1所述的方法，其特征在于，第一客戶端所發(fā)布的呈現(xiàn) 信息中的問題信息還包括有效期或緊急標志。
18、 一種即時通信客戶端，其特征在于，所述客戶端包括 問題呈現(xiàn)信息設置模塊，用于接收問題的輸入，并將問題信息包含在呈現(xiàn)信息中進行發(fā)布；答案即時消息發(fā)送模塊，用于從呈現(xiàn)信息中提取問題信息，并接收答案的 輸入，然后將答案信息通過即時消息發(fā)送；問題和答案顯示模塊，用于將即時消息中的答案以及對應的問題顯示出來。
19、 根據權利要求18所述的客戶端，其特征在于，所述客戶端還包括 問題呈現(xiàn)信息轉發(fā)模塊，用于從所獲取的呈現(xiàn)信息中提取問題信息，并將提取的問題信息包含在自己的呈現(xiàn)信息中進行發(fā)布。
20、 根據權利要求18所述的客戶端，其特征在于，所述客戶端還包括 靜態(tài)問題呈現(xiàn)信息設置模塊，用于接收問題的輸入，并將問題信息通過XCAP協(xié)議發(fā)布到服務器。
21、 根據權利要求18所述的客戶端，其特征在于，所述客戶端還包括 問答會話模塊，用于建立并進行與問題相關聯(lián)的會話。
22、 一種即時通信服務器，其特征在于，所述服務器包括 呈現(xiàn)信息處理模塊，用于接收包含問題信息的呈現(xiàn)信息，并將其進行分發(fā); 即時消息處理模塊，用于接收包含答案信息的即時消息，并將其進行轉發(fā)。
23、 一種實現(xiàn)問答業(yè)務的方法，其特征在于，該方法包括步驟 接收包含問題信息的呈現(xiàn)信息并進行分發(fā)；接收包含答案信息的即時消息并進行轉發(fā)。
全文摘要
本發(fā)明公開了一種實現(xiàn)問答業(yè)務的方法，包括步驟第一客戶端將問題信息包含在呈現(xiàn)信息中進行發(fā)布；第二客戶端獲得包含問題信息的呈現(xiàn)信息；第二客戶端將答案信息通過即時消息發(fā)送給第一客戶端；第一客戶端將所接收到的答案和對應的問題一起顯示出來。本發(fā)明充分使用了即時通信系統(tǒng)中的人際關系網絡信息，結合即時通信中的呈現(xiàn)業(yè)務和即時消息實現(xiàn)了問答業(yè)務，使用戶可以方便的基于廣泛使用的即時通信系統(tǒng)提出問題并獲得答案。
文檔編號H04L12/58GK101431479SQ20071012444
公開日2009年5月13日 申請日期2007年11月8日 優(yōu)先權日2007年11月8日
發(fā)明者謙 孫, 揚 招 申請人:華為技術有限公司