JP2009164802A - 通信制御システム、通信制御方法、および通信制御プログラム - Google Patents

通信制御システム、通信制御方法、および通信制御プログラム Download PDF

Info

Publication number
JP2009164802A
JP2009164802A JP2007340744A JP2007340744A JP2009164802A JP 2009164802 A JP2009164802 A JP 2009164802A JP 2007340744 A JP2007340744 A JP 2007340744A JP 2007340744 A JP2007340744 A JP 2007340744A JP 2009164802 A JP2009164802 A JP 2009164802A
Authority
JP
Japan
Prior art keywords
communication
communication device
authentication result
authentication
party
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2007340744A
Other languages
English (en)
Other versions
JP4851439B2 (ja
Inventor
Shoji Toyama
将司 外山
Koji Murakami
幸司 村上
Yoshiko Sueda
欣子 末田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2007340744A priority Critical patent/JP4851439B2/ja
Publication of JP2009164802A publication Critical patent/JP2009164802A/ja
Application granted granted Critical
Publication of JP4851439B2 publication Critical patent/JP4851439B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Telephonic Communication Services (AREA)

Abstract

【課題】 回線単位の認証に限られることなく認証の手法を柔軟に選択することを課題とする。
【解決手段】第1の通信装置と第1の通信にて通信可能に接続された第三者機関装置は、認証要求を当該第1の通信装置から第1の通信にて受信すると、当該第1の通信装置を認証し、認証結果を当該第1の通信装置に第1の通信にて送信し、第三者機関装置との間で第1の通信を行うとともに第2の通信装置との間で第2の通信を行う第1の通信装置は、第2の通信装置との間で第2の通信を確立する前に、認証要求を第三者機関装置に第1の通信にて送信し、第1の通信にて送信された認証結果を第2の通信装置に第2の通信を確立する過程において送信し、第2の通信装置は、認証結果を受信すると、当該認証結果に基づいて、当該第1の通信装置との間で第2の通信を確立するか否かの認可判定を行う。
【選択図】 図1

Description

本発明は、通信制御システム、通信制御方法、および通信制御プログラムに関する。
従来より、VoIP(Voice over Internet Protocol)やVPN(Virtual Private Network)など、SIP(Session Initiation Protocol)通信を用いたSIPサービスにおいては、電気通信事業者が、電話番号、SIP−URI(Uniform Resource Identifier)、IMS(IP Multimedia Subsystem)のpublic ID、private ID、回線契約を示すSubNoなどの認証情報に基づいて、発信側の通信装置と着信側の通信装置との間のSIP通信確立を制御してきた。例えば、着信側の通信装置から、番号非通知の着信を拒否する設定(非通知着信拒否)や、指定する番号の着信を拒否する設定(番号指定着信拒否)などがなされている場合には、電気通信事業者は、発信側の通信装置の電話番号などの認証情報に基づいて、着信側の通信装置との間のSIP通信確立を認可すべきか否かを判定してきた。
また、非特許文献1には、発信側の通信装置と着信側の通信装置との間のSIP通信確立の前に、電気通信事業者が、自ら管理する属性情報(発信者側の通信装置を利用する利用者に関する情報)を、証明書形式で着信側の通信装置に送信するSIP−SAML(Security Assertion Markup Language)方式という手法が提案されている。
具体的には、SIPとは、IP(Internet Protocol)電話などの通信を制御することを目的として策定されたプロトコルであり、SAMLとは、認証、認可、属性情報をXML(Extensible Markup Language)で記述されたデータで交換することを目的として策定されたプロトコルである。つまり、SIP−SAML方式とは、図14に示すように、SIPの構成要素であるSIPプロキシが、SAMLの構成要素である認証機関(非特許文献1においては、AS(Authentication Service))から発信側の通信装置を利用する利用者の属性情報を証明書形式で取得し、取得した証明書を、発信側の通信装置から着信側の通信装置に送信されたSIPメッセージに付加することで、着信側の通信装置に証明書を送信する手法である。
"SIP SAML Profile and Binding"、[online]、[平成19年11月26日検索]、インターネット<http://tools.ietf.org/html/draft-ietf-sip-saml-02>
ところで、上記した従来の技術では、回線単位の認証に基づく制御しかできないという課題があった。すなわち、電話番号などの認証情報に基づいて通信確立を制御する方式では、発信側の通信装置を、当該発信側の通信装置が接続されている回線に基づいて認証しているにすぎない。また、発信側の通信装置を利用する利用者の属性情報を送信するSIP−SAML方式であっても、電気通信事業者は、発信側の通信装置が接続されている回線に基づいて、当該発信側の通信装置を利用している利用者を契約時の利用者であるとみなしているにすぎず、また、属性オーソリティが管理している属性情報を用いるという意味で回線に基づく認証を強化しているに過ぎず、発信側の通信装置を現に利用している利用者の属性情報を送信していることにはならない。
そこで、本発明は、上記した従来技術の課題を解決するためになされたものであり、回線単位の認証に限られることなく認証の手法を柔軟に選択することが可能な通信制御システム、通信制御方法、および通信制御プログラムを提供することを目的とする。
上記した課題を解決し、目的を達成するため、請求項1に係る発明は、第1の通信装置と第2の通信装置との間における通信の確立を制御する通信制御システムであって、前記第1の通信装置と第1の通信にて通信可能に接続された第三者機関装置は、前記第1の通信装置を認証することを要求する認証要求を当該第1の通信装置から前記第1の通信にて受信すると、当該第1の通信装置を認証する認証手段と、前記認証手段によって前記第1の通信装置が認証されると、認証結果を当該第1の通信装置に前記第1の通信にて送信する認証結果送信手段とを備え、前記第三者機関装置との間で前記第1の通信を行うとともに前記第2の通信装置との間で第2の通信を行う前記第1の通信装置は、前記第2の通信装置との間で前記第2の通信を確立する前に、前記認証要求を前記第三者機関装置に前記第1の通信にて送信する認証要求送信手段と、前記認証結果送信手段によって前記第1の通信にて送信された認証結果を受信すると、当該認証結果を前記第2の通信装置に前記第2の通信を確立する過程において送信する認証結果送信手段とを備え、前記第2の通信装置は、前記第1の通信装置の認証結果送信手段によって送信された認証結果を受信すると、当該認証結果に基づいて、当該第1の通信装置との間で前記第2の通信を確立するか否かの認可判定を行う認可判定手段を備えたことを特徴とする。
また、請求項2に係る発明は、上記の発明において、前記第2の通信は、SIPによって確立される通信であることを特徴とする。
また、請求項3に係る発明は、上記の発明において、前記第三者機関装置の認証結果送信手段は、前記認証結果を検証可能な形式で送信し、前記第2の通信装置は、前記第1の通信装置の認証結果送信手段によって送信された認証結果が検証可能な形式である場合には、当該認証結果に関する事実を検証する認証結果検証手段をさらに備え、前記認可判定手段は、受信した認証結果の他に、前記認証結果検証手段によって検証された当該認証結果に関する事実にも基づいて、前記認可判定を行うことを特徴とする。
また、請求項4に係る発明は、上記の発明において、前記第1の通信装置は、複数の第三者機関装置と第1の通信にて通信可能に接続されるものであって、前記認証要求送信手段は、前記認証要求を、前記複数の第三者機関装置から選択した一つまたは複数の第三者機関装置に送信することを特徴とする。
また、請求項5に係る発明は、上記の発明において、前記第2の通信装置は、前記認証結果を当該第2の通信装置に送信することを前記第1の通信装置に対して要求する認証結果要求手段をさらに備え、前記第1の通信装置の認証要求送信手段は、前記認証結果要求手段によって前記認証結果を前記第2の通信装置に送信することを要求された場合に、前記認証要求を前記第三者機関装置に送信することを特徴とする。
また、請求項6に係る発明は、上記の発明において、前記第2の通信装置の認証結果要求手段は、前記認証結果を所定の第三者機関装置から取得して前記第2の通信装置に送信することを要求し、前記第1の通信装置の認証要求送信手段は、前記認証結果要求手段によって前記認証結果を前記所定の第三者機関装置から取得して前記第2の通信装置に送信することを要求された場合に、前記認証要求を当該所定の第三者機関装置に送信することを特徴とする。
また、請求項7に係る発明は、第1の通信装置と第2の通信装置との間における通信の確立を制御する通信制御システムの当該第1の通信装置であって、第三者機関装置との間で第1の通信を行うとともに前記第2の通信装置との間で第2の通信を行う前記第1の通信装置は、前記第2の通信装置との間で前記第2の通信を確立する前に、当該第1の通信装置を認証することを要求する認証要求を、当該第1の通信装置を認証する第三者機関装置に前記第1の通信にて送信する認証要求送信手段と、前記第三者機関装置によって認証された認証結果を当該第三者機関装置から前記第1の通信にて受信すると、前記第2の通信装置において当該認証結果に基づいて当該第1の通信装置との間で前記第2の通信を確立するか否かの認可判定が行われるように、当該認証結果を当該第2の通信装置に当該第2の通信を確立する過程において送信する認証結果送信手段とを備えたことを特徴とする。
また、請求項8に係る発明は、第1の通信装置と第2の通信装置との間における通信の確立を制御する通信制御システムの当該第2の通信装置であって、前記第1の通信装置との間で第2の通信を行う前記第2の通信装置は、前記第1の通信装置を認証する第三者機関装置から当該第1の通信装置が第1の通信にて受信した認証結果を、当該第1の通信装置との間で前記第2の通信を確立する前に当該第1の通信装置から受信すると、当該認証結果に基づいて、当該第1の通信装置との間で当該第2の通信を確立するか否かの認可判定を行う認可判定手段を備えたことを特徴とする。
また、請求項9に係る発明は、第1の通信装置と第2の通信装置との間における通信の確立を制御する通信制御方法であって、第三者機関装置との間で第1の通信を行うとともに前記第2の通信装置との間で第2の通信を行う前記第1の通信装置は、前記第2の通信装置との間で前記第2の通信を確立する前に、当該第1の通信装置を認証することを要求する認証要求を、当該第1の通信装置を認証する第三者機関装置に前記第1の通信にて送信する認証要求送信工程と、前記第三者機関装置によって認証された認証結果を当該第三者機関装置から前記第1の通信にて受信すると、前記第2の通信装置において当該認証結果に基づいて当該第1の通信装置との間で前記第2の通信を確立するか否かの認可判定が行われるように、当該認証結果を当該第2の通信装置に当該第2の通信を確立する過程において送信する認証結果送信工程とを含むことを特徴とする。
また、請求項10に係る発明は、第1の通信装置と第2の通信装置との間における通信の確立を制御する通信制御方法であって、前記第1の通信装置との間で第2の通信を行う前記第2の通信装置は、前記第1の通信装置を認証する第三者機関装置から当該第1の通信装置が第1の通信にて受信した認証結果を、当該第1の通信装置との間で前記第2の通信を確立する前に当該第1の通信装置から受信すると、当該認証結果に基づいて、当該第1の通信装置との間で当該第2の通信を確立するか否かの認可判定を行う認可判定工程を含んだことを特徴とする。
また、請求項11に係る発明は、第1の通信装置と第2の通信装置との間における通信の確立を制御する通信制御方法を当該第1の通信装置としてのコンピュータに実行させる通信制御プログラムであって、第三者機関装置との間で第1の通信を行うとともに前記第2の通信装置との間で第2の通信を行う前記第1の通信装置としてのコンピュータに、前記第2の通信装置との間で前記第2の通信を確立する前に、当該第1の通信装置を認証することを要求する認証要求を、当該第1の通信装置を認証する第三者機関装置に前記第1の通信にて送信する認証要求送信手順と、前記第三者機関装置によって認証された認証結果を当該第三者機関装置から前記第1の通信にて受信すると、前記第2の通信装置において当該認証結果に基づいて当該第1の通信装置との間で前記第2の通信を確立するか否かの認可判定が行われるように、当該認証結果を当該第2の通信装置に当該第2の通信を確立する過程において送信する認証結果送信手順とを実行させることを特徴とする。
また、請求項12に係る発明は、第1の通信装置と第2の通信装置との間における通信の確立を制御する通信制御方法を当該第2の通信装置としてのコンピュータに実行させる通信制御プログラムであって、前記第1の通信装置との間で第2の通信を行う前記第2の通信装置としてのコンピュータに、前記第1の通信装置を認証する第三者機関装置から当該第1の通信装置が第1の通信にて受信した認証結果を、当該第1の通信装置との間で前記第2の通信を確立する前に当該第1の通信装置から受信すると、当該認証結果に基づいて、当該第1の通信装置との間で当該第2の通信を確立するか否かの認可判定を行う認可判定手順を実行させることを特徴とする。
請求項1または7〜12の発明によれば、第1の通信装置と第2の通信装置との間における通信の確立を制御する通信制御システムであって、第1の通信装置と第1の通信にて通信可能に接続された第三者機関装置は、第1の通信装置を認証することを要求する認証要求を当該第1の通信装置から第1の通信にて受信すると、当該第1の通信装置を認証し、第1の通信装置を認証すると、認証結果を当該第1の通信装置に第1の通信にて送信し、第三者機関装置との間で第1の通信を行うとともに第2の通信装置との間で第2の通信を行う第1の通信装置は、第2の通信装置との間で第2の通信を確立する前に、認証要求を第三者機関装置に第1の通信にて送信し、第1の通信にて送信された認証結果を受信すると、当該認証結果を第2の通信装置に第2の通信を確立する過程において送信し、第2の通信装置は、第1の通信装置によって送信された認証結果を受信すると、当該認証結果に基づいて、当該第1の通信装置との間で第2の通信を確立するか否かの認可判定を行うので、回線単位の認証に限られることなく認証の手法を柔軟に選択することが可能になる。
また、請求項2の発明によれば、第2の通信は、SIPによって確立される通信であるので、柔軟に選択された手法による認証の認証結果に基づいて、SIPによって通信を確立することが可能になる。
また、請求項3の発明によれば、第三者機関装置は、認証結果を検証可能な形式で送信し、第2の通信装置は、第1の通信装置によって送信された認証結果が検証可能な形式である場合には、当該認証結果に関する事実を検証し、受信した認証結果の他に、検証された当該認証結果に関する事実にも基づいて、認可判定を行うので、信用性の高い認証の手法を柔軟に選択することが可能になる。
また、請求項4の発明によれば、第1の通信装置は、複数の第三者機関装置と第1の通信にて通信可能に接続されるものであって、認証要求を、複数の第三者機関装置から選択した一つまたは複数の第三者機関装置に送信するので、インターネットなどのIPネットワーク上に存在する1つ以上の証明機関が発行する認証情報(認証結果)を流通させることができ、多様な認証の手法を柔軟に選択することが可能になる。
また、請求項5の発明によれば、第2の通信装置は、認証結果を当該第2の通信装置に送信することを第1の通信装置に対して要求し、認証結果を第2の通信装置に送信することを要求された場合に、認証要求を第三者機関装置に送信するので、認証情報(認証結果)が不要な通信相手に対して認証情報(認証結果)を送信してしまうことを防ぐことが可能になる。
また、請求項6の発明によれば、第2の通信装置は、認証結果を所定の第三者機関装置から取得して第2の通信装置に送信することを要求し、第1の通信装置は、認証結果を所定の第三者機関装置から取得して第2の通信装置に送信することを要求された場合に、認証要求を所定の第三者機関装置に送信するので、通信相手から指定された認証情報(認証結果)を送信することから、通信相手にとって適切な認証の手法を柔軟に選択することが可能になる。
以下に添付図面を参照して、本発明に係る通信制御システム、通信制御方法、および通信制御プログラムの実施例を詳細に説明する。なお、以下では、以下の実施例で用いる主要な用語、実施例1に係る通信制御システムの概要および特徴、実施例1に係る通信制御システムの構成、実施例1に係る通信制御システムによる処理の手順、実施例1の効果を順に説明し、続いて、他の実施例について説明する。
[用語の説明]
まず最初に、以下の実施例で用いる主要な用語を説明する。以下の実施例において、「通信制御システム」は、通信装置と通信装置との間における通信の確立を制御するものである。ここで、「通信の確立」の意味であるが、SIP通信を想定して例示すると、まず、発信側の通信装置(発信者装置)が、着信側の通信装置(着信者装置)に対して『INVITE』メッセージを送信し、これに応答して、着信側の通信装置が、発信側の通信装置に対して『200 OK』メッセージを送信し、さらにこれに応答して、発信側の通信装置が、着信側の通信装置に対して『ACK』メッセージを送信すると、発信側の通信装置と着信側の通信装置との間で通信が確立され、例えば、音声通話が可能になる。このように、発信側の通信装置と着信側の通信装置との間では、「通信の確立」の前に制御メッセージの送受信がなされており、「通信制御システム」は、かかる制御メッセージの送受信を制御することで、「通信の確立」を制御する。
次に、「通信の確立を制御する」の意味であるが、「通信制御システム」は、全ての通信を確立するように制御すればよいというものではなく、場合によっては、通信の確立を認可しないよう制御しなければならないこともある。例えば、着信側の通信装置から、番号非通知の着信を拒否する設定(非通知着信拒否)や、指定する番号の着信を拒否する設定(番号指定着信拒否)などがなされている場合には、「通信制御システム」は、従来より、制御メッセージに含まれる電話番号などの「認証情報」に基づいて、通信を確立するか否かの認可判定を行ってきた。このように、「通信制御システム」は、制御メッセージに含まれる「認証情報」に基づいて、通信を確立するか否かの「認可判定」を行い、通信を確立すると認可された場合にのみ、通信を確立するよう制御する。
ところで、制御メッセージに含まれる「認証情報」として、従来どのようなものが扱われてきたかというと、電話番号、SIP−URI、IMSのpublic ID、private ID、回線契約を示すSubNoや、SIPプロキシが取得する属性情報などであった。このような「認証情報」は、いずれも、通信事業者や、SIPプロキシを運営する事業者等が把握している情報にすぎず、回線契約に基づく「認証情報」や、SIPプロキシが取得する「認証情報」にすぎなかった。言い換えると、従来の「通信制御システム」は、回線単位の認証に基づく制御しかできなかったということになる。この点、以下の実施例に係る「通信制御システム」は、第三者機関が任意の手法によって通信装置を認証し、当該第三者機関が当該認証の結果に基づいて発行した「認証情報」を利用することで、回線単位の認証に限られることなく柔軟に選択された手法の認証に基づいて、通信の確立を制御するものである。
なお、「通信制御システム」は、必ずしも、発信側の通信装置の認証情報に基づいて通信の確立を制御するとは限らず、着信側の通信装置の認証情報に基づいて通信の確立を制御することもある。このため、以下の実施例においては、発信側であるか着信側であるかの区別の他に、認証される側の通信装置を「第1通信装置」(特許請求の範囲に記載の「第1の通信装置」に対応する)と呼び、認証された通信装置と通信を確立する側の通信装置を「第2通信装置」(特許請求の範囲に記載の「第2の通信装置」に対応する)と呼ぶ。
[実施例1に係る通信制御システムの概要および特徴]
続いて、図1を用いて、実施例1に係る通信制御システムの概要および特徴を説明する。図1は、実施例1に係る通信制御システムの概要および特徴を説明するための図である。
実施例1に係る通信制御システムは、上記したように、第1通信装置と第2通信装置との間における通信の確立を制御することを概要とし、回線単位の認証に限られることなく認証の手法を柔軟に選択することが可能であることを主たる特徴とする。
この主たる特徴について簡単に説明すると、実施例1に係る通信制御システムの第三者機関装置(Web上のIdP)は、図1に示すように、第1通信装置とHTTP(HyperText Transfer Protocol)通信にて通信可能に接続され、認証情報記憶部に、『Alice@idp.example.com』に関する認証情報を記憶している。また、発信者装置を利用する利用者は、図1に示すように、『Alice@idp.example.com』のIDを有する者である。
このような構成の下、まず、発信者装置が、着信者装置との間でSIP通信を確立する前に、当該発信者装置を認証することを要求する認証要求を、第三者機関装置にHTTP通信にて送信する(図1の(1)を参照)。例えば、発信者装置を利用する利用者が、認証要求を、認証情報(ID『Alice@idp.example.com』およびパスワード)とともに入力することで、発信者装置は、これらの情報を第三者機関装置に送信する。
一方、第三者機関装置は、認証要求を発信者装置からHTTP通信にて受信すると、当該発信者装置を認証する(図1の(2)を参照)。例えば、第三者機関装置は、発信者装置から送信された認証情報(ID『Alice@idp.example.com』およびパスワードなどの秘密情報)から、認証情報記憶部に記憶されているID『Alice@idp.example.com』に関する認証情報(パスワードなどの秘密情報、ないし秘密情報から導出される情報)を検索し、検索したこれらの情報を判定することで当該発信者装置を認証し、認証結果として証明書を発行する。ここで、証明書とは、第三者機関装置の署名が付与されたものをいう。
そして、第三者機関装置は、認証結果を発信者装置にHTTP通信にて返送する(図1の(3)を参照)。例えば、第三者機関装置は、認証結果として、証明書を返送する。
すると、発信者装置は、第三者機関装置からHTTP通信にて送信された認証結果を、着信者装置に送信する(図1の(4)を参照)。例えば、発信者装置は、第三者機関装置から送信された証明書を認証情報として制御メッセージに含め、着信者装置に送信する。
一方、着信者装置は、発信者装置から送信された認証結果を受信すると、当該認証結果に基づいて、発信者装置との間でSIP通信を確立するか否かの認可判定を行う(図1の(5)を参照)。例えば、着信者装置は、発信者装置から送信された証明書を受信すると、当該証明書を検証するとともに認可判定を行い、通信を確立することを認可する。
すると、発信者装置と着信者装置との間において、SIP通信が確立する(図1の(6)を参照)。
このように、実施例1に係る通信制御システムにおいては、柔軟に選択された手法による認証が第1通信装置と第三者機関装置との間でHTTP通信にて行われ、当該認証に基づく認証結果が、認証情報として第2通信装置に送信され、第2通信装置は、当該認証結果に基づいてSIP通信を確立するか否かの認可判定を行うので、回線単位の認証に限られることなく認証の手法を柔軟に選択することが可能になる。
なお、実施例1においては、第三者機関装置が認証記憶部に予め認証情報(IDおよびパスワード)を記憶している手法を説明するが、本発明はこれに限られるものではない。例えば、チャレンジ&レスポンス、ワンタイムパスワードや利用者証明書、またはこれらの組み合わせなどの既存のWeb認証や、その他の認証など、第1通信装置と第三者機関装置との間で行われる認証の手法はいずれでもよい。言い換えると、認証の手法がいずれでもよいという点が、認証の手法を柔軟に選択することが可能であるという点につながるといえる。
[実施例1に係る通信制御システムの構成]
次に、図2〜図5を用いて、実施例1に係る通信制御システムを説明する。実施例1に係る通信制御システムは、第三者機関装置100と、第1通信装置200と、第2通信装置300と、SIP通信の構成要素であるSIPプロキシ(0〜n個)とから構成される。ここで、第三者機関装置100を運営する事業者と、SIPプロキシを運営する事業者とは、異なる事業者であることを想定している。また、SIPプロキシを運営する事業者は、一般的なIP電話やVoIPなどにおいては通信事業者であることが想定されるが、インターネット上のSIPプロキシなど、非通信事業者が運営していてもよい。
以下では、特に本発明に密接に関連するものとして、第三者機関装置100、第1通信装置200、第2通信装置300とを順に説明する。図2は、実施例1に係る通信制御システムの構成を示すブロック図であり、図3は、認証結果(Assertion)を説明するための図であり、図4は、第三者機関装置の署名を説明するための図であり、図5は、証明書検証部を説明するための図である。
[第三者機関装置100]
実施例1における第三者機関装置100は、以下に説明する各部が汎用的なサーバなどに備えられることによって実現され、特に本発明に密接に関連するものとしては、図2に示すように、通信部110と、記憶部120と、制御部130とを備える。また、第三者機関装置100は、第1通信装置200とHTTP通信にて通信可能に接続される。
通信部110は、HTTP通信用の一般的なインタフェースやライブラリを備え、第1通信装置200との間における情報の送受信を制御する。具体的には、通信部110は、第1通信装置200から認証要求を受信するHTTP通信や、第1通信装置200に認証結果を送信するHTTP通信における情報の送受信を制御する。なお、通信プロトコルとして、HTTP以外のその他のプロトコルを利用する場合にも、本発明を同様に適用することができる。
記憶部120は、制御部130における各種制御に用いられる情報を記憶し、特に本発明に密接に関連するものとしては、図2に示すように、認証情報記憶部121を備える。
認証情報記憶部121は、第1通信装置200の認証情報を予め記憶する。例えば、認証情報記憶部121は、第1通信装置200を利用する利用者のIDおよびパスワードの組み合わせを認証情報として予め記憶する。また、認証情報記憶部121が記憶する認証情報は、後述する認証部131による処理に利用されるなどする。
なお、本発明に係る通信制御システムが、IDおよびパスワードの手法による認証ではなく、チャレンジ&レスポンス、ワンタイムパスワードや利用者証明書、またはこれらの組み合わせなどの既存のWeb認証や、その他の手法の認証による場合には、認証情報記憶部121は、認証の手法に併せ、適切な認証情報を記憶することになる。
制御部130は、第三者機関装置100における各種制御を行い、特に本発明に密接に関連するものとしては、図2に示すように、認証部131と、証明書発行部132と、証明書返送部133とを備える。なお、認証部131は、特許請求の範囲に記載の「認証手段」に対応し、証明書発行部132および証明書返送部133は、特許請求の範囲に記載の「認証結果送信手段」に対応する。
認証部131は、第1通信装置200を認証する。具体的には、認証部131は、第1通信装置200から認証要求を受信すると、当該第1通信装置200を認証し、認証結果を証明書発行部132に伝達する。
例えば、認証部131は、第1通信装置200から、認証要求を、認証情報(ID『Alice@idp.example.com』およびパスワード)とともに受信すると、受信した認証情報から認証情報記憶部121に記憶されているID『Alice@idp.example.com』に関する認証情報としてパスワードを検索し、検索したパスワードと送信されたパスワードとが一致するか否かを判定することで、第1通信装置200を認証する。そして、認証部131は、パスワードが一致すると判定した場合に、認証に成功したとの認証結果を、証明書発行部132に伝達する。
証明書発行部132は、第1通信装置200の認証結果を証明書形式で発行する。具体的には、証明書発行部132は、認証部131から、第1通信装置200の認証に成功したとの認証結果を伝達されると、認証成功の認証結果を証明書形式で発行し、証明書返送部133に伝達する。なお、認証結果に署名を付与することを、証明書形式で発行するという。
例えば、証明書発行部132は、図3および図4に示すような証明書(SAML方式で発行された証明書を例示)を発行する。まず、図3の(A)に示すように、証明書発行部132が発行する証明書には、第三者機関装置100が管理するID『Alice@idp.example.com』が設定されており、電話番号やSIP−URIなどの回線単位の情報でない点に注意されたい。
また、盗難やリプレイなどの対策として、『condition』や『attribute value』を用いて、受取者や送信者を制限している点にも注意されたい。具体的には、図3の(B)に示すように、証明書発行部132が発行する証明書には、証明書の受け取り者『0422591111@sip.example2.com』が設定されている。これは、SIPメッセージの『To』ヘッダの値を想定するものである。また、図3の(C)に示すように、証明書発行部132が発行する証明書には、証明書の送信者『0422592222』が設定されている。これは、SIPメッセージの『From』ヘッダの値を想定するものであり、ここでは、電話番号などの回線単位の情報が設定されていてもよいことになる。
また、図4に示すように、証明書発行部132は、認証結果に署名を付与することで証明書を発行する。例えば、証明書発行部132は、認証結果のハッシュ値を算出し、算出したハッシュ値を第三者機関装置100の秘密鍵で暗号化することで、第三者機関装置100の署名(図4の『署名データ』を参照)を作成し、認証結果に作成した署名を付与する。なお、図4に示す例では、証明書発行部132は、第三者機関装置100の公開鍵(図4の『公開鍵情報』を参照)をも添付している。これは、この証明書を受け取った者が、添付された公開鍵を用いて証明書を検証することができるように添付しているものであるが、このように添付するかどうかはいずれでもよい。以下の実施例1においては、証明書を受け取った第2通信装置300は、添付された公開鍵を用いることなく、公開鍵を第三者機関装置100に要求している。
なお、証明書発行部132は、証明書に、上記したIDの他、認証した利用者の職位情報、利用できるサービスの権限情報、課金情報等を含めることもできる。
証明書返送部133は、証明書を第1通信装置200に返送する。具体的には、証明書返送部133は、証明書発行部132によって発行された証明書をHTTP通信にて第1通信装置200に返送する。
[第1通信装置200]
実施例1における第1通信装置200は、以下に説明する各部が汎用的なIP電話端末(例えば、電話機、情報家電、ファクシミリなど)や、汎用的なパーソナルコンピュータ、汎用的なゲートウェイ装置、もしくはこれらの組み合わせなどに備えられることによって実現され、特に本発明に密接に関連するものとしては、図2に示すように、通信部210と、制御部230とを備える。また、第1通信装置200は、第三者機関装置100との間でHTTP通信を行うとともに、第2通信装置300との間でSIP通信を行う。
通信部210は、HTTP通信用およびSIP通信用の一般的なインタフェースやライブラリを備え、第三者機関装置100との間における情報の送受信や、第2通信装置300との間における情報の送受信を制御する。具体的には、通信部210は、第三者機関装置100に認証要求を送信するHTTP通信や、第三者機関装置100から認証結果を受信するHTTP通信における情報の送受信を制御する。また、通信部210は、第2通信装置300に証明書を送信するSIP通信や、その他のSIP通信における情報の送受信を制御する。また、通信部210は、S/MIME(Secure Multipurpose Internet Mail Extensions)などの技術を利用して、証明書を付与したSIPメッセージ本文を暗号化することにより、例えば、盗聴や盗難、リプレイなどの攻撃を防止することが可能である。なお、通信プロトコルとして、HTTPやSIP以外のその他のプロトコルを利用する場合にも、本発明を同様に適用することができる。
制御部230は、第1通信装置200における各種制御を行い、特に本発明に密接に関連するものとしては、図2に示すように、認証要求部231と、証明書送信部232とを備える。なお、認証要求部231は、特許請求の範囲に記載の「認証要求送信手段」に対応し、証明書送信部232は、特許請求の範囲に記載の「認証結果送信手段」に対応する。
認証要求部231は、認証要求を送信する。具体的には、認証要求部231は、第1通信装置200を認証することを要求する認証要求をHTTP通信にて第三者機関装置100に送信する。例えば、認証要求部231は、認証要求を、認証情報(ID『Alice@idp.example.com』およびパスワード)とともに送信する。
証明書送信部232は、証明書を第2通信装置300に送信する。具体的には、証明書送信部232は、第三者機関装置100から認証結果として証明書を受信すると、証明書を認証情報としてSIP通信の制御メッセージに含め、第2通信装置300に送信する。
ここで、証明書送信部232による送信手法について検討すると、まず、認証情報である証明書を、SIPのヘッダやボディ部に含め、第2通信装置300に直接送信する手法が考えられる。また、認証情報である証明書が存在するURI等のリファレンス情報を、SIPの制御メッセージに含め、第2通信装置300に送信する手法が考えられる。この場合には、リファレンス情報を受信した第2通信装置300は、指定されたURI等にアクセスするなどして、認証情報を取得する。また、認証情報である証明書を暗号化した文字列としてSIPの制御メッセージに含め、第2通信装置300に送信する手法が考えられる。
[第2通信装置300]
実施例1における第2通信装置300は、以下に説明する各部が汎用的なIP電話端末(例えば、電話機、情報家電、ファクシミリなど)や、汎用的なパーソナルコンピュータ、汎用的なゲートウェイ装置、もしくはこれらの組み合わせなどに備えられることによって実現され、特に本発明に密接に関連するものとしては、図2に示すように、通信部310と、制御部330とを備える。また、第2通信装置300は、第1通信装置200との間でSIP通信を行う。
通信部310は、HTTP通信用およびSIP通信用の一般的なインタフェースやライブラリを備え、第三者機関装置100との間における情報の送受信や、第1通信装置200との間における情報の送受信を制御する。具体的には、通信部310は、第三者機関装置100に公開鍵要求を送信するHTTP通信や、第三者機関装置100から公開鍵を受信するHTTP通信における情報の送受信を制御する。また、通信部310は、第1通信装置200から証明書を受信するSIP通信や、その他のSIP通信における情報の送受信を制御する。なお、通信プロトコルとして、HTTPやSIP以外のその他のプロトコルを利用する場合にも、本発明を同様に適用することができる。
制御部330は、第2通信装置300における各種制御を行い、特に本発明に密接に関連するものとしては、図2に示すように、証明書受信部331と、証明書検証部332と、認可判定部333とを備える。なお、証明書検証部332は、特許請求の範囲に記載の「認証結果検証手段」に対応し、認可判定部333は、特許請求の範囲に記載の「認可判定手段」に対応する。
証明書受信部331は、証明書を受信する。具体的には、証明書受信部331は、第1通信装置200から証明書を受信し、受信した証明書を、証明書検証部332および認可判定部333に各々伝達する。
証明書検証部332は、証明書を検証する。具体的には、証明書検証部332は、証明書受信部331から伝達された証明書を検証し、検証結果を認可判定部333に伝達する。
例えば、証明書検証部332は、図5に示すように、証明書の検証を行う。すなわち、実施例1における証明書は、認証結果に、第三者機関装置100の署名が付与されている。ここで、第三者機関装置100の署名とは、認証結果から算出されたハッシュ値を、第三者機関装置100の秘密鍵で暗号化したものである。したがって、図5に示すように、証明書検証部332は、第三者機関装置100の公開鍵で、認証結果から算出されたハッシュ値を取り出す。なお、証明書検証部332は、証明書に添付されている第三者機関装置100の公開鍵を用いてもよいし、第三者機関装置100に公開鍵を要求し、返送された公開鍵を用いてもよい。
一方、証明書検証部332は、図5に示すように、認証結果からハッシュ値を算出する。こうして、証明書検証部332は、署名から取り出したハッシュ値と、算出されたハッシュ値とを比較し、同じハッシュ値であるか否かを検証する。2つのハッシュ値が同じ値である場合には、証明書検証部332は、認証結果に関する事実として、確かに第三者機関装置100から発行された認証結果であること、また、認証結果に改竄が行われていないことを検証することができる。なお、第三者機関装置100(ひいては第1通信装置200)が、認証結果を送信した事実を否認しないことなども検証することができる。なお、例えば、第三者機関装置100から発行された証明書が、X.509方式などその他の方式であれば、その方式に適合した手法で検証すればよい。
認可判定部333は、認可判定を行う。具体的には、認可判定部333は、証明書受信部331から伝達された証明書、および、証明書検証部332から伝達された証明書の検証結果に基づいて、第1通信装置200との間でSIP通信を確立するか否かの認可判定を行い、判定結果を、通信部310に伝達する。
例えば、認可判定部333は、証明書検証部332から伝達された検証結果によって、証明書の正当性を把握した上で(正しい証明書だと確認した上で)、証明書受信部331から伝達された証明書の記載内容に基づいて、第1通信装置200との間でSIP通信を確立するか否かの認可判定を行う。
ここで、認可判定部333が行う認可判定の手法について、具体的に例を挙げて説明すると、認可判定部333は、例えば、証明書内に記載されたID情報によって第1通信装置200がアクセス許可リストに含まれていることの確認をしたり、証明書内に記載された情報によって第1通信装置200がアクセスに必要な権限を持っていることの確認をしたり、証明書内に記載された情報によって第1通信装置200に対して所定の金額の課金が行われたことの確認をすることなどで、認可判定を行う。
[実施例1に係る通信制御システムによる処理の手順]
次に、図6および図7を用いて、実施例1に係る通信制御システムによる処理の手順を説明する。図6は、実施例1に係る通信制御システムによる処理の手順(認可OK)を示すシーケンス図であり、図7は、実施例1に係る通信制御システムによる処理の手順(認可NG)を示すシーケンス図である。なお、図6および図7に示す「SIPプロキシ」は、SIP通信の構成要素であり、第1通信装置200と第2通信装置300との間のSIP通信を中継する役割などを果たしている。また、図6および図7に示す点線は、HTTP通信で行われることを意味し、実線は、SIP通信で行われることを意味する。
[通信確立を認可するケース]
まず、発信者装置(第1通信装置)200の認証要求部231は、当該発信者装置200を認証することを要求する認証要求を、第三者機関装置100にHTTP通信にて送信する(ステップS101)。例えば、発信者装置200を利用する利用者が、認証要求を、認証情報(ID『Alice@idp.example.com』およびパスワード)とともに入力することで、認証要求部231は、これらの情報を第三者機関装置100に送信する。
一方、第三者機関装置100の認証部131は、認証要求を発信者装置200からHTTP通信にて受信すると、当該発信者装置200を認証する。そして、証明書発行部132は、認証部131によって認証された認証結果を証明書形式で発行し、証明書返送部133は、証明書発行部132によって発行された証明書を発信者装置200に返送する(ステップS102)。
例えば、認証部131は、発信者装置200から送信された認証情報(ID『Alice@idp.example.com』およびパスワード)から、認証情報記憶部121に記憶されているID『Alice@idp.example.com』に関する認証情報としてパスワードを検索し、検索したパスワードと送信されたパスワードとが一致するか否かを判定することで、当該発信者装置200を認証する。また、証明書発行部132が、認証結果を証明書形式で発行するが、この時、証明書発行部132は、認証結果に第三者機関装置100の署名を付与することで、認証結果を証明書形式で発行する。
次に、発信者装置200の証明書送信部232は、第三者機関装置100からHTTP通信にて返送された証明書をSIP信号(『INVITE』メッセージ)に含め、着信者装置300に送信する(ステップS103−1およびS103−2)。なお、この時、SIPプロキシ400は、通常のSIPサービスと同様、Digest認証などにより、発信者装置200を認証してもよい。
一方、着信者装置300の証明書受信部331が証明書を受信すると、証明書検証部332は、第三者機関装置100に対して、第三者機関装置100の公開鍵を要求し(ステップS104)、第三者機関装置100から公開鍵を受信する(ステップS105)。
そして、着信者装置300の証明書検証部332は、証明書を検証する(ステップS106)。例えば、証明書検証部332は、認証結果に付与された署名を第三者機関装置100の公開鍵によって復号化し、認証結果のハッシュ値を取り出すとともに、認証結果からハッシュ値を算出し、取り出したハッシュ値と算出したハッシュ値とを比較することで、認証結果に関する事実を検証する。
続いて、着信者装置300の認可判定部333は、発信者装置200との間でSIP通信を確立するか否かの認可判定を行う(ステップS107)。具体的には、認可判定部333は、ステップS103−2で受信した認証結果と、ステップS106で検証した検証結果とに基づいて、認可判定を行う。
着信者装置300は、ステップS107における認可判定によって、SIP通信を確立することを認可するとの判定を行った場合に、通信部310が、『200 OK』メッセージを発信者装置200に送信するなどして、SIP通信確立を認可することを発信者装置200に通知する(ステップS108−1およびS108−2)。
すると、発信者装置200の通信部210が、『ACK』メッセージを着信者装置300に送信するなどして(ステップS109−1およびS109−2)、その後、発信者装置200と着信者装置300との間でSIP通信が確立する(ステップS110)。例えば、着信者装置300がサービス提供装置の場合には、着信者装置300から発信者装置200に対してサービスが提供されるなどする。
なお、実施例1においては、第三者機関装置100によって返送される認証結果が証明書形式である場合を想定したので、これに伴い、着信者装置300において証明書検証を行ったが(ステップS106を参照)、本発明はこれに限られるものではない。第三者機関装置100によって返送される認証結果が検証可能な形式でない場合には、着信者装置300における証明書検証も(公開鍵要求や公開鍵返送も)不要になる。
[通信確立を認可しないケース]
また、図7に、認可NGの場合の処理の手順を示すが、ステップS201〜S207は、認可OKの場合の処理の手順(図6)と同様である。異なる点は、着信者装置300が、ステップS207における認可判定によって、通信を確立することを認可しないとの判定を行った場合に、通信部310が、『401 Unauthorized』メッセージを第1通信装置200に送信するなどして、通信確立を認可しないことを第1通信装置200に通知する点である(ステップS208−1およびS208−2)。
すると、第1通信装置200の通信部210が、『ACK』メッセージを第2通信装置300に送信するなどして(ステップS209−1およびS209−2)、SIP通信が確立しないまま、第1通信装置200と第2通信装置300との間で処理が終了する。
なお、図7においては、『401 Unauthorized』メッセージを例示したが、クライアント・エラー応答であるステータス・コード『4xx』のメッセージなど、いずれでもよい。
[実施例1の効果]
上記してきたように、実施例1によれば、第1の通信装置と第2の通信装置との間における通信の確立を制御する通信制御システムであって、第1の通信装置と第1の通信にて通信可能に接続された第三者機関装置は、第1の通信装置を認証することを要求する認証要求を当該第1の通信装置から第1の通信にて受信すると、当該第1の通信装置を認証し、第1の通信装置を認証すると、認証結果を当該第1の通信装置に第1の通信にて送信し、第三者機関装置との間で第1の通信を行うとともに第2の通信装置との間で第2の通信を行う第1の通信装置は、第2の通信装置との間で第2の通信を確立する前に、認証要求を第三者機関装置に第1の通信にて送信し、第1の通信にて送信された認証結果を受信すると、当該認証結果を第2の通信装置に第2の通信を確立する過程において送信し、第2の通信装置は、第1の通信装置によって送信された認証結果を受信すると、当該認証結果に基づいて、当該第1の通信装置との間で第2の通信を確立するか否かの認可判定を行うので、回線単位の認証に限られることなく認証の手法を柔軟に選択することが可能になる。
例えば、従来のSIPサービスでは、回線単位の認証に基づいて通信確立を制御することしかできなかったが、実施例1に係る通信制御システムによれば、個人単位や課金単位など、細かい単位の認証に基づいて通信確立を制御することが可能になる。
また、例えば、実施例1に係る通信制御システムを、SIPサービスを利用した出張先からのVPN(Virtual Private Network)アクセスなど、日常と異なる回線からのアクセスに適用する場合、第三者機関装置による認証結果として、既存のWeb認証に基づく証明書を用いることができるので、新たな認証システムを構築することなく、日常と同等のサービスを提供することが可能になる。
また、例えば、実施例1に係る通信制御システムによれば、回線接続とは独立した認証情報(認証結果)を流通させる手法であるので、回線接続とは独立した認証に基づいて通信確立を制御することが可能になる。例えば、発信側の通信装置が発番号非通知の状態(匿名の状態、『184』を付与して行われる発信など)であっても、着信側の通信装置は、発番号とは独立した認証に基づいて、安全にサービスを提供することが可能になる。
また、例えば、実施例1に係る通信制御システムによれば、SIPの呼接続に使用される信号のみを用いることで、言い換えると、SIP通信の信号を介して認証情報(認証結果)を流通させることで、SIP通信の制御(認可)が可能になる。
また、実施例1によれば、第三者機関装置は、認証結果を検証可能な形式で送信し、第2の通信装置は、第1の通信装置によって送信された認証結果が検証可能な形式である場合には、当該認証結果に関する事実を検証し、受信した認証結果の他に、検証された当該認証結果に関する事実にも基づいて、認可判定を行うので、信用性の高い認証の手法を柔軟に選択することが可能になる。
例えば、第2通信装置においては、認証結果に関する事実として、確かに第三者機関装置から発行された認証結果であることが検証され、また、認証結果に改竄が行われていないことが検証される。なお、第三者機関装置(ひいては第1通信装置)が認証情報を送信した事実を否認しないことなども検証される。
また、実施例1によれば、第1の通信がHTTPによって行われる通信であり、第2の通信がSIPによって確立される通信である場合に、第1の通信装置は、第1の通信にて取得した認証情報を、第2の通信を確立するためのプロトコルであるSIPにより伝達することで、第2の通信装置との間でSIPによる通信の確立を制御することが可能になる。すなわち、Webのシングルサインオンシステムなどのように、認証結果をアプリケーションレベルでの制御に引き継ぐのとは異なり、第2の通信自体の確立の制御を目的として引き継ぐことが可能になる。
ところで、これまで実施例1として、SIP通信における発信側である第1通信装置が、着信側である第2通信装置からの要求無しに、自ら認証結果を取得して第2通信装置に送信する手法(着信側の要求に基づかない発信側による認証結果送信)を説明してきたが、本発明はこれに限られるものではない。発信側である第1通信装置が、着信側である第2通信装置から認証結果の送信を要求された場合に、認証結果を取得して第2通信装置に送信する手法(着信側の要求に基づく発信側による認証結果送信)にも、本発明を同様に適用することができる。以下では、実施例2として、着信側の要求に基づく発信側による認証結果送信の手法を、図8を用いて説明する。図8は、実施例2に係る通信制御システムによる処理の手順を示すシーケンス図である。なお、図8に例示する処理の手順が、図6に例示する処理の手順と異なる点を中心に説明する。
上記したように、実施例2においては、発信側である第1通信装置が、着信側の要求に基づいて認証結果を送信することになる。すなわち、まず、発信者装置200は、一般的なSIP通信と同様、着信者装置300との間でSIP通信を確立することを要求するSIP信号(『INVITE』メッセージ)を、着信者装置300に送信する(ステップS301−1およびS301−2)。
一方、着信者装置300は、これに対して『403 Request Failure』メッセージで応答するが、この時、認証結果を当該着信者装置300に送信することを要求する『REQUEST』をSIP信号に含めている(ステップS302−1およびS302−2)。このSIP信号こそが、着信側の要求を意味する。
すると、発信者装置200は、着信者装置300の要求を受け、認証要求をHTTP通信にて第三者機関装置100に送信する(ステップS303)。
なお、以下の処理の手順は、図6に例示する処理の手順とほぼ同様であるが、ステップS305−1およびS305−2におけるSIP信号が、ステップS302−1およびステップS302−2におけるSIP信号に含められていた『REQUEST』に対する『RESPONSE』である点に注意されたい。
[実施例2の効果]
上記してきたように、実施例2によれば、第2の通信装置は、認証結果を当該第2の通信装置に送信することを第1の通信装置に対して要求し、認証結果を第2の通信装置に送信することを要求された場合に、認証要求を第三者機関装置に送信するので、認証情報(認証結果)が不要な通信相手に対して認証情報(認証結果)を送信してしまうことを防ぐことが可能になる。
また、実施例2によれば、第1の通信装置は、第2の通信装置に送信すべき認証情報を事前に知ることができ、要求された記載内容の認証情報を第2の通信装置に送信することも可能になる。例えば、第2の通信装置が、『300円を支払った通信装置には通信の確立を認可する』といった趣旨の要求を第1の通信装置に送信すると、第1の通信装置は、認証情報(認証結果)として『300円の課金結果』のAssertionを送信することが可能になる。
ところで、これまで実施例1および実施例2として、SIP通信における発信側である第1通信装置が、着信側である第2通信装置に認証結果を送信する手法(発信側による認証結果送信)を説明してきたが、本発明はこれに限られるものではなく、着信側である第1通信装置が、発信側である第2通信装置に認証結果を送信する手法(着信側による認証結果送信)にも、本発明を同様に適用することができる。以下では、実施例3として、着信側による認証結果送信の手法を、図9および図10を用いて説明する。図9は、実施例3に係る通信制御システムによる処理の手順(発信側の要求なし)を示すシーケンス図であり、図10は、実施例3に係る通信制御システムによる処理の手順(発信側の要求あり)を示すシーケンス図である。
まず、発信者装置(第2通信装置)300の通信部310は、着信者装置(第1通信装置)200との間でSIP通信を確立することを要求するSIP信号(『INVITE』メッセージ)を、着信者装置200に送信する(ステップS401−1およびS401−2)。
すると、着信者装置200の認証要求部231は、当該着信者装置200を認証することを要求する認証要求を、第三者機関装置100にHTTP通信にて送信する(ステップS402)。
一方、第三者機関装置100の認証部131は、認証要求を着信者装置200から受信すると、当該着信者装置200を認証する。そして、証明書発行部132は、認証部131によって認証された認証結果を証明書形式で発行し、証明書返送部133は、証明書発行部132によって発行された証明書をHTTP通信にて着信者装置200に返送する(ステップS403)。
次に、着信者装置200の証明書送信部232は、第三者機関装置100から返送された証明書をSIP信号(『200 OK』メッセージ)に含め、発信者装置300に送信する(ステップS404−1およびS404−2)。
一方、発信者装置300の証明書受信部331が証明書を受信すると、証明書検証部332は、第三者機関装置100に対して、第三者機関装置100の公開鍵を要求し(ステップS405)、第三者機関装置100から公開鍵を受信する(ステップS406)。
そして、発信者装置300の証明書検証部332は、証明書を検証する(ステップS407)。
続いて、発信者装置300の認可判定部333は、着信者装置200との間でSIP通信を確立するか否かの認可判定を行う(ステップS408)。
発信者装置300は、ステップS408における認可判定によって、SIP通信を確立することを認可するとの判定を行った場合に、通信部310が、『ACK』メッセージを着信者装置200に送信するなどして、SIP通信確立を認可することを着信者装置200に通知する(ステップS409−1およびS409−2)。
すると、その後、発信者装置300と着信者装置200との間でSIP通信が確立する(ステップS410)。
次に、図10に例示する処理の手順は、着信側である第1通信装置が、発信側の要求に基づいて認証結果を送信するものであるので、図9に例示する処理の手順と異なる点を中心に説明する。
すなわち、まず、発信者装置300は、着信者装置200との間でSIP通信を確立することを要求するSIP信号(『INVITE』メッセージ)を、着信者装置200に送信するが、この時、認証結果を当該発信者装置300に送信することを要求する『REQUEST』をSIP信号に含めている(ステップS501−1およびS501−2)。このSIP信号こそが、発信側の要求を意味する。
すると、着信者装置200は、発信者装置300の要求を受け、認証要求を第三者機関装置100にHTTP通信にて送信する(ステップS502)。
なお、以下の処理の手順は、図9に例示する処理の手順とほぼ同様であるが、ステップS504−1およびS504−2におけるSIP信号が、ステップS501−1およびS502−2におけるSIP信号に含められていた『REQUEST』に対する『RESPONSE』である点に注意されたい。
ところで、これまで実施例1〜実施例3として、SIP通信における発信側である第1通信装置、もしくは、着信側である第1通信装置が、認証結果を送信する手法を説明してきたが、本発明はこれに限られるものではなく、互いに認証結果を送信し合う手法(双方向の認証結果送信)にも、本発明を同様に適用することができる。以下では、実施例4として、双方向の認証結果送信の手法を、図11を用いて説明する。図11は、実施例4に係る通信制御システムによる処理の手順を示すシーケンス図である。
すなわち、まず、発信者装置は、着信者装置との間で通信を確立することを要求するSIP信号(『INVITE』メッセージ)を、着信者装置に送信するが、この時、認証結果を当該発信者装置に送信することを要求する『REQEST A』をSIP信号に含めている(ステップS601−1およびS601−2)。
すると、着信者装置は、発信者装置の要求を受け、認証要求を第三者機関装置にHTTP通信にて送信する(ステップS602)。
一方、第三者機関装置は、認証要求を着信者装置からHTTP通信にて受信すると、当該着信者装置を認証し、認証結果を証明書形式で発行し、着信者装置にHTTP通信にて返送する(ステップS603)。
すると、着信者装置は、ステップS601−1およびS601−2における『INVITE』メッセージに対して『403 OK』メッセージで応答するが、この時、認証結果『RESPONSE A』をSIP信号に含めるとともに、認証結果を当該着信者装置に送信することを要求する『REQUEST B』をSIP信号に含めている(ステップS604−1およびS604−2)。
一方、発信者装置が証明書を受信すると、第三者機関装置に対して、第三者機関装置の公開鍵を要求し(ステップS605)、第三者機関装置から公開鍵を受信する(ステップS606)。
そして、発信者装置は、証明書を検証し(ステップS607)、着信者装置との間でSIP通信を確立するか否かの認可判定を行う(ステップS608)。
続いて、発信者装置は、ステップS604−1およびS604−2における着信者装置の要求を受け、認証要求を第三者機関装置にHTTP通信にて送信する(ステップS609)。
一方、第三者機関装置は、認証要求を発信者装置からHTTP通信にて受信すると、当該発信者装置を認証し、認証結果を証明書形式で発行し、発信者装置にHTTP通信にて返送する(ステップS610)。
すると、発信者装置は、ステップS608における認可判定によって、SIP通信を確立することを認可するとの判定を行った場合に、『INVITE』メッセージを着信者装置に送信するなどして、SIP通信確立を認可することを着信者装置に通知するが、この時、認証結果『RESPONSE B』をSIP信号に含める(ステップS611−1およびS611−2)。
一方、着信者装置が証明書をHTTP通信にて受信すると、第三者機関装置に対して、第三者機関装置の公開鍵を要求し(ステップS612)、第三者機関装置から公開鍵を受信する(ステップS613)。
そして、着信者装置は、証明書を検証し(ステップS614)、発信者装置との間でSIP通信を確立するか否かの認可判定を行う(ステップS615)。
着信者装置は、ステップS615における認可判定によって、SIP通信を確立することを認可するとの判定を行った場合に、『200 OK』メッセージを発信者装置に送信するなどして、SIP通信確立を認可することを発信者装置に通知し(ステップS616−1およびS616−2)、発信者装置が、『ACK』メッセージを着信者装置に送信するなどして(ステップS617−1およびS617−2)、その後、発信者装置と着信者装置との間でSIP通信が確立する(ステップS618)。
次に、実施例5として、本発明に係る通信制御システムの運用形態の一例を説明する。図12は、出張先からのリモートアクセスを説明するための図であり、図13は、ホテルから自宅へのリモートアクセスを説明するための図である。
[出張先からのリモートアクセス]
例えば、図12に示すように、出張先からオフィスにリモートアクセスする運用形態を考える。出張先の端末(第1通信装置に相当)は、まず、HTTPS(Hypertext Transfer Protocol Security)通信によって、IPネットワークを経由してWebポータル(第三者機関装置に相当)へアクセスする(図12の(1)を参照)。
すると、出張先の端末のディスプレイに、図12に示すようなログイン画面(『社内システムログイン』)が表示されるので、出張先の端末の利用者は、当該端末を認証することを要求する認証要求として、認証情報(ID『denden』およびパスワード)を入力し、『送信』アイコンをクリックする。
こうして、出張先の端末は、認証要求をWebポータルに送信するので、Webポータルは、認証要求を受信し、出張先の端末を認証する。例えば、ID『denden』に対応するパスワードが入力されたか否かなどによって、認証する。
Webポータルによる認証の結果、認証に成功すると、Webポータルは、出張先の端末に対して、認証に成功したことを示す認証結果として、図12に示すようなサービス提供画面(『リモートアクセスサービス』)送信し、出張先の端末のディスプレイに表示される。
出張先の端末の利用者が、『武蔵野へ接続』をクリックすると、当該端末は、SIP通信によって、VPNトンネルを経由してオフィスにアクセスする(図12の(2)を参照)。このVPNアクセスには、Webポータルによる認証結果(Assertion)が含まれており、オフィスのゲートウェイ(第2通信装置に相当)は、出張先の端末から送信された認証結果に基づいて、当該端末からのアクセスを認可するか否かの認可判定を行う。なお、出張先の端末には、図12に示すような画面『武蔵野(0422−59−XXXX)へ接続』が表示される。
ゲートウェイによってアクセスが認可されると、出張先の端末は、オフィスにリモートアクセスすることができるようになる。このように、既存のWebポータルをそのまま利用して、出張先からのリモートアクセスを実現することが可能である。
[ホテルから自宅へのリモートアクセス]
また、例えば、図13に示すように、ホテルから自宅にリモートアクセスする運用形態を考える。ホテルの端末(第1通信装置に相当)は、まず、HTTPS通信によって、IPネットワークを経由してABCポータル(第三者機関装置に相当)へアクセスする(図13の(1)を参照)。
すると、ホテルの端末のディスプレイに、図13に示すようなログイン画面(『ABCポータルログイン』)が表示されるので、ホテルの端末の利用者は、当該端末を認証することを要求する認証要求として、認証情報(ID『denden』およびパスワード)を入力し、『送信』アイコンをクリックする。
こうして、ホテルの端末は、認証要求をABCポータルに送信するので、ABCポータルは、認証要求を受信し、ホテルの端末を認証する。例えば、ID『denden』に対応するパスワードが入力されたか否かなどによって、認証する。
ABCポータルによる認証の結果、認証に成功すると、ABCポータルは、ホテルの端末に対して、認証に成功したことを示す認証結果として、図13に示すようなサービス提供画面(『ABCポータルサービス』)送信し、ホテルの端末のディスプレイに表示される。
ホテルの端末の利用者が、『自宅へ接続』をクリックすると、当該端末は、SIP通信によって、VPNトンネルを経由して自宅にアクセスする(図13の(2)を参照)。このVPNアクセスには、ABCポータルによる認証結果(Assertion)が含まれており、自宅のゲートウェイ(第三者機関装置に相当)は、ホテルの端末から送信された認証結果に基づいて、当該端末からのアクセスを認可するか否かの認可判定を行う。なお、ホテルの端末には、図13に示すような画面『自宅(0422−59−YYYY)へ接続』が表示される。
ゲートウェイによってアクセスが認可されると、ホテルの端末は、自宅にリモートアクセスすることができるようになる。例えば、DLNA(Digital Living Network Alliance)を利用して、自宅のHDDレコードの映像を確認することができるようになる(図13の(3)を参照)。
[他の実施例]
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。
上記の実施例においては、認証結果が検証可能な形式(第三者機関装置の署名が付与された証明書形式)で流通する手法について説明したが、本発明はこれに限られるものではない。第三者機関装置の署名が付与されていないなど、検証不可能な形式であってもよい。このような場合には、第2通信装置は、認証結果の内容にのみ基づいて認可判定を行うことになる。
また、検証可能な形式を実現する手法についても、証明書形式以外の手法であってもよい。例えば、第三者機関装置と第2通信装置との間で予め共通鍵を共有していたとする。このような構成の下、第三者機関装置が当該共通鍵で暗号化した認証結果を第1通信装置に送信し、第2通信装置は、第1通信装置から送信された認証結果(共通鍵で暗号化済み)を受信すると、自ら保有する共通鍵で認証結果を復号化する、といった手法である。
また、上記の実施例においては、第1通信装置が一つの第三者機関装置から認証結果を受信して、第2通信装置に送信する事例を説明したが、本発明はこれに限られるものではない。第1通信装置が複数の第三者機関装置から認証結果を受信し、複数の第三者機関装置から受信した認証結果を第2通信装置に送信する事例にも、本発明を同様に適用することができる。
すなわち、第1の通信装置は、第1の通信装置は、複数の第三者機関装置と第1の通信にて通信可能に接続されるものであって、認証要求を、複数の第三者機関装置から選択した一つまたは複数の第三者機関装置に送信するので、インターネットなどのIPネットワーク上に存在する1つ以上の証明機関が発行する認証情報(認証結果)を流通させることができ、多様な認証の手法を柔軟に選択することが可能になる。
また、上記の実施例においては、第2通信装置が第1通信装置に認証結果を送信することを要求する際、特に第三者機関装置を指定しないで要求する手法を説明したが、本発明はこれに限られるものではなく、第2通信装置が第三者機関装置を指定して要求してもよい。
すなわち、第2の通信装置は、認証結果を所定の第三者機関装置から取得して第2の通信装置に送信することを要求し、第1の通信装置は、認証結果を所定の第三者機関装置から取得して第2の通信装置に送信することを要求された場合に、認証要求を所定の第三者機関装置に送信するので、通信相手から指定された認証情報(認証結果)を送信することから、通信相手にとって適切な認証の手法を柔軟に選択することが可能になる。
[システム構成等]
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示(例えば、図2など)の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
なお、本実施例で説明した通信制御方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク(FD)、CD−ROM、MO、DVDなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。
以上のように、本発明に係る通信制御システム、通信制御方法、通信制御プログラムは、第1の通信装置と第2の通信装置との間における通信の確立を制御することに有用であり、特に、回線単位の認証に限られることなく認証の手法を柔軟に選択することが可能になる。
実施例1に係る通信制御システムの概要および特徴を説明するための図である。 実施例1に係る通信制御システムの構成を示すブロック図である。 認証結果(Assertion)を説明するための図である。 第三者機関装置の署名を説明するための図である。 証明書検証部を説明するための図である。 実施例1に係る通信制御システムによる処理の手順(通信確立を認可するケース)を示すシーケンス図である。 実施例1に係る通信制御システムによる処理の手順(通信確立を認可しないケース)を示すシーケンス図である。 実施例2に係る通信制御システムによる処理の手順を示すシーケンス図である。 実施例3に係る通信制御システムによる処理の手順(発信側の要求なし)を示すシーケンス図である。 実施例3に係る通信制御システムによる処理の手順(発信側の要求あり)を示すシーケンス図である。 実施例4に係る通信制御システムによる処理の手順を示すシーケンス図である。 出張先からのリモートアクセスを説明するための図である。 ホテルから自宅へのリモートアクセスを説明するための図である。 従来技術を説明するための図である。
符号の説明
1 ネットワーク
100 第三者機関装置
110 通信部
120 記憶部
121 認証情報記憶部
130 制御部
131 認証部
132 証明書発行部
133 証明書返送部
200 第1通信装置
210 通信部
230 制御部
231 認証要求部
232 証明書送信部
300 第2通信装置
310 通信部
330 制御部
331 証明書受信部
332 証明書検証部
333 認可判定部

Claims (12)

  1. 第1の通信装置と第2の通信装置との間における通信の確立を制御する通信制御システムであって、
    前記第1の通信装置と第1の通信にて通信可能に接続された第三者機関装置は、
    前記第1の通信装置を認証することを要求する認証要求を当該第1の通信装置から前記第1の通信にて受信すると、当該第1の通信装置を認証する認証手段と、
    前記認証手段によって前記第1の通信装置が認証されると、認証結果を当該第1の通信装置に前記第1の通信にて送信する認証結果送信手段とを備え、
    前記第三者機関装置との間で前記第1の通信を行うとともに前記第2の通信装置との間で第2の通信を行う前記第1の通信装置は、
    前記第2の通信装置との間で前記第2の通信を確立する前に、前記認証要求を前記第三者機関装置に前記第1の通信にて送信する認証要求送信手段と、
    前記認証結果送信手段によって前記第1の通信にて送信された認証結果を受信すると、当該認証結果を前記第2の通信装置に前記第2の通信を確立する過程において送信する認証結果送信手段とを備え、
    前記第2の通信装置は、
    前記第1の通信装置の認証結果送信手段によって送信された認証結果を受信すると、当該認証結果に基づいて、当該第1の通信装置との間で前記第2の通信を確立するか否かの認可判定を行う認可判定手段を備えたことを特徴とする通信制御システム。
  2. 前記第2の通信は、SIPによって確立される通信であることを特徴とする通信制御システム。
  3. 前記第三者機関装置の認証結果送信手段は、前記認証結果を検証可能な形式で送信し、
    前記第2の通信装置は、
    前記第1の通信装置の認証結果送信手段によって送信された認証結果が検証可能な形式である場合には、当該認証結果に関する事実を検証する認証結果検証手段をさらに備え、
    前記認可判定手段は、受信した認証結果の他に、前記認証結果検証手段によって検証された当該認証結果に関する事実にも基づいて、前記認可判定を行うことを特徴とする請求項1または2に記載の通信制御システム。
  4. 前記第1の通信装置は、複数の第三者機関装置と第1の通信にて通信可能に接続されるものであって、
    前記認証要求送信手段は、前記認証要求を、前記複数の第三者機関装置から選択した一つまたは複数の第三者機関装置に送信することを特徴とする請求項1〜3のいずれか一つに記載の通信制御システム。
  5. 前記第2の通信装置は、
    前記認証結果を当該第2の通信装置に送信することを前記第1の通信装置に対して要求する認証結果要求手段をさらに備え、
    前記第1の通信装置の認証要求送信手段は、前記認証結果要求手段によって前記認証結果を前記第2の通信装置に送信することを要求された場合に、前記認証要求を前記第三者機関装置に送信することを特徴とする請求項1〜4のいずれか一つに記載の通信制御システム。
  6. 前記第2の通信装置の認証結果要求手段は、前記認証結果を所定の第三者機関装置から取得して前記第2の通信装置に送信することを要求し、
    前記第1の通信装置の認証要求送信手段は、前記認証結果要求手段によって前記認証結果を前記所定の第三者機関装置から取得して前記第2の通信装置に送信することを要求された場合に、前記認証要求を当該所定の第三者機関装置に送信することを特徴とする請求項1〜5のいずれか一つに記載の通信制御システム。
  7. 第1の通信装置と第2の通信装置との間における通信の確立を制御する通信制御システムの当該第1の通信装置であって、
    第三者機関装置との間で第1の通信を行うとともに前記第2の通信装置との間で第2の通信を行う前記第1の通信装置は、
    前記第2の通信装置との間で前記第2の通信を確立する前に、当該第1の通信装置を認証することを要求する認証要求を、当該第1の通信装置を認証する第三者機関装置に前記第1の通信にて送信する認証要求送信手段と、
    前記第三者機関装置によって認証された認証結果を当該第三者機関装置から前記第1の通信にて受信すると、前記第2の通信装置において当該認証結果に基づいて当該第1の通信装置との間で前記第2の通信を確立するか否かの認可判定が行われるように、当該認証結果を当該第2の通信装置に当該第2の通信を確立する過程において送信する認証結果送信手段と、
    を備えたことを特徴とする第1の通信装置。
  8. 第1の通信装置と第2の通信装置との間における通信の確立を制御する通信制御システムの当該第2の通信装置であって、
    前記第1の通信装置との間で第2の通信を行う前記第2の通信装置は、
    前記第1の通信装置を認証する第三者機関装置から当該第1の通信装置が第1の通信にて受信した認証結果を、当該第1の通信装置との間で前記第2の通信を確立する前に当該第1の通信装置から受信すると、当該認証結果に基づいて、当該第1の通信装置との間で当該第2の通信を確立するか否かの認可判定を行う認可判定手段を備えたことを特徴とする第2の通信装置。
  9. 第1の通信装置と第2の通信装置との間における通信の確立を制御する通信制御方法であって、
    第三者機関装置との間で第1の通信を行うとともに前記第2の通信装置との間で第2の通信を行う前記第1の通信装置は、
    前記第2の通信装置との間で前記第2の通信を確立する前に、当該第1の通信装置を認証することを要求する認証要求を、当該第1の通信装置を認証する第三者機関装置に前記第1の通信にて送信する認証要求送信工程と、
    前記第三者機関装置によって認証された認証結果を当該第三者機関装置から前記第1の通信にて受信すると、前記第2の通信装置において当該認証結果に基づいて当該第1の通信装置との間で前記第2の通信を確立するか否かの認可判定が行われるように、当該認証結果を当該第2の通信装置に当該第2の通信を確立する過程において送信する認証結果送信工程と、
    を含むことを特徴とする通信制御方法。
  10. 第1の通信装置と第2の通信装置との間における通信の確立を制御する通信制御方法であって、
    前記第1の通信装置との間で第2の通信を行う前記第2の通信装置は、
    前記第1の通信装置を認証する第三者機関装置から当該第1の通信装置が第1の通信にて受信した認証結果を、当該第1の通信装置との間で前記第2の通信を確立する前に当該第1の通信装置から受信すると、当該認証結果に基づいて、当該第1の通信装置との間で当該第2の通信を確立するか否かの認可判定を行う認可判定工程を含んだことを特徴とする通信制御方法。
  11. 第1の通信装置と第2の通信装置との間における通信の確立を制御する通信制御方法を当該第1の通信装置としてのコンピュータに実行させる通信制御プログラムであって、
    第三者機関装置との間で第1の通信を行うとともに前記第2の通信装置との間で第2の通信を行う前記第1の通信装置としてのコンピュータに、
    前記第2の通信装置との間で前記第2の通信を確立する前に、当該第1の通信装置を認証することを要求する認証要求を、当該第1の通信装置を認証する第三者機関装置に前記第1の通信にて送信する認証要求送信手順と、
    前記第三者機関装置によって認証された認証結果を当該第三者機関装置から前記第1の通信にて受信すると、前記第2の通信装置において当該認証結果に基づいて当該第1の通信装置との間で前記第2の通信を確立するか否かの認可判定が行われるように、当該認証結果を当該第2の通信装置に当該第2の通信を確立する過程において送信する認証結果送信手順と、
    を実行させることを特徴とする通信制御プログラム。
  12. 第1の通信装置と第2の通信装置との間における通信の確立を制御する通信制御方法を当該第2の通信装置としてのコンピュータに実行させる通信制御プログラムであって、
    前記第1の通信装置との間で第2の通信を行う前記第2の通信装置としてのコンピュータに、
    前記第1の通信装置を認証する第三者機関装置から当該第1の通信装置が第1の通信にて受信した認証結果を、当該第1の通信装置との間で前記第2の通信を確立する前に当該第1の通信装置から受信すると、当該認証結果に基づいて、当該第1の通信装置との間で当該第2の通信を確立するか否かの認可判定を行う認可判定手順を実行させることを特徴とする通信制御プログラム。
JP2007340744A 2007-12-28 2007-12-28 通信制御システム、通信制御方法、および通信制御プログラム Expired - Fee Related JP4851439B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007340744A JP4851439B2 (ja) 2007-12-28 2007-12-28 通信制御システム、通信制御方法、および通信制御プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007340744A JP4851439B2 (ja) 2007-12-28 2007-12-28 通信制御システム、通信制御方法、および通信制御プログラム

Publications (2)

Publication Number Publication Date
JP2009164802A true JP2009164802A (ja) 2009-07-23
JP4851439B2 JP4851439B2 (ja) 2012-01-11

Family

ID=40966913

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007340744A Expired - Fee Related JP4851439B2 (ja) 2007-12-28 2007-12-28 通信制御システム、通信制御方法、および通信制御プログラム

Country Status (1)

Country Link
JP (1) JP4851439B2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013239883A (ja) * 2012-05-15 2013-11-28 Nippon Telegr & Teleph Corp <Ntt> 電話システムおよびその動作方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000041032A (ja) * 1998-07-22 2000-02-08 Hitachi Ltd 複数認証機関のポリシーに対応可能な認証書取得方式
JP2003233595A (ja) * 2002-02-12 2003-08-22 Kddi Corp 携帯電話端末における利用者認証システム及び方法、並びに利用者認証プログラム
WO2005011192A1 (ja) * 2003-07-11 2005-02-03 Nippon Telegraph & Telephone アドレスに基づく認証システム、その装置およびプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000041032A (ja) * 1998-07-22 2000-02-08 Hitachi Ltd 複数認証機関のポリシーに対応可能な認証書取得方式
JP2003233595A (ja) * 2002-02-12 2003-08-22 Kddi Corp 携帯電話端末における利用者認証システム及び方法、並びに利用者認証プログラム
WO2005011192A1 (ja) * 2003-07-11 2005-02-03 Nippon Telegraph & Telephone アドレスに基づく認証システム、その装置およびプログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013239883A (ja) * 2012-05-15 2013-11-28 Nippon Telegr & Teleph Corp <Ntt> 電話システムおよびその動作方法

Also Published As

Publication number Publication date
JP4851439B2 (ja) 2012-01-11

Similar Documents

Publication Publication Date Title
US10742631B2 (en) Using an IP multimedia subsystem for HTTP session authentication
CN102150408B (zh) 用于从身份管理系统获得用于应用程序的用户证书的方法、设备和计算机程序产品
US8595816B2 (en) User authentication system and method for the same
EP2705642B1 (en) System and method for providing access credentials
US9648006B2 (en) System and method for communicating with a client application
US9344417B2 (en) Authentication method and system
JP4620755B2 (ja) ワイヤレスホームエリアネットワークを動作させる方法及び装置
JP5292712B2 (ja) 認証連携システム、中継装置、認証連携方法および認証連携プログラム
JP2009027652A (ja) 接続制御システム、接続制御方法、接続制御プログラムおよび中継装置
US20070150726A1 (en) System and method for securely storing and accessing credentials and certificates for secure VoIP endpoints
US20080137859A1 (en) Public key passing
Beltran et al. User identity for WebRTC services: A matter of trust
WO2001047232A2 (en) Secure enrollment of a device with a clearinghouse server for internet telephony system
Sabadello et al. Introduction to did auth
US20240106808A1 (en) Encryption-based device enrollment
JP4472566B2 (ja) 通信システム、及び呼制御方法
US11146536B2 (en) Method and a system for managing user identities for use during communication between two web browsers
JP4950095B2 (ja) サービス提供システム、サービス提供方法およびサービス提供プログラム
JP2007334753A (ja) アクセス管理システムおよび方法
JP4851439B2 (ja) 通信制御システム、通信制御方法、および通信制御プログラム
JP4963425B2 (ja) セッション鍵共有システム、第三者機関装置、要求側装置、および応答側装置
JP2004343440A (ja) 通信制御方法及びシステム
EP2274927A1 (en) Service reporting
WO2011017851A1 (zh) 客户端安全访问消息存储服务器的方法和相关设备
JP4551376B2 (ja) 顧客情報開示システム、顧客情報開示方法、顧客装置、および顧客プログラム

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20101029

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20101214

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110209

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110322

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110520

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20110520

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20110520

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110607

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110802

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20111018

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20111020

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20141028

Year of fee payment: 3

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

LAPS Cancellation because of no payment of annual fees