(57)【要約】【課題】対象機器が提供するリソースへのアクセスを適切に切り換える。【解決手段】本発明の実施形態としてアクセス認可装置は、通信部と、状態判定部と、アクセス代行部と、決定部とを備える。前記通信部は、ネットワークに接続された対象機器と、および前記対象機器が提供するリソースを利用可能な通信装置と通信する。前記状態判定部は、前記通信装置と前記ネットワークとの接続状態を特定するための情報を前記通信装置および前記対象機器の少なくとも一方から取得し、前記情報に基づき前記接続状態を判定する。前記アクセス代行部は、前記対象機器が提供するリソースの利用要求を前記対象機器に送信する。前記決定部は、前記接続状態に基づき、前記対象機器が提供するリソースの利用要求を前記通信装置が前記対象機器に送信するか、前記アクセス代行部が前記対象機器に送信するかを決定する。【選択図】図１
2016177795.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続された対象機器と、および前記対象機器が提供するリソースを利用可能な通信装置と通信する通信部と、
前記通信装置と前記ネットワークとの接続状態を特定するための情報を前記通信装置および前記対象機器の少なくとも一方から取得し、前記情報に基づき前記接続状態を判定する状態判定部と、
前記対象機器が提供するリソースの利用要求を前記対象機器に送信するアクセス代行部と、
前記接続状態に基づき、前記対象機器が提供するリソースの利用要求を前記通信装置が前記対象機器に送信するか、前記アクセス代行部が前記対象機器に送信するかを決定する決定部と、
を備えるアクセス認可装置。
【請求項２】
前記状態判定部は、前記通信装置が前記ネットワークに接続されているか否か、または前記ネットワークに接続可能な状態か否かを判定する
請求項１に記載のアクセス認可装置。
【請求項３】
前記決定部は、前記通信装置が前記ネットワークに接続されているまたは接続可能な状態の場合、前記通信装置から前記対象機器に前記利用要求を送信することを決定して、前記対象機器へ前記利用要求を送信することの指示情報を、前記通信装置に送信する
請求項２に記載のアクセス認可装置。
【請求項４】
前記決定部は、前記指示情報を前記通信装置に送信した後、前記通信装置から前記対象機器への前記利用要求の送信に対してエラーが発生した旨の報告を受けた場合は、前記アクセス代行部が前記利用要求を前記対象機器に送信することを決定し、
前記アクセス代行部は、前記決定部の決定に応じて、前記利用要求を前記対象機器へ送信する
請求項３に記載のアクセス認可装置。
【請求項５】
前記決定部は、前記通信装置が前記ネットワークに接続されていない場合または接続不能な状態の場合、前記アクセス代行部が前記対象機器に前記利用要求を送信することを決定し、
前記アクセス代行部は、前記決定部の決定に応じて、前記利用要求を前記対象機器へ送信する
請求項２または３に記載のアクセス認可装置。
【請求項６】
前記通信部は、前記通信装置から送信される第１要求を受信し、
前記状態判定部は、前記第１要求が受信された場合に、前記接続状態の判定を行う
請求項１ないし５のいずれか一項に記載のアクセス認可装置。
【請求項７】
前記第１要求は、前記リソースの利用に関する許可要求、または前記リソースの利用要求の少なくとも一方である
請求項６に記載のアクセス認可装置。
【請求項８】
前記許可要求に基づく前記接続状態の判定に応じて、前記通信装置が前記ネットワークに接続されていないまたは接続不能な状態と判定した場合に、前記リソースの利用要求を前記アクセス代行部が受け付けるための第１ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）に関する情報を含む第１許可応答を前記通信装置に送信し、
前記アクセス代行部は、前記通信装置からの前記第１ＡＰＩに関する情報に基づく前記リソースの利用要求を受けて、前記リソースの利用要求を前記対象機器に送信する
請求項７に記載のアクセス認可装置。
【請求項９】
前記通信装置からの前記リソースの利用要求に基づく前記接続状態の判定に応じて、前記通信装置が前記ネットワークに接続されているまたは接続可能な状態であると判定した場合に、エラー応答を前記通信装置に送信し、
前記エラー応答を送信後、前記通信装置から前記リソースの利用に関する前記許可要求を受信し、前記許可要求に基づく前記接続状態の判定に応じて、前記通信装置が前記ネットワークに接続されている場合または接続可能な状態であると判定した場合に、前記利用要求を送信することの指示情報を含む第２許可応答を前記通信装置に送信する
請求項７に記載のアクセス認可装置。
【請求項１０】
前記第２許可応答は、前記対象機器が前記リソースの利用要求を受け付けるための第２ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）に関する情報を含む
請求項９に記載のアクセス認可装置。
【請求項１１】
前記第２ＡＰＩは、ゲートウェイ装置が前記対象機器への前記リソースの利用要求を受け付けるためのＡＰＩであり、
前記通信部は、前記対象機器の代わりに、前記ゲートウェイ装置と通信する
請求項１０に記載のアクセス認可装置。
【請求項１２】
前記第２許可応答は、複数の前記第２ＡＰＩに関する情報を含み、
前記ゲートウェイ装置は複数のネットワークに接続されており、前記ネットワークごとに、受け付け可能な前記第２ＡＰＩが異なる
請求項１１に記載のアクセス認可装置。
【請求項１３】
前記通信装置からの前記リソースの利用要求に基づく前記接続状態の判定に応じて、前記通信装置が前記ネットワークに接続されているまたは接続可能な状態であると判定した場合に、複数の第２ＡＰＩに関する情報を含む応答を、前記通信装置に送信し、
前記第２ＡＰＩは、ゲートウェイ装置が前記対象機器への前記リソースの利用要求を受け付けるためのＡＰＩであり、
前記通信部は、前記対象機器の代わりに、前記ゲートウェイ装置と通信し、
前記ゲートウェイ装置は複数のネットワークに接続されており、前記ネットワークごとに、受け付け可能な前記第２ＡＰＩが異なる
請求項７に記載のアクセス認可装置。
【請求項１４】
前記状態判定部は、前記通信装置から受信する前記第１要求の送信元ＩＰアドレスが、前記対象機器に対して予め登録したＩＰアドレスに一致するか、または予め登録したＩＰアドレスの範囲に含まれるかに応じて、前記通信装置が前記ネットワークに接続されているかを判定する
請求項６ないし１３のいずれか一項に記載のアクセス認可装置。
【請求項１５】
前記状態判定部は、前記通信装置が存在する位置を特定する情報を前記通信装置から受信し、受信した情報と、前記対象機器の予め取得した位置情報とに基づいて、前記通信装置が前記ネットワークに接続可能な状態かを判定する
請求項６ないし１３のいずれか一項に記載のアクセス認可装置。
【請求項１６】
前記状態判定部が、前記通信装置が前記ネットワークに接続されているまたは接続可能であると判定した場合に、前記リソースの利用要求を受け付ける機能を有効化することの指示情報を前記対象機器に送信する
請求項１ないし１５のいずれか一項に記載のアクセス認可装置。
【請求項１７】
前記状態判定部が、前記通信装置が前記ネットワークに接続されていない場合または接続不能な状態の場合と判定した場合に、前記リソースの利用要求を受け付ける機能を無効化することの指示情報を前記対象機器に送信する
請求項１ないし１６のいずれか一項に記載のアクセス認可装置。
【請求項１８】
前記通信装置が前記ネットワークに接続されていないまたは接続不能な状態であるとの判定から、前記通信装置が前記ネットワークに接続されているまたは接続可能な状態であるとの判定に変更された場合、予め与えられたポリシー情報に基づき、前記通信装置のユーザに、変更の許諾を得る必要があるか否かを判断し、許諾を得る必要がある場合には、ユーザの許諾を示す情報を受信した後で、前記対象機器に前記リソースの利用要求を送信することの指示情報を前記通信装置に送信する
請求項１ないし１７のいずれか一項に記載のアクセス認可装置。
【請求項１９】
予め与えられたポリシー情報が前記通信装置が前記ネットワークに接続されているまたは接続可能な場合も、前記アクセス代行部がリソースの利用要求の送信を代行することを示す場合は、前記通信装置が前記ネットワークに接続されているまたは接続可能な場合も、前記アクセス代行部は前記リソースの利用要求を前記対象機器に送信する
請求項１ないし１３のいずれか一項に記載のアクセス認可装置。
【請求項２０】
前記通信部は、前記通信装置が前記ネットワークに接続されているまたは接続可能な状態であると判定された場合、前記対象機器との通信コネクションを切断する
請求項１ないし１９のいずれか一項に記載のアクセス認可装置。
【請求項２１】
ネットワークに接続された対象機器が提供するリソースを利用可能な通信装置と前記ネットワークとの接続状態を特定するための情報を前記通信装置および前記対象機器の少なくとも一方から取得し、前記情報に基づき前記接続状態を判定する状態判定ステップと、  前記接続状態に基づき、前記対象機器が提供するリソースの利用要求を前記通信装置が前記対象機器に送信するか、アクセス代行部が送信するかを決定する決定ステップと、
を備えたアクセス認可方法。
【請求項２２】
ネットワークに接続された対象機器が提供するリソースを利用可能な通信装置と前記ネットワークとの接続状態を特定するための情報を前記通信装置および前記対象機器の少なくとも一方から取得し、前記情報に基づき前記接続状態を判定する状態判定ステップと、  前記接続状態に基づき、前記対象機器が提供するリソースの利用要求を前記通信装置が前記対象機器に送信するか、アクセス代行部が送信するかを決定する決定ステップと、
をコンピュータに実行させるためのプログラム。
【請求項２３】
請求項１ないし２０のいずれか一項に記載のアクセス認可装置と、
前記対象機器および前記通信装置の少なくとも一方と
を備えた通信システム。
【請求項２４】
前記対象機器と前記通信装置の両方を備えた
請求項２３に記載の通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、アクセス認可装置、アクセス認可方法、プログラムおよび通信システムに関する。
【背景技術】
【０００２】
家電などのホームネットワーク内の機器が、スマートフォン等に搭載されたアプリケーションに対して提供するＲＥＳＴ  ＡＰＩ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）（以下、プライベートＡＰＩ）へのアクセス認可を、家電以外の機器で行う方法が知られている。アクセス認可とは、特定のアプリケーションがアクセスしてよいか否かの判断のことである。
【０００３】
一方、機器がインターネット上などの外部サーバに接続され、外部サーバ経由で当該機器の監視や制御が実現可能なシステムにおいて、外部サーバが、プライベートＡＰＩと同様のＲＥＳＴ  ＡＰＩを公開し、このＲＥＳＴ  ＡＰＩ経由で当該機器の制御を行う方法が知られている。当該外部サーバが公開するＡＰＩを以降、パブリックＡＰＩと呼ぶ。
【０００４】
上記２つのＡＰＩ（プライベートＡＰＩとパブリックＡＰＩ）が併存するケースにおいて、ユーザには両者を切り替えるメリットがある。例えば、宅内での利用時にはプライベートＡＰＩに切り換えることで、サーバに制御ログを残さなくてすむ。また、法的に切り替えを義務付けられる可能性もある。しかしながら、正当なアプリケーションにだけアクセス認可しつつ、両者をシームレスに切り替える方法は知られていない。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１４−６７９８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明の実施形態は、対象機器が提供するリソースへアクセスする手法を適切に切り替えることを目的とする。
【課題を解決するための手段】
【０００７】
本発明の実施形態としてアクセス認可装置は、通信部と、状態判定部と、アクセス代行部と、決定部とを備える。前記通信部は、ネットワークに接続された対象機器と、および前記対象機器が提供するリソースを利用可能な通信装置と通信する。前記状態判定部は、前記通信装置と前記ネットワークとの接続状態を特定するための情報を前記通信装置および前記対象機器の少なくとも一方から取得し、前記情報に基づき前記接続状態を判定する。前記アクセス代行部は、前記対象機器が提供するリソースの利用要求を前記対象機器に送信する。前記決定部は、前記接続状態に基づき、前記対象機器が提供するリソースの利用要求を前記通信装置が前記対象機器に送信するか、前記アクセス代行部が前記対象機器に送信するかを決定する。
【図面の簡単な説明】
【０００８】
【図１】第１の実施形態に関わる通信システムの構成図。
【図２】トークン記憶部に記憶された情報の例を示す図。
【図３】対象機器情報記憶部に記憶された情報の例を示す図。
【図４】第１の実施形態に係る通信シーケンスの例を示す図。
【図５】図４に続く通信シーケンスの例を示す図。
【図６】トークン発行処理のフローチャートを示す図。
【図７】第１の実施形態に係る通信システムの他の構成例を示す図。
【図８】第１の実施形態に係る通信システムの他の構成例を示す図。
【図９】第１の実施形態に係る通信システムの他の構成例を示す図。
【図１０】第２の実施形態に関わる通信システムの構成図。
【図１１】確認画面の例を示す図。
【図１２】第３の実施形態に係る通信システムの構成例を示す図。
【図１３】第３の実施形態に係る対象機器情報記憶部の構成例を示す図。
【図１４】第３の実施形態に係る動作シーケンスの例を示す図。
【図１５】第３の実施形態に係る動作シーケンスの例を示す図。
【図１６】第３の実施形態に係る動作シーケンスの例を示す図。
【図１７】第４の実施形態に係る通信システムの他の構成例を示す図。
【発明を実施するための形態】
【０００９】
以下、図面を参照しながら、本発明の実施形態について説明する。
【００１０】
（第１の実施形態）
本実施形態は、ユーザが宅外から宅内に移動すると、利用するＡＰＩを自動的にパブリックＡＰＩから、プライベートＡＰＩに切り替えるように制御することを特徴とする。以下、本実施形態について詳細に説明する。
【００１１】
図１は、本発明の第１の実施形態に関わる通信システムの構成図である。この通信システムは、アクセス認可装置１０１と、通信装置２０１と、対象機器３０１と、中継装置４０１と、第１ネットワーク５０１と、第２ネットワーク６０１とを備える。
【００１２】
第１ネットワーク５０１は、広域通信網である。本実施形態では、具体的には、インターネットを想定している。ただし、ＮＧＮ（Ｎｅｘｔ  Ｇｅｎｅｒａｔｉｏｎ  Ｎｅｔｗｏｒｋ）など、閉域網を含むその他のネットワークであっても構わない。
【００１３】
第２ネットワーク６０１は、ローカル通信網である。本実施形態では、具体的には、ホームネットワークを想定している。物理媒体は有線（Ｅｔｈｅｒｎｅｔ（登録商標）等）、無線（ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｚｉｇｂｅｅ（登録商標）等）を問わない。上位の通信プロトコルは、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）であることを想定しているが、これも本実施形態の通信シーケンスが同様に実行される限りにおいて、どのような通信プロトコルであってもよい。
【００１４】
中継装置４０１は、第１ネットワーク５０１と第２ネットワーク６０１を接続するルータである。本実施形態では、ホームネットワークとインターネットを接続する、ＮＡＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ）機能を備えたブロードバンドルータであることを想定している。
【００１５】
通信装置２０１は、エンドユーザが利用するスマートフォン、タブレット、ＰＣ等の装置である。本実施形態では、通信装置２０１はスマートフォンであることを想定している。ユーザは、宅外・宅内を問わずに、スマートフォンを携帯し、利用する。アクセス認可装置１０１が認可を与える対象は、スマートフォン上で動作するプログラムを構成要素として持つ、アプリケーションである。図１では、通信装置２０１は第１ネットワーク５０１と第２ネットワーク６０１に接続されているように描かれているが、第１ネットワーク５０１に接続されているが第２ネットワーク６０１に接続されていない状態、第１ネットワーク５０１に接続されていないが第２ネットワーク６０１に接続されている状態、両方のネットワークに接続されている状態など、種々の接続状態がある。
【００１６】
対象機器３０１は、通信機能を持った家電またはセンサーなどの機器である。本実施形態では、ブロードバンドルータ配下のホームネットワークに接続されたデジタルテレビを想定する。対象機器３０１は、ＲＥＳＴ  ＡＰＩ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を第２ネットワーク６０１、すなわち、ホームネットワークに公開している。このＲＥＳＴ  ＡＰＩを以降、プライベートＡＰＩと呼ぶことがある。本実施形態では、対象機器３０１は、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）でアクセス可能なＡＰＩとして、プライベートＡＰＩを公開しているものとする。
【００１７】
通信装置２０１は、第２ネットワーク６０１を介して対象機器３０１と接続されているとき、対象機器３０１のプライベートＡＰＩに第２ネットワーク６０１を介してＨＴＴＰリクエストを送信することで、所望のリソースを利用できる。例えば、テレビ番組の録画予約を行うプライベートＡＰＩを利用するＨＴＴＰメッセージ例（以下、メッセージＡとして参照する）を以下に記す。ＨＴＴＰ  ＰＯＳＴメソッドを利用し、ＨＴＴＰのリクエストボディにチャンネルや日時等を指定している。この例では、所望のリソースは、テレビ（対象機器３０１）の録画予約(reserved_programs)である。
【００１８】
［メッセージＡ］
【表１】
2016177795.tif 000003
【００１９】
テレビのチャンネルを変更するプライベートＡＰＩを利用するＨＴＴＰメッセージ例（以下、メッセージＢとして参照する）を以下に示す。ＨＴＴＰ  ＰＵＴメソッドを利用し、リクエストボディにチャンネルを指定している。この例では、通信装置２０１が利用しようとする所望のリソースは、テレビ（対象機器３０１）の状態(status)である。
【００２０】
［メッセージＢ］
【表２】
2016177795.tif 000004
【００２１】
以上は、あくまで実現方法の一形態であり、パラメータやＵＲＬは、上記の例に限定されるものではない。
【００２２】
アクセス認可装置１０１は、第１ネットワーク５０１に接続されたサーバ装置である。
アクセス認可装置１０１は、ＣＰＵ、メモリおよびストレージで構成される一般的な計算機の構成を有することを想定しているが、クラウドシステム上の仮想サーバとして実現されてもよい。本実施形態では、具体的には、サーバ装置上に実装されたソフトウェアプログラムが、本実施形態に係るアクセス認可装置１０１の機能を実現することを想定している。このソフトウェアプログラムは、ＯＡｕｔｈ２．０、ＯｐｅｎＩＤ  Ｃｏｎｎｅｃｔ
１．０といった、インターネット上でのアクセス認可を実現する標準規格に則った認可サーバ機能を備えているものとする。
【００２３】
アクセス認可装置１０１は、通信部１１１、トークン発行部１１２、認可対象決定部（決定部）１１３、状態判定部１１４、トークン検証部１１５、アクセス代行部１１６、トークン記憶部１１７、対象機器情報記憶部１１８を備える。
【００２４】
通信部１１１は、第１ネットワーク５０１を介して通信装置２０１および対象機器３０１と通信を行う。対象機器３０１との通信は、中継装置４０１を介して行う。
【００２５】
アクセス代行部１１６は、パブリックＡＰＩを備え、パブリックＡＰＩを、第１ネットワーク５０１に公開している。前述したように、具体的に、パブリックＡＰＩは、本実施形態では、プライベートＡＰＩと同様の、ＨＴＴＰでアクセス可能なＡＰＩを提供しているものとする。
例えば、アクセス認可装置１０１のドメインがapi.publiccontroller.example.comであり、対象機器３０１の識別子を“xyz”とした場合、対象機器３０１のプライベートＡＰＩ（前述したメッセージＡおよびＢを参照）に相当するパブリックＡＰＩのＵＲＬは、それぞれ以下のように表現できる。
【表３】
2016177795.tif 000005
【００２６】
トークン発行部１１２は、通信装置２０１から対象機器３０１のリソースへのアクセス許可要求を受信して、通信装置２０１の認証、ならびにリソースのアクセス権限者の認証および認可を行う。これらの認証および認可が成功すると、トークン発行部１１２は、アクセス許可情報（アクセストークン）を通信装置２０１に対して発行する。アクセストークンは、プライベートＡＰＩへのアクセスのものと、パブリックＡＰＩへのアクセスのものがあり、どちらを発行するかは、後述する認可対象決定部１１３と状態判定部１１４の結果に応じて判断する。通信装置２０１は、パブリックＡＰＩまたはプライベートＡＰＩへのアクセストークンの発行を受けると、対象機器３０１のリソースへのアクセスが可能となる。プライベートＡＰＩの場合は、対象機器３０１に対して直接、リソースへアクセスし、パブリックＡＰＩの場合は、アクセス認可装置１０１の代行により行われる。なお、この機能は、ＯＡｕｔｈ２．０の認可サーバの基本機能である。アクセス認可要求およびそれに基づく認証および認可等は、この標準仕様に則ったＨＴＴＰＳ通信で実現される。
【００２７】
トークン記憶部１１７は、トークン発行部１１２により発行されたアクセストークンを、リソースにアクセスする際に利用する１つ以上のＡＰＩ情報に関連付けて記憶する（後述する図２参照）。ＡＰＩ情報は、ＡＰＩに関する情報の一例である。その他の例としては、後述する図３のＡＰＩパス（ＡＰＩ情報の一部）などがある。
ＡＰＩ情報は、それ自体の記述から、プライベートＡＰＩとパブリックＡＰＩを区別可能になっている。ＡＰＩ情報は、例えばリソースアクセスのときに利用するＵＲＬを含む。またトークン記憶部１１７には、アクセス可能な対象機器のＩＤおよびユーザのＵＩＤが、アクセストークンに関連づけられて記憶される。また、アクセストークンの有効期限も設定されている。リフレッシュトークンはアクセストークンと同時に発行され、その使用方法は後述する。
【００２８】
トークン記憶部１１７自体の具体的な実現形態は、揮発メモリ上の簡易なハッシュ構造であってもよいし、ＫＶＳ（Ｋｅｙ  Ｖａｌｕｅ  Ｓｔｏｒｅ）であってもよいし、不揮発ストレージに記憶するリレーショナルデータベース管理システムであってもよい。アクセストークンから、関連する認可対象情報を参照できるかぎりにおいて実現方法は問わない。
【００２９】
トークン検証部１１５は、通信装置２０１からパブリックＡＰＩへのリソースの利用要求を受けた場合に、当該アクセス要求に含まれるアクセストークンが、発行済みの有効なアクセストークンであるかを検証する。また、通信装置２０１からトークン発行要求を受信し、当該トークン発行要求にリフレッシュトークンが含まれる場合に、リフレッシュトークンが、発行済みの有効なものであるかを検証する。対象機器３０１からアクセストークン検証要求を受信し、当該検証要求に含まれるアクセストークンが、発行済みの有効なリフレッシュトークンであるかを検証する。トークン発行部１１２と同様、検証要求およびそれに基づく検証は、ＨＴＴＰＳ通信で実現される。
【００３０】
対象機器情報記憶部１１８は、対象機器３０１にアクセスするために用いる情報（アクセス情報）と、対象機器３０１を一意に識別する対象機器ＩＤ（デバイス識別子）と、プライベートＡＰＩのパスとを含む。アクセス情報は、対象機器３０１の外部ＩＰアドレス、およびポート番号を含む。外部ＩＰアドレスは、対象機器３０１と通信するときにアクセス認可装置１０１で把握される対象機器３０１のＩＰアドレスであり、通常、中継装置４０１の第１ネットワーク５０１側のポートに割り当てられたグローバルＩＰアドレスに一致する。なお、本実施形態のＩＰアドレスは、ＩＰｖ４アドレスでも、ＩＰｖ６アドレスでもよい。また、ＩＰアドレス以外の種類のアドレスを用いてもよい。
【００３１】
アクセス情報は、アクセス認可装置１０１と対象機器３０１間の通信方式に依存して、様々なバリエーションが考えられる。例えば、対象機器３０１からアクセス認可装置１０１に通信コネクションを維持し続ける方式（ＷｅｂＳｏｃｋｅｔや、ＨＴＴＰ  Ｌｏｎｇ
Ｐｏｌｌｉｎｇ等）では、通信ソケット情報を加えてもよい。記憶部自体の実現形態は、トークン記憶部１１７と同様に種々の形態が可能である。
【００３２】
本実施形態では、当該方式（ＷｅｂＳｏｃｋｅｔや、ＨＴＴＰ  Ｌｏｎｇ  Ｐｏｌｌｉｎｇ等）を利用して、対象機器３０１がアクセス認可装置１０１と通信コネクションを維持し続けている状況を想定する。この状況では、アクセス認可装置１０１から中継装置４０１を介して対象機器３０１へ通信（ＴＣＰ通信など）を開始することも可能である。
【００３３】
状態判定部１１４は、通信装置２０１からの要求（トークン発行要求、リソース利用要求など）が受信された際に、通信装置２０１の接続状態を判定する。具体的に、通信装置２０１が、第２ネットワーク６０１に接続されているか否かを判定する。具体的な判定方法として、状態判定部１１４が、対象機器情報記憶部１１８内の対象機器３０１の外部ＩＰアドレスを参照し、これと、アクセス認可装置１０１で受信した要求の送信元ＩＰアドレスが一致するか否かで、第２ネットワーク６０１に接続されているかを判定する。対象機器３０１の外部ＩＰアドレスが送信元ＩＰアドレスと一致する場合には、第２ネットワーク６０１に接続されていると判断し、一致しない場合は、第２ネットワーク６０１に接続されていない（すなわち第１ネットワーク５０１に接続されている）と判断する。要求の送信元ＩＰアドレスは、通信装置２０１の第２ネットワーク６０１との接続状態（接続されているか否か、あるいは接続可能な状態か否か）を特定するための情報の一例である。
対象機器に対してＩＰアドレスの範囲を設定し、送信元ＩＰアドレスが、当該範囲（複数の対象機器が取り得るＩＰアドレスの範囲など）に含まれるか否かで、第２ネットワークに接続されているかを判定してもよい。
第２ネットワーク６０１に接続されている場合、ユーザは宅内にいるとみなせるから、宅内からのアクセスであると言える。第２ネットワーク６０１に接続されていない場合、すなわち第１ネットワーク５０１に接続されている場合、宅外にいるとみなすことができるから、宅外からのアクセスであると言える。以下では、第２ネットワーク６０１を介したアクセス認可装置１０１へのアクセスを宅内からのアクセス、第２ネットワークを介さず、第１ネットワーク５０１を介したアクセス認可装置１０１へのアクセスを宅外からのアクセスと表現することがある。状態判断部１１４は、判定結果に基づき、通信装置２０１の接続状態を表す状態情報を生成する。状態情報は、通信装置２０１のアクセス認可装置１０１のアクセスが、宅内からのアクセスか、宅外からのアクセスかを表す。
【００３４】
ここでは通信装置２０１が第２ネットワーク６０１に接続されているかを判断したが、通信装置２０１が第１ネットワーク５０１に接続されているが、第２ネットワーク６０１に接続可能な状態か否かを判断してもよい。例えばユーザが宅内に存在し、第２ネットワーク６０１にいつでも接続可能であるが、現時点では第１ネットワーク５０１に接続されている場合は、第２ネットワーク６０１に接続可能な状態であると判断できる。接続可能な状態かを判断するのに、通信装置２０１が、対象機器３０１に対して一定の距離範囲内に存在するかを判断してもよい。例えば、通信装置２０１がＧＰＳを搭載しており、また、対象機器３０１の設置位置情報を予め取得しておくとする。この場合、通信装置２０１からＧＰＳの位置情報を取得し、取得した位置情報を、設置位置情報と比較することで、第２ネットワーク６０１に接続可能な状態かを判断してもよい。または、対象機器３０１がＧＰＳを搭載している場合には、当該対象機器３０１のＧＰＳの位置情報を取得し、これを対象機器３０１の位置情報と比較することで、第２ネットワーク６０１に接続可能な状態かを判断してもよい。接続可能な状態の場合、接続されている状態（宅内からのアクセスの場合）に準じた処理を行っても良い。プライベートＡＰＩへアクセスすることになった場合、通信装置２０１が自動的に接続先を第１ネットワーク５０１から第２ネットワーク６０１に切り換えても良い。ＧＰＳの位置情報は、通信装置２０１の第２ネットワーク６０１との接続状態を特定するための情報の一例である。
【００３５】
認可対象決定部１１３は、状態判定部１１４で生成された状態情報を用いて、プライベートＡＰＩおよびパブリックＡＰＩのいずれをアクセス対象として許可するかを決定する。認可対象決定部１１３が認可を与える対象は、通信装置２０１に搭載されたアプリケーションに対してである。一例として、状態情報が宅内からのアクセスを示す場合は、プライベートＡＰＩ、宅外からのアクセスを示す場合は、パブリックＡＰＩを認可の対象として決定する。通信装置２０１のアプリケーションがアクセスする対象は、上記プライベートＡＰＩ、もしくは、パブリックＡＰＩであり、いずれのアクセスに認可を与えるか判断する。プライベートＡＰＩが決定された場合、通信装置２０１が直接、対象機器３０１のプライベートＡＰＩにアクセスする（すなわち通信装置２０１がリソースの利用要求を対象機器３０１に送信する）ことを意味する。パブリックＡＰＩの場合、アクセス代行部１１６が、通信装置２０１からのパブリックＡＰＩへのアクセスを受けて、アクセス代行部１１６がリソースの利用要求を対象機器３０１に送信する。なお、アクセス代行部１１６が対象機器３０１のリソースを利用する方法は事前に定められているものとする。専用のＡＰＩが用意されていてもよいし、プライベートＡＰＩのＵＲＬを含むデータを対象機器に送信し、対象機器が当該データに含まれるプライベットＡＰＩのＵＲＬを内部的に解釈および実行してもよい。
【００３６】
以下、具体的な事例に基づき、本通信システムの動作を説明する。説明の前に、ユーザ行動の想定シナリオと、通信システムの前提条件について説明する。
【００３７】
＜想定シナリオ＞
ユーザが、宅外からスマートフォン（通信装置２０１）に搭載されたテレビリモコンアプリケーション（以降、クライアントと呼ぶ）を操作し、自宅のテレビ（対象機器３０１）の番組録画予約を行う。続いて、ユーザは、帰宅後に当該テレビリモコンアプリケーションでテレビの電源ＯＮし、チャンネルを切り替える。このとき、Ｗｅｂ上のテレビリモコンサービスを提供するサーバ（アクセス認可装置１０１）は、ユーザが宅外にいるときはパブリックＡＰＩを、ユーザが宅内にいるときは、プライベートＡＰＩを利用するように、使用するＡＰＩを自動的に切り換えるように制御する。この制御により、ユーザが番組録画予約を行うときは通信装置２０１はパブリックＡＰＩにアクセスし、チャンネル切り替えを行うときはプライベートＡＰＩにアクセスする。このようなＡＰＩの切り替えは、宅外から宅内への移動を契機として自動的に実行される。
【００３８】
＜前提条件＞
・スマートフォン（通信装置２０１）上のリモコンアプリケーション（クライアント）は、ＯＡｕｔｈの標準規格に従い、テレビリモコンサービスを提供するサーバ（アクセス認可装置１０１）から発行されたクライアント識別子（client_id）とクライアント秘密情報(client_secret)を保持している。この発行は、特定リソースへのアクセス（取得と変更）を行うクライアントを、クライアントの開発者が、アクセス認可装置１０１（の管理者）に登録申請し、アクセス認可装置１０１の管理者の承諾を経て実行される。登録、許諾、発行は、電子的に自動で行われることが一般的であるが、本実施形態では、この発行方法については規定しない。なお、特定リソースは、本実施形態では、テレビ（対象機器３０１）の状態(status)、および録画予約(reserved_programs)である。
・アクセス認可装置１０１側にも、クライアント認証用にこのclient_id、client_secret（図示せず）が登録されている。
・アクセス認可装置１０１の対象機器情報記憶部１１８には、対象機器３０１の外部ＩＰアドレス等が、対象機器３０１の識別情報（デバイス識別子：device_id）と共に記憶されている（図３参照）。本実施形態では、この登録手法については規定しない。手動でデータベースに登録されていてもよいし、対象機器３０１（テレビ）がアクセス認可装置１０１と通信を行って、自動的に登録するようにしてもよい。
・通信装置２０１のユーザは、対象機器３０１の所有者であり、テレビリモコンサービスを提供するサーバ（アクセス認可装置１０１）で、予めユーザアカウント(user_id, user_password)を作成している。なお、ユーザＩＤ（user_id）は、トークン記憶部１１７においてトークンに関連づけられて登録されている（図２参照）。
・アクセス認可装置１０１上に、ユーザと、ユーザが所有する対象機器３０１（テレビ）が対応付けられている。この対応付けの方法も様々な実現形態が考えられるが、本実施形態ではその方法を規定しない。トークン記憶部１１７には、このユーザと対象機器３０１との対応付けが、ユーザＩＤ（user_id）と対象機器ＩＤ（device_id）との対応付けにより登録されている。
【００３９】
＜本実施形態の通信シーケンス＞
図４は、本実施形態に係る通信システムにおける対象機器３０１、通信装置２０１およびアクセス認可装置１０１間で行われる通信シーケンスを示す。図５は、図４に続く通信シーケンスを示す。図４および図５における各数字はステップの番号を表す。
【００４０】
［ステップ１］ユーザが、通信装置２０１上のクライアントを立ちあげ、所望の番組の録画予約（リソース利用）を行う。このとき、クライアントは、未だアクセストークンを取得していないので、ユーザに認可画面を表示し、許可画面にはクライアントが対象機器３０１のリソース利用を求めている旨と、許諾ボタンおよびキャンセルボタンとを表示する。許可画面にユーザが宅内および宅外のいずれにいるか（第１ネットワーク５０１および第２ネットワーク６０１のどちらに接続されているか）を区別する情報を表示してもよい。
【００４１】
［ステップ２］ユーザが、許可画面内の認可ボタンを押下する。本実施形態では、クライアントが認可画面を生成しているが、アクセス認可装置１０１に認可要求を送信し、アクセス認可装置１０１が認可画面を応答する方法を採ってもよい。この場合、アクセス認可装置１０１から応答された許可画面を、通信装置２０１で表示する。
【００４２】
［ステップ３］クライアントは、ユーザの許諾を受けて、アクセス認可装置１０１のトークン発行部１１２にアクセストークン発行要求（リソースの許可要求）を送信する。このとき、アクセストークン発行要求は、一実現形態としては、client_id、client_secret、user_id、user_password、および、要求するＡＰＩに関する情報である認可範囲情報（認可対象情報）を含む。認可範囲情報は、一例として、192.168.11.19 /v1/status, および192.168.11.19 /v1/reserved_programを含む。「192.168.11.19 /v1/」をアクセス認可装置で把握している場合、認可範囲情報はstatus とreserved_programを含んでもよい。
【００４３】
user_idとuser_passwordは、通信装置２０１がユーザに入力画面（ステップ１のユーザ認可画面でもよい）を表示し、その入力値を利用するようにしてもよいし、予め、通信装置２０１内に記憶しておき、これを利用するようにしてもよい。
【００４４】
認可範囲情報は、アクセストークン発行要求に含めずに、予めクライアント識別子（client_id）に紐づけてアクセス認可装置１０１側で記憶しておいてもよい。なお、client_id, client_secret, user_id, user_passwordを含むアクセストークン発行要求は、ＯＡｕｔｈ２．０のリソースオーナーパスワードクレデンシャルグラントという承認方式（グラントタイプ）に則っている。本実施形態では、このグラントタイプに則ったシーケンスのみを記すが、これ以外のグラントタイプ（認可コード、インプリシットグラント、またはクライアントクレデンシャルグラント）に則ったシーケンスであってもよい。
【００４５】
（ステップ４）トークン発行部１１２は、アクセストークン発行要求に含まれるclient_id, client_secretに基づき、当該クライアントが正規のクライアントであることを認証する。正規のクライアントとは、アクセス認可装置１０１に事前に登録および承認されたクライアントのことである。
【００４６】
（ステップ５）トークン発行部１１２は、user_id, user_passwordに基づき、ユーザが正規のユーザであることを認証する。正規のユーザとは、アクセス認可装置１０１に事前に登録および承認されたユーザのことである。アクセス認可装置１０１ではユーザと対象機器３０１とが予め関連づけて登録されているため、認証の結果として、ユーザの所有対象機器３０１が判明する。ここでは、ユーザの所有対象機器３０１は、テレビ（device_id=xyz）である。
【００４７】
（ステップ６）状態判定部１１４は、アクセストークン発行要求の送信元ＩＰアドレスを取得し、この送信元ＩＰアドレスを、対象機器情報記憶部１１８における当該テレビに対応するＩＰアドレス（図３参照）と比較する。当該テレビに対応するＩＰアドレスは、トークン記憶部においてユーザに関連づけられた機器（テレビ）を特定し、当該テレビのＩＰアドレスを、対象機器情報記憶部１１８から特定することで行うことができる。これらが異なっていれば、ユーザのアクセスは宅外アクセスであり、同じであれば宅内アクセスであると判定する。ここでは、宅外アクセスと判定される。
【００４８】
（ステップ７）認可対象決定部１１３は、状態判定部１１４の判定結果と、ユーザに関連づけられた対象機器３０１（device_id=xyz）に基づき、パブリックＡＰＩ（api.tvcontroller.example.com/v1/devices/xyz/statusと、api.tvcontroller.example.com/v1/devices/xyz/reserved_program）を認可対象として決定する。具体的に、図２のトークン記憶部１１７に記憶された情報において、ユーザ（この例ではaliceとする）と対象機器３０１（xyz）とに関連づけられたパブリックＡＰＩおよびプライベートＡＰＩのうち、宅内アクセスの判定結果から、パブリックＡＰＩを決定する。図２の情報においてパブリックＡＰＩとプライベートＡＰＩの区別は、許可対象情報（ＡＰＩ情報）の記述自体から行ってもよいし（例えば許可対象情報にプライベートＩＰアドレスが含まれていればプライベートＡＰＩと判断するなど）、あるいは、パブリックＡＰＩとプライベートＡＰＩを区別するための識別情報を別途付与し、この識別情報に基づいて行ってもよい。
【００４９】
（ステップ８）トークン発行部１１２は、認可対象決定部１１３の決定に基づき、パブリックＡＰＩ用のアクセストークンを発行し、発行したアクセストークンを含むアクセストークン応答をクライアントに送信する。発行されたアクセストークンは、トークン記憶部１１７に記憶される（図２の１行目の「アクセストークン」の列）。本実施形態では、トークン発行部１１２は、発行したアクセストークンに有効期限（図２の１行目の「有効期限」の列」）を設け、さらに、アクセストークンの更新用に用いるリフレッシュトークン（図２の１行目の「リフレッシュトークン」の列」）をあわせて発行する。このリフレッシュトークンも、クライアントに送信するアクセストークン応答に含める。なお、アクセストークン応答に、パブリックＡＰＩ情報を含めてもよいし、クライアント側でパブリックＡＰＩ情報を事前に把握するようにしてもよい。
【００５０】
リフレッシュトークンは、アクセストークンよりも長い有効期限を設けてもよい。アクセストークンが期限切れした場合や、後述する通信装置２０１の状態（宅内か宅外か）が変化する等してトークン検証が失敗した場合には、クライアントは、このリフレッシュトークンを提示して、新しいアクセストークンの発行を要求する。リフレッシュトークンを利用することで、再度ユーザ認証等から処理をやり直す必要がない利点がある。なお、後述するステップ１８に記すように、リフレッシュトークンを用いない形態も可能である。
【００５１】
（ステップ９）クライアントは、アクセス認可装置１０１から受信したアクセストークン応答に含まれるパブリックＡＰＩ用のアクセストークンとリフレッシュトークンを取得する。クライアントは、アクセストークンを含む録画予約要求（リソース利用要求）を、パブリックＡＰＩ（アクセス代行部１１６）に送信する。具体的には、パブリックＡＰＩのＵＲＬhttps://api.tvcontroller.example.com/v1/devices/xyz/reserved_programsに対して、前述したメッセージＡを送信する。なお、前述したメッセージＡの例では、アクセストークン等の表記は省略されている。
【００５２】
（ステップ１０）
アクセス代行部１１６は、パブリックＡＰＩ用のアクセストークンを含む録画予約要求を受信する。このとき、トークン検証部１１５は、録画予約要求に含まれるアクセストークンが、パブリックＡＰＩ用に発行された有効なものであることを、トークン記憶部１１７を参照して確認する。すなわち、録画予約要求に含まれるアクセストークンがトークン記憶部１１７に存在し、かつ有効期限内であることを確認する。
【００５３】
（ステップ１１）状態判定部１１４は、ステップ６と同様に、録画予約要求の送信元ＩＰアドレスを、対象機器情報記憶部１１８における当該テレビ（例えばパブリックＡＰＩのＵＲＬの「xyz」から特定）に対応するＩＰアドレス（図３参照）と比較することで、宅外アクセスか宅外アクセスかを判定する。ここでは両者が一致しないため、宅外アクセスと判断する。トークン検証部１１５は、状態判定部１１４の判定結果に基づき、録画予約要求に含まれているアクセストークンが宅外からの録画予約要求用に発行された正当なものと判定する。
【００５４】
（ステップ１２）アクセス代行部１１６は、リソース利用要求である録画予約要求を、対象機器３０１に送信する。送信された録画予約要求は第１ネットワーク５０１、中継装置４０１および第２ネットワーク５０２を介して、対象機器３０１で受信される。
【００５５】
（ステップ１３）対象機器３０１は、アクセス認可装置１０１から録画予約要求を受信し、録画予約要求に基づき録画予約を実行する。対象機器３０１は録画予約を実行すると、録画予約を完了報告をアクセス認可装置１０１に送信する。アクセス認可装置１０１は、録画予約の完了報告を対象機器３０１から受信する。アクセス代行部１１６は、要求された録画予約が完了したことを示す応答（パブリックＡＰＩアクセス応答）を通信装置２０１に返す。
【００５６】
（ステップ１４）ユーザが、宅外から宅内に移動し、通信装置２０１に搭載されたクライアントを用いて、テレビのチャンネル切り替えを行う。このとき、宅外で使われていた携帯キャリア通信（３ＧやＬＴＥ）から、宅内のＷｉＦｉに通信が切り替わったとする。すなわち、通信装置２０１の接続先が第１ネットワーク５０１から第２ネットワーク６０１に切り替わったとする。
【００５７】
（ステップ１５）クライアントは、アクセス代行部１１６のパブリックＡＰＩに対して、パブリックＡＰＩ用のアクセストークンを含むチャンネル切り替え要求（リソース利用要求）を送信する。具体的には、パブリックＡＰＩのＵＲＬhttps://api.tvcontroller.example.com/v1/devices/xyz/statusに対して、前述したメッセージＢを送信する。なお、前述したメッセージＢの例では、アクセストークン等の表記は省略されている。
【００５８】
（ステップ１６）アクセス代行部１１６は、アクセストークンを含むチャンネル切り替え要求を受信する。このとき、トークン検証部１１５は、ステップ１０と同様、アクセストークンがパブリックＡＰＩ用に発行された有効なものであることを、トークン記憶部１１７を参照して確認する。
【００５９】
（ステップ１７）状態判定部１１４は、ステップ１１と同様に、チャンネル切り替え要求の送信元ＩＰアドレスを、対象機器情報記憶部１１８における当該テレビ（例えばパブリックＡＰＩのＵＲＬの「xyz」から特定）に対応するＩＰアドレス（図３参照）と比較することで、宅外アクセスか宅外アクセスかを判定する。ここでは両者が一致するため、宅内アクセスと判断する。トークン検証部１１５は、状態判定部１１４の判定結果に基づき、認可エラーを判断する。アクセス代行部１１６は、これを受けて、パブリックＡＰＩへの、宅内（中継装置４０１配下の第２ネットワーク６０１）からのアクセスを拒絶し、認可エラー応答を送信する。
【００６０】
（ステップ１８）通信装置２０１に搭載されたクライアントは認可エラー応答を受信すると、アクセストークン発行要求を生成してトークン発行部１１２に送信する。このアクセストークン発行要求は、ステップ８で発行されたリフレッシュトークンを含む。バリエーションとしては、リフレッシュトークンは使わず、ステップ３と同様、再度、新規のアクセストークン発行要求を送信する方法もある。
【００６１】
（ステップ１９）トークン検証部１１５は、トークン発行要求に含まれるリフレッシュトークンを取得し、取得したリフレッシュトークンが、トークン記憶部１１７に登録されているかを確認する（なお、この時点では図２の２行目のアクセストークンおよびリフレッシュトークンは登録されていなくてよい）。登録されていることから、当該リフレッシュトークンが、正当なリフレッシュトークンであると判断する。このとき、リフレッシュトークンの発行対象である対象機器３０１のＩＤ、すなわちdevice_id（=xyz）をトークン記憶部１１７から取得する。
【００６２】
（ステップ２０）ステップ１７と同様、状態判定部１１４は、トークン発行要求の送信元ＩＰアドレスを、対象機器情報記憶部１１８における当該テレビ（xyz）に対応するＩＰアドレス（図３参照）と比較することで、宅外アクセスか宅外アクセスかを判定する。ここでは、両者が一致するため、宅内アクセスであると判定する。
【００６３】
（ステップ２１）認可対象決定部１１３は、状態判定部１１４の判定結果と、ユーザに関連づけられた対象機器３０１（device_id=xyz）に基づき、対象機器３０１に搭載されたプライベートＡＰＩ（192.168.11.19 /v1/status, reserved_program）を、通信装置２０１のアクセス認可対象に決定する。
【００６４】
（ステップ２２）トークン発行部１１２は、認可対象決定部１１３の決定に基づき、プライベートＡＰＩ用のアクセストークンを発行する。発行されたアクセストークンは、トークン記憶部１１７に記憶される（図２の２行目の「アクセストークン」の列）。この際、パブリックＡＰＩ用のリフレッシュトークンと同じ値のリフレッシュトークンを、プライベートＡＰＩ用のアクセストークンに対するリフレッシュトークンとしてトークン記憶部１１７に記憶する（図２の２行目の「リフレッシュトークン」の列）。また、トークン発行部１１２は、図２のトークン記憶部１１７におけるプライベートＡＰＩ情報（認可対象情報）を取得し、アクセストークンとプライベートＡＰＩ情報等を含むアクセストークン応答を生成する。トークン発行部は、アクセストークン応答を通信装置２０１に送信する。なお、リフレッシュトークンの値は、パブリックＡＰＩ用のリフレッシュトークンと異なってもよい。
【００６５】
（ステップ２３）通信装置２０１に搭載されたクライアントは、アクセストークン応答に含まれるアクセストークンとプライベートＡＰＩ情報を取得し、対象機器３０１のプライベートＡＰＩに、当該取得したアクセストークンを含むチャンネル切り替え要求（リソース利用要求）を送信する（すなわち、プライベートＡＰＩアクセスを実行する）。なお、通信装置２０１で事前にプライベートＡＰＩ情報を把握している場合は、アクセス認可装置１０１から送信するアクセストークン応答にプライベートＡＰＩ情報を含めなくてもよい。この場合、アクセス認可装置１０１でプライベートＡＰＩ情報を把握しない構成にしてもよい。
【００６６】
（ステップ２４）対象機器３０１のプライベートＡＰＩは、アクセストークンを含むチャンネル切り替え要求を受信する。対象機器３０１のプライベートＡＰＩは、チャンネル切り替え要求に含まれるアクセストークンを取得し、当該アクセストークンを含むトークン検証要求を生成して、アクセス認可装置１０１に送信する。
【００６７】
（ステップ２５）アクセス認可装置１０１の通信部１１１は、対象機器３０１から送信されるトークン検証要求を受信する。トークン検証部１１５は、トークン検証要求に含まれるアクセストークンが、対象機器３０１のプライベートＡＰＩ用に発行された有効なものであることを、トークン記憶部１１７を参照して確認する。当該アクセストークンと同じ値がトークン記憶部１１７において当該対象機器３０１に対して記憶されており、有効期限内であるため、有効であると判断できる。なお、トークン検証部１１５は、トークン検証要求の送信元が対象機器３０１（device_id=xyz）であることは、トークン検証要求に対象機器ＩＤの“xyz”を含め、これを検出することで把握してもよい。または、Ｗｅｂｓｏｃｋｅｔで対象機器３０１とアクセス認可装置１０１との接続が維持されている場合に、当該接続を介して送信される要求の送信元機器が常に対象機器３０１（device_id=xyz）であると判断する仕組みにしてもよい。ここで述べた以外の方法で判断してもよい。
【００６８】
（ステップ２６）状態判定部１１４が、トークン検証要求の送信元ＩＰアドレスを、対象機器情報記憶部１１８における当該テレビ（xyz）に対応するＩＰアドレス（図３参照）と比較することで、通信装置２０１のアクセス（すなわちユーザのアクセス）が、宅外アクセスか宅外アクセスかを判定する。ここでは、両者が一致するため、宅内アクセスであると判定する。トークン検証要求に含まれる送信元ＩＰアドレスは、通信装置２０１の第２ネットワーク６０１との接続状態を特定するための情報の一例である。トークン検証部１１５は、状態判定部１１４の判定結果（宅内アクセス）から、クライアントからの対象機器３０１へのアクセスは正当なアクセスであると判定（すなわちユーザはアクセス認可装置１０１で認証および認可を経て、宅内の対象機器３０１のプライベートＡＰＩにアクセスしようとしていると判断）し、その旨の検証結果を表す応答を対象機器３０１に送信する。
【００６９】
（ステップ２７）対象機器３０１は、アクセス認可装置１０１の検証結果から、通信装置２０１からのプライベートＡＰＩアクセスで指示されたチャンネル切り替えを実行してよいと判断し、当該チャンネル切り替えを実行する。対象機器３０１は、チャンネル切り替えを実行した旨を表す応答（プライベートＡＰＩアクセス応答）を通信装置２０１に送信する。
【００７０】
図６は、アクセス認可装置１０１が通信装置２０１からトークン発行要求を受信した場合に行う処理のフローチャートである。前述した図４および図５のシーケンスでは、ステップ３とステップ１８でトークン発行要求を通信装置２０１から受信している。
【００７１】
トークン発行要求を受信すると、トークン発行要求にリフレッシュトークンが含まれているかを判断する（ステップ３１）。
【００７２】
リフレッシュトークンが含まれていない場合、クライアント認証（ステップ３２）およびユーザ認証（ステップ３３）を行う。クライアント認証およびユーザ認証の詳細は前述した通りである。いずれかの認証が失敗すれば、通信装置２０１に認証エラー応答を送信して処理を終了する（ステップ３９）。両方の認証が成功した場合は、通信装置２０１の状態判定（ユーザが宅内にいるか宅外にいるかの判定）を行う（ステップ３４）。判定方法の詳細は前述した通りである。状態判定の結果に応じて、パブリックＡＰＩおよびプライベートＡＰＩのいずれをアクセス認可対象にするかを決定し（ステップ３５）、決定したＡＰＩに対応するアクセストークンを生成する（ステップ３６）。生成したアクセストークンは、ＡＰＩ情報、および対象機器３０１およびユーザ等に関連づけて、トークン記憶部１１７に記憶する（ステップ３７）。
【００７３】
一方、トークン発行要求にリフレッシュトークンが含まれている場合は、リフレッシュトークンを検証する（ステップ３８）。すなわち、当該リフレッシュトークンがトークン記憶部１１７に有効に登録されているかを判断する。有効に登録されている場合は、ステップ３４の通信装置２０１の状態判定を行い、以降は上述したステップ３５〜３７を行う。リフレッシュトークンがトークン記憶部１１７に登録されていない、もしくは登録されているが有効期限が切れている場合は、通信装置２０１に認証エラー応答を送信して処理を終了する（ステップ３９）。
【００７４】
本実施形態では、対象機器が宅内に１つある場合を示したが、複数の対象機器がある場合も同様にして実施可能である。このとき、対象機器ごとにパブリックＡＰＩ用およびプライベートＡＰＩ用のアクセストークンをそれぞれ発行してもよいし、それぞれ同じアクセストークンを複数の対象機器で用いてもよい。
【００７５】
また、本実施形態では、中継装置４０１が通信装置２０１とは別に存在したが、通信装置２０１が中継機能を備え、対象機器３０１が通信装置２０１の中継機能を利用して、アクセス認可装置１０１と通信してもよい。この場合も、通信装置２０１は、対象機器３０１と同じネットワークに接続されているといえる。
【００７６】
また、本実施形態ではアクセス認可装置は対象機器３０１とＷｅｂｓｏｃｋｅｔ等で常時通信コネクションを維持している状況を想定したが、通信装置２０１が第２ネットワーク６０２に接続されている（または接続可能な状態である）と判定された場合は、対象機器３０１との通信コネクションを切断してもよい。また、通信装置２０１が第２ネットワーク６０２に接続されていない（または接続不能な状態である）と判定された場合は、対象機器３０１との通信コネクションを再度設定してもよい。
【００７７】
以上、本実施形態によれば、アクセストークンの発行（ステップ４〜８、１９〜２２）、アクセストークンを利用したリソースアクセス（９〜１２，  １５〜１７）、アクセストークンの検証（２５〜２６）において、通信装置２０１の状態（宅外か宅内か）に応じた処理を行う。具体的には、ユーザが宅外にいる場合には、パブリックＡＰＩを利用し、宅内にいる場合には、必ずプライベートＡＰＩを利用するようクライアントに強制することができる。このとき、ユーザはＡＰＩの切り替えの都度、再認可を行う必要はなく、ユーザが知らない間に、利用するＡＰＩが切り替わる。ユーザは、宅外からのＡＰＩアクセスを行う場合にだけ、インターネット（第１ネットワーク５０１）上のサーバ（アクセス認可装置１０１）を利用するので、サーバに残る通信ログを必要最小限でき、かつ、可能な限りホームネットワーク（第２ネットワーク６０１）での直接通信を利用することで、リソース利用に要する通信遅延を短くできる。
【００７８】
以下、本実施形態のバリエーションについて説明する。
【００７９】
＜通信シーケンスのバリエーション（１）＞
図５のステップ１８〜２２ではアクセストークンを発行し直しているが、アクセストークンを発行し直さないシーケンスも可能である。以下のこの場合のシーケンスの変更点を説明する。
【００８０】
図４のステップ１の認可画面で、宅内・宅外両用のアクセストークンの認可をユーザに求めるようにする。
【００８１】
ステップ８のトークン発行で、プライベートＡＰＩ、パブリックＡＰＩ両用のアクセストークンを発行する。発行されるアクセストークンは、図２の１行目、２行目の認可対象情報を両方に対して有効である。
【００８２】
ステップ１７でエラー応答とせずに、プライベートＡＰＩへのリダイレクト応答を通信装置２０１に送信する。このリダイレクト応答にはプライベートＡＰＩ情報を含める。リダイレクト応答を受信した通信装置２０１は、リダイレクト応答に含まれるプライベートＡＰＩ情報に基づき、図５のステップ２３の動作を実行する。これによりステップ１８〜２２の動作は不要となる。
【００８３】
＜通信シーケンスのバリエーション（２）＞
図４および図５のシーケンスでは、トークン検証（トークンの有効性検証）および状態判定の順で処理を行っている（ステップ１０−１１、ステップ１６−１７、ステップ１９−２０、ステップ２５−２６）が、これは実装依存の部分であり、状態判定を先に行っても構わない。
【００８４】
＜通信シーケンスのバリエーション（３）＞
図５のステップ２７の後、ユーザが宅内から宅外に移動して、別途録画予約を行う場合のシーケンスを、以下にステップ２８〜３１として示す。
【００８５】
（ステップ２８）ユーザが、宅内から宅外に移動する。この時、通信装置２０１は、通信をＷｉＦｉから、３ＧないしＬＴＥなどのモバイル広域通信に切り替える。すなわち、通信装置２０１は、通信の接続先を第２ネットワーク６０１から第１ネットワーク５０１に切り換える。
【００８６】
（ステップ２９）ステップ２３と同様、クライアントは、宅内用のアクセストークンを用いて、対象機器３０１のプライベートＡＰＩに録画予約要求を送信する。
【００８７】
（ステップ３０）プライベートＡＰＩへのアクセスが失敗する。すなわち、通信装置２０１は第１ネットワーク５０１に接続されているため、第２ネットワーク６０１内の対象機器３０１のプライベートＡＰＩへアクセスするための通信は失敗する（タイムアウトする）。このため、通信装置２０１のクライアントは、第１ネットワーク５０１を介して、アクセス認可装置１０１のトークン発行部１１２にトークン発行要求を送信する。このトークン発行要求には、プライベートＡＰＩ用のリフレッシュトークンを含める。
【００８８】
（ステップ３１）以降は、宅外から宅内に移動した場合とは反対に、宅内向けのアクセストークンを、宅外向けのアクセストークンに切り替える処理を行う。処理の内容は基本的にステップ１９〜２２と同様の処理を、順次行えばよい。前回発行したパブリックＡＰＩ用のアクセストークンは廃棄し、パブリックＡＰＩ用のアクセストークンは新たに発行し直す。ただし、前回のパブリックＡＰＩ用のアクセストークンをそのまま使用し続けることも可能である。この際、有効期限を延長してもよいし、有効期限は変更しなくてもよい。
【００８９】
＜通信シーケンスのバリエーション（４）＞
通信シーケンスのバリエーション（３）と同様、図５のステップ２７の後、ユーザが宅内から宅外に移動して、別途録画予約を行う場合のシーケンスを、以下にステップ３２〜３７として示す。
【００９０】
（ステップ３２）ユーザが、宅内から宅外に移動する。この時、通信装置２０１は、通信をＷｉＦｉから、３ＧないしＬＴＥなどのモバイル広域通信に切り替える。すなわち、通信装置２０１は、通信の接続先を第２ネットワーク６０１から第１ネットワーク５０１に切り換える。
【００９１】
（ステップ３３）クライアントは、ステップ１８と同様、リフレッシュトークンを用いて、アクセストークンの発行要求をトークン発行部１１２に送信する。ステップ３に記すように新規アクセストークンの発行要求でも構わない。いずれにしても、バリエーション（３）がアクセス失敗を契機としてトークン発行要求を行うのに対して、本バリエーションでは、毎回（クライアント起動時に毎回、クライアントのＩＰアドレス変更時に毎回、リソース利用要求発生時に毎回など）アクセストークン発行要求を行い、プライベートＡＰＩへのアクセス失敗を契機としない。
【００９２】
（ステップ３４）ステップ１９と同様、トークン検証部１１５は、トークン発行要求に含まれるリフレッシュトークンを取得し、取得したリフレッシュトークンが、トークン記憶部１１７に登録されているかを確認する。これにより、対応するdevice_id(=xyz)を取得する。
【００９３】
（ステップ３５）ステップ６と同様、状態判定部１１４は、宅外アクセスか宅外アクセスかを判定する。ここでは、宅外アクセスであると判定する。
【００９４】
（ステップ３６）ステップ７と同様、認可対象決定部１１３は、状態判定部１１４の判定結果と、ユーザに関連づけられた対象機器３０１（device_id=xyz）に基づき、対象機器３０１に搭載されたパブリックＡＰＩを、通信装置２０１のアクセス認可対象に決定する。
【００９５】
（ステップ３７）ステップ２２と同様、トークン発行部１１２は、認可対象決定部１１３の決定に基づき、パブリックＡＰＩ用のアクセストークンを発行する。発行されたアクセストークンは、トークン記憶部１１７に記憶される。また、トークン発行部１１２は、図２のトークン記憶部１１７におけるパブリックＡＰＩ情報（認可対象情報）を取得し、アクセストークンとパブリックＡＰＩ情報等を含むアクセストークン応答を生成する。トークン発行部１１２は、アクセストークン応答を通信装置２０１に送信する。なお、リフレッシュトークンの値は、プライベートＡＰＩ用のリフレッシュトークンと異なっていてもよい。
【００９６】
＜通信シーケンスのバリエーション（５）＞
バリエーション（３）、（４）と同様、図５のステップ２７の後、ユーザが宅内から宅外に移動して、別途録画予約を行う場合のシーケンスのバリエーションを示す。バリエーション（３）では、クライアントがプライベートＡＰＩへのアクセスを試行する例を示したが、本バリエーションでは、クライアントがプライベートＡＰＩを有する機器の探索機能を有し、これを毎回（クライアント起動時に毎回、クライアントのＩＰアドレス変更時に毎回、リソース利用要求発生時に毎回など）実行する。具体的には、マルチキャストＤＮＳ、ＵＰｎＰ、ＥＣＨＯＮＥＴ  Ｌｉｔｅ等の周辺機器の探索機能を用いて、プライベートＡＰＩを備える機器を探索する（プロトコルは、この３つに限定されるものではなく、ホームネットワーク等を対象としたプロトコルにおいて同等機能が定義されている例は多々あり、それらを用いてもよい）。発見対象の機器の機器情報（プライベートＡＰＩを備える機器識別情報（ＩＰアドレス等）あるいはプライベートＡＰＩ）は、アクセス認可装置からアクセストークン発行時に関連情報として含まれるケース（図５のprivate_api_path）、対象機器情報を提供するＡＰＩをアクセス認可装置が別途備えているケース、あらかじめクライアントにプリセットされているケース、ユーザがクライアントに手動設定するケースが考えられる。対象機器が見つからなかった場合、クライントは、バリエーション（３）と同様、アクセス認可装置１０１のトークン発行部１１２にトークン発行要求を送信する。
【００９７】
＜構成のバリエーション（１）＞
図７に、本実施形態に係る通信システムの他の構成例を示す。図１のアクセス代行部１１６と対象機器情報記憶部１１８が、アクセス認可装置１０１から除去され、アクセス代行装置（制御代行装置）１３１として分離して配置されている。アクセス代行装置１３１は、第１ネットワーク５０１に接続されており、アクセス認可装置１２１、通信装置２０１および対象機器３０１と通信する通信部１１９を備えている。
【００９８】
他の構成例として、トークン記憶部１１７または対象機器情報記憶部１１８等の記憶部を全て別個の単独した装置として分離する構成も一般的である。その他、アクセス認可装置で構成する各要素が、様々な組み合わせで別装置として配置され、各機能間の連携が装置間の通信によって実装されてもよい。
【００９９】
＜構成のバリエーション（２）＞
図８に、本実施形態に係る通信システムの他の構成例を示す。全体のシステム構成に変化は無いが、認可対象提供部１１９が追加されている。図５では、トークン発行要求の応答に、プライベートＡＰＩ情報（private_api_path）が含まれる例を示しているが、本バリエーションは、このプライベートＡＰＩ情報を提供する機能をトークン発行部１１２から分離した構成をなしている。この構成において、クライアントは、アクセストークン発行後、別途アクセス認可装置上の認可対象提供部１１９にアクセスする。認可対象提供部１１９は、アクセストークンの検証後、トークン記憶部１１７の認可対象情報（ＡＰＩ情報）を応答する。
【０１００】
＜構成のバリエーション（３）＞
図９に、本実施形態に係る通信システムの他の構成例を示す。図１との差分は、通信装置２０１は、ゲートウェイ装置７０１を介して１つ以上の対象機器と接続されている点である。ゲートウェイ装置と１つ以上の対象機器とは第３ネットワーク８０１を介して接続されている（通信可能な状態にある）。以下、各構成要素について説明する。
【０１０１】
第３ネットワーク８０１は、例えばＢｌｕｅｔｏｏｔｈ、無線ＬＡＮ、Ｚｉｇｂｅｅなどローカルネットワークであってもよいし、ＨＤＭＩ（登録商標）やＵＳＢなど有線であって、直接、あるいはハブを介して、ゲートウェイ装置７０１と対象機器を繋ぐものであってもよい。また、第３ネットワーク８０１は、第２ネットワーク６０１と同一のネットワークであってもよい。
【０１０２】
本バリエーションにおける対象機器３０１、３０２は、上記実施形態で述べたようにプライベートＡＰＩを備えるものであってもよいが、備えていなくてもよい。本実施形態では備えないものとするが、ゲートウェイ装置７０１によるリソース利用を受け付ける通信機能は備えているものとする。具体的には、ＥＣＨＯＮＥＴ  Ｌｉｔｅ対応家電等、何らかのホームネットワーク上で機器を制御するプロトコルに準拠した機器であるものとする。
【０１０３】
ゲートウェイ装置７０１は、第２ネットワーク６０１に接続されるインタフェースと、第３ネットワーク８０１に接続されるインタフェースを有する。ゲートウェイ装置７０１は、通信装置２０１と対象機器３０１，３０２との間に介在し、リソース利用要求および応答を中継する装置である。例えばブロードバンドルータのようなルータ装置であったり、ＰＣやスマートフォンといった一般的な計算機の構成をとる装置であったり、スマートメータであったりしてよい。すなわち、ゲートウェイ装置７０１は、中継装置４０１と同一であってもよく、さらには、通信装置２０１と同一であってもよい。ここでは、ブロードバンドルータであるものとする。
ゲートウェイ装置７０１は、プライベートＡＰＩを備え、第３ネットワーク８０１を介して接続された対象機器３０１，３０２を制御する。すなわち、ゲートウェイ装置７０１は、アクセス認可装置１０１のアクセス代行部１１６と同様のアクセス代行部と、接続された対象機器をアクセス認可装置１０１に登録する登録部と、を備える。またゲートウェイ装置７０１は、対象機器情報記憶部１１８に準ずる機能、すなわち、ゲートウェイ装置７０１上のアクセス代行部が受信した通信装置２０１からの要求から、リソース利用の対象機器を特定するための変換情報を備えている。ＡＰＩのＵＲＬ中にデバイス識別子を含む場合には、例えばＵＲＬから制御対象機器への命令（例えばＥＣＨＯＮＥＴ  Ｌｉｔｅリクエスト）に変換する機能をゲートウェイ装置７０１は備える。
【０１０４】
本バリエーションにおいて、ＡＰＩは、あらたにゲートウェイ装置７０１がプライベートＡＰＩを備えることを想定したデータ構造になる。一例であるが、パブリックＡＰＩの構成を、以下のようにする実現形態が考えられる。
【表４】
2016177795.tif 000006
この場合、一方プライベートＡＰＩは、例えば以下のようになる。
【表５】
2016177795.tif 000007
【０１０５】
これに対応づけて、対象機器情報記憶部１１８のテーブル構造を２階層してもよい。すなわちゲートウェイ識別子とベースとなるＵＲＬ（プライベートおよびパブリック用のそれぞれのＵＲＬ）とを記憶したテーブルと、属するゲートウェイ識別子を含む対象機器情報で構成されるテーブル（この場合、機器識別情報は、アクセス認可装置内で一意に識別できるものでなく、ゲートウェイ装置内で一意に識別できるレベルの識別子であってもよい）と、で構成する方法が考えられる。
または、１階層で構成し、各対象機器情報が、属するゲートウェイ識別情報と、ベースとなるそのＵＲＬ情報（図２における認可対象情報）を保持するように構成してもよい。
これにより、アクセス認可装置１０１は、対象機器の特定と同時に適切なゲートウェイ装置のプライベートＡＰＩを特定することができる。本バリエーションにより、クラウドＡＰＩとゲートウェイ装置のプライベートＡＰＩを、シームレスに切り替えることが可能となる。
【０１０６】
（第２の実施形態）
本実施形態は、ユーザが宅外から宅内に移動すると、ユーザのポリシー設定に基づき、パブリックＡＰＩ利用からプライベートＡＰＩ利用に切り替えるか否かをユーザに問い合わせる等、いくつかの機能を追加したことを特徴とする。以下、本実施形態について詳細に説明する。
【０１０７】
図１０は、第２の実施形態に係る通信システムを示す。第１の実施形態に対しアクセス認可装置の構成が異なっている。本実施形態のアクセス認可装置１２１は、ポリシー記憶部１４３と、対象機器登録部１４２と、アクセス制御部１４１が新たに追加されている。
【０１０８】
ポリシー記憶部１４３は、ＡＰＩ切り替え（あるいはトークン切り替え）に関するポリシー情報を記憶する。ポリシー情報は、一例として、ユーザにＡＰＩの切り替え（あるいはトークンの切り替え）を問い合わせるか否かの設定を含む。別の例として、宅内にいても、常にパブリックＡＰＩを使用することを示す設定を含むポリシーもあり得る。
【０１０９】
対象機器登録部１４２は、対象機器３０１から登録要求、あるいは、更新要求を受信し、当該要求に従って、対象機器情報記憶部１１８に情報を記憶または情報を更新する。本実施形態では、対象機器３０１は、対象機器３０１のＩＰアドレスまたはホスト名またはこれらの両方等が変更される際に、更新要求を発行する。対象機器情報記憶部１１８にはＩＰアドレスまたはホスト名に基づくプライベートＡＰＩパスが登録されており（図３参照）、ＩＰアドレスまたはホスト名が変更されれば、プライベートＡＰＩパスも更新する。ＩＰアドレスまたはホスト名からプライベートＡＰＩパスを生成する仕組みは事前に定まっているものとする。
または、対象機器３０１が、変更後のＩＰアドレスまたはホスト名に基づきプライベートＡＰＩパスを生成し、これを含む更新要求をアクセス認可装置１５１に送信してもよい。この場合は、更新要求に含まれるプライベートＡＰＩパスを対象機器情報記憶部１１８に登録すればよい。
登録要求の場合も同様であり、ＩＰアドレスまたはホスト名から対象機器登録部１４２がプライベートＡＰＩパスを生成してもよいし、対象機器３０１が、ＩＰアドレスまたはホスト名に基づきプライベートＡＰＩパスを生成し、これを含む登録要求をアクセス認可装置１５１に送信してもよい。
なお、プライベートＡＰＩパスが変更または登録された場合は、これに応じて図２のトークン記憶部１１７内のプライベートＡＰＩ用の認可対象情報（ＡＰＩ情報）も、変更後のプライベートＡＰＩパスに基づいたものに更新するものとする。
対象機器登録部１４２を、図１、図７、図８または図９のアクセス認可装置に設けてもよい。
【０１１０】
アクセス制御部１４１は、トークン発行部１１２がプライベートＡＰＩへのアクセストークンを発行する場合に、アクセス対象の対象機器３０１にプライベートＡＰＩの有効化要求を送信する。あるいは、プライベートＡＰＩへのアクセストークンを無効化する場合に、対象機器３０１にプライベートＡＰＩの無効化要求を送信する。
【０１１１】
対象機器３０１は、アクセス制御部１４１から有効化要求を受けると、対象機器３０１のプライベートＡＰＩをホームネットワーク（第２ネットワーク６０１）からアクセス可能にする。また、対象機器３０１は、アクセス制御部１４１から無効化要求を受けると、対象機器３０１のプライベートＡＰＩをホームネットワーク（第２ネットワーク６０１）からアクセスできないようにする。具体的には、対象機器３０１において、通信装置２０１に搭載されるクライアントからのアクセスを受け付けるサーバ機能の起動または停止を行う。
【０１１２】
あるいは、アクセス制御部１４１を、単に、有効化または無効化のトリガーを与えるように構成にし、実際に有効化または無効化するかは、対象機器３０１側で判断するようにしてもよい。またアクセス制御部１４１は、初回のプライベートＡＰＩ発行時には、プライベートＡＰＩを有効化する更新ファームウェアを、対象機器に送信するようにしてもよい。
【０１１３】
以下、第２の実施形態に係る通信シーケンスを示す。ここでは第１の実施形態に係る通信シーケンス（図４および図５）との差分のみを説明する。
【０１１４】
図４のステップ１の前に、対象機器３０１が、初期登録処理として、ＩＰアドレスなど対象機器情報を、アクセス認可装置１５１の対象機器登録部１４２を介して、対象機器情報記憶部１１８に登録する。このとき、アクセス認可装置１５１は、対象機器３０１の認証を行う必要がある。また、ユーザと当該対象機器３０１を関連づける必要がある。認証および関連づけの双方について、様々な実現方法がある。
【０１１５】
例えば、対象機器３０１に予め装置認証用の秘密情報を登録しておき、これを、アクセス認可装置１５１に送信することで、正当な対象機器３０１のみが対象機器情報をアクセス認可装置１５１に登録できるようにする。また、ユーザは、対象機器３０１の秘密情報と共に、所有機器の情報をアクセス認可装置１５１に登録する。シンプルな実現方法としては、対象機器３０１の筐体に秘密情報が貼り付けてあり、アクセス認可装置１５１の登録画面を介して、ユーザがこれを手動登録する等がある。ここで述べた例は一例であり、他にも様々な方法が可能である。
【０１１６】
なお、対象機器３０１は、初期登録処理時だけでなく、ＩＰアドレスの変更など機器情報の変更を検知すると、その都度、アクセス認可装置１５１に対象機器情報の更新要求を送信する。アクセス認可装置１５１の対象機器登録部１４２は、更新要求に基づき、対象機器情報記憶部１１８内の対象機器３０１に関する情報を更新する。
【０１１７】
図４のステップ１の認可画面に、ポリシー情報の選択インタフェースを表示し、宅外から宅内へ移動した場合に、ＡＰＩ切り替え（トークン切り替え）の確認画面を表示するか否かの設定を含むポリシー情報を、ユーザに選択可能に表示させてもよい。他の種類のポリシー情報も表示し、ユーザが任意のポリシー情報を選択できるようにしてもよい。もちろん、ユーザは、どのポリシー情報を選択しなくてもよく、この場合、第１の実施形態と同様の動作となる。
【０１１８】
図４のステップ２で、ユーザは、認可画面に表示されたポリシー情報を選択する。
【０１１９】
図４のステップ３で、通信装置からアクセス認可装置１５１に送信するトークン発行要求に、ユーザが選択したポリシー情報を含める。
【０１２０】
図４のステップ８で、トークン発行時にパブリックＡＰＩ用のアクセストークンと関連付けて、ポリシー情報を登録する。上記例では、ポリシー情報の設定をステップ２で行うユーザの認可と関連付けているが、ステップ２のユーザの認可と独立して、ポリシー設定を行えるように構成してもよい。
【０１２１】
図５のステップ１７とステップ１８の間で、ステップ１７Ａとして、通信装置２０１はＡＰＩ切り替え（トークン切り替え）の確認画面を表示する。例えば、そのままパブリックＡＰＩを使い続けるか、プライベートＡＰＩに切り替えるかを、ユーザに選択させる確認画面を表示する。確認画面の例を図１１（Ａ）に示す。ここでは、ユーザがプライベートＡＰＩに切り換える選択をした場合を想定する。
【０１２２】
図５のステップ２１とステップ２２の間で、ステップ２１Ａとして、アクセス認可装置１５１のアクセス制御部１４１は、対象機器３０１に、プライベートＡＰＩの有効化要求を送信する。対象機器３０１は、有効化要求を受けて、プライベートＡＰＩをホームネットワークからアクセス可能にする。具体的には、通信装置２０１に搭載されるクライアントがアクセスするサーバ機能（ＨＴＴＰサーバ）を対象機器３０１が起動する。反対に、プライベートＡＰＩからパブリックＡＰＩに切り替える場合には、アクセス制御部１４１は対象機器３０１に無効化要求を行うように構成してもよい。この場合、対象機器３０１は、サーバ機能の動作を停止させる。なお、プライベートＡＰＩからパブリックＡＰＩに切り替える場合には、図１１（Ｂ）に示す確認画面を表示して、ユーザに切り換えを許可するか選択させてもよい。
【０１２３】
なお、ステップ２２において、対象機器３０１のＩＰアドレスが変更されている場合には、これに追従した新しいプライベートＡＰＩに対するアクセストークンを発行することができる。
【０１２４】
以上、本実施形態によれば、ユーザが、より柔軟なポリシー設定に基づき、パブリックＡＰＩおよびプライベートＡＰＩ間の切り替えを制御できる。また、対象機器３０１のＩＰアドレスが変化することに起因して、クライアントがプライベートＡＰＩへのアクセスに失敗するケースを回避できる。また、必要時にのみプライベートＡＰＩを有効化することで、ホームネットワーク上でのリソース利用のセキュリティを高めることができる。
【０１２５】
（第３の実施形態）
第１および第２の実施形態では、宅内ネットワークの対象機器にアクセスするプライベートＡＰＩは１つのみであったが、複数のプライベートＡＰＩが存在する場合もある。例えば、ゲートウェイ装置（図９参照）が複数のプライベートＡＰＩを備える場合がある。このとき、アクセス認可装置（サーバ）１０１は、通信装置２０１に、どちらのプライベートＡＰＩの使用を許可すれば、通信装置２０１上のクライアント（アプリ）が、対象機器を操作（アクセス）できるか分からない。このことを、図１２を用いて説明する。
【０１２６】
図１２に本実施形態に係る通信システムの例を示す。ゲートウェイ装置９０１は、第２ネットワーク６０１側のインタフェースからアクセス可能なプライベートＡＰＩ（プライベートＡＰＩ−１と記述する）と、第３ネットワーク８０１側のインタフェースからアクセス可能なプライベートＡＰＩ（プライベートＡＰＩ−２と記述する）とを有する。第２の実施形態では通信装置２０１が、第２ネットワーク６０１に接続されていたが、図９では、第３ネットワーク８０１に接続されている。通信装置２０１が第２ネットワーク６０１に接続される場合は破線で示している。ゲートウェイ装置９０１の第２ネットワーク６０１側のネットワークアドレスと、第３ネットワーク８０１側のネットワークアドレスとは互いに異なる。例えば第２ネットワーク６０１側のネットワークアドレスが、１９２．１６８．０．０／２４であり、第３ネットワーク８０１側のネットワークアドレスが、１９２．１６８．１２６．０／２４である。
【０１２７】
通信装置２０１上のクライアントは、通信装置２０１が第３ネットワーク８０１に接続されているときは、プライベートＡＰＩ−２にアクセスすれば、ゲートウェイ装置９０１を介して、対象機器（３０１または３０２）を操作可能である。クライアントは、プライベートＡＰＩ−１にアクセスした場合は、対象機器を操作できない。一方、通信装置２０１上のクライアントは、通信装置２０１が第２ネットワーク６０１に接続されているときは、プライベートＡＰＩ−１にアクセスすれば、ゲートウェイ装置９０１を介して、対象機器を操作可能である。ただし、クライアントは、プライベートＡＰＩ−２にアクセスした場合は、対象機器を操作できない。
【０１２８】
アクセス認可装置１０１が、通信装置２０１が第２ネットワーク６０１および第３ネットワーク８０１のどちらに接続されているかを把握できれば、それに応じて適切なプライベートＡＰＩ情報を通信装置２０１に通知することも可能である。しかしながら、アクセス認可装置１０１が、通信装置２０１がどちらのネットワークに接続されているかを把握できない場合もある。例えば中継装置４０１のＮＡＴ機能により、中継装置４０１の配下の装置からの送信パケットの送信元アドレスは中継装置４０１のグローバルＩＰアドレスに統一され、アクセス認可装置１０１では、通信装置２０１がどのローカルネットワーク（６０１、８０１）に接続されているかを判断できない。
【０１２９】
そこで、本実施形態では、アクセス認可装置１０１が、ゲートウェイ装置の複数のプライベートＡＰＩ情報を通信装置２０１に通知する。通信装置２０１が複数のプライベートＡＰＩ情報のうち、利用可能なプライベートＡＰＩ情報を特定し、特定したプライベートＡＰＩ情報を用いて、ゲートウェイ装置を介して、対象機器にアクセス（対象機器を操作）する。本実施形態に係る対象機器情報記憶部の構成例を図１３に示す。デバイス識別子が“ｈｗｇ１”のゲートウェイ装置のプライベートAPIパスが２つ登録されている。なお、APIパスの登録形態は、図１３（および前述した図３）では、“https://”と“/V1”との間にIPアドレスを配置した形態であるが、IPアドレスのみの形態でもよいし、“/V1”を省いた形態でもよいし、その他の形態でもよい。
【０１３０】
以下、本実施形態の動作例を示す。なお、図９を用いて行った説明と重複する説明は、適宜省略する。
【０１３１】
まず、初期設定として、通信装置２０１がアクセストークンの発行を受けるまでの動作例を示す。
【０１３２】
スマートフォン等の通信装置２０１上で動作するクライアント（アプリケーション）は、対象機器における特定機能（録画予約など）を利用するために、アクセス認可装置１０１に、トークン発行要求を送信する（図４のステップ３）。
【０１３３】
トークン発行要求を受けたアクセス認可装置１０１は、クライアント認証およびユーザ認証を行う（ステップ５およびステップ６）。ユーザ認証とともに、ユーザの認可を求める画面を通信装置２０１に表示させてもよい。この場合、例えば、トークン発行要求を認証認可ＵＲＬへ転送（リダイレクト）してもよい。ユーザは、自身の認証情報と、クライアントによる特定機能の利用を認可する旨とを入力する。認証および認可のいずれかが正しく行われなかった場合、トークン発行を行うことができない旨を、アクセス認可装置１０１はクライアントに通知する。
【０１３４】
認証および認可が正しく行われた場合、通信装置の状態判定（通信装置２０１が宅内に存在するか、宅外に存在するか）に応じて、パブリックまたはプライベート用のアクセストークンが、クライアントに対して発行される。または、アクセストークンに加えて、リフレッシュトークンを発行してもよい、両方の役割を兼ねた単一のアクセストークンを発行してもよい。
【０１３５】
通信装置２０１（クライアント）が宅外に存在し、パブリックアクセス用のアクセストークンが発行された場合の、以降のＡＰＩアクセス手順を述べる。
【０１３６】
アクセストークンを受け取ったクライアントは、パブリックＡＰＩ情報に基づき、アクセス認可装置１０１に対して、録画予約などのパブリックＡＰＩアクセスを行う（図４のステップ９）。これに先駆けて、クライアントは、宅外に自身が存在することを確認するために、アクセス認可装置などに、クライアントの状態判定（宅内と宅外のどちらに存在するか）を要求してもよい。
【０１３７】
パブリックＡＰＩアクセスを受けたアクセス認可装置は、アクセストークンの有効性の検証と、通信装置２０１（クライアント）の状態判定（宅内と宅外のどちらに存在するか）を行う（ステップ１０、ステップ１１）。アクセストークンが有効であり、通信装置２０１が宅外に存在する場合は、アクセス認可装置は、対象機器（録画機器等）に対して、録画予約などの制御を実行する。具体的には、アクセス代行部１１６が、通信装置２０１からのパブリックＡＰＩへのアクセスを受けて、アクセス代行部１１６がリソースの利用要求をゲートウェイ装置９０１に送信する（ステップ１２、ステップ１３）。なお、アクセス代行部１１６がゲートウェイ装置９０１を利用する方法は事前に定められているものとする。専用のＡＰＩが用意されていてもよいし、プライベートＡＰＩのＵＲＬを含むデータをゲートウェイ装置９０１に送信し、ゲートウェイ装置９０１が当該データに含まれるプライベットＡＰＩのＵＲＬを内部的に解釈および実行してもよい。一方、アクセストークンが有効でない場合、または通信装置２０１が宅内に存在すると判断した場合、パブリックＡＰＩアクセスを許可できない旨を、クライアントに応答する（図５のステップ１６、ステップ１７、およびステップ１７に続く“認可エラー応答”のシーケンスを参照）。
【０１３８】
なお、アクセストークンの有効性の検証において、アクセストークンが有効でないと判断された場合は、アクセス認可装置は、自装置へのアクセス情報（トークン発行要求の方法など）を、クライアントに通知しても良い。
【０１３９】
通信装置２０１（クライアント）のユーザが、通信装置２０１を保持したまま、宅外から宅内に移動したとする。すなわち、通信装置２０１が宅外に存在する状態から、宅内に存在する状態に変わったとする。この場合に、通信装置２０１上のクライアントが、パブリックＡＰＩ情報に基づき、アクセス認可装置１０１に対して、録画予約などのパブリックＡＰＩアクセスを行ったとする（図４のステップ９）。アクセス認可装置１０１は、通信装置２０１の状態判定において、通信装置２０１が宅内に存在すると判断して、パブリックＡＰＩアクセスを許可できない旨を、クライアントに応答する（図５のステップ１６、ステップ１７、およびステップ１７に続く“認可エラー応答”のシーケンスを参照）。これにより、クライアントは、通信装置２０１が宅外から宅内に移動したことを知る。あるいは、前述のように、クライアントが、通信装置２０１が宅外および宅内のいずれの状態であるかを確認するために、アクセス認可装置などに状態判定を要求してもよい。
【０１４０】
通信装置２０１上のクライアントは、トークン発行要求（例えばリフレッシュトークンを含む）をアクセス認可装置１０１に送信し（図５のステップ１８）、アクセス認可装置１０１は、リフレッシュトークンを検証し、状態判定を行う。ここでは、検証に成功し、通信装置２０１が宅内に存在すると判断する。そして、アクセス認可装置１０１は、通信装置２０１に提供する認可対象情報（ＡＰＩ情報）を決定する。ここでは、前述したように、ゲートウェイ装置９０１のデバイス識別子（ｄｅｖｉｃｅ＿ｉｄ）に対して複数のプライベートＡＰＩが存在する。第１の実施形態の図９の例では、プライベートＡＰＩパスが１つ存在したが、本実施形態では複数のプライベートＡＰＩパスが存在する。なお、ＡＰＩパスごとに、機能（“ｓｔａｔｕｓ”または“ｒｅｓｅｒｖｅｄ＿ｐｒｏｇｒａｍ”）ごとのＡＰＩ情報（図２参照）が存在する。
【０１４１】
アクセス認可装置１０１は、クライアントから要求された機能（録画等）に対応する複数のＡＰＩ情報を含むリストを送信する。複数のＡＰＩ情報のリストの代わりに、複数のＡＰＩパスを含むリストを送信してもよい。この場合、ＡＰＩパスの末尾には端末側で、機能に応じた文字列を付加して、ＡＰＩ情報と同じものを生成できるものとする。ＡＰＩパスは、ＡＰＩ情報の一部（例えばＡＰＩ情報から機能を特定する部分を除いたもの）に相当する（図２および図３参照）。通信装置２０１が、ゲートウェイ装置９０１が備える複数のインタフェースのうちのどれと同じネットワークに接続されているかは、アクセス認可装置では分からない場合があり、複数のＡＰＩ情報のうちの１つを特定することはできない。このため、アクセス認可装置１０１は、ゲートウェイ装置が備えるすべてのプライベートＡＰＩパス（またはクライアントから要求された機能に関するすべてのプライベートＡＰＩ情報）のリストを提供する。なお、上述したようなクライアントが状態判定を要求した際に、プライベートＡＰＩパスのリストを、アクセス認可装置１０１からクライアントに提供してもよい。
【０１４２】
複数のプライベートＡＰＩ情報のリスト（または、プライベートＡＰＩパスのリスト）を受け取ったクライアントは、どのプライベートＡＰＩ情報を利用するか判定する必要がある。これには複数の方法が考えられる。
【０１４３】
（第１の方法）各ＡＰＩパスを順番に選択して、選択したＡＰＩパスに対して、ｄｅｖｉｃｅ＿ｉｄの返信を要求するメッセージを送信する。選択したＡＰＩパスが、利用できないＡＰＩパスなら、応答は来ない。選択したＡＰＩパスが、期待したＡＰＩパスと異なっているなら、応答されるｄｅｖｉｃｅ＿ｉｄは、自装置がアクセスしたい装置のｄｅｖｉｃｅ＿ｉｄ（期待する値）と異なる（例えば複数のサブネットが存在し、サブネットごとに同じＩＰアドレスのゲートウェイ装置が存在する状況があり得る）。応答されたｄｅｖｉｃｅ＿ｉｄと、期待する値とが一致した場合、選択したＡＰＩパスは正解である。正解のＡＰＩパスが分かった後は、正解のＡＰＩパスを含むプライベートＡＰＩ情報に基づき、ＡＰＩアクセスを実行する（図５のステップ２３）。このとき、ゲートウェイ装置９０１は、アクセス認可装置１０１に対して、ＡＰＩアクセスでクライアントから送られるトークンの検証を要求する（図５のステップ２４）。この際、アクセス認可装置が備えるｔｏｋｅｎ  ｉｎｔｒｏｓｐｅｃｔｉｏｎ  ｅｎｄｐｏｉｎｔを利用してもよい。
【０１４４】
（第２の方法）クライアントは、ＡＰＩ情報のリストとともに、アクセス認可装置１０１からサーバ証明書（非対称）または事前共有鍵（ＰＳＫ、対称）またはこれらの両方を受信する。アクセス認可装置は、サーバ証明書または事前共有鍵等も、ゲートウェイ装置のｄｅｖｉｃｅ＿ｉｄに対応づけて、事前に内部に記憶しておく。クライアントは、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ）またはＤＴＬＳ（Ｄａｔａｇｒａｍ  Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ）などの認証機能を使って、正解のＡＰＩパスを判定する。ネットワークで利用できないＡＰＩパスを用いて認証を試みたなら、ゲートウェイ装置９０１から応答は来ない（ＩＰレイアの通信に失敗する）。また、期待するＡＰＩパスと異なるＡＰＩパスを用いた場合、認証に失敗する。つまり、ＩＰレイヤでの通信は成功するが、ＴＬＳ等の認証に失敗する。正解のＡＰＩパスが分かった後の動作は、第１の方法と同様である。
【０１４５】
第１の方法および第２の方法以外の方法を用いて、使用するＡＰＩパスを決定してもよい。
【０１４６】
図１４に、アクセス認可装置から複数のＡＰＩパスを取得し、利用するＡＰＩパスを特定する場合の動作のシーケンス例を示す。ゲートウェイ装置は、自装置が有する複数のＡＰＩパスを、アクセス認可装置に通知する（ステップ７１）。アクセス認可装置は、通知された複数のＡＰＩパスを登録し、応答を返す（ステップ７２）。なお、応答のパケットの送信先のアドレスは、例えばグローバルＩＰアドレス（例えば“１３３．１９６．２９．２”）であるが、ルータ４０１のＮＡＴ機能により、送信先のアドレスは、ローカルのＩＰアドレスに変換されて、パケットがゲートウェイ装置に届く。なお、ＩＰアドレスのみでなく、宛先ポート番号も変換される構成もある。
【０１４７】
通信装置上のクライアントが、宅内に存在する状況において、アクセス認可装置に対して、ゲートウェイ装置が備える複数のＡＰＩパスを含むリストを応答するよう、要求したとする（ステップ７３）。
【０１４８】
アクセス認可装置は、クライアントのユーザに関連づけられて登録されているゲートウェイ装置を特定（または、パケットの送信元アドレスに関連づけられて登録されているゲートウェイ装置を特定）し、特定したゲートウェイ装置が備える複数のＡＰＩパスを特定する。
【０１４９】
ここでは、アクセス認可装置は、２つのゲートウェイ装置（図のｈｇｗ１と、ｈｇｗ２）を特定し、それぞれに対して、２つのＡＰＩパス（ＷＡＮ側のインタフェースのＡＰＩパスと、ＬＡＮ側のインタフェースのＡＰＩパス）を特定する。なお、ここでのＡＰＩパスは、プライベートＡＰＩパスである。
【０１５０】
アクセス認可装置は、一方のゲートウェイ装置識別子“ｈｇｗ１”とその２つのＡＰＩパス、ならびに、もう一方のゲートウェイ装置の識別子“ｈｇｗ２”とその２つのＡＰＩパス、とを含むメッセージを、通信装置上のクライアントに応答する（ステップ７４）。
【０１５１】
応答のパケットの送信先のアドレスは、例えばグローバルＩＰアドレス（例えば“１３３．１９６．２９．２”）あるが、ルータ４０１のＮＡＴ機能により、送信先のアドレスはローカルのＩＰアドレスに変換されて、パケットが通信装置（クライアント）に届く。なお、ＩＰアドレスのみでなく、宛先ポート番号も変換される構成もある。
【０１５２】
通信装置上のクライアントは、まず一方のゲートウェイ装置（ここではｈｇｗ１）を特定し、特定したゲートウェイ装置が備える複数のＡＰＩパスのうちの一方を選択して、ｄｅｖｉｃｅ＿ｉｄの返答を要求するメッセージを送信する（ステップ７５）。しかしながら、選択したＡＰＩパスは、当該ゲートウェイ装置のＷＡＮ側のネットワークで利用できないため、メッセージに対する応答は送信されない（タイムアウトになる）。通信装置は、もう一方のＡＰＩパスを選択して、ｄｅｖｉｃｅ＿ｉｄの返答を要求するメッセージを送信する（ステップ７６）。アクセス認可装置は、当該メッセージに対して、自装置の識別子“ｈｇｗ１”を含む応答を返す（ステップ７７）。この応答に含まれる識別子は、クライアントが期待する識別子と一致するため、当該ＡＰＩパスに基づくＡＰＩ情報を用いて、ゲートウェイ装置にプライベートＡＰＩアクセスすることにより、ゲートウェイ装置の配下の対象機器を制御する（ステップ７８）。
【０１５３】
図１５に、アクセス認可装置から複数のＡＰＩパスを取得し、利用するＡＰＩパスを１つに特定する場合の動作の他のシーケンス例を示す。最初のステップ７１、７２は図１４と同様である。
【０１５４】
ステップ７２に続くステップ８１では、通信装置上のクライアントが、自装置の状態判定（宅内および宅外のいずれに存在するか）の問い合わせのメッセージを送信する。アクセス認可装置は、状態判定を行うことにより、通信装置が宅内に存在すると判断する。また、アクセス認可装置は、宅内に存在しうるゲートウェイ装置として、ここではｈｇｗ１の１つを特定する（ここでは、たまたまユーザまたは送信元IPアドレスに対して、１つのゲートウェイ装置のみがアクセス認可装置に登録されていたとする）。アクセス認可装置は、ゲートウェイ装置の識別子“ｈｇｗ１”と、その２つのＡＰＩパスとを含むメッセージを、通信装置上のクライアントに応答する（ステップ８２）。この後のステップ７５〜７８は、図１４と同じである。
【０１５５】
図１６は、図１５のシーケンスにおいて通信装置が宅外にいると判定された場合の動作の例を示す。ステップ７１、７２、８１までは図１５と同じである。
【０１５６】
ステップ８１の次のステップ８５として、アクセス認可装置は、通信装置が宅外に存在することを通知するメッセージを送信する。通信装置上のクライアントは、パブリックＡＰＩ情報に基づき、アクセス認可装置に対してパブリックＡＰＩアクセスを行う（ステップ８６、８７）。なお、パブリックアクセス用のアクセストークンの発行をまだ受けていない場合、トークン発行要求を先に行う。
【０１５７】
前述した図１４のシーケンスでは、通信装置が仮に宅外にいる状態で、各APIパスに対する検査（ステップ７５およびステップ７６）を行った場合、各APIパスともタイムアウトになるまで、クライアントは、通信装置が宅外にいることが分からない。タイムアウトになった時点で、クライアントは、宅外アクセスに切り換えることができる。一方、図１５および図１６のシーケンスでは、クライアントがアクセス認可装置に状態判定を要求するため、宅内および宅外のいずれにいるかが事前に分かった上で、クライアントは動作することができる。したがって、図１５および図１６のシーケンスでは、宅外にいる場合の動作の遅延を防止できる利点がある。
【０１５８】
（第４の実施形態）
第１ネットワーク５０１がＣＧＮ（Ｃａｒｒｉｅｒ  Ｇｒａｄｅ  ＮＡＴ）またはＬＳＮ（Ｌａｒｇｅ  Ｓｃａｌｅ  ＮＡＴ）（以下、ＣＧＮ／ＬＳＮと記載）の機能を備える場合を想定する。この場合、アクセス認可装置による状態判定によって、通信装置が宅内に存在すると判断されたにも関わらず、クライアントが、アクセス認可装置から通知された全てのプライベートＡＰＩパスのいずれにもアクセスできない状況が発生する場合がある。
【０１５９】
図１７に、本実施形態に係る通信システムの構成例を示す。図１７の通信システムは、図１０の構成をベースにしている。第１ネットワーク５０１は、ＣＧＮ／ＬＳＮの機能を備えている。中継装置１１０１および第３ネットワーク１１０２は、中継装置４０１、第２ネットワークおよび対象機器３０１とは別の家屋内に配置されている。通信装置１１０３は、スマートフォン等の通信装置である。第３ネットワーク１１０２は、例えばホームネットワーク（ローカルネットワーク）である。ただし、第２ネットワーク６０１の場合と同様、他の種類のネットワークでもよい。中継装置１１０１は、ＮＡＴ機能を備えたブロードバンドルータである。図では通信装置１１０３が第３ネットワーク１１０２に接続されている。通信装置１１０３は、中継装置１０１を介して第１ネットワーク５０１に接続されている。ただし、通信装置１１０３は、第１ネットワーク５０１に直接接続することも可能である。
【０１６０】
通信装置１１０３が第３ネットワーク１１０２に接続されているときに、第２ネットワーク６０１に接続された対象機器３０１を制御する場合を考える。通信装置１１０３上のクライアントが、中継装置１１０１を介してアクセス認可装置１５１に、プライベートＡＰＩアクセス用のトークン発行要求（図５のステップ１８）を送信する。アクセス認可装置が、トークン検証および状態判定を行い、通信装置１１０３が宅内に存在すると判断する。
【０１６１】
第１ネットワーク５０１がＣＧＮ／ＬＳＮの機能を備える場合、中継装置１１０１および中継装置４０１のいずれのＷＡＮ側インタフェース（第１ネットワーク５０１側のインタフェース）にも、それぞれローカルＩＰアドレスが割り当てられる場合がある。この場合、中継装置４０１の宅内から送信されるパケットの送信元ＩＰアドレスも、中継装置１１０１の家屋内から送信されるパケットの送信元ＩＰアドレスも、ＣＧＮ／ＬＳＮにより、同一のグローバルＩＰアドレスに変換されて、アクセス認可装置１５１に送信される。したがって、アクセス認可装置１５１では、ＩＰアドレスを元に状態判定を行う場合、通信装置１１０３が第３ネットワーク１１０２および第２ネットワーク６０１のどちらに接続されているかを区別できない。このためアクセス認可装置は、通信装置１１０３が、中継装置４０１の宅内に存在すると判断し、対象機器３０１のプライベートＡＰＩパス（またはプライベートAPI情報）を含む応答を、通信装置１１０３に送信する。なお、ここでは第３ネットワーク１１０２にはAPIアクセス可能な対象機器が存在しない場合を想定する。
【０１６２】
通信装置１１０３上のクライアントは、通知されたプライベートＡＰＩ情報を用いて対象機器３０１にアクセスしようとしても、対象機器３０１と同じ家屋（ローカルネットワーク）に存在しないため、対象機器３０１にアクセスできない。例えば、第１ネットワーク５０１内のルータからパケットを転送できない旨のエラーメッセージが返ってきたり、タイムアウトになったり、対象機器３０１のプライベートＡＰＩパスがドメイン名などを用いて表現されている場合にIPアドレスをDNSから取得できない、などのエラーが発生し得る。この問題を解決するため、以下の複数の方法が考えられる。本実施形態では、これらのいずれかの方法を実行する。
【０１６３】
（第１の方法）通信装置１１０３上のクライアントは、エラー発生後、一定時間をおいて、アクセス認可装置に、状態判定の要求、またはトークン発行要求（図５のステップ１８）を行う。ＣＧＮ／ＬＳＮ機能を備えたネットワークでは、ＮＡＴの適用箇所が時間経過によって変わる場合がある。この場合、中継装置１１０１（ローカルIPアドレスしかもっていない）からのパケットはグローバルIPアドレス #1 からのパケットに変換され、中継装置４０１からのパケットはグローバルIP アドレス#2からのパケットに変換されることもある（ある時刻は両方ともグローバルＩＰアドレスは#1だった）。。これによりアクセス認可装置の対象機器情報記憶部１１８等が更新され、状態判定の結果も変わり得る。例えば、通信装置１１０３が、中継装置４０１の宅外に存在すると判断される。これにより通信装置１１０３は、アクセス認可装置により宅外に存在すると判断され、パブリックＡＰＩパス（またはパブリックAPI情報）が通信装置１１０３に送られる。通信装置１１０３は、パブリックＡＰＩ情報に基づき、アクセス認可装置１５１を介して対象機器３０１を操作する。
【０１６４】
（第２の方法）通信装置１１０３は、アクセス認可装置１５１から通知されたプライベートＡＰＩ情報で、対象機器３０１にアクセスできない旨を伝えるフラグを立てたメッセージを、アクセス認可装置１５１に送信する。このフラグが立てられたメッセージを受信した場合、アクセス認可装置は、状態判定を省略する。この際、状態判定を省略したことのログをとってもよい。状態判定を省略した場合、アクセス認可装置１５１は、通信装置１１０３に対して、対象機器３０１に対するパブリックＡＰＩ情報を通知またはパブリックアクセス用のアクセストークンを発行するようにすればよい。
【０１６５】
（第３の方法）通信装置１１０３は、プライベートＡＰＩ情報でのアクセスに失敗したときのエラー内容（応答パケットなど）を含むメッセージを、アクセス認可装置１５１に送信する。アクセス認可装置は、当該メッセージに含まれるエラー内容を、メモリ装置等の記憶装置に記録する。過去に報告されたエラー内容や、その他の情報と照合して、そのエラー内容が尤もらしいかどうかを判定する（公知の尤度判定を行えばよい）。尤度が一定値以上であれば、状態判定を省略し、上記と同様の処理を行えばよい。
【０１６６】
尚、各実施形態のアクセス認可装置、通信装置および対象機器の各装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現可能である。すなわち、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現出来る。このとき、各装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現することや、各種の記憶媒体に記憶、あるいはネットワークを介して上記のプログラムを配布、このプログラムをコンピュータ装置に適宜インストールすることで実現が出来る。また、各装置内の各記憶部は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。
【０１６７】
本発明は上記実施形態そのままに限定されず、実施段階では要旨を逸脱しない範囲で構成要素を変形し具体化出来る。上記実施形態に開示されている複数の構成要素の適宜な組み合わせで、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除出来、異なる実施形態に渡る要素を適宜組み合わせることも出来る。
【符号の説明】
【０１６８】
１０１：アクセス認可装置
２０１：通信装置
３０１：対象機器
３０２：対象機器
４０１：中継装置
５０１：第１ネットワーク
６０１：第２ネットワーク
７０１：ゲートウェイ装置
８０１：第３ネットワーク 
１１１：通信部
１１２：トークン発行部
１１３：認可対象決定部
１１４：状態判定部
１１５：トークン検証部
１１６：アクセス代行部
１１７：トークン記憶部
１１８：対象機器情報記憶部
１１９：認可対象提供部
１４１：アクセス制御部
１４２：対象機器登録部
１４３：ポリシー記憶部
【図１】
2016177795.tif 000008
【図２】
2016177795.tif 000009
【図３】
2016177795.tif 000010
【図４】
2016177795.tif 000011
【図５】
2016177795.tif 000012
【図６】
2016177795.tif 000013
【図７】
2016177795.tif 000014
【図８】
2016177795.tif 000015
【図９】
2016177795.tif 000016
【図１０】
2016177795.tif 000017
【図１１】
2016177795.tif 000018
【図１２】
2016177795.tif 000019
【図１３】
2016177795.tif 000020
【図１４】
2016177795.tif 000021
【図１５】
2016177795.tif 000022
【図１６】
2016177795.tif 000023
【図１７】
2016177795.tif 000024