JP7363497B2

JP7363497B2 - 制御方法、デバイス及び制御システム

Info

Publication number: JP7363497B2
Application number: JP2020004022A
Authority: JP
Inventors: 洋介中村; 和明二村
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2020-01-14
Filing date: 2020-01-14
Publication date: 2023-10-18
Anticipated expiration: 2040-01-14
Also published as: EP4224988A2; EP3852489B1; EP3852489A2; US11412048B2; EP3852489A3; US11689624B2; US20220321665A1; JP2021111921A; EP4224988A3; US20210218815A1

Description

本発明は、制御方法、デバイス及び制御システムに関する。

Web技術により全てのIoT（Internet of Things）デバイスを扱えるようにするWoT（Web of Things）という概念が、W3C（World Wide Web）により提唱されている。WoTでは、API等のプロファイルを統一形式で記述するためのTD（Thing Description）によるIoTデバイスへのアクセスが可能になる。

また、アプリケーションとIoTデバイスが異なるネットワークに存在する場合、アプリケーションがIoTを扱えるようにするために、ネットワーク間にプロキシが設けられる場合がある。

特開２００７－１１０１８０号公報特開２０１５－５８８９６号公報特開２０１８－１２１３２８号公報

しかしながら、上記の技術では、アプリケーションからIoTデバイスへのアクセスの正当性を検証することが困難な場合があるという問題がある。

例えば、アプリケーションは、IoTデバイスにより発行されたTDを受け取り、当該受け取ったTDに記述された内容に従い、IoTデバイスに宛てたWebリクエストを送信する。このとき、上記のようにアプリケーションとIoTデバイスとの間にプロキシが設けられている場合、Webリクエストがプロキシに向けられるようにするためにTDを書き換えておく必要がある。そして、TDが書き換えられた場合、IoTデバイスは、プロキシを経由したWebリクエストを受け取ることになる。

ここで、初めにIoTデバイスから発行されるTDは、Webリクエストがプロキシを経由することを想定したものではないため、IoTデバイスは、プロキシ経由で送られてきたWebリクエストが正当なものであるか否かを判断することができない場合がある。

１つの側面では、アプリケーションからIoTデバイスへのアクセスの正当性を検証することを目的とする。

１つの態様において、制御方法は、コンピュータに、デバイスの仕様情報を端末装置に送信した後、仕様情報により生成されたリクエストを端末装置から受信すると、リクエストを実行するか否かを判定する処理を実行させる。制御方法は、コンピュータに、リクエストがデバイスに到達するまでに経由した通信装置と、仕様情報が端末装置に到達するまでに経由した通信装置との比較結果に基づき判定する処理を実行させる。

１つの側面では、アプリケーションからIoTデバイスへのアクセスの正当性を検証することができる。

図１は、WoTシステムの各装置の配置例を示す図である。図２は、制御システムの構成例を示すブロック図である。図３は、制御システムの構成例を示すブロック図である。図４は、プロトコルの変更前後のTDの例を示す図である。図５は、認証方式の変更前後のTDの例を示す図である。図６は、変更対象リストの一例を示す図である。図７は、HTTPリクエストの一例を示す図である。図８は、TDの変更処理の流れを示すフローチャートである。図９は、リクエストの検証処理の流れを示すフローチャートである。図１０は、ハッシュ検証履歴が記述されたTDの例を示す図である。図１１は、ハードウェア構成例を説明する図である。

以下に、本発明に係る制御方法、デバイス及び制御システムの実施例を図面に基づいて詳細に説明する。なお、この実施例により本発明が限定されるものではない。また、各実施例は、矛盾のない範囲内で適宜組み合わせることができる。

まず、図１を用いて、WoTを実現するためのWoTシステムについて説明する。図１は、WoTシステムの各機能の配置例を示す図である。システムは、ローカルネットに配置されるIoTデバイス及びインターネットに配置されるWebアプリを有する。

Webアプリは、IoTを直接扱えない場合がある。そのような場合、インターネットとローカルネットの間にあるプロキシが双方のIFの差を吸収する。具体的には、プロキシはIPアドレス及びデータ等の書き換えを行い、また、クライアント機能を有する。IoTデバイスは、プロキシ向けIFを介して、TDをプロキシに受け渡す。

IoTデバイスが出力するTDには、API詳細として、URL in localが記載される。プロキシは、TDを書き換え、Webアプリに受け渡す。書き換えた後のTDには、API詳細として、URL in global等が記載される。また、いずれのTDにも各種の入出力パラメータが記載され得る。

ここで、図１に示すようなシステムにおいては、WebアプリとIoTデバイスとの間の信頼を確保するためには、例えば以下の４つの検知又は検証が行われる必要がある。すなわち、（１）Webアプリとプロキシ間でのTDの不正書き換えの検知、（２）プロキシにおけるTD書き換えの正当性の検証、（３）書き換え以前のTDの正当性の検証、（４）Webアクセスの信頼性の検証である。

１つの側面では、本実施例は上記の検知及び検証を行うことを目的とするものである。特に、本実施例によれば、従来の技術では困難であった上記の（２）と（４）の検証を行うことができる。

［機能構成］
図２及び図３を用いて、実施例に係る制御システム１の構成を説明する。図２及び図３は、制御システムの構成例を示すブロック図である。図２及び図３に示すように、制御システム１は、デバイス１０、プロキシ２０及び端末装置３０を有する。

デバイス１０は、例えば自動車、家電、ウェアラブル装置、センサ等のIoTデバイスである。プロキシ２０は、例えばプロキシ機能を備えたサーバである。端末装置３０は、Webアプリのクライアントとして機能する端末である。また、端末装置３０は、Webアプリを提供するサーバであってもよい。なお、制御システム１の各装置は、図１で示したシステムの各装置と同様の機能を有するものとする。

図２は、デバイス１０が端末装置３０にTDを送信する際に使用される各装置の機能を処理部として表している。一方、図３は、端末装置３０がデバイス１０に対しWebアクセスをする際に使用される各装置の機能を処理部として表している。

（TDの送信）
まず、デバイス１０がTDを送信する際に使用される各処理部について説明する。図２に示すように、プロキシ２０は、ハッシュ検証部２０１、検証履歴記述部２０２、変更部２０３、変更履歴記述部２０４、生成部２０５及び変更対象リスト２０６を有する。また、端末装置３０は、TD取得部３０１、ハッシュ検証部３０２、検証履歴検証部３０３、変更対象取得部３０４及び変更履歴検証部３０５を有する。

デバイス１０は、TD５０１を端末装置３０に宛てて送信する。デバイス１０は、任意のタイミングでTDを送信することができる。例えば、デバイス１０は、デバイス１０がネットワークに追加された際に自動的にTDを送信してもよいし、手動で操作されることによりTDを送信してもよいし、端末装置３０やプロキシ２０等の他の装置からの要求に応じてTDを送信してもよい。このとき、TD５０１は、デバイス１０と端末装置３０との間の通信経路上にあるプロキシ２０によって受信される。ハッシュ検証部２０１は、デバイス１０によって送信されたTD５０１のハッシュを検証する。検証履歴記述部２０２は、ハッシュ検証部２０１によってTD５０１が正当なものであると検証された場合、検証履歴をTD５０１に記述する。

変更部２０３は、TD５０１が端末装置３０によって受信される前に、TD５０１の内容を変更する。また、変更履歴記述部２０４は、TD５０１に、変更する処理による変更の内容を変更履歴として記述する。TD５０２は、変更履歴記述部２０４によってTD５０１に変更履歴が記述されたものである。なお、TDは仕様情報の一例である。また、TD５０１は、デバイス１０によって端末装置３０に宛てて送信されるTDであって、端末装置３０によってデバイス１０に宛てて送信されるリクエストに関する情報が記述されたTDである。なお、リクエストには、HTTPリクエスト等のWebリクエストが含まれる。

例えば、プロキシ２０がWebsocketに非対応であって、HTTPに対応している場合、変更部２０３は、TD５０１に記述されたAPIのプロトコルをWebsocketからHTTPに書き換えることができる。その際、変更履歴記述部２０４は、プロトコルが書き換えられたことを変更履歴としてTD５０１に記述する。

図４は、プロトコルの変更前後のTDの例を示す図である。TD５０１は、プロキシ２０によって受信された時点のTDである。TD５０２は、検証履歴記述部２０２による検証履歴の記述、変更部２０３による内容の変更、及び変更履歴記述部２０４による変更履歴の記述が行われた後のTDである。

ここで、TDに含まれるdescriptionタグの値は、オブジェクトを要素とする配列である。また、オブジェクトは、１つ以上の"key":"value"の組を持つものとする。また、descriptionタグは、Human Readable情報、すなわち人間が読み取り可能な情報を記述するためのタグの一例である。

検証履歴記述部２０２は、descriptionタグの配列の第１要素に、TD提供元を示すオブジェクト、及びハッシュ確認者を示すオブジェクトを記述する。ハッシュ確認者は、ハッシュ確認を行った主体であり、プロキシ等の装置である。

図４のTD５０２の「"source":"sensor1"」は、TD提供元を示すオブジェクトである。当該オブジェクトは、TD提供元、すなわち「source」が「sensor1」であることを示している。なお、「sensor1」はデバイス１０を識別するための文字列である。

図４のTD５０２の「"checker":"Lproxy"」は、ハッシュ確認者を示すオブジェクトである。当該オブジェクトは、ハッシュ確認者、すなわち「checker」が「Lproxy」であることを示している。なお、「Lproxy」はプロキシ２０を識別するための文字列である。なお、TDに検証履歴が記述されていることは、正当性が検証されたことを示している。このため、検証履歴記述部２０２は、正当であったか否かを明示的に記述する必要はない。

変更部２０３は、hrefタグの値を変更することで、プロトコルを書き換える。図４に示すように、変更部２０３は、hrefタグの値を「ws://xxx/get_temp」から「http://xxx/get_temp」に書き換える。

変更履歴記述部２０４は、descriptionタグの配列の第２要素に、TDの変更を行った変更者を示すオブジェクト、変更前の情報を示すオブジェクト、及び変更後の情報を示すオブジェクトを記述する。TDの変更を行った変更者は、TDの変更を行った主体であり、プロキシ等の装置である。

図４のTD５０２の「"place":"Rproxy"」は、TDの変更を行った変更者を示すオブジェクトである。当該オブジェクトは、変更者、すなわち「place」が「Rproxy」であることを示している。なお、「Rproxy」はプロキシ２０を識別するための文字列である。

図４のTD５０２の「"orig-p":"websocket"」は、変更前の情報を示すオブジェクトである。当該オブジェクトは、変更前のプロキシ、すなわち「orig-p」が「websocket」であることを示している。

図４のTD５０２の「"modify-p":"http"」は、変更後の情報を示すオブジェクトである。当該オブジェクトは、変更後のプロキシ、すなわち「modify-p」が「http」であることを示している。

このように、変更履歴記述部２０４は、人間が読み取り可能な情報を記述するためのタグの値に、変更する処理による変更の内容及び変更した値に対応するタグを特定する情報を記述する。

変更部２０３は、TDに含まれるタグに対応する値のうちの少なくともいずれかを変更することができる。変更部２０３が値を変更するタグは、hrefタグに限られない。例えば、変更部２０３は、認証方式を表すsecurityタグの値を変更してもよい。

図５は、認証方式の変更前後のTDの例を示す図である。図５の例では、変更部２０３は、securityタグの値を「{"schema":"nosec"}」から「{"schema":"basic"}」に書き換える。TD５０２ａは、検証履歴記述部２０２による検証履歴の記述、変更部２０３による内容の変更、及び変更履歴記述部２０４による変更履歴の記述が行われた後のTDである。

図５のTD５０２ａの「"place":"Rproxy"」は、TDの変更を行った変更者を示すオブジェクトである。当該オブジェクトは、変更者、すなわち「place」が「Rproxy」であることを示している。

図５のTD５０２ａの「"orig-p":"nosec"」は、変更前の情報を示すオブジェクトである。当該オブジェクトは、変更前の認証方法、すなわち「orig-p」が「nosec」であることを示している。

図５のTD５０２ａの「"modify-p":"basic"」は、変更後の情報を示すオブジェクトである。当該オブジェクトは、変更後の認証方法、すなわち「modify-p」が「basic」であることを示している。

図２に戻り、生成部２０５は、変更履歴記述部２０４によって変更履歴が記述されたTD５０２のハッシュを生成する。プロキシ２０は、TD５０２をハッシュとともに端末装置３０に送信する。

端末装置３０のTD取得部３０１は、TD５０２を取得する。ハッシュ検証部３０２は、デバイス１０によって送信されたTD５０２のハッシュを検証する。また、検証履歴検証部３０３は、プロキシ等で行われたハッシュの検証の正当性を検証する。検証履歴検証部３０３は、TD５０２のハッシュ検証履歴を基に、プロキシ２０によって行われたハッシュ検証の正当性を検証する。

変更履歴検証部３０５は、TDに記述された変更履歴が示す変更の内容が、あらかじめ許可された変更の内容と一致するか否かを検証する。変更対象取得部３０４は、プロキシ２０から変更対象リスト２０６を取得する。変更対象リスト２０６は、変更が許可されているタグ及び変更の内容を規定した情報である。変更対象リスト２０６は、プロキシ２０ではなく、端末装置３０又は他の装置によって保持されていてもよい。

図６は、変更対象リストの一例を示す図である。図６に示すように、変更対象リスト２０６には、値の変更が許可されたタグの名称が少なくとも含まれ、変更の内容がさらに含まれていてもよい。「{"tag":"href"}」は、hrefタグの値の変更が許可されていることを示している。また、「{"tag":"href","rewrite":"http"}」は、hrefタグによって示されるプロトコルを「http」に変更することが許可されていることを示している。

（Webアクセス）
次に、端末装置３０がデバイス１０に対してWebアクセスをする際に使用される各処理部について説明する。図３に示すように、デバイス１０は、TD取得部１５１、判定部１５２、提供部１５３及び認証部１５４を有する。また、プロキシ２０は、要求部２５１、経路情報記述部２５２、再構成部２５３、提供部２５４及び認証部２５５を有する。また、端末装置３０は、要求部３５１を有する。

まず、端末装置３０の要求部３５１は、デバイス１０に宛ててリスエストを送信する。プロキシ２０の提供部２５４は、Webサーバとして機能する。つまり、提供部２５４は、要求部３５１によって送信されたリクエストを受信する。また、認証部２５５は、提供部２５４が受信したリクエストの認証を行う。再構成部２５３は、URLの変換等によりリクエストを再構成する。

ここで、経路情報記述部２５２は、経路に関する情報をリクエストに記述する。図７に示すように、経路情報記述部２５２は、HTTPリクエストに情報を記述する。図７は、HTTPリクエストの一例を示す図である。

経路情報記述部２５２は、情報を記述するための独自パラメータをリクエストに追加する。このとき、経路情報記述部２５２は、HTTPリクエストのヘッダにパラメータを入れる場合の慣例に従い、「X-」から始まるキーを設定する。図７に示すように、経路情報記述部２５２は、キーが「X-Auth-History」であるパラメータをHTTPリクエストのヘッダに追加する。

経路情報記述部２５２は、例えば認証場所及び認証方式を記述する。図７のパラメータ「X-Auth-History」のオブジェクトのうち「{"place":"Rproxy","method":"basic"}」は、認証場所が「Rproxy」であり、認証方式が「basic」であることを示している。また、HTTPリクエストが複数のプロキシを経由した場合、経路情報記述部２５２は、パラメータ「X-Auth-History」にさらにオブジェクトを追加する。「{"place":"Lproxy","method":"nosec"}」は、認証場所が「Lproxy」であり、認証方式が「nosec」であることを示している。なお、「nosec」は、認証がないことを示している。

要求部２５１は、クライアントとして機能する。つまり、要求部２５１は、再構成部２５３によって再構成され、経路情報記述部２５２によって記述が行われたリクエストをデバイス１０に送信する。

デバイス１０の提供部１５３は、Webサーバとして機能する。つまり、提供部１５３は、プロキシ２０の要求部２５１によって送信されたリクエストを受信する。また、認証部１５４は、提供部１５３が受信したリクエストの認証を行う。

TD取得部１５１は、端末装置３０によってデバイス１０に宛てて送信されるリクエストの通信経路をあらかじめ定義したTDを取得する。ここで、TD取得部１５１が取得するTDは、端末装置３０が取得したTDと同じものである。つまり、TD取得部１５１は、TD５０２をプロキシ２０を取得する。

TD取得部１５１は、端末装置３０によってデバイス１０に送信されるリクエストのヘッダに記述された所定のパラメータを読み取ることによりTDを取得する。例えば、図７に示すように、HTTPリクエストには、通信経路上のプロキシ２０を特定する情報である「place」及び各プロキシ２０における認証方式である「method」が少なくとも記述されている。TD取得部１５１は、HTTPリクエストから読み取った情報を基にプロキシ２０に接続し、TD５０２を取得する。

判定部１５２は、デバイス１０のTDを端末装置３０に送信した後、TDにより生成されたリクエストを端末装置３０から受信すると、リクエストを実行するか否かを判定する。判定部１５２は、リクエストがデバイス１０に到達するまでに経由した通信装置と、TDが端末装置３０に到達するまでに経由した通信装置との比較結果に基づき判定する。TDは、TD取得部１５１によって取得される。リクエストは、プロキシ２０によって送信され、提供部１５３によって受信される。

図７に示すように、HTTPリクエストには、「Lproxy」を少なくとも経由したことが示されている。また、図４に示すように、TD５０２にも、「Lproxy」を少なくとも経由したことが示されている。この場合、判定部１５２は、通信経路上の少なくとも一部のプロキシが一致しているため、リクエストを実行すると判定する。

判定部１５２は、第１のリクエストが経由した通信経路と、TD取得部１５１によって取得されたTDによって定義された通信経路との少なくとも一部が一致する場合にリクエストを実行すると判定してもよい。また、判定部１５２は、第１のリクエストが経由した通信経路と、TD取得部１５１によって取得されたTDによって定義された通信経路とが完全一致する場合にリクエストを実行すると判定してもよい。

［処理の流れ］
図８を用いて、TDの送信時におけるTDの変更処理の流れを説明する。図８は、TDの変更処理の流れを示すフローチャートである。まず、デバイス１０はTDのハッシュを生成する（ステップＳ１０１）。次に、プロキシ２０がTDを取得する（ステップＳ１０２）。そして、プロキシ２０はハッシュを検証する（ステップＳ１０３）。ここで、プロキシ２０は、ハッシュ検証履歴をTDに付与する（ステップＳ１０４）。

プロキシ２０は、TDを書き換える（ステップＳ１０５）。例えば、プロキシ２０は、プロトコル及び認証方式等を書き換える。そして、プロキシ２０は、変更履歴をTDに記述する（ステップＳ１０６）。さらに、プロキシ２０は、書き換え及び変更履歴の記述が行われたTDのハッシュを生成する（ステップＳ１０７）。

端末装置３０、すなわちアプリは、プロキシ２０からTDを取得する（ステップＳ１０８）。ここで、端末装置３０は、取得したTDのハッシュを検証する（ステップＳ１０９）。さらに、端末装置３０は、ハッシュ履歴を検証する（ステップＳ１１０）。そして、端末装置３０は、変更対象リストを取得（ステップＳ１１１）し、変更履歴と変更対象リストの一致を確認する（ステップＳ１１２）。

図９を用いて、Webアクセス時におけるリクエストの検証処理を説明する。図９は、リクエストの検証処理の流れを示すフローチャートである。まず、端末装置３０、すなわちアプリがプロキシ２０へWebリクエストを送信する（ステップＳ２０１）。

プロキシ２０は、リクエストを受信し（ステップＳ２０２）、認証を行う（ステップＳ２０３）。さらに、プロキシ２０は、URL変換等によりリクエストを再構成する（ステップＳ２０４）。

そして、プロキシ２０は、プロキシID、認証情報を経路履歴としてリクエストに付加する（ステップＳ２０５）。プロキシ２０は、デバイス１０へリクエストを送信する（ステップＳ２０６）。

デバイス１０は、リクエストを受信し（ステップＳ２０７）、認証を行う（ステップＳ２０８）。ここで、デバイス１０は、プロキシ２０からアプリが取得したTDを取得する（ステップＳ２０９）。そして、デバイス１０は、取得したTDのハッシュ履歴及び変更履歴と、リクエストに記述された経路履歴とを比較し一致を確認する（ステップＳ２１０）。

［効果］
判定部１５２は、デバイス１０のTDを端末装置３０に送信した後、仕様情報により生成されたリクエストを端末装置３０から受信すると、リクエストを実行するか否かを判定する。判定部１５２は、リクエストがデバイス１０に到達するまでに経由した通信装置と、TDが端末装置３０に到達するまでに経由した通信装置との比較結果に基づき判定する。このように、IoTデバイスであるデバイス１０は、アプリケーションを実行する端末装置３０によって送信されるリクエストの実際の通信経路と書き換え済みのTDに基づく通信経路とを比較する。この結果、実施例１によれば、アプリケーションからIoTデバイスへのアクセスの正当性を検証することができる。つまり、実施例１によれば、Webアクセスの信頼性の検証が可能になる。

変更部２０３は、デバイス１０によって端末装置３０に宛てて送信されるTDであって、端末装置３０によってデバイス１０に宛てて送信されるリクエストに関する情報が記述されたTDが端末装置３０によって受信される前に、TDの内容を変更する。変更履歴記述部２０４は、TDに、変更する処理による変更の内容を変更履歴として記述する。変更履歴検証部３０５は、TDに記述された変更履歴が示す変更の内容が、あらかじめ許可された変更の内容と一致するか否かを検証する。このように、端末装置３０は、TD自体の記述内容を基にTDの正当性を検証することができる。この結果、実施例１によれば、プロキシにおけるTD書き換えの正当性の検証が可能になる。

判定部１５２は、リクエストがデバイス１０に到達するまでに経由した通信装置と、パラメータを読み取ることにより取得したTDに定義された、TDが端末装置３０に到達するまでに経由した通信装置と、の比較結果に基づきリクエストを実行するか否かを判定する。パラメータは、端末装置３０によってデバイス１０に送信されるリクエストのヘッダに記述されたものである。パラメータには、所定の通信経路上のプロキシを特定する情報及び各プロキシにおける認証方式が少なくとも記述されている。これにより、デバイス１０は、プロキシ２０に接続し、TDを取得することができる。

変更部２０３は、TDに含まれるタグに対応する値のうちの少なくともいずれかを変更する。変更履歴記述部２０４は、人間が読み取り可能な情報を記述するためのタグの値に、変更する処理による変更の内容及び変更した値に対応するタグを特定する情報を記述する。このように、プロキシ２０は、例えばdescriptionタグの値に情報を記述する。この結果、実施例１によれば、既存のTDのフォーマットを変更することなく、検証のための情報を追記することが可能になる。

なお、上述の例では、デバイス１０と端末装置３０との間のプロキシは１つであった。一方で、デバイス１０と端末装置３０との間のプロキシは１つであっても複数であってもよい。つまり、端末装置３０とデバイス１０との間の通信経路上に備えられた１つ以上のプロキシ２０が変更する処理を実行する。そして、各プロキシの変更履歴記述部２０４は、TDに、変更する処理による変更の内容及び当該変更を行ったプロキシを特定する情報を変更履歴として記述する。

ここで、一例として、デバイス１０と端末装置３０との間に第１のプロキシと第２のプロキシが存在する場合のTDの変更処理について説明する。端末装置３０とデバイス１０との間の通信経路上に備えられた第１のプロキシが、変更する処理及び記述する。さらに、第１のプロキシが、記述する処理によって変更の内容が記述されたTDからハッシュを生成する処理をさらに実行する。そして、通信経路上に備えられた第２のプロキシが、第１のプロキシによって生成されたハッシュの正当性を検証し、さらに検証結果をTDに記述する。

図１０は、ハッシュ検証履歴が記述されたTDの例を示す図である。この場合、各プロキシは、Key値にナンバリングして区別をつける。例えば、第１のプロキシはKey値として「source」及び「checker」を使う。そして、第２のプロキシはKey値として「source2」及び「checker2」を使う。

［システム］
上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。また、実施例で説明した具体例、分布、数値等は、あくまで一例であり、任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。さらに、各装置にて行われる各処理機能は、その全部又は任意の一部が、CPU及び当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

［ハードウェア］
図１１は、ハードウェア構成例を説明する図である。図１１に示すように、デバイス１０は、通信インタフェース１０ａ、HDD（Hard Disk Drive）１０ｂ、メモリ１０ｃ、プロセッサ１０ｄを有する。また、図１１に示した各部は、バス等で相互に接続される。また、プロキシ２０及び端末装置３０も同様に、図１１に示すようなハードウェア構成を有していてもよい。

通信インタフェース１０ａは、ネットワークインタフェースカード等であり、他のサーバとの通信を行う。HDD１０ｂは、図３に示した機能を動作させるプログラムやDBを記憶する。

プロセッサ１０ｄは、図３に示した各処理部と同様の処理を実行するプログラムをHDD１０ｂ等から読み出してメモリ１０ｃに展開することで、図３等で説明した各機能を実行するプロセスを動作させるハードウェア回路である。すなわち、このプロセスは、デバイス１０が有する各処理部と同様の機能を実行する。具体的には、プロセッサ１０ｄは、TD取得部１５１、判定部１５２、提供部１５３及び認証部１５４と同様の機能を有するプログラムをHDD１０ｂ等から読み出す。そして、プロセッサ１０ｄは、TD取得部１５１、判定部１５２、提供部１５３及び認証部１５４等と同様の処理を実行するプロセスを実行する。

このようにデバイス１０は、プログラムを読み出して実行することで学習類方法を実行する情報処理装置として動作する。また、デバイス１０は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、デバイス１０によって実行されることに限定されるものではない。例えば、他のコンピュータ又はサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。

このプログラムは、インターネット等のネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（FD）、CD-ROM、MO（Magneto－Optical disk）、DVD（Digital Versatile Disc）等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することができる。

１制御システム
１０デバイス
２０プロキシ
３０端末装置
１５１ TD取得部
１５２判定部
１５３提供部
１５４認証部
２０１ハッシュ検証部
２０２検証履歴記述部
２０３変更部
２０４変更履歴記述部
２０５生成部
２０６変更対象リスト
２５１要求部
２５２経路情報記述部
２５３再構成部
２５４提供部
２５５認証部
３０１ TD取得部
３０２ハッシュ検証部
３０３検証履歴検証部
３０４変更対象取得部
３０５変更履歴検証部
３５１要求部
５０１、５０２、５０２ａ TD

Claims

デバイスが実行する制御方法において、
前記デバイスの仕様情報を端末装置に送信した後、前記仕様情報により生成された第１のリクエストを前記端末装置から受信すると、前記第１のリクエストが前記デバイスに到達するまでに経由した通信装置と、前記仕様情報が前記端末装置に到達するまでに経由した通信装置との比較結果に基づき、前記第１のリクエストを実行するか否かを判定する
処理をコンピュータが実行することを特徴とするデバイスの制御方法。
デバイスと端末装置とを有するシステムを制御する制御方法であって、
前記デバイスによって前記端末装置に宛てて送信される前記デバイスの仕様情報であって、前記端末装置によって前記デバイスに宛てて送信されるリクエストに関する情報が記述された仕様情報が前記端末装置によって受信される前に、前記仕様情報の内容を変更し、
前記仕様情報に、前記変更する処理による変更の内容を変更履歴として記述し、
前記仕様情報に記述された前記変更履歴が示す変更の内容が、あらかじめ許可された変更の内容と一致するか否かを検証し、
前記デバイスが、前記仕様情報を端末装置に送信した後、前記仕様情報により生成された第２のリクエストを前記端末装置から受信すると、前記第２のリクエストが前記デバイスに到達するまでに経由した通信装置と、前記仕様情報が前記端末装置に到達するまでに経由した通信装置との比較結果に基づき、前記第２のリクエストを実行するか否かを判定する
処理をコンピュータが実行することを特徴とする制御方法。
前記判定する処理は、前記第１のリクエストが前記デバイスに到達するまでに経由した通信装置と、前記端末装置によって前記デバイスに送信されるリクエストのヘッダに記述された所定のパラメータであって、通信経路上のプロキシを特定する情報及び各プロキシにおける認証方式が少なくとも記述されたパラメータを読み取ることにより取得された前記仕様情報に定義された前記仕様情報が前記端末装置に到達するまでに経由した通信装置と、の比較結果に基づき、前記第１のリクエストを実行するか否かを判定することを特徴とする請求項１に記載のデバイスの制御方法。
前記変更する処理は、前記仕様情報に含まれるタグに対応する値のうちの少なくともいずれかを変更し、
前記記述する処理は、人間が読み取り可能な情報を記述するためのタグの値に、前記変更する処理による変更の内容及び変更した値に対応するタグを特定する情報を記述することを特徴とする請求項２に記載の制御方法。
前記端末装置と前記デバイスとの間の通信経路上に備えられた１つ以上のプロキシが前記変更する処理を実行し、
前記記述する処理は、前記仕様情報に、前記変更する処理による変更の内容及び当該変更を行ったプロキシを特定する情報を変更履歴として記述することを特徴とする請求項２又は４に記載の制御方法。
前記端末装置と前記デバイスとの間の通信経路上に備えられた第１のプロキシが、前記変更する処理及び前記記述する処理を実行し、
前記第１のプロキシが、前記記述する処理によって前記変更の内容が記述された前記仕様情報からハッシュを生成する処理をさらに実行し、
前記通信経路上に備えられた第２のプロキシが、前記生成する処理によって生成されたハッシュの正当性を検証し、検証結果を前記仕様情報に記述する処理を実行することを特徴とする請求項２、４又は５に記載の制御方法。
端末装置からのリクエストを受信するデバイスであって、
前記デバイスの仕様情報を前記端末装置に送信した後、前記仕様情報により生成された第１のリクエストを前記端末装置から受信すると、前記第１のリクエストが前記デバイスに到達するまでに経由した通信装置と、前記仕様情報が前記端末装置に到達するまでに経由した通信装置との比較結果に基づき、前記第１のリクエストを実行するか否かを判定する判定部と、
を有することを特徴とするデバイス。
端末装置と、デバイスと、前記端末装置と前記デバイスとの間の通信経路上に備えられたプロキシと、を有する制御システムであって、
前記デバイスは、
前記デバイスの仕様情報を前記端末装置に送信した後、前記仕様情報により生成された第１のリクエストを前記端末装置から受信すると、前記第１のリクエストが前記デバイスに到達するまでに経由した通信装置と、前記仕様情報が前記端末装置に到達するまでに経由した通信装置との比較結果に基づき、前記第１のリクエストを実行するか否かを判定する判定部と、
を有することを特徴とする制御システム。