JP2003157190A

JP2003157190A - 同期メッセージ処理方法

Info

Publication number: JP2003157190A
Application number: JP2002257401A
Authority: JP
Inventors: Tsutomu Uenoyama; 努上野山; Kazunori Yamada; 和範山田
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 2001-09-05
Filing date: 2002-09-03
Publication date: 2003-05-30

Abstract

(57)【要約】【課題】同期メッセージが大量に送られて来た場
合でも、被害に遭わずに済むこと。【解決手段】端末装置１００は、データ同期すべきデ
ータを保管し、このデータへのユーザ操作を受け付ける
アプリケーション部１０２と、このアプリケーション部
１０２で保管するデータをサーバ３００のデータと同期
させるための同期メッセージを作成するとともに、サー
バ３００から受信した同期メッセージを解釈する同期処
理部１０４と、この同期処理部１０４が作成した同期メ
ッセージをネットワーク２００に送信するためにプロト
コル処理を行うとともに、ネットワーク２００から受信
した同期メッセージを同期処理部１０４に渡すためにプ
ロトコル処理を行うプロトコル処理部１０６とを有し、
プロトコル処理部１０６は、先に受信した同期メッセー
ジとの受信時間間隔が一定時間以内の同期メッセージを
破棄する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワークを介
してサーバに接続し、サーバに管理されたデータとのデ
ータ同期を行う端末装置における同期メッセージ処理方
法に関する。

【０００２】

【従来の技術】情報機器が普及した現在、一人のユーザ
が、携帯端末や携帯電話機、パソコンなど、幾つかの端
末装置を所有し、その各々に住所録やスケジュールなど
のデータを記録している場合が少なくない。このように
複数の端末装置に記録されているデータを最新のデータ
に更新することを「データ同期」といい、データ同期を
取ることにより、各端末装置で保持されるデータの内容
が均一化する。

【０００３】近年、ユーザの各端末装置のデータ同期を
ユーザに代わって実行するシステムや、ネットワークを
介して関係者の間で仕事に必要なデータを共有し、この
データを関係者が参照したり、関係者の端末にコピーし
たりすることができるグループウエアと呼ばれるシステ
ムが出現している。

【０００４】こうしたシステムでは、図１０に示すよう
に、端末装置（図中では単に「端末」と略称する。他の
図面についても同様）１０として、例えば、携帯電話１
２や携帯端末１４、デスクトップパソコン１６、ノート
パソコン１８などが、インターネット２０を介してサー
バ３０に接続されており、例えば、携帯電話１２の住所
録が更新されたとき、その更新データがサーバ３０に登
録される。携帯電話１２以外の端末装置１４、１６、１
８に記録された住所録を更新する場合は、その端末装置
１４〜１８からサーバ３０に対し、インターネット２０
を通じてデータ同期の要求が出される。これを受けて、
サーバ３０は、住所録の更新データを返信し、当該端末
装置１４〜１８の住所録が更新される。

【０００５】図１１は、この場合の処理シーケンスを示
している。まず、データ同期を求める端末装置１０は、
サーバ３０に対して同期開始を要求し、最終更新日時等
の初期情報を提供する（１）。これを受けて同期処理が
開始され、サーバ３０は、サーバ３０側の最終更新日時
等の初期情報を端末装置１０に提供する（２）。端末装
置１０は、データ更新が必要な場合、住所録の更新履歴
をサーバ３０に提供し（３）、サーバ３０は、自らが保
持する住所録データと端末装置１０の住所録データとを
比較して、更新内容を端末装置１０に伝え、更新を指示
する（４）。端末装置１０は、サーバ３０から受けた更
新内容通りに住所録の更新が完了すると、同期完了通知
をサーバ３０に送信する（５）。サーバ３０は、その端
末装置１０での更新状態を記録して、同期完了確認通知
を端末装置１０に送信する（６）。

【０００６】しかし、かかる先行技術は、文献公知発明
に係るものでないため、記載すべき先行技術文献情報は
ない。

【０００７】こうしたデータ同期処理を行うには、端末
装置１０に専用のソフトウエアを搭載することが必要で
あり、このソフトウエアには汎用性が無い。そのため、
現在、データ同期処理の標準化が検討されており、この
標準化の方式は一般に「ＳｙｎｃＭＬ」と呼ばれてい
る。

【０００８】ＳｙｎｃＭＬによる新しい同期処理シーケ
ンスでは、図１２に示すように、まず、サーバ３０ａが
端末装置１０ａに対して、データ同期の開始を指示する
メッセージ（「サーバアラートメッセージ」と呼ばれ
る）を送り（１）、端末装置１０ａが、このメッセージ
を解釈（メッセージ処理）して、表示画面に表示する
（２）。ユーザがデータ同期処理を選択すると、図１１
と同様に、端末装置１０ａからサーバ３０ａに同期開始
の要求と初期情報とが提供され（３）、図１１と同じ同
期処理が開始される（４）（例えば、非特許文献１参
照）。

【０００９】このＳｙｎｃＭＬによる新しい同期処理シ
ーケンスでは、サーバ３０ａ側からデータ同期開始の指
示を出し、端末装置１０ａでそのメッセージ処理を行う
点が、図１１の場合と相違している。

【００１０】このとき、サーバ３０ａは、ユーザや端末
装置１０ａの状態を知らずにサーバアラートメッセージ
を送出するので、端末装置１０ａから同期開始要求
（３）が送られない場合も発生する。そのため、サーバ
３０ａは、端末装置１０ａから同期開始要求（３）を受
信しないとき、サーバアラートメッセージを繰り返し送
信する。

【００１１】このように、サーバ側から同期開始指示を
出すことにより、ユーザは、端末装置のデータ同期を忘
れずに実行することができる。また、端末装置のメーカ
では、販売した端末装置をサーバで登録・管理するシス
テムにＳｙｎｃＭＬ方式を導入することにより、各端末
装置のソフトウエアのバージョンアップなどをサーバを
通じて行うことが可能になる。

【００１２】図１３は、ＳｙｎｃＭＬのプロトコル構成
を示している。端末装置１０ａとサーバ３０ａとの間で
アプリケーションのデータをやり取りする通信では、対
応するそれぞれの階層において、送信側では、データを
分割したり、そのデータにヘッダを付けたりする処理が
行われ、受信側では、データのヘッダを外したり、デー
タを結合したりする処理が行われる。

【００１３】図１３では、端末装置１０ａの住所録のデ
ータベースに新たに追加したデータがサーバ３０ａに送
信される際の処理を例示している。このデータは、Ｓｙ
ｎｃＭＬコアにより同期メッセージのデータフォーマッ
トに変換され、その後、セッション層（例えば、ＨＴＴ
Ｐ）、トランスポート層（例えば、ＴＣＰ）、およびネ
ットワーク層（例えば、ＩＰ）の処理を経て、ＩＰヘッ
ダが付されたパケットに成形され、例えば、ＬＡＮで接
続されたサーバ３０ａに伝送される。

【００１４】サーバ３０ａでは、受信したデータが、ネ
ットワーク層、トランスポート層、およびセッション層
での処理により、同期メッセージのフォーマットのデー
タに戻される。セッション層は、そのフォーマットから
データが同期メッセージであることを識別して、それを
ＳｙｎｃＭＬコアに渡す。ＳｙｎｃＭＬコアは、このデ
ータを解釈してアプリケーションの住所録のデータベー
スに書き込むデータ構造に変換する。こうして、サーバ
３０ａのアプリケーションのデータベースに新たなデー
タが追加される。

【００１５】このプロトコル構造の各階層の処理は、端
末装置１０ａやサーバ３０ａのＣＰＵで行われるが、上
位の階層の処理ほどＣＰＵの負荷が増大して処理に時間
がかかる。例えば、大雑把に言って、１００バイトのデ
ータを処理する場合、ネットワーク層、トランスポート
層、およびセッション層の合計の処理時間が０.０１ｓ
ｅｃとすると、ＳｙｎｃＭＬコアで行われるメッセージ
処理は、おおよそその１０倍の０.１ｓｅｃの処理時間
が必要である。

【００１６】

【非特許文献１】ＳｙｎｃＭＬＳｙｎｃＰｒｏｔｏ
ｃｏｌ，ｖ１.１、インターネット＜ＵＲＬ："http://s
yncml.org/technology.html"＞

【００１７】

【発明が解決しようとする課題】しかしながら、サーバ
側から同期開始指示メッセージ（サーバアラートメッセ
ージ）を送るＳｙｎｃＭＬ方式では、次のような問題が
予想される。

【００１８】データ同期処理の過程での端末装置１０ａ
とサーバ３０ａとの間の交信は、相手方の応答を待って
次の送信に進むが、サーバ３０ａ側が端末装置１０ａに
対してデータ同期の開始を指示するサーバアラートメッ
セージは、ユーザの意志や端末装置１０ａの状態に関係
なく送信され、これを受信した端末装置１０ａでは、そ
のメッセージを解釈する処理が行われる。そして、解釈
の結果を基にデータ同期を始めるか否かは、ユーザの選
択に任されるが、サーバアラートメッセージを受信した
場合、メッセージ処理までは不可欠であり、その処理の
ためのＣＰＵの負担は少なくない。

【００１９】もしも悪意を持つ人物（ハッカーやクラッ
カー）が端末装置１０ａに大量（例えば、１秒に１００
メッセージなど）の同期メッセージを送り付けた場合に
は、端末装置１０ａは、そのメッセージ処理のために他
の処理がストップし、最悪のケースでは、システムがフ
リーズする事態に立ち至る虞がある。ここで、「同期メ
ッセージ」とは、データ同期の処理に関係する任意のメ
ッセージをいい、例えば、図１２（および図１１）で
は、サーバアラートメッセージを始めとして同図に示す
メッセージをすべて含んでいる。

【００２０】実際に、大量のメッセージが一時に送り付
けられる被害は、インターネットの人気ホームページや
検索ページなどでも過去に発生している。

【００２１】こうした事態を防ぐため、一般的には、受
信を拒否する送り主を規定したブラックリストや、受信
を許容する送り主のみを規定したホワイトリストを設定
して、ブラックリストに載る送り主からのメッセージを
破棄したり、ホワイトリストに載る送り主以外のメッセ
ージを破棄したりすることが行われる。

【００２２】しかし、こうしたリストをユーザが作成す
るには手間がかかり、有効なリストを作成することが困
難である。また、サーバを通じて端末装置のソフトウエ
アなどを設定するシステムでは、メーカ側の都合でサー
バを変更する場合があり、このようなとき、同期メッセ
ージの送り主をホワイトリストで限定すると、受信すべ
きサーバからの同期メッセージが受けられなくなる虞が
ある。また、出没するハッカーをブラックリストで特定
することは事実上難しい。

【００２３】本発明は、かかる点に鑑みてなされたもの
であり、同期メッセージが大量に送られて来た場合で
も、被害に遭わずに済むことができる同期メッセージ処
理方法を提供することを目的とする。

【００２４】

【課題を解決するための手段】本発明の方法は、データ
を受信するステップと、受信したデータが同期メッセー
ジであるか否かを判断するステップと、受信したデータ
が同期メッセージである場合、受信したデータの受信時
刻を記録するステップと、受信時刻の記録結果に基づい
て、前回受信した同期メッセージと今回受信した同期メ
ッセージとの受信間隔を算出するステップと、算出した
受信間隔を閾値と比較するステップと、算出した受信間
隔が閾値以下の場合、今回受信した同期メッセージを破
棄するステップとを有するようにした。

【００２５】この方法によれば、前回受信した同期メッ
セージと今回受信した同期メッセージとの受信間隔が閾
値以下の場合、今回受信した同期メッセージを破棄す
る、つまり、同期メッセージが一定時間以内に複数送ら
れて来たときは、最初のもの以外を破棄するため、同期
メッセージが一度に大量に送り付けられた場合でも、被
害を防ぐことができる。具体的には、例えば、悪意を持
つ第３者から同期メッセージが大量に送られて来た場合
でも、システムがダウンしたり、機能が麻痺したりする
被害を避けることができる。

【００２６】

【発明の実施の形態】以下、本発明の実施の形態につい
て、図面を参照して詳細に説明する。

【００２７】（実施の形態１）図１は、本発明の実施の
形態１に係る同期メッセージ処理方法を適用した端末装
置の構成の一例を示すブロック図である。

【００２８】この端末装置１００は、図１に示すよう
に、ネットワーク２００を介してサーバ３００に接続さ
れている。端末装置１００自体は、データ同期すべきデ
ータを保管し、このデータへのユーザ操作を受け付ける
アプリケーション部１０２と、アプリケーション部１０
２で保管するデータをサーバ３００のデータと同期させ
るための同期メッセージを作成するとともに、サーバ３
００から受信した同期メッセージを解釈する同期処理部
１０４と、同期処理部１０４が作成した同期メッセージ
をネットワーク２００に送信するためにプロトコル処理
を行うとともに、ネットワーク２００から受信した同期
メッセージを同期処理部１０４に渡すためにプロトコル
処理を行うプロトコル処理部１０６とを備えている。ア
プリケーション部１０２の具体例としては、例えば、携
帯電話の電話帳アプリなどを挙げることができる。端末
装置１００とサーバ３００との間では、ＳｙｎｃＭＬに
よるデータ同期処理が行われる。なお、ここで、「同期
メッセージ」とは、前述したように、データ同期の処理
に関係する任意のメッセージをいい、サーバアラートメ
ッセージを始めとして端末装置１００とサーバ３００と
の間でデータ同期の処理に関してやり取りされるすべて
のメッセージを含んでいる。

【００２９】同期処理部１０４は、送信データをＳｙｎ
ｃＭＬのデータフォーマットに変換し、また、逆に、Ｓ
ｙｎｃＭＬフォーマットの受信データを解釈して、アプ
リケーション部１０２で保管するデータのデータ構造に
変換する。

【００３０】プロトコル処理部１０６は、受信データが
同期メッセージである場合、ＳｙｎｃＭＬフォーマット
のデータに戻すまでのプロトコル処理を行い、処理した
データを同期処理部１０４に渡す。ただし、本実施の形
態では、この同期メッセージが、一定時間内に複数受信
した同期メッセージの一つである場合には、その同期メ
ッセージが最初のデータであるときだけ同期処理部１０
４に渡し、それ以外の場合には破棄する。このプロトコ
ル処理部１０６の動作については、後で詳述する。

【００３１】この端末装置１００は、例えば、携帯電話
や携帯端末、パソコンなどであり（図１０参照）、ハー
ドウエア構成として、例えば、図２に示すように、ＣＰ
Ｕ１１０、ＲＯＭ１１２、ＲＡＭ１１４、送受信チップ
１１６、およびタイマ１１８を備えている。ＣＰＵ１１
０は、アプリケーション部１０２、同期処理部１０４、
およびプロトコル処理部１０６の処理を行う。ＲＯＭ１
１２は、ＣＰＵ１１０の動作を規定するプログラムを格
納している。ＲＡＭ１１４は、ＣＰＵ１１０の作業領域
として使用される。送受信チップ１１６は、図１のネッ
トワーク２００を介してデータの送受信を行う。タイマ
１１８は、データの受信時刻を計測する。なお、プログ
ラムの格納媒体は、もちろん、ＲＯＭに限定されるわけ
ではなく、プログラムの格納に適した任意の記録媒体
（例えば、フラッシュメモリなど）を使用することがで
きる。

【００３２】ＣＰＵ１１０が同期処理部１０４やアプリ
ケーション部１０２の処理に要する負荷は、ＣＰＵ１１
０がプロトコル処理部１０６の処理に要する負荷に比べ
てはるかに大きい。そのため、本実施の形態では、ＣＰ
Ｕ１１０の負荷を軽減するため、プロトコル処理部１０
６において、つまり、同期メッセージの解釈を行う前
に、その中身を見ずに、受信した同期メッセージを上位
の階層（同期処理部１０４やアプリケーション部１０
２）に渡すかそれとも破棄するかを決定する。

【００３３】次いで、上記構成を有する端末装置１００
のプロトコル処理部１０６の動作について、図３に示す
フローチャートを用いて説明する。図３は、本実施の形
態に係る同期メッセージ処理方法を実現するためのプロ
トコル処理部１０６の動作を示している。なお、図３に
示すフローチャートは、ＲＯＭ１１２に制御プログラム
として格納されており、ＣＰＵ１１０によって実行され
る。

【００３４】まず、ステップＳ１０００では、サーバ３
００からメッセージ（データ）を受信する。

【００３５】そして、ステップＳ２０００では、ステッ
プＳ１０００で受信したメッセージに対してプロトコル
処理を行い、得られたデータのデータフォーマットか
ら、受信したメッセージが同期メッセージであるか否か
を判断する。この判断の結果として受信したメッセージ
が同期メッセージでない場合（例えば、Ｗｅｂブラウザ
や電子メールのメッセージである場合）は（Ｓ２００
０：ＮＯ）、ステップＳ３０００に進み、受信したメッ
セージが同期メッセージである場合は（Ｓ２０００：Ｙ
ＥＳ）、ステップＳ４０００に進む。

【００３６】ステップＳ３０００では、ステップＳ２０
００でプロトコル処理したメッセージを、上位モジュー
ル（例えば、Ｗｅｂブラウザや電子メールの処理部）に
渡す。

【００３７】一方、ステップＳ４０００では、タイマ１
１８によって計測されたそのメッセージ（同期メッセー
ジ）の受信時刻をＲＡＭ１１４に記録する。

【００３８】そして、ステップＳ５０００では、今回計
測された同期メッセージの受信時刻と、ＲＡＭ１１４に
記録されている前回の同期メッセージの受信時刻との時
間間隔を算出する。

【００３９】そして、ステップＳ６０００では、ステッ
プＳ５０００で算出した時間間隔があらかじめ設定され
た閾値以下であるか否かを判断する。閾値は、例えば、
一例として、プロトコル処理部１０６がサーバアラート
メッセージを受信し、同期処理部１０４がそのメッセー
ジの処理を完了するまでの処理時間に設定される。この
判断の結果として算出した時間間隔が閾値以下である場
合は（Ｓ６０００：ＹＥＳ）、ステップＳ７０００に進
み、算出した時間間隔が閾値よりも大きい場合は（Ｓ６
０００：ＮＯ）、ステップＳ８０００に進む。

【００４０】ステップＳ７０００では、前回の受信から
の時間間隔が閾値以下であるため、つまり、先に受信し
た同期メッセージとの受信時間間隔が一定時間以内であ
るため、今回受信した同期メッセージを破棄する。

【００４１】一方、ステップＳ８０００では、前回の受
信からの時間間隔が閾値よりも大きいため、つまり、先
に受信した同期メッセージとの受信時間間隔が一定時間
を超えるため、今回受信した同期メッセージを上位のモ
ジュールである同期処理部１０４に渡す。

【００４２】なお、同期処理部１０４は、プロトコル処
理部１０６から同期メッセージを受け取ると、その同期
メッセージを解釈する。そして、その同期メッセージの
内容に従って、例えば、図１２に示すデータ同期処理が
進められる。

【００４３】こうした動作は、ＣＰＵ１１０が、ＲＯＭ
１１２に格納された一つの階層の処理を規定するプログ
ラムを読み込み、ＲＡＭ１１４のデータを読み込んで
は、その階層の処理が済んだデータを再びＲＡＭ１１４
に書き込む手順を繰り返す中で行われる。

【００４４】すなわち、ＣＰＵ１１０は、サーバ３００
から送信されたデータが送受信チップ１１６で受信され
てＲＡＭ１１４に格納されると、このデータをＲＡＭ１
１４から読み出し、ヘッダを外して連結し、このデータ
が同期メッセージであるか否かを判断する（なお、これ
らの処理は、ＲＡＭ１１４を仲介させて複数の過程で実
行するようにしてもよい）。そして、このデータが同期
メッセージでないときは（ステップＳ２０００でＮＯの
場合）、それをＲＡＭ１１４に格納する。一方、このデ
ータが同期メッセージであるときは（ステップＳ２００
０でＹＥＳの場合）、ステップＳ４０００およびステッ
プＳ５０００の処理を行い、ステップＳ６０００の判断
を行う。そして、ステップＳ６０００でＹＥＳの場合
は、データをＲＡＭ１１４に戻さずに破棄する。一方、
ステップＳ６０００でＮＯの場合は、データをＲＡＭ１
１４に格納する。

【００４５】データが同期メッセージでない場合、例え
ば、Ｗｅｂブラウザや電子メールのメッセージである場
合、ＣＰＵ１１０は、ＲＡＭ１１４からそのデータを読
み出し、ＲＯＭ１１２から読み込んだ該当プログラムに
従ってその処理を行う。また、ＲＡＭ１１４に格納した
同期メッセージについても、同様に、そのデータをＲＡ
Ｍ１１４から読み出し、ＲＯＭ１１２から読み込んだプ
ログラムに従って同期メッセージを解釈し、データ同期
処理を実行する。

【００４６】仮に、この端末装置１００において、同期
メッセージを大量に受信し、ＣＰＵ１１０が同期メッセ
ージの解釈を次々と処理するにもかかわらず、受信した
同期メッセージがＲＡＭ１１４に溜まり、ＲＡＭ１１４
からオーバーフローするような状態になると、送受信チ
ップ１１６でのデータの受信が不可能になり、システム
ダウンが発生する虞がある。

【００４７】しかし、この端末装置１００では、所定の
時間（閾値）以内の短い間隔で受信した同期メッセージ
については、ＣＰＵ１１０の処理に時間がかかるメッセ
ージ処理を行わずに破棄しているため、同期メッセージ
を大量に受信した場合でも、システムダウンを免れるこ
とができる。

【００４８】なお、その際、破棄した同期メッセージの
中に、本来必要な、同期開始を指示する同期メッセージ
（サーバアラートメッセージ）が含まれていたとして
も、端末装置１００から同期開始要求を送出しない場合
には、サーバ３００から再度、この同期メッセージが送
られて来るため、全く支障がない。この点は、破棄した
場合に再送されないＷｅｂブラウザや電子メールのメッ
セージと大いに異なる点である。

【００４９】このように、本実施の形態によれば、同期
メッセージが一定時間内に複数送られて来たときには、
最初のもの以外を破棄しているため、同期メッセージが
一度に大量に送り付けられた場合でも、被害を防ぐこと
ができる。具体的には、例えば、悪意を持つ第３者から
同期メッセージが大量に送られて来た場合でも、システ
ムがダウンしたり、機能が麻痺したりする被害を避ける
ことができる。

【００５０】（実施の形態２）実施の形態２は、データ
同期処理中にサーバから送られて来るメッセージを誤っ
て破棄しないように構成した場合である。

【００５１】なお、本実施の形態に対応する端末装置の
基本的構成は、図１および図２に示す実施の形態１に対
応する端末装置と同じであるため、その説明を省略す
る。ただし、本実施の形態は、同期処理部１０４が、同
期処理（図１２の（４）参照）中に、それを表す同期処
理中フラグを立てる点で、実施の形態１と相違してい
る。

【００５２】前述したように、サーバ３００が端末装置
１００に対して同期開始を指示するサーバアラートメッ
セージは、端末装置１００が同期開始要求を送出しない
限り、サーバ３００から繰り返し送出される。しかし、
同期処理中にサーバ３００から端末装置１００に送られ
るメッセージについては、再送される保障がない。その
ため、本実施の形態では、同期処理部１０４が、同期処
理中に同期処理中フラグを立て、このフラグが立ってい
るときは、プロトコル処理部１０６が同期メッセージを
破棄しないようにしている。

【００５３】次いで、本実施の形態に対応するプロトコ
ル処理部１０６の動作について、図４に示すフローチャ
ートを用いて説明する。図４は、本実施の形態に係る同
期メッセージ処理方法を実現するためのプロトコル処理
部１０６の動作を示している。なお、図４に示すフロー
チャートは、ＲＯＭ１１２に制御プログラムとして格納
されており、ＣＰＵ１１０によって実行される。

【００５４】本実施の形態では、図４に示すように、ス
テップＳ２１００を図３に示すフローチャートに挿入し
ている。

【００５５】ステップＳ１０００およびステップＳ２０
００は、図３に示すフローチャートの各ステップと同様
であるため、その説明を省略する。ただし、本実施の形
態では、受信したメッセージが同期メッセージである場
合は（Ｓ２０００：ＹＥＳ）、ステップＳ２１００に進
む。

【００５６】そして、ステップＳ２１００では、同期処
理部１０４において同期処理中フラグが立っているか否
かを判断する。この判断の結果として同期処理中フラグ
が立っていない（ＯＦＦ）場合は（Ｓ２１００：ＹＥ
Ｓ）、ステップＳ４０００に進み、同期処理中フラグが
立っている場合は（Ｓ２１００：ＮＯ）、ただちにステ
ップＳ８０００に進む。

【００５７】ステップＳ４０００〜ステップＳ８０００
は、図３に示すフローチャートの各ステップと同様であ
るため、その説明を省略する。ただし、本実施の形態で
は、時間間隔が閾値未満である場合（Ｓ６０００：Ｎ
Ｏ）に加えて、同期処理中フラグが立っている場合（Ｓ
２１００：ＮＯ）に、ステップＳ８０００の処理が行わ
れる。

【００５８】このように、本実施の形態によれば、破棄
する同期メッセージを、サーバから再送されるサーバア
ラートメッセージに特定（限定）することができ、同期
処理を確実に実行することができる。

【００５９】（実施の形態３）実施の形態２は、同期メ
ッセージを破棄するか否かの判断にホワイトリストを利
用する場合である。

【００６０】なお、本実施の形態に対応する端末装置の
基本的構成は、図１および図２に示す実施の形態１に対
応する端末装置と同じであるため、その説明を省略す
る。ただし、本実施の形態では、ＲＡＭ１１４にホワイ
トリストが格納されており、プロトコル処理部１０６
は、同期メッセージを破棄するか否かを判断する際に、
このホワイトリストを参照する点で、実施の形態１と相
違している。

【００６１】次いで、本実施の形態に対応するプロトコ
ル処理部１０６の動作について、図５に示すフローチャ
ートを用いて説明する。図５は、本実施の形態に係る同
期メッセージ処理方法を実現するためのプロトコル処理
部１０６の動作を示している。なお、図５に示すフロー
チャートは、ＲＯＭ１１２に制御プログラムとして格納
されており、ＣＰＵ１１０によって実行される。

【００６２】本実施の形態では、図５に示すように、ス
テップＳ６１００およびステップＳ６２００を図３に示
すフローチャートに挿入している。

【００６３】ステップＳ１０００〜ステップＳ６０００
は、図３に示すフローチャートの各ステップと同様であ
るため、その説明を省略する。ただし、本実施の形態で
は、時間間隔が閾値以下である場合は（Ｓ６０００：Ｙ
ＥＳ）、ステップＳ６１００に進む。

【００６４】そして、ステップＳ６１００では、受信し
た同期メッセージの送信元を確認する。

【００６５】そして、ステップＳ６２００では、ステッ
プＳ６１００で確認した送信元がホワイトリストに載っ
ているか否かを判断する。この判断の結果として送信元
がホワイトリストに載っていない場合は（Ｓ６２００：
ＮＯ）、ステップＳ７０００に進み、送信元がホワイト
リストに載っている場合は（Ｓ６２００：ＹＥＳ）、ス
テップＳ８０００に進む。

【００６６】ステップＳ７０００では、同期メッセージ
の受信間隔が閾値以内であり、かつ、送信元がホワイト
リストにないため、今回受信した同期メッセージを破棄
する。

【００６７】一方、ステップＳ８０００では、同期メッ
セージの受信間隔が閾値を超えており、または、送信元
がホワイトリストに載っているため、今回受信した同期
メッセージを上位のモジュールである同期処理部１０４
に渡す。

【００６８】このように、本実施の形態によれば、ホワ
イトリストに載っている送信元から送られて来た同期メ
ッセージの破棄を回避することができる。しかも、この
場合におけるホワイトリストの利用の仕方は、従来のよ
うにメッセージの送り主をホワイトリストに載っている
送信元に限定するものではないため、例えば、端末装置
のソフトウエアなどを設定するサーバがメーカ側の都合
で変更された場合でも、変更先のサーバからのメッセー
ジを受け取ることが可能である。

【００６９】なお、追加の機能として、ホワイトリスト
には、正常に同期処理が行われた送信元を自動的に追加
することができる。この場合、例えば、Ｗｅｂブラウザ
や電子メールのメッセージについては、その内容をユー
ザが判断して、送信元をホワイトリストに載せるべきか
否かを決める必要があるが、同期メッセージについて
は、同期処理が正常に終了したか否かを機械的に判定
し、正常に終了した場合、その送信元をホワイトリスト
に載せることにより、ホワイトリストの自動生成が可能
である。

【００７０】（実施の形態４）実施の形態４は、同期メ
ッセージを破棄するか否かを判断するための閾値の設定
（変更）にホワイトリストを利用する場合である。

【００７１】なお、本実施の形態に対応する端末装置の
基本的構成は、図１および図２に示す実施の形態１に対
応する端末装置と同じであるため、その説明を省略す
る。ただし、本実施の形態では、ＲＡＭ１１４にホワイ
トリストが格納されており、プロトコル処理部１０６
は、同期メッセージを破棄するか否かを判断するための
閾値を決めるために、このホワイトリストを利用する点
で、実施の形態１と相違している。

【００７２】次いで、本実施の形態に対応するプロトコ
ル処理部１０６の動作について、図６に示すフローチャ
ートを用いて説明する。図６は、本実施の形態に係る同
期メッセージ処理方法を実現するためのプロトコル処理
部１０６の動作を示している。なお、図６に示すフロー
チャートは、ＲＯＭ１１２に制御プログラムとして格納
されており、ＣＰＵ１１０によって実行される。

【００７３】本実施の形態では、図６に示すように、ス
テップＳ５１００、ステップＳ５２００、ステップＳ５
３００、およびステップＳ５４００を図３に示すフロー
チャートに挿入している。

【００７４】ステップＳ１０００〜ステップＳ５０００
は、図３に示すフローチャートの各ステップと同様であ
るため、その説明を省略する。

【００７５】そして、ステップＳ５１００では、受信し
た同期メッセージの送信元を確認する。

【００７６】そして、ステップＳ５２００では、ステッ
プＳ５１００で確認した送信元がホワイトリストに載っ
ているか否かを判断する。この判断の結果として送信元
がホワイトリストに載っていない場合は（Ｓ５２００：
ＮＯ）、ステップＳ５３００に進み、送信元がホワイト
リストに載っている場合は（Ｓ５２００：ＹＥＳ）、ス
テップＳ５４００に進む。

【００７７】ステップＳ５３００では、送信元がホワイ
トリストに載っていないため、閾値を大きい値に設定
し、ステップＳ６０００に進む。具体的には、例えば、
サーバアラートメッセージを受信し、同期処理部１０４
がそのメッセージの処理を完了するまでの処理時間を基
準時間とした場合において、ＣＰＵ１１０に余裕を持た
せたいときに、大きい閾値を設定する。この場合、例え
ば、最悪でもサーバアラートメッセージの処理だけでＣ
ＰＵ１１０の５０％程度までしか占有しないようにする
ためには、閾値を基準時間の２倍に設定する。

【００７８】一方、ステップＳ５４００では、送信元が
ホワイトリストに載っているため、閾値を小さい値に設
定し、ステップＳ６０００に進む。具体的には、例え
ば、ステップＳ５３００で説明した閾値を大きくする場
合とは逆の場合である。また、本実施の形態のようにホ
ワイトリストの送り先の場合において、通常の閾値を基
準値の１０倍に設定して余裕を持たせておき、ホワイト
リストに載っている場合のみ１０分の１（１／１０）に
設定する。

【００７９】ステップＳ６０００〜ステップＳ８０００
は、図３に示すフローチャートの各ステップと同様であ
るため、その説明を省略する。ただし、本実施の形態で
は、ステップＳ５３００またはステップＳ５４００で設
定した閾値を用いてステップＳ６０００の処理を行う。

【００８０】このように、本実施の形態によれば、送信
元がホワイトリストに載っているか否かに応じてメッセ
ージの破棄条件を調整することができる。例えば、送信
元がホワイトリストに載っていない場合は、メッセージ
の破棄条件を破棄する方向に厳しくすることができる。

【００８１】（実施の形態５）実施の形態５は、同期メ
ッセージを破棄するか否かの判断にブラックリストを利
用する場合である。

【００８２】なお、本実施の形態に対応する端末装置の
基本的構成は、図１および図２に示す実施の形態１に対
応する端末装置と同じであるため、その説明を省略す
る。ただし、本実施の形態では、ＲＡＭ１１４にブラッ
クリストが格納されており、プロトコル処理部１０６
は、同期メッセージを破棄するか否かを判断する際に、
このブラックリストを参照する点で、実施の形態１と相
違している。

【００８３】次いで、本実施の形態に対応するプロトコ
ル処理部１０６の動作について、図７に示すフローチャ
ートを用いて説明する。図７は、本実施の形態に係る同
期メッセージ処理方法を実現するためのプロトコル処理
部１０６の動作を示している。なお、図７に示すフロー
チャートは、ＲＯＭ１１２に制御プログラムとして格納
されており、ＣＰＵ１１０によって実行される。

【００８４】本実施の形態では、図７に示すように、ス
テップＳ６１００およびステップＳ６３００を図３に示
すフローチャートに挿入している。なお、図５に示す実
施の形態３の場合と対比すると、ステップＳ６３００を
図５に示すフローチャートに挿入し、ステップＳ６２０
０を削除した構成になっている。

【００８５】ステップＳ１０００〜ステップＳ６０００
は、図３に示すフローチャートの各ステップと同様であ
るため、その説明を省略する。ただし、本実施の形態で
は、時間間隔が閾値以下である場合は（Ｓ６０００：Ｙ
ＥＳ）、ステップＳ６１００に進む。

【００８６】そして、ステップＳ６１００では、受信し
た同期メッセージの送信元を確認する。

【００８７】そして、ステップＳ６３００では、ステッ
プＳ６１００で確認した送信元がブラックリストに載っ
ているか否かを判断する。この判断の結果として送信元
がブラックリストに載っている場合は（Ｓ６３００：Ｙ
ＥＳ）、ステップＳ７０００に進み、送信元がブラック
リストに載っていない場合は（Ｓ６３００：ＮＯ）、ス
テップＳ８０００に進む。

【００８８】ステップＳ７０００では、同期メッセージ
の受信間隔が閾値以内であり、かつ、送信元がブラック
リストに載っているため、今回受信した同期メッセージ
を破棄する。

【００８９】一方、ステップＳ８０００では、同期メッ
セージの受信間隔が閾値を超えており、または、送信元
がブラックリストに載っていないため、今回受信した同
期メッセージを上位のモジュールである同期処理部１０
４に渡す。

【００９０】このように、本実施の形態によれば、同期
メッセージの受信間隔が閾値以下で、かつ、送信元がブ
ラックリストに載っている場合にだけ、同期メッセージ
を破棄することができる。

【００９１】（実施の形態６）実施の形態６は、同期メ
ッセージを破棄するか否かを判断するための閾値の設定
（変更）にブラックリストを利用する場合である。

【００９２】なお、本実施の形態に対応する端末装置の
基本的構成は、図１および図２に示す実施の形態１に対
応する端末装置と同じであるため、その説明を省略す
る。ただし、本実施の形態では、ＲＡＭ１１４にブラッ
クリストが格納されており、プロトコル処理部１０６
は、同期メッセージを破棄するか否かを判断するための
閾値を決めるために、このブラックリストを利用する点
で、実施の形態１と相違している。

【００９３】次いで、本実施の形態に対応するプロトコ
ル処理部１０６の動作について、図８に示すフローチャ
ートを用いて説明する。図８は、本実施の形態に係る同
期メッセージ処理方法を実現するためのプロトコル処理
部１０６の動作を示している。なお、図８に示すフロー
チャートは、ＲＯＭ１１２に制御プログラムとして格納
されており、ＣＰＵ１１０によって実行される。

【００９４】本実施の形態では、図８に示すように、ス
テップＳ５１００、ステップＳ５２５０、ステップＳ５
３００、およびステップＳ５４００を図３に示すフロー
チャートに挿入している。なお、図６に示す実施の形態
４の場合と対比すると、ステップＳ５２５０を図６に示
すフローチャートに挿入し、ステップＳ５２００を削除
した構成になっている。

【００９５】ステップＳ１０００〜ステップＳ５０００
は、図３に示すフローチャートの各ステップと同様であ
るため、その説明を省略する。

【００９６】そして、ステップＳ５１００では、受信し
た同期メッセージの送信元を確認する。

【００９７】そして、ステップＳ５２５０では、ステッ
プＳ５１００で確認した送信元がブラックリストに載っ
ているか否かを判断する。この判断の結果として送信元
がブラックリストに載っている場合は（Ｓ５２５０：Ｙ
ＥＳ）、ステップＳ５３００に進み、送信元がブラック
リストに載っていない場合は（Ｓ５２５０：ＮＯ）、ス
テップＳ５４００に進む。

【００９８】ステップＳ５３００では、送信元がブラッ
クリストに載っているため、閾値を大きい値に設定し、
ステップＳ６０００に進む。具体的には、例えば、サー
バアラートメッセージを受信し、同期処理部１０４がそ
のメッセージの処理を完了するまでの処理時間を基準時
間とした場合において、ＣＰＵ１１０に余裕を持たせた
いときに、大きい閾値を設定する。この場合、例えば、
最悪でもサーバアラートメッセージの処理だけでＣＰＵ
１１０の５０％程度までしか占有しないようにするため
には、閾値を基準時間の２倍に設定する。また、他の例
として、送信元がブラックリストに載っている場合に優
先的に破棄するときに、大きい閾値を設定する。この場
合、例えば、ブラックリストに載っている送信元からの
メッセージの処理を最悪でもＣＰＵ１１０の１０％程度
の占有に抑えるためには、ブラックリストに載っている
送信元用の閾値を基準時間の１０倍に設定する。

【００９９】一方、ステップＳ５４００では、送信元が
ブラックリストに載っていないため、閾値を小さい値に
設定し、ステップＳ６０００に進む。具体的には、例え
ば、ステップＳ５３００で説明した閾値を大きくする場
合とは逆の場合である。

【０１００】ステップＳ６０００〜ステップＳ８０００
は、図３に示すフローチャートの各ステップと同様であ
るため、その説明を省略する。ただし、本実施の形態で
は、ステップＳ５３００またはステップＳ５４００で設
定した閾値を用いてステップＳ６０００の処理を行う。

【０１０１】このように、本実施の形態によれば、送信
元がブラックリストに載っているか否かに応じてメッセ
ージの破棄条件を調整することができる。例えば、送信
元がブラックリストに載っている場合は、メッセージの
破棄条件を破棄する方向に厳しくすることができる。

【０１０２】（実施の形態７）実施の形態７は、ブラッ
クリストを自動生成する場合である。

【０１０３】なお、本実施の形態に対応する端末装置の
基本的構成は、図１および図２に示す実施の形態１に対
応する端末装置と同じであるため、その説明を省略す
る。ただし、本実施の形態では、ＲＡＭ１１４にブラッ
クリストが格納されており、プロトコル処理部１０６
は、同期メッセージを破棄するか否かを判断する際に、
このブラックリストを参照し、また、同一送信元が同期
メッセージを短時間に連続して送り付けて来た場合に、
この送信元をブラックリストに追加する処理を行う点
で、実施の形態１と相違している。

【０１０４】次いで、本実施の形態に対応するプロトコ
ル処理部１０６の動作について、図９に示すフローチャ
ートを用いて説明する。図９は、本実施の形態に係る同
期メッセージ処理方法を実現するためのプロトコル処理
部１０６の動作を示している。なお、図９に示すフロー
チャートは、ＲＯＭ１１２に制御プログラムとして格納
されており、ＣＰＵ１１０によって実行される。

【０１０５】本実施の形態では、図９に示すように、ス
テップＳ６１００、ステップＳ６１２０、ステップＳ６
１４０、ステップＳ６１６０、およびステップＳ６３０
０を図３に示すフローチャートに挿入している。なお、
図７に示す実施の形態５の場合と対比すると、ステップ
Ｓ６１２０、ステップＳ６１４０、およびステップＳ６
１６０を図７に示すフローチャートに挿入した構成にな
っている。

【０１０６】ステップＳ１０００〜ステップＳ６０００
は、図３に示すフローチャートの各ステップと同様であ
るため、その説明を省略する。ただし、本実施の形態で
は、時間間隔が閾値以下である場合は（Ｓ６０００：Ｙ
ＥＳ）、ステップＳ６１００に進む。

【０１０７】そして、ステップＳ６１００では、受信し
た同期メッセージの送信元を確認する。

【０１０８】そして、ステップＳ６１２０では、ステッ
プＳ６１００で確認した送信元を、例えば、ＲＡＭ１１
４に記録する。

【０１０９】そして、ステップＳ６１４０では、送信元
の記録を見て、同じ送信元から連続して同期メッセージ
が送られているか否かを判断する。この判断の結果とし
て同じ送信元から連続して同期メッセージが送られてい
る場合は（Ｓ６１４０：ＹＥＳ）、ステップＳ６１６０
に進み、同じ送信元から連続して同期メッセージが送ら
れていない場合は（Ｓ６１４０：ＮＯ）、ステップＳ６
３００に進む。

【０１１０】ステップＳ６１６０では、同じ送信元から
連続して同期メッセージが送られているため、その送信
元をブラックリストに追加し、ステップＳ６３００に進
む。

【０１１１】そして、ステップＳ６３００では、ステッ
プＳ６１００で確認した送信元がブラックリスト（ステ
ップＳ６１６０での追加分を含む）に載っているか否か
を判断する。この判断の結果として送信元がブラックリ
ストに載っている場合は（Ｓ６３００：ＹＥＳ）、ステ
ップＳ７０００に進み、送信元がブラックリストに載っ
ていない場合は（Ｓ６３００：ＮＯ）、ステップＳ８０
００に進む。

【０１１２】ステップＳ７０００では、同期メッセージ
の受信間隔が閾値以内であり、かつ、送信元がブラック
リストに載っているため、今回受信した同期メッセージ
を破棄する。

【０１１３】一方、ステップＳ８０００では、同期メッ
セージの受信間隔が閾値を超えており、または、送信元
がブラックリストに載っていないため、今回受信した同
期メッセージを上位のモジュールである同期処理部１０
４に渡す。

【０１１４】このように、本実施の形態によれば、同期
メッセージの受信間隔が閾値以下で、かつ、送信元がブ
ラックリストに載っている場合にだけ、同期メッセージ
を破棄することができるとともに、ブラックリストを機
械的に自動生成することができる。

【０１１５】なお、本発明は、上記各実施の形態に限定
されるわけではなく、請求の範囲内において様々変更可
能である。例えば、上記各実施の形態の特徴は、適宜、
任意に組み合わせることができる。

【０１１６】

【発明の効果】以上説明したように、本発明によれば、
悪意を持つ第３者から同期メッセージが大量に送られて
来た場合でも、システムがダウンしたり、機能が麻痺し
たりする被害を避けることができる。

【図面の簡単な説明】

【図１】本発明の実施の形態１に係る同期メッセージ処
理方法を適用した端末装置の構成の一例を示すブロック
図

【図２】図１に示す端末装置のハードウエア構成の一例
を示すブロック図

【図３】実施の形態１に係る同期メッセージ処理方法を
実現するための、図１に示す端末装置のプロトコル処理
部の動作を示すフローチャート

【図４】本発明の実施の形態２に係る同期メッセージ処
理方法を実現するための、図１に示す端末装置のプロト
コル処理部の動作を示すフローチャート

【図５】本発明の実施の形態３に係る同期メッセージ処
理方法を実現するための、図１に示す端末装置のプロト
コル処理部の動作を示すフローチャート

【図６】本発明の実施の形態４に係る同期メッセージ処
理方法を実現するための、図１に示す端末装置のプロト
コル処理部の動作を示すフローチャート

【図７】本発明の実施の形態５に係る同期メッセージ処
理方法を実現するための、図１に示す端末装置のプロト
コル処理部の動作を示すフローチャート

【図８】本発明の実施の形態６に係る同期メッセージ処
理方法を実現するための、図１に示す端末装置のプロト
コル処理部の動作を示すフローチャート

【図９】本発明の実施の形態７に係る同期メッセージ処
理方法を実現するための、図１に示す端末装置のプロト
コル処理部の動作を示すフローチャート

【図１０】データ同期を実施するシステムの一例を示す
図

【図１１】図１０に示すシステムにおけるデータ同期処
理シーケンスの一例を示す図

【図１２】ＳｙｎｃＭＬでのデータ同期処理シーケンス
の一例を示す図

【図１３】ＳｙｎｃＭＬでのプロトコル処理の一例を説
明するための概念図

【符号の説明】

１００端末装置１０２アプリケーション部１０４同期処理部１０６プロトコル処理部１１０ＣＰＵ１１２ＲＯＭ１１４ＲＡＭ１１６送受信チップ１１８タイマ２００ネットワーク３００サーバ

Claims

【特許請求の範囲】

【請求項１】データを受信するステップと、受信したデータが同期メッセージであるか否かを判断す
るステップと、受信したデータが同期メッセージである場合、受信した
データの受信時刻を記録するステップと、受信時刻の記録結果に基づいて、前回受信した同期メッ
セージと今回受信した同期メッセージとの受信間隔を算
出するステップと、算出した受信間隔を閾値と比較するステップと、算出した受信間隔が閾値以下の場合、今回受信した同期
メッセージを破棄するステップと、を有する同期メッセージ処理方法。
【請求項２】前記破棄ステップは、受信したデータの
解釈を行う前に実行される請求項１記載の同期メッセー
ジ処理方法。
【請求項３】前記破棄ステップは、受信した同期メッ
セージについて、算出した受信間隔が閾値以下の場合は
すべて破棄する請求項１記載の同期メッセージ処理方
法。
【請求項４】データ同期処理中か否かを判断するステ
ップ、をさらに有し、前記破棄ステップは、データ同期処理中の場合は、同期メッセージの破棄を行
わない、請求項１記載の同期メッセージ処理方法。
【請求項５】受信した同期メッセージの送信元を確認
するステップと、受信した同期メッセージの送信元がホワイトリストに載
っているか否かを判断するステップと、をさらに有し、前記破棄ステップは、算出した受信間隔が閾値以下の場合で、かつ、受信した
同期メッセージの送信元がホワイトリストに載っていな
い場合に、今回受信した同期メッセージを破棄する、請求項１記載の同期メッセージ処理方法。
【請求項６】受信した同期メッセージの送信元を確認
するステップと、受信した同期メッセージの送信元がホワイトリストに載
っているか否かを判断するステップと、受信した同期メッセージの送信元がホワイトリストに載
っているか否かに応じて、前記比較ステップで用いる閾
値を設定するステップと、をさらに有し、前記比較ステップは、算出した受信間隔を前記設定ステップで設定した閾値と
比較する、請求項１記載の同期メッセージ処理方法。
【請求項７】受信した同期メッセージに基づいてデー
タ同期処理が正常に終了したか否かを判断するステップ
と、受信した同期メッセージに基づいてデータ同期処理が正
常に終了した場合、当該同期メッセージの送信元をホワ
イトリストに追加するステップと、をさらに有する請求項５または請求項６記載の同期メッ
セージ処理方法。
【請求項８】受信した同期メッセージの送信元を確認
するステップと、受信した同期メッセージの送信元がブラックリストに載
っているか否かを判断するステップと、をさらに有し、前記破棄ステップは、算出した受信間隔が閾値以下の場合で、かつ、受信した
同期メッセージの送信元がブラックリストに載っている
場合に、今回受信した同期メッセージを破棄する、請求項１記載の同期メッセージ処理方法。
【請求項９】受信した同期メッセージの送信元を確認
するステップと、受信した同期メッセージの送信元がブラックリストに載
っているか否かを判断するステップと、受信した同期メッセージの送信元がブラックリストに載
っているか否かに応じて、前記比較ステップで用いる閾
値を設定するステップと、をさらに有し、前記比較ステップは、算出した受信間隔を前記設定ステップで設定した閾値と
比較する、請求項１記載の同期メッセージ処理方法。
【請求項１０】算出した受信間隔が閾値以下の場合、
今回受信した同期メッセージの送信元を確認するステッ
プと、算出した受信間隔が閾値以下の場合、今回受信した同期
メッセージの送信元を記録するステップと、送信元の記録結果に基づいて、算出した受信間隔がいず
れも閾値以下である前回受信した同期メッセージの送信
元と今回受信した同期メッセージの送信元とが同一であ
るか否かを判断するステップと、算出した受信間隔がいずれも閾値以下である前回受信し
た同期メッセージの送信元と今回受信した同期メッセー
ジの送信元とが同一である場合、当該同期メッセージの
送信元をブラックリストに追加するステップと、をさらに有する請求項８または請求項９記載の同期メッ
セージ処理方法。
【請求項１１】データを受信する受信手段と、受信されたデータが同期メッセージであるか否かを判断
する判断手段と、受信されたデータが同期メッセージであると判断された
場合、受信されたデータの受信時刻を記録する記録手段
と、前記記録手段の記録結果に基づいて、前回受信された同
期メッセージと今回受信された同期メッセージとの受信
間隔を算出する算出手段と、算出された受信間隔を閾値と比較する比較手段と、算出された受信間隔が閾値以下の場合、今回受信された
同期メッセージを破棄する破棄手段と、を有する同期メッセージ処理装置。
【請求項１２】データを受信するステップと、受信したデータが同期メッセージであるか否かを判断す
るステップと、受信したデータが同期メッセージである場合、受信した
データの受信時刻を記録するステップと、受信時刻の記録結果に基づいて、前回受信した同期メッ
セージと今回受信した同期メッセージとの受信間隔を算
出するステップと、算出した受信間隔を閾値と比較するステップと、算出した受信間隔が閾値以下の場合、今回受信した同期
メッセージを破棄するステップと、をコンピュータに実行させるための同期メッセージ処理
プログラム。