數據通信系統的製作方法

2023-08-02 04:34:51 4

專利名稱：數據通信系統的製作方法
技術領域：
本發明涉及數據通信方法及系統，特別是涉及利用對話管理伺服器裝 置、可以在通信裝置間進行數據通信的數據通信方法及系統。
背景技術：
在進行2個NTT (指例如裝置、或在裝置上執行軟體從而進行具體化 的進程)間的數據通信時，為了進行使該數據通信可行或切斷這樣的數據 通信的控制，有時使用與數據通信獨立的控制用通信協議。例如，在IP電 話中，作為控制用通信協議廣泛使用所謂SIP (Session Initiation Protocol:對話啟動協議)的協議(對於SIP的詳細情況參照IETF, RFC3261 : SIP : Session Initiation Protocol ， http:〃www.ietf.org/rfc/rfc3261.txt (以下，稱為文獻l))。
下面，簡單地說明在SIP中，利用對通信裝置間確立的通信對話進行 管理的對話管理伺服器，第一通信裝置確立與第二通信裝置之間的通信對 話(以下，僅稱為對話)，可以進行數據通信時的步驟。
並且，在本說明書中，所謂對話是指在通信裝置間進行的一連串數據 通信順序。例如，以SIP中的INVITE消息和對應的200OK和ACK消息 的往返為開始，對應於BYE消息的200OK消息的往返為結束。
首先，第二通信裝置在通信對話確立處理之前將該通信裝置的IP位址 登記在對話管理伺服器中。S口，該通信裝置向對話管理伺服器發送登記請 求消息(還稱為REGISTER消息)，該登記請求消息包含用於在對話管理 伺服器中識別該通信裝置或通信裝置的用戶的識別符(還稱為SIP—URD、 和該通信裝置的IP位址。對話管理伺服器將記載於登記請求消息中的識別 符和IP位址對應記錄。
而且，記錄在對話管理伺服器中的、某個通信裝置的識別符和IP位址 的對應，當經過了對應被記錄時設定的有效期間時被刪除。此外，還可以
通過該通信裝置發送登錄刪除請求消息(例如，在上述REGISTER消息中 指示將對應的有效期間設定為O)來刪除。
另外，在本說明書中，將某個通信裝置(NTT)的識別符和IP位址對 應記錄在對話管理伺服器的狀態還稱為該通信裝置登錄到對話管理服務 器，將未記錄的狀態還稱為該通信裝置從對話管理伺服器註銷。S卩，這裡， 第二通信裝置成為登錄到對話管理伺服器的狀態。
同樣地，第一通信裝置也在對話確立處理之前進行向對話管理伺服器 的登錄。
接著，第一通信裝置進行與第二通信裝置的對話確立。
艮P，第一通信裝置向對話管理伺服器發送請求與第二通信裝置確立對 話的連接請求消息(以下，也稱為INVITE消息)。在該INVITE消息中記 載有第一通信裝置的識別符和第二通信裝置的識別符。接收到INVITE消 息的對話管理伺服器向第二通信裝置傳輸該INVITE消息。接收到INVITE 消息的第二通信裝置在受理該連接請求時，向對話管理伺服器發送表示其 意思的響應消息(也稱為200OK消息)。該對話管理伺服器將接收到的 2000K消息向第一通信裝置傳輸。通過第一通信裝置接收該響應消息，從 而在與第二通信裝置之間確立通信對話。
以上是在SIP中至第一通信裝置利用對話管理伺服器確立與第二通信 裝置之間的對話並可以進行數據通信為止的步驟。
SIP從其擴展性的高度出發，不停留於IP電話，在瞬時消息服務或內 容發布服務等各種多媒體服務中作為在用戶與內容提供者之間的控制用通 信協議利用。此外，在NGN即下一代網絡(Next Generation Network) 作為其網絡的基礎而利用的IMS (IP Multimedia Subsystem: IP多媒體 子系統)中也利用SIP。
IMS是用於實現在IP網絡上的內容發布或IP電話等多媒體服務的通 信體系。在構成IMS的因素中具有中心作用的是稱為呼叫對話控制功能 (CSCF: Call Session Control Function)的SIP伺服器裝置。
CSCF與連接至IMS的用戶側通信裝置或服務側通信裝置、或者向IMS 內的節點提供各種功能的應用程式伺服器裝置(Application Server,以 下稱為AS)等，利用SIP進行數據通信。存在如下三種CSCF:處理來自
用戶的訪問的P-CSCF (Proxy —CSCF)、成為與其它網絡的通道的 I-CSCF(Interrogating — CSCF)、以及進行對話控制的S-CSCF( Serving —CSCF)。
I-CSCF及S-CSCF利用Diameter協議與存儲用戶信息或過濾準則 的歸屬用戶伺服器(Home Subscriber Server,以下稱為HSS)裝置進 行數據通信。Diameter是用於AAA (認正/授權/記帳)的協議。過濾準則 是S-CSCF與收取的消息內容進行對比、記述了用於判斷該消息的處理是 否需要利用哪一個AS的條件的數據(對於IMS的詳細情況參照3GPP， 3GPP TS 23.228: IP Multimedia Subsystem (IMS) Stage 2， http:〃www.3gpp.org/ftp/Specs/ html-info/ 23228.htm (以下稱為文 獻2))。
提供多媒體服務的內容提供者根據提供服務的種類要求對提供服務的 通信裝置(服務側通信裝置)安裝對服務的訪問控制功能或用戶與服務之 間的加密通信中使用的對話密鑰的生成功能等、對話確立中需要的功能。
但是，將對話確立中需要的各功能搭載於每個服務側通信裝置的情況 下，產生各服務側通信裝置上的軟體開發或安裝、維護等的工作花費很多 成本的問題。而且，各服務側通信裝置為了實現對話確立中需要的各功能 需要較多的計算資源，並且應管理的數據量也增加。
為了解決該問題考慮了如下方法不在各服務側通信裝置中配置對話 確立中所需的單一至多個處理，而向對話管理伺服器或與對話管理伺服器 協同工作的伺服器配置，從而實現功能的一元化。
例如，在IMS中，作為SIP伺服器的AS進行QoS控制或密鑰生成等 附加性的服務，從而可以減輕服務側通信裝置的負擔。
此外，在(日本)特開2005 — 284753號公報(稱為文獻3)中，作 為SIP伺服器的對話管理伺服器具有用於判斷可否向用戶提供服務的功能、 和在被判斷為可以提供該服務時向服務側通信裝置發送對話設定請求數據 包的功能。
這裡，對在文獻3中用戶側通信裝置經由SIP伺服器與服務側通信裝 置之間確立對話為止的順序(sequence)進行說明。SIP伺服器最初接收 從用戶側通信裝置向服務側通信裝置的INVITE消息。在由文獻1制定的
SIP的標準步驟中，SIP伺服器立即向服務側通信裝置傳輸該INVITE消息， 但是在文獻3記載的步驟中，追加了該INVITE消息的傳輸之前向用戶管 理伺服器詢問用戶是否保有用戶側通信裝置享受服務側通信裝置的服務的 權限的步驟。
權限判斷的結果，用戶保有上述權限的情況被傳到SIP伺服器時，SIP 伺服器向服務側通信裝置傳輸INVITE消息。以後執行與文獻3同樣的步 驟，從而具有享受服務側通信裝置的服務的權限的用戶利用的通信裝置可 以與服務側通信裝置確立對話。
如上所示，在文獻3中公開了如下方法通過每個服務側通信裝置不 具備服務提供的可否判斷功能、而一元地安裝在用戶管理伺服器上，從而 在服務側通信裝置中削減進行於用戶管理處理的成本。
在專利文獻1所示的方法中，對話管理伺服器從用戶側通信裝置接收 了 INVITE消息時，向服務側通信裝置傳輸該INVITE消息之前，待機直 到基於用戶管理伺服器的可否提供服務的判斷處理結束為止。因此，該判 斷處理所需的時間按原樣反映到確立對話所需的整體時間上，在該處理需 要較長時間的狀況下，存在確立對話也需要長時間的課題。
除此之外，服務側通信裝置由於伺服器內部錯誤等原因而處於不能提 供服務的狀態時，用戶側通信裝置在可否提供服務的判斷處理結束之後接 收其錯誤消息，因此，在該判斷處理需要較長時間的狀況下，存在對於與 用戶的權限無關的錯誤消息也花費用戶的等待時間的課題。

發明內容
由於對話確立所需的處理中的一個處理結果影響其它處理，所以本發 明提供一種通過並行進行過去等待其它處理結果而依次處理的多個處理、 從而可縮短處理時間的數據通信系統。
本發明提供一種數據通信系統，管理在通信裝置間確立的對話的對話 管理伺服器並行進行在通信裝置間往返的該對話確立所需的通信消息的傳 輸處理、和向其它功能提供裝置委託的該對話確立所需的處理。
具體地，本發明提供的對話管理伺服器的主要特徵在於，將從用戶側 通信裝置接收的請求對話確立的INVITE消息的傳輸處理、與該用戶是否
具有利用確立的對話享受服務用的權限的詢問或處理請求並行，例如在接 收這些結果之前進行。詢問或請求處理的對象也可以是功能提供伺服器等 其它裝置。
具體地，本發明的對話管理伺服器從進行用戶的權限判斷的權限判斷 伺服器或生成對話密鑰的密鑰生成伺服器等、進行對話確立所需的處理的 各種功能提供伺服器接收所請求的結果之前，向服務側通信裝置發送
INVITE消息。向功能提供伺服器發送詢問或處理請求的消息的定時，在 INVITE消息的發送之前或之後均無妨。
對話管理伺服器從服務側通信裝置接收到對傳輸的INVITE消息的可 提供服務消息時，向服務側通信裝置發送對該可提供服務消息的響應消息， 在該響應消息的發送之後，若有還未接收的結果，則等待接收來自這些功 能提供伺服器的結果。
此外，對話管理伺服器從功能提供伺服器作為對委託的處理的結果接 收到許可基於服務側通信裝置的服務提供的消息時，將對於該許可消息的 響應消息發送給功能提供伺服器，在該響應消息的發送之後，若有未接收 的結果，則等待接收對於向功能提供伺服器委託的處理、及/或向服務側通 信裝置發送的請求消息的結果。
根據如上所述的特徵，在本發明中，在不確定用戶側通信裝置是否保 有用於享受服務的權限的階段，對話管理伺服器向服務側通信裝置發送 INVITE消息。接收到該INVITE消息的服務側通信裝置根據由非專利文 獻1制定的標準的SIP的步驟，向對話管理伺服器發送作為響應的200OK 消息，轉移到與用戶側通信裝置之間完成對話確立的狀態。
該處理不依賴於用戶側通信裝置是否保有用於享受服務的權限而執 行，所以具有轉移到服務側通信裝置向不保有權限的用戶側通信裝置提供 服務的狀態的可能性。
對此，在本發明中，排除服務側通信裝置向不保有權限的用戶的通信 裝置提供服務的可能性，所以確定了用戶不保有用於享受服務的權限的情 況下，對話管理伺服器對服務側通信裝置進行用於切斷該對話的處理、例 如取消消息的發送。
具體地，對話管理伺服器若能夠確定用戶不保有用於享受服務的權限
的情況，則向服務側通信裝置發送用於取消該對話確立的SIP消息。發送
的SIP消息根據服務側通信裝置的狀態使用BYE消息或CANCEL消息。 此外，對話管理伺服器從服務側通信裝置接收到接受請求的響應消息
之後，從功能提供伺服器接收到為了接受服務提供所需的處理結果時，向
服務側通信裝置發送用於追加需要的信息的消息。
此外，從服務側通信裝置接收到對傳輸的請求消息的、拒絕提供服務
消息時，也可以向功能提供伺服器發送對該功能提供伺服器委託的處理的
取消消息。
對話管理伺服器從服務側通信裝置及委託處理的所有功能提供伺服器 接收響應，向服務側通信裝置發送需要的信息，在確認了服務側通信裝置 轉移到可提供服務的狀態的情況之後，向用戶側通信裝置發送對請求消息 的響應消息。
根據上述方式，對話管理伺服器並行進行在通信裝置間往返的連接請 求消息及連接響應消息的傳輸處理、和向其它功能委託的對話確立所需的 處理，所以可以縮短對話的確立所需的時間。
並且，根據上述方式，對話管理伺服器並行進行從通信裝置發送的錯 誤消息的傳輸處理、和向其它功能委託的對話確立所需的處理，所以可以 縮短錯誤消息到達用戶為止的時間。
進而，根據上述方式，用戶側通信裝置在服務側通信裝置處於不能提 供服務狀態時，用戶發送對話確立請求消息之後到接收錯誤消息為止的等 待時間縮短。
根據本發明，可以高速進行利用與功能提供伺服器協同工作的對話管 理伺服器的可否提供服務判斷處理。


圖1是表示第一實施例的系統結構的圖。
圖2是例示第一、第二實施例中使用的各裝置的硬體結構的框圖。 圖3是例示在第一實施例中用戶側通信裝置41及服務側通信裝置42 進行對SIP伺服器10的登錄處理時的順序的圖。
圖4是例示在第一實施例中用戶側通信裝置41及服務側通信裝置42
登錄之後的、SIP伺服器10的處理流程的圖。
圖5是例示在第一實施例中用戶側通信裝置41及服務側通信裝置42 登錄之後的、SIP伺服器10的處理流程的圖。
圖6是例示在第一實施例中用戶側通信裝置41及服務側通信裝置42 登錄之後的、SIP伺服器10的處理流程的圖。
圖7是例示第一實施例的對話日誌DB70、權限DB80、應用程式曰志 DB50中保存的信息的圖。
圖8是例示在第一實施例中SIP伺服器10在權限判斷伺服器20、密 鑰生成伺服器40、服務側通信裝置42之間收發的消息的圖。
圖9是例示在第一實施例中計費伺服器30接收的消息的圖。
圖10是例示在第一實施例中用戶側通信裝置41從服務側通信裝置42 接收服務的提供時的順序的圖。
圖11是例示在第一實施例中用戶側通信裝置41切斷與服務側通信裝 置42的對話時的順序的圖。
圖12是例示在第一實施例中服務側通信裝置42拒絕向用戶側通信裝 置41提供服務時的順序的圖。
圖13是例示在第一實施例中服務側通信裝置42不能向用戶側通信裝 置41提供服務時的順序的圖。
圖14是例示在第一實施例中服務側通信裝置42不能向用戶側通信裝 置41提供服務時的順序的圖。
圖15是表示第二實施例的系統結構的圖。
圖16是表示第二實施例的系統結構的圖。
圖17是例示在第二實施例中服務側通信裝置42向用戶側通信裝置41 提供服務時的順序的圖。
圖18是例示在第二實施例中服務側通信裝置42向用戶側通信裝置41 提供服務時的順序的圖。
圖19是例示在第二實施例中服務側通信裝置42拒絕向用戶側通信裝 置41提供服務時的順序的圖。
圖20是例示在第二實施例中服務側通信裝置42拒絕向用戶側通信裝 置41提供服務時的順序的圖。
圖21是例示在第二實施例中服務側通信裝置42拒絕向用戶側通信裝 置41提供服務時的順序的圖。
圖22是例示在第二實施例中服務側通信裝置42不能向用戶側通信裝 置41提供服務時的順序的圖。
圖23是例示在第二實施例中服務側通信裝置42不能向用戶側通信裝 置41提供服務時的順序的圖。
符號說明0、1:網絡
10:SIP伺服器
11、14: P-CSCF
12、15: I-CSCF
13、16: S-CSCF
20:權限判斷伺服器
21、22: HSS
30:計費伺服器
31:密鑰生成AS
32:權限判斷AS
40:密鑰生成伺服器
41:用戶側通信裝置
42:服務側通信裝置
50:應用程式DB
6〇註冊DB
70:對話日誌DB
80:權限DB
91:CPU
92:存儲器
93:硬碟
94:網絡接口
95:輸入輸出裝置
具體實施例方式
以下，利用附圖對本發明的實施方式進行說明。並且，本發明不通過 以下所述的實施方式進行限定。
此外，下面說明對SIP的應用例子，但是對於SIP以外的在確立通信
對話的情況下經由對話管理伺服器收發對話確立請求消息或響應消息的那 樣的系統也可以應用本發明。
而且，以下的各實施例的各裝置例如包括在圖2表示其結構例那樣
的處理器(CPU) 91，用於存儲在處理器91上執行的各種軟體(程序) 和數據的存儲器92及/或硬碟93，用於與網絡0連接的網絡接口 94，鼠 標、鍵盤等的輸入裝置，顯示裝置，以及包括外部存儲介質的讀寫裝置的 輸入輸出裝置95;在各構成因素通過總線等內部通信線96相互連接的一 般的電子計算機上實現。
艮P，以下的各實施例的各裝置具備的處理部和其處理通過在各裝置中， 在需要的定時，處理器91執行存儲於硬碟93或存儲器92中的、實現上 述各處理部的程序，從而進行具體化。在以下的實施方式的說明中，為了 方便將處理部作為處理的執行主體說明。並且，有時將程序稱為代碼或模 塊。
由處理器91執行的程序可以預先存儲在各裝置的硬碟93或存儲器92 中，也可以在需要時通過該裝置可利用的介質從其它裝置導入上述存儲部。 作為介質例如是指可以由輸入輸出裝置95可利用的可拆卸的存儲介質、或 者可以經由網絡接口 94利用的通信介質(即，網絡或在網絡上傳播的載波 或數位訊號)。此外，也可以由集成電路等硬體構成上述各處理部。
此外，在以下的實施例中使用的域名、URL、 URI、 IP位址等識別符 是為了用於說明而虛構的，即使是實際存在的也無妨。消息 M112，則SIP伺服器IO返回其它消息的等待接收狀態(S309、 S315)。 這裡，權限判斷結果[許可]消息M112由權限判斷伺服器20的權限判斷處 理部203製作，具有如圖8例示的正文部。即，作為Permission因素的 status屬性的值的accept表示權限判斷的結果、即用戶側通信裝置41保 有用於享受服務側通信裝置42的服務的權限，id屬性的值358ala77與 該消息對應的權限判斷請求消息中包含的id屬性的值一致。
從權限判斷伺服器20接收到的權限判斷結果消息是權限判斷結果[拒 絕]消息M121時，即用戶側通信裝置41不具有用於享受服務側通信裝置 42的服務的權限時，SIP伺服器10立即轉移到中斷對話的確立的處理
(S309、 S315、 S316)。這裡，權限判斷結果[拒絕]消息M121由權限 判斷伺服器20的權限判斷處理部203製作，具有如圖8例示的正文部。 即，作為Permission因素的status屬性的值的reject作為權限判斷的結 果，表示用戶側通信裝置41不具有用於享受服務側通信裝置42的服務的 權限，id屬性的值358ala77與該消息對應的權限判斷請求消息中包含的 id屬性的值一致。
這裡，對SIP伺服器10用於中斷對話確立的處理流程進行說明。
SIP伺服器10的SIP消息處理部102為了表示用戶側通信裝置41不 具有用於享受服務側通信裝置42的服務的權限的情況，生成作為SIP消息 的403Forbidden消息，向用戶側通信裝置41發送(S50D。
SIP伺服器10的應用程式處理部105向請求處理中的功能提供伺服器 即這裡是密鑰生成伺服器40發送密鑰生成取消消息M122 (S502)。
接著，SIP伺服器10的SIP消息處理部102進行用於取消向服務側 通信裝置42的連接請求的處理。對於該處理，在SIP伺服器10己經從服 務側通信裝置42接收了對INVITE的200OK消息的情況、和不是這樣的 情況下，步驟不同。以下，依次說明每一個。
首先，SIP伺服器10從服務側通信裝置42已經接收到對INVITE的 200OK消息時，SIP伺服器10的SIP消息處理部102向服務側通信裝置 42發送作為SIP消息的BYE消息，從而解除在與服務側通信裝置42之間 確立的SIP會話(S504)，結束處理(S505)。這裡，BYE消息M124由 SIP消息處理部102製作，具有如圖8例示的正文部。g卩，附加作為 Sessionlnfo因素的status屬性的值的cancel,是為了明示該BYE消息 不是因為用於通知已經確立的對話的結束而發送的，而是用於中斷仍未確 立的對話的確立處理而發送的情況。作為From因素的值的SIP—URI"sip: [email protected] " 及作為 To 因素的值的 SIP — URI "sip:[email protected] "表示為了中斷從作為SIP-URI具有 sip:[email protected]的用戶側通信裝置41向作為SIP-URI具有 sip:[email protected]的服務側通信裝置42的對話確立而發送了該BYE 消息M124的情況。關於Date因素的值與權限判斷取消消息M145相同。
接著，SIP伺服器10沒有從服務側通信裝置42接收對INVITE的
200OK消息時，通過SIP消息處理部102向服務側通信裝置42發送 CANCEL消息，從而中斷在與服務側通信裝置42之間嘗試的對話確立。 (S506)
在步驟S506中，由於網絡O上的通信障礙等理由，存在SIP伺服器 10發送的CANCEL消息未到達服務側通信裝置42的可能性。未到達的情 況下，服務側通信裝置42繼續進程啟動處理等、用於對話確立的處理，向 SIP伺服器10發送作為對INVITE的最終響應的200OK消息，所以從服 務側通信裝置42看來確立了與用戶側通信裝置41之間的對話，成為對話 確立的中斷不能實現的狀態。
因此，SIP伺服器10的SIP消息處理部102不管已經發送了 CANCEL 消息，從服務側通信裝置42接收到具有與先前發送的INVITE消息或 CANCEL消息相同的Call —ID標題、且在CSeq標題中包含文字列 "INVITE"的200OK消息時，通過向服務側通信裝置42發送BYE消息， 從而切斷在與服務側通信裝置42之間確立的對話(S507、 S504)。這裡 發送的BYE消息與圖8所示的相同。發送BYE消息之後，SIP伺服器10 結束處理(S505)。
向服務側通信裝置42發送CANCEL消息並經過了一定時間時，SIP 伺服器10視為服務側通信裝置42接收到該CANCEL消息，結束處理 (S5〇8、 S505)。
以上是SIP伺服器10從權限判斷伺服器20接收到權限判斷結果消息 時的、SIP伺服器10的處理流程。
另一方面，等待接收中的SIP伺服器10從密鑰生成伺服器40接收到 密鑰生成結果消息Ml 13時，SIP伺服器10的應用程式處理部105將包 含在該密鑰生成結果消息中的密鑰信息保存在對話日誌DB70中(S310、 S317)。艮P， SIP伺服器10在對話日誌DB70中，在與密鑰生成結果消息 正文部M113 —1中包含的From因素的值、To因素的值、CallID因素的 值對應的表條目中，作為對話密鑰信息記錄包含在該密鑰生成結果消息正 文部中的Key因素的值。這裡，密鑰生成結果消息M113由密鑰生成服務 器40的密鑰生成處理部403製作，具有如圖8所示的正文部。即，作為 KeyGen因素的status屬性的值的response表示該消息是為了傳輸密鑰
生成的結果得到的密鑰而發送的。From因素的值、To因素的值、CallID 因素的值與對應的密鑰生成請求消息中包含的各因素的值一致。關於Date 因素的值，與權限判斷取消消息M145相同。此外，作為Key因素的scheme 屬性的值的AES256表示Key因素中包含的信息是密鑰長度256比特的 AES算法中使用的密鑰，Key因素內的OctetString因素的值表示對話密 鑰信息。
以上是SIP伺服器10從密鑰生成伺服器40接收到密鑰生成結果消息 時的、SIP伺服器10的處理流程。
當等待接收狀態的SIP伺服器10從服務側通信裝置42、權限判斷服 務器20、密鑰生成伺服器40的所有伺服器接收到消息時，轉移到對話確 立的最終處理(S311、 S318)。
在對話確立的最終處理中，SIP伺服器10最初確認應用程式處理部 105從功能提供伺服器取得並記錄到對話日誌DB70中的信息中是否存在 應向用戶側通信裝置及服務側通信裝置傳達的信息(S601)D這裡，應向 用戶側通信裝置及服務側通信裝置傳達的信息具體地是指由密鑰生成服務 器40生成的對話密鑰信息等。
存在應向用戶側通信裝置及服務側通信裝置傳達的信息的情況下，SIP 伺服器10進行為了向用戶側通信裝置41及服務側通信裝置42傳達信息 所需的處理(S602、 S603)。
艮口， SIP伺服器10最初向服務側通信裝置42發送UPDATE消息 (S602)。 UPDATE消息M114由SIP消息處理部102製作，將記錄在 對話日誌DB70中的密鑰信息包含在正文部。
接著，當存在應向用戶側通信裝置及服務側通信裝置傳達的信息的情 況下，SIP伺服器10的SIP消息處理部102對記錄在對話日誌DB70中 的密鑰信息進行複製，並生成200OK消息M116的正文部(S603)。
以上是在存在應向用戶側通信裝置及服務側通信裝置傳達的信息的情 況下，SIP伺服器10為了向各通信裝置傳達信息而進行的處理流程。
在對話確立的最終處理中，SIP伺服器10的SIP消息處理部102在 從服務側通信裝置42接收的200OK消息M109的標題部除去包含自URI 的Via標題從而製作200OK消息M116的標題部，並向用戶側通信裝置41發送(S604)。關於消息的正文部，在存在應向用戶側通信裝置及服務 側通信裝置傳達的信息時，利用在步驟S603中生成的正文部。在不存在 應向用戶側通信裝置及服務側通信裝置傳達的信息時，在正文部不包含信 息進行發送。
最後，SIP伺服器10開始後面計費伺服器30進行計費處理時使用的 對話日誌的收集(S605)。艮卩，SIP伺服器10的對話管理部104對於與 INVITE消息M101的From標題表示的通信源SIP—URI、 To標題表示 的通信目的地SIP—URI、和Call—ID標題表示的通信對話的識別信息對 應的條目，在對話日誌DB70中記錄當前時刻作為該通信對話的開始時刻。 圖7表示保存在對話日誌DB70中的對話日誌信息的一例。
以上是SIP伺服器10從完成了登錄處理的用戶側通信裝置41接收到 INVITE消息M101之後的SIP伺服器10的處理流程。
接著，用圖10到圖14表示完成了登錄處理的用戶側通信裝置41向 服務側通信裝置42請求提供服務時的順序。
首先，利用圖10對用戶側通信裝置41具有用於享受服務側通信裝置 42的服務的權限時的順序進行說明。
首先，用戶側通信裝置41向服務側通信裝置42請求提供服務時，用 戶側通信裝置41向SIP伺服器10發送作為SIP消息的INVITE消息 MlOl。
SIP伺服器10從用戶側通信裝置41接收到INVITE消息MlOl時， 根據處理流程S302，註冊處理部103訪問註冊DB60檢索接收到的 INVITE消息的To標題表示的接收者SIP—URI的IP位址。若發現登記 的用戶側通信裝置41的IP位址，則SIP伺服器10根據處理流程S305， 對話管理部104在對話日誌DB70中與當前時刻一起記錄通信源SIP — URI、通信目的地SIP—URI、通信對話的識別信息、和該通信對話處於"確 立處理中(等待來自通信目的地的響應)"狀態(M102)。
接著，SIP伺服器10根據處理流程S306向權限判斷伺服器20發送 權限判斷請求消息M103,向密鑰生成伺服器40發送密鑰生成請求消息 M104。此外，SIP伺服器10根據處理流程S307向服務側通信裝置42 發送INVITE消息M105。
權限判斷請求消息M103由應用程式處理部105製作，具有如圖8所 示的正文部。
此外，密鑰生成請求消息M104由應用程式處理部105製作，具有如 圖8所示的正文部。
此外，INVITE消息M105由SIP消息處理部102在從用戶側通信裝 置41接收到的INVITE消息M101的標題部追加新的Via標題，將Max —Forward標題的值減1來製作。
在從圖10到圖U中，SIP伺服器10按照權限判斷請求消息M103、 密鑰生成請求消息M104、 INVITE消息M105的順序發送消息，但是本 發明不限於該順序。這些3個消息可以按任意的順序發送。
接收到權限判斷請求消息M103的權限判斷伺服器20由權限判斷處理 部203對權限DB80進行權限信息的詢問(M106)。
此外，接收到密鑰生成請求M104的密鑰生成伺服器40由密鑰生成處 理部403開始密鑰生成處理(M107)。
此外，接收到INVITE消息M105的服務側通信裝置42由伺服器處 理部423開始在服務的提供中所需的初始化處理(進程的啟動等)(M108)。
服務側通信裝置42完成該初始化處理時，SIP消息處理部423生成作 為SIP消息的200OK消息M109,向SIP伺服器10發送。
SIP伺服器10從服務側通信裝置42接收到200OK消息M109時， 根據處理流程S313， SIP消息處理部102生成對該200OK消息的ACK 消息MllO，向服務側通信裝置42發送。
服務側通信裝置42從SIP伺服器10接收到ACK消息M110時，服 務器處理部423開始收集對用戶側通信裝置41的服務的提供記錄(應用 程序日誌)(Mlll)。應用程式日誌被記錄在應用程式日誌DB50內。圖7 表示保存在應用程式日誌DB50中的應用程式日誌信息的一例。
權限判斷伺服器20進行權限判斷處理的結果，若確認用戶側通信裝置 41具有用於享受服務側通信裝置42的服務的權限，則向SIP伺服器10 發送權限判斷結果[許可]消息M112。權限判斷結果[許可]消息M112由 權限判斷處理部203製作，具有如圖8所示的正文部。
當密鑰生成伺服器40完成密鑰生成處理時，向SIP伺服器10發送密
鑰生成結果消息M113。密鑰生成結果消息M113由密鑰生成處理部403 製作，具有如圖8所示的正文部。
當SIP伺服器10從密鑰生成伺服器40接收到密鑰生成結果消息 M113時，根據處理流程S317，應用程式處理部105將該密鑰生成結果消 息中包含的密鑰信息保存在對話日誌DB70中。
當SIP伺服器10從服務側通信裝置42、密鑰生成伺服器40、權限判 斷伺服器20這三者中接收到消息時，根據處理流程S311轉移到對話確立 的最終處理。
在本實施例中，作為應向用戶側通信裝置及服務側通信裝置傳達的信 息，存在由密鑰生成伺服器生成的對話密鑰信息，所以SIP伺服器10根據 處理流程S602，由SIP消息處理部102生成UPDATE消息M114，向服 務側通信裝置42發送。
當服務側通信裝置42從SIP伺服器10接收到UPDATE消息M114 時，SIP消息處理部422取得在該UPDATE消息的正文部中包含的對話 密鑰信息之後，向SIP伺服器10發送對該UPDATE消息的2000K消息 M115，轉移到可以向用戶側通信裝置41提供服務的狀態。
此外，根據處理流程S603， SIP伺服器10由SIP消息處理部102 生成200OK消息M116的正文部，與在從服務側通信裝置42接收到的 200OK消息M109的標題部中除去包含自URI的Via標題從而生成的標 題部結合，作為200OK消息M116向用戶側通信裝置41發送。
當用戶側通信裝置41接收到200OK消息M116時，SIP消息處理部 412生成ACK消息M117，向SIP伺服器10發送。
SIP伺服器10從用戶側通信裝置41接收到ACK消息M117時，根 據處理流程S605，對話管理部104開始向對話日誌DB70收集用戶側通 信裝置41和服務側通信裝置42之間的對話記錄(對話日誌)(M118)。
通過以上的步驟，在用戶側通信裝置41和服務側通信裝置42之間確 立通信對話(M119)，可以進行從用戶側通信裝置41向服務側通信裝置 42的訪問、和從服務側通信裝置42向用戶側通信裝置41的信息服務。用 戶側通信裝置41和服務側通信裝置42之間的通信使用對話確立中得到的 對話密鑰信息來加密。此外，到對話開放為止的期間，繼續基於SIP服務
器10的對話日誌的收集和基於服務側通信裝置42的應用程式日誌的收集。
以上是用戶側通信裝置41具有用於享受服務側通信裝置42的服務的
權限時的順序。
在本順序中，並行進行基於權限判斷伺服器20的權限判斷處理M106、 基於密鑰生成伺服器的密鑰生成處理M107及基於服務側通信裝置42的進 程啟動處理等M108。因此，與一個一個依次進行各處理的過去的步驟相 比，具有可以縮短到通信開始所需的時間的效果。
接著，用圖11對用戶側通信裝置41向服務側通信裝置42請求對話 的切斷時的順序進行說明。
用戶側通信裝置41向服務側通信裝置42請求對話的切斷時，用戶側 通信裝置41首先由SIP消息處理部412向SIP伺服器10發送作為SIP 消息的BYE消息M301。
SIP伺服器10從用戶側通信裝置41接收到BYE消息M301時，對 話管理部104在對話日誌DB70中與密鑰生成結果消息正文部M113 — l 中包含的From因素的值、To因素的值、和CallID因素的值對應的表條 目中，記錄該通信對話處於"切斷處理中(等待來自通信目的地的響應)" 狀態的情況。
接著，SIP伺服器10由SIP消息處理部102在BYE消息M301的標 題部追加新的Via標題，通過將Max—Forward標題的值減1來製作BYE 消息M302，並向服務側通信裝置42發送。
服務側通信裝置42從SIP伺服器10接收到BYE消息M302時，SIP 消息處理部422向SIP伺服器IO發送作為對該BYE消息的響應的200OK 消息M303之後，伺服器處理部423結束向用戶側通信裝置41提供服務， 並且停止應用程式日誌的收集。此外，SIP消息處理部422確認在接收到 的BYE消息M302的標題部是否包含status屬性是cancel的Sessionlnfo 因素。在本順序中，在BYE消息的正文部不包含該因素，所以服務側通信 裝置42生成應用程式日誌信息消息M305，向計費伺服器30發送。這裡， 應用程式日誌信息消息M305由伺服器處理部423製作，具有如圖9所示 的正文部。
SIP伺服器10從服務側通信裝置42接收到200OK消息M303時，
SIP消息處理部102從該200OK消息的標題部除去包含自URI的Via標 題來製作200OK消息M304並向用戶側通信裝置41發送。接著，對話管 理部104向與200OK消息M303的From標題所示的通信源SIP — URI、 To標題表示的通信目的地SIP—URI、和Call—ID標題表示的通信對話的 識別信息對應的對話日誌DB70中的表條目中記錄當前時刻作為對話結束 時刻，並停止對話日誌的收集。
然後，SIP伺服器IO生成在標題部包含對話日誌信息的對話日誌信息 消息M306，並向計費伺服器30發送。這裡，對話日誌信息消息M306由 對話管理部104製作，具有如圖9所示的正文部。
以上是用戶側通信裝置41向服務側通信裝置42請求對話的切斷時的 順序。
接著，用圖12說明用戶側通信裝置41不具有用於享受服務側通信裝 置42的服務的權限的情況下、且比權限判斷的結果先通知來自服務側通信 裝置42的200OK消息的情況下的順序。
關於用戶側通信裝置41向SIP伺服器10發送INVITE消息M101之 後到服務側通信裝置42開始應用程式日誌的收集(Mill)為止的順序與 圖10所示的順序相同，所以省略說明。
然後，權限判斷伺服器20進行權限判斷處理的結果，確認用戶側通信 裝置41不具有用於享受服務側通信裝置42的服務的權限時，向SIP服務 器10發送權限判斷結果[拒絕]消息M121。權限判斷結果[拒絕]消息 M121由權限判斷處理部203製作，並具有如圖8所示的正文部。
SIP伺服器10從權限判斷伺服器20接收到權限判斷結果[拒絕]消息 M121時，根據處理流程S501， SIP消息處理部102生成作為SIP消息的 403Forbidden消息M122，並向用戶側通信裝置41發送。
用戶側通信裝置41從SIP伺服器10接收到403Forbidden消息 M122時，SIP消息處理部412生成ACK消息M123並向SIP伺服器10 發送。
SIP伺服器10向用戶側通信裝置41發送403Forbidden消息M122 之後，根據處理流程S502向密鑰生成伺服器40發送密鑰生成取消消息 M124。密鑰生成取消消息M124由應用程式處理部105製作，具有如圖8所示的正文部。
密鑰生成伺服器40從SIP伺服器10接收到密鑰生成取消消息M124 時，密鑰生成處理部403結束處於處理中的密鑰生成處理。接著，消息處 理部402生成密鑰生成取消響應消息M125，向SIP伺服器10發送。這 裡，密鑰生成取消響應消息M125具有如圖8所示的正文部。
這裡，用圖8對密鑰生成取消響應消息正文部M125 — 1的一例進行說 明。作為KeyGen因素的status屬性的值的canceled表示該消息是作為 對密鑰生成的取消請求的響應而發送的。KeyGen因素的內容與對應的密 鑰生成取消消息正文部M124 — 1的KeyGen因素的內容相同。
接著，SIP伺服器10根據處理流程S503，判斷是否從服務側通信裝 置42接收到200OK消息。在本順序中，處理在該時刻從服務側通信裝置 42接收到200OK消息的情況，所以根據處理流程S504，向服務側通信裝 置42發送BYE消息M126。 BYE消息M126由SIP消息處理部102生 成，具有如圖8所示的正文部。
服務側通信裝置42從SIP伺服器10接收到BYE消息M126時，SIP 消息處理部422生成作為對該BYE消息的響應的200OK消息M127，向 SIP伺服器10發送。接著，服務側通信裝置42由伺服器處理部423結束 向用戶側通信裝置41的可提供服務狀態，並且停止應用程式日誌的收集。 此外，SIP消息處理部422確認在接收的BYE消息M126的正文部是否包 含status屬性為cancel的Sessionlnfo因素。在本順序中，該因素包含 在BYE消息的正文部，所以服務側通信裝置42不向計費伺服器30發送 應用程式日誌信息消息,
最後，SIP伺服器10從服務側通信裝置42接收對BYE消息的200OK 消息M127，結束處理。
以上是用戶側通信裝置41不具有用於享受服務側通信裝置42的服務 的權限的情況下、且來自服務側通信裝置42的200OK消息比權限判斷的 結果先通知的情況下的順序。
在本順序中，其特徵在於，在為了消除暫時在SIP伺服器IO和服務側 通信裝置42之間確立的SIP會話而使用的BYE消息的正文部中，包含表 示用戶側通信裝置41未能確立對話的信息(圖8的BYE消息正文M126
一l表示的、作為Sessionlnfo因素的status屬性的值的cancel)。通過 包含該信息，服務側通信裝置42可以判斷接收到的BYE消息是為了結束 對話而發送的，或者為了表示對話確立處理在中途中斷而發送的。由此， 防止向計費伺服器30發送不需要的應用程式日誌，作為結果具有防止發生 不當的計費處理的效果。
接著，用圖13對用戶側通信裝置41不具有用於享受服務側通信裝置 42的服務的權限的情況、且權限判斷的結果比來自服務側通信裝置42的 200OK消息先通知的情況的順序進行說明。
從用戶側通信裝置41向SIP伺服器10發送INVITE消息M101之後 到服務側通信裝置42開始進程啟動處理等(M108)為止的順序，與圖10 所示的順序相同，所以省略說明。
然後，權限判斷伺服器20由權限判斷處理部203在服務側通信裝置 42發送200OK消息之前完成權限判斷處理，確認用戶側通信裝置41不 具有用於享受服務側通信裝置42的服務的權限時，向SIP伺服器10發送 權限判斷結果[拒絕]消息M121。權限判斷結果[拒絕]消息M121由消息 處理部202製作，具有如圖8所示的正文部。
SIP伺服器10從權限判斷伺服器20接收到權限判斷結果[拒絕]消息 M121時，根據處理流程S5〇l， SIP消息處理部102發送403Forbidden 消息M122。
用戶側通信裝置41從SIP伺服器10接收到403Forbidden消息 M122時，SIP消息處理部412生成ACK消息M123，向SIP伺服器10 發送。
SIP伺服器10向用戶側通信裝置41發送403Forbidden消息M122 之後，根據處理流程S502，向密鑰生成伺服器40發送密鑰生成取消消息 M124。密鑰生成取消消息M124由應用程式處理部105生成，具有如圖 8所示的正文部。
密鑰生成伺服器40從SIP伺服器10接收到密鑰生成取消消息M124 時，密鑰生成處理部403結束處於處理中的密鑰生成處理。接著，消息處 理部402生成密鑰生成取消響應消息M125，向SIP伺服器10發送。這 裡，密鑰生成取消響應消息M125具有如圖8所示的正文部。
接著，SIP伺服器10根據處理流程S503，判斷是否從服務側通信裝
置42接收到200OK消息。在本順序中，處理在該時刻仍未從服務側通信 裝置42接收200OK消息的情況，所以根據處理流程S506， SIP消息處 理部422向服務側通信裝置42發送作為SIP消息的CANCEL消息M131 。
服務側通信裝置42從SIP伺服器10接收到CANCEL消息M131時， SIP消息處理部422生成作為對該CANCEL消息的響應的200OK消息 M132，向SIP伺服器IO發送。
接著，服務側通信裝置42由SIP消息處理部422向SIP伺服器10 發送SIP最終響應消息即487 Request Terminated消息。
SIP伺服器10從服務側通信裝置42接收到對CANCEL消息M131 的2000K消息M132時，根據處理流程S508、 S505結束處理。
接著，用圖14對服務側通信裝置42成為不能提供服務的狀態時的順 序進行說明。
對於從用戶側通信裝置41向SIP伺服器10發送INVITE消息M101 到SIP伺服器10向服務側通信裝置42發送INVITE消息M105為止的順 序，與圖10所示的順序相同，所以省略說明。
接著，為了傳達服務側通信裝置42因任意的理由成為不能提供服務的 狀態的情況，SIP消息處理部422向SIP伺服器10發送SIP錯誤響應消 息M141。例如，服務側通信裝置42發送作為SIP消息的486Busy Here 消息，從而可以通知服務側通信裝置42已經與其它用戶側通信裝置確立多 個對話、並且處於不能再確立新的對話的狀況的情況。
SIP伺服器10接收到SIP錯誤響應消息M141時，根據處理流程 S401， SIP消息處理部102向服務側通信裝置42發送ACK消息M142。
接著，SIP伺服器10根據處理流程S402，由SIP消息處理部102在 從服務側通信裝置42接收到的SIP錯誤響應消息M141的標題部中除去 包含自URI的Via標題來生成SIP錯誤響應消息M143，向用戶側通信裝 置41發送。
用戶側通信裝置41從SIP伺服器10接收到SIP錯誤響應消息M143 時，SIP消息處理部412向SIP伺服器10發送ACK消息M144。
接著，SIP伺服器10根據處理流程S403，向功能提供伺服器發送用
於取消處理請求的消息。在本順序中，作為請求處理中的功能提供伺服器 存在權限判斷伺服器20及密鑰生成伺服器40。
首先，SIP伺服器10由應用程式處理部105生成權限判斷取消消息 M145，向權限判斷伺服器20發送。權限判斷取消消息M145具有如圖8 所示的正文部。
權限判斷伺服器20從SIP伺服器10接收到權限判斷取消消息M142 時，權限判斷處理部203結束處於處理中的權限判斷處理。接著，消息處 理部202生成權限判斷取消響應消息M146，向SIP伺服器10發送。權 限判斷取消響應消息M146具有如圖8所示的正文部。
這裡，用圖8對權限判斷取消響應消息正文部M146 — l的一例進行說 明。作為Permission因素的status屬性的值的canceled表示該消息是作 為對權限判斷的中斷請求的響應而發送的，id屬性的值358ala77與該消 息對應的權限判斷中斷消息中包含的id屬性的值一致。Permission因素 的內容與對應的權限判斷中斷消息正文部M142—1的Permission因素的 內容相同。
此外，SIP伺服器10由應用程式處理部105生成密鑰生成取消消息 M124，向密鑰生成伺服器40發送。密鑰生成取消消息M124具有如圖8 所示的正文部。
密鑰生成伺服器40從SIP伺服器10接收到密鑰生成取消消息M124 時，密鑰生成處理部403結束處於處理中的密鑰生成處理。接著，消息處 理部402生成密鑰生成取消響應消息M125，向SIP伺服器10發送。這 裡，密鑰生成取消響應消息M125由密鑰生成處理部403生成，具有如圖 8所示的正文部。
SIP伺服器10從權限判斷伺服器20接收權限判斷取消響應消息 M146，並且從密鑰生成伺服器40接收密鑰生成取消響應消息M123，結 束處理。
在本順序中，在執行權限判斷處理或密鑰生成處理的期間，SIP伺服器 10可以接收來自服務側通信裝置42的SIP錯誤響應消息，並且可以向用 戶側通信裝置41傳輸該SIP錯誤響應消息。因此，具有以下效果，即用戶 側通信裝置41可以比過去的步驟早知道服務側通信裝置42處於不能提供
服務的狀態的情況。
以上是服務側通信裝置42為不能提供服務的狀態時的順序。
在本實施例中，與過去的步驟相比，接收到INVITE消息的服務側通 信裝置42能夠與基於權限判斷伺服器20的權限判斷處理和基於密鑰生成 伺服器40的密鑰生成處理並行執行進程啟動處理等提供服務所需的初始 處理。因此，具有縮短到對話確立為止所需的時間的效果。
而且，在本實施例中，在對話確立中從功能提供伺服器提供的信息中 不存在應向用戶側通信裝置及服務側通信裝置傳達的信息時，SIP伺服器 10不需要發送UPDATE消息M114，並且，服務側通信裝置不需要發送 對UPDATE消息的200OK消息M115。具體地，在各通信裝置內或SIP 伺服器上進行密鑰生成處理的系統的情況下，不需要本實施例中使用的密 鑰生成伺服器，不存在應向用戶側通信裝置及服務側通信裝置傳達的信息。 因此，可以省略UPDATE消息及200OK消息的收發處理，可以實現更高 速的對話確立。
並且，在本實施方式中，作為分別不同的獨立的裝置進行說明的功能 提供伺服器的每一個和對話管理伺服器，任意的兩個以上作為一個裝置實 現也無妨。功能提供伺服器包含在對話管理伺服器裝置中的情況下，不需 要其IP位址，多個功能提供伺服器結合為一個時，具有共同的IP位址和 不同的埠號。
此外，在本實施例中，權限判斷伺服器20對用戶用於享受由服務側通 信裝置提供的服務的權限進行判斷，但是，作為該例子的變形，也可以在 權限判斷伺服器20中對於用戶側通信裝置與服務側通信裝置確立對話用 的權限進行判斷，由各服務側通信裝置進行對於用戶用於享受在該對話上 提供的服務的權限判斷的構成。
接著，參照從圖15到圖23對基於本發明的數據通信的第二實施例進 行說明。
在第二實施例中表示在作為Application Server (應用程式伺服器， AS)向IMS體系上配置進行用戶的權限判斷或對話密鑰的生成的功能提供 伺服器的系統中，S—CSCF並行進行INVITE消息的傳輸和對AS的處理
請求消息的發送，從而縮短到對話確立為止所需的時間的過程。
圖15及圖16中示出結構的第二實施例的系統，在網絡0和網絡1的 兩個網絡上構成。網絡0和網絡1由路由器等連接，在兩網絡上存在的裝
置可以互相進行通信。在網絡0上存在P-CSCFll、 I—CSCF12、 S— CSCF13、 HSS21、進行密鑰生成的應用程式伺服器即密鑰生成AS31、以 及用戶側通信裝置41。此外，在網絡1上存在P-CSCF14、 I一CSCF15、 S — CSCF16、進行用戶信息的管理的HSS22、進行權限判斷的應用程式 伺服器即權限判斷AS32、以及服務側通信裝置42。
P—CSCFll分配有192.168.11.11的IP位址。P—CSCFll作為其 功能例如包括用於經由網絡0與其它CSCF及通信裝置通信的網絡接口卡 部(NIC) 111、處理SIP消息的SIP消息處理部112、處理Diameter消 息的Diameter消息處理部113、以及基於來自各通信裝置的請求處理SIP 消息的傳輸等的P—CSCF處理部114。
P — CSCF14分配有192.168.14.11的IP位址。P — CSCF14的功能 構成與P—CSCF11相同，所以省略說明。
I—CSCF12分配有192.168.12.11的IP位址。I—CSCF12作為其功 能例如包括用於經由網絡0與其它CSCF及通信裝置通信的網絡接口卡部 (NIC) 121、處理SIP消息的SIP消息處理部122、處理Diameter消息 的Diameter消息處理部123、以及進行網絡內的S — CSCF的檢索等的I 一CSCF處理部124。
I一CSCF15分配有192.168.15.11的IP位址。I—CSCF15的功能構 成與1—CSCF12相同，所以省略說明。
S—CSCF13分配有192.168.13.11的IP位址。S — CSCF13作為其 功能例如包括用於經由網絡0與其它CSCF及通信裝置通信的網絡接口卡 部(NIC) 131、處理SIP消息的SIP消息處理部132、處理Diameter消 息的Diameter消息處理部133、以及與AS等協同進行對話的控制的S— CSCF處理部134。
S—CSCF16分配有192.168.16.11的IP位址。S—CSCF16的功能 構成與S — CSCF13相同，所以省略說明。
HSS21分配有192.168.21.11的IP位址。HSS21作為其功能例如包
括用於經由網絡0與其它伺服器及通信裝置通信的網絡接口卡部(NIC)
211、處理Diameter消息的Diameter消息處理部212、以及進行用戶信 息的管理的HSS處理部213。
HSS22分配有192.168.22.11的IP位址。HSS22的功能構成與 HSS21相同，所以省略說明。
HSS21、 HSS22分別作為Diameter伺服器工作，各Diameter消息 處理部可以接收Diameter消息LIR (Location — Info — Request)，並發 送Diameter消息LIA (Location—Info—Answer)。
密鑰生成AS31分配有192.168.31.11的IP位址。密鑰生成AS31 例如包括用於經由網絡0與其它伺服器及通信裝置通信的網絡接口卡部 (NIC) 311、處理SIP消息的SIP消息處理部312、以及基於處理請求進 行用戶側通信裝置和服務側通信裝置之間的加密通信所使用的對話密鑰的 生成處理的密鑰生成處理部313。
權限判斷AS32分配有192.168.32.11的IP位址，具備管理與各用戶 是否可以享受服務側通信裝置提供的服務有關的權限信息的權限DB80。與 實施例1同樣地，權限DB80的管理對象不僅包含用於享受服務的權限， 還包含用於確立對話的權限。權限判斷AS32例如包括用於經由網絡0與 其它伺服器及通信裝置通信的網絡接口卡部(NIC) 321、處理權限判斷請 求消息的消息處理部322、以及控制對權限DB80的處理的權限判斷處理 部323。
用戶側通信裝置41分配有192.168.41.11的IP位址。用戶側通信裝 置41的功能構成與第一實施例相同，所以省略說明。
服務側通信裝置42分配有192.168.42.11的IP位址。服務側通信裝 置42的功能構成與第一實施例相同，所以省略說明。
P—CSCFll、 14、 I—CSCF12、 15、 S—CSCF13、 16分另U作為SIP 伺服器工作，各SIP消息處理部收發作為SIP消息的INVITE消息、BYE 消息、CANCEL消息、UPDATE消息或對其的響應消息等。
Jl:匕夕卜，P—CSCFll、 14、 I一CSCF12、 15、 S — CSCF13、 16麼、另U 作為Diameter客戶機工作，各Diameter消息處理部可以發送Diameter 協議的LIR消息等。
下面，說明圖15所示的用戶側通信裝置41通過圖16所示的服務側
通信裝置42進行經由IMS的數據通信的情況的通信步驟。
首先，用戶側通信裝置41及服務側通信裝置42分別對網絡0及網絡 1上的P—CSCF開始登錄。關於該登錄處理，按照非專利文獻2所示的在 IMS規格下制定的步驟，所以省略說明。
以下，用圖17到圖23，對完成了向IMS的登錄處理的用戶側通信裝 置41確立與服務側通信裝置42的對話為止的順序進行說明。
網絡0上的S—CSCF13及網絡1上的S—CSCF16的處理流程與第 一實施例的SIP伺服器10的處理流程大致相同。
首先，用圖17及圖18表示完成了登錄處理的用戶側通信裝置41對 服務側通信裝置42請求服務提供時的順序。
首先，用戶側通信裝置41向網絡 上的P — CSCFll發送INVITE 消息M401。
P —CSCF11從用戶側通信裝置41接收到INVITE消息M401時，SIP 消息處理部112基於該INVITE消息生成INVITE消息M402，向S — CSCF13發送。
S —CSCF13從P—CSCF11接收到INVITE消息M402時，對比在 用戶側通信裝置41的登錄時從HSS21取得的過濾準則和該INVITE消息 中包含的用戶信息(M403)。其結果，在該實施例中，判斷為在對話確立 時需要密鑰生成AS31提供的功能，向密鑰生成AS31發送密鑰生成請求 消息M404。作為密鑰生成請求消息M404，使用作為SIP消息的 MESSAGE消息。該MESSAGE消息由SIP消息處理部132和S—CSCF 處理部134生成。此外，該MESSAGE消息的正文部具有與圖8所示的密 鑰生成請求消息正文部M104 — 1相同的結構。
接著，S—CSCF13不等待來自密鑰生成AS31的響應，向網絡1上 的I—CSCF15發送INVITE消息M405。
並且，S—CSCF13以密鑰生成請求消息M404、 INVITE消息M405 的順序發送消息，但是這兩個消息不限於該順序，可以按任意的順序發送。
密鑰生成AS31從S — CSCF13接收到密鑰生成請求消息M404時， 密鑰生成處理部313開始密鑰生成處理(M406)。
與此並行，網絡1上的I一CSCF15從S—CSCF13接收到INVITE 消息M405時，為了取得擔任該INVITE消息的目的地即服務側通信裝置 42的S—CSCF的IP位址，Diameter消息處理部153生成Diameter協 議的LIR消息M407，向相同的網絡1上的HSS22發送。
HSS22從I一CSCF15接收到LIR消息M407時，將從該LIR消息中 提取的服務側通信裝置42的IP位址作為密鑰檢索內部DB，得到擔任服務 側通信裝置42的S—CSCF16的IP位址。接著，HSS22的Diameter處 理部222生成包含所得到的S—CSCF16的IP位址的LIA消息M408， 向I一CSCF15發送。
I—CSCF15的Diameter消息處理部153在從HSS22接收到的LIA 消息M408中提取出S — CSCF16的IP位址時，SIP消息處理部152基於 INVITE消息M405生成INVITE消息M409，向S —CSCF16的IP位址 發送。
S—CSCF16從I一CSCF15接收到INVITE消息M409時，對比在服 務側通信裝置42的登錄時從HSS22取得的過濾準則和該INVITE消息中 包含的服務信息(M410)。其結果，在本實施例中，判斷為對話確立時需 要權限判斷AS32的功能，向權限判斷AS32發送權限判斷請求消息 M411。作為權限判斷請求消息M411，與密鑰生成請求消息同樣地，使用 作為SIP消息的MESSAGE消息。該MESSAGE消息由SIP消息處理部 162和S—CSCF處理部164生成。此外，該MESSAGE消息的正文部具 有與圖8所示的權限判斷請求消息正文部M103-1相同的結構。
接著，S—CSCF16不等待來自權限判斷AS32的響應，向網絡1上 的P—CSCF14發送INVITE消息M412。
並且，S—CSCF16按照權限判斷請求消息M411 、INVITE消息M412 的順序發送消息，但是這兩個消息不限於該順序，可以按任意的順序發送。
權限判斷AS32從S—CSCF16接收到權限判斷請求消息M411時， 權限判斷處理部323對權限DB80進行權限信息的詢問(M413)。
與此並行，網絡1上的P—CSCF14從S—CSCF16接收到INVITE 消息M412時，SIP消息處理部142基於該INVITE消息生成INVITE消 息M414，向相同的網絡1上的服務側通信裝置42發送。
接收到INVITE消息M414的服務側通信裝置42由伺服器處理部423 開始在提供服務中需要的初始化處理(進程的啟動等)(M415)。完成初始 化處理時，服務側通信裝置42向P — CSCF14發送200OK消息M416。
從服務側通信裝置42接收到200OK消息M416的P—CSCF14由 SIP消息處理部142基於該200OK消息生成200OK消息M417,向S — CSCF16發送。
S — CSCF16從P—CSCF14接收到200OK消息M417時，SIP消息 處理部162生成對該200OK消息的ACK消息M418，向P — CSCF14發送。
P —CSCF14從S—CSCF16接收妾ij ACK消息M418時，SIP消息處 理部142基於該ACK消息生成ACK消息M419，向服務側通信裝置42 發送。
進行了權限判斷處理M413的權限判斷AS32結束該權限判斷處理， 確認用戶側通信裝置41具有用於享受服務側通信裝置42的服務的權限時， 向S—CSCF16發送權限判斷結果[許可]消息M420。作為權限判斷結果 [許可]消息M420，使用作為SIP消息的2000K消息。該2000K消息由 SIP消息處理部322和權限判斷處理部323生成。此外，該2000K消息 的正文部具有與圖8所示的權限判斷結果[許可]消息正文部M112 — 1相同 的結構。
S—CSCF16從服務側通信裝置42、權限判斷AS32的兩者接收到消 息時，SIP消息處理部162從對INVITE消息M409的200OK消息M417 的標題部除去包含自URI的Via標題，從而生成對INVITE消息M409的 2000K消息M421，向I一CSCF15發送。
I一CSCF15從S—CSCF16接收妾U 2000K消息M421日寸，基於該 200OK消息生成200OK消息M422，向網絡0上的S—CSCF13發送。
S—CSCF13從I—CSCF15接收到2000K消息M422時，SIP消息 處理部132生成對該200OK消息的ACK消息M423，向S — CSCF16發 送。
進行密鑰生成處理M406的密鑰生成AS31完成該密鑰生成處理時， 向S — CSCF13發送密鑰生成結果消息M424。作為密鑰生成結果消息
M424，使用作為SIP消息的200OK消息。該200OK消息由SIP消息處 理部312和密鑰生成處理部313生成。此外，200OK消息的正文部具有 與如圖8所示的密鑰生成結果消息正文部M113 — l相同的效果。
S—CSCF13從服務側通信裝置42、密鑰生成AS31的兩者接收消息 時，向網絡1上的S—CSCF16發送作為SIP消息的UPDATE消息M425。 UPDATE消息M425由SIP消息處理部132及S — CSCF處理部134生 成。在該UPDATE消息的正文部包含由密鑰生成結果消息M424傳輸的 對話密鑰信息。
S—CSCF16從S—CSCF13接收至ij UPDATE消息M425時，SIP消 息處理部162基於該UPDATE消息生成UPDATE消息M426，向P — CSCF14傳輸。
P—CSCF14從S—CSCF16接收至廿UPDATE消息M426日寸，SIP消 息處理部142基於該UPDATE消息生成UPDATE消息M427，向服務側 通信裝置42傳輸。
服務側通信裝置42從P—CSCF14接收到UPDATE消息M427時， SIP消息處理部422取得在該UPDATE消息的正文部中包含的對話密鑰 信息之後，生成對該UPDATE消息的200OK消息M428。接著，向P — CSCF14發送該200OK消息，轉移到可以向用戶側通信裝置41提供服務 的狀態。
P—CSCF14從服務側通信裝置42接收到200OK消息M428時，SIP 消息處理部142基於該200OK消息生成200OK消息M429，向S — CSCF16發送。
S—CSCF16從P—CSCF14牛妾收至廿200OK消息M429時，SIP消息 處理部162基於該200OK消息生成200OK消息M430，向S—CSCF13 傳輸。
S—CSCF13從S—CSCF16接收200OK消息M430時，SIP消息處 理部132在從P—CSCF11接收到的INVITE消息M402的標題部除去包 含自URI的Via標題來生成200OK消息M431的標題部。此外，根據從 密鑰生成AS31接收到的密鑰信息結果消息的正文部包含的對話密鑰信息 生成200OK消息M431的正文部，並與標題部結合來生成200OK消息
M431，向P—CSCF11發送。
P — CSCFll從S—CSCF13接收到200OK消息M431時，SIP消息 處理部112基於該200OK消息生成200OK消息M432，向用戶側通信裝 置41發送。
用戶側通信裝置41從P — CSCF11接收到200OK消息M432時，SIP 消息處理部412取得在該200OK消息的正文部中包含的對話密鑰信息之 後，作為對該200OK消息的響應，向P—CSCFll發送ACK消息M433。
P—CSCFll從用戶側通信裝置41接收到ACK消息M433時，SIP 消息處理部112基於該ACK消息生成ACK消息M434，向S-CSCF13 發送。
S-CSCF13從P—CSCFll接收ACK消息M434，結束處理。
通過以上的步驟，在用戶側通信裝置41和服務側通信裝置42之間確 立通信對話，可以進行從用戶側通信裝置41向服務側通信裝置42的訪問 和從服務側通信裝置42向用戶側通信裝置41的信息服務(M435)。用戶 側通信裝置41和服務側通信裝置42之間的通信利用在對話確立中得到的 對話密鑰信息進行加密。
在本實施例中，並行進行基於密鑰生成AS31的密鑰生成處理M406、 基於權限判斷AS32的權限判斷處理M413、基於服務側通信裝置42的進 程啟動處理等M415。因此，與依次逐一進行各處理的步驟相比，具有縮 短到通信開始為止所需的時間的效果。
關於用戶側通信裝置41向服務側通信裝置42請求對話的切斷時的順 序，按照由IMS的規格制定的步驟，所以省略說明。
接著，用圖19及圖20說明用戶側通信裝置41不具有用於享受服務 側通信裝置42的服務的權限的情況、且來自服務側通信裝置42的200OK 消息比權限判斷的結果先通知的情況的順序。
關於用戶側通信裝置41向P—CSCFll發送INVITE消息M401之 後到P—CSCF14向服務側通信裝置42發送ACK消息M419為止的順序， 與用圖17及圖18所示的順序相同。
然後，權限判斷AS32進行權限判斷處理的結果，確認用戶側通信裝 置41不具有用於享受服務側通信裝置42的服務的權限時，向S—CSCF16
發送權限判斷結果[拒絕]消息M441。作為權限判斷結果[拒絕]消息
M441,使用作為SIP消息的403 Forbidden消息。該403 Forbidden消 息由SIP消息處理部322及權限判斷處理部323生成。此外，該403 Forbidden消息的正文部具有與圖6所示的權限判斷[拒絕]消息正文部 M121 — l相同的結構。
S—CSCF16接收到權限判斷結果[拒絕]消息M441時，SIP消息處理 部162生成對INVITE消息M409的403 Forbidden消息M442,向I— CSCF15發送。
此外，S—CSCF16由SIP消息處理部162生成BYE消息M443，向 P—CSCF14發送。
P — CSCF14從S—CSCF16接收到BYE消息M443時，SIP消息處 理部142基於該BYE消息生成BYE消息M444，向服務側通信裝置42 發送。
服務側通信裝置42從P — CSCF14接收到BYE消息M444時，SIP 消息處理部422作為對該BYE消息的響應生成2000K消息M445，向P —CSCF14發送。
P—CSCF14從服務側通信裝置42接收到200OK消息M445時，SIP 消息處理部142基於該200OK消息生成2000K消息M446，向S— CSCF16發送。
在圖20中，I一CSCF15從S—CSCF16接收到403 Forbidden消息 M442時，SIP消息處理部152基於該403 Forbidden消息生成403 Forbidden消息M447，向網絡0上的S—CSCF13發送。
S —CSCF13 ,人I—CSCF15接收至U 403 Forbidden消息M447日寸， SIP消息處理部132生成作為對該403 Forbidden消息的響應的ACK消 息M448，向網絡1上的S—CSCF16發送。
此外，S—CSCF13基於從I一CSCF15接收到的403 Forbidden消 息消息M447， SIP消息處理部132生成403 Forbidden消息M449，向 P—CSCFll發送。
P—CSCF11從S—CSCF13接收至廿403 Forbidden消息M449時， SIP消息處理部112基於該403 Forbidden消息生成403 Forbidden消
息M450，向用戶側通信裝置41發送。
用戶側通信裝置41從P—CSCFll接收至ij 403 Forbidden消息M450 時，SIP消息處理部412生成作為對該403 Forbidden消息的響應的ACK 消息M451，向P—CSCF11發送。
P—CSCF11從用戶側通信裝置41接收到ACK消息M451時，SIP 消息處理部112基於該ACK消息生成ACK消息M452，向S—CSCF13 發送。
此外，S—CSCF13向密鑰生成AS31發送密鑰生成取消消息M453。 作為密鑰生成取消消息M453，使用作為SIP消息的MESSAGE消息。該 MESSAGE消息由SIP消息處理部132生成。此外，該MESSAGE消息 的正文部具有與圖8所示的密鑰生成取消消息正文部M124 — l相同的結 構。
密鑰生成AS31從S—CSCF13接收到密鑰生成取消消息M453時， 密鑰生成處理部313結束處於處理中的密鑰生成處理。接著，SIP消息處 理部132生成密鑰生成取消響應消息M454，向S-CSCF13發送。作為密 鑰生成響應消息M454，使用作為SIP消息的2000K消息。此外，該200OK 消息的正文部具有與圖8所示的密鑰生成取消響應消息正文部M125—l 相同的結構。
接著，用圖21對用戶側通信裝置41不具有用於享受服務側通信裝置 42的服務的權限、且權限判斷的結果比來自用戶側通信裝置42的200OK 消息先通知時的順序進行說明。
關於用戶側通信裝置41向P — CSCFll發送INVITE消息M401之 後到服務側通信裝置42開始進程啟動處理等M415的執行為止的順序，與 用圖17及圖18所示的順序相同。
然後，權限判斷AS32進行權限判斷處理的結果，確認用戶側通信裝 置41不具有用於享受服務側通信裝置42的服務的權限時，在服務側通信 裝置42發送200OK消息之前向S—CSCF16發送權限判斷結果[拒絕]消 息M441。作為權限判斷結果[拒絕]消息M441，是與圖19所示的順序中 的權限判斷結果[拒絕]消息M441相同的消息。
S-CSCF16從權限判斷AS32接收到權限判斷結果[拒絕]消息M441
時，SIP消息處理部162生成對INVITE消息M409的403 Forbidden 消息M442，向I一CSCF15發送。
此夕卜，S—CSCF16由SIP消息處理部162生成CANCEL消息M461， 向P —CSCF14發送。
然後，關於在接收到403Forbidden消息M442的I一CSCF15、和網 絡0內的各裝置中進行的順序，與圖20所示的順序相同，所以省略說明。
P — CSCF14從S—CSCF16接收至U CANCEL消息M461時，SIP消 息處理部142基於該CANCEL消息，生成CANCEL消息M462，向服務 側通信裝置42發送。
此外，P—CSCF14由SIP消息處理部142生成對CANCEL消息M461 的響應消息即200OK消息M463，向S — CSCF16發送。
服務側通信裝置42從P—CSCF14接收到CANCEL消息M462時， SIP消息處理部422作為對該CANCEL消息的響應生成200OK消息 M464，向P—CSCF14發送。
接著，服務側通信裝置42由SIP消息處理部422生成作為SIP最終 響應消息的487 Request Terminated消息，向P — CSCF14發送。
P —CSCF14從服務側通信裝置42接收到487 Request Terminated 消息時，SIP消息處理部142基於該487 Request Terminated消息生成 487 Request Terminated消息M466，向S—CSCF16發送。
S—CSCF16從P—CSCF14接收至U487 Request Terminated消息 M466時，SIP消息處理部162生成作為對該487 Request Terminated 消息的響應的ACK消息M467，向P—CSCF14發送。
P—CSCF14從S—CSCF16接收到ACK消息M467時，SIP消息處 理部142基於該ACK消息生成ACK消息M468，向服務側通信裝置42 發送。
接著，用圖22及圖23對服務側通信裝置42處於不能提供服務的狀 態時的順序進行說明。
用戶側通信裝置41向P—CSCFll發送INVITE消息M401之後到P 一CSCF14向服務側通信裝置42發送INVITE消息M414為止的順序與 圖17及圖18所示的順序相同。
接著，服務側通信裝置42為了傳達因任意的理由處於不能提供服務的
狀態的情況，向P—CSCF14發送SIP錯誤響應消息M471。例如，服務 側通信裝置42發送作為SIP消息的486Busy Here消息，從而通知服務 側通信裝置42已經與其它用戶側通信裝置確立了多個對話、並且處於不能 再確立新的對話的狀況。
P — CSCF14從服務側通信裝置42接收到SIP錯誤響應消息M471時， SIP消息處理部142基於該SIP錯誤響應消息生成SIP錯誤響應消息 M472，向S—CSCF16發送。
S—CSCF16從P —CSCF14接收至ij SIP錯誤卩向應消息M472日寸，SIP 消息處理部162生成作為對該SIP錯誤響應消息的響應的ACK消息 M473，向P—CSCF14發送。
P—CSCF14從S—CSCF16接收到ACK消息M473時，SIP消息處 理部142基於該ACK消息生成ACK消息M474,向服務側通信裝置42 發送。
接著，S—CSCF16由SIP消息處理部162基於接收到的SIP錯誤響 應消息M472生成SIP錯誤響應消息M475，向I一CSCF15發送。
接著，S—CSCF16向權限判斷AS32發送權限判斷取消消息M476。 作為權限判斷取消消息M476，使用作為SIP消息的MESSAGE消息。該 MESSAGE消息由SIP消息處理部162生成。此外，該MESSAGE消息 的正文部具有與圖8所示的權限判斷取消消息正文部M145 — l相同的結 構。
權限判斷AS32從S—CSCF16接收到權限判斷取消消息M476時， 權限判斷處理部323結束處於處理中的權限判斷處理。接著，SIP消息處 理部322生成權限判斷取消響應消息M477,向S—CSCF16發送。作為 權限判斷取消響應消息M477,使用作為SIP消息的200OK消息。並且， 該2O0OK消息的正文部具有與圖8所示的權限判斷取消響應消息正文部 M146—l相同的結構。
另一方面，I一CSCF15基於從S—CSCF16接收到的SIP錯誤響應消 息M475生成SIP錯誤響應消息M478,向網絡0上的S—CSCF13發送。
S—CSCF13從網絡1上的I一CSCF15接收到SIP錯誤響應消息 M478時，SIP消息處理部132生成作為對該SIP錯誤響應消息的響應的 ACK消息M479，向網絡1上的S — CSCF16發送。
接著，S — CSCF13由SIP消息處理部132基於SIP錯誤響應消息 M478生成SIP錯誤響應消息M480，向P—CSCFll發送。
接著，S—CSCF13向密鑰生成AS31發送密鑰生成取消消息M481。 作為密鑰生成取消消息M481，使用作為SIP消息的MESSAGE消息。該 MESSAGE消息由SIP消息處理部132生成。此外，該MESSAGE消息 的正文部具有與圖8所示的密鑰生成取消消息正文部M124—l相同的結 構。
密鑰生成AS31從S—CSCF13接收到密鑰生成取消消息M481時， 密鑰生成處理部313結束處於處理中的密鑰生成處理。接著，SIP消息處 理部312生成密鑰生成取消響應消息M482，向S—CSCF13發送。作為 密鑰生成取消響應消息M482，使用作為SIP消息的200OK消息。此外， 該200OK消息的正文部具有與圖8所示的密鑰生成取消響應消息正文部 M125—l相同的結構。
另一方面，P — CSCFll從S — CSCF13接收到SIP錯誤響應消息 M480時，SIP消息處理部112基於該SIP錯誤響應消息生成SIP錯誤響 應消息M483，向用戶側通信裝置41發送。
用戶側通信裝置41從P—CSCFll接收到SIP錯誤響應消息M483 時，SIP消息處理部412生成作為對該SIP錯誤響應消息的響應的ACK 消息M楊，向P—CSCFll發送。
P—CSCFll從用戶側通信裝置41接收到ACK消息M484時，SIP 消息處理部112基於該ACK消息生成ACK消息M485，向S—CSCF13 發送。
在該實施例中，在執行權限判斷處理或密鑰生成處理的期間，S_ CSCF16及S-CSCF13也可以接收由P—CSCF或I一CSCF傳輸的來自 服務側通信裝置42的SIP錯誤響應消息。該SIP錯誤響應消息經由P_ CSCFll，送到用戶側通信裝置41處。因此，具有用戶側通信裝置41比 過去的步驟早知道服務側通信裝置42處於不能提供服務的狀態的情況的 效果。
此外，在本實施例中，權限判斷AS32關於用戶用於享受由服務側通 信裝置42提供的服務的權限進行了判斷，但是，作為該例子的變形例也可 以是如下結構在權限判斷AS32中關於用戶側通信裝置用於與服務側通 信裝置確立對話的權限進行判斷，由各服務側通信裝置進行用戶用於享受 在該對話上提供的服務的權限判斷。
權利要求
1. 一種數據通信系統，其特徵在於，包括第一通信裝置；第二通信裝置；對話管理伺服器，管理用於上述多個通信裝置進行數據通信的對話；以及功能提供伺服器，提供上述對話確立所需的功能，上述對話管理伺服器在接收到以上述第一通信裝置為通信源、請求與上述第二通信裝置的對話確立的請求消息時，並行進行傳輸上述請求消息並等待響應的處理、和向功能提供伺服器委託上述對話確立所需的處理並等待響應的處理。
2. 如權利要求1所述的數據通信系統，其特徵在於， 向上述功能提供伺服器委託的處理包括判斷上述第一通信裝置是否具有為了利用所確立的上述對話享受上述 第二通信裝置提供的服務所需的權限的處理。
3. 如權利要求1所述的數據通信系統，其特徵在於， 向上述功能提供伺服器委託的處理包括利用上述第一通信裝置與上述第二通信裝置的上述對話而進行的通信 的加密所需的加密密鑰的生成處理。
4. 如權利要求1所述的數據通信系統，其特徵在於， 上述對話管理伺服器從上述第二通信裝置接收到與所發送的上述請求消息對應的響應消息之前、從上述功能提供伺服器接收到拒絕從上述第二 通信裝置向上述第一通信裝置的服務提供的消息時，發送向上述第二通信裝置發送了的上述對話確立請求的取消消息、及/ 或取消在向上述功能提供伺服器委託之後還未接收到結果的處理的取消消
5. 如權利要求1所述的數據通信系統，其特徵在於，上述對話管理伺服器從上述第二通信裝置接收到與傳輸的上述請求消 息對應的可提供服務消息時，向上述第二通信裝置發送與上述可提供服務 消息對應的響應消息，在發送該響應消息後，等待接收與在向上述功能提 供伺服器委託之後還未接收到結果的處理對應的結果。
6. 如權利要求1所述的數據通信系統，其特徵在於，上述對話管理伺服器從上述功能提供伺服器作為與上述委託的處理對 應的上述結果、接收到許可從上述第二通信裝置向上述第一通信裝置的服 務提供的消息時，向上述功能提供伺服器發送與許可上述服務提供的消息 對應的響應消息，在發送該響應消息後，等待接收與向上述功能提供服務 器委託的處理、及/或向上述第二通信裝置發送的上述請求消息對應的結果。
7. 如權利要求6所述的數據通信系統，其特徵在於，上述對話管理伺服器從上述第二通信裝置及委託處理的所有上述功能 提供伺服器接收到響應時，以上述第二通信裝置及上述第一通信裝置為目 的地，發送在從上述功能提供伺服器接收的消息中包含的信息。
8. 如權利要求5所述的數據通信系統，其特徵在於， 上述對話管理伺服器從上述功能提供伺服器作為與上述委託的處理對應的上述結果、接收到拒絕從上述第二通信裝置向上述第一通信裝置的服 務提供的消息時，發送基於向上述第二通信裝置傳輸的上述請求消息的對 話確立請求的取消消息、及/或向其它上述功能提供伺服器委託的處理的取 消消息。
9. 如權利要求6所述的數據通信系統，其特徵在於， 上述對話管理伺服器從上述第二通信裝置及委託處理的所有上述功能提供伺服器接收到響應時，向上述第一通信裝置發送與請求對話確立的上 述請求消息對應的響應消息。
10. 如權利要求1所述的數據通信系統，其特徵在於，上述對話管理伺服器從上述第二通信裝置接收到與傳輸的上述請求消 息對應的服務提供拒絕消息時，向該功能提供伺服器發送向上述功能提供 伺服器委託的處理的取消消息。
11. 如權利要求8所述的數據通信系統，其特徵在於，所謂上述對話管理伺服器向上述第二通信裝置發送的對話確立請求的 取消消息，包括用於明示對話確立處理在處理的中途中斷的信息。
全文摘要
本發明涉及的數據通信系統，提供一種對話確立的高速化方法及系統，對話管理伺服器在對話的確立所需的各功能(可否提供服務的判斷、或對話密鑰的生成等)的處理需要較長時間時，縮短到對話確立為止所需的時間。對話管理伺服器設置並行進行向對話確立所需的各功能(可否提供服務的判斷、或對話密鑰的生成等)的處理請求、和通過要確立對話的通信裝置或其它對話管理伺服器而發送的通信消息的傳輸處理的手段。
文檔編號H04L29/08GK101388890SQ200810212579
公開日2009年3月18日 申請日期2008年9月5日 優先權日2007年9月10日
發明者入部真一, 山本暖, 矢戶晃史, 藤城孝宏, 鍛忠司 申請人:株式會社日立製作所