JP2019040579A - メッセージプッシュシステム、クライアント装置およびそのメッセージプッシュ方法 - Google Patents

Abstract

【課題】軽量なメッセージ配信を行うメッセージプッシュシステム、クライアント装置及びメッセージプッシュ方法を提供する。【解決手段】クライアント装置３００は、ローカルネットワークに存在し、ローカルネットワーク及び外部ネットワークを介してローカルサーバ４００並びにリモートサーバ５００に登録される。クライアント装置は、パブリッシュ／サブスクライブメカニズムに基づいて、ローカルネットワーク及びリモートネットワークのうちの少なくとも１つを介してメッセージをパブリッシュ又はサブスクライブする。ローカルネットワーク又は外部ネットワークを介して別のクライアント装置をいずれかのサーバに接続できれば、クライアント装置を外部ネットワークに接続できるかどうかにかかわらず、パブリッシュされるメッセージをクライアント装置に送信でき、クライアント装置からパブリッシュされる別のメッセージを正常に受信できる。【選択図】図４

Description

本開示は、メッセージ配信方法に関し、特にメッセージプッシュシステム、クライアント装置およびそのメッセージプッシュ方法に関する。

技術の急速な発展に伴い、センサ、従来の家電製品、照明装置、スイッチ装置などの種々の電子装置がメッセージを送受信したり、他の装置から制御を受けたり、あるいは他の装置を通じて情報を収集したりすることができるように、これらの装置で徐々に、かつ幅広く通信機能の活用が進んでいる。

一部の電子装置のハードウェア仕様では、通信機能において高ネットワーク帯域幅、複雑な通信プロトコル、または高いハードウェア要件を実現できていないが、これらの電子装置では、パブリッシュ／サブスクライブ（ＰｕｂＳｕｂ）メカニズムを通じて、より低いネットワーク帯域幅とそれほど高度ではないハードウェアリソースとを使用することによってもメッセージ配信を実現できる。さらに、ユーザによる他の装置を通じたやりとりを容易にするために、一部のサービスプロバイダは物のインターネット（ＩｏＴ）ベースのクラウドプラットフォームを立ち上げて、種々のネットワークサービスを提供している。図１Ａおよび図１Ｂは、従来のパブリッシュ／サブスクライブメカニズムを示す概略図である。まず図１Ａを参照すると、モバイルクライアント装置１１がクラウドプラットフォーム１２からトピックＡ（たとえば、電球の状態）をサブスクライブし、また固定クライアント装置１３がクラウドプラットフォーム１２からトピックＢ（たとえば、照明の点灯／消灯）をサブスクライブすることが想定される。モバイルクライアント装置１１は、トピックＢに関連する照明点灯のメッセージをクラウドプラットフォーム１２にパブリッシュし（ステップＳ１５）、クラウドプラットフォーム１２は、トピックＢのサブスクライバすべて（固定クライアント装置１３を含む）にメッセージを送信する。固定クライアント装置１３はＺ−Ｗａｖｅ技術によって電球１４を点灯し、電球１４が点灯したという状態を取得し、かつクラウドプラットフォーム１２に当該状態をパブリッシュすることができ、これにより、トピックＡのサブスクライバすべて（すなわち、モバイルクライアント装置１１）に当該状態が送信される。

しかしながら、図１Ｂを参照すると、モバイルクライアント装置１１をインターネットに接続できない場合には、上記の動作プロセスを正常に完了することができない。モバイルクライアント装置１１と固定クライアント装置１３とが同一のローカルエリアネットワークに存在していても、モバイルクライアント装置１１は、クラウドプラットフォーム１２への接続の失敗により、サービス動作を実行できない。したがって、現行のサービスアーキテクチャは依然として改善を要する。

したがって、本開示は、メッセージプッシュシステム、クライアント装置およびそのメッセージプッシュ方法を提供し、これにより、ローカルエリアネットワークにも存在するサーバを追加することができ、その結果、クライアント装置が様々なサービスのためのインターネットへの接続ができないという問題を解決する。

本開示のメッセージプッシュシステムは、第１のサーバと、第２のサーバと、第１のク
ライアント装置とを備える。第１のサーバは第１のネットワークに存在する。第２のサーバは第２のネットワークに存在し、第２のネットワークは第１のネットワークとは異なる。第１のクライアント装置は第１のネットワークに存在し、第１のサーバおよび第２のサーバに登録し、かつパブリッシュ／サブスクライブメカニズムに基づいて、第１のサーバおよび第２のサーバのうちの少なくとも１つを介してメッセージを送受信する。

本開示の一実施形態では、第１のクライアント装置は第１のサーバおよび第２のサーバの両方にサブスクライブし、かつ第１のサーバおよび第２のサーバの両方にパブリッシュする。

本開示の一実施形態では、メッセージプッシュシステムは第２のクライアント装置をさらに備える。第２のクライアント装置は、第１のサーバまたは第２のサーバのどちらにサブスクライブするかを決定する。

本開示の一実施形態では、第２のクライアント装置は、第１のサーバおよび第２のサーバのうちの１つから、第１のクライアント装置によってパブリッシュされるトピックをサブスクライブする。

本開示の一実施形態では、第１のクライアント装置は、第１のサーバおよび第２のサーバの両方から、第２のクライアント装置によってパブリッシュされるトピックをサブスクライブする。

本開示の一実施形態では、第１のクライアント装置は第１のサーバの動作を実行する。

本開示のメッセージプッシュ方法は、第１のネットワークに存在するサーバを設置するステップと、第１のネットワークおよび第１のネットワークとは異なる第２のネットワークを介して登録メッセージを送信するステップと、パブリッシュ／サブスクライブメカニズムに基づいて、第１のサーバおよび第２のサーバのうちの少なくとも１つを介してメッセージを送受信するステップとを含む。

本開示の一実施形態では、パブリッシュ／サブスクライブメカニズムに基づいて、第１のサーバおよび第２のサーバのうちの少なくとも１つを介してメッセージを送受信するステップは、第１のネットワークおよび第２のネットワークの両方を介してサブスクライブすることと、第１のネットワークおよび第２のネットワークの両方を介してパブリッシュすることとを含む。

さらに、本開示のクライアント装置は第１のネットワークに存在し、かつ通信回路およびプロセッサを備える。通信回路はメッセージを送受信するように構成されている。プロセッサは通信回路に接続されており、通信回路を通じ、第１のネットワークおよび第２のネットワークを介して登録メッセージを送信し、かつパブリッシュ／サブスクライブメカニズムに基づいて、第１のネットワークおよび第１のネットワークとは異なる第２のネットワークのうちの１つを介してメッセージを送受信するように構成されている。

本開示の一実施形態では、プロセッサは通信回路を通じ、第１のネットワークおよび第２のネットワークの両方を介してサブスクライブし、かつ第１のネットワークおよび第２のネットワークの両方を介してパブリッシュする。

本開示の一実施形態では、パブリッシュ／サブスクライブメカニズムはメッセージ・キュー・テレメトリ・トランスポート（ＭＱＴＴ）プロトコルに準拠している。

上記に基づいて、クライアント装置は、異なるネットワークに存在するサーバに登録した後、２つのサーバのトピックをサブスクライブしたり、またはこれらにメッセージをパブリッシュしたりすることができる。別のクライアント装置が同一のトピックをサブスクライブしているか、またはこれをパブリッシュしている場合、第２のネットワークに存在する第２のサーバは切断状態にあるかどうかにかかわらず、依然として第１のネットワークを介して正常にメッセージをパブリッシュしたり、サブスクライブされるメッセージを受信したりすることができる。

本開示における上記および他の特徴ならびに利点をより理解可能にするために、図面を伴ういくつかの実施形態について、以下に詳細に説明する。

添付の図面は、本開示のさらなる理解をもたらすために含まれ、かつ本明細書に組み込まれると共に、本明細書の一部を構成している。図面は本開示の実施形態を示し、かつその記載と共に、本開示の原理を説明する役割を果たしている。

従来のパブリッシュ／サブスクライブメカニズムを示す概略図である。 従来のパブリッシュ／サブスクライブメカニズムを示す概略図である。

本開示の一実施形態によるメッセージプッシュシステムを示す概略図である。

本開示の一実施形態によるクライアント装置を示すブロック図である。

本開示の一実施形態による、リモートアクセスシナリオにおけるメッセージプッシュ方法を示すメッセージフローチャートである。

本開示の一実施形態による、ローカルアクセスシナリオにおけるメッセージプッシュ方法を示すメッセージフローチャートである。

クライアント装置をワイドエリアネットワークに接続することができ、また別のクライアント装置がローカルエリアネットワークに存在することを示す、第１のシナリオ例の概略図である。 クライアント装置をワイドエリアネットワークに接続することができ、また別のクライアント装置がローカルエリアネットワークに存在することを示す、第１のシナリオ例の概略図である。

クライアント装置をワイドエリアネットワークに接続できず、また別のクライアント装置がローカルエリアネットワークに存在することを示す、第２のシナリオ例の概略図である。

クライアント装置をワイドエリアネットワークに接続することができ、また別のクライアント装置がローカルエリアネットワークに存在することを示す、第３のシナリオ例の概略図である。 クライアント装置をワイドエリアネットワークに接続することができ、また別のクライアント装置がローカルエリアネットワークに存在することを示す、第３のシナリオ例の概略図である。

図２は、本開示の一実施形態によるメッセージプッシュシステム１を示す概略図である。メッセージプッシュシステム１は、１台以上の被制御装置２１０と、クライアント装置３００と、ローカルサーバ４００と、ネットワークアクセス装置２３０と、リモートサーバ５００と、クライアント装置６００とを備える。

被制御装置２１０は、Ｚ−Ｗａｖｅ、Ｂｌｕｅｔｏｏｔｈ、Ｗｉ−Ｆｉ、ＺｉｇＢｅｅ通信技術またはメッセージを送受信するための他の無線通信技術をサポートするスマート電球、インテリジェント・リモートコントロール・スイッチ、インテリジェント・ドアロックおよびインテリジェント・センサなどの電子装置であってもよい。

図３は、本開示の一実施形態によるクライアント装置を示すブロック図である。図３を参照すると、クライアント装置３００は、ネットワーク接続回路３１０と、デバイス通信回路３２０と、プロセッサ３３０とを少なくとも含むが、これらに限定されない。ネットワーク接続回路３１０は、無線通信技術（たとえば、Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ、第４世代（４Ｇ）移動通信（ロングタームエボリューション（ＬＴＥ）通信）または有線通信技術（たとえば、イーサネット、光ファイバ通信）をサポートするネットワークインターフェースカード、プロセッサ、回路またはチップセットであってもよく、またネットワーク接続回路３１０は、メッセージ・キュー・テレメトリ・トランスポート（ＭＱＴＴ）プロトコルに準拠している。クライアント装置３００が被制御装置２１０と通信できるように、デバイス通信回路３２０は、被制御装置２１０と同様または類似の無線通信技術をサポートするネットワークインターフェースカード、プロセッサ、回路またはチップセットであってもよい。プロセッサ３３０はネットワーク接続回路３１０およびデバイス通信回路３２０に接続されている。プロセッサ３３０は中央処理装置（ＣＰＵ）、または他の任意のプログラマブル汎用マイクロプロセッサもしくは専用マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、プログラマブルコントローラ、特定用途向け集積回路（ＡＳＩＣ）、あるいは他の同様の構成要素もしくは上記の構成要素の組み合わせであってもよい。本実施形態では、プロセッサ３３０はクライアント装置３００のすべての動作を実行するように構成されている。

なお、他の実施形態では、クライアント装置３００はまた、ＭＱＴＴプロトコルに準拠する、たとえばスマート電球、インテリジェント・リモートコントロール・スイッチ、インテリジェント・ドアロック、およびインテリジェント・センサなどの電子装置であってもよい。

ローカルサーバ４００は、ＭＱＴＴプロトコルをサポートするブローカとして使用され、クライアント装置３００または６００から特定のトピックに対するサブスクライブ要求を受信し、かつ／またはパブリッシュされるメッセージをサブスクライバ（たとえば、クライアント装置３００または６００）に送信しており、これはパブリッシュ／サブスクライブ（ＰｕｂＳｕｂ）メカニズムと呼ばれている。本実施形態では、相互から分離され、かつ相互に通信可能な２台のソフトウェアモジュールを介して、クライアント装置３００およびローカルサーバ４００それぞれの動作をクライアント装置３００が実行できるように、クライアント装置３００とローカルサーバ４００とが１つに統合されている（すなわち、両者は同一の装置内にある）。さらに、クライアント装置３００およびローカルサーバ４００は、共にローカルエリアネットワーク（ＬＡＮ）２５０（またはローカルネットワークと呼ばれる）に存在する。

他の実施形態では、クライアント装置３００およびローカルサーバ４００はまた、２つの独立した装置であってもよく、かつ無線／有線方式で相互に通信することができる。

ＬＡＮ２５０に存在するクライアント装置３００をワイドエリアネットワーク（ＷＡＮ
）２７０（または外部ネットワークと呼ばれる）またはインターネットに接続できるように、ネットワークアクセス装置２３０は、ＬＡＮインターフェースカード、プロセッサ、回路またはチップセット（たとえば、Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈまたはイーサネット通信技術をサポートするインターフェース）およびＷＡＮインターフェースカード、プロセッサ、回路またはチップセット（たとえば、デジタル・サブスクライバ・ライン（ＤＳＬ）をサポートする銅ケーブル、パッシブ光ネットワーク（ＰＯＮ）をサポートする光ファイバ、もしくは他の通信技術）を少なくとも有する。

リモートサーバ５００はＭＱＴＴプロトコルに準拠したクラウドブローカであり、Ａｍａｚｏｎ Ｗｅｂサービス（ＡＷＳ）、ＧｏｏｇｌｅクラウドＩｏＴサービス、またはＭｉｃｒｏｓｏｆｔ Ａｚｕｒｅ ＩｏＴサービスなどの物のインターネット（ＩｏＴ）クラウドソリューションを提供することができる。同様の、または類似の方法で、リモートサーバ５００はクライアント装置３００または６００から特定のトピックに対するサブスクライブ要求を受信し、かつ／またはパブリッシュされるメッセージをサブスクライバ（たとえば、クライアント装置３００または６００）に送信することができる。また、リモートサーバ５００はＷＡＮ２７０（または外部ネットワークと呼ばれる）に存在する。

クライアント装置６００は、たとえばスマートフォン、タブレットコンピュータまたはノートパソコンなどのモバイル装置であってもよく、またこれをローカルサーバ４００またはリモートサーバ５００に接続することができる。クライアント装置６００は、ユーザが被制御装置２１０または取得した関連情報を制御するために、リモートサーバ５００によって提供されるサービスに適合するアプリケーションをさらにロードすることができる。

なお、他の実施形態では、ローカルサーバ４００およびリモートサーバ５００はまた、ＰｕｂＳｕｂメカニズムに基づいて、簡易通知サービス（ＳＮＳ）、ならびに拡張可能なメッセージングおよびプレゼンスプロトコル（ＸＭＰＰ）などの他のブローカをサポートしていてもよく、クライアント装置３００または６００は、同様の、または適合する通信プロトコルをサポートしている。また、ローカルサーバ４００およびリモートサーバ５００は、２つの異なるネットワークに存在する限り、本実施形態に適用可能である。

本実施形態では、クライアント装置６００は、ネットワークアクセス装置２３０を介してローカルサーバ４００に接続する。しかしながら、他の実施形態では、クライアント装置３００をＷＡＮ２７０またはインターネットに直接接続できる場合（たとえば、４Ｇ通信またはネットワークケーブルを介して）にのみ、クライアント装置６００はネットワークアクセス装置２３０を介さずに、Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ、イーサネット技術を使用してローカルサーバ４００と直接通信することもできる。

本実施形態の動作プロセスに対する理解を容易にするために、本開示のメッセージプッシュ方法を説明するいくつかの実施形態が以下に提供される。本実施形態の本方法は、図１に示すメッセージプッシュシステム１の各構成要素に適用可能である。以下、本実施形態の本方法について、クライアント装置３００の各構成要素およびモジュールを基準に説明する。本方法の各フローは、実際の実装シナリオに従って調整することができ、また本開示はこれらに限定されない。

図４は、本開示の一実施形態による、リモートアクセスシナリオにおけるメッセージプッシュ方法を示すメッセージフローチャートである。本シナリオでは、クライアント装置６００はＷＡＮ２７０に存在する。図４を参照すると、ローカルサーバ４００およびリモートサーバ５００に登録するように（ステップＳ４１０およびステップＳ４２０）、クライアント装置３００のプロセッサ３３０はネットワーク接続回路３１０を通じ、ＬＡＮ２
５０およびＷＡＮ２７０それぞれを介して登録メッセージを送信する。登録メッセージは、ＭＱＴＴプロトコルに準拠するＣＯＮＮＥＣＴポケット、または別の通信プロトコルに基づく登録用メッセージであってもよい。クライアント装置３００のプロセッサ３３０は、ＬＡＮ２５０およびＷＡＮ２７０の両方を介して、ローカルサーバ４００ならびにリモートサーバ５００からトピック（ここではトピックＢとする）をサブスクライブすることができる。クライアント装置６００は、ローカルサーバ４００またはリモートサーバ５００のどちらに登録するかを決定するが、ローカルサーバ４００に登録を試みると、クライアント装置６００は、ＬＡＮ２５０に存在しないことが原因となって、登録に失敗する（ステップＳ４３０）。次にクライアント装置６００はリモートサーバ５００に登録し（すなわち、登録が成功する）、クライアント装置３００がパブリッシュを予定するトピック（ここではトピックＡとする）をサブスクライブし、クライアント装置６００はまた、クライアント装置３００によってサブスクライブされるトピック（すなわち、トピックＢ）のパブリッシュを予定する（ステップＳ４４０）。

トピックＡに関連するメッセージがパブリッシュされる直前となった場合、クライアント装置３００は、ＬＡＮ２５０およびＷＡＮ２７０を介してローカルサーバ４００ならびにリモートサーバ５００の両方にメッセージをパブリッシュする（ステップＳ４５０）。トピックＡに関連するメッセージをクライアント装置６００が受信するように、リモートサーバ５００はトピックＡのサブスクライバすべてにメッセージを送信する（ステップＳ４６０）。一方、トピックＢに関連するメッセージがパブリッシュされる直前となった場合、クライアント装置６００はリモートサーバ５００にメッセージをパブリッシュし（ステップＳ４７０）、トピックＢに関連するメッセージをクライアント装置３００が受信するように、リモートサーバ５００はトピックＢのサブスクライバすべてにメッセージを送信する（ステップＳ４８０）。

図５は、本開示の一実施形態による、ローカルアクセスシナリオにおけるメッセージプッシュ方法を示すメッセージフローチャートである。本シナリオでは、クライアント装置６００はＬＡＮ２５０に存在する。図５を参照すると、クライアント装置３００のプロセッサ３３０は、ネットワーク接続回路３１０を介してローカルサーバ４００およびリモートサーバ５００に登録する（ステップＳ５１０およびステップＳ５２０）。本シナリオでは、クライアント装置６００はローカルサーバ４００に登録することができ、これにより、その後、リモートサーバ５００には登録しない（ステップＳ５３０）。なお、クライアント装置６００がローカルサーバ４００およびリモートサーバ５００に登録する順序は入れ替えることができる一方、いずれかのサーバに対する登録が完了していれば、クライアント装置６００は別のサーバに登録する必要がなくなる。換言すれば、クライアント装置６００は、登録に失敗した場合、または当該場合に限り、別のサーバに登録することを選択する。

クライアント装置３００がパブリッシュを予定するトピック（ここではトピックＡとする）をクライアント装置６００がサブスクライブし、クライアント装置６００がパブリッシュを予定するトピック（ここではトピックＢとする）をクライアント装置３００がサブスクライブすることが想定される。トピックＡに関連するメッセージがパブリッシュされる直前となった場合、クライアント装置３００は、ＬＡＮ２５０およびＷＡＮ２７０を介してローカルサーバ４００ならびにリモートサーバ５００の両方にメッセージをパブリッシュする（ステップＳ５４０）。トピックＡに関連するメッセージをクライアント装置６００が受信するように、ローカルサーバ４００はトピックＡのサブスクライバすべてにメッセージを送信する（ステップＳ５５０）。一方、トピックＢに関連するメッセージがパブリッシュされる直前となった場合、クライアント装置６００はローカルサーバ４００にメッセージをパブリッシュし（ステップＳ４７０）、トピックＢに関連するメッセージをクライアント装置３００が受信するように、ローカルサーバ４００はトピックＢのサブス
クライバすべてにメッセージを送信する（ステップＳ５７０）。

このように、ローカルサーバ４００およびリモートサーバ５００のうちの１つに接続可能であれば、ＬＡＮ２５０に存在するかＷＡＮ２７０に存在するかにかかわらず、クライアント装置６００はパブリッシュされるメッセージをサブスクライバに正常に送信したり、またはサブスクライブされるメッセージを正常に受信したりすることができ、これにより、既存のインターネットに切断シナリオが発生した場合に直面する、メッセージのパブリッシュおよび受信が失敗する問題を解決する。

本実施形態の実際の適用シナリオに対する理解を容易にすることを目的として、種々の適用シナリオを説明するために３つの例を以下に提供する。

図６Ａおよび図６Ｂは、クライアント装置３００をＷＡＮ２７０に接続することができ、またクライアント装置６００がＬＡＮ２５０に存在することを示す、第１のシナリオ例の概略図である。まず図６Ａを参照すると、クライアント装置３００はローカルサーバ４００およびリモートサーバ５００からトピックＢ（たとえば、照明の点灯／消灯）をサブスクライブし、またクライアント装置６００はローカルサーバ４００からトピックＡ（たとえば、電球の状態）をサブスクライブする。図６Ｂを参照すると、クライアント装置６００は照明を点灯する動作を受信し、次いでローカルサーバ４００にトピックＢに関連するメッセージ（すなわち、照明の点灯）をパブリッシュする（ステップＳ６１０）。ローカルサーバ４００はクライアント装置３００にメッセージを送信し（ステップＳ６２０）、クライアント装置３００はメッセージに基づいて、Ｚ−Ｗａｖｅ技術によって被制御装置２１０（ここではスマート電球とする）を制御してこれを点灯し（ステップＳ６３０）、また被制御装置２１０は、クライアント装置３００に電球が点灯したという状態を返信する（ステップＳ６４０）。クライアント装置３００はローカルサーバ４００およびリモートサーバ５００に電球の状態をパブリッシュし（ステップＳ６５０）、クライアント装置６００（トピックＡのサブスクライバである）はローカルサーバ４００を介して電球の状態を取得する（ステップＳ６６０）。

図７は、クライアント装置３００のＷＡＮ２７０への接続が失敗し、またクライアント装置６００がＬＡＮ２５０に存在することを示す、第２のシナリオ例の概略図である。図７を参照すると、図６Ａおよび図６Ｂに示す第１のシナリオ例とは異なり、第２のシナリオ例におけるクライアント装置３００は、リモートサーバ５００に電球の状態をパブリッシュすることができない。しかしながら、電球の状態について、やはり最終的にはローカルサーバ４００を介してクライアント装置６００に送信することができる。

図８Ａおよび図８Ｂは、クライアント装置３００をＷＡＮ２７０に接続することができ、またクライアント装置６００がＷＡＮ２７０に存在することを示す、第３のシナリオ例の概略図である。まず図８Ａを参照すると、クライアント装置３００はローカルサーバ４００およびリモートサーバ５００からトピックＢ（たとえば、照明の点灯／消灯）をサブスクライブし、またクライアント装置６００はリモートサーバ５００からトピックＡ（たとえば、電球の状態）をサブスクライブする。図８Ｂを参照すると、クライアント装置６００は照明を点灯する動作を受信し、次いでリモートサーバ５００にトピックＢに関連するメッセージ（すなわち、照明の点灯）をパブリッシュする（ステップＳ８１０）。リモートサーバ５００はクライアント装置３００にメッセージを送信し（ステップＳ８２０）、クライアント装置３００はメッセージに基づいて、被制御装置２１０を制御してこれを点灯し（ステップＳ８３０）、また被制御装置２１０は、クライアント装置３００に電球が点灯したという状態を返信する（ステップＳ８４０）。クライアント装置３００はローカルサーバ４００およびリモートサーバ５００に電球の状態をパブリッシュし（ステップＳ８５０）、またクライアント装置６００（トピックＡのサブスクライバである）はリモ
ートサーバ５００を介して電球の状態を取得することができる（ステップＳ８６０）。

以上の点を踏まえて、第１のクライアント装置がローカルサーバおよびリモートサーバに登録し、かつこれらにメッセージをパブリッシュしたり、またはこれらからメッセージを受信したりすることができるように、本実施形態で第１のクライアント装置が存在するネットワークにローカルサーバが新たに追加される。ネットワークの任意の１つにおいてサーバ（たとえば、ローカルサーバまたはリモートサーバ）に接続可能であれば、第１のクライアント装置と同一のネットワークに存在するか、または第１のクライアント装置とは異なるネットワークに存在するかにかかわらず、第２のクライアント装置は第１のクライアント装置によってパブリッシュされるメッセージを正常に受信したり、またはパブリッシュされるメッセージを第１のクライアント装置に正常に送信したりすることができる。このように、ユーザは被制御装置と同一のネットワークに第１のクライアント装置とローカルサーバとを設置することができるので、ユーザは第１のクライアント装置が存在する環境にあっても、または他の環境にあっても、第２のクライアント装置を介した被制御装置の制御および／またはこれからの情報収集を行うことができる。

本開示について、上記の実施形態を参照して説明したが、記載された本実施形態に対して本開示の趣旨から逸脱することなく変更が行われてもよいことは、当業者には明らかである。したがって、本開示の範囲は、上記の詳細な説明によってではなく、添付の特許請求の範囲によって定義される。

本発明のメッセージプッシュシステム、クライアント装置およびそのメッセージプッシュ方法は、通信装置ならびにその処理方法に適用することができる。

１ メッセージプッシュシステム
１１ モバイルクライアント装置
１２ クラウドプラットフォーム
１３ 固定クライアント装置
１４ 電球
２１０ 被制御装置
２３０ ネットワークアクセス装置
２５０ ローカルエリアネットワーク
２７０ ワイドエリアネットワーク
３００，６００ クライアント装置
３１０ ネットワーク接続回路
３２０ デバイス通信回路
３３０ プロセッサ
４００ ローカルサーバ
５００ リモートサーバ
Ｓ４１０〜Ｓ４８０，Ｓ５１０〜Ｓ５７０，Ｓ６１０〜Ｓ６６０，Ｓ８１０〜Ｓ８６０
ステップ

Claims (13)

1. 第１のネットワークに存在する第１のサーバと、
   前記第１のネットワークとは異なる第２のネットワークに存在する第２のサーバと、
   前記第１のネットワークに存在し、前記第１のサーバおよび前記第２のサーバに登録し、かつパブリッシュ／サブスクライブメカニズムに基づいて、前記第１のサーバおよび前記第２のサーバのうちの少なくとも１つを介してメッセージを送受信する第１のクライアント装置とを備える、メッセージプッシュシステム。
2. 前記第１のクライアント装置は前記第１のサーバおよび前記第２のサーバの両方にサブスクライブし、かつ前記第１のサーバおよび前記第２のサーバの両方にパブリッシュする、請求項１に記載のメッセージプッシュシステム。
3. 前記第１のサーバまたは前記第２のサーバのどちらにサブスクライブするかを決定する第２のクライアント装置をさらに備える、請求項１に記載のメッセージプッシュシステム。
4. 前記第２のクライアント装置は、前記第１のサーバおよび前記第２のサーバのうちの１つから、前記第１のクライアント装置によってパブリッシュされるトピックをサブスクライブする、請求項３に記載のメッセージプッシュシステム。
5. 前記第１のクライアント装置は、前記第１のサーバおよび前記第２のサーバの両方から、前記第２のクライアント装置によってパブリッシュされるトピックをサブスクライブする、請求項３に記載のメッセージプッシュシステム。
6. 前記第１のクライアント装置は前記第１のサーバの動作を実行する、請求項１に記載のメッセージプッシュシステム。
7. 前記パブリッシュ／サブスクライブメカニズムはメッセージ・キュー・テレメトリ・トランスポート（ＭＱＴＴ）プロトコルに準拠している、請求項１に記載のメッセージプッシュシステム。
8. 第１のネットワークに存在するサーバを設置するステップと、
   前記第１のネットワークおよび前記第１のネットワークとは異なる第２のネットワークを介して登録メッセージを送信するステップと、
   パブリッシュ／サブスクライブメカニズムに基づいて、前記第１のサーバおよび前記第２のサーバのうちの少なくとも１つを介してメッセージを送受信するステップとを含む、サーバに適用可能なメッセージプッシュ方法。
9. 前記パブリッシュ／サブスクライブメカニズムに基づいて、前記第１のサーバおよび前記第２のサーバのうちの少なくとも１つを介してメッセージを送受信する前記ステップは、
   前記第１のネットワークおよび前記第２のネットワークの両方を介してサブスクライブすることと、
   前記第１のネットワークおよび前記第２のネットワークの両方を介してパブリッシュすることとを含む、請求項８に記載のメッセージプッシュ方法。
10. 前記パブリッシュ／サブスクライブメカニズムはＭＱＴＴプロトコルに準拠している、請求項８に記載のメッセージプッシュ方法。
11. 第１のネットワークに存在するクライアント装置であって、
    メッセージを送受信する通信回路と、
    前記通信回路に接続されており、前記通信回路を通じ、前記第１のネットワークおよび第２のネットワークを介して登録メッセージを送信し、かつパブリッシュ／サブスクライブメカニズムに基づいて、前記第１のネットワークおよび前記第１のネットワークとは異なる前記第２のネットワークのうちの少なくとも１つを介して前記メッセージを送受信するプロセッサとを備える、クライアント装置。
12. 前記プロセッサは前記通信回路を通じ、前記第１のネットワークおよび前記第２のネットワークの両方を介してサブスクライブし、かつ前記第１のネットワークおよび前記第２のネットワークの両方を介してパブリッシュする、請求項１１に記載のクライアント装置。
13. 前記パブリッシュ／サブスクライブメカニズムはＭＱＴＴプロトコルに準拠している、請求項１１に記載のクライアント装置。