仲介サーバ、通信仲介方法、通信仲介プログラム、および通信システム
【課題】低負荷で通信装置を認証して通信を仲介する仲介サーバを提供する。
【解決手段】認証サーバ２００に対する通信の開始を要求する通信要求メッセージをＳＩＰクライアント４００から受信する通信要求受信部１０２と、受信した通信要求メッセージに対応して、ＳＩＰクライアント４００と認証サーバ２００との間の通信を仲介する通信仲介部１０３と、認証サーバ２００からＳＩＰクライアント４００の認証状態を受信する認証状態受信部１０４と、受信した認証状態に基づいてＳＩＰクライアント４００の認証の可否を判断する判断部１０５と、を備えた。
【解決手段】認証サーバ２００に対する通信の開始を要求する通信要求メッセージをＳＩＰクライアント４００から受信する通信要求受信部１０２と、受信した通信要求メッセージに対応して、ＳＩＰクライアント４００と認証サーバ２００との間の通信を仲介する通信仲介部１０３と、認証サーバ２００からＳＩＰクライアント４００の認証状態を受信する認証状態受信部１０４と、受信した認証状態に基づいてＳＩＰクライアント４００の認証の可否を判断する判断部１０５と、を備えた。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、通信端末間および通信端末と認証サーバとの間の通信を仲介する仲介サーバ、通信仲介方法、通信仲介プログラム、および通信システムに関するものである。
【背景技術】
【０００２】
近年、通信装置間に介在し通信を制御・中継するシグナリング手順としてＳＩＰ（Session Initiation Protocol）が広く知られている。従来のＳＩＰの認証方式としては、発信装置が送信メッセージとともにパスワードなどの認証情報を送信し、着信装置が送信メッセージとともに受信した認証情報に基づき発信装置に対して認証を実施する方法が一般的である。
【０００３】
例えば、発信装置であるＳＩＰクライアントは、着信装置であるＳＩＰプロキシに対し登録（ＲＥＧＩＳＴＥＲ）メッセージを送信する際、発信装置が正規のＳＩＰクライアントであることを担保する認証情報を合わせて送信する。これに対しＳＩＰプロキシは、まず登録メッセージ上で受信した認証データに基づく認証を行い、正規のＳＩＰクライアントであることを確認し、次に認証の可否により当該登録メッセージで要求される登録処理の可否を決定する。
【０００４】
すなわち、従来のＳＩＰ認証方式は、発信装置からあるメッセージで要求される着信装置における処理の可否を、着信装置で確認することを目的としたものである。従って、発信装置は該当するメッセージと同時に認証情報を送信する必要があり、認証情報は発信装置と着信装置（例えばＳＩＰクライアントとＳＩＰプロキシ）の通信で該当するメッセージとともに交換される。このため、認証情報は通信メッセージや通信処理を妨げないものに限定される。また、認証情報のデータ量が増加すると、発信装置と着信装置との間の通信データ量も増加する。
【０００５】
一方、認証状態が確立されると、明示的な要求で解除されるか、有効期限を経過するまで、その認証状態が持続する。これは、そもそもメッセージで要求される処理についての可否を判定することが認証の目的であることに起因する。このため、メッセージで要求された処理の有効性が認証状態の有効性と等価となる。例えば、登録処理の場合は、ある登録が有効な間は認証状態も有効であるとみなされる。
【０００６】
すなわち、通信装置からのメッセージに対し、通信装置の認証状態に基づき挙動を変化させるＳＩＰプロキシなどの通信仲介サーバは、実際には通信装置の登録状態に基づき挙動を変化させる必要がある。言い換えれば、認証サーバと通信仲介サーバとが、通信装置の認証状態の変化を検知できないことを意味する。このため、例えばＳＩＰプロキシがＳＩＰクライアントの認証状態の変化を即座に検知する場合、発信装置であるＳＩＰクライアントが登録の処理を頻繁に繰り返す必要が生じる。
【０００７】
通信装置の認証状態の変化を検知する方法として、特許文献１では、通信仲介サーバから定期的に通信装置の接続状態を確認することにより、認証状態を適切な契機で無効化する技術が提案されている。
【０００８】
【特許文献１】特開２００５−９９９８０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、特許文献１の方法では、ＳＩＰクライアントの認証状態の変化を即座に検知する場合に、ＳＩＰプロキシの処理負荷が大きくなるという問題があった。すなわち、ＳＩＰプロキシは、ＳＩＰクライアントの接続状態の確認のためのメッセージ送信を頻繁に繰り返す必要があった。
【００１０】
さらに、セキュリティ強化等のため生体情報や画像情報を用いた認証を行う場合は、認証に用いる認証情報のデータ量が大容量となるため、確認頻度の増加だけでなく通信データ量の増加により、ＳＩＰプロキシの処理負荷がさらに増大するという問題も生じる。
【００１１】
本発明は、上記に鑑みてなされたものであって、認証に用いる認証情報の情報量や認証頻度に依存することなく、低負荷で通信装置を認証して通信を仲介することができる仲介サーバ、通信仲介方法、および通信仲介プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
上述した課題を解決し、目的を達成するために、本発明は、通信端末と前記通信端末の認証を行う認証サーバとの間の通信を仲介する仲介サーバであって、前記認証サーバに対する通信の開始を要求する通信要求メッセージを前記通信端末から受信する通信要求受信部と、受信した前記通信要求メッセージに対応して、前記通信端末と前記認証サーバとの間の通信を仲介する通信仲介部と、前記認証サーバから前記通信端末に対する認証状態を受信する認証状態受信部と、受信した前記認証状態に基づいて前記通信端末の認証の可否を判断する判断部と、を備えたことを特徴とする。
【００１３】
また、本発明は、上記装置を実行することができる通信仲介方法および通信仲介プログラムである。
【００１４】
また、本発明は、通信端末の認証を行う認証サーバと、前記通信端末とネットワークを介して接続され、前記通信端末と前記認証サーバとの間の通信を仲介する仲介サーバとを備えた通信システムであって、前記仲介サーバは、前記認証サーバに対する通信の開始を要求する通信要求メッセージを前記通信端末から受信する通信要求受信部と、受信した前記通信要求メッセージに対応して、前記通信端末と前記認証サーバとの間の通信を仲介する通信仲介部と、前記認証サーバから前記通信端末に対する認証状態を受信する認証状態受信部と、受信した前記認証状態に基づいて前記通信端末の認証の可否を判断する判断部と、を備え、前記認証サーバは、前記通信端末から認証に用いる認証情報を受信する認証情報受信部と、受信した前記認証情報を用いて前記通信端末の認証を行う認証部と、前記認証状態を前記仲介サーバに送信する認証状態送信部と、を備えたこと、を特徴とする。
【発明の効果】
【００１５】
本発明によれば、認証サーバから通知された認証結果によって通信装置の認証状態を管理することができる。このため、認証に用いる認証情報の情報量や認証頻度に依存することなく、低負荷で通信装置を認証して通信を仲介することができるという効果を奏する。
【発明を実施するための最良の形態】
【００１６】
以下に添付図面を参照して、この発明にかかる仲介サーバ、通信仲介方法、通信仲介プログラム、および通信システムの最良な実施の形態を詳細に説明する。
【００１７】
（第１の実施の形態）
第１の実施の形態にかかる仲介サーバは、ＳＩＰのＩＮＶＩＴＥリクエストによって確立された通信を用いて認証サーバと通信端末との間で任意の方法および頻度で実行された認証処理の結果を当該認証サーバから受信し、通信端末の認証状態を判断するものである。
【００１８】
図１は、第１の実施の形態にかかる通信システムの特徴を説明するための説明図である。同図に示すように、通信システム１０は、仲介サーバであるＳＩＰプロキシ１００と、認証サーバ２００と、通信端末であるＳＩＰクライアント４００とを備えている。なお、認証サーバ２００およびＳＩＰクライアント４００は複数備えることができる。また、各装置は、インターネットやＬＡＮ（Local Area Network）などのネットワークにより接続されている。
【００１９】
同図に示すように、本実施の形態では、ＳＩＰクライアント４００が登録要求メッセージ（ＲＥＧＩＳＴＥＲ）を送信してＳＩＰプロキシ１００に自身を登録した後、ＩＮＶＩＴＥリクエストによって認証サーバ２００との間で確立されたデータチャネルによって認証情報の通信が行われる。また、ＳＩＰプロキシ１００は、ＩＮＶＩＴＥリクエストで確立されたダイアログを用いて、認証サーバ２００からＳＩＰクライアント４００の認証状態を受信する。
【００２０】
これにより、ＳＩＰクライアント４００からＳＩＰプロキシ１００に対して認証情報を送信してＳＩＰプロキシ１００で認証を実行する必要がない。また、ＩＮＶＩＴＥリクエストで確立された通信を用いてＳＩＰクライアント４００と認証サーバ２００との間で認証情報を通信して認証を行い、ＳＩＰプロキシ１００に対しては認証サーバ２００から認証状態のみを通知すればよいため、ＳＩＰプロキシ１００の処理負荷を低減することができる。
【００２１】
図２は、第１の実施の形態にかかる通信システム１０の構成を示すブロック図である。図１で説明したように、通信システム１０は、仲介サーバであるＳＩＰプロキシ１００と、認証サーバ２００と、ＳＩＰクライアント４００ａ、４００ｂとが、ネットワーク３００を介して接続された構成となっている。
【００２２】
ＳＩＰクライアント４００ａ、４００ｂ（以下、ＳＩＰクライアント４００という。）は、ＳＩＰのクライアント機能（ＳＩＰ ＵＡ（ユーザエージェント））を有する装置である。また、ＳＩＰクライアント４００は、自装置の認証を行うために、キーボード、カメラ、マイク、センサ等を用いて認証情報を取得し、認証サーバ２００に送信する。
【００２３】
認証サーバ２００は、ＳＩＰクライアント４００の認証を行うものである。本実施の形態では、ＩＮＶＩＴＥリクエストによりＳＩＰプロキシ１００を介してＳＩＰクライアント４００との間で確立されたデータチャネルを用いて、ＳＩＰクライアント４００から認証情報を受け取り、認証処理を行う。
【００２４】
図２に示すように、認証サーバ２００は、応答部２０１と、認証情報受信部２０２と、認証部２０３と、認証状態送信部２０４と、を備えている。
【００２５】
応答部２０１は、ＳＩＰプロキシ１００を介してＳＩＰクライアント４００から通信の確立を要求する通信要求メッセージであるＩＮＶＩＴＥリクエストに対する応答を返信するものである。
【００２６】
認証情報受信部２０２は、ＳＩＰクライアント４００から認証に利用する認証情報を受信するものである。認証情報受信部２０２は、後述する認証部２０３が採用する認証方法によって、認証情報として、文字情報、画像情報、音声情報、指紋等の生体情報などをＳＩＰクライアント４００から受信する。
【００２７】
認証部２０３は、認証情報受信部２０２が受信した認証情報を用いてＳＩＰクライアント４００の認証処理を行うものである。認証部２０３による認証方法としては、ＩＤとパスワードを利用する方法、生体情報を利用する方法などの従来から用いられているあらゆる認証方法を適用できる。
【００２８】
認証状態送信部２０４は、認証部２０３による認証結果を参照してＳＩＰクライアント４００の認証状態をＳＩＰプロキシ１００に送信するものである。なお、認証状態送信部２０４は、ＳＩＰクライアント４００に認証状態を送信するように構成してもよい。
【００２９】
なお、認証サーバ２００は、任意の頻度で認証情報を受信し、認証処理を行うように構成することができる。例えば、認証サーバ２００は、ＳＩＰクライアント４００を連続認証するように構成してもよい。
【００３０】
ここで、連続認証とは、認証サーバ２００とＳＩＰクライアント４００との間で、例えば、所定の時間間隔、あるいは任意の時間間隔で認証を繰り返す認証方式をいう。より具体的には、ＳＩＰクライアント４００が音声画像や生体情報などを認証サーバ２００に送り続け、受信した認証サーバ２００で所定あるいは任意の時間間隔で認証する認証方式をいう。認証の可否は、都度あるいは所定あるいは任意の時間間隔で認証サーバ２００からＳＩＰクライアント４００に直接送り返されてもよいし、ＳＩＰプロキシ１００を経由して通知されてもよい。
【００３１】
また、認証サーバ２００は、ＳＩＰクライアント４００に対して認証情報を要求するように構成してもよい。また、ＳＩＰクライアント４００と認証サーバ２００との間の通信を暗号化するように構成してもよい。この際の暗号化方法としては従来から用いられているあらゆる方法を適用できる。
【００３２】
ＳＩＰプロキシ１００は、認証サーバ２００とＳＩＰクライアント４００との間、または、複数のＳＩＰクライアント４００間の通信を仲介する仲介サーバであり、通信仲介のためのプロトコルとしてＳＩＰを用いるものである。ＳＩＰプロキシ１００は、記憶部１２０と、登録要求受信部１０１と、通信要求受信部１０２と、通信仲介部１０３と、認証状態受信部１０４と、判断部１０５と、通信切断部１０６と、通知受信部１０７と、通知部１０８と、を備えている。
【００３３】
記憶部１２０は、仲介サーバによる通信の仲介処理で用いる各種情報を記憶するものであり、ＨＤＤ（Hard Disk Drive）、光ディスク、メモリカード、ＲＡＭ（Random Access Memory）などの一般的に利用されているあらゆる記憶媒体により構成することができる。また、記憶部１２０は、各種情報を記憶するテーブルとして、登録情報テーブル１２１と、接続情報テーブル１２２と、認証状態テーブル１２３とを含んでいる。
【００３４】
登録情報テーブル１２１は、ＳＩＰプロキシ１００に登録済みのＳＩＰクライアント４００に関する情報を格納するものである。図３は、登録情報テーブル１２１のデータ構造の一例を示す説明図である。
【００３５】
同図に示すように、登録情報テーブル１２１は、登録したＳＩＰクライアント４００のＳＩＰ ＵＲＩ（Uniform Resource Identifier）と、登録したＳＩＰクライアント４００の名称であるホスト名と、利用するポート番号とを対応づけた登録情報を格納している。
【００３６】
接続情報テーブル１２２は、ＳＩＰクライアント４００間、またはＳＩＰクライアント４００と認証サーバ２００との間で確立した通信に関する接続情報を記憶するものである。図４は、接続情報テーブル１２２のデータ構造の一例を示す説明図である。
【００３７】
同図に示すように、接続情報テーブル１２２は、各ＳＩＰクライアント４００のＳＩＰ ＵＲＩであるＳＩＰ ＵＲＩ１およびＳＩＰ ＵＲＩ２と、ポート番号１およびポート番号２と、確立した通信の有効期限とを対応づけて格納している。
【００３８】
認証状態テーブル１２３は、登録したＳＩＰクライアント４００ごとに、認証サーバ２００による認証状態を格納するものである。図５は、認証状態テーブル１２３のデータ構造の一例を示す説明図である。
【００３９】
同図に示すように、認証状態テーブル１２３は、ＳＩＰ ＵＲＩと、認証状態と、を対応づけて格納している。認証状態には、認証サーバ２００により認証された状態を表す「有効」、または、認証されていない状態を表す「無効」のいずれかが設定される。
【００４０】
認証状態は、ＳＩＰクライアント４００が登録されたときには「無効」が設定され、認証サーバ２００から認証成功の通知を受けたときに「有効」に設定される。また、その後、認証サーバ２００から認証に失敗した旨の通知を受けたときに「無効」に設定される。なお、接続の有効期限が切れた場合などのようにＳＩＰプロキシ１００内で認証状態を判定して「無効」に設定することもできる。
【００４１】
登録要求受信部１０１は、ＳＩＰクライアント４００から送信された登録要求メッセージ（ＲＥＧＩＳＴＥＲリクエスト）を受信するものである。ＲＥＧＩＳＴＥＲリクエストの目的は、ＳＩＰクライアント４００を登録情報テーブル１２１に登録し、ＳＩＰクライアント４００とＳＩＰプロキシ１００との間でその後の通信を行うための接続状態を確立することである。なお、ＲＥＧＩＳＴＥＲリクエストに対する認証を目的として、通常のＳＩＰと同様にＲＥＧＩＳＴＥＲリクエストにダイジェスト認証を伴うように構成してもよい。
【００４２】
通信要求受信部１０２は、ＳＩＰクライアント４００から認証サーバ２００に対する通信の確立を要求するＩＮＶＩＴＥリクエストを受信するものである。
【００４３】
通信仲介部１０３は、受信したＩＮＶＩＴＥリクエストを認証サーバ２００に送信し、認証サーバ２００から返信された応答に従い、ＳＩＰクライアント４００と認証サーバ２００との間の通信を確立するものである。また、通信仲介部１０３は、通信を確立した場合、接続情報テーブル１２２に確立した通信に関する接続情報を記憶する。
【００４４】
認証状態受信部１０４は、通信を確立した認証サーバ２００から、ＳＩＰクライアント４００の認証状態を受信するものである。認証サーバ２００は、認証が成功した場合に、ＩＮＶＩＴＥリクエストをＳＩＰプロキシ１００に送信する。このため、認証状態受信部１０４は、ＩＮＶＩＴＥリクエストを、認証成功を表す認証状態として認証サーバ２００から受信する。また、認証サーバ２００は、認証が失敗した場合に、ＢＹＥリクエストをＳＩＰプロキシ１００に送信するため、認証状態受信部１０４は、ＢＹＥリクエストを、認証失敗を表す認証状態として受信する。
【００４５】
判断部１０５は、ＳＩＰクライアント４００から他のクライアント４００等に対するＩＮＶＩＴＥリクエストなどの通知メッセージを受信した場合に、認証状態テーブル１２３に保存した認証状態を参照してＳＩＰクライアント４００の認証可否を判断するものである。
【００４６】
通信切断部１０６は、判断部１０５によりＳＩＰクライアント４００の認証が無効であると判断された場合に、当該ＳＩＰクライアント４００に関して確立されている通信を切断するものである。
【００４７】
通知受信部１０７は、認証サーバ２００による認証後に、認証されたＳＩＰクライアント４００から他のＳＩＰクライアント４００等に対するＩＮＶＩＴＥリクエストなどの通信に関する通知メッセージを受信するものである。通知受信部１０７は、通知メッセージとして、ＩＮＶＩＴＥの他に、ＳＵＢＳＣＲＩＢＥ、ＭＥＳＳＡＧＥ、ＢＹＥなどのＳＩＰで扱われるあらゆるメッセージを受信することができる。
【００４８】
通知部１０８は、ＳＩＰクライアント４００に対する各種通知メッセージを送信するものである（第１通知部）。例えば、通知部１０８は、通知受信部１０７が受信した通知メッセージを、通知先として指定された他のＳＩＰクライアント４００に対して通知する。また、通知部１０８は、認証サーバ２００から受信した認証状態をＳＩＰクライアント４００に通知するように構成してもよい（第２通知部）。さらに、通知部１０８は、ＳＩＰクライアント４００を登録した後、登録したＳＩＰクライアント４００に対して、利用可能な認証サーバ２００に関する情報を通知するように構成してもよい（第３通知部）。
【００４９】
次に、このように構成された第１の実施の形態にかかるＳＩＰプロキシ１００による通信仲介処理について説明する。図６は、第１の実施の形態における通信仲介処理の全体の流れを示すフローチャートである。
【００５０】
まず、ＳＩＰクライアント４００は、登録要求メッセージとしてＲＥＧＩＳＴＥＲリクエストをＳＩＰプロキシ１００に対して送信する（ステップＳ６０１）。
【００５１】
次に、ＳＩＰプロキシ１００の登録要求受信部１０１は、登録要求メッセージを受信し、ＳＩＰクライアント４００を登録情報テーブル１２１に登録する（ステップＳ６０２）。また、登録要求受信部１０１は、登録したＳＩＰクライアント４００の認証状態を同時に認証状態テーブル１２３に格納してもよいが、この時点では認証状態は「無効」に設定する。
【００５２】
なお、本実施の形態では、通常のＳＩＰと異なり、ＲＥＧＩＳＴＥＲリクエストが成功してＳＩＰクライアント４００を登録した後は、ＳＩＰプロキシ１００がＳＩＰクライアント４００から受け付ける通信状態の制御要求は、ＳＩＰクライアント４００から認証サーバ２００に対するものに限定する。同時に、他のＳＩＰクライアント４００等からＳＩＰクライアント４００に対する接続状態の制御要求を受け付けない。他の装置との通信を制御する前に、認証サーバ２００により認証を行いその結果の通知を受ける必要があるためである。
【００５３】
次に、通知部１０８が、利用可能な認証サーバ２００の情報をＳＩＰクライアント４００に送信する（ステップＳ６０３）。なお、ＳＩＰクライアント４００が事前に認証サーバ２００の情報を入手している場合には、本ステップを省略してもよい。
【００５４】
次に、ＳＩＰクライアント４００が、認証サーバ２００との間の通信を確立する通信要求メッセージとしてＩＮＶＩＴＥリクエストをＳＩＰプロキシ１００に対して送信する（ステップＳ６０４）。
【００５５】
次に、ＳＩＰプロキシ１００の通信要求受信部１０２は、ＳＩＰクライアント４００からＩＮＶＩＴＥリクエストを受信し、認証サーバ２００に対して転送する（ステップＳ６０５）。
【００５６】
認証サーバ２００の応答部２０１は、ＩＮＶＩＴＥリクエストを受信し、当該ＩＮＶＩＴＥリクエストに対する応答をＳＩＰプロキシ１００に返信する（ステップＳ６０６）。ここでは、通信の確立を認可する応答を送信したものとする。
【００５７】
次に、ＳＩＰプロキシ１００の通信仲介部１０３は、ＳＩＰクライアント４００と認証サーバ２００との通信を確立し、確立した通信の接続状態、すなわち、ＩＮＶＩＴＥリクエストにより確立されたダイアログに関する接続情報を接続情報テーブル１２２に登録する（ステップＳ６０７）。このダイアログにより、ＳＩＰクライアント４００と認証サーバ２００が直接通信できるように構成される。
【００５８】
次に、通知部１０８は、通信確立が成功したことをＳＩＰクライアント４００に通知する（ステップＳ６０８）。
【００５９】
次に、このようにして確立されたダイアログを用いて、ＳＩＰクライアント４００と認証サーバ２００との直接通信により、ＳＩＰクライアント４００は認証サーバ２００に対して認証情報を送信する（ステップＳ６０９）。
【００６０】
認証サーバ２００の認証情報受信部２０２は、ＳＩＰクライアント４００から認証情報を受信し（ステップＳ６１０）、認証部２０３が、受信した認証情報を用いて認証処理を実行する（ステップＳ６１１）。次に、認証状態送信部２０４は、認証状態をＳＩＰクライアント４００に送信する（ステップＳ６１２）。また、認証状態送信部２０４は、認証状態をＳＩＰプロキシ１００に送信する（ステップＳ６１３）。
【００６１】
この際、認証状態送信部２０４は、認証が成功したときは、ダイアログを更新するためのＩＮＶＩＴＥリクエスト（ｒｅ−ＩＮＶＩＴＥリクエスト）を送信する。また、認証状態送信部２０４は、認証が失敗したときは、ＢＹＥリクエストをＳＩＰプロキシ１００に送信する。
【００６２】
ＳＩＰプロキシ１００の認証状態受信部１０４は、認証状態を受信し、認証可否に応じて認証状態として「有効」または「無効」を認証状態テーブル１２３に保存する（ステップＳ６１４）。
【００６３】
なお、同図には図示していないが、認証が失敗した場合、通信切断部１０６が、接続情報テーブル１２２から認証が失敗したＳＩＰクライアント４００に関する接続情報を削除することにより、ダイアログを破棄する。これにより、当該ＳＩＰクライアント４００からの通信または当該ＳＩＰクライアント４００に対する通信が制限されることになる。また、ＳＩＰプロキシ１００は、受信した認証状態や、それに基づく認証状態をＳＩＰクライアント４００に対して送信するように構成してもよい。
【００６４】
なお、ステップＳ６０９からステップＳ６１４までの処理は、この後、任意の間隔、頻度で繰り返し実行される。また、例えば、認証サーバ２００による認証状態の通知は、ダイアログが確立された直後の最初の認証時のほか、認証サーバ２００に設定された任意の間隔、認証サーバ２００が認証状態の変化を検出した時点などあらゆるタイミングで実行可能である。また、認証サーバ２００で設定した一定時間の間にＳＩＰクライアント４００から認証情報を取得できないとき、認証サーバ２００は認証失敗時と同様の動作を行うように構成してもよい。
【００６５】
また、認証状態の通知方法として、成功時にＩＮＶＩＴＥリクエストを送信し、失敗時にＢＹＥリクエストを送信する方法が最も通信量を削減できるが、代わりにＭＥＳＳＡＧＥやＮＯＴＩＦＹ等により、ＳＩＰプロキシ１００やＳＩＰクライアント４００に対して認証状態を通知するように構成してもよい。
【００６６】
このように、本実施の形態では、ＳＩＰを用いた通信の確立時に、通信の確立を仲介する仲介サーバであるＳＩＰプロキシ１００内で認証処理を行わず、確立した通信を介して送信した認証情報によって認証サーバ２００で認証処理を行い、その結果をＳＩＰプロキシ１００に通知することによりＳＩＰクライアント４００の認証状態を判定することができる。ＳＩＰプロキシ１００は認証サーバ２００から認証状態に関する情報を受信するだけであるため、認証サーバ２００で実行される認証処理の実現方法に関わらず、ＳＩＰプロキシ１００の処理負荷を低減することができる。
【００６７】
次に、認証後に、ＳＩＰクライアント４００間で接続状態の制御要求を受信した場合の処理について説明する。図７は、第１の実施の形態における制御要求仲介処理の全体の流れを示すフローチャートである。なお、以下では、制御要求を送信するＳＩＰクライアント４００をＳＩＰクライアント４００ａとし、制御要求を受信するＳＩＰクライアント４００をＳＩＰクライアント４００ｂとする。
【００６８】
まず、ＳＩＰクライアント４００ａは、ＳＩＰクライアント４００ｂに対する接続状態の制御を要求する通知メッセージをＳＩＰプロキシ１００に対して送信する（ステップＳ７０１）。通知メッセージとは、ＩＮＶＩＴＥ、ＳＵＢＳＣＲＩＢＥ、ＭＥＳＳＡＧＥ、ＢＹＥ等のＳＩＰのシグナリングリクエストをいう。
【００６９】
次に、ＳＩＰプロキシ１００の通知受信部１０７は、通知メッセージを受信する（ステップＳ７０２）。次に、判断部１０５は、接続情報テーブル１２２および認証状態テーブル１２３を参照して、ＳＩＰクライアント４００ａ、４００ｂの接続状態と認証状態を確認する（ステップＳ７０３）。
【００７０】
具体的には、判断部１０５は、ＳＩＰクライアント４００ａとＳＩＰクライアント４００ｂとの間の接続情報が接続情報テーブル１２２に記憶されているか否かにより、両者が接続された状態であるか否かを確認する。また、判断部１０５は、ＳＩＰクライアント４００ａおよび４００ｂのＳＩＰ ＵＲＩに対応する認証状態をそれぞれ認証状態テーブル１２３から取得し、認証状態が共に「有効」であるかを確認する。
【００７１】
次に、判断部１０５は、両者が接続されており、かつ、ＳＩＰクライアント４００ａおよび４００ｂの認証状態が「有効」であるか否かを判断する（ステップＳ７０４）。両者が接続されており、かつ、認証状態がそれぞれ「有効」である場合（ステップＳ７０４：ＹＥＳ）、通知部１０８は、ＳＩＰクライアント４００ｂに対して通知メッセージを中継する（ステップＳ７０６）。
【００７２】
ＳＩＰクライアント４００ｂは、中継された通知メッセージを受信し（ステップＳ７０７）、受信した通知メッセージに対する応答をＳＩＰクライアント４００ａに対して送信する（ステップＳ７０８）。
【００７３】
ステップＳ７０４で、両者が接続されており、かつ、認証状態が「有効」であると判断された場合以外は（ステップＳ７０４：ＮＯ）、通知部１０８は、通知メッセージの中継を拒否する応答をＳＩＰクライアント４００ａに対して送信する（ステップＳ７０５）。
【００７４】
ＳＩＰクライアント４００ａは、ＳＩＰプロキシ１００またはＳＩＰクライアント４００ｂからの応答を受信する（ステップＳ７０９）。
【００７５】
ただし、ＳＩＰクライアント４００ｂが、例えば他のドメインで運用されるなど、ＳＩＰプロキシ１００の管理外にある場合は、ＳＩＰクライアント４００ｂに関する認証の確認処理は、ＳＩＰクライアント４００ｂが接続されているＳＩＰプロキシ（ＳＩＰプロキシ１００以外のプロキシ）によって実施されることも考えられる。この場合にＳＩＰプロキシ１００とＳＩＰクライアント４００ｂが接続されるＳＩＰプロキシとの間で認証情報を交換することも考えられる。この場合の認証情報の交換方法としては、従来から用いられているあらゆる技術を適用できる。
【００７６】
このように、一旦ＳＩＰクライアント４００の認証状態が有効となると、ＳＩＰプロキシ１００は、認証サーバ２００とＳＩＰクライアント４００との通信を確立したダイアログの存在が確認できる限り、原則としてＳＩＰクライアント４００の認証状態は有効であると判定することができる。
【００７７】
この結果、認証サーバ２００がＳＩＰクライアント４００を正しく認証し、認証状態をＳＩＰプロキシ１００に正しく通知することが保証されていれば、ＳＩＰクライアント４００とＳＩＰプロキシ１００との間で認証に関わる通信を全く行わないとしても、ＳＩＰプロキシ１００は正しくＳＩＰクライアント４００の認証を行うことが可能となる。
【００７８】
また、認証が無効になった場合、認証サーバ２００が無効になった時点で即時にＳＩＰプロキシ１００に対して認証状態を通知すれば、ＳＩＰプロキシ１００がＳＩＰクライアント４００の認証状態の変化を即座に検知することも可能となる。
【００７９】
また、認証情報は認証サーバ２００とＳＩＰクライアント４００との間でのみ送受信されるため、画像情報、生体情報などの情報量の大きい認証情報による認証技術を用いた場合であっても、ＳＩＰプロキシ１００の負荷に影響を与えることがない。
【００８０】
このように、第１の実施の形態にかかる仲介サーバでは、ＳＩＰのＩＮＶＩＴＥリクエストによって確立された通信を用いて実行された認証処理の結果を認証サーバから受信し、通信端末の認証状態を判断することができる。このため、認証に用いる認証情報の情報量や認証頻度に依存することなく、低負荷で通信装置を認証して通信を仲介することができる。
【００８１】
また、認証状態を無効にすべき時点で即座に無効とするにはリアルタイムな連続認証が必要であるが、従来の方法では、ＳＩＰプロキシがＳＩＰクライアントに対して連続して認証を試みる必要があった。これに対し、本実施の形態では、認証サーバが即時に認証状態をＳＩＰプロキシに対して送信するように構成すれば、ＳＩＰプロキシの処理負荷を増大させることなく、リアルタイム認証が可能となる。
【００８２】
一般に、ＳＩＰプロキシは、電子メールサーバと同等の規模で多数の利用者を収容する装置であり、認証状態にあるＳＩＰクライアントからの要求を仲介し通信の制御・中継（シグナリング）などを処理するものである。このため、処理の負荷を軽減する規模運用性（スケーラビリティ）に重点を置いた設計が必要であり、認証情報は軽量としかつ通信頻度は最小化することが求められる。
【００８３】
これは、ＳＩＰに限らず、通信装置間に介在し通信を制御・中継するシグナリングを行う通信仲介サーバと通信装置の通信方式でも同様である。ところが、従来の手法では、通信仲介サーバに対し多大な負荷を与えるため、通信装置の認証に大容量なデータを用いかつリアルタイムな連続認証を実現することはできなかった。
【００８４】
これに対し、本実施の形態の手法によれば、ＳＩＰに代表される通信装置間に介在し通信を制御・中継するシグナリング手順を用いる通信方式で、通信仲介サーバにより担保された通信において、通信装置と認証サーバが認証情報を送受信するため、通信装置と通信仲介サーバの間では認証情報の送受信を不要としつつ、認証サーバと通信仲介サーバは軽量な通信処理により認証状態を常に一致することが可能となる。
【００８５】
これにより、通信装置が通信仲介サーバと認証情報を交換する場合と比べ、通信仲介サーバの負荷を軽減できる。この場合も、通信装置が通信仲介サーバと認証情報を交換する場合と同等の認証状態を実現できる。また、大容量な認証データの交換が容易となり、任意の頻度で連続的な認証処理を実施することも可能となる。このようにして、通信仲介サーバ本来の処理や規模運用性を全く損なうことなく、安全性を向上させる認証処理を実現することが可能となる。
【００８６】
（第２の実施の形態）
第１の実施の形態では、ＩＮＶＩＴＥリクエストによって認証サーバとＳＩＰクライアントとの間の通信を確立し、ＩＮＶＩＴＥリクエストで確立した通信を用いて認証情報を送受信していた。認証情報の交換は、このようにＩＮＶＩＴＥリクエストで確立した通信を用いる必要はなく、任意の方法で確立した通信によって認証情報を送受信可能である。例えば、ＳＩＰにおけるプレゼンス情報の処理に用いられるＳＵＢＳＣＲＩＢＥリクエストなどのように、ダイアログでデータチャネルが確立されないメッセージを用いてもよい。
【００８７】
第２の実施の形態にかかる仲介サーバは、ＳＩＰのＳＵＢＳＣＲＩＢＥリクエストに関連付けられた認証サーバ２００とＳＩＰクライアント４００との直接通信を用いて認証サーバと通信端末との間で任意の方法および頻度で実行された認証処理の結果を当該認証サーバから受信し、通信端末の認証状態を判断するものである。
【００８８】
ここで、ＳＵＢＳＣＲＩＢＥリクエストに関連づけられた直接通信とは、ＳＵＢＳＣＲＩＢＥのダイアログとは別の方法で認証サーバ２００とＳＩＰクライアント４００との間で確立され、ＳＵＢＳＣＲＩＢＥリクエストと関連づける情報を付与された通信をいう。例えば、ＳＩＰクライアント４００と認証サーバ２００との間で予め定められた任意の手段で通信を確立し、同じユーザ名等の情報を送ることによってＳＵＢＳＣＲＩＢＥのダイアログと関連付けることができる。また、公開鍵暗号の鍵ペアを片側ずつ送る方法など、その他のあらゆる関連付け方法を適用できる。
【００８９】
図８は、第２の実施の形態にかかる通信システムの特徴を説明するための説明図である。同図に示すように、通信システム８０は、ＳＩＰプロキシ９００と、認証サーバ９２０と、ＳＩＰクライアント９４０とを備えている。
【００９０】
同図に示すように、本実施の形態では、ＳＵＢＳＣＲＩＢＥリクエストによって認証サーバ９２０とＳＩＰクライアント９４０との間でＳＵＢＳＣＲＩＢＥリクエストに関連づけられた直接通信によって認証情報の送受信が行われる。また、ＳＩＰプロキシ９００は、ＳＵＢＳＣＲＩＢＥリクエストで確立されたダイアログを用いて、認証サーバ９２０からＳＩＰクライアント９４０の認証状態を受信する。
【００９１】
これにより、第１の実施の形態と同様に、ＳＩＰクライアント９４０からＳＩＰプロキシ９００に対して認証情報を送信してＳＩＰプロキシ９００で認証を実行する必要がなくなり、ＳＩＰプロキシ９００の処理負荷を低減することができる。また、ＩＮＶＩＴＥリクエストで確立するデータチャネル以外の任意の通信チャネルによって第１の実施の形態と同様の機能を実現できる。
【００９２】
図９は、第２の実施の形態にかかる通信システム８０の構成を示すブロック図である。通信システム８０は、仲介サーバであるＳＩＰプロキシ９００と、認証サーバ９２０と、ＳＩＰクライアント９４０ａ、９４０ｂとが、ネットワーク３００を介して接続された構成となっている。
【００９３】
第２の実施の形態では、ＳＩＰクライアント９４０の機能、認証サーバ９２０の認証状態送信部９２４の機能、および、ＳＩＰプロキシ９００の通信要求受信部９０２、通信仲介部９０３、認証状態受信部９０４の機能が第１の実施の形態と異なっている。その他の構成および機能は、第１の実施の形態にかかる通信システム１０の構成を表すブロック図である図２と同様であるので、同一符号を付し、ここでの説明は省略する。
【００９４】
ＳＩＰクライアント９４０は、ＩＮＶＩＴＥリクエストではなく、ＳＵＢＳＣＲＩＢＥリクエストによって通信の開始を要求する通信要求メッセージを送信する点が、第１の実施の形態のＳＩＰクライアント４００と異なっている。
【００９５】
認証サーバ９２０の認証状態送信部９２４は、ＳＩＰクライアント９４０の認証状態を、認証状態を含むＳＩＰのＮＯＴＩＦＹリクエストとして送信するものである。
【００９６】
ＳＩＰプロキシ９００の通信要求受信部９０２は、ＳＩＰクライアント９４０から認証サーバ９２０に対する通信の開始を要求する通信要求メッセージとして、ＳＵＢＳＣＲＩＢＥリクエストを受信するものである。
【００９７】
通信仲介部９０３は、受信したＳＵＢＳＣＲＩＢＥリクエストを認証サーバ９２０に送信し、認証サーバ９２０から返信された応答（ＮＯＴＩＦＹ）に従い、ＳＩＰクライアント９４０と認証サーバ９２０との間の通信を仲介するものである。また、通信仲介部９０３は、通信を仲介した場合、接続情報テーブル１２２に仲介した通信に関する接続情報を記憶する。
【００９８】
認証状態受信部９０４は、通信を開始した認証サーバ９２０から、ＳＩＰクライアント９４０の認証状態を受信するものである。本実施の形態では、認証サーバ９２０は、認証状態を含むＮＯＴＩＦＹリクエストを送信するため、認証状態受信部９０４は、認証サーバ９２０からＮＯＴＩＦＹリクエストを認証状態として受信する。
【００９９】
次に、このように構成された第２の実施の形態にかかるＳＩＰプロキシ９００による通信仲介処理について説明する。図１０は、第２の実施の形態における通信仲介処理の全体の流れを示すフローチャートである。
【０１００】
ステップＳ１００１からステップＳ１００３までの、クライアント登録処理は、第１の実施の形態にかかるＳＩＰプロキシ１００におけるステップＳ６０１からステップＳ６０３までと同様の処理なので、その説明を省略する。
【０１０１】
次に、ＳＩＰクライアント９４０が、認証サーバ９２０との間の通信の開始を要求する通信要求メッセージとしてＳＵＢＳＣＲＩＢＥリクエストをＳＩＰプロキシ９００に対して送信する（ステップＳ１００４）。
【０１０２】
次に、ＳＩＰプロキシ９００の通信要求受信部１０２は、ＳＩＰクライアント９４０からＳＵＢＳＣＲＩＢＥリクエストを受信し、認証サーバ９２０に対して転送する（ステップＳ１００５）。
【０１０３】
認証サーバ９２０の応答部２０１は、ＳＵＢＳＣＲＩＢＥリクエストを受信し、当該ＳＵＢＳＣＲＩＢＥリクエストに対する応答（ＮＯＴＩＦＹリクエスト）をＳＩＰプロキシ９００に返信する（ステップＳ１００６）。ここでは、通信の開始を認可する応答を送信したものとする。
【０１０４】
次に、ＳＩＰプロキシ９００の通信仲介部９０３は、ＳＩＰクライアント９４０と認証サーバ９２０との通信を仲介し、仲介した通信に関する接続情報を接続情報テーブル１２２に登録する（ステップＳ１００７）。この接続情報が表す接続状態は、ＳＵＢＳＣＲＩＢＥリクエストにより開始されたダイアログである。このダイアログは、ＳＩＰクライアント９４０と認証サーバ９２０が直接通信する認証情報の状態を認証サーバ９２０からＳＩＰプロキシ９００に通知するために用いられる。
【０１０５】
なお、本実施の形態では、認証サーバ９２０とＳＩＰクライアント９４０との間の直接通信の形態は問わない。任意の方法で接続された直接通信により認証情報が送受信され、当該認証情報を用いた認証処理の結果が、上記ダイアログを介して認証サーバ９２０からＳＩＰプロキシ９００に対して送信される。
【０１０６】
ステップＳ１００８からステップＳ１０１１までの、成功通知処理、認証情報送信処理、および認証処理は、第１の実施の形態にかかるＳＩＰプロキシ１００におけるステップＳ６０８からステップＳ６１１までと同様の処理なので、その説明を省略する。
【０１０７】
次に、認証状態送信部９２４は、認証状態をＳＩＰクライアント９４０に送信する（ステップＳ１０１２）。また、認証状態送信部９２４は、認証状態をＮＯＴＩＦＹリクエストとしてＳＩＰプロキシ９００に送信する（ステップＳ１０１３）。
【０１０８】
ＳＩＰプロキシ９００の認証状態受信部９０４は、ＮＯＴＩＦＹリクエストを受信し、当該ＮＯＴＩＦＹリクエストに含まれる認証状態に応じて認証状態として「有効」または「無効」を認証状態テーブル１２３に保存する（ステップＳ１０１４）。
【０１０９】
このように、第２の実施の形態にかかる仲介サーバでは、ＳＩＰのＳＵＢＳＣＲＩＢＥリクエストによって開始された通信を用いて認証サーバと通信端末との間で任意の方法および頻度で実行された認証処理の結果を当該認証サーバから受信し、通信端末の認証状態を判断することができる。このため、ＩＮＶＩＴＥリクエストで確立されたデータチャネル以外の任意の通信チャネルを用いて認証情報を送受信することが可能となる。
【０１１０】
図１１は、第１または第２の実施の形態にかかる仲介サーバのハードウェア構成を示す説明図である。
【０１１１】
第１または第２の実施の形態にかかる仲介サーバは、ＣＰＵ（Central Processing Unit）５１などの制御装置と、ＲＯＭ（Read Only Memory）５２やＲＡＭ５３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ５４と、ＨＤＤ（Hard Disk Drive）、ＣＤ（Compact Disc）ドライブ装置などの外部記憶装置と、ディスプレイ装置などの表示装置と、キーボードやマウスなどの入力装置と、各部を接続するバス６１を備えており、通常のコンピュータを利用したハードウェア構成となっている。
【０１１２】
第１または第２の実施の形態にかかる仲介サーバで実行される通信仲介プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact Disk Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。
【０１１３】
また、第１または第２の実施の形態にかかる仲介サーバで実行される通信仲介プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、第１または第２の実施の形態にかかる仲介サーバで実行される通信仲介プログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
【０１１４】
また、第１または第２の実施の形態の通信仲介プログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。
【０１１５】
第１または第２の実施の形態にかかる仲介サーバで実行される通信仲介プログラムは、上述した各部（登録要求受信部、通信要求受信部、通信仲介部、認証状態受信部、判断部、通信切断部、通知受信部、通知部）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ５１（プロセッサ）が上記記憶媒体から通信仲介プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、上述した各部が主記憶装置上に生成されるようになっている。
【産業上の利用可能性】
【０１１６】
以上のように、本発明にかかる仲介サーバ、通信仲介方法、通信仲介プログラム、および通信システムは、生体情報や画像情報などのようにデータ用量の大きい認証情報を用いてリアルタイム認証を行う仲介サーバ、通信仲介方法、および通信仲介プログラムに適している。
【図面の簡単な説明】
【０１１７】
【図１】第１の実施の形態にかかる通信システムの特徴を説明するための説明図である。
【図２】第１の実施の形態にかかる通信システムの構成を示すブロック図である。
【図３】登録情報テーブルのデータ構造の一例を示す説明図である。
【図４】接続情報テーブルのデータ構造の一例を示す説明図である。
【図５】認証状態テーブルのデータ構造の一例を示す説明図である。
【図６】第１の実施の形態における通信仲介処理の全体の流れを示すフローチャートである。
【図７】第１の実施の形態における制御要求仲介処理の全体の流れを示すフローチャートである。
【図８】第２の実施の形態にかかる通信システムの特徴を説明するための説明図である。
【図９】第２の実施の形態にかかる通信システムの構成を示すブロック図である。
【図１０】第２の実施の形態における通信仲介処理の全体の流れを示すフローチャートである。
【図１１】第１または第２の実施の形態にかかる仲介サーバのハードウェア構成を示す説明図である。
【符号の説明】
【０１１８】
５１ ＣＰＵ
５２ ＲＯＭ
５３ ＲＡＭ
５４ 通信Ｉ／Ｆ
６１ バス
１０ 通信システム
８０ 通信システム
１００ ＳＩＰプロキシ
１０１ 登録要求受信部
１０２ 通信要求受信部
１０３ 通信仲介部
１０４ 認証状態受信部
１０５ 判断部
１０６ 通信切断部
１０７ 通知受信部
１０８ 通知部
１２０ 記憶部
１２１ 登録情報テーブル
１２２ 接続情報テーブル
１２３ 認証状態テーブル
２００ 認証サーバ
２０１ 応答部
２０２ 認証情報受信部
２０３ 認証部
２０４ 認証状態送信部
３００ ネットワーク
４００ ＳＩＰクライアント
９００ ＳＩＰプロキシ
９０２ 通信要求受信部
９０３ 通信仲介部
９０４ 認証状態受信部
９２０ 認証サーバ
９２４ 認証状態送信部
９４０ ＳＩＰクライアント
【技術分野】
【０００１】
この発明は、通信端末間および通信端末と認証サーバとの間の通信を仲介する仲介サーバ、通信仲介方法、通信仲介プログラム、および通信システムに関するものである。
【背景技術】
【０００２】
近年、通信装置間に介在し通信を制御・中継するシグナリング手順としてＳＩＰ（Session Initiation Protocol）が広く知られている。従来のＳＩＰの認証方式としては、発信装置が送信メッセージとともにパスワードなどの認証情報を送信し、着信装置が送信メッセージとともに受信した認証情報に基づき発信装置に対して認証を実施する方法が一般的である。
【０００３】
例えば、発信装置であるＳＩＰクライアントは、着信装置であるＳＩＰプロキシに対し登録（ＲＥＧＩＳＴＥＲ）メッセージを送信する際、発信装置が正規のＳＩＰクライアントであることを担保する認証情報を合わせて送信する。これに対しＳＩＰプロキシは、まず登録メッセージ上で受信した認証データに基づく認証を行い、正規のＳＩＰクライアントであることを確認し、次に認証の可否により当該登録メッセージで要求される登録処理の可否を決定する。
【０００４】
すなわち、従来のＳＩＰ認証方式は、発信装置からあるメッセージで要求される着信装置における処理の可否を、着信装置で確認することを目的としたものである。従って、発信装置は該当するメッセージと同時に認証情報を送信する必要があり、認証情報は発信装置と着信装置（例えばＳＩＰクライアントとＳＩＰプロキシ）の通信で該当するメッセージとともに交換される。このため、認証情報は通信メッセージや通信処理を妨げないものに限定される。また、認証情報のデータ量が増加すると、発信装置と着信装置との間の通信データ量も増加する。
【０００５】
一方、認証状態が確立されると、明示的な要求で解除されるか、有効期限を経過するまで、その認証状態が持続する。これは、そもそもメッセージで要求される処理についての可否を判定することが認証の目的であることに起因する。このため、メッセージで要求された処理の有効性が認証状態の有効性と等価となる。例えば、登録処理の場合は、ある登録が有効な間は認証状態も有効であるとみなされる。
【０００６】
すなわち、通信装置からのメッセージに対し、通信装置の認証状態に基づき挙動を変化させるＳＩＰプロキシなどの通信仲介サーバは、実際には通信装置の登録状態に基づき挙動を変化させる必要がある。言い換えれば、認証サーバと通信仲介サーバとが、通信装置の認証状態の変化を検知できないことを意味する。このため、例えばＳＩＰプロキシがＳＩＰクライアントの認証状態の変化を即座に検知する場合、発信装置であるＳＩＰクライアントが登録の処理を頻繁に繰り返す必要が生じる。
【０００７】
通信装置の認証状態の変化を検知する方法として、特許文献１では、通信仲介サーバから定期的に通信装置の接続状態を確認することにより、認証状態を適切な契機で無効化する技術が提案されている。
【０００８】
【特許文献１】特開２００５−９９９８０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、特許文献１の方法では、ＳＩＰクライアントの認証状態の変化を即座に検知する場合に、ＳＩＰプロキシの処理負荷が大きくなるという問題があった。すなわち、ＳＩＰプロキシは、ＳＩＰクライアントの接続状態の確認のためのメッセージ送信を頻繁に繰り返す必要があった。
【００１０】
さらに、セキュリティ強化等のため生体情報や画像情報を用いた認証を行う場合は、認証に用いる認証情報のデータ量が大容量となるため、確認頻度の増加だけでなく通信データ量の増加により、ＳＩＰプロキシの処理負荷がさらに増大するという問題も生じる。
【００１１】
本発明は、上記に鑑みてなされたものであって、認証に用いる認証情報の情報量や認証頻度に依存することなく、低負荷で通信装置を認証して通信を仲介することができる仲介サーバ、通信仲介方法、および通信仲介プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
上述した課題を解決し、目的を達成するために、本発明は、通信端末と前記通信端末の認証を行う認証サーバとの間の通信を仲介する仲介サーバであって、前記認証サーバに対する通信の開始を要求する通信要求メッセージを前記通信端末から受信する通信要求受信部と、受信した前記通信要求メッセージに対応して、前記通信端末と前記認証サーバとの間の通信を仲介する通信仲介部と、前記認証サーバから前記通信端末に対する認証状態を受信する認証状態受信部と、受信した前記認証状態に基づいて前記通信端末の認証の可否を判断する判断部と、を備えたことを特徴とする。
【００１３】
また、本発明は、上記装置を実行することができる通信仲介方法および通信仲介プログラムである。
【００１４】
また、本発明は、通信端末の認証を行う認証サーバと、前記通信端末とネットワークを介して接続され、前記通信端末と前記認証サーバとの間の通信を仲介する仲介サーバとを備えた通信システムであって、前記仲介サーバは、前記認証サーバに対する通信の開始を要求する通信要求メッセージを前記通信端末から受信する通信要求受信部と、受信した前記通信要求メッセージに対応して、前記通信端末と前記認証サーバとの間の通信を仲介する通信仲介部と、前記認証サーバから前記通信端末に対する認証状態を受信する認証状態受信部と、受信した前記認証状態に基づいて前記通信端末の認証の可否を判断する判断部と、を備え、前記認証サーバは、前記通信端末から認証に用いる認証情報を受信する認証情報受信部と、受信した前記認証情報を用いて前記通信端末の認証を行う認証部と、前記認証状態を前記仲介サーバに送信する認証状態送信部と、を備えたこと、を特徴とする。
【発明の効果】
【００１５】
本発明によれば、認証サーバから通知された認証結果によって通信装置の認証状態を管理することができる。このため、認証に用いる認証情報の情報量や認証頻度に依存することなく、低負荷で通信装置を認証して通信を仲介することができるという効果を奏する。
【発明を実施するための最良の形態】
【００１６】
以下に添付図面を参照して、この発明にかかる仲介サーバ、通信仲介方法、通信仲介プログラム、および通信システムの最良な実施の形態を詳細に説明する。
【００１７】
（第１の実施の形態）
第１の実施の形態にかかる仲介サーバは、ＳＩＰのＩＮＶＩＴＥリクエストによって確立された通信を用いて認証サーバと通信端末との間で任意の方法および頻度で実行された認証処理の結果を当該認証サーバから受信し、通信端末の認証状態を判断するものである。
【００１８】
図１は、第１の実施の形態にかかる通信システムの特徴を説明するための説明図である。同図に示すように、通信システム１０は、仲介サーバであるＳＩＰプロキシ１００と、認証サーバ２００と、通信端末であるＳＩＰクライアント４００とを備えている。なお、認証サーバ２００およびＳＩＰクライアント４００は複数備えることができる。また、各装置は、インターネットやＬＡＮ（Local Area Network）などのネットワークにより接続されている。
【００１９】
同図に示すように、本実施の形態では、ＳＩＰクライアント４００が登録要求メッセージ（ＲＥＧＩＳＴＥＲ）を送信してＳＩＰプロキシ１００に自身を登録した後、ＩＮＶＩＴＥリクエストによって認証サーバ２００との間で確立されたデータチャネルによって認証情報の通信が行われる。また、ＳＩＰプロキシ１００は、ＩＮＶＩＴＥリクエストで確立されたダイアログを用いて、認証サーバ２００からＳＩＰクライアント４００の認証状態を受信する。
【００２０】
これにより、ＳＩＰクライアント４００からＳＩＰプロキシ１００に対して認証情報を送信してＳＩＰプロキシ１００で認証を実行する必要がない。また、ＩＮＶＩＴＥリクエストで確立された通信を用いてＳＩＰクライアント４００と認証サーバ２００との間で認証情報を通信して認証を行い、ＳＩＰプロキシ１００に対しては認証サーバ２００から認証状態のみを通知すればよいため、ＳＩＰプロキシ１００の処理負荷を低減することができる。
【００２１】
図２は、第１の実施の形態にかかる通信システム１０の構成を示すブロック図である。図１で説明したように、通信システム１０は、仲介サーバであるＳＩＰプロキシ１００と、認証サーバ２００と、ＳＩＰクライアント４００ａ、４００ｂとが、ネットワーク３００を介して接続された構成となっている。
【００２２】
ＳＩＰクライアント４００ａ、４００ｂ（以下、ＳＩＰクライアント４００という。）は、ＳＩＰのクライアント機能（ＳＩＰ ＵＡ（ユーザエージェント））を有する装置である。また、ＳＩＰクライアント４００は、自装置の認証を行うために、キーボード、カメラ、マイク、センサ等を用いて認証情報を取得し、認証サーバ２００に送信する。
【００２３】
認証サーバ２００は、ＳＩＰクライアント４００の認証を行うものである。本実施の形態では、ＩＮＶＩＴＥリクエストによりＳＩＰプロキシ１００を介してＳＩＰクライアント４００との間で確立されたデータチャネルを用いて、ＳＩＰクライアント４００から認証情報を受け取り、認証処理を行う。
【００２４】
図２に示すように、認証サーバ２００は、応答部２０１と、認証情報受信部２０２と、認証部２０３と、認証状態送信部２０４と、を備えている。
【００２５】
応答部２０１は、ＳＩＰプロキシ１００を介してＳＩＰクライアント４００から通信の確立を要求する通信要求メッセージであるＩＮＶＩＴＥリクエストに対する応答を返信するものである。
【００２６】
認証情報受信部２０２は、ＳＩＰクライアント４００から認証に利用する認証情報を受信するものである。認証情報受信部２０２は、後述する認証部２０３が採用する認証方法によって、認証情報として、文字情報、画像情報、音声情報、指紋等の生体情報などをＳＩＰクライアント４００から受信する。
【００２７】
認証部２０３は、認証情報受信部２０２が受信した認証情報を用いてＳＩＰクライアント４００の認証処理を行うものである。認証部２０３による認証方法としては、ＩＤとパスワードを利用する方法、生体情報を利用する方法などの従来から用いられているあらゆる認証方法を適用できる。
【００２８】
認証状態送信部２０４は、認証部２０３による認証結果を参照してＳＩＰクライアント４００の認証状態をＳＩＰプロキシ１００に送信するものである。なお、認証状態送信部２０４は、ＳＩＰクライアント４００に認証状態を送信するように構成してもよい。
【００２９】
なお、認証サーバ２００は、任意の頻度で認証情報を受信し、認証処理を行うように構成することができる。例えば、認証サーバ２００は、ＳＩＰクライアント４００を連続認証するように構成してもよい。
【００３０】
ここで、連続認証とは、認証サーバ２００とＳＩＰクライアント４００との間で、例えば、所定の時間間隔、あるいは任意の時間間隔で認証を繰り返す認証方式をいう。より具体的には、ＳＩＰクライアント４００が音声画像や生体情報などを認証サーバ２００に送り続け、受信した認証サーバ２００で所定あるいは任意の時間間隔で認証する認証方式をいう。認証の可否は、都度あるいは所定あるいは任意の時間間隔で認証サーバ２００からＳＩＰクライアント４００に直接送り返されてもよいし、ＳＩＰプロキシ１００を経由して通知されてもよい。
【００３１】
また、認証サーバ２００は、ＳＩＰクライアント４００に対して認証情報を要求するように構成してもよい。また、ＳＩＰクライアント４００と認証サーバ２００との間の通信を暗号化するように構成してもよい。この際の暗号化方法としては従来から用いられているあらゆる方法を適用できる。
【００３２】
ＳＩＰプロキシ１００は、認証サーバ２００とＳＩＰクライアント４００との間、または、複数のＳＩＰクライアント４００間の通信を仲介する仲介サーバであり、通信仲介のためのプロトコルとしてＳＩＰを用いるものである。ＳＩＰプロキシ１００は、記憶部１２０と、登録要求受信部１０１と、通信要求受信部１０２と、通信仲介部１０３と、認証状態受信部１０４と、判断部１０５と、通信切断部１０６と、通知受信部１０７と、通知部１０８と、を備えている。
【００３３】
記憶部１２０は、仲介サーバによる通信の仲介処理で用いる各種情報を記憶するものであり、ＨＤＤ（Hard Disk Drive）、光ディスク、メモリカード、ＲＡＭ（Random Access Memory）などの一般的に利用されているあらゆる記憶媒体により構成することができる。また、記憶部１２０は、各種情報を記憶するテーブルとして、登録情報テーブル１２１と、接続情報テーブル１２２と、認証状態テーブル１２３とを含んでいる。
【００３４】
登録情報テーブル１２１は、ＳＩＰプロキシ１００に登録済みのＳＩＰクライアント４００に関する情報を格納するものである。図３は、登録情報テーブル１２１のデータ構造の一例を示す説明図である。
【００３５】
同図に示すように、登録情報テーブル１２１は、登録したＳＩＰクライアント４００のＳＩＰ ＵＲＩ（Uniform Resource Identifier）と、登録したＳＩＰクライアント４００の名称であるホスト名と、利用するポート番号とを対応づけた登録情報を格納している。
【００３６】
接続情報テーブル１２２は、ＳＩＰクライアント４００間、またはＳＩＰクライアント４００と認証サーバ２００との間で確立した通信に関する接続情報を記憶するものである。図４は、接続情報テーブル１２２のデータ構造の一例を示す説明図である。
【００３７】
同図に示すように、接続情報テーブル１２２は、各ＳＩＰクライアント４００のＳＩＰ ＵＲＩであるＳＩＰ ＵＲＩ１およびＳＩＰ ＵＲＩ２と、ポート番号１およびポート番号２と、確立した通信の有効期限とを対応づけて格納している。
【００３８】
認証状態テーブル１２３は、登録したＳＩＰクライアント４００ごとに、認証サーバ２００による認証状態を格納するものである。図５は、認証状態テーブル１２３のデータ構造の一例を示す説明図である。
【００３９】
同図に示すように、認証状態テーブル１２３は、ＳＩＰ ＵＲＩと、認証状態と、を対応づけて格納している。認証状態には、認証サーバ２００により認証された状態を表す「有効」、または、認証されていない状態を表す「無効」のいずれかが設定される。
【００４０】
認証状態は、ＳＩＰクライアント４００が登録されたときには「無効」が設定され、認証サーバ２００から認証成功の通知を受けたときに「有効」に設定される。また、その後、認証サーバ２００から認証に失敗した旨の通知を受けたときに「無効」に設定される。なお、接続の有効期限が切れた場合などのようにＳＩＰプロキシ１００内で認証状態を判定して「無効」に設定することもできる。
【００４１】
登録要求受信部１０１は、ＳＩＰクライアント４００から送信された登録要求メッセージ（ＲＥＧＩＳＴＥＲリクエスト）を受信するものである。ＲＥＧＩＳＴＥＲリクエストの目的は、ＳＩＰクライアント４００を登録情報テーブル１２１に登録し、ＳＩＰクライアント４００とＳＩＰプロキシ１００との間でその後の通信を行うための接続状態を確立することである。なお、ＲＥＧＩＳＴＥＲリクエストに対する認証を目的として、通常のＳＩＰと同様にＲＥＧＩＳＴＥＲリクエストにダイジェスト認証を伴うように構成してもよい。
【００４２】
通信要求受信部１０２は、ＳＩＰクライアント４００から認証サーバ２００に対する通信の確立を要求するＩＮＶＩＴＥリクエストを受信するものである。
【００４３】
通信仲介部１０３は、受信したＩＮＶＩＴＥリクエストを認証サーバ２００に送信し、認証サーバ２００から返信された応答に従い、ＳＩＰクライアント４００と認証サーバ２００との間の通信を確立するものである。また、通信仲介部１０３は、通信を確立した場合、接続情報テーブル１２２に確立した通信に関する接続情報を記憶する。
【００４４】
認証状態受信部１０４は、通信を確立した認証サーバ２００から、ＳＩＰクライアント４００の認証状態を受信するものである。認証サーバ２００は、認証が成功した場合に、ＩＮＶＩＴＥリクエストをＳＩＰプロキシ１００に送信する。このため、認証状態受信部１０４は、ＩＮＶＩＴＥリクエストを、認証成功を表す認証状態として認証サーバ２００から受信する。また、認証サーバ２００は、認証が失敗した場合に、ＢＹＥリクエストをＳＩＰプロキシ１００に送信するため、認証状態受信部１０４は、ＢＹＥリクエストを、認証失敗を表す認証状態として受信する。
【００４５】
判断部１０５は、ＳＩＰクライアント４００から他のクライアント４００等に対するＩＮＶＩＴＥリクエストなどの通知メッセージを受信した場合に、認証状態テーブル１２３に保存した認証状態を参照してＳＩＰクライアント４００の認証可否を判断するものである。
【００４６】
通信切断部１０６は、判断部１０５によりＳＩＰクライアント４００の認証が無効であると判断された場合に、当該ＳＩＰクライアント４００に関して確立されている通信を切断するものである。
【００４７】
通知受信部１０７は、認証サーバ２００による認証後に、認証されたＳＩＰクライアント４００から他のＳＩＰクライアント４００等に対するＩＮＶＩＴＥリクエストなどの通信に関する通知メッセージを受信するものである。通知受信部１０７は、通知メッセージとして、ＩＮＶＩＴＥの他に、ＳＵＢＳＣＲＩＢＥ、ＭＥＳＳＡＧＥ、ＢＹＥなどのＳＩＰで扱われるあらゆるメッセージを受信することができる。
【００４８】
通知部１０８は、ＳＩＰクライアント４００に対する各種通知メッセージを送信するものである（第１通知部）。例えば、通知部１０８は、通知受信部１０７が受信した通知メッセージを、通知先として指定された他のＳＩＰクライアント４００に対して通知する。また、通知部１０８は、認証サーバ２００から受信した認証状態をＳＩＰクライアント４００に通知するように構成してもよい（第２通知部）。さらに、通知部１０８は、ＳＩＰクライアント４００を登録した後、登録したＳＩＰクライアント４００に対して、利用可能な認証サーバ２００に関する情報を通知するように構成してもよい（第３通知部）。
【００４９】
次に、このように構成された第１の実施の形態にかかるＳＩＰプロキシ１００による通信仲介処理について説明する。図６は、第１の実施の形態における通信仲介処理の全体の流れを示すフローチャートである。
【００５０】
まず、ＳＩＰクライアント４００は、登録要求メッセージとしてＲＥＧＩＳＴＥＲリクエストをＳＩＰプロキシ１００に対して送信する（ステップＳ６０１）。
【００５１】
次に、ＳＩＰプロキシ１００の登録要求受信部１０１は、登録要求メッセージを受信し、ＳＩＰクライアント４００を登録情報テーブル１２１に登録する（ステップＳ６０２）。また、登録要求受信部１０１は、登録したＳＩＰクライアント４００の認証状態を同時に認証状態テーブル１２３に格納してもよいが、この時点では認証状態は「無効」に設定する。
【００５２】
なお、本実施の形態では、通常のＳＩＰと異なり、ＲＥＧＩＳＴＥＲリクエストが成功してＳＩＰクライアント４００を登録した後は、ＳＩＰプロキシ１００がＳＩＰクライアント４００から受け付ける通信状態の制御要求は、ＳＩＰクライアント４００から認証サーバ２００に対するものに限定する。同時に、他のＳＩＰクライアント４００等からＳＩＰクライアント４００に対する接続状態の制御要求を受け付けない。他の装置との通信を制御する前に、認証サーバ２００により認証を行いその結果の通知を受ける必要があるためである。
【００５３】
次に、通知部１０８が、利用可能な認証サーバ２００の情報をＳＩＰクライアント４００に送信する（ステップＳ６０３）。なお、ＳＩＰクライアント４００が事前に認証サーバ２００の情報を入手している場合には、本ステップを省略してもよい。
【００５４】
次に、ＳＩＰクライアント４００が、認証サーバ２００との間の通信を確立する通信要求メッセージとしてＩＮＶＩＴＥリクエストをＳＩＰプロキシ１００に対して送信する（ステップＳ６０４）。
【００５５】
次に、ＳＩＰプロキシ１００の通信要求受信部１０２は、ＳＩＰクライアント４００からＩＮＶＩＴＥリクエストを受信し、認証サーバ２００に対して転送する（ステップＳ６０５）。
【００５６】
認証サーバ２００の応答部２０１は、ＩＮＶＩＴＥリクエストを受信し、当該ＩＮＶＩＴＥリクエストに対する応答をＳＩＰプロキシ１００に返信する（ステップＳ６０６）。ここでは、通信の確立を認可する応答を送信したものとする。
【００５７】
次に、ＳＩＰプロキシ１００の通信仲介部１０３は、ＳＩＰクライアント４００と認証サーバ２００との通信を確立し、確立した通信の接続状態、すなわち、ＩＮＶＩＴＥリクエストにより確立されたダイアログに関する接続情報を接続情報テーブル１２２に登録する（ステップＳ６０７）。このダイアログにより、ＳＩＰクライアント４００と認証サーバ２００が直接通信できるように構成される。
【００５８】
次に、通知部１０８は、通信確立が成功したことをＳＩＰクライアント４００に通知する（ステップＳ６０８）。
【００５９】
次に、このようにして確立されたダイアログを用いて、ＳＩＰクライアント４００と認証サーバ２００との直接通信により、ＳＩＰクライアント４００は認証サーバ２００に対して認証情報を送信する（ステップＳ６０９）。
【００６０】
認証サーバ２００の認証情報受信部２０２は、ＳＩＰクライアント４００から認証情報を受信し（ステップＳ６１０）、認証部２０３が、受信した認証情報を用いて認証処理を実行する（ステップＳ６１１）。次に、認証状態送信部２０４は、認証状態をＳＩＰクライアント４００に送信する（ステップＳ６１２）。また、認証状態送信部２０４は、認証状態をＳＩＰプロキシ１００に送信する（ステップＳ６１３）。
【００６１】
この際、認証状態送信部２０４は、認証が成功したときは、ダイアログを更新するためのＩＮＶＩＴＥリクエスト（ｒｅ−ＩＮＶＩＴＥリクエスト）を送信する。また、認証状態送信部２０４は、認証が失敗したときは、ＢＹＥリクエストをＳＩＰプロキシ１００に送信する。
【００６２】
ＳＩＰプロキシ１００の認証状態受信部１０４は、認証状態を受信し、認証可否に応じて認証状態として「有効」または「無効」を認証状態テーブル１２３に保存する（ステップＳ６１４）。
【００６３】
なお、同図には図示していないが、認証が失敗した場合、通信切断部１０６が、接続情報テーブル１２２から認証が失敗したＳＩＰクライアント４００に関する接続情報を削除することにより、ダイアログを破棄する。これにより、当該ＳＩＰクライアント４００からの通信または当該ＳＩＰクライアント４００に対する通信が制限されることになる。また、ＳＩＰプロキシ１００は、受信した認証状態や、それに基づく認証状態をＳＩＰクライアント４００に対して送信するように構成してもよい。
【００６４】
なお、ステップＳ６０９からステップＳ６１４までの処理は、この後、任意の間隔、頻度で繰り返し実行される。また、例えば、認証サーバ２００による認証状態の通知は、ダイアログが確立された直後の最初の認証時のほか、認証サーバ２００に設定された任意の間隔、認証サーバ２００が認証状態の変化を検出した時点などあらゆるタイミングで実行可能である。また、認証サーバ２００で設定した一定時間の間にＳＩＰクライアント４００から認証情報を取得できないとき、認証サーバ２００は認証失敗時と同様の動作を行うように構成してもよい。
【００６５】
また、認証状態の通知方法として、成功時にＩＮＶＩＴＥリクエストを送信し、失敗時にＢＹＥリクエストを送信する方法が最も通信量を削減できるが、代わりにＭＥＳＳＡＧＥやＮＯＴＩＦＹ等により、ＳＩＰプロキシ１００やＳＩＰクライアント４００に対して認証状態を通知するように構成してもよい。
【００６６】
このように、本実施の形態では、ＳＩＰを用いた通信の確立時に、通信の確立を仲介する仲介サーバであるＳＩＰプロキシ１００内で認証処理を行わず、確立した通信を介して送信した認証情報によって認証サーバ２００で認証処理を行い、その結果をＳＩＰプロキシ１００に通知することによりＳＩＰクライアント４００の認証状態を判定することができる。ＳＩＰプロキシ１００は認証サーバ２００から認証状態に関する情報を受信するだけであるため、認証サーバ２００で実行される認証処理の実現方法に関わらず、ＳＩＰプロキシ１００の処理負荷を低減することができる。
【００６７】
次に、認証後に、ＳＩＰクライアント４００間で接続状態の制御要求を受信した場合の処理について説明する。図７は、第１の実施の形態における制御要求仲介処理の全体の流れを示すフローチャートである。なお、以下では、制御要求を送信するＳＩＰクライアント４００をＳＩＰクライアント４００ａとし、制御要求を受信するＳＩＰクライアント４００をＳＩＰクライアント４００ｂとする。
【００６８】
まず、ＳＩＰクライアント４００ａは、ＳＩＰクライアント４００ｂに対する接続状態の制御を要求する通知メッセージをＳＩＰプロキシ１００に対して送信する（ステップＳ７０１）。通知メッセージとは、ＩＮＶＩＴＥ、ＳＵＢＳＣＲＩＢＥ、ＭＥＳＳＡＧＥ、ＢＹＥ等のＳＩＰのシグナリングリクエストをいう。
【００６９】
次に、ＳＩＰプロキシ１００の通知受信部１０７は、通知メッセージを受信する（ステップＳ７０２）。次に、判断部１０５は、接続情報テーブル１２２および認証状態テーブル１２３を参照して、ＳＩＰクライアント４００ａ、４００ｂの接続状態と認証状態を確認する（ステップＳ７０３）。
【００７０】
具体的には、判断部１０５は、ＳＩＰクライアント４００ａとＳＩＰクライアント４００ｂとの間の接続情報が接続情報テーブル１２２に記憶されているか否かにより、両者が接続された状態であるか否かを確認する。また、判断部１０５は、ＳＩＰクライアント４００ａおよび４００ｂのＳＩＰ ＵＲＩに対応する認証状態をそれぞれ認証状態テーブル１２３から取得し、認証状態が共に「有効」であるかを確認する。
【００７１】
次に、判断部１０５は、両者が接続されており、かつ、ＳＩＰクライアント４００ａおよび４００ｂの認証状態が「有効」であるか否かを判断する（ステップＳ７０４）。両者が接続されており、かつ、認証状態がそれぞれ「有効」である場合（ステップＳ７０４：ＹＥＳ）、通知部１０８は、ＳＩＰクライアント４００ｂに対して通知メッセージを中継する（ステップＳ７０６）。
【００７２】
ＳＩＰクライアント４００ｂは、中継された通知メッセージを受信し（ステップＳ７０７）、受信した通知メッセージに対する応答をＳＩＰクライアント４００ａに対して送信する（ステップＳ７０８）。
【００７３】
ステップＳ７０４で、両者が接続されており、かつ、認証状態が「有効」であると判断された場合以外は（ステップＳ７０４：ＮＯ）、通知部１０８は、通知メッセージの中継を拒否する応答をＳＩＰクライアント４００ａに対して送信する（ステップＳ７０５）。
【００７４】
ＳＩＰクライアント４００ａは、ＳＩＰプロキシ１００またはＳＩＰクライアント４００ｂからの応答を受信する（ステップＳ７０９）。
【００７５】
ただし、ＳＩＰクライアント４００ｂが、例えば他のドメインで運用されるなど、ＳＩＰプロキシ１００の管理外にある場合は、ＳＩＰクライアント４００ｂに関する認証の確認処理は、ＳＩＰクライアント４００ｂが接続されているＳＩＰプロキシ（ＳＩＰプロキシ１００以外のプロキシ）によって実施されることも考えられる。この場合にＳＩＰプロキシ１００とＳＩＰクライアント４００ｂが接続されるＳＩＰプロキシとの間で認証情報を交換することも考えられる。この場合の認証情報の交換方法としては、従来から用いられているあらゆる技術を適用できる。
【００７６】
このように、一旦ＳＩＰクライアント４００の認証状態が有効となると、ＳＩＰプロキシ１００は、認証サーバ２００とＳＩＰクライアント４００との通信を確立したダイアログの存在が確認できる限り、原則としてＳＩＰクライアント４００の認証状態は有効であると判定することができる。
【００７７】
この結果、認証サーバ２００がＳＩＰクライアント４００を正しく認証し、認証状態をＳＩＰプロキシ１００に正しく通知することが保証されていれば、ＳＩＰクライアント４００とＳＩＰプロキシ１００との間で認証に関わる通信を全く行わないとしても、ＳＩＰプロキシ１００は正しくＳＩＰクライアント４００の認証を行うことが可能となる。
【００７８】
また、認証が無効になった場合、認証サーバ２００が無効になった時点で即時にＳＩＰプロキシ１００に対して認証状態を通知すれば、ＳＩＰプロキシ１００がＳＩＰクライアント４００の認証状態の変化を即座に検知することも可能となる。
【００７９】
また、認証情報は認証サーバ２００とＳＩＰクライアント４００との間でのみ送受信されるため、画像情報、生体情報などの情報量の大きい認証情報による認証技術を用いた場合であっても、ＳＩＰプロキシ１００の負荷に影響を与えることがない。
【００８０】
このように、第１の実施の形態にかかる仲介サーバでは、ＳＩＰのＩＮＶＩＴＥリクエストによって確立された通信を用いて実行された認証処理の結果を認証サーバから受信し、通信端末の認証状態を判断することができる。このため、認証に用いる認証情報の情報量や認証頻度に依存することなく、低負荷で通信装置を認証して通信を仲介することができる。
【００８１】
また、認証状態を無効にすべき時点で即座に無効とするにはリアルタイムな連続認証が必要であるが、従来の方法では、ＳＩＰプロキシがＳＩＰクライアントに対して連続して認証を試みる必要があった。これに対し、本実施の形態では、認証サーバが即時に認証状態をＳＩＰプロキシに対して送信するように構成すれば、ＳＩＰプロキシの処理負荷を増大させることなく、リアルタイム認証が可能となる。
【００８２】
一般に、ＳＩＰプロキシは、電子メールサーバと同等の規模で多数の利用者を収容する装置であり、認証状態にあるＳＩＰクライアントからの要求を仲介し通信の制御・中継（シグナリング）などを処理するものである。このため、処理の負荷を軽減する規模運用性（スケーラビリティ）に重点を置いた設計が必要であり、認証情報は軽量としかつ通信頻度は最小化することが求められる。
【００８３】
これは、ＳＩＰに限らず、通信装置間に介在し通信を制御・中継するシグナリングを行う通信仲介サーバと通信装置の通信方式でも同様である。ところが、従来の手法では、通信仲介サーバに対し多大な負荷を与えるため、通信装置の認証に大容量なデータを用いかつリアルタイムな連続認証を実現することはできなかった。
【００８４】
これに対し、本実施の形態の手法によれば、ＳＩＰに代表される通信装置間に介在し通信を制御・中継するシグナリング手順を用いる通信方式で、通信仲介サーバにより担保された通信において、通信装置と認証サーバが認証情報を送受信するため、通信装置と通信仲介サーバの間では認証情報の送受信を不要としつつ、認証サーバと通信仲介サーバは軽量な通信処理により認証状態を常に一致することが可能となる。
【００８５】
これにより、通信装置が通信仲介サーバと認証情報を交換する場合と比べ、通信仲介サーバの負荷を軽減できる。この場合も、通信装置が通信仲介サーバと認証情報を交換する場合と同等の認証状態を実現できる。また、大容量な認証データの交換が容易となり、任意の頻度で連続的な認証処理を実施することも可能となる。このようにして、通信仲介サーバ本来の処理や規模運用性を全く損なうことなく、安全性を向上させる認証処理を実現することが可能となる。
【００８６】
（第２の実施の形態）
第１の実施の形態では、ＩＮＶＩＴＥリクエストによって認証サーバとＳＩＰクライアントとの間の通信を確立し、ＩＮＶＩＴＥリクエストで確立した通信を用いて認証情報を送受信していた。認証情報の交換は、このようにＩＮＶＩＴＥリクエストで確立した通信を用いる必要はなく、任意の方法で確立した通信によって認証情報を送受信可能である。例えば、ＳＩＰにおけるプレゼンス情報の処理に用いられるＳＵＢＳＣＲＩＢＥリクエストなどのように、ダイアログでデータチャネルが確立されないメッセージを用いてもよい。
【００８７】
第２の実施の形態にかかる仲介サーバは、ＳＩＰのＳＵＢＳＣＲＩＢＥリクエストに関連付けられた認証サーバ２００とＳＩＰクライアント４００との直接通信を用いて認証サーバと通信端末との間で任意の方法および頻度で実行された認証処理の結果を当該認証サーバから受信し、通信端末の認証状態を判断するものである。
【００８８】
ここで、ＳＵＢＳＣＲＩＢＥリクエストに関連づけられた直接通信とは、ＳＵＢＳＣＲＩＢＥのダイアログとは別の方法で認証サーバ２００とＳＩＰクライアント４００との間で確立され、ＳＵＢＳＣＲＩＢＥリクエストと関連づける情報を付与された通信をいう。例えば、ＳＩＰクライアント４００と認証サーバ２００との間で予め定められた任意の手段で通信を確立し、同じユーザ名等の情報を送ることによってＳＵＢＳＣＲＩＢＥのダイアログと関連付けることができる。また、公開鍵暗号の鍵ペアを片側ずつ送る方法など、その他のあらゆる関連付け方法を適用できる。
【００８９】
図８は、第２の実施の形態にかかる通信システムの特徴を説明するための説明図である。同図に示すように、通信システム８０は、ＳＩＰプロキシ９００と、認証サーバ９２０と、ＳＩＰクライアント９４０とを備えている。
【００９０】
同図に示すように、本実施の形態では、ＳＵＢＳＣＲＩＢＥリクエストによって認証サーバ９２０とＳＩＰクライアント９４０との間でＳＵＢＳＣＲＩＢＥリクエストに関連づけられた直接通信によって認証情報の送受信が行われる。また、ＳＩＰプロキシ９００は、ＳＵＢＳＣＲＩＢＥリクエストで確立されたダイアログを用いて、認証サーバ９２０からＳＩＰクライアント９４０の認証状態を受信する。
【００９１】
これにより、第１の実施の形態と同様に、ＳＩＰクライアント９４０からＳＩＰプロキシ９００に対して認証情報を送信してＳＩＰプロキシ９００で認証を実行する必要がなくなり、ＳＩＰプロキシ９００の処理負荷を低減することができる。また、ＩＮＶＩＴＥリクエストで確立するデータチャネル以外の任意の通信チャネルによって第１の実施の形態と同様の機能を実現できる。
【００９２】
図９は、第２の実施の形態にかかる通信システム８０の構成を示すブロック図である。通信システム８０は、仲介サーバであるＳＩＰプロキシ９００と、認証サーバ９２０と、ＳＩＰクライアント９４０ａ、９４０ｂとが、ネットワーク３００を介して接続された構成となっている。
【００９３】
第２の実施の形態では、ＳＩＰクライアント９４０の機能、認証サーバ９２０の認証状態送信部９２４の機能、および、ＳＩＰプロキシ９００の通信要求受信部９０２、通信仲介部９０３、認証状態受信部９０４の機能が第１の実施の形態と異なっている。その他の構成および機能は、第１の実施の形態にかかる通信システム１０の構成を表すブロック図である図２と同様であるので、同一符号を付し、ここでの説明は省略する。
【００９４】
ＳＩＰクライアント９４０は、ＩＮＶＩＴＥリクエストではなく、ＳＵＢＳＣＲＩＢＥリクエストによって通信の開始を要求する通信要求メッセージを送信する点が、第１の実施の形態のＳＩＰクライアント４００と異なっている。
【００９５】
認証サーバ９２０の認証状態送信部９２４は、ＳＩＰクライアント９４０の認証状態を、認証状態を含むＳＩＰのＮＯＴＩＦＹリクエストとして送信するものである。
【００９６】
ＳＩＰプロキシ９００の通信要求受信部９０２は、ＳＩＰクライアント９４０から認証サーバ９２０に対する通信の開始を要求する通信要求メッセージとして、ＳＵＢＳＣＲＩＢＥリクエストを受信するものである。
【００９７】
通信仲介部９０３は、受信したＳＵＢＳＣＲＩＢＥリクエストを認証サーバ９２０に送信し、認証サーバ９２０から返信された応答（ＮＯＴＩＦＹ）に従い、ＳＩＰクライアント９４０と認証サーバ９２０との間の通信を仲介するものである。また、通信仲介部９０３は、通信を仲介した場合、接続情報テーブル１２２に仲介した通信に関する接続情報を記憶する。
【００９８】
認証状態受信部９０４は、通信を開始した認証サーバ９２０から、ＳＩＰクライアント９４０の認証状態を受信するものである。本実施の形態では、認証サーバ９２０は、認証状態を含むＮＯＴＩＦＹリクエストを送信するため、認証状態受信部９０４は、認証サーバ９２０からＮＯＴＩＦＹリクエストを認証状態として受信する。
【００９９】
次に、このように構成された第２の実施の形態にかかるＳＩＰプロキシ９００による通信仲介処理について説明する。図１０は、第２の実施の形態における通信仲介処理の全体の流れを示すフローチャートである。
【０１００】
ステップＳ１００１からステップＳ１００３までの、クライアント登録処理は、第１の実施の形態にかかるＳＩＰプロキシ１００におけるステップＳ６０１からステップＳ６０３までと同様の処理なので、その説明を省略する。
【０１０１】
次に、ＳＩＰクライアント９４０が、認証サーバ９２０との間の通信の開始を要求する通信要求メッセージとしてＳＵＢＳＣＲＩＢＥリクエストをＳＩＰプロキシ９００に対して送信する（ステップＳ１００４）。
【０１０２】
次に、ＳＩＰプロキシ９００の通信要求受信部１０２は、ＳＩＰクライアント９４０からＳＵＢＳＣＲＩＢＥリクエストを受信し、認証サーバ９２０に対して転送する（ステップＳ１００５）。
【０１０３】
認証サーバ９２０の応答部２０１は、ＳＵＢＳＣＲＩＢＥリクエストを受信し、当該ＳＵＢＳＣＲＩＢＥリクエストに対する応答（ＮＯＴＩＦＹリクエスト）をＳＩＰプロキシ９００に返信する（ステップＳ１００６）。ここでは、通信の開始を認可する応答を送信したものとする。
【０１０４】
次に、ＳＩＰプロキシ９００の通信仲介部９０３は、ＳＩＰクライアント９４０と認証サーバ９２０との通信を仲介し、仲介した通信に関する接続情報を接続情報テーブル１２２に登録する（ステップＳ１００７）。この接続情報が表す接続状態は、ＳＵＢＳＣＲＩＢＥリクエストにより開始されたダイアログである。このダイアログは、ＳＩＰクライアント９４０と認証サーバ９２０が直接通信する認証情報の状態を認証サーバ９２０からＳＩＰプロキシ９００に通知するために用いられる。
【０１０５】
なお、本実施の形態では、認証サーバ９２０とＳＩＰクライアント９４０との間の直接通信の形態は問わない。任意の方法で接続された直接通信により認証情報が送受信され、当該認証情報を用いた認証処理の結果が、上記ダイアログを介して認証サーバ９２０からＳＩＰプロキシ９００に対して送信される。
【０１０６】
ステップＳ１００８からステップＳ１０１１までの、成功通知処理、認証情報送信処理、および認証処理は、第１の実施の形態にかかるＳＩＰプロキシ１００におけるステップＳ６０８からステップＳ６１１までと同様の処理なので、その説明を省略する。
【０１０７】
次に、認証状態送信部９２４は、認証状態をＳＩＰクライアント９４０に送信する（ステップＳ１０１２）。また、認証状態送信部９２４は、認証状態をＮＯＴＩＦＹリクエストとしてＳＩＰプロキシ９００に送信する（ステップＳ１０１３）。
【０１０８】
ＳＩＰプロキシ９００の認証状態受信部９０４は、ＮＯＴＩＦＹリクエストを受信し、当該ＮＯＴＩＦＹリクエストに含まれる認証状態に応じて認証状態として「有効」または「無効」を認証状態テーブル１２３に保存する（ステップＳ１０１４）。
【０１０９】
このように、第２の実施の形態にかかる仲介サーバでは、ＳＩＰのＳＵＢＳＣＲＩＢＥリクエストによって開始された通信を用いて認証サーバと通信端末との間で任意の方法および頻度で実行された認証処理の結果を当該認証サーバから受信し、通信端末の認証状態を判断することができる。このため、ＩＮＶＩＴＥリクエストで確立されたデータチャネル以外の任意の通信チャネルを用いて認証情報を送受信することが可能となる。
【０１１０】
図１１は、第１または第２の実施の形態にかかる仲介サーバのハードウェア構成を示す説明図である。
【０１１１】
第１または第２の実施の形態にかかる仲介サーバは、ＣＰＵ（Central Processing Unit）５１などの制御装置と、ＲＯＭ（Read Only Memory）５２やＲＡＭ５３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ５４と、ＨＤＤ（Hard Disk Drive）、ＣＤ（Compact Disc）ドライブ装置などの外部記憶装置と、ディスプレイ装置などの表示装置と、キーボードやマウスなどの入力装置と、各部を接続するバス６１を備えており、通常のコンピュータを利用したハードウェア構成となっている。
【０１１２】
第１または第２の実施の形態にかかる仲介サーバで実行される通信仲介プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact Disk Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。
【０１１３】
また、第１または第２の実施の形態にかかる仲介サーバで実行される通信仲介プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、第１または第２の実施の形態にかかる仲介サーバで実行される通信仲介プログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
【０１１４】
また、第１または第２の実施の形態の通信仲介プログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。
【０１１５】
第１または第２の実施の形態にかかる仲介サーバで実行される通信仲介プログラムは、上述した各部（登録要求受信部、通信要求受信部、通信仲介部、認証状態受信部、判断部、通信切断部、通知受信部、通知部）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ５１（プロセッサ）が上記記憶媒体から通信仲介プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、上述した各部が主記憶装置上に生成されるようになっている。
【産業上の利用可能性】
【０１１６】
以上のように、本発明にかかる仲介サーバ、通信仲介方法、通信仲介プログラム、および通信システムは、生体情報や画像情報などのようにデータ用量の大きい認証情報を用いてリアルタイム認証を行う仲介サーバ、通信仲介方法、および通信仲介プログラムに適している。
【図面の簡単な説明】
【０１１７】
【図１】第１の実施の形態にかかる通信システムの特徴を説明するための説明図である。
【図２】第１の実施の形態にかかる通信システムの構成を示すブロック図である。
【図３】登録情報テーブルのデータ構造の一例を示す説明図である。
【図４】接続情報テーブルのデータ構造の一例を示す説明図である。
【図５】認証状態テーブルのデータ構造の一例を示す説明図である。
【図６】第１の実施の形態における通信仲介処理の全体の流れを示すフローチャートである。
【図７】第１の実施の形態における制御要求仲介処理の全体の流れを示すフローチャートである。
【図８】第２の実施の形態にかかる通信システムの特徴を説明するための説明図である。
【図９】第２の実施の形態にかかる通信システムの構成を示すブロック図である。
【図１０】第２の実施の形態における通信仲介処理の全体の流れを示すフローチャートである。
【図１１】第１または第２の実施の形態にかかる仲介サーバのハードウェア構成を示す説明図である。
【符号の説明】
【０１１８】
５１ ＣＰＵ
５２ ＲＯＭ
５３ ＲＡＭ
５４ 通信Ｉ／Ｆ
６１ バス
１０ 通信システム
８０ 通信システム
１００ ＳＩＰプロキシ
１０１ 登録要求受信部
１０２ 通信要求受信部
１０３ 通信仲介部
１０４ 認証状態受信部
１０５ 判断部
１０６ 通信切断部
１０７ 通知受信部
１０８ 通知部
１２０ 記憶部
１２１ 登録情報テーブル
１２２ 接続情報テーブル
１２３ 認証状態テーブル
２００ 認証サーバ
２０１ 応答部
２０２ 認証情報受信部
２０３ 認証部
２０４ 認証状態送信部
３００ ネットワーク
４００ ＳＩＰクライアント
９００ ＳＩＰプロキシ
９０２ 通信要求受信部
９０３ 通信仲介部
９０４ 認証状態受信部
９２０ 認証サーバ
９２４ 認証状態送信部
９４０ ＳＩＰクライアント
【特許請求の範囲】
【請求項１】
通信端末と前記通信端末の認証を行う認証サーバとの間の通信を仲介する仲介サーバであって、
前記認証サーバに対する通信の開始を要求する通信要求メッセージを前記通信端末から受信する通信要求受信部と、
受信した前記通信要求メッセージに対応して、前記通信端末と前記認証サーバとの間の通信を仲介する通信仲介部と、
前記認証サーバから前記通信端末に対する認証状態を受信する認証状態受信部と、
受信した前記認証状態に基づいて前記通信端末の認証の可否を判断する判断部と、
を備えたことを特徴とする仲介サーバ。
【請求項２】
前記通信端末ごとの認証状態を記憶する認証状態記憶部をさらに備え、
前記判断部は、前記認証状態記憶部に保存された前記認証状態に基づいて前記通信端末の認証の可否を判断すること、
を特徴とする請求項１に記載の仲介サーバ。
【請求項３】
前記通信端末間の通信に関する通知メッセージを前記通信端末から受信する通知受信部と、
前記通知メッセージの通知先である前記通信端末に前記通知メッセージを通知する第１通知部と、をさらに備え、
前記判断部は、前記通知メッセージを送信した前記通信端末の前記認証状態を前記認証状態記憶部から取得し、取得した前記認証状態に基づいて、前記通知メッセージを送信した前記通信端末の認証の可否を判断し、
前記第１通知部は、前記判断部により前記通知メッセージを送信した前記通信端末が認証されていると判断された場合に、前記通知メッセージを通知先である前記通信端末に通知すること、
を特徴とする請求項２に記載の仲介サーバ。
【請求項４】
前記判断部により前記通信端末が認証されていないと判断された場合に、認証されていないと判断された前記通信端末に関する通信を切断する通信切断部をさらに備えたこと、
を特徴とする請求項１に記載の仲介サーバ。
【請求項５】
仲介した通信に関する情報である接続情報を記憶可能な接続情報記憶部をさらに備え、
前記通信仲介部は、前記通信端末と前記認証サーバとの間の通信を仲介したときに、仲介した通信に関する前記接続情報を前記接続情報記憶部に保存し、
前記通信切断部は、通信を切断した場合に、前記接続情報記憶部から切断した通信に関する前記接続情報を削除すること、
を特徴とする請求項４に記載の仲介サーバ。
【請求項６】
前記認証サーバから受信した前記認証状態を前記通信端末に通知する第２通知部をさらに備えたこと、
を特徴とする請求項１に記載の仲介サーバ。
【請求項７】
前記通信要求受信部は、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）のＩＮＶＩＴＥリクエストを前記通信要求メッセージとして受信すること、
を特徴とする請求項１に記載の仲介サーバ。
【請求項８】
前記認証状態受信部は、ＳＩＰのＢＹＥリクエストを前記通信端末が認証されなかったときの前記認証状態として受信すること、
を特徴とする請求項７に記載の仲介サーバ。
【請求項９】
前記認証状態受信部は、ＳＩＰのＩＮＶＩＴＥリクエストを前記通信端末が認証されたときの前記認証状態として受信すること、
を特徴とする請求項７に記載の仲介サーバ。
【請求項１０】
前記通信要求受信部は、ＳＩＰのＳＵＢＳＣＲＩＢＥリクエストを前記通信要求メッセージとして受信すること、
を特徴とする請求項１に記載の仲介サーバ。
【請求項１１】
前記認証状態受信部は、前記認証状態を含むＳＩＰのＮＯＴＩＦＹリクエストを受信すること、
を特徴とする請求項１０に記載の仲介サーバ。
【請求項１２】
通信の仲介を依頼する前記通信端末として登録することを要求する登録要求メッセージを前記通信端末から受信する登録要求受信部と、
前記登録要求メッセージを受信した場合に、前記認証サーバに関する情報を前記通信端末に通知する第３通知部と、をさらに備えたこと、
を特徴とする請求項１に記載の仲介サーバ。
【請求項１３】
前記認証状態受信部は、前記通信端末との間で連続認証を行う前記認証サーバから、前記連続認証によって得られる前記認証状態を受信すること、
を特徴とする請求項１に記載の仲介サーバ。
【請求項１４】
通信端末と前記通信端末の認証を行う認証サーバとの間の通信を仲介する仲介サーバにおける通信仲介方法であって、
通信要求受信部によって、前記認証サーバに対する通信の開始を要求する通信要求メッセージを前記通信端末から受信する通信要求受信ステップと、
通信仲介部によって、受信した前記通信要求メッセージに対応して、前記通信端末と前記認証サーバとの間の通信を仲介する通信仲介ステップと、
認証状態受信部によって、前記認証サーバから前記通信端末に対する認証状態を受信する認証状態受信ステップと、
判断部によって、受信した前記認証状態に基づいて前記通信端末の認証の可否を判断する判断ステップと、
を備えたことを特徴とする通信仲介方法。
【請求項１５】
通信端末と前記通信端末の認証を行う認証サーバとの間の通信を仲介する仲介サーバにおける通信仲介プログラムであって、
前記認証サーバに対する通信の開始を要求する通信要求メッセージを前記通信端末から受信する通信要求受信手順と、
受信した前記通信要求メッセージに対応して、前記通信端末と前記認証サーバとの間の通信を仲介する通信仲介手順と、
前記認証サーバから前記通信端末に対する認証状態を受信する認証状態受信手順と、
受信した前記認証状態に基づいて前記通信端末の認証の可否を判断する判断手順と、
をコンピュータに実行させる通信仲介プログラム。
【請求項１６】
通信端末の認証を行う認証サーバと、前記通信端末とネットワークを介して接続され、前記通信端末と前記認証サーバとの間の通信を仲介する仲介サーバとを備えた通信システムであって、
前記仲介サーバは、
前記認証サーバに対する通信の開始を要求する通信要求メッセージを前記通信端末から受信する通信要求受信部と、
受信した前記通信要求メッセージに対応して、前記通信端末と前記認証サーバとの間の通信を仲介する通信仲介部と、
前記認証サーバから前記通信端末に対する認証状態を受信する認証状態受信部と、
受信した前記認証状態に基づいて前記通信端末の認証の可否を判断する判断部と、を備え、
前記認証サーバは、
前記通信端末から認証に用いる認証情報を受信する認証情報受信部と、
受信した前記認証情報を用いて前記通信端末の認証を行う認証部と、
前記認証状態を前記仲介サーバに送信する認証状態送信部と、を備えたこと、
を特徴とする通信システム。
【請求項１】
通信端末と前記通信端末の認証を行う認証サーバとの間の通信を仲介する仲介サーバであって、
前記認証サーバに対する通信の開始を要求する通信要求メッセージを前記通信端末から受信する通信要求受信部と、
受信した前記通信要求メッセージに対応して、前記通信端末と前記認証サーバとの間の通信を仲介する通信仲介部と、
前記認証サーバから前記通信端末に対する認証状態を受信する認証状態受信部と、
受信した前記認証状態に基づいて前記通信端末の認証の可否を判断する判断部と、
を備えたことを特徴とする仲介サーバ。
【請求項２】
前記通信端末ごとの認証状態を記憶する認証状態記憶部をさらに備え、
前記判断部は、前記認証状態記憶部に保存された前記認証状態に基づいて前記通信端末の認証の可否を判断すること、
を特徴とする請求項１に記載の仲介サーバ。
【請求項３】
前記通信端末間の通信に関する通知メッセージを前記通信端末から受信する通知受信部と、
前記通知メッセージの通知先である前記通信端末に前記通知メッセージを通知する第１通知部と、をさらに備え、
前記判断部は、前記通知メッセージを送信した前記通信端末の前記認証状態を前記認証状態記憶部から取得し、取得した前記認証状態に基づいて、前記通知メッセージを送信した前記通信端末の認証の可否を判断し、
前記第１通知部は、前記判断部により前記通知メッセージを送信した前記通信端末が認証されていると判断された場合に、前記通知メッセージを通知先である前記通信端末に通知すること、
を特徴とする請求項２に記載の仲介サーバ。
【請求項４】
前記判断部により前記通信端末が認証されていないと判断された場合に、認証されていないと判断された前記通信端末に関する通信を切断する通信切断部をさらに備えたこと、
を特徴とする請求項１に記載の仲介サーバ。
【請求項５】
仲介した通信に関する情報である接続情報を記憶可能な接続情報記憶部をさらに備え、
前記通信仲介部は、前記通信端末と前記認証サーバとの間の通信を仲介したときに、仲介した通信に関する前記接続情報を前記接続情報記憶部に保存し、
前記通信切断部は、通信を切断した場合に、前記接続情報記憶部から切断した通信に関する前記接続情報を削除すること、
を特徴とする請求項４に記載の仲介サーバ。
【請求項６】
前記認証サーバから受信した前記認証状態を前記通信端末に通知する第２通知部をさらに備えたこと、
を特徴とする請求項１に記載の仲介サーバ。
【請求項７】
前記通信要求受信部は、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）のＩＮＶＩＴＥリクエストを前記通信要求メッセージとして受信すること、
を特徴とする請求項１に記載の仲介サーバ。
【請求項８】
前記認証状態受信部は、ＳＩＰのＢＹＥリクエストを前記通信端末が認証されなかったときの前記認証状態として受信すること、
を特徴とする請求項７に記載の仲介サーバ。
【請求項９】
前記認証状態受信部は、ＳＩＰのＩＮＶＩＴＥリクエストを前記通信端末が認証されたときの前記認証状態として受信すること、
を特徴とする請求項７に記載の仲介サーバ。
【請求項１０】
前記通信要求受信部は、ＳＩＰのＳＵＢＳＣＲＩＢＥリクエストを前記通信要求メッセージとして受信すること、
を特徴とする請求項１に記載の仲介サーバ。
【請求項１１】
前記認証状態受信部は、前記認証状態を含むＳＩＰのＮＯＴＩＦＹリクエストを受信すること、
を特徴とする請求項１０に記載の仲介サーバ。
【請求項１２】
通信の仲介を依頼する前記通信端末として登録することを要求する登録要求メッセージを前記通信端末から受信する登録要求受信部と、
前記登録要求メッセージを受信した場合に、前記認証サーバに関する情報を前記通信端末に通知する第３通知部と、をさらに備えたこと、
を特徴とする請求項１に記載の仲介サーバ。
【請求項１３】
前記認証状態受信部は、前記通信端末との間で連続認証を行う前記認証サーバから、前記連続認証によって得られる前記認証状態を受信すること、
を特徴とする請求項１に記載の仲介サーバ。
【請求項１４】
通信端末と前記通信端末の認証を行う認証サーバとの間の通信を仲介する仲介サーバにおける通信仲介方法であって、
通信要求受信部によって、前記認証サーバに対する通信の開始を要求する通信要求メッセージを前記通信端末から受信する通信要求受信ステップと、
通信仲介部によって、受信した前記通信要求メッセージに対応して、前記通信端末と前記認証サーバとの間の通信を仲介する通信仲介ステップと、
認証状態受信部によって、前記認証サーバから前記通信端末に対する認証状態を受信する認証状態受信ステップと、
判断部によって、受信した前記認証状態に基づいて前記通信端末の認証の可否を判断する判断ステップと、
を備えたことを特徴とする通信仲介方法。
【請求項１５】
通信端末と前記通信端末の認証を行う認証サーバとの間の通信を仲介する仲介サーバにおける通信仲介プログラムであって、
前記認証サーバに対する通信の開始を要求する通信要求メッセージを前記通信端末から受信する通信要求受信手順と、
受信した前記通信要求メッセージに対応して、前記通信端末と前記認証サーバとの間の通信を仲介する通信仲介手順と、
前記認証サーバから前記通信端末に対する認証状態を受信する認証状態受信手順と、
受信した前記認証状態に基づいて前記通信端末の認証の可否を判断する判断手順と、
をコンピュータに実行させる通信仲介プログラム。
【請求項１６】
通信端末の認証を行う認証サーバと、前記通信端末とネットワークを介して接続され、前記通信端末と前記認証サーバとの間の通信を仲介する仲介サーバとを備えた通信システムであって、
前記仲介サーバは、
前記認証サーバに対する通信の開始を要求する通信要求メッセージを前記通信端末から受信する通信要求受信部と、
受信した前記通信要求メッセージに対応して、前記通信端末と前記認証サーバとの間の通信を仲介する通信仲介部と、
前記認証サーバから前記通信端末に対する認証状態を受信する認証状態受信部と、
受信した前記認証状態に基づいて前記通信端末の認証の可否を判断する判断部と、を備え、
前記認証サーバは、
前記通信端末から認証に用いる認証情報を受信する認証情報受信部と、
受信した前記認証情報を用いて前記通信端末の認証を行う認証部と、
前記認証状態を前記仲介サーバに送信する認証状態送信部と、を備えたこと、
を特徴とする通信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００８−８３８５９（Ｐ２００８−８３８５９Ａ）
【公開日】平成２０年４月１０日（２００８．４．１０）
【国際特許分類】
【出願番号】特願２００６−２６１３５４（Ｐ２００６−２６１３５４）
【出願日】平成１８年９月２６日（２００６．９．２６）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２０年４月１０日（２００８．４．１０）
【国際特許分類】
【出願日】平成１８年９月２６日（２００６．９．２６）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]