JP2009518719A - 文書処理システム及びその方法 - Google Patents

Abstract

本発明は、文書処理システム及びその方法を開示している。この文書処理システムは、少なくとも１つのアプリケーションを有するアプリケーション層と、文書ベースシステムとを含み、前記アプリケーションが、文書を操作するための、動作とオブジェクトとを含む標準指令を文書ベースシステムに送信し、前記文書ベースシステムが、記憶された文書データ内の前記オブジェクトに対して、標準指令で指示された動作を実行する。本発明に係る文書処理システム及びその方法では、アプリケーション層とデータ処理層を分離させることにより、文書の相互運用性が実現されている。
【選択図】図１

Description

本発明は文書処理システム及びその方法に関する。

情報は構造化データと非構造化データに大別される。そのうち、資料統計により、テキスト文書及びストリーミングメディアを主とする非構造化データのシェアが７０％を越える。構造化データの構造は、即ち２次元の表の構造であり、比較的に簡単である。構造化データの処理技術は、主にデータベースシステムを利用して処理することであり、２０世紀の７０、８０年代から発展して、９０年代にピークに達し、その研究開発と応用が既に成熟した。非構造化データは固定のデータ構造がないため、非構造化データに対する処理が非常に複雑である。

現在、各種の非構造化文書を処理するアプリケーションは既に普及しており、さまざまな文書フォーマットが並存している状況になっている。例えば、文書編集については、現在、Ｍｉｃｒｏｓｏｆｔ（登録商標）のｗｏｒｄ、ＷＰＳ、永中科技有限公司のＯｆｆｉｃｅ、ＲｅｄのＯｆｆｉｃｅなどが存在している。通常、１つの内容管理アプリケーションは２００、３００種もの文書フォーマットに対して処理することがあり、そして、これらのフォーマットが絶えずに更新されているため、このようなアプリケーションの開発に多大な困難をもたらす。文書の汎用性、デジタル内容の抽出、フォーマットの互換性がますます焦点になり、下記の問題解決に迫っている。

（１）文書が汎用できない。
基本的に、異なるユーザは、同じアプリケーションで処理された文書だけ交換でき、異なるアプリケーションで処理された文書を交換できないため、情報の閉鎖につながる。

（２）アクセスインターフェースが不統一で、データの互換性の代価が高すぎる。
異なる文書処理アプリケーションの間で、文書フォーマットは互いに互換できず、処理中においては、相手のフォーマットに対して、相手のコンポーネントを利用して解析し（相手から相応インターフェースの提供を前提とする）、又は、自分で研究開発の力を投入して最初から最後まで解析する必要がある。

（３）情報セキュリティが悪い。
現在、テキスト文書に対する権限制御手段は単一で、主にデータ暗号化とパスワード認証とを含む。毎年、情報漏えいで会社が巨大な損失を食う事件は次々に発生する。

（４）単一文書のみに対する処理であり、マルチ文書管理手段が乏しい。
各人のコンピュータに大量な文書があるが、複数の文書の間では、有効な組織管理が乏しく、且つリソースの共有が難しい。例えば、フォント・書体ファイルや全文データ検索などである。

（５）ページの階層化の技術が不整備。
現在、Ａｄｏｂｅ（登録商標）のｐｈｏｔｏｓｈｏｐやＭｉｃｒｏｓｏｆｔのｗｏｒｄのようなアプリケーションには層という概念が多少あったが、その層は、機能がまだ単純で、管理手段が比較的に簡単で、応用ニーズを満たすことができない。

（６）検索手段が豊富でない。
情報の大量化に伴い、どのキーワードで検索しても膨大な検索結果になってしまう。全文検索技術により再現率の課題がほぼ解決されているが、適合率が速やかに最も重要な課題になっている。従来技術では、適合率の課題の解決に全ての情報を十分に利用していない。例えば、各字の書体や文字サイズが、この字の重要性判断にまったく使用可能であるが、検索時に無視されてしまった。

現在、各大手会社は全部、自社特有の文書フォーマットを市場の標準規格に発展させるように努力しており、各標準化団体も汎用文書フォーマット規格の制定に力を尽くしている。しかし、専有の文書フォーマット（例えば．ｄｏｃ）やオープンな文書フォーマット（例えばＰＤＦ）にかかわらず、文書フォーマットを規格とする限り、下記の問題が避けられない。

ａ）重複開発、効果の不統一
同一文書フォーマット標準規格を使用する異なるアプリケーションがこのフォーマットの文書の解釈・生成を自分で行う必要があることにより、大量の重複開発をもたらす。また、各アプリケーションの解釈プログラムは異り、例えば、整備なものもあるし、相対的に簡単なものもあり、新バージョンをサポートするものもあるし、旧バージョンのみをサポートするものもある。そのため、同一文書は異なるアプリケーションによって異なるページレイアウトで表示され、ひいては、解釈エラーが発生して文書を開けくことができないこともある。

ｂ）革新に妨害
ソフトウェア産業は絶えずに革新している産業であるが、新機能を追加するたびにこの機能の記述情報を追加する必要があり、且つ、新たなフォーマットの追加が標準規格の修正時まで待つしかできないため、記憶フォーマットの固定は技術革新の競争を妨害する。

ｃ）検索性能に影響
大量の情報に対して、検索性能を向上するため、大量の検索情報を追加する必要があるが、固定の記憶フォーマットについては検索情報の追加が難しい。

ｄ）可搬性と拡張性に影響
異なるシステム環境下で、異なる応用ニーズにより異なる記憶要求がありうる。例えば、ハードディスクに記憶する場合、性能を向上するようにディスクヘッドのシーク回数を如何に減少するかを考慮する必要がある。一方、組込式応用では、データがメモリに記憶されるものに相当するため、上記問題はない。例えば、同一メーカーのデータベースアプリケーションは、異なるプラットフォームで異なる記憶フォーマットを使用する可能性がある。そのため、文書記憶標準規格の設定はシステムの可搬性と拡張性に影響を及ぼす。

従来技術で最もオープンな、互換性の最も優れた文書がＡｄｏｂｅ ＡｃｒｏｂａｔのＰＤＦである。しかし、ＰＤＦは既にグローバルの文書配布・交換の事実上の標準規格になったにもかかわらず、異なるアプリケーションの間でＰＤＦ文書の交換は実現できなく、つまり、ＰＤＦ文書の相互運用性を実現できない。そして、ＡｃｒｏｂａｔやＯｆｆｉｃｅにかかわらず、単一文書しか処理できず、マルチ文書に対する管理機能が乏しく、文書ベースへの操作機能を有しない。

また、従来技術は文書情報セキュリティの面にも多くの欠陥がある。ＷｏｒｄとＰＤＦのような応用の最も幅広い文書では、全部、データ暗号化又はパスワード認証などを採用してデータセキュリティ制御を行うが、体系的な身分認証メカニズムを提供せず、権限制御は、文書全体の範囲で行われ、文書内の任意領域まで精細化できず、任意のロジックデータに対して暗号化と署名を設定できない。従来の内容管理システムでは、比較的に良い身分認証メカニズムを提供できるが、文書処理システムと分離しているため、文書レベルの管理粒度しか実現できないばかりでなく、文書使用中に文書に対してセキュリティ制御を実施できず、必要なセキュリティ管理を実行しにくい。上記からわかるように、従来のセキュリティメカニズムと文書処理がそれぞれ単独のモジュールで実現されるため、セキュリティ欠陥が発生しやすい。

本発明は、文書の相互運用性、マルチ文書の管理、よりよい文書セキュリティ及びよりよい問い合わせ検索を実現できる文書処理システム及びその方法を提供する。

文書処理システムであって、
少なくとも１つのアプリケーションを有するアプリケーション層と、文書ベースシステムとを含み、
前記アプリケーションが、文書を操作するための、動作とオブジェクトとを含む標準指令を文書ベースシステムに送信し、
前記文書ベースシステムが、記憶された文書データ内の前記オブジェクトに対して、標準指令で指示された動作を実行する。

文書処理方法であって、
アプリケーションが、文書を操作するための、動作とオブジェクトとを含む標準指令を文書ベースシステムに送信する過程と、
文書ベースシステムが、記憶された文書データ内の前記オブジェクトに対して、標準指令で指示された動作を実行する過程とを含む。

文書処理システムであって、
少なくとも１つのアプリケーションを有するアプリケーション層と、文書ベースシステムと、インターフェース層とを含み、
前記アプリケーションが、文書を操作するための、動作とオブジェクトとを含む標準指令を、インターフェース層を介して文書ベースシステムに送信し、
前記文書ベースシステムが、インターフェース層を介して前記標準指令を受信し、記憶された文書データ内のオブジェクトに対して、標準指令で指示された動作を実行する。

本発明によれば、ユーザインターフェースから文書記憶までを１つのアプリケーションによって実現する現状が変えられている。本発明では、文書処理をアプリケーション層と文書ベースシステム層に区分し、且つ両層間のやり取りを規範したインターフェース標準を定義する。このインターフェース標準に適合するインターフェース層を更に構築してもよい。文書ベースシステムは各種の文書操作機能を備える汎用技術プラットフォームであり、アプリケーションが文書を操作しようとするとき、該インターフェース層を介して文書ベースシステムへ相応の指令を送信し、文書ベースシステムがこの指令に基づいて相応の操作を実行する。このように、各アプリケーションと各文書ベースシステムが同様の標準に従う限り、異なるアプリケーションは同一文書ベースシステムを介して同一文書を操作することができ、即ち文書の相互運用性を実現できる。同様に、同一アプリケーションは、各種の文書フォーマットに応じてそれぞれに開発することなく、異なる文書ベースシステムを介して異なる文書を操作することもできる。

また、本発明は汎用文書モデルも含み、このモデルが各アプリケーションの処理必要な文書にも適合することができる。インターフェース標準が該文書モデルに基づいて決定されたものであるため、異なるアプリケーションがインターフェース層を介して文書を操作できることが実現できる。この汎用文書モデルが各種の文書フォーマットにも適用できるため、同一アプリケーションがインターフェース層を介して異なるフォーマットの文書を操作することができる。

インターフェース標準には、該汎用文書モデルに基づいて文書を操作するための各種の指令、及びアプリケーションから文書ベースシステムへの指令送信の方式が定義されている。文書ベースシステムは、アプリケーションからのこれらの指令を実現する機能を備える。

また、該汎用文書モデルには、複数の文書からなる文書セット、文書ベース及び文書ウェアハウスなどの階層が含まれ、インターフェース標準にも、マルチ文書の組織管理、問い合わせ検索、及びセキュリティ制御などの指令が含まれる。

また、該汎用モデルには、上下の順序を有する層からなるページが含まれ、インターフェース標準にも、層に対する各種の操作指令、及び文書のある層に対応するソースファイルの記憶と取り出しが含まれる。

また、文書ベースシステムは、ロールに基づく細粒度の権限管理のような文書の情報セキュリティ管理制御機能を備え、且つインターフェース標準には関連の操作指令が定義されている。

本発明によれば、アプリケーション層とデータ処理層を分離させることになる。このように、アプリケーションが具体的な文書フォーマットと直接な関係なく、文書も特定のアプリケーションとバインドされず、同一文書が、異なるアプリケーション間で汎用でき、同一アプリケーションも、異なる文書を操作できるようになって、文書の相互運用性が実現されている。文書処理システム全体は、単一文書処理に限られず、マルチ文書処理機能も備える。ページを複数の層に分けると、異なる層に対して異なる管理と制御を行うことが実現でき、異なるアプリケーションによる同一ページに対する操作（異なるアプリケーションによる異なる層への管理・維持と設計してよい）が更に便利になる。これは、ソースファイル方式で編集することに便利で、履歴保存のよい方式でもある。情報セキュリティを文書処理のコア層に組み入れることによって、セキュリティ欠陥が消滅でき、セキュリティメカニズムと文書操作が、分離可能な２つのモジュールではなく、密接に一体化されるとともに、セキュリティ管理技術の配置空間がもっと多くなり、関連コードがもっと深く隠蔽されることができ、不法攻撃を有効に防げ、セキュリティ信頼性が向上でき、またもっと多くの権限類別や、もっと小さい管理ユニットのような細粒度のセキュリティ管理手段を提供できる。

以下、図面及び実施形態を参照しながら、本発明について更に詳しく説明する。ここで述べた具体的な実施形態は、本発明を解釈するのみに用いられ、本発明を限定するものではないと解されるべきである。

図１に示すように、本発明による文書処理システムは主にアプリケーションと、インターフェース層と、文書ベースシステムと、記憶装置と、を含む。

ここでのアプリケーションは、従来の文書処理と内容管理のいかなるアプリケーションを含む。これらのアプリケーションは、文書処理システムのアプリケーション層に位置し、インターフェース標準に適合する指令の送信により文書を操作する。前記操作は全部、汎用文書モデルに適合する文書に対して行うものであり、具体的な記憶フォーマットと関係ない。

ここでのインターフェース層は、アプリケーション層と文書ベースシステムとの間のやり取りを規範したインターフェース標準に適合する。前記アプリケーション層は、インターフェース層を介して、文書ベースシステムに標準指令を送信し、前記文書ベースシステムは、インターフェース層を介して、アプリケーション層に実行結果を返信する。上記からわかるように、アプリケーションが皆インターフェース層を介して標準指令を送信し、汎用文書モデルに適合する文書を操作できるため、異なるアプリケーションは同一文書ベースシステムを介して同一文書を操作でき、同一アプリケーションは異なる文書ベースシステムを介して異なるフォーマットの文書も操作できる。

好ましくは、インターフェース層に上インターフェースユニットと下インターフェースユニットが含まれてよい。アプリケーションは上インターフェースユニットを介して標準指令を下インターフェースユニットに送信し、文書ベースシステムは下インターフェースユニットを介して標準指令を受信し、下インターフェースユニットはまた上インターフェースユニットを介して文書ベースシステムの実行結果をアプリケーションに返信する。実現には、上インターフェースユニットはアプリケーション層に位置してよく、下インターフェースユニットは文書ベースシステムに位置してよい。

ここでの文書ベースシステムは、文書処理システムのコア層であり、アプリケーションからインターフェース層を介して送信された標準指令に基づいて、具体的な文書処理操作を実行する。

ここでの記憶装置は、文書処理システムの記憶層であり、通常、ハードディスク又はメモリを含み、コンパクトディスク、フラッシュメモリ、フロッピーディスク、テープ、又はリモート記憶装置を含んでもよく、つまりデータ記憶能力さえあればよい。記憶装置には複数の文書が記憶されるが、アプリケーションにとって文書の具体的な記憶方式に注目する必要はない。

上記からわかるように、本発明によれば、アプリケーション層とデータ処理層を確実に分離させ、文書が特定のアプリケーションとバインドされず、アプリケーションが具体的な文書フォーマットと直接な関係なく、異なるアプリケーションで汎用文書モデルに適合する同一文書を編集でき、異なるアプリケーションの間で文書の優れた相互運用性を有するようになった。

また、本発明はアプリケーションを開示している。前記アプリケーションは、汎用文書モデルに適合する文書を操作するための標準指令を送信するインターフェースユニットを含む。

また、本発明は文書ベースシステムを開示している。前記文書ベースシステムは、標準指令を受信するインターフェースユニットと、前記標準指令に基づいて、汎用文書モデルに適合する文書を操作する処理ユニットと、を含む。

また、本発明はインターフェース層を開示している。前記インターフェース層は、
汎用文書モデルに適合する文書を操作するための標準指令を送信する上インターフェースユニットと、
前記標準指令を受信する下インターフェースユニットと、を含む。

さらに、上インターフェースユニットはアプリケーション層からの指令に基づいて標準指令を生成し、下インターフェースユニットは受信した指令が標準に適合するかどうかを判断し、標準に適合する指令を解析するようにしてよい。

以下、本発明に係る文書処理システムの具体的な実施形態を説明する。

汎用文書モデル
紙の特性を参考して前記汎用文書モデルを定義してよい。これは、紙を文書情報の記録手段とすることが今まで通用している標準方法であり、紙の全ての機能さえあれば、仕事や生活などの実際の応用ニーズを満たすことができるためである。

文書内の１ページを１枚の紙と見なして、紙に書かれることができるいかなるものを記録すれば、この汎用文書モデルはページ上の全ての可視内容を記述できる。従来技術のページ記述言語（例えばＰｏｓｔＳｃｒｉｐｔ）が紙に印刷可能な全ての情報を記述できるため、この部分について詳しい説明を省略する。一般的に、ページ上の可視内容は最終的にテキスト、図形、及び画像の３種類に分かれてよい。

文書が特定書体又は特殊文字に係る場合、各コンピュータでの同じ効果を確保するために、文書に相応のフォントを組み込む必要がある。記憶効率を向上するために、フォントリソースを共有すべきである。このようにして、複数の箇所に同じ文字を使用しても、１つだけのフォントを組み込めばよい。画像も複数の箇所に出る可能性があり、例えば、各ページで共通の背景画像又はいつも出てくる会社のロゴである。この場合にも、これらの画像を共有したほうがよい。

もちろん、より先進的な情報処理ツールとしては、紙の特性を模擬するだけでなく、メタデータ、ナビゲーション、スレッド、サムネイルイメージのような強化されたデジタル特性を追加する必要がある。メタデータは、データを記述するためのデータを含む。例えば、図書のメタデータは、著者、出版社、出版日付、ＩＳＢＮ番号などを含む。メタデータが業界内の共通用語であるため、ここで説明を省略する。ナビゲーションは図書の目次のような情報を含み、それも業界内の共通用語である。スレッド情報が文書の所在領域と閲読の順序を記述するため、読者が、あるスクリーンを読んだ後、次のスクリーンに表示すべきものは該情報に基づいて自動的に判断されることができる。また、スレッド情報によっては、読者が手動で位置を指定することなく、自動改段や自動改ページも実現できる。サムネイルイメージは、事前に生成した、各ページの縮小図を含む。読者はサムネイルイメージを調べることによってどのページを閲読するかを指定できる。

図２は本発明の好ましい実施形態に係る汎用文書モデルである。図２に示すように、この汎用文書モデルには、文書ウェアハウス、文書ベース、文書セット、文書、ページ、層、オブジェクトグループ、レイアウトオブジェクトなどの複数の階層が含まれる。

ここで、文書ウェアハウスは１つ又は複数の文書ベースからなる。文書ベースの下位階層間の関係と比べて、文書ベース間の関係が比較的に緩く、文書ベース自身のデータを修正することなく、文書ベース同士が簡単に組合せ・解体されることができる。この複数の文書ベースの間は統一インデックス（特に全文インデックス）が作成されていない場合が多いため、文書ウェアハウスに対する多くの検索操作については、普通、使用可能な統一的なインデックスがなく、各文書ベースのインデックスを走査する必要がある。各文書ベースはそれぞれ１つ又は複数の文書セットからなる。各文書セットはそれぞれ、１つ又は複数の文書からなり、任意数のサブ文書セットも含んでよい。ここで言われた文書は、現在の普通の文書ファイル（例えばＤＯＣ文書）を含む。汎用文書モデルでは、１つの文書が１つの文書セットのみに属することを規定してもよいが、１つの文書が複数の文書セットに属することを許してもよい。文書ベースは、複数の文書の簡単な組合せではなく、複数の文書を密接に組織してできたものである。特に、文書内容のために各種の統一検索インデックスを作成すると、より大きな利便性をもたらす。

各文書はそれぞれ、１ページ、又は一定の順序（例えば前後の順序）を有する複数のページからなる。各ページの版面は異なってよく、且つ、版面は、必ずしも矩形ではなく、任意の形状であってよく、１本又は複数本の閉曲線で表すことができる。

各ページはそれぞれ、１層、又は一定の順序（例えば上下の順序）を有する複数の層からなる。各層間は重なり合うガラス板のような関係である。層は任意数のレイアウトオブジェクトとオブジェクトグループからなる。レイアウトオブジェクトは、ステータス（例えば、書体、文字サイズ、色、ＲＯＰなど）、テキスト（符号を含む）、図形（例えば、直線、曲線、指定の色で塗りつぶされた閉領域、グラデーション色など）、画像（例えば、ＴＩＦ、ＪＰＥＧ、ＢＭＰ、ＪＢＩＧなど）、セマンティック情報（例えば、タイトル開始、タイトル終了、改行など）、ソースファイル、スクリプト、プラグイン、組込式オブジェクト、ブックマーク、ハイパーリンク、ストリーミングメディア、２値化データストリームなどを含む。１つ又は複数のレイアウトオブジェクトが１つのオブジェクトグループに構成されてよい。オブジェクトグループに任意数のサブオブジェクトグループが含まれてもよい。

文書ベース、文書セット、文書、ページ、層には、メタデータ（例えば、名称、最後の修正時間などであり、その類型は応用ニーズによって設定できる）及び／又は履歴がさらに含まれてよい。文書には、ナビゲーション情報、スレッド情報、サムネイルイメージがさらに含まれてよい。サムネイルイメージをページ又は層のレベルに置いてもよい。文書ベース、文書セット、文書、ページ、層、オブジェクトグループには、デジタル署名がさらに含まれてよい。セマンティック情報はレイアウト情報に従ったほうがよい。これによって、データの冗長を避けることができ、且つレイアウトとの対応関係の確立が比較的に容易になる。文書ベース、文書には、フォントや画像などの共有リソースが含まれてもよい。

また、この汎用文書モデルでは、１つ又は複数のロールを定義して、各ロールに一定の権限を配分してもよい。文書ベース、文書セット、文書、ページ、層、オブジェクトグループ、メタデータをユニットとして権限を配分し、各ロールに対して、該ユニットへのリード可否、ライト可否、コピー可否、印刷可否などを定義する。

この汎用文書モデルは、単一文書が単一ファイルに対応する従来の方式を超えるものである。文書ベースには複数の文書セットが含まれ、文書セットには複数の文書が含まれる。文書ベース内の文書内容に対して細粒度のアクセスとセキュリティ制御を採用していることで、従来の文書管理システムがファイル名レベルしかアクセスできないことと違って、文書ベース内のある文字又は矩形まで具体的にアクセスできる。

図３〜図９は本発明の好ましい実施形態に係る汎用文書モデルに関する各オブジェクトの構成を示す図である。前記各オブジェクトの構成はツリー構造であり、層ごとに展開、細分化される。

文書ウェアハウスオブジェクトは１つ又は複数の文書ベースオブジェクト（図示せず）からなる。

図３に示すように、文書ベースオブジェクトには、１つ又は複数の文書セットオブジェクト、任意数の文書ベース補助オブジェクト、及び任意数の文書ベース共有オブジェクトが含まれる。

図４に示すように、前記文書ベース補助オブジェクトには、メタデータオブジェクト、ロールオブジェクト、権限オブジェクト、プラグインオブジェクト、インデックス情報オブジェクト、スクリプトオブジェクト、デジタル署名オブジェクト、履歴オブジェクトなどが含まれる。文書ベース共有オブジェクトには、文書ベース内の異なる文書で共有可能なオブジェクト、例えばフォントオブジェクトや画像オブジェクトなどが含まれる。

図５に示すように、各文書セットオブジェクトにはそれぞれ、１つ又は複数の文書オブジェクト、任意数の文書セットオブジェクト、及び任意数の文書セット補助オブジェクトが含まれる。文書セット補助オブジェクトには、メタデータオブジェクト、デジタル署名オブジェクト、履歴オブジェクトが含まれる。文書セットオブジェクトに複数の文書セットオブジェクトが含まれる場合は、エクスプローラにおいて１つのフォルダに複数のフォルダが含まれる形式と類似している。

図６に示すように、各文書オブジェクトにはそれぞれ、１つ又は複数のページオブジェクト、任意数の文書補助オブジェクト、及び任意数の文書共有オブジェクトが含まれる。文書補助オブジェクトには、メタデータオブジェクト、フォントオブジェクト、ナビゲーション情報オブジェクト、スレッド情報オブジェクト、サムネイルイメージオブジェクト、デジタル署名オブジェクト、履歴オブジェクトなどが含まれる。文書共有オブジェクトには、文書内の異なるページに共通使用可能なオブジェクト、例えば画像オブジェクトや印章オブジェクトなどが含まれる。

図７に示すように、各ページオブジェクトにはそれぞれ、１つ又は複数の層オブジェクト、及び任意数のページ補助オブジェクトが含まれる。ページ補助オブジェクトには、メタデータオブジェクト、デジタル署名オブジェクト、履歴オブジェクトが含まれる。

図８に示すように、各層オブジェクトにはそれぞれ、１つ又は複数のレイアウトオブジェクト、任意数のオブジェクトグループ、及び任意数の層補助オブジェクトが含まれる。層補助オブジェクトには、メタデータオブジェクト、デジタル署名オブジェクト、履歴オブジェクトが含まれる。オブジェクトグループには、任意数のレイアウトオブジェクト、任意数のオブジェクトグループ、及び選択可能なデジタル署名オブジェクトが含まれる。オブジェクトグループに複数のオブジェクトグループが含まれる場合は、エクスプローラにおいて１つのフォルダに複数のフォルダが含まれる形式と類似している。

図９に示すように、レイアウトオブジェクトには、ステータスオブジェクト、テキストオブジェクト、直線オブジェクト、曲線オブジェクト、円弧オブジェクト、パスオブジェクト、グラデーション色オブジェクト、画像オブジェクト、ストリーミングメディアオブジェクト、メタデータオブジェクト、コメントオブジェクト、セマンティック情報オブジェクト、ソースファイルオブジェクト、スクリプトオブジェクト、プラグインオブジェクト、２値化データストリームオブジェクト、ブックマークオブジェクト、及びハイパーリンクオブジェクトが含まれる。

ここで、ステータスオブジェクトには、任意数の、文字セットオブジェクト、書体オブジェクト、文字サイズオブジェクト、文字色オブジェクト、ラスター操作オブジェクト、背景色オブジェクト、線色オブジェクト、塗りつぶし色オブジェクト、線種（ｌｉｎｅｔｙｐｅ）オブジェクト、線幅（ｌｉｎｅ ｗｉｄｔｈ）オブジェクト、継ぎ目オブジェクト、ブラシオブジェクト、陰影オブジェクト、陰影色オブジェクト、回転オブジェクト、袋文字オブジェクト、縁取り文字オブジェクト、透明オブジェクト、及びレンダリングモードオブジェクトが含まれる。

具体的な実施過程において、上記汎用文書モデルの上でさらに強化又は簡略化してよい。簡略化モデルに文書セットオブジェクトが省略される場合、文書ベースオブジェクトは文書オブジェクトを直接に含み、簡略化モデルに層オブジェクトが省略される場合、ページオブジェクトはレイアウトオブジェクトを直接に含む。

最も簡略化された汎用文書モデルには、文書オブジェクト、ページオブジェクト、及びレイアウトオブジェクトのみが含まれることが理解できる。ここで、レイアウトオブジェクトには、テキストオブジェクト、直線オブジェクト、及び画像オブジェクトのみが含まれる。完全モデルと最も簡略化されたモデルとの間の各種の中間モデルは、この好ましい実施形態の変形である。

汎用セキュリティモデル
各種の応用による文書セキュリティへのニーズを満すため、従来のアプリケーションの文書セキュリティ機能があまり強くなく、又はセキュリティ管理メカニズムと文書処理モジュールの繋がりが切れることによるセキュリティ欠陥を解決するように、汎用の文書セキュリティモデルを定義する必要がある。本発明の好ましい実施形態によれば、汎用文書セキュリティモデルは下記のものを含む。

１．文書ベースにおいて若干のロールを定義する。ロールオブジェクトは文書ベースオブジェクトのサブオブジェクトである。

２．任意ロールによる任意オブジェクト（例えば、文書ベース、文書セット、文書、ページ、層、オブジェクトグループ、レイアウトオブジェクトなど）へのアクセス権限を設定できる。あるロールに対して、あるオブジェクトへのアクセス権限を設定すると、この権限は該オブジェクトの全てのサブオブジェクトに適用する。

３．文書ベースシステムで実現されたアクセス権限には、リード可否、ライト可否、権限再付与可否、権限解除可否、及び上記の任意の組合せが含まれる。印刷不可のような、実現にアプリケーションの協力を必要とする他の権限も定義できる。

４．ロールは任意のオブジェクトに対して署名できる。あるオブジェクトに対する署名範囲は、該オブジェクトのサブオブジェクト、及び該オブジェクトに引用されたオブジェクトを含む。

５．ロールオブジェクト作成指令の実行結果は、アプリケーションから該ロール身分でログインするための鍵を、アプリケーションに返信することである。この鍵は、通常、ＰＫＩの秘密鍵であり、アプリケーションによって保管される。この鍵はログインパスワードであってもよい。

６．アプリケーションが、あるロールの身分でログインする場合、通常、「挑戦／応答」メカニズムが採用される。即ち、文書ベースシステムが、保存しているロールの公開鍵を用いてランダムデータブロックを暗号化して、アプリケーションに送信し、アプリケーションが、その暗号化されたものを復号化してから文書ベースシステムに返信し、復号化が正しい場合は、アプリケーションがこのロールに対応する秘密鍵を確実に有することを表す。「挑戦／応答」メカニズムは以下の方式でも実現できる。即ち、文書ベースシステムがランダムデータブロックをアプリケーションに送信し、アプリケーションが秘密鍵を用いてそれを暗号化してから文書ベースシステムに返信し、文書ベースシステムが、保存しているロールの公開鍵を用いて、その暗号化されたものを復号化し、復号化が正しい場合は、アプリケーションがこのロールに対応する秘密鍵を確実に有することを表す。念のため、この認証プロセスが何回も繰り返されることが可能である。「挑戦／応答」メカニズムを用いることで、秘密鍵のセキュリティをよりよく保護できる。ロールの鍵がログインパスワードである場合、ユーザが正しいログインパスワードを入力しなければならない。

７．アプリケーションは同時に複数のロールでログインしてよく、この時、このアプリケーションの有している権限はそれらの複数のロールの権限の和集合である。

具体的な実施過程において、上記汎用セキュリティモデルの上でさらに強化又は簡略化してよい。上記セキュリティモデルに対するいかなる簡略化モデルは本実施形態の変形である。

インターフェース層の具体的な実現
前記インターフェース層の統一インターフェース標準は、汎用文書モデル、汎用セキュリティモデル及び常用の文書操作に基づいて定義されてよく、汎用文書モデル内の各オブジェクトに対する操作指令を送信することに用いられる。前記汎用文書モデル内の各オブジェクトに対する操作指令はインターフェース標準に適合し、各種のアプリケーションはインターフェース層を介して標準指令を送信できる。

以下、インターフェース標準の実現方式を紹介する。インターフェース標準を実現するために、上インターフェースユニットが、予め定義された標準フォーマットに従って、例えば「＜ＵＯＭＬ＿ＩＮＳＥＲＴ （ＯＢＪ＝ＰＡＧＥ， ＰＡＲＥＮＴ＝１２３．４５６．７８９， ＰＯＳ＝３）／＞」のような命令列を生成し、この命令列を下インターフェースユニットに送信し、下インターフェースユニットを介して、文書ベースシステムから、該命令に対する実行結果又は他のフィードバック情報を受信するようにしてよい。又は、インターフェース標準を実現するために、下インターフェースユニットが、標準名称とパラメータを有する、例えば「ＢＯＯＬ ＵＯＩ＿ＩｎｓｅｒｔＰａｇｅ （ＵＯＩ＿Ｄｏｃ ＊ｐＤｏｃ， ｉｎｔ ｎＰａｇｅ）」のようなインターフェース関数を若干提供し、上インターフェースユニットがこれらの標準関数を呼び出し、呼び出し操作自身は上インターフェースユニットが標準指令を送信することと意味するようにしてよい。又は、インターフェース標準を実現するために、上記方法を組合せてよい。

インターフェース標準が「操作動作＋操作オブジェクト」の方式で実現されると、インターフェース標準の勉強と理解に便利で、インターフェース標準の安定性維持にも便利である。例えば、２０種類の異なるオブジェクトに対して１０種類の操作を行う場合、２０×１０＝２００種類の指令を定義してもよいし、２０種類のオブジェクトと１０種類の動作を定義してもよい。しかし、後者の方式では、記憶負担が大いに軽減するのが明らかで、且つ今後インターフェース標準を拡張する時、オブジェクト又は動作の追加も簡単である。前記操作オブジェクトは、汎用文書モデルに含まれるオブジェクトである。

例えば、以下の７種類の操作動作を定義する。
オープン：文書ベースを作成又はオープンする。
クローズ：セッションハンドルや文書ベースをクローズする。
取得：オブジェクトリスト、オブジェクトの関連属性及びデータを取得する。
設定：オブジェクトデータを設定・修正する。
挿入：指定のオブジェクト又はデータを挿入する。
削除：オブジェクトのあるサブオブジェクトを削除する。
検索問い合わせ：定義された条件によって文書において条件に適合する内容を検索する。これらの条件は、正確な情報であってもよいし、不正確な情報であってもよい。即ち、曖昧検索がサポートされる。

文書ベース、文書セット、文書、ページ、層、オブジェクトグループ、テキスト、画像、図形、パス（順に接続された図形からなるグループであり、ここでの図形は開図形又は閉図形であってもよい）、ソースファイル、スクリプト、プラグイン、オーディオ、ビデオ、ロールなどのようなオブジェクトを定義する。

オブジェクトには、背景色、線色、塗りつぶし色、線種、線幅、ＲＯＰ、ブラシ、陰影、陰影色、文字高さ、文字幅、回転、透明、レンダリングモードなどのステータスオブジェクトも含まれる。

「操作動作＋操作オブジェクト」の方式でインターフェース標準を実現する場合、各オブジェクトと各動作の全ての組合せは必ず実際の意味のある操作指令を構成できると自動的に認識すべきでなく、一部の組合せは意味がない、ということが理解できる。

「操作動作＋操作オブジェクト」以外の関数方式でインターフェース標準を定義するようにしてもよい。例えば、各オブジェクトの各種の操作ごとに１つのインターフェース関数を定義すると、各種の操作指令は、上インターフェースユニットから下インターフェースユニットのインターフェース関数を呼び出すことで文書ベースシステムに送信される。

各オブジェクトをカプセル化して、例えば文書ベースクラスのようなクラスを形成し、該オブジェクトの実行可能な操作を該クラスのメソッドとして定義するようにしてもよい。

特に、インターフェース標準ではページビットマップの取得指令が定義されると、レイアウトの一致性、及び文書の相互運用性の保障に肝心な役割を果たす。

検索問い合わせ指令では、普通のキーワード検索以外に、もっと豊富な検索手段を提供できる。普通の検索技術では、検索は文書処理と分離しているものであり、検索プログラムは、文書からプレーンテキスト情報しか抽出できず、もっと多くの情報を取得できないため、テキスト情報しかに基づいて検索できない。本発明では、検索問い合わせ機能を文書処理のコア層、即ち文書ベースシステムに組み入れることによって、文書に含まれる情報を十分に利用してもっと強い検索手段を提供できる。例えば、
１．書体情報に基づく検索、例えば、黒体文字の「書生」の検索、Ｔｉｍｅｓ Ｎｅｗ Ｒｏｍａｎ体の「Ｓｕｒｓｅｎ」の検索。
２．文字サイズ情報に基づく検索、例えば、３号の「書生」の検索、２０ポイント以上の「Ｓｕｒｓｅｎ」の検索、長体文字（即ち文字高さが文字幅を超える）の「文書ベース」の検索。
３．色に基づく検索、例えば、赤色の「書生」の検索、青色の「Ｓｕｒｓｅｎ」の検索。
４．レイアウト位置に基づく検索、例えば、ページの上半部分にある「書生」の検索、フッターにある「Ｓｕｒｓｅｎ」の検索。
５．文字修飾の特殊効果に基づく検索、例えば、斜体文字の「書生」の検索、時計回り方向で３０度〜９０度回転される「Ｓｕｒｓｅｎ」の検索、袋文字の「ＳＥＰ」の検索、縁取り文字の「文書ベース」の検索。
６．類似の考え方によって、さらに、他の類型の検索、例えば白黒反転（黒地に白字）の「書生」の検索、画像に重ね合わせた「Ｓｕｒｓｅｎ」の検索なども提供できる。
７．複数のレイアウトオブジェクトの組合せ、例えば「書生」と「Ｓｕｒｓｅｎ」の距離が５ｃｍに超えないものを検索できる。
８．上記検索条件の任意の組合せ。

以下は「操作動作＋操作オブジェクト」の方式でインターフェース標準を実現する実施形態である。該実施形態において、インターフェースは、非構造化操作マークアップ言語（ＵＯＭＬ）と呼ばれ、拡張可能なマークアップ言語（ＸＭＬ）で記述する一連の命令である。各動作はそれぞれ１つのＸＭＬ要素に対応し、各オブジェクトもそれぞれ１つのＸＭＬ要素に対応する。命令を記述する際、オブジェクトを記述するＸＭＬ要素を、動作を記述するＸＭＬ要素の子要素とすることにより、「動作+オブジェクト」を含む文字列を生成することができる。上インターフェースユニットがこの文字列を下インターフェースユニットに送信することで、相応の操作指令を文書ベースシステムに送信する。文書ベースシステムがこれらの命令を実行した後、下インターフェースユニットは、実行結果に対してもＵＯＭＬフォーマットに適合する文字列を生成して、上インターフェースユニットに返信することで、アプリケーションに操作の実行結果を知らせる。

全ての実行結果はＵＯＭＬ＿ＲＥＴで表される。図１０を参照すると、ＵＯＭＬ＿ＲＥＴは以下のように定義される。
属性
ＳＵＣＣＥＳＳ：値が真（ｔｒｕｅ）の場合は操作成功、それ以外の場合は操作失敗、を表す。
子要素
ＥＲＲ＿ＩＮＦＯ：選択可能なものであり、操作失敗の場合だけ出現し、相応のエラー情報を記述する。
他の子要素：具体的な命令によって決定され、各命令に対する説明を参照してよい。

ＵＯＭＬの動作は以下のものを含む。
１．ＵＯＭＬ＿ＯＰＥＮ（文書ベースの作成又はオープン、図１１を参照）
１．１ 属性
１．１．１ Ｃｒｅａｔｅ：ｔｒｕｅの場合は作成し、それ以外の場合は既存の文書ベースをオープンすることを表す。
１．２ 子要素
１．２．１ Ｐａｔｈ：文書ベースのパス。それは、ディスクファイル名、ＵＲＬ、メモリポインタ、ネットワークパス、文書ベースのロジック名称、又は文書ベースを指定できる他の表現方式であってよい。異なる特徴を有する文字列で上記の各種の場合を区分し、即ち命令フォーマットを変化せず、文字列に対して異なる特徴さえ設定すれば、異なる方法で文書ベースを指定できる。例えば、ディスクファイル名は、デバイス名（例えばドライブレター）と「：」（例えば、「Ｃ：」、「Ｄ：」）を先頭として、そして「：」の直後は「//」又は他の「：」ではない。ＵＲＬは、プロトコル名称と「：//」（例えば「ｈｔｔｐ：//」）を先頭とする。メモリポインタは、「ＭＥＭ：：」を先頭として、その次はポインタの文字列での表現方式であり、例えば「ＭＥＭ：：１２３４：５６７８」である。ネットワークパスは、「\\」を先頭として、次はサーバ名及びサーバでのパスであり、例えば「\\ｓｅｒｖｅｒ\ａｂｃ\ｄｅｆ．ｓｅｐ」である。文書ベースのロジック名称は、「＊」を先頭としてよく、例えば「＊ＭｙＤｏｃＢａｓｅ１」である。下インターフェースユニットが解析するとき、先頭１文字が「＊」である場合は該文字列が文書ベースのロジック名称を表し、先頭２文字が「\\」である場合は該文字列がネットワークパスを表し、先頭５文字が「ＭＥＭ：：」である場合は該文字列がメモリポインタを表し、上記以外の場合は、文字列の最初の「：」を探して、この「：」の次が「//」であると文字列がＵＲＬを表し、そうでないとローカルデバイスのファイルを表す。サーバの文書ベースをオープンする場合を区分するように、特別なＵＲＬプロトコルを設定してよい。例えば、「Ｄｏｃｂａｓｅ：//ｍｙｓｅｒｖｅｒ/ｍｙｄｏｃ２」を用いて、サーバｍｙｓｅｒｖｅｒにおける文書ベースシステムのサーバシステムで管理される文書ベースｍｙｄｏｃ２のオープンを指示する。要するに、文字列に異なる特徴さえ設定できれば、異なる方式で文書ベースを指定できる。上記説明によれば、各種の異なる文字列特徴を定義してもよい。この方式は、文書ベースパスの指定に適用するだけでなく、他の場合、特に特定リソース位置を指定するための応用場合にも適用できる。新たな方式で関連リソースを指定したいが、既存のプロトコル又は関数を変えることができず、又は変えたくない場合が多い。このとき、文字列に異なる特徴を設定する方式で指定できる。このような方法は最適な汎用性があり、原因として、いかなるプロトコル又は関数でも、ディスクファイル名又はＵＲＬさえサポートすれば、文字列もサポートする。
１．３ 戻り値
成功の場合、ハンドルを記録するための子要素「ｈａｎｄｌｅ」をＵＯＭＬ＿ＲＥＴに追加する。
２．ＵＯＭＬ＿ＣＬＯＳＥ（クローズ、図１２を参照）
２．１ 属性：なし。
２．２ 子要素
２．２．１ ｈａｎｄｌｅ：文字列で表される、オブジェクトへの引用ポインタであるオブジェクトハンドル。
２．２．２ ｄｂ＿ｈａｎｄｌｅ：文字列で表される、文書ベースへの引用ポインタである文書ベースハンドル。
２．３ 戻り値：なし。
３．ＵＯＭＬ＿ＧＥＴ（取得、図１３を参照）
３．１ 属性
ｕｓａｇｅ：用途であり、「ＧｅｔＨａｎｄｌｅ」（指定オブジェクトハンドル取得）、「ＧｅｔＯｂｊ」（指定オブジェクトデータ取得）、「ＧｅｔＰａｇｅＢｍｐ」（ページビットマップ取得）のうち１つ。
３．２ 子要素
３．２．１ ｐａｒｅｎｔ：親オブジェクトハンドルであり、ｕｓａｇｅ属性が「ＧｅｔＨａｎｄｌｅ」の場合に使用する。
３．２．２ ｐｏｓ：位置順番であり、ｕｓａｇｅ属性が「ＧｅｔＨａｎｄｌｅ」の場合に使用する。
３．２．３ ｈａｎｄｌｅ：指定オブジェクトのハンドルであり、ｕｓａｇｅ属性が「ＧｅｔＯｂｊ」の場合に使用する。
３．２．４ Ｐａｇｅ：表示必要なページのハンドルであり、ｕｓａｇｅ属性が「ＧｅｔＰａｇｅＢｍｐ」の場合に使用する。
３．２．５ ｉｎｐｕｔ：入力ページに対する要求を記述し、例えば、１層又は複数層の内容の表示を指定でき（表示可能な層は必ず現在のロールにアクセス権限がある層である）、Ｃｌｉｐ領域の指定によって表示領域の大きさも指定できる。ｕｓａｇｅ属性が「ＧｅｔＰａｇｅＢｍｐ」の場合に使用する。
３．２．６ ｏｕｔｐｕｔ：ページビットマップの出力方式を記述し、ｕｓａｇｅ属性が「ＧｅｔＰａｇｅＢｍｐ」の場合に使用する。
３．３ 戻り値
３．３．１ ｕｓａｇｅ属性が「ＧｅｔＨａｎｄｌｅ」の場合、実行成功のとき、ｐａｒｅｎｔの第ｐｏｓ個のサブオブジェクトのハンドルを記録するための子要素「ｈａｎｄｌｅ」をＵＯＭＬ＿ＲＥＴに追加する。
３．３．２ ｕｓａｇｅ属性が「ＧｅｔＯｂｊ」の場合、実行成功のとき、ｈａｎｄｌｅオブジェクトデータのｘｍｌ表現を含む子要素「ｘｏｂｊ」をＵＯＭＬ＿ＲＥＴに追加する。
３．３．３ ｕｓａｇｅ属性が「ＧｅｔＰａｇｅＢｍｐ」の場合、実行成功のとき、子要素「ｏｕｔｐｕｔ」で指定された位置にページビットマップを出力する。
４．ＵＯＭＬ＿ＳＥＴ（設定、図１４を参照）
４．１ 属性：なし。
４．２ 子要素
４．２．１ Ｈａｎｄｌｅ：オブジェクトのハンドルを設定する。
４．２．２ ｘｏｂｊ：オブジェクトの記述。
４．３ 戻り値：なし。
５．ＵＯＭＬ＿ＩＮＳＥＲＴ（挿入、図１５を参照）
５．１ 属性：なし。
５．２ 子要素
５．２．１ ｐａｒｅｎｔ：親オブジェクトハンドル。
５．２．２ ｘｏｂｊ：オブジェクトの記述。
５．２．３ ｐｏｓ：挿入位置。
５．３ 戻り値：実行成功の場合、パラメータ「ｘｏｂｊ」で表されるオブジェクトを、ｐａｒｅｎｔの第ｐｏｓ個のサブオブジェクトとしてｐａｒｅｎｔに挿入し、新たに挿入されたオブジェクトのハンドルを表す子要素「ｈａｎｄｌｅ」をＵＯＭＬ＿ＲＥＴに追加する。
６．ＵＯＭＬ＿ＤＥＬＥＴＥ（削除、図１６を参照）
６．１ 属性：なし。
６．２ 子要素
６．２．１ ｈａｎｄｌｅ：削除必要なオブジェクトのハンドル。
６．３ 戻り値：なし。
７．ＵＯＭＬ＿ＱＵＥＲＹ（検索問い合わせ、図１７を参照）
７．１ 属性：なし。
７．２ 子要素
７．２．１ ｈａｎｄｌｅ：問い合わせ必要な文書ベースハンドル。
７．２．２ ｃｏｎｄｉｔｉｏｎ：問い合わせ条件。
７．３ 戻り値：成功の場合、問い合わせ結果のハンドルを表す子要素「ｈａｎｄｌｅ」、及び問い合わせ結果の数を表す子要素「ｎｕｍｂｅｒ」をＵＯＭＬ＿ＲＥＴに追加する。ＵＯＭＬ＿ＧＥＴで各問い合わせ結果を取得できる。

ＵＯＭＬオブジェクトは、
文書ベース（ＵＯＭＬ＿ＤＯＣＢＡＳＥ）、文書セット（ＵＯＭＬ＿ＤＯＣＳＥＴ）、文書（ＵＯＭＬ＿ＤＯＣ）、ページ（ＵＯＭＬ＿ＰＡＧＥ）、層（ＵＯＭＬ＿ＬＡＹＥＲ）、オブジェクトグループ（ＵＯＭＬ＿ＯＢＪＧＲＯＵＰ）、テキスト（ＵＯＭＬ＿ＴＥＸＴ）、画像（ＵＯＭＬ＿ＩＭＡＧＥ）、直線（ＵＯＭＬ＿ＬＩＮＥ）、曲線（ＵＯＭＬ＿ＢＥＩＺＥＲ）、円弧（ＵＯＭＬ＿ＡＲＣ）、パス（ＵＯＭＬ＿ＰＡＴＨ）、ソースファイル（ＵＯＭＬ＿ＳＲＣＦＩＬＥ）、背景色（ＵＯＭＬ＿ＢＡＣＫＣＯＬＯＲ）、前景色（ＵＯＭＬ＿ＣＯＬＯＲ）、ＲＯＰ（ＵＯＭＬ＿ＲＯＰ）、文字サイズ（ＵＯＭＬ＿ＣＨＡＲＳＩＺＥ）、及び書体（ＵＯＭＬ＿ＴＹＰＥＦＡＣＥ）を含む。

下記はＵＯＭＬ＿ＤＯＣ、ＵＯＭＬ＿ＴＥＸＴ、及びＵＯＭＬ＿ＣＨＡＲＳＩＺＥを例としてその定義方式を説明する。
１．ＵＯＭＬ＿ＤＯＣ
１．１ 属性：なし。
１．２子要素
１．２．１ ｍｅｔａｄａｔａ：メタデータ。
１．２．２ ｐａｇｅｓｅｔ：各ページ。
１．２．３ ｆｏｎｔｉｎｆｏ：組み込みフォント。
１．２．４ ｎａｖｉｇａｔｉｏｎ：ナビゲーション情報。
１．２．５ ｔｈｒｅａｄ：スレッド情報。
１．２．６ ｍｉｎｉｐａｇｅ：サムネイルイメージ。
１．２．７ ｓｉｇｎｉｔｕｒｅ：デジタル署名。
１．２．８ ｓｈａｒｅｓｏｕｒｃｅ：共有リソース。
２．ＵＯＭＬ＿ＴＥＸＴ
２．１ 属性
２．１．１ Ｅｎｃｏｄｉｎｇ：テキスト符号化方式。
２．２ 子要素
２．２．１ ＴｅｘｔＤａｔａ：テキスト内容。
２．２．２ ＣｈａｒＳｐａｃｉｎｇＬｉｓｔ：非等間隔の場合の文字間隔リスト。
２．２．３ ＳｔａｒｔＰｏｓ：開始位置。
３．ＵＯＭＬ＿ＣＨＡＲＳＩＺＥ
３．１ 属性
３．１．１ ｗｉｄｔｈ：文字幅。
３．１．２ ｈｅｉｇｈｔ：文字高さ。
３．２ 子要素：なし。

上記に準じて類推すると、同様の方法で全てのＵＯＭＬオブジェクトを記述できる。アプリケーションにより文書ベースを操作する場合、上記ＵＯＭＬ動作及びＵＯＭＬオブジェクトによりＸＭＬシンタックスに従って相応のＵＯＭＬ命令を生成し、このＵＯＭＬ命令を文書ベースシステムに送信し、即ち文書ベースシステムに相応の操作指令を送信することを表す。

例えば、文書ベースの作成操作について、以下の命令で完成できる。
＜ＵＯＭＬ＿ＯＰＥＮ ｃｒｅａｔｅ＝"ｔｒｕｅ"＞
＜ｐａｔｈ ｖａｌ＝"ｆ：\\ｄａｔａ\\ｄｏｃｂａｓｅ１．ｓｅｐ"/＞
＜/ＵＯＭＬ＿ＯＰＥＮ＞

文書セットの作成操作について、以下の命令で完成できる。
＜ＵＯＭＬ＿ＩＮＳＥＲＴ＞
＜ｐａｒｅｎｔ ｖａｌ＝"１２３．４５６．７８９"/＞
＜ｐｏｓ ｖａｌ＝"１"/＞
＜ｘｏｂｊ＞
＜ｄｏｃｓｅｔ/＞
＜/ｘｏｂｊ＞
＜/ＵＯＭＬ＿ＩＮＳＥＲＴ＞

説明すべきものとして、ＵＯＭＬがＸＭＬで定義されるものであるが、さらに簡潔そうに見えるために、「＜？ｘｍｌ ｖｅｒｓｉｏｎ＝"１．０" ｅｎｃｏｄｉｎｇ＝"ＵＴＦ−８"？＞」、及び「ｘｍｌｎｓ：ｘｓｉ＝ "ｈｔｔｐ：//ｗｗｗ．ｗ３．ｏｒｇ/２００１/ＸＭＬＳｃｈｅｍａ−ｉｎｓｔａｎｃｅ"」のような通常のＸＭＬフォーマットが先頭に省略されており、ＸＭＬシンタックスに詳しい実施者であれば、実施中に自らそれを追加できる。

ＸＭＬ以外の方式で命令列を定義してもよい。例えば、ＰｏｓｔＳｃｒｉｐｔのような方式を用いて、上記の例が以下のように変化する。
１， "ｆ：\\ｄａｔａ\\ｄｏｃｂａｓｅ１．ｓｅｐ"，/Ｏｐｅｎ
/ｄｏｃｓｅｔ， １， “１２３．４５６．７８９” ，/Ｉｎｓｅｒｔ

同様の考え方によって、他の類型の命令列のフォーマットを定義でき、テキスト方式ではなく、２値化方式で命令列を定義することまでもできる。

以下、各オブジェクトの各操作ごとに１つの命令で表す方式の具体的な実施形態を紹介する。本実施形態において、「ＵＯＭＬ＿ＩＮＳＥＲＴ＿ＤＯＣＳＥＴ」で文書セットの挿入を表し、「ＵＯＭＬ＿ＩＮＳＥＲＴ＿ＰＡＧＥ」でページの挿入を表し、下記のような方式で各命令を定義する。
ＵＯＭＬ＿ＩＮＳＥＲＴ＿ＤＯＣＳＥＴ：文書ベースに１つの文書セットを作成。
属性：なし。
子要素：
ｐａｒｅｎｔ：文書ベースハンドル。
ｐｏｓ：挿入位置。
戻り値：実行成功の場合、新たに挿入された文書セットのハンドルを表す子要素「ｈａｎｄｌｅ」をＵＯＭＬ＿ＲＥＴに追加する。

このように、上記の例が以下のように変化する。
＜ＵＯＭＬ＿ＩＮＳＥＲＴ＿ＤＯＣＳＥＴ＞
＜ｐａｒｅｎｔ ｖａｌ＝"１２３．４５６．７８９"/＞
＜ｐｏｓ ｖａｌ＝"１"/＞
＜/ＵＯＭＬ＿ＩＮＳＥＲＴ＿ＤＯＣＳＥＴ＞

このような方法で命令フォーマットを定義するには、各オブジェクトの正当な各操作ごとにそれぞれ１つの命令を定義する必要があるため、そのデメリットは煩雑である。

以下、関数呼び出しの方式でインターフェース標準を実現する実施形態を紹介する。本実施形態において、上インターフェースから下インターフェースのインターフェース関数を呼び出す方式で、操作指令を文書ベースシステムに送信する。以下、ＵＯＩと呼ばれる本実施形態について、Ｃ＋＋言語を例として説明する。本実施形態において、全てのオブジェクトの基本クラスとしてＵＯＩ＿Ｏｂｊｅｃｔが定義され、各動作ごとに１つの関数が定義される。該関数のパラメータは基本クラスへのポインタまたは引用であってよく、このように該関数は全てのオブジェクトに適用される。

まず、ＵＯＩ戻り値の構造を定義する。
ｓｔｒｕｃｔ ＵＯＩ＿Ｒｅｔ ｛
ＢＯＯＬ ｍ＿ｂＳｕｃｃｅｓｓ；
ＣＳｔｒｉｎｇ ｍ＿ＥｒｒＩｎｆｏ；
｝；

全てのＵＯＩオブジェクトの基本クラスを定義する。
ｃｌａｓｓ ＵＯＩ＿Ｏｂｊｅｃｔ ｛
ｐｕｂｌｉｃ：
ｅｎｕｍ Ｔｙｐｅ ｛
ＴＹＰＥ＿ＤＯＣＢＡＳＥ，
ＴＹＰＥ＿ＤＯＣＳＥＴ，
ＴＹＰＥ＿ＤＯＣ，
ＴＹＰＥ＿ＰＡＧＥ，
ＴＹＰＥ＿ＬＡＹＥＲ，
ＴＹＰＥ＿ＴＥＸＴ，
ＴＹＰＥ＿ＣＨＡＲＳＩＺＥ，
……
｝；
Ｔｙｐｅ ｍ＿Ｔｙｐｅ；
ＵＯＩ＿Ｏｂｊｅｃｔ（）；
ｖｉｒｔｕａｌ 〜 ＵＯＩ＿Ｏｂｊｅｃｔ（）；
ｓｔａｔｉｃ ＵＯＩ＿Ｏｂｊｅｃｔ Ｃｒｅａｔｅ（Ｔｙｐｅ ｏｂｊＴｙｐｅ）；
｝；

次に、「操作動作＋操作オブジェクト」方式の実施形態におけるいくつかのＵＯＭＬ動作に対応して、下記のいくつかのＵＯＩ関数を定義する。
ＵＯＩ＿ＲＥＴ ＵＯＩ＿Ｏｐｅｎ（ｃｈａｒ ＊ｐａｔｈ， ＢＯＯＬ ｂＣｒｅａｔｅ， ＨＡＮＤＬＥ ＊ｐＨａｎｄｌｅ）；
ＵＯＩ＿ＲＥＴ ＵＯＩ＿Ｃｌｏｓｅ（ＨＡＮＤＬＥ ｈａｎｄｌｅ， ＨＡＮＤＬＥ ｄｂ＿ｈａｎｄｌｅ）；
ＵＯＩ＿ＲＥＴ ＵＯＩ＿ＧｅｔＨａｎｄｌｅ（ＨＡＮＤＬＥ ｈＰａｒｅｎｔ， ｉｎｔ ｎＰｏｓ， ＨＡＮＤＬＥ ＊ｐＨａｎｄｌｅ）；
ＵＯＩ＿ＲＥＴ ＵＯＩ＿ＧｅｔＯｂｊＴｙｐｅ（ＨＡＮＤＬＥ ｈａｎｄｌｅ， ＵＯＩ＿Ｏｂｊｅｃｔ ：：Ｔｙｐｅ ＊ｐＴｙｐｅ）；
ＵＯＩ＿ＲＥＴ ＵＯＩ＿ＧｅｔＯｂｊ（ＨＡＮＤＬＥ ｈａｎｄｌｅ， ＵＯＩ＿Ｏｂｊｅｃｔ ＊ｐＯｂｊ）；
ＵＯＩ＿ＲＥＴ ＵＯＩ＿ＧｅｔＰａｇｅＢｍｐ（ＨＡＮＤＬＥ ｈＰａｇｅ， ＲＥＣＴ ｒｅｃｔ， ｖｏｉｄ ＊ｐＢｕｆ）；
ＵＯＩ＿ＲＥＴ ＵＯＩ＿ＳｅｔＯｂｊ（ＨＡＮＤＬＥ ｈａｎｄｌｅ， ＵＯＩ＿Ｏｂｊｅｃｔ ＊ｐＯｂｊ）；
ＵＯＩ＿ＲＥＴ ＵＯＩ＿Ｉｎｓｅｒｔ（ＨＡＮＤＬＥ ｈＰａｒｅｎｔ， ｉｎｔ ｎＰｏｓ， ＵＯＩ＿Ｏｂｊｅｃｔ ＊ｐＯｂｊ， ＨＡＮＤＬＥ ＊ｐＨａｎｄｌｅ ＝ ＮＵＬＬ）；
ＵＯＩ＿ＲＥＴ ＵＯＩ＿Ｄｅｌｅｔｅ（ＨＡＮＤＬＥ ｈａｎｄｌｅ）；
ＵＯＩ＿ＲＥＴ ＵＯＩ＿Ｑｕｅｒｙ（ＨＡＮＤＬＥ ｈＤｏｃｂａｓｅ， ｃｏｎｓｔ ｃｈａｒ ＊ｓｔｒＣｏｎｄｉｔｉｏｎ， ＨＡＮＤＬＥ ＊ｐｈＲｅｓｕｌｔ， ｉｎｔ ＊ｐＲｅｓｕｌｔＣｏｕｎｔ）

その後、各ＵＯＩオブジェクトを定義する。依然としてＵＯＩ＿Ｄｏｃ、ＵＯＩ＿Ｔｅｘｔ及びＵＯＭＬ＿ＣｈａｒＳｉｚｅを例として説明する。
ｃｌａｓｓ ＵＯＩ＿Ｄｏｃ：ｐｕｂｌｉｃ ＵＯＩ＿Ｏｂｊｅｃｔ ｛
ｐｕｂｌｉｃ：
ＵＯＩ＿ＭｅｔａＤａｔａ ｍ＿ＭｅｔａＤａｔａ；
ｉｎｔ ｍ＿ｎＰａｇｅｓ；
ＵＯＩ＿Ｐａｇｅ ＊＊ｍ＿ｐＰａｇｅｓ；
ｉｎｔ ｍ＿ｎＦｏｎｔｓ；
ＵＯＩ＿Ｆｏｎｔ ＊＊ｍ＿ｐＦｏｎｔｓ；
ＵＯＩ＿Ｎａｖｉｇａｔｉｏｎ ｍ＿Ｎａｖｉｇａｔｉｏｎ；
ＵＯＩ＿Ｔｈｒｅａｄ ｍ＿Ｔｈｒｅａｄ；
ＵＯＩ＿ＭｉｎｉＰａｇｅ ＊ｍ＿ｐＭｉｎｉＰａｇｅｓ；
ＵＯＩ＿Ｓｉｇｎａｔｕｒｅ ｍ＿Ｓｉｇｎａｔｕｒｅ；
ｉｎｔ ｍ＿ｎＳｈａｒｅｄ；
ＵＯＩ＿Ｏｂｊ ＊ｍ＿ｐＳｈａｒｅｄ；
ＵＯＩ＿Ｄｏｃ（）；
ｖｉｒｔｕａｌ 〜ＵＯＩ＿Ｄｏｃ（）；
｝；

ｃｌａｓｓ ＵＯＩ＿Ｔｅｘｔ：ｐｕｂｌｉｃ ＵＯＩ＿Ｏｂｊｅｃｔ ｛
ｐｕｂｌｉｃ：
ｅｎｕｍ Ｅｎｃｏｄｉｎｇ ｛
ＥＮＣＯＤＥ＿ＡＳＣＩＩ，
ＥＮＣＯＤＥ＿ＧＢ１３０００，
ＥＮＣＯＤＥ＿ＵＮＩＣＯＤＥ，
……
｝；
Ｅｎｃｏｄｉｎｇ ｍ＿Ｅｎｃｏｄｉｎｇ；
ｃｈａｒ ＊ｍ＿ｐＴｅｘｔ；
Ｐｏｉｎｔ ｍ＿Ｓｔａｒｔ；
ｉｎｔ ＊ｍ＿ＣｈａｒＳｐａｃｅ；
ＵＯＩ＿Ｔｅｘｔ（）；
ｖｉｒｔｕａｌ 〜 ＵＯＩ＿Ｔｅｘｔ（）；
｝；

ｃｌａｓｓ ＵＯＩ＿ＣｈａｒＳｉｚｅ：ｐｕｂｌｉｃ ＵＯＩ＿Ｏｂｊｅｃｔ ｛
ｐｕｂｌｉｃ：
ｉｎｔ ｍ＿Ｗｉｄｔｈ；
ｉｎｔ ｍ＿Ｈｅｉｇｈｔ；

ＵＯＩ＿ＣｈａｒＳｉｚｅ（）；
ｖｉｒｔｕａｌ 〜ＵＯＩ＿ＣｈａｒＳｉｚｅ（）；
｝；

以下、ＵＯＩの使用方法を説明する。まず、文書ベースを作成する。
ｒｅｔ ＝ ＵＯＩ＿Ｏｐｅｎ（"ｆ：\\ｄａｔａ\\ｄｏｃｂａｓｅ１．ｓｅｐ"，ＴＲＵＥ，＆ｈＤｏｃＢａｓｅ）；

次に、新たなオブジェクトを作成するための関数を構築する。
ＨＡＮＤＬＥ ＩｎｓｅｒｔＮｅｗＯｂｊ（ＨＡＮＤＬＥ ｈＰａｒｅｎｔ， ｉｎｔ ｎＰｏｓ， ＵＯＩ＿Ｏｂｊｅｃｔ：：Ｔｙｐｅ ｔｙｐｅ）
｛
ＵＯＩ＿Ｒｅｔ ｒｅｔ；
ＨＡＤＮＬＥ ｈａｎｄｌｅ；
ＵＯＩ＿Ｏｂｊ ＊ｐＮｅｗＯｂｊ ＝ ＵＯＩ＿Ｏｂｊ：：Ｃｒｅａｔｅ（ｔｙｐｅ）；
ｉｆ（ｐＮｅｗＯｂｊ ＝＝ ＮＵＬＬ）
ｒｅｔｕｒｎ ＮＵＬＬ；
ｒｅｔ ＝ ＵＯＩ＿Ｉｎｓｅｒｔ（ｈＰａｒｅｎｔ，ｎＰｏｓ，ｐＮｅｗＯｂｊ， ＆ｈａｎｄｌｅ）；
ｄｅｌｅｔｅ ｐＮｅｗＯｂｊ；
ｒｅｔｕｒｎ ｒｅｔ．ｍ＿ｂＳｕｃｃｅｓｓ ？ ｈａｎｄｌｅ： ＮＵＬＬ；
｝

その後、オブジェクトを直接に取得するための関数を構築する。
ＵＯＩ＿Ｏｂｊ ＊ＧｅｔＯｂｊ（ＨＡＮＤＬＥ ｈａｎｄｌｅ）
｛
ＵＯＩ＿Ｒｅｔ ｒｅｔ；
ＵＯＩ＿Ｏｂｊｅｃｔ：：Ｔｙｐｅ ｔｙｐｅ；
ＵＯＩ＿Ｏｂｊ ＊ｐＯｂｊ；
ｒｅｔ＝ＵＯＩ＿ＧｅｔＯｂｊＴｙｐｅ（ｈａｎｄｌｅ，＆ｔｙｐｅ）；
ｉｆ（！ｒｅｔ．ｍ＿ｂＳｕｃｃｅｓｓ）
ｒｅｔｕｒｎ ＮＵＬＬ；
ｐＯｂｊ＝ＵＯＩ＿Ｏｂｊ：：Ｃｒｅａｔｅ（ｔｙｐｅ）；
ｉｆ（ｐＯｂｊ＝＝ＮＵＬＬ）
ｒｅｔｕｒｎ ＮＵＬＬ；
ｒｅｔ＝ＵＯＩ＿ＧｅｔＯｂｊ（ｈａｎｄｌｅ，ｐＯｂｊ）；
ｉｆ（！ｒｅｔ．ｍ＿ｂＳｕｃｃｅｓｓ） ｛
ｄｅｌｅｔｅ ｐＯｂｊ；
ｒｅｔｕｒｎ ＮＵＬＬ；
｝
ｒｅｔｕｒｎ ｐＯｂｊ；
｝

各オブジェクトの各操作ごとに１つのインターフェース関数を定義する方式では、文書セット挿入の操作指令は、上インターフェースから下記の方式で下インターフェースのインターフェース関数を呼び出すことによって、文書ベースシステムに送信される。
ＵＯＩ＿ＩｎｓｅｒｔＤｏｃｓｅｔ（ｐＤｏｃｂａｓｅ，０）；

各オブジェクトクラス（例えば文書ベースクラス）をカプセル化する方式では、該オブジェクトの実行可能な操作を該クラスのメソッドとして定義する。例えば、
ｃｌａｓｓ ＵＯＩ＿ＤｏｃＢａｓｅ：ｐｕｂｌｉｃ ＵＯＩ＿Ｏｂｊ
｛
ｐｕｂｌｉｃ：
/＊！
＊ \ｂｒｉｅｆ 文書ベースの作成
＊ \ｐａｒａｍ ｓｚＰａｔｈ： 文書ベースのフルパス
＊ \ｐａｒａｍ ｂＯｖｅｒｒｉｄｅ： 元のファイルをオーバーライトするかどうか
＊ \ｒｅｔｕｒｎ ＵＯＩ＿ＤｏｃＢａｓｅ オブジェクト
＊/
ＢＯＯＬ Ｃｒｅａｔｅ（ｃｏｎｓｔ ｃｈａｒ ＊ｓｚＰａｔｈ， ｂｏｏｌ ｂＯｖｅｒｒｉｄｅ ＝ ｆａｌｓｅ）；
/＊！
＊ \ｂｒｉｅｆ 文書ベースのオープン
＊ \ｐａｒａｍ ｓｚＰａｔｈ： 文書ベースのフルパス
＊ \ｒｅｔｕｒｎ ＵＯＩ＿ＤｏｃＢａｓｅ オブジェクト
＊/
ＢＯＯＬ Ｏｐｅｎ（ｃｏｎｓｔ ｃｈａｒ ＊ｓｚＰａｔｈ）；
/＊！
＊ \ｂｒｉｅｆ 文書ベースのクローズ
＊ \ｐａｒａｍ なし
＊ \ｒｅｔｕｒｎ なし
＊/
ｖｏｉｄ Ｃｌｏｓｅ（）；
/＊！
＊ \ｂｒｉｅｆ ロールリストの取得
＊ \ｐａｒａｍ なし
＊ \ｒｅｔｕｒｎ ＵＯＩ＿ＲｏｌｅＬｉｓｔ オブジェクト
＊ \ｓａ ＵＯＩ＿ＲｏｌｅＬｉｓｔ
＊/
ＵＯＩ＿ＲｏｌｅＬｉｓｔ ＧｅｔＲｏｌｅＬｉｓｔ（）；
/＊！
＊ \ｂｒｉｅｆ 文書ベースの記憶
＊ \ｐａｒａｍ ｓｚＰａｔｈ： 記憶しようとする文書ベースのフルパス
＊ \ｒｅｔｕｒｎ なし
＊/
ｖｏｉｄ Ｓａｖｅ（ｃｈａｒ ＊ｓｚＰａｔｈ ＝ ０）；
/＊！
＊ \ｂｒｉｅｆ 文書セットの挿入
＊ \ｐａｒａｍ ｎＰｏｓ： 文書セットの挿入位置
＊ \ｒｅｔｕｒｎ ＵＯＩ＿ＤｏｃＳｅｔ オブジェクト
＊ \ｓａ ＵＯＩ＿ＤｏｃＳｅｔ
＊/
ＵＯＩ＿ＤｏｃＳｅｔ ＩｎｓｅｒｔＤｏｃＳｅｔ（ｉｎｔ ｎＰｏｓ）；
/＊！
＊ \ｂｒｉｅｆ 指定インデックスの文書セットの取得
＊ \ｐａｒａｍ ｎＩｎｄｅｘ： 文書リストのインデックス番号
＊ \ｒｅｔｕｒｎ ＵＯＩ＿ＤｏｃＳｅｔ オブジェクト
＊ \ｓａ ＵＯＩ＿ＤｏｃＳｅｔ
＊/
ＵＯＩ＿ＤｏｃＳｅｔ ＧｅｔＤｏｃＳｅｔ（ｉｎｔ ｎＩｎｄｅｘ）；
/＊！
＊ \ｂｒｉｅｆ 文書セットの総数の取得
＊ \ｐａｒａｍ なし
＊ \ｒｅｔｕｒｎ 文書セットの数
＊/
ｉｎｔ ＧｅｔＤｏｃＳｅｔＣｏｕｎｔ（）；
/＊！
＊ \ｂｒｉｅｆ 文書ベース名称の設定
＊ \ｐａｒａｍ ｎＬｅｎ： 文書ベース名称の長さ
＊ \ｐａｒａｍ ｓｚＮａｍｅ： 文書ベース名称
＊ \ｒｅｔｕｒｎ なし
＊/
ｖｏｉｄ ＳｅｔＮａｍｅ（ｉｎｔ ｎＬｅｎ， ｃｏｎｓｔ ｃｈａｒ＊ ｓｚＮａｍｅ）；
/＊！
＊ \ｂｒｉｅｆ 文書ベース名称の長さの取得
＊ \ｐａｒａｍ なし
＊ \ｒｅｔｕｒｎ 長さ
＊/
ｉｎｔ ＧｅｔＮａｍｅＬｅｎ（）；
/＊！
＊ \ｂｒｉｅｆ 文書ベース名称の取得
＊ \ｐａｒａｍ なし
＊ \ｒｅｔｕｒｎ 文書ベース名称
＊/
ｃｏｎｓｔ ｃｈａｒ＊ ＧｅｔＮａｍｅ（）；
/＊！
＊ \ｂｒｉｅｆ 文書ベースｉｄの長さの取得
＊ \ｐａｒａｍ なし
＊ \ｒｅｔｕｒｎ 長さ
＊/
ｉｎｔ ＧｅｔＩＤＬｅｎ（）；
/＊！
＊ \ｂｒｉｅｆ 文書ベースｉｄの取得
＊ \ｐａｒａｍ なし
＊ \ｒｅｔｕｒｎ ｉｄ
＊/
ｃｏｎｓｔ ｃｈａｒ＊ ＧｅｔＩＤ（）；
//！ コンストラクタ関数
ＵＯＩ＿ＤｏｃＢａｓｅ（）；
//！ デストラクタ関数
ｖｉｒｔｕａｌ 〜ＵＯＩ＿ＤｏｃＢａｓｅ（）；
｝；

このように、文書セット挿入の操作指令は、上インターフェースから下記の方式で下インターフェースのインターフェース関数を呼び出すことによって、文書ベースシステムに送信される。
ｐＤｏｃＢａｓｅ．ＩｎｓｅｒｔＤｏｃｓｅｔ（０）；

同様の方法によっては、Ｊａｖａ（登録商標）、Ｃ＃、ＶＢ、Ｄｅｌｐｈｉなどの各種のプログラミング言語で開発されたアプリケーションに対して、異種類のインターフェース標準を設計するようにしてもよい。

インターフェース標準には、特定のオペレーションシステム（例えばＷＩＮＤＯＷＳ（登録商標）、ＵＮＩＸ（登録商標）/ＬＩＮＵＸ（登録商標）、ＭＡＣ（登録商標） ＯＳ、ＳＹＭＢＩＡＮ（登録商標））又は特定のハードウェアプラットフォーム（例えばｘ８６ＣＰＵ、ＭＩＰＳ、ＰＯＷＥＲ ＰＣなど）に関連する特徴が含まれなければ、このインターフェース標準がクロスプラットフォーム性を備え、異なるプラットフォームで運行しているアプリケーション及び文書ベースシステムは、同様のインターフェース標準を統一的に使用できるようになって、特にあるプラットフォームで運行しているアプリケーションから、他のプラットフォームで運行している文書ベースシステムを呼び出して、相応の操作を実行できるようになる。例えば、アプリケーションは、ＰＣ及びＷｉｎｄｏｗｓオペレーションシステムを使用しているクライアント側に配置され、文書ベースシステムは、大型機及びＬＩＮＵＸオペレーションシステムを使用しているサーバ側に配置されるが、アプリケーションから依然として、ローカル文書ベースシステムへの呼び出しと同様に、サーバにおける文書ベースシステムを呼び出して、相応の文書操作を実行することができる。

インターフェース標準には、特定のプログラミング言語に関連する特徴が含まれない場合、このインターフェース標準がプログラミング言語と関係ないことも可能である。上記からわかるように、命令列の方式では、プラットフォーム及びプログラミング言語と関係ないインターフェース標準を容易に構築でき、汎用性も高くなる。特に、ＸＭＬで命令列を構成すると、現在、各種の異なるプラットフォーム、異なるプログラミング言語にも、取得しやすいＸＭＬ生成解析ツールがあるため、このインターフェース標準は、優れたクロスプラットフォーム性、及びプログラミング言語との無関係性があるだけでなく、エンジニアによる上インターフェースユニット及び下インターフェースユニットへの開発にも非常に便利である。

上記には複数のインターフェース標準の実現方法が挙げられており、類似の考え方によって設計されるさらに多くのインターフェース標準も本発明の保護範囲に含まれる。

理解すべきものとして、同様の考え方によって上記実施形態の上で操作指令を追加、又は簡略化してもよい。特に文書モデルが簡略化される場合、操作指令も相応に簡略化される。一番簡略化された場合は、文書の作成、ページの作成、各レイアウトオブジェクトの作成のいくつかの操作指令だけある。

文書操作処理
図１を参照して、本発明の好ましい実施形態による文書処理システムの動作プロセスを引き続き説明する。

アプリケーションは、インターフェース標準に適合する上インターフェースユニットを含むアプリケーション、例えば、Ｏｆｆｉｃｅアプリケーション、内容管理、リソース収集などである。いずれかのアプリケーションが文書を操作しようとする場合、前記方法に従って指令を文書ベースシステムに伝送し、文書ベースシステムが指令に基づいて具体的な操作プロセスを完成する。

文書ベースシステムは、文書ベースデータに対して、記憶及び組織を自由に行うことができる。例えば、１つの文書ベースの全ての文書を１つのディスクファイルに記憶するようにしてよく、１つの文書を１つのディスクファイルに対応させ、オペレーションシステムのファイルシステム機能を利用してマルチ文書組織を実現するようにしてよく、１ページを１つのディスクファイルに対応させてもよく、オペレーションシステムを完全に利用しなくて、ディスクに領域を残して、ディスクトラック、セクタを直接に管理するようにしてもよい。文書ベースデータの記憶フォーマットについて、２値化フォーマット、ＸＭＬ、又は２値化ＸＭＬで保存してよい。ページ記述言語（ページ上のテキスト、図形、画像などのオブジェクトを定義する方法）について、ＰｏｓｔＳｃｒｉｐｔ、ＰＤＦ、又はＳＰＤ（書生会社で使用するページ記述言語）を採用してよく、もちろん、統一的なインターフェース標準に適合する限り、カスタマイズのいかなるページ記述言語を採用してもよい。

例えば、ＸＭＬで文書ベースデータを記述してよい。文書モデルが階層型である場合、それと完全に対照して相応のＸＭＬツリーを確立できる。作成操作の実行時にＸＭＬツリーにノードを追加し、削除操作の実行時に相応ノードを削除し、設定操作の実行時に相応ノードの属性を設定し、取得操作の実行時に相応ノードの属性を取り出してアプリケーションに返信し、問い合わせ操作の実行時に関連ノードを走査して検索する。
以下、上記実施形態を更に説明する。

１．ＸＭＬで各オブジェクトを記述する。つまり、各オブジェクトごとに対応のＸＭＬツリーを確立する。属性が比較的に簡単なオブジェクトについて、対応のＸＭＬツリーにルートノードだけあり、属性が比較的に複雑なオブジェクトについて、対応のＸＭＬツリーにサブノードもある。具体的な記述方法について、前記ＸＭＬで操作オブジェクトを定義する説明を参照してよい。

２．文書ベースが新規作成される場合、ルートノードが文書ベースオブジェクトであるＸＭＬファイルを新規作成する。

３．文書ベースにオブジェクト（例えば、テキストオブジェクト）が挿入されるたびに、このオブジェクトに対応するＸＭＬツリーを挿入位置の親ノード（例えば層）の下に挿入する。このように、文書ベースの各オブジェクトはそれぞれ、文書ベースがルートノードであるＸＭＬツリーにおける対応ノードを有する。

４．オブジェクトが削除される場合、このオブジェクトに対応するノード、及び該ノードの全てのサブノードを削除する。削除プロセスでは、リーフノードから始めた走査を下から上まで行う。

５．オブジェクト属性が設定される場合、このオブジェクトに対応するノードの属性を該属性に設定する。この属性がサブノードの属性で表される場合、対応のサブノードの属性を設定する。

６．オブジェクト属性が取得される場合、このオブジェクトに対応するノードにアクセスし、このノードの属性及びサブノードによって該オブジェクトの属性を取得する。

７．オブジェクトのハンドルが取得される場合、このオブジェクトに対応するノードのＸＭＬパスを戻す。

８．オブジェクト（例えばページ）が指定位置にコピーされる場合、このオブジェクトに対応するノードから始めるサブツリー全体を、目標位置に対応する親ノード（例えば文書）の下にコピーする。オブジェクトが他の文書ベースにコピーされる場合、このサブツリーで引用されたオブジェクト（例えば組込みフォント）も一緒にコピーする必要がある。

９．レイアウト情報の取得指令が実行される場合、まず、サイズが指定領域と同じである指定ビットマップフォーマットの空白ビットマップを生成し、その後、指定ページの全てのレイアウトオブジェクトを走査し、指定領域内に位置するレイアウトオブジェクト（一部分のみ該領域内にあるものも含む）であれば、その意味を解釈して、レイアウトへ相応に反映する。具体的なプロセスが比較的に複雑で専門的であるが、従来のＲＩＰ技術の範囲に属するので、ここで説明を省略する。

文書セキュリティ処理
ロールオブジェクトの作成時に、ランダムの公開鍵と秘密鍵の鍵ペア（例えば５１２ｂｉｔのＲＳＡ鍵）を生成し、公開鍵をロールオブジェクトに記憶し、秘密鍵をアプリケーションに戻す。

アプリケーションのログイン時に、ランダムデータブロック（例えば１２８バイト）を生成し、相応のロールオブジェクトの公開鍵で該データを暗号化してアプリケーションに送信する。アプリケーションがそれを復号化してから比較検証し、正しい場合、該ロールに対応する秘密鍵をアプリケーションが確実に有することを表し、ログイン成功になる。念のため、この認証プロセスを３回繰り返してよく、３回とも通過した場合のみ、ログイン成功になる。

あるオブジェクトに対して署名を行うことは、即ちその対応ノードから始めるサブツリーに対して署名を行うことである。具体的な物理記憶方式による影響を署名に及ぼさないために、予め正規化を行うことにより、論理的に等価な変化（例えば、記憶位置の変化が相応ポインタの変化につながる）が署名の有効性を影響しないようにする必要がある。

正規化の方法は、目標オブジェクトをルートノードとするサブツリーの各ノード（即ち目標オブジェクト及びその各サブオブジェクト）を深さ優先で走査し、走査順序に従って各ノードの正規化結果を順次算出して結合することを含む。

ここで、サブツリーのあるノードの正規化結果を算出する方法は、まず、このノードのサブノード数のＨＡＳＨ値を算出し、次に、このノード類型及びその各属性のＨＡＳＨ値を順次算出して、順序に従って該ノードのサブノード数のＨＡＳＨ値の次に結合し、その後、この結合結果のＨＡＳＨ値を算出して、該ノードの正規化結果を得ることを含む。サブツリーのあるノードで引用されたオブジェクトに対しても署名を一緒に行う必要がある場合、該ノードで引用されたオブジェクトも該ノードのサブノードとして、上記と同様の方法で処理するようにしてよい。

正規化してから、ＨＡＳＨ値を算出してロールの秘密鍵で署名する処理が従来技術を採用して行われることができるため、ここで説明を省略する。

上記正規化プロセスにおいて、ノードの正規化結果を算出する方法は、このノードのサブノード数、類型及びその各属性を順序に従ってセパレーターで結合し、この結合結果のＨＡＳＨ値を算出して、該ノードの正規化結果を得ることを含むようにしてよい。ノードの正規化結果を算出する方法は、このノードのサブノード数、類型及びその各属性の長さを順序に従ってセパレーターで結合して、またサブノード数、類型、各属性と結合して、該ノードの正規化結果を得ることを含むようにしてもよい。つまり、ノードの正規化結果を算出する方法は、ツリーのあるノードに対して、そのサブノード数、類型、各属性、及びサブノード数・類型・各属性の長さ（選択可能）の元の値又は特定変換（例えば、ＨＡＳＨ、圧縮）後の値を、所定の順序に従って結合する（直接に結合又はセパレーターで結合）ことを含む。

上記所定の順序は、サブノード数の長さ、類型の長さ、各属性の長さ、サブノード数、類型、各属性の任意の所定の並べ順序を含む。

また、サブツリーの各ノードの走査について、深さ優先走査、幅優先走査のいずれかを採用してもよい。

上記方案の各種の変形を提供することが難しくない。例えば、各ノードのサブノード数を深さ優先の順序に従ってセパレーターで結合して、また各ノードの他のデータの正規化結果と結合する。つまり、該サブツリーの全てのノードのサブノード数、類型及び各属性を所定の方法によって並べる限り、本実施形態の変形に属する。

あるオブジェクトに対する権限設定について、最も簡単な実現方式は、各ロールの該オブジェクト（及びそのサブオブジェクト）に対する権限を簡単に記録して、且つ今後各ロールでのアクセス時に比較し、権限に適合する場合、相応の操作を許し、権限に適合しない場合、エラー情報を報告して戻すことを含む。更に好ましい実現方式は、相応のデータを暗号化して、鍵で権限を制御することを含む。該ロールには相応の鍵がなければ対応の権限もない。このような方式は攻撃耐性が更に強い。具体的な方案は以下の通りである。

ａ）保護されたデータ領域（通常はサブツリーであり、あるオブジェクト及びその全てのサブオブジェクトに対応する）に対応するＰＫＩ鍵ペアがあり、そのうちの暗号化鍵を用いてこのデータ領域を暗号化する。

ｂ）リード権限のあるロールに復号化鍵を与え、該ロールがこの鍵を用いてこのデータ領域を復号化して、これらのデータを正確に読み出すことができる。

ｃ）ライト権限のあるロールに暗号化鍵を与え、該ロールがこの鍵を用いて修正後のデータを暗号化して、該領域のデータを正確に書き込むことができる。

ｄ）ＰＫＩの暗号化・復号化の効率が比較的に低いため、運行効率を向上させるように、対称鍵を利用してデータ領域を暗号化してもよい。暗号化鍵でこの対称鍵を暗号化し、暗号化された鍵データを復号化鍵で復号化することで、正確な対称鍵を取得する。リード権限だけあるロールが対称鍵を取得した後にそれを利用してデータを修正することを防止するために、暗号化鍵を用いて該データ領域に対してデジタル署名を行うようにしてよい。ライト権限のあるロールが該データ領域を修正するたびに改めて署名を行うことによって、データがライト権限のないロールに改竄されないことを確保する。

ｅ）あるロールに暗号化鍵又は復号化鍵を与える場合、このロールの公開鍵を用いて該暗号化鍵又は復号化鍵を暗号化してから記憶するようにしてよい。これにより、該ロールの秘密鍵を持たなければ、該暗号化鍵又は復号化鍵を取り出すことができない。

説明すべきものとして、本発明に説明した文書セキュリティ技術、例えば、ロールに基づく権限管理、ロールの認証方式、マルチロールログイン、ツリー構造に対する正規化技術、細粒度の権限管理ユニット、暗号化に基づく権限設定などは、本発明に係る文書処理システムのみならず、更に幅広い他の応用場合にも適用できる。

層に対する管理
本発明において、文書処理システムで紙の特性をよく模擬できるように、「追加のみ修正せず」という技術案を提供している。つまり、各アプリケーションは、現在の文書内容の上に新たな内容を追加するだけで、既存内容を修正・削除しない。これにより、文書のページが紙のようになり、異なる人が異なるペンを用いて紙に書くことができるが、だれでも既存内容を修正・削除できない。具体的な方法は以下の通りである。各アプリケーションは、他のアプリケーションで生成された文書を編集する場合、現在の文書の上に１層を新たに追加し、本アプリケーションで新たに編集された全ての内容をこの層に置き、前の各層の内容を修正・削除しない。このように、各文書の各層ごとに１つだけのアプリケーションによって管理・維持されるが、他のアプリケーションで該層を編集できなくなる。現在の社会が紙に基づいて運営されるため、文書処理システムは、紙の特性に適合する限り、現在の応用ニーズを満たすことができ、十分の実用価値がある。

各層の内容が生成された後、修正・削除されないことを確保するために、各層のデジタル署名オブジェクトを利用してよい。デジタル署名は、本層の内容に対して署名してよい。好ましくは、本層及び本層の前に生成された全ての層の内容に対して一緒に署名する。署名後にも、文書に対するコメントなどの更なる編集が妨害されない。新たな内容が新たな層に位置し、署名時に既存の各層が修正・破壊されない限り、署名は依然として有効であるが、署名者が署名前の内容のみに対して責任を負い、署名後の内容に対して責任を負わない。これは応用ニーズに非常に適合する技術案であり、かなり実用価値がある。これに比べて、従来の他の技術では、署名後の編集が許されなかったり、編集後（「追加のみ修正せず」の編集にもかかわらず）に署名が破壊されたりする。

前記技術案では、文書の既存内容の修正が許されなく、紙の特性との互換性及びデジタル署名問題を考慮しなくても、修正必要の場合にレイアウトレベルの編集しかできない。即ち、各レイアウトオブジェクトに対する編集（追加、削除、修正）は、他のレイアウトオブジェクトに影響を及ぼさない（汎用文書モデルが可視部分を基礎として構築され、大量の不可視の、レイアウトオブジェクト同士間の関係を含まないため、いかなるレイアウトオブジェクトを修正する場合にも、他のレイアウトオブジェクトへの相応の調整を発生することなく、例えば、１つの文字が削除される場合、右側の文字が自動的に左へ移動することなく、その位置に空白が残ることになる。）。ユーザが文書の既存内容を元の方式で編集しようとする場合、以下の技術案でこの応用ニーズをよく満たすことができる。該方案について、アプリケーションが初期編集を完成すると、１層を新規作成して現在の編集内容を保存する以外に、またソースファイル（各オブジェクト間の完全な関係がアプリケーション自分のフォーマットで記録されているファイル、例えば．ｄｏｃファイル）を文書に組み込む。今回引き続き編集する必要がある場合、文書からこのソースファイルを取り出して、該ソースファイルを使用して引き続き編集する。編集が完成された後、該アプリケーションで管理された層を消去し、該層の内容を改めて生成し、且つ新たに修正されたソースファイルを引き続き文書に組み込む。

具体的な方法は以下のステップを含む。
１．アプリケーションは、文書を初めて処理するとき、１層を新規作成し、新たな編集内容に対応するレイアウトオブジェクトを新規作成の層に挿入するとともに、自分のフォーマットで新たな編集内容（即ちソースファイル）を別途記憶する。
２．文書オブジェクトのサブオブジェクトとしてソースファイルオブジェクトを新規作成する。該ソースファイルオブジェクトは、ソースファイルを組み込み（例えば、２値化データの方式で全体組み込む）、どの層が該ソースファイルオブジェクトに対応するかを記録することに用いられる。
３．同じアプリケーションを用いて該文書を再度編集するとき、対応のソースファイルオブジェクトから対応のソースファイルを取り出す。
４．該ソースファイルを使用して該層の内容を引き続き編集する。このソースファイルのフォーマットが該アプリケーション自分のフォーマットであるため、該アプリケーション自分の機能によって該層の内容を引き続き編集できる。
５．再度編集が終了した後、新たに編集後の結果によって該層の内容を更新する（例えば、全部消去後改めて生成する方式で）とともに、新たに修正後のソースファイルを改めて文書オブジェクトに組み込む。
６．このように繰り返して、元のアプリケーションを用いて元の方式で文書の既存内容を編集できる。

上記技術案を採用することで、文書の相互運用性を最大限に実現できる。十分のセキュリティ権限がある前提で、アプリケーション及び文書は本発明の技術を採用すると、以下の機能を実現できる。
１．いかなる文書について、いかなるアプリケーションでも、正確にオープン・表示・印刷できる。
２．いかなる文書について、いかなるアプリケーションでも、いかなる内容を追加でき、且つ文書の既存署名が破壊されない。
３．いかなる文書について、文書の既存署名を考慮する必要がない（署名なし、又は署名あるが破壊を許す）前提で、いかなるアプリケーションでも、文書の既存内容に対してレイアウトレベルの編集を行うことができる。
４．いかなる文書について、文書の既存内容の元の編集アプリケーションで、この内容を正常に編集できる。

上記からわかるように、本発明の層に対する管理によって、文書の管理、相互運用性、セキュリティ設定に極めて大きな便利をもたらす。

以下、アプリケーションＡが文書を作成し、アプリケーションＢがそれを編集することを例として、その動作プロセスを説明する。本実施形態では、インターフェース標準としてＵＯＩが用いられる。
１．文書ベースｃ：\ｓａｍｐｌｅ\ｍｙｄｏｃｂａｓｅ．ｓｅｐを作成して、そのハンドルをｈＤｏｃＢａｓｅに保存するための指令を、アプリケーションＡが送信する。
ＵＯＩ＿Ｏｐｅｎ（“ｃ：\\ｓａｍｐｌｅ\\ｍｙｄｏｃｂａｓｅ．ｓｅｐ”， ＴＲＵＥ， ＆ｈＤｏｃＢａｓｅ）；
２．文書ベースｈＤｏｃＢａｓｅに文書セットを新規作成して、そのハンドルをｈＤｏｃＳｅｔに保存するための指令を、アプリケーションＡが送信する。
ｈＤｏｃＳｅｔ ＝ ＩｎｓｅｒｔＮｅｗＯｂｊ（ｈＤｏｃＢａｓｅ， ０， ＵＯＩ＿Ｏｂｊ：： ＴＹＰＥ＿ＤＯＣＳＥＴ）；
本実施形態では、この文書ベースに１つの文書セット、即ち第１文書セットのみある。
３．文書セットｈＤｏｃＳｅｔに文書を新規作成して、そのハンドルをｈＤｏｃに保存するための指令を、アプリケーションＡが送信する。
ｈＤｏｃ ＝ ＩｎｓｅｒｔＮｅｗＯｂｊ（ｈＤｏｃＳｅｔ， ０， ＵＯＩ＿Ｏｂｊ：： ＴＹＰＥ＿ＤＯＣ）；
本実施形態では、この文書セットに１つの文書、即ち第１文書のみある。
４．文書ｈＤｏｃに、幅がｗであり高さがｈであるページを新規作成して、そのハンドルをｈＰａｇｅに保存するための指令を、アプリケーションＡが送信する。
ＵＯＩ＿Ｐａｇｅ ｐａｇｅ；
ｐａｇｅ．ｓｉｚｅ．ｗ ＝ ｗ；
ｐａｇｅ．ｓｉｚｅ．ｈ ＝ ｈ；
ＵＯＩ＿Ｉｎｓｅｒｔ（ｈＤｏｃ， ０， ＆ｐａｇｅ， ＆ｈＰａｇｅ）；
本実施形態では、この文書に１ページ、即ち第１ページのみある。
５．ページｈＰａｇｅに層を新規作成して、そのハンドルをｈＬａｙｅｒに保存するための指令を、アプリケーションＡが送信する。
ｈＬａｙｅｒ ＝ ＩｎｅｒｔＮｅｗＯｂｊ（ｈＰａｇｅ， ０， ＵＯＩ＿Ｏｂｊ：：ＴＹＰＥ＿ＬＡＹＥＲ）；
本実施形態では、このページに１層、即ち第１層のみある。
６．文字サイズをｓに設定するための指令を、アプリケーションＡが送信する。
ＵＯＩ＿ＣｈａｒＳｉｚｅ ｃｈａｒＳｉｚｅ；
ｃｈａｒＳｉｚｅ．ｍ＿Ｗｉｄｔｈ ＝ ｃｈａｒＳｉｚｅ．ｍ＿Ｈｅｉｇｈｔ ＝ ｓ；
ＵＯＩ＿Ｉｎｓｅｒｔ（ｈＬａｙｅｒ， ０， ＆ｃｈａｒＳｉｚｅ）
本実施形態では、この層の第１レイアウトオブジェクトが文字サイズオブジェクトである。
７．座標（ｘ１，ｙ１）の位置に文字列「書生の意氣は揮斥にして方に遒かりき」を挿入するための指令を、アプリケーションＡが送信する。
ＵＯＩ＿Ｔｅｘｔ ｔｅｘｔ；
ｔｅｘｔ．ｍ＿ｐＴｅｘｔ ＝ Ｄｕｐｌｉｃａｔｅ（“書生の意氣は揮斥にして方に遒かりき”）；
ｔｅｘｔ．ｍ＿Ｅｎｃｏｄｉｎｇ ＝ ＵＯＩ＿Ｔｅｘｔ：： ＥＮＣＯＤＥ＿ＧＢ１３０００；
ｔｅｘｔ．ｍ＿Ｓｔａｒｔ．ｘ ＝ ｘ１；
ｔｅｘｔ．ｍ＿Ｓｔａｒｔ．ｙ ＝ ｙ１；
ＵＯＩ＿Ｉｎｓｅｒｔ（ｈＬａｙｅｒ， １， ＆ｔｅｘｔ）；
本実施形態では、この層の第２レイアウトオブジェクトがテキストオブジェクトである。
８．文書ベースｈＤｏｃＢａｓｅをクローズするための指令を、アプリケーションＡが送信する。
ＵＯＩ＿Ｃｌｏｓｅ（ｈＤｏｃＢａｓｅ）；
文書ベースｃ：\ｓａｍｐｌｅ\ｍｙｄｏｃｂａｓｅ．ｓｅｐを開いて、そのハンドルをｈＤｏｃＢａｓｅに保存するための指令を、アプリケーションＢが送信する。
ＵＯＩ＿Ｏｐｅｎ（“ｃ：\\ｓａｍｐｌｅ\\ｍｙｄｏｃｂａｓｅ．ｓｅｐ”， ＦＡＬＳＥ， ＆ｈＤｏｃＢａｓｅ）；
文書ベースｈＤｏｃＢａｓｅの第１文書セットのポインタを取得して、そのハンドルをｈＤｏｃＳｅｔに保存するための指令を、アプリケーションＢが送信する。
ＵＯＩ＿ＧｅｔＨａｎｄｌｅ（ｈＤｏｃＢａｓｅ， ０， ＆ｈＤｏｃＳｅｔ）；
９．文書セットｈＤｏｃＳｅｔの第１文書のポインタを取得して、そのハンドルをｈＤｏｃに保存するための指令を、アプリケーションＢが送信する。
ＵＯＩ＿ＧｅｔＨａｎｄｌｅ（ｈＤｏｃＳｅｔ， ０， ＆ｈＤｏｃ）；
１０．文書ｈＤｏｃの第１ページのポインタを取得して、そのハンドルをｈＰａｇｅに保存するための指令を、アプリケーションＢが送信する。
ＵＯＩ＿ＧｅｔＨａｎｄｌｅ（ｈＤｏｃ， ０， ＆ｈＰａｇｅ）；
１１．アプリケーションＢが、このページを表示するためのビットマップを取得する。
ＵＯＩ＿ＧｅｔＰａｇｅＢｍｐ（ｈＰａｇｅ， ｒｅｃｔ， ｂｕｆ）；
１２．ｈＰａｇｅの第１層のポインタを取得して、そのハンドルをｈＬａｙｅｒに保存するための指令を、アプリケーションＢが送信する。
ＵＯＩ＿ＧｅｔＨａｎｄｌｅ（ｈＰａｇｅ， ０， ＆ｈＬａｙｅｒ）；
１３．第１レイアウトオブジェクトのハンドルｈＯｂｊを取得するための指令を、アプリケーションＢが送信する。
ＵＯＩ＿ＧｅｔＨａｎｄｌｅ（ｈＬａｙｅｒ， ０， ＆ｈＯｂｊ）；
１４．ｈＯｂｊの類型を取得するための指令を、アプリケーションＢが送信する。
ＵＯＩ＿ＧｅｔＯｂｊＴｙｐｅ（ｈＯｂｊ， ＆ｔｙｐｅ）；
１５．アプリケーションＢは、これが文字サイズオブジェクトであると発見し、このオブジェクトを取得する。
ＵＯＩ＿ＧｅｔＯｂｊ（ｈＯｂｊ， ＆ｃｈａｒＳｉｚｅ）；
１６．アプリケーションＢが文字高さを２倍に拡大する。
ｃｈａｒＳｉｚｅ．ｍ＿Ｈｅｉｇｈｔ ＊＝ ２；
ＵＯＩ＿ＳｅｔＯｂｊ（ｈＯｂｊ， ＆ｃｈａｒＳｉｚｅ）；

アプリケーションＢがページビットマップを改めて取得して表示する。このとき、スクリーンにおいて「書生の意氣は揮斥にして方に遒かりき」が長体文字になっている。

以下、図１０を参照して、本発明による文書処理システムで操作を実行する実施形態を説明する。この実施形態では、アプリケーションが統一的なインターフェース標準（例えば、ＵＯＭＬインターフェース）を介して、文書に対する操作を要求する。文書ベースシステムに異なるメーカーからの異なるタイプがあり得るが、アプリケーションの開発メーカーにとって同じインターフェース標準に向くため、異なるメーカーからの異なるタイプの各文書ベースシステムがアプリケーションとあわせて使用できる。Ｒｅｄ Ｏｆｆｉｃｅ、ＯＣＲ、ウェブページ生成アプリケーション、楽譜編集アプリケーション、書生リーダー、Ｏｆｆｉｃｅ編集アプリケーション、その他のリーダーなどが、ＵＯＭＬインターフェースを介して文書ベースシステムに操作を指示する。文書ベースシステムが複数であってもよく、図１０に文書ベースシステム１、文書ベースシステム２及び文書ベースシステム３が示される。文書ベースシステムがＵＯＭＬからの統一標準指令によって、汎用文書モデルに適合した文書を操作し、例えば、文書を作成・保存・表示・表現する。本発明において、異なるアプリケーションは同時又は異時に同一文書ベースシステムを呼び出すことができ、同一アプリケーションは同時又は異時に異なる文書ベースシステムを呼び出すことができる。

本発明によれば、アプリケーション層とデータ処理層を分離させ、同一文書が異なるアプリケーション間で汎用され、異なるアプリケーション間に優れた文書の相互運用性があるようになった。

本発明によれば、産業は、分業になり、重複開発が減少され、更に専門、完備、正確になる。文書に対する基本操作が全て文書ベースシステムにおいて処理されるため、各アプリケーションにおいて重複に開発される必要はない。そして、文書ベースシステムが専門メーカーによって開発され、関連技術の専門性、完備性、正確性が保障され、且つアプリケーションメーカーとユーザが最適の文書ベースシステムメーカーを選択できるため、処理効果の正確性と一致性を確保できる。

本発明によれば、マルチ文書ひいては大量文書の管理メカニズムが提供され、文書同士を有効に組織できるようになり、検索・問い合わせ・保管に便利で、比較的に強い情報セキュリティメカニズムの組み込みに便利になる。

本発明によれば、優れたセキュリティメカニズムが提供され、マルチロールを設定でき、各ロールの権限を細粒度に設定できる。ここでの細粒度には意味が２つあり、文書全体又は文書の微小な所に対して権限設定を行うことができる一方、伝統的なリード・ライト・アクセス不可の３段の権限だけでなく、多種類の権限を設定できる。

本発明によれば、革新及び合理的な競争が励まされる。合理的な産業の分業になった後、Ｍｉｃｒｏｓｏｆｔ Ｗｏｒｄのような文書フォーマットによってアプリケーションを独占する状況が発生することなく、各文書ベースシステムメーカーと各アプリケーションメーカーが各自の分野で競争を展開することになる。ユーザを引くために、各文書ベースシステムメーカーが標準以外に新たな機能を追加してよい。そのため、標準が革新を縛ることにはならない。

本発明によれば、性能の最適化が便利になり、もっと優れた可搬性と拡張性が提供されている。いかなる性能を持ついかなるプラットフォームでも、同様の呼び出しインターフェースに従うことができるため、インターフェース標準を変えずに、性能を絶えず最適化でき、且つ異なるプラットフォームに移行できる。

上記は、本発明の好ましい実施形態にすぎず、本発明の保護範囲を限定するものではない。本発明の精神と原則内で行われる種々の修正、均等切替、改善などは全て本発明の保護範囲内に含まれるべきである。

本発明による文書処理システムの構成を示すブロック図である。 本発明の好ましい実施形態による汎用文書モデルの構成を示す図である。 図２の汎用文書モデルにおける文書ベースオブジェクトの構成を示す図である。 図３の文書ベースオブジェクトにおける文書ベース補助オブジェクトの構成を示す図である。 図３の文書ベースオブジェクトにおける文書セットオブジェクトの構成を示す図である。 図５の文書セットオブジェクトにおける文書オブジェクトの構成を示す図である。 図６の文書オブジェクトにおけるページオブジェクトの構成を示す図である。 図７のページオブジェクトにおける層オブジェクトの構成を示す図である。 図８の層オブジェクトにおけるレイアウトオブジェクトの構成を示す図である。 本発明に係る実施形態に定義された動作を示す図である。 本発明に係る実施形態に定義された動作を示す図である。 本発明に係る実施形態に定義された動作を示す図である。 本発明に係る実施形態に定義された動作を示す図である。 本発明に係る実施形態に定義された動作を示す図である。 本発明に係る実施形態に定義された動作を示す図である。 本発明に係る実施形態に定義された動作を示す図である。 本発明に係る実施形態に定義された動作を示す図である。 ＵＯＭＬインターフェースを例とする文書処理システムの処理を示す図である。

Claims (16)

1. 文書処理システムであって、
   少なくとも１つのアプリケーションを有するアプリケーション層と、文書ベースシステムとを含み、
   前記アプリケーションが、文書を操作するための、動作とオブジェクトとを含む標準指令を文書ベースシステムに送信し、
   前記文書ベースシステムが、記憶された文書データ内の前記オブジェクトに対して、標準指令で指示された動作を実行する、
   ことを特徴とするシステム。
2. アプリケーションが、動作とオブジェクトとを含む標準指令を送信する上インターフェースユニットを含み、
   文書ベースシステムが、前記標準指令を受信する下インターフェースユニットを含む、
   ことを特徴とする請求項１に記載のシステム。
3. 前記動作が、オープン、クローズ、取得、設定、挿入、削除、検索問い合わせの少なくとも１つを含むことを特徴とする請求項１に記載のシステム。
4. 前記オブジェクトが、文書ベースオブジェクト、文書セットオブジェクト、文書オブジェクト、ページオブジェクト、層オブジェクト、オブジェクトグループ、ステータスオブジェクト、テキストオブジェクト、画像オブジェクト、図形オブジェクト、パスオブジェクト、ソースファイルオブジェクト、スクリプトオブジェクト、プラグインオブジェクト、ストリーミングメディアオブジェクト、リンクオブジェクト、印章オブジェクト、２値化データストリームオブジェクト、ブックマークオブジェクト、コメントオブジェクト、セマンティック情報オブジェクト、メタデータオブジェクト、ロールオブジェクト、権限オブジェクト、デジタル署名オブジェクト、フォントオブジェクト、ナビゲーション情報オブジェクト、スレッド情報オブジェクト、サムネイルイメージオブジェクト、インデックス情報オブジェクト、履歴オブジェクトの少なくとも１つを含むことを特徴とする請求項１に記載のシステム。
5. 文書処理方法であって、
   アプリケーションが、文書を操作するための、動作とオブジェクトとを含む標準指令を文書ベースシステムに送信する過程と、
   文書ベースシステムが、記憶された文書データ内の前記オブジェクトに対して、標準指令で指示された動作を実行する過程と、
   を含むことを特徴とする方法。
6. 前記標準指令を送信する過程が、
   各オブジェクトと各動作をそれぞれ定義する過程と、
   アプリケーションの操作要求に対応するオブジェクトと動作を決定する過程と、
   前記オブジェクトと動作の定義に基づいて、対応の標準指令を生成する過程と、
   を含むことを特徴とする請求項５に記載の方法。
7. 前記標準指令が、動作とオブジェクトとを含む文字列であることを特徴とする請求項６に記載の方法。
8. 前記文字列が、拡張可能なマークアップ言語（ＸＭＬ）であることを特徴とする請求項７に記載の方法。
9. 前記各動作がそれぞれ１つのＸＭＬ要素に対応し、前記各オブジェクトがそれぞれ１つのＸＭＬ要素に対応し、
   前記標準指令を生成する過程が、動作に対応する第１のＸＭＬ要素を生成し、オブジェクトに対応するＸＭＬ要素を前記第１のＸＭＬ要素の子要素とする過程を含む、
   ことを特徴とする請求項８に記載の方法。
10. 前記各オブジェクトがそれぞれ、同一の基本クラスから派生した１種類の類型に対応し、前記各動作がそれぞれ１つのインターフェース関数に対応し、該インターフェース関数のパラメータが基本クラスへのポインタまたは引用を含み、
    前記標準指令を送信する過程が、操作要求に基づいてインターフェース関数を呼び出す過程を含む、
    ことを特徴とする請求項６に記載の方法。
11. 前記インターフェース関数が、Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）、Ｃ＃、ＶＢまたはＤｅｌｐｈｉの関数を含むことを特徴とする請求項１０に記載の方法。
12. 前記動作が、オープン、クローズ、取得、設定、挿入、削除、検索問い合わせの少なくとも１つを含むことを特徴とする請求項５〜１１のいずれか１項に記載の方法。
13. 前記オープン動作のパラメータが、パスを含み、
    前記クローズ動作のパラメータが、クローズ対象オブジェクトまたはクローズ対象オブジェクトのハンドルを含み、
    前記取得動作のパラメータが、用途属性と、親オブジェクトまたは親オブジェクトのハンドルとを含み、
    前記設定動作のパラメータが、設定対象オブジェクトまたは設定対象オブジェクトのハンドルと、オブジェクト記述とを含み、
    前記挿入動作のパラメータが、親オブジェクトまたは親オブジェクトのハンドルと、オブジェクト記述と、挿入位置とを含み、
    前記削除動作のパラメータが、削除対象オブジェクトまたは削除対象オブジェクトのハンドルを含み、
    前記検索問い合わせ動作のパラメータが、問い合わせ対象オブジェクトまたは問い合わせ対象オブジェクトのハンドルと、問い合わせ条件とを含む、
    ことを特徴とする請求項１２に記載の方法。
14. 前記オブジェクトが、文書ベースオブジェクト、文書セットオブジェクト、文書オブジェクト、ページオブジェクト、層オブジェクト、オブジェクトグループ、ステータスオブジェクト、テキストオブジェクト、画像オブジェクト、図形オブジェクト、パスオブジェクト、ソースファイルオブジェクト、スクリプトオブジェクト、プラグインオブジェクト、ストリーミングメディアオブジェクト、リンクオブジェクト、印章オブジェクト、２値化データストリームオブジェクト、ブックマークオブジェクト、コメントオブジェクト、セマンティック情報オブジェクト、メタデータオブジェクト、ロールオブジェクト、権限オブジェクト、デジタル署名オブジェクト、フォントオブジェクト、ナビゲーション情報オブジェクト、スレッド情報オブジェクト、サムネイルイメージオブジェクト、インデックス情報オブジェクト、履歴オブジェクトの少なくとも１つを含むことを特徴とする請求項５〜１１のいずれか１項に記載の方法。
15. 前記アプリケーションが標準指令を送信する過程が、各オブジェクトに対して各種の動作を実行するための標準指令を予め定義し、アプリケーションの操作要求に基づいて対応の標準指令を決定する過程を含むことを特徴とする請求項５に記載の方法。
16. 文書処理システムであって、
    少なくとも１つのアプリケーションを有するアプリケーション層と、文書ベースシステムと、インターフェース層とを含み、
    前記アプリケーションが、文書を操作するための、動作とオブジェクトとを含む標準指令を、インターフェース層を介して文書ベースシステムに送信し、
    前記文書ベースシステムが、インターフェース層を介して前記標準指令を受信し、記憶された文書データ内のオブジェクトに対して、標準指令で指示された動作を実行する、
    ことを特徴とするシステム。

Images