JP2002506254A - ファイルおよびその他の対象物を部分的に複製されたデータベースに付与する方法、装置、システム、およびプログラム製品 - Google Patents

Abstract

(57)【要約】 ファイルおよび他の対象物を分散形コンピュータ環境の中で添付すること。これは、ファイル添付、テキストデータ、ウェブファイルデータ、イメージファイルデータ等の非データベース対象物および他のファイル添付対象物をデータベースに追加することを包含する。このような対象物は、宛先であるノードの都合に応じて検索してよい。どの添付、どの対象物がノードによって見られるかを決める可視性の規則を設定することができる。対象物の分配の規則は、ノードが対象物を要請せねばならぬか否か、または、ノードが対象物を受け取るよう強制されるか否かを決定する。

Description

【発明の詳細な説明】

【０００１】 発明の分野 本発明は、テキストファイルデータ、ウェブファイルデータ、画像ファイルデ
ータ、およびその他のファイル添付の対象物等のファイル添付および非データベ
ースオブジェクトをデータベースに付加するデータベース管理システム、データ
ベース管理方法、データベース管理装置、およびデータベース管理プログラム製
品に関する。テキストデータ、ウェブベースデータおよびその他の対象物は、関
連するデータが検索されるときに検索されることができる。

【０００２】 発明の背景 関係のあるデータベースは、ビジネスその他の環境でデータを表すため広く採
用されているデータ構造である。関係のあるデータベースは、２次元表の集合の
形式によるデータを表す。各表は、行および列に配置された一連のセルからなる
。一般に、表中の行は特定の観測を表す。列はデータフィールドまたは別の表の
行へのポインタを表す。

【０００３】 例えば、組織構造を記述するデータベースは、組織の各地位を記述する1 つの
表と、組織の各従業員を記述する別の表を持つことができる。従業員表には、氏
名、従業員番号、年齢、給与等、従業員固有の情報を含むことができる。地位表
には、地位肩書き（「販売員」、「副社長」等）、給与範囲等、地位固有情報を
含むことができる。これらの表は、例えば、従業員表の各行に地位表の特定の行
へのポインタを設けて関連付け、従業員表の各行について、その従業員の地位を
記述する地位表の特定の行へのポインタがあるよう調整することができる。リレ
ーショナルデータベース管理システム（RDBMS ）は、ユーザからの問い合わせに
対応してこれら表の「結合」をサポートし、例えば特定の従業員について問い合
わせたユーザに、従業員表の情報だけでなく関連する地位表の情報を含む、選択
した従業員の報告書を与えることができる。

【０００４】 リレーショナルデータベースは、複数の表とその間の複数の関係を持つ、この
例よりはるかに複雑なものになることがある。さらに、テキストデータファイル
、画像データファイル、ウェブデータファイル等の他のオブジェクトをこのよう
なデータベースに付加することがしばしば望ましい。

【０００５】 安価なポータブルコンピュータの普及により、中央コンピュータから離れた場
所で参照するため、ポータブルコンピュータにデータベースを複製することが有
利である。そして、複製されたデータベースをポータブルコンピュータのユーザ
が参照できるが、その場合、中央データベースを参照する必要はなく、中央デー
タベースはポータブルコンピュータのユーザにとって不便な中央所在地に維持す
ることができる。しかしながら、複製データベースの利用には多数の困難がある
。

【０００６】 或る欠点は、中央データベースのフルコピーには、必要あるいは経済的以上の
データ保管が必要なことである。例えば、現場で働く販売員は、自分の販売エリ
アの販売商機に関連する情報のデータベースを参照する必要はあるが、自分のエ
リア以外の販売商機に関連する情報を参照する必要はない。

【０００７】 必要なデータ保管量を削減するアプローチとして、単にユーザが必要とするデ
ータベース部分のみ複製するというものが考えられる。しかし、このアプローチ
は、データのどの部分を必要とするかの判断基準が時間によって変化する可能性
がある点を認識していない。例えば、販売員は自分の領域に新しい都市を加える
ことがある。従来のアプローチでは、この販売員はデータベースの自分のローカ
ルコピーを再複製する必要があり、この時、加えた都市を含むデータを選択する
。このような慣行は不便でエラーが生じやすく、時間がかかる。

【０００８】 複製データベースの別の欠点は、複製コピーを使ってデータをアップデートし
ようとする時遭遇する困難である。複製データベースに加えられた変更は中央デ
ータベースには加えられず、データベースの複製コピーに保存された情報と中央
データベースに保存された情報との間に不一致が生じることになる。複製コピー
の修正を記録し、同一の修正を中央データベースに適用することは可能だが、こ
のアプローチにはアップデートの衝突という問題がある。すなわち、複製コピー
のユーザが、中央コピーのユーザ、または別の複製コピーのユーザによっても変
更されたデータを変更する場合である。

【０００９】 多くのデータベース管理システムのさらに別の欠点は、テキストデータファイ
ル添付、画像データファイル添付、ウェブベースデータファイル添付、および他
のオブジェクトをリレーショナルデータベースに付加する困難である。

【００１０】 そのため、複製の程度を複製データベース全体のリフレッシュの必要なく容易
に変更可能で、中央データベースのユーザおよび部分複製データベースのユーザ
間でアップデートを調整できるような方法で、中央データベースの1 個以上の部
分複製コピーを維持する機能を備えることが望ましい。データベースへのオブジ
ェクトの添付によるアップデートを可能にして、そのオブジェクトを関連するデ
ータアイテムと共に取り出せるようにすることが特に望ましい。

【００１１】 発明の目的 本発明の主要な目的は、デベロッパまたはコンフィグレータが選択するビジネ
スオブジェクトに、テキストデータファイル添付、画像データファイル添付、ウ
ェブベースデータファイル添付等を含むファイル添付をユーザが添付できるよう
にすることにある。

【００１２】 本発明の他の主要な目的は、ビジネスオブジェクトが見える全てのドッキング
クライアントにファイル添付を自動的に複製することにある。これは、ユーザが
データベースサーバまたはモバイルのファイルをアップデートして、全てのデー
タベースでファイルを同期できるようにするものである。

【００１３】 本発明のさらに他の主要な目的は、モバイルユーザがファイルのダウンロード
を延期し、これによって接続時間を最小限にすることにある。これによってモバ
イルユーザは延期したファイルを将来のドッキングセッションで要求することが
できる。

【００１４】 本発明のさらに他の主要な目的は、ファイル添付の作成、アップデートおよび
削除をサポートする予め定義された専門的なビジネスコンポーネントを持つソフ
トウェアプラットホームの提供にある。これにより、デベロッパおよびコンフィ
グレータが、この専門的ビジネスコンポーネントを用いるアプレットを作成し、
そのアプレットを付加することで、どのようなビジネスオブジェクトでも20個の
ファイル添付が容易に可能となる。

【００１５】 発明の概要 本発明のこれらのおよびその他の目的は、本発明の方法、システム、装置、お
よびプログラム製品により達成される。 そのため、本発明によると、ユーザはファイルやファイル添付などの非データ
ベースオブジェクトを、デベロッパまたはコンフィグレータが選択するビジネス
オブジェクトに添付することができる。本発明はさらに、ビジネスオブジェクト
が見える全てのドッキングクライアントにファイル添付（ａｔｔａｃｈｍｅｎｔ
ｓ）の自動複製を行うことができる。これによって、ユーザはデータベースサー
バまたはモバイルのファイルおよび関連非データベースオブジェクトおよび添付
をアップデートして、全てのデータベースでファイルを同期できる。

【００１６】 また、本発明の方法および装置を使って、モバイルユーザはファイルおよび関
連非データベースオブジェクトおよび添付のダウンロードを延期し、これにより
接続時間を最小限にすることができる。これにより、モバイルユーザは将来のド
ッキングセッションで延期したファイルを要求することができる。

【００１７】 また、本発明の方法、装置、システムおよびプログラム製品を使って、ファイ
ル添付および非データベースオブジェクトファイルの作成、アップデートおよび
削除をサポートする予め定義された専門的なビジネスコンポーネントを持つソフ
トウェアプラットホームを提供することができる。これにより、デベロッパおよ
びコンフィグレータが、この専門的ビジネスコンポーネントを用いるアプレット
を作成し、そのアプレットを付加することで、どのようなビジネスオブジェクト
でもファイル添付が容易に可能となる。

【００１８】 本発明の方法、装置、システムおよびプログラム製品は以下のファイル添付属
性を持つ。 複数バージョン。本発明の方法、装置、システムおよびプログラム製品によっ
て、ユーザはファイルに複数のバージョンを作ることができる。

【００１９】 あらゆるビジネスオブジェクトのファイル添付。本発明の方法、装置、システ
ムおよびプログラム製品によって、ユーザは、サービス要求、商機、見積り、契
約等を含むあらゆるビジネスオブジェクトにファイル添付を構成することができ
る。

【００２０】 本発明の方法、装置、システムおよびプログラム製品は、ユーザがあらゆるフ
ァイルを登録するビジネスオブジェクトツールを提供する。ビジネスオブジェク
トツールは、あるユーザが非データベースオブジェクトファイルまたはファイル
添付を登録し、他のユーザをファイルチームに追加できるようなオブジェクトフ
ァイルチームをサポートする。ファイルチームのユーザは全員が非データベース
オブジェクトファイルまたはファイル添付を見ることができる。非データベース
オブジェクトファイルまたはファイル添付は、チームの全ユーザに自動的に配布
される。

【００２１】 本発明の方法、装置、システムおよびプログラム製品は、次の機能を遠隔サポ
ートする。 本発明のシステム、装置、方法およびプログラム製品は、文献およびコレポン
テンプレートの配布をサポートする。これには、モバイルユーザが適切なスクリ
ーンまたはメニュー、スクリーンなどで文献を要求し、要求した文献を次のドッ
キングセッションでダウンロードできるようにし、公表されている文献およびコ
レポンテンプレートを配布することが含まれる。

【００２２】 本発明のシステム、方法、装置およびプログラム製品は、ファイル表の行と関
連するファイル添付または非データベースファイルオブジェクトを、ファイルに
対するビジビリティを持つドッキングクライアントに自動的に複製する。トラン
ザクションルータがファイル表行をルーチングするとき、さらに関連するファイ
ル添付または非データベースファイルオブジェクトに関する情報を好適なファイ
ルに書きこむ。ドッキングクライアントがファイル表行でトランザクションの送
信または取り出しを行う時、さらにそのファイル表の行について関連するファイ
ル添付または非データベースファイルオブジェクトを送信および取り出す。デー
タマージがデータベースにファイル表の行を適用する時、さらにそのファイルを
ローカルファイルシステムにコピーする。

【００２３】 実施例では、本発明のシステム、方法、装置またはプログラム製品は関連する
全てのファイルを地域データベースに複製する。

【００２４】 本発明の方法、装置、システムおよびプログラム製品は、行と列を持つ少なく
とも1 個のデータベース表を有するデータベースを管理する。行はデータベース
オブジェクトに対応し、列はオブジェクトの属性に対応する。属性は、非データ
ベースオブジェクトファイルまたはファイル添付を参照する。

【００２５】 エンドユーザによる使用の容易であること。エンドユーザは、ファイルを容易
に作成、アップデートおよび削除できる。さらに、ファイルは自動的にドッキン
グクライアントに複製される。管理しやすさ。本発明は、管理者がファイル添付
を登録する簡単な方法を提供する。

【００２６】 デベロッパおよびコンフィグレータは、予め構築された専門的ビジネスコンポ
ーネント、フレーム、およびアプレットを使って、容易にファイル添付を可能に
できる。このように、デベロッパおよびコンフィグレータは、ドラッグ・アンド
・ドロップ、ファイルのアップデート、競合解消等の標準機能を利用するのに新
しいコードを書く必要がない。

【００２７】 本発明の方法、装置、システムおよびプログラム製品によって、ユーザは、例
えばファイルシステムまたはウェブページに保存された外部ファイルをコピーす
ることで、ファイルを作成することができる。さらに、本発明の方法、装置、シ
ステムおよびプログラム製品は、オリジナルの外部ファイルから自動的にファイ
ルのコピーをアップデートすることができる。

【００２８】 本発明の方法、装置、システムおよびプログラム製品によって、異なるビジネ
スオブジェクトが同じファイルコピーを共有することができる。例えば、2 個の
サービス要求が同一のファイルを共有することができる。同様に、商機およびサ
ービス要求が同一ファイルを共有できる。

【００２９】 本発明の方法、装置、システムおよびプログラム製品は、ローカルのhtmlのフ
ァイルの添付をサポートする。Htmlのファイルはしばしば他のファイルを含むこ
とに注意する。

【００３０】 本発明の方法、装置、システムおよびプログラム製品によって、ユーザはどこ
でもファイルをアップデートすることができ（すなわち、サーバデータベースま
たはモバイルクライアントに接続している時）、ファイルに対するビジビリティ
を持つ全てのドッキングクライアントにアップデートしたファイルを複製するこ
とができる。ドッキングにより一意性を解決し、ファイルの競合をアップデート
し、全データベースの一貫性を保証する。

【００３１】 本発明の方法、装置、システムおよびプログラム製品は、ビジビリティルール
を使ってドッキングクライアントにファイルをルーチングする。さらに、本発明
の方法、装置、システムおよびプログラム製品は、どのファイルをどのノードに
転送するかを決定する堅牢なビジビリティルールセットをサポートする。これら
ビジビリティルールには、あるタイプの全ファイル（例えば公表文献）、ユーザ
選択ファイル（例えば文献の検索）、ビジブルオブジェクトに添付されたファイ
ル（例えば見積り、契約、サービス要求等への添付）の指定が含まれる。

【００３２】 本発明の方法、装置、システムおよびプログラム製品は、ファイルを関連する
データベーストランザクションと共に複製し、全てのドッキングのクライアント
についてトランザクションの統合性を保証する。

【００３３】 本発明の方法、装置、システムおよびプログラム製品は、モバイルのユーザに
ドッキングセッションでファイルのダウンロードを延期させ、ユーザがドッキン
グセッションの持続時間を短縮できるようにする。例えば、ファイルのダウンロ
ードを最大サイズ、一定ファイルタイプ等に制約する。ファイルのダウンロード
を延期できるのはモバイルのユーザのみである。地域データベースおよびサーバ
データベースは常に全ファイルを取得する。

【００３４】 本発明の方法、装置、システムおよびプログラム製品によって、モバイルユー
ザは延期したファイルを要求することができる。さらに、本発明の方法、装置、
システムおよびプログラム製品は、要求したファイルを次のドッキングセッショ
ンでダウンロードする。要求したファイルのダウンロードは迅速に行い、サーバ
データベースの負担になってはならない。ファイルを延期したら（すなわち、ロ
ーカルデータベースにファイルが存在すると述べる行があるが、実際のファイル
はモバイルクライアントにはない）、モバイルユーザは（何かをクリックするこ
とで）ファイルを要求し、本発明の方法、装置、システムおよびプログラム製品
は次のドッキングセッションでファイルを取り出す。

【００３５】 本発明の方法、装置、システムおよびプログラム製品によって、モバイルユー
ザはモバイルクライアントのローカルディスクから要求したファイルを削除し、
ディスク使用量を最小限にすることができる。

【００３６】 本発明の方法、装置、システムおよびプログラム製品は、例えば接続したユー
ザとモバイルユーザ両方等、異なるデータソースからのファイルアクセスをサポ
ートする。この場合、サーバはどのファイルが利用可能でどのファイルがそうで
ないかを区別できなければならない。

【００３７】 本発明のシステム、方法、装置およびプログラム製品は、ドッキングクライア
ントを抽出および初期化する時、データばかりでなくファイルも初期化しなけれ
ばならない。

【００３８】 本発明のシステム、方法、装置およびプログラム製品は、モバイルクライアン
トばかりでなく地域データベースにもファイルを配布する。これには、ドッキン
グクライアントからサーバデバイスおよびその逆へのファイルのルーチングが含
まれる。

【００３９】 本発明によると、ユーザは一貫したユーザインターフェース（すなわちファイ
ル添付アプレット）を使ってファイルの作成、アップデートおよび削除を行う。
デベロッパおよびコンフィグレータは、あらゆる既存オブジェクトにファイル添
付アプレットを追加することができる。また、ニーズに合わせてファイル添付行
動を強化または上書きできる。

【００４０】 ユーザが新しいデータエントリまたはファイルを作成するとき、本発明のクラ
イアント機能は、表にファイルに関する情報を保存する行を挿入する。これらフ
ァイル表は、名称、サイズ、オリジナルソース（ソースファイルのタイプおよび
フル経路名等）およびファイルのドッキングステータスを含むファイル情報を保
存する。デベロッパおよびコンフィグレータは、各ファイル添付アプレットにフ
ァイル表を作成しなければならない。

【００４１】 クライアントの機能はまた、ファイルシステムに内部名でファイルのコピーを
保存する。データベース管理システムは、ディスク使用量を削減するため、圧縮
フォーマットで各ファイルを保存しなければならない。接続したユーザについて
は、ファイルシステムはファイルサーバのディレクトリの集合で、これは、例え
ばコンフィグレーションファイル等、ファイルの値で指定する。モバイルユーザ
については、ファイルシステムは一般にモバイルクライアントのローカルディス
ク、一般には例えばクライアントインストールディレクトリ等好適なディレクト
リに常駐する。

【００４２】 ユーザがファイルにアクセスすると、クライアントは（圧縮されている場合）
ファイルを解凍してファイルシステムからテンポラリディレクトリにコピーし、
ファイルを表示して編集するための適切なプログラム（例えばMicrosoft Word）
を呼び出す。ユーザがファイルを修正すると、クライアントはファイル表中のフ
ァイル情報をアップデートし、修正したファイルをテンポラリディレクトリから
ファイルシステムにコピーする。

【００４３】 本発明のシステム、方法、装置およびプログラム製品によって、モバイルユー
ザは選択したファイルおよび関連ファイル、ファイル添付、および非データベー
スファイルオブジェクトのダウンロードを延期して接続時間を最小限にすること
ができる。モバイルユーザは、例えばファイル同期ダイアログボックスのような
コントロールファイルでドッキングセッションの好みを設定し、延期したいファ
イルを指定する。例えば、モバイルユーザが10K より大きいファイルのダウンロ
ードを延期したいとする。モバイルユーザがファイルを表示するスクリーンにナ
ビゲートすると、クライアントは各ファイルが存在するか、ファイルが存在しな
いか、またはファイルがローカルのファイルのシステムでアウト・オブ・デート
かを表示する。

【００４４】 本発明のシステム、方法、装置およびプログラム製品によってモバイルユーザ
は、以前に延期したか、アウト・オブ・ デートなファイルを要求することができ
る。そして、本発明のシステム、方法、装置またはプログラム製品は、次のドッ
キング・セッションでファイルのアップ・トゥ・デートなコピーを取り出す。

【００４５】 本発明のシステム、方法、装置およびプログラム製品によって、同時アクセス
およびトランザクション・セマンチックをサポートする改訂を利用することがで
きる。 本発明のシステム、方法、装置およびプログラム製品によって、ルーチングお
よび競合解消ルールと異なるファイル添付をどのように延期するか制御するルー
ルを利用することができる。

【００４６】 本発明の方法、装置、構造、システムおよびプログラム製品は、本書に添付す
る図面を参照することで理解される。

【００４７】 詳細な説明 本発明の方法、装置、システムおよびプログラム製品により、複製または部分
的複製データベースの個々のユーザは、例としてテキストデータファイル添付、
画像データファイル添付およびウェブベースファイルデータ添付を含むファイル
、非データベースファイルオブジェクト、ファイル添付等を、ユーザ、デベロッ
パまたはコンフィグレータが選択するあらゆるビジネスオブジェクトに添付する
ことができるようになる。これは、ファイル添付の作成、アップデートおよび削
除をサポートする予め定義された専門ビジネスコンポーネントを持つソフトウェ
アプラットホームを使って達成する。このソフトウェアプラットホームによって
、ユーザ、デベロッパおよびコンフィグレータは、この専門ビジネスコンポーネ
ントを利用するアプレットの作成、追加および/ または利用によってあらゆるビ
ジネスオブジェクトに容易にファイル添付することができる。エンドユーザ、デ
ベロッパおよびコンフィグレータは、予め構築した専門ビジネスコンポーネント
、フレームおよびアプレットを使って、容易にファイル添付が可能である。

【００４８】 このようなやりかたで、エンドユーザ、デベロッパおよびコンフィグレータは
、ドラッグ・アンド・ドロップ、ファイルのアップデート、競合解消等標準機能
を利用するのに新しいコードを書く必要がない。非データベースファイルオブジ
ェクトまたはファイル添付は、データベース表の属性コラムまたはデータベース
表の属性フィールドまたは行のセルで参照されるオブジェクトである。ファイル
添付は、このような参照により呼び出し可能または取り出し可能またはアドレス
指定可能であるが、データベース表にはない。

【００４９】 例として挙げると、非データベースファイルオブジェクトまたはファイル添付
は、パンフレット、会報等のテキストファイル、画像ファイル（MPEG、JPEG、ビ
ットマップ等）、URL 、サウンドファイルまたはアプリケーションである。

【００５０】 ファイル添付はさらに、ビジネスオブジェクトに対する可視性を持つ全てのド
ッキングクライアントへのファイル添付の自動複製を含む。これによって、ユー
ザはあらゆるデータベースサーバまたはモバイルでファイルをアップデートでき
、全てのデータベース間でファイルを同期できる。

【００５１】 図1 は、接続されたユーザのためのファイル作成を示す。図示のように、ユー
ザはクライアントスクリーンで新しいファイルを作る。このファイルは圧縮され
、ファイルシステムとローカルファイルキャッシュにコピーされる。そしてファ
イル表の行に書き込まれ、トランザクションがデータベースに記録される。

【００５２】 特に、図1 は、接続されたユーザのためのファイル作成を示す。図示のように
、ユーザはクライアントスクリーンで新しいファイルを作る。このファイルは圧
縮され、ファイルシステムとローカルファイルキャッシュにコピーされる。そし
てファイル表の行に書き込まれ、トランザクションがデータベースに記録される
。図1 に示す本発明のある一面は、ローカルファイルキャッシュをサポートする
コンフィグレーションファイルの変更の実施である。

【００５３】 クライアントは、ファイルアクセスパフォーマンスを改善するために自動的に
ローカルファイルキャッシュを維持する。図1 のように、ユーザがファイルを見
てファイルサーバにアクセスする時は常に、クライアントはまずローカルファイ
ルキャッシュからファイルを開いてから、ファイルサーバからファイルを読み取
ろうとする。ユーザはローカルファイルキャッシュを管理することができる（ウ
ェブブラウザと同じ）。ユーザは、現在、ローカルディスクにキャッシュされて
いるファイルのリストを見て、キャッシュの最大サイズを制御し、ローカルディ
スクスペースを回復するためキャッシュから全てのファイルを削除することがで
きる。ローカルファイルキャッシングをサポートするコントロールファイルの変
更は図3 にも示す。

【００５４】 図2 は、接続されたユーザがどのようにファイルを見て修正するかを示す。ユ
ーザは、例えばダブルクリックによって既存ファイルを選択する。これにより、
ファイルは必要に応じてローカルファイルキャッシュにコピーされる。そしてこ
のファイルは解凍され、テンポラリディレクトリにコピーされる。ファイルがユ
ーザ修正の場合、ユーザ修正ファイルは圧縮され、ファイルシステムとローカル
ファイルキャッシュに再びコピーされる。修正ファイルとトランザクションがデ
ータベースに書き込まれる。

【００５５】 専門フレームおよびビジネスコンポーネントは、オリジナルファイルまたはフ
ァイル添付が変更された場合、ユーザがファイル添付のコピーをアップデートで
きる「アップデートリンク」方法を提供する。

【００５６】 ユーザが既存ファイル添付を表示すると、本発明のデータベース管理システム
はファイルシステムからファイル添付を解凍してテンポラリディレクトリにコピ
ーする。そして、本発明のデータベース管理システムはファイル添付を表示およ
び編集するための適切な手順またはプログラムを呼び出す。ユーザがファイル添
付を修正すると、本発明のデータベース管理システムはファイル表のファイル添
付情報をアップデートして、修正したファイル添付をテンポラリディレクトリか
らファイルシステムへコピーする。

【００５７】 ユーザがファイル表の行を削除すると、本発明のデータベース管理システムは
そこで参照されているファイル添付をファイルシステムから自動的に削除し、フ
ァイル表の行をデータベースから削除する。

【００５８】 クライアントは、ファイルアクセスパフォーマンスを改善するために自動的に
ローカルファイルキャッシュを維持する。図1 のように、ユーザがファイルを見
てファイルサーバにアクセスする時は常に、クライアントはまずローカルファイ
ルキャッシュからファイルを開いてから、ファイルサーバからファイルを読み取
ろうとする。ユーザはローカルファイルキャッシュを管理することができる（ウ
ェブブラウザに類似する）。ユーザは、現在、ローカルディスクにキャッシュさ
れているファイルのリストを見て、キャッシュの最大サイズを制御し、ローカル
ディスクスペースを回復するためキャッシュから全てのファイルを削除すること
ができる。

【００５９】 ビジネスオブジェクトのファイルを管理できる能力を追加することで、デベロ
ッパまたはエンドユーザは専門フレームとビジネスコンポーネントをビジネスオ
ブジェクトに追加することができる。デベロッパは専門フレームとビジネスコン
ポーネントから下位に分類し、追加機能性を加えることができる。

【００６０】 図3 に、ローカルファイルキャッシングをサポートするコンフィグレーション
ファイルとしてのコントロールファイルの変更を示す。

【００６１】 図4 に、ファイルとトランザクションの取り出しとモバイルクライアントへの
適用を示す。図示のように、トランザクションルータはトランザクションとファ
イル添付を適切なファイルに書き込む。ドッキングクライアントはファイルをク
ライアントのインボックスに取り出し、またサーバからファイルを取り出す。フ
ァイルがクライアントのインボックスに存在すると、これはローカルクライアン
トのインボックスにコピーされる。そうでない場合、ファイルを例えば次のセッ
ションで取り出す要求が提出される。トランザクションがローカルデータベース
に適用され、ファイルの状態がアップデートされる。

【００６２】 .ｄｘファイルをドッキングサーバからモバイルクライアントへ取り出す時、
ドッキングクライアントは各 .ｄｘファイルについて関連するファイルも取り出
す。ドッキングクライアントは、ファイルの内部名（<ROW ID> <extension>等）
を使って関連するファイルをドッキングクライアントのインボックスディレクト
リに書きこむ。ドッキングクライアントは、インボックスディレクトリに既にフ
ァイルが存在しないか、サイズまたはアップデート日付が異なる場合のみファイ
ルを取り出す。これは、補遺7 の冗長転送に説明する。

【００６３】 ドッキングクライアントはある種のファイルのダウンロードを延期することが
できる。ドッキングクライアントはTOC ファイルを読み取ってどのファイルをダ
ウンロードしどのファイルを延期するかを決定する。

【００６４】 モバイルユーザは、本発明のデータベース管理システム中のファイル添付ダウ
ンロードを含むファイルダウンロードの好みを設定する。

【００６５】 高度ダイアログボックスでは、モバイルユーザはどのファイルおよびファイル
添付を延期するかを複数の方法で指定できる。

【００６６】 各ビジネスオブジェクトについて取り出しファイルフラグを指定する。値がイ
エスの場合、ドッキングクライアントはこのビジネスオブジェクトに関連するフ
ァイルを取り出す。しかし、値がノーの場合、ドッキングクライアントはこのビ
ジネスオブジェクトに関連するファイルをすべて延期するが、行の延期フラグが
イエスに設定されている場合を除く。

【００６７】 各ビジネスオブジェクトについて、ユーザは最大サイズ未満かこれに等しいフ
ァイルを取り出すため最大ファイルサイズを指定する。本発明のデータベース管
理システムは、「ある拡張を持つ全てのファイルを取り出す」、ファイル名など
、追加基準も設ける。各ビジネスオブジェクトについて、本発明のデータベース
管理システムは、ファイル表行のドックオブジェクトインスタンスの最低ビジビ
リティ強度を指定する。本発明のデータベース管理システムは、ドックオブジェ
クトインスタンスが最低ビジビリティ強度より大きいかこれに等しい場合にファ
イルを取り出す。本発明のデータベース管理システムは、ドックオブジェクトイ
ンスタンスが最低ビジビリティ強度より小さい場合にファイルを取り出さない。

【００６８】 ファイル表の各行について、延期フラグを用いることができる。そのため、値
がイエスの場合、ドッキングクライアントはファイル取得を延期できる。しかし
、値がノーの場合、ドッキングクライアントは、ユーザがこのビジネスオブジェ
クトについてはファイルを取り出さないか、最大サイズより大きいファイルは取
り出さないと指定していても、常にこのファイルを取り出さなければならない。

【００６９】 これらオプションは、ドッキングクライアントまたはローカルデータベース内
、あるいはサーバデータベースに複製するノードタイプの表にファイルとして保
存することができる。

【００７０】 複製エージェントは常に全てのファイルを取り出し、地域データベースのファ
イルシステム上の全てのファイルがアップ・トゥ・デートであるようにする。複
製エージェントは地域データベースのファイルのダウンロードを延期することは
できない。

【００７１】 図5 は、モバイルクライアントからのファイルおよびトランザクションの送信
と適用を示す。ここでは、ドッキングクライアントはファイルをクライアントの
アウトボックスに書き込み、ファイルをクライアントのインボックスに送信する
。ドッキングクライアントはローカルファイルシステムのファイルもクライアン
トのインボックスに送る。マージ機能はファイルサーバのファイルに適用され、
トランザクションマネージャはトランザクションをサーバデータベースに適用す
る。 本発明のデータベース管理システムは次のファイル表行のあるファイルを送信
する。

【００７２】 サーバに送る .ｄｘファイルを作る時、ドッキングクライアントは関連ファイ
ルを一覧するTOC ファイルも作る。TOC ファイルには、ドッキングクライアント
が .ｄｘファイルをサーバデータベースに送るときにアップロードしなければな
らないファイルリストが入っている。各ファイルについて、TOC ファイルはファ
イル名、ファイルサイズ、目標ディレクトリ、モバイルクライアントがファイル
のダウンロードを延期できるか否か、ファイル表名、ファイル表行のROW IDを一
覧する。

【００７３】 モバイルクライアントからドッキングサーバへ .ｄｘファイルを送信する時、
ドッキングクライアントは各 .ｄｘファイルの関連ファイルも送信する。ドッキ
ングクライアントは各 .ｄｘファイルに関連するTOC ファイルを読み取り、どの
関連ファイルをドッキングサーバに送るか決定する。ドッキングサーバは関連フ
ァイルをドッキングクライアントのインボックスディレクトリに書き混む。

【００７４】 モバイルユーザはドッキングサーバへのファイルの送信を延期することはでき
ない。ドッキングクライアントは常に各 .ｄｘファイルの関連ファイル全てをド
ッキングサーバに送る。

【００７５】 地域データベースからドッキングサーバへ .ｄｘファイルを送信する時は、地
域データベースは各 .ｄｘファイルの関連ファイルも送信する。 図6 に、ファイルドック状態の状態図を示す。これは、存在せず、存在、アウ
ト・オブ・ デートの3 つの状態を状態間のトランザクションと共に示す。

【００７６】 ファイル表の行にトランザクションを適用する時、データマージはドッキング
クライアントのインボックスディレクトリから目標ディレクトリへファイルをコ
ピーすることによって関連ファイルを適用する。

【００７７】 データマージは、これらルールを使ってFILE DOCK STATE FLAGの値をアップデ
ートする。データマージは常にサーバまたは地域データベースで「E 」（ファイ
ル存在）に状態を設定する。

【００７８】 ファイルは成功的に適用され、値を「E 」（ファイルは存在する）に設定する
。ファイルが存在しない場合。ファイルがインボックスディレクトリに存在しな
い場合、値を「N 」に設定する。ファイルがローカルファイルシステムに存在し
、古い値が「E 」の場合、値を「O 」（アウト・オブ・デート）に設定する。延
期されたファイルで、その FILE DEFER FLG が「P 」（モバイルクライアントは
ファイルを持っていなければならない）に設定されている場合、データマージは
次のドッキングセッションでファイルを取り出す要求を自動的に提出する。デー
タマージは、延期され、FILE DEFER FLGが「R 」（モバイルユーザはファイルを
明示的に要求しなければならない）に設定されているファイルには要求を提出し
ない。

【００７９】 図7 は、本発明の実施例によるファイル添付の専門フレームのスクリーン図で
ある。エディットリンクは「名称」、「ソース」、「サイズ」および「タイムス
タンプ」で、アクションは「リンク切断」、「ソースからアップデート」および
「ソース変更」に「OK」と「キャンセル」である。

【００８０】 図8 は、ファイル転送とマージの概要を、ファイルf ．s01 を持つサーバ、お
よびファイルf ．s01 のローカル複製を持つクライアントA およびB の図で示す
。補遺5 は図8 を詳細に参照する。

【００８１】 図9 は、クライアントA がローカルファイルf ．a0も持ち、クライアントB が
ローカルファイルf ．b0を持つ図8 のシステムの概要である。補遺5 は図8 を詳
細に参照する。

【００８２】 本発明はデータベースの管理方法で、行と列を持つ少なくとも1 つのデータベ
ース表を有する。データベース表の各行はデータベースオブジェクトに対応し、
各列はオブジェクトの属性に対応する。属性の1 つは、非データベースオブジェ
クトファイルを参照する。

【００８３】 さらに、非データベースオブファイルは、例えば、URL アドレス、テキストフ
ァイル、画像ファイル、サウンドファイル、実行ファイルまたはその組み合わせ
である。

【００８４】 ノードとユーザは、中央データベースで非データベースオブジェクトを作成、
削除およびアップデートすることができる。

【００８５】 本発明の他の１つの観点において、非データベースオブジェクトのノードへの
配布は、ノードが非データベースオブジェクトを受信することを選択するまで延
期できる。例として、モバイルユーザは非データベースオブジェクトのダウンロ
ードを延期して、接続時間を最小限にし、将来のドッキングセッションまでダウ
ンロードをセーブすることができる。

【００８６】 1 個以上の非データベースオブジェクトファイルがデータベースに存在するこ
とができ、ノードに配布されることができる。ノードは、中央データベースで非
データベースオブジェクトファイルを作成、削除およびアップデートすることが
できる。これらオブジェクトファイルのノードへの配布は、ノードがファイルの
受信を選択するまで延期することができる。

【００８７】 非データベースオブジェクトファイルの条件を指定することができ、条件を満
たした場合のみノードに配布される。

【００８８】 さらに、非データベースオブジェクトファイルのノードへの配布は、ノードが
非データベースオブジェクトファイルを要求し、非データベースオブジェクトフ
ァイルへのビジビリティを持つ場合にのみ、非データベースオブジェクトファイ
ルがノードに配布されるよう制御することができる。

【００８９】 また、非データベースオブジェクトファイルのアップデートは全てのノードと
ファイルのコピーを持つ部分的複製データベースに配布される。 ファイルがノードの設定した規則を満足する場合のみノードで非データベース
オブジェクトファイルを受信するようノードで規則を設定することができる。

【００９０】 非データベースオブジェクトファイルは、ファイルがノードの設定したルール
を満足しない場合でも、ノードにファイル受信を強制し、ノードにブロードキャ
ストできる。ブロードキャストされた非データベースオブジェクトファイルは、
そのファイルへのビジビリティを持つノードにのみ配布することもできる。非デ
ータベースオブジェクトファイルは、ノードの要求によってのみノードが利用可
能とすることができる。また、配布ルールは、配布ルールが満たされた場合のみ
ファイルがノードに配布されるようファイルについて設定することができる。こ
れらのルールの例には、あるタイプまたはサイズのファイルのみ受信が含まれる
。

【００９１】 非データベースファイルオブジェクトはファイル添付であることができる。ノ
ードは、データベースでファイル添付を作成、削除およびアップデートすること
ができる。

【００９２】 ファイル添付のノードへの配布は、ノードがファイル添付の受信を選択するま
で延期することができる。 ファイル添付に1 個以上の条件を指定することができ、条件を満たした場合の
みファイル添付をノードに配布する。

【００９３】 本発明の他の１つの実施例では、ノードがファイル添付を要求し、そのファイ
ル添付へのビジビリティを持つ場合のみ、ファイル添付をノードに配布すること
ができる。

【００９４】 ファイル添付のアップデートは全てのノードとファイル添付のコピーを持つ部
分的複製データベースに配布される。 ファイル添付がノードの設定したルールを満足する場合のみ、ノードでファイ
ル添付を受信するようノードでルールを設定することができる。

【００９５】 ブロードキャストファイル添付は、ファイル添付がノードの設定したルールを
満たさない場合でも、ファイル添付の受信をノードに強制して、ノードに配布す
ることができる。

【００９６】 ファイル添付を配布ルールが満たされた場合にのみノードに配布するよう、フ
ァイル添付に配布ルールを設定することができる。

【００９７】 エンドユーザは、ファイル添付を容易に作成、アップデートおよび削除するこ
とができる。これには、例えばファイルシステムまたはウェブページに保存した
外部ファイルのコピーが含まれる。さらに、本発明の方法、装置、システムおよ
びプログラム製品は、オリジナルの外部ファイルからファイルのコピーを自動的
にアップデートできる。この機能のある側面は、ユーザが、サービス要求、商機
、見積り、契約等を含むあらゆるビジネスオブジェクトでファイル添付を容易に
構成できることである。エンドユーザはまた、ファイルの複数バージョンを作成
することができる。

【００９８】 さらに、ファイル添付はドッキングクライアントに自動的に複製される。これ
により、異なるビジネスオブジェクトがファイルの同一コピーを共有することが
できる。例えば、2 つのサービス要求が同一ファイルを共有することができる。
同様に、商機とサービス要求が同一ファイルを共有することができる。

【００９９】 本発明の他の１つの観点は、あらゆるファイル添付を登録するためのビジネス
オブジェクトツールのユーザへの提供である。ビジネスオブジェクトは、あるユ
ーザがファイルを登録し、他のユーザをファイルチームに追加するようファイル
チームをサポートする。ファイルチームの全ユーザはファイルを見ることができ
る。このファイルは自動的にチームの全ユーザに配布される。

【０１００】 本発明の方法、装置、システムおよびプログラム製品は、文献およびコレポン
テンプレートまたはファイル添付の配布のリモートサポートを提供する。これに
は、モバイルユーザが適切なスクリーンまたはメニュー、スクリーンなどで文献
を要求し、要求した文献を次のドッキングセッションでダウンロードできるよう
にし、公表されている文献およびコレポンテンプレートを配布することが含まれ
る。

【０１０１】 本発明の他の１つの観点は、ファイル添付のリモートアップデートをサポート
する。これは、個々のユーザがあらゆる場所で（すなわち、サーバデータベース
またはモバイルクライアントに接続されながら）ファイルをアップデートする権
限を与えることで達成し、アップデートファイルをそのファイルへのビジビリテ
ィを持つ全ドッキングクライアントに複製する。ドッキングで一意性が解消され
、ファイルの間の競合をアップデートし、データベース全体の一貫性が保証され
る。

【０１０２】 本発明の方法、装置、システムおよびプログラム製品は、ビジビリティルール
を使ってドッキングクライアントにファイルをルーチングする。

【０１０３】 さらに、本発明の方法、装置、システムおよびプログラム製品は、どのファイ
ルをどのノードに送るかを決定するビジビリティルールの堅牢なセットをサポー
トする。これらビジビリティルールには、あるタイプの全ファイル（例えば公表
文献）、ユーザ選択ファイル（例えば文献取り出し）、ビジブルオブジェクトに
添付されたファイル（例えば見積り、契約、サービス要求等への添付）の指定が
含まれる。

【０１０４】 これらはすべて、データの整合性を維持しながら達成される。本発明の方法、
装置、システムおよびプログラム製品は、ファイルとその関連するデータベース
トランザクションを複製して、全てのドッキングクライアントにトランザクショ
ンの整合性を保証する。

【０１０５】 ダウンロードは延期あるいはオンデマンドで行うことができる。例えば、モバ
イルユーザはドッキングセッションでファイルダウンロードを延期して、ユーザ
がドッキングセッションの持続時間を短縮できるようにできる。例えば、ファイ
ルのダウンロードを最大サイズ、あるファイルタイプ等に制約する。モバイルユ
ーザのみがファイルダウンロードを延期できる。地域データベースおよびサーバ
データベースは常に全ファイルを取得する。あるいは、モバイルユーザは延期し
たファイルを要求することができる。延期したダウンロードの場合、要求したフ
ァイルは次のドッキングセッションでダウンロードされる。要求したファイルの
ダウンロードは迅速に行い、サーバデータベースの負担になってはならない。フ
ァイルを延期したら（すなわち、ローカルデータベースにファイルが存在すると
述べる行があるが、実際のファイルはモバイルクライアントにおいては利用可能
ではない）、モバイルユーザは（何かについてクリックすることにより）ファイ
ルを要求し、次のドッキングセッションでファイルが送られる。

【０１０６】 接続時間と通信帯域幅を短縮するため、モバイルユーザは選択したファイルの
ダウンロードを延期して接続時間を最小限にすることができる。モバイルユーザ
は、例えばファイル同期ダイアログボックスのようなコントロールファイルでド
ッキングセッションの好みを設定し、延期したいファイルを指定する。例えば、
モバイルユーザが10K より大きいファイルのダウンロードを延期したいとする。
モバイルユーザがファイルを表示するスクリーンにナビゲートすると、クライア
ントは各ファイルが存在するか、ファイルが存在しないか、またはファイルがロ
ーカルファイルシステムでアウト・オブ・デートかを表示する。さらに、モバイ
ルユーザは以前に延期したかアウト・ オブ・デートであるファイルを要求し、ダ
ウンロードすることができる。そして、次のドッキングセッションでファイルの
アップ・ トゥ・ デートなコピーを取り出す。

【０１０７】 モバイルユーザをさらにサポートするため、本発明の方法、装置、システムお
よびプログラム製品では、モバイルユーザはモバイルクライアントのローカルデ
ィスクから要求したファイルを削除し、ディスク使用量を最小限にすることがで
きる。

【０１０８】 モバイルユーザが多数いる状況では、クライアントコンフィグレーションは必
然的に複数となる。本発明の方法、装置、システムおよびプログラム製品は、例
えば接続したユーザとモバイルユーザ両方等、異なるデータソースからのファイ
ルアクセスをサポートする。本発明のシステム、方法、装置およびプログラム製
品は、モバイルクライアントだけでなく地域データベースにファイルを配布する
。これには、ドッキングクライアントからサーバデータベースへ、およびその逆
へのファイルのルーチングを含む。

【０１０９】 これらの状況において、サーバはどのファイルをダウンロードできるか、どの
ファイルができないかを区別する。 本発明のシステム、方法、装置およびプログラム製品は、ドッキングクライア
ントを抽出、初期化する時、データだけでなくファイルを初期化する。

【０１１０】 ユーザが新しいファイルを作ると、本発明のクライアント機能は、ファイルに
関する情報を保存する表に行を挿入する。これらファイル表は、名称、サイズ、
オリジナルソース（ソースファイルのタイプおよびフル経路名等）およびファイ
ルのドッキングステータスを含むファイル情報を保存する。デベロッパおよびコ
ンフィグレータは、各ファイル添付アプレットにファイル表を作成しなければな
らない。

【０１１１】 クライアント機能はまた、ファイルシステムに内部名でファイルのコピーを保
存する。データベース管理システムは、ディスク使用量を削減するため、圧縮フ
ォーマットで各ファイルを保存できる。接続したユーザについては、ファイルシ
ステムはファイルサーバのディレクトリの集合で、これは、例えばコンフィグレ
ーションファイル等、ファイルの値で指定する。モバイルユーザについては、フ
ァイルシステムは一般にモバイルクライアントのローカルディスク、一般には例
えばクライアントインストールディレクトリ等好適なディレクトリに常駐する。

【０１１２】 ユーザがファイルにアクセスすると、クライアントは（圧縮されている場合）
ファイルを解凍してファイルシステムからテンポラリディレクトリにコピーし、
ファイルを表示して編集するための適切なプログラム（Microsoft Word等）を呼
び出す。ユーザがファイルを修正すると、クライアントはファイル表中のファイ
ル情報をアップデートし、修正したファイルをテンポラリディレクトリからファ
イルシステムにコピーする。

【０１１３】 ファイル表の行と関連するファイルが、ファイルへのビジビリティを持つドッ
キングクライアントに複製される。トランザクションルータがファイル表の行を
ルーチングする時、関連ファイルに関する情報も好適なファイルに書き込む。ド
ッキングクライアントがファイル表の行でトランザクションを送信または取り出
すと、ファイル表の行の関連ファイルも送信および取り出しを行う。データマー
ジがファイル表の行をデータベースに適用する時、そのファイルをローカルファ
イルシステムにもコピーする。

【０１１４】 好適な例示において、本発明のシステム、方法、装置またはプログラム製品は
関連ファイルを全て地域データベースに複製する。 アプリケーションの視点からは、ファイル使用はトランスペアレントである。
ファイルはビジネスオブジェクト（サービス契約、見積書、製品等）の一部であ
る。ビジネスオブジェクトが複数のファイルをサポートする場合、ビジネスオブ
ジェクトの各インスタンスについて複数のファイルを保存するファイル表を持っ
ていなければならない。

【０１１５】 ユーザは次の方法の1 つを使ってファイルを作成できる。 ピックリストまたは関連リストを使ってデータベースに登録した既存ファイル
をコピーする。

【０１１６】 ドラッグ・アンド・ドロップを使って（E メールを含む）新しいファイルを作
成する。 適切なアプリケーション（Microsoft Word等）を呼び出して新しいファイルを
作成する。

【０１１７】 コレポンマネージャまたは報告機能を含む高度テンプレート/ マージ機能を使
って新しいファイルを作成する。 クライアントは、ファイルシステムにソースファイルをコピーし、新しいファ
イルのファイル表の行を作る。

【０１１８】 ユーザは選択したファイルをダブルクリックして、ファイルの表示と編集を行
う。クライアントは適切なプログラムを呼び出してファイルシステムからファイ
ルを読み取り、そのファイルを表示する。

【０１１９】 デベロッパが削除をエネイブルにすると、ユーザは既存ファイルを削除するこ
とができる。クライアントはファイルシステムからファイルを削除する。 接続されるユーザのためにファイルをキャッシュする。

【０１２０】 ファイルサーバにアクセスできるユーザに関して、ファイルアクセス性能を改
善するために、クライアントは、ファイルアタッチメントを含むファイルを、フ
ァイルサーバから、ユーザのローカルディスク上のローカルファイルキャッシュ
に自動的にコピーする。接続ユーザが常にファイルサーバにアクセスできるべき
であるということに留意されたい。

【０１２１】 移動ユーザは、一般的にローカルディスク上のローカルファイルシステムにア
クセスするが、その代わりに（例えば、インターネットを使用して）ファイルサ
ーバにアクセスすることを選択することが可能である。ユーザがファイルを閲覧
する時には常に、クライアントは、ファイルサーバからファイルを読み出す前に
、まず最初にローカルファイルキャッシュからファイルを開こうとする。

【０１２２】 ユーザは（ウェブブラウザと同様に）ローカルファイルキャッシュを管理する
ことが可能である。接続ユーザは、ローカルディスク上に現在キャッシングされ
ているファイルのリストを閲覧し、そのキャッシュの最大サイズを操作し、ロー
カルディスク容量を回復させるためにそのキャッシュから全ファイルを削除する
。

【０１２３】 本発明は、当該ファイルに対して可視性を有する全てのドッキングクライアン
トに対してファイルアタッチメントを含むファイルを自動的に複製する。移動ユ
ーザは、ファイルおよびファイルアタッチメントを複製するために何もする必要
はない。本発明のデータベース管理システムは、ドッキングクライアント上のロ
ーカルファイルシステムにファイルおよびファイルアタッチメントをコピーする
。移動クライアントに関しては、このローカルファイルシステムがそのクライア
ントのルートディレクトリ下に残る。領域内データベースに関しては、ローカル
ファイルシステムのルートディレクトリが、適切な環境変数または関数を使用し
て指定される。

【０１２４】 本発明は、接続時間を最小化するために、指定されたファイルおよびファイル
アタッチメントのダウンロードを移動ユーザが据え置くことを可能にする。ユー
ザは、各ドッキングセッションでダウンロードすべきファイルおよびファイルア
タッチメントのタイプと個数とを次のように指定することが可能である。

【０１２５】 ファイルサイズ。本発明の方法と装置とシステムとプログラム製品とが、ある
特定のサイズよりも小さいかまたは大きいファイルおよびファイルアタッチメン
ト（例えば、１０Ｋ未満のサイズのファイル）だけをダウンロードするように制
御されることが可能である。

【０１２６】 ファイル拡張子。本発明の方法と装置とシステムとプログラム製品とが、ある
特定のファイル拡張子（例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｏｒｄ文書、ビットマ
ップ、ＪＰＥＧファイル、ＭＰＥＧファイル、テキストファイル、サウンドファ
イル、実行可能ファイル等）が付いているかまたは付いていないファイルおよび
ファイルアタッチメントだけをダウンロードする。

【０１２７】 ファイルタイプ。本発明の方法と装置とシステムとプログラム製品とが、ある
特定のビジネスオブジェクトに関するファイルおよびファイルアタッチメント（
例えば、取引価格（Ｑｕｏｔｅｓ）に関するファイルであるが、サービス契約（
Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔｓ）に関するファイルでない）をダウンロード
する。

【０１２８】 移動クライアントの場合には、このクライアントは各々のファイルおよびその
ファイルアタッチメントの状態を表示する。このドック状態は、ファイルが存在
するかどうか、ファイルが陳腐化しているかどうか、または、ローカルファイル
システム上にファイルが存在しないかどうかを表示する。ファイルが陳腐化して
いる場合、または、ファイルが存在しない場合には、移動ユーザは、その次のド
ッキングセッションにおいてファイルの現在コピーを検索する要求を提出するこ
とが可能である。ファイルおよびそのファイルアタッチメントを最新の状態に保
つために、要求されているファイルに対する全アップデートを本発明が検索すべ
きかどうかを、移動ユーザは指定することが可能である。ファイルまたはそのフ
ァイルのアタッチメントが存在する場合、または、陳腐化している場合には、移
動ユーザは、ディスク使用を減少させるためにローカルファイルシステムからそ
のファイルを除去することが可能である。ユーザは、その次のドッキングセッシ
ョンの前に、要求をキャンセルすることが可能である。

【０１２９】 アドミニストレータの手順 アドミニストレータは、ファイルシステムを格納するためにファイルサーバを
提供する必要がある。接続ユーザ全員がファイルシステムに対してアクセスでき
なければならない。ファイルを生成し更新し削除することが可能なユーザは、フ
ァイルシステムに対して読み書きが可能でなければならない。ファイルを閲覧す
ることしか必要でないユーザは、ファイルシステムに読み取りアクセスできる必
要がある。

【０１３０】 ファイルシステムは、さらに、ドッキングクライアントに関するトランザクシ
ョンを経路指定し受け取る全てのアプリケーションサーバに対してアクセス可能
でなければならない。サーバの構成要素、すなわち、ドッキングサーバ（Ｄｏｃ
ｋｉｎｇ Ｓｅｒｖｅｒ）、トランザクションマージャ（Ｔｒａｎｓａｃｔｉｏ
ｎ Ｍｅｒｇｅｒ）、トランザクションルータ（Ｔｒａｎｓａｃｔｉｏｎ Ｒｏ
ｕｔｅｒ）、および、データベース抽出（Ｄａｔａｂａｓｅ Ｅｘｔｒａｃｔ）
は、ファイルシステムに対する読み書きが可能でなければならない。

【０１３１】 システムアドミニストレータは、データベースへのファイルのコピーとデータ
ベースからのファイルのコピーとを容易に行うためにクライアントを利用するこ
とが可能である。クライアントは、サーバ内にファイルのセットを生成するため
にアドミニストレータにドラッグアンドドロップを使用させる。クライアントは
、さらに、既存のファイルをそのリンクから更新するためのボタンを提供する。
デベロッパの手順 デベロッパ（ｄｅｖｅｌｏｐｅｒｓ）は、ファイルアタッチメントを格納する
ための新たなテーブルを作成しなければならない。各々のファイルテーブルは、
各ファイルアタッチメントに関する情報を格納するために必要な追加の列のセッ
トを含まなければならない。

【０１３２】 デベロッパは、基本的なファイル機能性を提供する専用ビジネスコンポーネン
ト（およびフレーム）を使用する（または、下位分類する）新たなアプレットを
作成しなければならない。この専用ビジネスコンポーネントは、３つのプロシー
ジャ、すなわち、（）ＣＳＳＢＣＡｔｔａｃｈ、ＣＳＳＢＣＦｉｌｅＲｅｑ、お
よび、ＣＳＳＢＣＤｏｃｋＲｅｑの組合せである。この専用ビジネスコンポーネ
ントは、ビジネスコンポーネントユーザ特性（Ｂｕｓｉｎｅｓｓ Ｃｏｍｐｏｎ
ｅｎｔ Ｕｓｅｒ Ｐｒｏｐｅｒｔｉｅｓ）によって制御され、したがって、デ
ベロッパは、他の特殊なオペレーションを自分が行う必要がなければ、この専用
ビジネスコンポーネントを下位分類する必要はないはずである。

【０１３３】 次いで、デベロッパは、ファイルアタッチメントを実行可能にするために、新
たなアプレットを既存のビジネスオブジェクトに付加する。

【０１３４】 高レベルのアーキテクチャ ファイルシステム ファイルシステムは、サーバ内に登録されている参照ファイルを格納するディ
レクトリ構造である。これは、ファイルアタッチメントを参照するか、呼び出す
か、指示する列エントリを有することが可能なファイルに関係する。全ファイル
が格納され、圧縮され、かつ、ファイルテーブル行のＲＯＷ＿ＩＤ値によって命
名される。ファイルシステムをレイアウトすることが可能な方法が幾つかある。

【０１３５】 選択１：フラットディレクトリ。フラットディレクトリでは、参照ファイルの
全てが単一のディレクトリ内に格納される。これは実現が容易であるが、オペレ
ーティングシステムが、単一のディレクトリ内に格納可能なファイルの個数を制
限するかも知れない。

【０１３６】 選択２：ファイルタイプによるディレクトリ内へのファイルのハッシング。ハ
ッシングでは、各ファイル拡張子毎に１つのディレクトリの形で、多数のディレ
クトリがファイルシステム内に作成される。ファイルシステム内のファイルを読
み書きする時には、各プログラムがファイルを適切なファイルタイプディレクト
リに格納する。ハッシングでは、ファイルが多数のディレクトリの中に分散させ
られる。しかし、ファイルはディレクトリの中に不均一に分布させられる。

【０１３７】 選択３：ファイル名によるディレクトリ内へのファイルのハッシング。ファイ
ル名によるハッシングでは、ファイルシステム内に多数のディレクトリが作成さ
れる（例えば、ａ、ｂ、ｃ、．．．、ｚと命名された２６個のディレクトリ）。
ファイルシステム内のファイルを読み書きする時には、各プログラムがＲＯＷ＿
ＩＤ値にハッシュ関数を適用し、ファイルがどのディレクトリ（すなわち、ハッ
シュバケット）に存在するかを決定する。ファイル名によるハッシングでは、フ
ァイルが多数のディレクトリ中に分散させられ、これによって、ディレクトリ内
のファイル数に対する制限を回避する。しかし、ファイル名によるハッシングの
欠点は、格納可能なファイルの合計数が依然として有限である（しかし、単一の
フラットディレクトリの２６倍である）ということである。 ファイルのアタッチメントを構成し使用する

【０１３８】 本発明の方法と装置とシステムとプログラム製品は、ビジネスオブジェクトに
ファイルを添付するための、使いやすく構成しやすい標準的なユーザインタフェ
ースを提供する。

【０１３９】 ファイルを格納するための、ビジネスオブジェクトに固有のテーブルを作成す
るために、デベロッパは、ファイルアタッチメントを必要とするあらゆるビジネ
スオブジェクトのためのファイルテーブルを作成する。例えば、機会（Ｏｐｐｏ
ｒｔｕｎｉｔｉｅｓ）、取引価格（Ｑｕｏｔｅｓ）、および、サービス契約（Ｓ
ｅｒｖｉｃｅ Ａｇｒｅｅｍｅｎｔｓ）がファイルアタッチメントを必要とする
場合には、デベロッパは、３つのテーブル、すなわち、Ｓ＿ＯＰＴＹ＿ＦＩＬＥ
Ｓ＿ＱＵＯＴＥ＿ＦＩＬＥと、Ｓ＿ＳＲＶ＿ＲＥＱ＿ＦＩＬＥとを作成する。

【０１４０】 各ファイルテーブルは、ファイルに関する情報を格納するための１組の列（各
列は事前定義された名称を有する）を有する。 ファイルサイズ。ファイルシステム内のファイルのサイズ。

【０１４１】 ファイル日付。ファイルシステム内でファイルが最後に更新された日付と時刻
。 ファイル接尾語。ファイルの接尾語（例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｏｒｄ
文書の場合には「．ｄｏｃ」であり、プレーンテキストファイルの場合には「．
ｔｘｔ」である）。

【０１４２】 内部ディレクトリ名。ファイルシステム内でのファイルのディレクトリ名。こ
の名称はファイルシステムのルートディレクトリに関係している。 ソースファイルタイプ。オリジナルファイルのタイプ。例えば、ユーザがオペ
レーティングシステムからファイルをコピーする時、データベース管理システム
内に既に登録されている別のファイルからファイルをコピーする時、または、Ｗ
ＷＷページからファイルをコピーする時。さらに、ユーザは、Ｄｏｃｕｍｅｎｔ
ｕｍのような他のデータ販売会社からファイルをコピーしてもよい。

【０１４３】 ソースファイル名。オリジナルファイルの名称。オペレーティングシステムの
ファイルの場合には、これは、オリジナルファイルへの全パス名を格納する。Ｗ
ＷＷページの場合には、これはウェブページのＵＲＬを格納する。ファイルの場
合には、これは、ファイルシステム内のファイルとディレクトリの内部名称を格
納する。

【０１４４】 据置き（ｄｅｆｅｒ）のフラグ。ファイルが同報通信されているかどうか（移
動ユーザは常にファイルをダウンロードしなければならない）、ファイルが公開
されているかどうか（移動ユーザはファイルを持たなければならないが、ダウン
ロードを据え置くことが可能である）、または、ファイルが要求可能であるかど
うか（移動ユーザがファイルを明示的に要求しなければならないかどうか）を表
示する。このフラグは移動クライアントだけに適用される。

【０１４５】 要請（ｒｅｑｕｅｓｔ）のフラグ。その次のセッションでファイルを検索する
要求かどうかを表示する。このフラグは移動クライアントだけに適用される。 ドック状態のフラグ。ファイルが存在するかどうか、ファイルが存在するが陳
腐化しているかどうか、または、ローカルファイルシステム内にファイルが存在
しないかどうかを表示する。このフラグは移動クライアントだけに適用される。

【０１４６】 自動更新のフラグ。システムがファイルのアップデートを検索すべきかどうか
を表示する。このフラグは移動クライアントだけに適用される。 ファイルの改訂（ｒｅｖｉｓｉｏｎ）。ファイルを改訂すること。ユーザがフ
ァイルを更新する毎にリビジョンが変化する。２人のユーザが同じファイルを奪
い合うことを防止するために、各々のリビジョンに独特なｉｄが与えられる。

【０１４７】 デベロッパはリポジトリにファイルテーブルを登録し、したがって、本発明の
データベース管理システムは、これらのテーブル内の各行が関連ファイルを有す
ることを認識する。これを付録１に示す。

【０１４８】 共有ファイルを格納するためにデータベーステーブルを作成する 本発明のデータベース管理システムは、あらゆるタイプのファイルを格納する
ためにファイルビジネスオブジェクトを使用する。顧客は、ファイルをユーザに
配布するためにこのテーブルを使用することが可能である。ビジネスオブジェク
トは、ファイルヘッダと、ファイル属性を格納するためのテーブルと、どのユー
ザがファイルにアクセスできるかを示すためのチームテーブル（ｔｅａｍ ｔａ
ｂｌｅ）とを含む。ビジネスオブジェクトは、どの移動クライアントがどのファ
イルを取得するかを決めるために可視性規則を有する。これを付録２に示す。

【０１４９】 本発明のさらなる観点は、ビジネスオブジェクト内のファイルを閲覧し管理す
るための画面である。デベロッパがファイルを共有することを好む場合には、デ
ベロッパは、自分のファイルテーブルを作成する代わりに、自分のビジネスオブ
ジェクトからファイルビジネスオブジェクトへの交差テーブルを作成することが
可能である。例えば、デベロッパは、各々の機会に関するファイルを格納するた
めに機会テーブルを作成する代わりに、機会ファイルテーブル内のファイルと機
会を関連付ける交差テーブルを作成することが可能である。デベロッパは、さら
に、移動ユーザにとって可視的である機会によってファイルが使用される場合に
機会ファイル行が可視的であるということを記述する可視性規則を機会ファイル
テーブルに加える必要があるだろう。これを付録３に示す。

【０１５０】 本発明のさらなる観点は、ユーザがファイルアタッチメントを作成し維持し閲
覧するための整合性のある方法を提供することである。これは、ファイルアタッ
チメントを操作するための専用のフレームおよびビジネスコンポーネントを必要
とする。専用フレームおよびビジネスコンポーネントは、ユーザがファイルアタ
ッチメントを作成、編集および削除することを可能にし、さらに、ドラッグアン
ドドロップをサポートし、それによって、ユーザはファイルマネジャーからファ
イルをドラッグして、そのファイルをデータベースの中にドロップすることが可
能である。

【０１５１】 ユーザはデータベース内に新たなファイルアタッチメントを作成する複数の方
法を有する： 「外部」ファイルから新たなファイルアタッチメントを作成する。ユーザは、
ファイルシステム上に既に存在するファイルを指示することによって、新たなフ
ァイルを作成する。こうしてＤｏｃｕｍｅｎｔｕｍ等のような他の記憶場所内の
ファイルを参照することが可能である。

【０１５２】 既存ファイルまたは既存ファイルアタッチメントから新たなファイルアタッチ
メントを作成する。ユーザは、データベース内に既に存在するファイルまたはフ
ァイルアタッチメントを指定することによって、新たなファイルアタッチメント
を作成する。

【０１５３】 ゼロから新たなファイルアタッチメントを作成する。ユーザは、ファイルアタ
ッチメントを作成するためにプログラム（例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｏｒ
ｄ）を呼び出すことによって新たなファイルアタッチメントを作成する。これは
、例えばＭｉｃｒｏｓｏｆｔまたはファイルブラウズダイアログによって行われ
るように、オブジェクトＵＩを挿入することを含んでよい。

【０１５４】 ユーザが新たなファイルアタッチメントを作成する時には、本発明のデータベ
ース管理システムはオリジナルのファイルアタッチメントのコピーを作成して、
このファイルアタッチメントをファイルシステム内に格納する。ファイルシステ
ムは、ディスク使用を減少させるために圧縮ファイルアタッチメントを格納して
もよく、および、格納することが好ましく、新たなファイルを「＜ＲＯＷ＿ＩＤ
＞．拡張子」と命名し、ここで、ＲＯＷ＿ＩＤはファイルテーブル行のＲＯＷ＿
ＩＤ値であり、拡張子はそのファイルのオリジナルの拡張子である（例えば、Ｍ
ｉｃｒｏｓｏｆｔ Ｗｏｒｄの場合にはｄｏｃ）。

【０１５５】 本発明のデータベース管理システムは、さらに、ファイルアタッチメントが得
られるオリジナルのファイルの全パス名またはソースを格納してもよい。 本発明のさらなる観点は、本発明のデータベース管理システム内に既に存在す
るファイルアタッチメントを更新することが可能であることである。専用フレー
ムおよびビジネスコンポーネントが、オリジナルのファイルまたはファイルアタ
ッチメントが変更される場合にユーザにファイルアタッチメントのコピーを更新
させる「アップデートリンク（ｕｐｄａｔｅ ｌｉｎｋ）」手法を実現する。

【０１５６】 ユーザが既存のファイルアタッチメントを閲覧するとき、本発明のデータベー
ス管理システムは、ファイルシステムからのファイルアタッチメントを解凍して
、一時ディレクトリにコピーする。その次に、本発明のデータベース管理システ
ムは、ファイルアタッチメントを表示して編集するために、適切なプロシージャ
またはプログラムを呼び出す。ユーザがファイルアタッチメントを変更する場合
には、本発明のデータベース管理システムは、ファイルテーブル内のそのファイ
ルアタッチメント情報を更新し、変更されたファイルアタッチメントを一時ディ
レクトリからファイルシステムにコピーする。

【０１５７】 ユーザがファイルテーブル行を削除するとき、本発明のデータベース管理シス
テムは、ファイルシステム内で参照されるファイルアタッチメントをファイルシ
ステムから自動的に削除し、データベースからファイルテーブル行を削除する。

【０１５８】 クライアントは、ファイルアクセス性能を向上させるためにローカルファイル
キャッシュを自動的に維持する。図１に示すようにユーザがファイルを閲覧して
ファイルサーバにアクセスする時にはいつでも、クライアントは、ファイルサー
バからファイルを読み出す前に、最初にローカルファイルキャッシュからファイ
ルを開こうと試みる。ユーザは（ウェブブラウザと同様に）ローカルファイルキ
ャッシュを操作することが可能である。ユーザは、ローカルディスク上に現在キ
ャッシングされているファイルのリストを閲覧し、キャッシュの最大サイズを調
整し、ローカルディスク容量を回復するためにそのキャッシュから全ファイルを
削除することが可能である。

【０１５９】 ビジネスオブジェクト内のファイルを管理する能力を付加するために、デベロ
ッパまたはエンドユーザは、ビジネスオブジェクトに専用フレームおよびビジネ
スコンポーネントとを加えてもよい。デベロッパは、追加の機能性を付加するた
めに、専用フレームおよびビジネスコンポーネントから下位分類することが可能
である。

【０１６０】 図１は、接続ユーザの場合のファイル作成を示す。この図に示すように、ユー
ザはクライアント画面内で新たなファイルを作成する。このファイルは圧縮され
て、ファイルシステムとローカルファイルキャッシュとにコピーされる。その次
にファイルテーブル行が書き込まれ、トランザクションがデータベースにログさ
れる。図１に示す本発明の一側面は、ローカルファイルキャッシュをサポートす
るためのコンフィグレーションファイルに対する変更の実装である。 ファイルを複製する 基本的に、ファイルアタッチメントはファイルテーブル行に付加される。ファ
イルテーブル行に関するトランザクションは、本発明のデータベース管理システ
ムが複製することが必要なファイルを表す。ファイルテーブル行上のトランザク
ションを送受する時には、本発明はさらに、トランザクションが参照するファイ
ルをローカルインボックス中にダウンロードすることを含む。

【０１６１】 移動クライアントにトランザクションを適用（併合）する時には、本発明のデ
ータベース管理システムは、ディレクトリ構造内の適正な場所にファイルを移動
させる。本発明がトランザクションを適用しない（すなわち、コンフリクトであ
る）場合には、本発明は、ファイルを適正な場所に移動させることなしにファイ
ルをインボックスから取り除く。

【０１６２】 現在のアーキテクチャがトランザクションの代わりにを .ｄｘファイルダウン
ロードするので、トランザクション経路指定プログラムが各々の .ｄｘファイル
に関する補助的な目録（ＴＯＣ）を構築する。このＴＯＣファイルは、そのトラ
ンザクションによって参照されるファイルをリストする。ソースにおいては、Ｔ
ＯＣファイルはオリジナルのファイルに対する参照を含む。宛先においては、Ｔ
ＯＣファイルは、インボックスディレクトリ内に格納されている一時ファイルに
対する参照を含む。ＴＯＣファイル内のファイルは、 .ｄｘファイル内のファイ
ルテーブル行トランザクションによって要求される通りにリストされる。これを
付録４に示す。

【０１６３】 付録４に示すこのアーキテクチャは、対応するファイルテーブル行に対する更
新もある限り、（クライアントまたはサーバからの）ファイルアタッチメントに
対するアップデートをサポートする。クライアントからのプログラムの呼出しの
後にファイルアタッチメントが変更される場合に、これらの更新が自動的に生じ
る。あるいは、ディレクトリ構造が定期的に走査され、ファイルアタッチメント
が変更されたように見える場合には、アップデートが作成されることが可能であ
る。

【０１６４】 移動クライアントに関する据え置きダウンロード特徴を付加することは、追加
のシステムの機能を要求するドッキングクライアントは、移動ユーザが据え置き
たいと望むファイルをフィルタリングによって取り除くことが可能でなければな
らない。クライアントは、幾つかのファイルが存在しないかまたは陳腐化してい
ることをユーザに表示しなければならない。最後に、ユーザは、紛失したファイ
ルまたは陳腐化したファイルの更新コピーを得ることが可能でなければならない
。 ユーザがファイルおよびファイルアタッチメントを作成し、更新し、および削除
するようにさせる。

【０１６５】 移動ユーザまたは接続ユーザはいずれも、本発明のデータベース管理システム
内において、新たなファイルアタッチメントを作成し、既存のファイルアタッチ
メントを更新し、または、既存のファイルアタッチメントを削除することが可能
である。ユーザは、ファイルを作成、更新または削除するためにクライアントを
使用することが可能である。ファイルアタッチメントが変更される時にはいつで
も、クライアントはファイルアタッチメントのサイズと日付を更新し、ファイル
更新回数を増分し、ドッキングトランザクションログ中に更新トランザクション
をログする。

【０１６６】 ファイルアタッチメントの転送と併合とリビジョンとの管理を付録５で説明し
、図８と図９とに示す。 ファイルをファイルテーブル上のトランザクションについてルート操作する 本発明のデータベース管理システムは新たなファイルまたは更新されたファイ
ルを宛先の全てに複製する。本発明のデータベース管理システムは、関連したフ
ァイルテーブル行と共にファイルを経路指定する。各々のファイルテーブルはそ
れ自体のドックオブジェクトに関連付けられており、ドックオブジェクトに関す
る可視性規則を使用する。例えば、機会がドッキングクライアントに可視である
場合には、移動ユーザは、機会に関する機会行を含むその機会に関する全ての行
を得る。例えば、移動ユーザがファイルチーム上に存在する（すなわち、Ｓ＿Ｆ
ＩＬＥ＿ＰＯＳＴＮ）場合には、この移動ユーザはＳ＿ＦＩＬＥ内の行を得る。
Ｓ＿ＦＩＬＥを付録６で説明する。

【０１６７】 ファイルテーブル行を経路指定するとき、本発明のデータベース管理システム
はその行を .ｄｘファイルに書き込み、さらに、 .ｄｘファイルに関するＴＯＣ
ファイルに関連したファイルに関する情報を書き込む。このＴＯＣファイルは、
ドッキングクライアントが .ｄｘファイルをリモートデータベースに転送する時
にダウンロードしなければならないファイルのリストを含む。各ファイル毎に、
ＴＯＣファイルが図６に示す次の情報をリストする。

【０１６８】 移動クライアントに関しては、ドッキングクライアントは常にドッキングサー
バに更新済みファイルを送る。領域内データベースに関しては、複製エージェン
トが常に更新済みファイルをドッキングサーバに送る。サーバデータベースに関
しては、トランザクション経路指定プログラムが、更新済みファイルを含むファ
イルテーブル行上の更新トランザクションを、「トランザクションを伴うファイ
ルの検索」に対して可視性を有するドッキングクライアントに送る。

【０１６９】 ドッキングサーバから移動クライアントに .ｄｘファイルを検索するとき、ド
ッキングクライアントは、さらに、各々の .ｄｘファイルに関する関連ファイル
を検索する。ドッキングクライアントは、ファイルの内部名称（例えば、＜ＲＯ
Ｗ＿ＩＤ＞．＜拡張子＞）を使用して、関連ファイルをドッキングクライアント
のインボックスディレクトリ内に書き込む。ファイルが既にインボックスディレ
クトリ内に存在していない場合、または、異なったサイズを有するか日付が更新
されている場合にだけ、ドッキングクライアントはファイルを検索する。これは
付録７の冗長転送において説明される。

【０１７０】 ドッキングクライアントは特定のファイルのダウンロードを据え置くことが可
能である。ドッキングクライアントは、どのファイルをダウンロードすべきか、
および、どのファイルを据え置くべきかを決定するために、ＴＯＣファイルを読
み取る。

【０１７１】 移動ユーザは、本発明のデータベース管理システム内のファイルアタッチメン
トダウンロードを含むファイルダウンロードに関する基本設定を設定する。 拡張ダイアログにおいて、移動ユーザは、どのファイルおよびファイルアタッ
チメントを据え置くべきかを指定する複数の方法を有する。

【０１７２】 各々のビジネスオブジェクトに関して、ユーザは検索ファイルフラグを指定す
る。その値がｙｅｓならば、ドッキングクライアントは、このビジネスオブジェ
クトに関連したファイルを検索する。しかし、その値がｎｏならば、行の据え置
きフラグがｙｅｓに設定されている場合を除いて、ドッキングクライアントは、
このビジネスオブジェクトに関連した全ファイルを据え置く。

【０１７３】 各々のビジネスオブジェクトに関して、ユーザは、最大サイズ以下のファイル
を検索するために最大ファイルサイズを指定する。本発明のデータベース管理シ
ステムは、さらに、「特定の拡張子を有するファイル全てを検索する」、ファイ
ル名等のような追加の基準を提供する。各々のビジネスオブジェクトに関して、
本発明のデータベース管理システムは、ファイルテーブル行のドックオブジェク
トインスタンス（ｄｏｃｋ ｏｂｊｅｃｔ ｉｎｓｔａｎｃｅ）の最小の可視性
の強さを指定する。本発明のデータベース管理システムは、ドックオブジェクト
インスタンスが最小可視性強さ以上である場合に、ファイルを検索する。本発明
のデータベース管理システムは、ドックオブジェクトインスタンスが最小可視性
強さよりも小さい場合には、ファイルを検索しない。

【０１７４】 ファイルテーブル内の各行に関して、据置きフラグを使用することが可能であ
る。したがって、この値がｙｅｓである場合には、ドッキングクライアントはフ
ァイルの取得を据え置くことが可能である。しかし、この値がｎｏである場合に
は、ユーザがこのビジネスオブジェクトに関してファイルを検索しないと指定し
ている場合にさえ、または、ファイルが最大ファイルサイズよりも大きい場合に
さえ、ドッキングクライアントは常にこのファイルを検索しなければならない。

【０１７５】 これらのオプションを、ドッキングクライアント上、ローカルデータベース内
、または、サーバデータベースに複製されるノードタイプのテーブル内にファイ
ルとして格納してもよい。

【０１７６】 複製エージェントは、常に、領域内データベースのファイルシステム上の全フ
ァイルが最新のものであることを確保するために全ファイルを検索する。複製エ
ージェントは、領域内データベースに対するファイルのダウンロードを据え置く
ことが不可能である。 ファイルをトランザクションと共に送る 本発明のデータベース管理システムはファイルをファイルテーブル行と共に送
る。

【０１７７】 サーバに送るために .ｄｘファイルを作成する時には、ドッキングクライアン
トが、関連ファイルをリストするＴＯＣファイルも作成する。ＴＯＣファイルは
、ドッキングクライアントが .ｄｘファイルをサーバデータベースに転送する時
に更新されるべきファイルのリストを含む。各ファイルに関して、ＴＯＣファイ
ルはファイル名、ファイルサイズ、ターゲットディレクトリ、移動クライアント
がファイルダウンロードを据え置くことが可能かどうか、ファイルテーブル名、
および、ファイルテーブル行のＲＯＷ＿ＩＤをリストする。

【０１７８】 移動クライアントからドッキングサーバに .ｄｘファイルを送るとき、ドッキ
ングクライアントは、各 .ｄｘファイルに関する関連ファイルも送る。ドッキン
グクライアントは、どの関連ファイルをドッキングサーバに送るべきかを決める
ために、各 .ｄｘファイルに関連したＴＯＣファイルを読み出す。ドッキングサ
ーバは関連ファイルをドッキングクライアントのインボックスディレクトリに書
き込む。

【０１７９】 移動ユーザは、ドッキングサーバへのファイルの送出を据え置くことが不可能
である。ドッキングクライアントは常に各 .ｄｘファイルに関する関連ファイル
全てをドッキングサーバに送る。

【０１８０】 .ｄｘファイルを領域内データベースからドッキングサーバに送るとき、領域
内データベースは各 .ｄｘファイルに関する関連ファイルも送る。 トランザクションをともないファイルを適用する ファイルテーブル行にトランザクションを適用するとき、データ併合（Ｄａｔ
ａ Ｍｅｒｇｅ）が、ドッキングクライアントのインボックスディレクトリから
ファイルをターゲットディレクトリにコピーすることによって関連ファイルを適
用する。

【０１８１】 データ併合は、これらの規則を使用してＦＩＬＥ＿ＤＯＣＫ＿ＳＴＡＴ＿ＦＬ
Ｇの値を更新する。データ併合は常にサーバデータベースまたは領域内データベ
ース上において、状態を「Ｅ」（ファイルが存在する）に設定する。

【０１８２】 ファイルは成功的に適用される。値を‘Ｅ’（ファイルは存在する）に設定す
る。ファイルが存在しない場合は、ファイルがインボックスディレクトリ内に存
在しない場合には、上記値を‘Ｎ’に設定する。据え置かれておりかつそのＦＩ
ＬＥ＿ＤＥＦＥＲ＿ＦＬＧが‘Ｐ’（移動クライアントはファイルを有するべき
である）に設定されている場合には、データ併合が自動的に、その次のドッキン
グセッションにおいてそのファイルを検索する要求を提出する。データ１５ｓの
併合は、据え置かれておりかつそのＦＩＬ＿ＤＥＦＥＲ＿ＦＬＧが「Ｒ」（移動
クライアントがファイルを明示的に要求しなければならない）に設定されている
ファイルを求める要求を提出しない。

【０１８３】 更新のコンフリクトがファイルテーブル行のファイルデータ列上で生ずるなら
ば、データ併合は、入力トランザクションがそのコンフリクトに勝利する場合に
、ファイルを適用する。入力トランザクションがそのコンフリクトに敗北する場
合には、データ併合は、そのファイルを適用せず、そのファイルをインボックス
ディレクトリから削除する。

【０１８４】 ファイルが「＜ＲＯＷ＿ＩＤ＞．＜拡張子＞」と命名されているから、独特の
コンフリクトは、ファイルの名前については生じ得ない。 ユーザにディファーのファイルを要請し、検索し、除去することをさせる 移動ユーザは、存在しないファイルまたは陳腐化したファイルをその次のドッ
キングセッションで検索するために、本発明のデータベース管理システムに対し
て要求を提出することが可能である。これは移動クライアントのユーザだけに当
てはまるということに留意されたい。これは、接続ユーザまたは領域内データベ
ースのユーザには当てはまらない。

【０１８５】 移動ユーザは、ファイルを要求するためにクライアントを使用する。クライア
ントは行をドッキング要求待ち行列テーブル（すなわち、Ｓ＿ＤＣＫ＿ＲＥＱ＿
ＩＴＥＭ）の中に挿入する。

【０１８６】 ドッキングクライアントは、ファイル検索が実行可能にされるその次のドッキ
ングセッションにおいてドッキング要求を処理する。ドッキングクライアントは
ドッキング要求待ち行列テーブル内の各行を読み取る。ドッキングクライアント
はドッキングサーバからファイルを検索し、その検索したファイルをターゲット
ディレクトリにコピーする。ドッキングクライアントはＤＯＣＫ＿ＳＴＡＴ＿Ｆ
ＬＧを「Ｅ」（ファイルが存在する）に更新し、ドッキング要求テーブルからそ
の行を削除し、ローカルデータベースに変更を加える。

【０１８７】 移動ユーザは、さらに、本発明のデータベース管理システムが、ファイルを最
新のものに保つために、要求されたファイルに対する全てのアップデートを検索
すべきであるかどうかを指定することが可能である。そうである場合には、本発
明のデータベース管理システムはそのファイルに対するアップデートを検索する
。そうでない場合には、本発明のデータベース管理システムは、その次のドッキ
ングセッションにおいてファイルのコピーを検索するが、そのファイルに対する
アップデートは検索しない。これについては付録８で説明する。

【０１８８】 移動ユーザは、ディスク使用を減少させるためにローカルコンピュータからフ
ァイルを除去することが可能である。移動ユーザは、ファイル除去のためにクラ
イアントを使用する。クライアントはローカルディスクからファイルを削除し、
ＤＯＣＫ＿ＳＴＡＴ＿ＦＬＧを「Ｎ」（ファイルが存在しない）に更新する。ユ
ーザがそのファイルを再び閲覧することを望む場合には、ユーザは、その次のド
ッキングセッションにおいてそのファイルを検索することを本発明のデータベー
ス管理システムに明示的に要求することが可能である。 ファイルをファイルテーブル上のトランザクションをともなって抽出する

【０１８９】 データベースの抽出は、関連したファイルテーブル行を伴うファイルを抽出す
る。データベース抽出は、ファイルテーブル行をスナップショットファイルに書
き込む時に、関連ファイルに関する情報もスナップショットファイルに関するＴ
ＯＣファイルに書き込む。このＴＯＣファイルは、 .ｄｘファイルに関するＴＯ
Ｃファイルと同一のフォーマットを有する。このＴＯＣファイルは、ドッキング
クライアントがスナップショットファイルを検索するときにダウンロードすべき
ファイルのリストを含む。各ファイル毎に、ＴＯＣファイルは、ファイル名、フ
ァイルサイズ、ターゲットディレクトリ、移動ユーザがファイルのダウンロード
を据え置くことが可能かどうか（すなわち、据置きフラグ）、ファイルテーブル
名称、および、ファイルテーブル行のＲＯＷ＿ＩＤをリストする。ドッキングク
ライアントは、移動クライアントに関するスナップショットファイルを検索する
時に、ドッキングクライアントのディレクトリに対するＴＯＣファイルも検索す
る。ドッキングクライアントは、特定のファイルのダウンロードを据え置くこと
が可能である。ドッキングクライアントは、どのファイルをダウンロードすべき
かを判定し、および、どのファイルを据え置くべきかを決定するために、ＴＯＣ
ファイルを読み取る。ドッキングクライアントは、例えば拡張ダイアログボック
ス内の、ファイルダウンロードに関する基本設定を使用する。

【０１９０】 ローカルのデータベースを作成する前に、データベース初期化プロシージャが
ローカルファイルシステムから全ファイルを削除する。データを作成してローカ
ルデータベースにロードした後に、データベース初期化プロシージャは、インボ
ックスディレクトリ内のＴＯＣファイルを読み取り、各ファイルをローカルファ
イルシステムに適用する。データベース初期化プロシージャは、データ併合と同
じ規則を使用してＦＩＬＥ＿ＤＯＣＫ＿ＳＴＡＴ＿ＦＬＧの値を更新する。ＤＢ
ＩＮＩＴに関するファイルアタッチメントを付録９に示す通りにダウンロードす
る。

【０１９１】 領域内データベースのファイルシステム上の全ファイルが最新のものであるこ
とを確保するために、複製のエージェントは常に全ファイルを検索する。複製エ
ージェントは領域内データベースへのファイルのダウンロードを据え置くことは
不可能である。 標準のファイルのアタッチメントのアプレット（ａｐｐｌｅｔ）

【０１９２】 本発明の一つの実施形態において、専用フレームおよびビジネスコンポーネン
トが、デベロッパがファイルアタッチメントアプレット上に露出させることが可
能な次のフィールドを提供する。 ファイルサイズ。ファイルサイズをバイトで示す。このフィールドは読み取り専
用であり、本発明の専用フレームおよびビジネスコンポーネントシステムによっ
て維持される。接続ユーザの場合には、このフィールドは、ローカルファイルキ
ャッシュ内にファイルが存在するかどうかを示す。このフィールドは読み取り専
用であり、本発明のデータベース管理システムによって維持される。

【０１９３】 本発明の特に好適な実施形態においては、専用フレームおよびビジネスコンポ
ーネントが次の組込み動作を提供する： 既存のオペレーティングシステムファイル、データベース内にファイルを作成
する。標準ファイルダイアログボックスをポップアップさせ、作成すべき１つま
たは複数のファイルをユーザに指定させる。専用フレームおよびビジネスコンポ
ーネントが新たなファイルテーブル行を作成し、オペレーティングシステムファ
イルをファイルシステムにコピーする。フレームおよびビジネスコンポーネント
はさらに、ファイルサイズと、ファイル日付と、内部ファイル名と、オリジナル
ファイルの全パス名とをファイルテーブル行の中に格納する。

【０１９４】 ドラッグ、アンド、ドロップを使用して本発明のデータベース管理システム内
にファイルを作成する。ドラッグアンドドロップ要求に応答して、専用フレーム
およびビジネスコンポーネントは新たなファイルテーブル行を作成し、オペレー
ティングシステムファイルをファイルシステムにコピーする。専用フレームおよ
びビジネスコンポーネントはさらに、ファイルサイズと、ファイル日付と、内部
ファイル名と、オリジナルファイルの全パス名とをファイルテーブル行の中に格
納する。

【０１９５】 既存ファイルからのファイルを本発明のデータベース管理システム内にコピー
する。ダイアログボックスをポップアップさせ、コピーすべき１つまたは複数の
ファイルをユーザに指定させる。専用フレームおよびビジネスコンポーネントは
、新たなファイルテーブル行を作成し、ファイルをファイルシステムにコピーす
る。フレームおよびビジネスコンポーネントはさらに、ファイルサイズと、ファ
イル日付と、内部ファイル名と、ＲＯＷ＿ＩＤと、オリジナルファイルのテーブ
ル名とをファイルテーブル行の中に格納する。

【０１９６】 ファイルをソースから更新する。オリジナルファイルからのファイルシステム
内のファイルコピーを更新する。ファイルがオペレーティングシステムファイル
から作成された場合には、オペレーティングシステムファイルを再びファイルシ
ステムにコピーする。ユーザが別のファイルをコピーすることによってファイル
を作成した場合には、ソールファイルを再びシステムファイルにコピーする。

【０１９７】 ユーザがワールド、ワイド、ウェブのページをコピーすることによってファイ
ルを作成すれば、ウェブページを再びファイルシステムにダウンロードする。フ
ァイルテーブル行内のファイルサイズとファイルテーブルを更新する。

【０１９８】 リンクを遮断する。ソースファイルに関する情報を削除し、したがって、オリ
ジナルファイルからファイルが更新できない。 ファイルを削除する。ファイルシステムからファイルを削除する。これは、ユ
ーザがファイルテーブル行を削除する時に自動的に生じる。

【０１９９】 プログラムを呼び出す。ファイルを表示し編集するためのプログラムを呼び出
す。接続ユーザに関しては、クライアントは最初にファイルがローカルファイル
キャッシュ内に存在しておりかつ最新のものであることを確認し（すなわち、日
付とサイズを比較し）、ファイルシステムからのファイルをローカルファイルキ
ャッシュにコピーする。移動ユーザに関しては、クライアントは、本発明のデー
タベース管理システムが維持するローカルファイルシステムからファイルを読み
取る。

【０２００】 クライアントはファイルを解凍して、そのファイルのオリジナルの名称（すな
わち、ソースファイル名）と共にファイルを一時ディレクトリ（Ｃ：＼ｔｅｍｐ
）にファイルをコピーし、その次に、一時ファイルを表示し編集するためのプロ
グラムを呼び出す。ソースファイル名を使用することによって、プログラム（例
えば、Ｍｉｃｒｏｓｏｆｔ Ｗｏｒｄ）が有意味なファイル名をユーザに示すこ
とが可能である。

【０２０１】 ユーザがプログラムを閉じた後、クライアントは一時ファイルをファイルシス
テムに戻す。さらに、クライアントは、ファイルテーブル行内のファイルサイズ
とファイル日付とを更新する。

【０２０２】 ファイルを要求する。移動ユーザに関してのみ利用可能である。ファイルがド
ック状態「Ｏ」（ファイルの陳腐化）または「Ｎ」（ファイルが存在しない）を
有する場合に、その次のドッキングセッションでファイルを検索する要求を提出
する。専用ビジネスコンポーネントおよびフレームは、ＲＯＷ＿ＩＤとファイル
テーブル行のテーブル名と共に行をＳ＿ＤＣＫ＿ＲＥＱ＿ＩＴＥＭテーブルの中
に挿入する。 ファイルのスクリーン ファイル画面は３つのビューを有する。

【０２０３】 可視のビュー。あなたがファイルチーム上に存在する場合に全ファイルを示す
。あなたは行の上をダブルクリックすることが可能であり、クライアントはユー
ザにファイルを編集させる。

【０２０４】 システムの管理のリスト。ファイルテーブル内の全ファイルを示す。あなたは
行の上をダブルクリックすることが可能であり、クライアントはユーザにファイ
ルを編集させる。

【０２０５】 読み取り専用の可視のリスト。個々のユーザがファイルチーム上に存在する場
合に全ファイルを示す。ユーザはこのビューを使用してファイルを編集すること
は不可能である。

【０２０６】 本発明のさらなる例示は、司令部（“ＨＱ”）データベース、すなわち、中央
のまたは、マスターのデータベース、または、データベースの集合体を有するシ
ステムである。データベースは、ＨＱデータベースからのオブジェクトの完全コ
ピーまたは部分コピーを使用して、ＨＱデータベースを完全にまたは部分的にノ
ードの形に複製するために階層の形に構成されている。この階層は、ノード自体
が完全なまたは部分的な複製を有することが可能であるように拡張されることが
可能である。ユーザは、これらのデータベースと、これらのデータベースが含む
オブジェクトと、これらのオブジェクトの属性と、これらの属性の値とを変更す
ることが可能であり、こうした変更は、自己一致性の作業単位、すなわち、「ト
ランザクション」の形にグループ化される。このトランザクションの効果は、「
同期化」プロセスにおいて、ノードからＨＱデータベースへ、ＨＱデータベース
からノードへ自動的に伝播させられる。

【０２０７】 本発明のさらなる観点は、ノードで適用されるトランザクションのセットを記
述する情報を取得してＨＱデータベースに送る同期化プロセスであり、この同期
化プロセスは、「トランザクション」を経路指定するために、ＨＱ ＤＢにおい
て適用されるトランザクションのセットを記述する情報を取得してノードに送る
。この同期化プロセスは、トランザクションを「併合」するために、ノードから
の経路指定されたトランザクション情報をＨＱ ＤＢに適用し、ＨＱ ＤＢから
の経路指定されたトランザクション情報をノードに適用する。併合の効果は整合
性を生じさせることであり、この場合には、オブジェクトと、これらのオブジェ
クトに関する属性のセットと、これらの属性の値とを含む１つのデータベースの
状態またはこの状態の何らかのサブセットが、併合されたトランザクションが導
出されるデータベースの状態またはこの状態の何らかのサブセットと実質的に同
一である。１つのデータベースから別のデータベースへのトランザクションの伝
播のプロセスは、ローカルデータベースに作業を適用するプロセスよりも遅れて
もよく、データベースは、未だ伝播されていない幾つかのトランザクションの状
態によって様々である。

【０２０８】 本発明のさらなる観点は、「コンフリクト解決」規則に基づいてコンフリクト
を自動的に解決する併合プロセスである。１つのデータベースの２つ以上の複製
が、同じデータベースオブジェクトまたはオブジェクトのセットのコピー上にト
ランザクションを有し、オブジェクトまたはオブジェクトのセットの変更が同じ
属性または属性のセットに影響し、かつ、オブジェクトまたはオブジェクトのセ
ットの属性が以前には整合していた時には、併合プロセスが１つの複製からのト
ランザクションを適用し、その他の複製からのトランザクションを適用しない。

【０２０９】 同期化プロセスは、経路指定規則に基づいて自動的にトランザクションを経路
指定し、これらの経路指定規則は、他の要素に加えて、トランザクションにおけ
る変更されたオブジェクトのセットと、変更されている属性のセットと、変更の
前と後のこれらの属性の値と、変更の種類とを調べ、トランザクション全体、ま
たは、トランザクションの情報の何らかの整合したサブセットを特定のノードが
受け入れるべきかどうかを判定する。好ましい具体例では、経路指定規則は、安
全性と情報記憶域の削減と、併合の効率とを非限定的に含む理由のために、複製
内に格納される情報の量を制限する。別の好ましい実施形態では、経路指定規則
が、さらに、複製内の情報を、特定のユーザもしくはユーザの集団に対して可視
的であるか、または、特定の領域もしくは領域のセットに対して可視的であるか
、または、特定のディビジョン（ｄｉｖｉｓｉｏｎ）もしくはディビジョンのセ
ットに対して可視的である情報のセットに制限する。

【０２１０】 本発明のさらなる例示において、データベースオブジェクトが、値がファイル
アタッチメント（すなわち、データベース中に含まれないオブジェクト）に対す
る参照である属性を有する。これらのオブジェクトは、ローカルノードによって
維持されるデータまたはプログラムファイルと、サウンドファイルと、画像ファ
イルと、他のファイルと、ユニバーサルリソースロケータ（「ＵＲＬ」）によっ
て記述される通りの局所的にまたは遠隔的に格納されているリソースとを非限定
的に含む。非データベースオブジェクトの維持と変更は、データベースにおいて
オブジェクトを維持するために使用されかつデータベースオブジェクトとデータ
ベースオブジェクトの属性とこの属性の値とを変更するために使用されるプロシ
ージャ、方法、または、装置とは無関係である、専用のプロシージャ、方法、ま
たは、装置を使用する。

【０２１１】 本発明の他の１つの例示において、ファイルアタッチメント参照がデータベー
スオブジェクトの属性の値として含まれており、トランザクションに関する標準
的な経路指定規則とコンフリクト解決規則とが同期化中の参照の伝播を制御する
。ファイルアタッチメント参照は、そのファイルアタッチメントに固有の専用の
プロシージャや方法や装置に対する連係によって、非データベースオブジェクト
を維持および変更し、これらの参照の作成と削除はこうしたプロシージャや方法
や装置を呼び出す。ファイルアタッチメントの変更は、非データベースオブジェ
クトの新たなバージョンまたはリビジョンの作成を生じさせ、ファイルアタッチ
メントオブジェクトの１つのバージョンを以前のバージョンまたは後続のバージ
ョンから区別するのに十分なリビジョン情報が、データベース内のファイルアタ
ッチメント参照の一部分として追加の属性または属性の値として格納される。

【０２１２】 本発明の他の１つの観点において、変更される非データベースオブジェクトを
データベースファイルアタッチメント参照が変更する時に、ファイルアタッチメ
ントのバージョンまたはリビジョンがトランザクションセマンティックスを維持
する。多数のユーザが同時に同じ１つのファイルアタッチメントオブジェクトを
変更する時に、各ユーザはそのユーザ自身のバージョンを認識する。トランザク
ションが行われる時に、データベースのユーザが、行われたトランザクションに
関連しているファイルアタッチメントの適切なリビジョンを認識する。

【０２１３】 本発明の他の１つの観点において、データベースファイルアタッチメント参照
がファイルアタッチメントの適切なリビジョンに対するアクセスを実現すること
を確実なものにするために、ローカルノードまたはデータベースによって維持さ
れるデータおよびプログラムファイルを含む、特定の非データベースオブジェク
トが、同期化中に１つのノードまたはデータベースから別のノードまたはデータ
ベースにコピーされる。特定のファイルアタッチメント参照は、非データベース
オブジェクトの関連リビジョンが参照内に含まれるバージョン情報と矛盾するこ
とを可能にする。アタッチメントのコピーを後の同期化に据え置くかまたは無期
限に据え置いてもよいので、この属性を有するファイルアタッチメントは「据置
き可能である」。この据置き可能な属性は、データベース内にファイルアタッチ
メント参照の属性または属性値として格納されている「据置きフラグ」によって
表示される。据置きフラグの値は、非データベースオブジェクトの適切なリビジ
ョンが常にアクセス可能であることをファイルアタッチメント参照が保証する「
同報通信」すなわち「据置き不可能」と、非データベースオブジェクトの何らか
のリビジョンがアクセス可能であることをファイルアタッチメント参照が保証す
る「公開」と、ファイルアタッチメントのリビジョンがアクセス可能である必要
はないが何らかのリビジョンがユーザの要求によって後続の同期化中に検索され
てもよい「要求」とを非限定的に含む。

【０２１４】 本発明は或る好適な具体例および実例に関し記述されてきたが、これにより本
発明の範囲を制限することは意図されておらず、本発明の範囲は添付の特許請求
の範囲により制限されるものである。

【０２１５】 付録 付録１ ファイルテーブルにおける標準のコラム ファインテーブルはすべて任意のビジネス目的に特有のコラムに加えて下記の
コラムを有しなければならぬ。本発明は、ファイルの場所、名称、および状態を
識別するためにファイルテーブルにこれらのコラムをさがすことを行なう。

【０２１６】

【表１】

【０２１７】

【表２】

【０２１８】 付録２ Ｓ ファイル このテーブルはファイルビジネスの目的用のファイルについての情報を格納す
る。

【０２１９】

【表３】

【０２２０】

【表４】

【０２２１】

【表５】

【０２２２】 付録３ Ｓ テーブル（新しいコラム） ５．テーブルがファイルテーブルであるかどうかをあらわすために新しいコラ
ムを付加する。本発明はファイルのアタッチメントを複製するためにこの属性を
使用する。

【０２２３】

【表６】

【０２２４】 付録４ ファイルアタッチメントのルーティング用のコンテンツファイルのテーブル 本発明のシステム、方法、装置、およびプログラムプロダクトのアーキテクチ
ャにおいてトランザクションのルータは遠隔のユーザが見ることができるトラン
ザクションを抽出しそれをサーバ上のトランザクション（ＤＸ）ファイルへ集合
させる。この文書は、トランザクション ルータがＤＸファイルに記憶されるト
ランザクションにより参照されるファイルアタッチメントをリストするテーブル
オブコンテンツ（ＴＯＣ）のファイルと称される補助のファイルを作成する１つ
の設計を記述している。ドッキングのクライアントはドッキングに際しＴＯＣの
ファイルをサーバから検索し、次いでクライアントはＴＯＣのファイルに表示さ
れている関連するアタッチメントを検索する。さらに、クライアントはトランザ
クションをアタッチメントとともにサーバへ送出することが可能であり、トラン
ザクションマージャはトランザクションに関連するファイルを適用せねばならぬ
。

【０２２５】 ドッキングリクエストの層は下記を支持せねばならぬ： ＤＸファイルが関連するＴＯＣを有するかどうかを決定する。関連するファイ
ルが開かれたときドッキングクライアントにＴＯＣファイルの存在を通知する。
ＴＯＣファイルを要請に応じクライアントへ転送する。要請に応じファイルアタ
ッチメントをクライアントまたはサーバへ転送し、もしできれば、ファイルのメ
タデータ（例えば作成の日付、修正の目的、ファイルの所有者）を保存する。 ＴＯＣルーチン ＴＯＣの情報を使用するサーバとクライアントの設備は、下記のルーチンを使
用してＴＯＣファイルへアクセスすることができる。

【０２２６】

【表７】

【０２２７】 トランザクションのルータ トランザクションのルータがＤＸのファイルへファイルテーブルの列を書込む
とき、トランザクションのルータは関連するファイルについての情報をＴＯＣの
ファイルへ書込む。ＴＯＣのファイルが存在しないときは、ＴＯＣのファイルが
作成される。ＴＯＣのファイルはＤＸのファイルと同じ数を有するか、ＴＯＣの
延長部を有する。

【０２２８】 ＤＲＬおよびクライアントのダウンロード ドッキングリクエストレイヤーのファイルオープンの方法は番号を付されたフ
ァイルがＤＸファイルなのかＴＯＣなのかを特定する新しいパラメータを取り、
この方法はＤＸファイルが関連するＴＯＣを有するか否かを表示せねばならぬ。
クライアントがサーバからＴＯＣファイルをダウンロードした後、クライアント
はどのファイルのアタッチメントがダウンロードされねばならぬかを発見するた
めにＴＯＣを読取る。 トランザクションのマージャーおよびクライアントのアップロード ドッキングのクライアントがＤＸのファイルへトランザクションを抽出しつつ
あるとき、ドッキングのクライアントはまた、ＴＯＣのファイルを作成する。し
かし、クライアントはＴＯＣのファイルをサーバへアップロードしない。その代
りに、ドッキングに際して、クライアントはＴＯＣファイルを使用して何という
ファイルを転送すべきかを決定し、クライアントはこれらのファイルを直接に転
送する。トランザクションの併合はクライアントのトランザクションをサーバの
データベースへ適用するから、トランザクションの併合は関連するファイルをイ
ンボックスからファイルシステムへ移動させる。

【０２２９】

【表８】

【０２３０】

【表９】

【０２３１】

【表１０】

【０２３２】 さらに、この方法は、オープンされつつあるＤＸまたはスナップショットのフ
ァイルが関連するＴＯＣのファイルを有するか否かを表わすよう特別のブール出
力のパラメータを取る。

【０２３３】 ＴＯＣのファイルをオープンしクライアントへダウンロードすることはＤＸの
ファイルをダウンロードする手順と同一であるが、ただ例外はＤＲＬＦＸＴ ａ
ｂｌｅ Ｏｆ Ｃｏｎｔｅｎｔｓ対ＤＲＬＦＸＴトランザクションの仕様書の点
である。クライアントがファイルのアタッチメントをダウンロードするとき、ク
ライアントはＦｉｌｅ Ｏｐｅｎの方法のファイル名前のバージョンを使用する
。

【０２３４】

【表１１】

【０２３５】 付録５ ファイルを＜ローウィド（ＲＯＷＩＤ）＞、＜エクステンション（ｅｘｔｅｎ
ｓｉｏｎ）＞として格納する代りに、最新の設計は任意の場所の任意のファイル
の任意の改訂に独特の称呼＜ローウィド（ＲＯＷＩＤ）＞、＜リビジョン（ＲＥ
ＶＩＳＩＯＮ）＞を与え、その場合に改訂は他の１つの、世界的に独特のローウ
ィド（ｒｏｗｉｄ）である。例えば、サーバ上の“ｆｏｏ．ｂａｒ”というファ
イルは独特の称呼ｆ．ｓ０１が割当てられることが可能であり、転送および併合
の全体図を提供する図８に示されるようにこの称呼をもってクライアントＡおよ
びクライアントＢに対しコピイが行われることが可能である。

【０２３６】 クライアントＡおよびクライアントＢが“ｆｏｏ．ｂａｒ”の新しい改訂を作
成すると、各々が世界的に独特の称呼を獲得する。クライアントＡについて新し
い改訂はｆ．ａ０１として格納され、クライアントＢについて新しい改訂はｆ．
ｂ０１として格納される。クライアントＡがサーバとドックすると、ファイルｆ
．ａ０１は図９に示されるようにサーバ上のクライアントインボックスへルート
される。トランザクションマージャがトランザクションを適用すると、ファイル
デートのコラムはファイル“ｆｏｏ．ｂａｒ”へ修正されてしまうことが了解さ
れる。この特定のトランザクションについてアップデートはクライアントＡはｆ
．ｓ０１の古い値とｆ．ａ０１の新しい値を有することを示す。サーバ上の実際
の値はｆ．ｓ０１であり、それによりコンフリクトは存在しない。併合は下記の
ように進行する。

【０２３７】

【表１２】

【０２３８】

【表１３】

【０２３９】 ファイルの旧の改訂を削除する 前述のセクションで提案された“攻撃的”な削除についての主要な課題は旧の
ファイル用のＴＯＣファイルのエントリが無効にされることになっていることで
ある。前述の例である旧のファイルｆ．ｓ０１が削除される場合には、まだドッ
クしていない第３のドッキングのクライアントのためにＴＯＣのファイルにおい
て参照されている可能性がある。さらに、可視性の規則の変化は、この他のクラ
イアントはクライアントＡからの改訂ｆ．ａ０１を見ていないはずであるという
ことを意味する可能性があり、したがって改訂ｆ．ｓ０１のみがこのクライアン
トへルートされる可能性がある。幾つかの代替の改訂の制御の方策が表に示され
る。

【０２４０】

【表１４】

【０２４１】 ドッキングのクライアントは或る追加の代替の削除機構を使用することができ
る。クライアントはサーバに対しあらゆるトランザクション（およびあらゆるフ
ァイルアタッチメント）をルートするから、クライアントはファイルの旧の改訂
をファイルシステムからアウトボックスへ移動させることができる。クライアン
トがサーバがＤＸのファイル（ＳＤＯＣＫ ＳＴＡＴＵＳを経由して）処理して
しまったことを知ると、クライアントは関連するＴＯＣのファイルにリストされ
ているアウトボックスにおけるファイル改訂のすべてを削除し、次いでＴＯＣの
ファイルおよびＤＸのファイルを削除することができる。クライアントはファイ
ルの初期の改訂をアウトボックスへ移動することを終了させることが可能であり
、初期の改訂はサーバへ復帰ルートさせられないことに注意すべきである。しか
し、初期の改訂はスナップショット用にＴＯＣのファイルに表示されており、し
たがってクライアントがスナップショットのＴＯＣのファイルを保持していれば
、クライアントはこのＴＯＣのファイルに表示されている改訂をアウトボックス
から常に削除することができる。クライアントがデータベースを再初期化すると
、クライアントはアウトボックスの完全な内容を常に削除すべきである。 ファイルのアタッチメントを併合する ファイルのアタッチメントは、標準のトランザクションのルーティング、ｄｂ
ｅｘｔｒａｃｔ／ｄｂｉｎｉｔ、またはアップグレードのいずれであろうと、普
通の矛盾のない態様で適用されることが必要である。併合されるあらゆる行につ
いて、併合の過程は行を試験しファイルテーブルから到来したのか否かを決定せ
ねばならぬ。行がファイルテーブルから到来したのであれば、併合の過程は、Ｆ
ＩＬＥ ＲＥＶ ＮＵＭの列を点検し値が変化しているか否かを知る。ＦＩＬＥ ＲＥＶ ＮＵＭの列が変化していれば、併合の過程はインボックスにおいてフ
ァイルのアタッチメントを発見しデータベースへ適用せねばならぬ。ファイルの
アタッチメントのあらゆる改訂は形式＜ＲＯＷＩＤ＞．＜ＦＩＬＥ ＲＥＶ Ｎ
ＵＭ＞の名前をもって独特に識別される。ファイルのあらゆる改訂は、特有のＦ
ＩＬＥ ＲＥＶ ＮＵＭの後位文字をともなう同じ共通のＲＯＷＩＤの前位文字
を有する。併合の一般的な態様は、ＩＮＢＯＸにおける正確なファイルの改訂を
検索し、ファイルアタッチメントの形式に従いファイルを適用しデータベースを
更新することである。ＦＩＬＥ ＤＥＦＥＲ ＦＬＧに格納されている形式はブ
ロードカスト、パブリッシュド、またはリクェストである。

【０２４２】

【表１５】

【０２４３】

【表１６】

【０２４４】

【表１７】

【０２４５】 付録６ Ｓ ファイル ポジション このテーブルは与えられた１つのファイルへのアクセスを有するポジションの
リストを格納している。

【０２４６】

【表１８】

【０２４７】 ＴＯＣのファイルは下記をリストする、 ファイルの名前、 ファイルのサイズ、 目標のディレクトリ、 モバイルのクライアントがファイル（すなわち据置きのフラグ）、 ファイルテーブルの名前、およびファイルテーブルの行がデータベースの一部で
あるドックの目的の瞬間のファイルテーブルの行の可視性の強度の行のｉｄのダ
ウンロードを遅延させることができるか否か。 旧の改訂の削除 各ノードは要請又は発表されたファイルの単一の改訂を維持することを必要と
するのみである。しかし、アタッチメントを包含する、トランザクションを併合
するとき他のノードがファイルの適切な改訂を受理することを保証するために、
まだ併合されていないこれらのファイルの旧の改訂を維持することが望ましい可
能性がある。さらに、トランザクションが作動開始していないとデータベースは
矛盾のあるものであるから、削除はトランザクションの作動開始より先行するこ
とはできない。最後に、ｄｂｉｎｉｔとアップグレードの場合には、ムーブと削
除は、初期化またはアップグレードが完了へまで進行することができない場合、
データベースとファイルシステムに以前の状態に復帰するようにさせるために、
反転可能なものであらねばならぬ。これらの目標を達成するために、削除のキュ
ーと称されるリストにファイルの削除が計画されている。

【０２４８】 第１の場合は、ファイルはトランザクションが併合されるまで保持されている
が、ルートされるトランザクションのすべてはキューに受け入れられる。併合の
過程は、トランザクションが適切な受取り者のすべてにおいて併合されてしまっ
ているか否かを決定せねばならず、そのときにおいてのみキューからトランザク
ションを移動させ関連するファイルを削除することができる。併合用の改訂を維
持する目標が放棄される場合には、トランザクションの併合用のより簡単な機構
が作動することになる。この場合には、併合は、キュー上の旧のファイル改訂の
名前を、データベースへの更新を適用するものとして、格納するのみである。各
トランザクションを作動させた後、併合はキュー上にリストされるファイル改訂
のすべてを削除する。システムが作動の後しかしすべての削除が完了する前に崩
壊すればこの削除のキューは揮発性記憶装置内に存在することができ、システム
は依然として矛盾のない状態にあるのであり、もっともファイルサーバは廃用の
改訂を維持することになる。必要であれば簡単なクリーンアップの過程がこれら
の廃用の改訂を検出し消滅させることが可能である。

【０２４９】 ｄｂｉｎｉｔおよびアップグレードの場合 ｄｂｉｎｉｔおよびアップグレード（ｕｐｇｒａｄｅ）の場合には、アップグ
レードの過程はアップグレードの全部が処理されてしまうまでキューからどの改
定も削除してはならない。インボックスからファイルディレクトリへのファイル
の運動を追跡するために類似の機構が必要であり、アップグレードが成功しなけ
ればファイルはインボックスへ復帰させられねばならぬ。ＴＯＣファイルはどの
ファイル改訂がインボックスからファイルディレクトリへ運動してしまったかを
決定するに十分な情報を包含しないことに注意すべきであり、その理由はトラン
ザクションは要請または公表されたファイルのどの改訂についても適用すること
ができるからである。しかし、アップグレードがインボックスからファイルを移
動させるのではなくコピイするならば、全体の結果はムーブの反転可能なリスト
に極めて類似している。ムーブのリストは安定である必要がある可能性があり、
したがってアップグレードの期間に機械が崩壊すると、回復の過程はムーブのリ
ストを読みファイルを原の場所へ置換することであることが可能である。ファイ
ルのコピイとキューの削除の組合せを使用する場合については、キューの削除は
揮発性の記憶装置に存在することが可能である。アップグレードが完了する前に
システムが崩壊すると、原のファイルはインボックスにとどまっている。トラン
ザクションの併合の例のように、最終の作動の後の故障はインボックスにおける
或るファイル改訂を残置する可能性があるが、システムは依然として矛盾のない
ものである。

【０２５０】 付録８ Ｓ ＤＯＣＫ ＲＥＱ ＲＥＦ（新しいテーブル） このテーブルは次位のドッキングセッションにおけるファイルを検索する要請
を格納している。このテーブルはモバイルのクライアントについて使用されるの
みであり、複製は行なわれない。

【０２５１】

【表１９】

【０２５２】 付録９ Ｄｂｉｎｉｔについてのファイルアタッチメントのダウンロード 初期化の期間に、 .ｓｎｐファイル、 .ｔｏｃファイルおよびすべての‘Ｂ’
の文献をブリングダウンし、‘Ｐ’の文献をブリングダウンする。初期化のアッ
プグレードウイザードのフェイズの期間に、すべての‘Ｂ’のファイルをインボ
ックス（ｉｎｂｏｘ）からファイルディレクトリへ移動させ、ファイルディレク
トリへダウンロードされた‘Ｐ’のファイルをすべて移動させ、ダウンロードさ
れなかったファイルをすべて要請する。

【０２５３】 すべての‘Ｒ’のファイルは無視される データモデルの仕様書 Ｓ ＴＡＢＬＥ（新しいコラム） テーブルがファイルテーブルであるか否かを示すために新しいコラムを付加す
る。本発明はファイルアタッチメントを複製するためにこの属性を使用する。

【０２５４】 コラムの名前 ＦＩＬＥ ＴＢＬ ＦＬＧ 形 式 ＣＨＡＲ（ｉ） 制約、注釈 ‘Ｙ’またはＮＵＬＬ−テーブルはファイルテーブルである ‘Ｎ’ −テーブルはファイルテーブルではな い Ｓ ＤＯＣＫ ＲＥＱ ＲＥＦ（新しいテーブル） このテーブルは次位のドッキングセッションにおけるファイルを検索する要請
を格納する。このテーブルはモバイルのクライアントにおいてのみ使用され、複
製されない。

【０２５５】

【表２０】

【０２５６】 ファイルテーブルにおける標準のコラム すべてのファイルテーブルは、任意のビジネス目的に特定のコラムに加えて、
下記のコラムを有しなければならぬ。本発明はファイルテーブルにおいてこれら
のコラムを探索し、ファイルの場所、名前、および状態を識別する。

【０２５７】

【表２１】

【０２５８】

【表２２】

【０２５９】 Ｓファイル この表はファイルビジネスの目的のためファイルについての情報を格納してい
る。

【０２６０】

【表２３】

【０２６１】

【表２４】

【０２６２】

【表２５】

【０２６３】 Ｓファイルの位置 この表は与えられたファイルへのアクセスを有する位置の表を格納する

【０２６４】

【表２６】

【０２６５】 アルゴリズムおよび手順 この技術特徴を実行するために必要な詳細 ＴＯＣファイルで修正されたＴｘｎルータのアルゴリズムの特殊化されたビジ
ネスの要素およびフレームで修正されたドッキング要請の属のメッセージの要請
の構造ファイルの記憶装置を抽出し初期化する修正されたデータ併合のアルゴリ
ズムで修正されたアルゴリズムおよびモバイルのユーザのためにファイル選択を
ダウンロードするユーザのインターフェイス。Ｄｂｉｎｉｔのためのファイルア
タッチメントのダウンロード。

【０２６６】 ｉｎｉｔの期間において、 .ｓｎｐのファイル、 .ｔｏｃのファイル、および
すべての‘Ｂ’文書をブリングダウン、初期化のアップグレードのウイザード位
相の期間において、すべての‘Ｂ’のファイルをインボックスからファイルディ
レクトリへ移動させ、ダウンロードされたすべての‘Ｐ’のファイルをファイル
ディレクトリへ移動させ、およびダウンロードされなかったすべてのファイルを
要請する。

【０２６７】 すべての‘Ｒ’のファイルは無視される。 ファイルアッチメントのルーティング用のコンテンツファイルの表 発明のシステム、方法、装置、およびプログラムプロダクトのアーキテクチャ
において、トランザクションのルータは遠隔のユーザに可視のトランザクション
を抽出しサーバ上のトランザクション（ＤＸ）のファイルへ集合させる。この文
書は１つの設計を記述し、この記述においては、トランザクションのルータはテ
ーブルオブコンテンツ（ＴＯＣ）のファイルと称される補助のファイルを作成し
、該補助のファイルはＤＸのファイルに格納されている、トランザクションによ
り参照されるファイルアタッチメントを表示する。

【０２６８】 ドッキングのクライアントはドッキングに際しサーバからＴＯＣのファイルを
検索し、次いでクライアントはＴＯＣのファイルに表示される関連するアタッチ
メントを検索する。さらに、クライアントはアタッチメントをともなうトランザ
クションをサーバへ送出し、トランザクションマージャーはトランザクションに
関連するファイルを適用せねばならぬ。

【０２６９】 ドッキング要請の属は下記を支持せねばならぬ。 ＤＸのファイルが関連するＴＯＣのフアイルを有するか否かを決定。関連する
ＤＸのファイルがオープンされるとＴＯＣのファイルの存在をドッキングのクラ
イアントへ通知。要請に際しＴＯＣのファイルをクライアントへ転送。要請に際
しファイルアタッチメントのクライアントまたはサーバへの転送、もしできれば
ファイルのメタデータ（例えば、作成の日付、修正の日付、ファイルの所有者）
の保持。

【０２７０】

【表２７】

【０２７１】 トランザクションのルータ ファイルテーブルの行をＤＸのファイルへ書込むとき、トランザクションのル
ータは関連するファイルについての情報をＴＯＣのファイルへ書込む。ＴＯＣの
ファイルが存在しなければ、ＴＯＣのファイルが作成される。ＴＯＣのファイル
はＤＸのファイルと同じ番号を有するか、ＴＯＣの拡張子を有する。

【０２７２】 ＤＲＬおよびクライアントのダウンロード ドッキング要請の層のファイルオープンの方法は番号をもつファイルがＤＸの
ファイルかＴＯＣかを特定する新しいパラメータを取り、この方法はＤＸのファ
イルが関連するＴＯＣを有するか否かを表わさねばならぬ。サーバからＴＯＣを
ダウンロードした後、クライアントはＴＯＣを読取りどのファイルのアタッチメ
ントがダウンロードせねばならぬかを発見する。

【０２７３】 トランザクションのマージャーおよびクライアントのアップロード トランザクションをＤＸのファイルへ抽出しつつあるときドッキングのクライ
アントはまたＴＯＣのファイルを作成する。しかし、クライアントはＴＯＣのフ
ァイルをサーバへアップロードしない。その代りに、ドッキングに際しクライア
ントはＴＯＣのファイルを使用しどのファイルを転送すべきかを決定し、クライ
アントはそれらのファイルを直ちに転送する。クライアントのトランザクション
をサーバのデータに適用するとき、トランザクションのマージャーは関連するフ
ァイルをインボックスからファイルのシステムへ移動させる。

【０２７４】

【表２８】

【０２７５】

【表２９】

【０２７６】

【表３０】

【０２７７】

【表３１】

【０２７８】 冗長な転送 ファイルアタッチメントの行はクライアントへルートされる多重のトランザク
ションにおいて参照されることが可能であり、したがって同じファイルがｍｂｏ
ｘに複数回書込まれる。以前には、ファイルの名前は転送の期間独特のストリン
グに翻訳され、したがって衝突は検出不可能であった。今は、ファイル名前は＜
ＲＯＷ ＩＤ＞．＜ｅｘｔｅｎｓｉｏｎ＞として格納される。したがってわれわ
れがインボックスのディレクトリに対しファイルを検索するかまたはアウトボッ
クスのディレクトリへファイルを書き込むかするとき、ファイルがすでに存在し
同じ日付とサイズを有していれば、われわれはファイルを再びコピイする必要は
ない。〔ファイルのサイズのツリーを樹立し、ファイルサイズが一致すれば、同
じ名前か否かを点検する〕 ラップトップ上でファイルを修正することを維持していれば、ユーザは、サー
バへ転送されることが必要なファイルの多重の改訂を作成することを終了する。
各トランザクションの期間にファイルのみが修正されれば（すなわち、ＦＩＬＥ ＤＡＴＥ、ＦＩＬＥ ＳＩＺＥ、およびＦＩＬＥ ＲＥＶＩＳＩＯＮのコラム
のみが実際のファイルアタッチメントとともに変化させられる）、中間のファイ
ル改訂を消滅させ最後の改訂のみを転送することが望ましい可能性がある。我々
の発明のさらなる実施例によれば、“プッシュテーブル”が使用される。これは
要請のテーブルと同様のものである。ファイルを修正するのみのファイルテーブ
ルのトランザクションは記録されず、その代りに、ファイルテーブルの名前、フ
ァイルの行のｉｄ、および現行の行の値がプッシュテーブルに対し記録される。
ドッキングを行なうとき、クライアントは、プッシュテーブルにもとづき合成の
トランザクションを包含するＤＸのファイルを作成し、各リストされたファイル
の最も現在に近い改訂を参照するドックのｏｐｅｒｓを作成する。さらに、クラ
イアントは、各ファイルの最も現在に近い改訂をサーバに強制せねばならぬ。最
後に、ファイルトランザクションが１つのファイルトランザクションより多くを
修正すれば、ルータはＴＯＣファイルのエントリを書き込み、トランザクション
を記録し、およびファイルを作動開始の前にプッシュテーブルから削除せねばな
らぬ。

【０２７９】 クライアントＡおよびクライアントＢが“ｆｏｏ．ｂａｒ”の新しい改訂を作
成すると、各々は世界的に独特の名前を得る。クライアントＡにあっては新しい
改訂はｆ．ａ０１として、クライアントＢにあっては新しい改訂はｆ．ｂ０１と
して格納される。クライアントＡがサーバとドッキングすればファイルｆ．ａ０
１はサーバ上のクライアントインボックスへルートされる。トランザクションを
適用するとき、トランザクションマージャーはＦＩＬＥ ＤＡＴＥのコラムはフ
ァイル“ｆｏｏ．ｂａｒ”について修正されてしまっていることを見ることにな
る。この特定のトランザクションについて、アップデートはクライアントＡが旧
の値ｆ．ｓ０１および新しい値ｆ．ａ０１を有することを示すことになる。サー
バ上の実際の値はｆ．ｓ０１であり、したがって衝突は存在しない。併合は下記
のように進行する。

【０２８０】

【表３２】

【０２８１】

【表３３】

【０２８２】 クライアントＡの後にサーバとドッキングすると、クライアントＢはｆ．ｂ０
１がルートされるファイルをサーバ上のクライアントのインボックスへルートす
る。トランザクションを適用するときトランザクションのマージャーはＦＩＬＥ ＤＡＴＥのコラムがファイル“ｆｏｏ．ｂａｒ”について修正されてしまって
いることを見ることになる。この特定のトランザクションについて、アップデー
トはクライアントＢが旧の値ｆ．ｓ０１を、新しい値ｆ．ｂ０１を有することを
示すことになる。しかし今は、サーバ上の実際の値はｆ．ａ０１であり、したが
って衝突は存在しない。規則が“サーバが勝つ”というデフォルトであれば、ト
ランザクションは適用することができず、ファイルｆ．ｂ０１はインボックスか
ら削除される。 ファイルの旧の改訂を削除する 前述のセクションで提案された“攻撃的な”削除の方策についての主要な課題
は、旧のファイル用のＴＯＣファイルのエントリが無効化されるということであ
る。旧のファイルｆ．ｓ０１が削除される前述の例において、まだドッキングさ
れていない第３のドッキングクライアントのためにＴＯＣのファイルにおいて参
照される可能性がある。さらに、可視性の規則の変化はこの他のクライアントは
クライアントＡからの改定ｆ．ａ０１を見たはずはないことを意味する可能性が
あり、したがって改訂ｆ．ｓ０１のみがこのクライアントへルートされる可能性
がある。幾つかの代替の改訂の制御の方策がリストにされる。

【０２８３】

【表３４】

【０２８４】 ファイルアタッチメントを併合する ファイルアタッチメントが標準のトランザクションのルーティング、ｄｂｅｘ
ｔｒａｃｔ／ｄｂｉｎｉｔ、またはアップグレードのいずれにより伝搬されるに
せよ、ファイルアタッチメントは共通の、矛盾のない態様で適用される必要があ
る。併合されるあらゆる行については、併合の過程は行を試験しファイルテーブ
ルから到来したか否かを決定せねばならぬ。行がファイルテーブルから到来して
いれば、併合の過程はＦＩＬＥ ＲＥＶ ＮＵＭのコラムを点検し値が変化して
いるか否かを知らねばならぬ。ＦＩＬＥ ＲＥＶ ＮＵＭのコラムが変化してい
れば、併合の過程はインボックス内にファイルアタッチメントを発見しデータベ
ースへ適用することを試みなければならぬ。ファイルアタッチメントのあらゆる
改訂は＜ＲＯＷＩＤ＞，＜ＦＩＬＥ ＲＥＶ ＮＵＭ＞の形式の名前をもって独
特に識別される。ファイルのあらゆるバージョンは、識別性あるＦＩＬＥ ＲＥ
Ｖ ＮＵＭのサフィクスをともなう同じ、共通のＲＯＷＩＤのプリフィクスを有
する。併合の一般的な態様はＩＮＢＯＸにおける正確なファイル改訂を検索しフ
ァイルアタッチメントの形式に従ってファイルを適用しデータベースを更新する
ことである。ＦＩＬＥ ＤＥＦＥＲ ＦＬＧに格納されている形式は、ブロード
カスト、パブリッシュド、またはリクエストである。

【０２８５】

【表３５】

【０２８６】

【表３６】

【０２８７】 旧の改訂を削除する 各ノードは要請または公表されたファイルの単一の改訂を保持することが必要
であるのみである。しかし、アタッチメントを包含するトランザクションを併合
するとき他のノードがファイルの適切な改訂を受理することを保証するためにま
だ併合されたことのないこれらのファイルの旧の改訂を保持することが望ましい
可能性がある。さらに、削除はトランザクションの作動開始より先行することは
できないのであり、その理由は、 トランザクションが作動していないとデータベースは矛盾のあるものである可
能性があるからである。最後に、ｄｂｉｎｉｔおよびアップグレードの場合には
、初期化またはアップグレードが完了にまで進行できなければデータベースおよ
びファイルシステムを以前の状態へ復帰させるためにはムーブおよび削除は反転
可能なものであらねばならぬ。これらの目標を達成するため、ファイル削除は削
除のキューと称されるリストにおいて計画作成される。

【０２８８】 第１の場合につき、ファイルがトランザクションが併合されるまで維持される
場合には、ルートされるトランザクションのすべてはキューへ進入させられる。
併合の過程は、トランザクションが適切な受取り者のすべてにおいて併合されて
しまったか否かを決定せねばならず、その場合にのみトランザクションをキュー
から除去し関連するどのファイルをも削除することができる。併合のために改訂
を維持する目標が放棄されれば、トランザクションの併合用にはより簡単な機構
が作動するであろう。この場合には、併合は、キュー上の旧のファイル改訂の名
前を、データベースへの更新の適用として、格納するのみである。

【０２８９】 各トランザクションを作動開始させた後、キューに表示されるあらゆるファイ
ル改訂を削除する。この削除のキューは揮発性記憶装置に存在することができ、
作動の後にしかしすべての削除が完了する前にシステムが崩壊すると、ファイル
サーバが幾らかの廃用の改訂を保持していても、システムは依然として矛盾のな
い状態にある。必要であれば、簡単なクリーンアップの過程がこれらの廃用の改
訂を検出し消滅させることが可能である。

【０２９０】 ｄｂｉｎｉｔおよびアップグレードの場合について、アップグレードの過程は
アップグレードの全部が処理されるまではキューからどの改定をも削除してはな
らぬ。インボックスからファイルディレクトリへのファイルの移動を追跡するた
めに類似の機構が必要であり、アップグレードが成功しないと、ファイルはイン
ボックスへ復帰させられねばならぬ。ＴＯＣのファイルはどのファイル改訂がイ
ンボックスからファイルディレクトリへ修正されたかを決定する充分な情報を包
含しないことに注意すべきであり、その理由はトランザクションは要請または公
表されたファイルのどの改訂も適用することができるからである。しかし、アッ
プグレードがファイルをインボックスから、移動ではなく、コピイし、インボッ
クスのエントリを削除のキューへ付加すれば、全体の結果はムーブの反転可能な
リストに極めて類似するものになる。ムーブのリストは安定であることが必要で
ある可能性があり、したがってアップグレードの期間において機械が崩壊すれば
、回復の過程はムーブのリストを読みファイルを原の場所へ置換することである
ことが可能である。ファイルのコピイ作成と削除のキューの組合せを使用する場
合には、削除のキューは揮発性の記憶装置に存在することができる。アップグレ
ードが完了する前にシステムが崩壊すると、原のファイルは依然としてインボッ
クスに存在する。トランザクションの併合の例と同様に、最終の作動の後の故障
はインボックスに幾らかのファイル改訂を残置する可能性があるが、システムは
依然として矛盾のない状態にある。

【図面の簡単な説明】

【図１】 接続したユーザのためのファイル作成を示す図である。図示のように、ユーザ
はクライアントスクリーンで新しいファイルを作成する。このファイルを圧縮し
、ファイルシステムおよびローカルファイルキャッシュにコピーする。そしてフ
ァイル表の行に書き込み、トランザクションをデータベースに記録する。

【図２】 接続したユーザがどのようにファイルを見て修正するかを示す図である。ユー
ザは、例えばダブルクリックによって既存ファイルを選択する。これにより、フ
ァイルは必要に応じてローカルファイルキャッシュにコピーされる。そしてこの
ファイルは解凍され、テンポラリディレクトリにコピーされる。ファイルがユー
ザ修正の場合、ユーザ修正ファイルは圧縮され、ファイルシステムとローカルフ
ァイルキャッシュに再びコピーされる。修正ファイルとトランザクションがデー
タベースに書き込まれる。

【図３】 ローカルファイルキャッシュをサポートするコンフィグレーションファイルと
してのコントロールファイルの変更を示す図である。

【図４】 ファイルとトランザクションの取り出しとモバイルクライアントへの適用を示
す図である。図示のように、トランザクションルータがトランザクションとファ
イル添付を適切なファイルに書き込む。ドッキングクライアントはファイルをク
ライアントのインボックスに取り出し、またサーバからファイルを取り出す。ク
ライアントのインボックスにファイルが存在する場合、これがローカルクライア
ントのインボックスにコピーされる。そうでない場合、例えば次のセッションで
ファイルを取り出すよう要求が提出される。トランザクションはローカル・デー
タベースに適用され、ファイルの状態がアップデートされる。

【図５】 モバイルクライアントからのファイルとトランザクションの送信と適用を示す
図である。ここでは、ドッキングクライアントはファイルをクライアントのアウ
トボックスに書き込み、そのファイルをクライアントのインボックスに送信する
。ドッキングクライアントはまたローカルファイルシステムからファイルをクラ
イアントのインボックスに送信する。マージ機能がファイルをファイルサーバに
適用し、トランザクションマネージャがトランザクションをサーバデータベース
に適用する。

【図６】 ファイルドックの状態についての状態の線図である。これは、存在せず、存在
、アウト・オブ・ デートの3 つの状態を状態間のトランザクションと共に示す。

【図７】 本発明の或る実施例によるファイル添付専用フレームのスクリーン図である。
エディットリンクは「名称」、「ソース」、「サイズ」および「タイムスタンプ
」で、アクションは「リンク切断」、「ソースからアップデート」および「ソー
ス変更」に「OK」と「キャンセル」である。

【図８】 ファイル転送とマージの概要を、ファイルf ．s01 を持つサーバ、およびファ
イルf ．b0のローカル複製を持つクライアントA およびB の図で示す。

【図９】 クライアントA がローカルファイルf ．a0も持ち、クライアントB がローカル
ファイルf ．b0を持つ図8 のシステムの概要である。

【手続補正書】

【提出日】平成１２年１０月１９日（２０００．１０．１９）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】０２４７

【補正方法】変更

【補正内容】

【０２４７】 ＴＯＣのファイルは下記をリストする、 ファイルの名前、 ファイルのサイズ、 目標のディレクトリ、 モバイルのクライアントがファイル（すなわち据置きのフラグ）、 ファイルテーブルの名前、およびファイルテーブルの行がデータベースの一部で
あるドックの目的の瞬間のファイルテーブルの行の可視性の強度の行のｉｄのダ
ウンロードを遅延させることができるか否か。付録７ 冗長な転送 ファイルアタッチメントの行はクライアントへルートされる多重のトランザクシ ョンにおいて参照されることが可能であり、したがって同じファイルがｍｂｏｘ に複数回書込まれる。以前には、ファイルの名前は転送の期間独特のストリング に翻訳され、したがって衝突は検出不可能であった。今は、ファイル名前は＜Ｒ ＯＷＩＤ＞．＜ｅｘｔｅｎｓｉｏｎ＞として格納される。したがってわれわれが インボックスのディレクトリに対しファイルを検索するかまたはアウトボックス のディレクトリへファイルを書き込むかするとき、ファイルがすでに存在し同じ 日付とサイズを有していれば、われわれはファイルを再びコピイする必要はない 。〔ファイルのサイズのツリーを樹立し、ファイルサイズが一致すれば、同じ名 前か否かを点検する〕 ラップトップ上でファイルを修正することを維持していれば、ユーザは、サーバ へ転送されることが必要なファイルの多重の改訂を作成することを終了する。各 トランザクションの期間にファイルのみが修正されれば（すなわち、ＦＩＬＥ＿ ＤＡＴＥ，ＦＩＬＥ＿ＳＩＺＥ、およびＦＩＬＥ＿ＲＥＶＩＳＩＯＮのコラムの みが実際のファイルアタッチメントとともに変化させられる）、中間のファイル 改訂を消滅させ最後の改訂のみを転送することが望ましい可能性がある。我々の 発明のさらなる実施例によれば、“プッシュテーブル”が使用される。これは要 請のテーブルと同様のものである。ファイルを修正するのみのファイルテーブル のトランザクションは記録されず、その代りに、ファイルテーブルの名前、ファ イルの行のｉｄ、および現行の行の値がプッシュテーブルに対し記録される。ド ッキングを行なうとき、クライアントは、プッシュテーブルにもとづき合成のト ランザクションを包含するＤＸのファイルを作成し、各リストされたファイルの 最も現在に近い改訂を参照するドックのｏｐｅｒｓを作成する。さらに、クライ アントは、各ファイルの最も現在に近い改訂をサーバに強制せねばならぬ。最後 に、ファイルトランザクションが１つのファイルトランザクションより多くを修 正すれば、ルータはＴＯＣファイルのエントリを書き込み、トランザクションを 記録し、およびファイルを作動開始の前にプッシュテーブルから削除せねばなら ぬ。 旧の改訂の削除 各ノードは要請又は発表されたファイルの単一の改訂を維持することを必要と
するのみである。しかし、アタッチメントを包含する、トランザクションを併合
するとき他のノードがファイルの適切な改訂を受理することを保証するために、
まだ併合されていないこれらのファイルの旧の改訂を維持することが望ましい可
能性がある。さらに、トランザクションが作動開始していないとデータベースは
矛盾のあるものであるから、削除はトランザクションの作動開始より先行するこ
とはできない。最後に、ｄｂｉｎｉｔとアップグレードの場合には、ムーブと削
除は、初期化またはアップグレードが完了へまで進行することができない場合、
データベースとファイルシステムに以前の状態に復帰するようにさせるために、
反転可能なものであらねばならぬ。これらの目標を達成するために、削除のキュ
ーと称されるリストにファイルの削除が計画されている。

【手続補正２】

【補正対象書類名】明細書

【補正対象項目名】０２７８

【補正方法】変更

【補正内容】

【０２７８】 冗長な転送 ファイルアタッチメントの行はクライアントへルートされる多重のトランザク
ションにおいて参照されることが可能であり、したがって同じファイルがｍｂｏ
ｘに複数回書込まれる。以前には、ファイルの名前は転送の期間独特のストリン
グに翻訳され、したがって衝突は検出不可能であった。今は、ファイル名前は＜
ＲＯＷ ＩＤ＞．＜ｅｘｔｅｎｓｉｏｎ＞として格納される。したがってわれわ
れがインボックスのディレクトリに対しファイルを検索するかまたはアウトボッ
クスのディレクトリへファイルを書き込むかするとき、ファイルがすでに存在し
同じ日付とサイズを有していれば、われわれはファイルを再びコピイする必要は
ない。〔ファイルのサイズのツリーを樹立し、ファイルサイズが一致すれば、同
じ名前か否かを点検する〕 ラップトップ上でファイルを修正することを維持していれば、ユーザは、サー
バへ転送されることが必要なファイルの多重の改訂を作成することを終了する。
各トランザクションの期間にファイルのみが修正されれば（すなわち、ＦＩＬＥ
ＤＡＴＥ、ＦＩＬＥ ＳＩＺＥ、およびＦＩＬＥ ＲＥＶＩＳＩＯＮのコラム
のみが実際のファイルアタッチメントとともに変化させられる）、中間のファイ
ル改訂を消滅させ最後の改訂のみを転送することが望ましい可能性がある。我々
の発明のさらなる実施例によれば、“プッシュテーブル”が使用される。これは
要請のテーブルと同様のものである。ファイルを修正するのみのファイルテーブ
ルのトランザクションは記録されず、その代りに、ファイルテーブルの名前、フ
ァイルの行のｉｄ、および現行の行の値がプッシュテーブルに対し記録される。
ドッキングを行なうとき、クライアントは、プッシュテーブルにもとづき合成の
トランザクションを包含するＤＸのファイルを作成し、各リストされたファイル
の最も現在に近い改訂を参照するドックのｏｐｅｒｓを作成する。さらに、クラ
イアントは、各ファイルの最も現在に近い改訂をサーバに強制せねばならぬ。最
後に、ファイルトランザクションが１つのファイルトランザクションより多くを
修正すれば、ルータはＴＯＣファイルのエントリを書き込み、トランザクション
を記録し、およびファイルを作動開始の前にプッシュテーブルから削除せねばな
らぬ。 再訪されるファイル転送および併合 ファイルを＜ＲＯＷＩＤ＞．＜ｅｘｔｅｎｓｉｏｎ＞として格納する代りに、 最新の最大の設計はあらゆる場所のあらゆるファイルのあらゆる改訂に独特の名 前＜ＲＯＷＩＤ＞．＜ＲＥＶＩＳＩＯＮ＞を与え、その場合に改訂は他の１つの 、世界的に独特なｒｏｗｉｄである。例えば、サーバ上のファイル“ｆｏｏ．ｂ ａｒ”は独特の名前ｆ．ｓｏ１が割当てられることが可能であり、これはクライ アントＡおよびクライアントＢに対しこの名前をもってコピイさせられることが 可能である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＵＧ，ＺＷ)，Ｅ Ａ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ， ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，Ｇ Ｈ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ， ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，Ｍ Ｗ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ， ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者 チャタージー，プラシャント アメリカ合衆国，カリフォルニア 95070， サラトガ，グレンモント ドライブ 21281 (72)発明者 コーエン，ジェフリー アメリカ合衆国，カリフォルニア 94086， サニーベール，イースト マッキンレイ アベニュ 499 (72)発明者 リム，ピーター エス． アメリカ合衆国，カリフォルニア 94065， レッドウッド シティ，ガバナース ベイ ドライブ 917 Ｆターム(参考） 5B075 KK04 NR20 QT06 5B082 GA01 GB02 HA05 HA08

Claims (88)

【特許請求の範囲】
1. 【請求項１】 1. 関係のあるデータベースを管理する方法であって、該方
   法は、 a. データベースにおけるデータベースのエントリの作成、更新、アクセス、
   ダウンロード、および削除の1 つ以上を実行すること、および、 b. データベースにおけるデータベースのエントリへのファイル添付の作成、
   更新、アクセス、ダウンロード、および削除の1 つ以上を実行すること、 を具備することを特徴とする方法。
2. 【請求項２】 ファイル添付は、テキストファイル添付、イメージファイル
   添付、およびウェブにもとづくファイル添付からなるグループの1 つ以上を具備
   する、請求項１記載の方法。
3. 【請求項３】 a. どのデータベースのエントリ、どのファイル添付をドッ
   キングのクライアントに対して反復してよいかを決める可視性の規則を適用する
   こと、および、 b. データベースのエントリに対し可視性を有するドッキングのクライアント
   に対してデータベースのエントリおよびファイル添付を反復すること、 をさらに具備する、請求項１記載の方法。
4. 【請求項４】 a. ドッキング中のファイルおよびファイル添付を更新する
   こと、および、 b. ファイルに対し可視性を有するすべてのドッキングのクライアントに対し
   て更新されたファイルおよびファイル添付を反復すること、 をさらに具備する、請求項３記載の方法。
5. 【請求項５】 ドッキング中のファイルおよびファイル添付を更新すること
   をさらに具備する請求項４記載の方法。
6. 【請求項６】 a. 独特性を解決すること、 b. ファイルにおける衝突を更新すること、および、 c. ドッキングの間にデータベースファイルにまたがる無矛盾性および完全性
   を点検すること、 をさらに具備する、請求項５記載の方法。
7. 【請求項７】 ドッキングのクライアントにおけるトランザクションの完全
   性を保証するためにファイルを関連のデータベーストランザクションとともに反
   復することをさらに具備する、請求項６記載の方法。
8. 【請求項８】 可視性の規則は、或る形式のファイル、1 組のユーザ選択フ
   ァイル、および可視的対象に添付された1 組のファイルからなるグループの1 つ
   以上のファイルを特定する、請求項５記載の方法。
9. 【請求項９】 a. ドッキングのクライアントを抽出し、初期化すること、
   および、 b. ドッキングのクライアントを抽出し、初期化する時にファイル添付とファ
   イルの両方を初期化すること、 をさらに具備する、請求項３記載の方法。
10. 【請求項１０】 ファイルの種類、ユーザ選択ファイル、およびドッキング
    のクライアントにとって可視的なデータベースエントリに添付されたファイルの
    1 つ以上を特定する可視性の規則を適用することを具備する、請求項３記載の方
    法。
11. 【請求項１１】 a. データベースのサーバまたはモバイルのサーバにおけ
    るファイル添付を更新すること、および、 b. ファイルの完全性を維持するために反復されたデータベースの間でファイ
    ル添付を同期化すること、 をさらに具備する、請求項３記載の方法。
12. 【請求項１２】 a. クライアントに対するファイル添付の複製を据置くこ
    と、および、 b. 据置かれたクライアントに対するファイル添付を将来のドッキングのセッ
    ションにおいて反復すること、 をさらに具備する、請求項３記載の方法。
13. 【請求項１３】 ファイルのサイズとファイルの種類からなる判定基準のグ
    ループの1 つ以上に基づいてファイル添付のダウンロードを据置く、請求項１２
    記載の方法。
14. 【請求項１４】 a. モバイルのユーザがファイル添付のダウンロードを据
    置くのを可能にすること、および、 b. ファイル添付のダウンロードを区域内データベースおよびサーバのデータ
    ベースに送ること、 をさらに具備する請求項６記載の方法。
15. 【請求項１５】 据置かれたファイル添付をモバイルのユーザにリクエスト
    に応じてダウンロードすることをさらに具備する、請求項１４記載の方法。
16. 【請求項１６】 リクエストされたファイル添付を後続のドッキングのセッ
    ションにおいてダウンロードする、請求項１５記載の方法。
17. 【請求項１７】 a. データベース同期化を不可能にすること、および b. サーバからのファイル添付を削除することなく、モバイルのクライアント
    のローカルディスクからのファイル添付を削除すること、 をさらに具備する、請求項１６記載の方法。
18. 【請求項１８】 非データベースの対象物をローカルのユーザにおけるデー
    タベースのエントリに添付することをさらに具備し、非データベースの対象物は
    ファルおよびファイル添付からなるグループの1 つ以上を包含する、請求項１記
    載の方法。
19. 【請求項１９】 ローカルユーザにおいてファイル添付の多重バージョンを
    作成することをさらに具備する、請求項１８記載の方法。
20. 【請求項２０】 ローカルユーザにおいてデータベースエントリへのファイ
    ル添付を構成することをさらに具備する請求項１８記載の方法。
21. 【請求項２１】 データベースの中のデータベースエントリへのファイル添
    付としてファイルを追加するためにデータベースの外のファイルをコピーするこ
    とを具備する、請求項１記載の方法。
22. 【請求項２２】 オリジナル外部ファイルからの外部ファイルのコピーを更
    新することをさらに具備する、請求項２１記載の方法。
23. 【請求項２３】 HTMLファイルの添付を可能にすることをさらに具備する、
    請求項２１記載の方法。
24. 【請求項２４】 HTMLファイルが1 つ以上の他のファイルを具備する、請求
    項２３記載の方法。
25. 【請求項２５】 a. ユーザが、非データベース対象ファイルとデータベー
    スファイルへのファイル添付からなるグループの少なくとも1 つを添付するのを
    可能にすること、および、 b. ユーザが、ファイル添付に対するビジビリティを他のユーザに追加し、そ
    れで1 つのファイルチームを形成するのを可能にすること、 を具備する請求項１記載の方法。
26. 【請求項２６】 非データベース対象ファイルとファイル添付からなるグル
    ープから選択されたファイル添付をファイルチームメンバーに観察させることを
    具備する、請求項２５記載の方法。
27. 【請求項２７】 非データベース対象ファイルとファイル添付からなるグル
    ープの少なくとも1 つを全ユーザに対してファイルチーム上で反復することを具
    備する、請求項２５記載の方法。
28. 【請求項２８】 データベースは、ファイル名、ファイルサイズ、オリジナ
    ルファイルソースおよび1 つ以上のファイルドッキング状態からなるグループの
    1 つ以上を包含するファイル添付情報を記憶する、請求項１記載の方法。
29. 【請求項２９】 オリジナルファイルソースは、1 種類のソースファイルと
    ソースファイルのフルパスネームからなるグループの1 つ以上を包含する、請求
    項２８記載の方法。
30. 【請求項３０】 ファイル添付アプレットを作成することをさらに具備する
    請求項２８記載の方法。
31. 【請求項３１】 ファイル添付のコピーおよびファイルシステム内部のファ
    イルの名前を記憶することをさらに具備する、請求項２８記載の方法。
32. 【請求項３２】 ディスク使用率を下げるために各ファイル添付を圧縮フォ
    ーマットで記憶することをさらに具備する、請求項２８記載の方法。
33. 【請求項３３】 a. 接続相手のユーザのために、ファイルサーバ側のディ
    レクトリの集合からなるファイルシステムを使用すること、および、 b. ファイルにおいて値を指定すること、 をさらに具備する、請求項２８記載の方法。
34. 【請求項３４】 モバイルのクライアントのために、モバイルのクライアン
    トのローカルディスク側のある場所に存するファイルシステムを使用することを
    さらに具備する請求項２８記載の方法。
35. 【請求項３５】 モバイルのクライアントのローカルディスク側の当該場所
    はクライアントの搭載のディレクトリである、請求項３４記載の方法。
36. 【請求項３６】 ファイル添付は、非データベースファイル添付と非データ
    ベース対象ファイルからなるグループから選択される、請求項に記載の方法。
37. 【請求項３７】 データベースエントリは、サービスリクエスト、オポチュ
    ニティ、クオートおよびアグリーメントからなるグループから選択されたビジネ
    ス対象を包含する、請求項３６記載の方法。
38. 【請求項３８】 ローカルユーザにおいてファイル添付の多重バージョンを
    作成することをさらに具備する、請求項３６記載の方法。
39. 【請求項３９】 ローカルユーザにおいてデータベースエントリへのファイ
    ル添付を構成することをさらに具備する、請求項３６記載の方法。
40. 【請求項４０】 a. どのデータベースエントリ、どのファイル添付をドッ
    キングのクライアントに対して反復してよいかを決めるビジビリティルールを適
    用し、データベースエントリに対してビジビリティを有するドッキングのクライ
    アントに対してデータベースエントリおよびファイル添付を反復すること、 b. データベースから反復すべきファイル添付をドッキングのクライアントに
    リクエストすること、および、 c. リクエストされたファイル添付を後続のドッキングのセッションの間にド
    ッキングのクライアントに対して反復すること、 をさらに具備する、請求項１記載の方法。
41. 【請求項４１】 a. データベースの中のデータベースのエントリの作成、
    更新、アクセス、ダウンロードまたは削除を実行すること、前記データベースが
    、列および欄を含む少なくとも1 つのデータベース表を有し、そこで、1 つの列
    が1 つのデータベース対象に相当し、1 つの欄が該対象の1 つの属性に対応する
    こと、 b. データベースの中のデータベースのエントリへのファイル添付の作成、追
    加、更新または削除を実行すること、および、 c. どのデータベースのエントリ、どのファイル添付をドッキングのクライア
    ントに対して反復してよいかを決めるビジビリティルールを適用し、データベー
    スのエントリに対して可視性を有するドッキングのクライアントに対してデータ
    ベースエントリおよびファイル添付を反復すること、 を具備する、請求項１記載の方法。
42. 【請求項４２】 データベースの対象に対する可視性を有するドッキングの
    クライアントに対してファイルテーブルの列および関連のファイル添付または非
    データベースのファイルの対象を反復すること、をさらに具備する、請求項４１
    記載の方法。
43. 【請求項４３】 関連のファイル添付または非データベースのファイルの対
    象に関する情報をファイルに書き込むこと、をさらに具備する、請求項４２記載
    の方法。
44. 【請求項４４】 関連のファイル添付または非データベースのファイルの対
    象をファイル表する情報をファイルテーブルの列ごとに送信、検索すること、を
    さらに具備する、請求項４２記載の方法。
45. 【請求項４５】 a. ファイルテーブルの列をデータベースまたはファイル
    に適用すること、および、 b. データベースまたはファイルをローカルのファイルのシステムにコピーす
    ること、 をさらに具備する、請求項４１記載の方法。
46. 【請求項４６】 区域内データベースに関連のすべてのファイルを反復する
    ことをさらに具備する、請求項４５記載の方法。
47. 【請求項４７】 ファイル添付または非データベースファイル対象をデータ
    ベースに、データベースエントリの属性を通じてリンクさせることを具備する、
    請求項４１記載の方法。
48. 【請求項４８】 クライアント／サーバのコンピュータのシステムであって
    、該システムは、 a. 下記のものを包含する1 つ以上のサーバのコンピュータ、 1. データベース管理システム、 2. データベース管理システムにおけるデータエントリへのファイル添付を
    受け持つ記憶システム、 b. 下記のものを包含する1 つ以上のクライアントのコンピュータ、 1. サーバのコンピュータからクライアントのコンピュータに向けて反復さ
    れた部分反復データベース、 2. データベース管理システムからクライアントのコンピュータに向けて反
    復されたデータエントリへのファイル添付を受け持つ記憶システム、 c. 1 つ以上のサーバのコンピュータを1 つ以上のクライアントのコンピュー
    タに接続するための通信システム、 d. 1 つ以上のクライアントのコンピュータと1 つ以上のサーバのコンピュー
    タの間のアクセスを制御するドッキングのシステム、 を具備し、クライアント／サーバのシステムは、 1. データベースにおけるデータベースのエントリの作成、更新、アクセス
    、ダウンロードおよび削除の1 つ以上を実行すること、および、 2. データベースにおけるデータベースのエントリへのファイル添付の作成
    、更新、アクセス、ダウンロードおよび削除の1 つ以上を実行すること、 に使用される、ことを特徴とするシステム。
49. 【請求項４９】 ファイル添付が、テキストデータファイル添付、イメージ
    データファイル添付およびウェブベースのデータファイル添付からなるグループ
    の1 つ以上を包含する、請求項４８記載のクライアント／サーバのコンピュータ
    のシステム。
50. 【請求項５０】 クライアント／サーバのシステムがさらに、クライアント
    かサーバかいずれか一方またはその両方からのデータベースの中のデータベース
    エントリの作成、更新、アクセス、ダウンロードおよび削除の1 つ以上を実行す
    るのに使用される、請求項４８記載のクライアント／サーバのコンピュータのシ
    ステム。
51. 【請求項５１】 クライアント／サーバのシステムがさらに、ドッキング中
    のサーバのシステムからクライアントのシステムに向けてファイルおよびファイ
    ル添付を反復するのに使用される、請求項４８記載のクライアント／サーバのコ
    ンピュータのシステム。
52. 【請求項５２】 クライアント／サーバのシステムが、クライアントがサー
    バのコンピュータのデータベースの中のデータベースエントリに対してビジビリ
    ティを有するかどうかを決めるために、サーバのコンピュータシステムにおける
    ビジビリティルールをクライアントのコンピュータシステムに関するドッキング
    システムのデータのエントリに適用するのに使用され、さらにまた、どのデータ
    ベースのエントリ、どのファイル添付をクライアントのコンピュータシステムに
    対して反復してよいかを決め、データベースのエントリに対して可視性を有する
    クライアントのコンピュータのシステムに対してデータベースのエントリおよび
    ファイル添付を反復するのに使用される、請求項４８記載のクライアント／サー
    バのコンピュータのシステム。
53. 【請求項５３】 クライアント／サーバのシステムはさらに、 a. ドッキング中のファイルおよびファイル添付を更新すること、および b. ファイルに対してビジビリティを有するクライアント・コンピュータシス
    テムに対して更新されたファイルおよびファイル添付を反復すること、 に使用される、請求項５２記載のクライアント／サーバのコンピュータのシステ
    ム。
54. 【請求項５４】 クライアント／サーバのシステムはさらに、 a. 唯一性を分解すること、 b. ファイル内部の矛盾箇所を更新すること、および、 c. ドッキング中のデータベースファイルを横断して無矛盾性および完全性を
    点検すること、 に使用される、請求項５３記載のクライアント／サーバのコンピュータのシステ
    ム。
55. 【請求項５５】 クライアント／サーバ・システムがさらに、ドッキングの
    クライアントにおけるランザクションの完全性を保証するためにファイルを関連
    のデータベーストランザクションとともに反復するのに使用される、請求項５４
    記載のクライアント／サーバのコンピュータのシステム。
56. 【請求項５６】 ビジビリティルールが、或る一定の種類のファイル、1 組
    のユーザ選択ファイル、および可視的対象に添付された1 組のファイルからなる
    グループの1 つ以上のファイルを指定する、請求項５２記載のクライアント／サ
    ーバのコンピュータのシステム。
57. 【請求項５７】 クライアント／サーバ・システムは、 a. ドッキングのクライアントを抽出し、初期化すること、および b. ドッキングのクライアントを抽出し、初期化する時にファイル添付とファ
    イルの両方を初期化すること、 にさらに使用される、請求項５２記載のクライアント／サーバのコンピュータの
    システム。
58. 【請求項５８】 クライアント／サーバのシステムは、ファイルの種類、ユ
    ーザ選択ファイル、およびドッキングのクライアントにとって可視的なデータベ
    ースエントリに添付されたファイルの1 つ以上を特定する可視性の規則を適用す
    ることに使用される、請求項５２記載のクライアント／サーバのコンピュータの
    システム。
59. 【請求項５９】 クライアント／サーバのシステムは、 a. サーバにおけるファイル添付を更新すること、および b. ファイルの完全性を維持するために反復されたデータベースの間でファイ
    ル添付を同期化すること、 にさらに使用される、請求項５２記載のクライアント／サーバのコンピュータの
    システム。
60. 【請求項６０】 クライアント／サーバ・システムは、 a. クライアント・コンピュータシステムに対するファイル添付の反復を遅延
    させること、および、 b. 遅延させられたクライアントのコンピュータシステムに対するファイル添
    付を将来のドッキングのセッションにおいて反復すること、 にさらに使用される、請求項５２記載のクライアント／サーバのコンピュータの
    システム。
61. 【請求項６１】 クライアント／サーバのシステムは、ファイルのサイズと
    ファイルの種類からなる判定基準のグループの1 つ以上に基づいてファイル添付
    のダウンロードを遅延させることにさらに使用される、請求項６０記載のクライ
    アント／サーバのコンピュータのシステム。
62. 【請求項６２】 クライアント／サーバのシステムは、データベースの中の
    データベースのエントリへのファイル添付としてファイルを追加するためにデー
    タベースの外のファイルをコピーすることにさらに使用される、請求項４８記載
    のクライアント／サーバのコンピュータのシステム。
63. 【請求項６３】 クライアント／サーバのシステムは、オリジナル外部ファ
    イルからの外部ファイルのコピーを自動的に更新することにさらに使用される、
    請求項６２記載のクライアント／サーバのコンピュータのシステム。
64. 【請求項６４】 クライアント／サーバ・システムがさらに、HTMLファイル
    の添付を可能にするのに使用されることを特徴とする前記システム。
65. 【請求項６５】 クライアント／サーバ・システムがさらに、1 つ以上の他
    のファイルからなるHTMLファイルの添付を可能にするのに使用されることを特徴
    とする前記システム。
66. 【請求項６６】 クライアント／サーバのシステムは、 a. ユーザが、非データベース対象ファイルとデータベースファイルへのファ
    イル添付からなるグループの少なくとも1 つを添付するのを可能にする、および b. ユーザが、ファイル添付に対するビジビリティを他のユーザに追加し、そ
    れで1 つのファイルチームを形成するのを可能にする にさらに使用される、請求項４８記載のクライアント／サーバのコンピュータの
    システム。
67. 【請求項６７】 クライアント／サーバ・システムは、非データベース対象
    ファイルとファイル添付からなるグループの少なくとも1 つをファイルのチーム
    上のすべてのユーザに対し反復することに使用される、請求項６６記載のクライ
    アント／サーバのコンピュータのシステム。
68. 【請求項６８】 クライアント／サーバのシステムの管理のために機械で読
    み取ることができ、機械で実行することのできる命令のプログラムを具体化する
    複数のプログラム記憶の装置であって、該装置は、 a. 下記のものを有する1 つ以上のサーバのコンピュータ、 1. データベース管理システム、および、 2. データベース管理システムにおけるデータエントリへのファイル添付を
    受け持つ記憶システム、 b. 下記のものを有する1 つ以上のクライアントのコンピュータ、 1. サーバのコンピュータからクライアントのコンピュータに向けて反復さ
    れた部分反復データベース、 2. データベース管理システムからクライアントのコンピュータに向けて反
    復されたデータエントリへのファイル添付を受け持つ記憶システム、 c. 1 つ以上のサーバのコンピュータを1 つ以上のクライアントのコンピュー
    タに接続するための通信システム、 d. 1 つ以上のクライアントのコンピュータから1 つ以上のサーバのコンピュ
    ータへのアクセスを制御するためのドッキングのシステム、 を包含し、クライアント／サーバのシステムは、 1. データベースの中のデータベースのエントリの作成、更新、アクセス、
    ダウンロードおよび削除の1 つ以上を実行すること、および、 2. データベースの中のデータベースのエントリへのファイル添付の作成、
    更新、アクセス、ダウンロードおよび削除の1 つ以上を実行すること、 のため命令のプログラムを実行する、ことを特徴とする装置。
69. 【請求項６９】 ファイル添付は、テキストデータファイル添付、イメージ
    データファイル添付およびウェブベースのデータファイル添付からなるグループ
    の1 つ以上を包含する、請求項６８記載の複数のプログラム記憶装置。
70. 【請求項７０】 命令のプログラムは、クライアントかサーバかいずれか一
    方またはその両方からのデータベースの中のデータベースエントリの作成、更新
    、アクセス、ダウンロードおよび削除の1 つ以上に関する命令をさらに包含する
    、請求項６８記載の複数のプログラム記憶装置。
71. 【請求項７１】 ドッキング中のサーバのシステムからクライアントのシス
    テムに向けてファイルおよびファイル添付を反復する命令を包含する、請求項６
    ８記載の複数のプログラム記憶装置。
72. 【請求項７２】 クライアントがサーバのコンピュータのデータベースの中
    のデータベースのエントリに対して可視性を有するかどうかを決めるために、サ
    ーバのコンピュータシステムにおける可視性の規則をクライアントのコンピュー
    タシステムに関するドッキングのシステムのデータエントリに適用し、さらにま
    た、どのデータベースのエントリ、どのファイル添付をクライアントのコンピュ
    ータシステムに対して反復してよいかを決め、データベースのエントリに対して
    可視性を有するクライアントのコンピュータのシステムに対してデータベースの
    エントリおよびファイル添付を反復する命令を包含する、請求項68記載の複数の
    プログラム記憶装置。
73. 【請求項７３】 請求項72に記載の複数のプログラム記憶装置において、命
    令のプログラムがさらに、 a. ドッキング中のファイルおよびファイル添付を更新すること、および、 b. ファイルに対して可視性を有するクライアントのコンピュータシステムに
    対して更新されたファイルおよびファイル添付を反復すること、 をさらに包含する、請求項７２記載の複数のプログラム記憶装置。
74. 【請求項７４】 命令のプログラムは、 a. 唯一性を分解し、 b. ファイル内部の矛盾箇所を更新し、および、 c. ドッキング中のデータベースファイルを横断して一貫性および完全性をチ
    ェックする、 請求項73記載の複数のプログラム記憶装置。
75. 【請求項７５】 命令のプログラムは、ドッキングのクライアントにおける
    ランザクションの完全性を保証するためにファイルを関連のデータベースのトラ
    ンザクションとともに反復する、請求項74記載の複数のプログラム記憶装置。
76. 【請求項７６】 命令のプログラムの中の可視性の規則は、或る一定の種類
    のファイル、1 組のユーザ選択ファイル、および可視的対象に添付された1 組の
    ファイルからなるグループの1 つ以上のファイルを指定する、請求項72記載の複
    数のプログラム記憶装置。
77. 【請求項７７】 命令のプログラムは、 a. ドッキングのクライアントを抽出し、初期化し、および b. ドッキングのクライアントを抽出し、初期化する時にファイル添付とファ
    イルの両方を初期化する、 請求項72記載の複数のプログラム記憶装置。
78. 【請求項７８】 命令のプログラムは、ファイルの種類、ユーザ選択ファイ
    ル、およびドッキングのクライアントにとって可視的なデータベースエントリに
    添付されたファイルの1 つ以上を特定する可視性の規則を適用する、請求項72記
    載の複数のプログラム記憶装置。
79. 【請求項７９】 命令のプログラムは、 a. サーバにおけるファイル添付を更新し、および b. ファイルの完全性を維持するために反復されたデータベースの間でファイ
    ル添付を同期化する、 請求項72記載の複数のプログラム記憶装置。
80. 【請求項８０】 命令のプログラムは、 a. クライアントのコンピュータシステムに対するファイル添付の反復を据置
    き、および、 b. 据置かれたクライアントのコンピュータシステムに対するファイル添付を
    将来のドッキングのセッションにおいて反復する、 請求項72記載の複数のプログラム記憶装置。
81. 【請求項８１】 命令のプログラムは、ファイルのサイズとファイルの種類
    からなる判定基準のグループの1 つ以上に基づいてファイル添付のダウンロード
    を遅延させる、請求項80記載の複数のプログラム記憶装置。
82. 【請求項８２】 命令のプログラムは、データベースの中のデータベースエ
    ントリへのファイル添付としてファイルを追加するためにデータベースの外のフ
    ァイルをコピーする、請求項68記載の複数のプログラム記憶装置。
83. 【請求項８３】 命令のプログラムは、オリジナル外部ファイルからの外部
    ファイルのコピーを自動的に更新する、請求項82記載の複数のプログラム記憶装
    置。
84. 【請求項８４】 命令のプログラムは、HTMLファイルの添付を可能にする、
    請求項82記載の複数のプログラム記憶装置。
85. 【請求項８５】 命令のプログラムは、1 つ以上の他のファイルからなるHT
    MLファイルの添付を可能にする、請求項84記載の複数のプログラム記憶装置。
86. 【請求項８６】 命令のプログラムは、 a. 非データベース対象ファイルとデータベースファイルへのファイル添付か
    らなるグループの少なくとも1 つを添付し、および、 b. ファイル添付に対する可視性を他のユーザに追加し、それで1 つのファイ
    ルチームを形成する、 請求項68記載の複数のプログラム記憶装置。
87. 【請求項８７】 命令のプログラムは、非データベース対象ファイルとファ
    イル添付からなるグループの少なくとも1 つを全ユーザに対してファイルチーム
    上で反復する、請求項86記載の複数のプログラム記憶装置。
88. 【請求項８８】 前記複数のプログラム記憶装置の少なくとも1 つはクライ
    アントのコンピュータシステムに属するように適応させ、前記複数のプログラム
    記憶装置の少なくとも1 つがサーバのコンピュータのシステムに属するように適
    応させてある、請求項68記載の複数のプログラム記憶装置。