JP3654360B2 - 制御システムおよび方法、情報処理装置および方法、情報処理端末および方法、記録媒体、並びにプログラム - Google Patents
制御システムおよび方法、情報処理装置および方法、情報処理端末および方法、記録媒体、並びにプログラム Download PDFInfo
- Publication number
- JP3654360B2 JP3654360B2 JP2002349994A JP2002349994A JP3654360B2 JP 3654360 B2 JP3654360 B2 JP 3654360B2 JP 2002349994 A JP2002349994 A JP 2002349994A JP 2002349994 A JP2002349994 A JP 2002349994A JP 3654360 B2 JP3654360 B2 JP 3654360B2
- Authority
- JP
- Japan
- Prior art keywords
- information processing
- message
- processing terminal
- server
- communication
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
- H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
- H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
Description
【０００１】
【発明の属する技術分野】
本発明は、制御システムおよび方法、情報処理装置および方法、情報処理端末および方法、記録媒体、並びにプログラムに関し、特に、ネットワークを介して接続される機器の制御を、より確実に、かつ効率的に行うことができるようにする制御システムおよび方法、情報処理装置および方法、情報処理端末および方法、記録媒体、並びにプログラムに関する。
【０００２】
【従来の技術】
近年、携帯電話機などの通信端末を利用して、遠隔地に設置されている機器を制御するシステムが各種提案されている。
【０００３】
そのようなシステムとして、例えば、特許文献１には、外出先（外部）から電話で送信される暗証番号によって、家庭内に設置されたエアーコンディショナやビデオ録画装置などの家電製品を制御するシステムが開示されている。
【０００４】
また、特許文献２には、制御端末と被制御端末の間にサーバが設置されており、そのサーバを経由して、制御端末が被制御端末の動作を制御するシステムが開示されている。
【０００５】
ところで、これらの制御システムにおいては、遠隔制御される装置が何らかの通信手段により常時接続されており、遠隔にある端末から必ず接続できる環境にあることを前提としている（例えば、特許文献１のシステムにおいては、家電製品がリモートコントローラおよびアダプタを介して電話回線に常時接続されている）。
【０００６】
このように、制御する側の第１の装置と、制御される側の第２の装置が常に通信を行うことができる環境にある場合、いずれの装置も、自分自身が主導となって通信を開始させることが可能である。例えば、第１の装置から第２の装置に対してリクエストを含む各種のデータを任意のタイミングで送信したり、反対に、第２の装置から第１の装置に対して各種のデータを送信したりすることが可能である。
【０００７】
従って、ネットワークを介して通信を行うことにより、どのタイミングであっても、装置を直接制御することができる。
【０００８】
【特許文献１】
特開２０００−１８４０８１号公報
【特許文献２】
特開２００２−４１３７８号公報
【０００９】
【発明が解決しようとする課題】
しかしながら、このように、ネットワークに常時接続されている環境にない、例えば、ICカード、ディスプレイ、或いは、メモリなどのデバイスを遠隔操作する場合、それらのデバイスを管理するパーソナルコンピュータなどのクライアントからサーバにリクエストが送信され、サーバから返信されるリクエストの結果に基づいて、デバイスが操作されるという仕組みが一般的であり、サーバが主導となり、デバイスを直接操作するということが困難であるという課題があった。
【００１０】
すなわち、デバイスがネットワークに常時接続されていないため、サーバからクライアントに任意のタイミングでアクセスし、サーバが主導となり、クライアントにより管理されているデバイスを制御することができない。
【００１１】
具体的には、ネットワークに接続されている装置（例えば、ICカードリーダライタやRF-ID受信装置）に近接または載置されることにより、所定のタイミングでサーバに接続されるICカードや非接触RF-IDなどのデバイスに対して、サーバが主導となって、デバイスの属性を変更させたり、または、デバイスを操作したりすることは非常に困難である。
【００１２】
また、従来の制御システムにおいては、サーバ−クライアント間でコマンドやレスポンスを送受信する場合、一般的に、１コマンド毎に、または１レスポンス毎に送受信が行われるため、サーバ−クライアント間での送受信の回数が多くなり、それに伴い、通信コストが高くなるという課題があった。
【００１３】
コマンドやレスポンスの送受信が行われる毎に、ヘッダやフッタなどの情報が付加されるため、それらの送受信回数が増えるにつれて、１回の通信データ量が増え、さらに、１回の送受信に要する通信時間が長くなる。この課題は、通信速度が遅く、通信コストが比較的高い、例えば、携帯電話機などの端末を遠隔操作する場合、さらに深刻なものとなる。
【００１４】
また、従来の制御システムにおいては、例えば、サーバから送信されてきたコマンドを受信したクライアントでエラーが発生した場合、エラーの内容にかかわらず、その時点で常に処理が中断されてしまい、エラーが発生した処理の次の処理をクライアントに実行させるには、サーバ−クライアント間で再接続し、コマンドを再度送信する必要があった。
【００１５】
本発明はこのような状況に鑑みてなされたものであり、ネットワークを介して接続される機器の制御を、より確実に、かつ効率的に行うことができるようにするものである。
【００１６】
【課題を解決するための手段】
本発明の制御システムの情報処理端末は、機器が接続された状態で、情報処理装置に対して、ネットワークを介した通信の確立を要求する要求手段と、要求手段による要求に応じて確立された通信により情報処理装置から送信される、機器の制御に関する命令を含むパケットを受信する受信手段と、受信手段により受信されたパケットに含まれる命令に基づいて、機器を制御する制御手段とを備え、情報処理装置は、情報処理端末からの要求に応じて、情報処理端末との間でネットワークを介した通信を確立する確立手段と、確立手段により情報処理端末との間で通信が確立されたとき、自分自身から、パケットを情報処理端末に送信する送信手段とを備えることを特徴とする。
【００１７】
本発明の制御システムの制御方法は、機器が接続された状態で、情報処理装置に対して、ネットワークを介した通信の確立を要求する要求ステップと、要求ステップの処理に応じて確立された通信により情報処理装置から送信される、機器の制御に関する命令を含むパケットを受信する受信ステップと、受信ステップの処理により受信されたパケットに含まれる命令に基づいて、機器を制御する制御ステップと、情報処理端末からの要求に応じて、情報処理端末との間でネットワークを介した通信を確立する確立ステップと、確立ステップの処理により情報処理端末との間で通信が確立されたとき、自分自身から、パケットを情報処理端末に送信する送信ステップとを含むことを特徴とする。
【００１８】
本発明の情報処理装置は、情報処理端末に機器が接続された状態で行われる情報処理端末からの要求に応じて、情報処理端末との間でネットワークを介した通信を確立する確立手段と、確立手段により情報処理端末との間で通信が確立されたとき、自分自身から、機器の制御に関する命令を含む第１のパケットを情報処理端末に送信する送信手段とを備えることを特徴とする。
【００１９】
送信手段により送信された命令に対応する、情報処理端末からの返信を含む第２のパケットを受信する受信手段をさらに備えるようにすることができる。
【００２０】
命令には、その命令に基づく処理が情報処理端末において失敗した場合に、次の命令に基づく処理を続行するか否かを表す情報が含まれるようにすることができる。
【００２１】
送信手段は、同一のプロトコルに属する複数の命令を１つの第１のパケットに含めて送信するようにすることができる。
【００２２】
送信手段は、機器による処理の結果によって、機器に次に実行させる処理を情報処理端末に判断させる簡易プログラムを、第１のパケットと共に送信するようにすることができる。
【００２３】
送信手段は、命令に基づく処理の対象となる機器を表す識別情報を含む第１のパケットを送信するようにすることができる。
【００２４】
確立手段により確立された通信経路上に情報処理端末のファイアウォールが存在する場合、送信手段は、通信プロトコルとしてHTTPを用い、第１のパケットを送信するようにすることができる。
【００２５】
送信手段は、複数の第１のパケットを送信する期間、確立手段により確立されたHTTPによる通信リンクを継続させるようにすることができる。
【００２６】
確立手段により確立された通信において、情報処理端末から所定の情報の送信が開始されるように、情報処理端末に指示する指示手段をさらに備えるようにすることができる。
【００２７】
本発明の情報処理装置の情報処理方法は、情報処理端末に機器が接続された状態で行われる情報処理端末からの要求に応じて、情報処理端末との間でネットワークを介した通信を確立する確立ステップと、確立ステップの処理により情報処理端末との間で通信が確立されたとき、自分自身から、機器の制御に関する命令を含むパケットを情報処理端末に送信する送信ステップとを含むことを特徴とする。
【００２８】
本発明の記録媒体に記録されているプログラム、および、本発明の第１のプログラムは、情報処理端末に機器が接続された状態で行われる情報処理端末からの要求に応じて、情報処理端末との間でネットワークを介した通信を確立する確立ステップと、確立ステップの処理により情報処理端末との間で通信が確立されたとき、自分自身から、機器の制御に関する命令を含むパケットを情報処理端末に送信する送信ステップとを含むことを特徴とする。
【００２９】
本発明の情報処理端末は、機器が接続された状態で、情報処理装置に対して、ネットワークを介した通信の確立を要求する要求手段と、要求手段による要求に応じて確立された通信により情報処理装置から送信される、機器の制御に関する命令を含む第１のパケットを受信する受信手段と、受信手段により受信された第１のパケットに含まれる命令に基づいて、機器を制御する制御手段とを備えることを特徴とする。
【００３０】
制御手段による機器の制御結果を表す返信を含む第２のパケットを情報処理装置に送信する送信手段をさらに備えるようにすることができる。
【００３１】
本発明の情報処理端末の情報処理方法は、機器が接続された状態で、情報処理装置に対して、ネットワークを介した通信の確立を要求する要求ステップと、要求ステップによる要求に応じて確立された通信により情報処理装置から送信される、機器の制御に関する命令を含むパケットを受信する受信ステップと、受信ステップの処理により受信されたパケットに含まれる命令に基づいて、機器を制御する制御ステップとを含むことを特徴とする。
【００３２】
本発明の記録媒体に記録されているプログラム、および、本発明の第２のプログラムは、機器が接続された状態で、情報処理装置に対して、ネットワークを介した通信の確立を要求する要求ステップと、要求ステップによる要求に応じて確立された通信により情報処理装置から送信される、機器の制御に関する命令を含むパケットを受信する受信ステップと、受信ステップの処理により受信されたパケットに含まれる命令に基づいて、機器を制御する制御ステップとを含むことを特徴とする。
【００３３】
本発明の制御システムおよび方法においては、機器が接続された状態で、情報処理装置に対して、ネットワークを介した通信の確立が要求され、要求に応じて確立された通信により情報処理装置から送信される、機器の制御に関する命令を含むパケットが受信され、受信されたパケットに含まれる命令に基づいて、機器が制御される。また、情報処理端末からの要求に応じて、情報処理端末との間でネットワークを介した通信が確立され、情報処理端末との間で通信が確立されたとき、パケットが情報処理端末に送信される。
【００３４】
本発明の情報処理装置および方法、記録媒体、並びにプログラムにおいては、情報処理端末に機器が接続された状態で行われる情報処理端末からの要求に応じて、情報処理端末との間でネットワークを介した通信が確立され、情報処理端末との間で通信が確立されたとき、機器の制御に関する命令を含む第１のパケットが情報処理端末に送信される。
【００３５】
本発明の情報処理端末および方法、記録媒体、並びにプログラムにおいては、機器が接続された状態で、情報処理装置に対して、ネットワークを介した通信の確立が要求され、要求に応じて確立された通信により情報処理装置から送信される、機器の制御に関する命令を含む第１のパケットが受信される。また、受信された第１のパケットに含まれる命令に基づいて、機器が制御される。
【００３６】
【発明の実施の形態】
図１は、本発明を適用した制御システムの構成例を示す図である。
【００３７】
ネットワーク１には、ネットワーク１に接続されるクライアント（クライアントを介してネットワーク１に接続されるデバイス）を遠隔制御するサーバ２およびサーバ４が接続されている。サーバ２には、クライアントとの間で行われる通信において、サーバ２と協働してデータの暗号化処理および復号処理、並びに認証処理を実行する暗号・認証用サーバ３が接続されている。
【００３８】
サーバ２またはサーバ４によるデバイス（機器）の制御は、クライアントを介して行われる。
【００３９】
ネットワーク１には、クライアントとしての携帯電話機５およびパーソナルコンピュータ６が接続されている。後に詳述するように、クライアント（携帯電話機５またはパーソナルコンピュータ６）と、サーバ（サーバ２またはサーバ４）の間で行われる通信においては、サーバが主導となってクライアントを制御することができるプロトコルが用いられる。
【００４０】
図１の例においては、サーバ２またはサーバ４によりクライアントを介して制御されるデバイスとして、リーダライタ１１、ICカード１３、スピーカ１４、およびディスプレイ１５が携帯電話機５に接続または内蔵されている。
【００４１】
また、携帯電話機５には、ICカード１３のように携帯電話機５に直接接続または内蔵されるのではなく、近接または載置されたときに、リーダライタ１１との間で電磁誘導を利用した通信を行う外部ICカード１２がリーダライタ１１を介して接続されている。
【００４２】
同様に、図１においては、サーバ２またはサーバ４によりクライアントを介して制御されるデバイスとして、ICカード２１、スピーカ２２、およびディスプレイ２３、リーダライタ２４がパーソナルコンピュータ６に接続されている。リーダライタ２４には、所定のタイミングで、外部ICカード２５が近接または載置される。
【００４３】
これらのデバイス（リーダライタ１１、外部ICカード１２、ICカード１３、スピーカ１４、ディスプレイ１５、ICカード２１、スピーカ２２、ディスプレイ２３、リーダライタ２４、および外部ICカード２５）は、ネットワーク１にクライアントを介して常時接続されているものではなく、所定のタイミングで接続されるものである。
【００４４】
当然、図１に示されるシステム構成は適宜変更可能である。例えば、携帯電話機５やパーソナルコンピュータ６以外にも、クライアントとしてのPDA(Personal Digital Assistants)や、デバイスとしてのメモリなどがネットワーク１を介してサーバ２やサーバ４に接続されるようにしてもよい。
【００４５】
図２は、図１のサーバ２の構成例を示すブロック図である。
【００４６】
CPU（Central Processing Unit）３１は、ROM（Read Only Memory）３２に記憶されているプログラム、または、記憶部３８からRAM（Random Access Memory）３３にロードされたプログラムに従って各種の処理を実行する。RAM３３にはまた、CPU３１が各種の処理を実行する上において必要なデータなどが適宜記憶される。
【００４７】
例えば、CPU３１により所定の制御プログラムが実行され、図１の制御システムにおいて用いられるプロトコル（以下、適宜、制御プロトコルと称する）の通信によりクライアントを制御するサーバが実現される。
【００４８】
CPU３１、ROM３２、およびRAM３３は、バス３４を介して相互に接続されている。このバス３４にはまた、入出力インタフェース３５も接続されている。
【００４９】
入出力インタフェース３５には、キーボード、マウスなどよりなる入力部３６、CRT(Cathode Ray Tube)、LCD(Liquid Crystal Display)などよりなるディスプレイ、並びにスピーカなどよりなる出力部３７、ハードディスクなどより構成される記憶部３８、モデム、ターミナルアダプタなどより構成される通信部３９が接続されている。通信部３９は、ネットワーク１を介しての通信処理を行う。
【００５０】
入出力インタフェース３５にはまた、必要に応じてドライブ４０が接続され、磁気ディスク４１、光ディスク４２、光磁気ディスク４３、或いは半導体メモリ４４などが適宜装着され、それから読み出されたコンピュータプログラムが、必要に応じて記憶部３８にインストールされる。
【００５１】
サーバ４の構成、並びに、クライアントである携帯電話機５およびパーソナルコンピュータ６の構成は、図２に示されるサーバ２の構成と基本的に同様であるため、その説明は省略する。なお、図２は、必要に応じて、携帯電話機５またはパーソナルコンピュータ６の構成としても引用される。
【００５２】
ここで、サーバとクライアントの間で行われる通信において用いられるプロトコルについて説明する。以下、適宜、サーバとクライアントの間で行われる通信において用いられるプロトコルを制御プロトコルと称する。
【００５３】
この制御プロトコルにより、クライアントにおいて実行されているWebアプリケーションの背後で、クライアントとサーバ間の通信が行われる。なお、携帯電話機５などでは、Webアプリケーションは必要なく、クライアントとの機器通信のみの場合がある。この場合、例えば、携帯電話機５のアプリケーションが、表示用データを全て保持しており、デバイスの制御と同様に、アプリケーションやディスプレイに対して制御を行うことにより、表示等を行う。
【００５４】
制御プロトコルを使用してWebアプリケーションを開発することにより、例えば、第１に、ビジネスロジックを１つの関数／メソッドの中に記述することができ（HTTP(Hyper Text Transfer Protocol)コネクションが毎回切れることを意識する必要がない）、第２に、サーバからクライアントに対してリクエストを送信させることができ（HTTPの「リクエストの送信元は常にクライアント」という制限を受けない）、第３に、クライアント上で任意の処理を実行させることができる（Applet，ActiveXコントロールのような制限を受けない）。
【００５５】
制御プロトコルは、Data Transfer Protocolと、その他のサブプロトコルで構成される。例えば、サブプロトコルとして、Handshake Protocol，Farewell Protocol，Error Protocol，Update Entity Protocol，Application Data Transfer Protocol，Operate Entity Protocolの６つが規定される。
【００５６】
具体的には、Data Transfer Protocolは、サブプロトコル電文の送受信手順を規定するものであり、Handshake Protocolは、コネクションの確立手順を規定するものである。また、Farewell Protocolは、コネクションの開放手順を規定するものであり、Error Protocolは、エラーの通知手順を規定するものである。
【００５７】
さらに、Update Entity Protocolは、サーバがクライアントの状態を変更する手順を規定するものであり、Application Data Transfer Protocolは、アプリケーション固有のデータの送受信手順を規定するものであり、Operate Entity Protocolは、サーバがクライアントを操作する手順を規定するものである。
【００５８】
これらのプロトコルを含む制御プロトコルは、データ通信の核（枠）となる部分だけを定義するものであり、所定のデバイスを操作するなど、アプリケーション固有の処理を実行するには、そのアプリケーション用のエクステンション（拡張モジュール）が必要である。すなわち、制御プロトコルによって、制御プロトコル本体とエクステンションが協調して動作するための手順が定義される。
【００５９】
図３は、制御プロトコルに基づく通信を実現するサーバ（例えば、サーバ２）の機能構成例を示すブロック図である。図３に示される各機能ブロックは、例えば、サーバ２のCPU３１により、所定の制御プログラムが実行されて実現される。
【００６０】
制御部５１は、Handshake Protocolに属するメッセージ（命令）を管理するHandshakeメッセージ管理部５２、Farewell Protocolに属するメッセージを管理するFarewellメッセージ管理部５５、Error Protocolに属するメッセージを管理するErrorメッセージ管理部５８、Application Data Transfer Protocolに属するメッセージを管理するApplication Data Transferメッセージ管理部６１、Update Entity Protocolに属するメッセージを管理するUpdate Entityメッセージ管理部６４、および、Operate Entity Protocolに属するメッセージを管理するOperate Entityメッセージ管理部６７を含む、サーバ２の機能全体を制御する。
【００６１】
なお、Handshake Protocolに属するメッセージ（以下、適宜、Handshakeメッセージと称する）については図７を参照して、Farewell Protocolに属するメッセージ（以下、適宜、Farewellメッセージと称する）については図９を参照して、Error Protocolに属するメッセージ（以下、適宜、Errorメッセージと称する）については図１１を参照して、Update Entity Protocolに属するメッセージ（以下、適宜、Update Entityメッセージと称する）については図１４を参照して、Application Data Transfer Protocolに属するメッセージ（以下、適宜、Application Data Transferメッセージと称する）については図１６を参照して、Operate Entity Protocolに属するメッセージ（以下、適宜、Operate Entityメッセージと称する）については図１８を参照して、それぞれ詳述する。
【００６２】
Handshakeメッセージ管理部５２は、Handshakeメッセージに関する処理を管理し、例えば、クライアントからパケットに含められて送信されてきたHandshakeメッセージがHandshakeメッセージ受信制御部５４から供給されてきたとき、そのメッセージに応じたHandshakeメッセージを生成し、クライアントに対して送信すべく、生成したHandshakeメッセージをHandshakeメッセージ送信制御部５３に出力する。
【００６３】
Handshakeメッセージ送信制御部５３は、図２の通信部３９において行われる、携帯電話機５などのクライアントに対するHandshakeメッセージの送信を制御し、Handshakeメッセージ受信制御部５４は、図２の通信部３９において行われる、クライアントから送信されてきたHandshakeメッセージの受信を制御する。
【００６４】
Farewellメッセージ管理部５５は、Farewellメッセージに関する処理を管理し、例えば、クライアントからパケットに含められて送信されてきたFarewellメッセージがFarewellメッセージ受信制御部５７から供給されてきたとき、そのメッセージに応じたFarewellメッセージを生成し、クライアントに対して送信すべく、生成したFarewellメッセージをFarewellメッセージ送信制御部５６に出力する。
【００６５】
Farewellメッセージ送信制御部５６は、図２の通信部３９において行われる、クライアントに対するFarewellメッセージの送信を制御し、Farewellメッセージ受信制御部５７は、図２の通信部３９において行われる、クライアントから送信されてきたFarewellメッセージの受信を制御する。
【００６６】
Errorメッセージ管理部５８は、Errorメッセージに関する処理を管理し、例えば、クライアントから送信されてきたパケットにフォーマットのエラーが存在することが制御部５１により検出されたとき、それに対応するErrorメッセージを生成し、クライアントに対して送信すべく、生成したErrorメッセージをErrorメッセージ送信制御部５９に出力する。
【００６７】
Errorメッセージ送信制御部５９は、図２の通信部３９において行われる、クライアントに対するErrorメッセージの送信を制御し、Errorメッセージ受信制御部６０は、図２の通信部３９において行われる、クライアントから送信されてきたErrorメッセージの受信を制御する。
【００６８】
Application Data Transferメッセージ管理部６１は、Application Data Transferメッセージに関する処理を管理し、例えば、クライアントからパケットに含められて送信されてきたApplication Data TransferメッセージがApplication Data Transferメッセージ受信制御部６３から供給されてきたとき、そのメッセージに応じたApplication Data Transferメッセージを生成し、クライアントに対して送信すべく、生成したApplication Data TransferメッセージをApplication Data Transferメッセージ送信制御部６２に出力する。
【００６９】
Application Data Transferメッセージ送信制御部６２は、図２の通信部３９において行われる、クライアントに対するApplication Data Transferメッセージの送信を制御する。具体的には、Application Data Transferメッセージ送信制御部６２は、Application Data Transferメッセージ管理部６１から供給されてきた所定の数のメッセージにFINISHDメッセージを付加し、１つのパケットとしてクライアントに送信する。
【００７０】
Application Data Transferメッセージ受信制御部６３は、図２の通信部３９において行われる、クライアントから送信されてきたApplication Data Transferメッセージの受信を制御する。具体的には、Application Data Transferメッセージ受信制御部６３は、クライアントから送信されてきたパケットの終端を、それに含まれるFINISHDメッセージにより検出し、パケットに含まれるApplication Data TransferメッセージをApplication Data Transferメッセージ管理部６１に出力する。
【００７１】
Update Entityメッセージ管理部６４は、Update Entityメッセージに関する処理を管理し、例えば、制御部５１から、所定のUpdate Entityメッセージをクライアントに対して送信することが指示されたとき、指示に対応するUpdate Entityメッセージを生成し、クライアントに対して送信すべく、生成したUpdate EntityメッセージをUpdate Entityメッセージ送信制御部６５に出力する。
【００７２】
Update Entityメッセージ送信制御部６５は、図２の通信部３９において行われる、クライアントに対するUpdate Entityメッセージの送信を制御する。具体的には、Update Entityメッセージ送信制御部６５は、Update Entityメッセージ管理部６４から供給されてきた所定の数のメッセージにFINISHDメッセージを付加し、１つのパケットとしてクライアントに送信する。
【００７３】
Update Entityメッセージ受信制御部６６は、図２の通信部３９において行われる、クライアントから送信されてきたUpdate Entityメッセージの受信を制御する。具体的には、Update Entityメッセージ受信制御部６６は、クライアントから送信されてきたパケットの終端を、それに含まれるFINISHDメッセージにより検出し、パケットに含まれるUpdate EntityメッセージをUpdate Entityメッセージ管理部６４に出力する。
【００７４】
Operate Entityメッセージ管理部６７は、Operate Entityメッセージに関する処理を管理し、例えば、制御部５１から、所定のOperate Entityメッセージをクライアントに対して送信することが指示されたとき、指示に対応するOperate Entityメッセージを生成し、クライアントに対して送信すべく、生成したOperate EntityメッセージをOperate Entityメッセージ送信制御部６８に出力する。
【００７５】
Operate Entityメッセージ送信制御部６８は、図２の通信部３９において行われる、クライアントに対するOperate Entityメッセージの送信を制御する。具体的には、Operate Entityメッセージ送信制御部６８は、Operate Entityメッセージ管理部６７から供給されてきた所定の数のメッセージにFINISHDメッセージを付加し、１つのパケットとしてクライアントに送信する。
【００７６】
Operate Entityメッセージ受信制御部６９は、図２の通信部３９において行われる、クライアントから送信されてきたOperate Entityメッセージの受信を制御する。具体的には、Operate Entityメッセージ受信制御部６９は、クライアントから送信されてきたパケットの終端を、それに含まれるFINISHDメッセージにより検出し、パケットに含まれるOperate EntityメッセージをOperate Entityメッセージ管理部６７に出力する。
【００７７】
図４は、制御プロトコルに基づく通信を実現するクライアント（例えば、携帯電話機５）の機能構成例を示すブロック図である。図４に示される構成は、基本的には図３に示されるサーバ側の構成と同様であるため、上述したものと重複する説明については適宜省略する。
【００７８】
図４に示される各構成は、例えば、携帯電話機５のCPU３１により、所定の制御プログラムが実行されて実現される。
【００７９】
制御部８１は、Handshakeメッセージ管理部８２、Farewellメッセージ管理部８５、Errorメッセージ管理部８８、Application Data Transferメッセージ管理部９１、Update Entityメッセージ管理部９４、および、Operate Entityメッセージ管理部９７を含む、携帯電話機５（クライアント）の機能全体を制御する。
【００８０】
例えば、制御部８１は、サーバから送信され、Update Entityメッセージ受信制御部９６において受信された所定のUpdate EntityメッセージがUpdate Entityメッセージ管理部９４を介して供給されてきたとき、デバイス制御部１００を制御し、供給されてきたUpdate Entityメッセージに基づく処理をデバイスに実行させる。
【００８１】
また、制御部８１は、クライアント自身に接続されているデバイスにより所定の処理を実行させたとき、デバイスによる実行結果（例えば、処理が成功したか否かを表す情報）をデバイス制御部１００から取得し、それをUpdate Entityメッセージ管理部９４に出力する。
【００８２】
Update Entityメッセージ管理部９４においては、処理結果に基づくレスポンスメッセージ（Update Entityメッセージ）が生成され、Update Entityメッセージ送信制御部９５を介して、クライアントに対して送信される。
【００８３】
デバイス制御部１００は、Application Data Transferメッセージ受信制御部９３により取得されたApplication Data Transferメッセージが制御部８１に供給され、それに基づく処理をデバイスに実行させることが制御部８１から指示されたとき、また、Update Entityメッセージ受信制御部９６により取得されたUpdate Entityメッセージが制御部８１に供給され、それに基づく処理をデバイスに実行させることが制御部８１から指示されたとき、或いは、Operate Entityメッセージ受信制御部９９により取得されたOperate Entityメッセージが制御部８１に供給され、それに基づく処理をデバイスに実行させることが制御部８１から指示されたとき、それらの指示に基づいて、クライアント自身に接続されているデバイスの動作を制御する。
【００８４】
また、デバイス制御部１００は、その制御結果（デバイスによる処理結果）を制御部８１に出力する。この処理結果に基づいて、Application Data Transferメッセージ管理部９１、Update Entityメッセージ管理部９４、または、Operate Entityメッセージ管理部９７においてサーバに対するレスポンスが生成される。
【００８５】
次に、図５を参照して、制御プロトコルの状態遷移について説明する。なお、それぞれの状態において行われる通信の詳細については後述するものとする。
【００８６】
ステップＳ１において、クライアント（例えば、携帯電話機５）のCPU３１によりクライアントプログラムが起動され、状態遷移が開始される。起動時には、例えば、以下の各情報が必要となる。
【００８７】
・サーバURL(Uniform Resource Locator)
クライアントを制御するサーバのURL（例：http://www.oge.com/webapp/Server）
【００８８】
・ビュー表示WebアプリケーションURL
アプリケーションの前面でエンドユーザに対してビュー（画面）を提供するWebアプリケーションのURL（例：http://www.oge.com/webapp/ViewDispatcher）
【００８９】
なお、携帯電話機５等において、Webアプリケーションが必要ない場合、このURLは必要ない。
【００９０】
・クッキー（オプション）
セッションを識別するためのクッキー
【００９１】
クライアントは、サーバURLにより指定されたサーバ（例えば、サーバ２）に対して、指定されたセッションIDを使ってHTTPリクエストを送信する。上述した例においては、「www.oge.com」の所定のポート番号に対して、「/webapp/Server」に電文をPOSTするHTTPリクエストが送信される。
【００９２】
なお、起動時にクッキー情報がセットされた場合、クライアントは、HTTPリクエストのCookieヘッダに、指定されたクッキー情報を付加する。
【００９３】
サーバからの返信電文はHTTPレスポンスのコンテンツ部に格納される。
【００９４】
起動後、クライアントは、ステップＳ２において、Handshakeサブプロトコルを使ってCLIENT_HELLOメッセージをサーバに送信し、通信の確立を要求する。CLIENT_HELLOメッセージが送信されてから、コネクションが確立されるまでの状態がHandshakeステートとされる（図５のstate1）。
【００９５】
クライアントは、Handshake Protocolを終了したとき、ステップＳ３において、サーバに対してFINISHEDメッセージを送信する。これによりコネクションが確立され、制御の主導権がサーバに移る。
【００９６】
なお、CLIENT_HELLO_DONEをクライアントからサーバへ送信することにより、コネクションが確立される場合もある（図２５参照）。
【００９７】
すなわち、サーバからクライアントに対して所定のコマンド（メッセージ）が送信され、そのメッセージに基づく処理結果などを表すレスポンスがクライアントからサーバに返信される。コネクションが確立し、主導権がサーバに移った状態がNeutralステートとされる（図５のstate2）。
【００９８】
Neutralステートの状態にあるステップＳ４において、サーバは、自分自身が主導的に、アプリケーションのロジックに従って、クライアントの状態制御、またはアプリケーション固有データの送受信を行う。
【００９９】
このとき、クライアントの状態制御には、Update Entityサブプロトコルが用いられ、アプリケーション固有データの送受信にはApplication Data Transferサブプロトコルが用いられる。また、クライアント側のデバイスの操作にはOperate Entityサブプロトコルが用いられる。
【０１００】
Neutralステートに限り、これらの３つのサブプロトコルのパケットを、任意の順序で、複数同時に送受信することが可能とされる。例えば、図２０乃至図２２を参照して後述するように、１つのパケットに含めることができるサブプロトコル種別は１種類であり（１種類のサブプロトコルのヘッダおよびメッセージ列により１つのパケットが構成され）、それぞれのパケットの末尾には、そのサブプロトコルのFinishedメッセージが含まれる。
【０１０１】
また、Neutralステートで使用されるサブプロトコル（Update Entity，Application Data Transfer，Operate Entity）によりサーバからクライアントに対して送信されるそれぞれのメッセージには、処理に失敗した場合に、それに続く後続のメッセージの処理を続行するのか、または、中止するのかをクライアントに判断させる情報が含まれている。
【０１０２】
例えば、クライアントは、先頭ビットが「０」であるメッセージの処理に失敗した場合、後続のメッセージの処理を中止し、一方、先頭ビットが「１」であるメッセージの処理に失敗した場合、後続のメッセージの処理を続行する。各サブプロトコルの拡張メッセージについても同様である。
【０１０３】
アプリケーションのロジックが終了したとき、サーバは、ステップＳ５において、Farewellサブプロトコルを使ってSERVER_GOOD_BYEメッセージをクライアントに送信する。SERVER_GOOD_BYEメッセージが送信されてから、コネクションが開放されるまでの状態がFarewellステートとされる（図５のstate3）。
【０１０４】
サーバは、Farewell Protocolが終了したと判断したとき、ステップＳ６において、クライアントに対してFINISHEDメッセージを送信し、コネクションを終了させる。クライアントにおいては、ステップＳ７で、リソースが開放され、処理が終了される。
【０１０５】
なお、SERVER_GOOD_BYE_DONEをサーバからクライアントへ送信することにより、Farewellステートを経ずに、コネクションが終了され、クライアントにおいて、リソースが開放されて、処理が終了する場合もある（図２５）。
【０１０６】
また、任意の場所（状態）で処理を続行することが不可能なエラーが発生した場合、クライアントまたはサーバは、ステップＳ８において、Errorサブプロトコルを用いてエラーメッセージを相手に送信する。エラーが発生してから制御プロトコルによる通信が終了されるまでの状態がErrorステートとされる（図５のstate4）。
【０１０７】
ステップＳ９において、例えば、サーバからFINISHEDメッセージがクライアントに送信されたとき、Errorステートが終了され、コネクションが終了される。
【０１０８】
以上のような状態遷移を有する制御プロトコルに従って、クライアントとサーバ間で通信が行われる。
【０１０９】
次に、Data Transfer Protocolにより規定されるパケットのデータフォーマットについて説明する。
【０１１０】
図６は、パケットのデータフォーマットの例を示す図である。
【０１１１】
図６に示されるように、パケットは、所定の数のメッセージ（サブプロトコル用の電文）からなるメッセージ列と、ヘッダから構成される。
【０１１２】
ヘッダは、さらに、Version，Sub Protocol Type(SPT)，Lengthの３つのフィールドから構成される。
【０１１３】
Versionにより制御プロトコルのバージョン番号が表される。例えば、Versionのうちの上位バイトによりメジャーバージョン番号が表され、下位バイトによりマイナーバージョン番号が表される。Data Transfer Protocolの変更によりメジャーバージョン番号が上がり、サブプロトコルの追加または変更により、マイナーバージョン番号が上がる。
【０１１４】
Sub Protocol TypeによりHandshake Protocol，Farewell Protocol，Error Protocol，Application Data Transfer Protocol，Update Entity Protocol， Operate Entity Protocolのうちの、パケットで用いられているサブプロトコルの種別が表される。
【０１１５】
Lengthによりメッセージ列の長さが表される。
【０１１６】
一方、メッセージ列に含まれる１つのメッセージは、Extension(Ext)，Device ID(DID)，Message Type(MT)，Length，Dataのフィールドから構成される。
【０１１７】
Extensionによりアプリケーションドメイン固有の処理を実行するためのエクステンションの種別が表される。
【０１１８】
Device IDによりメッセージが対象とするデバイスのIDが表される。例えば、クライアントに複数のデバイスが接続されている場合、そのデバイス全体がメッセージの適用範囲とされるようなIDや、サーバ／クライアントとも、デバイスを意識することなくメッセージの適用範囲を決定するIDなども必要に応じて規定される。
【０１１９】
Message Typeによりメッセージの種別が表される。後に詳述するように、例えば、Handshakeプロトコルには、クライアントからサーバに対して行われるCLIENT_HELLOメッセージや、サーバからクライアントに対して行われるSERVER_HELLOメッセージなどが規定されているが、それらのメッセージの種別がMessage Typeにより表される。
【０１２０】
Lengthにより、メッセージのデータ部（Data）の長さが表される。メッセージのデータ部のデータフォーマットはメッセージタイプに依存する。
【０１２１】
次に、上述したそれぞれのサブプロトコルについて説明する。
【０１２２】
図７は、Handshake Protocolにおいて用いられるメッセージを示す図である。
【０１２３】
図７に示されるように、FINISHEDメッセージはサブプロトコルの終了を意味し、WARNINGメッセージは警告の通知を意味する。WARNINGメッセージのデータ部には、所定の文字列からなる警告メッセージが含まれる。
【０１２４】
CLIENT_HELLOメッセージはクライアントからサーバに対するHandshakeデータの送信開始を意味し、CLIENT_HELLO_DONEメッセージはHandshakeデータの送信終了を意味する。
【０１２５】
SERVER_HELLOメッセージはサーバからクライアントに対するHandshakeデータの送信開始を意味し、SERVER_HELLO_DONEメッセージはHandshakeデータの送信終了を意味する。
【０１２６】
DEVICESメッセージはデバイスリストの通知を意味し、そのデータ部により、デバイス固有のデバイスID、パーミッション、タイプ名長、タイプ名、デバイス名長、およびデバイス名が表される。例えば、パーミションによりデバイスに対するアクセス権の有無が表され、「０」がアクセス可（操作可）、「１」がアクセス不可（操作不可）とされる。
【０１２７】
例えば、DEVICESメッセージにより、クライアントに接続されている、操作対象のデバイスリストの通知や、デバイスに実行させることが可能な処理の通知が行われる。
【０１２８】
次に、図８のシーケンスを参照して、図７に示されるメッセージを用いて行われるHandshake Protocolについて説明する。以下のシーケンスにおいては、制御プロトコルによる通信によりデバイスを制御するサーバとしてのサーバ２と、クライアントとしての携帯電話機５により実行される処理について説明する。
【０１２９】
Handshake Protocolは、ステップＳ２１において、例えば、携帯電話機５（クライアント）のHandshakeメッセージ送信制御部８３（図４）がCLIENT_HELLOメッセージを、例えば、サーバ２（サーバ）に送信することにより開始される。すなわち、制御部８１からの指示に応じて、Handshakeメッセージ管理部８２においてCLIENT_HELLOメッセージが生成され、Handshakeメッセージ送信制御部８３によりサーバ２に送信される。
【０１３０】
携帯電話機５のHandshakeメッセージ送信制御部８３は、ステップＳ２２において、自分自身に接続されているデバイスであって、かつ、サーバ２によるコントロールを許可する全てのデバイスに関する情報を、DEVICESメッセージを用いてサーバに通知する。このDEVICESメッセージも、制御部８１の指示に基づいてHandshakeメッセージ管理部８２により生成されたものである。
【０１３１】
DEVICESメッセージにより、例えば、携帯電話機５に接続されているリーダライタ１１、およびリーダライタ１１を介して接続されている外部ICカード１２に関する情報などがサーバ２に通知される。
【０１３２】
アプリケーション固有のメッセージがステップＳ２３において送信され、ステップＳ２４においてCLIENT_HELLO_DONEメッセージが送信されたとき、携帯電話機５からサーバ２に対するHandshakeデータの送信が終了される。
【０１３３】
一方、携帯電話機５から送信されてきたCLIENT_HELLOメッセージ、DEVICESメッセージ、アプリケーション固有のメッセージ、および、CLIENT_HELLO_DONEメッセージがステップＳ４１乃至Ｓ４４においてサーバ２のHandshakeメッセージ受信制御部５４で取得されたとき、ステップＳ４５に進み、Handshakeメッセージ送信制御部５３（図３）は、携帯電話機５に対してSERVER_HELLOメッセージを送信する。
【０１３４】
また、サーバ２のHandshakeメッセージ送信制御部５３は、ステップＳ４６において、アプリケーション固有のメッセージを送信し、ステップＳ４７に進み、SERVER_HELLO_DONEメッセージを送信する。ここでは、Handshake Protocolにおいて送信される、アプリケーション固有のメッセージを含む全てのメッセージがHandshakeメッセージ送信制御部５３の制御の下に送信されている。
【０１３５】
サーバ２から送信されたSERVER_HELLOメッセージ、アプリケーション固有のメッセージ、およびSERVER_HELLO_DONEメッセージは、ステップＳ２５乃至Ｓ２７において携帯電話機５のHandshakeメッセージ受信制御部８４によりそれぞれ受信される。
【０１３６】
サーバ２のHandshakeメッセージ送信制御部５３は、携帯電話機５と自分自身の双方がHELLO_DONEメッセージ（CLIENT_HELLO_DONEメッセージ、SERVER_HELLO_DONEメッセージ）を送信したとき、ステップＳ４８において、さらに、携帯電話機５に対してFINISHEDメッセージを送信する。
【０１３７】
サーバ２から送信されたFINISHEDメッセージは、ステップＳ２８において、携帯電話機５のHandshakeメッセージ受信制御部８４により受信される。
【０１３８】
携帯電話機５のHandshakeメッセージ送信制御部８３は、ステップＳ２９においてアプリケーション固有のメッセージを送信し、ステップＳ３０に進み、サーバ２に対してFINISHEDメッセージを送信する。携帯電話機５から送信されたアプリケーション固有のメッセージとFINISHEDメッセージは、ステップＳ４９とＳ５０においてサーバ２のHandshakeメッセージ受信制御部５４によりそれぞれ受信され、これにより携帯電話機５とサーバ２の双方においてHandshake Protocolが終了される。
【０１３９】
なお、図８の一点鎖線は、アプリケーション固有のメッセージの送受信が必要な場合にのみ、それぞれ所定の数だけ送信されることを表している。例えば、ステップＳ２３において、メッセージが送信されない場合もあるし、複数のメッセージが送信される場合もある。後述する図１０においても同様である。
【０１４０】
また、図８においては、ステップＳ５０において、サーバ２によりFINISHEDメッセージが受信されたときにHandshake Protocolが終了されるとしたが、その前に、ステップＳ４４において、サーバ２で受信されたCLIENT_HELLO_DONEメッセージが受信されたときに、Handshake Protocolが終了されるようにしてもよい。
【０１４１】
さらに、図８においては、サーバ２と携帯電話機５から、それぞれHELLOメッセージとHELLO DONEメッセージが送信されるとしたが、携帯電話機５からのみ、それらのメッセージがサーバ２に対して送信されるようにしてもよい。これにより、Handshake Protocolの確実性は多少損なわれるものの、Handshake Protocolを迅速に終了させ、Neutralステートにおける処理を迅速に開始させることができる。換言すれば、携帯電話機５とサーバ２の双方が_HELLOメッセージと_HELLO DONEメッセージを送受信することにより、より確実に、Handshake Protocolを実行させることができる。
【０１４２】
図９は、Farewell Protocolにおいて用いられるメッセージを示す図である。
【０１４３】
FINISHEDメッセージはサブプロトコルの終了を意味し、WARNINGメッセージは警告の通知を意味する。WARNINGメッセージのデータ部には、所定の文字列からなる警告メッセージが含まれる。
【０１４４】
CLIENT_GOOD_BYEメッセージは、クライアントからサーバに対するFarewellデータの送信開始を意味し、CLIENT_GOOD_BYE_DONEメッセージはFarewellデータの送信終了を意味する。
【０１４５】
一方、SERVER_GOOD_BYEメッセージは、サーバからクライアントに対するFarewellデータの送信開始を意味し、SERVER_GOOD_BYE_DONEメッセージはFarewellデータの送信終了を意味する。
【０１４６】
RETURN_CODEメッセージはサーバによる終了コードの通知を意味し、そのメッセージのデータ部には終了コードが含まれる。
【０１４７】
次に、図１０のシーケンスを参照して、図９に示されるメッセージを用いて行われるFarewell Protocolについて説明する。
【０１４８】
ステップＳ８１において、サーバ２（サーバ）のFarewellメッセージ送信制御部５６がSERVER_GOOD_BYEメッセージを送信することによりFarewell Protocolが開始される。このように、Farewell Protocolは、通信の主導権を有するサーバ２からのメッセージにより開始される（図５を参照して説明したように、Handshake Protocolが終了した後は、サーバが通信の主導権を有している）。
【０１４９】
サーバ２のFarewellメッセージ送信制御部５６は、ステップＳ８２において、携帯電話機５（クライアント）に対してRETURN_CODEメッセージを送信し、ステップＳ８３に進み、アプリケーション固有のメッセージ（Extension中のFarewell用拡張メッセージ）を送信する。
【０１５０】
また、サーバ２のFarewellメッセージ送信制御部５６は、全てのアプリケーション固有のメッセージを送信した後、ステップＳ８４に進み、SERVER_GOOD_BYE_DONEメッセージを携帯電話機５に送信する。
【０１５１】
ステップＳ８１乃至Ｓ８４においてサーバ２から送信された情報は、それぞれステップＳ６１乃至Ｓ６４において携帯電話機５のFarewellメッセージ受信制御部８７により受信される。
【０１５２】
携帯電話機５のFarewellメッセージ送信制御部８６は、ステップＳ６５において、サーバ２に対してCLIENT_GOOD_BYEメッセージを送信する。
【０１５３】
また、携帯電話機５のFarewellメッセージ送信制御部８６は、ステップＳ６６において、アプリケーション固有のメッセージを送信し、ステップＳ６７に進み、CLIENT_GOOD_BYE_DONEメッセージを送信する。
【０１５４】
携帯電話機５のFarewellメッセージ送信制御部８６は、CLIENT_GOOD_BYE_DONEメッセージをサーバ２に対して送信した後、ステップＳ６８に進み、FINISHEDメッセージを送信する。ステップＳ６５乃至Ｓ６８において携帯電話機５のFarewellメッセージ送信制御部８６から送信された情報は、それぞれステップＳ８５乃至Ｓ８８においてサーバ２のFarewellメッセージ受信制御部５７により受信される。
【０１５５】
サーバ２のFarewellメッセージ受信制御部５７により、携帯電話機５から送信されてきたFINISHEDメッセージがステップＳ８８において受信されたとき、ステップＳ８９に進み、Farewellメッセージ送信制御部５６から携帯電話機５に対してFINISHEDメッセージが送信され、Farewell Protocolが終了される。サーバ２のFarewellメッセージ送信制御部５６から送信されたFINISHEDメッセージは、ステップＳ６９において携帯電話機５により受信される。
【０１５６】
なお、ステップＳ８４において、SERVER_GOOD_BYE_DONEを送信することにより、Farewell Protocolが終了されるようにしてもよい。これにより、Farewell Protocolを迅速に終了させることができる。
【０１５７】
図１１は、Error Protocolにおいて用いられるメッセージを示す図である。
【０１５８】
FINISHEDメッセージはサブプロトコルの終了を意味し、WARNINGメッセージは警告の通知を意味する。WARNINGメッセージのデータ部には、所定の文字列からなる警告メッセージが含まれる。
【０１５９】
PACKET_FORMAT_ERRORメッセージはパケットのフォーマットにエラーがあることを意味し、ILLEGAL_STATE_ERRORメッセージは不正なメッセージを検知したことを意味する。
【０１６０】
UNEXPECTED_ERRORメッセージは、予期しないエラーが発生したことを意味する。
【０１６１】
PACKET_FORMAT_ERRORメッセージ、ILLEGAL_STATE_ERRORメッセージ、およびUNEXPECTED_ERRORメッセージのそれぞれのデータ部には、エラーの内容を表す、所定の文字列からなるエラーメッセージが含まれる。
【０１６２】
次に、図１２および図１３のシーケンスを参照して、図１１に示されるメッセージを用いて行われるError Protocolについて説明する。
【０１６３】
図１２は、携帯電話機５によりエラーが検出された場合のError Protocolのシーケンスを示す図である。
【０１６４】
携帯電話機５の制御部８１は、その後の処理を続行することが不可能なエラーを検知した場合、ステップＳ１０１において、ERRORメッセージ管理部８８を制御し、図１１のメッセージ（PACKET_FORMAT_ERRORメッセージ、ILLEGAL_STATE_ERRORメッセージ、またはUNEXPECTED_ERRORメッセージ）を用いて、エラーを検知したこと（検知されたエラーの内容）をサーバ２に通知する。すなわち、制御部８１からの指示に応じた所定のメッセージがERRORメッセージ管理部８８により生成され、それがERRORメッセージ送信制御部８９から送信される。
【０１６５】
その後、携帯電話機５によるステップＳ１０２およびＳ１０３、並びにサーバ２によるステップＳ１１２およびＳ１１３の処理により、携帯電話機５とサーバ２間でFINISHEDメッセージが送受信され、図５を参照して説明したように、サーバ−クライアント間の通信が終了される。
【０１６６】
図１３は、サーバ２によりエラーが検出された場合のError Protocolのシーケンスを示す図である。
【０１６７】
サーバ２の制御部５１は、その後の処理を続行することが不可能なエラーを検知した場合、ステップＳ１３１において、ERRORメッセージ管理部５８を制御し、検知したエラーの内容に応じたメッセージを用いて、エラーを検知したことを携帯電話機５に通知する。すなわち、制御部５１からの指示に応じた所定のメッセージがERRORメッセージ管理部５８により生成され、それがERRORメッセージ送信制御部５９から送信される。
【０１６８】
サーバ２のERRORメッセージ送信制御部５９は、エラーを検知したことを通知したとき、ステップＳ１３２に進み、携帯電話機５に対してFINISHEDメッセージを送信する。
【０１６９】
サーバ２から送信されたメッセージがステップＳ１２１およびＳ１２２において携帯電話機５により受信され、通信が終了される。
【０１７０】
以上のように、サーバ２および携帯電話機５は、それぞれのサブプロトコルに基づく通信において、エラーを検知した場合、任意のタイミングで相手側に対してErrorメッセージを送信することができる。
【０１７１】
なお、上述したErrorサブプロトコルによるメッセージだけでなく、アプリケーションにより独自に規定されたエラー通知メッセージが用いられて、相手側にエラーの検知が通知されるようにしてもよい。
【０１７２】
また、ErrorメッセージのうちのWARNINGメッセージは、シーケンスに影響を与えない。すなわち、WARNINGメッセージが受信された側において、メッセージの内容がログに出力されるようにしてもよいし、無視されるようにしてもよい。
【０１７３】
図１４は、Update Entity Protocolにおいて用いられるメッセージを示す図である。
【０１７４】
Update Entity Protocolのメッセージは、例えば、図１のリーダライタ１１の表面に設けられているLED(Light Emitting Diode)を発光させたり、または、所定のデバイスの電源をオンにするなど、デバイスの状態（属性）を変更させるときに用いられる。
【０１７５】
FINISHEDメッセージはパケットの終端を意味し、WARNINGメッセージは警告の通知を意味する。WARNINGメッセージのデータ部には所定の文字列からなる警告メッセージが含まれる。
【０１７６】
SET_PROPERTYメッセージは、サーバからクライアントに対して送信され、クライアントに接続されているデバイスの属性値の設定を意味する。SET_PROPERTYメッセージに対するクライアントからの返信は、PROPERTY_SETメッセージにより行われる。
【０１７７】
このSET_PROPERTYメッセージは、メッセージに基づく処理がクライアントにおいて失敗したとき、後続のメッセージの処理を中止しなければならないメッセージである。従って、SET_PROPERTYメッセージの先頭ビットは、後続のメッセージの処理を中断するように設定される。
【０１７８】
SET_PROPERTYメッセージのデータ部には、属性名長、属性名、属性値長、属性値などの、デバイスに新たに設定させる属性に関する情報が含まれる。
【０１７９】
PROPERTY_SETメッセージは、サーバから送信されてきたSET_PROPERTYメッセージに対するクライアントからの返信を意味し、そのデータ部には、SET_PROPERTYメッセージに基づく処理がクライアントにおいて成功したのか否かを表すフラグが含まれる。
【０１８０】
GET_PROPERTYメッセージは、サーバからクライアントに対して送信され、クライアントに接続されたデバイスの属性値の取得を意味する。GET_PROPERTYメッセージに対するクライアントからの返信は、PROPERTYメッセージにより行われる。
【０１８１】
このGET_PROPERTYメッセージは、メッセージに基づく処理がクライアントにおいて失敗したとき、後続のメッセージの処理を中止しなければならないメッセージである。従って、GET_PROPERTYメッセージの先頭ビットは、後続のメッセージの処理を中断するように設定される。
【０１８２】
GET_PROPERTYメッセージのデータ部には、属性値の取得を要求するデバイスの属性名長、および属性名などの情報が含まれる。
【０１８３】
PROPERTYメッセージは、サーバから送信されてきたGET_PROPERTYメッセージに対するクライアントからの返信を意味し、そのデータ部には、サーバからの要求に対応する、デバイスの属性値長および属性値などの情報が含まれる。
【０１８４】
SET_NETWORK_TIMEOUTメッセージは、クライアントのネットワークタイムアウト値の設定を意味する。
【０１８５】
このSET_NETWORK_TIMEOUTメッセージは、メッセージに基づく処理がクライアントにおいて失敗した場合であっても、後続のメッセージの処理を継続するメッセージである。従って、SET_NETWORK_TIMEOUTメッセージの先頭ビットは、後続のメッセージの処理を継続するように設定される。
【０１８６】
SET_NETWORK_TIMEOUTメッセージのデータ部には、クライアントに設定させるタイムアウト値が含まれる。
【０１８７】
次に、図１５のシーケンスを参照して、図１４に示されるメッセージを用いて行われるUpdate Entity Protocolについて説明する。
【０１８８】
携帯電話機５に接続されたデバイスの状態を変更するとき、サーバ２のUpdate Entityメッセージ管理部６４は、制御部５１による制御に基づいて、ステップＳ１５１において、携帯電話機５に送信するUpdate Entityメッセージを生成する。生成されたUpdate EntityメッセージはUpdate Entityメッセージ送信制御部６５に出力される。
【０１８９】
サーバ２のUpdate Entityメッセージ送信制御部６５は、ステップＳ１５２において、ステップＳ１５１で生成されたUpdate Entityメッセージ列の末尾にFINISHEDメッセージを付加し、Update Entityメッセージ列とFINISHEDメッセージからなるパケットを携帯電話機５に送信する。
【０１９０】
すなわち、ステップＳ１５１で生成される所定の数のUpdate Entityメッセージと、ステップＳ１５２で付加される１つのFINISHEDメッセージからなる１つのパケットが携帯電話機５に対して送信される。
【０１９１】
このように、１つのパケットに複数のメッセージを含めて携帯電話機５に送信することができるため（複数のメッセージを送信するのに１つのヘッダやフッタを付加するだけでよいため）、１つのメッセージ毎にヘッダやフッタが付加されて構成されるパケットが送信される場合に較べて、データ量を抑制することができる。また、通信時間を抑制することができるとともに、通信コストを抑制することができる。このことは、全てのプロトコルにおいても同様である。
【０１９２】
パケットに含められてサーバ２から送信されたUpdate Entityメッセージは、ステップＳ１４１において携帯電話機５のUpdate Entityメッセージ受信制御部９６により取得され、Update Entityメッセージ列の末尾に付加されたFINISHEDメッセージは、ステップＳ１４２において取得される。
【０１９３】
携帯電話機５においては、サーバから送信されてきたパケットに含まれるメッセージが取得され、取得された順に、メッセージに基づく処理が行われる。また、必要に応じて、処理結果を表すレスポンスが制御部８１により生成される。
【０１９４】
携帯電話機５のUpdate Entityメッセージ受信制御部９６は、サーバ２から送信されてきたFINISHEDメッセージを受信することによりパケットの終端を検知する。受信したUpdate Entityメッセージに対するレスポンス（Update Entityメッセージ）がステップＳ１４３においてUpdate Entityメッセージ管理部９４により生成される。
【０１９５】
例えば、サーバ２からデバイスの属性値を変更することが指示されたとき、属性値の変更がデバイス制御部１００により行われ、属性値の変更が成功したか否かが制御部８１からUpdate Entityメッセージ管理部９４に通知される。Update Entityメッセージ管理部９４においては、その通知に対応するレスポンスが生成され、Update Entityメッセージ送信制御部６５に出力される。
【０１９６】
ステップＳ１４４において、携帯電話機５のUpdate Entityメッセージ送信制御部９５は、生成したレスポンスにFISNISHEDメッセージを付加し、１つのパケットとしてサーバ２に送信する。なお、レスポンスの有無、およびその数は、サーバ２から送信されてきたメッセージ次第である。
【０１９７】
パケットに含められて携帯電話機５から送信されたUpdate Entityメッセージは、ステップＳ１５３においてサーバ２のUpdate Entityメッセージ受信制御部６６により取得され、Update Entityメッセージ列の末尾に付加されたFINISHEDメッセージは、ステップＳ１５４において取得される。
【０１９８】
以下、適宜、Neutralステートにおいて、サーバ２から携帯電話機５に対して送信されるパケット（０を含む所定の数のUpdate Entityメッセージと１つのFISNISHEDメッセージを含むパケット、０を含む所定の数のApplication Data Transferメッセージと１つのFISNISHEDメッセージを含むパケット、または、０を含む所定の数のOperate Entityメッセージと１つのFISNISHEDメッセージを含むパケット）を制御パケットと称する。
【０１９９】
また、その制御パケットに含まれるメッセージの処理結果等を通知すべく、携帯電話機５からサーバ２に対して返信されるパケット（メッセージに対応する０を含む所定の数のレスポンスと１つのFISNISHEDメッセージを含むパケット）を返信パケットと称する。
【０２００】
以上のようにして、Update EntityメッセージとFISNISHEDメッセージを含む制御パケットが、サーバ主導でサーバ２から携帯電話機５に対して送信され、それに基づく処理が携帯電話機５において実行される。携帯電話機５においては、サーバ２から送信されてきたUpdate Entityメッセージに対応するレスポンスが生成され、レスポンスとFISNISHEDメッセージを含む返信パケットがサーバ２に対して送信される。
【０２０１】
具体的には、例えば、図１４のSET_PROPERTYメッセージを含む制御パケットがサーバ２から携帯電話機５に対して送信されたとき、携帯電話機５においては、SET_PROPERTYメッセージに基づくデバイスの属性値の設定が行われ、PROPERTY_SETメッセージ（レスポンス）を含む返信パケットがサーバ２に対して返信される。
【０２０２】
なお、携帯電話機５およびサーバ２は、Update Entityメッセージ列の中に、所定の数のアプリケーション固有メッセージ（Extension中のUpdate Entity用拡張メッセージ）を含めて送信することができる。
【０２０３】
図１６は、Application Data Transfer Protocolにおいて用いられるメッセージを示す図である。
【０２０４】
Application Data Transfer Protocolは、例えば、リーダライタ１１を介して携帯電話機５に接続される外部ICカード１２を制御するためのアプリケーションのコマンドなど、サーバとクライアント（デバイス）間におけるアプリケーションデータを送受信するときに用いられる。
【０２０５】
FINISHEDメッセージはパケットの終端を意味し、WARNINGメッセージは警告の通知を意味する。WARNINGメッセージのデータ部には所定の文字列からなる警告メッセージが含まれる。
【０２０６】
次に、図１７のシーケンスを参照して、図１６に示されるメッセージを用いて行われるApplication Data Transfer Protocolについて説明する。
【０２０７】
ステップＳ１７１において、サーバ２のApplication Data Transferメッセージ管理部６１は、一群のApplication Data Transferメッセージ列を生成する。生成されたApplication Data Transferメッセージは、Application Data Transferメッセージ送信制御部６２に出力される。
【０２０８】
サーバ２のApplication Data Transferメッセージ送信制御部６２は、ステップＳ１７２において、生成したApplication Data Transferメッセージ列の末尾にFINISHEDメッセージを付加し、所定の数のApplication Data Transferメッセージ列と１つのFINISHEDメッセージからなる制御パケットを携帯電話機５に送信する。
【０２０９】
制御パケットに含まれるApplication Data Transferメッセージは、ステップＳ１６１において、携帯電話機５のApplication Data Transferメッセージ受信制御部９３により受信され、FINISHEDメッセージはステップＳ１６２において受信される。
【０２１０】
携帯電話機５のApplication Data Transferメッセージ受信制御部９３は、サーバ２から送信されてきたFINISHEDメッセージを受信することにより制御パケットの終端を検知し、制御パケットに含まれるApplication Data TransferメッセージがApplication Data Transferメッセージ管理部９１に出力される。
【０２１１】
ステップＳ１６３において、パケットに含まれるApplication Data Transferメッセージに対応するレスポンスが生成される。すなわち、デバイス制御部１００により行われた制御の結果がApplication Data Transferメッセージ管理部９１に通知され、Application Data Transferメッセージ管理部９１により、その結果に対応するレスポンスが生成される。生成されたレスポンスはApplication Data Transferメッセージ送信制御部９２に供給される。
【０２１２】
ステップＳ１６４において、携帯電話機５のApplication Data Transferメッセージ送信制御部９２は、生成されたレスポンス（Application Data Transferメッセージ）列の末尾にFINISHEDメッセージを付加し、生成した返信パケットをサーバ２に送信する。
【０２１３】
パケットに含められて携帯電話機５から送信されたApplication Data Transferメッセージは、ステップＳ１７３においてサーバ２のApplication Data Transferメッセージ受信制御部６３により取得され、Application Data Transferメッセージ列の末尾に付加されたFINISHEDメッセージは、ステップＳ１７４において取得される。
【０２１４】
なお、レスポンスの有無、およびその数は、サーバ２から送信されてきたメッセージ次第である。
【０２１５】
上述したUpdate Entity Protocolの場合と同様に、携帯電話機５およびサーバ２は、Application Data Transferメッセージ列の中に、所定の数のアプリケーション固有メッセージ（Extension中のApplication Data Transfer用拡張メッセージ）を送信することができる。
【０２１６】
図１８は、Operate Entity Protocolにおいて用いられるメッセージを示す図である。
【０２１７】
Operate Entity Protocolは、例えば、携帯電話機５に接続されたリーダライタ１１による電磁波の輻射の開始または停止、或いは、ユーザに対して所定の入力を行わせるための所定の画面表示など、クライアントに接続されたデバイスを制御するときに用いられる。
【０２１８】
FINISHEDメッセージはパケットの終端を意味し、WARNINGメッセージは警告の通知を意味する。WARNINGメッセージのデータ部には、所定の文字列からなる警告メッセージが含まれる。
【０２１９】
UPDATE_VIEWメッセージは、サーバからクライアントに対して送信され、クライアントにおけるビュー（表示画面）の更新を意味する。UPDATE_VIEWメッセージに対する返信は、VIEW_UPDATEDメッセージによりサーバに対して行われる。
【０２２０】
このUPDATE_VIEWメッセージは、メッセージに基づく処理がクライアントにおいて失敗したとき、後続のメッセージの処理を中止しなければならないメッセージである。従って、UPDATE_VIEWメッセージの先頭ビットは、後続のメッセージの処理を中断するように設定される。
【０２２１】
VIEW_UPDATEDメッセージは、サーバから送信されてきたUPDATE_VIEWメッセージに対する返信を意味し、そのデータ部には、ビューの更新が成功したか否かを表すフラグが含まれる。
【０２２２】
BEGIN_DATA_INPUTメッセージは、サーバからクライアントに対して送信され、デバイスに対するデータの入力を開始することを意味する。BEGIN_DATA_INPUTメッセージに対するクライアントからの返信は、END_DATA_INPUTによりサーバに対して行われる。
【０２２３】
このBEGIN_DATA_INPUTメッセージは、メッセージに基づく処理がクライアントにおいて失敗したとき、後続のメッセージの処理を中止しなければならないメッセージである。従って、BEGIN_DATA_INPUTメッセージの先頭ビットは、その処理に失敗した場合、後続のメッセージの処理を中断するように設定される。
【０２２４】
END_DATA_INPUTメッセージは、BEGIN_DATA_INPUTに対するクライアントからの返信を意味し、そのデータ部には、データの入力が成功したか否かを表すフラグ、属性名長、属性名、属性値長、および属性値の情報が含まれる。
【０２２５】
OPERATE_DEVICEメッセージは、サーバからクライアントに対して送信され、クライアントに接続されたデバイスを操作することを意味する。OPERATE_DEVICEメッセージに対するクライアントからの返信は、DEVICE_RESPONSEメッセージによりサーバに対して行われる。
【０２２６】
このOPERATE_DEVICEメッセージは、メッセージに基づく処理がクライアントにおいて失敗したとき、後続のメッセージの処理を中止しなければならないメッセージである。従って、OPERATE_DEVICEメッセージの先頭ビットは、その処理に失敗した場合、後続のメッセージの処理を中断するように設定される。
【０２２７】
OPERATE_DEVICEメッセージのデータ部には、操作名文字数、操作名、パラメタ長、およびパラメタの情報が含まれる。
【０２２８】
DEVICE_RESPONSEメッセージは、クライアントからサーバに対して送信され、デバイス操作の結果の通知を意味する。DEVICE_RESPONSEメッセージのデータ部には、レスポンス長、レスポンスの情報が含まれる。
【０２２９】
PLAY_SOUNDメッセージは、サーバからクライアントに対して送信され、クライアント側において、サーバにより指定された論理名に対応した音を発生させることを意味する。PLAY_SOUNDメッセージに対する返信は行われない。
【０２３０】
このPLAY_SOUNDメッセージは、メッセージに基づく処理がクライアントにおいて失敗した場合であっても、後続のメッセージの処理を継続するメッセージである。従って、PLAY_SOUNDメッセージの先頭ビットは、その処理に失敗した場合であっても、後続のメッセージの処理を継続するように設定される。
【０２３１】
PLAY_SOUNDメッセージのデータ部には、発生させる音の論理名を表す情報が含まれる。
【０２３２】
次に、図１９のシーケンスを参照して、図１８に示されるメッセージを用いて行われるOperate Entity Protocolについて説明する。
【０２３３】
サーバ２のOperate Entityメッセージ管理部６７は、ステップＳ１９１において、携帯電話機５に送信する、意味のある一群のOperate Entityメッセージ列を生成する。生成されたOperate EntityメッセージはOperate Entityメッセージ送信制御部６８に出力される。
【０２３４】
携帯電話機５のOperate Entityメッセージ送信制御部６８は、ステップＳ１９２において、生成したメッセージ列の末尾にFINISHEDメッセージを付加し、制御パケットとして携帯電話機５に送信する。
【０２３５】
携帯電話機５に対して送信された制御パケットに含まれるOperate EntityメッセージおよびFINISHEDメッセージは、ステップＳ１８１およびＳ１８２においてそれぞれ受信される。
【０２３６】
携帯電話機５のOperate Entityメッセージ管理部９７は、ステップＳ１８３において、サーバ２から送信されてきたOperate Entityメッセージに対するレスポンスを制御部８１による指示に基づいて生成する。なお、レスポンスの有無、およびその数は、サーバ２から送信されてきたメッセージ次第である。
【０２３７】
携帯電話機５のOperate Entityメッセージ送信制御部６５は、ステップＳ１８４において、Operate Entityメッセージ管理部９７により生成されたレスポンスにFISNISHEDメッセージを付加し、返信パケットとしてサーバ２に送信する。
【０２３８】
パケットに含められて携帯電話機５から送信されたOperate Entityメッセージは、ステップＳ１９３においてサーバ２のOperate Entityメッセージ受信制御部６９により取得され、Operate Entityメッセージ列の末尾に付加されたFINISHEDメッセージは、ステップＳ１９４において取得される。
【０２３９】
なお、携帯電話機５、およびサーバ２は、Operate Entityメッセージ列の中に所定の数のアプリケーション固有メッセージ（Extension中のOperate Entity用拡張メッセージ）を送信することができる。
【０２４０】
以上のように、携帯電話機５とサーバ２の間でHandshakeが成立し、Neutralステート（図５）のときには、サーバ２が通信の主導権を有し、サーバ２から、Update Entity Protocol，Application Data Transfer Protocol、またはOperate Entity Protocolに基づくメッセージが携帯電話機５に対して送信される（Update Entity Protocolによる通信のシーケンスを示す図１５、Application Data Transfer Protocolによる通信のシーケンスを示す図１７、および、Operate Entity Protocolによる通信のシーケンスを示す図１９においては、いずれもサーバ２から通信が開始されている）。
【０２４１】
すなわち、携帯電話機５からの命令に応じて、サーバ２がレスポンスを携帯電話機５に返信し、その返信に基づいてデバイスが制御されるのではなく、サーバ２から携帯電話機５に対して直接送信された命令に基づいて、携帯電話機５に接続されているデバイスが制御される。
【０２４２】
従って、１度通信が確立された後は、サーバ２からの通信によりデバイスを直接制御することができる。
【０２４３】
次に、図２０を参照して、以上のようなサブプロトコルに従ってNeutralステートにおける通信を行う、サーバ（サーバ２）とクライアント（携帯電話機５）の処理について説明する。
【０２４４】
図２０においては、ステップＳ２１１において、Application Data TransferメッセージＡ（MsgＡ）、Application Data TransferメッセージＢ（MsgＢ）にFinishedメッセージが付加されて生成された制御パケット（Application Data Transferパケット）２０１がサーバ２から携帯電話機５に対して送信されている。
【０２４５】
図１７を参照して説明したように、Application Data Transfer Protocolによる通信においては、サーバ２のApplication Data Transferメッセージ送信制御部６２から、所定の数のApplication Data TransferメッセージにFinishedメッセージが付加されて構成される制御パケットが携帯電話機５に対して送信される。
【０２４６】
また、ステップＳ２１１においては、Operate EntityメッセージＸ（MsgＸ）にFinishedメッセージが付加されて生成された制御パケット（Operate Entityパケット）２０２がサーバ２から携帯電話機５に対して送信されている。
【０２４７】
図１９を参照して説明したように、Operate Entity Protocolによる通信においては、サーバ２から、所定の数のOperate EntityメッセージにFinishedメッセージが付加されて構成される制御パケットが携帯電話機５に対して送信される。
【０２４８】
さらに、ステップＳ２１１においては、Application Data TransferメッセージＣ（MsgＣ）にFinishedメッセージが付加されて生成された制御パケット（Application Data Transferパケット）２０３がサーバ２から携帯電話機５に対して送信されている。
【０２４９】
このように、複数の制御パケットが携帯電話機５に一括して送信されるため、それぞれのプロトコルのパケットをそれぞれ送信する場合に較べて、通信回数を抑制することができる。
【０２５０】
制御パケットに含められてサーバ２から送信されたメッセージは、送信された順序で携帯電話機５により処理され、レスポンスが順次生成される。携帯電話機５により生成されたレスポンスは、生成された順序でサーバ２に返信される。
【０２５１】
従って、図２０の例においては、ステップＳ２０１で携帯電話機５により制御パケット２０１乃至２０３が受信されたとき、Application Data TransferメッセージＡ、Application Data TransferメッセージＢ、Operate EntityメッセージＸ、Application Data TransferメッセージＣの順に、それらのメッセージに基づく処理が携帯電話機５により実行される。
【０２５２】
上述したように、メッセージに基づく処理の途中でエラーが発生した場合、それに続くメッセージの処理を続行するのか、または、その時点で処理を中断するのかは、メッセージの先頭ビットの値により設定されている。
【０２５３】
図２０に示される処理においては、送信された全てのメッセージの処理が成功した場合の例とされている。また、Application Data TransferメッセージＡとOperate EntityメッセージＸは、それぞれ返信（レスポンス）が必要とされるメッセージであり、Application Data TransferメッセージＢとApplication Data TransferメッセージＣは、共に返信が必要でないメッセージとされている。
【０２５４】
携帯電話機５において処理が成功したか否かをサーバ２側で管理する必要があるメッセージに対しては、携帯電話機５によりレスポンスが生成される。
【０２５５】
従って、携帯電話機５は、Application Data TransferメッセージＡに基づく処理を実行したとき、それに対するレスポンスＡ（ResＡ）を生成し、レスポンスＡにFinishedメッセージを付加して生成した返信パケット（Application Data Transferパケット）２１１を、ステップＳ２０２において、サーバ２に対して送信する。
【０２５６】
図１７を参照して説明したように、Application Data Transfer Protocolによる通信においては、サーバ２から送信されてきた制御パケットに含まれるApplication Data Transferメッセージに対応してApplication Data Transferメッセージ管理部９２によりレスポンスが生成され、生成されたレスポンスとFinishedメッセージからなる返信パケットがApplication Data Transferメッセージ送信制御部９２からサーバ２に送信される。
【０２５７】
また、携帯電話機５は、Operate EntityメッセージＸに基づく処理を実行したとき、それに対するレスポンスＸ（ResＸ）を生成し、レスポンスＸにFinishedメッセージを付加して生成した返信パケット（Operate Entityパケット）２１２を、ステップＳ２０２において、サーバ２に対して送信する。
【０２５８】
図１９を参照して説明したように、Operate Entity Protocolによる通信においては、サーバ２から送信されてきた制御パケットに含まれるOperate Entityメッセージに対応して、Operate Entityメッセージ管理部９７によりレスポンスが生成され、生成されたレスポンスとFinishedメッセージからなる返信パケットがOperate Entityメッセージ送信制御部９８からサーバ２に送信される。
【０２５９】
なお、携帯電話機５は、返信メッセージの有無に関わらず、サーバ２から送信されてきた１つの制御パケットに対して１つの返信パケットをサーバ２に送信しなければならないため、Application Data TransferメッセージＣが返信を必要としないメッセージである場合であっても、制御パケット２０３に対して、Finishedメッセージが末尾に付加された返信パケット（Application Data Transferパケット）２１３をステップＳ２０２においてサーバ２に送信する。
【０２６０】
携帯電話機５から送信された返信パケットはステップＳ２１２においてサーバ２により受信され、返信パケットに含まれるレスポンスにより、携帯電話機５においてメッセージに基づく処理が成功されたことが取得される。
【０２６１】
このように、サーバ２から送信されたそれぞれのメッセージに対して、送信された順序で返信メッセージが生成されるため、サーバ２および携帯電話機５は、送信メッセージと返信メッセージを対応付けて管理することができる。
【０２６２】
図２１は、サーバ２と携帯電話機５により実行される他の処理について説明するシーケンスである。
【０２６３】
図２１においては、ステップＳ２３１において、図２０の場合と同様に、制御パケット２２１乃至２２３がサーバ２から携帯電話機５に対して送信されている。
【０２６４】
なお、図２１においては、携帯電話機５に対して送信されたApplication Data TransferメッセージＡ（MsgＡ）の処理が失敗した場合の例とされている。また、Application Data TransferメッセージＡの先頭ビットにより、Application Data TransferメッセージＡの処理が失敗した場合、その時点で処理を中断することが表されている場合の例とされている。
【０２６５】
従って、ステップＳ２２１において、携帯電話機５により制御パケット２２１に含まれるApplication Data TransferメッセージＡが取得され、それに基づく処理が失敗したとき、Application Data TransferメッセージＡに続くApplication Data TransferメッセージＢ、Operate EntityメッセージＸ、Application Data TransferメッセージＣに基づく処理は実行されない。
【０２６６】
携帯電話機５は、Application Data TransferメッセージＡに基づく処理に失敗したとき、処理が失敗したことをサーバ２に通知するレスポンスＡ（ResＡ）を生成する。携帯電話機５は、ステップＳ２２２において、生成したレスポンスＡにFinishedメッセージを付加し、返信パケット（Application Data Transferパケット）２３１をサーバ２に送信する。
【０２６７】
ステップＳ２３２において、サーバ２は、携帯電話機５からの返信パケット２３１を受信し、それに含まれるレスポンスＡに基づいて、Application Data TransferメッセージＡに基づく処理が携帯電話機５において失敗したことを取得する。また、サーバ２は、Application Data TransferメッセージＢ、Operate EntityメッセージＸ、Application Data TransferメッセージＣに基づく処理が実行されていないことを取得する。
【０２６８】
図２２は、サーバ２と携帯電話機５により実行されるさらに他の処理について説明するシーケンスである。
【０２６９】
図２２においても、図２０または図２１と同様に、ステップＳ２５１において、制御パケット２４１乃至２４２がサーバ２から携帯電話機５に対して送信されている。
【０２７０】
なお、図２２においては、携帯電話機５に対して送信されたApplication Data TransferメッセージＢ（MsgＢ）の処理が失敗した場合の例とされている。また、Application Data TransferメッセージＢの先頭ビットにより、Application Data TransferメッセージＢの処理が失敗した場合であっても、それに続くメッセージの処理を続行することが表されている場合の例とされている。
【０２７１】
さらに、Application Data TransferメッセージＡおよびOperate EntityメッセージＸは、返信メッセージを必要とするメッセージであり、Application Data TransferメッセージＣは、返信メッセージを必要としないメッセージとされている。
【０２７２】
従って、携帯電話機５は、ステップＳ２４１において、制御パケット２４１を受信し、Application Data TransferメッセージＡに基づく処理を実行し、レスポンスＡ（ResＡ）を生成する。
【０２７３】
また、携帯電話機５は、Application Data TransferメッセージＢに基づく処理に失敗した場合であっても、Application Data TransferメッセージＢの先頭ビットにより表される指示に従って、それに続く処理を続行する。すなわち、携帯電話機５は、制御パケット２４２に含まれるOperate EntityメッセージＸに基づく処理を実行し、Operate EntityメッセージＸに対応するレスポンスＸ（ResＸ）を生成する。
【０２７４】
さらに、携帯電話機５は、レスポンスＸを生成した後、制御パケット２４３に含まれるApplication Data TransferメッセージＣに基つく処理を実行する。
【０２７５】
携帯電話機５により生成されたレスポンスＡとFinishedパケットを含む返信パケット（Application Data Transferパケット）２５１、レスポンスＸとFinishedパケットを含む返信パケット（Operate Entityパケット）２５２、および、Finishedパケットを含む返信パケット（Application Data Transferパケット）２５３は、ステップＳ２４２において、サーバ２に対して送信される。
【０２７６】
携帯電話機５から送信された返信パケットは、ステップＳ２５２においてサーバ２により受信され、Application Data TransferメッセージＡに基づく処理、および、Operate Entityメッセージに基づく処理が携帯電話機５において成功したこと、並びに、Application Data TransferメッセージＢに基づく処理が失敗したことが取得され、処理が終了される。
【０２７７】
Neutralステートのとき、以上のようなサーバ２と携帯電話機５の間でのパケットの送受信が繰り返し実行され、サーバ主導によるクライアント（デバイス）の制御が行われる。
【０２７８】
以上においては、携帯電話機５に対するメッセージの送信と、サーバ２に対するレスポンスの返信が繰り返されることにより、所定のデバイスの制御が行われるとしたが、例えば、サーバ２から携帯電話機５に対してスクリプト（簡易プログラム）が制御パケットと共に一括して送信され、メッセージに基づく処理結果と、簡易プログラムに従って、次に実行する処理が携帯電話機５自身により判断されるようにしてもよい。
【０２７９】
すなわち、スクリプトには、所定のメッセージに対して生成されたレスポンス（デバイスのレスポンス）の内容によって、次に、どのメッセージに基づく処理を実行するのかが記述される。
【０２８０】
スクリプトに基づく処理が終了されたとき、デバイスから携帯電話機５に対して行われたレスポンスの内容が、サーバ２に対して一括して送信される返信パケットに含められて送信される。
【０２８１】
スクリプトの実行履歴（携帯電話機５からデバイスに送信されたメッセージ（携帯電話機５により実行されたメッセージ）の内容と、その順序を表す情報）がサーバ２に送信されることにより、サーバ２は、携帯電話機５から送信されてきたレスポンスが、どのメッセージに対するものなのかを判断することができる。
【０２８２】
また、以上においては、Handshakeプロトコルにより通信が確立したとき、サーバ２が通信の主導となり、携帯電話機５との間での通信が行われるとしたが、任意のタイミングで、携帯電話機５が通信の主導権を有することができるようにしてもよい。
【０２８３】
この場合、例えば、主導権の逆転は、サーバ・クライアント送受信方向逆転プロトコルによって行われる。
【０２８４】
例えば、サーバ２が主導となって通信が行われている場合、所定のタイミングで、サーバ２から携帯電話機５に対してサーバ・クライアント送受信方向逆転プロトコルのEXCHANGEメッセージが送信される。それ以降の通信においては、携帯電話機５が主導となって、上述したものと同様の通信が行われる。
【０２８５】
一方、携帯電話機５が主導となって通信が行われている場合、所定のタイミングで、携帯電話機５からサーバ２に対してサーバ・クライアント送受信方向逆転プロトコル（EXCHANGEプロトコル）のEXCHANGEメッセージが送信される。この場合、サーバ２が主導となり、それ以降の通信が行われる。
【０２８６】
図２３および図２４は、EXCHANGE（交換）プロトコルのシーケンスを示す図である。
【０２８７】
図２３においては、始めに、携帯電話機５（Client）が通信の主導を有している。ステップＳ３０１において携帯電話機５から送信されたEXCHANGEメッセージは、ステップＳ３１１においてサーバ２（Server）により受信され、それ以降、サーバ２が主導となり、サーバ２と携帯電話機５との間で通信が行われる。
【０２８８】
一方、図２４においては、始めに、サーバ２が通信の主導を有している。ステップＳ３３１においてサーバ２から送信されたEXCHANGEメッセージは、ステップＳ３２１において携帯電話機５により受信され、それ以降、携帯電話機５が主導となり、サーバ２と携帯電話機５との間で通信が行われる。
【０２８９】
以上のようにして、Neutralステートでの通信の主導権の切り替えが行われる。
【０２９０】
なお、サーバ２と携帯電話機５の間で確立された通信経路上に携帯電話機５のファイアウォールが存在する場合、そのファイアウォールを越えて通信を行うことができるようにして、サーバ２と携帯電話機５の間では、HTTPによる通信が行われる。この場合、上述した複数のプロトコルのパケットの送受信は、１回のセッションが維持された状態で行われる。
【０２９１】
図２５は、制御プロトコルの状態遷移について説明する他の図であり、基本的には、図５を参照して説明したものと同様である。上述した図５に代えて、図２５に示されるように、状態遷移が行われるようにしてもよい。なお、図５と重複する部分については、その説明を適宜省略する。
【０２９２】
クライアントは、Handshake Protocol（State1）を終了したとき、ステップＳ３４３において、サーバに対してCLIENT_HELLO_DONEメッセージを送信する。これによりコネクションが確立され、制御の主導権がサーバに移る。
【０２９３】
また、Neutralステート状態にあるステップＳ３４４においては、サーバが主導となり、Update Entityサブプロトコル、Application Data Transferサブプロトコル、および、Operate Entityサブプロトコルによる通信が行われるだけでなく、必要に応じて、上述したEXCHANGEメッセージが用いられ、主導権の切り替えが行われる。
【０２９４】
サーバは、Farewell Protocolが終了したと判断したとき、ステップＳ３４６において、クライアントに対してSERVER_GOOD_BYE_DONEメッセージを送信し、コネクションを終了させる。これにより、クライアントのリソースが開放され、処理が終了される。
【０２９５】
このように、SERVER_GOOD_BYE_DONEメッセージが送信されることにより、処理が終了される場合もある。
【０２９６】
図２６は、上述したように、クライアントからサーバに対して、CLIENT_HELLO_DONEメッセージが送信されることにより、コネクションが終了される場合のシーケンスである。
【０２９７】
すなわち、ステップＳ３６１において、クライアントからサーバに対して、CLIENT_HELLOメッセージが送信され、ステップＳ３６２に進み、DEVICESメッセージが送信される。
【０２９８】
ステップＳ３６３において、アプリケーション固有のメッセージが送信され、ステップＳ３６４に進み、CLIENT_HELLO_DONEメッセージが送信されたとき、サーバとクライアント間でのコネクションが確立される。
【０２９９】
なお、サーバにおいては、ステップＳ３７１乃至Ｓ３７４において、クライアントから送信されてきたCLIENT_HELLOメッセージ、DEVICESメッセージ、アプリケーション固有のメッセージ、および、CLIENT_HELLO_DONEメッセージがそれぞれ受信される。
【０３００】
例えば、クライアントが携帯電話機などの機器である場合、図８の処理と比較して、データの送受信が一部省略された、以上の処理により、クライアントとサーバの間でコネクションが確立されることがある。
【０３０１】
図２７は、上述したように、サーバからクライアントに対して、SERVER_GOOD_BYE_DONEメッセージが送信されることにより、Farewell Protocolが終了される場合のシーケンスである。
【０３０２】
すなわち、ステップＳ３９１において、サーバからSERVER_GOOD_BYEメッセージが送信されることによりFarewell Protocolが開始され、ステップＳ３９２において、RETURN_CODEメッセージが送信される。また、ステップＳ３９３において、アプリケーション固有のメッセージが送信される。
【０３０３】
ステップＳ３９４において、サーバからクライアントに対して、SERVER_GOOD_BYE_DONEメッセージが送信され、これにより、コネクションが終了される。
【０３０４】
サーバから送信されたSERVER_GOOD_BYEメッセージ、RETURN_CODEメッセージ、アプリケーション固有のメッセージ、および、SERVER_GOOD_BYE_DONEメッセージは、それぞれ、クライアントにより、ステップＳ３８１乃至Ｓ３８４の処理により受信される。SERVER_GOOD_BYE_DONEメッセージが受信されたとき、クライアントのリソースが開放される。
【０３０５】
上述したHandshake Protocolの場合と同様に、例えば、クライアントが携帯電話機などの機器である場合、図１０の処理と比較して、データの送受信が一部省略された、以上のような処理により、クライアントとサーバの間でのコネクションが終了されることがある。
【０３０６】
上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。
【０３０７】
一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば、汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
【０３０８】
この記録媒体は、図２に示されるように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク４１（フレキシブルディスクを含む）、光ディスク４２（CD-ROM(Compact Disk-Read Only Memory)，DVD(Digital Versatile Disk)を含む）、光磁気ディスク４３（MD（登録商標）(Mini-Disk)を含む）、もしくは半導体メモリ４４などよりなるパッケージメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM３２や、記憶部３８に含まれるハードディスクなどで構成される。
【０３０９】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に従って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０３１０】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表わすものである。
【０３１１】
【発明の効果】
本発明によれば、情報処理装置と情報処理端末の間で通信を行うこと、特に、重宝処理装置が主導となり情報処理端末との間で通信を行うことができる。
【０３１２】
また、本発明によれば、効率的にかつ確実に各種のパケットを送受信することができるとともに、通信コストを抑制することができ、これにより、情報処理装置が、情報処理端末を効率的かつ確実に制御することができる。
【０３１３】
さらに、本発明によれば、処理のエラーが発生した場合であっても、それに続く処理をクライアントに実行させることができる。
【図面の簡単な説明】
【図１】本発明を適用した制御システムの構成例を示す図である。
【図２】図１のサーバの構成例を示すブロック図である。
【図３】サーバの機能構成例を示すブロック図である。
【図４】クライアントの機能構成例を示すブロック図である。
【図５】制御プロトコルの状態遷移について説明する図である。
【図６】パケットのフォーマットの例を示す図である。
【図７】 Handshake Protocolにおいて用いられるメッセージを示す図である。
【図８】図７に示されるメッセージを用いて行われるHandshake Protocolについて説明するシーケンスである。
【図９】 Farewell Protocolにおいて用いられるメッセージを示す図である。
【図１０】図９に示されるメッセージを用いて行われるFarewell Protocolについて説明するシーケンスである。
【図１１】 Error Protocolにおいて用いられるメッセージを示す図である。
【図１２】図１１に示されるメッセージを用いて行われるError Protocolについて説明するシーケンスである。
【図１３】図１１に示されるメッセージを用いて行われる他のError Protocolについて説明するシーケンスである。
【図１４】 Update Entity Protocolにおいて用いられるメッセージを示す図である。
【図１５】図１４に示されるメッセージを用いて行われるUpdate Entity Protocolについて説明するシーケンスである。
【図１６】 Application Data Transfer Protocolにおいて用いられるメッセージを示す図である。
【図１７】図１６に示されるメッセージを用いて行われるApplication Data Transfer Protocolについて説明するシーケンスである。
【図１８】 Operate Entity Protocolにおいて用いられるメッセージを示す図である。
【図１９】図１８に示されるメッセージを用いて行われるOperate Entity Protocolについて説明するシーケンスである。
【図２０】 Neutralステートにおける通信を説明するシーケンスである。
【図２１】 Neutralステートにおける他の通信を説明するシーケンスである。
【図２２】 Neutralステートにおけるさらに他の通信を説明するシーケンスである。
【図２３】 Exchange Protocolについて説明するシーケンスである。
【図２４】 Exchange Protocolについて説明するシーケンスである。
【図２５】制御プロトコルの他の状態遷移について説明する図である。
【図２６】 Handshake Protocolについて説明する他のシーケンスである。
【図２７】 Farewell Protocolについて説明する他のシーケンスである。
【符号の説明】
１ ネットワーク， ２および４ サーバ， ５ 携帯電話機， ６ パーソナルコンピュータ， １１ 磁気ディスク， １２ 光ディスク， １３ 光磁気ディスク， １４ 半導体メモリ
【発明の属する技術分野】
本発明は、制御システムおよび方法、情報処理装置および方法、情報処理端末および方法、記録媒体、並びにプログラムに関し、特に、ネットワークを介して接続される機器の制御を、より確実に、かつ効率的に行うことができるようにする制御システムおよび方法、情報処理装置および方法、情報処理端末および方法、記録媒体、並びにプログラムに関する。
【０００２】
【従来の技術】
近年、携帯電話機などの通信端末を利用して、遠隔地に設置されている機器を制御するシステムが各種提案されている。
【０００３】
そのようなシステムとして、例えば、特許文献１には、外出先（外部）から電話で送信される暗証番号によって、家庭内に設置されたエアーコンディショナやビデオ録画装置などの家電製品を制御するシステムが開示されている。
【０００４】
また、特許文献２には、制御端末と被制御端末の間にサーバが設置されており、そのサーバを経由して、制御端末が被制御端末の動作を制御するシステムが開示されている。
【０００５】
ところで、これらの制御システムにおいては、遠隔制御される装置が何らかの通信手段により常時接続されており、遠隔にある端末から必ず接続できる環境にあることを前提としている（例えば、特許文献１のシステムにおいては、家電製品がリモートコントローラおよびアダプタを介して電話回線に常時接続されている）。
【０００６】
このように、制御する側の第１の装置と、制御される側の第２の装置が常に通信を行うことができる環境にある場合、いずれの装置も、自分自身が主導となって通信を開始させることが可能である。例えば、第１の装置から第２の装置に対してリクエストを含む各種のデータを任意のタイミングで送信したり、反対に、第２の装置から第１の装置に対して各種のデータを送信したりすることが可能である。
【０００７】
従って、ネットワークを介して通信を行うことにより、どのタイミングであっても、装置を直接制御することができる。
【０００８】
【特許文献１】
特開２０００−１８４０８１号公報
【特許文献２】
特開２００２−４１３７８号公報
【０００９】
【発明が解決しようとする課題】
しかしながら、このように、ネットワークに常時接続されている環境にない、例えば、ICカード、ディスプレイ、或いは、メモリなどのデバイスを遠隔操作する場合、それらのデバイスを管理するパーソナルコンピュータなどのクライアントからサーバにリクエストが送信され、サーバから返信されるリクエストの結果に基づいて、デバイスが操作されるという仕組みが一般的であり、サーバが主導となり、デバイスを直接操作するということが困難であるという課題があった。
【００１０】
すなわち、デバイスがネットワークに常時接続されていないため、サーバからクライアントに任意のタイミングでアクセスし、サーバが主導となり、クライアントにより管理されているデバイスを制御することができない。
【００１１】
具体的には、ネットワークに接続されている装置（例えば、ICカードリーダライタやRF-ID受信装置）に近接または載置されることにより、所定のタイミングでサーバに接続されるICカードや非接触RF-IDなどのデバイスに対して、サーバが主導となって、デバイスの属性を変更させたり、または、デバイスを操作したりすることは非常に困難である。
【００１２】
また、従来の制御システムにおいては、サーバ−クライアント間でコマンドやレスポンスを送受信する場合、一般的に、１コマンド毎に、または１レスポンス毎に送受信が行われるため、サーバ−クライアント間での送受信の回数が多くなり、それに伴い、通信コストが高くなるという課題があった。
【００１３】
コマンドやレスポンスの送受信が行われる毎に、ヘッダやフッタなどの情報が付加されるため、それらの送受信回数が増えるにつれて、１回の通信データ量が増え、さらに、１回の送受信に要する通信時間が長くなる。この課題は、通信速度が遅く、通信コストが比較的高い、例えば、携帯電話機などの端末を遠隔操作する場合、さらに深刻なものとなる。
【００１４】
また、従来の制御システムにおいては、例えば、サーバから送信されてきたコマンドを受信したクライアントでエラーが発生した場合、エラーの内容にかかわらず、その時点で常に処理が中断されてしまい、エラーが発生した処理の次の処理をクライアントに実行させるには、サーバ−クライアント間で再接続し、コマンドを再度送信する必要があった。
【００１５】
本発明はこのような状況に鑑みてなされたものであり、ネットワークを介して接続される機器の制御を、より確実に、かつ効率的に行うことができるようにするものである。
【００１６】
【課題を解決するための手段】
本発明の制御システムの情報処理端末は、機器が接続された状態で、情報処理装置に対して、ネットワークを介した通信の確立を要求する要求手段と、要求手段による要求に応じて確立された通信により情報処理装置から送信される、機器の制御に関する命令を含むパケットを受信する受信手段と、受信手段により受信されたパケットに含まれる命令に基づいて、機器を制御する制御手段とを備え、情報処理装置は、情報処理端末からの要求に応じて、情報処理端末との間でネットワークを介した通信を確立する確立手段と、確立手段により情報処理端末との間で通信が確立されたとき、自分自身から、パケットを情報処理端末に送信する送信手段とを備えることを特徴とする。
【００１７】
本発明の制御システムの制御方法は、機器が接続された状態で、情報処理装置に対して、ネットワークを介した通信の確立を要求する要求ステップと、要求ステップの処理に応じて確立された通信により情報処理装置から送信される、機器の制御に関する命令を含むパケットを受信する受信ステップと、受信ステップの処理により受信されたパケットに含まれる命令に基づいて、機器を制御する制御ステップと、情報処理端末からの要求に応じて、情報処理端末との間でネットワークを介した通信を確立する確立ステップと、確立ステップの処理により情報処理端末との間で通信が確立されたとき、自分自身から、パケットを情報処理端末に送信する送信ステップとを含むことを特徴とする。
【００１８】
本発明の情報処理装置は、情報処理端末に機器が接続された状態で行われる情報処理端末からの要求に応じて、情報処理端末との間でネットワークを介した通信を確立する確立手段と、確立手段により情報処理端末との間で通信が確立されたとき、自分自身から、機器の制御に関する命令を含む第１のパケットを情報処理端末に送信する送信手段とを備えることを特徴とする。
【００１９】
送信手段により送信された命令に対応する、情報処理端末からの返信を含む第２のパケットを受信する受信手段をさらに備えるようにすることができる。
【００２０】
命令には、その命令に基づく処理が情報処理端末において失敗した場合に、次の命令に基づく処理を続行するか否かを表す情報が含まれるようにすることができる。
【００２１】
送信手段は、同一のプロトコルに属する複数の命令を１つの第１のパケットに含めて送信するようにすることができる。
【００２２】
送信手段は、機器による処理の結果によって、機器に次に実行させる処理を情報処理端末に判断させる簡易プログラムを、第１のパケットと共に送信するようにすることができる。
【００２３】
送信手段は、命令に基づく処理の対象となる機器を表す識別情報を含む第１のパケットを送信するようにすることができる。
【００２４】
確立手段により確立された通信経路上に情報処理端末のファイアウォールが存在する場合、送信手段は、通信プロトコルとしてHTTPを用い、第１のパケットを送信するようにすることができる。
【００２５】
送信手段は、複数の第１のパケットを送信する期間、確立手段により確立されたHTTPによる通信リンクを継続させるようにすることができる。
【００２６】
確立手段により確立された通信において、情報処理端末から所定の情報の送信が開始されるように、情報処理端末に指示する指示手段をさらに備えるようにすることができる。
【００２７】
本発明の情報処理装置の情報処理方法は、情報処理端末に機器が接続された状態で行われる情報処理端末からの要求に応じて、情報処理端末との間でネットワークを介した通信を確立する確立ステップと、確立ステップの処理により情報処理端末との間で通信が確立されたとき、自分自身から、機器の制御に関する命令を含むパケットを情報処理端末に送信する送信ステップとを含むことを特徴とする。
【００２８】
本発明の記録媒体に記録されているプログラム、および、本発明の第１のプログラムは、情報処理端末に機器が接続された状態で行われる情報処理端末からの要求に応じて、情報処理端末との間でネットワークを介した通信を確立する確立ステップと、確立ステップの処理により情報処理端末との間で通信が確立されたとき、自分自身から、機器の制御に関する命令を含むパケットを情報処理端末に送信する送信ステップとを含むことを特徴とする。
【００２９】
本発明の情報処理端末は、機器が接続された状態で、情報処理装置に対して、ネットワークを介した通信の確立を要求する要求手段と、要求手段による要求に応じて確立された通信により情報処理装置から送信される、機器の制御に関する命令を含む第１のパケットを受信する受信手段と、受信手段により受信された第１のパケットに含まれる命令に基づいて、機器を制御する制御手段とを備えることを特徴とする。
【００３０】
制御手段による機器の制御結果を表す返信を含む第２のパケットを情報処理装置に送信する送信手段をさらに備えるようにすることができる。
【００３１】
本発明の情報処理端末の情報処理方法は、機器が接続された状態で、情報処理装置に対して、ネットワークを介した通信の確立を要求する要求ステップと、要求ステップによる要求に応じて確立された通信により情報処理装置から送信される、機器の制御に関する命令を含むパケットを受信する受信ステップと、受信ステップの処理により受信されたパケットに含まれる命令に基づいて、機器を制御する制御ステップとを含むことを特徴とする。
【００３２】
本発明の記録媒体に記録されているプログラム、および、本発明の第２のプログラムは、機器が接続された状態で、情報処理装置に対して、ネットワークを介した通信の確立を要求する要求ステップと、要求ステップによる要求に応じて確立された通信により情報処理装置から送信される、機器の制御に関する命令を含むパケットを受信する受信ステップと、受信ステップの処理により受信されたパケットに含まれる命令に基づいて、機器を制御する制御ステップとを含むことを特徴とする。
【００３３】
本発明の制御システムおよび方法においては、機器が接続された状態で、情報処理装置に対して、ネットワークを介した通信の確立が要求され、要求に応じて確立された通信により情報処理装置から送信される、機器の制御に関する命令を含むパケットが受信され、受信されたパケットに含まれる命令に基づいて、機器が制御される。また、情報処理端末からの要求に応じて、情報処理端末との間でネットワークを介した通信が確立され、情報処理端末との間で通信が確立されたとき、パケットが情報処理端末に送信される。
【００３４】
本発明の情報処理装置および方法、記録媒体、並びにプログラムにおいては、情報処理端末に機器が接続された状態で行われる情報処理端末からの要求に応じて、情報処理端末との間でネットワークを介した通信が確立され、情報処理端末との間で通信が確立されたとき、機器の制御に関する命令を含む第１のパケットが情報処理端末に送信される。
【００３５】
本発明の情報処理端末および方法、記録媒体、並びにプログラムにおいては、機器が接続された状態で、情報処理装置に対して、ネットワークを介した通信の確立が要求され、要求に応じて確立された通信により情報処理装置から送信される、機器の制御に関する命令を含む第１のパケットが受信される。また、受信された第１のパケットに含まれる命令に基づいて、機器が制御される。
【００３６】
【発明の実施の形態】
図１は、本発明を適用した制御システムの構成例を示す図である。
【００３７】
ネットワーク１には、ネットワーク１に接続されるクライアント（クライアントを介してネットワーク１に接続されるデバイス）を遠隔制御するサーバ２およびサーバ４が接続されている。サーバ２には、クライアントとの間で行われる通信において、サーバ２と協働してデータの暗号化処理および復号処理、並びに認証処理を実行する暗号・認証用サーバ３が接続されている。
【００３８】
サーバ２またはサーバ４によるデバイス（機器）の制御は、クライアントを介して行われる。
【００３９】
ネットワーク１には、クライアントとしての携帯電話機５およびパーソナルコンピュータ６が接続されている。後に詳述するように、クライアント（携帯電話機５またはパーソナルコンピュータ６）と、サーバ（サーバ２またはサーバ４）の間で行われる通信においては、サーバが主導となってクライアントを制御することができるプロトコルが用いられる。
【００４０】
図１の例においては、サーバ２またはサーバ４によりクライアントを介して制御されるデバイスとして、リーダライタ１１、ICカード１３、スピーカ１４、およびディスプレイ１５が携帯電話機５に接続または内蔵されている。
【００４１】
また、携帯電話機５には、ICカード１３のように携帯電話機５に直接接続または内蔵されるのではなく、近接または載置されたときに、リーダライタ１１との間で電磁誘導を利用した通信を行う外部ICカード１２がリーダライタ１１を介して接続されている。
【００４２】
同様に、図１においては、サーバ２またはサーバ４によりクライアントを介して制御されるデバイスとして、ICカード２１、スピーカ２２、およびディスプレイ２３、リーダライタ２４がパーソナルコンピュータ６に接続されている。リーダライタ２４には、所定のタイミングで、外部ICカード２５が近接または載置される。
【００４３】
これらのデバイス（リーダライタ１１、外部ICカード１２、ICカード１３、スピーカ１４、ディスプレイ１５、ICカード２１、スピーカ２２、ディスプレイ２３、リーダライタ２４、および外部ICカード２５）は、ネットワーク１にクライアントを介して常時接続されているものではなく、所定のタイミングで接続されるものである。
【００４４】
当然、図１に示されるシステム構成は適宜変更可能である。例えば、携帯電話機５やパーソナルコンピュータ６以外にも、クライアントとしてのPDA(Personal Digital Assistants)や、デバイスとしてのメモリなどがネットワーク１を介してサーバ２やサーバ４に接続されるようにしてもよい。
【００４５】
図２は、図１のサーバ２の構成例を示すブロック図である。
【００４６】
CPU（Central Processing Unit）３１は、ROM（Read Only Memory）３２に記憶されているプログラム、または、記憶部３８からRAM（Random Access Memory）３３にロードされたプログラムに従って各種の処理を実行する。RAM３３にはまた、CPU３１が各種の処理を実行する上において必要なデータなどが適宜記憶される。
【００４７】
例えば、CPU３１により所定の制御プログラムが実行され、図１の制御システムにおいて用いられるプロトコル（以下、適宜、制御プロトコルと称する）の通信によりクライアントを制御するサーバが実現される。
【００４８】
CPU３１、ROM３２、およびRAM３３は、バス３４を介して相互に接続されている。このバス３４にはまた、入出力インタフェース３５も接続されている。
【００４９】
入出力インタフェース３５には、キーボード、マウスなどよりなる入力部３６、CRT(Cathode Ray Tube)、LCD(Liquid Crystal Display)などよりなるディスプレイ、並びにスピーカなどよりなる出力部３７、ハードディスクなどより構成される記憶部３８、モデム、ターミナルアダプタなどより構成される通信部３９が接続されている。通信部３９は、ネットワーク１を介しての通信処理を行う。
【００５０】
入出力インタフェース３５にはまた、必要に応じてドライブ４０が接続され、磁気ディスク４１、光ディスク４２、光磁気ディスク４３、或いは半導体メモリ４４などが適宜装着され、それから読み出されたコンピュータプログラムが、必要に応じて記憶部３８にインストールされる。
【００５１】
サーバ４の構成、並びに、クライアントである携帯電話機５およびパーソナルコンピュータ６の構成は、図２に示されるサーバ２の構成と基本的に同様であるため、その説明は省略する。なお、図２は、必要に応じて、携帯電話機５またはパーソナルコンピュータ６の構成としても引用される。
【００５２】
ここで、サーバとクライアントの間で行われる通信において用いられるプロトコルについて説明する。以下、適宜、サーバとクライアントの間で行われる通信において用いられるプロトコルを制御プロトコルと称する。
【００５３】
この制御プロトコルにより、クライアントにおいて実行されているWebアプリケーションの背後で、クライアントとサーバ間の通信が行われる。なお、携帯電話機５などでは、Webアプリケーションは必要なく、クライアントとの機器通信のみの場合がある。この場合、例えば、携帯電話機５のアプリケーションが、表示用データを全て保持しており、デバイスの制御と同様に、アプリケーションやディスプレイに対して制御を行うことにより、表示等を行う。
【００５４】
制御プロトコルを使用してWebアプリケーションを開発することにより、例えば、第１に、ビジネスロジックを１つの関数／メソッドの中に記述することができ（HTTP(Hyper Text Transfer Protocol)コネクションが毎回切れることを意識する必要がない）、第２に、サーバからクライアントに対してリクエストを送信させることができ（HTTPの「リクエストの送信元は常にクライアント」という制限を受けない）、第３に、クライアント上で任意の処理を実行させることができる（Applet，ActiveXコントロールのような制限を受けない）。
【００５５】
制御プロトコルは、Data Transfer Protocolと、その他のサブプロトコルで構成される。例えば、サブプロトコルとして、Handshake Protocol，Farewell Protocol，Error Protocol，Update Entity Protocol，Application Data Transfer Protocol，Operate Entity Protocolの６つが規定される。
【００５６】
具体的には、Data Transfer Protocolは、サブプロトコル電文の送受信手順を規定するものであり、Handshake Protocolは、コネクションの確立手順を規定するものである。また、Farewell Protocolは、コネクションの開放手順を規定するものであり、Error Protocolは、エラーの通知手順を規定するものである。
【００５７】
さらに、Update Entity Protocolは、サーバがクライアントの状態を変更する手順を規定するものであり、Application Data Transfer Protocolは、アプリケーション固有のデータの送受信手順を規定するものであり、Operate Entity Protocolは、サーバがクライアントを操作する手順を規定するものである。
【００５８】
これらのプロトコルを含む制御プロトコルは、データ通信の核（枠）となる部分だけを定義するものであり、所定のデバイスを操作するなど、アプリケーション固有の処理を実行するには、そのアプリケーション用のエクステンション（拡張モジュール）が必要である。すなわち、制御プロトコルによって、制御プロトコル本体とエクステンションが協調して動作するための手順が定義される。
【００５９】
図３は、制御プロトコルに基づく通信を実現するサーバ（例えば、サーバ２）の機能構成例を示すブロック図である。図３に示される各機能ブロックは、例えば、サーバ２のCPU３１により、所定の制御プログラムが実行されて実現される。
【００６０】
制御部５１は、Handshake Protocolに属するメッセージ（命令）を管理するHandshakeメッセージ管理部５２、Farewell Protocolに属するメッセージを管理するFarewellメッセージ管理部５５、Error Protocolに属するメッセージを管理するErrorメッセージ管理部５８、Application Data Transfer Protocolに属するメッセージを管理するApplication Data Transferメッセージ管理部６１、Update Entity Protocolに属するメッセージを管理するUpdate Entityメッセージ管理部６４、および、Operate Entity Protocolに属するメッセージを管理するOperate Entityメッセージ管理部６７を含む、サーバ２の機能全体を制御する。
【００６１】
なお、Handshake Protocolに属するメッセージ（以下、適宜、Handshakeメッセージと称する）については図７を参照して、Farewell Protocolに属するメッセージ（以下、適宜、Farewellメッセージと称する）については図９を参照して、Error Protocolに属するメッセージ（以下、適宜、Errorメッセージと称する）については図１１を参照して、Update Entity Protocolに属するメッセージ（以下、適宜、Update Entityメッセージと称する）については図１４を参照して、Application Data Transfer Protocolに属するメッセージ（以下、適宜、Application Data Transferメッセージと称する）については図１６を参照して、Operate Entity Protocolに属するメッセージ（以下、適宜、Operate Entityメッセージと称する）については図１８を参照して、それぞれ詳述する。
【００６２】
Handshakeメッセージ管理部５２は、Handshakeメッセージに関する処理を管理し、例えば、クライアントからパケットに含められて送信されてきたHandshakeメッセージがHandshakeメッセージ受信制御部５４から供給されてきたとき、そのメッセージに応じたHandshakeメッセージを生成し、クライアントに対して送信すべく、生成したHandshakeメッセージをHandshakeメッセージ送信制御部５３に出力する。
【００６３】
Handshakeメッセージ送信制御部５３は、図２の通信部３９において行われる、携帯電話機５などのクライアントに対するHandshakeメッセージの送信を制御し、Handshakeメッセージ受信制御部５４は、図２の通信部３９において行われる、クライアントから送信されてきたHandshakeメッセージの受信を制御する。
【００６４】
Farewellメッセージ管理部５５は、Farewellメッセージに関する処理を管理し、例えば、クライアントからパケットに含められて送信されてきたFarewellメッセージがFarewellメッセージ受信制御部５７から供給されてきたとき、そのメッセージに応じたFarewellメッセージを生成し、クライアントに対して送信すべく、生成したFarewellメッセージをFarewellメッセージ送信制御部５６に出力する。
【００６５】
Farewellメッセージ送信制御部５６は、図２の通信部３９において行われる、クライアントに対するFarewellメッセージの送信を制御し、Farewellメッセージ受信制御部５７は、図２の通信部３９において行われる、クライアントから送信されてきたFarewellメッセージの受信を制御する。
【００６６】
Errorメッセージ管理部５８は、Errorメッセージに関する処理を管理し、例えば、クライアントから送信されてきたパケットにフォーマットのエラーが存在することが制御部５１により検出されたとき、それに対応するErrorメッセージを生成し、クライアントに対して送信すべく、生成したErrorメッセージをErrorメッセージ送信制御部５９に出力する。
【００６７】
Errorメッセージ送信制御部５９は、図２の通信部３９において行われる、クライアントに対するErrorメッセージの送信を制御し、Errorメッセージ受信制御部６０は、図２の通信部３９において行われる、クライアントから送信されてきたErrorメッセージの受信を制御する。
【００６８】
Application Data Transferメッセージ管理部６１は、Application Data Transferメッセージに関する処理を管理し、例えば、クライアントからパケットに含められて送信されてきたApplication Data TransferメッセージがApplication Data Transferメッセージ受信制御部６３から供給されてきたとき、そのメッセージに応じたApplication Data Transferメッセージを生成し、クライアントに対して送信すべく、生成したApplication Data TransferメッセージをApplication Data Transferメッセージ送信制御部６２に出力する。
【００６９】
Application Data Transferメッセージ送信制御部６２は、図２の通信部３９において行われる、クライアントに対するApplication Data Transferメッセージの送信を制御する。具体的には、Application Data Transferメッセージ送信制御部６２は、Application Data Transferメッセージ管理部６１から供給されてきた所定の数のメッセージにFINISHDメッセージを付加し、１つのパケットとしてクライアントに送信する。
【００７０】
Application Data Transferメッセージ受信制御部６３は、図２の通信部３９において行われる、クライアントから送信されてきたApplication Data Transferメッセージの受信を制御する。具体的には、Application Data Transferメッセージ受信制御部６３は、クライアントから送信されてきたパケットの終端を、それに含まれるFINISHDメッセージにより検出し、パケットに含まれるApplication Data TransferメッセージをApplication Data Transferメッセージ管理部６１に出力する。
【００７１】
Update Entityメッセージ管理部６４は、Update Entityメッセージに関する処理を管理し、例えば、制御部５１から、所定のUpdate Entityメッセージをクライアントに対して送信することが指示されたとき、指示に対応するUpdate Entityメッセージを生成し、クライアントに対して送信すべく、生成したUpdate EntityメッセージをUpdate Entityメッセージ送信制御部６５に出力する。
【００７２】
Update Entityメッセージ送信制御部６５は、図２の通信部３９において行われる、クライアントに対するUpdate Entityメッセージの送信を制御する。具体的には、Update Entityメッセージ送信制御部６５は、Update Entityメッセージ管理部６４から供給されてきた所定の数のメッセージにFINISHDメッセージを付加し、１つのパケットとしてクライアントに送信する。
【００７３】
Update Entityメッセージ受信制御部６６は、図２の通信部３９において行われる、クライアントから送信されてきたUpdate Entityメッセージの受信を制御する。具体的には、Update Entityメッセージ受信制御部６６は、クライアントから送信されてきたパケットの終端を、それに含まれるFINISHDメッセージにより検出し、パケットに含まれるUpdate EntityメッセージをUpdate Entityメッセージ管理部６４に出力する。
【００７４】
Operate Entityメッセージ管理部６７は、Operate Entityメッセージに関する処理を管理し、例えば、制御部５１から、所定のOperate Entityメッセージをクライアントに対して送信することが指示されたとき、指示に対応するOperate Entityメッセージを生成し、クライアントに対して送信すべく、生成したOperate EntityメッセージをOperate Entityメッセージ送信制御部６８に出力する。
【００７５】
Operate Entityメッセージ送信制御部６８は、図２の通信部３９において行われる、クライアントに対するOperate Entityメッセージの送信を制御する。具体的には、Operate Entityメッセージ送信制御部６８は、Operate Entityメッセージ管理部６７から供給されてきた所定の数のメッセージにFINISHDメッセージを付加し、１つのパケットとしてクライアントに送信する。
【００７６】
Operate Entityメッセージ受信制御部６９は、図２の通信部３９において行われる、クライアントから送信されてきたOperate Entityメッセージの受信を制御する。具体的には、Operate Entityメッセージ受信制御部６９は、クライアントから送信されてきたパケットの終端を、それに含まれるFINISHDメッセージにより検出し、パケットに含まれるOperate EntityメッセージをOperate Entityメッセージ管理部６７に出力する。
【００７７】
図４は、制御プロトコルに基づく通信を実現するクライアント（例えば、携帯電話機５）の機能構成例を示すブロック図である。図４に示される構成は、基本的には図３に示されるサーバ側の構成と同様であるため、上述したものと重複する説明については適宜省略する。
【００７８】
図４に示される各構成は、例えば、携帯電話機５のCPU３１により、所定の制御プログラムが実行されて実現される。
【００７９】
制御部８１は、Handshakeメッセージ管理部８２、Farewellメッセージ管理部８５、Errorメッセージ管理部８８、Application Data Transferメッセージ管理部９１、Update Entityメッセージ管理部９４、および、Operate Entityメッセージ管理部９７を含む、携帯電話機５（クライアント）の機能全体を制御する。
【００８０】
例えば、制御部８１は、サーバから送信され、Update Entityメッセージ受信制御部９６において受信された所定のUpdate EntityメッセージがUpdate Entityメッセージ管理部９４を介して供給されてきたとき、デバイス制御部１００を制御し、供給されてきたUpdate Entityメッセージに基づく処理をデバイスに実行させる。
【００８１】
また、制御部８１は、クライアント自身に接続されているデバイスにより所定の処理を実行させたとき、デバイスによる実行結果（例えば、処理が成功したか否かを表す情報）をデバイス制御部１００から取得し、それをUpdate Entityメッセージ管理部９４に出力する。
【００８２】
Update Entityメッセージ管理部９４においては、処理結果に基づくレスポンスメッセージ（Update Entityメッセージ）が生成され、Update Entityメッセージ送信制御部９５を介して、クライアントに対して送信される。
【００８３】
デバイス制御部１００は、Application Data Transferメッセージ受信制御部９３により取得されたApplication Data Transferメッセージが制御部８１に供給され、それに基づく処理をデバイスに実行させることが制御部８１から指示されたとき、また、Update Entityメッセージ受信制御部９６により取得されたUpdate Entityメッセージが制御部８１に供給され、それに基づく処理をデバイスに実行させることが制御部８１から指示されたとき、或いは、Operate Entityメッセージ受信制御部９９により取得されたOperate Entityメッセージが制御部８１に供給され、それに基づく処理をデバイスに実行させることが制御部８１から指示されたとき、それらの指示に基づいて、クライアント自身に接続されているデバイスの動作を制御する。
【００８４】
また、デバイス制御部１００は、その制御結果（デバイスによる処理結果）を制御部８１に出力する。この処理結果に基づいて、Application Data Transferメッセージ管理部９１、Update Entityメッセージ管理部９４、または、Operate Entityメッセージ管理部９７においてサーバに対するレスポンスが生成される。
【００８５】
次に、図５を参照して、制御プロトコルの状態遷移について説明する。なお、それぞれの状態において行われる通信の詳細については後述するものとする。
【００８６】
ステップＳ１において、クライアント（例えば、携帯電話機５）のCPU３１によりクライアントプログラムが起動され、状態遷移が開始される。起動時には、例えば、以下の各情報が必要となる。
【００８７】
・サーバURL(Uniform Resource Locator)
クライアントを制御するサーバのURL（例：http://www.oge.com/webapp/Server）
【００８８】
・ビュー表示WebアプリケーションURL
アプリケーションの前面でエンドユーザに対してビュー（画面）を提供するWebアプリケーションのURL（例：http://www.oge.com/webapp/ViewDispatcher）
【００８９】
なお、携帯電話機５等において、Webアプリケーションが必要ない場合、このURLは必要ない。
【００９０】
・クッキー（オプション）
セッションを識別するためのクッキー
【００９１】
クライアントは、サーバURLにより指定されたサーバ（例えば、サーバ２）に対して、指定されたセッションIDを使ってHTTPリクエストを送信する。上述した例においては、「www.oge.com」の所定のポート番号に対して、「/webapp/Server」に電文をPOSTするHTTPリクエストが送信される。
【００９２】
なお、起動時にクッキー情報がセットされた場合、クライアントは、HTTPリクエストのCookieヘッダに、指定されたクッキー情報を付加する。
【００９３】
サーバからの返信電文はHTTPレスポンスのコンテンツ部に格納される。
【００９４】
起動後、クライアントは、ステップＳ２において、Handshakeサブプロトコルを使ってCLIENT_HELLOメッセージをサーバに送信し、通信の確立を要求する。CLIENT_HELLOメッセージが送信されてから、コネクションが確立されるまでの状態がHandshakeステートとされる（図５のstate1）。
【００９５】
クライアントは、Handshake Protocolを終了したとき、ステップＳ３において、サーバに対してFINISHEDメッセージを送信する。これによりコネクションが確立され、制御の主導権がサーバに移る。
【００９６】
なお、CLIENT_HELLO_DONEをクライアントからサーバへ送信することにより、コネクションが確立される場合もある（図２５参照）。
【００９７】
すなわち、サーバからクライアントに対して所定のコマンド（メッセージ）が送信され、そのメッセージに基づく処理結果などを表すレスポンスがクライアントからサーバに返信される。コネクションが確立し、主導権がサーバに移った状態がNeutralステートとされる（図５のstate2）。
【００９８】
Neutralステートの状態にあるステップＳ４において、サーバは、自分自身が主導的に、アプリケーションのロジックに従って、クライアントの状態制御、またはアプリケーション固有データの送受信を行う。
【００９９】
このとき、クライアントの状態制御には、Update Entityサブプロトコルが用いられ、アプリケーション固有データの送受信にはApplication Data Transferサブプロトコルが用いられる。また、クライアント側のデバイスの操作にはOperate Entityサブプロトコルが用いられる。
【０１００】
Neutralステートに限り、これらの３つのサブプロトコルのパケットを、任意の順序で、複数同時に送受信することが可能とされる。例えば、図２０乃至図２２を参照して後述するように、１つのパケットに含めることができるサブプロトコル種別は１種類であり（１種類のサブプロトコルのヘッダおよびメッセージ列により１つのパケットが構成され）、それぞれのパケットの末尾には、そのサブプロトコルのFinishedメッセージが含まれる。
【０１０１】
また、Neutralステートで使用されるサブプロトコル（Update Entity，Application Data Transfer，Operate Entity）によりサーバからクライアントに対して送信されるそれぞれのメッセージには、処理に失敗した場合に、それに続く後続のメッセージの処理を続行するのか、または、中止するのかをクライアントに判断させる情報が含まれている。
【０１０２】
例えば、クライアントは、先頭ビットが「０」であるメッセージの処理に失敗した場合、後続のメッセージの処理を中止し、一方、先頭ビットが「１」であるメッセージの処理に失敗した場合、後続のメッセージの処理を続行する。各サブプロトコルの拡張メッセージについても同様である。
【０１０３】
アプリケーションのロジックが終了したとき、サーバは、ステップＳ５において、Farewellサブプロトコルを使ってSERVER_GOOD_BYEメッセージをクライアントに送信する。SERVER_GOOD_BYEメッセージが送信されてから、コネクションが開放されるまでの状態がFarewellステートとされる（図５のstate3）。
【０１０４】
サーバは、Farewell Protocolが終了したと判断したとき、ステップＳ６において、クライアントに対してFINISHEDメッセージを送信し、コネクションを終了させる。クライアントにおいては、ステップＳ７で、リソースが開放され、処理が終了される。
【０１０５】
なお、SERVER_GOOD_BYE_DONEをサーバからクライアントへ送信することにより、Farewellステートを経ずに、コネクションが終了され、クライアントにおいて、リソースが開放されて、処理が終了する場合もある（図２５）。
【０１０６】
また、任意の場所（状態）で処理を続行することが不可能なエラーが発生した場合、クライアントまたはサーバは、ステップＳ８において、Errorサブプロトコルを用いてエラーメッセージを相手に送信する。エラーが発生してから制御プロトコルによる通信が終了されるまでの状態がErrorステートとされる（図５のstate4）。
【０１０７】
ステップＳ９において、例えば、サーバからFINISHEDメッセージがクライアントに送信されたとき、Errorステートが終了され、コネクションが終了される。
【０１０８】
以上のような状態遷移を有する制御プロトコルに従って、クライアントとサーバ間で通信が行われる。
【０１０９】
次に、Data Transfer Protocolにより規定されるパケットのデータフォーマットについて説明する。
【０１１０】
図６は、パケットのデータフォーマットの例を示す図である。
【０１１１】
図６に示されるように、パケットは、所定の数のメッセージ（サブプロトコル用の電文）からなるメッセージ列と、ヘッダから構成される。
【０１１２】
ヘッダは、さらに、Version，Sub Protocol Type(SPT)，Lengthの３つのフィールドから構成される。
【０１１３】
Versionにより制御プロトコルのバージョン番号が表される。例えば、Versionのうちの上位バイトによりメジャーバージョン番号が表され、下位バイトによりマイナーバージョン番号が表される。Data Transfer Protocolの変更によりメジャーバージョン番号が上がり、サブプロトコルの追加または変更により、マイナーバージョン番号が上がる。
【０１１４】
Sub Protocol TypeによりHandshake Protocol，Farewell Protocol，Error Protocol，Application Data Transfer Protocol，Update Entity Protocol， Operate Entity Protocolのうちの、パケットで用いられているサブプロトコルの種別が表される。
【０１１５】
Lengthによりメッセージ列の長さが表される。
【０１１６】
一方、メッセージ列に含まれる１つのメッセージは、Extension(Ext)，Device ID(DID)，Message Type(MT)，Length，Dataのフィールドから構成される。
【０１１７】
Extensionによりアプリケーションドメイン固有の処理を実行するためのエクステンションの種別が表される。
【０１１８】
Device IDによりメッセージが対象とするデバイスのIDが表される。例えば、クライアントに複数のデバイスが接続されている場合、そのデバイス全体がメッセージの適用範囲とされるようなIDや、サーバ／クライアントとも、デバイスを意識することなくメッセージの適用範囲を決定するIDなども必要に応じて規定される。
【０１１９】
Message Typeによりメッセージの種別が表される。後に詳述するように、例えば、Handshakeプロトコルには、クライアントからサーバに対して行われるCLIENT_HELLOメッセージや、サーバからクライアントに対して行われるSERVER_HELLOメッセージなどが規定されているが、それらのメッセージの種別がMessage Typeにより表される。
【０１２０】
Lengthにより、メッセージのデータ部（Data）の長さが表される。メッセージのデータ部のデータフォーマットはメッセージタイプに依存する。
【０１２１】
次に、上述したそれぞれのサブプロトコルについて説明する。
【０１２２】
図７は、Handshake Protocolにおいて用いられるメッセージを示す図である。
【０１２３】
図７に示されるように、FINISHEDメッセージはサブプロトコルの終了を意味し、WARNINGメッセージは警告の通知を意味する。WARNINGメッセージのデータ部には、所定の文字列からなる警告メッセージが含まれる。
【０１２４】
CLIENT_HELLOメッセージはクライアントからサーバに対するHandshakeデータの送信開始を意味し、CLIENT_HELLO_DONEメッセージはHandshakeデータの送信終了を意味する。
【０１２５】
SERVER_HELLOメッセージはサーバからクライアントに対するHandshakeデータの送信開始を意味し、SERVER_HELLO_DONEメッセージはHandshakeデータの送信終了を意味する。
【０１２６】
DEVICESメッセージはデバイスリストの通知を意味し、そのデータ部により、デバイス固有のデバイスID、パーミッション、タイプ名長、タイプ名、デバイス名長、およびデバイス名が表される。例えば、パーミションによりデバイスに対するアクセス権の有無が表され、「０」がアクセス可（操作可）、「１」がアクセス不可（操作不可）とされる。
【０１２７】
例えば、DEVICESメッセージにより、クライアントに接続されている、操作対象のデバイスリストの通知や、デバイスに実行させることが可能な処理の通知が行われる。
【０１２８】
次に、図８のシーケンスを参照して、図７に示されるメッセージを用いて行われるHandshake Protocolについて説明する。以下のシーケンスにおいては、制御プロトコルによる通信によりデバイスを制御するサーバとしてのサーバ２と、クライアントとしての携帯電話機５により実行される処理について説明する。
【０１２９】
Handshake Protocolは、ステップＳ２１において、例えば、携帯電話機５（クライアント）のHandshakeメッセージ送信制御部８３（図４）がCLIENT_HELLOメッセージを、例えば、サーバ２（サーバ）に送信することにより開始される。すなわち、制御部８１からの指示に応じて、Handshakeメッセージ管理部８２においてCLIENT_HELLOメッセージが生成され、Handshakeメッセージ送信制御部８３によりサーバ２に送信される。
【０１３０】
携帯電話機５のHandshakeメッセージ送信制御部８３は、ステップＳ２２において、自分自身に接続されているデバイスであって、かつ、サーバ２によるコントロールを許可する全てのデバイスに関する情報を、DEVICESメッセージを用いてサーバに通知する。このDEVICESメッセージも、制御部８１の指示に基づいてHandshakeメッセージ管理部８２により生成されたものである。
【０１３１】
DEVICESメッセージにより、例えば、携帯電話機５に接続されているリーダライタ１１、およびリーダライタ１１を介して接続されている外部ICカード１２に関する情報などがサーバ２に通知される。
【０１３２】
アプリケーション固有のメッセージがステップＳ２３において送信され、ステップＳ２４においてCLIENT_HELLO_DONEメッセージが送信されたとき、携帯電話機５からサーバ２に対するHandshakeデータの送信が終了される。
【０１３３】
一方、携帯電話機５から送信されてきたCLIENT_HELLOメッセージ、DEVICESメッセージ、アプリケーション固有のメッセージ、および、CLIENT_HELLO_DONEメッセージがステップＳ４１乃至Ｓ４４においてサーバ２のHandshakeメッセージ受信制御部５４で取得されたとき、ステップＳ４５に進み、Handshakeメッセージ送信制御部５３（図３）は、携帯電話機５に対してSERVER_HELLOメッセージを送信する。
【０１３４】
また、サーバ２のHandshakeメッセージ送信制御部５３は、ステップＳ４６において、アプリケーション固有のメッセージを送信し、ステップＳ４７に進み、SERVER_HELLO_DONEメッセージを送信する。ここでは、Handshake Protocolにおいて送信される、アプリケーション固有のメッセージを含む全てのメッセージがHandshakeメッセージ送信制御部５３の制御の下に送信されている。
【０１３５】
サーバ２から送信されたSERVER_HELLOメッセージ、アプリケーション固有のメッセージ、およびSERVER_HELLO_DONEメッセージは、ステップＳ２５乃至Ｓ２７において携帯電話機５のHandshakeメッセージ受信制御部８４によりそれぞれ受信される。
【０１３６】
サーバ２のHandshakeメッセージ送信制御部５３は、携帯電話機５と自分自身の双方がHELLO_DONEメッセージ（CLIENT_HELLO_DONEメッセージ、SERVER_HELLO_DONEメッセージ）を送信したとき、ステップＳ４８において、さらに、携帯電話機５に対してFINISHEDメッセージを送信する。
【０１３７】
サーバ２から送信されたFINISHEDメッセージは、ステップＳ２８において、携帯電話機５のHandshakeメッセージ受信制御部８４により受信される。
【０１３８】
携帯電話機５のHandshakeメッセージ送信制御部８３は、ステップＳ２９においてアプリケーション固有のメッセージを送信し、ステップＳ３０に進み、サーバ２に対してFINISHEDメッセージを送信する。携帯電話機５から送信されたアプリケーション固有のメッセージとFINISHEDメッセージは、ステップＳ４９とＳ５０においてサーバ２のHandshakeメッセージ受信制御部５４によりそれぞれ受信され、これにより携帯電話機５とサーバ２の双方においてHandshake Protocolが終了される。
【０１３９】
なお、図８の一点鎖線は、アプリケーション固有のメッセージの送受信が必要な場合にのみ、それぞれ所定の数だけ送信されることを表している。例えば、ステップＳ２３において、メッセージが送信されない場合もあるし、複数のメッセージが送信される場合もある。後述する図１０においても同様である。
【０１４０】
また、図８においては、ステップＳ５０において、サーバ２によりFINISHEDメッセージが受信されたときにHandshake Protocolが終了されるとしたが、その前に、ステップＳ４４において、サーバ２で受信されたCLIENT_HELLO_DONEメッセージが受信されたときに、Handshake Protocolが終了されるようにしてもよい。
【０１４１】
さらに、図８においては、サーバ２と携帯電話機５から、それぞれHELLOメッセージとHELLO DONEメッセージが送信されるとしたが、携帯電話機５からのみ、それらのメッセージがサーバ２に対して送信されるようにしてもよい。これにより、Handshake Protocolの確実性は多少損なわれるものの、Handshake Protocolを迅速に終了させ、Neutralステートにおける処理を迅速に開始させることができる。換言すれば、携帯電話機５とサーバ２の双方が_HELLOメッセージと_HELLO DONEメッセージを送受信することにより、より確実に、Handshake Protocolを実行させることができる。
【０１４２】
図９は、Farewell Protocolにおいて用いられるメッセージを示す図である。
【０１４３】
FINISHEDメッセージはサブプロトコルの終了を意味し、WARNINGメッセージは警告の通知を意味する。WARNINGメッセージのデータ部には、所定の文字列からなる警告メッセージが含まれる。
【０１４４】
CLIENT_GOOD_BYEメッセージは、クライアントからサーバに対するFarewellデータの送信開始を意味し、CLIENT_GOOD_BYE_DONEメッセージはFarewellデータの送信終了を意味する。
【０１４５】
一方、SERVER_GOOD_BYEメッセージは、サーバからクライアントに対するFarewellデータの送信開始を意味し、SERVER_GOOD_BYE_DONEメッセージはFarewellデータの送信終了を意味する。
【０１４６】
RETURN_CODEメッセージはサーバによる終了コードの通知を意味し、そのメッセージのデータ部には終了コードが含まれる。
【０１４７】
次に、図１０のシーケンスを参照して、図９に示されるメッセージを用いて行われるFarewell Protocolについて説明する。
【０１４８】
ステップＳ８１において、サーバ２（サーバ）のFarewellメッセージ送信制御部５６がSERVER_GOOD_BYEメッセージを送信することによりFarewell Protocolが開始される。このように、Farewell Protocolは、通信の主導権を有するサーバ２からのメッセージにより開始される（図５を参照して説明したように、Handshake Protocolが終了した後は、サーバが通信の主導権を有している）。
【０１４９】
サーバ２のFarewellメッセージ送信制御部５６は、ステップＳ８２において、携帯電話機５（クライアント）に対してRETURN_CODEメッセージを送信し、ステップＳ８３に進み、アプリケーション固有のメッセージ（Extension中のFarewell用拡張メッセージ）を送信する。
【０１５０】
また、サーバ２のFarewellメッセージ送信制御部５６は、全てのアプリケーション固有のメッセージを送信した後、ステップＳ８４に進み、SERVER_GOOD_BYE_DONEメッセージを携帯電話機５に送信する。
【０１５１】
ステップＳ８１乃至Ｓ８４においてサーバ２から送信された情報は、それぞれステップＳ６１乃至Ｓ６４において携帯電話機５のFarewellメッセージ受信制御部８７により受信される。
【０１５２】
携帯電話機５のFarewellメッセージ送信制御部８６は、ステップＳ６５において、サーバ２に対してCLIENT_GOOD_BYEメッセージを送信する。
【０１５３】
また、携帯電話機５のFarewellメッセージ送信制御部８６は、ステップＳ６６において、アプリケーション固有のメッセージを送信し、ステップＳ６７に進み、CLIENT_GOOD_BYE_DONEメッセージを送信する。
【０１５４】
携帯電話機５のFarewellメッセージ送信制御部８６は、CLIENT_GOOD_BYE_DONEメッセージをサーバ２に対して送信した後、ステップＳ６８に進み、FINISHEDメッセージを送信する。ステップＳ６５乃至Ｓ６８において携帯電話機５のFarewellメッセージ送信制御部８６から送信された情報は、それぞれステップＳ８５乃至Ｓ８８においてサーバ２のFarewellメッセージ受信制御部５７により受信される。
【０１５５】
サーバ２のFarewellメッセージ受信制御部５７により、携帯電話機５から送信されてきたFINISHEDメッセージがステップＳ８８において受信されたとき、ステップＳ８９に進み、Farewellメッセージ送信制御部５６から携帯電話機５に対してFINISHEDメッセージが送信され、Farewell Protocolが終了される。サーバ２のFarewellメッセージ送信制御部５６から送信されたFINISHEDメッセージは、ステップＳ６９において携帯電話機５により受信される。
【０１５６】
なお、ステップＳ８４において、SERVER_GOOD_BYE_DONEを送信することにより、Farewell Protocolが終了されるようにしてもよい。これにより、Farewell Protocolを迅速に終了させることができる。
【０１５７】
図１１は、Error Protocolにおいて用いられるメッセージを示す図である。
【０１５８】
FINISHEDメッセージはサブプロトコルの終了を意味し、WARNINGメッセージは警告の通知を意味する。WARNINGメッセージのデータ部には、所定の文字列からなる警告メッセージが含まれる。
【０１５９】
PACKET_FORMAT_ERRORメッセージはパケットのフォーマットにエラーがあることを意味し、ILLEGAL_STATE_ERRORメッセージは不正なメッセージを検知したことを意味する。
【０１６０】
UNEXPECTED_ERRORメッセージは、予期しないエラーが発生したことを意味する。
【０１６１】
PACKET_FORMAT_ERRORメッセージ、ILLEGAL_STATE_ERRORメッセージ、およびUNEXPECTED_ERRORメッセージのそれぞれのデータ部には、エラーの内容を表す、所定の文字列からなるエラーメッセージが含まれる。
【０１６２】
次に、図１２および図１３のシーケンスを参照して、図１１に示されるメッセージを用いて行われるError Protocolについて説明する。
【０１６３】
図１２は、携帯電話機５によりエラーが検出された場合のError Protocolのシーケンスを示す図である。
【０１６４】
携帯電話機５の制御部８１は、その後の処理を続行することが不可能なエラーを検知した場合、ステップＳ１０１において、ERRORメッセージ管理部８８を制御し、図１１のメッセージ（PACKET_FORMAT_ERRORメッセージ、ILLEGAL_STATE_ERRORメッセージ、またはUNEXPECTED_ERRORメッセージ）を用いて、エラーを検知したこと（検知されたエラーの内容）をサーバ２に通知する。すなわち、制御部８１からの指示に応じた所定のメッセージがERRORメッセージ管理部８８により生成され、それがERRORメッセージ送信制御部８９から送信される。
【０１６５】
その後、携帯電話機５によるステップＳ１０２およびＳ１０３、並びにサーバ２によるステップＳ１１２およびＳ１１３の処理により、携帯電話機５とサーバ２間でFINISHEDメッセージが送受信され、図５を参照して説明したように、サーバ−クライアント間の通信が終了される。
【０１６６】
図１３は、サーバ２によりエラーが検出された場合のError Protocolのシーケンスを示す図である。
【０１６７】
サーバ２の制御部５１は、その後の処理を続行することが不可能なエラーを検知した場合、ステップＳ１３１において、ERRORメッセージ管理部５８を制御し、検知したエラーの内容に応じたメッセージを用いて、エラーを検知したことを携帯電話機５に通知する。すなわち、制御部５１からの指示に応じた所定のメッセージがERRORメッセージ管理部５８により生成され、それがERRORメッセージ送信制御部５９から送信される。
【０１６８】
サーバ２のERRORメッセージ送信制御部５９は、エラーを検知したことを通知したとき、ステップＳ１３２に進み、携帯電話機５に対してFINISHEDメッセージを送信する。
【０１６９】
サーバ２から送信されたメッセージがステップＳ１２１およびＳ１２２において携帯電話機５により受信され、通信が終了される。
【０１７０】
以上のように、サーバ２および携帯電話機５は、それぞれのサブプロトコルに基づく通信において、エラーを検知した場合、任意のタイミングで相手側に対してErrorメッセージを送信することができる。
【０１７１】
なお、上述したErrorサブプロトコルによるメッセージだけでなく、アプリケーションにより独自に規定されたエラー通知メッセージが用いられて、相手側にエラーの検知が通知されるようにしてもよい。
【０１７２】
また、ErrorメッセージのうちのWARNINGメッセージは、シーケンスに影響を与えない。すなわち、WARNINGメッセージが受信された側において、メッセージの内容がログに出力されるようにしてもよいし、無視されるようにしてもよい。
【０１７３】
図１４は、Update Entity Protocolにおいて用いられるメッセージを示す図である。
【０１７４】
Update Entity Protocolのメッセージは、例えば、図１のリーダライタ１１の表面に設けられているLED(Light Emitting Diode)を発光させたり、または、所定のデバイスの電源をオンにするなど、デバイスの状態（属性）を変更させるときに用いられる。
【０１７５】
FINISHEDメッセージはパケットの終端を意味し、WARNINGメッセージは警告の通知を意味する。WARNINGメッセージのデータ部には所定の文字列からなる警告メッセージが含まれる。
【０１７６】
SET_PROPERTYメッセージは、サーバからクライアントに対して送信され、クライアントに接続されているデバイスの属性値の設定を意味する。SET_PROPERTYメッセージに対するクライアントからの返信は、PROPERTY_SETメッセージにより行われる。
【０１７７】
このSET_PROPERTYメッセージは、メッセージに基づく処理がクライアントにおいて失敗したとき、後続のメッセージの処理を中止しなければならないメッセージである。従って、SET_PROPERTYメッセージの先頭ビットは、後続のメッセージの処理を中断するように設定される。
【０１７８】
SET_PROPERTYメッセージのデータ部には、属性名長、属性名、属性値長、属性値などの、デバイスに新たに設定させる属性に関する情報が含まれる。
【０１７９】
PROPERTY_SETメッセージは、サーバから送信されてきたSET_PROPERTYメッセージに対するクライアントからの返信を意味し、そのデータ部には、SET_PROPERTYメッセージに基づく処理がクライアントにおいて成功したのか否かを表すフラグが含まれる。
【０１８０】
GET_PROPERTYメッセージは、サーバからクライアントに対して送信され、クライアントに接続されたデバイスの属性値の取得を意味する。GET_PROPERTYメッセージに対するクライアントからの返信は、PROPERTYメッセージにより行われる。
【０１８１】
このGET_PROPERTYメッセージは、メッセージに基づく処理がクライアントにおいて失敗したとき、後続のメッセージの処理を中止しなければならないメッセージである。従って、GET_PROPERTYメッセージの先頭ビットは、後続のメッセージの処理を中断するように設定される。
【０１８２】
GET_PROPERTYメッセージのデータ部には、属性値の取得を要求するデバイスの属性名長、および属性名などの情報が含まれる。
【０１８３】
PROPERTYメッセージは、サーバから送信されてきたGET_PROPERTYメッセージに対するクライアントからの返信を意味し、そのデータ部には、サーバからの要求に対応する、デバイスの属性値長および属性値などの情報が含まれる。
【０１８４】
SET_NETWORK_TIMEOUTメッセージは、クライアントのネットワークタイムアウト値の設定を意味する。
【０１８５】
このSET_NETWORK_TIMEOUTメッセージは、メッセージに基づく処理がクライアントにおいて失敗した場合であっても、後続のメッセージの処理を継続するメッセージである。従って、SET_NETWORK_TIMEOUTメッセージの先頭ビットは、後続のメッセージの処理を継続するように設定される。
【０１８６】
SET_NETWORK_TIMEOUTメッセージのデータ部には、クライアントに設定させるタイムアウト値が含まれる。
【０１８７】
次に、図１５のシーケンスを参照して、図１４に示されるメッセージを用いて行われるUpdate Entity Protocolについて説明する。
【０１８８】
携帯電話機５に接続されたデバイスの状態を変更するとき、サーバ２のUpdate Entityメッセージ管理部６４は、制御部５１による制御に基づいて、ステップＳ１５１において、携帯電話機５に送信するUpdate Entityメッセージを生成する。生成されたUpdate EntityメッセージはUpdate Entityメッセージ送信制御部６５に出力される。
【０１８９】
サーバ２のUpdate Entityメッセージ送信制御部６５は、ステップＳ１５２において、ステップＳ１５１で生成されたUpdate Entityメッセージ列の末尾にFINISHEDメッセージを付加し、Update Entityメッセージ列とFINISHEDメッセージからなるパケットを携帯電話機５に送信する。
【０１９０】
すなわち、ステップＳ１５１で生成される所定の数のUpdate Entityメッセージと、ステップＳ１５２で付加される１つのFINISHEDメッセージからなる１つのパケットが携帯電話機５に対して送信される。
【０１９１】
このように、１つのパケットに複数のメッセージを含めて携帯電話機５に送信することができるため（複数のメッセージを送信するのに１つのヘッダやフッタを付加するだけでよいため）、１つのメッセージ毎にヘッダやフッタが付加されて構成されるパケットが送信される場合に較べて、データ量を抑制することができる。また、通信時間を抑制することができるとともに、通信コストを抑制することができる。このことは、全てのプロトコルにおいても同様である。
【０１９２】
パケットに含められてサーバ２から送信されたUpdate Entityメッセージは、ステップＳ１４１において携帯電話機５のUpdate Entityメッセージ受信制御部９６により取得され、Update Entityメッセージ列の末尾に付加されたFINISHEDメッセージは、ステップＳ１４２において取得される。
【０１９３】
携帯電話機５においては、サーバから送信されてきたパケットに含まれるメッセージが取得され、取得された順に、メッセージに基づく処理が行われる。また、必要に応じて、処理結果を表すレスポンスが制御部８１により生成される。
【０１９４】
携帯電話機５のUpdate Entityメッセージ受信制御部９６は、サーバ２から送信されてきたFINISHEDメッセージを受信することによりパケットの終端を検知する。受信したUpdate Entityメッセージに対するレスポンス（Update Entityメッセージ）がステップＳ１４３においてUpdate Entityメッセージ管理部９４により生成される。
【０１９５】
例えば、サーバ２からデバイスの属性値を変更することが指示されたとき、属性値の変更がデバイス制御部１００により行われ、属性値の変更が成功したか否かが制御部８１からUpdate Entityメッセージ管理部９４に通知される。Update Entityメッセージ管理部９４においては、その通知に対応するレスポンスが生成され、Update Entityメッセージ送信制御部６５に出力される。
【０１９６】
ステップＳ１４４において、携帯電話機５のUpdate Entityメッセージ送信制御部９５は、生成したレスポンスにFISNISHEDメッセージを付加し、１つのパケットとしてサーバ２に送信する。なお、レスポンスの有無、およびその数は、サーバ２から送信されてきたメッセージ次第である。
【０１９７】
パケットに含められて携帯電話機５から送信されたUpdate Entityメッセージは、ステップＳ１５３においてサーバ２のUpdate Entityメッセージ受信制御部６６により取得され、Update Entityメッセージ列の末尾に付加されたFINISHEDメッセージは、ステップＳ１５４において取得される。
【０１９８】
以下、適宜、Neutralステートにおいて、サーバ２から携帯電話機５に対して送信されるパケット（０を含む所定の数のUpdate Entityメッセージと１つのFISNISHEDメッセージを含むパケット、０を含む所定の数のApplication Data Transferメッセージと１つのFISNISHEDメッセージを含むパケット、または、０を含む所定の数のOperate Entityメッセージと１つのFISNISHEDメッセージを含むパケット）を制御パケットと称する。
【０１９９】
また、その制御パケットに含まれるメッセージの処理結果等を通知すべく、携帯電話機５からサーバ２に対して返信されるパケット（メッセージに対応する０を含む所定の数のレスポンスと１つのFISNISHEDメッセージを含むパケット）を返信パケットと称する。
【０２００】
以上のようにして、Update EntityメッセージとFISNISHEDメッセージを含む制御パケットが、サーバ主導でサーバ２から携帯電話機５に対して送信され、それに基づく処理が携帯電話機５において実行される。携帯電話機５においては、サーバ２から送信されてきたUpdate Entityメッセージに対応するレスポンスが生成され、レスポンスとFISNISHEDメッセージを含む返信パケットがサーバ２に対して送信される。
【０２０１】
具体的には、例えば、図１４のSET_PROPERTYメッセージを含む制御パケットがサーバ２から携帯電話機５に対して送信されたとき、携帯電話機５においては、SET_PROPERTYメッセージに基づくデバイスの属性値の設定が行われ、PROPERTY_SETメッセージ（レスポンス）を含む返信パケットがサーバ２に対して返信される。
【０２０２】
なお、携帯電話機５およびサーバ２は、Update Entityメッセージ列の中に、所定の数のアプリケーション固有メッセージ（Extension中のUpdate Entity用拡張メッセージ）を含めて送信することができる。
【０２０３】
図１６は、Application Data Transfer Protocolにおいて用いられるメッセージを示す図である。
【０２０４】
Application Data Transfer Protocolは、例えば、リーダライタ１１を介して携帯電話機５に接続される外部ICカード１２を制御するためのアプリケーションのコマンドなど、サーバとクライアント（デバイス）間におけるアプリケーションデータを送受信するときに用いられる。
【０２０５】
FINISHEDメッセージはパケットの終端を意味し、WARNINGメッセージは警告の通知を意味する。WARNINGメッセージのデータ部には所定の文字列からなる警告メッセージが含まれる。
【０２０６】
次に、図１７のシーケンスを参照して、図１６に示されるメッセージを用いて行われるApplication Data Transfer Protocolについて説明する。
【０２０７】
ステップＳ１７１において、サーバ２のApplication Data Transferメッセージ管理部６１は、一群のApplication Data Transferメッセージ列を生成する。生成されたApplication Data Transferメッセージは、Application Data Transferメッセージ送信制御部６２に出力される。
【０２０８】
サーバ２のApplication Data Transferメッセージ送信制御部６２は、ステップＳ１７２において、生成したApplication Data Transferメッセージ列の末尾にFINISHEDメッセージを付加し、所定の数のApplication Data Transferメッセージ列と１つのFINISHEDメッセージからなる制御パケットを携帯電話機５に送信する。
【０２０９】
制御パケットに含まれるApplication Data Transferメッセージは、ステップＳ１６１において、携帯電話機５のApplication Data Transferメッセージ受信制御部９３により受信され、FINISHEDメッセージはステップＳ１６２において受信される。
【０２１０】
携帯電話機５のApplication Data Transferメッセージ受信制御部９３は、サーバ２から送信されてきたFINISHEDメッセージを受信することにより制御パケットの終端を検知し、制御パケットに含まれるApplication Data TransferメッセージがApplication Data Transferメッセージ管理部９１に出力される。
【０２１１】
ステップＳ１６３において、パケットに含まれるApplication Data Transferメッセージに対応するレスポンスが生成される。すなわち、デバイス制御部１００により行われた制御の結果がApplication Data Transferメッセージ管理部９１に通知され、Application Data Transferメッセージ管理部９１により、その結果に対応するレスポンスが生成される。生成されたレスポンスはApplication Data Transferメッセージ送信制御部９２に供給される。
【０２１２】
ステップＳ１６４において、携帯電話機５のApplication Data Transferメッセージ送信制御部９２は、生成されたレスポンス（Application Data Transferメッセージ）列の末尾にFINISHEDメッセージを付加し、生成した返信パケットをサーバ２に送信する。
【０２１３】
パケットに含められて携帯電話機５から送信されたApplication Data Transferメッセージは、ステップＳ１７３においてサーバ２のApplication Data Transferメッセージ受信制御部６３により取得され、Application Data Transferメッセージ列の末尾に付加されたFINISHEDメッセージは、ステップＳ１７４において取得される。
【０２１４】
なお、レスポンスの有無、およびその数は、サーバ２から送信されてきたメッセージ次第である。
【０２１５】
上述したUpdate Entity Protocolの場合と同様に、携帯電話機５およびサーバ２は、Application Data Transferメッセージ列の中に、所定の数のアプリケーション固有メッセージ（Extension中のApplication Data Transfer用拡張メッセージ）を送信することができる。
【０２１６】
図１８は、Operate Entity Protocolにおいて用いられるメッセージを示す図である。
【０２１７】
Operate Entity Protocolは、例えば、携帯電話機５に接続されたリーダライタ１１による電磁波の輻射の開始または停止、或いは、ユーザに対して所定の入力を行わせるための所定の画面表示など、クライアントに接続されたデバイスを制御するときに用いられる。
【０２１８】
FINISHEDメッセージはパケットの終端を意味し、WARNINGメッセージは警告の通知を意味する。WARNINGメッセージのデータ部には、所定の文字列からなる警告メッセージが含まれる。
【０２１９】
UPDATE_VIEWメッセージは、サーバからクライアントに対して送信され、クライアントにおけるビュー（表示画面）の更新を意味する。UPDATE_VIEWメッセージに対する返信は、VIEW_UPDATEDメッセージによりサーバに対して行われる。
【０２２０】
このUPDATE_VIEWメッセージは、メッセージに基づく処理がクライアントにおいて失敗したとき、後続のメッセージの処理を中止しなければならないメッセージである。従って、UPDATE_VIEWメッセージの先頭ビットは、後続のメッセージの処理を中断するように設定される。
【０２２１】
VIEW_UPDATEDメッセージは、サーバから送信されてきたUPDATE_VIEWメッセージに対する返信を意味し、そのデータ部には、ビューの更新が成功したか否かを表すフラグが含まれる。
【０２２２】
BEGIN_DATA_INPUTメッセージは、サーバからクライアントに対して送信され、デバイスに対するデータの入力を開始することを意味する。BEGIN_DATA_INPUTメッセージに対するクライアントからの返信は、END_DATA_INPUTによりサーバに対して行われる。
【０２２３】
このBEGIN_DATA_INPUTメッセージは、メッセージに基づく処理がクライアントにおいて失敗したとき、後続のメッセージの処理を中止しなければならないメッセージである。従って、BEGIN_DATA_INPUTメッセージの先頭ビットは、その処理に失敗した場合、後続のメッセージの処理を中断するように設定される。
【０２２４】
END_DATA_INPUTメッセージは、BEGIN_DATA_INPUTに対するクライアントからの返信を意味し、そのデータ部には、データの入力が成功したか否かを表すフラグ、属性名長、属性名、属性値長、および属性値の情報が含まれる。
【０２２５】
OPERATE_DEVICEメッセージは、サーバからクライアントに対して送信され、クライアントに接続されたデバイスを操作することを意味する。OPERATE_DEVICEメッセージに対するクライアントからの返信は、DEVICE_RESPONSEメッセージによりサーバに対して行われる。
【０２２６】
このOPERATE_DEVICEメッセージは、メッセージに基づく処理がクライアントにおいて失敗したとき、後続のメッセージの処理を中止しなければならないメッセージである。従って、OPERATE_DEVICEメッセージの先頭ビットは、その処理に失敗した場合、後続のメッセージの処理を中断するように設定される。
【０２２７】
OPERATE_DEVICEメッセージのデータ部には、操作名文字数、操作名、パラメタ長、およびパラメタの情報が含まれる。
【０２２８】
DEVICE_RESPONSEメッセージは、クライアントからサーバに対して送信され、デバイス操作の結果の通知を意味する。DEVICE_RESPONSEメッセージのデータ部には、レスポンス長、レスポンスの情報が含まれる。
【０２２９】
PLAY_SOUNDメッセージは、サーバからクライアントに対して送信され、クライアント側において、サーバにより指定された論理名に対応した音を発生させることを意味する。PLAY_SOUNDメッセージに対する返信は行われない。
【０２３０】
このPLAY_SOUNDメッセージは、メッセージに基づく処理がクライアントにおいて失敗した場合であっても、後続のメッセージの処理を継続するメッセージである。従って、PLAY_SOUNDメッセージの先頭ビットは、その処理に失敗した場合であっても、後続のメッセージの処理を継続するように設定される。
【０２３１】
PLAY_SOUNDメッセージのデータ部には、発生させる音の論理名を表す情報が含まれる。
【０２３２】
次に、図１９のシーケンスを参照して、図１８に示されるメッセージを用いて行われるOperate Entity Protocolについて説明する。
【０２３３】
サーバ２のOperate Entityメッセージ管理部６７は、ステップＳ１９１において、携帯電話機５に送信する、意味のある一群のOperate Entityメッセージ列を生成する。生成されたOperate EntityメッセージはOperate Entityメッセージ送信制御部６８に出力される。
【０２３４】
携帯電話機５のOperate Entityメッセージ送信制御部６８は、ステップＳ１９２において、生成したメッセージ列の末尾にFINISHEDメッセージを付加し、制御パケットとして携帯電話機５に送信する。
【０２３５】
携帯電話機５に対して送信された制御パケットに含まれるOperate EntityメッセージおよびFINISHEDメッセージは、ステップＳ１８１およびＳ１８２においてそれぞれ受信される。
【０２３６】
携帯電話機５のOperate Entityメッセージ管理部９７は、ステップＳ１８３において、サーバ２から送信されてきたOperate Entityメッセージに対するレスポンスを制御部８１による指示に基づいて生成する。なお、レスポンスの有無、およびその数は、サーバ２から送信されてきたメッセージ次第である。
【０２３７】
携帯電話機５のOperate Entityメッセージ送信制御部６５は、ステップＳ１８４において、Operate Entityメッセージ管理部９７により生成されたレスポンスにFISNISHEDメッセージを付加し、返信パケットとしてサーバ２に送信する。
【０２３８】
パケットに含められて携帯電話機５から送信されたOperate Entityメッセージは、ステップＳ１９３においてサーバ２のOperate Entityメッセージ受信制御部６９により取得され、Operate Entityメッセージ列の末尾に付加されたFINISHEDメッセージは、ステップＳ１９４において取得される。
【０２３９】
なお、携帯電話機５、およびサーバ２は、Operate Entityメッセージ列の中に所定の数のアプリケーション固有メッセージ（Extension中のOperate Entity用拡張メッセージ）を送信することができる。
【０２４０】
以上のように、携帯電話機５とサーバ２の間でHandshakeが成立し、Neutralステート（図５）のときには、サーバ２が通信の主導権を有し、サーバ２から、Update Entity Protocol，Application Data Transfer Protocol、またはOperate Entity Protocolに基づくメッセージが携帯電話機５に対して送信される（Update Entity Protocolによる通信のシーケンスを示す図１５、Application Data Transfer Protocolによる通信のシーケンスを示す図１７、および、Operate Entity Protocolによる通信のシーケンスを示す図１９においては、いずれもサーバ２から通信が開始されている）。
【０２４１】
すなわち、携帯電話機５からの命令に応じて、サーバ２がレスポンスを携帯電話機５に返信し、その返信に基づいてデバイスが制御されるのではなく、サーバ２から携帯電話機５に対して直接送信された命令に基づいて、携帯電話機５に接続されているデバイスが制御される。
【０２４２】
従って、１度通信が確立された後は、サーバ２からの通信によりデバイスを直接制御することができる。
【０２４３】
次に、図２０を参照して、以上のようなサブプロトコルに従ってNeutralステートにおける通信を行う、サーバ（サーバ２）とクライアント（携帯電話機５）の処理について説明する。
【０２４４】
図２０においては、ステップＳ２１１において、Application Data TransferメッセージＡ（MsgＡ）、Application Data TransferメッセージＢ（MsgＢ）にFinishedメッセージが付加されて生成された制御パケット（Application Data Transferパケット）２０１がサーバ２から携帯電話機５に対して送信されている。
【０２４５】
図１７を参照して説明したように、Application Data Transfer Protocolによる通信においては、サーバ２のApplication Data Transferメッセージ送信制御部６２から、所定の数のApplication Data TransferメッセージにFinishedメッセージが付加されて構成される制御パケットが携帯電話機５に対して送信される。
【０２４６】
また、ステップＳ２１１においては、Operate EntityメッセージＸ（MsgＸ）にFinishedメッセージが付加されて生成された制御パケット（Operate Entityパケット）２０２がサーバ２から携帯電話機５に対して送信されている。
【０２４７】
図１９を参照して説明したように、Operate Entity Protocolによる通信においては、サーバ２から、所定の数のOperate EntityメッセージにFinishedメッセージが付加されて構成される制御パケットが携帯電話機５に対して送信される。
【０２４８】
さらに、ステップＳ２１１においては、Application Data TransferメッセージＣ（MsgＣ）にFinishedメッセージが付加されて生成された制御パケット（Application Data Transferパケット）２０３がサーバ２から携帯電話機５に対して送信されている。
【０２４９】
このように、複数の制御パケットが携帯電話機５に一括して送信されるため、それぞれのプロトコルのパケットをそれぞれ送信する場合に較べて、通信回数を抑制することができる。
【０２５０】
制御パケットに含められてサーバ２から送信されたメッセージは、送信された順序で携帯電話機５により処理され、レスポンスが順次生成される。携帯電話機５により生成されたレスポンスは、生成された順序でサーバ２に返信される。
【０２５１】
従って、図２０の例においては、ステップＳ２０１で携帯電話機５により制御パケット２０１乃至２０３が受信されたとき、Application Data TransferメッセージＡ、Application Data TransferメッセージＢ、Operate EntityメッセージＸ、Application Data TransferメッセージＣの順に、それらのメッセージに基づく処理が携帯電話機５により実行される。
【０２５２】
上述したように、メッセージに基づく処理の途中でエラーが発生した場合、それに続くメッセージの処理を続行するのか、または、その時点で処理を中断するのかは、メッセージの先頭ビットの値により設定されている。
【０２５３】
図２０に示される処理においては、送信された全てのメッセージの処理が成功した場合の例とされている。また、Application Data TransferメッセージＡとOperate EntityメッセージＸは、それぞれ返信（レスポンス）が必要とされるメッセージであり、Application Data TransferメッセージＢとApplication Data TransferメッセージＣは、共に返信が必要でないメッセージとされている。
【０２５４】
携帯電話機５において処理が成功したか否かをサーバ２側で管理する必要があるメッセージに対しては、携帯電話機５によりレスポンスが生成される。
【０２５５】
従って、携帯電話機５は、Application Data TransferメッセージＡに基づく処理を実行したとき、それに対するレスポンスＡ（ResＡ）を生成し、レスポンスＡにFinishedメッセージを付加して生成した返信パケット（Application Data Transferパケット）２１１を、ステップＳ２０２において、サーバ２に対して送信する。
【０２５６】
図１７を参照して説明したように、Application Data Transfer Protocolによる通信においては、サーバ２から送信されてきた制御パケットに含まれるApplication Data Transferメッセージに対応してApplication Data Transferメッセージ管理部９２によりレスポンスが生成され、生成されたレスポンスとFinishedメッセージからなる返信パケットがApplication Data Transferメッセージ送信制御部９２からサーバ２に送信される。
【０２５７】
また、携帯電話機５は、Operate EntityメッセージＸに基づく処理を実行したとき、それに対するレスポンスＸ（ResＸ）を生成し、レスポンスＸにFinishedメッセージを付加して生成した返信パケット（Operate Entityパケット）２１２を、ステップＳ２０２において、サーバ２に対して送信する。
【０２５８】
図１９を参照して説明したように、Operate Entity Protocolによる通信においては、サーバ２から送信されてきた制御パケットに含まれるOperate Entityメッセージに対応して、Operate Entityメッセージ管理部９７によりレスポンスが生成され、生成されたレスポンスとFinishedメッセージからなる返信パケットがOperate Entityメッセージ送信制御部９８からサーバ２に送信される。
【０２５９】
なお、携帯電話機５は、返信メッセージの有無に関わらず、サーバ２から送信されてきた１つの制御パケットに対して１つの返信パケットをサーバ２に送信しなければならないため、Application Data TransferメッセージＣが返信を必要としないメッセージである場合であっても、制御パケット２０３に対して、Finishedメッセージが末尾に付加された返信パケット（Application Data Transferパケット）２１３をステップＳ２０２においてサーバ２に送信する。
【０２６０】
携帯電話機５から送信された返信パケットはステップＳ２１２においてサーバ２により受信され、返信パケットに含まれるレスポンスにより、携帯電話機５においてメッセージに基づく処理が成功されたことが取得される。
【０２６１】
このように、サーバ２から送信されたそれぞれのメッセージに対して、送信された順序で返信メッセージが生成されるため、サーバ２および携帯電話機５は、送信メッセージと返信メッセージを対応付けて管理することができる。
【０２６２】
図２１は、サーバ２と携帯電話機５により実行される他の処理について説明するシーケンスである。
【０２６３】
図２１においては、ステップＳ２３１において、図２０の場合と同様に、制御パケット２２１乃至２２３がサーバ２から携帯電話機５に対して送信されている。
【０２６４】
なお、図２１においては、携帯電話機５に対して送信されたApplication Data TransferメッセージＡ（MsgＡ）の処理が失敗した場合の例とされている。また、Application Data TransferメッセージＡの先頭ビットにより、Application Data TransferメッセージＡの処理が失敗した場合、その時点で処理を中断することが表されている場合の例とされている。
【０２６５】
従って、ステップＳ２２１において、携帯電話機５により制御パケット２２１に含まれるApplication Data TransferメッセージＡが取得され、それに基づく処理が失敗したとき、Application Data TransferメッセージＡに続くApplication Data TransferメッセージＢ、Operate EntityメッセージＸ、Application Data TransferメッセージＣに基づく処理は実行されない。
【０２６６】
携帯電話機５は、Application Data TransferメッセージＡに基づく処理に失敗したとき、処理が失敗したことをサーバ２に通知するレスポンスＡ（ResＡ）を生成する。携帯電話機５は、ステップＳ２２２において、生成したレスポンスＡにFinishedメッセージを付加し、返信パケット（Application Data Transferパケット）２３１をサーバ２に送信する。
【０２６７】
ステップＳ２３２において、サーバ２は、携帯電話機５からの返信パケット２３１を受信し、それに含まれるレスポンスＡに基づいて、Application Data TransferメッセージＡに基づく処理が携帯電話機５において失敗したことを取得する。また、サーバ２は、Application Data TransferメッセージＢ、Operate EntityメッセージＸ、Application Data TransferメッセージＣに基づく処理が実行されていないことを取得する。
【０２６８】
図２２は、サーバ２と携帯電話機５により実行されるさらに他の処理について説明するシーケンスである。
【０２６９】
図２２においても、図２０または図２１と同様に、ステップＳ２５１において、制御パケット２４１乃至２４２がサーバ２から携帯電話機５に対して送信されている。
【０２７０】
なお、図２２においては、携帯電話機５に対して送信されたApplication Data TransferメッセージＢ（MsgＢ）の処理が失敗した場合の例とされている。また、Application Data TransferメッセージＢの先頭ビットにより、Application Data TransferメッセージＢの処理が失敗した場合であっても、それに続くメッセージの処理を続行することが表されている場合の例とされている。
【０２７１】
さらに、Application Data TransferメッセージＡおよびOperate EntityメッセージＸは、返信メッセージを必要とするメッセージであり、Application Data TransferメッセージＣは、返信メッセージを必要としないメッセージとされている。
【０２７２】
従って、携帯電話機５は、ステップＳ２４１において、制御パケット２４１を受信し、Application Data TransferメッセージＡに基づく処理を実行し、レスポンスＡ（ResＡ）を生成する。
【０２７３】
また、携帯電話機５は、Application Data TransferメッセージＢに基づく処理に失敗した場合であっても、Application Data TransferメッセージＢの先頭ビットにより表される指示に従って、それに続く処理を続行する。すなわち、携帯電話機５は、制御パケット２４２に含まれるOperate EntityメッセージＸに基づく処理を実行し、Operate EntityメッセージＸに対応するレスポンスＸ（ResＸ）を生成する。
【０２７４】
さらに、携帯電話機５は、レスポンスＸを生成した後、制御パケット２４３に含まれるApplication Data TransferメッセージＣに基つく処理を実行する。
【０２７５】
携帯電話機５により生成されたレスポンスＡとFinishedパケットを含む返信パケット（Application Data Transferパケット）２５１、レスポンスＸとFinishedパケットを含む返信パケット（Operate Entityパケット）２５２、および、Finishedパケットを含む返信パケット（Application Data Transferパケット）２５３は、ステップＳ２４２において、サーバ２に対して送信される。
【０２７６】
携帯電話機５から送信された返信パケットは、ステップＳ２５２においてサーバ２により受信され、Application Data TransferメッセージＡに基づく処理、および、Operate Entityメッセージに基づく処理が携帯電話機５において成功したこと、並びに、Application Data TransferメッセージＢに基づく処理が失敗したことが取得され、処理が終了される。
【０２７７】
Neutralステートのとき、以上のようなサーバ２と携帯電話機５の間でのパケットの送受信が繰り返し実行され、サーバ主導によるクライアント（デバイス）の制御が行われる。
【０２７８】
以上においては、携帯電話機５に対するメッセージの送信と、サーバ２に対するレスポンスの返信が繰り返されることにより、所定のデバイスの制御が行われるとしたが、例えば、サーバ２から携帯電話機５に対してスクリプト（簡易プログラム）が制御パケットと共に一括して送信され、メッセージに基づく処理結果と、簡易プログラムに従って、次に実行する処理が携帯電話機５自身により判断されるようにしてもよい。
【０２７９】
すなわち、スクリプトには、所定のメッセージに対して生成されたレスポンス（デバイスのレスポンス）の内容によって、次に、どのメッセージに基づく処理を実行するのかが記述される。
【０２８０】
スクリプトに基づく処理が終了されたとき、デバイスから携帯電話機５に対して行われたレスポンスの内容が、サーバ２に対して一括して送信される返信パケットに含められて送信される。
【０２８１】
スクリプトの実行履歴（携帯電話機５からデバイスに送信されたメッセージ（携帯電話機５により実行されたメッセージ）の内容と、その順序を表す情報）がサーバ２に送信されることにより、サーバ２は、携帯電話機５から送信されてきたレスポンスが、どのメッセージに対するものなのかを判断することができる。
【０２８２】
また、以上においては、Handshakeプロトコルにより通信が確立したとき、サーバ２が通信の主導となり、携帯電話機５との間での通信が行われるとしたが、任意のタイミングで、携帯電話機５が通信の主導権を有することができるようにしてもよい。
【０２８３】
この場合、例えば、主導権の逆転は、サーバ・クライアント送受信方向逆転プロトコルによって行われる。
【０２８４】
例えば、サーバ２が主導となって通信が行われている場合、所定のタイミングで、サーバ２から携帯電話機５に対してサーバ・クライアント送受信方向逆転プロトコルのEXCHANGEメッセージが送信される。それ以降の通信においては、携帯電話機５が主導となって、上述したものと同様の通信が行われる。
【０２８５】
一方、携帯電話機５が主導となって通信が行われている場合、所定のタイミングで、携帯電話機５からサーバ２に対してサーバ・クライアント送受信方向逆転プロトコル（EXCHANGEプロトコル）のEXCHANGEメッセージが送信される。この場合、サーバ２が主導となり、それ以降の通信が行われる。
【０２８６】
図２３および図２４は、EXCHANGE（交換）プロトコルのシーケンスを示す図である。
【０２８７】
図２３においては、始めに、携帯電話機５（Client）が通信の主導を有している。ステップＳ３０１において携帯電話機５から送信されたEXCHANGEメッセージは、ステップＳ３１１においてサーバ２（Server）により受信され、それ以降、サーバ２が主導となり、サーバ２と携帯電話機５との間で通信が行われる。
【０２８８】
一方、図２４においては、始めに、サーバ２が通信の主導を有している。ステップＳ３３１においてサーバ２から送信されたEXCHANGEメッセージは、ステップＳ３２１において携帯電話機５により受信され、それ以降、携帯電話機５が主導となり、サーバ２と携帯電話機５との間で通信が行われる。
【０２８９】
以上のようにして、Neutralステートでの通信の主導権の切り替えが行われる。
【０２９０】
なお、サーバ２と携帯電話機５の間で確立された通信経路上に携帯電話機５のファイアウォールが存在する場合、そのファイアウォールを越えて通信を行うことができるようにして、サーバ２と携帯電話機５の間では、HTTPによる通信が行われる。この場合、上述した複数のプロトコルのパケットの送受信は、１回のセッションが維持された状態で行われる。
【０２９１】
図２５は、制御プロトコルの状態遷移について説明する他の図であり、基本的には、図５を参照して説明したものと同様である。上述した図５に代えて、図２５に示されるように、状態遷移が行われるようにしてもよい。なお、図５と重複する部分については、その説明を適宜省略する。
【０２９２】
クライアントは、Handshake Protocol（State1）を終了したとき、ステップＳ３４３において、サーバに対してCLIENT_HELLO_DONEメッセージを送信する。これによりコネクションが確立され、制御の主導権がサーバに移る。
【０２９３】
また、Neutralステート状態にあるステップＳ３４４においては、サーバが主導となり、Update Entityサブプロトコル、Application Data Transferサブプロトコル、および、Operate Entityサブプロトコルによる通信が行われるだけでなく、必要に応じて、上述したEXCHANGEメッセージが用いられ、主導権の切り替えが行われる。
【０２９４】
サーバは、Farewell Protocolが終了したと判断したとき、ステップＳ３４６において、クライアントに対してSERVER_GOOD_BYE_DONEメッセージを送信し、コネクションを終了させる。これにより、クライアントのリソースが開放され、処理が終了される。
【０２９５】
このように、SERVER_GOOD_BYE_DONEメッセージが送信されることにより、処理が終了される場合もある。
【０２９６】
図２６は、上述したように、クライアントからサーバに対して、CLIENT_HELLO_DONEメッセージが送信されることにより、コネクションが終了される場合のシーケンスである。
【０２９７】
すなわち、ステップＳ３６１において、クライアントからサーバに対して、CLIENT_HELLOメッセージが送信され、ステップＳ３６２に進み、DEVICESメッセージが送信される。
【０２９８】
ステップＳ３６３において、アプリケーション固有のメッセージが送信され、ステップＳ３６４に進み、CLIENT_HELLO_DONEメッセージが送信されたとき、サーバとクライアント間でのコネクションが確立される。
【０２９９】
なお、サーバにおいては、ステップＳ３７１乃至Ｓ３７４において、クライアントから送信されてきたCLIENT_HELLOメッセージ、DEVICESメッセージ、アプリケーション固有のメッセージ、および、CLIENT_HELLO_DONEメッセージがそれぞれ受信される。
【０３００】
例えば、クライアントが携帯電話機などの機器である場合、図８の処理と比較して、データの送受信が一部省略された、以上の処理により、クライアントとサーバの間でコネクションが確立されることがある。
【０３０１】
図２７は、上述したように、サーバからクライアントに対して、SERVER_GOOD_BYE_DONEメッセージが送信されることにより、Farewell Protocolが終了される場合のシーケンスである。
【０３０２】
すなわち、ステップＳ３９１において、サーバからSERVER_GOOD_BYEメッセージが送信されることによりFarewell Protocolが開始され、ステップＳ３９２において、RETURN_CODEメッセージが送信される。また、ステップＳ３９３において、アプリケーション固有のメッセージが送信される。
【０３０３】
ステップＳ３９４において、サーバからクライアントに対して、SERVER_GOOD_BYE_DONEメッセージが送信され、これにより、コネクションが終了される。
【０３０４】
サーバから送信されたSERVER_GOOD_BYEメッセージ、RETURN_CODEメッセージ、アプリケーション固有のメッセージ、および、SERVER_GOOD_BYE_DONEメッセージは、それぞれ、クライアントにより、ステップＳ３８１乃至Ｓ３８４の処理により受信される。SERVER_GOOD_BYE_DONEメッセージが受信されたとき、クライアントのリソースが開放される。
【０３０５】
上述したHandshake Protocolの場合と同様に、例えば、クライアントが携帯電話機などの機器である場合、図１０の処理と比較して、データの送受信が一部省略された、以上のような処理により、クライアントとサーバの間でのコネクションが終了されることがある。
【０３０６】
上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。
【０３０７】
一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば、汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
【０３０８】
この記録媒体は、図２に示されるように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク４１（フレキシブルディスクを含む）、光ディスク４２（CD-ROM(Compact Disk-Read Only Memory)，DVD(Digital Versatile Disk)を含む）、光磁気ディスク４３（MD（登録商標）(Mini-Disk)を含む）、もしくは半導体メモリ４４などよりなるパッケージメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM３２や、記憶部３８に含まれるハードディスクなどで構成される。
【０３０９】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に従って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０３１０】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表わすものである。
【０３１１】
【発明の効果】
本発明によれば、情報処理装置と情報処理端末の間で通信を行うこと、特に、重宝処理装置が主導となり情報処理端末との間で通信を行うことができる。
【０３１２】
また、本発明によれば、効率的にかつ確実に各種のパケットを送受信することができるとともに、通信コストを抑制することができ、これにより、情報処理装置が、情報処理端末を効率的かつ確実に制御することができる。
【０３１３】
さらに、本発明によれば、処理のエラーが発生した場合であっても、それに続く処理をクライアントに実行させることができる。
【図面の簡単な説明】
【図１】本発明を適用した制御システムの構成例を示す図である。
【図２】図１のサーバの構成例を示すブロック図である。
【図３】サーバの機能構成例を示すブロック図である。
【図４】クライアントの機能構成例を示すブロック図である。
【図５】制御プロトコルの状態遷移について説明する図である。
【図６】パケットのフォーマットの例を示す図である。
【図７】 Handshake Protocolにおいて用いられるメッセージを示す図である。
【図８】図７に示されるメッセージを用いて行われるHandshake Protocolについて説明するシーケンスである。
【図９】 Farewell Protocolにおいて用いられるメッセージを示す図である。
【図１０】図９に示されるメッセージを用いて行われるFarewell Protocolについて説明するシーケンスである。
【図１１】 Error Protocolにおいて用いられるメッセージを示す図である。
【図１２】図１１に示されるメッセージを用いて行われるError Protocolについて説明するシーケンスである。
【図１３】図１１に示されるメッセージを用いて行われる他のError Protocolについて説明するシーケンスである。
【図１４】 Update Entity Protocolにおいて用いられるメッセージを示す図である。
【図１５】図１４に示されるメッセージを用いて行われるUpdate Entity Protocolについて説明するシーケンスである。
【図１６】 Application Data Transfer Protocolにおいて用いられるメッセージを示す図である。
【図１７】図１６に示されるメッセージを用いて行われるApplication Data Transfer Protocolについて説明するシーケンスである。
【図１８】 Operate Entity Protocolにおいて用いられるメッセージを示す図である。
【図１９】図１８に示されるメッセージを用いて行われるOperate Entity Protocolについて説明するシーケンスである。
【図２０】 Neutralステートにおける通信を説明するシーケンスである。
【図２１】 Neutralステートにおける他の通信を説明するシーケンスである。
【図２２】 Neutralステートにおけるさらに他の通信を説明するシーケンスである。
【図２３】 Exchange Protocolについて説明するシーケンスである。
【図２４】 Exchange Protocolについて説明するシーケンスである。
【図２５】制御プロトコルの他の状態遷移について説明する図である。
【図２６】 Handshake Protocolについて説明する他のシーケンスである。
【図２７】 Farewell Protocolについて説明する他のシーケンスである。
【符号の説明】
１ ネットワーク， ２および４ サーバ， ５ 携帯電話機， ６ パーソナルコンピュータ， １１ 磁気ディスク， １２ 光ディスク， １３ 光磁気ディスク， １４ 半導体メモリ
Claims (19)
- ネットワークを介して接続される情報処理端末と情報処理装置からなる制御システムにおいて、
前記情報処理端末は、
機器が接続された状態で、前記情報処理装置に対して、前記ネットワークを介した通信の確立を要求する要求手段と、
前記要求手段による要求に応じて確立された通信により前記情報処理装置から送信される、前記機器の制御に関する命令を含むパケットを受信する受信手段と、
前記受信手段により受信された前記パケットに含まれる前記命令に基づいて、前記機器を制御する制御手段と
を備え、
前記情報処理装置は、
前記情報処理端末からの要求に応じて、前記情報処理端末との間で前記ネットワークを介した通信を確立する確立手段と、
前記確立手段により前記情報処理端末との間で通信が確立されたとき、自分自身から、前記パケットを前記情報処理端末に送信する送信手段と
を備えることを特徴とする制御システム。 - ネットワークを介して接続される情報処理端末と情報処理装置からなる制御システムの制御方法において、
前記情報処理端末の情報処理方法は、
機器が接続された状態で、前記情報処理装置に対して、前記ネットワークを介した通信の確立を要求する要求ステップと、
前記要求ステップの処理に応じて確立された通信により前記情報処理装置から送信される、前記機器の制御に関する命令を含むパケットを受信する受信ステップと、
前記受信ステップの処理により受信された前記パケットに含まれる前記命令に基づいて、前記機器を制御する制御ステップと
を含み、
前記情報処理装置の情報処理方法は、
前記情報処理端末からの要求に応じて、前記情報処理端末との間で前記ネットワークを介した通信を確立する確立ステップと、
前記確立ステップの処理により前記情報処理端末との間で通信が確立されたとき、自分自身から、前記パケットを前記情報処理端末に送信する送信ステップと
を含むことを特徴とする制御方法。 - ネットワークに接続される情報処理端末を介して、所定のタイミングで前記情報処理端末に接続される機器を制御する情報処理装置において、
前記情報処理端末に前記機器が接続された状態で行われる前記情報処理端末からの要求に応じて、前記情報処理端末との間で前記ネットワークを介した通信を確立する確立手段と、
前記確立手段により前記情報処理端末との間で通信が確立されたとき、自分自身から、前記機器の制御に関する命令を含む第１のパケットを前記情報処理端末に送信する送信手段と
を備えることを特徴とする情報処理装置。 - 前記送信手段により送信された前記命令に対応する、前記情報処理端末からの返信を含む第２のパケットを受信する受信手段をさらに備える
ことを特徴とする請求項３に記載の情報処理装置。 - 前記命令には、その命令に基づく処理が前記情報処理端末において失敗した場合に、次の命令に基づく処理を続行するか否かを表す情報が含まれる
ことを特徴とする請求項３に記載の情報処理装置。 - 前記送信手段は、同一のプロトコルに属する複数の前記命令を１つの前記第１のパケットに含めて送信する
ことを特徴とする請求項３に情報処理装置。 - 前記送信手段は、前記機器による処理の結果によって、前記機器に次に実行させる処理を前記情報処理端末に判断させる簡易プログラムを、前記第１のパケットと共に送信する
ことを特徴とする請求項３に記載の情報処理装置。 - 前記送信手段は、前記命令に基づく処理の対象となる前記機器を表す識別情報を含む前記第１のパケットを送信する
ことを特徴とする請求項３に記載の情報処理装置。 - 前記確立手段により確立された通信経路上に前記情報処理端末のファイアウォールが存在する場合、前記送信手段は、通信プロトコルとしてHTTPを用い、前記第１のパケットを送信する
ことを特徴とする請求項３に記載の情報処理装置。 - 前記送信手段は、複数の前記第１のパケットを送信する期間、前記確立手段により確立されたHTTPによる通信リンクを継続させる
ことを特徴とする請求項９に記載の情報処理装置。 - 前記確立手段により確立された通信において、前記情報処理端末から所定の情報の送信が開始されるように、前記情報処理端末に指示する指示手段をさらに備える
ことを特徴とする請求項３に記載の情報処理装置。 - ネットワークに接続される情報処理端末を介して、所定のタイミングで前記情報処理端末に接続される機器を制御する情報処理装置の情報処理方法において、
前記情報処理端末に前記機器が接続された状態で行われる前記情報処理端末からの要求に応じて、前記情報処理端末との間で前記ネットワークを介した通信を確立する確立ステップと、
前記確立ステップの処理により前記情報処理端末との間で通信が確立されたとき、自分自身から、前記機器の制御に関する命令を含むパケットを前記情報処理端末に送信する送信ステップと
を含むことを特徴とする情報処理方法。 - ネットワークに接続される情報処理端末を介して、所定のタイミングで前記情報処理端末に接続される機器を制御する処理をコンピュータに行わせるプログラムの記録媒体において、
前記情報処理端末に前記機器が接続された状態で行われる前記情報処理端末からの要求に応じて、前記情報処理端末との間で前記ネットワークを介した通信を確立する確立ステップと、
前記確立ステップの処理により前記情報処理端末との間で通信が確立されたとき、自分自身から、前記機器の制御に関する命令を含むパケットを前記情報処理端末に送信する送信ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。 - ネットワークに接続される情報処理端末を介して、所定のタイミングで前記情報処理端末に接続される機器を制御する処理をコンピュータに行わせるプログラムにおいて、
前記情報処理端末に前記機器が接続された状態で行われる前記情報処理端末からの要求に応じて、前記情報処理端末との間で前記ネットワークを介した通信を確立する確立ステップと、
前記確立ステップの処理により前記情報処理端末との間で通信が確立されたとき、自分自身から、前記機器の制御に関する命令を含むパケットを前記情報処理端末に送信する送信ステップと
を含むことを特徴とするプログラム。 - 機器を遠隔制御する情報処理装置と、ネットワークを介して接続される情報処理端末において、
前記機器が接続された状態で、前記情報処理装置に対して、前記ネットワークを介した通信の確立を要求する要求手段と、
前記要求手段による要求に応じて確立された通信により前記情報処理装置から送信される、前記機器の制御に関する命令を含む第１のパケットを受信する受信手段と、
前記受信手段により受信された前記第１のパケットに含まれる前記命令に基づいて、前記機器を制御する制御手段と
を備えることを特徴とする情報処理端末。 - 前記制御手段による前記機器の制御結果を表す返信を含む第２のパケットを前記情報処理装置に送信する送信手段をさらに備える
ことを特徴とする請求項１５に記載の情報処理端末。 - 機器を遠隔制御する情報処理装置と、ネットワークを介して接続される情報処理端末の情報処理方法において、
前記機器が接続された状態で、前記情報処理装置に対して、前記ネットワークを介した通信の確立を要求する要求ステップと、
前記要求ステップによる要求に応じて確立された通信により前記情報処理装置から送信される、前記機器の制御に関する命令を含むパケットを受信する受信ステップと、
前記受信ステップの処理により受信された前記パケットに含まれる前記命令に基づいて、前記機器を制御する制御ステップと
を含むことを特徴とする情報処理方法。 - 機器を遠隔制御する情報処理装置との間で行われる、ネットワークを介した情報処理をコンピュータに行わせるプログラムの記録媒体において、
前記機器が接続された状態で、前記情報処理装置に対して、前記ネットワークを介した通信の確立を要求する要求ステップと、
前記要求ステップによる要求に応じて確立された通信により前記情報処理装置から送信される、前記機器の制御に関する命令を含むパケットを受信する受信ステップと、
前記受信ステップの処理により受信された前記パケットに含まれる前記命令に基づいて、前記機器を制御する制御ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。 - 機器を遠隔制御する情報処理装置との間で行われる、ネットワークを介した情報処理をコンピュータに行わせるプログラムにおいて、
前記機器が接続された状態で、前記情報処理装置に対して、前記ネットワークを介した通信の確立を要求する要求ステップと、
前記要求ステップによる要求に応じて確立された通信により前記情報処理装置から送信される、前記機器の制御に関する命令を含むパケットを受信する受信ステップと、
前記受信ステップの処理により受信された前記パケットに含まれる前記命令に基づいて、前記機器を制御する制御ステップと
を含むことを特徴とするプログラム。
Priority Applications (8)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002349994A JP3654360B2 (ja) | 2002-12-02 | 2002-12-02 | 制御システムおよび方法、情報処理装置および方法、情報処理端末および方法、記録媒体、並びにプログラム |
| US10/714,869 US7603465B2 (en) | 2002-12-02 | 2003-11-18 | Control system and control method, method and apparatus for processing information, information processing terminal and method thereof, storage medium, and program |
| SG200306819A SG125929A1 (en) | 2002-12-02 | 2003-11-19 | Control system and control method, method and apparatus for processing information, information pro cessing terminal and method thereof, storage medium, and program |
| CNB2003101187479A CN100527690C (zh) | 2002-12-02 | 2003-12-02 | 用于控制信息处理设备的系统和方法 |
| HK04110318.0A HK1069491A1 (en) | 2002-12-02 | 2004-12-29 | System and method for controlling the information processing device |
| US12/509,102 US8065420B2 (en) | 2002-12-02 | 2009-07-24 | Control system and control method, method and apparatus for processing information, information processing terminal and method thereof, storage medium, and program |
| US13/279,927 US9100367B2 (en) | 2002-12-02 | 2011-10-24 | Control system and control method, method and apparatus for processing information, information processing terminal and method thereof, storage medium, and program |
| US14/803,659 US10749862B2 (en) | 2002-12-02 | 2015-07-20 | Control system and control method, method and apparatus for processing information, information processing terminal and method thereof, storage medium, and program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002349994A JP3654360B2 (ja) | 2002-12-02 | 2002-12-02 | 制御システムおよび方法、情報処理装置および方法、情報処理端末および方法、記録媒体、並びにプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004186883A JP2004186883A (ja) | 2004-07-02 |
| JP3654360B2 true JP3654360B2 (ja) | 2005-06-02 |
Family
ID=32376150
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002349994A Expired - Lifetime JP3654360B2 (ja) | 2002-12-02 | 2002-12-02 | 制御システムおよび方法、情報処理装置および方法、情報処理端末および方法、記録媒体、並びにプログラム |
Country Status (5)
| Country | Link |
|---|---|
| US (4) | US7603465B2 (ja) |
| JP (1) | JP3654360B2 (ja) |
| CN (1) | CN100527690C (ja) |
| HK (1) | HK1069491A1 (ja) |
| SG (1) | SG125929A1 (ja) |
Families Citing this family (41)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10361802B1 (en) | 1999-02-01 | 2019-07-23 | Blanding Hovenweep, Llc | Adaptive pattern recognition based control system and method |
| US7966078B2 (en) | 1999-02-01 | 2011-06-21 | Steven Hoffberg | Network media appliance system and method |
| JP2004178254A (ja) * | 2002-11-27 | 2004-06-24 | Hitachi Ltd | 情報処理システム、ストレージシステム、記憶デバイス制御装置、及びプログラム |
| JP3654360B2 (ja) * | 2002-12-02 | 2005-06-02 | ソニー株式会社 | 制御システムおよび方法、情報処理装置および方法、情報処理端末および方法、記録媒体、並びにプログラム |
| US7996514B2 (en) * | 2003-12-23 | 2011-08-09 | Microsoft Corporation | System and method for sharing information based on proximity |
| JP4636531B2 (ja) * | 2004-09-30 | 2011-02-23 | フェリカネットワークス株式会社 | 通信システム、サーバ装置、クライアント装置、通信方法、並びにプログラム |
| US20060095385A1 (en) * | 2004-10-26 | 2006-05-04 | Paul Atkinson | Method and network for selectively controlling the utility a target |
| US7519693B2 (en) * | 2004-11-18 | 2009-04-14 | International Business Machines Corporation | Apparatus, system, and method for integrating an enclosure |
| US20060132285A1 (en) * | 2004-12-07 | 2006-06-22 | Paul Atkinson | Device and method for selectively controlling a processing device |
| US20070194945A1 (en) * | 2004-12-07 | 2007-08-23 | Paul Atkinson | Mobile Device for Selectively Activating a Target and Method of Using Same |
| US7349384B2 (en) * | 2004-12-10 | 2008-03-25 | Microsoft Corporation | Reliable one-way messaging over request-response transport protocols |
| US20060192653A1 (en) * | 2005-02-18 | 2006-08-31 | Paul Atkinson | Device and method for selectively controlling the utility of an integrated circuit device |
| CN101180856B (zh) * | 2005-04-25 | 2013-03-06 | Lg电子株式会社 | 询问射频标识标签数据的方法 |
| WO2007006005A2 (en) * | 2005-07-06 | 2007-01-11 | Kestrel Wireless Inc. | Device and method for authenticating and securing transactions using rf communication |
| US20070008169A1 (en) * | 2005-07-11 | 2007-01-11 | Conero Ronald S | A Radio Frequency Activated Integrated Circuit and Method of Disabling the Same |
| WO2007047841A2 (en) * | 2005-10-18 | 2007-04-26 | Kestrel Wireless Inc. | Activation confirmation feedback circuits and methods |
| WO2007085016A2 (en) * | 2006-01-20 | 2007-07-26 | Kestrel Wireless Inc. | Optical media with reduced areal-sized optical shutters |
| US20080046114A1 (en) * | 2006-08-15 | 2008-02-21 | White Charles A | System, packaging, and method for distributing products |
| CN101198002B (zh) * | 2006-12-04 | 2010-06-23 | 中兴通讯股份有限公司 | 可视电话远程控制建立方法 |
| KR101532369B1 (ko) * | 2006-12-11 | 2015-06-29 | 삼성전자주식회사 | 휴대용 단말기의 원격제어 장치 및 방법 |
| CN101246538A (zh) * | 2007-02-14 | 2008-08-20 | 日电（中国）有限公司 | 射频识别系统和方法 |
| JP4264958B2 (ja) * | 2007-03-23 | 2009-05-20 | フェリカネットワークス株式会社 | 携帯情報端末 |
| US20080309665A1 (en) * | 2007-06-13 | 2008-12-18 | 3D Systems, Inc., A California Corporation | Distributed rapid prototyping |
| US20080313309A1 (en) * | 2007-06-18 | 2008-12-18 | Pradipta Kumar Banerjee | Client-server data transfer control |
| US20090077184A1 (en) * | 2007-09-18 | 2009-03-19 | Martin John Brewer | Remote Control of Mobile Terminal via Remote Control Proxy and SMS |
| US20110125697A1 (en) * | 2009-11-20 | 2011-05-26 | Avaya Inc. | Social media contact center dialog system |
| US20110125826A1 (en) * | 2009-11-20 | 2011-05-26 | Avaya Inc. | Stalking social media users to maximize the likelihood of immediate engagement |
| US20110125793A1 (en) * | 2009-11-20 | 2011-05-26 | Avaya Inc. | Method for determining response channel for a contact center from historic social media postings |
| US9240952B2 (en) * | 2011-04-02 | 2016-01-19 | Open Invention Network, Llc | System and method for communication between networked applications |
| US9998545B2 (en) * | 2011-04-02 | 2018-06-12 | Open Invention Network, Llc | System and method for improved handshake protocol |
| CN102333071A (zh) * | 2011-05-26 | 2012-01-25 | 浙江大学 | 一种工程机械车辆联网通信方法及工程机械车辆联网系统 |
| CN103973746A (zh) * | 2013-02-04 | 2014-08-06 | 鸿富锦精密工业（深圳）有限公司 | 远程控制管理系统及方法 |
| CN104104699A (zh) * | 2013-04-03 | 2014-10-15 | 上海卓石科技有限公司 | 手机远程配置系统及其配置方法 |
| US9501300B2 (en) * | 2013-09-16 | 2016-11-22 | General Electric Company | Control system simulation system and method |
| CN106325451A (zh) * | 2015-06-19 | 2017-01-11 | 上海高清数字科技产业有限公司 | 硬件管理系统及硬件管理方法 |
| CN105553737A (zh) * | 2015-12-25 | 2016-05-04 | 浪潮(北京)电子信息产业有限公司 | 一种节点管理方法与系统 |
| US20190394194A1 (en) | 2016-12-09 | 2019-12-26 | Sony Corporation | Information processing device and relay device |
| EP3388863A1 (en) * | 2017-04-10 | 2018-10-17 | Bea S.A. | Sensor for controlling an automatic door |
| US20210050997A1 (en) | 2018-02-06 | 2021-02-18 | Sony Corporation | Information processing apparatus, information processing method, program, and information processing system |
| CN109922147A (zh) * | 2019-03-04 | 2019-06-21 | 上海卓易科技股份有限公司 | 一种远程控制方法、装置、服务器及存储介质 |
| US11875217B2 (en) | 2019-03-06 | 2024-01-16 | Sony Group Corporation | Information processing apparatus, information processing terminal apparatus, and information processing method |
Family Cites Families (45)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4454509A (en) * | 1980-02-27 | 1984-06-12 | Regency Electronics, Inc. | Apparatus for addressably controlling remote units |
| US4594591A (en) * | 1982-07-28 | 1986-06-10 | Motorola, Inc. | General purpose data control terminal |
| US4761780A (en) * | 1986-12-22 | 1988-08-02 | Bell Communications Research, Inc. | Enhanced efficiency Batcher-Banyan packet switch |
| US4985895A (en) * | 1988-11-14 | 1991-01-15 | Wegener Communications, Inc. | Remote controlled receiving system apparatus and method |
| US5559800A (en) | 1994-01-19 | 1996-09-24 | Research In Motion Limited | Remote control of gateway functions in a wireless data communication network |
| US5729665A (en) * | 1995-01-18 | 1998-03-17 | Varis Corporation | Method of utilizing variable data fields with a page description language |
| JP3262689B2 (ja) * | 1995-05-19 | 2002-03-04 | 富士通株式会社 | 遠隔操作システム |
| WO1996041446A1 (en) * | 1995-06-07 | 1996-12-19 | E-Comm Incorporated | System for detecting unauthorized account access |
| US7130888B1 (en) * | 1996-02-16 | 2006-10-31 | G&H Nevada-Tek | Method and apparatus for controlling a computer over a TCP/IP protocol network |
| US7007070B1 (en) * | 1996-03-06 | 2006-02-28 | Hickman Paul L | Method and apparatus for computing over a wide area network |
| US5898835A (en) * | 1996-08-16 | 1999-04-27 | Electronic Data Systems Corporation | System and method for remotely executing a command |
| US6035264A (en) * | 1996-11-26 | 2000-03-07 | Global Maintech, Inc. | Electronic control system and method for externally controlling process in a computer system with a script language |
| US6289320B1 (en) * | 1998-07-07 | 2001-09-11 | Diebold, Incorporated | Automated banking machine apparatus and system |
| US5886647A (en) * | 1996-12-20 | 1999-03-23 | Badger; Berkley C. | Apparatus and method for wireless, remote control of multiple devices |
| US5901303A (en) * | 1996-12-27 | 1999-05-04 | Gemplus Card International | Smart cards, systems using smart cards and methods of operating said cards in systems |
| US6094221A (en) * | 1997-01-02 | 2000-07-25 | Andersion; Eric C. | System and method for using a scripting language to set digital camera device features |
| US6031990A (en) * | 1997-04-15 | 2000-02-29 | Compuware Corporation | Computer software testing management |
| US6128555A (en) * | 1997-05-29 | 2000-10-03 | Trw Inc. | In situ method and system for autonomous fault detection, isolation and recovery |
| JP3710257B2 (ja) * | 1997-06-10 | 2005-10-26 | キヤノン株式会社 | カメラ制御システムおよびその制御方法およびその制御を実行するプログラムを記憶した記憶媒体 |
| US6065046A (en) * | 1997-07-29 | 2000-05-16 | Catharon Productions, Inc. | Computerized system and associated method of optimally controlled storage and transfer of computer programs on a computer network |
| US6226744B1 (en) * | 1997-10-09 | 2001-05-01 | At&T Corp | Method and apparatus for authenticating users on a network using a smart card |
| US6236332B1 (en) * | 1997-10-22 | 2001-05-22 | Profile Systems, Llc | Control and monitoring system |
| EP0936812A1 (en) * | 1998-02-13 | 1999-08-18 | CANAL+ Société Anonyme | Method and apparatus for recording of encrypted digital data |
| JP3542103B2 (ja) * | 1998-09-08 | 2004-07-14 | 富士通株式会社 | ネットワーク制御方式 |
| US6182149B1 (en) * | 1999-01-11 | 2001-01-30 | 3Com Corporation | System for managing dynamic processing resources in a network |
| US6782426B1 (en) * | 1999-04-09 | 2004-08-24 | Canon Kabushiki Kaisha | Shared device control method and server-client system |
| US6553422B1 (en) * | 1999-04-26 | 2003-04-22 | Hewlett-Packard Development Co., L.P. | Reverse HTTP connections for device management outside a firewall |
| GB9920834D0 (en) * | 1999-09-04 | 1999-11-10 | Hewlett Packard Co | Providing secure access through network firewalls |
| DE19947986A1 (de) * | 1999-10-05 | 2001-04-12 | Ibm | System und Verfahren zum Herunterladen von Anwendungsteilen auf eine Chipkarte |
| US6516427B1 (en) * | 1999-11-05 | 2003-02-04 | Hewlett-Packard Company | Network-based remote diagnostic facility |
| US6834326B1 (en) * | 2000-02-04 | 2004-12-21 | 3Com Corporation | RAID method and device with network protocol between controller and storage devices |
| CA2305249A1 (en) * | 2000-04-14 | 2001-10-14 | Branko Sarcanin | Virtual safe |
| KR100441969B1 (ko) * | 2000-05-10 | 2004-07-27 | 주식회사 네오엠텔 | 이동통신 단말기의 원격제어신호 중계방법 및 이를 구현한이동통신 단말기 및 이동통신 시스템 |
| AU2001272980A1 (en) * | 2000-06-23 | 2002-01-08 | Sportvision, Inc. | Gps based tracking system |
| US7552333B2 (en) * | 2000-08-04 | 2009-06-23 | First Data Corporation | Trusted authentication digital signature (tads) system |
| EP1217475B1 (en) * | 2000-12-13 | 2005-10-26 | Lg Electronics Inc. | Apparatus and method for remotely controlling household appliances |
| US20020080782A1 (en) * | 2000-12-22 | 2002-06-27 | Broadband Gateways, Inc. | Method and system for central control of terminal units |
| US20020143954A1 (en) * | 2001-04-03 | 2002-10-03 | Aiken John Andrew | Methods, systems and computer program products for content-based routing via active TCP connection transfer |
| US7003316B1 (en) * | 2002-02-22 | 2006-02-21 | Virtual Fonlink, Inc. | System and method for wireless transactions |
| US20040194091A1 (en) * | 2002-07-10 | 2004-09-30 | Weems Mason L | System and method for capturing and managing a process flow |
| US6880037B2 (en) * | 2002-08-13 | 2005-04-12 | Activcard, Inc. | Method of data caching on a smartcard |
| US20040054789A1 (en) * | 2002-09-12 | 2004-03-18 | International Business Machines Corporation | Pervasive home network portal |
| JP3654360B2 (ja) * | 2002-12-02 | 2005-06-02 | ソニー株式会社 | 制御システムおよび方法、情報処理装置および方法、情報処理端末および方法、記録媒体、並びにプログラム |
| US7296187B1 (en) * | 2003-07-14 | 2007-11-13 | Zilog, Inc. | Hardware debug device having script-based host interface |
| US7446895B2 (en) * | 2003-07-18 | 2008-11-04 | Sharp Laboratories Of America, Inc. | Print content system and method for providing document control |
-
2002
- 2002-12-02 JP JP2002349994A patent/JP3654360B2/ja not_active Expired - Lifetime
-
2003
- 2003-11-18 US US10/714,869 patent/US7603465B2/en active Active
- 2003-11-19 SG SG200306819A patent/SG125929A1/en unknown
- 2003-12-02 CN CNB2003101187479A patent/CN100527690C/zh not_active Expired - Fee Related
-
2004
- 2004-12-29 HK HK04110318.0A patent/HK1069491A1/xx not_active IP Right Cessation
-
2009
- 2009-07-24 US US12/509,102 patent/US8065420B2/en not_active Expired - Fee Related
-
2011
- 2011-10-24 US US13/279,927 patent/US9100367B2/en not_active Expired - Fee Related
-
2015
- 2015-07-20 US US14/803,659 patent/US10749862B2/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| US20090282154A1 (en) | 2009-11-12 |
| US8065420B2 (en) | 2011-11-22 |
| US20120042043A1 (en) | 2012-02-16 |
| US10749862B2 (en) | 2020-08-18 |
| CN100527690C (zh) | 2009-08-12 |
| US20150334194A1 (en) | 2015-11-19 |
| US9100367B2 (en) | 2015-08-04 |
| US20040107246A1 (en) | 2004-06-03 |
| SG125929A1 (en) | 2006-10-30 |
| JP2004186883A (ja) | 2004-07-02 |
| CN1510875A (zh) | 2004-07-07 |
| US7603465B2 (en) | 2009-10-13 |
| HK1069491A1 (en) | 2005-05-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3654360B2 (ja) | 制御システムおよび方法、情報処理装置および方法、情報処理端末および方法、記録媒体、並びにプログラム | |
| Soni et al. | API features individualizing of web services: REST and SOAP | |
| JP4825270B2 (ja) | 強化学習及び伝播によるネットワークプロトコルオプションの最適化 | |
| CN111628976B (zh) | 一种报文处理方法、装置、设备及介质 | |
| CN112612985A (zh) | 基于WebSocket的多用户和多类型消息的推送系统及方法 | |
| CN113709263B (zh) | 一种物联网协议mqtt的数据接入方法、计算机及存储介质 | |
| JP2002334056A (ja) | ログイン代行システム及びログイン代行方法 | |
| KR100736081B1 (ko) | 웹 서비스 제공 장치, 웹 서비스 요청 장치, 웹 서비스제공 방법 및 웹 서비스 요청 방법 | |
| CN113556359B (zh) | 一种通讯协议转换方法、设备、系统及网关设备 | |
| US10938960B2 (en) | System and method for implementing augmented object members for remote procedure call | |
| KR20120008401A (ko) | 홈 네트워크에서 멀티캐스트 메시지를 이용하여 복수 개의 원격 사용자 인터페이스 서버들을 제어하기 위한 장치 및 방법 | |
| EP1729217A1 (en) | Data processing method, program, device, message structure, message generation method, and message transmission method | |
| Giretti | Understanding the gRPC Specification | |
| US20080147802A1 (en) | Queuing of invocations for mobile web services | |
| CN101902449A (zh) | 网络设备之间持续http连接的仿真 | |
| JP5091003B2 (ja) | 情報処理システム、情報処理方法、プログラム、及び、記録媒体 | |
| CN114025005A (zh) | 一种数据通讯方法、系统、电子设备及存储介质 | |
| Durmus et al. | Service knowledge discovery in smart machine networks | |
| US20040088395A1 (en) | Method for probing a server | |
| Domingo-Prieto et al. | JXTA security in mobile constrained devices | |
| JP2008176483A (ja) | 情報提供システム | |
| Arasa et al. | Development of android application for Device to Device Communication in IoT using Rabbit MQ broker | |
| EP2608479A1 (en) | Method of communication between at least a first device requesting an execution of a remote function by a second device capable of executing the remote function | |
| Akilli | Analysis of transformation capabilities between communication types of cloud application components | |
| Shan et al. | IoT Communication Based on MQTT and OneNET Cloud Platform in Big Data Environment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050207 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050209 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050222 |
|
| R151 | Written notification of patent or utility model registration |
Ref document number: 3654360 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080311 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090311 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090311 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100311 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100311 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110311 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110311 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120311 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130311 Year of fee payment: 8 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140311 Year of fee payment: 9 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |