JP5418681B2 - 仲介処理方法、仲介装置及びシステム - Google Patents

Description

本技術は、コンピュータ間の通信の仲介技術に関する。

ユーザが第１のサーバにデータを蓄えておき、当該第１のサーバに蓄えられているデータを第２のサーバに利用させる場合に、ＯＡｕｔｈというプロトコルが使用され始めている。簡単に図１を用いてＯＡｕｔｈについて説明しておく。

図１の前提としては、ユーザはプロバイダに自身のデータを蓄積している。また、コンシューマは、プロバイダに予め登録を行っておくものとする。そして、ユーザは、コンシューマに対してプロバイダに蓄積されている自身のデータへのアクセス権を取得するように指示する（ステップ（１））。そうすると、コンシューマは、プロバイダに対してアクセスし（ステップ（２））、プロバイダから未認可のリクエストトークンＲ０を取得する（ステップ（３））。その後、コンシューマは、ユーザをプロバイダにリダイレクトさせる（ステップ（４））。この際、コンシューマは、未認可のリクエストトークンＲ０をＵＲＬ（Uniform Resource Locator）パラメータに付加して、未認可のリクエストトークンＲ０がプロバイダにユーザ経由で送信されるようにする。プロバイダは、ユーザからのアクセスに応じて、コンシューマによるプロバイダへのアクセス権の取得を認可するように求めるデータをユーザに対して送信する（ステップ（５））。これに対してユーザは、コンシューマによるアクセス権の取得を許可する旨の通知をプロバイダに送信する（ステップ（６））。そうすると、プロバイダは、未認可のリクエストトークンＲ０を認可済みのリクエストトークンＲ１に変化させ、ユーザをコンシューマにリダイレクトさせる（ステップ（７））。この際、プロバイダは、認可済みのリクエストトークンＲ１をＵＲＬパラメータに付加し、認可済みのリクエストトークンＲ１がユーザ経由でコンシューマに送信されるようにする。

その後、コンシューマは、認可済みのリクエストトークンＲ１をプロバイダに送信し（ステップ（８））、プロバイダからアクセストークンＡを取得する（ステップ（９））。そして、このアクセストークンＡを利用してユーザのデータをプロバイダから取得する（ステップ（１０））。

一般的に、コンシューマもプロバイダも複数存在しており、各組み合わせについて上で述べた処理を行うことになる。また、アクセス権には有効期間があるため、有効期間が終われば同様の処理を実施することになる。これはユーザにとって煩雑である。

なお、ＯｐｅｎＩＤという認証機構において中間認証サーバを導入して、本人性の確認を担保するという従来技術があるが、このような技術を用いても上で述べたような問題は解決しない。また、代理認証という技術も存在している。例えば代理認証装置は、クライアントからの要求に応じて、ネットワークを介して接続されるサーバにアクセスする。この代理認証装置には、ユーザ認証が未完了であることを示す応答を識別するための複数の認証許否確認論理が予め定義されている。そして、代理認証装置は、サーバからの応答が複数の認証許否確認論理のいずれかに適合するか否かに基づきユーザ認証の要否を判断する。ユーザ認証が要と判断された場合、代理認証装置は、サーバからの応答が適合する認証許否確認論理に対応付けて予め定義されている認証手順に従って、サーバとの間でユーザ認証手続きを代理で行う。このような技術は上で述べたＯＡｕｔｈのような状況を前提としておらず、単純には適用できない。

特開２００９−２８２５６１号公報 特開２００５−１１０９８号公報

従って、本技術の目的は、一側面においては、第１の装置に蓄積されているユーザのデータへのアクセス権を第２の装置に与えることを認可する際のユーザ操作を簡便化するための技術を提供することである。

本仲介処理方法は、ユーザのデータを保持する第１の装置と当該第１の装置からユーザのデータを取得して利用する第２の装置とユーザの端末とのそれぞれと通信を行う仲介装置により実行される。そして、（Ａ）ユーザの識別子と、第２の装置の識別子とを、ユーザの端末から取得し、データ格納部に格納するステップと、（Ｂ）第２の装置にアクセスし、第２の装置から第１の装置が発行し且つ第２の装置によるユーザのデータの利用が未認可であることを表す第１のデータと第１の装置の識別子とを含む第１の応答を受信した場合、データ格納部に格納されているユーザの識別子及び第２の装置の識別子と第１の装置の識別子との組み合わせが、第１の装置に対する自動応答のためのデータを格納する自動応答データ格納部に格納されているか確認するステップと、（Ｃ）上記組み合わせが自動応答データ格納部に格納されていない場合には、第１の応答をユーザの端末に送信し、ユーザの端末に仲介装置を経由して第１の装置との間で第２の装置に対する利用認可のためのトランザクションを実施させ、当該トランザクションについてのデータをデータ格納部に格納する記録ステップと、（Ｄ）第１の装置から第２の装置によるユーザのデータの利用が認可済みであることを表す第２のデータを含む応答を受信した場合、データ格納部に格納されているトランザクションについてのデータから生成される照合データ及び返信データを、ユーザの識別子と第２の装置の識別子と第１の装置の識別子とに対応付けて自動応答データ格納部に格納するステップとを含む。

図１は、ＯＡｕｔｈの処理の概要を示す図である。 図２は、実施の形態に係るシステムの概要図である。 図３は、仲介装置の機能ブロック図である。 図４は、実施の形態におけるシステムの動作を説明するための処理フローを示す図である。 図５は、実施の形態におけるシステムの動作を説明するための処理フローを示す図である。 図６は、自動応答ＤＢに格納されるデータの一例を示す図である。 図７は、実施の形態におけるシステムの動作を説明するための処理フローを示す図である。 図８は、認可要求ページの一例を示す図である。 図９は、実施の形態におけるシステムの動作を説明するための処理フローを示す図である。 図１０は、認可要求ページデータの一例を示す図である。 図１１は、回答データの一例を示す図である。 図１２は、照合データの一例を示す図である。 図１３は、実施の形態におけるシステムの動作を説明するための処理フローを示す図である。 図１４は、実施の形態におけるシステムの動作を説明するための処理フローを示す図である。 図１５は、応答データの一例を示す図である。 図１６は、生成される回答データの一例を示す図である。 図１７は、実施の形態におけるシステムの動作を説明するための処理フローを示す図である。 図１８は、実施の形態におけるシステムの動作を説明するための処理フローを示す図である。 図１９は、コンピュータの機能ブロック図である。

図２に、本技術の実施の形態に係るシステムの概要を示す。例えば、インターネットなどのネットワーク１には、ＯＡｕｔｈにおけるプロバイダとして動作する１又は複数のプロバイダ装置７と、ＯＡｕｔｈにおけるコンシューマとして動作する１又は複数のコンシューマ装置９と、Ｗｅｂブラウザが実行されているパーソナルコンピュータなどの１又は複数のユーザ端末３と、本実施の形態において主要な処理を行う仲介装置５とが接続されている。

プロバイダ装置７にはユーザ端末３のユーザのデータが保持されており、コンシューマ装置９は、ユーザ端末３のユーザが利用を欲するサービスが提供されているものとする。プロバイダ装置７は、従来のＯＡｕｔｈに基づく動作を行う装置である。一方、コンシューマ装置９は、基本的にはＯＡｕｔｈに基づく動作を行う装置ではあるが、仲介装置５を利用するために一部的に変更された動作を行う。ユーザ端末３は、上でも述べたように例えば通常のＷｅｂブラウザを実行している通常のパーソナルコンピュータでよい。

図３に、仲介装置５の機能ブロック図を示す。仲介装置５は、中継処理部５１と、データ格納部５２と、自動応答データベース（ＤＢ）５３とを有する。中継処理部５１は、ユーザ端末３とコンシューマ装置９との間の通信を仲介する処理、ユーザ端末３とプロバイダ装置７との間の通信を仲介する処理を実施する。そして中継処理部５１は、特に後者の処理について記録処理部５１１を有している。記録処理部５１１は、データ格納部５２を用いて応答処理部５１２のためのデータを生成して自動応答ＤＢ５３に登録する。さらに、中継処理部５１は、プロバイダ装置７に対してコンシューマ装置９へのアクセス権の認可のための操作をユーザに代わって自動的に行うための応答処理部５１２をも有する。応答処理部５１２は、プロバイダ装置７からのデータを受信すると自動応答ＤＢ５３に格納されているデータを用いてユーザ端末３に代わってプロバイダ装置７へ送信データを送信する。

次に、図４乃至図１８を用いて、図２に示したシステムの動作について説明する。前提として、シングルサインオンなどの技術によってユーザ端末３のユーザは、コンシューマ装置９、プロバイダ装置７及び仲介装置５に対して既にログインされている状態であるものとする。このような前提がない場合においても、初めてアクセスする場合にはユーザＩＤ及びパスワードなどによってログインするものとする。

まず、ユーザは、ユーザ端末３を操作して、コンシューマ装置９に対して、プロバイダ装置７に蓄積されている、ユーザの特定のデータを利用した特定のサービスの実行を要求するリクエストを送信させる（ステップＳ１）。コンシューマ装置９は、ユーザ端末３から、プロバイダ装置７に蓄積されている、ユーザの特定のデータを利用した特定のサービスの実行を要求するリクエストを受信すると（ステップＳ３）、仲介装置５へアクセスさせるようなリダイレクトのための応答を、ユーザ端末３に返信する（ステップＳ５）。

ユーザ端末３は、コンシューマ装置９から、仲介装置５へアクセスさせるようなリダイレクトのための応答を受信すると、そのまま仲介装置５へアクセスする（ステップＳ７）。このリダイレクトによるアクセスでは、仲介装置５へユーザＩＤ及びコンシューマ装置９のＦＱＤＮ（Fully Qualified Domain Name）（ＦＱＤＮではなく他の識別子であってもよい）を送信するようになっている。

仲介装置５の中継処理部５１は、ユーザ端末３からユーザＩＤ及びリダイレクト元のコンシューマ装置９のＦＱＤＮを受信し、データ格納部５２に格納する（ステップＳ９）。そして、中継処理部５１は、リダイレクト元のコンシューマ装置９のＦＱＤＮ等からコンシューマ装置９の所定のアクセス先を特定し、アクセスする（ステップＳ１１）。これによって、特定のサービスの要求元が仲介装置５になる。

コンシューマ装置９は、仲介装置５からのアクセスに応じて、予めプロバイダ装置７から取得済みのコンシューマキー等を含む、リクエストトークンの要求を、プロバイダ装置７に送信する（ステップＳ１３）。仲介装置５からのアクセスに応じて行われる点を除き、本ステップは従来と同じであるからこれ以上述べない。プロバイダ装置７は、コンシューマ装置９からリクエストトークンの要求を受信すると（ステップＳ１５）、未認可のリクエストトークンをコンシューマ装置９へ送信する（ステップＳ１７）。このステップについても従来と同じであるからこれ以上述べない。コンシューマ装置９は、プロバイダ装置７から未認可のリクエストトークンを受信する（ステップＳ１９）。このステップについても従来と同じであるからこれ以上述べない。処理は端子Ａを介して図５の処理に移行する。

図５の処理の説明に移行して、コンシューマ装置９は、プロバイダ装置７へリダイレクトさせる、未認可のリクエストトークン付きの応答を、仲介装置５へ返信する（ステップＳ２１）。この応答にはプロバイダ装置７のＦＱＤＮ（ＦＱＤＮではなく他の識別子であってもよい）が含まれている。仲介装置５の中継処理部５１は、コンシューマ装置９から、プロバイダ装置７へリダイレクトさせる、未認可リクエストトークン付きの応答を受信する（ステップＳ２３）。この応答にはプロバイダ装置７のＦＱＤＮが含まれるので、仲介装置５の中継処理部５１は、受信した応答に応じて、自動応答ＤＢ５３に、データ格納部５２に格納されているユーザＩＤ及びコンシューマ装置９のＦＱＤＮとプロバイダ装置７のＦＱＤＮの組み合わせが登録済みであるか確認する（ステップＳ２５）。該当するレコードが存在する場合には読み出す。

自動応答ＤＢ５３は、例えば図６に示すようなデータを格納している。図６の例では、ユーザＩＤと、コンシューマ装置９のＦＱＤＮと、プロバイダ装置７のＦＱＤＮと、プロバイダ装置７から受信する応答のデータから生成される照合データとプロバイダ装置７へ送信するデータから生成される返信データとの１又は複数の組み合わせとを登録するようになっている。ユーザＩＤとコンシューマ装置９のＦＱＤＮとプロバイダ装置７のＦＱＤＮとがキーとなっている。なお、図６のデータフォーマットは一例であって、照合データと返信データの組み合わせ毎に１レコード生成し、順番を示すデータを各レコードに付加しておくような構成であってもよい。

ユーザＩＤとコンシューマ装置９のＦＱＤＮとプロバイダ装置７のＦＱＤＮとの組み合わせについてのレコードが自動応答ＤＢ５３に登録されている場合には（ステップＳ２７：Ｙｅｓルート）、端子Ｂを介して図１４の処理に移行する。端子Ｂ以降の処理は、自動応答時の処理である。

ユーザＩＤとコンシューマ装置９のＦＱＤＮとプロバイダ装置７のＦＱＤＮとの組み合わせについてのレコードが自動応答ＤＢ５３に登録されていない場合には（ステップＳ２７：Ｎｏルート）、仲介装置５の中継処理部５１は、プロバイダ装置７のＦＱＤＮを、ユーザＩＤ及びコンシューマ装置９のＦＱＤＮに対応付けて格納する（ステップＳ２９）。これ以降の処理で、ユーザ端末３とプロバイダ装置７との間のトランザクションについてのデータを収集する。

そして、仲介装置５の記録処理部５１１は、コンシューマ装置９から受信した応答のリダイレクト先を仲介装置５に変更した上で、当該仲介装置５へリダイレクトさせる、未認可のリクエストトークン付きの応答を、ユーザ端末３に送信する（ステップＳ３１）。ユーザ端末３は、未認可のリクエストトークン付きの応答を仲介装置５から受信すると（ステップＳ３３）、リダイレクトの指示に応じて、仲介装置５へ、受信した未承認のリクエストトークンを伴う要求を送信する（ステップＳ３５）。仲介装置５の記録処理部５１１は、ユーザ端末３から、未認可のリクエストトークンを伴う要求を受信する（ステップＳ３７）。処理は端子Ｃを介して図７の処理に移行する。

図７の処理の説明に移行して、記録処理部５１１は、未認可のリクエストトークンを伴う要求を、プロバイダ装置７へ転送する（ステップＳ３９）。プロバイダ装置７は、仲介装置５から未認可のリクエストトークンを伴う要求を受信すると（ステップＳ４１）、コンシューマ装置９へのアクセス権の認可を求める認可要求ページデータを仲介装置５へ送信する（ステップＳ４３）。仲介装置５の記録処理部５１１は、認可要求ページデータを受信し、ユーザＩＤとプロバイダ装置７のＦＱＤＮとコンシューマ装置９のＦＱＤＮに対応付けてデータ格納部５２に格納する（ステップＳ４５）。

また、記録処理部５１１は、受信した認可要求ページデータをユーザ端末３に転送する（ステップＳ４７）。ユーザ端末３は、仲介装置５から、認可要求ページデータを受信し、表示装置に表示する（ステップＳ４９）。例えば図８に示すような表示が表示装置になされる。図８の例では、コンシューマがＸＸＸというデータへアクセスを要求している旨のメッセージと、アクセス権の有効期限と、承認ボタンと、拒否ボタンとが表示されるようになっている。ユーザは、承認ボタン又は拒否ボタンをクリックする。通常であれば、承認ボタンをクリックすることになる。なお、本実施の形態では、前提としてシングルサインオンなどの技術によってプロバイダ装置７へのログインは省略できることになっているが、そのような技術を用いていない場合には、プロバイダ装置７へ例えばユーザＩＤ及びパスワードでログインすることになる。さらに、図８の例では１画面で承認又は拒否を完了させるような画面例を示しているが、複数画面に渡って承認又は拒否を入力させるようにする場合もある。

ユーザ端末３は、ユーザからのクリックに応じて回答、すなわち承認又は拒否を表すデータを仲介装置５へ送信する（ステップＳ５１）。仲介装置５の記録処理部５１１は、ユーザ端末３から回答を受信し、回答についてのデータを、ユーザＩＤとプロバイダ装置７のＦＱＤＮとコンシューマ装置９のＦＱＤＮとに対応付けてデータ格納部５２に格納する（ステップＳ５３）。そして、仲介装置５の記録処理部５１１は、受信した返信をプロバイダ装置７へ転送する（ステップＳ５５）。プロバイダ装置７は、仲介装置５から返信を受信する（ステップＳ５７）。処理は端子Ｄ及びＥを介して図９の処理に移行する。

図９の処理の説明に移行して、ステップＳ５５の後に、仲介装置５の記録処理部５１１は、ステップＳ４５で受信した認可要求ページデータとステップＳ５３で受信した回答のデータから、自動応答ＤＢ５３に登録するための返信データ及び照合データを生成し、ユーザＩＤとプロバイダ装置７のＦＱＤＮとコンシューマ装置９のＦＱＤＮに対応付けてデータ格納部５２に格納する（ステップＳ５９）。

この処理については、図１０乃至図１２を用いて説明する。図８に示したような認可要求ページデータの場合、図１０に示すようなタグのデータが含まれる。すなわち、＜ｆｏｒｍ＞タグと＜／ｆｏｒｍ＞タグとの間に、承認や拒否といった回答に関係するタグが含まれる。一方、承認ボタンをクリックすると、回答のデータとして、図１１に示すようなデータをボディに有するＨＴＴＰ（Hyper Text Transfer Protocol）のＰＯＳＴメッセージが送信される。図１１に示すように、リクエストパラメータのキーとその値との組み合わせが「＆」で連結された形になっている。リクエストパラメータのキーａｐｐｒｏｖｅ、ｈｉｄｄｅｎ＿ｋｅｙ１及びｈｉｄｄｅｎ＿ｋｅｙ２は、図１０では、＜ｉｎｐｕｔ＞タグ内の属性ｎａｍｅの値となっている。また、リクエストパラメータのキーの値には、同一の＜ｉｎｐｕｔ＞タグ内の属性ｖａｌｕｅの値が設定されている。具体的には、リクエストパラメータのキーａｐｐｒｏｖｅについては、属性ｎａｍｅ＝”ａｐｐｒｏｖｅ”と同一＜ｉｎｐｕｔ＞タグの属性ｖａｌｕｅの値「承認」が設定されている。また、リクエストパラメータのキーｈｉｄｄｅｎ＿ｋｅｙ１については、属性ｎａｍｅ＝”ｈｉｄｄｅｎ＿ｋｅｙ１”と同一＜ｉｎｐｕｔ＞タグの属性ｖａｌｕｅの値「ｈｉｄｄｅｎ＿ｖａｌ１」が設定されている。さらに、リクエストパラメータのキーｈｉｄｄｅｎ＿ｋｅｙ２については、属性ｎａｍｅ＝”ｈｉｄｄｅｎ＿ｋｅｙ２”と同一＜ｉｎｐｕｔ＞タグの属性ｖａｌｕｅの値「ｈｉｄｄｅｎ＿ｖａｌ２」が設定されている。

このように、回答のデータに関連する、認可要求ページデータの部分を抽出することで、実質的に同一の認可要求ページデータが送られてきているかを確認するための照合データを生成することにする。なお、認可要求ページデータには、複数の＜ｆｏｒｍ＞タグが含まれる可能性があり、そのためどの＜ｆｏｒｍ＞タグであるかを特定するために、＜ｆｏｒｍ＞タグの属性ｉｄやｎａｍｅ及びその値、そして回答のデータの送信先を表す属性ａｃｔｉｏｎ及びその値をも抽出する。ｍｅｔｈｏｄについても、ＰＯＳＴ又はＧＥＴの可能性があるので、抽出しておく。

但し、認可要求ページデータを送る毎又はある期間経過すると変化する可能性があるデータについては照合データには含めない。例えば、＜ｉｎｐｕｔ＞タグにおける属性ｖａｌｕｅの値は変更される可能性があるので、照合データには属性ｖａｌｕｅ及びその値は含めない。このような抽出処理には、よく知られている構文解析が用いられる。

例えば、図１０の例の場合、図１２に示すようなデータを抽出して、照合データとして生成し、データ格納部５２に格納する。図１２の例では、先頭が＜ｆｏｒｍ＞タグ内のキーとなる属性及びその値であり、以下３行が、回答のデータで用いられる部分である。

一方、回答のデータからは、リクエストパラメータのキーを抽出する。すなわち、ａｐｐｒｏｖｅ、ｈｉｄｄｅｎ＿ｋｅｙ１及びｈｉｄｄｅｎ＿ｋｅｙ２を抽出することで、返信データを生成する。リクエストパラメータのキーの値は変化しうるため、返信データには含めない。

なお、この他の形式のＷｅｂページデータの場合には、その形式に合わせて照合データ及び返信データを抽出する。例えば、背景技術の欄で説明したような技術や特開２００６−１０７００７号公報に示されているような技術を用いて、手順に合わせて照合データ及び返信データを抽出する。

図９の処理の説明に戻って、プロバイダ装置７は、次の応答のデータを仲介装置５へ送信する（ステップＳ６１）。仲介装置５の記録処理部５１１は、次の応答のデータを受信し（ステップＳ６３）、認可済みリクエストトークンが付いているかを確認する（ステップＳ６５）。認可済みリクエストトークンが付いてきたということは、コンシューマ装置９へのアクセス権認可について本人意思確認がプロバイダ装置７によって完了したことを意味する。従って、ステップＳ６９に移行して、記録処理部５１１の処理を終了させるようになる。なお、この場合、プロバイダ装置７から受信した応答は、コンシューマ装置９へリダイレクトさせる、認可済みリクエストトークン付きの応答である。

一方、受信した応答に認可済みリクエストトークンが付いていない場合には、記録処理部５１１は、まだ次の手順が存在するということで、受信した応答データを、データ格納部５２に格納し（ステップＳ６７）、端子Ｈを介してステップＳ４７に戻る。すなわち、次の手順における照合データ及び返信データの生成を行う。

なお、ユーザが図８の画面において「拒否」を選択したり、その他のエラーが発生した場合には、認可済みのリクエストトークンを受信しないで仲介装置５とプロバイダ装置７との間のトランザクションが終わってしまう場合もある。その場合には、データ格納部５２には、ユーザＩＤとプロバイダ装置７のＦＱＤＮとコンシューマ装置９のＦＱＤＮとの組み合わせとそれに対応付けて格納されている照合データ及び返信データやトランザクションについてのデータが、自動応答ＤＢ５３に登録されずに残ってしまう。このような場合には、最初又は最後にデータを格納してから所定時間を経過してもデータ格納部５２に残っているデータについては破棄させることで、正常終了していないトランザクションについてのデータを破棄するものとする。

認可済みのリクエストトークン付きの応答を受信した場合には、記録処理部５１１は、コンシューマ装置９へリダイレクトさせる、認可済みリクエストトークン付き応答を、宛先をユーザ端末３に変更した上で転送する（ステップＳ６９）。ユーザ端末３は、コンシューマ装置９へリダイレクトさせる、認可済みのリクエストトークン付きの応答を受信する（ステップＳ７１）。ユーザ端末３の処理は端子Ｊを介して図１３の処理に移行する。

一方、仲介装置５の記録処理部５１１は、ユーザＩＤとプロバイダ装置７のＦＱＤＮとコンシューマ装置９のＦＱＤＮとの組み合わせに対応付けて、データ格納部５２に格納されている照合データと返信データとの組み合わせを、自動応答ＤＢ５３に登録する（ステップＳ７３）。このように、ユーザ端末３とプロバイダ装置７とのトランザクションが正常に完了したことを確認した上で、自動応答ＤＢ５３にデータを書き込むので、自動応答ＤＢ５３に適切なデータが蓄えられるようになる。

図１３の処理の説明に移行して、ユーザ端末３は、リダイレクトにより、認可済みのリクエストトークン付きの要求をコンシューマ装置９へ送信する（ステップＳ７５）。そして、コンシューマ装置９は、ユーザ端末３から認可済みのリクエストトークン付きの要求を受信する（ステップＳ７７）。これによって、コンシューマ装置９は、認可済みのリクエストトークンを取得できたことになる。図示していないが、この後、コンシューマ装置９は、特定のサービス実行の指示についての応答をユーザ端末へ返すこともあるが、この点については本実施の形態の主要ではないのでこれ以上述べない。

その後、コンシューマ装置９は、認可済みのリクエストトークン等を含む、アクセストークンの取得要求を、プロバイダ装置７に送信する（ステップＳ８３）。プロバイダ装置７は、コンシューマ装置９から認可済みのリクエストトークン等を含む、アクセストークンの取得要求を受信すると（ステップＳ８５）、認可済みのリクエストトークン等を確認の上、問題がなければアクセストークンをコンシューマ装置９へ送信する（ステップＳ８７）。コンシューマ装置９は、プロバイダ装置７からアクセストークンを受信する（ステップＳ８９）。以下は、従来と同じであるから説明を省略する。

以上述べたような処理を行うことで、自動応答のためのデータが自動応答ＤＢ５３に登録されたことになる。

次に、図１４乃至図１８を用いて、図５のステップＳ２７で、ユーザＩＤとプロバイダ装置７のＦＱＤＮとコンシューマ装置９のＦＱＤＮとの組み合わせが登録済みであると判断された場合について説明する。上でも述べたように、ユーザＩＤとプロバイダ装置７のＦＱＤＮとコンシューマ装置９のＦＱＤＮとの組み合わせに対応付けられている照合データ及び返信データについては自動応答ＤＢ５３から読み出しておく。

仲介装置５の応答処理部５１２は、ステップＳ２３で受信した未認可リクエストトークンを伴う要求をプロバイダ装置７に送信する（ステップＳ９１）。プロバイダ装置７は、未認可リクエストトークンを伴う要求を仲介装置５から受信すると（ステップＳ９３）、予め定められた処理を実施して応答データを送信する（ステップＳ９５）。仲介装置５の応答処理部５１２は、プロバイダ装置７から応答データを受信し、例えばメインメモリなどの記憶装置に格納する（ステップＳ９７）。そして、応答処理部５１２は、受信した応答データが、自動応答ＤＢ５３から読み出された照合データに適合するか確認する（ステップＳ９９）。具体的には、照合データに含まれるキーとなる属性及び属性名（図１２の第１行目）が含まれる＜ｆｏｒｍ＞タグを含んでいるか確認した上で、当該＜ｆｏｒｍ＞タグと対応する＜／ｆｏｒｍ＞タグの間に、照合すべき＜ｉｎｐｕｔ＞タグ（図１２の第２行目乃至第４行目）が含まれているか確認する。両方の条件を満たす場合には、適合していると判断される。なお、複数回ステップＳ９９が実施される場合もあるので、自動応答ＤＢ５３に登録されている順番（順番が付いている場合には順番に従い、順番が付いていない場合には並び順）で照合データ及び返信データを用いる。

応答データが照合データに適合しない場合には（ステップＳ１０１：Ｎｏルート）、端子Ｆを介して図１８の処理に移行する。一方、応答データが照合データに適合している場合には（ステップＳ１０１：Ｙｅｓルート）、応答処理部５１２は、読み出した返信データと受信した応答データとから回答のデータを生成し、プロバイダ装置７に送信する（ステップＳ１０３）。具体的には、返信データには、照合データで特定される＜ｉｎｐｕｔ＞タグにおける属性ｎａｍｅの属性値がリクエストパラメータのキーとして含まれているので、応答データにおいて同一の＜ｉｎｐｕｔ＞タグにおける属性ｖａｌｕｅの属性値を読み出して、「＝」でつなぐ。リクエストパラメータのキーが返信データに複数含まれている場合には、それらを「＆」でつないで、ＨＴＴＰのＰＯＳＴメッセージのボディに配置する。送信先は、＜ｆｏｒｍ＞タグの属性ａｃｔｉｏｎの属性値を用いる。

なお、登録時には図１０に示したような応答データ（上で述べた認可要求ページデータ）であったが、図１５のような応答データを受信した場合でも、上で述べたような処理を実施すれば、図１６に示すような回答のデータを生成することができる。すなわち、＜ｉｎｐｕｔ＞タグの属性ｎａｍｅがａｐｐｒｏｖｅであって、属性ｖａｌｕｅの属性値が「承認」ではなく「許可」であるので、ａｐｐｒｏｖｅ＝許可となる。また、＜ｉｎｐｕｔ＞タグの属性ｎａｍｅがｈｉｄｄｅｎ＿ｋｅｙ１であって、属性ｖａｌｕｅの属性値が「ｈｉｄｄｅｎ＿ｖａｌ１」ではなく「ｓｅｃｒｅｔ＿ｖａｌ１」であるので、ｈｉｄｄｅｎ＿ｋｅｙ１＝ｓｅｃｒｅｔ＿ｖａｌ１となる。さらに、＜ｉｎｐｕｔ＞タグの属性ｎａｍｅがｈｉｄｄｅｎ＿ｋｅｙ２であって、属性ｖａｌｕｅの属性値が「ｈｉｄｄｅｎ＿ｖａｌ２」ではなく「ｓｅｃｒｅｔ＿ｖａｌ２」であるので、ｈｉｄｄｅｎ＿ｋｅｙ２＝ｓｅｃｒｅｔ＿ｖａｌ２となる。それらが「＆」で連結されている。

このように返信データと応答データから今回の応答データに適した回答のデータを生成することができる。

プロバイダ装置７は、仲介装置５から回答データを受信し（ステップＳ１０５）、予め定められた処理を実施して、次の応答データを生成して、仲介装置５へ送信する（ステップＳ１０７）。仲介装置５の応答処理部５１２は、プロバイダ装置７から次の応答データを受信し（ステップＳ１０９）、次の応答データに認可済みリクエストトークンが付いているか判断する（ステップＳ１１１）。認可済みリクエストトークンが付いていない場合には（ステップＳ１１１：Ｎｏルート）、次の順番の照合データ及び返信データについてステップＳ９９に戻る。

一方、次の応答データに認可済みリクエストトークンが付いてきた場合には（ステップＳ１１１：Ｙｅｓルート）、コンシューマ装置９に対するアクセス権の認可の手続きが成功裏に完了したということであるから、端子Ｇを介して図１７の処理に移行する。なお、コンシューマ装置９へリダイレクトさせる、認可済みリクエストトークン付きの応答が受信されたことになる。

図１７の処理の説明に移行して、仲介装置５の応答処理部５１２は、コンシューマ装置９へリダイレクトさせる、認可済みリクエストトークン付きの応答をユーザ端末３へ転送する（ステップＳ１１３）。ユーザ端末３は、認可済みリクエストトークン付きの応答を、仲介装置５から受信すると（ステップＳ１１５）、リダイレクトの指示に応じて、認可済みリクエストトークン付きの要求をコンシューマ装置９へ送信する（ステップＳ１１７）。コンシューマ装置９は、ユーザ端末３から、認可済みリクエストトークン付きの要求を受信する（ステップＳ１１９）。以降の処理は、図１３のステップＳ８３以降の処理と同じであるから、説明を省略する。

このようにすればユーザは、仲介装置５に操作を行わせたことになるので、簡単にアクセス権の認可をコンシューマ装置９に対して行うことができるようになる。

一方、図１４のステップＳ１０１で、応答データが照合データに適合しないと判断された場合の処理について図１８を用いて説明する。仲介装置５の応答処理部５１２は、ユーザＩＤとプロバイダ装置７のＦＱＤＮとコンシューマ装置９のＦＱＤＮとの組み合わせを含むデータを自動応答ＤＢ５３において削除する（ステップＳ１２１）。これは、アクセス権認可の意思確認手順が大幅に変更されたと判断されるので、以後、変更前のデータを使用することはないので削除するものである。そして、応答処理部５１２は、ユーザ端末３にエラー発生を通知する（ステップＳ１２３）。ユーザ端末３は、仲介装置５からエラー発生通知を受信し、表示装置に表示する（ステップＳ１２５）。このような処理を実施することによって、ユーザは、仲介装置５に登録した自動応答のためのデータが無効になったことを認識できるので、手順を最初からやり直すことになる。また、コンシューマ装置９及びプロバイダ装置７は、処理の途中で放置されることになるが、一般的にはタイムアウトするので、特に問題は発生しない。

以上本技術の実施の形態を説明したが、本技術はこれに限定されるものではない。例えば、図３に示した機能ブロック図は一例であって、必ずしも実際のプログラムモジュール構成と一致するわけではない。

また、上で述べた処理の処理フローについても、結果が変わらない限り、処理順番を入れ替えたり、並列実行するようにしても良い。

なお、上で述べた仲介装置５、コンシューマ装置９及びプロバイダ装置７は、コンピュータ装置であって、図１９に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた本実施の形態をまとめると、以下のようになる。

本実施の形態に係る仲介処理方法は、ユーザのデータを保持する第１の装置（例えばプロバイダ装置）と当該第１の装置からユーザのデータを取得して利用する第２の装置（例えばコンシューマ装置）とユーザの端末とのそれぞれと通信を行う仲介装置により実行される。そして、（Ａ）ユーザの識別子と、第２の装置の識別子とを、ユーザの端末から取得し、データ格納部に格納するステップと、（Ｂ）第２の装置にアクセスし、第２の装置から第１の装置が発行し且つ第２の装置によるユーザのデータの利用が未認可であることを表す第１のデータ（例えば未認可リクエストトークン）と第１の装置の識別子とを含む第１の応答を受信した場合、データ格納部に格納されているユーザの識別子及び第２の装置の識別子と第１の装置の識別子との組み合わせが、第１の装置に対する自動応答のためのデータを格納する自動応答データ格納部（例えば自動応答ＤＢ）に格納されているか確認するステップと、（Ｃ）上記組み合わせが自動応答データ格納部に格納されていない場合には、第１の応答をユーザの端末に送信し、ユーザの端末に仲介装置を経由して第１の装置との間で第２の装置に対する利用認可のためのトランザクションを実施させ、当該トランザクションについてのデータをデータ格納部に格納する記録ステップと、（Ｄ）第１の装置から第２の装置によるユーザのデータの利用が認可済みであることを表す第２のデータ（例えば認可済みリクエストトークン）を含む応答を受信した場合、データ格納部に格納されているトランザクションについてのデータから生成される照合データ及び返信データを、ユーザの識別子と第２の装置の識別子と第１の装置の識別子とに対応付けて自動応答データ格納部に格納するステップとを含む。

このようにすれば、第１のデータの受信且つキーとなるデータが自動応答データ格納部に未登録であるという適切なタイミングでトランザクションについてのデータを蓄積し始める。また、第２のデータの受信という適切なタイミングで、自動応答に用いる照合データ及び返信データを自動応答データ格納部に登録する。これによって、適切なデータが自動応答データ格納部に登録されるので、ユーザは次回以降同じ操作を行わずに済み、ユーザの操作が簡便になる。

なお、本実施の形態に係る仲介処理方法は、（Ｅ）データ格納部に格納されているトランザクションについてのデータに含まれており且つユーザの端末から受信した第３のデータからリクエストパラメータのキー（又は引数の要素）を抽出することにより返信データを生成するステップと、（Ｆ）返信データに含まれるリクエストパラメータのキーを属性値として含む部分を、トランザクションについてのデータに含まれており且つ第１の装置から第１のデータの直前に受信した第４のデータから抽出することにより照合データを生成するステップとをさらに含むようにしても良い。

このようにすれば、自動応答時に、実質的に同一の応答を特定できる照合データが生成され、また受信した応答から適切な回答データを自動生成できる返信データが生成される。

また、本実施の形態に係る仲介処理方法は、（Ｇ）上記組み合わせが自動応答データ格納部に格納されている場合には、自動応答データ格納部から、ユーザの識別子及び第２の装置の識別子と第１の装置の識別子との組み合わせに対応付けて格納されている照合データ及び返信データを読み出すステップと、第１の応答を第１の装置に送信し、当該第１の装置から第２の応答を受信する受信ステップと、（Ｈ）第２の応答が、読み出された照合データを含んでいるか判断する判断ステップと、（Ｉ）第２の応答が照合データを含んでいる場合には、第２の応答と返信データとから回答データを生成し、第１の装置に送信する送信ステップとをさらに含むようにしてもよい。この場合、受信ステップと判断ステップと送信ステップとを、判断ステップにおいて肯定的な判断がなされ且つ第１の装置から第２のデータを受信するまで繰り返すようにしてもよい。このようにすれば、自動応答データ格納部に蓄積したデータを有効活用して、ユーザ操作を簡便化することができる。

本実施の形態に係るシステムは、（Ａ）ユーザのデータを保持する第１の装置からユーザのデータを取得して利用する第２の装置と、（Ｂ）ユーザの端末と、（Ｃ）ユーザの端末と第１の装置と第２の装置とのそれぞれと通信を行う仲介装置とを有する。そして、第２の装置は、ユーザの端末からの要求に応じて、ユーザの端末に対して、第２の装置の識別子を含み、仲介装置へアクセスさせるための第１の応答を送信する。

また、仲介装置は、（Ａ）ユーザの識別子と第２の装置の識別子とを、ユーザの端末から受信し、データ格納部に格納し、その後、第２の装置にアクセスし、第２の装置から第１の装置が発行し且つ第２の装置によるユーザのデータの利用が未認可であることを表す第１のデータと第１の装置の識別子とを含む第２の応答を受信した場合、データ格納部に格納されているユーザの識別子及び第２の装置の識別子と第１の装置の識別子との組み合わせが、第１の装置に対する自動応答のためのデータを格納する自動応答データ格納部に格納されているか確認する中継処理部と、（Ｂ）上記組み合わせが自動応答データ格納部に格納されていない場合には、第２の応答をユーザの端末に送信し、ユーザの端末に仲介装置を経由して第１の装置との間で第２の装置に対する利用認可のためのトランザクションを実施させ、当該トランザクションについてのデータをデータ格納部に格納し、第１の装置から第２の装置によるユーザのデータの利用が認可済みであることを表す第２のデータを含む第３の応答を受信した場合、ユーザの識別子と第２の装置の識別子と第１の装置の識別子とに対応付けてデータ格納部に格納されているトランザクションについてのデータから生成される照合データ及び返信データを自動応答データ格納部に格納する記録処理部とを有する。

なお、上で述べたような処理をコンピュータに実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭなどの光ディスク、光磁気ディスク、半導体メモリ（例えばＲＯＭ）、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、ＲＡＭ等の記憶装置に一時保管される。

Claims (9)

1. ユーザのデータを保持する第１の装置と当該第１の装置から前記ユーザのデータを取得して利用する第２の装置と前記ユーザの端末とのそれぞれと通信を行う仲介装置により実行される仲介処理方法であって、
   前記ユーザの識別子と、前記第２の装置の識別子とを、前記ユーザの端末から取得し、データ格納部に格納するステップと、
   前記第２の装置にアクセスし、前記第２の装置から前記第１の装置が発行し且つ前記第２の装置による前記ユーザのデータの利用が未認可であることを表す第１のデータと前記第１の装置の識別子とを含む第１の応答を受信した場合、前記データ格納部に格納されている前記ユーザの識別子及び前記第２の装置の識別子と前記第１の装置の識別子との組み合わせが、前記第１の装置に対する自動応答のためのデータを格納する自動応答データ格納部に格納されているか確認するステップと、
   前記組み合わせが前記自動応答データ格納部に格納されていない場合には、前記第１の応答を前記ユーザの端末に送信し、前記ユーザの端末に前記仲介装置を経由して前記第１の装置との間で前記第２の装置に対する利用認可のためのトランザクションを実施させ、当該トランザクションについてのデータを前記データ格納部に格納する記録ステップと、
   前記第１の装置から前記第２の装置による前記ユーザのデータの利用が認可済みであることを表す第２のデータを含む応答を受信した場合、前記データ格納部に格納されている前記トランザクションについてのデータから生成される照合データ及び返信データを、前記ユーザの識別子と前記第２の装置の識別子と前記第１の装置の識別子とに対応付けて前記自動応答データ格納部に格納するステップと、
   を含む仲介処理方法。
2. 前記データ格納部に格納されている前記トランザクションについてのデータに含まれており且つ前記ユーザの端末から受信した第３のデータからリクエストパラメータのキーを抽出することにより前記返信データを生成するステップと、
   前記返信データに含まれる前記リクエストパラメータのキーを所定の属性の属性値として含む部分を、前記トランザクションについてのデータに含まれており且つ前記第１の装置から前記第１のデータの直前に受信した第４のデータから抽出することにより前記照合データを生成するステップと、
   をさらに含む請求項１記載の仲介処理方法。
3. 前記組み合わせが前記自動応答データ格納部に格納されている場合には、前記自動応答データ格納部から、前記ユーザの識別子及び前記第２の装置の識別子と前記第１の装置の識別子との組み合わせに対応付けて格納されている前記照合データ及び前記返信データを読み出すステップと、
   前記第１の応答を前記第１の装置に送信し、当該第１の装置から第２の応答を受信する受信ステップと、
   前記第２の応答が、読み出された前記照合データを含んでいるか判断する判断ステップと、
   前記第２の応答が前記照合データを含んでいる場合には、前記第２の応答と前記返信データとから回答データを生成し、前記第１の装置に送信する送信ステップと、
   をさらに含み、
   前記受信ステップと前記判断ステップを、前記判断ステップにおいて肯定的な判断がなされ且つ前記第１の装置から前記第２のデータを受信するまで繰り返す
   請求項１又は２記載の仲介処理方法。
4. ユーザのデータを保持する第１の装置に対する自動応答のためのデータを格納する自動応答データ格納部と、
   ユーザの識別子と、前記第１の装置が保持する前記ユーザのデータを利用する第２の装置の識別子とを、前記ユーザの端末から取得し、データ格納部に格納し、その後、前記第２の装置にアクセスし、前記第２の装置から前記第１の装置が発行し且つ前記第２の装置による前記ユーザのデータの利用が未認可であることを表す第１のデータと前記第１の装置の識別子とを含む第１の応答を受信した場合、前記データ格納部に格納されている前記ユーザの識別子及び前記第２の装置の識別子と前記第１の装置の識別子との組み合わせが、前記自動応答データ格納部に格納されているか確認する中継処理部と、
   前記組み合わせが前記自動応答データ格納部に格納されていない場合には、前記第１の応答を前記ユーザの端末に送信し、前記ユーザの端末に前記仲介装置を経由して前記第１の装置との間で前記第２の装置に対する利用認可のためのトランザクションを実施させ、当該トランザクションについてのデータを前記データ格納部に格納し、前記第１の装置から前記第２の装置による前記ユーザのデータの利用が認可済みであることを表す第２のデータを含む第２の応答を受信した場合、前記ユーザの識別子と前記第２の装置の識別子と前記第１の装置の識別子とに対応付けて前記データ格納部に格納されている前記トランザクションについてのデータから生成される照合データ及び返信データを前記自動応答データ格納部に格納する記録処理部と、
   を有する仲介装置。
5. 前記記録処理部が、
   前記データ格納部に格納されている前記トランザクションについてのデータに含まれており且つ前記ユーザの端末から受信した第３のデータからリクエストパラメータのキーを抽出することにより前記返信データを生成し、
   前記返信データに含まれる前記リクエストパラメータのキーを所定の属性の属性値として含む部分を、前記トランザクションについてのデータに含まれており且つ前記第１の装置から前記第１のデータの直前に受信した第４のデータから抽出することにより前記照合データを生成する
   請求項４記載の仲介装置。
6. 前記組み合わせが前記自動応答データ格納部に格納されている場合には、前記自動応答データ格納部から、前記ユーザの識別子及び前記第２の装置の識別子と前記第１の装置の識別子との組み合わせに対応付けて格納されている前記照合データ及び前記返信データを読み出し、前記第１の応答を前記第１の装置に送信し、当該第１の装置から第３の応答を受信する受信処理と、前記第３の応答が、読み出された前記照合データを含んでいるか判断する判断処理と、前記第３の応答が前記照合データを含んでいる場合には、前記第３の応答と前記返信データとから回答データを生成し、前記第１の装置に送信する送信処理とを実施する応答処理部
   をさらに有し、
   前記受信処理と前記判断処理を、前記判断処理において肯定的な判断がなされ且つ前記第１の装置から前記第２のデータを受信するまで繰り返す
   請求項４又は５記載の仲介装置。
7. ユーザのデータを保持する第１の装置から前記ユーザのデータを取得して利用する第２の装置と、
   前記ユーザの端末と、
   前記ユーザの端末と前記第１の装置と前記第２の装置とのそれぞれと通信を行う仲介装置と、
   を有し、
   前記第２の装置は、
   前記ユーザの端末からの要求に応じて、前記ユーザの端末に対して、前記第２の装置の識別子を含み、前記仲介装置へアクセスさせるための第１の応答を送信し、
   前記仲介装置は、
   前記ユーザの識別子と前記第２の装置の識別子とを、前記ユーザの端末から受信し、データ格納部に格納し、その後、前記第２の装置にアクセスし、前記第２の装置から前記第１の装置が発行し且つ前記第２の装置による前記ユーザのデータの利用が未認可であることを表す第１のデータと前記第１の装置の識別子とを含む第２の応答を受信した場合、前記データ格納部に格納されている前記ユーザの識別子及び前記第２の装置の識別子と前記第１の装置の識別子との組み合わせが、前記第１の装置に対する自動応答のためのデータを格納する自動応答データ格納部に格納されているか確認する中継処理部と、
   前記組み合わせが前記自動応答データ格納部に格納されていない場合には、前記第２の応答を前記ユーザの端末に送信し、前記ユーザの端末に前記仲介装置を経由して前記第１の装置との間で前記第２の装置に対する利用認可のためのトランザクションを実施させ、当該トランザクションについてのデータを前記データ格納部に格納し、前記第１の装置から前記第２の装置による前記ユーザのデータの利用が認可済みであることを表す第２のデータを含む第３の応答を受信した場合、前記ユーザの識別子と前記第２の装置の識別子と前記第１の装置の識別子とに対応付けて前記データ格納部に格納されている前記トランザクションについてのデータから生成される照合データ及び返信データを前記自動応答データ格納部に格納する記録処理部と、
   を有する
   ことを特徴とするシステム。
8. 前記記録処理部が、
   前記データ格納部に格納されている前記トランザクションについてのデータに含まれており且つ前記ユーザの端末から受信した第３のデータからリクエストパラメータのキーを抽出することにより前記返信データを生成し、
   前記返信データに含まれる前記リクエストパラメータのキーを所定の属性の属性値として含む部分を、前記トランザクションについてのデータに含まれており且つ前記第１の装置から前記第１のデータの直前に受信した第４のデータから抽出することにより前記照合データを生成する
   請求項７記載のシステム。
9. 前記仲介装置が、
   前記組み合わせが前記自動応答データ格納部に格納されている場合には、前記自動応答データ格納部から、前記ユーザの識別子及び前記第２の装置の識別子と前記第１の装置の識別子との組み合わせに対応付けて格納されている前記照合データ及び前記返信データを読み出し、前記第２の応答を前記第１の装置に送信し、当該第１の装置から第４の応答を受信する受信処理と、前記第４の応答が、読み出された前記照合データを含んでいるか判断する判断処理と、前記第４の応答が前記照合データを含んでいる場合には、前記第４の応答と前記返信データとから回答データを生成し、前記第１の装置に送信する送信処理とを実施する応答処理部
   をさらに有し、
   前記受信処理と前記判断処理を、前記判断処理において肯定的な判断がなされ且つ前記第１の装置から前記第２のデータを受信するまで繰り返す
   請求項７又は８記載のシステム。

Images