JP6055201B2 - サーバー装置、システム及びその制御方法 - Google Patents

Description

本発明は、クライアント装置とインターネットを介して通信するサーバー装置、システム及びその制御方法に関する。

従来、クライアント・サーバーシステムにおける接続の確立方法には、受信側が受信した接続要求に基づいて送信側で有効化されたセキュリティプロトコル（例えば、ＳＳＬ）を識別し、適切なプロトコルを用いて接続を確立する方法がある。そして、メッセージを暗号化して通信を行う。例えば、特許文献１参照。

また、クライアントからのハンドシェークを起点として、インターネット上のサーバーからファイアウォール内のイントラネットワーク上のクライアントに対して持続的に通信コネクションを維持することで通信を行うPush通信方式が提案されている。例えば、非特許文献１参照。

特表２００９−５０８２６１号公報

Internet Engineering Task Force (IETF) RFC 6455: The WebSocket protocol（URL：http://tools.ietf.org/html/rfc6455）

Push通信を行う際、クライアントとサーバー間の通信コネクションを持続的に維持すると、サーバーでは通信を行うクライアントの台数分だけメモリやＣＰＵ使用、コネクション等のリソースを消費し続けることになる。よって、サーバーでのリソース消費効率を考慮すると、Push通信が必要になったタイミングで初めてクライアントからハンドシェークを行うことで通信コネクションを確立し、Push通信が完了したら通信コネクションを解放することが望ましい。

しかし、従来のクライアント・サーバーシステムにおける接続の確立方法では、Push通信を行うタイミングでサーバーからクライアントに対してハンドシェークを開始するように指示することができなかった。

本発明は、インターネットを介して通信を行うクライアント装置とサーバー装置の間で、サーバー装置側のリソースを考慮して、上述のようなPush通信を含む特定の通信方式に、適切なタイミングで切り替えることが可能な手法を提供する。

本発明は、クライアント装置とインターネットを介して通信するサーバー装置であって、
前記クライアント装置からＨＴＴＰ（HyperText Transfer Protocol）プロトコルで問い合わせを受信する受信手段と、
前記受信した問い合わせの応答として、ＨＴＴＰプロトコルから、前記クライアント装置からの要求なしに前記サーバー装置から指示が可能となる、ＨＴＴＰプロトコルとは異なる特定の通信方式に切り替えるための初期通信を行う第１の条件を送信する送信手段と、
前記クライアント装置と前記第１の条件に従う初期通信を行うことにより前記特定の通信方式に切り替え、前記特定の通信方式により当該クライアント装置に対して送信の指示を行う指示手段と、
を有することを特徴とする。

本発明によれば、インターネットを介して通信を行うクライアント装置とサーバー装置の間で、サーバー装置側のリソースを考慮して、上述のようなPush通信を含む特定の通信方式に、適切なタイミングで切り替えることが可能となる。

Push通信型クライアント・サーバーシステムのシステム構成及びハードウェア構成を示すブロック図。 図１に示すシステムのソフトウェア構成を示すブロック図。 データベースサーバーサービスモジュール内のテーブル構成例を示す図。 リクエストを受信した第１の実施形態の処理を示すフローチャート。 第１の実施形態のハンドシェーク制御情報の例を示す図。 ハンドシェーク開始を登録する際の処理を示すフローチャート。 リクエストを受信した第２の実施形態の処理を示すフローチャート。 第２の実施形態のハンドシェーク制御情報の例を示す図。 Close処理を行うか否かを設定する際の処理を示すフローチャート。 ハンドシェークを開始する第３の実施形態の処理を示すフローチャート。 レスポンスを送信する第３の実施形態の処理を示すフローチャート。

以下、図面を参照しながら発明を実施するための形態について詳細に説明する。以下の実施形態では、Push通信型クライアント・サーバーシステムを例に挙げて説明する。尚、Push通信のプロトコルには、特定の通信方式である「WebSocket」を用いるものとする。

このWebSocketによる双方向通信では、インターネット上のサーバー装置からPushでコマンド送信が可能である。また、クライアント装置からの問い合わせ（要求）がなくても、コマンド送信が可能であり、双方向通信の際にヘッダ情報等を省略でき、ネットワーク上に流れるデータ量を少なくすることができる。しかしながら、サーバー装置のリソースが少ないと、複数のクライアント装置を管理することが困難であるという問題がある。

［第１の実施形態］
まず、Push通信型クライアント・サーバーシステムのシステム構成とハードウェア構成とを、図１に示すブロック図を用いて説明する。Push通信型クライアント・サーバーシステムは、ＬＡＮで接続されたクライアントコンピューター１２０、ネットワークプリンター１４０、ファイアウォール１６０及びＷＡＮを介して接続されるサーバーコンピューター１００とで構成される。

尚、サーバーコンピューター１００とクライアントコンピューター１２０とは、汎用のコンピューター（例えば、パーソナルコンピューター）の構成を有するものとする。また、サーバーコンピューター１００とクライアントコンピューター１２０とのハードウェア構成で重複するものについては、どちらか一方のみを説明し、もう一方については説明を省略する。

また、クライアントコンピューター１２０は、パーソナルコンピューター又はデジタル複合機などの画像形成装置である。

サーバーコンピューター１００において、ＣＰＵ１０１は、ＲＯＭ１０３や外部メモリ１０６に記憶されたアプリケーションプログラム等に従って各種処理を実行する。更に、ＣＰＵ１０１はシステムバス１０７に接続される各デバイスを総括的に制御する。ＲＡＭ１０２は、ＣＰＵ１０１の主メモリ、ワークエリア等として機能する。ＲＯＭ１０３は、基本Ｉ／Ｏプログラム等の記憶領域として機能する読み出し専用のメモリである。ＲＯＭ１０３或いは外部メモリ１０６には、ＣＰＵ１０１の制御プログラムであるオペレーティングシステム（以下ＯＳ）等が記憶される。更に、ＲＯＭ１０３或いは外部メモリ１０６には、アプリケーションプログラム等に基づく処理の際に使用するファイルやその他各種データを記憶する。

ネットワークＩ／Ｆ１０４は、ネットワークへ接続し、ネットワーク通信を制御する。外部メモリＩ／Ｆ１０５は、ハードディスク（ＨＤ）等の外部メモリ１０６とのアクセスを制御する。外部メモリ１０６は、ブートプログラム、各種のアプリケーション、ユーザーファイル、編集ファイル等を記憶する。

サーバーコンピューター１００は、ＣＰＵ１０１がＲＯＭ１０３や外部メモリ１０６に書き込まれた基本Ｉ／Ｏプログラム及びＯＳを実行している状態で動作する。基本Ｉ／ＯプログラムはＲＯＭ１０３に書き込まれており、ＯＳはＲＯＭ１０３もしくは外部メモリ１０６に書き込まれている。そして、コンピューターの電源がＯＮされたときに、基本Ｉ／Ｏプログラム中のイニシャルプログラムロード機能により、ＲＯＭ１０３もしくは外部メモリ１０６からＯＳがＲＡＭ１０２に書き込まれ、ＯＳの動作が開始される。システムバス１０７は、各デバイスを接続する。

クライアントコンピューター１２０において、キーボードＩ／Ｆ１２１は、キーボード１２２や不図示のポインティングデバイスからの入力を制御する。ディスプレイＩ／Ｆ１２３は、ディスプレイ１２４の表示を制御する。ＣＰＵ１０１は、ディスプレイ１２４上の不図示のマウスカーソル等で指示されたコマンドに基づいて登録された種々のウインドウを開き、種々のデータ処理を実行する。

ネットワークプリンター１４０において、ネットワークＩ／Ｆ１４１は、ネットワークへ接続し、ネットワーク通信を制御する。ＣＰＵ１４２は、制御プログラム等に基づいてシステムバス１５１に接続されるプリンターＩ／Ｆ１４７を介してプリンター１４８に出力情報としての画像信号を出力する。尚、制御プログラムは、ＲＯＭ１４４や外部メモリ１５０等に記憶される。

ＣＰＵ１４２は、ネットワークＩ／Ｆ１４１を介してコンピューターと通信処理が可能となっており、ネットワークプリンター１４０内の情報等をクライアントコンピューター１２０に通知可能に構成されている。更に、ＣＰＵ１４２はＲＯＭ１４４或いは外部メモリ１５０に記憶されたアプリケーションプログラム等に基づいて処理を実行する。ＲＡＭ１４３は、ＣＰＵ１４２の主メモリ、ワークエリア等として機能し、不図示の増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。尚、ＲＡＭ１４３は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。ＲＯＭ１４４或いは外部メモリ１５０には、ＣＰＵ１４２の制御プログラムや出力情報を生成する際に使用するフォントデータ、ネットワークプリンター１４０上で利用される情報等が記憶される。

操作部Ｉ／Ｆ１４５は、操作部１４６との間のインタフェースであり、表示すべき画像データを操作部１４６に対して出力する。また、ユーザーが操作部１４６を介して入力した情報の受信も行う。操作部１４６は、操作のためのスイッチ及びＬＥＤ表示器等が配されている操作パネル等に相当する。プリンターＩ／Ｆ１４７は、プリンター１４８（プリンターエンジン）に出力情報としての画像信号を出力する。外部メモリＩ／Ｆ（メモリコントローラ）１４９は、ハードディスク（ＨＤ）やＩＣカード等で構成される外部メモリ１５０のアクセスを制御する。また、外部メモリ１５０は１個に限らず、少なくとも１個以上備え、内蔵フォントに加えてオプションフォントカード、言語系の異なるプリンター制御言語を解釈するプログラムを格納した外部メモリを複数接続できるように構成されていてもよい。更に、不図示のＮＶＲＡＭを有し、操作部１４６から指示されたプリンターモード設定情報を記憶するようにしてもよい。システムバス１５１は、各デバイスを接続する。

次に、Push通信型クライアント・サーバーシステムのソフトウェア構成を、図２に示すブロック図を用いて説明する。まず、サーバーコンピューター１００のソフトウェア構成を示す。

サーバーコンピューター１００において、アプリケーション２０５、モジュール２００、２０４、２１０は、外部メモリ１０６に保存されたファイルとして存在する。これらは実行時にＯＳやそのモジュールを利用するモジュールによってＲＡＭ１０２にロードされ実行されるプログラムモジュールである。また、アプリケーション２０５は、外部メモリ１０６の不図示のＣＤ−ＲＯＭ、ネットワークを経由して外部メモリ１０６のＨＤに追加することが可能となっている。

ネットワークモジュール２００は、コンピューターとのネットワーク通信を行う。このネットワークモジュール２００は、ＴＣＰ／ＩＰモジュール２０１、ＨＴＴＰモジュール２０２、WebSocketモジュール２０３より構成される。ＴＣＰ／ＩＰモジュール２０１はＴＣＰ／ＩＰプロトコルでのネットワーク通信を行う。ＨＴＴＰモジュール２０２はトランスポート・プロトコルとしてＴＣＰを使用し、ＨＴＴＰプロトコルでのネットワーク通信を行う。WebSocketモジュール２０３はトランスポート・プロトコルとしてＴＣＰを使用し、WebSocketプロトコルでのネットワーク通信を行う。

Ｗｅｂサーバーサービスモジュール２０４は、クライアントコンピューター１２０からのＨＴＴＰリクエストを受け取るとＨＴＴＰレスポンスを応答するサービスを提供する。一方、アプリケーション２０５は、クライアントコンピューター１２０に指示を出すことでクライアントコンピューター１２０経由でネットワークプリンター１４０を管理する。また、アプリケーション２０５は、例えばＨＴＴＰリクエストに応答して処理を実行するプログラムとして実装される。上述のように、アプリケーション２０５はＷｅｂサーバーサービスモジュール２０４とともに、クライアントコンピューター１２０及びネットワークプリンター１４０を管理するＷｅｂアプリケーションを実現している。

アプリケーション２０５において、探索モジュール２０６は、ＬＡＮ接続されたネットワークプリンター１４０を探索するようクライアントコンピューター１２０に指示を行う。また、探索モジュール２０６はクライアントコンピューター１２０がアップロードしたネットワークプリンター１４０の探索結果を、ネットワークモジュール２００を介して受信する。そして、受信した探索結果を後述するデータベースサーバーサービスモジュール２１０に格納する。ファームウェア配信モジュール２０７は、ＬＡＮ接続されたネットワークプリンター１４０にファームウェアを配信するようクライアントコンピューター１２０に指示を行う。また、ファームウェア配信モジュール２０７はクライアントコンピューター１２０がアップロードしたネットワークプリンター１４０のファームウェア配信結果を、ネットワークモジュール２００を介して受信する。そして、受信したファームウェア配信結果を後述のデータベースサーバーサービスモジュール２１０に格納する。

設定情報配信モジュール２０８は、ＬＡＮ接続されたネットワークプリンター１４０の設定情報を配信するようクライアントコンピューター１２０に指示を行う。また、設定情報配信モジュール２０８はクライアントコンピューター１２０がアップロードしたネットワークプリンター１４０の設定情報配信結果を、ネットワークモジュール２００を介して受信する。そして、受信した設定情報配信結果を後述するデータベースサーバーサービスモジュール２１０に格納する。ハンドシェーク制御情報管理モジュール２０９は、クライアントコンピューター１２０に対してWebSocketプロトコルのハンドシェーク開始を要求するためのハンドシェーク制御情報の作成を行う。尚、ハンドシェークは、クライアントコンピューター１２０からの要求がない場合にも、クライアントコンピューター１２０に対して指示が可能となる特定の通信方式に切り替えるための初期通信である。

データベースサーバーサービスモジュール２１０は、データを管理し、他モジュールからの要求に合わせてデータの格納と取り出しを行う。このデータベースサーバーサービスモジュール２１０は、アプリケーション２０５からアクセス可能であれば、サーバーコンピューター１００とは別の機器上にあってもよい。ここでデータベースサーバーサービスモジュール２１０内のテーブル構成の一例を図３に示す。尚、図３に示すテーブル構成はあくまで一例であり、本例とは異なるテーブル構成であってもよい。

サービス管理テーブル３００は、アプリケーション２０５が提供するネットワークプリンター管理サービスに関する情報を管理するテーブルである。このサービス管理テーブル３００で管理される情報は、例えばサービスＩＤ、サービス名等である。ここでサービスＩＤとは、サービスを一意に識別するＩＤである。クライアントコンピューター管理テーブル３０１は、サーバーコンピューター１００がPush通信を行うクライアントコンピューター１２０の情報を管理するテーブルである。このクライアントコンピューター管理テーブル３０１で管理される情報は、例えばクライアントＩＤ、クライアント名、ＩＰアドレス等である。ここでクライアントＩＤとは、クライアントコンピューター１２０を一意に識別するＩＤである。

クライアントコンピューター・サービス管理テーブル３０２は、クライアントコンピューター１２０が行うネットワークプリンター管理サービスの紐付け情報を管理するテーブルである。プリンター管理テーブル３０３は、クライアントコンピューター１２０が探索したネットワークプリンター１４０の情報を管理するテーブルである。このプリンター管理テーブル３０３で管理される情報は、例えばプリンターＩＤ、プリンター名、設置場所、モデルＩＤ、ＩＰアドレス等である。ここでプリンターＩＤとは、ネットワークプリンター１４０を一意に識別するＩＤである。

クライアントコンピューター・プリンター管理テーブル３０４は、クライアントコンピューター１２０が探索し、管理対象とするネットワークプリンター１４０の紐付け情報を管理するテーブルである。設定情報管理テーブル３０５は、設定情報配信モジュール２０８からクライアントコンピューター１２０の設定情報配信モジュール２２８を介してネットワークプリンター１４０に配信される設定情報を管理するテーブルである。この設定情報管理テーブル３０５で管理される情報は、例えば設定情報ＩＤ、モデルＩＤ、ＳＮＭＰｖ１設定、ＭＩＢアクセス設定、ＳＮＭＰｖ３設定、管理用パスワード設定、設置場所、ファイルサーバーＵＲＬ等である。

ここで設定情報ＩＤとは、設定情報を一意に識別するＩＤである。ＳＮＭＰｖ１設定とは、ネットワークプリンター１４０をＳＮＭＰｖ１（Simple Network Management Protocol Version1）プロトコルが利用できる状態にするか否かの設定である。ここでＳＮＭＰｖ１はネットワークプリンター１４０を監視・制御するためのプロトコルである。ＭＩＢアクセス設定とは、ネットワークプリンター１４０上のＭＩＢ（Management Information Base）へのアクセス権限に関する設定であり、書き込み／読み込み、読み込みのみ、アクセス不可等の設定がある。

ＳＮＭＰｖ３設定とは、ネットワークプリンター１４０がＳＮＭＰｖ３（Simple Network Management Protocol Version3）を利用できる状態にするか否かの設定である。ここでＳＮＭＰｖ３はＳＮＭＰの最新版であり、ｖ１と比べてセキュリティ等が強化されている。管理用パスワード設定とは、ネットワークプリンター１４０をリモート管理する際に必要なパスワードを初期設定から変更するための設定である。ここで管理用パスワード設定はセキュリティ上暗号化されて設定情報管理テーブル３０５に格納される。

ファームウェア管理テーブル３０６は、ファームウェア配信モジュール２０７からクライアントコンピューター１２０のファームウェア配信モジュール２２７を介してネットワークプリンター１４０に配信されるファームウェアの情報を管理するテーブルである。このファームウェア管理テーブル３０６で管理される情報は、例えばファームウェアＩＤ、モデルＩＤ、ファームウェアバージョン、ファイルパス、リリース日時等である。ここでファームウェアＩＤとは、ファームウェアを一意に識別するＩＤである。ファイルパスとは、ファームウェアの実体ファイルが格納されているファイルパスである。リリース日時とは、ファームウェアのリリース予定を表す日時情報である。

設定情報配信タスク管理テーブル３０７は、ネットワークプリンター１４０へ設定情報配信を行うタスクを管理するテーブルである。この設定情報配信タスク管理テーブル３０７で管理される情報は、例えばタスクＩＤ、プリンターＩＤ、設定情報ＩＤ、配信結果、実行日時等である。ここでタスクＩＤとは、設定情報配信のタスクを一意に識別するＩＤである。ファームウェア配信タスク管理テーブル３０８は、ネットワークプリンター１４０へファームウェア配信を行うタスクを管理するテーブルである。このファームウェア配信タスク管理テーブル３０８で管理される情報は、例えばタスクＩＤ、プリンターＩＤ、ファームウェアＩＤ、配信結果、実行日時等である。ここでタスクＩＤとは、ファームウェア配信のタスクを一意に識別するＩＤである。

次に、クライアントコンピューター１２０のソフトウェア構成を説明する。尚、クライアントコンピューター１２０を構成する各モジュールは、それぞれＲＯＭ１０３もしくは外部メモリ１０６に保存されたファイルとして存在するプログラムモジュールである。そして、実行時にＯＳやそのモジュールを利用するモジュールによってＲＡＭ１０２にロードされ実行される。

ネットワークモジュール２２０は、サーバーコンピューター１００やネットワークプリンター１４０とのネットワーク通信を行う。ネットワークモジュール２２０は、ＴＣＰ／ＩＰモジュール２２１、ＨＴＴＰモジュール２２２、WebSocketモジュール２２３より構成される。ＴＣＰ／ＩＰモジュール２２１はＴＣＰ／ＩＰプロトコルでのネットワーク通信を行う。ＨＴＴＰモジュール２２２はトランスポート・プロトコルとしてＴＣＰを使用し、ＨＴＴＰプロトコルでのネットワーク通信を行う。WebSocketモジュール２２３はトランスポート・プロトコルとしてＴＣＰを使用し、WebSocketプロトコルでのネットワーク通信を行う。

アプリケーション２２４は、サーバーコンピューター１００から受けた指示に基づいてネットワークプリンター１４０を管理する。また、アプリケーション２２４は、ネットワークプリンター１４０の管理結果をサーバーコンピューター１００にアップロードする。このアプリケーション２２４において、ハンドシェーク制御情報管理モジュール２２５はサーバーコンピューター１００から送信されたハンドシェーク制御情報を受信・解釈する。そして、ハンドシェーク制御情報によって指定されたタイミングに従って、WebSocketモジュール２２３を通じてWebSocketプロトコルのハンドシェーク処理を開始する。探索モジュール２２６は、サーバーコンピューター１００からの指示を受けてＬＡＮ接続されたネットワークプリンター１４０を探索する。

この探索モジュール２２６が探索に使用する通信プロトコルの例としては、ＳＮＭＰ（Simple Network Management Protocol）やＳＬＰ（Service Location Protocol）等が挙げられる。その他として、ＷＳ−Ｄｉｓｃｏｖｅｒｙ（Web Services Dynamic Discovery）などの通信プロトコルを使用してもよい。また、探索モジュール２２６はネットワークプリンター１４０の探索結果を、ネットワークモジュール２００を介してサーバーコンピューター１００にアップロードする。

ファームウェア配信モジュール２２７は、サーバーコンピューター１００からの指示を受けてＬＡＮ接続されたネットワークプリンター１４０にファームウェアを配信する。また、ファームウェア配信モジュール２２７は、ネットワークプリンター１４０へファームウェア配信結果を、ネットワークモジュール２００を介してサーバーコンピューター１００にアップロードする。設定情報配信モジュール２２８は、サーバーコンピューター１００からの指示を受けてＬＡＮ接続されたネットワークプリンター１４０に設定情報を配信する。また、設定情報配信モジュール２２８は、ネットワークプリンター１４０へ設定情報配信結果を、ネットワークモジュール２００を介してサーバーコンピューター１００にアップロードする。

続いて、ネットワークプリンター１４０のソフトウェア構成を説明する。ネットワークプリンター１４０において、各種モジュールはＲＯＭ１４４或いは外部メモリ１５０に保存されたファイルとして存在し、実行時にＲＡＭ１４３にロードされ実行される。ネットワークモジュール２４０は、任意の通信プロトコルを使用してクライアントコンピューター１２０とのネットワーク通信を行う。印刷処理モジュール２４１は、クライアントコンピューター１２０から送信された印刷ジョブの受信及び制御、印刷処理を行う。

ファームウェア管理モジュール２４２は、ネットワークプリンター１４０のファームウェアの管理を行う。ファームウェア管理モジュール２４２がネットワークモジュール２４０経由でクライアントコンピューター１２０上のファームウェア配信モジュール２２７からファームウェア配信指示を受信すると、そのファームウェアで自機のファームウェアを更新する。そして、ファームウェア更新結果を応答としてクライアントコンピューター１２０上のファームウェア配信モジュール２２７に返却する。

設定情報管理モジュール２４３は、ネットワークプリンター１４０の設定情報の管理を行う。ここで設定情報とは、例えばＳＮＭＰｖ１設定、ＭＩＢアクセス設定、ＳＮＭＰｖ３設定、管理用パスワード設定、設置場所等である。設定情報管理モジュール２４３がネットワークモジュール２４０経由でクライアントコンピューター１２０上の設定情報配信モジュール２２８から設定情報配信指示を受信すると、その設定情報で自機の設定を更新する。そして、設定情報更新結果を応答としてクライアントコンピューター１２０上の設定情報配信モジュール２２８に返却する。

以上の構成において、サーバーコンピューター１００が、クライアントコンピューター１２０から送信されたＨＴＴＰリクエストを受信した際の動作を、図４に示すフローチャートを用いて説明する。

Ｓ４００で、ＨＴＴＰモジュール２０２がクライアントコンピューター１２０からＨＴＴＰリクエストをＴＣＰ／ＩＰモジュール２０１を経由して受信する。Ｓ４０１でハンドシェーク制御情報管理モジュール２０９が、アプリケーション２０５がハンドシェークを要求しているか否かを判定する。アプリケーション２０５がハンドシェークを要求しているか否かの判定は、例えばデータベースサーバーサービスモジュール２１０の各テーブルに格納された値に基づいて判定してもよい。

ここでは、クライアント・サービス管理テーブル３０２でクライアントコンピューター１２０とファームウェア配信サービスが紐づけられ、ファームウェア管理テーブル３０６に近い将来リリース予定のファームウェアが登録されているケースを考える。アプリケーション２０５は、ファームウェアがリリースされ次第、なるべく早くクライアントコンピューター１２０経由でネットワークプリンター１４０に対してPush通信でファームウェアを配信したい。よって、この例では、ハンドシェーク制御情報管理モジュール２０９がハンドシェーク要求あり、と判定する。

また、別の例として、設定情報配信タスク管理テーブル３０７やファームウェア配信タスク管理テーブル３０８に、一定時間内に実行予定のタスクが任意数以上登録されているケースを考える。通常であれば、クライアントコンピューター１２０のアプリケーション２２４が定期的にサーバーコンピューター１００にアクセスし（ポーリング）、サーバーコンピューター１００上に登録されたタスクの情報を取得してタスクを実行する。しかし、サーバーコンピューター１００に登録されたタスクが任意数よりも多い場合、サーバーコンピューター１００はクライアントコンピューター１２０からの定期アクセスを待たずに直ちにPush通信でタスク実行を指示したい。よって、この例でも、ハンドシェーク制御情報管理モジュール２０９がハンドシェーク要求あり、と判定する。

更に、他の例として、クライアント・サービス管理テーブル３０２に、新たにクライアントコンピューター１２０と設定情報配信サービスが紐付けられたケースを考える。この場合、クライアントコンピューター１２０のアプリケーション２２４は新規にネットワークプリンター１４０を探索したらPush通信で直ちにネットワークプリンター１４０に対して初期設定を配信したい。よって、この例でも、ハンドシェーク制御情報管理モジュール２０９がハンドシェーク要求あり、と判定する。

上述のように、ハンドシェーク制御情報管理モジュール２０９は、例えばデータベースサーバーサービスモジュール２１０の各テーブルに格納された値に基づいて、アプリケーション２０５がハンドシェークを要求しているか否かを判定する。尚、ハンドシェーク制御情報管理モジュール２０９が、データベースサーバーサービスモジュール２１０に格納された値以外の情報に基づき、アプリケーション２０５がハンドシェークを要求しているか否かを判定してもよい。この場合、ハンドシェーク制御情報管理モジュール２０９は、サーバーコンピューター１００のメモリやハードディスク等のリソース消費状況、ネットワーク帯域の混雑状況等に基づいて判定してもよい。

Ｓ４０１で、アプリケーション２０５がハンドシェークを要求していると判定した場合はＳ４０２へ進み、そうでない場合はＳ４０８へ進む。Ｓ４０２ではハンドシェーク制御情報管理モジュール２０９が、アプリケーション２０５の要求するハンドシェークがクライアントコンピューター１２０上のイベントをトリガーに開始するものか否かを判定する。上述の例で言うと、まずファームウェアリリース時にPush通信でファームウェアを配信する場合、サーバーコンピューター１００上でのファームウェアリリースをトリガーにハンドシェークが開始される。よって、Ｓ４０２でハンドシェーク制御情報管理モジュール２０９が、ハンドシェークはクライアントコンピューター１２０上のイベントをトリガーに開始するものではないと判定する。

次に、サーバーコンピューター１００からPush通信でタスク実行を指示する場合、サーバーコンピューター１００上で登録タスク数が任意数以上になったことをトリガーにハンドシェークが開始される。よって、この場合もＳ４０２で、ハンドシェーク制御情報管理モジュール２０９が、ハンドシェークはクライアントコンピューター１２０上のイベントをトリガーに開始するものではないと判定する。

最後に、新規に探索されたネットワークプリンター１４０に対して初期設定を配信する場合、クライアントコンピューター１２０がネットワークプリンター１４０を探索したらそれをトリガーにハンドシェークが開始される。よって、この場合はＳ４０２で、ハンドシェーク制御情報管理モジュール２０９が、ハンドシェークはクライアントコンピューター１２０上のイベントをトリガーに開始するものであると判定する。

Ｓ４０２で、ハンドシェークがクライアントコンピューター１２０上のイベントをトリガーに開始するものであると判定した場合はＳ４０４へ進み、そうでない場合はＳ４０３へ進む。Ｓ４０３ではハンドシェーク制御情報管理モジュール２０９がアプリケーション２０５の要求するハンドシェークは周期的に開始するものか否かを判定する。上述の例で言うと、まずファームウェアリリース時にPush通信でファームウェアを配信する場合、ファームウェアの配信は一回行われるのみである。よって、Ｓ４０３でハンドシェーク制御情報管理モジュール２０９が、ハンドシェークは周期的に開始するものではない、と判定する。

一方、サーバーコンピューター１００からPush通信でタスク実行を指示する場合は、サーバーコンピューター１００上での登録タスク数が任意数以下になるまで、周期的にタスク実行が指示される。よって、この場合は、Ｓ４０３でハンドシェーク制御情報管理モジュール２０９が、ハンドシェークは周期的に開始するものであると判定する。

Ｓ４０３で、ハンドシェークが周期的に開始するものであると判定した場合はＳ４０５へ進み、そうでない場合はＳ４０６へ進む。Ｓ４０４〜Ｓ４０６では、ハンドシェーク制御情報管理モジュール２０９がハンドシェーク制御情報を生成する。このハンドシェーク制御情報の例を図５に示す。尚、図５では、ＸＭＬ形式による記述の例を示しているが、他の形式で記述されていてもよい。また、ハンドシェーク開始のトリガー（起因）となる第１の条件（５００〜５０２）については、Ｓ４０４〜Ｓ４０６の説明の中で述べる。

Ｓ４０４ではハンドシェーク制御情報管理モジュール２０９が、クライアントコンピューター１２０上のイベントをトリガーにハンドシェークを開始するように指定されたハンドシェーク制御情報を生成する。クライアントコンピューター１２０上のイベントをトリガーにハンドシェークを開始するように指定されたハンドシェーク制御情報の例を図５の５００に示す。この例では、ハンドシェーク開始のトリガーとなるアセンブリ、クラス、イベントをＸＭＬ形式で記述している。

Ｓ４０５ではハンドシェーク制御情報管理モジュール２０９が、指定時刻以降、周期的にハンドシェークを開始するように指定されたハンドシェーク制御情報を生成する。指定時刻以降、周期的にハンドシェークを開始するように指定されたハンドシェーク制御情報の例を図５の５０１に示す。この例では、ハンドシェークの開始時刻、終了時刻、周期をＸＭＬ形式で記述している。

Ｓ４０６ではハンドシェーク制御情報管理モジュール２０９が、ハンドシェークが指定時刻に一回のみ開始されるように指定されたハンドシェーク制御情報を生成する。指定時刻に一回のみハンドシェークを開始するように指定されたハンドシェーク制御情報の例を図５の５０２に示す。この例では、ハンドシェークの開始時刻をＸＭＬ形式で記述している。

Ｓ４０７で、ハンドシェーク制御情報管理モジュール２０９が、Ｓ４０４〜Ｓ４０６で生成されたハンドシェーク制御情報をＨＴＴＰモジュール２０２が作成したＨＴＴＰレスポンスに付与する。ここで、ＨＴＴＰレスポンスへのハンドシェーク制御情報の付与は、例えばＨＴＴＰのヘッダーやボディに含めることで行う。そして、Ｓ４０８で、ＨＴＴＰモジュール２０２がＨＴＴＰレスポンスをクライアントコンピューター１２０に送信し、この処理を終了する。

尚、WebSocketのハンドシェーク（初期通信）を行う起因となる第１の条件として予め定めれたイベント、スケジュール情報及び周期を例に挙げたが、本発明はこれだけに限るものではない。

次に、クライアントコンピューター１２０がサーバーコンピューター１００にＨＴＴＰリクエストを送信し、受信したＨＴＴＰレスポンスに基づいてハンドシェーク開始を登録する際の動作を、図６に示すフローチャートを用いて説明する。

Ｓ６００で、ＨＴＴＰモジュール２２２が、ＴＣＰ／ＩＰモジュール２２１を経由してＨＴＴＰリクエストをサーバーコンピューター１００に送信する。Ｓ６０１で、ＨＴＴＰモジュール２２２が、ＴＣＰ／ＩＰモジュール２２１を経由してサーバーコンピューター１００から送信されたＨＴＴＰレスポンスを受信する。Ｓ６０２で、ハンドシェーク制御情報管理モジュール２２５が、Ｓ６０１で受信したＨＴＴＰレスポンスにハンドシェーク制御情報が付与されているか否かを判定する。ハンドシェーク制御情報が付与されている場合はＳ６０３へ進み、付与されていない場合はそのまま処理を終了する。

Ｓ６０３では、ハンドシェーク制御情報管理モジュール２２５が、ＨＴＴＰレスポンスからハンドシェーク制御情報を取得する。そして、Ｓ６０４で、ハンドシェーク制御情報管理モジュール２２５が、取得したハンドシェーク制御情報の内容がクライアントコンピューター１２０上のイベントをトリガーにハンドシェークを開始するように記述されているか否かを判定する。判定した結果、ハンドシェーク制御情報の内容がクライアントコンピューター１２０上のイベントをトリガーにハンドシェークを開始するように記述されている場合はＳ６０６へ進み、そうでない場合はＳ６０５へ進む。

Ｓ６０５ではハンドシェーク制御情報管理モジュール２２５が、取得したハンドシェーク制御情報の内容が指定時刻以降、周期的にハンドシェークを開始するように記述されているか否かを判定する。判定した結果、ハンドシェーク制御情報の内容が指定時刻以降、周期的にハンドシェークを開始するように記述されている場合はＳ６０７へ進み、そうでない場合はＳ６０８へ進む。Ｓ６０６〜Ｓ６０８ではハンドシェーク制御情報管理モジュール２２５が、WebSocketモジュール２２３に対してハンドシェーク開始を登録する。

Ｓ６０６では、ハンドシェーク制御情報管理モジュール２２５が、WebSocketモジュール２２３に対してクライアントコンピューター１２０上のイベントをトリガーにハンドシェークを開始するようにハンドシェーク開始を登録する。また、Ｓ６０７では、ハンドシェーク制御情報管理モジュール２２５が、WebSocketモジュール２２３に対して指定時刻以降、周期的にハンドシェークを開始するようにハンドシェーク開始を登録する。また、Ｓ６０８では、ハンドシェーク制御情報管理モジュール２２５が、WebSocketモジュール２２３に対して指定時刻に一回のみハンドシェークを開始するようにハンドシェーク開始を登録する。

以上の処理により、Push通信を行う際に、サーバーコンピューター１００からクライアントコンピューター１２０に対してPush通信を行うためのハンドシェークを開始するように指示することができる。よって、Push通信を行うためのサーバーコンピューター１００とクライアントコンピューター１２０との間の通信コネクションを持続維持する時間を短くすることができる。そのため、サーバーコンピューター１００のメモリやＣＰＵ使用、コネクション等のリソース消費を抑えることができる。

［第２の実施形態］
第１の実施形態では、Push通信を行う時のみ、サーバーコンピューター１００からクライアントコンピューター１２０に対してハンドシェーク開始を指示することで、必要以上にサーバーのリソースを消費せずにPush通信を実現した。

第２の実施形態では、サーバーコンピューター１００が自身に登録されているPush通信タスクを確認し、タスクの実行スケジュール間隔が一定時間以内であればWebSocketセッションのKeepAliveを指示する処理を説明する。このWebSocketセッションのKeepAlive指示によりPush通信完了後のClose処理をスキップし、次回以降のPush通信で接続を切断することなくそのまま使用することでＣＰＵ負荷や時間の無駄を節約することができる。

第２の実施形態におけるPush通信型クライアント・サーバーシステムのシステム構成及びハードウェア構成・ソフトウェア構成は、第１の実施形態における図１及び図２と同様であるため、説明は省略する。

まず、サーバーコンピューター１００がクライアントコンピューター１２０から送信されたＨＴＴＰリクエストを受信する際の動作を、図７に示すフローチャートを用いて説明する。尚、この説明の一部は、第１の実施形態の図４と重複するため、異なる部分のみを以下に説明する。

Ｓ７００で、ハンドシェーク制御情報管理モジュール２０９が、Push通信完了後にClose処理が必要か否かを判定する。ここでPush通信完了後にClose処理が必要か否かの判定は、例えば設定情報配信タスク管理テーブル３０７やファームウェア配信タスク管理テーブル３０８に任意の閾値時間内の間隔で実行予定のタスクが登録されているか否かで判定する。しかしながら、Push通信完了後にClose処理を行っても、結局、短い間隔しか空けずに再度Push通信を行うためのハンドシェークを行う必要があり、サーバーコンピューター１００のＣＰＵ負荷や時間を消費してしまう。そこで、設定情報配信タスク管理テーブル３０７やファームウェア配信タスク管理テーブル３０８に任意の閾値時間内の間隔で実行予定のタスクが登録されている場合は、接続を維持した方が効率的なので、Push通信完了後にClose処理が不要と判定する。もちろん、ハンドシェーク制御情報管理モジュール２０９が上記以外の方法で、Push通信完了後にClose処理が必要か否かを判定してもよい。

Ｓ７００でClose処置が必要と判断した場合はＳ７０１へ進み、そうでない場合はＳ７０２へ進む。このＳ７０１では、ハンドシェーク制御情報管理モジュール２０９が、Push通信完了後にClose処理を行うようにハンドシェーク制御情報に設定する。一方、Ｓ７０２では、ハンドシェーク制御情報管理モジュール２０９が、WebSocketセッションのKeepAliveを行うために、Push通信完了後にClose処理を行わないようにハンドシェーク制御情報に設定する。

Push通信完了後にClose処理を行うか否かを設定したハンドシェーク制御情報の例を図８に示す。尚、図８では、ＸＭＬ形式による記述の例を示しているが、もちろん、他の形式で記述されていてもよい。図８では、ｃｌｏｓｅタグでPush通信完了後にClose処理を行うか否かを記述している。この図８に示す８００、８０１、８０２は第１の実施形態で説明した図５に示す第１の条件５００、５０１、５０２にそれぞれ対応する第２の条件である。

次に、クライアントコンピューター１２０がサーバーコンピューター１００にＨＴＴＰリクエストを送信し、受信したＨＴＴＰレスポンスに基づいて、Close処理を行うか否かを設定する際の動作を、図９に示すフローチャートを用いて説明する。尚、この説明の一部は、第１の実施形態の図６と重複するため、異なる部分のみを以下に説明する。

Ｓ９００で、ハンドシェーク制御情報管理モジュール２２５が、Ｓ６０３で取得したハンドシェーク制御情報に基づいて、Push通信完了後にClose処理が必要か否かを判定する。ここでClose処理が必要と判定した場合はＳ９０１へ進み、必要でないと判定した場合はＳ９０２へ進む。Ｓ９０１では、ハンドシェーク制御情報管理モジュール２２５が、WebSocketモジュール２２３に対してＳ６０６〜６０８で登録されたハンドシェーク開始後に行われるPush通信完了後にClose処理を行うように設定を行う。

一方、Ｓ９０２では、ハンドシェーク制御情報管理モジュール２２５が、WebSocketモジュール２２３に対してＳ６０６〜６０８で登録されたハンドシェーク開始後に行われるPush通信完了後にClose処理をスキップするように設定を行う。

尚、Push通信完了後のClose処理をスキップした場合、最終的なWebSocket通信のClose処理はサーバーコンピューター１００もしくはクライアントコンピューター１２０の何れから行ってもよい。例えば、サーバーコンピューター１００からClose処理を行う場合、サーバーコンピューター１００が任意の閾値時間を経過して実行予定のタスクが登録されていないと判断すると、Close処理を行う。一方、クライアントコンピューター１２０からClose処理を行う場合、所定のタイムアウト時間が経過すると、Close処理を行う。

以上の処理により、サーバーコンピューター１００が登録されているPush通信タスクの実行スケジュール間隔が一定以内であればWebSocketセッションのKeepAliveを指示し、Push通信完了後のClose処理をスキップする。それにより、次回以降のPush通信においても接続をそのまま使用することで、サーバーコンピューター１００のＣＰＵ負荷や時間の無駄を節約することができる。

［第３の実施形態］
第２の実施形態では、サーバーコンピューター１００がPush通信タスクの実行スケジュール間隔が一定以内であればWebSocketセッションのKeepAliveを指示していた。

第３の実施形態では、クライアントコンピューター１２０上で時刻指定もしくは周期実行のハンドシェーク開始が登録された場合、ハンドシェークを開始する前にサーバーコンピューター１００にハンドシェーク要求有無の問い合わせを行う。

第３の実施形態におけるPush通信型クライアント・サーバーシステムのシステム構成及びハードウェア構成・ソフトウェア構成は、第１の実施形態における図１及び図２と同様であるため、説明は省略する。

また、サーバーコンピューター１００がクライアントコンピューター１２０から送信されたＨＴＴＰリクエストを受信する際の動作は、第１の実施形態の図４と同様であるため、説明は省略する。

更に、クライアントコンピューター１２０がサーバーコンピューター１００にＨＴＴＰリクエストを送信し、受信したＨＴＴＰレスポンスに基づいてハンドシェーク開始を登録する際の動作は、第１の実施形態の図６と同様であるため、説明は省略する。

ここで、クライアントコンピューター１２０がハンドシェーク要求に基づいて時刻指定もしくは周期実行でハンドシェークを開始する際の動作を、図１０に示すフローチャートを用いて説明する。

まず、Ｓ１０００で、ハンドシェーク制御情報管理モジュール２２５が、ネットワークモジュール２２０を経由してサーバーコンピューター１００に対してハンドシェーク要求有無取得リクエストを送信する。Ｓ１００１で、ハンドシェーク制御情報管理モジュール２２５が、ネットワークモジュール２２０を経由してサーバーコンピューター１００から送信されたレスポンスを受信する。そして、Ｓ１００２で、ハンドシェーク制御情報管理モジュール２２５が、受信したレスポンスに基づいてハンドシェーク要求の有無を判定する。ハンドシェーク要求があると判定した場合はＳ１００３へ進み、WebSocketモジュール２２３がWebSocketプロトコルのハンドシェークを開始する。一方、ハンドシェーク要求がないと判定した場合はハンドシェークを開始せず、処理を終了する。

次に、サーバーコンピューター１００がクライアントコンピューター１２０からハンドシェーク要求有無取得リクエストを受信し、レスポンスを送信する際の動作を、図１１に示すフローチャートを用いて説明する。

まず、Ｓ１１００で、ハンドシェーク制御情報管理モジュール２０９が、ネットワークモジュール２００経由でハンドシェーク要求有無取得リクエストを受信する。Ｓ１１０１で、ハンドシェーク制御情報管理モジュール２０９が、アプリケーション２０５がハンドシェークを要求しているか否かを判定する。アプリケーション２０５がハンドシェークを要求しているか否かの判定は、例えば第１の実施形態のＳ４０１の説明で記載の方法などで行う。

ここで、ハンドシェークによるWebSocketプロトコルの確立が不要と判断する場合は、クライアントコンピューター１２０に対して緊急のファームアップの指示や閾値を上回るような多くの指示がサーバーコンピューター１００に存在しない場合である。

Ｓ１１０１でアプリケーション２０５がハンドシェークを要求していると判定した場合はＳ１１０２へ進み、そうでない場合はＳ１１０３へ進む。このＳ１１０２では、ハンドシェーク制御情報管理モジュール２０９が、ハンドシェーク要求ありをレスポンスとしてネットワークモジュール２００経由でクライアントコンピューター１２０に送信する。

一方、Ｓ１１０３では、ハンドシェーク制御情報管理モジュール２０９が、ハンドシェーク要求なしをレスポンスとしてネットワークモジュール２００経由でクライアントコンピューター１２０に送信する。

以上の処理により、クライアントコンピューター１２０上で時刻指定もしくは周期実行のハンドシェーク開始が登録された場合、ハンドシェークを開始する前にサーバーコンピューター１００にハンドシェーク要求の有無を確認する。よって、不要なハンドシェーク開始を減らすことができ、必要以上にサーバーコンピューター１００のコネクション等のリソースを消費することを防ぐことができる。

また、実施形態では、ハンドシェークに先立って、クライアントコンピューター１２０がその要否のリクエストを行っていた。しかしながら、そのようなリクエストを行わなくても、サーバーコンピューター１００が不要と判断した場合には、クライアントコンピューター１２０からのハンドシェークの要求に対して、無視する、又はエラーを返すなどするといった手法をとってもよい。これにより、不要なWebSocketプロトコルの確立を抑制することが可能となる。

［他の実施形態］
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (24)

1. クライアント装置とインターネットを介して通信するサーバー装置であって、
   前記クライアント装置からＨＴＴＰ（HyperText Transfer Protocol）プロトコルで問い合わせを受信する受信手段と、
   前記受信した問い合わせの応答として、ＨＴＴＰプロトコルから、前記クライアント装置からの要求なしに前記サーバー装置から指示が可能となる、ＨＴＴＰプロトコルとは異なる特定の通信方式に切り替えるための初期通信を行う第１の条件を送信する送信手段と、
   前記クライアント装置と前記第１の条件に従う初期通信を行うことにより前記特定の通信方式に切り替え、前記特定の通信方式により当該クライアント装置に対して送信の指示を行う指示手段と、
   を有することを特徴とするサーバー装置。
2. 前記特定の通信方式は、WebSocketであることを特徴とする請求項１に記載のサーバー装置。
3. 前記初期通信は、前記WebSocketのハンドシェークであることを特徴とする請求項２に記載のサーバー装置。
4. 前記第１の条件は、さらに、スケジュール情報及び周期の少なくとも何れかを含むことを特徴とする請求項１乃至３の何れか１項に記載のサーバー装置。
5. 前記第１の条件は、ネットワークを介して新規に画像形成装置を探索したことであることを特徴とする請求項１乃至４の何れか１項に記載のサーバー装置。
6. 前記クライアント装置は、画像形成装置であることを特徴とする請求項１乃至５の何れか１項に記載のサーバー装置。
7. 前記第１の条件に対応する第２の条件に従って前記特定の通信方式による通信を切断する切断手段を更に有することを特徴とする請求項１乃至６の何れか１項に記載のサーバー装置。
8. 前記切断手段は、前記第２の条件として、前記クライアント装置に対して送信すべき指示がない場合に、前記特定の通信方式による通信を切断することを特徴とする請求項７に記載のサーバー装置。
9. 前記クライアント装置からの前記第１の条件に従う初期通信が行われる際に、前記クライアント装置に対して送信すべき指示がない場合、前記特定の通信方式に切り替えないよう制御することを特徴とする請求項１乃至８の何れか１項に記載のサーバー装置。
10. クライアント装置とインターネットを介して通信するサーバー装置の制御方法であって、
    受信手段が、前記クライアント装置からＨＴＴＰ（HyperText Transfer Protocol）プロトコルで問い合わせを受信する受信工程と、
    送信手段が、前記受信した問い合わせの応答として、ＨＴＴＰプロトコルから、前記クライアント装置からの要求なしに前記サーバー装置から指示が可能となる、ＨＴＴＰプロトコルとは異なる特定の通信方式に切り替えるための初期通信を行う第１の条件を送信する送信工程と、
    指示手段が、前記クライアント装置と前記第１の条件に従う初期通信を行うことにより前記特定の通信方式に切り替え、前記特定の通信方式により当該クライアント装置に対して送信の指示を行う指示工程と、
    を有することを特徴とするサーバー装置の制御方法。
11. 前記特定の通信方式は、WebSocketであることを特徴とする請求項１０に記載の制御方法。
12. 前記第１の条件は、さらに、スケジュール情報及び周期の少なくとも何れかを含むことを特徴とする請求項１０又は１１に記載の制御方法。
13. 前記第１の条件に対応する第２の条件に従って前記特定の通信方式による通信を切断する切断工程を更に有することを特徴とする請求項１０乃至１２の何れか１項に記載の制御方法。
14. 前記切断工程では、前記第２の条件として、前記クライアント装置に対して送信すべき指示がない場合に、前記特定の通信方式による通信を切断することを特徴とする請求項１３に記載の制御方法。
15. 前記クライアント装置からの前記第１の条件に従う初期通信が行われる際に、前記クライアント装置に対して送信すべき指示がない場合、前記特定の通信方式に切り替えないよう制御することを特徴とする請求項１０乃至１４の何れか１項に記載の制御方法。
16. 請求項１乃至９の何れか１項に記載のサーバー装置の各手段としてコンピューターを機能させるためのプログラム。
17. クライアント装置と、当該クライアント装置とインターネットを介して通信するサーバー装置とを含むシステムであって、
    前記サーバー装置は、
    前記クライアント装置からＨＴＴＰ（HyperText Transfer Protocol）プロトコルで問い合わせを受信する受信手段と、
    前記受信した問い合わせの応答として、ＨＴＴＰプロトコルから、前記クライアント装置からの要求なしに前記サーバー装置から指示が可能となる、ＨＴＴＰプロトコルとは異なる特定の通信方式に切り替えるための初期通信を行う第１の条件を送信する送信手段と、
    前記クライアント装置と前記第１の条件に従う初期通信を行うことにより前記特定の通信方式に切り替え、前記クライアント装置からの要求がなくても、前記特定の通信方式により当該クライアント装置に対して送信の指示を行う指示手段と、を有し、
    前記クライアント装置は、
    前記サーバー装置から、前記第１の条件を受信する受信手段と、
    前記受信された前記第１の条件に従い、前記サーバー装置に対して、前記初期通信を開始する制御手段と、を有する
    ことを特徴とするシステム。
18. 前記特定の通信方式は、WebSocketであることを特徴とする請求項１７に記載のシステム。
19. 前記第１の条件は、さらに、スケジュール情報及び周期の少なくとも何れかを含むことを特徴とする請求項１７又は１８に記載のシステム。
20. 前記クライアント装置は、画像形成装置であることを特徴とする請求項１７乃至１９の何れか１項に記載のシステム。
21. 前記サーバー装置が、前記第１の条件に対応する第２の条件に従って前記特定の通信方式による通信を切断する切断手段を更に有することを特徴とする請求項１７乃至２０の何れか１項に記載のシステム。
22. 前記切断手段は、前記第２の条件として、前記クライアント装置に対して送信すべき指示がない場合に、前記特定の通信方式による通信を切断することを特徴とする請求項２１に記載のシステム。
23. 前記サーバー装置が、前記クライアント装置からの前記第１の条件に従う初期通信が行われる際に、前記クライアント装置に対して送信すべき指示がない場合、前記特定の通信方式に切り替えないよう制御することを特徴とする請求項１７乃至２２の何れか１項に記載のシステム。
24. クライアント装置と、当該クライアント装置とインターネットを介して通信するサーバー装置とを含むシステムにおける制御方法であって、
    前記サーバー装置は、
    前記クライアント装置からＨＴＴＰ（HyperText Transfer Protocol）プロトコルで問い合わせを受信する受信工程と、
    前記受信した問い合わせの応答として、ＨＴＴＰプロトコルから、前記クライアント装置からの要求なしに前記サーバー装置から指示が可能となる、ＨＴＴＰプロトコルとは異なる特定の通信方式に切り替えるための初期通信を行う第１の条件を送信する送信工程と、
    前記クライアント装置と前記第１の条件に従う初期通信を行うことにより前記特定の通信方式に切り替え、前記クライアント装置からの要求がなくても、前記特定の通信方式により当該クライアント装置に対して送信の指示を行う指示工程と、を実行し、
    前記クライアント装置は、
    前記サーバー装置から、前記第１の条件を受信する受信工程と、
    前記受信された前記第１の条件に従い、前記サーバー装置に対して、前記初期通信を開始する制御工程と、を実行する、
    ことを特徴とする制御方法。

Images