以下、本発明の実施の形態について説明する。
図1は、本発明の一実施形態に係るIoTリソース管理システム1の構成例を示す図である。
図1に示すIoTリソース管理システム1は、API2aを有するデバイス2を所有する一次利用者と、デバイス2が備える機能(IoTリソース)を二次利用する二次利用者との間にデバイス管理装置10が設けられた構成を有する。
一次利用者は、1個以上のデバイス2を所有しており、所有するデバイス2をデバイス管理装置10に登録する。そして、一次利用者は、登録したデバイス2を用いて、所定のイベントの発生に対応してイベント通知などを行うアプリケーションを利用する。
デバイス2に対しては、デバイス2が備えるAPI2aを介してデータの送受信が行われる。API2aは、デバイス2が備える機能ごとに規定されており、外部からAPI2aに対して制御メッセージを送信することで、デバイス2に所定の動作を行わせることができる。例えば、デバイス2がサーモスタットである場合、サーモスタットが設置された部屋の現在の室温を要求元へ通知するセンシング機能、デバイス2が冷暖房器具である場合、冷温風を送風するアクチュエータ機能などがAPI2aとして規定される。
二次利用者は、IoTリソースの利用を要求するリソース要求をデバイス管理装置10に入力し、リソース要求に応じて提供されたIoTリソースを用いて所望のアプリケーションを実行する。二次利用者の具体例としては、例えば、世界中の「暑い部屋」をリアルタイムに把握した上で、その部屋の住人に清涼飲料水の広告を通知したい広告事業者や、「詳細な室温情報」を「定期的に」把握した上で、インフルエンザの推定罹患者に受診を促す広告を通知したい医療事業者などが想定される。リソース要求では主に、取得したいデータ、行いたい動作、通信のタイミングなどが指定される。
デバイス管理装置10は、一次利用者が所有するデバイス2を管理し、二次利用者からのリソース要求に応じてIoTリソースを二次利用者に提供する。以下では、デバイス管理装置10の構成について、より詳細に説明する。なお、図1において、太線矢印はデータの入出力を示し、実線矢印は制御信号の入出力を示し、破線矢印は一次利用者あるいは二次利用者による入力を示す。
図1に示すデバイス管理装置10は、デバイス管理部11と、アプリケーション設定部12と、コンテキスト解析部13と、デバイス管理DB14と、要求解釈部(要求取得部)15と、二次利用コントローラ管理部16と、二次利用ポインタDB17とを備える。なお、図1においては、デバイス管理装置10が、上述した各構成を備える例を示しているが、これに限られるものではなく、各構成は個別の装置として分散して設けられてもよい。また、詳細は後述するが、デバイス管理部11、アプリケーション設定部12、コンテキスト解析部13およびデバイス管理DB14は主に、一次利用者によるデバイス2の利用(一次利用)に関する機能ブロックであり、以下では、これらの機能ブロックを総称して一次利用機能ブロック群と称することがある。また、要求解釈部15、二次利用コントローラ管理部16および二次利用ポインタDB17は、二次利用者によるデバイス2の利用(二次利用)に関する機能ブロックであり、以下では、これらの機能ブロックを総称して、二次利用機能ブロック群と称することがある。
デバイス管理部11は、一次利用者からのデバイス2の登録に応じて、デバイス2を所有する一次利用者と、登録されたデバイス2と、そのデバイス2が備えるAPI2aとを対応付けて、デバイス管理DB14に記録する。また、デバイス管理部11は、一次利用者からの入力に応じて、デバイス2が備えるAPI2aに制御メッセージを送信したり、アプリケーション設定部12を利用して任意のアプリケーションを作成したりする。また、デバイス管理部11は、二次利用コントローラ管理部16と連携しており、二次利用コントローラ管理部16が生成した二次利用コントローラ161から指定されたデバイス2のAPI2aに対して、センシングやアクチュエーションのための制御メッセージを送信することで、デバイス2を制御することができる。
アプリケーション設定部12は、一次利用者が所有するデバイス2を用いたアプリケーション121(アプリケーションプログラム)が設定される。アプリケーション121としては、一次利用者自身により詳細に設定されたアプリケーション、第三者により作成され、設定済みのアプリケーションなどがある。
図2A〜2Cは、アプリケーション121の構成例を示す図である。図2A〜2Cに示すように、アプリケーション121は、デバイス2のAPI2aに接続したコントローラ122が制御メッセージを伝達する構成を有する。図2Aでは、1つのデバイス2のAPI2aとアプリケーション121のコントローラ122とが通信を行う例を示している。図2Bでは、あるデバイス2のAPI2aとインプットコントローラ122aとが通信を行い、別のデバイス2のAPI2aとアウトプットコントローラ122bとが通信を行い、さらに、インプットコントローラ122aとアウトプットコントローラ122bとの間の制御ルールが設定された例を示している。また、図2Cでは、複数のコントローラ122がそれぞれ異なるデバイス2のAPI2aと通信を行い、さらに、コントローラ122間のメッセージングフローが設定された例を示している。
アプリケーション121としては、複数のデバイス2(例えば、サーモスタットおよび冷暖房器具)のAPI2aを使って、「室温が26℃以上になったら」「冷房機能をONにする」という、イベントの発生に応じて所定の動作を実行するアプリケーションが設定可能である。また、アプリケーション121に用いられるAPIは、デバイス2のAPI2aだけでなく、Webサービスが備えるAPIを含んでいてもよい。この場合、例えば、「室温が26℃以上になったら」「SNSに“暑い”とつぶやく」といった動作を行うアプリケーション121を設定することも可能である。
図1を再び参照すると、アプリケーション設定部12は、設定されたアプリケーション121の構成情報(アプリケーション構成情報)およびイベント情報をコンテキスト解析部13に出力する。アプリケーション構成情報とは、アプリケーション121で利用されるデバイス2の製品情報、デバイス2が備えるAPI2a、API2aに送信される制御メッセージ、一次利用者が設定したラベルなどを示す情報である。また、これらの情報を機械学習により解析して得られる情報がアプリケーション構成情報に含まれてもよい。イベント情報とは、アプリケーション121に設定された条件に基づいて通知されるリアルタイムな情報である。
コンテキスト解析部13は、アプリケーション設定部12に設定されたアプリケーション121に基づき、デバイス2の利用態様を示すコンテキストを生成する。具体的には、コンテキスト解析部13は、アプリケーション設定部12から出力されたアプリケーション構成情報を解析し、アプリケーション121毎に、アプリケーション121に用いられるデバイス2の利用方法や利用環境といった利用態様を示すコンテキストを生成する。そして、コンテキスト解析部13は、コンテキストハンドラ131というプロセスを生成する。コンテキストハンドラ131は、アプリケーション構成情報を解析して得られたデバイス2のコンテキストを、イベント情報が通知されたときに、デバイス管理DB14の該当するデバイス2のエントリに反映させる役割を有する。コンテキストには有効期限が定められており、有効期限を超過すると、コンテキスト解析部13は、そのコンテキストを削除する。なお、デバイス管理DB14の1つのエントリには複数のコンテキストを設定することができるが、対称的なコンテキストの場合には、新しいコンテキストが採用される。
例として、前述したサーモスタットおよび冷暖房器具の連携アプリケーションを考える。このアプリケーションには、一次利用者によって、「部屋が暑くなったら冷房を点ける」というラベルが設定されているとする。コンテキスト解析部13は、このラベルから「暑い部屋」、「冷房を点ける」というコンテキストを解析し、コンテキストハンドラ131を生成する。サーモスタットのAPI「温度計測」による測定結果が26℃以上であったときに、イベント情報が通知されるとすると、コンテキスト解析部13は、サーモスタットのAPI「温度計測」が、「26℃以上」という特定の場合のみ「暑い部屋」というコンテキストを有すると解析する。このコンテキストは、有効期限の経過、もしくは、対称的なコンテキスト(「寒い部屋」)が取得されると、無効となる。
デバイス管理DB14は、ポインタと、デバイス2を所有する一次利用者のユーザ名と、デバイス2のアドレスと、デバイス名と、デバイス2が備えるAPI2aのAPI名と、API2aのコンテキストとをエントリに持つデータベースである。デバイス管理DB14は、デバイス管理部11からの登録に加えて、コンテキスト解析部13からコンテキストの登録を受け付ける。この際、デバイス管理DB14は、登録されたデバイス2が備えるAPI2aのコンテキストとしての追加属性を付与する。例えば、デバイス管理DB14は、事前にデバイス管理部11によりサーモスタットが登録されている場合、コンテキストの登録において、サーモスタットのAPI「温度計測」に「部屋が暑い」という属性を論理的に追加する。この属性は、コンテキスト解析部13からの通知を受けてリアルタイムに変動する。
要求解釈部15は、二次利用者からリソース要求を取得し、取得したリソース要求をデバイス管理装置10で認識可能な形式に整形して、二次利用コントローラ管理部16に出力する。二次利用者からの要求としては、二次利用の形式を指定する利用形式、検索対象となるキー(コンテキストまたはAPI名)、通信のタイミングを取り決めるスケジュール設定、デバイス管理装置10との相互通信を取り決めるエンドポイント設定がある。要求解釈部15は、整形後のリソース要求を二次利用コントローラ管理部16に出力する。
例えば、二次利用者が前述した広告事業者である場合、リソース要求は、利用形式「間接センサ」、キー「コンテキスト:暑い部屋」、スケジュール設定「リアルタイム」、エンドポイント設定「二次利用者側のデータ受付アドレス」となる。なお、二次利用者は要求の内容を自然言語で入力し、要求解釈部15が、自然言語で入力された要求の内容を解析して、リソース要求として取得してもよい。
二次利用コントローラ管理部16は、要求解釈部15からリソース要求(認識可能な形式に整形されたリソース要求)が入力されると、デバイス2の二次利用を実行する二次利用コントローラ161を生成する。そして、二次利用コントローラ管理部16は、生成した二次利用コントローラ161に対応するエントリを二次利用ポインタDB17に生成し、リソース要求に含まれるキーを生成したエントリに登録する。例えば、利用形式「間接センサ」、キー「コンテキスト:暑い部屋」を含むリソース要求が入力されると、二次利用コントローラ管理部16は、新しい二次利用コントローラ161を生成し、生成した二次利用コントローラ161に対応するエントリを二次利用ポインタDB17に生成する。また、二次利用コントローラ管理部16は、リソース要求に含まれるキー「コンテキスト:暑い部屋」を生成したエントリに登録する。
二次利用ポインタDB17は、二次利用ポインタと、キーと、デバイス管理DBポインタとを対応付けて記憶するデータベースである。二次利用ポインタDB17は、二次利用コントローラ161毎に生成されたエントリで構成される。1つのエントリは、二次利用コントローラ161を識別するための二次利用ポインタと、二次利用者からの要求に対応するキーと、そのキーによって検索されたデバイス管理DB14のエントリのポインタ(デバイス管理DBポインタ)のリストとを含む。デバイス管理DBポインタのリストは、二次利用コントローラ161がスケジュール設定に従って検索を行うたびに更新される。デバイス管理DBポインタを参照することで、二次利用コントローラ161は、対応するデバイス管理DB14のエントリの前回の検索時の値を取得することができる。
次に、二次利用コントローラ161について説明する。
図3は、二次利用コントローラ161の構成例を示す図である。
図3に示すように、二次利用コントローラ161は、二次利用ポインタ162と、スケジューラ163と、エンドポイント164とを備える。
二次利用ポインタ162には、二次利用ポインタDB17において二次利用コントローラ161を識別するための二次利用ポインタが格納される。スケジューラ163は、リソース要求に含まれるスケジュール設定が格納される。なお、スケジュール設定としては、センシングやアクチュエーションを行う時間間隔を指定する「ポーリング型」、センシングやアクチュエーションを行う時刻を指定する「リクエスト型」などがある。エンドポイント164には、リソース要求に含まれるエンドポイント設定が格納される。エンドポイント設定には、アドレス部と、制御メッセージ部とが含まれる。アドレス部には、デバイス2に行わせたい動作に応じて、二次利用者側のアドレス(デバイス2からのデータの出力先)、あるいは、デバイス2に命令を入力するデバイス管理装置10側のアドレス(デバイス2への命令の入力元)が設定される。制御メッセージ部には、デバイス2に行わせたい動作に対応する制御メッセージ(例えば、JSON形式のメッセージ)が設定される。エンドポイント設定により、二次利用コントローラ161は、デバイス2から取得したデータの二次利用者側への出力、または、デバイス2への制御メッセージの入力を行うことができる。
二次利用コントローラ161は、一次利用者のデバイス2(IoTリソース)の二次利用者による任意のタイミングでの利用を可能とする実行プログラムである。二次利用コントローラ161は、二次利用ポインタDB17に登録されるエントリと1対1で対応する。二次利用コントローラ161は、二次利用ポインタDB17に登録された対応するエントリを参照し、エントリに保持されたキーを用いてデバイス管理DB14を検索する。そして、二次利用コントローラ161は、ヒットしたデバイス管理DB14のエントリを参照し、そのエントリのポインタをデバイス管理DBポインタとして、二次利用ポインタDB17の対応するエントリに一時的に保存する。デバイス管理DB14のエントリを参照することで、エントリに保存されたデバイス2の最新の状態を取得することができる。このような利用形式は「間接センサ」に相当する。
すなわち、利用形式「間接センサ」においては、図4Aに示すように、二次利用コントローラ161は、スケジューラ163に格納されたスケジュール設定で指定されたタイミングになると、二次利用ポインタ162に格納された二次利用ポインタを含むエントリを二次利用ポインタDB17から検索する。そして、二次利用コントローラ161は、検索されたエントリに保持されたキーを用いてデバイス管理DB14を検索し、ヒットしたエントリのポインタを二次利用ポインタDB17の対応するエントリに一時的に保存する。そして、二次利用コントローラ161は、デバイス管理DBポインタとしてポインタを保存したデバイス管理DB14のエントリに含まれるデバイス2の情報を、エンドポイント164に格納されたエンドポイント設定で指定された二次利用者側のアドレスに出力する。
図4Bは、利用形式「直接センサ」を示す図である。利用形式「直接センサ」の場合、二次利用コントローラ161は、図4Bに示すように、デバイス管理DB14を検索してヒットしたエントリに対応するデバイス2のAPI2aに対して、センシングを指示する制御メッセージを送信し、その制御メッセージに従うセンシングにより得られたデータを取得し、二次利用者側に出力する。
図4Cは、利用形式「直接アクチュエータ」を示す図である。利用形式「直接アクチュエータ」の場合、二次利用コントローラ161は、図4Cに示すように、デバイス管理DB14を検索してヒットしたエントリに対応するデバイス2のAPI2aに対して、アクチュエーションを指示する制御メッセージを送信する。
上述した利用形式は、二次利用者からの要求に応じて設定される。したがって、二次利用者は、利用形式、スケジュール設定、エンドポイント設定、キーなどを設定することで、所望の動作をデバイス2に行わせることができる。
次に、本実施形態に係るデバイス管理装置10の動作について、一次利用機能ブロック群の動作と二次利用機能ブロック群の動作とに分けて説明する。なお、二次利用機能ブロック群がコンテキストを利用する場合、一次利用機能ブロック群によりコンテキストが付加されたデバイス管理DB14を参照する必要がある。そのため、一次利用機能ブロック群の動作フローと、二次利用機能ブロック群の動作フローとは、デバイス管理DB14を中心に連動する。
まず、一次利用機能ブロック群の動作について説明する。図5は、一次利用機能ブロック群の動作を示すフローチャートである。また、図6は、一次利用機能ブロック群による処理の流れを模式的に示したものである。図6において、実線矢印は制御信号の入出力を示し、破線矢印は一次利用者による入力を示す。
デバイス管理部11は、一次利用者によるデバイス2の登録を受け付け、デバイス管理DB14に登録する(ステップS101)。
図7は、デバイス管理DB14の構成例を示す図である。
図7に示すように、デバイス管理DB14は、ポインタと、一次利用者のユーザ名と、デバイス2のアドレスと、デバイス2のデバイス名と、デバイス2が備えるAPI2aのAPI名と、コンテキストとを対応付けて記憶する。
デバイス管理部11は、一次利用者による登録に応じて、ユーザ名、アドレス、デバイス名、API名をデバイス管理DB14に記憶させる。
図5を再び参照すると、アプリケーション設定部12は、デバイス管理部11に登録されたデバイス2のAPI2aを用いて作成されたアプリケーション121の設定を受け付ける(ステップS102)。
図8は、アプリケーション121の設定例を示す図である。図8においては、一例として、アプリケーション121が、「サーモスタットの温度計測が26℃以上を示したら冷房をONにする(ラベル:部屋が暑くなったら冷房を点ける)」という動作を行う場合の例を示している。この場合、if−then条件(もし〜したら、〜にする)を用いてアプリケーション121が設定される。
具体的には、図8に示すように、アプリIDと、アプリケーション121を利用する一次利用者のユーザ名と、if文およびthen文それぞれにおけるデバイス名、API名およびAPI2aの動作の設定と、一次利用者が入力したラベルとが対応付けて設定される。
アプリケーション設定部12は、設定されたアプリケーション121のアプリケーション構成情報をコンテキスト解析部13に出力する。
図5を再び参照すると、コンテキスト解析部13は、アプリケーション設定部12から出力されたアプリケーション構成情報を解析し、アプリケーション121に用いられるデバイス2の利用方法や利用環境といった利用態様を示すコンテキストを生成する。そして、コンテキスト解析部13は、生成したコンテキストを含むコンテキストハンドラ131を生成する(ステップS103)。
図9は、コンテキストハンドラ131の構成例を示す図である。
図9に示すように、コンテキストハンドラ131は、アプリIDと、アプリケーションを利用する一次利用者のユーザ名と、デバイス名と、API名と、コンテキストと、有効期限とが対応付けられた構成を有する。図9では、一例として、図8における一次利用者Aが利用するアプリID「App_00」のアプリケーションのアプリケーション構成情報における「設定」や「ラベル」が解析され、アプリID「App_00」のアプリケーションのイベントが発生した際に、「暑い部屋」「冷房を点ける」というコンテキストを出力するコンテキストハンドラ131が生成された例を示している。
図5を再び参照すると、コンテキスト解析部13は、アプリケーション121のアプリケーション構成情報を解析して生成したコンテキストハンドラ131へのリンクを、そのアプリケーション121に設定する(ステップS104)。こうすることで、アプリID「App_00」のアプリケーションのif条件である「サーモスタットの温度計測」が「26℃以上」になったとき、コンテキストハンドラ131にイベント情報が通知される。なお、上述したように、コンテキストには有効期限が設定される。
次に、コンテキスト解析部13は、設定されたコンテキストハンドラ131の有効期限が超過したか否かを判定する(ステップS105)。
コンテキストハンドラ131が有効期限を超過したと判定した場合には(ステップS105:Yes)、コンテキスト解析部13は、有効期限を超過したコンテキストハンドラ131を削除する。そして、コンテキスト解析部13は、コンテキストを登録するデバイス管理DB14のエントリ(登録先のエントリ)からもコンテキストを削除する(ステップS106)。
コンテキストの有効期限を超過していないと判定した場合には(ステップS105:No)、コンテキストハンドラ131は、リンクが設定されたアプリケーション121からイベント情報を受信したか否かを判定する(ステップS107)。
イベント情報を受信していないと判定した場合には(ステップS107:No)、コンテキストハンドラ131は、ステップS105の処理に戻る。
イベント情報を受信したと判定した場合には(ステップS107:Yes)、コンテキストハンドラ131は、コンテキストを登録するデバイス管理DB14のエントリ(登録先のエントリ)に、登録対象のコンテキストと対称的な属性を有するコンテキスト(対称的なコンテキスト)が登録されているか否かを判定する(ステップS108)。例えば、コンテキストハンドラ131は、登録対象のコンテキストが「暑い部屋」である場合に、デバイス管理DB14の登録先のエントリに、登録対象のコンテキストとは対称的な属性を有するコンテキスト「寒い部屋」が登録されているか否かを判定する。
登録先のエントリに対称的なコンテキストが登録されていると判定した場合には(ステップS108:Yes)、コンテキストハンドラ131は、その対称的なコンテキストを登録対象のコンテキストで上書きする(ステップ109)。
登録先のエントリに対称的なコンテキストが登録されていないと判定した場合には(ステップS108:No)、コンテキストハンドラ131は、登録対象のコンテキストを新しいコンテキストとして登録先のエントリに追加する(ステップS110)。この場合、図7に示すように、デバイス管理DB14のデバイス名「サーモスタット」、API名「温度計測」のエントリにコンテキスト「暑い部屋」が登録され、デバイス名「冷暖房器具」、API名「冷房ON」のエントリにコンテキスト「冷房を点ける」が登録される。
ステップS109またはステップS110の処理の後、コンテキストハンドラ131は、ステップS105の処理に戻る。また、ステップS106の処理の後は、一次利用機能ブロック群による一連の処理を完了する。
次に、二次利用機能ブロック群の動作について説明する。図10は、二次利用機能ブロック群の動作を示すフローチャートである。また、図11は、二次利用コントローラ161の生成までの二次利用機能ブロック群による処理の流れを模式的に示したものである。また、図12は、二次利用コントローラによる処理の流れを模式的に示したものである。図11,12において、太線矢印はデータの入出力を示し、実線矢印は制御信号の入出力を示し、破線矢印は二次利用者による入力を示す。
要求解釈部15は、二次利用者により入力されたリソース要求を受け付ける(ステップS201)。なお、リソース要求の入力は、自然言語を用いた入力であってもよいし、GUI(Graphical User Interface)等を用いた入力であってもよい。
要求解釈部15は、入力されたリソース要求をデバイス管理装置10で認識可能な形式に整形し、整形後のリソース要求から各種設定を取得する(ステップS202)。以下では、図13に示すように、二次利用者Xにより、キー「コンテキスト:暑い部屋」、利用形式「間接センサ」、スケジュール設定「ポーリング:毎時」、エンドポイント設定「二次利用者Xのアドレス」が設定されたものとする。
図10を再び参照すると、二次利用コントローラ管理部16は、要求解釈部15により取得されたリソース要求に基づき、二次利用コントローラ161を生成する。
図14は、図13に示すリソース要求に応じて生成された二次利用コントローラ161の構成例を示す図である。図14に示すように、二次利用コントローラ161を識別可能な二次利用ポインタ「c_X_00」と、二次利用者のユーザ名と、キー「コンテキスト:暑い部屋」と、利用形式「間接センサ」と、スケジュール設定「ポーリング:毎時」と、エンドポイント設定「二次利用者Xのアドレス」とが設定される。二次利用コントローラ管理部16は、生成した二次利用コントローラ161の二次利用ポインタ「c_X_00」およびキーを二次利用ポインタDB17に登録する(ステップS203)。
図15は、二次利用ポインタDB17の構成例を示す図である。図15に示すように、二次利用ポインタDB17は、二次利用ポインタと、キーと、デバイス管理DBポインタとを対応付けて記憶する。図15に示す例では、二次利用コントローラ管理部16は、生成した二次利用コントローラ161の二次利用ポインタ「c_X_00」に対応して、リソース要求で設定されたキー「コンテキスト:暑い部屋」を登録する。
上述したステップS201〜S203までの処理が、図11に示す二次利用コントローラ161の生成までの処理の流れに相当する。そして、以降の処理が、図12に示す二次利用コントローラ161による処理の流れに相当する。なお、以下では、デバイス管理DB14には、図16に示すような情報が格納されているとする。
図10を再び参照すると、二次利用コントローラ161は、スケジュール設定でスケジュールされたタイミングになったか否かを判定する(ステップS204)。例えば、スケジュール設定「ポーリング:毎時」の場合には、二次利用コントローラ161は、1時間毎にポーリングを行い、ポーリングの実行タイミングまでは待機状態に入る。
スケジュールされたタイミングになっていないと判定した場合には(ステップS204:No)、二次利用コントローラ161は、ステップS204の処理を繰り返す。
スケジュールされたタイミングになったと判定した場合には(ステップS204:Yes)、二次利用コントローラ161は、対応する二次利用ポインタDB17のエントリに設定されたキーを用いて、デバイス管理DB14を検索する(ステップS205)。図15に示す例では、二次利用コントローラ161は、「コンテキスト:暑い部屋」をキーとして、デバイス管理DB14を検索する。
「コンテキスト:暑い部屋」をキーとして図16に示すデバイス管理DB14を検索した場合、ポインタ「d_A_01」のエントリと、ポインタ「d_B_02」のエントリとが、コンテキスト「暑い部屋」であるためヒットする。二次利用コントローラ161は、図15に示すように、ヒットしたエントリのポインタ「d_A_01」,「d_B_02」を二次利用ポインタDB17の二次利用ポインタ「c_X_00」のエントリのデバイス管理DBポインタに登録する。
次に、二次利用コントローラ161は、利用形式は「間接センサ」であるか否かを判定する(ステップS206)。
利用形式が「間接センサ」であると判定した場合には(ステップS206:Yes)、二次利用コントローラ161は、図12に示すように、デバイス管理DB14を検索してヒットしたエントリの情報をエンドポイント設定に設定された二次利用者Xのアドレスに送信する(ステップS207)。
利用形式が「間接センサ」でないと判定した場合には(ステップS206:No)、二次利用コントローラ161は、デバイス管理DB14を検索してヒットしたエントリのアドレスを参照する(ステップS208)。
次に、二次利用コントローラ161は、利用形式は「直接センサ」であるか否かを判定する(ステップS209)。
利用形式が「直接センサ」であると判定した場合には(ステップS209:Yes)、二次利用コントローラ161は、図12に示すように、参照したアドレスのデバイス2にセンシングを指示する制御メッセージを送信する。そして、二次利用コントローラ161は、その制御メッセージに従いセンシングを行ったデバイス2からデータを取得し(ステップS210)、エンドポイント設定に設定された二次利用者Xのアドレスに送信する(ステップS211)。
利用形式が「直接センサ」でないと判定した場合には(ステップS209:No)、二次利用コントローラ161は、図12に示すように、参照したアドレスのデバイス2にアクチュエーションを指示する制御メッセージを送信し、アクションを命令する(ステップS212)。
このように本実施形態においては、デバイス管理装置10は、一次利用者がデバイス2を用いて利用するアプリケーション121が設定されるアプリケーション設定部12と、アプリケーション設定部12に設定されたアプリケーション121に基づき、デバイス2の利用態様を示すコンテキストを生成するコンテキスト解析部13と、を備える。
一次利用者がデバイス2を用いて利用するアプリケーション121を解析することで、一次利用者によるデバイス2の利用方法や利用環境といった利用態様を推定することができる。そのため、アプリケーション121を解析してデバイス2のコンテキストを生成することで、デバイス2の利用態様に応じてデバイス2を管理することができる。
また、デバイス管理装置10は、デバイス2と、デバイス2のコンテキストとを対応付けて記憶するデバイス管理DB14と、二次利用者から、所望のリソースの利用を要求するリソース要求を取得する要求解釈部15と、要求解釈部15が取得したリソース要求に対応するコンテキストを有するデバイスをデバイス管理DB14から検索し、検索されたデバイス2のリソースをリソース要求に応じて利用可能とする二次利用コントローラ161を生成する二次利用コントローラ管理部16と、を備える。
コンテキストを用いた検索により、二次利用者が要求するリソースに対応するコンテキストを有するデバイス2を抽出して二次利用者に提供することができ、網羅的なIoTリソースの活用が可能となる。
また、リソース要求には、リソースを利用するタイミングを指示するスケジュール設定が含まれ、二次利用コントローラ161は、リソース要求に含まれるスケジュール設定で指示されるタイミングで検索されたデバイス2のリソースを利用する。
また、リソース要求には、デバイス2からのデータの出力先のアドレスまたはデバイス2への命令の入力元のアドレスが設定されるアドレス部と、デバイス2に対する制御メッセージが設定される制御メッセージ部とを含むエンドポイント設定が含まれ、二次利用コントローラ161は、エンドポイント設定に従い、デバイス2から取得したデータの出力またはデバイスへの制御メッセージの入力を行う。
そのため、二次利用者が任意のタイミング、任意の命令でIoTリソースの制御を行うことができる。
なお、実施形態では特に触れていないが、デバイス管理装置10が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、CD−ROMやDVD−ROMなどの記録媒体であってもよい。また、プログラムは、ネットワークを介して提供してもよい。
また、上述した実施形態では、デバイス管理装置10の構成と動作について説明したが、本発明はこれに限られず、デバイス管理装置10におけるデバイス管理方法として構成されてもよい。
本発明を図面および実施形態に基づき説明してきたが、当業者であれば本開示に基づき種々の変形または修正を行うことが容易であることに注意されたい。したがって、これらの変形または修正は本発明の範囲に含まれることに留意されたい。例えば、各ブロックなどに含まれる機能などは論理的に矛盾しないように再配置可能であり、複数のブロックを1つに組み合わせたり、或いは分割したりすることが可能である。