オーバーフロー防止方法、 装置、 及びプログラム 技術分野
[0001] 本発明は、サーバコンピュータ (以下、「サーバ」 t 、う)からクライアントコンピュータ( 以下、「クライアント」 t 、う)へのデータ送信によるクライアント側メモリのオーバーフロ 一を防止するためのオーバーフロー防止装置等に関する。
背景技術
[0002] 近年、携帯情報端末 (携帯電話、 PDA等の比較的データ容量が小さ ヽデバイス)を 企業内サーバのクライアントとして活用したいという要求が高まっており、そのような要 求に対応した製品も登場している。尚、ここで、企業内サーバとは、例えば、米国 IB M社の Lotus Domino,米国マイクロソフト社の Microsoft Exchangeといったグループゥ エアや、米国 IBM社の DB2、米国オラクル社の Oracle等のデータベース製品を指し ている。
[0003] そのようなクライアントは、サーバとの接続の仕方に注目すると大きく 2種類に分けら れる。
1つは、 Connectedモデルのクライアントである。このモデルのクライアントは、常に サーバと通信しながら処理を行う。 Connectedモデルの代表的な例としては、サーバ が生
成する HTML文書を Webブラウザで閲覧しながら処理を進めていくクライアント形態 が挙げられる。
もう 1つは、 Disconnectedモデルのクライアントである。このモデルのクライアントは、 サーバとの通信を切断した状態で処理を行 、、クライアント上のデータをサーバ上の データに一致させる、いわゆるデータ同期を行う必要がある時に、サーバとの通信を 行う(
例えば、特許文献 1参照。 )o
[0004] このような Disconnectedモデルのクライアントでは、ユーザがデータの閲覧'入力処
理を行う際に通信が発生しないため、 Connectedモデルのクライアントに比べ、ユー ザ操作
が高速に行えるという大きな利点がある。但し、その利点を最大限生かすにはデータ 同期の頻度をできるだけ抑える必要があり、そのためには、できるだけ多くのデータを クライアントに保存しておくことが必要になる。例えば、クライアントでの操作に必要な 全てのデータを保存しておくことができれば理想的である。
[0005] 特許文献 1:特開 2000— 227889号公報 (第 2段落)
発明の開示
課題を解決するための手段
[0006] かかる目的のもと、本発明は、オーバーフローしないことが判明した場合にのみ、デ ータを送信するようにしている。即ち、本発明のオーバーフロー防止方法は、サーバ が保持するサーバデータベース (以下、「サーバ DB」 t 、う)からクライアントが保持す るクライアントデータベース (以下、「クライアント DB」という)へデータを送信することで 発生するクライアント DBのオーバーフローを防止するものであり、クライアントが、サ ーバに対し、クライアント DBの容量と、サーバ DB力 データを抽出するための条件と を知らせるステップと、サーバが、知らされた条件に合致するデータをサーバ DBから 抽出するステップと、抽出されたデータの容量力 知らされたクライアント DBの容量を 超えない場合に、抽出されたデータが、サーノからクライアント DBへ渡されるステツ プとを含んでいる。
一方、オーバーフローすることが判明した場合には、オーバーフローを起こさないよ うな設定変更の方法をユーザに知らせるようにしている。即ち、本発明のオーバーフ ロー防止方法は、抽出されたデータの容量力 知らされたクライアント DBの容量を超 える場合に、条件の変更に関するアドバイス情報をクライアントに提示するステップを 更に含んでもよい。
[0007] また、本発明は、オーバーフローしないことが判明した場合にのみ、データを送信 するオーバーフロー防止装置として捉えることもできる。その場合、本発明のオーバ 一フロー防止装置は、クライアントが保持するクライアント DBをサーバが保持するサ ーバ DBに同期させることで発生するクライアント DBのオーバーフローを防止するも
のであり、クライアントが指定する条件に合致するデータをサーバ DB力 抽出し、クラ イアント DBを抽出されたデータに同期させることでクライアント DBのオーバーフロー が発生するかどうかを判断する前処理部と、この前処理部によりクライアント DBのォ 一バーフローが発生しないと判断された場合に、クライアント DBを抽出されたデータ に同期させるための処理を行う同期処理部とを備えて 、る。
一方、オーバーフローすることが判明した場合には、オーバーフローを起こさないよ うな設定変更の方法をユーザに知らせることの可能なオーバーフロー防止装置とし て捉えることもできる。その場合は、前処理部が、クライアント DBのオーバーフローが 発生する
と判断された場合に、条件の変更に関するアドバイス情報をクライアントに提示するこ とを特徴とする。
[0008] さらに、本発明は、オーバーフロー防止機能を有するサーバとして捉えることもでき る。その場合、本発明のサーバは、クライアントから、そのクライアントのデータ格納領 域の容量情報と、そのクライアントに送信すべきデータを特定するための設定情報と を受信する受信部と、この受信部により受信された設定情報によってクライアントに送 信すべきデータを特定し、特定されたデータの容量情報と、受信部により受信された データ格納領域の容量情報とに基づき、特定されたデータがデータ格納領域のォー バーフローを発生させるかどうかを判定する判定部と、この判定部により特定された データがオーバーフローを発生させな!/、と判定された場合に、特定されたデータがク ライアントへ渡されるように処理する受渡し処理部とを備えて!/、る。
また、判定部により特定されたデータがオーバーフローを発生させると判定された 場合に、オーバーフローを発生させないようにするための設定情報に関するアドバイ ス情報を生成してクライアントに提示するアドバイス情報提示部を更に備えてもよい。
[0009] 一方、本発明は、コンピュータに所定の機能を実現させるためのプログラムとして捉 えることもできる。その場合、本発明の第 1のプログラムは、コンピュータに、他のコン ピュータから、他のコンピュータのデータ格納領域の容量情報と、他のコンピュータに 送信すべきデータを特定するための設定情報とを受信する機能と、受信された設定 情報によって他のコンピュータに送信すべきデータを特定し、特定されたデータの容
量情報と、受信されたデータ格納領域の容量情報とに基づき、特定されたデータが データ格納領域のオーバーフローを発生させるかどうかを判定する機能と、特定され たデータがオーバーフローを発生させな!/、と判定された場合に、特定されたデータ が他のコンピュータへ渡されるように処理する機能とを実現させる。
また、本発明の第 2のプログラムは、コンピュータに、他のコンピュータから、他のコ ンピュータのデータ格納領域の容量情報と、他のコンピュータに送信すべきデータを 特定するための設定情報とを受信する機能と、受信された設定情報によって他のコ ンピュータに送信すべきデータを特定し、特定されたデータの容量情報と、受信され たデータ格納領域の容量情報とに基づき、特定されたデータがデータ格納領域のォ 一バーフローを発生させるかどうかを判定する機能と、特定されたデータがオーバー フローを発生させると判定された場合に、設定情報を少なくとも 1つの制限方法で制 限して得られる少なくとも 1つの新たな設定情報を要素とする第 1の集合を求め、その 第 1の集合の要素から、データ格納領域のオーバーフローを発生させるデータを特 定する設定情報に対応する要素を除外することによって第 2の集合を求め、その第 2 の集合の要素の少なくとも 1つをアドバイス情報として提示する機能とを実現させる。
[0010] し力しながら、携帯情報端末のデータ容量は、数百キロバイトから多くても数メガバ イトであり、携帯情報端末に全てのデータを保存しておくことは事実上不可能である。 これに対し、サーバ上のデータをフィルタリングする機能を用いることも考えられる。 フィルタリング機能とは、サーバ上のデータを、クライアントがデータ同期を行う対象の データに絞り込む機能である。例えば、電子メールの場合には、発信者、緊急度 (緊 急、
普通、参考情報等)、サイズによるフィルタリング機能が提供され得る。また、スケジュ ールデータの場合には、期間によるフィルタリング機能が提供され得る。
[0011] しかし、このようなフィルタリング機能を用いても、以下のような問題点が存在する。
第 1の問題点は、フィルタリング機能によりデータを絞り込んでも、やはり、クライアン トのデータ容量を超えるデータが送信されることは防げないという点である。その結果 、フィルタリング機能により別の絞り方を試さなければならず、無駄な通信が発生して しく BR stvle= page-break-after: always ' >
まう。
例えば、携帯情報端末のデータ容量を考慮し、「10/01— 10/31」というフィルタリン グ設定を行ったとしても、オーバーフローが発生しな 、と 、う保証はな 、のである。
[0012] 第 2の問題点は、クライアントにてデータのオーバーフローが発生した場合に、どの データ同期が成功しどのデータ同期が成功しな力つたかが不明であり、次回データ 同期を行う際にオーバーフローを起こさないようなフィルタリングの設定変更の方法 が不明であるという点である。
例えば、「10/01— 10/31」というフィルタリング設定でオーバーフローした場合にお いて、フィルタリング設定を「10/06— 10/24」にすればオーバーフローしないのではな いかと推測し、そのようなフィルタリング設定を行ったとする。しかし、その場合でも、ォ 一バーフローしてしまう可能性はある。フィルタリング設定を、例えば、「10/06— 10/17」か「10/13— 10/31」に変更すればオーバーフローが防げる場合においても、 ユーザは、何度かの試行錯誤を繰り返さなければそのことを知ることはできな 、。
[0013] 本発明は、以上のような技術的課題を解決するためになされたものであって、その 目的は、サーノ からクライアントへデータを送信する際にクライアント側メモリのォー バーフローを起こさな 、ようにすることにある。 また他の目的は、サーノ からクライアントへデータを送信する際にどのような設定を すればクライアント側メモリのオーバーフローを起こさないかを知らせることにある。 発明の効果
[0014] 本発明によれば、サーバからクライアントへデータを送信する際にクライアント側メモ リのオーバーフローが起こらな 、ようになる。
図面の簡単な説明
[0015] [図 1]本発明の実施の形態が適用されるクライアント/サーバシステムの全体構成を示 した図である。
[図 2]本発明の実施の形態におけるオーバーフロー防止装置のハードウェア構成を 示したブロック図である。
[図 3]本発明の実施の形態におけるオーバーフロー防止装置の機能構成を示したブ ロック図である。
[図 4]本発明の実施の形態におけるサーブレットの動作を示したフローチャートである
[図 5]本発明の実施の形態における同期アダプタの動作を示したフローチャートであ る。
[図 6]本発明の実施の形態におけるアドバイス情報生成部の動作を示したフローチヤ ートである。
[図 7]本発明の実施の形態の動作を具体的に説明するための図である。
発明を実施するための最良の形態
[0016] 以下、添付図面を参照して、本発明を実施するための最良の形態 (以下、「実施の 形態
」と 、う)につ!/、て詳細に説明する。
図 1に示すように、本実施の形態は、クライアント 10と、サーバ 20と、汎用データ同 期装置 30と、同期データベース (以下、「同期 DB」という) 40と、オーバーフロー防止 装置 50とを備える。
クライアント 10は、例えば、携帯電話等の携帯情報端末であり、クライアント DB11と 、拡張アプリケーションプログラム (以下、「拡張 AP」という) 12とを有している。尚、拡 張 AP12は、オーバーフロー防止装置 50と直接通信を行うために、本実施のく BR style= page— break— after:always >
形態においてクライアント 10に新たに導入されたプログラムであり、例えば、無線通 信によりクライアント 10にダウンロードしインストールしたものであってよい。また、クラ イアント 10は、拡張 API 2に対しユーザが各種設定を入力するためのユーザインタ 一フェースを備える。
[0017] サーバ 20は、複数のクライアント 10から共通にアクセス可能なコンピュータである。
サーバ 20は、サーバ DB21を有し、クライアント DB11内のデータと同じ項目のデー タを格納する。
ところで、本実施の形態において、クライアント 10は、 Disconnectedモデルのクライ アントであり、所定のタイミングで、クライアント DB11の内容をサーバ DB21の内容に 一致させるデータ同期を行う必要がある。このデータ同期を行うの力 汎用データ同
期装置 30である。汎用データ同期装置 30としては、例えば、 SyncMLによりデータ 同期を行う Syncサーバが挙げられる。
[0018] 同期 DB40は、汎用データ同期装置 30によるデータ同期の対象となるデータ (以下 、「同期データ」という)を格納するデータベースである。尚、図 1には図示していない 力 同期 DB40は、複数のクライアント 10のそれぞれに対して設けられ、あるクライァ ント 10へ送られる同期データは、そのクライアント 10に対応する同期 DB40に格納さ れること〖こなる。
そして、オーバーフロー防止装置 50は、本実施の形態の中核部分をなす装置であ り、同期処理を行う同期処理部としての機能と、同期処理部の前段階の処理を行う前 処理部としての機能とを有するものである。ここで、前処理部とは、拡張 AP12から受 信した情報に基づき、クライアント DB11のオーバーフローが発生するかどうかを判断 し、オーバーフローが発生すると判断された場合にオーバーフローを発生させな 、よ うな設定をアドバイス情報としてクライアント 10に通知するものである。また、同期処理 部とは、クライアント DB11のオーバーフローが発生しない場合に、同期データを同 期 DB40に格納するものである。
[0019] 図 2は、本実施の形態におけるオーバーフロー防止装置として用いるのに好適なコ ンピュータのハードウェア構成の例を模式的に示した図である。
図 2に示すコンピュータは、演算手段である CPU(Central Processing Unit)501 と、 M/B (マザ一ボード)チップセット 502および CPUバスを介して CPU501に 接続されたメインメモリ 503と、同じく M/Bチップセット 502および AGP(Accelerated Graphics Port)を介して CPU501に接続されたビデオカード 504及びディスプレイ 51 0と、 PCI(Peripheral Component Interconnect)バスを介して M/Bチップセット 502に 接続された磁気ディスク装置 (HDD)505、ネットワークインターフェイス 506と、さらに この PCIバスからブリッジ回路 507および ISAdndustry Standard Architecture)バスな どの低速なバスを介して M/Bチップセット 502に接続さ
れたフレキシブルディスクドライブ 508およびキーボード/マウス 509とを備える。
[0020] 尚、図 2は本実施の形態を実現するコンピュータのハードウェア構成を例示するに 過ぎず、本実施の形態を適用可能であれば、他の種々の構成を取ることができる。
例えば、ビデオカード 504を設ける代わりに、ビデオメモリのみを搭載し、 CPU501に てイメージデータを処理する構成としてもよいし、外部記憶装置として、 ATA(AT Attachment)や SCSI(Small Computer System Interface)等のインターフェイスを介し て CD— R(Compact Disc Recordable)や DVD— RAM(Digital Versatile Disc Random Access Memory)のドライブを設けてもよい。
[0021] 次に、図 3を参照して、本実施の形態におけるオーバーフロー防止装置 50の機能 について説明する。
図 3に示すように、オーバーフロー防止装置 50は、サーブレット 51と、同期アダプタ 52と、共有データベース (以下、「共有 DB」という) 53とを含んでいる。ここで、サーブ レット 51及び同期アダプタ 52は、オーバーフロー防止装置 50上で動作するプロダラ ムである。即ち、オーバーフロー防止装置 50の CPU501が、例えば、磁気ディスク 装置 505に記憶されたこれらのプログラムをメインメモリ 503に読み込んで実行する。 その実行状態において、サーブレット 51が果たす機能を細分ィ匕すると、受信部 54と 、データ取得部 55と、判定部 56と、アドバイス情報生成部 57と、送信部 58とに分け ることがでさる。
[0022] 受信部 54は、クライアント 10からクライアント DB11の容量とフィルタリング設定とを 含む同期開始要求を受信する部分である。データ取得部 55は、受信部 54が受信し た同期開始要求に含まれるフィルタリング設定に基づき、サーバ DB21から同期デー タを抽出し、共有 DB53に格納する部分である。判定部 56は、同期データの容量が 、受信部 54が受信した同期開始要求に含まれるクライアント DB11の容量を超えて いるかどうかを判定し、超えていればアドバイス情報生成部 57を呼び出し、超えてい なければ同期アダプタ 52を呼び出す部分である。
アドバイス情報生成部 57は、フィルタリング設定をどのように変更すれば同期デー タの容量がクライアント DB11の容量を超えなくなるかのアドバイス情報を生成する部 分である。送信部 58は、判定部 56による判定の結果に基づき、同期可能通知又は エラーコード ·アドバイス情報を送信する部分である。
[0023] 次に、図 4一 6を参照して、本実施の形態の動作について、詳細に説明する。
図 4は、サーブレット 51の動作を示したフローチャートである。
まず、受信部 54が、クライアント 10から同期開始要求を受信したかどうか判定する( ステップ 101)。同期開始要求には、クライアント DB11の容量とフィルタリング設定と が含まれる。
尚、フィルタリング設定とは、サーバ DB21に格納されたデータに対しフィルタリング を行って同期データを抽出する際の条件設定である。サーバ DB21にスケジュール データが格納されている場合であれば、例えば、「Aさんのスケジュール」、「Bさんの スケジュール」等、「人」に着目して設定を行う場合や、「4日のスケジュール」、「5日 のスケジュール」等、「日」に着目して設定を行う場合等が考えられる。以下では、この ような設定における「人」、「日」等、フィルタリングにおいて着目する項目を「フィルタリ ング項目」と呼ぶことにし、このような設定における「Aさん」、「4日」等、フィルタリング 項目にお 、て指定される値のことを「項目値」と呼ぶことにする。
[0024] ここで、受信部 54は、同期開始要求を受信したと判定しな 、場合、ステップ 101の 判定を繰り返すが、同期開始要求を受信したと判定すると、同期開始要求に含まれ るクライアント DB11の容量を判定部 56に受け渡すと共に、同期開始要求に含まれ るフィルタリング設定をデータ取得部 55に受け渡す。
これにより、データ取得部 55は、フィルタリング設定にマッチするデータ (同期デー タ)をサーバ DB21から取得し、同期データを共有 DB53に格納すると共に、その容 量を判定部 56に受け渡す (ステップ 102)。尚、クライアント 10に既に取得されたデー タがある場合には、データ取得部 55は、そのデータの取得以降にサーバ 20にて変 更 ·追加されたデータの中力もフィルタリング設定にマッチするデータ (同期データ)を 取得する。
この方法としては、例えば、クライアント DB11内のデータ及びそのクライアント 10へ の送信日時情報を同期 DB40に記憶しておき、データ取得部 55が、これらの情報を 参照してそれ以降にサーバ DB21にて変更 ·追カ卩が行われたデータを抽出する方法 が考えられる。
[0025] その後、判定部 56は、受信部 54から受け渡されたクライアント DB11の容量と、デ ータ取得部 55から受け渡された同期データの容量とを比較し、同期データの容量が クライアント DB11の容量以下であるかどうかを判定する (ステップ 103)。
ここで、同期データの容量力クライアント DB11の容量以下であると判定すると、判 定部 56は、同期アダプタ 52に対し、同期データを同期 DB40に格納するよう要求し( ステップ 104)、図 5に示す同期アダプタ 52の処理が行われる (ステップ 105)。
その後、送信部 58は、データ同期が可能であることを示す戻り値 (同期可能通知)を クライアント 10に返信する (ステップ 106)。
一方、同期データの容量力 Sクライアント DB11の容量よりも大きいと判定すると、判 定部 56は、アドバイス情報生成部 57に対し、アドバイス情報を生成するよう要求し、 図 6に示すアドバイス情報生成処理が行われる (ステップ 107)。そして、アドバイス情 報が生成されると、オーバーフローを示すエラーコードとアドバイス情報とをクライアン ト 10に返信する (ステップ 108)。
[0026] 次に、図 5を参照して、同期アダプタ 52の動作を説明する。
まず、同期アダプタ 52は、サーブレット 51から同期データ格納要求を受信したかど うか判定する (ステップ 201)。ここで、同期データ格納要求を受信していないと判定す ると、ステップ 201を繰り返すが、同期データ格納要求を受信したと判定すると、共有 DB53から同期データを読み出し (ステップ 202)、その同期データを同期 DB40に格 納する (ステップ 203)。
[0027] また、図 6を参照して、アドバイス情報生成部 57の動作を説明する。
動作の開始にあたり、アドバイス情報生成部 57は、クライアント DB11に何件のデ ータが格納可能であるかを予め把握しておく。このデータ件数は、クライアント DB11 の容量を同期データのサイズで除することにより求めることができる。
尚、同期データのサイズとしては、フィルタリング設定における全てのフィルタリング 項目を考慮して抽出される同期データのサイズを採用する。例えば、サーバ DB21に スケジュールデータが格納されて 、る場合に、フィルタリング設定におけるフィルタリ ング項目として「日」及び「人」が選択されたとすると、特定の日の特定の人について のスケジュールデータのサイズを採用することになる。
[0028] このような状態の下で、アドバイス情報生成部 57は、フィルタリング設定におけるフ ィルタリング項目ごとに図 6の処理を行う。
まず、アドバイス情報生成部 57は、着目するフィルタリング項目において指定され
た項目値の少なくとも 1通りの組み合わせを用意し、それらの組み合わせを要素とす る集合 Iを求める (ステップ 301)。尚、この少なくとも 1通りの組み合わせを選定するに あた
つては、まず、全ての項目値力 なる組み合わせは除外する。それは、全ての項目値 力 なる組み合わせにつ 、ては、クライアント DB11のオーバーフローを発生させるこ とは分力つているので、そのような組み合わせをアドバイス情報として提示することは あり得な!/、からである。また、「日」のように、項目値に連続性のあるフィルタリング項目 の場合、互いに隣接しない項目値を含む組み合わせは除外する。それは、例えば、 フィルタリング項目「日」に対し、「4日」、「5日」、「6日」、「7日」を指定した場合に、そ れを「4日」及び「7日」の指定に変更するような要望はあまりないと考えられる力もであ る。
[0029] 次に、集合 Iの要素である項目値の組み合わせのそれぞれに対し、その組み合わ せでフ
ィルタリングを行った場合に抽出されるデータの容量を計算する (ステップ 302)。 その結果、データ容量力クライアント DB11の容量を超えることとなる組み合わせを 集合 Iの要素から除外し、その除外後の集合を集合 IIとする (ステップ 303)。
更に、アドバイス情報生成部 57は、集合 IIの要素のうち、集合 IIの他の要素に包含 される要素を集合 IIから除外し、その除外後の集合を集合 IIIとする (ステップ 304)。 そして、集合 IIIの全ての要素をアドバイス情報として送信部 58に受け渡す (ステップ
305)。これにより、送信部 58が、クライアント 10に対し、アドバイス情報を送信 すること〖こなる。
[0030] 次に、本実施の形態の動作について、具体例を用いて述べる。
本具体例は、本発明を SFA(Sales Force Automation)システムに適用し、携帯電話 等のクライアント 10からサーバ 20で管理する営業員のスケジュール情報を閲覧する 場面を想定したものである。図 7(a)にこのようなスケジュール情報の一部を示す。この スケジュール情報は、 Aさん、 Bさん、 Cさんの 4一 7日のスケジュール情報というフィ ルタリング設定により抽出されたものである。
ステップ 101で受信部 54が受信する同期開始要求にこのフィルタリング設定が含ま
れ、ステップ 102でデータ取得部 55がこのフィルタリング設定にマッチするデータを サーバ DB21から抽出することでこのような情報を取得する。
ここで、この抽出された全データの件数は「32」であり、クライアント DB11に格納可 能なデータの件数が「32」以上であれば、ステップ 103での判定は「Yes」となり、デ ータ同期は成功する。
[0031] し力し、ここでは、例えば、クライアント DB11の容量が 5120バイトであるとし、特定 の日の特定の人のスケジュールデータのサイズが 256バイトであるとする。即ち、クラ イアント DB11に格納可能なデータの件数は、「20(= 5120/256)」で
あるとする。
そうすると、ステップ 103での判定は「No」となり、ステップ 107でアドバイス情報が 生成され、ステップ 108でその生成されたアドバイス情報がクライアント 10に送信され ることになる。
[0032] 以下、アドバイス情報の生成について、詳細に述べる。
まず、フィルタリング項目「日」に着目した場合の図 6の動作について、図 7(b)を参 照しながら説明する。
フィルタリング項目「日」に対する項目値は、「4日」、「5日」、「6日」、「7日」であるの で、ステップ 301で、その項目値の少なくとも 1通りの組み合わせを要素とする集合 Iを 求める。フィルタリング項目「日」はその項目値に連続性があるため、「全
ての項目値力もなる組み合わせは除外する」 t 、う規則に加え、「互いに隣接しな!ヽ 項目値を含む組み合わせは除外する」という規則を適用し、集合 Iの要素は、図 7(b) に示す
ように、「5曰、 6曰、 7曰」、「4曰、 5曰、 6曰」、「6曰、 7曰」、「5曰、 6曰」、「4曰、 5曰」 、「7日」、「6日」、「5日」、「4日」となる。
[0033] 次に、ステップ 302で集合 Iの各要素に対し、その要素でフィルタリングを行った場 合に抽出されるデータの容量を対応付ける。具体的には、「5日、 6日、 7日」に対して は、図 7(a)の「5日」に対する合計と、「6日」に対する合計と、「7日」に対する合計とを 足し合わせることにより、「29(=8 + 8 + 13)」を対応付ける。同様に、「4日、 5日、 6日 」に対し「19(= 3 + 8 + 8)」を、「6日、 7日」に対し「21(=8
+ 13)」を、「5日、 6日」に対し「16(=8 + 8)」を、「4日、 5日」に対し「1 1(= 3 + 8)」を、「7日」に対し「13」を、「6日」に対し「8」を、「5日」に対し「8」を、「4日 」に対し「3」を対応付ける。
[0034] 次に、ステップ 303で、求めたデータ容量がクライアント DB11の容量を超える要素 については、集合 Iから除外することで、集合 IIを求める。即ち、集合 IIの要素におい ては、図 7(b)に示すように、集合 Iから「5日、 6日、 7日」及び「6日、 7日」力 S除 外されている。
更に、ステップ 304で、集合 IIの要素力も他の要素に包含される要素を除外すること で、集合 IIIを求める。良!]ち、「5日、 6日」、「4日、 5日」、「6日」、「5日」、
「4日」は、「4日、 5日、 6日」に包含されるので、集合 IIIの要素においては、図 7(b)に 示すように、これらの要素は除外されている。
結局、集合 ΠΙの要素は、「4日、 5日、 6日」及び「7日」となり、ステップ 305 では、これをアドバイス情報とする。
[0035] 次に、フィルタリング項目「人」に着目した場合の図 6の動作について、図 7(c)を参 照しながら説明する。
フィルタリング項目「人」に対する項目値は、「Aさん」、「Bさん」、「Cさん」であるので 、ステップ 301で、その項目値の少なくとも 1通りの組み合わせを要素とする集合 Iを 求める。フィルタリング項目「人」はその項目値に連続性がないため、「全ての 項目値力もなる組み合わせは除外する」という規則のみを適用し、集合 Iの要素は、 図 7(c)に示すように、「Bさん、じさん」、「Aさん、じさん」、「Aさん、 Bさん」、「〉 じさん」、「Bさん」、「Aさん」となる。
[0036] 次に、ステップ 302で集合 Iの各要素に対し、その要素でフィルタリングを行った場 合に抽出されるデータの容量を対応付ける。具体的には、「Bさん、 Cさん」に対して は、図 7(a)の「Bさん」に対する合計と、「Cさん」に対する合計とを足し合わせることに より、「24(= 11 + 13)」を対応付ける。同様に、「Aさん、 Cさん」に対し「21(=8 + 13) 」を、「Aさん、 Bさん」に対し「19(=8 + 11)」を、「Cさん」に対し「13」を、「Bさん」に対 し「11」を、「Aさん」に対し「8」を対応付ける。
[0037] 次に、ステップ 303で、求めたデータ容量がクライアント DB11の容量を超える要素
については、集合 Iから除外することで、集合 IIを求める。即ち、集合 IIの要素におい ては、図 7(c)に示すように、集合 Iから「Bさん、 Cさん」及び「Aさん、 Cさん」が 除外されている。
更に、ステップ 304で、集合 IIの要素力も他の要素に包含される要素を除外すること で、集合 IIIを求める。即ち、「Bさん」、「Aさん」は、「Aさん、 Bさん」に包含さ れるので、集合 IIIの要素においては、図 7(c)に示すように、これらの要素は除外され ている。
結局、集合 IIIの要素は、「Aさん、 Bさん」及び「Cさん」となり、ステップ 305 では、これをアドバイス情報とする。
[0038] 以上により、送信部 58は、例えば、「アドバイス 1(期間の変更) :データ同期範囲を 4 、 5、 6日又は 7日にしましょう」、「アドバイス 2(メンバの変更):データ同期範囲を A、 B 又は Cにしましょう」といったアドバイス情報を送信する。
[0039] 以上述べたように、本実施の形態では、同期 DB40には、クライアント DB11がォー バーフローを起こさな 、分のデータしか存在しな 、ので、クライアント DB11がオーバ 一フローすることはなく、従って、無駄な通信は発生しない。
また、同期アダプタ 52からのフィルタリング設定のアドバイス情報に基づきフィルタリ ング設定をすれば、次回のデータ同期は必ず成功する。
更に、本実施の形態では、データ同期機能の部分は、従来のものをそのまま利用 できる構成にしており、クライアント側ソフトウェアの拡張が容易かつ変更量が小さい という利点がある。
[0040] 尚、本実施の形態は、 SyncMLプロトコルを用いたデータ同期システムだけに限ら ず、サーバとクライアントのデータ同期を行うシステム全般 (DB2等のデータベース他) に適用可能である。また、データ同期を行うシステムに限られるものでもなぐサーバ 20からクライアント 10へ単にデータを送信する一般的なシステムにも適用できるもの である。その場合、汎用データ同期装置 30は、サーバ 20からクライアント 10へのデ ータ送信処理を行う所定の機能となり、同期 DB40は、その装置へ送信対象のデー タを受け渡すための中間ファイルとなる。
更に、本実施の形態では、オーバーフロー防止装置 50を、サーバ DB21を有する
サーバ 20とは物理的に独立した装置して述べた力 オーバーフロー防止装置 50の 機能の全部又は一部をサーバ 20の機能として実現することも可能である。