JP7234849B2 - 情報処理装置、アクセス制御システム及びアクセス制御プログラム - Google Patents

Description

本発明は、情報処理装置、アクセス制御システム及びアクセス制御プログラムに関する。

ＩｏＴ（Internet of Things）と呼ばれるムーブメントが起こり、様々なデバイスがネットワークに接続されてリモートで制御である。また、シェアードエコノミーと呼ばれるムーブメントもあり、或る個人が所有するものを不特定多数に貸し出すというサービス（例えば、シェアードカーや民泊）が普及している。ＩｏＴ機器をシェアして利用するには、その時々で利用権限を有さない人には利用が制限されるようにアクセス制御が行われる必要がある。

国際公開２００６／０４０９９１号 特開２００４－３２２２０号公報 特開２００７－４５７９号公報

そこで、ＩｏＴ機器の制御に関するサービスの提供者が提供する、ＩｏＴ機器の制御用のＡＰＩ（Application Programming Interface）についてアクセス制御を行うことが考えられる。この方法は、例えば、民泊として貸し出す家の鍵としてのＩｏＴ機器の解錠又は施錠や、電球としてのＩｏＴ機器の点灯又は消灯のように、制御の粒度が大きい（制御の種類が少ない）場合には有効であると考えられる。

一方、例えば、電球について、色の調整（ＲＧＢの各値の変更）の制御を可能としたい場合のようにＩｏＴ機器について複数種類の制御（細粒度な制御）を可能としたい場合も考えられる。斯かる制御の具体例として、電球の色について、ＲＧＢのいずれかの値を＋Ｎ、－Ｎ（Ｎは、１～２５５）したり、ＲＧＢのいずれかの値に０～２５５のいずれかを設定することが挙げられる。

このような場合において、制御の粒度に合わせて細粒度なアクセス制御（例えば、或るユーザにはＲとＧについて値の変更を可能とし、他のユーザについては、Ｂについて値の変更を可能とするアクセス制御等）を行おうとすると、アクセス制御の管理機構が複雑になってしまう。

そこで、一側面では、本発明は、ネットワークを介して制御可能な機器についてアクセス制御の粒度を細かくすることを目的とする。

一つの態様では、ネットワークを介して接続される機器の制御に関するＡＰＩ群を提供する情報処理装置は、前記ＡＰＩ群のうちのいずれかのＡＰＩに関するデータを端末から受信する受信部と、前記データに含まれている、前記情報処理装置が実行する処理を示す第１のコードを実行して、前記ＡＰＩ群のうち前記第１のコードに指定されているＡＰＩを前記端末から呼び出し可能な状態にするコード実行部と、前記端末から送信される前記第１のコードに指定されているＡＰＩの呼び出し要求に応じ、当該ＡＰＩに応じた制御を前記機器に対して実行する制御部と、を有する。

一側面として、ネットワークを介して制御可能な機器についてアクセス制御の粒度を細かくすることができる。

第１の実施の形態におけるアクセス制御システムの構成例を示す図である。 第１の実施の形態におけるサーバ装置１０のハードウェア構成例を示す図である。 第１の実施の形態におけるユーザ端末２０のハードウェア構成例を示す図である。 第１の実施の形態におけるサーバ装置１０及びユーザ端末２０の機能構成例を示す図である。 第１の実施の形態におけるアクセス制御システムにおいて実行される処理手順の一例を説明するための図である。 チケットの構成例を示す図である。 サーバコードの一例を示す図である。 クライアントコードの一例を示す図である。 第２の実施の形態におけるアクセス制御システムにおいて実行される処理手順の一例を説明するための図である。 ＡＰＩ情報の一例を示す図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、第１の実施の形態におけるアクセス制御システムの構成例を示す図である。図１において、アクセス制御システム１は、サーバ装置１０、１以上のユーザ端末２０、及び１以上の機器３０を含む。サーバ装置１０と各ユーザ端末２０とはネットワークＮ１を介して接続される。サーバ装置１０と各機器３０とはネットワークＮ２を介して接続される。ネットワークＮ１及びネットワークＮ２は、例えば、インターネット、ＬＡＮ（Local Area Network）、又は近距離無線通信等である。ネットワークＮ１及びネットワークＮ２は、共通のネットワークであってもよい。

サーバ装置１０は、ユーザ端末２０による機器３０へのアクセスを仲介する１以上のコンピュータである。具体的には、サーバ装置１０は、各機器３０を制御するためのＷｅｂＡＰＩ（以下、単に「ＡＰＩ」という。）をネットワークＮ１上に公開する。但し、各ＡＰＩは、常にアクセス可能ではなく、サーバ装置１０がユーザ端末２０からチケットを受信した際に、当該チケットにおいてアクセス対象とされているＡＰＩがオープンされ、アクセス可能となる。サーバ装置１０は、チケットに基づいてオープンされたいずれかのＡＰＩがアクセスされると、当該チケットに対応する機器３０について当該ＡＰＩに応じた制御を実行する。なお、チケットとは、サーバ装置１０がネットワークを介して公開可能なＡＰＩ群（機器３０の制御用のＡＰＩ群）のうち、ユーザ端末２０（ユーザ）がアクセス可能（呼び出し可能）なＡＰＩを制限するためのデータである。チケットの構成の詳細については後述される。

ユーザ端末２０は、いずれかの機器３０を遠隔操作するユーザが利用する端末である。例えば、ＰＣ（Personal Computer）、スマートフォン、タブレット端末等がユーザ端末２０の一例として挙げられる。ユーザ端末２０は、機器３０を遠隔操作するためのチケットを入手し、当該チケットをサーバ装置１０へ送信することで、当該機器３０に対する所望の制御をサーバ装置１０に実行させる。なお、チケットを生成するのは、サーバ装置１０であるが、ユーザ端末２０がサーバ装置１０からチケットを入手するとは限らない。例えば、ユーザは、チケットのブローカーを通じてチケットを入手し、当該チケットをユーザ端末２０にインストール（保存）してもよい。一例として、民泊として借りた部屋の鍵としての機器３０をチケットで制御することを考えると、家の持ち主と借り主をつなぐ仲介業者が運営するコンピュータを通じてチケットが入手されてもよい。この際、当該仲介業者とユーザとの間の契約等に応じて、当該チケットを用いてアクセス可能（呼び出し可能）なＡＰＩ群等が決定され、サーバ装置１０は、当該ＡＰＩ群にアクセス可能な（当該ＡＰＩ群を呼び出し可能な）チケットを生成する。又は、チケットの流通が許容される場合、或るユーザから他のユーザに対してチケットが譲渡されてもよい。例えば、特開２０１９－１１３９８１号公報に開示された方法と同様の方法でチケットが入手されてもよい。

機器３０は、ネットワークＮ２を介して制御可能な機器である。ＩｏＴ機器が機器３０として利用されてもよい。本実施の形態では、色（ＲＧＢ）の調整の制御をネットワークを介して可能な電球を機器３０の一例として説明するが、家電製品、自動車やその他の通信機器等が機器３０として利用されてもよい。

図２は、第１の実施の形態におけるサーバ装置１０のハードウェア構成例を示す図である。図２のサーバ装置１０は、それぞれバスで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

サーバ装置１０での処理を実現するプログラムは、記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってサーバ装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

なお、記録媒体１０１の一例としては、ＣＤ－ＲＯＭ、ＤＶＤディスク、又はＵＳＢメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置１０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体１０１及び補助記憶装置１０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。

図３は、本発明の実施の形態におけるユーザ端末２０のハードウェア構成例を示す図である。図３のユーザ端末２０は、それぞれバスＢで相互に接続されているドライブ装置２００、補助記憶装置２０２、メモリ装置２０３、ＣＰＵ２０４、インタフェース装置２０５、表示装置２０６、及び入力装置２０７等を有する。

ユーザ端末２０での処理を実現するプログラムは、記録媒体２０１によって提供される。プログラムを記録した記録媒体２０１がドライブ装置２００にセットされると、プログラムが記録媒体２０１からドライブ装置２００を介して補助記憶装置２０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体２０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置２０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置２０３は、プログラムの起動指示があった場合に、補助記憶装置２０２からプログラムを読み出して格納する。ＣＰＵ２０４は、メモリ装置２０３に格納されたプログラムに従ってユーザ端末２０に係る機能を実現する。インタフェース装置２０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置２０６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置２０７はキーボード、マウス、ボタン、又はタッチパネル等であり、様々な操作指示を入力させるために用いられる。

なお、記録媒体２０１の一例としては、ＣＤ－ＲＯＭ、ＤＶＤディスク、ＵＳＢメモリ、又はＳＤカード等の可搬型の記録媒体が挙げられる。また、補助記憶装置２０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体２０１及び補助記憶装置２０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。

図４は、第１の実施の形態におけるサーバ装置１０及びユーザ端末２０の機能構成例を示す図である。図４において、ユーザ端末２０は、チケット送信部２１、クライアントコード実行部２２及びＡＰＩ呼出部２３等を有する。これら各部は、ユーザ端末２０にインストールされたアプリケーションプログラムが、ＣＰＵ２０４に実行させる処理により実現される。当該アプリケーションプログラムは、例えば、サーバ装置１０が提供するサービスに対応するアプリケーションプログラムである。例えば、ＨＴＭＬ及びＪａｖａＳｃｒｉｐｔ（登録商標）が当該アプリケーションプログラムを構成してもよい。ユーザ端末２０は、また、チケット記憶部２４を有する。チケット記憶部２４は、例えば、補助記憶装置２０２等を用いて実現可能である。

チケット送信部２１は、例えば、ユーザによる操作等に応じたタイミングで、チケット記憶部２４に記憶されているチケットをサーバ装置１０へ送信する。チケット記憶部２４には、ユーザが予め入手したチケットが記憶されている。本実施の形態では、便宜上、チケット記憶部２４には１つのチケットが記憶されていることとする。但し、複数のチケットがチケット記憶部２４に記憶されていてもよい。この場合、送信対象とされるチケットは、ユーザによる操作等に応じて選択されてもよい。

クライアントコード実行部２２は、チケットに含まれている情報のうち、ユーザ端末２０に実行させるプログラミングコード（以下、「クライアントコード」という。）を含む部分（以下、「クライアント部」という。）を解釈し、当該クライアントコードに応じた処理を実行する。クライアント部には、当該チケットによってアクセスが許可されるＡＰＩが指定されたクラアイントコードが含まれる。

ＡＰＩ呼出部２３は、クライアントコード実行部２２によるクライアントコードに応じた処理の実行の結果として呼び出し対象とされる、当該チケットにおいてアクセスが許可されるＡＰＩの呼び出しを行う。

一方、サーバ装置１０は、チケット受信部１１、サーバコード実行部１２及び機器制御部１３等を有する。これら各部は、サーバ装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

チケット受信部１１は、ユーザ端末２０から送信されたチケットを受信する。

サーバコード実行部１２は、チケット受信部１１が受信したチケットに含まれている情報のうち、サーバ装置１０に実行させるプログラミングコード（以下、「サーバコード」という。）を含む部分（以下、「サーバ部」という。）を解釈し、当該サーバコードに応じた処理を実行する。サーバ部には、当該チケットによってアクセスが許可されるＡＰＩのオープンや、当該ＡＰＩの呼び出しに応じた処理に関する定義が含まれる。ＡＰＩのオープンとは、ＡＰＩを有効化することをいう。ＡＰＩの有効化とは、ＡＰＩをアクセス可能（呼び出し可能）な状態にすることをいう。例えば、ＡＰＩに対応するソケットのオープンや、ＡＰＩに対応するスレッドの起動等によってＡＰＩの有効化が実現されてもよい。

機器制御部１３は、サーバコード実行部１２によるサーバコードに応じた処理の実行の結果として呼び出される、機器３０の制御用の関数（ＡＰＩ）の呼び出しに応じ、呼び出された関数に対応する制御を機器３０に対して実行する。

以下、アクセス制御システム１において実行される処理手順について説明する。図５は、第１の実施の形態におけるアクセス制御システムにおいて実行される処理手順の一例を説明するための図である。

ステップＳ１１０において、ユーザ端末２０のチケット送信部２１は、例えば、ユーザによる操作に応じ、チケット記憶部２４に記憶されているチケットを、当該チケットに記述されている送信先に送信する。当該チケットの送信は、Ｗｅｂサービスで通常利用されるＨＴＴＰＳを使用して安全に実行される。

図６は、チケットの構成例を示す図である。図６に示されるチケットは、ＪＳＯＮ（JavaScript（登録商標） Object Notation）形式によって記述されている。図６において、チケットは、ｈｅａｄｅｒキー（ｋｅｙ）の値（ｖａｌｕｅ）であるヘッダ部ｈ１と、ｐａｙｌｏａｄキー（ｋｅｙ）の値（ｖａｌｕｅ）であるペイロード部ｐ１とを含む。

ヘッダ部ｈ１は、ｕｒｌキー及びその値と、ｍｅｔａｄａｔａキー及びその値とを含む。ｕｒｌキーの値である「http://service1.fff.com/service1」は、当該チケットの送信先のＵＲＬ（Uniform Resource Locator）である。

ｍｅｔａｄａｔａキーの値は、当該チケットの有効期限（ｂｅｇｉｎｄａｔｅ、ｅｎｄｄａｔｅ）や当該チケットに関する説明（"ｄｅｓｃｒｉｐｔｉｏｎ"："ＬＥＤ ｃｏｎｔｒｏｌｌｅｒ"）等を含む。ｍｅｔａｄａｔａキーの値（特に、ｄｅｓｃｒｉｐｔｉｏｎキーの値）は、表示用の情報である。

ペイロード部ｐ１は、ｓｅｒｖｅｒキーの値であるサーバ部ｐ１ｓと、ｃｌｉｅｎｔキーの値であるクライアント部ｐ１ｃとを含む。サーバ部ｐ１ｓ及びクライアント部ｐ１ｃは、ｂａｓｅ６４でエンコードされている。但し、サーバ部ｐ１ｓは、エンコードの前にサーバ装置１０に記憶されている暗号鍵（以下、「サーバ鍵」という。）によって暗号化されている。そうすることで、サーバ装置１０が実行する処理が不正に書き換えられることを防止することができる。

本実施の形態において、チケットのヘッダ部ｈ１のｕｒｌキーの値として記述されるＵＲＬは、サーバ装置１０に対応する。したがって、ステップＳ１１０において送信されたチケット（以下、「対象チケット」という。）は、サーバ装置１０のチケット受信部１１によって受信される（Ｓ１２０）。

続いて、サーバ装置１０のサーバコード実行部１２は、対象チケットのペイロード部ｐ１のサーバ部ｐ１ｓをデコードしてサーバ鍵で復号することにより、サーバコードを得る（Ｓ１３０）。

図７は、サーバコードの一例を示す図である。図７には、ＷｏＴ（Web of Things）で規定されているＳｃｒｉｐｔｉｎｇ ＡＰＩ（https://w3c.github.io/wot-scripting-api/）を利用したプログラムとしてサーバコードが記述された例が示されている。Ｓｃｒｉｐｔｉｎｇ ＡＰＩは、Ｗ３ＣのＷｏＴ ＷＧが検討している、機器３０を制御するためのＡＰＩを生成したり、生成したＡＰＩにアクセスしたりするプログラムを簡単に記述することを可能にするＡＰＩを定義するものである。

続いて、サーバコード実行部１２は、復号されたサーバコードに従った処理を実行する（Ｓ１４０）。このタイミングでは、サーバコード実行部１２は、記述ｄ１２及び記述ｄ１４のそれぞれのａｄｄＰｒｏｐｅｒｔｙを呼び出すことで、２つのＡＰＩのオープンを実行する（Ｓ１５０）。具体的には、記述ｄ１２に含まれている"ｌｅｄＲｅｄ"に対応するＡＰＩと、記述ｄ１４に含まれている"ｌｅｄＧｒｅｅｎ" に対応するＡＰＩとがオープンされる。ここでオープンされたＡＰＩが、対象チケットの送信元のユーザ端末２０に対してアクセスが許可されるＡＰＩである。

続いて、サーバコード実行部１２は、オープンした各ＡＰＩに対してそれぞれのＵＲＬを対応付けて、各ＡＰＩの呼び出しを待機する（Ｓ１６０）。例えば、サーバコード実行部１２は、サーバ装置１０のＵＲＬ（http://service1.fff.com/service1）に対して、記述ｄ１１に含まれているＬＥＤ電球の識別情報である"ＬＥＤ１２３４５６７８"及び"ｌｅｄＲｅｄ"を含むパス名を付加したＵＲＬである「http://service1.fff.com/service1/LED12345678/ledRed」を、"ｌｅｄＲｅｄ"に対応するＡＰＩに対応付ける。また、サーバコード実行部１２は、サーバ装置１０のＵＲＬ（http://service1.fff.com/service1）に対して、記述ｄ１１に含まれているＬＥＤ電球の識別情報である"ＬＥＤ１２３４５６７８"及び"ｌｅｄＧｒｅｅｎ"を含むパス名を付加したＵＲＬである「http://service1.fff.com/service1/LED12345678/ledRed」を、"ｌｅｄＧｒｅｅｎ"に対応するＡＰＩに対応付ける。なお、
続いて、サーバコード実行部１２は、対象チケットに対する応答を対象チケットの送信元のユーザ端末２０へ送信する（Ｓ１７０）。

ユーザ端末２０のチケット送信部２１が当該応答を受信すると（Ｓ１８０）、クライアントコード実行部２２は、対象チケットのクライアント部ｐ１ｃをデコードすることで得られるクライアントコードに従った処理を実行する（Ｓ１９０）。

図８は、クライアントコードの一例を示す図である。図８では、ＨＴＭＬの中にＪａｖａＳｃｒｉｐｔが記述される形式でクライアントコードが実装されている。但し、クライアントコード実行部２２が解釈可能な形式であれば、クライアントコードの形式は所定のものに限定されない。

記述ｄ２１では、ｔｄ変数によりサーバ装置１０で用意するＡＰＩの名前（ｌｅｄＲｅｄ、ｌｅｄＧｒｅｅｎ）と、当該ＡＰＩにアクセスするためのＵＲＬ（http://service1.fff.com/service1/LED12345678/ledRed、http://service1.fff.com/service1/LED12345678/ledGreen）との対応付けが記述されている。当該各ＵＲＬは、サーバ装置１０のサーバコード実行部１２が各ＡＰＩに対して動的に対応付けるＵＲＬに一致する。換言すれば、サーバコード実行部１２は、クライアントコードに記述されている各ＵＲＬに一致するように、オープン対象の各ＡＰＩに対するＵＲＬを生成する。ＵＲＬが動的に生成されることで、ＡＰＩに対するＵＲＬの推測を困難にすることができ、ＡＰＩに対する不正アクセスの可能性を低下させることができる。なお、名前が「ｌｅｄＲｅｄ」であるＡＰＩを、以下「ＲｅｄＡＰＩ」といい、名前が「ｌｅｄＧｒｅｅｎ」であるＡＰＩを、以下「ＧｒｅｅｎＡＰＩ」という。

記述ｄ２２には、ｉｎｖｏｋｅＡｃｔｉｏｎにより、クライアントコードとしてのＨＴＭＬによってユーザ端末２０に表示される画面（以下、「アプリ画面」という。）の赤色に対応するテキストボックス（ｒｅｄＴｅｘｔ）に入力された値（０～２５５）を指定して、ｌｅｄＲｅｄの名前に対応するＲｅｄＡＰＩ（すなわち、「http://service1.fff.com/service1/LED12345678/ledRed」）を呼び出す定義が記述されている。

記述ｄ２３には、ｉｎｖｏｋｅＡｃｔｉｏｎにより、アプリ画面の緑色に対応するテキストボックス（ｇｒｅｅｎＴｅｘｔ）に入力された値（０～２５５）を指定して、ｌｅｄＧｒｅｅｎの名前に対応するＧｒｅｅｎＡＰＩ（すなわち、「http://service1.fff.com/service1/LED12345678/ledGreen」）を呼び出す定義が記述されている。

記述ｄ２１、記述ｄ２２及び記述ｄ２３等は、サーバコードと同様に、ＷｏＴのＳｃｒｉｐｔｉｎｇ ＡＰＩに基づいて記述されている。

ステップＳ１９０では、記述ｄ２１と、記述ｄ２２又は記述ｄ２３と等に応じた処理が実行される。その結果、ＡＰＩ呼出部２３が、記述ｄ２２又は記述ｄ２３に応じたＡＰＩの呼び出しを実行する（Ｓ２００）。具体的には、ＡＰＩ呼出部２３は、当該ＡＰＩに対応するＵＲＬ宛てにリクエストを送信する。なお、当該リクエストには、アプリ画面のテキストボックスに入力された値（０～２５５）も含まれる。

サーバ装置１０のサーバコード実行部１２は、当該リクエストを受信すると（Ｓ２１０）、サーバコード実行部１２は、サーバコードにおいて当該リクエストに係るＵＲＬに対応するＡＰＩの定義に従った処理を実行する（Ｓ２２０）。例えば、当該ＵＲＬが、「http://service1.fff.com/service1/LED12345678/ledRed」であれば、サーバコード実行部１２は、サーバコード（図７）の記述ｄ１３の「LED.changeRed(value);」を呼び出す。一方、当該ＵＲＬが「http://service1.fff.com/service1/LED12345678/ledGreen」であれば、サーバコード実行部１２は、サーバコード（図７）の記述ｄ１５の「LED.changeGreen(value);」を呼び出す。これらの呼び出しは、機器制御部１３が提供する関数の呼び出しに相当する。すなわち、当該関数の呼び出しは、機器制御部１３に対する機器３０の制御要求に相当する。なお、リクエストに係るＵＲＬに対応するＡＰＩの定義に従った処理を実行は、記述ｄ１２又は記述ｄ１３におけるｓｅｔＰｒｏｐｅｒｔｙＷｒｉｔｅＨａｎｄｌｅｒによる、関数の呼び出し設定に基づいて実現される。また、記述ｄ１３の「LED.changeRed(value);」又は記述ｄ１５の「LED.changeGreen(value);」のvalueには、受信されたリクエストに含まれている値（０～２５５）が代入される。

当該関数の呼び出しに応じ、機器制御部１３は、機器３０に対して当該関数に応じた制御命令を送信する（Ｓ２３０）。例えば、Ｒの値を２５５にすることを示す命令等が送信される。機器３０は、当該制御命令を受信すると、当該制御命令に応じた動作を実行する（Ｓ２４０）。なお、図５では省略されているが、必要に応じて、機器３０による動作結果を示す情報を含む応答がサーバコード実行部１２からユーザ端末２０へ送信されてもよい。

ステップＳ２００～Ｓ２４０は、例えば、ユーザによるアプリ画面の操作に応じて繰り返される。その後、ＡＰＩのクローズ要求が発生すると（Ｓ２５０でＹｅｓ）、サーバコード実行部１２は、ステップＳ１５０においてオープンした全てのＡＰＩをクローズする（Ｓ２６０）。ＡＰＩのクローズとは、ＡＰＩを無効化することをいう。ＡＰＩの無効化とは、ＡＰＩをアクセスできない状態にすることをいう。例えば、ＡＰＩに対応するソケットのクローズや、ＡＰＩに対応するスレッドの停止等によってＡＰＩの無効化が実現されてもよい。

なお、本実施の形態では、サーバコード（図７）の記述ｄ１６におけるｓｅｔＴｉｍｅｏｕｔ関数において、ＡＰＩのオープンから１００００ミリ秒後にｔｈｉｎｇ．ｓｔｏｐ（）を呼び出して、ｐｒｏｃｅｓｓ．ｅｘｉｔ（１）を呼び出すことが定義されている。当該定義は、ＡＰＩをオープンしてから１００００ミリ秒後に当該ＡＰＩをクローズされることを示す。

したがって、サーバコード実行部１２は、ステップＳ１５０から１００００ミリ秒経過後にステップＳ１６０を実行して、ステップＳ１５０においてオープンした全てのＡＰＩをクローズする。その結果、以降においてユーザ端末２０からＡＰＩが呼び出されたとしても、当該ＡＰＩの呼び出しに関するリクエストはサーバコード実行部１２によって受信されなくなる。すなわち、当該ＡＰＩへのアクセスが不可能になる。

なお、本実施の形態では、ＡＰＩのオープンからの経過時間によって当該ＡＰＩのクローズのタイミングが規定される例を示したが、ユーザ端末２０からＡＰＩのクローズの要求を可能としてもよい。この場合、ＡＰＩのクローズを示すＡＰＩ（以下、「クローズＡＰＩ」という。）へのユーザ端末２０によるアクセスが可能となるようにチケットのペイロード部ｐ１が定義されればよい。具体的には、ペイロード部ｐ１のクライアント部ｐ１ｃのクライアントコードには、ユーザによるアプリ画面に対する何らかの操作に応じてクローズＡＰＩを呼び出す処理の定義が記述されればよい。一方、ペイロード部ｐ１のサーバ部ｐ１ｓのサーバコードには、クローズＡＰＩの呼び出しに応じて、ＡＰＩをクローズする処理の定義が記述されればよい。

上述したように、第１の実施の形態によれば、チケットのペイロード部ｐ１に、機器３０の制御用のＡＰＩを一時的にオープンするためのコードが記述され、当該コードの実行に応じてＡＰＩがオープンされる。ＡＰＩのオープンによって、ユーザ端末２０から当該ＡＰＩを通じて機器３０を制御することが可能となる。すなわち、ユーザ端末２０がアクセスできるＡＰＩは、チケットに定義されたコードにおいて指定されたＡＰＩに制限される。したがって、細粒度なアクセス制御を行いたい場合には、サーバ装置１０において特別な管理機構を設けずとも、所望の粒度に応じたアクセスを可能とするチケットを定義すればよい。よって、本実施の形態によれば、ネットワークを介して制御可能な機器についてアクセス制御の粒度を細かくすることができる。

また、サーバ装置１０は、チケットの受信に応じて当該チケットにおいて指定されている（オープンが要求されている）ＡＰＩをオープンし、所定期間経過後に当該ＡＰＩをクローズする。したがって、各ＡＰＩにアクセス可能な期間が限定されるため、ＡＰＩに対する不正アクセスの可能性を低下させることができる。

なお、上記では、ＡＰＩがＷｅｂＡＰＩである例について示したが、Ｂｌｕｅｔｏｏｔｈ（登録商標）やＩＣカードリーダとの通信方法を用いた通信におけるＡＰＩについて本実施の形態が適用されてもよい。この場合、Ｂｌｕｅｔｏｏｔｈ（登録商標）アドレスや、ＩＣカードのＩＤ等によって各ＡＰＩが区別されてもよい。この場合、例えば、機器３０に対してユーザ端末２０をタッチすることで、機器３０を制御可能とすることができる。

なお、本実施の形態ではチケットの受信に応じて当該チケットにおいて指定されたＡＰＩがオープンされる例を示したが、例えば、制御対象の機器３０に関する利用料金の支払いやユーザ認証等、他の要件が更に満たされた場合に、ＡＰＩのオープンが実行されるようにしてもよい。

次に、第２の実施の形態について説明する。第２の実施の形態では第１の実施の形態と異なる点について説明する。第２の実施の形態において、特に言及されない点については、第１の実施の形態と同様でもよい。

図９は、第２の実施の形態におけるアクセス制御システムにおいて実行される処理手順の一例を説明するための図である。図９中、図５と同一ステップには同一ステップ番号を付し、その説明は省略する。

第２の実施の形態において、サーバコード実行部１２は、ステップＳ１５０に続いてステップＳ１５１を実行する。ステップＳ１５１において、サーバコード実行部１２は、第２の実施の形態においてクライアント部ｐ１ｃのクライアントコードの代わりとなるＡＰＩ情報を、対象チケットのヘッダ部ｈ１及びサーバ部ｐ１ｓ等に基づいて生成する。なお、第２の実施の形態において、対象チケットのペイロード部ｐ１には、クライアント部ｐ１ｃは含まれていなくてよい。一方、サーバ部ｐ１ｓは、第１の実施の形態と同様のものが対象チケットのペイロード部ｐ１に含まれているとする。

図１０は、ＡＰＩ情報の一例を示す図である。ＡＰＩ情報には、ユーザ端末２０からアクセス可能（呼び出し可能）な（ユーザ端末２０に対してアクセスが許可される）ＡＰＩごとに、当該ＡＰＩを呼び出すために必要な情報（以下「ＡＰＩ呼び出し情報」という。）が含まれている。各ＡＰＩ呼び出し情報では、当該ＡＰＩの機能の名称と当該ＡＰＩに対応するＵＲＬが対応付けられている。

図１０において、記述ｄ３１は、ＲｅｄＡＰＩのＡＰＩ呼び出し情報（以下、「ＲｅｄＡＰＩ呼び出し情報」という。）である。すなわち、記述ｄ３１には、Ｒ（ｌｅｄＲｅｄ）の値を変更したいのであれば、「http://service1.fff.com/service1/LED12345678/ledRed」にアクセスすべきことが定義されている。また、ＧｒｅｅｎＡＰＩのＡＰＩ呼び出し情報（以下、「ＧｒｅｅｎＡＰＩ呼び出し情報」という。）である。すなわち、記述ｄ３２には、Ｇ（ｌｅｄＧｒｅｅｎ）の値を変更したいのであれば、「http://service1.fff.com/service1/LED12345678/ledGreen」にアクセスすべきことが定義されている。

ＲｅｄＡＰＩ情報は、対象チケットのヘッダ部ｈ１（図６）と、対象チケットのサーバ部ｐ１ｓ（図７）の記述ｄ１１及びｄ１２等に基づいて生成可能である。ＧｒｅｅｎＡＰＩ情報は、対象チケットのヘッダ部ｈ１（図６）と、対象チケットのサーバ部ｐ１ｓ（図７）の記述ｄ１１及びｄ１４等に基づいて生成可能である。

なお、図１０のＡＰＩ情報に含まれる各ＡＰＩ呼び出し情報は、ＷｏＴで規定されているＴｈｉｎｇ Ｄｅｓｃｒｉｐｔｉｏｎの形式を流用して記述されているため、ＷｏＴに準拠したユーザ端末２０にとって親和性が高い。但し、ＡＰＩごとにアクセスする先が明確に指定された情報であれば、ＡＰＩ呼び出し情報は、他の形式によって記述されてもよい。

ユーザ端末２０のチケット送信部２１が当該ＡＰＩ情報を受信すると（Ｓ１８０ａ）、ＡＰＩ呼出部２３が当該ＡＰＩ情報を解釈する。ＡＰＩ呼出部２３は、当該ＡＰＩ情報に含まれるＡＰＩ呼び出し情報に基づいて、ユーザ端末２０がアクセス可能ないずれかのＡＰＩに対応するＵＲＬ宛てにリクエストを送信する（Ｓ２００）。なお、呼び出し対象とするＡＰＩは、アプリ画面等のユーザインタフェースにおいてユーザによって選択可能とされてもよい。

以降は、第１の実施の形態と同様である。

上述したように、第２の実施の形態によれば、チケットのペイロード部ｐ１においてクライアント部ｐ１ｃの記述は不要とされる。したがって、チケットの作成に関する作業負担を軽減することができる。

なお、上記各実施の形態において、サーバ装置１０は、情報処理装置の一例である。ユーザ端末２０は、端末の一例である。チケットは、データの一例である。チケット受信部１１は、受信部の一例である。サーバコード実行部１２は、コード実行部、生成部及び送信部の一例である。機器制御部１３は、制御部の一例である。サーバコードは、第１のコードの一例である。クライアントコードは、第２のコードの一例である。

以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

以上の説明に関し、更に以下の項を開示する。
（付記１）
ネットワークを介して接続される機器の制御に関するＡＰＩ群を提供する情報処理装置であって、
前記ＡＰＩ群のうちのいずれかのＡＰＩに関するデータを端末から受信する受信部と、
前記データに含まれている、前記情報処理装置が実行する処理を示す第１のコードを実行して、前記ＡＰＩ群のうち前記第１のコードに指定されているＡＰＩを前記端末から呼び出し可能な状態にするコード実行部と、
前記端末から送信される前記第１のコードに指定されているＡＰＩの呼び出し要求に応じ、当該ＡＰＩに応じた制御を前記機器に対して実行する制御部と、
を有することを特徴とする情報処理装置。
（付記２）
前記データは、前記端末が実行する処理を示す第２のコードを含み、
前記制御部は、前記端末が前記第２のコードを実行することで前記端末から送信される前記第１のコードに指定されているＡＰＩの呼び出し要求に応じ、当該ＡＰＩに応じた制御を前記機器に対して実行する、
ことを特徴とする付記１記載の情報処理装置。
（付記３）
前記第１のコードを実行することで前記端末から呼び出し可能な状態になるＡＰＩを前記端末から呼び出すために必要な情報を前記データに基づいて生成する生成部と、
前記情報を前記端末へ送信する送信部とを有し、
前記制御部は、前記情報に基づいて前記端末から送信される前記第１のコードに指定されているＡＰＩの呼び出し要求に応じ、当該ＡＰＩに応じた制御を前記機器に対して実行する、
ことを特徴とする付記１記載の情報処理装置。
（付記４）
ネットワークを介して接続される機器の制御に関するＡＰＩ群を提供する情報処理装置と、前記情報処理装置にネットワークを介して接続される端末とを含むアクセス制御システムであって、
前記情報処理装置は、
前記ＡＰＩ群のうちのいずれかのＡＰＩに関するデータを端末から受信する受信部と、
前記データに含まれている、前記情報処理装置が実行する処理を示す第１のコードを実行して、前記ＡＰＩ群のうち前記第１のコードに指定されているＡＰＩを前記端末から呼び出し可能な状態にするコード実行部と、
前記端末から送信される前記第１のコードに指定されているＡＰＩの呼び出し要求に応じ、当該ＡＰＩに応じた制御を前記機器に対して実行する制御部と、
を有することを特徴とするアクセス制御システム。
（付記５）
前記データは、前記端末が実行する処理を示す第２のコードを含み、
前記制御部は、前記端末が前記第２のコードを実行することで前記端末から送信される前記第１のコードに指定されているＡＰＩの呼び出し要求に応じ、当該ＡＰＩに応じた制御を前記機器に対して実行する、
ことを特徴とする付記４記載のアクセス制御システム。
（付記６）
前記情報処理装置は、
前記第１のコードを実行することで前記端末から呼び出し可能な状態になるＡＰＩを前記端末から呼び出すために必要な情報を前記データに基づいて生成する生成部と、
前記情報を前記端末へ送信する送信部とを有し、
前記制御部は、前記情報に基づいて前記端末から送信される前記第１のコードに指定されているＡＰＩの呼び出し要求に応じ、当該ＡＰＩに応じた制御を前記機器に対して実行する、
ことを特徴とする付記４記載のアクセス制御システム。
（付記７）
ネットワークを介して接続される機器の制御に関するＡＰＩ群を提供する情報処理装置に、
前記ＡＰＩ群のうちのいずれかのＡＰＩに関するデータを端末から受信し、
前記データに含まれている、前記情報処理装置が実行する処理を示す第１のコードを実行して、前記ＡＰＩ群のうち前記第１のコードに指定されているＡＰＩを前記端末から呼び出し可能な状態にし、
前記端末から送信される前記第１のコードに指定されているＡＰＩの呼び出し要求に応じ、当該ＡＰＩに応じた制御を前記機器に対して実行する、
処理を実行させることを特徴とするアクセス制御プログラム。
（付記８）
前記データは、前記端末が実行する処理を示す第２のコードを含み、
前記制御を前記機器に対して実行する処理は、前記端末が前記第２のコードを実行することで前記端末から送信される前記第１のコードに指定されているＡＰＩの呼び出し要求に応じ、当該ＡＰＩに応じた制御を前記機器に対して実行する、
ことを特徴とする付記７記載のアクセス制御プログラム。
（付記９）
前記第１のコードを実行することで前記端末から呼び出し可能な状態になるＡＰＩを前記端末から呼び出すために必要な情報を前記データに基づいて生成し、
前記情報を前記端末へ送信する、
処理を前記情報処理装置に実行させ、
前記制御を前記機器に対して実行する処理は、前記情報に基づいて前記端末から送信される前記第１のコードに指定されているＡＰＩの呼び出し要求に応じ、当該ＡＰＩに応じた制御を前記機器に対して実行する、
ことを特徴とする付記７記載のアクセス制御プログラム。

１ アクセス制御システム
１０ サーバ装置
１１ チケット受信部
１２ サーバコード実行部
１３ 機器制御部
２０ ユーザ端末
２１ チケット送信部
２２ クライアントコード実行部
２３ ＡＰＩ呼出部
２４ チケット記憶部
３０ 機器
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
２００ ドライブ装置
２０１ 記録媒体
２０２ 補助記憶装置
２０３ メモリ装置
２０４ ＣＰＵ
２０５ インタフェース装置
２０６ 表示装置
２０７ 入力装置
Ｎ１ ネットワーク
Ｎ２ ネットワーク

Claims (5)

1. ネットワークを介して接続される機器の制御に関するＡＰＩ群を提供する情報処理装置であって、
   前記ＡＰＩ群のうちのいずれかのＡＰＩに関するデータを端末から受信する受信部と、
   前記データに含まれている、前記情報処理装置が実行する処理を示す第１のコードを実行して、前記ＡＰＩ群のうち前記第１のコードに指定されているＡＰＩを前記端末から呼び出し可能な状態にするコード実行部と、
   前記端末から送信される前記第１のコードに指定されているＡＰＩの呼び出し要求に応じ、当該ＡＰＩに応じた制御を前記機器に対して実行する制御部と、
   を有することを特徴とする情報処理装置。
2. 前記データは、前記端末が実行する処理を示す第２のコードを含み、
   前記制御部は、前記端末が前記第２のコードを実行することで前記端末から送信される前記第１のコードに指定されているＡＰＩの呼び出し要求に応じ、当該ＡＰＩに応じた制御を前記機器に対して実行する、
   ことを特徴とする請求項１記載の情報処理装置。
3. 前記第１のコードを実行することで前記端末から呼び出し可能な状態になるＡＰＩを前記端末から呼び出すために必要な情報を前記データに基づいて生成する生成部と、
   前記情報を前記端末へ送信する送信部とを有し、
   前記制御部は、前記情報に基づいて前記端末から送信される前記第１のコードに指定されているＡＰＩの呼び出し要求に応じ、当該ＡＰＩに応じた制御を前記機器に対して実行する、
   ことを特徴とする請求項１記載の情報処理装置。
4. ネットワークを介して接続される機器の制御に関するＡＰＩ群を提供する情報処理装置と、前記情報処理装置にネットワークを介して接続される端末とを含むアクセス制御システムであって、
   前記情報処理装置は、
   前記ＡＰＩ群のうちのいずれかのＡＰＩに関するデータを端末から受信する受信部と、
   前記データに含まれている、前記情報処理装置が実行する処理を示す第１のコードを実行して、前記ＡＰＩ群のうち前記第１のコードに指定されているＡＰＩを前記端末から呼び出し可能な状態にするコード実行部と、
   前記端末から送信される前記第１のコードに指定されているＡＰＩの呼び出し要求に応じ、当該ＡＰＩに応じた制御を前記機器に対して実行する制御部と、
   を有することを特徴とするアクセス制御システム。
5. ネットワークを介して接続される機器の制御に関するＡＰＩ群を提供する情報処理装置に、
   前記ＡＰＩ群のうちのいずれかのＡＰＩに関するデータを端末から受信し、
   前記データに含まれている、前記情報処理装置が実行する処理を示す第１のコードを実行して、前記ＡＰＩ群のうち前記第１のコードに指定されているＡＰＩを前記端末から呼び出し可能な状態にし、
   前記端末から送信される前記第１のコードに指定されているＡＰＩの呼び出し要求に応じ、当該ＡＰＩに応じた制御を前記機器に対して実行する、
   処理を実行させることを特徴とするアクセス制御プログラム。

Images