(57)【要約】      （修正有）【課題】セキュリティを向上できる認証装置、認証方法及び認証プログラムを提供する。【解決手段】認証装置（リモートプロキシ１００）は、解釈部１０１と、更新部１０２とを有する。解釈部は、デバイスから取得したＴＤ（Thing  Description）に含まれるＡＰＩ（Application  Programming  Interface）に関する情報を抽出する。更新部は、抽出したＡＰＩに関する情報に基づいて、異なる種別のＡＰＩに変更するか否かを判断する。更新部は、変更すると判断した場合、ＴＤに含まれるＡＰＩに関する情報を所定の種別のＡＰＩの情報に変換するとともに、自装置で使用する認証種別に対応する認証パラメータをＡＰＩの引数として追加することで、ＴＤを更新する。一方、更新部は、変更しないと判断した場合、自装置で使用する認証種別に対応する認証パラメータをＡＰＩの引数として追加することで、ＴＤを更新する。【選択図】図４
2020077304.tif 000002
【特許請求の範囲】
【請求項１】
デバイスから取得したＴＤ（Thing  Description）に含まれるＡＰＩ（Application  Programming  Interface）に関する情報を抽出する解釈部と、
抽出した前記ＡＰＩに関する情報に基づいて、異なる種別のＡＰＩに変更するか否かを判断し、変更すると判断した場合、前記ＴＤに含まれる前記ＡＰＩに関する情報を所定の種別のＡＰＩの情報に変換するとともに、自装置で使用する認証種別に対応する認証パラメータを前記ＡＰＩの引数として追加することで、一方、変更しないと判断した場合、自装置で使用する認証種別に対応する認証パラメータを前記ＡＰＩの引数として追加することで、前記ＴＤを更新する更新部と、
を有することを特徴とする認証装置。
【請求項２】
クライアントから前記デバイスに対するリクエストを受け付けると、更新された前記ＴＤを参照し、前記リクエストから前記デバイスの認証パラメータと、前記自装置の認証パラメータと、前記デバイスの前記ＡＰＩの引数とを抽出する抽出部と、
抽出された前記自装置の認証パラメータに基づいて、認証を行う認証部と、
抽出された前記デバイスの認証パラメータと、前記ＡＰＩの引数と、更新前後の前記ＴＤとに基づいて、前記ＡＰＩに応じたリクエストを再生成する生成部と、
再生成された前記リクエストを前記デバイスに発信する発信部と、
を有することを特徴とする請求項１に記載の認証装置。
【請求項３】
前記更新部は、前記ＡＰＩの種別が入力引数を持つ種別である場合、前記ＡＰＩの種別を変更しないと判断し、前記自装置で使用する認証種別に対応する認証パラメータを前記ＡＰＩの引数として追加する、
ことを特徴とする請求項１または２に記載の認証装置。
【請求項４】
前記更新部は、前記ＡＰＩの種別が入力引数を持たない種別である場合、前記ＡＰＩの種別を変更すると判断し、前記ＡＰＩに関する情報を、入力引数を持つ種別のＡＰＩの情報に変換するとともに、前記自装置で使用する認証種別に対応する認証パラメータを前記ＡＰＩの引数として追加する、
ことを特徴とする請求項１または２に記載の認証装置。
【請求項５】
前記更新部は、前記ＡＰＩの種別が入力引数を持たず、かつ、プッシュ通知型の種別である場合、前記ＡＰＩの種別を変更すると判断し、前記ＡＰＩの通信プロトコルを双方向通信が可能なプロトコルに変換し、前記ＡＰＩに関する情報を、入力引数を持つ種別のＡＰＩの情報に変換するとともに、前記自装置で使用する認証種別に対応する認証パラメータを前記ＡＰＩの引数として追加する、
ことを特徴とする請求項１または２に記載の認証装置。
【請求項６】
デバイスから取得したＴＤ（Thing  Description）に含まれるＡＰＩ（Application  Programming  Interface）に関する情報を抽出し、
抽出した前記ＡＰＩに関する情報に基づいて、異なる種別のＡＰＩに変更するか否かを判断し、変更すると判断した場合、前記ＴＤに含まれる前記ＡＰＩに関する情報を所定の種別のＡＰＩの情報に変換するとともに、自装置で使用する認証種別に対応する認証パラメータを前記ＡＰＩの引数として追加することで、一方、変更しないと判断した場合、自装置で使用する認証種別に対応する認証パラメータを前記ＡＰＩの引数として追加することで、前記ＴＤを更新する、
処理をコンピュータが実行することを特徴とする認証方法。
【請求項７】
デバイスから取得したＴＤ（Thing  Description）に含まれるＡＰＩ（Application  Programming  Interface）に関する情報を抽出し、
抽出した前記ＡＰＩに関する情報に基づいて、異なる種別のＡＰＩに変更するか否かを判断し、変更すると判断した場合、前記ＴＤに含まれる前記ＡＰＩに関する情報を所定の種別のＡＰＩの情報に変換するとともに、自装置で使用する認証種別に対応する認証パラメータを前記ＡＰＩの引数として追加することで、一方、変更しないと判断した場合、自装置で使用する認証種別に対応する認証パラメータを前記ＡＰＩの引数として追加することで、前記ＴＤを更新する、
処理をコンピュータに実行させることを特徴とする認証プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認証装置、認証方法および認証プログラムに関する。
【背景技術】
【０００２】
近年、多数のセンサ等の物をネットワークに接続するＩｏＴ（Internet  of  Things）と呼ばれる技術が提案されている。これらのセンサ等はＩｏＴデバイスと呼ばれ、様々な通信方法やプロトコルを用いている。ＩｏＴデバイスをＷｅｂ上で利用するためには、様々な通信方法やプロトコルを統一的に扱えることが望ましい。Ｗ３Ｃ（World  Wide  Web  Consortium）では、ＷｏＴ（Web  of  Things）ＩＧ（Interest  Group）において、認証を備えたＷｅｂＡＰＩ（Application  Programming  Interface）をクラウドやゲートウェイ上に構築する仕組みの標準化が進められている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１３−０４１４０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、ＷｏＴで規定するＡＰＩの種別に合わせて、クラウドやＧＷで独自に認証を追加することが、現在の仕様では難しい。このため、ＷｏＴの規定に対してセキュリティを向上させることが難しい。
【０００５】
一つの側面では、セキュリティを向上できる認証装置、認証方法および認証プログラムを提供することにある。
【課題を解決するための手段】
【０００６】
一つの態様では、認証装置は、解釈部と、更新部とを有する。解釈部は、デバイスから取得したＴＤ（Thing  Description）に含まれるＡＰＩ（Application  Programming  Interface）に関する情報を抽出する。更新部は、抽出した前記ＡＰＩに関する情報に基づいて、異なる種別のＡＰＩに変更するか否かを判断する。更新部は、変更すると判断した場合、前記ＴＤに含まれる前記ＡＰＩに関する情報を所定の種別のＡＰＩの情報に変換するとともに、自装置で使用する認証種別に対応する認証パラメータを前記ＡＰＩの引数として追加することで、前記ＴＤを更新する。一方、更新部は、変更しないと判断した場合、自装置で使用する認証種別に対応する認証パラメータを前記ＡＰＩの引数として追加することで、前記ＴＤを更新する。
【発明の効果】
【０００７】
セキュリティを向上できる。
【図面の簡単な説明】
【０００８】
【図１】図１は、ＷｏＴ基盤の一例を示す図である。
【図２】図２は、ＴＤの記述の一例を示す図である。
【図３】図３は、実施例のＷｏＴ基盤の構成の一例を示す図である。
【図４】図４は、実施例のリモートプロキシの機能構成の一例を示すブロック図である。
【図５】図５は、実施例のＴＤ書換処理の一例を示すシーケンス図である。
【図６】図６は、実施例のリクエスト発行処理の一例を示すシーケンス図である。
【図７】図７は、実施例のリクエスト発行処理の一例を示すシーケンス図である。
【図８】図８は、ＴＤ解釈の一例を示す図である。
【図９】図９は、ＴＤ書換の一例を示す図である。
【図１０】図１０は、ＴＤ書換の他の一例を示す図である。
【図１１】図１１は、ＴＤ書換の他の一例を示す図である。
【図１２】図１２は、パラメータの分離の一例を示す図である。
【図１３】図１３は、リクエストの再生成の一例を示す図である。
【図１４】図１４は、ｅｖｅｎｔデータの送信の一例を示す図である。
【図１５】図１５は、認証プログラムを実行するコンピュータの一例を示す図である。
【発明を実施するための形態】
【０００９】
以下、図面に基づいて、本願の開示する認証装置、認証方法および認証プログラムの実施例を詳細に説明する。なお、本実施例により、開示技術が限定されるものではない。また、以下の実施例は、矛盾しない範囲で適宜組みあわせてもよい。
【実施例】
【００１０】
まず、認証を備えたＷｅｂＡＰＩをクラウドやゲートウェイ（以下、ＧＷ（Gateway）という。）上に構築するＷｏＴ基盤について説明する。図１は、ＷｏＴ基盤の一例を示す図である。図１に示すように、ＷｏＴ基盤５は、ＧＷ１０と、デバイス１５と、ＴＤ（Thing  Description）レポジトリ２０と、クライアント端末２２とを有する。
【００１１】
ＧＷ１０は、Ｗｅｂサーバ１１と、クライアント１２と、システムＡＰＩ１３と、Ｗｅｂプロトコル変換１４とを有する。デバイス１５は、例えば、ＢＬＥ（Bluetooth（登録商標）  Low  Energy）デバイス１６、ＯＣＦ（Open  Connectivity  Foundation）デバイス１７、Ｅｃｈｏｎｅｔデバイス１８、Ｓｅｒｖｉｅｎｔ１９といった各種のデバイスを有する。ＢＬＥデバイス１６は、例えば、通信にＢＬＥを用いたセンサ等である。Ｅｃｈｏｎｅｔデバイス１８は、例えば、スマートハウス向けの通信プロトコルであるＥｃｈｏｎｅｔを用いた照明器具等である。Ｓｅｒｖｉｅｎｔ１９は、例えば、電球等の通信モジュールを持たないレガシーデバイスを制御するスマートハブ等である。
【００１２】
ＧＷ１０は、デバイス１５に対するＷｅｂアクセスを行うために、ＷｅｂＡＰＩを提供するゲートウェイサーバである。Ｗｅｂサーバ１１は、ネットワーク経由でアクセスするクライアント端末２２に対してＷｅｂＡＰＩを提供する。クライアント１２は、システムＡＰＩ１３と、Ｗｅｂプロトコル変換１４とを制御して、デバイス１５の各種のデバイスとの間で通信を行う。システムＡＰＩ１３は、例えば、ＢＬＥ  Ｓｔａｃｋ等であり、ＢＬＥデバイス１６との通信を制御するためのＡＰＩである。Ｗｅｂプロトコル変換１４は、例えば、ＯＣＦデバイス１７、Ｅｃｈｏｎｅｔデバイス１８、Ｓｅｒｖｉｅｎｔ１９等との通信において、ＯＣＦやＥｃｈｏｎｅｔ等のプロトコル変換を行う。
【００１３】
ＴＤレポジトリ２０は、デバイス１５に含まれる各デバイスのＡＰＩの詳細、例えば、ＵＲＬ（Uniform  Resource  Locator）、ｉｎｐｕｔ／ｏｕｔｐｕｔパラメータフォーマットといった情報を記述するＴＤ２１を記憶する。クライアント端末２２は、Ｗｅｂアプリケーション２３を用いてＧＷ１０を介してデバイス１５の各種のデバイスにアクセスする。このとき、Ｗｅｂアプリケーション２３は、ＴＤ２１を参照することで、ＷｅｂＡＰＩの叩き方が分かる。また、Ｗｅｂサーバ１１は、ＴＤ２１を参照することで、ＷｅｂＡＰＩの開き方、つまりデバイス１５の各種デバイスへのアクセスの仕方が分かる。つまり、ＴＤ２１をＧＷ１０、デバイス１５およびＷｅｂアプリケーション２３で共有することで、ＷｅｂＡＰＩアクセスを可能とする。
【００１４】
すなわち、ＷｏＴ基盤５は、ＢＬＥデバイス１６、ＯＣＦデバイス１７、Ｅｃｈｏｎｅｔデバイス１８、Ｓｅｒｖｉｅｎｔ１９といった通信方法やプロトコルが多様化するＩｏＴデバイスをＷｅｂ技術で統一的に扱うことで、連携を容易にする。
【００１５】
図２は、ＴＤの記述の一例を示す図である。図２に示すＴＤ２１ａは、３種類のＡＰＩの記述について、それぞれ一例を示したものである。３種類のＡＰＩは、ｐｒｏｐｅｒｔｙ、ａｃｔｉｏｎおよびｅｖｅｎｔである。ｐｒｏｐｅｒｔｙは、入力引数を持たず、デバイス属性値を参照するＡＰＩである。記述２４は、ｐｒｏｐｅｒｔｙの記述の一例である。ａｃｔｉｏｎは、入力引数を持ち、デバイスへの問い合わせを行うＡＰＩである。記述２５は、ａｃｔｉｏｎの記述の一例である。ｅｖｅｎｔは、デバイス起点のＰＵＳＨ型通知のＡＰＩである。記述２６は、ｅｖｅｎｔの記述の一例である。なお、記述２４〜２６では、ｈｒｅｆを用いてＷｅｂＡＰＩのＵＲＬやプロトコル（ｈｔｔｐ／ｃｏａｐ等）を指定する。また、ａｃｔｉｏｎでは、ｉｎｐｕｔで入力引数を指定することができる。
【００１６】
しかしながら、ＴＤ２１ａは、プロキシで独自の認証を追加したいときに、プロキシ認証を行うための認証方法やパラメータに関する情報を記述することができない。セキュリティメタデータには、そのままでは複数の認証方法を記述することができないため、デバイスが認証を備える場合に、プロキシ認証の情報をセキュリティメタデータで表現することができなくなる。また、ＡＰＩ種別がｐｒｏｐｅｒｔｙのような入力引数を指定しないＡＰＩである場合、プロキシ認証の情報を記述する場所がない。これに対し、本実施例では、ＡＰＩ種別に合わせて、引数追加、ＡＰＩ種別変換、通信プロトコル変換等を行って適切にＴＤを書き換える。本実施例では、ＴＤの書き換えにより、デバイスの認証情報とプロキシの認証情報とを記述することで、プロキシにおける独自の認証を追加することができる。
【００１７】
次に、実施例のＷｏＴ基盤の構成について説明する。図３は、実施例のＷｏＴ基盤の構成の一例を示す図である。図３に示すように、ＷｏＴ基盤１は、ローカルネットワークであるネットワークＮ１と、クラウド７０と、クライアント端末９０とを有する。なお、ＷｏＴ基盤１では、ネットワークＮ１およびクライアント端末９０の数は限定されず、任意の数のネットワークＮ１およびクライアント端末９０を有するようにしてもよい。
【００１８】
ネットワークＮ１と、クラウド７０との間は、ネットワークＮを介して、相互に通信可能に接続される。かかるネットワークＮには、有線または無線を問わず、インターネットを始め、ＬＡＮ（Local  Area  Network）やＶＰＮ（Virtual  Private  Network）などの任意の種類の通信網を採用できる。また、ネットワークＮを介する通信は、例えば、ＴＬＳ（Transport  Layer  Security）／ＳＳＬ（Secure  Sockets  Layer）等によって暗号化されるようにしてもよい。クラウド７０と、クライアント端末９０との間は、例えばインターネット等の図示しないネットワークを介して、相互に通信可能に接続される。
【００１９】
ネットワークＮ１は、ローカルネットワークを示し、当該ローカルネットワーク内には、ローカルプロキシ（以下、ＬＰ（Local  Proxy）という。）５０と、ＧＷ５１と、ＢＬＥデバイス５２ａと、Ｅｃｈｏｎｅｔデバイス５２ｂとを有する。なお、以下の説明において、ＢＬＥデバイス５２ａと、Ｅｃｈｏｎｅｔデバイス５２ｂとを区別しない場合には、デバイス５２と表現する。クラウド７０は、ＴＤレポジトリ８０と、リモートプロキシ（以下、ＲＰ（Remote  Proxy）という。）１００とを有する。なお、クラウド７０は、例えば、ＰａａＳ（Platform  as  a  Service）等のクラウドコンピューティング技術を用いてクラウドサービスを提供する。
【００２０】
ＬＰ５０は、ネットワークＮ１内とクラウド７０との間の通信を中継するプロキシサーバである。ＧＷ５１は、デバイス５２と接続され、システムＡＰＩの呼び出しやプロトコル変換等を行うことで、非Ｗｅｂデバイスや各種のプロトコルを用いたデバイスの違いを吸収するためのゲートウェイサーバである。また、ＧＷ５１は、デバイス５２のＴＤ６０を持つ。ＴＤ６０は、予めＧＷ５１がデバイス５２から取得するか、ネットワークＮ１の管理者によってＧＷ５１に設定される。ＧＷ５１は、ＬＰ５０から要求があると、ＴＤ６０をＬＰ５０に送信する。
【００２１】
ＴＤレポジトリ８０は、ＲＰ１００で更新されたＴＤ６１を記憶する。ＴＤ６１は、クライアント端末９０およびＲＰ１００から参照することができる。ＲＰ１００は、クライアント端末９０に対してＷｅｂＡＰＩを公開し、クライアント端末９０とＬＰ５０との間の通信を中継するプロキシサーバである。また、ＲＰ１００は、プロキシ認証を行う認証装置でもある。クライアント端末９０は、クライアントアプリを介して、ユーザに情報の提供および操作の受け付け等を行うユーザインタフェースを提供する。
【００２２】
すなわち、ＷｏＴ基盤１では、ネットワークＮ１内のデバイス５２をクラウド７０から安全に利用することを想定している。このため、ＷｏＴ基盤１は、ＲＰ１００とＬＰ５０との２段構成で、クライアント端末９０のクライアントアプリからデバイス５２へのアクセスを実現する。
【００２３】
つまり、ＲＰ１００は、デバイス５２から取得したＴＤ６０に含まれるＡＰＩに関する情報を抽出する。ＲＰ１００は、抽出したＡＰＩに関する情報に基づいて、異なる種別のＡＰＩに変更するか否かを判断する。ＲＰ１００は、変更すると判断した場合、ＴＤ６０に含まれるＡＰＩに関する情報を所定の種別のＡＰＩの情報に変換するとともに、自装置で使用する認証種別に対応する認証パラメータをＡＰＩの引数として追加することで、ＴＤ６０をＴＤ６１に更新する。一方、ＲＰ１００は、変更しないと判断した場合、自装置で使用する認証種別に対応する認証パラメータをＡＰＩの引数として追加することで、ＴＤ６０をＴＤ６１に更新する。これにより、ＲＰ１００は、セキュリティを向上できる。
【００２４】
続いて、ＲＰ１００の構成について説明する。図４は、実施例のリモートプロキシの機能構成の一例を示すブロック図である。図４に示すように、ＲＰ１００は、ＴＤ解釈部１０１と、ＴＤ書換部１０２と、ＵＰ部１０３と、ＷｅｂＡＰＩ１０４と、書換情報１０５とを有する。また、ＲＰ１００は、パラメータ抽出部１０６と、認証実行部１０７と、認証情報１０８と、リクエスト発信部１０９と、リクエスト対応情報１１０とを有する。なお、書換情報１０５と、認証情報１０８と、リクエスト対応情報１１０とは、図示しない記憶部に記憶される。
【００２５】
ＴＤ解釈部１０１は、セキュリティメタデータ等の解釈を行う。ＴＤ解釈部１０１は、ネットワークＮを介して、ＬＰ５０からＴＤ６０を受信すると、ＴＤ６０のセキュリティメタデータ“ｓｅｃｕｒｉｔｙ”からデバイスの認証方法を取得する。認証方法には、例えば、ＢＡＳＩＣ認証等が挙げられる。また、ＴＤ解釈部１０１は、ＴＤ６０から暗号化の有無とＡＰＩ種別とを取得する。
【００２６】
ＴＤ解釈部１０１は、ＴＤ６０のＡＰＩのＵＲＬを示す“ｈｒｅｆ”から暗号化の有無を取得する。例えば、ＴＤ解釈部１０１は、“ｈｒｅｆ”に記述されるＵＲＬが「ｈｔｔｐｓ」から始まる場合には暗号化ありとの情報を取得する。一方、ＴＤ解釈部１０１は、“ｈｒｅｆ”に記述されるＵＲＬが「ｈｔｔｐ」から始まる場合には暗号化なしとの情報を取得する。ＴＤ解釈部１０１は、ＡＰＩ種別としてａｃｔｉｏｎ、ｐｒｏｐｅｒｔｙおよびｅｖｅｎｔのうち、いずれであるかを取得する。なお、ａｃｔｉｏｎは、入力引数を持つＡＰＩ種別であり、ｐｒｏｐｅｒｔｙは、入力引数を持たないＡＰＩ種別である。また、ｅｖｅｎｔは、入力引数を持たず、かつ、プッシュ通知型（ＰＵＳＨ型通知）のＡＰＩ種別である。ＴＤ解釈部１０１は、取得したデバイスの認証方法、暗号化の有無を示す情報およびＡＰＩ種別を、ＴＤ６０とともにＴＤ書換部１０２に出力する。
【００２７】
言い換えると、ＴＤ解釈部１０１は、デバイス５２から取得したＴＤ６０に含まれるＡＰＩに関する情報を抽出する解釈部の一例である。
【００２８】
ＴＤ書換部１０２は、アドレス変換（ＩＰ（Internet  Protocol）アドレス変換）、引数追加、ＡＰＩ種別変換およびプロトコル変換を行う。ＴＤ書換部１０２は、ＴＤ解釈部１０１からデバイスの認証方法、暗号化の有無を示す情報、ＡＰＩ種別およびＴＤ６０が入力されると、ＡＰＩ種別を判定する。ＴＤ書換部１０２は、ＡＰＩ種別がａｃｔｉｏｎであると判定した場合には、ＲＰ１００の認証パラメータをＡＰＩの引数に追加してＴＤ６０をＴＤ６１に更新する。つまり、入力引数を持つａｃｔｉｏｎは、入力引数部分（ｉｎｐｕｔ）にＲＰ１００の認証パラメータを追記することで、セキュリティメタデータを使わずにプロキシ認証情報を要求する。なお、ＲＰ１００では、独自の認証として、例えばｄｉｇｅｓｔ認証を実行するものとする。ＴＤ書換部１０２は、ＡＰＩの引数“ｉｎｐｕｔ”に、予め決定された、ｄｉｇｅｓｔ認証に用いるｕｓｅｒｎａｍｅや、所定の計算結果であるｒｅｓｐｏｎｓｅ等を追加する。また、ＴＤ書換部１０２は、“ｈｒｅｆ”内のＷｅｂＡＰＩのアドレスに対応するＵＲＬを暗号化に対応するように、例えば、ｈｔｔｐからｈｔｔｐｓに変更する。なお、ＴＤの書き換えは、Ｗ３ＣのＷｏＴで規定されたＴＤの書式の範囲内で行うものである。
【００２９】
ＴＤ書換部１０２は、ＡＰＩ種別がｐｒｏｐｅｒｔｙであると判定した場合には、ＡＰＩ種別をａｃｔｉｏｎに変換する。ＴＤ書換部１０２は、ａｃｔｉｏｎに変換後に、ＡＰＩ種別がａｃｔｉｏｎの場合と同様に、ＲＰ１００の認証パラメータをＡＰＩの引数に追加してＴＤ６０をＴＤ６１に更新する。つまり、入力引数を持たないｐｒｏｐｅｒｔｙは、ＡＰＩ種別をａｃｔｉｏｎに変換した上で、入力引数部分（ｉｎｐｕｔ）にＲＰ１００の認証パラメータを追記する。
【００３０】
ＴＤ書換部１０２は、ＡＰＩ種別がｅｖｅｎｔであると判定した場合には、通信プロトコルをｈｔｔｐからＷｅｂｓｏｃｋｅｔ等の双方向通信が可能な通信プロトコルに変換する。ＴＤ書換部１０２は、例えば、ＴＤ６０の“ｆｏｒｍｓ”の”ｈｒｅｆ”を用いて、ＡＰＩの通信プロトコルをｈｔｔｐからＷｅｂｓｏｃｋｅｔに書き換える。なお、クライアント端末９０のクライアントアプリが双方向通信に非対応の場合、ｈｔｔｐ（ｓ）のロングポーリングによる記述を追加するようにしてもよい。この場合、１つのａｃｔｉｏｎに“ｆｏｒｍｓ”を２つ記述することで、サーバが２通りの通信方法に対応していることを表すことができる。このとき、クライアントアプリは、自身が対応する通信方法を用いてリクエストを送信する。ＴＤ書換部１０２は、通信プロトコルの変換後に、ＡＰＩ種別をａｃｔｉｏｎに変換する。ＴＤ書換部１０２は、ａｃｔｉｏｎに変換後に、ＡＰＩ種別がａｃｔｉｏｎの場合と同様に、ＲＰ１００の認証パラメータをＡＰＩの引数に追加してＴＤ６０をＴＤ６１に更新する。つまり、ＰＵＳＨ型通知を行うｅｖｅｎｔでは、通信プロトコル変換を行い、かつ、ＡＰＩ種別をａｃｔｉｏｎに変換した上で、入力引数部分（ｉｎｐｕｔ）にＲＰ１００の認証パラメータを追記する。
【００３１】
ＴＤ書換部１０２は、更新前後のＴＤ６０，６１を書換情報１０５として図示しない記憶部に記憶する。また、ＴＤ書換部１０２は、更新後のＴＤ６１を、ＵＰ部１０３を介してＴＤレポジトリ８０に送信して記憶させる。ＴＤ書換部１０２は、更新後のＴＤ６１に対応するＷｅｂＡＰＩ１０４を設定する。
【００３２】
言い換えると、ＴＤ書換部１０２は、抽出したＡＰＩに関する情報に基づいて、異なる種別のＡＰＩに変更するか否かを判断する。ＴＤ書換部１０２は、変更すると判断した場合、ＴＤに含まれるＡＰＩに関する情報を所定の種別のＡＰＩの情報に変換するとともに、自装置で使用する認証種別に対応する認証パラメータをＡＰＩの引数として追加することで、ＴＤを更新する。一方、ＴＤ書換部１０２は、変更しないと判断した場合、自装置で使用する認証種別に対応する認証パラメータをＡＰＩの引数として追加することで、ＴＤを更新する。また、ＴＤ書換部１０２は、ＡＰＩの種別が入力引数を持つ種別である場合、ＡＰＩの種別を変更しないと判断し、自装置で使用する認証種別に対応する認証パラメータをＡＰＩの引数として追加する。また、ＴＤ書換部１０２は、ＡＰＩの種別が入力引数を持たない種別である場合、ＡＰＩの種別を変更すると判断する。ＴＤ書換部１０２は、ＡＰＩに関する情報を、入力引数を持つ種別のＡＰＩの情報に変換するとともに、自装置で使用する認証種別に対応する認証パラメータをＡＰＩの引数として追加する。また、ＴＤ書換部１０２は、ＡＰＩの種別が入力引数を持たず、かつ、プッシュ通知型の種別である場合、ＡＰＩの種別を変更すると判断する。ＴＤ書換部１０２は、ＡＰＩの通信プロトコルを双方向通信が可能なプロトコルに変換する。さらに、ＴＤ書換部１０２は、ＡＰＩに関する情報を、入力引数を持つ種別のＡＰＩの情報に変換するとともに、自装置で使用する認証種別に対応する認証パラメータをＡＰＩの引数として追加する。すなわち、ＴＤ書換部１０２は、更新部の一例である。
【００３３】
パラメータ抽出部１０６は、認証パラメータの抽出、および、パラメータの分離を行う。パラメータ抽出部１０６は、クライアント端末９０のクライアントアプリから、ＷｅｂＡＰＩ１０４を介してリクエストを受信すると、受信したリクエストが暗号化されているか否かを判定する。パラメータ抽出部１０６は、暗号化されていると判定した場合には、リクエストのヘッダおよびボディ部を復号する。パラメータ抽出部１０６は、暗号化されていないと判定した場合には、リクエストのヘッダおよびボディ部の復号を行わない。パラメータ抽出部１０６は、ＴＤレポジトリ８０または書換情報１０５のＴＤ６１を参照し、ＲＰ１００の認証パラメータ、デバイスの認証パラメータおよびＡＰＩの引数を抽出して分離する。パラメータ抽出部１０６は、分離したＲＰ１００の認証パラメータ、デバイスの認証パラメータおよびＡＰＩの引数を認証実行部１０７に出力する。
【００３４】
言い換えると、パラメータ抽出部１０６は、クライアント端末９０からデバイス５２に対するリクエストを受け付けると、更新されたＴＤ６１を参照し、リクエストからデバイス５２の認証パラメータと、自装置の認証パラメータと、デバイス５２のＡＰＩの引数とを抽出する。
【００３５】
認証実行部１０７は、パラメータ抽出部１０６からＲＰ１００の認証パラメータ、デバイスの認証パラメータおよびＡＰＩの引数が入力されると、認証情報１０８を参照し、ＲＰ１００の認証パラメータを用いて認証を実行する。すなわち、認証実行部１０７は、抽出された自装置の認証パラメータに基づいて、認証を行う。認証実行部１０７は、認証がＯＫであるか否かを判定する。認証実行部１０７は、認証がＯＫであると判定した場合には、デバイスの認証パラメータおよびＡＰＩの引数をリクエスト発信部１０９に出力する。認証実行部１０７は、認証がＮＧであると判定した場合には、認証失敗情報をクライアント端末９０のクライアントアプリに送信する。
【００３６】
リクエスト発信部１０９は、リクエスト再生成、ＡＰＩ種別変換およびプロトコル変換を行う。リクエスト発信部１０９は、認証実行部１０７からデバイスの認証パラメータおよびＡＰＩの引数が入力されると、書換情報１０５を参照し、元のＡＰＩ種別を判定する。すなわち、リクエスト発信部１０９は、書換前のＴＤ６０と書換後のＴＤ６１とを比較することで、元のＡＰＩ種別を判定する。リクエスト発信部１０９は、元のＡＰＩ種別がａｃｔｉｏｎであると判定した場合には、再生成するリクエストのＡＰＩ種別をａｃｔｉｏｎに設定する。リクエスト発信部１０９は、元のＡＰＩ種別がｐｒｏｐｅｒｔｙであると判定した場合には、再生成するリクエストのＡＰＩ種別をｐｒｏｐｅｒｔｙに設定する。
【００３７】
リクエスト発信部１０９は、元のＡＰＩ種別がｅｖｅｎｔであると判定した場合には、通信プロトコルをＷｅｂｓｏｃｋｅｔ等の変換後の通信プロトコルから元の通信プロトコル、例えばｈｔｔｐ（ｓ）に変換する。リクエスト発信部１０９は、再生成するリクエストのＡＰＩ種別をｅｖｅｎｔに設定する。
【００３８】
リクエスト発信部１０９は、リクエスト対応情報１１０を参照し、リクエストされたＵＲＬからデバイスＵＲＬを取得する。リクエスト発信部１０９は、書換情報１０５を参照し、デバイスＵＲＬと、デバイスの認証パラメータと、ＡＰＩの引数に基づいて、デバイス５２宛のリクエストを再生成する。リクエスト発信部１０９は、再生成したリクエストを、デバイス５２宛としてＬＰ５０に送信する。リクエスト発信部１０９は、ＬＰ５０からリクエストに対するレスポンスを受信すると、受信したレスポンスをクライアント端末９０に送信する。
【００３９】
言い換えると、リクエスト発信部１０９は、抽出されたデバイス５２の認証パラメータと、ＡＰＩの引数と、更新前後のＴＤ６０，６１とに基づいて、ＡＰＩに応じたリクエストを再生成する。また、リクエスト発信部１０９は、再生成されたリクエストをデバイス５２に発信する。つまり、リクエスト発信部１０９は、生成部および発信部の一例である。
【００４０】
次に、実施例のＷｏＴ基盤１の動作について説明する。まず、デバイス５２のＴＤ６０を書き換えてＴＤレポジトリ８０に記憶するＴＤ書換処理について説明する。図５は、実施例のＴＤ書換処理の一例を示すシーケンス図である。
【００４１】
ＬＰ５０は、ＧＷ５１にデバイス５２が接続されると、ＧＷ５１を介してデバイス５２の接続を検出する（ステップＳ１）。ＬＰ５０は、デバイス５２の接続を検出すると、デバイス５２またはＧＷ５１からＴＤ６０を取得する。ＬＰ５０は、取得したＴＤ６０をＲＰ１００に送信する（ステップＳ２）。
【００４２】
ＲＰ１００のＴＤ解釈部１０１は、ＬＰ５０からＴＤ６０を受信すると（ステップＳ３）、ＴＤ６０のセキュリティメタデータ“ｓｅｃｕｒｉｔｙ”からデバイスの認証方法を取得する（ステップＳ４）。また、ＴＤ解釈部１０１は、ＴＤ６０から暗号化の有無とＡＰＩ種別とを取得する（ステップＳ５）。ＴＤ解釈部１０１は、取得したデバイスの認証方法、暗号化の有無を示す情報およびＡＰＩ種別を、ＴＤ６０とともにＴＤ書換部１０２に出力する。
【００４３】
ＴＤ書換部１０２は、ＴＤ解釈部１０１からデバイスの認証方法、暗号化の有無を示す情報、ＡＰＩ種別およびＴＤ６０が入力されると、ＡＰＩ種別を判定する（ステップＳ６）。ＴＤ書換部１０２は、ＡＰＩ種別がａｃｔｉｏｎであると判定した場合には（ステップＳ６：ａｃｔｉｏｎ）、ＡＰＩ種別はそのままでステップＳ１０に進む。
【００４４】
ＴＤ書換部１０２は、ＡＰＩ種別がｐｒｏｐｅｒｔｙであると判定した場合には（ステップＳ６：ｐｒｏｐｅｒｔｙ）、ＡＰＩ種別をａｃｔｉｏｎに変換し（ステップＳ７）、ステップＳ１０に進む。ＴＤ書換部１０２は、ＡＰＩ種別がｅｖｅｎｔであると判定した場合には（ステップＳ６：ｅｖｅｎｔ）、通信プロトコルをｈｔｔｐからＷｅｂｓｏｃｋｅｔ等の双方向通信が可能な通信プロトコルに変換する（ステップＳ８）。ＴＤ書換部１０２は、通信プロトコルの変換後に、ＡＰＩ種別をａｃｔｉｏｎに変換し（ステップＳ９）、ステップＳ１０に進む。
【００４５】
ＴＤ書換部１０２は、ステップＳ６：ａｃｔｉｏｎ、ステップＳ７、または、ステップＳ９の処理に続いて、ＲＰ１００の認証パラメータをＡＰＩの引数に追加してＴＤ６０をＴＤ６１に更新する（ステップＳ１０）。
【００４６】
ＴＤ書換部１０２は、更新前後のＴＤ６０，６１を書換情報１０５として図示しない記憶部に記憶する（ステップＳ１１）。また、ＴＤ書換部１０２は、更新後のＴＤ６１をＴＤレポジトリ８０に送信する（ステップＳ１２）。
【００４７】
ＴＤレポジトリ８０は、ＲＰ１００から更新後のＴＤ６１を受信すると、図示しない記憶部にＴＤ６１を記憶する（ステップＳ１３）。ＴＤレポジトリ８０は、ＲＰ１００およびクライアント端末９０から参照可能なようにＴＤ６１を公開する。これにより、ＲＰ１００は、デバイス５２から取得したＴＤ６０を、独自の認証を行うための情報を追加したＴＤ６１に更新することができる。
【００４８】
続いて、クライアント端末９０からリクエストが発行された場合の処理について説明する。図６および図７は、実施例のリクエスト発行処理の一例を示すシーケンス図である。なお、以下の説明では、クライアントアプリを省略してクライアント端末９０として説明する場合がある。
【００４９】
クライアント端末９０は、例えば、クライアントアプリの起動に応じて、Ｗ３Ｃの定義に則ったＴＤ取得指示をＴＤレポジトリ８０に送信する（ステップＳ２１）。ＴＤレポジトリ８０は、ＴＤ取得指示を受信すると、ＴＤ取得指示に応じてＴＤ６１をクライアント端末９０に送信する（ステップＳ２２）。クライアント端末９０は、ＴＤレポジトリ８０からＴＤ６１を受信して取得する（ステップＳ２３）。
【００５０】
クライアント端末９０は、例えば、ユーザのクライアントアプリの操作に基づいて、デバイス５２に対するリクエストの送信指示を受け付けると、ＴＤ６１のセキュリティメタデータから認証方法と暗号化の有無の情報とを取得する（ステップＳ２４）。クライアント端末９０は、取得した認証方法と暗号化の有無の情報とに基づいて、リクエストを生成する。クライアント端末９０は、生成したリクエストをＲＰ１００に送信する（ステップＳ２５）。
【００５１】
ＲＰ１００のパラメータ抽出部１０６は、クライアント端末９０からリクエストを受信すると（ステップＳ２６）、受信したリクエストが暗号化されているか否かを判定する（ステップＳ２７）。パラメータ抽出部１０６は、暗号化されていると判定した場合には（ステップＳ２７：肯定）、リクエストのヘッダおよびボディ部を復号する（ステップＳ２８）。パラメータ抽出部１０６は、暗号化されていないと判定した場合には（ステップＳ２７：否定）、リクエストのヘッダおよびボディ部の復号を行わない。
【００５２】
パラメータ抽出部１０６は、ＴＤレポジトリ８０または書換情報１０５のＴＤ６１を参照し、ＲＰ１００の認証パラメータ、デバイスの認証パラメータおよびＡＰＩの引数を抽出して分離する（ステップＳ２９）。パラメータ抽出部１０６は、分離したＲＰ１００の認証パラメータ、デバイスの認証パラメータおよびＡＰＩの引数を認証実行部１０７に出力する。
【００５３】
認証実行部１０７は、パラメータ抽出部１０６からＲＰ１００の認証パラメータ、デバイスの認証パラメータおよびＡＰＩの引数が入力されると、認証情報１０８を参照し、ＲＰ１００の認証パラメータを用いて認証を実行する（ステップＳ３０）。認証実行部１０７は、認証がＯＫであるか否かを判定する（ステップＳ３１）。認証実行部１０７は、認証がＯＫであると判定した場合には（ステップＳ３１：肯定）、デバイスの認証パラメータおよびＡＰＩの引数をリクエスト発信部１０９に出力し、ステップＳ３５に進む。
【００５４】
認証実行部１０７は、認証がＮＧであると判定した場合には（ステップＳ３１：否定）、認証失敗情報をクライアント端末９０に送信し（ステップＳ３２）、処理を終了する。クライアント端末９０は、認証失敗情報を受信したか否かを判定する（ステップＳ３３）。クライアント端末９０は、認証失敗情報を受信したと判定した場合には（ステップＳ３３：肯定）、認証失敗をユーザに通知する（ステップＳ３４）。クライアント端末９０は、認証失敗情報を受信していないと判定した場合には（ステップＳ３３：否定）、ユーザに対する通知を行わない。
【００５５】
ＲＰ１００のリクエスト発信部１０９は、認証実行部１０７からデバイスの認証パラメータおよびＡＰＩの引数が入力されると、書換情報１０５を参照し、元のＡＰＩ種別を判定する（ステップＳ３５）。リクエスト発信部１０９は、元のＡＰＩ種別がａｃｔｉｏｎであると判定した場合には（ステップＳ３５：ａｃｔｉｏｎ）、再生成するリクエストのＡＰＩ種別をａｃｔｉｏｎに設定する（ステップＳ３６）。リクエスト発信部１０９は、元のＡＰＩ種別がｐｒｏｐｅｒｔｙであると判定した場合には（ステップＳ３５：ｐｒｏｐｅｒｔｙ）、再生成するリクエストのＡＰＩ種別をｐｒｏｐｅｒｔｙに設定する（ステップＳ３７）。
【００５６】
リクエスト発信部１０９は、元のＡＰＩ種別がｅｖｅｎｔであると判定した場合には（ステップＳ３５：ｅｖｅｎｔ）、通信プロトコルを元の通信プロトコルに変換する（ステップＳ３８）。リクエスト発信部１０９は、再生成するリクエストのＡＰＩ種別をｅｖｅｎｔに設定する（ステップＳ３９）。
【００５７】
リクエスト発信部１０９は、リクエスト対応情報１１０を参照し、リクエストされたＵＲＬからデバイスＵＲＬを取得する（ステップＳ４０）。リクエスト発信部１０９は、書換情報１０５を参照し、デバイスＵＲＬと、デバイスの認証パラメータと、ＡＰＩの引数に基づいて、デバイス５２宛のリクエストを再生成する（ステップＳ４１）。リクエスト発信部１０９は、再生成したリクエストをＬＰ５０に送信する（ステップＳ４２）。
【００５８】
ＬＰ５０は、ＲＰ１００からリクエストを受信すると、受信したリクエストをデバイス５２に送信する。ＬＰ５０は、デバイス５２からリクエストに対するレスポンスを取得する（ステップＳ４３）。ＬＰ５０は、取得したレスポンスをＲＰ１００に送信する（ステップＳ４４）。
【００５９】
ＲＰ１００のリクエスト発信部１０９は、ＬＰ５０からリクエストに対するレスポンスを受信すると、受信したレスポンスをクライアント端末９０に送信し（ステップＳ４５）、処理を終了する。クライアント端末９０は、レスポンスを受信すると（ステップＳ４６）、レスポンスに応じた処理、例えば、レスポンスに含まれる温度情報を表示する等を行って、処理を終了する。これにより、ＲＰ１００は、デバイス５２での認証に加えて、ＲＰ１００での独自の認証を行うことができるので、セキュリティを向上させることができる。すなわち、ＲＰ１００は、ＷｅｂＡＰＩを安全に公開することができる。つまり、ＷｏＴ基盤１は、デバイス５２自身が持つ認証機能をＷｅｂＡＰＩに反映させ、間に存在するクラウドやＧＷに影響されず、デバイス５２とクライアント端末９０のクライアントアプリとの間で独自の認証とデバイスの認証を実現することができる。
【００６０】
次に、図８から図１４を用いて、ＴＤ解釈、ＴＤ書換、パラメータの分離、リクエストの再生成、および、ｅｖｅｎｔデータの送信について、具体例を用いて説明する。
【００６１】
図８は、ＴＤ解釈の一例を示す図である。図８に示すＴＤ１５１は、例えば、明るさや色が制御可能な、いわゆるスマート電球のオリジナルＴＤである。ＴＤ１５１の記述のうち、記述１５１ａは、セキュリティメタデータ“ｓｅｃｕｒｉｔｙ”を示し、認証方法を含む。記述１５１ａでは、ｓｃｈｅｍａ：ｂａｓｉｃであるのでＢＡＳＩＣ認証を示し、Ａｕｔｈｏｒｉｚａｔｉｏｎ  Ｈｅａｄｅｒでパラメータを受信することを示す。記述１５１ｂでは、ＷｅｂＡＰＩのＵＲＬを示す“ｈｒｅｆ”から暗号化の有無を取得できる。記述１５１ｂでは、ｈｔｔｐｓであるので暗号化通信であることを示す。記述１５１ｃでは、ＡＰＩの種類から引数の追加方法を取得できる。記述１５１ｃは、ａｃｔｉｏｎであるので、認証を追加する場合は“ｉｎｐｕｔ”内にパラメータを追加する。
【００６２】
図９は、ＴＤ書換の一例を示す図である。図９の例は、ＲＰ１００でｄｉｇｅｓｔ認証を独自に実行する場合に、ＡＰＩ種別がａｃｔｉｏｎであるＴＤ１５１を書き換えてＴＤ１５２とする場合である。ＴＤ１５１は、ＡＰＩ種別がａｃｔｉｏｎであるので、ＴＤ１５２では、ＡＰＩの“ｉｎｐｕｔ”の引数に、記述１５３に示すように、ｕｓｅｒｎａｍｅとｒｅｓｐｏｎｃｅとを追加する。なお、ｕｓｅｒｎａｍｅおよびｒｅｓｐｏｎｃｅは、ｄｉｇｅｓｔ認証に用いる情報である。
【００６３】
図１０は、ＴＤ書換の他の一例を示す図である。図１０の例は、ＲＰ１００でｄｉｇｅｓｔ認証を独自に実行する場合に、ＡＰＩ種別がｐｒｏｐｅｒｔｙであるＴＤ１５４を書き換えてＴＤ１５５とする場合である。ＴＤ１５４は、例えば、温度センサが温度を取得するＡＰＩをｐｒｏｐｅｒｔｙで公開する場合のＴＤである。ＴＤ１５４は、ＡＰＩ種別がｐｒｏｐｅｒｔｙであるため、インプットパラメータを指定することができない。従って、ＴＤ１５５では、記述１５６〜１６０に示す書き換えを行う。記述１５６では、ＡＰＩ種別をｐｒｏｐｅｒｔｙからａｃｔｉｏｎに変換する。記述１５７では、ｄｉｇｅｓｔ認証のパラメータを追加する。記述１５８では、“ｏｕｔｐｕｔ”をｐｒｏｐｅｒｔｙで取得できるデータ型に合わせる。記述１５９では、暗号化通信を示すｈｔｔｐｓとする。記述１６０では、“ｉｎｐｕｔ”をｂｏｄｙで渡すので、ＧＥＴをＰＯＳＴに変更する。なお、ＡＰＩ種別の違いは、クライアント端末９０がリクエストを出す際に意識する必要はない。
【００６４】
図１１は、ＴＤ書換の他の一例を示す図である。図１１の例は、ＲＰ１００でｄｉｇｅｓｔ認証を独自に実行する場合に、ＡＰＩ種別がｅｖｅｎｔであるＴＤ１６１を書き換えてＴＤ１６２とする場合である。ＴＤ１６１は、例えば、温度センサが定期的に温度を通知するＡＰＩをｅｖｅｎｔで公開する場合のＴＤである。ＴＤ１６１は、ＰＵＳＨ型のデータ送信を行うが、ａｃｔｉｏｎはＰＵＬＬ型であるので、ＡＰＩ種別をａｃｔｉｏｎに変換してもＰＵＳＨ型に対応することが求められる。従って、ＴＤ１６２では、記述１６３に示すように、“ｆｏｒｍ”内に双方向通信のＷｅｂｓｏｃｋｅｔと、ロングポーリングに対応するｈｔｔｐの２通りのプロトコルを記述する。クライアント端末９０は、自身が対応するいずれか一方のプロトコルを用いてリクエストを出せばよい。
【００６５】
図１２は、パラメータの分離の一例を示す図である。図１２の例では、ＲＰ１００は、リクエスト１６５が暗号化されているので、リクエスト１６５のヘッダおよびボディ部を復号してリクエスト１６６とする。ＲＰ１００は、ＴＤ１６７を参照し、記述１６８に基づいて、リクエスト１６６のＲｅｑｕｅｓｔ  Ｂｏｄｙから、ＲＰ１００の認証パラメータを抽出する。また、ＲＰ１００は、リクエスト１６６のＲｅｑｕｅｓｔ  Ｂｏｄｙから、ＡＰＩの引数を抽出する。さらに、ＲＰ１００は、ＴＤ１６７を参照し、記述１６９に基づいて、リクエスト１６６のＲｅｑｕｅｓｔ  Ｈｅａｄｅｒから、デバイスの認証パラメータを抽出する。ＲＰ１００は、抽出した各パラメータ等を分離して仕分けることで、パラメータ１７０とする。
【００６６】
図１３は、リクエストの再生成の一例を示す図である。図１３の例は、クライアント端末９０から受信したリクエストから抽出されたパラメータ１７０に基づいて、ＬＰ５０へ送信するリクエスト１７１を再生成する場合である。リクエスト１７１は、デバイス５２に対するリクエストであり、ＬＰ５０およびＧＷ５１を経由するものとする。ＲＰ１００は、書換情報１０５の書換前後のＴＤと、リクエスト対応情報１１０とを参照し、パラメータ１７０に基づいて、デバイス５２に対応するリクエスト１７１を再生成する。なお、リクエスト対応情報１１０の受信欄は、クライアント端末９０からＲＰ１００を見た場合のＵＲＬを示し、送信欄は、ＲＰ１００からＬＰ５０を見た場合のＵＲＬを示す。
【００６７】
図１４は、ｅｖｅｎｔデータの送信の一例を示す図である。図１４は、ＡＰＩ種別をｅｖｅｎｔからａｃｔｉｏｎに変換した場合における、デバイス５２からのｅｖｅｎｔデータの送信の一例である。デバイス５２から送信されたデータ１７２は、ＧＷ５１およびＬＰ５０を経由して、ＲＰ１００がプッシュ受信を行う。ＲＰ１００は、データ１７２から温度データ１７３を抽出し、通信プロトコル変換と、ＡＰＩ種別のａｃｔｉｏｎへの変換とを行ってデータ１７４を再生成する。ＲＰ１００は、再生成したデータ１７４をクライアント端末９０にプッシュ送信する。
【００６８】
このように、ＲＰ１００は、デバイス５２から取得したＴＤに含まれるＡＰＩに関する情報を抽出する。また、ＲＰ１００は、抽出したＡＰＩに関する情報に基づいて、異なる種別のＡＰＩに変更するか否かを判断する。ＲＰ１００は、変更すると判断した場合、ＴＤに含まれるＡＰＩに関する情報を所定の種別のＡＰＩの情報に変換するとともに、自装置で使用する認証種別に対応する認証パラメータをＡＰＩの引数として追加することで、ＴＤを更新する。一方、ＲＰ１００は、変更しないと判断した場合、自装置で使用する認証種別に対応する認証パラメータをＡＰＩの引数として追加することで、ＴＤを更新する。その結果、ＲＰ１００は、独自の認証を追加することができるので、セキュリティを向上できる。
【００６９】
また、ＲＰ１００は、クライアント端末９０からデバイス５２に対するリクエストを受け付けると、更新されたＴＤを参照し、リクエストからデバイス５２の認証パラメータと、自装置の認証パラメータと、デバイス５２のＡＰＩの引数とを抽出する。また、ＲＰ１００は、抽出された自装置の認証パラメータに基づいて、認証を行う。また、ＲＰ１００は、抽出されたデバイス５２の認証パラメータと、ＡＰＩの引数と、更新前後のＴＤとに基づいて、ＡＰＩに応じたリクエストを再生成する。また、ＲＰ１００は、再生成されたリクエストをデバイス５２に発信する。その結果、ＲＰ１００は、独自の認証を行いつつ、デバイス５２へのリクエストを発信できる。
【００７０】
また、ＲＰ１００は、ＡＰＩの種別が入力引数を持つ種別である場合、ＡＰＩの種別を変更しないと判断し、自装置で使用する認証種別に対応する認証パラメータをＡＰＩの引数として追加する。その結果、ＲＰ１００は、独自の認証を追加することができる。
【００７１】
また、ＲＰ１００は、ＡＰＩの種別が入力引数を持たない種別である場合、ＡＰＩの種別を変更すると判断する。ＲＰ１００は、ＡＰＩに関する情報を、入力引数を持つ種別のＡＰＩの情報に変換するとともに、自装置で使用する認証種別に対応する認証パラメータをＡＰＩの引数として追加する。その結果、ＲＰ１００は、入力引数を持たないＡＰＩの種別である場合であっても、独自の認証を追加することができる。
【００７２】
また、ＲＰ１００は、ＡＰＩの種別が入力引数を持たず、かつ、プッシュ通知型の種別である場合、ＡＰＩの種別を変更すると判断する。ＲＰ１００は、ＡＰＩの通信プロトコルを双方向通信が可能なプロトコルに変換する。ＲＰ１００は、ＡＰＩに関する情報を、入力引数を持つ種別のＡＰＩの情報に変換するとともに、自装置で使用する認証種別に対応する認証パラメータをＡＰＩの引数として追加する。その結果、ＲＰ１００は、入力引数を持たず、かつ、プッシュ通知型のＡＰＩの種別である場合であっても、独自の認証を追加することができる。
【００７３】
なお、上記実施例では、ＴＤレポジトリ８０をクラウド７０に設けたが、これに限定されない。例えば、ＲＰ１００とクライアント端末９０とからアクセス可能な場所であれば、他のネットワーク上に設けるようにしてもよい。
【００７４】
また、図示した各部の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、ＲＰ１００のＴＤ解釈部１０１とＴＤ書換部１０２とを統合してもよい。また、図示した各処理は、上記の順番に限定されるものでなく、処理内容を矛盾させない範囲において、同時に実施してもよく、順序を入れ替えて実施してもよい。
【００７５】
さらに、各装置で行われる各種処理機能は、ＣＰＵ（またはＭＰＵ、ＭＣＵ（Micro  Controller  Unit）等のマイクロ・コンピュータ）上で、その全部または任意の一部を実行するようにしてもよい。また、各種処理機能は、ＣＰＵ（またはＭＰＵ、ＭＣＵ等のマイクロ・コンピュータ）で解析実行されるプログラム上、またはワイヤードロジックによるハードウェア上で、その全部または任意の一部を実行するようにしてもよいことは言うまでもない。
【００７６】
ところで、上記の各実施例で説明した各種の処理は、予め用意されたプログラムをコンピュータで実行することで実現できる。そこで、以下では、上記の各実施例と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。図１５は、認証プログラムを実行するコンピュータの一例を示す図である。
【００７７】
図１５に示すように、コンピュータ２００は、各種演算処理を実行するＣＰＵ２０１と、データ入力を受け付ける入力装置２０２と、モニタ２０３とを有する。また、コンピュータ２００は、記憶媒体からプログラム等を読み取る媒体読取装置２０４と、各種装置と接続するためのインタフェース装置２０５と、他の情報処理装置等と有線または無線により接続するための通信装置２０６とを有する。また、コンピュータ２００は、各種情報を一時記憶するＲＡＭ２０７と、ハードディスク装置２０８とを有する。また、各装置２０１〜２０８は、バス２０９に接続される。
【００７８】
ハードディスク装置２０８には、図４に示したＴＤ解釈部１０１、ＴＤ書換部１０２、パラメータ抽出部１０６、認証実行部１０７およびリクエスト発信部１０９の各処理部と同様の機能を有する認証プログラムが記憶される。また、ハードディスク装置２０８には、書換情報１０５、認証情報１０８、リクエスト対応情報１１０、および、認証プログラムを実現するための各種データが記憶される。入力装置２０２は、例えば、コンピュータ２００の管理者から操作情報等の各種情報の入力を受け付ける。モニタ２０３は、例えば、コンピュータ２００の管理者に対して表示画面等の各種画面を表示する。インタフェース装置２０５は、例えば印刷装置等が接続される。通信装置２０６は、例えば、ネットワークＮ、ＴＤレポジトリ８０およびクライアント端末９０と接続され、ＬＰ５０、ＴＤレポジトリ８０、クライアント端末９０および他の情報処理装置と各種情報をやりとりする。
【００７９】
ＣＰＵ２０１は、ハードディスク装置２０８に記憶された各プログラムを読み出して、ＲＡＭ２０７に展開して実行することで、各種の処理を行う。また、これらのプログラムは、コンピュータ２００を図４に示したＴＤ解釈部１０１、ＴＤ書換部１０２、パラメータ抽出部１０６、認証実行部１０７およびリクエスト発信部１０９として機能させることができる。
【００８０】
なお、上記の認証プログラムは、必ずしもハードディスク装置２０８に記憶されている必要はない。例えば、コンピュータ２００が読み取り可能な記憶媒体に記憶されたプログラムを、コンピュータ２００が読み出して実行するようにしてもよい。コンピュータ２００が読み取り可能な記憶媒体は、例えば、ＣＤ−ＲＯＭやＤＶＤ（Digital  Versatile  Disc）、ＵＳＢ（Universal  Serial  Bus）メモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリ、ハードディスクドライブ等が対応する。また、公衆回線、インターネット、ＬＡＮ等に接続された装置にこの認証プログラムを記憶させておき、コンピュータ２００がこれらから認証プログラムを読み出して実行するようにしてもよい。
【符号の説明】
【００８１】
１  ＷｏＴ基盤
５０  ローカルプロキシ（ＬＰ）
５１  ゲートウェイ（ＧＷ）
５２  デバイス
５２ａ  ＢＬＥデバイス
５２ｂ  Ｅｃｈｏｎｅｔデバイス
６０，６１  ＴＤ
７０  クラウド
８０  ＴＤレポジトリ
９０  クライアント端末
１００  リモートプロキシ（ＲＰ）
１０１  ＴＤ解釈部
１０２  ＴＤ書換部
１０３  ＵＰ部
１０４  ＷｅｂＡＰＩ
１０５  書換情報
１０６  パラメータ抽出部
１０７  認証実行部
１０８  認証情報
１０９  リクエスト発信部
１１０  リクエスト対応情報
Ｎ，Ｎ１  ネットワーク
【図１】
2020077304.tif 000003
【図２】
2020077304.tif 000004
【図３】
2020077304.tif 000005
【図４】
2020077304.tif 000006
【図５】
2020077304.tif 000007
【図６】
2020077304.tif 000008
【図７】
2020077304.tif 000009
【図８】
2020077304.tif 000010
【図９】
2020077304.tif 000011
【図１０】
2020077304.tif 000012
【図１１】
2020077304.tif 000013
【図１２】
2020077304.tif 000014
【図１３】
2020077304.tif 000015
【図１４】
2020077304.tif 000016
【図１５】
2020077304.tif 000017