JP2006121251A - サーバ - Google Patents

Abstract

【課題】Ｗｅｂカメラからのデータを、端末の能力に応じて最適に受信したい。
【解決手段】端末から、Ｗｅｂカメラのデータ受信を要求された場合、端末の能力によって受信方法を切り替える。端末能力が低い場合は、自装置を仲介して受信し、端末能力が高い場合は、ルータのアドレスとポート番号を通知して、直接受信させる。
【選択図】図１

Description

この発明は、サーバに関し、特にたとえば、コマンド処理装置と処理要求装置との間のデータ通信を仲介する、サーバに関する。

従来この種のサーバの一例が、特許文献１に開示されている。この従来技術は、コマンド処理装置（カメラ）へのコマンドの送信を依頼する送信依頼を処理要求装置（クライアントＰＣ）から受け付けたときコマンドをコマンド処理装置に送信し、送信されたコマンドの実行結果をコマンド処理装置から受信し、そして受信された実行結果を処理要求装置に送信する（図２参照）。
特開２００３−２４９９４３号公報〔Ｈ０４Ｌ １２／４６，１２／５６，１２／６６，Ｈ０４Ｎ ７／１８〕

従来技術は、コマンド処理装置と処理要求装置との間のデータ通信を的確に仲介することができる。しかし、実行結果が動画像など多量のデータを含む場合、大きな負荷がかかる。

それゆえに、この発明の主たる目的は、コマンド処理装置と処理要求装置との間のデータ通信を、負荷を低減しつつ的確に仲介することができる、サーバを提供することである。

請求項１の発明に従うサーバは、コマンド処理装置へのコマンドの送信を依頼する送信依頼を処理要求装置から受け付けたとき処理要求装置が所定条件を満足するか否かを判別する判別手段、判別手段の判別結果が否定的であるときコマンドをコマンド処理装置に送信する第１送信手段、第１送信手段によって送信されたコマンドの実行結果をコマンド処理装置から受信する受信手段、受信手段によって受信された実行結果を処理要求装置に送信する第２送信手段、判別手段の判別結果が肯定的であるときコマンドを受信するための準備処理をコマンド処理装置に命令する第１命令手段、および第１命令手段の命令に関連してコマンド処理装置へのコマンドの直接送信を処理要求装置に命令する第２命令手段を備える。

判別手段は、コマンド処理装置へのコマンドの送信を依頼する送信依頼を処理要求装置から受け付けたとき、処理要求装置が所定条件を満足するか否かを判別する。判別手段の判別結果が否定的であるとき、第１送信手段がコマンドをコマンド処理装置に送信する。受信手段は、第１送信手段によって送信されたコマンドの実行結果をコマンド処理装置から受信し、第２送信手段は、受信手段によって受信された実行結果を処理要求装置に送信する。判別手段の判別結果が肯定的であるとき、コマンドを受信するための準備処理を第１命令手段がコマンド処理装置に命令し、第２命令手段は、かかる第１命令手段の命令に関連して、コマンド処理装置へのコマンドの直接送信を処理要求装置に命令する。

処理要求装置が所定条件を満足しないときは、コマンド処理装置へのコマンドの送信，送信されたコマンドの実行結果のコマンド処理装置からの受信，および受信された実行結果の処理要求装置への送信を行う。処理要求装置が所定条件を満足するときは、コマンドを受信するための準備処理をコマンド処理装置に命令すると共に、コマンド処理装置へのコマンドの直接送信を処理要求装置に命令することによって、コマンド処理装置と処理要求装置との間でコマンドおよび実行結果が直接やり取りされるように仕向ける。このため、コマンド処理装置と処理要求装置との間のデータ通信を、負荷を軽減しつつ的確に仲介することができる。

請求項２の発明に従うサーバは、請求項１に従属し、コマンド処理装置はコマンドをルータを通して受信し、準備処理は任意のポートの公開をルータに要求する処理である。

請求項３の発明に従うサーバは、請求項２に従属し、第１命令手段の命令に応じて公開されたポートの識別子をコマンド処理装置から取得する取得手段をさらに備え、第２命令手段は取得手段によって取得された識別子を含む宛先情報を命令に割り当てる。

コマンド処理装置がコマンドをルータを通して受信する場合、コマンド処理装置を通じて任意のポートをルータに公開させ、公開ポートの識別子をコマンド処理装置から取得し、そして公開ポートの識別子を含む宛先情報を処理要求装置に通知するので、処理要求装置は、コマンドをコマンド処理装置へ直接送信することができる。

請求項４の発明に従うサーバは、請求項１ないし３のいずれかに従属し、所定条件は処理要求装置の能力が閾値よりも高いという条件を含み、第２送信手段は実行結果に含まれるデータの量を処理要求装置の能力に応じて削減する削減手段を含む。

処理要求装置の能力が低いときには、受信された実行結果に含まれるデータの量を処理要求装置の能力に応じて削減するので、能力の低い処理要求装置であっても、無理なく実行結果を利用できる。

請求項５の発明に従うサーバは、請求項４に従属し、能力は表示能力を含み、実行結果は画像データを含み、削減手段は画像データを表示能力に応じてリサイズする。これにより、表示能力の低い処理要求装置であっても、無理なく画像を表示できる。

請求項６の発明に従うサーバは、請求項１ないし５のいずれかに従属し、送信依頼には複数のユーザ識別子のいずれかが含まれ、複数のユーザ識別子と複数のユーザ識別子の各々に割り当てられたサービス種別とを少なくとも含む顧客情報を登録する登録手段、判別手段が判別を行う前に送信依頼からユーザ識別子を抽出する抽出手段、抽出手段によって抽出されたユーザ識別子に割り当てられたサービス種別を顧客情報に基づいて特定する特定手段、および特定手段の特定結果が第１種別を示すとき判別手段，第１送信手段，受信手段および第２送信手段を無効化する第１無効化手段をさらに備え、第１命令手段は第１無効化手段による無効化が行われたとき命令を行う。

送信依頼には複数のユーザ識別子のいずれかが含まれており、登録手段は、複数のユーザ識別子と複数のユーザ識別子の各々に割り当てられたサービス種別とを少なくとも含む顧客情報を登録する。判別手段が判別を行う前に抽出手段が送信依頼からユーザ識別子を抽出し、特定手段は、抽出手段によって抽出されたユーザ識別子に割り当てられたサービス種別を顧客情報に基づいて特定する。かかる特定手段の特定結果が第１種別を示すとき、第１無効化手段によって判別手段，第１送信手段，受信手段および第２送信手段が無効化される。第１命令手段は、第１無効化手段による無効化が行われたとき命令を行う。

送信依頼に含まれるユーザ識別子に割り当てられたサービス種別が第１種別であれば、処理要求装置が所定条件を満足するか否かに関わらず、コマンドをコマンド処理装置に送信し、送信されたコマンドの実行結果をコマンド処理装置から受信し、そして受信された実行結果を処理要求装置に送信する。

請求項７の発明に従うサーバは、請求項６に従属し、特定手段の特定結果が第２種別を示すとき第１命令手段および第２命令手段を無効化する第２無効化手段をさらに備え、第１送信手段は第２無効化手段による無効化が行われたとき送信を行う。

送信依頼に含まれるユーザ識別子に割り当てられたサービス種別が第２種別であれば、処理要求装置が所定条件を満足するか否かに関わらず、コマンドを受信するための準備処理をコマンド処理装置に命令すると共に、コマンド処理装置へのコマンドの直接送信を処理要求装置に命令する。

請求項６および７に従えば、ユーザの好みによって、常に“サーバ経由”で通信を行うこともでき、また、常に“サーバ非経由”で通信を行うこともできる。

請求項８の発明に従うサーバは、コマンド処理装置へのコマンドの送信を依頼する送信依頼を処理要求装置から受け付けたときコマンドの実行結果に含まれるデータの量が閾値よりも多いか否かを判別するデータ量判別手段、データ量判別手段の判別結果が否定的であるときコマンドをコマンド処理装置に送信する第１送信手段、第１送信手段によって送信されたコマンドの実行結果をコマンド処理装置から受信する受信手段、受信手段によって受信された実行結果を処理要求装置に送信する第２送信手段、データ量判別手段の判別結果が肯定的であるときコマンドを受信するための準備処理をコマンド処理装置に命令する第１命令手段、および第１命令手段の命令に関連してコマンド処理装置へのコマンドの直接送信を処理要求装置に命令する第２命令手段を備える。

データ量判別手段は、コマンド処理装置へのコマンドの送信を依頼する送信依頼を処理要求装置から受け付けたとき、コマンドの実行結果に含まれるデータの量が閾値よりも多いか否かを判別する。データ量判別手段の判別結果が否定的であるとき、第１送信手段がコマンドをコマンド処理装置に送信する。受信手段は、第１送信手段によって送信されたコマンドの実行結果をコマンド処理装置から受信し、第２送信手段は、受信手段によって受信された実行結果を処理要求装置に送信する。データ量判別手段の判別結果が肯定的であるとき、コマンドを受信するための準備処理を第１命令手段がコマンド処理装置に命令し、第２命令手段は、かかる第１命令手段の命令に関連して、コマンド処理装置へのコマンドの直接送信を処理要求装置に命令する。

コマンドの実行結果に含まれるデータの量が閾値以下のときは、コマンド処理装置へのコマンドの送信，送信されたコマンドの実行結果のコマンド処理装置からの受信，および受信された実行結果の処理要求装置への送信を行う。コマンドの実行結果に含まれるデータの量が閾値よりも多いときは、コマンドを受信するための準備処理をコマンド処理装置に命令すると共に、コマンド処理装置へのコマンドの直接送信を処理要求装置に命令することによって、コマンド処理装置と処理要求装置との間でコマンドおよび実行結果が直接やり取りされるように仕向ける。このため、コマンド処理装置と処理要求装置との間のデータ通信を、負荷を軽減しつつ的確に仲介することができる。

請求項９の発明に従うサーバは、請求項８に従属し、データ量判別手段が判別を行う前に負荷が第１閾値を下回っているか否かを判別する負荷判別手段、および負荷判別手段の判別結果が肯定的であるときデータ量判別手段を無効化する第１無効化手段をさらに備え、第１命令手段は負荷判別手段の判別結果が肯定的であるとき命令を行う。

負荷判別手段は、データ量判別手段が判別を行う前に、負荷が第１閾値を下回っているか否かを判別する。第１無効化手段は、負荷判別手段の判別結果が肯定的であるとき、データ量判別手段を無効化する。第１送信手段は、課金判別手段の判別結果が肯定的であるとき送信を行う。

負荷が閾値を下回っていると判別されたとき、データ量判別手段が無効化され、このため第１命令手段による命令および第２命令手段による命令はいずれも行われない。一方で第１送信手段が送信を行い、これに伴って受信手段による受信および第２送信手段による送信も実行される。

負荷が軽いときには、データ量の多少に関わらず“サーバ経由”で通信が行われるので、実行結果に必要な処理を施すことができる。

請求項１０の発明に従うサーバは、請求項９に従属し、負荷判別手段が判別を行う前にコマンドに従う処理が課金対象であるか否かを判別する課金判別手段、および課金判別手段の判別結果が肯定的であるときデータ量判別手段および負荷判別手段を無効化する第２無効化手段をさらに備え、第１命令手段は課金判別手段の判別結果が肯定的であるとき命令を行う。

課金判別手段は、負荷判別手段が判別を行う前に、コマンドに従う処理が課金対象であるか否かを判別する。第２無効化手段は、課金判別手段の判別結果が肯定的であるとき、データ量判別手段および負荷判別手段を無効化する。第１送信手段は、課金判別手段の判別結果が肯定的であるとき送信を行う。

コマンドに従う処理が課金対象であると判別されたとき、データ量判別手段および負荷判別手段が共に無効化され、このため第１命令手段による命令および第２命令手段による命令はいずれも行われない。一方で第１送信手段が送信を行い、これに伴って受信手段による受信および第２送信手段による送信も実行される。

コマンドに従う処理が課金対象であれば、負荷の大小やデータ量の多少に関わらず“サーバ経由”で通信が行われるので、課金を的確に行うことができる。

請求項１１の発明に従う仲介方法は、コマンド処理装置と処理要求装置との間のデータ通信を仲介する方法であって、コマンド処理装置へのコマンドの送信を依頼する送信依頼を処理要求装置から受け付けたとき処理要求装置が所定条件を満足するか否かを判別する判別ステップ、判別ステップの判別結果が否定的であるときコマンドをコマンド処理装置に送信する第１送信ステップ、第１送信ステップによって送信されたコマンドの実行結果をコマンド処理装置から受信する受信ステップ、受信ステップによって受信された実行結果を処理要求装置に送信する第２送信ステップ、判別ステップの判別結果が肯定的であるときコマンドを受信するための準備処理をコマンド処理装置に命令する第１命令ステップ、および第１命令ステップの命令に関連してコマンド処理装置へのコマンドの直接送信を処理要求装置に命令する第２命令ステップを備える。

請求項１２の発明に従う制御プログラムは、コマンド処理装置と処理要求装置との間のデータ通信を仲介するサーバのプロセサによって実行される制御プログラムであって、コマンド処理装置へのコマンドの送信を依頼する送信依頼を処理要求装置から受け付けたとき処理要求装置が所定条件を満足するか否かを判別する判別ステップ、判別ステップの判別結果が否定的であるときコマンドをコマンド処理装置に送信する第１送信ステップ、第１送信ステップによって送信されたコマンドの実行結果をコマンド処理装置から受信する受信ステップ、受信ステップによって受信された実行結果を処理要求装置に送信する第２送信ステップ、判別ステップの判別結果が肯定的であるときコマンドを受信するための準備処理をコマンド処理装置に命令する第１命令ステップ、および第１命令ステップの命令に関連してコマンド処理装置へのコマンドの直接送信を処理要求装置に命令する第２命令ステップを備える。

請求項１３の発明に従う仲介方法は、コマンド処理装置と処理要求装置との間のデータ通信を仲介する方法であって、コマンド処理装置へのコマンドの送信を依頼する送信依頼を処理要求装置から受け付けたときコマンドの実行結果に含まれるデータの量が第１閾値よりも多いか否かを判別するデータ量判別ステップ、データ量判別ステップの判別結果が否定的であるときコマンドをコマンド処理装置に送信する第１送信ステップ、第１送信ステップによって送信されたコマンドの実行結果をコマンド処理装置から受信する受信ステップ、受信ステップによって受信された実行結果を処理要求装置に送信する第２送信ステップ、データ量判別ステップの判別結果が肯定的であるときコマンドを受信するための準備処理をコマンド処理装置に命令する第１命令ステップ、および第１命令ステップの命令に関連してコマンド処理装置へのコマンドの直接送信を処理要求装置に命令する第２命令ステップを備える。

請求項１４の発明に従う制御プログラムは、コマンド処理装置と処理要求装置との間のデータ通信を仲介するサーバのプロセサによって実行される制御プログラムであって、コマンド処理装置へのコマンドの送信を依頼する送信依頼を処理要求装置から受け付けたときコマンドの実行結果に含まれるデータの量が第１閾値よりも多いか否かを判別するデータ量判別ステップ、データ量判別ステップの判別結果が否定的であるときコマンドをコマンド処理装置に送信する第１送信ステップ、第１送信ステップによって送信されたコマンドの実行結果をコマンド処理装置から受信する受信ステップ、受信ステップによって受信された実行結果を処理要求装置に送信する第２送信ステップ、データ量判別ステップの判別結果が肯定的であるときコマンドを受信するための準備処理をコマンド処理装置に命令する第１命令ステップ、および第１命令ステップの命令に関連してコマンド処理装置へのコマンドの直接送信を処理要求装置に命令する第２命令ステップを備える。

この発明によれば、コマンド処理装置と処理要求装置との間のデータ通信を、負荷を低減しつつ的確に仲介することができる。

この発明の上述の目的，その他の目的，特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。

図１を参照して、この実施例の監視カメラシステム１０は、クライアントであるＷｅｂカメラ１２と、サーバ１４とを含む。サーバ１４は、図示しない専用線を介してインターネット２０に接続され、Ｗｅｂカメラ１２は、ルータ１６およびＤＳＬモデム１８を介して同じインターネット２０に接続される。

なお、ルータ１６には、Ｗｅｂカメラ１２だけでなく、必要に応じて他のクライアント、たとえば情報家電，ＰＣなどが接続される。ルータ１６としては、ＵＰｎＰ（Universal Plug & Play）プロトコルに対応したタイプが用いられる。このタイプのルータは、クライアントの要求に応じて所望のポートを公開する機能を持つ。

インターネット２０にはさらに、各種の端末、この実施例では携帯電話２２ａおよびパーソナルコンピュータ（ＰＣ）２２ｂが、図示しないゲートウエイ，モデム等を介して接続される。

Ｗｅｂカメラ１２は、サーバ１４を通して、またはサーバ１４を通さずに直接、携帯電話２２ａおよびＰＣ２２ｂからの操作を受け付ける。具体的な操作としては、たとえば撮像ユニット２４およびカメラ処理回路２６を通して感度，ズーム倍率などを調節したり、図示しない駆動ユニットを介してＷｅｂカメラ１２の向きを制御したりする操作が挙げられる。

サーバ１４のハードディスク４４ｄにはデータベース（ＤＢ）が格納されており、サーバ１４は、このＤＢに基づいて認証，振り分け，仲介などの処理を実行する。ＤＢは、具体的には、図２に示す顧客情報ＤＢ，図３に示す端末情報ＤＢ，および図４に示すクライアント情報ＤＢを含む。

図２を参照して、顧客情報ＤＢには、顧客登録された一人一人のユーザについて、サービス種別，ユーザＩＤおよびパスワードが登録される。サービスＡを利用するユーザには、端末・クライアント間で通信を行う方式として、常に“サーバ非経由”方式が適用される。サービスＢを利用するユーザには、携帯電話２２ａからアクセスしたときは“サーバ経由”方式が適用され、ＰＣ２２ｂからアクセスしたときは“サーバ非経由”方式が適用される。サービスＣを利用するユーザには、常に“サーバ経由”方式が適用される。ユーザＩＤおよびパスワードは、サーバ１４にアクセスしてきたユーザが正規のユーザか否かを判別する認証処理に利用される。

図３を参照して、端末情報ＤＢには、ユーザが利用する各種の端末について、能力を示すパラメータ、この実施例では表示能力つまりモニタ画面の最大解像度が登録される。最大解像度は、クライアントから受信した実行結果を端末に送信するとき、実行結果に含まれる画像のサイズを端末画面に適合させるリサイズ処理を行うのに利用される。

なお、端末情報ＤＢには、最大解像度に代えて、またはこれと共に、通信速度，処理速度，記憶容量などを登録してもよい。つまり端末情報ＤＢには、端末の能力を示す１つまたは複数のパラメータが登録される。サーバ１４は、登録された１つまたは複数のパラメータに基づいて、実行結果を個々の端末に最適化する最適化処理を実行する。最適化処理の具体例としては、リサイズ処理のほか、フレームレートの変換，圧縮率の変更といった処理が挙げられる。

図４を参照して、クライアント情報ＤＢには、ルータ１６に接続された１台１台のクライアントについて、ＩＰアドレスおよびポート番号が登録される。クライアント・端末間の通信方式として“サーバ経由”が選択された場合、サーバ１４は、クライアント情報ＤＢに登録されたＩＰアドレスおよびポート番号に基づいて、端末から受信したコマンドをクライアントに送信する。

一方、通信方式として“サーバ非経由”が選択された場合には、サーバ１４は、任意のポートの公開をルータ１６に要求するポート公開要求の発行をクライアントに命令し、公開されたポートの番号をクライアントから取得し、そして、取得された公開ポート番号と、クライアント情報ＤＢに登録されたＩＰアドレスとを端末に通知する。端末は、通知されたアドレスおよびポート番号で特定される宛先にコマンドを送信する。

図５（Ａ）には、“サーバ経由”方式に従う通信プロトコルが示され、図６（Ａ）には、“サーバ非経由”方式に従う通信プロトコルが示されている。ここでは、ユーザに“サービスＢ”が割り当てられており、このため、ユーザが携帯電話２２ａからサーバ１４にアクセスしたときは“サーバ経由”方式が選択され、ＰＣ２２ｂからアクセスしたときは“サーバ非経由”方式が選択される。

まず図５（Ａ）を参照して、携帯電話２２ａから送信されたアクセスパケットは、サーバ１４によって受信される。アクセスパケットのデータ領域には、図５（Ｂ）に示されるように、ユーザＩＤ，端末種別，パスワードおよびコマンド送信依頼が格納されている。なお、携帯電話２２ａのように特定のユーザしか利用しない端末の場合、ヘッダ領域に記述された機器ＩＤをユーザＩＤとして利用すれば、データ領域からユーザＩＤを省略することもできる。つまりユーザは、アクセス時に自分のＩＤを端末に入力する手間が省ける。

サーバ１４は、受信されたアクセスパケットからユーザＩＤ，端末種別，パスワードおよびコマンド送信依頼などの情報を抽出し、抽出情報をＲＡＭ３６に保持する。なお、ＲＡＭ３６内の情報は、ハードディスクドライブ（ＨＤＤ）４４によって随時バックアップされる（以下同様）。そして、クライアント情報ＤＢ（図４参照）に記載されたＩＰアドレス／ポート番号に基づいて、クライアントに“コマンド有り”を通知する。

通知後、サーバ１４は、抽出されたユーザＩＤをキーとして顧客情報ＤＢ（図２参照）を検索することよりサービス種別を特定し、特定されたサービス種別および抽出された端末種別に基づいて通信方式を決定する。この場合、サービス種別が“Ｂ”、端末種別が“携帯電話”なので、通信方式は“サーバ経由”に決定される。

通知を受けたクライアント（Ｗｅｂカメラ１２）は、サーバ１４との間でＴＣＰ（Transmission Control Protocol）接続を確立した後、コマンドをサーバ１４に要求する。要求を受けたサーバ１４は、通信方式が“サーバ経由”なので、ＲＡＭ３６に格納された送信依頼に従うコマンドをクライアントに送信する。

クライアントは、コマンドに従う処理を実行し、そして実行結果をサーバ１４に送信する。サーバ１４は、実行結果を受信し、受信された実行結果を携帯電話２２ａに送信する。その際サーバ１４は、端末情報ＤＢ（図３参照）を参照して、実行結果に含まれる画像のサイズが携帯電話２２ａのモニタ画面（図示せず）の解像度に適合するか否かを判別し、適合しなければ画像にリサイズ処理を施す。携帯電話２２ａは、送信された実行結果を受信し、受信された実行結果をモニタ画面に表示する。

図６（Ａ）を参照して、ＰＣ２２ｂから送信されたアクセスパケットは、サーバ１４によって受信される。アクセスパケットのデータ領域には、図６（Ｂ）に示されるように、ユーザＩＤ，端末種別，パスワードおよびコマンド送信依頼が格納されている。

サーバ１４は、受信されたアクセスパケットから情報を抽出し、抽出情報をＲＡＭ３６に保持し、そしてクライアントに“コマンド有り”を通知する。通知後、サーバ１４は、サービス種別を特定し、通信方式を決定する。この場合、サービス種別が“Ｂ”、端末種別が“ＰＣ”なので、通信方式は“サーバ非経由”に決定される。

“コマンド有り”通知を受けたクライアントは、コマンドをサーバ１４に要求する。要求を受けたサーバ１４は、通信方式が“サーバ非経由”なので、コマンドを送信する代わりに、“ポート公開要求”の発行をクライアントに命令する。

“ポート公開要求”の発行命令を受けたクライアントは、ルータ１６に任意のポートの公開を要求する。ルータ１６は、要求に従ってポートを公開する。その後、クライアントは、ポート通知パケットをサーバ１４送信する。ポート通知パケットのデータ領域には、図６（Ｃ）に示されるように、公開されたポートの番号が記述される。

サーバ１４は、ポート通知パケットを受信し、ＰＣ２２ｂにリダイレクト命令パケットを送信する。リダイレクト命令パケットのデータ領域には、図６（Ｄ）に示されるように、クライアントのＩＰアドレスと、ポート通知パケットから抽出された公開ポート番号と、リダイレクト命令とが記述される。なお、ＩＰアドレスは、クライアント情報ＤＢ（図４参照）から読み取られる。

ＰＣ２２ｂは、リダイレクト命令パケットを受信し、コマンドをクライアントに送信する。コマンドの送信は、リダイレクト命令パケットから抽出されたＩＰアドレスおよびポート番号によって特定される宛先に向けて行われる。

クライアントは、コマンドに従う処理を実行し、そして実行結果をＰＣ２２ｂに送信する。ＰＣ２２ｂは、送信された実行結果を受信し、受信された実行結果に基づく画像をモニタ画面（図示せず）に表示する。以降、公開ポートが閉鎖されるまでの間、ＰＣ２２ｂは、コマンドを直接クライアントに送信し、実行結果を直接クライアントから受信することができる。

サーバ１４のＣＰＵ４２は、具体的には、図７および図８に示された認証／振り分けタスクと、図９に示された仲介タスクとを実行する。認証／振り分けタスクは常時起動されており、ＣＰＵ４２は、認証／振り分けタスクに従って、端末からアクセスを受けたとき認証を行い、そして認証が成立したとき振り分け処理を実行する。仲介タスクは、振り分け処理の完了後に起動される。認証／振り分けタスクおよび仲介タスクが起動された状態では、ＣＰＵ４２は、μＩＴＲＯＮのようなマルチタスクＯＳの制御下で、２つのタスクを並列的に処理する。なお、これらのフロー図に対応する制御プログラムは、ＲＯＭ３８に格納される。

図７を参照して、ステップＳ１でＣＰＵ４２は、ネットワークコントローラ４０を通してアクセスパケット（図５（Ｂ），図６（Ｂ）参照）を受信したか否かを判別する。アクセスパケットが受信されると、ステップＳ３に移って、アクセスパケットからユーザＩＤ，端末種別，パスワードおよびコマンド送信依頼を抽出する。抽出された情報は、ＲＡＭ３６に保持される。

ステップＳ５では、顧客情報ＤＢ（図２参照）を検索して、ユーザＩＤおよびパスワードによる認証処理を行う。ステップＳ７では、認証が成立するか否かが判別される。具体的には、アクセスパケットから抽出されたユーザＩＤおよびパスワードが顧客情報ＤＢの登録情報と一致するか否かが判別され、一致したとき認証が成立する。認証が成立しなければ、ステップＳ１３で端末にエラーを通知し、その後ステップＳ１に戻る。

認証が成立すると、ステップＳ７からステップＳ９に移り、振り分け処理（後述）を行う。振り分け処理が完了すると、ステップＳ１１で仲介タスクを起動し、その後ステップＳ１に戻る。

ステップＳ９の振り分け処理は、図８に示すサブルーチンに従う。図８を参照して、ステップＳ２１でＣＰＵ４２は、顧客情報ＤＢ（図２参照）を検索して、サービス種別を特定する。具体的には、顧客情報ＤＢから、ステップＳ３で抽出されたユーザＩＤに対応するサービス種別が読み取られる。

ステップＳ２３およびＳ２５では、読み取られたサービス種別が“Ａ”，“Ｂ”および“Ｃ”のどれであるかが判別される。サービス種別が“Ａ”であれば、ステップＳ２３からステップＳ２９に移って、通信方式を“サーバ非経由”に決定する。サービス種別が“Ｂ”であれば、ステップＳ２５からステップＳ２７に移る。サービス種別が“Ｃ”であれば、ステップＳ２５からステップＳ３１に移って、通信方式を“サーバ経由”に決定する。

ステップＳ２７では、読み取られた端末種別がＰＣか否かが判別され、判別結果が肯定的であればステップＳ２９に移って、通信方式を“サーバ非経由”に決定する。判別結果が否定的であれば、ステップＳ３１に移って通信方式を“サーバ経由”に決定する。

つまり、サービス種別が“Ａ”であれば端末種別に関わりなく通信方式は“サーバ非経由”に決定され、サービス種別が“Ｃ”であれば端末種別によらず通信方式は“サーバ経由”に決定される。サービス種別が“Ｂ”の場合、端末種別がＰＣであれば通信方式は“サーバ非経由”に決定され、端末種別が携帯電話であれば通信方式は“サーバ経由”に決定される。

こうして決定された通信方式を示す情報は、ＣＰＵ４２内のレジスタＲに保持される。決定後、ＣＰＵ４２は、上位層のルーチンに復帰する。

図９を参照して、仲介タスクが起動されると、ＣＰＵ４２は、ステップＳ４１でクライアントに“コマンド有り”を通知し、ステップＳ４３でクライアントからのコマンド要求を待つ。ネットワークコントローラ４０を通じてコマンド要求が受信されると、ステップＳ４５に移って、通信方式が“サーバ非経由”であるか否かを判別する。判別は、レジスタＲを参照して行われる。この判別の結果が肯定的であればステップＳ４７〜Ｓ５１を実行し、否定的であればステップＳ５３〜Ｓ６３を実行する。

ステップＳ４７では、“ポート公開要求”の発行をクライアントに命令する。ステップＳ４９では、クライアントからポート通知パケット（図６（Ｃ）参照）が送られてくるのを待つ。ポート通知パケットが受信されると、ステップＳ５１で端末にリダイレクト命令パケット（図６（Ｄ）参照）を送信する。リダイレクト命令パケットの送信後、このタスクは終了される。

ステップＳ５３では、クライアントにコマンドを送信する。ステップＳ５５では、クライアントから実行結果が送られてくるのを待つ。実行結果が受信されるとステップＳ５７に移り、端末情報ＤＢ（図３参照）を検索して端末の最大解像度を特定する。具体的には、端末情報ＤＢから、ステップＳ３で抽出された端末種別に対応する最大解像度が読み取られる。ステップＳ５９では、受信された実行結果に含まれる画像のサイズが、特定された最大解像度を超えていないかどうかを確認する。

画像サイズが最大解像度以内に収まっていれば、ステップＳ６３に進む。画像サイズが最大解像度を超えている場合には、ステップＳ６１でリサイズ処理を行い、その後ステップＳ６３に移る。ステップＳ６３では、端末に実行結果を送信する。実行結果の送信後、このタスクは終了される。

クライアント（Ｗｅｂカメラ１２）のＣＰＵ２８は、具体的には、図１０に示されたコマンド実行タスクに従ってコマンドに従う処理を実行する。コマンド実行タスクは、図示しない操作パネルを介して遠隔操作モードがオンされたとき起動され、遠隔操作モードがオフされたとき終了される。ＣＰＵ２８は、このタスクに従って、端末からサーバ経由でまたはサーバ非経由でコマンドを受け、コマンドに従う処理を実行し、そして実行結果をサーバ経由でまたはサーバ非経由で端末に送信する。コマンド実行タスクを含む複数のタスクが起動された状態では、ＣＰＵ２８は、μＩＴＲＯＮのようなマルチタスクＯＳの制御下で、複数のタスクを並列的に処理する。なお、このフロー図に対応する制御プログラムは、フラッシュメモリ３０に格納される。

図１０を参照して、ステップＳ８１でＣＰＵ２８は、サーバ１４から“コマンド有り”の通知を受けたか否かを判別する。通知を受けると、ステップＳ８３に移って、サーバ１４にコマンドを要求する。その後、ステップＳ８５およびＳ８７のループに入る。ステップＳ８５では、サーバ１４からのコマンドを受信したか否かを判別し、ステップＳ８７では、“ポート公開要求”の発行命令を受けたか否かを判別する。

サーバ１４からのコマンドを受信すると、ステップＳ８５でＹＥＳと判別し、ステップＳ８９に移って、コマンドに従う処理を実行する。次のステップＳ９１では、サーバ１４に実行結果を送信し、その後、ステップＳ８１に戻る。

“ポート公開要求”の発行命令を受けると、ステップＳ８７でＹＥＳと判別し、ステップＳ９３に移って、ルータ１６に任意のポートの公開を要求する。ステップＳ９５では、公開ポートの番号をサーバ１４に通知する。その後、ステップＳ９７およびＳ９９のループに入る。ステップＳ９７では、端末からのコマンドを受信したか否かを判別し、ステップＳ９９では、終了イベントが発生したか否かを判別する。

端末からのコマンドを受信すると、ステップＳ９７でＹＥＳと判別し、ステップＳ１０３に移ってコマンドに従う処理を実行する。次のステップＳ１０５では、端末に実行結果を送信し、その後、ステップＳ９７およびＳ９９のループに戻る。終了イベントが発生すると、ルータ１６に公開ポートの閉鎖を要求し、その後ステップＳ８１に戻る。なお、終了イベントとしては、端末またはサーバ１４からの終了通知の受信，タイムアウトの検出などがある。

以上から明らかなように、この実施例のサーバ１４は、端末（携帯電話２２ａ，ＰＣ２２ｂ）からのアクセスを受け付けたとき、端末のユーザに割り当てられたサービスの種別と、端末の種別つまり端末の能力とに基づいて、“サーバ経由”方式および“サーバ非経由”方式のいずれかを選択する。

具体的には、サービス種別が“Ａ”であれば、端末種別に関係なく“サーバ非経由”が選択され、サービス種別が“Ｃ”であれば、端末種別に関係なく“サーバ経由”が選択される。サービス種別が“Ｂ”であれば、端末種別の判別が行われ、判別結果が携帯電話２２ａを示すとき“サーバ経由”が選択される。判別結果がＰＣ２２ｂを示すときには“サーバ非経由”が選択される。

つまり、表示，情報処理，通信などの能力が高いＰＣ２２ｂからのアクセスに対しては“サーバ非経由”が選択され、能力の低い携帯電話２２ａからのアクセスに対しては“サーバ経由”が選択される。ユーザの好みによっては、かかる端末の能力に基づく自動選択は行わず、ＰＣ２２ｂからのアクセスであっても携帯電話２２ａからのアクセスであっても常に“サーバ非経由”が選択されるような設定が可能であり、また、常に“サーバ非経由”が選択されるような設定も可能である。

“サーバ経由”方式を選択したとき、サーバ１４は、コマンドをクライアント（Ｗｅｂカメラ１２）に送信し、コマンドに従う処理の実行結果をクライアントから受信し、そして受信された実行結果を端末に送信する。

“サーバ非経由”方式を選択したとき、サーバ１４は、まずコマンドを受信するための準備処理をクライアントに命令する。具体的には、任意のポートの公開をルータ１６に要求するポート公開要求の発行をクライアントに命令する。次に、公開されたポートの番号をクライアントから取得し、そして、取得した番号を含む宛先情報によって特定される宛先へのコマンドの送信を端末に命令する。

“サーバ経由”方式を選択すれば、実行結果の端末への最適化を行うことができる。一方、サーバ非経由”方式を選択すれば、負荷を削減することができる。

このような２つの通信方式のどちらかが端末の能力に基づいて自動的に選択されるので、ユーザが面倒な操作を行わなくても、端末は無理なく実行結果を利用できる。具体的には、表示能力の低い携帯電話２２ａからアクセスを行ったとき“サーバ経由”が自動で選択され、サーバ１４において実行結果に含まれる画像がリサイズされるので、ユーザがスクロール操作を行わなくても、携帯電話２２ａは画像の全体をモニタ画面内に表示することができる。

なお、この実施例でサーバ１４は、端末の能力に基づいて“サーバ経由”方式および“サーバ非経由”方式のいずれかを選択したが、コマンドの実行結果に含まれるデータの量，負荷の大きさ，課金を行うか否か等に基づいて通信方式の選択を行うこともできる。以下には、かかる基準で選択を行う他の実施例を説明する。

この実施例が先の実施例と異なるのは、振り分け処理、および仲介タスクの一部だけである。よって、この実施例にも図１〜図７および図１０を援用し、重複する説明を省略する。図７のステップＳ９に示された振り分け処理は、図１１のサブルーチンに従う。同じくステップＳ１１に示された仲介タスクは、図１２のフローチャートに従って実行される。

図１１を参照して、ステップＳ１２１でＣＰＵ４２は、アクセスパケット（図５（Ｂ），図６（Ｂ）参照）から抽出されたコマンド送信依頼を解析する。ステップＳ１２３では、コマンドに従う処理が課金の対象であるか否かを判別する。課金対象であれば、ステップＳ１３３に進んで、通信方式を“サーバ経由”に決定する。

課金対象でなければ、ステップＳ１２５に移って、ＣＰＵ４２自身の現在の負荷が閾値Ｓを下回っているか否かを判別し、負荷が閾値Ｓを下回っていればステップＳ１３３に進んで、通信方式を“サーバ経由”に決定する。負荷が閾値Ｓに達していれば、ステップＳ１２７に移って、コマンドの実行結果に動画像が含まれるか否かを判別する。実行結果に動画像が含まれていればステップＳ１３１に進み、通信方式を“サーバ非経由”に決定する。

実行結果に動画像が含まれていなければステップＳ１２９に移り、実行結果に含まれるデータの量が閾値Ｔを超えているか否かをさらに判別する。データ量が閾値Ｔを超えていれば、ステップＳ１３１に進んで、通信方式を“サーバ非経由”に決定する。データ量が閾値Ｔを越えていなければ、ステップＳ１３３に進んで、通信方式を“サーバ経由”に決定する。

つまり、コマンドに従う処理が課金対象であれば、負荷やデータ量に関係なく“サーバ経由”方式が選択される。コマンドに従う処理が課金対象でなければ、ＣＰＵ４２にかかる負荷が軽いとき“サーバ経由”方式が選択される。ＣＰＵ４２にかかる負荷が重いときには、実行結果に動画が含まれるか、または実行結果のデータ量が多い場合に“サーバ非経由”方式が選択され、実行結果に動画が含まれず、かつ実行結果のデータ量が少ない場合には“サーバ経由”方式が選択される。

こうして決定された通信方式を示す情報は、ＣＰＵ４２内のレジスタＲに保持される。決定後、ＣＰＵ４２は、上位層のルーチンに復帰する。

図１２を参照して、ステップＳ４１〜Ｓ５５は、図９のステップＳ４１〜Ｓ５５と同様である。ＣＰＵ４２は、ステップＳ５５の判別結果が肯定的であるとき、ステップＳ５９ａに移る。ステップＳ５９ａでは、送信されたコマンドに従う処理が課金対象か否かを判別し、判別結果が肯定的であれば、ステップＳ６１ａで課金処理を行い、その後ステップＳ６３に移る。ここで課金は、ステップＳ３（図７参照）で抽出されたユーザＩＤに対応する顧客に対して行われる。

ステップＳ５９ａの判別結果が否定的であれば、直ちにステップＳ６３に移る。ステップＳ６３では、端末に実行結果を送信する。実行結果の送信後、このタスクは終了される。

この実施例では、サーバ１４は、“コマンドに従う処理が課金対象であれば、通信方式としてサーバ経由”を選択し、クライアント（Ｗｅｂカメラ１２）から受信した実行結果を端末（携帯電話２２ａ，ＰＣ２２ｂ）に送信するとき課金処理を行う。コマンドに従う処理が課金対象でなければ、ＣＰＵ４２の負荷が軽いとき“サーバ経由”方式を選択する。ＣＰＵ４２の負荷が重いときには、実行結果に動画が含まれるか、または実行結果のデータ量が多い場合に“サーバ非経由”方式を選択し、実行結果に動画が含まれず、かつ実行結果のデータ量が少ない場合には“サーバ経由”方式を選択する。

コマンドに従う処理が課金対象であれば、“サーバ経由”方式を選択することで確実に課金を行うことができ、課金対象でなければ、ＣＰＵ４２の負荷が大きいときに、実行結果に含まれるデータの態様やデータ量に応じて、適宜“サーバ非経由”方式を選択することによって、ＣＰＵ４２の負荷を軽減することが可能となる。

以上では、Ｗｅｂカメラ１２およびサーバ１４からなる監視カメラシステム１０について説明したが、この発明は、サーバとサーバから通知されるコマンドに従う処理を実行するコマンド処理装置（クライアント）とからなるあらゆる処理システムに適用することができる。

この発明の一実施例の構成を示すブロック図である。 顧客情報データベースを示す図解図である。 端末情報データベースを示す図解図である。 クライアント情報データベースを示す図解図である。 （Ａ）は“サーバ経由”方式に従う通信方式を示すシーケンス図であり、（Ｂ）はアクセスパケットの構成を示す図解図である。 （Ａ）は“サーバ非経由”方式に従う通信方式を示すシーケンス図であり、（Ｂ）はアクセスパケットの構成を示す図解図であり、（Ｃ）はポート通知パケットの構成を示す図解図であり、（Ｄ）はリダイレクト命令パケットの構成を示す図解図である。 サーバＣＰＵの動作の一部を示すフロー図である。 サーバＣＰＵの動作の他の一部を示すフロー図である。 サーバＣＰＵの動作のその他の一部を示すフロー図である。 クライアントＣＰＵの動作の一部を示すフロー図である。 他の実施例におけるサーバＣＰＵの動作の一部を示すフロー図である。 他の実施例におけるサーバＣＰＵの動作の他の一部を示すフロー図である。

符号の説明

１０…監視カメラシステム
１２…Ｗｅｂカメラ（クライアント）
１４…サーバ
１６…ルータ
２０…インターネット
２２ａ…携帯電話（端末）
２２ｂ…パーソナルコンピュータ（端末）
２８，４２…ＣＰＵ
３４，４０…ネットワークコントローラ

Claims (14)

1. コマンド処理装置へのコマンドの送信を依頼する送信依頼を処理要求装置から受け付けたとき前記処理要求装置が所定条件を満足するか否かを判別する判別手段、
   前記判別手段の判別結果が否定的であるとき前記コマンドを前記コマンド処理装置に送信する第１送信手段、
   前記第１送信手段によって送信された前記コマンドの実行結果を前記コマンド処理装置から受信する受信手段、
   前記受信手段によって受信された実行結果を前記処理要求装置に送信する第２送信手段、
   前記判別手段の判別結果が肯定的であるとき前記コマンドを受信するための準備処理を前記コマンド処理装置に命令する第１命令手段、および
   前記第１命令手段の命令に関連して前記コマンド処理装置への前記コマンドの直接送信を前記処理要求装置に命令する第２命令手段を備える、サーバ。
2. 前記コマンド処理装置は前記コマンドをルータを通して受信し、
   前記準備処理は任意のポートの公開を前記ルータに要求する処理である、請求項１記載のサーバ。
3. 前記第１命令手段の命令に応じて公開されたポートの識別子を前記コマンド処理装置から取得する取得手段をさらに備え、
   前記第２命令手段は前記取得手段によって取得された識別子を含む宛先情報を命令に割り当てる、請求項２記載のサーバ。
4. 前記所定条件は前記処理要求装置の能力が閾値よりも高いという条件を含み、
   前記第２送信手段は前記実行結果に含まれるデータの量を前記処理要求装置の能力に応じて削減する削減手段を含む、請求項１ないし３のいずれかに記載のサーバ。
5. 前記能力は表示能力を含み、
   前記実行結果は画像データを含み、
   前記適合化手段は前記画像データを前記表示能力に応じてリサイズする、請求項４記載のサーバ。
6. 前記送信依頼は複数のユーザ識別子のいずれか１つを含み、
   前記複数のユーザ識別子と前記複数のユーザ識別子の各々に割り当てられたサービス種別とを少なくとも含む顧客情報を登録する登録手段、
   前記判別手段が判別を行う前に前記送信依頼からユーザ識別子を抽出する抽出手段、
   前記抽出手段によって抽出されたユーザ識別子に割り当てられたサービス種別を前記顧客情報に基づいて特定する特定手段、および
   前記特定手段の特定結果が第１種別を示すとき前記判別手段，前記第１送信手段，前記受信手段および前記第２送信手段を無効化する第１無効化手段をさらに備え、
   前記第１命令手段は前記第１無効化手段による無効化が行われたとき命令を行う、請求項１ないし５のいずれかに記載のサーバ。
7. 前記特定手段の特定結果が第２種別を示すとき前記第１命令手段および前記第２命令手段を無効化する第２無効化手段をさらに備え、
   前記第１送信手段は前記第２無効化手段による無効化が行われたとき送信を行う、請求項６記載のサーバ。
8. コマンド処理装置へのコマンドの送信を依頼する送信依頼を処理要求装置から受け付けたとき前記コマンドの実行結果に含まれるデータの量が第１閾値よりも多いか否かを判別するデータ量判別手段、
   前記データ量判別手段の判別結果が否定的であるとき前記コマンドを前記コマンド処理装置に送信する第１送信手段、
   前記第１送信手段によって送信された前記コマンドの実行結果を前記コマンド処理装置から受信する受信手段、
   前記受信手段によって受信された実行結果を前記処理要求装置に送信する第２送信手段、
   前記データ量判別手段の判別結果が肯定的であるとき前記コマンドを受信するための準備処理を前記コマンド処理装置に命令する第１命令手段、および
   前記第１命令手段の命令に関連して前記コマンド処理装置への前記コマンドの直接送信を前記処理要求装置に命令する第２命令手段を備える、サーバ。
9. 前記データ量判別手段が判別を行う前に負荷が第２閾値を下回っているか否かを判別する負荷判別手段、および
   前記負荷判別手段の判別結果が肯定的であるとき前記データ量判別手段を無効化する第１無効化手段をさらに備え、
   前記第１送信手段は前記負荷判別手段の判別結果が肯定的であるとき送信を行う、請求項８記載のサーバ。
10. 前記負荷判別手段が判別を行う前に前記コマンドに従う処理が課金対象であるか否かを判別する課金判別手段、および
    前記課金判別手段の判別結果が肯定的であるとき前記データ量判別手段および前記負荷判別手段を無効化する第２無効化手段をさらに備え、
    前記第１送信手段は前記課金判別手段の判別結果が肯定的であるとき送信を行う、請求項９記載のサーバ。
11. コマンド処理装置と処理要求装置との間のデータ通信を仲介する方法であって、
    前記コマンド処理装置へのコマンドの送信を依頼する送信依頼を前記処理要求装置から受け付けたとき前記処理要求装置が所定条件を満足するか否かを判別する判別ステップ、
    前記判別ステップの判別結果が否定的であるとき前記コマンドを前記コマンド処理装置に送信する第１送信ステップ、
    前記第１送信ステップによって送信された前記コマンドの実行結果を前記コマンド処理装置から受信する受信ステップ、
    前記受信ステップによって受信された実行結果を前記処理要求装置に送信する第２送信ステップ、
    前記判別ステップの判別結果が肯定的であるとき前記コマンドを受信するための準備処理を前記コマンド処理装置に命令する第１命令ステップ、および
    前記第１命令ステップの命令に関連して前記コマンド処理装置への前記コマンドの直接送信を前記処理要求装置に命令する第２命令ステップを備える、仲介方法。
12. コマンド処理装置と処理要求装置との間のデータ通信を仲介するサーバのプロセサによって実行される制御プログラムであって、
    前記コマンド処理装置へのコマンドの送信を依頼する送信依頼を前記処理要求装置から受け付けたとき前記処理要求装置が所定条件を満足するか否かを判別する判別ステップ、
    前記判別ステップの判別結果が否定的であるとき前記コマンドを前記コマンド処理装置に送信する第１送信ステップ、
    前記第１送信ステップによって送信された前記コマンドの実行結果を前記コマンド処理装置から受信する受信ステップ、
    前記受信ステップによって受信された実行結果を前記処理要求装置に送信する第２送信ステップ、
    前記判別ステップの判別結果が肯定的であるとき前記コマンドを受信するための準備処理を前記コマンド処理装置に命令する第１命令ステップ、および
    前記第１命令ステップの命令に関連して前記コマンド処理装置への前記コマンドの直接送信を前記処理要求装置に命令する第２命令ステップを備える、制御プログラム。
13. コマンド処理装置と処理要求装置との間のデータ通信を仲介する方法であって、
    前記コマンド処理装置へのコマンドの送信を依頼する送信依頼を前記処理要求装置から受け付けたとき前記コマンドの実行結果に含まれるデータの量が第１閾値よりも多いか否かを判別するデータ量判別ステップ、
    前記データ量判別ステップの判別結果が否定的であるとき前記コマンドを前記コマンド処理装置に送信する第１送信ステップ、
    前記第１送信ステップによって送信された前記コマンドの実行結果を前記コマンド処理装置から受信する受信ステップ、
    前記受信ステップによって受信された実行結果を前記処理要求装置に送信する第２送信ステップ、
    前記データ量判別ステップの判別結果が肯定的であるとき前記コマンドを受信するための準備処理を前記コマンド処理装置に命令する第１命令ステップ、および
    前記第１命令ステップの命令に関連して前記コマンド処理装置への前記コマンドの直接送信を前記処理要求装置に命令する第２命令ステップを備える、仲介方法。
14. コマンド処理装置と処理要求装置との間のデータ通信を仲介するサーバのプロセサによって実行される制御プログラムであって、
    前記コマンド処理装置へのコマンドの送信を依頼する送信依頼を前記処理要求装置から受け付けたとき前記コマンドの実行結果に含まれるデータの量が第１閾値よりも多いか否かを判別するデータ量判別ステップ、
    前記データ量判別ステップの判別結果が否定的であるとき前記コマンドを前記コマンド処理装置に送信する第１送信ステップ、
    前記第１送信ステップによって送信された前記コマンドの実行結果を前記コマンド処理装置から受信する受信ステップ、
    前記受信ステップによって受信された実行結果を前記処理要求装置に送信する第２送信ステップ、
    前記データ量判別ステップの判別結果が肯定的であるとき前記コマンドを受信するための準備処理を前記コマンド処理装置に命令する第１命令ステップ、および
    前記第１命令ステップの命令に関連して前記コマンド処理装置への前記コマンドの直接送信を前記処理要求装置に命令する第２命令ステップを備える、制御プログラム。

Images