JP2001209729A - 知識統合化管理システム、文書提出プロセス制御追跡システム - Google Patents

Abstract

(57)【要約】 【課題】 企業内情報管理において各種の独立したソフ
トウェアアプリケーションの運用を統合する。 【解決手段】 クライアントとサーバ間、およびサーバ
同士の間でデータを転送するためのエンジン２１と、す
べての監査証跡情報を統合するデータベース２２と、検
証計画の作成／維持、データ解析データベースとそれに
対応する文書リポジトリの設定、またプロセスの進捗と
監査証跡情報を可視化するためのクライアントコンポー
ネントを保有するＫｎｏｗｌｅｄｇｅＰａｔｈクライア
ント３７とを有し、統合化された情報管理アプリケーシ
ョンの内外およびアプリケーション同士の情報の流れを
容易に監視できるようにすることにより、知識情報を吸
収し、そのような情報の制御を容易にする。また、知識
情報を用いて企業内の知識をより効率的に利用できるよ
うにする付加的なツールも含まれていて、そのような知
識のコンテキスト（前後関係）を整理したり知識の可視
化を実現する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は一般にデータ、情
報、および知識を統合化するアーキテクチャに関し、特
に異なる種類のソフトウェアシステムに同期的に含まれ
るデータ、情報、知識に簡単にアクセスして操作し、ま
た可視化することを可能にする目的で知識リポジトリを
管理かつ利用する方法および装置に関する。

【０００２】

【従来の技術】規制対象業種（例えば、航空宇宙、エネ
ルギー、ヘルスケア、製造業、製薬、電気通信、公益事
業）で事業展開する企業は、数年にわたりしばしば発生
する膨大な量の情報を管理し、校閲(review)するよう求
められている。この情報の主要な要素として、構造化さ
れた数値データと構造化されていないテキスト文書があ
る。収集されたデータは、複雑な統計解析が施され、次
いで義務付けられた審査（review）における厳しい基準
に合格すべく業界の専門家により解釈および報告され
る。別々のグループや組織がこの種のデータを何度も繰
り返し生み出して、何千もの統計データ解析ファイルが
何千もの関連文書に関係付けられている可能性がある。
このようなグループはしばしば独自に、専門的だが時に
一貫性を欠く手順や職務慣行を発展させてきた。その結
果、データ解析と文書管理のために別々のソフトウェア
システムが別々のソリューションとして利用されてき
た。情報源と作業グループが共に分かれていることは共
通の目標を危うくする。従って、ここでの課題は、企業
内で意思決定をより良く、より速く行なうのに必要なあ
らゆる情報の流れ、プロセス、および職務慣行を統合化
して同期させることである。

【０００３】現在、データとデータ解析レポートを提出
が義務付けられた文書と統合するプロセスは、（ａ）完
全な手作業による処理（すなわち、紙をコピーしてハー
ドコピーの冊子に加える）、（ｂ）多段階の電子的処理
（すなわち、ある部門がファイルを集中ファイル保管場
所に置き、別の部門が検索する）、あるいは（ｃ）処理
の一部を自動化するために利用される、社内開発された
カスタムソリューションに分類できる。このようなプロ
セスにおける問題は典型的に以下のものを含む。 ・プロセスの管理に必要なシステムが複雑で間違いを生
じやすい（例えば、関連文書やデータの手作業による更
新。これらのオブジェクト同士を互いに“記憶に頼る”
関連付けで維持（すなわち、メタ情報カタログ）するこ
とを求め、ビジネスプロセスを通じて定義されたオブジ
ェクトの“関連付け”の整合性を強制する）。 ・情報発生のライフサイクルを通じて、相互に関連付け
られた文書やデータを探し出して仕事に利用することが
困難である（統合化されたテキストおよび数値情報が欠
如しているために企業情報ワークフローおよび意思決定
が著しく制約される）。 ・現行の文書管理およびデータ解析システムにおいて、
別々のシステムに保持されている多くの異なる種類の情
報を探し出して仕事に利用するための効率的なメカニズ
ムが欠如している。 ・情報発生のライフサイクルを通じて、データと文書の
間の依存関係を識別し、評価し、実現することができな
い。複雑な情報ワークスペーストポロジーが存在する
が、これらの関連する情報オブジェクトの参照整合性を
維持する立場にあるユーザだけが元来このことを知って
いる。 ・情報発生のライフサイクルを通じて、データ変更が一
連の文書変更を引き起こし、次いで他の文書にも修正が
必要になるという状態を扱うプロセスに柔軟性が欠けて
いる。

【０００４】一方、本発明は複数のソフトウェア・プラ
ットフォームに完全な形で、かつ同期的に含まれる情報
へ簡単にアクセスして操作し、可視化することを目的に
して知識リポジトリを含むアーキテクチャを用いて上述
の問題を解決するものである。

【０００５】以下の説明は本発明の実施の形態を製薬業
界における認可プロセスを例にして特徴づける。ただ
し、この説明により本発明の範囲は何ら制限されるもの
ではない。むしろ製薬業界の実施の形態により、義務付
けられた審査プロセスにおける本発明の利点の理解し易
くする実施例を与えようと意図されている。

【０００６】さらに本発明の特徴を述べるために、大規
模で国際的な診療研究を始めた製薬研究の企業を検討し
よう。（新しい化学的対象を求めて）研究の方向性を規
定する研究プロトコルは臨床研究者（医学博士）により
書かれた。４年の歳月と数百万ドルを費やした後、統計
解析の結果、義務付けられた申請認可の主張は支持され
なかった。皮肉なことに、その薬が安全で効能があるこ
とは知られていた。失敗の原因はまさにプロトコル設計
の欠陥であった。これは組織の重大な金銭的損失を表す
が、これは適切な知識ベースとツールがあれば避けられ
たかもしれない。少なくとも、今後は回避すべきもので
ある。

【０００７】提示されたシナリオ、および多くの規制対
象である業種団体において、以下のグループ１〜５すべ
てにおいて専門家チームが、当時適切な選択であると思
われていた項目を考案した。 −＞専門家グループ１−プロトコル設計 −＞専門家グループ２−ケースレポートの書式設計 −＞専門家グループ３−データベース設計 −＞専門家グループ４−統計解析 −＞専門家グループ５−臨床試験。

【０００８】これらのチームには、同じグループのメン
バーや他のグループのメンバーが行なった、互いに依存
し合う意思決定の連鎖を可視化して理解を助ける“ツー
ル”がなかった。無論これらの意思決定の背後にある理
由付けは言うまでもない。規制対象のプロセスではよく
あることだが、統計解析が行われたとき、元のチームは
既に以前のままではなかったばかりか、その企業にチー
ムの代表者さえ残っていなかった。最終提出の準備して
いる段階で過ち、すなわち解析がうまく行かなかった理
由（例：正しいデータポイントの収集が抜けていた）が
露見するかも知れないが、プロジェクトは終了してお
り、関係者は経験したことを深く考えたがらないため、
過ちが専門家グループ全体には伝達されない。

【０００９】本発明の利点のいくつかは“コンテキスト
（前後関係）”を保存し、過去、現在、および将来起こ
り得るな意思決定を可視化して探索することができ、個
人と企業の学習のインフラストラクチャ構築し、今日ま
でほとんど構造化されておらず記録もされていないプロ
セス、実践、応用およびそれらの間の相互作用を構造化
する点である。上述のシナリオから得た教訓は、この種
の問題を解くシステムの実装を追求する価値が少なくと
も３レベルあることを示唆する。

【００１０】１．（重複等を）完全に回避できる能力。
適切なツールがあったならば、元のチームは各種の情報
源、意思決定ポイント等の依存関係を含めて自分達が計
画していた仕事の構造を“見る”すなわち可視化する機
会があったであろう。

【００１１】２．（問題を）早期に認識できる能力。最
低でも、早い段階で自分達が行なった選択同士を関係付
けることができたならば、少なくともチームとして早期
に問題を認識して、それらを修正する選択肢を持てた可
能性がある。

【００１２】３．過去（の経験）から学ぶ能力。最悪の
場合、企業は投資した資金を失うものの、少なくとも犯
してはならない失敗例として文書化しておくことはでき
よう。これは長い目で見れば、将来多数のプロジェクト
の時間と金を節約することになろう。次に設計されるプ
ロトコルは、同じ、あるいは似た問題を抱えることは避
られそうである。それは、経験に基づいて作り上げてい
るからである。

【００１３】

【発明が解決しようとする課題】上記のシナリオで述べ
たように、規制対象業界で事業展開する企業は、膨大な
量の情報を管理かつ校閲するよう求められており、その
情報は数年にわたり頻繁に発生、解析される。この情報
の主要な要素として、構造化された数値データと構造化
されていないテキスト文書がある。データは収集されて
複雑な統計解析がなされ、その結果は申請と認可を義務
付けた政府の厳格な要求に応えるために業界専門家によ
り解釈されて解析データとして報告される。典型的な組
織において、いくつかの別々のグループがこの種のデー
タを何度も繰り返し生み出して、何千もの統計データ解
析ファイルが何千もの関連文書に紐付けられている可能
性がある。これらのグループはしばしば独自に、専門的
だが時に一貫性を欠く手順や職務慣行を発展させてき
た。その結果、データ解析と文書管理のために別々のソ
フトウェアシステムが別々のソリュージョンとして利用
されてきた。情報源と作業グループが共に分かれている
ことは義務づけられた認可の取得という共通の目標を危
うくする。

【００１４】

【課題を解決するための手段】企業において意思決定を
より良く、より速く行なうのに必要なあらゆる情報、プ
ロセス、および職務慣行の統合化と同期化を促進するた
めに、本発明の態様を共通のアーキテクチャで実施して
いる。単純化して表わせば、企業の知識は図１に示すよ
うな文書ライフサイクル図で表現できる。例えば、企業
文書管理システム（ＥＤＭＳ）１０、画像管理システム
１２および企業ワークフローシステム１４は、現在スタ
ンドアローン型システムとして利用可能な知識管理シス
テムの部分を構成する。例えば、Ｄｏｃｕｍｅｎｔｕｍ
（登録商標）とＰＣ Ｄｏｃｓ（登録商標）は文書管理
システムを提供し、ＦｉｌｅＮｅｔ（登録商標）は画像
管理と企業ワークフローソリューションを、そしてＩｎ
Ｃｏｎｃｅｒｔ（登録商標）はワークフロー管理ソフト
ウェアを提供する。本発明の一つの好適な実施の形態に
おいて、企業が利用するシステムは全社規模のシステム
の部分１０、１２と１４を統合できるようにするだけで
はなく、さらに知識統合化手段１６により表現される機
能をも含む。

【００１５】ＦｉｌｅＮｅｔの“企業文書管理戦略白書
に関する趣意書(foundation)”（１９９７年９月）にお
いて、ユーザ主導による主要産業の動向を示唆してい
る。それは、ワークフロー、文書の画像化、電子文書管
理、およびレーザーディスク（登録商標）へのコンピュ
ータ出力が普通のデスクトップＰＣ環境で動作する製品
ファミリに収斂しつつあるという点である。ＦｉｌｅＮ
ｅｔの趣意書は、企業がすべての文書とそれらを利用す
るビジネスプロセスにアクセスして管理する全社規模の
環境を容易に構築することができる基礎である。Ｆｉｌ
ｅＮｅｔのアーキテクチャモデルはクライアント／サー
バ計算パラダイムに基づいている。４種類の一般的なク
ライアントアプリケーションが述べられていて、４個の
主要な要素は以下のものである。 検索−業界標準のデータベースにアクセスして結果を使
いやすく読みやすいフォーマットで表示することによ
り、全社に散らばる文書に“索引付け”を行なう情報を
生み出して呼び出せる機能。 閲覧−あらゆる種類の文書を閲覧して最も適切なしかた
で仕事に利用できる機能であり、閲覧、再生（ビデオや
音声）、変更／編集、注釈付け、ズーミング、パンニン
グ、スクローリング、ハイライティング等がある。 開発ツール−顧客、または選ばれたアプリケーション開
発やインテグレーションパートナーが、組織内で既存の
他アプリケーションとのインターフェースを有する特定
のアプリケーションを開発することができる業界標準の
開発ツールセット（例：Ａｃｔｉｖｅ Ｘ、Ｐｏｗｅｒ
Ｂｕｉｉｄｅｒ）。管理アプリケーション−ユーザ、開
発者あるいはシステム管理者が、タスクの最適化、ビジ
ネスプロセスの完了、あるいは文書特性や機能について
のデータを受け取ることができるような経営および管理
情報の送達アプリケーション。

【００１６】規制対象業種（例：製薬等）の例における
主要な課題は、一般に、いかにしてすべての情報をコン
テキスト（前後関係）を損なうことなくできるだけ速
く、同期させて、義務付けられた申請事例の妥当性を証
明するかである、と考えられる。すべての情報の流れを
自動化および同期化することが審査作業の促進に役立
つ。しかし、より大きな課題は、知識を応用するのに必
要なコンテキストを維持することである。文書とデータ
に一貫性があるか、データと文書の繰り返しは同期して
いるか、データの完全性を維持するために何がなされた
か、誰が何の資格でその作業をしたのか、などの質問に
答えるために、ユーザが自分の知識を仕事に生かすこと
ができるシステムが求められている。これらの質問に的
確に答えられなければ、集めたデータおよびその妥当性
の主張に対する審査者／監督官庁の信頼感が揺らぐ恐れ
があるが、現行システムでは未だに情報は死蔵されてい
たり、失われたり、あるいは記録すらされない状況にあ
る。本発明は、義務付けられた認可の要件を満たすのに
用いられた“経路”を識別、確認、統合して他者が辿れ
るようにするためのシステム、アーキテクチャ、および
関連付けられたプロセスを対象としている。

【００１７】本発明に係る知識統合化管理システムは、
文書に関連付けられた知識に関するコンテキストをアー
カイブ可能とし、過去、現在、および将来起こり得る意
思決定、インフラストラクチャの整備、構造化プロセス
および実施へのアクセスおよび評価を行なう機能を提供
する知識統合化モジュールと、異なる文書およびデータ
ソース間でアプリケーションの相互運用(interoperabil
ity)と同期化を実現するアプリケーション統合化モジュ
ールと、前記知識統合化モジュールと前記アプリケーシ
ョン統合化モジュールの間で構造化および非構造化デー
タ、情報、知識の橋渡しを行なう知識統合化ミドルウェ
アとを含むことを特徴とする。

【００１８】本発明によれば、異なる文書およびデータ
ソース間でアプリケーションの相互運用と同期化を実現
する知識統合化管理システムを提供する。本システム
は、少なくとも１個のデータベースに保存されているデ
ータを用いて独立してデータ解析処理を行なってデータ
および解析結果を生成するのに適したデータソースモジ
ュールと、知識を獲得して文書形式で保存し、その知識
の正確さを検証し、獲得した知識をネットワーク経由で
利用可能にする、文書データベースメモリを含む文書ソ
ースモジュールと、データソースモジュールおよび文書
ソースモジュール間の情報の流れを管理するためにデー
タソースモジュールおよび文書ソースモジュールにアク
セスできるクライアント／サーバシステムの一部として
の知識統合化モジュールとを含み、これによりデータお
よび解析結果と文書との統合化を可能にし、さらにデー
タまたは解析結果が変更された場合に文書を自動的に更
新するようにデータおよび解析結果と文書との間に関連
付けを与える。

【００１９】本発明のさらに別の態様によれば、異なる
文書およびデータソース間でアプリケーションの相互運
用と同期化を実現する方法を提供する。本方法は、少な
くとも１個のデータベースにアクセスするステップと、
少なくとも１個のデータベースに保存されたデータを用
いてデータおよび解析結果を生成するデータ解析処理を
行なうステップと、文書データベースに文書形式で独立
して知識を保存するとともに獲得した知識の正確さを検
証してネットワーク経由で利用可能にするステップと、
データおよび解析結果と文書の統合化可能にし、データ
または解析結果が変更された場合に自動的に文書を更新
するように少なくとも１個のデータベースと文書データ
ベースの間の情報の流れを管理するステップとを含む。

【００２０】本発明のさらに別の態様によれば、知識統
合化システムを提供する。本システムは、異なる文書お
よびデータソース間でアプリケーションの相互運用と同
期化を実現するアプリケーション統合化モジュールと、
知識関連コンテキストをアーカイブ可能とし、過去、現
在、および将来起こり得る意思決定、インフラストラク
チャの整備、構造化プロセスおよび実施へのアクセスお
よび評価を行なう機能を提供する知識統合化モジュール
とを含む。

【００２１】本発明のさらに別の態様によれば、異なる
文書およびデータソース間でアプリケーションの相互運
用と同期化を実現する知識統合化システムを提供する。
本システムは、統合化知識リポジトリを構築して管理す
るために従来のアプリケーション統合化ミドルウェアと
合わせて知識統合化ミドルウェアを用いるべくプログラ
ムされたコンピュータと、情報に一様にアクセスするこ
とで構造化および非構造化データの橋渡しを行なう手段
と、企業内の知識作業者が生み出した、構造化または非
構造化データ、業務遂行上のデータおよびメタデータの
知識を関連付け、可視化して利用することにより全体と
して情報の統合化を可能にする統合化知識ベース・ソフ
トウェア・アプリケーションと、統合化トランザクショ
ンの記録、ユーザやアプリケーションからのコンテキス
ト情報、情報メタデータのカタログ、知識のアクセス制
御、アプリケーション起動ルール、知識統合化のメタデ
ータとルール、知識の生成、知識の可視化、”生きた”
知識のリンク、タスク実行、および義務付けられた審査
用のケース別データを含む知識リポジトリとを含む。

【００２２】本発明のさらに別の態様によれば、現在は
企業内の別個の文書管理およびデータ解析システムで管
理されている、異なる文書およびデータソース間でアプ
リケーションの相互運用と同期化を実現する方法を提供
する。本方法は、企業の文書管理システム、統計データ
ベースおよびアプリケーションの間で”生きた”リンク
を確立して利用するステップと、文書内の任意の場所か
ら１個以上のアプリケーションにより実行されてテキス
トおよび数値解析情報が体系的に同期化される複数のタ
スクをユーザが定義して起動できるようにするステップ
と、文書を作成し、データと文書間の情報の流れを同期
化し、データ解析ソフトウェアに戻るリンクを提供する
ためにデータ解析レポートを文書管理システムへ転送す
るプロセスを自動化するステップとを含む。

【００２３】本発明のさらに別の態様によれば、知識管
理および統合化システムを提供する。本システムは、文
書に関係付けられた知識に関するコンテキスト（前後関
係）をアーカイブ可能とし、過去、現在、および将来起
こり得る意思決定、インフラストラクチャの整備、構造
化プロセスおよび実施へのアクセスおよび評価を行なう
機能を提供する知識統合化モジュールと、異なる文書お
よびデータソース間でアプリケーションの相互運用と同
期化を実現するアプリケーション統合化モジュールと、
前記知識統合化モジュールと前記アプリケーション統合
化モジュールの間で構造化および非構造化データ、情
報、知識の橋渡しを行なう知識統合化ミドルウェアを含
む。

【００２４】また、本発明に係る文書提出プロセス制御
追跡システムは、文書の作成から最終審査までの全体の
制御及び追跡をし、既存のデータ解析ツール、オーサリ
ングツール、および文書管理システムと統合化される文
書提出プロセス制御および追跡システムであって、デー
タベースと、前記データベースにおけるすべてのプロセ
ス監査証跡情報(process audit trail information)を
取り込む手段と、前記監査証跡情報と前記プロセスを可
視化する手段と、全体の検証計画(proof plan)の定義と
維持を可能にする手段と、前記最終検証計画からの提出
文書の構築を自動化する手段とを含むことを特徴する。

【００２５】また、本発明に係る知識統合化管理システ
ムは、文書オーサリングモジュールと文書解析モジュー
ル間のデータ転送を仲介する文書リポジトリと、統計デ
ータ解析およびデータ解析の結果を前記文書リポジトリ
に送るデータ解析モジュールと、文書のオーサリング、
保存、検索用の要素およびデータ解析結果を前記文書リ
ポジトリに書き込む文書オーサリングモジュールと、検
証計画を作成して維持し、データ解析データベースと前
記文書リポジトリの設定を行ない、プロセスの進捗と監
査証跡情報を可視化するクライアント要素を含むプロセ
ス管理モジュールとを含むことを特徴とする。

【００２６】本発明が提示するアーキテクチャの目的
は、例えばソフトウェア製品群(suite)で実現されてお
り、知識統合化ミドルウェア（ＫＩＭＷ）を介して知識
リポジトリを管理して利用し、異なるソフトウェアシス
テムに含まれる完全で同期化されている情報を簡単にア
クセス、操作および可視化できるようにすることであ
る。本発明の態様には以下のものが含まれる。 ・従来のアプリケーション統合化ミドルウェアと合わせ
て知識統合化ミドルウェアを利用した統合化知識リポジ
トリの構築。 ・情報に一様にアクセスすることで構造化および非構造
化データの橋渡しを行う一般的なメカニズムの提供。 ・企業内の知識作業者が生み出した、構造化または非構
造化データ、業務遂行上のデータおよびメタデータの知
識を関連付けて、可視化して利用することにより全体と
して情報の統合化を可能にする４種類の統合化知識ベー
ス・ソフトウェアアプリケーション（後述）の指定。 ・統合化トランザクションの記録、ユーザやアプリケー
ションからのコンテキスト情報、情報メタデータのカタ
ログ、知識のアクセス制御、アプリケーション起動ルー
ル、知識統合化のメタデータとルール、知識の生成、知
識の可視化、”生きた”知識のリンク、タスク実行、お
よび義務付けられた審査用のケース別データを含む知識
リポジトリの使用。 ・企業情報が保存および管理されている任意の場所への
アクセスを許すユーザ固有の概念スキーマと合わせた３
次元インターフェースの使用。 ・マーケティング申請を監督官庁へ提出するための、仮
説／検証／主張という構造をとるルールベースのパラダ
イムの実装。

【００２７】本発明は、現在は企業内の別個の文書管理
およびデータ解析システムで管理されているような、異
なる文書およびデータソース間でアプリケーションの相
互運用と同期化を提供する。始めに、本発明はユーザが
企業の文書管理システムと統計データベースの間で”生
きた”リンクを確立して利用できるようにする。本発明
の代替または改善された実施の形態により、文書内の任
意の場所から１個以上のアプリケーションにより実行さ
れる複数のタスクをユーザが定義して起動できるように
なる。

【００２８】知識管理システムのユーザは、統合化文書
管理、画像管理、ワークフロー管理および情報検索を提
供する、統合化されていて柔軟なプロセスを求めてい
る。本発明の態様は、上記ユーザの大多数は自分のデー
タを、テキストおよび数値の解析情報が体系的に同期化
されている場所と同じく文書ライフサイクルプラットホ
ームへの統合化を望んでいるという見方に注目する。そ
のようなシステムは意思決定者が完全な情報を把握でき
るようにする。

【００２９】本発明の一態様は、企業文書管理システム
（ＥＤＭＳ）に保存されている文書に記載されているデ
ータから企業内における知識の流れが把握できる、とい
う発見に基づいている。この発見は、文書がＥＤＭＳに
保存される前あるいはその時点で情報の流れが厳密に特
徴付けられている必要があるという、従来の文書あるい
は知識管理システムで生じる問題を回避する。

【００３０】本発明の別の態様は、データ解析レポート
を義務付けられた文書作成のために文書管理システムに
転送するプロセスを自動化し、データと文書の間に情報
の流れを同期させ、データ解析ソフトウェアに戻るリン
クを提供することができる技術の発見に基づいている。
本発明のさらに別の態様は、文書と関連付けられた解析
データに保存されている”生きた”知識リンクを埋め込
んで実行し、それによりユーザは情報コンテンツ内で１
個以上のデータあるいは文書アプリケーションにより実
行される多数のタスクを定義して起動することができ
る。本発明の別の態様は、統合化知識ベースに保持され
ているオブジェクトやリンクを可視化し、好適には３次
元インタフェースと概念スキーマを用いて企業情報にア
クセスして操作する。本発明の最後の態様は、義務付け
られたマーケティング申請処理を管理するために利用さ
れている知識文書を作成する。

【００３１】ここで述べる技術の利点は、柔軟で、あら
ゆる知識統合化ニーズに適合できる点である。ここでは
監督官庁向けの提出物準備に関して記述しているが、知
識として獲得した情報を理解して利用しようと努めてい
るあらゆる企業も基本的に本発明を利用することができ
る。本発明の技術の利点は、知識リポジトリの効率的な
構築と利用ができる点である。いくつかの技術は構造化
および非構造化データの橋渡しを行なうために利用する
ことができる。その他の技術は、企業内の知識作業者が
生み出した、構造化または非構造化データ、業務遂行上
のデータおよびメタデータの知識を関連付け、可視化し
て利用することによる情報の統合化を提供する。本発明
の結果、ここで述べる本方法と装置のユーザは、企業内
で誰が、なぜ、いつ、どこで、どのように情報と文書を
利用したかを正確に把握することが可能になる。

【００３２】

【発明の実施の形態】以下、図面に基づいて、本発明の
好適な実施の形態について説明する。

【００３３】１．定義 組織あるいは企業における知識とは、組織により採用さ
れている個人およびシステムの全体としての学習を反映
したものである。ここで“知識”という用語は、デジタ
ルな電子フォーマットで反映、記録、あるいは特徴付け
られている組織的なノウハウの一部を反映する。“知識
リポジトリ”とは、企業のいかなる部署であってもその
知識の受け入れまたは記録に適した任意の物理的または
仮想的、集中型または分散型システムである。

【００３４】ここで“知識統合化ミドルウェア”という
用語は、知識、知識アプリケーション、または知識サー
ビスを記録、配布、および起動する目的で、別々の情報
源およびそれに対応するアプリケーションの統合化支援
に用いられるあらゆるソフトウェアを表わす。より具体
的には、知識統合化ミドルウェアは好適にはコンテキス
ト（前後関係）の認識（追跡、監視、解析を含む）のた
めに利用されていて、コンテキストを知識管理に使える
ようにするためにコンテキスト内の情報が利用されてい
る。

【００３５】“文書管理”は、管理することによってユ
ーザに管理情報を提供し、ユーザがタスクを最適化した
り、業務処理を遂行したり、文書特性や機能に関するデ
ータを受け取れるようにするプロセスとそのようなプロ
セスが動作する装置を指す。“統合化文書管理”という
語句は、それぞれが１個以上の特定の動作を行なうべく
最適化された多数の独立したソフトウェア・アプリケー
ションを用いて文書管理を実行できるプロセスまたはシ
ステム、および情報が一つのアプリケーションから流れ
て、１個以上の他の文書管理プロセスに組み込まれる
か、その中でアクションを引き起こすプロセスを指す。
“企業文書管理システム”は、企業内で利用されている
文書の、すべてでないにせよ、重要な部分を取り込んで
管理するように実装された文書管理システムである。

【００３６】“画像管理”は、特に画像文書をそのライ
フサイクルを通じて管理する技術である。画像管理シス
テムは通常、先端的な画像処理およびパターン認識技術
の組合わせを利用して洗練された情報検索と画像固有の
解析機能を提供する。

【００３７】“ワークフロー管理”は、ビジネスプロセ
スを管理して自動化する技術である。ワークフローは最
終成果物を生み出すために用いられる、組織内の規定さ
れた一連の作業を記述するために用いられる。

【００３８】“情報検索”は、各種の情報源から情報を
探して、検索する技術である。この用語は一般に、基本
的にテキスト型である情報を体系化して、維持し、かつ
アクセスするアルゴリズム、ソフトウェア、およびハー
ドウェアを指す。

【００３９】“監督官庁(regulatory agency)”とは、
特定の業種、マーケット、製品あるいはサービスに対し
て義務付けられた監督や認可を行なうあらゆる組織や団
体である。監督官庁による審査を受ける必要がある業種
の例として、航空宇宙、エネルギー、ヘルスケア、製造
業、製薬業、電気通信、および公益事業等がある。

【００４０】“データ”は、情報の個々の断片を指し、
“解析的データ”は、データの統計解析を通じて生み出
された数値情報を指す。“メタデータ”は、データに関
するデータを指す。ここでのメタデータは、特定のデー
タの組を誰が、いつ、どのように集めたか、またそのデ
ータがどのようなフォーマットであるかを特徴付ける。
“情報”は、解析、処理、あるいは編集されて有意味な
パターンに変換されたデータを意味し、一方”知識”
は、実用に耐え得る、または活用できるように編集され
た情報を意味する。

【００４１】データ解析と文書管理システムにおけるオ
ブジェクト間に“生きたリンクを確立する”のような語
句で用いられる”生きた(Live)”は、そのようなオブジ
ェクトを管理している異種アプリケーション間でスムー
ズな制御と機能を実現することを意味する。

【００４２】２．概要 本発明はこの開示をとおして、“知識経路(KnowledgePa
th)”と呼ばれる。本発明の一適用例において、“提出
プロセスの制御および追跡システム”全体を示す。これ
は政府から製品発売の認可を勝ち取るために、規制業種
が提出プロセス全体の制御と追跡を行なうのを支援する
ものである。ＫｎｏｗｌｅｄｇｅＰａｔｈ（登録商標）
ソフトウェアは既存のデータ解析ツール、オーサリング
ツールおよび文書管理システムと統合化できる。Ｋｎｏ
ｗｌｅｄｇｅＰａｔｈのシステム概念は製薬業界の枠を
越えて、大規模なデータ解析に基づく複雑な文書を提出
することが必要なあらゆる規制対象業種に適用できる。
このような業種として、ヘルスケア、エネルギー、金融
サービス、製造業と電気通信業等がある。

【００４３】３．システム全体の実装 規制対象業種のある企業が新製品を発表したり、あるい
は料金表(rate schedule)を改定したい場合、その企業
は膨大かつ複雑な文書と関連する参照データの組を行政
機関に提出して認可を得なくてはならない。この文書
は、大規模なデータ収集と解析に基づいて、当製品が適
用される規制に適合していると検証された旨を提示する
ものである。官庁はその文書と関連データを用いて、検
証結果を支持する証拠を審査し、証拠収集のいかなる段
階でも異議を唱えるかもしれない。

【００４４】文書提出につながる隅々までのプロセスは
往々にして非常に複雑である。すなわち、 ・証過程を構成、文書化する計画を立てる必要がある。 ・データを集めて解析を行なう過程で、計画に対する全
体的な進捗を把握しておく必要がある。 ・この進捗に基づいて、計画の調整が必要な場合があ
る。 ・計画の遂行を慎重に追跡する必要があり、活動の監査
証跡を保存する必要がある。 ・提出文書は、検証結果と支持監査証跡(the supportin
g audit trail)の両方を提示すべく編成される必要があ
る。

【００４５】今日、提出プロセスで用いられる主要なツ
ールとして、統計データ解析ソフトウェア（例：ＳＡＳ
（登録商標）パッケージ）、オーサリングツール（例：
ＭｉｃｒｏｓｏｆｔＷｏｒｄ（登録商標））および文書
管理システム（例：Ｄｏｃｕｍｅｎｔｕｍ（登録商
標））等がある。データ解析ソフトウェアは、データの
収集、構造化、解析、およびプレゼンテーション、結果
の要約、さらに解析段階と依存関係の監査証跡の取り込
みを支援する。文書管理システムは作成された文書の断
片、編成された文書としての構造化、さらに文書バージ
ョン、構成および発表条件の監査証跡を保存する。

【００４６】データ解析ソフトウェアと文書管理システ
ムは、提出プロセスの細部の管理には非常に役立つもの
の、提出プロセス全体として隅々までの制御と追跡を行
なうには非常に不十分である。特にこれらのツールだけ
は不十分である理由は以下の点に対応していないからで
ある。 ・データ解析ソフトウェアのデータ解析結果と文書管理
ソフトウェアの文書コンポーネントとの間の監査証跡依
存関係の取り込みと維持。 ・データ解析進捗と文書編成進捗にまたがる隅々までの
プロセス進捗の統合化。 ・プロセスの全体進捗の可視化／理解の簡便化。 ・検証計画に合わせた、提出文書の編成、作成の管理の
支援。

【００４７】ＫｎｏｗｌｅｄｇｅＰａｔｈは、包括的な
“提出プロセス制御および追跡システム”であり、提出
プロセスの隅々までの制御と追跡を行ない、既存のデー
タ解析ツール、オーサリングツール、および文書管理シ
ステムと統合化できる。ＫｎｏｗｌｅｄｇｅＰａｔｈの
付加価値は以下の点である。 ・１個のデータベースですべてのプロセス監査証跡情報
を取り込む。 ・監査証跡情報、および全体的なプロセスの進捗の可視
化ツールを提供する。 ・全体的な検証計画の定義と維持を可能にする。 ・最終の検証計画から得られる提出文書の編成を完全に
自動化する。

【００４８】４．システムアーキテクチャ 本発明によるシステムアーキテクチャの実施の形態を描
くブロック図を図２、３に示す。ＫｎｏｗｌｅｄｇｅＰ
ａｔｈのユーザ指向の技術アーキテクチャを図２に示
す。本アーキテクチャは以下の５個のソフトウェアカテ
ゴリのコンポーネントを統合したものである。 データ解析クライアント／サーバ（クライアント３１／
サーバ３２）、 文書管理クライアント／サーバ（クライアント３３／サ
ーバ３４）、 文書オーサリングクライアント３５、 アプリケーション間ミドルウェア３６、 ＫｎｏｗｌｅｄｇｅＰａｔｈクライアント／サーバ（ク
ライアント３７／サーバ３８）

【００４９】これらのコンポーネントが統合化されて、
データアナリスト２６、文書作成者２８、およびプロセ
ス管理者２９の３種類のユーザを支援する。

【００５０】データアナリスト２６は統計データ解析
（クライアント３１）用に、また文書リポジトリ２３を
横断してデータ解析結果（インタフェース２５を用い
て）を送るためにクライアントコンポーネントを保有す
る。後者のコンポーネントは、データ解析側２６と文書
管理側２８の間のデータ転送を仲介できるようにＫｎｏ
ｗｌｅｄｇｅＰａｔｈから提供される。

【００５１】文書作成者２８は、オーサリング（クライ
アント３５）、文書の保存と検索（クライアント３
３）、また文書リポジトリ２３を横断してデータ解析結
果（インタフェース２７を用いて）を送るためのクライ
アントコンポーネントを保有する。後者のコンポーネン
トは、これらのデータ転送を仲介できるようにＫｎｏｗ
ｌｅｄｇｅＰａｔｈから提供される。

【００５２】プロセス管理者２９は、検証計画の作成／
維持、データ解析データベースとそれに対応する文書リ
ポジトリの設定、またプロセスの進捗と監査証跡情報を
可視化するためのクライアントコンポーネントを保有す
る。

【００５３】クライアントコンポーネントは３種類のユ
ーザのそれぞれにスムーズなユーザインタフェースを提
供するために、ＡｃｔｉｖｅＸ、あるいはＷｅｂＢｒｏ
ｗｓｅｒ技術を介して統合化することができる。

【００５４】ＫｎｏｗｌｅｄｇｅＰａｔｈサーバには以
下のコンポーネントが含まれる。まず、クライアントと
サーバ間、およびサーバ同士の間でデータを転送するた
めのエンジン２１である。このエンジンは、新規提出プ
ロセスに対しても簡単に再構成できるようなルールに基
づいている。データ転送はデータ解析結果（クライアン
ト−サーバ）および監査証跡データ（サーバサーバ）の
両方を含む。データ転送自体もそれぞれ監査痕跡の新規
アイテムとして記録される。

【００５５】次に、データが元々 Ｋｎｏｗｌｅｄｇｅ
Ｐａｔｈ（データ解析から文書リポジトリ転送まで）、
データ解析サーバ（データ、解析結果の依存性）、また
は文書管理サーバ（文書コンポーネントの依存性）のい
ずれから取り込まれたかにかかわらず、すべての監査証
跡情報を（論理的に）統合するためのデータベース２２
である。このデータベースは、各データ解析あるいは文
書コンポーネントに誰が、いつ、なぜ、何をしたかを取
り込む。このデータベースは、”証拠”の連鎖を理解す
るのに必要な、また計画に対する提出プロセスの進捗を
把握するのに必要な情報を提供する。

【００５６】データ解析側２６と文書管理側２８の間で
クライアントが起動したすべてのデータ解析の転送は、
必要な監査証跡情報が記録できるように仲介役としてＫ
ｎｏｗｌｅｄｇｅＰａｔｈを用いる。さらに、データ解
析および文書管理サーバ上のすべての監査証跡情報は、
転送エンジンルールベースに取り込まれたルールに従っ
て、 ＫｎｏｗｌｅｄｇｅＰａｔｈサーバ上に論理的に
複製される。サーバにより起動された３個のサーバ間で
のすべてのデータおよびイベントの転送はアプリケーシ
ョン間のミドルウェアを介して生じる。これによりＫｎ
ｏｗｌｅｄｇｅＰａｔｈは、すべて利用可能な監査証跡
情報を、それが元々どこで取り込まれたかにかかわら
ず、保有することができる。

【００５７】クライアントが起動したデータ解析転送
は、データ解析結果を文書リポジトリの中へ物理的にコ
ピーするか、あるいはデータ解析データベースに生きた
リンクを返してもよい。ＫｎｏｗｌｅｄｇｅＰａｔｈは
要求されたときに生きたリンクを解決し、任意の関連付
けられた監査証跡情報を記録する。文書作成者２８がリ
ポジトリ２３に保存された（合成）文書内で生きたリン
クを開くと、ＫｎｏｗｌｅｄｇｅＰａｔｈはデータ解析
データベースインタフェース２７を用いてデータ解析デ
ータベース２４から適切なデータ解析結果を検索し、そ
れをユーザのクライアントにある文書ビューワ(viewer)
の中で開く。

【００５８】複雑な提出プロセスには、いくつかの異な
る企業から得た文書が含まれているかもしれず、分散提
出プロセス環境におけるデータ解析および文書管理の両
ソフトウェアの多数のベンダから提供された多数のイン
スタンスが存在するかもしれない。Ｋｎｏｗｌｅｄｇｅ
Ｐａｔｈは究極的には分散した異種混合環境で動作する
必要がある。

【００５９】ＤａｔａＤｏｃｋｅｔを実装する実施の形
態のためのユーザ指向の技術アーキテクチャを図３に示
す。本アーキテクチャは、データ解析アプリケーション
にＳＡＳ／ＰＨ−Ｃｌｉｎｉｃａｌ、文書管理クライア
ント／サーバアプリケーションとしてＤｏｃｕｍｅｎｔ
ｕｍを用いた統合化である。

【００６０】５．アーキテクチャの可動性／拡張性 本アーキテクチャは、ＳＡＳ／ＰＨ−Ｃｌｉｎｉｃａｌ
とＤｏｃｕｍｅｎｔｕｍに結び付けられているソフトウ
ェアから、各種の統計解析ツールや文書管理システムと
協動でき、提出プロセスの制御と追跡にさらに特徴を持
つソフトウェアを提供することができる。

【００６１】ＫｎｏｗｌｅｄｇｅＰａｔｈのシステム概
念は製薬業界の枠を越えて、大規模なデータ解析に基づ
く複雑な文書を提出することが必要なあらゆる規制対象
業種に適用できる。このような業種として、ヘルスケ
ア、エネルギー、金融サービス、製造業と電気通信業等
がある。本システム概念は、規制対象業種以外の（政府
機関の目的とは逆に）社内目的のために未発表製品の効
果解析および報告を実施するあらゆる業界へも応用する
ことができる。

【００６２】データと文書の間に複雑で動的に変わりや
すい依存関係があって両方が情報の全体的な状態に寄与
している場合、特にこの全体的な状態を可視化して追跡
する必要がある場合にＫｎｏｗｌｅｄｇｅＰａｔｈは有
用である。データベースシステムと文書管理システムを
相互運用するための便利なパラダイムが他にもある。大
企業における典型的なものは、データベース内のデータ
からビジネス文書を動的に作成し、その結果作られた文
書のコピーをリポジトリにアーカイブすることである。
この場合、文書は単に“人が使うために用意されたデー
タ”のビューに過ぎず、データと文書間の依存関係は単
純かつ静的である。後者の状況ではＫｎｏｗｌｅｄｇｅ
Ｐａｔｈの能力は必要とされない。

【００６３】６．ＤａｔａＤｏｃｋｅｔ 好適な一実施の形態において、本発明は一段階以上の複
雑さを以って実装され、各段階は、従来技術の機能の上
により多くの付加価値を加え、知識統合化問題のより複
雑な側面を扱うことにより構築される。第一すなわち基
本レベルにおいて、ＤａｔａＤｏｃｋｅｔフェーズは文
書作成（例：認可のために提出が義務付けられている）
のためにデータ解析レポートを文書管理システムに転送
するプロセスを自動化し、データリポジトリと文書リポ
ジトリ（およびその中の各文書）間での情報の流れを同
期させ、文書からデータ解析ソフトウェアへ戻るリンク
を提供する。このようなシステムはまた、好適には、デ
ータのユーザにより共有、保存、アクセスされる情報と
関連付けられたメタデータを取り込んで、情報が使われ
ている“コンテキスト（前後関係）”を特徴付ける。例
えば、図４、５に示すように、顧客データ解析ソフトウ
ェアアプリケーション５０（例：ＳＡＳ／ＰＨ−Ｃｌｉ
ｎｉｃａｌ）は企業文書管理システム５５（例：Ｄｏｃ
ｕｍｅｎｔｕｍやＰＣ Ｄｏｃｓ）から分離、独立して
いる。２個のアプリケーション間で情報のやりとりを行
なうためのメカニズムはない。単純化した形で、情報の
通信はポイント間システム６０に実装されてよく、カス
タマイズされたソフトウェアが、データベース／解析ア
プリケーション５０から文書リポジトリソフトウェア５
５に保存された文書へのデータ転送と貼り付けを実現す
るよう設計されている。しかしながら、このようなシス
テムは、あるソフトウェア・アプリケーションから別の
ものへ通信する問題を解決する以外にはほとんど価値が
ない。

【００６４】図４または５に示す好適なＤａｔａＤｏｃ
ｋｅｔアーキテクチャは、企業の情報システムを構成す
る２個以上のアプリケーション間の情報の流れを管理す
る“ミドルウェア”６０により特徴づけられる。ソフト
ウェアは好適にはオブジェクト指向コード（例：Ｖｉｓ
ｕａｌ Ｃ＋＋コード）として実装され、Ｖｉｓｕａｌ
Ｂａｓｉｃで作成されたプロトタイプモジュールを使
用してもよい。図６に示すように、ソフトウェアはクラ
イアント／サーバ型システム（例：Ｗｉｎｄｏｗｓ Ｎ
Ｔ）上で動作してＷｅｂベースの操作性を実現し、ユー
ザはＷｉｎｄｏｗｓ ＮＴ／９５オペレーティングシス
テムソフトウェアを搭載したＰＣクライアントシステム
を操作しよう。ＤａｔａＤｏｃｋｅｔフェーズの機能に
は以下のものが含まれる。 （ａ）独立したデータ解析と文書管理ソフトウェアの統
合化 （ｂ）メニュー選択方式またはバッチ処理方式のコマン
ド （ｃ）データの流れを表現する監査証跡の生成 （ｄ）解析データのバージョン管理 （ｅ）データ解析ソフトウェアとＥＤＭＳ間のリンク実
現 （ｆ）統合化トランザクションに関する動的な情報を保
存する知識ベースの更新 （ｇ）データ解析および文書管理システム内のオブジェ
クト間で“生きた”リンクを実現 （ｈ）保存されたコンテキスト情報を利用して、レポー
トがどのように作成されたか、誰が作業を行ない、いつ
完成したかに関する履歴情報へのアクセスを実現 （ｉ）統合化トランザクションの一部としてワークフロ
ーイベントを発生（例：電子メールでの通知、翻訳作成
要求等）

【００６５】ＤａｔａＤｏｃｋｅｔフェーズから得られ
る利点は、情報統合化のプロセスと実施が改善され、手
作業で通常発生する誤りの頻度が減少し、ワークプロセ
スの品質が保証されることにより、ビジネス上の意思決
定がより良くより速く行なえ、ユーザのデスクトップか
らテキストおよび数値情報源の両方により簡単にアクセ
スできるようになる点である。

【００６６】図６にＤａｔａＤｏｃｋｅｔのアーキテク
チャをより詳細に示し、その中で上述の機能を可能にす
るのに必要なソフトウェアコンポーネントを表わす。特
に、本アーキテクチャは相互に関係付けられた一連のソ
フトウェアコンポーネントを含む。本アーキテクチャの
中心に、クライアントとサーバ副コンポーネント（ＤＤ
クライアントとＤＤサーバ）で構成されるＤＤコントロ
ーラコンポーネント７０がある。ＤａｔａＤｏｃｋｅｔ
（ＤＤ）コントローラコンポーネントは、すべてのＤａ
ｔａＤｏｃｋｅｔコンポーネントの通信と動作を制御
し、マルチスレッドのサーバと並行して動作するクライ
アントソフトウェア、すなわちＤＤサーバとＤＤクライ
アントで構成される。設計の特徴／オブジェクトは好適
には、Ｍａｉｔｒｅ ｄ−、データベースコミュニケー
タ、ワークホース、クライアント、ロガー、アドミニス
トレータ、ソケットコミュニケータ、ジョブキュー、ク
ライアントメーラー、オーディタ、ジョブ／オブジェク
ト状態、トランザクションフィードバック、同期／非同
期動作モード、バージョン管理等を含み、それらのソー
スコードを添付のソースコード付録掲載した。

【００６７】クライアント／サーバコンポーネント７０
がＤａｔａＤｏｃｋｅｔによりリンクされている可能性
のある各種の独立したアプリケーションとインタフェー
スを持つために、システムは好適にはＤａｔａＤｏｃｋ
ｅｔアプリケーション・プログラミング・インタフェー
ス（ＡＰＩ）８０を採用している。ＡＰＩ８０は、ＤＤ
コントローラー外部との通信をつかさどり、独立したソ
フトウェアアプリケーション（例：データ解析ソフトウ
ェアや文書管理ソフトウェア）間の統合を可能にする。

【００６８】図６に示すように、データ解析および審査
ブロック９０は、データベース９４に保存された解析結
果とメタデータにアクセスできてその情報をユーザ１０
１にアクセスさせるデータ審査サブコンポーネント９２
を含む。解析結果およびその出力がサブコンポーネント
９６により与えられ、ユーザの指示によりデータベース
に保存されているメタデータを処理する。ＡＰＩ８０を
手段として用いて、データ審査、データ解析および出力
生成がＤＤコントローラ７０により起動および制御され
る。

【００６９】同様に、文書管理および審査(review)ブロ
ック１００は好適には文書校閲(review)サブコンポーネ
ント１０２を含んでおり、ユーザ１０１は文書データベ
ース１０４に保存されている参照文書や主張(assertio
n)文書を校閲することができる。文書管理およびワーク
フローサブコンポーネント１０６はまた、ユーザの指示
により文書データベースに１０４とインタフェースを持
って、文書の作成、管理、または更新を行なう。データ
解析や校閲機能と同様に、文書管理および校閲ブロック
１００とＤＤコントローラ７０のサブコンポーネント間
のインタフェースはＡＰＩ８０を介して実現されてい
る。ＤａｔａＤｏｃｋｅｔの基本的な実施の形態におけ
る各種コンポーネントの一般的な動作を述べたので、以
下ではサブコンポーネントの特徴をより詳細に解説す
る。

【００７０】ＤＤコントローラ７０のクライアントサブ
コンポーネントはＤＤサーバと並行して動作する。本ク
ライアントサブコンポーネントは以下の擬似コードによ
り特徴付けられる。

【００７１】クライアント起動タスク (Client Startup
Tasks)(仮定: ＰＨＣまたはコマンドラインからユーザ
名がわかっている) , ＰＨＣは出力ディレクトリを送
る。実際に起動されていれば、バッチジョブかどうかわ
かる。 サーバへのログオン試行 [動詞 : LogＯn。ログイン応答でハンドオフ領域が返 される ] -生きていることをチェック -送信／返信されたクラスと互換性のあるバージョン -互換性無ければ通知を表示して異常終了 メッセ−ジ確認(Check Msgs)( 動詞 : GetMsgList ) その時バッチで無ければ、待機中または未読メッセージがあればユーザ に表示 理想的には、読み取り中にジョブ処理を中断しないこと ルートファイル [handoff＿area] 領域がサーバが探索している場所と一致して 、使用されていることを確認してドライブマッピングを回避するためにＵＮＣネ ーミング規約に変換 ジョブファイル読み込み ＳＡＳによる上書きからファイルを（名前変更／移動により）保護 （ジョブディレクション内のファイルパスを更新してサーバへ送信） >>how? ジョブ送信試行(Try to send job)(動詞 : QueueJob) 受理されなかった場合において、 対話処理の場合、キュー状態メッセージを表示。（これに応答して、サーバは キュー状態を返す。例：“バックアップ中のため文書使用不可”） それ以外の場合、（バッチ）キュー状態メッセージをユーザにメール送信 WriteSasLog ("queue not accepting"),quit. 同期／非同期事項： 同期：ジョブ状態追跡、進捗表示［コンテキスト表示試行／ジョブ仕様を識別す るために情報を要約（可能なら）［10月31日はdate/timeを使用］］ −サーバから'stllAlive'のpingピングを取得 −十分な頻度でなければ、WriteSasLog（"serverDied"）して終了 −受信メッセージ(Incoming message)：jobHasMoved status＿inQUeue −jobHasMoved status＿inQUeue −jobHasMoved status＿inProcess −ユーザ入力受理 −メッセージがあれば読む −キャンセルボタン −クリックされたらサーバへRequestCancelを送信 −完了(Completion)： −受信メッセージ(Incoming message)：status＿doneでジョブステータスを 取得 −GetSASLogfile(jobID)メッセージをサーバへ送信、SASログが返る −バッチでなければ、恐らくユーザにログを表示 −DBにSASLogファイル作成を要求。プログラムを書き込んで終了 −ClientQuittingを送信 クライアントが受信したメッセージ(Msgs received by Client) CmailBox｛ CmailBox （ int myID ）; // 所有者のユーザｉｄを渡す CMsg ^*GetMsg ( int msgID ); BooL HaveUnread (); BooL MarkAsUnread (CMsg ^*theMsg); // ユーザが一致するか確認すべきか ？ Private: Int m＿myID; ]; メニュー項目(Menu Items) Preferences −サーバのIPアドレスを設定 Config サーバのIPアドレス

【００７２】同様に、ＤＤコントローラ７０のサーバサ
ブコンポーネントは以下の擬似コードに従って動作し、
好適には付録のソースコード表に示すＡｄｍｉｎ， Ｗ
ｏｒｋｈｏｒｓｅ、Ｍａｉｔｒｅ機能を含む。

【００７３】 サーバ起動 (Server Startup) ? 管理者(Admin): サービス実施するか MD [インスタンス変数: WH リスト, キュー状態, ユーザリスト, Cdatabase m＿ db;] : マシン上の単一インスタンス: 既にコピーが実行中であれば速やかに終了 DBへ接続(Connect to DB) 不可能ならば警告する -- (どのように?) 設定情報をロード(Load configuration) −マシンのIPアドレスがtbConfig. Server＿IPに一致しなければ終了 Preflight −file＿root領域は視認可能でアクセス可能 −接続できない場合、メールメッセージを管理者に送信 (高優先度) 起動(Startup) : Workhorses 開始(Start Workhorses) For (max workhorses) ( WHTable.LaunchNewWH ) . .exeはMD .exe と同じフォ ルダ内で" DDWork . exe"と呼ばれると仮定 ジョブキュー構築(Build Job Queue) “準備中”状態のジョブをDBに問い合わせる。状態を“待機中”に戻す。管 理者にジョブが異常終了して再起動中とのメッセージを送る “実行中”状態のジョブをDBに問い合わせる。管理者にジョブが異常終了し て再起動中とのメッセージを送る（およびどの出力オブジェクトで起きたか、も ） 待機中状態のジョブをDBに問い合わせる。（ジョブｉｄ順に）。メモリにリ スト作成 JobHasMoved メッセージをすべてのログインユーザに送信して接続／状態を確立 −受信メッセージを受理(Accept incoming msgs): −Login ［注:ユーザは同時に2台の異なるＰＣにログオンできる ］: −ユーザが既にログインしていい場合、ログインを許可する 。ログインしてＩＰアドレスを記録する(login..record IP address)。 [DISC] −クラスのバージョンを比較 −成功／失敗の応答を送信 (キュー状態も送信？) −実行中のユーザプロセスがある場合、ユーザへJobHasMove dを送信 −GetSASLogFile [jobID] [これらのリクエストを実行するのか かった時間を監視する必要あり] −ログファイル生成。テキストを返して、 −int errCount; −BOOL foundJoblD; −Cstring logFileText; −RequestCancel [joblD] −ジョブ[joblD]が見つかって、待機状態であれば、 − BEGIN＿MUTEX(job). − DBにコミットしながら、状態をキャンセルに設定す る −メモリ内のジョブキューから削除 − [Joblnfo] とSAS ファイルを削除 // サブルーティ ン呼び出しであるべき サブルーティン呼び出し − END MUTEX − RefreshJobStatus ( ); // 接続中のクライアントへJ obHasMovedを送信 − QueueJob [注: 所要時間を監視すべき。CPUを独占して、送 られてきたクライアントリクエストを妨害しないよう注意を要する] − 関連付けられたクラス: CJobInfo − エラーが無く、キューがジョブを受理する場合、 − メモリ内のリストに登録し、JobQueueエントリを 生成してDBを更新 − 解析済みジョブデータから[JobInfo]ファイル(Carc hive)を作成する。’一時’ファイルに保存し、JobQueueレコードに記入する − JoblDをクライアントに返す − それ以外は(Else) − エラーコード／ストリングをクライアントに返す − WHメッセージ(WH messages): − StillAlive − Whtable [proclD] IastAllve = time を設定 − アイドルループ(Idle loop) − Wh [xl が死んだ場合、そのジョブを再びキューに登録 − 必要なら WH を再起動 − WHTable.LiveSessions () < Max＿workhorses ］の場合 − WHTable.LaunchNewWH − WH にとってMethods が使用可能(Methods available to WH): − PeekNextQueueltem() − 待機中または実行中状態のジョブを返す可能性あり − SetJobStatus ( ジョブlD、 新状態 [準備中／実行中／完了] ) − DB内のJobQueueの状態を更新 − JobMoved メッセージの送信を実行 − 多数のwhがある場合、これが最初と仮定すべきでない WH [2スレッド:2番目のものは10秒毎に‘生存中’をMDに送信するジョブを有す る] : Connect to MD (他のマシン上にあってもよい) . Connect to DB −DocBase／あて先フォルダ情報の設定を読む − Preflight : − DCTMの接続状態を確認 −＞ 管理者にメッセージ送信可能 − 接続できない場合、tbConfig. EDMS＿Retry秒後に再試行 − DocBaseにDDWriterとして接続 − 必要であれば出力フォルダを作成 − それらを発見／作成できることを確認 −メイン処理ループ − BeginTrans [ 重要: OutputQueueオブジェクトが作成され、か つ(JobInfo)ファイルが削除されるまで／されない限り、状態を実行中に変更し てはならない] − MD.PeekNextQueueltem ()を有するキュー内のフロントジ ョブを見る。 − MD.SetJobStatus（ id,preparing） − BEGIN＿MUTEX(job). // ジョブを操作中なので状態を変更 できる。これにより他人がジョブに触ることができなくなる。 − If ( status == pending [既にジョブが実行中でDBレコー ドが生成されているかもしれない]) [ Data Members : Cdatabase m＿db; −[Joblnfo]ファイルからのオブジェクトのためにOutputQueu e オブジェクトを作成 - すべてに待機中としてマークを付ける。プロセスが失 敗した場合、すべての００オブジェクトの周囲にトランザクションが存在する − MD. SetJobStatus (Inwork) −] − END＿MUTEX − EndTrans − CUserlnfo ActiveClient (job.UserlD); // ログオンされないか、 ２台以上のＰＣにある − ActiveJob 内のＯＯ個数回ループ −For 各出力オブジェクト: − If HasBeenSent (Source＿Object＿ID) // バージョン付 与されていないため、２回送信してはならない − Next OO - BeginTrans − ファイル個数回ループ ファイルをDocBase へチェックイン ENDLOOP OO.Status fieldを更新 OO.Destination に保存( ログファイルをDocBase へチェックイン 監査情報を添付 EndTrans − MD.SendMsg (ActiveClientJob.JobHasMoved) . // 通 信エラーを無視 − ENDLOOP // アクティブなジョブ − CMailMsg をクライアントへポストし、ジョブ完了を通知する − MD.SendMsg （ActiveClientJob, PostedMsg ） − [Joblnfo]ファイルを削除 − SAS コンテンツファイルを削除 (常に、エラー／キャンセルで も ) − MD.SetJobStatus (status done) [JobHasMovedをクライ アントへ送信する] //通信エラーを無視 − Ping Thread − If (time elapsed > 10 秒) MD.StillAlive (processID) − アクティブクライアントにPingし、生きていることを通知

【００７４】以下の擬似コードは、クライアントをサー
バから分離しないクライアント／サーバモデルの実装を
表わす。言い換えるならば、擬似コードはクライアント
とサーバを念頭において書かれていて、適切に抽象化さ
れているが、それらは同じ実行可能プログラムに存在し
て、クライアントＰＣから実行されてもよい。好適な一
実施の形態において、これらのオブジェクト組は分離さ
れるであろう。

【００７５】 必要な設定情報(Config Info Needed) Registry/INI 内 DB＿Path DB位置 Max＿workhorses workhorsesの最大値 DB内(In DB) Target docbase [handoff＿area] オフファイルを渡すルートフォルダ(UNC conven tions) ?? DCTMに入るためのパスワード サーバメニュー機能(SErver Menu Functions): Broadcast Message メッセージ要求。全ユーザへ送信 Queue Status キュー状態を以下のいずれかに設定させる: ()新規ジョブを受け付ける ()新規ジョブ無し Choose Docbase [宛先フォルダも選択。DDWRiter アカウントを設定する必要あ り。フォーマット設定とdocbase準備に作業発生の可能性] − WHが実行中でないときのみ許す Kill workhorses- Preferences Root Folder PHCから内容を渡すために使われたフォルダを選ぶ workhorseが実行中またはユーザがログオン中は変更不可 ジョブの状態(Job statuses) 待機中(Pending) [JobInfo]ファイルにジョブの記述あり OutputQueue レコードは未作成 準備中(Preparing) トランザクション開始 DBレコード作成 トランザクション終了 [JobInfo]ファイル削除 実行中(InWork) 完了(Done)６

【００７６】上述のように、ＤＤアプリケーション・プ
ログラミング・インタフェース（ＡＰＩ）は、ＤＤコン
トローラー外部との通信をつかさどり、複数の独立した
ソフトウェア・アプリケーション（例：データ解析ソフ
トウェアや文書管理ソフトウェア）間の統合を可能にす
る。

【００７７】図６はまた、知識管理ブロックすなわちレ
ベル１２０をも示す。知識管理レベル１２０はＤａｔａ
Ｄｏｃｋｅｔ知識ベース（ＤＤ−ＫＢ）１２２を含み、
これはＤａｔａＤｏｃｋｅｔ基本システムの第二の、ま
たはそれ以上に改良された実施の形態で実現された他の
機能と同様に、“生きた”リンクを識別し、ビジネスプ
ロセスや仕事のしかたと関連付けられたすべてのトラン
ザクションを追跡および記録するのに必要な情報を保存
することにより知識を獲得すべく設計された、Ｄａｔａ
Ｄｏｃｋｅｔアーキテクチャ内の専用データベースであ
る。知識管理レベル１２０はまた、ＤａｔａＤｏｃｋｅ
ｔ Ｗｅｂベースの知識レポータ（ＤＤ−ＫＲＰＴ）１
２４をも含み、これは好適にはＷｅｂブラウザインター
フェースを介してＤａｔａＤｏｃｋｅｔ知識ベースが管
理する情報の問合せとレポーティングを実現するコンポ
ーネントである。

【００７８】続いて図７に、知識統合化管理システム２
００の一般化された３次元ビューを示す。特に、システ
ム２００は以下に述べる一連の情報関連アプリケーショ
ン２１０の動作を統合化することができる。すなわち、
情報検索２１２、他のアプリケーションやサービス２１
３、出版アプリケーションやサービス２１４、データア
プリケーション（管理、ウェアハウジング、解析）２１
６、文書管理やライブラリサービス２１８、ワークフロ
ー管理２２０、文書作成ツール（コンテンツのテンプレ
ートや文書編集を含む）２２２、出力と配布サービス２
２４、および画像管理２２６である。各種の情報関連ア
プリケーションの統合化を越えるレベルで、本システム
は、知識統合化範囲２３０で表わされるそれぞれのアプ
リケーションに含まれる知識を統合する。同様に、一度
統合化された知識が得られると追加の機能がシステムに
加えられてよく、以下にそのような例を一般的に特徴付
けて示す。

【００７９】また図８を参照するに、図７の知識統合化
システム２００の上位ソフトウェアアーキテクチャを示
す。図８のアーキテクチャにおいて、システムは３個の
別々のソフトウェアレベル、すなわち情報管理３００、
ミドルウェア３０２および知識管理３０４に分割されて
いる。情報管理レベル３００内には、ＤａｔａＤｏｃｋ
ｅｔシステムが制御する複数の独立した情報管理アプリ
ケーションがあり、例えば、画像データ３１０Ａとそれ
に関連付けられた画像アプリケーション３１０Ｂ、文書
３１２Ａとそれに関連付けられた文書アプリケーション
３１２Ｂ、統計および／または解析データ３１４Ａとそ
れに関連付けられたデータ処理や解析アプリケーション
３１４Ｂがある。

【００８０】上述のように、ＤａｔａＤｏｃｋｅｔシス
テムはレベル３００におけるこれら各種の情報管理アプ
リケーション間でインターフェースを取るためにＡＰＩ
レイヤ（図示せず）を用いる。ＡＰＩ、およびＡＰＩの
機能を制御するＤＤコントローラコンポーネントは、一
般にレベル３０１に位置付けられるミドルウェア３２１
として特徴付けられる。ミドルウェア３２１により実現
された機能は、各種の情報管理アプリケーション（アプ
リケーション統合化３２０）の機能の統合化を可能にす
るだけでなく、各種の情報管理アプリケーション（知識
統合化３２２）の内外を出入りする情報の流れを監視す
る付加的なリソースをも提供する。次いで知識統合化ブ
ロック３２２は、知識リポジトリ３３０を介して知識管
理レベル３０４への入力を与え、またそこから命令を受
け取る。

【００８１】入力として、知識統合ブロックはトランザ
クションレコード、ユーザやアプリケーションからのコ
ンテキスト情報、および知識リポジトリ３３０内で情報
メタデータカタログに保存する情報を提供する。知識ア
プリケーション／サービスは潜在的に、システムに存在
する統合化された知識の効率的な利用と抽出を可能にす
る広範囲な特徴である。本発明の特徴を以下により詳細
に述べる。

【００８２】７．ＲｅｐｏｒｔＣｏｏｒｄｉｎａｔｏｒ ＲｅｐｏｒｔＣｏｏｒｄｉｎａｔｏｒ（登録商標）（Ｒ
Ｃ）は、生のデータシートの受け取り、データ解析、手
渡しから文書作成まで、データレポートの作成に必要な
プロセスを調整する。ＲＣはレポートを、レポート要素
（コード、データシート、ログ、出力）の論理的な組と
して組織化して、統計解析データ、レポート、コードロ
グ、外部マクロ、コードライブラリを登録する。ＲＣは
レポート要素（コード、データセット、ログ、出力等）
間にある暗黙の依存関係を識別し、データレポート作成
プロセスの一部として作成されたデータと文書コンポー
ネントを同期させ、レポート要素（コード、データセッ
ト、ログ、出力）を見るためにコンテンツ専用のビュー
ワを提供し、レポート作成に関係するすべてのコンポー
ネント間の依存関係を管理し、データレポートコンポー
ネントの状態を監視する。ＲＣは、ＤａｔａＤｏｃｋｅ
ｔを経由して、データレポートを自動的かつ特別に(ad-
hoc)ＥＤＭＳに転送し、ＥＤＭＳにある解析データレポ
ートと文書の間を接続し、レポート更新の必要性を識別
して更新しやすくする。ＲＣはワークグループ通知とデ
ータレポート転送の受信を行なう。レポートを登録する
ためにバッチ起動がサポートされていて、オプションと
して文書作成機能へレポートを転送する。

【００８３】８．ＫｎｏｗｌｅｄｇｅＬｉｎｋ ＫｎｏｗｌｅｄｇｅＬｉｎｋ（登録商標）（Ｋ−Ｌｉｎ
ｋ）”の実施の形態は、文書および解析データに保存さ
れた“生きた”知識リンクを埋め込んで実行する。ユー
ザは実際の情報コンテンツのどこからでも、１個以上の
情報管理（データまたは文書）アプリケーションにより
実行される複数のタスクを定義し、起動することが可能
になる。特に、原文書または出版された文書の中から知
識リンクが指定されて、データ解析システム内の関連オ
ブジェクトに戻るリンクを設定してもよい。（文書コン
テンツ中のアンカーすなわちページの特定の場所、で定
義された）任意の原文書リンクは、文書が特定のフォー
マット（例：Ａｄｏｂｅ（登録商標）ＰＤＦ）で出版さ
れた場合でも維持される。それによりユーザは知識リン
クを呼び出して、知識リポジトリ内の情報にアクセスし
て、各種のアプリケーションとの間で一連のトランザク
ションを起動する一連の規定されたタスクを起動させる
ことができる。従ってＫ−Ｌｉｎｋはデータと文書コン
ポーネントの間の関係と依存関係をさまざまなレベルの
粒度でマッピングして、特定のタスクに関係するデータ
や文書に関する知識の取り込みと再利用を可能にする。

【００８４】９．ＫｎｏｗｌｅｄｇｅＶｉｚ ＫｎｏｗｌｅｄｇｅＶｉｚ（登録商標）（Ｋ−Ｖｉｚ）
の実施の形態は、ユーザが３次元インタフェースと概念
スキーマを用いて、保存・管理されている場所にかかわ
らず企業情報にアクセスすることにより、統合化知識ベ
ースに保存されたオブジェクトやリンクを可視化できる
ようにするものである。特に、知識可視化手段は、ここ
で述べた知識管理システムにグラフィカルなフロントエ
ンドを提供し、ユーザ固有の分類法／分類階層を介した
知識を探索、アクセス、および利用できるようにする。
本手段は例えば、３次元作業環境を用いて、データと情
報リポジトリ（統計データ、文書、イメージ等）、それ
らの構造、要員、義務付けられた提出物／製品、プリン
ター等のすべてを含んだ、親しみのある規制対象環境を
構築し、それらのオブジェクトおよびオブジェクト間の
リンクをシミュレーションしてその実時間での状態を把
握するような使い方ができる。このような可視化手段の
例を、ＩｎＸｉｇｈｔ社から提供される製品群として述
べ、Ｈｙｐｅｒｂｏｌｉｃ Ｔｒｅｅ、Ｐｅｒｓｐｅｃ
ｔｉｖｅ Ｗａｌｌ、Ｔａｂｌｅ Ｌｅｎｓ、Ｃｏｎｅ
Ｔｒｅｅが含まれる。

【００８５】１０． ＫｎｏｗｌｅｄｇｅＧｅｎ ＫｎｏｗｌｅｄｇｅＧｅｎ（登録商標）（Ｋ−Ｇｅｎ）
の実施の形態は、義務付けられたマーケティングアプリ
ケーションプロセスの管理に用いられる知識文書を作成
するものである。ルールベースのアプローチを用いるこ
とにより、仮説の設定、構造化および非構造化データで
構成される主張と説明が可能になる。義務付けられた認
可を得ることが求められる最終結果である申請におい
て、Ｋ−Ｇｅｎは確実に認可を受けられるように全体的
な検証計画を定義し、維持する。

【００８６】本好適な実施の形態は、完全な、かつ同期
した情報源の組に基づく結論を下したり支持する責任を
持つ“義務付けられた”知識作業者を支援する統合化シ
ステムとフレームワークでであろう。このようなフレー
ムワークの実装は、上述のごとく統合知識ベースを自動
的に構築するメカニズムを提供し、解析と意思決定を支
援する情報処理に役立つユーザ指定のリンクに基づいて
統合知識ベースを拡張し、統合知識ベースをグラフィカ
ルに表現し、義務付けられた検証（ある仮説を支持する
主張に基づく論理的な議論であって、その目的は、結論
に達するために用いられた“推論”を明確にするのを手
助けすることであって、仮説を支持するデータや矛盾す
るデータの有無が認識できるようにしたり、新しいデー
タの影響を調べることにより知識生成ライフサイクルを
通じて有用なはずである）を確立させるようなツールを
必然的に含む。

【００８７】このシステムをさらに拡張するものとし
て、評価にとり最も重要度の高い情報を識別するメカニ
ズムが含まれ、それにより知識作業者の監督下で、自動
化された“エージェント”が傾向、異常、リンク等を調
べるために統合化知識ベースを継続的に見直して、精査
する。このようなシステムにより、新しいデータを以前
の情報や議論と比較することが可能になる。

【００８８】１１．ユーザ対話機能 ここで述べたアーキテクチャの実施の形態と機能は、統
合化された解析および意思決定プロセスの効率に影響を
与えないために知識作業者がツール間をスムーズに対話
できるように統合化されていることが好適である。この
アーキテクチャで指定されているメカニズムの設計と実
装にとって極めて重要なことは、義務付けられた申請書
を提出するための証明を揃える一環として求められる、
あらゆる作業の“知識経路”を取り込むことである。究
極的には、証明を校閲している者は誰でも、完成した申
請書から議論の発生や解析過程で行なわれた主張および
最終的には元のデータにまで至る、すべてのステップを
たどり直すことができねばならない。従って、なされた
意思決定を支持するすべてのトランザクションに対する
コンテキストを取り込むことが不可欠である。このよう
な機能において トランザクションのテキスト記述、た
とえば知識作業者が“なぜ”ある作業をしているのか、
を記録することが必要となろう。しかし可能な限り情報
の記録は、出典情報およびそのような情報を管理するシ
ステムへの動的な（すなわち“生きた”）リンクにより
電子的かつ自動的に行なわれるべきである。一例とし
て、電子的な文献索引付けおよび配布システムにより管
理されている関連出版物は、ある主張を支持する特定の
意思決定プロセスの一部として用いられ、次いでこのシ
ステムから参照された項目は、システムから検索する方
法を含めて、一意に識別されるべきである。ここで述べ
たシステムの主要な目的の一つも同じく重要であり、そ
れは知識作業者が自らの結論を、あらゆる原文書から得
たより完全な情報群に基づいて得ることができるように
することである。

【００８９】次に、図９乃至図２０に示した各種のユー
ザインタフェース画面を参照しつつ、 ＤａｔａＤｏｃ
ｋｅｔシステムの実施の形態の各種の態様を説明する。
本発明の一実施の形態は、解析結果出力のＥＤＭＳへの
自動転送である。図９に、病院関連のデータを管理する
ＳＡＳ／ＰＨ−Ｃｌｉｎｉｃａｌ（登録商標）ソフトウ
ェアを利用したシステム例へのユーザインタフェースを
示す。特に、図９は架空の薬品“Ｄｏｃａｚｏｌ”用に
管理されたデータとレポートのフォルダ構造を示す。ウ
インドウの左側カラムに各種の提出レポートが、右側カ
ラムに特定のフォルダのコンテンツが、ＳＡＳ／ＰＨ−
Ｃｌｉｎｉｃａｌソフトウェア環境と同様に、すべてＭ
Ｓ−Ｗｉｎｄｏｗｓ（登録商標）搭載の環境に表示され
ている。ＳＡＳ／ＰＨ−Ｃｌｉｎｉｃａｌデータベース
またはリポジトリ（図１０に示すとおり）からの解析デ
ータの転送は、ポップアップウインドウ７１０で表示さ
れた“送信(Send to...)”オプションを選択すれば起動
される。“送信”オプション７１２を選択するとウイン
ドウ７２０が開いて、送信対象解析データの所望の宛先
が表示される。“送信”オプションを選択すると上述の
ようにＤＤ−ＡＰＩが呼ばれて転送処理が起動される。
転送処理は監視され、トランザクションの進捗と正常終
了を確認するための進捗ボックス７５０内の棒グラフを
介して表示される。処理が完了すると、転送された情報
は図１１に示すＤｏｃｕｍｅｎｔｕｍ（登録商標）ワー
クスペースの結果、特に仮想文書マネージャフォルダ８
２０内で見ることができる。

【００９０】本発明の別の態様は、ワークフローイベン
トを発生させる機能である。例えば、図１２に、Ｄａｔ
ａＤｏｃｋｅｔコントローラ進捗ウインドウ９１０がサ
ブウインドウ９２０内でメールの状態を表示して、通知
ウインドウ９３０でユーザに電子メールトランザクショ
ンが完了した旨を知らせる様子を示す。図１３に示すよ
うに、ユーザは確認ウインドウ１０１０でリンク１０２
０を選ぶことにより、ジョブの状態を問い合わせること
もできる。ユーザがリンクを選択すると、ブラウザウイ
ンドウ１０３０が開いて転送状態（例：完了）を示す。

【００９１】続いて図１４を参照するに、図中にワーク
スペース文書マネージャーウインドウ１１１０の一部
と、その中の文書データベースウインドウ１１２０が示
されている。ハイライトされたテキスト１１３０で示す
ように、ユーザは解析出力を利用してレポートを作成す
ることができる。例えば、ハイライトされた項目を選ぶ
と、図１５に示した仮想文書マネージャーウインドウ１
２１０ が表示される。

【００９２】本発明の別の態様は、文書からのデータ解
析システムへ戻る動的リンクの確立である。例えば、図
１６に示すように、ユーザはＤｏｃｕｍｅｎｔｕｍ Ｅ
ＤＭＳインタフェースから、を支持したソースデータま
でたどり着くことができる。特に、ユーザは、仮想文書
マネージャーウインドウ１３１０でハイライトされたオ
ブジェクト１３４０をダブルクリックして選択すること
により、選択したオブジェクトを見るオプションを起動
することができる。ウインドウ１３２０内で“閲覧(Vie
w)”ボタン１３３０が選択された場合、解析データベー
スにリンクして、一実施の形態において、ＳＡＳ／ＰＨ
−Ｃｌｉｎｉｃａｌ環境を呼び出すことにより、オブジ
ェクトが表示され、そこで図１７に示すようにＡｎｏｖ
ａプロットを表示させることができる。図１８に示すよ
うに、同様の機能がＷｅｂベースの環境からブラウザウ
インドウ１５１０を介して実現できる。さらに、他のデ
ータへのさらなるリンク、例えば場所１５２０により参
照が行なわれてもよい。

【００９３】図１９及び図２０に、コンテキスト情報や
メタデータの知識ベースへの登録を示す。特に、図１９
は一対のウインドウ１６１０，１６１２を示す。ブラウ
ザウインドウ１６１０内で、ユーザは“ビュー出力オブ
ジェクト(View Output Objects)”リンク１６２０を選
択してウインドウ１６１２を呼び出すことができる。ウ
インドウ１６１２によりユーザは、自分のデスクトップ
からＷｅｂベースの問合せを起動して、例えば、解析出
力（テキストフィールド１６１４a ）の名前、特定の作
成者（フィールド１６１４b）、転送状態（プルダウン
フィールド１６１４e ）等の特定の特徴を有する知識ベ
ースレコードを見ることができる。図２０に、解析出力
探索（例：”ａｅレポート＃１”の探索）に応答して得
られた結果の例を示す。

【００９４】要約するに、本発明は、最初に企業内の情
報管理に向けた各種の独立したソフトウェア・アプリケ
ーションの運用を統合化する方法と装置である。しか
し、システムアーキテクチャは拡張可能なアーキテクチ
ャであり、統合化された情報管理アプリケーションの内
外およびアプリケーション同士の情報の流れを容易に監
視できるようにすることにより、知識情報を吸収し、そ
のような情報の制御を容易にする知識統合化手段が組み
込まれている。また、知識情報を用いて企業内の知識を
より効率的に利用できるようにする付加的なツールも含
まれる。

【図面の簡単な説明】

【図１】 本発明に係る知識統合化管理システムを構成
する各種の要素を一般的な表わす説明図である。

【図２】 本発明に係る知識統合化管理システムの一実
施の形態を示したブロック構成図である。

【図３】 本発明に係る知識統合化管理システムの一実
施の形態を示したブロック構成図である。

【図４】 本実施の形態における各要素の関係を表した
ブロック図である。

【図５】 本実施の形態における各要素の関係を表した
ブロック図である。

【図６】 本実施の形態において全機能を実装するのに
必要な要素の詳細を表した図である。

【図７】 本実施の形態における知識統合化管理システ
ムの一般的なアーキテクチャを示した図である。

【図８】 図７に示した知識統合システムにおけるソフ
トウェアの階層的なレベルを表わした図である。

【図９】 本実施の形態において用いるユーザインタフ
ェース画面の例を示した図である。

【図１０】 本実施の形態において用いるユーザインタ
フェース画面の例を示した図である。

【図１１】 本実施の形態において用いるユーザインタ
フェース画面の例を示した図である。

【図１２】 本実施の形態において用いるユーザインタ
フェース画面の例を示した図である。

【図１３】 本実施の形態において用いるユーザインタ
フェース画面の例を示した図である。

【図１４】 本実施の形態において用いるユーザインタ
フェース画面の例を示した図である。

【図１５】 本実施の形態において用いるユーザインタ
フェース画面の例を示した図である。

【図１６】 本実施の形態において用いるユーザインタ
フェース画面の例を示した図である。

【図１７】 本実施の形態において用いるユーザインタ
フェース画面の例を示した図である。

【図１８】 本実施の形態において用いるユーザインタ
フェース画面の例を示した図である。

【図１９】 本実施の形態において用いるユーザインタ
フェース画面の例を示した図である。

【図２０】 本実施の形態において用いるユーザインタ
フェース画面の例を示した図である。

【符号の説明】

１０ 企業文書管理システム、１２ 画像管理システ
ム、１４ 企業ワークフローシステム、１６ 知識統合
化手段、２１ データ転送エンジン、２２ 監査証跡デ
ータベース、２３ 文書リポジトリ、２４ データ解析
データベース、２５ 文書リポジトリインタフェース、
２６ データ解析手段、２７ データ解析データベース
インタフェース、２８ 文書作成者、２９ プロセス管
理者、３１ デーア解析ライアント、３２ デーア解析
サーバ、３３ 文書管理クライアント、３４ データ管
理サーバ、３５ オーサリングクライアント、３６ ア
プリケーション間ミドルウェア、３７ Ｋｎｏｗｌｅｄ
ｇｅＰａｔｈクライアント、３８ Ｋｎｏｗｌｅｄｇｅ
Ｐａｔｈサーバ、５０ 顧客データ解析アプリケーショ
ン、５５ 文書リポジトリソフトウェア、６０ ポイン
ト間システム、７０ＤＤコントローラ、８０ アプリケ
ーション・プログラミング・インタフェース（ＡＰ
Ｉ）、９０ データ解析および審査ブロック、９２ デ
ータ審査サブコンポーネント、９４ 解析およびメタデ
ータデータベース、９６ データ解析出力作成サブコン
ポーネント、１００ 文書管理および審査ブロック、１
０１ ユーザ、１０２ 文書校閲サブコンポーネント、
１０４ 参照文書／主張文書データベース、１０６ 文
書管理およびワークフローサブコンポーネント、１２０
知識管理ブロック、１２２ ＤａｔａＤｏｃｋｅｔ知識
ベース（ＤＤ−ＫＢ）、１２４ ＤａｔａＤｏｃｋｅｔ
Ｗｅｂベースの知識レポータ（ＤＤ−ＫＲＰＴ）、２
００ 知識統合化システム、２１０ 情報関連アプリケ
ーション、２１２情報検索、２１３ 他のアプリケーシ
ョン／サービス、２１４ 出版アプリケーション／サー
ビス、２１６ データアプリケーション（管理、ウェア
ハウジング、解析）、２１８ 文書管理やライブラリサ
ービス、２２０ ワークフロー管理、２２２ 文書作成
（コンテンツのテンプレートや文書編集を含む）ツー
ル、２２４ 出力と配布サービス、２２６ 画像管理、
２３０ 知識統合化範囲、３００ 情報管理、３１０Ａ
画像データ、３１０Ｂ 画像アプリケーション、３１
２Ａ 文書、３１２Ｂ 文書アプリケーション、３１４
Ａ 統計および／または解析データ、３１４Ｂ データ
アプリケーション、３１６Ａ 他の情報源、３１６Ｂ
他のアプリケーション、３０２ ミドルウェア、３２０
アプリケーション統合化、３２１ Ｋｎｏｗｌｅｄｇ
ｅＰａｔｈ、３２２ 知識統合化、３０４ 知識管理、
３３０ 知識リポジトリ、３３２ 知識アプリケーショ
ン／サービス、７１０ ポップアップウインドウ、７２
０ ウインドウ、７５０ 進捗ボックス、８２０ 仮想
文書マネージャフォルダ、９１０ ＤａｔａＤｏｃｋｅ
ｔコントローラ進捗ウインドウ、９２０ サブウインド
ウ、９３０ 通知ウインドウ、１０１０ 確認ウインド
ウ、１０３０ ブラウザウインドウ、１１１０ ワーク
スペース文書マネージャーウインドウ、１１２０ 文書
データベースウインドウ、１２１０ 仮想文書マネージ
ャーウインドウ、１３１０ 仮想文書マネージャーウイ
ンドウ、１３２０ ウインドウ、１３３０ “閲覧”ボ
タン、１５１０ ブラウザウインドウ、１６１０，１６
１２ ウインドウ。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ジェフリー エル ウィンクラー アメリカ合衆国 ペンシルバニア州 カレ ッジビル センテニアル ストリート 112 (72)発明者 イブリン エイ ジェイノス アメリカ合衆国 ペンシルバニア州 ウェ スト チェスター デイビス サークル 346 (72)発明者 イガー マーキダン アメリカ合衆国 ニュージャージー州 チ ェーリー ヒル ウィロウデイル ドライ ブ 1109 (72)発明者 クン ドウ アメリカ合衆国 ペンシルバニア州 ノー ス ウェールズ ハンコック ロード 1621

Claims (3)

【特許請求の範囲】
1. 【請求項１】 文書に関連付けられた知識に関するコン
   テキストをアーカイブ可能とし、過去、現在、および将
   来起こり得る意思決定、インフラストラクチャの整備、
   構造化プロセスおよび実施へのアクセスおよび評価を行
   なう機能を提供する知識統合化モジュールと、 異なる文書およびデータソース間でアプリケーションの
   相互運用と同期化を実現するアプリケーション統合化モ
   ジュールと、 前記知識統合化モジュールと前記アプリケーション統合
   化モジュールの間で構造化および非構造化データ、情
   報、知識の橋渡しを行なう知識統合化ミドルウェアとを
   含むことを特徴とする知識統合化管理システム。
2. 【請求項２】 文書の作成から最終審査までの全体の制
   御及び追跡をし、既存のデータ解析ツール、オーサリン
   グツール、および文書管理システムと統合化される文書
   提出プロセス制御および追跡システムであって、 データベースと、 前記データベースにおけるすべてのプロセス監査証跡情
   報を取り込む手段と、 前記監査証跡情報と前記プロセスを可視化する手段と、 全体の検証計画の定義と維持を可能にする手段と、 前記最終検証計画からの提出文書の構築を自動化する手
   段とを含むことを特徴する文書提出プロセス制御追跡シ
   ステム。
3. 【請求項３】 文書オーサリングモジュールと文書解析
   モジュール間のデータ転送を仲介する文書リポジトリ
   と、 統計データ解析およびデータ解析の結果を前記文書リポ
   ジトリに送るデータ解析モジュールと、 文書のオーサリング、保存、検索用の要素およびデータ
   解析結果を前記文書リポジトリに書き込む文書オーサリ
   ングモジュールと、 検証計画を作成して維持し、データ解析データベースと
   前記文書リポジトリの設定を行ない、プロセスの進捗と
   監査証跡情報を可視化するクライアント要素を含むプロ
   セス管理モジュールとを含むことを特徴とする知識統合
   化管理システム。