JP2015041146A - サーバ装置、クライアント装置、システム、情報処理方法及びプログラム - Google Patents

Abstract

【課題】同期処理中断時であっても他のデバイスが最新のデータを早期に利用できるようにしつつ、不用意な更新処理を防ぐことを目的とする。
【解決手段】第１のクライアント装置より同期対象データを特定する特定情報を受信する受信手段と、受信手段により受信された特定情報に基づいて、同期対象データを特定する特定手段と、特定手段により特定された同期対象データの更新データを第１のクライアント装置より受信し、同期対象データを更新データで更新することで第１のクライアント装置とデータを同期する同期手段と、同期手段における第１のクライアント装置との同期対象データの同期が中断された場合、同期対象データの内、未同期データの状態をしかかり中であることを示す状態として確定する確定手段と、未同期データの状態を含む同期対象データを、第２のクライアント装置に送信する送信手段と、を有する。
【選択図】図８

Description

本発明は、サーバ装置、クライアント装置、システム、情報処理方法及びプログラムに関する。

複数のコンピュータ間でデータの同期を取ることが一般的になっている。例えば、タブレット端末やカメラ、複合機に代表されるデバイスに記録されているスケジュールや写真、アドレス帳、設定値情報等のデータをサーバに同期することにより、複数のデバイスの間でのデータ共有が実現されている。これらのデータは、通常データベースに格納されて管理されている。また、複数のデータ間に依存関係があることも多いため、これらのデータの更新及びサーバへの同期は、不可分な一連の処理として実行される。通常、通信断等によって同期処理が途中で失敗した場合には、同期処理全体として失敗とみなされ、更新内容は破棄される。

特許文献１においては、サーバのシステムダウンによってデバイスとサーバとの間の同期処理が一時的に中断した場合にもトランザクションを継続し、サーバの復帰後にトランザクションの再開を行う方式が開示されている。本文献に係る技術では、サーバの復帰後に、同期対象の各デバイスについてトランザクションの成否を判断し、トランザクションの失敗した対象のデバイスに処理を継続するか否か確認する。そして、処理継続要求が有れば、未処理のトランザクションを遂行し、処理継続要求がなければ、未処理のトランザクションを破棄するものである。
また、特許文献２においては、デバイスがサーバのデータベースに更新処理要求を発行する際に、データベース更新処理情報に加えてデータベースの更新処理に失敗した場合のトランザクション処理方式を付加する方式が開示されている。本文献に係る技術によれば、トランザクション処理方式として、トランザクションの破棄以外に、トランザクションの継続及び更新済みデータのみでのトランザクションの確定を選択することができる。

特開平４−４４４５号公報 特開平８−１１５２４３号公報

同期処理が途中で中断された場合に、更新内容を破棄してしまうと、同期再開後に同期元から同じデータを再送しなくてはならない。通信断が多く発生するような状況において、同期のために何度も同じデータを再送するのはオーバーヘッドが大きい。また、特許文献１のようにトランザクションが中断されたときに、トランザクション処理中のデータを保管しておき、通信再開後に継続または破棄を行うこともできるが、この場合、他のデバイスからは最新のデータを利用できない状態が続くという課題がある。
一方、特許文献２のように同期途中でデータを確定してしまうと、未同期状態のデータがあるということを知らない他のデバイスがデータを更に更新してしまうという問題が起きる。この場合、元のデバイスとの同期再開時によって未同期データが反映されたときに、その更新内容が失われてしまう可能性がある。これを回避するためには、トランザクションログの解析等が必要であり、同期処理が複雑になるという課題がある。

本発明は、同期処理中断時であっても他のデバイスが最新のデータを早期に利用できるようにしつつ、不用意な更新処理を防ぐことを目的とする。

そこで、本発明のサーバ装置は、第１のクライアント装置より同期対象データを特定する特定情報を受信する受信手段と、前記受信手段により受信された前記特定情報に基づいて、同期対象データを特定する特定手段と、前記特定手段により特定された同期対象データの更新データを前記第１のクライアント装置より受信し、前記同期対象データを前記更新データで更新することで前記第１のクライアント装置とデータを同期する同期手段と、前記同期手段における前記第１のクライアント装置との同期対象データの同期が中断された場合、前記同期対象データの内、未同期データの状態をしかかり中であることを示す状態として確定する確定手段と、前記未同期データの状態を含む前記同期対象データを、第２のクライアント装置に送信する送信手段と、を有する。

本発明によれば、同期処理中断時であっても他のデバイスが最新のデータを早期に利用できるようにしつつ、不用意な更新処理を防ぐことができる。

データ同期システムのシステム構成の概略図である。 データ同期システムを構成する装置のハードウェア構成及びモジュール構成の一例を示す図である。 データの形式の一例を示した図である。 従来手法によって同期する例を示す図である。 本実施形態の手法によって同期する例を示す図である。 ステータス情報の保持方式のバリエーションを示した図である。 デバイスにおける情報処理の一例を示すフローチャートである。 同期サーバにおける情報処理の一例を示すフローチャートである。 デバイスにおける同期サーバとの通信再開時の情報処理の一例を示すフローチャートである。 データ同期システムを構成する装置のモジュール構成の一例を示す図である。 同期サーバにおける情報処理の一例を示すフローチャートである。 ステップＳ１１０１の処理の一例を示したフローチャートである。

以下、本発明の実施形態について図面に基づいて説明する。

（第１の実施形態）
図１は、データ同期システムのシステム構成の概略図である。本実施形態のデータ同期システムは、同期サーバ１０１と複数のデバイス１０２及びデバイス１０３とで構成されている。同期サーバ１０１とデバイス１０２及びデバイス１０３とは、インターネットやイントラネット経由で通信することができる。同期サーバ１０１内には、マスタデータベース１０４が、デバイス１０２内には、ローカルデータベース１０５がそれぞれ格納されている。マスタデータベース１０４とローカルデータベース１０５内のデータは同期されており、一方のデータベースへの更新はリアルタイムに他方のデータベースへ反映される。
本実施形態では、マスタデータベース１０４及びローカルデータベース１０５内に格納するデータとして、複数ユーザで共有するスケジュールデータを用いる。各ユーザのスケジュールデータは、マスタデータベース１０４上に集約されており、事前に設定されたグループ内のユーザが共有可能である。各ユーザが保持するデバイス１０２上のローカルデータベース１０５は、マスタデータベース１０４と同期しており、ネットワークにつながらない環境であっても、スケジュールを参照及び更新することができる。
デバイス１０２やデバイス１０３は、第１のクライアント装置や第２のクライアントう装置の一例である。

図２の（Ａ）は、データ同期システムを構成する装置のハードウェア構成の一例を示す図である。図１記載の同期サーバ１０１とデバイス１０２とのハードウェア構成を示している。デバイス１０２とデバイス１０３との内部構成は同一であるため、記載を省略する。
同期先の機器である同期サーバ１０１は、１つ或いは複数のＰＣ（コンピュータ）から構成される。ＣＰＵ２０１は、ＲＯＭ２０２に格納されているプログラムを実行することにより、同期サーバ１０１の制御を行う。同期サーバ１０１のＣＰＵ２０１がプログラムを実行することにより、同期サーバ１０１のモジュール構成及び同期サーバ１０１に係るフローチャートの処理が実現される。ＲＡＭ２０３は、各構成要素からの各種データを一時記憶する。また、ＲＡＭ２０３は、ＣＰＵ２０１の制御に基づきプログラムを展開し、同期サーバ１０１が実行可能な状態にする。記憶装置２０４は、本実施形態の処理対象となるデータを保持している。例えば、記憶装置２０４は、同期対象となるデータそのものや、その管理情報をマスタデータベース１０４に格納して保持することができる。記憶装置２０４としては、フラッシュメモリ、ＨＤＤ等を用いることができる。同期サーバ１０１は、通信部２０５を介して、デバイス１０２と通信することができる。

同期元の機器であるデバイス１０２は、タブレット端末、携帯電話端末、デジタルカメラ、プリンタ複合機等である。ＣＰＵ２０６は、ＲＯＭ２０７に格納されているプログラムを実行することにより、デバイス１０２の制御を行う。ＲＡＭ２０８は、各構成要素からの各種データを一時記憶する。また、ＲＡＭ２０８は、ＣＰＵ２０６の制御に基づきプログラムを展開し、デバイス１０２が実行可能な状態にする。入力部２０９は、操作ボタン、タッチパネル等で構成され、ユーザからの指示を受け付ける。表示部２１０は、液晶パネル等で構成され、本実施形態の処理対象となるデータを表示する。記憶装置２１１は、本実施形態の処理対象となるデータを保持している。例えば、同期対象となるデータそのものや、その管理情報をローカルデータベース１０５に格納して保持することができる。また、デバイス１０２は、通信部２１２を介して、同期サーバ１０１と通信することができる。
なお、本実施形態では後述するフローチャートの各ステップに対応する処理を、ＣＰＵ２０１又はＣＰＵ２０６はプログラムに基づき実行するものとして説明を行うが、その処理の一部又は全部を電子回路等のハードウェアで実現するようにしてもよい。即ち、以下に示す図２の（Ｂ）のモジュール構成（ソフトウェア構成）の一部又は全部を電子回路等のハードウェアで実現するようにしてもよい。
図２の（Ｂ）は、データ同期システムを構成する装置のモジュール構成の一例を示す図である。各モジュール（処理部）に関する説明は、後述のフローチャートを用いて説明を行う。

図３は、本システムにおいて扱うデータの形式の一例を示した図である。
テーブル３０１は、５つのカラムから構成されており、ユーザのスケジュールデータを格納している。５つのカラムはそれぞれ、スケジュールの識別情報であるＩＤ（ｉｄ）３０２、タイトル（ｔｉｔｌｅ）３０３、開始日時（ｓｔａｒｔ）３０４、終了日時（ｅｎｄ）３０５、スケジュールの所有者（ｏｗｎｅｒ）３０６を管理するものである。

図４の（Ａ）では、図３のデータを同期サーバ１０１とデバイス１０２及びデバイス１０３との間で、従来手法によって同期する例を示している。ここでは、デバイス１０２及びデバイス１０３と同期サーバ１０１とがネットワークを介してデータの同期を行っている。同期対象のテーブルは、それぞれ、テーブル４０１、テーブル４０２、テーブル４０３である。テーブル４０１及びテーブル４０２は、それぞれデバイス１０２及びデバイス１０３が保持するローカルデータベース１０５内に格納されている。テーブル４０３はマスタデータベース１０４に格納されている。ユーザが何れかのデータベースに対して更新処理を行う前の状態においては、これら３テーブルには全て同一のデータが格納された状態となっている。
ここで、デバイス１０２が自身の保持するテーブル４０１に対して更新を行い、レコード群４０４を１つのトランザクションとして更新したとする。例えば、定例会議の開催時間帯の一括変更等の操作がこれに相当する。この更新内容は、ネットワークを介して同期サーバ１０１内のテーブル４０３へ、同じく１つのトランザクションとして同期される。

この同期途中にネットワークの通信断が発生した場合には、１トランザクション内で同期済みデータと未同期データとが生じることになる。この例では、レコード群４０５は同期済みデータであり、レコード４０６は同期予定であったが未同期状態のデータである。
デバイス１０２は、通信再開時に備え、レコード４０６に相当するデータが未同期であることを、未同期データログ４０８に記憶しておく。レコード４０６は、同期が予定されているが、通信断等の理由によって同期できていない状態であるため、「しかかり中データ」となる。ここで、１トランザクションとして同期が予定されているが、トランザクション途中で同期処理が中断されたことによって未同期である状態を「しかかり中状態」と定義し、「しかかり中状態」であるデータを「しかかり中データ」と表現する。
従来手法では、しかかり中データを無視してトランザクションを確定することが可能である。従来手法により、しかかり中データであるレコード４０６を無視して、トランザクションを確定し、同期済みデータのレコード群４０５の更新のみを確定させたとする。同期サーバ１０１のトランザクションが確定されると、更新内容はデバイス１０３内のテーブル４０２へ同期され、レコード群４０７が更新される。

図４の（Ｂ）は、図４の（Ａ）に示す状態の後に、デバイス１０３がレコード群４０９を更新した場合の同期サーバ１０１内のテーブル４０３の状態を示している。デバイス１０３の更新が、同期サーバ１０１に同期された状態となっている。ここでは、デバイス１０３が行った更新は、デバイス１０２が行った更新より新しいため、デバイス１０２の更新内容より優先されるべきものである。
図４の（Ｃ）は、図４の（Ｂ）に示す状態の後に、デバイス１０２と同期サーバ１０１との通信が再開した状態を示している。デバイス１０２は、未同期データログ４０８を参照し、未同期データであるレコード４１０を同期サーバ１０１へ再送信する。この場合、デバイス１０３が既に対象レコードを新しい値で更新しているにもかかわらず、デバイス１０２が古い値を上書きしてしまうことになる。

図５の（Ａ）は、図３のデータを同期サーバ１０１とデバイス１０２及びデバイス１０３との間で、本実施形態の手法によって同期する例を示している。テーブルの構成は図４の（Ａ）と同一である。
ここで、デバイス１０２が自身の保持するテーブル４０１に対して更新を行い、レコード群４０４を１つのトランザクションとして更新したとする。このとき、同期サーバ１０１は、しかかり中データであるレコード４０６のステータスを「しかかり中」状態に変更した上でトランザクションを確定し、同期済みデータのレコード群４０５の更新を確定させる。この例では、同期サーバ１０１は、しかかり中状態を表すために、「ＷＯＲＫＩＮＧ」フラグをデータに付与している。なお、データのステータスとしては、「しかかり中」状態の他に「通常」状態が存在し、データの更新前のステータスは「通常」状態である。
同期サーバ１０１のトランザクションが確定されると、更新内容はデバイス１０３内のテーブル４０２へ同期され、レコード群４０７が更新されると同時に、レコード５０１のステータスも変更される。このように、同期サーバ１０１が特定のデータがしかかり中ステータスであることを、デバイス１０３に知らせる。このことで、デバイス１０３は、ステータスに応じたデータの扱いを行うことができる。例えば、しかかり中のデータに対しての更新を禁止することもできるし、しかかり中であっても、元のデータの値をそのまま利用したり、値の上書きを許可したりするよう設計することもできる。また、しかかり中データの値を元データの値のままで更新したい場合には、該当データのステータスを「しかかり中」から「通常」に変更することで、データの更新を他のデバイスに対して明確に示すことができる。

図５の（Ｂ）は、図５の（Ａ）に示す状態の後に、デバイス１０３がレコード群４０９を更新した場合の同期サーバ１０１内のテーブル４０３の状態を示している。デバイス１０３の更新が、同期サーバ１０１に同期された状態となっている。デバイス１０３は、「しかかり中」ステータスをもつレコードの値を新しい値で更新しているため、対象レコードの「しかかり中」ステータスは、「通常」状態に戻ることになる。
図５の（Ｃ）は、図５（Ｂ）に示す状態の後に、デバイス１０２と同期サーバ１０１の通信が再開した状態を示している。デバイス１０２は、同期サーバ１０１に問い合わせを行い、しかかり中ステータスのデータを特定する。更に、未同期データログ４０８を参照し、未同期データの内、同期サーバ１０１において、しかかり中ステータスであるデータのみを同期サーバ１０１へ再送信する。この例では、同期サーバ１０１において、しかかり中ステータスであるデータが存在しないため、データの再送信は行われない。
このように、同期途中のデータに対し、しかかり中ステータスを設けることで、他のデバイスが最新のデータを早期に利用できるようにしつつ、対象データが更新可能かを容易に判断でき、不用意な参照や上書きを回避することができる。

図６は、ステータス情報の保持方式のバリエーションを示した図である。
図６の（Ａ）は、データを格納するテーブルに、ステータス情報専用のカラムを追加する方式である。カラム６０１及びカラム６０３は、データを格納するカラムであり、カラム６０２及びカラム６０４は、それぞれカラム６０１及びカラム６０３のステータス情報を記録する。
図６の（Ｂ）は、ステータス情報専用のテーブルを追加する方式である。カラム６０２及びカラム６０４を管理するテーブルを別に設けることで、「しかかり中」状態のレコードのみ情報を記録し、管理データ量を減らすことができる。
図６の（Ｃ）は、データの格納領域の一部にステータスを示すフラグ情報を割り当てることで、ステータス情報を保持する方式である。ここでは、データ実体６０６に対し、フラグ６０５を付与した状態でデータを格納している。この場合、専用のカラムやテーブルの追加が不要であり、処理を単純化することができる。
図６の（Ｄ）は、しかかり中ステータスのレコードを記録する専用ログを用いる構成である。この構成によれば、スキーマの変更を行わずに、「しかかり中」状態のレコードを特定することができ、かつ、しかかり中ステータスのレコードのみ情報を記録するため、管理データ量を減らすことができる。

上述の動作を、フローチャートに従って説明する。
図７は、デバイス１０２やデバイス１０３における情報処理の一例を示すフローチャートである。
ステップＳ７０１で、トランザクション開始部２１３がローカルデータベース１０５に対するトランザクションを開始する。
ステップＳ７０２で、データ更新部２１４がローカルデータベース１０５に対して更新を行う。
ステップＳ７０３で、トランザクション確定部２１５がトランザクションを終了する。
ステップＳ７０２の処理は、更新対象のデータ件数分、繰り返されるものとする。また、ステップＳ７０２では、同期対象記録部２２７が、更新対象のデータを特定するための情報を同時に記録する。

ステップＳ７０４で、同期対象情報送信部２１６が同期対象となるレコードを特定するための情報を同期サーバ１０１へ送信する（特定情報送信）。同期対象を特定するための情報としては、例えば同期対象のレコードのＩＤを用いることができる他、同期対象のカラムを特定する情報や、更新に用いるＳＱＬクエリを用いることができる。
その上で、ステップＳ７０５で、同期データ送信部２１７が同期対象となる更新データを順次、同期サーバ１０１へ送信する。ステップＳ７０５は、通信断によって処理が中断されるか、全てのデータの送信が完了した時点で処理を終える。
ステップＳ７０６では、同期データ送信部２１７がデータ送信中に通信断が発生したか否かを判定する。同期データ送信部２１７は、例えば、同期サーバ１０１から、一定時間応答がなかった場合に、通信断とみなすことができる。ステップＳ７０６において、同期データ送信部２１７は、通信断が発生したと判定された場合（Ｓ７０６においてＹｅｓ）、ステップＳ７０７へ進む。一方、通信断が発生しなかった場合（Ｓ７０６においてＮｏ）、同期データ送信部２１７は、図７に示すフローチャートに係る処理を終了する。
ステップＳ７０７では、未同期データ記録部２１８が通信断発生により同期サーバ１０１へ送信できていないデータを特定する情報を記録する。ステップＳ７０７の処理を終えると、未同期データ記録部２１８は、図７に示すフローチャートに係る処理を終了する。

図８は、同期サーバ１０１における情報処理の一例を示すフローチャートである。
ステップＳ８０１で、同期対象特定部２２１がデバイス１０２から送信された同期対象特定情報を受信する。
ステップＳ８０２で、同期対象特定部２２１が同期対象となるレコードを特定する。ここで、同期対象特定部２２１は、ステップＳ８０１で受信した同期対象特定情報が、同期対象のレコードのＩＤである場合には、そのまま同期サーバ１０１内の同期対象のレコードを特定する情報として利用することができる。また、同期対象特定情報が、同期対象のカラムを特定する情報、更新に用いるＳＱＬクエリ等である場合、同期対象特定部２２１は、同期対象のレコードのＩＤへ変換する処理を行う。
次に、ステップＳ８０３で、トランザクション開始部２２２がマスタデータベース１０４に対するトランザクションを開始する。
その上で、ステップＳ８０４で、ステータス情報付与部２２３が同期対象となるレコードのステータスを「しかかり中」に変更する。

ステップＳ８０５で、データ受信部２２４が同期対象の更新データを順次受信する。
そして、ステップＳ８０６で、データ更新部２２５が受信した同期対象レコードに対する更新を行う。この際、データ更新部２２５は、更新が終了したレコードのステータスを「しかかり中」から「通常」状態に更新する。
ステップＳ８０５及びステップＳ８０６は、全件一括で処理を行ってもよいし、所定の件数ずつ受信・更新処理のセットを繰り返すものであってもよい。
ステップＳ８０７では、データ受信部２２４が同期処理中に通信断が発生したか、或いは同期対象レコードを全件受信し、更新処理が終了したかを判定する。同期対象レコードの更新処理が終了したかは、データ受信部２２４は、ステップＳ８０１で特定した同期対象レコード全件に対して更新が終了したか否かで判断することができる。
ステップＳ８０７において、通信断が発生しておらず、かつ、更新処理が未終了であった場合（Ｓ８０７においてＮｏ）、データ受信部２２４は、ステップＳ８０５へ戻り、同期対象データの受信及び更新処理を繰り返す。一方、ステップＳ８０７において、通信断が発生、或いは更新処理が終了したと判断した場合（Ｓ８０７においてＹｅｓ）、データ受信部２２４は、処理をステップＳ８０８へ進める。

ステップＳ８０８では、トランザクション確定部２２６がマスタデータベース１０４に対するトランザクションを確定する。このとき、通信断によって未同期データが存在していた場合には、未同期データのステータスは「しかかり中」のまま確定する。
最後に、ステップＳ８０９で、同期範囲判定部２２８が他のデバイスに対して、今回の更新内容を送信し、データを同期する。このとき、マスタデータベース１０４内における各レコードのステータス情報も同期される。本同期処理は、デバイス側でトランザクション制御され、１トランザクションとして実行される。各レコードのステータス情報は、他のデバイスによって変更することができる。例えば、「しかかり中」ステータスであっても値の上書きを行って、ステータスを「通常」状態に戻すことも可能である。
本実施形態では、同期対象のレコードのステータス変更をデータ更新前に一括で行う構成としたが、通信断発生を検知した後に、未同期データに対してのみステータスを更新する構成としてもよい。この構成によれば、ステータス変更の回数を少なくすることができる。

また、ステップＳ８０９において、他のデバイスに対して、今回の更新内容を同期する際に、同期範囲判定部２２８が各レコードのステータスに応じた同期処理を行ってもよい。例えば、同期範囲判定部２２８は、しかかり中ステータスであるレコードを含む同期処理において、同期対象のデバイスが予め設定等されたデバイスか否かを判定する。そして、同期範囲判定部２２８は、同期対象のデバイスが予め設定等されたデバイスである場合には、しかかり中ステータスであるレコードを含む同期処理においては前記レコードを反映しないようにすることもできる。この構成によれば、これらのデバイスは、最新のデータを参照できなくなる代わりに、レコードのステータスを意識した設計を行う必要がなくなる。

図９は、デバイスにおける同期サーバ１０１との通信再開時の情報処理の一例を示すフローチャートである。
まず、ステップＳ９０１で、未同期データ記録部２１８がステップＳ７０７で記録した情報を参照し、未同期データを特定する。
ステップＳ９０２で、しかかり中データ判定部２１９が同期サーバ１０１に問い合わせを行い、マスタデータベース１０４内で、しかかり中ステータスとなっているレコードを特定する（しかかり中データ特定）。
ステップＳ９０３で、しかかり中データ判定部２１９が未同期データの内、マスタデータベース１０４内で、しかかり中ステータスとなっているレコードがあるかを判定する。未同期、かつ、しかかり中ステータスのレコードがある場合（Ｓ９０３においてＹｅｓ）、ステップＳ９０４でデータ再送部２２０が該当するレコードを同期サーバ１０１に再送信する。一方、未同期、かつ、しかかり中ステータスのレコードがない場合（Ｓ９０３においてＮｏ）、しかかり中データ判定部２１９は、図９に示す処理を終了する。
なお、本実施形態では、同期トランザクションの中断原因を通信断によるものとしたが、デバイスの電源断や割り込み処理が中断の原因であってもよい。また、本実施形態では、スケジュールデータを同期対象としたが、本実施形態の適用先はこれに限定されるものではない。スケジュールデータの他に、デバイスの設定値情報や、写真や動画等のコンテンツデータを同期対象とすることもできる。

本実施形態の処理によれば、他のデバイスが最新のデータを早期に利用できるようになると共に、未同期データを考慮した処理を容易に実現可能となる。また、デバイス１０２は、自身が同期サーバ１０１へ同期途中であったデータが、通信断発生中に他のデバイス１０３によって上書きされたことを容易に判断でき、通信再開後に自身が保持する古い値でデータを更新してしまうことを回避できる。

（第２の実施形態）
以下、第２の実施形態を説明する。なお、第１の実施形態と同一構成部分についてはその説明を省略する。
第１の実施形態の処理では、同期トランザクションの中断時に、一律で同期済みのデータを確定しつつ、未同期データのステータスを「しかかり中」に変更するものであった。しかし、本実施形態の処理では、条件に応じてトランザクション処理方式を選択可能にする。
図１０は、データ同期システムを構成する装置のモジュール構成の一例を示す図である。本実施形態では、デバイス１０２は、トランザクション処理方式通知部１００１を持ち、同期処理開始前に、同期サーバ１０１に対して、トランザクション処理方式の通知を行う。ここでは、通信断等によって同期トランザクションが途中で失敗した場合の処理方法を事前に定めることができる。例えば、同期済みレコードの割合に応じてトランザクション処理方式を切り替えるよう同期サーバ１０１と取り決めを行うことができる。同期サーバ１０１は、トランザクション処理方式設定部１００２を持ち、デバイス１０２と取り決めたトランザクション処理方式を記憶する。その他の部に関する処理の説明等は、後述のフローチャートを用いて行う。

図１１は、同期サーバ１０１における情報処理の一例を示すフローチャートである。
ステップＳ８０１〜ステップＳ８０９の処理は、第１の実施形態と同一構成である。
本実施形態では、ステップＳ８０７で、データ受信部２２４が、通信断が発生したと判断した場合、ステップＳ１１０１へ進む。
ステップＳ１１０１で、トランザクション終了部１００３が、トランザクション処理方式設定部１００２が記憶した方式に従ってトランザクション処理を行う。トランザクション終了部１００３は、トランザクション確定部２２６及びトランザクション破棄部１００４を保持しており、どちらの部を用いるかを選択することができる。

図１２は、ステップＳ１１０１の処理の一例を示したフローチャートである。
ステップＳ１２０１では、トランザクション終了部１００３は、同期対象のレコードの内、マスタデータベース１０４に対して同期済みのレコードが所定の割合以上であるか否かを判定する。同期対象のレコードの内、マスタデータベース１０４に対して同期済みのレコードが所定の割合以上である場合、ステップＳ１２０２へ進み、トランザクション終了部１００３は、トランザクションを確定する。一方、同期済みのレコードが所定の割合未満であった場合、ステップＳ１２０３へ進み、トランザクション終了部１００３は、トランザクションを破棄する。トランザクションが破棄された場合には、今回の同期処理で変更した、しかかり中ステータス情報も破棄される。

このように、同期済みデータの割合に応じて、トランザクションを確定するか、破棄するかを選択することで、大量のレコードがしかかり中ステータスとなることを防ぐことができる。なお、本実施形態では、同期済みデータの割合に応じて、トランザクション処理方式を選択するものとしたが、同期済みデータの件数に応じて選択するよう構成してもよい。つまり、トランザクション終了部１００３は、同期対象データの内、予め設定された件数以上のデータが同期されているか否かを判定し、判定結果に基づいて、トランザクション処理方式を選択するようにしてもよい。この構成によれば、同期済みデータの割合を算出する必要がなく、処理を単純化することができる。特に、１トランザクションのデータ件数がほぼ一定であり、件数と割合を近似できる環境において有効である。
また、通信の安定度合によって、トランザクション処理方式を選択するよう構成してもよい。この場合、例えば通信断の発生頻度が所定回数以上である場合には、トランザクションを破棄し、所定回数未満である場合には、しかかり中ステータスのままトランザクションを確定することができる。また、通信の安定度合を示す指標として、通信断の発生頻度の他、通信断の平均時間を判断基準に用いてもよい。この構成によれば、通信断の平均時間が長い場合には、通信再開の可能性が低いと判断してトランザクションを破棄し、そうでない場合に未同期データをしかかり中ステータスとして確定することができる。
本実施形態の構成によれば、第１の実施形態で得られる効果に加え、大量のレコードがしかかり中ステータスとなることや、しかかり中ステータスが長時間継続することを防ぐことができる。

（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

以上、上述した各実施形態によれば、同期処理中断時であっても他のデバイスが最新のデータを早期に利用できるようにしつつ、不用意な更新処理を防ぐことができる。また、ネットワークを介して、サーバと複数のデバイスとの間でデータをリアルタイムに同期するシステムにおいて、他のデバイスが最新のデータを早期に利用できるようになると共に、未同期データを考慮した処理を容易に実現することができる。また、「しかかり中データ」を特定する仕組みを持つことによって、他のデバイスが「しかかり中データ」に対して更新を行った場合に容易に検知可能にする。また、他のデバイスが「しかかり中データ」の存在を知ることができ、不用意な更新処理を防ぐこともできる。

以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０１ サーバ、１０２ デバイス、１０３ デバイス

Claims (13)

1. 第１のクライアント装置より同期対象データを特定する特定情報を受信する受信手段と、
   前記受信手段により受信された前記特定情報に基づいて、同期対象データを特定する特定手段と、
   前記特定手段により特定された同期対象データの更新データを前記第１のクライアント装置より受信し、前記同期対象データを前記更新データで更新することで前記第１のクライアント装置とデータを同期する同期手段と、
   前記同期手段における前記第１のクライアント装置との同期対象データの同期が中断された場合、前記同期対象データの内、未同期データの状態をしかかり中であることを示す状態として確定する確定手段と、
   前記未同期データの状態を含む前記同期対象データを、第２のクライアント装置に送信する送信手段と、
   を有するサーバ装置。
2. 前記第１のクライアント装置より同期対象データの同期が中断された場合の処理方法の通知を受け取る受け取り手段を更に有し、
   前記確定手段は、前記処理方法が状態を確定する処理方法であった場合には、前記同期手段における前記第１のクライアント装置との同期対象データの同期が中断された場合、前記同期対象データの内、未同期データの状態をしかかり中であることを示す状態として確定する請求項１記載のサーバ装置。
3. 前記確定手段は、前記同期手段における前記第１のクライアント装置との同期対象データの同期が中断された場合、前記同期対象データの内、予め設定された割合以上のデータが同期されているか否かを判定し、前記同期対象データの内、予め設定された割合以上のデータが同期されている場合、前記未同期データの状態をしかかり中であることを示す状態として確定する請求項１記載のサーバ装置。
4. 前記確定手段は、前記同期手段における前記第１のクライアント装置との同期対象データの同期が中断された場合、前記同期対象データの内、予め設定された件数以上のデータが同期されているか否かを判定し、前記同期対象データの内、予め設定された件数以上のデータが同期されている場合、前記未同期データの状態をしかかり中であることを示す状態として確定する請求項１記載のサーバ装置。
5. 前記確定手段は、前記同期手段における前記第１のクライアント装置との同期対象データの同期が中断された場合、前記第１のクライアント装置との通信の安定度合を示す指標に基づいて、前記未同期データの状態をしかかり中であることを示す状態として確定する否かを判断し、前記指標が予め定めた条件をみたす場合、前記未同期データの状態をしかかり中であることを示す状態として確定する請求項１記載のサーバ装置。
6. 同期対象データを特定する特定情報を、サーバ装置に送信する特定情報送信手段と、
   前記同期対象データの更新データを前記サーバ装置に送信する送信手段と、
   前記送信手段による前記サーバ装置への前記同期対象データの更新データの送信が中断された場合、前記同期対象データの更新データの内、未同期データを識別する識別情報を記録する記録手段と、
   を有するクライアント装置。
7. 前記サーバ装置との通信が再開された場合、前記記録手段により記録された識別情報に基づいて、前記未同期データを特定する特定手段と、
   前記サーバ装置へ問い合わせを行い、前記特定手段で特定された未同期データのうち、しかかり中であることを示す状態のデータを特定するしかかり中データ特定手段と、
   前記しかかり中データ特定手段で特定されたデータを前記サーバ装置へ再送信する再送信手段と、
   を更に有する請求項６記載のクライアント装置。
8. 第１のクライアント装置と、第２のクライアント装置と、サーバ装置と、を含むシステムであって、
   前記サーバ装置は、
   第１のクライアント装置より同期対象データを特定する特定情報を受信する受信手段と、
   前記受信手段により受信された前記特定情報に基づいて、同期対象データを特定する特定手段と、
   前記特定手段により特定された同期対象データの更新データを前記第１のクライアント装置より受信し、前記同期対象データを前記更新データで更新することで前記第１のクライアント装置とデータを同期する同期手段と、
   前記同期手段における前記第１のクライアント装置との同期対象データの同期が中断された場合、前記同期対象データの内、未同期データの状態をしかかり中であることを示す状態として確定する確定手段と、
   前記未同期データの状態を含む前記同期対象データを、第２のクライアント装置に送信する第１の送信手段と、
   を有し、
   前記第１のクライアント装置は、
   同期対象データを特定する特定情報を、サーバ装置に送信する特定情報送信手段と、
   前記同期対象データの更新データを前記サーバ装置に送信する第２の送信手段と、
   前記第２の送信手段による前記サーバ装置への前記同期対象データの更新データの送信が中断された場合、前記同期対象データの更新データの内、未同期データを識別する識別情報を記録する記録手段と、
   を有するシステム。
9. サーバ装置が実行する情報処理方法であって、
   第１のクライアント装置より同期対象データを特定する特定情報を受信する受信ステップと、
   前記受信ステップにより受信された前記特定情報に基づいて、同期対象データを特定する特定ステップと、
   前記特定ステップにより特定された同期対象データの更新データを前記第１のクライアント装置より受信し、前記同期対象データを前記更新データで更新することで前記第１のクライアント装置とデータを同期する同期ステップと、
   前記同期ステップにおける前記第１のクライアント装置との同期対象データの同期が中断された場合、前記同期対象データの内、未同期データの状態をしかかり中であることを示す状態として確定する確定ステップと、
   前記未同期データの状態を含む前記同期対象データを、第２のクライアント装置に送信する送信ステップと、
   を含む情報処理方法。
10. クライアント装置が実行する情報処理方法であって、
    同期対象データを特定する特定情報を、サーバ装置に送信する特定情報送信ステップと、
    前記同期対象データの更新データを前記サーバ装置に送信する送信ステップと、
    前記送信ステップによる前記サーバ装置への前記同期対象データの更新データの送信が中断された場合、前記同期対象データの更新データの内、未同期データを識別する識別情報を記録する記録ステップと、
    を含む情報処理方法。
11. 第１のクライアント装置と、第２のクライアント装置と、サーバ装置と、を含むシステムにおける情報処理方法であって、
    前記第１のクライアント装置が、同期対象データを特定する特定情報を、サーバ装置に送信する特定情報送信ステップと、
    前記サーバ装置が、前記第１のクライアント装置より同期対象データを特定する特定情報を受信する受信ステップと、
    前記サーバ装置が、前記受信ステップにより受信された前記特定情報に基づいて、同期対象データを特定する特定ステップと、
    前記第１のクライアント装置が、前記同期対象データの更新データを前記サーバ装置に送信する第１の送信ステップと、
    前記サーバ装置が、前記特定ステップにより特定された同期対象データの更新データを前記第１のクライアント装置より受信し、前記同期対象データを前記更新データで更新することで前記第１のクライアント装置とデータを同期する同期ステップと、
    前記サーバ装置が、前記同期ステップにおける前記第１のクライアント装置との同期対象データの同期が中断された場合、前記同期対象データの内、未同期データの状態をしかかり中であることを示す状態として確定する確定ステップと、
    前記サーバ装置が、前記未同期データの状態を含む前記同期対象データを、第２のクライアント装置に送信する第２の送信ステップと、
    前記第１のクライアント装置が、前記第１の送信ステップによる前記サーバ装置への前記同期対象データの送信が中断された場合、前記同期対象データの内、未同期データを識別する識別情報を記録する記録ステップと、
    を含む情報処理方法。
12. コンピュータに、
    第１のクライアント装置より同期対象データを特定する特定情報を受信する受信ステップと、
    前記受信ステップにより受信された前記特定情報に基づいて、同期対象データを特定する特定ステップと、
    前記特定ステップにより特定された同期対象データの更新データを前記第１のクライアント装置より受信し、前記同期対象データを前記更新データで更新することで前記第１のクライアント装置とデータを同期する同期ステップと、
    前記同期ステップにおける前記第１のクライアント装置との同期対象データの同期が中断された場合、前記同期対象データの内、未同期データの状態をしかかり中であることを示す状態として確定する確定ステップと、
    前記未同期データの状態を含む前記同期対象データを、第２のクライアント装置に送信する送信ステップと、
    を実行させるためのプログラム。
13. コンピュータに、
    同期対象データを特定する特定情報を、サーバ装置に送信する特定情報送信ステップと、
    前記同期対象データの更新データを前記サーバ装置に送信する送信ステップと、
    前記送信ステップによる前記サーバ装置への前記同期対象データの更新データの送信が中断された場合、前記同期対象データの更新データの内、未同期データを識別する識別情報を記録する記録ステップと、
    を実行させるためのプログラム。

Images