JP5962676B2 - 情報処理装置、情報処理方法及びプログラム - Google Patents

Description

本技術は、ネットワークを介して複数のデバイスと通信可能な情報処理装置に関する。

従来から、ＮＡＴ（Network Address Translation）ルータやプロキシサーバ／ファイアーウォールのために直接は通信できないデバイス間で、自由な通信を行わせるための技術として、ＸＭＰＰ（Extensible Messaging and Presence Protocol）と呼ばれるメッセージングプロトコルがある。すなわち、当該ＸＭＰＰを用いたサーバがクラウド上に配置され、デバイス間の全ての通信をこのサーバが仲介することで、各デバイスはＮＡＴルータやプロキシサーバ／ファイアーウォールの影響を受けずに互いに通信を行うことが可能となる。ＸＭＰＰに関連した文献としては、例えば以下の特許文献１がある。

特開２００７−３１８１８５号公報

しかしながら、上記ＸＭＰＰを用いた手法では、ＸＭＬ（Extensible Markup Language）をベースとしたプロトコルが用いられるため、サーバは、全てのクライアントと常時接続した上でＸＭＬのパース等の複雑な処理を行う必要がある。したがってこの手法では、１台のサーバで扱うことのできるクライアントの数が十分でない。

以上のような事情に鑑み、本技術の目的は、クラウド側のシステムの負荷を軽減し、１台で膨大な数のデバイスを扱うことが可能な情報処理装置、情報処理方法及びプログラムを提供することにある。

上述の課題を解決するため、本技術の一形態に係る情報処理装置は、通信部と制御部とを有する。上記通信部は、第１の機器、第２の機器、並びに上記第２の機器とネットワークを介して常時接続される常時接続サーバとの間で、上記ネットワークを介して必要に応じて接続して通信可能である。上記制御部は、上記第１の機器から、上記第２の機器宛のデータを受信し、当該データの存在を通知する通知メッセージを上記第２の機器へ送信するように要求する通知要求情報を上記常時接続サーバへ送信し、上記通知メッセージを受信した第２の機器からの要求に応じて、上記データを当該第２の機器へ送信するように、上記通信部を制御可能である。

本技術では、情報処理装置は、第１の機器から第２の機器宛のデータを受信した場合には、常時接続サーバを介して第２の機器へ通知メッセージを送信し、第２の機器からのアクセスに応じてデータを送信できる。したがって情報処理装置は、常時接続サーバに、第１の機器及び第２の機器との接続の維持及びデータの存在の通知を代行させることで、自身の負荷を軽減することができる。また常時接続サーバは、複雑な処理を必要とせず、通信バッファも最小限で済むため、極めて多数の第１の機器及び第２の機器と接続することが可能となる。この結果、１台の情報処理装置が間接的に扱うことができる機器の数が大幅に増加する。

ここで上記データには、例えば動画、静止画、音声、テキスト、メッセージ、プログラム等、あらゆるデータが含まれる。また上記情報処理装置は、典型的にはサーバ装置であるが、それに限られるものではなく、他のあらゆる機器であり得る。

当該情報処理装置は記憶部をさらに有してもよい。また上記第２の機器は、通信中継装置を介して当該情報処理装置及び上記常時接続サーバと通信してもよい。この場合上記制御部は、上記通信中継装置が、当該情報処理装置からの通信を第２の機器へ転送するように設定されている場合には、当該転送設定に関する情報を記憶するように上記記憶部を制御してもよい。また制御部は、上記記憶された情報を用いて、上記通知要求情報の送信に代えて、または、上記通知要求情報の送信に加えて、上記通知メッセージを上記第２の機器へ直接送信するように上記通信部を制御してもよい。

これにより情報処理装置は、第２の機器側の通信中継装置（ルータ）がUPnP IGD（Universal Plug and Play Internet Gateway Device）プロトコルによるNAT Traversal機構をサポートしている場合には、いわゆるＮＡＴ超えにより、第２の機器へ直接通知メッセージを送信することもできる。

上記制御部は、上記第２の機器にグローバルＩＰアドレスが割り当てられている場合には、上記通知要求情報の送信に代えて、または、上記通知要求情報の送信に加えて、上記通知メッセージを上記第２の機器へ直接送信するように上記通信部を制御してもよい。

これにより情報処理装置は、第２の機器が通信中継装置を介さずにアクセス可能な場合には、第２の機器へ直接通知メッセージを送信することもできる。

当該情報処理装置及び上記常時接続サーバはそれぞれ複数存在してもよい。この場合上記第１の機器及び上記第２の機器は、それぞれ１つの上記情報処理装置及び上記常時接続サーバと通信するよう、当該第１の機器、上記第２の機器、上記複数の情報処理装置、上記複数の常時接続サーバをそれぞれ一意に識別する機器識別情報を用いて対応付けられていてもよい。この場合上記制御部は、上記機器識別情報を基に、上記第２の機器が他の情報処理装置と対応付けられていると判断した場合には、上記データを当該他の情報処理装置へ転送するように上記通信部を制御してもよい。

これにより、情報処理装置及び常時接続サーバが複数存在することで、より膨大な数の機器の通信がサポートされる。

上記情報処理装置は、記憶部をさらに有してもよい。この場合上記制御部は、上記第１の機器及び上記第２の機器のそれぞれの機器識別情報を基に所定のハッシュ関数から得られるハッシュ値に基づいた値と、当該複数の情報処理装置のそれぞれの識別情報との対応関係を定めたテーブルを作成してもよい。また制御部は、上記作成されたテーブルを記憶するように上記記憶部を制御してもよく、上記記憶されたテーブルを基に、上記第２の機器に対応する他の情報処理装置を決定してもよい。

これにより情報処理装置は、上記テーブルを用いることで、第２の機器に対応する他の情報処理装置を容易に決定することができる。

上記制御部は、上記第１の機器及び上記第２の機器にそれぞれを所有するユーザを一意に識別するユーザ識別情報が設定されている場合には、上記機器識別情報に代えて上記ユーザ識別情報を用いて上記テーブルを作成してもよい。

これにより、機器の識別情報が異なっていても、同一のユーザによって所有される機器は同一の情報処理装置に接続されることになるため、複数の情報処理装置間の通信が削減され、クラウド側の負荷が低減する。

本技術の他の形態に係る情報処理装置は、通信部と制御部とを有する。上記通信部は、第１の機器及び第２の機器とネットワークを介して常時接続して通信可能である。また通信部は、上記第１の機器と上記第２の機器との間のデータの送受信を上記ネットワーク上で仲介する仲介サーバと必要に応じて接続して通信可能である。上記制御部は、上記第１の機器から送信された上記第２の機器宛のデータが上記仲介サーバにより受信された場合に、当該仲介サーバから、当該データの存在を通知する通知メッセージを上記第２の機器へ送信するように要求する通知要求情報を受信し、当該通知要求情報に基づいて、上記通知メッセージを上記第２の機器へ送信するように、上記通信部を制御可能である。

これにより情報処理装置は、１台の仲介サーバが間接的に扱うことができる機器の数を大幅に増加させ、仲介サーバの負荷を軽減することができる。

本技術の他の形態に係る情報処理装置は、通信部と制御部とを有する。上記通信部は、ネットワーク上の第１のサーバと必要に応じて接続して通信可能であり、上記ネットワーク上の第２のサーバと常時接続して通信可能である。上記制御部は、他の情報処理装置から送信されたデータの存在を通知する通知メッセージを上記第２のサーバから受信し、当該受信された通知メッセージを基に、上記データを上記第１のサーバから受信するように上記通信部を制御可能である。

本技術の他の形態に係る情報処理方法は、第１の機器とネットワークを介して接続を確立して当該第１の機器から第２の機器宛のデータを受信することを含む。当該方法では、上記データの存在を通知する通知メッセージを当該第２の機器へ送信するように要求する通知要求情報が、上記第２の機器と常時接続されたサーバへ送信される。そして、上記通知メッセージを受信した上記第２の機器からの要求に応じて接続が確立されて当該第２の機器へ上記データが送信される。

本技術のまた別の形態に係るプログラムは、情報処理装置に、受信ステップと、第１の送信ステップと、第２の送信ステップとを実行させる。上記受信ステップでは、第１の機器とネットワークを介して接続が確立されて当該第１の機器から第２の機器宛のデータが受信される。上記第１の送信ステップでは、上記データの存在を通知する通知メッセージを当該第２の機器へ送信するように要求する通知要求情報が、上記第２の機器と常時接続された常時接続サーバへ送信される。上記第２の送信ステップでは、上記通知メッセージを受信した上記第２の機器からの要求に応じて当該第２の機器と接続が確立されて当該第２の機器へ上記データが送信される。

以上のように、本技術によれば、クラウド側のシステムの負荷を軽減し、１台で膨大な数のデバイスを扱うことができる。

本技術の第１の実施形態におけるシステムのネットワーク構成を示した図である。 上記システムにおけるメッセージングサーバのハードウェア構成を示したブロック図である。 上記システムにおけるデバイスのハードウェア構成を示したブロック図である。 上記システムにおける各ノードのソフトウェアモジュール構成を示したブロック図である。 上記メッセージングサーバが有する通知手段リストの例を示した図である。 上記メッセージングサーバが有する接続情報リストの例を示した図である。 通知手段が通知サーバである場合の、デバイス間のデータ送信処理の流れを模式的に示した図である。 通知手段がGlobal IPである場合の、デバイス間のデータ送信処理の流れを模式的に示した図である。 通知手段がUPnP IGDである場合の、デバイス間のデータ送信処理の流れを模式的に示した図である。 通知手段がUser Settingである場合の、デバイス間のデータ送信処理の流れを模式的に示した図である。 データの送信元であるデバイスのメッセージ送信部の動作の流れを示したフローチャートである。 データの宛先となるデバイスの通知手段設定部の動作の流れを示したフローチャートである。 データの宛先となるデバイスの通知サーバ通知受信部の動作の流れを示したフローチャートである。 データの宛先となるデバイスの直接通知受信部の動作の流れを示したフローチャートである。 データの宛先となるデバイスのメッセージ受信部の動作の流れを示したフローチャートである。 通知サーバの接続処理部の動作の流れを示したフローチャートである。 通知サーバの接続管理部の動作の流れを示したフローチャートである。 メッセージングサーバの接続処理部の動作の流れを示したフローチャートである。 メッセージングサーバの接続管理部の動作の流れを示したフローチャートである。 メッセージングサーバのメッセージ送信部の動作の流れを示したフローチャートである。 本技術の第２の実施形態におけるシステムのネットワーク構成を示した図である。 本技術の第２の実施形態における上記システムにおける各ノードのソフトウェアモジュール構成を示した図である。 本技術の第２の実施形態における、デバイスに対応するサーバの決定処理の流れを示したフローチャートである。 本技術の第２の実施形態において作成されるメッセージングサーバ割り当てテーブルの例を示した図である。 本技術の第２の実施形態において作成される通知サーバ割り当てテーブルの例を示した図である。 本技術の第２の実施形態において作成される、メッセージングサーバのネットワークアドレス決定用のレゾリューションテーブルの例を示した図である。 本技術の第２の実施形態において作成される、通知サーバのネットワークアドレス決定用のレゾリューションテーブルの例を示した図である。 本技術の第２の実施形態におけるデバイス間のデータ送信処理の流れを模式的に示した図である。 本技術の第２の実施形態におけるメッセージングサーバの接続処理部の動作の流れを示したフローチャートである。 本技術の第２の実施形態におけるメッセージングサーバの接続管理部の動作の流れを示したフローチャートである。 本技術の第２の実施形態におけるメッセージングサーバのメッセージ転送部の動作の流れを示したフローチャートである。 本技術の第３の実施形態におけるシステムのネットワーク構成を示した図である。 本技術の第３の実施形態におけるメッセージングサーバの接続管理部の動作の流れを示したフローチャートである。

以下、本技術に係る実施形態を、図面を参照しながら説明する。

＜第１の実施形態＞
まず、本技術の第１の実施形態を説明する。

［システムのネットワーク構成］
図１は、本実施形態に係るシステムのネットワーク構成を示した図である。

同図に示すように、このシステムは、クラウド上のメッセージングサーバ１００及び通知サーバ２００と、それらサーバとＷＡＮ（Wide Area Network）を介して接続可能な複数のデバイス３００とを有する。

本実施形態では、メッセージングサーバ１００及び通知サーバ２００はクラウド上にそれぞれ１台ずつ設けられる。

デバイス３００は、例えばスマートフォン、携帯電話機、タブレットＰＣ（Personal Computer）、デスクトップＰＣ、ノートブックＰＣ、ＰＤＡ（Personal Digital Assistant）、携帯型ＡＶプレイヤー、電子ブック、デジタルスチルカメラ、カムコーダ、テレビジョン装置、ＰＶＲ（Personal Video Recorder）、ゲーム機器、カーナビゲーションシステム、デジタルフォトフレーム等、あらゆる情報処理装置であり得る。同図では、デバイス３００Ａとデバイス３００Ｂの２台のみが示されているが、デバイス３００の数は３台以上であっても構わない。

各デバイス３００は、通信中継装置３１０を介して上記メッセージングサーバ１００及び通知サーバ２００と通信する場合もあるし、通信中継装置３１０を介さずに直接それらのサーバと通信する場合もある。

各デバイス３００は、通知サーバ２００とは常時接続により通信可能である一方、メッセージングサーバ１００とは必要に応じて接続を確立して通信する。メッセージングサーバ１００は、通知サーバ２００及び各デバイス３００と、必要に応じて接続を確立して通信する。

通信中継装置３１０とは、内側（デバイス３００側）のネットワークと外部（クラウド側）のネットワークとの間の通信を中継する機能を持ち、両ネットワークにおいて利用されるアドレスの相違や、セキュリティを保護する機構のために、外部のサーバが、特別な手段を用いない限り、内部の特定のデバイスを指定して接続することを不可能にしているものをいう。このような通信中継装置３１０としては、例えばＮＡＴルータやプロキシサーバまたはファイアーウォールが挙げられる。

詳細は後述するが、メッセージングサーバ１００は、デバイス３００間の通信（例えばメッセージの送受信）を仲介するサーバとして機能する。また通知サーバ２００は、あるデバイス３００から送信されたデータ（メッセージ）が存在する旨の通知メッセージを、当該データの宛先のデバイス３００へ送信するための通知手段の１つとして機能する。他の通知手段については後述する。

以降の説明では、メッセージングサーバ１００、通知サーバ２００及びデバイス３００をまとめて「ノード」と称する場合もある。

［メッセージングサーバのハードウェア構成］
図２は、上記メッセージングサーバ１００のハードウェア構成を示した図である。同図に示すように、メッセージングサーバ１００は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ（Read Only Memory）１２、ＲＡＭ（Random Access Memory）１３、入出力インタフェース１５、及び、これらを互いに接続するバス１４を備える。

ＣＰＵ１１は、必要に応じてＲＡＭ１３等に適宜アクセスし、各種演算処理を行いながらメッセージングサーバ１００の各ブロック全体を統括的に制御する。ＲＯＭ１２は、ＣＰＵ１１に実行させるＯＳ、プログラムや各種パラメータなどのファームウェアが固定的に記憶されている不揮発性のメモリである。ＲＡＭ１３は、ＣＰＵ１１の作業用領域等として用いられ、ＯＳ、実行中の各種アプリケーション、処理中の各種データを一時的に保持する。

入出力インタフェース１５には、表示部１６、操作受付部１７、記憶部１８、通信部１９等が接続される。

表示部１６は、例えばＬＣＤ（Liquid Crystal Display）、ＯＥＬＤ（Organic ElectroLuminescence Display）、ＣＲＴ（Cathode Ray Tube）等を用いた表示デバイスである。

操作受付部１７は、例えばマウス等のポインティングデバイス、キーボード、タッチパネル、その他の入力装置である。操作受付部１７がタッチパネルである場合、そのタッチパネルは表示部１６と一体となり得る。

記憶部１８は、例えばＨＤＤ（Hard Disk Drive）や、フラッシュメモリ（ＳＳＤ；Solid State Drive）、その他の固体メモリ等の不揮発性メモリである。当該記憶部１８には、上記ＯＳや各種アプリケーション、各種データが記憶される。特に本実施形態において、記憶部１８には、後述する複数のソフトウェアモジュール等のプログラムや、通知手段リスト、接続情報リスト等のデータベースが記憶される。

通信部１９は、ＷＡＮ５０に接続するためのＮＩＣ等であり、通知サーバ２００やデバイス３００との間の通信処理を担う。

［通知サーバのハードウェア構成］
上記通知サーバ２００のハードウェア構成も、上記メッセージングサーバのハードウェア構成と同様であるため、説明を省略する。本実施形態では、通知サーバ２００において、上記メッセージングサーバ１００のＣＰＵ１１、記憶部１８、通信部１９と対応するハードウェアをそれぞれＣＰＵ２１、記憶部２８、通信部２９と称する。

記憶部２８には、後述する複数のソフトウェアモジュール等のプログラムや、接続情報リスト等のデータベースが記憶される。

［デバイスのハードウェア構成］
図３は、上記デバイス３００のハードウェア構成を示した図である。同図に示すように、デバイス３００のハードウェア構成も、上記サーバ１００のハードウェア構成と基本的に同様である。すなわち、デバイス３００は、ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、入出力インタフェース３５、及び、これらを互いに接続するバス３４、表示部３６、操作受付部３７、記憶部３８、通信部３９を備える。

ここで表示部３６は、デバイス３００に内蔵されていてもよいし、デバイス３００に外部接続されていてもよい。

記憶部３８には、後述する複数のソフトウェアモジュール等のプログラムや、各種データベースが記憶される。

［各機器のモジュール構成］
図４は、上記メッセージングサーバ１００、通知サーバ２００及びデバイス３００がそれぞれ有するソフトウェアモジュールの構成を示した図である。

（メッセージングサーバのモジュール構成）
同図に示すように、メッセージングサーバ１００は、接続処理部１０１、接続管理部１０２、メッセージ処理部１０５及びメッセージ送信部１０６の各ソフトウェアモジュールと、通知手段リスト１０３及び接続情報リスト１０４の各データベースとを有する。

接続処理部１０１は、デバイス３００からの接続要求を受け、デバイス３００と接続を確立する。

接続管理部１０２は、通知サーバ２００及びデバイス３００との全ての接続を管理し、受け取ったメッセージを処理、送信、または転送する。

メッセージ処理部１０５は、受信したメッセージングサーバ１００宛のメッセージを処理する。

メッセージ送信部１０６は、メッセージングサーバ１００が担当するデバイス３００へメッセージを送信する。

通知手段リスト１０３は、デバイス３００へメッセージの存在を通知する通知手段に関する情報のリストである。図５に、当該通知手段リストの例を示す。

後述するが、各デバイス３００は、実際の通信に先立ち、メッセージングサーバ１００と通信を行って、メッセージングサーバ１００が各デバイス宛のメッセージを受け取った場合に、どのような手段を用いて通知してもらいたいかを登録しておく。

同図に示すように、通知手段リストには、ノードＩＤ（デバイスであればデバイスＩＤ、サーバであればサーバＩＤ）、通知手段及び関連情報の各項目が記載される。

ノードＩＤは、メッセージングサーバ１００、通知サーバ２００及び各デバイス３００を一意に識別する例えば１２８ビットのＩＤである。

デバイスＩＤは、全てのデバイス３００毎にユニークなＩＤとなるように、通常はＷＬＡＮ／Ｅｔｈｅｒｎｅｔ（登録商標）におけるＭＡＣアドレスや、携帯電話のＩＭＥＩなど、各デバイス３００のハードウェアに予め埋め込まれた情報を元に生成される。しかし、当該デバイスＩＤは、一意性が保証されるのであれば、どのような形で割り当てられてもよい。

サーバＩＤは、クラウド上のメッセージングサーバ１００及び通知サーバ２００を一意に指定するためのＩＤで、通常は、障害対策時にサーバを置き換えるなどの目的から、起動時に指定したＩＤなどが用いられるが、上記デバイスＩＤと同様にどのような形で設定されてもよい。

当該ノードＩＤは、例えば、上位ビットでＩＤのタイプ、下位ビットで各ノード固有のＩＤを表す。ＩＤのタイプとは、例えばデバイスＩＤであれば「0300」、メッセージングサーバ１００のサーバＩＤであれば「0400」、通知サーバ２００のサーバＩＤであれば「0401」等である。

具体的には、デバイスＩＤは例えば「03000000-0000-0000-0000-0000c293975d」といったものであり、サーバＩＤは例えば「04010000-0000-0000-0000-000000000123」といったものである。同図の例では１つのデバイスＩＤに関する複数の通知手段のエントリが示されているが、実際には、異なるＩＤを有するノード（メッセージングサーバ１００、通知サーバ２００及び複数のデバイス３００）についてそれぞれ通知手段のエントリが記載される。

本実施形態では、通知手段として、「Global IP」、「UPnP IGD」、「User Setting」及び「Server」の４つが存在する。上記通知サーバ２００は、上記通信中継装置３１０により、外部（メッセージングサーバ１００）からの直接の通信が行えない場合のために設けられるものである。したがって、通信中継装置３１０が存在しない場合や、通信中継装置３１０に特別な設定が可能である場合には、メッセージングサーバ１００は、通知サーバ２００によらずに通知処理を実行可能である。

「Global IP」は、デバイス３００（例えばモバイルデバイス）にグローバルＩＰアドレスが割り振られており、メッセージングサーバ１００からデバイス３００に、通信中継装置３１０を介さずに直接接続可能であることを示す。このエントリでは、関連情報として、ノードＩＤに対応するノードのグローバルＩＰアドレス及びポート番号が記載される。

「UPnP IGD」は、通信中継装置３１０が、それに接続されたローカル側のノードからの指示により、外部からの通信を内部の特定のノードへ転送する設定が可能とされており、メッセージングサーバ１００から通信中継装置３１０を経由してデバイス３００へ接続可能であることを示す。これは具体的には、通信中継装置３１０としてのＮＡＴルータが、UPnP IGDプロトコルによるNAT Traversal機構をサポートしている場合である。この場合、内部のデバイス３００が、メッセージングサーバ１００と共同してＷＡＮ５０側のポート番号とＬＡＮ側のポート番号とを決定して、当該ＷＡＮ５０側のポート番号への通信を、当該ＬＡＮ側のＩＰアドレス／ポート番号へ転送するように、ＮＡＴルータに設定する。メッセージングサーバ１００は、当該ＷＡＮ側のＩＰアドレス及びポート番号を、通知手段リスト上で関連情報として記憶しておき、デバイス３００と通信する際には、当該記憶されたＩＰアドレス及びポート番号を用いる。

「User Setting」は、「UPnP IGD」と同様の転送設定が、デバイス３００からの指示ではなく、ポートフォワーディング機構を用いて、ユーザが手動で変更することにより可能とされていることを示す。この場合も、設定されたＩＰアドレス及びポート番号は関連情報として記憶される。

「Server」は、メッセージングサーバ１００が通知サーバ２００を経由して各デバイス３００へ接続可能であることを示す。各デバイス３００が上記NAT Traversal機構等をサポートしない通常の通信中継装置３１０を経由してクラウド側と接続される場合は、当該通知手段が用いられる。

この通知手段リストは、同一デバイスの情報が複数のエントリとして存在することもある。例えば、デバイス３００がスマートフォン等の携帯端末であって、それが携帯電話のネットワークにも、Wireless LANにも接続されている場合などである。また、実際の運用時においては、当該リストの各エントリに有効期限が設けられてもよい。

接続情報リスト１０４は、メッセージングサーバ１００が、その時点で保持している接続に関する情報を記したリストである。図６にその一例を示す。同図に示すように、接続情報リスト１０４は、メッセージングサーバ１００が接続中の通知サーバ２００またはデバイス３００について、それらのノードＩＤ、ＩＰアドレス及びソケット番号の各項目が記載される。当該接続情報リスト１０４では、通知サーバ２００またはデバイス３００との接続が確立されるたびに該当するエントリが追加され、接続が解除された場合には、該当するエントリが削除される。

（通知サーバのモジュール構成）
図４に示すように、通知サーバ２００は、接続処理部２０１及び接続管理部２０２の各ソフトウェアモジュールと、データベースとしての接続情報リスト２０３とを有する。

接続処理部２０１は、デバイス３００からの接続要求を受け接続を確立する。

接続管理部２０２は、メッセージングサーバ１００及びデバイス３００との全ての接続を管理し、メッセージングサーバ１００から通知要求があった場合には、対応するデバイス３００に通知メッセージを送信する。

接続情報リスト２０３は、通知サーバ２００が、その時点で保持している接続に関する情報を記したリストであり、その構成は上記メッセージングサーバ１００が有する接続情報リスト１０４と同様である。

（デバイスのモジュール構成）
図４に示すように、各デバイス３００は、通知手段設定部３０１、通知サーバ通知受信部３０２、直接通知受信部３０３、メッセージ受信部３０４、メッセージ送信部３０５及びメッセージ処理部３０６の各ソフトウェアモジュールを有する。

通知手段設定部３０１は、メッセージングサーバ１００に、デバイス３００が利用可能な通知手段を設定する。

通知サーバ通知受信部３０２は、通知サーバ２００と接続して、通知メッセージを受信する。

直接通知受信部３０３は、通知サーバ２００を介さずに、メッセージングサーバ１００から直接、通知メッセージを受信する。

メッセージ受信部３０４は、メッセージングサーバ１００と接続して、他のデバイス３００から送信されたデータ（メッセージ）を受信する。

メッセージ送信部３０５は、メッセージングサーバ１００と接続して、他のデバイス宛のデータ（メッセージ）を送信する。

メッセージ処理部３０６は、メッセージングサーバ１００から受信したデータ（メッセージ）を処理する。

メッセージ送信側のデバイス３００Ａは、最低限、メッセージ送信部３０５を有していればよいため、同図では、その他のモジュールブロックを破線で示している。しかし、もちろん、送信側のデバイス３００Ａは、受信側のデバイス３００Ｂと同様にそれらのモジュールを有していてもよい。同様に、同図ではメッセージ受信側のデバイス３００Ｂにおいて、メッセージ送信部３０５が破線で示されているが、当該デバイス３００Ｂもメッセージ送信部３０５を有していてもよい。

［システムの動作］
次に、以上のように構成されたシステムにおけるメッセージングサーバ１００、通知サーバ２００及びデバイス３００の動作について、デバイス３００間のデータ（メッセージ）送信処理を中心に説明する。本実施形態及び他の実施形態において、システムを構成する各ノードにおける動作は、ＣＰＵと、その制御下において実行される上記各ソフトウェアモジュールとで協働して行われる。

データ（メッセージ）の送信処理に先立って、メッセージングサーバ１００及び通知サーバ２００は、初期設定情報として、通知サーバＩＤ、メッセージングサーバＩＤ及びそれらに対応するネットワークアドレス（ホスト名またはＩＰアドレス/ポート番号）等を予め各デバイス３００へ通知しておく。

（データ送信処理例：通知手段が通知サーバである場合）
まず、通知手段が通知サーバ２００である場合の、デバイス３００間のデータ（メッセージ）送信処理の流れを説明する。図７はこの場合のデバイス３００Ａからデバイス３００Ｂへのデータ送信処理の流れの概要を模式的に示した図である。

同図に示すように、まず、メッセージ受信側（宛先）のデバイス３００Ｂが、クラウド側との通信環境を確認した上で、通信中継装置３１０Ｂを介して通知サーバ２００と接続する（同図（１））。当該接続は常時維持される。

続いて、デバイス３００Ｂは、通信中継装置３１０Ｂを介してメッセージングサーバ１００と接続して、通知手段として通知サーバ２００を設定する（通知手段設定情報を送信する）（同図（２））。

続いて、メッセージ送信元のデバイス３００Ａが、デバイス３００Ｂ宛のメッセージをメッセージングサーバ１００へ送信する（同図（３））。

続いて、メッセージを受信したメッセージングサーバ１００は、通知サーバ２００に対して、デバイス３００Ａからデバイス３００Ｂ宛のメッセージの存在を通知する通知メッセージの送信要求（通知要求）を送信する（同図（４））。

続いて、上記通知要求を受信した通知サーバ２００は、既に確立しているデバイス３００Ｂとの接続を用いて、デバイス３００Ｂに上記通知メッセージを送信する（同図（５））。

そして、上記通知メッセージを受信したデバイス３００Ｂが、通信中継装置３１０Ｂを介してメッセージングサーバ１００と接続を確立して、上記デバイス３００Ａからのメッセージを受信する（同図（６））。

（データ送信処理例：通知手段がGlobal IPである場合）
次に、通知手段がGlobal IPである場合の、デバイス３００間のデータ（メッセージ）送信処理の流れを説明する。図８はこの場合のデバイス３００Ａからデバイス３００Ｂへのデータ送信処理の流れの概要を模式的に示した図である。

同図に示すように、まず、メッセージ受信側（宛先）のデバイス３００Ｂが、クラウド側との通信環境を確認する（同図（１））。

続いて、デバイス３００Ｂは、クラウド側と直接通信が可能であることを確認すると、メッセージングサーバ１００と接続して、通知手段としてGlobal IPを設定する（同図（２））。

続いて、メッセージ送信元のデバイス３００Ａが、デバイス３００Ｂ宛のメッセージをメッセージングサーバ１００へ送信する（同図（３））。

続いて、メッセージを受信したメッセージングサーバ１００は、デバイス３００Ｂと接続を確立して、上記通知メッセージを直接、デバイス３００Ｂへ送信する（同図（４））。

そして、上記通知メッセージを受信したデバイス３００Ｂが、メッセージングサーバ１００と接続を確立して、上記デバイス３００Ａからのメッセージを受信する（同図（５））。

（データ送信処理例：通知手段がUPnP IGDである場合）
次に、通知手段がUPnP IGDである場合の、デバイス３００間のデータ（メッセージ）送信処理の流れを説明する。図９はこの場合のデバイス３００Ａからデバイス３００Ｂへのデータ送信処理の流れの概要を模式的に示した図である。

同図に示すように、まず、メッセージ受信側（宛先）のデバイス３００Ｂが、クラウド側との通信環境を確認した上で、UPnP IGDによるNAT Traversal機構を用いて、通信中継装置３１０Ｂ（ルータ）に対して、クラウド側からの通信をデバイス３００Ｂに転送するように設定する（同図（１））。

続いて、デバイス３００Ｂは、通信中継装置３１０Ｂを介してメッセージングサーバ１００と接続して、通知手段としてUPnP IGDを設定する（同図（２））。

続いて、メッセージ送信元のデバイス３００Ａが、デバイス３００Ｂ宛のメッセージをメッセージングサーバ１００へ送信する（同図（３））。

続いて、メッセージを受信したメッセージングサーバ１００は、上記UPnP IGDの設定を元に、デバイス３００Ｂと接続を確立して、上記通知メッセージを通信中継装置３１０Ｂを介してデバイス３００Ｂへ送信する（同図（４））。

そして、上記通知メッセージを受信したデバイス３００Ｂが、上記UPnP IGDの設定を元に、メッセージングサーバ１００と接続を確立して、通信中継装置３１０Ｂを介して上記デバイス３００Ａからのメッセージを受信する（同図（５））。

（データ送信処理例：通知手段がUser Settingである場合）
次に、通知手段がUser Settingである場合の、デバイス３００間のデータ（メッセージ）送信処理の流れを説明する。図１０はこの場合のデバイス３００Ａからデバイス３００Ｂへのデータ送信処理の流れの概要を模式的に示した図である。

同図に示すように、まず、メッセージ受信側（宛先）のデバイス３００Ｂのユーザが、クラウド側との通信環境を確認した上で、ポートフォワーディング機構を用いて、通信中継装置３１０Ｂ（ルータ）に対して、クラウド側からの通信をデバイス３００Ｂに転送するように手動で設定する（同図（１））。

続いて、デバイス３００Ｂは、通信中継装置３１０Ｂを介してメッセージングサーバ１００と接続して、通知手段としてUser Settingを設定する（同図（２））。

続いて、メッセージ送信元のデバイス３００Ａが、デバイス３００Ｂ宛のメッセージをメッセージングサーバ１００へ送信する（同図（３））。

続いて、メッセージを受信したメッセージングサーバ１００は、上記ポートフォワーディング機構による設定を元に、デバイス３００Ｂと接続を確立して、通信中継装置３１０Ｂを介して上記通知メッセージをデバイス３００Ｂへ送信する（同図（４））。

そして、上記通知メッセージを受信したデバイス３００Ｂが、上記ポートフォワーディング機構による設定を元に、メッセージングサーバ１００と接続を確立して、通信中継装置３１０Ｂを介して上記デバイス３００Ａからのメッセージを受信する（同図（５））。

（デバイスの動作）
次に、上述の送信処理におけるデバイス３００の動作について説明する。

図１１は、メッセージの送信元であるデバイス３００Ａの上記メッセージ送信部３０５の動作の流れを示したフローチャートである。

同図に示すように、メッセージ送信部３０５はまず、デバイス３００ＡのノードＩＤ（デバイスＩＤ）から、対応するメッセージングサーバ１００を判定する（ステップ１１１）。上述のように、本実施形態では、メッセージングサーバ１００は１台のみであり、各デバイス３００には、そのサーバＩＤ及びネットワークアドレスが予め知らされているため、メッセージ送信部３０５は当該情報によりメッセージングサーバ１００を特定する。

続いてメッセージ送信部３０５は、通信中継装置３１０Ａを介して、メッセージングサーバ１００と接続を確立する（ステップ１１２）。

続いてメッセージ送信部３０５は、デバイス３００Ｂ宛のメッセージをメッセージングサーバ１００へ送信する（ステップ１１３）。

そしてメッセージ送信部３０５は、メッセージの送信が完了すると、メッセージングサーバ１００との接続を解除する（ステップ１１４）。

図１２は、データ（メッセージ）の宛先となるデバイス３００Ｂの上記通知手段設定部３０１の動作の流れを示したフローチャートである。

同図に示すように、通知手段設定部３０１はまず、デバイス３００ＢのノードＩＤ（デバイスＩＤ）から、対応するメッセージングサーバ１００を決定する（ステップ１２１）。上述のように、本実施形態では、デバイス３００Ｂにも、メッセージングサーバ１００のサーバＩＤ及びネットワークアドレスが予め知らされているため、通知手段設定部３０１は当該情報によりメッセージングサーバ１００を特定する。

続いて通知手段設定部３０１は、通信中継装置３１０Ｂを介して、メッセージングサーバ１００と接続を確立する（ステップ１２２）。

続いて通知手段設定部３０１は、メッセージングサーバ１００に、上述した４つのうち少なくとも１つの通知手段を特定した通知手段設定情報を送信する（ステップ１２３）。

そして通知手段設定部３０１は、通知手段設定情報の送信が完了すると、メッセージングサーバ１００との接続を解除する（ステップ１２４）。

図１３は、デバイス３００Ｂの上記通知サーバ通知受信部３０２の動作の流れを示したフローチャートである。上述のように、この動作は通知手段が通知サーバ２００に設定されている場合に行われる。

同図に示すように、通知サーバ通知受信部３０２はまず、デバイス３００ＢのノードＩＤ（デバイスＩＤ）から、対応する通知サーバ２００を決定する（ステップ１３１）。上述のように、本実施形態では、通知サーバ２００は１台のみであり、各デバイス３００には、そのサーバＩＤ及びネットワークアドレスが予め知らされているため、通知サーバ通知受信部３０２は当該情報により通知サーバ２００を特定する。

続いて通知サーバ通知受信部３０２は、通信中継装置３１０Ｂを介して、通知サーバ２００と接続を確立する（ステップ１３２）。

続いて通知サーバ通知受信部３０２は、デバイス３００ＢのノードＩＤ（デバイスＩＤ）を通知サーバ２００へ通知する（ステップ１３３）。

続いて通知サーバ通知受信部３０２は、メッセージングサーバ１００からの通知要求を受けた通知サーバ２００から、通知メッセージを受信する（ステップ１３４）。

続いて、通知メッセージを受信した通知サーバ通知受信部３０２は、その時点でメッセージングサーバ１００との接続が確立されているか否かを判断する（ステップ１３５）。

メッセージングサーバ１００との接続が確立されていないと判断した場合（Ｙｅｓ）には、通知サーバ通知受信部３０２は、メッセージ受信部３０４に、メッセージングサーバ１００との接続を要求する（ステップ１３６）。

通知サーバ通知受信部３０２は、上記ステップ１３４〜１３６の処理を、通知メッセージを受信するたびに繰り返す。

図１４は、デバイス３００Ｂの上記直接通知受信部３０３の動作の流れを示したフローチャートである。上述のように、この動作は、通知手段が通知サーバ２００以外に設定されている場合に行われる。

同図に示すように、直接通知受信部３０３はまず、メッセージングサーバ１００から送信される通知メッセージの受信待ち処理する（ステップ１４１）。

続いて直接通知受信部３０３は、メッセージングサーバ１００から通知メッセージを受信する（ステップ１４２）。

続いて、通知メッセージを受信した直接通知受信部３０３は、その時点でメッセージングサーバ１００との接続が確立されているか否かを判断する（ステップ１４３）。

メッセージングサーバ１００との接続が確立されていないと判断した場合（Ｙｅｓ）には、直接通知受信部３０３は、メッセージ受信部３０４に、メッセージングサーバ１００との接続を要求する（ステップ１４４）。

直接通知受信部３０３は、上記ステップ１４２〜１４４の処理を、通知メッセージを受信するたびに繰り返す。

図１５は、デバイス３００Ｂの上記メッセージ受信部３０４及びメッセージ処理部３０６の動作の流れを示したフローチャートである。

同図に示すように、メッセージ受信部３０４はまず、上述と同様に、デバイス３００ＢのノードＩＤ（デバイスＩＤ）から、対応するメッセージングサーバ１００を判定する（ステップ１５１）。

続いてメッセージ受信部３０４は、通信中継装置３１０Ｂを介して、（通知手段がGlobal IPの場合は、通信中継装置３１０Ｂを介さずに直接）メッセージングサーバ１００と接続を確立する（ステップ１５２）。

続いてメッセージ受信部３０４は、デバイス３００ＢのノードＩＤ（デバイスＩＤ）をメッセージングサーバ１００へ通知する（ステップ１５３）。

続いてメッセージ受信部３０４はメッセージングサーバ１００からのメッセージの受信、タイムアウト、エラーまたは通信切断の何れかを待つ（ステップ１５４）。

メッセージを受信した場合（ステップ１５５のＹｅｓ）、メッセージ処理部３０６は、受信したメッセージを処理する（ステップ１５６）。

メッセージを受信しないままタイムアウトし、またはエラーが発生した場合（ステップ１５７のＹｅｓ）には、メッセージ受信部３０４は、メッセージングサーバ１００との接続を解除する（ステップ１５８）。

メッセージ受信部３０４及びメッセージ処理部３０６は、上記ステップ１５４〜１５８の処理を、メッセージングサーバ１００との接続確立のたびに繰り返す。

（通知サーバの動作）
次に、上述の送信処理における通知サーバ２００の動作について説明する。

図１６は、通知サーバ２００の上記接続処理部２０１の動作の流れを示したフローチャートである。

同図に示すように、接続処理部２０１はまず、デバイス３００またはメッセージングサーバ１００からの接続要求を待つ（ステップ１６１）。

デバイス３００またはメッセージングサーバ１００からの接続要求があった場合（ステップ１６２のＹｅｓ）、接続処理部２０１は、当該接続要求を受け入れ、接続を確立する（ステップ１６３）。

続いて接続処理部２０１は、接続元のデバイス３００またはメッセージングサーバ１００から、それらのノードＩＤ（デバイス３００のデバイスＩＤまたはメッセージングサーバ１００のサーバＩＤ）を受信する（ステップ１６４）。

そして接続処理部２０１は、上記接続情報リスト２０３に上記ノードＩＤ及び接続に関する情報（ＩＰアドレス及びソケット番号）を記録し、それらを新たに接続管理対象に加える（ステップ１６５）。

図１７は、通知サーバ２００の上記接続管理部２０２の動作の流れを示したフローチャートである。

同図に示すように、接続管理部２０２はまず、上記接続情報リスト２０３で管理している全ての接続について、メッセージの受信、エラーまたは通信切断の何れかを待つ（ステップ１７１）。

続いて接続管理部２０２は、メッセージを受信したか否かを判断する（ステップ１７２）。

メッセージを受信したと判断した場合（Ｙｅｓ）、接続管理部２０２は、当該メッセージがメッセージングサーバ１００からの通知要求であるか否かを判断する（ステップ１７３）。

上記メッセージがメッセージングサーバ１００からの通知要求であると判断した場合（Ｙｅｓ）、接続管理部２０２は、受信したメッセージから、通知対象（通知メッセージの送信対象）のデバイス３００のデバイスＩＤを取得する（ステップ１７４）。

続いて接続管理部２０２は、上記接続情報リスト２０３に、上記取得したデバイスＩＤと合致するエントリが存在するか否かを判断する（ステップ１７５）。

取得したデバイスＩＤと合致するエントリが存在すると判断した場合（ステップ１７６のＹｅｓ）、接続管理部２０２は、当該エントリに対応する接続（ＩＰアドレス及びソケット番号）を用いて、対象のデバイス３００に通知メッセージを送信する（ステップ１７７）。

上記ステップ１７２において、メッセージを受信していないと判断した場合（Ｎｏ）、接続管理部２０２は、管理対象のいずれかの接続について、エラーの発生または通信切断があったか否かを判断する（ステップ１７８）。

エラーの発生または通信切断があったと判断した場合（Ｙｅｓ）、接続管理部２０２は、当該エラーが発生しまたは通信が切断された接続に関するエントリを接続情報リスト２０３から除外する（ステップ１７９）。

（メッセージングサーバの動作）
次に、上述の送信処理におけるメッセージングサーバ１００の動作について説明する。

図１８は、メッセージングサーバ１００の上記接続処理部１０１の動作の流れを示したフローチャートである。

同図に示すように、接続処理部１０１はまず、デバイス３００からの接続要求を待つ（ステップ１８１）。

デバイス３００からの接続要求があった場合（ステップ１８２のＹｅｓ）、接続処理部１０１は、当該デバイス３００からの接続要求を受け入れ、接続を確立する（ステップ１８３）。

続いて接続処理部１０１は、接続元のデバイス３００から、そのデバイスＩＤを受信する（ステップ１８４）。

そして接続処理部１０１は、上記接続情報リスト１０４に上記デバイスＩＤ及び接続に関する情報（ＩＰアドレス及びソケット番号）を記録し、当該デバイス３００を新たに接続管理対象に加える（ステップ１８５）。

図１９は、メッセージングサーバ１００の上記接続管理部１０２及び上記メッセージ処理部１０５の動作の流れを示したフローチャートである。

同図に示すように、接続管理部１０２はまず、上記接続情報リスト１０４で管理している全ての接続について、メッセージの受信、エラーまたは通信切断の何れかを待つ（ステップ１９１）。

続いて接続管理部１０２は、メッセージを受信したか否かを判断する（ステップ１９２）。

メッセージを受信したと判断した場合（Ｙｅｓ）、接続管理部１０２は、当該メッセージから、その送付先に設定されているノードＩＤを取得する（ステップ１９３）。

続いて接続管理部１０２は、取得したノードＩＤが、メッセージングサーバ１００のノードＩＤ（サーバＩＤ）であるか否かを判断する（ステップ１９４）。

上記ノードＩＤがメッセージングサーバ１００のノードＩＤであると判断した場合（Ｙｅｓ）、メッセージ処理部１０５が上記メッセージを処理する（ステップ１９５）。

一方、送付先のノードＩＤがメッセージングサーバ１００のノードＩＤでないと判断した場合（Ｎｏ）、接続管理部１０２は、送付先に設定されているノードＩＤから、それに対応するメッセージングサーバのノードＩＤを判定する（ステップ１９６）。

上述のように、本実施形態では、メッセージングサーバ１００は１台のみであるから、接続管理部１０２は、送付先に対応するサーバのノードＩＤは自身（メッセージングサーバ１００）のノードＩＤであると判定する（ステップ１９７のＹｅｓ）。

そして接続管理部１０２は、メッセージ送信部１０６へ上記メッセージを引き渡す（ステップ１９８）。

上記ステップ１９２において、メッセージを受信していないと判断した場合（Ｎｏ）、接続管理部１０２は、管理対象のいずれかの接続について、エラーの発生または通信切断があったか否かを判断する（ステップ１９９）。

エラーの発生または通信切断があったと判断した場合（Ｙｅｓ）、接続管理部１０２は、当該エラーが発生しまたは通信が切断された接続に関するエントリを接続情報リスト１０４から除外する（ステップ２００）。

図２０は、メッセージングサーバ１００の上記メッセージ送信部１０６の動作の流れを示したフローチャートである。

同図に示すように、メッセージ送信部１０６はまず、上記通知手段リスト１０３から、送付先に設定されているノードＩＤと合致するエントリを取得する（ステップ２０１）。

上記通知手段リスト１０３に、上記ノードＩＤと合致するエントリが存在しないと判断した場合（ステップ２０２のＹｅｓ）は、メッセージ送信部１０６は、処理を終了する。

上記ノードＩＤと合致するエントリが存在すると判断した場合（ステップ２０２のＮｏ）、メッセージ送信部１０６は、当該エントリの通知手段が、通知サーバ２００以外に設定されているか否かを判断する（ステップ２０３）。

上記通知手段が通知サーバ２００以外に設定されていると判断した場合（Ｙｅｓ）、メッセージ送信部１０６は、当該エントリ上の関連情報に基づいて、メッセージ送付先のデバイス３００（３００Ｂ）と接続を確立する（ステップ２０４）。

続いてメッセージ送信部１０６は、上記接続を用いて、上記通知メッセージをデバイス３００へ送信する（ステップ２０５）。

通知メッセージの送信が完了した場合、メッセージ送信部１０６は、上記デバイス３００との接続を解除する（ステップ２０６）。

一方、上記ステップ２０３で、通知手段が通知サーバ２００に設定されていると判断した場合（Ｎｏ）、メッセージ送信部１０６は、送付先に設定されているノードＩＤから、それに対応する通知サーバ２００のノードＩＤ（サーバＩＤ）を判定する（ステップ２０７）。

続いてメッセージ送信部１０６は、上記ノートＩＤを有する通知サーバ２００へ、メッセージの送付先に設定されているデバイス３００への通知要求を、そのノードＩＤ（デバイスＩＤ）とともに送信する（ステップ２０９）。当該送信が完了した場合、メッセージ送信部１０６は、通知サーバ２００との接続を解除する（ステップ２１０）。

続いてメッセージ送信部１０６は、メッセージ送付先のデバイス３００からの新たな接続またはタイムアウトを待つ（ステップ２１１）。

当該送付先のノードＩＤを有するデバイス３００がメッセージングサーバ１００に接続されたと判断した場合（ステップ２１２のＹｅｓ）、メッセージ送信部１０６は、当該ノードＩＤに対応する接続を用いて、当該デバイス３００へメッセージを送信する（ステップ２１３）。

一方、通知サーバ２００への通知要求を送信してから、所定の時間内に、上記送付先のノードＩＤを有するデバイス３００から接続がない（タイムアウトした）場合（ステップ２１４のＹｅｓ）、メッセージ送信部１０６は、メッセージを破棄する（ステップ２１５）。

そしてメッセージ送信部１０６は、上記通知手段リスト１０３から、上記送付先のノードＩＤと合致する次のエントリを取得し（ステップ２１６）、上記ステップ２０２以降の処理を繰り返す。

［まとめ］
以上説明したように、本実施形態では、クラウド側に、メッセージングサーバ１００に加えて、デバイス３００への通知手段としての通知サーバ２００が設けられることで、各デバイス３００は、通信中継装置３１０が存在する場合でも、クラウド側と常時接続することができる。また、それにより、メッセージングサーバ１００の負荷も軽減する。

また、全てのデバイス３００がメッセージングサーバ１００に常時接続する場合と比較して、通知サーバ２００に常時接続した上で、必要なときのみにメッセージングサーバ１００に接続することの利点は、後者の方が、１台のサーバに接続できるデバイス３００の数を大幅に増やすことができることである。例えば、メッセージングサーバ１００が１台でサポート可能なデバイス数が５万台だとすると、通知サーバ２００が１台でサポート可能なデバイス数は１００万台となる。

メッセージングサーバ１００では、行われる処理が複雑な上に、通信の効率の観点から、１つの接続あたりの通信バッファサイズを十分に用意する必要がある。しかし、通知サーバ２００では、通知サーバ２００は、単にデバイス３００へ非常に小さなメッセージ（通知メッセージ）を送付する機能だけ有していればよく、処理も非常にシンプルな上に、通信バッファも最小限で済む。したがって、通知サーバ２００が１台あたりに必要なリソースを極限まで最小化することができる。

さらに本実施形態では、他の通知手段として、通信中継装置３１０に外部からの通信を内部の特定のデバイス３００へ転送するように設定可能な場合には、当該機構が用いられることで、クラウド側の負荷がさらに軽減される。UPnP IGD等、通知サーバ２００以外の手段は、単独では全てのデバイス３００間の通信に適用できない場合もあるが、上記通知サーバ２００を前提としたシステムにおいては、システム全体の負荷を軽減するための手段としては有効に機能する。

＜第２の実施形態＞
次に、本技術の第２の実施形態を説明する。本実施形態において、上記第１の実施形態と同様の構成及び機能を有する箇所には同一の符号を付し、説明を省略する。

［システムのネットワーク構成］
図２１は、本実施形態に係るシステムのネットワーク構成を示した図である。

上記第１の実施形態では、メッセージングサーバ１００及び通知サーバ２００はクラウド（ＷＡＮ５０）側にそれぞれ１台のみ設けられたが、同図に示すように、本実施形態では、メッセージングサーバ１００及び通知サーバ２００がそれぞれ複数設けられる。後述するが、このような構成により、デバイス３００からのメッセージが、複数のメッセージングサーバ１００間で中継される。

同図では、メッセージングサーバ１００は計６台、通知サーバ２００は計２台示されているが、メッセージングサーバ１００及び通知サーバ２００の数はこれらに限られない。

［各機器のモジュール構成］
図２２は、上記メッセージングサーバ１００、通知サーバ２００及びデバイス３００がそれぞれ有するソフトウェアモジュールの構成を示した図である。

（メッセージングサーバのモジュール構成）
同図に示すように、メッセージングサーバ１００は、上記第１の実施形態と同様のモジュール（図４参照）に加えて、メッセージ転送部１０７を有する。

メッセージ転送部１０７は、メッセージングサーバ１００（１００Ａ）が自ら担当しないデバイス３００へメッセージを送るために、当該メッセージを他のメッセージングサーバ１００（１００Ｂ）へ転送する。

本実施形態において、通知サーバ２００及びデバイス３００が有するモジュールの構成は第１の実施形態で説明したものと同様である。

［システムの動作］
次に、以上のように構成されたシステムにおけるメッセージングサーバ１００、通知サーバ２００及びデバイス３００の動作について、デバイス３００間のデータ（メッセージ）送信処理を中心に説明する。

（デバイスが利用するサーバの決定処理）
本実施形態では、メッセージングサーバ１００及び通知サーバ２００が複数設けられることから、メッセージの送信処理に先立ち、各デバイス３００がどのメッセージングサーバ１００及び通知サーバ２００を利用するかが予め決定される。このデバイス３００とそれが利用する各サーバとの対応関係は、デバイスＩＤを基にした所定の計算により決定される。この決定処理についてまず説明する。

以下で説明する決定処理は一例であり、メッセージングサーバ１００とデバイス３００の双方で実行でき、どちらで実行しても同じ結果が得られることが保証されさえすれば、どのような方法で対応関係が決定されてもよい。

図２３は、当該デバイス３００に対応するサーバの決定処理の流れを示したフローチャートである。以下の処理は、メッセージングサーバ１００の上記メッセージ転送部１０７が実行するものとして説明するが、他のモジュールが実行しても構わない。

同図に示すように、メッセージ転送部１０７は、まず、メッセージングサーバ１００及び通知サーバ２００のそれぞれについて、0から0xffffffffまでの値を、実際に用いるサーバの数に応じて分割し、サーバ割り当てテーブルを作成しておく（ステップ２７１）。当該テーブルは例えば記憶部１８に記憶される。

図２４は、メッセージングサーバ１００についてのサーバ割り当てテーブルの例を示した図であり、図２５は、通知サーバ２００についてのサーバ割り当てテーブルの例を示した図である。両図に示すように、上記0から0xffffffffまでの値が所定の範囲ごとに分割され、当該値の範囲に対してそれぞれメッセージングサーバ１００及び通知サーバ２００の各サーバＩＤが割り当てられている。

続いてメッセージ転送部１０７は、サーバ割り当て対象のデバイス３００から、そのノードＩＤを受信する（ステップ２７２）。

続いてメッセージ転送部１０７は、上記受信したノードＩＤと、所定のパディングデータとを組み合わせて、SHA256-HASHによるハッシュ値を計算する（ステップ２７３）。

続いてメッセージ転送部１０７は、得られたハッシュ値から、その下位３２ビットを取り出す（ステップ２７４）。

そしてメッセージ転送部１０７は、上記取り出した下位３２ビットを、上記サーバ割り当てテーブルから検索して、それに割り当てられたサーバＩＤを参照することで、対応するサーバＩＤを決定する（ステップ２７５）。

同図では、メッセージングサーバ１００が決定処理を実行する例が示されたが、上記処理の全てまたは一部（例えばステップ２７２〜２７４）は、デバイス３００で実行されてもよい。その際、上記サーバ割り当てテーブル等、必要な情報はメッセージングサーバ１００からデバイス３００へ送信される。

また、上記第１の実施形態と同様に、デバイスＩＤは、各デバイス３００のハードウェアに埋め込まれた情報(Wireless LANのMACアドレスや携帯電話のIMEI等)に基づいて決定される。したがって、ユーザは、デバイス３００を購入後、何も設定しなくても、当該デバイス３００に対応するメッセージングサーバ１００及び通知サーバ２００と接続ができ、それらを介して任意の他のデバイス３００と通信できる環境を享受できる。

（サーバのネットワークアドレスの決定処理）
本実施形態では、メッセージングサーバ１００及び通知サーバ２００が複数設けられることから、上記複数のメッセージングサーバ１００及び通知サーバ２００のサーバＩＤに対応する、ＴＣＰ／ＩＰ上のネットワークアドレスも予め決定する必要がある。以下、当該ネットワークアドレスの決定処理について説明する。

このネットワークアドレスの決定処理についても、以下の説明は一例であり、メッセージングサーバ１００とデバイス３００の双方で実行でき、どちらで実行しても同じ結果が得られることが保証されさえすれば、どのような方法で実行されてもよい。

以下では、上記ネットワークアドレス（ＩＰアドレス及びポート番号）を決定するために、（１）ＤＮＳ（Domain Name System）を用いる例と、（２）レゾリューションテーブルを用いる例とを説明する。以下の処理も、メッセージングサーバ１００の上記メッセージ転送部１０７が実行するものとして説明するが、他のモジュールが実行しても構わない。

（１）ＤＮＳを用いる例
メッセージングサーバ１００のメッセージ転送部１０７は、ネットワークアドレス決定対象である他のメッセージングサーバ１００のサーバ番号から、ホスト名を生成する。そしてメッセージ転送部１０７は、当該ホスト名を基に、TCP/IPネットワーク上のDNS機構を用いてＩＰアドレスを取得する。

例えば、メッセージングサーバ１００のホスト名は"ms15.server.com"と生成され、通知サーバのホスト名は"ns1.server.com"と生成される。

また、それぞれのポート番号としては、固定値が用いられる。

そして、上記取得されたＩＰアドレス及びポート番号は、デバイス３００、他のメッセージングサーバ１００及び通知サーバ２００に配布される。

（２）レゾリューションテーブルを用いる例
メッセージ転送部１０７は、サーバ番号に対応するＩＰアドレス及びポート番号を定めたレゾリューションテーブルを、メッセージングサーバ１００と通知サーバ２００のそれぞれについて作成する。これらレゾリューションテーブルは、デバイス３００、他のメッセージングサーバ１００及び通知サーバ２００に配布される。

図２６は、メッセージングサーバ１００用のレゾリューションテーブルの例を示した図であり、図２７は、通知サーバ２００用のレゾリューションテーブルの例を示した図である。

（データ送信処理例）
次に、本実施形態におけるデバイス３００間のデータ（メッセージ）送信処理を説明する。図２８は、当該デバイス３００間におけるデータ送信処理の流れの概要を模式的に示した図である。

同図に示すように、まず、メッセージ送信元のデバイス３００Ａが、デバイス３００Ｂ宛のメッセージをメッセージングサーバ１００Ａへ送信する（同図（１））。

続いて、メッセージを受信したメッセージングサーバ１００Ａは、それが他のメッセージングサーバ１００Ｂが対応すべきメッセージであると判断すると、当該メッセージをメッセージングサーバ１００Ｂへ転送する（同図（２））。

続いて、メッセージを転送されたメッセージングサーバ１００Ｂが、それに対応した通知サーバ２００Ｂに対して、デバイス３００Ａからデバイス３００Ｂ宛のメッセージの存在を通知するよう要求する通知要求を送信する。当該通知要求を受けた通知サーバ２００Ｂは、それに対応するデバイス３００Ｂへ通知メッセージを送信する（同図（３））。

そして、上記通知メッセージを受信したデバイス３００Ｂが、それに対応するメッセージングサーバ１００Ｂと接続を確立して、上記デバイス３００Ａからのメッセージを受信する（同図（４））。

（メッセージングサーバの動作）
次に、上記送信処理におけるメッセージングサーバ１００の動作について説明する。以下の説明では、デバイス３００から最初にメッセージを受信するメッセージングサーバ１００Ａの動作を示す。また、他のメッセージングサーバ１００を説明の便宜上メッセージングサーバ１００Ｂと称する。

図２９は、メッセージングサーバ１００Ａの接続処理部１０１の動作の流れを示したフローチャートである。

同図に示すように、接続処理部１０１はまず、デバイス３００または他のメッセージングサーバ１００Ｂからの接続要求を待つ（ステップ２９１）。

デバイス３００または他のメッセージングサーバ１００Ｂからの接続要求があった場合（ステップ２９２のＹｅｓ）、接続処理部１０１は、当該接続要求を受け入れ、接続を確立する（ステップ２９３）。

続いて接続処理部１０１は、接続元のデバイス３００または他のメッセージングサーバ１００Ｂから、そのノードＩＤ（デバイスＩＤ、サーバＩＤ）を受信する（ステップ２９４）。

そして接続処理部１０１は、上記接続情報リスト１０４に上記ノードＩＤ及び接続に関する情報（ＩＰアドレス及びソケット番号）を記録し、当該デバイス３００または他のメッセージングサーバ１００Ｂを新たに接続管理対象に加える（ステップ２９５）。

図３０は、メッセージングサーバ１００Ａの接続管理部１０２の動作の流れを示したフローチャートである。

同図に示すように、接続管理部１０２はまず、上記接続情報リスト１０４で管理している全ての接続について、メッセージの受信、エラーまたは通信切断の何れかを待つ（ステップ３０１）。

続いて接続管理部１０２は、メッセージを受信したか否かを判断する（ステップ３０２）。

メッセージを受信したと判断した場合（Ｙｅｓ）、接続管理部１０２は、当該メッセージから、その送付先に設定されているノードＩＤを取得する（ステップ３０３）。

続いて接続管理部１０２は、取得したノードＩＤが、メッセージングサーバ１００ＡのノードＩＤ（サーバＩＤ）であるか否かを判断する（ステップ３０４）。

上記ノードＩＤがメッセージングサーバ１００ＡのノードＩＤであると判断した場合（Ｙｅｓ）、メッセージ処理部１０５が上記メッセージを処理する（ステップ３０５）。

一方、送付先のノードＩＤがメッセージングサーバ１００ＡのノードＩＤでないと判断した場合（Ｎｏ）、接続管理部１０２は、上記サーバ割り当てテーブルを参照して、送付先に設定されているノードＩＤから、それに対応するメッセージングサーバのノードＩＤを判定する（ステップ３０６）。

続いて接続管理部１０２は、上記ユーザＩＤに対応するメッセージングサーバのノードＩＤがメッセージングサーバ１００ＡのノードＩＤであるか否かを判断する（ステップ３０７）。

対応するメッセージングサーバのノードＩＤがメッセージングサーバ１００ＡのノードＩＤであると判断した場合（Ｙｅｓ）、接続管理部１０２は、メッセージ送信部１０６へ上記メッセージを引き渡す（ステップ３０８）。

一方、対応するメッセージングサーバのノードＩＤが他のメッセージングサーバ１００ＢのノードＩＤであると判断した場合（Ｎｏ）、接続管理部１０２は、メッセージ転送部１０７へ上記メッセージを引き渡す（ステップ３０９）。

上記ステップ３０２において、メッセージを受信していないと判断した場合（Ｎｏ）、接続管理部１０２は、管理対象のいずれかの接続について、エラーの発生または通信切断があったか否かを判断する（ステップ３１０）。

エラーの発生または通信切断があったと判断した場合（Ｙｅｓ）、接続管理部１０２は、当該エラーが発生しまたは通信が切断された接続に関するエントリを接続情報リスト１０４から除外する（ステップ３１１）。

図３１は、メッセージングサーバ１００Ａのメッセージ転送部１０７の動作の流れを示したフローチャートである。

同図に示すように、メッセージ転送部１０７は、上記接続情報リスト１０４に基づき、他のメッセージングサーバ１００ＢのノードＩＤに対応する接続が存在するか（他のメッセージングサーバ１００Ｂに既に接続されているか）否かを確認する（ステップ３１１）。

対応する接続が存在すると判断した場合（ステップ３１２のＹｅｓ）、メッセージ転送部１０７は、当該接続された他のメッセージングサーバ１００Ｂへメッセージを転送する（ステップ３１３）。

一方、対応する接続が存在しないと判断した場合（ステップ３１２のＮｏ）、メッセージ転送部１０７は、当該他のメッセージングサーバ１００Ｂと接続を確立する（ステップ３１４）。

そしてメッセージ転送部１０７は、上記接続情報リスト１０４にそのエントリを追加した上で（ステップ３１５）、上記ステップ３１１以降の処理を繰り返す。

［まとめ］
以上説明したように、本実施形態においては、メッセージングサーバ１００及び通知サーバ２００が複数設けられ、メッセージングサーバ１００間でメッセージが転送されることで、非常に多数のデバイス３００間での通信がサポートされる。

＜第３の実施形態＞
次に、本技術の第３の実施形態を説明する。本実施形態において、上記第１及び第２の実施形態と同様の構成及び機能を有する箇所には同一の符号を付し、説明を省略する。

［システムのネットワーク構成］
図３２は、本実施形態に係るシステムのネットワーク構成を示した図である。

上述の第１及び第２の実施形態では、各デバイス３００をそれぞれ別々のユーザが所有することを前提にしていた。しかし、複数のデバイス３００を複数のユーザが所有することも当然あり得る。その場合、同じユーザが所有するデバイス３００間の通信は、他と比較して多くなると考えられる。そこで本実施形態では、各デバイス３００の「オーナー」という概念を導入し、オーナーを識別するユーザＩＤが設定されているデバイス３００については、当該ユーザＩＤからそれに対応するメッセージングサーバ１００及び通知サーバ２００を決定することとしている。

同図に示すように、本実施形態でも、上記第２の実施形態と同様に、メッセージングサーバ１００及び通知サーバ２００はそれぞれクラウド上に複数存在する。またデバイス３００中、デバイス３００Ｂとデバイス３００Ｃには同一のユーザがオーナーとして設定されている。この場合、デバイス３００Ｂはメッセージングサーバ１００Ｂ及び通知サーバ２００Ｂがその対応する各サーバとして設定される。またデバイス３００Ｃについては、上記第２の実施形態で説明したサーバ割り当てテーブルに基づいて、メッセージングサーバ１００Ｃと通知サーバ２００Ｃがその対応する各サーバに設定されるほか、デバイス３００Ｂと同一のユーザＩＤを有することから、メッセージングサーバ１００Ｂ及び通知サーバ２００Ｂもその対応する各サーバとして設定される。

［システムの動作］
次に、以上のように構成されたシステムにおけるメッセージングサーバ１００、通知サーバ２００及びデバイス３００の動作について、デバイス３００間のデータ（メッセージ）送信処理を中心に説明する。

（ユーザＩＤを基にした利用サーバの決定処理）
メッセージングサーバ１００は、初期データとして、上記第２の実施形態で説明したようなデバイスＩＤを基にしたメッセージングサーバ割り当てテーブル及び通知サーバ割り当てテーブル（以下、デバイスＩＤ用サーバ割り当てテーブルと称する）に加えて、ユーザＩＤを基にしたメッセージングサーバ割り当てテーブル及び通知サーバ割り当てテーブル（以下、ユーザＩＤ用サーバ割り当てテーブルと称する）を作成する。これらのテーブルは予め各デバイス３００並びに各メッセージングサーバ１００及び通知サーバ２００へ配布される。当該ユーザＩＤ用サーバ割り当てテーブルの作成方法は、デバイスＩＤがユーザＩＤに代わる以外は、上記第２実施形態で説明したのと同様である。

これらデバイスＩＤ用サーバ割り当てテーブル及びユーザＩＤ用サーバ割り当てテーブルは、デバイス３００側で作成されてもよい。

上記各テーブルの作成にあたって、デバイスＩＤを基に割り当てられる各サーバ群と、ユーザＩＤを基に割り当てられる各サーバ群とは、別個に用意される。

また各デバイス３００は、ユーザＩＤ（オーナーＩＤ）を記録する手段を有する。各デバイス３００の初期状態では、NULLが設定される。

ユーザＩＤが未設定のデバイス３００は、上記第２実施形態と同様に、デバイスＩＤによって決定されるメッセージングサーバ１００及び通知サーバ２００と接続する。

一方、ユーザＩＤが設定済みのデバイス３００は、デバイスＩＤとユーザＩＤのそれぞれによって決定されるメッセージングサーバ１００及び通知サーバ２００の全てと接続可能とされている。メッセージ送信側のデバイス３００は、通常はそのユーザＩＤによって決定されるメッセージングサーバ１００に接続する。メッセージ受信側のデバイス３００は、メッセージの宛先にユーザＩＤが設定されていればそれに対応するメッセージングサーバ１００へ接続し、そうでない場合にはデバイスＩＤに対応するメッセージングサーバ１００へ接続する。

各デバイス３００は、メッセージ送付先のデバイス３００のデバイスＩＤとユーザＩＤの双方を知っている場合には、双方をメッセージの宛先に設定してメッセージを送信する。

一方、各デバイス３００は、メッセージ送付先のデバイス３００のデバイスＩＤのみを知っている場合には、当該デバイスＩＤをメッセージの宛先に設定してメッセージを送信する。

（メッセージングサーバの動作）
次に、上記メッセージ送信処理におけるメッセージングサーバ１００の動作について説明する。図３３は、当該動作の流れを示したフローチャートである。以下の説明では、デバイス３００から最初にメッセージを受信するメッセージングサーバ１００Ａの動作を示す。また、他のメッセージングサーバ１００を説明の便宜上メッセージングサーバ１００Ｂと称する。

同図に示すように、メッセージングサーバ１００Ａの接続管理部１０２はまず、上記接続情報リスト１０４で管理している全ての接続について、メッセージの受信、エラーまたは通信切断の何れかを待つ（ステップ３３１）。

続いて接続管理部１０２は、メッセージを受信したか否かを判断する（ステップ３３２）。

メッセージを受信したと判断した場合（Ｙｅｓ）、接続管理部１０２は、当該メッセージから、その送付先に設定されているユーザＩＤ及びノードＩＤを取得する（ステップ３３３）。

続いて接続管理部１０２は、取得したノードＩＤが、メッセージングサーバ１００ＡのノードＩＤ（サーバＩＤ）であるか否かを判断する（ステップ３３４）。

上記ノードＩＤがメッセージングサーバ１００ＡのノードＩＤであると判断した場合（Ｙｅｓ）、メッセージ処理部１０５が上記メッセージを処理する（ステップ３３５）。

一方、送付先のノードＩＤがメッセージングサーバ１００ＡのノードＩＤでないと判断した場合（Ｎｏ）、接続管理部１０２は、送付先としてユーザＩＤとノードＩＤの双方が存在するか否かを判断する（ステップ３３６）。

送付先のユーザＩＤとノードＩＤの双方が存在すると判断した場合（Ｙｅｓ）、接続管理部１０２は、上記ユーザＩＤ用サーバ割り当てテーブルを参照して、送付先に設定されているユーザＩＤから、それに対応するメッセージングサーバのノードＩＤを判定する（ステップ３３７）。

続いて接続管理部１０２は、上記ユーザＩＤに対応するメッセージングサーバのノードＩＤがメッセージングサーバ１００ＡのノードＩＤであるか否かを判断する（ステップ３３８）。

対応するメッセージングサーバのノードＩＤがメッセージングサーバ１００ＡのノードＩＤであると判断した場合（Ｙｅｓ）、接続管理部１０２は、メッセージ送信部１０６へ上記メッセージを引き渡す（ステップ３３９）。

一方、対応するメッセージングサーバのノードＩＤが他のメッセージングサーバ１００ＢのノードＩＤであると判断した場合（Ｎｏ）、接続管理部１０２は、メッセージ転送部１０７へ上記メッセージを引き渡す（ステップ３４０）。

上記ステップ３３６において、送付先のユーザＩＤとノードＩＤの双方が存在しない、すなわち、ノードＩＤのみが存在すると判断した場合（Ｎｏ）、接続管理部１０２は、上記デバイスＩＤ用サーバ割り当てテーブルを参照して、送付先に設定されているノードＩＤ（デバイスＩＤ）から、それに対応するメッセージングサーバのノードＩＤを判定する（ステップ３４１）。

続いて接続管理部１０２は、上記ノードＩＤに対応するメッセージングサーバのノードＩＤがメッセージングサーバ１００ＡのノードＩＤであるか否かを判断する（ステップ３４２）。

対応するメッセージングサーバのノードＩＤがメッセージングサーバ１００ＡのノードＩＤであると判断した場合（Ｙｅｓ）、接続管理部１０２は、メッセージ送信部１０６へ上記メッセージを引き渡す（ステップ３４３）。

一方、対応するメッセージングサーバのノードＩＤが他のメッセージングサーバ１００ＢのノードＩＤであると判断した場合（Ｎｏ）、接続管理部１０２は、メッセージ転送部１０７へ上記メッセージを引き渡す（ステップ３４４）。

上記ステップ３３２において、メッセージを受信していないと判断した場合（Ｎｏ）、接続管理部１０２は、管理対象のいずれかの接続について、エラーの発生または通信切断があったか否かを判断する（ステップ３４６）。

エラーの発生または通信切断があったと判断した場合（Ｙｅｓ）、接続管理部１０２は、当該エラーが発生しまたは通信が切断された接続に関するエントリを接続情報リスト１０４から除外する（ステップ３４７）。

［まとめ］
以上説明したように、本実施形態によれば、同一のユーザＩＤが設定されたデバイス３００は、メッセージの宛先に当該ユーザＩＤが設定されている限り、同一のメッセージングサーバ１００及び通知サーバ２００に接続することになる。したがって、メッセージングサーバ１００間の通信が削減され、クラウド側の負荷が低減する。

［変形例］
本技術は上述の実施形態にのみ限定されるものではなく、本技術の要旨を逸脱しない範囲内において種々変更され得る。

上述の各実施形態では、メッセージングサーバ１００から通知サーバ２００への通信は、通信の度に接続確立／接続解除されるが、一定時間は接続が維持されてもよい。

上述の各実施形態では、メッセージングサーバ１００は、複数の通知手段が利用可能な場合、それらを順に試していた。しかし、メッセージングサーバ１００は、レスポンスを向上させるため、複数の通信手段が利用可能な場合、優先順位に従って試してもよいし、複数の通知手段で並行して通知してもよい。

上述の各実施形態では、通知手段を設定するために各デバイス３００に通知手段設定部３０１が設けられたが、各デバイス３００が特定の通知手段しか用いない場合は、通知手段設定部３０１は省略されてもよい。

上述の各実施形態では、各デバイス３００には、通知サーバ２００の利用の有無に応じて、通知サーバ通知受信部３０２と直接通知受信部３０３とが設けられたが、それらはどちらか一方のみが動作してもよいし、同時に動作可能とされてもよい。

上述の各実施形態では、各デバイス３００のメッセージ受信部３０４で用いられる接続は、一度確立すると一定時間保持されていたが、メッセージ受信部３０４は、必要に応じてサーバと毎回接続してもよい。また上述の各実施形態では、各デバイス３００のメッセージ送信部３０５で用いられる接続は、毎回接続確立／接続解除されるが、一度接続が確立した場合には一定時間それが保持されてもよい。

上述の各実施形態では、各デバイス３００のメッセージ受信部３０４及びメッセージ送信部３０５は別個のモジュールとして示されたが、両者で用いられる接続が共用されてもよい。

上述の各実施形態では、各デバイス３００は、メッセージングサーバ１００と接続している期間も、通知サーバ２００との接続を維持していた。しかし、各デバイス３００は、一旦通知サーバ２００との接続を切断し、メッセージングサーバ１００との接続が解除されたときに、再度通知サーバ２００と接続してもよい。

上述の各実施形態では、デバイス３００間のメッセージングサーバ１００経由でのやり取りには、全てメッセージが用いられていた。しかし、各デバイス３００のアプリケーションには、このメッセージ機構を元に、ＲＰＣ（Remote Procedure Call）機構やストリーム通信機構、さらにはＨＴＴＰエミューレーション等の通信機構が提供されてもよい。

上述の実施形態では、メッセージングサーバ１００と通知サーバ２００とは物理的に異なるサーバとして示された。しかし、両者の違いは、各デバイス３００との接続についてのバッファサイズの設定や取り扱い方から生じることから、物理的に異なるサーバ上で動作させる形態でなくとも、以下のような形態でも同様の効果が得られる。
（１）単一のサーバマシン上で通知サーバプロセスとメッセージングサーバプロセス双方を動作させる。
（２）単一のサーバマシン上で、通知サーバ機能とメッセージングサーバ機能を持った１つのサーバプロセスを動作させる(デバイス３００との通信状況に応じて、通知サーバ相当の接続形態と、メッセージングサーバ相当の接続形態を切り替える)。

［その他］
本技術は以下のような構成も採ることができる。
［１］
第１の機器、第２の機器、並びに前記第２の機器とネットワークを介して常時接続される常時接続サーバとの間で、前記ネットワークを介して必要に応じて接続して通信可能な通信部と、
前記第１の機器から、前記第２の機器宛のデータを受信し、当該データの存在を通知する通知メッセージを前記第２の機器へ送信するように要求する通知要求情報を前記常時接続サーバへ送信し、前記通知メッセージを受信した第２の機器からの要求に応じて、前記データを当該第２の機器へ送信するように、前記通信部を制御可能な制御部と
を具備する情報処理装置。
［２］
上記［１］に記載の情報処理装置であって、
記憶部をさらに具備し、
前記第２の機器は、通信中継装置を介して当該情報処理装置及び前記常時接続サーバと通信し、
前記制御部は、
前記通信中継装置が、当該情報処理装置からの通信を第２の機器へ転送するように設定されている場合には、当該転送設定に関する情報を記憶するように前記記憶部を制御し、
前記記憶された情報を用いて、前記通知要求情報の送信に代えて、または、前記通知要求情報の送信に加えて、前記通知メッセージを前記第２の機器へ直接送信するように前記通信部を制御する
情報処理装置。
［３］
上記［１］または［２］に記載の情報処理装置であって、
前記制御部は、前記第２の機器にグローバルＩＰアドレスが割り当てられている場合には、前記通知要求情報の送信に代えて、または、前記通知要求情報の送信に加えて、前記通知メッセージを前記第２の機器へ直接送信するように前記通信部を制御する
情報処理装置。
［４］
上記［１］〜［３］のいずれかに記載の情報処理装置であって、
当該情報処理装置及び前記常時接続サーバはそれぞれ複数存在し、
前記第１の機器及び前記第２の機器は、それぞれ１つの前記情報処理装置及び前記常時接続サーバと通信するよう、当該第１の機器、前記第２の機器、前記複数の情報処理装置、前記複数の常時接続サーバをそれぞれ一意に識別する機器識別情報を用いて対応付けられており、
前記制御部は、前記機器識別情報を基に、前記第２の機器が他の情報処理装置と対応付けられていると判断した場合には、前記データを当該他の情報処理装置へ転送するように前記通信部を制御する
情報処理装置。
［５］
上記［４］に記載の情報処理装置であって、
記憶部をさらに具備し、
前記制御部は、
前記第１の機器及び前記第２の機器のそれぞれの機器識別情報を基に所定のハッシュ関数から得られるハッシュ値に基づいた値と、当該複数の情報処理装置のそれぞれの識別情報との対応関係を定めたテーブルを作成し、
前記作成されたテーブルを記憶するように前記記憶部を制御し、
前記記憶されたテーブルを基に、前記第２の機器に対応する他の情報処理装置を決定する
情報処理装置。
［６］
上記［５］に記載の情報処理装置であって、
前記制御部は、前記第１の機器及び前記第２の機器にそれぞれを所有するユーザを一意に識別するユーザ識別情報が設定されている場合には、前記機器識別情報に代えて前記ユーザ識別情報を用いて前記テーブルを作成する
情報処理装置。

１１、３１…ＣＰＵ
１２、３２…ＲＯＭ
１３、３３…ＲＡＭ
１８、３８…記憶部
１９、３９…通信部
５０…ＷＡＮ
１００（１００Ａ，１００Ｂ，１００Ｃ）…メッセージングサーバ
１０１…接続処理部
１０２…接続管理部
１０３…通知手段リスト
１０４…接続情報リスト
１０５…メッセージ処理部
１０６…メッセージ送信部
１０７…メッセージ転送部
２００（２００Ａ，２００Ｂ，２００Ｃ）…通知サーバ
２０１…接続処理部
２０２…接続管理部
２０３…接続情報リスト
３００（３００Ａ，３００Ｂ，３００Ｃ）…デバイス
３０１…通知手段設定部
３０２…通知サーバ通知受信部
３０３…直接通知受信部
３０４…メッセージ受信部
３０５…メッセージ送信部
３０６…メッセージ処理部
３１０（３１０Ａ，３１０Ｂ）…通信中継装置

Claims (6)

1. 第１の機器、第２の機器、並びに前記第２の機器とネットワークを介して常時接続される常時接続サーバとの間で、前記ネットワークを介して必要に応じて接続して通信可能な通信部と、
   前記第１の機器から、前記第２の機器宛のデータを受信し、当該データの存在を通知する通知メッセージを前記第２の機器へ送信するように要求する通知要求情報を前記常時接続サーバへ送信し、前記通知メッセージを受信した第２の機器からの要求に応じて、前記データを当該第２の機器へ送信するように、前記通信部を制御可能な制御部と、
   記憶部とを具備し、
   前記第２の機器は、通信中継装置を介して当該情報処理装置及び前記常時接続サーバと通信し、
   前記制御部は、
   前記通信中継装置が、当該情報処理装置からの通信を第２の機器へ転送するように設定されている場合には、当該転送設定に関する情報を記憶するように前記記憶部を制御し、
   前記記憶された情報を用いて、前記通知要求情報の送信に代えて、または、前記通知要求情報の送信に加えて、前記通知メッセージを前記第２の機器へ直接送信するように前記通信部を制御する
   情報処理装置。
2. 第１の機器、第２の機器、並びに前記第２の機器とネットワークを介して常時接続される常時接続サーバとの間で、前記ネットワークを介して必要に応じて接続して通信可能な通信部と、
   前記第１の機器から、前記第２の機器宛のデータを受信し、当該データの存在を通知する通知メッセージを前記第２の機器へ送信するように要求する通知要求情報を前記常時接続サーバへ送信し、前記通知メッセージを受信した第２の機器からの要求に応じて、前記データを当該第２の機器へ送信するように、前記通信部を制御可能な制御部と
   を具備し、
   前記制御部は、前記第２の機器にグローバルＩＰアドレスが割り当てられている場合には、前記通知要求情報の送信に代えて、または、前記通知要求情報の送信に加えて、前記通知メッセージを前記第２の機器へ直接送信するように前記通信部を制御する
   情報処理装置。
3. 第１の機器、第２の機器、並びに前記第２の機器とネットワークを介して常時接続される常時接続サーバとの間で、前記ネットワークを介して必要に応じて接続して通信可能な通信部と、
   前記第１の機器から、前記第２の機器宛のデータを受信し、当該データの存在を通知する通知メッセージを前記第２の機器へ送信するように要求する通知要求情報を前記常時接続サーバへ送信し、前記通知メッセージを受信した第２の機器からの要求に応じて、前記データを当該第２の機器へ送信するように、前記通信部を制御可能な制御部と、
   記憶部と、を具備し、
   当該情報処理装置及び前記常時接続サーバはそれぞれ複数存在し、
   前記第１の機器及び前記第２の機器は、それぞれ１つの前記情報処理装置及び前記常時接続サーバと通信するよう、当該第１の機器、前記第２の機器、前記複数の情報処理装置、前記複数の常時接続サーバをそれぞれ一意に識別する機器識別情報を用いて対応付けられており、
   前記制御部は、前記機器識別情報を基に、前記第２の機器が他の情報処理装置と対応付けられていると判断した場合には、前記データを当該他の情報処理装置へ転送するように前記通信部を制御し、
   前記制御部は、
   前記第１の機器及び前記第２の機器のそれぞれの機器識別情報を基に所定のハッシュ関数から得られるハッシュ値に基づいた値と、当該複数の情報処理装置のそれぞれの識別情報との対応関係を定めたテーブルを作成し、
   前記作成されたテーブルを記憶するように前記記憶部を制御し、
   前記記憶されたテーブルを基に、前記第２の機器に対応する他の情報処理装置を決定する
   情報処理装置。
4. 請求項３に記載の情報処理装置であって、
   前記制御部は、前記第１の機器及び前記第２の機器にそれぞれを所有するユーザを一意に識別するユーザ識別情報が設定されている場合には、前記機器識別情報に代えて前記ユーザ識別情報を用いて前記テーブルを作成する
   情報処理装置。
5. 第１の機器とネットワークを介して接続を確立して当該第１の機器から第２の機器宛のデータを受信し、
   前記データの存在を通知する通知メッセージを当該第２の機器へ送信するように要求する通知要求情報を、前記第２の機器と常時接続されたサーバへ送信し、
   前記通知メッセージを受信した前記第２の機器からの要求に応じて、通信中継装置を介して接続を確立して当該第２の機器へ前記データを送信し、
   前記通信中継装置に記憶されている情報を用いて、前記通知要求情報の送信に代えて、または、前記通信要求情報の送信に加えて、前記通知メッセージを前記第２の機器へ直接送信する
   情報処理方法。
6. 情報処理装置に、
   第１の機器とネットワークを介して接続を確立して当該第１の機器から第２の機器宛のデータを受信するステップと、
   前記データの存在を通知する通知メッセージを当該第２の機器へ送信するように要求する通知要求情報を、前記第２の機器と常時接続された常時接続サーバへ送信するステップと、
   前記通知メッセージを受信した前記第２の機器からの要求に応じて、通信中継装置を介して当該第２の機器と接続を確立して当該第２の機器へ前記データを送信するステップと、
   前記通信中継装置に記憶されている情報を用いて、前記通知要求情報の送信に代えて、または、前記通信要求情報の送信に加えて、前記通知メッセージを前記第２の機器へ直接送信すステップと、
   を実行させるプログラム。

Images