JP2011118771A - 情報処理装置、情報処理方法、データ管理サーバおよびデータ同期システム - Google Patents

Abstract

【課題】サーバ負荷と処理時間を軽減することが可能なデータ同期システムを提供する。
【解決手段】本発明の情報処理装置は、サーバから取得したデータを記憶するデータ記憶部と、サーバで記憶されている、サーバにおけるデータの変更内容を示す変更履歴情報の蓄積状態を確認する確認部と、確認部の確認結果に基づいて、変更履歴情報に従ってデータ記憶部に記憶されているデータをサーバの管理するデータと同期させる第１の取得方法と、サーバに存在するデータを示すデータ存在情報をサーバから取得してデータ記憶部に記憶されているデータを同期させる第２の取得方法とのいずれの取得方法によりデータを取得するかを決定し、サーバからデータを取得するデータ取得処理部と、を備える。
【選択図】図２

Description

本発明は、情報処理装置、情報処理方法、データ管理サーバおよびデータ同期システムに関する。

近年、ネットワーク接続機器の増加と、モバイル端末の普及により、時間や場所を問わずユーザがサーバ上で管理している情報にアクセスすることが可能となった。これに伴い、サーバ上の情報を、ユーザが管理するすべての機器で一貫性を持って利用できることが求められている。このための技術が同期技術である。クライアント／サーバと携帯端末との同期に関しては、例えば、ＯＭＡ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）により仕様が設定された「ＳｙｎｃＭＬ」という標準化されたプロトコルがある。ここでは、クライアントの認証や同期タイプの確認後、サーバとクライアントとの間でのデータのやり取りの流れを規定している。この際、同期するデータを特定するため、自身の変更履歴を記憶しておき、その変更履歴に基づいて相手に送信する必要のある情報を相手へ送信することが考えられている。

例えば、特許文献１には、一度のデータ同期で大量の情報を送受信することのないように、データの更新履歴に基づいて適当なデータ送信量でのデータ同期を自動的に開始するデータ同期システムが開示されている。これにより、通信時間の増大やデータ同期中にエラーが発生する可能性を低減することができ、通信コストの削減やデータ同期プログラムによるクライアント端末の占有を回避することが可能となる。

特開２００４−８６８００号公報

しかし、特許文献１に記載のデータ同期システムでは、クライアント端末がデータ同期開始要求に応じない場合、例えば複数台のクライアント端末のうち一部のクライアント端末の電源が完全にオフとなっている場合等は、履歴数は保存可能な閾値を超えて増加し、同期開始時に送受信される情報量が多大になってしまう。また、この場合、履歴数が増加することでメモリ使用量も増加するため、履歴を保持しているサーバ側の負荷も大きくなる。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、サーバ負荷と処理時間を軽減することが可能な、新規かつ改良された情報処理装置、情報処理方法、データ管理サーバおよびデータ同期システムを提供することにある。

上記課題を解決するために、本発明のある観点によれば、サーバから取得したデータを記憶するデータ記憶部と、サーバで記憶されている、サーバにおけるデータの変更内容を示す変更履歴情報の蓄積状態を確認する確認部と、確認部の確認結果に基づいて、変更履歴情報に従ってデータ記憶部に記憶されているデータをサーバの管理するデータと同期させる第１の取得方法と、サーバに存在するデータを示すデータ存在情報をサーバから取得してデータ記憶部に記憶されているデータを同期させる第２の取得方法とのいずれの取得方法によりデータを取得するかを決定し、サーバからデータを取得するデータ取得処理部と、を備える、情報処理装置が提供される。

ここで、確認部は、サーバで蓄積された変更履歴情報の数が所定の履歴数を超えているかを確認し、データ取得処理部は、サーバで蓄積された変更履歴情報が所定の履歴数以下であるとき、第１の取得方法を用いてデータを取得し、サーバで蓄積された変更履歴情報が所定の履歴数より多いとき、第２の取得方法を用いてデータを取得してもよい。

また、データ記憶部には、当該データ記憶部で保持するデータに関する情報であるクライアントデータ情報が記憶されており、データ取得処理部は、第２の取得方法によりデータを取得するとき、データ存在情報とクライアントデータ情報とを比較して、サーバにて更新されたデータのみをサーバから取得してもよい。

さらに、データ取得処理部は、第２の取得方法によりデータを取得するとき、データ存在情報とクライアントデータ情報とを比較して、情報処理装置にのみ存在するデータを特定し、情報処理装置にのみ存在するデータをデータ記憶部から削除してもよい。

また、データ取得処理部は、クライアントデータ情報に含まれる、情報処理装置にて変更され、かつサーバへ未送信のデータを示す送信状態情報に基づいて、情報処理装置にて変更されたデータに同期してサーバで管理されるデータを更新するための情報を、サーバへ送信してもよい。

さらに、データ取得処理部は、変更履歴情報をデータ単位で集約し、集約された変更履歴情報に基づいて、サーバからデータを取得してもよい。

また、データ取得処理部は、時系列に並んだ変更履歴情報を所定のデータ数で分割し、分割された変更履歴情報ごとにサーバからデータを取得してもよい。

また、上記課題を解決するために、本発明の別の観点によれば、ネットワークを介して接続され、データを管理するサーバで記憶されている、サーバにおけるデータの変更内容を示す変更履歴情報の蓄積状態を確認するステップと、変更履歴情報の蓄積状態の確認結果に基づいて、変更履歴情報に従ってサーバから取得したデータを記憶するデータ記憶部に記憶されているデータをサーバの管理するデータと同期させる第１の取得方法と、サーバに存在するデータを示すデータ存在情報をサーバから取得してデータ記憶部に記憶されているデータを同期させる第２の取得方法とのいずれの取得方法によりデータを取得するかを決定するステップと、決定された取得方法により、サーバからデータを取得するステップと、を含む、情報処理方法が提供される。

さらに、上記課題を解決するために、本発明の別の観点によれば、データを記憶するデータ記憶部と、変更情報に基づいて、データ記憶部に記憶されたデータを変更するデータ変更部と、データ変更部により変更されたデータの変更内容を示す変更履歴情報を記憶するサーバ履歴記憶部と、サーバ履歴記憶部に記憶する変更履歴情報の上限蓄積量を記憶する設定記憶部と、上限蓄積量に基づいてサーバ履歴記憶部に記憶する変更履歴情報の蓄積量を管理する管理部と、ネットワークを介して接続されたクライアントからの要求に応じて、クライアントへ送信するデータまたは変更履歴情報を取得し、データ記憶部に記憶されたデータに基づいてデータ記憶部に存在するデータを示すデータ存在情報を作成する情報処理部と、情報処理部により取得されたデータ、変更履歴情報、または作成されたデータ存在情報をクライアントへ送信するサーバ通信部と、を備える、データ管理サーバが提供される。

管理部は、サーバ履歴記憶部に記憶された変更履歴情報の蓄積量が上限蓄積量を超えたとき、変更履歴情報の蓄積を停止してもよい。

また、管理部は、サーバ履歴記憶部に記憶された変更履歴情報の蓄積量が上限蓄積量を超えたとき、変更履歴情報の蓄積量が上限蓄積量を超えたことを示すオーバーフロー判定情報をデータ履歴記憶部に記録してもよい。

さらに、情報処理部は、データ記憶部よりデータを取得し、サーバ存在情報を作成する第１の処理部と、サーバ履歴記憶部より変更履歴情報を取得する第２の処理部と、を備えてもよい。このとき、サーバ通信部は、クライアントから変更履歴情報の送信要求を受けたとき、第２の処理部にサーバ履歴記憶部から変更履歴情報を取得させる。

また、サーバ履歴記憶部は、ネットワークを介して接続されたクライアントごとに変更履歴情報を記憶してもよい。

さらに、上記課題を解決するために、本発明の別の観点によれば、変更情報に基づいて、データを記憶するデータ記憶部に記憶されたデータを変更するステップと、変更されたデータの変更内容を示す変更履歴情報をサーバ履歴記憶部に記憶するステップと、サーバ履歴記憶部に記憶する変更履歴情報の上限蓄積量に基づいてサーバ履歴記憶部に記憶する変更履歴情報の蓄積量を管理するステップと、ネットワークを介して接続されたクライアントからの要求に応じて、クライアントへ送信するデータまたは変更履歴情報を取得するステップと、クライアントからの要求に応じて、データ記憶部に記憶されたデータに基づいてデータ記憶部に存在するデータを示すデータ存在情報を作成するステップと、取得したデータ、変更履歴情報、または作成したデータ存在情報をクライアントへ送信するステップと、を含む、情報処理方法が提供される。

また、上記課題を解決するために、本発明の別の観点によれば、ネットワークを介して接続されたサーバとクライアントとのデータを同期する、データ同期システムが提供される。サーバは、データを記憶するデータ記憶部と、変更情報に基づいて、データ記憶部に記憶されたデータを変更するデータ変更部と、データ変更部により変更されたデータの変更内容を示す変更履歴情報を記憶するサーバ履歴記憶部と、サーバ履歴記憶部に記憶する変更履歴情報の上限蓄積量を記憶する設定記憶部と、上限蓄積量に基づいてサーバ履歴記憶部に記憶する変更履歴情報の蓄積量を管理する管理部と、ネットワークを介して接続されたクライアントからの要求に応じて、クライアントへ送信するデータまたは変更履歴情報を取得し、データ記憶部に記憶されたデータに基づいてデータ記憶部に存在するデータを示すデータ存在情報を作成する情報処理部と、情報処理部により取得されたデータ、変更履歴情報、または作成されたデータ存在情報をクライアントへ送信するサーバ通信部と、を備える。クライアントは、サーバからデータ、変更履歴情報およびデータ存在情報を受信するクライアント通信部と、サーバから取得したデータを記憶するデータ記憶部と、サーバで記憶されている変更履歴情報の蓄積状態を確認する確認部と、確認部の確認結果に基づいて、変更履歴情報に従ってデータ記憶部に記憶されているデータをサーバの管理するデータと同期させる第１の取得方法と、サーバに存在するデータを示すデータ存在情報をサーバから取得してデータ記憶部に記憶されているデータを同期させる第２の取得方法とのいずれの取得方法によりデータを取得するかを決定し、サーバからデータを取得するデータ取得処理部と、を備える。

以上説明したように本発明によれば、サーバ負荷と処理時間を軽減することが可能な情報処理装置、情報処理方法、データ管理サーバおよびデータ同期システムを提供することができる。

本発明の実施形態に係るデータ同期システムの概略構成を示す概念図である。 同実施形態にかかるデータ同期システムの機能構成を示すブロック図である。 履歴情報ファイルの一構成を示す説明図である。 サーバでオーバーフローが発生していないときのクライアントにおけるデータ同期処理を示すフローチャートである。 サーバでオーバーフローが発生しているときのクライアントにおけるデータ同期処理を示すフローチャートである。 サーバでオーバーフローが発生しているときのクライアントにおけるデータの更新・追加処理を示すフローチャートである。 クライアントにて管理しているデータ情報の一例を示す説明図である。 図６の処理におけるデータの更新・追加処理を説明するための説明図である。 サーバでオーバーフローが発生しているときのクライアントにおけるデータの削除処理を示すフローチャートである。 図９の処理におけるデータの削除処理を説明するための説明図である。 変更履歴情報の集約の一例を示す説明図である。 変更履歴情報の分割および集約の一例を示す説明図である。

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

なお、説明は以下の順序で行うものとする。
１．データ同期システムの構成例
２．データ同期システムの構成
３．データ同期処理
３−１．オーバーフローが発生していない場合のデータ同期処理
３−２．オーバーフローが発生している場合のデータ同期処理
４．変更履歴情報の効率的な処理方法
４−１．変更履歴情報の集約
４−２．変更履歴情報の分割

［１．データ同期システムの構成例］
まず、図１に基づいて、本発明の実施形態に係るデータ同期システムの概略構成について説明する。なお、図１は、本実施形態に係るデータ同期システムの概略構成を示す概念図である。

本実施形態に係るデータ同期システムは、データを提供するサーバ１００と、サーバ１００からデータを取得可能な１または複数のクライアント２００とを、ネットワーク１０を介して接続して構築されている。例えば、図１に示すように、サーバ１００と、４つのクライアント２００Ａ、２００Ｂ、２００Ｃ、２００Ｄとが接続された、データ同期システムを構築することができる。サーバ１００とクライアント２００との通信は、無線通信であってもよく、有線通信であってもよい。サーバ１００とクライアント２００との間で送受信されるデータとしては、例えば、写真などの静止画像、動画像、文書ファイル、メール、カレンダーなどのアプリケーションデータ等がある。

サーバ１００は、データを保持し、クライアント２００からの要求によりデータを提供する。また、サーバ１００は、データに対する変更を履歴管理して、データの同期処理に用いられる履歴情報ファイルをクライアント２００に提供する。クライアント２００は、サーバ１００から所望のデータを取得可能な情報処理端末であって、例えば、携帯電話やＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）等の通信端末や、コンピュータ、テレビジョン受像機等である。各クライアント２００は、サーバ１００から取得したデータを参照したり、変更することが可能であり、また、データを削除したり追加することも可能である。

本実施形態に係るデータ同期システムでは、各クライアント２００がサーバ１００の保持するデータを同一の状態で取得可能なように、同期処理が行われる。例えば、図１に示すように、ネットワーク１０を介して接続されたクライアント２００Ａ〜２００ＤのユーザＡ〜Ｄが相違する場合には、ユーザ間で共有したいデータを最新の状態で同期することにより、ユーザ同士で異なったデータを有することを防止する。また、クライアント２００Ａ〜２００Ｄが同一のユーザである場合には、自身が所持し管理するデータを、いつでもどこでも最新の状態でどのクライアント２００でも取得できるようにするため、データの同期が必要である。

すべてのクライアント２００は、サーバ１００で管理されているデータのすべて、もしくは一部を、自身に備えるデータベースまたはメモリにコピーしている。そして、クライアント２００は、サーバ１００に記憶されているデータに変更がある場合にはその変更情報を取得して、変更を自身に反映させることで同期がとれた状態を維持する。また、クライアント２００の保持するデータに変更があった場合には、その変更情報をサーバ１００へ送信し、必要な処理をサーバ１００に実行させる。以下、サーバ負荷と処理時間を軽減することの可能な、本実施形態に係るデータ同期システムの構成と当該システムにおけるデータ同期処理について説明していく。

［２．データ同期システムの構成］
まず、図２および図３に基づいて、本実施形態に係るデータ同期システムの構成について説明する。なお、図２は、本実施形態に係るデータ同期システムの機能構成を示すブロック図である。図３は、履歴情報ファイルの一構成を示す説明図である。

本実施形態に係るデータ同期システムのサーバ１００は、図２に示すように、データベースサーバ（以下、「ＤＢサーバ」と称する。）１１０と、アプリケーションサーバ（以下、「ＡＰＰサーバ」と称する。）１２０と、ＨＴＴＰサーバ１３０とから構成される。ＤＢサーバ１１０、ＡＰＰサーバ１２０、ＨＴＴＰサーバ１３０は、それぞれ別体であってもよく、２つ以上のサーバを組み合わせて一体としてもよい。

ＤＢサーバ１１０は、データを保持し、管理するサーバである。本実施形態のＤＢサーバ１１０は、データ本体の情報や、メタ情報、アプリケーションデータ等のすべてのデータを記憶する。例えば、データ本体の情報やメタ情報は、ＤＢサーバ１１０のデータ記憶部１１２に記録され、アプリケーションデータはアプリケーション記憶部１１４に記憶されるように、データは、ＤＢサーバ１１０の所定の記憶部に記録される。また、ＤＢサーバ１１０は、ＡＰＰサーバ１２０からの指示情報に基づいて、記憶部に記憶されたデータを変更するデータ変更部（図示せず。）や、データをＡＰＰサーバ１２０へ出力する出力部（図示せず。）を備えている。

ＡＰＰサーバ１２０は、ＤＢサーバ１１０とＨＴＴＰサーバ１３０との間でクライアントの要求を受けてデータを変更する仲介や、ＤＢサーバ１１０に記憶されているデータを監視してＨＴＴＰサーバ１３０へデータの状態を示すデータ情報の出力等をする。例えば、ＡＰＰサーバ１２０は、図２に示すように、ＡＰＰサーバ処理部１２２と、設定記憶部１２４とを備える。

ＡＰＰサーバ処理部１２２は、ＤＢサーバ１１０とＨＴＴＰサーバ１３０との間でのデータの仲介処理や、設定情報に基づくデータ情報の取得処理等を行う情報処理部として機能する。ＡＰＰサーバ処理部１２２は、ＤＢサーバ１１０に記憶されているデータの変更履歴情報をＨＴＴＰサーバ１３０へ出力し、サーバ履歴記憶部１３６に記憶させる。また、ＡＰＰサーバ処理部１２２は、サーバ１００で管理するデータの変更履歴情報がオーバーフローしているか否かを判定し、ＨＴＴＰサーバ１３０へ判定結果（オーバーフロー判定情報）を通知する管理部としても機能する。設定記憶部１２４は、例えば履歴保存条件や、オーバーフロー実施履歴回数、履歴処理回数等の設定情報を記憶している。なお、これらの設定情報についての説明は後述する。

また、ＡＰＰサーバ処理部１２２は、クライアント２００からの要求に応じて、ＤＢサーバ１１０のデータ記憶部１１２に記憶されているすべてのデータについて、データ名と当該データの最終変更時間とからなるデータ存在情報を作成する。データ存在情報は、クライアント２００から送信が要求される度に作成される。クライアント２００は、データ存在情報を取得することにより、データ記憶部１１２で管理されているデータの最新状態を認識することができる。

ＨＴＴＰサーバ１３０は、クライアント２００との通信を行うサーバである。ＨＴＴＰサーバ１３０は、例えば、サーバ通信部１３２と、履歴処理部１３４と、サーバ履歴記憶部１３６とを備える。サーバ通信部１３２は、クライアント２００との通信を行うインタフェースである。サーバ通信部１３２は、クライアント２００から取得した情報を、ＡＰＰサーバ１２０を介してＤＢサーバ１１０へ出力したり、ＤＢサーバ１１０から取得したデータを、ＡＰＰサーバ１２０を介してクライアント２００へ送信したりする。また、サーバ通信部１３２は、ＤＢサーバ１１０におけるデータの状態を示すデータ情報を履歴処理部１３４へ出力する。

履歴処理部１３４は、データ情報に基づいて、ＤＢサーバ１１０に記録されているデータに対する変更を管理する変更履歴情報をサーバ履歴記憶部１３６に記録する。履歴処理部１３４は、データ情報に含まれるデータ名、データの変更時間、および変更内容を変更履歴情報として、サーバ履歴記憶部１３６に記録する。また、履歴処理部１３４は、クライアント２００からの要求に応じて、変更履歴情報を含む履歴情報ファイルを取得する情報処理部としても機能し、サーバ通信部１３２を介してクライアント２００へ送信する。

サーバ履歴記憶部１３６は、データの変更履歴情報等からなる履歴情報ファイルを記憶する。サーバ履歴記憶部１３６には、ＤＢサーバ１１０のデータ記憶部１１２に記憶されるデータが変更される度に、ＡＰＰサーバ処理部１２２から送信されたデータの変更情報が書き込まれる。サーバ履歴記憶部１３６の履歴情報ファイルに含まれる変更履歴情報は、例えば図３に示すように、変更時間１３６１と、データ名１３６２と、変更内容１３６３とを記憶して管理することができる。変更内容１３６３には、例えばＤＢサーバ１１０に新規に追加された場合を示す「追加」、すでに記憶されているデータを更新した場合を示す「更新」、記憶されていたデータを削除した場合を示す「削除」等の区分が記録される。

また、履歴情報ファイルには、変更履歴情報がサーバ履歴記憶部１３６に記憶する履歴数（オーバーフロー実施履歴回数）を超えたか、すなわち、オーバーフローしたか否かを示すオーバーフロー判定情報が含まれる。オーバーフロー実施履歴回数は、サーバ１００やクライアント２００の性能に応じて、サーバ１００やクライアント２００の負荷が大きくならないような値に設定することができる。サーバ履歴記憶部１３６は、履歴情報ファイルをクライアント２００ごとに管理している。

本実施形態のサーバ１００は、サーバ１００におけるデータの変更内容を示す変更履歴情報とオーバーフロー判定情報とを含む履歴情報ファイルを、クライアント２００との通信を担当するＨＴＴＰサーバ１３０で管理している。これにより、クライアント２００からの履歴情報ファイルの送信要求に対して迅速に応答することが可能となり、サーバ１００の負荷を低減することが可能となる。

次に、クライアント２００は、図２に示すように、クライアント通信部２１０と、保存条件設定部２２０と、オーバーフロー確認部２３０と、データ取得処理部２４０と、データ記憶部２５０とからなる。

クライアント通信部２１０は、サーバ１００との通信を行うインタフェースである。クライアント通信部２１０は、サーバ１００に対して変更履歴情報やデータ存在情報、データの送信要求や、保存条件設定部２２０により設定された履歴保存条件を送信したり、サーバ１００から変更履歴情報やデータ存在情報、データを受信したりする。クライアント通信部２１０は、受信した変更履歴情報やデータ存在情報、データをオーバーフロー確認部２３０、データ取得処理部２４０へ出力する。

保存条件設定部２２０は、ユーザにより入力された入力情報や、クライアント２００の仕様等に基づいて、サーバ１００に変更履歴情報を保存するための設定情報を設定する。設定情報としては、例えば、クライアント２００に適合する監視条件（例えば、大容量のメモリを有するクライアント２００であればサーバ１００のデータすべてを同期し、小さいメモリしか有していないクライアント２００であればデータの一部を同期する、という場合の同期フォルダの指定条件等）がある。また、設定情報として、変更履歴情報を保存するデータの種類を限定する条件等を設定することもできる。保存条件設定部２２０は、クライアント通信部２１０を介して、設定情報をサーバ１００へ出力する。

オーバーフロー確認部２３０は、履歴情報ファイルのオーバーフロー判定情報を参照して、サーバ１００側においてデータの変更履歴情報を保存する蓄積量を超えているか否かを確認する。サーバ１００で管理する変更履歴情報が膨大となると、ＨＴＴＰサーバ１３０で管理する履歴情報ファイルのデータ量が増加し、メモリの使用量が著しく増加することが懸念される。また、履歴情報処理に要する時間が、サーバ１００で管理するデータをすべてクライアント２００側へコピーする時間よりも長くなる履歴数の閾値があると考えられる。本実施形態では、この閾値付近で変更履歴情報に基づく履歴情報処理からデータ存在情報に基づくデータコピー処理へ処理が移行するようにすることにより、サーバ負荷の軽減や同期処理時間の短縮を図る。すなわち、オーバーフロー判定情報は、履歴情報処理からデータコピー処理へ移行することを示す情報である。

サーバ１００のオーバーフロー判定情報は、クライアント２００においてオーバーフローフラグとして管理される。例えば、オーバーフロー判定情報より履歴情報ファイルで管理されている履歴数がオーバーフロー履歴実施回数を超えていないと確認された場合には、オーバーフローフラグに「false」が設定される。また、オーバーフロー判定情報より履歴情報ファイルで管理されている履歴数がオーバーフロー履歴実施回数を超えていると確認された場合には、オーバーフローフラグに「true」が設定される。すなわち、オーバーフロー履歴実施回数が上述の閾値を示す値であり、サーバ１００のＡＰＰサーバ処理部１２２から受信したオーバーフロー判定情報およびクライアント２００で設定されるオーバーフローフラグは、上記閾値に対するサーバ１００の変更履歴情報の数の状態を示す情報となる。このように、オーバーフロー確認部２３０は、取得した履歴情報ファイルのオーバーフロー判定情報を参照して、サーバ１００側でオーバーフローが生じているか否かを確認し、確認結果（オーバーフローフラグ）をデータ取得処理部２４０へ出力する。

データ取得処理部２４０は、オーバーフロー確認部２３０による確認結果に基づいてサーバ１００からのデータの取得方法を決定し、データをサーバ１００から取得する。データ取得処理部２４０は、サーバ１００側でのオーバーフローの発生についての確認結果より、履歴情報処理（第１の取得方法）またはデータコピー処理（第２の取得方法）のいずれを実行するかを決定する。そして、データ取得処理部２４０は、決定した取得方法に基づき、クライアント通信部２１０を介してサーバ１００へデータの提供を要求する。かかる要求によりサーバ１００から提供されたデータは、クライアント通信部２１０からデータ取得処理部２４０へ出力され、データ記憶部２５０に記録される。

データ取得処理部２４０は、サーバ１００からデータを取得するに際して、ＨＴＴＰサーバ１３０のサーバ履歴記憶部１３６に記憶された履歴情報ファイルまたはＡＰＰサーバ処理部１２２により作成されるデータ存在情報を、クライアント通信部２１０を介して取得する。また、データ取得処理部２４０は、サーバ１００から取得したデータに基づき、クライアント２００で保持するデータに関する情報であるクライアントデータ情報を作成・更新する。クライアントデータ情報は、クライアント２００側でデータの追加や変更、削除等の処理が実行された場合にも、データ取得処理部２４０により更新される。なお、クライアントデータ情報の内容については、後述する。

データ記憶部２５０は、データ取得処理部２４０によってサーバ１００から取得されたデータを記憶する。クライアント２００のユーザは、データ記憶部２５０に記憶されたデータの参照、更新、追加、削除等の処理を行うことができる。また、データ記憶部２５０は、データ記憶部２５０に記憶されているデータに関する情報をクライアントデータ情報として記憶している。クライアントデータ情報には、各データについて、データ名、サーバ１００での最終変更時間、データ記憶部２５０に記録した保存時間、およびクライアント２００からサーバ１００へ当該データを送信したか否かを示す送信状態フラグが含まれている。また、クライアントデータ情報は、クライアント２００の保持するデータがサーバ１００に存在するデータであるか否かを示す存在チェックフラグを含むこともできる。存在チェックフラグは、データコピー処理時のデータの削除の際に利用される。当該処理の詳細は後述する。クライアントデータ情報は、データ記憶部２５０で保持するデータの状態が変更する度に更新される。

以上、本実施形態に係るデータ同期システムの機能構成について説明した。

［３．データ同期処理］
次に、図４〜図１０に基づいて、本実施形態に係るデータ同期システムにおけるデータ同期処理について説明する。なお、図４は、サーバ１００でオーバーフローが発生していないときのクライアント２００におけるデータ同期処理を示すフローチャートである。図５は、サーバ１００でオーバーフローが発生しているときのクライアント２００におけるデータ同期処理を示すフローチャートである。図６は、サーバ１００でオーバーフローが発生しているときのクライアント２００におけるデータの更新・追加処理を示すフローチャートである。図７は、クライアント２００にて管理しているデータ情報の一例を示す説明図である。図８は、図６の処理におけるデータの更新・追加処理を説明するための説明図である。図９は、サーバ１００でオーバーフローが発生しているときのクライアント２００におけるデータの削除処理を示すフローチャートである。図１０は、図９の処理におけるデータの削除処理を説明するための説明図である。

本実施形態にかかるデータ同期システムでは、サーバ１００で管理する変更履歴情報がオーバーフローしているか否かにより、サーバ１００とクライアント２００とが保持するデータを同期させるためのデータの取得方法が異なる。以下、オーバーフローが発生していない場合と、オーバーフローが発生している場合との、データ同期処理について詳細に説明する。

（３−１．オーバーフローが発生していない場合のデータ同期処理）
オーバーフローが発生していない場合のデータ同期処理は、図４に示すフローチャートに沿って行われる。クライアント２００は、定期的にサーバ１００の状態を監視しており、当該データ同期処理を終了する終了条件を満たしているかを確認する（ステップＳ１００）。終了条件は、例えばクライアント２００とサーバ１００との接続が切断された状態等とすることができる。クライアント２００は、終了条件を満たしているか否かを判定し（ステップＳ１０２）、終了条件を満たしている場合には、データ同期処理を終了する。一方、終了条件を満たしていない場合には、履歴保存条件の設定が完了しているかを確認する（ステップＳ１０４）。

履歴保存条件は、サーバ１００に記憶される情報であって、クライアント２００の仕様等より当該クライアント２００に適合した条件でデータの同期が行われるように、クライアント２００ごとに設定される。履歴保存条件には、例えば、大容量のメモリを有するクライアント２００であればサーバ１００のデータすべてを同期し、小さいメモリしか有していないクライアント２００であればデータの一部を同期する、という場合の同期フォルダの指定条件や、データ種類を限定する条件等の設定情報が含まれる。また、履歴保存条件には、保存したい履歴の変更内容（例えば、「追加」、「更新」、「削除」等）の種別の指定も含めることができる。

クライアント２００は、保存条件設定部２２０による上記設定情報の設定が行われたか否かを判定する（ステップＳ１０６）。設定情報が設定されていない場合には、クライアント２００は、設定情報の設定を行い、クライアント通信部２１０を介してサーバ１００へ履歴保存条件として出力する（ステップＳ１０８）。そして、クライアント２００は、ステップＳ１０８にて履歴保存条件が設定された後、あるいは、すでに履歴保存条件が設定されているときには、サーバ１００にて管理するデータが、サーバ１００からクライアント２００へコピーされているかを確認する（ステップＳ１１０）。

サーバ１００にて管理されるデータのコピーは、クライアント２００がサーバ１００に最初に接続されたときに実行される処理であり、頻繁にデータの同期処理を行っているシステムでは、一度実行すれば再度行われることはほとんどない。再度実行される場合としては、例えば、サーバ１００で管理する変更履歴情報の数がオーバーフローした場合や、コピーすべきデータが多いため複数回に分けてデータがクライアント２００へ送信される場合にすべてのデータの受信を完了していないとき等がある。なお、データのコピーが再度実行される場合の処理については、後述する。また、ステップＳ１１０では、実際には、後述する図５のステップＳ２１０と同様、サーバ１００で変更履歴情報のオーバーフローが発生していないかをオーバーフローフラグを参照して確認している。しかし、ここではオーバーフローは発生していない場合を説明しているため、かかる処理の記載を省略している。

クライアント２００は、サーバ１００からクライアント２００へのデータのコピーが完了しているか否かを判定し（ステップＳ１１２）、完了していない場合には、サーバ１００で管理するデータのコピーを行う（ステップＳ１１４；データコピー処理）。ステップＳ１１４の処理は、まず、クライアント２００からサーバ１００に対して、サーバ１００に存在する全データの情報、すなわちデータ存在情報の要求が行われる。かかる要求を受信したＨＴＴＰサーバ１３０は、ＡＰＰサーバ１２０のＡＰＰサーバ処理部１２２に要求を通知する。ＡＰＰサーバ処理部１２２は、データ記憶部１１２を参照して、データ記憶部１２２に記憶されている全データのデータ名および最終変更時間を取得し、サーバ存在情報を作成する。ＡＰＰサーバ処理部１２２は、作成したサーバ存在情報を、ＨＴＴＰサーバ１３０を介してクライアント２００へ送信する。次いで、クライアント２００は、データ存在情報とクライアントデータ情報とを比較して、クライアント２００に存在しないデータ等サーバ１００から取得の必要なデータを特定する。

クライアント２００は、特定された取得の必要なデータの送信をサーバ１００へ要求する。当該要求を受信したＨＴＴＰサーバ１３０は、ＡＰＰサーバ１２０へその要求を伝達する。そして、ＡＰＰサーバ１２０は、ＤＢサーバ１１０に対して要求されたデータを取得して送信するよう要求する。ＤＢサーバ１１０は、要求されたデータを取得すると、当該データをＡＰＰサーバ１２０へ出力する。そして、ＡＰＰサーバ１２０は、ＤＢサーバ１１０から送信されたデータをＨＴＴＰサーバ１３０へ出力し、ＨＴＴＰサーバ１３０は、受信したデータをクライアント２００へ出力する。このとき、クライアント２００は、取得したデータをデータ記憶部２５０に記録する。

一方、ステップＳ１１２にてサーバ１００からクライアント２００へのデータのコピーが完了している場合には履歴情報処理を実行する（ステップＳ１１６）。履歴情報処理は、サーバ１００のＨＴＴＰサーバ１３０にて管理されているデータの変更履歴情報に基づいて、クライアント２００で保持するデータを変更する処理である。サーバ１００とクライアント２００との同期が少なくとも一度とれていれば、クライアント２００が取得しているデータの変更内容を取得することで、サーバ１００で管理されているデータと同一のデータを保持することができる。これにより、サーバ負荷の低い状態でデータ同期処理を行うことができる。

履歴情報処理を実行するために、サーバ１００は、クライアント２００ごとに、サーバ１００にて実行されたデータの変更を変更履歴情報として、ＨＴＴＰサーバ１３０のサーバ履歴記憶部１３６に記憶している。ＡＰＰサーバ１２０のＡＰＰサーバ処理部１２２は、履歴保存条件に基づきデータの状態を監視し、変更があるごとにＨＴＴＰサーバ１３０へ変更情報を出力して、変更履歴情報としてサーバ履歴記憶部１３６に記録させる。

ステップＳ１１６において、クライアント２００は、まず、サーバ１００に対して変更履歴情報を含む履歴情報ファイルの送信を要求する。履歴情報ファイルの送信の要求を受けたサーバ１００は、ＨＴＴＰサーバ１３０にてサーバ履歴記憶部１３６から当該クライアント２００の履歴情報ファイルを取得して、クライアント２００へ送信する。履歴情報ファイルは、ＨＴＴＰサーバ１３０にて直接扱うことが可能であるため、クライアント２００から履歴情報ファイルの取得要求を受信したとき、ＨＴＴＰサーバ１３０だけで当該処理を完結することができる。よって、サーバ１００としては、管理する履歴件数が膨大でない限りはサーバ負荷を低くして同期処理をすることが可能となる。

履歴情報ファイルを取得したクライアント２００は、変更履歴情報を参照し、現在クライアント２００がデータ記憶部２５０に保持しているデータを更新する。すなわち、データ取得処理部２４０は、変更履歴情報に含まれるデータのデータ名、変更内容、および変更時間（サーバ１００での最終変更時間）に基づいて、データ記憶部２５０のデータを更新し、サーバ１００の保持するデータとの同期を図る。

ステップＳ１１４またはＳ１１６の処理により、サーバ１００で管理されているデータの状態がクライアント２００に反映されると、続いて、クライアント２００の保持するデータの状態が必要に応じてサーバ１００へ通知される（ステップＳ１１８）。他のクライアント２００によりデータが変更されている場合に、サーバ１００より変更後のデータを取得する一方、クライアント２００自身で更新したデータについては、他のクライアント２００とデータの同期をとるため、変更されたデータをサーバ１００へ通知する必要がある。そこで、クライアント２００は、クライアントデータ情報の送信状態フラグに基づいて、サーバ１００からの取得以降にクライアント２００自身で変更したデータをサーバ１００へ送信する。

送信状態フラグは、クライアント２００で追加や変更等なされたがサーバ１００へ未送信のデータを判別するため情報である。例えば、送信状態フラグには、クライアント２００で更新されたがサーバ１００へ未送信のデータには「Post」が設定され、サーバ１００への送信が成功したデータには「PostSuccess」が設定され、それ以外のデータには「Steady」が設定される。クライアント２００は、送信状態フラグに「Post」が設定されているデータをサーバ１００へ送信する。

クライアント２００で変更されたデータを受信したサーバ１００は、ＤＢサーバ１１０に記憶されているデータを変更し、クライアント２００のデータの状態と同期をとる。これにより、サーバ１００とクライアント２００とがそれぞれ保持するデータが同一となる。また、他のクライアント２００は、サーバ１００の変更履歴ファイルを参照することにより、サーバ１００のデータが更新されたことを認識して、変更後のデータをサーバ１００より取得し、データの同期を図ることができる。

変更したデータを送信したクライアント２００の変更履歴ファイルにも、自身が変更したデータがサーバ１００のデータ記憶部１１２に反映されたことが変更履歴情報として記録される。これより、かかるクライアント２００が次にサーバ１００から変更履歴ファイルを取得したときには、変更履歴情報から自身が更新したデータがサーバ１００側に反映されていることを認識することができる。すなわち、クライアントデータ情報の送信状態フラグが「Post」のデータについて、サーバ１００への送信が成功すると、当該データの送信状態フラグには「PostSuccess」が設定される。その後、クライアント２００がサーバ１００から取得した変更履歴情報に基づき変更されたデータを更新する際、クライアント２００は、クライアントデータ情報の送信状態フラグを確認する。このとき、送信状態フラグに「PostSuccess」が設定されていれば、自身が変更したデータであり、サーバ１００へ送信を要求しなくともよいことがわかる。したがって、変更履歴情報に基づいて更新しようとするデータの送信状態フラグが「PostSuccess」のときには、クライアント２００は、クライアント２００の保持するデータを更新しないとともに、クライアントデータ情報の当該データの送信状態フラグを「PostSuccess」から「Steady」に設定を変更する。なお、その後、さらに当該データが更新されたときには、送信状態フラグは再び「Post」に設定される。

なお、クライアント２００のデータの変更内容をサーバ１００側に反映させる場合、上述したように変更後のデータ自体をサーバ１００へ送信してもよく、変更内容のみをサーバ１００へ送信してもよい。変更内容を受信した場合、サーバ１００は、変更内容に基づいて、ＤＢサーバ１１０のデータ記憶部１１２に記憶されるデータを変更して、データの同期をとることになる。

ここで、クライアント２００におけるデータの変更のうち、データの削除については、クライアント２００の変更に伴ってサーバ１００上のデータも削除してもよいが、サーバ２００上にはデータを保持しておくようにしてもよい。あるクライアント２００からデータが削除されてしまった場合、削除を望まない他のクライアント２００からも当該データが削除されてしまうことが考えられるためである。サーバ１００は、クライアント２００からデータを削除する要求を受けたとき、例えばクライアント２００に対して当該データを削除してもよいか確認するメッセージを送信する。そして、サーバ１００は、クライアント２００から削除を許可する返信を受けた場合のみ、データを削除するようにしてもよい。あるいは、サーバ１００上のデータは削除せず、クライアント２００側でデータが削除された場合には、クライアント２００の要求またはサーバ１００が自動的に、削除されたデータをサーバ１００からクライアント２００へ送信するようにしてもよい。

このように、ステップＳ１１４〜Ｓ１１８の処理により、サーバ１００とクライアント２００との間でデータを同期させることができる。ステップＳ１１８の処理が終了すると、ステップＳ１００に戻り、データ同期処理を繰り返し実施するか確認する。

以上、オーバーフローが発生していない場合のデータ同期処理について説明した。オーバーフローが発生していない場合、基本的に変更履歴情報に基づいて変更のあったデータのみを更新する。一方、変更履歴情報が膨大になった場合には、サーバ１００に保持しておく履歴情報ファイルによりメモリが著しく消費することが考えられる。そして、履歴情報処理に要する時間がサーバ１００の管理するデータをクライアント２００にすべてコピーするために必要な時間を超えるようになる。そこで、本実施形態に係るデータ同期処理では、サーバ１００の負荷を軽減し、同期処理時間を短縮することができる。以下、図５に基づいて、本実施形態に係るデータ同期システムのサーバ１００において、オーバーフローが発生している場合のデータ同期処理について説明する。

（３−２．オーバーフローが発生している場合のデータ同期処理）
オーバーフローが発生している場合のデータ同期処理は、図５に示すフローチャートに沿って行われる。オーバーフローが発生しているか否かは、ＡＰＰサーバ１２０の設定記憶部１２４に記憶されているオーバーフロー実施履歴回数に基づき、ＡＰＰサーバ処理部１２２によって判断される。ＡＰＰサーバ処理部１２２は、ＨＴＴＰサーバ１３０のサーバ履歴記憶部１３６に記録される変更履歴情報の数がオーバーフロー実施履歴回数以下であるときには、ＤＢサーバ１１０で保持するデータが変更される度に、変更情報をサーバ履歴記憶部１３６の履歴情報ファイルに変更履歴情報として追加する。したがって、クライアント２００がサーバ１００へアクセスするまでにサーバ１００側で変更されたデータの変更履歴は、履歴情報ファイルより認識することができる。

しかし、クライアント２００が長時間サーバ１００にアクセスしていない場合や、ネットワーク１０に接続するクライアント２００が複数存在したり、あるクライアント２００が頻繁にアクセスしたりしている場合には、膨大な変更履歴情報が生成される。このような変更履歴情報に基づいて、１つずつクライアント２００がデータを取得すると、データのコピーに莫大な時間がかかることになる。また、変更履歴情報を記憶するサーバ１００の負荷も大きくなる。

そこで、このような場合には、ＡＰＰサーバ処理部１２２は、履歴処理部１３４に対して、サーバ履歴記憶部１３６の履歴情報ファイルに、変更履歴情報を書き込むことを停止させるとともに、オーバーフローしたことを示すオーバーフロー判定情報を記録させる。クライアント２００は、オーバーフロー判定情報からサーバ１００において変更履歴情報のオーバーフローが生じていることを認識すると、サーバ１００にて保持するすべてのデータに関する情報であるデータ存在情報を取得することにより、データの同期を図る。以下、図５に基づき、オーバーフロー発生時のデータ同期処理について説明していく。なお、ステップＳ２００〜Ｓ２０８までは、図４に示すオーバーフローが発生していない場合のデータ同期処理のステップＳ１００〜Ｓ１０８と同一の処理であるため、かかる処理の詳細な説明は省略する。

まず、クライアント２００は、データ同期処理を終了する終了条件を満たしているかを確認する（ステップＳ２００）。クライアント２００は、終了条件を満たしているか否かを判定し（ステップＳ２０２）、終了条件を満たしている場合には、データ同期処理を終了する。一方、終了条件を満たしていない場合には、履歴保存条件の設定が完了しているかを確認する（ステップＳ２０４）。

その後、クライアント２００は、保存条件設定部２２０による上記設定情報の設定が行われたか否かを判定する（ステップＳ２０６）。設定情報が設定されていない場合には、クライアント２００は、設定情報の設定を行い、クライアント通信部２１０を介してサーバ１００へ履歴保存条件として出力する（ステップＳ２０８）。そして、クライアント２００は、ステップＳ２０８にて履歴保存条件が設定された後、あるいは、すでに履歴保存条件が設定されているときには、サーバ１００にて管理するデータが、サーバ１００からクライアント２００へコピーされているかを確認するとともに、オーバーフローフラグの状態を確認する（ステップＳ２１０）。

オーバーフローフラグは、ＨＴＴＰサーバ１３０のサーバ履歴記憶部１３６に記憶されている履歴情報ファイルに含まれるオーバーフロー判定情報に基づいて設定される。本実施形態では、オーバーフロー判定情報より履歴情報ファイルで管理されている履歴数がオーバーフロー履歴実施回数を超えていないと確認された場合には、オーバーフローフラグに「false」が設定されている。また、オーバーフロー判定情報より履歴情報ファイルで管理されている履歴数がオーバーフロー履歴実施回数を超えていると確認された場合には、オーバーフローフラグには「true」が設定されている。

クライアント２００は、ステップＳ２１０における確認処理より、データのコピーが完了し、かつオーバーフローフラグが「false」であるか否かを判定する（ステップＳ２１２）。そして、データのコピーの完了、またはオーバーフローフラグが「false」であることの少なくともいずれか一方を満たさない場合には、クライアント２００は、サーバ１００の管理するデータのコピーを行う（ステップＳ２１４；データコピー処理）。ステップＳ２１４の処理は、図４のステップＳ１１４と同様に行うことができる。

ここで、図４のステップＳ１１４および図５のステップＳ２１４におけるデータのコピー処理は、処理するデータの数や内容に応じて分割して処理することが必要となる場合がある。例えば、一度にすべてのデータをコピーすることで１回のループにかかる時間が長くなってしまう場合には、分割してコピーすることが望ましい。

また、サーバ１００側でオーバーフローが発生している場合には、クライアント２００側で各データのサーバ１００での最終変更時間を保持することにより、既に保持しているデータをサーバ１００から再取得せずに済む。これにより、データ同期処理に要する時間の短縮に貢献することができる。さらに、オーバーフローが発生した後からデータの同期処理再開までの間に、サーバ１００側でデータの削除があった場合には、サーバ１００に存在するデータの情報とクライアント２００に存在するデータとを比較することで、削除されたデータを特定することも可能である。

より具体的に説明すると、データコピー処理での、必要と判断したデータのみの取得処理は、例えば図６〜図１０に示す方法により実行することができる。まず、更新または追加されたデータの取得処理は、図６に示すフローチャートに沿って行われる。まず、クライアント２００のデータ取得処理部２４０は、サーバ１００から取得したデータ存在情報とクライアント２００で管理しているクライアントデータ情報とを比較して、更新されたデータの有無を判定する（ステップＳ３００）。データ取得処理部２４０は、データ存在情報の最終変更時間とクライアントデータ情報のサーバ１００での最終変更時間とを比較して、データ存在情報の最終変更時間が新しい場合に、サーバ１００側でデータの変更が行われたと判定する。

ステップＳ３００にて更新されたデータが存在すると判定した場合には、データ取得処理部２４０は、当該データをサーバ１００より取得することを決定する（ステップＳ３０２）。一方、データ存在情報の最終変更時間とクライアントデータ情報のサーバ１００での最終変更時間とが同一である場合には、データ取得処理部２４０は、当該データを取得対象としない。

例えば、図７に示す情報がクライアント２００のクライアントデータ情報の一部であり、図８の左側の表で示す情報がサーバ１００で管理されているデータ存在情報であるとする。データ取得処理部２４０は、データ存在情報とクライアントデータ情報とのデータ名と最終変更時間とを比較し、変更時間がサーバ１００側で更新されているか否かを判定する。図７および図８の例では、データ名「222.jpg」のデータがサーバ１００側で更新されていることがわかる。これより、データ取得処理部２４０は、データ「222.jpg」をサーバ１００から取得することを決定する。

次いで、データ取得処理部２４０は、サーバ１００から取得したデータ存在情報の最終変更時間とクライアント２００のクライアントデータ情報とを比較して、サーバ１００に新たに追加されたデータの有無を判定する（ステップＳ３０４）。データ取得処理部２４０は、データ存在情報とクライアントデータ情報とのデータ名を比較して、サーバ１００のデータ存在情報に含まれるデータが、クライアント２００のクライアントデータ情報に含まれるか否かを確認する。そして、データ存在情報にのみ含まれるデータ名が存在した場合、データ取得処理部２４０は、当該データは新たにサーバ１００に追加されたものと判定し、サーバ１００から取得することを決定する（ステップＳ３０６）。一方、データ存在情報のみに含まれるデータ名が存在しない場合、データ取得処理部２４０は、サーバ１００からのデータの取得は行わない。

例えば、図７および図８の例では、データ名「444.jpg」のデータがデータ存在情報にのみ含まれていることがわかる。このとき、データ取得処理部２４０は、データ「444.jpg」をサーバ１００から取得することを決定する。このようにして、サーバ１００側で更新または追加されたデータをクライアント２００側に取得することができる。

ここで、図７および図８に示す情報のみからは、サーバ１００側でオーバーフローが発生している間にサーバ１００側で削除されたデータを特定することができない。そこで、例えば、クライアント２００側で保持するデータがサーバ１００に存在しているか否かを示す情報である存在チェックフラグをクライアントデータ情報に設けてもよい。本実施形態において、存在チェックフラグは、サーバ１００側に同一データの存在が確認されているとき「true」の値をとり、サーバ１００側に同一データの存在が確認できないとき「false」の値をとる。したがって、存在チェックフラグの値が「false」のデータは、サーバ１００に存在していないデータであり、オーバーフローが発生している間に削除されたものと判断することができる。

サーバ１００側で削除されたデータのクライアント２００側への反映は、図９に示すフローチャートに沿って行うことができる。まず、データ取得処理部２４０は、オーバーフローフラグよりサーバ１００で変更履歴情報のオーバーフローが発生していることを認識すると、クライアント２００のクライアントデータ情報の存在チェックフラグをすべて「false」にする（ステップＳ３１０）。このときに存在チェックフラグを管理パラメータとしてクライアントデータ情報に追加設定してもよく、予め管理パラメータとして設定していてもよい。

次いで、データ取得処理部２４０は、サーバ１００からデータ存在情報を取得する（ステップＳ３１１）。そして、データ取得処理部２４０は、データ存在情報のデータが、クライアント２００のクライアントデータ情報に存在するか否かを確認する（ステップＳ３１２）。そして、データ取得処理部２４０は、同一データ名のデータが存在した場合には、クライアントデータ情報の存在チェックフラグを「false」から「true」に変更する（ステップＳ３１３）。一方、データ取得処理部２４０は、同一データ名のデータが存在しない場合には、クライアントデータ情報の存在チェックフラグを「false」のままとする（ステップＳ３１４）。

ステップＳ３１２〜Ｓ３１４の処理は、サーバ１００のデータ存在情報のすべてのデータについて確認されるまで繰り返される（ステップＳ３１５）。すべてのデータについて存在チェックが行われると、データ取得処理部２４０は、クライアントデータ情報より存在チェックフラグが「false」のデータを特定し、データ記憶部２５０から当該データを削除する（ステップＳ３１６）。

例えば、図７および図８の例では、図９の処理に従ってデータの存在をチェックしていくと、データ名「666.jpg」のデータがサーバ１００のデータ存在情報には含まれていないことがわかる。したがって、データ取得処理部２４０は、データ記憶部２５０からデータ「666.jpg」を削除する。このようにして、オーバーフロー発生時にサーバ１００側で削除されたデータの情報もクライアント２００側へ反映させることができる。

図５に戻り、ステップＳ２１４のデータのコピー処理が完了すると、クライアント２００は、オーバーフローフラグを「false」にする（ステップＳ２１６）。一方、ステップＳ２１２にて、データのコピーが完了し、かつオーバーフローフラグが「false」であると判定された場合には、クライアント２００は履歴情報処理を実行する（ステップＳ２１８）。履歴情報処理は、図４のステップＳ１１６の処理と同様に行われる。クライアント２００は、サーバ１００から取得した履歴情報ファイルの変更履歴情報と、クライアント２００のクライアントデータ情報とを比較して、変更されたデータのみをサーバ１００から取得し、データ記憶部２５０に記録する。

ここで、クライアント２００は、ステップＳ２１８においてサーバ１００にて変更履歴情報のオーバーフローが発生しているか否かを判定する（ステップＳ２２０）。ステップＳ２２０は、データ同期処理の次のループにおいてオーバーフローが生じているか否かを判定するために用いる情報を生成する処理である。クライアント２００は、オーバーフローが発生していると判定したときオーバーフローフラグを「true」とし（ステップＳ２２２）、オーバーフローが発生していないと判定したときオーバーフローフラグを「false」とする（ステップＳ２２４）。

その後、クライアント２００は、クライアント２００自身の保持するデータの状態を必要に応じてサーバ１００へ通知する（ステップＳ２２６）。ステップＳ２２６の処理は、図４のステップＳ１１８の処理と同様に行うことができる。クライアント２００は、クライアントデータ情報の送信状態フラグに基づいて、クライアント２００で変更したがサーバ１００に未送信のデータをサーバ１００へ送信する。クライアント２００で変更されたデータを受信したサーバ１００は、ＤＢサーバ１１０に記憶されているデータを変更し、クライアント２００のデータの状態と同期をとる。これにより、サーバ１００とクライアント２００とがそれぞれ保持するデータが同一となる。また、他のクライアント２００は、サーバ１００の変更履歴ファイルを参照することにより、サーバ１００のデータが更新されたことを認識して、変更後のデータをサーバ１００より取得し、データの同期を図ることができる。

以上、サーバ１００にてオーバーフローが発生している場合のデータ同期処理について説明した。このように、サーバ１００で管理するデータの変更履歴情報がオーバーフロー実施履歴回数を超えた場合には、サーバ１００での変更履歴情報の記録を停止し、履歴情報ファイルのオーバーフロー判定情報にオーバーフローが生じていることを示す情報を設定する。この場合、クライアント２００は、サーバ１００からデータをコピーするデータコピー処理を実施して、データの同期を図る。そして、サーバ１００とクライアント２００との間でデータの同期が完了すると、履歴情報ファイルのオーバーフロー判定情報にオーバーフローが生じていないことを示す情報が設定される。これにより、次に変更履歴情報のオーバーフローが発生するまでは、変更履歴情報に基づく履歴情報処理によりサーバ１００とクライアント２００とのデータの同期が行われる。こうして、サーバ１００に莫大な変更履歴情報が蓄積されサーバ負荷が高くなるのを防止することができ、データの同期処理に要する時間を短縮することができる。

［４．変更履歴情報の効率的な処理方法］
ここで、変更履歴情報を集約して、データ同期処理に要する時間を短縮することもできる。以下、変更履歴情報の効率的な処理方法について、図１１および図１２の例に沿って説明する。なお、図１１は、変更履歴情報の集約の一例を示す説明図である。図１２は、変更履歴情報の分割および集約の一例を示す説明図である。

（４−１．変更履歴情報の集約）
変更履歴情報は、データに対して行われた変更の内容を示す情報であり、例えば図３に示すように時系列に並べられている。例えば、サーバ履歴記憶部１３６に、図３のような変更情報Ａ〜Ｋが変更履歴情報に含まれているとする。通常、変更時間の古い変更情報から順に、サーバ１００の保持するデータをクライアント２００へ反映させることにより、データの同期を正常に行うことができる。ここで、同一のデータに対して複数の変更が行われている場合、データ単位で処理をまとめることで、データの同期処理の回数を減少させることができる。

例えば、データ「Test.txt」に対しては、変更情報Ａ、Ｅ、ＩおよびＫより４つの変更処理が行われている。クライアント２００のデータ取得処理部２４０は、図１１に示すようにこれらの変更情報を集約する。かかる例では、データ「Test.txt」は、データを新規に追加した後に２回更新され、さらに削除されていることから、結果として、はじめから存在しなかったものとみなすことができる。そこで、データ取得処理部２４０は、データ「Test.txt」をサーバ１００から取得しないと決定する。

同様に、データ「Tree.jpg」に対しては、変更情報Ｂ、ＦおよびＪより３つの変更処理が行われている。かかる例では、既にサーバ１００に存在していたデータ「Tree.jpg」を３回更新していることから、データ取得処理部２４０は、データ「Tree.jpg」に対する最後の変更（変更情報Ｊ）のみをクライアント２００のデータに反映させる。また、データ「Tmp.doc」に対しては、変更情報ＣおよびＧの２つの変更処理が行われている。かかる例では、新たなデータ「Tmp.doc」が新規に追加された後更新されていることから、データ取得処理部２４０は、更新後（変更情報Ｇ）のデータ「Tree.jpg」をクライアント２００のデータ記憶部２５０に追加する。

そして、データ「cmd.log」に対しては、変更情報ＤおよびＨの２つの変更処理が行われている。かかる例では、既にサーバ１００に存在していたデータ「cmd.log」を更新した後削除していることから、データ取得処理部２４０は、データ「cmd.log」をクライアント２００のデータ記憶部２５０から削除する。以上より、図３の変更履歴情報の処理は、結果として図１１に示す３つの処理に集約されることになる。これにより、データのコピー処理の時間が短縮され、データ同期処理の時間短縮に大きく貢献することができる。

（４−２．変更履歴情報の分割）
データのコピー処理においては、上述したように、１回のループで処理するデータ数を限定することで、１回のデータのコピー処理に要する時間を適度な時間に抑え、スムーズなデータ同期処理を実現することができる。変更履歴情報についても同様に考えることができる。ただし、データのコピー処理については分割が容易であり、例えば、ファイル単位の同期については、ファイル単位で分割し処理するのであれば、その分割方法や処理の順序に特に留意しなくても正常に行うことができる。一方、変更履歴情報については、変更処理を行った時間、すなわち処理の順序が非常に重要であり、時間を考慮しないで分割すると正しい同期処理は行われない。したがって、変更処理の実施された順序に沿った変更履歴情報の分割をする必要がある。変更履歴情報の分割は、１回のループにおいて処理する変更履歴情報の数、すなわち履歴変更回数に応じて行われる。

例えば、図３に示す１１の履歴情報Ａ〜Ｋからなる変更履歴情報の分割を考える。このとき、１回のループにおける履歴処理回数は、ＡＰＰサーバ１２０の設定記憶部１２４に予め記憶されているものとする。履歴処理回数は、オーバーフロー実施履歴回数と同一あるいはそれ以下の値に設定される。例えば、オーバーフロー実施履歴回数が２０、１回のループにおける履歴処理回数が６と設定されているとする。このとき、図３に示すように、履歴情報の数は１１であるから、オーバーフローは発生しておらず、履歴情報を６つ処理してから１回のループが終了する。次の回のループでは、履歴情報が増加していない場合には、残りの５つの履歴情報の処理が行われる。

すなわち、図１２に示すように、最初のループでは、履歴情報を昇順に並べて古いものから６つの履歴情報Ａ〜Ｆが処理され、次の回のループでは、残りの５つの履歴情報Ｇ〜Ｋが処理される。そして、上述したように、２つの分割された履歴情報をさらに集約することもできる。

例えば、履歴情報Ａ〜Ｆを集約すると、データ「Test.txt」に対しては、変更情報ＡおよびＥの２つの変更処理が行われている。かかる例では、新たなデータ「Test.txt」が新規に追加された後更新されていることから、データ取得処理部２４０は、更新後（変更情報Ｅ）のデータ「Test.txt」をクライアント２００のデータ記憶部２５０に追加する。同様に、データ「Tree.jpg」に対しては、変更情報ＢおよびＦの２つの変更処理が行われている。かかる例では、既にサーバ１００に存在していたデータ「Tree.jpg」を２回更新していることから、データ取得処理部２４０は、データ「Tree.jpg」に対する最後の変更（変更情報Ｆ）のみをクライアント２００のデータに反映させる。

データ「Tmp.doc」および「cmd.log」については、データ取得処理部２４０は、それぞれ履歴情報Ｃ、Ｄの内容をデータ記憶部２５０に反映させる。このように集約することにより、６つの履歴情報を４つの処理にまとめることができ（図１２の上側の表）、１回のループにおける処理をさらに軽減することができる。同様に、履歴情報Ｇ〜Ｋを集約すると、５つの履歴情報を４つの処理にまとめることができる（図１２の下側の表）。このようにして、変更履歴情報を分割してもデータの同期処理を正しく実施することができる。

本例のように変更履歴情報を分割した場合、結果として８つの処理を実施することになる。図１１に基づき説明したような、変更履歴情報を一括して集約した場合と比較すると、処理の回数は３から８となっており、増加する。しかし、データの数や種類等によって変更履歴情報をどの程度集約可能かは変化する。分割してデータ同期処理を行うことにより、上述したように、１回のループでの処理に要する時間を確実に適度な時間に抑えることが可能となり、スムーズな同期処理を実現することが可能である。

また、例えば、図１２の下側の表のデータ「Tree.jpg」および「Tmp.doc」の更新処理が、変更履歴情報の処理を実施しているクライアント２００自身で行われたものである場合もある。クライアント２００は、上述したように、クライアントデータ情報の送信状態フラグを参照して、自身がサーバ１００に対して要求したデータの変更内容であることを確認することができる。すなわち、送信状態フラグが「PostSuccess」であるときには、当該データは既に保持しているデータと同一であると判断して、サーバ１００から当該データを取得する処理を省略することも可能である。これにより、さらに同期処理に要する時間を短縮することができる。

以上、本発明の実施形態に係るデータ同期システムの構成と、当該データ同期システムにおけるデータ同期処理について説明した。本実施形態に係るデータ同期システムによれば、データの変更履歴を管理するサーバ１００側において履歴数がオーバーフローした場合、サーバ１００は履歴を保持せずオーバーフロー発生を示すオーバーフロー判定情報を保持する。そして、クライアント２００は、サーバ１００でオーバーフローが発生していないときには、変更履歴情報に基づいてデータの同期処理を行い、オーバーフローが発生しているときには、データ存在情報に基づいてサーバ１００側で保持する最新のデータをコピーする。

これにより、サーバ１００側に所定数以上のデータの変更履歴が蓄積されないので、サーバ１００のメモリの使用量を低減することができる。また、長期間データ同期処理がされていないクライアント２００がネットワーク１０に接続され、データ同期処理が再開されたとしても、上記データ同期処理によって正しく高速にデータを同期させることができる。これは、通信量の減少にもつながり、逼迫しつつある帯域の節約や通信料金の削減にも貢献する。

以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。

例えば、上記実施形態では、サーバ１００側のデータの変更内容をクライアント２００側のデータに反映させた後、クライアント２００側でのデータの変更内容をサーバ１００に通知したが、本発明はかかる例に限定されない。例えば、クライアント２００側でのデータの変更内容をサーバ１００に通知した後、サーバ１００側のデータの変更内容をクライアント２００側のデータに反映させてもよい。

１００ サーバ
１１０ ＤＢサーバ
１１２ データ記憶部
１２０ ＡＰＰサーバ
１２２ ＡＰＰサーバ処理部
１２４ 設定記憶部
１３０ ＨＴＴＰサーバ
１３２ サーバ通信部
１３４ 履歴処理部
１３６ サーバ履歴記憶部
２００ クライアント
２１０ クライアント通信部
２２０ 保存条件設定部
２３０ オーバーフロー確認部
２４０ データ取得処理部
２５０ データ記憶部

Claims (15)

1. ネットワークを介してデータを管理するサーバと接続され、
   前記サーバから取得した前記データを記憶するデータ記憶部と、
   前記サーバで記憶されている、前記サーバにおける前記データの変更内容を示す変更履歴情報の蓄積状態を確認する確認部と、
   前記確認部の確認結果に基づいて、前記変更履歴情報に従って前記データ記憶部に記憶されている前記データを前記サーバの管理する前記データと同期させる第１の取得方法と、前記サーバに存在する前記データを示すデータ存在情報を前記サーバから取得して前記データ記憶部に記憶されている前記データを同期させる第２の取得方法とのいずれの取得方法により前記データを取得するかを決定し、前記サーバから前記データを取得するデータ取得処理部と、
   を備える、情報処理装置。
2. 前記確認部は、前記サーバで蓄積された前記変更履歴情報の数が所定の履歴数を超えているかを確認し、
   前記データ取得処理部は、
   前記サーバで蓄積された前記変更履歴情報が前記所定の履歴数以下であるとき、前記第１の取得方法を用いて前記データを取得し、
   前記サーバで蓄積された前記変更履歴情報が前記所定の履歴数より多いとき、前記第２の取得方法を用いて前記データを取得する、請求項１に記載の情報処理装置。
3. 前記データ記憶部には、当該データ記憶部で保持する前記データに関する情報であるクライアントデータ情報が記憶されており、
   前記データ取得処理部は、前記第２の取得方法により前記データを取得するとき、前記データ存在情報と前記クライアントデータ情報とを比較して、前記サーバにて更新されたデータのみを前記サーバから取得する、請求項２に記載の情報処理装置。
4. 前記データ取得処理部は、前記第２の取得方法により前記データを取得するとき、
   前記データ存在情報と前記クライアントデータ情報とを比較して、前記情報処理装置にのみ存在するデータを特定し、
   前記情報処理装置にのみ存在するデータを前記データ記憶部から削除する、請求項３に記載の情報処理装置。
5. 前記データ取得処理部は、前記クライアントデータ情報に含まれる、前記情報処理装置にて変更され、かつ前記サーバへ未送信のデータを示す送信状態情報に基づいて、前記情報処理装置にて変更されたデータに同期して前記サーバで管理されるデータを更新するための情報を、前記サーバへ送信する、請求項３に記載の情報処理装置。
6. 前記データ取得処理部は、前記変更履歴情報をデータ単位で集約し、集約された前記変更履歴情報に基づいて、前記サーバから前記データを取得する、請求項１に記載の情報処理装置。
7. 前記データ取得処理部は、時系列に並んだ前記変更履歴情報を所定のデータ数で分割し、分割された前記変更履歴情報ごとに前記サーバから前記データを取得する、請求項１に記載の情報処理装置。
8. ネットワークを介して接続され、データを管理するサーバで記憶されている、前記サーバにおける前記データの変更内容を示す変更履歴情報の蓄積状態を確認するステップと、
   前記変更履歴情報の蓄積状態の確認結果に基づいて、前記変更履歴情報に従って前記サーバから取得した前記データを記憶するデータ記憶部に記憶されている前記データを前記サーバの管理する前記データと同期させる第１の取得方法と、前記サーバに存在する前記データを示すデータ存在情報を前記サーバから取得して前記データ記憶部に記憶されている前記データを同期させる第２の取得方法とのいずれの取得方法により前記データを取得するかを決定するステップと、
   決定された前記取得方法により、前記サーバから前記データを取得するステップと、
   を含む、情報処理方法。
9. データを記憶するデータ記憶部と、
   変更情報に基づいて、前記データ記憶部に記憶された前記データを変更するデータ変更部と、
   前記データ変更部により変更された前記データの変更内容を示す変更履歴情報を記憶するサーバ履歴記憶部と、
   前記サーバ履歴記憶部に記憶する前記変更履歴情報の上限蓄積量を記憶する設定記憶部と、
   前記上限蓄積量に基づいて前記サーバ履歴記憶部に記憶する前記変更履歴情報の蓄積量を管理する管理部と、
   ネットワークを介して接続されたクライアントからの要求に応じて、前記クライアントへ送信する前記データまたは前記変更履歴情報を取得し、前記データ記憶部に記憶された前記データに基づいて前記データ記憶部に存在する前記データを示すデータ存在情報を作成する情報処理部と、
   前記情報処理部により取得された前記データ、前記変更履歴情報、または作成された前記データ存在情報を前記クライアントへ送信するサーバ通信部と、
   を備える、データ管理サーバ。
10. 前記管理部は、前記サーバ履歴記憶部に記憶された前記変更履歴情報の蓄積量が前記上限蓄積量を超えたとき、前記変更履歴情報の蓄積を停止する、請求項９に記載のデータ管理サーバ。
11. 前記管理部は、前記サーバ履歴記憶部に記憶された前記変更履歴情報の蓄積量が前記上限蓄積量を超えたとき、前記変更履歴情報の蓄積量が前記上限蓄積量を超えたことを示すオーバーフロー判定情報を前記データ履歴記憶部に記録する、請求項１０に記載のデータ管理サーバ。
12. 前記情報処理部は、前記データ記憶部より前記データを取得し、前記サーバ存在情報を作成する第１の処理部と、前記サーバ履歴記憶部より前記変更履歴情報を取得する第２の処理部と、を備え、
    前記サーバ通信部は、前記クライアントから前記変更履歴情報の送信要求を受けたとき、前記第２の処理部に前記サーバ履歴記憶部から前記変更履歴情報を取得させる、請求項９に記載のデータ管理サーバ。
13. 前記サーバ履歴記憶部は、前記ネットワークを介して接続されたクライアントごとに前記変更履歴情報を記憶する、請求項９に記載のデータ管理サーバ。
14. 変更情報に基づいて、データを記憶するデータ記憶部に記憶された前記データを変更するステップと、
    変更された前記データの変更内容を示す変更履歴情報をサーバ履歴記憶部に記憶するステップと、
    前記サーバ履歴記憶部に記憶する前記変更履歴情報の上限蓄積量に基づいて前記サーバ履歴記憶部に記憶する前記変更履歴情報の蓄積量を管理するステップと、
    ネットワークを介して接続されたクライアントからの要求に応じて、前記クライアントへ送信する前記データまたは前記変更履歴情報を取得するステップと、
    前記クライアントからの要求に応じて、前記データ記憶部に記憶された前記データに基づいて前記データ記憶部に存在する前記データを示すデータ存在情報を作成するステップと、
    取得した前記データ、前記変更履歴情報、または作成した前記データ存在情報を前記クライアントへ送信するステップと、
    を含む、情報処理方法。
15. ネットワークを介して接続されたサーバとクライアントとのデータを同期する、データ同期システムであって、
    前記サーバは、
    前記データを記憶するデータ記憶部と、
    変更情報に基づいて、前記データ記憶部に記憶された前記データを変更するデータ変更部と、
    前記データ変更部により変更された前記データの変更内容を示す変更履歴情報を記憶するサーバ履歴記憶部と、
    前記サーバ履歴記憶部に記憶する前記変更履歴情報の上限蓄積量を記憶する設定記憶部と、
    前記上限蓄積量に基づいて前記サーバ履歴記憶部に記憶する前記変更履歴情報の蓄積量を管理する管理部と、
    ネットワークを介して接続されたクライアントからの要求に応じて、前記クライアントへ送信する前記データまたは前記変更履歴情報を取得し、前記データ記憶部に記憶された前記データに基づいて前記データ記憶部に存在する前記データを示すデータ存在情報を作成する情報処理部と、
    前記情報処理部により取得された前記データ、前記変更履歴情報、または作成された前記データ存在情報を前記クライアントへ送信するサーバ通信部と、
    を備え、
    前記クライアントは、
    前記サーバから前記データ、前記変更履歴情報および前記データ存在情報を受信するクライアント通信部と、
    前記サーバから取得した前記データを記憶するデータ記憶部と、
    前記サーバで記憶されている前記変更履歴情報の蓄積状態を確認する確認部と、
    前記確認部の確認結果に基づいて、前記変更履歴情報に従って前記データ記憶部に記憶されている前記データを前記サーバの管理する前記データと同期させる第１の取得方法と、前記サーバに存在する前記データを示すデータ存在情報を前記サーバから取得して前記データ記憶部に記憶されている前記データを同期させる第２の取得方法とのいずれの取得方法により前記データを取得するかを決定し、前記サーバから前記データを取得するデータ取得処理部と、
    を備える、データ同期システム。
    

Images