JP2007529050A - 仮想ドキュメントアーキテクチャを通して共同編集と責任分担を容易にする自動出版システム - Google Patents

Abstract

本発明は、金融、法律、および政府ドキュメントの出版、および構造化された出版物、会社規定または外部法規基準の遵守を必要とし、コンテント要素の共有が可能な出版物の出版を自動化する。本発明において、ユーザは常にアクセス可能である慣れ親しんだインターネット環境上での管理が可能である。その仮想ドキュメント構造およびインターネット、イントラネット上での作業を可能にする能力によって、本システムは共同作業および責任追跡管理を容易にする。自動出版における主要な概念は、より良いコンテント管理による、スケジュールおよびコストの管理である。本発明は、ドキュメント・コンテントを、小さく再使用可能なコンポーネントとしてパラグラフおよび表中セルレベルで処理する。インターフェイスによって、ユーザは簡単に自動的にバージョン管理されたこれらのコンポーネントを使うことができ、これによってドキュメントをアセンブルする事が可能である。本システムは、各コンポーネントと共に記憶保存された文脈およびフィルタリング基準を適用し、コンテント断片の最新ドキュメントへの位置づけと適用を実行する。本発明のシステムは、法規条件および会社ビジネス規定に遵守するための、構造規定および内容条件を適用する事が可能である。システム内の作業中仮想ドキュメントは、常に全ての構成要素の最新バージョンを組み込んでいる。

Description

本発明は、ドキュメント間でコンテント要素を共有し、綿密に関わり合い類似した構造に作られたある一式の形式を持つ複数のドキュメントの共同準備、共同構成、および共同出版に関するものである。ドキュメント一式は、ビジネスルールや法令に従うために構造およびコンテントに関する管理を必要とし、複数の異なるフォーマットや媒体での同時提出が必要とされる場合もある。こうしたドキュメント出版においては、時間とコストをいかに減らすかが重要となる。

今日に至るまでの主なドキュメント準備方式は（１）直列製造方式、および（２）出版スケジュールを管理するデータソースの有効性に依存する方式が使われてきた。その工程では、クライアント・データをWordのような準備システムから、タイプセットおよび印刷準備のために他の製造システムに転送するようなことも必要とされる。この工程において植字業者は、エラー（PEs、クライアントへ請求不可）を起こす可能性があり、これは著者による変更（AAs、請求可）と請求書発行の際に区別しなければならない。

ドキュメント一式がテキストまたは他要素を共有している場合には、それらの共有要素に対する全ての変更はドキュメント・セット全体に反映されなければならない。しかし個々のドキュメントの出版期日は大抵異なる期日に予定されている。この間題に対してよく使われる手作業的な解決法は、変更が必要とされる個々のドキュメントの責任者である編集者にメモを配布することである。この方法は（それぞれのドキュメントが出版される間にまた他の変更がする発生可能性があるため）通用するかどうかの保障性がなく、変更作業の確実性を保障することができない。

この問題を解決すべく使われていた旧式の電子的方式は、ボイラープレート・ライブラリ（反復使用語句のライブラリ）と呼ばれるもので、初期の私有ワードプロセッシング・システム上に導入され、この方式ではボイラープレート要素はドキュメント上に頻繁に直接インポートされ使われた。しばらくしてさらに一般化された方式が登場し、それは国際標準化機構（ISO）で標準化されたSGML（Standard Generalized Markup Language：スタンダード・ジェネラライズド・マークアップ・ランゲージ）言語を使用した。SGMLは、同じ構造やコンテント形式を共有する複数のドキュメント群における、マークアップのための一連の記述ルールをオープン形式で標準化した。SGMLは、ボイラープレートやスタンディング・テキストをリファレンスとして保存したり挿入することを可能にした。これによってボイラープレートをドキュメント本体の外部に置くことができた。しかしながら、このリファレンスはまだドキュメント・ストリームに埋め込まれている状態であり、ドキュメントはボイラープレート・リファレンスのソースを識別しなければならなかった。この時点では、出版工程を断片的に処理する有効な方法がなかった。

その後、SGMLから派生したものがXML（Extensible Markup Language：エクステンシブル・マークアップ・ランゲージ）と呼ばれるドキュメントの構造およびコンテント要素を記述する方式であり、この方式ではインターネット上での操作が可能となった。XMLは、SGMLと同様にドキュメント構造およびコンテントを表面上のフォーマットと効果的に分割する。そこで発明側に持ちかけられたチャレンジは、共有要素をストリーミング・ドキュメントに埋め込むことなく効果的に一体化するメカニズムを開発することであった。そして本発明でのXMLの導入が構造化の実施およびコンテントの記述に対する問題を解決し、そしてさらなる構造のコンテントからの分離が、XML要素をドキュメント内に含むことなくコンテントを指示することのみに使うことで実現した。結果は仮想ドキュメントである。

本発明は、ドキュメントをパラグラフおよびテーブル・セルレベルで、小さく再使用可能な共有コンポーネントとして処理するシステムに対するものである。本システム上においてユーザは、ユーザ・インターフェースを使っての作業により、自動サポートでバージョン管理された複数のコンポーネントから出版物を作成することができる。

本発明は、従来の出版方法に比べて多くの利点を持つ。例えば、本発明は正確性および一貫性をもたらすことでエラーを少なくするため、出版までの時間を削減することができる。全ての変更がログすることによって行われるので、責任が明確化される。本発明によってインターネット上での直接的な共同作業が可能となる。また本発明は、ドキュメント内容に対して分配された責任性の問題、例えば数字を管理する経営部署およびディスクロージャーを管理する法律部署間の問題についても解決することができる。

加えて本発明では、校正および著者による変更の回数が何回におよぼうと遅れることなくプルーフを作成することができる。コメントおよびプルーフの配布は電子的に実行することが可能である。また本システムには全てのテキストを検索できる能力もあり、統一されたスキームでシステム上全てのオブジェクトの参照が可能である。本システムは他のドキュメントと共有されているコンポーネントの変更を防ぐツールも含んでいる。本システムを使うことによって、スケジュールに融通性が生じ、またユーザはバージョン管理に混乱することなく前もって準備を始めることができる。全てのドキュメントに反映されなければならないグローバル・チェンジは、ライブラリを通じて自動的に行われる。本システムでは制限付きのワークグループを設定することにより、強力なシステム管理を行うことが可能である。

上記システムは、多様な状況に適応できる。例えば：
・一連のドキュメントが、非常に多くのコンテントを共有している場合−−ドキュメント内のコンポーネントをパラグラフレベルで管理することによって、コンテントを大きい単位でしか処理出来ないシステムとは対照的に、効率性および融通性を最大に生かせる粒度でコンポーネントをドキュメント間で共有することができる。
・共有されているコンポーネントに修正が必要な場合−−修正は1度のみで良い。コンポーネントはビジネスルールおよび法令を取り込んだ特性を有することとなり、それがコンポーネントの含まれるドキュメントを管理することとなる。
・複数のドキュメントがひとつの、または複数のルール環境に従わなくてはならない場合−―本システムは、そのルール環境の構造的なアウトラインおよびコンポーネントのバージョンを記憶しておくことができる。
・ドキュメントの準備作業を共同で進める場合−−テキスト本の出版のように、複数の著者が関わってくる場合でも、複数の著者が同時に同じ本、または同じセクションを開き、同時進行で作業を進めることができる。様々なセクションを、企業内の異なるワーク・グループでそれぞれに準備することも可能である。
・ドキュメントが、外部の複数の会社から寄稿されたものを集めて出来ている場合−−大システム内の一部を下請けした寄稿者は、彼らのドキュメント担当部分を供給し所有することが可能であり、それぞれの寄稿者はドキュメント上で同時に作業ができる。（未完原稿だらけのドキュメントを集める必要がない。）
・ドキュメントを速やかに多言語に翻訳する必要がある場合−−本システムは強健な翻訳管理システム機能を有しており、修正が発生した場合にはその修正箇所が確実に翻訳されるべく翻訳者に通知書が電子的に送られる。そして各パラグラフは多言語版およびローカライゼーション版に変換される。
・校閲作業に複数の外部寄稿者が関わってくる場合−−校間者はそれぞれのコメントを電子的に提出することができ、それを追跡管理システムに入力することにより、編集者はコンポーネントレベルでの正式なコメント通知を受け取る。校閲者はウェブ上の全てのタイプセット・プルーフにアクセスすることが可能である。
・権限を持っていないユーザの修正からコンテントを保護する必要がある場合−−本システムはパラグラフレベルでコンテントの所有者を設定することができる。
・会社が複数のモデルの目録を有し、これを正式に記録したい場合−−サービス用マニュアルおよびユーザ用マニュアルは、各モデル間の類似点と相違点を記すことが可能である。
・会社が予算内でカスタマイズされたドキュメントを出版したい場合−−本システムでは、カスタマイズを実行するための外部データベースへの複数のリンクを容易に統合することができ、高品質なオンデマンド印刷物をすばやく、また自動的に制作することが可能である。
・締め切りが迫っているドキュメントを、同時に複数のフォーマットで出版しなければならない場合−−本システムは新しく完全なタイプセット・プルーフを必要に応じて数分以内に出力することができる。またユーザのビジネス・ニーズによって、複数のフォーマットでプルーフおよびマスターファイルの両方を同時に出力できる。

いくつかの産業がこれらの状況に直面していることに気付いており、その産業には、金融および保険サービス業、主要製造ビジネス業、テキスト本およびジャーナル出版業、統治団体、全国紙および多国籍紙、法律に関する出版、飛行機製造業、防衛産業、そしてエネルギー、薬品、および食品プロバイダ業、またソフトウェア企業などの行政規制業界が含まれる。

本発明の実施形態において、出版物は（1）クライアントが主題、読者、目的などによって、他の出版ドキュメントと識別できる（2）企業の個性および企業のビジネスルールに従うことができる（3）印刷物やインターネット上のファイルのような慣習的に配布できる形態で出版することができる（4）定期的に新しい出版形態で再出版できるドキュメントである。必然的に、出版物は言語プロパティを有し、それはひとつのみである。（多言語出版は独自の言語セットを有する。）全ての出版物は、その出版物の種類、出版物のコンテントに関して一般化されたルールの正式定義、それらの順序、および親／子の関係に従わなければならない。いくつかのコンテントを共有し、それぞれに独立した出版物の種類によって統合される一群の関連し合う出版物は、パブリケーション・セットと呼ばれる。例えば、金融サービス業界では金融趣意書はひとつのパブリケーション・タイプであり、株主への報告書は別の独特の種類である。しかしこの2つの出版物は株主情報としての同じパブリケーション・セットの一部分であり、それはその2つが同じ財務表、ディスクロージャ、ポートフォリオ・マネージャの略歴等を共有しているからである。本発明は構造要素を指示するポインターが順次にコンテントを指示するものに変わるしくみを利用して仮想ドキュメントを作るので、異なる構造タイプを持った複数のドキュメントは同じコンテントを共有することが可能である。

本発明は、出版工程の分散化を中心に展開されるため、ドキュメントの異なる部分にそれぞれ責任を持つワークグループは、図14で示している様に仮想ドキュメント上で同時に作業をすることができる。ドキュメント・コンテントはドキュメントを編集する前に制作することができる。直列生産方式においては、スケジュール上で共同作業者同士が承認およびワークグループでのやりとりするために、会うことを必要とされる事が頻繁に起こる。本発明の実施形態において、共同作業者たちは担当コンポーネントの最終化に応じてその責任範囲のドキュメントのコンポーネントを承認し、その旨を他のチームメンバーにEメールで通知することができる。例えば、ほとんどの金融サービス会社は生産管理部署に表データを割り当て、法務部署には必須の言語およびディスクロージャの照合、マーケテイングおよび／またはポートフォリオ・マネージャに投資ポリシーやゴールについての記述を割り当てる。これらの異なる種類のコンテントは、本システムの多様なフィルタ機能を使って、ひとつまたはさらに多くのドキュメントに前もって割り当てることによりいつでも制作することができる。このように本システムは、物理的あるいは電子的なグループ間での書類の受け渡しの必要なく、全てのドキュメント・コンテントに対して拡散した、または共同の責任分担を可能にする。

図26a、26b、および26cは、従来の技術方式と本発明における実施形態方式のひとつの比較を表している。従来の技術方式図がドキュメント準備工程の複雑さを証明している様に、出願人は図26cが示しているさらに単純化されたドキュメント準備工程の方が有益であると認識する。クライアントからのニーズに対応する際、出願人は（a）金融サービスおよび他のクライアントのドキュメントが、全域にわたって特有のサブセットまたはひとつのドキュメントを使った複数のコンポーネントで構成されていること（b）共有コンポーネントを更新する作業が、時間がかかり不正確な工程であること（c）クライアントのドキュメントが、法律、法規、会社のマーケテイング条件に適合する必要があること（d）期日通りに出版できないことでクライアントに厳しいペナルティが生じ、必要な要素や法的ディスクロージャが含まれていないことはさらに厳しいペナルティに繋がること（e）スケジュールがデータソースのスケジュール性、基金会計の外部ソーシング、法的サービス、または第三者からの寄稿によって制限されること（f）会社の社員が既にタイプセット業者に渡す前の社内校閲段階でデスクトップ環境でのドキュメント準備を行っていること（g）重要な資料が、クライアントから送られたファイルにはエラーがないにも関わらず、タイプセット業者によって何度も手入力された結果、頻繁にエラーを引き起こしてしまうこと（h）出版サービス業者が、ページの構成や変更作業を始める前に資料の交換が必要であるため、48時間から8時間程の提出サイクルの遅れが生じてしまうこと。および（i）通常のプルーフ作成や出版の作業工程が直列方式であるため、時間の遅れが発生してしまい、それがスケジュールを悪化させてしまうことを認識した。これらの後半の要因は、特に印刷する期日が迫っている時には重要な問題である。

加えて、金融サービス業界のクライアントは、ドキュメントを特有のフォーマットで政府取締局に提出する必要があり、これは印刷準備と同時に提出されなければならない。しかし印刷のための承認とEDGARIIとして知られるルールフォーマットのサービス業者からの受け取りには常に時間のずれが生じるため、同時提出の必要性はスケジュールに関するもうひとつの問題源でもあった。またEDGARIIファイルを制作する工程でのデータソースは、印刷物を制作した時と同じ物が常に使われていなかった。

本発明は、ワークフロー、およびドキュメント準備工程、校閲、編集、追跡管理、コメント収集、通常のプルーフおよびブラックライン表示付きプルーフ作成、請求書発行、および印刷物と（EDGARIIのような）補助ファイルの作成方法を完全に変えることによって、これらの問題に対応する。

本発明の実施形態において、システムはXMLのエンコーディングを通して数々の重要な機能の実行を可能にする。オープン・マークアップ・スタンダードを使うことにより、ひとつのデータソースから複数の異なるデータ／ファイル・フォーマットへ同時転送が可能となり、これはビュー・トランスフォーメーション機能としても知られている。例えば金融サービス業のクライアントは必要な時にいつでも、構成済みのプルーフページをPDFフォーマット、EDGARII、およびHTMLで受け取ることができる。またXMLは、出版物に含まれるコンポーネント候補群の基準評価のフィルタリング機能も果たす。

本発明の実施形態において、システムはドキュメントの構造情報を維持したままポイント・アンド・クリック操作で作業ができる新しい編集方法を導入する。ストラクチャー・バーの概念については、詳細記述の項目に詳しい説明があり、また図20から図25の図中にも示されている。

本発明の実施形態において、システムはクライアントによって起動開始され、クライアントによって管理される。ユーザがリアルタイムで操作することは、資料の物理的な受け渡しの必要性、またはファックスで植字業者に送られる必要性がなくなることを意味し、その結果クライアントが植字業者からプルーフが届けられるのを待つ間の締切までの時間の遅れがなくなる。クライアントはドキュメントの最新プルーフを、いつでも追加料金を払うことなく、最小限の遅れで作成することができる。クライアント・ユーザは彼らの作業と工程を完全管理する。クライアント以外の第三者サービス業者がコンポーネントまたはドキュメント・データに触れることは決してない；クライアントのみがそれを実行できるのである。生産システム課程でデータが受け渡しされることは全くないため、植字業者によるエラーの概念そのものがなくなる。

クライアントは、クライアント・インターフェイス（コマンド・レイヤー）（図1参照）に組み込まれた許可システムを使うことによって、ユーザの詳しいパーミッション・リストを設定し、システム全体を管理する。パーミッション機能は、見る側に表示されるシステム・オプションを含むユーザ・インターフェイスの様々な様相を管理する。コンポーネントおよびドキュメント・データは、クライアントまたはサービス業者の人間であろうと、権限付与されたユーザでなければ、見ることまたはアクセスすることさえ出来ない。クライアントの仕事の安全性は、従来型の製造過程で行われていた手渡し工程で起こり得た妨害から保護されている。本システムは、コンテントのソースおよび構成されたページを含む全ての出力フォーマットの生産者の両方であり、出版のための継ぎ目のない生産システムである。

本発明の実施形態において、システムはインターネット上のウェブ環境で、または専用イントラネット上で同様のプロトコルを使って操作できる。クライアントのコスト面での利点は、機器またはソフトウェアを購入する必要がないことであり、ほとんどのクライアントは常時インターネットにアクセスできる状況である。クライアントはリアルタイムでウェブを通して本発明システムおよびサーバと対話する。ユーザは、一般ブラウザを搭載したマシンとインターネットへの接続環境さえあれば、昼、夜、またはタームゾーンを問わずいつでも何処からでも本システムにアクセスすることができる。したがって実効上、本システムは閉じられることはない。本システムはLAN接続に依存する必要がなく、したがってサイトまたは装置として独立する。

本発明の実施形態において、システムは全てのクライアントのドキュメントおよび出版スケジュールのプロファイル表を記憶保存する。これらの表は、ドキュメント内で（複数レベルで）扱われるクライアントの商品、サービスおよび／またはトピックスのような、クライアント・ドキュメントの主題の他側面も記憶する。例えば、多くの金融サービス会社は投資信託をいくつかのファンド・タイプ（equity、bond、balanced、money marketなど）あるいは商品ラインを扱う金融趣意書の中に混ぜたりする。クライアントはまた、retail、institutional、private managementなどの、異なったシェアクラスのファンドに対して別々の金融趣意書を発行することもある。後半でビジネス・オブジェクト定義として記述され、図6および図7の中で図式説明されたようなプロファイル表は、指定されたドキュメントに特定コンポーネントを適用するためのフィルタリング・システムの一部である。プロファイル表はクライアントのニーズに合わせて再構成可能で、データは再変更が可能である。コンポーネントをドキュメント内に含むべきかどうかの評価を行う“ビジネスルール”も、構成可能である。

表および脚注を含む全てのコンポーネントは、たとえそれらがひとつのドキュメント内にしか含まれていない場合でも、特定ドキュメントから独立した形で存在する。コンポーネントはどんなドキュメントにも適用可能で、コンポーネントが更新された場合には、更新されたコンポーネントがそれが存在する全てのドキュメント内に（それぞれのドキュメントの有効期日設定に応じて）自動的に適用される。

本システムはテキストの言語特性の相違、異なる複数の法規環境に適合すべく作成されたトピックの照合、および異なったマーケット設定における商品用語とID番号によって、コンポーネントの同等性を認識する。この同等性は、自動言語翻訳機能、および国または州ごとの異なる必要条件に適合しなければならない取締所用ファイリングのための基本となるものである。

表および脚注は特別に設定された管理モジュールによって処理される。このサブシステムによって、表はデータが使用可能になる際に作成され、一旦作成が完了すると自動的に適切なアクティブ・エディションに適用される。また、表はそれらが適用されるであろうドキュメントに対して、前もって作っておくこともできる。脚注も、独立したコンポーネントとして作られ維持され、特別に作られたユーザ・インターフェイスによって、容易に表全体に、または表内の個々のセルやパラグラフに適用することができる。

全てのコンポーネントの修正履歴は、そのコンポーネントの生涯にわたり、全てのドキュメントを通して追跡管理される。修正ログは全ての修正記録を表示し、これに対してユーザは説明メモ、修正日の記録リスト、修正を行ったユーザ名、ユーザがコンポーネントにアクセスしたドキュメントの表紙の目付け、修正が行われた際のプループ番号、もし適用できれば出版日、およびコンポーネントテキストのブラックライニング表示を添付することができる。ドキュメントのプルーフは、ユーザが新しいプループを制作する際にいつでもブラックライニング表示付きに設定することができる。（ブラックライニングとは、これまでに行われた修正、削除、および追加箇所を校閲プルーフ上に表示するマークを意味する技術用語である。）

本システムによって、クライアント組織の内部および外部の共同作業熟練者は、電子的に校閲およびコメントすることができる。校閲者は制作されたプルーフの特別表示バージョン上にコメントを入力し、ドキュメント内のどんなコンポーネントにもコメントを添付することができる。これらのコメントは解決されるべき問題として追跡管理される。

自動化されたビュー・トランスフォーメーション機能は、プルーフを作成したりドキュメントを出版するためのリクエストに結合する。EDGARIIのようなフォーマットはタイプセット・プルーフを作成するものと同じ仮想ドキュメントからデータソース送信される。どのようなフォーマットで作成するか、およびどの時点で作成するかは構成選択が可能である。

特有の動作が行われた場合、その特有の動作に対する全ての通知を受け取る許可を持っているユーザのもとに自動的に通知が送られる。システムからユーザへ送られる自動通知内容には：PDFプルーフが利用可能になったこと、ドキュメントの新しいエディションが開始されたこと、表がアップロードされたこと、およびドキュメントの出版が完了したことが含まれる。コンポーネントへの変更は特別なマークによってコンポーネントの表示欄に示される。（修正ログは変更を記録する。）

本発明は、内容埋め込み式の連続ドキュメント・ファイルではなく、ドキュメントの仮想エディションをアセンブルし、作成するものである。ドキュメントは、組織の内部・外部を問わず特定の受け取り人一式に一連の情報を伝える目的で、コンテントが総合集結したものである。この定義では、ドキュメントは文書やメモのように仕事仲間内で使われる一時的な情報伝達ではない。本発明の実施形態におけるドキュメントは、何らかの正式な、またはフォーマットで広い範囲に配布すべく表示される。ドキュメントはタイトル、および他の識別子、説明文、図形イラスト、グラフ、表、目次およびインデックスのような内部参照、脚注やウェブサイトリンク情報などの他の参照事項を（しかしこれらだけに限らず）含むことができる。

本システムは、構造ドキュメント概念を利用している。構造ドキュメントはコンポーネント部分の配列順序、階層型の関係、および要素の種類など、その文字通りの内容または意味から独立して記述することができる。多くのビジネス・ドキュメントおよび法規ドキュメントには、それらが構造処理に適したドキュメントになり得る次のような2つの特質がある：（1）金融および法律ドキュメントなどの多くのドキュメントには、決められたコンテントが含まれる。（2）ほとんどのビジネスおよび政府ドキュメントは、一貫したテンプレートまたはテンプレート一式に従って作られる。したがって、基準が正式に決まっているか、あるいは慣習によって間接的に示唆されているかに関わらず、根本基準に従うべく一連のシーケンスルールおよび名前が付けられたコンテント要素を開発することが可能である。新規ドキュメントおよびコンポーネントはルールに従うことによって構築可能である。

本発明の実施形態において、ドキュメント・セット全体のテキストおよびコンポーネントは、パブリケーション・セットと呼ばれる小さな個別の構成要素へと分けられる。基本的に、全てのヘッド、サブヘッド、パラグラフ、表中セル、脚注、リストアイテムおよびその他は、独自のIDでコンテント・コンポーネントとして識別され、ドキュメント要素によって参照可能である。XMLにおいて、要素は公表された名前、内容の種類、およびドキュメント内に所在を持つ判別済みのドキュメント・データ部分のことである。要素は、親要素および他要素（子要素）を含むこともできる。また要素は、テキストデータ、他表示方法（例えばイラストのような）および他種類のデータを含むことができる。

低レベルの要素は、文脈を持ったテキストをドキュメント内に供給する高レベル・コンポーネントの子である。これらの高レベル・コンポーネントは“危険要素”または“不確定責任”のような記述的なマークアップによって識別可能である。要素の文脈は階層的で、ドキュメントの根本となる要素自体から始まる。（その根本となる要素とは、ドキュメント内の主要要素であり、要素だけを含み、他の全ての要素の親である。）要素の文脈はメタデータの一部であり、ドキュメント作成やテキスト検索のフィールドを狭める時など、多くの工程に欠かせないものである。（メタデータとは、要素、ドキュメント、およびその他、例えばタイムスタンプ、著者、最新の更新、出版物の種類、文脈、表示名といった要素の内容とは別の要素についてのデータの集合体である。）要素には、ライブラリの中で特定のコンポーネントを位置づけるために使われる、コンポーネント・プロパティのためのルールまたは条件が含まれる。例：1anguage must equal“Spanish．”（言語は“スペイン語”と同等でなければならない。）

本発明において、コンテント・コンポーネントは独立した個別の記録としてドキュメント・インデペンデント・テーブル内に記憶保存される。ある出版エディションは、それを構成する要素のリストとして仮想的にのみ存在する。要素はコンテントを直接持たず、それぞれのコンポーネントIDと繋がっている。この方法によって、あるひとつのテキストを異なった出版物間で複数の異なった要素によって共有することが可能となる。要素マップは、既存出版物を使って新規出版物を作る際の基盤として使うことができる。

本システムは、バージョン管理されたコンポーネントのコンテント・ライブラリを維持することによってコンテントを管理する。コンポーネントは、キー値ペアであり、コンポーネントを有意義な形で記述することができるプロパティを持つ、コンテントのセレクションである。コンポーネントの種類には、テキスト、脚注、表、外部データを送り込むためのポインタ、数字データ、グラフィック、ドキュメントの断片、内容グループなどが（しかしこれだけに限らず）含まれる。それぞれのコンポーネントは、コンテント・ライブラリ内の分割要素である。コンポーネントは複数の出版物の間で共有することができる。新規コンポーネントはライブラリ内に追加可能で、既存コンポーネントを基盤とした子孫として分けられる。保存されているデータの量を必要最小限にするために、本システムはライブラリ全体の中で複製されたコンポーネントを探知することができる。コンポーネントは、本システムの統一された検索機能を使って検索することができ、その機能はシステム上全てのオブジェクトに関連し、フルテキスト検索機能を持つ質問システムとして操作することができる。検索はアクティブ・エディション編集中にも実行でき、また出版物やエディション別に個別に実行することも可能である。コンポーネントには様々な評価を添付することが可能で、その内容には、例えばいつそれが有効か、あるいはいつそれらのコンポーネントが初めてアクティブ・エディションで使用されたか、またそのコンポーネントはもはやどのアクティブ・ドキュメント内の一部でもないことなどがある。追跡記録は、全てのコンポーネントの作成日、制作者名、更新日、更新したユーザ名、修正の理論的根拠、およびブラックライニング変更を表示するために作られるものである。

コンテント・グループは、複数の特定コンポーネント・バージョンがある場合に構築可能で、その複数のバージョンは通常の言語、各国の特定の語法の相違、および法規や異なったマーケット階層への対応または異なった複数の商品モデルに対応するなどのビジネスルールに目的をしぼった語法の相違を表示することができる。このような複数のバージョンは、いくつかの点で関連し合うことがある。例えば、各コンポーネントは同内容の事柄を扱っていながらも異なる言語で表示されていたり、あるいは異なった地域の法律をカバーしている場合等である。他のコンポーネントと同じように、コンテント・グループは独自のプロパティを持つことはできるが、独自のコンテントは持っていないのである。むしろ、コンテント・グループは他のいくつかのコンポーネントを参照する。コンテント・グループは、システムのプロパティや環境に対する評価を基に、コンポーネント群の中からひとつのコンテントを供給する。コンポーネント・バージョン間にはそれぞれ強い、あるいは弱い関連性が存在し、その関連性はコンテント群の主要メンバーへの従属性への強弱によって表示される。

脚注や表は独自のライブラリ一式を作成する。表中の事柄はドキュメント・インデペンデント・ライブラリとして維持され、アクティブ・エディションとは別に校正および編集することが可能である。ライブラリ中の表は、どんなドキュメントに対してもシングル・コマンド適用が可能である。第三者より取得しなければならない表データは目標テーブルの種類および目標ドキュメントを識別する予め用意されたプロトコルを使ってシステムに取り込み可能である。またプロトコルを使って、脚注をデータ・フィードに割り当てることも可能である。とりわけ、本システムはディスクロージャーおよび脚注のライブラリを維持するのに適している。ユーザ・インターフェイスによって、脚注を表全体または個別の表中セルに簡単に割り当てることができる。インベントリー・データのような追加の個別ライブラリは、クライアントのニーズに合わせてシステムに加えることができる。

本システムは、特定デブロイメントのための広範囲の構成変更が可能である。デブロイメントは、ユーザ組織のニーズを基にオブジェクト・テーブル、プロパティ、ルール、およびルーチンによってサポートされたシステムの特有構成である。システムの特定動作は、デプロイメント工程の一部として構成することが可能である。

広い観点から見て、顧客ビジネスルールおよびデータによって出版物の違いを決定することが可能である。様々な組織は部署ライン、商品ライン、ターゲット市場、国家の境界、専門的技術の領域、および思考の類似によって出版物の所有権および責任を分割または確立したりする。こういったデータにより、ドキュメントのオーサリング工程は自動化可能であるが、しかしそうするためにはデータは構築されたフォーマットに取り込まれなければならない。こういった構築済みのデータを考慮することは、以下のような作業を行う上で有用である：出版物の主題の確定、テキストおよびウェブアドレス、またライブリンクの挿入ポイントの制作、編集の際に使用が考慮されるコンポーネントの適正判断、および変動要素の決定。各クライアントのために特注のプログラムを書く必要性をなくすために、本システムは構造的データ一式の構築のための一般化された方法論を有する。このデータ一式は、処理要求されたシステムの多くの基本となる機能へと統合される。この方法は、デプロイメント時に構成変更が可能で、データ更新のためのユーザ・インターフェイスが備えられている。

本システムは、ビジネス・オブジェクトとして構成を行うクライアントの特有データを活用することが可能である。ビジネス・オブジェクトは正規のフレームワークに従ってそれぞれのデプロイメントのために作られたビジネス・オブジェクト定義ファイルのひとつと適合しなければならない。定義ファイルにはオブジェクトタイプの名称、およびドキュメント内容に影響を与える可能性、またはテキスト作成や可変解決のために使われる可能性のあるプロパティ一式が含まれる。

本発明の実施形態において、各出版物は環境またはビジネス・オブジェクトの関連性およびドキュメントに関する出版特性を持つ。その環境は、プルーフのための出版物一式からコンポーネント・レベルに至るまで、複数レベルで関連させることが可能である。環境は、親オブジェクトから子オブジェクトへとデータ継承していく有用性の集積である。例えばアクティブ・エディションにエディション・レベルで特定の環境セットがない場合には、出版物の親データファイルから、または最近の出版物一式の親データファイルから継承される。

ドキュメント・オブジェクトは通常、例えば翻訳されたドキュメントにどのバージョンのコンポーネントを組み込んでおくかを決定するような、動作を起こすための環境変数を評価する使用法ルールと結びついている。このルールとはビジネス・オブジェクトや属性価値をローカル環境で参照する陳述である。それは仮定側および結果側から成る。仮定側は“真実”か、さもなければ価値を満たしているか、またはその結果動作が起こるための比較陳述を評価する状況を設定する。結果側は、それらの多様な評価結果に対して行われるべき動作を記述する。例えば翻訳ドキュメントにおいて出版物は、全てのコンポーネントが照合する言語プロパティ・バリューを設定するためにアクティブ・エディションから継承された、言語の値を持つことになる。

本システムは、ドキュメントをテキスト・ストリームとして保存するのではなく、オンライン上の構造ドキュメントの要素へのポインターとして保存する。要素は結果として特定のコンポーネントを示唆することとなる。この組織は非反復保存を促進し、そして最も重要なことに、その要素を通して示唆される修正済みのコンポーネントが全ての出版物において自動更新されることが可能である。要素およびコンポーネントの双方は（それぞれに）属性および所有性を持ち、それらの値はクライアントの特有ビジネスルールに従って特定の出版物／アクティブ・エディション・プロパティへと配置可能である。

出版物は全てのエディションの親であり、構造化ドキュメント定義によって管理され、そして本発明の実施形態においてはパブリケーション・タイプと呼ばれる。パブリケーション・タイプは、ドキュメント構造（図5参照）としてメモリー内で具体化され、ドキュメント構造はエディション構築の際、オートポピュレータをガイドする。（図11参照）

修正可能段階の出版物であるアクティブ・エディションは、ライブラリに保存されているコンポーネントを参照する要素からアセンブルされる。新規のアクティブ・エディションは、出版物アーカイブの中に記憶されている既存エディションから作成することも可能である。

アクティブ・エディションがユーザによって開かれる度に、本システムは要素のリストを集め、それを通して最新状態のコンポーネントを作成する。エディションはこのプロセスの中でアセンブルされるのであり、物理的ストリームとして編集のために保存されることはない。エディションは外部への配布（例えば、プルーフ、EDGARIIファイル、ウェブ・ポスティング、出版されたドキュメントのアーカイブなど）のためにプロセスされる時だけ、実在物として存在するのである。

ユーザが、既存出版物の新規エディションを開始する際（図13参照）、本システムは以前のエディションの情報を検索し、新規エディションを構築するための土台となるエディションとして検討することが可能である。もし土台となるエディションが保管された後にコンポーネントのどれかが更新された場合には、リファレンス機能によって最新版のコンポーネントが組み込まれる。本システムのドキュメント・マネージャと呼ばれる部分は、ドキュメント・アセンブリをオートポピュレータに送り、オートポピュレータは最新のビジネスルールや出版環境に従っているかを確実なものにするためにオンラインで出版物の各要素を再評価する。（図13参照）ビジネス・オブジェクトおよびルールが変更された場合には、特定の要素は出版物の中からはずされることもある。本システムは、以前有効だった要素を省くことはせず、エラーが表示されるソフト・インクルージョンという状態でその要素を保存する。そしてそれらのソフト・インクルージョン状態の全ての要素は（a）ユーザによってエディションから削除されるか、または（b）エディションが出版される前にその使用ルールの変更に対する要素の有効性を確認されなければならない。

以前有効だった法的要素を無効にする使用法ルールの変更のひとつの例は、金融サービス会社が以前は単一だった金融趣意書を、小口投資家用と機関投資家用の別々の出版物に分ける場合である。ビジネス・オブジェクトはこの変更を反映するために更新され、それによって機関投資家用に特定されていた言語表現は小口投資家用の出版物では使用可能の状態ではなくなる。そして小口投資家用の金融趣意書には、システムはもはや“機関投資家”用の特性を持ったコンポーネントは選択しない。

アセンブリ工程において、本システムはシステムに組み込むための候補要素を評価する。候補となる要素は、特定のドキュメントを特定な場所に含むための必要条件を全てにおいて、または部分的に満たしている要素である。候補は、最も特定なものからより一般的なもの、つまりプロパティとの照合条件をたくさん満たすものからあまり満たさないものの順で評価される。言語形態のようないくつかのコンポーネント・プロパティは完全なマッチングが必要とされ、もしマッチするものが見つからない場合は、どの候補要素も結果として表示されない。

ドキュメント・アセンブリはドキュメント環境システムによって複数のルールを基に管理されている。これらのルールには以下のことが含まれる：
ａ）完全な条件付き用語（ルート要素から始まる、全ての親ファイル）または相対的な方法（特定の親要素などの上位互換ファイルの参照）によって表される。；要素の文脈プロパティは選択された挿入箇所と照合しなければならない。XMLを基盤としたルールは、特定の構造を要求することによって、アクティブ・エディション内で要素のアセンブリを制約することが可能である。
ｂ）ローカル環境で評価されるビジネス・オブジェクトルールおよびプロパティ。特定デプロイメント・ビジネス・データが、特定の内容がアクティブ・エディションまたは一部の有効範囲の中において適任であるか適任でないかの決定を支配することが可能である。
ｃ）要素または要素およびその親の両方かのどちらかの特性有用価値を評価するルール。部分的な環境プロパティの切り換えで、内容が適任か不適任かを決定することができる。その良い一例は、アクティブ・エディションの部分内での特定言語の設定であろう。
ｄ）コンポーネントが、アクティブ・エディションに含まれる適任性を持つために従わなければならないルール。
ｅ）特定の環境売価値上で切り換えられる、ひとつのコンテント・グループ内でのコンポーネントのダイナミック代用。例えば、同パラグラフ上での英語版とフランス語版の切り換えが、この仕組みで遂行可能である。

ユーザが新規の出版物の初回エディションを開始する際（図13参照）、本システムは要素とコンポーネント候補の決定を上記方法によって行う。もしある場所にマッチする要素が見つからない場合は、システムはパブリケーション・タイプの形式構造ルールに従って、エディション中に必要な要素のためのプレイスホルダー（場所を確保するもの）を挿入する。少なくとも、エディションはこれらのプレイスホルダーによって構成される形となる。最良のケースでは、エディションはライブラリ中に存在する文脈条件を満たした全てのコンポーネント、および必要とされるがまだライブラリの中に存在しないコンポーネントのためのプレイスホルダーで構成されることになる。

本システム全体の根本下部構造に、ドキュメント分析および／または組織スタイルおよびビジネスルールの正式記述によって形成された会社のドキュメントの構造マップがある。これらの構造マップはドキュメントを総称的に記述するために規格化されたsyntax（シンタックス）に従い、XML Document Type Definitions（DTDs：ドキュメント・タイプ・デフイニッション）またはXMLスキーマを使うこともある。

ストラクチャー・バー編集インターフェイス
本発明は、構造ドキュメント、特にXMLドキュメント編集のためのユーザに分かり易いエディターを提供する。旧式の構造ドキュメント編集方式に対して、多くのユーザが感じていた大きな難点は、（a）システムを簡単に使用するためには、多くのマークアップ言語原理の知識が必要とされること、または（b）非常に少ない構造部分しか表示されないため多くの間違いが発生し、またそれはマークアップ確認時にのみしか発見されないことだった。

本発明によって採用された解決法は（1）ドキュメント・アウトラインをピュアXMLスキーマ・アブストラクト・ツリーおよびドキュメントの実際内容との複合型として表示することであり、これによってユーザはトピック・アウトラインの認識が可能となる。（2）ドキュメントのマークアップ言語に含まれる構造情報をドキュメントのテキストから分離させる。これによってタイプセット・ページに近いフォーマット（以下“WYSIWYG”とする）での編集が可能となる。

本システムのドキュメント編集システムは、図20で表示されているユーザ・インターフェイス1を有し、それは次の3つの主なコンポーネントから成っている：ひとつめはドキュメント構造を示す収納型複合ツリー10で、画面の左側に（しかしこの場所に限らず）配置することが可能である。次に編集可能なWYSIWYGドキュメントが表示されるエディター・ペイン30、そしてエディター・ペインの内容についての構造情報を図形を使って表示するストラクチャー・バー20である。ユーザ・インターフェイスは多様なコントロール・ボタンやアイコンを表示するツール・バー40も含む。

複合ツリーはドキュメント構造、またドキュメントのスペックによって定義される“required−and−missing：必要−および−欠けている”構造を表示する階層型表示のナビゲーション・ツールとして使うことができる。図21で示されている複合ツリーは、コンテナ・ノード11、コンテナ・ノード21、ゴースト・ノード31、マルチ・ノード・41およびエラー・インディケータ51から成っている。コンテナ・ノード11はドキュメント・セクションの個々の内容部分を表示する多数のコンポーネント・ノード21を含んでいる。複合ツリーは、コンテナ・ノード11またはコンポーネント・ノード21のどちらかをクリックすることによって編集したいドキュメント部分を選択するのに使われ、その時点でエディター・ペインはドキユメントの選択された部分をWYSIWYGによって表示する。選択されたノードは現在選択されているドキュメント・セクションをハイライト表示し続ける。

ゴースト・ノード31は、まだ実在しないがスペック内で定義づけられているドキュメントの部分を表す。ゴースト・ノード31とつながっているマルチ・ノード41は、スペックによってコンポーネントの反復使用が可能なことを表している。エラー・インディケータ51は、スペックがコンポーネントまたはコンテナの存在を要求することを示すために、ゴースト・ノード31と共に表示される。ユーザはゴースト・ノード31上をクリックすることで、このエラーをすばやく処理することができ、これによって適切なコンポーネントの追加が可能となる。

本システムは図23で示されている様に、ストラクチャー・バーとして知られるツールも利用している。ストラクチャー・バー20は、アクティブ・エディション30のWYSIWYG表示に影響することなく、アクティブ・エディション30の概念的および組織的構造を記述する。ストラクチャー・バー20は、コンポーネントとセクションの再配列、移動、削除、および挿入を通して、アクティブ・エディションの操作を容易にする。またストラクチャー・バー20は、コンポーネントのメタデータへのアクセスや更新も容易にし、XMLスキーマで記述されたアクティブ・エディション30の中で、操作の致命的欠陥をユーザに知らせる。

ほとんどのワード・プロセッサはWYSIWYG環境での編集機能を備えているが、それらはドキュメントの概念的構造およびそのルールについての情報は伝達しない。その上、構造ドキュメントの編集機能を備えている多くのXMLエディターは、WYSIWYG環境での編集機能の利点に欠けている。ストラクチャー・バーは、目に見えない（そしてその結果、WYSIWYGの有効範囲外の）構造要素を基にした情報を表示する。ストラクチャー・バー20は、ブラケット表示を使用するコード・エディターとは違い、これらの“ブラケット（角括弧）で括られたグループ”をひとつの統一体として操作することが可能である。

ストラクチャー・バー20は、明確で完全に統合された構造およびコンテントを強制する。これによってコンテントを寄稿する編集者は、構造内容の複雑さから保護されポイント・アンド・クリックの慣れ親しんだ環境での作業が可能である。構造的な変更は、ドラッグ・アンド・ドロップを使用して、コンポーネントの挿入、再配列、および削除ができる様シンプルに作られている。

ストラクチャー・バー20は、追跡記録されたアクティブ・エディション30の左隣に縦位置に表示される。右側に表示された各コンポーネントには、それぞれ左側に呼応するハンドル12がある。ハンドル12は、関連し合うコンポーネントへの直接操作を可能にするコンポーネント82をアイコン化して表現したものである。ハンドル12は呼応するコンポーネントを縦位置に記録する。コンポーネントを削除するには、ハンドル12をゴミ箱アイコン72にドラッグする。コンポーネントを移動するには、ハンドル12をアクティブ・エディション30内の新規目的場所にドラッグする。

加えて、コンテナ22はストラクチャー・バー中に表示ハンドルを有する。コンテナ22はアクティブ・エディション内のセクションを表示する。それらはセクション内に属するコンポーネント82のハンドルを持ったブラケットとして図形的に表現される。コンテナのハンドルは基準コンポーネントを表象するハンドルと同じ方法で操作が可能である。ハンドルを移動／削除した時の結果は、それが含まれる全てのコンポーネントに反映される。

コンポーネント82またはコンテナ22をアクティブ・エディションから削除するには、そのハンドルをゴミ箱アイコンへドラッグする。コンポーネント82またはコンテナ22をアクティブ・エディション30内で移動するには、ハンドルをエディター・ペイン内の移動させたい場所へドラッグする。コンポーネント82をアクティブ・エディションに挿入するには、挿入アイコン62をエディター・ペイン内の挿入させたい場所にドラッグする。

ストラクチャー・バーおよびエディター・ペインは、コンポーネントをドラッグして挿入／移動している間バイタル・フィードバックを供給する。コンポーネント82またはアイコン62がアクティブ・エディション30上にドラッグされる際、現在選択されている挿入箇所を示す線がアクティブ・エディション30内に引かれる。挿入を示す線は、マウス・ポインターに一番近いコンポーネント間に引かれる。これらの挿入線が引かれるにつれ、挿入箇所と思われるものを有するコンテナ22はハイライト表示される。ふたつの隣接するコンポーネントが異なった親コンテナを持っている場合、挿入箇所はコンポーネント間に必要な数だけ利用可能で、適切な親コンテナがハイライト表示される。

ハンドル上でマウスをロールオーバーさせると、ハンドルはハイライト表示されツール・チップが現れる。このツール・チップは、コンポーネントのXMLタグ名、およびディスプレイ名のようなメタデータを（しかし、これだけに限らず）有する。ハンドルをダブル・クリックすると、コンポーネント・メタデータ・パネル全体が現れる。このパネルは表示可能で、これによってユーザはデータを適切なコンポーネントに変えることが可能である。

複合ツリーでは、スペックによって要求された内容が欠けているアクティブ・エディション30内の位置を示すために、ミッシング・コンポーネント・インディケータ32を表示することが可能である。これによって、ユーザはスペックにマッチするための何らかの操作を行う必要性を知る。全てのエラー・インディケータの内容に関する追加情報は、クリックまたはロールオーバーすることによって見ることが可能である。

図24は、ユーザがアクティブ・エディションを編集する間に実行可能な操作を示すフロー図である。S100で、ユーザが多くの操作の中からひとつを選択する時、工程が開始する。例えば、ユーザはS110で、スクリーン上のテキスト編集を選ぶことが可能である。その後、S111においてWYSIWYG表示のテキストが編集可能となる。テキスト編集の後、ユーザがSl12でエンター・キーを押すことによってポップアップ・ウインドウを開き、ユーザはSl13でその編集されたテキストに関してのコメントを付けることが可能である。ユーザは、Sl14でコメントを提出し、編集されたテキストおよびコメントはSl15で新しい訂正として保存され、工程はS170において終了する。

S120では、ユーザはハンドルを掴んで関連するコンポーネントを異なる場所へドラッグすることが可能である。それからシステムはS121で、新しい場所が適切な目的場所であるかどうかを判断する。目的地が適切な場合、コンポーネントは新しい場所に移動され、S123でアクティブ・エディションおよびストラクチャー・バーの両方が新しい場所のコンポーネントを表示する。目的地が適切ではない場合は、コンポーネントはS122から移動されない。

S130では、ユーザはハンドルを掴んでゴミ箱アイコンにドラッグすることが可能である。これにつながるコンポーネントは、S131でアクティブ・エディションから削除され、コンポーネントがアクティブ・エディション内で必要とされているかどうかがS132で判断される。もしそれが必要とされていない場合は、工程はS170で終了する。コンポーネントが必要とされている場合は、コンポーネント・ノードはS133で複合ツリー中にゴースト・ノードとして表示される。

ユーザは、S140において追加したいコンポーネントを掴み、目的の場所にドラッグすることでアクティブ・エディット内にコンポーネントを追加したい場合がある。S141では、ポップアップ・ウインドウが現れ、S142においてユーザが選択できる様に希望する場所のための適切なコンポーネント全てを表示する。選択された後、コンポーネントはS143でアクティブ・エディション、複合ツリー、およびストラクチャー・バー内に表示される。

ユーザがコンポーネントとつながったメタデータを編集したい場合には、ユーザはS150においてハンドル上をダブルクリックすればよい。S151でポップアップ・ダイアログボックスが現れ、ユーザはコンポーネントとつながったメタデータを編集することができる。

またユーザは、ストラクチャー・バーのオン／オフをトグル式にすることも希望可能で、その場合ユーザはS160においてストラクチャー・バー・トグル・ボタンをクリックすればよい。それからS161で、ストラクチャー・バーが視覚表示されているかどうかの判断がされる。ストラクチャー・バーが視覚表示されている場合は、ストラクチャー・バーはS162で消える。ストラクチャー・バーが視覚表示されていない場合は、ストラクチャー・バーがS163で現れる。

図25は、アクティブ・エディションの修正シーケンスを示している。このシーケンスの中で、ユーザはS210においてエディター・ユーザ・インターフェイスを使ってアクティブ・エディションを修正する。S220では、システムは上記修正をサーバに知らせる。そしてS230で、サーバは修正を実行し、S240で修正済みアクティブ・エディションのスナップショットを送る。S250では、エディターが修正後のアクティブ・エディションを表示する。

図22は、ユーザが複合ツリー内で実行可能な動作を示している。S305で、ユーザは実行したい動作を選択する。ユーザがS310でノードをクリックした場合には、エディター・ペインはノードをツリー中の最も高レベルで表示し、S311でノードの全ての内容とそれに呼応するアクティブ・エディション内のサブ・ノードを表示する。S320でユーザが拡張ノードの拡張タブをクリックした場合は、S321でノードが拡張されたかどうかの判断がされる。ノードが拡張されていない場合は、ノードはS322で拡張表示に変わる。ノードが拡張されている場合は、ノードはS323で非拡張表示に変わる。S330において、ユーザがディスプレイ名表示をクリックした場合には、システムはS331でディスプレイ名が表示されているかどうかを判断する。ディスプレイ名が表示されていない場合には、それらはS332で現れる。ディスプレイ名が表示されている場合には、それらはS333で消える。ユーザがS340でタグ名表示をクリックした場合には、システムはS341でタグ名が表示されているかどうか判断する。タグ名が表示されていない場合はそれらはS342で現れ、表示されている場合は、S343で消える。

校正、校閲サイクルおよび問題追跡システム
ユーザは、一連の修正を終えた後エディションをそれが配布されるフォーマットで校閲することが可能である。ユーザはプルーフを作成することによって、それが可能である。本発明においては、プルーフはその時点でのアクティブ・エディションの静的な表象物であり、それはPDFまたはHTMLファイルのような、携帯可能なフォーマット形式のタイプセット・ページである。校正の特権を有するユーザは、エディションが使用可能な時はいっでもプルーフを作成することができ、プルーフは数分以内にウェブ、FTPサイトまたは他のネットワーク・プロトコル・サイト上で、閲覧またはクライアントによる使用が可能となる。プルーフはそれらのネットワークを通して、PDFまたは他のフォーマットで用意され、配布されることが可能である。他にも多種類のフォーマットが、各プルーフの自動作成において可能である。ブラックライン表示のプルーフも、いっでも、それまでのどのプルーフに対しても、プルーフ作成の一部として要求することができる。作成されたプルーフ、コンポーネント、および出版されたプルーフは、後にアクセスできるよう保存される。

本発明におけるシステムは、複数の校閲者がプルーフを見ることができる校閲サイクルの概念を導入する。社内および外部の校閲者の双方が電子的にコメントを供給でき、彼らのコメントはプルーフ内のどの箇所にも添付することができ、問題として追跡管理される。会社内ユーザはEメール、または付属のコメント機能を使って返答することができる。校閲の際、校閲者達が停止した状態のプルーフを見ている間、ユーザはアクティブ・エディション上で作業を続けることが可能である。校閲者からのコメントに対する変更を開始するのを待たずに、コメントは積極的および対話形式的に機能することが可能である。

全てのコメントは問題追跡管理システム内に入れられる。問題はコメントおよびコンテントに関する質問、コンポーネントの通用性および適用性、バージョン、方針などを追跡管理する。問題はエディション出版、コンポーネントの翻訳またはローカライゼーションの開始、または複数の出版に影響を及ぼすであろう拡張方針を設定するために解決されなければならない。ユーザは問題に優先レベルを割り当てることが可能で、各レベルはデブロイメント構成によってシステムの行動が決定される。問題は特定のチームメンバーに割り当てることが可能で、その状況ごとに追跡管理される。可能な問題状況には：未解決、訂正、解決済み、および据え置きがある。問題はユーザによってポストされ、または限定された状況下ではシステムによって自動的に呼び出されることが可能である。その状況には、例えばコンポーネントが新しいコンポーネントが利用可とならないまま有効期限を過ぎてしまう場合がある。コンポーネントの翻訳が見つからない場合のような問題は、ユーザの一部または他のシステム機能による適切な処置によって解決することが可能である。

翻訳管理
本システムは、言語別出版または多言語エディションのドキュメント管理が可能である。市場や法規条件は、国、州、地方によって異なるので、本システムのデザインは、地理環境における個別要求も認識する。

言語は頻繁にひとつ以上の独立国家において使われるため、翻訳版またはローカライゼーション版は複数の独立したプロパティである。例えば、国家法規条件の独自セットを有するスイス国版のドキュメントは、フランス法律ではなくスイス法律に従うために、しばしばドイツ語、フランス語、イタリア語、および英語で表記される。スイスにおけるフランス語はフランスにおけるものと異なる言葉遣いが必要とされることがあり、これと同じことが、他言語の組み合わせやローカライゼーション・プロパティでも起こる。本システムはコンテント・グループごとにバージョンを保存する機能によってこの状況を管理し、そこにおいてはコンポーネントは他メンバーに準じ、またコンポーネントは他メンバーに対して強あるいは弱の従属性を持つことが可能である。

最も常習的な場合、出版物は最初ひとつの言語で作成される。これは著者の母言語によることが多いため、この原型バージョンが権威ある、または“本来の”バージョンとなり、そのコンポーネントへの訂正は他言語バージョンでの訂正を引き起こす。このような状況では、翻訳バージョンは原版への強い従属性を持つことが必要とされ；他バージョンは原型に“準ずる”。

従属性の弱さは、ネットが拡張するにつれ、特にバージョンが使用言語およびローカライゼーションの両方、または他のプロパティによって分岐する際に目立ち始める。ネット上の末端に位置する版は初版に依存しないだろうが、権威バーションから派生した2次出版物に関連し、原版への弱い従属性は、ネットの末端に位置する出版物の訂正には直接影響しない。この出版物は、本来の権威あるバージョンへの訂正に対する通知を必要とするかもしれないが、その通知のみでは訂正行動は起こるに至らない。

本システムは、本来の言語に2次的な言語によるコンポーネントが存在するか否かをモニターすべく、構成されることが可能である。2次言語による出版物の存在、または制作が確認された後、システムは自動的にその言語バージョンを持たないコンポーネントを翻訳者および翻訳サービス会社に送るためにアセンブルする。細かいやりとりのメカニズムについてはデプロイメント時に構成されるが、それらは以下のことも含む。
1．翻訳者への／からの、構造的ファイルの転送
2．リアルタイム翻訳のための、専用のブラウザ・インターフェイス
3．バッチ処理またはリアルタイム翻訳のための、直接的データベース

必要とされる翻訳が欠けている各コンポーネントは、それに対して問題状況がポストされる。翻訳が見つかり更新された際、本システムはその間題状況表示を解決済み表示に変更する。問題表示スクリーンは、クライアントの作業工程のためのデプロイメント時に構成可能で、このような翻訳における個々の問題を表示するか、もしくは問題の種類ごとのサブ設定のいずれかを選択する。

バージョン化することは、言語翻訳やローカライゼーション以外にも、様々なドキュメント出版術を可能にする。それは同一国におけるマスター・ドキュメントと、地方政府のための変形版ファイリングをサポートする。例えば、アメリカ合衆国の保険プランは州によって特有の遵守内容を持っている。商品マニュアルには消費者のための拡張セールス情報、およびサービス組織のための独占技術情報を載せることも可能である。カタログは特定の市場に焦点をしぼることも可能である。

許可
本システムは、管理者によるアクセス／編集許可の割り当て、またはユーザへのワークグループ・メンバーシップの割り当てを可能にする。また、社内または外部からのシステム機能アクセスの差別化が可能である。プルーフプラス・クライアント・インターフェイス（コマンド・レイヤー）は、ユーザから届いたリクエストに対しての許可を実行する。許可システムは、ユーザのスクリーン表示およびユーザがログインする際に表示される他システム動作のためのポートレットを管理することにより、それぞれのユーザのシステム・ビューを管理する。例えば、ドキュメント管理を任されたユーザは、全てのシステム・オブジェクト（出版物アーカイブ、アクティブ・エディション、問題の追跡管理、チーム、およびアクティブ・エディションの校閲状況の完全明快な概要）の総合表示を見ることが可能である。寄稿編集者は、これより制限された概要しか見られず、アクティブ・エディション内の彼らが寄稿した部分または関係しているシステム機能のみへのアクセスが許可される。

本システムは、以下のような多数の個別ユーザ許可を（しかし、これのみに限らず）管理する、リクエスト・プロセッサを備えている。
●ドキュメントの作成
●コンポーネントの著述
●コンポーネント・プロパティの編集
●要素使用ルールの編集
●プルーフの校閲
●プルーフ上のコメント記述
●ドキュメントの更新（編集）
●プルーフの作成
●ドキュメントの承認および承認取り消し
●ドキュメントの出版
●ビジネス・オブジェクト表の更新
●表（内容）へのアクセス、作成、および編集
●ライブラリからのコンポーネント削除
●脚注へのアクセス、作成、および編集
●ドキュメントが出版された際の自動通知の受け取り
●新規ドキュメントが作成された際の自動通知の受け取り
●表の更新がドキュメントに行われた際の自動通知の受け取り
●クライアント側のシステム管理
●サーバ側のシステム管理
●印刷物制作のスペック
●伝達メモ

本発明の実施形態において、ユーザ・インターフェイスはインターネットを通してユーザをシステム・サーバに接続する。コマンド・レイヤーは、ユーザ許可を調べ、ユーザによって行われた選択をモニターし、適切な返答を表（ユーザへ）および裏（アーカイブなどに）両方に送る。その一例は、システム内で使用されるライブラリ、アーカイブ、およびプログラムのインターネット・サーバ上でのデータ保存である。本システムの実施形態において、ユーザはアクセス・ポータルとしてのブラウザを使ってウェブサイト上でログオンすることによって、システムと対話するのである。校閲者は、インターネットと通して共同作業工程に加わる事が可能である。インターフェイスおよび検索ツールはインターネットが基盤であるため、システムは常に利用可能で、インターネットにアクセス可能な全てのマシンから、タイムゾーンに関係なく作業を行うことが可能である。

印刷準備
印刷出版における問題を解決する本システムの実施形態において、システムは承認済みプルーフを印刷準備済みファイルへと導く多くの工程を自動化している。承認済みプルーフには、ファイルをカラー分解または各版処理に適したファイルに変えるために、カラー・モデルのCMYK変換、クロツプ・マークまたは印刷マークの挿入、全てのインポジション・コンフィギュレーション処理が行われる。さらに本システムは、ウェブ用カラーモードの赤・緑・青（RGB）に準備された保護および圧縮機能付きPDFファイルを制作し、ユーザや管理者に通知を送り、通信トラフィックおよび印刷通知を送信する。ドキュメントはそれから出版済みアーカイブに移動される。他の出力ファイル保管場所は、最終プルーフの異なった目的をサポートするために工程に追加可能である。

出版物は細分割された、再使用可能なコンポーネントで作られているが、全ての出版物はそれらがあたかも通常のドキュメントであるかのように管理されなければならない。エディションは一旦出版されると、直列構造ファイルおよび仮想ドキュメント、要素マップとしてドキュメント・アーカイブに保存される。HTMLやEDGARIIのような最終段階用途のフォーマットもまた、アーカイブ内に保存される。エディションが使用可能な間、アーカイブはブラックライニング機能および修復モジュールとして機能するために、ドキュメント全てのプルーフを維持する。アーカイブはコンポーネント・ライブラリの一部ではなく、システムの分割された一部である。

システム操作における、ユーザの概念的視点
何人かのユーザの視点からの出版工程の記述は、図27、28、および29に示されており、次のように要約することができる。

まず、エディション管理担当のユーザは出版物のエディションを作成する。エディションは、その反復が前もって決定されたスケジュールによって主導されていようと、市場／法規条件によって主導されているものであろうとに関わらず、出版物の定期反復行為である。エディションは、新規コンテントおよび／または以前のエディションの訂正を組み込むことが可能である。新たなエディションが準備される場合、それはアクティブ・エディションと呼ばれる。アクティブ・エディションは、編集可能で、それには保障された、または要望された新規コンポーネントの追加が含まれる。ユーザはこの時からアセンブルされたアクティブ・エディションに対する編集が可能となり、上記のように複合ツリー表示を通して操作し、編集パネル内で変更を行う。

エディションを管理するユーザは、いつでもアクティブ・エディションのプルーフをリクエストする事が可能である。ユーザは通常のブラックライン非表示プルーフに加えて、ブラックライン表示付きプルーフをリクエストすることが可能である。ブラックラインは、動的であり、新規プルーフは全ての他のユーザのリクエストに応じて、プルーフまたはドキュメント初期バージョンとの比較が可能である。ユーザはプルーフを作成する度に、ブラックライン表示付きのプルーフを受け取るか、またそれがどの段階のプルーフを比較対象とするかを選択することが可能である。このように、多様なレベルでの累積的な変更が記録可能である。

その後、エディションを管理するユーザは校閲とコメントのためにプルーフを配布する。管理者は複数の配布リストから配布先を選択することが可能で、更に個別受け取り人を加える事が可能である。校閲者、編集者および管理者は、インターネットまたは他のネットワーク接続を通じてプルーフにアクセス可能である。ドキュメント・コンポーネントへの変更およびコメントは、プルーフごとに合図される。プルーフ校閲時、ユーザがプルーフ上に調査されなければならない問題を発見する事がある。その際ユーザは電子コメントを作成することにより、そのコメントを問題追跡システムに入力する。

ユーザは、コンポーネント内容に関する訂正が誰によって、いつ、どの内容に、また何故行われたかの全ての変更を追跡管理する、追跡記録を参照することも可能である。変更は各エディション、および全てのエディションに対して、ブラックライン表示によって完全なその統計情報を伴って表示される。追跡記録は、2002年のSarbanes Oxley法のように、アメリカ合衆国政府によって制定された法規に従って詳細記録を保管する義務のある金融施設にも有用である。

適切な権限許可を持つユーザは、必要に応じてプルーフを編集、再校正、および校閲することが可能である。特権付きユーザは、プルーフをエディションの最終バージョンとして承認することができ、その後承認済みプルーフは“出版”される。承認済みプルーフが出版される時、図19が示す様に、プルーフはデプロイメント時に確立された特定フォーマットで設定された一連の受け取り人へ配布されることが承認される。出版されたドキュメントは保存されている最新エディションの最終段階を表示する。特定デプロイメントは、組み付け印刷のマスターを作成することが可能で、特定の受け取り人に特別電子フォーマットを届けることが可能で、またウェブまたは他のネットワーク・サイトに出版物をポストすることも可能であるが、これらの動作はシステム内の出版行為の後に続いて起こる動作で、出版ドキュメントの基盤となる記憶構造に影響しない。

プルーフが出版用に承認された後、校閲者または編集者は、コンポーネントまたは複数のコンポーネントに編集が必要だと判断する場合がある。このような場合には、出版のための承認は撤回される。撤回において、寄稿者と編集管理者は通常通りアセンブルと編集を選択し、制限編集と呼ばれるモードの操作をリクエストすることが可能である。制限編集において、ユーザは最新エディションが出版用に承認されて以降に訂正が加えられたアクティブ・エディション内の共有コンポーネントのリストを見る。ユーザは、制限モードまたは違うモードでこれらの訂正をアクティブ・エディションに適用することが可能である。承認済み撤回をもたらした編集は、アクティブ・ドキュメントにのみに（そしてそのエディションのみで無効となる）適用可能で、即座に全ての適切なドキュメントに、あるいは全ての将来的アクティブ・エディションに適用可能である。

本発明の好ましい実施形態とそれによる変更形態は、これまで細部に渡り記述した通りであるが、本発明がその実施形態と変更形態にのみ限定されるわけではないこと、および他の変更形態や変形形態は、本追加請求項にある通り、本発明の精神や意図から離れることなく、当分野における技術によってさらに効果的なものになる可能性のあることは、理解される必要がある。

システム全体のアーキテクチャおよび本発明の実施形態におけるクライアント・インターフェイス（コマンド・レイヤー）からの複数のクライアント・ユーザとの通信経路を示している。 本発明の実施形態における、全ての経路がクライアント・インターフェイス（コマンド・レイヤー）を通過するクライアント・コミュニケーション・プロトコルを示している。 本発明の実施形態におけるHTTPコミュニケーション・ワークフローのフロー図である。 本発明の実施形態におけるSOAP（Simple Object Access Protocol：シンプル・オブジェクト・アクセス・プロトコル）コミュニケーション・ワークフローのフロー図である。 本発明の実施形態における仮想ドキュメントの基礎をなすアーキテクチャ、およびそれらがどのように組み立てられているかを示している。 本発明の実施形態において、ビジネス・オブジェクト管理のアーキテクチャが複数のビジネス・オブジェクトの集合体を動的に作成することを示している。 本発明の実施形態におけるビジネス・オブジェクトの具体化を示すフロー図である。 本発明に実施形態において、ドキュメントのどの部分に対してもドキュメント環境価値を構築する、環境管理システムのアーキテクチャを示している。 本発明の実施形態における、ドキュメント管理サブ・システムによるドキュメントの構築および更新を示すフロー図である。 本発明の実施形態において、他の出版物からの要素を参照することなく出版物の初版を組み立てることができる、自動ポピュレ一夕機能のアーキテクチャおよび相互関係を示している。 本発明の実施形態において、出版バージョンのアーカイブがないドキュメントを作成するリクエストに対して、DTDおよびルールだけを使用してドキュメントを作成する流れを示すフロー図である。 本発明の実施形態において、基礎エディションのエレメント・マップを基礎として新しいエディションを組み立てる、自動ポピュレ一夕機能のアーキテクチャおよび相互関係を示している。 本発明の実施形態における、出版物の新規エディション、およびアーカイブ・ドキュメント、基礎エディションの作成開始のリクエストのフロー図である。 本発明の実施形態において、複数のワーク・グループがそれぞれの責任の領域に従い、同じドキュメント上で作業することを示す図である。 本発明の実施形態においての、要素の修正における要素およびコンポーネント間の関係を示している。 コンポーネントの修正工程を示すフロー図である。 本発明の実施形態において、プルーフ制作および出力済みのドキュメントを特有の場所にポストするリクエストのフロー図である。 本発明の実施形態において、出力フォーマット先から出力明細情報を検索するトランスフォーメーション・エンジンを持つ、出力システムのアーキテクチャ全体を示している。 本発明の実施形態における“出版”のためのドキュメントの状況変化の動作を示すフロー図である。 本発明の実施形態における、アクティブ・エディションを編集するためのユーザ・インターフェイス・スクリーンを示し、そこには複合ツリー・ナビゲーション・ウインドウ、ストラクチャー・バー、およびWYSIWYG編集ウインドウが表示されている。 本発明の実施形態における複合ツリー・インターフェイスの拡大図である。 本発明の実施形態における、4つのフロー・シナリオを表示した複合ツリー・ユーザの動作図である。 本発明の実施形態における、ストラクチャー・バーおよびエディター・ペイン・インターフェイスの拡大図である。 本発明の実施形態において、エディター・パネル上で実行可能なユーザによる多様な動作のフロー図である。 本発明の実施形態における、アクティブ・エディションの修正シーケンスを示すフロー図である。 従来の技術方法および本発明の実施形態との比較を示している。 従来の技術方法および本発明の実施形態との比較を示している。 従来の技術方法および本発明の実施形態との比較を示している。 本発明の実施形態において、編集管理者、寄稿著者／編集者、および校閲者側から見たシステム操作を示している。 本発明の実施形態において、編集管理者、寄稿著者／編集者、および校閲者側から見たシステム操作を示している。 本発明の実施形態において、編集管理者、寄稿著者／編集者、および校閲者側から見たシステム操作を示している。

Claims (19)

1. ドキュメント管理のためのユーザ・インターフェイスと、
   少なくともひとつのコンテント・ライブラリ、構造ルール、デプロイメント特定データ、またはデプロイメント特定ビジネス工程のデータを含む、データを記憶保存するメモリーと、
   前期メモリー内に記憶保存された前記データを基にしたドキュメントのアクティブ・エディションの自動アセンブリングのためのプロセッサを備え、
   前記ドキュメントのプルーフが、前記アクティブ・エディションから作成され、
   前記プルーフが承認された際、前記ドキュメントが出版されることを特徴とするドキュメントの自動化出版システム。
2. 前記コンテント・ライブラリ内のコンテントが多数のコンポーネントとして処理され、前記多数コンポーネントが多数のドキュメントによって共有可能であることを特徴とする請求項１記載のシステム。
3. 前記ドキュメントが多数の要素を備えた構造ドキュメントであり、各要素が構造情報を供給するか、あるいは前記コンテント、ライブラリ内に記憶されたコンポーネントを参照することを特徴とする請求項１記載のシステム。
4. 前記プルーフの承認以前にそのプルーフにつながった多数の発行物を発行するためのイシュー・ジェネレータを備えることを特徴とする請求項１記載のシステム。
5. 少なくともひとつのコンテント・ライブラリ、構造ルール、デプロイメント特定データ、またはデブロイメント特定ビジネス工程からの前記ドキュメントのアクティブ・エディションのアセンブリと、
   ユーザ・インターフェイスを使用した前記アクティブ・エディションの編集と、
   前記アクティブ・エディションからのプルーフ作成と、
   前記プルーフの校閲と、
   前記プルーフの出版の工程を備えるドキュメントの自動化出版方式。
6. 新規プルーフが発行される様、前記校閲工程において前記プルーフ作成のために前記アクティブ・エディション編集する機能を備えることを特徴とする請求項５記載の方式。
7. 前記プルーフに関連する多数の発行物を作成する工程を備えることを特徴とし、ユーザが前記プルーフが出版される前に前記発行部数を指定しなければならないことを特徴とする請求項５記載の方式。
8. 内容の関連する多数コンポーネントを備え、それぞれの前記多数コンポーネントがそれと関連する多数のバージョンを有することを特徴とするバージョン管理されたコンテント・ライブラリ。
9. 前記多数バージョンが多数バージョンと関連しているコンポーネントの外国言語翻訳であることを特徴とする請求項８記載のバージョン管理されたコンテント・ライブラリ。
10. 前記多数バージョンが特定地域のためにカスタマイズできることを特徴とする請求項８記載のバージョン管理されたコンテント・ライブラリ。
11. 前記コンポーネントが複数のドキュメントによって共有されることを特徴とする請求項８記載のバージョン管理されたコンテント・ライブラリ。
12. 前記コンポーネントがユーザによる編集が可能で、前記ユーザはユーザ・インターフェイスの使用を通して編集済みコンポーネントを、前記ドキュメント、全ての将来のドキュメント、全ての記憶保存されているドキュメント、または全てのドキュメントに適用可能であることを特徴とする請求項８記載のバージョン管理されたコンテント・ライブラリ。
13. 前記コンポーネントに行われた全ての編集の追跡記録が記憶保存されていることを特徴とする請求項１２記載のバージョン管理されたコンテント・ライブラリ。
14. 前記ドキュメントのセクションを表すコンテナと、
    前記コンテナ内で前記ドキュメント内の要素と関連するコンポーネントと、
    多数のハンドル、ひとつのコンテナまたはコンポーネントと関連する各ハンドル、前記コンテナ・コンポーネントを扱うために使用される前記ハンドルを備え、
    ドキュメントの概念的および組織的構造を記述するストラクチャー・バー。
15. 編集された前記ドキュメントをユーザが操作する事が可能な複合ツリー図を備える、請求項１４記載のストラクチャー・バー。
16. 前記ストラクチャー・バーがドキュメント構造ルールとマークアップ・シンタックスを確実に施行する、請求項１４記載のストラクチャー・バー。
17. 前記仮想構造ドキュメントのための構造を組み立てる構造要素と、
    コンテント・ライブラリ内に存ずるコンポーネントにポインターを置くための、前記仮想構造ドキュメント内の位置を定義するコンテント要素を備え、
    前記仮想構造ドキュメントが、少なくともひとつの構造ルール、デプロイメント特定データ、またはデプロイメント特定ビジネス工程を基にアセンブルされることを特徴とする仮想構造ドキュメント。
18. 必要要素を備え、前記必要要素が前記仮想構造ドキュメント内に存在しない限り出版用承認はされないことを特徴とする請求項１７記載の仮想構造ドキュメント。
19. システムが、少なくともひとつの文脈ルール、デプロイメント特定データ、デプロイメント特定ビジネス工程を基に前記仮想構造ドキュメント内使用のためのコンポーネント候補を識別することを特徴とする請求項１７記載の仮想構造ドキュメント。

Images