JPWO2006080403A1 - 通信機器、通信システム、通信方法、通信プログラム、通信回路 - Google Patents

通信機器、通信システム、通信方法、通信プログラム、通信回路 Download PDF

Info

Publication number
JPWO2006080403A1
JPWO2006080403A1 JP2007500577A JP2007500577A JPWO2006080403A1 JP WO2006080403 A1 JPWO2006080403 A1 JP WO2006080403A1 JP 2007500577 A JP2007500577 A JP 2007500577A JP 2007500577 A JP2007500577 A JP 2007500577A JP WO2006080403 A1 JPWO2006080403 A1 JP WO2006080403A1
Authority
JP
Japan
Prior art keywords
frame
data
transmission
communication
received
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.)
Granted
Application number
JP2007500577A
Other languages
English (en)
Other versions
JP4198741B2 (ja
Inventor
酒井　宏仁
宏仁 酒井
仁志 直江
仁志 直江
深江　文博
文博 深江
大澤　昇平
昇平 大澤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sharp Corp
Original Assignee
Sharp Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from PCT/JP2005/014446 external-priority patent/WO2006013979A1/ja
Application filed by Sharp Corp filed Critical Sharp Corp
Priority claimed from PCT/JP2006/301238 external-priority patent/WO2006080403A1/ja
Publication of JPWO2006080403A1 publication Critical patent/JPWO2006080403A1/ja
Application granted granted Critical
Publication of JP4198741B2 publication Critical patent/JP4198741B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H04L1/009—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location arrangements specific to transmitters

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

送信機（２００１）では、ウィンドウサイズの制限のない各送信フレーム生成に際し、一括送信最終フラグ生成回路（２００４）により一括送信最終フラグ、および通し番号生成回路（２００５）により通し番号を各送信フレームに付与する。受信機では、送信機（２００１）から受信したフレームの通し番号を解析し、通し番号の抜けが検出されたら、受信フレーム中の一括送信最終フラグが最終を示すフレーム受信時に、再送要求を行う。これにより、ＵＩフレームを用いてのデータ転送において、再送を行うことができ、通信効率を向上させることができる。

Description

本発明は、データの送受信を行う通信機器、通信システム、通信方法、通信プログラム、通信回路に関するものである。
近年、赤外線通信システムは、携帯電話、ノート型パーソナルコンピュータや電子手帳等携帯個人用端末を中心に、これら携帯に適した電子機器相互間の、あるいはこれらと、デスクトップ型パーソナルコンピュータや赤外線対応プリンタ等とのデータ交換に普及してきている。
赤外線通信システムにおける通信方式としては、ＩｒＤＡ（Ｉｎｆｒａｒｅｄ Ｄａｔａ Ａｓｓｏｃｉａｔｉｏｎ）方式やＡＳＫ方式などが挙げられるが、ＩｒＤＡ方式は、コンピュータ間を主体とする高速・高効率な伝送のための通信方式であるＨＤＬＣ通信方式を元に、赤外線通信のために規定された通信プロトコルであって、一般的なものとしてよく普及している。
また、コンピュータ等におけるデータ伝送にあたっては、ある大きさのデータと、その前後に付与された通し番号、アドレス等を示す情報とからなるパケットを送受信するパケット交換によることが一般的であるが、ＨＤＬＣ通信方式やＩｒＤＡ通信方式において用いられるパケットはフレームと呼ばれ、ＩｒＬＡＰ層にて管理される。
フレームは、アドレス（Ａ）、制御（Ｃ）、情報（Ｉ）、およびＦＣＳの各フィールドと、前後に付与されるフラグから構成されるものであって、情報（データ）転送用に用いられるＩ（Ｉｎｆｏｒｍａｔｉｏｎ）フレーム、通信の監視制御のためのＳ（Ｓｕｐｅｒｖｉｓｏｒｙ）フレーム、および通信における接続や切断、再送のないデータ通信等のために用いるＵ（Ｕｎｎｕｍｂｅｒｅｄ）フレームがある。
通常、伝送されるべきデータは１フレームで送信できない場合が多いため、複数のフレーム（ＩフレームもしくはＵＩフレーム）に分割して送信される。Ｉフレームは伝送するデータをＩ（Ｉｎｆｏｒｍａｔｉｏｎ）フィールドに持ち、データ抜けのチェックに用いる通し番号を有することで信頼性の高い通信の実現を図る。ＵＩフレームは、伝送するデータをＩフィールドに持つが、データ抜けのチェックに用いる通し番号を持たない。
Ｓフレームはデータを保持するＩフィールドを有しない構成となっていて、受信準備完了、ビジー状態、再送要求等を伝送するのに用いられる。Ｕフレームは、Ｉフレームのような番号を有しないので、非番号フレームと呼ばれ、通信モードの設定、応答や異常状態の報告、データリンクの確立や切断に用いられる。
前述のようにＩｒＤＡ通信方式は、ＨＤＬＣ通信方式に基づくものであるが、一般に通信方式としては、送信と受信とを同時に行い得る全二重通信方式と、同時に行わない半二重通信方式とがあり、半二重通信方式の場合には、送信と受信とを切り換える信号を規定しておく必要がある。
ＨＤＬＣ方式では全二重方式の採用も可能であるが、ＩｒＤＡ通信方式の場合、データの伝送に自由空間上を伝搬するベースバンド変調の赤外線を使用しており、通信圏内で２つ以上の局が同時に送信すると赤外線の干渉が発生して正常な通信を行えない。
このため、ＩｒＤＡ通信方式では、通信リンクを確立する前は通信圏内に赤外線が存在しない場合にのみ送信を行い、通信リンク確立後は通信を行っている２局の間で送信権の交換を定期的に行う半二重方式を用いている。
図１９に、ＩｒＤＡにおける通信リンクを確立する様子を示す。ＩｒＤＡにおいては、一次局がＳＮＲＭコマンドを送信し、二次局がこれに対してＵＡレスポンスを返すことで、リンク層（ＬＡＰ層）の接続が確立する。前記ＳＮＲＭコマンドおよびＵＡレスポンス内には、データ転送時の各種パラメータ（データ転送速度、最大データ長など）が配置され、お互いに対向局の通信パラメータを知ることができ、最も効率の良い通信パラメータにおいて、データ転送が行われることとなる。
図９は、かかる通信方式の応用を説明するためのブロック図である。ＨＤＬＣ通信方式やＩｒＤＡ通信方式では、送信または受信を行うものを「局」と呼び、一般には、通信をコントロールするデータリンク制御を行う一次局と、一次局の制御に従う二次局とが、上記のフレームをコマンド（一次局→二次局）とレスポンス（二次局→一次局）として送受信することで通信を行う。かかる方式は不平衡通信方式といわれる。図示するようにコンピュータ、携帯電話、電子手帳等、ＴＶ等は通信においては局として機能し、赤外線を伝送媒体として、データ交換を行う。
図１０は、これら通信方式におけるＩフレームを用いた一般的な手順を説明するための信号シーケンス図である。ここでは、一次局としてのＡ局から二次局としてのＢ局に複数のＩフレームに分割されたデータを送信する場合を示している。なお、このときのウィンドウサイズ（中断せずに一度の送信できるＩフレーム数）は３とする。
先ず、Ａ局は、送信するデータに対応する各フレームをＩフレームとして番号「０」「１」「２」を付与してそれぞれ送信する。通し番号が「０」「１」のフレームを送信する際には、送信権を二次局に委譲しないために、Ｐ／Ｆ（Ｐｏｌｅ／Ｆｉｎａｌ）ビットを０にして送信する。また、通し番号が「２」のフレームを送信する際には、送信権を二次局に委譲するために、Ｐ／Ｆビットを１にして送信する。
通し番号が「０」「１」「２」のフレームをそれぞれ受信したＢ局は、それぞれのフレームを正常に受信できた場合、Ｐ／Ｆビットが１の通し番号「２」のフレームを受信後、「２」の次の「３」の番号を付与したフレームを応答フレームとして返信し、「３番目のデータを送信せよ」の意を伝達する。この応答フレームはＲＲフレームというＳフレームである。二次局がＲＲフレームを送信する際には、やはり一次局に送信権を委譲するためにＰ／Ｆビットを１にする。
Ａ局はＢ局の応答を確認して３番目のデータから再び「３」「４」「５」の通し番号を付与して送信する。この手順を必要なだけ繰り返すことによって、複数フレーム通信の精度の向上を図ることができる。Ｂ局において、エラーやデータ抜けを検知した場合は、再送して欲しいデータ番号をいれてＲＲフレームを送信し、Ａ局が、前記再送して欲しいデータ番号から再送することで、再送を行うことが可能となる。
Ｉフレームを用いたデータ転送では、一次局が一度に送信できるフレーム数は、ウィンドウサイズによって制限され、ＩｒＤＡのＩｒＬＡＰ（Ｉｎｆｒａｒｅｄ Ｌｉｎｋ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）（Ｖｅｒ１．１）においては、最大７となっている。このため、大量のデータ転送を行う場合には、ウィンドウサイズごとに二次局からの応答フレームが送信されるため、エラーがないような通信状況においては、通信効率の悪化の要因となる。
図１１は、これら通信方式におけるＵＩフレームを用いた一般的な手順を説明するための信号シーケンス図である。ここでは、Ａ局からＢ局に複数のＵＩフレームに分割されたデータを送信する場合を示している。ＵＩフレームを用いたデータ転送の場合は、ウィンドウサイズの制限を受けないため、Ａ局は、最大ターンアラウンド時間の間、連続してフレームを送信することが可能となる。Ａ局の最大ターンアラウンド時間が経過すると、二次局に送信権を委譲するためのＲＲフレームを送信する。
最大ターンアラウンド時間とは、ある局が送信権を維持できる時間であり、送信権を相手局に委譲してから、相手局の最大ターンアラウンド時間を経過しても相手局からレスポンスがない場合は、送信権委譲フレームを送信した局は、相手局に送信権委譲のためのフレームが届いていないことを知ることが可能となる。相手局の最大ターンアラウンド時間は、接続確立時にパラメータ交換することにより、知ることが可能である。ＩｒＬＡＰにおいては、最大５００ｍｓのターンアラウンド時間が規定されている。
ＲＲフレームにより、送信権を委譲されたＢ局は、自局内で送信データ転送要求がない場合は、Ｐ／Ｆビットを１にして、ＲＲフレームを送信することにより、一次局に送信権を委譲する。
ＵＩフレームを用いたデータ転送では、Ｉフレームを用いた場合の再送を行わないが、通信路の品質がよくエラーが発生しないような状況においては、前述のように最大５００ｍｓの時間、Ａ局は連続フレーム送信を行うことが可能であり、通信効率の向上へとつながる。
図１８に標準のＩｒＤＡのプロトコルスタックを示す。ＩｒＤＡのプロトコルスタックは、変調方式、信号強度、指向性等を定義するＩｒＰＨＹ（ＩｒＤＡ Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ）、汎用のＨＤＬＣ（Ｈｉｇｈ Ｌｅｖｅｌ Ｄａｔａ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）に従った誤り制御機能、透過伝送、およびフロー制御の他、通信速度や最大データサイズを通信に先立って互いにネゴシエーションする機能、および接続すべき不特定の外部機器を探索して発見する手続き等を定義したＩｒＬＡＰ（ＩｒＤＡ Ｌｉｎｋ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）プロトコルのＴＣＰやＵＤＰで使われるポート番号に相当する多重化・多重分離の機能を提供するＩｒＬＭＰ（ＩｒＤＡ Ｌｉｎｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）、個別の論理リンクにおいてフロー制御を行うためのＴｉｎｙ ＴＰ（Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）、データの送受信つまりデータ通信におけるオブジェクト交換用の通信プロトコルであるＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）で構成される。
ＯＢＥＸでは、コマンドを要求する側の機器をクライアント機器、その要求に応じて応答を返す側をサーバ機器と呼ぶ。通常、クライアント機器がサーバ機器に対してＰｕｔ／Ｇｅｔなどの要求コマンドを発行し、サーバ機器が応答コマンドを返すクライアント／サーバモデルに従っている。
ＯＢＥＸで規定されている要求コマンドは概ね次のものを備えている。通信相手と接続／切断を行うＣＯＮＮＥＣＴ／ＤＩＳＣＯＮＮＥＣＴ、ファイルなどのオブジェクトの送信／受信を行うＰＵＴ／ＧＥＴ、受信機器側であるサーバ機器の受信先パス（カレントパス）を変更するＳＥＴＰＡＴＨ、そしてオブジェクトの送信や受信を強制的に中断するＡＢＯＲＴがある。
図２０に、クライアント機器とサーバ機器との間での基本的な要求コマンド／応答コマンドのやり取りについて説明する。利用者からのオブジェクト交換要求を受けると、クライアント機器はサーバ機器との接続を確立するために、サーバ機器に対して、接続要求を意味するＣＯＮＮＥＣＴコマンドを送信する。
ＣＯＮＮＥＣＴコマンドを受信したサーバ機器はクライアント機器に対して、接続が可能である場合には、ＳＵＣＣＥＳＳ応答コマンドを返信し、クライアント機器がＳＵＣＣＥＳＳの応答コマンドを受信することにより、クライアント機器−サーバ機器の間で接続が確立される。
クライアント機器では、接続確立後、オブジェクトの交換を開始し、サーバ機器に対してオブジェクトの送信を行うＰＵＴコマンドを送信する。サーバ機器はクライアント機器からのＰＵＴコマンドを正常に受信するとＣＯＮＴＩＮＵＥ応答コマンドを返信し、クライアント機器は、サーバ機器からのＣＯＮＴＩＮＵＥ応答コマンドを受信し、サーバ機器が正常にＰＵＴコマンドを受信したことを確認後、次のＰＵＴコマンドを送信する。クライアント機器では、すべてのオブジェクトを送信し終えるまで、ＰＵＴコマンドの送信を行う。サーバ機器では、最後のＰＵＴ（Ｆｉｎａｌ）コマンドまで正常に受信し終えると、ＳＵＣＣＥＳＳの応答コマンドをクライアント機器に対して返信する。
クライアント機器では、サーバ機器からのＳＵＣＣＥＳＳの応答コマンドを受信後、サーバ機器との切断処理を行うために切断要求を意味するＤＩＳＣＯＮＮＥＣＴコマンドをサーバ機器に対して送信する。
ＤＩＳＣＯＮＮＥＣＴコマンドを受信したサーバ機器はクライアント機器に対して、切断の許可を意味するＳＵＣＣＥＳＳの応答コマンドを返信し、クライアント機器がＳＵＣＣＥＳＳの応答コマンドを受信することにより、クライアント機器−サーバ機器の間の接続が切断され、一連のクライアント機器−サーバ機器間のオブジェクト交換が完了する。
このように、ＯＢＥＸでは、クライアント機器からの要求コマンドに対して、サーバ機器が応答コマンドを返すことにより、オブジェクトの交換を行う。
また、上記のＩｒＤＡプロトコルスタックにあるようにＯＳＩのような階層構造を持つ通信プロトコルにおいては、層毎に他の層とは独立にヘッダ情報が定義されており、計算機器間で本来転送されるべきデータに、最上位層から最下位層まで各層においてヘッダ情報が順次付加される。
また、受信データに対しては、最下位層から最上位層までの各層において順次ヘッダ情報が除去され、上位層にデータが渡されていく。
〔特許文献１〕日本国公開特許公報「特開平１０−３０８７９１号公報（公開日１９９８年１１月１７日）」
しかしながら、上記従来の構成では、ＵＩフレームを用いてデータ転送では、通信路の品質が良くエラーが発生しないような状況においては、前述のように最大５００ｍｓの時間、連続フレーム送信を行うことが可能であり、通信効率の向上へとつながるが、あまり通信路の品質が良くない場合には、Ｉフレームを用いた場合のような再送を行うことができないので、かえって通信効率が悪化してしまうという問題を生じる。
また、従来のＩｒＤＡでは、レスポンスを必要としない片方向通信でのデータ転送はサポートされていない。
本発明の目的は、データ転送においてフレームの再送を行うことができる通信機器、通信システム、通信方法、通信プログラム、通信回路を提供することにある。
上記の目的を達成するために、本発明に係る通信機器は、一度に送信可能なフレーム数に制限がない通信方式に従って、送信権を委譲せずに、データを一括送信する通信機器であって、一括送信する一括送信データを分割して送信フレームを生成する送信フレーム生成部（送信フレーム生成回路、送信フレーム生成手段）と、上記送信フレームに通し番号を付与する通し番号生成部（通し番号生成回路、通し番号生成手段）と、上記一括送信データの最終の送信フレームに、一括送信データの最終の送信フレームであることを示す一括送信最終フラグを設定する一括送信最終フラグ生成部（一括送信最終フラグ生成回路、一括送信最終フラグ生成手段）と、上記送信フレームを送信する送信部（送信回路、送信手段）と、を備えることを特徴としている。
また、本発明に係る通信方法は、一度に送信可能なフレーム数に制限がない通信方式に従って、送信権を委譲せずに、データを一括送信する通信方法であって、一括送信する一括送信データを分割して送信フレームを生成し、上記送信フレームに通し番号を付与し、上記一括送信データの最終の送信フレームには、一括送信データの最終の送信フレームであることを示す一括送信最終フラグを設定して、上記送信フレームを送信することを特徴としている。
また、本発明に係る通信機器は、一度に送信可能なフレーム数に制限がない通信方式に従って、送信権を委譲されずに、データを一括受信する通信機器であって、上記受信フレームに含まれる通し番号を解析して、通し番号のエラーがないかどうかを判別する通し番号解析部（通し番号解析回路、通し番号解析手段）と、上記受信フレームに含まれる一括送信最終フラグが、当該受信フレームが送信機によって複数の送信フレームに分割されて一括送信された一括送信データの最終の送信フレームであることを示しているとき、上記通し番号解析部によって、それまでに受信した受信フレームにエラーが検出された場合、エラー有りを示すように設定したエラー無しフラグおよびエラー発生時の通し番号を含む送信フレームを生成する送信フレーム生成部（送信フレーム生成回路、送信フレーム生成手段）と、上記送信フレームを送信する送信部（送信回路、送信手段）と、を備えることを特徴としている。
また、本発明に係る通信方法は、一度に送信可能なフレーム数に制限がない通信方式に従って、送信権を委譲されずに、データを一括受信する通信方法であって、上記受信フレームに含まれる通し番号を解析して、通し番号のエラーがないかどうかを判別し、上記受信フレームに含まれる一括送信最終フラグが、当該受信フレームが送信機によって複数の送信フレームに分割されて一括送信された一括送信データの最終の送信フレームであることを示しているとき、それまでに受信した受信フレームにエラーが検出された場合、エラー有りを示すように設定したエラー無しフラグおよびエラー発生時の通し番号を含む送信フレームを生成し、上記送信フレームを送信することを特徴としている。
また、本発明に係る通信システムは、上記の送信機としての通信機器と、上記の受信機としての通信機器とを含むことを特徴としている。
上記の構成および方法により、一度に送信可能なフレーム数に制限がない通信方式に従って、送信権を委譲せずに、データを一括送信する際に、送信機では、一括送信データを分割して送信フレームを生成し、送信フレームに通し番号を付与するとともに、さらに、一括送信データの最終の送信フレームには、一括送信データの最終の送信フレームであることを示す一括送信最終フラグを設定して、送信フレームを送信する。一方、受信機では、受信フレームに含まれる通し番号を解析して、通し番号のエラーがないかどうかを判別し、受信フレームにエラーが検出された場合、エラー有りを示すように設定したエラー無しフラグおよびエラー発生時の通し番号を含む送信フレームを生成して、送信機へ送信する。そして、送信機は、受信機から、エラー発生時の通し番号を含むフレームを受信すると、その通し番号に対応する送信フレームを再送する。
ここで、受信機は、送信機が一括送信データを分割した送信フレームの内の最終の送信フレームを受信したことが、受信フレームに含まれる一括送信最終フラグによって判明するまで、上記エラー発生時の通し番号を含む送信フレームを送信しない。つまり、エラーの通知を一括送信データ単位で行う。
よって、一度に送信または受信可能なフレーム数（ウィンドウサイズ）の制限がない通信方式を用いても、フレームの抜け等を検出して、再送することができるため、信頼性の高い通信を行うことが可能となるという効果を奏する。また、エラーの通知を一括送信データ単位で行うため、データ転送の効率がよいという効果を奏する。
なお、上記通信機器は、コンピュータによって実現してもよく、この場合には、コンピュータを上記通信機器の各部として動作させることにより上記通信機器をコンピュータにて実現させる通信機器の通信プログラム、およびそれを記録したコンピュータ読み取り可能な記録媒体も、本発明の範疇に入る。
また、上記通信機器は、上記の各部として機能する通信回路によって実現してもよい。
また、上記通信機器は、該通信機器によって通信を行う携帯電話に好適である。上記携帯電話によれば、品質および／あるいは転送効率の高い通信を行うことが可能となる。
また、上記通信機器は、該通信機器によって受信したデータに基づいて表示する表示装置に好適である。このような表示装置によれば、品質および／あるいは転送効率の高い通信を行うことが可能となる。
また、上記通信機器は、該通信機器によって受信したデータに基づいて印刷する印刷装置に好適である。このような印刷装置によれば、品質および／あるいは転送効率の高い通信を行うことが可能となる。
また、上記通信機器は、該通信機器によって受信したデータを記録する記録装置に好適である。このような記録装置によれば、品質および／あるいは転送効率の高い通信を行うことが可能となる。
本発明のさらに他の目的、特徴、および優れた点は、以下に示す記載によって十分に分かるであろう。また、本発明の利点は、添付図面を参照した次の説明で明白になるであろう。
本発明の通信システムに用いる実施の第一形態に係る一次局の構成を示すブロック図である。 上記実施の第一形態に係る二次局の構成を示すブロック図である。 上記実施の第一形態におけるフレーム構成を示すブロック図である。 上記実施の第一形態におけるデータ転送処理の手順を示す信号シークエンス図である。 上記実施の第一形態におけるエラー発生時のデータ転送処理の手順を示す信号シークエンス図である。 本発明の通信システムにおける実施の第二形態に係る一次局、二次局の構成を示すブロック図である。 上記実施の第二形態におけるフレーム構成を示すブロック図である。 上記実施の第二形態におけるデータ転送処理の手順を示す信号シークエンス図である。 従来からのＨＤＬＣ通信方式やＩｒＤＡ通信方式の応用を説明するためのブロック図である。 ＩｒＤＡ通信規格におけるＩフレームを用いたデータ転送の一般的な手順を説明するための信号シークエンス図である。 ＩｒＤＡ通信規格におけるＵＩフレームを用いたデータ転送の一般的な手順を説明するための信号シークエンス図である。 本発明の通信システムにおける実施の第三形態に係る一次局、二次局の構成を示すブロック図である。 上記実施の第三形態におけるデータ転送システムのプロトコルスタックを示す図である。 上記実施の第三形態におけるフレーム構成を示すブロック図である。 上記実施の第三形態におけるデータ転送処理の手順を示す信号シークエンス図である。 上記実施の第三形態における認証時などに上位層から認証要求が発行される場合のデータ転送の手順を示す信号シークエンス図である。 上記実施の第三形態における認証時などに上位層から認証要求が発行される場合のデータ転送の他の手順を示す信号シークエンス図である。 従来のＩｒＤＡのプロトコルスタックを示す図である。 従来のＩｒＤＡにおける接続時のシークエンス図である。 ＯＢＥＸの接続、データ転送、切断のシークエンス図である。 ＩｒＤＡでのデータ転送の流れを示すシークエンス図である。 （ａ）はＩｒＬＡＰにおけるＩフレームのフレームフォーマット、（ｂ）はＩｒＬＡＰにおけるＵＩフレームのフレームフォーマットを示す説明図である。 ＩｒＬＭＰのフレームフォーマットを示す説明図である。 ＴｉｎｙＴＰ層のフレームフォーマットを示す説明図である。 （ａ）はＯＢＥＸのＰｕｔコマンドのフレームフォーマット、（ｂ）はＣＯＮＴＩＮＵＥレスポンスのフレームフォーマット、（ｃ）はＳＵＣＣＥＳＳレスポンスのフレームフォーマットを示す説明図である。 ＩｒＳｉｍｐｌｅの双方向通信でのデータ転送の流れを示すシークエンス図である。 （ａ）はＩｒＳｉｍｐｌｅの双方向通信の場合のＳＭＰフレームのフレームフォーマット、（ｂ）はＩｒＳｉｍｐｌｅの片方向通信の場合のＳＭＰフレームのフレームフォーマットを示す説明図である。 ＩｒＳｉｍｐｌｅの片方向通信でのデータ転送の流れを示すシークエンス図である。 上位層としてＯＢＥＸが存在し、ＯＢＥＸのＰｕｔコマンドによるデータ転送を示すシークエンス図である。 受信機がエラー無しフラグを含むフレームとＳＵＣＣＥＳＳを含むフレームとを１つにまとめて送信する通信例を示すシークエンス図である。 本発明の通信システムに用いる実施の第四形態に係る送信機の構成を示すブロック図である。 本発明の通信システムに用いる実施の第四形態および第五形態に係る受信機の構成を示すブロック図である。 本発明の通信システムに用いる実施の第四形態に係るシークエンス図である。 本発明の通信システムに用いる実施の第五形態に係る送信機の構成を示すブロック図である。 本発明の通信システムに用いる実施の第五形態に係る第一のシークエンス図である。 本発明の通信システムに用いる実施の第五形態に係る第二のシークエンス図である。 本発明の通信システムに用いる実施の第六形態に係る送信機の構成を示すブロック図である。 本発明の通信システムに用いる実施の第六形態に係る受信機の構成を示すブロック図である。 本発明の通信システムに用いる実施の第六形態に係るシークエンス図である。 本発明の通信システムに用いる実施の第七形態に係る送信機の構成を示すブロック図である。 本発明の通信システムに用いる実施の第七形態に係る受信機の構成を示すブロック図である。 本発明の通信システムに用いる実施の第七形態に係るシークエンス図である。 本発明の通信システムに用いる実施の第八形態に係るシークエンス図である。 本発明の通信システムに用いる実施の第九形態に係る送信機の構成を示すブロック図である。 本発明の通信システムに用いる実施の第九形態に係る受信機の構成を示すブロック図である。 本発明の通信システムに用いる実施の第九形態に係るシークエンス図である。 ＪＰＥＧエンコーダおよびＪＰＥＧデコーダの構成を示すブロック図である。 ＪＰＥＧのブロック（ｍｃｕ）の説明図であり、（ａ）は８×８、（ｂ）は８×１６、（ｃ）は１６×８、（ｄ）は１６×１６のブロックを示す。 本発明の通信システムにおけるｍｃｕ単位での分割、再送処理の説明図である。 本発明の通信システムにおけるライン単位での分割、再送処理の説明図である。 本発明の通信システムにおけるファイル単位での分割、再送処理の説明図である。 従来の通信システムにおけるクライアント機器の構成を示すブロック図である。 従来の通信システムにおけるＯＢＥＸクライアントの動作を示すフローチャートである。 本発明に係る実施の第十一形態および第十二形態の通信システムにおけるクライアント機器の構成を示すブロック図である。 上記実施の第十一形態の通信システムにおけるクライアント機器におけるＯＢＥＸ層の動作を示すフローチャートである。 本発明に係る実施の第十一形態の通信システムにおけるクライアント機器におけるＯＢＥＸ層の他の動作を示すフローチャートである。 本発明に係る実施の第十二形態の通信システムにおけるクライアント機器におけるＯＢＥＸ層の動作を示すフローチャートである。 従来の通信システムにおけるサーバ機器の構成を示すブロック図である。 従来の通信システムにおけるＯＢＥＸサーバの動作を示すフローチャートである。 本発明に係る実施の第十三形態および第十四形態の通信システムにおけるサーバ機器の他の構成を示すブロック図である。 上記実施の第十三形態の通信システムにおけるサーバ機器におけるＯＢＥＸ層の動作を示すフローチャートである。 上記実施の第十三形態の通信システムにおけるサーバ機器におけるＯＢＥＸ層の他の動作を示すフローチャートである。 本発明に係る実施の第十四形態の通信システムにおけるサーバ機器におけるＯＢＥＸ層の動作を示すフローチャートである。 本発明の通信システムを用いた実施の第十五形態に係る通信システムの説明図である。 本発明の通信システムを用いた実施の第十六形態に係る通信システムの説明図である。 本発明の通信システムを用いた実施の第十七形態に係る通信システムの説明図である。 本発明の通信システムを用いた実施の第十八形態に係る通信システムの説明図である。 ＯＳＩ７階層モデルと、ＩｒＤＡの階層および本発明の階層の対応関係を示す模式図である。 （ａ）は、本発明の実施の形態に係る接続確立のシーケンス図である。（ｂ）は、本発明の実施の形態に係る接続確立のシーケンス図である。（ｃ）は、本発明の実施の形態に係る接続確立のためのパケットフォーマットである。 （ａ）は、本発明の実施の形態に係るデータ交換シーケンスを示す図である。（ｂ）は、本発明の実施の形態に係るデータ交換シーケンスを示す図である。 （ａ）は、ＩｒＤＡのデータ交換で使用されるパケットフォーマットを示す図である。（ｂ）は、本発明のデータ交換で使用されるパケットフォーマットを示す図である。 （ａ）は、本発明の実施の形態に係るデータ交換シーケンスを示す図である。（ｂ）は、本発明の実施の形態に係るデータ交換シーケンスを示す図である。 （ａ）は、本発明の実施の形態に係る切断シ−ケンスを示す図である。（ｂ）は、本発明の実施の形態に係る切断シーケンスを示す図である。（ｃ）は、本発明の実施の形態に係る切断シーケンスのパケットフォーマットである。 本発明の実施の形態に係る接続シーケンス時の各層間の関数（命令、メッセージ）とパケットの流れを示すシーケンス図である。 （ａ）は、本発明の実施の形態に係る接続シーケンス時の図７４および図７６における右向きの矢印の各層間の関数におけるデータの変化を示す説明図である。（ｂ）は、本発明の実施の形態に係る各層間の関数におけるデータの変化を示す図である。 本発明の実施の形態に係る接続シーケンス時の各層間の関数（命令、メッセージ）とパケットの流れを示すシーケンス図である。 本発明の実施の形態に係るデータ交換時の各層間の関数（命令、メッセージ）とパケットの流れを示すシーケンス図である。 本発明の実施の形態に係るデータ交換時の図７７および図７９における各層間の関数におけるデータの変化を示す図である。 本発明の実施の形態に係るデータ交換時の各層間の関数（命令、メッセージ）とパケットの流れを示すシーケンス図である。 本発明の実施の形態に係る切断シーケンス時の各層間の関数（命令、メッセージ）とパケットの流れを示すシーケンス図である。 （ａ）は、本発明の実施の形態に係る切断シーケンス時の図８０および図８２における右向きの矢印の各層間の関数におけるデータの変化を示す説明図である。（ｂ）は、本発明の実施の形態に係る各層間の関数におけるデータの変化を示す説明図である。 本発明の実施の形態に係る切断シーケンス時の各層間の関数（命令、メッセージ）とパケットの流れを示すシーケンス図である。 本発明の実施の形態に係る１次局における接続要求関数のデータと接続パラメータの受け渡しを表す模式図である。 本発明の実施の形態に係る２次局における接続要求関数の接続パラメータの受け渡しを表す模式図である。 本発明の実施の形態に係る１次局における接続確認関数と２次局における接続通知関数のデータと接続パラメータの受け渡しを表す模式図である。 本発明の実施の形態に係る２次局における接続返答関数のデータの受け渡しを表す模式図である。 本発明の実施の形態に係る１次局における接続確認関数の接続パラメータの受け渡しを表す模式図である。 実施の形態の変形例である、接続パラメータを層間で共有する場合のの１次局における接続要求関数のデータと接続パラメータの受け渡しを表す模式図である。 実施の形態の変形例である、接続パラメータを層間で共有する場合の２次局における接続通知関数のデータと接続パラメータの受け渡しを表す模式図である。 実施の形態の変形例である、接続パラメータを各層が別々に下位層に渡す場合の１次局における接続要求関数のデータと接続パラメータの受け渡しを表す模式図である。
〔符号の説明〕
１ 一次局
１１ ＣＰＵ
１２ メモリ
１３ コントローラ
１４ 送信器
１５ 受信器
１３１ 制御部
１３２ 送信フレーム生成部
１３３ 受信フレーム解析部
１３２１ データ読み出し部
１３２２ フレーム通し番号付加部
１３２３ 送信権委譲フラグ付加部
１３２４ フレーム構築部
１３２５ 誤り検出または訂正符号付加部
１３３１ 再送要求判定部
１３３２ フレーム通し番号抽出部
２ 二次局
２１ ＣＰＵ
２２ メモリ
２３ コントローラ
２４ 受信器
２５ 送信器
２３１ 制御部
２３２ フレーム処理部
２３３ 誤り検出または訂正回路
２３４ エラーフレーム番号保持部
２３５ レスポンスフレーム生成部
２３６ 誤り検出または訂正符号付加部
６ 一次局または二次局
６１ ＣＰＵ
６２ コントローラ
６３ 送信器
６４ 受信器
６２１ 制御部
６２２ 送信フレーム生成部
６２３ 受信フレーム解析部
６２２１ 接続確立フレーム生成部
６２２２ 再送可能フレーム数付加部
６２３１ フレーム解析部
６２３２ 再送可能フレーム数検出部
１２ 局（一次局または二次局）
１２１ Ａｐｐｌｏｃａｔｉｏｎ層処理部
１２２ ＯＢＥＸ層処理部
１２３ ＳＭＰ層処理部
１２４ ＩｒＬＭＰ層処理部
１２５ ＩｒＬＡＰ層処理部
１２６ 送信器
１２７ 受信器
１２３１ 制御部
１２３２ 送信フレーム生成部
１２３３ 受信フレーム生成部
１２３２１ 応答フレーム要求フラグ付加部
１２３２２ フレーム通し番号付加部
１２３２３ 送信権委譲フラグ付加部
１２３２４ 再送要求フラグ付加部
１２３２５ フレーム構築部
１２３３１ 応答フレーム要求フラグ判定部
１２３３２ フレーム通し番号解析部
１２３３３ 送信権委譲フラグ判定部
１２３３４ 再送要求判定部
１２３３５ 上位層データ抽出部
２００１ 送信機（一次局、クライアント機器）
２００２ 制御部（制御手段）
２００３ メモリ（記憶手段）
２００４ 一括送信最終フラグ生成回路（一括送信最終フラグ生成手段）
２００５ 通し番号生成回路（通し番号生成手段）
２００６ 送信フレーム生成回路（送信フレーム生成手段）
２００７ 送信部（送信手段）
２００８ 受信部（受信手段）
２００９ 受信フレーム解析回路（受信フレーム解析手段）
２０１０ エラー無しフラグ解析回路（エラー無しフラグ解析手段）
２０１１ エラー検出回路（エラー検出手段）
２０１２ 通し番号解析回路（通し番号解析手段）
２１０１ 受信機（二次局、サーバ機器）
２１０２ 制御部（手段）
２１０３ メモリ（手段）
２１０４ エラー無しフラグ生成回路（エラー無しフラグ生成手段）
２１０５ 通し番号生成回路（通し番号生成手段）
２１０６ 送信フレーム生成回路（送信フレーム生成手段）
２１０７ 送信部（送信手段）
２１０８ 受信部（受信手段）
２１０９ 受信フレーム解析回路（受信フレーム解析手段）
２１１０ 一括送信最終フラグ解析回路（一括送信最終フラグ解析手段）
２１１１ エラー検出回路（エラー検出手段）
２１１２ 通し番号解析回路（通し番号解析手段）
２２０１ 送信機（一次局、クライアント機器）
２２１３ タイマ（計時手段）
２３０１ 送信機（一次局、クライアント機器）
２３１３ 対向局バッファサイズ解析回路（対向局バッファサイズ解析手段）
２４０１ 受信機（二次局、サーバ機器）
２４１３ バッファサイズ生成回路（バッファサイズ生成手段）
２５０１ 送信機（一次局、クライアント機器）
２５１３ データ最終フラグ生成回路（データ最終フラグ生成手段）
２６０１ 受信機（二次局、サーバ機器）
２６１３ データ最終フラグ解析回路（データ最終フラグ解析手段）
２７０１ 送信機（一次局、クライアント機器）
２７０２ 制御部（制御手段）
２７０３ メモリ（記憶手段）
２７０５ 通し番号生成回路（通し番号生成手段）
２７０６ 送信フレーム生成回路（送信フレーム生成手段）
２７０７ 送信部（送信手段）
２７１３ データ最終フラグ生成回路（データ最終フラグ生成手段）
２８０１ 受信機（二次局、サーバ機器）
２８０２ 制御部（手段）
２８０３ メモリ（手段）
２８０８ 受信部（受信手段）
２８０９ 受信フレーム解析回路（受信フレーム解析手段）
２８１１ エラー検出回路（エラー検出手段）
２８１２ 通し番号解析回路（通し番号解析手段）
２８１３ データ最終フラグ解析回路（データ最終フラグ解析手段）
３３００ クライアント機器（通信装置、一次局）
３３１０ アプリケーション層処理部
３３２０ ＯＢＥＸ層処理部（オブジェクト交換層処理部）
３３２１ 制御部
３３２２ 要求通知部
３３２３ 応答受信部
３３２４ 通信方向選択部
３３３０ 下位層処理部
３３４０ 送信部
３３５０ 受信部
３５００ サーバ機器（通信装置、二次局）
３５１０ アプリケーション層処理部
３５２０ ＯＢＥＸ層処理部（オブジェクト交換層処理部）
３５２１ 制御部
３５２２ 応答通知部
３５２３ 要求解析部
３５３０ 下位層処理部
３５４０ 送信部
３５５０ 受信部
はじめに、本発明の通信システムの概要について、図２１から図３０を参照しながら説明すると以下の通りである。
〔概要〕
（通信層）
後述する各実施の形態では、本発明に係る通信システムの送信機および受信機の構成および動作について、ＯＳＩ７層モデルに基づいて詳細に説明する。ここで、ＯＳＩ７層モデルとは、いわゆる「ＯＳＩ基本参照モデル」「ＯＳＩ階層モデル」とも呼ばれているものである。
ＯＳＩ７層モデルでは、異機種間のデータ通信を実現するために、コンピュータの持つべき通信機能が７階層に分割され、各層ごとに標準的な機能モジュールが定義されている。
具体的には、第１層（物理層）は、データを通信回線に送出するための電気的な変換や機械的な作業を受け持つ。第２層（データリンク層）は、物理的な通信路を確保し、通信路を流れるデータのエラー検出などを行う。第３層（ネットワーク層）は、通信経路の選択や通信経路内のアドレスの管理を行う。第４層（トランスポート層）は、データ圧縮や誤り訂正、再送制御などを行う。第５層（セッション層）は、通信プログラム同士がデータの送受信を行うための仮想的な経路（コネクション）の確立や解放を行う。第６層（プレゼンテーション層）は、第５層から受け取ったデータをユーザが分かりやすい形式に変換したり、第７層から送られてくるデータを通信に適した形式に変換したりする。第７層（アプリケーション層）は、データ通信を利用した様々なサービスを人間や他のプログラムに提供する。
各実施の形態に係る通信システムの各通信層も、上記ＯＳＩ７層モデルの対応する階層と同等の機能を有する。ただし、各実施の形態では、上記通信システムは、セッション層とプレゼンテーション層とを１つにした、６階層の構造となっている。また、アプリケーション層については、説明を省略する。
本発明は、送信機および受信機が複数の通信層の接続を確立して通信を行う通信システムに広く適用可能である。すなわち、通信機能の分割はＯＳＩ７層モデルに従っていなくてもよい。また、通信層の数は、接続すべき通信層が複数であれば、任意に選択できる。
また、本発明は、フレームに通し番号を付与して、フレーム単位の再送を一括送信データごとに行うことを可能とするものであるため、エラーの少ない通信においては、通信効率が高く、また仮にエラーが発生した場合でも、再送により通信の信頼性を確保することができる。よって、本発明は、短時間に大量のデータを送信を行いたい通信、例えば赤外線による無線通信に特に適している。ただし、本発明は、他の無線通信、および、有線通信においても効果的である。
各実施の形態では、説明の便宜上、本発明の一適用例であるＩｒＳｉｍｐｌｅに基づいて説明する。しかし、本発明はＩｒＳｉｍｐｌｅに限定されるものではない。なお、ＩｒＳｉｍｐｌｅとは、従来のＩｒＤＡの一部機能を改良したものである。
各実施の形態では、ＩｒＳｉｍｐｌｅに則って、データリンク層、ネットワーク層、トランスポート層、セッション層＋プレゼンテーション層を、それぞれ、ＬＡＰ、ＬＭＰ、ＳＭＰ、ＯＢＥＸと表記することがある。また、通信層を送信機、受信機で区別する場合には、送信機に“Ｐ”、受信機に“Ｓ”と付記する。例えば、“ＬＡＰ（Ｐ）”とは、送信機のデータリンク層を意味する。
（ＩｒＤＡとＩｒＳｉｍｐｌｅとの比較）
以下、本発明の従来技術であるＩｒＤＡと、本発明の一適用例であるＩｒＳｉｍｐｌｅとを比較する。
１．ＩｒＤＡにおけるデータ転送の流れ
図２１に、従来ＩｒＤＡでのデータ転送の流れを示す。なお、以下の説明においては、ＩｒＤＡプロトコルスタックとして、ＩｒＬＡＰ、ＩｒＬＭＰ、ＴｉｎｙＴＰ（図中でのＴＴＰ）、ＯＢＥＸが存在するものとする。
（１）ＩｒＬＡＰ層は、データ転送において、エラー時に再送を行うことで、上位層に対して、データの信頼性を保証するモードと、エラー時に再送を行わず、上位層に対して、データの信頼性を保証しないモードが存在する。本説明においては、前述の信頼性を保証するモードでのデータ転送を行うこととする。また、信頼性を保証するために、ＩｒＬＡＰでは、Ｉ（Ｉｎｆｏｒｍａｔｉｏｎ）フレームを用いてデータ転送を行う。
図２２（ａ）に、ＩｒＬＡＰにおけるＩフレームのフレームフォーマットを示す。
Ｉフレームには、フレームを受信する機器において、フレームの抜けを検出できるようにするために、通し番号が振られる。この通し番号は、図２２（ａ）のＮｓフィールド領域に割り当てられる。
ＩｒＬＡＰでは、Ｉフレームを用いてデータ転送を行う場合、一度に送信可能なフレーム数（ウィンドウサイズ）に制限を設けており、ウィンドウサイズは最大７となる。このウィンドウサイズは、接続時に、一次局と二次局が、それぞれ自機器が一度に受信可能なフレーム数（ウィンドウサイズ）を対向局に通知する。そして、対向局のウィンドウサイズを超えるフレームを連続して送信してはいけないこととなっている。本説明においては、一次局のウィンドウサイズは１、二次局のウィンドウサイズは２としている。
また、フレームを受信した機器が受信成功が否かを通知するために、Ｎｒフィールドが存在する。連続して受信したフレームが全て正常であった場合は、次に送信して欲しい通し番号をＮｒフィールドに設定して、送信する。例えば、Ｎｓが１、２のフレームを連続受信して、いずれも正常受信した場合は、Ｎｒフィールドに３を設定して送信する。
一方、受信フレームに誤りがあった場合は、再送して欲しいフレームの通し番号をＮｒフィールドに設定して送信する。例えば、Ｎｓが１、２のフレームを連続受信して、２のフレームにエラーがあったと判別された場合、Ｎｒフィールドに２を設定して送信する。
フレームを送信した機器は、フレームを連続送信後、受信フレームのＮｒフィールドを監視し、Ｎｒフィールドが自機器の送信したフレームの内、最後に送信したフレームのＮｓの値より１だけ大きい値である場合は、前回のフレーム連続送信がすべて正常に完了したことを認識し、次のフレーム送信を開始する。また、受信フレームのＮｒフィールドが自機器の送信したフレームの内のいくつかの通し番号の値である場合は、その通し番号から再送を行うこととなる。このとき、Ｎｓフィールドも、Ｎｒフィールドの値から振り直す。
上述の手順により、ＩｒＬＡＰ層におけるＩフレームを用いた再送が可能となる。ＩｒＬＡＰの再送を用いる場合、ウィンドウサイズはＩｒＬＡＰの規格上、最大７であるため、８以上のフレームを連続送信することは不可能である。
（２）ＩｒＬＭＰ層は、アプリケーションごとの論理的なチャネル（ＬＳＡＰ：Ｌｉｎｋ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）を上位層に提供する層である。
図２３に、ＩｒＬＭＰのフレームフォーマットを示す。
フレームを送信する側のＩｒＬＭＰ層では、上位層（ＴｉｎｙＴＰ層）からのデータとＩｒＬＭＰフレームに配置するとともに、送信先の論理的なチャネル（ＤＬＳＡＰ：Ｄｅｓｔｉｎａｔｉｏｎ Ｌｉｎｋ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）と送信元の論理的なチャネル（ＳＬＳＡＰ：Ｓｏｕｒｃｅ Ｌｉｎｋ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）をＩｒＬＭＰヘッダとして、配置する。
一方、フレームを受信する側のＩｒＬＭＰ層では、下位層からの受信フレームのＤＬＳＡＰフィールドを監視することにより、どの上位層アプリケーションのデータであるかを判別し、対応する上位層アプリケーションに対して、受信フレーム内データを渡す。
（３）ＴｉｎｙＴＰ層は、上位層（ＯＢＥＸ層）データの分割・結合およびフロー制御を行う層である。
図２４に、ＴｉｎｙＴＰ層のフレームフォーマットを示す。
ＴｉｎｙＴＰ層は、上位層から送信データが渡されると、下位層（ＬＡＰ層）の最大フレーム長を超えない範囲で、送信データを分割して、下位層（ＬＭＰ層）にデータを渡す。また、受信する側においては、下位層（ＩｒＬＭＰ層）からの受信フレーム内のデータを結合し、上位層（ＯＢＥＸ層）に渡す。また、受信バッファがあふれるのを未然に防ぐために、自局が受信可能なフレーム数をクレジットという形で、対向局に通知する。そして、対向局のクレジットを超えるフレームを連続して送信してはいけないことになっている。
（４）ＯＢＥＸ層は、オブジェクト交換用のプロトコルである。
図２５に、ＯＢＥＸ層のフレームフォーマットを示す。
図２５（ａ）がＯＢＥＸ層のＰｕｔコマンドのフォーマットである。ＯＢＥＸ層は、ファイルの送信を行う場合は、Ｐｕｔコマンドを用いて送信を行う。また、送信するファイルのファイル名、ファイルサイズなどの情報も合わせて付加される。
また、図２５（ｂ）および（ｃ）が、ＣＯＮＴＩＮＵＥレスポンスおよびＳＵＣＣＥＳＳレスポンスのフレームフォーマットである。ファイルの受信を行う側は、Ｐｕｔコマンド受信ごとに、レスポンスを返す必要がある。最終でないＰｕｔコマンドを受信した場合は、ＣＯＮＴＩＮＵＥレスポンスを、また最終のＰｕｔコマンドを受信した場合は、ＳＵＣＣＥＳＳレスポンスをそれぞれ返信する。
つづいて、従来のＩｒＤＡにおける、ＯＢＥＸのＰｕｔコマンドを用いたデータ転送の手順について説明する。
一次局のＯＢＥＸにおいてファイル送信要求が発生すると、一次局のＯＢＥＸ層（以下、ＯＢＥＸ（Ｐ））は、下位層である一次局のＴｉｎｙＴＰ層（以下、ＴＴＰ（Ｐ））に対して、Ｐｕｔコマンドを送信データとして渡す。本説明においては、Ｐｕｔコマンドが、ｄａｔａＰ０、ｄａｔａＰ１、ｄａｔａＰ２、ｄａｔａＰ３で構成されているものとする。
これを受けたＴＴＰ（Ｐ）は、下位層であるＬＡＰ層の最大データ長に送信データを分割する。本説明においては、ＴＴＰ（Ｐ）において、ｄａｔａＰ０、ｄａｔａＰ１、ｄａｔａＰ２、ｄａｔａＰ３に分割されるものとする。また、ＴＴＰ（Ｐ）の受信可能クレジット数は１であるため、クレジットを１とする。前記クレジットおよび分割データを用いて、ＴＴＰフレームとして生成し、下位層である一次局のＩｒＬＭＰ層（以下、ＬＭＰ（Ｐ））に渡す。
これを受けたＬＭＰ（Ｐ）は、論理チャネル情報（ＬＳＡＰヘッダ）を付加して、ＬＭＰフレームを生成し、下位層である一次局のＩｒＬＡＰ層（以下、ＬＡＰ（Ｐ））に渡す。
これを受けたＬＡＰ（Ｐ）は、Ｉフレームを用いて、データ転送を行う。本説明においては、二次局のウィンドウサイズが２であることから、Ｎｓが０、１のＩフレームを連続送信している。
一方、二次局のＩｒＬＡＰ層（以下、ＬＡＰ（Ｓ））では、前述のＩフレームを連続受信すると、Ｎｓフィールドを監視しながら、フレームの抜けを検出するとともに、Ｉフレーム内の上位層データを上位層である二次局のＩｒＬＭＰ層（以下、ＬＭＰ（Ｓ））に渡す。また、Ｉフレームの連続受信成功通知を行う必要があるが、本説明においては、この段階では、Ｎｒフィールドを２にした連続受信成功通知フレームは、送信しない。
前述のフレーム受信通知を受けたＬＭＰ（Ｓ）は、ＬＳＡＰヘッダを除去した後、上位層データを上位層である二次局のＴｉｎｙＴＰ層（以下、ＴＴＰ（Ｓ））に渡す。
これを受けたＴＴＰ（Ｓ）は、受信フレーム内の上位層データを結合する。本説明においては、ＯＢＥＸ層に渡すデータの単位をｄａｔａＰ０、ｄａｔａＰ１、ｄａｔａＰ２、ｄａｔａＰ３を結合したデータサイズ相当としているため、ｄａｔａＰ０、ｄａｔａＰ１を結合し終わった時点では、ＯＢＥＸ層に対してデータ受信の通知は行っていない。また、ＴＴＰ（Ｓ）の受信可能クレジット数２分のデータ処理（ｄａｔａＰ０、ｄａｔａＰ１の結合処理）が完了したため、対向局に対して、クレジットを２として、自機器が、２つのフレームを受信可能であることを通知するために下位層にＴｉｎｙＴＰフレームを渡す。
これを受けたＬＭＰ（Ｓ）は、ＬＳＡＰ情報をＬＭＰヘッダとして付加し、ＬＡＰ（Ｓ）に渡す。
これを受けたＬＡＰ（Ｓ）は、Ｉフレームを用いて、データ転送を行う。このとき、前述で送信を保留していたＬＡＰのＩフレーム連続受信成功通知のためのＮｒフィールドに、次に送信して欲しいＮｓフィールドの値２を設定して送信する。また、Ｎｓフィールドには、二次局の送信フレームの通し番号を合わせて設定する。
これを受けたＬＡＰ（Ｐ）は、Ｎｒフィールドを監視することにより、前回のＩフレームの連続送信が正常に終了しているかどうかを確認する。本説明の場合、Ｎｒフィールドが２であるため、前回送信したＮｓフィールドが０および１のＩフレームを二次局が正常に受信できたことを認識する。また、受信Ｉフレーム内に上位層データが入っているため、ＬＭＰ（Ｐ）に上位層データを渡す。
これを受けたＬＭＰ（Ｐ）は、ＬＳＡＰヘッダを除去した後、上位層データをＴＴＰ（Ｐ）に渡す。
これを受けたＴＴＰ（Ｐ）は、受信フレーム内の対向局のクレジットが２であることから、対向局のＴＴＰ（Ｓ）が２つのフレームを受信可能であると認識し、上位層からの送信データの内、残りの分割データｄａｔａＰ２、ｄａｔａＰ３にそれぞれ一次局のクレジット情報を付加し、ＬＭＰ（Ｐ）に渡す。
これを受けたＬＭＰ（Ｐ）は、ＬＳＡＰヘッダを付加し、ＬＡＰ（Ｐ）に渡す。
これを受けたＬＡＰ（Ｐ）は、２つのＩフレームを用いて、上位層からの２つの送信データをそれぞれ送信する。このとき、前述の二次局からのＩフレームの受信が正常に行えたことを通知するためにＮｒフィールドに次の二次局のＮｓフィールドの値を設定するとともに、Ｎｓフィールドには、前回一次局が最後に送信したＩフレームのＮｓフィールドの値に１だけ足した値を設定する。
これを受けたＬＡＰ（Ｓ）は、Ｎｒフィールドを監視することにより、前回二次局が送信したＩフレームを一次局が正常に受信したことを認識するとともに、受信Ｉフレーム内の上位層データをＬＭＰ（Ｓ）に渡す。
これを受けたＬＭＰ（Ｓ）は、ＬＳＡＰヘッダを除去し、ＴＴＰ（Ｓ）に渡す。
これを受けたＴＴＰ（Ｓ）は、受信フレーム内の上位層データを結合する。前述の結合された上位層データ（ｄａｔａＰ０、ｄａｔａＰ１）に今回受信したｄａｔａＰ２、ｄａｔａＰ３を結合する。この時点で、上位層ＯＢＥＸ層に渡すデータサイズに達しているため、上位層である二次局のＯＢＥＸ層（以下、ＯＢＥＸ（Ｓ））に上位層データを渡す。また、この時点で、受信データの処理が完了しているため、クレジットを２として、下位層に渡してもよいが、本発明においては、この送信処理は保留する。
これを受けたＯＢＥＸ（Ｓ）は、下位層からのデータを解析し、Ｐｕｔコマンドであることを確認すると、一次局のＯＢＥＸに対して応答を返すために、応答フレームを生成し、ＴＴＰ（Ｓ）に渡す。本説明の場合、受信したコマンドが最終でないＰｕｔコマンドであるため、ＣＯＮＴＩＮＵＥコマンドを生成することとなる。
これを受けたＴＴＰ（Ｓ）は、前述のクレジットと上位層からのデータを合わせてＴｉｎｙＴＰフレームを生成し、ＬＭＰ（Ｓ）に渡す。
これを受けたＬＭＰ（Ｓ）は、ＬＳＡＰヘッダを付加し、ＬＡＰ（Ｓ）に渡す。
これを受けたＬＡＰ（Ｓ）は、Ｉフレームを用いて、データ転送を行う。また、このときＮｒフィールドに前回のＩフレーム受信成功の旨を設定し、またＮｓフィールドには通し番号を設定する。
これを受けたＬＡＰ（Ｐ）は、Ｎｒフィールドの監視により、前回送信した２つのＩフレームが二次局で正常に受信できたことを認識するとともに、受信Ｉフレーム内の上位層データをＬＭＰ（Ｐ）に渡す。
これを受けたＬＭＰ（Ｐ）は、ＬＳＡＰヘッダを除去し、上位層データをＴＴＰ（Ｐ）に渡す。
これを受けたＴＴＰ（Ｐ）は、受信フレーム内のデータをＯＢＥＸ（Ｐ）に渡す。
これを受けたＯＢＥＸ（Ｐ）は、受信フレームを解析する。本説明においては、ＣＯＮＴＩＮＵＥレスポンスを受信しているため、前回のＰｕｔコマンドによるデータ転送（ｄａｔａＰ０からｄａｔａＰ３）が正常に二次局に転送できたことを認識する。
以上により、最終でないＰｕｔコマンドの場合の通信が終了する。
最終のＰｕｔコマンドの通信の場合は、前述のＯＢＥＸ（Ｓ）から返信されるレスポンスがＳＵＣＣＥＳＳレスポンスに変わるだけで、その他の通信の流れは基本的に同じである。
上記のとおり、本説明の条件においては、通信路を流れるフレーム数は１２個となる。
２．ＩｒＳｉｍｐｌｅの双方向通信におけるデータ転送の流れ
図２６に、本発明の適用例であるＩｒＳｉｍｐｌｅの双方向通信でのデータ転送の流れを示す。なお、以下の説明においては、一次局と二次局は、それぞれＩｒＬＡＰ層、ＩｒＬＭＰ層、ＩｒＳＭＰ層（Ｉｎｆｒａｒｅｄ Ｓｅｑｕｅｎｃｅ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）、ＯＢＥＸ層をサポートしているものとする。
（１）ＩｒＬＡＰ層においては、ＵＩフレームを用いて、データ転送を行う。前述のとおり、ＵＩフレームを用いると、ウィンドウサイズの制限がなくなるため、Ｉフレームを用いた場合に一度に連続送信可能なフレーム数７よりも多くのフレームを連続送信することが可能となる。このことにより、フレーム受信後、送信を開始するまでに待たなければならない時間（Ｍｉｎ Ｔｕｒｎ Ａｒｏｕｎｄ Ｔｉｍｅ）の累積によるデータ転送効率の削減が期待できる。
図２２（ｂ）に、ＬＡＰ層のＵＩフレームのフレームフォーマットを示す。
図２２（ｂ）に示すように、ＵＩフレームには、Ｉフレーム（図２２（ａ）に）に存在していたＮｒ、Ｎｓフィールドが存在していない。これは、フレームに通し番号が振られていないことを示しており、ＬＡＰ層レベルでのフレーム抜けの検出が行えず、また、再送要求すべきフレームの通し番号の設定を行うこともできないことを示している。すなわち、ＵＩフレームを用いた転送の場合は、ＬＡＰ層レベルでの上位層データの信頼性は保証していない。
（２）ＩｒＬＭＰ層は、アプリケーションごとの論理的なチャネル（ＬＳＡＰ：Ｌｉｎｋ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）を上位層に提供する層である。
図２３に示したように、フレームを送信する側のＩｒＬＭＰ層では、上位層（ＴｉｎｙＴＰ層）からのデータとＩｒＬＭＰフレームに配置するとともに、送信先の論理的なチャネル（ＤＬＳＡＰ：Ｄｅｓｔｉｎａｔｉｏｎ Ｌｉｎｋ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）と送信元の論理的なチャネル（ＳＬＳＡＰ：Ｓｏｕｒｃｅ Ｌｉｎｋ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）をＩｒＬＭＰヘッダとして、配置する。
一方、フレームを受信する側のＩｒＬＭＰ層では、下位層からの受信フレームのＤＬＳＡＰフィールドを監視することにより、どの上位層アプリケーションのデータであるかを判別し、対応する上位層アプリケーションに対して、受信フレーム内データを渡す。
（３）ＩｒＳＭＰ層は、上位層のデータを分割・結合する。また、前述のとおり、ＩｒＬＡＰ層にてＵＩフレームを用いて、データ転送を行い、ＩｒＬＡＰ層での再送制御を行わないため、このＩｒＳＭＰ層にて再送制御を行う。
具体的には、一次局のＩｒＳＭＰ層（以下、ＳＭＰ（Ｐ））では、上位層データを下位層のＵＩフレームの最大データ長以下に分割した後、分割データを複数のフレーム内に配置して、ＬＭＰ（Ｐ）に渡す。その際、通し番号、一括送信終了フラグ、データ終了フラグをＳＭＰヘッダとして付加する。
図２７（ａ）に、ＩｒＳｉｍｐｌｅの双方向通信の場合のＳＭＰフレームのフレームフォーマットを示す。
通し番号（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）は、フレームごとに１ずつ増えていく。通信中にエラーが発生した場合には、二次局から送られてくる再送要求通し番号に番号を振り直して、再びＳＭＰフレームを送信する。
一括送信終了フラグ（図中のＢＬ：Ｂｌｏｃｋ Ｌａｓｔ）は、接続時に二次局から通知された受信バッファサイズを元に、二次局の受信バッファのサイズを超えない範囲で、ＳＭＰフレームを連続送信する際に、最終のフレーム送信時に、一括送信終了を示す値（図中ではＢＬ＝１）に設定する。二次局は、受信フレームの通し番号を監視し、フレームの抜けを検出する。二次局がＢＬ＝１のフレームを受信するとそれまでに受信したフレームにフレーム抜けやエラーが検出されなければ、エラー無しを示すフラグ（ＲＳ：Ｒｅｃｅｉｖｅ Ｓｔａｔｕｓ）をエラー無しの意味（図中ではＲＳ＝１）として、下位層に渡す。また、エラーが発生している場合は、通し番号に再送して欲しい通し番号を設定する。
データ終了フラグ（ＤＬ：Ｄａｔａ Ｌａｓｔ）は、上位層データの最終データがフレームに含まれているかどうかを示すフラグである。含まれている場合は、その旨を示す値（図中ではＤＬ＝１）に設定する。また、二次局のＩｒＳＭＰ層（以下、ＳＭＰ（Ｓ））は、受信した上位層データを結合し、二次局の上位層であるＯＢＥＸ層（以下、ＯＢＥＸ（Ｓ））との間で予め定められたデータのサイズまで、受信データが結合されると、結合データを上位層に渡す。
（４）ＯＢＥＸ層は、オブジェクト交換用のプロトコルである。ファイルの送信を行う場合は、Ｐｕｔコマンドを用いて送信を行う。前述と同様、Ｐｕｔコマンドにより、ファイル転送を行う。
また、ファイルの受信を行う側では、本発明の方式においては、ＯＢＥＸ（Ｓ）は、Ｐｕｔコマンド受信を受信した際に、最終のＰｕｔコマンドのみＳＵＣＣＥＳＳレスポンスを返し、最終でないＰｕｔコマンド受信時には、ＣＯＮＴＩＮＵＥレスポンスを返信しない。また、一次局のＯＢＥＸ層（以下、ＯＢＥＸ（Ｐ））においては、最終でないＰｕｔコマンド送信時には、二次局からのＣＯＮＴＩＮＵＥレスポンスを待たず、次のＰｕｔコマンドの送信を行い、最終のＰｕｔコマンド送信時のみ二次局からのＳＵＣＣＥＳＳレスポンウを待ち、二次局がＰｕｔコマンドによるデータ送信を正常受信できたかどうかを判別する。上述の通り、ＣＯＮＴＩＮＵＥレスポンスのやり取りを省略することで、ＬＡＰ層でのフレーム数削減が期待できる。
つづいて、本発明の方式による双方向通信でのデータ転送の流れを説明する。
一次局のＯＢＥＸでファイル送信要求が発生すると、ＯＢＥＸ（Ｐ）はＴＴＰ（Ｐ）に対して、Ｐｕｔコマンドを送信データとして渡す。本説明においては、最終でないＰｕｔコマンドが、ｄａｔａＰ０、ｄａｔａＰ１、ｄａｔａＰ２、ｄａｔａＰ３で構成され、また最終のＰｕｔコマンドがｄａｔａＰ４、ｄａｔａＰ５、ｄａｔａＰ６、ｄａｔａＰ７で構成されているものとする。ＯＢＥＸ（Ｐ）は、最終でないＰｕｔコマンドに対するＣＯＮＴＩＮＵＥレスポンス受信を待たないため、ＳＭＰ（Ｐ）の送信バッファに空きがある場合、連続してＰｕｔコマンドをＳＭＰ（Ｐ）に渡す。
これを受けたＳＭＰ（Ｐ）は、下位層であるＬＡＰ層の最大データ長以下で送信データを分割する。本説明においては、ＳＭＰ（Ｐ）において、ｄａｔａＰ０、ｄａｔａＰ１、ｄａｔａＰ２、ｄａｔａＰ３に分割されるものとする。また、ＳＭＰ（Ｐ）において、再送制御を行うために、Ｓｅｑ，ＢＬが設定される。本説明においては、接続時に二次局のＳＭＰ（Ｓ）から得られる受信バッファのサイズが、ｄａｔａＰ０からｄａｔａＰ５までの和であることをＳＭＰ（Ｐ）が認識しているものとし、ｄａｔａＰ５までのフレームを連続送信し、ｄａｔａＰ５のフレーム送信時にＢＬを１としている。本説明においては、受信バッファのサイズがフレーム６個分となっているが、これよりも大きな値、例えばフレーム１２８個分（ＬＡＰ層の最大データ長を２ＫＢとして、２５６ＫＢ）としてもよい。この場合は、ｄａｔａＰ７のフレーム送信時のみ、ＢＬ＝１（ＤＬ＝１）とすることとなる。ＳＭＰ（Ｐ）により、ＳＭＰヘッダ（ＤＬ，ＢＬ，ＳＥＱ）が付加されたＳＭＰフレームは、ＬＭＰ（Ｐ）に渡される。
これを受けたＬＭＰ（Ｐ）では、ＬＳＡＰヘッダが付加されて、ＬＡＰ（Ｐ）に渡される。
これを受けたＬＡＰ（Ｐ）では、ＵＩフレームでのデータ転送が行われる。
これを受けたＬＡＰ（Ｓ）では、ＵＩフレーム内の上位層データをＬＭＰ（Ｓ）に渡す。
これを受けたＬＭＰ（Ｓ）では、ＬＳＡＰヘッダを除去して、上位層データをＳＭＰ（Ｓ）に渡す。
これを受けたＳＭＰ（Ｓ）では、通し番号を監視することにより、ＳＭＰフレームの抜けを検出するとともに、フレーム抜けのない上位層データに関しては、結合を行う。本説明においては、ＯＢＥＸ（Ｓ）との間で予め定められた上位層のデータサイズの単位が、ｄａｔａＰ０からｄａｔａＰ３を結合したデータのサイズであったため、ｄａｔａＰ３を結合完了した時点で、上位層に対して結合データを渡す。ＤＬ＝０、ＢＬ＝１のフレームを受信した時点で、それまでの受信フレームにフレームぬけやエラーが検出されていないため、エラー無しフラグＲＳを１にして、下位層に渡す。
前述のＳＭＰ（Ｓ）からの受信データを受けたＯＢＥＸ（Ｓ）では、受信データの解析を行う。本説明においては、最終でないＰｕｔコマンドであるため、ＣＯＮＴＩＮＵＥレスポンスを一次局に返信しない。
また、前述のＲＳ＝１のＳＭＰフレームを受けたＬＭＰ（Ｓ）は、ＬＳＡＰヘッダを付加して、ＬＡＰ（Ｓ）に渡す。
これを受けたＬＡＰ（Ｓ）は、ＵＩフレームでのデータ転送を行う。
これを受けたＬＡＰ（Ｐ）は、ＵＩフレーム内の上位層データをＬＭＰ（Ｐ）に渡す。
これを受けたＬＭＰ（Ｐ）は、ＬＳＡＰヘッダを除去し、ＳＭＰ（Ｐ）に上位層データを渡す。
これを受けたＳＭＰ（Ｐ）は、受信フレーム内のＲＳフィールドが１であることより、前回の一括送信が正常に行えたことを認識し、上位層の分割データの内、残りの分割データｄａｔａＰ６、ｄａｔａＰ７を送信する。また、ｄａｔａＰ７を送信時には、ＢＬ＝１とするとともに、ＤＬ＝１として、このフレームが上位層データの最終フレームであることを通知する。
これを受けたＬＭＰ（Ｐ）は、ＬＳＡＰヘッダを付加して、ＬＡＰ（Ｐ）に渡す。
これを受けたＬＡＰ（Ｐ）は、ＵＩフレームでのデータ転送を行う。
これを受けたＬＡＰ（Ｓ）は、ＵＩフレーム内の上位層データをＬＭＰ（Ｓ）に渡す。
これを受けたＬＭＰ（Ｓ）は、ＬＳＡＰヘッダを除去し、ＳＭＰ（Ｓ）に上位層データを渡す。
これを受けたＳＭＰ（Ｓ）は、受信フレーム内の通し番号を監視することにより、フレームの抜けを検出するとともに、エラーのないフレームについては、フレーム内の上位層データを結合し、結合データを上位層に渡す。また、本説明においては、ｄａｔａＰ７を含むフレームのＢＬが１であると同時にＤＬが１であるため、ＳＭＰ層での受信結果を通知するためのフレーム（ＲＳを含むフレーム）をこの時点では、送信しない。
これを受けたＯＢＥＸ（Ｓ）は、受信データ内を解析するとともに、受信データが最終のＰｕｔコマンドであると認識した場合は、それまでの受信コマンドが正常であった場合は、ＳＵＣＣＥＳＳレスポンスを生成し、ＳＭＰ（Ｓ）に渡す。
これを受けたＳＭＰ（Ｓ）は、前述のＳＭＰ層での受信結果（ＲＳ）を１にし、上位層データと合わせて、ＬＭＰ（Ｓ）に渡す。
これを受けたＬＭＰ（Ｓ）は、ＬＳＡＰヘッダを付加し、ＬＡＰ（Ｓ）に渡す。
これを受けたＬＡＰ（Ｓ）は、ＵＩフレームでのデータ転送を行う。
これを受けたＬＡＰ（Ｐ）は、ＵＩフレーム内の上位層データをＬＭＰ（Ｐ）に渡す。
これを受けたＬＭＰ（Ｐ）は、ＬＳＡＰヘッダを除去し、上位層データをＳＭＰ（Ｐ）に渡す。
これを受けたＳＭＰ（Ｐ）は、受信フレーム内のＲＳフィールドが１であることで、前回の一括送信が正常に行えたことを認識するとともに、上位層データをＯＢＥＸ（Ｐ）に渡す。
これを受けたＯＢＥＸ（Ｐ）は、受信データを解析し、受信データがＳＵＣＣＥＳＳレスポンスであることを認識すると、それまでの最終でないＰｕｔコマンドおよび最終のＰｕｔコマンドでのデータ転送が全て正常に終了したことを認識することとなる。
上記により、ＩｒＬＡＰ層でＵＩフレームを用いた場合でも、ＳＭＰ層で再送制御を行うことにより、信頼性が確保された通信を行うことが可能となる。また、ＵＩフレームを用いることにより、Ｉフレームを用いた場合のウィンドウサイズの制限がなくなり、二次局の受信バッファサイズに最適化された通信を行うことが可能となる。
上記のとおり、本説明の条件においては、通信路を流れるフレーム数は、１０個となり、従来のＩｒＤＡについて前述したＩフレームを用いた通信と比べて、少ないフレーム数での通信が可能となる。
また、本説明においては、ＳＭＰ層での一括送信可能なフレーム数が６として説明を行っているが、この値は、再送のための一次局の送信バッファおよび二次局の受信バッファのサイズが許す限り、いくつにでも設定可能であり、通信系の持っている最大の能力での通信を実現することが可能となる。これに対して、Ｉフレームを用いた通信においては、一次局、二次局がそれぞれ大量のバッファを保有していたとしても、ウィンドウサイズの制限（ＬＡＰにおける７）により、通信効率の向上を達成するのは困難である。
３．ＩｒＳｉｍｐｌｅの片方向通信におけるデータ転送の流れ
図２８に、本発明の適用例であるＩｒＳｉｍｐｌｅの片方向通信でのデータ転送の流れを示す。なお、以下の説明においては、一次局と二次局は、それぞれＩｒＬＡＰ層、ＩｒＬＭＰ層、ＩｒＳＭＰ層（Ｉｎｆｒａｒｅｄ Ｓｅｑｕｅｎｃｅ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）、ＯＢＥＸ層をサポートしているものとする。
（１）ＩｒＬＡＰ層においては、ＵＩフレーム（図２２（ｂ））を用いて、データ転送を行う。前述のとおり、ＵＩフレームを用いると、ウィンドウサイズの制限がなくなるため、Ｉフレームを用いた場合に一度に連続送信可能なフレーム数７よりも多くのフレームを連続送信することが可能となる。このことにより、フレーム受信後、送信を開始するまでに待たなければならない時間（Ｍｉｎ Ｔｕｒｎ Ａｒｏｕｎｄ Ｔｉｍｅ）の累積によるデータ転送効率の削減が期待できる。
図２２（ｂ）に示すように、ＵＩフレームには、Ｉフレームに存在していたＮｒ、Ｎｓフィールドが存在していない。これは、フレームに通し番号が振られていないことを示しており、ＬＡＰ層レベルでのフレーム抜けの検出が行えず、また、再送要求すべきフレームの通し番号の設定を行うこともできないことを示している。すなわち、ＵＩフレームを用いた転送の場合は、ＬＡＰ層レベルでの上位層データの信頼性は保証していない。
（２）ＩｒＬＭＰ層は、アプリケーションごとの論理的なチャネル（ＬＳＡＰ：Ｌｉｎｋ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）を上位層に提供する層である。
フレームを送信する側のＩｒＬＭＰ層では、上位層（ＴｉｎｙＴＰ層）からのデータとＩｒＬＭＰフレームに配置するとともに、送信先の論理的なチャネル（ＤＬＳＡＰ：Ｄｅｓｔｉｎａｔｉｏｎ Ｌｉｎｋ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）と送信元の論理的なチャネル（ＳＬＳＡＰ：Ｓｏｕｒｃｅ Ｌｉｎｋ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）をＩｒＬＭＰヘッダとして、配置する。
一方、フレームを受信する側のＩｒＬＭＰ層では、下位層からの受信フレームのＤＬＳＡＰフィールドを監視することにより、どの上位層アプリケーションのデータであるかを判別し、対応する上位層アプリケーションに対して、受信フレーム内データを渡す。
（３）ＩｒＳＭＰ層は、上位層のデータを分割・結合する。また、前述のとおり、ＩｒＬＡＰ層にてＵＩフレームを用いて、データ転送を行い、ＩｒＬＡＰ層でフレームに通し番号が振られないいため、このＩｒＳＭＰ層にてフレームに通し番号が振られる。
具体的には、一次局のＩｒＳＭＰ層（以下、ＳＭＰ（Ｐ））では、上位層データを下位層のＵＩフレームの最大データ長以下に分割した後、分割データを複数のフレーム内に配置して、ＬＭＰ（Ｐ）に渡す。その際、通し番号、データ終了フラグをＳＭＰヘッダとして付加する。
図２７（ｂ）に、ＩｒＳｉｍｐｌｅの片方向通信の場合のＳＭＰフレームのフレームフォーマットを示す。
通し番号（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）は、フレームごとに１ずつ増えていく。二次局は、受信フレームの通し番号を監視し、フレームの抜けを検出する。フレーム抜けやエラーが検出されれば、検出された時点で、ＯＢＥＸ（Ｓ）に対して、その旨を通知する。
データ終了フラグ（ＤＬ：Ｄａｔａ Ｌａｓｔ）は、上位層データの最終データがフレームに含まれているかどうかを示すフラグである。含まれている場合は、その旨を示す値（図中ではＤＬ＝１）に設定する。また、二次局のＩｒＳＭＰ層（以下、ＳＭＰ（Ｓ））は、受信した上位層データを結合し、二次局の上位層であるＯＢＥＸ層（以下、ＯＢＥＸ（Ｓ））との間で予め定められたデータのサイズまで、受信データが結合されると、結合データを上位層に渡す。
（４）ＯＢＥＸ層は、オブジェクト交換用のプロトコルである。ファイルの送信を行う場合は、Ｐｕｔコマンドを用いて送信を行う。前述と同様、Ｐｕｔコマンドにより、ファイル転送を行う。
また、ファイルの受信を行う側は、本発明の方式においては、ＯＢＥＸ（Ｓ）は、Ｐｕｔコマンド受信を受信した際に、Ｐｕｔコマンドに対するレスポンス（ＣＯＮＴＩＮＵＥレスポンスおよびＳＵＣＣＥＳＳレスポンス）を返信しない。
また、一次局のＯＢＥＸ層（以下、ＯＢＥＸ（Ｐ））においては、Ｐｕｔコマンド送信時には、二次局からのレスポンスを必要としない。
つづいて、本発明の方式による片方向通信でのデータ転送の流れを説明する。
一次局のＯＢＥＸでファイル送信要求が発生すると、ＯＢＥＸ（Ｐ）はＴＴＰ（Ｐ）に対して、Ｐｕｔコマンドを送信データとして渡す。本説明においては、最終でないＰｕｔコマンドが、ｄａｔａＰ０、ｄａｔａＰ１、ｄａｔａＰ２、ｄａｔａＰ３で構成され、また最終のＰｕｔコマンドがｄａｔａＰ４、ｄａｔａＰ５、ｄａｔａＰ６、ｄａｔａＰ７で構成されているものとする。ＯＢＥＸ（Ｐ）は、Ｐｕｔコマンドに対するレスポンス受信を待たないため、ＳＭＰ（Ｐ）の送信バッファに空きがある場合、連続してＰｕｔコマンドをＳＭＰ（Ｐ）に渡す。ＯＢＥＸ（Ｐ）は、最終のＰｕｔコマンドをＳＭＰ（Ｐ）に渡した時点で、Ｐｕｔコマンドによるデータ転送を終了する。
これを受けたＳＭＰ（Ｐ）は、下位層であるＬＡＰ層の最大データ長以下で送信データを分割する。本説明においては、ＳＭＰ（Ｐ）において、ｄａｔａＰ０、ｄａｔａＰ１、ｄａｔａＰ２、ｄａｔａＰ３に分割されるものとする。また、ＳＭＰ（Ｐ）において、二次局でのフレーム抜け検出のために、通し番号（Ｓｅｑ）が設定される。また、上位層の最終データ送信時には、ＤＬを１として送信する。ＳＭＰ（Ｐ）により、ＳＭＰヘッダ（ＤＬ，ＳＥＱ）が付加されたＳＭＰフレームは、ＬＭＰ（Ｐ）に渡される。
これを受けたＬＭＰ（Ｐ）では、ＬＳＡＰヘッダが付加されて、ＬＡＰ（Ｐ）に渡される。
これを受けたＬＡＰ（Ｐ）では、ＵＩフレームでのデータ転送が行われる。
これを受けたＬＡＰ（Ｓ）では、ＵＩフレーム内の上位層データをＬＭＰ（Ｓ）に渡す。
これを受けたＬＭＰ（Ｓ）では、ＬＳＡＰヘッダを除去して、上位層データをＳＭＰ（Ｓ）に渡す。
これを受けたＳＭＰ（Ｓ）では、通し番号を監視することにより、ＳＭＰフレームの抜けを検出するとともに、フレーム抜けのない上位層データに関しては、結合を行う。本説明においては、ＯＢＥＸ（Ｓ）との間で予め定められた上位層のデータサイズの単位が、ｄａｔａＰ０からｄａｔａＰ３を結合したデータのサイズであったため、ｄａｔａＰ３を結合完了した時点で、上位層に対して結合データを渡す。また、ＤＬ＝１のフレームを受信した時点で、一次局ＯＢＥＸの送信データを全て受信したことを認識し、ｄａｔａＰ４からｄａｔａＰ７を受信データとして上位層に通知する。
これを受けたＯＢＥＸ（Ｓ）では、受信データの解析を行う。本説明においては、一次局がＰｕｔコマンドに対するレスポンスを必要としないため、ＣＯＮＴＩＮＵＥレスポンスおよびＳＵＣＣＥＳＳレスポンスを一次局に返信しない。最終のＰｕｔコマンドを受信した時点で、ＯＢＥＸでのＰｕｔコマンドによるデータ転送が完了することとなる。
上述の通り、本発明の通信方式における片方向通信においては、再送制御は行えないものの、ＯＢＥＸ層にて、Ｐｕｔコマンドに対するレスポンスを必要としないことを予め一次局と二次局の間で定めておけば、問題なく通信を行うことが可能となる。また、ＩｒＳＭＰ層において、通し番号を付加することにより、通し番号がないＵＩフレームを用いた場合でも、フレームの抜け検出が可能となり、ユーザに受信エラーの通知などを適切に行うことが可能となる。
（データ終了フラグ受信時の受信機の処理）
データ終了フラグ受信時の受信機の処理について説明する。
図２９は、上位層としてＯＢＥＸが存在し、ＯＢＥＸのＰｕｔコマンドによるデータ転送を示すシークエンス図である。
図２９では、送信機がＯＢＥＸデータの最終が含まれていることを示すＰｕｔ Ｆｉｎａｌコマンドにより、ｄａｔａ０からｄａｔａ３を一括で送信している。そして、Ｐｕｔ Ｆｉｎａｌコマンドの最終データであるｄａｔａ３を含むフレーム送信時に、一括送信終了フラグを１にするとともに、データ終了フラグも１としている。
一方、受信機は、一括送信終了フラグおよびデータ終了フラグが１のフレームを受信したとき、上位層に受信データを渡すとともに、それまでの受信データにエラーがなかったため、エラー無しフラグをエラー無しの意味として、返信している。その後、受信機では下位層が、上位層のＯＢＥＸから受信成功の意味のＳＵＣＣＥＳＳレスポンスの通知を受けるが、通知受信時点では、受信機に送信権がないため、送信を保留している。
次に、送信機は、エラー無しフラグがエラー無しを示すフレームを受信し、受信機がエラーなく通信できたことを認識するが、対向局からのＳＵＣＣＥＳＳレスポンスを受信しないといけないため、再び受信機に送信権を渡すために、フレームを送信する。図２９では、この時点で、送信機から送信すべきデータが存在しないため、一括送信終了フラグを１として、ユーザデータ領域には何もデータを配置せず（ｄａｔａ＝ＮＵＬＬ）、フレームを送信している。
次に、受信機がこれを受信すると、送信を保留していたＳＵＣＣＥＳＳレスポンスを送信する。
その後、送信機がこれを受信して、上位層のＯＢＥＸに受信したデータ（ＳＵＣＣＥＳＳレスポンス）を渡すことで、上位層のＯＢＥＸレベルでの通信が完了する。
ここで、上記と同じ条件において、エラー無しフラグを含むフレームとＳＵＣＣＥＳＳを含むフレームとを１つにまとめて送信する通信例について説明する。
図３０は、受信機がエラー無しフラグを含むフレームとＳＵＣＣＥＳＳを含むフレームとを１つにまとめて送信する通信例を示すシークエンス図である。
図３０に示すように、受信機においては、一括送信終了フラグおよびデータ終了フラグが１のフレームを受信したとき、下位層が上位層に受信データを渡した後、直ちにエラー無しフラグをエラー無しとして、フレームを生成、送信せずに、下位層は上位層からのＳＵＣＣＥＳＳレスポンスを待って、前述のエラー無しフラグとＳＵＣＣＥＳＳレスポンスをまとめて１つのフレーム内に配置し、送信している。
こうすることにより、図２９に示したように、受信機がエラー無しフラグのみを含むフレームを送信した後に、送信権移動のためのフレームを送信機が送信する必要がない。また、受信機では、上位層がＳＵＣＣＥＳＳレスポンス送信要求を発生した後、下位層が直ちにＳＵＣＣＥＳＳフレームを送信できるため、通信の効率化を図ることが可能となる。また、送信権移動のためのフレームがなくなることとなり、送信権移動のためのフレームで発生したエラーの処理等を考える必要がなくなるため、処理が簡単化できる。
つづいて、本発明の通信システムにおける実施の各形態について図１から図８、図３１から図６７（ただし、図５２、図５３、図５８、図５９は従来技術の説明図である）に基づいて説明すると以下の通りである。すなわち、本発明は、画像データや文書データなどのような、所定の容量を一塊として一定の情報を表し、かつ、転送すべき転送データを送受信するような一次局および二次局を有する通信システムに適用できる。ここで、所定のデータ容量は、転送データによって可変である。
以下の実施の各形態では、赤外線により転送データを転送するＩｒＤＡに準拠した転送方式（伝送方式）を例にとり本発明を説明する。
〔実施の第一形態〕
本発明の実施の第一形態に係る転送データの転送システム（通信システム）について、図１および図２に基づいて説明すると以下の通りである。なお、他の実施の形態において定義した用語（部材及び機能を含む）については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。
図１は、本実施の形態における一次局の構成を示すブロック図である。図１に示すように、一次局（送信装置）１は、ＣＰＵ１１と、メモリ１２と、コントローラ１３と、送信器１４と、受信器１５とを備えている。
ＣＰＵ１１は、図示しない操作部に入力された利用者の指示に応じて、所定の演算処理を行うものである。所定の演算処理としては、転送データの転送処理がある。ＣＰＵ１１は、操作部から転送データの転送指示を受けると、転送すべき転送データをメモリ１２に格納するとともに、コントローラ１３に対して転送要求を行う。また、ＣＰＵ１１は、コントローラ１３から転送データの送信終了を表す送信終了通知を受けると、転送処理を完了する。
メモリ１２は、転送すべき転送データを一時記憶するものであり、ＣＰＵ１１により転送データが書き込まれる。コントローラ１３は、ＣＰＵ１１からの転送要求に応じて、転送データの転送を制御するものであり、また、受信フレームの解析結果をＣＰＵ１１に通知するものである。コントローラ１３は、制御部１３１、送信フレーム生成部１３２、および受信フレーム解析部１３３を備えている。
また、送信フレーム生成部１３２は、データ読み出し部１３２１、フレーム通し番号付加部（通し番号付加手段）１３２２、送信権委譲フラグ付加部（送信権委譲フラグ付与手段）１３２３、フレーム構築部１３２４および誤り検出または訂正符号付加部１３２５を備えている。
また、受信フレーム解析部１３３は、再送要求判定部１３３１およびフレーム通し番号抽出部１３３２を備えている。
制御部１３１は、ＣＰＵ１１から転送要求を受けると、データ読み出し部１３２１に対して、データの読み出し要求を行うとともに、フレーム通し番号付加部１３２２に通し番号の通知、送信権委譲フラグ付加部１３２３に相手局に送信権を委譲するか否かの通知を行う。このとき、制御部１３１は、データ読み出し部１３２１が読み出すデータ長や、読み出す間隔を制御することにより、フレーム長やフレーム間隔を制御する。なお、制御部１３１は、後述する誤り検出または訂正符号付加部１３２５において検出できるデータ容量から求められる最大フレーム長以下となるようにフレーム長を制御する。
また、制御部１３１は、メモリ１２から読み出した転送データに対応する全てのフレームが送信器１４から送信されたことを検知して、転送データの送信が終了したことを表す送信終了通知をＣＰＵ１１に送る。
フレーム構築部１３２４は、データ読み出し部１３２１から受けたデータと、フレーム通し番号付加部１３２２から通知されたフレーム通し番号と、送信権委譲フラグ付加部１３２３から通知された送信権委譲行うかどうかの情報を基にフレームを生成する。なお、フレーム構築部１３２４が生成したフレームの転送速度は、制御部１３１により制御される。
また、フレーム構築部１３２４は、生成したフレームを順次誤り検出または訂正符号付加部１３２５に送る。このとき、フレーム構築部１３２４は、各フレーム間の時間間隔を、制御部１３１から受けたフレーム間隔になるようにする。
誤り検出または訂正符号付加部１３２５は、フレーム構築部１３２４で生成されたフレームに対して、誤り検出符号（または訂正符号）を付加して、後段の送信器１４に送る。誤り検出または訂正符号付加部１３２５は、誤り検出符号（または訂正符号）をフレーム内のＦＣＳに含ませる。
なお、誤り検出符号は、例えば、ＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）符号などの巡回符号であり、訂正符号は、例えば、パリティ検査符号、ハミング符号、リードソロモン符号などのＢＣＨ符号などである。なお、ＣＲＣ符号は例えば４バイトにて設定されており、該４バイトで検出できるようにデータ容量が限られる。
送信器１４は、赤外線通信路を介して、コントローラ１３から受信した複数のフレームを所定の時間間隔で外部に送信する。また、受信器１５は、二次局から受信したレスポンスフレームを順次、コントローラ１３内の受信フレーム解析部１３３に送る。
受信フレーム解析部１３３では、受信器１５から受信したフレームを、再送要求判定部１３３１およびフレーム通し番号抽出部１３３２においてそれぞれ、二次局が再送を要求しているか、およびどのフレームに誤りがあったかをフレーム番号を抽出することにより、制御部１３１へそれぞれ通知を行う。
ここで、制御部１３１は、ＣＰＵ１１に対して、送信したフレームに誤りがあったか否かと、誤りがあった場合には、どのフレームに誤りがあったかをそれぞれ通知する。
ＣＰＵ１１では、エラーが発生しなかった場合には、所定のフレーム数を再度二次局に対し送信できるように、二次局から一次局に送信権の委譲を行うよう指示を二次局に対して行っていく。このようにして、すべてのファイルデータを送信し終わるまで同様の手順を繰り返す。
また、エラーが発生した旨の通知を受けた場合には、上記と同様の手順で、送信権の委譲を行うまでに送信したフレーム数を再度送信する。また、ここで、ＣＰＵ１１は、エラーが発生したフレーム番号の通知を受けた場合には、その番号フレームから再送を行ってもよい。
次に、本実施の形態の二次局について、図２を参照しながら説明する。図２は、二次局の構成を示すブロック図である。図２に示されるように、本実施の形態の二次局（受信装置）は、ＣＰＵ２１と、メモリ２２と、コントローラ２３と、受信器２４と、送信器（送信手段）２５とを備えている。
受信器２４は、赤外線通信路を介して、一次局から送信されたフレームを受信し、受信したフレームをコントローラ２３に送る。コントローラ２３は、受信器２４から受けたフレームを基に、所定の制御処理を行うものである。コントローラ２３は、制御部２３１、フレーム処理部２３２、誤り検出または訂正回路２３３、エラーフレーム番号保持部２３４、レスポンスフレーム生成部（レスポンスフレーム生成手段）２３５および誤り検出または訂正符号付加部２３６を備えている。
フレーム処理部２３２は、受信器２４からフレームを受け、データフィールド、送信権委譲フラグ、フレーム通し番号およびＦＣＳ部分を抽出する。すなわち、フレーム処理部２３２は、受信器２４が受信したフレームのデータフィールドに含まれる情報と、送信権委譲フラグ、受信したフレームのフレーム通し番号、該情報に対する誤り検出符号（または訂正符号）とを抽出する。フレーム処理部２３２は、抽出した情報および誤り検出符号（または訂正符号）を、制御部２３１、誤り検出または訂正回路２３３およびエラーフレーム番号保持部２３４に送る。
例えば、フレーム処理部２３２は、フレームを受けると、該フレームに含まれる送信データ、送信権委譲フラグ、フレームの通し番号および誤り検出符号（または訂正符号）とを抽出し、抽出した送信データ、送信権委譲フラグ、フレームの通し番号および誤り検出符号（または訂正符号）を、制御部２３１、誤り検出または訂正回路２３３およびエラーフレーム番号保持部２３４に送る。誤り検出または訂正回路２３３は、受けた情報に対して誤り検出（または訂正）を行い、その結果を制御部２３１、エラーフレーム番号保持部２３４に送る。
制御部２３１は、誤り検出または訂正回路２３３から送られる結果に応じて、所定の処理を行う。すなわち、誤り検出または訂正回路２３３からの結果が受信データに誤り（エラー）がないことを示している場合、制御部２３１は、該受信データをメモリ２２に書き込み、ＣＰＵ２１に対して受信完了通知を行う。
一方、誤り検出または訂正回路２３３からの結果が受信データにエラーがあることを示している場合、制御部２３１は、該受信データを破棄して、エラーフレーム番号保持部２３４からエラーが発生したフレーム番号を読み出し、ＣＰＵ２１に対して受信エラーがある旨とエラーが発生したフレームの番号の通知を行う。また、制御部２３１は、フレーム処理部２３２で抽出された送信権委譲フラグを基に、送信権の委譲が行われたか否かの通知も合わせて行う。
メモリ２２は、受信器２４が受信データを記憶するものであり、制御部２３１により誤りがなかった受信データが書き込まれる。
ＣＰＵ２１は、制御部２３１からの通知に応じた処理を行う。すなわち、制御部２３１送信権の委譲が行われた旨の通知を受けた場合、それまで受信したすべてのフレームについて誤りがなかったときには、メモリ２２に格納されたすべての受信データを基に、所定の受信データ後処理を行い、制御部２３１へは、すべてのフレームを正常受信した旨のレスポンスフレームを一次局へ返信する旨の送信通知を行う。また、制御部２３１から送信権の委譲が行われた旨の通知を受けた場合、それまで受信したフレーム中にエラーが発生した旨の通知を受けていた場合には、制御部２３１へ、エラーが発生したので再送を要求する旨の送信通知を行う。また、ここで、合わせてエラーが発生したフレームのフレーム番号の通知も行う。
制御部２３１では、ＣＰＵ２１から送信要求を受けると、レスポンスフレーム生成部２３５に対して、レスポンスフレーム生成する旨の通知を行う。ここで、受信したフレームにエラーがあったか否かの情報と、エラーがあった場合についてはそのエラーフレームのフレーム番号の通知も合わせて行う。
レスポンスフレーム生成部２３５では、制御部２３１からの通知を基に、レスポンスフレームを生成し、誤り検出または訂正符号付加部２３６へフレームを送る。誤り検出または訂正符号付加部２３６では、レスポンスフレーム生成部２３５で生成されたフレームに誤り検出または訂正符号を付加して、送信器２５に送る。送信器２５は、赤外線通信路を介して、誤り検出または訂正符号付加部２３６から受信したフレームを外部に送信する。
図３に、ＵＩフレームおよびＵＩフレームに対するレスポンス（応答）フレームにフレームの通し番号、相手局に送信権を委譲するか否かを示すフラグ、およびそれまで受信したフレーム中にエラーまたはフレーム抜けがあったかどうかを示すフラグを付与した場合のフレーム構成を示す。ただし、ここで示すフレーム構成は一例であって、これに限るものではない。
ここでは、ＵＩフレームおよびＵＩフレームに対するレスポンスフレームに３バイトのパラメータを付与し、相手局に送信権を委譲するか否かを示すフラグ、二次局が使用する受信フレームにエラーがあったかどうかを示すフラグ、および残り２２ビットをフレームの通し番号で構成される。
以下、相手局に送信権を委譲するか否かを示すフラグをＢＬ、二次局が使用する受信フレームにエラーがあったかどうかを示すフラグをＲＳ、フレームの通し番号をＳとする。以下、このフレーム構成を用いて、一次局とに二次局との間にて、どのようにしてデータ転送が行われるかについて説明する。
一次局および二次局におけるデータ転送処理の手順について図４、図５の信号シーケンス図を参照しながら説明する。なお、図４は、双方向通信においてすべての受信データについてエラーが発生しなかった場合を示している。
まず、一次局において、操作部からの転送指示を受けたＣＰＵ１１は、転送すべき転送データをメモリ１２に格納し、コントローラ１３に対して、転送要求を出力する。ここでは、ｎフレーム単位で二次局に送信権の委譲が行われるとする。また図４、図５に示すＳ、ＢＬ、ＲＳはそれぞれ、フレームの通し番号、送信権の委譲を行うかどうかを示すフラグ、再送が必要であるかどうかを示すフラグである。
一次局では、まずｎ個のフレーム（通し番号がＳ＝０からＳ＝ｎ−１まで）を、赤外線通信路を介して二次局に送信する。ここではｎフレーム単位で送信権の委譲が行われるため、Ｓ＝ｎ−１のフレームについては、ＢＬ＝１にしてフレームの送信を行う。
二次局では、一次局が送信したフレームＳ＝０からＳ＝ｎ−１を順に受信する。その後受信したｎ個のフレーム中にエラーがなく受信完了した場合には、一次局に対しては、受信フレーム中にエラーがなく、再送が必要でないことを意味するよう、ＲＳ＝１にしてレスポンスフレームを送信する。
一次局では、二次局から送信したｎ個のフレームを正常に受信した旨のレスポンスフレームを受信すると、上記処理と同様の処理を行う。また二次局でも上記処理と同様の処理を行い、すべての受信フレームにエラーがなく受信完了通知を受けたＣＰＵは、該受信データを基に所定の受信データ後処理を行う。
次に、一次局および二次局におけるデータ転送処理の手順について図５の信号シーケンス図を参照しながら説明する。なお、図５は、双方向通信においてフレーム通信中にエラーが発生した場合を示している。
ここでは、ｎフレーム単位で二次局に送信権の委譲が行われるとする。また、図４と同様、Ｓ、ＢＬ、ＲＳはそれぞれ、フレームの通し番号、送信権の委譲を行うかどうかを示すフラグ、再送が必要であるかどうかを示すフラグである。
一次局では、まずｎ個のフレーム（通し番号がＳ＝０からＳ＝ｎ−１まで）を、赤外線通信路を介して二次局に送信する。ここではｎフレーム単位で送信権の委譲が行われるため、Ｓ＝ｎ−１のフレームについては、ＢＬ＝１にしてフレームの送信を行う。
ここで、二次局は、フレーム０についてエラーがなく、フレーム１についてエラーがあることを検出したとする。二次局では、一次局から送信権の委譲を示すフラグが委譲を意味するフレームを受信すると、一次局に対して、受信したフレームにエラーが発生したことを意味するフラグを有効にしてフレーム送信を行う。一次局では、二次局からのエラーが発生した旨のフレームを受信し、エラーが発生したことを検知し、エラーが発生したフレームの再送を行う。
〔実施の第二形態〕
本実施の形態では、上記実施の第一形態の変形例について説明する。なお、他の実施の形態において定義した用語（部材及び機能を含む）については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。
上記実施の第一形態では、一次局が二次局との間での送信権の委譲をｎフレーム毎に行う構成としたが、ここではＩｒＤＡ通信方式で行われる接続確立時に、接続確立時に、前記一次局である自局から送信される接続要求フレームと前記二次局である相手局から自局へ送信される接続応答フレームにそれぞれ、各局の一度に送受信可能なフレーム数を意味するフィールドを付与してフレーム交換を行い、各局において受信した相手局の一度に受信可能なフレーム数を参照して最適なフレーム数を算出し、該フレーム数に応じて送信権の委譲を行う場合について説明を行う。上記フレーム数については任意数に設定できるものである。
ＩｒＤＡ通信方式では、一次局が二次局に対して、データ転送状態の確立を求めて、まず、ＳＮＲＭフレームを送信する。これを受信した二次局は、通信不可能である場合にはＤＭフレームを返信し、通信可能である場合には承諾を意味するＵＡフレームを一次局に対し返信する。ＳＮＲＭフレーム、ＤＭフレーム、ＵＡフレームは、いずれもＵフレームの形態である。二次局がＵＡフレームを返信すると両局はデータ転送状態が確立され、データ転送が可能となる。
本実施の形態では、上記ＳＮＲＭフレームまたはＵＡフレームに、自局の再送可能データサイズを示すパラメータを付与して接続確立を行うようにしたものである。
上記の構成によれば、一次局と二次局との両局間でサポートされているフレーム数毎に必ず送信権の委譲が行われるので、各局に搭載されたメモリ容量に応じたフレーム交換を行うことができる。
図６は、本実施の形態に係る通信システムに使用される送受信回路の構成を示すブロック図である。図６に示すように、本実施の形態の送受信回路は、ＣＰＵ６１と、コントローラ６２と、送信器６３と、受信器６４とを備えている。
ＣＰＵ６１は、図示しない操作部に入力された利用者の相手局との接続指示を受けると、コントローラ６２に対して接続要求を行う。コントローラ６２は、ＣＰＵ６１からの接続要求に応じて、接続処理を制御するものである。コントローラ６２は、制御部６２１、送信フレーム生成部６２２および受信フレーム解析部６２３を備えている。
また、送信フレーム生成部６２２は、接続確立フレーム生成部６２２１および再送可能フレーム数付加部６２２２を備えている。ＣＰＵ６１から接続要求および、再送可能フレーム数の通知を受けた制御部６２１は、接続確立フレーム生成部６２２１に対して、接続要求フレームの生成を要求し、再送可能フレーム数付加部６２２２へＣＰＵ６１から通知を受けた再送可能フレーム数を通知する。
接続確立フレーム生成部６２２１では、接続要求フレームを生成し、再送可能フレーム数付加部６２２２は、生成された接続要求フレームに再送可能フレームを示すフィールドを付加し、送信器６３に送る。送信器６３では、送信フレーム生成部６２２から受けたフレームを赤外線通信路により送信を行う。
本送受信回路では、接続要求フレームを送信後、相手局である二次局からの接続応答（レスポンス）フレームを受信器６４が受信する。接続応答フレームを受信した受信器６４は、受信フレームをコントローラ６２内の受信フレーム解析部６２３に送る。
受信フレーム解析部６２３は、フレーム解析部６２３１および再送可能フレーム数検出部６２３２を備えている。フレーム解析部６２３１は、受信フレームの解析を行い、自局の接続要求に対する相手局の応答結果を制御部６２１へ通知する。
また、再送可能フレーム数検出部６２３２は、受信フレームから、再送可能フレーム数を示すフィールドの抽出を行い、制御部６２１へ通知する。
制御部６２１では、受信フレーム解析部６２３からの通知結果と、自局の再送可能フレーム数を比較することにより、両局での最大再送可能フレーム数を知ることができ、その結果をＣＰＵ６１に通知する。
ＣＰＵ６１では、その結果を受けて、データ転送を行う際には、両局での最大再送可能フレーム数毎に実施の第一形態で前述した方法で、相手局への送信権の委譲を行えばよいことになる。
また、ここでは、一次局が両局の最大再送可能フレーム数を知るまでの手順を述べたが、二次局でも同様に、一次局から受信した接続要求フレーム中の再送可能フレーム数と、自局の再送可能フレーム数を比較することにより、両局の最大再送可能フレーム数を知ることができるので、ここでは、説明を割愛する。
図７に、ＳＮＲＭフレームまたはＵＡフレームに自局の再送可能データサイズを示すパラメータを付与した場合のフレーム構成を示す。ただし、ここで示すフレーム構成は一例であって、これに限るものではない。
ここでは、１バイトのパラメータを付与し、各ビットがそれぞれ自局の再送可能データサイズを示しており、各局は自局がサポートしているデータサイズを示すビットをすべて１にして、フレームの交換を行う。ここで示す例では、ビット０が１Ｂｙｔｅ、ビット１が２Ｂｙｔｅ、ビット２が３Ｂｙｔｅ、ビット３が４Ｂｙｔｅ、ビット４が８Ｂｙｔｅ、ビット５が１６Ｂｙｔｅ、ビット６が３２Ｂｙｔｅ、ビット７が６４Ｂｙｔｅを意味するものとする。
両局では、それぞれ受信したフレームを基に、対向局のパラメータから得られる対向局の受信可能データサイズ以内で、フレームの送信権の委譲を行えばよいこととなる。
図８に、本発明の実施の形態におけるフレームのやり取りを信号シークエンス図にて示す。ここでは一次局は再送可能データサイズが４Ｂｙｔｅであり、二次局では３Ｂｙｔｅであるとする。一次局では、再送可能データサイズが４Ｂｙｔｅであるため、図７に示すフレーム構成では、“００００１１１１”のデータをＳＮＲＭフレームに付与してＳＮＲＭフレームの送信を行う。
また、二次局では、再送可能データサイズが３Ｂｙｔｅであるため、図７に示すフレーム構成では、“０００００１１１”のデータをＵＡフレームに付与してＵＡフレームの送信を行う。一次局では、二次局の最大受信可能データサイズが３Ｂｙｔｅであることが分かるので、これ以降のフレームの送信では、実施の第一形態で前述した方法を用いることにより、一次局では３フレームを送信するごとに相手局に送信権の委譲を行う。
〔実施の第三形態〕
本実施の第三形態に係るデータの転送システム（通信システム）は、階層構造の各通信プロトコルを用いて通信を行うシステムに関するものである。なお、他の実施の形態において定義した用語（部材及び機能を含む）については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。
本実施の形態に係るデータの転送システムについて、図１２から図１７に基づいて説明すると以下の通りである。
図１２は、本実施の形態における局（一次局（送信装置）または二次局（受信装置））の構成を示すブロック図である。また、図１３に、本発明におけるデータ転送システムのプロトコルスタックを示す。図１３ではＩｒＤＡのプロトコルスタックのＴｉｎｙＴＰ層に位置する通信プロトコル層で本実施の形態の機能を実現することとし、以下、該通信プロトコル層をＳＭＰ（Ｓｅｑｕｅｎｃｅ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）層と呼ぶこととする。もちろん、本発明に係る通信システムを実現するためのプロトコルスタックはこれに限るものではない。
図１２に示すように、一次局または二次局である局１２は、アプリケーション層処理部１２１と、ＯＢＥＸ層処理部１２２と、ＳＭＰ層処理部１２３と、ＩｒＬＭＰ層処理部１２４と、ＩｒＬＡＰ層処理部１２５と、送信器１２６と、受信器１２７とを備えている。
アプリケーション層処理部１２１と、ＯＢＥＸ層処理部１２２と、ＳＭＰ層処理部１２３と、ＩｒＬＭＰ層処理部１２４と、ＩｒＬＡＰ層処理部１２５とは、この順番にて階層構造を備えた、複数種類の各通信プロトコルの機能を実現するブロックである。
一次局における二次局に対する要求フレーム送信時の各ブロックの機能について説明すると以下の通りである。
アプリケーション層処理部１２１は、図示しない操作部に入力された利用者の指示に応じて、ＯＢＥＸ層処理部１２２に対して、外部との通信のための要求フレームの発行を行うよう通知（制御）する。また、アプリケーション層処理部１２１は、ＯＢＥＸ層処理部１２２から応答フレームを受信した旨の通知を受けると、受信した応答フレームに応じて、所定の処理を行う。
ＯＢＥＸ層処理部１２２は、アプリケーション層処理部１２１からの要求に応じて、要求フレームの生成およびＳＭＰ層処理部１２３への要求フレームの発行を行うよう通知（制御）する。また、ＳＭＰ層処理部１２３からの応答フレームを受けて、アプリケーション層処理部１２１に対して受信結果の通知を行う。
ＳＭＰ層処理部１２３は、制御部１２３１と、送信フレーム生成部１２３２と、受信フレーム解析部１２３３とを備えている。
また、送信フレーム生成部１２３２は、応答フレーム要求フラグ付加部１２３２１と、フレーム通し番号付加部（通し番号付加手段）１２３２２と、送信権委譲フラグ付加部（送信権委譲フラグ付与手段）１２３２３と、再送要求フラグ付加部（レスポンスフレーム生成手段）１２３２４と、フレーム構築部１２３２５とを備える。
また、受信フレーム解析部１２３３は、応答フレーム要求フラグ判定部１２３３１、フレーム通し番号解析部１２３３２と、送信権委譲フラグ判定部１２３３３と、再送要求判定部１２３３４と、上位層データ抽出部１２３３５とを備える。
制御部１２３１は、ＯＢＥＸ層処理部１２２からの転送要求を受けると、フレーム通し番号付加部１２３２２に送信フレームの通し番号の通知、送信権委譲フラグ付加部１２３２３に相手局に送信権を委譲するか否かの通知を行う。また、ＯＢＥＸ層処理部１２２からの転送要求が応答フレームを要求しているか否かに応じて、制御部１２３１は、応答フレーム要求フラグ付加部１２３２１を制御する。また、本実施の形態では、一次局において再送要求を行わないため、再送要求フラグ付加部１２３２４は、特に制御を行う必要はない。なお、一次局において再送要求を行う場合は、再送要求フラグ付加部１２３２４にて再送要求フラグを付加することとなる。
フレーム構築部１２３２５では、ＯＢＥＸ層処理部１２２から受けた要求フレームに対して、応答フレーム要求フラグ付加部１２３２１から通知された、上位層が送信フレームに対して応答フレームが要求されているか否かを示す情報と、フレーム通し番号付加部１２３２２から通知されたフレームの通し番号と、送信権委譲フラグ付加部１２３２３から通知された、送信権の委譲を行うか否かを示す情報と、再送要求フラグ付加部１２３２４からの再送要求を行うか否かを示す情報（ただし、一次局では再送要求を行わないので常に固定値）とに基づいてヘッダ情報を生成し、そのヘッダ情報を付加してフレームを構築する。そして、フレーム構築部１２３２５は、構築したフレームを下位層であるＩｒＬＭＰ層処理部１２４へ出力する。
ＩｒＬＭＰ層処理部１２４では受信した要求フレームに所定のヘッダ情報を付加して、フレームを生成し、下位層であるＩｒＬＡＰ層処理部１２５へフレームを出力する。
同様に、ＩｒＬＡＰ層処理部１２５では、受信した要求フレームに所定のヘッダ情報を付加してフレームを生成し、送信器１２６へ出力する。
送信器１２６は、赤外線通信路を介して、ＩｒＬＡＰ層処理部１２５から受信した複数のフレームを所定の時間間隔で外部に送信する。
次に、一次局における二次局から送信される応答フレーム受信時の各ブロックの動作について説明すると以下の通りである。
受信器１２７が、赤外線通信路を介して、二次局から送信される応答フレームを受信すると、受信した応答フレームをＩｒＬＡＰ層処理部１２５へ出力する。
ＩｒＬＡＰ層処理部１２５、ＩｒＬＭＰ層処理部１２４では、それぞれ受信した応答フレームからヘッダ情報の解析を行い、ヘッダ情報に基づいて所定の処理を行い、ヘッダ情報の除去を行い上位層に対して応答フレームが渡されていく。
ＳＭＰ層処理部１２３では、下位層であるＩｒＬＭＰ層処理部１２４から応答フレームを受信し、受信フレーム解析部１２３３において応答フレームの解析を行う。
送信権委譲フラグ判定部１２３３３では、受信フレームのＢＬ（後述する）ビットを参照し、送信権の委譲が行われているか否かの判定結果を制御部１２３１へ通知する。
また、再送要求判定部１２３３４では、受信フレームのＲＳ（後述する）ビットを参照し、相手局からの再送要求が行われているか否かの判定結果を制御部１２３１へ通知する。
また、フレーム通し番号解析部１２３３２において、受信フレームからフレーム番号を抽出し、制御部１２３１へ出力する。
制御部１２３１では、再送要求判定部１２３３１からの判定結果の通知を受けて、相手局が再送を要求している場合には、フレーム通し番号解析部１２３３２より通知された通し番号のフレームから再送を行うように送信フレーム生成部１２３２を制御する。また、再送要求判定部１２３３１からの判定結果が相手局が再送を要求していないことを示している場合には、送信完了していないフレームを順次送信していく。
また、上位層データ抽出部１２３３５では、下位層（ここではＩｒＬＭＰ層処理部１２４）から受信したフレームから、ＳＭＰ層のヘッダ情報の除去を行い、上位層（ここではＯＢＥＸ層処理部１２２）へデータを出力する。
こうして、一次局では、転送データが送信完了するまで上記の手順で二次局へデータ転送を行っていく。
次に、二次局における一次局から送信される要求フレーム受信時の各ブロックの動作について説明すると以下の通りである。
一次局と同様、二次局においても受信器１２７が一次局から送信される要求フレームを受信し、ＩｒＬＡＰ層処理部１２５およびＩｒＬＭＰ層処理部１２４において、それぞれヘッダ情報の解析、ヘッダ情報の除去が行われ、上位層に要求フレームが渡されていく。
ＳＭＰ層処理部１２３では、ＩｒＬＭＰ層処理部１２４から要求フレームを渡されると、受信フレーム解析部１２３３において受信フレームの解析を行う。
フレーム通し番号解析部１２３３２では、受信フレームからフレーム通し番号の抽出を行い、受信したフレームの通し番号のチェックを行い、正常であるか異常が（フレーム抜け等）あるかの判定結果を制御部１２３１に通知する。また、異常があった場合には合わせてエラーがあったフレームの通し番号（再送してほしいフレーム番号）を制御部１２３１へ通知する。
また、送信権委譲フラグ判定部１２３３３では、受信フレームのＢＬ（後述する）ビットを参照し、送信権の委譲が行われているか否かの判定結果を制御部１２３１へ通知する。
また、応答フレーム要求フラグ判定部１２３３１では、受信フレームのＤＬ（後述する）ビットを参照し、ＤＬビットが上位層の応答フレームを要求しているか否かの判定結果を制御部１２３１へ通知する。
制御部１２３１では、送信権委譲フラグ判定部１２３３３から通知される判定結果をもとに、判定結果が相手局から送信権の委譲が行われていることを示している場合には、送信フレーム生成部１２３２に対して、応答フレームの生成および送信を行うよう制御（通知）する。
この時、フレーム通し番号解析部１２３３２の解析結果を基にフレーム通し番号のエラーが発生していた場合には、制御部１２３１は、再送要求フラグ付加部１２３２４に再送要求を行うことを示すようフラグを設定することを通知し、フレーム通し番号付加部１２３２２に対しては、フレーム通し番号解析部１２３３２から通知されたエラーが発生したフレーム通し番号を通知する。
また、フレーム通し番号解析部１２３３２の解析結果がエラーが発生していないことを示している場合には、制御部１２３１は、再送フラグ付加部１２３２４に対して再送要求は行わず正常に受信が完了していることを示すようフラグを設定することを通知する。
ただし、制御部１２３１では、応答フレーム要求フラグ判定部１２３３１の判定結果が上位層の応答フレームを要求していること示している場合には、ＯＢＥＸ層処理部１２２が応答フレームの準備が完了するまで、応答フレームを返信せず、ＯＢＥＸ層処理部１２２から応答フレームの準備が完了した旨の通知を受けた時点で、送信フレーム生成部１２３２へ応答フレームの生成を指示する。送信フレーム生成部１２３２では、ＯＢＥＸ層処理部１２２から受信した応答フレームに、所定のヘッダ情報を付加してフレームを構築し、下位層であるＩｒＬＭＰ層処理部１２４へ出力する。
また、ＯＢＥＸ層処理部１２２が応答フレームの準備が完了するまでに、ＳＭＰ層処理部１２３において応答フレームを生成して送信しておいてもよい。ただし、この場合には、制御部１２３１は、送信権委譲フラグ付加部１２３２３に対して、一次局に送信権の委譲を行わないように制御して、送信フレームを生成するように制御する。そして、ＯＢＥＸ層処理部１２２から応答フレームの準備が完了した旨の通知を受けた時点で、送信フレーム生成部１２３２へ応答フレームの生成を指示する。また、このとき送信権委譲フラグ付加部１２３２３に対して一次局に送信権の委譲を行うようフラグを設定するように制御する。送信フレーム生成部１２３２では、ＯＢＥＸ層処理部１２２から受信した応答フレームに、所定のヘッダ情報を付加してフレームを構築し、下位層であるＩｒＬＭＰ層処理部１２４へ出力する。
送信フレーム生成部１２３２では、制御部１２３１からの制御に応じて応答フレームを生成し、下位層であるＩｒＬＭＰ層処理部１２４へ生成した応答フレームを出力する。
こうして、二次局においては、一次局からの要求フレームに対する応答フレームの送信を、一次局から送信権の委譲が行われる毎に行っていく。
図１４にＵＩフレーム及びＵＩフレームに対するレスポンス（応答）フレームに、フレームの通し番号、相手局に送信権を委譲するか否かを示すフラグ、それまで受信したフレーム中にエラーまたはフレーム抜けがあったか否かを示すフラグ、および一次局の上位層が要求フレームに対する応答フレームを要求しているか否かを示すフラグを付与した場合のフレーム構成を示す。ただし、ここで示すフレーム構成は一例であって、これに限るものではない。
ここでは、ＵＩフレームおよびＵＩフレームに対するレスポンスフレームに３バイトのヘッダを付与し、相手局に送信権を委譲するか否かを示すフラグ、一次局の上位層が要求フレームに対する応答フレームを要求しているか否かを示すフラグ、二次局が使用する受信フレームにエラーがあったか否かを示すフラグ、および残り２１ビットが送信フレームの通し番号として構成される。
以下、一次局の上位層が要求フレームに対する応答フレームを要求しているか否かを示すフラグをＤＬ、相手局に送信権を委譲するか否かを示すフラグをＢＬ、二次局が使用する受信フレームにエラーがあったか否かを示すフラグをＲＳ、フレームの通し番号をＳとする。
以下、このフレーム構成を用いて、本実施の形態によって構成される一次局と二次局との間にて、どのようにしてデータ転送が行われるかについて図１５を用いて説明する。
なお、図１５は、双方向通信においてすべての受信データについてエラーが発生しなかった場合を示す。
まず、一次局において、図示しない操作部に入力された利用者の指示に応じて、アプリケーション層処理部１２１から要求フレーム転送要求が通知され、ＯＢＥＸ層処理部１２２は下位層であるＳＭＰ層に対して要求フレームを出力する。
ここでは、ｎフレーム単位で二次局に送信権の委譲が行われるとする。また、図１５に示すＳ、ＤＬ、ＢＬ、ＲＳはそれぞれ、フレームの通し番号、一次局の上位層が要求フレームに対する応答フレームを要求しているか否かを示すフラグ、送信権の委譲を行うか否かを示すフラグ、再送要求を行うか否かを示すフラグである。
ＳＭＰ層は、上位層であるＯＢＥＸ層から受け渡された転送データを所定のデータサイズに分割し、通し番号を付けて下位層であるＩｒＬＭＰ層に出力する。ここでは、ｎフレーム単位で送信権の委譲を行うこととしているので、Ｓ＝ｎ−１のフレームはＢＬ＝１にして下位層にデータを出力する。
ＳＭＰ層の下位層であるＩｒＬＭＰ層およびＩｒＬＡＰ層は、ＳＭＰ層から受けたフレームに対してそれぞれ順次ヘッダを付加していき、赤外線通信路を介して二次局にフレームの送信を行う。
一方、二次局では、赤外線通信路を介して一次局からフレームを受信する。二次局は、ＳＭＰ層の下位層であるＩｒＬＡＰ層、ＩｒＬＭＰ層においてそれぞれ受信フレームから順次ヘッダ情報の解析を行い、ヘッダ情報を除去して上位層に対してデータを出力していく。
ＳＭＰ層は、下位層であるＩｒＬＭＰ層からフレームの受信を行い、受信フレームのヘッダ情報（ここでは３Ｂｙｔｅ）の解析を行う。そして、ヘッダ情報内のフレーム通し番号を元にフレーム抜けなどのエラーが発生していないかをチェックし、エラーが発生していない場合は、ヘッダ情報の除去を行い、ＯＢＥＸ層（上位層）に順次データを渡していく。ただし、Ｓ＝ｎ−１のフレームについては、ＢＬ＝１、ＤＬ＝０であるので、一次局から送信権の委譲が行われており、かつ上位層であるＯＢＥＸ層の応答が必要でないので、ＳＭＰ層は、受信したｎ個のフレーム中にエラーがなく、再送が必要でないことを意味するよう、ＲＳ＝１にしてレスポンスフレームを送信する。
一次局は、二次局から送信したｎ個のフレームを正常に受信した旨のレスポンスフレームを受信すると、上記処理と同様の処理を行い、次のｎ個のフレームを送信する。また、二次局も同様に、次のｎ個のフレームを受信し、ＢＬ＝１のフレーム（図ではＳ＝ｍ−１）のフレームを受信すると、ｎ個のフレームを正常に受信した旨のレスポンスフレームを一次局に対して返信する。
こうして、一次局は、順次ｎ個のフレーム単位毎に二次局に送信権の委譲を行いながら、フレーム送信を行っていくが、転送データの最終フレームではＢＬ＝１、ＤＬ＝１として、一次局の上位層が要求フレームに対する応答フレームを要求するようにして送信を行う。ここでは、ＤＬビットを一次局の上位層が要求フレームに対する応答フレームを要求していることを示すためのフラグとして利用しているが、他の意味のフラグと兼用して利用することも可能である。例えば、図１５で示す例の場合、転送データの最終フレームを意味するフラグとして扱うことも可能である。
ＢＬ＝１、ＤＬ＝１のフレームを受信した二次局のＳＭＰ層は、ＤＬ＝１のため上位層であるＯＢＥＸ層に対して、受信した要求フレームに対する応答フレームが要求されている旨の通知を行う。ＯＢＥＸ層では、ＳＭＰ層からの通知を受けて、正常にすべてのデータ受信が完了したので、ＳＭＰ層に対して応答フレームの送信要求を行い、応答フレームを渡す。ＳＭＰ層は、ＯＢＥＸ層からの応答フレーム送信要求を受けて、ＯＢＥＸ層から受け渡された応答フレームにヘッダ情報（ここでは、再送が必要でないことを示すようにＲＳ＝１にし、ＢＬ＝１、ＤＬ＝１にする）を付加して、下位層であるＩｒＬＭＰ層にデータを渡す。下位層であるＩｒＬＭＰ層、およびＩｒＬＡＰ層は、それぞれ上位層から受け渡されたデータに所定のヘッダ情報を付加して、下位層に応答フレームを渡していき、ＩｒＬＡＰ層では赤外線通信路を介して一次局に対して応答フレームの送信を行う。
二次局から送信された応答フレームを受信した一次局は、下位層から順次ヘッダ情報の解析および除去を行い、上位層に対してデータが受け渡していく。そして、ＳＭＰ層の上位層であるＯＢＥＸ層は、二次局から送信されたＯＢＥＸ応答フレームを受信し、一次局のＳＭＰ層の上位層もデータ転送が正常に完了したことを認識できることになる。
また、図１６、図１７は、認証時などに上位層から認証要求が発行される場合のデータ転送の手順を示す信号シークエンス図である。
図１６に示されるように、上位層から受け渡された認証用フレームに対して、ＳＭＰ層においてＤＬ＝０、ＢＬ＝１のヘッダ情報を付加して、二次局にデータ転送を行った場合には、二次局は、受信したフレームがＢＬ＝１のため送信権が一次局から委譲されており、ＤＬ＝０であるので上位層からの応答を待つことなくレスポンスを返信するので、二次局の上位層の応答フレームが返信できないため、両局間で認証が完了しないことになる。
一方、本実施の形態による構成で、ＤＬ＝１にして認証フレームを二次局に送信した場合には、二次局のＳＭＰ層においてＤＬ＝１であるため、上位層が応答フレームを準備完了した時点で、上位層から渡される応答フレームにヘッダ情報を付加して認証フレームに対するレスポンスフレームの返信を行うので、両局間の上位層間の認証が完了することになる。
また、図１７に示すように、ＤＬ＝１、ＢＬ＝１のパケットを受信した場合に、ＳＭＰ層は、上位層であるＯＢＥＸ層に対して受信した要求フレームに対する応答フレームが要求されている旨の通知を行い、ＳＭＰ層レベルでの応答フレームを先に返信してもよい。ただし、この場合には、ＢＬ＝０で返信を行い、相手局に送信権を委譲しないようにしておく。そして、ＯＢＥＸ層で応答フレームの送信準備が完了した時点で、再度ＯＢＥＸの応答フレームにＳＭＰ層のヘッダ情報を付加して応答フレームを返信する。
こうすることにより、一次局のＳＭＰ層は、二次局のＯＢＥＸ層において応答フレームが準備されてから応答フレームが返信されてくる前に、ＳＭＰ層レベルの応答フレーム（ＯＢＥＸ層の応答フレームが包含されていない）を受信することができる。これにより、一次局のＳＭＰ層は、ＯＢＥＸ層からの応答フレームが返信される前に、相手局が正常にフレームを受信できたか否かを知ることができるので、あらかじめ次のデータ転送の準備などを行っておくことができる。
なお、上記各実施の形態では、送信機（一次局）および受信機（二次局）がＣＰＵを備える構成としたが、ＣＰＵに限らず、マイコンなどの演算処理機能を有するものであってもよい。
また、上記各実施の形態では、ＣＰＵからの指示を受けて、コントローラが転送データの転送を行うものとした。しかしながら、ＣＰＵを介さずに、ＤＭＡ（ダイレクトメモリアクセス）によって、コントローラが転送データの転送を行ってもよい。この場合、ＣＰＵからの指示を受けることなく、メモリから転送データの転送を行うことができる。これにより、ＣＰＵの負担を低減することができる。
〔実施の第四形態〕
本実施の第四形態に係る転送データの転送システム（通信システム）について、図３１から図３３に基づいて説明すると以下の通りである。なお、他の実施の形態において定義した用語（部材及び機能を含む）については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。
本実施の形態では、送信機のブロック図として図３１、受信機のブロック図として図３２、信号のシークエンス図として図３３を用いて説明する。
図３１は、本実施の形態に係る送信機２００１のブロック図である。なお、図３１は、送信機の構成の一例であり、これに限るものではない。また、各構成回路はソフトウェアであってもハードウェアであっても構わない。以下に各構成要素の説明を行う。
送信機２００１は、送信データを送信する側の機器である。ここでいう送信データとは、例えばテキストデータ、画像データなどがあげられるが、これに限らない。
図３１に示すように、送信機（一次局、クライアント機器）２００１は、制御部（制御手段）２００２、メモリ（記憶手段）２００３、一括送信最終フラグ生成回路（一括送信最終フラグ生成手段）２００４、通し番号生成回路（通し番号生成手段）２００５、送信フレーム生成回路（送信フレーム生成手段）２００６、送信部（送信手段）２００７、受信部（受信手段）２００８、受信フレーム解析回路（受信フレーム解析手段）２００９、エラー無しフラグ解析回路（エラー無しフラグ解析手段）２０１０、エラー検出回路（エラー検出手段）２０１１、通し番号解析回路（通し番号解析手段）２０１２を備えて構成されている。
制御部２００２は、送信機２００１の各構成要素の制御を行う。
メモリ２００３には送信データが蓄えられる。このメモリ２００３は、揮発性のメモリ（例えばＳＤＲＡＭなど）であっても、不揮発性のメモリ（例えばフラッシュメモリ、ＨＤＤ、ＤＶＤなど）であってもよい。また、図３１では、メモリ２００３は、送信機２００１内に配置されているが、必ずしも送信機２００１内に存在する必要はなく、送信機２００１の外部メモリとして送信機２００１に接続されていても構わない。
一括送信最終フラグ生成回路２００４は、送信機２００１があるまとまった単位でデータ転送を行うときに、前記あるまとまった単位の最終データを含むフレームを送信する際に、それを意味する値として設定する回路である。本実施の形態においては、ＢＬ（Ｂｌｏｃｋ Ｌａｓｔ）という略語を定義し、ＢＬが１である場合は、前記あるまとまった単位の最終データを含むフレームであり、ＢＬが０である場合は、前記あるまとまった単位の最終データがフレームに含まれていないものとする。
後述する図３３のシークエンス図においても、同様の意味でＢＬという略語を用いている。また、本実施の形態においては、一括送信最終フラグと表現しているが、例えば通信確認要求フラグなどであっても、本質的には本実施の形態における一括送信最終フラグと同様の意味を持つため、一括送信最終フラグと必ずしも同一の意味を持ったフラグでなくても、同様の動作を行うフラグであれば、これに限らない。
通し番号生成回路２００５は、予め定められたルールに従って、通し番号を増減し、各送信フレームに付与する回路である。本実施の形態においては、ＳＥＱ（Ｓｅｑｕｅｎｃｅｎｕｍｂｅｒ）という略語を定義し、ＳＥＱが１である場合は、通し番号が１であることを示している。図３３のシークエンス図においても、同様の意味でＳＥＱという略語を用いている。
送信フレーム生成回路２００６は、予め定められたフォーマットにより、送信フレームを生成する回路である。前述の一括送信最終フラグＢＬ、通し番号ＳＥＱ、送信データを予め定められたフォーマットに従って配置し、送信フレームを生成する。なお、本発明においては、ウィンドウサイズの制限がない通信方式を用いているため、ウィンドウサイズの制限がないフレームフォーマットでの送信フレームを生成する。例として、ＩｒＬＡＰ（Ｉｎｆｒａｒｅｄ Ｌｉｎｋ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）におけるＵＩ（Ｕｎｎｕｍｂｅｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ）フレームがあげられるがこれに限らない。また、対向局がエラー検出を行うためのエラー検出符号も合わせて付加される。エラー検出符号としては、例えばＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）などがあるがこれに限らない。また、エラー訂正符号が付加されてもよい。
送信部２００７は、送信フレーム生成回路２００６によって生成された送信フレームを送信する回路である。例えば、通信媒体として赤外線を用いるならば、ＬＥＤ（発光ダイオード）やＬＤ（レーザダイオード）となるが、これに限らない。また、他の通信媒体を用いる場合は、その通信媒体に応じた送信部となる。
受信部２００８は、対向局が送信したフレームを受信する回路である。例えば、通信媒体として赤外線を用いるならば、ＰＤ（フォトダイオード）となるが、これに限らない。また、他の通信媒体を用いる場合は、その通信媒体に応じた受信部となる。
受信フレーム解析回路２００９は、受信部２００８により受信した受信フレームの解析を行う。具体的には、受信フレーム内のエラー無しフラグを抽出し、エラー無しフラグ解析回路２０１０に渡す。また、受信フレーム内の通し番号を抽出し、通し番号解析回路２０１２に渡す。また、受信フレーム内にデータが存在する場合は、データを抽出し、制御部２００２を介して、メモリ２００３に保存する。なお、メモリ２００３にデータを保存する場合は、必ずしも制御部２００３を介さなくてもよい。
エラー無しフラグ解析回路２０１０は、予め定められたフォーマットにより対向局に設定されたエラー無しフラグを解析し、解析結果を制御部に通知する。本実施の形態では、エラー無しフラグと表現しているが、例えばエラーありフラグや再送要求フラグ、再送要求無しフラグであっても構わない。
エラー検出回路２０１１は、受信フレームに付与されているエラー検出用の符号を解析し、受信フレームにエラーがないかどうかを判別し、解析結果を制御部に通知する。エラー検出用の符号として、例えば、ＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）符号などの巡回符号があげられるが、これに限らない。また、エラー訂正符号が付与されている場合は、エラー訂正を行うこととなる。
通し番号解析回路２０１２は、受信した通し番号を解析し、解析結果を制御部２００２に通知する。
図３２は、本実施の形態に係る受信機２１０１のブロック図である。なお、図３２は、受信機の構成の一例であり、これに限るものではない。また、各構成回路はソフトウェアであってもハードウェアであっても構わない。以下に各構成要素の説明を行う。
受信機２１０１は、対向機器からの送信データを受信する側の機器である。ここでいう送信データとは、例えばテキストデータ、画像データなどがあげられるが、これに限らない。
図３２に示すように、受信機（二次局、サーバ機器）２１０１は、制御部（制御手段）２１０２、メモリ（記憶手段）２１０３、エラー無しフラグ生成回路（エラー無しフラグ生成手段）２１０４、通し番号生成回路（通し番号生成手段）２１０５、送信フレーム生成回路（送信フレーム生成手段）２１０６、送信部（送信手段）２１０７、受信部（受信手段）２１０８、受信フレーム解析回路（受信フレーム解析手段）２１０９、一括送信最終フラグ解析回路（一括送信最終フラグ解析手段）２１１０、エラー検出回路（エラー検出手段）２１１１、通し番号解析回路（通し番号解析手段）２１１２を備えて構成されている。
制御部２１０２は、受信機２１０１の各構成要素の制御を行う。
メモリ２１０３には、受信データが蓄えられる。このメモリ２１０３は、揮発性のメモリ（例えばＳＤＲＡＭなど）であっても、不揮発性のメモリ（例えばフラッシュメモリ、ＨＤＤ、ＤＶＤなど）であってもよい。また、図３２では、メモリ２１０３は、受信機２１０１に配置されているが、必ずしも受信機２１０１内に存在する必要はなく、受信機２１０１の外部メモリとして受信機２１０１に接続されていても構わない。
エラー無しフラグ生成回路２１０４は、対向局から受信したフレーム内にエラーがあったかどうかを対向局に通知するためのエラー無しフラグを予め定められたフォーマットにより生成する回路である。本実施の形態では、エラー無しフラグと表現しているが、例えばエラーありフラグや再送要求フラグ、再送要求無しフラグであっても、本質的には、エラー無しフラグと同様の意味を持つため、エラー無しフラグと同一の意味を持たないフラグであっても同様の動作をするものであるフラグならばこれに限らない。
通し番号生成回路２１０５は、それまでに受信したフレームにエラーが検出された場合に、対向局に再送要求を行う際に、再送して欲しい通し番号を設定する回路である。
送信フレーム生成回路２１０６は、前述のエラー無しフラグ、通し番号を予め定められたフォーマットに従って配置し、送信フレームを生成する回路である。例として、ＩｒＬＡＰ（Ｉｎｆｒａｒｅｄ Ｌｉｎｋ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）におけるＵＩ（Ｕｎｎｕｍｂｅｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ）フレームがあげられるがこれに限らない。
送信部２１０７は、送信フレーム生成回路２１０６によって生成された送信フレームを送信する回路である。例えば、通信媒体として赤外線を用いるならば、ＬＥＤ（発光ダイオード）やＬＤ（レーザダイオード）となるが、これに限らない。また、他の通信媒体を用いる場合は、その通信媒体に応じた送信部となる。
受信部２１０８は、対向局が送信したフレームを受信する回路である。例えば、通信媒体として赤外線を用いるならば、ＰＤ（フォトダイオード）となるが、これに限らない。また、他の通信媒体を用いる場合は、その通信媒体に応じた受信部となる。
受信フレーム解析回路２１０９は、受信部２１０８により受信した受信フレームの解析を行う。具体的には、受信フレーム内の一括送信最終フラグを抽出し、一括送信最終フラグ解析回路に渡す。また、受信フレーム内の通し番号を抽出し、通し番号解析回路に渡す。また、受信フレーム内にデータが存在する場合は、データを抽出し、制御部を介して、メモリに保存する。メモリにデータを保存する場合は、必ずしも制御部を介さなくてもよい。
一括送信最終フラグ解析回路２１１０は、受信フレーム解析回路２１０９により渡された一括送信最終フラグを解析し、解析結果を制御部２１０２に通知する。
エラー検出回路２１１１は、受信フレームに付与されているエラー検出用の符号を解析し、受信フレームにエラーがないかどうかを判別し、解析結果を制御部２１０２に通知する。エラー検出用の符号として、例えば、ＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）符号などの巡回符号があげられるが、これに限らない。また、エラー訂正符号が付与されている場合は、エラー訂正を行うこととなる。
通し番号解析回路２１１２は、受信フレーム内に付与されている通し番号が予め定められたルールによって増減しているかどうかを解析し、解析結果を制御部２１０２に通知する。例えば、通信路において、フレームが抜けた場合などは、この通し番号解析回路２１１２によりエラーと判断される。
具体的には、送信フレーム生成回路２１０６は、エラー検出回路２１１１でデータのエラーが検出された場合に、エラー無しフラグをエラー有りに設定して、そのときの受信フレームの通し番号を含む送信フレームを生成する。また、送信フレーム生成回路２１０６は、エラー検出回路２１１１ではデータのエラーが検出されなかったが、通し番号解析回路２１１２において通し番号のエラーが検出された場合、そのときの受信フレームの通し番号を含む送信フレームを生成する。
つづいて、図３１、図３２、および図３３のシークエンス図を参照しながら、本実施の形態における各信号の流れを説明する。
送信機２００１は、自機器内もしくは外部から送信データの転送要求が発生すると、制御部２００２が一括で送信するデータのサイズを定め、一括送信最終フラグ生成回路２００３に通知する。
一括送信最終フラグ生成回路２００３は、前記一括送信データサイズを内部に保持し、制御部２００２もしくはメモリ２００３から渡されるデータのサイズの累計を計算し、累計データサイズが、前記一括送信データサイズに達したならば、一括送信最終フラグを予め定められたフォーマットにより最終の意味（ＢＬ＝１）と設定し、また、前記一括送信データサイズに達していないならば、最終でない意味（ＢＬ＝０）と設定し、送信フレーム生成回路２００５に渡す。また、制御部２００２は、フレームを生成するごとに、通し番号生成回路２００４に通し番号を生成するように通知する。
これを受けた通し番号生成回路２００４は、予め定められたルールにより通し番号を増減し、送信フレーム生成回路２００５に渡す。
送信フレーム生成回路２００５は、前記の一括送信最終フラグ、通し番号、データを予め定められたフォーマットにより配置し、送信部２００６を介して送信する。
図３３においては、ｔ１０１、ｔ１０２、ｔ１０３、ｔ１０４、ｔ１１０が一括送信最終フラグが最終でないフレームであり、ｔ１０５、ｔ１１１が一括送信最終フラグが最終のフレームである。また、ｔ１０１、ｔ１０２、ｔ１０３、ｔ１０４、ｔ１０５の各フレーム内の通し番号（ＳＥＱ）は、本実施の形態においては、１ずつ増えていくものとして記述している。
受信機２１０１では、対向局からフレームを受信部２１０８を介して受信すると、受信フレーム解析回路２１０９にて受信フレーム内の各パラメータを抽出する。前記パラメータとは、例えば一括送信最終フラグ、通し番号、データなどであり、一括送信最終フラグは、一括送信最終フラグ解析回路２１１０に渡され、通し番号は通し番号解析回路２１１２に渡され、データは、必要ならば、制御部２１０２を介して、メモリ２１０３に保存される。
また、同時にエラー検出回路２１１１により、受信フレームにて、例えばＣＲＣエラーがないかどうかのエラー検出が行われる。エラー検出もしくはエラー訂正符号がＣＲＣ符号以外の場合は、それに従ったエラー検出もしくはエラー訂正が行われる。
また、一括送信最終フラグ解析回路２１１０では、一括送信最終フラグの解析を行い、解析結果を通知する。
図３３のシークエンス図においては、ｔ１１３，ｔ１１４，ｔ１１５、ｔ１２１のフレーム受信時は、一括送信最終フラグは最終でなく、ｔ１１６、ｔ１２２のフレーム受信時は、一括送信最終フラグを最終としてそれぞれ制御部２１０２に通知される。
また、通し番号解析回路２１１２においては、受信フレーム中の通し番号が予め定められたルールに従って、増減されているかどうかを解析し、解析結果を制御部２１０２に通知する。本実施の形態では、前記予め定められたルールとして通し番号はフレームごとに１ずつ増加することとしている。
図３３のシークエンス図では、送信機２００１が送信した通し番号３のフレームが通信路の異常により、受信機２１０２において認識されず、次の通し番号４のフレームを受信した場合を示している。この場合は、通し番号３のフレームがエラーが起きたフレームとして制御部２１０２に通知される。
制御部２１０２では、一括送信最終フラグが最終を意味するフレームを受信したことを通知され、またエラーが起きたフレームとして通し番号３が通知されているため、エラー無しフラグ生成回路２１０４に対して、エラーありを、また通し番号生成回路２１０５に対して、通し番号３をそれぞれ通知し、送信フレーム生成回路２１０６に送信フレームを生成するように通知する。
これを受けたエラー無しフラグ生成回路２１０４は、予め定められたフォーマットによりエラーありの意味を示すフラグを生成し、送信フレーム生成回路２１０６に渡す。
また、通し番号生成回路２１０５は、制御部２１０２より渡された通し番号３を送信フレーム生成回路２１０６に渡す。
これらのエラー無しフラグおよび通し番号を渡された送信フレーム生成回路２１０６は、予め定められたフォーマットによりこれらのパラメータを配置し、送信部２１０７を介して送信する。図３３のシークエンス図においては、ｔ１１７のフレームを指している。
ｔ１１７のフレームをｔ１０６に受信部２００８を介して受信した送信機２００１は、受信フレーム解析回路２００９にて、受信フレーム中の各パラメータの抽出を行い、抽出されたエラー無しフラグはエラー無しフラグ解析回路２０１０へ、また通し番号は通し番号解析回路２０１２へそれぞれ渡す。
エラー無しフラグ解析回路２０１０では、渡されたエラー無しフラグの解析を行う。この場合、受信機２１０１が送信したｔ１１７のフレームはエラーありを示しているため、エラーありとして解析され、その旨を制御部２００２へ通知する。
また、通し番号解析回路２０１２では、通し番号の解析を行い、解析結果を制御部２００２へと通知する。この場合、通し番号３が制御部２００２へ通知される。
また、同時にエラー検出回路２０１１により、受信フレームにて、例えばＣＲＣエラーがないかどうかのエラー検出が行われる。エラー検出もしくはエラー訂正符号がＣＲＣ符号以外の場合は、それに従ったエラー検出もしくはエラー訂正が行われる。
制御部２００２は、前述のエラー無しフラグの解析結果、通し番号、エラー検出結果により、受信機２１０１に正常に一括送信が行えたかどうかを判断し、送信データに未送信の部分があるならば、それらのデータを一括送信するか、もしくはすでに送信したデータの再送を行うかどうかを判断する。この場合、エラーがあり、通し番号が３のフレームからの送信を受信機２１０１が要求していると判断されるため、送信データを前回の送信時において通し番号が３の部分から、再送を行うようにする。具体的には、一括送信最終フラグ回路２００４に再送を行う旨を通知するとともに、通し番号生成回路２００５には開始番号として３を通知する。
一括送信最終フラグ生成回路２００４では、必要なら一括送信データサイズの再計算を行う。前回の一括送信データサイズと同じ値を用いてもよいし、また、前回の一括送信最終フラグを最終と意味するフレームを送信した際のフレームの通し番号で一括送信最終フラグを最終としてもよい。具体的には、１回目の一括送信にて、通し番号が１から５のフレームを送信した際に、受信機から通し番号３からのフレームの再送要求を受信した場合に、２回目の一括送信において、通し番号３から７の一括送信を行ってもよいし、通し番号３から５の一括送信を行ってもよいということである。
通し番号生成回路２００５では、制御部２００２から通し番号３からの再送を通知されると、通し番号の開始番号を３に再設定し、送信フレーム生成回路２００６へと渡す。
送信フレーム生成回路２００６は、送信フレームを生成し、送信部２００７を介して送信する。
これらの再送の様子が、図３３のｔ１１７、ｔ１１０、ｔ１１１である。
これらの再送フレームを受信した受信機２１０１は、エラー検出回路２１１１および通し番号解析回路２１１２にてすべての受信フレームにエラーがないと判断されると、一括送信最終フラグが最終を意味しているフレームｔ１２２を受信した後、制御部２１０２は、エラー無しフラグ生成回路２１０４にエラー無しの通知をする。
エラー無しフラグ生成回路２１０４はこれを受けて、エラー無しフラグをエラー無しの意味として設定し、送信フレーム生成回路２１０６に渡す。
送信フレーム生成回路２１０６はこれを受けて、エラー無しフラグをフレーム内に配置し、送信部２１０７を介して送信する。このときの通し番号については、説明を省略する。
このエラー無しフラグがエラー無しを示すフレームをｔ１１２にて受信した送信機２００１では、エラー無しフラグ解析回路２０１０にて、エラー無しと判断され、制御部２００２へと通知されると、一括送信が成功したことを制御部２００２が認識し、送信データに未送信のデータがある場合は、引き続き一括送信を行うことが可能となる。
以上のように、送信機２００１および受信機２１０１によれば、ウィンドウサイズの制限のないフレームを用いた通信方式においても、エラー発生時には再送処理を行うことが可能となり、信頼性の高い通信を行うことが可能となる。
また、送信機２００１において、受信機２１０１から、エラー無しフラグがエラーありを意味する再送要求を受信したときに、同時に受信した通し番号からの再送を行うのではなく、送信データの開始からの再送を行ってもよい。
また、送信データの最初からの再送を行う場合は、付与される通し番号は予め定められたルールによる初期値から（例えば、本実施の形態では０から）送信されるのが望ましい。
また、送信データの再送を行う場合、再送回数に制限を設け、予め定められた値よりも多くの再送を行っても、受信機２１０１に正常に一括送信できない場合は、送信を中断もしくは終了するようにしてもよい。こうすることで、通信路の品質が極端に悪い場合、通信を中断もしくは終了しユーザに通知することが可能となり、品質の向上した通信路での通信を行うことが可能となる、
また、再送回数の制限を例えば１回とした場合、カウンタではなく、フラグでの処理も可能となり、回路の簡略化へとつながる。
また、受信機２１０１からの再送要求での通し番号からの再送においても、再送回数に制限を設けることで、通信路の品質が悪い場合に、送信を中断もしくは終了し、ユーザに通知することで、通信路の品質が向上する可能性がある。
また、前記と同様、再送回数を例えば１回とした場合、カウンタでなく、フラグでの処理も可能となり、回路の簡略化へとつながる。
また、送信機２００１は、一括送信データサイズを１フレーム長とし、全てのフレームにおいて、一括送信最終フラグが最終となるようにしてもよい。この場合、全てのフレームにおいて、受信機２１０１からの応答が必要となり、通信効率は低下するが、送信機２００１が受信機２１０１からの再送要求に対して、保持しておくべきデータの保存領域を少なくすることが可能となり、メモリの確保が十分にできないような送信機２００１においては有効となる。
また、受信機２１０１において、エラー検出回路２１１１および通し番号検出回路２１１２により、受信フレームにエラーがあることが検出された場合、制御部２１０２は、一括送信最終フラグ解析回路２１１０により、一括送信最終フラグが最終のフレームを受信し、送信機２００１に再送を要求するまでのデータは、送信機２００１により再送される予定のデータであることから、その間のデータをメモリ２１０３に保存する処理を行わないとしてもよい。こうすることにより、再送による再受信の予定のあるデータの保存にかかる消費電力の削減につながる。
また、受信機２１０１において、送信機２００１からの受信フレームにエラーが検出されたときに行う再送要求の回数に制限を設け、予め定められた値よりも多くの再送要求を行っても、受信機２１０１において、正常に一括受信できない場合は、受信を中断もしくは終了するようにしてもよい。こうすることで、通信路の品質が極端に悪い場合、通信を中断もしくは終了しユーザに通知することが可能となり、品質の向上した通信路での通信を行うことが可能となる。
また、再送要求回数の制限を例えば１回とした場合、カウンタではなく、フラグでの処理も可能となり、回路の簡略化へとつながる。
また、受信機２１０１において、送信機２００１からの受信フレームにエラーが検出されたときに行う再送要求において、通し番号生成回路２１０５に予め定められた初期値（例えば、本実施の形態では０）を常に設定して、送信機２００１に再送要求フレームを送信してもよい。こうすることで、エラーが検出された場合の再送要求のための通し番号を保持しておく必要がなり、回路の簡略化につながる。
〔実施の第五形態〕
本実施の第五形態に係る転送データの転送システム（通信システム）について、図３２、図３４から図３６に基づいて説明すると以下の通りである。なお、他の実施の形態において定義した用語（部材及び機能を含む）については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。
本実施の形態では、送信機のブロック図として図３４、受信機のブロック図として図３２、信号のシークエンス図として図３５および図３６を用いて説明する。
図３４は、本実施の形態における送信機２２０１のブロック図である。なお、図３４は、送信機の構成の一例であり、これに限るものではない。また、各構成回路はソフトウェアであってもハードウェアであっても構わない。以下に各構成要素の説明を行う。
送信機（一次局、クライアント機器）２２０１は、送信データを送信する側の機器である。ここでいう送信データとは、例えばテキストデータ、画像データなどがあげられるが、これに限らない。また、タイマ（計時手段）２２１３以外の各構成要素は、上述した実施の第四形態における送信機２００１（図３１）の各構成要素と同一の機能を持つため、説明は省略する。
タイマ２２１３は、制御部２００２によって制御される。具体的には、一括送信最終フラグを最終として送信を行った後、制御部２００２によりスタートされ、予め定められた時間以内に、受信機２１０１より応答フレームを正常受信しない場合、制御部２００２にタイムアウトを通知する。
このタイムアウトの通知を受けた制御部２００２は、通信路の異常により、直前に送信した一括送信最終フラグが最終を示すフレームが受信機２１０１にて正常に受信できていない（図３５のｔ２０５のフレーム）、もしくは、直前に送信した一括送信最終フラグが最終を示すフレームは受信機にて正常に受信できているが、それに対して受信機から送信されたエラー無しフラグを含むフレームが通信路の異常により、送信機にて正常に受信できていない（図３６のｔ３１２のフレーム）と判断し、一括送信最終フラグ生成回路２００４、通し番号生成回路２００５、送信フレーム生成回路２００６にそれぞれ通知する。
前記通知を受けた一括送信最終フラグ生成回路２００４は、一括送信最終フラグを最終とし、送信フレーム生成回路２００６に渡す。
また、前記通知を受けた通し番号生成回路２００５は、直前のフレームの通し番号を再度設定して送信フレーム生成回路２００６に渡す。
これらを受けた送信フレーム生成回路２００６は、直前に送信したフレームと同一のデータを再度設定し、また、前記一括送信最終フラグおよび通し番号を設定し、送信部２００７を介して送信する。
以上のように、送信機２２０１が構成されることにより、一括送信最終フラグが最終を意味するフレームの再送信が可能となり、通信路の品質が悪い状態でも、再送処理を行うことが可能となり、信頼性の高い通信を行うことが可能となる。
また、一括送信最終フラグが最終のフレームの再送を行う場合、再送回数に制限を設け、予め定められた値よりも多くの再送を行っても、受信機２１０１に正常に一括送信できない場合は、送信を中断もしくは終了するようにしてもよい。こうすることで、通信路の品質が極端に悪い場合、通信を中断もしくは終了しユーザに通知することが可能となり、品質の向上した通信路での通信を行うことが可能となる。
また、図３６のシークエンス図に示すように、一括送信最終フラグが最終を示す値となっているｔ３１１のフレームに対して、返信フレームｔ３１２を送信したにもかかわらず、通信路に異常があり、返信フレームｔ３１２が送信機にて正常に受信できなかった場合に、再び一括送信最終フラグが最終を示す値となっているフレームｔ３１３を受信する場合がある。
このような場合においては、受信機２１０１では、制御部２１０２において、直前の通し番号を保持しておき、一括送信最終フラグ解析回路２１１０にて、一括送信最終フラグが最終のフレームを受信した通知を受けたときに、通し番号解析回路２１１２からの通し番号が直前の通し番号と同一であった場合は、通し番号解析回路２１１２の解析結果がエラーであったとしても、エラーとして処理を行わず、制御部２１０２は、エラー無しフラグ生成回路２１０４に直前に送信したフレームと同一の値を設定し、また通し番号生成回路２１０５に同じく直前に送信したフレームの通し番号を設定し、送信することとなる。エラー無しフラグ生成回路２１０４にて設定される値がエラー無しを示しているならば、通し番号は設定されなくてもよい。
こうすることで、通信路の品質が悪く、受信機の送信したフレームを送信機が正常に受信できない場合でも、受信機からのフレームの再送を行うことが可能となり、信頼性の高い通信を行うことが可能となる。
また、受信機２１０１では、上記のように一括送信最終フラグが最終を示し、かつ同一の通し番号を持ったフレームを複数受信した場合は、２つめ以降のフレームについては、フレーム内データはすでにメモリ内に保存されているため、改めて保存しないように、制御部２１０２において制御してもよい。こうすることで、データの保存にかかる電力の消費を削減することが可能となる。
〔実施の第六形態〕
本実施の第六形態に係る転送データの転送システム（通信システム）について、図３７から図３９に基づいて説明すると以下の通りである。なお、他の実施の形態において定義した用語（部材及び機能を含む）については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。
本実施の形態では、送信機のブロック図として図３７、受信機のブロック図として図３８、信号のシークエンス図として図３９を用いて説明する。
図３７は、本実施の形態に係る送信機２３０１のブロック図である。なお、図３７は、送信機の構成の一例であり、これに限るものではない。また、各構成回路はソフトウェアであってもハードウェアであっても構わない。以下に各構成要素の説明を行う。
送信機（一次局、クライアント機器）２３０１は、送信データを送信する側の機器である。ここでいう送信データとは、例えばテキストデータ、画像データなどがあげられるが、これに限らない。また、対向局バッファサイズ解析回路（対向局バッファサイズ解析手段）２３１３以外の各構成要素は、上述した実施の第四形態における送信機２００１（図３１）の各構成要素と同一の機能を持つため、説明は省略する。
対向局バッファサイズ解析回路２３１３は、受信機２４０１（図３８）から受信したフレーム内に含まれるバッファサイズパラメータを解析し、解析結果を制御部２００２に通知する。
制御部２００２は、これを受けて一括送信最終フラグ生成回路２００４に対して、一括送信データサイズを、受信機２４０１のバッファサイズよりも小さな値に設定し、一括送信を行う。この受信機のバッファサイズは、一括送信を行う前に受信した方が望ましい。
図３８は、本実施の形態に係る受信機２４０１のブロック図である。なお、図３８は、受信機の構成の一例であり、これに限るものではない。また、各構成回路はソフトウェアであってもハードウェアであっても構わない。以下に各構成要素の説明を行う。
受信機（二次局、サーバ機器）２４０１は、対向機器からの送信データを受信する側の機器である。ここでいう送信データとは、例えばテキストデータ、画像データなどがあげられるが、これに限らない。また、バッファサイズ生成回路（バッファサイズ生成手段）２４１３以外の各構成要素は、上述した実施の第四形態における受信機２１０１（図３２）の各構成要素と同一の機能を持つため、説明は省略する。
制御部２１０２は、受信機２４０１が一括で受信可能なバッファのサイズをバッファサイズ生成回路２４１３に渡す。
バッファサイズ生成回路２４１３は、制御部２１０２から渡されたバッファサイズを予め定められたフォーマットにより生成し、送信フレーム生成回路２１０６に渡す。
送信フレーム生成回路２１０６は、前記バッファサイズを送信フレーム内に配置し、送信を行う。なお、前記バッファサイズを含むフレームは、一括送信を送信機が行う前に、送信機に対して送信するのが望ましく、例えば接続時に送信されるフレーム内に前記バッファサイズを配置して送信するのが望ましいが、これに限らない。
つづいて、図３９のシークエンス図を参照しながら、本実施の形態における各信号の流れを説明する。
受信機２４０１の制御部２１０２は、例えば接続時に、バッファサイズ生成回路２４１３に対して、受信機２１０１が一括で受信可能なバッファサイズを通知する。
これを受けたバッファサイズ生成回路２４１３は、予め定められたフォーマットにより、バッファサイズパラメータを生成し、送信フレーム生成回路２１０６に渡す。
これを受けた送信フレーム生成回路２１０６は、予め定められたフォーマットにより、前記バッファサイズパラメータを送信フレーム内に配置し、送信する。これが図３９のｔ４０８のフレームである。
送信機２３０１がｔ４０１にて、受信機２４０１のバッファサイズパラメータを含むフレームを受信すると、受信フレーム解析回路２００９にて、バッファサイズパラメータが抽出され、対向局バッファサイズ解析回路２３１３に渡される。
対向局バッファサイズ解析回路２３１３では、バッファサイズパラメータを解析し、解析結果を制御部２００２に通知する。
制御部２００２は、解析されたバッファサイズ以下のサイズを一括送信データサイズとして設定し、一括送信最終フラグ生成回路２００４へと渡す。
一括送信最終フラグ生成回路２００４は、制御部２００２より渡された一括送信データサイズを元に、一括送信最終フラグを設定し、一括送信を行う。
上記のようにすることで、受信機２４０１が一括で受信可能なバッファサイズを送信機２３０１に通知することが可能となり、また送信機２３０１により、受信機２４０１からの一括受信可能バッファサイズを元に一括送信データサイズを再計算し、一括送信最終フラグの制御に反映させることで、受信機２４０１の一括受信可能バッファサイズを越えた一括送信を送信機２３０１が行うことを未然に防ぐことが可能となる。
また、事前に一括受信可能バッファサイズのデフォルト値を送信機２３０１と受信機２４０１の間で定めておき、また、一括受信可能バッファサイズを送信機２３０１が受信していない場合は、デフォルトの値が採用されると定めておくことで、受信機２４０１において、一括受信可能バッファサイズのデフォルト値が受信機２４０１の一括受信可能バッファサイズ以下であるならば、一括受信可能バッファサイズを送信機２３０１に通知しなくとも、送信機２３０１がデフォルトの一括受信可能バッファサイズを用いて、一括送信を行うようにすれば、やはり受信機の一括受信可能バッファサイズを超えた一括送信を送信機が行うことを未然に防ぐことが可能となる。また、この場合は、受信機２４０１が送信機２３０１に一括送信可能バッファサイズを通知するためのフレームを送信する必要がなくなり、帯域の効率化につながる。
〔実施の第七形態〕
本実施の第七形態に係る転送データの転送システム（通信システム）について、図４０から図４２に基づいて説明すると以下の通りである。なお、他の実施の形態において定義した用語（部材及び機能を含む）については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。
本実施の形態では、送信機のブロック図として図４０、受信機のブロック図として図４１、信号のシークエンス図として図４２を用いて説明する。
図４０は、本実施の形態に係る送信機２５０１のブロック図である。なお、図４０は、送信機の構成の一例であり、これに限るものではない。また、各構成回路はソフトウェアであってもハードウェアであっても構わない。以下に各構成要素の説明を行う。
送信機（一次局、クライアント機器）２５０１は、送信データを送信する側の機器である。ここでいう送信データとは、例えばテキストデータ、画像データなどがあげられるが、これに限らない。また、データ最終フラグ生成回路（データ最終フラグ生成手段）２５１３以外の各構成要素は、上述した実施の第四形態における送信機２００１（図３１）の各構成要素と同一の機能を持つため、説明は省略する。
データ最終フラグ生成回路２５１３は、送信フレームに送信データの最終が含まれるかどうかを判別し、最終データが含まれる場合は、その意味を示す予め定められたフォーマットにより、データ最終フラグを生成し、また、最終データが含まれない場合は、その意味を示す予め定められたフォーマットにより、データ最終フラグを生成し、送信フレーム生成回路２００６に渡す。
送信機２５０１の制御部２００２は、送信フレームを生成する際に、データ最終フラグ生成回路２５１３に対して、送信フレーム生成回路２００６にて送信フレームに配置されるデータが送信データの最終データがそうでないかを通知する。
データ最終フラグ生成回路２５１３は、これを受けて、予め定められたフォーマットにより、データ最終フラグを生成し、送信フレーム生成回路２００６に渡す。本実施の形態においては、ＤＬ（Ｄａｔａ Ｌａｓｔ）という略語を定義し、ＤＬが０の場合は、送信データの最終データがフレーム内に含まれていない、またＤＬが１の場合は、送信データの最終データが含まれていることを意味する。本実施の形態においては、ＤＬという略語で表現しているが、別の表現であっても構わない。また、送信データの最終データを含むフレームを送信する場合にＤＬを１としているが、例えば、対向局からレスポンスとして、ある種のレスポンスデータを必要とする場合は、本フラグは、レスポンス要求フラグとしての意味を持ち、その意味で、本フラグがレスポンス要求フラグとして、本実施の形態における送信データの最終データを意味するフラグＤＬと同様の動作を行うものであるならば、本フラグは、レスポンス要求フラグであってもよい。
送信フレーム生成回路２００６は、データ最終フラグおよび一括送信最終フラグ、通し番号、データを送信フレーム内に配置し、送信部２００７を介して、送信する。
図４２のシークエンス図においては、ｔ５０１、ｔ５０２、ｔ５０３、ｔ５０４のフレームはデータ最終フラグＤＬが０で、フレーム内に送信データの最終データが含まれておらず、ｔ５０５のフレームはデータ最終フラグＤＬが１で、フレーム内に送信データの最終データが含まれていることを示している。
次に、図４１は、本実施の形態に係る受信機２６０１のブロック図である。なお、図４１は、受信機の構成の一例であり、これに限るものではない。また、各構成回路はソフトウェアであってもハードウェアであっても構わない。以下に各構成要素の説明を行う。
受信機（二次局、サーバ機器）２６０１は、対向機器からの送信データを受信する側の機器である。ここでいう送信データとは、例えばテキストデータ、画像データなどがあげられるが、これに限らない。また、データ最終フラグ解析回路（データ最終フラグ解析手段）２６１３以外の各構成要素は、上述した実施の第四形態における受信機２１０１（図３２）の各構成要素と同一の機能を持つため、説明は省略する。
データ最終フラグ解析回路２６１３は、受信フレーム内に配置されたデータ最終フラグを解析し、受信フレームに送信機が送信する送信データの最終データが含まれているかどうかを制御部２１０２へと通知する。
受信機２６０１では、受信部２１０８を介して受信した受信フレームは、受信フレーム解析回路２１０９にて、データ最終フラグが抽出され、データ最終フラグ解析回路２６１３に渡される。また、同時に一括送信最終フラグ、通し番号も抽出され、各解析回路にて解析される。
データ最終フラグ解析回路２６１３では、受信フレーム中に、送信機２５０１の送信データの最終データが含まれるかどうかが解析され、その結果が制御部２１０２へと通知される。
制御部２１０２では、送信機２５０１の送信データの最終データが含まれている場合、予め定められた処理（例えば、受信データが圧縮されＪＰＥＧ（Ｊｏｉｎｔ Ｐｈｏｔｏｇｒａｐｈｉｃ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）データである場合、ＪＰＥＧのデコードを開始するなど）を開始するなどの処理を行うことが可能である。
また、送信データの最終データを含むフレームにおいて、一括送信最終フラグが最終を示している場合は、エラー無しフラグを適当な値に設定し、送信を行うことが可能となる。
また、このとき、送信機２５０１からの送信データに対して、レスポンスデータを返す必要がある場合は、データを送信フレームに配置するときに、合わせてエラー無しフラグを配置して送信することで、帯域の効率化を図ることが可能となる。これが、図４２のｔ５１２のフレームとなる。
このフレームｔ５１２をｔ５０６にて受信した送信機２５０１は、受信フレーム内のデータを解析することにより、受信機２６０１からのレスポンスデータを受信することが可能となる。
〔実施の第八形態〕
本実施の第八形態に係る転送データの転送システム（通信システム）について、図４３に基づいて説明すると以下の通りである。なお、他の実施の形態において定義した用語（部材及び機能を含む）については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。なお、本実施の形態に係るシークエンスは、上述した送信機２００１（図３１）、受信機２１０１（図３２）、送信機２２０１（図３４）、受信機２３０１（図３７）、受信機２４０１（図３８）、送信機２５０１（図４０）、受信機２６０１（図４１）に実装可能な付加的な機能である。
図４３は、本実施の形態に係るシークエンス図である。
本実施の形態においては、送信機と受信機の間では、ウィンドウサイズの制限のない通信方式として、ＩｒＤＡ（Ｉｎｆｒａｒｅｄ Ｄａｔａ Ａｓｓｏｃｉａｔｉｏｎ）のＩｒＬＡＰ（Ｉｎｆｒａｒｅｄ Ｌｉｎｋ Ａｃｃｅｓｓ ｐｒｏｔｏｃｏｌ）のＵＩ（Ｕｎｎｕｍｂｅｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ）フレームを用いて、通信を行う。また、送信機および受信機はＯＢＥＸ（Ｏｂｊｅｃｔ Ｅｘｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ）をサポートしており、Ｐｕｔオペレーションによりデータを送信するものとする。
図４３においては、ＯＢＥＸのＰｕｔ Ｆｉｎａｌコマンドに送信データが配置され、ＩｒＬＡＰのＵＩフレームを用いて、フレーム送信が行われる。
Ｐｕｔ Ｆｉｎａｌコマンドは、ｄａｔａ０からｄａｔａ７によって構成され、ｄａｔａ０からｄａｔａ７を全て連結するとＰｕｔ Ｆｉｎａｌコマンドとなるように分割されている。
また、送信機の一括送信データサイズは、ｄａｔａ０からｄａｔａ３を連結したサイズであり、通し番号が３になった時点で、一括送信最終フラグＢＬを１としたフレームｔ６０４を送信する。このとき、ＯＢＥＸのＰｕｔ Ｆｉｎａｌコマンドで構成された送信データの最終データであるｄａｔａ７は、送信フレームに含まれていないため、データ最終フラグＤＬは０である。
ｔ６１４にて前記一括送信最終フラグＢＬが１のフレームを受信した受信機は、それまでの受信フレームにエラーが検出されなかったため、エラー無しフラグをエラー無しとし、ｔ６１５にて送信する。また、受信したフレームのデータ最終フラグが０であるため、この時点では、ＯＢＥＸのＰｕｔ Ｆｉｎａｌコマンドに対する正常受信を意味するＳＵＣＣＥＳＳレスポンスは送信フレームには含まれない。
ｔ６０５にて、前記エラー無しフラグがエラー無しを示すフレームを受信した送信機は、受信機が通し番号０から３の一括送信を正常受信したと判断し、引き続きｄａｔａ４からｄａｔａ７を一括送信する。ｔ６０９にて通し番号７のフレーム送信を行う際には、一括送信最終フラグを１としている。また、ｔ６０９にて通し番号７のフレームには、送信データの最終データであるｄａｔａ７が含まれるため、データ最終フラグＤＬを１としている。
ｔ６１９にて、データ最終フラグが１のフレームを受信した受信機は、通し番号４から７のフレームを正常に受信しており、また、送信機からのＰｕｔ Ｆｉｎａｌコマンドを全て正常受信できたため、Ｐｕｔ Ｆｉｎａｌコマンドに対する正常受信を意味するＳＵＣＣＥＳＳレスポンスを生成する。また、一括送信最終フラグが１であるため、ＳＵＣＣＥＳＳレスポンスに合わせて、エラー無しフラグをエラー無しの意味とし、ｔ６２０にて合わせて送信する。
ｔ６１０にて、前記エラー無しフラグがエラー無しを示すフレームを受信した送信機は、通し番号４から通し番号７までの一括送信が正常に終了したことを認識するとともに、前記受信フレーム内に、送信機が送信したＰｕｔ Ｆｉｎａｌコマンドに対するＳＵＣＣＥＳＳレスポンスが含まれているため、Ｐｕｔオペレーションも正常に終了したことを認識することが可能となる。
以上のように、本実施の形態の通信方法によれば、ウィンドウサイズの制限のないＩｒＬＡＰのＵＩフレームを用いた場合でも、送信機と受信機の間で、通信の確認およびデータの交換が確実に行われることが可能となる。
〔実施の第九形態〕
本実施の第九形態に係る転送データの転送システム（通信システム）について、図４４から図４６に基づいて説明すると以下の通りである。なお、他の実施の形態において定義した用語（部材及び機能を含む）については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。
本実施の形態では、送信機のブロック図として図４４、受信機のブロック図として図４５、信号のシークエンス図として図４６を用いて説明する。
図４４は、本実施の形態に係る送信機２７０１のブロック図である。図４４は、送信機の構成の一例であり、これに限るものではない。また、各構成回路はソフトウェアであってもハードウェアであっても構わない。以下に各構成要素の説明を行う。
送信機２７０１は、送信データを送信する側の機器である。ここでいう送信データとは、例えばテキストデータ、画像データなどがあげられるが、これに限らない。
図４４に示すように、送信機（一次局、クライアント機器）２７０１は、制御部（制御手段）２７０２、メモリ（記憶手段）２７０３、通し番号生成回路（通し番号生成手段）２７０５、送信フレーム生成回路（送信フレーム生成手段）２７０６、送信部（送信手段）２７０７、データ最終フラグ生成回路（データ最終フラグ生成手段）２７１３を備えて構成されている。
制御部２７０２は、送信機２７０１の各構成要素の制御を行う。
メモリ２７０３には送信データが蓄えられる。このメモリ２７０３は、揮発性のメモリ（例えばＳＤＲＡＭなど）であっても、不揮発性のメモリ（例えばフラッシュメモリ、ＨＤＤ、ＤＶＤなど）であってもよい。また、図４４では、メモリ２７０３は、送信機２７０１に配置されているが、必ずしも送信機２７０１内に存在する必要はなく、送信機２７０１の外部メモリとして送信機２７０１に接続されていても構わない。
通し番号生成回路２７０５は、予め定められたルールに従って、通し番号を増減し、各送信フレームに付与する回路である。本実施の形態においては、ＳＥＱ（Ｓｅｑｕｅｎｃｅｎｕｍｂｅｒ）という略語を定義し、ＳＥＱが１である場合は、通し番号が１であることを示している。図４６のシークエンス図においても、同様の意味でＳＥＱという略語を用いている。
データ最終フラグ生成回路２７１３は、送信フレームに送信データの最終が含まれるかどうかを判別し、最終データが含まれる場合は、その意味を示す予め定められたフォーマットにより、データ最終フラグを生成し、また、最終データが含まれない場合は、その意味を示す予め定められたフォーマットにより、データ最終フラグを生成し、送信フレーム生成回路２７０６に渡す。本実施の形態においては、ＤＬ（Ｄａｔａ Ｌａｓｔ）という略語を定義し、ＤＬが０の場合は、送信データの最終データがフレーム内に含まれていない、またＤＬが１の場合は、送信データの最終データが含まれていることを意味する。なお、本実施の形態においては、ＤＬという略語で表現しているが、別の表現であっても構わない。また、送信機２７０１と受信機２８０１の間で、事前に取り決めが行われているならば、本データ最終フラグは、必ずしも送信データの最終データを含む送信フレームにおいてのみ、最終を示す値をとる必要はなく、予め定められたルールに従い、例えば、送信データの最終データでない特定のデータを送信する際に、本データ最終フラグを最終を示す値に設定してもよい。その際は、データ最終フラグと異なる名称となる可能性もある。本実施の形態においては、データ最終フラグとしてＤＬという略語を用いることとする。
送信フレーム生成回路２７０６は、予め定められたフォーマットにより、送信フレームを生成する回路である。前述のデータ最終フラグＤＬ、通し番号ＳＥＱ、送信データを予め定められたフォーマットにしたがって配置し、送信フレームを生成する。なお、本発明においては、ウィンドウサイズの制限がない通信方式を用いているため、ウィンドウサイズの制限がないフレームフォーマットでの送信フレームを生成する。本実施の形態においては、ＩｒＬＡＰ（Ｉｎｆｒａｒｅｄ Ｌｉｎｋ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）におけるＵＩ（Ｕｎｎｕｍｂｅｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ）フレームを用いる。また、対向局がエラー検出を行うためのエラー検出符号も合わせて付加される。エラー検出符号としては、例えばＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）などがあるがこれに限らない。また、エラー訂正符号が付加されてもよい。
送信部２７０７は、送信フレーム生成回路２７０６によって生成された送信フレームを送信する回路である。例えば、通信媒体として赤外線を用いるならば、ＬＥＤ（発光ダイオード）やＬＤ（レーザダイオード）となるが、これに限らない。また、他の通信媒体を用いる場合は、その通信媒体に応じた送信部となる。
図４５は、本実施の形態に係る受信機２８０１のブロック図である。図４５は、受信機の構成の一例であり、これに限るものではない。また、各構成回路はソフトウェアであってもハードウェアであっても構わない。以下に各構成要素の説明を行う。
受信機２８０１は、対向機器からの送信データを受信する側の機器である。ここでいう送信データとは、例えばテキストデータ、画像データなどがあげられるが、これに限らない。
図４５に示すように、受信機（二次局、サーバ機器）２８０１は、制御部（制御手段）２８０２、メモリ（記憶手段）２８０３、受信部（受信手段）２８０８、受信フレーム解析回路（受信フレーム解析手段）２８０９、エラー検出回路（エラー検出手段）２８１１、通し番号解析回路（通し番号解析手段）２８１２、データ最終フラグ解析回路（データ最終フラグ解析手段）２８１３を備えて構成されている。
制御部２８０２は、受信機２８０１の各構成要素の制御を行う。
メモリ２８０３には受信データが蓄えられる。このメモリ２８０３は、揮発性のメモリ（例えばＳＤＲＡＭなど）であっても、不揮発性のメモリ（例えばフラッシュメモリ、ＨＤＤ、ＤＶＤなど）であってもよい。また、図４５では、メモリ２８０３は、受信機２８０１内に配置されているが、必ずしも受信機２８０１内に存在する必要はなく、受信機２８０１の外部メモリとして受信機２８０１に接続されていても構わない。
受信部２８０８は、対向局が送信したフレームを受信する回路である。例えば、通信媒体として赤外線を用いるならば、ＰＤ（フォトダイオード）となるが、これに限らない。また、他の通信媒体を用いる場合は、その通信媒体に応じた受信部となる。
受信フレーム解析回路２８０９は、受信部２８０８により受信した受信フレームの解析を行う。具体的には、受信フレーム内のデータ最終フラグを抽出し、データ最終フラグ解析回路２８１３に渡す。また、受信フレーム内の通し番号を抽出し、通し番号解析回路２８１２に渡す。また、受信フレーム内にデータが存在する場合は、データを抽出し、制御部２８０２を介して、メモリ２８０３に保存する。メモリ２８０３にデータを保存する場合は、必ずしも制御部２８０２を介さなくてもよい。
エラー検出回路２８１１は、受信フレームに付与されているエラー検出用の符号を解析し、受信フレームにエラーがないかどうかを判別し、解析結果を制御部２８０２に通知する。エラー検出用の符号として、例えば、ＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）符号などの巡回符号があげられるが、これに限らない。また、エラー訂正符号が付与されている場合は、エラー訂正を行うこととなる。
通し番号解析回路２８１２は、受信フレーム内に付与されている通し番号が予め定められたルールによって増減しているかどうかを解析し、解析結果を制御部２８０２に通知する。例えば、通信路において、フレームが抜けた場合などは、この通し番号解析回路２８１２によりエラーと判断される。
データ最終フラグ解析回路２８１３は、受信フレーム解析回路２８０９により渡されたデータ最終フラグを解析し、解析結果を制御部２８０２に通知する。
つづいて、図４４、図４５、および図４６のシークエンス図を参照しながら、本実施の形態における各信号の流れを説明する。なお、送信機２７０１および受信機２８０１はＯＢＥＸ（Ｏｂｊｅｃｔ Ｅｘｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ）をサポートしており、Ｐｕｔオペレーションによりデータを送信するものとする。
図４６においては、ＯＢＥＸのＰｕｔ Ｆｉｎａｌコマンドに送信データが配置され、ＩｒＬＡＰのＵＩフレームを用いて、フレーム送信が行われる。
Ｐｕｔ Ｆｉｎａｌコマンドは、ｄａｔａ０からｄａｔａ７によって構成され、ｄａｔａ０からｄａｔａ７を全て連結するとＰｕｔ Ｆｉｎａｌコマンドとなるように分割されている。また、ｄａｔａ７がＰｕｔ Ｆｉｎａｌコマンドの最終データである。
送信機２７０１では、自機器内もしくは外部から送信データの転送要求が発生すると、制御部２７０２が通し番号生成回路２７０５に対して通し番号の生成を通知する。また、データ最終フラグ生成回路２７１３に対してデータ最終フラグの生成を通知する。
通し番号生成回路２７０５は、予め定められたルールにより通し番号を増減し、送信フレーム生成回路２００６に渡す。
また、データ最終フラグ生成回路２７１３は、送信フレームに送信データの最終データが含まれるかどうかを判別し、含まれる場合は最終を示し、含まれない場合は、最終でないを示す予め定められたフォーマットによるデータ最終フラグを作成し、送信フレーム生成回路２７０６に渡す。
送信フレーム生成回路２７０６は、前記データ最終フラグ、通し番号、データを予め定められたフォーマットにより配置し、送信部２７０６を介して送信する。
図４６においては、ｔ７０１、ｔ７０２、ｔ７０３、ｔ７０４、ｔ７０５、ｔ７０６、ｔ７０７がデータ最終フラグが最終でないフレーム、ｔ７０８がデータ最終フラグが最終のフレームである。ｔ７０１からｔ７０８の各フレーム内の通し番号（ＳＥＱ）は、本実施の形態においては、１ずつ増えていくものとして記述している。
次に、受信機２８０１では、対向局からフレームを受信部２８０８を介して受信すると、受信フレーム解析回路２８０９にて受信フレーム内の各パラメータを抽出する。前記パラメータとは、例えばデータ最終フラグ、通し番号、データなどであり、データ最終フラグは、データ最終フラグ解析回路２８１３に渡され、通し番号は通し番号解析回路２８１２に渡され、データは、必要ならば、制御部２８０２を介して、メモリ２８０３に保存される。また、同時にエラー検出回路２８１１により、受信フレームにて、例えばＣＲＣエラーがないかどうかのエラー検出が行われる。エラー検出もしくはエラー訂正符号がＣＲＣ符号以外の場合は、それに従ったエラー検出もしくはエラー訂正が行われる。
また、データ最終フラグ解析回路２８１３では、データ最終フラグの解析を行い、解析結果を通知する。図４６のシークエンス図においては、ｔ７０１、ｔ７０２、ｔ７０３、ｔ７０４、ｔ７０５、ｔ７０６、ｔ７０７のフレーム受信時は、データ最終フラグは最終でなく、ｔ７０８のフレーム受信時は、データ最終フラグを最終としてそれぞれ制御部２８０２に通知される。
また、通し番号解析回路２８１２においては、受信フレーム中の通し番号が予め定められたルールに従って、増減されているかどうかを解析し、解析結果を制御部２８０２に通知する。本実施の形態では、前記予め定められたルールとして通し番号はフレームごとに１ずつ増加することとしている。図４６のシークエンス図においては、送信機２７０１が送信した８つのフレームは、全て正常受信し、送信機２７０１との間で予め通し番号は１ずつ増えていくと定められている状態で、全てのフレームの通し番号が１つ前のフレームの通し番号と比べて１だけ増加しているため、全ての受信フレームにおいて、正常受信として、受信機２８０１の制御部２８０２に通知される。
制御部２８０２では、全ての受信フレームにおいて、エラーが検出されず、またデータ最終フラグを含むフレームを受信した場合は、予め定められた処理（例えば、受信データが圧縮されたＪＰＥＧデータである場合、ＪＰＥＧのデコードを開始するなど）を開始するなどの処理を行うことが可能である。
また、受信機２８０１において、エラー検出回路２８１１および通し番号検出回路２８１２により、受信フレームにエラーがあることが検出された場合、以降のデータをメモリ２１０３に保存する処理を行わないとしてもよい。こうすることにより、エラーが検出された場合の以降のデータ保存にかかる消費電力の削減が可能となる。
以上のように、送信機２７０１および受信機２８０１によれは、ウィンドウサイズの制限のないＩｒＬＡＰのＵＩフレームを用いた通信方式において、片方向通信においても、フレームの抜けを検出することが可能となり、信頼性の高い通信を行うことが可能となる。また、片方向通信時には、送信機２７０１において、ＯＢＥＸのＰｕｔ Ｆｉｎａｌコマンドに対するＳＵＣＣＥＳＳレスポンスの受信ができないが、送信機２７０１の制御部２７０２において、片方向通信時には、Ｐｕｔ Ｆｉｎａｌを送信完了した時点で、Ｐｕｔオペレーションの終了を行うように定めていれば、片方向通信においても、Ｐｕｔオペレーションによるデータ転送を正常に行うことが可能となる。
〔実施の第十形態〕
本実施の第十形態に係る転送データの転送システム（通信システム）について、図４７から図５１に基づいて説明すると以下の通りである。なお、他の実施の形態において定義した用語（部材及び機能を含む）については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。
本実施の形態では、一括して送信するデータのサイズの決め方について説明する。本発明の通信システムでは、送信機が一括して送信する一括送信データのサイズを、データの再送および受信機でのデータ処理に都合の良いように決めることができる。なお、一括送信データのサイズは、送信するデータの種類や通信路の状態等に応じて、送信機のアプリケーション等が決定してもよいし、受信機から一括送信データのサイズあるいは該サイズを決定するための情報（例えば、受信機のバッファサイズ）を送信機に送信してもよい。
また、データの分割は、通常ＳＭＰ層が行うが、その他の層において行ってもよい。
本実施の形態では、一例として、ＪＰＥＧ画像を転送する場合について記述する。
図４７は、送信機におけるＪＰＥＧエンコーダおよび受信機におけるＪＰＥＧデコーダの構成を示すブロック図である。
図４７に示すように、ＪＰＥＧ画像を転送する際には、送信機のＪＰＥＧエンコーダ９１において、まず原画像をブロック（ｍｃｕ：ｍｉｎｉｍｕｍ ｃｏｄｅｄ ｕｎｉｔ）単位でＤＣＴ変換を行う。ｍｃｕとは、ＪＰＥＧ変換を行ううえでの最小単位であり、圧縮方式により、８×８、８×１６、１６×８、１６×１６の４種類がある（図４８（ａ）〜（ｄ））。
８×８（図４８（ａ））では、すべての画素において、輝度成分（Ｙ）、色度成分（Ｃｂ、Ｃｒ）が１対１の関係となる。８×１６（図４８（ｂ））では、１つの縦長の単位内（１）にＹが２つ（８×８における１と９に相当）とＣｂ（８×８における１と９の平均）、Ｃｒ（８×８における１と９の平均）がそれぞれ１つずつ入っている。１６×８（図４８（ｃ））では、１つの横長の単位内にＹが２つ（８×８における１と２に相当）と、Ｃｂ（８×８における１と２の平均）、Ｃｒ（８×８における１と２の平均）がそれぞれ１つずつ入っている。１６×１６（図４８（ｄ））では、１つの単位内（１）にＹが４つ（８×８における１、２、９、１０に相当）とＣｂ（８×８における１、２、９、１６の平均）、Ｃｒ（８×８における１、２、９、１６の平均）がそれぞれ１つずつ入っている。
上述のように、８×８が最も圧縮率が低く、復号後の画像が原画像と近くなるがデータ量が多くなる。これは一般に４：４；４と呼ばれている。また、１６×１６ブロックが最も圧縮率が高く、データ量が少なくなるが、平均している部分が多くなるため、原画像と異なる復号画像が得られる可能性が高くなる。
そして、ＤＣＴ変換においては、前述のブロック単位での入力を元に、ＤＣＴ変換（離散コサイン変換）を行う。この変換は、２次元マトリクスの乗算として計算され、ブロック内の画素数と同じ数である６４個の変換係数が得られる。得られた変換係数は、左上に近いほど、周波数成分が低くなり、右下に近いほど、周波数成分が高くなる。一般に画像は、隣接する画素との相関が大きいため、周波数成分の高い変換係数ほど、出現確率は少なくなる。
次に、量子化においては、前述の変換係数を予め定められた量子化テーブルにより除算する。前述のとおり、一般的に周波数の高い変換係数の出現確率は低いため、変換テーブルの周波数の高い部分を大きくすると、周波数成分の高い変換係数は、量子化を行うことによりほとんどが０となる。
最後に、エントロピー符号化においては、予め定められたエントロピー符号化テーブルを元にエントロピー符号化を行う。前述の通り、量子化により０に変換された変換係数は、エントロピー符号化により０の連続数として表現され、この時点で圧縮が可能となる。つまり、原画像において、周波数成分が低い（隣接する色の変化が激しくない）画像は、ＪＰＥＧ圧縮の圧縮効率が高くなる傾向がある。
そして、エントロピー符号化された画像データが、通信路に伝送される。
一方、通信路から前述のエントロピー符号化された画像データを受信した受信機では、ＪＰＥＧデコーダ９２において、送信機で行われた作業と全く逆の作業を行うことにより、ＪＰＥＧ復号を行う。
まず、エントロピー復号化において、予め定められたエントロピー符号化テーブルを元にエントロピー復号を行う。そして、エントロピー復号を行って得られたデータは、逆量子化により、予め定められた逆量子化テーブルを用いて、逆量子化される。逆量子化後のデータは、逆ＤＣＴ変換により、輝度成分Ｙ、色度成分Ｃｂ、Ｃｒに変換される。また、このとき、８×８、８×１６、１６×８、１６×１６それぞれの圧縮方式によって、輝度成分Ｙ、平均化された色度成分Ｃｂ、Ｃｒを用いて、画像が復元される。
上述のように、ＪＰＥＧ画像の転送においては、圧縮画像生成、復号において、ブロック単位（ｍｃｕ）単位で、データの処理が行われている。また、復号後の表示においては、前述のｍｃｕが１列分並んだ１ライン単位での処理や、１フレーム単位（１画像単位）での処理を行うことで都合がよいことがある。これは、映像信号において、１ラインごとに水平同期信号が存在し、また１フレームごとに垂直同期信号が存在し、それらの同期信号ごとに、ラインバッファや、フレームバッファを更新することで、ビデオメモリの更新タイミングを処理することが可能となるからである。なお、このことは、ブロック単位での処理を行うＭＰＥＧなどの動画処理においても同様である。
つづいて、データの分割再送処理の具体例として、ｍｃｕ単位で分割再送する場合、ライン単位で分割再送する場合、ファイル単位で分割再送する場合について、それぞれ説明する。
図４９は、本発明の通信システムにおけるｍｃｕ単位での分割、再送処理の説明図である。
送信機では、前述のＤＣＴ、量子化、エントロピー符号化を行ったｍｃｕ単位での転送を行っている。具体的には、ｍｃｕ１つ分のデータに相当する単位で送信用一時バッファにデータを転送し、送信用一時バッファのデータを転送し終えると、一括送信終了フラグを１としている。
受信機では、一括送信終了フラグが１であるフレームを受信するごとに、受信用一時バッファのデータを例えばアプリケーションに転送し、アプリケーションにおいてＪＰＥＧデコードする。
このようにｍｃｕ単位で分割再送を行う場合、送信機の送信用一時バッファおよび受信機の受信用一時バッファは、ｍｃｕ１つ分だけ（通常、数１０バイトから数百バイト程度）確保すればよい。それゆえ、一時的なメモリの確保が困難な通信機においては、有効な分割再送方式となる。
図５０は、本発明の通信システムにおけるライン単位での分割、再送処理の説明図である。
送信機では、送信用一時バッファに、１列分（８×８の場合、８ライン分に相当）のデータを転送し、１列分の送信が終わった時点で、一括送信終了フラグを１としている。
受信機では、一括送信終了フラグが１のフレームを受信した時点で、例えばアプリケーションに受信データを転送し、アプリケーションにおいてＪＰＥＧデコードを行う。
このようにライン単位で分割再送を行う場合、アプリケーションにデータが転送された時点で、１列分（８×８の場合、８ライン分）のデータがそろっていることになり、受信データを列単位で処理する場合での処理を簡略化することが可能となる。また、エラー発生時には、エラーが発生していない部分だけを表示する表示系においては、デコード後のデータが列単位であるため、列の途中で表示データが切れることがない。なお、この方式の場合、送信機の送信用一時バッファおよび受信機の受信用一時バッファは、数キロバイトから数百キロバイト程度が必要になると予想される。
図５１は、本発明の通信システムにおけるファイル単位での分割、再送処理の説明図である。
送信機では、送信用一時バッファに、送信画像１つ分を渡し、送信用一時バッファ内のデータを全て送信し終わった時点で、一括送信終了フラグを１としている。
受信側では、一括送信終了フラグが１のフレームを受信した時点で、例えばアプリケーションに受信データを渡し、アプリケーションにおいてＪＰＥＧデコード処理を行っている。
このようにファイル単位で分割再送を行う場合、画像１枚分のデータ単位での分割再送処理を行うことができるため、アプリケーションのＪＰＥＧデコーダでは、１枚の画像単位でのＪＰＥＧデコードを行うこととなり、１枚の画像のデコードが完了した時点で、表示用のフレームメモリを更新するなどの処理が簡単に行える。なお、この方式の場合、送信機の送信用一時バッファおよび受信機の受信用一時バッファは、数１００ｋＢから数ＭＢ程度となることが予想される。また、ＭＰＥＧなどのように、静止画像を連続して送信するような、処理系において、通信によりエラーが発生した場合に、直前の画像を完全な状態で表示し続けるなどの処理が簡単に行えるため、有効である。
また、受信機からの応答を待つ時間に関しては、一括送信終了フラグが１のフレームにエラーが発生した場合には、直ちに再送することが望ましい。ただし、エラーが発生しておらず、受信機での受信データの処理に時間がかかっている場合などのように、応答が返せない場合がある。その場合には、受信データ処理時間よりも大きいが、大きすぎないような時間を送信機が設定し、前述の時間を待っても応答が返ってこないときには、一括送信終了フラグが１のフレームを再送してもよい。これにより、受信機でのデータ処理時間が保証され、かつ最適な再送処理を行うことが可能となる。
〔実施の第十一形態〕
本発明の実施の第十一形態に係る転送データの転送システム（通信システム）のクライアント機器（通信装置）について説明すると以下のとおりである。なお、他の実施の形態において定義した用語（部材及び機能を含む）については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。
まず、図５２は、従来のＯＢＥＸプロトコルを用いて通信を行うクライアント機器のブロック図である。
図５２に示すように、従来のクライアント機器（通信装置）３２００は、アプリケーション層処理部３２１０と、ＯＢＥＸ層処理部（オブジェクト交換層処理部）３２２０と、下位層処理部３２３０と、送信部３２４０と、受信部３２５０とを少なくとも備えている。
アプリケーション層処理部３２１０は、図示しない操作部に入力された利用者の指示に応じて、ＯＢＥＸ層処理部３２２０に対して、要求コマンドの発行処理を要求する。
ＯＢＥＸ層処理部３２２０は、制御部３２２１と、要求通知部３２２２と、応答受信部３２２３とを備えている。
制御部３２２１は、アプリケーション層処理部３２１０からの要求に応じて、要求通知部３２２２に対して要求コマンドの生成および下位層へ要求コマンドの発行を行うよう通知する。また、応答受信部３２２３からの応答コマンド受信結果通知を受けて、アプリケーション層処理部３２１０へ応答コマンドの受信結果を通知する。
要求通知部３２２２は、制御部３２２１からの要求コマンド発行通知を受けて、要求コマンドを生成し、下位層処理部３２３０へ出力する。応答受信部３２２３は、下位層処理部３２３０から出力される応答コマンドを受信し、受信した応答コマンドの解析を行い、制御部３２２１に対して、コマンド解析結果および応答コマンドを受信した旨の通知を行う。
下位層処理部３２３０は、ＯＢＥＸ層処理部３２２０からの要求コマンドに適当な下位層のヘッダを付加して送信部３２４０に渡すとともに、受信部３２５０からの受信応答コマンドから、適当な下位層のヘッダを除去して、ＯＢＥＸ層処理部３２２０に渡す。
送信部３２４０は、赤外線通信路を介して、下位層処理部３２３０から受信した要求コマンドを外部に送信する。
受信部３２５０は、赤外線通信路を介して、相手機器（サーバ機器）から送信された応答コマンドを受信し、受信した応答コマンドを下位層処理部３２３０に出力する。
次に、図５３に示すフローチャートを用いて、図５２のＯＢＥＸ層処理部３２２０の制御部３２２１の動作を説明する。
ステップＳ５１は、クライアント機器３２００のアプリケーション層処理部３２１０およびＯＢＥＸ層処理部３２２０の制御部３２２１において、サーバ機器への要求コマンドが発生しているかどうかを判別するステップである。発生している場合は、ステップＳ５２へ、また発生していない場合は、再びステップＳ５１へそれぞれ遷移する。
ステップＳ５２は、サーバ機器への要求コマンドを下位層処理部３２３０へ送信するステップである。送信終了後、ステップＳ５３へと遷移する。
ステップＳ５３は、サーバ機器からの応答コマンドを下位層処理部３２３０から受信したがどうかを判別するステップである。受信した場合は、ステップＳ５４へ、また受信していない場合は、再びステップＳ５３へ、それぞれ遷移する。
ステップＳ５４は、受信した応答コマンドを解析するステップである。解析終了後、ステップＳ５５へと遷移する。
ステップＳ５５は、通信終了かどうかを判別するステップである。通信終了でない場合は、再びステップＳ５１へと遷移する。
以上の動作により、従来のクライアント機器３２００のＯＢＥＸ層処理部３２２０は、要求コマンドを発行し、それに対する応答コマンドを解析し、次の要求コマンドを再び発行することで通信を行うことが可能となる。
しかし、前述の従来のクライアント機器３２００のＯＢＥＸ層処理部３２２０の動作では、サーバ機器から応答コマンドを受信しない限り、次の要求コマンドの送信ができないといった問題がある。
これを解決するために、図５５のフローチャートに示すとおり、本実施の形態に係るクライアント機器３３００（図５４）では、サーバ機器へ要求コマンドを発行した後、サーバ機器からの応答コマンドを受信しなくとも次の要求コマンドを発行することを可能とする。具体的には以下のとおりとなる。
ステップＳ６１は、クライアント機器３３００のアプリケーション層処理部３３１０およびＯＢＥＸ層処理部３３２０の制御部３３２１において、サーバへの要求コマンドが発生しているかどうかを判別するステップである。発生している場合は、ステップＳ６２へ、また発生していない場合は、再びステップＳ６１へそれぞれ遷移する。
ステップＳ６２は、サーバ機器への要求コマンドを下位層処理部３３３０へと送信するステップである。送信終了後、ステップＳ６５へと遷移する。
ステップＳ６５は、通信終了かどうかを判別するステップである。通信終了でない場合は、再びステップＳ６１へと遷移する。
以上の動作をクライアント機器３３００のＯＢＥＸ層処理部３３２０の制御部３３２１が行うことにより、クライアント機器３３００から、要求コマンドを送信した後、サーバ機器からの応答コマンドを受信しなくても、次の要求コマンドを送信することが可能となる。
ここで、図５４は、本実施の形態に係るクライアント機器３３００のブロック図である。
ＯＢＥＸ層処理部（オブジェクト交換層処理部）３３２０の通信方向選択部３３２４以外の各ブロックは、図５２を用いて上述した従来のクライアント機器３２００のＯＢＥＸ層処理部３２２０の各ブロックと同じ機能を持つため説明を省略する。
通信方向選択部３３２４は、通信が片方向通信か双方向通信かを選択する機能を有する。ここでいう片方向通信とは、クライアント機器からの要求コマンドに対して、サーバ機器からの応答コマンドを必要としない通信である。サーバ機器に送信部が存在しない場合、もしくは、クライアント機器に受信部が存在しない場合は、必然的に片方向通信となるが、送信部と受信部をクライアント機器およびサーバ機器がそれぞれ有しているが、信号の流れがクライアント機器からサーバ機器への片方向である場合は、やはり片方向通信となる。また、双方向通信とは、クライアント機器から送信された要求コマンドに対して、応答コマンドをサーバ機器が送信し、前記応答コマンドの解析後に、再びクライアント機器が次の要求コマンドを送信する通信方式である。この場合、すべての要求コマンドに対して、応答コマンドが必要になるわけでなく、クライアント機器のＯＢＥＸ層とサーバ機器のＯＢＥＸ層の双方で、事前に取り決めがなされていれば、特定の要求コマンドに対する応答コマンドは必ずしも必要でない。
次に、図５６のフローチャートを用いて、本実施の形態に係るクライアント機器３３００のＯＢＥＸ層処理部３３２０の制御部３３２１の動作を説明する。
ステップＳ７０は、通信方向選択部３３２４にて、双方向通信か片方向通信かを選択するステップである。双方向通信の場合は、ステップＳ７１へ、また片方向通信の場合は、Ｓ８１へそれぞれ遷移する。
ステップＳ７１は、双方向通信において、アプリケーション層処理部３３１０もしくはＯＢＥＸ層処理部３３２０の制御部３３２１において、サーバ機器への要求コマンドが発生しているかどうかを判別するステップである。発生している場合は、ステップＳ７２へ、発生していない場合は、再びステップＳ７１へそれぞれ遷移する。
ステップＳ７２は、双方向通信において、サーバ機器への要求コマンドを下位層処理部３３３０へ送信するステップである。送信終了後、ステップＳ７３へ遷移する。
ステップＳ７３は、双方向通信において、サーバ機器からの応答コマンドを受信したかどうかを判別するステップである。受信した場合は、ステップＳ７４へ、受信していない場合は、再びステップＳ７３へそれぞれ遷移する。
ステップＳ７４は、双方向通信において、サーバ機器からの応答コマンドを解析するステップである。解析終了後、ステップＳ７５へ遷移する。
ステップＳ７５は、双方向通信において、通信を終了するかどうかを判別するステップである。終了でない場合は、ステップＳ７１へ再び遷移する。
一方、ステップＳ８１は、片方向通信において、アプリケーション層処理部３３１０もしくはＯＢＥＸ層処理部３３２０の制御部３３２１において、サーバ機器への要求コマンドが発生しているかどうかを判別するステップである。発生している場合は、ステップＳ８２へ、発生していない場合は、再びステップＳ８１へそれぞれ遷移する。
ステップＳ８２は、片方向通信において、サーバ機器への要求コマンドを下位層処理部３３３０へ送信するステップである。送信終了後、ステップＳ８５へ遷移する。
ステップＳ８５は、片方向通信において、通信を終了するかどうかを判別するステップである。終了でない場合は、ステップＳ８１へ再び遷移する。
以上の動作を、クライアント機器３３００のＯＢＥＸ層処理部３３２０の制御部３３２１が行うことにより、双方向通信では、サーバ機器からの応答コマンドを待ってから次の要求コマンドを送信し、片方向通信では、サーバ機器からの応答コマンドを受信しなくても次の要求コマンドを送信することが可能となる。
〔実施の第十二形態〕
本発明の実施の第十二形態に係る転送データの転送システム（通信システム）のクライアント機器（通信装置）について説明すると以下のとおりである。なお、他の実施の形態において定義した用語（部材及び機能を含む）については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。
図５４が本実施の形態のクライアント機器３３００のブロック図である。すなわち、上述した実施の第十一形態と同一であり、また、ＯＢＥＸ層処理部３３２０の制御部３３２１以外の各ブロックの動作も基本的に実施の第十一形態における各ブロックの動作と同じであるため、説明を省略する。
図５７に示すフローチャートを用いて、本実施の形態に係るＯＢＥＸ層処理部３３２０の制御部３３２１の動作を説明する。
ステップＳ９１は、アプリケーション層処理部３３１０もしくはＯＢＥＸ層処理部３３２０の制御部３３２１において、サーバ機器へのＰｕｔ要求コマンドが発生しているかどうかを判別するステップである。発生している場合は、ステップＳ９２へ、発生していない場合は、再びステップＳ９１へそれぞれ遷移する。
ステップＳ９２は、サーバ機器へＰｕｔ要求コマンドを送信するステップである。送信終了後、ステップＳ９３へ遷移する。
ステップＳ９３は、送信したＰｕｔ要求コマンドが最終のＰｕｔ要求コマンドがそうでないかを判別するステップである。最終である場合は、ステップＳ９４へ、また最終でない場合は、ステップＳ９１へそれぞれ遷移する。
ステップＳ９４は、サーバ機器からの応答コマンドを受信したかどうかを判別するステップである。受信した場合は、ステップＳ９５へ、受信していない場合は、再びステップＳ９４へそれぞれ遷移する。
ステップＳ９５は、サーバ機器からの応答コマンドを解析するステップである。解析終了後、ステップＳ９６へと遷移する。このとき、最終のＰｕｔ要求コマンドに対するＳＵＣＣＥＳＳ応答コマンドを受信したかどうかを判別することとなる。
ステップＳ９６は、通信が終了かどうかを判別するステップである。終了でない場合は、再びステップＳ９１へと遷移する。
以上の動作を、クライアント機器３３００のＯＢＥＸ層処理部３３２０の制御部３３２１が行うことにより、最終でないＰｕｔ要求コマンドに対しては、サーバ機器からのＣＯＮＴＩＮＵＥ応答コマンドを待つことなく、次のＰｕｔ要求コマンドを送信することが可能となり、通信の効率をあげることが可能となる。また、最終のＰｕｔコマンドに対するサーバ機器からのＳＵＣＣＥＳＳ応答コマンドに対してはクライアント機器３３００において、確認を行うため、クライアント機器３３００において、サーバ機器に正常にデータ転送を行えたかどうかを判別することが可能となる。
また、図５６に示したように、通信方向選択部３３２４による双方向通信、片方向通信の切り替えと組合わせることで、双方向通信時は、最終のＰｕｔコマンドのみＳＵＣＣＥＳＳ応答コマンドを必要とし、片方向通信時は、全ての要求コマンドに対して応答コマンドを必要としないといった動作を行うことが可能となる。
〔実施の第十三形態〕
本発明の実施の第十三形態に係る転送データの転送システム（通信システム）のサーバ機器（通信装置）について説明すると以下のとおりである。なお、他の実施の形態において定義した用語（部材及び機能を含む）については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。
まず、図５８に、従来のＯＢＥＸプロトコルを用いて通信を行うサーバ機器のブロック図を示す。
図５８に示すよう、にサーバ機器（通信装置）３４００は、アプリケーション層処理部３４１０と、ＯＢＥＸ層処理部（オブジェクト交換層処理部）３４２０と、下位層処理部３４３０と、送信部３４４０と、受信部３４５０とを少なくとも備えている。
アプリケーション層処理部３４１０は、図示しない操作部に入力された利用者の指示に応じて、ＯＢＥＸ層処理部３４２０に対して、受信要求コマンド処理および応答コマンド発行を要求する。
ＯＢＥＸ層処理部３４２０は、制御部３４２１と、応答通知部３４２２と、要求解析部３４２３とを備えている。
制御部３４２１は、アプリケーション層処理部３４１０からの要求に応じて、応答通知部３４２２に対して応答コマンドの生成および下位層へ応答コマンドの発行を行うよう通知する。また、要求解析部３４２３からの要求コマンド受信結果通知を受けて、アプリケーション層処理部３４１０へ要求コマンドの受信結果を通知する。
応答通知部３４２２は、制御部３４２１からの応答コマンド発行通知を受けて、応答コマンドを生成し、下位層処理部３４３０へ出力する。要求解析部３４２３は、下位層処理部３４３０から出力される要求コマンドを受信し、受信した要求コマンドの解析を行い、制御部３４２１に対して、コマンド解析結果および要求コマンドを受信した旨の通知を行う。
下位層処理部３４３０は、ＯＢＥＸ層処理部３４２０からの応答コマンドに適当な下位層のヘッダを付加して送信部３４４０に渡すとともに、受信部３４５０からの受信要求コマンドから、適当な下位層のヘッダを除去して、ＯＢＥＸ層処理部３４２０に渡す。
送信部３４４０は、赤外線通信路等を介して、下位層処理部３４３０から受信した要求コマンドを外部に送信する。
受信部３４５０は、赤外線通信路等を介して、相手機器（クライアント機器）から送信された要求コマンドを受信し、受信した要求コマンドを下位層処理部３４３０に出力する。
次に、図５９に示すフローチャートを用いて、図５８に示した従来のＯＢＥＸサーバ機器３４００におけるＯＢＥＸ層処理部３４２０の制御部３４２１の動作を説明する。
ステップＳ１０１は、クライアント機器から要求コマンドを受信したかかどうかを判別するステップである。受信した場合は、ステップＳ１０２へ、また受信していない場合は、再びステップＳ１０１へそれぞれ遷移する。
ステップＳ１０２は、クライアント機器からの要求コマンドを解析するステップである。解析終了後、ステップＳ１０３へ遷移する。
ステップＳ１０３は、クライアント機器への応答コマンドを作成するステップである。応答コマンド作成終了後、ステップＳ１０４へと遷移する。
ステップＳ１０４は、前記応答コマンドをクライアント機器に送信するステップである。送信終了後、ステップＳ１０５へ遷移する。
ステップＳ１０５は、通信を終了するかどうかを判別するステップである。終了でない場合、再びステップＳ１０１へ遷移する。
以上の動作により、従来のサーバ機器３４００のＯＢＥＸ層処理部３４２０は、要求コマンドを受信解析し、それに対する応答コマンドを生成し送信することで通信を行うことが可能となる。
しかし、前述の従来のサーバ機器３４００のＯＢＥＸ層処理部３４２０の動作では、クライアント機器からの要求コマンドに対して、応答コマンドを生成し、送信してしまうため、例えば片方向通信のように、サーバ機器３４００からの送信が不必要な通信においては、応答コマンドの生成にかかる電力は無駄なものとなっている。
これを解決するために、図６１のフローチャートに示すとおり、本実施の形態に係るサーバ機器３５００（図６０）においては、クライアント機器からの要求コマンドを受信、解析した後、クライアント機器への応答コマンドを生成、送信を行うこととなく、次の要求コマンドを受信することが可能とする。具体的には以下のとおりとなる。
ステップＳ１１１は、クライアント機器からの要求コマンドを受信したかどうかを判別するステップである。受信した場合は、ステップＳ１１２へ、また受信していない場合は、再びステップＳ１１１へそれぞれ遷移する。
ステップＳ１１２は、受信した要求コマンドを解析するステップである。解析終了後、ステップＳ１１５へ遷移する。
ステップＳ１１５は、通信が終了したかどうかを判別するステップである。終了でない場合は、再びステップＳ１１１へ遷移する。
以上の動作を、サーバ機器３５００のＯＢＥＸ層処理部３５２０の制御部３５２１が行うことで、受信した要求コマンドに対する応答コマンドの生成、送信を行わず、次の要求コマンドの受信を行うことが可能となる。
ここで、図６０は、本実施の他の形態に係るサーバ機器３５００のブロック図である。
ＯＢＥＸ層処理部（オブジェクト交換層処理部）３５２０の通信方向選択部３５２４以外の各ブロックは、図５８を用いて上述した従来のサーバ機器３４００のＯＢＥＸ層処理部３４２０の各ブロックと同じ機能を持つため説明を省略する。
通信方向選択部３５２４は、通信が片方向通信か双方向通信かを選択する機能を有する。ここでいう片方向通信とは、クライアント機器からの要求コマンドに対して、サーバ機器からの応答コマンドを必要としない通信である。サーバ機器に送信部が存在しない場合、もしくは、クライアント機器に受信部が存在しない場合は、必然的に片方向通信となるが、送信部と受信部をクライアント機器およびサーバ機器がそれぞれ有しているが、信号の流れがクライアント機器からサーバ機器への片方向である場合は、やはり片方向通信となる。また、双方向通信とは、クライアント機器から送信された要求コマンドに対して、応答コマンドをサーバ機器が送信し、前記応答コマンドの解析後に、再びクライアント機器が次の要求コマンドを送信する通信方式である。この場合、すべての要求コマンドに対して、応答コマンドが必要になるわけでなく、クライアント機器側のＯＢＥＸ層とサーバ機器側のＯＢＥＸ層の双方で、事前に取り決めがなされていれば、特定の要求コマンドに対する応答コマンドは必ずしも必要でない。
次に、図６２のフローチャートを用いて、本実施の形態に係るサーバ機器３５００のＯＢＥＸ層処理部３５２０の制御部３５２１の動作を説明する。
ステップＳ１２０は、通信方向選択部３５２４にて、双方向通信か片方向通信かを選択するステップである。双方向通信の場合は、ステップＳ１２１へ、また片方向通信の場合は、Ｓ１３１へそれぞれ遷移する。
ステップＳ１２１は、双方向通信において、クライアント機器からの要求コマンドを受信したかどうかを判別するステップである。受信した場合は、ステップＳ１２２へ、また受信していない場合は、再びステップＳ１２１へそれぞれ遷移する。
ステップＳ１２２は、双方向通信において、クライアント機器からの要求コマンドを解析するステップである。解析終了後、ステップＳ１２３へ遷移する。
ステップＳ１２３は、双方向通信において、クライアント機器への応答コマンドを作成するステップである。応答コマンド作成終了後、ステップＳ１２４へ遷移する。
ステップＳ１２４は、双方向通信において、前記作成した応答コマンドをクライアント機器に送信するために、下位層処理部３５３０に通知するステップである。通知終了後、ステップＳ１２５へ遷移する。
ステップＳ１２５は、通信を終了するかどうかを判別するステップである。終了でない場合は、再びステップＳ１２１へ遷移する。
一方、ステップＳ１３１は、片方向通信において、クライアント機器からの要求コマンドを受信したかどうかを判別するステップである。受信した場合は、ステップＳ１３２へ、また受信していない場合は、再びステップＳ１３１へそれぞれ遷移する。
ステップＳ１３２は、片方向通信において、クライアント機器からの要求コマンドを解析するステップである。解析終了後、ステップＳ１３５へ遷移する。
ステップＳ１３５は、片方向通信において、通信が終了したかどうかを判別するステップである。終了でない場合は、再びステップＳ１３１へ遷移する。
以上の動作を、サーバ機器３５００のＯＢＥＸ層処理部３５２０の制御部３５２１が行うことにより、双方向通信では、クライアント機器からの要求コマンド受信時には、応答コマンドを生成、送信し、また、片方向通信では、クライアント機器からの要求コマンド受信後、応答コマンドを生成、送信せず、次の要求コマンドを受信することが可能となる。
〔実施の第十四形態〕
本発明の実施の第十四形態に係る転送データの転送システム（通信システム）のサーバ機器（通信装置）について説明すると以下のとおりである。なお、他の実施の形態において定義した用語（部材及び機能を含む）については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。
図６０が本実施の形態のサーバ機器３５００のブロック図である。すなわち、上述した実施の第十三形態と同一であり、また、ＯＢＥＸ層処理部３５２０の制御部３５２１以外の各ブロックの動作も基本的に実施の第十三形態における各ブロックの動作と同じであるため、説明を省略する。
図６３に示すフローチャートを用いて、本実施の形態に係るＯＢＥＸ層処理部３５２０の制御部３５２１の動作を説明する。
ステップＳ１４１は、クライアント機器からのＰｕｔコマンドを受信したかどうかを判別するステップである。受信した場合は、ステップＳ１４２へ、また受信していない場合は、再びステップＳ１４１へそれぞれ遷移する。
ステップＳ１４２は、受信したＰｕｔコマンドを解析するステップである。解析終了後、ステップＳ１４３へ遷移する。
ステップＳ１４３は、解析されたＰｕｔコマンドが最終のＰｕｔコマンドが最終でないＰｕｔコマンドかどうかを判別するステップである。最終のＰｕｔコマンドである場合は、ステップＳ１４４へ、また最終でないＰｕｔコマンドの場合は、再びステップＳ１４１へそれぞれ遷移する。
ステップＳ１４４は、クライアント機器への応答コマンドを生成するステップである。応答コマンド生成終了後、ステップＳ１４５へ遷移する。なお、このステップＳ１４４において、生成される応答コマンドは、クライアント機器からのＰｕｔコマンドを全て正常に終了した場合は、例えばＳＵＣＣＥＳＳ応答コマンドとなる。また、それ以外の場合については、本実施の形態では、言及しない。
ステップＳ１４５は、前述の応答コマンドをクライアント機器に送信するために、下位層処理部３５３０に通知するステップである。通知終了後、ステップＳ１４６へ遷移する。
ステップＳ１４６は、通信が終了かどうかを判別するステップである。終了でない場合は、ステップＳ１４１へ遷移する。
以上の動作を、サーバ機器３５００のＯＢＥＸ層処理部３５２０の制御部３５２１が行うことにより、最終でないＰｕｔ要求コマンドに対しては、従来のＯＢＥＸ層処理部で生成していたＣＯＮＴＩＮＵＥ応答コマンドの生成、送信を行わず、最終のＰｕｔ要求コマンドに対しては、ＳＵＣＣＥＳＳ応答コマンドを生成、送信することが可能となり、通信の効率を上げることが可能となる。また、最終のＰｕｔコマンドに対するＳＵＣＣＥＳＳ応答コマンドをクライアント機器に送信するため、クライアント機器において、サーバ機器３５００に正常にデータ転送を行えたかどうかを判別することが可能となる。
また、図６２に示したように、通信方向選択部３５２４による双方向通信、片方向通信の切り替えと組合わせることで、双方向通信時は、最終のＰｕｔコマンドのみＳＵＣＣＥＳＳ応答コマンドを生成、送信し、片方向通信時は、全ての要求コマンドに対して応答コマンドの生成、送信を行わない動作を行うことが可能となる。
〔実施の第十五形態〕
本実施の第十五形態に係る転送データの転送システム（通信システム）について、図６４に基づいて説明すると以下の通りである。なお、他の実施の形態において定義した用語（部材及び機能を含む）については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。
本実施の形態では、図６４を用いて、携帯電話間での通信例について説明する。なお、送信機と受信機に携帯電話を用いているが、送信機もしくは受信機のどちらか一方が携帯電話であればよく、本発明のいずれかの方式により赤外線等にてデータの送信もしくは受信が可能であるならば、対向機器が携帯電話でなくても構わない。
図６４では、赤外線を用いて、携帯電話Ａ内のデータを携帯電話Ｂに送信している。携帯電話Ｂでは、携帯電話Ａから送信されたデータを受信すると、携帯電話Ｂ内のメモリもしくは接続された外部メモリ内に受信データを保存する。前述のデータとは、テキストデータ、画像データ、音声データ、電話帳データ、システム情報などであり、特定のフォーマットに限定されるものではない。また、携帯電話Ａ内のデータとは、携帯電話Ａの内部メモリ内のデータ、携帯電話Ａに接続されている外部メモリ（ＳＤカードなどの不揮発性メモリ）内のデータのどちらでもよい。
例えば、双方向通信時には、送信側（携帯電話Ａ）においては、前述の各実施の形態のいずれかの方法により、ウィンドウサイズの制限のないＩｒＬＡＰのＵＩフレームに通し番号を付与して送信し、受信側（携帯電話Ｂ）の返信フレームの内容により、必要ならば再送を行い、受信側（携帯電話Ｂ）においては、エラー検出および通し番号の解析を行い、必要ならば再送要求を行うことで、品質の高い通信を行うことが可能となる。
また、例えば、片方向通信時には、送信側（携帯電話Ａ）においては、前述の各実施の形態のいずれかの方法により、ウィンドウサイズの制限のないＩｒＬＡＰのＵＩフレームに通し番号を付与して送信し、受信側（携帯電話Ｂ）においては、エラー検出及び通し番号の解析を行うことで、品質の高い通信を行うことが可能となる。
これにより、ＵＩフレームを用いることで、従来のＩフレームでのウィンドウサイズの制限以内での対向局との確認に比べ、少なくすることが可能となり、転送効率が高く、かつ品質の高い通信を行うことが可能となる。
特に、携帯電話にＳＭＰを用いる場合、送信するファイルごとに、適切な送信機のタイムアウト時間を決定することで、エラー発生時での通信効率の高い通信路を提供するこが可能となる。具体的には、受信機において、データ処理に時間がかかると思われるファイル（例えばＪＰＥＧ画像やＭＰＥＧ動画などのデコード処理を行わなければならないファイル）については、ＢＬ＝１のフレーム送信後のＲＳが含まれるフレームの待ち時間を長くし、テキストファイルなどデータ処理に時間がかからないと思われるファイル送信時には、待ち時間を短くすればよい。
〔実施の第十六形態〕
本実施の第十六形態に係る転送データの転送システム（通信システム）について、図６５に基づいて説明すると以下の通りである。なお、他の実施の形態において定義した用語（部材及び機能を含む）については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。
本実施の形態では、図６５を用いて、携帯電話と表示装置との間での通信例について説明する。なお、送信機として携帯電話を用いているが、本発明のいずれかの方式により赤外線等にてデータの送信が可能であるならば、送信機器が携帯電話でなくても構わない。また、表示装置が送信側となっても構わない。
図６５では、赤外線を用いて、携帯電話Ａ内のデータを表示装置Ｂ（ＴＶやモニタなど）に送信している。表示装置Ｂでは、携帯電話Ａから送信されたデータに対して適切な処理を行い、例えば、画像データであった場合は、必要ならば圧縮されたデータを解凍するなどして、表示を行うが、これに限らない。また、前述のデータとは、テキストデータ、画像データ、音声データ、電話帳データ、システム情報などであり、特定のフォーマットに限定されるものではない。また、携帯電話Ａ内のデータとは、携帯電話Ａの内部メモリ内のデータ、携帯電話Ａに接続されている外部メモリ（ＳＤカードなどの不揮発性メモリ）内のデータのどちらでもよい。
例えば、双方向通信時には、送信側（携帯電話Ａ）においては、前述の各実施の形態のいずれかの方法により、ウィンドウサイズの制限のないＩｒＬＡＰのＵＩフレームに通し番号を付与して送信し、受信側（表示装置Ｂ）の返信フレームの内容により、必要ならば再送を行い、受信側（表示装置Ｂ）においては、エラー検出および通し番号の解析を行い、必要ならば再送要求を行うことで、品質の高い通信を行うことが可能となる。
また、例えば、片方向通信時には、送信側（携帯電話Ａ）においては、前述の各実施の形態のいずれかの方法により、ウィンドウサイズの制限のないＩｒＬＡＰのＵＩフレームに通し番号を付与して送信し、受信側（表示装置Ｂ）においては、エラー検出及び通し番号の解析を行うことで、品質の高い通信を行うことが可能となる。
これにより、ＵＩフレームを用いることで、従来のＩフレームでのウィンドウサイズの制限以内での対向局との確認に比べ、少なくすることが可能となり、転送効率が高く、かつ品質の高い通信を行うことが可能となる。
特に、表示装置にＳＭＰを用いる場合、接続時に表示装置が送信機に通知する受信バッファサイズを、ＪＰＥＧ画像の画像サイズ（数１００ＫＢから数ＭＢ程度）に設定することで、送信機の一括送信データサイズを、ＪＰＥＧ画像１枚が一度に送信できる程度のサイズに設定することができる。
これにより、例えば、表示装置が受信バッファを２つ持ち、１つの受信バッファにＪＰＥＧ画像データを受信し終わった時点で、受信バッファの切り替えを行い、２つめの受信バッファに次のＪＰＥＧ画像を受信している間に１つめの受信バッファ内のＪＰＥＧデータのデコードを行うなどの処理が簡単に行える。
〔実施の第十七形態〕
本実施の第十七形態に係る転送データの転送システム（通信システム）について、図６６に基づいて説明すると以下の通りである。なお、他の実施の形態において定義した用語（部材及び機能を含む）については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。
本実施の形態では、図６６を用いて、携帯電話と印刷装置との間での通信例について説明する。なお、送信機として携帯電話を用いているが、本発明のいずれかの方式により赤外線等にてデータの送信が可能であるならば、送信機器が携帯電話でなくても構わない。また、印刷装置が送信側となっても構わない。
図６６では、赤外線を用いて、携帯電話Ａ内のデータを印刷装置Ｂに送信している。印刷装置Ｂでは、携帯電話Ａから送信されたデータに対して適切な処理を行い、例えば、画像データであった場合は、必要ならば圧縮されたデータを解凍するなどして、印刷を行うが、これに限らない。また、前述のデータとは、テキストデータ、画像データ、電話帳データ、システム情報などであり、特定のフォーマットに限定されるものではない。また、携帯電話Ａ内のデータとは、携帯電話Ａの内部メモリ内のデータ、携帯電話Ａに接続されている外部メモリ（ＳＤカードなどの不揮発性メモリ）内のデータのどちらでもよい。
例えば、双方向通信時には、送信側（携帯電話Ａ）においては、前述の各実施の形態のいずれかの方法により、ウィンドウサイズの制限のないＩｒＬＡＰのＵＩフレームに通し番号を付与して送信し、受信側（印刷装置Ｂ）の返信フレームの内容により、必要ならば再送を行い、受信側（印刷装置Ｂ）においては、エラー検出および通し番号の解析を行い、必要ならば再送要求を行うことで、品質の高い通信を行うことが可能となる。
また、例えば、片方向通信時には、送信側（携帯電話Ａ）においては、前述の各実施の形態のいずれかの方法により、ウィンドウサイズの制限のないＩｒＬＡＰのＵＩフレームに通し番号を付与して送信し、受信側（印刷装置Ｂ）においては、エラー検出及び通し番号の解析を行うことで、品質の高い通信を行うことが可能となる。
これにより、ＵＩフレームを用いることで、従来のＩフレームでのウィンドウサイズの制限以内での対向局との確認に比べ、少なくすることが可能となり、転送効率が高く、かつ品質の高い通信を行うことが可能となる。
特に、印刷装置にＳＭＰを用いる場合、接続時に印刷装置が送信機に通知する受信バッファサイズを、ＪＰＥＧ画像の画像サイズ（数１００ＫＢから数ＭＢ程度）に設定することで、一次局の一括送信データサイズを、ＪＰＥＧ画像１枚が一度に送信できる程度のサイズに設定することができる。
これにより、例えば、印刷装置が受信バッファを２つ持ち、１つの受信バッファにＪＰＥＧ画像データを受信し終わった時点で、受信バッファの切り替えを行い、２つめの受信バッファに次のＪＰＥＧ画像を受信している間に１つめの受信バッファ内のＪＰＥＧデータのデコードを行うなどの処理が簡単に行える。また、印刷装置は、印刷中で次のデータを受信できない状態の場合、エラーが発生していない状況でも、擬似的にエラーが発生していると送信機に通知し、送信機からの再送を行わせるなどして、時間稼ぎを行うことが可能となる。
〔実施の第十八形態〕
本実施の第十八形態に係る転送データの転送システム（通信システム）について、図６７に基づいて説明すると以下の通りである。なお、他の実施の形態において定義した用語（部材及び機能を含む）については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。
本実施の形態では、図６７を用いて、携帯電話と記録装置との間での通信例について説明する。なお、送信機として携帯電話を用いているが、本発明のいずれかの方式により赤外線等にてデータの送信が可能であるならば、送信機器が携帯電話でなくても構わない。また、記録装置が送信側となっても構わない。
図６７では、赤外線を用いて、携帯電話Ａ内のデータを記録装置Ｂに送信している。記録装置Ｂでは、携帯電話Ａから送信されたデータに対して適切な処理を行い、例えば、画像データであった場合は、記録装置Ｂ内のメモリまたは記録装置Ｂに接続された外部メモリに記録を行う。記録装置Ｂ内のメモリとは、ＳＤＲＡＭなどの揮発性メモリでも、フラッシュメモリなどの不揮発性メモリ、記録可能なＤＶＤ、ＨＤＤドライブなど、一時的または半永久的に記録できる媒体であれば何でもよい。また、前述のデータとは、テキストデータ、画像データ、音声データ、電話帳データ、システム情報などであり、特定のフォーマットに限定されるものではない。また、携帯電話Ａ内のデータとは、携帯電話Ａの内部メモリ内のデータ、携帯電話Ａに接続されている外部メモリ（ＳＤカードなどの不揮発性メモリ）内のデータのどちらでもよい。
例えば、双方向通信時には、送信側（携帯電話Ａ）においては、前述の各実施の形態のいずれかの方法により、ウィンドウサイズの制限のないＩｒＬＡＰのＵＩフレームに通し番号を付与して送信し、受信側（記録装置Ｂ）の返信フレームの内容により、必要ならば再送を行い、受信側（記録装置Ｂ）においては、エラー検出および通し番号の解析を行い、必要ならば再送要求を行うことで、品質の高い通信を行うことが可能となる。
また、例えば、片方向通信時には、送信側（携帯電話Ａ）においては、前述の各実施の形態のいずれかの方法により、ウィンドウサイズの制限のないＩｒＬＡＰのＵＩフレームに通し番号を付与して送信し、受信側（記録装置Ｂ）においては、エラー検出及び通し番号の解析を行うことで、品質の高い通信を行うことが可能となる。
これにより、ＵＩフレームを用いることで、従来のＩフレームでのウィンドウサイズの制限以内での対向局との確認に比べ、少なくすることが可能となり、転送効率が高く、かつ品質の高い通信を行うことが可能となる。
特に、記録装置にＳＭＰを用いる場合、接続時に記録装置が送信機に通知する受信バッファサイズを、ＭＰＥＧ動画のフレームサイズ（数１００ＫＢから数ＭＢ程度）に設定することで、送信機の一括送信データサイズを、フレーム１枚が一度に送信できる程度のサイズに設定することができる。
これにより、例えば、記録装置が受信バッファを２つ持ち、１つの受信バッファにフレームデータ１枚分を受信し終わった時点で、受信バッファの切り替えを行い、２つめの受信バッファに次のフレームデータを受信している間に１つめの受信バッファ内のフレームデータのデコードを行うなどの処理が簡単に行える。
〔実施の第十九形態〕
本発明の他の実施の形態について図６８から図９０に基づいて説明すれば、以下のとおりである。なお、本実施の形態で説明する通信プロトコルは、実施の第一形態〜第十八形態に適用されるものである。よって、実施の第一形態〜第十八形態において定義した用語については、特に断らない限り本実施の形態においてもその定義に則って用いるものとする。
（１）通信層
図６８は、ＯＳＩ７階層モデルと、ＩｒＤＡの階層および本発明に係る通信システムの階層の対応関係を示す模式図である。
本実施の形態に係る通信システムの各通信層も、上記ＯＳＩ７層モデルの対応する階層と同等の機能を有する。ただし、図６８に示すように、上記通信システムは、セッション層とプレゼンテーション層とを１つにした、６階層の構造となっている。
本実施の形態では、説明の便宜上、本発明の一適用例であるＩｒＳｉｍｐｌｅに基づいて説明する。しかし、本発明はＩｒＳｉｍｐｌｅに限定されるものではない。なお、ＩｒＳｉｍｐｌｅとは、従来のＩｒＤＡの一部機能を改良したものである。
本実施の形態では、ＩｒＳｉｍｐｌｅに則って、データリンク層、ネットワーク層、トランスポート層、セッション層＋プレゼンテーション層を、それぞれ、ＬＡＰ、ＬＡＭＰ、ＳＭＰ、ＯＢＥＸと表記することがある。また、通信層を送信機、受信機で区別する場合に、送信機（一次局）に“Ｐ”、受信機（二次局）に“Ｓ”と付記する。例えば、“ＬＡＰ（Ｐ）”とは、送信機のデータリンク層を意味する。
（２）送信機−受信機間のシーケンス
（２−１）接続シーケンス
〔Ａ〕レスポンス有り
図６９（ａ）は、本実施の形態（レスポンス有り）の接続シーケンスを示すシーケンス図である。また、図６９（ｃ）は、本実施の形態（レスポンス有り）の接続シーケンスの際の通信データのデータ構造を示す説明図である。
本実施の形態（レスポンス有り）では、ＳＮＲＭのＤｅｓｔｉｎａｔｉｏｎ Ｄｅｖｉｃｅ Ａｄｄｒｅｓｓにグローバルアドレスを使用することにより、サーチと同様の機能をＳＮＲＭコマンドに持たせることができる（図６９（ｃ）のＳＮＲＭ ｃｏｍｍａｎｄ）。
また、本実施の形態（レスポンス有り）では、データリンク層の接続パケットであるＳＮＲＭコマンドおよびＵＡレスポンスの中に、ネットワーク層、トランスポート層、セション層、プレゼンテーション層等の上位層の接続に必要なパラメータおよびコマンドを挿入する。これにより、従来のＩｒＤＡでは必要であった上位層それぞれを接続するための接続パケットを１つのパケットに凝縮することができる。
それゆえ、従来、複数のパケットが必要であった、サーチと接続シーケンスを１つのパケット対で行うことができる。
〔Ｂ〕レスポンス無し
図６９（ｂ）は、本実施の形態（レスポンス無し）の接続シーケンスを示すシーケンス図である。また、図６９（ｃ）は、本実施の形態（レスポンス無し）の接続シーケンスの際の通信データのデータ構造を示す説明図である。なお、本実施の形態（レスポンス無し）では、ＵＡレスポンス（図６９（ｃ）のＵＡ ｒｅｓｐｏｎｓｅ ｆｏｒ ＳＮＲＭ）は不要である。
ユーザまたはアプリケーションおよびデータ種類によっては、受信機からのレスポンスを省略した通信方式を選択できる。この場合、図３８（ｂ）に示すように、ＳＮＲＭコマンドのみでサーチおよび接続が終了したものとできる。
このように、本実施の形態の接続シーケンスは、複数の通信層の接続リクエストをまとめることにより、接続に要する時間を短縮するものであるため、通信路が切断した場合でも再接続が容易である。よって、通信路が切断しやすい、例えば赤外線による無線通信に特に適している。ただし、ＩＥＥＥ８０２．１１無線、Ｂｌｕｅｔｏｏｔｈを含む他の無線通信、および、有線通信においても効果的である。
また、本実施の形態では、すべての通信層の接続を１回の通信で接続する例について説明するが、本発明はこれに限定されない。例えば、１つの通信層を接続した後、残りの複数の通信層を接続するようにしてもよい。また、１つの通信層の接続が複数回の通信によって行われてもよい。例えば、ネットワーク層の接続が２回の通信を要する場合、データリンク層の接続とネットワーク層の１回目の接続とを１つの接続リクエストにまとめ、ネットワーク層の２回目の接続とトランスポート層の接続とを１つの接続リクエストにまとめてもよい。
（２−２）データ交換シーケンス
〔Ａ〕レスポンス有り
図７０（ａ）（ｂ）は、本実施の形態（レスポンス有り）のデータ交換シーケンスを示すシーケンス図である。また、図７０（ａ）は、本実施の形態（レスポンス有り）のデータ交換シーケンスの際の通信データのデータ構造を示す説明図である。
本実施の形態（レスポンス有り）では、１つのデータ間毎の下位層及び上位層のレスポンスを極力減らし、多くのデータを送信した後にエラーがあったか無かったかを返信する。
送信機は、データ通信時に、シーケンシャルなパケット番号および受信データに問題がなかったかを問うためのフラグと、上記データをパケットのサイズに合わせて分割した分割データで構築されたパケットを用いる。
図７０（ａ）に示すように、送信機は、所定数のパケット数を送信した後に上記フラグをオンにしたパケットの送信を行う。これに対し、受信機は、以前のデータの始めから、もしくは上記フラグがオンであったパケットを受信し、返信を行ってから、エラーを検出しなかった場合は、正常に受信した旨を送信機に通知する。また、受信機は、以前のデータの始めから、もしくは上記フラグがオンであったパケットを受信し、返信を行ってから、エラーを検出した場合は、受信することができなかったパケット以降の上記分割データ部分を無視し、上記フラグのみを確認し、上記フラグがオンであった場合に、エラーにより受信できなかったパケット番号を送信機へ通知する。
さらに、送信機は、正常に受信した旨を受信機から受けた場合、次のパケットから送信を行う。また、送信機は、エラーがあったという通知を受けた場合、受信できなかったパケット番号から、上記フラグをオンにしたパケットまでを再送信する。
これにより、パケット間を詰めることができ、効率のよい通信が可能となる。
図７０（ａ）に示すように、本実施の形態（レスポンス有り）では、ＵＩフレーム（図７１（ｂ））を使用する。このため、データリンク層（ＬＡＰ層）ではパケットの抜けが認識できず、トランスポート層で検出する。
ＵＩフレームのトランスポート層のデータ部分にシーケンシャルナンバーとデータ確認用フラグ、データの最後のパケットかどうか、受信したデータが正常であったかを示すフラグを設け、それらのフラグによってデータの送信を行う。
〔Ｂ〕レスポンス無し
図７２（ａ）（ｂ）は、本実施の形態（レスポンス無し）のデータ交換シーケンスを示すシーケンス図である。また、図７２（ｂ）は、本実施の形態（レスポンス無し）のデータ交換シーケンスの際の通信データのデータ構造を示す説明図である。
本実施の形態（レスポンス無し）では、受信機のレスポンスを必要としない場合、データの完全性のみを確認する。そのため、送信機はパケットにシーケンスナンバーを振り、全てのデータを連続で送信する。
そして、受信機は、エラーがあったかどうかを確認するのみであり、正常に受信した場合には全てのデータを受けた後、受信機内で正常受信であることを認識し、次の動作を行う。この場合の次の動作とは、例えば受信したデータを表示したり、印刷したり、保存したりすることである。一方、エラーを検出した場合、受信機内で正常受信できなかったことを認識し、次の動作を行う。この場合の次の動作とは、失敗したことをユーザーに知らせるためのインジケートや、次の受信待ち状態になることである。
なお、本実施の形態（レスポンス無し）でも、図７２（ｂ）に示すＵＩフレーム（図７１（ｂ））を使用する。
（２−３）切断シーケンス
〔Ａ〕レスポンス有り
図７３（ａ）は、本実施の形態（レスポンス有り）の切断シーケンスを示すシーケンス図である。また、図７３（ｃ）は、本実施の形態（レスポンス有り）の切断シーケンスの際の通信データのデータ構造を示す説明図である。
図７３（ｃ）に示すように、本実施の形態（レスポンス有り）では、ネットワーク層、トランスポート層、セション層、プレゼンテーション層等の上位層の切断に必要なパラメータおよびコマンドを、ＤＩＳＣコマンドおよびＵＡレスポンスの中に挿入した。
これにより、従来、複数のパケットが必要であった、切断シーケンスを１つのパケット対で行うことができる。
〔Ｂ〕レスポンス無し
図７３（ｂ）は、本実施の形態（レスポンス無し）の切断シーケンスを示すシーケンス図である。また、図７３（ｃ）は、本実施の形態（レスポンス有り）の切断シーケンスの際の通信データのデータ構造を示す説明図である。なお、本実施の形態（レスポンス無し）では、ＵＡレスポンス（図７３（ｃ）のＵＡ ｒｅｓｐｏｎｓｅ）は不要である。
図７３（ｂ）に示すように、本実施の形態（レスポンス無し）では、受信機のレスポンスを必要としないとして接続した場合、ＤＩＳＣコマンドのみでサーチおよび切断が終了したものとできる。
（３）送信機、受信機内のシーケンス
図７４〜図９０では、説明の便宜上、データリンク層をＬＡＰ、ネットワーク層をＬＡＭＰ、トランスポート層をＴＴＰまたはＳＭＰ、セッション層およびプレゼンテーション層をＯＢＥＸと表記する。また、通信層を送信機と受信機とで区別するために、送信機に“Ｐ”、受信機に“Ｓ”と付記する。例えば、“ＬＡＰ（Ｐ）”とは、送信機のデータリンク層を意味する。
（３−１）接続シーケンス
〔Ａ〕レスポンス有り
図７４は、本実施の形態（レスポンス有り）の接続シーケンスを示すシーケンス図である。また、図７５（ａ）、図７５（ｂ）は、本実施の形態（レスポンス有り）の接続シーケンスの際の通信データのデータ構造を示す説明図である。
図７４に示すように、本実施の形態（レスポンス有り）では、送信機、受信機とも、接続準備を行う。その後、送信機は、上位層のリクエストをそのまま下位層に渡していき、１つのパケット（ＳＮＲＭ）として送信する。一方、受信機は、ＳＮＲＭパケットを受けて、そのまま上位層へ接続できた旨の通知を行った後、ＯＢＥＸ（Ｓ）のレスポンスをそのまま下位層に渡していき、１つのパケット（ＵＡ）として送信する。送信機は、ＵＡを受けたことで接続完了とし、上位層に通知（Ｃｏｎｎｅｃｔ．ｃｏｎｆｉｒｍ）を上げていく。
このときの、送信機、受信機内のシーケンスは以下のとおりである。
まず、送信機の各通信層について説明する。
ＯＢＥＸ（Ｐ）は、アプリケーションからの接続要求が来た場合に、速やかに下位層（ＳＭＰ（Ｐ））に対して接続要求コマンドをデータに入れて接続要求関数（Ｐｒｉｍｉｔｉｖｅ）を発生する。また、ＯＢＥＸ（Ｐ）は、ＳＭＰ（Ｐ）から接続確認関数を受けた場合に、そのデータの中からＯＢＥＸ接続のレスポンスを確認し、問題ない（Ｓｕｃｃｅｓｓ）というレスポンスであれば、接続完了とする。
ＳＭＰ（Ｐ）は、ＯＢＥＸ（Ｐ）からの接続要求関数を受けて、速やかにＯＢＥＸ（Ｐ）の接続要求関数のデータに、受信機のＳＭＰ（Ｓ）との通信に必要なパラメータを付加して、下位層（ＬＭＰ（Ｐ））に対して接続要求関数を発生する。また、ＳＭＰ（Ｐ）は、ＬＭＰ（Ｐ）から接続確認関数を受けた場合、関数のデータから受信機のＳＭＰ（Ｓ）が生成したパラメータを抜き取り、値を確認して、ＳＭＰ（Ｓ）とのネゴシエーションを終了する。また、ＳＭＰ（Ｐ）は、接続確認関数のデータからＳＭＰ（Ｓ）のパラメータを取り除いたデータをＯＢＥＸ（Ｐ）に対して接続確認関数として送信する。
ＬＭＰ（Ｐ）は、ＳＭＰ（Ｐ）からの接続要求関数を受けて、速やかにＳＭＰ（Ｐ）の接続要求関数のデータに、受信機のＬＭＰ（Ｓ）との通信に必要なパラメータを付加して、下位層（ＬＡＰ（Ｐ））に対して接続要求関数を発生する。また、ＬＭＰ（Ｐ）は、ＬＡＰ（Ｐ）から接続確認関数を受けた場合、関数のデータから受信機のＬＭＰ（Ｓ）が生成したパラメータを抜き取り、値を確認して、ＬＭＰ（Ｓ）とのネゴシエーションを終了する。また、ＬＭＰ（Ｐ）は、接続確認関数のデータからＬＭＰ（Ｓ）のパラメータを取り除いたデータを、ＳＭＰ（Ｐ）に対して接続確認関数として送信する。
なお、通常は論理ポートを管理するためにＬＳＡＰ（Ｌｉｎｋ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）が定義される。そして、１対１で１つの接続をする場合にはＬＭＰを使用する必要がない。この場合、ＬＳＡＰにコネクションレスの値を固定値として使用する。このため、ＬＭＰの接続パラメータ交換は不要となっている。
ＬＡＰ（Ｐ）は、ＬＭＰ（Ｐ）からの接続要求関数を受けて、速やかにＬＭＰ（Ｐ）の接続要求関数のデータに、受信機のＬＡＰ（Ｓ）との通信に必要なパラメータを付加して、受信機の物理層に対してＳＮＲＭコマンドを出力する。また、ＬＡＰ（Ｐ）は、受信機の物理層からＵＡレスポンスを受けた場合、ＵＡレスポンスのデータから受信機のＬＡＰ（Ｓ）が生成したパラメータを抜き取り、値を確認して、ＬＡＰ（Ｓ）とのネゴシエーションを終了する。また、ＬＡＰ（Ｐ）は、ＵＡレスポンスのデータからＬＡＰ（Ｓ）のパラメータを取り除いたデータを、ＬＭＰ（Ｐ）に対して接続確認関数として送信する。
つづいて、受信機の各通信層について説明する。
ＯＢＥＸ（Ｓ）は、アプリケーションから接続要求関数を受けて、受信待機状態になる。また、ＯＢＥＸ（Ｓ）は、下位層（ＳＭＰ（Ｓ））から接続通知関数（Ｉｎｄｉｃａｔｉｏｎ）を受けた場合に、そのデータの中からＯＢＥＸ接続コマンドを確認し、問題が無ければＳｕｃｃｅｓｓというレスポンスを接続返答関数（Ｒｅｓｐｏｎｓｅ）としてＳＭＰ（Ｓ）に対して出力し、接続完了とする。
ＳＭＰ（Ｓ）は、ＯＢＥＸ（Ｓ）からの接続要求関数を受けて、受信待機状態になる。また、ＳＭＰ（Ｓ）は、下位層（ＳＭＰ（Ｓ））から接続通知関数を受けた場合に、関数のデータから送信機のＳＭＰ（Ｐ）が生成したパラメータを抜き取り、それに対しての返答のパラメータを作成し、上記関数のデータからＳＭＰ（Ｐ）のパラメータを除いたデータを入れた接続要求関数をＯＢＥＸ（Ｓ）に発した後、ＯＢＥＸ（Ｓ）からの接続返答関数を待つ。また、ＳＭＰ（Ｓ）は、ＯＢＥＸ（Ｓ）からの接続返答関数を受けた場合に、ＬＭＰ（Ｓ）に対してＯＢＥＸ（Ｓ）の接続返答関数のデータに上記返答のパラメータを付加して、ＬＭＰ（Ｓ）に対して接続返答関数を発生し、ＳＭＰ層のネゴシエーションを終了する。
ＬＭＰ（Ｓ）は、ＳＭＰ（Ｓ）からの接続要求関数を受けて、受信待機状態になる。また、ＬＭＰ（Ｓ）は、下位層（ＬＡＰ（Ｓ））から接続通知関数を受けた場合に、関数のデータから送信機のＬＭＰ（Ｐ）が生成したパラメータを抜き取り、それに対しての返答のパラメータを作成し、上記関数のデータからＬＭＰ（Ｐ）のパラメータを除いたデータを入れた接続要求関数をＳＭＰ（Ｓ）に発した後、ＳＭＰ（Ｓ）からの接続返答関数を待つ。また、ＬＭＰ（Ｓ）は、ＳＭＰ（Ｓ）からの接続返答関数を受けた場合に、ＬＡＰ（Ｓ）に対してＳＭＰ（Ｓ）の接続返答関数のデータに上記返答のパラメータを付加して、ＬＡＰ（Ｓ）に対して接続返答関数を発生し、ＬＭＰ層のネゴシエーションを終了する。
なお、通常は論理ポートを管理するためにＬＳＡＰ（Ｌｉｎｋ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）が定義される。そして、１対１で１つの接続をする場合にはＬＭＰを使用する必要がない。この場合、ＬＳＡＰにコネクションレスの値を固定値として使用する。このため、ＬＭＰの接続パラメータ交換は不要となっている。
ＬＡＰ（Ｓ）は、ＬＭＰ（Ｓ）からの接続要求関数を受けて、受信待機状態になる。また、ＬＡＰ（Ｓ）は、物理層からＳＮＲＭコマンドを受けた場合に、ＳＮＲＭコマンドのデータから送信機のＬＡＰ（Ｐ）が生成したパラメータを抜き取り、ＳＮＲＭコマンドのデータからＬＡＰ（Ｐ）のパラメータを除いたデータを入れた接続要求関数をＬＭＰ（Ｓ）に発した後、それに対しての返答のパラメータを作成し、ＬＭＰ（Ｓ）からの接続返答関数を待つ。また、ＬＡＰ（Ｓ）は、ＬＭＰ（Ｓ）からの接続返答関数を受けた場合に、ＬＭＰ（Ｓ）の接続返答関数のデータに上記返答のパラメータを付加して、物理層に対してＵＡレスポンスを出力し、ＬＡＰ層のネゴシエーションを終了する。
〔Ｂ〕レスポンス無し
図７６は、本実施の形態（レスポンス無し）の接続シーケンスを示すシーケンス図である。また、図７５（ａ）は、本実施の形態（レスポンス無し）の接続シーケンスの際の通信データのデータ構造を示す説明図である。
図７６に示すように、本実施の形態（レスポンス無し）では、送信機、受信機とも、接続準備を行う。その後、送信機は、上位層のリクエストをそのまま下位層に渡していき、１つのパケット（ＳＮＲＭ）として送信する。そして、送信機は、ＳＮＲＭパケットを送信した時点で接続完了として、ＬＡＰ（Ｐ）から上位層に通知（Ｃｏｎｎｅｃｔ．ｃｏｎｆｉｒｍ）を上げていく。一方、受信機は、ＳＮＲＭパケットを受けて、そのまま上位層へ接続できた旨の通知を行い、ＯＢＥＸ（Ｓ）に通知した時点で接続完了とする。
このときの、送信機、受信機内のシーケンスは以下のとおりである。
まず、送信機の各通信層について説明する。
ＯＢＥＸ（Ｐ）は、アプリケーションからの接続要求が来た場合に、速やかに下位層（ＳＭＰ（Ｐ））に対して接続要求コマンドをデータに入れて接続要求関数（Ｐｒｉｍｉｔｉｖｅ）を発生する。また、ＯＢＥＸ（Ｐ）は、ＳＭＰ（Ｐ）から接続確認関数を受けた場合に、接続完了とする。
ＳＭＰ（Ｐ）は、ＯＢＥＸ（Ｐ）からの接続要求関数を受けて、速やかにＯＢＥＸ（Ｐ）の接続要求関数のデータに、受信機のＳＭＰ（Ｓ）との通信に必要なパラメータを付加して、下位層（ＬＭＰ（Ｐ））に対して接続要求関数を発生する。また、ＳＭＰ（Ｐ）は、ＬＭＰ（Ｐ）から接続確認関数を受けた時点で、送信したパラメータでネゴシエーションができたとして、ＳＭＰ層のネゴシエーションを終了する。また、この時、ＳＭＰ（Ｐ）は、ＯＢＥＸ（Ｐ）に対して接続確認関数を送信する。
ＬＭＰ（Ｐ）は、ＳＭＰ（Ｐ）からの接続要求関数を受けて、速やかにＳＭＰ（Ｐ）の接続要求関数のデータに、受信機のＬＭＰ（Ｓ）との通信に必要なパラメータを付加して、下位層（ＬＡＰ（Ｐ））に対して接続要求関数を発生する。また、ＬＭＰ（Ｐ）は、ＬＡＰ（Ｐ）から接続確認関数を受けた時点で、送信したパラメータでネゴシエーションができたとして、ＬＭＰ層のネゴシエーションを終了する。また、この時、ＬＭＰ（Ｐ）は、ＳＭＰ（Ｐ）に対して接続確認関数を送信する。
なお、通常は論理ポートを管理するためにＬＳＡＰ（Ｌｉｎｋ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）が定義される。そして、１対１で１つの接続をする場合にはＬＭＰを使用する必要がない。この場合、ＬＳＡＰにコネクションレスの値を固定値として使用する。このため、ＬＭＰの接続パラメータ交換は不要となっている。
ＬＡＰ（Ｐ）は、ＬＭＰ（Ｐ）からの接続要求関数を受けて、速やかにＬＭＰ（Ｐ）の接続要求関数のデータに、受信機のＬＡＰ（Ｓ）との通信に必要なパラメータを付加して、受信機の物理層に対してＳＮＲＭコマンドを出力する。また、ＬＡＰ（Ｐ）は、ＳＮＲＭコマンドを出力した時点で、送信したパラメータでネゴシエーションができたとして、ＬＡＰ層のネゴシエーションを終了する。また、この時、ＬＡＰ（Ｐ）は、ＬＭＰ（Ｐ）に対して接続確認関数を送信する。
つづいて、受信機の各通信層について説明する。
ＯＢＥＸ（Ｓ）は、アプリケーションから接続要求関数を受けて、受信待機状態になる。また、ＯＢＥＸ（Ｓ）は、下位層（ＳＭＰ（Ｓ））から接続通知関数（Ｉｎｄｉｃａｔｉｏｎ）を受けた場合に、そのデータの中からＯＢＥＸ接続コマンドを確認し、問題が無ければ、接続完了とする。
ＳＭＰ（Ｓ）は、ＯＢＥＸ（Ｓ）からの接続要求関数を受けて、受信待機状態になる。また、ＳＭＰ（Ｓ）は、下位層（ＳＭＰ（Ｓ））から接続通知関数を受けた場合に、関数のデータから送信機のＳＭＰ（Ｐ）が生成したパラメータを抜き取り、そのパラメータを使用してネゴシエーションを完了させる。そして、ＳＭＰ（Ｓ）は、上記関数のデータからＳＭＰ（Ｐ）のパラメータを除いたデータを入れた接続要求関数をＯＢＥＸ（Ｓ）に発する。
ＬＭＰ（Ｓ）は、ＳＭＰ（Ｓ）からの接続要求関数を受けて、受信待機状態になる。また、ＬＭＰ（Ｓ）は、下位層（ＬＡＰ（Ｓ））から接続通知関数を受けた場合に、関数のデータから送信機のＬＭＰ（Ｐ）が生成したパラメータを抜き取り、そのパラメータを使用してネゴシエーションを完了させる。そして、ＬＭＰ（Ｓ）は、上記関数のデータからＬＭＰ（Ｐ）のパラメータを除いたデータを入れた接続要求関数をＳＭＰ（Ｓ）に発する。
なお、通常は論理ポートを管理するためにＬＳＡＰ（Ｌｉｎｋ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）が定義される。そして、１対１で１つの接続をする場合にはＬＭＰを使用する必要がない。この場合、ＬＳＡＰにコネクションレスの値を固定値として使用する。このため、ＬＭＰの接続パラメータ交換は不要となっている。
ＬＡＰ（Ｓ）は、ＬＭＰ（Ｓ）からの接続要求関数を受けて、受信待機状態になる。また、ＬＡＰ（Ｓ）は、物理層からＳＮＲＭコマンドを受けた場合に、ＳＮＲＭコマンドのデータから送信機のＬＡＰ（Ｐ）が生成したパラメータを抜き取り、そのパラメータを使用してネゴシエーションを完了させる。そして、ＬＡＰ（Ｓ）は、上記関数のデータからＬＡＰ（Ｐ）のパラメータを除いたデータを入れた接続要求関数をＬＭＰ（Ｓ）に発する。
（３−２）データ交換シーケンス
〔Ａ〕レスポンス有り
図７７は、本実施の形態（レスポンス有り）のデータ交換シーケンスを示すシーケンス図である。また、図７８は、本実施の形態（レスポンス有り）のデータ交換シーケンスの際の通信データのデータ構造を示す説明図である。
図７７に示すように、本実施の形態（レスポンス有り）では、送信機が、ＰＵＴコマンドを発生し、それが下位層まで伝わり、ＵＩフレーム（図７１（ｂ））として出力される。
一方、受信機は、データを受け取り、上位層へ通知を上げていく。このとき、ＳＭＰ（Ｓ）では、上位層のＯＢＥＸ（Ｓ）に対して、データが続くことを通知する（ｓｔａｔｕｓ＝ｔｒｕｎｃａｔｅｄ）。
送信機は、ある一定数のパケットを送信した後に、データがきちんと届いているかどうかを確認するフラグをＯＮにして送信する。これを受けて、受信機では、ＳＭＰ（Ｓ）が、エラーがあったかなかったか、あった場合にはエラーが発生した番号を送信機に通知する。
送信機は、エラーが無ければ次のパケット群を出力し、エラーがあればエラーがあったパケット以降のパケットを再送信する。
送信機は、データの最後になったときに、データの最後であることを示すフラグをＯＮにして送信する。これに対して、受信機は、ＳＭＰ（Ｓ）が、このフラグがＯＮであれば、ＯＢＥＸ（Ｓ）にデータがそろったことを通知し（ｓｔａｔｕｓ＝ＯＫ）、ＯＢＥＸ（Ｓ）のレスポンスを待つ。そして、ＯＢＥＸ（Ｓ）のレスポンスが発生したとき、そのデータを下位層へ伝えていき、ＵＩフレームとして出力する。
送信機は、受けたレスポンスがＳｕｃｃｅｓｓであれば、正常終了する。
このときの、送信機、受信機内のシーケンスは以下のとおりである。
送信機では、ＯＢＥＸ（Ｐ）が下位層に対してＰＵＴコマンドをデータ送信関数として出力する。ただし、ＯＢＥＸ（Ｐ）は、ＰＵＴ Ｆｉｎａｌ（最後のＰＵＴ）コマンド以外のＰＵＴコマンドのレスポンス（正常の場合はＣｏｎｔｉｎｕｅが返る）を必要とせずにＳＭＰ（Ｐ）で送信可能である場合には、次のコマンドを出力していく。ＰＵＴ ＦｉｎａｌコマンドもしくはＰＵＴコマンド以外のコマンドの場合には、下位層からのデータ通知関数を待ち、そのデータ内のレスポンスをみてコマンドを終了する。
ここで、データ送信関数とは、下位層に対してデータ送信を要求する関数（Ｄａｔａ Ｒｅｑｕｅｓｔ）である。また、データ通知関数とは、下位層からデータを受信したことを知らせる関数（Ｄａｔａ Ｉｎｄｉｃａｔｅ）である。
受信機では、ＯＢＥＸ（Ｓ）が下位層からデータ通知関数を受けて、データを受ける。ただし、ＯＢＥＸ（Ｓ）は、ＰＵＴ Ｆｉｎａｌコマンド以外のＰＵＴコマンドに対しては、レスポンスを返さず、ＰＵＴ ＦｉｎａｌコマンドもしくはＰＵＴコマンド以外のコマンドの場合はデータ送信関数としてレスポンスを返す。
ここで、送信機、受信機に共通する、上位層と下位層のデータ送信関数およびデータ通知関数でのヘッダ等について説明する。
ＳＭＰは、ＯＢＥＸからデータ送信関数を受けると、ＬＭＰに対して、（ａ）ＬＭＰで送信可能なサイズがデータ送信関数内のデータのサイズよりも小さいときには、該データをＬＭＰが送信可能なサイズに分割し、（ｂ）ＬＭＰで送信可能なサイズがデータ送信関数内のデータのサイズよりも大きいときには、いくつかのデータを結合して、送信可能なサイズ以下の、より大きなデータを作成する。また、ＳＭＰは、シーケンシャルな番号、相手機器にデータ受信状態を問い合わせる引数、データの最後を示す引数、相手機器のＳＭＰがＯＢＥＸのレスポンスが必要であることを示す引数、受信したデータが正常であったかどうかを示す引数などを入れたＳＭＰヘッダを作成する。そして、このＳＭＰヘッダを、上記分割または結合したデータに付加したデータを入れたデータ送信関数をＬＭＰに対して発する。
さらに、ＳＭＰは、ＬＭＰからデータ通知関数を受けると、該関数内のデータからＳＭＰヘッダを抜き出し、シーケンス番号が正常であるか（すなわち、抜けなく順番に来ているか）を確認する。そして、正常であった場合には、ＯＢＥＸへデータ通知関数を発する。このとき、データ通知関数は、下位層からのデータ通知関数ごとに出力してもよいし、いくつかの下位層からのデータ通知関数のデータをあわせて出力してもよい。
送信機のＳＭＰ（Ｐ）は、ＯＢＥＸ（Ｐ）からのデータ送信関数をＬＭＰ（Ｐ）へのデータ送信関数に変換して、規定しているある一定数のデータ量のデータ送信関数を発する。その後、ＳＭＰ（Ｐ）は、受信機にデータ受信状態を問い合わせる引数をＴｒｕｅにしてデータ送信関数を発して、ＬＭＰ（Ｐ）のデータ通知関数を待つ。
ＳＭＰ（Ｐ）は、ＬＭＰ（Ｓ）からのデータ通知関数内のＳＭＰヘッダを解析し、受信したデータが正常であったかどうかを示す引数が正常に受信していたことを示していた場合、次のデータを送信する準備ができたとして、ＯＢＥＸ（Ｐ）に対して送信可能であるステートになる。すなわち、この状態でＯＢＥＸ（Ｐ）からのデータを受け付けることができる。
これに対して、ＳＭＰ（Ｐ）は、ＬＭＰ（Ｓ）からの受け取ったデータ通知関数のＳＭＰヘッダを解析して受信したデータが正常であったかどうかを示す引数が正常に受信していなかったことを示していた場合、正常に受信できなかったと通知されたデータ送信関数から相手機器にデータ受信状態を問い合わせる引数をＴｒｕｅにしたデータ送信関数までを再度発生する。ＳＭＰ（Ｐ）は、全てのデータ送信関数によるデータが受信機に通知されるまで、もしくはある規定回数再発生を繰り返す。
さらに、ＳＭＰ（Ｐ）は、ＯＢＥＸ（Ｐ）からデータの最後であるとした引数がＴｒｕｅであるデータ送信関数を受けた場合、そのデータ送信関数の最後のデータを入れた、ＬＭＰ（Ｐ）へのデータ送信関数を、このデータ送信関数がデータの最後であることを示す引数、または、受信機のＯＢＥＸ（Ｓ）のレスポンスが必要であることを示す引数をＴｒｕｅにして発する。
これに対して、受信機のＳＭＰ（Ｓ）は、ＬＭＰ（Ｓ）からデータ通知関数を受けた際に、データの最後または受信機のＯＢＥＸ（Ｓ）のレスポンスが必要であることを示す引数がＴｒｕｅであった場合に、ＯＢＥＸ（Ｓ）へＳＭＰ（Ｓ）のヘッダを外したデータを入れたデータ通知関数を発する。
また、ＳＭＰ（Ｓ）は、データ通知関数をＬＭＰ（Ｓ）から受けた場合に、そのデータ通知関数内のデータからＳＭＰヘッダを解析し、シーケンシャルな番号を確認する。ＳＭＰ（Ｓ）は、受信機にデータ受信状態を問い合わせる引数がＴｒｕｅであるヘッダを受けるまで正常に受信できていれば、受信したデータが正常であったかどうかを示す引数を正常に受信できたことを示すものにしてＳＭＰヘッダを作成し、それをデータとしてＬＭＰ（Ｓ）に対してデータ送信関数を発する。
一方、ＳＭＰ（Ｓ）は、正常に受信できなかったことを検出した場合には、正常に受信できなかったと予測されるＳＭＰヘッダの番号を記憶する。例えば、０，１，２，３，５と受けたとき、５個目は４となるべきなのに４を受けなかった場合には、正常に受信できなかったと予測される番号は４となる。そして、それ以降、ＳＭＰ（Ｓ）は、ＳＭＰヘッダの受信機にデータ受信状態を問い合わせる引数がＴｒｕｅであるかどうかのみを調べて、ＯＢＥＸ（Ｓ）へのデータ通知関数の出力を停止する。
ＳＭＰ（Ｓ）は、受信機にデータ受信状態を問い合わせる引数がＴｒｕｅであるデータ通知関数を受けた場合に、受信したデータが正常であったかどうかを示す引数を正常に受信できなかったことを示すものにし、正常に受信できなかったＳＭＰヘッダの番号をシーケンシャル番号を入れるフィールドに挿入したＳＭＰヘッダを作成して、それをデータとしてＬＭＰ（Ｓ）に向けてデータ送信関数を発する。
また、ＳＭＰ（Ｓ）は、データの最後であることを示す引数、または受信機のＯＢＥＸ（Ｓ）のレスポンスが必要であることを示す引数がＴｒｕｅであったデータ通知関数を受けた場合、ＯＢＥＸ（Ｓ）へデータ通知関数を出力した後、ＯＢＥＸ（Ｓ）からのデータ送信要求を待つ。
ＳＭＰ（Ｓ）は、ＯＢＥＸ（Ｓ）からのデータ送信要求を受けた場合には、受信したデータが正常であったかどうかを示す引数に正常に受信できたとするＳＭＰヘッダを作成し、それをＯＢＥＸ（Ｓ）のデータ送信要求のデータに付加して、ＬＭＰ（Ｓ）に対してデータ送信関数を発する。なお、エラーがあった場合には、ＯＢＥＸ（Ｓ）への通知は止まるため、待つときは正常であったときのみとなる。
つぎに、ＬＭＰは上位層からデータ送信要求関数を受けたときには、その関数内のデータにＬＭＰヘッダをつけてデータを作成し、ＬＡＰにそのデータが入ったデータ送信要求関数を発する。また、ＬＭＰは、ＬＡＰからデータ通知関数を受けた場合には、その関数内のデータからＬＭＰヘッダを除いたデータを作成し、ＳＭＰにそのデータが入ったデータ通知関数を発する。
なお、１対１で１つの接続をする場合にはＬＭＰを使用する必要がない。この場合、ＬＭＰヘッダにはコネクションレスの値が入ったＬＳＡＰが入る。
ＬＡＰは、ＬＭＰからデータ送信要求関数を受けたとき、その関数内のデータにＬＡＰヘッダをつけてデータを作成し、物理層にそのデータがはいったＵＩフレームを発する。また、ＬＡＰは、物理層からデータ受信通知を受けた場合には、そのＵＩフレームのデータからＬＡＰヘッダを除いたデータを作成し、ＬＭＰにそのデータが入ったデータ通知関数を発する。なお、本実施の形態では、ＬＡＰヘッダには、接続アドレスとＵＩインジケータが含まれる。
〔Ｂ〕レスポンス無し
図７９は、本実施の形態（レスポンス無し）のデータ交換シーケンスを示すシーケンス図である。また、図７８は、本実施の形態（レスポンス無し）のデータ交換シーケンスの際の通信データのデータ構造を示す説明図である。
図７９に示すように、本実施の形態（レスポンス無し）では、送信機が、ＰＵＴコマンドを発生し、それが下位層まで伝わり、ＵＩフレームとして出力される。
一方、受信機は、データを受け取り、上位層へ通知を上げていく。このとき、ＳＭＰ（Ｓ）では、上位層のＯＢＥＸ（Ｓ）に対して、データが続くことを通知する（ｓｔａｔｕｓ＝ｔｒｕｎｃａｔｅｄ）。
そして、送信機は、データの最後になったときに、データの最後であることを示すフラグをＯＮにして送信する。これに対して、受信機は、ＳＭＰ（Ｓ）が、このフラグがＯＮであれば、ＯＢＥＸ（Ｓ）にデータがそろったことを通知して（ｓｔａｔｕｓ＝ＯＫ）、データ交換シーケンスを終了する。
このときの、送信機、受信機内のシーケンスは以下のとおりである。
送信機では、ＯＢＥＸ（Ｐ）が下位層に対してＰＵＴコマンドをデータ送信関数として出力する。ただし、ＯＢＥＸ（Ｐ）は、すべてのコマンドに対するレスポンスを必要とせずに、コマンドを終了することができる。そして、ＯＢＥＸ（Ｐ）は、ＳＭＰ（Ｐ）で送信可能である場合に、次のコマンドを出力していく。
受信機では、ＯＢＥＸ（Ｓ）が下位層からデータ通知関数を受けて、すべてのコマンドに対してレスポンスを返さずに、データのみを受け取る。
ここで、送信機、受信機に共通する、上位層と下位層のデータ送信関数およびデータ通知関数でのヘッダ等について説明する。
ＳＭＰは、ＯＢＥＸからデータ送信関数を受けると、ＬＭＰに対して、（ａ）ＬＭＰで送信可能なサイズがデータ送信関数内のデータのサイズよりも小さいときには、該データをＬＭＰが送信可能なサイズに分割し、（ｂ）ＬＭＰで送信可能なサイズがデータ送信関数内のデータのサイズよりも大きいときには、いくつかのデータを結合して、送信可能なサイズ以下の、より大きなデータを作成する。また、ＳＭＰは、シーケンシャルな番号、相手機器にデータ受信状態を問い合わせる引数、データの最後を示す引数、相手機器のＳＭＰがＯＢＥＸのレスポンスが必要であることを示す引数、受信したデータが正常であったかどうかを示す引数などを入れたＳＭＰヘッダを作成する。そして、このＳＭＰヘッダを、上記分割または結合したデータに付加したデータを入れたデータ送信関数をＬＭＰに対して発する。
さらに、ＳＭＰは、ＬＭＰからデータ通知関数を受けると、該関数内のデータからＳＭＰヘッダを抜き出し、シーケンス番号が正常であるか（すなわち、抜けなく順番に来ているか）を確認する。そして、正常であった場合には、ＯＢＥＸへデータ通知関数を発する。このとき、データ通知関数は、下位層からのデータ通知関数ごとに出力してもよいし、いくつかの下位層からのデータ通知関数のデータをあわせて出力してもよい。
送信機のＳＭＰ（Ｐ）は、ＯＢＥＸ（Ｐ）からのデータ送信関数をＬＭＰ（Ｐ）へのデータ送信関数に変換する。そして、ＯＢＥＸ（Ｐ）からデータの最後であるとした引数がＦａｌｓｅであるデータ送信関数を受けた場合には、そのデータにＳＭＰヘッダを付けたデータを、ＬＭＰ（Ｐ）へ発する。これに対して、ＳＭＰ（Ｐ）は、ＯＢＥＸ（Ｐ）からデータの最後であるとした引数がＴｒｕｅであるデータ送信関数を受けた場合には、そのデータ送信関数の最後のデータを入れた、ＬＭＰ（Ｐ）へのデータ送信関数を、このデータ送信関数がデータの最後であることを示す引数、または、受信機のＯＢＥＸ（Ｓ）のレスポンスが必要であることを示す引数をＴｒｕｅにして発する。
一方、受信機のＳＭＰ（Ｓ）は、データ通知関数を下位層から受けた場合に、そのデータ通知関数内のデータからＳＭＰヘッダを解析し、シーケンシャルな番号を確認する。そして、ＳＭＰ（Ｓ）は、ＳＭＰヘッダを解析して、正常に受信できていることを確認できた場合、ＬＭＰ（Ｓ）に対してデータ送信関数を発する。
これに対して、ＳＭＰ（Ｓ）は、正常に受信できなかったことを検出した場合には、ＯＢＥＸ（Ｓ）にエラーとして通知する。例えば、０，１，２，３，５と受けたとき、５個目は４となるべきなのに４を受けなかった場合である。
そして、それ以降、ＳＭＰ（Ｓ）は、ＳＭＰヘッダのデータの最後を示す引数、または受信機のＯＢＥＸ（Ｓ）のレスポンスが必要であることを示す引数がＴｒｕｅであることを待ち、Ｔｒｕｅであるデータ通知関数を受けるか（なお、受けてもＯＢＥＸ（Ｓ）へは通知はしない）、切断通知関数を受けるか、もしくはある一定時間経つまで、ＯＢＥＸ（Ｓ）へデータ通知を行わないようにする。
つぎに、送信機のＬＭＰ（Ｐ）は、ＳＭＰ（Ｓ）からデータ送信要求関数を受けたときには、その関数内のデータにＬＭＰヘッダをつけてデータを作成し、ＬＡＰ（Ｐ）にそのデータが入ったデータ送信要求関数を発する。
一方、受信機のＬＭＰ（Ｓ）は、ＬＡＰ（Ｓ）からデータ通知関数を受けた場合には、その関数内のデータからＬＭＰヘッダを除いたデータを作成し、ＳＭＰ（Ｓ）にそのデータが入ったデータ通知関数を発する。
なお、１対１で１つの接続をする場合にはＬＭＰを使用する必要がない。この場合、ＬＭＰヘッダにはコネクションレスの値が入ったＬＳＡＰが入る。
送信機のＬＡＰ（Ｐ）は、ＬＭＰ（Ｐ）からデータ送信要求関数を受けたとき、その関数内のデータにＬＡＰヘッダをつけてデータを作成し、物理層にそのデータが入ったＵＩフレームを発する。
一方、受信機のＬＡＰ（Ｓ）は、物理層からデータ受信通知を受けた場合には、そのＵＩフレームのデータからＬＡＰヘッダを除いたデータを作成し、ＬＭＰ（Ｓ）にそのデータが入ったデータ通知関数を発する。なお、本実施の形態では、ＬＡＰヘッダには、接続アドレスとＵＩインジケータが含まれる。
（３−３）切断シーケンス
〔Ａ〕レスポンス有り
図８０は、本実施の形態（レスポンス有り）の切断シーケンスを示すシーケンス図である。また、図８１（ａ），図８１（ｂ）は、本実施の形態（レスポンス有り）の切断シーケンスの際の通信データのデータ構造を示す説明図である。
図８０に示すように、本実施の形態（レスポンス有り）では、送信機の切断コマンドが下位層に伝わっていき、ＤＩＳＣコマンドが発生する。受信機は、そのＤＩＳＣコマンドを受けて上位層へ通知していき、そのレスポンスが返り、ＵＡレスポンスが発生する。その後、送信機の上位層まで、ＵＡレスポンスを受信したことを通知して終了する。
このときの、送信機、受信機内のシーケンスは以下のとおりである。
まず、送信機の各通信層について説明する。
ＯＢＥＸ（Ｐ）は、アプリケーションからの切断要求が来た場合に、速やかに下位層（ＳＭＰ（Ｐ））に対して切断要求コマンドをデータに入れて切断要求関数（Ｐｒｉｍｉｔｉｖｅ）を発生する。また、ＯＢＥＸ（Ｐ）は、ＳＭＰ（Ｐ）から切断確認関数を受けた場合に、そのデータの中からＯＢＥＸ切断のレスポンスを確認し、問題ない（Ｓｕｃｃｅｓｓ）というレスポンスであれば、切断完了とする。
ＳＭＰ（Ｐ）は、ＯＢＥＸ（Ｐ）からの切断要求関数を受けて、速やかにＯＢＥＸ（Ｐ）の切断要求関数のデータに、受信機のＳＭＰ（Ｓ）との通信に必要なパラメータを付加して、下位層（ＬＭＰ（Ｐ））に対して切断要求関数を発生する。また、ＳＭＰ（Ｐ）は、ＬＭＰ（Ｐ）から切断確認関数を受けた場合、関数のデータから受信機のＳＭＰ（Ｓ）が生成したパラメータを抜き取り、値を確認して、ＳＭＰ（Ｓ）との切断処理を終了する。また、ＳＭＰ（Ｐ）は、切断確認関数のデータからＳＭＰ（Ｓ）のパラメータを取り除いたデータをＯＢＥＸ（Ｐ）に対して切断確認関数として送信する。ただし、通常、切断時にＳＭＰ（Ｐ）で新たに追加するパラメータは無い。
ＬＭＰ（Ｐ）は、ＳＭＰ（Ｐ）からの切断要求関数を受けて、速やかにＳＭＰ（Ｐ）の切断要求関数のデータに、受信機のＬＭＰ（Ｓ）との通信に必要なパラメータを付加して、下位層（ＬＡＰ（Ｐ））に対して切断要求関数を発生する。また、ＬＭＰ（Ｐ）は、ＬＡＰ（Ｐ）から切断確認関数を受けた場合、関数のデータから受信機のＬＭＰ（Ｓ）が生成したパラメータを抜き取り、値を確認して、ＬＭＰ（Ｓ）との切断処理を終了する。また、ＬＭＰ（Ｐ）は、切断確認関数のデータからＬＭＰ（Ｓ）のパラメータを取り除いたデータを、ＳＭＰ（Ｐ）に対して切断確認関数として送信する。ただし、通常、切断時にＬＭＰ（Ｐ）で新たに追加するパラメータは無い。
ＬＡＰ（Ｐ）は、ＬＭＰ（Ｐ）からの切断要求関数を受けて、速やかにＬＭＰ（Ｐ）の切断要求関数のデータに、受信機のＬＡＰ（Ｓ）との通信に必要なパラメータを付加して、受信機の物理層に対してＤＩＳＣコマンドを出力する。また、ＬＡＰ（Ｐ）は、受信機の物理層からＵＡレスポンスを受けた場合、ＵＡレスポンスのデータから受信機のＬＡＰ（Ｓ）が生成したパラメータを抜き取り、値を確認して、ＬＡＰ（Ｓ）との接続を終了する。また、ＬＡＰ（Ｐ）は、ＵＡレスポンスのデータからＬＡＰ（Ｓ）のパラメータを取り除いたデータを、ＬＭＰ（Ｐ）に対して切断確認関数として発する。ただし、通常、切断時にＬＡＰ（Ｐ）で新たに追加するパラメータは無い。
つづいて、受信機の各通信層について説明する。
ＯＢＥＸ（Ｓ）は、下位層（ＳＭＰ（Ｓ））から切断通知関数（Ｉｎｄｉｃａｔｉｏｎ）を受けた場合に、そのデータの中からＯＢＥＸ切断コマンドを確認し、問題が無ければＳｕｃｃｅｓｓというレスポンスを切断返答関数（Ｒｅｓｐｏｎｓｅ）としてＳＭＰ（Ｓ）に対して出力し、切断完了とする。
ＳＭＰ（Ｓ）は、下位層（ＳＭＰ（Ｓ））から切断通知関数を受けた場合に、関数のデータから送信機のＳＭＰ（Ｐ）が生成したパラメータを抜き取り、それに対しての返答のパラメータを作成し、上記関数のデータからＳＭＰ（Ｐ）のパラメータを除いたデータを入れた切断要求関数をＯＢＥＸ（Ｓ）に発した後、ＯＢＥＸ（Ｓ）からの切断返答関数を待つ。また、ＳＭＰ（Ｓ）は、ＯＢＥＸ（Ｓ）からの切断返答関数を受けた場合に、ＬＭＰ（Ｓ）に対してＯＢＥＸ（Ｓ）の切断返答関数のデータに上記返答のパラメータを付加して、ＬＭＰ（Ｓ）に対して切断返答関数を発生し、ＳＭＰ層の切断処理を終了する。ただし、通常、切断時にＳＭＰ（Ｓ）で新たに追加するパラメータは無い。
ＬＭＰ（Ｓ）は、下位層（ＬＡＰ（Ｓ））から切断通知関数を受けた場合に、関数のデータから送信機のＬＭＰ（Ｐ）が生成したパラメータを抜き取り、それに対しての返答のパラメータを作成し、上記関数のデータからＬＭＰ（Ｐ）のパラメータを除いたデータを入れた切断要求関数をＳＭＰ（Ｓ）に発した後、ＳＭＰ（Ｓ）からの切断返答関数を待つ。また、ＬＭＰ（Ｓ）は、ＳＭＰ（Ｓ）からの切断返答関数を受けた場合に、ＬＡＰ（Ｓ）に対してＳＭＰ（Ｓ）の切断返答関数のデータに上記返答のパラメータを付加して、ＬＡＰ（Ｓ）に対して切断返答関数を発生し、ＬＭＰ層の切断処理を終了する。ただし、通常、切断時にＬＭＰ（Ｓ）で新たに追加するパラメータは無い。
ＬＡＰ（Ｓ）は、物理層からＤＩＳＣコマンドを受けた場合に、ＤＩＳＣコマンドのデータから送信機のＬＡＰ（Ｐ）が生成したパラメータを抜き取り、ＤＩＳＣコマンドのデータからＬＡＰ（Ｐ）のパラメータを除いたデータを入れた切断要求関数をＬＭＰ（Ｓ）に発した後、それに対しての返答のパラメータを作成し、ＬＭＰ（Ｓ）からの切断返答関数を待つ。また、ＬＡＰ（Ｓ）は、ＬＭＰ（Ｓ）からの切断返答関数を受けた場合に、ＬＭＰ（Ｓ）の切断返答関数のデータに上記返答のパラメータを付加して、物理層に対してＵＡレスポンスを出力し、ＬＡＰ層の切断処理を終了する。ただし、通常、切断時にＬＡＰ（Ｓ）で新たに追加するパラメータは無い。
〔Ｂ〕レスポンス無し
図８２は、本実施の形態（レスポンス無し）の切断シーケンスを示すシーケンス図である。また、図８１（ａ）は、本実施の形態（レスポンス無し）の切断シーケンスの際の通信データのデータ構造を示す説明図である。
図８２に示すように、本実施の形態（レスポンス無し）では、送信機の切断コマンドが下位層に伝わっていき、ＤＩＳＣコマンドが発生する。送信機では、この時点で切断処理が終了する。一方、受信機は、そのＤＩＳＣコマンドを受けて上位層へ伝えていき、上位層まで通知した時点で切断処理が終了する。
このときの、送信機、受信機内のシーケンスは以下のとおりである。
まず、送信機の各通信層について説明する。
ＯＢＥＸ（Ｐ）は、アプリケーションからの切断要求が来た場合に、速やかに下位層（ＳＭＰ（Ｐ））に対して切断要求コマンドをデータに入れて切断要求関数（Ｐｒｉｍｉｔｉｖｅ）を発生する。また、ＯＢＥＸ（Ｐ）は、ＳＭＰ（Ｐ）から切断確認関数を受けた場合に、切断完了とする。
ＳＭＰ（Ｐ）は、ＯＢＥＸ（Ｐ）からの切断要求関数を受けて、速やかにＯＢＥＸ（Ｐ）の切断要求関数のデータに、受信機のＳＭＰ（Ｓ）との通信に必要なパラメータを付加して、下位層（ＬＭＰ（Ｐ））に対して切断要求関数を発生する。また、ＳＭＰ（Ｐ）は、ＬＭＰ（Ｐ）から切断確認関数を受けた時点で、送信したパラメータで切断できたとして、ＳＭＰ層の切断処理を終了する。また、ＳＭＰ（Ｐ）は、ＯＢＥＸ（Ｐ）に対して切断確認関数を送信する。ただし、通常、切断時にＳＭＰ（Ｐ）で新たに追加するパラメータは無い。
ＬＭＰ（Ｐ）は、ＳＭＰ（Ｐ）からの切断要求関数を受けて、速やかにＳＭＰ（Ｐ）の切断要求関数のデータに、受信機のＬＭＰ（Ｓ）との通信に必要なパラメータを付加して、下位層（ＬＡＰ（Ｐ））に対して切断要求関数を発生する。また、ＬＭＰ（Ｐ）は、ＬＡＰ（Ｐ）から切断確認関数を受けた時点で、送信したパラメータで切断できたとして、ＬＭＰ層の切断処理を終了する。また、ＬＭＰ（Ｐ）は、ＳＭＰ（Ｐ）に対して切断確認関数を送信する。ただし、通常、切断時にＬＭＰ（Ｐ）で新たに追加するパラメータは無い。
ＬＡＰ（Ｐ）は、ＬＭＰ（Ｐ）からの切断要求関数を受けて、速やかにＬＭＰ（Ｐ）の切断要求関数のデータに、受信機のＬＡＰ（Ｓ）との通信に必要なパラメータを付加して、受信機の物理層に対してＤＩＳＣコマンドを出力する。また、ＬＡＰ（Ｐ）は、ＤＩＳＣコマンドを出力した時点で、送信したパラメータで切断できたとして、ＬＡＰ層の切断処理を終了する。また、ＬＡＰ（Ｐ）は、ＬＭＰ（Ｐ）に対して切断確認関数を発する。ただし、通常、切断時にＬＡＰ（Ｐ）で新たに追加するパラメータは無い。
つづいて、受信機の各通信層について説明する。
ＯＢＥＸ（Ｓ）は、下位層（ＳＭＰ（Ｓ））から切断通知関数（Ｉｎｄｉｃａｔｉｏｎ）を受けた場合に、そのデータの中からＯＢＥＸ切断コマンドを確認し、問題が無ければ、切断完了とする。
ＳＭＰ（Ｓ）は、下位層（ＳＭＰ（Ｓ））から切断通知関数を受けた場合に、関数のデータから送信機のＳＭＰ（Ｐ）が生成したパラメータを抜き取り、そのパラメータを使用して切断を完了させる。また、ＳＭＰ（Ｓ）は、上記関数のデータからＳＭＰ（Ｐ）のパラメータを除いたデータを入れた切断要求関数をＯＢＥＸ（Ｓ）に発する。ただし、通常、切断時にＳＭＰ（Ｓ）で新たに追加するパラメータは無い。
ＬＭＰ（Ｓ）は、下位層（ＬＡＰ（Ｓ））から切断通知関数を受けた場合に、関数のデータから送信機のＬＭＰ（Ｐ）が生成したパラメータを抜き取り、そのパラメータを使用して切断を完了させる。また、ＬＭＰ（Ｓ）は、上記関数のデータからＬＭＰ（Ｐ）のパラメータを除いたデータを入れた切断要求関数をＳＭＰ（Ｓ）に発する。ただし、通常、切断時にＬＭＰ（Ｓ）で新たに追加するパラメータは無い。
ＬＡＰ（Ｓ）は、物理層からＤＩＳＣコマンドを受けた場合に、ＤＩＳＣコマンドのデータから送信機のＬＡＰ（Ｐ）が生成したパラメータを抜き取り、そのパラメータを使用して切断を完了させる。また、ＬＡＰ（Ｓ）は、ＤＩＳＣコマンドのデータからＬＡＰ（Ｐ）のパラメータを除いたデータを入れた切断要求関数をＬＭＰ（Ｓ）に発する。ただし、通常、切断時にＬＡＰ（Ｓ）で新たに追加するパラメータは無い。
（４）レスポンスの有無の切換え
図８３〜図９０を参照しながら、送信機および受信機の通信層間におけるデータおよびパラメータの流れを説明する。
本実施の形態では、送信機および受信機の各通信層ＬＡＰ、ＬＭＰ、ＳＭＰ、ＯＢＥＸは、接続要求関数、接続通知関数、接続応答関数、接続確認関数を持っている。これらの関数は、上位層（つまり、ＬＭＰ層）からＬＡＰ層へアクセスするための関数である。
そして、上記関数は、引数として、Ｄａｔａ（以下、データと記す）とＲｅｑｕｅｓｔｅｄ−ＱｏｓまたはＲｅｔｕｒｎｅｄ−ＱｏＳが指定できる。上記データは、上述したように、各通信層において設定される。
一方、Ｑｏｓは、ＬＡＰで決定されたボーレート等のネゴシエーションパラメータの指定やネゴシエーション結果を、ＯＢＥＸを含めた上位層に通知する。なお、Ｑｏｓは従来のＩｒＤＡでも使用されている。
例えば、送信機のアプリケーションもしくはＯＢＥＸ（Ｐ）が、レスポンスが必要／不要というパラメータの入ったＱｏＳを発すると、それが下位層へ順にＬＡＰ（Ｐ）まで伝わる。そして、ＬＡＰ（Ｐ）は、そのＱｏＳの値をネゴシエーションパラメータ（Ａｃｋ Ｌｅｓｓ Ｃｏｎｎｅｃｔ）の値として反映させ、受信機へ送信する。
その結果、送信機および受信機の各通信層が、送信機のアプリケーションもしくはＯＢＥＸ（Ｐ）によるレスポンス必要／不要の指定に従って動作するため、双方向／片方向の接続ができることになる。
図８３〜図８７は、本実施の形態（レスポンス有り）の接続シーケンス（図７４）のときの、通信層間のデータおよびパラメータの流れを示す説明図である。なお、ＯＢＥＸ−ＳＭＰ間、ＳＭＰ−ＬＭＰ間、ＬＭＰ−ＬＡＰ間のＱｏＳのパラメータは、同一であってもよいが、異なっていてもよい。それゆえ、図中では、−ａ，−ｂ，−ｃを付して区別している。
送信機では、図８３に示すように、ｃｏｎ．ｒｅｑ（ｄａｔａ）（図７４）によって、受信機へ送信するＤａｔａとＱｏＳ−１（送信機の要求するＱｏＳ）のデータとを上位層から下位層に渡す。
一方、受信機では、図８４に示すように、ｃｏｎ．ｒｅｑによって、ＱｏＳ−２（受信機の要求するＱｏＳ）のデータのみを上位層から下位層にそれぞれ渡す。
その後、受信機では、ＬＡＰ（Ｓ）がＳＮＲＭコマンドを受けた時点で、送信機のＱｏＳ−１と自機のＱｏＳ−２を比較して、共通でネゴシエートしたパラメータとしてＱｏＳ−３を作成する。そして、図８５に示すように、ＬＡＰ（Ｓ）は、ｃｏｎ．ｉｎｄ（ｄａｔａ）によって、ＱｏＳ−３を送信機からのデータと一緒に上位層へ通知する。各上位層は、このＱｏＳ−３を記憶して、接続時における接続パラメータとして保持する。
つづいて、受信機では、ｃｏｎ．ｒｅｓｐ（ｄａｔａ）を通知する際、ＱｏＳが不要となっている。よって、図８６に示すように、ｃｏｎ．ｒｅｓｐ（ｄａｔａ）ではデータのみが上位層から下位層に渡されていく。そして、ＬＡＰ（Ｓ）がｃｏｎ．ｒｅｓｐ（ｄａｔａ）を受けると、ＵＡレスポンスにＱｏＳ−３を入れて、ＵＡレスポンスを発する。
つづいて、送信機では、ＬＡＰ（Ｐ）がＵＡレスポンスを受けてＱｏＳ−３をネゴシエートしたパラメータとして記憶する。そして、ＬＡＰ（Ｐ）は、図８７に示すように、ｃｏｎ．ｃｏｎｆ（ｄａｔａ）によって、ＱｏＳ−３を受信機のデータと一緒に上位層へ通知する。各通信層は、このＱｏＳ−３を、確立させた接続における接続パラメータとして保持する。
本実施の形態では、例えば、ｃｏｎ．ｒｅｑのＱｏＳとして、Ｒｅｑｕｅｓｔｅｄ−ＱｏＳ：Ｂａｕｄ−Ｒａｔｅ＋Ｍａｘ−Ｔｕｒｎ−Ａｒｏｕｎｄ−Ｔｉｍｅ＋Ｄｉｓｃｏｎｎｅｃｔ−Ｔｈｒｅｓｈｏｌｄ＋ＤａｔａＳｉｚｅ＋Ａｃｋ ｌｅｓｓ ｃｏｎｎｅｃｔｉｏｎ＋Ｍｉｎ−Ｐａｃｋｅｔ−Ｉｎｔｅｒｖａｌ、を使用する。また、Ｃｏｎ．ｉｎｄ，ｃｏｎ．ｃｏｎｆのＱｏＳとして、Ｒｅｓｕｌｔａｎｔ−ＱｏＳ：Ｂａｕｄ−Ｒａｔｅ＋Ｄｉｓｃｏｎｎｅｃｔ−Ｔｈｒｅｓｈｏｌｄ＋ＤａｔａＳｉｚｅ＋Ａｃｋ ｌｅｓｓ ｃｏｎｎｅｃｔｉｏｎ（ｉｎｄｉｃａｔｉｏｎ ｐｒｉｍｉｔｉｖｅ ｏｎｌｙ）、を使用する。
また、本実施の形態（レスポンス無し）の接続シーケンス（図７６）のときには、通信層間のデータおよびパラメータの流れは次のようになる。
送信機では、図８３に示すように、ｃｏｎ．ｒｅｑ（ｄａｔａ）（図７６）によって、受信機へ送信するＤａｔａとＱｏＳ−１（送信機の要求するＱｏＳ）のデータとを上位層から下位層に渡す。
そして、送信機のＬＡＰ（Ｐ）は、ＱｏＳ−１をそのままＱｏＳ−３として記憶する。そして、ＬＡＰ（Ｐ）は、図８７に示すように、ｃｏｎ．ｃｏｎｆによってＱｏＳ−３を上位層へ通知する。各通信層は、このＱｏＳ−３を、確立させた接続における接続パラメータとして保持する。
一方、受信機では、図８４に示すように、ｃｏｎ．ｒｅｑによって、ＱｏＳ−２（受信機の要求するＱｏＳ）のデータのみを上位層から下位層にそれぞれ渡す。
その後、受信機では、ＬＡＰ（Ｓ）がＳＮＲＭコマンドを受けた時点で、送信機のＱｏＳ−１をもって、ＱｏＳ−３とする。なお、ＱｏＳ−２のパラメータがＱｏＳ−１との組み合わせで満足しない場合には受信できない。
つづいて、図８５に示すように、ＬＡＰ（Ｓ）は、ｃｏｎ．ｉｎｄ（ｄａｔａ）によって、ＱｏＳ−３を送信機からのデータと一緒に上位層へ通知する。各上位層は、このＱｏＳ−３を記憶して、接続時における接続パラメータとして保持する。
これにより、レスポンス有り／無しを、アプリケーションが上記ＱｏＳ−１とＱｏＳ−２を上位層（アプリケーション）操作することで、切り替えることができる。
ここで、レスポンス有り／無しの切換えの基準としては、送信するファイルのファイル形式、アプリケーション、ユーザの選択等が考えられる。
具体的には、ファイル形式を基準とする場合、例えば、マルチメディア関連ファイルの場合にはレスポンス有り／無し両方選べるようにし、電話帳、メール、スケジュール等のファイルであってデータが受信されたことを確認したい場合にはレスポンス有りが自動的に選択されるようにしてもよい。また、アプリケーションを基準とする場合、例えば、スライドショーの場合にはレスポンス無しが自動的に選択されるようにしてもよい。また、ユーザの選択による場合、例えば、レスポンス有り／無しのメニュー表示からユーザに選択させるようにしてもよい。
図８８〜図９０は、本実施の形態の接続シーケンスのときの、通信層間のデータおよびパラメータの流れの変形例を示す説明図である。
送信機において最初のＳＮＲＭコマンドにすべての通信層の情報が含まれる場合に（図７４）、データやパラメータを各通信層でリレーしながら伝達する（図８３）のではなく、図８８のように、各通信層からＬＡＰ層へ直接渡すように構成することもできる。
また逆に、図８９のように、受信機において、ＳＮＲＭコマンドに含まれるデータやパラメータをすべて取り出し、宛先である各通信層へＬＡＰ層から直接渡すように構成することもできる。
また、図９０のように、送信機において、ＯＢＥＸ（Ｐ）、ＳＭＰ（Ｐ）、ＬＭＰ（Ｐ）のデータやパラメータをＬＭＰ（Ｐ）で統合し、さらに、ＬＡＰ（Ｐ）にて、上記統合したデータやパラメータにＬＡＰ（Ｐ）のパラメータを追加してＳＮＲＭコマンドを生成するように構成することもできる。
なお、上記各実施の形態における送信機（一次局）としては、例えば、携帯電話機、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）、デジタルカメラ、パーソナルコンピユータなどが挙げられる。また、受信機（二次局）としては、例えば、携帯電話機、テレビ、ＡＶ機器、ＤＶＤレコーダ、ＨＤＤレコーダなどの記録装置、プリンタ、パーソナルコンピュータなどの電子機器が挙げられる。
また、前述した送信機（一次局）または受信機（二次局）の各ブロックは、ハードウェアロジック（通信回路）によって構成してもよいし、次のようにＣＰＵなどの演算処理装置を用いてソフトウェアによって実現してもよい。
すなわち、前述した送信機または受信機は、各機能を実現する制御プログラムの命令を実行するＣＰＵ（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）、上記プログラムを格納したＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、上記プログラムを展開するＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、上記プログラムおよび各種データを格納するメモリ等の記憶装置（記録媒体）などを備えている。
そして、本発明の目的は、上述した機能を実現するソフトウェアである送信機または受信機の通信プログラムのプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録した記録媒体を、上記送信機または受信機に供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。
上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ系、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクやＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ−Ｒ等の光ディスクを含むディスク系、ＩＣカード（メモリカードを含む）／光カード等のカード系、あるいはマスクＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ／フラッシュＲＯＭ等の半導体メモリ系などを用いることができる。
また、送信機または受信機を通信ネットワークと接続可能に構成し、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークとしては、特に限定されず、例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（ｖｉｒｔｕａｌ ｐｒｉｖａｔｅ ｎｅｔｗｏｒｋ）、電話回線網、移動体通信網、衛星通信網等が利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された搬送波あるいはデータ信号列の形態でも実現され得る。
以上のように、本発明に係る通信機器は、一度に送信可能なフレーム数に制限がない通信方式に従って、送信権を委譲せずに、データを一括送信する通信機器であって、一括送信する一括送信データを分割して送信フレームを生成する送信フレーム生成手段と、上記送信フレームに通し番号を付与する通し番号生成手段と、上記一括送信データの最終の送信フレームに、一括送信データの最終の送信フレームであることを示す一括送信最終フラグを設定する一括送信最終フラグ生成手段と、上記送信フレームを送信する送信手段と、を備えることを特徴としている。
また、本発明に係る通信方法は、一度に送信可能なフレーム数に制限がない通信方式に従って、送信権を委譲せずに、データを一括送信する通信方法であって、一括送信する一括送信データを分割して送信フレームを生成し、上記送信フレームに通し番号を付与し、上記一括送信データの最終の送信フレームには、一括送信データの最終の送信フレームであることを示す一括送信最終フラグを設定して、上記送信フレームを送信することを特徴としている。
さらに、本発明に係る通信機器は、受信した受信フレームからエラー無しフラグおよび通し番号を抽出する受信フレーム解析手段と、上記エラー無しフラグを解析してエラーの有無を判定するエラー無しフラグ解析手段と、上記エラー無しフラグがエラー有りを示している場合、上記通し番号に対応する送信フレームを再送する制御手段と、を備えることを特徴としている。
また、本発明に係る通信機器は、一度に送信可能なフレーム数に制限がない通信方式に従って、送信権を委譲されずに、データを一括受信する通信機器であって、上記受信フレームに含まれる通し番号を解析して、通し番号のエラーがないかどうかを判別する通し番号解析手段と、上記受信フレームに含まれる一括送信最終フラグが、当該受信フレームが送信機によって複数の送信フレームに分割されて一括送信された一括送信データの最終の送信フレームであることを示しているとき、上記通し番号解析手段によって、それまでに受信した受信フレームにエラーが検出された場合、エラー有りを示すように設定したエラー無しフラグおよびエラー発生時の通し番号を含む送信フレームを生成する送信フレーム生成手段と、上記送信フレームを送信する送信手段と、を備えることを特徴としている。
また、本発明に係る通信方法は、一度に送信可能なフレーム数に制限がない通信方式に従って、送信権を委譲されずに、データを一括受信する通信方法であって、上記受信フレームに含まれる通し番号を解析して、通し番号のエラーがないかどうかを判別し、上記受信フレームに含まれる一括送信最終フラグが、当該受信フレームが送信機によって複数の送信フレームに分割されて一括送信された一括送信データの最終の送信フレームであることを示しているとき、それまでに受信した受信フレームにエラーが検出された場合、エラー有りを示すように設定したエラー無しフラグおよびエラー発生時の通し番号を含む送信フレームを生成し、上記送信フレームを送信することを特徴としている。
また、本発明に係る通信システムは、上記の送信機としての通信機器と、上記の受信機としての通信機器とを含むことを特徴としている。
上記の構成および方法により、一度に送信可能なフレーム数に制限がない通信方式に従って、送信権を委譲せずに、データを一括送信する際に、送信機では、一括送信データを分割して送信フレームを生成し、送信フレームに通し番号を付与するとともに、さらに、一括送信データの最終の送信フレームには、一括送信データの最終の送信フレームであることを示す一括送信最終フラグを設定して、送信フレームを送信する。一方、受信機では、受信フレームに含まれる通し番号を解析して、通し番号のエラーがないかどうかを判別し、受信フレームにエラーが検出された場合、エラー有りを示すように設定したエラー無しフラグおよびエラー発生時の通し番号を含む送信フレームを生成して、送信機へ送信する。そして、送信機は、受信機から、エラー発生時の通し番号を含むフレームを受信すると、その通し番号に対応する送信フレームを再送する。
ここで、受信機は、送信機が一括送信データを分割した送信フレームの内の最終の送信フレームを受信したことが、受信フレームに含まれる一括送信最終フラグによって判明するまで、上記エラー発生時の通し番号を含む送信フレームを送信しない。つまり、エラーの通知を一括送信データ単位で行う。
よって、一度に送信または受信可能なフレーム数（ウィンドウサイズ）の制限がない通信方式を用いても、フレームの抜け等を検出して、再送することができるため、信頼性の高い通信を行うことが可能となる。また、エラーの通知を一括送信データ単位で行うため、データ転送の効率がよい。
さらに、本発明に係る通信機器は、１つの送信データを複数の上記一括送信データに分割して送信する際、当該送信データの最終の送信フレームに、送信データの最終の送信フレームであることを示すデータ最終フラグを設定するデータ最終フラグ生成手段を備えることを特徴としている。
上記の構成によれば、さらに、受信機に送信データの終わりを知らせることができる。それゆえ、受信機では、例えば受信バッファ内のデータの処理を効率よく開始することが可能となる。
さらに、本発明に係る通信機器は、上記通信方式が、ＩｒＬＡＰ（Ｉｎｆｒａｒｅｄ Ｌｉｎｋ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）のＵＩ（Ｕｎｎｕｍｂｅｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ）フレームを用いた通信であることを特徴としている。
上記の構成によれば、さらに、一度に送信または受信可能なフレーム数（ウィンドウサイズ）の制限がない通信方式として、ＩｒＬＡＰのＵＩフレームを用いることができる。すなわち、ＩｒＬＡＰのＵＩフレームを用いて、再送を行うことが可能となる。
さらに、本発明に係る通信機器は、上記送信フレームには、ＯＢＥＸ（Ｏｂｊｅｃｔ Ｅｘｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ）の最終のＰＵＴコマンドまたは最終でないＰＵＴコマンドの少なくとも一部が含まれていることを特徴としている。
上記の構成によれば、さらに、ＯＢＥＸＰＵＴコマンドを用いて、品質および転送効率の高い再送を行うことが可能となる。
さらに、本発明に係る通信機器は、上記送信フレームには、ＯＢＥＸ（Ｏｂｊｅｃｔ Ｅｘｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ）のＳＵＣＣＥＳＳレスポンスの一部もしくは全てが含まれていることを特徴としている。
上記の構成によれば、送信機からＯＢＥＸのＰｕｔコマンドでのデータ転送が行われた場合、ＯＢＥＸのＳＵＣＣＥＳＳレスポンスを送信することが可能となり、ＯＢＥＸのＰｕｔオペレーションを用いた通信が可能となる。
また、本発明に係る通信機器は、一度に送信可能なフレーム数に制限がない通信方式に従って、送信権を委譲されずに、データを一括受信する通信機器であって、受信した受信フレームにエラーがないかどうかを判別するためのエラー検出手段と、上記受信フレームに含まれる一括送信最終フラグが、当該受信フレームが送信機によって複数の送信フレームに分割されて一括送信された一括送信データの最終の送信フレームであることを示しているとき、上記エラー検出手段によって、それまでに受信した受信フレームにエラーが検出されているか否かに応じて、エラーの有無を示すように設定したエラー無しフラグを含む送信フレームを生成する送信フレーム生成手段と、上記送信フレームを送信する送信手段と、を備えることを特徴としている。
上記の構成によれば、送信機に対してエラーの有無を通知することが可能となる。それゆえ、これを受けた送信機が再送を行うことが可能となる。
よって、一度に送信または受信可能なフレーム数（ウィンドウサイズ）の制限がない通信方式を用いても、フレームの抜け等を検出して、再送することができるため、信頼性の高い通信を行うことが可能となる。また、エラーの通知を一括送信データ単位で行うため、データ転送の効率がよい。
また、本発明に係る通信機器は、オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ Ｅｘｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、オブジェクトを送信する通信機器であって、ＯＢＥＸコマンドを送信後、受信機からのＯＢＥＸレスポンスを受信することなく、次のＯＢＥＸコマンドを送信するＯＢＥＸ層処理部を備えることを特徴としている。
また、本発明に係る通信方法は、オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、オブジェクトを送信する通信方法であって、ＯＢＥＸコマンドを送信後、受信機からのＯＢＥＸレスポンスを受信することなく、次のＯＢＥＸコマンドを送信することを特徴としている。
上記の構成および方法によれば、送信機は、受信機からのＯＢＥＸレスポンスを受信しなくても、次のＯＢＥＸコマンドを送信することができる。よって、送信機からの要求コマンドに対する応答コマンドを受信機が送信しない場合、あるいは、受信機に送信機能がない場合においても、ＯＢＥＸによってオブジェクトを転送することが可能となる。すなわち、ＯＢＥＸを用いた片方向通信が実現できる。
また、本発明に係る通信機器は、オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、オブジェクトを送信する通信機器であって、ＯＢＥＸの最終でないＰｕｔコマンドを送信後のみ、受信機からのＯＢＥＸレスポンスを受信することなく、次のＯＢＥＸの最終でないＰｕｔコマンドもしくは最終のＰｕｔコマンドを送信するＯＢＥＸ層処理部を備えることを特徴としている。
また、本発明に係る通信方法は、オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、オブジェクトを送信する通信方法であって、ＯＢＥＸの最終でないＰｕｔコマンドを送信後のみ、受信機からのＯＢＥＸレスポンスを受信することなく、次のＯＢＥＸの最終でないＰｕｔコマンドもしくは最終のＰｕｔコマンドを送信することを特徴としている。
上記の構成および方法によれば、最終でないＰｕｔコマンドのレスポンス（ＣＯＮＴＩＮＵＥ応答コマンド）を省略することによって、効率のよいデータ転送を実現することができる。
また、本発明に係る通信機器は、オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、送信機からオブジェクトを受信する通信機器であって、ＯＢＥＸコマンドを受信後に、ＯＢＥＸレスポンスを常に送信しないＯＢＥＸ層処理部を備えることを特徴としている。
また、本発明に係る通信方法は、オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、送信機からオブジェクトを受信する通信方法であって、ＯＢＥＸコマンドを受信後に、ＯＢＥＸレスポンスを常に送信しないことを特徴としている。
上記の構成および方法によれば、送信機が受信機からのＯＢＥＸレスポンスを受信しなくても、次のＯＢＥＸコマンドを送信することができる場合、受信機において、不必要な応答コマンドの生成および送信を行わないという制御を行うことが可能となる。よって、ＯＢＥＸを用いた片方向通信が実現できる。
また、本発明に係る通信機器は、オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、送信機からオブジェクトを受信する通信機器であって、ＯＢＥＸの最終でないＰｕｔコマンド受信時には、ＯＢＥＸレスポンスの送信を行わず、最終のＰｕｔコマンド受信時には、ＯＢＥＸのレスポンスの送信を行うＯＢＥＸ層処理部を備えることを特徴としている。
また、本発明に係る通信方法は、オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、送信機からオブジェクトを受信する通信方法であって、ＯＢＥＸの最終でないＰｕｔコマンド受信時には、ＯＢＥＸレスポンスの送信を行わず、最終のＰｕｔコマンド受信時には、ＯＢＥＸのレスポンスの送信を行うことを特徴としている。
上記の構成および方法によれば、最終でないＰｕｔコマンドのレスポンス（ＣＯＮＴＩＮＵＥ応答コマンド）を省略することによって、効率のよいデータ転送を実現することができる。
なお、上記通信機器は、コンピュータによって実現してもよく、この場合には、コンピュータを上記通信機器の各部として動作させることにより上記通信機器をコンピュータにて実現させる通信機器の通信プログラム、およびそれを記録したコンピュータ読み取り可能な記録媒体も、本発明の範疇に入る。
また、上記通信機器は、上記の各部として機能する通信回路によって実現してもよい。
また、上記通信機器は、該通信機器によって通信を行う携帯電話に好適である。上記携帯電話によれば、品質および／あるいは転送効率の高い通信を行うことが可能となる。
また、上記通信機器は、該通信機器によって受信したデータに基づいて表示する表示装置に好適である。このような表示装置によれば、品質および／あるいは転送効率の高い通信を行うことが可能となる。
また、上記通信機器は、該通信機器によって受信したデータに基づいて印刷する印刷装置に好適である。このような印刷装置によれば、品質および／あるいは転送効率の高い通信を行うことが可能となる。
また、上記通信機器は、該通信機器によって受信したデータを記録する記録装置に好適である。このような記録装置によれば、品質および／あるいは転送効率の高い通信を行うことが可能となる。
さらに、本発明は以下のように構成してもよい。
〔一次局〕
（１．一次局がＬＡＰ層のＵＩフレームに通し番号及びＢＬフラグをつけて送信）
本発明に係る通信機器〔１〕は、ウィンドウサイズ（一度に送信または受信可能なフレーム数）の制限がない通信方式を用いて、あるまとまったサイズのデータを、送信権を委譲せずに、一括送信する通信機器であって、送信フレームに通し番号、一括送信データの終わりを示すフラグ、および送信データを付与して送信フレームを生成する回路と、前記、送信フレームを送信する回路とを有し、データ転送時において、前記、一括送信データの終わりを示すフラグがデータの終わりを示す値を設定して送信するまで、前記通し番号を予め定められた値だけ増減していくことを特徴とする。
上記の構成によれば、ウィンドウサイズの制限がない通信方式を用いても、上記フレームを受信した通信機器は、フレームのぬけを検出することができ、信頼性の高い通信を行うことが可能となる。
（２．二次局から再送要求がきたら、すべて再送）
本発明に係る通信機器〔２〕は、上記通信機器〔１〕において、対向局から受信したフレーム内のエラー無しフラグがエラー有りを示している場合は、最初からデータを再送することを特徴とする。
上記の構成によれば、対向局がエラーにより再送要求を行っている場合は、再送を行うことが可能となる。
（３．すべて再送時に通し番号を０からにする）
本発明に係る通信機器〔３〕は、上記通信機器〔２〕において、前記再送する際に、１つめのフレーム送信時に通し番号を予め定められたルールでの初期値とすることを特徴とする。
上記の構成によれば、これを受信した通信機器は、再送が最初から行われていることを知ることが可能となる。
（４．すべて再送は１回のみ）
本発明に係る通信機器〔４〕は、上記通信機器〔２〕において、前記再送は１回のみであることを特徴とする。
上記の構成によれば、通信路の品質が悪い場合の再送による消費電力の削減を行うことが可能となる。
（５．すべて再送に回数の制限を設ける）
本発明に係る通信機器〔５〕は、上記通信機器〔２〕において、前記再送は予め定められた値以下であることを特徴とする。
上記の構成によれば、通信路の品質によって、再送回数の制限を変更することが可能となり、より効率の高い消費電力の低減を行うことが可能となる。
（６．二次局から再送要求された通し番号からの再送）
本発明に係る通信機器〔６〕は、上記通信機器〔１〕において、対向局から受信したフレーム内のエラー無しフラグがエラー有りを示している場合は、それまでに送信したフレームのうち、受信したフレーム内の通し番号に相当するフレームから再送を行うことを特徴とする。
上記の構成によれば、対向局から要求された通し番号からの再送が可能となり、エラー時の転送効率が高くなる。
（７．二次局から再送要求された通し番号からの再送（通し番号も戻す））
本発明に係る通信機器〔７〕は、上記通信機器〔６〕において、前記再送する際に、１つめのフレーム送信時に通し番号を直前に受信したフレーム内の通し番号とすることを特徴とする。
上記の構成によれば、対向局がデータの再送開始場所を知ることが可能となる。
（８．二次局が指定した通し番号からの再送は１回のみ）
本発明に係る通信機器〔８〕は、上記通信機器〔６〕において、前記再送は１回のみであることを特徴とする。
上記の構成によれば、通信路の品質が悪い場合の再送による消費電力の削減を行うことが可能となる。
（９．二次局が指定した通し番号からの再送に回数の制限を設ける）
本発明に係る通信機器〔９〕は、上記通信機器〔６〕において、前記再送は予め定められた値以下であることを特徴とする。
上記の構成によれば、通信路の品質によって、再送回数の制限を変更することが可能となり、より効率の高い消費電力の低減を行うことが可能となる。
（１０．二次局から再送要求がなかったら、通し番号を増やして送信）
本発明に係る通信機器〔１０〕は、上記通信機器〔１〕において、対向局から受信したフレーム内のエラー無しフラグがエラー無しを示している場合は、前回送信したフレームの通し番号を予め定められた値だけ増やした値を、通し番号として付与し、送信を行うことを特徴とする。
上記の構成によれば、対向局から再送要求がない場合は、引き続きデータの送信を行うことが可能となる。
（１１．ＢＬ＝１とするデータサイズの単位は受信側のバッファサイズで決まる）
本発明に係る通信機器〔１１〕は、上記通信機器〔１〕において、接続時に対向局から受信した対向局の一括受信可能データサイズを保持し、送信フレーム内の送信データの累計が前記接続時に対向局から受信したデータサイズ以下で、前記一括送信データの終わりを示すフラグをデータの終わりの意味する値として設定し、送信することを特徴とする。
上記の構成によれば、受信側のバッファがあふれてオーバーランエラーが起きる状態を未然に防ぐことが可能となる。
（１２．ブロックサイズパラメータを受信しなかった場合は、デフォルト値をブロックサイズとする）
本発明に係る通信機器〔１２〕は、上記通信機器〔１１〕において、接続時に対向局から対向局の一括受信可能データサイズを受信しなかった場合は、予め定められた値以下で一括送信データの終わりを示すフラグをデータの終わりの意味する値として設定し、送信することを特徴とする。
上記の構成によれば、対向局との間で、デフォルト値を定めていれば、対向局はデフォルト値での通信が可能であるならば、接続時に受信バッファを対向局に対して通知する必要がなくなる。
（１３．一次局がＢＬ＝１として送信した後、タイムアウトしたら直前の送信フレームを再送する）
本発明に係る通信機器〔１３〕は、上記通信機器〔１〕において、特にタイマを持ち、前記、一括送信データの終わりを示すフラグをデータの終わりの意味として設定してフレームを送信後、予め定められた一定時間、対向局からフレームを受信しなかった場合、直前に送信したフレームのみを再送することを特徴とする。
上記の構成によれば、一括送信データの終わりを示すフラグを含むフレームにエラーが発生し、対向局にて正常に受信できない場合に、再送することが可能となる。
（１４．一次局がＢＬ＝１のフレームを再送するのは１回のみ）
本発明に係る通信機器〔１４〕は、上記通信機器〔１３〕において、前記再送は１回のみであることを特徴とする。
上記の構成によれば、通信路の品質が悪い場合の再送による消費電力の削減を行うことが可能となる。
（１５．一次局がＢＬ＝１のフレームを再送するのに制限を設ける）
本発明に係る通信機器〔１５〕は、上記通信機器〔１３〕において、前記再送は予め定められた回数以下であることを特徴とする。
上記の構成によれば、通信路の品質によって、再送回数の制限を変更することが可能となり、より効率の高い消費電力の低減を行うことが可能となる。
（１６．一次局が全てのフレーム送信時にＢＬ＝１とする）
本発明に係る通信機器〔１６〕は、上記通信機器〔１〕において、全ての送信フレームにおいて、前記一括送信データの終わりを示すフラグをデータの終わりを示す値として設定して送信することを特徴とする。
上記の構成によれば、再送のために必要とする送信バッファのサイズを小さく抑えることが可能となる。
（１７．一次局が上位層からのデータの終わりを示すフラグを設定する）
本発明に係る通信機器〔１７〕は、上記通信機器〔１〕において、特に自局の送信データの終わりを示すフラグを設定する回路を有し、自局の送信データの終わりを送信する場合、前記自局の送信データの終わりを示すフラグをデータの終わりを意味する値に設定し、送信することを特徴とする。
上記の構成によれば、対向局は、送信データの終わりを知ることが可能となる。
（１８．一次局がＩｒＤＡのＵＩフレームによる双方向通信を行う）
本発明に係る通信機器〔１８〕は、上記通信機器〔１〕〜〔１７〕のいずれかにおいて、前記ウィンドウサイズの制限がない通信方式とは、ＩｒＬＡＰ（Ｉｎｆｒａｒｅｄ Ｌｉｎｋ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）のＵＩフレームを用いた通信であることを特徴とする。
上記の構成によれば、ＩｒＬＡＰのＵＩフレームを用いて、再送を行うことが可能となる。
（１９．一次局が片方向送信でＬＡＰ層のＵＩフレームに通し番号をつけて送信）
本発明に係る通信機器〔１９〕は、ＩｒＬＡＰ（Ｉｎｆｒａｒｅｄ Ｌｉｎｋ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）のＵＩフレームを用いて、対向局からのレスポンスを必要としない通信を行う場合において、ＵＩフレームに通し番号および送信データを付与して送信フレームを生成する回路と、前記、送信フレームを送信する回路とを有し、データ転送時において、前記通し番号を予め定められた値だけ増減していくことを特徴とする。
上記の構成によれば、ＩｒＤＡのＵＩフレームを用いても、片方向通信において、受信したフレームに抜けがあるかどうかを検出することが可能となり、通信の品質の向上につながる。
（２０．一次局が片方向通信でＵＩフレームに通し番号に加えてＤＬフラグをつけて送信）
本発明に係る通信機器〔２０〕は、上記通信機器〔１９〕において、特に送信データの終わりを示すフラグを生成する回路を有し、前記送信データの終わりを示すフラグを設定して送信することを特徴とする。
上記の構成によれば、受信側が前記送信データの終わりを示すフラグを受信した時点で、所望の処理を行うことが可能である。
（２１．一次局が送信するデータはＯＢＥＸのＰＵＴコマンドである）
本発明に係る通信機器〔２１〕は、上記通信機器〔１〕〜〔２０〕のいずれかにおいて、前記送信データには、ＯＢＥＸ（Ｏｂｊｅｃｔ Ｅｘｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ）のＰｕｔ（Ｆｉｎａｌもしくはｎｏｔ Ｆｉｎａｌ）コマンドの一部もしくは全てが含まれていることを特徴とする。
上記の構成によれば、ＯＢＥＸのＰｕｔコマンドを用いた通信が可能となる。
〔二次局〕
（２２．二次局がＢＬ＝１のフレームを受信したらエラーの有無を一次局に通知）
本発明に係る通信機器〔２２〕は、ウィンドウサイズ（一度に送信または受信可能なフレーム数）の制限がない通信方式を用いて、あるまとまったサイズのデータを、送信権が委譲されずに、一括受信する通信機器であって、受信フレームにエラーがないかどうかを判別するための誤り検出回路と、受信フレーム内のデータを受信バッファに保存する回路と、受信バッファ内のデータを処理する回路と、一括送信データの終わりを示すフラグを判別する回路と、エラー無しフラグを付与して、送信フレームを生成する回路と、前記送信フレームを送信する回路とを有し、データ転送時において、受信フレーム中の前記一括送信データの終わりを示すフラグがデータの終わりを意味している場合に、それまでに受信したフレームにおいてエラーが検出されなかった場合は、前記エラー無しフラグをエラー無しの意味とし、エラーが検出された場合は、前記エラー無しフラグをエラーありの意味としてフレームを生成し、送信することを特徴とする。
上記の構成によれば、対向局に対してエラーの有無を通知することが可能となる。これを受けた対向局は再送を行うことが可能となる。
（２３．二次局がＢＬ＝１のフレームを受信したら、エラーの有無とエラー時の通し番号を一次局に通知）
本発明に係る通信機器〔２３〕は、ウィンドウサイズ（一度に送信または受信可能なフレーム数）の制限がない通信方式を用いて、あるまとまったサイズのデータを、送信権が委譲されずに、一括受信する通信機器であって、受信フレームにエラーがないかどうかを判別するための誤り検出回路と、受信すべき通し番号を算出する回路と、受信すべき通し番号と受信したフレームの通し番号を比較する回路と、受信フレーム内のデータを受信バッファに保存する回路と、受信バッファ内のデータを処理する回路と、エラーを検出したフレームの通し番号を保持する回路と、一括送信データの終わりを示すフラグを判別する回路と、エラー無しフラグおよび、エラーがある場合は、エラー発生時の通し番号を合わせて付与して送信フレームを生成する回路と、前記送信フレームを送信する回路とを有し、データ転送時において、受信フレーム中の前記一括送信データの終わりを示すフラグがデータの終わりを意味している場合に、それまでに受信したフレームにおいて、前記、誤り検出回路および通し番号比較回路において、エラーが検出されなかった場合は、前記エラー無しフラグをエラー無しの意味とし、エラーが検出された場合は、前記エラー無しフラグをエラーありの意味とするとともに、１つめのエラーが検出されたフレームの通し番号を、あわせて送信することを特徴とする。
上記の構成によれば、対向局に対してエラーの有無を通知することが可能となる。また、再送して欲しい通し番号を通知することが可能となり、効率のよい再送を行うことが可能となる。
（２４．二次局がエラー検出後のフレーム受信時に、受信フレーム内データの処理を行わない）
本発明に係る通信機器〔２４〕は、上記通信機器〔２２〕または〔２３〕において、前記誤り検出回路および通し番号比較回路にて、エラーが検出された場合は、少なくとも、前記一括送信データの終わりを示すフラグがデータの終わりを意味する値となっているフレームを受信するまで、受信フレーム内のデータを受信バッファに保存することを行わないことを特徴とする。
上記の構成によれば、エラー発生時には、対向局に再送要求するまでのデータ処理にかかる電力の消費を削減することが可能となる。
（２５．二次局が再送要求をするのは１回だけ）
本発明に係る通信機器〔２５〕は、上記通信機器〔２２〕または〔２３〕において、前記誤り検出回路および通し番号比較回路において、受信フレームにエラーが検出された場合に、前記エラー無しフラグをエラーありの意味として送信するのは１回のみであることを特徴とする。
上記の構成によれば、通信路の品質が悪い場合の再送による消費電力の削減を行うことが可能となる。
（２６．二次局が再送要求をするのに制限を設ける）
本発明に係る通信機器〔２６〕は、上記通信機器〔２２〕または〔２３〕において、前記誤り検出回路および通し番号比較回路において、受信フレームにエラーが検出された場合に、前記エラー無しフラグをエラーありの意味として送信するのは予め定められた回数以下であることを特徴とする。
上記の構成によれば、通信路の品質によって、再送回数の制限を変更することが可能となり、より効率の高い消費電力の低減を行うことが可能となる。
（２７．二次局は常に０からの再送を要求する）
本発明に係る通信機器〔２７〕は、上記通信機器〔２３〕において、前記エラー無しフラグをエラーありの意味として送信を行う際に、通し番号を常に予め定められたルールでの初期値と設定して送信することを特徴とする。
上記の構成によれば、エラーが検出された場合に常にデータの最初からの再送を要求することになり、エラーが発生したフレームの通し番号を管理する必要がなくなり、回路の簡略化につながる。
（２８．接続時に二次局がバッファサイズを一次局に通知する）
本発明に係る通信機器〔２８〕は、上記通信機器〔２２〕または〔２３〕において、接続時に、自局のバッファサイズをフレームに付与して送信することを特徴とする。
上記の構成によれば、対向局に自局の受信バッファサイズを通知することが可能となり、対向局が一括送信するデータサイズを調整することが、自局の受信バッファがあふれてオーバーランエラーとなることを防ぐことが可能となる。
（２９．二次局がＢＬ＝１で同一の通し番号のフレームを連続受信した場合は、エラーとして処理しない）
本発明に係る通信機器〔２９〕は、上記通信機器〔２３〕において、受信したフレームの一括送信データの終わりを示すフラグがデータの終わりを意味しており、かつ、その時の通し番号が直前に受信した一括送信データの終わりを示すフラグがデータの終わりを示しているフレームの通し番号と同じである場合は、前記通し番号比較回路においてエラーとして処理しないことを特徴とする。
上記の構成によれば、自局が送信したフレームにエラーが発生し、対向局が正常に受信できなかった場合に再送された対向局からのフレームをエラーとして処理しないことが可能となる。
（３０．二次局がＢＬ＝１の再送パケットを受信したときは、フレーム内データを受信バッファ内に保存しない）
本発明に係る通信機器〔３０〕は、上記通信機器〔２９〕において、前記、受信したフレームの一括送信データの終わりを示すフラグがデータの終わりを意味しており、かつ、その時の通し番号が直前に受信した一括送信データの終わりを示すフラグがデータの終わりを示しているフレームの通し番号と同じである場合は、受信フレーム内のデータを受信バッファ内に保存しないことを特徴とする。
上記の構成によれば、自局が送信したフレームにエラーが発生し、対向局が正常に受信できなかった場合に再送された対向局からのフレーム内のデータを二重に受信バッファに保存することを防ぐことが可能となる。
（３１．二次局がＢＬ＝１の再送パケットを受信したときは、直前に送信したフレームを再送する）
本発明に係る通信機器〔３１〕は、上記通信機器〔２９〕において、前記受信したフレームの一括送信データの終わりを示すフラグがデータの終わりを意味しており、かつ、その時の通し番号が直前に受信した一括送信データの終わりを示すフラグがデータの終わりを示しているフレームの通し番号と同じである場合は、直前に送信したフレームを再送することを特徴とする。
上記の構成によれば、自局が送信したフレームにエラーが発生し、対向局が正常に受信できなかった場合に、再送を行うことが可能となる。
（３２．二次局がＤＬ＝１のフレームを受信したら、対向局の上位層のデータが終了したことを通知する）
本発明に係る通信機器〔３２〕は、上記通信機器〔２２〕または〔２３〕において、特に、対向局のデータの終わりを示すフラグを判別する回路を有し、受信フレームにおいて、前記対向局のデータの終わりを示すフラグがデータの終わりを示している場合は、自局の受信バッファ内データ処理部に対して、その旨を通知することを特徴とする。
上記の構成によれば、対向局の送信データの終わりを自局内受信データ処理部に通知することが可能となる。
（３３．二次局がＤＬ＝１のフレームを受信したら、二次局の上位層のデータを送信）
本発明に係る通信機器〔３３〕は、上記通信機器〔３２〕において、受信フレームにおいて、前記対向局のデータの終わりを示すフラグがデータの終わりを示している場合は、自局の受信バッファ内データ処理部に対して、その旨を通知した後、自局のデータを送信することを特徴とする。
上記の構成によれば、受信データに対するレスポンスデータを送信することが可能となる。
（３４．二次局が送信するデータはＯＢＥＸのＳＵＣＣＥＳＳ）
本発明に係る通信機器〔３４〕は、上記通信機器〔３３〕において、前記自局のデータには、ＯＢＥＸ（Ｏｂｊｅｃｔ Ｅｘｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ）のＳＵＣＣＥＳＳレスポンスの一部または全てが含まれていることを特徴とする。
上記の構成によれば、対向局からＯＢＥＸのＰｕｔコマンドでのデータ転送が行われた場合、ＯＢＥＸのＳＵＣＣＥＳＳレスポンスを送信することが可能となり、ＯＢＥＸのＰｕｔオペレーションを用いた通信が可能となる。
（３５．二次局が上位層のデータを送信するときにエラー無しフラグを合わせて送信）
本発明に係る通信機器〔３５〕は、上記通信機器〔３３〕において、特に前記自局のデータを送信時に、前記エラー無しフラグを合わせて送信することを特徴とする。
上記の構成によれば、対向局にエラー無しを通知するフレームと、自局のレスポンスデータを送信するフレームを１つにまとめることができ、帯域の効率化につながる。
（３６．二次局がＩｒＤＡのＵＩフレームによる双方向通信を行う）
本発明に係る通信機器〔３６〕は、上記通信機器〔２２〕〜〔３５〕のいずれかにおいて、前記ウィンドウサイズの制限がない通信方式とは、ＩｒＬＡＰ（Ｉｎｆｒａｒｅｄ Ｌｉｎｋ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）のＵＩフレームを用いた通信であることを特徴とする。
上記の構成によれば、ＩｒＬＡＰのＵＩフレームを用いて、再送を行うことが可能となる。
（３７．二次局が片方向通信でデータを受信（通し番号をチェックする））
本発明に係る通信機器〔３７〕は、ＩｒＬＡＰ（Ｉｎｆｒａｒｅｄ Ｌｉｎｋ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）のＵＩフレームを用いて、対向局に対してレスポンスを送信しない通信を行う場合において、受信フレームにエラーがないかどうかを判別するための誤り検出回路と、受信すべき通し番号を算出する回路と、受信すべき通し番号と受信したフレームの通し番号を比較する回路と、受信フレーム内のデータを受信バッファに保存する回路と、受信バッファ内のデータを処理する回路とを有し、データ転送時において、受信したフレームにおいて、前記誤り検出回路および通し番号比較回路において、エラーが検出されなかった場合は、正常なデータ受信として所望の処理を行い、エラーが検出された場合は、データ受信失敗として所望の処理を行うことを特徴とする。
上記の構成によれば、ＩｒＬＡＰのＵＩフレームを用いた片方向通信時においても、フレームの通し番号をチェックすることで、フレームの抜けを検出することが可能となる。
（３８．二次局が片方向受信においてＤＬ解析回路でデータ終了を判断する）
本発明に係る通信機器〔３８〕は、上記通信機器〔３７〕において、特に、対向局のデータの終わりを示すフラグを判別する回路を有し、受信フレームにおいて、前記対向局のデータの終わりを示すフラグがデータの終わりを示している場合は、自局の受信バッファ内データ処理部に対して、その旨を通知することを特徴とする。
上記の構成によれば、受信側において、受信フレーム内に送信側が送信する全データ長の情報がない状態でも、受信データの終わりを判別することが可能となる。
（３９．二次局が片方向受信でエラー検出後のフレーム受信時に、受信フレーム内データの処理を行わない）
本発明に係る通信機器〔３９〕は、上記通信機器〔３７〕において、前記誤り検出回路および通し番号比較回路にて、エラーが検出された場合は、少なくとも、前記一括送信データの終わりを示すフラグがデータの終わりを意味する値となっているフレームを受信するまで、受信フレーム内のデータを受信バッファに保存することを行わないことを特徴とする。
上記の構成によれば、エラーが検出された後のデータ保存処理を行わないことが可能となり、消費電力の削減を行うことが可能となる。
（４０．通信回路）
本発明に係る通信回路〔４０〕は、上記通信機器〔１〕〜〔３９〕のいずれかの通信を実現可能な通信回路であることを特徴とする。
上記の構成によれば、他の通信機器にも組み込むことが可能となる。
（４１．プログラム）
本発明に係る通信プログラム〔４１〕は、上記通信機器〔１〕〜〔３９〕のいずれかの通信を実現可能な通信プログラムであることを特徴とする。
上記の構成によれば、他の通信機器にも組み込むことが可能となる。
（４２．記録媒体）
本発明に係る記録媒体〔４２〕は、上記通信プログラム〔４１〕が記録されており、コンピュータ読み取り可能な記録媒体であることを特徴とする。
上記の構成によれば、本記録媒体に記録されたプログラムをメモリ上に展開して動作させることで、本発明を実行することが可能となる。
（４３．携帯電話）
本発明に係る携帯電話〔４３〕は、上記通信機器〔１〕〜〔３９〕のいずれかの通信を実現可能な携帯電話であることを特徴とする。
上記の構成によれば、携帯電話を用いて、前述のいずれかの通信方式を実現することにより品質の高い通信が可能となる。
（４４．表示装置）
本発明に係る表示装置〔４４〕は、上記通信機器〔１〕〜〔３９〕のいずれかの通信を実現可能な表示装置であることを特徴とする。
上記の構成によれば、表示装置を用いて、前述のいずれかの通信方式を実現することにより品質の高い通信が可能となる。
（４５．印刷装置）
本発明に係る印刷装置〔４５〕は、上記通信機器〔１〕〜〔３９〕のいずれかの通信を実現可能な印刷装置であることを特徴とする。
上記の構成によれば、印刷装置を用いて、前述のいずれかの通信方式を実現することにより品質の高い通信が可能となる。
（４６．記録装置）
本発明に係る記録装置〔４６〕は、上記通信機器〔１〕〜〔３９〕のいずれかの通信を実現可能な記録装置であることを特徴とする。
上記の構成によれば、印刷装置を用いて、前述のいずれかの通信方式を実現することにより品質の高い通信が可能となる。
（４７．ＯＢＥＸ層でレスポンス不要の通信方法）
また、本発明に係る他の通信方法は、オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、対向局にオブジェクトを送信する通信方法において、ＯＢＥＸコマンドを送信後、対向局からのＯＢＥＸレスポンスを受信することなく、次のＯＢＥＸコマンドを送信することを特徴としている。
（４８．片方向送信時のみレスポンス不要の通信方法）
本発明に係る他の通信方法は、さらに、上記の通信方法において、特にＯＢＥＸコマンド送信後に対向局からのＯＢＥＸレスポンスを必要とする双方向通信と対向局からのＯＢＥＸレスポンスを必要としない片方向通信を切り替える手段を有し、前記片方向通信を選択している場合のみ、前記ＯＢＥＸコマンド送信後、対向局からのＯＢＥＸレスポンスを受信することなく、次のＯＢＥＸコマンドを送信するようにしてもよい。
（４９．ＯＢＥＸ層でレスポンス不要の通信装置）
また、本発明に係る他の通信装置は、さらに、オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、対向局にオブジェクトを送信することが可能なＯＢＥＸ層処理部持つ通信装置において、前記ＯＢＥＸ層処理部では、ＯＢＥＸコマンドを生成し送信後、対向局からのＯＢＥＸレスポンスを受信することなく、次のＯＢＥＸコマンドを生成し送信することを特徴としている。
（５０．片方向送信時のみレスポンス不要の通信装置）
本発明に係る他の通信装置は、さらに、上記の通信装置において、特にＯＢＥＸコマンド送信後に対向局からのＯＢＥＸレスポンスを必要とする双方向通信と対向局からのＯＢＥＸレスポンスを必要としない片方向通信を切り替える通信方法切り替え部を有し、前記、通信方法切り替え部が片方向通信を選択している場合のみ、前記ＯＢＥＸコマンドを生成し送信後、対向局からのＯＢＥＸレスポンスを受信することなく、次のＯＢＥＸコマンドを生成し送信するようにしてもよい。
上記の方法および構成によれば、例えばＯＢＥＸを用いた片方向通信において、クライアント機器側からの要求コマンドに対するサーバの応答コマンドをクライアント機器側が受信できない場合においても、ＯＢＥＸでのオブジェクト送信を可能とすることができる。また、双方向通信時は、サーバからの応答を確認する通信を行い、片方向通信時は、サーバからの応答無しに通信を行うことが可能となり、双方向通信と片方向通信を１つのＯＢＥＸプロトコルで実現することが可能となる。
（５１．ＦｉｎａｌでないＰｕｔコマンドのみレスポンス不要の通信方法）
また、本発明に係る他の通信方法は、オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、対向局にオブジェクトを送信する通信方法において、ＯＢＥＸの最終でないＰｕｔコマンドを送信後のみ、対向局からのＯＢＥＸレスポンスを受信することなく、次のＯＢＥＸの最終でないＰｕｔコマンドもしくは最終のＰｕｔコマンドを送信することを特徴としている。
（５２．ＦｉｎａｌでないＰｕｔコマンドのみレスポンス不要の通信装置）
また、本発明に係る他の通信装置は、オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、対向局にオブジェクトを送信することが可能なＯＢＥＸ層処理部持つ通信装置において、前記ＯＢＥＸ層処理部では、ＯＢＥＸの最終でないＰｕｔコマンドを生成送信後のみ、対向局からのＯＢＥＸレスポンスを受信することなく、次のＯＢＥＸの最終でないＰｕｔコマンドもしくは最終のＰｕｔコマンドを生成し送信することを特徴としている。
上記の方法および構成によれば、前述のＰＵＴコマンドに対するＣＯＮＴＩＮＵＥ応答コマンドのみを必要としないオブジェクト交換を実現することが可能となる。
（５３．ＯＢＥＸ層でレスポンスを送信しない通信方法）
本発明に係る他の通信方法は、オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、対向局からオブジェクトを受信する通信方法において、対向局からのＯＢＥＸコマンドを受信後に、常にＯＢＥＸレスポンスを送信しないことを特徴としている。
（５４．片方向受信時のみ、ＯＢＥＸ層でレスポンスを送信しない通信方法）
また、本発明に係る他の通信方法は、さらに、上記の通信方法において、特にＯＢＥＸコマンド送信後に対向局からのＯＢＥＸレスポンスを必要とする双方向通信と対向局からのＯＢＥＸレスポンスを必要としない片方向通信を切り替える手段を有し、前記片方向通信を選択している場合のみ、前記ＯＢＥＸコマンド受信後、常に対向局にＯＢＥＸレスポンスを送信しないとしてもよい。
（５５．ＯＢＥＸ層でレスポンスを送信しない通信装置）
また、本発明に係る他の通信装置は、オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、対向局からオブジェクトを受信することが可能なＯＢＥＸ層処理部持つ通信装置において、前記ＯＢＥＸ層処理部では、対向局からのＯＢＥＸコマンドを受信後に、常にＯＢＥＸレスポンスを送信しないことを特徴としている。
（５６．片方向受信時のみ、ＯＢＥＸ層でレスポンスを送信しない通信装置）
また、本発明に係る他の通信装置は、さらに、上記の通信装置において、特にＯＢＥＸコマンド送信後に対向局からのＯＢＥＸレスポンスを必要とする双方向通信と対向局からのＯＢＥＸレスポンスを必要としない片方向通信を切り替える通信方法切り替え部を有し、前記、通信方法切り替え部が片方向通信を選択している場合のみ、前記ＯＢＥＸコマンド受信後、常に対向局にＯＢＥＸレスポンスを送信しないとしてもよい。
上記の方法および構成によれば、例えばＯＢＥＸを用いた片方向通信において、クライアント機器側からの要求コマンドに対するサーバ機器側の応答コマンドをクライアント機器側が送信する必要がない場合に、不必要な応答コマンドの生成および送信を行わないといった制御を行うことが可能となる。また、双方向通信時は、クライアント機器側へ応答コマンドを送信することにより、クライアント機器側での通信の確認を可能とし、片方向通信時は、クライアント機器への不必要な応答コマンドの生成および送信を行わないことが可能となり、双方向通信と片方向通信を１つのＯＢＥＸプロトコルで実現することが可能となる。
（５７．ＦｉｎａｌでないＰｕｔコマンドのみレスポンスしない通信方法）
また、本発明に係る他の通信方法は、オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、対向局からオブジェクトを受信する通信方法において、ＯＢＥＸの最終でないＰｕｔコマンド受信時には、ＯＢＥＸレスポンスの送信を行わず、最終のＰｕｔコマンド受信時には、ＯＢＥＸのレスポンスの送信を行うことを特徴としている。
（５８．ＦｉｎａｌでないＰｕｔコマンドのみレスポンスしない通信装置）
また、本発明に係る他の通信装置は、オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、対向局からオブジェクトを受信することが可能なＯＢＥＸ層処理部持つ通信装置において、前記ＯＢＥＸ層処理部では、ＯＢＥＸの最終でないＰｕｔコマンド受信時には、ＯＢＥＸレスポンスの送信を行なわず、最終のＰｕｔコマンド受信時には、ＯＢＥＸのレスポンスを生成し送信することを特徴としている。
上記の方法および構成によれば、クライアント機器側からの最終でないＰＵＴコマンドに対するＣＯＮＴＩＮＵＥ応答コマンドのみを生成し、送信しないといった制御を行うことが可能となり、通信帯域の効率化を図ることが可能となる。
また、本発明は以下のように構成してもよい。
本発明に係る通信システムは、通信データを複数の非制限フレームに分割して、一次局と二次局との間にてフレーム単位で通信データを通信する通信システムにおいて、該一次局では、前記非制限フレームにフレームの通し番号、および送信権を委譲するか否かを示すフラグを付与してデータ送信を行い、該二次局では、前記一次局から受信したフレームの送信権を委譲するか否かを示すフラグが送信権の委譲を意味しているとき、前記一次局に対して、それまで受信したフレーム中にエラーやフレーム抜けがあったかどうかの通信結果の通知を行うことを特徴とする。
前記非制限フレームとしては、赤外線を用いた、例えばＩｒＤＡ通信方式に準拠した通信方式にて使用されている、ＵＩ（Ｕｎｎｕｍｂｅｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ）フレームが挙げられる。ＵＩフレームは、連続送信できる最大ターンアラウンド時間の間であれば、送信フレーム数に制限されずに、連続して送信することできるものである。
上記の構成によれば、ウィンドウサイズの制限を持たない非制限フレームを用いた通信においても、エラーやフレーム抜けが生じたフレームの再送を行うことが可能となる。それゆえ、通信効率の向上を図ることができる。
また、前記二次局は、エラーやフレーム抜けを検知した場合、一次局に通信結果を通知する際、エラーまたはフレーム抜けがあったフレームの通し番号も合わせて通知することを特徴とする。
上記の構成によれば、一次局ではすべてのフレームを再送する必要がないため、通信におけるオーバーヘッドの低減、一次局の消費電力を低減するという効果を奏する。
また、前記一次局は、前記二次局からエラーまたはフレーム抜けがあった旨の通知を受けると、前記二次局から通知されたエラーまたはフレーム抜けがあったフレーム以降のフレームを再度送信することを特徴とする。
上記の構成によれば、一次局ではすべてのフレームを再送する必要がないため、通信におけるオーバーヘッドの低減、一次局の消費電力を低減するという効果を奏する。
また、前記一次局は、エラーまたはフレーム抜けがあったフレームの通し番号以降のフレームを再度送信することを一回だけ行うことを特徴とする。
上記の構成によれば、一次局ではフレームの再送を１回だけ行うため、該送信に伴う消費電力を低減することができるという効果を奏する。
また、前記二次局では、エラーまたはフレーム抜けを検知した際、エラーまたはフレーム抜けを検知したフレーム以降のフレームの受信処理を停止することを特徴とする。
上記の構成によれば、二次局ではエラーまたはフレーム抜けを検出した以降のフレームを受信しないことにより、無駄なフレームの受信を行わなくてよく、消費電力の低減を図ることができる。
また、前記二次局では、前記一次局から再度送信されたフレームの中から必要なエラーまたはフレーム抜けがあったフレームのみを受信することを特徴とする。
上記の構成によれば、二次局では、無駄なフレームの受信を行わなくてよく、消費電力の低減を図ることができる。
また、接続確立時に、前記一次局から送信される接続要求フレームと前記二次局から送信される接続応答フレームにそれぞれ、各局の一度に送受信可能なフレーム数を意味するフィールドを付与してフレーム交換を行い、各局において受信した相手局の一度に受信可能なフレーム数を参照して最適なフレーム数を算出し、該フレーム数に応じて送信権の委譲を行うことを特徴とする。
上記の構成によれば、一次局と二次局両局間でサポートされているフレーム数毎に必ず送信権の委譲が行われるので、各局に搭載されたメモリ容量に応じたフレーム交換を行うことができる。
また、本発明に係る通信システムは、通信データを複数の非制限フレームに分割したうえで、一次局と二次局との間でフレーム単位にて通信データを通信する通信システムにおいて、前記一次局と二次局とは、階層構造の通信プロトコルを用いて通信を行い、該一次局は、前記階層構造を構成する一つの特定通信プロトコル層において、前記非制限フレームにフレームの通し番号、および、送信権を委譲するか否かを示すフラグを付与し、該二次局は、前記特定通信プロトコル層において、前記一次局から受信したフレームの送信権を委譲するか否かを示すフラグが送信権の委譲を意味しているとき、前記一次局に対して、それまで受信したフレーム中にエラーやフレーム抜けがあったかどうかの通信結果の通知を行うことを特徴とする。
上記の構成によれば、ウィンドウサイズの制限を持たない非制限フレームを用いた通信においても、再送を行うことが可能となるとともに、上記特定通信プロトコル層以外の層について既存のものから変更する必要がない。
さらに、前記二次局は、前記特定通信プロトコル層において、エラーやフレーム抜けを検知した場合、一次局に通信結果を通知する際、エラーまたはデータ抜けがあったフレームの通し番号も合わせて通知することを特徴とする。
上記の構成によれば、通信におけるオーバーヘッドの低減、一次局の消費電力を低減するとともに、上記特定通信プロトコル層以外の層について既存のものから変更する必要がない。
さらに、前記一次局は、前記特定通信プロトコル層において、前記二次局からエラーまたはフレーム抜けがあった旨の通知を受けると、前記二次局から通知されたエラーまたはフレーム抜けがあったフレーム以降のフレームを再度送信することを特徴とする。
上記の構成によれば、通信におけるオーバーヘッドの低減、一次局の消費電力を低減するとともに、上記特定通信プロトコル層以外の層について既存のものから変更する必要がない。
さらに、前記一次局は、前記特定通信プロトコル層において、前記二次局からエラーまたはフレーム抜けがあった旨の通知を受けた際、フレームの再送を一回だけ行うことを特徴とする。
上記の構成によれば、送信に伴う消費電力を低減することができるとともに、上記特定通信プロトコル層以外の層について既存のものから変更する必要がない。
さらに、前記二次局においては、前記特定通信プロトコル層において、エラーまたはフレーム抜けを検知した際、エラーまたはフレーム抜けを検知したフレーム以降のフレームの受信処理を停止することを特徴とする。
上記の構成によれば、二次局が無駄なフレームの受信を行わなくてよく、消費電力の低減を図ることができるとともに、上記特定通信プロトコル層以外の層について既存のものから変更する必要がない。
さらに、前記二次局では、前記特定通信プロトコル層において、前記一次局から再度送信されたフレームの中から必要なエラーまたはフレーム抜けがあったフレームのみを受信することを特徴とする。
上記の構成によれば、二次局が無駄なフレームの受信を行わなくてよく、消費電力の低減を図ることができるとともに、上記特定通信プロトコル層以外の層について既存のものから変更する必要がない。
さらに、前記特定通信プロトコル層において、接続確立時に、前記一次局から送信される接続要求フレームと前記二次局から送信される接続応答フレームにそれぞれ、各局の一度に送受信可能なフレーム数を意味するフィールドを付与してフレーム交換を行い、各局において受信した相手局の一度に受信可能なフレーム数を参照して最適なフレーム数を算出し、該フレーム数に応じて送信権の委譲を行うことを特徴とする。
上記の構成によれば、各局に搭載されたメモリ容量に応じたフレーム交換を行うことができるとともに、上記特定通信プロトコル層以外の層について既存のものから変更する必要がない。
さらに、前記一次局では、前記特定通信プロトコル層において、前記非制限フレームに対して、上位層が送信フレームに対する応答フレームを要求するか否かを示すフラグを付与してフレームの送信を行い、前記二次局では、前記特定通信プロトコル層において、前記一次局から受信したフレームの前記一次局の上位層が送信フレームに対する応答フレームを要求しているか否かを示すフラグが応答フレームを要求していることを意味している場合、上位層に対してその旨の通知を行い、上位層が応答フレームの準備を完了した時点で、上位層から渡された応答フレームに対して、それまで受信したフレーム中にエラーやフレーム抜けがあったかどうかの通信結果を意味する情報を付与して応答フレーム生成し、送信することを特徴とする。
上記の構成によれば、再送管理を行う上記特定通信プロトコル層の上位層に位置する通信プロトコル層での要求フレームおよび応答フレームのやり取りが可能となる。
さらに、前記一次局では、前記特定通信プロトコル層において、前記非制限フレームに対して、上位層が送信フレームに対する応答フレームを要求するか否かを示すフラグを付与してフレームの送信を行い、前記二次局では、前記特定通信プロトコル層において、前記一次局から受信したフレームの前記一次局の上位層が送信フレームに対する応答フレームを要求しているか否かを示すフラグが応答フレームを要求していることを意味している場合、上位層に対してその旨の通知を行い、先にそれまで受信したフレーム中にエラーやフレーム抜けがあったかどうかの通信結果を意味する応答フレームを送信し、上位層が応答フレームを準備が完了した時点で、上位層からの応答フレームを再度送信することを特徴とする。
上記の構成によれば、一次局の上記特定通信プロトコル層では、二次局の上記特定通信プロトコル層の上位層において応答フレームが準備されてから応答フレームが返信されてくる前の間に、上記特定通信プロトコル層レベルの応答フレーム（つまり上位層の応答フレームが包含されていない）を受信することができる。これにより、一次局の上記特定通信プロトコル層は、上位層からの応答フレームが返信される前に、二次局が正常にフレームを受信できたか否かを知ることができるので、あらかじめ次のデータ転送の準備などを行っておくことができる。
また、本発明に係る送信装置は、通信データを複数の非制限フレームに分割したうえで、フレーム単位にて通信データを受信局に送信する送信装置において、前記非制限フレームにフレームの通し番号を付与する通し番号付加手段と、前記非制限フレームに送信権を委譲するか否かを示すフラグを付与する送信権委譲フラグ付与手段とを備えることを特徴とする。
また、本発明に係る通信方法は、通信データを複数の非制限フレームに分割したうえで、フレーム単位にて通信データを受信局に送信する送信装置の通信方法であって、前記非制限フレームにフレームの通し番号を付与する通し番号付加ステップと、前記非制限フレームに送信権を委譲するか否かを示すフラグを付与する送信権委譲フラグ付与ステップとを含むことを特徴とする。
上記の構成によれば、ウィンドウサイズの制限を持たない非制限フレームを用いた通信においても、受信装置からエラーやフレーム抜けがあったか否かを示すフレームを受信することができる。これにより、エラーやフレーム抜けがあった非制限フレームの再送を行うことが可能となる。
また、本発明に係る受信装置は、上記送信装置から通信データを受信する受信装置において、前記送信装置から受信したフレームの送信権を委譲するか否かを示すフラグが送信権の委譲を意味しているとき、それまで受信したフレーム中にエラーやフレーム抜けがあったかどうかのを示すレスポンスフレームを生成するレスポンスフレーム生成手段と、レスポンスフレーム生成手段が生成したレスポンスフレームを前記送信装置に送信する送信手段とを備えることを特徴とする。
また、本発明に係る通信方法は、上記送信装置から通信データを受信する受信装置の通信方法であって、前記送信装置から受信したフレームの送信権を委譲するか否かを示すフラグが送信権の委譲を意味しているとき、それまで受信したフレーム中にエラーやフレーム抜けがあったかどうかのを示すレスポンスフレームを生成するレスポンスフレーム生成ステップと、レスポンスフレーム生成手段が生成したレスポンスフレームを前記送信装置に送信する送信ステップとを含むことを特徴とする。
上記の構成によれば、ウィンドウサイズの制限を持たない非制限フレームを受信した場合でも、エラーやフレーム抜けがあったか否かを示すフレームを送信することができる。これにより、エラーのあった非制限フレームの再送を行うことが可能となる。
また、本発明に係る通信システムが備える一次局を動作させる通信プログラムは、コンピュータを上記一次局で行われるデータ通信処理を実行するコンピュータ・プログラムである。
上記の構成によれば、コンピュータで上記一次局で行われるデータ通信処理を実行することによって、上記通信システムが備える一次局を動作させることができる。
また、本発明に係る通信システムが備える二次局を動作させる通信プログラムは、コンピュータを上記二次局で行われるデータ通信処理を実行するコンピュータ・プログラムである。
上記の構成によれば、コンピュータで上記二次局で行われるデータ通信処理を実行することによって、上記通信システムが備える二次局を動作させることができる。
また、本発明に係る記録媒体は、上記通信システムが備える一次局を動作させる通信プログラム、あるいは、上記通信システムが備える二次局を動作させる通信プログラムを記録したコンピュータ読み取り可能な記録媒体である。
上記の構成によれば、上記記録媒体から読み出された通信プログラムによって、上記一次局で行われるデータ通信処理あるいは二次局で行われるデータ通信処理をコンピュータ上に実現することができる。
本発明は上述した各実施の形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施の形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施の形態についても本発明の技術的範囲に含まれる。
発明の詳細な説明の項においてなされた具体的な実施態様または実施例は、あくまでも、本発明の技術内容を明らかにするものであって、そのような具体例にのみ限定して狭義に解釈されるべきものではなく、本発明の精神と次に記載する特許請求事項との範囲内で、いろいろと変更して実施することができるものである。
本発明の通信システム、送信装置、受信装置、通信方法、通信プログラムおよび記録媒体では、データ転送における信頼性が高く、データ転送に要する時間を短縮化できるので、本発明に係る通信システムの送信機能は、例えば、携帯電話機、ＰＤＡ、パーソナルコンピュータなどに適用することができる一方、本発明に係る通信システムの受信機能は、例えば、携帯電話機、テレビ、ＡＶ機器、プリンタ、ＤＶＤレコーダ、ＨＤＤレコーダなどの記録装置、パーソナルコンピュータなどに適用することができる。また、本発明の通信システムは、ＩｒＤＡに準拠した赤外線通信に適用することができる。

Claims (26)

  1. 一度に送信可能なフレーム数に制限がない通信方式に従って、送信権を委譲せずに、データを一括送信する通信機器であって、
    一括送信する一括送信データを分割して送信フレームを生成する送信フレーム生成手段と、
    上記送信フレームに通し番号を付与する通し番号生成手段と、
    上記一括送信データの最終の送信フレームに、一括送信データの最終の送信フレームであることを示す一括送信最終フラグを設定する一括送信最終フラグ生成手段と、
    上記送信フレームを送信する送信手段と、を備えることを特徴とする通信機器。
  2. 受信した受信フレームからエラー無しフラグおよび通し番号を抽出する受信フレーム解析手段と、
    上記エラー無しフラグを解析してエラーの有無を判定するエラー無しフラグ解析手段と、
    上記エラー無しフラグがエラー有りを示している場合、上記通し番号に対応する送信フレームを再送する制御手段と、を備えることを特徴とする請求項１に記載の通信機器。
  3. １つの送信データを複数の上記一括送信データに分割して送信する際、当該送信データの最終の送信フレームに、送信データの最終の送信フレームであることを示すデータ最終フラグを設定するデータ最終フラグ生成手段を備えることを特徴とする請求項２に記載の通信機器。
  4. 上記通信方式が、ＩｒＬＡＰ（Ｉｎｆｒａｒｅｄ Ｌｉｎｋ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）のＵＩ（Ｕｎｎｕｍｂｅｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ）フレームを用いた通信であることを特徴とする請求項１から３のいずれか１項に記載の通信機器。
  5. 上記送信フレームには、ＯＢＥＸ（Ｏｂｊｅｃｔ ＥＸｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ）の最終のＰＵＴコマンドまたは最終でないＰＵＴコマンドの少なくとも一部が含まれていることを特徴とする請求項１から４のいずれか１項に記載の通信機器。
  6. 一度に送信可能なフレーム数に制限がない通信方式に従って、送信権を委譲されずに、データを一括受信する通信機器であって、
    上記受信フレームに含まれる通し番号を解析して、通し番号のエラーがないかどうかを判別する通し番号解析手段と、
    上記受信フレームに含まれる一括送信最終フラグが、当該受信フレームが送信機によって複数の送信フレームに分割されて一括送信された一括送信データの最終の送信フレームであることを示しているとき、上記通し番号解析手段によって、それまでに受信した受信フレームにエラーが検出された場合、エラー有りを示すように設定したエラー無しフラグおよびエラー発生時の通し番号を含む送信フレームを生成する送信フレーム生成手段と、
    上記送信フレームを送信する送信手段と、を備えることを特徴とする通信機器。
  7. 一度に送信可能なフレーム数に制限がない通信方式に従って、送信権を委譲されずに、データを一括受信する通信機器であって、
    受信した受信フレームにエラーがないかどうかを判別するためのエラー検出手段と、
    上記受信フレームに含まれる一括送信最終フラグが、当該受信フレームが送信機によって複数の送信フレームに分割されて一括送信された一括送信データの最終の送信フレームであることを示しているとき、上記エラー検出手段によって、それまでに受信した受信フレームにエラーが検出されているか否かに応じて、エラーの有無を示すように設定したエラー無しフラグを含む送信フレームを生成する送信フレーム生成手段と、
    上記送信フレームを送信する送信手段と、を備えることを特徴とする通信機器。
  8. 上記通信方式が、ＩｒＬＡＰ（Ｉｎｆｒａｒｅｄ Ｌｉｎｋ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）のＵＩ（Ｕｎｎｕｍｂｅｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ）フレームを用いた通信であることを特徴とする請求項６または７に記載の通信機器。
  9. 上記送信フレームには、ＯＢＥＸ（Ｏｂｊｅｃｔ Ｅｘｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ）のＳＵＣＣＥＳＳレスポンスの一部もしくは全てが含まれていることを特徴とする請求項６から８のいずれか１項に記載の通信機器。
  10. 一度に送信可能なフレーム数に制限がない通信方式に従って、送信権を委譲せずに、データを一括送信する通信方法であって、
    一括送信する一括送信データを分割して送信フレームを生成し、
    上記送信フレームに通し番号を付与し、
    上記一括送信データの最終の送信フレームには、一括送信データの最終の送信フレームであることを示す一括送信最終フラグを設定して、
    上記送信フレームを送信することを特徴とする通信方法。
  11. 一度に送信可能なフレーム数に制限がない通信方式に従って、送信権を委譲されずに、データを一括受信する通信方法であって、
    上記受信フレームに含まれる通し番号を解析して、通し番号のエラーがないかどうかを判別し、
    上記受信フレームに含まれる一括送信最終フラグが、当該受信フレームが送信機によって複数の送信フレームに分割されて一括送信された一括送信データの最終の送信フレームであることを示しているとき、それまでに受信した受信フレームにエラーが検出された場合、エラー有りを示すように設定したエラー無しフラグおよびエラー発生時の通し番号を含む送信フレームを生成し、
    上記送信フレームを送信することを特徴とする通信方法。
  12. 請求項１に記載の通信機器と、
    請求項６に記載の通信機器と、を含むことを特徴とする通信システム。
  13. オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、オブジェクトを送信する通信機器であって、
    ＯＢＥＸコマンドを送信後、受信機からのＯＢＥＸレスポンスを受信することなく、次のＯＢＥＸコマンドを送信するＯＢＥＸ層処理部を備えることを特徴とする通信機器。
  14. オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、オブジェクトを送信する通信方法であって、
    ＯＢＥＸコマンドを送信後、受信機からのＯＢＥＸレスポンスを受信することなく、次のＯＢＥＸコマンドを送信することを特徴とする通信方法。
  15. オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、オブジェクトを送信する通信機器であって、
    ＯＢＥＸの最終でないＰｕｔコマンドを送信後のみ、受信機からのＯＢＥＸレスポンスを受信することなく、次のＯＢＥＸの最終でないＰｕｔコマンドもしくは最終のＰｕｔコマンドを送信するＯＢＥＸ層処理部を備えることを特徴とする通信機器。
  16. オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、オブジェクトを送信する通信方法であって、
    ＯＢＥＸの最終でないＰｕｔコマンドを送信後のみ、受信機からのＯＢＥＸレスポンスを受信することなく、次のＯＢＥＸの最終でないＰｕｔコマンドもしくは最終のＰｕｔコマンドを送信することを特徴とする通信方法。
  17. オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、送信機からオブジェクトを受信する通信機器であって、
    ＯＢＥＸコマンドを受信後に、ＯＢＥＸレスポンスを常に送信しないＯＢＥＸ層処理部を備えることを特徴とする通信機器。
  18. オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、送信機からオブジェクトを受信する通信方法であって、
    ＯＢＥＸコマンドを受信後に、ＯＢＥＸレスポンスを常に送信しないことを特徴とする通信方法。
  19. オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、送信機からオブジェクトを受信する通信機器であって、
    ＯＢＥＸの最終でないＰｕｔコマンド受信時には、ＯＢＥＸレスポンスの送信を行わず、最終のＰｕｔコマンド受信時には、ＯＢＥＸのレスポンスの送信を行うＯＢＥＸ層処理部を備えることを特徴とする通信機器。
  20. オブジェクト交換用プロトコルＯＢＥＸ（ＯＢｊｅｃｔ ＥＸｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）を用いて、送信機からオブジェクトを受信する通信方法であって、
    ＯＢＥＸの最終でないＰｕｔコマンド受信時には、ＯＢＥＸレスポンスの送信を行わず、最終のＰｕｔコマンド受信時には、ＯＢＥＸのレスポンスの送信を行うことを特徴とする通信方法。
  21. 請求項１から８、１３、１５、１７、１９のいずれか１項に記載の通信機器を動作させる通信プログラムであって、コンピュータを上記の各部として機能させるための通信プログラム。
  22. 請求項１から８、１３、１５、１７、１９のいずれか１項に記載の通信機器を動作させる通信回路であって、上記の各部として機能することを特徴とする通信回路。
  23. 請求項１から８、１３、１５、１７、１９のいずれか１項に記載の通信機器を搭載し、該通信機器によって通信を行うことを特徴とする携帯電話。
  24. 請求項６から８、１７、１９のいずれか１項に記載の通信機器を搭載し、該通信機器によって受信したデータに基づいて表示することを特徴とする表示装置。
  25. 請求項６から８、１７、１９のいずれか１項に記載の通信機器を搭載し、該通信機器によって受信したデータに基づいて印刷することを特徴とする印刷装置。
  26. 請求項６から８、１７、１９のいずれか１項に記載の通信機器を搭載し、該通信機器によって受信したデータを記録することを特徴とする記録装置。
JP2007500577A 2005-01-28 2006-01-26 通信機器、通信システム、通信方法、通信プログラム、通信回路 Active JP4198741B2 (ja)

Applications Claiming Priority (17)

Application Number Priority Date Filing Date Title
JP2005022209 2005-01-28
JP2005022209 2005-01-28
JP2005023901 2005-01-31
JP2005023929 2005-01-31
JP2005023901 2005-01-31
JP2005023929 2005-01-31
JP2005116096 2005-04-13
JP2005116096 2005-04-13
JP2005152910 2005-05-25
JP2005152910 2005-05-25
JP2005192903 2005-06-30
JP2005192903 2005-06-30
PCT/JP2005/014446 WO2006013979A1 (ja) 2004-08-06 2005-08-05 送信機、受信機、通信システム、通信方法、通信プログラム
JPPCT/JP2005/014446 2005-08-05
JP2005271233 2005-09-16
JP2005271233 2005-09-16
PCT/JP2006/301238 WO2006080403A1 (ja) 2005-01-28 2006-01-26 通信機器、通信システム、通信方法、通信プログラム、通信回路

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2007268430A Division JP2008079330A (ja) 2005-01-28 2007-10-15 通信機器、通信方法、通信プログラム、通信回路、携帯電話、表示装置、印刷装置、記録装置

Publications (2)

Publication Number Publication Date
JPWO2006080403A1 true JPWO2006080403A1 (ja) 2008-06-19
JP4198741B2 JP4198741B2 (ja) 2008-12-17

Family

ID=40133485

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007500577A Active JP4198741B2 (ja) 2005-01-28 2006-01-26 通信機器、通信システム、通信方法、通信プログラム、通信回路

Country Status (3)

Country Link
US (1) US8291273B2 (ja)
JP (1) JP4198741B2 (ja)
CN (1) CN101964705B (ja)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7684786B2 (en) * 2003-08-26 2010-03-23 Nokia Corporation Method and system for establishing a connection between network elements
US8036244B2 (en) * 2004-08-06 2011-10-11 Sharp Kabushiki Kaisha Transmitter, receiver, communication system, communication method, non-transitory computer readable medium
KR100902341B1 (ko) * 2005-01-28 2009-06-12 샤프 가부시키가이샤 통신기기, 통신시스템, 통신방법, 통신 프로그램을 기록한 컴퓨터독취가능한 기록매체, 통신회로
JP4198741B2 (ja) 2005-01-28 2008-12-17 シャープ株式会社 通信機器、通信システム、通信方法、通信プログラム、通信回路
US7787391B2 (en) * 2005-01-28 2010-08-31 Sharp Kabushiki Kaisha Communication device, communication system, communication method, communication program, and communication circuit
US8051182B2 (en) * 2005-01-28 2011-11-01 Sharp Kabushiki Kaisha Communication device, communication system, communication method, communication program, and communication circuit
CN101305580B (zh) * 2005-11-10 2012-01-18 夏普株式会社 数据发送装置及其控制方法、数据接收装置及其控制方法、数据发送系统、数据发送装置控制程序、数据接收装置控制程序以及记录有该程序的记录介质
JP4219950B2 (ja) * 2006-10-16 2009-02-04 シャープ株式会社 通信機器、通信方法、通信回路、携帯電話機、プログラム、およびプログラムを記録したコンピュータ読み取り可能な記録媒体
US8064332B2 (en) * 2007-11-27 2011-11-22 Intel Corporation Avoiding collisions between users if map containing persistent scheduling information is lost
US8072875B2 (en) * 2007-11-27 2011-12-06 Intel Corporation Avoiding collisions between users if MAP containing persistent scheduling information is lost
JP4557028B2 (ja) * 2008-03-19 2010-10-06 ソニー株式会社 情報処理装置、情報処理方法、クライアント機器、情報処理システム
JP2009278391A (ja) * 2008-05-15 2009-11-26 Yokogawa Electric Corp 計装制御システム
EP2535818A1 (en) * 2010-02-08 2012-12-19 Fujitsu Limited Error generation indicator circuit, storage device, information processing device and control method of error generation indicator circuit
TWI483117B (zh) * 2010-09-29 2015-05-01 Toshiba Kk 用於執行命令之裝置、主機控制器及用於執行命令之系統
US9813350B2 (en) * 2012-01-31 2017-11-07 Sharp Kabushiki Kaisha Generation device, reproduction device, data structure, generation method, reproduction method, control program, and recording medium
JP6451629B2 (ja) * 2013-07-30 2019-01-16 ソニー株式会社 情報処理装置、情報処理方法及びプログラム
TWI538425B (zh) 2014-04-14 2016-06-11 微晶片科技公司 藍牙介面的資料傳輸系統及傳輸方法
CN105530355B (zh) * 2014-10-20 2020-08-11 现代自动车株式会社 用于车辆的免提装置和控制该免提装置的方法
JP6792959B2 (ja) * 2016-05-16 2020-12-02 クラリオン株式会社 情報端末、通信端末、ライセンス移行システム、ライセンス移行方法
JP7032631B2 (ja) * 2017-07-04 2022-03-09 富士通株式会社 送受信システム、送受信システムの制御方法、及び送信装置
US10917196B2 (en) * 2019-02-12 2021-02-09 Cisco Technology, Inc. Efficient transmission of small packets in low power and lossy networks
JP7145117B2 (ja) * 2019-04-05 2022-09-30 ルネサスエレクトロニクス株式会社 通信装置
US11265301B1 (en) * 2019-12-09 2022-03-01 Amazon Technologies, Inc. Distribution of security keys

Family Cites Families (127)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS5856200A (ja) 1981-09-30 1983-04-02 富士通株式会社 手書文字情報の伝送方式
US4957348A (en) 1989-03-21 1990-09-18 Hewlett-Packard Company Optical transceiver with multiple communication modes
US5001471A (en) * 1989-12-26 1991-03-19 Motorola, Inc. Paging system employing designated batch information service data message transmission
JP2902776B2 (ja) 1990-11-29 1999-06-07 富士通株式会社 Ｉｓｄｎインタフェース装置
EP0836350A3 (en) 1990-11-29 1999-06-02 Fujitsu Limited ISDN interface unit
JPH0563749A (ja) 1991-09-02 1993-03-12 Hitachi Ltd マルチプロトコル通信制御装置
DE4131133B4 (de) 1991-09-19 2005-09-08 Robert Bosch Gmbh Verfahren und Vorrichtung zum Austausch von Daten in Datenverarbeitungsanlagen
EP0597064B1 (en) * 1992-05-29 2001-10-04 Motorola, Inc. Data communication receiver having variable length message carry-on
JPH0670383A (ja) 1992-08-21 1994-03-11 Toshiba Corp 赤外線送受信システム
US5515508A (en) 1993-12-17 1996-05-07 Taligent, Inc. Client server system and method of operation including a dynamically configurable protocol stack
JP3161910B2 (ja) 1994-07-26 2001-04-25 シャープ株式会社 通信装置
US5557634A (en) 1994-10-14 1996-09-17 International Business Machines Corporation Multiprotocol directed infrared communication controller
FI97659C (fi) 1995-01-13 1997-01-27 Nokia Mobile Phones Ltd Menetelmä ja -laite virran säästämiseksi infrapuna-tiedonsiirrossa
JP3324671B2 (ja) 1995-05-16 2002-09-17 インターナショナル・ビジネス・マシーンズ・コーポレーション コンピュータ・システム
US5923443A (en) 1996-01-16 1999-07-13 Nokia Mobile Phones Limited Infrared communication port fax software legacy flow control emulation
KR100566110B1 (ko) * 1996-01-16 2006-06-07 노키아 모빌 폰즈 리미티드 적외데이터결합호환시스템의처리지원프로토콜
US6188431B1 (en) 1996-02-17 2001-02-13 Casio Computers Co., Ltd. Electronic still camera and method for communication between electronic still cameras
JP3759233B2 (ja) 1996-04-19 2006-03-22 ローム株式会社 光通信用デバイス
JP3698833B2 (ja) 1996-09-20 2005-09-21 株式会社リコー ワイヤレス通信システム
CA2216980C (en) 1996-10-04 2001-09-25 Hitachi, Ltd. Communication method
US6728774B1 (en) 1997-01-15 2004-04-27 Nokia Mobile Phones Limited Transaction support for IRDA-compatible systems
JPH10289180A (ja) 1997-02-12 1998-10-27 Canon Inc 通信処理装置及び方法
DE69840972D1 (de) 1997-02-14 2009-08-27 Canon Kk Vorrichtung, System und Verfahren zur Datenübertragung und Vorrichtung zur Bildverarbeitung
SG74611A1 (en) 1997-02-14 2000-08-22 Canon Kk Data communication apparatus and method
JP2957507B2 (ja) 1997-02-24 1999-10-04 インターナショナル・ビジネス・マシーンズ・コーポレイション 小型情報処理機器
JP3439320B2 (ja) 1997-05-08 2003-08-25 松下電器産業株式会社 データ通信方法、データ通信装置、およびデータ通信プログラム記録媒体
JPH1115761A (ja) 1997-06-02 1999-01-22 Internatl Business Mach Corp <Ibm> 赤外線通信機能を持つ情報処理装置及びその制御方法
JP3482103B2 (ja) 1997-07-29 2003-12-22 シャープ株式会社 赤外線通信制御装置および方法
US6658480B2 (en) 1997-10-14 2003-12-02 Alacritech, Inc. Intelligent network interface system and method for accelerated protocol processing
US6178181B1 (en) 1997-12-01 2001-01-23 Telefonaktiebolaget L M Ericsson (Publ) Mapping function and method of transmitting signaling system 7(SS7) telecommunications messages over data networks
CA2314956A1 (en) 1997-12-17 1999-06-24 Yaron Ruziack Network communications link
US6256296B1 (en) 1997-12-17 2001-07-03 Yaron Ruziak Network communications link
US6907013B1 (en) 1997-12-17 2005-06-14 Infracom, Ltd. Network communications link
US6735245B1 (en) 1998-01-09 2004-05-11 Panasonic Communications Co., Ltd. Activation of multiple XDSL modems with channel probe
JP3847952B2 (ja) 1998-05-01 2006-11-22 キヤノン株式会社 無線通信装置及び制御方法
JP2000010745A (ja) 1998-06-17 2000-01-14 Toshiba Corp 印刷システム、端末装置、印刷装置及び記録媒体
JP3005525B2 (ja) 1998-07-15 2000-01-31 日本電気移動通信株式会社 データ通信方法及びその制御プログラムを記録した記録媒体
JP2000032000A (ja) 1998-07-16 2000-01-28 Kawasaki Steel Corp 赤外線通信機
US6499068B1 (en) * 1998-07-23 2002-12-24 Canon Kabushiki Kaisha Processing data transmission jobs to destinations in batch or not depending on specified transmission type
JP3945034B2 (ja) 1998-08-25 2007-07-18 カシオ計算機株式会社 印刷装置
JP2000101605A (ja) 1998-09-24 2000-04-07 Sanyo Electric Co Ltd 赤外線通信装置、赤外線通信方法および記録媒体
US6675203B1 (en) * 1998-10-05 2004-01-06 Symbol Technologies, Inc. Collecting data in a batch mode in a wireless communications network with impeded communication
US6446127B1 (en) 1998-10-30 2002-09-03 3Com Corporation System and method for providing user mobility services on a telephony network
US6519644B1 (en) 1998-12-01 2003-02-11 Telefonaktiebolaget Lm Ericsson (Publ) System and method for dial-up networking over infrared data link
US6347339B1 (en) 1998-12-01 2002-02-12 Cisco Technology, Inc. Detecting an active network node using a login attempt
JP3552199B2 (ja) 1998-12-28 2004-08-11 株式会社東芝 機器制御装置及び通信ノード
JP3180790B2 (ja) 1998-12-28 2001-06-25 日本電気株式会社 赤外線非接続型オブジェクト交換通信方法および装置
JP3492229B2 (ja) 1999-03-12 2004-02-03 富士通株式会社 通信制御装置
GB2349949B (en) 1999-05-14 2003-03-05 Taylor Hobson Ltd Metrological instrument
JP2000332688A (ja) 1999-05-17 2000-11-30 Sharp Corp 光空間伝送装置
JP2000349782A (ja) 1999-06-08 2000-12-15 Nec Corp 赤外線送受信装置および赤外線送受信方法
US6812881B1 (en) 1999-06-30 2004-11-02 International Business Machines Corp. System for remote communication with an addressable target using a generalized pointing device
JP3374798B2 (ja) 1999-08-23 2003-02-10 日本電気株式会社 赤外線通信機能付き携帯無線端末とその通信方法
JP2001083948A (ja) 1999-09-13 2001-03-30 Canon Inc 表示装置及びその方法
JP3718091B2 (ja) 1999-11-16 2005-11-16 富士通株式会社 移動体搭載無線通信装置
FI110831B (fi) 1999-12-31 2003-03-31 Nokia Corp Menetelmä tiedonsiirron tehostamiseksi ja tiedonsiirtoprotokolla
GB0001025D0 (en) 2000-01-18 2000-03-08 Hewlett Packard Co Communication initiation method employing an authorisation server
JP2001202281A (ja) 2000-01-19 2001-07-27 Sony Corp 記録方法及び装置、転送方法及び装置、再生方法及び装置、記録媒体
JP2001308955A (ja) 2000-04-20 2001-11-02 Sharp Corp 伝送方法
WO2002015138A1 (en) 2000-08-14 2002-02-21 Adbeep, L.C.C. Method and apparatus for displaying advertising indicia on a wireless device
EP1323291A1 (en) 2000-09-18 2003-07-02 Koninklijke Philips Electronics N.V. Stand-alone monitor as photograph slide show projector
JP3748509B2 (ja) 2000-09-25 2006-02-22 キヤノン株式会社 撮像装置及び方法、並びに記憶媒体、並びに通信装置及び方法、並びに記憶媒体
JP2002135260A (ja) 2000-10-20 2002-05-10 Canon Inc 無線通信システム、送信無線装置、受信無線装置、伝送レート変更方法及び記憶媒体
JP2002158730A (ja) 2000-11-17 2002-05-31 Sony Corp 通信方法及び通信装置
US20020065065A1 (en) 2000-11-30 2002-05-30 E. Michael Lunsford Method and system for applying line of sight IR selection of a receiver to implement secure transmission of data to a mobile computing device via an RF link
US20020128039A1 (en) 2000-12-28 2002-09-12 Time Domain Corporation Method and apparatus for enabling communication and synchronization between an information processing device and a personal digital assistant using impulse radio wireless techniques
US6973023B1 (en) 2000-12-30 2005-12-06 Cisco Technology, Inc. Method for routing information over a network employing centralized control
JP3737033B2 (ja) 2001-01-24 2006-01-18 シャープ株式会社 情報交換システム
JP3636667B2 (ja) 2001-01-30 2005-04-06 三菱電機株式会社 通信方法、通信システム
US6842433B2 (en) 2001-04-24 2005-01-11 Wideray Corporation System and method for communicating information from a computerized distributor to portable computing devices
US6839564B2 (en) 2001-04-25 2005-01-04 Nokia Corporation Synchronization of database data
EP1265445A3 (en) 2001-06-08 2007-05-30 The Distribution Systems Research Institute Terminal-to-terminal communication connection control system for IP full service
JP2003008553A (ja) 2001-06-22 2003-01-10 Mitsubishi Electric Corp 送信機、受信機、送受信機および通信システム
US7339939B2 (en) * 2001-06-29 2008-03-04 Nokia Corporation Apparatus, method and system for an object exchange bridge
GB0115996D0 (en) 2001-06-29 2001-08-22 Nokia Corp Circuit-switched and packet-switched communications
JP3822539B2 (ja) * 2001-08-09 2006-09-20 山一電機株式会社 Ｉｃソケット
JP2003069610A (ja) 2001-08-22 2003-03-07 Canon Inc 通信装置、その制御方法、通信システム、及び制御プログラム
US20030093503A1 (en) 2001-09-05 2003-05-15 Olympus Optical Co., Ltd. System for controling medical instruments
JP3668170B2 (ja) 2001-09-20 2005-07-06 株式会社東芝 無線通信装置
JP2003101554A (ja) 2001-09-21 2003-04-04 Sony Corp 情報伝送システム、送信装置、受信装置、送信方法、受信方法、プログラム及びプログラム記録媒体
JP3871113B2 (ja) 2001-09-28 2007-01-24 株式会社日立製作所 通信端末装置、通信確立方法、および該方法に係るプログラム
EP2369770A1 (en) 2001-11-08 2011-09-28 Mitsubishi Denki Kabushiki Kaisha Packet Transmission Method and Packet Transmission Device
TW506594U (en) 2001-12-11 2002-10-11 Chung Shan Inst Of Science Self-service photograph printing device
JP2003218936A (ja) 2002-01-18 2003-07-31 Nissan Motor Co Ltd 可変長メッセージの送受信方法および送受信装置
JP2003258880A (ja) 2002-03-01 2003-09-12 Nippon Telegr & Teleph Corp <Ntt> ネットワークおよびノードおよびデータ転送方法
US7305007B2 (en) 2002-03-07 2007-12-04 Broadcom Corporation Receiver-aided set-up request routing
JP2003263403A (ja) 2002-03-07 2003-09-19 Canon Inc オブジェクト交換装置及びオブジェクト受信方法
US7007103B2 (en) 2002-04-30 2006-02-28 Microsoft Corporation Method to offload a network stack
US7480312B2 (en) 2002-08-19 2009-01-20 Tehuti Networks Ltd. Network traffic accelerator system and method
JP4201550B2 (ja) 2002-08-30 2008-12-24 富士通株式会社 負荷分散装置
JP2004104441A (ja) 2002-09-09 2004-04-02 Ricoh Co Ltd 無線ネットワークシステム、中継装置プログラム及び記憶媒体
US7014374B2 (en) 2002-09-25 2006-03-21 Seiko Epson Corporation Printing apparatus and printing method for performing pre-communication with an external device
US7363534B1 (en) 2002-09-30 2008-04-22 Cisco Technology, Inc. Method and system for stateful switch-over in a high-availability point to point system
JP3857210B2 (ja) 2002-10-18 2006-12-13 パイオニア株式会社 情報記録装置、情報再生装置、情報記録用プログラム、情報再生用プログラム、記録媒体及び情報記録媒体
US7411974B2 (en) 2002-11-14 2008-08-12 Qualcomm Incorporated Wireless communication rate shaping
JP2004177586A (ja) 2002-11-26 2004-06-24 Matsushita Electric Ind Co Ltd 携帯通信端末、コンテンツ再生装置およびコンテンツ再生システム
JP4108495B2 (ja) 2003-01-31 2008-06-25 松下電器産業株式会社 局発見処理方法および無線通信装置
GB0307861D0 (en) 2003-04-04 2003-05-14 Mitel Networks Corp System and method for pda to pda communication using a network portal
TW200425690A (en) 2003-05-13 2004-11-16 Benq Corp A header format of transmission control protocol/Internet protocol
JP3996870B2 (ja) 2003-05-13 2007-10-24 日本電信電話株式会社 無線データ通信開始方法および無線データ通信装置
US20050014468A1 (en) 2003-07-18 2005-01-20 Juha Salokannel Scalable bluetooth multi-mode radio module
US7474677B2 (en) 2003-08-12 2009-01-06 Bose Corporation Wireless communicating
JP2005070832A (ja) 2003-08-22 2005-03-17 Sharp Corp 電子装置およびインタフェース装置
EP1531646B1 (en) 2003-09-16 2010-11-03 Research In Motion Limited Method and apparatuses for selecting a wireless network based on quality of service (QoS) criteria associated with an application
TWI296083B (en) 2003-09-29 2008-04-21 Sharp Kk Communication controller, host-side controller, communication system, usb system, communication equipment, communication method, packet-based communication method, packet-based communication program, and storage medium
US7366532B2 (en) 2003-10-09 2008-04-29 Motorola, Inc. Group call management through receive/transmit synchronization
JP2005143086A (ja) 2003-10-17 2005-06-02 Matsushita Electric Ind Co Ltd 移動検知方法および移動端末
KR100606060B1 (ko) 2004-02-21 2006-07-26 삼성전자주식회사 휴대단말기의 데이터를 외부장치로 출력하는 장치 및 방법
JP4335090B2 (ja) 2004-05-14 2009-09-30 シャープ株式会社 移動端末装置
JP4597583B2 (ja) 2004-05-31 2010-12-15 シャープ株式会社 データ送信装置、データ受信装置、通信システム、データ送信装置の制御プログラム、データ受信装置の制御プログラム、および、コンピュータ読み取り可能な記録媒体
US8036244B2 (en) 2004-08-06 2011-10-11 Sharp Kabushiki Kaisha Transmitter, receiver, communication system, communication method, non-transitory computer readable medium
US7894383B2 (en) 2004-11-04 2011-02-22 Panasonic Corporation Multi-interface communication device, terminal, and path switching method
JP4592551B2 (ja) 2004-11-10 2010-12-01 シャープ株式会社 通信装置
JP4198741B2 (ja) 2005-01-28 2008-12-17 シャープ株式会社 通信機器、通信システム、通信方法、通信プログラム、通信回路
KR100902341B1 (ko) 2005-01-28 2009-06-12 샤프 가부시키가이샤 통신기기, 통신시스템, 통신방법, 통신 프로그램을 기록한 컴퓨터독취가능한 기록매체, 통신회로
US7787391B2 (en) 2005-01-28 2010-08-31 Sharp Kabushiki Kaisha Communication device, communication system, communication method, communication program, and communication circuit
JP4563201B2 (ja) 2005-01-28 2010-10-13 シャープ株式会社 通信方法
US8051182B2 (en) 2005-01-28 2011-11-01 Sharp Kabushiki Kaisha Communication device, communication system, communication method, communication program, and communication circuit
JP4094657B2 (ja) 2005-01-28 2008-06-04 シャープ株式会社 通信機器、通信システム、通信方法、通信プログラム、通信回路
US8265069B2 (en) 2005-06-23 2012-09-11 Nokia Corporation System, terminal, method, and computer program product for establishing a transport-level connection with a server located behind a network address translator and/or firewall
KR101114688B1 (ko) 2005-07-29 2012-02-29 삼성전자주식회사 휴대 통신 단말기 리모콘 장치 및 그 기능 수행 방법
JP4642617B2 (ja) 2005-09-16 2011-03-02 シャープ株式会社 受信機器、電子装置、通信方法、通信プログラム、および記録媒体
CN101305580B (zh) 2005-11-10 2012-01-18 夏普株式会社 数据发送装置及其控制方法、数据接收装置及其控制方法、数据发送系统、数据发送装置控制程序、数据接收装置控制程序以及记录有该程序的记录介质
JP4232802B2 (ja) 2006-08-23 2009-03-04 セイコーエプソン株式会社 データ受信装置、データ受信方法及びそのプログラム
JP4219950B2 (ja) 2006-10-16 2009-02-04 シャープ株式会社 通信機器、通信方法、通信回路、携帯電話機、プログラム、およびプログラムを記録したコンピュータ読み取り可能な記録媒体
JP2008141253A (ja) 2006-11-29 2008-06-19 Sharp Corp 通信機器、通信方法、通信回路、通信システム、プログラム、およびプログラムを記録したコンピュータ読み取り可能な記録媒体
JP2008141252A (ja) 2006-11-29 2008-06-19 Sharp Corp 通信機器、通信方法、通信回路、通信システム、プログラム、およびプログラムを記録したコンピュータ読み取り可能な記録媒体

Also Published As

Publication number Publication date
US8291273B2 (en) 2012-10-16
US20080313518A1 (en) 2008-12-18
CN101964705A (zh) 2011-02-02
CN101964705B (zh) 2012-08-08
JP4198741B2 (ja) 2008-12-17

Similar Documents

Publication Publication Date Title
JP4198741B2 (ja) 通信機器、通信システム、通信方法、通信プログラム、通信回路
JP4689689B2 (ja) 通信機器、通信システム、通信方法、通信プログラム、通信回路、携帯電話、表示装置、印刷装置および記録装置
JP4091095B2 (ja) 送信機、受信機、通信システム、通信方法、通信プログラム
US6574668B1 (en) Retransmission scheme in wireless computer networks
JP4094657B2 (ja) 通信機器、通信システム、通信方法、通信プログラム、通信回路
US7787391B2 (en) Communication device, communication system, communication method, communication program, and communication circuit
US8051182B2 (en) Communication device, communication system, communication method, communication program, and communication circuit
JP2006217242A (ja) 無線通信方法および無線通信装置
JPH1146187A (ja) データ伝送方法及びデータ伝送装置
JP2007520148A (ja) データフレームの再伝送方法および前記方法を用いるネットワーク装置
JP2008079330A (ja) 通信機器、通信方法、通信プログラム、通信回路、携帯電話、表示装置、印刷装置、記録装置
US20060155856A1 (en) Communications device, network system, communication management method, request signal, response signal, program, and recording medium containing the program
JP2008311969A (ja) 受信機、送信機、通信システム、受信機の制御方法、通信方法、受信機の制御プログラム、およびそれを記録した記録媒体
JP4948113B2 (ja) 送信機、受信機、通信システム、通信方法、通信プログラム
WO2006080403A1 (ja) 通信機器、通信システム、通信方法、通信プログラム、通信回路
JP7396298B2 (ja) 通信装置、及び通信方法
CN115694742A (zh) 在无线通信系统中发送确认信号的方法和电子设备
WO2006080330A1 (ja) 通信装置、通信システム、通信方法、通信プログラム、通信回路
JP3148733B2 (ja) 信号処理装置及び信号処理システム
WO2021186587A1 (ja) 送信局及び受信局
JP4430054B2 (ja) 通信装置、通信方法、通信プログラム、記録媒体
JP4137992B2 (ja) 通信機器、通信システム、通信方法、通信プログラム、通信回路、携帯電話、表示装置、印刷装置、記録装置
JP4394141B2 (ja) 通信装置、通信システム、通信方法、通信プログラム、通信回路
CN115967467A (zh) 数据处理方法、装置及计算机可读存储介质
WO2006080372A1 (ja) 通信機器、通信システム、通信方法、通信プログラム、通信回路

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080324

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080603

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080804

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: 20080930

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20081001

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20111010

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4198741

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121010

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131010

Year of fee payment: 5

SG99 Written request for registration of restore

Free format text: JAPANESE INTERMEDIATE CODE: R316G99

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350