JP4179880B2 - データを同期させるシステム、そのシステムに用いられる装置およびデータ同期方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
この発明は、データアクセスシステムに関し、特に、データサーバ装置に記憶されているデータをクライアント装置に記憶されているかのごとく利用することが可能なデータアクセスシステムに関する。
【０００２】
【従来の技術】
従来、サーバにおいてクライアント装置のデータを一括管理するシステムとして、グループウェアシステムがある。
【０００３】
グループウェアシステムでは、たとえば、スケジュールやメモなどのデータをグループデータとしてサーバに登録しておくと、そのグループに属する全てのユーザはそのスケジュールを参照できるようになるものである。このグループウェアにおけるグループデータの参照の方法には大きく分けて２種類ある。一つはクライアント装置がグループデータを参照するときには必ずサーバへ接続し、その時点でのサーバのデータを参照する方法である。もう一つは、クライアント装置毎にグループデータを全て記憶しておき、サーバのグループデータに変更があると、サーバは全てのクライアント装置に記憶されているグループデータを変更する処理を行なう方法がある。
【０００４】
特開２０００−１４８５７２公報においては、無線移動端末からの通信要求を、通信が不可能な間は、メッセージキューに蓄積しておき、通信が可能となったときに、キューに蓄積された通信処理を行なう方法、および、無線移動端末の表示装置に表示されるリストを変更するリスト更新方法について開示されている。
【０００５】
また、特開２０００−１４８６９１公報においては、情報同期システムとして、クライアント装置において発生したデータ更新が、グループウェア情報であった場合に、関係するメンバーのクライアント装置の同じグループウェア情報を、メールを利用することにより一致させる情報同期システムが開示されている。
【０００６】
しかしながら、従来のグループウェアでは、次のような課題がある。
クライアント装置がデータを参照するときにサーバへ接続し、その時点でのサーバのデータを参照する場合においては、サーバにおいて管理されているグループデータに変更があった場合、個々の端末では、サーバにおいてグループデータの更新があったことが通知されない。このため、ユーザが意識をしてサーバ上のグループデータにアクセスしない限り、該グループデータの更新に気がつかないことがあるという問題がある。また、クライアント装置がグループデータを参照する毎に通信が発生し、ネットワーク上のトラフィックが増大するという問題がある。
【０００７】
次に、クライアント装置内にグループデータを全て記憶しておき、サーバのグループデータに変更があったときに全てのクライアント装置内のグループデータを変更するようにした場合、各クライアントで完全なグループデータを記憶する記憶容量が必要となる問題がある。また、サーバのグループデータに変更が生じると、全てのクライアントのグループデータを更新しなければならない。このため、ネットワーク上のトラフィックが増大するという問題がある。
【０００８】
次に、特開２０００−１４８５７２公報においては、サーバから無線移動端末のデータを効率よく更新するような技術は開示されていない。また、サーバにおいて記憶されている各無線移動端末のデータのオリジナルと各無線移動端末のデータとの複雑な関連を記憶する方法に関してはなんら教示しておらず、解決を与えることができない。
【０００９】
特開２０００−１４８６９１公報においては、各クライアントにおいてサーバの記憶領域を、各クライアントの記憶領域のように使用することはできない。このため、各クライアントは、実際に各クライアントに実装されている記憶領域以上のデータを取り扱うことができない。また、各クライアントにおいて、同期するべきグループデータを管理するグループウェア管理テーブルおよび管理機能が必要となり、クライアント側の負担が増大する。さらに、あるクライアントにおいてグループデータの更新が発生すると全てのクライアント装置に対して更新内容を通知するため、ネットワーク上のトラフィックが増大する。
【００１０】
【発明が解決しようとする課題】
これら特開２０００−１４８５７２公報および特開２０００−１４８６９１公報に開示の技術を単に組み合わせたとしても、グループデータの更新のたびにすべてのクライアント装置に対して通信が発生しネットワーク上のトラフィックが増大するという問題は解決できない。また、個々のクライアント装置の負担を軽減しながら種々の通信サービスを実現することもできない。
【００１１】
そこで、この発明の目的は、ネットワークトラフィックを増加させることなく、ユーザがクライアント装置を用いて情報を利用することができるデータサーバ装置、クライアント装置およびデータアクセスシステムを提供することである。
【００１２】
この発明の他の目的は、ユーザがクライアント装置を用いて、そのクライアント装置の実記憶容量よりもはるかに多い情報を利用することができるデータサーバ装置、クライアント装置およびデータアクセスシステムを提供することである。
【００１３】
この発明のさらに他の目的は、ユーザがクライアント装置を用いて、そのユーザにとって有意義な情報を利用することができるデータサーバ装置、クライアント装置およびデータアクセスシステムを提供することである。
【００１４】
この発明のさらに他の目的は、セキュリティを確保しつつ、ユーザがクライアント装置を用いて情報を利用することができるデータサーバ装置、クライアント装置およびデータアクセスシステムを提供することである。
【００１５】
この発明のさらに他の目的は、ユーザがクライアント装置を用いて、必要に応じて情報を利用することができるデータサーバ装置、クライアント装置およびデータアクセスシステムを提供することである。
【００１６】
【課題を解決するための手段】
本発明のある局面に従うデータサーバ装置は、木構造を構成する要素の集合をサーバデータとして記憶するサーバデータ記憶部と、サーバデータのそれぞれとクライアント装置との対応関係と、各クライアント装置の表現能力を示す属性とを記憶するクライアント記憶データ管理部とを含み、サーバデータは、要素がどのような種類のデータであるかを示す種別属性を持つ要素およびユーザにより指定された重要度を示す重要度属性を持つ要素を含み、クライアント記憶データ管理部は、サーバデータ記憶部に記憶されたサーバデータが更新された場合に、サーバデータとクライアント装置との対応関係に基づき通知すべきクライアント装置を決定し、更新されたサーバデータの各要素の種別属性および重要度属性とクライアント装置の種別を含む属性とに基づき、木構造を構成する要素の集合の部分集合を選択して送信する。
好ましくは、さらに、ユーザが所属するグループおよび所有する端末装置を示すユーザの属性を記憶するユーザプロファイル記憶部を含み、クライアント記憶データ管理部による選択は、サーバデータに含まれる要素が持つ種別属性および重要度属性、クライアント装置の種別を含む属性、ユーザの属性のいずれかから導出される必要性に応じて行なわれる。
好ましくは、クライアント記憶データ管理部による選択において、要素の削除は、要素の実体の削除か、サーバ上の要素へのリンクの置換えのいずれかを、選択的に行なうことにより実現される。
好ましくは、サーバデータは、ＸＭＬを用いて構造化されている。
【００７９】
さらに好ましくは、クライアント記憶データ管理部は、クライアント装置において記憶中のクライアントデータを更新するデータと、少なくとも要素の重要度属性、時間属性または端末属性に基づいて決定された、クライアントデータが更新されたことをユーザに通知する方法を表わす通知情報とを、対応関係に基づいて抽出されたクライアント装置に送信するように処理を決定する。
【００８０】
クライアント装置のユーザに、データ更新を通知する方法が、対応関係に基づいて決定される。これにより、たとえばサーバデータの重要度に基づいて、通知方法を、大音量の警報による通知、ビープ音による通知、表示のみによる通知などに決定できる。
【００８１】
さらに好ましくは、クライアント記憶データ管理部は、クライアント装置において記憶中のクライアントデータを更新するデータと、少なくとも要素の重要度属性、時間属性または端末属性に基づいて決定された、更新されたクライアントデータを消去する方法を表わす消去情報とを、対応関係に基づいて抽出されたクライアント装置に送信するように処理を決定する。
【００８２】
クライアント装置のユーザに、データを消去する方法が、対応関係に基づいて決定される。これにより、たとえばサーバデータの重要度に基づいて、データの消去方法を、更新から１日経過すると消去、更新から１週間経過すると消去などに決定できる。
さらに好ましくは、クライアント記憶データ管理部は、サーバデータに含まれる要素が持つ種別属性、重要度属性およびクライアント装置の種別を含む属性に対応させて定められたアルゴリズムに基づいて、ユーザ通知の必要性およびガーベージコレクションの必要性を規定した機会優先度およびクライアントデータを伝播すべき時間および伝播すべきクライアント装置を規定した伝播優先度を算出し、算出された優先度に対応して、クライアントデータに対する処理を決定する。
さらに好ましくは、クライアント記憶データ管理部は、クライアント装置へ送信される通信データを、構造化されたデータに含まれる複数の要素の中から要素を選択することにより、クライアントデータに対して処理するように決定する。
本発明の別の局面に従うクライアント装置は、データサーバ装置のサーバデータ記憶部
に記憶されたサーバデータの一部または全部であるクライアントデータを記憶するクライアントデータ記憶部と、データサーバ装置から、更新されたクライアントデータと通知情報とを含む更新情報を受信する受信部と、クライアント装置のユーザに、クライアントデータが更新されたことを通知する通知部と、更新情報を受信すると、クライアントデータ記憶部に記憶されている当該データを更新情報に応じて更新するとともに、クライアントデータに含まれる要素がどのような種類のデータであるかを示す種別属性および重要度属性、クライアント装置の種別を含む属性、ユーザが所属するグループおよび所有する端末装置を示すユーザの属性のいずれかから導出される必要性に応じて、クライアントデータが更新されたことをユーザに通知する、あるいは通知しないように、クライアントデータ記憶部と通知部とを制御する制御部とを含み、受信部による更新情報によりクライアントデータ記憶部の空き容量が不足した場合、クライアント装置は、クライアントデータの各要素の種別属性および重要度属性とクライアント装置の種別を含む属性とに基づき、クライアントデータ記憶部に記憶されたクライアントデータの要素を消去して、クライアントデータの要素が消去されたことに応答して、消去されたクライアントデータの要素に対応するデータサーバ装置のマスタデータの当該要素へのリンク情報を設定する消去処理部をさらに含む。
好ましくは、クライアント装置は、クライアントデータ記憶部に記憶されたクライアントデータを、クライアントデータの各要素の種別属性および重要度属性、クライアント装置の種別を含む属性、ユーザが所属するグループおよび所有する端末装置を示す属性のいずれかから導出される必要性に応じて、段階的に消去する消去処理部をさらに含む。
好ましくは、データサーバ装置のサーバデータ記憶部に記憶されたサーバデータの一部または全部であるクライアントデータを記憶するクライアントデータ記憶部と、データサーバ装置から、更新されたクライアントデータと消去情報とを含む更新情報を受信する受信部と、クライアントデータ記憶部と受信部とに接続され、受信部が受信した更新情報に含まれる更新されたクライアントデータをクライアントデータ記憶部に記憶するとともに、更新情報に含まれる消去情報に基づいてクライアントデータ記憶部に記憶されたクライアントデータを消去するように、クライアントデータ記憶部を制御する制御部とを含む。
本発明のさらに別の局面に従うデータアクセスシステムは、上記データサーバ装置と、ネットワークを介して、データサーバ装置に接続された上記クライアント装置とを含む。
本発明のさらに別の局面に従うデータアクセスシステムは、データ同期方法は、木構造を構成する要素の集合をサーバデータとして記憶し、サーバデータのそれぞれとクライアント装置との対応関係と、各クライアント装置の表現能力を示す属性とを記憶するデータサーバ装置と、ネットワークを介して、データサーバ装置と接続され、サーバデータの一部または全部であるクライアントデータを記憶するクライアント装置とを含むデータアクセスシステムで用いられる、サーバデータとクライアントデータとのデータ同期方法であって、サーバデータは、要素がどのような種類のデータであるかを示す種別属性を持つ要素およびユーザにより指定された重要度を示す重要度属性を持つ要素を含み、クライアント装置が、クライアント装置に記憶されているクライアントデータが更新された際に、データサーバ装置にデータ更新の通知をするステップと、データサーバ装置が、クライアント装置からデータ更新の通知を受信すると、サーバデータとクライアント装置との対応関係に基づき通知すべきクライアント装置を決定し、更新されたサーバデータの各要素の種別属性および重要度属性とクライアント装置の種別を含む属性とに基づき、木構造を構成する要素の集合の部分集合を選択して送信するステップとを含む。
本発明のさらに別の局面に従う記録媒体は、コンピュータにデータサーバ機能を実現させるためのプログラムを記録したコンピュータ読取可能な記録媒体であって、プログラムは、コンピュータを、木構造を構成する要素の集合をサーバデータとして記憶するサーバデータ記憶手段と、サーバデータのそれぞれとクライアント装置との対応関係と、各クライアント装置の表現能力を示す属性とを記憶するクライアント記憶データ管理部として機能させ、サーバデータは、要素がどのような種類のデータであるかを示す種別属性を持つ要素およびユーザにより指定された重要度を示す重要度属性を持つ要素を含み、クライアント記憶データ管理部が、サーバデータ記憶部に記憶されたサーバデータが更新された場合に、サーバデータとクライアント装置との対応関係に基づき通知すべきクライアント装置を決定し、更新されたサーバデータの各要素の種別属性および重要度属性とクライアント装置の種別を含む属性とに基づき、木構造を構成する要素の集合の部分集合を選択して送信するよう機能させるためのプログラムである。
【００９９】
【発明の実施の形態】
以下、図面を参照しつつ、本発明の実施例について説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称および機能も同じである。したがってそれらについての詳細な説明の繰返しは適宜省略する。
【０１００】
第１の実施例
図１を参照して、本実施例に係るデータアクセスシステムは、インターネットに代表されるネットワーク５に接続され、スケジュールやメモなどのデータを登録、表示するためにユーザが使用するクライアント装置１０と、ネットワーク５に接続され、クライアント装置１０において記憶中のデータを管理するデータサーバ装置１とを含む。
【０１０１】
図２を参照して、データサーバ装置１は、各クライアント装置１０により利用されるサーバデータを記憶するサーバデータ記憶部３と、サーバデータ記憶部３に接続され、各クライアント装置１０において記憶中のデータを管理するクライアント記憶データ管理部２と、ネットワーク５およびクライアント記憶データ管理部２に接続され、各クライアント装置１０と通信を行なう通信部４とを含む。
【０１０２】
図３を参照して、クライアント装置１０は、ネットワーク５を介してデータサーバ装置１と通信を行なう通信部１１と、データサーバ装置１のサーバデータ記憶部３に記憶されたサーバデータの一部または全部、および、場合によってはクライアント装置１０に固有のデータを記憶するクライアントデータ記憶部１２と、ユーザへ文字情報や映像情報を提示する表示装置（図示せず）と、音や音声を出力するスピーカからなる出力部１３と、キーボード、ボタン、カメラまたはマイクなどからなる入力部１４と、通信部１１、クライアントデータ記憶部１２、出力部１３、入力部１４および表示装置に接続され、これらの装置を制御する制御部１５とを含む。
【０１０３】
クライアント装置１０として、図４Ａに示すようなＰＤＡ（PersonalDigital Assistants）や、図４Ｂに示すような携帯電話が想定される。
【０１０４】
本構成において、各クライアント装置１０のクライアントデータ記憶部１２には、データサーバ装置１のサーバデータ記憶部３に記憶されているサーバデータの一部または全部が記憶されているものとする。すなわち、クライアント装置１０は、データサーバ装置１より必要なサーバデータを適宜クライアントデータ記憶部１２にダウンロードする。原則的に比較的最近使ったデータについてはクライアント装置１０のクライアントデータ記憶部１２に記憶されているようにし、古いデータや重要度の低いデータは順次クライアントデータ記憶部１２より削除を行なうようにする。このような仕組みを設けることにより、クライアント装置１０は、あたかもデータサーバ装置１の広大な記憶容量を有するサーバデータ記憶部３がクライアント装置１０内にあるかのように利用できるようになる。
【０１０５】
なお、クライアント装置１０が携帯電話機能を持つ場合などは、クライアントデータ記憶部１２より電話帳のデータについては削除しないなど、状況やデータの種類などに応じ所定の取り決めに従いデータを扱うようになっている。また、クライアント装置１０の制御部１５は、クライアントデータ記憶部１２において削除処理が発生すると、そのことをデータサーバ装置１に通知するようになっている。データサーバ装置１のクライアント記憶データ管理部２は、各クライアント装置１０のクライアントデータ記憶部１２に、サーバデータのどの部分が記憶されているかをクライアント装置１０毎に管理する。
【０１０６】
図５〜図７を参照して、データサーバ装置１の機能を実現するためのプログラムの制御構造の概要について説明する。
【０１０７】
図５を参照して、データサーバ装置１の全体的な制御の流れについて説明する。
【０１０８】
データサーバ装置１はクライアント装置１０からの通信を待ち（Ｓ１０１）、通信があると（Ｓ１０１でＹｅｓ）、そのクライアント装置１０からの通信データがデータサーバ装置１のサーバデータ記憶部３に記憶されているサーバデータの更新を要求するものかどうかを判断する（Ｓ１０２）。
【０１０９】
通信データがサーバデータの更新を要求するものであった場合（Ｓ１０２でＹｅｓ）、クライアント記憶データ管理部２は、サーバデータの更新要求の整合性を確認する（Ｓ１０３）。この整合性の確認とは、たとえば、更新を行なおうとするデータへのアクセス権の確認や、更新データのもととなったサーバデータが、この更新データが該クライアント装置１０に転送された時から変更されているなど、複数箇所での編集といったコンフリクトが発生していないか、等の確認を指す。
【０１１０】
整合性の確認がＯＫであった場合（Ｓ１０３でＹｅｓ）、クライアント記憶データ管理部２は、データサーバ装置１のサーバデータ記憶部３に記憶されている該当するサーバデータの更新を行なう。このとき、サーバデータの最終更新日時の更新も同時に行なう（Ｓ１０４）。クライアント記憶データ管理部２は、更新したサーバデータについて、本更新データを送信してきたクライアント装置１０以外のクライアント装置１０への反映処理を行なう（Ｓ１０５）。本処理の詳細については後述する。反映処理（Ｓ１０５）が終了すると、データサーバ装置１は次の通信を待つ処理（Ｓ１０１）に戻る。
【０１１１】
通信データがサーバデータの更新要求で無かった場合（Ｓ１０２でＮｏ）、データサーバ装置１のクライアント記憶データ管理部２は、通信データがクライアント装置１０の接続復帰を知らせるものであるかどうかを判断する（Ｓ１０６）。
【０１１２】
通信データが、クライアント装置１０の接続復帰を知らせるものである場合（Ｓ１０６でＹｅｓ）、クライアント記憶データ管理部２は、該クライアント装置１０に関する端末通信キューの有無を調べ（Ｓ１０７）、端末通信キューが存在した場合には（Ｓ１０７でＹｅｓ）、その内容に従い、通信部４により該クライアント装置１０のクライアントデータ記憶部１２に記憶されているクライアントデータを更新する通信を行ない（Ｓ１０８）、次の通信を待つ処理に戻る（Ｓ１０１）。また、該クライアント装置１０への端末通信キューが空である場合は（Ｓ１０７でＮｏ）、何も処理を行なわずに、次の通信を待つ処理に戻る（Ｓ１０１）。
【０１１３】
クライアント装置１０からの通信データが更新要求であり、かつ整合性がとれなかった場合（Ｓ１０２でＹｅｓ，Ｓ１０３でＮｏ）や、該通信データがデータ更新要求でも接続復帰でも無かった場合（Ｓ１０２でＮｏ，Ｓ１０６でＮｏ）については、適宜例外処理（Ｓ１０９）を行なう。なお、例外処理とは、たとえば整合性の確認に失敗した場合には、その理由を該クライアント装置１０へ送付し、事後の処理をユーザに問い合わせる処理や、または、通信データがデータ更新でも接続復帰でもない、たとえば新しいクライアント装置１０のユーザ登録を依頼する通信であったりする場合のユーザ登録処理などを指す。
【０１１４】
図６を参照して、上述の更新データを送信してきたクライアント装置１０以外のクライアント装置１０への反映処理（Ｓ１０５）についてさらに詳細に説明する。
【０１１５】
クライアント装置１０から送信され、データサーバ装置１により受信された更新データが、スケジュールデータやアルバムデータなど、特殊な通信処理を含まない一般データであった場合（ＳＡ０１でＹｅｓ）、データサーバ装置１のクライアント記憶データ管理部２は、一般データの更新処理を行なう（ＳＡ０２）。なお、本一般データの更新処理の詳細については後述する。
【０１１６】
該更新データがメールデータであった場合（ＳＡ０１でＮｏ，ＳＡ０３でＹｅｓ）、メールデータの更新処理を行なう（ＳＡ０４）。メールデータの更新処理においては、更新データ中に含まれていた宛先情報より、メールデータを配布すべきクライアント装置１０を一台または複数台特定する。それぞれのクライアント装置１０のクライアントデータ記憶部１２に対して新規メールデータとして該メールデータを保存するように、通信部４より更新データを送信する。また、メールデータを送信したクライアント装置１０のユーザが所有するクライアント装置１０が複数台存在した場合には、それらのクライアント装置１０に対しても、該メールデータが送信済みメールとして登録されるように更新データを送信する（ＳＡ０４）。なお、該メールデータの宛先として更新データを受信したクライアント装置１０は、該データを新規メールとしてユーザへ通知する処理を行なう。
【０１１７】
次に、該更新データがチャットデータであった場合（ＳＡ０１でＮｏ，ＳＡ０３でＮｏ，ＳＡ０５でＹｅｓ）、チャットデータの更新処理を行なう。チャットデータの更新処理においては、更新データ中に含まれていたチャットメンバーの情報より、配布すべきクライアント装置１０を一台または複数台特定する。それぞれのクライアント装置１０のクライアントデータ記憶部１２に対して新規チャットデータとして該チャットデータを保存するように、通信部４より更新データを送信する（ＳＡ０６）。なお、該チャットデータを受信したクライアント装置１０においては、該チャットデータをチャット画面に表示する処理を適宜行なう。
【０１１８】
該更新データがメールデータでもチャットデータでも無かった場合（ＳＡ０１でＮｏ，ＳＡ０３でＮｏ，ＳＡ０５でＮｏ）、該データについて定められた所定の処理を行なうものとする（ＳＡ０７）。
【０１１９】
図７を参照し、上述のクライアント装置１０から送信され、データサーバ装置１により受信された更新データが、一般データであった場合の一般データの更新処理（ＳＡ０２）について、さらに詳細に説明する。
【０１２０】
データサーバ装置１のクライアント記憶データ管理部２は、該更新の発生した一般データが、該更新データを送信したクライアント装置１０以外のクライアント装置１０によって共有されるべきデータであるかどうかを判断する（ＳＢ０１）。共有されるべき他のクライアント装置１０が存在しない場合は（ＳＢ０１でＮｏ）、本処理においては何も実行しない。
【０１２１】
共有されるべき他のクライアント装置１０が存在した場合（ＳＢ０１でＹｅｓ）、クライアント装置１０が複数台あればそのうちの一台を、一台しか存在しなければ該クライアント装置１０をそれぞれ選択する（ＳＢ０２）。次に、選択した該クライアント装置１０に対して、本データ更新の通知が必要であるかどうかの判断を行なう（ＳＢ０３）。本判断は、次のようにして行なわれる。まず、該クライアント装置１０のクライアントデータ記憶部１２に、対応するクライアントデータがその時点において記憶されているかどうかを確認する。対応するクライアントデータが記憶されていなければ、原則として該クライアント装置１０のクライアントデータの更新は必要ないと判断する。ただし、更新データに付与されている重要度が高い場合や、ユーザによる設定の場合にはこの限りではない。次に、該クライアント装置１０のクライアントデータ記憶部１２に、対応するクライアントデータが記憶されていた場合は、原則として該クライアント装置１０のクライアントデータの更新が必要であると判断する。ただし、更新データに付与されている重要度が高い場合や、該クライアント装置１０への通信コストが高い場合などはこの限りではない。なお、ＳＢ０２におけるクライアント装置１０の選択処理において、最後にサーバへの接続があったクライアント装置１０を最初に選択するようにしてもよい。これにより、現在ユーザに使用されている可能性が高いクライアント装置１０へ最も早く通知することが可能になり、利便性が向上する。
【０１２２】
通知の必要性の判断（ＳＢ０３）を終え、通知の必要性がないと判断すると（ＳＢ０３でＮｏ）、共有すべきさらに他のクライアント装置１０がないかどうかの確認処理（ＳＢ１０）へ移る。通知の必要性があると判断すると（ＳＢ０３でＹｅｓ）、該クライアント装置１０へ送信する該更新データについて加工の必要性があるかどうかの判断を行なう（ＳＢ０４）。本判断は、次のようにして行なわれる。まず更新データの内容を表現するために必要となる能力が該クライアント装置１０の表現能力を超えている場合、即ち、８ｂｉｔカラーの表示しか行なえないクライアント装置１０に対して２４ｂｉｔカラーの画像の更新通知である場合や、たとえば所定の値以上の大きなデータである場合には更新内容の概要のみの通知でよいようにユーザが設定していた場合などには、データ加工が必要と判断される。更新データ内容が、ユーザ設定、クライアント装置１０の表現能力、通信路に問題がない場合には、データ加工は必要ないと判断する。データ加工が必要と判断した場合には（ＳＢ０４でＹｅｓ）、通知データの加工を行なった後（ＳＢ０５）、該クライアント装置１０への通信を開始し（ＳＢ０６）、必要ないと判断した場合には（ＳＢ０４でＮｏ）、すぐ該クライアント装置１０への通信を開始する（ＳＢ０６）。
【０１２３】
該クライアント装置１０への通信を開始し、通信路の確立に成功した場合には（ＳＢ０７でＹｅｓ）、該クライアント装置１０へのデータの更新通知を実施し（ＳＢ０８）、通信路の確立に失敗した場合には（ＳＢ０７でＮｏ）、該クライアント装置１０に対する端末通信キューへ本更新通知を追加する処理（ＳＢ０９）を行ない、共有すべきさらに他のクライアント装置１０がないかどうかの確認処理（ＳＢ１０）を行なう。本処理において共有すべき他のクライアント装置１０が残っていた場合には（ＳＢ１０でＹｅｓ）、ＳＢ０２に戻り、まだ更新処理の行なわれていないクライアント装置１０の選択から、順次上述の処理を繰り返す。また、本処理において共有すべき他のクライアント装置１０が残っていなかった場合には（ＳＢ１０でＮｏ）、データサーバ装置１は次の通信が行なわれるのを待つ処理（図５のＳ１０１）へ戻る。なお、本処理においては、端末データの更新の必要があれば、直ちにクライアント装置１０との通信および端末データの更新を試みるようにしたが、もちろん、重要度が低い場合などは、直ちに通信を試みずに、端末通信キューへの追加を行なうのみにとどめるようにしてもよい。
【０１２４】
これらの通信処理においては、悪意を持ったユーザからの不正アクセス等を防止するため、暗号化処理や、端末認証手続きを行なうようにする。なお、以後のデータサーバ装置１とクライアント装置１０の全ての通信において、秘匿性の求められる通信においては、適宜暗号化処理や、認証手続きを行なうものとする。本暗号化および認証手続きについては、公知の技術であるので、ここではその説明は繰返さない。
【０１２５】
図８を参照して、クライアント装置１０の動作の説明を行なう。
クライアント装置１０の制御部１５は、データサーバ装置１よりネットワーク５および通信部１１を経由してデータ更新要求を受信した場合には（Ｓ２０１でＹｅｓ）、データサーバ装置１に起因するクライアント装置１０のクライアントデータ更新処理（Ｓ２０２）を行なう。なお、本処理の詳細については後述する。
【０１２６】
次に、入力部１４により検知されたユーザ操作により、クライアントデータの更新要求が発生した場合には（Ｓ２０１でＮｏ，Ｓ２０３でＹｅｓ）、クライアント装置１０に起因したデータ更新処理を行なう（Ｓ２０４）。なお、本処理の詳細については後述する。
【０１２７】
次に、サーバによるデータ更新も、ユーザ操作によるデータ更新も行なわれず（Ｓ２０１でＮｏ，Ｓ２０３でＮｏ）、定期的、ここでは３０分毎に訪れる通信路チェック時間となり、かつ、サーバ通信キューが存在した場合（Ｓ２０５でＹｅｓ）、サーバへの接続を開始する（Ｓ２０６）。なお、通信路チェック時間ではない場合、または、通信路チェック時間でありかつサーバ通信キューが存在しない場合は（Ｓ２０５でＮｏ）、Ｓ２０１の処理へ戻る。
【０１２８】
Ｓ２０６でサーバへの接続を開始し、通信路の確立に成功した場合（Ｓ２０７でＹｅｓ）には、サーバ通信キューに蓄積されたデータのデータサーバ装置１への送信処理を行なう（Ｓ２０８）。Ｓ２０８の後、または、通信路の確立に失敗した場合には（Ｓ２０７でＮｏ）、Ｓ２０１の処理へ戻る。
【０１２９】
図９を参照して、データサーバ装置１に起因するデータ更新処理（図８のＳ２０２）について説明する。
【０１３０】
データサーバ装置１よりネットワーク５および通信部１１を介して伝達されたデータ更新要求に応じ、制御部１５はクライアント装置１０内のクライアントデータ記憶部１２に記憶されている当該データの更新を行なう（Ｓ３０５）。なお、更新内容が、新データの追加であった場合には、新データの追加をクライアントデータ記憶部１２に行ない、更新データの反映処理を行なう。なお、本処理の詳細については後述する。
【０１３１】
次に、該データの属性により、通知が必要であるかどうかを判断する（Ｓ３０６）。通知が必要である場合（Ｓ３０６でＹｅｓ）、該データを利用するアプリケーションに対して更新の通知を行なう。アプリケーションが動作中でない場合は、必要に応じて該データを利用するアプリケーションや、更新通知用のアプリケーションを立ち上げてから通知を行なうようにしてもよい。また、同時に呼び出し音を鳴らす、アイコンを変更する、など、ユーザへの通知を行なうようにしてもよい（Ｓ３０７）。また、この通知をするに当たり、後述するデータの重要度やデータの種類に応じて、アイコンの変更の程度や通知音のある・なし、大きさなど、ユーザに注意を喚起するレベルを変化させてもよい。また、Ｓ３０６においてたとえば時刻表データのミスの訂正と言った特にユーザへの通知を必要としないような変更については、ユーザへの通知を行なわない。
【０１３２】
次に図１０を参照して、クライアント装置１０に起因するデータ更新処理（図８のＳ２０４）について説明する。
【０１３３】
制御部１５は、入力部１４により更新または新規入力されたデータに基づいて、クライアントデータ記憶部１２の該当データの更新を行なうか、または、クライアントデータ記憶部１２へのデータの新規追加を行なうかして、更新データの反映処理を行なう（Ｓ３０１）。なお、本処理の詳細については後述する。
【０１３４】
制御部１５は、更新されたデータの属性を確認し（Ｓ３０２）、クライアント装置１０固有で記憶すべきデータではなく、データサーバ装置１において管理されているサーバデータの更新が必要かどうかを判断する（Ｓ３０３）。本判断では、たとえばユーザの指定などによりクライアント装置１０固有のデータであればサーバデータの更新が必要ないと判断するが、通常のユーザデータについてはサーバデータの更新を行なうものとする。
【０１３５】
サーバデータの更新が必要である場合（Ｓ３０３でＹｅｓ）、通信部１１およびネットワーク５を介してデータサーバ装置１において管理されているサーバデータの更新が行なわる（Ｓ３０４）。その後、図８のＳ２０１の処理へ戻る。サーバデータの更新が必要でなかった場合には（Ｓ３０３でＮｏ）、Ｓ２０１の処理へ戻る。
【０１３６】
図１１を参照して、クライアント装置１０からのデータサーバ装置１のサーバデータを更新する処理（図１０のＳ３０４）について説明する。
【０１３７】
サーバデータの更新が直ちに必要かどうかを、データの重要度、種類などにより所定のアルゴリズムにより判断する（ＳＣ０１）。
【０１３８】
直ちにサーバデータの更新が必要であると判断すると（ＳＣ０１でＹｅｓ）、クライアント装置１０の制御部１５は通信部１１を介してデータサーバ装置１への通信の開始を行なう（ＳＣ０２）。
【０１３９】
通信路の確立に成功した場合（ＳＣ０３でＹｅｓ）、制御部１５はデータサーバ装置１のサーバデータ記憶部３の対応するデータの更新を行なうよう通知を行なう（ＳＣ０４）。
【０１４０】
直ちにサーバデータの更新が必要でないと判断された場合（ＳＣ０１でＮｏ）、または、通信路の確立に失敗した場合（ＳＣ０３でＮｏ）、制御部１５はサーバ通信キューへ、本更新処理要求を追加する（ＳＣ０５）。なお、本サーバ通信キューは通常、上述のＳ２０８においていずれ処理される。この処理により、たとえば直ちにサーバデータの更新が必要でないようなデータの更新の際には、連続して複数回の編集を行なったとしても、その都度サーバデータの更新が行なわれてたとえば通信料の課金が増大するといった問題が回避できる。
【０１４１】
また、これらの通信において、悪意を持ったユーザからの不正アクセス等を防止するため、暗号化処理や、ユーザ認証手続きを行なうようにする。
【０１４２】
次に、本実施例における実際の動作の様子について、データの状態や手順を示して詳細に説明する。また、以降クライアント装置のことを単に「端末」と記すことがある。
【０１４３】
図１２に、本実施例におけるデータサーバ装置１のサーバデータ記憶部３において記憶されているサーバデータと複数のクライアント装置１０のクライアントデータ記憶部１２において記憶されているクライアントデータとの関係の一例を概念的に示す。
【０１４４】
本実施例において、本システムの利用者は「鈴木太郎」、「鈴木花子」および「田中次郎」の３名であるものとする。「鈴木太郎」と「鈴木花子」とは婚姻関係にあり、両者はデータサーバ装置１において管理されている、「鈴木家」と言うグループ２２０に所属するものとする。「鈴木太郎」と、「田中次郎」との両名は、同様にデータサーバ装置１において管理されているスキー同好会グループ２２１に所属しているものとする。
【０１４５】
また、「鈴木太郎」はクライアント装置である、端末Ａ２０６および端末Ｂ２０７を所持し、「鈴木花子」は端末Ｃ２０８および端末Ｄ２０９を所持し、「田中次郎」は端末Ｅ２１０および端末Ｆ２１１を所持しているものとする。
【０１４６】
この場合、データサーバ装置１のサーバデータ記憶部３においては、データ集合として、鈴木花子個人データ２０１、鈴木太郎個人データ２０２、鈴木家データ２０３、スキー同好会グループデータ２０４および田中次郎個人データ２０５のサーバデータが管理されているものとする。図１２において、データサーバ装置１内のサーバデータのグループとそれぞれのクライアント装置１０内のクライアントデータとは、直線により結ばれたような対応関係になっているものとする。
【０１４７】
たとえば、「鈴木太郎」の所持している端末Ａ２０６のクライアントデータ記憶部１２には、データサーバ装置１にサーバデータとして管理されている、鈴木太郎個人データ２０２、鈴木家データ２０３およびスキー同好会グループデータ２０４の、それぞれのサーバデータの一部が記憶されているものとする。
【０１４８】
図１３に、データサーバ装置１のサーバデータ記憶部３において記憶されているサーバデータのデータ記憶形式の一例を示す。なお、この例は図１２に示した、各ユーザ、端末、グループの関係にしたがっている。
【０１４９】
本実施例では、各クライアント装置１０において、個人の予定やグループの予定を管理することができるスケジュールアプリケーション、知人友人の電話番号や住所を管理することができる住所録アプリケーション、電子メールの送受信を行ない、受信メールや送信メールを管理することができるメールアプリケーション、写真データや動画データを管理することができるアルバムアプリケーション、文字ベースなどでリアルタイムに画面上で所定のメンバー間での会話を実現することができるチャットアプリケーション、および天気予報やニュース速報などを適宜入手し、管理することができるニュースアプリケーションなどが実装されているものとする。各クライアント装置１０から参照されるサーバデータは、図１３に示したような形式にて記憶されているものとする。
【０１５０】
また、図１３におけるそれぞれの行のデータ単位を以降「データエントリ」と表現する。各データエントリには、各データエントリのデータ内容３０１、それぞれのデータエントリを扱うアプリケーションを示すアプリケーション属性３０２、それぞれのデータエントリの所属するグループを示す所属グループ属性３０３、それぞれのデータエントリを使用する端末を示す使用端末属性３０４、それぞれのデータエントリを現在記憶中である端末を示す記憶中端末属性３０５、およびそれぞれのデータエントリの重要度を示す重要度属性３０６などの属性があるものとする。データエントリは、それぞれのデータエントリの属性に基づいて、たとえば同じ属性の値を持つデータエントリは、同じカテゴリに分類される。所属グループ属性３０３については、後述の図１５のテーブルにより必ずしも各データの属性として付与される必要はないと考えられるが、本実施例では分かりやすいよう付与している。使用端末属性３０４については、後述の図１４及び図１５のテーブルにより導き出すことができるため、必ずしも各データの属性として付与される必要はないと考えられるが、本実施例では分かりやすいよう付与している。
【０１５１】
図１４を参照して、データサーバ装置１のクライアント記憶データ管理部２において管理されている、各端末の属性を記憶するデータ形式の一例を示す。
【０１５２】
データサーバ装置１のクライアント記憶データ管理部２は、図１４に示すように、それぞれの端末毎に、端末を所持しているユーザを示すユーザ属性４０１、端末がＰＣ（Personal Computer）なのか、ＰＤＡなのか、携帯電話なのかなど、どのような種別であるかを示す種別属性４０２、ユーザは端末をどういった用途で所持しているのかを示す用途属性４０３、音声出力の可否や、映像表示能力など、端末がどのような表現能力を持っているかを示す表現能力属性４０４、および通信路として無線の通信路を利用しているのか、有線の通信路を利用しているのか、通信速度は高速なのか低速なのか、また、通信路は従量課金となっているのか、固定課金となっているのかを示す、通信路属性４０５などの属性を管理するテーブルを記憶している。
【０１５３】
本テーブルにより、本実施例では、端末Ａは、「鈴木太郎」に所有されている従量課金の高速無線通信機能を持ったパーソナル用途の携帯電話であり、表現能力としては、音声出力が可能、ＶＧＡ（Video Graphics Array）の表示能力を持つことが分かる。同様に、端末Ｂは、「鈴木太郎」に所有されている従量課金の低速無線通信機能を持ったビジネス用途のＰＤＡであり、表現能力としては、音声出力が不可、ＶＧＡの表示能力を持つことが分かる。端末Ｃは、「鈴木花子」に所有されている固定課金の高速有線通信機能を持ったパーソナル用途のデスクトップＰＣであり、表現能力としては、音声出力が可能、ＳＸＧＡ（SupereXtended Graphics Array）の表示能力を持つことが分かる。端末Ｄは、「鈴木花子」に所有されている従量課金の高速無線通信機能を持ったパーソナル用途の携帯電話であり、表現能力としては、音声出力が可能、テキストの表示のみが可能な表示能力を持つことが分かる。端末Ｅは、「田中次郎」に所有されている従量課金の高速無線通信機能を持ったパーソナル用途の携帯電話であり、音声出力が可能、ＶＧＡの表示能力を持つことが分かる。端末Ｆは、「田中次郎」に所有されている従量課金の低速無線通信機能を持ったビジネス用途のＰＤＡであり、音声出力が可能、ＶＧＡの表示能力を持つことが分かる。
【０１５４】
図１５に、データサーバ装置１のサーバデータ記憶部３において記憶されているグループデータのデータ記憶形式の一例を示す。なお、この例は図１２に示した、各ユーザ、端末、グループの関係にしたがっている。図１５に示すように、それぞれのグループ毎に、グループに属しているユーザを示すユーザ属性４０６を対応づけるテーブルを記憶している。
【０１５５】
本テーブルにより、“鈴木家”のグループには、「鈴木太郎」および「鈴木花子」が属していることが分かる。同様に、“スキー同好会”のグループには、「鈴木太郎」および「田中次郎」が、“鈴木太郎個人”には、「鈴木太郎」が、“鈴木花子個人”には「鈴木花子」が、“田中次郎個人”には「田中次郎」が属していることが分かるようになっている。
【０１５６】
図１４および図１５に示したテーブルは、各データの所属グループから、それぞれのデータがどの端末からアクセスされるか、すなわち、それぞれのデータエントリを所有する端末を示す使用端末属性（図１３の３０４）を判断することにも使用される。
【０１５７】
図１６にクライアント装置１０より、データサーバ装置１のサーバデータ記憶部３に記憶されているサーバデータを更新するために送信される、サーバデータ更新通知のフォーマットを示す。
【０１５８】
上述の図１１のＳＣ０４におけるデータサーバ装置１への更新通知処理においては、本フォーマットのデータが使用されるものとする。
【０１５９】
本フォーマットには、送信元のクライアント装置を識別するための端末ＩＤ（IDentification）Ｄ０１、データサイズＤ０２、データ内容Ｄ０３、データを利用するアプリケーションＤ０４、データの所属する所属グループＤ０５、データの重要度Ｄ０６、該当データのデータサーバ装置１における最終更新日時Ｄ０７（すなわち、該当データをデータサーバ装置１からクライアント装置１０へ最後に取り込んだ時点、または、該当データをクライアント装置１０からデータサーバ装置１へ最後に登録した時点での、データサーバ装置１における更新日時）、該当データのクライアント装置１０における最終更新日時Ｄ０８、および、該データがデータサーバ装置１のサーバデータ記憶部３への新規登録なのか、それとも、すでにサーバデータ記憶部３に記憶されているデータの更新なのかを示す、登録種別Ｄ０９を含む。
【０１６０】
なお、フォーマットには、ここに記載された情報以外の情報を適宜含むようにしてもよく、また、逆にここに記載されたすべてのフィールドが必須であるとは限らない。
【０１６１】
データサーバ装置１より、クライアント装置１０へのデータ更新通知についてもほぼ同様のデータフォーマットを用いることができる。
【０１６２】
次に、本システムにおける各サービスの動作を説明する。
図１７を参照して、住所録データの「田中次郎」のデータエントリが更新された場合についての説明を行なう。
【０１６３】
まず、「田中次郎」がパーソナル用途で使用している携帯電話のクライアント装置１０である端末Ｅにおいて、自分の住所データの更新を行なったとする。端末Ｅは、まず、該クライアント装置１０内のクライアントデータ記憶部１２に記憶されているデータサーバ装置１のサーバデータ記憶部３に記憶されているサーバデータのコピーである「田中次郎」の住所データが収められたエントリを、「田中次郎」の操作内容にしたがって変更する。次に、端末Ｅの制御部１５は、通信部１１により、ネットワーク５を介し、データサーバ装置１へ接続し、データサーバ装置１のサーバデータ記憶部３に記憶されている「田中次郎」の住所のサーバデータの更新要求を行なう（Ｓ５０１）。
【０１６４】
端末Ｅより、「田中次郎」の住所データの更新要求を受けたデータサーバ装置１のクライアント記憶データ管理部２は、サーバデータ記憶部３に記憶されているサーバデータの「田中次郎」の住所データのエントリの更新を行なうとともに、図１３に示されたテーブルより、該田中次郎の住所録のデータエントリを使用する端末は、Ａ，Ｂ，Ｅ，Ｆの４台、該データエントリを記憶中の端末は、端末Ａ，Ｅ，Ｆの３台であることを判断し、端末Ｅからの更新要求であるため、データ更新を行なうべき端末は、Ａ，Ｆの２台であると判断する。
【０１６５】
したがって、データサーバ装置１のクライアント記憶データ管理部２は、通信部４により、ネットワーク５を介して、端末Ａおよび端末Ｆのクライアントデータ記憶部１２に記憶されている、「田中次郎」の住所録のデータエントリを更新する旨の通信を行なう（Ｓ５０２，Ｓ５０３）。これにより、端末Ａおよび端末Ｆにおいては、更新された「田中次郎」の住所録データが参照可能となる。また、端末Ｂについては、該データエントリを使用する端末であるが、該データエントリを記憶中でないために、データ更新の手続きは行なわない（Ｓ５０４）。
【０１６６】
この後、端末Ｂにおいて、住所録アプリケーションが起動され、「田中次郎」の住所録へのアクセスがあると、端末Ｂの制御部１５は、クライアントデータ記憶部１２に「田中次郎」の住所録データがないため、通信部１１により、ネットワーク５を介して、データサーバ装置１のサーバデータ記憶部３に記憶されているサーバデータを要求する（Ｓ５０５）。端末Ｂより、「田中次郎」の住所録のサーバデータの要求を受けたデータサーバ装置１は、サーバデータ記憶部３に記憶されている更新済みの「田中次郎」の住所録データを読出し、通信部４により、ネットワーク５を介して、端末Ｂへ該住所録データを送付する（Ｓ５０６）。
【０１６７】
さらに、「田中次郎」が２度目の住所データの更新を端末Ｅにおいて行なった場合、上述同様の処理により、データサーバ装置１のサーバデータの更新要求を行なう（Ｓ５０７）。データの更新要求を受けたデータサーバ装置１は、該データエントリを記憶中の端末は、端末Ａ，Ｂ，Ｅ，Ｆの４台であることを判断し、端末Ｅからの更新要求であるため、データ更新を行なうべき端末は、Ａ，Ｂ，Ｆの３台であると判断する。したがって、データサーバ装置１のクライアント記憶データ管理部２は、通信部４により、ネットワーク５を介して、端末Ａ，Ｂ，Ｆのクライアントデータ記憶部１２に記憶されている、「田中次郎」の住所録のデータエントリを更新する旨の通信を行なう（Ｓ５０８）。
【０１６８】
以上の手続きにより、端末Ｂにおける「田中次郎」の住所録データの更新がデータサーバ装置１のサーバデータ記憶部３に反映された後は、他の「田中次郎」の住所録データを参照できるどの端末においても、正しく更新されたデータを共有することが可能となる。
【０１６９】
図１８〜図２３を参照して、図１７に示した本システムにおけるデータの更新処理におけるデータサーバ装置１におけるデータの変化について説明する。
【０１７０】
図１８は、図１７における「田中次郎」の住所録データ変更処理を開始する前のデータサーバ装置１におけるサーバデータ状態の例である。この時点では端末Ａ，Ｂ，Ｆの３台に、データサーバ装置１に「田中次郎」の第１回目の変更処理の前の時点での住所データが記憶されており、端末Ｂについては、「田中次郎」のデータを長らく使用していなかったため、端末Ｂの記憶装置からは削除されていたものとする。
【０１７１】
サーバデータは図１８に示したように、データ内容４２１とともに、それぞれの端末４２２について、その端末において該データを取り扱うのに使用するアプリケーションを示すアプリケーション属性４２３、その端末における該データの重要度を示す重要度属性４２４、その端末のクライアントデータ記憶部１２に記憶されている対応データが該サーバデータ４２１と同期済みであるかどうかを示す同期属性４２５、およびその端末が現在該データを記憶中であるかどうかを示す記憶中属性４２６を含む。
【０１７２】
上述のように、図１８では、端末Ａ，Ｅ，Ｆにおいては、記憶中属性４２６が「Ｙｅｓ」になっており、また、同期属性４２５も「済」になっている。なお、該データを記憶中でない端末Ｂについては、記憶中属性４２６が「Ｎｏ」となり、記憶中でないため、同期属性４２５はなし（「−」）となっている。
【０１７３】
図１９に「田中次郎」が端末Ｅにおいて住所録データ変更処理を行なったことにより、端末Ｅよりデータサーバ装置１へ更新通知があり（Ｓ５０１）、データサーバ装置１のサーバデータ記憶部３に記憶されている田中次郎住所録データのサーバデータが更新された直後のサーバデータの状態を示す。
【０１７４】
本時点において、端末Ｅと、データサーバ装置１のサーバデータ記憶部３に記憶された「田中次郎」の住所録データは一致しているため、端末Ｅに関する記憶中属性は「Ｙｅｓ」であり、同期属性は「済」となる。記憶中属性が「Ｙｅｓ」であるそれ以外の端末Ａおよび端末Ｆに関しては、同期属性は「未」となるため、図１９に示したような状態となる。
【０１７５】
次に、図２０に「田中次郎」の１回目の住所変更処理がデータサーバ装置１のサーバデータ記憶部３に反映された図１９の時点から、たとえば５分経過した時点での、データサーバ装置１のサーバデータの状態を示す。
【０１７６】
本時点においては、図１９の時点で同期属性が「未」であった端末Ａおよび端末Ｆに対して、データ更新通知処理（Ｓ５０３，Ｓ５０４）が終了しているため、これらの同期属性が「済」に変更され、図２０に示したような状態となる。
【０１７７】
次に、図２１に「田中次郎」の１回目の住所変更処理がデータサーバ装置１のサーバデータ記憶部３に反映された図１９の時点から、たとえば５時間経過した時点でのデータサーバ装置１のサーバデータの状態を示す。
【０１７８】
本時点においては、図２０の時点の後、端末Ｂにおいて住所録アプリケーションが起動され、「田中次郎」の住所録データへのアクセスがあったため、端末Ｂよりデータサーバ装置１へデータの要求が発生し（Ｓ５０５）、要求に応じてデータサーバ装置１より「田中次郎」の住所録データが端末Ｂへ転送されている（Ｓ５０６）。
【０１７９】
本時点においては、データサーバ装置のサーバデータは、図２０の時点で記憶中属性が「Ｎｏ」であった端末Ｂの記憶中属性が「Ｙｅｓ」になるとともに、同期属性が「済」に変更され、図２１に示したような状態となる。
【０１８０】
次に、図２２に「田中次郎」が端末Ｅにおいて２回目の住所録データ変更処理を行なったことにより、端末Ｅよりデータサーバ装置１へ更新通知があり（Ｓ５０７）、データサーバ装置１のサーバデータ記憶部３に記憶されている田中次郎住所録データのサーバデータが再度更新された直後のサーバデータの状態を示す。
【０１８１】
本時点において、図１９と同様、端末Ｅと、データサーバ装置１のサーバデータ記憶部３に記憶された「田中次郎」の住所録データとは一致しているため、端末Ｅに関する記憶中属性は「Ｙｅｓ」であり、同期属性は「済」となる。記憶中属性が「Ｙｅｓ」であるそれ以外の端末Ａ、端末Ｂ、および端末Ｆに関しては、同期属性は「未」となるため、図２２に示したような状態となる。
【０１８２】
次に、図２３に「田中次郎」の２回目の住所変更処理がデータサーバ装置１のサーバデータ記憶部３に反映された図２２の時点から、たとえば５分経過した時点での、データサーバ装置１のサーバデータの状態を示す。
【０１８３】
本時点においては、図２２の時点で同期属性が「未」であった端末Ａ、端末Ｂ、および端末Ｆに対して、データ更新通知処理（Ｓ５０８）が終了している。このため、これらの同期属性が「済」に変更され、図２３に示したような状態となる。
【０１８４】
図２４を参照して、本システムにおいてアルバムの新規入力を行なった場合の処理の流れを示す。
【０１８５】
まず、「鈴木太郎」に所有されているパーソナル用途の携帯電話である端末Ａにより、「鈴木家」の家族旅行の写真が、鈴木家データ２０３にアルバムとして新規入力された場合の説明を行なう。
【０１８６】
所属グループとして“鈴木家”、アプリケーションとして“アルバム”という属性が付加された鈴木家旅行アルバムが端末Ａにおいて新規入力されると、端末Ａの制御部１５は、入力されたアルバムデータをクライアントデータ記憶部１２に記憶する。それとともに、制御部１５は、通信部１１により、ネットワーク５を介して、データサーバ装置１へ接続し、データサーバ装置１中のサーバデータ記憶部３に、入力された新規アルバムデータをサーバデータとして新規登録する（Ｓ５１１）。
【０１８７】
端末Ａへのアルバムデータは、たとえば、デジタルカメラより、赤外線や近距離無線通信により端末Ａへ伝送することにより得られたものであってもよく、または、端末Ａにデジタルカメラの機能が内蔵されており、該カメラ機能により撮影されたものであってもよい。
【０１８８】
新規アルバムデータの登録を受けたデータサーバ装置１のクライアント記憶データ管理部２は、該新規アルバムデータを転送すべき端末があるかどうかを次のようにして判断する。
【０１８９】
まず、該アルバムデータの属性より、所属グループが「鈴木家」であることを判断し、次に図１５に示したグループデータのテーブルより、「鈴木家」には、「鈴木太郎」および「鈴木花子」が属していることを判断する。次に図１４に示した各端末の属性のテーブルより、「鈴木太郎」および「鈴木花子」の所有する端末が、端末Ａ，Ｂ，ＣおよびＤの４台であることを判断する。
【０１９０】
また、端末Ａに関しては、新規アルバムデータの作成元であることが分かっている。このため、端末Ａに対して新規アルバムデータを転送する必要はないと判断される。
【０１９１】
端末Ｃに関しては、デスクトップＰＣであることが判断でき、固定課金の高速有線接続で記憶領域がふんだんにあることより、転送を試みるが、このとき、端末Ｃの電源が切られている、または、通信路が障害により不通となっており（Ｓ５１２）、端末Ｃのクライアントデータの更新は断念する（Ｓ５１３）。
【０１９２】
端末Ｄに関しては、図１４に示したテーブルより、テキスト表示のみの表示能力しか持たないことが分かっている。このため、写真データである該新規アルバムデータを転送する必要はないと判断する（Ｓ５１４）。または、端末Ｄに対して新規アルバムデータがデータサーバ装置１上に登録された旨の通知を行なってもよい。
【０１９３】
端末Ｂに関しては、図１４より、ＰＤＡであることが分かり、また、低速の無線回線が従量課金となっている。このことより、該新規アルバムデータそのもの転送は行なわず、新規アルバムデータがデータサーバ装置１のサーバデータ記憶部のサーバデータに追加されたことの通知のみを行なう（Ｓ５１５）。
【０１９４】
「鈴木花子」が端末Ｃの電源を入れる、または、ネットワーク障害が解消し通信路が開通すると、端末Ｃの制御部１５は、通信部１１により、ネットワーク５を介してデータサーバ装置１へ、端末装置Ｃのクライアントデータ記憶部１２内に記憶されているクライアントデータに更新が必要なデータが存在するか否かを問い合わせる（Ｓ５１６）。データサーバ装置１は、該問い合わせに応じ、該新規アルバムデータの転送を行なう（Ｓ５１７）。新規アルバムデータの転送を受けた端末Ｃの制御部１５は、該新規アルバムデータをクライアントデータ記憶部１２に記憶させる。
【０１９５】
なお、ここでは、電源投入後に端末Ｃの電源投入後に更新が必要なデータの存在の有無の問い合わせを行なうようにしたが、逆に、端末Ｃからは問い合わせを行なわず、データサーバ装置１より定期的に更新処理を試みるようにしてもよい。この場合、たとえば更新されたデータが重要度の高いデータであれば、定期的に更新処理を試みる周期を短くするなどの処理も有用である。
【０１９６】
また、ここでは、端末Ｂは従量課金の無線回線であるため、新規データ追加の通知のみを行なうようになっているが、これもたとえば重要度が高く設定されたアルバムデータであれば画像データの転送を行なうようにしたり、重要度に応じて更新処理を変更したりすることも有用である。
【０１９７】
次に「鈴木太郎」が端末Ｂにおいて、アルバムデータへの参照を要求すると（Ｓ５１８）、データサーバ装置１のクライアント記憶データ管理部２は、通信部４により、ネットワーク５を介して、クライアント装置１０の一台である、端末装置Ｂへ、該新規アルバムデータの転送を行なう（Ｓ５１９）。
【０１９８】
以上の手続きにより、一台のクライアント装置１０において追加されたグループデータを、自動的にそのデータを共有すべきその他のクライアント装置１０のクライアントデータ記憶部１２に配布することが実現される。
【０１９９】
図２５を参照して、本システムにおいてメール送付を行なった場合の処理の流れについて説明する。ここでは、「鈴木太郎」に所有されているパーソナル用途の携帯電話である端末Ａにより、「鈴木家」および「スキー同好会」へ新規メールの送付を行なった場合について説明する。
【０２００】
端末Ａにおいて、「鈴木家」および「スキー同好会」へ新規メールの送付を行なうと、端末Ａの制御部１５は、まず、端末Ａのクライアントデータ記憶部１２に、メールデータとして、該新規メールを記憶するとともに、通信部１１により、ネットワーク５を介して、データサーバ装置１へ接続し、データサーバ装置１中のサーバデータ記憶部３に、入力された新規メールデータをサーバデータとして新規登録する（Ｓ５２０）。
【０２０１】
新規メールデータの登録を受けたデータサーバ装置１のクライアント記憶データ管理部２は、登録されたメールデータの宛先フィールドにより、転送すべき端末の特定を行なう。
【０２０２】
ここでは、宛先フィールドに、「鈴木花子」および「スキー同好会」が指定されているため、データサーバ装置１のクライアント記憶データ管理部２は、「鈴木花子」および「スキー同好会」のメンバーの所有するすべての端末のクライアントデータ記憶部１２に新規メールデータを送付する。該当する端末は、図１４および図１５のテーブルより、端末Ａ、Ｂ、Ｃ、Ｄ、ＥおよびＦの６台である。端末Ａに関しては、該新規メールの送信元であるため、データサーバ装置１のクライアント記憶データ管理部２は、端末Ｂ、Ｃ、Ｄ、ＥおよびＦの５台のクライアント装置１０を該新規メールの送付先として判断する。クライアント記憶データ管理部２は、通信部４により、ネットワーク５を介して、端末Ｂ、Ｃ、Ｄ、ＥおよびＦのそれぞれの端末へ接続し、それぞれの端末のクライアントデータ記憶部１２に登録するための該新規メールデータを転送する（Ｓ５２１）。
【０２０３】
該新規メールデータをクライアントデータ記憶部１２に登録した各クライアント装置１０の制御部１５は、新規登録されたデータのアプリケーション属性がメールであることより、メール用のユーザインターフェースにより新規メールが着信したことの表示を行なう。
【０２０４】
端末Ｂに関しては、同じ「鈴木太郎」の保有する端末であるため、送信済みメールとしてクライアントデータ記憶部１２に登録すべく、該新規メールデータを転送する（Ｓ５２２）。
【０２０５】
「鈴木花子」の所有する端末Ｃおいて、該新規メールの開封処理が行なわれると、端末Ｃの制御部１５は、クライアントデータ記憶部１２の該新規メールデータへの読出しアクセスの検出、または、メールアプリケーションからの通知により、該新規メールの開封処理を認識し、データサーバ装置１へ、該新規メールデータの開封処理の通知を行なう（Ｓ５２３）。端末Ｃにおける該新規メールデータの開封処理の通知を受けたデータサーバ装置１のクライアント記憶データ管理部２は、図１４のテーブルにより、同じユーザに所有される他の端末が端末Ｄであることを判断する。端末Ｃおよび端末Ｄのユーザは同一人物（鈴木花子）である。このため、本実施例では、データサーバ装置１のクライアント記憶データ管理部２は、通信部４によりネットワーク５を介し、端末Ｄに対して、既読通知を試みる（Ｓ５２４）。このとき端末Ｄはビルの中など、通信不可能な状況にあったとする（Ｓ５２５）。
【０２０６】
端末Ｄが、屋外へでるなどして、通信可能な状態となると、端末Ｄの制御部１５は、通信部１１により、ネットワーク５を介して、データサーバ装置１へ接続し、サーバデータの更新がないかどうかを確認する（Ｓ５２６）。この端末Ｄからの更新データの確認に応じて、データサーバ装置１は、端末Ｄへ該新規メールの既読通知を行なう（Ｓ５２７）。
【０２０７】
なお、ここでは、通信可能な状態となると端末Ｄよりデータサーバ装置１へサーバデータの更新の有無を問い合わせるようにしたが、逆に、端末Ｄからは問い合わせを行なわず、データサーバ装置１より、定期的にデータ更新の通知を試みるようにしてもよい。
【０２０８】
データサーバ装置１より、既読通知を受け取った端末Ｄは、該新規メールの属性を既読に変更する。
【０２０９】
以上の処理により、それぞれのクライアント装置１０でのメールアプリケーションが、メールデータをそれぞれのクライアント装置１０のクライアントデータ記憶部１２に対して所定の属性を付加して記憶することにより、メールシステムを実現することが可能となる。
【０２１０】
また、端末Ｃにて一度読んだメールが、再度端末Ｄにおいて新規メールとして取り扱われてしまい、「鈴木花子」が同じメールを２度新規メールとして読まされてしまうと言う問題の発生を回避できる。
【０２１１】
なお、上述のメールの既読、未読などの属性は、データサーバ装置１のサーバデータ記憶部３におけるサーバデータの該メールエントリに対し、複数のユーザ毎、端末毎に属性を設定し、その属性を、各通信において各端末へ反映するようにしてもよい。または、各端末毎に、サーバデータにおける該メールエントリをコピーし、それぞれの属性を管理するようにしてもよい。
【０２１２】
図２６〜図３１を参照して、本メール処理におけるデータサーバ装置１のサーバデータ記憶部３に記憶されている該メールデータに対応するサーバデータの遷移の様子を時間順に説明する。
【０２１３】
図２６は、端末Ａにおいて、新規メールを作成している途中での状態を示したものである。作成中のメール４５１はメールアプリケーションにおいてサーバデータ記憶部３内の下書きフォルダに保存されている。このため、下書きフォルダというフォルダ属性４５３が付与されている。また、ここでは、未読／既読属性４５４については、作成中の下書き状態のメールデータには「未読」という属性が付与されているものとする。また、ここではユーザにより本メールの重要度４５５は「４」という値に設定されているものとする。これらの属性が、それぞれの端末４５２毎に同期属性４５６およびそれぞれの端末に該メールデータが記憶中かどうかを示す記憶情報４５７とともに記憶されている。
【０２１４】
作成中のメールデータは、同じユーザ（鈴木太郎）が記憶する端末Ｂからも共有される。このため、端末Ｂについても同様の情報が管理される。ここでは、メールデータの作成中においては、端末Ｂのクライアントデータ記憶部１２への同期はしない。このため、同期情報は、端末Ａに関しては同期済みであるのに対し、端末Ｂに関しては未同期となっている。もちろん、この状態で端末Ｂより続きの編集をした場合には、端末Ｂのクライアントデータ記憶部１２に作成途中の該メールデータを記憶することとなる。
【０２１５】
図２７は、新規メールの執筆を完了し、新規メールの送信を行なっている途中の状態を示す。本時点においては、メールの執筆者は該メールを読んでいる。このため、メールの執筆者（鈴木太郎）の所有する端末Ａにおいては、未読／既読属性は「既読」となっており、その他の端末Ｃ、Ｄ、ＥおよびＦにおいては、いずれも開封処理をしていないため「未読」となっている。また、本時点においては、本メールデータを端末Ｄおよび端末Ｅのクライアントデータ記憶部１２で同期済みであり、端末Ｃおよび端末Ｆのクライアントデータ記憶部１２では、まだ同期処理が完了していない。また、端末Ａに関しては、フォルダ属性が「送信中」となっている。端末Ｂは、送信中においては、本データの同期処理を行なわないものとする。このため、「未読」の属性が付与されている。
【０２１６】
図２８は、新規メールの全ての配布先端末への同期が完了した時点での状態を示す。本時点において、メール発信者（鈴木太郎）の端末Ａおよび端末Ｂにおいては、「送信済み」のフォルダ属性が付与され、メールを執筆した本人なので「既読」の属性が付与されている。また、本時点において残りの端末については、該メールを開封したユーザがいないものとする。このため、すべて未読の属性が付与されている。
【０２１７】
図２９は、端末Ｃにおいて、本メールの開封処理が行なわれ、端末Ｃより本メールのデータ更新通知があった直後の状態を示す。
【０２１８】
本時点では、端末Ｃからの更新通知に応じて、端末Ｃの未読／既読属性を「既読」にするとともに、端末Ｄにおける未読／既読属性も同時に「既読」に変更する。また、端末Ｄに対する未読／既読属性の同期は本時点では完了していない。
【０２１９】
次に図３０に、図２９の時点からしばらく後の時点の状態を示す。本時点では、端末Ｄにおける未読／既読属性の同期が完了している。
【０２２０】
さらに図３１に、図３０の時点から数日経過した時点での状態を示す。本時点では、端末Ｄおよび端末Ｆにおいて、該メールの情報がしばらく使用されず、また、他のデータをデータサーバ装置１よりダウンロードするために、該メール情報がクライアントデータ記憶部１２より削除されている状態を示す。
【０２２１】
以上の処理により、各クライアント装置１０のメールアプリケーションは、メールデータを作成することにより、それぞれのクライアントデータ記憶部１２に対してメール送信が可能となる。
【０２２２】
なお、上述の処理では、他の上記クライアント装置に対してのみメール送信が可能となるが、たとえば、メールの宛先に従来のインターネットメールのアドレスが指定されていた場合には、データサーバ装置１において、メールデータのＴｏフィールドの宛先データを用い、ＳＭＴＰ（Simple Mail Transfer Protocol）に従い、従来のインターネットメールと同様にメールデータを送出するようにしてもよい。このようにすることにより、従来のインターネットメールとの互換性を保つことも容易である。
【０２２３】
図３２を参照して、本システムにおいてチャットを行なった場合の処理の流れについて説明する。ここでは、まず、「鈴木太郎」が端末Ａより「田中次郎」に対してチャットを開始し、その後、同じく「鈴木太郎」が「鈴木花子」をチャット対象に追加した場合の説明を行なう。
【０２２４】
「鈴木太郎」が端末Ａにおいてチャットアプリケーションを用いて、「田中次郎」に対してチャットを開始する。チャットアプリケーションは、端末Ａの制御部１５において実行されており、入力部１４より、「田中次郎」に対するチャットの開始を行なうような操作が検出されると、クライアントデータ記憶部１２にチャットデータとしてチャット内容のファイルを作成、保存する。このとき、本チャットデータは、「鈴木太郎」から「田中次郎」に対してのものであるため、データの所属グループに属する人物は、「田中次郎」および「鈴木太郎」の２名となる。
【０２２５】
端末装置Ｃの制御部１５は、クライアントデータ記憶部１２に新しく作成されたデータのアプリケーション属性が、チャットであることにより、すぐに通信部１１より、ネットワーク５を介して、データサーバ装置１へチャットデータを通知する（Ｓ５３０）。
【０２２６】
通知を受けたデータサーバ装置１のクライアント記憶データ管理部２は、サーバデータ記憶部３に、受信したチャットデータを記憶する。また、本データのアプリケーション属性が「チャット」であり、所属グループに属する人物が「鈴木太郎」および「田中次郎」であり、「鈴木太郎」より受信されたデータである。このため、鈴木太郎以外、すなわち、「田中次郎」の所持する端末へ、即時チャットデータの反映を試みる。この時、図１４のテーブルより、「田中次郎」の記憶する端末は、端末Ｅおよび端末Ｆの２台であるが、端末Ｆはビジネス用途の端末であるため、趣味仲間の「鈴木太郎」からのチャットデータは、パーソナル用途の携帯電話である端末Ｅに対してのみ通知を行なう（Ｓ５３１）。
【０２２７】
データサーバ装置１より、本チャットデータの通知を受けた端末Ｅの制御部１５は、チャットデータをクライアントデータ記憶部１２に記憶する。それとともに、本データのアプリケーション属性が、チャットであるため、チャットプログラムを起動するか、または、あらかじめプロセスとして実行されているチャットアプリケーションに新規チャットデータ受信の通知を行なう。通知を受けたチャットアプリケーションは、出力部１３にチャットのウィンドウを表示するか、または画面そのものを切り替えるなどし、受信したチャットデータを出力する。なお、このとき、ユーザに対して音により通知するようにしてもよい。
【０２２８】
次に、「田中次郎」が、鈴木次郎からのチャットメッセージに気が付き、端末Ｅの出力部１３に表示されているメッセージに対して書込を行なうと、チャットアプリケーションは、端末Ｅのクライアントデータ記憶部１２のチャットデータを更新する。端末Ｅの制御部１５は、クライアントデータ記憶部１２のチャットデータが更新されると、そのアプリケーション属性がチャットであるため、即時にデータサーバ装置１に該データの更新を通信部１１によりネットワーク５を介して通知する（Ｓ５３２）。
【０２２９】
通知を受けたデータサーバ装置１のクライアント記憶データ管理部２は、サーバデータ記憶部３のチャットデータを受信内容に基づき更新する。また、本データのアプリケーション属性が「チャット」であり、所属グループに属する人物が「鈴木太郎」および「田中次郎」であり、チャットデータが「田中次郎」より受信されたデータであるため、田中次郎以外、すなわち、「鈴木太郎」の所持する端末へ、即時チャットデータの反映を試みる。この時、図１４のテーブルより、「鈴木太郎」の記憶する端末は、端末Ａおよび端末Ｂの２台であるが、最初の「鈴木太郎」からのチャットデータは、端末Ａより通知されたため、端末Ａに対して、該更新通知を行なう（Ｓ５３３）。
【０２３０】
以後は、同様の処理が、それぞの端末の制御部１５において実行される。
また、Ｓ５３３のメッセージに対して、「鈴木太郎」が端末Ａの入力部１４により、チャットメンバーに「鈴木花子」を追加する操作を行なったとする。この場合、端末Ａの制御部１５は、該チャットデータの所属グループ属性を、「鈴木太郎」、「田中次郎」および「鈴木花子」の３名に変更して、データサーバ装置１へ通知する（Ｓ５３４）。
【０２３１】
端末Ａからのチャットデータにおいて、チャットデータの所属グループ属性が変更され、所属グループに「鈴木花子」が追加されたため、データサーバ装置１のクライアント記憶データ管理部２は、該チャットデータを、「田中次郎」の端末Ｅに通知する（Ｓ５３５）のみならず、図１４のテーブルより「鈴木花子」の記憶する端末である、端末Ｃおよび端末Ｄに対して、該チャットデータの更新の通知を行なう（Ｓ５３６，５３７）。端末Ｃおよび端末Ｄにおいては、該チャットデータは、クライアントデータ記憶部１２に記憶されていないため、新規データとして登録され、上述と同様の処理が端末Ｃおよび端末Ｄにおいてなされる。
【０２３２】
該チャットデータへの応答が、「鈴木花子」により端末Ｃおいて行なわれると、端末Ｃの制御部１５は、通信部１１によりネットワーク５を介してデータサーバ装置１に該チャットデータの更新通知を行なう（Ｓ５３８）。データサーバ装置１のクライアント記憶データ管理部２は、本更新通知が、端末Ｃより送付されているため、本チャットにおける「鈴木花子」へのチャットデータは端末Ｃに通知することとし、端末Ｃより受信したチャットデータを、「鈴木花子」以外のメンバーの端末である、端末Ａおよび端末Ｅに対して、通知を行なう（Ｓ５３９，Ｓ５４０）。
【０２３３】
したがって、このチャットデータへの次の更新通知が端末Ｅより行なわれると（Ｓ５４１）、データサーバ装置１のクライアント記憶データ管理部２は、該更新通知を端末Ａおよび端末Ｃに対して行なう（Ｓ５４２，Ｓ５４３）。
【０２３４】
以上の処理により、各クライアント装置１０のチャットアプリケーションが、それぞれのクライアントデータ記憶部１２に対してチャットデータを作成、更新し、それにより、チャットシステムが全体として実現される。
【０２３５】
図３３を参照して、複数のユーザで共通のスケジュールデータを入力した場合および端末固有のスケジュールを入力した場合の処理について説明する。
【０２３６】
まず、「田中次郎」の保有する端末Ｅより、所属グループ属性が「スキー同好会」のスケジュールデータの登録があった場合の処理を説明する。
【０２３７】
「田中次郎」が端末Ｅの入力部１４を操作し、「スキー同好会」のスキーツアーのスケジュールを、所属グループ属性を「スキー同好会」として登録する。すると、端末Ｅの制御部１５は、クライアントデータ記憶部１２に該スケジュールデータの登録を行なうとともに、通信部１１により、ネットワーク５を介してデータサーバ装置１に接続し、該スケジュールデータの登録を行なう（Ｓ５５０）。本処理における所属グループ属性の付与は、データの属性編集という形で可能であってもよいし、ディレクトリ管理されており、所定のディレクトリに対して、所属グループ属性が付与されており、そのディレクトリ内のファイルには全て該ディレクトリと同じ所属グループ属性が付与されるようになっていてもよい。
【０２３８】
端末Ｅより、所属グループ属性が「スキー同好会」のスケジュールデータの登録を受けたデータサーバ装置１のクライアント記憶データ管理部２は、スケジュールデータをサーバデータ記憶部３に記憶するとともに、通信部４により、ネットワーク５を介して、端末Ａ，ＢおよびＦの３台のクライアント装置１０に対して該スケジュールデータの登録を行なう（Ｓ５５１，５５２，５５３）。データサーバ装置１より、該スケジュールデータを受信した各クライアント装置１０の制御部１５は、それぞれのクライアントデータ記憶部１２に該スケジュールデータの登録を行なう。
【０２３９】
次に、端末Ｂより、「鈴木太郎」がビジネスデータであるＢ社との打ち合わせの予定の入力を行なった場合の処理について説明する。
【０２４０】
「鈴木太郎」が端末Ｂの入力部１４を操作し、Ｂ社との打ち合わせのスケジュールの入力を、所属グループ属性を端末Ｂとして登録すると、端末Ｂの制御部１５は、クライアントデータ記憶部１２に該スケジュールデータの登録を行なう。それとともに、制御部１５は、通信部１１により、ネットワーク５を介してデータサーバ装置１に接続し、該スケジュールデータの登録を行なう（Ｓ５５４）。
【０２４１】
データサーバ装置１は、本処理における所属グループ属性が端末Ｂであるため、端末Ｂにのみ同期を行なえばよいと認識し、同じユーザが保有するクライアント装置１０である端末Ａに対して同期の処理を行なわない。これにより、たとえば、秘匿性が必要なビジネスデータなどが、パーソナル用途の端末に反映されてしまうことによって情報の漏洩などが発生する可能性を低減することが可能となる。
【０２４２】
図３４を参照して、クライアント装置１０における更新データの反映処理について説明する。
【０２４３】
クライアント装置１０の制御部１５は、まず、更新データの反映において必要となる空き容量の必要量を算出する（Ｓ６０１）。クライアント装置１０のクライアントデータ記憶部１２の空き容量と、Ｓ６０１で計算された必要量とを比較する（Ｓ６０２）。空き容量が不足した場合（Ｓ６０２でＹｅｓ）、クライアント装置１０の制御部１５は、クライアントデータ記憶部１２に記憶されているデータより、削除するデータを決定し、削除を行ない（Ｓ６０３）、再度クライアント装置１０のクライアントデータ記憶部１２の空き容量と、Ｓ６０１で計算された必要量とを比較する（Ｓ６０２）。空き容量が足りるようになると（Ｓ６０２でＮｏ）、クライアント装置１０の制御部１５は、クライアントデータ記憶部１２内の記憶データの更新を行なう（Ｓ６０４）。
【０２４４】
なお、上述の処理においては、必ず更新データの反映処理を行なうようになっているが、たとえば、クライアントデータ記憶部１２に記憶されている情報がすべて更新データよりも重要度が高い場合などにおいては、更新データを受付けないようにしてもよい。または、ユーザの設定によって、サーバからのデータ更新を一時的に受付けないようにすることも有用である。
【０２４５】
本実施例において、上述の削除データの決定は、次のようにして行なわれるものとする。
【０２４６】
データの削除が必要となったときの、クライアント装置１０のクライアントデータ記憶部１２に記憶されているデータの内容が図３５のような状態であったとする。なお、本実施例では、各データは、最終データアクセス時刻５０１、ユーザにより付与された、または、内容より自動的に付与された５段階の重要度５０２、および削除操作を許可するかどうかの可否５０３等を属性として持っているものとする。
【０２４７】
ここで、最終データアクセス時刻５０１は、そのデータに対して行なわれた最新の読出しアクセスの時刻でもあってもよいし、最新の書込みアクセスの時刻であってもよい。または、それらが、データ種別によって変化するようになっていてもよい。
【０２４８】
重要度５０２は、データサーバ装置１のサーバデータ上で付与されている重要度であってもよいし、各端末の機能や特徴により、所定のアルゴリズムにより、重要度を変化させるようにしてもよい。ビジネス用の端末にとっては、ビジネス以外のデータの重要度は下げるなどが考えられる。
【０２４９】
同様に、削除の可否５０３についても各端末の機能や特徴により、所定のアルゴリズムにより、属性を変化させるようにしてもよい。たとえば、携帯電話の端末にとっては、電話帳データは必須のものであるため、このデータに対しては、削除不可能の属性を持たせるようにしてもよい。
【０２５０】
制御部１５は、これらのデータより、まず、削除が許可されているデータの中から、最も重要度の低いデータをサーチする。図２８に示した例のデータでは、チャットデータ５０４およびニュースデータ５０５の２つのデータエントリが該当する。次に、制御部１５はこれら二つのデータの最終アクセス時刻を比較し、より古いほうのデータ、すなわち本例においては、ニュースデータ５０５を削除データとして決定する。
【０２５１】
もちろん、削除データの決定方法はこれに限られない。たとえば、スケジュールデータなどでは、時間順を重要度順に優先させた手続きとしてもよい。また、重要度は持たせずに時間順にのみ削除するようにしてもよい。すなわち、将来のデータは削除しないが、過去のスケジュールについては削除対象のリストに加えるなどの決定方法にしてもよい。
【０２５２】
さらに、それぞれのデータをヘッダ部分と本データ部分とにより構成し、ヘッダ部分を残して、データ量の大きい本データ部分のみを削除するようにすると、削除データのタイトルなどの閲覧は可能となり、操作性が向上すると考えられる。
【０２５３】
次に、データサーバ装置１のサーバデータの一部へのアクセスを外部ＡＳＰなどに許可することにより、データ加工サービスやデータ配信サービスを可能とする場合について説明を行なう。図３６は本処理におけるハードウェア構成図である。
【０２５４】
図３６には、図１に示したデータアクセスシステムに、新たにＡＳＰ６０が接続されている。
【０２５５】
データサーバ装置１のクライアント記憶データ管理部２において、所定の暗号化および認証手続きを経た外部のＡＳＰ６０は、所定の手続きによりデータサーバ装置１のサーバデータ記憶部３に記憶されているサーバデータの一部にアクセスすることが許可される。許可するアクセスの種類としては、ユーザがデータに対して設定した所属グループ属性３０３（図１３）が「ａｎｙｏｎｅ」となっているデータに対する読出し動作や、配信データを受け取るためのスプールエリアに対する新規データの書込み動作などである。また、十分に信頼の置けるＡＳＰであれば、スケジュールデータなど秘匿性のあるデータであっても読出し動作を許可してもよい。これにより、たとえば、ユーザのスケジュールデータに基き、ＡＳＰではスケジュールにおいて必要となる可能性の高い時刻表や、昼食時にユーザがいる場所付近の飲食店の情報などを提示したり、さらには電子割引券をクライアント装置に対して発行することなどが可能となる。これにより、広告活動においてはユーザの行動情報を手中にしているため、きわめて高効率の宣伝を行なうことが可能になる。このようなＡＳＰ６０によって生成されたデータは、上述のサーバデータにおける新規データと同様の手続きにより、所望のクライアント装置１０へ配信され、適切な方法によりユーザの注意を喚起する。
【０２５６】
さらに、スケジュールデータをもとに、海外出張であればフライトの予約やホテルの予約を自動的に行なうサービスなどが考えられる。ただしユーザの確認がなければすぐにキャンセルするようにしておくことなどがこのようなサービスにおいては有効と考えれられる。
【０２５７】
別の応用としては、たとえばクライアント装置１０にカメラの機能がついている場合、写真に取った多数の名刺の画像データより、文字認識を行ない、電子名刺データを作成するサービスや、色調補正、高精彩プリントサービスなどが可能となる。
【０２５８】
上述の処理により、データサーバ装置１のクライアント記憶データ管理部２およびクライアント装置１０の制御部１５が、それぞれのデータエントリのアプリケーション属性に従って、自動的に通信を行なう。このため、データサーバ装置１やクライアント装置１０において通信を必要とするメール、チャットまたは掲示板などの各通信アプリケーションは、全く通信を意識せずに、データに所定の属性を付与し、それぞれのクライアントデータ記憶部１２にアクセスするだけで所定の通信が行なわれる。このため、クライアント装置１０は、それぞれのデータの特徴にあわせて表示方法などのユーザインターフェースを切り替えるだけでよい。これにより通信プロトコルの実装を省くことが可能となり、コーディングの作業が簡易化される。
【０２５９】
なお、ここではアプリケーション属性に基づいて通信処理を行なう、すなわち、アプリケーション属性を通信属性としても利用するようにした。しかし、もちろん、アプリケーション属性はユーザインターフェースの切り替えのみに使用し、クライアント装置１０からデータサーバ装置１への更新処理と、データサーバ装置１からクライアント装置１０への更新処理とを指定する通信属性を別途設けるようにしてもよい。
【０２６０】
また、データサーバ装置１のサーバデータへの一部アクセスを外部ＡＳＰへＶＰＮ（VirtualPrivate Network）などにより許可することにより、クライアント装置１０では処理が困難な高度なデータ処理を行なうＡＳＰ事業や、広大なＤＢ（データベース）を必要とするサービスなどを各クライアント装置１０に対して行なうことが可能となる。
【０２６１】
また、上述のシステムにおいて、クライアント装置１０のクライアントデータにおいて発生したデータ変更を、データサーバ装置１のサーバデータに反映する処理において、たとえば、変更されたクライアントデータのもととなったサーバデータの最終更新日付よりも、反映処理の時点でのサーバデータの最終更新日付の方が新しい場合などにおいては、クライアント装置１０からのサーバデータ更新要求を受付けないようにし、さらには、該クライアント装置１０を使用するユーザにその旨を通知するようにしてもよい。
【０２６２】
逆に、データサーバ装置１のサーバデータの更新をクライアント装置１０の対応するクライアントデータに反映する処理において、サーバデータの更新前の最終更新日時よりも、対応するクライアントデータの最終更新日時の方が新しい場合などにおいては、データサーバ装置１からのクライアントデータ更新要求を受付けないようにし、さらには、該クライアントデータの更新を行なったユーザにその旨を通知するようにしてもよい。
【０２６３】
その為に、更新通知においては、該更新データの更新以前の最終更新日時も合わせて通知するようにしてもよい。
【０２６４】
または、スイッチなどユーザの設定によって、データサーバ装置１からのデータ更新を一時的に受付けないようにすることも有用である。
【０２６５】
なお、上述したシステムにおいては、アプリケーションの使用するデータの共有を行なっているが、ＪＡＶＡ（Ｒ）など共通のアプリケーションを実行することが可能な環境においては、実行されるアプリケーションプログラムや、そのプログラムの環境設定ファイルを、上述した手法で共有することにより、たとえば、同一ユーザの端末間で、プログラムのツールバーの個人設定や、ブックマークなどを共通にしたり、ある端末で行なっていたゲームの続きを別の端末上で実行したりすることなども容易に実現することができる。
【０２６６】
ここに記述したフロー以外に、データサーバ装置１のサーバデータを各端末において、適宜ダウンロードして参照する手続きもある。
【０２６７】
また、たとえば、ワークステーションなどによるデータサーバ装置１が広域ネットワーク上にあり、広域ネットワークにクライアント装置としてＰＣが接続されており、そのＰＣをデータサーバ装置１としてＬＡＮ（Local Area Network）にＰＤＡなどがクライアント装置１０として接続されているような構成も有用と考えられる。
【０２６８】
本実施例では、データサーバ装置１に、全てのクライアント装置１０のマスターデータを記憶する構成とした。このような場合においては、ワークステーションなどによるデータサーバ装置１において全てのクライアント装置１０であるＰＣのデータのマスターデータを記憶することは、データの規模が大きくなった場合に非常に広大な記憶領域を必要とし、実現が困難となる。
【０２６９】
したがって、データサーバ装置１は一台のコンピュータで実現される必要はなく、複数台のコンピュータが適宜データの同期を取る、または、適宜データを転送するなどの処理によって連携することにより、仮想的に１台のデータサーバ装置１を形成するような構成としてもよい。あるいは、上述の任意のクライアント装置が１台または複数台でサーバ装置の機能を持つように構成してもよい。
【０２７０】
または、ワークステーションなどによるデータサーバ装置１においては、クライアント装置１０である全てのＰＣのマスターデータを記憶せずに、同期されるべきクライアント装置１０間のデータのみを一時的に記憶し、それぞれのクライアント装置１０間でデータの同期が取れれば、データサーバ装置１のサーバデータ記憶部３から該データを削除し、各クライアント装置１０であるＰＣのデータの同期されるべきデータ同士の関連と、相互同期状況のみを管理するような構成とすることも有用であると考えられる。
【０２７１】
以上説明したように本実施例によると、データサーバ装置１において、各クライアント装置１０で利用されるデータに対応したサーバデータが確実に保存されている。このため、クライアント装置１０に事故が発生してもそれらのデータは保証されるという効果がある。
【０２７２】
また、各クライアント装置１０はデータサーバ装置１のサーバデータ記憶部３を仮想記憶として使用する。このため、各端末の実記憶容量よりもはるかに多い情報を利用することが可能になる。それとともに、データサーバ装置１において各クライアント装置１０内に記憶されているデータを管理することにより、他のクライアント装置１０と共有すべき情報については、その情報を記憶しているクライアント装置１０に対して自動的に情報を同期する。このため、各ユーザは、情報を共有する端末において、２度同じ操作や処理を行なう必要がないという効果がある。
【０２７３】
さらに、各クライアント装置１０内の通信アプリケーションは、各サービスごとにファイルに通信属性をつけて仮想記憶に記憶することにより実現される。このため、通信アプリケーションごとに通信プロトコルなどの通信を意識したコーディングが不要になるという効果がある。
【０２７４】
第１の実施例 第１の変形例
以下、データサーバ装置における全体的な動作（図５）の変形例を、図３７を用いて説明する。なお、以下の説明において、前述の図５以外の、ハードウェア構成、フローチャートおよび動作は、前述の第１の実施例と同じであるため、それらについてのここでの詳細な説明は繰返さない。また、図３７に示す処理の中で、前述の図５と同じ処理については同じステップ番号を付してある。それらについての処理も同じである。したがってそれらについてのここでの詳細な説明は繰返さない。
【０２７５】
図３７を参照して、データサーバ装置１はクライアント装置１０からの通信を待ち（Ｓ１０１）、通信があると（Ｓ１０１でＹｅｓ）、そのクライアント装置１０からの通信データがデータサーバ装置１のサーバデータ記憶部３に記憶されているサーバデータの読出しを要求するものかどうかを判断する（ＳＤ１０１）。
【０２７６】
通信データがサーバデータの読出しを要求するものであった場合（ＳＤ１０１でＹｅｓ）、クライアント記憶データ管理部２は、データサーバ装置１のサーバデータ記憶部３に記憶されているその要求データを読出し、要求のあったクライアント装置１０へその要求データを転送する（ＳＤ１０２）。
【０２７７】
通信データが、サーバデータの読出しを要求するものでなかった場合（ＳＤ１０１でＮｏ）、通信データがデータサーバ装置１のサーバデータ記憶部３に記憶されているサーバデータの更新を要求するものかどうかを判断する（Ｓ１０２）。その後、処理は、Ｓ１０３またはＳ１０６へ移される。
【０２７８】
以上のようにして、本変形例においては、クライアント装置１０からサーバ装置１へ送信された通信データが、サーバデータの読出しの要求である場合には、要求されたデータの応答処理が行なわれる。
【０２７９】
第１の実施例 第２の変形例
以下、クライアント装置の全体的な動作（図８）の変形例を、図３８を用いて説明する。なお、以下の説明において、前述の図８以外の、ハードウェア構成、フローチャートおよび動作は、前述の第１の実施例と同じであるため、それらについてのここでの詳細な説明は繰返さない。また、図３８に示す処理の中で、前述の図８と同じ処理については同じステップ番号を付してある。それらについての処理も同じである。したがってそれらについてのここでの詳細な説明は繰返さない。
【０２８０】
図３８を参照して、入力部１４により検知されたユーザ操作により、データ参照要求が発生した場合には（Ｓ２０１でＮｏ，ＳＥ２０１でＹｅｓ）、クライアント装置１０のクライアントデータ記憶部１２に要求されたデータがキャッシュデータとして存在するかどうかを判断する（ＳＥ２０２）。
【０２８１】
クライアントデータ記憶部１２に要求されたデータが存在しなかった場合（ＳＥ２０２でＮｏ）、クライアント装置１０の制御部１５は通信部１１を制御してデータサーバ装置１へ接続し、データサーバ装置１のサーバデータ記憶部３に記憶されている要求データを読出し、提示する（ＳＥ２０４）。なお、この時サーバへのアクセスが不可能であった場合には、ユーザへサーバデータの取得に失敗したことを通知する。
【０２８２】
クライアントデータ記憶部１２に要求されたデータが存在した場合（ＳＥ２０２でＹｅｓ）、クライアント装置１０の制御部１５は、データの属性を確認し、重要度が所定の値より高い、あるいは、極めて即時性が重要なデータの種類である場合、サーバデータの参照が必要であると判断する（ＳＥ２０３でＹｅｓ）。クライアント装置１０の制御部１５は、通信部１１を制御してデータサーバ装置１へ接続し、データサーバ装置１のサーバデータ記憶部３に記憶されている要求データを読出し、これを提示する（ＳＥ２０４）。なお、この時データサーバ装置１へのアクセスが不可能であった場合には、クライアントデータ記憶部１２に記憶されていたキャッシュデータを提示し、ユーザへサーバデータの取得を失敗したため、キャッシュ中のデータを表示していることを通知する。
【０２８３】
また、クライアントデータ記憶部１２に要求のあったデータが存在した場合（ＳＥ２０２でＹｅｓ）、クライアント装置１０の制御部１５は、データの属性を確認し、重要度が所定の値より低い、あるいは、極めて即時性が重要ではないデータの種類である場合などは、サーバデータの参照が必要無いと判断する（ＳＥ２０３でＮｏ）。クライアント装置１０の制御部１５は、クライアント装置１０のクライアントデータ記憶部１２に記憶されている要求データを読出し、これを提示する（ＳＥ２０５）。
【０２８４】
以上のようにして、本変形例においては、入力部１４により検知されたユーザ操作によりデータの登録要求が発生すると、クライアント装置１０のキャッシュデータの有無を判断した後、要求されたデータが提示される。
【０２８５】
第２の実施例
以下、図面を参照しつつ、本実施例について説明する。なお、以下に説明する以外のハードウェア構成、フローチャートおよび動作は、前述の第１の実施例と同じであるため、それらについてのここでの詳細な説明は繰返さない。
【０２８６】
図３９に、データサーバ装置１のサーバデータ記憶部３において記憶されているサーバデータと、複数のクライアント装置１０のクライアントデータ記憶部１２において記憶されるクライアントデータとの関係を示す。
【０２８７】
本実施例において、本システムの利用者は「鈴木太郎」、「鈴木花子」、「田中次郎」および「山田三郎」の４名であると想定する。「鈴木太郎」と「鈴木花子」とは、婚姻関係にある。この両者は、データサーバ装置１において管理されている鈴木家グループ１２２０に所属する。「鈴木太郎」と「田中次郎」とは、データサーバ装置１において管理されているスキー同好会グループ１２２１に所属する。「田中次郎」と「山田三郎」とは、データサーバ装置１において管理されているＡ社ＳＥ部というグループ１２２２に所属する。
【０２８８】
「鈴木太郎」は、クライアント装置である、端末Ａ１２０６および端末Ｂ１２０７を所持する。「鈴木花子」は、端末Ｄ１２０９を所持する。「鈴木太郎」と「鈴木花子」とは、端末Ｃ１２０８を共用して所持する。「田中次郎」は、端末Ｅ１２１０を所持する。「山田三郎」は、端末Ｇ１２１２を所持する。「田中次郎」と「山田三郎」とは、端末Ｆ１２１１を共用して所持する。
【０２８９】
データサーバ装置１のサーバデータ記憶部３では、鈴木花子個人データ１２０１、鈴木太郎個人データ１２０２、鈴木家データ１２０３、スキー同好会グループデータ１２０４、田中次郎個人データ１２０５、Ａ社ＳＥ部グループデータ１２０６および山田三郎個人データ１２０７のデータ集合が記憶されている。図３９において、データサーバ装置１内のサーバデータのデータ集合とそれぞれのクライアント装置１０内のクライアントデータとは、直線により結ばれたような対応関係をもつ。
【０２９０】
たとえば、「鈴木太郎」が所持している端末Ａ１２０６のクライアントデータ記憶部１２には、データサーバ装置１により管理されたデータ集合である、鈴木太郎個人データ１２０２、鈴木家データ１２０３およびスキー同好会グループデータ１２０４の一部または全部が記憶されている。
【０２９１】
本実施例において、データサーバ装置１は、クライアント装置１０より参照されるサーバデータとその属性、サーバデータを反映させるクライアント装置とその属性、クライアント装置のユーザとその属性、の３つの対応関係を管理する。この属性に基づいて、サーバデータ、クライアント装置、ユーザは、それぞれのデータカテゴリに分類される。たとえば、同じ属性であるサーバデータ（サーバデータを実行するためのアプリケーションが同じ）は、同じデータカテゴリに分類される。同じ属性であるクライアント装置（データサーバ装置とクライアント装置との通信経路が同じ）は、同じ装置カテゴリに分類される。同じ属性であるユーザ（ユーザにより登録された嗜好が同じ）は、同じユーザカテゴリに分類される。データサーバ装置１は、分類された、データカテゴリ、装置カテゴリおよびユーザカテゴリを対応付けたテーブルを記憶する。データサーバ装置１は、そのテーブルと、更新されたデータエントリのデータ属性と、データ更新を通知するクライアント装置の装置属性と、データ更新を通知するクライアント装置を所持するユーザのユーザ属性とに基づいて、実行する処理を決定する。
【０２９２】
図４０に、データサーバ装置１のサーバデータ記憶部３に記憶される、サーバデータとその属性の記憶形式の一例を示す。なお、この例は、図３９に示した、各ユーザ、端末、グループの関係にしたがっている。
【０２９３】
クライアント装置１０の一部には、スケジュールアプリケーションと、住所録アプリケーション、アルバムアプリケーションがすでにインストールされていると想定する。
【０２９４】
図４０におけるそれぞれの行のデータ単位を、「データエントリ」と表現する。各データエントリは、データ内容１３０１、時間属性１３０２、アプリケーション属性１３０３、所属属性１３０４、用途属性１３０５、記憶中端末属性１３０６および重要度属性１３０７を含む。
【０２９５】
時間属性１３０２は、それぞれのデータエントリの作成時間、スケジュールアプリケーションを用いて入力された行動予定の時間などの属性（その作成時間がいつであるのか等を示す）である。アプリケーション属性１３０３は、それぞれのデータエントリのデータの種類、すなわち、そのデータを取扱うアプリケーションを示す属性である。所属属性１３０４は、それぞれのデータエントリが所属するユーザやユーザグループを示す属性である。用途属性１３０５は、それぞれのデータエントリがビジネス用のデータであるのかパーソナル用途のデータであるのかを示す属性である。記憶中端末属性１３０６は、それぞれのデータエントリを現在記憶中である端末を示す属性である。重要度属性１３０７は、それぞれのデータエントリの重要度を示す属性である。
【０２９６】
なお、これらの属性は、新規データ作成時にはデフォルトの値が設定されているものとする。すなわち、データの所属属性は、該データが作成されたクライアント装置のユーザ属性が設定され、アプリケーション属性は、該データを作成したアプリケーションが設定される。重要度は、たとえば中程度の“３”が設定される、などである。もちろんこれらのデフォルト属性のいくつか、すなわち、ユーザ所属属性、重要度属性、用途属性などは、ユーザの嗜好に合わせて変更することが可能であり、作成済みデータの属性もデータの所有者により更新可能である。
【０２９７】
図４１に、データサーバ装置１のクライアント記憶データ管理部２において管理される、クライアント装置とその属性を示す。
【０２９８】
データサーバ装置１のクライアント記憶データ管理部２は、図４１に示すような端末ごとの管理テーブルを管理する。この管理テーブルには、ユーザ属性１４０１、種別属性１４０２、用途属性１４０３、表現能力属性１４０４および通信路属性１４０５などが記憶される。
【０２９９】
ユーザ属性１４０１は、それぞれの端末ごとに、端末を所持しているユーザを示す属性である。種別属性１４０２は、端末がＰＣ(Personal Computer)であるのか、ＰＤＡであるのか、携帯電話であるのかという、端末の種別を示す属性である。用途属性１４０３は、ユーザがその端末をどのような用途、目的で所持しているのかを示す属性である。表現能力属性１４０４は、音声出力の可否や、映像表示能力など、端末がどのような表現能力を持っているかを示す属性である。、通信路属性１４０５は、通信路に無線の通信路を利用しているのか、通信路に有線の通信路を利用しているのか、通信速度は高速なのか低速なのか、通信路は従量課金であるのか、固定課金であるのかを示す属性である。
【０３００】
なお、これらの属性は、クライアント装置を本サービスに登録する際に所定の手続きによりサーバ装置へ追加、登録されるものとする。さらに、本実施例では、クライアント装置のハードウェアに関する属性は自動的に通知され、クライアント装置のユーザや用途などは、ユーザの入力によりサーバ装置へ通知されるようになっているものとする。
【０３０１】
この管理テーブルにより、端末Ａは、「鈴木太郎」に所有されている従量課金の高速無線通信機能を持ったパーソナル用途の携帯電話であることがわかる。この端末Ａは、音声出力および画像の表示能力を持つ。端末Ｂは、「鈴木太郎」に所有されている従量課金の低速無線通信機能を持ったビジネスおよびパーソナル用途のＰＤＡであることがわかる。この端末Ｂは、音声出力が不可、画像の表示能力を持つ。端末Ｃは、「鈴木太郎」と「鈴木花子」の両名により共用して所有されている固定課金の高速有線通信機能を持ったパーソナル用途のデスクトップＰＣであることがわかる。この端末Ｃは、音声出力が可能、画像の表示能力を持つ。端末Ｄは、「鈴木花子」に所有されている従量課金の高速無線通信機能を持ったパーソナル用途の携帯電話であることがわかる。この端末Ｃは、音声出力が可能、テキストの表示のみが可能な表示能力を持つ。端末Ｅは、「田中次郎」に所有されている従量課金の低速無線通信機能を持ったビジネスおよびパーソナル用途の携帯電話であることがわかる。この端末Ｅは、音声出力が可能、テキストの表示のみが可能な表示能力を持つ。端末Ｆは、「田中次郎」と「山田三郎」とに共用して所有されている従量課金の低速無線通信機能を持ったビジネス用途のＰＤＡであることがわかる。この端末Ｆは、音声出力が可能、画像の表示能力を持つ。端末Ｇは、「山田三郎」に所持されている、固定課金の高速有線通信機能を持ったパーソナル用途のデスクトップＰＣであることがわかる。この端末Ｇは、音声出力が可能、画像の表示能力を持つ。
【０３０２】
ユーザが共用して所持する端末においては、ログイン管理などにより、ユーザ毎に提示される内容が切換えられる処理が行なわれる。
【０３０３】
端末は、データサーバ装置１から受信した情報に基づいて、端末のユーザへ、データエントリが更新されたことを、音、振動、画面表示などを用いてユーザに通知することができる。さらに、この通知は、データサーバ装置１から受信したユーザ通知情報に基づいて、ユーザへの通知の度合いを切換えることができる。データサーバ装置１から「強いユーザ通知」を受信すると、たとえば、端末は大きな警告音を発生してユーザへデータ更新を通知する。携帯電話であれば、データサーバ装置１から受信した情報に基づいて、着信音の種類、音量が自動的に変更される。データサーバ装置１は、たとえば重要なデータであるほど、ユーザが気付きやすいようなユーザ通知を設定する。
【０３０４】
端末は、データサーバ装置１から受信した自動消去情報に基づいて、端末の記憶部に記憶されたデータを消去する優先順位を変更することができる。この消去の優先順位とは、図３４のＳ６０３における削除データの決定の優先順位であり、データサーバ装置１から「消えやすい自動消去」を受信すると、削除データとして優先的に決定され削除される対象になる。したがって、重要なデータであるほど、端末が自動消去しにくく、重要でないデータであるほど、消去されやすいように自動消去方法を設定する。
【０３０５】
図４２に、データサーバ装置１のサーバデータ記憶部３に記憶される、ユーザとその属性の記憶形式の一例を示す。
【０３０６】
図４２に示すように、このテーブルは、それぞれのユーザ１５０１ごとに、ユーザグループ属性１５０２、所有端末属性１５０３、個人設定属性１５０４、嗜好属性１５０５および購入ソフト属性１５０６などの属性を記憶する。
【０３０７】
ユーザグループ属性１５０２は、ユーザが所属しているユーザグループを示す属性である。所有端末属性１５０３は、ユーザが所持している端末を示す属性である。個人設定属性１５０４は、たとえばブックマークや、ツールバーの設定など、ユーザがそれぞれの端末で利用するアプリケーションの設定情報を示す属性である。嗜好属性１５０５は、ユーザの好きな音楽や好物、趣味などを示す属性である。購入ソフト属性１５０６は、ユーザが端末で利用することができる購入済みアプリケーションを示す属性である。
【０３０８】
なお、これらの属性は、ブラウザを用いるなど所定の手続きにより、ユーザがサーバへ登録可能となっているものとする。また、本実施例においては、ユーザグループは、自由にユーザがユーザＩＤやニックネーム等によりグループメンバーを特定して作成できる。新規グループの作成時には、各グループメンバーに登録の可否について問合せ、登録を許諾したメンバーのみが新規グループに登録されるものとする。メンバーの追加および削除については、グループを作成したユーザに権限があり、グループからの脱退については、各グループメンバーに権限があるとする。
【０３０９】
このテーブルには、例えば、「鈴木太郎」は、鈴木家グループとスキー同好会グループというユーザグループに属していること、「鈴木太郎」は、端末Ａ，端末Ｂ，端末Ｃの３台のクライアント装置１０を所持していること、「鈴木太郎」が個人的に設定したブックマークや呼出音の設定、「鈴木太郎」の好みはバッハの音楽であること、「鈴木太郎」の好物はカツ丼であること、「鈴木太郎」が購入済みのソフトウェアは、「表計算ソフトＡ」、「グラフィックソフトＡ」であることが分かる。
【０３１０】
「鈴木太郎」が使用する端末Ａ，端末Ｂ，端末Ｃの３台のクライアント装置１０では、個人設定を共通にすることができる。この個人設定とは、たとえば、ウェブブラウザのブックマークや、各種アプリケーションのツールバーなどの設定、マウスやキーボードの入力環境の設定である。これらが共通になることにより複数の端末を使用するユーザの利便性が向上する。なお、端末Ｃは、「鈴木太郎」および「鈴木花子」の２名により使用される端末であるため、ユーザ毎に設定されるログイン処理などにより、この個人設定が管理される。ログインしたユーザ毎にアプリケーションの設定が管理され、ログインユーザに応じて各種の設定が反映された画面が表示される。
【０３１１】
データサーバ装置１のサーバデータ記憶部３に、アプリケーションソフトを記憶しておき、クライアント装置からの要求に応じて、それらをそのクライアント装置へ送信できる。この時、図４２に示すテーブルを用いて、ユーザ毎に購入済みのソフトウェアを管理する。たとえば、「鈴木太郎」は、「表計算ソフトＡ」、「グラフィックソフトＡ」という２種類のアプリケーションを購入済みである。「鈴木太郎」が所有する端末Ａにこれらのソフトウェアがインストールされていない場合に、それらをデータサーバ装置１がクライアント装置１０に送信してその端末Ａにインストールすることができる。このとき、「鈴木太郎」は、これらのソフトウェアの販売会社から、１ユーザが所有する複数の装置へのインストールが認められているとする。
【０３１２】
また、ユーザの嗜好情報より、データサーバ装置１は、ユーザの嗜好に合致する、広告などの情報を送信することができる。たとえば、ユーザがデータサーバ装置１に、自己の嗜好を「音楽、バッハ」と登録しているユーザは、ユーザカテゴリが「音楽の趣味でバッハを好む」というカテゴリに分類される。このカテゴリに分類されたユーザの端末には、「バッハ」に関する情報が、データサーバ装置１から送信される。
【０３１３】
なお、端末属性の所有者情報とユーザ属性の所有端末属性とは、どちらか一方でもよい。
【０３１４】
本実施例における、データサーバ装置１のサーバデータ記憶部３に記憶されているデータエントリが更新されたときに、データサーバ装置１が実行する処理を決定するためのテーブルの一例を、図を用いて説明する。
【０３１５】
図４３に、データサーバ装置１のサーバデータ記憶部３に記憶されているデータエントリが更新されたときに、データサーバ装置１が実行する処理を決定するときに利用する、属性とその属性に対する処理とを記憶したテーブルの一部を示す。このテーブルは、データサーバ装置１のサーバデータ記憶部３に記憶される。
【０３１６】
図４３に示したテーブルを説明するために、ユーザ「鈴木太郎」が端末Ｃを用いて、スキー旅行写真のアルバムデータのデータエントリを更新した場合について説明する。
【０３１７】
図４０に示すように、このデータエントリは、アプリケーション属性として、“アルバム”、所属属性として“スキー同好会”、用途属性として“パーソナル”、記憶中端末属性として“Ａ，Ｃ，Ｅ”、重要度属性として“２”が記憶されている。このデータエントリの更新通知を受信したデータサーバ装置１は、図４３に示すテーブルと、更新されたサーバデータのデータ属性と、更新を通知する端末の端末属性とに基づいて、処理を決定する。図４３に示すテーブルにより、アプリケーション属性が“アルバム”、重要度が“２”以下であるこのデータエントリについては、以下の処理が実行されることが分かる。すなわち、画像が表示可能かつ通信路が固定課金である端末に対しては、定期的な通信時に、このデータエントリを記憶中の端末に、完全なデータを通知する。画像が表示可能かつ通信路が従量課金である端末に対しては、定期的な通信時に、このデータエントリを記憶中の端末に、データが更新されたということのみを通知する。テキストの表示しかできず画像が表示できない端末に対しては、一切通知を行わない。
【０３１８】
図４０と図４１とを参照することにより、端末Ａに対しては、従量課金の通信路を持つ端末であるため、定期的な通信時に、データが更新されたということのみが通知される。端末Ｃに対しては、固定課金の通信路を持つ端末であるため、定期的な通信時に、完全な更新データが通知される。端末Ｅに対しては、画像表示能力を持たないため、通知を行なわない。
【０３１９】
さらに、ユーザ「田中次郎」が端末Ｆにおいて、Ｃ社との打ち合わせのデータエントリを更新した場合について説明する。
【０３２０】
図４０に示すように、このデータエントリは、アプリケーション属性として、“スケジュール”、所属属性として“Ａ社ＳＥ部”、用途属性として“ビジネス”、記憶中端末属性として“Ｆ”、重要度属性として“５”が記憶されている。このデータの更新通知を受信したデータサーバ装置１は、図４３に示すテーブルと、更新されたサーバデータのデータ属性と、更新を通知する端末の端末属性とに基づいて、処理を決定する。図４３に示すテーブルにより、アプリケーション属性が“スケジュール”で重要度が“３”以上であるこのデータエントリについては、以下の処理が実行されることが分かる。すなわち、端末の属性には関係なく、このデータエントリを利用する端末の全てに、即時に、通知する。
【０３２１】
図４０と図４１を参照することにより、Ａ社ＳＥ部のメンバーである、「田中次郎」または「山田三郎」により利用される端末、かつビジネス用途である端末である端末“Ｅ”と端末“Ｆ”とに対して、即時に通知が実行される。
【０３２２】
このテーブルにより導き出される処理は、ユーザの嗜好により変化するため、所定の操作により（たとえば、ユーザがデータサーバ装置１に登録の変更を要求し、データサーバ装置１は、テーブルを書換える。）、ユーザが自由に属性の条件と処理とを編集できるようにすることが望ましい。
【０３２３】
本実施例における、データサーバ装置１のサーバデータ記憶部３に記憶されているデータエントリが更新されたときに、データサーバ装置１が実行する処理を決定するためのテーブルの一例を、さらに図を用いて説明する。
【０３２４】
図４４に、データサーバ装置１のサーバデータ記憶部３に記憶されているデータエントリが更新されたときに、データサーバ装置１が実行する処理を決定するときに利用する、属性とその属性に対する処理とを記憶したテーブルの一部を示す。このテーブルは、データサーバ装置１のサーバデータ記憶部３に記憶される。
【０３２５】
図４４に示したテーブルを説明するために、ユーザ「田中次郎」が端末Ｅを用いて、住所録データのデータエントリを更新した場合について説明する。
【０３２６】
図４０に示すように、このデータは、アプリケーション属性として、“住所録”、重要度属性として“２”が記憶されている。このデータエントリの更新通知を受信したデータサーバ装置１は、図４４に示すテーブルと、更新されたサーバデータのデータ属性と、更新を通知する端末の端末属性とに基づいて、処理を決定する。図４４に示すテーブルにより、端末が携帯電話である場合には、ユーザ通知が“弱”、自動消去が“なし”という情報とともに、端末にデータエントリの更新を送信する。端末が携帯電話以外である場合には、ユーザ通知情報が“弱”、自動消去情報が“消えやすい”という情報とともに、端末にデータエントリの更新を送信する。
【０３２７】
データサーバ装置１から、ユーザ通知情報および自動消去情報とともにデータエントリの更新を受信した端末は、ユーザ通知情報および自動消去情報に基づいて、ユーザへの音などによるデータ更新の通知および更新されたデータの自動消去を行なう。この自動消去は、図３４のＳ６０３において行なわれる。
【０３２８】
さらに、ユーザ「田中次郎」が端末Ｆにおいて、Ｃ社との打ち合わせのデータエントリを更新した場合について説明する。
【０３２９】
図４０に示すように、このデータエントリは、アプリケーション属性として“スケジュール”、重要度属性として“５”が記憶されている。このデータエントリの更新通知を受信したデータサーバ装置１は、図４４に示すテーブルと、更新されたサーバデータのデータ属性と、更新を通知する端末の端末属性とに基づいて、処理を決定する。このスケジュールが未来のスケジュールである場合には、端末の種別に関わらず、ユーザ通知情報が“強”、自動消去情報が“なし”という情報とともに、端末にデータエントリの更新を送信する。
【０３３０】
データサーバ装置１から、ユーザ通知情報および自動消去情報とともにデータエントリの更新を受信した端末は、ユーザ通知情報および自動消去情報に基づいて、更新されたデータの自動消去を行なう。
【０３３１】
このテーブルにより判断されるデータサーバ装置１が実行する処理は、ユーザの使用環境により（たとえば、一時的に大きな警告音を鳴らせたくないなど）、さまざまに変化するため、所定の操作により（たとえば、ユーザがデータサーバ装置１から受信した通知情報によらず、ユーザの通知を「画面のみ」とするなど）、ユーザが変更できるようにすることが望ましい。
【０３３２】
また、更新を行なったユーザと、クライアント装置における更新通知を行なう対象となるユーザが同一である場合と異なる場合とで、たとえば、異なる場合にはユーザ通知を行なうが、同一の場合にはユーザ通知を行なわないようにしてもよい。
【０３３３】
なお、ここでは、データサーバ装置においてユーザ通知および自動消去のレベルを決定したが、クライアント装置において図４４に示すテーブルを記憶しておいて、そのテーブルと、クライアント装置の属性と、データサーバ装置から受信したデータの属性とに基づいて、ユーザ通知および自動消去のレベルを判断させるようにしても良い。
【０３３４】
第３の実施例
以下、図面を参照しつつ、本実施例について説明する。なお、以下に説明する以外のハードウェア構成、フローチャートおよび動作は、前述の第２の実施例と同じであるため、それらについてのここでの詳細な説明は繰返さない。
【０３３５】
図４５に、データサーバ装置１のサーバデータ記憶部３に記憶される内容を示す。本実施例において、サーバデータ記憶部３は、各クライエント装置１０から利用されるオブジェクトおよびその属性（以下、属性をプロファイルとも記述する。）を記憶するオブジェクト／オブジェクトプロファイル記憶部７０１、クライエント装置の属性を記憶するクライエント装置プロファイル記憶部７０２、ユーザの属性を記憶するユーザプロファイル記憶部７０３、各プロファイルやその他の状況に応じてオブジェクトを操作するためのルールを記憶するプロセスルール記憶部７０４とを含む。
【０３３６】
本実施例においては、各オブジェクトは、たとえばＸＭＬ（eXtensibleMarkup
Language）のような記述言語により構造化された文書オブジェクトと想定し、１つのオブジェクトは、１つあるいは複数のエレメントにより構成されているものとする。
【０３３７】
図４６に、構造化されたオブジェクトが、複数のクライエント装置１０に適宜伝播していく様子を示す。この図は、クライエント装置Ａで、ユーザ操作により新たに作成されたオブジェクトＴが、端末に起因するデータ更新処理Ｓ２０４（図８参照）によりサーバ装置１へ伝播される（ＳＰ１）様子を示す。さらにこの図は、サーバ装置１の他のクライエント装置１０への反映処理Ｓ１０５（図５参照）よりオブジェクトＴが適宜加工されてクライエント装置Ｂおよびクライエント装置Ｃに伝播する（ＳＰ２）様子を示す。
【０３３８】
本実施例におけるオブジェクトの加工は、図４６に示すように、構造化されたオブジェクトのエレメント単位で選択が可能であり、各オブジェクトのルールノードを含む元のオブジェクトＴの部分集合Ｔ′およびＴ″へと加工される。この処理においてエレメントの削除は、実質的な削除でもよく、あるいはサーバ装置１のマスタオブジェクトの該当エレメントへのリンクへの交換でもよい。本処理の詳細については後述する。
【０３３９】
次に、サーバ１において、プロファイルなどの諸条件により、前述のオブジェクトの加工を図４５に示した各情報により行なう処理について説明する。
【０３４０】
オブジェクト／オブジェクトプロファイル記憶部７０１には、構造化言語によって記述されたオブジェクトが記憶されている。本実施例においてはＸＭＬの「attribute」により各属性が各オブジェクトに割当てられているものとする。クライエント装置プロファイル記憶部７０２には、図１４に示したように各クライエント装置１０の属性が記憶されている。ユーザプロファイル記憶部７０３には、図４２に示したように、各ユーザとその属性とが記憶されている。プロセスルール記憶部７０４には、図４７〜図５０に示すように、オブジェクトの更新処理を行なうためのテーブルと、前述のオブジェクトの加工や伝播における処理を行なうためのルールとが記憶されている。
【０３４１】
以下、これらのルールの利用方法について詳細に説明する。
図４７に、クライエント装置１０の能力と、オブジェクトのエレメントとの適合性を表わす、ブーリアンの出力を持つ能力適合関数の一部を示す。この図によれば、この関数は、たとえばオブジェクトのエレメントの種別属性が静止画であった場合、端末の表示能力属性がグラフィックであれば「１」を、テキストのみの表示しか行なえない端末であれば「０」を返す。また、この関数は、エレメントの種別属性が動画であった場合に、端末の動画処理属性が再生可能となっていれば「１」を、再生不可能となっていれば「０」を返す。このように、この関数はエレメントの種別属性によりそれを表現するための適切な端末属性とを照合し、適合するか否かをブーリアン値で返す関数である。なお、サーバでの減色処理等の単純化処理やフォーマット変換処理などの加工により端末において取扱うことが可能になる場合には「１」を返す。入力となるエレメントを「ｘ」として、この関数を「Ｆｃａ（ｘ）」と表記する。
【０３４２】
図４８に、あるオブジェクトと、そのオブジェクトを取巻く環境との意味的な整合性に基づいて出力される値の大きさが変わる関数の一部を示す。この図によれば、この関数は、たとえばオブジェクトの種別属性が「電話帳」であった場合、そのオブジェクトを記憶するクライエント装置１０の種別属性が「電話機」であれば高い値を、電話以外の「端末」であれば低い値を返す。また、たとえばオブジェクトの種別属性が「スケジュール」であった場合、そのオブジェクトの時間属性が「未来」であれば高い値を、「過去」であれば低い値を返す。このように、この関数はオブジェクトの種別属性によりそのオブジェクトと関連する適切な属性や環境とを照合し、そのオブジェクトとそのオブジェクトを取巻く環境との意味的な整合性を返す関数である。入力となるオブジェクトを「Ｔ」として、この関数を「Ｆｃｃ（Ｔ）」と表記する。
【０３４３】
ここで、オブジェクトＴの重要度属性を取出す関数をＩｍｐ（Ｔ）と表現し、機会優先度をＯＰ＝Ｆｃｃ（Ｔ）・Ｉｍｐ（Ｔ）と定義する。本実施例では、これらの関数を用いて、マスタオブジェクトより、そのルートノードを含む部分集合のオブジェクトを、「seek a subset Tsub of {x∈T｜Fca(x)≠0} such that OP≒(C・Σsize(xof Tsub))/Sc」のようなアルゴリズムにより作成する。ここで、「Ｓｃ」は、たとえば通信料／通信量や通信速度といったオブジェクトを転送するクライエント装置１０の通信能力を表現する値である。「Size」は、エレメント「x」のサイズを取出す関数であり、単純化処理やフォーマット変換処理を行なう場合には、その処理を行なった後のサイズを返すものとする。「Ｃ」は、通信コストとオブジェクトの機会優先度とのバランスを調整する定数である。本実施例では、本アルゴリズムにより削除されるエレメントのうち、Ｆｃａ（ｘ）が「０」であるものは実際に削除して、Ｆｃａ（ｘ）が「１」であるものは、サーバ装置１へのリンクと置換えを行なう。なお所定の条件に対してはこの加工方法とは別に定められた加工方法を優先して実行するようにすることで、ユーザ個人の独特な要望や特殊な場合に対応可能にすることもできる。
【０３４４】
次に、伝播優先度をＰＰ＝ＯＰ・Ｎｔｆ（Ｔ，Ｄ）・Ａｃｔ（Ｄ）として定義する。ここで、関数「Ｎｔｆ」は、あるクライエント装置１０を例として、オブジェクトＴの最終更新を端末Ｄのユーザへ伝えたか否かを表わす関数であり、通知済みであれば「１」、未通知であれば「２」の値をとるものとする。関数「Ａｃｔ（Ｄ）」は、ある端末Ｄの活動状況を表わす関数であり、使用中であれば「２」を、使用中でなければ「１」の値をとるものとする。
【０３４５】
図４９に、この伝播優先度ＰＰの値とオブジェクトの処理との対応を示す。この図に示されるルールにより、機会優先度が高く最終更新が未通知のオブジェクトは、より多くの端末により早く伝播させ、特に使用中の端末に対しては早く伝播させることができる。なお、所定の条件に対してはこの伝播方法とは別に定められた伝播方法を優先して実行するようにすることで、ユーザ個人の独特な要望や特殊な場合に対応することができる。
【０３４６】
図５０に、端末でのオブジェクトの処理を規定するためのオブジェクトのユーザ通知属性、およびガーベージコレクション属性を生成するルールを示す。この図に示されるルールにより、機会優先度により端末におけるユーザ通知の強度およびガーベージコレクションの方針を得ることができる。なお、所定の条件に対してはこの処理方針とは別に定められた処理方針を優先して実行することで、ユーザ個人独特な要望や特殊な場合に対応することも可能である。
【０３４７】
なお、図３４の削除データ決定および削除処理を、図５１のように構造化されたオブジェクトの末端のエレメントから順にエレメント単位で行ない、削除処理として削除するエレメントをサーバ装置１のマスタオブジェクトの該当エレメントへのリンクへ交換するようにすると、オブジェクトの利用可能性が高くなり効果的である。
【０３４８】
今回開示された実施例はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【０３４９】
以上のように、このデータアクセスシステムによれば、クライアント装置は、データの更新を行ないサーバに通知する。サーバは、その更新されたデータを記憶しているクライアント装置に対してのみ、クライアント装置において記憶されたデータを更新する。そのため、ネットワークトラフィックを増加させることなく、クライアント装置は、実記憶容量よりもはるかに多い情報を利用することができる。そのため、この発明のデータアクセスシステムは、多くのユーザがデータを共用して使用するサーバ・クライアントシステムに適している。
【図面の簡単な説明】
【図１】 本発明の第１の実施例に係るデータアクセスシステムの構成を示すブロック図である。
【図２】 第１の実施例に係るデータサーバ装置の構成を示すブロック図である。
【図３】 第１の実施例に係るクライアント装置の構成を示すブロック図である。
【図４】 第１の実施例に係るクライアント装置の外観図である。
【図５】 第１の実施例に係るデータサーバ装置の全体的な動作のフローチャートである。
【図６】 第１の実施例に係るデータサーバ装置による他のクライアント装置への更新データの反映処理のフローチャートである。
【図７】 第１の実施例に係るデータサーバ装置による一般データの更新反映処理のフローチャートである。
【図８】 第１の実施例に係るクライアント装置の全体的な動作のフローチャートである。
【図９】 第１の実施例に係るクライアント装置におけるデータサーバ装置に起因するデータ更新処理のフローチャートである。
【図１０】 第１の実施例に係るクライアント装置におけるクライアント装置に起因するデータ更新処理のフローチャートである。
【図１１】 第１の実施例に係るクライアント装置によるサーバデータ更新処理のフローチャートである。
【図１２】 第１の実施例に係るサーバデータとクライアントデータの関係の一例を示す図である。
【図１３】 第１の実施例に係るデータサーバ装置におけるサーバデータの記憶形式の一例を示す図である。
【図１４】 第１の実施例に係るデータサーバ装置における端末データの記憶形式の一例を示す図である。
【図１５】 第１の実施例に係るデータサーバ装置におけるグループデータの記憶形式の一例を示す図である。
【図１６】 第１の実施例に係るクライアント装置より、データサーバ装置に記憶されているサーバデータを更新するために送信される、サーバデータ更新通知のフォーマットを示す図である。
【図１７】 第１の実施例に係るデータアクセスシステムでのデータの更新処理の一例を説明するための図である。
【図１８】 第１の実施例に係る住所録データの一例を示す図（その１）である。
【図１９】 第１の実施例に係る住所録データの一例を示す図（その２）である。
【図２０】 第１の実施例に係る住所録データの一例を示す図（その３）である。
【図２１】 第１の実施例に係る住所録データの一例を示す図（その４）である。
【図２２】 第１の実施例に係る住所録データの一例を示す図（その５）である。
【図２３】 第１の実施例に係る住所録データの一例を示す図（その６）である。
【図２４】 第１の実施例に係るデータアクセスシステムでのアルバムデータ更新処理の一例を説明するための図である。
【図２５】 第１の実施例に係るデータアクセスシステムでのメール送信処理の一例を説明するための図である。
【図２６】 第１の実施例に係るメール送信処理におけるサーバデータの一例を示す図である。
【図２７】 第１の実施例に係るメール送信処理におけるサーバデータの一例を示す図である。
【図２８】 第１の実施例に係るメール送信処理におけるサーバデータの一例を示す図である。
【図２９】 第１の実施例に係るメール送信処理におけるサーバデータの一例を示す図である。
【図３０】 第１の実施例に係るメール送信処理におけるサーバデータの一例を示す図である。
【図３１】 第１の実施例に係るメール送信処理におけるサーバデータの一例を示す図である。
【図３２】 第１の実施例に係るデータアクセスシステムでのチャット処理の一例を説明するための図である。
【図３３】 第１の実施例に係るデータアクセスシステムでのスケジュールデータ更新処理の一例を説明するための図である。
【図３４】 第１の実施例に係るクライアント装置における更新データの反映処理のフローチャートである。
【図３５】 第１の実施例に係るデータ削除処理時におけるクライアントデータの一例を示す図である。
【図３６】 本発明の第１の実施例に係るデータアクセスシステムの他の構成を示すブロック図である。
【図３７】 第１の実施例の第１の変形例に係るデータサーバ装置の全体的な動作のフローチャートである。
【図３８】 第１の実施例の第２の変形例に係るクライアント装置の全体的な動作のフローチャートである。
【図３９】 本発明の第２の実施例に係るサーバデータとクライアントデータの関係の一例を示す図である。
【図４０】 第２の実施例に係るデータサーバ装置におけるサーバデータの記憶形式の一例を示す図である。
【図４１】 第２の実施例に係るデータサーバ装置における端末データの記憶形式の一例を示す図である。
【図４２】 第２の実施例に係るデータサーバ装置を使用するユーザのユーザデータの記憶形式の一例を示す図である。
【図４３】 第２の実施例に係るデータサーバ装置に記憶される処理テーブルの記憶形式の一例を示す図である。
【図４４】 第２の実施例に係るデータサーバ装置に記憶される処理テーブルの記憶形式の一例を示す図である。
【図４５】 第３の実施例に係るデータサーバ装置におけるサーバデータ記憶部の内容を示す図である。
【図４６】 第３の実施例において構造化されたオブジェクトが伝播する様子を示す図である。
【図４７】 オブジェクトの更新処理を行なうためのテーブルおよびルールを示す図である。
【図４８】 オブジェクトの更新処理を行なうためのテーブルおよびルールを示す図である。
【図４９】 オブジェクトの更新処理を行なうためのテーブルおよびルールを示す図である。
【図５０】 オブジェクトの更新処理を行なうためのテーブルおよびルールを示す図である。
【図５１】 第３の実施例において構造化されたオブジェクトのエレメントが削除される様子を示す図である。

Claims (14)

1. 木構造を構成する要素の集合をサーバデータとして記憶するサーバデータ記憶部と、
   前記サーバデータのそれぞれとクライアント装置との対応関係と、各クライアント装置の表現能力を示す属性とを記憶するクライアント記憶データ管理部とを含み、
   前記サーバデータは、要素がどのような種類のデータであるかを示す種別属性を持つ要素およびユーザにより指定された重要度を示す重要度属性を持つ要素を含み、
   前記クライアント記憶データ管理部は、前記サーバデータ記憶部に記憶されたサーバデータが更新された場合に、前記サーバデータとクライアント装置との対応関係に基づき通知すべきクライアント装置を決定し、前記更新されたサーバデータの各要素の種別属性および重要度属性とクライアント装置の種別を含む属性とに基づき、前記木構造を構成する要素の集合の部分集合を選択して送信する、データサーバ装置。
2. さらに、ユーザが所属するグループおよび所有する端末装置を示すユーザの属性を記憶するユーザプロファイル記憶部を含み、
   前記クライアント記憶データ管理部による選択は、前記サーバデータに含まれる要素が持つ種別属性および重要度属性、クライアント装置の種別を含む属性、ユーザの属性のいずれかから導出される必要性に応じて行なわれる、請求項１に記載のデータサーバ装置。
3. 前記クライアント記憶データ管理部による選択において、要素の削除は、要素の実体の削除か、サーバ上の要素へのリンクの置換えのいずれかを、選択的に行なうことにより実現されることを特徴とする、請求項１または２に記載のデータサーバ装置。
4. 前記サーバデータは、ＸＭＬを用いて構造化されていることを特徴とする、請求項１〜３のいずれかに記載のデータサーバ装置。
5. 前記クライアント記憶データ管理部は、クライアント装置において記憶中のクライアントデータを更新するデータと、少なくとも要素の重要度属性、時間属性または端末属性に基づいて決定された、クライアントデータが更新されたことをユーザに通知する方法を表わす通知情報とを、前記対応関係に基づいて抽出されたクライアント装置に送信するように処理を決定する、請求項１〜４のいずれかに記載のデータサーバ装置。
6. 前記クライアント記憶データ管理部は、クライアント装置において記憶中のクライアントデータを更新するデータと、少なくとも要素の重要度属性、時間属性または端末属性に基づいて決定された、更新されたクライアントデータを消去する方法を表わす消去情報とを、前記対応関係に基づいて抽出されたクライアント装置に送信するように処理を決定する、請求項１〜４のいずれかに記載のデータサーバ装置。
7. 前記クライアント記憶データ管理部は、前記サーバデータに含まれる要素が持つ種別属性、重要度属性および前記クライアント装置の種別を含む属性に対応させて定められたアルゴリズムに基づいて、ユーザ通知の必要性およびガーベージコレクションの必要性を規定した機会優先度およびクライアントデータを伝播すべき時間および伝播すべきクライアント装置を規定した伝播優先度を算出し、算出された前記優先度に対応して、クライアントデータに対する処理を決定する、請求項１〜４のいずれかに記載のデータサーバ装置。
8. 前記クライアント記憶データ管理部は、クライアント装置へ送信される通信データを、構造化されたデータに含まれる複数の要素の中から要素を選択することにより、クライアントデータに対して処理するように決定する、請求項１〜４のいずれかに記載のデータサーバ装置。
9. データサーバ装置のサーバデータ記憶部に記憶されたサーバデータの一部または全部であるクライアントデータを記憶するクライアントデータ記憶部と、
   前記データサーバ装置から、更新されたクライアントデータと通知情報とを含む更新情報を受信する受信部と、
   前記クライアント装置のユーザに、クライアントデータが更新されたことを通知する通知部と、
   前記更新情報を受信すると、前記クライアントデータ記憶部に記憶されている当該データを前記更新情報に応じて更新するとともに、前記クライアントデータに含まれる要素がどのような種類のデータであるかを示す種別属性および重要度属性、前記クライアント装置の種別を含む属性、ユーザが所属するグループおよび所有する端末装置を示すユーザの属性のいずれかから導出される必要性に応じて、クライアントデータが更新されたことをユーザに通知する、あるいは通知しないように、前記クライアントデータ記憶部と前記通知部とを制御する制御部とを含み、
   前記受信部による前記更新情報により前記クライアントデータ記憶部の空き容量が不足した場合、前記クライアント装置は、クライアントデータの各要素の種別属性および重要度属性とクライアント装置の種別を含む属性とに基づき、前記クライアントデータ記憶部に記憶されたクライアントデータの要素を消去して、前記クライアントデータの要素が消去されたことに応答して、消去されたクライアントデータの要素に対応する前記データサーバ装置のマスタデータの当該要素へのリンク情報を設定する消去処理部をさらに含む、クライアント装置。
10. 前記クライアント装置は、前記クライアントデータ記憶部に記憶されたクライアントデータを、前記クライアントデータの各要素の種別属性および重要度属性、前記クライアント装置の種別を含む属性、ユーザが所属するグループおよび所有する端末装置を示す属性のいずれかから導出される必要性に応じて、段階的に消去する消去処理部をさらに含む、請求項９に記載のクライアント装置。
11. データサーバ装置のサーバデータ記憶部に記憶されたサーバデータの一部または全部であるクライアントデータを記憶するクライアントデータ記憶部と、
    前記データサーバ装置から、更新されたクライアントデータと消去情報とを含む更新情報を受信する受信部と、
    前記クライアントデータ記憶部と前記受信部とに接続され、前記受信部が受信した更新情報に含まれる更新されたクライアントデータを前記クライアントデータ記憶部に記憶するとともに、前記更新情報に含まれる消去情報に基づいて前記クライアントデータ記憶部に記憶されたクライアントデータを消去するように、前記クライアントデータ記憶部を制御する制御部とを含む、請求項９または１０に記載のクライアント装置。
12. 請求項１〜８のいずれかに記載のデータサーバ装置と、
    ネットワークを介して、前記データサーバ装置に接続された請求項９〜１１のいずれかに記載のクライアント装置とを含む、データアクセスシステム。
13. 木構造を構成する要素の集合をサーバデータとして記憶し、前記サーバデータのそれぞれとクライアント装置との対応関係と、各クライアント装置の表現能力を示す属性とを記憶するデータサーバ装置と、ネットワークを介して、前記データサーバ装置と接続され、前記サーバデータの一部または全部であるクライアントデータを記憶するクライアント装置とを含むデータアクセスシステムで用いられる、前記サーバデータと前記クライアントデータとのデータ同期方法であって、
    前記サーバデータは、要素がどのような種類のデータであるかを示す種別属性を持つ要素およびユーザにより指定された重要度を示す重要度属性を持つ要素を含み、
    前記クライアント装置が、前記クライアント装置に記憶されているクライアントデータが更新された際に、前記データサーバ装置にデータ更新の通知をするステップと、
    前記データサーバ装置が、前記クライアント装置からデータ更新の通知を受信すると、前記サーバデータとクライアント装置との対応関係に基づき通知すべきクライアント装置を決定し、前記更新されたサーバデータの各要素の種別属性および重要度属性とクライアント装置の種別を含む属性とに基づき、前記木構造を構成する要素の集合の部分集合を選択して送信するステップとを含む、データ同期方法。
14. コンピュータにデータサーバ機能を実現させるためのプログラムを記録したコンピュータ読取可能な記録媒体であって、前記プログラムは、前記コンピュータを、
    木構造を構成する要素の集合をサーバデータとして記憶するサーバデータ記憶手段と、
    前記サーバデータのそれぞれとクライアント装置との対応関係と、各クライアント装置の表現能力を示す属性とを記憶するクライアント記憶データ管理部として機能させ、
    前記サーバデータは、要素がどのような種類のデータであるかを示す種別属性を持つ要素およびユーザにより指定された重要度を示す重要度属性を持つ要素を含み、
    前記クライアント記憶データ管理部が、前記サーバデータ記憶部に記憶されたサーバデータが更新された場合に、前記サーバデータとクライアント装置との対応関係に基づき通知すべきクライアント装置を決定し、前記更新されたサーバデータの各要素の種別属性および重要度属性とクライアント装置の種別を含む属性とに基づき、前記木構造を構成する要素の集合の部分集合を選択して送信するよう機能させるためのプログラムである、コンピュータ読取可能な記録媒体。

Images