JP2014096181A - 電気通信システムにおいて特権を付与してリソースを共有する方法 - Google Patents

Abstract

【課題】電気通信システムにおいて、リソースを共有する目的で特権を付与する方法を提供する。
【解決手段】サービス提供ドメインがサービス要求ドメイン内で要求するユーザに特権を付与することを可能とするための特権付与技術を提供する方法および装置が開示される。１以上のサービス関連リソースからなるサービス提供ドメイン内の要求処理装置が、本発明の実施例によって、サービスを利用するためのユーザのリクエストを受信し、特権付与サーバにトークンを要求する。特権付与サーバから付与される特権を特定するトークンを受信すると、要求処理装置は特権を要求元のユーザに拡張する。あるいは、要求処理装置は複数のトークンを前もって特権付与サーバに要求することもでき、トークンの受信後に、要求処理装置が１以上のサービスを利用するためのリクエストを受信すると、要求処理装置は特権を各要求元ユーザに拡張する。
【選択図】図２

Description

本発明は概略として電気通信に関し、より詳細には、電気通信システムにおいて１以上のリソースを共有する目的で１以上の特権を付与することに関する。

図１は従来技術における電気通信システム１００のブロック図である。電気通信システム１００には３つのタイプのデータ処理システムが示されている。それらは、（i）リソースを使うもの（例えば、ユーザシステム）、（ii）リソースそのもの、および（iii）ユーザシステムがリソースを使用するか否かを決定するセキュリティシステム、である。システム１００は、図のように相互接続される（i）ユーザ１１１、つまりユーザシステム；（ii）リソース１１４および１２４；並びに（iii）認証サーバ１１２および１２２並びにチケット付与サーバ１１３および１２３、つまりセキュリティシステム；からなる。

ユーザシステムが、サービスに関連するようなリソースを使用するか否かを決定するために、ユーザシステムは（i）認証され、および（ii）そのリソースを使用することを許可されなくてはならない。「認証」とは、セキュリティシステムが、ユーザシステムがあるべきものであることを認証するためのプロセスである。「許可」とは、セキュリティシステムがユーザシステムに対して、手順を進みそのリソースを使用するために特権を付与することである。

認証および許可はデータ通信ではよく知られているプロセスであり、あるレベルのセキュリティを認証若しくは許可またはその両方によって提供する多くのプロトコルが従来技術には存在する。電気通信システム１００は、ケルブロス（Ｋｅｒｂｅｒｏｓ）といわれる１つのそのようなプロトコルを用いて、ユーザ１１１に特権を与えるか否かを決定する。

第１の例において、ユーザ１１１、つまりクライアントマシンは、リソース１１４、つまりそのクライアントに対して、ローカルなデータベースサーバを使用する必要があるとする。リソース１１４は扱いに注意を要する情報を含んでいるので、ユーザ１１１はそのリソースを使用する前に、まず認証を受け許可されなくてはならない。ユーザ１１１は認証サーバ１１２によってローカルエリアネットワーク１１５を介して認証され、リソース１１４に対して身元の証明を提示するためにユーザによって使用される「チケット」がチケット付与サーバ１１３によって発行される。ユーザ１１１はそのチケットをリソース１１４に提示し、そしてリソース１１４に記憶された情報にアクセスすることを許可される。ユーザ１１１およびリソース１１４が互いにローカルであり、その結果として、それらは同じ認証および許可システム、即ち、認証サーバ１１２およびチケット付与サーバ１１３を使用することができるということにある程度起因して、このプロセスはほどよく簡素である。実際に、共通の認証サーバおよびチケット付与サーバがあるので、ユーザ１１１、サーバ１１２および１１３、リソース１１４並びにネットワーク１１５はそれら自身のケルブロス領域内に存在しているといえる。なお、その領域は図１の領域１１０として図示されている。

第２の例において、今、ユーザ１１１が異なるリソースであるリソース１２４、即ち、クライアントから離れたデータベースサーバを使用する必要があるとする。リソース１２４も扱いに注意を要する情報を含んでいるので、ユーザ１１１はリソース１２４を使用する前に、まず認証を受け許可されなくてはならない。しかし、リソース１２４へのアクセスがユーザ１１１に対してローカルなセキュリティシステムとは異なるセキュリティシステムによって制御されているという点で、リソース１２４はユーザ１１１とは異なる領域にある。このため、リソース１２４は、ユーザ１１１の領域とは異なる領域（図１で領域１２０として示す領域）にあるとみなされる。異なる領域にあるリソース１２４へのチケットを得るためには、ユーザ１１１はチケット付与サーバ１２３によって受け入れられるチケットをチケット付与サーバ１１３に要求しなければならない。離れたチケット付与サーバ１２３がローカルなチケット付与サーバ１１３に登録されていた場合、サーバ１１３はサーバ１２３で有効な第１のチケットをユーザ１１１に与える。ユーザ１１１は第１のチケットをサーバ１２３にネットワーク１１５および１２５を介して提示し、そして、リソース１２４に記憶されている情報にアクセスするための（または領域１２０の他のリソースにアクセスするための）第２のチケットをサーバ１２３から得ることを許可される。

電気通信システム１００によって使用されるセキュリティプロトコルについての問題は、図１の関連部１３０で示すように、チケット付与サーバ１１３と１２３とが「信頼関係」を持っている必要があることである。即ち、サーバ１１３と１２３は互いを知っていなければならず、情報を共有していなければならず、そして、その情報について互いを信用しなければならない。しかし、信頼関係は管理するのが難しいことに加えて、それは電気通信システムによっては十二分に必要なものである。

本発明は、サービス提供ドメインがサービス要求ドメイン内の要求元ユーザに対して特権を付与することを可能とするための特権付与技術を提供する。本発明の実施例によると、１以上のサービスに関連するリソースからなるサービス提供ドメインにおける要求処理装置がサービスを利用するためにユーザのリクエストを受信し、特権付与サーバにトークンを要求する。特権付与サーバからの付与される特権を特定するトークンを受信すると、要求処理装置は特権を要求元ユーザに拡張する。また、要求処理装置は前もって複数のトークンを特権付与サーバに要求できる。要求処理装置が１以上のサービスを利用するためのリクエストを受信するたびに、要求処理装置は、トークンを受け取った後に、要求元ユーザ各々に特権を拡張する。

実施例における特権付与技術は、何らかの電気通信システムにおいて、そのサービスに関連するリソースと同じドメイン内の、サービス要求を処理する装置のみを認証および許可すれば十分であるという事実に基づいている。それらの電気通信システムにおいては、異なるサービス要求ドメインにおいてユーザ達を許可および認証しなければならないということはない。結果として、実施例の技術において、２つのドメイン（即ち、サービス要求ドメインおよびサービス提供ドメイン）はケルブロス的に互いに信用している必要はない。

実施例の技術に基づく特権の付与方法は、種々のアプリケーション、特に、セッション開始プロトコル（ＳＩＰ：Session Initiation Protocol）に基づくアプリケーションに役立つ。ＳＩＰに基づくファクシミリサービス、ＳＩＰを用いるコレクトコール、および自動受信制御された呼の転送のような新しいサービスは、開示される技術を従来のその関連の技術よりも好適に適用できる。

本発明の実施例は、サービス提供ドメインにおいて、サービス要求ドメイン内の第１のデータ処理システムによって発せられたサービス提供ドメイン内のサービスを利用するためのリクエストを受信するステップ；そのサービス提供ドメイン内の第２のデータ処理システムにトークンを求めるリクエストを送信するステップであって第２のデータ処理システムは第１のデータ処理システムの素性（アイデンティティ）を知らないようなステップ；および、そのトークンを受信するステップであってそのトークンが付与される特権を特定しているようなステップからなる。

図１は従来技術における電気通信システム１００のブロック図である。 図２は本発明の実施例による電気通信システム２００のブロック図である。 図３は本発明の実施例による要求処理装置２２１の主要な構成要素のブロック図である。 図４は電気通信システム２００に関連する第１のメッセージフローの図である。 図５は電気通信システム２００に関連する第２のメッセージフローの図である。 図６は電気通信システム２００に関連する第３のメッセージフローの図である。

本明細書および請求項において、「ドメイン」という用語を、共通の通信アドレスを共有するデータ処理システムのグループと定義する。例えば、サービス要求ドメインは、１以上のサービスを利用することを要求するユーザ・データ処理システムが存在する領域である。サービス提供ドメインは、それらの要求されたサービスに関連するリソースへのアクセスを制御するデータ処理システムとともにそれらのリソースが存在する領域である。

図２に本発明の実施例による電気通信システム２００のブロック図を示す。電気通信システム２００は、ユーザ２１１−１〜２１１−Ｍ（Ｍは自然数）、ローカルエリアネットワーク２１２、要求処理装置２２１、認証サーバ２２２、特権付与サーバ２２３、リソース２２４−１〜２２４−Ｎ（Ｎは自然数）、およびローカルエリアネットワーク２２５からなり、図示するように相互接続されている。

電気通信システム２００は２つのドメイン、即ち、サービス要求ドメイン２１０およびサービス提供ドメイン２２０からなる。ユーザ２１１−１〜２１１−Ｍおよびローカルエリアネットワーク２１２がサービス要求ドメイン２１０を構成する。要求処理装置２２１、認証サーバ２２２、特権付与サーバ２２３、リソース２２４−１〜２２４−Ｎ、およびローカルエリアネットワーク２２５がサービス提供ドメイン２２０を構成する。信頼関係はサービス要求ドメイン２１０とサービス提供ドメイン２２０との間に、少なくともある期間は、及んでいない。さらに、ある実施例では、サービス提供ドメイン２２０は特権付与サーバ２２３の素性を要求元ユーザ２２１−ｍに与えない（ｍは１以上Ｍ以下の値である）。さらに、ある実施例では、サービス提供ドメイン２２０は１以上のリソース２２４−１〜２２４−Ｎの素性を要求元ユーザ２２１−ｍに与えない。

ユーザ２２１−ｍは、サービス提供ドメイン２２０において利用可能なサービスのリクエストを出すことができるサービス要求ドメイン２１０内のデータ処理システムである。さらに、一度サービス提供ドメイン２２０がユーザ２２１−ｍにサービスを利用するための特権を付与すると、ユーザ２１１−ｍはサービスを利用することができる。人間のユーザはサービスを要求し利用するためにユーザ２１１−ｍを操作する。例えば、ユーザ２１１−ｍは音声またはデータトラフィックを送受信することができるパソコンまたは電気通信端末であってもよい。また、代替の実施例では、ユーザ２１１−ｍは人間のユーザに従属していなくてもよい。当業者であれば分かるように、実施例において、ユーザ２１１−１〜２１１−Ｍは同じサービス要求ドメイン内に存在していてもよいし、２以上のサービス要求ドメインにわたって分散していてもよい。

ユーザ２１１−ｍはサービス提供ドメイン２２０内のデータ処理システムとローカルエリアネットワーク２１２を介して公知の方法で通信する。ユーザ２１１−ｍをどのように構成し使用するかは当業者には明白なはずである。

要求処理装置２２１は、１以上のサービスを利用するためのサービス要求ドメイン２１０からのリクエストを受信するとともに、それらのリクエストを処理するためにサービス要求ドメイン２１０内のユーザの代わりに行動するデータ処理システムである。実施例によると、要求処理装置２２１はユーザ２１１−１〜２１１−Ｍとセッション開始プロトコルを介して通信する。しかし、処理装置２２１は他のセットのプロトコル（例えば、Ｈ．３２３など）を介して通信することもできることが分かる。ユーザからの過去または将来のリクエストを処理するときに、処理装置２２１は認証サーバ２２２、特権付与サーバ２２３および１以上のリソース２２４−１〜２２４−Ｍと相互通信する。処理装置２２１はサービス提供ドメイン２２０の他の構成要素とローカルエリアネットワーク２２５を介して公知の方法で通信する。下記に図３に関して処理装置２２１の主要な構成要素を説明する。処理装置２２１は、下記に図４および５に関して説明する関連するタスクを実行する。

認証サーバ２２２は要求処理装置２２１を必要に応じて公知の方法で認証するシステムである。サーバ２２２は処理装置２２１から認証リクエストを直接受信し、あるいは、処理装置２２１を認証するためのリクエストを特権付与サーバ２２３から受信する。当業者であれば分かるように、サーバ２２２は処理装置２２１を認証する多くの公知技術の１つを用いるようにすればよい。当業者には認証サーバ２２２をどのように構成し使用するかは明白である。

本発明の実施例によると、特権付与サーバ２２３は、１以上のリソース２２４−１〜２２４−Ｎの使用を関与させる１以上のサービスを利用するための特権を付与するデータ処理システムである。サーバ２２３は１以上のトークンに対するリクエストを処理装置２２１から受信し、ここで各トークンは特権の付与自体も含めた付与される特権に関係する情報を提供する。サーバ２２３は処理装置２２１に対して、処理装置２２１がまだそうしていなければ、認証サーバ２２２に認証することを要求してもよい。特権付与サーバ２２３は処理装置２２１の素性を知っているが、サーバはサービスのリクエストを出しているユーザの素性を知っている必要はない。

サーバ２２３は１以上のトークンを生成し、それらを処理装置２２１に送信し、それによって処理装置２２１を許可して各付与される特権へのアクセスを提供する。サーバ２２３はまた、サービス要求ドメイン２１０からのユーザのその後の信号を受け入れて処理するためにサービス提供ドメイン２２０内の必要な環境をセットアップする役割を担う。さらに、サーバ２２３は付与される特権を要求元ユーザ（即ち、ユーザ２２１−ｍ）に拡張する（即ち、当該ユーザに利用可能とする（以下同じ））。本明細書を読めば、当業者には特権付与サーバ２２３をどのように構成し使用するかは明らかなものとなる。

リソース２２３−ｎ（ｎは１以上Ｎ以下の値）はサービスに関連するリソースである。リソース２２４−ｎはスタンドアローン型装置、他の装置の一部、ソフトウェアエンティティなどである。例えば、リソース２２４−ｎはデータベース、プリンタ、ファイヤーウォールにおけるポートまたはルール、会議ブリッジなどである。当業者にはリソース２２４−ｎをどのように構成し使用するかは明白である。

要求処理装置２２１は特権付与サーバ２２３とともにリソース２２４−１〜２２４−Ｎのどれが要求されたサービスとして必要かを判断する。例えば、要求されたサービスが、ユーザ２１１−１からファックスプリンタリソース２２４−３の近くにいる特定の受信者へのファクシミリ送信の処理に対応する場合、処理装置２２１およびサーバ２２３はファックスプリンタが必要とされていること、およびリソース２２４−３がその受信者に最も近いファックスプリンタであることを特定し、処理装置２２１はそれをユーザに示す。

図３に本発明の実施例による要求処理装置２２１の主要な構成要素のブロック図を示す。要求処理装置２２１はネットワークインターフェイス３０１、プロセッサ３０２およびメモリ３０３からなり、図示するように相互接続される。

ネットワークインターフェイス３０１は受信部および送信部からなる。受信部は、公知の方法で、電気通信システム２００内の他のデータ処理システムからの信号を受信し、信号内の符号化された情報をプロセッサ３０２に転送する。送信部は、公知の方法で、プロセッサ３０２からの情報を受信し、この情報を符号化するパケット関連信号を他のデータ処理システムに出力する。当業者にはネットワークインターフェイス３０１をどのように構成し使用するかは明白である。

プロセッサ３０２はネットワークインターフェイス３０１からの情報を受信することができる一般用途プロセッサであり、メモリ３０３からデータを読み出し、メモリ３０３にデータを書き込み、下記に図４および５に関連して説明するタスクを実行し、情報をネットワークインターフェイス３０１へ送信する。本発明の代替の実施例では、プロセッサ３０２は特定用途プロセッサであってもよい。いずれの場合も、本明細書を読めば、当業者にはプロセッサ３０２をどのように構成し使用するかは明らかなものとなる。

メモリ３０３はデータおよび実行可能な命令を公知の方法で格納する。当業者にはメモリ３０３をどのように構成し使用するかは明白である。

図４に本発明の実施例による電気通信システム２００に関連する第１のメッセージフローを示す。メッセージフローは、ユーザ２１１−１、即ち、サービス提供ドメイン２２０内のサービスを利用することを要求しているサービス要求ドメイン２１０内の第１のデータ処理システムから始まる。当業者には、図４に示すどのイベントが同時に、または図示されたものとは異なる順序で実行され得るかは明らかなはずである。

メッセージ４０１によって、要求処理装置２２１がサービス提供ドメイン２２０内のサービスを利用するためにユーザ２１１−１によって送信されたリクエストを受信する。そのリクエストは、リクエストを識別し処理するために要求処理装置２２１によって使用される何らかの予備的な情報を含む。

イベント４０２において、要求処理装置２２１はリクエスト中の予備的な情報に部分的に基づいてリクエストを受け入れるか否かを判断する。リクエストを受け入れる場合、処理装置２２１は自身を認証サーバ２２２に認証する必要があるかを判断する。実施例によっては、要求処理装置２２１はまた、ユーザ２１１−１が利用することを要求している特定のサービスに基づいて、リソース２２４−１〜２２４−Ｎのどれが必要とされているかを判断する。

要求処理装置２２１は自身を認証する必要がある場合、認証シーケンス４０３を認証サーバ２２２に対して公知の方法で行う。認証は要求処理装置２２１に対するものであってユーザ２１１−１に対するものではないので、認証シーケンス４０３はサービス要求ドメイン２１０を関与させない。

認証が成功すると、メッセージ４０４の一部として、要求処理装置２２１はトークンを求めるリクエストを送信する。要求処理装置２２１はそのリクエストを特権付与サーバ２２３、即ち、第２のデータ処理システムに送信する。実施例によっては、処理装置２２１はまた、どのリソースが要求されたサービスに関連するかを判断し、それらのリソースについての情報をサーバ２２３に対するリクエストの一部として送信する。

特権付与サーバ２２３は、要求されたサービスに対してどのリソースが必要とされているかを自律的にあるいは処理装置２２１からの入力によって判断する。ある実施例では、選択されたリソースによっては、特権付与サーバ２２３は、サービスに対するユーザ２２１−１のリクエストを受け入れるために選択されたリソースの環境―――ここではリソース２２４−４の環境―――をセットアップするためのメッセージ４０５を送信する。

サーバ２２３はまた、１以上のリソースの特定目的使用のような付与される特権を特定するトークンを生成する。実施例によっては、付与される特権はリソースの回数制限付き使用に関するものである。例えば、回数制限付き使用は一回限りの使用であってもよい。メッセージ４０６の一部として、サーバ２２３はそのトークンを送信し、それは要求処理装置２２１によって受信される。この時点で、要求処理装置２２１はそのトークンによって特定される付与される特権を拡張することを許可される。

メッセージ４０７によって、要求処理装置２２１はトークンの一部として受信した付与される特権をユーザ２１１−１に拡張する。さらに、処理装置２２１は要求されたサービスに関連するリソース―――ここではリソース２４４−４―――にどのようにアクセスするかの情報をユーザ２１１−１に転送する。

そして、ユーザ２１１−１は処理装置２２１によって転送された情報を利用して、メッセージ４０８をリソース２２４−４に送信することによって要求したサービスを利用する。

図５に本発明の実施例による電気通信システム２００に関連する第２のメッセージフローを示す。メッセージフローは、１以上のユーザ２１１−１〜２２１−Ｍからのサービスリクエストを処理する際に後で使用する１以上のトークンを特権付与サーバ２２３に要求する要求処理装置２２１に始まるシーケンスを示す。当業者には、図５に示すどのイベントが同時に、または図示されたものとは異なる順序で実行され得るかは明らかなはずである。

イベント５０１において、要求処理装置２２１は１以上のトークンを特権付与サーバ２２３に要求するために準備する。処理装置２２１は自身を認証サーバ２２２によって認証する必要があるか否かを判別する。実施例によっては、要求処理装置２２１はまた、処理装置２２１が１以上のユーザ（例えば、ユーザ２１１−１、ユーザ２２１−２など）から受信したと推定する、１以上のサービスを利用するためのリクエストに基づいてリソース２２４−１〜２２４−Ｍのどれが必要とされているのかを判定する。

要求処理装置２２１が自身を認証する必要がある場合、それは認証シーケンス５０２を認証サーバ２２２によって公知の方法で行う。認証は要求処理装置２２１に対するものであってユーザ２１１−１や２１１−２に対するものではないので、認証シーケンス５０２はサービス要求ドメイン２１０を関与させない。

認証が成功すると、メッセージ５０３の一部として、要求処理装置２２１は１以上のトークンについてのリクエストを送信する。要求処理装置２２１はそのリクエストを特権付与サーバ２２３に送信する。実施例によっては、処理装置２２１はまた、要求されたと思われるサービスにどのリソースが関連するかを判断し、それらのリソースについての情報をサーバ２２３に対するリクエストの一部として送信する。

特権付与サーバ２２３は、要求されたと思われるサービスに対してどのリソースが必要とされているかを自律的にあるいは処理装置２２１からの入力によって判断する。ある実施例では選択されたリソースによっては、特権付与サーバ２２３は、サービスに対する将来のリクエストを受け入れるために選択されたリソースの環境―――ここではリソース２２４−４および２２４−７の環境―――をセットアップするためのメッセージ５０４および５０５を送信する。

サーバ２２３はまた１以上のトークンを生成する。ここで、付与されたトークン各々は、１以上のリソースの特定目的使用のような付与される特権を特定する。ある実施例では、付与される特権はリソースの回数制限付き使用に関するものである。例えば、回数制限付き使用は一回限りの使用であってもよい。メッセージ５０６の一部として、サーバ２２３はそのトークンを送信し、それは要求処理装置２２１によって受信される。この時点で、要求処理装置２２１は受信されたトークン各々によって特定される付与される特権を、サービスの利用を引き続き要求する各ユーザに対して拡張することを許可される。

メッセージ５０７によって、最終的に要求処理装置２２１は、ユーザ２１１−１から送信されたサービス提供ドメイン２２０内のサービスを利用するためのリクエストを受信する。そのリクエストは、リクエストを識別し処理するために要求処理装置２２１によって使用される予備的な情報を含む。

メッセージ５０８によって、要求処理装置２２１は、トークンの一部として特権付与サーバ２２３から受信された付与される特権をユーザ２１１−１に拡張する。さらに、処理装置２２１は要求されたサービスに関連するリソース―――ここではリソース２４４−４―――にどのようにアクセスするかの情報をユーザ２１１−１に転送する。

そして、ユーザ２１１−１は処理装置２２１によって転送された情報を利用して、メッセージ５０９をリソース２２４−４に送信することによって要求したサービスを利用する。

最終的にメッセージ５１０によって、要求処理装置２２１は、サービス提供ドメイン２２０内の以前とは異なるサービスを利用するための、以前とは異なるユーザであるユーザ２１１−２によって送信されたリクエストを受信する。そのリクエストは、リクエストを識別および処理するために要求処理装置２２１によって使用される何らかの予備的な情報を含む。提供された例は以前とは異なるサービスを利用するために要求するものを示しているが、要求処理装置２２１は同じサービスに対する異なるユーザからのリクエストを処理できることは分かるはずである。

メッセージ５１１によって、要求処理装置２２１はトークンの一部として特権付与サーバ２２３から受信された付与される特権をユーザ２１１−２に拡張する。さらに、処理装置２２１は要求されたサービスに関連するリソース―――ここではリソース２４４−７―――にどのようにアクセスするかの情報をユーザ２１１−２に転送する。

そして、ユーザ２１１−２は処理装置２２１によって転送された情報を利用して、メッセージ５１２をリソース２２４−７に送信することによって要求したサービスを利用する。

実施例における技術を利用するいくつかのアプリケーションをここに開示する。実施例の特権付与技術を利用する第１のアプリケーション―――セッション開始プロトコルを用いるファクシミリサービス―――がここに開示され、そのメッセージフローを図６に示す。メッセージフローは、ユーザ２１１−１がサービス提供ドメイン２２０内の受信者の近くにあるプリンタにファクシミリが送られることを要求するシーケンスを示す。

このアプリケーションにおいて、特権付与サーバ２２３はファクシミリサーバとして機能するので、説明の便宜のため「ファックスサーバ２２３」という。認証サーバ２２２に関連する機能は、ウィンドウズ・ドメイン認証のような業者のユーザ認証エンジンによって提供される。サービスに関連するリソースであるリソース２２４−１はファクシミリファイルが受信されるプリンタである。

図６を参照すると、メッセージ６０１によって、要求処理装置２２１が、サービス提供ドメイン２２０においてファクシミリを受信するための、ユーザ２１１−１によって送信されたリクエストを受信する。そのリクエスト―――それはＳＩＰ・ＩＮＶＩＴＥメッセージの一部となり得る―――は送られているファクシミリに関する何らかの情報（例えば、ページ数、送信フォーマット、最初のページのプレビューなど）を含む。

イベント６０２において、要求処理装置２２１はリクエスト中の予備的な情報に基づいてリクエストを受け入れるか否かを判断する。リクエストを受け入れる場合、処理装置２２１は自身を認証サーバ２２２に認証する必要があるか否かを判断する。ある実施例では、要求処理装置２２１はまた、ユーザ２１１−１が利用することを要求している特定のサービスに基づいてリソース２２４−１〜２２４−Ｎのどれが必要とされているかを判断する。

メッセージ６０３によって、要求処理装置２２１はトークンを求めるリクエストを送信する。即ち、それはファックスサーバ２２３に対するリクエストを送信する。そして、ファックスサーバ２２３は、認証サーバ２２２（またはその機能上の同等物）が要求処理装置２２１を認証することをメッセージ６０４を介して要求する。

サーバ２２２は要求処理装置２２１に対して認証シーケンス６０５を（例えば、ドメインコントローラ認証を介して、など）公知の方法で実行する。サーバ２２２はメッセージ６０６を介してファックスサーバ２２３に認証結果を提供する。あるいは、図４および５に関して記載したように、要求処理装置を認証するために、ファックスサーバ２２３ではなく要求処理装置２２１がサーバ２２２にコンタクトをとるようにしてもよい。

ファックスサーバ２２３はどのプリンタがファクシミリの受信者に最も近いかを判断し、リソース２２４−１が最も近いプリンタであることが分かる。ファックスサーバ２２３は、必要であれば、プリンタを準備するためのメッセージ６０７をリソース２２４−１へ送信する。

ファックスサーバ２２３はまた、使用されるプリンタのような他の関係する情報だけでなく、要求処理装置２２１およびユーザ２１１−１（即ち、ファックスの送信元）の素性に基づいてトークン―――ここではクッキーである―――を生成する。トークンはファックス送信のために確認されたプリンタを利用するための付与される特権を特定する。実施例によっては、付与される特権はリソースの回数制限付き使用に対するものである。例えば、回数制限付き使用は一回限りの使用であってもよい。メッセージ６０８の一部として、ファックスサーバ２２３はトークンを送信し、そして、要求処理装置２２１によって受信される。この時点で、要求処理装置２２１はトークンによって特定される付与される特権を拡張することを許可される。

メッセージ６０９によって、要求処理装置２２１はトークンの一部として受信された付与される特権をユーザ２１１−１に拡張する。なお、メッセージ６０９はＳＩＰ・ＲＥＤＩＲＥＣＴであってもよい。さらに、処理装置２２１はそのプリンタにどのようにアクセスするかの情報をユーザ２１１−１に転送する。

メッセージ６１０を介して、ユーザ２１１−１は要求処理装置２２１によって転送された情報を利用して（例えば、ポストスクリプト・フォーマット、ＰＤＦフォーマットなどの）印刷情報を含むファイルをクッキーとともにファックスサーバ２２３へ送る。

そして、ファックスサーバ２２３はドキュメントファイルをプリンタ（即ち、リソース２２４−１）に送ることによって交信を完了する。サーバ２２３はファックスの配信およびプリンタの位置を示すステータスを要求処理装置２２１に送る。ステータスはメッセージ６１２を介して送られる。なお、メッセージ６１２はＳＩＰインスタント・メッセージであってもよい。そして、要求処理装置２２１はステータスの、人間による受信を知らせる。ファックスサーバ２２３はまた、確認メッセージ６１３をユーザ２１１−１に送り、ファックスがプリンタに配信されたことを示す。

実施例の特権付与技術を利用する第２のアプリケーション―――セッション開始プロトコルを用いるコレクトコール―――がここに開示される。当業者であれば分かるように、第三者課金のような関連する機能が同様に実施され得る。このアプリケーションのメッセージフローは図６に示したものと類似している。例えば、このコレクトコールアプリケーションにおいて、ユーザ２１１−１は呼に対してなされる課金をサービス提供ドメイン２２０内の受信者に返送することを要求する。なお、サーバ２２３は受信者のサービスプロバイダのコールコレクトサーバとして機能するので、以下、「コールコレクトサーバ２２３」という。他の違いとして、サービスに関連するリソースであるリソース２２４−１は、課金のために呼の詳細な記録を付加する能力だけでなく、ファイヤーウォールにおけるポートまたはルールも備える。

図６に示すように、発呼者（即ち、ユーザ２１１−１）はＳＩＰ・ＩＮＶＩＴＥメッセージ６０１を要求処理装置２２１に送信し、リクエストが返送された課金を含んでいることを示す。リクエストが受け入れられると、要求処理装置２２１はコールコレクトサーバ２２３にメッセージ６０３を介してコンタクトをとる。なお、リクエストの受け入れはイベント６０２で決定される。サーバ２２３は、要求処理装置２２１が認証サーバ２２２に対して認証することを必要とするとともにメッセージ６０４を介してこのことを示してもよい。認証サーバ２２２は認証プロセスの一環として認証シーケンス６０５を介して個人識別番号およびパスワードを要求処理装置２２１に要求する。

認証が完了し、サーバ２２２がコールコレクトサーバ２２３にメッセージ６０６を介して結果を提示すると、サーバ２２３はリソース２２４−１（即ち、ファイヤーウォール）においてメッセージ６０７を介してポートまたはルールをアクティベートして、その呼に関連するデータトラフィックが流れるようにする。

メッセージ６０８の一部として、サーバ２２３は付与されたトークンを送信し、それは要求処理装置２２１によって受信される。この時点で、要求処理装置２２１はコレクトコールを進めるためのトークンによって指定される付与される特権を拡張することを許可される。

メッセージ６０９によって、要求処理装置２２１はユーザ２１１−１にトークンの一部として受信した付与される特権を拡張する。なお、メッセージ６０９はＳＩＰ・ＲＥＤＩＲＥＣＴメッセージであってもよい。さらに、処理装置２２１は呼のトラフィックをどのようにルーティングするかについての情報をユーザ２１１−１に転送する。

メッセージ６１０を介して、ユーザ２１１−１は処理装置２２１によって転送された情報を用いて、呼のトラフィックをサーバ２２３によって受信者にルーティングする。

実施例の特権付与技術を利用する第３のアプリケーション―――受信者による会議ブリッジへの自動的な転送―――がここに開示される。このアプリケーションのメッセージフローは、いくつかの追加的な検討事項を付加すれば図６に示したものと類似する。例えば、この会議ブリッジアプリケーションにおいて、ユーザ２１１−１はサービス提供ドメイン２２０における会議ブリッジに追加されることを要求する。要求処理装置２２１は会議コールのホストとして機能し、ホストとして処理装置２２１は、予め了承された参加者リストをセットアップし、発呼者各々へのアクセスを可能とするポリシーをセットアップし、または、明示的な「許可／拒否」リストを保持する。「認証サーバ２２２」の機能は会議ブリッジソフトウエアに付帯している。なお、サーバ２２３はサービスプロバイダの会議を行うサーバとして機能するので、以下、「電話会議サーバ２２３」という。他の違いは、サービスに関連するリソースであるリソース２２４−１が会議ブリッジ自体（即ち、機器若しくはソフトウエアまたはその両方）であることである。

図６に示すように、発呼者（即ち、ユーザ２１１−１）はＳＩＰ・ＩＮＶＩＴＥメッセージ６０１を要求処理装置２２１に送信し、リクエストが会議ブリッジに追加されることを示す。リクエストが受け入れられると、要求処理装置２２１はコールコレクトサーバ２２３にメッセージ６０３を介してコンタクトをとる。なお、リクエストの受け入れはイベント６０２で決定される。サーバ２２３は要求処理装置２２１が認証機能（即ち、「認証サーバ２２２」）に対して認証することを必要とし、メッセージ６０４を介してこのことを示すようにしてもよい。認証機能によってホスト（即ち、処理装置２２１）をシーケンス６０５によって認証し、（図５に関して説明したメッセージフローにおけるように）各参加者の発呼ごとに、あるいは会議コールの前に、ホストが会議のポリシーまたは参加者リストを設定することを可能とする。

認証が完了し、サーバ２２２がコールコレクトサーバ２２３にメッセージ６０６を介して結果を提示すると、サーバ２２３は、必要であればメッセージ６０７を介して、リソース２２４−１、即ち、会議ブリッジを使用可能とする。

メッセージ６０８の一部として、サーバ２２３はトークン（例えば、一回限りのパスワードなど）を送信し、それは要求処理装置２２１によって受信される。この時点で、要求処理装置２２１は会議ブリッジをユーザ２１１−１において進めるためのトークンによって指定される付与される特権を拡張することを許可される。

メッセージ６０９によって、要求処理装置２２１はユーザ２１１−１にトークンの一部として受信した付与される特権を拡張する。なお、メッセージ６０９はＳＩＰ・ＲＥＤＩＲＥＣＴメッセージであってもよい。さらに、処理装置２２１は受信した一回限りのパスワードおよび呼トラフィックをブリッジまでどのようにルーティングするかについての情報をユーザ２１１−１に転送する。

メッセージ６１０を介して、ユーザ２１１−１はパスワードを使用して会議ブリッジにログオンし、転送された情報を使用して呼のトラフィックをブリッジを通じてルーティングする。なお、会議ブリッジサービスは、要求処理装置２２１を認証したことに加えて、さらに各発呼者を認証するためにログイン手順を用いることもできる。しかし、この第３のアプリケーションにおいては、実施例における特権付与技術を用いることによってブリッジ番号およびパスワードが各発呼者に送られるので、それらが前もって頒布されている必要はない。人間のユーザが外部的に関与することなく、終端におけるエージェントが認証およびブリッジへのログオンを実行する。

第３のアプリケーションは代替的に、（直前に示した図６ではなく）図５に関して説明されたメッセージフローを適用することによっても可能となる。この会議ブリッジアプリケーションに対する転送の変更例において、要求処理装置２２１（即ち、会議コールのホスト）は会議コールに先だって、予定参加者数に対して適切な数のトークンを得ておく。そして、各参加者は会議コールをかけると、要求処理装置２２１は、要求処理装置２２１がサーバ２２３からトークンの一部として受信した付与される特権を参加者に拡張する。さらに、処理装置２２１は受信した一回限りのパスワードおよび呼トラフィックをブリッジまでどのようにルーティングするかについての情報を参加者に転送する。

上述の実施例は本発明の単なる例示であり、上述の実施例に対する多数の変更例が当業者によって本発明の範疇を逸脱することなく考案され得ることが分かる。例えば、本明細書において、本発明の実施例の完全な記載と理解を提供するために多くの特定の詳細事項が提示された。しかし、当業者であれば、それらの詳細事項の１つまたはいくつかを欠いても、あるいは他の方法、素材（ソフトなど）、構成部材などを用いても実施可能であることは認識できるはずである。

さらに、例示によっては、実施例の特徴的側面が不明瞭になるのを避けるために、公知の構造、素材または動作を詳細には図示または記載していない。図面に示された種々の実施例は例示であり、必ずしも寸法通りには描かれていない。明細書を通じて、「１つの実施例」、「ある実施例」、「実施例によっては」などの記述は、実施例に関連して記載された特定の特徴、構造、素材または特性が本発明の少なくとも１つの実施例に含まれるが、必ずしも全ての実施例に含まれるとは限らないことを意味している。結果として、明細書中に随所に見られる「１つの実施例において」、「ある実施例では」、「実施例によっては」などの文言の使用は、必ずしも同じ実施例のことを指しているとは限らない。さらに、特定の特徴、構造、素材または特性は１以上の実施例において適宜組み合され得るものである。従って、そのような変更例は特許請求の範囲およびその均等な範囲に含まれることになる。

２００．電気通信システム
２１０．サービス要求ドメイン
２１１−１〜２１１−Ｍ．ユーザ
２１２．ローカルエリアネットワーク
２２０．サービス提供ドメイン
２２１．要求処理装置
２２２．認証サーバ
２２３．特権付与サーバ
２２４−１〜２２４−Ｎ．リソース
２２５．ローカルエリアネットワーク
３０１．ネットワークインターフェイス
３０２．プロセッサ
３０３．メモリ

Claims (28)

1. サービスを利用するためのリクエストを扱う方法であって、
   サービス要求ドメイン内の第１のデータ処理システムによって行われるサービス提供ドメイン内のサービスを利用するためのリクエストを、サービス提供ドメインにおいて受信するステップと、
   該サービス提供ドメイン内の第２のデータ処理システムにトークンのリクエストを送信するステップとを含み、該第２のデータ処理システムは、該第１のデータ処理システムの素性（アイデンティティ）を知らず、
   付与された特権を指定する該トークンを受信するステップと、
   該第１のデータ処理システムまで該付与された特権を延長するステップとを含み、
   １つのドメインが、共通の通信アドレスを共有する複数のデータ処理システムのグループを含み、該サービス提供ドメインの共通の通信アドレスは、該サービス要求ドメインの共通の通信アドレスとは独立である方法。
2. 請求項１記載の方法において、該付与される特権は、該サービスと関連する少なくとも１つのリソースの回数制限付き使用のためのものである方法。
3. 請求項２記載の方法において、該回数制限付き使用は、該少なくとも１つのリソースの一回限りの使用である方法。
4. 請求項１記載の方法において、該サービスを利用するための該リクエストを受信したことに基づいて、該サービスと関連する少なくとも１つのリソースを決定するステップを含む方法。
5. 請求項１記載の方法において、さらに、
   該第２データ処理システムから、認証に関連付けられたメッセージを受信するステップを含み、該認証は、該サービス提供ドメインに関連し、該サービス要求ドメインには関係しない方法。
6. 請求項１に記載の方法において、該サービス提供ドメインにおいて、該サービスを利用する該リクエストの受信の際に該サービス要求ドメインと該サービス提供ドメインとの間に信頼関係が存在しない方法。
7. 請求項６記載の方法において、該サービス提供ドメインは、該第２のデータ処理システムの素性を該第１のデータ処理システムに与えない方法。
8. 請求項６記載の方法において、該サービス提供ドメインは、該サービスと関連する少なくとも１つのリソースの素性を該第１のデータ処理システムに与えない方法。
9. 請求項１に記載の方法において、
   該サービスと関連する少なくとも１つのリソースにアクセスする方法を該第１のデータ処理システムに知らせるステップを含む方法。
10. 請求項１に記載の方法において、
    該第１のデータ処理システムまで該付与された特権を延長するステップは、少なくとの１つの暗号化されたメッセージを送信することによって行われる方法。
11. 請求項１記載の方法において、セッション開始プロトコルに従って、該サービスを利用するためのリクエストが受信されるとともに、該付与される特権が利用可能となる方法。
12. 請求項１に記載の方法において、該サービスは、該第１のデータ処理システムからのファックス通信の受信を含む方法。
13. サービスを利用するためのリクエストを扱う方法であって、
    サービス要求ドメイン内の第１のデータ処理システムによって行われるサービス提供ドメイン内のサービスを利用するためのリクエストを、サービス提供ドメインにおいて受信するステップと、
    該サービス提供ドメイン内の第２のデータ処理システムにトークンのリクエストを送信するステップと、
    該サービスと関連する少なくとも１つのリソースの回数制限付き使用のためのものである付与された特権を指定する該トークンを受信するステップとを含み、
    該第１のデータ処理システムまで該付与された特権を延長するステップとを含み、
    該サービス提供ドメインにおいて、該サービスを利用する該リクエストの受信の際に該サービス要求ドメインと該サービス提供ドメインとの間に信頼関係が存在せず、
    １つのドメインが、共通の通信アドレスを共有する複数のデータ処理システムのグループを含み、該サービス提供ドメインの共通の通信アドレスは、該サービス要求ドメインの共通の通信アドレスとは独立である方法。
14. 請求項１３に記載の方法において、該回数制限付き使用は、該少なくとも１つのリソースの一回限りの使用である方法。
15. 請求項１３に記載の方法において、
    該サービスを利用するための該リクエストを受信したことに基づいて、該サービスと関連する少なくとも１つのリソースを決定するステップを含み、該トークンのリクエストは、該少なくとも１つのリソースを指定する方法。
16. 請求項１３に記載の方法において、
    該第２データ処理システムから、認証に関連付けられたメッセージを受信するステップを含み、該認証は、該サービス提供ドメインに関連し、該サービス要求ドメインには関係しない方法。
17. 請求項１３に記載の方法において、
    該サービス提供ドメインは、該サービスと関連する少なくとも１つのリソースの素性を該第１のデータ処理システムに与えない方法。
18. 請求項１３に記載の方法において、
    該サービスと関連する少なくとも１つのリソースにアクセスする方法を該第１のデータ処理システムに知らせるステップを含む方法。
19. 請求項１３に記載の方法において、セッション開始プロトコルに従って、該サービスを利用するためのリクエストが受信されるとともに、該付与される特権が利用可能となる方法。
20. サービスを利用するためのリクエストを扱う方法であって、
    複数のトークンの要求を、サービス提供ドメイン内の第２のデータ処理システムに送信するステップを含み、該第２のデータ処理システムは、サービス要求ドメイン内の第１のデータ処理システムの素性（アイデンティティ）を知らず、該第１のデータ処理システムは、該サービス提供ドメイン内の第１のサービスを利用することができ、
    付与された第１の特権を指定する該複数のトークンを受信するステップと、
    該第１のデータ処理システムまで、該第１のサービスと関連する該付与された特権を延長するステップとを含み、
    １つのドメインが、共通の通信アドレスを共有する複数のデータ処理システムのグループを含み、該サービス提供ドメインの共通の通信アドレスは、該サービス要求ドメインの共通の通信アドレスとは独立である方法。
21. 請求項２０に記載の方法において、
    該第１の付与された特権は、該第１のサービスと関連する少なくとも１つのリソースの回数制限付き使用のためのものである方法。
22. 請求項２１に記載の方法において、該回数制限付き使用は、該少なくとも１つのリソースの一回限りの使用である方法。
23. 請求項２０に記載の方法において、該複数のトークンの該リクエストの該送信の際に該サービス要求ドメインと該サービス提供ドメインとの間に信頼関係が存在しない方法。
24. 請求項２０に記載の方法において、
    該サービスと関連する少なくとも１つのリソースを決定するステップを含み、該複数のトークンのリクエストは、該少なくとも１つのリソースを指定する方法。
25. 請求項２０に記載の方法において、
    該第３のデータ処理システムまで、該第２のサービスと関連する付与された第２の特権を延長するステップとを含み、
    該複数のトークンのうちの第２のトークンは、該外付与された第２の特権を指定し、
    該第２のデータ処理システムは、該第１のデータ処理システムの素性（アイデンティティ）を知らない方法。
26. 請求項２５に記載の方法において、該付与された第１の特権と該付与された第２の特権は同じである方法。
27. 請求項２０に記載の方法において、該第１のサービスは、該第１のデータ処理システムからのファックス通信の受信を含む方法。
28. 請求項２０に記載の方法において、該付与された第１の特権は、セッション開始プロトコルに従って延長される方法。

Images