JP2011257959A

JP2011257959A - 差分検索システム

Info

Publication number: JP2011257959A
Application number: JP2010131475A
Authority: JP
Inventors: Kei Yamaji; 圭山地; Mototaka Kanematsu; 基孝金松
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2010-06-08
Filing date: 2010-06-08
Publication date: 2011-12-22

Abstract

【課題】通信量が少なくデータを更新できる技術を提供する。
【解決手段】第１データベースを備え、データの変更履歴をバージョンで管理しているサーバと、通信回線網を介して前記サーバと接続され、前記サーバに同期して取得したデータとバージョンで構成される第２データベースを備えたクライアントとから成るクライアントサーバ型システムの検索システムであって、前記クライアントは、第１のネットワーク環境下では更新通知のみ前記サーバに送信し、前記第１のネットワーク環境より通信に有利な環境である第２のネットワーク環境下では、前記サーバに更新データを送信して、前記第１データベース及び前記第２データベースの同期を実行する差分検索システム。
【選択図】図４１

Description

本発明は、差分検索システムに関する。

最近、家電機器等において、組込み機器製品が高機能化し、機器自体がサーバになるこ
とが求められている。一方、サーバを利用するクライアント機器は、サーバ機器同様もし
くはそれ以上の性能を有することが多いが、それら機器を取り巻くネットワーク環境にお
いては、まだまだ十分とはいえない。クライアント機器は高性能であるが、サーバ機器は
さほど高性能でなく、ネットワーク環境は低水準にあるのが、現状である。

ネットワーク環境が高速かつ安価な時には、クライアント機器とサーバ間で、データベースの保有データを共通化するために、同期をとるのが望ましい。

クライアント機器とサーバ間で更新通知を行い、データベース内容の同期を図る従来技術として、Web検索の結果が毎回違うので、前回を覚えておき、差分を検出して表示する技術(例えば、特許文献１)、アクティブモードとパワーセーブモードの切り替えを最適化して、最適な受信と省電力化を図る技術(例えば、特許文献２）が提案されている。

特開２００６−３０１９７５号公開公報特開２００９−２０６７６２号公開公報

同期をとる際、例えば有線の利用が可能な状況では、通信上の問題は生じないが、クライアント機器がサーバから遠く離れている場合には、通信費用やトラフィック等の問題がネックとなる。従来の技術では、サーバから遠く離れている場合の通信費用やトラフィック等の問題が解決されなかった。

具体的には、ネットワーク環境が、高速な時・安価な時、例えば充電中とか、有線、内部ネットワーク内に入った時などにはデータベースを同期をしても問題ないが、低速で高価なとき（携帯電話による通信など）には、通信費用やトラフィック等の問題がネックとなる。
本発明の目的は、通信量が少なくデータを更新できる技術を提供することにある。

上記課題を解決する手段として、本発明は以下の特徴を有する。
本発明は、第1データベースを備え、データの変更履歴をバージョンで管理しているサーバと、通信回線網を介して前記サーバと接続され、前記サーバに同期して取得したデータとバージョンで構成される第２データベースを備えたクライアントとから成るクライアントサーバ型システムの検索システムであって、前記クライアントは、第１のネットワーク環境下では更新通知のみ前記サーバに送信し、前記第１のネットワーク環境より通信に有利な環境である第２のネットワーク環境下では、前記サーバに更新データを送信して、前記第1データベース及び前記第2データベースの同期を実行することを特徴とする差分検索システムであることを特徴としている。

本発明によれば、通信量が少なくデータを更新できる技術を提供することができる。

本発明の実施形態に係るクライアントサーバシステムの構成例を示す概念図である。本発明の実施形態に係るクライアントサーバシステムの機能ブロック図である。第１の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新およびバージョンを説明するための模式図である。情報端末装置の情報管理装置に対する要求処理の流れを示すフローチャートである。情報管理装置のユーザである情報端末装置の更新要求処理の流れを示すフローチャートである。データベースの構造(中身）を模式化した図である。データ量の比較を模式化した図である。データ量の比較を模式化した図である。データ量の比較を模式化した図である。データ量の比較を模式化した図である。変更履歴の追加がなされた場合のデータベースの構造（中身）の変化を例示する図である。変更発生時の変更履歴欄の更新処理の流れを示すフローチャートである。同期処理におけるデータベースの構造（中身）の変化を例示する図である。無効化処理におけるデータベースの構造（中身）の変化を例示する図である。探索要求時におけるデータベースの構造（中身）の変化を例示する図である。探索実行におけるデータベースの構造（中身）の変化を例示する図である。情報管理装置側における差分把握処理の流れを示すフローチャートである。情報端末装置側における差分除去処理の流れを示すフローチャートである。情報端末装置側における差分検索処理の流れを示すフローチャートである。情報管理装置における差分検索処理の流れを示すフローチャートである。変更履歴を用いた差分データからの検索処理を説明する図である。第２の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新およびバージョンを説明するための模式図である。変更発生時の変更履歴欄の更新処理の流れを示すフローチャートである。変更発生時の変更履歴欄の更新処理の流れを示すフローチャートである。変更発生時の変更履歴欄の更新処理の流れを示すフローチャートである。更新要求を受けつけた後の変更履歴処理全体の流れを示すフローチャートである。第３の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新およびバージョンを説明するための模式図である。変更発生時の変更履歴欄の更新処理の流れを示すフローチャートである。変更履歴の上位概念によるまとめ処理の流れを示すフローチャートである。第４の実施形態に係るクライアントサーバ型検索システムを説明する図である。情報管理装置における差分検索処理の流れを示すフローチャートである。第５の実施形態に係るクライアントサーバ型検索システムを説明する図である。情報管理装置における差分検索処理の流れを示すフローチャートである。送信データの決定処理の流れを示すフローチャートである。Ａ）は、ネットワーク環境が弱い状況下でのサーバ、クライアントＢを示した図、ネットワーク環境が強い状況下でのサーバ、クライアントＢを示した図である。図３５に示したクライアントＢがサーバに更新通知を行った後、別のクライアントであるクライアントＡがサーバに検索要求を行ったときの動作を示す図である。クライアント同士が通信可能である場合の同期実行前検索時のシステムの動作例を示す図である。クライアント同士が通信可能である場合の同期実行前検索時のシステムの別の動作例を示す図である。クエリキャッシュを利用した場合の、図３５に示したクライアントＢがサーバに更新通知を行った後、別のクライアントであるクライアントＡがサーバに検索要求を行ったときの動作を示す図である。図３８の状態の後、さらに別のクライアントＣがクライアントＡと同じ検索要求をした場合の本検索システムの動作例を示す図である。本システムの基本的な動作の概要を示した図である。更新要求クライアントによる遠距離更新時のユーザ更新要求の処理例を示したフローチャートである。サーバによる遠距離更新時のユーザ更新要求受付の例を示したフローチャートである。検索要求クライアントによる検索実行の例を示したフローチャートである。サーバによるユーザ参照要求受付の例を示したフローチャートである。ステップＳ４４０１のより具体的な処理内容を示したフローチャートである。サーバによる差分検索要求、更新要求クライアントによる差分検索応答の処理例を示したフローチャートである。新要求クライアントによる更新要求、サーバによるユーザ更新要求受付処理例を示したフローチャートである。

[差分検索システム]
まず、本発明の基本となる差分検索システムについて説明する。
図１は、本発明の実施形態に係るクライアントサーバシステムの構成例を示す概念図である。図１に示すように、クライアントサーバシステム１００は、サーバとなる情報管理装置２と、例えばインターネット網あるいは無線通信網３でクライアント機器となる情報端末装置１とから構成されている。情報管理装置（以下の説明では、サーバとも称する）２は、図１に示すように、データベース２４に接続されている。データベース２４は、都度、更新され、現在のバージョンと変更履歴が管理されている。情報管理装置２は、専用機器である必要は無い。所謂、家電機器と称される機器であってもネットワーク網に繋がり、バージョンの管理ができてサーバ機能を果たすものであればよい。さらに変更履歴は、各バージョンとそのバージョンで対象となるデータのＩＤとで把握されるようになっている。これらの詳細については、後述する。

情報端末装置（以下の説明では、クライアントとも称する）１は、データベース機能を備えるものであれば、携帯電話や携帯プレーヤが好適である。所謂、ウルトラモバイルＰＣと称されるものである。図１に示すように、各情報端末装置１も、それぞれデータベース１４に接続されているが、データベース１４は、情報管理装置２のデータベース２４と同期したときのバージョンとなっている。

図２は、本発明の実施形態に係るクライアントサーバシステム１００の機能ブロック図である。情報管理装置２は、接続部２１とデータベース２４を備え、情報端末装置１の要求を受け、結果を送信する。接続部２１は、インターネット網を介して、情報端末装置１と通信をする。情報端末装置１は、ユーザインターフェース１０と接続部１１及びデータベース１４を備える。ユーザインターフェース１０は、ユーザの要求を受け、結果を表示するものである。接続部１１は、インターネット網を介して、情報管理装置２と通信をする。

更に、情報管理装置２は、命令制御部２２とSQL実行部２３を有している。命令制御部２２は、情報端末装置１の要求に応じて、SQL実行部２３や接続部２１に命令を出し、結果をユーザインターフェース１０に表示する。命令としては、接続受付、差分通知、SQL受付、結果送信、同期送信、接続停止がある。SQL実行部２３は、データベース２４に対する命令であるSQL文を用いて、命令制御部２２からの要求にしたがってデータベース２４への操作や定義づけを行うものである。データベース２４は、情報端末装置１から操作によって追加・変更・削除されたデータ２４１と変更履歴２４３とバージョン２４２を保有する。更に、情報端末装置１は、命令制御部１２とSQL実行部１３を有している。命令制御部１２は、ユーザインターフェース１０の要求に応じて、SQL実行部１３や接続部１１に命令を出し、結果をユーザインターフェース１０に表示する。命令としては、接続開始、差分除去、差分検索、結果取得、同期受信、接続終了がある。詳細は後述する。SQL実行部１３は、データベース１４に対する命令であるSQL文を用いて、命令制御部１２からの要求にしたがってデータベース１４への操作を行うものである。データベース１４は、情報管理装置２と同期して取得したデータ１４１とバージョン１４２を保有する。本実施形態で使用する用語は、特にことわりのない場合、以下の意味で理解する。「同期」とは、サーバとクライアント機器との間で、データベース内のデータを共有している状態、もしくは共有化するための処理を意味する。「差分把握」とは、クライアントとサーバのデータの差分を互いのバージョンから把握し、検索処理において重複したデータを検索しないようにすることである。「差分検索」とは、差分データ、すなわち同期がとれていないデータに対する検索をいい、サーバが実行するものである。因みに、差分があるかどうか検索するわけではない。「変更履歴」とは、データベース内のデータについて変更履歴で変更した差分を管理する。変更履歴は、「バージョン」と「データＩＤ」の組を持っている。「バージョン」とは、サーバ側で一意に発行する数字で、データベース内のデータについて変更が行われたらバージョンが１つあがる。本実施形態において「バージョン」は、「差分把握」および「差分検索」を簡単にする為の仕組みである。

以下、いくつかの実施形態に分けて説明する。
（第１の実施形態）
図３は、第１の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新およびバージョンを説明するための模式図である。クライアント機器である情報端末装置１はサーバである情報管理装置２において、データベースの更新が行われると、現在のバージョンに対して１つインクリメント（バージョンを＋１する）とされる。更新の内容は変更履歴として管理される。変更履歴は、バージョンと対象となるデータのＩＤから成り立っている。更新に併せて、差分把握可能範囲が設定される。この差分把握可能範囲は、言わば、差分検索が可能な範囲を意味する。極端に古いバージョンのデータベースしか保持していないクライアント機器をケアする場合に対応するためのものである。クライアント機器が自ら保有しているデータベースに対して検索を行う際に、既にサーバ側ではデータベースが更新された結果、削除あるいは変更済みのデータが未だ存在している可能性がある。これら削除あるいは変更済みのデータに対して検索を行うことは全く無意味である。そこで、クライアント機器が自ら保有しているデータベースに対して検索を行う前に、クライアント機器において、該当データの「無効化処理」を行う。「無効化処理」は、サーバで「差分把握」を行い、クライアント機器はサーバから該当するデータＩＤを受け取って「無効化処理」をする。「差分検索」では、情報管理装置と情報端末装置間で、それぞれのデータベースのデータに差分が存在するか否か問い合わせを行う。情報管理装置は「変更履歴」から差分データについて検索して、情報端末装置に検索結果を送信する。

図４は、上記のように構成された検索システムにおけるユーザである情報端末装置の情報管理装置に対する要求処理の流れを示すフローチャートである。まず、情報管理装置は情報端末装置からの接続処理を行う（ステップＳ４１）。情報管理装置は、処理がまだあるか否かを判断する（ステップＳ４２）。処理がなければ、情報端末装置との接続を解除する接断処理を実行する（ステップＳ４６）。処理があれば（ＹＥＳならば）、更新処理か否かを判断する（ステップＳ４３）。ＹＥＳならば、更新処理を実行する（ステップＳ４４）。ＮＯであれば、検索処理を実行する（ステップＳ４５）。更新処理あるいは検索処理の実行後は、ステップＳ４２に戻る。

図５は、情報管理装置のユーザである情報端末装置の更新要求処理の流れを示すフローチャートである。情報管理装置は情報端末装置からデータの更新要求を受付、更新処理を実行する（ステップＳ５１）。更新に伴い、情報管理装置は変更履歴を更新する（ステップＳ５２）。データの更新要求に対する結果が返却され（ステップＳ５３）、更新完了が情報管理装置から情報端末装置に返される。

図６は、データベースの構造(中身）を模式化した図である。図６に示すデータベースは、“Ｔａｂｌｅ”、“Ｐａｇｅ”、“ｎｏｄｅ”と階層化されている。例えば、図書館に収蔵されている“本”のデータベースを考えると、“Ｔａｂｌｅ”は“市立図書館”であり、“Ｐａｇｅ”は“本棚”であり、“ｎｏｄｅ”は個々の“本”に該当する。いま、サーバのデータベースが更新され、バージョンは“３”となり、当該更新によって、“ｎｏｄｅ４”が“ＰａｇｅＢ”の本棚から、取り除かれた。クライアントのバージョンは“１”であり、サーバのバージョンとは一致していない。

このような状況のもとで、データの検索処理の流れについて説明する。まず、クライアント機器がサーバに対して、現在のバージョンの問い合わせを行う。バージョンの問い合わせを受けたサーバは変更履歴を確認し、変更したノードを探索する。すると、サーバはバージョン３となっており、“ｎｏｄｅ４”が変更されているので、クライアント機器に対して、差分把握として“ｎｏｄｅ４”が削除されているデータであることを知らせる。“ＰａｇｅＢ”との差分把握を受け取ったクライアント機器は、自らのデータベースから“ｎｏｄｅ４”に対して無効化する。クライアント機器は、無効処理後のデータベースについて全件探索を行う。一方、サーバでは、クライアント機器のバージョン１との差分データである“ｎｏｄｅ４”に対して全件探索、すなわち“ｎｏｄｅ４”に対して検索条件を満たすかどうかを判定する差分検索を行う。この差分検索の結果を受領したクライアント機器は、最新のデータベースに対する検索結果を得ることができる。

最新のデータについて検索を行うには、サーバおよびクライアント機器間で、必ず通信が必要である。差分把握、差分検索によれば、完全同期やサーバ全問い合わせに比べて格段に小さな通信量で、最新のデータに対する検索が実現できる。一般的に、完全同期データ量≧差分検索結果データ量であり、かつ、全件検索結果データ量≧差分検索結果データ量であることによる。これら、データ量の比較を模式化したものを図７乃至図１０に示す。図７は、サーバとクライアント機器が近距離に位置し、しかも両者間の通信環境が高速通信を行える状況であることを例示している。この場合には、両者のデータベースの更新は、完全同期させるのが好適である。尚、差分同期であっても支障はないといえる。図８は、クライアント機器では検索せずにサーバに検索を委ねる、全問い合わせの状況であることを例示している。この場合には、サーバは１Ｇバイトのデータ容量のデータベースに対して検索を実行し、１Ｍバイトの検索結果を得ている。したがって、ヒット率：ｈ＝０．１％となる。ここでは、検索結果がそのまま、クライアント機器に送られるが、通信容量はさほど大きくないので、低速通信であっても支障は無いといえる。図９は、サーバとクライアント機器との間で、差分データについて同期をとることを例示している。サーバのデータベースが更新された結果、更新前後の差分データが１Ｍバイトである状況を例示している。１Ｍバイトの差分データの更新前のデータベースに対する差分割合は０．１％となる。１Ｍバイトの差分データは、通信容量としてはさほど大きくないので、低速通信であっても支障は無いといえる。クライアント機器は、受け取った１Ｍバイトの差分データを加えた１Ｇバイトのデータベースに対して検索を実行し、１Ｍバイトの検索結果を得ている。次に、図１０は、差分検索を例示している。サーバからクライアント機器に対して差分ＩＤ群として１００バイトが送られる。この差分ＩＤ群とは、無効化処理すべきデータのＩＤのまとまりを意味している。さらに、サーバは、変更履歴に基づいて差分データ１Ｍバイトを抽出し、クライアント機器のために差分検索を実行する。得られた１Ｋバイト差分検索の結果は、クライアント機器に送られる。一方、クライアント機器は、差分ＩＤ群に基づいて自己のデータベースを更新して、検索を実行する。クライアント機器は、差分検索の結果１Ｋバイトと併せて、１Ｍバイトの検索結果を得ている。例えば、１つのデータ長が４０００ビット、データＩＤ長が４ビットとすると、あるＩＤを特定するためには、１／１０００の情報量で済むことになる。したがって、差分ＩＤ群および差分検索結果のデータ容量は、極めて少ない量となるから、低速通信であっても何等支障は無く、特に１つのデータが大きく、差分割合が少ない時に好適である。

次に、上記した処理に伴い、データベースの構造（中身）がどのように変化していくか、図を用いて例示する。図１１は、変更履歴の追加がなされた場合のデータベースの構造（中身）の変化を例示する。クライアント機器がデータベースを保有しており、同期させる場合の処理である。いま、サーバのデータベースに対して、”ＰａｇｅＢ“に“ｎｏｄｅ４”を追加する変更が行われた。かかる変更に伴い、変更履歴欄には、最新のバージョンは“３”から”Ｖｅｒ＝４”に、その変更内容として、“ｎｏｄｅ４”が更新されている。図１２は、変更発生時の変更履歴欄の更新処理の流れを示すフローチャートである。図１２に示すように、変更したノード＝ｎｏｄｅ４が変更履歴欄に追加されている。そして、バージョンを＋１している。図１３は、同期処理におけるデータベースの構造（中身）の変化を例示する。サーバのバージョンは“４”であるのに対し、クライアント機器のバージョンは“３”である。そこで、変更履歴から更新後の“ｎｏｄｅ４”のデータが、サーバのバージョン情報と共に、クライアント機器に送られる。クライアント機器では、“ｎｏｄｅ４”の内容を更新する。

図１４は、無効化処理におけるデータベースの構造（中身）の変化を例示する。クライアント機器のバージョンは“３”である。サーバは、変更履歴から自身の現在のバージョン“４”と、その変更内容である“ｎｏｄｅ４”の削除を確認する。サーバのバージョン情報および差分ＩＤ群情報は、クライアント機器に送られる。クライアント機器では、保有するデータベースに対してバージョン“４”の内容を反映させるために、バージョン“３”との差分である“ｎｏｄｅ４”を削除する。

図１５は、探索要求時におけるデータベースの構造（中身）の変化を例示する。サーバのデータベースに対するＳＥＬＥＣＴは、ＳＥＬＥＣＴ文ＷＨＥＲＥＶｅｒ＞３ＡＮＤＶｅｒ≦４となる。バージョン“３”でのデータベースに対する探索（検索）は、クライアント機器自身に割り当て、バージョン“４”を反映した探索（検索）は、サーバに割り当てられる。

図１６は、探索実行におけるデータベースの構造（中身）の変化を例示する。図１６に示すように、サーバのデータベースに対して、ＳＥＬＥＣＴ文ＷＨＥＲＥＶｅｒ＞３ＡＮＤＶｅｒ≦４で表わされる命令が発せられると、バージョン“４”の変更内容である“ｎｏｄｅ４”に対して検索を実行し、検索結果Ｓをクライアント機器に送る。一方、クライアント機器は、ＳＥＬＥＣＴ文によりバージョン“３”でのデータベースに対する検索を実行し、検索結果Ｃを得る。したがって、検索結果Ｃ＋検索結果Ｓが、最新のデータに対する検索結果として得ることができる。

次に、検索システムにおける情報管理装置と情報端末装置で実行される各処理の流れについて詳述する。

図１７は、情報管理装置側における差分把握処理の流れを示すフローチャートである。まず、情報端末装置のバージョン：Ｖｃを取得する（ステップＳ１７０１)。次いで、情報管理装置のバージョン：Ｖｓを取得する（ステップＳ１７０２)。次いで、両者のバージョンを比較する（ステップＳ１７０３)。Ｖｃ＝Ｖｓであれば、Ｖｓと結果：Ｒ＝「変更データ無し」を情報端末装置に通知する（ステップＳ１７０５)。Ｖｃ＝Ｖｓでなければ、変更履歴から差分把握可能範囲：Ｖａを取得する（ステップＳ１７０４)。次いで、Ｖａ＞Ｖｃかどうかを判断する（ステップＳ１７０６)。Ｖａ＞Ｖｃであれば、結果：Ｒ＝「差分検索不可」を情報端末装置に通知する（ステップＳ１７１１)。Ｖａ＞Ｖｃでなければ、データベースから変更履歴を使い、差分ＩＤsを作成する（ステップＳ１７０７)。次いで、変更が削除のみかどうかを判断する（ステップＳ１７０８)。変更が削除のみでなければ、Ｖｓと差分ＩＤ：ＩＤsを情報端末装置に通知する（ステップＳ１７０９)。変更が削除のみであれば、結果：Ｒ＝「差分削除のみ」Ｖｓと差分ＩＤ：ＩＤｓを情報端末装置に通知する（ステップＳ１７１０)。

図１８は、情報端末装置側における差分除去処理の流れを示すフローチャートである。まず、情報管理装置の差分ＩＤの結果：Ｒを取得する（ステップＳ１８０１)。次いで、Ｒ＝「差分削除のみ」かどうかを判断する（ステップＳ１８０２)。Ｒ＝「差分削除のみ」であれば、差分ＩＤｓを取得する（ステップＳ１８０３)。続いて、ＩＤｓに対応するデータをデータベースから削除する（ステップＳ１８０４)。続いて、サーバフラグ＝ＯＦＦと設定する（ステップＳ１８０５)。このサーバフラグは、サーバに検索要求をする必要があるか否かを示すもので、サーバに検索要求をする場合、ＯＮとなる。続いて、Ｖｃ＝Ｖｓとする（ステップＳ１８０６)。そして、差分把握完了フラグ＝ＯＮとする（ステップＳ１８０７)。一方、Ｒ＝「差分削除のみ」でない場合には、まず、Ｒ＝「差分検索不可」かどうかを判断する（ステップＳ１８０８)。Ｒ＝「差分検索不可」でなければ、続いて、Ｒ＝「変更データ無し」かどうかを判断する（ステップＳ１８０９)。Ｒ＝「変更データ無し」でなければ、差分ＩＤｓを取得する（ステップＳ１８１０)。続いて、ＩＤsに対応するデータをデータベースから削除する（ステップＳ１８１１)。続いて、サーバフラグ＝ＯＮと設定（ステップＳ１８１２)した後、ステップＳ１８０７に移る。一方、Ｒ＝「差分検索不可」の場合には、サーバフラグ＝ＯＮと設定（ステップＳ１８１３)。続いて、Ｖｃ＝０と設定（ステップＳ１８１４)した後、ステップＳ１８０７に移る。また、Ｒ＝「変更データ無し」の場合には、サーバフラグ＝ＯＦＦと設定する（ステップＳ１８１５)。続いて、Ｖｃ＝Ｖｓと設定（ステップＳ１８１６)した後、ステップＳ１８０７に移る。

図１９は、情報端末装置側における差分検索処理の流れを示すフローチャートである。まず、差分把握完了フラグ＝ＯＮかどうか判断する（ステップＳ１９０１)。差分把握完了フラグ＝ＯＮでなければ、接続処理（情報管理装置にＶｃを渡す）を行う（ステップＳ１９０２)。続いて、差分ＩＤの送受信を行い（ステップＳ１９０３)、差分ＩＤの除去を実行する（ステップＳ１９０４)。一方、差分把握完了フラグ＝ＯＮであれば、Ｖｃ≠０かどうか判断する（ステップＳ１９０５)。Ｖｃ≠０であれば、情報端末装置のデータベースから検索を実行する（ステップＳ１９０６)。次いで、サーバフラグ＝ＯＮかどうか判断する（ステップＳ１９０７)。一方、Ｖｃ≠０でなければ、直ちにステップＳ１９０７のサーバフラグ＝ＯＮかどうかの判断に移る。サーバフラグ＝ＯＮであれば、情報管理装置から検索を行う（ステップＳ１９０８)。そして、検索結果を表示する（ステップＳ１９０９)。図２０は、情報管理装置における差分検索処理の流れを示すフローチャートである。まず、情報管理装置への検索要求は、情報端末装置側でＶｃとＶｓを用いてＳＱＬ文を作成し（ステップＳ２００１)、ＳＱＬ文を情報管理装置側へ送信する（ステップＳ２００２)。情報管理装置側では、ＳＱＬ文を受信する（ステップＳ２００３)と、変更履歴を用いて差分データから検索を実行する（ステップＳ２００４)。情報管理装置は、検索結果を送信し（ステップＳ２００５)、情報端末装置は検索結果を取得する（ステップＳ２００６)。図２１は、上記したステップＳ２００４の変更履歴を用いた差分データからの検索処理を説明する図である。情報管理装置は、ＳＥＬＥＣＴＷＨＥＲＥ２＜ＶｅｒＡＮＤＶｅｒ≦４とのＳＱＬ文を受信すると（ステップＳ２１０１)、ＳＥＬＥＣＴ文を実行する（ステップＳ２１０２)。図２１に示す例では、変更履歴から、バージョン３ではｎｏｄｅ２に変更を加え、バージョン４ではｎｏｄｅ４に変更が加えられている。よって、情報管理装置が実行すべき差分検索は、ｎｏｄｅ２、ｎｏｄｅ４のみを検索対象とすることがわかる。したがって、検索に要する時間も極めて短時間である。このように、本実施形態によれば、差分処理なので検索対象が少なくて済み、差分検索結果のデータサイズは差分データサイズよりもはるかに小さいのでサーバの処理量が著しく減少させることができ、多くのクライアント機器をケアすることができる。さらに、バージョン管理により、効率よく最新データの把握ができる。

クライアント側では検索のための事前処理として無効化処理するので、効率的な検索が可能となる。また、サーバの処理量が少ないので、高性能でない機器でもデータベースサーバとして使用することができるので、低廉な検索システムを構築することができる。

（第２の実施形態）
図２２は、第２の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新およびバージョンを説明するための模式図である。第２の実施形態では、言わば、変更履歴を管理するために必要となるメモリの削減をその狙いとするものである。そのため、（１）変更履歴欄がいっぱいであれば、古いものを削除する、（２）変更履歴欄に同じデータＩＤが存在していたら、最新のものにまとめる、（３）変更履歴で把握できる範囲外のバージョンならば、あえて差分検索しない等を骨子としている。図２３は、変更発生時の変更履歴欄の更新処理であって、削除のみの変更の場合の流れを示すフローチャートである。まず、変更したノード＝ｎｏｄｅ４が変更履歴欄に追加されている（ステップＳ２３０１)。次いで、変更内容が削除以外にないかどうか判定する（ステップＳ２３０２)。ＹＥＳであれば、ＤＥＬＥＴＥＯＮＬＹフラグをＯＮにする（ステップＳ２３０３)。ここでは、ｎｏｄｅ４を削除するのみの変更が、バージョン“３”として、行われ、ＤＥＬＥＴＥＯＮＬＹフラグをＯＮにしている。次いで、バージョンを＋１している（ステップＳ２３０４)。図２４は、変更発生時の変更履歴欄の更新処理であって、データを節約する場合の流れを示すフローチャートである。まず、変更したノード＝ｎｏｄｅ４が変更履歴欄に追加されている（ステップＳ２４０１)。次いで、変更履歴に同じデータＩＤが存在するかどうか判定する（ステップＳ２４０２)。ＹＥＳであれば、変更履歴の古いものを削除する（ステップＳ２４０３)。ここでは、ｎｏｄｅ４を対象とする変更が過去においてバージョン“２”でなされているので、バージョン“２”の履歴を削除し、ｎｏｄｅ４を対象とする変更履歴をバージョン“４”のものにまとめている。次いで、バージョンを＋１している（ステップＳ２４０４)。図２５は、変更発生時の変更履歴欄の更新処理であって、古い差分情報は削除する場合の流れを示すフローチャートである。まず、変更したノード＝ｎｏｄｅ４が変更履歴欄に追加されている（ステップＳ２５０１)。次いで、変更履歴がいっぱいかどうか判定する（ステップＳ２５０２)。ＹＥＳであれば、古い差分情報を削除する（ステップＳ２５０３)。ここでは、ｎｏｄｅ１２を対象とするバージョン“１”の変更履歴を消すことになる。バージョン“１”の変更履歴が消されと、変更履歴の最も古いバージョン：Ｖｏを差分把握可能範囲：Ｖａに代入する（ステップＳ２５０４)。ここでは、最も古いバージョンが“２”となり、差分把握可能範囲もバージョン“２”となっている。次いで、バージョンを＋１している（ステップＳ２５０５)。

図２６は、ユーザから更新要求を受けつけた後の変更履歴処理全体の流れを示すフローチャートである。
まず、更新要求の受付後、更新処理を実行する（ステップＳ２６０１)。次いで、変更したノードを変更履歴に追加する（ステップＳ２６０２)。次いで、サーバのバージョンを＋１し、Ｖｓ＝Ｖｓ＋１と設定する（ステップＳ２６０３)。続いて、変更内容は削除以外にないかを判断する（ステップＳ２６０４)。削除のみならば、ＤＥＬＥＴＥＯＮＬＹフラグをＯＮにする（ステップＳ２６０５)。フラグ設定後、変更履歴に同じＩＤがあるかを判断する（ステップＳ２６０６)。変更内容が削除以外にもある場合もステップＳ２６０６に移る。変更履歴に同じＩＤがあれば、変更履歴の古いものを削除する（ステップＳ２６０７)。削除後、変更履歴がいっぱいかどうかを判断する（ステップＳ２６０８)。変更履歴に同じＩＤがない場合もステップＳ２６０８に移る。変更履歴がいっぱいであれば、古い差分情報を削除し（ステップＳ２６０９)、変更履歴の最も古いバージョンを差分可能範囲に代入する（ステップＳ２６１０)。次いで、変更履歴を上位概念でまとめ（ステップＳ２６１１)、結果を返却する（ステップＳ２６１２)。変更履歴がいっぱいでない場合には、ステップＳ２６１１以降に移る。第２の実施形態によれば、第１の実施形態での効果に加えて、変更履歴の管理をより効率的に行うことができる。

（第３の実施形態）
図２７は、第３の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新およびバージョンを説明するための模式図である。第３の実施形態では、バージョンアップに伴う処理をより効率的に行うことに狙いがある。そのため、変更履歴の管理をより上位の概念で行う、例えば、図６のＴａｂｌｅ単位あるいはＰａｇｅ単位でまとめるものである。

図２８は、変更発生時の変更履歴欄の更新処理の流れを示すフローチャートである。まず、変更したノード＝ｎｏｄｅ４が変更履歴欄に追加されている（ステップＳ２８０１)。次いで、同じＰａｇｅに所属するものが一定値以上かどうか判定する（ステップＳ２８０２)。一定値以上であれば、同じＰａｇｅのＩＤを削除し（ステップＳ２８０３)、ＰａｇｅＩＤを追加する（ステップＳ２８０４)。ここでは、ｎｏｄｅ１２とｎｏｄｅ１３を対象とする変更履歴が、ＰａｇｅＡを変更対象とするバージョン“４”として上位概念化している。次いで、バージョンを＋１している（ステップＳ２８０５)。

図２９は、変更履歴の上位概念によるまとめ処理の流れを示すフローチャートである。まず、同じページのＩＤをカウントする（ステップＳ２９０１)。Ｐａｇｅでまとめられるかどうかを判断する（ステップＳ２９０２)。Ｐａｇｅでまとめられる場合には、同じページのＩＤを変更履歴から削除する（ステップＳ２９０３)。次いで、同じテーブルのＩＤをカウントする（ステップＳ２９０４)。Ｐａｇｅでまとめられない場合には、直ちにステップＳ２９０４に移る。次いで、Ｔａｂｌｅでまとめられるかどうかを判断する（ステップＳ２９０５)。Ｔａｂｌｅでまとめられる場合には、同じテーブルのＩＤを変更履歴から削除し（ステップＳ２９０６)、上位概念でのまとめを終了する。Ｔａｂｌｅでまとめられない場合にも、上位概念でのまとめを終了する。

尚、情報端末装置におけるバージョンアップを簡単にするための工夫として、差分把握に関してデータＩＤを受け取って、ＤＥＬＥＴＥＯＮＬＹのフラグをチェックし、フラグがたっているならば、差分データを受け取ったのと同じなのでバージョンアップし、あるいは、差分データを受け取ったら、反映し、バージョンアップするようにすることもできる。第３の実施形態によれば、バージョンアップに伴う処理をより効率的に行うことができる。

（第４の実施形態）
図３０は、第４の実施形態にかかる検索システムを説明する図である。第４の実施形態では、情報管理装置での検索結果の通信量のさらなる低減を図るもので、差分検索に関して、検索結果と差分データから同期判断し、同期したほうが良いと判断した場合には、同期データを送信し、かかる同期判断は段階的に行ってもよい、等を骨子としている。ここでは、図３０に示すように、差分データＤｓと、差分検索結果Ｒｓのデータサイズを比較する。図３１は、情報管理装置における差分検索処理の流れを示すフローチャートである。まず、情報管理装置への検索要求は、情報端末装置側でＶｃとＶｓを用いてＳＱＬ文を作成し（ステップＳ３１０１)、ＳＱＬ文を情報管理装置側へ送信する（ステップＳ３１０２)。情報管理装置側では、SQL文を受信する（ステップＳ３１０３)と、変更履歴を用いて差分データから検索を実行する（ステップＳ３１０４)。次いで、差分データサイズ：Ｓｄを取得する（ステップＳ３１０５）。続いて、検索結果データサイズ：Ｓｒを取得する（ステップＳ３１０６）。そして、差分データサイズ：Ｓｄと積分の差分検索データサイズ：ΣＳｒについて、Ｓｄ＞ΣＳｒかどうかを判断する（ステップＳ３１０６）。情報管理装置は、Ｓｄ＞ΣＳｒでなければ、検索結果の代わりに差分データを送信し（ステップＳ３１０８)、Ｓｄ＞ΣＳｒであれば検索結果を送信する（ステップＳ３１０９)。情報端末装置はデータを取得し（ステップＳ３１１０)、データが差分データかどうかを判断する（ステップＳ３１１１）。差分データであれば、差分データをデータベースにアップデートする（ステップＳ３１１２）。Ｖｃ＝Ｖｓとし（ステップＳ３１１３）、サーバフラグ＝ＯＦＦと設定する（ステップＳ３１１４）。

繰り返しの検索によって、検索結果データが差分データよりも大きくなってしまう可能性がある。そのような場合には、（積算の差分検索結果データサイズ）≦（差分データサイズ）となり、積算の差分検索結果データサイズを送信したほうが結果的にデータ量は少ないので、検索結果を送信した方が特である。一方、（積算の差分検索結果データサイズ）＞（差分データサイズ）ならば、差分データを送り、以降の通信量は無しとすることにより、本実施形態によれば、繰り返しによる通信量を低減することができる。尚、上述では、積算の検索結果データと差分データの大小関係による判定について説明したが、これに限られない。例えば、差分データの８０％で比較する、あるいは検索要求を予測するようにしてもよい。

（第５の実施形態）
第５の実施形態では、情報管理装置での検索結果の通信量のさらなる低減を図るものである。図３２は、第５の実施形態にかかる検索システムを説明する図である。ここでは、図３２に示すように、バージョンごとのデータで、差分データＤｓと、差分検索結果Ｒｓのトータルサイズを比較する。

図３３は、情報管理装置における差分検索処理の流れを示すフローチャートである。
まず、情報管理装置への検索要求は、情報端末装置側でＶｃとＶｓを用いてＳＱＬ文を作成し（ステップＳ３３０１)、ＳＱＬ文を情報管理装置側へ送信する（ステップＳ３３０２)。情報管理装置側では、ＳＱＬ文を受信する（ステップＳ３３０３)と、Ｎ＝Ｎ＋１とカウントアップ（ステップＳ３３０４)した後、変更履歴を用いて差分データから検索を実行し、データを作成する（ステップＳ３３０５)。情報管理装置は、情報端末装置に送信データ：S の送信を行う（ステップＳ３３０６)。情報端末装置はデータを取得し（ステップＳ３３０７)、データに差分データがあるかどうかを判断する（ステップＳ３３０８）。差分データがあれば、差分データをデータベースにアップデートする（ステップＳ３３０９）。Ｖｃ＝Vdと設定し（ステップＳ３３１０）、Ｖｃ＝Ｖｓかどうかを判断する（ステップＳ３３１１）。Ｖｃ＝Ｖｓであれば、サーバフラグ＝ＯＦＦとする（ステップＳ３３１２）。一方、データに差分データがない場合には、ステップＳ３３１２に移る。Ｖｃ＝Ｖｓでない場合には終了する。

次に、検索結果と同期データの比較による送信データの決定について説明する。図３４は、送信データの決定処理の流れを示すフローチャートである。まず、ｉ＝Ｖｃ＋１とする（ステップＳ３４０１）。次いで、Ｖｓ＝ｉかどうかを判断する（ステップＳ３４０２）。Ｖｓ＝ｉでなければ、ｉ＝ｉ＋1とし（ステップＳ３４０３）、バージョンｉの差分データ量：Ｄｄとしたとき、Ｓｄ＝Ｓｄ＋Ｄｄとする（ステップＳ３４０４）。次いで、ｉの差分データが検索にヒットしたかどうかを判断する（ステップＳ３４０５）。ヒットした場合には、ｉの差分検索結果データ量：Ｒｄをもとめた（ステップＳ３４０６）後、積算検索結果データ量Ｓｒに足し上げ、Ｓｒ＝Ｓｒ＋Ｒｄとする（ステップＳ３４０７）。続いて、Ｓｄ＞Ｓｒかどうかを判断する（ステップＳ３４０８）。ステップＳ３４０５において、ｉの差分データが検索にヒットしなければ、ステップＳ３４０８に移る。Ｓｄ＞Ｓｒでなければ、どのバージョンまで差分を送るか確保し、Ｖｄ＝ｉとする（ステップＳ３４０９）。その後、ステップＳ３４０２に戻る。Ｓｄ＞Ｓｒであれば、直ちに、ステップＳ３４０２に戻る。

一方、Ｖｓ＝ｉであれば、Ｖｄまでのバージョンの差分データを送信データ：Ｓにコピーする（ステップＳ３４１０）。続いて、Ｖｄ以降の検索結果を送信データ：Ｓに追記コピーする（ステップＳ３４１１）。

第５の実施形態によれば、部分的なバージョンアップをするので、差分検索処理量が減り、差分データ量を減少させることができる。また、以降の通信量も減少させることができる。上述では、差分データと差分検索結果のトータルサイズの大小関係による判定について説明したが、これに限られない。例えば、差分データの８０％で比較する、あるいは検索要求を予測するようにしてもよい。

[本差分検索システムのデータ更新]
次に、上記の差分検索を行うことが可能な差分検索システムでのデータ更新方法について説明する。

対サーバ間でのネットワーク環境が弱い状況下では、クライアントは、サーバに更新したデータの一部、例えばデータＩＤのみ送信し、更新したデータ全体の送信は行わずにおき、後刻そのクライアントが対サーバ間でのネットワーク環境が強い状況下にきたときに、サーバのデータベースと、クライアントのデータベース間の完全同期を行うよう更新したデータの送受信を実行する。

図３５（Ａ）は、ネットワーク環境が弱い状況下でのサーバ、クライアントＢを示し、図３５（Ｂ）は、ネットワーク環境が強い状況下でのサーバ、クライアントＢを示している。

ネットワーク環境が弱い状況下(本発明の第１のネットワーク環境下に相当する)は、例えば移動体通信網のみ利用可能な通信環境であって、通信はできるがネットワーク環境が強い場合に比して通信速度が低速な環境である。一方、ネットワーク環境が強い状況下(本発明の第２のネットワーク環境下に相当する)は、例えば第１の通信環境下に比して通信速度が高速な通信環境であって、例えば有線ＬＡＮ,トランスファージェットによるネットワーク利用可能時である。

なお、ネットワーク環境が弱い状況下であるか、ネットワーク環境が強い状況下にあるかは、どのような手段によってクライアントが判断するようにしてもよく、例えば通信状況(回線の混雑具合含む)、有線接続であるか否か、ＧＰＳによる位置情報、ユーザの手動による切り替え操作によりどちらのネットワーク環境下にあるかを判断するようにしてもよい。

図３５（Ａ）の状態で、クライアントにユーザが新たなデータを追加入力し、クライアントのデータベースが更新されたものとする。このときクライアントは更新したデータの一部（例えば、更新したデータのデータＩＤのみ）をサーバに送信する。この弱いネットワーク環境下では送信可能な通信量が少なく、コストもかかるためである。このとき、サーバはクライアントＢによって更新されたことを記憶しておく。後刻、図３５（Ｂ）のように、クライアントがサーバと強いネットワーク環境下になったとき、サーバとクライアントは互いのデータベースの記憶内容を同期させる。強いネットワーク環境下では送信可能な通信量も十分であり、通信コストも低いためである。

図３６は、図３５に示したクライアントＢがサーバに更新通知を行った後、別のクライアントであるクライアントＡがサーバに検索要求を行ったときの動作を示す。まず、クライアントＡは、サーバにある内容の検索要求を行う。サーバは自己のデータベースについて依頼された検索を実行するとともに、先に更新通知をしてきたクライアントＢに、クライアントＢが記憶している更新分のデータについて検索するよう差分検索要求を行う。クライアントＢはその差分検索要求に応じて、自己のデータベースを検索し、検索結果をサーバに戻す。サーバはクライアントＢからの検索結果と自己のデータベースの検索結果を合わせて、クライアントＡに検索結果を返す。これで、同期前であってもシステム内の検索が完了できる。

クライアント同士が通信可能である環境であれば、図３６の例のようにサーバを介すことなく、クライアントとサーバのデータベース同期実行前であっても、システム内の検索を行うことが可能である。図３７Ａは、クライアント同士が通信可能である場合の同期実行前検索時のシステムの動作例を示す。まず、クライアントＡは、ある内容の検索要求をサーバに行う(図中丸数字１）。サーバは先に更新通知をしてきたクライアントＢに差分検索を要求するよう、クライアントＡに通知する（図中丸数字２）。クライアントＡはサーバからの通知に基づいて、クライアントＢに差分検索要求を送信する（図中丸数字３）。クライアントＢはその差分検索要求に応じて、自己のデータベースを検索し、検索結果をクライアントＢに戻す（図中丸数字４）。これで、同期前であってもシステム内の検索が完了できる。

また、本実施の形態は、図３６の例、図３７Ａの例を組み合わせた構成を採用することも可能である。

図３７Ｂに図３６の例、図３７Ａの例を組み合わせた構成を採用した場合の差分検索システムの動作例を示す。図３７Ｂの例も、クライアント同士が通信可能である場合の同期実行前検索時のシステムの動作例である。

まず、クライアントＡは、ある内容の検索要求をサーバに行う(図中丸数字１）。サーバは、現在持っているデータ内での最新の差分結果をクライアントＡに送信し、且つ最新データを持っているクライアントＢに差分検索を要求するよう、クライアントＡに通知する（図中丸数字２）。このとき、サーバからクライアントＡにどのバージョンでの最新結果かも提示される。クライアントＡはサーバからの通知に基づいて、クライアントＢに差分検索要求を送信する（図中丸数字３）。ここで、クライアントＡはサーバ〜通知されたバージョンでクライアントＢに問い合わせを行う。クライアントＢはその差分検索要求に応じて、自己のデータベースを検索し、検索結果をクライアントＢに戻す（図中丸数字４）。

上記図３７Ｂの例をより具体的に説明する。今、クライアントＡの保有するデータのバージョンは３、サーバの保有するデータのバージョンは４、クライアントＢの保有するデータのバージョンは５とする。なお、データのバージョンの数字が大きくなるほど、データは最新の内容である。

図中丸数字１の動作において、クライアントＡはサーバに問い合わせる際、「クライアントＡの保有するデータのバージョンは３」を示す情報を渡す。この情報を受け取ったサーバは、丸数字２の動作において、「最新データを保有するのはクライアントＢ」、「バージョン４とバージョン３の差分検索結果」、「サーバの保有するデータのバージョンは４」のそれぞれに相当する情報をクライアントＡに渡す。

丸数字３の動作において、クライアントＡはクライアントＢに「クライアントＡの保有するデータのバージョンは４」に相当する情報を渡す。丸数字４の動作においてクライアントＢは「バージョン５とバージョン４の差分検索結果」をクライアントＡに返す。

また、本発明ではクエリキャッシュを利用することにより通信量が少なくデータを更新することもできる。図３８は、クエリキャッシュを利用した場合の、図３５に示したクライアントＢがサーバに更新通知を行った後、別のクライアントであるクライアントＡがサーバに検索要求を行ったときの動作を示す。まず、クライアントＡは、サーバにある内容の検索要求を行う。サーバは自己のデータベースについて依頼された検索を実行するとともに、先に更新通知をしてきたクライアントＢに、クライアントＢが記憶している更新分のデータについて検索するよう差分検索要求を行う。クライアントＢはその差分検索要求に応じて、自己のデータベースを検索し、検索結果をサーバに戻す。サーバはクライアントＢからの検索結果と自己のデータベースの検索結果を合わせて、クライアントＡに検索結果を返す。さらにサーバは、検索結果をクエリキャッシュとして保存しておく。図３９は、図３８の状態の後、さらに別のクライアントＣがクライアントＡと同じ検索要求をした場合の本検索システムの動作例を示す。クライアントＣは同じ検索要求をサーバに送信する。サーバはクエリキャッシュを参照して同じ検索要求である場合は、クライアントＢに問い合わせを行うことなく、クライアントＣにクエリキャッシュを検索結果として送信する。これによりクライアントＢ、サーバ間の通信を省略することができ、結果として通信量を抑えておくことが可能となる。

先にあるクライアントが更新をサーバに通知したのち、更新が通知されたデータは別のクライアントによって更新されないようロック（更新禁止処理）される。あるデータがロックされている状態で、別のクライアントにおいて更新する必要が生ずることもある。その場合には、本発明は複数の対応方法を取りうる。
１．後発のロックはあきらめる。
２．先にロックをかけたクライアントによるロックを解除して、後発のクライアントによるロックを行う。後発のクライアントは先にロックをかけたクライアントに問い合わせて、内容を確認し、上記１．または２．のいずれかを選択する。

[稼働率]
本発明では、クライアントが更新データをサーバに送信するか否かを判定するための情報の一つとして、「稼働率」を利用する。稼働率は以下の式で算出される。

上記式で、「ＭＴＢＦ」は、完全同期から更新が発生するまでの時間である。MTBF = システムの稼動時間 / 故障回数という計算式で算出でき、これはMTBF =システムの稼動時間 / 更新回数（＝1/更新率）に等しい。

また、「ＭＴＴＲ」は、更新から完全同期するまでの時間である。同期自体にかかる時間は一瞬だが、同期を実行できるようになるまで時間かかる。これを「ＭＴＴＲ」として考慮に入れる。

稼働率の計算例を説明する。例えば、更新が5日に1回されるとして、MTBF=システムの稼働時間／更新回数＝5/1＝５となる。また、同期されるまでは半日かかるとすると、MTTR＝1/2（日）よってこの例の場合の稼働率は

この稼働率を「p」とする。稼働率「ｐ」であるシステムでは、確率「p」で差分検索が実行できる。逆に、確率 (1 - p)の時、サーバだけでは差分検索できない。よって、このサーバだけでは差分検索できない確率 (1 - p)の時、更新者に問い合わせをする方法を採る。

更新したデータをサーバに反映するためのデータ量をＤとし、ある期間での検索発生回数をｎ、差分検索のためのデータ量をＲ、更新者への問い合わせをした差分検索量を２Ｒとすると、更新データを送付した場合の送信データ量はＤ＋ｎ・Ｒであり、更新データを送付しない場合の送信データ量は、ｎ・（Ｒ・ｐ＋２Ｒ・（１−ｐ））で表すことができる。
前回と同様、更新データは同期のためのデータであり、（更新データを送付しない場合の送信データ量）≦更新データを送付した場合の送信データ量が成立する時、本発明の方式は効率的となる。よって

が成立する時、本発明による方式は効率的で得あると判定できる。
また、上記式は

と変形できる。一般に更新データは、差分検索結果データに比べ数倍大きい。この式により、検索要求頻度と更新頻度がデータ量の比より小さければ、効率できであるといえる
この判定式を使った予測によってデータを送信すべきかどうか決定できる。とりわけ最初の判断と、検索要求が多く来た時に利用可能である。

更新時にＤが決まり、Rとpとnが履歴から予測できれば更新時に上記式に基づいて効果的かどうかが判定できる。効果がないと判定された場合には、更新データをサーバに反映させるよう送信すればよい。

また、更新データに対して検索回数が増えるとｎが増加する。Dは更新時に決まっており、Rとpが予測から求められ、増加したｎによって上記式の不等号が成り立たなくなったら、更新データをサーバに反映するようにすればよい。

上記判定の具体例を上げる。２４時間中、１時間だけ更新が反映されない状況が生ずるとする。例えば、通勤移動時間が朝と夜で１時間かかるとする。この場合稼働率ｐは上記稼働率の計算式より
ｐ＝２３／（２３＋１）＝０．９５８
さらに、更新データ量Ｄは、差分検索のためのデータ量Ｒの１０倍（Ｄ＝１０Ｒ）とすると、前記不等式を変形してｎ≦Ｄ／（Ｒ×（１−ｐ））＝１０／０．０４＝２５０となり、結局２５０回／日の検索要求が一定間隔できても、結果効果的であることがわかる。

[本システムの基本的な動作]
以下、本システムの基本的な動作例について説明する。

図４０は、本システムの基本的な動作の概要を示した図である。この例では、サーバと、データ更新を行うクライアント（以下、区別のため更新要求クライアントと呼ぶ）と、検索を行うクライアント（以下、区別のため検索要求クライアントと呼ぶ）とでシステムが構成されているものとする。

更新要求クライアント（より詳しくは命令制御部１２、以下同じ）は最初にデータ更新要求を行った時にはネットワーク環境が弱い環境下に存在しているが、その後移動してネットワーク環境が強い環境下に存在するようになるものとする。

ここでは、以下の順にそれぞれの処理が行われる
（１）更新要求クライアントによる遠距離更新時のユーザ更新要求
（２）サーバによる遠距離更新時のユーザ更新要求受付
（３）検索要求クライアントによる検索実行
（４）サーバによるユーザ参照要求受付
（５）サーバによる差分検索要求、更新要求クライアントによる差分検索応答
（６）更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付
以下、上記手順の具体的内容について述べる。

[（１）更新要求クライアントによる遠距離更新時のユーザ更新要求]
図４１は、上記（１）更新要求クライアントによる遠距離更新時のユーザ更新要求の処理例を示したフローチャートである。以下このフローチャートを参照しながら更新要求クライアントによる遠距離更新時のユーザ更新要求を説明する。

サーバのデータベース更新を行う必要が生ずると、まず、更新要求クライアントは更新を行うために送信しなければならない送信データ量Ｄの算出を行う（Ｓ４１０１）。次に、更新要求クライアントは、検索発生回数ｎ、差分検索のためのデータ量Ｒ、稼働率ｐを取得する（Ｓ４１０２）。検索発生回数ｎ、差分検索のためのデータ量Ｒ、稼働率ｐ(以下、これらの値をまとめて実績値（ｎ，Ｒ，ｐ）とする）はサーバが過去データなどから算出して保持しており、各クライアントはこの実績値（ｎ，Ｒ，ｐ）のレプリカをサーバから取得し所持する。また、実績値は複数あってもよく、例えばテーブルごとに実績値（ｎ，Ｒ，ｐ）が保持されるようにしてもよい。

次に、更新クライアントは上記データ量Ｄ、及び実績値（ｎ，Ｒ，ｐ）に基づいて更新通知のみの方が効率的かどうかを判定する（Ｓ４１０３）。この判定は、上述の判定式

に値を当てはめ、この不等式が成立するかどうかにより行う。不等式が成立する場合は更新通知のみの方が効率的であるとの判定となり（Ｓ４１０３，Ｙｅｓ）、不等式が成立しない場合は更新通知のみの方が効率的でないとの判定となる（Ｓ４１０３，Ｎｏ）。

更新通知のみの方が効率的であるとの判定をした場合（Ｓ４１０３，Ｙｅｓ）、更新要求クライアントはサーバに更新通知を送信する（Ｓ４１０５）。例えば、更新したデータのＩＤのみ送信し、データの内容の送信は行わない。一方、更新通知のみの方が効率的でないと判定した場合（Ｓ４１０３，Ｎｏ）、更新要求クライアントはサーバに対して通常更新を実行する（Ｓ４１０４）。

[（２）ユーザ更新要求受付]
上記通常更新（更新データ）若しくは更新通知を受け付けたサーバ（より詳しくは命令制御部２２、以下同じ）は、ユーザ更新要求受付を実行する。図４２は、上記（２）サーバによる遠距離更新時のユーザ更新要求受付の例を示したフローチャートである。以下このフローチャートを参照しながらサーバによる遠距離更新時のユーザ更新要求受付の処理内容を説明する。

更新要求クライアントから送信された通常更新若しくは更新通知を受け付けたサーバは、まず受け付けた内容が更新通知であるか否かを判定する（Ｓ４２０１）。更新通知でないと判定した場合（Ｓ４２０１、Ｎｏ），サーバは受信した更新データに基づいてデータベースを通常に更新する（Ｓ４２０２）。一方、更新通知であると判定した場合（Ｓ４２０１、Ｙｅｓ），サーバは更新通知に含まれる情報(例えば、更新対象のデータＩＤなど）に基づいて、更新対象のデータを無効化(検索対象からはずす処理)し、当該データについては更新したユーザである更新要求クライアントに問い合わせるように設定(例えば、データベース中に要問い合わせフラグを記述し、問い合わせ先クライアント特定情報を付加する、など）する（Ｓ４２０３）。さらに、サーバは更新対象のデータを管理する（Ｓ４２０４）。

サーバ側は更新通知の対象のデータを覚えておく。他のクライアントからの最新データへの検索要求に対してサーバ自身は最新のデータをもっていいないことを覚えとかなければならない。具体的には、サーバは更新通知されたデータに対して、更新者をそのデータとペアにして（例えば、メモリ上で）管理する。
以上で、サーバによるユーザ更新要求受付が終了する。

[（３）検索要求クライアントによる検索実行]
上記サーバがユーザ更新要求受付を終了したのち、検索要求クライアントが検索要求をサーバに送信したものとする。このとき検索要求クライアントによる検索実行が行われる。図４３は、上記（３）検索要求クライアントによる検索実行の例を示したフローチャートである。以下このフローチャートを参照しながら検索要求クライアントによる検索実行の処理内容を説明する。

検索要求クライアントはサーバにデータベースにVersionの問い合わせを行う（Ｓ４３０１）。サーバが自己のデータベースのVersionを検索要求クライアントに返す。検索要求クライアントはサーバから取得したVersionから、サーバに問い合わせるか否かを判断する（Ｓ４３０２）。具体的には、例えば、検索要求クライアント自身のデータベースより新しいVersionであれば問い合わせする。

検索要求クライアントが問い合わせ必要であると判定した場合（Ｓ４３０３、Ｙｅｓ）、検索要求クライアントはサーバに差分検索を実行させ、検索結果を取得する（Ｓ４３０４）。その後、検索要求クライアントは自分が所持するデータベースを検索する（Ｓ４３０５）。
一方、検索要求クライアントが問い合わせ必要でないと判定した場合（Ｓ４３０３、Ｎｏ）、検索要求クライアントはサーバに差分検索を求めることなく直ちに自分が所持するデータベースを検索する（Ｓ４３０５）。

最後に、検索要求クライアントは検索結果を出力する。差分検索の結果をサーバから取得している場合には、自己のデータベースの検索結果と差分検索の結果を結合して検索結果として出力する（Ｓ４３０６）。
以上で、検索要求クライアントによる検索実行が終了する。

[（４）サーバによるユーザ参照要求受付]
検索要求クライアントから検索要求を受け付けたサーバは、ユーザ参照要求受付処理を実行する。図４４は、上記（４）サーバによるユーザ参照要求受付の例を示したフローチャートである。以下このフローチャートを参照しながらユーザ参照要求受付処理の内容を説明する。

検索要求を受け付けたサーバはまず、自己のデータベースを参照し、問い合わせしないと得られないデータを列挙する（Ｓ４４０１）。図４５は、このステップＳ４４０１のより具体的な処理内容を示したフローチャートである。サーバは自己のデータベース内のデータのうち、更新対象のデータを検索する（Ｓ４５０１）。検索して抽出されたデータについて、サーバは検索対象となるか否かを判定する（Ｓ４５０２）。検索対象となると判定した場合（Ｓ４５０２，Ｙｅｓ）には、サーバは当該データを問い合わせリストに追加する（Ｓ４５０３）。ここでいう「問い合わせリスト」は、どのユーザ（クライアント）に問い合わせすればいいか判断するためのリストである。一方、検索対象とならないと判定した場合（Ｓ４５０２，Ｙｅｓ）には、サーバは次の更新対象のデータに進む。上記Ｓ４５０２、Ｓ４５０３を全ての更新対象のデータについて終了するまで繰り返す。これでＳ４４０１のデータの列挙が終了する。

図４４に戻り、ユーザ参照要求受付処理の説明を続ける。データの列挙（Ｓ４４０１）が終了すると、サーバは問い合わせ先リストに従い、各ユーザ(クライアント)に差分検索を要求し、返される差分検索結果を取得する（Ｓ４４０２）。

次にサーバは、サーバ自身のデータベースを参照し、更新済みのデータを検索する（Ｓ４４０３）。さらにサーバは検索結果を出力する。差分検索の結果をクライアントから取得している場合には、自己のデータベースの検索結果と差分検索の結果を結合して検索結果として出力する（Ｓ４４０４）。

最後に、サーバは検索頻度ｎの値を1だけ増加させ、新しい検索頻度ｎとして記憶する（Ｓ４４０５）。実績値（ｎ，Ｒ，ｐ）を最新の状態に保っておくためである。
以上で、ユーザ参照要求受付処理が終了する。

[（５）サーバによる差分検索要求、更新要求クライアントによる差分検索応答]
検索要求クライアントから検索要求を受け付けたサーバは、更新クライアントに対して差分検索要求を出し、この差分検索要求を受け付けた更新要求クライアントは差分検索応答を行う。

図４６は、上記（５）サーバによる差分検索要求、更新要求クライアントによる差分検索応答の処理例を示したフローチャートである。以下このフローチャートを参照しながらサーバによる差分検索要求、更新要求クライアントによる差分検索応答の内容を説明する。

まず、サーバ側で行われる差分検索要求について先に説明する。検索要求クライアントから検索要求を受け付けたサーバはまず、他のクライアント（先の問い合わせリストにより決定する）に対して差分検索要求を送信する（Ｓ４６０１）。その後、差分検索要求を受け付けたクライアント(この例では更新要求クライアントのみとしたが、実際には更新要求クライアントに限られるわけではない）から結果を受け取る（Ｓ４６０２）。この「結果」は差分検索結果である場合と、更新データである場合と2通りある。

結果を受け取ったサーバは、その結果が更新データであるか否かを判定する（Ｓ４６０３）。その結果が更新データであると判定した場合（Ｓ４６０３、Ｙｅｓ）、サーバは受け取った更新データを自己のデータベースに反映させ（Ｓ４６０４）、差分検索のために送られたデータ量の合計Ｒ_ｓｕｍ、及び差分検索の実行回数ｎ_Ｒをリセットする（Ｓ４６０５）。なお、合計Ｒ_ｓｕｍ、及び差分検索の実行回数ｎ_Ｒは更新データに対してのデータなので、更新した場合は不要となる。これで、サーバ側で行われる差分検索要求は終了する。

一方、ステップＳ４６０３の判定において、その結果が更新データでない（検索結果である）と判定した場合（Ｓ４６０３、Ｎｏ）、サーバは、受け取った検索結果のデータＲを差分検索のために送られたデータ量の合計Ｒ_ｓｕｍに加算して新たなデータ量の合計Ｒ_ｓｕｍとして記憶する（Ｓ４６０６）。次に、サーバは差分検索の実行回数ｎ_Ｒを1増加させ、新たな差分検索の実行回数ｎ_Ｒとして記憶する（Ｓ４６０７）。実績値（ｎ，Ｒ，ｐ）を最新の状態に保っておくためである。これで、サーバ側で行われる差分検索要求は終了する。

次に、更新要求クライアントによる差分検索応答の処理例について説明する。
まず、更新要求クライアントは、サーバ側の差分検索要求のステップＳ４６０１においてサーバから送信された差分検索要求を受け取る（Ｓ４６０８）。次に、更新要求クライアントは、この差分検索要求に応じて、自己のデータベースを用いて差分検索を実行する（Ｓ４６０９）。次に、更新要求クライアントは今まで送った更新データのデータ量の合計値が、サーバに送るべき更新データのデータ量を超えているか否かを判定する（Ｓ４６１０）。
具体的には、下記式に基づいてＳ４６１０の判定が行われる。

但し、上記式においてR_iはi番目に行われた更新データのデータ量、Ｄはサーバに送るべき更新データのデータ量である。

上記Ｓ４６１０において更新要求クライアントは今まで送ったデータのデータ量の合計値が、サーバに送るべき更新データのデータ量を超えている(上記式が成立している）と判定した場合（Ｓ４６１０、Ｙｅｓ）、更新要求クライアントはサーバに更新データを返す（Ｓ４６１１）。これで更新要求クライアントによる差分検索応答は終了する。

一方、上記Ｓ４６１０において更新要求クライアントは今まで送ったデータのデータ量の合計値が、サーバに送るべき更新データのデータ量を超えていない（上記式が成立していない)と判定した場合（Ｓ４６１０、Ｎｏ）、Ｓ４６０９で得られた差分検索結果をサーバに返す（Ｓ４６１２）。さらに更新要求クライアントは送ったデータ量Ｒ_ｉを保持する。後に、今まで送った更新データのデータ量の合計値を算出し、Ｓ４６１０の判定を行うためである。これで更新要求クライアントによる差分検索応答は終了する。

[（６）更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付]
弱いネットワーク環境下にあった更新要求クライアントが強いネットワーク環境下に入った場合、更新要求クライアントによる更新要求並びにサーバによるユーザ更新要求受付が行われる。図４７は、上記更（６）新要求クライアントによる更新要求、サーバによるユーザ更新要求受付処理例を示したフローチャートである。以下このフローチャートを参照しながら更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付を説明する。

更新要求クライアントはまず、更新通知のみの更新データをサーバに送信する（Ｓ４７０１）。次に、更新要求クライアントはサーバから実績値（ｐ，ｎ，Ｒ）を取得する（Ｓ４７０２）。その後、更新クライアントは自己のデータベースとサーバのデータベースとの完全同期を実行する（Ｓ４７０３）。この完全同期の内容については後述する。完全同期終了後、更新要求クライアントは更新要求を終了する。

次に、サーバの更新要求受付について説明する。更新要求クライアントから送信された更新データを受信したサーバは、更新データを自己のデータベースに反映させる（Ｓ４７０４）。次に、サーバは前回の完全同期時刻と、更新通知日時と、現在時刻から稼働率ｐを算出する（Ｓ４７０５）。サーバは、差分検索のために送られたデータ量の合計Ｒｓｕｍを差分検索の実行回数ｎＲで割って、平均データ量Ｒを算出する（Ｓ４７０６）。次に、サーバは更新された実績値（ｎ，Ｒ，ｐ）を更新要求クライアントに送信する（Ｓ４７０７）。その後、サーバは更新要求クライアントとの間でデータベース内容の完全同期を実行する（Ｓ４７０８）。この完全同期の内容については後述する。完全同期終了後、サーバは更新要求受付を終了する。

最後に、更新要求クライアント及びサーバ間での完全同期処理について説明する。
完全同期処理を開始した更新要求クライアントはまず、自分のデータベースのVersionをサーバに通知する（Ｓ４７０９）。サーバは更新要求クライアントからデータベースのVersionを得る（Ｓ４７１０）と、更新要求クライアントに渡すべき差分となるデータを生成する（Ｓ４７１１）。次にサーバは、差分となるデータを更新要求クライアントに送信する（Ｓ４７１２）。更新要求クライアントはサーバから差分となるデータを受信する（Ｓ４７１３）。更新クライアントは受信した差分となるデータを自己のデータベースに更新させる（Ｓ４７１４）。これで、更新クライアント及びサーバ間のデータベース完全同期が完了する。

[本発明の効果的な状況]
本発明は、下記のような状況下でとりわけ有効である。
１．サーバ、クライアント間が近距離では安価で高速な通信ができ、遠距離では高価で低速でも通信が可能であること。
このような環境下で、本発明は、近距離では同期による更新をし、遠距離では本提案を実施する。
２．一定間隔で、データベースがリフレッシュできること
充電のついでに完全同期できるなど、そのような完全同期がある期間内には行われる環境であること。
３．クライアント側で入力されるような、更新データが大量であるが、検索対象になりにくい環境下であること。
同期するまで、当面、検索されないようなものほど本発明は効果がある。
上記において「近距離」とは例えば、（通信の）コストが小さい環境を意味し、「遠距離」とは例えば、（通信の）コストが大きい環境を意味する。
ここでいう「コスト」とは、通信に伴う料金（課金額）や、通信速度、レイテンシィ、電力消費量などを一つ乃至は複数考慮して決定する定量的なものを意味する。

[まとめ]
本発明によれば、以下のメリットを享受できる。
１．データを更新する際、悪い通信環境での通信量を減らすことができるため、（ネットワーク管理者から見てネットワークトラフィックが減り、ユーザから見た場合に通信費用が減る。
２．サーバの負担を減らすことも可能となる。

１…情報端末装置、１０…ユーザインターフェース、１１…接続部、１２…命令制御部
、１３…SQL実行部、１４…データベース、２…情報管理装置、２１…接続部、２２…命
令制御部、２３…SQL実行部、２４…データベース、１００…クライアントサーバシステム。

Claims

第1データベースを備え、データの変更履歴をバージョンで管理しているサーバと、通信回線網を介して前記サーバと接続され、前記サーバに同期して取得したデータとバージョンで構成される第２データベースを備えたクライアントとから成るクライアントサーバ型システムの検索システムであって、
前記クライアントは、第１のネットワーク環境下では更新通知のみ前記サーバに送信し、前記第１のネットワーク環境より通信に有利な環境である第２のネットワーク環境下では、前記サーバに更新データを送信して、前記第1データベース及び前記第2データベースの同期を実行する
ことを特徴とする差分検索システム。
前記クライアントは、通信速度、有線接続の有無、当該クライアントの位置情報、クライアント使用者の指示入力のいずれかに基づいて、当該クライアントが第１のネットワーク環境下であるか、第２のネットワーク環境下であるかを決定して、更新通知若しくは更新データをサーバに送信する
ことを特徴とする請求項１に記載の差分検索システム。
前記クライアントは、下記の不等式

が成立する場合は、更新通知のみの方が効率的であるとの判定し、更新通知のみサーバに送信し、前記不等式が成立しない場合は更新通知のみの方が効率的でないとの判定し、更新データを前記サーバに送信する
ことを特徴とする請求項１に記載の差分検索システム、但し、Ｄは更新を行うために送信しなければならない更新データの送信データ量、ｎは差分検索を含むすべての検索発生回数、Ｒは差分検索のためのデータ量、ｐは本差分検索システムの稼働率。
前記クライアントは、前記サーバから差分検索要求を受け取った場合、今まで送った更新データのデータ量の合計値が、サーバに送るべき更新データのデータ量を超えているか否かを判定し、今まで送ったデータのデータ量の合計値が、前記サーバに送るべき更新データのデータ量を超えると判定した場合、前記サーバに更新データを送信し、一方今まで送ったデータのデータ量の合計値が、前記サーバに送るべき更新データのデータ量を超ないと判定した場合には差分検索結果を前記サーバに送信する
ことを特徴とする請求項１に記載の差分検索システム。