データベース・システム、並びにそのクライアント
【課題】サーバを用いず、差分検索方式によるデータベースの検索、データベースの更新を可能とする。
【解決手段】クライアントは、記憶手段、判定手段、つなぎかえ要求手段、つなぎかえ指定手段、つなぎかえ処理手段を有する。記憶手段は更新権と問い合わせ先を記憶する。判定手段は、つなぎかえを行うために要する第１の送信データ量が、つなぎかえを行わない場合における問い合わせを行うために要する第２の送信データ量より小さいか否かを判定する。つなぎかえ要求手段は、問い合わせ先が示す他のクライアントにつなぎかえ要求を送信させる。つなぎかえ指定手段は、更新権の保有しているときつなぎかえ要求を受信した場合、つなぎかえ指定を他のクライアントに送信させる。つなぎかえ処理手段は、つなぎかえ指定を受信した場合、つなぎかえ指定で指定されたクライアントを問い合わせ先として記憶させる。
【解決手段】クライアントは、記憶手段、判定手段、つなぎかえ要求手段、つなぎかえ指定手段、つなぎかえ処理手段を有する。記憶手段は更新権と問い合わせ先を記憶する。判定手段は、つなぎかえを行うために要する第１の送信データ量が、つなぎかえを行わない場合における問い合わせを行うために要する第２の送信データ量より小さいか否かを判定する。つなぎかえ要求手段は、問い合わせ先が示す他のクライアントにつなぎかえ要求を送信させる。つなぎかえ指定手段は、更新権の保有しているときつなぎかえ要求を受信した場合、つなぎかえ指定を他のクライアントに送信させる。つなぎかえ処理手段は、つなぎかえ指定を受信した場合、つなぎかえ指定で指定されたクライアントを問い合わせ先として記憶させる。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書に記載の実施の形態は、データベース・システム、並びにそのクライアントに関する。
【背景技術】
【０００２】
最近、家電機器等において、組込み機器製品が高機能化し、機器自体がサーバになることが求められている。一方、サーバを利用するクライアント機器は、サーバが有するデータベースと同期するデータベースを有し、サーバと協働してデータベースの検索、データベースの更新を行い、ユーザが常に最新の内容のデータベースを利用できるシステムが提案されている。
【０００３】
このような、サーバを利用するデータベースシステムにおいて、検索において、クライアントが所有する最新でないデータベースを活用して、少ないデータの送受信量で最新のデータを検索することができたり、データベースの更新において、クライアントが大量のデータを更新したいとき、更新したことだけを通知することで、少ないデータの送受信量で更新データをデータベースに反映する技術も提案されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−１６４８４０号公報
【０００５】
【特許文献２】特開２００４−３４３２３４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来のサーバを利用するシステムでは、サーバの集中管理が必要であり、サーバの負荷を究極的に減らすことが困難であるという問題があった。サーバの負荷を究極的に減らす方法としては、サーバを利用しないシステムとすることが考えられるが、そのようなシステムにおいては、ある１クライアントに集中して問い合わせが発生して負荷がそのクライアントに集中してしまうという問題が発生する。
【０００７】
本実施の形態は、固定のサーバとなる装置を用いず、１つのクライアントに負荷が集中することなく、差分検索方式によるデータベースの検索、データベースの更新が可能な技術を提供することを目的とする。
【課題を解決するための手段】
【０００８】
一の実施の形態によれば、サーバを用いなくとも使用可能なデータベースシステムのためのクライアントが提案される。
【０００９】
このクライアントは、記憶手段と、判定手段と、つなぎかえ要求手段と、つなぎかえ指定手段と、つなぎかえ処理手段とを有する。
【００１０】
記憶手段は、自己が最新のデータベースの内容を保有しているか否かを示す情報である更新権と、差分検索又はデータベースの同期の相手となる他のクライアントを特定する情報である問い合わせ先を記憶する。判定手段は、つなぎかえを行うために要する第１の送信データ量が、つなぎかえを行わない場合における問い合わせを行うために要する第２の送信データ量より小さいか否かを判定する。
つなぎかえ要求手段は、前記判定手段が前記第１の送信データ量は前記第２の送信データ量より小さいと判定した場合、前記問い合わせ先が示す他のクライアントに、更新権を保有するクライアントを通知することを要求するメッセージであるつなぎかえ要求を送信させる。つなぎかえ指定手段は、前記更新権が更新権の保有を示しているときに他のクライアントからつなぎかえ要求を受信した場合、自己を前記問い合わせ先とすることを指示するメッセージであるつなぎかえ指定を前記他のクライアントに送信させる。つなぎかえ処理手段は、前記つなぎかえ指定を受信した場合、そのつなぎかえ指定において指定されたクライアントを前記問い合わせ先として記憶させる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態に係るクライアントサーバシステムの構成例を示す概念図
【図２】本発明の実施形態に係るクライアントサーバシステムの機能ブロック図
【図３】第１の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新及びバージョンを説明するための模式図
【図４】情報端末装置の情報管理装置に対する要求処理の流れを示すフローチャート
【図５】情報管理装置のユーザ情報端末装置の更新要求処理の流れを示すフローチャート
【図６】データベースの構造(中身）を模式化した図
【図７】データ量の比較を模式化した図
【図８】データ量の比較を模式化した図
【図９】データ量の比較を模式化した図
【図１０】データ量の比較を模式化した図
【図１１】変更履歴の追加がなされた場合のデータベースの構造（中身）の変化を例示する図
【図１２】変更発生時の変更履歴欄の更新処理の流れを示すフローチャート
【図１３】同期処理におけるデータベースの構造（中身）の変化を例示する図
【図１４】無効化処理におけるデータベースの構造（中身）の変化を例示する図
【図１５】探索要求時におけるデータベースの構造（中身）の変化を例示する図
【図１６】探索実行におけるデータベースの構造（中身）の変化を例示する図
【図１７】情報管理装置側における差分把握処理の流れを示すフローチャート
【図１８】情報端末装置側における差分除去処理の流れを示すフローチャート
【図１９】情報端末装置側における差分検索処理の流れを示すフローチャート
【図２０】情報管理装置における差分検索処理の流れを示すフローチャート
【図２１】変更履歴を用いた差分データからの検索処理を説明する図
【図２２】第２の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新及びバージョンを説明するための模式図
【図２３】変更発生時の変更履歴欄の更新処理の流れを示すフローチャート
【図２４】変更発生時の変更履歴欄の更新処理の流れを示すフローチャート
【図２５】変更発生時の変更履歴欄の更新処理の流れを示すフローチャート
【図２６】更新要求を受けつけた後の変更履歴処理全体の流れを示すフローチャート
【図２７】第３の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新及びバージョンを説明するための模式図
【図２８】変更発生時の変更履歴欄の更新処理の流れを示すフローチャート
【図２９】変更履歴の上位概念によるまとめ処理の流れを示すフローチャート
【図３０】第４の実施形態に係るクライアントサーバ型検索システムを説明する図
【図３１】情報管理装置における差分検索処理の流れを示すフローチャート
【図３２】第５の実施形態に係るクライアントサーバ型検索システムを説明する図
【図３３】情報管理装置における差分検索処理の流れを示すフローチャート
【図３４】送信データの決定処理の流れを示すフローチャート
【図３５】Ａ）は、ネットワーク環境が弱い状況下でのサーバ、クライアントＢを示した図、Ｂ）はネットワーク環境が強い状況下でのサーバ、クライアントＢを示した図
【図３６】図３５に示したクライアントＢがサーバに更新通知を行った後、別のクライアントクライアントＡがサーバに検索要求を行ったときの動作を示す図
【図３７Ａ】クライアント同士が通信可能場合の同期実行前検索時のシステムの動作例を示す図
【図３７Ｂ】クライアント同士が通信可能場合の同期実行前検索時のシステムの別の動作例を示す図
【図３８】クエリキャッシュを利用した場合の、図３５に示したクライアントＢがサーバに更新通知を行った後、別のクライアントクライアントＡがサーバに検索要求を行ったときの動作を示す図
【図３９】図３８の状態の後、さらに別のクライアントＣがクライアントＡと同じ検索要求をした場合の本検索システムの動作例を示す図
【図４０】本システムの基本的な動作の概要を示した図
【図４１】更新要求クライアントによる遠距離更新時のユーザ更新要求の処理例を示したフローチャート
【図４２】サーバによる遠距離更新時のユーザ更新要求受付の例を示したフローチャート
【図４３】検索要求クライアントによる検索実行の例を示したフローチャート
【図４４】サーバによるユーザ参照要求受付の例を示したフローチャート
【図４５】ステップＳ４４０１のより具体的な処理内容を示したフローチャート
【図４６】サーバによる差分検索要求、更新要求クライアントによる差分検索応答の処理例を示したフローチャート
【図４７】新要求クライアントによる更新要求、サーバによるユーザ更新要求受付処理例を示したフローチャート
【図４８】第６の実施の形態のシステム構成例を示したブロック図
【図４９】クライアントの機能ブロック図
【図５０】命令制御部の一構成例を示す機能ブロック図
【図５１】変更履歴の記憶内容の例を示すブロック図
【図５２】１つのマスター・クライアントと、１つのノード・クライアントの間での責任の移転の例を示す図
【図５３】あるデータａについての「責任」が移転する例を示す図
【図５４】図５３の状態から責任が移転した後の状態を示す図
【図５５】図５４の状態の後、つなぎかえが行われた状態を示す図
【図５６】クライアント間でのデータベース更新前のある状態を示す図
【図５７】図５６の後につなぎかえが行われた状態を示す図
【図５８】条件判定式の計算例を説明するための図
【図５９】条件判定式の計算例を説明するための別の図
【図６０】サーバを用いることなく検索を行う場合の、本実施の形態に係るデータベース・システムの動作例を示すシーケンス図
【図６１】差分通知と差分検索を同時に送信するようにした場合の、サーバを用いることなく検索を行う場合の本実施の形態に係るデータベースシステムの動作例を示したシーケンス図
【図６２】本データベースシステムにおいて、あるノード・クライアントがデータの検索（差分検索）を行うときの動作例を示したフローチャート
【図６３】問い合わせ先クライアントの差分通知要求に対する対応処理の一例を示したフローチャート
【図６４】問い合わせ先クライアントのつなぎかえ要求に対する応答処理を示したフローチャート
【図６５】更新要求を受信した問い合わせ先クライアントの動作例を示したフローチャート
【発明を実施するための形態】
【００１２】
[差分検索システム]
まず、本実施の形態の基本となる差分検索システムについて説明する。
図1は、本発明の実施形態に係るクライアントサーバシステムの構成例を示す概念図である。図１に示すように、クライアントサーバシステム１００は、サーバとなる情報管理装置２と、例えばインターネット網あるいは無線通信網３でクライアント機器となる情報端末装置１とから構成されている。情報管理装置（以下の説明では、サーバとも称する）２は、図１に示すように、データベース２４に接続されている。データベース２４は、都度、更新され、現在のバージョンと変更履歴が管理されている。情報管理装置２は、専用機器である必要は無い。所謂、家電機器と称される機器であってもネットワーク網に繋がり、バージョンの管理ができてサーバ機能を果たすものであればよい。さらに変更履歴は、各バージョンとそのバージョンで対象となるデータのＩＤとで把握されるようになっている。これらの詳細については、後述する。
【００１３】
情報端末装置（以下の説明では、クライアントとも称する）１は、データベース機能を備えるものであれば、携帯電話や携帯プレーヤが好適である。所謂、ウルトラモバイルＰＣと称されるものである。図１に示すように、各情報端末装置１も、それぞれデータベース１４に接続されているが、データベース１４は、情報管理装置２のデータベース２４と同期したときのバージョンとなっている。
【００１４】
図２は、本発明の実施形態に係るクライアントサーバシステム１００の機能ブロック図である。情報管理装置２は、接続部２１とデータベース２４を備え、情報端末装置１の要求を受け、結果を送信する。接続部２１は、インターネット網を介して、情報端末装置１と通信をする。情報端末装置１は、ユーザインターフェース１０と接続部１１及びデータベース１４を備える。ユーザインターフェース１０は、ユーザの要求を受け、結果を表示するものである。接続部１１は、インターネット網を介して、情報管理装置２と通信をする。
【００１５】
さらに、情報管理装置２は、命令制御部２２と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増加させ、新たな差分検索の実行回数ｎＲとして記憶する（Ｓ４６０７）。実績値（ｎ，Ｒ，ｐ）を最新の状態に保っておくためである。これで、サーバ側で行われる差分検索要求は終了する。
【００９３】
次に、更新要求クライアントによる差分検索応答の処理例について説明する。
まず、更新要求クライアントは、サーバ側の差分検索要求のステップＳ４６０１においてサーバから送信された差分検索要求を受け取る（Ｓ４６０８）。次に、更新要求クライアントは、この差分検索要求に応じて、自己のデータベースを用いて差分検索を実行する（Ｓ４６０９）。次に、更新要求クライアントは今まで送った更新データのデータ量の合計値が、サーバに送るべき更新データのデータ量を超えているか否かを判定する（Ｓ４６１０）。
具体的には、下記式に基づいてＳ４６１０の判定が行われる。
【数６】
但し、上記式においてRiはi番目に行われた更新データのデータ量、Ｄはサーバに送るべき更新データのデータ量である。
【００９４】
上記Ｓ４６１０において更新要求クライアントは今まで送ったデータのデータ量の合計値が、サーバに送るべき更新データのデータ量を超えている(上記式が成立している）と判定した場合（Ｓ４６１０、Ｙｅｓ）、更新要求クライアントはサーバに更新データを返す（Ｓ４６１１）。これで更新要求クライアントによる差分検索応答は終了する。
【００９５】
一方、上記Ｓ４６１０において更新要求クライアントは今まで送ったデータのデータ量の合計値が、サーバに送るべき更新データのデータ量を超えていない（上記式が成立していない)と判定した場合（Ｓ４６１０、Ｎｏ）、Ｓ４６０９で得られた差分検索結果をサーバに返す（Ｓ４６１２）。さらに更新要求クライアントは送ったデータ量Ｒｉを保持する。後に、今まで送った更新データのデータ量の合計値を算出し、Ｓ４６１０の判定を行うためである。これで更新要求クライアントによる差分検索応答は終了する。
【００９６】
[（６）更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付]
弱いネットワーク環境下にあった更新要求クライアントが強いネットワーク環境下に入った場合、更新要求クライアントによる更新要求並びにサーバによるユーザ更新要求受付が行われる。図４７は、上記更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付処理例を示したフローチャートである。以下このフローチャートを参照しながら更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付を説明する。
【００９７】
更新要求クライアントはまず、更新通知のみの更新データをサーバに送信する（Ｓ４７０１）。次に、更新要求クライアントはサーバから実績値（ｐ，ｎ，Ｒ）を取得する（Ｓ４７０２）。その後、更新クライアントは自己のデータベースとサーバのデータベースとの完全同期を実行する（Ｓ４７０３）。この完全同期の内容については後述する。完全同期終了後、更新要求クライアントは更新要求を終了する。
【００９８】
次に、サーバの更新要求受付について説明する。更新要求クライアントから送信された更新データを受信したサーバは、更新データを自己のデータベースに反映させる（Ｓ４７０４）。次に、サーバは前回の完全同期時刻と、更新通知日時と、現在時刻から稼働率ｐを算出する（Ｓ４７０５）。サーバは、差分検索のために送られたデータ量の合計Ｒｓｕｍを差分検索の実行回数ｎＲで割って、平均データ量Ｒを算出する（Ｓ４７０６）。次に、サーバは更新された実績値（ｎ，Ｒ，ｐ）を更新要求クライアントに送信する（Ｓ４７０７）。その後、サーバは更新要求クライアントとの間でデータベース内容の完全同期を実行する（Ｓ４７０８）。この完全同期の内容については後述する。完全同期終了後、サーバは更新要求受付を終了する。
【００９９】
最後に、更新要求クライアント及びサーバ間での完全同期処理について説明する。
完全同期処理を開始した更新要求クライアントはまず、自分のデータベースのVersionをサーバに通知する（Ｓ４７０９）。サーバは更新要求クライアントからデータベースのVersionを得る（Ｓ４７１０）と、更新要求クライアントに渡すべき差分となるデータを生成する（Ｓ４７１１）。次にサーバは、差分となるデータを更新要求クライアントに送信する（Ｓ４７１２）。更新要求クライアントはサーバから差分となるデータを受信する（Ｓ４７１３）。更新クライアントは受信した差分となるデータを自己のデータベースに更新させる（Ｓ４７１４）。これで、更新クライアント及びサーバ間のデータベース完全同期が完了する。
【０１００】
[本実施の形態の効果的な状況]
本実施の形態は、下記のような状況下でとりわけ有効である。
１．サーバ、クライアント間が近距離では安価で高速な通信ができ、遠距離では高価で低速でも通信が可能であること。
このような環境下で、本実施の形態は、近距離では同期による更新をし、遠距離では本提案を実施する。
２．一定間隔で、データベースがリフレッシュできること
充電のついでに完全同期できるなど、そのような完全同期がある期間内には行われる環境であること。
３．クライアント側で入力されるような、更新データが大量であるが、検索対象になりにくい環境下であること。
同期するまで、当面、検索されないようなものほど本実施の形態は効果がある。
上記において「近距離」とは例えば、（通信の）コストが小さい環境を意味し、「遠距離」とは例えば、（通信の）コストが大きい環境を意味する。
ここでいう「コスト」とは、通信に伴う料金（課金額）や、通信速度、レイテンシィ、電力消費量などを一つ乃至は複数考慮して決定する定量的なものを意味する。
【０１０１】
[本差分検索システムのデータ更新のまとめ]
本実施の形態によれば、以下のメリットを享受できる。
１．データを更新する際、悪い通信環境での通信量を減らすことができるため、ネットワーク管理者から見てネットワークトラフィックが減り、ユーザから見た場合に通信費用が減る。
２．サーバの負担を減らすことも可能となる。
なお、[本差分検索システムのデータ更新]は、第１の実施から第５の実施の
更新時に適用でき、また第６の実施にも適用できる。
【０１０２】
（第６の実施の形態）
次に、本実施の形態に係る第６の実施の形態について述べる。第６の実施の形態は、基本的に前述の第１の実施の形態から第５の実施の形態と同様の構成及び動作をするデータベースシステムであるが、本実施の形態は、サーバを使用することなく、クライアント間で差分検索を行い、及び／又は、クライアント間でデータベースを最新の状態に更新できるデータベースシステムである点で異なっている。
【０１０３】
[第６の実施の形態の構成例]
第６の実施の形態は、第１から第５の実施の形態における情報管理装置（以下の説明では、サーバとも称する）に相当する装置を有する構成としても成立するが、サーバを設けない構成としても本実施の形態は成立する。以下の説明ではサーバを設けない場合の構成として、本実施の形態の説明を行う。
【０１０４】
［用語］
本実施の形態の説明で使用する用語は、特にことわりのない場合、以下の意味を有する。
【０１０５】
「同期」とは、マスター・クライアントとノード・クライアントとの間で、データベース内のデータを共有している状態、若しくは共有化するための処理を意味する。
【０１０６】
「差分把握」とは、ノード・クライアントとマスター・クライアントのデータの差分を互いのバージョンから把握し、検索処理において重複したデータを検索しないようにすることである。
【０１０７】
「差分検索」とは、差分データ、すなわち同期がとれていないデータに対する検索をいい、マスター・クライアントが実行するものである。因みに、差分があるかどうか検索するわけではない。
【０１０８】
「変更履歴」とは、データベース内のデータについて変更履歴で変更した差分を管理する。変更履歴は、「バージョン」と「データＩＤ」の組を持っている。
【０１０９】
「バージョン」とは、本データベースシステム内でマスター・クライアントが一意に発行する数字で、データベース内のデータについて変更が行われたらバージョンが１つあがる。本実施形態において「バージョン」は、「差分把握」及び「差分検索」を簡単にするための仕組みである。
【０１１０】
図４８に、第６の実施の形態のシステム構成例を示したブロック図を示す。図４８に図示するように、システム４８００は、マスターとなる情報端末装置（以下、区別のためマスター・クライアントとも呼ぶ）４８０１と、例えばインターネット網、無線通信網、無線ＬＡＮなどの通信網４８０２でクライアント機器となる情報端末装置（以下、区別のためノード・クライアントとも呼ぶ）４８０３とから構成されている。各クライアントは同一の通信網で接続されてもよいし、異なる通信網により接続されてもよい。例えば、マスター・クライアント４８０１と全てのノード・クライアント４８０３が無線ＬＡＮに接続されていても本実施の形態は成立し、またあるクライアント同士はインターネット網で接続されており、別のクライアント同士は無線ＬＡＮで接続されている状態でも本実施の形態は成立する。
【０１１１】
マスター・クライアント４８０１は後述する「責任」を有するクライアントである。ノード・クライアント４８０３は、「責任」を有さないクライアントである。マスター・クライアント４８０１とノード・クライアント４８０３とは、「責任」の有無について異なるだけであって、装置構成、機能は共にクライアントであって差異はない。マスター・クライアント４８０１とノード・クライアント４８０３を区別しない場合には、単に「クライアント４８０１（４８０３）」と呼ぶこととする。
【０１１２】
「責任」を有するクライアント、すなわちマスター・クライアント４８０１は、ノード・クライアント４８０３の求めに応じて、後述する「つなぎかえ指定」、「差分検索」、データベースの同期を行うことができる唯一の装置である。なお、「責任」を有するか否かは、後述する「更新権」の有無によって識別される。「責任」を有するクライアントは、「更新権」を有するクライアントである。
【０１１３】
クライアント４８０１（４８０３）は、通信機能を有する情報処理装置、より詳しくは演算処理装置（ＣＰＵ）、主メモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、入出力装置（Ｉ／Ｏ）、必要な場合にはハードディスク装置等の外部記憶装置を具備している情報処理装置、あるいはそのような情報処理装置を含む装置である。クライアント４８０１（４８０３）は、データベース機能を備えるものであれば、どのような情報処理装置であってもよく、例えば携帯電話や携帯プレーヤが好適である。所謂、ウルトラモバイルＰＣと称されるものでもよい。
【０１１４】
図４９は、本実施形態に係るクライアント４８０１（４８０３）の機能ブロック図である。クライアント４８０１（４８０３）は、ユーザインターフェース４９０１、接続部４９０２、命令制御部４９０３、ＳＱＬ実行部４９０４、及びデータベース４９０５を有している。ユーザインターフェース４９０１及び接続部４９０２は命令制御部４９０３に接続されている。命令制御部４９０３はＳＱＬ実行部４９０４に接続されており、ＳＱＬ実行部４９０４はデータベース４９０５に接続されている。接続部４９０２は無線回線、あるいは有線回線を介して通信網４８０２に接続可能である。また、データベース４９０５は、データ４９０６、バージョン４９０７、変更履歴４９０８を記憶している。
【０１１５】
ユーザインターフェース４８０１は、ユーザの入力を受け付けるとともに、処理結果を表示する機能を有する。例えば、液晶ディスプレイ装置及びタッチパネルなどである。接続部４９０２は、通信網４８０２を介して他のクライアント４８０１（４８０３）と通信する機能を有する。
【０１１６】
命令制御部４９０３は、ユーザや他のクライアント４８０１（４８０３）からの要求や命令に応じて、所定の命令を実行し、必要に応じてＳＱＬ実行部４９０４や接続部４９０２に命令を出し、あるいは結果をユーザインターフェース４９０１に表示させる。図５０は、命令制御部４９０３の一構成例を示す機能ブロック図である。命令制御部４９０３は、接続開始部５００１、接続受付部５００２、接続停止部５００３、接続終了部５００４、差分通知部５００５、差分除去部５００６、差分検索部５００７、ＳＱＬ受付部５００８、結果取得部５００９、結果送信部５０１０、ネットワーク利用判断部５０１１、同期送信部５０１２、同期受信部５０１３、更新権利取得部５０１４、更新権利破棄部５０１５、つなぎかえ指定部５０１６、つなぎかえ処理部５０１７、最新保証処理部５０１８、つなぎかえ要求部５０１９、最新保証通知部５０２０、最新保証切れ部５０２１、判定部５０２２という各命令処理部を有している。また、命令制御部４０９３は、同期内ノード５０２３、更新権５０２４、問い合わせ先５０２５、最新保証フラグ５０２６、予測データ５０２７を記憶しており、本実施の形態の記憶手段として機能する。
【０１１７】
以下に、上記命令処理部のそれぞれについて説明する。
接続開始部５００１は、あるクライアントが他のクライアントとの通信を確立させるための処理を行う。
【０１１８】
接続受付部５００２は、他のクライアントからの接続要求を受けた場合、当該クライアントとの通信を確立する処理を行う。
【０１１９】
接続終了部５００３は、接続開始後、必要な処理が終了したのちに他のクライアントとの通信を解除する処理を行う。
接続停止部５００４は、接続のために用意していたメモリや通信部などの資源を解放するために他のクライアントからの求めに応じて確立させた通信を解除する処理を行う。
差分通知部５００５は、ノード・クライアント４８０３が自己のデータベースのバージョンをマスター・クライアント４８０１に通知して、互いのバージョンからデータの差分をマスター・クライアントに把握させる処理を行う。
差分除去部５００６は、差分データを無効化する処理を行う。
差分検索部５００７は、差分検索処理を実行する。
ＳＱＬ受付部５００８は、他のクライアントからＳＱＬ文を取得し、取得したＳＱＬ文をＳＱＬ実行部４９０４に渡す処理を行う。
結果取得部５００９は、前述の結果送信により送信されたデータを取得する処理を行う。
結果送信部５０１０は、ＳＱＬ実行部４９０４がＳＱＬ文を実行した結果をＳＱＬ文の送信元である他のクライアント４８０１（４８０３）に送信させる処理を行う。
ネットワーク利用判断部５０１１は、そのクライアント４８０１（４８０３）が使用しているネットワーク（通信網４８０２に相当）が「強いネットワーク環境」であるのか、「弱いネットワーク環境」であるのかを判定する。
同期送信部５０１２は、他のクライアント４８０１（４８０３）から同期を求められた場合、同期させるためのデータベースのデータを当該クライアント４８０１（４８０３）に送信させる処理を行う。
同期受信部５０１３は、上記「同期送信」に他のクライアント４８０１（４８０３）から送信されたデータを受信し、データベース４９０５の内容を同期させる処理を行う。
更新権利取得部５０１４は、「責任」を有するマスター・クライアント４８０１からその「責任」を取得する処理を行う。具体的には、「責任」の有無に応じて更新権５０２４の書き換えを行う。
更新権利破棄部５０１５は、自己の更新権５０２４を責任を有さないことを示すように書き換える。具体的には、「責任」の有無に応じて更新権５０２４の書き換えを行う。
つなぎかえ指定部５０１６は、つなぎかえ要求を送信したクライアント４８０３に対して、新しい「問い合わせ先」となるクライアントを通知する処理を行う。つなぎかえ指定５０１６は、本実施の形態のつなぎかえ指定手段に相当する。
つなぎかえ処理部５０１７は、つなぎかえ指定を受信したノード・クライアント４８０３が、問い合わせ先５０２５を更新する処理を行う。つなぎかえ処理５０１７は、本実施の形態のつなぎかえ処理手段に相当する。
つなぎかえ要求部５０１９は、現在「責任」を有しているマスター・クライアント４８０１を通知するよう求める処理を行う。つなぎかえ要求部５０１９は、本実施の形態のつなぎかえ要求手段に相当する。
【０１２０】
判定部５０２２は、予測データ５０２７に基づいて、つなぎかえ要求の要否の判定を行う。
【０１２１】
次に、命令制御部４９０３が有する各データについて説明する。
同期内ノード５０２３は、データベース４９０５の同期を行っている他のクライアント４８０１（４８０３）のリストである。
【０１２２】
更新権５０２４は、そのクライアント４８０１（４８０３）が「責任」、すなわち更新権利があるかどうかを示す情報である、例えば、更新権の内容が「１」なら自分が責任を有するマスター・クライアント４８０１であることを示し、「０」であれば自分は「責任」を有さないノード・クライアント４０８３であることを示す。更新権５０２４を所有するクライアントは、その時点でデータベース４９０５の内容が最新の内容であるクライアントであり、同時に複数は存在しえない。但し、「責任」、すなわち更新権は、データベースが更新されるごとに、クライアント間で移転していく。
【０１２３】
問い合わせ先５０２５は、自分よりも新しいバージョンのクライアント４８０１（４８０３）をひとつ覚えておくためのノードの連結情報である。但し、問い合わせ先であるクライアントがその時点でまだ責任を有しているかどうかはわからない。
【０１２４】
予測データ５０２７は、つなぎかえを行うか否かを判断するための予測値・実績値である。予測データには、ノード全体数、自分に属している子のノード数、更新確率・検索確率などが含まれる。予測データ５０２７については、クライアント４８０１（４８０３）は同期時に互いに情報交換することができるので、同期している他のノードの情報を使うことが可能である。
【０１２５】
図４９に戻り、クライアントの構成例の説明を続ける。
ＳＱＬ実行部４９０４は、データベース４９０５に対する命令であるＳＱＬ文を用いて、命令制御部４９０３からの要求にしたがってデータベース４９０５への操作や定義づけを行う機能を有する。
【０１２６】
データベース２４は、追加・変更・削除されたデータ４９０６と変更履歴４９０８とバージョン４９０７を記憶する。データ４９０６は、データベースを構成する個々のデータ要素の集合である。バージョン４９０７は、データ４９０６に対応する現在のバージョンを表す情報である。変更履歴４９０８は、データベース４９０５内のデータ４９０６について、変更した差分を管理するための情報である。図５１は、変更履歴４９０８の記憶内容の例を示すブロック図である。変更履歴は、差分把握可能範囲５１０１と、バージョン５１０２とデータＩＤ５１０３とを含む。差分把握可能範囲５１０１は、極端に古いバージョンのデータベースしか保持していないクライアント機器をケアする場合に対応するための情報であって、差分検索が可能な範囲を示す情報である。バージョン５１０２とデータＩＤ５１０３とは組になっており、データＩＤ５１０３は対応するバージョンにおいて追加・変更・削除されたデータ要素を特定する識別情報である。
【０１２７】
[本実施の形態の動作例について]
次に、本実施の形態に係るデータベースシステム４８００の動作例を説明する。
[責任の移転：２クライアント間の場合]
本実施の形態では、サーバを使用することなく、クライアント間で検索を行い、及びデータベースを最新の状態に更新できることを特徴の一つとしている。このための仕組みとして、本実施の形態では最新データを所持するクライアントが「責任」を有する。「責任」の有無は前述の更新権５０２４の内容によって識別される。前述の通り、「責任」を有するクライアントはマスター・クライアント４８０１となり、そうでないクライアントはノード・クライアント４８０３となるが、「責任」が移動することによって、マスター・クライアント４８０１はノード・クライアント４８０３となり、一方ノード・クライアント４８０３がマスター・クライアント４８０１になる。
【０１２８】
図５２に、１つのマスター・クライアントと、１つのノード・クライアントの間での責任の移転の例を示す。あるクライアントＡ（この時点ではノード・クライアント）が自己のデータベースを最新の状態にするべく、データベースの更新処理を行おうとする場合、その時点で「責任」を有するマスター・クライアントＢに対して更新要求を送信する（Ｓ５２０１）。更新要求を受信したマスター・クライアントＢはノード・クライアントＢにデータベースの更新をさせるとともに、更新要求の送信元であるノード・クライアントＡに「責任」を渡す。データベースの内容を最新の内容に更新し、新たに「責任」を保有したノード・クライアントＡは、以後マスター・クライアントＡとして振る舞うことになり、「責任」を保有しなくなったマスター・クライアントＢは以後ノード・クライアントＢとして振る舞うことになる。すなわち、以後、ノード・クライアントＢは、「責任」を受け取ったマスター・クライアントＡに問い合わせを行う。なお、「責任」の受け渡しに相当するデータ処理方法については後述する。
【０１２９】
[責任の移転：３クライアントの場合]
次に、３つのクライアントが関与する場合の「責任」の移転について説明する。図５３は、あるデータａについての「責任」が移転する例を示す。図５３に示した例では、３つのクライアントは相互に通信可能な状態にあるものとする。クライアントＡはデータａについて責任を有している。残りの２つのクライアント、クライアントＢ、クライアントＣは共にデータａについてデータベース記憶内容の更新を必要としている状態にあり、クライアントＢ、クライアントＣはデータａについてクライアントＡが責任を有すると記憶している。図中の矢印は、矢印の元にあるクライアントから見た、責任を有するクライアント、すなわち「問い合わせ先」に記述されたクライアントを示している。
【０１３０】
ここで、クライアントＢがクライアントＡに対してデータａについて更新要求を行ったものとする。クライアントＡはクライアントＢに対して最新の内容のデータａを送信する。クライアントＢの有するデータベース内容はデータａについて更新され、最新の内容となる。このときクライアントＡはデータａについての「責任」をクライアントＢに渡す。クライアントＢはこの「責任」を取得し、データａについて自分が「責任」を有すると記憶する。また、クライアントＡはデータａについての責任はクライアントＢが有するものと記憶する。図５４は図５３の状態から責任が移転した後の状態を示す図である。クライアントＢはこの「責任」を取得し、データａについて自分が責任を有すると記憶し、クライアントＡは、自分は「責任」を破棄し、データａについての責任はクライアントＢが有するものと記憶した状態を示す。クライアントＣは以前と変わらず、データａについてクライアントＡが責任を有すると記憶している状態が継続する。
【０１３１】
[最新の検索（差分把握）]
本実施の形態は、サーバ不要で、最新の内容のデータベースの検索することができる。
【０１３２】
各クライアントは、最新のデータベースの内容を検索をするためには、責任を有するクライアントに問い合わせすることが必要である。これは、前述した実施の形態における差分検索でいう「差分把握」に相当する処理である。先の図５４で示した例に基づいて、本実施の形態における最新の検索について説明する。
【０１３３】
クライアントＣは、最新のデータであるデータａについてクライアントＡが責任を有していると記憶している。クライアントＢはデータａについて自分が責任を有すると記憶し、クライアントＡはデータａについての責任はクライアントＢが有するものと記憶している状態である。
【０１３４】
クライアントＣはクライアントＡがデータａについて責任を有していると記憶しているので、クライアントＣはクライアントＡに問い合わせ(差分通知)を送信する。
【０１３５】
問い合わせ（差分通知）を受信したクライアントＡはデータａについて責任を持っておらず、且つ、クライアントＡはクライアントＢに聞くという情報を持っているので、クライアントＢにデータａについて問い合わせ（差分通知）を送信(転送、中継)する。クライアントＢはデータａについて責任を有しているので、自己が記憶する最新のデータａとの差分内容をクライアントＣに送信する。よって、クライアントＣは「責任」を有するクライアントとの差分を把握することができる。
【０１３６】
[連鎖問い合わせ：（差分検索）のつなぎかえ]
本実施の形態では、クライアントがデータベースを検索する場合において、最新のマスター・クライアント４８０１がどのクライアントであるかを把握することができるようになる。
【０１３７】
図５４は、クライアントＣは、最新のデータであるデータａについてクライアントＡが責任を有していると記憶している。クライアントＢはデータａについて自分が責任を有すると記憶し、クライアントＡはデータａについての責任はクライアントＢが有するものと記憶している状態である。
【０１３８】
ここで、クライアントＣがデータａについて検索を行おうとする場合、まずデータａについて責任を有する（とクライアントＣが記憶している）クライアントＡに問い合わせる。クライアントＡはデータａについての責任はクライアントＢが有するものと記憶しているので、データａについてクライアントＢに問い合わせる。すなわち、それぞれのクライアントにおいて「問い合わせ先」となっているクライアントに対して連鎖的に問い合わせが行われる。問い合わせに対してマスター・クライアント４８０１から応答がなされ、各クライアントは、今現在「責任」を有するクライアントを示す情報である問い合わせ先５０２５を更新する（「つなぎかえ」と呼ぶ）ことができる。但し、つなぎかえはつなぎかえをした方が有利な場合と判定された場合に行われ、常につなぎかえが行われるわけではない。図５４の状態の後、つなぎかえが行われた状態を図５５に示す。クライアントＣの「問い合わせ先」が更新され、現在のマスター・クライアントＢが新たな「問い合わせ先」として登録される。クライアントＡについて「問い合わせ先」の変更はない。
【０１３９】
[連鎖問い合わせ：更新の際のつなぎかえ]
本実施の形態では、クライアントがデータベースを更新する場合において、サーバを用いることなく更新を行うことができ、更新の際には、最新のマスター・クライアント４８０１がどのクライアントであるかを把握することができるようになる。
【０１４０】
図５６は、クライアント間でのデータベース更新前のある状態を示す図である。クライアントＣは、最新のデータであるデータａについてクライアントＡが責任を有していると記憶している。クライアントＢはデータａについて自分が責任を有すると記憶し、クライアントＡはデータａについての責任はクライアントＢが有するものと記憶している状態である。
【０１４１】
ここで、クライアントＣがデータａについてデータベースの更新を行おうとする場合、まずデータａについて責任を有する（とクライアントＣが記憶している）クライアントＡに問い合わせる。クライアントＡはデータａについての責任はクライアントＢが有するものと記憶しているので、データａについてクライアントＢに問い合わせる。すなわち、「問い合わせ先」となっているクライアントに対して連鎖的に問い合わせが行われる。
【０１４２】
クライアントＣがクライアントＢよりデータを取得し、データベースの内容を最新の内容に更新すると、データａについての責任はクライアントＢからクライアントＣに渡され、クライアントＣが新たに責任を有する状態になる。
【０１４３】
この場合、経由したクライアント（問い合わせに関与したクライアント）は、責任を有するクライアントの情報である問い合わせ先５０２５を書き換える（「つなぎかえ」と呼ぶ）。すなわち、クライアントＡ、クライアントＢはデータａについてクライアントＣが責任を有すると、記憶するように問い合わせ先５０２５を書き換える。但し、つなぎかえはつなぎかえをした方が有利な場合と判定された場合に行われる。図５６の後につなぎかえが行われた状態を図５７に示す。クライアントＡ，クライアントＢの「問い合わせ先」が更新され、現在のマスター・クライアントＣが新たな「問い合わせ先」として登録される。
【０１４４】
[つなぎかえの要否]
各クライアントは、以下の判定条件式に基づいて、つなぎかえを行うか否かを判定し、判定結果に基づいてつなぎかえ処理を実行する。
【０１４５】
判定条件式は以下の通り
(投資)＜（同期するまでに検索する回数）×（問い合わせ通信の減る量）
上記式の投資は本実施の形態の第１の送信データ量に相当し、上記式の右辺は本実施の形態の第２の送信データ量に相当する。
【０１４６】
上記判定条件式が満たされる場合には、クライアント、より詳しくは判定部５０２２は、つなぎかえ処理を実行すると判定する。同期すれば、1段化にされるためである。
【０１４７】
「投資」は、つなぎかえを行うために必要な送信データ量であって、dと表す。「同期するまでに検索する回数」は予測値を用いる。予測値は予測データ５０２７から過去の平均値を算出することなど適宜な方法によって得る。「問い合わせ通信の減る量」は（h-１）dにより算出される値である。ｈはそのクライアントから最新ノード（実際に責任を有するクライアント）までの高さ(階層差）である。また、「同期するまでに検索する回数」は、そのクライアントに属している子ノードの数Ｃに比例する。なお、高さ(階層差）及び子ノードは、本実施の形態に係るデータベースシステムを、最新ノード（実際に責任を有するクライアント）を根ノードとし、問い合わせ先のクライアントを親ノードとする木構造と見た場合の概念である。
【０１４８】
[つなぎかえの判定例]
上記判定条件式による判定例を以下に述べる。
【０１４９】
投資＝つなぎかえを行うために必要な送信データ量dとし、「同期するまでに検索する回数」は、（（属している子の数）＋１（自分））×（平均問い合わせ確率）×（同期していない確率）により算出するものとする。
【０１５０】
問い合わせ通信の減る量は、（（自分の高さ）−１）×ｄ
属している子の数＝C、平均問い合わせ確率＝ｎ、データベースのデータが完全である確率＝ｐ、自分の高さをｈとすると、条件判定式は以下のように表現される。
d ≦ (C+1)×ｎ×(1-p)×（h-1）×d …(条件判定式)
【０１５１】
なお、最新ノード（マスター・クライアント）に直結している場合は、h=1となり、つなぎかえの必要性は生じない(右辺＝０となるため、ｄ＞０なら条件判定式は常に不成立）。また、属している子の数Ｃと問い合わせ確率ｎが大きいほど、判定条件式が満たされる可能性が高まる。これは、子の数だけ問い合わせ頻度が大きくなるためである。
【０１５２】
上記条件判定式の確率ｐについて説明する。
マスター・クライアント４８０１（他の実施の形態のサーバに相当する）のデータベース中のデータが完全である確率をｐとすると、他のクライアントに更新データの存在を確認しなければいけない確率、すなわち「同期していない確率」は（１−ｐ）となる。具体例で説明すると、１日のうち９割はマスター・クライアント４８０１とノード・クライアント４８０３とが同期できる環境となると設定すれば、確率ｐは０．９であり「同期していない確率」（１−ｐ）は０．１となる。
【０１５３】
次に平均問い合わせ確率ｎについて説明する。平均問い合わせ確率ｎは、１クライアントあたりのある一定期間での検索回数である。平均して1日あたり0.4回の検索をした場合では、平均問い合わせ確率ｎは0.4（/日）である。
【０１５４】
図５８に、条件判定式の計算例を説明するための図を掲げる。この例では、最新データを有し、「責任」を有するマスター・クライアント４８０１(図中、Ｒと表示する)、このマスター・クライアント４８０１を問い合わせ先５０２５に記憶しているノード・クライアント４８０３(図中、Ｎ１と表示)、ノード・クライアントＮ１を問い合わせ先５０２５に記憶しているノード・クライアント４８０３(図中、Ｎ２と表示)、ノード・クライアントＮ２を直接、又は間接に問い合わせるノード・クライアント４８０３の集団（ノード・クライアントＮ２の下位ノード集団と呼ぶ）がある。このとき、ノード・クライアントＮ１の高さｈ＝１、ノード・クライアントＮ２の高さｈ＝２となる。また、ノード・クライアントＮ２の下位ノード集団に含まれるノード・クライアント数Ｃ＝２９とする。
【０１５５】
ここで、上記条件下においてノード・クライアントＮ２が条件判定式を用いてつなぎかえの要否を判定するとどのようになるかを述べる。
【０１５６】
ノード・クライアントＮ２について、d ≦ (C+1)×ｎ×(1-p)×（h-1）×d の式を考えると、
Ｃ＝２９、ｎ＝０．４、Ｐ＝０．９、ｈ＝２であるからこれらを代入して
d ≦ (29+1)×0.4×0.1×(2-1)×d = 1.2d …(式１）
となる。よってｄ＞０であれば上記不等式１は成立し、式１の結果より、ノード・クライアントＮ２はつなぎかえを実施すると判定する。
【０１５７】
次に、上記条件下においてノード・クライアントＮ１が条件判定式を用いてつなぎかえの要否を判定するとどのようになるかを述べる。
【０１５８】
ノード・クライアントＮ１について、条件判定式、d ≦ (C+1)×ｎ×(1-p)×（h-1）×d の式を考えると、
Ｃ＝３０、ｎ＝０．４、Ｐ＝０．９、ｈ＝１であるからこれらを代入して
d ≦ (30+1)×0.4×(1-0.9)×(1-1)×d =0 …(式２）
【０１５９】
送信データ量ｄは０以下ではありえないので、式２の不等式は成立しない。
したがって、ノード・クライアントＮ１はつなぎかえを実施しないと判定することになる。
【０１６０】
さらに別の例で条件判定式の計算例を説明する。図５９に条件判定式の計算例を説明するための別の図を掲げる。図５９に示す例は、マスター・クライアントＲ，ノード・クライアントＮ１、ノード・クライアントＮ２については先の図５８に示した例と同じ条件とする。ノード・クライアントＮ２には、その子ノードである、ノード・クライアントＮ２を問い合わせ先５０２５とするノード・クライアント４８０３(区別のためＮ３と呼ぶ）が存在し、ノード・クライアントＮ３には、直接又は間接に問い合わせを送信するノード・クライアント４８０３の集団（ノード・クライアントＮ３の子ノード集団と呼ぶ)が存在する。なお、ノード・クライアントＮ３の子ノード集団の個数Ｃ＝９であるとする。ノード・クライアントＮ３の高さｈ＝３である。
【０１６１】
ノード・クライアントＮ３について、条件判定式、d ≦ (C+1)×ｎ×(1-p)×（h-1）×d の式を考えると、
Ｃ＝９、ｎ＝０．４、Ｐ＝０．９、ｈ＝３であるからこれらを代入して
d ≦ (9+1)×0.4×0.1×(3-1)×d = 0.8d …(式３)
である。つなぎかえに必要な送信データ量は常にｄ＞０であるから、上記式３の不等式は成立せず、子の条件下ではノード・クライアントＮ３はつなぎかえを実施しないと判定することになる。但し、前述の通り、ノード・クライアントＮ２において判定すると、式２に示した結果より、ノード・クライアントＮ２はつなぎかえを実施する。すなわち、同じノード内でも、つなぎかえを行うクライアントと行わないノードが混在することありうる。
【０１６２】
[つなぎかえの処理例]
次に、本実施の形態におけるつなぎかえの動作例について説明する。
図６０にサーバを用いることなく検索を行う場合の、本実施の形態に係るデータベース・システムの動作例をシーケンス図として示す。図６０に示す例では、１つのマスター・クライアント４８０１、及び３つのノード・クライアント４８０３（互いを区別するため、マスター・クライアント４８０１をクライアントＲ、３つのノード・クライアント４８０３をクライアントＮ１、クライアントＮ２，クライアントＮ３と呼ぶ）が存在している。
【０１６３】
クライアントＮ３は責任を有するのはクライアントＮ２であると記憶しており、クライアントＮ２は責任を有するのはクライアントＮ１であると記憶しており、クライアントＮ１は責任を有するのはクライアントＲであると記憶しており、実際に責任を有しているのはクライアントＲである。
【０１６４】
ここで、クライアントＮ３がデータベースの検索を行おうとしたとする。まず、検索を実行しようとするクライアントＮ３は、差分通知要求（Ｓ６００１）とつなぎかえ要求（Ｓ６００２）をクライアントＮ２に送信する。
つなぎかえ要求には、つなぎ換えを行った方が有利となるか否かを判定してもらうために必要なデータ（判定用データと呼ぶ）が含まれている。ここではクライアントＮ３の高さｈ、子ノード集団の個数Ｃがつなぎかえ要求のメッセージに付加されているとする。具体例としては
Ｎ３：ｈ＝１、Ｃ＝９
のような判定用データである。
【０１６５】
クライアントＮ３から差分通知要求とつなぎかえ要求を受信したクライアントＮ２は自分は責任を有していないので、責任を有すると記憶しているクライアントＮ１に差分通知要求を送信（転送）する（Ｓ６００３）。また、クライアントＮ２は差分通知要求（Ｓ６００３）とともに、クライアントＮ３から受信した判定用データとともに、自己分の判定用データを含めたつなぎかえ要求（Ｓ６００４）をクライアントＮ１に送信する。具体的にはクライアントＮ３分の判定用データと、自己（Ｎ２)の判定用データが含まれる。その内容は以下のとおりである。
Ｎ３：ｈ＝２、Ｃ＝９
Ｎ２：ｈ＝１、Ｃ＝２９
なお、他のクライアントから受け取った判定用データ中のｈの値は1だけ増加された値に変更される。
【０１６６】
クライアントＮ２から差分通知要求とつなぎかえ要求を受信したクライアントＮ１は自分は責任を有していないので、責任を有すると記憶しているクライアントＲに差分通知要求を送信（転送）する（Ｓ６００５）。また、クライアントＮ１は、差分通知要求（Ｓ６００５）を転送するとともに、他のクライアントから受信した判定用データ及び自己分の判定用データを含めたつなぎかえ要求（Ｓ６００６）をクライアントＲに送信する。具体的にはクライアントＮ３分の判定用データ、クライアントＮ２分の判定データと、自己（Ｎ１)の判定用データが含まれる。その内容は以下のとおりである。
Ｎ３：ｈ＝３、Ｃ＝９
Ｎ２：ｈ＝２、Ｃ＝２９
Ｎ１：ｈ＝１、Ｃ＝３０
なお、他のクライアントから受け取った判定用データ中のｈの値は1だけ増加された値に変更される。
【０１６７】
クライアントＲは自己が責任を有するクライアントであると記憶しているので、受信したつなぎかえ要求に応答する。すなわち、クライアントＲは、責任を有するクライアントをクライアントＲとして記憶するように指令するつなぎかえ指定をクライアントＮ２に送信する（Ｓ６００７）。つなぎかえ指定を受信したクライアントＮ２は責任を有するクライアントをクライアントＲとするように記憶内容、すなわち問い合わせ先５０２５の内容を更新するつなぎかえ処理を行う（Ｓ６００８）。
【０１６８】
さらにクライアントＲはクライアントＮ３にもつなぎかえ指定を送信する（Ｓ６０１０）し、また差分通知要求（Ｓ６００１）に対応する結果送信（Ｓ６００９）を行う。
【０１６９】
つなぎかえ指定（Ｓ６０１０）を受信したクライアントＮ３は責任を有するクライアントをクライアントＲとするように記憶内容、すなわち問い合わせ先５０２５の内容を更新する（Ｓ６０１１）。また、クライアントＮ３は結果送信（Ｓ６０１１）の内容に基づいて差分除去を行う（Ｓ６０１２）。
【０１７０】
次に、クライアントＮ３は差分除去（Ｓ６０１２）後のデータベースの内容に基づいて、差分検索の要求をクライアントＲに送信する（Ｓ６０１３）。差分検索の要求を受信したクライアントＲはＳＱＬ受付を行う（Ｓ６０１４）。ＳＱＬの内容に基づいてデータベース検索を実行し差分検索結果を生成したクライアントＲは、結果をクライアントＮ３に送信する（Ｓ６０１５）。クライアントＲから差分検索結果を受信（Ｓ６０１６）したクライアントＮ３は自己のデータベース検索内容とクライアントＲの差分検索内容により、完全な最新のデータベース内容についての検索結果を得られることになる。
【０１７１】
また、検索に関する処理の一方、つなぎかえ処理（Ｓ６００８、Ｓ６０１１）が行われたクライアントＮ３，Ｎ２については責任を有するクライアントＲに次回からはダイレクトに問い合わせを送信することが可能となる。
【０１７２】
[変形例]
上記の検索処理においては、差分通知要求と差分検索要求を別々に送信するものとして説明したが、本実施の形態では差分通知要求と差分検索要求を同時に送信するようにしても、サーバを用いない検索を成立させることができる。検索クエリが小さい場合はこのように同時に送信する方が有効(1パケット内に収まる)からである。
【０１７３】
図６１は、差分通知要求と差分検索要求を同時に送信するようにした場合の、サーバを用いることなく検索を行う場合の本実施の形態に係るデータベースシステムの動作例を示したシーケンス図である。
【０１７４】
ここで説明する例において、１つのマスター・クライアント４８０１、及び３つのノード・クライアント４８０３（互いを区別するため、マスター・クライアント４８０１をクライアントＲ、３つのノード・クライアント４８０３をクライアントＮ１、クライアントＮ２，クライアントＮ３と呼ぶ）が存在している。
【０１７５】
クライアントＮ３は責任を有するのはクライアントＮ２であると記憶しており、クライアントＮ２は責任を有するのはクライアントＮ１であると記憶しており、クライアントＮ１は責任を有するのはクライアントＲであると記憶しており、実際に責任を有しているのはクライアントＲである。
【０１７６】
まず、検索を実行しようとするクライアントＮ３は、差分通知要求及び検索要求（Ｓ６１０１）と、つなぎかえ要求（Ｓ６１０２）をクライアントＮ２に送信する。つなぎかえ要求には、自己分の判定用データが含まれている。
【０１７７】
差分通知要求及び検索要求（Ｓ６１０１）とつなぎかえ要求（Ｓ６１０２）を受信したクライアントＮ２は、自分は責任を有していないので、責任を有するクライアント、すなわち問い合わせ先５０２５に記憶しているクライアントＮ１に差分通知要求及び検索要求を送信する（Ｓ６１０３）。また、クライアントＮ２はクライアントＮ３から受信した判定用データとともに、自己分の判定用データを含めたつなぎかえ要求をクライアントＮ１に送信する（Ｓ６１０４）。具体的にはクライアントＮ３分の判定用データと、自己（Ｎ２)の判定用データが含まれる。
【０１７８】
差分通知要求及び検索要求（Ｓ６１０３）とつなぎかえ要求（Ｓ６１０４）を受信したクライアントＮ１は、自分は責任を有していないので、責任を有すると記憶しているクライアントＲに差分通知要求及び検索要求（Ｓ６１０５）を送信する。また、クライアントＮ１は他のクライアントから受信した判定用データ及び自己分の判定用データを含めたつなぎかえ要求（Ｓ６１０６）をクライアントＲに送信する。具体的にはクライアントＮ３分の判定用データ、クライアントＮ２分の判定データと、自己（Ｎ１)の判定用データが含まれる。
【０１７９】
差分通知要求及び検索要求、つなぎかえ要求を受信したクライアントＲは、差分通知要求に応じたＳＱＬ受付を行う（Ｓ６１０７）。
【０１８０】
また、クライアントＲは自己が責任を有するクライアントであると記憶しているので、つなぎかえ要求に応答する。すなわち、クライアントＲは、責任を有するクライアントをクライアントＲとして記憶するように指令するつなぎかえ指定をクライアントＮ２及びクライアントＮ３に送信する（Ｓ６１０８、Ｓ６１１１）。なお、この例ではクライアントＮ１についてはつなぎ換えを行っても有利にならないと判定されたため、クライアントＮ１についてはつなぎ換え指定は送信されないものとする。
つなぎ換え指定を受信したクライアントＮ２は、つなぎかえ指定（Ｓ６１０８）に応じて、問い合わせ先２０５５をクライアントＲとするように記憶内容を更新するつなぎかえ処理を行う（Ｓ６１０９）。
【０１８１】
次に、クライアントＲは差分通知要求に応答する差分把握を生成するとともに、ＳＱＬ受付（Ｓ６１０７）に基づいてデータベース検索を実行し差分検索結果を生成し、これらをクライアントＮ３に送信する（Ｓ６１１０）。また、クライアントＲはクライアントＮ３にもつなぎかえ指定を送信する（Ｓ６１０８）。
【０１８２】
クライアントＮ３は、クライアントＲから送信された結果送信の内容に基づいて差分除去を行う（Ｓ６１１４）。また、クライアントＮ３は、つなぎかえ指定（Ｓ６１１１）に応じて、問い合わせ先２０５５をクライアントＲとするように記憶内容を更新するつなぎかえ処理を行う（Ｓ６１１３）。
【０１８３】
最後に、クライアントＮ３は差分除去後の自己のデータベース検索内容とクライアントＲから受信した差分検索内容により、最新のデータベース内容についての検索結果を得られることになる。
【０１８４】
また、それぞれのつなぎかえ処理（Ｓ６１０８、Ｓ６１１１）により、クライアントＮ２，Ｎ３は、最新のデータを有するクライアントＲに次回からは他のクライアントを経由することなくダイレクトに問い合わせを送れるようになる。
【０１８５】
[クライアントの動作例]
次に、個々のクライアント４８０１（４８０３）の動作例について説明する。
[クライアントの動作例：検索の場合]
【０１８６】
図６２は、本データベースシステムにおいて、あるノード・クライアント４８０３がデータの検索（差分検索）を行うときの動作例を示したフローチャートである。
【０１８７】
検索（差分検索）を行う場合、ノード・クライアント４８０３（以下、区別のため起点クライアントと呼ぶ）、より詳しくは接続開始部５００１が問い合わせ先５０２５に記述されたクライアント４８０１（４８０３）（以下、「問い合わせ先クライアント」と称す）との通信を確立する（図略）。
【０１８８】
次にこの起点クライアント、より詳しくは差分通知部５００５は、問い合わせ先クライアントに差分通知要求を送信する（Ｓ６２０１）。
【０１８９】
次に、起点クライアント、より詳しくはそのつなぎかえ要求部５０１９は、問い合わせ先クライアントにつなぎかえ要求を送信する（Ｓ６２０２）。起点クライアント、より詳しくはそのつなぎかえ処理部５０１７は、データに対して「責任（更新権）」を有するクライアントからつなぎかえ指定が送信されてくるのを待ち受ける（Ｓ６２０３）。
【０１９０】
「責任（更新権）」を有するクライアントからつなぎかえ指定を受信すると、起点クライアント、より詳しくはそのつなぎかえ処理部５０１７は、つなぎかえ指定に記述されたクライアントを新たな問い合わせ先クライアントとするように、問い合わせ先５０２５の内容を書き換える処理であるつなぎかえ処理を実行する（Ｓ６２０５）。
【０１９１】
また、起点クライアント、より詳しくはその差分通知部５００５は、先に送信した差分通知要求（Ｓ６２０１）に応答する結果を待ち受ける（Ｓ６２０６）。「責任（更新権）」を有するクライアントから前記差分通知要求に対する結果を受信する（Ｓ６２０７）と、起点クライアント、より詳しくはその差分除去部５００５は、受信した結果に基づいてデータベースの４９０５の差分除去を行う（Ｓ６２０８）。
【０１９２】
次に、起点クライアント、より詳しくはその差分検索部５００７は、「責任（更新権）」を有するクライアントへ差分検索の要求を送信し（Ｓ６２０９）、「責任（更新権）」を有するクライアントから差分検索の結果を受信する（Ｓ６２１０）。
【０１９３】
次に、前述した起点クライアントから差分通知要求、つなぎかえ要求を受信する問い合わせ先クライアントの動作例について説明する。なお、問い合わせ先クライアントは、差分通知、つなぎかえ要求の双方に対応処理するのであるが、ここでは差分通知、つなぎかえ要求の対応を分けて説明する。
【０１９４】
［差分通知に対する対応］
図６３は問い合わせ先クライアントの差分通知要求に対する対応処理の一例を示したフローチャートである。まず、問い合わせ先クライアントは差分通知要求を受信する（Ｓ６３０１）。問い合わせ先クライアントは自己の更新権５０２４の内容を参照して、自己が更新権を保有しているか否かを判定する（Ｓ６３０２）。自己が更新権を保有していると判定した場合（Ｓ６３０２、Ｙｅｓ）、この問い合わせ先クライアントは、「責任（更新権）」を有するクライアントであるので、差分通知要求に応答して、差分通知を起点クライアントに送信し（Ｓ６３０３）、処理を終了する。
【０１９５】
一方、ステップＳ６３０２において自己が更新権を保有していないと判定した場合（Ｓ６３０２、Ｎｏ）、問い合わせ先クライアントは、自己の問い合わせ先５０２５に記述されたクライアント（区別のため、次段問い合わせ先クライアントと呼ぶ）に対して、起点クライアントから受信した差分通知要求を転送し（６３０４）、処理を終了する。この差分通知要求を転送された次段問い合わせ先クライアントは、同様にステップＳ６３０１からステップＳ６３０４までの処理を実行する。差分通知要求の転送は「責任（更新権）」を有するクライアントに到達するまで繰り返される。
【０１９６】
［つなぎかえ要求に対する対応］
次に、問い合わせ先クライアントのつなぎかえ要求に対する応答処理について説明する。図６４は、問い合わせ先クライアントのつなぎかえ要求に対する応答処理を示したフローチャートである。
【０１９７】
まず、問い合わせ先クライアントはつなぎかえ要求を受信する（Ｓ６４０１）。問い合わせ先クライアントは自己の更新権５０２４の内容を参照して、自己が更新権を保有しているか否かを判定する（Ｓ６４０２）。自己が更新権を保有していると判定した場合（Ｓ６４０２、Ｙｅｓ）、この問い合わせ先クライアントは、ステップＳ６４０１において受信したつなぎかえ要求に含まれるデータから、ノード１件分のデータを取得する（Ｓ６４０４）。
問い合わせ先クライアントは、取得したノード１件分のデータに基づいて当該ノードについてつなぎ換えを行わせた方が有利になるか否かを判定する（Ｓ６４０５）。有利にならないと判定した場合（Ｓ６４０５、Ｎｏ）、この問い合わせ先クライアントはそのまま処理を終了する。一方、有利になると判定した場合（Ｓ６４０５、Ｙｅｓ）、この問い合わせ先クライアントは、前記取得したノード１件分のデータに対応するクライアントに、自己を問い合わせ先とするようにつなぎかえ処理を行うよう指示するつなぎかえ指定を送信する（Ｓ６４０７）。
次に、この問い合わせ先クライアントはステップＳ６４０１において受信したつなぎかえ要求に含まれる、全てのノード分のデータを処理したか否かを判定する（Ｓ６４０７）。すべて処理したと判定した場合（Ｓ６４０７，Ｙｅｓ）、この問い合わせ先クライアントは処理を終了する。一方、すべて処理していないと判定した場合（Ｓ６４０７，Ｎｏ）、この問い合わせ先クライアントはステップＳ６４０４に戻り、未処理のノードのデータについてステップＳ６４０４からＳ６４０７の処理を繰り返し行う。
「責任（更新権）」を有するクライアントであるので、つなぎかえ要求に応答して、つなぎかえ指定を起点クライアントに送信し（Ｓ６４０３）、処理を終了する。
【０１９８】
一方、ステップＳ６３０２において自己が更新権を保有していないと判定した場合（Ｓ６３０２、Ｎｏ）、問い合わせ先クライアント、より詳しくはその判定部５０２２は起点クライアントから受信しているつなぎかえ要否判定に要するデータ、自己分のつなぎかえ要否判定に要するデータを含むつなぎかえ要求を、自己の問い合わせ先（すなわち、次段問い合わせ先クライアント）に送信するか否かを判定するため、前述の判定条件式を用いて、つなぎかえを行った方が送信データ量削減の観点等から有利であるか否かを判定する（Ｓ６４０４）。
【０１９９】
ステップＳ６４０２において、更新権を保有していないと判定した場合（Ｓ６４０２、Ｎｏ）、問い合わせ先クライアント、より詳しくはそのつなぎかえ要求部５０１９は、次段問い合わせ先クライアントにつなぎかえ要求を送信する（Ｓ６４０３）。なお、このつなぎかえ要求には、起点クライアントから受信しているつなぎかえ要否判定に要するデータ、自己分のつなぎかえ要否判定に要するデータが含まれるように構成される。
【０２００】
問い合わせ先クライアント、より詳しくはそのつなぎかえ処理部５０１７は、データに対して「責任（更新権）」を有するクライアントからつなぎかえ指定が送信されてくるのを待ち受ける（Ｓ６４０６）。
【０２０１】
「責任（更新権）」を有するクライアントからつなぎかえ指定を受信する（Ｓ６４０７）と、問い合わせクライアント、より詳しくはそのつなぎかえ処理部５０１７は、つなぎかえ指定に記述されたクライアントを新たな問い合わせ先クライアントとするように、問い合わせ先５０２５の内容を書き換える処理である問い合わせ処理を実行する（Ｓ６４０８）。
【０２０２】
問い合わせ先クライアントからつなぎかえ要求を送信若しくは転送された次段問い合わせ先クライアントは、同様にステップＳ６４０１からステップＳ６４０８までの処理を実行する。つなぎかえ要求の転送は「責任（更新権）」を有するクライアントに到達するまで繰り返される。
【０２０３】
[クライアントの動作例：更新（同期）の場合]
次に、本実施の形態に係るデータベースシステムにおいて、あるノード・クライアント４８０３がデータの更新（同期）を行うときの動作例について述べる。
【０２０４】
起点クライアントが更新要求を送信するに先だって、差分通知要求を行うため、更新（同期）の場合におけるつなぎかえ要求の送信、つなぎかえ要求の転送、つなぎかえ要求への応答は、図６２、図６４において説明した処理と同様となるので、ここでは詳細な内容の説明は省略する。
【０２０５】
次に、更新要求を受信した問い合わせ先クライアントの動作例について説明する。図６５は、更新要求を受信した問い合わせ先クライアントの動作例を示したフローチャートである。
【０２０６】
まず、問い合わせ先クライアントは更新要求を受信する（Ｓ６５０１）。問い合わせ先クライアントは自己の更新権５０２４の内容を参照して、自己が更新権を保有しているか否かを判定する（Ｓ６５０２）。自己が更新権を保有していると判定した場合（Ｓ６４０２、Ｙｅｓ）、この問い合わせ先クライアント、より詳しくは同期送信部５０１２は、「責任（更新権）」を有するクライアントであるので、更新要求に応答して、更新に必要なデータ（差分データ）を起点クライアントに送信し（Ｓ６５０３）、更新権利破棄部５０１５が更新権破棄処理を実行して、更新権５０２４の内容を更新権を保有しないことを示す情報を示すものに書き換え（Ｓ６５０４）、問い合わせ先５０２５の内容を新たに最新のデータベース内容を有することになった起点クライアントを示す情報に書き換え（Ｓ６５０５）、これを持って処理を終了する。
【０２０７】
一方、ステップＳ６５０２において自己が更新権を保有していないと判定した場合（Ｓ６５０２、Ｎｏ）、問い合わせ先クライアントは、自己の問い合わせ先５０２５に記述されたクライアント（区別のため、次段問い合わせ先クライアントと呼ぶ）に対して、起点クライアントから受信した更新要求を転送し（Ｓ６５０６）、処理を終了する。この更新要求を転送された次段問い合わせ先クライアントは、同様にステップＳ６５０１からステップＳ６５０６までの処理を実行する。更新要求の転送は「責任（更新権）」を有するクライアントに到達するまで繰り返される。
【０２０８】
［第６の実施の形態のまとめ］
（１）本実施の形態は、サーバレスなシステムを構築することを可能とする。
（２）本実施の形態では、クライアント間で検索や更新のための通信をするときコストが発生するが、それを無駄にしないことを可能とする。クライアント間で通信するときに、今後の負担（データベースシステム全体における送信データ量）を減らすデータのやり取りも実施するためである。
［備考］
上記第１から第６の実施の形態は、いずれか２以上の実施の形態を適宜選択し、それらを組み合わせても、本発明の実施の形態の範囲内であり、発明の一態様として成立する。
【符号の説明】
【０２０９】
４８００…データベースシステム
４８０１…マスター・クライアント
４８０３…ノード・クライアント
４９０３…命令制御部
４８０５…データベース
５０１４…更新権利取得
５０１５…更新権利破棄
５０１６…つなぎかえ指定
５０１７…つなぎかえ処理
５０１９…つなぎかえ要求
５０２２…判定部
５０２７…予測データ
【技術分野】
【０００１】
本明細書に記載の実施の形態は、データベース・システム、並びにそのクライアントに関する。
【背景技術】
【０００２】
最近、家電機器等において、組込み機器製品が高機能化し、機器自体がサーバになることが求められている。一方、サーバを利用するクライアント機器は、サーバが有するデータベースと同期するデータベースを有し、サーバと協働してデータベースの検索、データベースの更新を行い、ユーザが常に最新の内容のデータベースを利用できるシステムが提案されている。
【０００３】
このような、サーバを利用するデータベースシステムにおいて、検索において、クライアントが所有する最新でないデータベースを活用して、少ないデータの送受信量で最新のデータを検索することができたり、データベースの更新において、クライアントが大量のデータを更新したいとき、更新したことだけを通知することで、少ないデータの送受信量で更新データをデータベースに反映する技術も提案されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−１６４８４０号公報
【０００５】
【特許文献２】特開２００４−３４３２３４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来のサーバを利用するシステムでは、サーバの集中管理が必要であり、サーバの負荷を究極的に減らすことが困難であるという問題があった。サーバの負荷を究極的に減らす方法としては、サーバを利用しないシステムとすることが考えられるが、そのようなシステムにおいては、ある１クライアントに集中して問い合わせが発生して負荷がそのクライアントに集中してしまうという問題が発生する。
【０００７】
本実施の形態は、固定のサーバとなる装置を用いず、１つのクライアントに負荷が集中することなく、差分検索方式によるデータベースの検索、データベースの更新が可能な技術を提供することを目的とする。
【課題を解決するための手段】
【０００８】
一の実施の形態によれば、サーバを用いなくとも使用可能なデータベースシステムのためのクライアントが提案される。
【０００９】
このクライアントは、記憶手段と、判定手段と、つなぎかえ要求手段と、つなぎかえ指定手段と、つなぎかえ処理手段とを有する。
【００１０】
記憶手段は、自己が最新のデータベースの内容を保有しているか否かを示す情報である更新権と、差分検索又はデータベースの同期の相手となる他のクライアントを特定する情報である問い合わせ先を記憶する。判定手段は、つなぎかえを行うために要する第１の送信データ量が、つなぎかえを行わない場合における問い合わせを行うために要する第２の送信データ量より小さいか否かを判定する。
つなぎかえ要求手段は、前記判定手段が前記第１の送信データ量は前記第２の送信データ量より小さいと判定した場合、前記問い合わせ先が示す他のクライアントに、更新権を保有するクライアントを通知することを要求するメッセージであるつなぎかえ要求を送信させる。つなぎかえ指定手段は、前記更新権が更新権の保有を示しているときに他のクライアントからつなぎかえ要求を受信した場合、自己を前記問い合わせ先とすることを指示するメッセージであるつなぎかえ指定を前記他のクライアントに送信させる。つなぎかえ処理手段は、前記つなぎかえ指定を受信した場合、そのつなぎかえ指定において指定されたクライアントを前記問い合わせ先として記憶させる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態に係るクライアントサーバシステムの構成例を示す概念図
【図２】本発明の実施形態に係るクライアントサーバシステムの機能ブロック図
【図３】第１の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新及びバージョンを説明するための模式図
【図４】情報端末装置の情報管理装置に対する要求処理の流れを示すフローチャート
【図５】情報管理装置のユーザ情報端末装置の更新要求処理の流れを示すフローチャート
【図６】データベースの構造(中身）を模式化した図
【図７】データ量の比較を模式化した図
【図８】データ量の比較を模式化した図
【図９】データ量の比較を模式化した図
【図１０】データ量の比較を模式化した図
【図１１】変更履歴の追加がなされた場合のデータベースの構造（中身）の変化を例示する図
【図１２】変更発生時の変更履歴欄の更新処理の流れを示すフローチャート
【図１３】同期処理におけるデータベースの構造（中身）の変化を例示する図
【図１４】無効化処理におけるデータベースの構造（中身）の変化を例示する図
【図１５】探索要求時におけるデータベースの構造（中身）の変化を例示する図
【図１６】探索実行におけるデータベースの構造（中身）の変化を例示する図
【図１７】情報管理装置側における差分把握処理の流れを示すフローチャート
【図１８】情報端末装置側における差分除去処理の流れを示すフローチャート
【図１９】情報端末装置側における差分検索処理の流れを示すフローチャート
【図２０】情報管理装置における差分検索処理の流れを示すフローチャート
【図２１】変更履歴を用いた差分データからの検索処理を説明する図
【図２２】第２の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新及びバージョンを説明するための模式図
【図２３】変更発生時の変更履歴欄の更新処理の流れを示すフローチャート
【図２４】変更発生時の変更履歴欄の更新処理の流れを示すフローチャート
【図２５】変更発生時の変更履歴欄の更新処理の流れを示すフローチャート
【図２６】更新要求を受けつけた後の変更履歴処理全体の流れを示すフローチャート
【図２７】第３の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新及びバージョンを説明するための模式図
【図２８】変更発生時の変更履歴欄の更新処理の流れを示すフローチャート
【図２９】変更履歴の上位概念によるまとめ処理の流れを示すフローチャート
【図３０】第４の実施形態に係るクライアントサーバ型検索システムを説明する図
【図３１】情報管理装置における差分検索処理の流れを示すフローチャート
【図３２】第５の実施形態に係るクライアントサーバ型検索システムを説明する図
【図３３】情報管理装置における差分検索処理の流れを示すフローチャート
【図３４】送信データの決定処理の流れを示すフローチャート
【図３５】Ａ）は、ネットワーク環境が弱い状況下でのサーバ、クライアントＢを示した図、Ｂ）はネットワーク環境が強い状況下でのサーバ、クライアントＢを示した図
【図３６】図３５に示したクライアントＢがサーバに更新通知を行った後、別のクライアントクライアントＡがサーバに検索要求を行ったときの動作を示す図
【図３７Ａ】クライアント同士が通信可能場合の同期実行前検索時のシステムの動作例を示す図
【図３７Ｂ】クライアント同士が通信可能場合の同期実行前検索時のシステムの別の動作例を示す図
【図３８】クエリキャッシュを利用した場合の、図３５に示したクライアントＢがサーバに更新通知を行った後、別のクライアントクライアントＡがサーバに検索要求を行ったときの動作を示す図
【図３９】図３８の状態の後、さらに別のクライアントＣがクライアントＡと同じ検索要求をした場合の本検索システムの動作例を示す図
【図４０】本システムの基本的な動作の概要を示した図
【図４１】更新要求クライアントによる遠距離更新時のユーザ更新要求の処理例を示したフローチャート
【図４２】サーバによる遠距離更新時のユーザ更新要求受付の例を示したフローチャート
【図４３】検索要求クライアントによる検索実行の例を示したフローチャート
【図４４】サーバによるユーザ参照要求受付の例を示したフローチャート
【図４５】ステップＳ４４０１のより具体的な処理内容を示したフローチャート
【図４６】サーバによる差分検索要求、更新要求クライアントによる差分検索応答の処理例を示したフローチャート
【図４７】新要求クライアントによる更新要求、サーバによるユーザ更新要求受付処理例を示したフローチャート
【図４８】第６の実施の形態のシステム構成例を示したブロック図
【図４９】クライアントの機能ブロック図
【図５０】命令制御部の一構成例を示す機能ブロック図
【図５１】変更履歴の記憶内容の例を示すブロック図
【図５２】１つのマスター・クライアントと、１つのノード・クライアントの間での責任の移転の例を示す図
【図５３】あるデータａについての「責任」が移転する例を示す図
【図５４】図５３の状態から責任が移転した後の状態を示す図
【図５５】図５４の状態の後、つなぎかえが行われた状態を示す図
【図５６】クライアント間でのデータベース更新前のある状態を示す図
【図５７】図５６の後につなぎかえが行われた状態を示す図
【図５８】条件判定式の計算例を説明するための図
【図５９】条件判定式の計算例を説明するための別の図
【図６０】サーバを用いることなく検索を行う場合の、本実施の形態に係るデータベース・システムの動作例を示すシーケンス図
【図６１】差分通知と差分検索を同時に送信するようにした場合の、サーバを用いることなく検索を行う場合の本実施の形態に係るデータベースシステムの動作例を示したシーケンス図
【図６２】本データベースシステムにおいて、あるノード・クライアントがデータの検索（差分検索）を行うときの動作例を示したフローチャート
【図６３】問い合わせ先クライアントの差分通知要求に対する対応処理の一例を示したフローチャート
【図６４】問い合わせ先クライアントのつなぎかえ要求に対する応答処理を示したフローチャート
【図６５】更新要求を受信した問い合わせ先クライアントの動作例を示したフローチャート
【発明を実施するための形態】
【００１２】
[差分検索システム]
まず、本実施の形態の基本となる差分検索システムについて説明する。
図1は、本発明の実施形態に係るクライアントサーバシステムの構成例を示す概念図である。図１に示すように、クライアントサーバシステム１００は、サーバとなる情報管理装置２と、例えばインターネット網あるいは無線通信網３でクライアント機器となる情報端末装置１とから構成されている。情報管理装置（以下の説明では、サーバとも称する）２は、図１に示すように、データベース２４に接続されている。データベース２４は、都度、更新され、現在のバージョンと変更履歴が管理されている。情報管理装置２は、専用機器である必要は無い。所謂、家電機器と称される機器であってもネットワーク網に繋がり、バージョンの管理ができてサーバ機能を果たすものであればよい。さらに変更履歴は、各バージョンとそのバージョンで対象となるデータのＩＤとで把握されるようになっている。これらの詳細については、後述する。
【００１３】
情報端末装置（以下の説明では、クライアントとも称する）１は、データベース機能を備えるものであれば、携帯電話や携帯プレーヤが好適である。所謂、ウルトラモバイルＰＣと称されるものである。図１に示すように、各情報端末装置１も、それぞれデータベース１４に接続されているが、データベース１４は、情報管理装置２のデータベース２４と同期したときのバージョンとなっている。
【００１４】
図２は、本発明の実施形態に係るクライアントサーバシステム１００の機能ブロック図である。情報管理装置２は、接続部２１とデータベース２４を備え、情報端末装置１の要求を受け、結果を送信する。接続部２１は、インターネット網を介して、情報端末装置１と通信をする。情報端末装置１は、ユーザインターフェース１０と接続部１１及びデータベース１４を備える。ユーザインターフェース１０は、ユーザの要求を受け、結果を表示するものである。接続部１１は、インターネット網を介して、情報管理装置２と通信をする。
【００１５】
さらに、情報管理装置２は、命令制御部２２と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増加させ、新たな差分検索の実行回数ｎＲとして記憶する（Ｓ４６０７）。実績値（ｎ，Ｒ，ｐ）を最新の状態に保っておくためである。これで、サーバ側で行われる差分検索要求は終了する。
【００９３】
次に、更新要求クライアントによる差分検索応答の処理例について説明する。
まず、更新要求クライアントは、サーバ側の差分検索要求のステップＳ４６０１においてサーバから送信された差分検索要求を受け取る（Ｓ４６０８）。次に、更新要求クライアントは、この差分検索要求に応じて、自己のデータベースを用いて差分検索を実行する（Ｓ４６０９）。次に、更新要求クライアントは今まで送った更新データのデータ量の合計値が、サーバに送るべき更新データのデータ量を超えているか否かを判定する（Ｓ４６１０）。
具体的には、下記式に基づいてＳ４６１０の判定が行われる。
【数６】
但し、上記式においてRiはi番目に行われた更新データのデータ量、Ｄはサーバに送るべき更新データのデータ量である。
【００９４】
上記Ｓ４６１０において更新要求クライアントは今まで送ったデータのデータ量の合計値が、サーバに送るべき更新データのデータ量を超えている(上記式が成立している）と判定した場合（Ｓ４６１０、Ｙｅｓ）、更新要求クライアントはサーバに更新データを返す（Ｓ４６１１）。これで更新要求クライアントによる差分検索応答は終了する。
【００９５】
一方、上記Ｓ４６１０において更新要求クライアントは今まで送ったデータのデータ量の合計値が、サーバに送るべき更新データのデータ量を超えていない（上記式が成立していない)と判定した場合（Ｓ４６１０、Ｎｏ）、Ｓ４６０９で得られた差分検索結果をサーバに返す（Ｓ４６１２）。さらに更新要求クライアントは送ったデータ量Ｒｉを保持する。後に、今まで送った更新データのデータ量の合計値を算出し、Ｓ４６１０の判定を行うためである。これで更新要求クライアントによる差分検索応答は終了する。
【００９６】
[（６）更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付]
弱いネットワーク環境下にあった更新要求クライアントが強いネットワーク環境下に入った場合、更新要求クライアントによる更新要求並びにサーバによるユーザ更新要求受付が行われる。図４７は、上記更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付処理例を示したフローチャートである。以下このフローチャートを参照しながら更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付を説明する。
【００９７】
更新要求クライアントはまず、更新通知のみの更新データをサーバに送信する（Ｓ４７０１）。次に、更新要求クライアントはサーバから実績値（ｐ，ｎ，Ｒ）を取得する（Ｓ４７０２）。その後、更新クライアントは自己のデータベースとサーバのデータベースとの完全同期を実行する（Ｓ４７０３）。この完全同期の内容については後述する。完全同期終了後、更新要求クライアントは更新要求を終了する。
【００９８】
次に、サーバの更新要求受付について説明する。更新要求クライアントから送信された更新データを受信したサーバは、更新データを自己のデータベースに反映させる（Ｓ４７０４）。次に、サーバは前回の完全同期時刻と、更新通知日時と、現在時刻から稼働率ｐを算出する（Ｓ４７０５）。サーバは、差分検索のために送られたデータ量の合計Ｒｓｕｍを差分検索の実行回数ｎＲで割って、平均データ量Ｒを算出する（Ｓ４７０６）。次に、サーバは更新された実績値（ｎ，Ｒ，ｐ）を更新要求クライアントに送信する（Ｓ４７０７）。その後、サーバは更新要求クライアントとの間でデータベース内容の完全同期を実行する（Ｓ４７０８）。この完全同期の内容については後述する。完全同期終了後、サーバは更新要求受付を終了する。
【００９９】
最後に、更新要求クライアント及びサーバ間での完全同期処理について説明する。
完全同期処理を開始した更新要求クライアントはまず、自分のデータベースのVersionをサーバに通知する（Ｓ４７０９）。サーバは更新要求クライアントからデータベースのVersionを得る（Ｓ４７１０）と、更新要求クライアントに渡すべき差分となるデータを生成する（Ｓ４７１１）。次にサーバは、差分となるデータを更新要求クライアントに送信する（Ｓ４７１２）。更新要求クライアントはサーバから差分となるデータを受信する（Ｓ４７１３）。更新クライアントは受信した差分となるデータを自己のデータベースに更新させる（Ｓ４７１４）。これで、更新クライアント及びサーバ間のデータベース完全同期が完了する。
【０１００】
[本実施の形態の効果的な状況]
本実施の形態は、下記のような状況下でとりわけ有効である。
１．サーバ、クライアント間が近距離では安価で高速な通信ができ、遠距離では高価で低速でも通信が可能であること。
このような環境下で、本実施の形態は、近距離では同期による更新をし、遠距離では本提案を実施する。
２．一定間隔で、データベースがリフレッシュできること
充電のついでに完全同期できるなど、そのような完全同期がある期間内には行われる環境であること。
３．クライアント側で入力されるような、更新データが大量であるが、検索対象になりにくい環境下であること。
同期するまで、当面、検索されないようなものほど本実施の形態は効果がある。
上記において「近距離」とは例えば、（通信の）コストが小さい環境を意味し、「遠距離」とは例えば、（通信の）コストが大きい環境を意味する。
ここでいう「コスト」とは、通信に伴う料金（課金額）や、通信速度、レイテンシィ、電力消費量などを一つ乃至は複数考慮して決定する定量的なものを意味する。
【０１０１】
[本差分検索システムのデータ更新のまとめ]
本実施の形態によれば、以下のメリットを享受できる。
１．データを更新する際、悪い通信環境での通信量を減らすことができるため、ネットワーク管理者から見てネットワークトラフィックが減り、ユーザから見た場合に通信費用が減る。
２．サーバの負担を減らすことも可能となる。
なお、[本差分検索システムのデータ更新]は、第１の実施から第５の実施の
更新時に適用でき、また第６の実施にも適用できる。
【０１０２】
（第６の実施の形態）
次に、本実施の形態に係る第６の実施の形態について述べる。第６の実施の形態は、基本的に前述の第１の実施の形態から第５の実施の形態と同様の構成及び動作をするデータベースシステムであるが、本実施の形態は、サーバを使用することなく、クライアント間で差分検索を行い、及び／又は、クライアント間でデータベースを最新の状態に更新できるデータベースシステムである点で異なっている。
【０１０３】
[第６の実施の形態の構成例]
第６の実施の形態は、第１から第５の実施の形態における情報管理装置（以下の説明では、サーバとも称する）に相当する装置を有する構成としても成立するが、サーバを設けない構成としても本実施の形態は成立する。以下の説明ではサーバを設けない場合の構成として、本実施の形態の説明を行う。
【０１０４】
［用語］
本実施の形態の説明で使用する用語は、特にことわりのない場合、以下の意味を有する。
【０１０５】
「同期」とは、マスター・クライアントとノード・クライアントとの間で、データベース内のデータを共有している状態、若しくは共有化するための処理を意味する。
【０１０６】
「差分把握」とは、ノード・クライアントとマスター・クライアントのデータの差分を互いのバージョンから把握し、検索処理において重複したデータを検索しないようにすることである。
【０１０７】
「差分検索」とは、差分データ、すなわち同期がとれていないデータに対する検索をいい、マスター・クライアントが実行するものである。因みに、差分があるかどうか検索するわけではない。
【０１０８】
「変更履歴」とは、データベース内のデータについて変更履歴で変更した差分を管理する。変更履歴は、「バージョン」と「データＩＤ」の組を持っている。
【０１０９】
「バージョン」とは、本データベースシステム内でマスター・クライアントが一意に発行する数字で、データベース内のデータについて変更が行われたらバージョンが１つあがる。本実施形態において「バージョン」は、「差分把握」及び「差分検索」を簡単にするための仕組みである。
【０１１０】
図４８に、第６の実施の形態のシステム構成例を示したブロック図を示す。図４８に図示するように、システム４８００は、マスターとなる情報端末装置（以下、区別のためマスター・クライアントとも呼ぶ）４８０１と、例えばインターネット網、無線通信網、無線ＬＡＮなどの通信網４８０２でクライアント機器となる情報端末装置（以下、区別のためノード・クライアントとも呼ぶ）４８０３とから構成されている。各クライアントは同一の通信網で接続されてもよいし、異なる通信網により接続されてもよい。例えば、マスター・クライアント４８０１と全てのノード・クライアント４８０３が無線ＬＡＮに接続されていても本実施の形態は成立し、またあるクライアント同士はインターネット網で接続されており、別のクライアント同士は無線ＬＡＮで接続されている状態でも本実施の形態は成立する。
【０１１１】
マスター・クライアント４８０１は後述する「責任」を有するクライアントである。ノード・クライアント４８０３は、「責任」を有さないクライアントである。マスター・クライアント４８０１とノード・クライアント４８０３とは、「責任」の有無について異なるだけであって、装置構成、機能は共にクライアントであって差異はない。マスター・クライアント４８０１とノード・クライアント４８０３を区別しない場合には、単に「クライアント４８０１（４８０３）」と呼ぶこととする。
【０１１２】
「責任」を有するクライアント、すなわちマスター・クライアント４８０１は、ノード・クライアント４８０３の求めに応じて、後述する「つなぎかえ指定」、「差分検索」、データベースの同期を行うことができる唯一の装置である。なお、「責任」を有するか否かは、後述する「更新権」の有無によって識別される。「責任」を有するクライアントは、「更新権」を有するクライアントである。
【０１１３】
クライアント４８０１（４８０３）は、通信機能を有する情報処理装置、より詳しくは演算処理装置（ＣＰＵ）、主メモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、入出力装置（Ｉ／Ｏ）、必要な場合にはハードディスク装置等の外部記憶装置を具備している情報処理装置、あるいはそのような情報処理装置を含む装置である。クライアント４８０１（４８０３）は、データベース機能を備えるものであれば、どのような情報処理装置であってもよく、例えば携帯電話や携帯プレーヤが好適である。所謂、ウルトラモバイルＰＣと称されるものでもよい。
【０１１４】
図４９は、本実施形態に係るクライアント４８０１（４８０３）の機能ブロック図である。クライアント４８０１（４８０３）は、ユーザインターフェース４９０１、接続部４９０２、命令制御部４９０３、ＳＱＬ実行部４９０４、及びデータベース４９０５を有している。ユーザインターフェース４９０１及び接続部４９０２は命令制御部４９０３に接続されている。命令制御部４９０３はＳＱＬ実行部４９０４に接続されており、ＳＱＬ実行部４９０４はデータベース４９０５に接続されている。接続部４９０２は無線回線、あるいは有線回線を介して通信網４８０２に接続可能である。また、データベース４９０５は、データ４９０６、バージョン４９０７、変更履歴４９０８を記憶している。
【０１１５】
ユーザインターフェース４８０１は、ユーザの入力を受け付けるとともに、処理結果を表示する機能を有する。例えば、液晶ディスプレイ装置及びタッチパネルなどである。接続部４９０２は、通信網４８０２を介して他のクライアント４８０１（４８０３）と通信する機能を有する。
【０１１６】
命令制御部４９０３は、ユーザや他のクライアント４８０１（４８０３）からの要求や命令に応じて、所定の命令を実行し、必要に応じてＳＱＬ実行部４９０４や接続部４９０２に命令を出し、あるいは結果をユーザインターフェース４９０１に表示させる。図５０は、命令制御部４９０３の一構成例を示す機能ブロック図である。命令制御部４９０３は、接続開始部５００１、接続受付部５００２、接続停止部５００３、接続終了部５００４、差分通知部５００５、差分除去部５００６、差分検索部５００７、ＳＱＬ受付部５００８、結果取得部５００９、結果送信部５０１０、ネットワーク利用判断部５０１１、同期送信部５０１２、同期受信部５０１３、更新権利取得部５０１４、更新権利破棄部５０１５、つなぎかえ指定部５０１６、つなぎかえ処理部５０１７、最新保証処理部５０１８、つなぎかえ要求部５０１９、最新保証通知部５０２０、最新保証切れ部５０２１、判定部５０２２という各命令処理部を有している。また、命令制御部４０９３は、同期内ノード５０２３、更新権５０２４、問い合わせ先５０２５、最新保証フラグ５０２６、予測データ５０２７を記憶しており、本実施の形態の記憶手段として機能する。
【０１１７】
以下に、上記命令処理部のそれぞれについて説明する。
接続開始部５００１は、あるクライアントが他のクライアントとの通信を確立させるための処理を行う。
【０１１８】
接続受付部５００２は、他のクライアントからの接続要求を受けた場合、当該クライアントとの通信を確立する処理を行う。
【０１１９】
接続終了部５００３は、接続開始後、必要な処理が終了したのちに他のクライアントとの通信を解除する処理を行う。
接続停止部５００４は、接続のために用意していたメモリや通信部などの資源を解放するために他のクライアントからの求めに応じて確立させた通信を解除する処理を行う。
差分通知部５００５は、ノード・クライアント４８０３が自己のデータベースのバージョンをマスター・クライアント４８０１に通知して、互いのバージョンからデータの差分をマスター・クライアントに把握させる処理を行う。
差分除去部５００６は、差分データを無効化する処理を行う。
差分検索部５００７は、差分検索処理を実行する。
ＳＱＬ受付部５００８は、他のクライアントからＳＱＬ文を取得し、取得したＳＱＬ文をＳＱＬ実行部４９０４に渡す処理を行う。
結果取得部５００９は、前述の結果送信により送信されたデータを取得する処理を行う。
結果送信部５０１０は、ＳＱＬ実行部４９０４がＳＱＬ文を実行した結果をＳＱＬ文の送信元である他のクライアント４８０１（４８０３）に送信させる処理を行う。
ネットワーク利用判断部５０１１は、そのクライアント４８０１（４８０３）が使用しているネットワーク（通信網４８０２に相当）が「強いネットワーク環境」であるのか、「弱いネットワーク環境」であるのかを判定する。
同期送信部５０１２は、他のクライアント４８０１（４８０３）から同期を求められた場合、同期させるためのデータベースのデータを当該クライアント４８０１（４８０３）に送信させる処理を行う。
同期受信部５０１３は、上記「同期送信」に他のクライアント４８０１（４８０３）から送信されたデータを受信し、データベース４９０５の内容を同期させる処理を行う。
更新権利取得部５０１４は、「責任」を有するマスター・クライアント４８０１からその「責任」を取得する処理を行う。具体的には、「責任」の有無に応じて更新権５０２４の書き換えを行う。
更新権利破棄部５０１５は、自己の更新権５０２４を責任を有さないことを示すように書き換える。具体的には、「責任」の有無に応じて更新権５０２４の書き換えを行う。
つなぎかえ指定部５０１６は、つなぎかえ要求を送信したクライアント４８０３に対して、新しい「問い合わせ先」となるクライアントを通知する処理を行う。つなぎかえ指定５０１６は、本実施の形態のつなぎかえ指定手段に相当する。
つなぎかえ処理部５０１７は、つなぎかえ指定を受信したノード・クライアント４８０３が、問い合わせ先５０２５を更新する処理を行う。つなぎかえ処理５０１７は、本実施の形態のつなぎかえ処理手段に相当する。
つなぎかえ要求部５０１９は、現在「責任」を有しているマスター・クライアント４８０１を通知するよう求める処理を行う。つなぎかえ要求部５０１９は、本実施の形態のつなぎかえ要求手段に相当する。
【０１２０】
判定部５０２２は、予測データ５０２７に基づいて、つなぎかえ要求の要否の判定を行う。
【０１２１】
次に、命令制御部４９０３が有する各データについて説明する。
同期内ノード５０２３は、データベース４９０５の同期を行っている他のクライアント４８０１（４８０３）のリストである。
【０１２２】
更新権５０２４は、そのクライアント４８０１（４８０３）が「責任」、すなわち更新権利があるかどうかを示す情報である、例えば、更新権の内容が「１」なら自分が責任を有するマスター・クライアント４８０１であることを示し、「０」であれば自分は「責任」を有さないノード・クライアント４０８３であることを示す。更新権５０２４を所有するクライアントは、その時点でデータベース４９０５の内容が最新の内容であるクライアントであり、同時に複数は存在しえない。但し、「責任」、すなわち更新権は、データベースが更新されるごとに、クライアント間で移転していく。
【０１２３】
問い合わせ先５０２５は、自分よりも新しいバージョンのクライアント４８０１（４８０３）をひとつ覚えておくためのノードの連結情報である。但し、問い合わせ先であるクライアントがその時点でまだ責任を有しているかどうかはわからない。
【０１２４】
予測データ５０２７は、つなぎかえを行うか否かを判断するための予測値・実績値である。予測データには、ノード全体数、自分に属している子のノード数、更新確率・検索確率などが含まれる。予測データ５０２７については、クライアント４８０１（４８０３）は同期時に互いに情報交換することができるので、同期している他のノードの情報を使うことが可能である。
【０１２５】
図４９に戻り、クライアントの構成例の説明を続ける。
ＳＱＬ実行部４９０４は、データベース４９０５に対する命令であるＳＱＬ文を用いて、命令制御部４９０３からの要求にしたがってデータベース４９０５への操作や定義づけを行う機能を有する。
【０１２６】
データベース２４は、追加・変更・削除されたデータ４９０６と変更履歴４９０８とバージョン４９０７を記憶する。データ４９０６は、データベースを構成する個々のデータ要素の集合である。バージョン４９０７は、データ４９０６に対応する現在のバージョンを表す情報である。変更履歴４９０８は、データベース４９０５内のデータ４９０６について、変更した差分を管理するための情報である。図５１は、変更履歴４９０８の記憶内容の例を示すブロック図である。変更履歴は、差分把握可能範囲５１０１と、バージョン５１０２とデータＩＤ５１０３とを含む。差分把握可能範囲５１０１は、極端に古いバージョンのデータベースしか保持していないクライアント機器をケアする場合に対応するための情報であって、差分検索が可能な範囲を示す情報である。バージョン５１０２とデータＩＤ５１０３とは組になっており、データＩＤ５１０３は対応するバージョンにおいて追加・変更・削除されたデータ要素を特定する識別情報である。
【０１２７】
[本実施の形態の動作例について]
次に、本実施の形態に係るデータベースシステム４８００の動作例を説明する。
[責任の移転：２クライアント間の場合]
本実施の形態では、サーバを使用することなく、クライアント間で検索を行い、及びデータベースを最新の状態に更新できることを特徴の一つとしている。このための仕組みとして、本実施の形態では最新データを所持するクライアントが「責任」を有する。「責任」の有無は前述の更新権５０２４の内容によって識別される。前述の通り、「責任」を有するクライアントはマスター・クライアント４８０１となり、そうでないクライアントはノード・クライアント４８０３となるが、「責任」が移動することによって、マスター・クライアント４８０１はノード・クライアント４８０３となり、一方ノード・クライアント４８０３がマスター・クライアント４８０１になる。
【０１２８】
図５２に、１つのマスター・クライアントと、１つのノード・クライアントの間での責任の移転の例を示す。あるクライアントＡ（この時点ではノード・クライアント）が自己のデータベースを最新の状態にするべく、データベースの更新処理を行おうとする場合、その時点で「責任」を有するマスター・クライアントＢに対して更新要求を送信する（Ｓ５２０１）。更新要求を受信したマスター・クライアントＢはノード・クライアントＢにデータベースの更新をさせるとともに、更新要求の送信元であるノード・クライアントＡに「責任」を渡す。データベースの内容を最新の内容に更新し、新たに「責任」を保有したノード・クライアントＡは、以後マスター・クライアントＡとして振る舞うことになり、「責任」を保有しなくなったマスター・クライアントＢは以後ノード・クライアントＢとして振る舞うことになる。すなわち、以後、ノード・クライアントＢは、「責任」を受け取ったマスター・クライアントＡに問い合わせを行う。なお、「責任」の受け渡しに相当するデータ処理方法については後述する。
【０１２９】
[責任の移転：３クライアントの場合]
次に、３つのクライアントが関与する場合の「責任」の移転について説明する。図５３は、あるデータａについての「責任」が移転する例を示す。図５３に示した例では、３つのクライアントは相互に通信可能な状態にあるものとする。クライアントＡはデータａについて責任を有している。残りの２つのクライアント、クライアントＢ、クライアントＣは共にデータａについてデータベース記憶内容の更新を必要としている状態にあり、クライアントＢ、クライアントＣはデータａについてクライアントＡが責任を有すると記憶している。図中の矢印は、矢印の元にあるクライアントから見た、責任を有するクライアント、すなわち「問い合わせ先」に記述されたクライアントを示している。
【０１３０】
ここで、クライアントＢがクライアントＡに対してデータａについて更新要求を行ったものとする。クライアントＡはクライアントＢに対して最新の内容のデータａを送信する。クライアントＢの有するデータベース内容はデータａについて更新され、最新の内容となる。このときクライアントＡはデータａについての「責任」をクライアントＢに渡す。クライアントＢはこの「責任」を取得し、データａについて自分が「責任」を有すると記憶する。また、クライアントＡはデータａについての責任はクライアントＢが有するものと記憶する。図５４は図５３の状態から責任が移転した後の状態を示す図である。クライアントＢはこの「責任」を取得し、データａについて自分が責任を有すると記憶し、クライアントＡは、自分は「責任」を破棄し、データａについての責任はクライアントＢが有するものと記憶した状態を示す。クライアントＣは以前と変わらず、データａについてクライアントＡが責任を有すると記憶している状態が継続する。
【０１３１】
[最新の検索（差分把握）]
本実施の形態は、サーバ不要で、最新の内容のデータベースの検索することができる。
【０１３２】
各クライアントは、最新のデータベースの内容を検索をするためには、責任を有するクライアントに問い合わせすることが必要である。これは、前述した実施の形態における差分検索でいう「差分把握」に相当する処理である。先の図５４で示した例に基づいて、本実施の形態における最新の検索について説明する。
【０１３３】
クライアントＣは、最新のデータであるデータａについてクライアントＡが責任を有していると記憶している。クライアントＢはデータａについて自分が責任を有すると記憶し、クライアントＡはデータａについての責任はクライアントＢが有するものと記憶している状態である。
【０１３４】
クライアントＣはクライアントＡがデータａについて責任を有していると記憶しているので、クライアントＣはクライアントＡに問い合わせ(差分通知)を送信する。
【０１３５】
問い合わせ（差分通知）を受信したクライアントＡはデータａについて責任を持っておらず、且つ、クライアントＡはクライアントＢに聞くという情報を持っているので、クライアントＢにデータａについて問い合わせ（差分通知）を送信(転送、中継)する。クライアントＢはデータａについて責任を有しているので、自己が記憶する最新のデータａとの差分内容をクライアントＣに送信する。よって、クライアントＣは「責任」を有するクライアントとの差分を把握することができる。
【０１３６】
[連鎖問い合わせ：（差分検索）のつなぎかえ]
本実施の形態では、クライアントがデータベースを検索する場合において、最新のマスター・クライアント４８０１がどのクライアントであるかを把握することができるようになる。
【０１３７】
図５４は、クライアントＣは、最新のデータであるデータａについてクライアントＡが責任を有していると記憶している。クライアントＢはデータａについて自分が責任を有すると記憶し、クライアントＡはデータａについての責任はクライアントＢが有するものと記憶している状態である。
【０１３８】
ここで、クライアントＣがデータａについて検索を行おうとする場合、まずデータａについて責任を有する（とクライアントＣが記憶している）クライアントＡに問い合わせる。クライアントＡはデータａについての責任はクライアントＢが有するものと記憶しているので、データａについてクライアントＢに問い合わせる。すなわち、それぞれのクライアントにおいて「問い合わせ先」となっているクライアントに対して連鎖的に問い合わせが行われる。問い合わせに対してマスター・クライアント４８０１から応答がなされ、各クライアントは、今現在「責任」を有するクライアントを示す情報である問い合わせ先５０２５を更新する（「つなぎかえ」と呼ぶ）ことができる。但し、つなぎかえはつなぎかえをした方が有利な場合と判定された場合に行われ、常につなぎかえが行われるわけではない。図５４の状態の後、つなぎかえが行われた状態を図５５に示す。クライアントＣの「問い合わせ先」が更新され、現在のマスター・クライアントＢが新たな「問い合わせ先」として登録される。クライアントＡについて「問い合わせ先」の変更はない。
【０１３９】
[連鎖問い合わせ：更新の際のつなぎかえ]
本実施の形態では、クライアントがデータベースを更新する場合において、サーバを用いることなく更新を行うことができ、更新の際には、最新のマスター・クライアント４８０１がどのクライアントであるかを把握することができるようになる。
【０１４０】
図５６は、クライアント間でのデータベース更新前のある状態を示す図である。クライアントＣは、最新のデータであるデータａについてクライアントＡが責任を有していると記憶している。クライアントＢはデータａについて自分が責任を有すると記憶し、クライアントＡはデータａについての責任はクライアントＢが有するものと記憶している状態である。
【０１４１】
ここで、クライアントＣがデータａについてデータベースの更新を行おうとする場合、まずデータａについて責任を有する（とクライアントＣが記憶している）クライアントＡに問い合わせる。クライアントＡはデータａについての責任はクライアントＢが有するものと記憶しているので、データａについてクライアントＢに問い合わせる。すなわち、「問い合わせ先」となっているクライアントに対して連鎖的に問い合わせが行われる。
【０１４２】
クライアントＣがクライアントＢよりデータを取得し、データベースの内容を最新の内容に更新すると、データａについての責任はクライアントＢからクライアントＣに渡され、クライアントＣが新たに責任を有する状態になる。
【０１４３】
この場合、経由したクライアント（問い合わせに関与したクライアント）は、責任を有するクライアントの情報である問い合わせ先５０２５を書き換える（「つなぎかえ」と呼ぶ）。すなわち、クライアントＡ、クライアントＢはデータａについてクライアントＣが責任を有すると、記憶するように問い合わせ先５０２５を書き換える。但し、つなぎかえはつなぎかえをした方が有利な場合と判定された場合に行われる。図５６の後につなぎかえが行われた状態を図５７に示す。クライアントＡ，クライアントＢの「問い合わせ先」が更新され、現在のマスター・クライアントＣが新たな「問い合わせ先」として登録される。
【０１４４】
[つなぎかえの要否]
各クライアントは、以下の判定条件式に基づいて、つなぎかえを行うか否かを判定し、判定結果に基づいてつなぎかえ処理を実行する。
【０１４５】
判定条件式は以下の通り
(投資)＜（同期するまでに検索する回数）×（問い合わせ通信の減る量）
上記式の投資は本実施の形態の第１の送信データ量に相当し、上記式の右辺は本実施の形態の第２の送信データ量に相当する。
【０１４６】
上記判定条件式が満たされる場合には、クライアント、より詳しくは判定部５０２２は、つなぎかえ処理を実行すると判定する。同期すれば、1段化にされるためである。
【０１４７】
「投資」は、つなぎかえを行うために必要な送信データ量であって、dと表す。「同期するまでに検索する回数」は予測値を用いる。予測値は予測データ５０２７から過去の平均値を算出することなど適宜な方法によって得る。「問い合わせ通信の減る量」は（h-１）dにより算出される値である。ｈはそのクライアントから最新ノード（実際に責任を有するクライアント）までの高さ(階層差）である。また、「同期するまでに検索する回数」は、そのクライアントに属している子ノードの数Ｃに比例する。なお、高さ(階層差）及び子ノードは、本実施の形態に係るデータベースシステムを、最新ノード（実際に責任を有するクライアント）を根ノードとし、問い合わせ先のクライアントを親ノードとする木構造と見た場合の概念である。
【０１４８】
[つなぎかえの判定例]
上記判定条件式による判定例を以下に述べる。
【０１４９】
投資＝つなぎかえを行うために必要な送信データ量dとし、「同期するまでに検索する回数」は、（（属している子の数）＋１（自分））×（平均問い合わせ確率）×（同期していない確率）により算出するものとする。
【０１５０】
問い合わせ通信の減る量は、（（自分の高さ）−１）×ｄ
属している子の数＝C、平均問い合わせ確率＝ｎ、データベースのデータが完全である確率＝ｐ、自分の高さをｈとすると、条件判定式は以下のように表現される。
d ≦ (C+1)×ｎ×(1-p)×（h-1）×d …(条件判定式)
【０１５１】
なお、最新ノード（マスター・クライアント）に直結している場合は、h=1となり、つなぎかえの必要性は生じない(右辺＝０となるため、ｄ＞０なら条件判定式は常に不成立）。また、属している子の数Ｃと問い合わせ確率ｎが大きいほど、判定条件式が満たされる可能性が高まる。これは、子の数だけ問い合わせ頻度が大きくなるためである。
【０１５２】
上記条件判定式の確率ｐについて説明する。
マスター・クライアント４８０１（他の実施の形態のサーバに相当する）のデータベース中のデータが完全である確率をｐとすると、他のクライアントに更新データの存在を確認しなければいけない確率、すなわち「同期していない確率」は（１−ｐ）となる。具体例で説明すると、１日のうち９割はマスター・クライアント４８０１とノード・クライアント４８０３とが同期できる環境となると設定すれば、確率ｐは０．９であり「同期していない確率」（１−ｐ）は０．１となる。
【０１５３】
次に平均問い合わせ確率ｎについて説明する。平均問い合わせ確率ｎは、１クライアントあたりのある一定期間での検索回数である。平均して1日あたり0.4回の検索をした場合では、平均問い合わせ確率ｎは0.4（/日）である。
【０１５４】
図５８に、条件判定式の計算例を説明するための図を掲げる。この例では、最新データを有し、「責任」を有するマスター・クライアント４８０１(図中、Ｒと表示する)、このマスター・クライアント４８０１を問い合わせ先５０２５に記憶しているノード・クライアント４８０３(図中、Ｎ１と表示)、ノード・クライアントＮ１を問い合わせ先５０２５に記憶しているノード・クライアント４８０３(図中、Ｎ２と表示)、ノード・クライアントＮ２を直接、又は間接に問い合わせるノード・クライアント４８０３の集団（ノード・クライアントＮ２の下位ノード集団と呼ぶ）がある。このとき、ノード・クライアントＮ１の高さｈ＝１、ノード・クライアントＮ２の高さｈ＝２となる。また、ノード・クライアントＮ２の下位ノード集団に含まれるノード・クライアント数Ｃ＝２９とする。
【０１５５】
ここで、上記条件下においてノード・クライアントＮ２が条件判定式を用いてつなぎかえの要否を判定するとどのようになるかを述べる。
【０１５６】
ノード・クライアントＮ２について、d ≦ (C+1)×ｎ×(1-p)×（h-1）×d の式を考えると、
Ｃ＝２９、ｎ＝０．４、Ｐ＝０．９、ｈ＝２であるからこれらを代入して
d ≦ (29+1)×0.4×0.1×(2-1)×d = 1.2d …(式１）
となる。よってｄ＞０であれば上記不等式１は成立し、式１の結果より、ノード・クライアントＮ２はつなぎかえを実施すると判定する。
【０１５７】
次に、上記条件下においてノード・クライアントＮ１が条件判定式を用いてつなぎかえの要否を判定するとどのようになるかを述べる。
【０１５８】
ノード・クライアントＮ１について、条件判定式、d ≦ (C+1)×ｎ×(1-p)×（h-1）×d の式を考えると、
Ｃ＝３０、ｎ＝０．４、Ｐ＝０．９、ｈ＝１であるからこれらを代入して
d ≦ (30+1)×0.4×(1-0.9)×(1-1)×d =0 …(式２）
【０１５９】
送信データ量ｄは０以下ではありえないので、式２の不等式は成立しない。
したがって、ノード・クライアントＮ１はつなぎかえを実施しないと判定することになる。
【０１６０】
さらに別の例で条件判定式の計算例を説明する。図５９に条件判定式の計算例を説明するための別の図を掲げる。図５９に示す例は、マスター・クライアントＲ，ノード・クライアントＮ１、ノード・クライアントＮ２については先の図５８に示した例と同じ条件とする。ノード・クライアントＮ２には、その子ノードである、ノード・クライアントＮ２を問い合わせ先５０２５とするノード・クライアント４８０３(区別のためＮ３と呼ぶ）が存在し、ノード・クライアントＮ３には、直接又は間接に問い合わせを送信するノード・クライアント４８０３の集団（ノード・クライアントＮ３の子ノード集団と呼ぶ)が存在する。なお、ノード・クライアントＮ３の子ノード集団の個数Ｃ＝９であるとする。ノード・クライアントＮ３の高さｈ＝３である。
【０１６１】
ノード・クライアントＮ３について、条件判定式、d ≦ (C+1)×ｎ×(1-p)×（h-1）×d の式を考えると、
Ｃ＝９、ｎ＝０．４、Ｐ＝０．９、ｈ＝３であるからこれらを代入して
d ≦ (9+1)×0.4×0.1×(3-1)×d = 0.8d …(式３)
である。つなぎかえに必要な送信データ量は常にｄ＞０であるから、上記式３の不等式は成立せず、子の条件下ではノード・クライアントＮ３はつなぎかえを実施しないと判定することになる。但し、前述の通り、ノード・クライアントＮ２において判定すると、式２に示した結果より、ノード・クライアントＮ２はつなぎかえを実施する。すなわち、同じノード内でも、つなぎかえを行うクライアントと行わないノードが混在することありうる。
【０１６２】
[つなぎかえの処理例]
次に、本実施の形態におけるつなぎかえの動作例について説明する。
図６０にサーバを用いることなく検索を行う場合の、本実施の形態に係るデータベース・システムの動作例をシーケンス図として示す。図６０に示す例では、１つのマスター・クライアント４８０１、及び３つのノード・クライアント４８０３（互いを区別するため、マスター・クライアント４８０１をクライアントＲ、３つのノード・クライアント４８０３をクライアントＮ１、クライアントＮ２，クライアントＮ３と呼ぶ）が存在している。
【０１６３】
クライアントＮ３は責任を有するのはクライアントＮ２であると記憶しており、クライアントＮ２は責任を有するのはクライアントＮ１であると記憶しており、クライアントＮ１は責任を有するのはクライアントＲであると記憶しており、実際に責任を有しているのはクライアントＲである。
【０１６４】
ここで、クライアントＮ３がデータベースの検索を行おうとしたとする。まず、検索を実行しようとするクライアントＮ３は、差分通知要求（Ｓ６００１）とつなぎかえ要求（Ｓ６００２）をクライアントＮ２に送信する。
つなぎかえ要求には、つなぎ換えを行った方が有利となるか否かを判定してもらうために必要なデータ（判定用データと呼ぶ）が含まれている。ここではクライアントＮ３の高さｈ、子ノード集団の個数Ｃがつなぎかえ要求のメッセージに付加されているとする。具体例としては
Ｎ３：ｈ＝１、Ｃ＝９
のような判定用データである。
【０１６５】
クライアントＮ３から差分通知要求とつなぎかえ要求を受信したクライアントＮ２は自分は責任を有していないので、責任を有すると記憶しているクライアントＮ１に差分通知要求を送信（転送）する（Ｓ６００３）。また、クライアントＮ２は差分通知要求（Ｓ６００３）とともに、クライアントＮ３から受信した判定用データとともに、自己分の判定用データを含めたつなぎかえ要求（Ｓ６００４）をクライアントＮ１に送信する。具体的にはクライアントＮ３分の判定用データと、自己（Ｎ２)の判定用データが含まれる。その内容は以下のとおりである。
Ｎ３：ｈ＝２、Ｃ＝９
Ｎ２：ｈ＝１、Ｃ＝２９
なお、他のクライアントから受け取った判定用データ中のｈの値は1だけ増加された値に変更される。
【０１６６】
クライアントＮ２から差分通知要求とつなぎかえ要求を受信したクライアントＮ１は自分は責任を有していないので、責任を有すると記憶しているクライアントＲに差分通知要求を送信（転送）する（Ｓ６００５）。また、クライアントＮ１は、差分通知要求（Ｓ６００５）を転送するとともに、他のクライアントから受信した判定用データ及び自己分の判定用データを含めたつなぎかえ要求（Ｓ６００６）をクライアントＲに送信する。具体的にはクライアントＮ３分の判定用データ、クライアントＮ２分の判定データと、自己（Ｎ１)の判定用データが含まれる。その内容は以下のとおりである。
Ｎ３：ｈ＝３、Ｃ＝９
Ｎ２：ｈ＝２、Ｃ＝２９
Ｎ１：ｈ＝１、Ｃ＝３０
なお、他のクライアントから受け取った判定用データ中のｈの値は1だけ増加された値に変更される。
【０１６７】
クライアントＲは自己が責任を有するクライアントであると記憶しているので、受信したつなぎかえ要求に応答する。すなわち、クライアントＲは、責任を有するクライアントをクライアントＲとして記憶するように指令するつなぎかえ指定をクライアントＮ２に送信する（Ｓ６００７）。つなぎかえ指定を受信したクライアントＮ２は責任を有するクライアントをクライアントＲとするように記憶内容、すなわち問い合わせ先５０２５の内容を更新するつなぎかえ処理を行う（Ｓ６００８）。
【０１６８】
さらにクライアントＲはクライアントＮ３にもつなぎかえ指定を送信する（Ｓ６０１０）し、また差分通知要求（Ｓ６００１）に対応する結果送信（Ｓ６００９）を行う。
【０１６９】
つなぎかえ指定（Ｓ６０１０）を受信したクライアントＮ３は責任を有するクライアントをクライアントＲとするように記憶内容、すなわち問い合わせ先５０２５の内容を更新する（Ｓ６０１１）。また、クライアントＮ３は結果送信（Ｓ６０１１）の内容に基づいて差分除去を行う（Ｓ６０１２）。
【０１７０】
次に、クライアントＮ３は差分除去（Ｓ６０１２）後のデータベースの内容に基づいて、差分検索の要求をクライアントＲに送信する（Ｓ６０１３）。差分検索の要求を受信したクライアントＲはＳＱＬ受付を行う（Ｓ６０１４）。ＳＱＬの内容に基づいてデータベース検索を実行し差分検索結果を生成したクライアントＲは、結果をクライアントＮ３に送信する（Ｓ６０１５）。クライアントＲから差分検索結果を受信（Ｓ６０１６）したクライアントＮ３は自己のデータベース検索内容とクライアントＲの差分検索内容により、完全な最新のデータベース内容についての検索結果を得られることになる。
【０１７１】
また、検索に関する処理の一方、つなぎかえ処理（Ｓ６００８、Ｓ６０１１）が行われたクライアントＮ３，Ｎ２については責任を有するクライアントＲに次回からはダイレクトに問い合わせを送信することが可能となる。
【０１７２】
[変形例]
上記の検索処理においては、差分通知要求と差分検索要求を別々に送信するものとして説明したが、本実施の形態では差分通知要求と差分検索要求を同時に送信するようにしても、サーバを用いない検索を成立させることができる。検索クエリが小さい場合はこのように同時に送信する方が有効(1パケット内に収まる)からである。
【０１７３】
図６１は、差分通知要求と差分検索要求を同時に送信するようにした場合の、サーバを用いることなく検索を行う場合の本実施の形態に係るデータベースシステムの動作例を示したシーケンス図である。
【０１７４】
ここで説明する例において、１つのマスター・クライアント４８０１、及び３つのノード・クライアント４８０３（互いを区別するため、マスター・クライアント４８０１をクライアントＲ、３つのノード・クライアント４８０３をクライアントＮ１、クライアントＮ２，クライアントＮ３と呼ぶ）が存在している。
【０１７５】
クライアントＮ３は責任を有するのはクライアントＮ２であると記憶しており、クライアントＮ２は責任を有するのはクライアントＮ１であると記憶しており、クライアントＮ１は責任を有するのはクライアントＲであると記憶しており、実際に責任を有しているのはクライアントＲである。
【０１７６】
まず、検索を実行しようとするクライアントＮ３は、差分通知要求及び検索要求（Ｓ６１０１）と、つなぎかえ要求（Ｓ６１０２）をクライアントＮ２に送信する。つなぎかえ要求には、自己分の判定用データが含まれている。
【０１７７】
差分通知要求及び検索要求（Ｓ６１０１）とつなぎかえ要求（Ｓ６１０２）を受信したクライアントＮ２は、自分は責任を有していないので、責任を有するクライアント、すなわち問い合わせ先５０２５に記憶しているクライアントＮ１に差分通知要求及び検索要求を送信する（Ｓ６１０３）。また、クライアントＮ２はクライアントＮ３から受信した判定用データとともに、自己分の判定用データを含めたつなぎかえ要求をクライアントＮ１に送信する（Ｓ６１０４）。具体的にはクライアントＮ３分の判定用データと、自己（Ｎ２)の判定用データが含まれる。
【０１７８】
差分通知要求及び検索要求（Ｓ６１０３）とつなぎかえ要求（Ｓ６１０４）を受信したクライアントＮ１は、自分は責任を有していないので、責任を有すると記憶しているクライアントＲに差分通知要求及び検索要求（Ｓ６１０５）を送信する。また、クライアントＮ１は他のクライアントから受信した判定用データ及び自己分の判定用データを含めたつなぎかえ要求（Ｓ６１０６）をクライアントＲに送信する。具体的にはクライアントＮ３分の判定用データ、クライアントＮ２分の判定データと、自己（Ｎ１)の判定用データが含まれる。
【０１７９】
差分通知要求及び検索要求、つなぎかえ要求を受信したクライアントＲは、差分通知要求に応じたＳＱＬ受付を行う（Ｓ６１０７）。
【０１８０】
また、クライアントＲは自己が責任を有するクライアントであると記憶しているので、つなぎかえ要求に応答する。すなわち、クライアントＲは、責任を有するクライアントをクライアントＲとして記憶するように指令するつなぎかえ指定をクライアントＮ２及びクライアントＮ３に送信する（Ｓ６１０８、Ｓ６１１１）。なお、この例ではクライアントＮ１についてはつなぎ換えを行っても有利にならないと判定されたため、クライアントＮ１についてはつなぎ換え指定は送信されないものとする。
つなぎ換え指定を受信したクライアントＮ２は、つなぎかえ指定（Ｓ６１０８）に応じて、問い合わせ先２０５５をクライアントＲとするように記憶内容を更新するつなぎかえ処理を行う（Ｓ６１０９）。
【０１８１】
次に、クライアントＲは差分通知要求に応答する差分把握を生成するとともに、ＳＱＬ受付（Ｓ６１０７）に基づいてデータベース検索を実行し差分検索結果を生成し、これらをクライアントＮ３に送信する（Ｓ６１１０）。また、クライアントＲはクライアントＮ３にもつなぎかえ指定を送信する（Ｓ６１０８）。
【０１８２】
クライアントＮ３は、クライアントＲから送信された結果送信の内容に基づいて差分除去を行う（Ｓ６１１４）。また、クライアントＮ３は、つなぎかえ指定（Ｓ６１１１）に応じて、問い合わせ先２０５５をクライアントＲとするように記憶内容を更新するつなぎかえ処理を行う（Ｓ６１１３）。
【０１８３】
最後に、クライアントＮ３は差分除去後の自己のデータベース検索内容とクライアントＲから受信した差分検索内容により、最新のデータベース内容についての検索結果を得られることになる。
【０１８４】
また、それぞれのつなぎかえ処理（Ｓ６１０８、Ｓ６１１１）により、クライアントＮ２，Ｎ３は、最新のデータを有するクライアントＲに次回からは他のクライアントを経由することなくダイレクトに問い合わせを送れるようになる。
【０１８５】
[クライアントの動作例]
次に、個々のクライアント４８０１（４８０３）の動作例について説明する。
[クライアントの動作例：検索の場合]
【０１８６】
図６２は、本データベースシステムにおいて、あるノード・クライアント４８０３がデータの検索（差分検索）を行うときの動作例を示したフローチャートである。
【０１８７】
検索（差分検索）を行う場合、ノード・クライアント４８０３（以下、区別のため起点クライアントと呼ぶ）、より詳しくは接続開始部５００１が問い合わせ先５０２５に記述されたクライアント４８０１（４８０３）（以下、「問い合わせ先クライアント」と称す）との通信を確立する（図略）。
【０１８８】
次にこの起点クライアント、より詳しくは差分通知部５００５は、問い合わせ先クライアントに差分通知要求を送信する（Ｓ６２０１）。
【０１８９】
次に、起点クライアント、より詳しくはそのつなぎかえ要求部５０１９は、問い合わせ先クライアントにつなぎかえ要求を送信する（Ｓ６２０２）。起点クライアント、より詳しくはそのつなぎかえ処理部５０１７は、データに対して「責任（更新権）」を有するクライアントからつなぎかえ指定が送信されてくるのを待ち受ける（Ｓ６２０３）。
【０１９０】
「責任（更新権）」を有するクライアントからつなぎかえ指定を受信すると、起点クライアント、より詳しくはそのつなぎかえ処理部５０１７は、つなぎかえ指定に記述されたクライアントを新たな問い合わせ先クライアントとするように、問い合わせ先５０２５の内容を書き換える処理であるつなぎかえ処理を実行する（Ｓ６２０５）。
【０１９１】
また、起点クライアント、より詳しくはその差分通知部５００５は、先に送信した差分通知要求（Ｓ６２０１）に応答する結果を待ち受ける（Ｓ６２０６）。「責任（更新権）」を有するクライアントから前記差分通知要求に対する結果を受信する（Ｓ６２０７）と、起点クライアント、より詳しくはその差分除去部５００５は、受信した結果に基づいてデータベースの４９０５の差分除去を行う（Ｓ６２０８）。
【０１９２】
次に、起点クライアント、より詳しくはその差分検索部５００７は、「責任（更新権）」を有するクライアントへ差分検索の要求を送信し（Ｓ６２０９）、「責任（更新権）」を有するクライアントから差分検索の結果を受信する（Ｓ６２１０）。
【０１９３】
次に、前述した起点クライアントから差分通知要求、つなぎかえ要求を受信する問い合わせ先クライアントの動作例について説明する。なお、問い合わせ先クライアントは、差分通知、つなぎかえ要求の双方に対応処理するのであるが、ここでは差分通知、つなぎかえ要求の対応を分けて説明する。
【０１９４】
［差分通知に対する対応］
図６３は問い合わせ先クライアントの差分通知要求に対する対応処理の一例を示したフローチャートである。まず、問い合わせ先クライアントは差分通知要求を受信する（Ｓ６３０１）。問い合わせ先クライアントは自己の更新権５０２４の内容を参照して、自己が更新権を保有しているか否かを判定する（Ｓ６３０２）。自己が更新権を保有していると判定した場合（Ｓ６３０２、Ｙｅｓ）、この問い合わせ先クライアントは、「責任（更新権）」を有するクライアントであるので、差分通知要求に応答して、差分通知を起点クライアントに送信し（Ｓ６３０３）、処理を終了する。
【０１９５】
一方、ステップＳ６３０２において自己が更新権を保有していないと判定した場合（Ｓ６３０２、Ｎｏ）、問い合わせ先クライアントは、自己の問い合わせ先５０２５に記述されたクライアント（区別のため、次段問い合わせ先クライアントと呼ぶ）に対して、起点クライアントから受信した差分通知要求を転送し（６３０４）、処理を終了する。この差分通知要求を転送された次段問い合わせ先クライアントは、同様にステップＳ６３０１からステップＳ６３０４までの処理を実行する。差分通知要求の転送は「責任（更新権）」を有するクライアントに到達するまで繰り返される。
【０１９６】
［つなぎかえ要求に対する対応］
次に、問い合わせ先クライアントのつなぎかえ要求に対する応答処理について説明する。図６４は、問い合わせ先クライアントのつなぎかえ要求に対する応答処理を示したフローチャートである。
【０１９７】
まず、問い合わせ先クライアントはつなぎかえ要求を受信する（Ｓ６４０１）。問い合わせ先クライアントは自己の更新権５０２４の内容を参照して、自己が更新権を保有しているか否かを判定する（Ｓ６４０２）。自己が更新権を保有していると判定した場合（Ｓ６４０２、Ｙｅｓ）、この問い合わせ先クライアントは、ステップＳ６４０１において受信したつなぎかえ要求に含まれるデータから、ノード１件分のデータを取得する（Ｓ６４０４）。
問い合わせ先クライアントは、取得したノード１件分のデータに基づいて当該ノードについてつなぎ換えを行わせた方が有利になるか否かを判定する（Ｓ６４０５）。有利にならないと判定した場合（Ｓ６４０５、Ｎｏ）、この問い合わせ先クライアントはそのまま処理を終了する。一方、有利になると判定した場合（Ｓ６４０５、Ｙｅｓ）、この問い合わせ先クライアントは、前記取得したノード１件分のデータに対応するクライアントに、自己を問い合わせ先とするようにつなぎかえ処理を行うよう指示するつなぎかえ指定を送信する（Ｓ６４０７）。
次に、この問い合わせ先クライアントはステップＳ６４０１において受信したつなぎかえ要求に含まれる、全てのノード分のデータを処理したか否かを判定する（Ｓ６４０７）。すべて処理したと判定した場合（Ｓ６４０７，Ｙｅｓ）、この問い合わせ先クライアントは処理を終了する。一方、すべて処理していないと判定した場合（Ｓ６４０７，Ｎｏ）、この問い合わせ先クライアントはステップＳ６４０４に戻り、未処理のノードのデータについてステップＳ６４０４からＳ６４０７の処理を繰り返し行う。
「責任（更新権）」を有するクライアントであるので、つなぎかえ要求に応答して、つなぎかえ指定を起点クライアントに送信し（Ｓ６４０３）、処理を終了する。
【０１９８】
一方、ステップＳ６３０２において自己が更新権を保有していないと判定した場合（Ｓ６３０２、Ｎｏ）、問い合わせ先クライアント、より詳しくはその判定部５０２２は起点クライアントから受信しているつなぎかえ要否判定に要するデータ、自己分のつなぎかえ要否判定に要するデータを含むつなぎかえ要求を、自己の問い合わせ先（すなわち、次段問い合わせ先クライアント）に送信するか否かを判定するため、前述の判定条件式を用いて、つなぎかえを行った方が送信データ量削減の観点等から有利であるか否かを判定する（Ｓ６４０４）。
【０１９９】
ステップＳ６４０２において、更新権を保有していないと判定した場合（Ｓ６４０２、Ｎｏ）、問い合わせ先クライアント、より詳しくはそのつなぎかえ要求部５０１９は、次段問い合わせ先クライアントにつなぎかえ要求を送信する（Ｓ６４０３）。なお、このつなぎかえ要求には、起点クライアントから受信しているつなぎかえ要否判定に要するデータ、自己分のつなぎかえ要否判定に要するデータが含まれるように構成される。
【０２００】
問い合わせ先クライアント、より詳しくはそのつなぎかえ処理部５０１７は、データに対して「責任（更新権）」を有するクライアントからつなぎかえ指定が送信されてくるのを待ち受ける（Ｓ６４０６）。
【０２０１】
「責任（更新権）」を有するクライアントからつなぎかえ指定を受信する（Ｓ６４０７）と、問い合わせクライアント、より詳しくはそのつなぎかえ処理部５０１７は、つなぎかえ指定に記述されたクライアントを新たな問い合わせ先クライアントとするように、問い合わせ先５０２５の内容を書き換える処理である問い合わせ処理を実行する（Ｓ６４０８）。
【０２０２】
問い合わせ先クライアントからつなぎかえ要求を送信若しくは転送された次段問い合わせ先クライアントは、同様にステップＳ６４０１からステップＳ６４０８までの処理を実行する。つなぎかえ要求の転送は「責任（更新権）」を有するクライアントに到達するまで繰り返される。
【０２０３】
[クライアントの動作例：更新（同期）の場合]
次に、本実施の形態に係るデータベースシステムにおいて、あるノード・クライアント４８０３がデータの更新（同期）を行うときの動作例について述べる。
【０２０４】
起点クライアントが更新要求を送信するに先だって、差分通知要求を行うため、更新（同期）の場合におけるつなぎかえ要求の送信、つなぎかえ要求の転送、つなぎかえ要求への応答は、図６２、図６４において説明した処理と同様となるので、ここでは詳細な内容の説明は省略する。
【０２０５】
次に、更新要求を受信した問い合わせ先クライアントの動作例について説明する。図６５は、更新要求を受信した問い合わせ先クライアントの動作例を示したフローチャートである。
【０２０６】
まず、問い合わせ先クライアントは更新要求を受信する（Ｓ６５０１）。問い合わせ先クライアントは自己の更新権５０２４の内容を参照して、自己が更新権を保有しているか否かを判定する（Ｓ６５０２）。自己が更新権を保有していると判定した場合（Ｓ６４０２、Ｙｅｓ）、この問い合わせ先クライアント、より詳しくは同期送信部５０１２は、「責任（更新権）」を有するクライアントであるので、更新要求に応答して、更新に必要なデータ（差分データ）を起点クライアントに送信し（Ｓ６５０３）、更新権利破棄部５０１５が更新権破棄処理を実行して、更新権５０２４の内容を更新権を保有しないことを示す情報を示すものに書き換え（Ｓ６５０４）、問い合わせ先５０２５の内容を新たに最新のデータベース内容を有することになった起点クライアントを示す情報に書き換え（Ｓ６５０５）、これを持って処理を終了する。
【０２０７】
一方、ステップＳ６５０２において自己が更新権を保有していないと判定した場合（Ｓ６５０２、Ｎｏ）、問い合わせ先クライアントは、自己の問い合わせ先５０２５に記述されたクライアント（区別のため、次段問い合わせ先クライアントと呼ぶ）に対して、起点クライアントから受信した更新要求を転送し（Ｓ６５０６）、処理を終了する。この更新要求を転送された次段問い合わせ先クライアントは、同様にステップＳ６５０１からステップＳ６５０６までの処理を実行する。更新要求の転送は「責任（更新権）」を有するクライアントに到達するまで繰り返される。
【０２０８】
［第６の実施の形態のまとめ］
（１）本実施の形態は、サーバレスなシステムを構築することを可能とする。
（２）本実施の形態では、クライアント間で検索や更新のための通信をするときコストが発生するが、それを無駄にしないことを可能とする。クライアント間で通信するときに、今後の負担（データベースシステム全体における送信データ量）を減らすデータのやり取りも実施するためである。
［備考］
上記第１から第６の実施の形態は、いずれか２以上の実施の形態を適宜選択し、それらを組み合わせても、本発明の実施の形態の範囲内であり、発明の一態様として成立する。
【符号の説明】
【０２０９】
４８００…データベースシステム
４８０１…マスター・クライアント
４８０３…ノード・クライアント
４９０３…命令制御部
４８０５…データベース
５０１４…更新権利取得
５０１５…更新権利破棄
５０１６…つなぎかえ指定
５０１７…つなぎかえ処理
５０１９…つなぎかえ要求
５０２２…判定部
５０２７…予測データ
【特許請求の範囲】
【請求項１】
自己が最新のデータベースの内容を保有しているか否かを示す情報である更新権と、差分検索又はデータベースの同期の相手となる他のクライアントを特定する情報である問い合わせ先を記憶する記憶手段と、
つなぎかえを行うために要する第１の送信データ量が、つなぎかえを行わない場合における問い合わせを行うために要する第２の送信データ量より小さいか否かを判定する判定手段と、
前記判定手段が前記第１の送信データ量は前記第２の送信データ量より小さいと判定した場合、前記問い合わせ先が示す他のクライアントに、更新権を保有するクライアントを通知することを要求するメッセージであるつなぎかえ要求を送信させるつなぎかえ要求手段と、
前記更新権が更新権の保有を示しているときに他のクライアントからつなぎかえ要求を受信した場合、自己を前記問い合わせ先とすることを指示するメッセージであるつなぎかえ指定を前記他のクライアントに送信させるつなぎかえ指定手段と、
前記つなぎかえ指定を受信した場合、そのつなぎかえ指定において指定されたクライアントを前記問い合わせ先として記憶させるつなぎかえ処理手段と
を有することを特徴とするクライアント。
【請求項２】
前記判定手段は、
前記第２の送信データ量を、同期するまでに検索する回数と、つなぎかえにより減少する問い合わせに要する送信データ量と
から算出することを特徴とする、請求項１に記載のクライアント。
【請求項３】
前記判定手段は、下記式を用いて前記第１の送信データ量は前記第２の送信データ量より小さいか否かを判定することを特徴とする請求項１に記載のクライアント
d ≦ (C+1)×ｎ×(1-p)×（h-1）×d
但し、Ｃは当該クライアントの子ノードの数、ｎは平均問い合わせ回数、ｐはデータベースのデータが完全である確率、ｈは当該クライアントと更新権を有するクライアントとの階数差。
【請求項４】
前記請求項１から３までのいずれかに記載の複数のクライアントを有するデータベース・システム。
【請求項１】
自己が最新のデータベースの内容を保有しているか否かを示す情報である更新権と、差分検索又はデータベースの同期の相手となる他のクライアントを特定する情報である問い合わせ先を記憶する記憶手段と、
つなぎかえを行うために要する第１の送信データ量が、つなぎかえを行わない場合における問い合わせを行うために要する第２の送信データ量より小さいか否かを判定する判定手段と、
前記判定手段が前記第１の送信データ量は前記第２の送信データ量より小さいと判定した場合、前記問い合わせ先が示す他のクライアントに、更新権を保有するクライアントを通知することを要求するメッセージであるつなぎかえ要求を送信させるつなぎかえ要求手段と、
前記更新権が更新権の保有を示しているときに他のクライアントからつなぎかえ要求を受信した場合、自己を前記問い合わせ先とすることを指示するメッセージであるつなぎかえ指定を前記他のクライアントに送信させるつなぎかえ指定手段と、
前記つなぎかえ指定を受信した場合、そのつなぎかえ指定において指定されたクライアントを前記問い合わせ先として記憶させるつなぎかえ処理手段と
を有することを特徴とするクライアント。
【請求項２】
前記判定手段は、
前記第２の送信データ量を、同期するまでに検索する回数と、つなぎかえにより減少する問い合わせに要する送信データ量と
から算出することを特徴とする、請求項１に記載のクライアント。
【請求項３】
前記判定手段は、下記式を用いて前記第１の送信データ量は前記第２の送信データ量より小さいか否かを判定することを特徴とする請求項１に記載のクライアント
d ≦ (C+1)×ｎ×(1-p)×（h-1）×d
但し、Ｃは当該クライアントの子ノードの数、ｎは平均問い合わせ回数、ｐはデータベースのデータが完全である確率、ｈは当該クライアントと更新権を有するクライアントとの階数差。
【請求項４】
前記請求項１から３までのいずれかに記載の複数のクライアントを有するデータベース・システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７Ａ】
【図３７Ｂ】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図５２】
【図５３】
【図５４】
【図５５】
【図５６】
【図５７】
【図５８】
【図５９】
【図６０】
【図６１】
【図６２】
【図６３】
【図６４】
【図６５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７Ａ】
【図３７Ｂ】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図５２】
【図５３】
【図５４】
【図５５】
【図５６】
【図５７】
【図５８】
【図５９】
【図６０】
【図６１】
【図６２】
【図６３】
【図６４】
【図６５】
【公開番号】特開２０１２−１３７８６０（Ｐ２０１２−１３７８６０Ａ）
【公開日】平成２４年７月１９日（２０１２．７．１９）
【国際特許分類】
【出願番号】特願２０１０−２８８５８２（Ｐ２０１０−２８８５８２）
【出願日】平成２２年１２月２４日（２０１０．１２．２４）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２４年７月１９日（２０１２．７．１９）
【国際特許分類】
【出願日】平成２２年１２月２４日（２０１０．１２．２４）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]