JP6000231B2 - ネットワークシステム、常時接続方法、電子機器、常時接続サーバ、アプリケーションサーバ、プログラム - Google Patents

Description

本発明は、電子機器同士を常時接続するための技術に関し、特にクライアントとサーバとを常時接続するネットワークシステム、常時接続方法、電子機器、常時接続サーバ、アプリケーションサーバ、プログラムに関する。

従来から、通信機器が互いに相手にデータを送信するための様々な技術が知られている。たとえば、特開２０１０−２７７４９２号公報（特許文献１）には、電子会議サーバおよびコンピュータプログラムが開示されている。特開２０１０−２７７４９２号公報（特許文献１）によると、ウェブ・アプリケーションにて電子会議システムを提供する場合にリアルタイム性を確保可能とすること、および電子会議システムの運用に付随した未解決課題の管理などを実現する。具体的には、アプリケーションサーバは、Ｃｏｍｅｔサーバが各電子機器からのＨＴＴＰリクエストを受信して保留状態となるように制御する。ある電子機器からメッセージデータをアプリケーションサーバが受信したら、アプリケーションサーバが会議データベースから必要データを引き出してメッセージデータとともに該当する電子機器へＣｏｍｅｔサーバから送信する。送信後は前記アプリケーションサーバが各電子機器からのＨＴＴＰリクエストを受信して再び保留状態となるように制御する。

しかしながら、Ｃｏｍｅｔでは、通信のたびにＨＴＴＰセッションが必要となるため、クライアントとサーバとの間で何度も同じデータをやり取りする必要があった。そこで、近年では、ＴＣＰ（Transmission Control Protocol）上で動作するＷｅｂＳｏｃｋｅｔという技術が開発されている。ＷｅｂＳｏｃｋｅｔは、インターネットの標準化団体であるＷ３ＣとＩＥＴＦがウェブサーバとウェブブラウザとの間の双方向通信用の技術規格である。ＷｅｂＳｏｃｋｅｔプロトコルの仕様はＲＦＣ（Request For Comment）６４５５に規定されている。

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

しかしながら、従来のＷｅｂＳｏｃｋｅｔプロトコルを利用した常時接続では、サーバからのデータが常時接続中の複数のクライアントにマルチキャストされていた。すなわち、従来は、サーバからのデータを、選択した１つのクライアントにプッシュすることが困難であった。

本発明は、かかる問題を解決するためになされたものであり、その目的は、常時接続技術に関し、サーバからのデータを、選択した１つのクライアントにプッシュすることが可能なネットワークシステム、常時接続方法、電子機器、常時接続サーバ、アプリケーションサーバ、プログラムを提供することにある。

この発明のある態様に従うと、識別情報に対応付けられる複数の電子機器と、複数の電子機器と常時接続するための常時接続サーバと、識別情報に基づいて常時接続サーバを介して複数の電子機器のいずれかへ情報をプッシュするアプリケーションサーバとを備える、ネットワークシステムが提供される。なお、ここでいう、常時接続サーバは、コンピュータとしてのハードウェアと、サービスプログラムとしてのソフトウェアとを含む概念である。同様に、アプリケーションサーバも、コンピュータとしてのハードウェアと、サービスプログラムとしてのソフトウェアとを含む概念である。

好ましくは、常時接続サーバが第１のコンピュータに搭載される。アプリケーションサーバが第２のコンピュータに搭載される。

好ましくは、常時接続サーバとアプリケーションサーバとが、１つのコンピュータに搭載される。

好ましくは、複数の電子機器の各々と常時接続サーバとは、常時接続開始後に、常時接続可能なプロトコルを使用して識別情報を交換する。

好ましくは、アプリケーションサーバは、複数の電子機器のいずれかと常時接続サーバとに認証情報を発行する。常時接続サーバは、アプリケーションサーバからの認証情報と複数の電子機器のいずれかからの認証情報とに基づいて、アプリケーションサーバと複数の電子機器のいずれかとに識別情報を発行する。

好ましくは、ネットワークシステムは、アプリケーションサーバとして、複数のアプリケーションサーバを備える。複数のアプリケーションサーバの各々は、識別情報を利用することによって常時接続サーバを介して複数の電子機器のいずれかへ情報をプッシュする。

好ましくは、常時接続サーバは、電子機器にデータ本体とトランザクションＩＤとを電子機器に送信する。電子機器は、データ本体の受信完了後に、トランザクションＩＤを常時接続サーバに送信する。常時接続サーバは、電子機器からのトランザクションＩＤに基づいて、電子機器へのデータ送信が完了した旨をアプリケーションサーバに通知する。

好ましくは、電子機器は、常時接続サーバにデータ本体とトランザクションＩＤとを常時接続サーバに送信する。常時接続サーバは、データ本体の受信完了後に、トランザクションＩＤを電子機器に送信する。常時接続サーバは、電子機器からのトランザクションＩＤに基づいて、電子機器からのデータ受信が完了した旨をアプリケーションサーバに通知する。

この発明の別の態様に従うと、複数の電子機器と常時接続サーバとが常時接続を開始するステップと、複数の電子機器に識別情報を対応付けるステップと、アプリケーションサーバが、識別情報に基づいて常時接続サーバを介して複数の電子機器のいずれかへ情報をプッシュするステップとを備える、常時接続方法が提供される。

この発明の別の態様に従うと、識別情報を格納するメモリと、常時接続サーバと常時接続するための通信インターフェイスと、通信インターフェイスを利用することによって、識別情報に基づいて常時接続サーバを介してアプリケーションサーバからの情報を受信するプロセッサとを備える、電子機器が提供される。

この発明の別の態様に従うと、複数の電子機器に対応付けられる識別情報を格納するメモリと、複数の電子機器と常時接続し、アプリケーションサーバと通信するための通信インターフェイスと、通信インターフェイスを利用することによって、識別情報に基づいてアプリケーションサーバからの情報を複数の電子機器のいずれかにプッシュする、常時接続サーバが提供される。

この発明の別の態様に従うと、複数の電子機器に対応付けられる識別情報を格納するメモリと、常時接続サーバと通信するための通信インターフェイスと、通信インターフェイスを利用することによって、識別情報に基づいて常時接続サーバを介して複数の電子機器のいずれかに情報をプッシュするプロセッサとを備える、アプリケーションサーバが提供される。

この発明の別の態様に従うと、プロセッサとメモリと通信インターフェイスとを含む電子機器で利用されるプログラムが提供される。プログラムは、通信インターフェイスを介して常時接続サーバと常時接続を開始するステップと、識別情報をメモリに格納するステップと、通信インターフェイスを利用することによって、識別情報に基づいて常時接続サーバを介してアプリケーションサーバからの情報を受信するステップとをプロセッサに実行させる。

この発明の別の態様に従うと、プロセッサとメモリと通信インターフェイスとを含むコンピュータで利用されるプログラムが提供される。プログラムは、通信インターフェイスを利用することによって、複数の電子機器と常時接続を開始するステップと、複数の電子機器に対応付けられる識別情報をメモリに格納するステップと、通信インターフェイスを利用することによって、識別情報に基づいてアプリケーションサーバからの情報を複数の電子機器のいずれかにプッシュするステップとをプロセッサに実行させる。

この発明の別の態様に従うと、プロセッサとメモリと通信インターフェイスとを含むコンピュータで利用されるプログラムが提供される。プログラムは、複数の電子機器に対応付けられる識別情報をメモリに格納するステップと、通信インターフェイスを利用することによって、識別情報に基づいて常時接続サーバを介して複数の電子機器のいずれかに情報をプッシュするステップとをプロセッサに実行させる。

以上のように、この発明によれば、常時接続技術に関し、サーバからのデータを、選択した１つのクライアントにプッシュすることが可能なネットワークシステム、常時接続方法、電子機器、常時接続サーバ、アプリケーションサーバ、プログラムが提供される。

本実施の形態にかかるネットワークシステム１の全体構成を示すイメージ図である。 本実施の形態にかかるネットワークシステム１における常時接続開始時の動作概要を示す第１のイメージ図である。 本実施の形態にかかるネットワークシステム１における常時接続開始時の動作概要を示す第２のイメージ図である。 本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からの接続確認時の動作概要を示すイメージ図である。 本実施の形態にかかるネットワークシステム１におけるクライアント１００からの接続確認時の動作概要を示すイメージ図である。 本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からの通常の情報プッシュ時の動作概要を示すイメージ図である。 本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からの大容量の情報プッシュ時の動作概要を示すイメージ図である。 本実施の形態にかかるネットワークシステム１におけるクライアント１００からの通常の情報プッシュ時の動作概要を示すイメージ図である。 本実施の形態にかかるネットワークシステム１におけるクライアント１００からの大容量の情報プッシュ時の動作概要を示すイメージ図である。 本実施の形態にかかるネットワークシステム１全体の通信構成を示すブロック図である。 本実施の形態にかかるクライアント１００のハードウェア構成を表わすブロック図である。 本実施の形態にかかる常時接続サーバ２００のハードウェア構成を表わすブロック図である。 本実施の形態にかかるアプリケーションサーバ３００のハードウェア構成を表わすブロック図である。 本実施の形態にかかるスマートフォン５００のハードウェア構成を表わすブロック図である。 本実施の形態にかかるネットワークシステム１における常時接続に関する装置間のデータのやり取りの処理手順を示すシーケンス図である。 本実施の形態にかかるネットワークシステム１における常時接続開始時の処理手順の詳細を示すシーケンス図である。 本実施の形態にかかるネットワークシステム１におけるクライアントからの常時接続切断時の処理手順の詳細をシーケンス図である。 本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からの常時接続切断時の処理手順の詳細をシーケンス図である。 本実施の形態にかかるネットワークシステム１におけるクライアント１００からの接続確認時の処理手順の詳細をシーケンス図である。 本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からの接続確認時の処理手順の詳細をシーケンス図である。 本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からの通常のデータプッシュ時の処理手順の詳細をシーケンス図である。 本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からの大容量のデータプッシュ時の処理手順の詳細をシーケンス図である。 本実施の形態にかかるネットワークシステム１におけるクライアント１００からの通常のデータプッシュ時の処理手順の詳細をシーケンス図である。 本実施の形態にかかるネットワークシステム１におけるクライアント１００からの大容量のデータプッシュ時の処理手順の詳細をシーケンス図である。 本実施形態にかかるＷＳデータの構造を示すイメージ図である。 第５の実施の形態にかかるネットワークシステム１の通信構成を示すイメージ図である。 第６の実施の形態にかかるネットワークシステム１の通信構成を示すイメージ図である。 第７の実施の形態にかかるネットワークシステム１の通信構成を示すイメージ図である。

以下、図面を参照しつつ、本発明の実施の形態について説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称および機能も同じである。したがって、それらについての詳細な説明は繰り返さない。

また、以下では、常時接続の一例として、ＷｅｂＳｏｃｋｅｔプロトコルを利用した通信について説明する。しかしながら、アプリケーションサーバから任意のタイミングでクライアントにデータをプッシュできればよく、本発明はＷｅｂＳｏｃｋｅｔプロトコルを利用する常時接続に限定されるものではない。
＜第１の実施の形態＞
＜ネットワークシステムの全体構成＞

まず、本実施の形態にかかるネットワークシステム１の全体構成について説明する。図１は、本実施の形態にかかるネットワークシステム１の全体構成を示すイメージ図である。

図１を参照して、ネットワークシステム１は、住居またはオフィスなどに配置される複数の家電１００Ａ，１００Ｂと、ネットワークを介して家電１００Ａ，１００Ｂと接続される常時接続サーバ２００と、家電１００Ａ，１００Ｂに関する様々なサービスを提供する複数のアプリケーションサーバ３００Ａ，３００Ｂとを含む。家電としては、たとえば、掃除機１００Ａ、エアコン１００Ｂ、テレビ、洗濯機、冷蔵庫、炊飯器、空気清浄器、床暖房、ＩＨ（Induction Heating）クッキングヒーター、などが挙げられる。さらに、家電は、住居内またはオフィス内の通信機器であればよく、たとえば、パーソナルコンピュータ、テレビ以外のＡＶ機器、インターホンシステムなどを含んでもよい。また、常時接続サーバ２００とアプリケーションサーバ３００とは、家電と同じ住居内、オフィス内、ビル内、会社あるいは学校の構内に存在するサーバなどを含んでもよい。

また、家電と各サーバ間は、光ファイバ等の回線を経由し、途中に、光回線終端装置、無線ＬＡＮ通信を行うためのアクセスポイント、ルータ等が接続されてもよい。家電は、ネットワークに接続する手段として、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃなどの無線ＬＡＮ通信、あるいは、有線ＬＡＮなどが用いられるが、接続方法はこれらに限定されるものではない。

そして、本実施の形態においては、掃除機１００Ａおよびエアコン１００Ｂが、常時接続サーバ２００と常時接続される。これによって、掃除機用のアプリケーションサーバ３００Ａは、常時接続サーバ２００を介して任意のタイミングで掃除機１００Ａにデータをプッシュ送信することができる。同様に、エアコン用のアプリケーションサーバ３００Ｂは、常時接続サーバ２００を介して任意のタイミングでエアコン１００Ｂにデータをプッシュ送信することができる。

すなわち、本実施形態にかかるネットワークシステム１では、多数の家電の各々が、自身に適したサービスを提供するアプリケーションサーバの全てと、直接的に常時接続する必要がない。また、逆に、複数のアプリケーションサーバの各々が、対応する家電の全てと、直接的に常時接続する必要がない。

なお、本実施の形態においては、常時接続サーバ２００とアプリケーションサーバ３００Ａ，３００Ｂとが別々のコンピュータである。換言すれば、常時接続サーバ２００において、家電と常時接続するためのサービスプログラムが稼働する。そして、アプリケーションサーバ３００Ａ，３００Ｂにおいて、家電に情報を送信することによって家電を制御するためのサービスプログラムや、家電からの情報を取得することによって当該情報を他の電子機器で利用するためのサービスプログラムなどが稼働する。

しかしながら、他の実施の形態として後述するように、１つのアプリケーションサーバが複数のアプリケーションサービスプログラムを搭載してもよい。また、常時接続サーバとアプリケーションサーバとが同一のコンピュータであってもよい。たとえば、１つのコンピュータ、すなわち装置としてのサーバが、家電と常時接続するための通信サービスプログラムと、家電を制御するためのアプリケーションサービスプログラムとを搭載してもよい。
＜ネットワークシステムの動作概要＞

次に、本実施の形態にかかるネットワークシステム１の動作概要について説明する。なお、以下では、掃除機１００Ａ、エアコン１００Ｂなどの家電を総称して、クライアント１００ともいう。また、以下では、掃除機用のアプリケーションサーバ３００Ａおよびエアコン用のアプリケーションサーバ３００Ｂなどの各種のサービスをクライアント１００およびユーザなどに提供するためのアプリケーションサーバを総称して、アプリケーションサーバ３００ともいう。
＜常時接続開始時の動作概要＞

まず、ネットワークシステム１における常時接続開始時の動作概要について説明する。図２は、本実施の形態にかかるネットワークシステム１における常時接続開始時の動作概要を示す第１のイメージ図である。図３は、本実施の形態にかかるネットワークシステム１における常時接続開始時の動作概要を示す第２のイメージ図である。

図２を参照して、クライアント１００は、ＨＴＴＰプロトコルを使用して、アプリケーションサーバ３００に認証情報を要求する。すると、アプリケーションサーバ３００は、認証情報を生成し、ＨＴＴＰプロトコルを使用して、クライアント１００に認証情報を送信する。アプリケーションサーバ３００は、常時接続サーバ２００にも認証情報を送信する。

図３を参照して、クライアント１００は、ＨＴＴＰプロトコルを使用して、認証情報に基づいて常時接続サーバ２００に常時接続の開始を要求する。常時接続サーバ２００は、クライアント１００からの認証情報とアプリケーションサーバ３００からの認証情報とに基づいて、クライアント１００の認証処理を行う。認証に成功すると、常時接続サーバ２００は、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、クライアント１００との常時接続を確立する。常時接続サーバ２００は、クライアント１００とサーバ３００間のＷｅｂＳｏｃｋｅｔ接続を一意に特定するための接続ＩＤを作成し、接続ＩＤをアプリケーションサーバ３００に通知する。これによって、アプリケーションサーバ３００は、接続ＩＤに基づいて、常時接続サーバ２００を介して、クライアント１００に情報をプッシュすることが可能になる。
＜アプリケーションサーバからの接続確認時の動作概要＞

次に、アプリケーションサーバ３００からの接続確認時の動作概要について説明する。図４は、本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からの接続確認時の動作概要を示すイメージ図である。

図４を参照して、アプリケーションサーバ３００は、常時接続サーバ２００にクライアント１００との常時接続が有効であるか否か（たとえば、クライアント１００や常時接続サーバ２００が正常に動作しているか否か）についての接続確認（生死確認）を要求する。常時接続サーバ２００は、当該要求に応じて、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、クライアント１００に接続確認データを送信する。

クライアント１００は、接続確認データを受信したときに、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、常時接続サーバ２００に結果通知データを送信する。常時接続サーバ２００は、結果通知データを受信した場合、クライアント１００との常時接続が有効である旨をアプリケーションサーバ３００に送信する。一方、常時接続サーバ２００は、結果通知データを受信しなかった場合、クライアント１００との常時接続が無効である旨をアプリケーションサーバ３００に送信する。

このような構成は、以下のように利用される。たとえば、アプリケーションサーバ３００は、スマートフォン５００からの何らかの命令を受け付けた際あるいはスマートフォン５００に命令を受け付ける画面が表示される際に、常時接続サーバ２００に接続確認を要求する。そして、アプリケーションサーバ３００は、常時接続が有効である場合に限り、家電に対する命令の受付を続行する。一方、常時接続が有効でない場合、スマートフォン５００を介してユーザに命令を実行できない旨を通知する。
＜クライアントからの接続確認時の動作概要＞

次に、クライアント１００からの接続確認時の動作概要について説明する。図５は、本実施の形態にかかるネットワークシステム１におけるクライアント１００からの接続確認時の動作概要を示すイメージ図である。

図５を参照して、クライアント１００は、常時接続サーバ２００に常時接続が有効であるか否かを調べるために、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、常時接続サーバ２００に接続確認データを送信する。常時接続サーバ２００は、接続確認データを受信できたときに、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、クライアント１００に結果通知データを送信する。このとき、常時接続サーバ２００は、クライアント１００との常時接続が有効である旨をアプリケーションサーバ３００にも送信する。
＜アプリケーションサーバからの通常の情報プッシュ時の動作概要＞

次に、アプリケーションサーバ３００からクライアント１００への通常の情報プッシュ時の動作概要について説明する。図６は、本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からの通常の情報プッシュ時の動作概要を示すイメージ図である。

図６を参照して、アプリケーションサーバ３００は、クライアント１００を特定するための接続ＩＤとクライアント１００に送信するためのデータ本体とを、常時接続サーバ２００に送信する。常時接続サーバ２００は、当該データ本体が所定のデータ量よりも大きいか否かを判断する。常時接続サーバ２００は、当該データ本体が所定のデータ量以下である場合、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、データ本体と今回のデータ送信を特定するためのトランザクションＩＤとを、接続ＩＤに対応するクライアント１００に送信する。

クライアント１００は、データ本体を受信すると、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、当該データ本体を受信したことを示す結果情報と上記のトランザクションＩＤとを常時接続サーバ２００に送信する。常時接続サーバ２００は、受信した結果情報とトランザクションＩＤとに基づいて、データ送信の結果をアプリケーションサーバ３００に通知する。
＜アプリケーションサーバからの大容量の情報プッシュ時の動作概要＞

次に、アプリケーションサーバ３００からクライアント１００への大容量の情報プッシュ時の動作概要について説明する。図７は、本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からの大容量の情報プッシュ時の動作概要を示すイメージ図である。なお、より詳細には、常時接続による通信を大容量ファイルが占有することを防ぎ、常時接続に関するネットワークリソースの負荷を軽減するために、以下のような機能を有する。

図７を参照して、アプリケーションサーバ３００は、クライアント１００を特定するための接続ＩＤとクライアント１００に送信するためのデータ本体とを、常時接続サーバ２００に送信する。常時接続サーバ２００は、当該データ本体が所定のデータ量よりも大きいか否かを判断する。常時接続サーバ２００は、当該データ本体が所定のデータ量よりも大きい場合、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、データの取得方法を示すＵＲＬ情報と今回のデータ送信を特定するためのトランザクションＩＤとを、接続ＩＤに対応するクライアント１００に送信する。

クライアント１００は、ＵＲＬ情報とトランザクションＩＤとを受信すると、ＨＴＴＰプロトコルを使用して、常時接続サーバ２００にトランザクションＩＤを送信する。常時接続サーバ２００は、トランザクションＩＤに基づいて、クライアント１００にデータ本体を送信する。クライアント１００は、ＵＲＬ情報に対応する格納場所からデータ本体をダウンロードすると、データ本体を受信したことを示す結果情報と上記のトランザクションＩＤとを常時接続サーバ２００に送信する。常時接続サーバ２００は、受信した結果情報とトランザクションＩＤとに基づいて、データ送信の結果をアプリケーションサーバ３００に通知する。

なお、常時接続サーバ２００の代わりに、アプリケーションサーバ３００が、データの容量に関する上記の判断を行っても良い。この場合は、データの容量が所定値よりも大きい場合に、アプリケーションサーバ３００が、常時接続サーバ２００を介してクライアント１００にＵＲＬ情報を送信する。クライアント１００は、ＵＲＬ情報に基づいて、ＨＴＴＰプロトコルを利用して、常時接続サーバ２００かアプリケーションサーバ３００からデータをダウンロードする。
＜クライアントからの通常の情報プッシュ時の動作概要＞

次に、クライアント１００からの通常の情報プッシュ時の動作概要について説明する。図８は、本実施の形態にかかるネットワークシステム１におけるクライアント１００からの通常の情報プッシュ時の動作概要を示すイメージ図である。

図８を参照して、クライアント１００は、送信すべきデータ本体が所定のデータ量よりも大きいか否かを判断する。当該データ本体が所定のデータ量以下である場合、クライアント１００は、送信すべきアプリケーションサーバ３００を特定するためのサービスＩＤと、データ本体と、今回のデータ送信を特定するためのトランザクションＩＤとを、ＷｅｂＳｏｃｋｅｔプロトコルを使用して常時接続サーバ２００に送信する。

常時接続サーバ２００は、サービスＩＤに対応するアプリケーションサーバ３００Ｂに、当該データ本体とクライアント１００に対応する接続ＩＤとを送信する。アプリケーションサーバ３００Ｂは、データ本体を受信すると、接続ＩＤに対応づけて当該データ本体を記憶する。アプリケーションサーバ３００Ｂは、データ本体を受信した旨を示す結果通知を常時接続サーバ２００に送信する。常時接続サーバ２００は、結果通知に応じて、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、トランザクションＩＤと送信結果とをクライアント１００に送信する。
＜クライアントからの大容量の情報プッシュ時の動作概要＞

次に、クライアント１００からの大容量の情報プッシュ時の動作概要について説明する。図９は、本実施の形態にかかるネットワークシステム１におけるクライアント１００からの大容量の情報プッシュ時の動作概要を示すイメージ図である。

図９を参照して、クライアント１００は、送信すべきデータ本体が所定のデータ量よりも大きいか否かを判断する。当該データ本体が所定のデータ量よりも大きい場合、クライアント１００は、送信すべきアプリケーションサーバ３００を特定するためのサービスＩＤと、データ量と、今回のデータ送信を特定するためのトランザクションＩＤとを、ＷｅｂＳｏｃｋｅｔプロトコルを使用して常時接続サーバ２００に送信する。

常時接続サーバ２００は、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、クライアント１００に、トランザクションＩＤとデータのアップロード先とを通知する。クライアント１００は、ＨＴＴＰプロトコルを使用して、トランザクションＩＤに基づいてデータ本体をアップロード先にアップロードする。

常時接続サーバ２００は、アップロードが完了すると、サービスＩＤに対応するアプリケーションサーバ３００Ｂに、当該データ本体とクライアント１００に対応する接続ＩＤとを送信する。アプリケーションサーバ３００Ｂは、データ本体を受信すると、接続ＩＤに対応づけて当該データ本体を記憶する。アプリケーションサーバ３００Ｂは、データ本体を受信した旨を示す結果通知を常時接続サーバ２００に送信する。常時接続サーバ２００は、結果通知に応じて、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、トランザクションＩＤと送信結果とをクライアント１００に送信する。

上記の複数の動作概要に示した通り、本実施の形態にかかるネットワークシステム１では、クライアント１００に接続ＩＤが付与されるため、当該接続ＩＤに基づいて、アプリケーションサーバ３００からのデータを、選択された１つのクライアント１００にプッシュすることが可能となる。

また、本実施の形態にかかるネットワークシステム１では、クライアント１００とアプリケーションサーバ３００とか常時接続サーバ２００を介して常時接続されている。このため、ブラウザとしてのクライアントとサービスプログラムとしてのアプリケーションサーバとの組み合わせ毎にＷｅｂＳｏｃｋｅｔによる常時接続状態を確立する必要がない。よって、ネットワークシステム１にかかる負荷を従来よりも低減させることができる。

また、本実施の形態にかかるネットワークシステム１では、クライアント１００および常時接続サーバ２００が、送信されるデータの容量でプロトコルを切り替えるため、ＷｅｂＳｏｃｋｅｔプロトコルによる通信経路が一部のデータの送受信によって占有される可能性を低減することができる。すなわち、ＷｅｂＳｏｃｋｅｔプロトコルを利用した他のデータの送受信が行えなくなる可能性を低減することができる。

以下、このような機能を実現するためのネットワークシステム１の各部の具体的な構成について詳述する。
＜ネットワークシステム１＞

まず、本実施の形態にかかるネットワークシステム１全体の通信構成について説明する。図１０は、本実施の形態にかかるネットワークシステム１全体の通信構成を示すブロック図である。

図１０を参照して、クライアント１００は、ＨＴＴＰプロトコルを使用して常時接続サーバ２００およびアプリケーションサーバ３００と通信することができるし、ＷｅｂＳｏｃｋｅｔプロトコルを使用して常時接続サーバ２００と常時接続することもできる。より詳細には、クライアント１００は、後述するクライアントＡＰＰ１１０ＡとクライアントＡＰＩ１１０Ｂとを搭載する。クライアントＡＰＰ１１０Ａは、クライアント１００の各部を制御する。クライアントＡＰＩ１１０Ｂは、後述する通信インターフェイスを介して、ＨＴＴＰプロトコルを使用して通信したり、ＨＴＴＰプロトコル上で利用されるＷｅｂＳｏｃｋｅｔプロトコルを使用して通信したりする。

なお、本実施形態にかかる構成は、ＨＴＴＰ／ＷｅｂＳｏｃｋｅｔプロトコルの他に、ＳＳＬで通信路を暗号化できるＨＴＴＰＳ／ＷＳＳプロトコルでも利用可能である。すなわち、本実施形態にかかるネットワークシステム１は、ＨＴＴＰＳ／ＷＳＳプロトコルを利用するシステムにも適応できる。

常時接続サーバ２００は、ＷｅｂＳｏｃｋｅｔプロトコルを使用してクライアント１００との常時接続通信を制御するためのプログラムとしてのＷＳサーバ（すなわち、ソフトウェアとしての常時接続サーバ）２１０Ａを含む。常時接続サーバ２００は、他のプロトコルを使用して、他のデータベース４５０にもアクセスすることができる。なお、本実施の形態においては、常時接続サーバ２００は、ＨＴＴＰプロトコルを使用して、アプリケーションサーバ３００に任意のタイミングでデータを送信できる。

本実施の形態にかかるネットワークシステム１は、複数のアプリケーションサーバ３００Ａ，３００Ｂを含む。複数のアプリケーションサーバ３００Ａ，３００Ｂの各々は、クライアント１００やスマートフォン５００などにサービスを提供するプログラムとしてのサーバＡＰＰ（すなわち、ソフトウェアとしてのアプリケーションサーバ）３１０ＡとＨＴＴＰプロトコルを利用して常時接続サーバ２００と通信するためのサーバＡＰＩ３１０Ｂとを搭載する。

たとえば、ネットワークシステム１は、掃除機１００Ａを制御するためのアプリケーションサーバ３００Ａと、エアコン１００Ｂを制御するためのアプリケーションサーバ３００Ｂなどを含む。複数のアプリケーションサーバ３００Ａ，３００Ｂの各々は、ＨＴＴＰプロトコルを使用して、常時接続サーバ２００、他のデータベース、スマートフォン５００などと通信することができる。そして、本実施の形態においては、アプリケーションサーバ３００Ａ，３００Ｂは、ＨＴＴＰプロトコルを使用して、常時接続サーバ２００に任意のタイミングでデータを送信できる。
＜クライアント１００のハードウェア構成＞

次に、クライアント１００のハードウェア構成の一態様について説明する。図１１は、本実施の形態にかかるクライアント１００のハードウェア構成を表わすブロック図である。

図１１を参照して、クライアント１００は、主たる構成要素として、ＣＰＵ１１０と、メモリ１２０と、入出力部１３０と、家電制御回路１５０と、通信インターフェイス１６０とを含む。

ＣＰＵ１１０は、メモリ１２０あるいは外部の記憶媒体に記憶されているプログラムを実行することによって、クライアント１００の各部を制御する。より詳細には、ＣＰＵ１１０は、後述するＡＰＰデータに基づいてクライアントＡＰＰ１１０Ａ（図１６〜図２４を参照。）として動作するとともに、後述するＡＰＩデータに基づいてクライアントＡＰＩ１１０Ｂ（図１６〜図２４を参照。）として動作する。

メモリ１２０は、各種のＲＡＭ（Random Access Memory）、各種のＲＯＭ（Read-Only Memory）や、フラッシュメモリーなどによって実現される。なお、メモリ１２０は、インターフェイスを介して利用される、ＵＳＢ（Universal Serial Bus）（登録商標）メモリ、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk）、メモリカード、ハードディスク、ＩＣ（Integrated Circuit）カード、光カード、マスクＲＯＭ、ＥＰＲＯＭ（Erasable Programmable Read Only Memory）、ＥＥＰＲＯＭ（Electronically Erasable Programmable Read-Only Memory）などの記憶媒体などによっても実現される。

メモリ１２０は、ＣＰＵ１１０によって実行されるプログラムや、ＣＰＵ１１０によるプログラムの実行により生成されたデータ、入出力部１３０を介して入力されたデータ、掃除機またはエアコンなどのようなクライアントとして動作するＡＰＰ（Application software）データ、クライアントＡＰＰとデータをやり取りしながら常時接続サーバ２００と通信するためのＡＰＩ（Application Programming Interface）データを記憶する。具体的には、メモリ１２０は、常時接続サーバの接続先、アプリケーションサーバ接続先、サービス識別コード、サービス認証トークン、接続ＩＤ、クライアント識別ＩＤなどを記憶する。

入出力部１３０は、ユーザからの命令を受け付けて、当該命令をＣＰＵ１１０に入力する。また、入出力部１３０は、ＣＰＵ１１０からの信号に基づいて、文字や画像を出力する。

家電制御回路１５０は、ＣＰＵ１１０からの信号に基づいて、家電としてのクライアントの各部（モータなど）を制御する。

通信インターフェイス１６０は、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃなどの無線ＬＡＮ通信、ＺｉｇＢｅｅ(登録商標)、ＢｌｕｅＴｏｏｔｈ（登録商標）、あるいは、イーサネット（登録商標）などの有線ＬＡＮなどの通信モジュールによって実現される。通信インターフェイス１６０は、有線通信あるいは無線通信によって他の装置との間でデータをやり取りする。ＣＰＵ１１０は、通信インターフェイス１６０を介して、他の装置からプログラム、制御命令、画像データ、テキストデータなどを受信したり、他の装置にテキストデータ、画像データなどを送信したりする。
＜常時接続サーバ２００のハードウェア構成＞

次に、常時接続サーバ２００のハードウェア構成の一態様について説明する。図１２は、本実施の形態にかかる常時接続サーバ２００のハードウェア構成を表わすブロック図である。なお、常時接続サーバ２００は、apache、tomcat、mysqlなど、一般的なサーバモジュールで担保できる機能は標準的に利用可能である。

図１２を参照して、常時接続サーバ２００は、主たる構成要素として、ＣＰＵ２１０と、メモリ２２０と、入出力部２３０と、通信インターフェイス２６０とを含む。常時接続サーバ２００のハードウェア構成は、クライアント１００のハードウェア構成と比較して、家電の各部を制御するための家電制御回路１５０を有さない点、ＣＰＵ２１０の動作、メモリ２２０に格納されているデータに関して異なる。以下では、ＣＰＵ２１０の動作とメモリ２２０が記憶するデータとについて説明するものとし、その他のハードウェア構成については説明を繰り返さない。

ＣＰＵ２１０は、メモリ２２０あるいは外部の記憶媒体に記憶されているプログラムを実行することによって、常時接続サーバ２００の各部を制御する。具体的には、ＣＰＵ２１０は、メモリ２２０に記憶されているプログラムを実行することによって、ＷＳサーバ２１０Ａ（図１６〜図２４を参照。）として動作する。

メモリ２２０は、ＣＰＵ２１０によって実行されるプログラムや、ＣＰＵ２１０によるプログラムの実行により生成されたデータ、入出力部２３０を介して入力されたデータ、サービスＩＤ、サービス名、アプリケーションサーバ３００の接続先ＵＲＬ、サービス認証トークン生成情報、認証情報（ワンタイムキー）、接続ＩＤなどを記憶する。
＜アプリケーションサーバ３００のハードウェア構成＞

次に、アプリケーションサーバ３００のハードウェア構成の一態様について説明する。図１３は、本実施の形態にかかるアプリケーションサーバ３００のハードウェア構成を表わすブロック図である。なお、アプリケーションサーバ３００は、apache、tomcat、mysqlなど、一般的なサーバモジュールで担保できる機能は標準的に利用可能である。

図１３を参照して、アプリケーションサーバ３００は、主たる構成要素として、ＣＰＵ３１０と、メモリ３２０と、入出力部３３０と、通信インターフェイス３６０とを含む。アプリケーションサーバ３００のハードウェア構成は、クライアント１００のハードウェア構成と比較して、家電の各部を制御するための家電制御回路１５０を有さない点、ＣＰＵ３１０の動作、メモリ３２０に格納されているデータに関して異なる。よって、以下では、ＣＰＵ３１０の動作と、メモリ３２０が記憶するデータとについて説明するものとし、その他のハードウェア構成については説明を繰り返さない。

ＣＰＵ３１０は、メモリ３２０あるいは外部の記憶媒体に記憶されているプログラムを実行することによって、アプリケーションサーバ３００の各部を制御する。具体的には、ＣＰＵ３１０は、メモリ３２０に記憶されているプログラムを実行することによって、後述するＡＰＰデータに基づいてサーバＡＰＰ３１０Ａ（図１６〜図２４を参照。）として動作するとともに、後述するＡＰＩデータに基づいてサーバＡＰＩ３１０Ｂ（図１６〜図２４を参照。）として動作する。

メモリ３２０は、ＣＰＵ３１０によって実行されるプログラムや、ＣＰＵ３１０によるプログラムの実行により生成されたデータ、入出力部３３０を介して入力されたデータ、アプリケーションサーバ３００として動作するＡＰＰデータ、サーバＡＰＰとデータをやり取りしながら常時接続サーバ２００と通信するためのＡＰＩデータを記憶する。具体的には、メモリ３２０は、常時接続サーバのＵＲＬ、サービスＩＤとサービス認証トークン、認証情報（ワンタイムキー）生成情報、接続ＩＤなどを記憶する。
＜スマートフォン５００のハードウェア構成＞

次に、スマートフォン５００のハードウェア構成の一態様について説明する。図１４は、本実施の形態にかかるスマートフォン５００のハードウェア構成を表わすブロック図である。

図１４を参照して、スマートフォン５００は、主たる構成要素として、ＣＰＵ５１０と、メモリ５２０と、ボタン５３０と、ディスプレイ５４０と、通信インターフェイス５６０とを含む。スマートフォン５００のハードウェア構成は、クライアント１００のハードウェア構成と比較して、家電の各部を制御するための家電制御回路１５０を有さない点、ＣＰＵ５１０の動作、メモリ３２０に格納されているデータに関して異なる。よって、ここでは、ハードウェア構成の各部については説明を繰り返さない。なお、近年はボタン５３０とディスプレイ５４０の代わりにタッチパネルが利用されることが多い。
＜常時接続に関する装置間のデータのやり取り＞

次に、本実施の形態にかかるネットワークシステム１における常時接続に関する装置間のデータのやり取りの概要について説明する。なお、図１５は、本実施の形態にかかるネットワークシステム１における常時接続に関する装置間のデータのやり取りの処理手順を示すシーケンス図である。

図１５を参照して、クライアント１００は、ＨＴＴＰプロトコルを使用して、アプリケーションサーバ３００に認証情報を要求する（ステップＳ００２）。このとき、クライアント１００は、アプリケーションサーバ３００に、認証に利用されるクライアントＩＤを送信する。アプリケーションサーバ３００は、当該要求に応じてＨＴＴＰプロトコルを使用してクライアント１００に認証情報を送信する（ステップＳ００４）。

アプリケーションサーバ３００は、常時接続サーバ２００にも認証情報を送信する（ステップＳ００６）。常時接続サーバ２００は、アプリケーションサーバ３００から受信した認証情報を保存する（ステップＳ００８）。

クライアント１００と常時接続サーバ２００とは、ＨＴＴＰプロトコルを使用して、ＷｅｂＳｏｃｋｅｔを利用した常時接続状態を確立する（ステップＳ０１０、ステップＳ０１２）。具体的には、クライアント１００は、ＨＴＴＰプロトコルを使用して、常時接続サーバ２００にハンドシェイク要求を送る。常時接続サーバ２００は、ハンドシェイク応答を返す。これによって、クライアント１００と常時接続サーバ２００との間で、ＷｅｂＳｏｃｋｅｔプロトコルによる常時接続が有効になる。

クライアント１００は、認証情報を常時接続サーバ２００に送信する（ステップＳ０１４）。常時接続サーバ２００は、クライアント１００からの認証情報と予め保存している認証情報とに基づいて、クライアント１００を認証する（ステップＳ０１６）。認証に成功すると、常時接続サーバ２００は、アプリケーションサーバ３００がクライアント１００を識別するための接続ＩＤを発行する（ステップＳ０１８）。すなわち、常時接続サーバ２００は、常時接続中のクライアント１００と接続ＩＤとの対応関係を、接続状態管理情報として記憶する。クライアント１００は、接続ＩＤを受信して、記憶する（ステップＳ０２０）。アプリケーションサーバ３００も、接続ＩＤを受信して、記憶する（ステップＳ０２２）。

その後、アプリケーションサーバ３００は、必要に応じて、データ本体と送り先のクライアント１００を特定するための接続ＩＤとを常時接続サーバ２００に送信する（ステップＳ０３２）。常時接続サーバ２００は、アプリケーションサーバ３００からデータ本体と接続ＩＤとを受信する（ステップＳ０３４）。常時接続サーバ２００は、接続状態管理情報を参照して、接続ＩＤに基づいてクライアント１００を特定する（ステップＳ０３６）。

常時接続サーバ２００は、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、特定されたクライアント１００にデータ本体を送信する（ステップＳ０３８）。クライアント１００は、データ本体を受信する（ステップＳ０４０）。クライアント１００は、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、受信結果を常時接続サーバ２００に送信する（ステップＳ０４２）。常時接続サーバ２００は、受信結果を受信すると、当該受信結果をアプリケーションサーバ３００に送信する（ステップＳ０４４）。アプリケーションサーバ３００は、受信結果を受信する（ステップＳ０４６）。

以下では、本実施の形態にかかるネットワークシステム１における各処理手順についてより詳細に説明する。なお、上述したように、図１０と図１１を参照して、クライアントＡＰＰ１１０Ａは、クライアント１００のＣＰＵ１１０がプログラムを実行することによって実現されるものであって、クライアント１００としての動作を制御する。クライアントＡＰＩ１１０Ｂは、クライアント１００のＣＰＵ１１０がプログラムを実行することによって実現されるものであって、通信インターフェイス１６０を使用しながらＨＴＴＰプロトコルおよびＷｅｂＳｏｃｋｅｔプロトコルを使用して常時接続サーバ２００と通信する。

また、図１０と図１３を参照して、サーバＡＰＰ３１０Ａは、アプリケーションサーバ３００のＣＰＵ３１０がプログラムを実行することによって実現されるものであって、アプリケーションサービスプログラムとして動作する。サーバＡＰＩ３１０Ｂは、アプリケーションサーバ３００のＣＰＵ３１０がプログラムを実行することによって実現されるものであって、通信インターフェイス３６０を使用しながら常時接続サーバ２００と通信する。

また、図１０と図１２を参照して、ＷＳサーバ２１０Ａは、常時接続サーバ２００のＣＰＵ２１０がプログラムを実行することによって実現されるものである。ＷＳサーバ２１０Ａは、通信インターフェイス２６０を使用しながらＨＴＴＰプロトコルを使用してアプリケーションサーバ３００と通信する。さらに、本実施形態においては、ＷＳサーバ２１０Ａは、通信インターフェイス２６０を使用しながらＨＴＴＰプロトコルおよびＷｅｂＳｏｃｋｅｔプロトコルを使用してクライアント１００と通信する。
＜常時接続開始時の処理手順の詳細＞

次に、本実施の形態にかかるネットワークシステム１における常時接続開始時の処理手順の詳細について説明する。図１６は、本実施の形態にかかるネットワークシステム１における常時接続開始時の処理手順の詳細を示すシーケンス図である。

図１６を参照して、クライアントＡＰＰ１１０Ａは、アプリケーションサーバ３００との常時接続を開始するための要求を、クライアントＡＰＩ１１０Ｂに受け渡す（ステップＳ１０２）。このとき、クライアントＡＰＰ１１０Ａは、クライアントＡＰＩ１１０ＢにクライアントＩＤを受け渡す。

クライアントＡＰＩ１１０Ｂは、通信インターフェイス１６０を介してＨＴＴＰプロトコルを使用して、アプリケーションサーバ３００に、クライアントＩＤを送るとともに認証情報を要求する（ステップＳ１０４）。なお、クライアントＡＰＰまたはクライアントＡＰＩ１１０Ｂは、サービスの認証に必要な情報も引数として、アプリケーションサーバ３００に送信する（ステップＳ１０６）。

サーバＡＰＩ３１０Ｂは、クライアントＩＤと当該要求とを受信すると、認証情報を生成する（ステップＳ１０８）。サーバＡＰＩ３１０Ｂは、サーバＡＰＰ３１０Ａに接続開始を通知する（ステップＳ１１０）。サーバＡＰＩ３１０Ｂは、サーバＡＰＰ３１０Ａから接続を許可する返答を受け取ると（ステップＳ１１４）、通信インターフェイス３６０を介して常時接続サーバ２００に認証情報を送信する（ステップＳ１１６）。ＷＳサーバ２１０Ａは、認証情報をメモリ１２０に格納する（ステップＳ１１８）。サーバＡＰＩ３１０Ｂは、通信インターフェイス２６０を介して、認証情報をクライアント１００に送信する（ステップＳ１２０）。

クライアントＡＰＩ１１０Ｂは、通信インターフェイス１６０を介して、ＨＴＴＰプロトコルを使用して、常時接続サーバ２００にハンドシェイク要求を送信する（ステップＳ１２２）。ＷＳサーバ２１０Ａは、通信インターフェイス２６０を介して、ハンドシェイク応答をクライアント１００に返す（ステップＳ１２４）。これによって、クライアント１００と常時接続サーバ２００とのＷｅｂＳｏｃｋｅｔプロトコルによる常時接続が開始される。

クライアントＡＰＩ１１０Ｂは、通信インターフェイス１６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、常時接続サーバ２００に認証情報を送信する（ステップＳ１２６）。ＷＳサーバ２１０Ａは、先にアプリケーションサーバ３００から受信していた認証情報と今回クライアント１００から受信した認証情報とに基づいてクライアント１００を認証する（ステップＳ１２８）。

認証に成功すると、ＷＳサーバ２１０Ａは、接続ＩＤを発行する（ステップＳ１３０）。ＷＳサーバ２１０Ａは、通信インターフェイス２６０を介して、接続確立状況としてクライアント１００の接続ＩＤをアプリケーションサーバ３００に送信する（ステップＳ１３２）。サーバＡＰＩ３１０Ｂは、接続ＩＤをメモリ３２０に記憶する（ステップＳ１３４）。サーバＡＰＩ３１０Ｂは、接続確立状況をサーバＡＰＰ３１０Ａに通知する（ステップＳ１３６）。サーバＡＰＩ３１０Ｂは、認証情報を削除する（ステップＳ１３８）。

ＷＳサーバ２１０Ａは、通信インターフェイス２６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、認証要求の応答として接続ＩＤをクライアント１００に返信する（ステップＳ１４４）。クライアントＡＰＩ１１０Ｂは、接続ＩＤを記憶する。

クライアントＡＰＩ１１０Ｂは、通信インターフェイス１６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、接続確認を要求する（ステップＳ１４６）。ＷＳサーバ２１０Ａは、当該要求を受信すると、通信インターフェイス２６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、接続確認に対して応答する（ステップＳ１４８）。クライアントＡＰＩ１１０Ｂは、当該応答に応じて、クライアントＡＰＰ１００Ａに常時接続が開始された旨を通知する（ステップＳ１５０）。
＜クライアントからの常時接続切断時の処理手順の詳細＞

次に、本実施の形態にかかるネットワークシステム１におけるクライアントからの常時接続切断時の処理手順の詳細について説明する。図１７は、本実施の形態にかかるネットワークシステム１におけるクライアントからの常時接続切断時の処理手順の詳細をシーケンス図である。

図１７を参照して、クライアントＡＰＰ１１０Ａは、アプリケーションサーバ３００との常時接続を切断するための要求を、クライアントＡＰＩ１１０Ｂに受け渡す（ステップＳ２０２）。このとき、クライアント１００は、クライアントＡＰＩ１１０Ｂに接続ＩＤも受け渡す。

クライアントＡＰＩ１１０Ｂは、通信インターフェイス１６０を介してＷｅｂＳｏｃｋｅｔプロトコルを使用して、常時接続サーバ２００に、常時接続の切断を要求する（ステップＳ２０４）。ＷＳサーバ２１０Ａは、通信インターフェイス２６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、常時接続の切断を了解する（ステップＳ２０６）。

クライアントＡＰＩ１１０Ｂは、常時接続サーバ２００との常時接続を終了し、常時接続サーバ２００とのＴＣＰの通信も終了する（ステップＳ２０８）。クライアントＡＰＩ１１０Ｂは、常時接続を終了した旨をクライアントＡＰＰ１００Ａに通知する（ステップＳ２１０）。

ＷＳサーバ２１０Ａは、クライアント１００との常時接続を終了し、クライアント１００とのＴＣＰの通信も終了する（ステップＳ２１２）。ＷＳサーバ２１０Ａは、通信インターフェイス２６０を介して、アプリケーションサーバ３００に常時接続を切断した旨を通知する（ステップＳ２１４）。

サーバＡＰＩ３１０Ｂは、当該通知を受けてサーバＡＰＰ３１０Ａにクライアント１００との常時接続が終了した旨を通知する（ステップＳ２１８）。具体的には、サーバＡＰＩ３１０Ｂは、常時接続が終了したクライアント１００に対応する接続ＩＤをサーバＡＰＰ３１０Ａに受け渡す。
＜アプリケーションサーバからの常時接続切断時の処理手順の詳細＞

次に、本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からの常時接続切断時の処理手順の詳細について説明する。なお、アプリケーションサーバ３００は、プログラムのバージョンアップをする時およびトラブルに対するメンテナンス時などに、クライアント１００との常時接続を切断する場合がある。図１８は、本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からの常時接続切断時の処理手順の詳細をシーケンス図である。

図１８を参照して、サーバＡＰＰ３１０Ａは、クライアント１００との常時接続を切断するための要求を、サーバＡＰＩ３１０Ｂに受け渡す（ステップＳ３０２）。このとき、サーバＡＰＰ３１０Ａは、サーバＡＰＩ３１０Ｂに対象となるクライアント１００の接続ＩＤも受け渡す。

サーバＡＰＩ３１０Ｂは、通信インターフェイス３６０を介して、常時接続サーバ２００に、クライアント１００との常時接続の切断を要求する（ステップＳ３０４）。ＷＳサーバ２１０Ａは、通信インターフェイス２６０を介して、常時接続の切断を了解する。サーバＡＰＩ３１０Ｂは、クライアント１００との常時接続が終了した旨をサーバＡＰＰ３１０Ａに通知する（ステップＳ３０６）。

ＷＳサーバ２１０Ａは、通信インターフェイス２６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、クライアント１００に常時接続の切断を要求する（ステップＳ３１０）。クライアントＡＰＩ１１０Ｂは、当該要求に応じて、クライアントＡＰＰ１００Ａに常時接続の切断を通知する（ステップＳ３１２）。クライアントＡＰＩ１１０Ｂは、常時接続サーバ２００との常時接続を終了し、常時接続サーバ２００とのＴＣＰの通信も終了する（ステップＳ３１６）。

ＷＳサーバ２１０Ａは、クライアント１００との常時接続を終了し、クライアント１００とのＴＣＰの通信も終了する（ステップＳ３１８）。ＷＳサーバ２１０Ａは、通信インターフェイス２６０を介して、クライアント１００との常時接続の切断が完了した旨を通知する（ステップＳ３２０）。

サーバＡＰＩ３１０Ｂは、当該通知に基づいて、メモリ３２０に記憶されている接続状態管理情報からクライアント１００の接続ＩＤを削除する（ステップＳ３２２）。サーバＡＰＩ３１０Ｂは、切断処理が完了した旨をサーバＡＰＰ３１０Ａに通知する（ステップＳ３２４）。
＜クライアントからの接続確認時の処理手順の詳細＞

次に、本実施の形態にかかるネットワークシステム１におけるクライアント１００からの接続確認時の処理手順の詳細について説明する。なお、クライアント１００は、一定期間常時接続によるデータの受信を行わなかった場合およびユーザから常時接続機能をＯＦＦする指示を受け付けた場合などに、アプリケーションサーバ３００との常時接続を切断する場合がある。図１９は、本実施の形態にかかるネットワークシステム１におけるクライアント１００からの接続確認時の処理手順の詳細をシーケンス図である。

図１９を参照して、クライアントＡＰＰ１００Ａは、クライアントＡＰＩ１１０Ｂに、常時接続サーバ２００との接続確認を要求する（ステップＳ４０２）。クライアントＡＰＩ１１０Ｂは、通信インターフェイス１６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、常時接続サーバ２００に接続確認要求（ping）を送信する（ステップＳ４０４）。

ＷＳサーバ２１０Ａは、接続確認要求（ping）と受信すると、通信インターフェイス２６０を介してクライアント１００に接続確認応答（pong）送信する（ステップＳ４０６）。クライアントＡＰＩ１１０Ｂは、接続状態の判定結果をクライアントＡＰＰ１００Ａに通知する（ステップＳ４０８）。

なお、常時接続サーバ２００から接続確認応答（pong）が返信されてこない場合は、クライアントＡＰＩ１１０Ｂは、自動再接続フラグを確認し、常時接続を要求するための処理を呼び出す（ステップＳ４１２）。その後、ネットワークシステム１は、常時接続を開始するときと同じ処理を実行する（図１５および図１６を参照。）。
＜アプリケーションサーバからの接続確認時の処理手順の詳細＞

次に、本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からの接続確認時の処理手順の詳細について説明する。図２０は、本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からの接続確認時の処理手順の詳細をシーケンス図である。

図２０を参照して、サーバＡＰＰ３１０Ａは、サーバＡＰＩ３１０Ｂに、常時接続サーバ２００とクライアント１００との接続確認を要求する（ステップＳ５０２）。サーバＡＰＩ３１０Ｂは、通信インターフェイス３６０を介して、常時接続サーバ２００にクライアント１００との接続確認を要求する（ステップＳ５０４）。

ＷＳサーバ２１０Ａは、通信インターフェイス２６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、クライアント１００に接続確認要求（ping）を送信する（ステップＳ５０６）。クライアントＡＰＩ１１０Ｂは、接続確認要求（ping）と受信すると、通信インターフェイス２６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して常時接続サーバ２００に接続確認応答（pong）送信する（ステップＳ５０８）。

ＷＳサーバ２１０Ａは、接続確認応答（pong）を受信すると、接続状態情報を作成する（ステップＳ５１０）。ＷＳサーバ２１０Ａは、通信インターフェイス２６０を介して、接続状態情報をアプリケーションサーバ３００に送信する（ステップＳ５１２）。サーバＡＰＩ３１０Ｂは、接続状態情報をサーバＡＰＰ３１０Ａに受け渡す（ステップＳ５１４）。
＜アプリケーションサーバからの通常のデータプッシュ時の処理手順の詳細＞

次に、本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からのデータプッシュ時の処理手順の詳細について説明する。より詳細には、以下では、本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からの通常の（小容量の）データプッシュ時の処理手順の詳細と大容量のデータプッシュ時の処理手順の詳細とに分けて説明する。

なお、アプリケーションサーバ３００から送信される小容量のデータの例としては、コマンドなどのテキストファイル、小さいサイズの画像/音声/動画ファイル(再生すべきコンテンツで、容量の小さいもの)などが挙げられる。一方、アプリケーションサーバ３００から送信される大容量のデータの例としては、大きいサイズの画像/音声/動画ファイルなどが挙げられる。

まずは、本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からのデータプッシュ時の処理手順の詳細について説明する。図２１は、本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からの通常のデータプッシュ時の処理手順の詳細をシーケンス図である。

図２１を参照して、サーバＡＰＰ３１０Ａは、サーバＡＰＩ３１０Ｂに、データプッシュを要求する（ステップＳ６０２）。具体的には、サーバＡＰＰ３１０Ａは、サーバＡＰＩ３１０Ｂに、クライアント１００を特定するための接続ＩＤと、データ本体と、アプリケーションを特定するためのデータとを受け渡す。サーバＡＰＩ３１０Ｂは、トランザクションＩＤを発行する（ステップＳ６０４）。

サーバＡＰＩ３１０Ｂは、ＷＳデータ構造を判定する（ステップＳ６０６）。図２５は、本実施形態にかかるＷＳデータの構造を示すイメージ図である。図２５に示すように、ＷＳデータ１０００は、たとえば、type"sendbin_"(8bytes)、トランザクションＩＤ、データレングス、データ名、アプリ定義データレングス、アプリ定義データ、データレングス、データ本体などを含む。本実施の形態においては、サーバＡＰＩ３１０Ｂは、データ本体の容量が所定値より大きいか否かを判断する。あるいは、サーバＡＰＩ３１０Ｂは、クライアント１００に送信すべきデータ全体の容量が、所定値より大きいか否かを判断する。ここでは、データ量が所定値以下である場合について説明する。

サーバＡＰＩ３１０Ｂは、常時接続サーバ２００にデータプッシュを要求する（ステップＳ６０８）。具体的には、サーバＡＰＩ３１０Ｂは、通信インターフェイス３６０を介して常時接続サーバ２００に、接続ＩＤと、トランザクションＩＤと、ＷＳデータ種別と、データ本体と、アプリケーションを特定するためのデータとを送信する。

ＷＳサーバ２１０Ａは、アプリケーションサーバ３００からのデータを受信して、当該データをＷｅｂＳｏｃｋｅｔプロトコルに対応したデータに構成しなおす（ステップＳ６１０）。ＷＳサーバ２１０Ａは、通信インターフェイス２６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、接続ＩＤと、トランザクションＩＤと、ＷＳデータ種別と、データ本体と、アプリケーションを特定するためのデータとをクライアント１００に送信する（ステップＳ６１２）。

クライアントＡＰＩ１１０Ｂは、通信インターフェイス１６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、常時接続サーバ２００からデータを受信する。クライアントＡＰＩ１１０Ｂは、受信したＷＳデータを解析する（ステップＳ６１４）。クライアントＡＰＩ１１０Ｂは、受信したデータをクライアントＡＰＰ１００Ａに受け渡す（ステップＳ６１６）。

クライアントＡＰＩ１１０Ｂは、通信インターフェイス１６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、トランザクションＩＤを含むデータを送信することによって、データ本体がクライアント１００に届いた旨を常時接続サーバ２００に通知する。ＷＳサーバ２１０Ａは、通信インターフェイス２６０を介して、トランザクションＩＤを含むデータを送信することによって、データ本体がクライアント１００に届いた旨をアプリケーションサーバ３００に通知する（ステップＳ６２０）。
＜アプリケーションサーバからの大容量のデータプッシュ時の処理手順の詳細＞

次に、本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からの大容量のデータプッシュ時の処理手順の詳細について説明する。図２２は、本実施の形態にかかるネットワークシステム１におけるアプリケーションサーバ３００からの大容量のデータプッシュ時の処理手順の詳細をシーケンス図である。

図２２を参照して、サーバＡＰＰ３１０Ａは、サーバＡＰＩ３１０Ｂに、データプッシュを要求する（ステップＳ７０２）。具体的には、サーバＡＰＰ３１０Ａは、サーバＡＰＩ３１０Ｂに、クライアント１００を特定するための接続ＩＤと、データ本体と、アプリケーションを特定するためのデータとを受け渡す。サーバＡＰＩ３１０Ｂは、トランザクションＩＤを発行する（ステップＳ７０４）。

サーバＡＰＩ３１０Ｂは、ＷＳデータ構造を判定する（ステップＳ７０６）。本実施の形態においては、サーバＡＰＩ３１０Ｂは、データ本体の容量が所定値より大きいか否かを判断する。あるいは、サーバＡＰＩ３１０Ｂは、クライアント１００に送信すべきデータ全体の容量が、所定値より大きいか否かを判断する。ここでは、データ量が所定値より大きい場合について説明する。

サーバＡＰＩ３１０Ｂは、常時接続サーバ２００にデータプッシュを要求する（ステップＳ７０８）。具体的には、サーバＡＰＩ３１０Ｂは、通信インターフェイス３６０を介して常時接続サーバ２００に、接続ＩＤと、トランザクションＩＤと、ＵＲＬ情報と、ＷＳデータ種別と、アプリケーションを特定するためのデータと、結果通知フラグとを送信する。このとき、サーバＡＰＩ３１０Ｂは、サーバＡＰＰ３１０ＡにもトランザクションＩＤを受け渡す（ステップＳ７１０）。

ＷＳサーバ２１０Ａは、アプリケーションサーバ３００からのデータを受信して、当該データをＷｅｂＳｏｃｋｅｔプロトコルに対応したデータに構成しなおす（ステップＳ７１２）。ＷＳサーバ２１０Ａは、通信インターフェイス２６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、接続ＩＤと、トランザクションＩＤと、ＵＲＬ情報と、ＷＳデータ種別と、アプリケーションを特定するためのデータと、結果通知フラグとをクライアント１００に送信する（ステップＳ７１４）。

クライアントＡＰＩ１１０Ｂは、通信インターフェイス１６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、常時接続サーバ２００からデータを受信する。クライアントＡＰＩ１１０Ｂは、受信したデータを解析する（ステップＳ７１６）。

クライアントＡＰＩ１１０Ｂは、通信インターフェイス１６０を介して、ＨＴＴＰプロトコルを使用して、受信したＵＲＬ情報とトランザクションＩＤに基づいてアプリケーションサーバ３００にデータを要求する(ステップＳ７１８)。サーバＡＰＩ３１０Ｂは、当該要求に応じて、クライアント１００に送信すべきデータを組み立てる(ステップＳ７２０)。サーバＡＰＩ３１０Ｂは、通信インターフェイス３６０を介して、ＨＴＴＰプロトコルを使用して、データ本体をクライアント１００に送信する(ステップＳ７２２)。すなわち、クライアントＡＰＩ１１０Ｂは、通信インターフェイス２６０を介して、ＨＴＴＰプロトコルを使用して、ＵＲＬが示すアプリケーションサーバ３００の格納場所からデータをダウンロードする。

クライアントＡＰＩ１１０Ｂは、受信したデータを解析する(ステップＳ７２４)。クライアントＡＰＩ１１０Ｂは、受信したデータをクライアントＡＰＰ１００Ａに受け渡す（ステップＳ７２６）。クライアントＡＰＩ１１０Ｂは、結果通知フラグを確認する(ステップＳ７２８)。

クライアントＡＰＩ１１０Ｂは、通信インターフェイス１６０を介して、ＨＴＴＰプロトコルを使用して、アプリケーションサーバ３００にクライアントにデータが届いた旨を通知する（ステップＳ７３２）。具体的には、クライアントＡＰＩ１１０Ｂは、トランザクションＩＤとデータプッシュ結果ステータスとをアプリケーションサーバ３００に送信する。ＷＳサーバ２１０Ａは、トランザクションＩＤとデータプッシュ結果ステータスとをサーバＡＰＰ３１０Ａに受け渡す(ステップＳ７３４)。

なお、ここでは、図２１および図２２を参照して、アプリケーションサーバ３００がデータの大きさを判断する構成について説明したが、図６および図７に示したように、常時接続サーバ２００が当該判断を行う構成であってもよい。

また、ここでは、図２２を参照して、クライアント１００が大容量のデータをアプリケーションサーバ３００からダウンロードする構成について説明したが、図７に示したように、クライアント１００は当該データを常時接続サーバ２００からダウンロードしても良い。つまり、先に、アプリケーションサーバ３００が常時接続サーバ２００にデータを送信し、その後にクライアント１００から常時接続サーバ２００からデータをダウンロードする構成であってもよい。
＜クライアントからの通常のデータプッシュ時の処理手順の詳細＞

次に、本実施の形態にかかるネットワークシステム１におけるクライアント１００からのデータプッシュ時の処理手順の詳細について説明する。より詳細には、以下では、本実施の形態にかかるネットワークシステム１におけるクライアント１００からの通常の（小容量の）データプッシュ時の処理手順の詳細と大容量のデータプッシュ時の処理手順の詳細とに分けて説明する。

なお、クライアント１００から送信される小容量のデータの例としては、日時ログなどのテキストファイル、小さいサイズの画像/音声/動画ファイル(カメラ画像とか、音声認識に利用する音声とか)などが挙げられる。一方、アプリケーションサーバ３００から送信される大容量のデータの例としては、数日間以上の大量ログなどのテキストファイル、大きいサイズの画像/音声/動画ファイルなどが挙げられる。

まずは、本実施の形態にかかるネットワークシステム１におけるクライアント１００からの通常のデータプッシュ時の処理手順の詳細について説明する。図２３は、本実施の形態にかかるネットワークシステム１におけるクライアント１００からの通常のデータプッシュ時の処理手順の詳細をシーケンス図である。

図２３を参照して、クライアントＡＰＰ１１０Ａは、クライアントＡＰＩ１１０Ｂに、データプッシュを要求する（ステップＳ８０２）。具体的には、クライアントＡＰＰ１１０Ａは、クライアントＡＰＩ１１０Ｂに、自身を特定するための接続ＩＤと、データ本体と、アプリケーションを特定するためのデータとを受け渡す。サーバＡＰＩ３１０Ｂは、トランザクションＩＤを発行する（ステップＳ８０４）。

クライアントＡＰＩ１１０Ｂは、ＷＳデータ構造を判定する（ステップＳ８０６）。本実施の形態においては、クライアントＡＰＩ１１０Ｂは、データ本体の容量が所定値より大きいか否かを判断する。あるいは、クライアントＡＰＩ１１０Ｂは、常時接続サーバ２００に送信すべきデータ全体の容量が、所定値より大きいか否かを判断する。ここでは、データ量が所定値以下である場合について説明する。

クライアントＡＰＩ１１０Ｂは、接続ＩＤと、トランザクションＩＤと、ＷＳデータ種別と、データ本体と、アプリケーションを特定するためのデータと含むＷＳデータをＷｅｂＳｏｃｋｅｔプロトコルに対応したデータに構成しなおす（ステップＳ８０８）。クライアントＡＰＩ１１０Ｂは、通信インターフェイス１６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、組み立てたＷＳデータを常時接続サーバ２００に送信する(ステップＳ８１０)。

ＷＳサーバ２１０Ａは、ＷＳデータから接続ＩＤを取得する(ステップＳ８１２)。ＷＳサーバ２１０Ａは、受信したＷＳデータを解析する(ステップＳ８１４)。ＷＳサーバ２１０Ａは、通信インターフェイス２６０を介して、クライアント１００からのデータを送信する(ステップＳ８１６)。より詳細には、ＷＳサーバ２１０Ａは、通信インターフェイス１６０を介して、ＨＴＴＰプロトコルを利用して、クライアント１００の接続ＩＤと、データ本体と、アプリケーションを特定するためのデータとをアプリケーションサーバ３００に送信する。

サーバＡＰＩ３１０Ｂは、受信したデータをサーバＡＰＰ３１０Ａに受け渡す（ステップＳ８１８）。サーバＡＰＩ３１０Ｂは、通信インターフェイス３６０を介して、トランザクションＩＤを含むデータを送信することによって、データ本体がアプリケーションサーバ３００に届いた旨を常時接続サーバ２００に通知する（ステップＳ８２２）。ＷＳサーバ２１０Ａは、通信インターフェイス３６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、トランザクションＩＤを含むデータを送信することによって、データ本体がアプリケーションサーバ３００に届いた旨を通知する。
＜クライアントからの大容量のデータプッシュ時の処理手順の詳細＞

次に、本実施の形態にかかるネットワークシステム１におけるクライアント１００からの大容量のデータプッシュ時の処理手順の詳細について説明する。図２４は、本実施の形態にかかるネットワークシステム１におけるクライアント１００からの大容量のデータプッシュ時の処理手順の詳細をシーケンス図である。

図２４を参照して、クライアントＡＰＰ１１０Ａは、クライアントＡＰＩ１１０Ｂに、データプッシュを要求する（ステップＳ９０２）。具体的には、クライアントＡＰＰ１１０Ａは、クライアントＡＰＩ１１０Ｂに、クライアント１００を特定するための接続ＩＤと、データ本体と、アプリケーションを特定するためのデータとを受け渡す。クライアントＡＰＩ１１０Ｂは、トランザクションＩＤを発行する（ステップＳ９０４）。

クライアントＡＰＩ１１０Ｂは、ＷＳデータ構造を判定する（ステップＳ９０６）。本実施の形態においては、クライアントＡＰＩ１１０Ｂは、データ本体の容量が所定値より大きいか否かを判断する。あるいは、クライアントＡＰＩ１１０Ｂは、常時接続サーバ２００に送信すべきデータ全体の容量が、所定値より大きいか否かを判断する。ここでは、データ量が所定値より大きい場合について説明する。

クライアントＡＰＩ１１０Ｂは、接続ＩＤと、トランザクションＩＤと、ＷＳデータ種別と、アプリケーションを特定するためのデータと、データの容量とを含むＷＳデータをＷｅｂＳｏｃｋｅｔプロトコルに対応したデータに構成しなおす（ステップＳ９０８）。クライアントＡＰＩ１１０Ｂは、通信インターフェイス１６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、組み立てたＷＳデータを常時接続サーバ２００に送信する(ステップＳ９１０)。

ＷＳサーバ２１０Ａは、ＷＳサーバ２１０Ａは、受信したＷＳデータから接続ＩＤを取得する(ステップＳ９１２)。ＷＳサーバ２１０Ａは、受信したＷＳデータを解析する(ステップＳ９１４)。ＷＳサーバ２１０Ａは、通信インターフェイス２６０を介して、データ本体の送信先のＵＲＬをアプリケーションサーバ３００に要求する(ステップＳ９１６)。具体的には、ＷＳサーバ２１０Ａは、通信インターフェイス２６０を介して、接続ＩＤと、アプリ定義データと、トランザクションＩＤとをアプリケーションサーバ３００に送信する。

サーバＡＰＩ３１０Ｂは、常時接続サーバ２００からの要求に応じて、アップロード用のＵＲＬを発行する(ステップＳ９１８)。サーバＡＰＩ３１０Ｂは、通信インターフェイス３６０を介して、常時接続サーバ２００にクライアント１００へのデータプッシュを要求する(ステップＳ９２０)。具体的には、サーバＡＰＩ３１０Ｂは、通信インターフェイス３６０を介して、ＨＴＴＰプロトコルを利用して、接続ＩＤと、トランザクションＩＤと、送信先ＵＲＬと、ＷＳデータ種別と、アプリケーションを特定するための情報とを常時接続サーバ２００に送信する。

ＷＳサーバ２１０Ａは、アプリケーションサーバ３００から受信した情報に基づいて、ＷｅｂＳｏｃｋｅｔプロトコルに対応したデータを組み立てる(ステップＳ９２２)。ＷＳサーバ２１０Ａは、通信インターフェイス２６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、ＷＳデータをクライアント１００に送信する(ステップＳ９２４)。

クライアントＡＰＩ１１０Ｂは、ＷＳデータを解析する(ステップＳ９２６)。クライアントＡＰＩ１１０Ｂは、データ本体に基づいて送信用（アップロード用）のデータを組み立てる(ステップＳ９２８)。クライアントＡＰＩ１１０Ｂは、ＵＲＬ情報に基づいて、通信インターフェイス１６０を介して、ＨＴＴＰプロトコルを使用して、アプリケーションサーバ３００にデータ本体とトランザクションＩＤとをアップロードする(ステップＳ９３０)。

サーバＡＰＩ３１０Ｂは、受信したデータを解析する(ステップＳ９３２)。サーバＡＰＩ３１０Ｂは、トランザクションＩＤとデータ本体とを取得する(ステップＳ９３４)。サーバＡＰＩ３１０Ｂは、接続ＩＤと、データ本体と、アプリケーションを特定するための情報とをサーバＡＰＰ３１０Ａに受け渡す(ステップＳ９３６)。

サーバＡＰＩ３１０Ｂは、通信インターフェイス３６０を介して、トランザクションＩＤを含むデータを送信することによって、データ本体がアプリケーションサーバ３００に届いた旨を常時接続サーバ２００に通知する。ＷＳサーバ２１０Ａは、通信インターフェイス２６０を介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、トランザクションＩＤを含むデータを送信することによって、データ本体がアプリケーションサーバ３００に届いた旨を通知する（ステップＳ９４０）。

なお、ここでは、図２４を参照して、クライアント１００が大容量のデータをアプリケーションサーバ３００にアップロードする構成について説明したが、図９に示したように、クライアント１００は当該データを常時接続サーバ２００にアップロードしても良い。そして、常時接続サーバ２００が、アプリケーションサーバ３００にデータを送信しても良い。

以上、ネットワークシステム１における各種の詳細な処理手順を説明した。本実施の形態にかかるネットワークシステム１では、接続ＩＤに基づいて、アプリケーションサーバ３００からのデータを、選択された１つのクライアント１００にプッシュすることが可能となる。また、常時接続サーバ２００を介して、クライアント１００とアプリケーションサーバ３００とがデータをプッシュし合うので、ネットワークシステムにかかる負荷を従来よりも低減させることができる。さらに、送信されるデータの容量でプロトコルを切り替えるため、一部のデータ送受信によってＷｅｂＳｏｃｋｅｔプロトコルを使用する通信が占有される可能性を低減し、ＷｅｂＳｏｃｋｅｔプロトコルを使用する他のデータの送受信が行えなくなる可能性を低減することができる。
＜第２の実施の形態＞

次に、第２の実施の形態について説明する。上述の第１の実施の形態にかかるネットワークシステム１では、クライアント１００および常時接続サーバ２００の少なくともいずれかが、通常のＨＴＴＰプロトコルとＷｅｂＳｏｃｋｅｔプロトコルとを使い分けていた。より詳細には、クライアント１００および常時接続サーバ２００の少なくともいずれかが、送信されるデータの容量が所定値よりも大きい場合には、ＨＴＴＰプロトコルを使用してデータを送受信し、送信されるデータの容量が所定値以下である場合には、ＷｅｂＳｏｃｋｅｔプロトコルを使用してデータを送受信するものであった。

しかしながら、本実施の形態においては、データの容量ではなく、通信速度に基づいて適切なプロトコルを判断するものである。なお、アプリケーションサーバ３００から送信されるデータのうちで早い通信速度を必要とするものは、たとえば、即時にコマンドを発行する必要のあるコマンドデータ（エアコン電源ＯＮ／ＯＦＦなど）、即時に再生が必要な画像/音声/動画ファイル（緊急なメッセージ例えば緊急地震速報など）などが挙げられる。一方、クライアント１００から送信されるデータのうちで早い通信速度が必要とされる場合としては、たとえば、画像や音声などを即時に端末(スマートフォン)側などで再生する必要がある場合などが挙げられる。

以下、詳細に説明する。まず、図２１のステップＳ６０６および図２２のステップＳ７０６において、本実施の形態においては、サーバＡＰＩ３１０Ｂは、現在のＷｅｂＳｏｃｋｅｔプロトコルに係る通信速度が所定値より遅いか否かを判断する。あるいは、サーバＡＰＩ３１０Ｂは、対象となるデータをＷｅｂＳｏｃｋｅｔプロトコルで送信した場合における通信速度が所定値より遅いか否かを判断する。

具体的には、サーバＡＰＩ３１０Ｂは、通信インターフェイス３６０を介して、クライアント１００に速度確認用の信号（ping）を送信し、応答信号（pong）が返ってくるまでの時間を計測することによって、通信速度を計算することができる。あるいは、サーバＡＰＩ３１０Ｂは、ＷＳサーバ２１０Ａに、同様の方法で通信速度を計算させても良い。

なお、ステップＳ６０８以降は、通信速度が所定値以上場合についての説明である。ステップＳ７０８以降は、通信速度が所定値より遅い場合についての説明である。

同様に、図２３のステップＳ８０６および図２４のステップＳ９０６において、本実施の形態においては、クライアントＡＰＩ１１０Ｂは、現在のＷｅｂＳｏｃｋｅｔプロトコルに係る通信速度が所定値より遅いか否かを判断する。あるいは、クライアントＡＰＩ１１０Ｂは、対象となるデータをＷｅｂＳｏｃｋｅｔプロトコルで送信した場合における通信速度が所定値より遅いか否かを判断する。

なお、ステップＳ８０８以降は、通信速度が所定値以上である場合についての説明である。ステップＳ９０８以降は、通信速度が所定値より遅い場合についての説明である。

ここでは、アプリケーションサーバ３００が上記の判断する構成について説明したが、図６および図７と同様に、常時接続サーバ２００が当該判断を行う構成であってもよい。
＜第３の実施の形態＞

さらに、プロトコルの選択方法に関して、第３の実施の形態について説明する。本実施の形態においては、送信時間に基づいて適切なプロトコルを判断するものである。以下、詳細に説明する。

まず、図２１のステップＳ６０６および図２２のステップＳ７０６において、本実施の形態においては、サーバＡＰＩ３１０Ｂは、対象となるデータをＷｅｂＳｏｃｋｅｔプロトコルで送信した場合における送信時間が所定値より長いか否かを判断する。ステップＳ６０８以降は、送信時間が所定値以下である場合についての説明である。ステップＳ７０８以降は、送信時間が所定値より長い場合についての説明である。

同様に、図２３のステップＳ８０６および図２４のステップＳ９０６において、本実施の形態においては、クライアントＡＰＩ１１０Ｂは、対象となるデータをＷｅｂＳｏｃｋｅｔプロトコルで送信した場合における送信時間が所定値より長いか否かを判断する。ステップＳ８０８以降は、送信時間が所定値以下である場合についての説明である。ステップＳ９０８以降は、送信時間が所定値より長い場合についての説明である。

ここでは、アプリケーションサーバ３００が上記の判断する構成について説明したが、図６および図７と同様に、常時接続サーバ２００が当該判断を行う構成であってもよい。
＜第４の実施の形態＞

さらに、プロトコルの選択方法に関して、第４の実施の形態について説明する。本実施の形態においては、ＷｅｂＳｏｃｋｅｔプロトコルに基づくデータの送受信の頻度に基づいて適切なプロトコルを判断するものである。なお、アプリケーションサーバ３００から送信されるデータのうちで送受信の頻度が高いものとしては、たとえば、生死確認用のデータなどが挙げられる。一方、クライアント１００から送信されるデータのうちで送受信の頻度が高いものとしては、たとえば、生死確認用のデータおよびログアップデータなどが挙げられる。

以下、詳細に説明する。まず、図２１のステップＳ６０６および図２２のステップＳ７０６において、本実施の形態においては、サーバＡＰＩ３１０Ｂは、ＷｅｂＳｏｃｋｅｔプロトコルを使用したデータの送受信の頻度が所定値よりも多いか否かを判断する。たとえば、サーバＡＰＩ３１０Ｂは、常時接続サーバ２００とクライアント１００との間で、１分当たりのＷｅｂＳｏｃｋｅｔプロトコルを使用したデータの送受信の回数を計測する。あるいは、サーバＡＰＩ３１０Ｂは、常時接続サーバ２００とクライアント１００との間で、１分当たりのＷｅｂＳｏｃｋｅｔプロトコルを使用したデータの送受信の回数をＷＳサーバ２１０Ａから取得する。ステップＳ６０８以降は、当該回数が所定値以下である場合についての説明である。ステップＳ７０８以降は、当該回数が所定値より多い場合についての説明である。

同様に、図２３のステップＳ８０６および図２４のステップＳ９０６において、本実施の形態においては、クライアントＡＰＩ１１０Ｂは、ＷｅｂＳｏｃｋｅｔプロトコルを使用したデータの送受信の頻度が所定値よりも多いか否かを判断する。たとえば、クライアント１００は、常時接続サーバ２００とクライアント１００との間で、１分当たりのＷｅｂＳｏｃｋｅｔプロトコルを使用したデータの送受信の回数を計測する。クライアント１００は、当該回数が所定値より多いか否かを判断する。ステップＳ８０８以降は、当該回数が所定値以下である場合についての説明である。ステップＳ９０８以降は、当該回数が所定値より多い場合についての説明である。

ここでは、アプリケーションサーバ３００が上記の判断する構成について説明したが、図６および図７と同様に、常時接続サーバ２００が当該判断を行う構成であってもよい。
＜第５の実施の形態＞

次に、第５の実施の形態について説明する。上述の第１から第４の実施の形態にかかるネットワークシステム１では、常時接続サーバ２００が、クライアント１００とのデータ送受信を制御するＷＳサーバ２１０Ａの機能を有し、アプリケーションサーバ３００の各々が、プログラムとしてのサーバＡＰＰ３１０Ａの機能や認証情報を生成するサーバＡＰＩ３１０Ｂの機能を搭載するものであった。

しかしながら、本実施の形態においては、認証情報を生成する機能２１０Ｂを常時接続サーバ２００が有するものである。図２６は、第５の実施の形態にかかるネットワークシステム１の通信構成を示すイメージ図である。
＜第６の実施の形態＞

さらに、第６の実施の形態について説明する。本実施の形態においては、アプリケーションサーバ３００Ｕが、ＷＳサーバ３１０Ｗの機能と、認証情報を生成する機能３１０Ｚと、２つのサーバＡＰＰ３１０Ａ，３１０Ａの機能とを有する。図２７は、第７の実施の形態にかかるネットワークシステム１の通信構成を示すイメージ図である。なお、本実施の形態にかかるネットワークシステム１においては、クライアント１００に関する構成が第１の実施の形態とそれと同様であるため、クライアント１００の構成については説明を繰り返さない。

図２７を参照して、アプリケーションサーバ３００Ｕは、ＷｅｂＳｏｃｋｅｔプロトコルを使用した通信を制御するプログラムとしてのＷＳサーバ３１０Ｗの機能と、認証情報を生成する機能３１０Ｚと、第１のサービスプログラムとしてのサーバＡＰＰ３１０Ａの機能と、第２のサービスプログラムとしてのＡＰＰ３１０Ａの機能とを有する。複数のサーバＡＰＰ３１０Ａ，３１０Ａの各々は、ＨＴＴＰプロトコルを使用して、他のデータベース、スマートフォン５００などと通信することができる。そして、サーバＡＰＰ３１０Ａ，３１０Ａは、ＷＳサーバ３１０Ｗを介して、ＷｅｂＳｏｃｋｅｔプロトコルを使用して、クライアント１００に情報をプッシュ送信することができる。
＜第７の実施の形態＞

さらに、第７の実施の形態について説明する。本実施の形態においては、第５および第６の実施の形態とは逆に、ＷＳサーバの機能と、認証情報を生成する機能と、２つのサーバＡＰＰの機能とが、バラバラに別のコンピュータに搭載される。図２８は、第８の実施の形態にかかるネットワークシステム１の通信構成を示すイメージ図である。

図２８を参照して、クライアント１００は、ＨＴＴＰプロトコルを使用して常時接続サーバ２００Ｔ、認証情報生成サーバ２００Ｕ、アプリケーションサーバ３００Ａ，３００Ｂと通信することができるし、ＷｅｂＳｏｃｋｅｔプロトコルを使用して常時接続サーバ２００Ｔと常時接続することもできる。より詳細には、クライアント１００は、クライアントＡＰＰ１１０ＡとクライアントＡＰＩ１１０Ｂとを搭載する。クライアントＡＰＰ１１０Ａは、クライアント１００の各部を制御する。クライアントＡＰＩ１１０Ｂは、通信インターフェイス１６０を介して、ＨＴＴＰプロトコルを使用して通信したり、ＨＴＴＰプロトコル上で利用されるＷｅｂＳｏｃｋｅｔプロトコルを使用して通信したりする。

常時接続サーバ２００Ｔは、ＷｅｂＳｏｃｋｅｔプロトコルを使用してクライアント１００との常時接続通信を制御するためのプログラムとしてのＷＳサーバ２１０Ａを搭載する。常時接続サーバ２００Ｔは、ＨＴＴＰプロトコルを使用して、他のデータベース４５０にもアクセスすることができる。

認証情報生成サーバ２００Ｕは、ＨＴＴＰプロトコルを使用して複数のアプリケーションサーバ３００との通信を制御する。本実施の形態においては、常時接続サーバ２００Ｔは、ＨＴＴＰプロトコルを使用して、認証情報生成サーバ２００Ｕを介して、アプリケーションサーバ３００Ａ，３００Ｂに任意のタイミングでデータを送信できる。

本実施の形態にかかるネットワークシステム１は、複数のアプリケーションサーバ３００Ａ，３００Ｂを含む。複数のアプリケーションサーバ３００Ａ，３００Ｂの各々は、クライアント１００やスマートフォン５００などにサービスを提供するプログラムとしてのサーバＡＰＰ３１０ＡとＨＴＴＰプロトコルを利用して常時接続サーバ２００と通信するためのサーバＡＰＩ３１０Ｂとを搭載する。

たとえば、ネットワークシステム１は、掃除機１００Ａを制御するためのアプリケーションサーバ３００Ａと、エアコン１００Ｂを制御するためのアプリケーションサーバ３００Ｂなどを含む。複数のアプリケーションサーバ３００Ａ，３００Ｂの各々は、ＨＴＴＰプロトコルを使用して、常時接続サーバ２００、他のデータベース、スマートフォン５００などと通信することができる。そして、本実施の形態においては、アプリケーションサーバ３００Ａ，３００Ｂは、ＨＴＴＰプロトコルを使用して、常時接続サーバ２００に任意のタイミングでデータを送信できる。
＜第８の実施の形態＞

上述した第１から第４の実施の形態においては、ＷｅｂＳｏｃｋｅｔプロトコルを利用してデータを送信するか、ＨＴＴＰプロトコルを利用してデータを送信するかの判断するための基準が１種類であった。しかしながら、クライアント１００、常時接続サーバ２００、アプリケーションサーバ３００は、２つ以上の基準に基づいて判断しても良い。以下では、説明のために、クライアント１００、常時接続サーバ２００、アプリケーションサーバ３００を総称してコンピュータともいう。

たとえば、コンピュータは、第１の実施の形態の基準と第２の実施の形態の基準とに基づいて判断してもよい。そして、第１の実施の形態に関する条件を満たし、かつ、第２の実施の形態に関する条件を満たした場合に、コンピュータが、ＨＴＴＰプロトコルを利用してデータをアップロードまたはダウンロードしても良い。あるいは、第１の実施の形態に関する条件および第２の実施の形態に関する条件のうちの少なくとも１つを満たした場合に、コンピュータが、ＨＴＴＰプロトコルを利用してデータをアップロードまたはダウンロードしても良い。

同様に、コンピュータは、第１の実施の形態の基準と第３の実施の形態の基準とに基づいて判断してもよいし、第１の実施の形態の基準と第４の実施の形態の基準とに基づいて判断してもよいし、第２の実施の形態の基準と第３の実施の形態の基準とに基づいて判断してもよいし、第２の実施の形態の基準と第４の実施の形態の基準とに基づいて判断してもよいし、第３の実施の形態の基準と第５の実施の形態の基準とに基づいて判断してもよい。さらに、コンピュータは、３つ以上の基準に基づいて判断してもよい。そして、全ての条件を満たした場合、あるいは一部の条件を満たした場合に、コンピュータが、ＨＴＴＰプロトコルを利用してデータをアップロードまたはダウンロードしても良い。
＜その他の応用例＞

本発明は、システム或いは装置にプログラムを供給することによって達成される場合にも適用できることはいうまでもない。そして、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記憶媒体（あるいはメモリ）を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の効果を享受することが可能となる。

この場合、記憶媒体から読出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

また、コンピュータが読出したプログラムコードを実行することにより、前述した実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わる他の記憶媒体に書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれることは言うまでもない。

今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１ ：ネットワークシステム
１００ ：クライアント
１１０ ：ＣＰＵ
１１０Ａ ：クライアントＡＰＰ
１１０Ｂ ：クライアントＡＰＩ
１２０ ：メモリ
１５０ ：家電制御回路
１６０ ：通信インターフェイス
２００ ：常時接続サーバ
２１０ ：ＣＰＵ
２１０Ａ ：ＷＳサーバ
２２０ ：メモリ
２６０ ：通信インターフェイス
３００ ：アプリケーションサーバ
３１０ ：ＣＰＵ
３１０Ａ ：サーバＡＰＰ
３１０Ｂ ：サーバＡＰＩ
３２０ ：メモリ
３６０ ：通信インターフェイス

Claims (11)

1. 複数の電子機器と、常時接続サーバと、アプリケーションサーバとを備え、
   前記常時接続サーバは、前記複数の電子機器と常時接続し、常時接続を開始した当該複数の電気機器それぞれとの常時接続に利用するための識別情報を発行し、当該識別情報を前記アプリケーションサーバに送信し、
   前記アプリケーションサーバは、前記識別情報を受信した後に前記識別情報に基づいて前記常時接続サーバを介して常時接続中にある前記複数の電子機器のいずれかへ情報をプッシュする、ネットワークシステム。
2. 前記常時接続サーバが第１のコンピュータに搭載され、
   前記アプリケーションサーバが第２のコンピュータに搭載される、請求項１に記載のネットワークシステム。
3. 前記常時接続サーバと前記アプリケーションサーバとが、１つのコンピュータに搭載される、請求項１に記載のネットワークシステム。
4. 前記常時接続サーバは、常時接続開始後に、常時接続可能なプロトコルを利用して、前記複数の電子機器の各々に前記識別情報を発行する、請求項１から３のいずれか１項に記載のネットワークシステム。
5. 前記アプリケーションサーバは、前記複数の電子機器のいずれかと前記常時接続サーバとに認証情報を発行し、
   前記常時接続サーバは、前記アプリケーションサーバからの前記認証情報と前記複数の電子機器のいずれかからの前記認証情報とに基づいて、前記アプリケーションサーバと前記複数の電子機器のいずれかとに前記識別情報を発行する、請求項１から４のいずれか１項に記載のネットワークシステム。
6. 前記アプリケーションサーバとして、複数のアプリケーションサーバを備え、
   前記複数のアプリケーションサーバの各々は、前記識別情報を利用することによって前記常時接続サーバを介して前記複数の電子機器のいずれかへ情報をプッシュする、請求項１から５のいずれか１項に記載のネットワークシステム。
7. 前記常時接続サーバは、前記電子機器にデータ本体とトランザクションＩＤとを前記電子機器に送信し、
   前記電子機器は、前記データ本体の受信完了後に、前記トランザクションＩＤを前記常時接続サーバに送信し、
   前記常時接続サーバは、前記電子機器からの前記トランザクションＩＤに基づいて、前記電子機器へのデータ送信が完了した旨を前記アプリケーションサーバに通知する、請求項１から６のいずれか１項に記載のネットワークシステム。
8. 前記電子機器は、前記常時接続サーバにデータ本体とトランザクションＩＤとを前記常時接続サーバに送信し、
   前記常時接続サーバは、前記データ本体の受信完了後に、前記トランザクションＩＤを前記電子機器に送信し、
   前記常時接続サーバは、前記電子機器からの前記トランザクションＩＤに基づいて、前記電子機器からのデータ受信が完了した旨を前記アプリケーションサーバに通知する、請求項１から７のいずれか１項に記載のネットワークシステム。
9. 複数の電子機器と常時接続サーバとが常時接続を開始するステップと、
   前記常時接続サーバが、常時接続を開始した当該複数の電気機器それぞれとの常時接続に利用するための識別情報を発行して当該当該複数の電気機器それぞれの識別情報をアプリケーションサーバに送信するステップと、
   前記アプリケーションサーバが、前記識別情報を受信した後に、前記識別情報に基づいて前記常時接続サーバを介して常時接続中にある前記複数の電子機器のいずれかへ情報をプッシュするステップとを備える、常時接続方法。
10. 複数の電子機器に対応付けられる識別情報を格納するためのメモリと、
    通信インターフェイスと、
    前記通信インターフェイスを利用することによって、前記複数の電子機器と常時接続し、常時接続を開始した当該複数の電気機器それぞれとの常時接続に利用するための識別情報を発行し、当該当該複数の電気機器それぞれの識別情報をアプリケーションサーバに送信し、前記識別情報を受信した後に、前記識別情報に基づいて前記アプリケーションサーバからの情報を常時接続中にある前記複数の電子機器のいずれかにプッシュする、常時接続サーバ。
11. プロセッサとメモリと通信インターフェイスとを含むコンピュータで利用されるプログラムであって、
    前記通信インターフェイスを利用することによって、複数の電子機器と常時接続を開始するステップと、
    常時接続を開始した当該複数の電気機器それぞれとの常時接続に利用するための識別情報を発行し、当該識別情報を前記メモリに格納するステップと、
    前記通信インターフェイスを利用することによって、当該複数の電気機器それぞれの識別情報をアプリケーションサーバに送信するステップと、
    前記通信インターフェイスを利用することによって、前記識別情報に基づいて前記アプリケーションサーバからの情報を常時接続中にある前記複数の電子機器のいずれかにプッシュするステップとを前記プロセッサに実行させる、プログラム。

Images