一種即時通信客戶端及服務(wù)端的制作方法
【專利摘要】本發(fā)明提供一種即時通信客戶端以及服務(wù)端，其中群主客戶端在該群消息界面選中群呼選項時，客戶端向服務(wù)端發(fā)送群呼請求以請求服務(wù)端向其他在線用戶的客戶端發(fā)送呼叫請求，其他客戶端接收到服務(wù)端發(fā)送的呼叫請求時，控制該終端輸出呼叫提示且該呼叫提示的極限持續(xù)時長為第一指定時長。在相反的方向上，多個用戶向服務(wù)端發(fā)送單呼請求時，服務(wù)端發(fā)現(xiàn)預(yù)定條件滿足時，向群主的客戶端發(fā)送呼叫請求。本發(fā)明根據(jù)群內(nèi)即時通信的需要引入呼叫提示和普通消息提示兩種輸出機制，并且在上下行方向上采用不同呼叫請求觸發(fā)機制，既能夠合理使用呼叫請求機制來服務(wù)群內(nèi)通信需要，又能夠合理控制呼叫請求的使用。
【專利說明】一種即時通信客戶端及服務(wù)端
【技術(shù)領(lǐng)域】
[0001 ] 本發(fā)明涉及即時通信領(lǐng)域，尤其涉及一種即時通信客戶端及服務(wù)器。
【背景技術(shù)】
[0002]在互聯(lián)網(wǎng)技術(shù)進入普通民眾生活之后，即時通信技術(shù)給民眾帶來了各種工作與生活的便利。從早期的ICQ以及OICQ (今日廣泛使用的QQ)到如今更新一代的微信以及來往等，即時通信技術(shù)正在不斷地向著更加便利用戶的方向演進。
[0003]目前很多即時通信客戶端都開始支持群聊技術(shù)，群聊技術(shù)可以允許一些對共同話題關(guān)注的用戶聚集在一起進行信息的交互與分享。在一個用戶群內(nèi)，群內(nèi)用戶通常區(qū)分為多種角色，比如管理員(也稱為“群主”)與普通用戶，當然可能還有副群主這樣的角色。目前，在群聊應(yīng)用中，用戶的需求與點對點的通信需求有著較大的差異。群聊應(yīng)用特點是共同話題與事件往往需要三個或者更多的用戶一起參與，有時候需要多個不同角色的用戶一起參與，缺少特定角色的用戶或者缺少足夠數(shù)量的用戶，往往會導(dǎo)致特定應(yīng)用下的用戶體驗下降。因此，用戶群中用戶非常關(guān)注召集話題參與者的功能。目前這種功能的實現(xiàn)依賴于傳統(tǒng)的方式，比如發(fā)送即時消息，甚至打電話等等來通知特定用戶登錄并參與進來。
[0004]發(fā)送即時消息來實現(xiàn)參與用戶召集其提示效果較差，用戶可能并不關(guān)注即時消息的提示。而使用電話方式則更加不方便，召集者可能需要撥打多個電話，甚為不便。以一個簡單的示例來說，假設(shè)一個同學關(guān)系的用戶群中，多個用戶希望就聚餐事宜通知大家相應(yīng)的時間與地點。通知者往往是到群里發(fā)個消息，然后看看誰回復(fù)了，沒有回復(fù)的人，通知者通常再撥打電話確認其是否收到該消息。由此可見，現(xiàn)有技術(shù)在群體即時通信的實現(xiàn)上仍然存在用戶使用不便利等缺點。

【發(fā)明內(nèi)容】

[0005]有鑒于此，本發(fā)明提供一種即時通信客戶端，應(yīng)用于便攜式用戶終端上，與服務(wù)端配合使用，該客戶端包括:會話管理單元、呼叫發(fā)起單元以及呼叫處理單元，其中:
[0006]會話管理單元，用于為用戶開啟群消息界面，針對下行核心用戶在該群消息界面上提供群呼選項，針對非核心用戶在該群消息界面上提供單呼選項；
[0007]呼叫發(fā)起單元，用于在用戶選中群呼選項時，向服務(wù)端發(fā)送針對群內(nèi)所有其他用戶的群呼請求，該群呼請求中攜帶有用戶所屬用戶群標識以及群呼標識；當用戶選中單呼選項，向所述服務(wù)端發(fā)送針對被叫用戶的單呼請求；
[0008]呼叫處理單元，用于在接收到服務(wù)器發(fā)送的呼叫請求時按照預(yù)定的前臺占用優(yōu)先級向操作系統(tǒng)請求前臺占用；并在請求前臺占用成功的情況下，在用戶終端屏幕上輸出至少部分覆蓋當前用戶界面的呼叫響應(yīng)界面，并在呼叫提示被允許的情況下控制該用戶終端輸出一種或多種呼叫提示，其中該呼叫響應(yīng)界面包括接受選項以及拒絕選項。
[0009]本發(fā)明還提供一種即時通信服務(wù)端，應(yīng)用于即時通信服務(wù)提供商的服務(wù)器上，與即時通信用戶使用的客戶端配合使用，該服務(wù)端端包括:群呼處理單元以及單呼處理單元，其中:
[0010]群呼處理單元，用于在接收到下行核心用戶發(fā)送的群呼請求時，獲取該消息中攜帶的用戶群標識，向該用戶群內(nèi)的其他在線用戶發(fā)送呼叫請求；
[0011]單呼處理單元，用于在接收到針對上行核心用戶的單呼請求時，獲取該消息中攜帶的用戶群標識；在該用戶群的單呼請求列表中記錄本次單呼請求，判斷當前單呼請求列表是否滿足預(yù)定條件，若滿足，則向該上行核心用戶發(fā)送呼叫請求，清空該用戶群的單呼請求列表。
[0012]相較于現(xiàn)有技術(shù)，本發(fā)明根據(jù)群內(nèi)即時通信的需要引入呼叫提示和普通即時通信消息提示兩種輸出機制，并且在上下行方向上采用不同呼叫請求觸發(fā)機制，既能夠合理使用呼叫請求機制來服務(wù)群內(nèi)通信需要，又能夠合理控制呼叫請求的使用，避免給用戶帶來糟糕的體驗。
【專利附圖】

【附圖說明】
[0013]圖1是本發(fā)明一種實施方式中客戶端與服務(wù)端的邏輯結(jié)構(gòu)以及基本硬件環(huán)境示意圖。
[0014]圖2是本發(fā)明一種實施方式中的處理流程圖。
[0015]圖3是本發(fā)明一種實施方式中客戶端一側(cè)的處理流程圖。
[0016]圖4是本發(fā)明一種實施方式中服務(wù)端一側(cè)的第一部分處理流程圖。
[0017]圖5是本發(fā)明一種實施方式中服務(wù)端一側(cè)的第二部分處理流程圖。
【具體實施方式】
[0018]針對現(xiàn)有技術(shù)的問題，在優(yōu)選的方式中，本發(fā)明提供一種新的即時通信客戶端以及與之配合的服務(wù)端。在以下實施方式中，所述客戶端以及服務(wù)端是一種計算機軟件實現(xiàn)的虛擬裝置，分別運行于便攜式用戶終端(比如智能手機)以及即時通信服務(wù)提供商的服務(wù)器上。當然本發(fā)明并不排除其他諸如邏輯器件或者硬件等實現(xiàn)方式。在此僅以最為流行的軟件實現(xiàn)為例進行示例性說明，在硬件環(huán)境上，用戶終端與服務(wù)器有較大的差異，但是為了描述方便起見，圖1中只是示例性地給出了客戶端與服務(wù)端運行所需的基本通用的硬件架構(gòu)。
[0019]請參考圖1，從邏輯功能層面上講，該客戶端包括會話管理單元、呼叫發(fā)起單元以及呼叫處理單元；而該服務(wù)端包括群呼處理單元以及單呼處理單元。在客戶端一側(cè)，從用戶的角色做區(qū)分，用戶可以分為兩大角色。第一種是核心用戶，在本發(fā)明中，核心用戶細分為下行核心用戶以及上行核心用戶，其中下行核心用戶擁有發(fā)送群呼請求權(quán)限，該群呼請求用于請求或者說觸發(fā)服務(wù)端向群內(nèi)所有其他在線用戶發(fā)送呼叫請求。在實際使用過程中，下行核心用戶一般為群主或副群主，當然也可以是群主指定的擁有該權(quán)限的用戶；上行核心用戶則為可以被服務(wù)端單獨發(fā)送呼叫請求的用戶。第二種是擁有單呼請求權(quán)限的非核心用戶，一般情況下，群內(nèi)所有用戶都擁有該權(quán)限。在開發(fā)過程中，客戶端的實現(xiàn)是可以統(tǒng)一的，依據(jù)權(quán)限不同的用戶呈現(xiàn)不同的群消息界面給用戶。以下為了描述方便，僅以群主同時是上行核心用戶和下行核心用戶為例進行說明，當然事實上，上行核心用戶和下行核心用戶可以是不同的用戶。[0020]用戶在智能手機上安裝好客戶端之后，其可以進行注冊，成為注冊用戶后上線。在用戶登錄過程中，客戶端獲取用戶輸入的身份認證信息(比如用戶名與密碼)發(fā)送給服務(wù)端，服務(wù)端對該身份認證信息進行驗證，若通過則允許用戶上線，并返回該用戶的群屬性信息。用戶首次登陸時，其可能沒有加入任何用戶群，在登錄后可以通過在用戶界面上搜索，創(chuàng)建或者以其他方式加入某個用戶群中，服務(wù)端記錄該用戶的群屬性信息，群屬性信息一般包括該用戶所屬用戶群ID以及在各個用戶群中的角色等。這部分的處理與實現(xiàn)可以參考現(xiàn)有技術(shù)，本發(fā)明在此不再一一詳述。
[0021]請參考圖2以及圖3，在登錄之后，用戶開啟群消息界面，此時會話管理單元根據(jù)用戶權(quán)限來確定該用戶的群消息界面。假設(shè)當前用戶在其所屬的用戶群中為群主，則會話管理單元根據(jù)用戶的開啟指令，為用戶開啟群消息界面，并在該操作界面上提供群呼選項，比如圖2中的“發(fā)送群呼”這一觸摸按鈕就是所述群呼選項；當然也可以為該用戶提供單呼選項；對于普通群用戶，則可以僅提供單呼選項。若用戶在該操作界面上選中該群呼選項，比如用戶點擊該觸摸按鈕，則呼叫發(fā)起單元向服務(wù)端發(fā)送群呼請求，該消息中攜帶有群ID以及群呼類型標記，比如使用“0102”作為群呼類型標記，表征該消息為群呼類型的請求。在優(yōu)選的方式中，呼叫發(fā)起單元在群消息界面上提供附加輸入欄，以允許用戶通過各種方式輸入附加數(shù)據(jù)，比如文本類數(shù)據(jù)以及多媒體類地址數(shù)據(jù)中的一種或者多種，其中多媒體數(shù)據(jù)主要包括圖片、音頻以及視頻，甚至可以是其他類型的文件。
[0022]用戶輸入附加數(shù)據(jù)的方式多種多樣，一種方式是在文本輸入欄中輸入文本類數(shù)據(jù)，另一種方式是附加多媒體類地址數(shù)據(jù)。針對文本類的附加數(shù)據(jù)，該類附加數(shù)據(jù)可以攜帶在群呼請求中發(fā)送給服務(wù)端。在向上傳服務(wù)端上傳該多媒體文件并獲取該上傳服務(wù)端返回的多媒體類地址數(shù)據(jù)，用戶通過附加輸入欄附加多媒體文件時，呼叫發(fā)起單元則可先向上傳服務(wù)器上傳用戶選擇的多媒體文件(比如一個視頻文件)，并獲得服務(wù)器返回的多媒體地址數(shù)據(jù)，該地址數(shù)據(jù)通常是一個URL。呼叫發(fā)起單元將該多媒體類地址數(shù)據(jù)攜帶在群呼請求中發(fā)送給服務(wù)端。
[0023]請繼續(xù)參考圖2、圖3以及圖4，在圖4中，服務(wù)端收到群內(nèi)通信的消息時，首先判斷該消息是否合法，如果不合法則丟棄該消息。消息不合法的情況有多種，比如消息格式有誤又或者群ID等信息不存在或者錯誤等。若消息合法，則可以先判斷消息類型，對于群呼請求和單呼請求(后文繼續(xù)描述)以外的普通消息，比如群內(nèi)普通消息發(fā)布，按照既有規(guī)則在群內(nèi)轉(zhuǎn)發(fā)給其他在線用戶即可。對于單呼請求，由單呼處理單元處理，對于群呼類型消息，則由群呼處理單元處理，其可根據(jù)該消息中攜帶的用戶群標識向該用戶群內(nèi)其他在線用戶發(fā)送呼叫請求，比如消息類型可以為“0103”。
[0024]如果群呼請求中沒有攜帶附加數(shù)據(jù)，則直接發(fā)送呼叫請求即可。如果群呼請求中攜帶有附加數(shù)據(jù)，則群呼處理單元從該消息中獲取該附加數(shù)據(jù)。在優(yōu)選的方式中，群呼處理單元可以先判斷該數(shù)據(jù)有無文本類的附加數(shù)據(jù)，若該附加數(shù)據(jù)中有文本類的附加數(shù)據(jù)，則將該附加數(shù)據(jù)添加到呼叫請求中發(fā)送給群內(nèi)其他在線用戶，接下來判斷是否還有多媒體類附加數(shù)據(jù)，若該附加數(shù)據(jù)中還有多媒體類地址數(shù)據(jù)，則將該多媒體類地址數(shù)據(jù)攜帶在呼叫請求中發(fā)送給客戶端，并向CDN (內(nèi)容分發(fā)網(wǎng)絡(luò))系統(tǒng)發(fā)送針對該地址對應(yīng)的多媒體數(shù)據(jù)(通常為一個多媒體文件)的同步請求?？紤]到該地址后續(xù)可能被很多用戶同時訪問，若不進行同步，雖然并不影響訪問的可達性，但是若同時訪問的用戶過多可能造成訪問速度下降，從用戶的角度看，則是視頻音頻播放不流暢，圖片下載緩慢等等。此時本發(fā)明有針對性地通知CDN系統(tǒng)該地址對應(yīng)的數(shù)據(jù)進行同步，可以確保用戶能夠以較佳的體驗獲得該多媒體數(shù)據(jù)，提升用戶體驗。值得注意的是，這里的在線用戶是一個廣義的概念，并不要求用戶的客戶端必須在前臺在線運行，該用戶的客戶端在后臺保持與服務(wù)端的連接并處于可喚醒客戶端程序狀態(tài)亦可。
[0025]每個在線用戶的客戶端收到該呼叫請求后，其呼叫處理單元確定該消息類型為呼叫請求，呼叫處理單元此時按照預(yù)定的前臺占用優(yōu)先級向手機操作系統(tǒng)申請前臺占用。一般來說呼叫處理單元所使用的優(yōu)先級是開發(fā)人員預(yù)定的，該優(yōu)先級通常較高，在一種優(yōu)選的方式中，呼叫處理單元按照僅僅低于電話應(yīng)用的優(yōu)先級向系統(tǒng)申請前臺占用，其使用的優(yōu)先級不低于其他應(yīng)用的前臺占用優(yōu)先級。由于此時呼叫處理單元所使用的優(yōu)先級很高，除非用戶正在使用電話應(yīng)用在通話中，否則呼叫處理單元請求前臺占用的申請將被操作系統(tǒng)所允許。對于不支持移動通話通信功能的便攜終端，比如Pad類的便攜終端來說，所述預(yù)定的前臺占用優(yōu)先級可設(shè)定為最高的前臺占用優(yōu)先級。
[0026]在前臺占用成功的情況下，呼叫處理單元在前臺提供一個呼叫響應(yīng)界面供用戶來操作。一般來說，呼叫響應(yīng)界面上提供接受選項和拒絕選項。與此同時，呼叫處理單元還可以通過驅(qū)動控制終端輸出呼叫提示，呼叫提示可以包括響鈴提示以及震動提示等方式。值得注意的是，本發(fā)明的呼叫提示與普通即時通信的消息提示的作用以及持續(xù)時間長度并不相同。從作用上來說，呼叫提示主要是將被叫用戶“拉入” 一個群內(nèi)的實時會話，以便在群內(nèi)進行持續(xù)性的且更接近于面對面效果的會話。從提示的輸出極限時間長度上而言，一般來說普通即時通信消息提示的極限持續(xù)時長通常比較短，比如收到一個用戶留言時，終端的語音提示或者震動提示通?？赡軆H僅只有數(shù)秒鐘。而本發(fā)明在用戶無干預(yù)的情況下呼叫提示的極限持續(xù)時長大于前者的極限持續(xù)時長。比如說，呼叫處理單元收到可以觸發(fā)普通即時通信消息提示的普通群內(nèi)消息(也就是非呼叫提示)時，控制用戶終端進行語音提示或者震動提示，其提示極限持續(xù)時長可能僅僅只有數(shù)秒鐘。呼叫提示的極限持續(xù)時長稱為第一指定時長，其長度為數(shù)分鐘，遠大于前者。在優(yōu)選的方式中，建議開發(fā)人員在1-60分鐘這一區(qū)間內(nèi)，選擇一個時長作為所述第一指定時長。此外，若呼叫請求中攜帶有附加數(shù)據(jù)，則呼叫處理的單元在當前界面上播放該附加數(shù)據(jù)，對于文本類數(shù)據(jù)進行顯示處理，對于多媒體類地址數(shù)據(jù)，則通過消息中的地址通過網(wǎng)絡(luò)獲取對應(yīng)的多媒體數(shù)據(jù)進行播放。
[0027]在優(yōu)選的方式中，根據(jù)呼叫請求輸出呼叫提示時，若會話管理單元捕獲到指定用戶操作進行干預(yù)則通過驅(qū)動控制呼叫提示輸出停止，比如說用戶點擊“Home鍵”或者“電源鍵”或者“音量鍵”或者指定的觸摸按鈕等操作來干預(yù)，這些指定操作可以由開發(fā)者自行定義，只要方便用戶使用即可。在優(yōu)選的方式中，呼叫處理單元在控制提供呼叫提示輸出時還在界面上提供接受選項與拒絕選項。若用戶選中接受選項，則會話管理單元根據(jù)該接受操作執(zhí)行開啟群消息界面處理并通過驅(qū)動控制呼叫提示輸出停止，在前臺為用戶提供群消息界面。
[0028]在群消息界面下，用戶可以自由選擇通信方式。該群消息界面中可以包括語音聊天與視頻聊天選項供用戶選擇，還可以包括其他手動消息輸入欄，所謂手動消息輸入欄可以包括文本輸入欄位，還可以包括圖片、音頻、視頻或其他文件附加欄位(比如說對講機這樣的功能就可以實現(xiàn)非實時的音頻數(shù)據(jù)的傳遞)。與語音或視頻聊天不同的是，在這些交流方式中，信息的傳遞其需要用戶手動介入。由此可見，本發(fā)明通過前臺占用的方式來提示群用戶，使得群用戶非常清晰地知道其有相對重要的群內(nèi)通信需求。這種設(shè)計方式不但融入了電話呼叫的帶有強制性處理要求的好處，又融合了即時通信客戶端豐富多樣的通信手段，避免了電話應(yīng)用在交流手段上的單一性。在優(yōu)選的方式中，處于實時會話狀態(tài)的消息界面的前臺占用優(yōu)先級同樣比較高，在優(yōu)選的方式中該優(yōu)先級與呼叫處理單元所使用的優(yōu)先級一致。這樣一來，該消息界面不再容易因其他應(yīng)用占用前臺而退入后臺。
[0029]由于用戶進入該消息界面是接受呼叫觸發(fā)的，此時會話管理單元返回給服務(wù)端一個用戶狀態(tài)更新通知，通知服務(wù)端自身狀態(tài)從異步會話狀態(tài)變更為實時會話狀態(tài)，而服務(wù)端則將該用戶更新后的用戶狀態(tài)同步給群內(nèi)其他用戶的客戶端，同樣的道理，用戶客戶端的會話管理單元在收到服務(wù)器同步其他用戶的狀態(tài)更新消息時，相應(yīng)將自身群用戶列表中對應(yīng)的用戶狀態(tài)進行更新?？紤]到群消息界面可能因為各種原因離開前臺，比如用戶主動關(guān)閉該群消息界面；再比如說，此時用戶的智能手機接收到一個電話呼叫，由于電話應(yīng)用的前臺占用優(yōu)先級最高，因此電話呼叫會占用前臺導(dǎo)致用戶的群消息界面退入后臺運行。在處于實時會話狀態(tài)用戶的群消息界面離開前臺時，所述會話管理單元通知服務(wù)端自身狀態(tài)從異步會話狀態(tài)變更為實時會話狀態(tài)。而其他客戶端的會話管理單元在根據(jù)服務(wù)端同步過來的用戶狀態(tài)更新通知，相應(yīng)將自身群用戶列表中對應(yīng)的用戶狀態(tài)進行更新。通過狀態(tài)更新的同步機制，用戶群內(nèi)的每個用戶可以知曉哪些用戶是在實時會話狀態(tài)，哪些用戶是異步會話狀態(tài)，哪些用戶是離線狀態(tài)。
[0030]若用戶選中拒絕選項，則會話管理單元根據(jù)該拒絕操作通過驅(qū)動控制呼叫提示輸出停止，并將之前的用戶界面恢復(fù)。當然如果一直不選擇，則呼叫處理單元通過驅(qū)動控制呼叫提示持續(xù)輸出。如前所述，本發(fā)明的呼叫請求所觸發(fā)的呼叫提示持續(xù)時間通常也有一定的限制，在收到呼叫請求時，呼叫處理單元啟動第一定時器，該第一定時器的定時時長就是前述第一指定時長，在第一定時器超時的時候，呼叫處理單元通過驅(qū)動控制呼叫提示輸出停止。在一些靈活的實施方式中，客戶端可能允許用戶指定一種或多種呼叫提示的輸出，此時呼叫提示的輸出將是用戶允許的輸出方式。當然用戶也可能配置為完全不允許任何呼叫提示輸出，比如用戶設(shè)定了靜音且不允許震動輸出，此時呼叫提示將被禁止。當然在一些特殊的場景中，開發(fā)者可能不允許用戶對呼叫提示的輸出進行配置，此時相當于呼叫提示被默認允許了。
[0031]從以上的描述中可以看出，本發(fā)明實現(xiàn)了用戶群中特定權(quán)限的用戶對用戶群中其他所有用戶進行呼叫請求，以及群內(nèi)用戶召喚以及緊急事項通知的目標。用戶若不進行操作干預(yù)，則用戶終端會長時間持續(xù)輸出呼叫提示，提示效果強烈。值得注意的是，由于這樣的群體呼叫請求只能由群主這類有群呼權(quán)限的少數(shù)用戶發(fā)起，群主這類少數(shù)用戶通常在有相對重要的事項需要召集群內(nèi)成員進行交流才會啟動群呼功能，因此本發(fā)明可以在實現(xiàn)有效群體交流的同時，避免允許任意成員之間隨意呼叫請求可能引發(fā)給用戶帶來困擾的問題，因為一個用戶群中很多成員用戶之間并不是熟人關(guān)系。
[0032]舉例而言，假設(shè)一個興趣主題是K歌的QQ群，群主若希望組織所有時間方便的成員在兩個小時后到指定地點進行K歌活動，在傳統(tǒng)方式中，群主只能在群內(nèi)留言實現(xiàn)活動的通知。由于時間比較倉卒，部分用戶可能因為對群發(fā)言進行不提示設(shè)置的原因無法接收到這一重要通知，而部分用戶雖然對群內(nèi)發(fā)言沒有進行不提示設(shè)置，但由于群內(nèi)發(fā)言量可能比較大，稍不留意就可能錯過了這一重要的通知，或者需要不斷地往回查找才能得到確切的消息。使用本發(fā)明之后，群主只需要在客戶端界面上發(fā)送群呼請求，并輸入K歌活動的詳情即可實現(xiàn)召喚群內(nèi)所有用戶參加指定活動的目標。再比如說，假設(shè)群主是公司某個部門的總監(jiān)，而群內(nèi)其他成員是其下屬的項目經(jīng)理。該總監(jiān)可以在其智能手機上使用本發(fā)明的客戶端，通過群呼的方式召集所有項目經(jīng)理，比如通告所有項目經(jīng)理在指定時間指定地點集合開會，或者要求所有項目經(jīng)理在指定時間立刻上報項目進展報告等等。這樣一來該總監(jiān)無需逐個電話通知，而且如果呼叫請求都無法召喚到該項目經(jīng)理，只能說明該項目經(jīng)理沒有將手機隨身攜帶，此時即便打電話也無濟于事。
[0033]在相反的通信方向，本發(fā)明繼續(xù)為用戶提供便利。在用戶群的交流中，除了群主通過群呼的方式來召喚其他用戶之外，事實上還存在著其他用戶召喚群主的需求。在一個公司內(nèi)部的用戶群應(yīng)用中，普通群成員用戶只需要撥打群主電話即可，比如說項目經(jīng)理因緊急事項撥打總監(jiān)的電話即可實現(xiàn)對群主的召喚。但是在社交類的用戶群中，這一點往往是難以實現(xiàn)的。在很多社交類用戶群(比如QQ群)中，各個用戶之間往往并不知曉對方的電話號碼等比較私密的聯(lián)系方式，或者只有極少數(shù)的人知道群主的電話。若當前有緊急事項需要召喚群主，比如說需要群主維持討論秩序避免討論偏離主題，現(xiàn)有技術(shù)只能靠留言之類的方式來實現(xiàn)。留言的方式往往無法實現(xiàn)滿足緊急事項在時間上的緊迫性要求。
[0034]請繼續(xù)參考圖2，假設(shè)此時群內(nèi)在線用戶因某緊急事項需要召喚群主進行處理，而群主當前并沒有參與在線討論，此時群內(nèi)的在線用戶可在自身客戶端的群消息界面中選中“呼叫群主”這一單呼選項，此時客戶端的呼叫發(fā)起單元向服務(wù)端發(fā)送單呼請求。如果用戶在界面上添加了附加數(shù)據(jù)，則將該附加數(shù)據(jù)一并攜帶在單呼請求中發(fā)送給服務(wù)端，對于非核心用戶而言，優(yōu)選的方式中，建議附加輸入欄僅允許輸入文本類數(shù)據(jù)。這種方式的好處在于，如果大量用戶都發(fā)送多媒體數(shù)據(jù)，那么群主有可能在后續(xù)收到大量多媒體數(shù)據(jù)，對群主所使用的終端來說下載和處理數(shù)據(jù)的壓力較大。
[0035]請參考圖5，服務(wù)端一側(cè)收到單呼請求后，單呼處理單元獲得該消息中攜帶的群ID,在該群的單呼請求列表中記錄下本次請求。在優(yōu)選的方式中，單呼處理單元記錄本次單呼請求的接收時間以及發(fā)送者的用戶ID。在記錄之后，單呼處理單元繼續(xù)判斷該群的單呼請求列表是否已經(jīng)滿足預(yù)定條件，如果滿足預(yù)定條件，則向群主發(fā)送呼叫請求。群主的客戶端收到該呼叫請求之后則會根據(jù)呼叫請求持續(xù)輸出呼叫提示，具體過程可以參考圖3流程以及之前的相關(guān)描述。此外，如果單呼請求中有附加數(shù)據(jù)，則將對應(yīng)的附加數(shù)據(jù)匯總之后添加在呼叫請求中。
[0036]上述方式中，單呼處理單元所采用的預(yù)定條件可以有多種變化，預(yù)定條件可以是第二指定時長內(nèi)指定數(shù)量(大于或等于2)的用戶發(fā)送了單呼請求，舉例來說，此時該預(yù)定條件可以是I分鐘內(nèi)收到至少5個用戶發(fā)送的單呼請求。請參考表I的單呼請求列表示例，在服務(wù)端收到用戶E的單呼請求之后，此時群內(nèi)已經(jīng)有5個用戶發(fā)送的單呼請求，但是I分鐘內(nèi)只有4個用戶發(fā)送過，因此不滿足預(yù)定條件，此時再次收到用戶D在19:00:15第二次發(fā)送的單呼請求，條件還是不滿足，因為此時消息數(shù)量雖然是5個，但是發(fā)送者還是4個。在收到用戶F發(fā)送的單呼請求后，上述預(yù)定條件就得到了滿足。
[0037]
【權(quán)利要求】
1.一種即時通信客戶端，應(yīng)用于便攜式用戶終端上，與服務(wù)端配合使用，該客戶端包括:會話管理單元、呼叫發(fā)起單元以及呼叫處理單元，其特征在于: 會話管理單元，用于為用戶開啟群消息界面，針對下行核心用戶在該群消息界面上提供群呼選項，針對非核心用戶在該群消息界面上提供單呼選項； 呼叫發(fā)起單元，用于在用戶選中群呼選項時，向服務(wù)端發(fā)送針對群內(nèi)所有其他用戶的群呼請求，該群呼請求中攜帶有用戶所屬用戶群標識以及群呼標識；當用戶選中單呼選項，向所述服務(wù)端發(fā)送針對被叫用戶的單呼請求； 呼叫處理單元，用于在接收到服務(wù)端發(fā)送的呼叫請求時按照預(yù)定的前臺占用優(yōu)先級向操作系統(tǒng)請求前臺占用；并在請求前臺占用成功的情況下，在用戶終端屏幕上輸出至少部分覆蓋當前用戶界面的呼叫響應(yīng)界面，并在呼叫提示被允許的情況下控制該用戶終端輸出一種或多種呼叫提示，其中該呼叫響應(yīng)界面包括接受選項以及拒絕選項。
2.如權(quán)利要求1所述的客戶端，其特征在于: 所述呼叫發(fā)起單元進一步用于針對下行核心用戶在群消息界面上提供附加輸入欄，并將用戶通過該附加輸入欄輸入的附加數(shù)據(jù)添加在所述群呼請求中； 所述呼叫處理單元進一步用于獲取呼叫請求中的附加數(shù)據(jù)，并在終端屏幕上播放該附加數(shù)據(jù)。
3.如權(quán)利要求2所述的客戶端，其特征在于:所述附加輸入欄包括文本附加輸入欄以及多媒體附加輸入欄，所述附加數(shù)據(jù)包括文本類數(shù)據(jù)以及多媒體類地址數(shù)據(jù)，其中所述呼叫發(fā)起單元進一步用于在用戶通過附加輸入欄附加多媒體文件時，向上傳服務(wù)端上傳該多媒體文件并獲取該上傳服務(wù)端返回的多媒體類地址數(shù)據(jù)； 所述呼叫處理單元進一步用于根據(jù)多媒體類地址數(shù)據(jù)從網(wǎng)絡(luò)上獲取多媒體數(shù)據(jù)進行播放。`
4.如權(quán)利要求1所述的客戶端，其特征在于:所述呼叫發(fā)起單元進一步用于針對非核心用戶在群消息界面上提供文本附加輸入欄，并將用戶通過文本附加輸入欄輸入的文本類附加數(shù)據(jù)添加在所述單呼請求中； 所述呼叫處理單元進一步用于獲取呼叫請求中的附加數(shù)據(jù)，并在終端屏幕上播放該附加數(shù)據(jù)。
5.如權(quán)利要求1所述的客戶端，其特征在于: 所述會話管理單元進一步用于在接收到用戶選中接受選項操作時，停止呼叫提示輸出，并在該用戶的群消息界面未開啟的情況下，為該用戶開啟群消息界面；在接收到用戶選中拒絕選項操作時，停止呼叫提示輸出并將之前的用戶界面恢復(fù)。
6.如權(quán)利要求1所述的客戶端，其特征在于:所述呼叫處理單元進一步用于在接收到呼叫請求時啟動第一定時器，其中該第一定時器的定時時長為所述第一指定時長，并在該第一定時器超時時停止呼叫提不輸出。
7.如權(quán)利要求5所述的客戶端，其特征在于:所述群消息界面至少包括手動消息輸入欄。
8.如權(quán)利要求1所述的客戶端，其特征在于:所述會話管理單元進一步用于: 在接收到用戶選中接受選項操作時，通知服務(wù)端自身狀態(tài)從異步會話狀態(tài)變更為實時會話狀態(tài)；在群消息界面離開前臺時，通知服務(wù)端自身狀態(tài)從實時會話狀態(tài)變更為異步會話狀態(tài)； 在接收到服務(wù)同步的用戶狀態(tài)更新通知時，將群內(nèi)用戶列表中對應(yīng)用戶的狀態(tài)進行相應(yīng)的更新。
9.一種即時通信服務(wù)端，應(yīng)用于即時通信服務(wù)提供商的服務(wù)器上，與即時通信用戶使用的客戶端配合使用，該服務(wù)端包括:群呼處理單元以及單呼處理單元，其特征在于: 群呼處理單元，用于在接收到下行核心用戶發(fā)送的群呼請求時，獲取該消息中攜帶的用戶群標識，向該用戶群內(nèi)的其他在線用戶發(fā)送呼叫請求； 單呼處理單元，用于在接收到針對上行核心用戶的單呼請求時，獲取該消息中攜帶的用戶群標識；在該用戶群的單呼請求列表中記錄本次單呼請求，判斷當前單呼請求列表是否滿足預(yù)定條件，若滿足，則向該上行核心用戶發(fā)送呼叫請求，清空該用戶群的單呼請求列表。
10.如權(quán)利要求9所述的服務(wù)端，其特征在于:所述群呼處理單元進一步用于獲取群呼請求中攜帶的附加數(shù)據(jù)，并將該附加數(shù)據(jù)添加到所述呼叫請求中。
11.如權(quán)利要求10所述的服務(wù)端，其特征在于:當所述附加數(shù)據(jù)為多媒體類地址數(shù)據(jù)時，所述群呼處理單元進一步用于向內(nèi)容分發(fā)網(wǎng)絡(luò)⑶N系統(tǒng)發(fā)送針對該地址對應(yīng)的多媒體數(shù)據(jù)的同步請求。
12.如權(quán)利要求9所述的服務(wù)端，其特征在于:所述記錄本次單呼請求具體包括記錄本次單呼請求的接收時間以及發(fā)送者的用戶ID，所述預(yù)定條件具體為:第二指定時長內(nèi)接收到N個用戶發(fā)送的單呼請求，其中N為大于或等于2的自然數(shù)；所述單呼處理單元進一步用于在接收到單呼請求時啟動第二定時器，并在該第二定時器超時時，從所述單呼請求列表中刪除對應(yīng)的單呼請求記錄，其中該第二定時器的定時時長為第二指定時長。
13.如權(quán)利要求9所述的服務(wù)端，其特征在于:所述單呼處理單元進一步用于在向該上行核心用戶發(fā)送呼叫請求前，先判斷距離上次向該上行核心用戶發(fā)送呼叫請求的時長是否達到第三指定時長，如果是，則發(fā)送該呼叫請求，否則抑制本次呼叫請求的發(fā)送。
14.如權(quán)利要求9所述的服務(wù)端，其特征在于:所述單呼處理單元進一步用于獲取單呼請求中攜帶的文本類數(shù)據(jù)并記錄于該用戶群的單呼請求列表中，在發(fā)送呼叫請求時將單呼請求列表中來自多個用戶的附加數(shù)據(jù)匯總后添加到該呼叫請求中。
【文檔編號】H04L12/58GK103873354SQ201410120415
【公開日】2014年6月18日 申請日期:2014年3月27日 優(yōu)先權(quán)日:2014年3月27日
【發(fā)明者】劉巖 申請人:劉巖