JP2016177795A - Access authorization apparatus, access authorization method, program and communication system - Google Patents
Access authorization apparatus, access authorization method, program and communication system Download PDFInfo
- Publication number
- JP2016177795A JP2016177795A JP2016046197A JP2016046197A JP2016177795A JP 2016177795 A JP2016177795 A JP 2016177795A JP 2016046197 A JP2016046197 A JP 2016046197A JP 2016046197 A JP2016046197 A JP 2016046197A JP 2016177795 A JP2016177795 A JP 2016177795A
- Authority
- JP
- Japan
- Prior art keywords
- access
- communication device
- request
- network
- communication
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Abstract
Description
本発明の実施形態は、アクセス認可装置、アクセス認可方法、プログラムおよび通信システムに関する。 Embodiments described herein relate generally to an access authorization device, an access authorization method, a program, and a communication system.
家電などのホームネットワーク内の機器が、スマートフォン等に搭載されたアプリケーションに対して提供するＲＥＳＴ ＡＰＩ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）（以下、プライベートＡＰＩ）へのアクセス認可を、家電以外の機器で行う方法が知られている。アクセス認可とは、特定のアプリケーションがアクセスしてよいか否かの判断のことである。 A device in a home network such as a home appliance authorizes access to a REST API (Representative State Transfer Programming Interface) (hereinafter referred to as a private API) provided to an application installed in a smartphone or the like. The method is known. Access authorization is the determination of whether or not a specific application can access.
一方、機器がインターネット上などの外部サーバに接続され、外部サーバ経由で当該機器の監視や制御が実現可能なシステムにおいて、外部サーバが、プライベートＡＰＩと同様のＲＥＳＴ ＡＰＩを公開し、このＲＥＳＴ ＡＰＩ経由で当該機器の制御を行う方法が知られている。当該外部サーバが公開するＡＰＩを以降、パブリックＡＰＩと呼ぶ。 On the other hand, in a system in which a device is connected to an external server such as the Internet and the device can be monitored and controlled via an external server, the external server publishes a REST API similar to a private API, and passes through this REST API. A method for controlling the device is known. The API released by the external server is hereinafter referred to as a public API.
上記２つのＡＰＩ（プライベートＡＰＩとパブリックＡＰＩ）が併存するケースにおいて、ユーザには両者を切り替えるメリットがある。例えば、宅内での利用時にはプライベートＡＰＩに切り換えることで、サーバに制御ログを残さなくてすむ。また、法的に切り替えを義務付けられる可能性もある。しかしながら、正当なアプリケーションにだけアクセス認可しつつ、両者をシームレスに切り替える方法は知られていない。 In the case where the two APIs (private API and public API) coexist, the user has an advantage of switching between the two. For example, when using in a home, it is not necessary to leave a control log on the server by switching to a private API. In addition, there is a possibility that legal switching is required. However, there is no known method for seamlessly switching between both while authorizing access only to legitimate applications.
本発明の実施形態は、対象機器が提供するリソースへアクセスする手法を適切に切り替えることを目的とする。 An object of the embodiment of the present invention is to appropriately switch a method of accessing a resource provided by a target device.
本発明の実施形態としてアクセス認可装置は、通信部と、状態判定部と、アクセス代行部と、決定部とを備える。前記通信部は、ネットワークに接続された対象機器と、および前記対象機器が提供するリソースを利用可能な通信装置と通信する。前記状態判定部は、前記通信装置と前記ネットワークとの接続状態を特定するための情報を前記通信装置および前記対象機器の少なくとも一方から取得し、前記情報に基づき前記接続状態を判定する。前記アクセス代行部は、前記対象機器が提供するリソースの利用要求を前記対象機器に送信する。前記決定部は、前記接続状態に基づき、前記対象機器が提供するリソースの利用要求を前記通信装置が前記対象機器に送信するか、前記アクセス代行部が前記対象機器に送信するかを決定する。 As an embodiment of the present invention, an access authorization device includes a communication unit, a state determination unit, an access proxy unit, and a determination unit. The communication unit communicates with a target device connected to a network and a communication device that can use resources provided by the target device. The state determination unit acquires information for specifying a connection state between the communication device and the network from at least one of the communication device and the target device, and determines the connection state based on the information. The access proxy unit transmits a request for using a resource provided by the target device to the target device. The determination unit determines whether the communication device transmits a resource use request provided by the target device to the target device or the access proxy unit transmits to the target device based on the connection state.
以下、図面を参照しながら、本発明の実施形態について説明する。 Hereinafter, embodiments of the present invention will be described with reference to the drawings.
（第１の実施形態）
本実施形態は、ユーザが宅外から宅内に移動すると、利用するＡＰＩを自動的にパブリックＡＰＩから、プライベートＡＰＩに切り替えるように制御することを特徴とする。以下、本実施形態について詳細に説明する。
(First embodiment)
The present embodiment is characterized in that when the user moves from outside the house to the house, the API to be used is automatically switched from the public API to the private API. Hereinafter, this embodiment will be described in detail.
図１は、本発明の第１の実施形態に関わる通信システムの構成図である。この通信システムは、アクセス認可装置１０１と、通信装置２０１と、対象機器３０１と、中継装置４０１と、第１ネットワーク５０１と、第２ネットワーク６０１とを備える。
FIG. 1 is a configuration diagram of a communication system according to the first embodiment of the present invention. This communication system includes an
第１ネットワーク５０１は、広域通信網である。本実施形態では、具体的には、インターネットを想定している。ただし、ＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）など、閉域網を含むその他のネットワークであっても構わない。
The
第２ネットワーク６０１は、ローカル通信網である。本実施形態では、具体的には、ホームネットワークを想定している。物理媒体は有線（Ｅｔｈｅｒｎｅｔ（登録商標）等）、無線（ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｚｉｇｂｅｅ（登録商標）等）を問わない。上位の通信プロトコルは、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）であることを想定しているが、これも本実施形態の通信シーケンスが同様に実行される限りにおいて、どのような通信プロトコルであってもよい。 The second network 601 is a local communication network. In this embodiment, specifically, a home network is assumed. The physical medium may be wired (Ethernet (registered trademark) or the like) or wireless (WiFi, Bluetooth (registered trademark), Zigbee (registered trademark), or the like). The upper communication protocol is assumed to be IP (Internet Protocol), but any communication protocol may be used as long as the communication sequence of the present embodiment is similarly executed.
中継装置４０１は、第１ネットワーク５０１と第２ネットワーク６０１を接続するルータである。本実施形態では、ホームネットワークとインターネットを接続する、ＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）機能を備えたブロードバンドルータであることを想定している。
The
通信装置２０１は、エンドユーザが利用するスマートフォン、タブレット、ＰＣ等の装置である。本実施形態では、通信装置２０１はスマートフォンであることを想定している。ユーザは、宅外・宅内を問わずに、スマートフォンを携帯し、利用する。アクセス認可装置１０１が認可を与える対象は、スマートフォン上で動作するプログラムを構成要素として持つ、アプリケーションである。図１では、通信装置２０１は第１ネットワーク５０１と第２ネットワーク６０１に接続されているように描かれているが、第１ネットワーク５０１に接続されているが第２ネットワーク６０１に接続されていない状態、第１ネットワーク５０１に接続されていないが第２ネットワーク６０１に接続されている状態、両方のネットワークに接続されている状態など、種々の接続状態がある。
The
対象機器３０１は、通信機能を持った家電またはセンサーなどの機器である。本実施形態では、ブロードバンドルータ配下のホームネットワークに接続されたデジタルテレビを想定する。対象機器３０１は、ＲＥＳＴ ＡＰＩ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を第２ネットワーク６０１、すなわち、ホームネットワークに公開している。このＲＥＳＴ ＡＰＩを以降、プライベートＡＰＩと呼ぶことがある。本実施形態では、対象機器３０１は、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）でアクセス可能なＡＰＩとして、プライベートＡＰＩを公開しているものとする。
The
通信装置２０１は、第２ネットワーク６０１を介して対象機器３０１と接続されているとき、対象機器３０１のプライベートＡＰＩに第２ネットワーク６０１を介してＨＴＴＰリクエストを送信することで、所望のリソースを利用できる。例えば、テレビ番組の録画予約を行うプライベートＡＰＩを利用するＨＴＴＰメッセージ例（以下、メッセージＡとして参照する）を以下に記す。ＨＴＴＰ ＰＯＳＴメソッドを利用し、ＨＴＴＰのリクエストボディにチャンネルや日時等を指定している。この例では、所望のリソースは、テレビ（対象機器３０１）の録画予約(reserved_programs)である。
When the
［メッセージＡ］
テレビのチャンネルを変更するプライベートＡＰＩを利用するＨＴＴＰメッセージ例（以下、メッセージＢとして参照する）を以下に示す。ＨＴＴＰ ＰＵＴメソッドを利用し、リクエストボディにチャンネルを指定している。この例では、通信装置２０１が利用しようとする所望のリソースは、テレビ（対象機器３０１）の状態(status)である。
An example of an HTTP message (hereinafter referred to as message B) using a private API for changing the TV channel is shown below. Using the HTTP PUT method, a channel is specified in the request body. In this example, the desired resource that the
［メッセージＢ］
以上は、あくまで実現方法の一形態であり、パラメータやＵＲＬは、上記の例に限定されるものではない。 The above is only one form of an implementation method, and parameters and URLs are not limited to the above examples.
アクセス認可装置１０１は、第１ネットワーク５０１に接続されたサーバ装置である。
アクセス認可装置１０１は、ＣＰＵ、メモリおよびストレージで構成される一般的な計算機の構成を有することを想定しているが、クラウドシステム上の仮想サーバとして実現されてもよい。本実施形態では、具体的には、サーバ装置上に実装されたソフトウェアプログラムが、本実施形態に係るアクセス認可装置１０１の機能を実現することを想定している。このソフトウェアプログラムは、ＯＡｕｔｈ２．０、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ
１．０といった、インターネット上でのアクセス認可を実現する標準規格に則った認可サーバ機能を備えているものとする。
The
The
It is assumed that an authorization server function conforming to a standard for realizing access authorization on the Internet such as 1.0 is provided.
アクセス認可装置１０１は、通信部１１１、トークン発行部１１２、認可対象決定部（決定部）１１３、状態判定部１１４、トークン検証部１１５、アクセス代行部１１６、トークン記憶部１１７、対象機器情報記憶部１１８を備える。
The
通信部１１１は、第１ネットワーク５０１を介して通信装置２０１および対象機器３０１と通信を行う。対象機器３０１との通信は、中継装置４０１を介して行う。
The
アクセス代行部１１６は、パブリックＡＰＩを備え、パブリックＡＰＩを、第１ネットワーク５０１に公開している。前述したように、具体的に、パブリックＡＰＩは、本実施形態では、プライベートＡＰＩと同様の、ＨＴＴＰでアクセス可能なＡＰＩを提供しているものとする。
例えば、アクセス認可装置１０１のドメインがapi.publiccontroller.example.comであり、対象機器３０１の識別子を“xyz”とした場合、対象機器３０１のプライベートＡＰＩ（前述したメッセージＡおよびＢを参照）に相当するパブリックＡＰＩのＵＲＬは、それぞれ以下のように表現できる。
For example, when the domain of the
トークン発行部１１２は、通信装置２０１から対象機器３０１のリソースへのアクセス許可要求を受信して、通信装置２０１の認証、ならびにリソースのアクセス権限者の認証および認可を行う。これらの認証および認可が成功すると、トークン発行部１１２は、アクセス許可情報（アクセストークン）を通信装置２０１に対して発行する。アクセストークンは、プライベートＡＰＩへのアクセスのものと、パブリックＡＰＩへのアクセスのものがあり、どちらを発行するかは、後述する認可対象決定部１１３と状態判定部１１４の結果に応じて判断する。通信装置２０１は、パブリックＡＰＩまたはプライベートＡＰＩへのアクセストークンの発行を受けると、対象機器３０１のリソースへのアクセスが可能となる。プライベートＡＰＩの場合は、対象機器３０１に対して直接、リソースへアクセスし、パブリックＡＰＩの場合は、アクセス認可装置１０１の代行により行われる。なお、この機能は、ＯＡｕｔｈ２．０の認可サーバの基本機能である。アクセス認可要求およびそれに基づく認証および認可等は、この標準仕様に則ったＨＴＴＰＳ通信で実現される。
The
トークン記憶部１１７は、トークン発行部１１２により発行されたアクセストークンを、リソースにアクセスする際に利用する１つ以上のＡＰＩ情報に関連付けて記憶する（後述する図２参照）。ＡＰＩ情報は、ＡＰＩに関する情報の一例である。その他の例としては、後述する図３のＡＰＩパス（ＡＰＩ情報の一部）などがある。
ＡＰＩ情報は、それ自体の記述から、プライベートＡＰＩとパブリックＡＰＩを区別可能になっている。ＡＰＩ情報は、例えばリソースアクセスのときに利用するＵＲＬを含む。またトークン記憶部１１７には、アクセス可能な対象機器のＩＤおよびユーザのＵＩＤが、アクセストークンに関連づけられて記憶される。また、アクセストークンの有効期限も設定されている。リフレッシュトークンはアクセストークンと同時に発行され、その使用方法は後述する。
The
The API information can distinguish a private API and a public API from its own description. The API information includes a URL used for resource access, for example. Further, the
トークン記憶部１１７自体の具体的な実現形態は、揮発メモリ上の簡易なハッシュ構造であってもよいし、ＫＶＳ（Ｋｅｙ Ｖａｌｕｅ Ｓｔｏｒｅ）であってもよいし、不揮発ストレージに記憶するリレーショナルデータベース管理システムであってもよい。アクセストークンから、関連する認可対象情報を参照できるかぎりにおいて実現方法は問わない。
A specific implementation form of the
トークン検証部１１５は、通信装置２０１からパブリックＡＰＩへのリソースの利用要求を受けた場合に、当該アクセス要求に含まれるアクセストークンが、発行済みの有効なアクセストークンであるかを検証する。また、通信装置２０１からトークン発行要求を受信し、当該トークン発行要求にリフレッシュトークンが含まれる場合に、リフレッシュトークンが、発行済みの有効なものであるかを検証する。対象機器３０１からアクセストークン検証要求を受信し、当該検証要求に含まれるアクセストークンが、発行済みの有効なリフレッシュトークンであるかを検証する。トークン発行部１１２と同様、検証要求およびそれに基づく検証は、ＨＴＴＰＳ通信で実現される。
When receiving a resource use request to the public API from the
対象機器情報記憶部１１８は、対象機器３０１にアクセスするために用いる情報（アクセス情報）と、対象機器３０１を一意に識別する対象機器ＩＤ（デバイス識別子）と、プライベートＡＰＩのパスとを含む。アクセス情報は、対象機器３０１の外部ＩＰアドレス、およびポート番号を含む。外部ＩＰアドレスは、対象機器３０１と通信するときにアクセス認可装置１０１で把握される対象機器３０１のＩＰアドレスであり、通常、中継装置４０１の第１ネットワーク５０１側のポートに割り当てられたグローバルＩＰアドレスに一致する。なお、本実施形態のＩＰアドレスは、ＩＰｖ４アドレスでも、ＩＰｖ６アドレスでもよい。また、ＩＰアドレス以外の種類のアドレスを用いてもよい。
The target device
アクセス情報は、アクセス認可装置１０１と対象機器３０１間の通信方式に依存して、様々なバリエーションが考えられる。例えば、対象機器３０１からアクセス認可装置１０１に通信コネクションを維持し続ける方式（ＷｅｂＳｏｃｋｅｔや、ＨＴＴＰ Ｌｏｎｇ
Ｐｏｌｌｉｎｇ等）では、通信ソケット情報を加えてもよい。記憶部自体の実現形態は、トークン記憶部１１７と同様に種々の形態が可能である。
Depending on the communication method between the
In the case of Polling or the like, communication socket information may be added. The realization form of the storage unit itself can be various forms as with the
本実施形態では、当該方式（ＷｅｂＳｏｃｋｅｔや、ＨＴＴＰ Ｌｏｎｇ Ｐｏｌｌｉｎｇ等）を利用して、対象機器３０１がアクセス認可装置１０１と通信コネクションを維持し続けている状況を想定する。この状況では、アクセス認可装置１０１から中継装置４０１を介して対象機器３０１へ通信（ＴＣＰ通信など）を開始することも可能である。
In the present embodiment, it is assumed that the
状態判定部１１４は、通信装置２０１からの要求（トークン発行要求、リソース利用要求など）が受信された際に、通信装置２０１の接続状態を判定する。具体的に、通信装置２０１が、第２ネットワーク６０１に接続されているか否かを判定する。具体的な判定方法として、状態判定部１１４が、対象機器情報記憶部１１８内の対象機器３０１の外部ＩＰアドレスを参照し、これと、アクセス認可装置１０１で受信した要求の送信元ＩＰアドレスが一致するか否かで、第２ネットワーク６０１に接続されているかを判定する。対象機器３０１の外部ＩＰアドレスが送信元ＩＰアドレスと一致する場合には、第２ネットワーク６０１に接続されていると判断し、一致しない場合は、第２ネットワーク６０１に接続されていない（すなわち第１ネットワーク５０１に接続されている）と判断する。要求の送信元ＩＰアドレスは、通信装置２０１の第２ネットワーク６０１との接続状態（接続されているか否か、あるいは接続可能な状態か否か）を特定するための情報の一例である。
対象機器に対してＩＰアドレスの範囲を設定し、送信元ＩＰアドレスが、当該範囲（複数の対象機器が取り得るＩＰアドレスの範囲など）に含まれるか否かで、第２ネットワークに接続されているかを判定してもよい。
第２ネットワーク６０１に接続されている場合、ユーザは宅内にいるとみなせるから、宅内からのアクセスであると言える。第２ネットワーク６０１に接続されていない場合、すなわち第１ネットワーク５０１に接続されている場合、宅外にいるとみなすことができるから、宅外からのアクセスであると言える。以下では、第２ネットワーク６０１を介したアクセス認可装置１０１へのアクセスを宅内からのアクセス、第２ネットワークを介さず、第１ネットワーク５０１を介したアクセス認可装置１０１へのアクセスを宅外からのアクセスと表現することがある。状態判断部１１４は、判定結果に基づき、通信装置２０１の接続状態を表す状態情報を生成する。状態情報は、通信装置２０１のアクセス認可装置１０１のアクセスが、宅内からのアクセスか、宅外からのアクセスかを表す。
The
An IP address range is set for the target device, and the source IP address is connected to the second network depending on whether or not the source IP address is included in the range (such as a range of IP addresses that can be taken by a plurality of target devices). It may be determined whether or not.
When connected to the second network 601, it can be said that the access is from the home because the user can be regarded as being at home. When it is not connected to the second network 601, that is, when it is connected to the
ここでは通信装置２０１が第２ネットワーク６０１に接続されているかを判断したが、通信装置２０１が第１ネットワーク５０１に接続されているが、第２ネットワーク６０１に接続可能な状態か否かを判断してもよい。例えばユーザが宅内に存在し、第２ネットワーク６０１にいつでも接続可能であるが、現時点では第１ネットワーク５０１に接続されている場合は、第２ネットワーク６０１に接続可能な状態であると判断できる。接続可能な状態かを判断するのに、通信装置２０１が、対象機器３０１に対して一定の距離範囲内に存在するかを判断してもよい。例えば、通信装置２０１がＧＰＳを搭載しており、また、対象機器３０１の設置位置情報を予め取得しておくとする。この場合、通信装置２０１からＧＰＳの位置情報を取得し、取得した位置情報を、設置位置情報と比較することで、第２ネットワーク６０１に接続可能な状態かを判断してもよい。または、対象機器３０１がＧＰＳを搭載している場合には、当該対象機器３０１のＧＰＳの位置情報を取得し、これを対象機器３０１の位置情報と比較することで、第２ネットワーク６０１に接続可能な状態かを判断してもよい。接続可能な状態の場合、接続されている状態（宅内からのアクセスの場合）に準じた処理を行っても良い。プライベートＡＰＩへアクセスすることになった場合、通信装置２０１が自動的に接続先を第１ネットワーク５０１から第２ネットワーク６０１に切り換えても良い。ＧＰＳの位置情報は、通信装置２０１の第２ネットワーク６０１との接続状態を特定するための情報の一例である。
Here, it is determined whether or not the
認可対象決定部１１３は、状態判定部１１４で生成された状態情報を用いて、プライベートＡＰＩおよびパブリックＡＰＩのいずれをアクセス対象として許可するかを決定する。認可対象決定部１１３が認可を与える対象は、通信装置２０１に搭載されたアプリケーションに対してである。一例として、状態情報が宅内からのアクセスを示す場合は、プライベートＡＰＩ、宅外からのアクセスを示す場合は、パブリックＡＰＩを認可の対象として決定する。通信装置２０１のアプリケーションがアクセスする対象は、上記プライベートＡＰＩ、もしくは、パブリックＡＰＩであり、いずれのアクセスに認可を与えるか判断する。プライベートＡＰＩが決定された場合、通信装置２０１が直接、対象機器３０１のプライベートＡＰＩにアクセスする（すなわち通信装置２０１がリソースの利用要求を対象機器３０１に送信する）ことを意味する。パブリックＡＰＩの場合、アクセス代行部１１６が、通信装置２０１からのパブリックＡＰＩへのアクセスを受けて、アクセス代行部１１６がリソースの利用要求を対象機器３０１に送信する。なお、アクセス代行部１１６が対象機器３０１のリソースを利用する方法は事前に定められているものとする。専用のＡＰＩが用意されていてもよいし、プライベートＡＰＩのＵＲＬを含むデータを対象機器に送信し、対象機器が当該データに含まれるプライベットＡＰＩのＵＲＬを内部的に解釈および実行してもよい。
The authorization
以下、具体的な事例に基づき、本通信システムの動作を説明する。説明の前に、ユーザ行動の想定シナリオと、通信システムの前提条件について説明する。 The operation of this communication system will be described below based on specific examples. Before the description, an assumed scenario of user behavior and preconditions of the communication system will be described.
＜想定シナリオ＞
ユーザが、宅外からスマートフォン（通信装置２０１）に搭載されたテレビリモコンアプリケーション（以降、クライアントと呼ぶ）を操作し、自宅のテレビ（対象機器３０１）の番組録画予約を行う。続いて、ユーザは、帰宅後に当該テレビリモコンアプリケーションでテレビの電源ＯＮし、チャンネルを切り替える。このとき、Ｗｅｂ上のテレビリモコンサービスを提供するサーバ（アクセス認可装置１０１）は、ユーザが宅外にいるときはパブリックＡＰＩを、ユーザが宅内にいるときは、プライベートＡＰＩを利用するように、使用するＡＰＩを自動的に切り換えるように制御する。この制御により、ユーザが番組録画予約を行うときは通信装置２０１はパブリックＡＰＩにアクセスし、チャンネル切り替えを行うときはプライベートＡＰＩにアクセスする。このようなＡＰＩの切り替えは、宅外から宅内への移動を契機として自動的に実行される。
<Assumed scenario>
A user operates a TV remote control application (hereinafter referred to as a client) installed in a smartphone (communication device 201) from outside the house to make a program recording reservation for the home TV (target device 301). Subsequently, after returning home, the user turns on the TV with the TV remote control application and switches the channel. At this time, the server (access authorization device 101) that provides the TV remote control service on the Web is used so that the public API is used when the user is outside the home and the private API is used when the user is inside the home. The API to be automatically switched is controlled. With this control, the
＜前提条件＞
・スマートフォン（通信装置２０１）上のリモコンアプリケーション（クライアント）は、ＯＡｕｔｈの標準規格に従い、テレビリモコンサービスを提供するサーバ（アクセス認可装置１０１）から発行されたクライアント識別子（client_id）とクライアント秘密情報(client_secret)を保持している。この発行は、特定リソースへのアクセス（取得と変更）を行うクライアントを、クライアントの開発者が、アクセス認可装置１０１（の管理者）に登録申請し、アクセス認可装置１０１の管理者の承諾を経て実行される。登録、許諾、発行は、電子的に自動で行われることが一般的であるが、本実施形態では、この発行方法については規定しない。なお、特定リソースは、本実施形態では、テレビ（対象機器３０１）の状態(status)、および録画予約(reserved_programs)である。
・アクセス認可装置１０１側にも、クライアント認証用にこのclient_id、client_secret（図示せず）が登録されている。
・アクセス認可装置１０１の対象機器情報記憶部１１８には、対象機器３０１の外部ＩＰアドレス等が、対象機器３０１の識別情報（デバイス識別子：device_id）と共に記憶されている（図３参照）。本実施形態では、この登録手法については規定しない。手動でデータベースに登録されていてもよいし、対象機器３０１（テレビ）がアクセス認可装置１０１と通信を行って、自動的に登録するようにしてもよい。
・通信装置２０１のユーザは、対象機器３０１の所有者であり、テレビリモコンサービスを提供するサーバ（アクセス認可装置１０１）で、予めユーザアカウント(user_id, user_password)を作成している。なお、ユーザＩＤ（user_id）は、トークン記憶部１１７においてトークンに関連づけられて登録されている（図２参照）。
・アクセス認可装置１０１上に、ユーザと、ユーザが所有する対象機器３０１（テレビ）が対応付けられている。この対応付けの方法も様々な実現形態が考えられるが、本実施形態ではその方法を規定しない。トークン記憶部１１７には、このユーザと対象機器３０１との対応付けが、ユーザＩＤ（user_id）と対象機器ＩＤ（device_id）との対応付けにより登録されている。
<Prerequisites>
The remote control application (client) on the smartphone (communication device 201) conforms to the OAuth standard, and the client identifier (client_id) and client secret information (client_secret) issued from the server (access authorization device 101) that provides the TV remote control service ). In this issuance, the client developer applies to the access authorization device 101 (administrator) for registration of a client that accesses (acquires and changes) a specific resource, and passes through the approval of the administrator of the
The client_id and client_secret (not shown) are registered on the
The target device
The user of the
On the
＜本実施形態の通信シーケンス＞
図４は、本実施形態に係る通信システムにおける対象機器３０１、通信装置２０１およびアクセス認可装置１０１間で行われる通信シーケンスを示す。図５は、図４に続く通信シーケンスを示す。図４および図５における各数字はステップの番号を表す。
<Communication sequence of this embodiment>
FIG. 4 shows a communication sequence performed between the
［ステップ１］ユーザが、通信装置２０１上のクライアントを立ちあげ、所望の番組の録画予約（リソース利用）を行う。このとき、クライアントは、未だアクセストークンを取得していないので、ユーザに認可画面を表示し、許可画面にはクライアントが対象機器３０１のリソース利用を求めている旨と、許諾ボタンおよびキャンセルボタンとを表示する。許可画面にユーザが宅内および宅外のいずれにいるか（第１ネットワーク５０１および第２ネットワーク６０１のどちらに接続されているか）を区別する情報を表示してもよい。
[Step 1] A user starts up a client on the
［ステップ２］ユーザが、許可画面内の認可ボタンを押下する。本実施形態では、クライアントが認可画面を生成しているが、アクセス認可装置１０１に認可要求を送信し、アクセス認可装置１０１が認可画面を応答する方法を採ってもよい。この場合、アクセス認可装置１０１から応答された許可画面を、通信装置２０１で表示する。
[Step 2] The user presses the authorization button in the permission screen. In this embodiment, the client generates the authorization screen. However, a method may be adopted in which an authorization request is transmitted to the
［ステップ３］クライアントは、ユーザの許諾を受けて、アクセス認可装置１０１のトークン発行部１１２にアクセストークン発行要求（リソースの許可要求）を送信する。このとき、アクセストークン発行要求は、一実現形態としては、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を含んでもよい。
[Step 3] Upon receiving permission from the user, the client transmits an access token issue request (resource permission request) to the
user_idとuser_passwordは、通信装置２０１がユーザに入力画面（ステップ１のユーザ認可画面でもよい）を表示し、その入力値を利用するようにしてもよいし、予め、通信装置２０１内に記憶しておき、これを利用するようにしてもよい。
For the user_id and user_password, the
認可範囲情報は、アクセストークン発行要求に含めずに、予めクライアント識別子（client_id）に紐づけてアクセス認可装置１０１側で記憶しておいてもよい。なお、client_id, client_secret, user_id, user_passwordを含むアクセストークン発行要求は、ＯＡｕｔｈ２．０のリソースオーナーパスワードクレデンシャルグラントという承認方式（グラントタイプ）に則っている。本実施形態では、このグラントタイプに則ったシーケンスのみを記すが、これ以外のグラントタイプ（認可コード、インプリシットグラント、またはクライアントクレデンシャルグラント）に則ったシーケンスであってもよい。
The authorization range information may be stored in advance on the
（ステップ４）トークン発行部１１２は、アクセストークン発行要求に含まれるclient_id, client_secretに基づき、当該クライアントが正規のクライアントであることを認証する。正規のクライアントとは、アクセス認可装置１０１に事前に登録および承認されたクライアントのことである。
(Step 4) The
（ステップ５）トークン発行部１１２は、user_id, user_passwordに基づき、ユーザが正規のユーザであることを認証する。正規のユーザとは、アクセス認可装置１０１に事前に登録および承認されたユーザのことである。アクセス認可装置１０１ではユーザと対象機器３０１とが予め関連づけて登録されているため、認証の結果として、ユーザの所有対象機器３０１が判明する。ここでは、ユーザの所有対象機器３０１は、テレビ（device_id=xyz）である。
(Step 5) The
（ステップ６）状態判定部１１４は、アクセストークン発行要求の送信元ＩＰアドレスを取得し、この送信元ＩＰアドレスを、対象機器情報記憶部１１８における当該テレビに対応するＩＰアドレス（図３参照）と比較する。当該テレビに対応するＩＰアドレスは、トークン記憶部においてユーザに関連づけられた機器（テレビ）を特定し、当該テレビのＩＰアドレスを、対象機器情報記憶部１１８から特定することで行うことができる。これらが異なっていれば、ユーザのアクセスは宅外アクセスであり、同じであれば宅内アクセスであると判定する。ここでは、宅外アクセスと判定される。
(Step 6) The
（ステップ７）認可対象決定部１１３は、状態判定部１１４の判定結果と、ユーザに関連づけられた対象機器３０１（device_id=xyz）に基づき、パブリックＡＰＩ（api.tvcontroller.example.com/v1/devices/xyz/statusと、api.tvcontroller.example.com/v1/devices/xyz/reserved_program）を認可対象として決定する。具体的に、図２のトークン記憶部１１７に記憶された情報において、ユーザ（この例ではaliceとする）と対象機器３０１（xyz）とに関連づけられたパブリックＡＰＩおよびプライベートＡＰＩのうち、宅内アクセスの判定結果から、パブリックＡＰＩを決定する。図２の情報においてパブリックＡＰＩとプライベートＡＰＩの区別は、許可対象情報（ＡＰＩ情報）の記述自体から行ってもよいし（例えば許可対象情報にプライベートＩＰアドレスが含まれていればプライベートＡＰＩと判断するなど）、あるいは、パブリックＡＰＩとプライベートＡＰＩを区別するための識別情報を別途付与し、この識別情報に基づいて行ってもよい。
(Step 7) The authorization
（ステップ８）トークン発行部１１２は、認可対象決定部１１３の決定に基づき、パブリックＡＰＩ用のアクセストークンを発行し、発行したアクセストークンを含むアクセストークン応答をクライアントに送信する。発行されたアクセストークンは、トークン記憶部１１７に記憶される（図２の１行目の「アクセストークン」の列）。本実施形態では、トークン発行部１１２は、発行したアクセストークンに有効期限（図２の１行目の「有効期限」の列」）を設け、さらに、アクセストークンの更新用に用いるリフレッシュトークン（図２の１行目の「リフレッシュトークン」の列」）をあわせて発行する。このリフレッシュトークンも、クライアントに送信するアクセストークン応答に含める。なお、アクセストークン応答に、パブリックＡＰＩ情報を含めてもよいし、クライアント側でパブリックＡＰＩ情報を事前に把握するようにしてもよい。
(Step 8) Based on the determination by the authorization
リフレッシュトークンは、アクセストークンよりも長い有効期限を設けてもよい。アクセストークンが期限切れした場合や、後述する通信装置２０１の状態（宅内か宅外か）が変化する等してトークン検証が失敗した場合には、クライアントは、このリフレッシュトークンを提示して、新しいアクセストークンの発行を要求する。リフレッシュトークンを利用することで、再度ユーザ認証等から処理をやり直す必要がない利点がある。なお、後述するステップ１８に記すように、リフレッシュトークンを用いない形態も可能である。 The refresh token may have a longer expiration date than the access token. When the access token expires or the token verification fails due to a change in the state of the communication device 201 (in-home or out-of-home), which will be described later, the client presents this refresh token and performs a new access Request issuance of a token. By using the refresh token, there is an advantage that it is not necessary to start the process again from the user authentication or the like. In addition, as described in Step 18 described later, a form that does not use a refresh token is also possible.
（ステップ９）クライアントは、アクセス認可装置１０１から受信したアクセストークン応答に含まれるパブリックＡＰＩ用のアクセストークンとリフレッシュトークンを取得する。クライアントは、アクセストークンを含む録画予約要求（リソース利用要求）を、パブリックＡＰＩ（アクセス代行部１１６）に送信する。具体的には、パブリックＡＰＩのＵＲＬhttps://api.tvcontroller.example.com/v1/devices/xyz/reserved_programsに対して、前述したメッセージＡを送信する。なお、前述したメッセージＡの例では、アクセストークン等の表記は省略されている。
(Step 9) The client obtains an access token and a refresh token for public API included in the access token response received from the
（ステップ１０）
アクセス代行部１１６は、パブリックＡＰＩ用のアクセストークンを含む録画予約要求を受信する。このとき、トークン検証部１１５は、録画予約要求に含まれるアクセストークンが、パブリックＡＰＩ用に発行された有効なものであることを、トークン記憶部１１７を参照して確認する。すなわち、録画予約要求に含まれるアクセストークンがトークン記憶部１１７に存在し、かつ有効期限内であることを確認する。
(Step 10)
The
（ステップ１１）状態判定部１１４は、ステップ６と同様に、録画予約要求の送信元ＩＰアドレスを、対象機器情報記憶部１１８における当該テレビ（例えばパブリックＡＰＩのＵＲＬの「xyz」から特定）に対応するＩＰアドレス（図３参照）と比較することで、宅外アクセスか宅外アクセスかを判定する。ここでは両者が一致しないため、宅外アクセスと判断する。トークン検証部１１５は、状態判定部１１４の判定結果に基づき、録画予約要求に含まれているアクセストークンが宅外からの録画予約要求用に発行された正当なものと判定する。
(Step 11) Similarly to step 6, the
（ステップ１２）アクセス代行部１１６は、リソース利用要求である録画予約要求を、対象機器３０１に送信する。送信された録画予約要求は第１ネットワーク５０１、中継装置４０１および第２ネットワーク５０２を介して、対象機器３０１で受信される。
(Step 12) The
（ステップ１３）対象機器３０１は、アクセス認可装置１０１から録画予約要求を受信し、録画予約要求に基づき録画予約を実行する。対象機器３０１は録画予約を実行すると、録画予約を完了報告をアクセス認可装置１０１に送信する。アクセス認可装置１０１は、録画予約の完了報告を対象機器３０１から受信する。アクセス代行部１１６は、要求された録画予約が完了したことを示す応答（パブリックＡＰＩアクセス応答）を通信装置２０１に返す。
(Step 13) The
（ステップ１４）ユーザが、宅外から宅内に移動し、通信装置２０１に搭載されたクライアントを用いて、テレビのチャンネル切り替えを行う。このとき、宅外で使われていた携帯キャリア通信（３ＧやＬＴＥ）から、宅内のＷｉＦｉに通信が切り替わったとする。すなわち、通信装置２０１の接続先が第１ネットワーク５０１から第２ネットワーク６０１に切り替わったとする。
(Step 14) The user moves from outside the house to the house, and uses the client installed in the
（ステップ１５）クライアントは、アクセス代行部１１６のパブリックＡＰＩに対して、パブリックＡＰＩ用のアクセストークンを含むチャンネル切り替え要求（リソース利用要求）を送信する。具体的には、パブリックＡＰＩのＵＲＬhttps://api.tvcontroller.example.com/v1/devices/xyz/statusに対して、前述したメッセージＢを送信する。なお、前述したメッセージＢの例では、アクセストークン等の表記は省略されている。
(Step 15) The client transmits a channel switching request (resource use request) including an access token for the public API to the public API of the
（ステップ１６）アクセス代行部１１６は、アクセストークンを含むチャンネル切り替え要求を受信する。このとき、トークン検証部１１５は、ステップ１０と同様、アクセストークンがパブリックＡＰＩ用に発行された有効なものであることを、トークン記憶部１１７を参照して確認する。
(Step 16) The
（ステップ１７）状態判定部１１４は、ステップ１１と同様に、チャンネル切り替え要求の送信元ＩＰアドレスを、対象機器情報記憶部１１８における当該テレビ（例えばパブリックＡＰＩのＵＲＬの「xyz」から特定）に対応するＩＰアドレス（図３参照）と比較することで、宅外アクセスか宅外アクセスかを判定する。ここでは両者が一致するため、宅内アクセスと判断する。トークン検証部１１５は、状態判定部１１４の判定結果に基づき、認可エラーを判断する。アクセス代行部１１６は、これを受けて、パブリックＡＰＩへの、宅内（中継装置４０１配下の第２ネットワーク６０１）からのアクセスを拒絶し、認可エラー応答を送信する。
(Step 17) As in step 11, the
（ステップ１８）通信装置２０１に搭載されたクライアントは認可エラー応答を受信すると、アクセストークン発行要求を生成してトークン発行部１１２に送信する。このアクセストークン発行要求は、ステップ８で発行されたリフレッシュトークンを含む。バリエーションとしては、リフレッシュトークンは使わず、ステップ３と同様、再度、新規のアクセストークン発行要求を送信する方法もある。
(Step 18) Upon receiving the authorization error response, the client installed in the
（ステップ１９）トークン検証部１１５は、トークン発行要求に含まれるリフレッシュトークンを取得し、取得したリフレッシュトークンが、トークン記憶部１１７に登録されているかを確認する（なお、この時点では図２の２行目のアクセストークンおよびリフレッシュトークンは登録されていなくてよい）。登録されていることから、当該リフレッシュトークンが、正当なリフレッシュトークンであると判断する。このとき、リフレッシュトークンの発行対象である対象機器３０１のＩＤ、すなわちdevice_id（=xyz）をトークン記憶部１１７から取得する。
(Step 19) The
（ステップ２０）ステップ１７と同様、状態判定部１１４は、トークン発行要求の送信元ＩＰアドレスを、対象機器情報記憶部１１８における当該テレビ（xyz）に対応するＩＰアドレス（図３参照）と比較することで、宅外アクセスか宅外アクセスかを判定する。ここでは、両者が一致するため、宅内アクセスであると判定する。
(Step 20) As in step 17, the
（ステップ２１）認可対象決定部１１３は、状態判定部１１４の判定結果と、ユーザに関連づけられた対象機器３０１（device_id=xyz）に基づき、対象機器３０１に搭載されたプライベートＡＰＩ（192.168.11.19 /v1/status, reserved_program）を、通信装置２０１のアクセス認可対象に決定する。
(Step 21) Based on the determination result of the
（ステップ２２）トークン発行部１１２は、認可対象決定部１１３の決定に基づき、プライベートＡＰＩ用のアクセストークンを発行する。発行されたアクセストークンは、トークン記憶部１１７に記憶される（図２の２行目の「アクセストークン」の列）。この際、パブリックＡＰＩ用のリフレッシュトークンと同じ値のリフレッシュトークンを、プライベートＡＰＩ用のアクセストークンに対するリフレッシュトークンとしてトークン記憶部１１７に記憶する（図２の２行目の「リフレッシュトークン」の列）。また、トークン発行部１１２は、図２のトークン記憶部１１７におけるプライベートＡＰＩ情報（認可対象情報）を取得し、アクセストークンとプライベートＡＰＩ情報等を含むアクセストークン応答を生成する。トークン発行部は、アクセストークン応答を通信装置２０１に送信する。なお、リフレッシュトークンの値は、パブリックＡＰＩ用のリフレッシュトークンと異なってもよい。
(Step 22) The
（ステップ２３）通信装置２０１に搭載されたクライアントは、アクセストークン応答に含まれるアクセストークンとプライベートＡＰＩ情報を取得し、対象機器３０１のプライベートＡＰＩに、当該取得したアクセストークンを含むチャンネル切り替え要求（リソース利用要求）を送信する（すなわち、プライベートＡＰＩアクセスを実行する）。なお、通信装置２０１で事前にプライベートＡＰＩ情報を把握している場合は、アクセス認可装置１０１から送信するアクセストークン応答にプライベートＡＰＩ情報を含めなくてもよい。この場合、アクセス認可装置１０１でプライベートＡＰＩ情報を把握しない構成にしてもよい。
(Step 23) The client installed in the
（ステップ２４）対象機器３０１のプライベートＡＰＩは、アクセストークンを含むチャンネル切り替え要求を受信する。対象機器３０１のプライベートＡＰＩは、チャンネル切り替え要求に含まれるアクセストークンを取得し、当該アクセストークンを含むトークン検証要求を生成して、アクセス認可装置１０１に送信する。
(Step 24) The private API of the
（ステップ２５）アクセス認可装置１０１の通信部１１１は、対象機器３０１から送信されるトークン検証要求を受信する。トークン検証部１１５は、トークン検証要求に含まれるアクセストークンが、対象機器３０１のプライベートＡＰＩ用に発行された有効なものであることを、トークン記憶部１１７を参照して確認する。当該アクセストークンと同じ値がトークン記憶部１１７において当該対象機器３０１に対して記憶されており、有効期限内であるため、有効であると判断できる。なお、トークン検証部１１５は、トークン検証要求の送信元が対象機器３０１（device_id=xyz）であることは、トークン検証要求に対象機器ＩＤの“xyz”を含め、これを検出することで把握してもよい。または、Ｗｅｂｓｏｃｋｅｔで対象機器３０１とアクセス認可装置１０１との接続が維持されている場合に、当該接続を介して送信される要求の送信元機器が常に対象機器３０１（device_id=xyz）であると判断する仕組みにしてもよい。ここで述べた以外の方法で判断してもよい。
(Step 25) The
（ステップ２６）状態判定部１１４が、トークン検証要求の送信元ＩＰアドレスを、対象機器情報記憶部１１８における当該テレビ（xyz）に対応するＩＰアドレス（図３参照）と比較することで、通信装置２０１のアクセス（すなわちユーザのアクセス）が、宅外アクセスか宅外アクセスかを判定する。ここでは、両者が一致するため、宅内アクセスであると判定する。トークン検証要求に含まれる送信元ＩＰアドレスは、通信装置２０１の第２ネットワーク６０１との接続状態を特定するための情報の一例である。トークン検証部１１５は、状態判定部１１４の判定結果（宅内アクセス）から、クライアントからの対象機器３０１へのアクセスは正当なアクセスであると判定（すなわちユーザはアクセス認可装置１０１で認証および認可を経て、宅内の対象機器３０１のプライベートＡＰＩにアクセスしようとしていると判断）し、その旨の検証結果を表す応答を対象機器３０１に送信する。
(Step 26) The
（ステップ２７）対象機器３０１は、アクセス認可装置１０１の検証結果から、通信装置２０１からのプライベートＡＰＩアクセスで指示されたチャンネル切り替えを実行してよいと判断し、当該チャンネル切り替えを実行する。対象機器３０１は、チャンネル切り替えを実行した旨を表す応答（プライベートＡＰＩアクセス応答）を通信装置２０１に送信する。
(Step 27) From the verification result of the
図６は、アクセス認可装置１０１が通信装置２０１からトークン発行要求を受信した場合に行う処理のフローチャートである。前述した図４および図５のシーケンスでは、ステップ３とステップ１８でトークン発行要求を通信装置２０１から受信している。
FIG. 6 is a flowchart of processing performed when the
トークン発行要求を受信すると、トークン発行要求にリフレッシュトークンが含まれているかを判断する（ステップ３１）。 When the token issue request is received, it is determined whether the token issue request includes a refresh token (step 31).
リフレッシュトークンが含まれていない場合、クライアント認証（ステップ３２）およびユーザ認証（ステップ３３）を行う。クライアント認証およびユーザ認証の詳細は前述した通りである。いずれかの認証が失敗すれば、通信装置２０１に認証エラー応答を送信して処理を終了する（ステップ３９）。両方の認証が成功した場合は、通信装置２０１の状態判定（ユーザが宅内にいるか宅外にいるかの判定）を行う（ステップ３４）。判定方法の詳細は前述した通りである。状態判定の結果に応じて、パブリックＡＰＩおよびプライベートＡＰＩのいずれをアクセス認可対象にするかを決定し（ステップ３５）、決定したＡＰＩに対応するアクセストークンを生成する（ステップ３６）。生成したアクセストークンは、ＡＰＩ情報、および対象機器３０１およびユーザ等に関連づけて、トークン記憶部１１７に記憶する（ステップ３７）。
If the refresh token is not included, client authentication (step 32) and user authentication (step 33) are performed. Details of client authentication and user authentication are as described above. If any authentication fails, an authentication error response is transmitted to the
一方、トークン発行要求にリフレッシュトークンが含まれている場合は、リフレッシュトークンを検証する（ステップ３８）。すなわち、当該リフレッシュトークンがトークン記憶部１１７に有効に登録されているかを判断する。有効に登録されている場合は、ステップ３４の通信装置２０１の状態判定を行い、以降は上述したステップ３５〜３７を行う。リフレッシュトークンがトークン記憶部１１７に登録されていない、もしくは登録されているが有効期限が切れている場合は、通信装置２０１に認証エラー応答を送信して処理を終了する（ステップ３９）。
On the other hand, if the token issuance request includes a refresh token, the refresh token is verified (step 38). That is, it is determined whether the refresh token is effectively registered in the
本実施形態では、対象機器が宅内に１つある場合を示したが、複数の対象機器がある場合も同様にして実施可能である。このとき、対象機器ごとにパブリックＡＰＩ用およびプライベートＡＰＩ用のアクセストークンをそれぞれ発行してもよいし、それぞれ同じアクセストークンを複数の対象機器で用いてもよい。 In the present embodiment, the case where there is one target device in the house is shown, but the same can be implemented when there are a plurality of target devices. At this time, an access token for public API and private API may be issued for each target device, or the same access token may be used by a plurality of target devices.
また、本実施形態では、中継装置４０１が通信装置２０１とは別に存在したが、通信装置２０１が中継機能を備え、対象機器３０１が通信装置２０１の中継機能を利用して、アクセス認可装置１０１と通信してもよい。この場合も、通信装置２０１は、対象機器３０１と同じネットワークに接続されているといえる。
In this embodiment, the
また、本実施形態ではアクセス認可装置は対象機器３０１とＷｅｂｓｏｃｋｅｔ等で常時通信コネクションを維持している状況を想定したが、通信装置２０１が第２ネットワーク６０２に接続されている（または接続可能な状態である）と判定された場合は、対象機器３０１との通信コネクションを切断してもよい。また、通信装置２０１が第２ネットワーク６０２に接続されていない（または接続不能な状態である）と判定された場合は、対象機器３０１との通信コネクションを再度設定してもよい。
In this embodiment, it is assumed that the access authorization device always maintains a communication connection between the
以上、本実施形態によれば、アクセストークンの発行（ステップ４〜８、１９〜２２）、アクセストークンを利用したリソースアクセス（９〜１２， １５〜１７）、アクセストークンの検証（２５〜２６）において、通信装置２０１の状態（宅外か宅内か）に応じた処理を行う。具体的には、ユーザが宅外にいる場合には、パブリックＡＰＩを利用し、宅内にいる場合には、必ずプライベートＡＰＩを利用するようクライアントに強制することができる。このとき、ユーザはＡＰＩの切り替えの都度、再認可を行う必要はなく、ユーザが知らない間に、利用するＡＰＩが切り替わる。ユーザは、宅外からのＡＰＩアクセスを行う場合にだけ、インターネット（第１ネットワーク５０１）上のサーバ（アクセス認可装置１０１）を利用するので、サーバに残る通信ログを必要最小限でき、かつ、可能な限りホームネットワーク（第２ネットワーク６０１）での直接通信を利用することで、リソース利用に要する通信遅延を短くできる。 As described above, according to the present embodiment, the access token issuance (steps 4 to 8 and 19 to 22), the resource access using the access token (9 to 12 and 15 to 17), and the access token verification (25 to 26). In FIG. 5, processing is performed according to the state of the communication device 201 (external or in-home). Specifically, it is possible to force the client to use a public API when the user is outside the home and to use a private API whenever the user is at home. At this time, the user does not need to reauthorize each time the API is switched, and the API to be used is switched while the user does not know. Since the user uses the server (access authorization device 101) on the Internet (first network 501) only when performing API access from outside the house, the communication log remaining on the server can be minimized and possible. By using direct communication in the home network (second network 601) as much as possible, communication delay required for resource use can be shortened.
以下、本実施形態のバリエーションについて説明する。 Hereinafter, variations of the present embodiment will be described.
＜通信シーケンスのバリエーション（１）＞
図５のステップ１８〜２２ではアクセストークンを発行し直しているが、アクセストークンを発行し直さないシーケンスも可能である。以下のこの場合のシーケンスの変更点を説明する。
<Variation of communication sequence (1)>
In steps 18 to 22 in FIG. 5, the access token is reissued, but a sequence in which the access token is not reissued is also possible. The sequence changes in this case will be described below.
図４のステップ１の認可画面で、宅内・宅外両用のアクセストークンの認可をユーザに求めるようにする。
On the authorization screen in
ステップ８のトークン発行で、プライベートＡＰＩ、パブリックＡＰＩ両用のアクセストークンを発行する。発行されるアクセストークンは、図２の１行目、２行目の認可対象情報を両方に対して有効である。 By issuing a token in step 8, an access token for both private API and public API is issued. The access token to be issued is valid for both the authorization object information in the first and second lines in FIG.
ステップ１７でエラー応答とせずに、プライベートＡＰＩへのリダイレクト応答を通信装置２０１に送信する。このリダイレクト応答にはプライベートＡＰＩ情報を含める。リダイレクト応答を受信した通信装置２０１は、リダイレクト応答に含まれるプライベートＡＰＩ情報に基づき、図５のステップ２３の動作を実行する。これによりステップ１８〜２２の動作は不要となる。
In step 17, a redirect response to the private API is transmitted to the
＜通信シーケンスのバリエーション（２）＞
図４および図５のシーケンスでは、トークン検証（トークンの有効性検証）および状態判定の順で処理を行っている（ステップ１０−１１、ステップ１６−１７、ステップ１９−２０、ステップ２５−２６）が、これは実装依存の部分であり、状態判定を先に行っても構わない。
<Variation of communication sequence (2)>
In the sequence of FIG. 4 and FIG. 5, processing is performed in the order of token verification (token validity verification) and state determination (step 10-11, step 16-17, step 19-20, step 25-26). However, this is an implementation-dependent part, and the state determination may be performed first.
＜通信シーケンスのバリエーション（３）＞
図５のステップ２７の後、ユーザが宅内から宅外に移動して、別途録画予約を行う場合のシーケンスを、以下にステップ２８〜３１として示す。
<Variation of communication sequence (3)>
A sequence in the case where the user moves from the inside of the house to the outside of the house after the step 27 in FIG.
（ステップ２８）ユーザが、宅内から宅外に移動する。この時、通信装置２０１は、通信をＷｉＦｉから、３ＧないしＬＴＥなどのモバイル広域通信に切り替える。すなわち、通信装置２０１は、通信の接続先を第２ネットワーク６０１から第１ネットワーク５０１に切り換える。
(Step 28) The user moves from inside the house to outside the house. At this time, the
（ステップ２９）ステップ２３と同様、クライアントは、宅内用のアクセストークンを用いて、対象機器３０１のプライベートＡＰＩに録画予約要求を送信する。
(Step 29) Similar to step 23, the client transmits a recording reservation request to the private API of the
（ステップ３０）プライベートＡＰＩへのアクセスが失敗する。すなわち、通信装置２０１は第１ネットワーク５０１に接続されているため、第２ネットワーク６０１内の対象機器３０１のプライベートＡＰＩへアクセスするための通信は失敗する（タイムアウトする）。このため、通信装置２０１のクライアントは、第１ネットワーク５０１を介して、アクセス認可装置１０１のトークン発行部１１２にトークン発行要求を送信する。このトークン発行要求には、プライベートＡＰＩ用のリフレッシュトークンを含める。
(Step 30) Access to the private API fails. That is, since the
（ステップ３１）以降は、宅外から宅内に移動した場合とは反対に、宅内向けのアクセストークンを、宅外向けのアクセストークンに切り替える処理を行う。処理の内容は基本的にステップ１９〜２２と同様の処理を、順次行えばよい。前回発行したパブリックＡＰＩ用のアクセストークンは廃棄し、パブリックＡＰＩ用のアクセストークンは新たに発行し直す。ただし、前回のパブリックＡＰＩ用のアクセストークンをそのまま使用し続けることも可能である。この際、有効期限を延長してもよいし、有効期限は変更しなくてもよい。 After (step 31), contrary to the case of moving from outside the house to the house, a process of switching the access token for home use to the access token for home use is performed. The content of the processing may be basically performed sequentially in the same manner as in steps 19-22. The previously issued public API access token is discarded, and the public API access token is newly issued again. However, it is possible to continue using the access token for the previous public API as it is. At this time, the expiration date may be extended or the expiration date may not be changed.
＜通信シーケンスのバリエーション（４）＞
通信シーケンスのバリエーション（３）と同様、図５のステップ２７の後、ユーザが宅内から宅外に移動して、別途録画予約を行う場合のシーケンスを、以下にステップ３２〜３７として示す。
<Variation of communication sequence (4)>
Similar to the communication sequence variation (3), after step 27 in FIG. 5, a sequence in which the user moves from the house to the house and makes a separate recording reservation is shown as
（ステップ３２）ユーザが、宅内から宅外に移動する。この時、通信装置２０１は、通信をＷｉＦｉから、３ＧないしＬＴＥなどのモバイル広域通信に切り替える。すなわち、通信装置２０１は、通信の接続先を第２ネットワーク６０１から第１ネットワーク５０１に切り換える。
(Step 32) The user moves from inside the house to outside the house. At this time, the
（ステップ３３）クライアントは、ステップ１８と同様、リフレッシュトークンを用いて、アクセストークンの発行要求をトークン発行部１１２に送信する。ステップ３に記すように新規アクセストークンの発行要求でも構わない。いずれにしても、バリエーション（３）がアクセス失敗を契機としてトークン発行要求を行うのに対して、本バリエーションでは、毎回（クライアント起動時に毎回、クライアントのＩＰアドレス変更時に毎回、リソース利用要求発生時に毎回など）アクセストークン発行要求を行い、プライベートＡＰＩへのアクセス失敗を契機としない。
(Step 33) As in step 18, the client transmits an access token issuance request to the
（ステップ３４）ステップ１９と同様、トークン検証部１１５は、トークン発行要求に含まれるリフレッシュトークンを取得し、取得したリフレッシュトークンが、トークン記憶部１１７に登録されているかを確認する。これにより、対応するdevice_id(=xyz)を取得する。
(Step 34) Similar to step 19, the
（ステップ３５）ステップ６と同様、状態判定部１１４は、宅外アクセスか宅外アクセスかを判定する。ここでは、宅外アクセスであると判定する。
(Step 35) As in step 6, the
（ステップ３６）ステップ７と同様、認可対象決定部１１３は、状態判定部１１４の判定結果と、ユーザに関連づけられた対象機器３０１（device_id=xyz）に基づき、対象機器３０１に搭載されたパブリックＡＰＩを、通信装置２０１のアクセス認可対象に決定する。
(Step 36) Similar to step 7, the authorization
（ステップ３７）ステップ２２と同様、トークン発行部１１２は、認可対象決定部１１３の決定に基づき、パブリックＡＰＩ用のアクセストークンを発行する。発行されたアクセストークンは、トークン記憶部１１７に記憶される。また、トークン発行部１１２は、図２のトークン記憶部１１７におけるパブリックＡＰＩ情報（認可対象情報）を取得し、アクセストークンとパブリックＡＰＩ情報等を含むアクセストークン応答を生成する。トークン発行部１１２は、アクセストークン応答を通信装置２０１に送信する。なお、リフレッシュトークンの値は、プライベートＡＰＩ用のリフレッシュトークンと異なっていてもよい。
(Step 37) Similar to step 22, the
＜通信シーケンスのバリエーション（５）＞
バリエーション（３）、（４）と同様、図５のステップ２７の後、ユーザが宅内から宅外に移動して、別途録画予約を行う場合のシーケンスのバリエーションを示す。バリエーション（３）では、クライアントがプライベートＡＰＩへのアクセスを試行する例を示したが、本バリエーションでは、クライアントがプライベートＡＰＩを有する機器の探索機能を有し、これを毎回（クライアント起動時に毎回、クライアントのＩＰアドレス変更時に毎回、リソース利用要求発生時に毎回など）実行する。具体的には、マルチキャストＤＮＳ、ＵＰｎＰ、ＥＣＨＯＮＥＴ Ｌｉｔｅ等の周辺機器の探索機能を用いて、プライベートＡＰＩを備える機器を探索する（プロトコルは、この３つに限定されるものではなく、ホームネットワーク等を対象としたプロトコルにおいて同等機能が定義されている例は多々あり、それらを用いてもよい）。発見対象の機器の機器情報（プライベートＡＰＩを備える機器識別情報（ＩＰアドレス等）あるいはプライベートＡＰＩ）は、アクセス認可装置からアクセストークン発行時に関連情報として含まれるケース（図５のprivate_api_path）、対象機器情報を提供するＡＰＩをアクセス認可装置が別途備えているケース、あらかじめクライアントにプリセットされているケース、ユーザがクライアントに手動設定するケースが考えられる。対象機器が見つからなかった場合、クライントは、バリエーション（３）と同様、アクセス認可装置１０１のトークン発行部１１２にトークン発行要求を送信する。
<Variation of communication sequence (5)>
As with variations (3) and (4), after step 27 in FIG. 5, a sequence variation in the case where the user moves from the house to the house and makes a separate recording reservation is shown. In variation (3), an example in which a client tries to access a private API has been shown. However, in this variation, the client has a function of searching for a device having a private API, and this is performed each time (every client starts up, the client Every time the IP address is changed, every time a resource use request occurs, etc.). Specifically, a device having a private API is searched using a peripheral device search function such as multicast DNS, UPnP, ECHONET Lite, etc. (The protocol is not limited to these three. There are many examples where equivalent functions are defined in the target protocol, and they may be used). Device information (device identification information (IP address etc.) or private API with a private API) of a device to be discovered is included as related information when an access token is issued from an access authorization device (private_api_path in FIG. 5), target device information There may be a case where the access authorization device is separately provided with an API that provides the password, a case preset in the client, and a case where the user manually sets the client. When the target device is not found, the client transmits a token issuance request to the
＜構成のバリエーション（１）＞
図７に、本実施形態に係る通信システムの他の構成例を示す。図１のアクセス代行部１１６と対象機器情報記憶部１１８が、アクセス認可装置１０１から除去され、アクセス代行装置（制御代行装置）１３１として分離して配置されている。アクセス代行装置１３１は、第１ネットワーク５０１に接続されており、アクセス認可装置１２１、通信装置２０１および対象機器３０１と通信する通信部１１９を備えている。
<Configuration variation (1)>
FIG. 7 shows another configuration example of the communication system according to the present embodiment. The
他の構成例として、トークン記憶部１１７または対象機器情報記憶部１１８等の記憶部を全て別個の単独した装置として分離する構成も一般的である。その他、アクセス認可装置で構成する各要素が、様々な組み合わせで別装置として配置され、各機能間の連携が装置間の通信によって実装されてもよい。
As another configuration example, a configuration in which the storage units such as the
＜構成のバリエーション（２）＞
図８に、本実施形態に係る通信システムの他の構成例を示す。全体のシステム構成に変化は無いが、認可対象提供部１１９が追加されている。図５では、トークン発行要求の応答に、プライベートＡＰＩ情報（private_api_path）が含まれる例を示しているが、本バリエーションは、このプライベートＡＰＩ情報を提供する機能をトークン発行部１１２から分離した構成をなしている。この構成において、クライアントは、アクセストークン発行後、別途アクセス認可装置上の認可対象提供部１１９にアクセスする。認可対象提供部１１９は、アクセストークンの検証後、トークン記憶部１１７の認可対象情報（ＡＰＩ情報）を応答する。
<Configuration variation (2)>
FIG. 8 shows another configuration example of the communication system according to the present embodiment. Although there is no change in the overall system configuration, an authorization
＜構成のバリエーション（３）＞
図９に、本実施形態に係る通信システムの他の構成例を示す。図１との差分は、通信装置２０１は、ゲートウェイ装置７０１を介して１つ以上の対象機器と接続されている点である。ゲートウェイ装置と１つ以上の対象機器とは第３ネットワーク８０１を介して接続されている（通信可能な状態にある）。以下、各構成要素について説明する。
<Configuration variation (3)>
FIG. 9 shows another configuration example of the communication system according to the present embodiment. The difference from FIG. 1 is that the
第３ネットワーク８０１は、例えばＢｌｕｅｔｏｏｔｈ、無線ＬＡＮ、Ｚｉｇｂｅｅなどローカルネットワークであってもよいし、ＨＤＭＩ（登録商標）やＵＳＢなど有線であって、直接、あるいはハブを介して、ゲートウェイ装置７０１と対象機器を繋ぐものであってもよい。また、第３ネットワーク８０１は、第２ネットワーク６０１と同一のネットワークであってもよい。
The third network 801 may be a local network such as Bluetooth, wireless LAN, or Zigbee, or is wired such as HDMI (registered trademark) or USB, and directly or via a hub, the
本バリエーションにおける対象機器３０１、３０２は、上記実施形態で述べたようにプライベートＡＰＩを備えるものであってもよいが、備えていなくてもよい。本実施形態では備えないものとするが、ゲートウェイ装置７０１によるリソース利用を受け付ける通信機能は備えているものとする。具体的には、ＥＣＨＯＮＥＴ Ｌｉｔｅ対応家電等、何らかのホームネットワーク上で機器を制御するプロトコルに準拠した機器であるものとする。
The
ゲートウェイ装置７０１は、第２ネットワーク６０１に接続されるインタフェースと、第３ネットワーク８０１に接続されるインタフェースを有する。ゲートウェイ装置７０１は、通信装置２０１と対象機器３０１，３０２との間に介在し、リソース利用要求および応答を中継する装置である。例えばブロードバンドルータのようなルータ装置であったり、ＰＣやスマートフォンといった一般的な計算機の構成をとる装置であったり、スマートメータであったりしてよい。すなわち、ゲートウェイ装置７０１は、中継装置４０１と同一であってもよく、さらには、通信装置２０１と同一であってもよい。ここでは、ブロードバンドルータであるものとする。
ゲートウェイ装置７０１は、プライベートＡＰＩを備え、第３ネットワーク８０１を介して接続された対象機器３０１，３０２を制御する。すなわち、ゲートウェイ装置７０１は、アクセス認可装置１０１のアクセス代行部１１６と同様のアクセス代行部と、接続された対象機器をアクセス認可装置１０１に登録する登録部と、を備える。またゲートウェイ装置７０１は、対象機器情報記憶部１１８に準ずる機能、すなわち、ゲートウェイ装置７０１上のアクセス代行部が受信した通信装置２０１からの要求から、リソース利用の対象機器を特定するための変換情報を備えている。ＡＰＩのＵＲＬ中にデバイス識別子を含む場合には、例えばＵＲＬから制御対象機器への命令（例えばＥＣＨＯＮＥＴ Ｌｉｔｅリクエスト）に変換する機能をゲートウェイ装置７０１は備える。
The
The
本バリエーションにおいて、ＡＰＩは、あらたにゲートウェイ装置７０１がプライベートＡＰＩを備えることを想定したデータ構造になる。一例であるが、パブリックＡＰＩの構成を、以下のようにする実現形態が考えられる。
これに対応づけて、対象機器情報記憶部１１８のテーブル構造を２階層してもよい。すなわちゲートウェイ識別子とベースとなるＵＲＬ（プライベートおよびパブリック用のそれぞれのＵＲＬ）とを記憶したテーブルと、属するゲートウェイ識別子を含む対象機器情報で構成されるテーブル（この場合、機器識別情報は、アクセス認可装置内で一意に識別できるものでなく、ゲートウェイ装置内で一意に識別できるレベルの識別子であってもよい）と、で構成する方法が考えられる。
または、１階層で構成し、各対象機器情報が、属するゲートウェイ識別情報と、ベースとなるそのＵＲＬ情報（図２における認可対象情報）を保持するように構成してもよい。
これにより、アクセス認可装置１０１は、対象機器の特定と同時に適切なゲートウェイ装置のプライベートＡＰＩを特定することができる。本バリエーションにより、クラウドＡＰＩとゲートウェイ装置のプライベートＡＰＩを、シームレスに切り替えることが可能となる。
Correspondingly, the table structure of the target device
Alternatively, it may be configured in one layer, and each target device information may be configured to hold the gateway identification information to which it belongs and the URL information (authorization target information in FIG. 2) as a base.
Thereby, the
（第２の実施形態）
本実施形態は、ユーザが宅外から宅内に移動すると、ユーザのポリシー設定に基づき、パブリックＡＰＩ利用からプライベートＡＰＩ利用に切り替えるか否かをユーザに問い合わせる等、いくつかの機能を追加したことを特徴とする。以下、本実施形態について詳細に説明する。
(Second Embodiment)
This embodiment is characterized by the addition of several functions such as inquiring the user whether to switch from public API usage to private API usage based on the user's policy settings when the user moves from outside the home. And Hereinafter, this embodiment will be described in detail.
図１０は、第２の実施形態に係る通信システムを示す。第１の実施形態に対しアクセス認可装置の構成が異なっている。本実施形態のアクセス認可装置１２１は、ポリシー記憶部１４３と、対象機器登録部１４２と、アクセス制御部１４１が新たに追加されている。
FIG. 10 shows a communication system according to the second embodiment. The configuration of the access authorization device is different from that of the first embodiment. In the
ポリシー記憶部１４３は、ＡＰＩ切り替え（あるいはトークン切り替え）に関するポリシー情報を記憶する。ポリシー情報は、一例として、ユーザにＡＰＩの切り替え（あるいはトークンの切り替え）を問い合わせるか否かの設定を含む。別の例として、宅内にいても、常にパブリックＡＰＩを使用することを示す設定を含むポリシーもあり得る。
The
対象機器登録部１４２は、対象機器３０１から登録要求、あるいは、更新要求を受信し、当該要求に従って、対象機器情報記憶部１１８に情報を記憶または情報を更新する。本実施形態では、対象機器３０１は、対象機器３０１のＩＰアドレスまたはホスト名またはこれらの両方等が変更される際に、更新要求を発行する。対象機器情報記憶部１１８にはＩＰアドレスまたはホスト名に基づくプライベートＡＰＩパスが登録されており（図３参照）、ＩＰアドレスまたはホスト名が変更されれば、プライベートＡＰＩパスも更新する。ＩＰアドレスまたはホスト名からプライベートＡＰＩパスを生成する仕組みは事前に定まっているものとする。
または、対象機器３０１が、変更後のＩＰアドレスまたはホスト名に基づきプライベートＡＰＩパスを生成し、これを含む更新要求をアクセス認可装置１５１に送信してもよい。この場合は、更新要求に含まれるプライベートＡＰＩパスを対象機器情報記憶部１１８に登録すればよい。
登録要求の場合も同様であり、ＩＰアドレスまたはホスト名から対象機器登録部１４２がプライベートＡＰＩパスを生成してもよいし、対象機器３０１が、ＩＰアドレスまたはホスト名に基づきプライベートＡＰＩパスを生成し、これを含む登録要求をアクセス認可装置１５１に送信してもよい。
なお、プライベートＡＰＩパスが変更または登録された場合は、これに応じて図２のトークン記憶部１１７内のプライベートＡＰＩ用の認可対象情報（ＡＰＩ情報）も、変更後のプライベートＡＰＩパスに基づいたものに更新するものとする。
対象機器登録部１４２を、図１、図７、図８または図９のアクセス認可装置に設けてもよい。
The target
Alternatively, the
The same applies to a registration request. The target
If the private API path is changed or registered, the authorization object information (API information) for the private API in the
The target
アクセス制御部１４１は、トークン発行部１１２がプライベートＡＰＩへのアクセストークンを発行する場合に、アクセス対象の対象機器３０１にプライベートＡＰＩの有効化要求を送信する。あるいは、プライベートＡＰＩへのアクセストークンを無効化する場合に、対象機器３０１にプライベートＡＰＩの無効化要求を送信する。
When the
対象機器３０１は、アクセス制御部１４１から有効化要求を受けると、対象機器３０１のプライベートＡＰＩをホームネットワーク（第２ネットワーク６０１）からアクセス可能にする。また、対象機器３０１は、アクセス制御部１４１から無効化要求を受けると、対象機器３０１のプライベートＡＰＩをホームネットワーク（第２ネットワーク６０１）からアクセスできないようにする。具体的には、対象機器３０１において、通信装置２０１に搭載されるクライアントからのアクセスを受け付けるサーバ機能の起動または停止を行う。
Upon receiving an activation request from the
あるいは、アクセス制御部１４１を、単に、有効化または無効化のトリガーを与えるように構成にし、実際に有効化または無効化するかは、対象機器３０１側で判断するようにしてもよい。またアクセス制御部１４１は、初回のプライベートＡＰＩ発行時には、プライベートＡＰＩを有効化する更新ファームウェアを、対象機器に送信するようにしてもよい。
Alternatively, the
以下、第２の実施形態に係る通信シーケンスを示す。ここでは第１の実施形態に係る通信シーケンス（図４および図５）との差分のみを説明する。 The communication sequence according to the second embodiment is shown below. Here, only the difference from the communication sequence (FIGS. 4 and 5) according to the first embodiment will be described.
図４のステップ１の前に、対象機器３０１が、初期登録処理として、ＩＰアドレスなど対象機器情報を、アクセス認可装置１５１の対象機器登録部１４２を介して、対象機器情報記憶部１１８に登録する。このとき、アクセス認可装置１５１は、対象機器３０１の認証を行う必要がある。また、ユーザと当該対象機器３０１を関連づける必要がある。認証および関連づけの双方について、様々な実現方法がある。
Prior to step 1 in FIG. 4, the
例えば、対象機器３０１に予め装置認証用の秘密情報を登録しておき、これを、アクセス認可装置１５１に送信することで、正当な対象機器３０１のみが対象機器情報をアクセス認可装置１５１に登録できるようにする。また、ユーザは、対象機器３０１の秘密情報と共に、所有機器の情報をアクセス認可装置１５１に登録する。シンプルな実現方法としては、対象機器３０１の筐体に秘密情報が貼り付けてあり、アクセス認可装置１５１の登録画面を介して、ユーザがこれを手動登録する等がある。ここで述べた例は一例であり、他にも様々な方法が可能である。
For example, by registering secret information for device authentication in advance in the
なお、対象機器３０１は、初期登録処理時だけでなく、ＩＰアドレスの変更など機器情報の変更を検知すると、その都度、アクセス認可装置１５１に対象機器情報の更新要求を送信する。アクセス認可装置１５１の対象機器登録部１４２は、更新要求に基づき、対象機器情報記憶部１１８内の対象機器３０１に関する情報を更新する。
Note that the
図４のステップ１の認可画面に、ポリシー情報の選択インタフェースを表示し、宅外から宅内へ移動した場合に、ＡＰＩ切り替え（トークン切り替え）の確認画面を表示するか否かの設定を含むポリシー情報を、ユーザに選択可能に表示させてもよい。他の種類のポリシー情報も表示し、ユーザが任意のポリシー情報を選択できるようにしてもよい。もちろん、ユーザは、どのポリシー情報を選択しなくてもよく、この場合、第１の実施形態と同様の動作となる。
Policy information including a setting for whether to display an API switching (token switching) confirmation screen when the policy information selection interface is displayed on the authorization screen in
図４のステップ２で、ユーザは、認可画面に表示されたポリシー情報を選択する。 In step 2 of FIG. 4, the user selects the policy information displayed on the authorization screen.
図４のステップ３で、通信装置からアクセス認可装置１５１に送信するトークン発行要求に、ユーザが選択したポリシー情報を含める。
In step 3 of FIG. 4, the policy information selected by the user is included in the token issue request transmitted from the communication device to the
図４のステップ８で、トークン発行時にパブリックＡＰＩ用のアクセストークンと関連付けて、ポリシー情報を登録する。上記例では、ポリシー情報の設定をステップ２で行うユーザの認可と関連付けているが、ステップ２のユーザの認可と独立して、ポリシー設定を行えるように構成してもよい。 In step 8 of FIG. 4, policy information is registered in association with an access token for public API when a token is issued. In the above example, the policy information setting is associated with the user authorization performed in step 2, but the policy information may be configured to be independent of the user authorization in step 2.
図５のステップ１７とステップ１８の間で、ステップ１７Ａとして、通信装置２０１はＡＰＩ切り替え（トークン切り替え）の確認画面を表示する。例えば、そのままパブリックＡＰＩを使い続けるか、プライベートＡＰＩに切り替えるかを、ユーザに選択させる確認画面を表示する。確認画面の例を図１１（Ａ）に示す。ここでは、ユーザがプライベートＡＰＩに切り換える選択をした場合を想定する。
Between step 17 and step 18 in FIG. 5, as step 17A, the
図５のステップ２１とステップ２２の間で、ステップ２１Ａとして、アクセス認可装置１５１のアクセス制御部１４１は、対象機器３０１に、プライベートＡＰＩの有効化要求を送信する。対象機器３０１は、有効化要求を受けて、プライベートＡＰＩをホームネットワークからアクセス可能にする。具体的には、通信装置２０１に搭載されるクライアントがアクセスするサーバ機能（ＨＴＴＰサーバ）を対象機器３０１が起動する。反対に、プライベートＡＰＩからパブリックＡＰＩに切り替える場合には、アクセス制御部１４１は対象機器３０１に無効化要求を行うように構成してもよい。この場合、対象機器３０１は、サーバ機能の動作を停止させる。なお、プライベートＡＰＩからパブリックＡＰＩに切り替える場合には、図１１（Ｂ）に示す確認画面を表示して、ユーザに切り換えを許可するか選択させてもよい。
Between step 21 and step 22 in FIG. 5, as step 21 </ b> A, the
なお、ステップ２２において、対象機器３０１のＩＰアドレスが変更されている場合には、これに追従した新しいプライベートＡＰＩに対するアクセストークンを発行することができる。
If the IP address of the
以上、本実施形態によれば、ユーザが、より柔軟なポリシー設定に基づき、パブリックＡＰＩおよびプライベートＡＰＩ間の切り替えを制御できる。また、対象機器３０１のＩＰアドレスが変化することに起因して、クライアントがプライベートＡＰＩへのアクセスに失敗するケースを回避できる。また、必要時にのみプライベートＡＰＩを有効化することで、ホームネットワーク上でのリソース利用のセキュリティを高めることができる。
As described above, according to the present embodiment, the user can control switching between the public API and the private API based on more flexible policy settings. Further, it is possible to avoid a case where the client fails to access the private API due to the change of the IP address of the
（第３の実施形態）
第１および第２の実施形態では、宅内ネットワークの対象機器にアクセスするプライベートＡＰＩは１つのみであったが、複数のプライベートＡＰＩが存在する場合もある。例えば、ゲートウェイ装置（図９参照）が複数のプライベートＡＰＩを備える場合がある。このとき、アクセス認可装置（サーバ）１０１は、通信装置２０１に、どちらのプライベートＡＰＩの使用を許可すれば、通信装置２０１上のクライアント（アプリ）が、対象機器を操作（アクセス）できるか分からない。このことを、図１２を用いて説明する。
(Third embodiment)
In the first and second embodiments, there is only one private API that accesses the target device of the home network, but there may be a plurality of private APIs. For example, the gateway device (see FIG. 9) may include a plurality of private APIs. At this time, the access authorization device (server) 101 does not know which of the private APIs the
図１２に本実施形態に係る通信システムの例を示す。ゲートウェイ装置９０１は、第２ネットワーク６０１側のインタフェースからアクセス可能なプライベートＡＰＩ（プライベートＡＰＩ−１と記述する）と、第３ネットワーク８０１側のインタフェースからアクセス可能なプライベートＡＰＩ（プライベートＡＰＩ−２と記述する）とを有する。第２の実施形態では通信装置２０１が、第２ネットワーク６０１に接続されていたが、図９では、第３ネットワーク８０１に接続されている。通信装置２０１が第２ネットワーク６０１に接続される場合は破線で示している。ゲートウェイ装置９０１の第２ネットワーク６０１側のネットワークアドレスと、第３ネットワーク８０１側のネットワークアドレスとは互いに異なる。例えば第２ネットワーク６０１側のネットワークアドレスが、１９２．１６８．０．０／２４であり、第３ネットワーク８０１側のネットワークアドレスが、１９２．１６８．１２６．０／２４である。
FIG. 12 shows an example of a communication system according to this embodiment. The
通信装置２０１上のクライアントは、通信装置２０１が第３ネットワーク８０１に接続されているときは、プライベートＡＰＩ−２にアクセスすれば、ゲートウェイ装置９０１を介して、対象機器（３０１または３０２）を操作可能である。クライアントは、プライベートＡＰＩ−１にアクセスした場合は、対象機器を操作できない。一方、通信装置２０１上のクライアントは、通信装置２０１が第２ネットワーク６０１に接続されているときは、プライベートＡＰＩ−１にアクセスすれば、ゲートウェイ装置９０１を介して、対象機器を操作可能である。ただし、クライアントは、プライベートＡＰＩ−２にアクセスした場合は、対象機器を操作できない。
When the
アクセス認可装置１０１が、通信装置２０１が第２ネットワーク６０１および第３ネットワーク８０１のどちらに接続されているかを把握できれば、それに応じて適切なプライベートＡＰＩ情報を通信装置２０１に通知することも可能である。しかしながら、アクセス認可装置１０１が、通信装置２０１がどちらのネットワークに接続されているかを把握できない場合もある。例えば中継装置４０１のＮＡＴ機能により、中継装置４０１の配下の装置からの送信パケットの送信元アドレスは中継装置４０１のグローバルＩＰアドレスに統一され、アクセス認可装置１０１では、通信装置２０１がどのローカルネットワーク（６０１、８０１）に接続されているかを判断できない。
If the
そこで、本実施形態では、アクセス認可装置１０１が、ゲートウェイ装置の複数のプライベートＡＰＩ情報を通信装置２０１に通知する。通信装置２０１が複数のプライベートＡＰＩ情報のうち、利用可能なプライベートＡＰＩ情報を特定し、特定したプライベートＡＰＩ情報を用いて、ゲートウェイ装置を介して、対象機器にアクセス（対象機器を操作）する。本実施形態に係る対象機器情報記憶部の構成例を図１３に示す。デバイス識別子が“ｈｗｇ１”のゲートウェイ装置のプライベートAPIパスが２つ登録されている。なお、APIパスの登録形態は、図１３（および前述した図３）では、“https://”と“/V1”との間にIPアドレスを配置した形態であるが、IPアドレスのみの形態でもよいし、“/V1”を省いた形態でもよいし、その他の形態でもよい。
Therefore, in this embodiment, the
以下、本実施形態の動作例を示す。なお、図９を用いて行った説明と重複する説明は、適宜省略する。 Hereinafter, an operation example of this embodiment will be described. In addition, the description which overlaps with the description performed using FIG. 9 is abbreviate | omitted suitably.
まず、初期設定として、通信装置２０１がアクセストークンの発行を受けるまでの動作例を示す。
First, as an initial setting, an operation example until the
スマートフォン等の通信装置２０１上で動作するクライアント（アプリケーション）は、対象機器における特定機能（録画予約など）を利用するために、アクセス認可装置１０１に、トークン発行要求を送信する（図４のステップ３）。
A client (application) operating on the
トークン発行要求を受けたアクセス認可装置１０１は、クライアント認証およびユーザ認証を行う（ステップ５およびステップ６）。ユーザ認証とともに、ユーザの認可を求める画面を通信装置２０１に表示させてもよい。この場合、例えば、トークン発行要求を認証認可ＵＲＬへ転送（リダイレクト）してもよい。ユーザは、自身の認証情報と、クライアントによる特定機能の利用を認可する旨とを入力する。認証および認可のいずれかが正しく行われなかった場合、トークン発行を行うことができない旨を、アクセス認可装置１０１はクライアントに通知する。
The
認証および認可が正しく行われた場合、通信装置の状態判定（通信装置２０１が宅内に存在するか、宅外に存在するか）に応じて、パブリックまたはプライベート用のアクセストークンが、クライアントに対して発行される。または、アクセストークンに加えて、リフレッシュトークンを発行してもよい、両方の役割を兼ねた単一のアクセストークンを発行してもよい。
If authentication and authorization are performed correctly, a public or private access token is sent to the client according to the state determination of the communication device (whether the
通信装置２０１（クライアント）が宅外に存在し、パブリックアクセス用のアクセストークンが発行された場合の、以降のＡＰＩアクセス手順を述べる。 The following API access procedure when the communication apparatus 201 (client) exists outside the home and an access token for public access is issued will be described.
アクセストークンを受け取ったクライアントは、パブリックＡＰＩ情報に基づき、アクセス認可装置１０１に対して、録画予約などのパブリックＡＰＩアクセスを行う（図４のステップ９）。これに先駆けて、クライアントは、宅外に自身が存在することを確認するために、アクセス認可装置などに、クライアントの状態判定（宅内と宅外のどちらに存在するか）を要求してもよい。
The client that has received the access token performs public API access such as recording reservation to the
パブリックＡＰＩアクセスを受けたアクセス認可装置は、アクセストークンの有効性の検証と、通信装置２０１（クライアント）の状態判定（宅内と宅外のどちらに存在するか）を行う（ステップ１０、ステップ１１）。アクセストークンが有効であり、通信装置２０１が宅外に存在する場合は、アクセス認可装置は、対象機器（録画機器等）に対して、録画予約などの制御を実行する。具体的には、アクセス代行部１１６が、通信装置２０１からのパブリックＡＰＩへのアクセスを受けて、アクセス代行部１１６がリソースの利用要求をゲートウェイ装置９０１に送信する（ステップ１２、ステップ１３）。なお、アクセス代行部１１６がゲートウェイ装置９０１を利用する方法は事前に定められているものとする。専用のＡＰＩが用意されていてもよいし、プライベートＡＰＩのＵＲＬを含むデータをゲートウェイ装置９０１に送信し、ゲートウェイ装置９０１が当該データに含まれるプライベットＡＰＩのＵＲＬを内部的に解釈および実行してもよい。一方、アクセストークンが有効でない場合、または通信装置２０１が宅内に存在すると判断した場合、パブリックＡＰＩアクセスを許可できない旨を、クライアントに応答する（図５のステップ１６、ステップ１７、およびステップ１７に続く“認可エラー応答”のシーケンスを参照）。
The access authorization device that has received public API access verifies the validity of the access token and determines the state of the communication device 201 (client) (whether it exists in the house or outside the house) (steps 10 and 11). . When the access token is valid and the
なお、アクセストークンの有効性の検証において、アクセストークンが有効でないと判断された場合は、アクセス認可装置は、自装置へのアクセス情報（トークン発行要求の方法など）を、クライアントに通知しても良い。 In the verification of the validity of the access token, if it is determined that the access token is not valid, the access authorization device may notify the client of access information (such as a token issuance request method) to the device itself. good.
通信装置２０１（クライアント）のユーザが、通信装置２０１を保持したまま、宅外から宅内に移動したとする。すなわち、通信装置２０１が宅外に存在する状態から、宅内に存在する状態に変わったとする。この場合に、通信装置２０１上のクライアントが、パブリックＡＰＩ情報に基づき、アクセス認可装置１０１に対して、録画予約などのパブリックＡＰＩアクセスを行ったとする（図４のステップ９）。アクセス認可装置１０１は、通信装置２０１の状態判定において、通信装置２０１が宅内に存在すると判断して、パブリックＡＰＩアクセスを許可できない旨を、クライアントに応答する（図５のステップ１６、ステップ１７、およびステップ１７に続く“認可エラー応答”のシーケンスを参照）。これにより、クライアントは、通信装置２０１が宅外から宅内に移動したことを知る。あるいは、前述のように、クライアントが、通信装置２０１が宅外および宅内のいずれの状態であるかを確認するために、アクセス認可装置などに状態判定を要求してもよい。
It is assumed that the user of the communication apparatus 201 (client) moves from outside the house to the house while holding the
通信装置２０１上のクライアントは、トークン発行要求（例えばリフレッシュトークンを含む）をアクセス認可装置１０１に送信し（図５のステップ１８）、アクセス認可装置１０１は、リフレッシュトークンを検証し、状態判定を行う。ここでは、検証に成功し、通信装置２０１が宅内に存在すると判断する。そして、アクセス認可装置１０１は、通信装置２０１に提供する認可対象情報（ＡＰＩ情報）を決定する。ここでは、前述したように、ゲートウェイ装置９０１のデバイス識別子（ｄｅｖｉｃｅ＿ｉｄ）に対して複数のプライベートＡＰＩが存在する。第１の実施形態の図９の例では、プライベートＡＰＩパスが１つ存在したが、本実施形態では複数のプライベートＡＰＩパスが存在する。なお、ＡＰＩパスごとに、機能（“ｓｔａｔｕｓ”または“ｒｅｓｅｒｖｅｄ＿ｐｒｏｇｒａｍ”）ごとのＡＰＩ情報（図２参照）が存在する。
The client on the
アクセス認可装置１０１は、クライアントから要求された機能（録画等）に対応する複数のＡＰＩ情報を含むリストを送信する。複数のＡＰＩ情報のリストの代わりに、複数のＡＰＩパスを含むリストを送信してもよい。この場合、ＡＰＩパスの末尾には端末側で、機能に応じた文字列を付加して、ＡＰＩ情報と同じものを生成できるものとする。ＡＰＩパスは、ＡＰＩ情報の一部（例えばＡＰＩ情報から機能を特定する部分を除いたもの）に相当する（図２および図３参照）。通信装置２０１が、ゲートウェイ装置９０１が備える複数のインタフェースのうちのどれと同じネットワークに接続されているかは、アクセス認可装置では分からない場合があり、複数のＡＰＩ情報のうちの１つを特定することはできない。このため、アクセス認可装置１０１は、ゲートウェイ装置が備えるすべてのプライベートＡＰＩパス（またはクライアントから要求された機能に関するすべてのプライベートＡＰＩ情報）のリストを提供する。なお、上述したようなクライアントが状態判定を要求した際に、プライベートＡＰＩパスのリストを、アクセス認可装置１０１からクライアントに提供してもよい。
The
複数のプライベートＡＰＩ情報のリスト（または、プライベートＡＰＩパスのリスト）を受け取ったクライアントは、どのプライベートＡＰＩ情報を利用するか判定する必要がある。これには複数の方法が考えられる。 A client that has received a list of a plurality of private API information (or a list of private API paths) needs to determine which private API information to use. There are several ways to do this.
（第１の方法）各ＡＰＩパスを順番に選択して、選択したＡＰＩパスに対して、ｄｅｖｉｃｅ＿ｉｄの返信を要求するメッセージを送信する。選択したＡＰＩパスが、利用できないＡＰＩパスなら、応答は来ない。選択したＡＰＩパスが、期待したＡＰＩパスと異なっているなら、応答されるｄｅｖｉｃｅ＿ｉｄは、自装置がアクセスしたい装置のｄｅｖｉｃｅ＿ｉｄ（期待する値）と異なる（例えば複数のサブネットが存在し、サブネットごとに同じＩＰアドレスのゲートウェイ装置が存在する状況があり得る）。応答されたｄｅｖｉｃｅ＿ｉｄと、期待する値とが一致した場合、選択したＡＰＩパスは正解である。正解のＡＰＩパスが分かった後は、正解のＡＰＩパスを含むプライベートＡＰＩ情報に基づき、ＡＰＩアクセスを実行する（図５のステップ２３）。このとき、ゲートウェイ装置９０１は、アクセス認可装置１０１に対して、ＡＰＩアクセスでクライアントから送られるトークンの検証を要求する（図５のステップ２４）。この際、アクセス認可装置が備えるｔｏｋｅｎ ｉｎｔｒｏｓｐｅｃｔｉｏｎ ｅｎｄｐｏｉｎｔを利用してもよい。
(First Method) Each API path is selected in order, and a message requesting a reply of device_id is transmitted to the selected API path. If the selected API path is an unavailable API path, no response is received. If the selected API path is different from the expected API path, the returned device_id is different from the device_id (expected value) of the device that the device wants to access (for example, multiple subnets exist and the same for each subnet) There may be a situation where there is a gateway device of an IP address). If the returned device_id matches the expected value, the selected API path is correct. After the correct API path is known, API access is executed based on the private API information including the correct API path (step 23 in FIG. 5). At this time, the
（第２の方法）クライアントは、ＡＰＩ情報のリストとともに、アクセス認可装置１０１からサーバ証明書（非対称）または事前共有鍵（ＰＳＫ、対称）またはこれらの両方を受信する。アクセス認可装置は、サーバ証明書または事前共有鍵等も、ゲートウェイ装置のｄｅｖｉｃｅ＿ｉｄに対応づけて、事前に内部に記憶しておく。クライアントは、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）またはＤＴＬＳ（Ｄａｔａｇｒａｍ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）などの認証機能を使って、正解のＡＰＩパスを判定する。ネットワークで利用できないＡＰＩパスを用いて認証を試みたなら、ゲートウェイ装置９０１から応答は来ない（ＩＰレイアの通信に失敗する）。また、期待するＡＰＩパスと異なるＡＰＩパスを用いた場合、認証に失敗する。つまり、ＩＰレイヤでの通信は成功するが、ＴＬＳ等の認証に失敗する。正解のＡＰＩパスが分かった後の動作は、第１の方法と同様である。
(Second Method) The client receives the server certificate (asymmetric) and / or the pre-shared key (PSK, symmetric) or both from the
第１の方法および第２の方法以外の方法を用いて、使用するＡＰＩパスを決定してもよい。 The API path to be used may be determined using a method other than the first method and the second method.
図１４に、アクセス認可装置から複数のＡＰＩパスを取得し、利用するＡＰＩパスを特定する場合の動作のシーケンス例を示す。ゲートウェイ装置は、自装置が有する複数のＡＰＩパスを、アクセス認可装置に通知する（ステップ７１）。アクセス認可装置は、通知された複数のＡＰＩパスを登録し、応答を返す（ステップ７２）。なお、応答のパケットの送信先のアドレスは、例えばグローバルＩＰアドレス（例えば“１３３．１９６．２９．２”）であるが、ルータ４０１のＮＡＴ機能により、送信先のアドレスは、ローカルのＩＰアドレスに変換されて、パケットがゲートウェイ装置に届く。なお、ＩＰアドレスのみでなく、宛先ポート番号も変換される構成もある。
FIG. 14 shows a sequence example of an operation when acquiring a plurality of API paths from the access authorization device and specifying an API path to be used. The gateway device notifies the access authorization device of a plurality of API paths that the gateway device has (step 71). The access authorization device registers the notified plurality of API paths and returns a response (step 72). Note that the destination address of the response packet is, for example, a global IP address (for example, “133.196.29.2”), but the NAT function of the
通信装置上のクライアントが、宅内に存在する状況において、アクセス認可装置に対して、ゲートウェイ装置が備える複数のＡＰＩパスを含むリストを応答するよう、要求したとする（ステップ７３）。 Assume that the client on the communication device requests the access authorization device to respond with a list including a plurality of API paths provided in the gateway device in a situation where the client exists in the home (step 73).
アクセス認可装置は、クライアントのユーザに関連づけられて登録されているゲートウェイ装置を特定（または、パケットの送信元アドレスに関連づけられて登録されているゲートウェイ装置を特定）し、特定したゲートウェイ装置が備える複数のＡＰＩパスを特定する。 The access authorization device identifies a gateway device registered in association with the user of the client (or identifies a gateway device registered in association with the transmission source address of the packet), and a plurality of the gateway devices identified Specify the API path of.
ここでは、アクセス認可装置は、２つのゲートウェイ装置（図のｈｇｗ１と、ｈｇｗ２）を特定し、それぞれに対して、２つのＡＰＩパス（ＷＡＮ側のインタフェースのＡＰＩパスと、ＬＡＮ側のインタフェースのＡＰＩパス）を特定する。なお、ここでのＡＰＩパスは、プライベートＡＰＩパスである。 Here, the access authorization device identifies two gateway devices (hgw1 and hgw2 in the figure), and for each, two API paths (an API path of the WAN side interface and an API path of the LAN side interface) ). The API path here is a private API path.
アクセス認可装置は、一方のゲートウェイ装置識別子“ｈｇｗ１”とその２つのＡＰＩパス、ならびに、もう一方のゲートウェイ装置の識別子“ｈｇｗ２”とその２つのＡＰＩパス、とを含むメッセージを、通信装置上のクライアントに応答する（ステップ７４）。 The access authorization device sends a message including one gateway device identifier “hgw1” and its two API paths, and another gateway device identifier “hgw2” and the two API paths to the client on the communication device. (Step 74).
応答のパケットの送信先のアドレスは、例えばグローバルＩＰアドレス（例えば“１３３．１９６．２９．２”）あるが、ルータ４０１のＮＡＴ機能により、送信先のアドレスはローカルのＩＰアドレスに変換されて、パケットが通信装置（クライアント）に届く。なお、ＩＰアドレスのみでなく、宛先ポート番号も変換される構成もある。
The destination address of the response packet is, for example, a global IP address (for example, “133.196.29.2”), but the NAT function of the
通信装置上のクライアントは、まず一方のゲートウェイ装置（ここではｈｇｗ１）を特定し、特定したゲートウェイ装置が備える複数のＡＰＩパスのうちの一方を選択して、ｄｅｖｉｃｅ＿ｉｄの返答を要求するメッセージを送信する（ステップ７５）。しかしながら、選択したＡＰＩパスは、当該ゲートウェイ装置のＷＡＮ側のネットワークで利用できないため、メッセージに対する応答は送信されない（タイムアウトになる）。通信装置は、もう一方のＡＰＩパスを選択して、ｄｅｖｉｃｅ＿ｉｄの返答を要求するメッセージを送信する（ステップ７６）。アクセス認可装置は、当該メッセージに対して、自装置の識別子“ｈｇｗ１”を含む応答を返す（ステップ７７）。この応答に含まれる識別子は、クライアントが期待する識別子と一致するため、当該ＡＰＩパスに基づくＡＰＩ情報を用いて、ゲートウェイ装置にプライベートＡＰＩアクセスすることにより、ゲートウェイ装置の配下の対象機器を制御する（ステップ７８）。 The client on the communication device first identifies one gateway device (here, hgw1), selects one of a plurality of API paths provided in the identified gateway device, and transmits a message requesting a response of device_id. (Step 75). However, since the selected API path cannot be used in the WAN side network of the gateway device, a response to the message is not transmitted (timeout occurs). The communication device selects the other API path and transmits a message requesting a response of device_id (step 76). In response to the message, the access authorization device returns a response including its own identifier “hgw1” (step 77). Since the identifier included in the response matches the identifier expected by the client, the target device under control of the gateway device is controlled by performing private API access to the gateway device using API information based on the API path ( Step 78).
図１５に、アクセス認可装置から複数のＡＰＩパスを取得し、利用するＡＰＩパスを１つに特定する場合の動作の他のシーケンス例を示す。最初のステップ７１、７２は図１４と同様である。
FIG. 15 shows another sequence example of the operation when acquiring a plurality of API paths from the access authorization device and specifying one API path to be used. The
ステップ７２に続くステップ８１では、通信装置上のクライアントが、自装置の状態判定（宅内および宅外のいずれに存在するか）の問い合わせのメッセージを送信する。アクセス認可装置は、状態判定を行うことにより、通信装置が宅内に存在すると判断する。また、アクセス認可装置は、宅内に存在しうるゲートウェイ装置として、ここではｈｇｗ１の１つを特定する（ここでは、たまたまユーザまたは送信元IPアドレスに対して、１つのゲートウェイ装置のみがアクセス認可装置に登録されていたとする）。アクセス認可装置は、ゲートウェイ装置の識別子“ｈｇｗ１”と、その２つのＡＰＩパスとを含むメッセージを、通信装置上のクライアントに応答する（ステップ８２）。この後のステップ７５〜７８は、図１４と同じである。
In
図１６は、図１５のシーケンスにおいて通信装置が宅外にいると判定された場合の動作の例を示す。ステップ７１、７２、８１までは図１５と同じである。
FIG. 16 shows an example of the operation when it is determined in the sequence of FIG. 15 that the communication device is outside the home.
ステップ８１の次のステップ８５として、アクセス認可装置は、通信装置が宅外に存在することを通知するメッセージを送信する。通信装置上のクライアントは、パブリックＡＰＩ情報に基づき、アクセス認可装置に対してパブリックＡＰＩアクセスを行う（ステップ８６、８７）。なお、パブリックアクセス用のアクセストークンの発行をまだ受けていない場合、トークン発行要求を先に行う。
As
前述した図１４のシーケンスでは、通信装置が仮に宅外にいる状態で、各APIパスに対する検査（ステップ７５およびステップ７６）を行った場合、各APIパスともタイムアウトになるまで、クライアントは、通信装置が宅外にいることが分からない。タイムアウトになった時点で、クライアントは、宅外アクセスに切り換えることができる。一方、図１５および図１６のシーケンスでは、クライアントがアクセス認可装置に状態判定を要求するため、宅内および宅外のいずれにいるかが事前に分かった上で、クライアントは動作することができる。したがって、図１５および図１６のシーケンスでは、宅外にいる場合の動作の遅延を防止できる利点がある。
In the above-described sequence of FIG. 14, when an inspection is performed on each API path (
（第４の実施形態）
第１ネットワーク５０１がＣＧＮ（Ｃａｒｒｉｅｒ Ｇｒａｄｅ ＮＡＴ）またはＬＳＮ（Ｌａｒｇｅ Ｓｃａｌｅ ＮＡＴ）（以下、ＣＧＮ／ＬＳＮと記載）の機能を備える場合を想定する。この場合、アクセス認可装置による状態判定によって、通信装置が宅内に存在すると判断されたにも関わらず、クライアントが、アクセス認可装置から通知された全てのプライベートＡＰＩパスのいずれにもアクセスできない状況が発生する場合がある。
(Fourth embodiment)
It is assumed that the
図１７に、本実施形態に係る通信システムの構成例を示す。図１７の通信システムは、図１０の構成をベースにしている。第１ネットワーク５０１は、ＣＧＮ／ＬＳＮの機能を備えている。中継装置１１０１および第３ネットワーク１１０２は、中継装置４０１、第２ネットワークおよび対象機器３０１とは別の家屋内に配置されている。通信装置１１０３は、スマートフォン等の通信装置である。第３ネットワーク１１０２は、例えばホームネットワーク（ローカルネットワーク）である。ただし、第２ネットワーク６０１の場合と同様、他の種類のネットワークでもよい。中継装置１１０１は、ＮＡＴ機能を備えたブロードバンドルータである。図では通信装置１１０３が第３ネットワーク１１０２に接続されている。通信装置１１０３は、中継装置１０１を介して第１ネットワーク５０１に接続されている。ただし、通信装置１１０３は、第１ネットワーク５０１に直接接続することも可能である。
FIG. 17 shows a configuration example of a communication system according to the present embodiment. The communication system of FIG. 17 is based on the configuration of FIG. The
通信装置１１０３が第３ネットワーク１１０２に接続されているときに、第２ネットワーク６０１に接続された対象機器３０１を制御する場合を考える。通信装置１１０３上のクライアントが、中継装置１１０１を介してアクセス認可装置１５１に、プライベートＡＰＩアクセス用のトークン発行要求（図５のステップ１８）を送信する。アクセス認可装置が、トークン検証および状態判定を行い、通信装置１１０３が宅内に存在すると判断する。
Consider a case in which the
第１ネットワーク５０１がＣＧＮ／ＬＳＮの機能を備える場合、中継装置１１０１および中継装置４０１のいずれのＷＡＮ側インタフェース（第１ネットワーク５０１側のインタフェース）にも、それぞれローカルＩＰアドレスが割り当てられる場合がある。この場合、中継装置４０１の宅内から送信されるパケットの送信元ＩＰアドレスも、中継装置１１０１の家屋内から送信されるパケットの送信元ＩＰアドレスも、ＣＧＮ／ＬＳＮにより、同一のグローバルＩＰアドレスに変換されて、アクセス認可装置１５１に送信される。したがって、アクセス認可装置１５１では、ＩＰアドレスを元に状態判定を行う場合、通信装置１１０３が第３ネットワーク１１０２および第２ネットワーク６０１のどちらに接続されているかを区別できない。このためアクセス認可装置は、通信装置１１０３が、中継装置４０１の宅内に存在すると判断し、対象機器３０１のプライベートＡＰＩパス（またはプライベートAPI情報）を含む応答を、通信装置１１０３に送信する。なお、ここでは第３ネットワーク１１０２にはAPIアクセス可能な対象機器が存在しない場合を想定する。
When the
通信装置１１０３上のクライアントは、通知されたプライベートＡＰＩ情報を用いて対象機器３０１にアクセスしようとしても、対象機器３０１と同じ家屋（ローカルネットワーク）に存在しないため、対象機器３０１にアクセスできない。例えば、第１ネットワーク５０１内のルータからパケットを転送できない旨のエラーメッセージが返ってきたり、タイムアウトになったり、対象機器３０１のプライベートＡＰＩパスがドメイン名などを用いて表現されている場合にIPアドレスをDNSから取得できない、などのエラーが発生し得る。この問題を解決するため、以下の複数の方法が考えられる。本実施形態では、これらのいずれかの方法を実行する。
Even if the client on the
（第１の方法）通信装置１１０３上のクライアントは、エラー発生後、一定時間をおいて、アクセス認可装置に、状態判定の要求、またはトークン発行要求（図５のステップ１８）を行う。ＣＧＮ／ＬＳＮ機能を備えたネットワークでは、ＮＡＴの適用箇所が時間経過によって変わる場合がある。この場合、中継装置１１０１（ローカルIPアドレスしかもっていない）からのパケットはグローバルIPアドレス #1 からのパケットに変換され、中継装置４０１からのパケットはグローバルIP アドレス#2からのパケットに変換されることもある（ある時刻は両方ともグローバルＩＰアドレスは#1だった）。。これによりアクセス認可装置の対象機器情報記憶部１１８等が更新され、状態判定の結果も変わり得る。例えば、通信装置１１０３が、中継装置４０１の宅外に存在すると判断される。これにより通信装置１１０３は、アクセス認可装置により宅外に存在すると判断され、パブリックＡＰＩパス（またはパブリックAPI情報）が通信装置１１０３に送られる。通信装置１１０３は、パブリックＡＰＩ情報に基づき、アクセス認可装置１５１を介して対象機器３０１を操作する。
(First Method) The client on the
（第２の方法）通信装置１１０３は、アクセス認可装置１５１から通知されたプライベートＡＰＩ情報で、対象機器３０１にアクセスできない旨を伝えるフラグを立てたメッセージを、アクセス認可装置１５１に送信する。このフラグが立てられたメッセージを受信した場合、アクセス認可装置は、状態判定を省略する。この際、状態判定を省略したことのログをとってもよい。状態判定を省略した場合、アクセス認可装置１５１は、通信装置１１０３に対して、対象機器３０１に対するパブリックＡＰＩ情報を通知またはパブリックアクセス用のアクセストークンを発行するようにすればよい。
(Second Method) The
（第３の方法）通信装置１１０３は、プライベートＡＰＩ情報でのアクセスに失敗したときのエラー内容（応答パケットなど）を含むメッセージを、アクセス認可装置１５１に送信する。アクセス認可装置は、当該メッセージに含まれるエラー内容を、メモリ装置等の記憶装置に記録する。過去に報告されたエラー内容や、その他の情報と照合して、そのエラー内容が尤もらしいかどうかを判定する（公知の尤度判定を行えばよい）。尤度が一定値以上であれば、状態判定を省略し、上記と同様の処理を行えばよい。
(Third Method) The
尚、各実施形態のアクセス認可装置、通信装置および対象機器の各装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現可能である。すなわち、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現出来る。このとき、各装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現することや、各種の記憶媒体に記憶、あるいはネットワークを介して上記のプログラムを配布、このプログラムをコンピュータ装置に適宜インストールすることで実現が出来る。また、各装置内の各記憶部は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。 In addition, each apparatus of the access authorization apparatus of each embodiment, a communication apparatus, and object apparatus is realizable also by using a general purpose computer apparatus as basic hardware, for example. That is, it can be realized by causing a processor mounted on the computer apparatus to execute a program. At this time, each device can be realized by installing the above program in the computer device in advance, or can be stored in various storage media or distributed through the network, and the program can be installed in the computer device as appropriate. This can be realized. Each storage unit in each apparatus appropriately uses a memory, a hard disk or a storage medium such as a CD-R, a CD-RW, a DVD-RAM, a DVD-R, or the like incorporated in or externally attached to the computer apparatus. Can be realized.
本発明は上記実施形態そのままに限定されず、実施段階では要旨を逸脱しない範囲で構成要素を変形し具体化出来る。上記実施形態に開示されている複数の構成要素の適宜な組み合わせで、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除出来、異なる実施形態に渡る要素を適宜組み合わせることも出来る。 The present invention is not limited to the above-described embodiments as they are, and the constituent elements can be modified and embodied without departing from the spirit in the implementation stage. Various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the embodiment. For example, some constituent elements can be deleted from all the constituent elements shown in the embodiments, and elements over different embodiments can be appropriately combined.
１０１：アクセス認可装置
２０１：通信装置
３０１：対象機器
３０２：対象機器
４０１：中継装置
５０１：第１ネットワーク
６０１：第２ネットワーク
７０１：ゲートウェイ装置
８０１：第３ネットワーク
１１１：通信部
１１２：トークン発行部
１１３：認可対象決定部
１１４：状態判定部
１１５：トークン検証部
１１６：アクセス代行部
１１７：トークン記憶部
１１８：対象機器情報記憶部
１１９：認可対象提供部
１４１：アクセス制御部
１４２：対象機器登録部
１４３：ポリシー記憶部
101: Access authorization device 201: Communication device 301: Target device 302: Target device 401: Relay device 501: First network 601: Second network 701: Gateway device 801: Third network
111: Communication unit 112: Token issuance unit 113: Authorization target determination unit 114: State determination unit 115: Token verification unit 116: Access proxy unit 117: Token storage unit 118: Target device information storage unit 119: Authorization target provision unit 141: Access control unit 142: target device registration unit 143: policy storage unit
Claims (24)
前記通信装置と前記ネットワークとの接続状態を特定するための情報を前記通信装置および前記対象機器の少なくとも一方から取得し、前記情報に基づき前記接続状態を判定する状態判定部と、
前記対象機器が提供するリソースの利用要求を前記対象機器に送信するアクセス代行部と、
前記接続状態に基づき、前記対象機器が提供するリソースの利用要求を前記通信装置が前記対象機器に送信するか、前記アクセス代行部が前記対象機器に送信するかを決定する決定部と、
を備えるアクセス認可装置。 A communication unit that communicates with a target device connected to a network, and a communication device that can use resources provided by the target device;
A state determination unit that acquires information for specifying a connection state between the communication device and the network from at least one of the communication device and the target device, and determines the connection state based on the information;
An access proxy unit that transmits a request to use the resource provided by the target device to the target device;
A determination unit that determines whether the communication device transmits a request to use the resource provided by the target device to the target device based on the connection state, or whether the access proxy unit transmits to the target device;
An access authorization device comprising:
請求項１に記載のアクセス認可装置。 The access authorization device according to claim 1, wherein the state determination unit determines whether the communication device is connected to the network or is connectable to the network.
請求項２に記載のアクセス認可装置。 When the communication device is connected to the network or in a connectable state, the determination unit determines to transmit the use request from the communication device to the target device, and the use to the target device The access authorization apparatus according to claim 2, wherein instruction information for transmitting a request is transmitted to the communication apparatus.
前記アクセス代行部は、前記決定部の決定に応じて、前記利用要求を前記対象機器へ送信する
請求項３に記載のアクセス認可装置。 The determining unit, after transmitting the instruction information to the communication device, receives a report that an error has occurred with respect to the transmission of the use request from the communication device to the target device. Determined to transmit the usage request to the target device,
The access authorization device according to claim 3, wherein the access proxy unit transmits the use request to the target device according to the determination of the determination unit.
前記アクセス代行部は、前記決定部の決定に応じて、前記利用要求を前記対象機器へ送信する
請求項２または３に記載のアクセス認可装置。 The determining unit determines that the access proxy unit transmits the use request to the target device when the communication device is not connected to the network or is not connectable.
The access authorization device according to claim 2 or 3, wherein the access proxy unit transmits the use request to the target device according to the determination of the determination unit.
前記状態判定部は、前記第１要求が受信された場合に、前記接続状態の判定を行う
請求項１ないし５のいずれか一項に記載のアクセス認可装置。 The communication unit receives a first request transmitted from the communication device,
The access authorization device according to any one of claims 1 to 5, wherein the state determination unit determines the connection state when the first request is received.
請求項６に記載のアクセス認可装置。 The access authorization apparatus according to claim 6, wherein the first request is at least one of a permission request regarding use of the resource and a use request of the resource.
前記アクセス代行部は、前記通信装置からの前記第１ＡＰＩに関する情報に基づく前記リソースの利用要求を受けて、前記リソースの利用要求を前記対象機器に送信する
請求項７に記載のアクセス認可装置。 In response to the determination of the connection state based on the permission request, when the communication device determines that the communication device is not connected to the network or cannot be connected, the access proxy unit accepts the resource use request. A first authorization response including information related to a first API (Application Programming Interface) is transmitted to the communication device;
The access authorization device according to claim 7, wherein the access proxy unit receives the resource usage request based on the information related to the first API from the communication device, and transmits the resource usage request to the target device.
前記エラー応答を送信後、前記通信装置から前記リソースの利用に関する前記許可要求を受信し、前記許可要求に基づく前記接続状態の判定に応じて、前記通信装置が前記ネットワークに接続されている場合または接続可能な状態であると判定した場合に、前記利用要求を送信することの指示情報を含む第２許可応答を前記通信装置に送信する
請求項７に記載のアクセス認可装置。 In response to the determination of the connection state based on the resource usage request from the communication device, if it is determined that the communication device is connected to the network or is in a connectable state, an error response is transmitted to the communication device. To the device,
After transmitting the error response, receiving the permission request regarding the use of the resource from the communication device, and depending on the determination of the connection state based on the permission request, the communication device is connected to the network or The access authorization device according to claim 7, wherein when it is determined that the connection is possible, a second permission response including instruction information for transmitting the use request is transmitted to the communication device.
請求項９に記載のアクセス認可装置。 The access authorization apparatus according to claim 9, wherein the second permission response includes information related to a second API (Application Programming Interface) for the target device to accept a request to use the resource.
前記通信部は、前記対象機器の代わりに、前記ゲートウェイ装置と通信する
請求項１０に記載のアクセス認可装置。 The second API is an API for the gateway device to accept a request to use the resource to the target device.
The access authorization device according to claim 10, wherein the communication unit communicates with the gateway device instead of the target device.
前記ゲートウェイ装置は複数のネットワークに接続されており、前記ネットワークごとに、受け付け可能な前記第２ＡＰＩが異なる
請求項１１に記載のアクセス認可装置。 The second permission response includes information on a plurality of the second APIs,
The access authorization device according to claim 11, wherein the gateway device is connected to a plurality of networks, and the second API that can be accepted is different for each network.
前記第２ＡＰＩは、ゲートウェイ装置が前記対象機器への前記リソースの利用要求を受け付けるためのＡＰＩであり、
前記通信部は、前記対象機器の代わりに、前記ゲートウェイ装置と通信し、
前記ゲートウェイ装置は複数のネットワークに接続されており、前記ネットワークごとに、受け付け可能な前記第２ＡＰＩが異なる
請求項７に記載のアクセス認可装置。 In response to the determination of the connection state based on the resource usage request from the communication device, when it is determined that the communication device is connected to or connectable to the network, a plurality of second APIs Sending a response including information to the communication device;
The second API is an API for the gateway device to accept a request to use the resource to the target device.
The communication unit communicates with the gateway device instead of the target device,
The access authorization device according to claim 7, wherein the gateway device is connected to a plurality of networks, and the second API that can be accepted is different for each network.
請求項６ないし１３のいずれか一項に記載のアクセス認可装置。 In the state determination unit, the transmission source IP address of the first request received from the communication device matches an IP address registered in advance with respect to the target device, or is included in a range of IP addresses registered in advance. The access authorization device according to any one of claims 6 to 13, wherein the communication device determines whether the communication device is connected to the network.
請求項６ないし１３のいずれか一項に記載のアクセス認可装置。 The state determination unit receives information specifying a position where the communication device exists from the communication device, and based on the received information and location information acquired in advance of the target device, the communication device The access authorization device according to any one of claims 6 to 13, wherein it is determined whether or not the connection is possible.
請求項１ないし１５のいずれか一項に記載のアクセス認可装置。 When the state determination unit determines that the communication device is connected to or can be connected to the network, the state determination unit transmits instruction information for activating the function of accepting the resource use request to the target device. The access authorization device according to any one of claims 1 to 15.
請求項１ないし１６のいずれか一項に記載のアクセス認可装置。 When the state determination unit determines that the communication device is not connected to the network or is in a state where connection is not possible, instruction information for disabling the function of accepting the resource use request is included in the target The access authorization device according to any one of claims 1 to 16, wherein the access authorization device is transmitted to a device.
請求項１ないし１７のいずれか一項に記載のアクセス認可装置。 When the determination that the communication device is not connected to the network or in a state where the communication device is not connected is changed to the determination that the communication device is connected to or connected to the network, Based on the policy information given in advance, it is determined whether or not it is necessary to obtain a change permission from the user of the communication device, and if it is necessary to obtain a permission, information indicating the permission of the user is received. The access authorization device according to any one of claims 1 to 17, wherein later, instruction information for transmitting the resource use request to the target device is transmitted to the communication device.
請求項１ないし１３のいずれか一項に記載のアクセス認可装置。 In the case where the policy information given in advance indicates that the access proxy unit performs transmission of a resource use request when the communication device is connected to or connectable to the network, the communication device The access authorization device according to any one of claims 1 to 13, wherein the access proxy unit transmits a request to use the resource to the target device even when connected to a network or connectable.
請求項１ないし１９のいずれか一項に記載のアクセス認可装置。 The communication unit disconnects a communication connection with the target device when it is determined that the communication device is connected to or connected to the network. The access authorization device described.
を備えたアクセス認可方法。 Information for identifying a connection state between a communication device that can use a resource provided by a target device connected to a network and the network is acquired from at least one of the communication device and the target device, and based on the information, A state determination step for determining a connection state; and a determination for determining whether the communication device transmits a request for using a resource provided by the target device to the target device or an access proxy unit based on the connection state Steps,
An access authorization method comprising:
をコンピュータに実行させるためのプログラム。 Information for identifying a connection state between a communication device that can use a resource provided by a target device connected to a network and the network is acquired from at least one of the communication device and the target device, and based on the information, A state determination step for determining a connection state; and a determination for determining whether the communication device transmits a request for using a resource provided by the target device to the target device or an access proxy unit based on the connection state Steps,
A program that causes a computer to execute.
前記対象機器および前記通信装置の少なくとも一方と
を備えた通信システム。 The access authorization device according to any one of claims 1 to 20,
A communication system comprising: at least one of the target device and the communication device.
請求項２３に記載の通信システム。 The communication system according to claim 23, comprising both the target device and the communication device.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US15/069,333 US20160277413A1 (en) | 2015-03-20 | 2016-03-14 | Access Permission Device, Access Permission Method, Program, and Communicating System |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2015058684 | 2015-03-20 | ||
| JP2015058684 | 2015-03-20 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2016177795A true JP2016177795A (en) | 2016-10-06 |
Family
ID=57070736
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2016046197A Abandoned JP2016177795A (en) | 2015-03-20 | 2016-03-09 | Access authorization apparatus, access authorization method, program and communication system |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2016177795A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018164236A1 (en) * | 2017-03-10 | 2018-09-13 | シャープ株式会社 | Internet server, terminal, communication system, control method for internet server, and control program |
| JP2020080482A (en) * | 2018-11-13 | 2020-05-28 | シャープ株式会社 | Network system, information processing method, communication terminal, and program |
| US11336449B2 (en) | 2018-09-13 | 2022-05-17 | Kabushiki Kaisha Toshiba | Information processing apparatus, computer program product, and resource providing method |
-
2016
- 2016-03-09 JP JP2016046197A patent/JP2016177795A/en not_active Abandoned
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018164236A1 (en) * | 2017-03-10 | 2018-09-13 | シャープ株式会社 | Internet server, terminal, communication system, control method for internet server, and control program |
| US11336449B2 (en) | 2018-09-13 | 2022-05-17 | Kabushiki Kaisha Toshiba | Information processing apparatus, computer program product, and resource providing method |
| JP2020080482A (en) * | 2018-11-13 | 2020-05-28 | シャープ株式会社 | Network system, information processing method, communication terminal, and program |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20160277413A1 (en) | Access Permission Device, Access Permission Method, Program, and Communicating System | |
| JP6668183B2 (en) | Communication device, communication method, communication system and program | |
| KR102318279B1 (en) | Method and apparatus for transmitting and receiving authentication information in a wireless communication system | |
| KR102362456B1 (en) | Authority transfer system, control method therefor, and storage medium | |
| JP6494149B2 (en) | Authorization processing method and device | |
| EP3073699B1 (en) | System and method for controlling mutual access of smart devices | |
| CN110138718B (en) | Information processing system and control method thereof | |
| JP6929181B2 (en) | Devices and their control methods and programs | |
| US10623191B2 (en) | Information processing apparatus, information processing system, information processing method, and recording medium | |
| US9413762B2 (en) | Asynchronous user permission model for applications | |
| JP6061633B2 (en) | Device apparatus, control method, and program thereof. | |
| WO2018177143A1 (en) | Identity authentication method and system, server and terminal | |
| US9549318B2 (en) | System and method for delayed device registration on a network | |
| US10523763B2 (en) | Communication device, communication method, controlled device, and non-transitory computer readable medium | |
| WO2020176356A1 (en) | Server-based setup for connecting a device to a local area network | |
| US20160134432A1 (en) | Method for setting up a local control channel between a control unit and a building-internal access portal | |
| KR20130001655A (en) | Apparatus and method for providing service to different service terminal | |
| US8769623B2 (en) | Grouping multiple network addresses of a subscriber into a single communication session | |
| JP2016177795A (en) | Access authorization apparatus, access authorization method, program and communication system | |
| US11368994B1 (en) | Process for managing reconnections of devices in a network | |
| US10511671B2 (en) | Communication device, communication method, controlled device, and non-transitory computer readable medium | |
| JP6056970B2 (en) | Information processing apparatus, terminal, information processing system, and information processing method | |
| US20230107045A1 (en) | Method and system for self-onboarding of iot devices | |
| KR101117316B1 (en) | Remote access service profile setting method and user authentication method for remote accessing UPNP devices | |
| JP2020053100A (en) | Information processing system, control method thereof and program |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20180222 |
|
| A762 | Written abandonment of application |
Free format text: JAPANESE INTERMEDIATE CODE: A762 Effective date: 20181129 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20181206 |