JP6749281B2 - ＩｏＴデバイス、シグナリングサーバ、メッセージバス管理サーバ、コネクション形成方法、及びプログラム - Google Patents

Description

本発明は、ＩｏＴデバイスの遠隔制御技術に関連するものである。

近年のＩｏＴなどコンピューティング技術の進化に伴い、エンタープライズユースケースにおいては拠点オフィスや工場・販売店など、コンシューマーユースケースにおいては宅内などのエッジ環境にＩｏＴデバイスを設置し、センサデータの収集や、スマートフォンなどの端末を用いたモニタリングや操作などを行うことが一般的となってきている。

これを用いることで、例えば電力消費量の削減を実現できる。具体的には、例えば、
・ＩｏＴ対応の照明デバイスを導入し、スマートフォンを検知することで人が近づいた時には点灯し、遠ざかった時には自動消灯する。

・照度センサを搭載したＩｏＴデバイスと照明デバイスを連動し、外からの灯りに応じて、自動消灯や光量の制御を行う。
などを実現できる。

ここで、これらＩｏＴデバイスの制御は、エッジ環境のみならす、リモート環境からの利用も想定される。例えば、
・リモートから宅内の照明デバイスにアクセスし、消し忘れていた場合に消灯する。また、防犯目的のため夜間に点灯する。

・各拠点オフィスの照明状況をクラウドのサーバ環境にて収集し、本社企画部門は収集したデータを分析し、オフィス利用状況の把握や有効活用のためのプランを策定する。
といった例が考えられる。

特開２０１４−２４１０２４号公報

ＩｏＴデバイスを遠隔に制御するための従来技術として、ユーザ端末が直接にＩｏＴデバイスに接続する技術や、ユーザ端末がクラウド経由でＩｏＴデバイスに接続する技術などがある。しかしながら、直接にＩｏＴデバイスに接続する技術では、小規模システム以外では管理が複雑になり、また、クラウド経由でＩｏＴデバイスに接続する技術では、クラウドとの接続ＮＷの障害による影響が大きく、大規模システムには適用できないなどの課題がある。

本発明は上記の点に鑑みてなされたものであり、適用するシステムの規模に拠らずに、ＩｏＴデバイスの遠隔制御を適切に行うことを可能とする技術を提供することを目的とする。

開示の技術によれば、メッセージバス管理サーバ、シグナリングサーバ、ＩｏＴデバイスである第１のメッセージバスエージェント装置、及び、第２のメッセージバスエージェント装置を含むシステムにおいて、前記第１のメッセージバスエージェント装置として使用されるＩｏＴデバイスであって、
前記メッセージバス管理サーバから払い出された前記第２のメッセージバスエージェント装置のエージェントＩＤを接続先として指定したシグナリングメッセージを、前記シグナリングサーバに送信するシグナリング手段と、
前記シグナリングサーバによるシグナリングメッセージの処理に基づいて、前記第２のメッセージバスエージェント装置との間のコネクションを、仮想メッセージバスとして形成する接続手段とを備え、
前記メッセージバス管理サーバにより、前記ＩｏＴデバイスと前記第２のメッセージバスエージェント装置との接続が許可されている場合に、前記接続手段は、前記第２のメッセージバスエージェント装置との間に前記仮想メッセージバスを形成し、
前記仮想メッセージバスは、アプリケーションからの接続要求に応じて、動的に形成され、アプリケーションの終了に伴い解放されるメッセージバスである
ことを特徴とするＩｏＴデバイスが提供される。

開示の技術によれば、適用するシステムの規模に拠らずに、ＩｏＴデバイスの遠隔制御を適切に行うことを可能とする技術が提供される。

エッジのＩｏＴデバイスに、リモートからアクセスするパターンを示す図である。 クラウドからの集中制御のアーキテクチャを示す図である。 ハイブリッドアーキテクチャを示す図である。 各方式の特徴をまとめた表である。 本発明の実施の形態におけるシステム構成図である。 ＷＶＭＢ管理サーバ５００の構成図である。 シグナリングサーバ４００の構成図である。 ユーザ端末１００の構成図である。 エッジコンピューティング装置２００の構成図である。 ＩｏＴデバイス３００の構成図である。 クラウドコンピューティング装置６００の構成図である。 各装置のハードウェア構成の例を示す図である。 シーケンス例を示す図である。 ステップ４００のバリエーションを説明するための図である。 柔軟なアクセス制御を説明するための図である。 ＳＤ−ＷＡＮコントローラを使用する例を説明するための図である。

以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

（本実施の形態に係る技術の概要）
本実施の形態の技術を詳細に説明する前に、当該技術がどのような検討過程に基づき発明されたかについて説明する。

背景技術で説明した各ユースケースを実現するためには、該当のＩｏＴデバイスに対し、エッジ及びリモートの双方からアクセスできる必要がある。その単純な実現手段としては、エッジのＩｏＴデバイスに、エッジからだけではなく、リモートからも直接アクセスできるようにすることが考えられる。

リモートから直接アクセスできるようにすることを技術的にブレークダウンすると、例えば、図１に示すパターン１〜３がある。

パターン１では、エッジのＩｏＴデバイス１にグローバルアドレスを付与し、インターネット２から直接アクセスできるようにする。

パターン２では、エッジのＮＡＴ機器３に、アドレス変換ルールを設定し、インターネット２からＩｏＴデバイス１にアクセスできるようにする。

パターン３では、エッジにＶＰＮアクセスできるようにし、リモートからＶＰＮ機器４を用いてＶＰＮ接続することで、ＩｏＴデバイス１にアクセスできるようにする。

ここで、パターン１については、ＩＰｖ４アドレスが枯渇している現状において現実的とは言えない。ＩＰｖ６を用いることでアドレス利用の課題は解決できるが、インターネットからデバイスに直接アクセスできることは第三者により容易にエッジの機器を制御できることを意味するため、セキュリティ観点より望ましくない。パターン２については、ＩＰｖ４環境でも実現できるメリットはあるが、パターン１とほぼ同様の課題が存在する。また、ＮＡＴ機器３のアドレス変換ルールの設定には、ＩＰ技術に対する知識が必要となるため、その設定コストがかかってしまうという問題もある。パターン３については、エンタープライズユースケースであれば適用も現実的ではあるが、コンシューマーユースケースで各家庭にＶＰＮ機器４を設置し、利用するのは現実的とは言えない。また、ＶＰＮ接続してしまえば、誰でも各機器にアクセスできてしまうという問題もある。

パターン１〜３のいずれの場合も、エッジの拠点のデバイスに対するコントロールにおいては、社員の権限に応じたアクセス制御が要求されることが多い。例えば、一般社員は照明器具点灯状況のモニタリングのみ可能とし、特定部門の担当者のみ、照明オンオフのリモート操作を可能とするといったケースである。

また、拠点内に誤ってワームが侵入してしまった場合、容易に機器を操作されてしまうという問題もある。従って、単にＶＰＮ接続等を通してデバイスにアクセスできれば良いという問題ではなく、更にデバイスへのアクセスに際し、ユーザ認証を行うことが要求される。このため、ＬＤＡＰやＳＮＳ認証などのＩＤＭ（ＩＤ Ｍａｎａｇｅｍｅｎｔ）と連携したアクセス制御が必要となる。

しかしながら、このようなＩＤＭ機構を各デバイスに搭載し、設定することは管理の煩雑化を生む。また、それぞれのデバイスにアクセスするために、認証が必要となってしまうため、ユーザビリティの低下も生じてしまう。

これを解決する技術として、図２に示すクラウドからの集中制御の方式（アーキテクチャ）がある。このアーキテクチャでは、全てのデバイス１がクラウド１０上のＭＱＴＴやＫａｆｋａなどメッセージバス１１のみに接続し、ユーザ５の解析・制御システム等はこれを経由することで各デバイスのモニタリングや制御を可能としている。

このアーキテクチャを用いることで、先に挙げたユーザ権限に応じたＩＤＭ１２によるアクセス制御も容易となる。このアーキテクチャではユーザ５からのデバイス１の制御は、全てクラウド１０のサーバを経由するものとなる。従って、アクセス制御についても、このサーバで行えばよくなり、ＩＤＭ１２の管理コストを激減することができる。

しかしながら、このアーキテクチャにも欠点がある。このモデルでは、全てのデータがクラウド１０を経由するため、そのデータ量が甚大となってしまい、その処理コストが問題となる。また、各エッジにおいても、拠点デバイスを制御するためには必ずクラウド１０にアクセスしなければいけない。これは、アクセス集中時やネットワーク障害時などに操作性の欠如といった問題を引き起こす可能性がある。

これを解決するために、図３に示すような、クラウド１０とエッジコンピューティングを共に活用するハイブリッドアーキテクチャが考えられる。これは、エッジ環境にもＭＱＴＴなどのメッセージバス６とそれに接続するユーザ５の処理サーバ等をセットアップし、クラウド１０とエッジのコンピューティングを連携することでこれらの問題を解決しようとするアーキテクチャである。

照明制御を例にすると、照度センサや照明デバイス（ＩｏＴデバイス１の例）は全てエッジのメッセージバス６に接続される。ユーザ５のエッジコンピューティング環境は、このエッジメッセージバス６に接続し、そのセンサ値を常時監視する。閾値を超えた場合（例えば暗くなった場合）には、エッジより照明デバイスを操作し、照明のオンオフや光量の制御を行う。このように、処理は全てエッジのみで行われるため、クラウド１０の負荷上昇や、レスポンス性の悪化といった課題が解決される。また、クラウド１０へは例えば１分ごとの平均データのみや閾値を超えた場合のみのデータを送信することで、負荷上昇によるクラウドコストの抑制を実現できる。更に、ユーザ権限に応じたアクセス制御についても、クラウド１０とエッジコンピューティング環境のみにＩＤＭ１２との連携機能を入れれば良く、エッジの各デバイスにまで適用しなくてもよい。これによりアクセス制限の管理・制御コストを抑制することが可能となる。ただし、このようなハイブリッドアーキテクチャは、各デバイスを管理するのに比べればベターではあるが、図２に示したクラウド型に比べ、制御は複雑になる。

図４に示したように、各方式には一長一短があり、どの方式を用いるかはシステムの管理コストとスケーラビリティのトレードオフとなる。端的には、規模が小さければ直接接続型を使用し、規模の拡大に応じて、クラウド型やハイブリッド型を用いるのが典型的であると考えられる。従って、段階的に各方式を導入していくプランが現実的である。しかしながら、これら三方式は、共通したアーキテクチャとは言いがたく、その移行にあたっては移行策の策定を要する。また、利用者のシステムマニュアルの変更やその共有などの作業が必要となる。

このような問題が生じるのは、全てのリソースにアクセスするためには、そのデータを管理するサーバにアクセスしなければならないという前提に帰着する。近年のＩＴ環境の構成は、フロントエンドの描画系、ユーザ−ＩｏＴ間のデータを処理する制御ロジック系、データソース、及び、認証認可機構に分類される。端的には、フロントエンド描画系はダッシュボードサーバ、制御ロジック系は制御サーバ、データソースはＭＱＴＴやＫａｆｋａなどのデータバス、認証認可はＩＤＭとなる。そして、直接的・間接的いずれにしろこれらのサーバに接続できないとサービスを提供することはできない。すなわち、何かしらの手段（ＦＷでＤＭＺを配置する、ＶＰＮ接続するなど）でこれらそれぞれのサーバに対して常にＩＰリーチャブルである必要がある。

しかしながら、近年の端末環境の高性能化・低コスト化によりこの状況は変化してきている。すなわち、フロントエンド系や制御ロジック系はモバイルアプリなどに代表されるユーザアプリケーションとして提供できるため、必ずしもサーバにアクセスする必要はない。Ｗｅｂアプリケーションによるサービス提供にしても、Ｓｅｒｖｉｃｅ Ｗｏｒｋｅｒに代表されるオフライン化の進展によりこの状況は変わりつつある。しかしながら、データソースに対するサーバアクセスは回避できない。裏を返せば、これを解決し、常にリーチャブルなサーバ環境を経由せずともデータソースにアクセスできれば、これまでに挙げた各種問題を解決することができ、システムのスムーズな拡大・移行を行うことができる。

（システム構成、動作概要、特徴）
以下、本実施の形態に係るシステムの構成、動作概要、特徴を説明する。このシステムでは「ＷｅｂＲＴＣ ｖｉｒｔｕａｌ ｍｅｓｓａｇｅ ｂｕｓ」（ＷｅｂＲＴＣ仮想メッセージハブ）が用いられる。これを略してＷＶＭＢと呼ぶ。

ＷＶＭＢに係る技術は、Ｐ２Ｐ技術に基づくＷｅｂＲＴＣを用いることで、上記課題を解決し、小規模から大規模まで共通したアーキテクチャによりＩｏＴソリューションを提供可能とするものである。なお、本実施の形態で使用するＷｅｂＲＴＣはＰ２Ｐコネクションを確立するための技術の一例であり、これに限定されるわけではなく、本実施の形態において、ＷｅｂＲＴＣ以外のＰ２Ｐコネクション技術を用いることも可能である。

ＷｅｂＲＴＣではＩＣＥ（Ｉｎｔｅｒａｃｔｉｖｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｅｓｔａｂｌｉｓｈｍｅｎｔ）と呼ばれる技術を使用して、Ｐ２Ｐ通信に使用する２端末のアドレスを決定する。ＩＣＥでは、各端末が、利用可能なアドレスを収集し、端末間で、収集されたアドレスを交換して、通信可能なアドレスのうち優先度の高いアドレスを選択して通信を行う。ＷｅｂＲＴＣ以外のＰ２Ｐコネクション技術として、例えば、ＩＣＥを使用するＷｅｂＲＴＣ以外の技術を使用してもよいし、ＩＣＥ以外のアドレス決定方法を使用するＰ２Ｐコネクション技術を使用してもよい。

図５は、本実施の形態におけるシステム構成図である。図５に示すように、当該システムにおいて、クラウド１０内にシグナリングサーバ４００、ＷＶＭＢ管理サーバ５００、クラウドコンピューティング装置６００が備えられる。なお、クラウド１０内にこれらの装置が備えられることは、例えば、これらの装置が仮想マシンにより構築されていることを意味する。ただし、仮想マシンを用いることは例であり、クライド１０内であるかどうかに関わらずに、シグナリングサーバ４００、ＷＶＭＢ管理サーバ５００、クラウドコンピューティング装置６００がそれぞれ物理サーバであってもよい。

エッジの拠点２０（これをエッジ２０と記載してもよい）内にＩｏＴデバイス３００、エッジコンピューティング装置２００が備えられる。また、エッジコンピューティング装置２００やクラウドコンピューティング装置６００のサービスを利用するユーザ端末１００が存在する。これらの装置はネットワーク（本実施の形態では例としてインターネット２）を介して他の装置と通信を行うことが可能である。

より詳細には、ＷｅｂＲＴＣによるＰ２Ｐコネクション形成処理により、ネットワーク２上に構築されるデータチャネル（Ｐ２Ｐコネクションと称してもよい）を介して装置間の通信がなされる。このデータチャネルをＷｅｂＲＴＣ ｖｉｒｔｕａｌ ｍｅｓｓａｇｅ ｂｕｓ（ＷｅｂＲＴＣ仮想メッセージバス）（略してＷＶＭＢ）３０と称している。当該ＷＶＭＢ３０を経由して、データ収集、モニタリング等が実施される。また、Ｐ２Ｐコネクション形成においてはシグナリングサーバ４００による制御が行われる。シグナリングサーバ４００が、ＩＤＭなどと連携することでセキュアかつ柔軟な接続制御を行うことが可能である。なお、上記のシグナリングサーバ４００による制御とは、ＷｅｂＲＴＣによるＰ２Ｐコネクション確立のためのシグナリング制御（これ自体は既存技術）に加えて、後述するＡｇｅｎｔＩＤに基づくＷＶＭＢ管理サーバ５００（ＩＤＭの例）と連携した接続制御等を行うことである。

各装置の機能構成及び動作については後に詳細に説明する。ここでは動作概要及び特徴について説明する。

ＷＶＭＢ３０を実現するために、ユーザ端末１００、エッジコンピューティング装置２００、ＩｏＴデバイス３００、クラウドコンピューティング装置６００にＷＶＭＢエージェントをインストールし、接続要求に応じて、ＷｅｂＲＴＣのデータチャネルを構築し、互いの装置をＰ２Ｐ接続する。ここではＷｅｂＲＴＣを用いるため、各装置は常時ＩＰリーチャブルである必要がない点が特徴である。

ＷｅｂＲＴＣのシグナリングサーバ４００がユーザ端末１００からの接続要求時に、ＩＤＭと連携したアクセス制御を行い、許可されたユーザ端末１００に対して、接続先との間に動的にデータ接続用のＰ２Ｐコネクションを形成する。このＰ２Ｐの接続が仮想的なメッセージバスとして機能し、ユーザ端末１００がそれぞれのデータソースと通信するための機構となる。事前にＤＭＺ上にサーバを設置したり、ＶＰＮコネクションを形成したりする必要はない。全てのＰ２Ｐコネクション（データパス）は、ユーザアプリケーションからの接続要求に応じて、動的に形成され、アプリケーションの終了に伴い解放される。唯一、シグナリングサーバ４００への接続性は担保されている必要があるが、このシグナリングサーバ４００との通信は、ＷｅｂＲＴＣによるＰ２Ｐコネクション形成開始・終了時などにのみ行われ、常時データ通信が行われるものではない。このため、エッジデバイスの増加に対してもスケーラビリティを保ちやすい。

また、システムの段階的な移行が容易である点も特徴である。ＷＶＭＢでは、仮想的なメッセージバスを用いるため、具体的な装置がクラウドやエッジのどこにあっても構わず、ＷＶＭＢへの接続は、シグナリングサーバ４００によって要求に応じて柔軟に制御することができる。このため、例えば、システム導入の初期段階では、ユーザ端末１００は、ＩｏＴデバイスそのもの、あるいは、複数ＩｏＴデバイスを集約したエッジのデータ管理部にＷＶＭＢ接続すれば良い。また、クラウド型に移行する際には、ユーザ端末１００は、クラウドのデータ管理部にＷＶＭＢ接続すれば良い。ハイブリッド型を使用する際には、アクセスするクラウド／エッジの各データソースへの接続振り分けは、要求に応じてシグナリングサーバ４００が担ってくれる。よって、接続先のＩＰアドレスを事前に各フロントエンドや制御系に設定する必要はない。これにより、システムの移行やエッジの追加・削除・変更といったマネージメントコストを飛躍的に下げることができる。

ＩＰアドレスの変更に対しても柔軟である。特にエッジ環境ではデバイスへのＩＰアドレスはＤＨＣＰなどで与えられるケースが多く、デバイスの再起動によりＩＰアドレスが変更となることが多い。また近年ではクラウドコンピューティングとしてＩａａＳを利用することが多いが、これについてもＶＭ（仮想マシン）の再構築を行うと、内部のＩＰアドレスは変更されてしまうケースが殆どである。

ここで、ＷＶＭＢでは仮想メッセージバスの形成時にそれぞれのデバイスやクラウド側のサーバに固有で与えられるＩＤ（後述するＡｇｅｎｔ ＩＤ）を用いるため、仮想メッセージバスの形成はそれぞれの装置のＩＰアドレスには依存しない。このため、ＩＰアドレスの変更が頻繁に発生するエッジ環境やＩａａＳ環境においても問題なくシステムを稼働させることができる。

セキュリティの観点でも堅牢である。ＷＶＭＢではそれぞれのデバイスやエッジ／クラウドコンピューティング環境で外部アクセスポートを開ける必要がない。外部との通信は、常にシグナリングサーバ４００により形成されるＰ２Ｐコネクションによって行われる。このため、万が一エッジ環境などにマルウェアが侵入したとしても、それによるデバイスやコンピューティング環境への攻撃を困難にすることができる。更に、内部のデバイスやコンピューティング環境内にマルウェアが侵入した場合でも、シグナリングサーバ４００側でそれを検知した場合、Ｐ２Ｐコネクションの接続要求を拒否するなどのオペレーションを行うだけで、当該デバイスやコンピューティング環境をシステムから切り離すことができる。これにより、複雑に分散されたハイブリッド環境においても、装置間の接続やセキュリティマネージメントを統合的かつシンプルに実現することができる。

以下、各装置の構成及び動作の例を詳細に説明する。

（装置構成）
各装置の機能構成を図６〜図１１を参照して説明する。

図６は、ＷＶＭＢ管理サーバ５００の構成図である。ＷＶＭＢ管理サーバ５００は、各ＷＶＭＢエージェントを管理するサーバであり、ＡｇｅｎｔＩＤ払い出し部５１０、ＡｇｅｎｔＩＤ確認部５２０、ＡｇｅｎｔＩＤ蓄積部５３０、シグナリングサーバ接続部５４０を有する。

ＡｇｅｎｔＩＤ払い出し部５１０は、各ＷＶＭＢエージェントに、エージェント固有の一時的なＩＤを払い出す。払い出されたＩＤは後述のＡｇｅｎｔＩＤ蓄積部５３０に蓄積される。ＡｇｅｎｔＩＤ確認部５２０は、エージェント−エージェント間を接続してよいか確認する。確認に際しては、後述のＡｇｅｎｔＩＤ蓄積部５３０を参照する。

ＡｇｅｎｔＩＤ蓄積部５３０は、払い出されているＡｇｅｎｔ ＩＤを蓄積するデータベースである。例えば、Ａｇｅｎｔ ＩＤ１のエージェントとＡｇｅｎｔ ＩＤ２のエージェントを接続することを要求する接続要求に対する接続可否判断において、Ａｇｅｎｔ ＩＤ１とＡｇｅｎｔ ＩＤ２が、払い出されているＡｇｅｎｔ ＩＤとしてＡｇｅｎｔＩＤ蓄積部５３０に蓄積されている場合に、接続可であると判断できる。なお、これは一例である。

シグナリングサーバ接続部５４０は、シグナリングサーバ４００との接続処理及びデータ通信を行う機能部である。

図７は、シグナリングサーバ４００の構成図である。シグナリングサーバ４００は、ＷＶＭＢエージェント間をＷｅｂＲＴＣによりＰ２Ｐ接続するために、シグナリングメッセージを交換するサーバである。

図７に示すとおり、シグナリングサーバ４００は、ＷＶＭＢエージェント接続部４１０、エージェント間接続管理部４２０、シグナリングメッセージ処理部４３０、ＷＶＭＢ管理サーバ接続部４４０を有する。

ＷＶＭＢエージェント接続部４１０は、各ＷＶＭＢエージェントとの接続処理及びデータ通信を行う機能部である。エージェント間接続管理部４２０は、ＷＶＭＢ管理サーバ５００に問い合わせを行い、エージェント間の接続可否の判定、インターネット経由接続可否の判定などを行う。エージェント間接続管理部４２０は、例えば、ＷＶＭＢ管理サーバ５００に問い合わせを行うことなく、エージェント間の接続可否の判定を行う機能を備えてもよい。

シグナリングメッセージ処理部４３０は、エージェント間のシグナリングメッセージの中継処理を行う。シグナリングメッセージとして、例えば、オファーＳＤＰ（接続要求）、アンサーＳＤＰ、ＩＣＥ ｃａｎｄｉｄａｔｅ等がある。ＩＣＥ ｃａｎｄｉｄａｔｅがＳＤＰの中に含まれるシグナリングメッセージもある。

また、シグナリングメッセージ処理部４３０は、エージェント間接続管理部４２０からの指示に従い、メッセージの破棄や変更処理を行う。例えば、エージェント間接続不可の場合は当該エージェント間で送受信される全メッセージを破棄し、インターネット経由接続が不可の場合は、該当のＩＣＥ ｃａｎｄｉｄａｔｅメッセージ（例：ＳＴＵＮやＴＵＲＮで取得したアドレスを含むメッセージ）を破棄する。ＷＶＭＢ管理サーバ接続部４４０は、ＷＶＭＢ管理サーバ５００との接続処理やデータ通信を行う。

なお、ＷＶＭＢ管理サーバ５００とシグナリングサーバ４００を１つの装置として構成してもよい。１つの装置として構成する場合、本実施の形態で説明されるＷＶＭＢ管理サーバ５００とシグナリングサーバ４００との間のデータ送受信処理等は、当該１つの装置の内部の動作に相当する。

続いて、ユーザ端末１００、ＩｏＴデバイス３００、エッジコンピューティング装置２００、クラウドコンピューティング装置６００について説明する。これらの装置は、ＷＶＭＢを用い、互いに接続する装置である。ユーザ端末１００は、センサデータのモニタリング等を行う。ＩｏＴデバイス３００（例：センサ機器）は、センサデータをエッジコンピューティング装置２００に送信する等の処理を行う。エッジコンピューティング装置２００は、センサデータの収集とユーザ端末１００へのモニタリングデータの送信を行う。また、クラウドコンピューティング装置６００も、センサデータの収集とユーザ端末１００へのモニタリングデータの送信を行うことが可能である。

各装置はＷＶＭＢエージェントを内包しており、このエージェントを経由してＷｅｂＲＴＣのデータチャネルにより装置間のデータ通信が行われる。ユーザ端末１００、ＩｏＴデバイス３００、エッジコンピューティング装置２００、クラウドコンピューティング装置６００をいずれもメッセージバスエージェント装置と称してもよい。

図８は、ユーザ端末１００の構成図である。図８に示すように、ユーザ端末１００は、ＷＶＭＢエージェント１１０と、モニタリングを実行するモニタリングアプリケーション１２０を有する。

ＷＶＭＢエージェント１１０は、ＷＶＭＢの通信処理を行うエージェント部であり、アプリケーション接続部１１１、ＷＶＭＢ接続部１１２、シグナリングサーバ接続部１１３、ＡｇｅｎｔＩＤ登録部１１４を有する。

アプリケーション接続部１１１は、モニタリングアプリケーション１２０と接続し、モニタリングアプリケーション１２０から渡されたデータをＷＶＭＢ接続部１１２に送信したり、ＷＶＭＢ接続部１１２から渡されたデータをモニタリングアプリケーション１２０に送信する。ＷＶＭＢ接続部１１２は、他のＷＶＭＢエージェントと接続し、エージェント間でＷｅｂＲＴＣにより構築されたデータチャネルを用いたデータ送受信処理を行う。

シグナリングサーバ接続部１１３は、ＷＶＭＢエージェント間のＰ２Ｐ接続処理を行うため、シグナリングサーバ４００と接続し、シグナリングサーバ４００とシグナリングメッセージの送受信を行う。ＡｇｅｎｔＩＤ登録部１１４は、ＷＶＭＢ管理サーバ５００より払い出されたＡｇｅｎｔ ＩＤを登録する。

図９は、エッジコンピューティング装置２００の構成図である。図９に示すように、エッジコンピューティング装置２００は、ＷＶＭＢエージェント２１０と、エッジコンピューティングを実行するエッジコンピューティングアプリケーション２２０を有する。

図１０は、ＩｏＴデバイス３００の構成図である。当該ＩｏＴデバイス３００は、センサ機器であることを想定している。図１０に示すように、ＩｏＴデバイス３００は、ＷＶＭＢエージェント３１０と、センサ処理を実行するセンサアプリケーション３２０を有する。

図１１は、クラウドコンピューティング装置６００の構成図である。図１１に示すように、クラウドコンピューティング装置６００は、ＷＶＭＢエージェント６１０と、クラウドコンピューティングを実行するクラウドコンピューティングアプリケーション６２０を有する。

図９〜図１１に示すように、エッジコンピューティング装置２００、ＩｏＴデバイス３００、クラウドコンピューティング装置６００それぞれのＷＶＭＢエージェントの構成は、図８に示したＷＶＭＢエージェント１１０の構成と同様であり、その機能も同様である。

上述したＷＶＭＢ管理サーバ５００、シグナリングサーバ４００、ユーザ端末１００、エッジコンピューティング装置２００、ＩｏＴデバイス３００、クラウドコンピューティング装置６００はいずれも、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。図１２は、各装置のハードウェア構成例を示す図である。図１２の装置は、それぞれバスＢで相互に接続されているドライブ装置７００、補助記憶装置７０２、メモリ装置７０３、ＣＰＵ７０４、インタフェース装置７０５、表示装置７０６、及び入力装置７０７等を有する。

当該装置（ＷＶＭＢ管理サーバ５００、シグナリングサーバ４００、ユーザ端末１００、エッジコンピューティング装置２００、ＩｏＴデバイス３００、又は、クラウドコンピューティング装置６００）での処理を実現するプログラムは、例えば、ＣＤ−ＲＯＭ又はメモリカード等の記録媒体７０１によって提供される。プログラムを記憶した記録媒体７０１がドライブ装置７００にセットされると、プログラムが記録媒体７０１からドライブ装置７００を介して補助記憶装置７０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体７０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置７０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置７０３は、プログラムの起動指示があった場合に、補助記憶装置７０２からプログラムを読み出して格納する。ＣＰＵ７０４は、メモリ装置７０３に格納されたプログラムに従って当該装置に係る機能を実現する。インタフェース装置７０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置７０６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置７０７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。なお、ユーザ端末１００以外の装置においては、表示装置７０６及び／又は入力装置７０７を備えないこととしてもよい。

（動作例）
次に、上記のように構成される各装置からなるシステムにおける動作例（シーケンス例）を図１３のシーケンス図を参照して説明する。

なお、ここでは、一例として、エッジコンピューティングのケースについて説明する。具体的には、以下の処理内容を想定している。

（１）ＩｏＴデバイス３００（ここでは温度センサ）からＷＶＭＢを用い、エッジコンピューティング装置２００に毎秒データを送信し、エッジコンピューティング装置２００内のＤＢに保存する。

（２）ユーザはＷＶＭＢを用い、（１）で保存されたデータにアクセスし、それをダッシュボードＵＩ等のグラフで確認する。

＜ステップＳ１００：エッジコンピューティング環境の登録＞
図１３のステップＳ１０１において、エッジコンピューティング装置２００の初期設置時に、ＷＶＭＢ管理サーバ５００のＡｇｅｎｔＩＤ払い出し部５１０よりエッジコンピューティング装置２００固有で払い出されるＷＶＭＢ ａｇｅｎｔ ＩＤ（Ａｇｅｎｔ ＩＤ）を、ＷＶＭＢエージェント２１０におけるＡｇｅｎｔＩＤ登録部２１４へ登録する。なお、払い出し手段は特定の手段に限られないが、例えば、メールによる払い出し、専用のＷｅｂコンソールによる払い出し、オペレーターを経由した口頭での払い出し、などがある。

Ａｇｅｎｔ ＩＤの登録が完了すると、ステップＳ１０２において、ＷＶＭＢエージェント２１０は、シグナリングサーバ接続部２１３により、シグナリングサーバ４００へ接続する。

＜ステップＳ２００：ＩｏＴデバイスの登録とコンピューティング環境への接続＞
ステップＳ２０１において、ＩｏＴデバイス３００の初期設置時に、ＷＶＭＢ管理サーバ５００のＡｇｅｎｔＩＤ払い出し部５１０よりＩｏＴデバイス３００固有で払い出されるＡｇｅｎｔ ＩＤを、ＷＶＭＢエージェント３１０におけるＡｇｅｎｔＩＤ登録部３１４へ登録する。払い出し手段については前述したとおりである。

登録が完了すると、ステップＳ２０２において、ＷＶＭＢエージェント３１０はシグナリングサーバ接続部３１３によりシグナリングサーバ４００へ常時接続を開始する。接続を開始したら、ステップＳ２０３において、ＷＶＭＢエージェント３１０は、シグナリングサーバ４００に対して、ステップＳ１００で設定したエッジコンピューティング装置２００に対する接続要求（例：オファーＳＤＰ等のシグナリングメッセージ）の送信を、エッジコンピューティング装置２００のＡｇｅｎｔ ＩＤを指定することにより実行する。接続要求のシグナリングメッセージには接続元のＡｇｅｎｔ ＩＤも含まれる。

ステップＳ２０４において、シグナリングサーバ４００では、エージェント間接続管理部４２０が、接続元及び接続先のＡｇｅｎｔ ＩＤをＷＶＭＢ管理サーバ５００に問い合わせることで、接続元と接続先間の接続が許可されているかどうかを確認する。シグナリングサーバ４００は、接続が許可されていることを示す情報を受信した場合にのみ、シグナリングメッセージ処理部４３０により、シグナリングメッセージ（例：アンサーＳＤＰ）を対向のエッジコンピューティング装置２００のＷＶＭＢエージェント２１０に送信する（ステップＳ２０５）。

その後、例えばＩｏＴデバイス３００とエッジコンピューティング装置２００間で、シグナリングサーバ４００を介したＩＣＥ ｃａｎｄｉｄａｔｅメッセージの交換を経て、ステップＳ２０６において、ＩｏＴデバイス３００のＷＶＭＢエージェント３１０におけるＷＶＭＢ接続部３１２と、エッジコンピューティング装置２００のＷＶＭＢエージェント２１０におけるＷＶＭＢ接続部２１２とにより、ＩｏＴデバイス３００とエッジコンピューティング装置２００の間に、ＷｅｂＲＴＣによるデータチャネルのＰ２Ｐコネクションが形成され、双方向のデータ通信可能状態となる。

＜ステップＳ３００：センサデータの送信＞
ステップＳ３０１において、ＩｏＴデバイス３００におけるセンサアプリケーション３２０により毎秒取得したセンサデータをアプリケーション接続部３１１が受信すると、ＷＶＭＢ接続部３１２は、当該センサデータをエッジコンピューティング装置２００に送信する。

ステップＳ３０２において、ＷＶＭＢ接続部２１２によりデータを受信したエッジコンピューティング装置２００では、アプリケーション接続部２１１経由でエッジコンピューティングアプリケーション２２０にそのデータが渡され、それを内部のＤＢに保存する。

＜ステップＳ４００：ユーザによるセンサデータの確認＞
ステップＳ４０１において、ユーザ端末１００は、ＷＶＭＢ管理サーバ５００に接続し、ＷＶＭＢ管理サーバ５００よりエッジコンピューティング装置２００のＡｇｅｎｔ ＩＤを取得する。なお、この時、ユーザ端末１００に対して一時的なＡｇｅｎｔ ＩＤがＷＶＭＢ管理サーバ５００から付与される。

ステップＳ４０２において、ユーザ端末１００は、シグナリングサーバ４００に接続し、エッジコンピューティング装置２００のＡｇｅｎｔ ＩＤを指定することにより、エッジコンピューティング装置２００への接続要求を開始する。接続要求にはユーザ端末１００の一時的なＡｇｅｎｔ ＩＤも含まれる。

ステップＳ４０３において、シグナリングサーバ４００では、エージェント間接続管理部４２０が、接続元及び接続先のＡｇｅｎｔ ＩＤをＷＶＭＢ管理サーバ５００に問い合わせることで、接続元と接続先間の接続が許可されているかどうかを確認する。シグナリングサーバ４００は、接続が許可されていることを示す情報を受信した場合にのみ、シグナリングメッセージ処理部４３０により、シグナリングメッセージを対向のエッジコンピューティング装置２００のＷＶＭＢエージェント２１０に送信する（ステップＳ４０４）。

ステップＳ４０５において、ユーザ端末１００のＷＶＭＢエージェント１１０におけるＷＶＭＢ接続部１１２と、エッジコンピューティング装置２００のＷＶＭＢエージェント２１０におけるＷＶＭＢ接続部２１２とにより、ユーザ端末１００とエッジコンピューティング装置２００との間に、ＷｅｂＲＴＣによるデータチャネルのＰ２Ｐコネクションが形成され、双方向のデータ通信可能状態となる。

ステップＳ４０６において、エッジコンピューティング装置２００のアプリケーション２２０のＤＢに保存されたセンサデータは、ＷＶＭＢ接続部２１２により、ユーザ端末１００のＷＶＭＢ接続部１１２に送信され、当該センサデータをモニタリングアプリケーション１２０が取得する。モニタリングアプリケーション１２０により、ユーザ端末１００上でセンサデータのグラフ表示がなされる。

（バリエーション、効果など）
上記のステップＳ４００（ユーザによるセンサデータの確認）において、図１４に示すように、ユーザ端末１００はエッジの拠点２０のローカルＮＷに存在してもよいし、リモート環境に存在してもよい。ＷｅｂＲＴＣでは、前述したＩＣＥと呼ばれるプロトコルにより、ローカル・リモートに関わらずＰ２Ｐコネクションを形成することができる。このため、ユーザが接続しているＮＷ環境はどこでも良い。これにより、ユーザ端末１００の場所に応じた接続先の変更やＶＰＮ接続などが不要となる。

また、図１５に示すように、ユーザ端末１００によるリモートからのエッジコンピューティング装置２００等への接続を拒否したい場合には、シグナリングサーバ４００のシグナリングメッセージ処理部４３０が、ＩＣＥ ｃａｎｄｉｄａｔｅメッセージのうちリモート経由の経路候補情報を破棄すれば良い。これにより、ローカル環境からのみアクセス可能とすることも実現できる。リモート経由の経路候補情報は、例えば、ＮＡＴ ｔｒａｖｅｒｓａｌ接続を示す情報（ＳＴＵＮにより取得したグルーバルＩＰアドレス、及び／又は、ＴＵＲＮのグルーバルＩＰアドレスを含む情報）である。

また、上記制御を接続ユーザごとに行うことで、例えば管理者にはリモートからの接続を許可し、担当者はローカルＮＷ接続時のみアクセスを許すといった柔軟なアクセス制御が可能となる。また、接続先についても、単にリモート経由の経路候補を落とすのではなく、そのグローバルＩＰアドレスをチェックすることで、特定のリモート拠点からのアクセスは可能とするといった制御も可能である。

なお、上述した例では、一例としてエッジコンピューティング装置２００へのアクセスを取り上げているが、クラウドコンピューティング装置２００へのアクセスについても同様のフローで実現できる。

ハイブリッド環境においては、エッジコンピューティング装置２００及びクラウドコンピューティング装置６００の双方にＷＶＭＢエージェントをインストールし、互いの接続設定を行えば良い。上記の例で言えば、例えば、エッジ環境には毎秒のデータを保存しておき、更に、エッジのＷＶＭＢエージェント２１０がクラウド１０に対して、１分毎の平均データを送信する。ユーザは参照したいデータに応じて、接続するＷＶＭＢエージェントのＡｇｅｎｔ ＩＤを選択するだけでよい。このようにして、設置場所に依存しないロケーションフリーなデータアクセスが可能となる。

また、上記フローでは、データの送受信元（ＷＶＭＢエージェント）は、外部にポートを開放している必要がないことに留意されたい。既に説明したように、データコネクション（Ｐ２Ｐコネクション）は、随時シグナリングサーバ４００の制御により動的に形成される。このため、常時サービスポートを開けていることによる外部からのクラッキングは困難となる。本例では、ＯｕｔｇｏｉｎｇのＷｅｂＲＴＣに必要となるポート番号だけを開けていればよい。

更に、近年注目を集めているＳＤ−ＷＡＮ（Ｓｏｆｔｗａｒｅ Ｄｅｆｉｎｅｄ ＷＡＮ）と連携することで更にセキュリティを高めることができる。例えば、図１６に示すようにＳＤ−ＷＡＮコントローラ８００を備える。ＷＶＭＢへの接続時（Ｐ２Ｐコネクション形成時）に、シグナリングサーバ４００がＩＣＥより接続ＵＤＰポート番号などを抽出しておく。そして、シグナリングサーバ４００とＳＤ−ＷＡＮコントローラ８００とが連携し、ＳＤ−ＷＡＮコントローラ８００によりクラウド及びエッジのＦＷ（Ｆｉｒｅｗａｌｌ）設定を変更し、動的に接続可能とする。これにより、マルウェアなどが外部接続することを防ぐことができる。より具体的には、例えば、Ｏｕｔｇｏｉｎｇのポートは常時は禁止しておき、シグナリングサーバ４００からの要求に応じてＳＤ−ＷＡＮコントローラ８００が、Ｐ２Ｐ接続形成時のみそのポートや接続先アドレスを開放するというものである。もちろん、Ｐ２Ｐ切断時には開けたポートは禁止するように制御する。このようにして、更にセキュリティレベルを高めることができる。

（実施の形態のまとめ）
以上、説明したように、本実施の形態によれば、メッセージバス管理サーバ、シグナリングサーバ、第１のメッセージバスエージェント装置、及び、第２のメッセージバスエージェント装置を含むシステムにおいて、前記第１のメッセージバスエージェント装置として使用されるメッセージバスエージェント装置であって、前記メッセージバス管理サーバから払い出された前記第２のメッセージバスエージェント装置のエージェントＩＤを接続先として指定したシグナリングメッセージを、前記シグナリングサーバに送信するシグナリング手段と、前記シグナリングサーバによるシグナリングメッセージの処理に基づいて、前記第２のメッセージバスエージェント装置との間のコネクションを、仮想メッセージバスとして形成する接続手段とを備えることを特徴とするメッセージバスエージェント装置が提供される。ユーザ端末１００、エッジコンピューティング装置２００、ＩｏＴデバイス３００、クラウドコンピューティング装置６００はいずれもメッセージバスエージェント装置の例である。

例えば、前記メッセージバス管理サーバにより、前記メッセージバスエージェント装置と前記第２のメッセージバスエージェント装置との接続が許可されている場合に、前記接続手段は、前記第２のメッセージバスエージェント装置との間のコネクションを形成する。

また、本実施の形態によれば、メッセージバス管理サーバ、シグナリングサーバ、第１のメッセージバスエージェント装置、及び、第２のメッセージバスエージェント装置を含むシステムにおける前記シグナリングサーバであって、前記第１のメッセージバスエージェント装置から、前記メッセージバス管理サーバから払い出された前記第２のメッセージバスエージェント装置のエージェントＩＤを接続先として指定したシグナリングメッセージを受信する受信手段と、前記メッセージバス管理サーバに、前記第１のメッセージバスエージェント装置と前記第２のメッセージバスエージェント装置との間の接続可否を問い合わせ、接続可である場合に、前記第２のメッセージバスエージェント装置にシグナリングメッセージを送信する送信手段とを備えることを特徴とするシグナリングサーバが提供される。シグナリングサーバ４００は、上記シグナリングサーバの例である。

また、本実施の形態により、メッセージバス管理サーバ、シグナリングサーバ、第１のメッセージバスエージェント装置、及び、第２のメッセージバスエージェント装置を含むシステムにおける前記メッセージバス管理サーバであって、各メッセージバスエージェント装置に対するエージェントＩＤを払い出す払い出し手段と、前記第２のメッセージバスエージェント装置のエージェントＩＤを接続先として指定したシグナリングメッセージを前記第１のメッセージバスエージェント装置から受信した前記シグナリングサーバから、前記第１のメッセージバスエージェント装置と前記第２のメッセージバスエージェント装置との間の接続可否の問い合わせを受信し、接続可否の判断結果を前記シグナリングサーバに送信する送信手段とを備えることを特徴とするメッセージバス管理サーバが提供される。ＷＶＭＢ管理サーバ５００は、メッセージバス管理サーバの例である。

（第１項）
メッセージバス管理サーバ、シグナリングサーバ、第１のメッセージバスエージェント装置、及び、第２のメッセージバスエージェント装置を含むシステムにおいて、前記第１のメッセージバスエージェント装置として使用されるメッセージバスエージェント装置であって、
前記メッセージバス管理サーバから払い出された前記第２のメッセージバスエージェント装置のエージェントＩＤを接続先として指定したシグナリングメッセージを、前記シグナリングサーバに送信するシグナリング手段と、
前記シグナリングサーバによるシグナリングメッセージの処理に基づいて、前記第２のメッセージバスエージェント装置との間のコネクションを、仮想メッセージバスとして形成する接続手段と
を備えることを特徴とするメッセージバスエージェント装置。
（第２項）
前記メッセージバス管理サーバにより、前記メッセージバスエージェント装置と前記第２のメッセージバスエージェント装置との接続が許可されている場合に、前記接続手段は、前記第２のメッセージバスエージェント装置との間のコネクションを形成する
ことを特徴とする第１項に記載のメッセージバスエージェント装置。
（第３項）
メッセージバス管理サーバ、シグナリングサーバ、第１のメッセージバスエージェント装置、及び、第２のメッセージバスエージェント装置を含むシステムにおける前記シグナリングサーバであって、
前記第１のメッセージバスエージェント装置から、前記メッセージバス管理サーバから払い出された前記第２のメッセージバスエージェント装置のエージェントＩＤを接続先として指定したシグナリングメッセージを受信する受信手段と、
前記メッセージバス管理サーバに、前記第１のメッセージバスエージェント装置と前記第２のメッセージバスエージェント装置との間の接続可否を問い合わせ、接続可である場合に、前記第２のメッセージバスエージェント装置にシグナリングメッセージを送信する送信手段と
を備えることを特徴とするシグナリングサーバ。
（第４項）
メッセージバス管理サーバ、シグナリングサーバ、第１のメッセージバスエージェント装置、及び、第２のメッセージバスエージェント装置を含むシステムにおける前記メッセージバス管理サーバであって、
各メッセージバスエージェント装置に対するエージェントＩＤを払い出す払い出し手段と、
前記第２のメッセージバスエージェント装置のエージェントＩＤを接続先として指定したシグナリングメッセージを前記第１のメッセージバスエージェント装置から受信した前記シグナリングサーバから、前記第１のメッセージバスエージェント装置と前記第２のメッセージバスエージェント装置との間の接続可否の問い合わせを受信し、接続可否の判断結果を前記シグナリングサーバに送信する送信手段と
を備えることを特徴とするメッセージバス管理サーバ。
（第５項）
メッセージバス管理サーバ、シグナリングサーバ、第１のメッセージバスエージェント装置、及び、第２のメッセージバスエージェント装置を含むシステムにおいて、前記第１のメッセージバスエージェント装置として使用されるメッセージバスエージェント装置が実行するコネクション形成方法であって、
前記メッセージバス管理サーバから払い出された前記第２のメッセージバスエージェント装置のエージェントＩＤを接続先として指定したシグナリングメッセージを、前記シグナリングサーバに送信するシグナリングステップと、
前記シグナリングサーバによるシグナリングメッセージの処理に基づいて、前記第２のメッセージバスエージェント装置との間のコネクションを、仮想メッセージバスとして形成する接続ステップと
を備えることを特徴とするコネクション形成方法。
（第６項）
コンピュータを、第１項又は第２項に記載のメッセージバスエージェント装置における各手段として機能させるためのプログラム。
（第７項）
コンピュータを、第３項に記載のシグナリングサーバにおける各手段として機能させるためのプログラム。
（第８項）
コンピュータを、第４項に記載のメッセージバス管理サーバにおける各手段として機能させるためのプログラム。
以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１００ ユーザ端末
１１０、２１０、３１０、６１０ ＷＶＭＢエージェント
１１１、２１１、３１１、６１１ アプリケーション接続部
１１２、２１２、３１２、６１２ ＷＶＭＢ接続部
１１３、２１３、３１３、６１３ シグナリングサーバ接続部
１１４、２１４、３１４、６１４ ＡｇｅｎｔＩＤ登録部
１２０ モニタリングアプリケーション
２００ エッジコンピューティング装置
２２０ エッジコンピューティングアプリケーション
３００ ＩｏＴデバイス
３２０ センサアプリケーション
４００ シグナリングサーバ
４１０ ＷＶＭＢエージェント接続部
４２０ エージェント間接続管理部
４３０ シグナリングメッセージ処理部
４４０ ＷＶＭＢ管理サーバ接続部
５００ ＷＶＭＢ管理サーバ
５１０ ＡｇｅｎｔＩＤ払い出し部
５２０ ＡｇｅｎｔＩＤ確認部
５３０ ＡｇｅｎｔＩＤ蓄積部
５４０ シグナリングサーバ接続部
６００ クラウドコンピューティング装置
６２０ クラウドコンピューティングアプリケーション
７００ ドライブ装置
７０１ 記録媒体
７０２ 補助記憶装置
７０３ メモリ装置
７０４ ＣＰＵ
７０５ インタフェース装置
７０６ 表示装置
７０７ 入力装置

Claims (7)

1. メッセージバス管理サーバ、シグナリングサーバ、ＩｏＴデバイスである第１のメッセージバスエージェント装置、及び、第２のメッセージバスエージェント装置を含むシステムにおいて、前記第１のメッセージバスエージェント装置として使用されるＩｏＴデバイスであって、
   前記メッセージバス管理サーバから払い出された前記第２のメッセージバスエージェント装置のエージェントＩＤを接続先として指定したシグナリングメッセージを、前記シグナリングサーバに送信するシグナリング手段と、
   前記シグナリングサーバによるシグナリングメッセージの処理に基づいて、前記第２のメッセージバスエージェント装置との間のコネクションを、仮想メッセージバスとして形成する接続手段とを備え、
   前記メッセージバス管理サーバにより、前記ＩｏＴデバイスと前記第２のメッセージバスエージェント装置との接続が許可されている場合に、前記接続手段は、前記第２のメッセージバスエージェント装置との間に前記仮想メッセージバスを形成し、
   前記仮想メッセージバスは、アプリケーションからの接続要求に応じて、動的に形成され、アプリケーションの終了に伴い解放されるメッセージバスである
   ことを特徴とするＩｏＴデバイス。
2. メッセージバス管理サーバ、シグナリングサーバ、ＩｏＴデバイスである第１のメッセージバスエージェント装置、及び、第２のメッセージバスエージェント装置を含むシステムにおける前記シグナリングサーバであって、
   前記ＩｏＴデバイスから、前記メッセージバス管理サーバから払い出された前記第２のメッセージバスエージェント装置のエージェントＩＤを接続先として指定したシグナリングメッセージを受信するシグナリングメッセージ処理部と、
   前記メッセージバス管理サーバに、前記ＩｏＴデバイスと前記第２のメッセージバスエージェント装置との間の接続可否を問い合わせ、前記メッセージバス管理サーバにより、前記ＩｏＴデバイスと前記第２のメッセージバスエージェント装置との間が接続可であると判定された場合に、前記メッセージバス管理サーバから、接続可であることを示す情報を受信するエージェント間接続管理部と、を備え、
   前記シグナリングメッセージ処理部は、前記ＩｏＴデバイスと前記第２のメッセージバスエージェント装置との間が接続可である場合に、前記第２のメッセージバスエージェント装置にシグナリングメッセージを送信し、
   前記シグナリングメッセージに基づいて、前記ＩｏＴデバイスと前記第２のメッセージバスエージェント装置との間に仮想メッセージバスが形成され、
   前記仮想メッセージバスは、アプリケーションからの接続要求に応じて、動的に形成され、アプリケーションの終了に伴い解放されるメッセージバスである
   ことを特徴とするシグナリングサーバ。
3. メッセージバス管理サーバ、シグナリングサーバ、ＩｏＴデバイスである第１のメッセージバスエージェント装置、及び、第２のメッセージバスエージェント装置を含むシステムにおける前記メッセージバス管理サーバであって、
   各メッセージバスエージェント装置に対するエージェントＩＤを払い出すエージェントＩＤ払い出し部と、
   払い出されているエージェントＩＤを蓄積するエージェントＩＤ蓄積部と、
   前記第２のメッセージバスエージェント装置のエージェントＩＤを接続先として指定したシグナリングメッセージを前記ＩｏＴデバイスから受信した前記シグナリングサーバから、前記ＩｏＴデバイスと前記第２のメッセージバスエージェント装置との間の接続可否の問い合わせを受信するシグナリングサーバ接続部と、
   前記ＩｏＴデバイスのエージェントＩＤと前記第２のメッセージバスエージェント装置のエージェントＩＤが前記エージェントＩＤ蓄積部に蓄積されているか否かを確認することにより、前記ＩｏＴデバイスと前記第２のメッセージバスエージェント装置との間の接続可否の判断を行うエージェントＩＤ確認部と、を備え、
   前記シグナリングサーバ接続部は、前記判断の結果を前記シグナリングサーバに送信し、
   前記ＩｏＴデバイスと前記第２のメッセージバスエージェント装置との間が接続可である場合に、前記ＩｏＴデバイスと前記第２のメッセージバスエージェント装置との間に仮想メッセージバスが形成され、
   前記仮想メッセージバスは、アプリケーションからの接続要求に応じて、動的に形成され、アプリケーションの終了に伴い解放されるメッセージバスである
   ことを特徴とするメッセージバス管理サーバ。
4. メッセージバス管理サーバ、シグナリングサーバ、ＩｏＴデバイスである第１のメッセージバスエージェント装置、及び、第２のメッセージバスエージェント装置を含むシステムにおいて、前記第１のメッセージバスエージェント装置として使用されるＩｏＴデバイスが実行するコネクション形成方法であって、
   前記メッセージバス管理サーバから払い出された前記第２のメッセージバスエージェント装置のエージェントＩＤを接続先として指定したシグナリングメッセージを、前記シグナリングサーバに送信するシグナリングステップと、
   前記シグナリングサーバによるシグナリングメッセージの処理に基づいて、前記第２のメッセージバスエージェント装置との間のコネクションを、仮想メッセージバスとして形成する接続ステップとを備え、
   前記メッセージバス管理サーバにより、前記ＩｏＴデバイスと前記第２のメッセージバスエージェント装置との接続が許可されている場合に、前記接続ステップにおいて、前記第２のメッセージバスエージェント装置との間に前記仮想メッセージバスを形成し、
   前記仮想メッセージバスは、アプリケーションからの接続要求に応じて、動的に形成され、アプリケーションの終了に伴い解放されるメッセージバスである
   ことを特徴とするコネクション形成方法。
5. コンピュータを、請求項１に記載のＩｏＴデバイスにおける各手段として機能させるためのプログラム。
6. コンピュータを、請求項２に記載のシグナリングサーバにおける各部として機能させるためのプログラム。
7. コンピュータを、請求項３に記載のメッセージバス管理サーバにおける各部として機能させるためのプログラム。

Images