JP6603645B2 - リソース検索装置およびリソース検索方法 - Google Patents

Description

本発明は、リソース検索装置およびリソース検索方法に関する。

特許文献１には、「少なくとも、異なるネットワークに接続された機器間での１対１通信を許可するルータを備え、このルータを介して２つのネットワークを接続してなるネットワークシステム上のいずれかのネットワークに接続されたサーバ装置であって、当該サーバ装置が接続された自ネットワークに前記ルータを介して接続された他ネットワークの機器との間で１対１通信を行うことにより、他ネットワークに接続された機器の機器情報を取得し、取得した他ネットワークの機器情報を記憶手段に記憶する第１の機器情報取得手段と、自ネットワークの機器から、前記ルータにより他ネットワークの機器との間で使用することを許可されない通信によって、機器情報を検索するパケットを受けると、その検索条件に対応した機器情報を前記記憶手段から読み出し、そのパケットを送信してきた機器に返信する機器情報返信手段と、を備えたことを特徴とするサーバ装置」が開示されている。

特許文献１の技術を用いれば、複数のネットワークに接続された機器（「リソース」または「デバイス」と呼ぶ場合がある）から機器情報を収集し、リソース検索することで、ユーザ端末からのリソース検索要求に応じた最適なリソースを発見する仕組みを実現することができる。ここで、機器情報とは、当該機器のＩＰアドレス、種類、機種名などのメタデータである。上記の仕組みによれば、発見したリソースからユーザ端末に対して所望の情報を送信するなどのサービスを提供することができる。例えば、さまざまな場所に配置されたカメラ群のうち、特定の移動体をトラッキング可能なカメラを発見し、発見したカメラから移動体のリアルタイムな映像をユーザ端末に配信することができる。

特開２００７−９７０５７号公報

しかし、特許文献１の技術によれば、リソースから収集されるメタデータは、リソースごとに予め規定されたスタティックな情報である。このため、ユーザ端末からのリソース検索要求に応じたリソースの検索には多くの時間を要する場合が多い。例えば、メタデータの属性が同じである複数のカメラ間で同じ移動体を映していても、画像データなどのセンシング情報（ダイナミックな情報であり、「ライブデータ」と呼ぶ場合もある）は異なっている。このとき、その移動体を映しているカメラを決定する際、メタデータによる検索では、候補となるカメラに一通り接続し、ライブデータを確認した後に選別する必要があり、多くの時間を要する。その結果、ユーザ端末に表示されている移動体の映像は、移動体の実際の状態からかけ離れてしまい、リアルタイム性の低下を招く場合が多い。

また、特許文献１の技術によれば、リソース群が接続するネットワークの数が増大した場合、各ネットワークに接続されているすべてのサーバ装置間で情報交換をする必要がある。よって、サーバ装置の通信トラフィックやメタデータの管理コストが増大し、サーバ装置に大きな負荷が発生する。その結果、ユーザ端末からのリソース検索要求に応じたリソースの検索には多くの時間を要する場合が多くなり、上記したリアルタイム性の低下を招く場合がある。

このような背景を鑑みて、本発明は、複数のネットワークに接続されているリソースを用いて実現するサービスを利用するユーザ端末に送信する情報のリアルタイム性を向上させることを課題とする。

前記した課題を解決するため、請求項１に記載の発明は、複数のネットワークに配置されている複数リソースから所望のリソースを検索するリソース検索装置であって、前記ネットワークの各々に配置されているサーバの位置情報を記憶する記憶部と、ユーザ端末からリソース検索要求を取得し、前記取得したリソース検索要求に含まれる位置情報に対応する前記サーバを特定し、前記リソース検索要求に含まれる検索プログラムを、前記特定したサーバに配置し、前記検索プログラムが配置されたサーバから、当該サーバが配置されているネットワークに配置されているリソースが配信するライブデータを収集し、前記収集したライブデータを用いて、前記リソース検索要求に含まれる検索対象の認識の一致度が所定値以上となるライブデータを配信するリソースを検索し、前記検索したリソースにアクセスするためのアクセス情報を前記ユーザ端末に送信する、制御部を備える、ことを特徴とする。

また、請求項３に記載の発明は、複数のネットワークに配置されている複数リソースから所望のリソースを検索するリソース検索装置におけるリソース検索方法であって、前記リソース検索装置は、前記ネットワークの各々に配置されているサーバの位置情報を記憶しており、ユーザ端末からリソース検索要求を取得するステップと、前記取得したリソース検索要求に含まれる位置情報に対応する前記サーバを特定するステップと、前記リソース検索要求に含まれる検索プログラムを、前記特定したサーバに配置するステップと、前記検索プログラムが配置されたサーバから、当該サーバが配置されているネットワークに配置されているリソースが配信するライブデータを収集するステップと、前記収集したライブデータを用いて、前記リソース検索要求に含まれる検索対象の認識の一致度が所定値以上となるライブデータを配信するリソースを検索するステップと、前記検索したリソースにアクセスするためのアクセス情報を前記ユーザ端末に送信するステップと、を実行する、ことを特徴とする。

請求項１，３に記載の発明によれば、リソース検索の際、各リソースが取得するライブデータ（センシング情報）を活用し、ユーザ端末が指定した検索対象について最良のライブデータを配信するリソース検索に要する時間を短縮することができる。また、リソース検索用の検索プログラムを配置するサーバを対象にすればよく、従来のようなサーバ間での情報交換は不要となるため、サーバに発生する負荷は低減され、リソース検索に要する時間を短縮することができる。
したがって、複数のネットワークに接続されているリソースを用いて実現するサービスを利用するユーザ端末に送信する情報のリアルタイム性を向上させることができる。

また、請求項２に記載の発明は、請求項１に記載のリソース検索装置であって、前記検索対象は、前記ユーザ端末が指定した移動体であり、前記検索プログラムは、前記移動体の画像認識と映像処理を行うアプリケーション、および、前記移動体のライブデータを検索するアプリケーションである、ことを特徴とする。

請求項２に記載の発明によれば、検索プログラムを、ユーザ端末が移動体の画像認識と映像処理を行うアプリケーション、および、移動体のライブデータを検索するアプリケーションとすることで、画像のライブデータに関するリソース検索を実現することができる。さらに、移動体の画像認識の一致度が最も高いライブデータを配信するリソースに都度切り替えるように検索することができる。

本発明によれば、複数のネットワークに接続されているリソースを用いて実現するサービスを利用するユーザ端末に送信する情報のリアルタイム性を向上させることができる。

本実施形態のライブデータ検索システムの全体構成例を示す図である。 本実施形態のリソース検索装置の機能構成例を示す図である。 本実施形態のリソース検索装置が実行する全体処理を示すフローチャートである。 リソース発見処理を示すフローチャートである。 リソース活用処理を示すフローチャートである。 リソース検索ポータル部が実行する処理を示すフローチャートである。 タイムアウト時における定義済みのエラー処理を示すフローチャートである。 外部エラー発生時における定義済みのエラー処理を示すフローチャートである。 コンテキスト情報集約部が実行する処理を示すフローチャートである。 バリデーションチェック時における定義済みのエラー処理を示すフローチャートである。 コンテキスト流通部が実行する処理を示すフローチャートである。 メタデータ管理部が実行する検索処理を示すフローチャートである。 配信制御部が実行する処理を示すフローチャートである。 シェアリソース管理部が実行するリソース発見処理を示すフローチャートである。 ネットワーク制御部が実行する処理を示すフローチャート（１／２）である。 ネットワーク制御部が実行する処理を示すフローチャート（２／２）である。 応用例２におけるライブデータ検索システムの全体構成例を示す図である。 応用例２におけるユーザ端末の画面例であり、（ａ）がサービス実行前、（ｂ）がサービス実行後である。

次に、本発明を実施するための形態ついて説明する。

≪構成≫
図１に示すように、本実施形態のライブデータ検索システムは、複数の個別ＮＷ５−１〜５−３に対して、リソース検索装置１と、サーバ２−１〜２−３と、リソース３−１〜３−８と、ルータ４−１〜４−３とを備えている。個別ＮＷ５−１には、サーバ２−１、ルータ４−１およびリソース３−１〜３−３が配置されている。個別ＮＷ５−２には、サーバ２−２、ルータ４−２およびリソース３−４〜３−６が配置されている。個別ＮＷ５−３には、サーバ２−３、ルータ４−３およびリソース３−７，３−８が配置されている。リソース検索装置１とサーバ２−１〜２−３とはＩＰリーチャブルである。

リソース検索装置１は、リソース検索装置１に通信可能に接続されているユーザ端末６に対し、リソース３−１〜３−８を用いた所定のサービスを提供する装置である。リソース検索装置１は、ＣＰＵ（Central Processing Unit）と、記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。このコンピュータは、ＣＰＵが、記憶部上に読み込んだプログラムを実行することで、各機能部により構成される制御部（制御手段）を動作させる。

サーバ２−１〜２−３は、サーバ２−１〜２−３自身と同じ個別ＮＷ５−１〜５−３に配置されているリソース３−１〜３−８を管理するサーバである。サーバ２−１〜２−３は、サーバ２−１〜２−３自身に配置された検索プログラム２ａ−１〜２ａ−３に従った処理を実行する。検索プログラム２ａ−１〜２ａ−３は、ユーザ端末６からのリソース検索要求に対する応答結果をユーザ端末６に出力するためのプログラムである。

リソース３−１〜３−８は、ユーザ端末６にライブデータを配信する機器である。リソース３−１〜３−８は、例えば、カメラ、マイク、ウェアラブル端末である。リソース３−１〜３−８は、所定の位置に固定配置されていてもよいし、移動式であってもよい。ライブデータは、リソース３−１〜３−８の各々が固有に取得可能であり、動的に変化するセンシング情報である。センシング情報は、例えば、カメラが映している画像データ、マイクが取得した音声データである。

リソース３−１〜３−８にはそれぞれ、固有のメタデータが割り当てられている。メタデータは、例えば、リソース３−１〜３−８へのアクセス手段（例：リソース３−１〜３−８それぞれのＩＰアドレス）、物理的位置（例：緯度、経度、地名）、機能（例：カメラの撮影機能）、利用状態（例：占有中であるか否か、共有可であるか否か）を含む属性情報である。

ルータ４−１〜４−３は、所定の情報を複数の個別ＮＷ５−１〜５−３間に中継する通信装置である。
ユーザ端末６は、リソース３−１〜３−８から配信されたライブデータを視聴する装置であり、ユーザが所持する。ユーザ端末６は、例えば、スマートフォン、タブレット端末である。

リソース検索装置１は、ユーザ端末６からリソース検索要求を受信すると、サーバ２−１〜２−３の少なくとも１つに検索プログラム２ａ−１〜２ａ−３を配置する。サーバ２−１〜２−３は、検索プログラム２ａ−１〜２ａ−３に従い、サーバ２−１〜２−３自身と同じ個別ＮＷ５−１〜５−３に配置されているリソース３−１〜３−８からライブデータを収集する。サーバ２−１〜２−３は、収集したライブデータを解析し、解析結果をリソース検索装置１に送信する。この解析結果は、具体的には、サーバ２−１〜２−３自身と同じ個別ＮＷ５−１〜５−３に配置されているリソース３−１〜３−８のうち、ユーザ端末６からリソース検索要求に含まれる条件を満たすリソースを示すリソース検索結果である。

リソース検索装置１は、サーバ２−１〜２−３から受信した解析結果に基づいて、ユーザ端末６にアクセス情報を送信する（詳細は後記）。アクセス情報は、ユーザ端末６からのリソース検索要求を満たす最適なリソースにユーザ端末６がアクセスするための情報である。

リソース検索装置１は、サーバ２−１〜２−３を、サーバ２−１〜２−３自身と同じ個別ＮＷ５−１〜５−３に配置されているリソース３−１〜３−８と合わせたグループとして管理する。例えば、リソース検索装置１は、同じ個別ＮＷ５−１に配置されている、サーバ２−１およびリソース３−１〜３−８を１つのグループとして扱う。このとき、リソース検索装置１は、リソース３−１〜３−８のメタデータを管理しないようにするとよい。つまり、リソース検索装置１自身は、リソース３−１〜３−８を把握せず、サーバ２−１〜２−３にメタデータを管理させる態様をとる。このような態様により、リソース検索装置１が多数のメタデータを集中管理することがないため、リソース検索装置１にかかる負荷を低減させることができる。なお、リソース検索装置１は、サーバ２−１〜２−３を制御可能であるため、サーバ２−１〜２−３を介して間接的に、メタデータを管理することができる。ただし、上記態様に限定せず、リソース検索装置１が、リソース３−１〜３−８のメタデータを管理することを妨げない。

本実施形態のリソース検索装置１の機能構成について図２を参照して説明する。リソース検索装置１は、リソース検索ポータル部１１と、コンテキスト情報集約部１２と、コンテキスト流通部１３と、メタデータ管理部１４と、配信制御部１５と、シェアリソース管理部１６，１６−１と、ネットワーク制御部１７とを備える。

リソース検索ポータル部１１は、ユーザ端末６からリソース検索要求を受け付ける。リソース要求には、例えば、ユーザがアクセスしたいリソースの条件を表現する情報が含まれる。また、リソース検索ポータル部１１は、リソース検索の結果となるリソースと、ユーザ端末６とを通信可能に接続する。ユーザ端末６は、リソース検索ポータル部１１を介して、接続したリソースからのライブデータを取得することができる。

コンテキスト情報集約部１２は、ユーザ端末６からリソース検索要求に対してリソース検索を実行し、検索結果をリソース検索ポータル部１１に返す。検索結果は、ユーザ端末６が該当リソースへアクセスするためのアクセス情報を含む。コンテキスト情報集約部１２は、シェアリソース管理部１６，１６−１が生成するコンテキスト（情報）（詳細は後記）を集約し、ユーザ端末６が接続するリソースを判別することができる。

コンテキスト流通部１３は、リソース検索要求の応答結果となるリソースにアクセスするための名前解決に必要な処理を実行する。コンテキスト流通部１３は、リソースの静的な特性（例：リソースのメタデータ）から検索するリソースを絞り込むことができる。

メタデータ管理部１４は、リソースのメタデータを管理する。メタデータ管理部１４は、同じネットワークに配置されているリソース３−１〜３−８のメタデータを記憶するサーバ２−１〜２−３と連携してメタデータを管理することができる。メタデータ管理部１４は、メタデータを用いて、リソース検索に対してリソース検索場所を設定することができる。

配信制御部１５は、ライブデータを用いたリソース検索に必要な機能を所望のリソースに配信するために必要な処理を実行する。配信制御部１５は、リソースの動的な状況を判断するための解析機能をリソースに配信することができる。

シェアリソース管理部１６，１６−１は、複数の異なるネットワークに配置されているリソースを管理し、リソース検索の検索条件を満たすリソースを発見する。シェアリソース管理部１６，１６−１の各々は、同じネットワークに配置されているリソース３−１〜３−８を管理するサーバ２−１〜２−３の各々と連携することで、リソース３−１〜３−８を間接的に管理することができる。シェアリソース管理部１６，１６−１が管理するリソースには、例えば、所定のアプリケーションが配置され演算処理を行う計算リソース、センシング情報を取得するセンサリソース、リソースを駆動するアクチュエータリソースがある。シェアリソース管理部１６，１６−１は、動的に変わるこれらのリソースの接続状態に応じてリソースの使用可否を判断することができる。シェアリソース管理部１６，１６−１は、例えば、異なるネットワークの数に応じて複数用意することができ、シェアリソース管理部１６−１は、シェアリソース管理部１６が管理するネットワークとは異なるネットワークを管理する。また、シェアリソース管理部１６，１６−１はそれぞれ、複数の異なるネットワークをまとめて管理してもよい。

ネットワーク制御部１７は、ユーザ端末６が所定のリソースに接続するために必要な設定を行う。この設定は、サービス継続中にリソースが切り替わるたびに行われる。ネットワーク制御部１７は、動的に変わるリソースの状況に応じて、そのリソースの接続を制御することができる。

≪処理≫
本実施形態のリソース検索装置１が実行する処理について説明する。

（全体処理）
図３に示すように、リソース検索装置１が実行する全体処理は、以下の通りである。なお、上記したリソース検索ポータル部１１と、コンテキスト情報集約部１２と、コンテキスト流通部１３と、メタデータ管理部１４と、配信制御部１５と、シェアリソース管理部１６，１６−１と、ネットワーク制御部１７が、全体処理のいずれの処理を担当するかについては後記する。

まず、リソース検索装置１は、サービスリクエスト処理を実行する（ステップＳ１）。具体的には、リソース検索装置１は、ユーザ端末６から、ユーザ端末６が接続するリソースを検索するためのリソース検索要求を受信し、解析する。

次に、リソース検索装置１は、リソース発見処理を実行する（ステップＳ２）。具体的には、リソース検索装置１は、ユーザ端末６からのリソース検索要求に対する検索を実行し、リソース検索要求を満たす最適なリソースを決定する。

次に、リソース検索装置１は、リソース活用処理を実行する（ステップＳ３）。具体的には、リソース検索装置１は、リソース発見処理にて決定したリソースからユーザ端末６にライブデータを配信可能とするための設定を実行する。

次に、リソース検索装置１は、リソース発見更新処理を実行する（ステップＳ４）。具体的には、リソース検索装置１は、リソース発見処理（ステップＳ２）の検索と同様の検索を継続し、リソース検索要求を満たす新たなリソースを決定する。

リソース検索装置１は、新たなリソースに対してリソース活用処理（ステップＳ３）を実行することができる。リソース検索装置１は、リソース活用処理（ステップＳ３）およびリソース発見更新処理（ステップＳ４）を所定期間だけ繰り返した後、全体処理を終了する。

（リソース発見処理（図３のステップＳ２）の詳細）
図４に示すように、リソース発見処理（図３のステップＳ２）の詳細は、以下の通りである。なお、図４の処理を、上記したリソース検索ポータル部１１と、コンテキスト情報集約部１２と、コンテキスト流通部１３と、メタデータ管理部１４と、配信制御部１５と、シェアリソース管理部１６，１６−１と、ネットワーク制御部１７のいずれが担当するかについては後記する。

まず、リソース検索装置１は、ユーザ端末６からリソース検索要求を受信すると、リソース検索を開始する（ステップＳ１１）。
次に、リソース検索装置１は、リソース検索要求を満たすリソース検索場所を設定する（ステップＳ１２）。リソース検索場所は、検索対象のリソースが配置されている場所である。リソース検索場所の設定の詳細は、後記する。

次に、リソース検索装置１は、ライブデータ検索機能を、設定したリソース検索場所に配置されているリソースに配布可能となるようにする（ステップＳ１３）。ライブデータ検索機能の配布の詳細は後記する。

次に、リソース検索装置１は、ライブデータ検索機能を配布したリソースからライブデータ検索情報を収集する（ステップＳ１４）。ライブデータ検索情報は、ライブデータ検索機能を用いて取得される情報である。ライブデータ検索情報の収集の詳細は、後記する。
次に、リソース検索装置１は、収集したライブデータ検索情報に基づいて出力されるリソース検索結果をユーザ端末６に返却する（ステップＳ１５）。リソース検索結果の返却の詳細は後記する。
ステップＳ１１〜ステップＳ１５の処理は繰り返し継続され、所定期間経過すると、リソース活用処理（図３のステップＳ３）を開始する。
図４の処理により、ユーザ端末６が接続するリソースを発見することができる。

（リソース活用処理（図３のステップＳ３）の詳細）
図５に示すように、リソース活用処理（図３のステップＳ３）の詳細は、以下の通りである。なお、図５の処理を、上記したリソース検索ポータル部１１と、コンテキスト情報集約部１２と、コンテキスト流通部１３と、メタデータ管理部１４と、配信制御部１５と、シェアリソース管理部１６，１６−１と、ネットワーク制御部１７のいずれが担当するかについては後記する。

まず、リソース検索装置１は、リソース発見処理（図３のステップＳ２）で発見したリソースを活用するための設定を開始する（ステップＳ２１）。リソース活用の設定の詳細は、後記する。
次に、リソース検索装置１は、リソースアクセスのための設定を変更する（ステップＳ２２）。リソースアクセスのための設定変更の詳細は、後記する。

次に、リソース検索装置１は、該当のリソースに対するメディア接続を行うとともに、該当のリソースから映像（ライブデータの具体例）を受信する（ステップＳ２３）。メディア接続および映像受信の詳細は、後記する。

次に、リソース検索装置１は、ユーザ端末６へ映像を配信する（ステップＳ２４）。ステップＳ２１〜ステップＳ２４の処理は繰り返し継続され、所定期間経過すると、リソース発見更新処理（図３のステップＳ４）を開始する。
図５の処理により、ユーザ端末６は、リソース検索要求を満たす最適なリソースから映像を受信することができる。

（リソース発見更新処理（図３のステップＳ４））
リソース発見更新処理（図３のステップＳ４）は、ライブデータ検索情報の収集（図４のステップＳ１４）、および、リソース検索結果の返却（図４のステップＳ１５）を繰り返し継続する処理に等しい。リソース発見更新処理により、ユーザ端末６が接続するリソースを再発見することができる。

（リソース検索ポータル部１１が実行する処理の詳細）
図６に示すように、リソース検索ポータル部１１が実行する処理の詳細は、以下の通りである。なお、図６の処理は、サービスリクエスト処理（図３のステップＳ１）の詳細に等しい。

まず、リソース検索ポータル部１１は、ユーザ端末６からサービスコンテキストを取得する（ステップＡ１）。サービスコンテキストは、サービス検索要求に含まれており、ユーザ端末６のユーザが入力する情報である。サービスコンテキストには、「検索対象（キーワード）」、「アウトプット条件」、「位置情報」、「検索の有効期間」、「コンテキスト認識アプリ」、「要求リソース条件」が含まれている。
なお、サービスコンテキストを取得は、ユーザ端末６からのリソース検索要求を取得に相当する。

「検索対象（キーワード）」は、ライブデータの対象となる移動体（または当該移動体を表現するキーワード）である。本実施形態の処理の説明では、一例として、検索対象（キーワード）を「ゼッケン１」（ゼッケン番号が１番である選手）とする。

「アウトプット条件」は、ユーザ端末６からのリソース検索要求を満たすリソースのうち、ユーザ端末６が接続することになるリソースを決定するための条件である。本実施形態の処理の説明では、一例として、アウトプット条件を「検索対象（キーワード）の一致度が最も高い１件のカメラ」とする。検索対象（キーワード）の「一致度」とは、リソースが撮影等で取得しているライブデータの対象となる移動体が、検索対象（キーワード）と一致する度合いである。一致度は、リソースに配置されるコンテキスト認識アプリの周知の機能によって得られる。

「位置情報」は、ユーザ端末６からのリソース検索要求を満たすリソースが配置されている場所を示す情報である。本実施形態の処理の説明では、一例として、位置情報を「武蔵野、西東京」とする。

「検索の有効期間」とは、ユーザ端末６からのリソース検索要求に対する検索を実行する期間であり、ユーザ端末６から取得するサービスコンテキストの生存期間である。本実施形態の処理の説明では、一例として、検索の有効期間を「３６００ｓｅｃ（秒）」とする。

「コンテキスト認識アプリ」は、リソース（計算リソース）が検索対象（キーワード）からライブデータを取得するために、リソースに配置しようとするアプリケーションである。本実施形態の処理の説明では、一例として、コンテキスト認識アプリを「画像認識・映像処理ＡＰＬおよびゼッケン１ライブデータ検索ＡＰＬ」とする（「ＡＰＬ」はアプリケーションを表す）。
「画像認識・映像処理ＡＰＬ」は、リソースが、移動体（例：ゼッケン１）を映して生成される画像データを解析して移動体を検索対象（キーワード）と認識し、移動体を含む映像データの生成、配信を行うための周知のアプリケーションである。
「ゼッケン１ライブデータ検索ＡＰＬ」は、リソースにて、画像認識・映像処理ＡＰＬが生成した映像データから移動体としてのゼッケン１を検索し、ゼッケン１のライブデータを生成するためのアプリケーションである。

「要求リソース条件」は、検索対象（キーワード）のライブデータを取得するために用いるリソースを決定するための条件である。シェアリソース管理部１６は、要求リソース条件に基づいて、コンテキスト認識アプリを配置するリソースを決定する（詳細は後記）。本実施形態の処理の説明では、一例として、要求リソース条件を「４コアの計算機、最大５台のカメラ」とする。つまり、シェアリソース管理部１６は、要求リソース条件にしたがって、コンテキスト認識アプリを配置する４つの計算リソースと、最大５つまでのセンサリソースを決定する。
なお、シェアリソース管理部１６に関する説明は、シェアリソース管理部１６−１にもあてはまるため、以降の説明では、特段の事情が無い限り、シェアリソース管理部１６−１に関する説明は省略する。

次に、リソース検索ポータル部１１は、コンテキスト情報集約部１２にサービスコンテキストを送信する（ステップＡ２）。
次に、リソース検索ポータル部１１は、タイムアウトに関するエラー処理、および、外部エラーに関するエラー処理を実行する（ステップＡ３）。タイムアウトに関するエラー処理、および、外部エラーに関するエラー処理は、任意の処理に対する定義済みの処理である。

図７に示すように、タイムアウトに関するエラー処理は、まず、任意の処理Ａが実行されると（ステップＺ１１）、実行結果としてのレスポンスがあったか否か判定する（ステップＺ１２）。レスポンスがあった場合（ステップＺ１２でＹｅｓ）、エラーが発生しなかったとして、タイムアウトに関するエラー処理を終了する。

一方、レスポンスがなかった場合（ステップＺ１２でＮｏ）、所定期間が満了するまでレスポンスがなかったか否か、つまり、タイムアウトになったか否かを判定する（ステップＺ１３）。タイムアウトでない場合（ステップＺ１３でＮｏ）、ステップＺ１２に戻り、レスポンスを待つ。一方、タイムアウトになった場合（ステップＺ１３でＹｅｓ）、タイムアウトのエラーレスポンスを出力して、タイムアウトに関するエラー処理を終了する。リソース検索装置１は、タイムアウトのエラーレスポンスが出力されると、実行中の処理を中断する。

また、図８に示すように、外部エラーに関するエラー処理は、まず、任意の処理Ａが実行されると（ステップＺ２１）、外部エラーがあったか否か判定する（ステップＺ２２）。外部エラーは、例えば、トラフィック増大による過負荷、システム障害がある。外部エラーがなかった場合（ステップＺ２２でＮｏ）、エラーが発生しなかったとして、外部エラーに関するエラー処理を終了する。

一方、外部エラーがあった場合（ステップＺ２２でＹｅｓ）、外部エラーのエラーレスポンスを出力して、外部エラーに関するエラー処理を終了する。リソース検索装置１は、タイムアウトのエラーレスポンスが出力されると、実行中の処理を中断する。

図６に戻り、リソース検索ポータル部１１の処理の説明を続ける。なお、ステップＡ３にて、タイムアウトも外部エラーもなかったとする。
リソース検索ポータル部１１は、コンテキスト情報集約部１２から名前解決結果ＵＲＩ（Uniform Resource Identifier）を受信する（ステップＡ４）。名前解決結果ＵＲＩは、コンテキスト情報集約部１２によって、サービスコンテキストに対して生成されるが、詳細は後記する。

次に、リソース検索ポータル部１１は、ネットワーク制御部１７にメディア接続を要求する（ステップＡ５）。具体的には、リソース検索ポータル部１１は、ネットワーク制御部１７に名前解決結果ＵＲＩを送信する。

次に、リソース検索ポータル部１１は、タイムアウトに関するエラー処理、および、外部エラーに関するエラー処理を実行する（ステップＡ６）。ステップＡ６は、ステップＡ３と同様である。ステップＡ６にて、タイムアウトも外部エラーもなかったとする。

次に、リソース検索ポータル部１１は、ネットワーク制御部１７からメディア接続用ＵＲＩを受信する（ステップＡ７）。メディア接続用ＵＲＩは、ネットワーク制御部１７によって、サービスコンテキストに対して生成されるが、詳細は後記する。

次に、リソース検索ポータル部１１は、タイムアウトに関するエラー処理、および、外部エラーに関するエラー処理を実行する（ステップＡ８）。ステップＡ８にて、タイムアウトも外部エラーもなかったとする。
次に、リソース検索ポータル部１１は、ユーザ端末６に対してメディア接続し、接続先のリソースから映像を受信する（ステップＡ９）。リソース検索ポータル部１１は、ネットワーク制御部１７から受信したメディア接続用ＵＲＩを用いて、ユーザ端末６によるメディア接続を実現する。ユーザ端末６は、リソース検索ポータル部１１が受信した映像のデータを、ユーザ端末６の表示部に表示することができる。
なお、ユーザ端末６に対してメディア接続することは、ユーザ端末６からのリソース検索要求に応じて検索したリソース３−１〜３−８にアクセスするためのアクセス情報をユーザ端末６に送信することに相当する。
以上で、リソース検索ポータル部１１が実行する処理が終了する。

（コンテキスト情報集約部１２が実行する処理の詳細）
図９に示すように、コンテキスト情報集約部１２が実行する処理の詳細は、以下の通りである。なお、図９の処理は、リソース発見処理（図３のステップＳ２）のうち、リソース検索の開始（図４のステップＳ１１）の処理、および、リソース検索結果の返却（図４のステップＳ１５）の処理に等しい。

まず、コンテキスト情報集約部１２は、リソース検索ポータル部１１からサービスコンテキストを受信する（ステップＢ１。図６のステップＡ２参照。）。
次に、コンテキスト情報集約部１２は、バリデーションチェックに関するエラー処理を実行する（ステップＢ２）。バリデーションチェックに関するエラー処理は、任意の処理に対する定義済みの処理である。

図１０に示すように、バリデーションチェックに関するエラー処理は、まず、任意の処理Ａが実行されると（ステップＺ３１）、バリデーションエラーがあったか否か判定する（ステップＺ３２）。バリデーションエラーは、例えば、ユーザ端末６が本実施形態のサービスを利用するためのログイン認証の失敗である。バリデーションエラーがなかった場合（ステップＺ３２でＮｏ）、エラーが発生しなかったとして、バリデーションチェックに関するエラー処理を終了する。

一方、バリデーションチェックがあった場合（ステップＺ３２でＹｅｓ）、バリデーションチェックのエラーレスポンスを出力して、バリデーションチェックに関するエラー処理を終了する。リソース検索装置１は、バリデーションチェックのエラーレスポンスが出力されると、実行中の処理を中断する。

図９に戻り、コンテキスト情報集約部１２の処理の説明を続ける。なお、ステップＢ２にて、バリデーションエラーはなかったとする。
コンテキスト情報集約部１２は、サービスコンテキストキーを生成する（ステップＢ３）。サービスコンテキストキーは、受信したサービスコンテキストの識別子である。本実施形態では、例えば、サービスコンテキストキーを「SCIDxxxxxxx」とする。

次に、コンテキスト情報集約部１２は、検索コンテキストを生成する（ステップＢ４）。検索コンテキストは、サービスコンテキストから、「検索対象（キーワード）」と「アウトプット条件」とを除き、「検索の有効期間」を絶対時刻（例えば、検索終了日時：20xx/xx/xx/xx:xx:xx（年月日時分秒））に変換し、サービスコンテキストキー（SCIDxxxxxxx）を付与したものに等しい。

次に、コンテキスト情報集約部１２は、コンテキスト流通部１３に検索コンテキストを送信する（ステップＢ５）。
次に、コンテキスト情報集約部１２は、コンテキスト流通部１３からコンテキストを受信するまで待機する（ステップＢ６。初回の受け待ち。）。コンテキストは、シェアリソース管理部１６によって、検索コンテキストに対して生成されるが、詳細は後記する。コンテキストは非同期、かつ、断続的に生成され、生成の都度、コンテキスト情報集約部１２に送信される。

次に、コンテキスト情報集約部１２は、タイムアウトに関するエラー処理を実行する（ステップＢ７）。ステップＢ７にて、タイムアウトはなかったとする。

次に、コンテキスト情報集約部１２は、名前解決結果ＵＲＩを生成する（ステップＢ８）。名前解決結果ＵＲＩは、コンテキストに含まれる名前解決結果（コンテキスト名前解決結果）に割り当てられたＵＲＩである。コンテキスト情報集約部１２は、初回の受け待ちの間、受信したコンテキストが１つでもあれば、名前解決結果ＵＲＩを生成する。生成される名前解決結果ＵＲＩは、例えば、「http://service-output+SCIDxxxxxxx」とすることができる。
次に、コンテキスト情報集約部１２は、引き続き、コンテキスト流通部１３からコンテキストを受信するまで待機し、コンテキストを蓄積する（ステップＢ９）。

次に、コンテキスト情報集約部１２は、レスポンス周期を満了したか否かを判定する（ステップＢ１０）。レスポンス周期は、コンテキストの受け待ち期間であり、周期的に用意されている。レスポンス周期を満了しない場合（ステップＢ１０でＮｏ）、ステップＢ９に戻り、コンテキスト情報集約部１２は、コンテキストの受け待ちを継続する。一方、レスポンス周期を満了した場合（ステップＢ１０でＹｅｓ）、コンテキスト情報集約部１２は、蓄積したコンテキストを、サービスコンテキスト内のアプトプット条件に基づいてソートする（ステップＢ１１）。本実施形態の例によれば、蓄積したコンテキストについて、一致度が最も高いカメラ（リソース）から取得されるコンテキストが先頭に蓄積される。
なお、ステップＢ１１における、蓄積したコンテキストのソートは、リソース検索装置１が、収集したライブデータ（蓄積したコンテキスト）を用いて、ユーザ端末６からのリソース検索要求に含まれる検索対象の認識の一致度が最も高いライブデータを配信するリソース３−１〜３−８を検索することに相当する。

次に、コンテキスト情報集約部１２は、ソートしたコンテキストを、名前解決結果ＵＲＩに登録する（ステップＢ１２）。
次に、コンテキスト情報集約部１２は、リソース検索ポータル部１１に名前解決結果ＵＲＩを送信する（ステップＢ１３。図６のステップＡ４参照。）。

次に、コンテキスト情報集約部１２は、サービスコンテキスト検索の生存期間が満了したか否かを判定する（ステップＢ１４）。サービスコンテキスト検索の生存期間は、検索コンテキスト内の「検索の有効期間」である。サービスコンテキスト検索の生存期間が満了しない場合（ステップＢ１４でＮｏ）、ステップＢ９に戻り、コンテキスト情報集約部１２は、コンテキストの受け待ちを継続する。一方、サービスコンテキスト検索の生存期間が満了した場合（ステップＢ１４でＹｅｓ）、コンテキスト情報集約部１２は、図９の処理を終了する。なお、サービスコンテキスト検索の生存期間が満了の場合、コンテキスト情報集約部１２は、図９の処理の終了結果をリソース検索ポータル部１１に通知しない。
以上で、コンテキスト情報集約部１２が実行する処理が終了する。

（コンテキスト流通部１３が実行する処理の詳細）
図１１に示すように、コンテキスト流通部１３が実行する処理の詳細は、以下の通りである。なお、図１１の処理は、リソース発見処理（図３のステップＳ２）のうち、リソース検索場所の設定（図４のステップＳ１２）の処理に等しい。

まず、コンテキスト流通部１３は、コンテキスト情報集約部１２から検索コンテキストを受信する（ステップＣ１。図９のステップＢ５参照。）。図９のステップＢ５の説明を踏まえれば、受信した検索コンテキストは、位置情報（武蔵野、西東京）、検索終了日時（20xx/xx/xx/xx:xx:xx）、コンテキスト認識アプリ（画像認識・映像処理ＡＰＬおよびゼッケン１ライブデータ検索ＡＰＬ）、要求リソース条件（４コアの計算機、最大５台のカメラ）、および、サービスコンテキストキー（SCIDxxxxxxx）を含む。

次に、コンテキスト流通部１３は、バリデーションチェックに関するエラー処理を実行する（ステップＣ２）。ステップＣ２は、ステップＢ２（図９）と同様である。ステップＣ２にて、バリデーションエラーはなかったとする。

次に、コンテキスト流通部１３は、メタデータ管理部１４に位置情報検索を要求する（ステップＣ３）。このとき、コンテキスト流通部１３は、検索コンテキスト内の位置情報（武蔵野、西東京）をメタデータ管理部１４に送信する。位置情報検索は、検索コンテキスト内の位置情報に該当するリソース管理ノード（後記）を特定するための検索である。

次に、コンテキスト流通部１３は、タイムアウトに関するエラー処理、および、外部エラーに関するエラー処理を実行する（ステップＣ４）。ステップＣ４にて、タイムアウトも外部エラーもなかったとする。

次に、コンテキスト流通部１３は、メタデータ管理部１４からリソース管理ノードアドレスリストを受信する（ステップＣ５）。リソース管理ノードアドレスリストは、位置情報検索の検索結果であるが、詳細は後記する。

次に、コンテキスト流通部１３は、配信制御コンテキストを生成する（ステップＣ６）。配信制御コンテキストは、検索コンテキスト（ステップＣ１参照）の位置情報（武蔵野、西東京）をリソース管理ノードアドレスリストに置き換えたものに等しい。
次に、コンテキスト流通部１３は、配信制御部１５に配信制御コンテキストを送信する（ステップＣ７）。

次に、コンテキスト流通部１３は、タイムアウトに関するエラー処理、および、外部エラーに関するエラー処理を実行する（ステップＣ８）。ステップＣ８にて、タイムアウトも外部エラーもなかったとする。

次に、コンテキスト流通部１３は、シェアリソース管理部１６から受信したコンテキストをコンテキスト情報集約部１２に送信する（ステップＣ９。図９のステップＢ６，Ｂ９参照）。シェアリソース管理部１６から受信したコンテキストには、名前解決結果（コンテキスト名前解決結果）が含まれている（詳細は後記）。

次に、コンテキスト流通部１３は、検索の有効期間が満了したか否かを判定する（ステップＣ１０）。検索の有効期間の満了時は、検索コンテキスト（ステップＣ１）の検索終了日時（20xx/xx/xx/xx:xx:xx）に等しい。検索の有効期間が満了しない場合（ステップＣ１０でＮｏ）、ステップＣ９に戻り、コンテキスト流通部１３は、コンテキストの送信を継続する。一方、検索の有効期間が満了した場合（ステップＣ１０でＹｅｓ）、コンテキスト流通部１３は、検索停止処理を実行する（ステップＣ１１）。具体的には、コンテキスト流通部１３は、配信制御部１５に終了処理を指示する。検索停止処理の実行後、図１１の処理を終了する。
以上で、コンテキスト流通部１３が実行する処理が終了する。

（メタデータ管理部１４が実行する検索処理の詳細）
図１２に示すように、メタデータ管理部１４が実行する処理の詳細は、以下の通りである。なお、図１２の処理は、リソース発見処理（図３のステップＳ２）のうち、リソース検索場所の設定（図４のステップＳ１２）の処理に等しい。

まず、メタデータ管理部１４は、コンテキスト流通部１３から位置情報を受信する（ステップＤ１。図１１のステップＣ３参照。）。受信する位置情報は、コンテキスト流通部１３の位置情報検索のキーであり、検索コンテキスト内の位置情報（武蔵野、西東京）（例えば、ＣＳＶ形式の文字列情報）に等しい。

次に、メタデータ管理部１４は、バリデーションチェックに関するエラー処理を実行する（ステップＤ２）。ステップＤ２は、ステップＢ２（図９）と同様である。ステップＤ２にて、バリデーションエラーはなかったとする。

次に、メタデータ管理部１４は、受信する位置情報を用いて、文字列をキーとしたＵＲＩの検索を実行する（ステップＤ３）。メタデータ管理部１４は、位置情報内の文字列に対応するリソース管理ノードに割り当てられているＵＲＩを取得する。「リソース管理ノード」は、当該リソース管理ノードが担当する地域（範囲）内のリソースを管理する装置であり、サーバ２−１〜２−３（図１参照）に相当する。本実施形態で扱う異なる複数のネットワークが地域ごとに用意されている場合、リソース管理ノードは、当該リソース管理ノードが配置されているネットワークに配置されているリソースを管理する装置となる。「位置情報内の文字列に対応するリソース管理ノード」とは、位置情報が示す地域を担当するリソース管理ノードである。

例えば、メタデータ管理部１４は、位置情報に含まれている「武蔵野」を担当するリソース管理ノードに割り当てられているＵＲＩ（例：グローバルＩＰアドレス）を周知の方法で取得することができる。取得したＵＲＩは、例えば、「http://guest:pass@musahoge.jp:9801/rm/index.html」と表現することができる。
なお、リソース検索装置１の記憶部には、リソース管理ノードの位置情報が記憶されている。この位置情報は、当該リソース管理ノードが配置されているネットワークに配置されているリソースの位置（地域）を示す情報に対応する。

次に、メタデータ管理部１４は、タイムアウトに関するエラー処理、および、外部エラーに関するエラー処理を実行する（ステップＤ４）。ステップＤ４にて、タイムアウトも外部エラーもなかったとする。

次に、メタデータ管理部１４は、リソース管理ノードアドレスリストを生成する（ステップＤ５）。リソース管理ノードアドレスリストは、文字列をキーとしたＵＲＩの検索（ステップＤ３）に該当したリソース管理ノードのリストである。例えば、リソース管理ノードアドレスリストは、文字列のキーと、文字列に対応するリソース管理ノードのＵＲＩとを組とした形式をとるリストである。本実施形態の例でいえば、前記組を、（武蔵野，ＵＲＩ−ｘ）、（西東京，ＵＲＩ−ｙ）、・・・と表現することができる。
なお、リソース管理ノードアドレスリストの生成は、リソース検索要求に含まれる位置情報に対応するリソース管理ノードの特定に相当する。

次に、メタデータ管理部１４は、コンテキスト流通部１３にリソース管理ノードアドレスリストを送信する（ステップＤ６。図１１のステップＣ５参照）。リソース管理ノードアドレスリストの送信後、図１２の処理が終了する。
以上で、メタデータ管理部１４が実行する検索処理が終了する。

（配信制御部１５が実行する処理）
図１３に示すように、配信制御部１５が実行する処理の詳細は、以下の通りである。なお、図１３の処理は、リソース発見処理（図３のステップＳ２）のうち、ライブデータ検索機能の配布（図４のステップＳ１３）の処理に等しい。

まず、配信制御部１５は、コンテキスト流通部１３から配信制御コンテキストを受信する（ステップＥ１。図１１のステップＣ７参照。）。図１１のステップＣ６の説明を踏まえれば、受信した配信制御コンテキストは、リソース管理ノードアドレスリスト、検索終了日時（20xx/xx/xx/xx:xx:xx）、コンテキスト認識アプリ（画像認識・映像処理ＡＰＬおよびゼッケン１ライブデータ検索ＡＰＬ）、要求リソース条件（４コアの計算機、最大５台のカメラ）、および、サービスコンテキストキー（SCIDxxxxxxx）を含む。

次に、配信制御部１５は、バリデーションチェックに関するエラー処理を実行する（ステップＥ２）。ステップＥ２は、ステップＢ２（図９）と同様である。ステップＥ２にて、バリデーションエラーはなかったとする。

次に、配信制御部１５は、配信先管理リストを生成する（ステップＥ３）。配信先管理リストは、機能の配信先の候補となるリソース管理ノードのリソース情報を管理するリストである。配信先管理リストは、例えば、「サービスコンテキストキー」、「リソース管理ノードのＵＲＩ」、「配信状態」、「タイムスタンプ」、および「検索終了日時」の組を、リソース管理ノード（または当該リソース管理ノードが担当する地域）ごとに生成してまとめたリストとすることができる。本実施形態の例でいえば、武蔵野については、（［サービスコンテキストキー］，［リソース管理ノードのＵＲＩ］，［配信状態］，［タイムスタンプ］,［検索終了日時］）＝（SCIDxxxxxxx，ＵＲＩ−ｘ，未配信，null，20xx/xx/xx/xx:xx:xx）となる。また、西東京については、（［サービスコンテキストキー］，［リソース管理ノードのＵＲＩ］，［配信状態］，［タイムスタンプ］,［検索終了日時］）＝（SCIDxxxxxxx，ＵＲＩ−ｙ，配信済み，20yy/yy/yy/yy:yy:yy，20xx/xx/xx/xx:xx:xx）となる。

配信先管理リストは、随時更新される。配信制御部１５は、例えば、サービスコンテキスト（図６参照）に示す検索の有効期間（３６００ｓｅｃ）だけ配信先管理リストを保持する。

次に、配信制御部１５は、タイムアウトに関するエラー処理、および、外部エラーに関するエラー処理を実行する（ステップＥ４）。ステップＥ４にて、タイムアウトも外部エラーもなかったとする。

次に、配信制御部１５は、受信した配信制御コンテキスト（ステップＥ１）内のアプリ（コンテキスト認識アプリ）をストレージに配置する（ステップＥ５）。ストレージ（図示せず）は、配布予定のアプリを記憶する記憶装置である。本実施形態の例でいえば、コンテキスト認識アプリとしての画像認識・映像処理ＡＰＬについては、画像認識・映像処理ＡＰＬのバイナリファイルをストレージに配置する。また、コンテキスト認識アプリとしてのゼッケン１ライブデータ検索ＡＰＬは、配信制御コンテキスト内の、検索終了日時（20xx/xx/xx/xx:xx:xx）、要求リソース条件（４コアの計算機、最大５台のカメラ）、および、サービスコンテキストキー（SCIDxxxxxxx）と併せた「ゼッケン１ライブデータ検索ＡＰＬセット」としてストレージに配置する。

次に、配信制御部１５は、ストレージに配置したアプリごとにダウンロード用ＵＲＩを生成する（ステップＥ６）。ダウンロード用ＵＲＩは、ストレージに配置したアプリを所定の装置にダウンロードするときのアクセス手段である。本実施形態の例でいえば、配信制御部１５は、画像認識・映像処理ＡＰＬのダウンロード用ＵＲＩと、ゼッケン１ライブデータ検索ＡＰＬのダウンロード用ＵＲＩを生成する。

次に、配信制御部１５は、各シェアリソース管理部１６（または１６−１）にダウンロード用ＵＲＩを配信する（ステップＥ７）。ダウンロード用ＵＲＩの配信先となるシェアリソース管理部１６は、配信先管理リスト（ステップＥ３）に登録されているリソース管理ノードと連携するシェアリソース管理部１６である。
次に、配信制御部１５は、各リソースでのコンテキスト認識アプリのダウンロードが完了するのを待ち、完了後、配信先管理リストを更新する（ステップＥ８）。この更新は、例えば、ダウンロードの完了を示すタイムスタンプの更新である。配信先管理リストの更新後、図１３の処理が終了する。
以上で、配信制御部１５が実行する処理が終了する。

（シェアリソース管理部１６が実行するリソース発見処理）
図１４に示すように、シェアリソース管理部１６が実行する処理の詳細は、以下の通りである。なお、図１４の処理は、リソース発見処理（図３のステップＳ２）のうち、ライブデータ検索情報の収集（図４のステップＳ１４）の処理に等しい。

まず、シェアリソース管理部１６は、配信制御部１５からダウンロード用ＵＲＩを受信する（ステップＦ１。図１３のステップＥ７参照。）。
次に、シェアリソース管理部１６は、受信したダウンロード用ＵＲＩにアクセスしたファイルのダウンロードを開始する（ステップＦ２）。本実施形態の例でいえば、ダウンロードするファイルは、画像認識・映像処理ＡＰＬのバイナリファイルと、ゼッケン１ライブデータ検索ＡＰＬセットである。シェアリソース管理部１６は、配信先管理リスト（図１３参照）に登録されたリソース管理ノードにファイルをダウンロードし、リソース管理ノードに画像認識・映像処理ＡＰＬおよびゼッケン１ライブデータ検索ＡＰＬセットを配置する（図１のサーバ２−１〜２−３の少なくとも１つに検索プログラム２ａ−１〜２ａ−３を配置することに相当）。

次に、シェアリソース管理部１６は、要求リソース条件に基づいてリソースアロケーションを実行する（ステップＦ３）。本実施形態の例でいえば、シェアリソース管理部１６は、ゼッケン１ライブデータ検索ＡＰＬセットに含まれる要求リソース条件（配信制御コンテキスト内の要求リソース条件（図１３のステップＥ１）と同じ）を満たす計算機（計算リソース）およびカメラ（センサリソース）を、配信先管理リスト（図１３参照）に登録されたリソース管理ノードが管理するリソースから選出し、選出したリソースに所定量のＣＰＵ資源、メモリ資源などを割り当てる。

次に、シェアリソース管理部１６は、タイムアウトに関するエラー処理、および、外部エラーに関するエラー処理を実行する（ステップＦ４）。ステップＦ４にて、タイムアウトも外部エラーもなかったとする。

次に、シェアリソース管理部１６は、要求リソース条件に基づいて決定したリソースに対してリソースアクセスを実行する（ステップＦ５）。具体的には、シェアリソース管理部１６は、計算リソースに、画像認識・映像処理ＡＰＬおよびライブデータ検索ＡＰＬを配置して、起動する。また、シェアリソース管理部１６は、計算リソースをセンサリソースに繋ぎ、画像を受信できる状態にする。ここで、１つの計算リソースに配置した画像認識・映像処理ＡＰＬと同じ画像認識・映像処理ＡＰＬを別の計算リソースに配置することを予定している場合、当該別の計算リソースには、ライブデータ検索ＡＰＬのみを配置すればよい。一般的に、複数種類のサービスコンテキスト間で同じ画像認識・映像処理ＡＰＬを用いる場合、画像認識・映像処理ＡＰＬを共用することができる。よって、例えば、各計算リソースに配置したライブデータ検索ＡＰＬに対して、同じ画像認識・映像処理ＡＰＬによって出力された認識結果を入力し、ライブデータに関する処理を実現することができる。換言すれば、画像認識・映像処理ＡＰＬを配置する計算リソースは１つだけ決定すればよい。

次に、シェアリソース管理部１６は、コンテキスト生成処理を実行する（ステップＦ６）。コンテキストは、コンテキスト認識アプリが配置されたリソースがコンテキスト認識アプリを起動させて得られた出力結果である。シェアリソース管理部１６は、コンテキストを、リソースからの出力結果にアクセスするためのＵＲＩとして作成することができる。

このＵＲＩは、例えば、「http://192.168.1.11&id=c001&result=80&SCID=xxxxxx」などといった形式で表現することができる。ここで、「192.168.1.11」はリソース管理ノードのグローバルＩＰアドレスである。「id=c001」は、コンテキスト認識アプリの実行結果を出力したリソースの識別子である。「result=80」は、コンテキスト名前解決結果として一致度が８０％であることを示している。「SCID=xxxxxx」は、サービスコンテキストキーである。
なお、コンテキスト生成処理は、リソース検索装置１が、検索プログラム２ａ−１〜２ａ−３が配置されたサーバ２−１〜２−３から、当該サーバ２−１〜２−３が配置されているネットワークに配置されているリソース３−１〜３−８が配信するライブデータを収集することに相当する。

次に、シェアリソース管理部１６は、コンテキスト流通部１３にコンテキストを送信する（ステップＦ７。図１１のステップＣ９参照。）。送信するコンテキストは、特に、ライブデータ検索ＡＰＬによるコンテキストである。シェアリソース管理部１６は、ステップＦ６にて生成したコンテキストにサービスコンテキストキーを紐付けて、コンテキスト流通部１３に送信する。

次に、シェアリソース管理部１６は、タイムアウトに関するエラー処理、および、外部エラーに関するエラー処理を実行する（ステップＦ８）。ステップＦ８にて、タイムアウトも外部エラーもなかったとして、図１４の処理を終了する。
以上で、シェアリソース管理部１６が実行するリソース発見処理が終了する。

（ネットワーク制御部１７が実行する処理）
図１５、図１６に示すように、ネットワーク制御部１７が実行する処理の詳細は、以下の通りである。なお、図１５、図１６の処理は、リソース活用処理（図３のステップＳ３）のうち、リソース活用設定の開始（図５のステップＳ２１）の処理、および、リソースアクセスのための設定の変更（図５のステップＳ２２）の処理に等しい。

まず、ネットワーク制御部１７は、リソース検索ポータル部１１から名前解決結果ＵＲＩを受信する（ステップＧ１）。この名前解決結果ＵＲＩは、コンテキスト情報集約部１２がリソース検索ポータル部１１に送信した名前解決結果ＵＲＩである（図６のステップＡ４、図９のステップＢ１３参照）。

次に、ネットワーク制御部１７は、受信した名前解決結果ＵＲＩを用いてコンテキスト情報集約部１２にアクセスし、ソケット通信を開始する（ステップＧ２）。

次に、ネットワーク制御部１７は、コンテキスト情報集約部１２からコンテキストおよび検索終了日時を取得する（ステップＧ３）。コンテキストは、シェアリソース管理部１６が生成したものであり（図１４のステップＦ６）、例えば、「http://192.168.1.11&id=c001&result=80&SCID=xxxxxx」などといったＵＲＩ形式で表現される。ネットワーク制御部１７は、取得したコンテキストを解析することで、取得時点における一致度（コンテキスト一致度）が最も高いＵＲＩを得ることができる。このＵＲＩは、すべてのコンテキストの中の最適値である。また、コンテキスト情報集約部１２から取得した検索終了日時は、コンテキスト情報集約部１２が生成した検索コンテキストに含まれる検索終了日時（20xx/xx/xx/xx:xx:xx）である。

次に、ネットワーク制御部１７は、検索終了日時を経過したか否か判定する（ステップＧ４）。経過した場合（ステップＧ４でＹｅｓ）、ネットワーク制御部１７は、リソース開放を指示する（ステップＧ５）。リソース開放を指示することで、発見したリソースを活用することができ、図１５、図１６の処理が終了する。

一方、検索終了日時を経過していない場合（ステップＧ４でＮｏ）、ネットワーク制御部１７は、取得したコンテキスト内のＵＲＩ（名前解決結果ＵＲＩ）にアクセスし、アクセス先のリソースに対してメディア接続を要求する（ステップＧ６）。

次に、ネットワーク制御部１７は、タイムアウトに関するエラー処理、および、外部エラーに関するエラー処理を実行する（ステップＧ７）。ステップＧ７にて、タイムアウトも外部エラーもなかったとする。

次に、ネットワーク制御部１７は、シェアリソース管理部１６によるリソースアクセス（図１４のステップＦ５）のための設定変更する（ステップＧ８）。この設定変更には、例えば、ネットワーク制御部１７が、メディア接続を要求したリソース（ステップＧ６）から、当該リソースへのアクセス権限を獲得すること、などが含まれる。
次に、ネットワーク制御部１７は、メディア接続先となるリソースからリソースアクセスＵＲＩを取得する（ステップＧ９）。
次に、ネットワーク制御部１７は、取得したリソースアクセスＵＲＩに対して、映像配信を要求する（図１６のステップＧ１０）。

次に、ネットワーク制御部１７は、タイムアウトに関するエラー処理、および、外部エラーに関するエラー処理を実行する（ステップＧ１１）。ステップＧ１１にて、タイムアウトも外部エラーもなかったとする。

次に、ネットワーク制御部１７は、メディア接続用ＵＲＩを生成する（ステップＧ１２）。メディア接続用ＵＲＩは、ユーザ端末６がメディア接続先となるリソースに接続するためのＵＲＩである。
次に、ネットワーク制御部１７は、リソース検索ポータル部１１にメディア接続用ＵＲＩを送信する（ステップＧ１３。図６のステップＡ７参照）。

次に、ネットワーク制御部１７は、例えば切替前のリソースが映像をすでに配信している場合には、その映像を終端し、リソース検索ポータル部１１からのメディア接続（の要求）を待つ（ステップＧ１４、図６のステップＡ５参照）。リソースの切替については後記する。ネットワーク制御部１７は、切替後のリソースからの映像をリソース検索ポータル部１１が受信する（図６のステップＡ９参照）ための制御をする。

次に、ネットワーク制御部１７は、タイムアウトに関するエラー処理、および、外部エラーに関するエラー処理を実行する（ステップＧ１５）。ステップＧ１５にて、タイムアウトも外部エラーもなかったとする。

次に、ネットワーク制御部１７は、リソースからの映像をリソース検索ポータル部１１に配信する（ステップＧ１６）。リソース検索ポータル部１１は、ユーザ端末６に当該映像を配信する。

以降では、映像を配信するリソースを切り替えるリソース切替処理が実行される。具体的には、ネットワーク制御部１７は、コンテキスト情報集約部１２からの変更通知があったか否か判定する（ステップＧ１７）。この変更通知は、コンテキスト情報集約部１２がリソース検索ポータル部１１に送信した名前解決結果ＵＲＩ（図９のステップＢ１３）が変更したため、映像を配信するリソースが切り替わることを示す通知である。リソースの切替は、コンテキスト内の一致度（コンテキスト一致度）が最も高い値を示していたリソースが別のリソースに変わったことを意味する。

変更通知が無かった場合（ステップＧ１７でＮｏ）、ステップＧ３に進み、ネットワーク制御部１７は、コンテキスト情報集約部１２からコンテキストおよび検索終了日時を改めて取得する。取得後、すでに説明した処理（ステップＧ４からの処理）が実行される。
一方、変更通知があった場合（ステップＧ１７でＹｅｓ）、ネットワーク制御部１７は、コンテキスト情報集約部１２から取得したコンテキストにおいて、一致度（コンテキスト一致度）以外の変更があったか否か判定する（ステップＧ１８）。一致度以外の変更が無かった場合（ステップＧ１８でＮｏ）、一致度（コンテキスト一致度）が最も高いＵＲＩ、つまりリソースは同じであり、リソースの切替が不要であることを意味している。よって、ステップＧ３に進み、ネットワーク制御部１７は、コンテキスト情報集約部１２からコンテキストおよび検索終了日時を改めて取得する。取得後、すでに説明した処理（ステップＧ４からの処理）が実行される。

一方、一致度以外の変更があった場合（ステップＧ１８でＹｅｓ）、リソースを切替が行われる。具体的には、ステップＧ６に進み、ネットワーク制御部１７は、コンテキスト内の新たなＵＲＩ、つまり、一致度が最も高いと新たに判定された切替後のリソースへアクセスし、メディア接続を要求する。要求後、切替後のリソースについて、すでに説明した処理（ステップＧ７からの処理）が実行される。最終的には、リソース開放指示（ステップＧ５）がなされたときに図１５、図１６の処理が終了する。
以上で、ネットワーク制御部１７が実行する処理の説明を終了する。

≪まとめ≫
本実施形態によれば、リソース検索の際、各リソース３−１〜３−８が取得するライブデータ（センシング情報）を活用し、ユーザ端末６が指定した検索対象について最良のライブデータを配信するリソース検索に要する時間を短縮することができる。また、リソース検索用の検索プログラム（コンテキスト認識アプリ）を配置するサーバ２−１〜２−３を対象にすればよく、従来のようなサーバ間での情報交換は不要となるため、サーバ２−１〜２−３に発生する負荷は低減され、リソース検索に要する時間を短縮することができる。
したがって、複数のネットワークに接続されているリソースを用いて実現するサービスを利用するユーザ端末に送信する情報のリアルタイム性を向上させることができる。

また、検索プログラムを、ユーザ端末６が移動体の画像認識と映像処理を行うアプリケーション、および、移動体のライブデータを検索するアプリケーションとすることで、画像のライブデータに関するリソース検索を実現することができる。さらに、移動体の画像認識の一致度が最も高いライブデータを配信するリソースに都度切り替えるように検索することができる。

≪応用例１≫
本実施形態のライブデータ検索システムを、特定人物の見守りに応用することができる。例えば、見守りたい人物の一致度を検出する画像認識プログラムを、カメラ（カメラリソース）近傍の計算機（計算リソース）に配置する。計算機は、カメラからライブデータを取得して解析することができ、解析結果から、当該人物が映っている最適なカメラ（一致度が最高値を示すカメラ）を検出することができる。リソース検索装置１は、検出したカメラにアクセス可能とするように各種ネットワーク機器の設定を変更し、見守り人の端末に対し、検出したカメラに当該端末がアクセスするためのアクセスアドレスを通知する。応用例１は、高齢者の監視にも応用することができる。

≪応用例２≫
本実施形態のライブデータ検索システムを、マラソン大会の特定選手の中継放送に応用することもできる。公道や競技トラックで実施されるマラソン大会の顔認識プログラムを計算機（計算リソース）に配置する。また、マラソン大会会場に配置されている固定カメラや移動カメラ（例：スマートフォン）の映像（ライブデータ）を解析することで、注目選手を映しているカメラを検出する。リソース検索装置１は、検出したカメラにアクセス可能とするように各種ネットワーク機器の設定を変更し、視聴者に対し、検出したカメラに当該端末がアクセスするためのアクセスアドレスを通知する。

応用例２の具体的構成を図１７に示す。図１７に示すように、応用例２のライブデータ検索システムは、リソース検索ポータルサーバ１Ａと、ライブデータ検索システム搭載サーバ１Ｂと、無線ＡＰ（１Ｃ）と、個別ＮＷ管理マシン２１，２２と、汎用マシン２３，２４とを備えている。また、ネットワークとしては、個別ＮＷ−Ａ，Ｂ（５１，５２）と、広域ＮＷ（５３）がある。個別ＮＷ−Ａ，Ｂ（５１，５２）、および、広域ＮＷ（５３）は、図示しないルータによって通信可能に接続されている。

広域ＮＷ（５３）には、リソース検索ポータルサーバ１Ａと、ライブデータ検索システム搭載サーバ１Ｂと、個別ＮＷ管理マシン２１と、ユーザ端末６１とが接続されている。
個別ＮＷ−Ａ（５１）には、個別ＮＷ管理マシン２２と、汎用マシン２３と、固定カメラ３１，３２が接続されている。
個別ＮＷ−Ｂ（５２）には、個別ＮＷ管理マシン２１と、汎用マシン２４と、無線ＡＰ１Ｃと、固定カメラ３３〜３５と、が接続されている。
個別ＮＷ−Ａ，Ｂ（５１，５２）は、ルータなどの転送装置が配置されるローカルネットワークである。

図１７に示すフィールド内には、選手ｒ１〜ｒ４と、固定カメラ３１〜３５と、移動カメラ３６が存在する。選手ｒ１〜ｒ４は、競技トラック内を走行する移動体である。
図１７中の実細線は、各種ＮＷと装置との有線の接続を示し、破細線は、無線の接続を示す。また、図１７中の実太矢印はカメラの撮影方向を示し、破太矢印は、選手の移動方向を示す。移動カメラ３６の撮影方向は動的に変化する。

リソース検索ポータルサーバ１Ａは、映像配信したい選手を選択し、選択した選手の映像を配信するＷｅｂサーバである。リソース検索ポータルサーバ１Ａは、本実施形態のリソース検索装置１のリソース検索ポータル部１１に相当する。

ライブデータ検索システム搭載サーバ１Ｂは、ライブデータ検索機能を提供するサーバであり、リソース検索ポータルサーバ１Ａのリクエストを契機に動作する。ライブデータ検索システム搭載サーバ１Ｂは、本実施形態のリソース検索装置１のコンテキスト情報集約部１２と、コンテキスト流通部１３と、メタデータ管理部１４と、配信制御部１５と、ネットワーク制御部１７に相当する。

無線ＡＰ（１Ｃ）は、無線通信の中継機器である（「ＡＰ」はアクセスポイントの意味）。無線ＡＰ（１Ｃ）は、個別ＮＷ−Ｂ（５２）に所属しており、個別ＮＷ管理マシン２１へブリッジ接続している。
ユーザ端末６１は、リソース検索ポータルサーバ１Ａにアクセスし、選手の選択や映像受信のためのブラウザを備える。

個別ＮＷ管理マシン２１，２２は、センサリソース（固定カメラ３１〜３５、移動カメラ３６）、計算リソースなどのリソースを管理する機能、ルーティング機能、および、ＤＨＣＰ（Dynamic Host Configuration Protocol）サーバ機能を有する。個別ＮＷ管理マシン２１，２２は、リソースの位置情報を有し、メタデータとして管理することができる。個別ＮＷ管理マシン２１，２２は、本実施形態のリソース検索装置１のシェアリソース管理部１６に相当する。

汎用マシン２３，２４は、１つの個別ＮＷに所属している計算機サーバである。汎用マシン２３，２４は、固定カメラ３１〜３５、移動カメラ３６との映像データ通信を終端したり、画像認識、コンテキスト化、マルチ映像配信に必要なリソースを提供したりすることができる。汎用マシン２３，２４は、本実施形態のサーバ２−１〜２−３（図１）に相当する。

図１７に示す構成によれば、注目選手の映す最適なカメラが検出され、そのカメラからの映像データをユーザ端末６１に表示することができる。ユーザ端末６１の画面例を図１８に示す。図１８（ａ）、（ｂ）に示すように、ユーザ端末６１の画面には、指定選手の映像を表示する映像領域６１１と、特定の選手を選択するための選手選択ボタン６１２〜６１４と、映像配信を停止するための停止ボタン６１５と、映像配信に関する説明が記述されるインフォメーションバー６１６が表示されている。

サービス実行前は、リソースへの未接続時である。このとき、図１８（ａ）に示すように、映像領域６１１には、ダミー画面が表示され、選手選択ボタン６１２〜６１４はアクティブ表示され選択可能状態となっている。インフォメーションバー６１６には、サービス実行前のインフォメーションが表示されている。

選手選択ボタン６１２を操作すると、サービスが実行され、図１８（ｂ）に示すように、ゼッケン１ アルファ選手のライブデータが映像領域６１１に表示される。このライブデータは、画像認識プログラムによりコンテキスト一致度が最高値を示すカメラに接続して配信された映像データである。選手選択ボタン６１２を操作の際、ユーザ端末６１からのリソース検索要求には、画像認識・映像処理ＡＰＬと、ゼッケン１ライブデータ検索ＡＰＬが含まれており、これらのＡＰＬが接続先のカメラと繋がっている計算リソースに配置されている。

選手選択ボタン６１２は選択中状態で表示されるとともに、選手選択ボタン６１３，６１４は、非アクティブ化し、ゼッケン２ ベータ選手、および、ゼッケン３ ガンマ選手の映像配信を受け付けないように制御している。また、停止ボタン６１５はアクティブ化し、選択すると、映像配信を中止させることができる。インフォメーションバー６１６には、指定した選手（アルファ選手）およびリソースの種類、位置が表示されている。
図１８に示すように、ユーザは、指定した選手の最適な映像データを容易に視聴することができる。

なお、本発明は、上記した実施形態に限定されることなく、その趣旨を逸脱しない範囲で変更することができる。
例えば、リソースとして、音声のセンシング情報を検出するマイクリソースを用いることもできる。
また、本実施形態において、リソース検索装置１が各リソースからライブデータを収集する際、各リソースのメタデータを収集してもよい。
また、本実施形態では、リソース検索装置１が、ユーザ端末６からのリソース検索要求に含まれる検索対象の認識の一致度が最も高いライブデータを配信するリソースを検索した。しかし、リソース検索装置１が、ユーザ端末６からのリソース検索要求に含まれる検索対象の認識の一致度が所定値以上となるライブデータを配信するリソースを検索してもよい。

１ リソース検索装置
２−１〜２−３ サーバ
２ａ−１〜２ａ−３ 検索プログラム
３−１〜３−８ リソース
４−１〜４−３ ルータ
５−１〜５−３ 個別ＮＷ
６ ユーザ端末
１１ リソース検索ポータル部
１２ コンテキスト情報集約部
１３ コンテキスト流通部
１４ メタデータ管理部
１５ 配信制御部
１６，１６−１ シェアリソース管理部
１７ ネットワーク制御部

Claims (3)

1. 複数のネットワークに配置されている複数リソースから所望のリソースを検索するリソース検索装置であって、
   前記ネットワークの各々に配置されているサーバの位置情報を記憶する記憶部と、
   ユーザ端末からリソース検索要求を取得し、
   前記取得したリソース検索要求に含まれる位置情報に対応する前記サーバを特定し、
   前記リソース検索要求に含まれる検索プログラムを、前記特定したサーバに配置し、
   前記検索プログラムが配置されたサーバから、当該サーバが配置されているネットワークに配置されているリソースが配信するライブデータを収集し、
   前記収集したライブデータを用いて、前記リソース検索要求に含まれる検索対象の認識の一致度が所定値以上となるライブデータを配信するリソースを検索し、
   前記検索したリソースにアクセスするためのアクセス情報を前記ユーザ端末に送信する、制御部を備える、
   ことを特徴とするリソース検索装置。
2. 前記検索対象は、前記ユーザ端末が指定した移動体であり、
   前記検索プログラムは、前記移動体の画像認識と映像処理を行うアプリケーション、および、前記移動体のライブデータを検索するアプリケーションである、
   ことを特徴とする請求項１に記載のリソース検索装置。
3. 複数のネットワークに配置されている複数リソースから所望のリソースを検索するリソース検索装置におけるリソース検索方法であって、
   前記リソース検索装置は、前記ネットワークの各々に配置されているサーバの位置情報を記憶しており、
   ユーザ端末からリソース検索要求を取得するステップと、
   前記取得したリソース検索要求に含まれる位置情報に対応する前記サーバを特定するステップと、
   前記リソース検索要求に含まれる検索プログラムを、前記特定したサーバに配置するステップと、
   前記検索プログラムが配置されたサーバから、当該サーバが配置されているネットワークに配置されているリソースが配信するライブデータを収集するステップと、
   前記収集したライブデータを用いて、前記リソース検索要求に含まれる検索対象の認識の一致度が所定値以上となるライブデータを配信するリソースを検索するステップと、
   前記検索したリソースにアクセスするためのアクセス情報を前記ユーザ端末に送信するステップと、を実行する、
   ことを特徴とするリソース検索方法。

Images