(57)【要約】【課題】コマンドのデータ構成をリアルタイムに変更してリトライ送信を行なうようにした技術を提供する。【解決手段】  通信端末は、通信相手先端末に向けて送信した複数のデータを含むコマンドの応答として前記通信相手先端末から応答を受信する受信手段と、前記送信手段により前記コマンドを送信した時点から基準時間内に前記受信手段により前記応答を受信するか否かに基づいて、前記通信相手先端末の通信負荷状態を判定する判定手段と、前記通信相手先端末で通信負荷が発生していると判定された場合に、前記通信相手先端末へ前記コマンドをリトライ送信した回数に応じて異なる方法で前記コマンドのデータ構成を変更する構成変更手段と、前記データ構成変更後のコマンドを前記通信相手先端末にリトライ送信する送信手段とを具備する。【選択図】  図１
2013222990.tif 000002
【特許請求の範囲】
【請求項１】
通信相手先端末に向けて送信した複数のデータを含むコマンドの応答として前記通信相手先端末から応答を受信する受信手段と、
前記コマンドを送信した時点から基準時間内に前記受信手段により前記応答を受信するか否かに基づいて、前記通信相手先端末の通信負荷状態を判定する判定手段と、
前記通信相手先端末で通信負荷が発生していると判定した場合に、前記通信相手先端末へ前記コマンドをリトライ送信した回数に応じて異なる方法で前記コマンドのデータ構成を変更する構成変更手段と、
前記データ構成変更後のコマンドを前記通信相手先端末にリトライ送信する送信手段と
を具備することを特徴とする通信端末。
【請求項２】
前記構成変更手段は、
前記リトライ送信した回数に応じて異なる方法で前記コマンド内のデータの配置位置を変更することで前記データ構成の変更を行なう
ことを特徴とする請求項１記載の通信端末。
【請求項３】
前記コマンドに含まれる前記複数のデータ各々に対してその優先度を示す評価値が設定されており、
前記構成変更手段は、
前記コマンド内の前半部から前記評価値の順に前記複数のデータを再配置することで前記データ構成の変更を行なう
ことを特徴とする請求項１又は２記載の通信端末。
【請求項４】
前記コマンドに含まれる前記複数のデータ各々に対して前記通信相手先端末に既に送信済みであるか否かの情報が保持されており、
前記構成変更手段は、
前記保持された情報に基づいて、前記コマンド内の前半部から順に前記通信相手先端末へ未送信のデータを再配置することで前記データ構成の変更を行なう
ことを特徴とする請求項１から３のいずれか１項に記載の通信端末。
【請求項５】
前記データ構成変更後のコマンドは、前記データ構成変更前のコマンドと同じサイズである
ことを特徴とする請求項２から４のいずれか１項に記載の通信端末。
【請求項６】
前記構成変更手段は、
前記コマンド内のデータの配置位置を変更することで前記リトライ送信を所定回数行なった後、前記リトライ送信した回数に応じて異なる方法で前記コマンド内のデータを削除することで前記データ構成の変更を行なう
ことを特徴とする請求項２から４のいずれか１項に記載の通信端末。
【請求項７】
前記コマンドに含まれる前記複数のデータ各々に対して前記通信相手先端末に既に送信済みであるか否かの情報が保持されており、
前記構成変更手段は、
前記保持された情報に基づいて、前記通信相手先端末に既に送信済みであるデータを前記コマンド内から削除する
ことを特徴とする請求項６記載の通信端末。
【請求項８】
前記コマンドに対応して該コマンド内のデータを減らした第２のコマンドが予め保持されており、
前記構成変更手段は、
前記コマンド内のデータを削除したコマンドとして、前記第２のコマンドを取得することで前記コマンドのデータ構成を変更する
ことを特徴とする請求項６又は７記載の通信端末。
【請求項９】
前記基準時間は、
コマンドを送信する度に、当該コマンドを送信した時点から前記受信手段により前記応答を受信するまでの応答時間を測定し、その平均値を算出することにより得られた値である
ことを特徴とする請求項１から８のいずれか１項に記載の通信端末。
【請求項１０】
通信端末の処理方法であって、
受信手段が、通信相手先端末に向けて送信した複数のデータを含むコマンドの応答として前記通信相手先端末から応答を受信する工程と、
判定手段が、前記コマンドを送信した時点から基準時間内に前記受信手段により前記応答を受信するか否かに基づいて、前記通信相手先端末の通信負荷状態を判定する工程と、
構成変更手段が、前記通信相手先端末で通信負荷が発生していると判定した場合に、前記通信相手先端末へ前記コマンドをリトライ送信した回数に応じて異なる方法で前記コマンドのデータ構成を変更する工程と、
送信手段が、前記データ構成変更後のコマンドを前記通信相手先端末にリトライ送信する工程と
を含むことを特徴とする処理方法。
【請求項１１】
コンピュータを、請求項１から９のいずれか１項に記載の通信端末として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信端末、その処理方法及びプログラムに関する。
【背景技術】
【０００２】
従来、通信端末においては、通信エラーの発生によるリトライ送信時に、当該通信エラーが発生した際のデータ量よりも少ないデータ量でデータ送信を行なう技術が提案されている（特許文献１）。この技術では、リトライ送信が成功した時のデータ量を送受信の双方で記憶しておき、次回以降その記憶されたデータ量でデータ送信を行なう。
【０００３】
また、別の手法としては、通信エラー発生時のデータを保証するために、画像データなどを記憶装置（ＨＤＤ）へ書き込んでおき、通信エラーが発生した場合に当該記憶装置に保存されたデータを送信する技術が提案されている（特許文献２）。
【０００４】
上記以外にも、通信コマンドのヘッダに優先処理レベルや連続して送受信した回数などを記憶しておき、通信エラー発生時に、それらヘッダに格納されたデータから送受信を行なう際のデータの優先度を判定して通信を行なう技術が提案されている（特許文献３）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０００−１１５２５８号公報
【特許文献２】特開２００８−２６９３３５号公報
【特許文献３】特開平０７−２７３７８９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、従来の方式では、例えば、以下に示す課題がある。特許文献１の手法では、通信エラー発生時よりも少ないデータ量で送受信を行なうため、いくつデータを削除すれば通信エラーが回避できるデータ量であるかを直ぐには特定できない。そのため、データ数を削減していった結果として通信エラーが発生し難くなるが、動作に必要なデータまで削減してしまう可能性があり、必要なデータの送受信が行なわれない可能性がある。
【０００７】
また、特許文献２の手法では、通信エラー発生時に備えてデータを全て記憶装置に保存しておくので、記録装置に読み書きする時間を確保する必要があり、その時間がタイムロスになってしまう。そのため、通信データのリアルタイム性が損なわれてしまう。また更に、どの程度、データのバックアップ用に記憶装置の空き容量を確保しておく必要があるかを予測するのが困難であり、余分に容量の大きい記憶装置を用意してく必要があり、コスト的面での問題もある。
【０００８】
また更に、特許文献３の手法では、上述した情報（優先処理レベルや回数）を格納するためのエリアを通信ヘッダ上で確保する必要があり、通信データの総量が大きくなってしまう。そのため、通信データの総量が増大してしまい、トラフィック量の増大による通信エラーを回避するための対策としては不十分である。
【０００９】
そこで、本発明は、上記課題に鑑みてなされたものであり、コマンドのデータ構成をリアルタイムに変更してリトライ送信を行なうようにした技術を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するため、本発明の一態様による通信端末は、通信相手先端末に向けて送信した複数のデータを含むコマンドの応答として前記通信相手先端末から応答を受信する受信手段と、前記コマンドを送信した時点から基準時間内に前記受信手段により前記応答を受信するか否かに基づいて、前記通信相手先端末の通信負荷状態を判定する判定手段と、前記通信相手先端末で通信負荷が発生していると判定した場合に、前記通信相手先端末へ前記コマンドをリトライ送信した回数に応じて異なる方法で前記コマンドのデータ構成を変更する構成変更手段と、前記データ構成変更後のコマンドを前記通信相手先端末にリトライ送信する送信手段とを具備する。
【発明の効果】
【００１１】
本発明によれば、従来の構成よりも、通信エラーを抑制できるため、通信の継続性を向上させられる。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施の形態に係わる通信システムの構成の一例を示す図。
【図２】コマンド送信時の処理の概要を示す図。
【図３】コマンド送信時の処理の概要を示す図。
【図４】第１の通信端末１０（送信側の通信端末）の動作の一例を示すフローチャート。
【図５】図４のＳ１０７に示すリトライ処理の動作の一例を示すフローチャート。
【図６】第１の構成変更の概要を示す図。
【図７】第３の構成変更の概要を示す図。
【図８】実施形態２の概要を示す図。
【図９】実施形態２の概要を示す図。
【発明を実施するための形態】
【００１３】
以下、本発明の一実施の形態について添付図面を参照して詳細に説明する。
【００１４】
図１を用いて、本発明の一実施の形態に係わる通信システムの構成の一例について説明する。
【００１５】
通信システムは、第１の通信端末１０と第２の通信端末３０とを具備して構成されており、これら端末は、有線又は無線のいずれかによって通信可能に構成されている。なお、本実施形態においては、第１の通信端末１０を送信側の通信端末として説明し、第２の通信端末３０を受信側の通信端末（通信相手先端末）として説明する。
【００１６】
ここで、これら通信端末の機能的な構成について説明する。なお、第１の通信端末１０及び第２の通信端末３０は、同様の構成を有しているため、ここでは、代表して、第１の通信端末１０の構成について説明する。
【００１７】
第１の通信端末１０には、所謂、コンピュータが内蔵されており、その機能的な構成として、通信部１１と、制御部１４と、記憶部１５と、通信負荷判定部１６と、リトライ部１９とが具備される。
【００１８】
通信部１１は、第２の通信端末３０との間でデータの通信を行なう機能を有し、データ送信を行なう送信部１２と、データ受信を行なう受信部１３とを具備して構成される。
【００１９】
制御部１４は、例えば、ＣＰＵ（Central Processing Unit）等で構成され、第１の通信端末１０における制御を統括制御する。すなわち、第１の通信端末１０に設けられる各構成は、制御部１４によってその動作が制御される。記憶部１５は、例えば、ＲＯＭ（Read Only Memory）及びＲＡＭ（Random Access Memory）等で構成され、各種データを記憶する。
【００２０】
通信負荷判定部１６は、通信相手先端末（この場合、第２の通信端末）の通信負荷状態を判定する機能を果たし、応答時間測定部１７と、基準時間算出部１８とを具備して構成される。
【００２１】
応答時間測定部１７は、コマンドの送信後、その応答時間が返ってくるまでの時間（応答時間）を測定する。すなわち、通信負荷判定部１６においては、コマンドを送信した時点から基準時間内に応答を受信するか否かに基づいて、通信相手先端末（第２の通信端末３０）の通信負荷状態を判定する。
【００２２】
基準時間算出部１８は、上記基準時間を算出する。基準時間算出部１８においては、第１の通信端末１０と第２の通信端末３０との間でリアルタイムに行なわれる通信の中で、その都度応答時間を取得し、その応答時間の積算を送受信回数で割り、それにより得られた平均値を基準時間として求める。すなわち、基準時間は、第１の通信端末１０と第２の通信端末３０との間でコマンド及びその応答の送受信が行なわれる度に、リアルタイムにその値が更新される。
【００２３】
リトライ部１９は、通信負荷判定部１６により通信相手先端末（第２の通信端末３０）で通信負荷が発生していると判定された場合に、リトライ処理を行なう機能を果たし、カウント部２０と、データ構成変更部２１とを具備して構成される。
【００２４】
カウント部２０は、リトライ送信した回数（データ構成の変更を行なった回数）をカウントする。データ構成変更部２１は、コマンドをリトライ送信した回数に応じて異なる方法でコマンドのデータ構成を変更する。このデータ構成の変更処理の詳細については後述するが、この処理では、リトライ送信した回数に応じて異なる方法でコマンド内のデータの配置位置の変更を行なう。
【００２５】
ここで、図１に示す第１の通信端末１０及び第２の通信端末３０との間で行なわれる通信の概要について説明する。まず、図２を用いて、コマンドの送信後、正常に応答が返って来た場合の動作の一例について説明する。
【００２６】
第１の通信端末１０は、コマンド５１を送信すると、第２の通信端末３０からその応答５２が第１の通信端末１０に送られてくる。
【００２７】
ここで、第１の通信端末１０は、応答時間測定部１７において、コマンド５１を送信する度に、当該コマンドを送信してから応答５２を受信するまでの時間を測定する。そして、基準時間算出部１８において、そのトータル時間を送信したコマンドの数で割り、平均値を算出し、このようにして算出された時間を基準時間Ｘとして保持する。基準時間Ｘは、このようにしてリアルタイムに更新され、通信相手先端末（第２の通信端末３０）の通信負荷状態の判定に用いられる。
【００２８】
次に、図３を用いて、コマンドの送信後、正常に応答が返って来なかった場合の動作の一例について説明する。
【００２９】
第１の通信端末１０が、コマンド５１を送信する。第２の通信端末３０からそれに対する応答５２が第１の通信端末１０に送られてくる。この場合、第２の通信端末３０においては、通信負荷が増大しており、応答５２の送信に失敗する。
【００３０】
一方、第１の通信端末１０は、コマンド５１の送信後、リトライ時間が経過するまで待機する。リトライ時間は、上述した基準時間Ｘと、マージン時間Ｙとを加算した時間となる。
【００３１】
ここで、リトライ時間を経過しても、第２の通信端末３０から応答が送られてこないため、第１の通信端末１０は、コマンド５３を再送する（リトライ１回目）。この場合も、第２の通信端末３０から応答５４が送られて来ないため、第１の通信端末１０は、再度、コマンド５５を再送する（リトライ２回目）。
【００３２】
第１の通信端末１０は、上述したリトライ送信を複数回繰り返し行なう。第１の通信端末１０は、リトライｎ回目のコマンド送信５６を行なった後、最初にコマンド（コマンド５１）を送信した時点から経過した時間が、エラー時間Ｚを越えたため、通信エラー５７として、このリトライ処理を終了する。
【００３３】
すなわち、第１の通信端末１０は、コマンドを送信した場合にその応答が受信できない場合には、エラー時間が経過するまでの間、リトライ時間を迎える度に、コマンドの再送を行なう。なお、このとき、第１の通信端末１０は、リトライ送信した回数に応じてコマンド内のデータ構成を変更する。
【００３４】
次に、図４を用いて、図１に示す第１の通信端末１０（すなわち、送信側の通信端末）の動作の一例について説明する。
【００３５】
この処理は、第１の通信端末１０が、送信部１２において、コマンド送信を行なうと開始される（Ｓ１０１）。コマンドの送信後、第１の通信端末１０は、通信負荷判定部１６において、受信部１３により応答を受信したか否かを判定する（Ｓ１０２）。
【００３６】
ここで、応答を受信した場合には（Ｓ１０２でＹＥＳ）、第１の通信端末１０は、そのままこの処理を終了する。一方、応答を受信していない場合には（Ｓ１０２でＮＯ）、第１の通信端末１０は、通信負荷判定部１６において、リトライ時間（基準時間Ｘ＋マージン時間Ｙ）が経過したか否かの判定を行なう。
【００３７】
リトライ時間が経過していなければ（Ｓ１０３でＮＯ）、第１の通信端末１０は、再度、Ｓ１０２の処理に戻り、応答を受信したか否かの判定を行なう。また、リトライ時間が経過していれば（Ｓ１０３でＹＥＳ）、第１の通信端末１０は、通信負荷判定部１６において、エラー時間Ｚが経過したか否かを判定を行なう（Ｓ１０４）。
【００３８】
判定の結果、エラー時間Ｚが経過していれば（Ｓ１０４でＹＥＳ）、第１の通信端末１０は、通信エラーとして（Ｓ１０５）、リトライ回数を初期化（この場合、ゼロ）した後（Ｓ１０６）、この処理を終了する。すなわち、コマンド構成を変更したにも拘わらず、通信エラーに至ってしまった場合には、リトライ回数（コマンドのデータ構成の変更回数）をクリアすることにより、コマンドのデータ構成の変更処理を初期化し、元のコマンドのデータ構成に戻す。
【００３９】
また、Ｓ１０４の判定の結果、エラー時間Ｚが経過していなければ（Ｓ１０４でＮＯ）、第１の通信端末１０は、リトライ部１９において、リトライ処理を行なう（Ｓ１０７）。また、このとき、第１の通信端末１０は、カウント部２０において、リトライ数をカウントアップする（Ｓ１０８）。その後、第１の通信端末１０は、再度、Ｓ１０２の処理に戻る。
【００４０】
次に、図５を用いて、図４のＳ１０７に示すリトライ処理の詳細について説明する。
【００４１】
リトライ処理が開始すると、第１の通信端末１０は、データ構成変更部２１において、コマンドのデータ構成数を判定する。判定の結果、コマンドのデータ構成数が２以上でなければ（Ｓ２０１でＮＯ）、図４のＳ１０１で送信したコマンドをそのまま再送する（Ｓ２０２）。この場合、コマンドを構成するデータが１つであるため、コマンドの構成の変更を行なえないため、そのまま再送処理を行なうことになる。
【００４２】
一方、コマンドのデータ構成数が２以上であれば（Ｓ２０１でＹＥＳ）、第１の通信端末１０は、データ構成変更部２１において、リトライ数を確認し（Ｓ２０３）、当該リトライ回数に応じてコマンドのデータ構成を変更する（Ｓ２０４）。そして、データ構成変更後のコマンドを第２の通信端末３０に向けて送信する（Ｓ２０５）。
【００４３】
次に、図５のＳ２０４に示すコマンドのデータ構成の変更処理の概要について説明する。この処理では、上述した通り、リトライ回数に応じて異なる方法でコマンドのデータ構成の変更を行なう。
【００４４】
まず、図６を用いて、第１の構成変更の概要について説明する。
【００４５】
第１の構成変更においては、初期のコマンドを構成するデータの配置位置を変更する（言い換えれば、データ構成を組み替える）。具体的には、コマンド内に配置されているデータのうち、絶対に送信する必要のあるデータをコマンド内の前半部に配置し、一度でも送ったデータをコマンド内の後半部に配置する。
【００４６】
このコマンドのデータ構成の変更処理について具体的に説明する。図６に示すように、元のコマンド６１のデータ構成を参照すると、コマンド内には、ヘッダ部分とそれ以降に続くデータのレングスとが含まれており、それ以降に実際の構成データが９つ続く構成となっている。
【００４７】
変更後のコマンド６２のデータ構成を参照すると、変更後のコマンド６２のデータ構成では、最後尾に配置されていた実際の動作に絶対に必要なデータがコマンド内の前半部に移動している。また、実際の動作に影響を与えないデータがコマンド内の前半部（最前列）から後半部へ再配置されている。
【００４８】
なお、コマンド内の後半部に配置するデータとしては、例えば、通信相手先端末に既に送っているデータや、重複して割り付けられているデータ、電源オン時などに一度送ってしまえば変更が起きないデータなどが挙げられる。
【００４９】
ここで、このようなコマンド内のデータの配置位置を決めるために、記憶部１５において、データに対応付けてその優先度を示す評価値を保持している。すなわち、データ構成変更部２１においては、この評価値に基づいてコマンド内のデータの配置位置を変更し、データ構成の変更を行なう。
【００５０】
このように第１の構成変更においては、実際の動作に絶対に必要なデータをコマンド内の前半部に配置し、当該データが通信相手先端末に送信される可能性を高くする。これにより、通信相手先端末がコマンド内の全てのデータを受信できなかった場合であっても、コマンド内の一部データ（前半部）を受信できれば、当該通信相手先端末の実動作に影響を与えずに済む。これにより、通信エラーを極力抑制できるため、通信の継続性を向上させることができる。
【００５１】
なお、図６の例では、コマンド内のデータ群が大きく２つある場合について説明したが、勿論、図７に示すように、コマンド内のデータ群がそれ以上（３つ以上）ある場合にも評価値に基づいて上記図６同様にデータ構成の配置位置を変更できる（すなわち、評価値の高い順にコマンド内の前半部にデータを再配置する）。
【００５２】
次に、第２の構成変更の概要について説明する。第２の構成変更では、例えば、電源オン起動後に一度でも通信相手先に送信できているか否かを示す送信結果情報を保持し、当該情報に基づいてコマンドのデータ構成を変更する。
【００５３】
具体的には、図８に示すように、コマンド内のデータ各々に対応して送信済みであるか否かを示すフラグ（送信済み：１、未送信：０）を設定した情報を送信結果情報として、例えば、記憶部１５に保持する。なお、ここでは、コマンドＡについての送信結果情報を示しているが、この情報は、各コマンドに対応して保持しておく。
【００５４】
そして、データ構成変更部２１において、当該送信結果情報を参照して、未送信のデータをコマンド内のデータの前半部に再配置し、既に送信済みであるデータをコマンド内の後半部（具体的には、未送信のデータの後）に再配置し、コマンド内のデータ構成の変更を行なう。この第２の構成変更を行なった場合にも、実際の動作に絶対に必要なデータをコマンド内の前半部に移動できるため、第１の構成変更の場合と同様の効果が得られる。
【００５５】
第１の通信端末１０においては、このような第１の構成変更及び第２の構成変更をリトライ回数に応じて切り替えて行なう。例えば、リトライ回数１回目で第１の構成変更を行ない、リトライ回数２回目で第２の構成変更を行ない、リトライ回数３回目で第１の構成変更及び第２の構成変更を組み合わせた構成変更等を行なうようにすれば良い。
【００５６】
以上説明したように本実施形態によれば、通信相手先端末で通信負荷が発生していると判定した場合に、リトライ送信した回数に応じて異なる方法でコマンドのデータ構成を変更してリトライ送信を行なう。すなわち、通信エラーが発生する前に通信相手先端末の通信負荷を検知して、コマンドのデータ構成をリアルタイムに変更してリトライ送信を行なうことができる。
【００５７】
これにより、従来の構成よりも、通信エラーを抑制できるため、通信の継続性を向上させられる。
【００５８】
また、コマンド内のデータの配置位置を変更するといった構成を採るため、データ構成変更前とデータ構成変更後とでは、データのサイズが同一となる。すなわち、本実施形態によれば、データの削除等を行なわなくても、通信の継続性を向上させることができる。
【００５９】
（実施形態２）
次に、実施形態２について説明する。実施形態２においては、上述したコマンドのデータ構成の変更として更に、コマンド内のデータの数を減らしてリトライ処理を行なう場合について説明する。この処理は、実施形態１で説明したデータ構成の変更（データの配置位置の変更）を所定回数行なった後、行なえば良い。なお、実施形態２に係わる第１の通信端末１０及び第２の通信端末３０の構成やその処理の流れは、上述した実施形態１と同様となるので、ここでは、その説明については省略する。
【００６０】
ここで、実施形態２に係わるコマンドのデータ構成の変更処理の概要について説明する。ここでは、コマンド内のデータの数を減らしてリトライ処理を行なう手法として２通り例を挙げて説明する。
【００６１】
まず、第１の削除方法では、通信仕様として規定されたコマンドの他に、これとは別に同様のコマンドではあるが、通信負荷が軽減されるようにデータ構成を変更したコマンドを予め用意しておく。
【００６２】
具体的には、図９に示すように、コマンド体系として、Ｉ群（第１のコマンド）とＩＩ群（第２のコマンド）とを予め定義しておく。Ｉ群のコマンドは、元々の通信仕様通りのコマンド体系である。ＩＩ群のコマンドは、動作の最初に一度だけ送信すれば、後の動作に影響しないデータや今回送信しなくても前回送信済みのデータを参照しても今回の動作には影響を与えないデータなどを組み合わされたコマンド体系である。
【００６３】
実施形態２に係わる第１の通信端末１０は、通信負荷判定部１６において、通信相手先端末で通信負荷が発生していると判定した場合、元々の通信仕様でコマンド体系Ｉ群で動作しているときには、コマンド体系ＩＩ群に切り替えてリトライ処理を行なう。これにより、通信相手先端末の負荷を軽減させることができる。
【００６４】
次に、第２の削除方法について説明する。第２の削除方法では、リトライ送信に際して、上記図８で説明した送信結果情報を用いてコマンド内のデータを削除する。具体的には、今回送信するコマンド内のデータのうち、既に送信済みのデータを削除する。この場合にも、上記第１のデータ削除方法と同様に、コマンド内のデータ数を減らしてリトライ処理を行なうことができる。
【００６５】
実施形態２に係わる第１の通信端末１０においては、実施形態１で説明したデータ構成の変更（データの配置位置の変更）を所定回数行なった後、このような第１の削除方法及び第２の削除方法をリトライ回数に応じて切り替えて行なう。例えば、リトライ回数１回目〜３回目では、上述した実施形態１の処理を実施し、リトライ回数４回目及び５回目では、第１の削除方法及び第２の削除方法を実施し、それ以降の処理では、それらの組み合わせ等によりリトライ処理を実施するようにすれば良い。
【００６６】
以上が本発明の代表的な実施形態の一例であるが、本発明は、上記及び図面に示す実施形態に限定することなく、その要旨を変更しない範囲内で適宜変形して実施できるものである。
【００６７】
例えば、装置の各動作フェーズ（電源オンから起動処理、制御対象の立上げ処理から動作中、動作終了、待機中など）毎に、リトライ処理を変更するようにしても良い。具体的には、動作フェース毎に、送受信の平均値や通信リトライまでの閾値、コマンドのデータ構成の変更に至るまでの閾値などを可変させるようにしても良い。これにより、より状態に合ったリアルタイムなコマンドのデータ構成の変更を行なえる。
【００６８】
また、例えば、上述した実施形態においては、実施形態１の処理を行なった後、実施形態２の処理を行なう場合について説明したが、これに限られず、実施形態２の処理を先に行うようにしても良い。すなわち、通信負荷が発生していると判定した場合に、データの削除処理を行なうことでリトライ処理を行ない、その後、実施形態１で説明したリトライ処理を行なうようにしても良い。
【００６９】
（その他の実施形態）
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
2013222990.tif 000003
【図２】
2013222990.tif 000004
【図３】
2013222990.tif 000005
【図４】
2013222990.tif 000006
【図５】
2013222990.tif 000007
【図６】
2013222990.tif 000008
【図７】
2013222990.tif 000009
【図８】
2013222990.tif 000010
【図９】
2013222990.tif 000011