JP2020035079A - システム、及びデータ処理方法 - Google Patents

Abstract

【課題】ストリーム受信サービスにおいて、データの送信元の特定を可能とする。【解決手段】認証認可サーバーは、クライアント端末からの要求に応じてクライアント端末を識別する情報を対応付けて第１のトークンを発行する。リソースサーバーは、クライアント端末から受信した第１のトークンを検証し、検証結果に応じて、ストリーム受信システムへアクセスするための第２のトークンを、クライアント端末へ提供する。クライアント端末は、第２のトークンを用いて、ストリーム受信システムにて保持させるデータに第１のトークンを含めて送信する。リソースサーバーは、ストリーム受信システムからデータを取得した際に、データに含まれる第１のトークンに対応付けられた情報に基づき、データの送信元であるクライアント端末を特定する。【選択図】図６

Description

本発明は、システム、及びデータ処理方法に関する。

近年、所謂クラウドサービスは個々にＷｅｂサービスのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を公開しており、他のアプリケーションからＡＰＩを介してサービスが提供する機能を利用する事が可能となっている。ＷｅｂサービスＡＰＩにて利用可能な認可に関する標準プロトロルであるＯＡｕｔｈ２．０によれば、例えば、あるサービスＡが管理するデータを取得するＡＰＩに対して、アプリケーションＢからのアクセスを認可する事ができる。アプリケーションＢは、アプリケーションＢである事を認証するための情報を用いてサービスＡのＡＰＩへのアクセス認可を得るためのトークン（以下、アクセストークンと称する）を受け取る事ができる。以降のサービスＡのＡＰＩへのアクセスはそのアクセストークンを用いて実現できる。

また、近年多くの機器がインターネットにつながり、機器の制御や様々なデータを送信するＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）が広く一般に浸透し始めている。オフィス環境でも画像形成装置などの多くの機器が稼働し、クラウドサービスにデータを送信するようになっている。このように多くの機器からデータをリアルタイムに受信するようなストリーミング処理では、刻一刻と変動する膨大なトラフィックが発生する。このようなトラックのデータを受信するサーバーは従来型のＡＰＩを備えたリソースサーバーでは対応しきれず、ストリーム専用のデータ受信サービス（以下、ストリーム受信サービス）を利用するのが一般的である。ＩｏＴ機器はそのストリーム受信サービスへデータを送信する。そして、ストリーム受信サービスはデータをバッファリングし、リソースサービスからのデータ受信要求に対してバッファリングしたデータを供給する。

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

ストリーム受信サービスは通常のリソースサービスとは異なる認証・認可基盤を利用した独立のサービスである。そのため、リソースサービスは、ストリーム受信サービスから取得したデータをどのクライアント端末が投入したものなのか識別することができない。クライアントの識別を行うためには、例えば、リソースサービスのＡＰＩを呼び出すために利用するアクセストークンが必要である。アクセストークンをデータと一緒にストリーム受信サービスに送信することでリソースサービスは、ストリーム受信サービスから取得したデータがどのクライアント端末のものか検証可能となる。この際、ストリーム受信サービスは受信したデータをバッファリングしており、リソースサービスがアクセストークンを取得するまでに時間がかかる。そのため、リソースサービスがアクセストークンを取得したタイミングではすでにアクセストークンの有効期限が切れてしまう場合がある。例えば、特許文献１では、トークンの有効期限をリソースに応じて変更する技術が開示されている。しかし、有効期限が無駄に長くなり、アクセストークンのセキュリティが低下してしまう。

本発明は、ストリーム受信サービス経由でデータを取得する際に、データの送信元を特定することを可能とする。

上記課題を解決するために本発明は以下の構成を有する。すなわち、クライアント端末、認証認可サーバー、ストリーム受信システム、及び、リソースサーバーを含むシステムであって、前記認証認可サーバーは、前記クライアント端末からの要求に応じて、当該クライアント端末を識別する情報を対応付けて第１のトークンを発行する発行手段を有し、前記リソースサーバーは、前記クライアント端末から受信した前記第１のトークンの検証を行う検証手段と、前記検証手段の検証結果に応じて、前記ストリーム受信システムへアクセスするための第２のトークンを、前記クライアント端末へ提供するための処理を行う提供手段と、前記ストリーム受信システムが保持するデータを取得し、当該データを用いて処理を行う処理手段とを有し、前記クライアント端末は、前記第１のトークンを用いて、前記リソースサーバーに前記第２のトークンの要求を行う要求手段と、前記要求手段の要求の応答として得られた前記第２のトークンを用いて、前記ストリーム受信システムにて保持させるデータを送信する送信手段とを有し、前記クライアント端末の前記送信手段は、前記データの送信を行う際に、前記第１のトークンを含めて送信し、前記リソースサーバーの前記処理手段は、前記ストリーム受信システムからデータを取得した際に、当該データに含まれる前記第１のトークンに対応付けられた前記情報に基づき、当該データの送信元である前記クライアント端末を特定する。

本発明により、ストリーム受信サービスによるリアルタイムデータ受信を行う場合に、データの送信元を特定することが可能となる。

本実施形態に係るシステム構成の例を示す図。 本実施形態に係る各装置のハードウェア構成の例を示す図。 本実施形態に係る各装置のソフトウェアモジュールの構成例を示す図。 本実施形態に係るストリーム受信サーバーへのデータ送信処理のシーケンス図。 本実施形態に係るデータ受信代行サーバー経由でのデータ送信処理のシーケンス図。 本実施形態に係るストリーム受信サーバーから取得したデータの検証処理のシーケンス図。 本実施形態に係るデータの検証処理のフローチャート。 本実施形態に係る管理テーブルの構成例を示す図。

＜第１の実施形態＞
以下、本発明を実施するための形態について図面を用いて説明する。本実施形態においては、インターネット上の各サーバーに後述する各種アプリケーションが設置されていることとする。アプリケーションは、クライアント端末と連携し、様々な機能（サービス）を提供する。

［システム構成］
本実施形態に係る情報処理システムであるデータアクセス管理システムは、図１に示すような構成のネットワーク上に実現される。ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）１００には、本実施形態ではＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）システムが構築されている。ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１０１、１０２、１０３は各構成要素を接続するネットワークである。図１に示す構成例では、ＬＡＮ１０１にクライアント端末１８０、１９０が属する。ＬＡＮ１０２に認証認可サーバー１１０、リソースサーバー１２０、及びデータ受信代行サーバー１３０が属する。ＬＡＮ１０３に認証認可サーバー１５０、及びストリーム受信サーバー１６０が属する。

認証認可サーバー１１０はクライアント端末の認証・認可を行うサーバーであり、リソースサーバー１２０およびデータ受信代行サーバー１３０へのアクセスを制御する。リソースサーバー１２０は、例えば、クライアント端末のデータをバックアップするサービスや、クライアント端末が備えるセンサー（不図示）にて取得したセンサー情報を分析するサービスなど様々なサービスを提供する。認証認可サーバー１５０は、ＬＡＮ１０２に配置された認証認可サーバー１１０とは別のサーバーであり、ストリーム受信サーバー１６０へのアクセスを制御する。ストリーム受信サーバー１６０は、ストリームによるデータ受信を行うサーバーであり、例えば、クライアント端末１８０から送信されるストリームデータを受信する。また、ストリーム受信サーバー１６０は、外部装置からの要求に応じて、受信したデータを提供する。ストリーム受信サーバー１６０と認証認可サーバー１５０をまとめて、ストリーム受信システムとしてもよい。

データ受信代行サーバー１３０は、クライアント端末１８０、１９０がストリーム受信サーバー１６０に直接データを送信できない場合に、データ受信を代行するための代替サーバーである。データ受信代行サーバー１３０は、受信したデータを改めてストリーム受信サーバー１６０に送信（転送）する転送サーバーとしての機能を備える。データ代行サーバー１３０が必要になる状況に関しては後述する。本実施形態において、各サーバーは１台のみを設置した構成を示しているが、複数台で構成されていてもよく、例えば、認証認可サーバーシステムとして提供されてもよい。１のサービスを提供するサーバーを複数設けることで、負荷分散等が行われるような構成であってよい。また、認証認可サーバー１１０、１５０はそれぞれ、上記のサーバーへのアクセスの制御に限定するものではなく、例えば、同じＬＡＮに配置された他のサーバーへのアクセスを制御するようにしてもよい。

クライアント端末１８０、１９０は、サービスを利用するためのパソコン、モバイル端末、画像形成装置などの機器であり、上述したＩｏＴ技術に対応したＩｏＴ機器に相当する。本実施形態では、クライアント端末１８０は、クライアント端末１９０よりも、処理速度や通信機能などの性能が高い機器である場合を想定して説明を行う。

［装置構成］
図２は、本実施形態に係る各サーバーおよびクライアント装置を構成する情報処理装置の一般的なハードウェア構成の例を示す図である。なお、以下に示す構成は一例であり、装置ごとに異なる構成であってもよい。

ＣＰＵ２３１は、ＲＯＭ２３３のプログラム用ＲＯＭに記憶された、或いはハードディスク（ＨＤ）等の外部メモリ２４１からＲＡＭ２３２にロードされたＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やアプリケーション等のプログラムを実行する。また、ＣＰＵ２３１は、システムバス２３４に接続される各ブロックを制御する。後述する各シーケンスの処理はこのプログラムの実行により実現できる。尚、本実施形態に係る後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２３１であり、ソフトウェア上の主体は外部メモリ２４１にインストールされたアプリケーションプログラムであるものとする。

ＲＡＭ２３２は、ＣＰＵ２３１の主メモリ、ワークエリア等として機能する揮発性の記憶領域である。ＲＯＭ２３３は、フォントＲＯＭ、プログラムＲＯＭ、及びデータＲＯＭを含んで構成される不揮発性の記憶領域である。操作部Ｉ／Ｆ２３５は、操作部２３９からの入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２３６は、ＣＲＴディスプレイ２４０の表示を制御する。ディスクコントローラ（ＤＫＣ）２３７は各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２４１におけるデータアクセスを制御する。ネットワークコントローラ（ＮＣ）２３８は、ＷＡＮ１００もしくはＬＡＮ１０１、１０２、１０３を介して接続されたサーバーや他の機器との通信制御処理を実行する。各構成要素は、システムバス２３４を介して互いに通信可能に接続される。

［ソフトウェア構成］
図３は、本実施の形態に係る各装置のモジュール（ソフトウェア）構成の例を示す図である。各々のモジュールが実行されることで、各装置が提供する機能を実現する。ここでは、本実施形態に係るモジュール構成のみを示しており、他のモジュールを含んで構成されてもよい。上述したように、本実施形態では、各モジュールに対応するプログラムが各装置のＣＰＵにより読み出されて実行されることで動作する。

認証認可サーバー１１０は、認証認可モジュール３１０、及びクライアント管理モジュール３１１を含んで構成される。認証認可モジュール３１０は、クライアント端末の認証処理、認証されたクライアント端末の認可処理を行う。クライアント管理モジュール３１１は、クライアントを管理し、クライアントのＩＤ（識別情報）やシークレット（認証用文字列）を管理する。ここでのクライアントとは、クライアント端末を操作するユーザーを意味するものとして説明するが、これに限定するものではない。

リソースサーバー１２０は、リソースサーバーモジュール３２０を含んで構成される。リソースサーバーモジュール３２０は、ストリーム受信サーバー１５０よりデータを受信して、そのデータを機器毎に保管する等、データを使って様々な機能を実現する。また、リソースサーバーモジュール３２０は、ＷｅｂサービスとしてＡＰＩを公開し、クライアント端末１８０からのサービス提供の要求を受け付け、その応答としてサービスの提供を行う。

クライアント端末１８０は、トークンプロバイダー３８１、及びデータ送信アプリケーション３８２を含んで構成される。トークンプロバイダー３８１は、認証認可サーバー１１０に対して、クライアントの認証の要求、アクセストークンの発行依頼や取得を行う。データ送信アプリケーション３８２は、リソースサーバー１２０で提供されるサービスを利用したり、クライアント端末１８０のデータをストリーム受信サーバー１６０に送信したりする。

クライアント端末１９０は、トークンプロバイダー３９１、及びデータ送信アプリケーション３９２を含んで構成される。トークンプロバイダー３９１は、認証認可サーバー１１０に対して、クライアントの認証の要求、アクセストークンの発行依頼や取得を行う。データ送信アプリケーション３９２は、リソースサーバー１２０で提供されるサービスを利用したり、クライアント端末１９０のデータをデータ受信代行サーバー１３０に送信したりする。

認証認可サーバー１１０は、図８（ａ）に示すように、クライアントを一意に識別するクライアントＩＤとクライアントを認証するための公開鍵、及び、クライアント端末を一意に識別するためのデバイスシリアル（識別情報）を対応付けて管理している。ここでは、クライアントＩＤ”ｃｌｉｅｎｔ１”はクライアント端末１８０のユーザーを示し、クライアント端末１８０のデバイスシリアルは”１２３４５６７８９”とする。同様に、クライアントＩＤ”ｃｌｉｅｎｔ２”はクライアント端末１９０のユーザーを示し、クライアント端末１９０のデバイスシリアルは”９８７６５４３２１”とする。認証認可モジュール３１０は、クライアントＩＤと公開鍵を元に各クライアント端末を認証し、クライアント端末それぞれのデバイスシリアルを特定することができる。

クライアント端末１８０のトークンプロバイダー３８１や、クライアント端末１９０のトークンプロバイダー３８２は図８（ｂ）に示すように、自端末用のクライアントＩＤと秘密鍵を保持している。図８（ａ）は、クライアント端末１８０にて保持されているテーブルの内容を示す。また、図８（ａ）の１レコード目に示す公開鍵と図８（ｂ）の秘密鍵は対である。

本実施形態では、クライアントＩＤと対となる鍵を用いた認証を前提として説明するが、前述の通り認証方式は特に問わず、クライアントＩＤとシークレットによる認証といった他の方法でもよい。また、他の認証方法であってもよく、認証方法に応じて、管理される情報が異なる。

また、クライアント端末へのクライアントＩＤと秘密鍵の登録に関し、クライアント端末の利用開始時に動的に登録する方法や、事前に登録しておくといった方法がある。例えば、動的に登録する場合、クライアント端末に秘密の情報を保持させておき、その秘密の情報を認証認可サーバー１１０にリクエストすると、クライアントＩＤに対応付けられる秘密鍵が動的に生成される。クライアント端末はそれぞれ、認証認可サーバー１１０にて生成されたクライアントＩＤと秘密鍵をレスポンスで取得し、クライアント管理テーブルにて管理する。

同様に、認証認可サーバー１５０は図８（ｃ）に示すように、クライアントを一意に識別するクライアントＩＤとクライアントを認証するためのシークレットを管理する。認証認可サーバー１５０の認証認可モジュール３５０は、その情報を元に要求元を認証する。ここでは、クライアントＩＤ”ｃｌｉｅｎｔＡ”はリソースサーバー１２０を示す。同様に、クライアントＩＤ”ｃｌｉｅｎｔＢ”はデータ受信代行サーバー１３０を示す。

リソースサーバー１２０のリソースサーバーモジュール３２０は、図８（ｄ）に示すように、自身のクライアントＩＤとシークレットを対応付けて保持している。図には示していないが、データ受信代行サーバー１３０のデータ受信代行モジュール３３０も同様に、自身のクライアントＩＤとシークレットを対応付けて保持しているものとする。

［処理シーケンス］
図４〜図６を用いて、クライアント端末１８０がストリーム受信サーバー１６０へデータを送信する処理と、リソースサーバー１２０がストリーム受信サーバー１６０からデータを取得して利用するデータ処理の流れを説明する。

（データ送信）
図４は、クライアント端末１８０がストリーム受信サーバー１６０へデータを送信する処理の流れを示す図である。図４において、実線は各種要求を示し、破線は要求に対する応答を示す。

Ｓ４０１にて、クライアント端末１８０のデータ送信アプリケーション３８２は、トークンプロバイダー３８１にトークンの発行要求を行う。

Ｓ４０２にて、トークンプロバイダー３８１は、図８（ｂ）にて管理されているクライアントＩＤと秘密鍵を利用してアサーションを作成し、アサーションとともにトークン発行リクエストを生成する。本実施形態では、アサーションは、ＲＦＣ７５１９にて決められたＪＳＯＮ Ｗｅｂ Ｔｏｋｅｎ（ＪＷＴ）を想定しており、ＪＷＴにはクライアントＩＤなどの情報が含まれる。ここで含まれる情報の詳細に関しては説明を省略する。

Ｓ４０２にて、トークンプロバイダー３８１は、認証認可サーバー１１０の認証認可モジュール３１０にアサーションを送信し、トークン発行要求を行う。トークンプロバイダー３４１からのトークン発行要求を受けた認証認可モジュール３１０は、トークン発行要求してきたクライアントの公開鍵をクライアント管理テーブル（図８（ａ））から取得し、アサーションの署名を検証する。署名の検証において正当なものであると判定された場合、認証認可モジュール３１０は、アクセストークンＡ１を発行し、トークンプロバイダー３８１へ応答として送信する。レスポンスを受信したクライアント端末１８０のトークンプロバイダー３８１は、アクセストークンＡ１をデータ送信アプリケーション３８２へ送信する。ここで生成されたアクセストークンＡ１は、認証認可サーバー１１０によりアクセス制御されている、リソースサーバー１２０およびデータ受信代行サーバー１３０へのアクセスをするためのものである。ここでは、リソースサーバー１２０にアクセスする際に用いられる場合を例に挙げて説明する。また、本実施形態では、アクセストークンはＪＷＴを想定しており、クライアントＩＤやクライアント端末１８０のデバイスシリアルといった情報、およびトークンの有効期限などが含まれる。

Ｓ４０３にて、データ送信アプリケーション３８２は、アクセストークンＡ１を利用してＩＤトークン発行要求をリソースサーバー１２０のリソースサーバーモジュール３２０に送信する。

Ｓ４０４にて、リソースサーバーモジュール３２０は、クライアント端末１８０から受信したアクセストークンＡ１の検証を行う。リソースサーバーモジュール３２０は、認証認可モジュール３１０が発行したＪＷＴを検証するための公開鍵を保持しており、ＪＷＴを検証することでクライアントの認可を行う。図４には示していないが、認証認可モジュール３１０が発行した公開鍵は、ＪＷＴの検証前にリソースサーバー１２０に提供され、適時更新されているものとする。ＪＷＴの検証では、ＪＷＴの署名が正当なものであるかが公開鍵を用いて検証され、さらにＪＷＴの有効期間中であるかが検証される。また、アクセストークンＡ１を検証した結果、クライアント情報を取得することが可能であり、アクセス元のクライアント端末１８０をデバイスシリアルで識別できる。なお、検証の方法は上記に限定するものではなく、リソースサーバーモジュール３２０は、クライアント端末から受信したアクセストークンの検証を認証認可モジュール３１０に依頼し、検証結果とクライアント情報を取得するといった別の構成であってもよい。検証の結果、受信したアクセストークンが正当なものであった場合、リソースサーバーモジュール３２０は、Ｓ４０５、Ｓ４０６にて、受信したリクエストに対する処理を行う。

Ｓ４０５にて、リソースサーバーモジュール３２０は、認証認可サーバー１５０の認証認可モジュール３５０にトークン発行要求を行う。本トークン発行要求では、図８（ｄ）に示すクライアントＩＤとシークレットとともに要求を送信する。トークン発行要求を受けた認証認可モジュール３５０は、図８（ｃ）で管理しているクライアントＩＤ及びシークレットの組と、要求に含まれるクライアントＩＤ及びシークレットの組とを比較する。そして、これらが一致する場合に、認証認可モジュール３５０は、アクセストークンＢを発行し、要求元のリソースサーバー１２０へ応答する。ここで発行されるアクセストークンＢは、認証認可サーバー１５０へアクセスするためのものである。

Ｓ４０６にて、アクセストークンＢを取得したリソースサーバーモジュール３２０は、認証認可モジュール３５０に対してＩＤトークン発行要求を行う。ＩＤトークン発行要求では、アクセストークンＢと、Ｓ４０４における検証結果から取得したクライアント端末１８０のクライアントＩＤが送信される。認証認可モジュール３５０は、受信したクライアントＩＤ用のＩＤトークンを発行する。発行されたＩＤトークンは、リソースサーバー１２０を介してクライアント端末１８０へ送信される。

ＩＤトークンとは、クライアント端末１８０を確かに認証したことを証明するためのトークンである。本実施形態では、クライアント端末１８０の認証は、Ｓ４０４にてリソースサーバーモジュール３２０がアクセストークンＡ１を検証することで確認している。認証認可モジュール３５０は、リソースサーバーモジュール３２０に対して自身のクライアントＩＤとシークレットを提供する形で信頼関係を結んでおり、リソースサーバーモジュール３２０がクライアント端末１８０を認証した結果を信頼する。認証認可モジュール３５０は、その信頼に基づいて、ＩＤトークンを発行する構成となる。本実施形態において、ＩＤトークンは、ＪＷＴ形式を想定しており、認証認可サーバーモジュール３５０は署名を検証することでＩＤトークンを検証可能である。

Ｓ４０７にて、ＩＤトークンを受信したクライアント端末１８０のデータ送信アプリケーション３８２は、認証認可サーバー１５０の認証認可モジュール３５０にトークン発行要求を行う。このトークン発行要求には、認証認可サーバー１５０にて発行されたＩＤトークンを含める。要求を受けた認証認可モジュール３５０は、トークン発行要求に含まれるＩＤトークンの検証を行う。検証により正当なＩＤトークンであると判定された場合、認証認可モジュール３５０は、アクセストークンＣを発行し、クライアント端末１８０へ応答する。ここで発行されたアクセストークンＣは、認証認可サーバー１５０によりアクセス制御されているストリーム受信サーバー１６０へアクセスするためのものである。

Ｓ４０８にて、アクセストークンＣを受信したクライアント端末１８０のデータ送信アプリケーション３８２は、ストリーム受信サーバー１６０のストリーム受信モジュール３６０にデータ送信を行う。ここでのデータ送信では、アクセストークンＣ、及び、アクセストークンＡ１とデータのペアを送信する。データ送信要求を受信したストリーム受信モジュール３６０は、アクセストークンＣを検証し正当なものであると判定された場合、アクセストークンＡ１とデータのペアを保持する。以上により、クライアント端末１８０からのストリーム受信サーバー１６０へのデータ送信が完了する。

（データ送信：データ受信代行サーバー利用時）
一方、図４の処理では、クライアント端末１８０は、認証認可サーバー１１０とリソースサーバー１２０だけではなく、認証認可サーバー１５０とストリーム受信サーバー１６０の両方にアクセスする必要がある。そのため、クライアント端末は、複数の認証認可方式や通信方式に対応する必要があり高いスペックが要求される。よって、スペックが低いクライアント端末では、図４の処理によりデータ送信が実現できない場合がある。

図５は、スペックの低いクライアント端末１９０を想定したデータ送信の流れを説明する図である。ここでは、スペックの低いクライアント端末１９０のために、データ受信代行サーバー１３０を用いる点が図４のシーケンスとは異なる。データ受信代行サーバー１３０は、認証認可サーバー１１０によりアクセス制御されており、リソースサーバー１２０と同様の通信方式でＡＰＩを公開している。これにより、クライアント端末１９０はリソースサーバー１２０への利用と同じ方式でデータ送信が実現できる。

なお、本実施形態では、データ受信代行サーバー１３０はリソースサーバー１２０と同様の構成とし、大量のストリームデータを受信する処理には向いていないものとして説明する。そのため、多くのクライアント端末からのデータを受信しようとした場合、ストリーム受信サーバー１６０に比べ、多くのサーバーリソースが必要となり非常にコストがかかる。よって、本実施形態では、ストリーム受信サーバー１６０に直接データを送信できないクライアント端末１９０に限定した処理とする。また、図４のデータ送信が行われるか、図５のデータ送信が行われるかの切り替え方法は特に限定するものではない。例えば、クライアント端末側で送信先（データ受信代行サーバー１３０を利用するか否か）を決定するような構成でもよい。もしくは、認証認可サーバー１１０側で、クライアント端末の機能（スペック）に応じて、送信先を決定するような構成であってもよい。

図５のＳ５０１とＳ５０２は、図４のＳ４０１とＳ４０２と同様の処理である。この工程の結果、クライアント端末１９０は、認証認可サーバー１１０が発行したアクセストークンＡ２を取得する。ここで生成されたアクセストークンＡ２は、認証認可サーバー１１０によりアクセス制御されている、リソースサーバー１２０およびデータ受信代行サーバー１３０へのアクセスをするためのものである。ここでは、データ受信代行サーバー１１０にアクセスする際に用いられる場合を例に挙げて説明する。

Ｓ５０３にて、アクセストークンＡ２を受信したクライアント端末１９０のデータ送信アプリケーション３９２は、データ受信代行サーバー１３０のデータ受信代行モジュール３３０にデータ送信を行う。データ送信では、アクセストークンＡ２とデータが送信される。

Ｓ５０４にて、データ受信代行モジュール３３０は、クライアント端末１９０から受信したアクセストークンＡ２の検証処理を行う。本工程は、図４のＳ４０４と同様の処理である。検証の結果、受信したアクセストークンＡ２が正当なものであると判定された場合、データ受信代行モジュール３３０は、Ｓ５０５、Ｓ５０６の処理を行う。

Ｓ５０５にて、データ受信代行モジュール３３０は、認証認可サーバー１５０の認証認可モジュール３５０にトークン発行要求を行う。本トークン発行要求では、図８（ｄ）に示したような、クライアントＩＤとシークレットとともに要求を送信する。上述したように、データ代行受信サーバー１３０においては、クライアントＩＤ”ｃｌｉｅｎｔＢ”、シークレット”ｓｅｃｒｅｔＢ”の情報が保持されている。トークン発行要求を受けた認証認可モジュール３５０は、図８（ｃ）で管理しているクライアントＩＤ及びシークレットの組と、要求に含まれるクライアントＩＤ及びシークレットの組が一致するか否かを比較する。そして、これらが一致する場合に、認証認可モジュール３５０は、アクセストークンＣを発行し、要求元のデータ受信代行サーバー１３０へ応答する。ここで発行されるアクセストークンＣは、認証認可サーバー１５０によりアクセス制御が行われるストリーム受信サーバー１６０へアクセスするためのものである。

Ｓ５０６にて、アクセストークンＣを受信したデータ受信代行モジュール３３０は、ストリーム受信サーバー１６０のストリーム受信モジュール３６０にデータ送信を行う。ここでのデータ送信では、アクセストークンＣ、及び、アクセストークンＡ２とデータと識別情報のセットを送信する。データ送信要求を受信したストリーム受信モジュール３６０は、アクセストークンＣを検証して正当なものであると判定された場合、アクセストークンＡ２とデータと識別情報のセットを保持する。識別情報とは、データ受信代行サーバー１３０を経由してデータを登録したことを識別するための情報であり、データを利用するリソースサーバー１２０とデータ受信代行サーバー１３０のみが知りえる秘匿情報である。この識別情報の内容は特に限定するものでは無いが、例えば、共通して管理している秘匿情報や、認証情報などが挙げられる。

以上により、クライアント端末１８０よりも低スペックのクライアント端末１９０は、データ受信代行サーバー１３０経由でストリーム受信サーバー１６０へのデータ送信が完了する。本シーケンスにより、クライアント端末１９０は、認証認可サーバー１５０やストリーム受信サーバー１６０に直接アクセスすることなく、データが送信できる。

図４もしくは図５で示したシーケンスが完了した際のストリーム受信サーバー１６０が保持しているデータの一例を図８（ｅ）に示す。ストリーム受信サーバー１６０は、データを一意に識別するＩＤ、データを受信した受信日時、及び、保持データが対応付けて保持される。保持データとしては、実際に送信されてきたアクセストークン、データ、及び、識別情報が１レコードとして管理される。識別情報は、図５の処理シーケンスが行われた場合に保持される。各レコードは、受信日時順にＩＤが発行され、これに従ってソートされる。また、各レコードは、受信後一定時間経過すると自動的に削除される。削除されるまでの時間は、ストリーム受信サーバー１６０側で予め設定されていてもよい。また、リソースサーバー１２０への提供が行われてから、所定の時間が経過後に削除されてもよい。

図８（ｅ）において、ＩＤ“１”〜“３”は、クライアント端末１８０が送信したデータであり、図４の処理で送信されたものである。保持データには、その際に受信したアクセストークンＡ１とデータが含まれる。ＩＤ“４”〜“６”は、クライアント端末１９０が送信したデータであり、図５の処理で送信されたものである。保持データにはその際に受信したアクセストークンＡ２、データ、及び識別情報が含まれる。

（データ処理）
図６は、リソースサーバー１２０がストリーム受信サーバー１６０からデータを取得し、取得したデータを処理する処理のシーケンス図である。

Ｓ６０１にて、リソースサーバー１２０のリソースサーバーモジュール３２０は、認証認可サーバー１５０に対してトークン発行要求を行い、アクセストークンＢを取得する。本処理は図４のＳ４０５と同様である。本工程により、リソースサーバー１２０は、ストリーム受信サーバー１６０にアクセスするためのアクセストークンＢを取得する。

Ｓ６０２にて、アクセストークンＢを取得したリソースサーバーモジュール３２０は、ストリーム受信サーバー１６０のストリーム受信モジュール３６０にデータ受信を要求する。ここでのデータ受信要求には、アクセストークンＢが含まれる。データ受信要求を受けたストリーム受信モジュール３６０は、アクセストークンＢを検証して正当なものであると判定された場合、図８（ｅ）に示すデータ保持テーブルにて管理している、受信日時の古いレコードから順に、リソースサーバー１２０に対して応答する。ここでの応答には、保持データと受信日時が含まれる。

Ｓ６０３にて、リソースサーバーモジュール３２０は、ストリーム受信サーバー１６０から受信したデータの検証を行う。本工程におけるデータ検証の詳細フローについては、図７を用いて後述する。そして、本処理シーケンスを終了する。

（データ検証）
図７は、本実施形態に係るリソースサーバー１２０がストリーム受信サーバー１６０から取得したデータに対する検証処理のフローチャートである。本処理フローは、リソースサーバー１２０のＣＰＵが、リソースサーバーモジュール３２０のプログラムを読み出して実行することにより実現される。

Ｓ７０１にて、リソースサーバーモジュール３２０は、取得したデータに識別情報が含まれるか否かを判定する。識別情報が含まれる場合には、データ受信代行サーバー１３０にてアクセストークンの検証がすでに行われているため（図５のＳ５０４）、アクセストークンの検証が省略（スキップ）可能である。言い換えると、識別情報が含まれる場合は図５のシーケンスが行われており、含まれない場合は図４のシーケンスが行われている。識別情報が含まれると判定された場合（Ｓ７０１にてＹＥＳ）Ｓ７０６へ進み、含まれないと判定された場合（Ｓ７０１にてＮＯ）Ｓ７０２へ進む。

Ｓ７０２にて、リソースサーバーモジュール３０２は、アクセストークンＡ１の署名検証を行う。本工程は、図４のＳ４０４と同様の処理であり、この工程が行われる場合は図４のシーケンスが行われているため、本例においては、アクセストークンＡ１が検証対象となる。

Ｓ７０３にて、リソースサーバーモジュール３０２は、Ｓ７０２の署名検証の結果、アクセストークンＡ１の署名が正当なものであるか否かを判定する。正当なものであると判定された場合（Ｓ７０３にてＹＥＳ）Ｓ７０４へ進み、正当なものでないと判定された場合（Ｓ７０３にてＮＯ）Ｓ７０７へ進む。

Ｓ７０４にて、リソースサーバーモジュール３０２は、アクセストークンＡ１の有効期限をチェックする。この時、リソースサーバーモジュール３０２は、ストリーム受信サーバー１６０がデータを受信した受信日時の時点でアクセストークンＡ１が有効であるか否かを判定する。これは、ストリーム受信サーバー１６０がデータを受信してから、リソースサーバー１２０がデータを受信するまでに時間差があるためである。つまり、ストリーム受信サーバー１６０が管理テーブルにて保持している「受信日時」の情報に基づいて有効期限のチェックが行われる。もし、通常の検証時と同様に、現在時刻とアクセストークンＡの有効期限との比較によりチェックを行った場合、受信時には有効であったはずのアクセストークンＡが検証時にすでに有効期限が切れてしまうことが発生するためである。

Ｓ７０５にて、リソースサーバーモジュール３０２は、Ｓ７０４のチェックの結果、アクセストークンＡ１が有効期限内であるか否かを判定する。有効期限内であると判定された場合は（Ｓ７０５にてＹＥＳ）Ｓ７０６へ進み、有効期限を過ぎていると判定された場合は（Ｓ７０５にてＮＯ）Ｓ７０７へ進む。

Ｓ７０６にて、リソースサーバーモジュール３０２は、アクセストークンＡ１もしくはアクセストークンＡ２からクライアント情報としてデバイスシリアルを取得する。本例の場合、アクセストークンＡ１からはクライアント端末１８０のデバイスシリアルが取得され、アクセストークンＡ２からはクライアント端末１９０のデバイスシリアルが取得される。そして、本処理フローを終了する。

Ｓ７０７にて、リソースサーバーモジュール３０２は、アクセストークンの署名が無効である、もしくは、有効期限が切れているものとして、エラー処理を行う。ここでのエラー処理は特に限定するものではないが、例えば、エラーに関する通知を行うなどの処理が行われる。そして、本処理フローを終了する。

以上、本処理フローにより、アクセストークンとともに保持されていたデータがどのデバイスから送信されたかを特定でき、データの送信デバイスを特定した上で利用できるようになる。なお、上記の処理では、アクセストークンが正当なものでは無い場合、クライアント情報の取得（Ｓ７０６）を行わないような構成としたが、これに限定するものではない。例えば、アクセストークンが正当なものでは無いと判定された場合でも、クライアント情報を取得し、そのクライアント情報を正当でないアクセストークンの送信元として管理、利用するような構成であってもよい。

以上、本実施形態により、クライアント端末がストリーム受信サーバーに対して送信したデータをリソースサーバーは、その送信元を特定することができる。これらの情報に基づいて、更なる処理を行うことが可能となる。また、アクセストークンの有効期限に対して、無駄に長い値の設定を行う必要がない。

＜その他の実施形態＞
本発明は上述の実施形態の１以上の機能を実現するプログラムをネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１１０…認証認可サーバー、１２０…リソースサーバー、１３０…データ受信代行サーバー、１５０…認証認可サーバー、１６０…ストリーム受信サーバー、１８０…クライアント端末、１９０…クライアント端末

Claims (9)

1. クライアント端末、認証認可サーバー、ストリーム受信システム、及び、リソースサーバーを含むシステムであって、
   前記認証認可サーバーは、前記クライアント端末からの要求に応じて、当該クライアント端末を識別する情報を対応付けて第１のトークンを発行する発行手段を有し、
   前記リソースサーバーは、
   前記クライアント端末から受信した前記第１のトークンの検証を行う検証手段と、
   前記検証手段の検証結果に応じて、前記ストリーム受信システムへアクセスするための第２のトークンを、前記クライアント端末へ提供するための処理を行う提供手段と、
   前記ストリーム受信システムが保持するデータを取得し、当該データを用いて処理を行う処理手段と
   を有し、
   前記クライアント端末は、
   前記第１のトークンを用いて、前記リソースサーバーに前記第２のトークンの要求を行う要求手段と、
   前記要求手段の要求の応答として得られた前記第２のトークンを用いて、前記ストリーム受信システムにて保持させるデータを送信する送信手段と
   を有し、
   前記クライアント端末の前記送信手段は、前記データの送信を行う際に、前記第１のトークンを含めて送信し、
   前記リソースサーバーの前記処理手段は、前記ストリーム受信システムからデータを取得した際に、当該データに含まれる前記第１のトークンに対応付けられた前記情報に基づき、当該データの送信元である前記クライアント端末を特定することを特徴とするシステム。
2. 前記リソースサーバーの前記処理手段は、前記ストリーム受信システムからデータを取得する際に、当該データが前記ストリーム受信システムにて保持を開始された日時の情報を併せて取得し、当該取得した日時の情報と、当該データに含まれる前記第１のトークンの有効期限とを比較することで、前記第１のトークンが有効か否かを判定することを特徴とする請求項１に記載のシステム。
3. 前記システムは更に、前記ストリーム受信システムへデータの転送を行う転送サーバーを含んで構成され、
   前記転送サーバーは、
   前記クライアント端末から前記第１のトークンを含むデータを受信した際に、当該第１のトークンの検証を行う第２の検証手段と、
   前記第２の検証手段の検証結果に応じて、前記第１のトークンを含む前記データを前記ストリーム受信システムに送信する転送手段と
   を有することを特徴とする請求項１または２に記載のシステム。
4. 前記転送サーバーの前記転送手段は、前記データを送信する際に、前記転送サーバーを介して前記データが転送されたことを示す識別情報を含め、
   前記リソースサーバーの前記処理手段は、前記ストリーム受信システムから取得したデータに前記識別情報が含まれている場合、当該データに含まれる前記第１のトークンの検証が行われているものとして、検証処理をスキップすることを特徴とする請求項３に記載のシステム。
5. クライアント端末、認証認可サーバー、ストリーム受信システム、リソースサーバー、及び、転送サーバーを含むシステムであって、
   前記認証認可サーバーは、前記クライアント端末からの要求に応じて、当該クライアント端末を識別する情報を対応付けて第１のトークンを発行する発行手段を有し、
   前記クライアント端末は、前記ストリーム受信システムにて保持させるデータを、前記第１のトークンを含めて前記転送サーバーに送信する送信手段を有し、
   前記転送サーバーは、
   前記クライアント端末から、前記第１のトークンを含むデータを受信した際に、当該第１のトークンの検証を行う検証手段と、
   前記検証手段の検証結果に応じて、前記第１のトークンを含む前記データを前記ストリーム受信システムに送信する転送手段と
   を有し、
   前記リソースサーバーは、前記ストリーム受信システムからデータを取得した際に、当該データに含まれる前記第１のトークンに対応付けられた前記情報に基づいて、当該データの送信元である前記クライアント端末を特定する処理手段を有する
   ことを特徴とするシステム。
6. 前記リソースサーバーの前記処理手段は、前記ストリーム受信システムからデータを取得する際に、当該データが前記ストリーム受信システムにて保持を開始された日時の情報を併せて取得し、当該取得した日時の情報と、当該データに含まれる前記第１のトークンの有効期限とを比較することで、前記第１のトークンが有効か否かを判定することを特徴とする請求項５に記載のシステム。
7. 前記転送サーバーの前記転送手段は、前記データを送信する際に、前記転送サーバーを介して前記データが転送されたことを示す識別情報を含め、
   前記リソースサーバーの前記処理手段は、前記ストリーム受信システムから取得したデータに、前記識別情報が含まれている場合、当該データに含まれる前記第１のトークンの検証が行われているものとして、検証処理をスキップすることを特徴とする請求項５または６に記載のシステム。
8. クライアント端末、認証認可サーバー、ストリーム受信システム、及び、リソースサーバーを含むシステムにおけるデータ処理方法であって、
   前記認証認可サーバーにより、前記クライアント端末からの要求に応じて、当該クライアント端末を識別する情報を対応付けて第１のトークンを発行し、
   前記リソースサーバーにより、前記クライアント端末から受信した前記第１のトークンの検証を行い、
   前記リソースサーバーにより、前記第１のトークンの検証結果に応じて、前記ストリーム受信システムへアクセスするための第２のトークンを、前記クライアント端末へ提供するための処理を行い、
   前記クライアント端末により、前記第１のトークンを用いて、前記リソースサーバーに前記第２のトークンの要求を行い、
   前記クライアント端末により、前記第２のトークンの要求の応答として得られた前記第２のトークンを用いて、前記ストリーム受信システムにて保持させる前記第１のトークンを含むデータを送信し、
   前記リソースサーバーにより、前記ストリーム受信システムが保持するデータを取得し、当該データを用いて処理を行い、
   前記リソースサーバーにより、前記ストリーム受信システムからデータを取得した際に、当該データに含まれる前記第１のトークンに対応付けられた前記情報に基づき、当該データの送信元である前記クライアント端末が特定されることを特徴とするデータ処理方法。
9. クライアント端末、認証認可サーバー、ストリーム受信システム、リソースサーバー、及び、転送サーバーを含むシステムにおけるデータ処理方法であって、
   前記認証認可サーバーにより、前記クライアント端末からの要求に応じて、当該クライアント端末を識別する情報を対応付けて第１のトークンを発行し、
   前記クライアント端末により、前記ストリーム受信システムにて保持させるデータを、前記第１のトークンを含めて前記転送サーバーに送信し、
   前記転送サーバーにより、前記クライアント端末から、前記第１のトークンを含むデータを受信した際に、当該第１のトークンの検証を行い、
   前記転送サーバーにより、前記第１のトークンの検証結果に応じて、前記第１のトークンを含む前記データを前記ストリーム受信システムに送信し、
   前記リソースサーバーにより、前記ストリーム受信システムからデータを取得した際に、当該データに含まれる前記第１のトークンに対応付けられた前記情報に基づいて、当該データの送信元である前記クライアント端末を特定する
   ことを特徴とするデータ処理方法。

Images