JP6871956B2 - 情報処理装置およびクライアントアプリケーションのテスト方法、プログラム - Google Patents

Description

本発明は、一以上のクライアントアプリケーションの通信テストを行う情報処理装置およびクライアントアプリケーションのテスト方法、プログラムに関する。

クラウドサービスは、一般的にＷｅｂサービスのＡＰＩ（Application Programming Interface）を公開しており、端末や他のクラウドサービスからＡＰＩを介してサービスが提供する機能を利用する事ができる。このＡＰＩ利用における認証、認可のプロトコルとして、OAuth2.0と呼ばれる標準プロトコルが策定されている。OAuth2.0では、クライアントとなる端末や他のリソースサーバと認可サーバとが連携することで認証および認可を行う。認証および認可を受けたクライアントは、認可サーバから認可トークンを取得し、その認可トークンを送信することでＡＰＩを利用する。
OAuth2.0では、認可プロトコルのフローをGrant Typeと呼んでいる。代表的なGrant Typeとして、ユーザがクライアントに権限を委譲するAuthorization Code Grantと、クライアントが自身のリソースにアクセスするためのClient Credentials Grantが定義されている。端末は、ユースケースによってGrant Typeを使い分ける事が考えられる。例えば、端末のオーナーであるユーザが、端末を操作した事を契機にクラウドサービスと連携する場合は、Authorization Code Grantが選択される。一方、端末が備えるセンサーや機器における変化を検知し、クラウドサービスと連携する場合は、Client Credentials Grantが選択される。このように、OAuth2.0を利用する事で、様々なユースケースに対応する事が可能である。

一つの端末上で各々がリソースサーバと連携する複数のクライアントアプリケーションが動作するシステムの場合、各アプリケーションが各々に認証・認可処理を行うのは非効率であるため、認証・認可処理を肩代わりするトークンプロバイダアプリケーションが配置される構成が提案されている(特許文献1)。その際、各クライアントアプリケーションはOAuth2.0による認証後にトークンプロバイダアプリケーションからアクセストークンを取得し、リソースサーバと連携する。

このとき、複数のクライアントアプリケーションと連携するリソースサーバはアプリケーションごとに異なり、そのドメインも異なることがある。そして各ドメインへのアクセス可否はファイヤウォール設定など端末設置先のネットワーク構成やセキュリティ設定などに依存する。したがって、端末上の各クライアントアプリケーションがリソースサーバと適切に連携するためには、クライアントアプリケーションとリソースサーバとの間の通信が可能であるかを確認する必要がある。通信相手のリソースサーバはクライアントアプリケーションごとに決まっているので、この確認はクライアントアプリケーションごとに実施しなければならない。

特許第６０６６６４７号

そこで各アプリケーションがクラウドサービスと連携できることを保証するには、まず端末使用者がトークンプロバイダアプリケーションにおいて認可サーバへの端末の登録を行う。そののち、使用者がクライアントアプリケーションを一つずつ起動して通信テストを行い、結果を確認する必要がある。この作業は煩雑な作業であり、クライアントアプリケーションが増えるに連れて作業量が増大し、使用者の負担となる。

本発明は上記従来に鑑みてなされたもので、クライアントアプリケーションの通信テストを自動化して作業者による作業負担を軽減することを目的とする。

上記目的を達成するために本発明は以下の構成を有する。すなわち本発明の一側面によれば、一以上のクライアントアプリケーションと、前記一以上のクライアントアプリケーションがリソースサーバと通信するために必要なトークン情報を提供するトークンプロバイダアプリケーションとを有する情報処理装置は、前記トークンプロバイダアプリケーションによって以下の機能を実行することを特徴とし、前記機能とは、
認可サーバへ前記情報処理装置の装置登録を行う登録機能と、
前記装置登録の実行に併せて、前記トークンプロバイダアプリケーションに対してイベントリスナとして登録済みの前記一以上のクライアントアプリケーションへ前記リソースサーバとの間の通信テストの開始を通知するテスト開始通知機能と、
通信テストに利用される前記トークン情報を要求元のクライアントアプリケーションに提供する提供機能と、
前記一以上のクライアントアプリケーションから前記通信テストの結果を受け取るテスト結果受信機能と、
であることを特徴とする情報処理装置が提供される。

本発明により、クライアントアプリケーションの通信テストを自動化して作業者による作業負担を低減することができる。

システム構成例を示す図である。 端末のハードウェア構成例を示す図である。 第一の実施形態に係るトークンプロバイダアプリケーション３１０のモジュール構成を示す図である。 第一の実施形態に係る通信テストのシーケンスを示す図である。 第一の実施形態に係る通信テストのシーケンスを示す図である。 通信テスト開始の表示画面例を示す図である。 通信テスト結果の表示画面例を示す図である。 通信テスト結果詳細の表示画面例を示す図である。 第二の実施形態に係るトークンプロバイダアプリケーション３１０のモジュール構成を示す図である。 第二の実施形態に係る通信テストのシーケンスを示す図である。

以下、本発明の実施形態について図面を用いて説明する。
[システム構成]
本実施形態にかかるシステムは、図１に示すような構成を示す図である。
認可サーバ１００は、端末の認証・アクセストークンの発行を実現するためのＡＰＩを備えるサーバである。
リソースサーバ２００はＷｅｂサービスとして公開されるＡＰＩを備える。端末３００は、例えばＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）やスマートフォンと呼ばれる携帯端末、複合機などが該当する。
トークンプロバイダアプリケーション３１０は、認可サーバ１００が公開するＡＰＩを利用することで、端末の認証を行い、クライアントアプリケーション３２０にリソースサーバ２００のＡＰＩ利用に必要なアクセストークンを提供する。クライアントアプリケーション３２０は一つとは限らず、一以上であってもよい。
クライアントアプリケーション３２０は、リソースサーバ２００が公開するＡＰＩを利用することで、自身の提供する機能と合わせたサービスをユーザに提供する。

本実施形態に係るシステムの構成要素は、例えば、図２に示すような構成の情報処理装置にて実現される。
図２は、認可サーバ１００、リソースサーバ２００、および端末３００のハードウェア構成の例を示す。なお認可サーバ１００とリソースサーバ２００については同じハードウェア構成を有するのでサーバとして示した。また端末３００としては、汎用のパーソナルコンピュータなどの情報処理装置のほか、ＭＦＰあるいは単にデバイスなどと呼ばれる多機能周辺機器などを利用することもできる。パーソナルコンピュータはサーバと同様のハードウェア構成でよいのでその図は省略し、多機能周辺機器の構成を図２に示した。なおサーバについては、ユーザインターフェースを持たなくとも端末との間の相互作用は可能なのでユーザインターフェースを示していない。しかし、コンピュータを端末として利用するのであれば、キーボードやポインティングデバイス、タッチパネルといったユーザインターフェースが端末には必要である。

図２は端末装置３００とサーバ１００，２００とを接続した構成例を示す。なお図２では端末装置３００とサーバ１００，２００とはネットワーク２２０を介して接続されているが、ネットワーク２２０は、ＬＡＮやＷＡＮ、インターネットなど様々な種類のネットワークやそれらの複合を含んでいてよい。

●端末（ＭＦＰ）のハードウェア
図２において、端末装置３００は、のの一例であるＭＦＰのハードウェア構成を示す。操作部２１０は、タッチパネル機能を有する表示部や各種ハードキー等を有し、制御部３０１からのデータに従ってユーザに対して情報を表示したり、ユーザの操作に応じた情報を制御部３０１に入力したりする。スキャナ部２１２は、原稿上の画像を読み取って、その画像の画像データを作成して制御部３０１に供給する。プリンタ部２１３は、制御部３０１から受け取った画像データに基づいて用紙上に画像を印刷する。

制御部３０１は、操作部２１０、スキャナ部２１２、プリンタ部２１３と電気的に接続されており、またネットワーク２２０にもネットワークインターフェース（Ｉ／Ｆ）２０６を介して接続されている。これによりネットワーク２２０を介した、ＴＣＰ／ＩＰ等の通信プロトコルによる通信が可能となっている。制御部３０１において、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、ＨＤＤ２０４、操作部Ｉ／Ｆ２０５、ネットワークＩ／Ｆ２０６、スキャナＩ／Ｆ２０７、画像処理部２０８及びプリンタＩ／Ｆ２０９がシステムバス２１１を介して接続されている。ＣＰＵ２０１は、ＲＯＭ２０２のブートプログラムを実行してＨＤＤ２０４に記憶されたＯＳや制御プログラムをＲＡＭ２０３に展開し、そのプログラムに基づいてこの端末（ＭＦＰ）３００を統括的に制御する。この制御には、後述のフローチャートを実現するためのプログラムの実行も含む。ＲＯＭ２０２には、このＭＦＰ１１０のブートプログラムや各種データが格納されている。ＲＡＭ２０３は、ＣＰＵ２０１が動作するためのワークメモリを提供し、また画像データを一時記憶するための画像メモリも提供している。ＨＤＤ２０４はハードディスクドライブであり、ＯＳや各種プログラムや画像データを格納している。

操作部Ｉ／Ｆ２０５は、システムバス２１１と操作部２１０とを接続するためのインターフェース部である。ネットワークＩ／Ｆ２０６は、ネットワーク２２０及びシステムバス２１１に接続し、ネットワークを介して情報の入出力を行う。スキャナＩ／Ｆ２０７は、スキャナ部２１２と制御部３０１との間のインターフェースを制御する。画像処理部２０８は、スキャナ部２１２から入力した画像データ、及びプリンタ部２１３に出力する画像データに対して、回転、色変換、画像圧縮／伸張処理などの画像処理を行う。プリンタＩ／Ｆ２０９は、画像処理部２０８で処理された画像データを受け取り、この画像データに付随している属性データに従ってプリンタ部２１３による印刷を制御する。

操作部２１０には、たとえば立ち上げ後の初期画面において、クライアントアプリケーション３２０の登録済みのショートカット（あるいはＧＵＩボタン）が表示される。クライアントアプリケーション３２０は、アクセス先のリソースサーバ２００ごとに用意される。ショートカットが操作される（押下される）と、対応するクライアントアプリケーション３２０が起動されて、設定されたアクセス先（リソースサーバ）へとアクセスする。

●サーバのハードウェア
図２には、認可サーバ１００とリソースサーバ２００（ここでは、これらをまとめてサーバ１００と称する）のハードウェア構成も示されている。サーバ１００は、ＣＰＵ２５１、ＲＡＭ２５２、ＲＯＭ２５３、ハードディスクドライブ（ＨＤＤ）２５４、ネットワークＩ／Ｆ２５５を有し、これらはシステムバス２５６を介して互いに通信可能に接続されている。ＲＯＭ２５３はブートプログラムを格納しており、ＣＰＵ２５１は電源オン時に、このブートプログラムを読み出してＨＤＤ２５４にインストールされているＯＳや制御プログラム等をＲＡＭ２５２に展開する。そしてＣＰＵ２５１が、ＲＡＭ２５２に展開したプログラムを実行することにより、このサーバ１００の機能が実現される。またＣＰＵ２５１は、ネットワークＩ／Ｆ２５５を介して接続されているネットワーク上の他の装置、例えば端末３００との通信を行う。尚、端末３００がコンピュータであるばあいには、キーボードなどのユーザインターフェースを有している。

＜第一の実施形態＞
以下に、第一の実施形態にかかる説明を記載する。
[モジュール構成]
図３は、第一の実施形態に係るトークンプロバイダアプリケーション３１０のモジュール構成の例を示す図である。各モジュールを実行されることでサービスを提供する。トークンプロバイダアプリケーション３１０は端末３００にインストールされて実行される。なお、ここでは、本実施形態に係るモジュールのみを示し、他のモジュールについては省略する。
トークンプロバイダアプリケーション３１０は、アクセストークン供給部３１１、通知テスト開始通知部３１２，通信テスト結果受信部３１３、および通信テスト結果表示部３１４を備える。
アクセストークン供給部３１１は、クライアントアプリケーション３２０からの要求を受けて、認可サーバ１００からアクセストークンを取得するためのモジュールである。また取得したアクセストークンをクライアントに提供するトークン提供部としても機能する。なおアクセストークンは情報であるので、アクセストークン情報あるいは認可トークン情報あるいは単にトークン情報とも呼ぶ。
通信テスト開始通知部３１２は、クライアントアプリケーション３２０が登録を行うイベントを用意し、通信テスト開始指示に応じて前記イベントを発行して登録したクライアントアプリケーション３２０への通知を行うためのモジュールである。通信テスト開始指示は、それ自体が独立した指示として操作者により入力されてもよいし、或いは、操作者などにより入力される端末３００の認可サーバ１００への登録指示や、または認可サーバ１００から受信した端末３００の登録完了の応答、または登録完了後の通信テスト指示そのものであってもよいし、それらをトリガーとして発行されてもよい。

通信テスト結果受信部３１３は、各クライアントアプリケーション３２０からの通信テスト完了結果を受け付けるモジュールである。また、通信テスト結果受信部３１３は通信テスト開始通知部３１２による通信テスト開始指示から一定時間までに通知を受け取れなかった場合、タイムアウトして通信テスト結果を失敗として処理する機能も備える。
通信テスト結果表示部３１４は、通信テスト結果受信部３１３が受信した各クライアントアプリケーション３２０からの通信テスト結果を取りまとめ、操作部２１０のＬＣＤなどの表示デバイスに表示するモジュールである。

[処理シーケンス]
図４Ａ〜７を用いて、本実施形態にかかるシステムが通信テストを完了するまでに必要なステップを説明する。
図４Ａでは、クライアントアプリケーション３２０を端末３００にインストールした際の処理を示している。ここでは、クライアントアプリケーション３２０のインストール以前にトークンプロバイダアプリケーション３１０がすでにインストールされていることを前提とする。

ステップＳ４０１では、まず、クライアントアプリケーション３０２が端末３００にインストールされる。このときにクライアントアプリケーション３２０はトークンプロバイダアプリケーション３１０が提供するイベントに、イベントリスナとして自身を登録する（ステップＳ４０２）。これにより、トークンプロバイダアプリケーション３１０は、クライアントアプリケーション３２０への通知が可能となる。すなわち、ステップＳ４０２では、クライアントアプリケーション３２０は、トークンプロバイダアプリケーション３１０に自身をイベント通知先として登録しておく。

本実施形態において、実際にトークンプロバイダアプリケーション３１０が端末登録の一連の処理において通信テストを実施する際のシーケンスを図４ＢのステップS４０３〜S４０８を用いて説明する。この手順は端末３００が認可サーバ１００からクライアントクレデンシャルを取得する必要がある場合に実行される。たとえば端末３００が新たにインストールされた場合や、新たな認可サーバ１００を利用する場合、クライアントクレデンシャルの有効期限が切れた場合などである。

ステップＳ４０３では、まず、トークンプロバイダアプリケーション３１０が認可サーバ１００へ端末３００の登録を要求する。処理が成功すると、認可サーバ１００は端末３００が認証されたデバイスであることを示すためのクライアントクレデンシャルを返す。これにより、以降の処理でアクセストークンの取得が可能となる。

ステップＳ４０４では、トークンプロバイダアプリケーション３１０が通信テスト開始イベントを発行し、ステップＳ４０２でイベントリスナ登録しているクライアントアプリケーションに対して通信テスト開始を通知する。本実施例では、クライアントアプリケーション３２０に通信テスト開始を通知する。
通信テストの内容はそれぞれのクライアントアプリケーション３２０固有である。またクライアントアプリケーション３２０は、アクセス先となるリソースサーバ２００のＵＲＬ、およびリソースへのアクセスに権限が必要な場合はその権限情報を保持できる。権限情報はたとえばアクセストークンでよく、いったん取得したなら有効である限り保持して利用できる。そこでアクセス権限が必要な通信テストを実施する場合、ステップＳ４０５において、クライアントアプリケーション３２０はトークンプロバイダアプリケーション３１０にアクセストークンを要求する。

トークンプロバイダアプリケーション３１０は要求を受けると、ステップＳ４０３で取得したクライアントクレデンシャルを用いて認可サーバ１００へアクセストークンの要求を行い、要求に応じてアクセストークンを取得する（Ｓ４０６）。

ステップＳ４０７では、クライアントアプリケーション３２０がリソースサーバ２００への通信テストを行い、通信テスト結果を取得する。通信テストはリソースサーバ２００とクライアントアプリケーション３２０との間であらかじめ定めた手順で実施すればよい。そのための手順はリソースサーバ２００とクライアントアプリケーション３２０それぞれに予めプログラムされていてよい。クライアントアプリケーション３２０は、通信テストに対するレスポンスが一定時間までに返ってこない場合には、タイムアウトして通信テスト失敗と判定する。

通信テストが完了すると、ステップＳ４０８において、クライアントアプリケーション３２０はトークンプロバイダアプリケーション３１０に通信テスト結果を通知する。

最後に、ステップＳ４０９では、トークンプロバイダアプリケーション３１０が、通信テスト開始を通知したすべてのクライアントアプリケーション３２０からのテスト結果を受け取り、表示デバイスへ結果を表示する。

以上の構成及び手順により、クライアントアプリケーション３２０によるリソースサーバ１００との間の通信テストを、個別のクライアントアプリケーション３２０に対する指示を行うことなく実施できる。より効率的に通信テストを行うには、たとえば端末３００をネットワーク２２０に接続する前に、トークンプロバイダアプリケーション３１０をインストールし、その後に利用予定のクライアントアプリケーション３２０をインストールしておけばよい。その後端末３００をネットワークに接続して、例えば操作者の明示的な指示などにより端末３００を認可サーバ１００に登録させれば、上記手順に従ってインストール済みのクライアントアプリケーション３２０すべてについて通信テストを実施できる。

なお本実施形態においては、ステップＳ４０３からＳ４０４までの処理を一連のシーケンスで表現しているが、これに限るものではなく、ステップＳ４０４の処理はステップＳ４０３以後であれば、別の操作をトリガーに開始されても良い。
また、ステップＳ４０５においてクライアントアプリケーション３２０がトークンプロバイダアプリケーション３１０にアクセストークンを要求しているが、必ずしもこの方式である必要はなく、トークンプロバイダアプリケーション３１０があらかじめアクセストークンを取得しておき、ステップＳ４０４の通信テスト開始を通知する際にアクセストークンを渡す方式でも良い。

●表示例
図５では、本実施形態において、通信テストを開始する際に表示されるトークンプロバイダアプリケーション３１０の画面の例を示している。
図５（Ａ）は、操作者による端末の登録指示をトリガーにして通信テストを行う場合の画面の一例である。登録ボタン５０１が押下されると、トークンプロバイダアプリケーション３１０が端末３００の認可サーバ１００への登録を行ったのち、連続してクライアントアプリケーション３２０への通信テスト開始通知を行う図４（ｂ）のシーケンスに沿った動作を行うものとなっている。

一方で、図５（Ｂ）では、操作者が端末の登録指示とは別に通信テスト開始指示を行う場合の画面の一例である。この例は、ステップＳ４０３までの処理が完了している状態で表示される画面であり、通信テスト実施ボタン５０２を押下することでステップＳ４０４の処理が開始される。図５（Ｂ）の画面は、図５（Ａ）の画面で端末の登録が完了した後に表示されてもよい。図５（Ｂ）の画面例では通信テストの実施は任意であり、ボタン５０３（ＯＫボタンまたはキャンセルボタン）を押下することで通信テストを実施しないまま機器登録を終えることもできる。その場合には図５（Ｂ）の画面をその後に表示させて通信テストを実施することもできる。

図６および図７は、通信テスト完了後のトークンプロバイダアプリケーション３１０の表示画面の一例を示している。図６は、結果の概要を示した画面の一例であり、端末の登録処理結果とともに通信テスト結果が表示されている。通信テストに失敗した端末がある場合には、そのことを示すメッセージが表示される。図６の表示に加えて、失敗した端末のＩＤなどを表示してもよい。さらにテスト結果詳細ボタン６０１を押下することで図７の例に示すような通信テスト結果詳細を閲覧することができる。

図７の通信テスト結果詳細画面の例では、各クライアントアプリケーション３２０の通信テスト結果を閲覧することができ、通信テストに失敗したテストにおいては、そのエラーの詳細を確認できる。詳細画面にはテスト再試行ボタン７０１が配置されており、失敗した通信テストが存在する場合、その押下に応じて再度テストを実行しても良い。すなわち、図４のステップＳ４０７−Ｓ４０９を繰り返し行ってもよい。この場合には、たとえば図７の詳細画面にリストされたクライアントアプリケーションごとに選択用チェックボックスを設けるなどして、テスト対象のクライアントアプリケーションを選択できるようにしてもよい。そして再テストが指示されたなら、選択されたアプリケーションについて再テストを行ってもよい。あるいは、テストに失敗したクライアントアプリケーションのみを選択するためのチェックボックス等を設け、それがチェックされているなら、通信テストに失敗したクライアントアプリケーションを対象として再テストを実行してもよい。

以上、本実施形態により、操作者はトークンプロバイダアプリケーション３１０上の端末３００の登録操作からの一連の流れで、各クライアントアプリケーション３２０の通信テスト結果を確認することが可能となる。

＜第二の実施形態＞
第一の実施形態では、図４Ａに示すとおり、クライアントアプリケーション３２０がトークンプロバイダアプリケーション３１０インストール後にインストールされるクライアントアプリケーション（以下、アドオンアプリケーションと呼称する）であることを前提としていた。しかしながら、端末３００にトークンプロバイダアプリケーション３１０がインストールされる以前からインストールされているクライアントアプリケーション（以下、プリインストールアプリケーションと呼称する）の場合、ステップＳ４０２で記載したイベントの登録を行うことができず、第一の実施形態では通信テストを実施できない。第二の実施形態では本課題を解決する。

［モジュール構成］
図８は第二の実施形態に係るトークンプロバイダアプリケーション３１０のモジュール構成の例を示す図である。
ここでの説明は前述の実施例の図３とほぼ同様なため、異なる部分のみを以下、説明する。通信テスト指示部８０１は、通信テスト開始通知部３１２ではイベント登録されていないクライアントアプリケーション３２０に通信テストを指示するモジュールである。通信テスト指示部８０１は予めテスト対象のクライアントアプリケーション３２０のリストを保持し、通信テスト開始指示を受けると、リストに従ってクライアントアプリケーション３２０の通信テストを行い、結果を通信テスト結果表示部３１４へと渡す。通信テスト指示部８０１が保持するテスト対象のクライアントアプリケーション３２０のリストは、たとえばトークンプロバイダアプリケーション３１０が作成してもよい。その場合例えばトークンプロバイダアプリケーション３１０は、それがインストールされたときに、レジストリ等を参照してインストール済みのクライアントアプリケーション３２０の情報を取得し、取得した情報に基づいて作成してよい。あるいは操作者がユーザインターフェース上で対象のクライアントアプリケーションのＩＤなどを入力することで作成してもよい。

［処理シーケンス］
本実施形態において、実際にトークンプロバイダアプリケーション３１０が端末登録の一連の処理において通信テストを実施する際のシーケンスを図９のステップＳ９０１〜Ｓ９０７を用いて説明する。本処理シーケンスは図４の処理シーケンスと並行して実施される。これにより、トークンプロバイダアプリケーション３１０とクライアントアプリケーション３２０のインストール順序に関わりなく、インストール済みのクライアントアプリケーション３２０について通信テストの自動化を実現できる。ただし、クライアントクレデンシャルの取得は、いずれか先に行った一度だけであってもよい。
ここで図９の処理の説明は前述の実施例の図４Ｂとほぼ同様なため、異なる部分のみを以下、説明する。

ステップＳ９０２において、トークンプロバイダアプリケーション３１０は保持している指定テスト対象のクライアントアプリケーション一覧を取得する。
そして、ステップＳ９０３において、前記クライアントアプリケーション一覧にあるすべてのクライアントアプリケーション３２０に通信テスト開始処理を指示する。

ステップＳ９０７において、すべてのクライアントアプリケーション３２０に対する通信テストの完了を受けて、図４Ｂの処理シーケンスによる通信テスト結果と合わせてイベント通知通信テスト結果を表示する。
このとき、前記クライアントアプリケーション一覧に記載されたクライアントアプリケーション３２０のうち、インストールされていない、あるいは、無効化されたクライアントアプリケーション３２０については、その結果を表示しない。

本実施形態により、トークンプロバイダアプリケーション３１０よりも後にインストールされるアドオンアプリケーションのみならず、プリインストールアプリケーションも含め、一連の操作で、複数のインストール済みクライアントアプリケーションを対象として通信テストを行うことが可能となる。このため捜査が簡略化されて操作者の操作負担が軽減される。

なお、端末３００にインストールされたクライアントアプリケーション３２０すべてについて、通信テスト指示部８０１に登録してもよい。この場合には、例えば、トークンプロバイダアプリケーション３１０は、通信テスト実施の指示に応じてまずレジストリ等を参照してインストール済みのクライアントアプリケーションのリストを作成する。そしてその後に、図９に示したステップＳ９０３以降の処理を実行する。こうすることで、第２実施形態に示した構成及び手順により、インストールされたクライアントアプリケーション３２０すべてを対象として通信テストを実施できる。

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

１００ 認可サーバ、２００ リソースサーバ、３００ 端末、３１０ トークンプロバイダアプリケーション、３２０ クライアントアプリケーション、３００ 端末、３１１ アクセストークン供給部、３１２ 通信テスト開始通知部、３１３ 通信テスト結果受信部、３１４ 通信テスト結果表示部、８０１ 通信テスト指示部

Claims (8)

1. 一以上のクライアントアプリケーションと、前記一以上のクライアントアプリケーションがリソースサーバと通信するために必要なトークン情報を提供するトークンプロバイダアプリケーションとを有する情報処理装置は、前記トークンプロバイダアプリケーションによって以下の機能を実行することを特徴とし、前記機能とは、
   認可サーバへ前記情報処理装置の装置登録を行う登録機能と、
   前記装置登録の実行に併せて、前記トークンプロバイダアプリケーションに対してイベントリスナとして登録済みの前記一以上のクライアントアプリケーションへ前記リソースサーバとの間の通信テストの開始を通知するテスト開始通知機能と、
   通信テストに利用される前記トークン情報を要求元のクライアントアプリケーションに提供する提供機能と、
   前記一以上のクライアントアプリケーションから前記通信テストの結果を受け取るテスト結果受信機能と、
   であることを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記一以上のクライアントアプリケーションからの要求に応じてイベント通知先として登録する登録機能を更に有し、
   前記テスト開始通知機能は、前記イベント通知先として登録した前記一以上のクライアントアプリケーションに対して、前記リソースサーバとの間の前記通信テストの開始を通知することを特徴とする情報処理装置。
3. 請求項１または２に記載の情報処理装置であって、
   テスト対象の前記一以上のクライアントアプリケーションを登録したリストを保持する保持機能を更に有し、
   前記テスト開始通知機能は、前記リストに登録されている前記一以上のクライアントアプリケーションに対して、前記リソースサーバとの間の前記通信テストの開始を通知することを特徴とする情報処理装置。
4. 請求項１乃至３のいずれか一項に記載の情報処理装置であって、
   前記テスト開始通知機能は、認可サーバへの前記情報処理装置の登録指示、または前記認可サーバから受信した前記情報処理装置の登録完了後の通信テスト指示をトリガーとして、前記通信テストの開始を通知することを特徴とする情報処理装置。
5. 請求項１乃至４のいずれか一項に記載の情報処理装置であって、
   前記通信テストの結果を出力する出力手段を更に有することを特徴とする情報処理装置。
6. 請求項１乃至５のいずれか一項に記載の情報処理装置であって、
   前記一以上のクライアントアプリケーションを実行することを特徴とする情報処理装置。
7. 一以上のクライアントアプリケーションと、前記一以上のクライアントアプリケーションがリソースサーバと通信するために必要なトークン情報を提供するトークンプロバイダアプリケーションとを有する情報処理装置を、前記トークンプロバイダアプリケーションによって、
   認可サーバへ前記情報処理装置の装置登録を行う登録手段と、
   前記装置登録の実行に併せて、前記トークンプロバイダアプリケーションに対してイベントリスナとして登録済みの前記一以上のクライアントアプリケーションへ前記リソースサーバとの間の通信テストの開始を通知するテスト開始通知手段と、
   通信テストに利用される前記トークン情報を要求元のクライアントアプリケーションに提供する提供手段と、
   前記一以上のクライアントアプリケーションから前記通信テストの結果を受け取るテスト結果受信手段と、
   して機能させるためのプログラム。
8. 一以上のクライアントアプリケーションと、前記一以上のクライアントアプリケーションがリソースサーバと通信するために必要なトークン情報を提供するトークンプロバイダアプリケーションとを有する情報処理装置により実行される前記トークンプロバイダアプリケーションによるクライアントアプリケーションのテスト方法であって、
   認可サーバへ前記情報処理装置の装置登録を行い、
   前記装置登録の実行に併せて、前記トークンプロバイダアプリケーションに対してイベントリスナとして登録済みの前記一以上のクライアントアプリケーションへ前記リソースサーバとの間の通信テストの開始を通知し、
   通信テストに利用される前記トークン情報を要求元のクライアントアプリケーションに提供し、
   前記一以上のクライアントアプリケーションから前記通信テストの結果を受け取る
   ことを特徴とするクライアントアプリケーションのテスト方法。

Images