(57)【要約】【課題】他の通信装置に、簡単、かつ、安全にアクセス権限を委譲できるようにすることを目的とする。【解決手段】認可サービスから、認可サービスによってアクセス権限を管理されたリソースに対するアクセス権限を示すトークンを取得する際に用いられるトークン取得情報を取得する取得手段と、他の装置との通信が一時的か否かを判断する判断手段と、判断手段により他の装置との通信が一時的でないと判断された場合、取得手段により取得されたトークン取得情報を他の装置に送信する送信手段と、を有することによって課題を解決する。【選択図】図１０
2014102561.tif 000002
【特許請求の範囲】
【請求項１】
認可サービスから、前記認可サービスによってアクセス権限を管理されたリソースに対するアクセス権限を示すトークンを取得する際に用いられるトークン取得情報を取得する取得手段と、
他の装置との通信が一時的か否かを判断する判断手段と、
前記判断手段により前記他の装置との通信が一時的でないと判断された場合、前記取得手段により取得された前記トークン取得情報を前記他の装置に送信する送信手段と、
を有する通信装置。
【請求項２】
前記判断手段により前記他の装置との通信が一時的であると判断された場合、前記取得手段により取得された前記トークン取得情報を用いて前記トークンを取得するトークン取得手段を更に有し、
前記送信手段は、前記判断手段により前記他の装置との通信が一時的であると判断された場合、前記トークン取得手段により取得された前記トークンを前記他の装置に送信する請求項１記載の通信装置。
【請求項３】
前記判断手段は、前記他の装置との無線通信接続におけるグループ形態が一時的であるか否かを判断し、前記グループ形態が一時的である場合、前記他の装置との通信が一時的であると判断する請求項１又は２記載の通信装置。
【請求項４】
前記他の装置との通信を継続しない場合、前記認可サービスに対して、前記トークン、又は前記トークン取得情報の無効化を要求する要求手段を更に有する請求項１乃至３何れか１項記載の通信装置。
【請求項５】
前記要求手段は、前記他の装置との無線通信接続に関する無線パラメタが削除される場合、前記他の装置との通信を継続しないと判断し、前記認可サービスに対して、前記トークン、又は前記トークン取得情報の無効化を要求する請求項４記載の通信装置。
【請求項６】
第１の通信装置と、第２の通信装置と、を含む通信システムであって、
前記第１の通信装置は、
認可サービスから、前記認可サービスによってアクセス権限を管理されたリソースに対するアクセス権限を示すトークンを取得する際に用いられるトークン取得情報を取得する取得手段と、
前記第２の通信装置との通信が一時的か否かを判断する判断手段と、
前記判断手段により前記第２の通信装置との通信が一時的でないと判断された場合、前記取得手段により取得された前記トークン取得情報を前記第２の通信装置に送信する送信手段と、
を有し、
前記第２の通信装置は、
前記トークン取得情報を前記第１の通信装置より受信すると、前記トークン取得情報を用いて前記認可サービスより前記トークンを取得するトークン取得手段と、
前記トークン取得手段により取得された前記トークンを用いて前記リソースに対してアクセスを行うアクセス手段と、
を有する通信システム。
【請求項７】
前記第１の通信装置は、
前記判断手段により前記第２の装置との通信が一時的であると判断された場合、前記取得手段により取得された前記トークン取得情報を用いて前記トークンを取得するトークン取得手段を更に有し、
前記送信手段は、前記判断手段により前記第２の装置との通信が一時的であると判断された場合、前記トークン取得手段により取得された前記トークンを前記第２の装置に送信し、
前記トークン取得手段は、前記第１の通信装置からトークンが送信されてきた場合は、前記トークンを取得する請求項６記載の通信システム。
【請求項８】
通信装置が実行する情報処理方法であって、
認可サービスから、前記認可サービスによってアクセス権限を管理されたリソースに対するアクセス権限を示すトークンを取得する際に用いられるトークン取得情報を取得する取得ステップと、
他の装置との通信が一時的か否かを判断する判断ステップと、
前記判断ステップにより前記他の装置との通信が一時的でないと判断された場合、前記取得ステップにより取得された前記トークン取得情報を前記他の装置に送信する送信ステップと、
を含む情報処理方法。
【請求項９】
第１の通信装置と、第２の通信装置と、を含む通信システムにおける情報処理方法であって、
前記第１の通信装置が、認可サービスから、前記認可サービスによってアクセス権限を管理されたリソースに対するアクセス権限を示すトークンを取得する際に用いられるトークン取得情報を取得する取得ステップと、
前記第１の通信装置が、前記第２の通信装置との通信が一時的か否かを判断する判断ステップと、
前記第１の通信装置が、前記判断ステップにより前記第２の通信装置との通信が一時的でないと判断された場合、前記取得ステップにより取得された前記トークン取得情報を前記第２の通信装置に送信する送信ステップと、
前記第２の通信装置が、前記トークン取得情報を前記第１の通信装置より受信すると、前記トークン取得情報を用いて前記認可サービスより前記トークンを取得するトークン取得ステップと、
前記第２の通信装置が、前記トークン取得ステップにより取得された前記トークンを用いて前記リソースに対してアクセスを行うアクセスステップと、
を含む情報処理方法。
【請求項１０】
コンピュータに、
認可サービスから、前記認可サービスによってアクセス権限を管理されたリソースに対するアクセス権限を示すトークンを取得する際に用いられるトークン取得情報を取得する取得ステップと、
他の装置との通信が一時的か否かを判断する判断ステップと、
前記判断ステップにより前記他の装置との通信が一時的でないと判断された場合、前記取得ステップにより取得された前記トークン取得情報を前記他の装置に送信する送信ステップと、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、通信システム、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
近年、インターネット上のコンテンツ共有サービスやコミュニケーションサービス等の外部サービスにアクセスする機能を備えた携帯電話やデジタルカメラが存在する。ユーザは、これらの通信装置を用いることで、撮像した画像コンテンツを写真共有サービスにアップロードする、或いはメッセージを友人に送信することができる。通常、これらの外部サービスは、認可サービスと連携して、外部サービス上のコンテンツやファイル等のリソースへのアクセス権限を管理している。
認可サービスにおいて、アクセス権限の管理を目的としたＯＡｕｔｈプロトコルの利用が増えてきている。ＯＡｕｔｈにおいて、まず通信装置は、認可サービスから、所望するリソースに対するアクセス権限を示すアクセストークン、及びアクセストークンを更新するためのリフレッシュトークンを取得する。その後、通信装置は、外部サービスから所望するリソースの取得を要求する際、認可サービスから取得したアクセストークンを合せて提示する。外部サービスは、アクセストークンが有効な場合のみ、通信装置に要求されたリソースを送信する。もしアクセストークンの有効期限が切れた場合、通信装置は、認可サービスにリフレッシュトークンを提示することで、アクセストークンを更新することができる。
【０００３】
一方、認証チケットを利用して、ユーザのアクセス権限を第三者に委譲し、第三者が認可サービスに対してユーザ認証に成功した場合、第三者が委譲されたアクセス権限を利用できる方法が提案されている（特許文献１参照）。
これらの方法を用いて、ユーザは、外部サービスのユーザのリソースに対するアクセス権限を、家族や友人に委譲することで、家族や友人とリソースを共有して楽しむことができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−２２１５０６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来の技術では、ユーザの通信装置と友人の通信装置との通信接続の関係に応じて、アクセス権限の委譲の有効期限やアクセス権限の範囲を変えることができなかった。そのため、友人の通信装置との通信接続が一時的であり、ユーザのアクセス権限を一時的に友人に委譲したい場合であっても、ユーザが明示的に有効期限やアクセス権限の範囲を指定する必要があり、ユーザの利便性が損なわれていた。また、ユーザが誤って永続的なアクセス権限の委譲を指定してしまい、セキュリティ上のリスクが生じる恐れがあった。
【０００６】
本発明はこのような問題点に鑑みなされたもので、他の通信装置に、簡単、かつ、安全にアクセス権限を委譲できるようにすることを目的とする。
【課題を解決するための手段】
【０００７】
そこで、本発明は、認可サービスから、前記認可サービスによってアクセス権限を管理されたリソースに対するアクセス権限を示すトークンを取得する際に用いられるトークン取得情報を取得する取得手段と、他の装置との通信が一時的か否かを判断する判断手段と、前記判断手段により前記他の装置との通信が一時的でないと判断された場合、前記取得手段により取得された前記トークン取得情報を前記他の装置に送信する送信手段と、を有する。
【発明の効果】
【０００８】
本発明によれば、他の通信装置に、簡単、かつ、安全にアクセス権限を委譲できるようにすることができる。
【図面の簡単な説明】
【０００９】
【図１】通信システムのシステム構成の一例を示す図である。
【図２】第１の通信装置のハードウェア構成の一例を示す図である。
【図３】第１の通信装置の機能モジュール構成の一例を示す図である。
【図４】無線パラメタのデータ構成の一例を示す図である。
【図５】第１の通信装置が、第２の通信装置と無線通信接続する際の情報処理の一例を示すシーケンス図である。
【図６】第１の通信装置が、第２の通信装置に、第２のアクセストークンを送信する際の情報処理の一例を示すシーケンス図である。
【図７】第１の通信装置が、第２の通信装置に、第１のアクセストークンを送信する際の情報処理の一例を示すシーケンス図である。
【図８】第２の通信装置が、第１のリソースを取得する際の情報処理の一例を示すシーケンス図である。
【図９】第１の通信装置が、第１のアクセストークンを無効化する際の情報処理の一例を示すシーケンス図である。
【図１０】第１の通信装置が、アクセストークン、又は認可コードを送信する動作の手順を示すフローチャートである。
【図１１】第２の通信装置が、リソースを取得する動作の手順を示すフローチャートである。
【図１２】第１の通信装置が、アクセストークンを無効化する動作の手順を示すフローチャートである。
【図１３Ａ】第１の通信装置が、認可サービス５０へ送信する認可リクエストの例を示す図である。
【図１３Ｂ】第１の通信装置が、認可サービス５０から受信する認可レスポンスの例を示す図である。
【図１４Ａ】第１の通信装置が、認可サービス５０へ送信するアクセストークンリクエストの例を示す図である。
【図１４Ｂ】第１の通信装置が、認可サービス５０から受信するアクセストークンレスポンスの例を示す図である。
【図１５Ａ】第２の通信装置が、認可サービス５０へ送信するアクセストークン更新リクエストの例を示す図である。
【図１５Ｂ】第２の通信装置が、認可サービス５０から受信するアクセストークン更新レスポンスの例を示す図である。
【図１６Ａ】第１の通信装置が、認可サービス５０へ送信するアクセストークン無効リクエストの例を示す図である。
【図１６Ｂ】第１の通信装置が、認可サービス５０から受信するアクセストークン無効レスポンスの例を示す図である。
【発明を実施するための形態】
【００１０】
以下、本発明の実施形態について図面に基づいて説明する。
【００１１】
＜第１実施形態＞
図１は、通信システムのシステム構成の一例を示す図である。
第１の通信装置１０は、表示機能、操作機能、及びＩＥＥＥ８０２．１１に則った無線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）通信機能を有する。第１の通信装置１０のより具体的な例は、デジタルカメラ、デジタルビデオカメラ、携帯電話、スマートフォン、ＰＣ、ノートＰＣ等である。なお、本実施形態では無線ＬＡＮ通信機能を用いたが、これに限らず、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）、ＲＦＩＤ等の他の無線通信規格を利用しても良い。
第２の通信装置２０は、第１の通信装置１０と同様である。
【００１２】
本実施形態において、第１の通信装置１０と、第２の通信装置２０とは、互いに通信を行う。通信方法は特に限定されないが、本実施形態において、第１の通信装置１０と、第２の通信装置２０とは、Ｗｉ−Ｆｉ  Ｄｉｒｅｃｔに従うＰ２Ｐグループを介して接続するものとする。なお、Ｗｉ−Ｆｉ  Ｄｉｒｅｃｔの代わりに、ＷＰＳ（Ｗｉ−Ｆｉ  Ｐｒｏｔｅｃｔｅｄ  Ｓｅｔｕｐ）、ＷＰＳＥ（ＷＰＳ  Ｅｘｔｅｎｓｉｏｎ）、アドホック接続等を用いることもできる。
無線ＡＰ３０は、第１の通信装置１０、及び第２の通信装置２０における無線ＬＡＮ通信を中継する無線アクセスポイントである。
ネットワーク４０は、無線ＡＰ３０、認可サービス５０、及び外部サービス６０が接続されるネットワークである。ネットワーク４０のより具体的な例は、有線ＬＡＮ、無線ＬＡＮ、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、インターネット等である。
認可サービス５０は、ＯＡｕｔｈ  ２．０に則り、外部サービス６０上の第１のリソースへのアクセス権限を管理する。なお、本実施形態ではＯＡｕｔｈ  ２．０を用いたが、これに限らず、ＯＡｕｔｈ  １．０、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔ等の認可規格や、独自の認可方式を利用しても良い。
外部サービス６０は、第１の通信装置１０を利用する第１のユーザが所有する第１のリソースを管理する。
【００１３】
次に、通信システムの構成要素を詳細に説明する。
図２は、第１の通信装置１０のハードウェア構成の一例を示す図である。なお、第２の通信装置２０も、第１の通信装置１０と同じ構成であるため、以後は第１の通信装置１０のみを説明する。
第１の通信装置１０は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２０１と、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２０２と、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２０３と、補助記憶装置２０４と、を備える。また、第１の通信装置１０は、表示部２０５と、操作部２０６と、通信部２０７と、アンテナ２０８と、を備える。
ＣＰＵ２０１は、第１の通信装置１０全体を制御する。
ＲＯＭ２０２は、変更を必要としないプログラムやパラメタを格納する。
ＲＡＭ２０３は、補助記憶装置２０４等から供給されるプログラムやデータを一時記憶する。
【００１４】
補助記憶装置２０４は、プログラムや、無線パラメタ等の設定データ、画像や動画等のコンテンツデータを記憶する。例えば、補助記憶装置２０４の一例としては、メモリカード、ハードディスク等が挙げられる。
表示部２０５は、第１のユーザが第１の通信装置１０を操作するためのＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を表示する。また、表示部２０５は、認可サービス５０から取得した認可承認画面を表示する。
操作部２０６は、第１のユーザが第１の通信装置１０を操作するための入力インタフェースである。
通信部２０７は、アンテナ２０８を制御し、無線ＡＰ３０、又は第２の通信装置２０と通信する。
ＣＰＵ２０１が、ＲＯＭ２０２又は補助記憶装置２０４に記憶されたプログラムに基づき処理を実行することによって、後述する機能モジュールの構成及びフローチャートやシーケンスに係る処理が実現される。
【００１５】
図３は、第１の通信装置１０の機能モジュール構成の一例を示す図である。なお、第２の通信装置２０も、第１の通信装置１０と同じ構成であるため、以後は第１の通信装置１０のみを説明する。
第１の通信装置１０は、制御部３０１と、通信制御部３０２と、表示制御部３０３と、操作制御部３０４と、記憶制御部３０５と、無線パラメタ管理部３０６と、通信判断部３０７と、権限管理部３０８と、認可コード取得部３０９と、を備える。また、第１の通信装置１０は、認可コード送信部３１０と、送信判断部３１１と、トークン取得部３１２と、トークン送信部３１３と、無効判断部３１４と、トークン無効部３１５と、トークン更新部３１６と、リソース取得部３１７と、を備える。
制御部３０１は、第１の通信装置１０が備える個々の機能モジュール全体を制御する。
通信制御部３０２は、通信部２０７を制御し、無線ＡＰ３０、又は第２の通信装置２０との通信制御を行う。本実施形態において、通信制御部３０２は、第２の通信装置２０との間で、Ｗｉ−Ｆｉ  Ｄｉｒｅｃｔのプッシュボタン方式に従って通信制御を行う。
【００１６】
表示制御部３０３は、表示部２０５を制御し、第１の通信装置１０におけるＧＵＩの表示制御を行う。また、表示制御部３０３は、認可サービス５０から取得した認可承認画面の表示制御を行う。
操作制御部３０４は、操作部２０６を制御し、第１の通信装置１０における第１のユーザからの操作入力制御を行う。
記憶制御部３０５は、補助記憶装置２０４を制御し、画像コンテンツデータや動画コンテンツデータを記憶する。
無線パラメタ管理部３０６は、通信制御部３０２における無線通信に使用する無線パラメタ１１を管理する。無線パラメタ管理部３０６は、Ｗｉ−Ｆｉ  Ｄｉｒｅｃｔに必要な情報として、後述する図４に示すＳＳＩＤ４０１、暗号化方式４０２、暗号化鍵４０３、Ｗｉ−Ｆｉ  Ｄｉｒｅｃｔ情報４０４、を無線パラメタとして管理する。無線パラメタ管理部３０６は、第２の通信装置２０との無線通信の際、第２の通信装置２０から取得した無線パラメタ１１を、記憶制御部３０５を用いて記憶する。
【００１７】
通信判断部３０７は、第２の通信装置２０との無線通信が一時的か否か、を判断する。本実施形態において、無線通信が一時的であるとは、第１の通信装置１０と第２の通信装置２０との間の無線通信における接続から切断までの処理を、一回又は数回しか実施しない、又は限定した時間しか実施しない、とする。一方、本実施形態において、無線通信が一時的でないとは、第１の通信装置１０と第２の通信装置２０との間の無線通信における接続から切断までの処理を、回数を限定せずに実施する、又は時間を限定せずに実施する、とする。
また、通信判断部３０７は、Ｗｉ−Ｆｉ  Ｄｉｒｅｃｔ情報４０４に記載されたグループ形態を参照し、グループ形態が一時的である場合に、第２の通信装置２０との無線通信が一時的である、と判断する。一方、通信判断部３０７は、グループ形態が永続的である場合に、第２の通信装置２０との無線通信が一時的でない、と判断する。
また、通信判断部３０７は、第２の通信装置２０との無線通信が一時的でないと判断した後、第２の通信装置２０との無線通信を継続するか否か、を更に判断する。本実施形態において、通信判断部３０７は、無線パラメタ管理部３０６によって、第２の通信装置２０との無線通信に使用する無線パラメタ１１が削除された場合、第２の通信装置２０との無線通信を継続しない、と判断する。
【００１８】
権限管理部３０８は、第２の通信装置２０から、外部サービス６０上の第１のリソースに対するアクセス権限の権限委譲の要求を受ける。また、逆に、権限管理部３０８は、第２の通信装置２０に対して、外部サービス６０上の第２のリソースに対するアクセス権限の権限委譲を要求する。
認可コード取得部３０９は、認可サービス５０に対して、第１のリソースに対するアクセス権限の認可を要求する。本実施形態において、認可コード取得部３０９は、認可サービス５０に対して、ＯＡｕｔｈ  ２．０に基づく認可リクエストを送信する。そして、認可コード取得部３０９は、認可サービス５０から、前記認可リクエストに対する応答として、ＯＡｕｔｈ  ２．０に基づく認可レスポンスを受信する。認可レスポンスには、アクセストークン、及びリフレッシュトークン、を取得するために必要な認可コード、が含まれる。認可コードは、トークン取得情報の一例である。
アクセストークンは、第１のリソースに対するアクセス権限を示す情報である。アクセストークンは、トークンの一例である。
リフレッシュトークンは、アクセストークンの有効期限が切れた際、アクセストークンを更新するために必要な情報である。リフレッシュトークンは、トークン取得情報の一例である。
また、認可サービス５０に対する認可要求において、認可コード取得部３０９は、認可サービス５０に登録された通信装置を示すクライアント識別子を、パラメタとして指定する。本実施形態において、認可コード取得部３０９が、第１の通信装置１０を示す第１のクライアント識別子を指定して第１の認可を要求した場合、認可コード取得部３０９は、認可サービス５０から、第１の認可コードを取得する。同様に、認可コード取得部３０９が、第２の通信装置２０を示す第２のクライアント識別子を指定して第２の認可を要求した場合、認可コード取得部３０９は、認可サービス５０から、第２の認可コードを取得する。
【００１９】
認可コード送信部３１０は、第２の通信装置２０に対して、認可コード取得部３０９において取得した認可コードを送信する。
送信判断部３１１は、第２の通信装置２０に、アクセストークン、リフレッシュトークン、又は認可コードを送信するか否かを判断する。本実施形態において、送信判断部３１１は、通信判断部３０７によって、第２の通信装置２０との無線通信が一時的である、と判断した場合、第２の通信装置２０に、第１のアクセストークンを送信する、と判断する。一方、送信判断部３１１は、通信判断部３０７によって、第２の通信装置２０との無線通信が一時的でない、と判断した場合、第２の通信装置２０に、第２の認可コードを送信する、と判断する。
なお、これに限らず、送信判断部３１１は、第２の通信装置２０との無線通信が一時的でない場合、第２の通信装置２０に、第２のアクセストークン、及び第２のリフレッシュトークンを送信する、と判断しても良い。
【００２０】
トークン取得部３１２は、認可サービス５０から、アクセストークン、及びリフレッシュトークン、を取得する。本実施形態において、トークン取得部３１２は、認可サービス５０に対して、ＯＡｕｔｈ  ２．０に基づくアクセストークンリクエストを送信する。そして、トークン取得部３１２は、認可サービス５０から、前記アクセストークンリクエストに対する応答として、ＯＡｕｔｈ  ２．０に基づくアクセストークンレスポンスを受信する。アクセストークンレスポンスには、アクセストークン、リフレッシュトークン、トークン種別、アクセストークンの有効期限、が含まれる。
また、トークン取得部３１２は、前記アクセストークンリクエストを送信する際、認可コード取得部３０９において取得した認可コード、及び認可コードを取得する際に指定したクライアント識別子をパラメタとして指定する。アクセストークンリクエストにおいて、トークン取得部３１２が、第１の認可コードを指定した場合、トークン取得部３１２は、認可サービス５０から、第１のアクセストークン、及び第１のリフレッシュトークンを取得する。同様に、トークン取得部３１２が、第２の認可コードを指定した場合、トークン取得部３１２は、認可サービス５０から、第２のアクセストークン、及び第２のリフレッシュトークンを取得する。なお、本実施形態において、第１のアクセストークン、及び第２のアクセストークンの有効期限、及びアクセス権限の範囲は同じとする。
【００２１】
トークン送信部３１３は、第２の通信装置２０に対して、トークン取得部３１２において取得したアクセストークン、及び／又はリフレッシュトークン、を送信する。
無効判断部３１４は、アクセストークン、又はリフレッシュトークン、又は認可コード、を無効化するか否か、を判断する。本実施形態において、通信判断部３０７によって、第２の通信装置２０との無線通信を継続しない、と判断した場合、無効判断部３１４は、アクセストークン、又はリフレッシュトークン、又は認可コードを無効化する、と判断する。
トークン無効部３１５は、認可サービス５０に対して、アクセストークン、又はリフレッシュトークンの無効化を要求する。本実施形態において、トークン無効部３１５は、認可サービス５０に対して、ＯＡｕｔｈ  ２．０に基づくアクセストークン無効リクエストを送信する。
また、トークン無効部３１５は、アクセストークン、又はリフレッシュトークンの無効化する際、認可コード取得部３０９、又はトークン取得部３１２において指定した同一のクライアント識別子を指定する。
なお、本実施形態において、トークン無効部３１５は、認可サービス５０に対して、アクセストークン、又はリフレッシュトークンを無効化するとしたが、これに限らず、認可コードを無効化しても良い。
【００２２】
トークン更新部３１６は、アクセストークンの有効期限が切れた場合、対応するリフレッシュトークンに基づき、認可サービス５０から、更新されたアクセストークンを取得する。本実施形態において、トークン更新部３１６は、認可サービス５０に対して、ＯＡｕｔｈ  ２．０に基づくアクセストークン更新リクエストを送信する。トークン更新部３１６は、前記アクセストークン更新リクエストを送信する際、リフレッシュトークンをパラメタとして渡す。そして、トークン更新部３１６は、認可サービス５０から、前記アクセストークン更新リクエストに対する応答として、ＯＡｕｔｈ  ２．０に基づくアクセストークン更新レスポンスを受信する。アクセストークン更新レスポンスには、更新されたアクセストークン、リフレッシュトークン、トークン種別、アクセストークンの有効期限、が含まれる。
なお、トークン更新部３１６は、アクセストークンを更新する際、トークン取得部３１２においてアクセストークンを取得する際に指定した同一のクライアント識別子を指定する。
リソース取得部３１７は、外部サービス６０から、第１のリソースを取得する。本実施形態において、リソース取得部３１７は、外部サービス６０に対して、第１のリソースの取得要求を送信する際、第１のアクセストークン、又は第２のアクセストークンを指定する。
【００２３】
図４は、無線パラメタ１１のデータ構成の一例を示す図である。
ＳＳＩＤ４０１は、第１の通信装置１０、又は第２の通信装置２０、又は無線ＡＰ３０を示す無線通信に関する識別子である。
暗号化方式４０２は、暗号化通信方式を示す情報である。
暗号化鍵４０３は、暗号化通信を実施する際の鍵情報である。
Ｗｉ−Ｆｉ  Ｄｉｒｅｃｔ情報４０４は、Ｗｉ−Ｆｉ  Ｄｉｒｅｃｔによる無線通信接続に必要な情報である。より具体的には、グループ形態種別（一時的、永続的）、Ｐ２ＰグループＩＤ等である。
【００２４】
図５は、第１の通信装置１０が、第２の通信装置２０と無線通信接続する際の情報処理の一例を示すシーケンス図である。なお、図５における無線パラメタ１１は、実際には、第一の通信装置１０内の補助記憶装置２０４に記憶されている。
Ｍ５０１において、第１の通信装置１０は、操作制御部３０４によって、ユーザによるＷｉ−Ｆｉ  Ｄｉｒｅｃｔのプッシュボタン方式による無線接続開始指示を検知する。
Ｍ５０２において、第２の通信装置２０は、操作制御部３０４によって、ユーザによるＷｉ−Ｆｉ  Ｄｉｒｅｃｔのプッシュボタン方式による無線接続開始指示を検知する。
Ｍ５０３において、第１の通信装置１０は、通信制御部３０２によって、第２の通信装置２０を発見する。
Ｍ５０４において、第１の通信装置１０は、通信制御部３０２によって、第２の通信装置２０との間で、Ｗｉ−Ｆｉ  Ｄｉｒｅｃｔによる無線パラメタ１１の交換を行う。
Ｍ５０５において、第１の通信装置１０は、通信制御部３０２によって、第２の通信装置２０から取得した無線パラメタ１１を用いて、第２の通信装置２０とＷｉ−Ｆｉ  Ｄｉｒｅｃｔによる無線通信接続を確立する。
Ｍ５０６において、第１の通信装置１０は、無線パラメタ管理部３０６によって、第２の通信装置２０から取得した無線パラメタ１１を記憶する。
【００２５】
図６は、第１の通信装置１０が、第２の通信装置２０に、第２のアクセストークンを送信する際の情報処理の一例を示すシーケンス図である。なお、本実施形態において、図６は、第１の通信装置１０と第２の通信装置２０との無線通信が一時的でない場合を想定する。
Ｍ６０１において、第２の通信装置２０は、権限管理部３０８によって、第１の通信装置１０に対して、外部サービス６０上の第１のリソースに対するアクセス権限の権限委譲を要求する。
Ｍ６０２において、第１の通信装置１０は、送信判断部３１１によって、第２の通信装置２０に第１のアクセストークンを送信するか、又は第２の認可コードを送信するか、を判断する。本実施形態において、送信判断部３１１は、第２の通信装置２０との無線通信が一時的でない、と判断し、第２の通信装置２０に第２の認可コードを送信する、と判断する。
Ｍ６０３において、第１の通信装置１０は、認可コード取得部３０９によって、認可サービス５０に対して、第２のクライアント識別子を指定して、外部サービス６０上の第１のリソースに対するアクセス権限の第２の認可を要求する。
【００２６】
Ｍ６０４において、認可サービス５０は、第１の通信装置１０に対して、第２の認可承認を要求する。
Ｍ６０５において、第１の通信装置１０は、認可サービス５０に対して、第２の認可承認を許可する。
Ｍ６０６において、認可サービス５０は、第１の通信装置１０に対して、第２の認可コードを送信する。
Ｍ６０７において、第１の通信装置１０は、認可コード送信部３１０によって、Ｍ６０６で、認可サービス５０から取得した第２の認可コードを、第２の通信装置２０に送信する。一方、第２の通信装置２０は、認可コード取得部３０９によって、第１の通信装置１０から、第２の認可コードを受信する。
Ｍ６０８において、第２の通信装置２０は、トークン取得部３１２によって、認可サービス５０に対して、第２の認可コード、及び第２のクライアント識別子を指定して、第２のアクセストークンを要求する。
Ｍ６０９において、認可サービス５０は、第２の通信装置２０に対して、第２の認可コードに基づく、第２のアクセストークン、及び第２のリフレッシュトークンを送信する。
【００２７】
図７は、第１の通信装置１０が、第２の通信装置２０に、第１のアクセストークンを送信する際の情報処理の一例を示すシーケンス図である。なお、本実施形態において、図７は、第１の通信装置１０と第２の通信装置２０との無線通信が一時的である場合を想定する。
Ｍ７０１において、第２の通信装置２０は、権限管理部３０８によって、第１の通信装置１０に対して、外部サービス６０上の第１のリソースに対するアクセス権限の権限委譲を要求する。
Ｍ７０２において、第１の通信装置１０は、送信判断部３１１によって、第２の通信装置２０に第１のアクセストークンを送信するか、又は第２の認可コードを送信するか、を判断する。本実施形態において、送信判断部３１１は、第２の通信装置２０との無線通信が一時的である、と判断し、第２の通信装置２０に第１のアクセストークンを送信する、と判断する。
Ｍ７０３において、第１の通信装置１０は、認可コード取得部３０９によって、認可サービス５０に対して、第１のクライアント識別子を指定して、外部サービス６０上の第１のリソースに対するアクセス権限の第１の認可を要求する。
【００２８】
Ｍ７０４において、認可サービス５０は、第１の通信装置１０に対して、第１の認可承認を要求する。
Ｍ７０５において、第１の通信装置１０は、認可サービス５０に対して、第１の認可承認を許可する。
Ｍ７０６において、認可サービス５０は、第１の通信装置１０に対して、第１の認可コードを送信する。
Ｍ７０７において、第１の通信装置１０は、トークン取得部３１２によって、認可サービス５０に対して、第１の認可コード、及び第１のクライアント識別子を指定して、第１のアクセストークンを要求する。
Ｍ７０８において、認可サービス５０は、第１の通信装置１０に対して、第１の認可コードに基づく、第１のアクセストークン、及び第１のリフレッシュトークンを送信する。
Ｍ７０９において、第１の通信装置１０は、トークン送信部３１３によって、Ｍ７０８で、認可サービス５０から取得した第１のアクセストークンを、第２の通信装置２０に送信する。一方、第２の通信装置２０は、トークン取得部３１２によって、第１の通信装置１０から、第１のアクセストークンを受信する。
【００２９】
図８は、第２の通信装置２０が、第１のリソースを取得する際の情報処理の一例を示すシーケンス図である。なお、本実施形態において、図８における第２の通信装置２０は、図６に示す通り、第２のアクセストークン、及び第２のリフレッシュトークンを取得している場合を想定する。更に、図８における第２のアクセストークンは、有効期限が切れている場合を想定する。
Ｍ８０１において、第２の通信装置２０は、リソース取得部３１７によって、外部サービス６０に対して、第２のアクセストークンを指定して、第１のリソースの取得を要求する。
Ｍ８０２において、外部サービス６０は、第２の通信装置２０に対して、第２のアクセストークンの有効期限が切れた旨を通知する。
【００３０】
Ｍ８０３において、第２の通信装置２０は、トークン更新部３１６によって、認可サービス５０に対して、第２のリフレッシュトークン、及び第２のクライアント識別子を指定して、第２のアクセストークンの更新を要求する。
Ｍ８０４において、認可サービス５０は、第２の通信装置２０に対して、更新された第２のアクセストークン、及びリフレッシュトークンを送信する。
Ｍ８０５において、第２の通信装置２０は、リソース取得部３１７によって、外部サービス６０に対して、更新された第２のアクセストークンを指定して、第１のリソースの取得を要求する。
Ｍ８０６において、外部サービス６０は、第２の通信装置２０に対して、第１のリソースを送信する。
【００３１】
図９は、第１の通信装置１０が、第１のアクセストークンを無効化する際の情報処理の一例を示すシーケンス図である。なお、本実施形態において、図９における第１の通信装置１０は、図７に示す通り、第２の通信装置２０に対して、第１のアクセストークンを送信している場合を想定する。
Ｍ９０１において、第１の通信装置１０は、操作制御部３０４によって、ユーザによる第２の通信装置２０から取得した無線パラメタ１１の削除指示を検知する。
Ｍ９０２において、第１の通信装置１０は、無線パラメタ管理部３０６によって、無線パラメタ１１を削除する。
Ｍ９０３において、第１の通信装置１０は、無効判断部３１４によって、第２の通信装置２０に送信した第１のアクセストークン、又は第２の認可コードに基づく第２のアクセストークンを無効化するか否か、を判断する。本実施形態において、Ｍ９０２において、無線パラメタ１１が削除されたため、通信判断部３０７は、第２の通信装置２０との無線通信を継続しない、と判断する。したがって、無効判断部３１４は、第１のアクセストークン、又は第２のアクセストークンを無効化する、と判断する。
【００３２】
Ｍ９０４において、第１の通信装置１０は、無効判断部３１４によって、第２の通信装置２０に対して、第２の認可コードを送信したか否か、を判断する。本実施形態において、第１の通信装置１０は、第２の通信装置２０に対して、第２の認可コードを送信していない、と判断する。
Ｍ９０５において、第１の通信装置１０は、トークン無効部３１５によって、認可サービス５０に対して、第１のクライアント識別子を指定して、第１のアクセストークンの無効化を要求する。
Ｍ９０６において、認可サービス５０は、第１の通信装置１０に対して、第１のアクセストークンの無効化要求の結果を送信する。
【００３３】
図１０は、第１の通信装置１０が、アクセストークン、又は認可コードを送信する動作の手順を示すフローチャートである。
ステップＳ１１０１において、権限管理部３０８は、第２の通信装置２０から、外部サービス６０上の第１のリソースに対するアクセス権限の権限委譲の要求を受信したか否か、を判断する。権限委譲要求を受信した場合（Ｓ１１０１；ＹＥＳ）、権限管理部３０８は、ステップＳ１１０２に処理を進める。一方、権限委譲要求を受信していない場合（Ｓ１１０１；ＮＯ）、権限管理部３０８は、処理を終了する。
ステップＳ１２０２において、通信判断部３０７は、第２の通信装置２０との無線通信が一時的か否か、を判断する。一時的であると判断した場合（Ｓ１１０２；ＹＥＳ）、送信判断部３１１は、第２の通信装置２０に対して、第１のアクセストークンを送信すると判断し、ステップＳ１１０３に処理を進める。一方、一時的でないと判断した場合（Ｓ１１０２；ＮＯ）、送信判断部３１１は、第２の通信装置２０に対して、第２の認可コードを送信すると判断し、ステップＳ１１０８に処理を進める。
【００３４】
ステップＳ１１０３において、認可コード取得部３０９は、認可サービス５０に対して、第１のクライアント識別子を指定して、外部サービス６０上の第１のリソースに対するアクセス権限の第１の認可を要求する。
ステップＳ１１０４において、認可コード取得部３０９は、認可サービス５０からの第１の認可承認の要求に対して、第１の認可承認を許可する。
ステップＳ１１０５において、認可コード取得部３０９は、認可サービス５０から第１の認可コードを取得する。
ステップＳ１１０６において、トークン取得部３１２は、認可サービス５０に対して、第１の認可コード、及び第１のクライアント識別子を指定して、第１のアクセストークンを要求する。そして、トークン取得部３１２は、認可サービス５０から、第１のアクセストークン、及び第１のリフレッシュトークンを取得する。
ステップＳ１１０７において、トークン送信部３１３は、第２の通信装置２０に対して、第１のアクセストークンを送信し、処理を終了する。
【００３５】
ステップＳ１１０８において、認可コード取得部３０９は、認可サービス５０に対して、第２のクライアント識別子を指定して、外部サービス６０上の第１のリソースに対するアクセス権限の第２の認可を要求する。
ステップＳ１１０９において、認可コード取得部３０９は、認可サービス５０からの第２の認可承認の要求に対して、第２の認可承認を許可する。
ステップＳ１１１０において、認可コード取得部３０９は、認可サービス５０から第２の認可コードを取得する。
ステップＳ１１１１において、認可コード送信部３１０は、第２の通信装置２０に対して、第２の認可コードを送信し、処理を終了する。
【００３６】
図１１は、第２の通信装置２０が、リソースを取得する動作の手順を示すフローチャートである。
ステップＳ１２０１において、リソース取得部３１７は、外部サービス６０に対して、所有するアクセストークンを指定して、第１のリソース取得を要求する。本実施形態において、第２の通信装置２０が所有するアクセストークンは、第１のアクセストークンか、第２のアクセストークンの何れかである。
ステップＳ１２０２において、リソース取得部３１７は、外部サービス６０から第１のリソースを取得できたか否か、を判断する。リソースを取得できた場合（Ｓ１２０２；ＹＥＳ）、リソース取得部３１７は、リソース取得に成功したとして、処理を終了する。一方、リソースを取得できなかった場合（Ｓ１２０２；ＮＯ）、リソース取得部３１７は、ステップＳ１２０３に処理を進める。
ステップＳ１２０３において、トークン更新部３１６は、所有するアクセストークンの有効期限が切れたか否か、を判断する。本実施形態において、トークン更新部３１６は、ステップＳ１２０１での第１のリソース取得において、外部サービス６０からの応答に、アクセストークンの有効期限が切れた旨を示す情報が有るか否かで判断する。アクセストークンの有効期限が切れた場合（Ｓ１２０３；ＹＥＳ）、トークン更新部３１６は、ステップＳ１２０４に処理を進める。一方、アクセストークンの有効期限が切れていない場合（Ｓ１２０３；ＮＯ）、トークン更新部３１６（又はリソース取得部３１７）は、リソース取得に失敗したとして、処理を終了する。
【００３７】
ステップＳ１２０４において、トークン更新部３１６は、ステップＳ１２０３において有効期限が切れたと判断したアクセストークンを更新するためのリフレッシュトークンを保持しているか否か、を判断する。リフレッシュトークンを保持している場合（ステップＳ１２０４；ＹＥＳ）、トークン更新部３１６は、ステップＳ１２０５に処理を進める。一方、リフレッシュトークンを保持していない場合（Ｓ１２０４；ＮＯ）、トークン更新部３１６（又はリソース取得部３１７）は、リソース取得に失敗したとして、処理を終了する。
ステップＳ１２０５において、トークン更新部３１６は、認可サービス５０に対して、リフレッシュトークン、及びクライアント識別子を指定して、有効期限が切れたアクセストークンの更新を要求する。
ステップＳ１２０６において、トークン更新部３１６は、認可サービス５０から、更新されたアクセストークンを取得できたか否か、を判断する。更新されたアクセストークンを取得できた場合（Ｓ１２０６；ＹＥＳ）、再度、外部サービス６０から第１のリソースを取得するために、トークン更新部３１６は、ステップＳ１２０１処理を戻す。一方、更新されたアクセストークンを取得できなかった場合（Ｓ１２０６；ＮＯ）、トークン更新部３１６（又はリソース取得部３１７）は、リソース取得に失敗したとして、処理を終了する。
【００３８】
図１２は、第１の通信装置１０が、アクセストークンを無効化する動作の手順を示すフローチャートである。
ステップＳ１３０１において、通信判断部３０７は、無線パラメタ管理部３０６によって、第２の通信装置２０から取得した無線パラメタ１１が削除されたか否か、を判断する。無線パラメタを削除された場合（Ｓ１３０１；ＹＥＳ）、通信判断部３０７は、第２の通信装置２０との無線通信を継続しない、と判断し、ステップＳ１３０２に処理を進める。一方、無線パラメタを削除されていない場合（Ｓ１３０１；ＮＯ）、通信判断部３０７は、第２の通信装置２０との無線通信を継続する、と判断し、処理を終了する。
【００３９】
ステップＳ１３０２において、無効判断部３１４は、第２の通信装置２０に対して、第２の認可コードを送信したか否か、を判断する。第２の認可コードを送信した場合（ステップＳ１３０２；ＹＥＳ）、無効判断部３１４は、第２のアクセストークン、及び第２のリフレッシュトークンを無効化する、と判断し、ステップＳ１３０４に処理を進める。一方、第２の認可コードを送信していない場合（ステップＳ１３０２；ＮＯ）、無効判断部３１４は、第１のアクセストークンを無効化する、と判断し、ステップＳ１３０３に処理を進める。
ステップＳ１３０３において、トークン無効部３１５は、認可サービス５０に対して、第１のクライアント識別子を指定して、第１のアクセストークンの無効化を要求し、処理を終了する。
ステップＳ１３０４において、トークン無効部３１５は、認可サービス５０に対して、第２のクライアント識別子を指定して、第２のアクセストークン、及び第２のリフレッシュトークンの無効化を要求し、処理を終了する。
【００４０】
図１３Ａは、第１の通信装置１０が、認可サービス５０へ送信する認可リクエストの例を示す図である。
認可リクエスト１４００は、ＯＡｕｔｈ  ２．０に基づく認可リクエストを示すＨＴＴＰリクエストメッセージである。
認可リクエストヘッダ１４０１は、認可リクエスト１４００中のＨＴＴＰリクエストヘッダである。パラメタｒｅｓｐｏｎｓｅ＿ｔｙｐｅは、認可リクエストに対応する認可レスポンスの種別を示し、パラメタ値ｃｏｄｅは認可コードを示す。パラメタｃｌｉｅｎｔ＿ｉｄは、クライアント識別子を示す。
図１３Ｂは、第１の通信装置１０が、認可サービス５０から受信する認可レスポンスの例を示す図である。
認可レスポンス１５００は、ＯＡｕｔｈ  ２．０に基づく認可レスポンスを示すＨＴＴＰレスポンスメッセージである。
認可レスポンスヘッダ１５０１は、認可レスポンス１５００中のＨＴＴＰレスポンスヘッダである。パラメタｃｏｄｅは、認可コードを示す。そして、そのパラメタ値は、実際の認可コードの値を示す。
【００４１】
図１４Ａは、第１の通信装置１０が、認可サービス５０へ送信するアクセストークンリクエストの例を示す図である。
アクセストークンリクエスト１６００は、ＯＡｕｔｈ  ２．０に基づくアクセストークンリクエストを示すＨＴＴＰリクエストメッセージである。
アクセストークンリクエストヘッダ１６０１は、アクセストークンリクエスト１６００中のＨＴＴＰリクエストヘッダである。ヘッダＡｕｔｈｏｒｉｚａｔｉｏｎ中のスキームＢａｓｉｃは、当該アクセストークンリクエストがＨＴＴＰベーシック認証であることを示す。本実施形態において、ＨＴＴＰベーシック認証のユーザＩＤとして、当該アクセストークンリクエストにおいて指定すべきクライアント識別子が用いられる。
アクセストークンリクエストボディ１６０２は、アクセストークンリクエスト１６００中のＨＴＴＰリクエストボディである。パラメタｇｒａｎｔ＿ｔｙｐｅは、認可グラント種別を示し、パラメタ値ａｕｔｈｏｒｉｚａｔｉｏｎ＿ｃｏｄｅは、認可コードに基づくアクセストークンリクエストであることを示す。パラメタｃｏｄｅは、認可コードを示す。そして、そのパラメタ値は、実際の認可コードの値を示す。
【００４２】
図１４Ｂは、第１の通信装置１０が、認可サービス５０から受信するアクセストークンレスポンスの例を示す図である。
アクセストークンレスポンス１７００は、ＯＡｕｔｈ  ２．０に基づくアクセストークンレスポンスを示すＨＴＴＰレスポンスメッセージである。
アクセストークンレスポンスヘッダ１７０１は、アクセストークンレスポンス１７００中のＨＴＴＰレスポンスヘッダである。
アクセストークンレスポンスボディ１７０２は、アクセストークンレスポンス１７００中のＨＴＴＰレスポンスボディである。パラメタａｃｃｅｓｓ＿ｔｏｋｅｎは、アクセストークンを示す。そして、そのパラメタ値は、実際のアクセストークンの値を示す。パラメタｔｏｋｅｎ＿ｔｙｐｅは、アクセストークンの種別を示す。パラメタｅｘｐｉｒｅｓ＿ｉｎは、アクセストークンの有効期限を示す。そして、そのパラメタ値は、実際の有効期限の値を秒単位で示す。パラメタｒｅｆｒｅｓｈ＿ｔｏｋｅｎは、リフレッシュトークンを示す。そして、そのパラメタ値は、実際のリフレッシュトークンの値を示す。
【００４３】
図１５Ａは、第２の通信装置２０が、認可サービス５０へ送信するアクセストークン更新リクエストの例を示す図である。
アクセストークン更新リクエスト１８００は、ＯＡｕｔｈ  ２．０に基づくアクセストークン更新リクエストを示すＨＴＴＰリクエストメッセージである。
アクセストークン更新リクエストヘッダ１８０１は、アクセストークン更新リクエスト１８００中のＨＴＴＰリクエストヘッダである。ヘッダＡｕｔｈｏｒｉｚａｔｉｏｎ中のスキームＢａｓｉｃは、当該アクセストークンリクエストがＨＴＴＰベーシック認証であることを示す。本実施形態において、ＨＴＴＰベーシック認証のユーザＩＤとして、当該アクセストークン更新リクエストにおいて指定すべきクライアント識別子が用いられる。
アクセストークン更新リクエストボディ１８０２は、アクセストークン更新リクエスト１８００中のＨＴＴＰリクエストボディである。パラメタｇｒａｎｔ＿ｔｙｐｅは、認可グラント種別を示す。パラメタ値ｒｅｆｒｅｓｈ＿ｔｏｋｅｎは、リフレッシュトークンに基づくアクセストークン更新リクエストであることを示す。パラメタｒｅｆｒｅｓｈ＿ｔｏｋｅｎは、リフレッシュトークンを示す。そして、そのパラメタ値は、更新対象となる実際のリフレッシュトークンの値を示す。
【００４４】
図１５Ｂは、第２の通信装置２０が、認可サービス５０から受信するアクセストークン更新レスポンスの例を示す図である。
アクセストークン更新レスポンス１９００は、ＯＡｕｔｈ  ２．０に基づくアクセストークン更新レスポンスを示すＨＴＴＰレスポンスメッセージである。
アクセストークン更新レスポンスヘッダ１９０１は、アクセストークン更新レスポンス１９００中のＨＴＴＰレスポンスヘッダである。
アクセストークン更新レスポンスボディ１９０２は、アクセストークン更新レスポンス１９００中のＨＴＴＰレスポンスボディである。パラメタａｃｃｅｓｓ＿ｔｏｋｅｎは、アクセストークンを示す。そして、そのパラメタ値は、実際のアクセストークンの値を示す。パラメタｔｏｋｅｎ＿ｔｙｐｅは、アクセストークンの種別を示す。パラメタｅｘｐｉｒｅｓ＿ｉｎは、アクセストークンの有効期限を示す。そして、そのパラメタ値は、実際の有効期限の値を秒単位で示す。パラメタｒｅｆｒｅｓｈ＿ｔｏｋｅｎは、リフレッシュトークンを示す。そして、そのパラメタ値は、実際のリフレッシュトークンの値を示す。
【００４５】
図１６Ａは、第１の通信装置１０が、認可サービス５０へ送信するアクセストークン無効リクエストの例を示す図である。
アクセストークン無効リクエスト２０００は、ＯＡｕｔｈ  ２．０に基づくアクセストークン無効リクエストを示すＨＴＴＰリクエストメッセージである。
アクセストークン無効リクエストヘッダ２００１は、アクセストークン無効リクエスト２０００中のＨＴＴＰリクエストヘッダである。ヘッダＡｕｔｈｏｒｉｚａｔｉｏｎ中のスキームＢａｓｉｃは、当該アクセストークンリクエストがＨＴＴＰベーシック認証であることを示す。本実施形態において、ＨＴＴＰベーシック認証のユーザＩＤとして、当該アクセストークン無効リクエストにおいて指定すべきクライアント識別子が用いられる。
アクセストークン無効リクエストボディ２００２は、アクセストークン無効リクエスト２０００中のＨＴＴＰリクエストボディである。パラメタｔｙｐｅは、アクセストークンを示す。そして、そのパラメタ値は、無効化対象となる実際のアクセストークンの値を示す。
【００４６】
図１６Ｂは、第１の通信装置１０が、認可サービス５０から受信するアクセストークン無効レスポンスの例を示す図である。
アクセストークン無効レスポンス２１００は、ＯＡｕｔｈ  ２．０に基づくアクセストークン無効レスポンスを示すＨＴＴＰレスポンスメッセージである。
アクセストークン無効レスポンスヘッダ２１０１は、アクセストークン無効レスポンス２１００中のＨＴＴＰレスポンスヘッダである。
【００４７】
以上、説明したように、第１の通信装置１０は、第２の通信装置２０からの権限委譲要求に対して、第２の通信装置２０との無線通信接続か一時的か否か、を判断する。もし、無線通信接続が一時的な場合、第１の通信装置１０は、第２の通信装置２０に対して、トークン取得情報の一つである第２の認可コードを送信せず、第１のアクセストークンのみを送信する。
第２の通信装置２０は、第２の認可コードがなければ、認可サービス５０から、第２のリフレッシュトークンを取得することができない。第２の通信装置２０は、第２のリフレッシュトークンがなければ、アクセストークンの有効期限が切れた場合に、アクセストークンを更新できない。もし、アクセストークンの有効期限が切れた場合、第２の通信装置２０は、外部サービス６０上の第１のリソースを取得できない。結果的に、第１の通信装置１０は、第２の通信装置２０に対して、一時的なアクセス権限の委譲が可能となる。
これによって、第１の通信装置１０は、ユーザによる明示的な有効期限やアクセス権限の範囲の指定といったアクセス権限の委譲に伴う煩雑な操作を簡略化することができ、ユーザの利便性が向上する。更に、第１の通信装置１０は、ユーザの操作ミスによって、一時的ではない永続的なアクセス権限の委譲が指定されてしまうことを防ぐことができ、セキュリティ上のリスクも軽減する。
【００４８】
一方、無線通信接続が一時的でない場合、第１の通信装置１０は、第２の通信装置２０に対して、第２の認可コードを送信する。第２の通信装置２０は、第１の通信装置１０から、第２の認可コードを取得した後、認可サービス５０から、第２の認可コードに基づいて、第２のアクセストークン、及び第２のリフレッシュトークンを取得する。第２の通信装置２０は、第２のリフレッシュトークンを保持していれば、第２のアクセストークンの有効期限が切れた場合でも、第２のアクセストークンを更新することができる。結果的に、第１の通信装置１０は、第２の通信装置２０に対して、一時的ではない永続的なアクセス権限の委譲が可能となる。
これによって、第１の通信装置１０は、ユーザによる明示的な有効期限や権限範囲の指定といったアクセス権限の委譲に伴う煩雑な操作を簡略化することができ、ユーザの利便性が向上する。
更に、本実施形態において、第１のアクセストークンと第２のアクセストークンの有効期限、及びアクセス権限の範囲は同じとしたが、これに限らず、有効期限を別にしても良い。例えば、第１のアクセストークンの有効期限を、第２のアクセストークンより短くしても良い。また、第１のアクセストークンのアクセス権限の範囲を、第２のアクセストークンより狭くしても良い。これによって、第１の通信装置１０は、第２の通信装置２０に対して、更に限定的なアクセス権限の委譲が可能となり、ユーザの利便性が更に向上し、セキュリティ上のリスクが更に軽減する。
【００４９】
また通常、ＯＡｕｔｈ  ２．０における第２の認可要求の内容は、ステップＳ１１０１において、第２の通信装置２０から受信した権限委譲要求に含まれている。第１の通信装置１０は、ＨＴＴＰリダイレクト等の手法を用いて、第２の認可要求を、認可サービス５０にそのまま送信する。つまり、第２の認可要求は、第２の通信装置２０が希望する内容であり、第２の通信装置２０にとって都合の良い内容となるため、必要以上に広範囲なアクセス権限を与えてしまう可能性がある。
それに対して、本実施形態では、ステップＳ１１０２において、第２の通信装置２０との無線通信が一時的である場合、送信判断部３１１は、第２の通信装置２０に対して、第１のアクセストークンを送信すると判断する。そして、ステップＳ１１０３において、認可コード取得部３０９は、認可サービス５０に対して、第１のクライアント識別子を指定して、外部サービス６０上の第１のリソースに対するアクセス権限の第１の認可を要求する。つまり、第１の認可要求の内容は、第１の通信装置１０が決定するため、必要十分な最小限の範囲のアクセス権限を指定することができ、ユーザの利便性が更に向上し、セキュリティ上のリスクが更に軽減する。
【００５０】
更に、本実施形態における認可サービス５０には、ＯＡｕｔｈ  ２．０において推奨されている次の２つの制限を想定する。
１つ目は、認可サービス５０に対する認可要求、アクセストークン取得、及びアクセストークン更新において、指定するクライアント識別子は、すべて同一である必要がある。例えば、認可サービス５０に対して、第２のクライアント識別子を指定して、第２の認可要求を行った場合、第２のアクセストークン取得、及び第２のアクセストークン更新でも、第２のクライアント識別子を指定する必要がある。
２つ目は、認可サービス５０に対するアクセストークン取得、及びアクセストークン更新において、指定したクライアント識別子に関するクライアント認証が必要となる。そのため、第１の通信装置１０は、認可サービス５０に対して、第２のクライアント識別子を指定して、第２のアクセストークン取得を要求しても、クライアント認証に失敗し、第２のアクセストークンを取得することができない。逆に、第２の通信装置２０は、たとえ第１の通信装置１０から第１の認可コードを取得しても、認可サービス５０から、第１のアクセストークンを取得することができない。
これに対して、第１の通信装置１０は、第２の通信装置２０との無線通信が一時的な場合、ステップＳ１１０６〜ステップＳ１１０７において、自身で第１のアクセストークンを取得して送信する。一方、無線通信が一時的でない場合、第２の通信装置２０に第２のアクセストークンを更新させるため、第１の通信装置１０は、第２の認可コードをそのまま送信する。これによって、第１の通信装置１０は、認可サービス５０との相互接続性を向上することができる。
【００５１】
一方、以上の制限がない認可サービス５０に対しては、第１の通信装置１０は、第２の通信装置２０に代わって、第２のアクセストークン、第２のリフレッシュトークンを、直接、取得しても良い。この場合、ステップＳ１１１１において、トークン送信部３１３は、第２の通信装置２０に対して、第２のアクセストークン、第２のリフレッシュトークンを送信する。これによって、第２の通信装置２０の処理負荷を軽減することができる。
更に、例えば、ステップＳ１１０２において、第２の通信装置２０との無線通信が一時的でない場合、送信判断部３１１は、第２の通信装置２０に対して、第２の認可コードを送信した場合を想定する。このとき、第２の通信装置２０は、第２の認可コードに基づき、認可サービス５０から、第２のリフレッシュトークンを取得することができるため、第１のリソースに対する永続的なアクセス権限を持つことになる。その後、第１の通信装置１０のユーザが、第２の通信装置２０との無線通信を今後行わないと考え、第２の通信装置２０との無線通信で使用していた無線パラメタ１１を削除したとする。
このとき、本実施形態において、通信判断部３０７は、無線パラメタ管理部３０６によって、第２の通信装置２０から取得した無線パラメタ１１が削除された場合、第２の通信装置２０との無線通信を継続しない、と判断する。そして、無効判断部３１４は、第２の通信装置２０に対して委譲していたアクセストークンを無効化する、と判断し、認可サービス５０に対して、アクセストークン無効化を要求する。
これによって、第１の通信装置１０は、ユーザによるアクセス権限の無効化に伴う煩雑な操作を簡略化することができ、ユーザの利便性が向上する。更に、第１の通信装置１０は、ユーザの操作忘れによって、いつまでもアクセス権限が委譲したままにすることを防ぐことができ、セキュリティ上のリスクも軽減する。
【００５２】
更に、本実施形態において、通信判断部３０７は、第２の通信装置２０との無線通信が一時的か否か、を判断していたが、これに限らず、他の通信方式において一時的か否か、を判断しても良い。例えば、公衆無線通信、近接無線通信、ＮＦＣ（Ｎｅａｒ  Ｆｉｅｌｄ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、有線通信、遠隔通信、リモートアクセス等でも良い。
同様に、通信判断部３０７は、第２の通信装置２０から取得した無線パラメタ１１が削除された場合、第２の通信装置２０との無線通信を継続しない、と判断したが、これに限らない。例えば、通信パラメタ、通信情報等、第２の通信装置２０との通信接続に用いる情報等でも良い。
【００５３】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００５４】
以上、上述した各実施形態においては、通信装置間の通信接続が一時的な場合、第１の通信装置は、第２の通信装置に、トークン取得情報を送信しない。一方、通信接続が一時的でない場合、つまり永続的な通信接続の場合、第１の通信装置は、第２の通信装置に、トークン取得情報を送信する。
これによって、アクセス権限の委譲に伴う煩雑なユーザ操作を簡単化する事ができ、ユーザの利便性が向上する。更に、ユーザの操作ミスに伴うセキュリティ上のリスクも軽減する。
【００５５】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００５６】
３０６  無線パラメタ管理部、３０７  通信判断部、３０８  権限管理部、３０９  認可コード取得部、３１０  認可コード送信部、３１１  送信判断部、３１２  トークン取得部、３１３  トークン送信部、３１４  無効判断部、３１５  トークン無効部、３１６  トークン更新部、３１７  リソース取得部
【図１】
2014102561.tif 000003
【図２】
2014102561.tif 000004
【図３】
2014102561.tif 000005
【図４】
2014102561.tif 000006
【図５】
2014102561.tif 000007
【図６】
2014102561.tif 000008
【図７】
2014102561.tif 000009
【図８】
2014102561.tif 000010
【図９】
2014102561.tif 000011
【図１０】
2014102561.tif 000012
【図１１】
2014102561.tif 000013
【図１２】
2014102561.tif 000014
【図１３Ａ】
2014102561.tif 000015
【図１３Ｂ】
2014102561.tif 000016
【図１４Ａ】
2014102561.tif 000017
【図１４Ｂ】
2014102561.tif 000018
【図１５Ａ】
2014102561.tif 000019
【図１５Ｂ】
2014102561.tif 000020
【図１６Ａ】
2014102561.tif 000021
【図１６Ｂ】
2014102561.tif 000022