(57)【要約】  医薬品の開発及び製造プロセスを管理するためのシステム及び方法を開示する。当該方法は、医薬品の開発及び製造の履歴を残し、記録する工程を備え、これにより製品の履歴を生成する。製品の履歴は、コンピュータ上に格納され、複数のデータの種類に基づいて検索可能であり、これにより簡単に情報を入手することができる。当該システムは、コンプライアンスを管理する手順を自動的に提供することができ、この結果、製薬業界の管理基準に準拠することができる。
2008525895.tif 000002
【特許請求の範囲】
【請求項１】
薬の製造のための開発過程を管理する方法であり、
薬の情報を記録する工程と、
複数のデータの次元（dimension）のうち、前記情報に対応するデータの次元に、前記情報を割り当てる工程と、
複数のデータの次元におけるデータの次元間の相互関係を決定する工程と、
前記情報のコンテキストを決定する工程と、
決定された前記コンテキストに対して、データの次元の相互関係をサーチする工程と、
複数の次元と複数の時点とにわたって開発過程の情報を検索する工程と
を備えることを特徴とする管理方法。
【請求項２】
前記情報は複数の次元のうちの１つの次元に割り当てられることを特徴とする請求項１に記載の方法。
【請求項３】
前記情報は素材、人、標準、設備、環境／施設、工程のグループから選択された少なくとも１つ以上のデータの次元に割り当てられることを特徴とする請求項１に記載の方法。
【請求項４】
前記コンテキストは、時間とイベントにわたって情報の変化を規定することを特徴とする請求項１に記載の方法。
【請求項５】
前記相互関係は異なるデータの次元における共通の情報に関連することを特徴とする請求項１に記載の方法。
【請求項６】
前記薬は医薬品であることを特徴とする請求項１に記載の方法。
【請求項７】
薬の製造過程の開発を管理するシステムであり、
長時間にわたり薬の開発及び製造履歴を記録する複数の記録モジュールと、
前記複数の記録モジュールと通信を行うことで、複数のデータの次元にわたって情報追跡ができるプラットフォームを提供するように設定されたコアモジュールと
を備えることを特徴とする管理システム。
【請求項８】
前記コアモジュールは１つのデータの次元に前記情報を割り当てるように設定されていることを特徴とする請求項７に記載のシステム。
【請求項９】
前記コアモジュールは素材、人、標準、設備、環境／施設、工程のグループから選択された少なくとも１つ以上のデータの次元に割り当てられることを特徴とする請求項７に記載のシステム。
【請求項１０】
前記薬は医薬品であることを特徴とする請求項７に記載のシステム。
【請求項１１】
コンピュータを用いて薬の製造過程を決定する方法であり、
コンピュータを用いて薬の開発に関連する情報を記録する工程と、
コンピュータを用いて複数の次元間のデータを関連付ける工程と、
薬の製造に使われる工程を決定するために長時間にわたって相互関係のあるデータをサーチし、薬の製造過程を決定する工程と、
複数の次元に基づいた知識システムを作成するため、製造過程を比較する工程と
を備えることを特徴とする決定方法。
【請求項１２】
前記薬は医薬品であることを特徴とする請求項１１に記載の方法。
【請求項１３】
薬の製造過程を決定するため、相互関係のある特定のコンテキストのデータを長時間にわたってサーチする工程を更に備えることを特徴とする請求項１１に記載の方法。
【請求項１４】
前記相互関係は、薬の製造に使われる過程を追跡するためにサーチ可能であることを特徴とする請求項１１に記載の方法。
【請求項１５】
前記相互関係は、薬の製造と開発に使われる過程を追跡するためにサーチ可能であることを特徴とする請求項１４に記載の方法。
【請求項１６】
前記相互関係は、薬の開発に使われる過程を追跡するためにサーチ可能であることを特徴とする請求項１１に記載の方法。
【請求項１７】
前記過程は薬の開発と製造に使われた素材と商品の完全性（integrity）、安全性、有効性の証明に使われた素材を含むことを特徴とする請求項１１に記載の方法。
【請求項１８】
コンピュータを用いて薬の商品履歴を記録する方法であり、
コンピュータを用いて薬の開発履歴をキャプチャする工程と、
コンピュータを用いて薬の製造履歴をキャプチャする工程と、
コンピュータを用いて開発履歴と製造履歴を記録する工程と、
薬の商品履歴である医薬品の製造履歴と開発履歴の多次元データセットを作成する工程と
を備えることを特徴とする記録方法。
【請求項１９】
前記薬は医薬品であることを特徴とする請求項１８に記載の方法。
【請求項２０】
薬の履歴を追跡するために前記多次元データセットをサーチできることを特徴とする請求項１８に記載の方法。
【請求項２１】
前記方法は薬の開発履歴を記録することを特徴とする請求項２０に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は規制される業界の管理に関する発明である。特に、この発明は厳しく規制される加工業界においての規制（regulatory）、納税（tax compliance）、在庫（inventory）、電子倉庫（e-warehouse）の管理を促進するものである。
【背景技術】
【０００２】
石油やガス、食品（例：農産物、加工食品、肉／鶏肉など）、飲料（例：蒸留酒、ワイン、ビール、ジュースなどの飲料）、化学薬品、消耗品（例：化粧品、スキンケアなど）、または医薬品（例：製剤原料として知られる化学薬品の開発等）、医薬開発（製剤としても知られる）、生物医薬品（製剤原料やジェネリック医薬品を含む医薬品等）の厳しく規制された加工業界にはいくつかの共通点がある。このような厳しく規制された加工業界では、製品の安全性と効率性を保ち、不正または有害な製品の販売を防ぐため、地域、国家または国際機関（例：食品医薬品局（ＦＤＡ）、貿易および税金部（財務省の貿易、税金部）によって厳しく規制されている。製品の安全性は、ある時点における製品記録を、開発、製造、販売の過程での他の時点における製品履歴記録と比較することによって証明される。しかしこの作業は、複雑で常に変化する製品を製造するこのような厳しく規制された業界にとっては、とても困難な作業である。したがって、これらの製品履歴記録に関する情報を管理しようとすると、さらに難しくなる。たとえば、これらの業界は哺乳類の細胞から分泌されたたんぱく質や、農作物のぶどうから生まれたグレープジュースなど、幅広い原材料を必要としている。
【０００３】
また、これらの“厳しく規制された業界”では開発から商品製造までの過程をすべて追跡できるようにし、第三者機関（ＦＤＡのような機関）の要求に応じて、ある時点から他の時点までの製品履歴を提供することが求められる。たとえば、メーカらは“製造しようとしている商品が実際に製造されており、主張する製造方法によって製造されている”ことを証明することが求められる。このような現場検査、会計検査、情報要求は、特定の原料、特定の過程について焦点を絞って行われることが多い。製品履歴の追跡ができない場合はメーカに相当な罰金や製造停止などが命じられることになる。
【０００４】
このような追跡に長期的に応えられない場合に加え、会計検査、ラベル、廃棄物、排気、安全などについての申請書を提出しなかった場合には重い罰金や、製造の延期／中止の対象となる。納税についても、商品の“製造量”と“種類”とによって金額が決まることになっており、そのため多次元の具体的な記録が必要となることから、適切な税金額を決定することはいまだに困難な作業である。
【０００５】
これらの業界では“処理が複雑化する傾向”にあり、商品は、複雑な混合、調合、製法などの過程の組み合わせを経て製造される。もうひとつの欠点としては、この業界の中には“文書化された履歴（paper trail）”といわれる具体的な製品履歴を求められる分野（例：医薬品、飲料分野）もある。このような履歴は、一般的にサプライチェーン上の中間生成物をすべて含む材料から完成品までのライフサイクルにおける完全な履歴を意味する。製品履歴に求められる情報としては次のような項目がある。すなわち、作業者とその訓練資格、加工材料、設備、基準、施設／環境情報等であり、これらは特定の記録のために、全体として広範囲な情報を形成している。
【０００６】
これらの業界は作業者、設備材料、プロセス（例：指導指針と実施、ワークオーダの生成など）を追跡する複雑な手順を有している。たとえば、原材料から中間物、完成品までの素材状態の追跡、または設備の履歴（調整、清掃、使用など）の追跡は複数の情報を必要とし、非常に複雑な過程である。これらの様々な情報は記録したり追跡したりするだけでなく、社内または規制する機関によって定められた標準値と対比されなければならない。さらに、これらの情報は時間の流れに伴う変化とも対比する必要がある（例：営業生産が９年目に行われるとすると、設備のセットアップ、調整、清掃、使用を記録し、８年目の同情報と対比して生産免許取得の資料としてＦＤＡに提出される）。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
これらの規制された加工業界は、完成品を製造する過程において複数の間接・投入品が生じ、これらの間接・投入・中間物もそれぞれ情報記録・追跡・比較処理の管理を要する。このような総合的な情報記録・管理は視認性（visibility）が要点となるが、現在ではすべての加工投入と商品履歴において視認性に欠けている。
【０００８】
現在のところ、これらの業界の工程管理における総合的な商品履歴などに要求される複雑な条件を満足させることができる広いウェブベース解決策は存在しない。実際、国家または州のレベルでの規制に使われる記録手段は、大抵、時代遅れの手作業によって行われている。
【課題を解決するための手段】
【０００９】
本発明は、規制された加工業界において原材料から完成品までのすべてのサプライチェーンに関わる情報の管理を可能にするシステムと方法について開示する。このシステムと方法は主原料がダイナミックに変化し管理が困難な規制商品に対する、大規模な記録管理を可能とする。本発明の実施形態は自動化された規則順守の機能や、税金報告機能などを通じて規制、納税データベースを容易に実現する。たとえば、規制管理と自動化された規則順守機能は、国家機関の提出条件（例：ＦＤＡ開発履歴、化学的製造とコントロール（ＣＭＣ）、医薬品製造免許に必要な薬学的開発（医薬品）提出条件）を順守することを会社が自動的に定義できるシステムによって実現される；すなわち、医薬品の開発段階におけるトレーサビィティの確立ならびに、会計監査、検査、製品の完全な調査に対処するのに必要な主要な情報の抽出が可能である。このシステムと方法はスマートインベントリ（smart inventory）、電子倉庫管理に関する解決法（e-warehouse management solution）と統合されている為、“候補選択から営業生産まで(candidate selection to commercial manufacturing)”の必需品の履歴情報が自動的に得られ、比較、相互関連、検定に適応できるようになり、国家機関への順守を定義することができる。たとえば、原材料、消耗品、中間物の完全な加工過程管理が定義できる。これらの原材料、中間物の各段階におけるこれらの情報は加工過程の完全な商品履歴を明示するための会社の記録管理要求に対して的確に利用される。これらの実施例は飲料、食品、石油、製薬、化学などの厳しく規制された業界に応用できる。
【００１０】
本発明は、原材料から完成品までのすべての必需品の履歴を管理する、完全にリアルタイムに実現されるウェブベースのサプライチェーンインフラを用いて、規則順守を目的とした設備を提供するものである。このシステムは地域、規則または税金に関する具体的な条件に対応できるように、業界ごとに十分なカスタマイゼーションが可能である。完全な商品履歴とは人、工程、素材（原料）、設備、環境・施設、基準（規則的また内部的）などの商品の開発と製造に不可欠な、次元に沿った主要な情報を含む。本発明は規則（水準）の管理を、自動化された規則順守機能や、税金報告機能、医薬品の開発及び製造に関する現在の在庫管理機能、を利用して可能にする。
【００１１】
本発明は、総合的な業界特異のサプライチェーンの規則順守アプリケーションを含む業界特異の規制、納税順守に関する解決法を提供するものである。本発明は現存する情報システム（例：ＥＲＰ、ＭＥＳ、ＬＩＭＳ、ＥＤＭＳなど）とともに動作し、補充アプリケーションとして提供されるように設計されている。
【００１２】
本システムにより、ユーザは、規制に関する申請（例：ＩＮＤ、ＮＤＡ、ＢＬＡ、ＡＤＮＡ）、納税順守、在庫（原材料、賦形剤、添加物、中間物、隔離または発売された完成品）の管理が可能になる。この特徴は、リアルタイムに実現されるウェブベースの企業全般のサプライチェーンインフラを活用することで、サプライチェーンの非効率的なところを減少させる。現在の面倒な履歴の文書化作業も大幅に減少させることができ、ユーザにとって、より正確でタイムリな順守が可能となり、規則違反や罰金などを回避することが可能となる。
【００１３】
本システムはこれらの業界の運営においての視認性を上昇させるサプライチェーン解決法を提供し得る。この特徴はリアルタイム情報に対する安全なアクセスを通して、より優れた情報管理と事前計画を可能にすることである。この特徴はユーザに安心できる管理システムを与え、コスト、在庫水準、運営資本のニーズを減らすことにある。このシステムは無線対応であってもよい。これによって重大な情報管理をさらに効率よく行うことができるようになる。
【００１４】
本システムは明確で総合的な商品履歴情報を提供して商品の妥当性を定義することができ、あるいは人、工程、素材、設備、環境・施設の基準などの次元上の商品履歴を（１つの時点から他の時点まで）追跡することができる。
【００１５】
柔軟にスケール変更が可能であるプラットフォームにより、本システムはサプライチェーンインフラをもとにしたリアルタイムのウェブベース規制納税順守を実現することを可能にすると同時に、規制納税順守、在庫管理、内容物管理、サプライヤカタログ管理モジュールを提供する。調達、発送管理、申請及び予想ツールと規制的な電子申請は、サプライチェーン解決法を補完する。
【００１６】
本システムは色々なサードパーティの企業資源と接続し、アプリケーションと既存のレガシーシステムを立案できる。本システムはｏｐｅｎ  ＡＰＩを利用したＪａｖａをベースとすることができ、拡張性に優れ柔軟性を備えた強力なモジュラであり、携帯性に優れている（ＰＤＡ、無線対応）。本システムは小型軽量クライアントを利用するため、ウェブブラウザだけを必要とし、デスクトップのインストールを要しない。本システムはブラウザとサーバとの送信を保護するためにセキュア・ソケット・レイヤ（ＳＳＬ）をサポートすることができる。さらに、ユーザのＩＤや暗証番号の保護、ならびにユーザによるコントロールも組み込むことが可能である。
【００１７】
本発明のシステムはコアプラットフォーム（core platform）とモジュラを利用して長時間にわたって多次元の情報記録を管理することができる。例えば、医薬品製造業界の素材管理機能がシステムと方法で提供される。具体的に、薬物の一連の管理には、例えば原料、試薬、溶媒、中間物、バルク（bulk）、ファイナルＡＰＩ（final API）が記録される。本システムは素材類ごとにすべての関連情報（ＣＯＡ’ｓ  Ｓｐｅｃｓなど）を管理する。発送センタから完成品の“錠剤”までの素材追跡はすべての素材に関する様々な情報（誰が、何を、どこで、いつ、どのように）が確信を持って提供される。
【００１８】
また、原料を作成したり、場所を指定（locate）したりすることも可能である。素材の要請、注文、在庫、販売、処分、移動などがわかる。一連の書類の状態（status）、サインオフ、警報、認証、電子署名、事故プロフィル（hazard profile）の使用を通して記録される。このような類似の機能は長期的な医薬品開発におけるすべての次元に導入されている（既に説明済みであるが、以下でも説明する）。
【００１９】
商品の品質は本システムによって管理することができる。原材料認定ＩＤと使用テスト、さらには原材料仕様書も記録される。本システムによって原材料の性質（例：評価日付、純度）による区別、追跡ができるようになる。
【００２０】
本システムは製造過程に使われる設備の管理を行うこともできる。設備の使用のための予約、または設備の性質、使用頻度、有効性などを見ることができる。その上に、設備使用、貸借、閉鎖も追跡することができる。設備のメンテナンス、掃除の追跡も可能である。
【００２１】
以下にリスト化された図面を参照しながら、下記の好適な実施形態についての詳細な説明を参酌することにより、当業者であれば、本発明の各種の実施形態に記載された効果や利益ならびに、他の効果や利益を理解することができよう。
【発明を実施するための最良の形態】
【００２２】
図１は在庫管理モジュール１００、規則モジュール２００、コンテンツ管理モジュール３００、カタログ管理モジュール４００、プロセスモジュール５００、サプライヤモジュール６００、コアモジュール１０００などを備えた商品適合（conformance）管理システム５のブロック図である。業界ごとにモジュールの数と種類が異なることは当業者にとっては自明である。たとえば、製薬業界では素材管理モジュール、設備管理モジュール、標準モジュール、方法実施モジュール、追跡可能性モジュールなどが含まれる。ここでは、ある特定の業界の解決法は一群のモジュールからなる複数のパッケージソフトから成り得る。モジュールはそれぞれプラットフォーム上に単独で配置可能である。複数のモジュールを用いることによって、解決法を容易に分散させることができ、顧客サイトに段階的に拡張することができる。
【００２３】
在庫管理モジュール１００は製薬業界のニーズに合わせたその業界特異の情報を持つ。特に、在庫管理モジュールは製造工程における原材料及び出発原料の動きを記録する。さらに、在庫管理モジュール１００は製造工程における在庫の追跡に加え、企業の素材（原材料、中間物、バルク（bulk）、完成品）の在庫を、場所を問わず子会社または企業レベルで調べることができる。在庫管理モジュール１００は再注文と順守要求のために設定された在庫閾値を導入し、システム、メール、ポケベルまたはＷＡＰなどを通して通知を送る。在庫管理モジュール１００は製造者とサプライヤの両者により在庫レベルが調べられるようにしている。在庫管理モジュール１００は商品の受け取り、発送、返品、移動、位置確認などの情報を提供する。従って、在庫管理モジュール１００は全開発過程を経て製造過程にいたるまでを商品管理することができる。
【００２４】
規則モジュール２００は医薬品製造に関する国家または州の複雑な規則順守のニーズに対応する。規則モジュール２００は製薬業界に影響を及ぼす最新の規則、税金順守情報を提供する。この規則、税金データベースは自動化した順守機能と納税報告機能も含む。規則モジュール２００は食品医薬品局（ＦＤＡ）、州機関（地域機関）、または他に存在するオンラインの法的情報源につながって、このデータベースを形成する。規則モジュール２００の重要な要素は化学的、生物学的またはジェネリックの物質について研究新薬の申請の提出過程を軸として構成されている。モジュール２００はプラットフォーム（コアモジュール１０００）との組み合わせで、開発と製造の商品電子履歴記録（ｅＰＨＲ）を作成することができる。現在、この商品履歴記録は、製薬業界の開発環境（電子開発記録（ｅＤＲ）と呼ばれる）または商業生産（電子商品履歴記録（ｅＰＨＲ）と呼ばれる）において固有のものとなっている。
【００２５】
ｅＰＨＲとｅＤＲは、両方とも長期にわたる開発における様々な次元に関する重要な情報を有するシステムにおいて高価な記録機能を用いて自動的に作られる。開発の次元とは、人、工程、素材、設備、標準、環境・施設を含む。ｅＰＨＲとｅＤＲは化学的、生物学的構造以外の状況を提供し、開発と製造上の上流または下流の情報を取得し、異なる複合物、段階、状況などに関連する商品履歴の比較を可能にする。新しい化学的、生物的構造が識別されると候補選択システム５はさまざまな次元に沿って重要な情報を取得し、自動的にｅＰＨＲとｅＤＲを作成する。
【００２６】
ｅＰＨＲとｅＤＲはより高い視認性と効率で、国家機関の許可前の検査と許可後の検査を効率的に処理し、より簡単に薬の使用の許可を得て、より上質な商品の製造を可能にする。さらに、ｅＰＨＲとｅＤＲは現地あるいは遠隔の会計検査をパスでき、許可後の変更項目の提出をより早く効率的に行うために、必要な情報を表示することができる。ｅＰＨＲとｅＤＲは医薬品の開発と製造の両方において“仕様範囲外（out of specification incidence”（ＯＳＳ）の事態に対し、より早い改善された解決法を提供する。ｅＰＨＲとｅＤＲによって長期間にわたる、あるいは商品の寿命期間にわたる開発の状況や局面が保存された複雑な情報の集合を構築することが可能になり、最終的にはこのシステムを利用する会社は、より深い“工程の理解（process understanding）”ができることを期待することができる。認証されたユーザはｅＰＨＲ／ｅＤＲのどの要素についてもサーチ、回収、分析、関連付けを行うことでき、工程のより深い理解が得られる。
【００２７】
コンテンツ管理モジュール３００は書類、在庫警報、仕様書、分析証明書（ＣＯＡ）、方法、標準などの業界特異、会社特有、またはサプライヤ特有の情報（会社固有かつ内部／外部機関固有の情報であってもよい）についての関係型データベースである。
【００２８】
商品販売を行うサプライヤは通常、オンライン上で、あるいは、ハードコピーとして、何がしかのカタログを有している。カタログ管理モジュール４００は製造者に対して複数のサプライヤの類似した商品を統合して提供し、商品の素材リスト、商品それぞれのコスト、入手に関する商品情報、隔離／発売情報も備える。
【００２９】
プロセスモジュール５００は医薬品の製造過程の様々な段階より情報を取得する。これらの情報は活動記録やラボ分析記録を包含する。これらの記録は素材の全ての段階で（原材料から中間物、大量商品（bulk product)、完成品まで）規則順守、会計検査のために追跡ができるようになっている。プロセスモジュール５００は指導指針と実施を通して膨大な記録管理ができるようにし、全ての工程段階、係わる人々、使用される設備、素材使用／段階、基準、ラボの状況、施設の位置の情報などを関連付ける。この工程情報が完結することで“厳しい規制”の対象となる化合物の物理的、化学的な特性をより効率よく管理できるようになる。化学、生物学的構造を上記方法において処理工程とリンクさせることによって、システム５は規制される加工業界（例：製薬）をより効果的に管理することができる。さらに、化学物質に適用された方法は同じく生物医薬品やジェネリック商品にも適用することが可能である。
【００３０】
サプライヤモジュール６００は会社／ユーザにサプライヤとそれに関連するカタログや購入した商品などの管理、さらには取引のコストまで管理できる機能を与える。たとえば、製薬業界の原材料、賦形剤、出発原料などの入手は長期にわたって複数の段階で発生する。原材料の入手は候補選択から営業生産までにわたる開発の過程の流れによって変化しなければならな（例：候補選択の段階での原材料の純度は営業生産の段階よりはるかに高い）。よって、原材料一つ一つに関する情報は開発の流れとともに、“リアルタイムに（in process）”捕らえる必要があり、この情報はサプライヤから“分析証明書”という形で提供される。これらの情報／記録管理は異なる時点で比較できるようにならないといけないため、会社側はこれらの情報を記録し追跡する必要がある。現在ではこの追跡は手作業で行われており、面倒な作業である。サプライヤモジュール６００はコアモジュール１０００とともに、このような情報を自動的に追跡、記録するシステムを形成する。
【００３１】
コアモジュール１０００（“製品の整合性管理（ＰＣＭ）”とも呼ぶ）はシステム５の基盤モジュールである。コアモジュール１０００はシステム５の機能を実施するものであって、顧客の様々なビジネス、規制プロセスにあうよう設定可能な共有プラットフォームである。コアモジュール１０００は顧客の規制プロセスに関する材料、設備、工程、社員、基準、環境についての情報をすべて管理する。コアモジュール１０００は顧客の要求に応じてすべての特性をダイナミックに定義する。コアモジュール１０００は有効な値（範囲、または目録）を与え、データのタイプ、値生成のアルゴリズム（ある場合のみ）を定義する。コアモジュール１０００は値の単位も定義し、様々な単位間の転換もサポートする。
【００３２】
さらに、コアモジュール１０００はすべての情報オブジェクトの状況、許可のためのワークフロー、状況の変化（例：ダイナミックで変わりやすい変化の管理）などを管理する。敷地、場所、組織的な上下関係もコアモジュール１０００によって管理される。コアモジュール１０００はユーザ、ユーザグループ、ユーザ機能を管理し、警報の設定と警報を要求したユーザへの通知のためのインフラを提供する。コアモジュール１０００は認証されたモードでソフトウェアシステム間のデータ移動を行い、政府の規則に順守することを確認する（例：２１  Ｃ．Ｆ．Ｒ  パート１１）。さらに、バージョニングサポートもコアモジュール１０００に提供されている。コアモジュール１０００はシステム内にキャプチャされたデータ変化の監査証跡、システム内の情報オブジェクトに対する添付ファイル、またはシステム内の情報オブジェクトに添付される多数の記録（notes）も生成する。
【００３３】
システム５の安全性を保つため、コアモジュール１０００はユーザ確認と暗号の組み合わせのログインによりアクセスを提供としている。３回ログインに失敗するとユーザアカウントが無効になり、管理者に通知される。ユーザアカウントを再び有効化できるのは管理者のみである。加えて、ユーザ名、メールアドレス、電話番号、システム使用開始日、ユーザの居場所などの詳細な情報は、コアモジュール１０００によって保持される。ログインサービスはユーザがアクセスによって許可されたシステム５のアプリケーションとアクセスによって許可された役割を確認する。
【００３４】
コアモジュール１０００はさらに外部システムによってユーザが認証できる外部認証サポートも提供する。この外部サービスはユーザ名と暗号を入力することによって呼び出される。コアモジュール１０００はシステム５の認証プロセスのようにログイン成功とログイン失敗の管理が可能である。外部認証を利用する場合はすべてのアカウントと暗号の管理は外部サービスによって処理される。
【００３５】
システム５はアクセスに関するさまざまな役割を果たすことができる。これらの役割は企業内の個人の機能的役割と一致していなくても良い。システムによって定義されたこれらの役割は主にシステムの多様な機能へのアクセスを管理することに使われる。これらの役割はひとつのアプリケーション、複数のアプリケーションの組み合わせ、または全アプリケーションに対応することができる。またこれらの役割は特定の地域にも、または企業全体にも対応することができる。ユーザはシステム内で１つ以上の役割を持つことができる。この役割というものはアクセスできるシステムの機能を特定し（例：メニューアイテム、スクリーンなど）、さらにこれらのアクセス可能な機能上で実施できる作業（例：読み、書き、アップデート、削除、リストなど）を特定する。役割はアクセス可能な区域／属性を定義する。
【００３６】
システム５への記録の入力を認証するため、コアモジュール１０００はユーザのサインを受け取るジェネリックな（一般的な）方法を電子的にサポートする。このサービスは電子サインの必要が生じるとアプリケーションによって起動される。ユーザはユーザ名と暗号を要求され、その情報が確認される。電子サインを一貫して（consistently）簡単に実施するために再利用できるユーザインタフェースが利用できる。この再利用できるコンポーネントはパラメータとしてユーザ名を受けとり、この情報をユーザインタフェースが現れるたびに自動的に入力しておく。これはサインが連続的に要求されるときの補助機能である。それぞれのサインはユーザによって認定あるいはサインオフされた動作と情報とに対応して保管される。
【００３７】
警報はシステム５には非常に重要である。警報は多くのアクティビティと事前通知に使われる。したがって、この警報は大きな拡張性を持ち、ジェネリック（一般的）である。
【００３８】
それぞれのアプリケーションは警報と関連付ける項目（例：作業命令、材料入荷、設備スケジュール等）と、その項目（オブジェクト）に対する種々の属性に関する数値の変化のうち、警報につながるような数値の変化を特定する。警報を出すために行う属性の比較方法は指定することができる。すべての一般的な比較方法（例：同等、不等、以上、以下、範囲、リストなど）がサポートされている。
【００３９】
警報を誘発するような動作には、オブジェクトを変える動作（作成、編集、削除）と時間によって発するトリガ（期限切れのアクティビティの確認）とがある。警報の状態に達すると任意にカスタムコードを実施させることも可能である。これは、通知書の生成が必要な場合に、算定論理を埋め込むために役に立つ。
【００４０】
展開されたシステムにおいて、管理者はシステム５のユーザたちが閲覧することができる警報を発行することができる。これは警報を受信することができるユーザ／役割を特定することによってなされる。発行はジェネリックシステム全般的な発行／受信（購読）メカニズムを介して実現される。
【００４１】
ユーザが警報を受信（購読）しようとすると、そのユーザと役割に合った警報だけがリストされる。ユーザは受信したい警報だけを選び、そのために必要な情報を登録する。ユーザインタフェースを介し、ユーザは受信する時の正確な条件を選ぶことができる。ユーザはオブジェクト（項目）とそれに関する属性を選択することができ、それぞれ警報発生の基準となる数値を指定する。ユーザのオブジェクトレベルの許可によって、ユーザはアクセス許可を持っている属性のみに関して通知の基準を指定できる。
【００４２】
ユーザは通知の配達方法を選択することができる。通知はシステム５のユーザの個人警報リストに配達される。加えて、ユーザはメールで通知をもらうことを選択することもできる。ポケベルや携帯電話にも通知が送られることは明らかであろう。
【００４３】
ユーザが警報を確実に受信することはシステム５の主な責任の一つであり、従ってコアモジュール１０００の責任でもある。システム５のそれぞれのページ上の警報領域はコアモジュール１０００によって作られている。警報領域は警報とその通知の特徴的な属性とを識別する。ユーザがシステム５のアプリケーションを使用中である場合は、警報領域はユーザに承認されていない最新の通知を常にアップデートする。
【００４４】
全ての通知は警報通知専用のインタフェースを通じて閲覧することが可能である。ユーザはこのインタフェースを通じて通知に関係ある詳細な記述を見ることができ、またこれらの通知を管理することもできる。ユーザは通知を見たことを確認することによって警報領域にディスプレイされないようにしたり、削除したりすることが出来る。
【００４５】
システム５のアプリケーションは、複数の商業企業のアプリケーションやニッチ商品、または会社内カスタム解決策と共存する必要がある。アプリケーションを連続的に起動し、電子商品開発の倉庫を実現するためにはコアモジュール１０００は他のシステムと簡単にデータ交換できなければならない。そのため、コアモジュール１０００は融合の際に用いる融合フレームワークを提供する。このフレームワークは次の条件に従う。
【００４６】
ミドルウェア独立性：ベンダ特有のミドルウェア商品に基づく条件を持たない。エンジニアはユーザに指定されたどの外部システムでもミドルウェア（例：ＴＩＢＣＯ、ＷｅｂＭｅｓｈｏｄｓ、ＳｅｅＢｅｙｏｎｄ、Ｖｉｔｒｉａなど）でも通信することが出来るフレームワークを構成することができる。ウェブサービスやＪＭＳのような業界標準のみをサポートする。
【００４７】
ＸＭＬデータフォーマット：システム間に伝送されるデータは業界のトレンドに従ってＸＭＬ形式にインコードされる。既存の業界標準仕様であるＷｏｒｌｄ  Ｂａｔｃｈ  ＦｏｒｕｍのＢａｔｃｈＭＬをサポートすることもできる。
【００４８】
融合イベントによるトリガ（制動）：フレームワークは、データ修正トリガまたは周期的なバッチモードアップデートに基づいて、リアルタイムでデータを移動させることが出来る。融合フレームワークはジェネリックな（一般的な）システム全体の警報通知フレームワークに組み込んでこの役割を果たす。
【００４９】
バックエンド（アプリケーションレベル）融合サポート：イベントトリガ（発生）に基づいて、フレームワークはウェブサービス、ＵＲＬ（ｈｔｔｐ  ｐｏｒｔ）、ＪＭＳサーバに、データを提供することができ、場合によっては連続的にラベルされたファイルを通じた単純なエクスポートで、データを提供することが出来る。融合フレームワークはウェブサービスやＪＭＳサーバを通じてデータを受け入れることが出来る。
【００５０】
データ交換の双方向性：システム５はシステム外にデータを公表することができ、さらにシステム内でデータの挿入、修正を行うこともできる。
【００５１】
記録システムの同定：システム５はアプリケーションのリストを規定することができ、さらに別個のデータアイテムを記録するマスタとして特定のシステムを同定することができる。
【００５２】
組織（organizational）マッピング：一般的には、交換されるデータの状態（context）を提供するのに組織ユニット名が必要となる。特定の組織ユニットに与えられた名は外部の異なるシステム間、またはシステム５内のシステム間において異なることがある。コアモジュール１０００はこれらの名を整理するマッピング方法を提供する。このマッピングは単純な１＜−＞1マッピングではない。
【００５３】
属性マッピング：１つのデータアイテムは２つの異なるシステムによって２つの異なる名で認識されることがある。このフレームワークは一般的な（ジェネリックな）マッピング機能を提供する(たとえばミドルウェアなしに融合が行われる場合）。マッピングは展開中または展開後、現場で設定可能でなければいけない。マッピングセット識別子を用いてマッピングの複数のグループを特定の外部システムと関連付けることも必要である。
【００５４】
ＵＯＭマッピング：パラメータのデータは、情報源システムのデータアイテムの単位とターゲットシステムが予期する単位とが異なることがある。融合フレームワークはこのような状況を対処するメカニズムを持たなければいけない。マッピングは展開中または展開後、現場で設定可能でなければならない。マッピングセット識別子を用いてマッピングの複数のグループを特定の外部システムと関連付けることも必要である。
【００５５】
後方互換性：このフレームワークは公表のｏｐｅｎ  ＡＰＩを定義する。ＡＰＩのマイナな修正バージョン変更はＡＰＩを用いて作られた融合機能を変更する必要がないようにしなければならない。
【００５６】
性能と拡張性：取引はシステム５によって処理された取引の数に正比例して処理する必要がある。理論上はシステムのどのオブジェクトを編集しても融合フレームワークを介してデータの移動が生じる可能性がある。融合フレームワークによる端末相互間の遅延やスループット経費は実際のユーザが経験する端末相互間の総合的な遅延やスループット経費には大きな影響は及ぼさない。
【００５７】
ロギング：データ交換のイベントはデバックの際に発生したエラーとともにフレームワークによってロギングされる。任意的に、デバックのログはデータの動きを追跡するのに利用することができる。すべてのログはユーザが指定したところに移動され、事項管理を行っている。ログファイルが設定されたサイズに至るとそのファイルを閉じ、アーカイブするために改名し、引き続き新しいファイルに記録する。
【００５８】
管理サポート：このフレームワークは管理者に作動中の構成された融合（integration）（例：メッセージが受信、公表されているオブジェクトであること）をすべて確認し、それらの状態（health）を監視するためのインタフェースを提供する。
【００５９】
システムの設定自由度：交換されるデータ、データのマッピング、交換の方向などは顧客のニーズに応じてシステムが起動するときに設定することができる。設定は設定ファイルの特定のエントリ、あるいはグラフィカルユーザインタフェースによるデータエントリに限定することも可能である。
【００６０】
システム５の一つの目的は、情報の共有を可能にすることである。データベースを基にしたシステムはこの機能を簡単に得ることができるが、ユーザまたは外部インタフェースに複数の異なる情報を具体的に送達しなければならない状況が生じる場合がある。これを可能にするために、システム５はジェネリックな（一般的な）システムを提供し、情報を公表、閲覧可能にする。当該メカニズムは公表の候補となる様々なオブジェクトをアプリケーション内に登録する機能を有している。このオブジェクトとは警報、スコアーカード、報告、データパッケージなどである。公表の規則は公表されるオブジェクトの種類に基づいて作られる。システムは三つの公表の種類をサポートする。
―システムによって規定されたもの：システム内に設定され、移動できない
―管理者によって規定されたもの：管理者のみ管理可能
―エンドユーザによって規定されたもの：エンドユーザが管理する。
【００６１】
公表する時は閲覧の許可を持つユーザ、ユーザグループ、役割を確認することが可能である。システム内のすべてのユーザはこれらに公表された様々な警報を調べることができ、どれを閲覧するか決めることができる。さらに、ユーザの付加的な情報を提供することによってどのような内容を希望するか同定することも可能である。たとえば、警報について閲覧を申し込む際、通知を発生させる条件を提供することができる。
【００６２】
ワークフローはシステム５によって提供される重要かつ決定的なサービスのひとつである。どのビジネスにおいても、プロセス、機能、役割は常に変化するものである。オブジェクトにルートを与えるためシステム内のどのオブジェクトに対しても状況及び経路情報を関連付け、ワークフローを使うことが可能である。システム５はオブジェクトに対しデフォルトのワークフローや作動モード固有のワークフローのいずれもサポートすることができる。
【００６３】
アプリケーションプログラマーはワークフローにかかわるオブジェクトをアプリケーションの中に登録することができる。アプリケーションは自らが持つ内部ロジックに基づいてワークフローを起動できる。ワークフローサービスはオブジェクトの現在の状況を決定し、その状況に応じたワークフローを介してオブジェクトを広める。状況のシーケンスはユーザによってシステム５のトランザクション層に定義され、コントロールされている。  ワークフローはユーザをシリアルルートで結んだり、複数のユーザを並行に一人のユーザに連結させることが可能である。さらに、ワークフローはユーザに対して、またはユーザの役割に対して、ルーティング後、またはルーティング中に同期化させることが可能である。動作してもオブジェクトの状況が変化しないようなオブジェクトを任意の受信者へルーティングすることも可能である。ワークフローは、第一許可者からある時間以内に返事がこない場合、バックアップ許可者にルーティングすることも可能である。エンドユーザはオブジェクトにいたるまでのワークフローや現在のオブジェクトのワークフロー上の位置を見ることができる。
【００６４】
アプリケーションがルーティングのためにオブジェクトを提出する場合、ワークフロー管理者は現状を確認し、次の順番のユーザに警報を発する。ユーザは、オブジェクトの‘位置（locate）’ページやユーザのホームページ、ワークスペースの待機アクティビティリストからオブジェクトの位置を確認することによって、警報通知に含まれるハイパーリンクから直接オブジェクトにつなげることができる。
【００６５】
ユーザがオブジェクトを見つけると、オブジェクトに対する命令（action）のリストが表示される。これらの命令はオブジェクトに対して定義された状況変化シーケンスによって決定される。
【００６６】
多くの業界は文書によって仕事を進めていく。ユーザの必要な情報が文書形式でしか存在しないことは頻繁に起こることである。また、システムのどのオブジェクトが添付情報を持つか予測できないことが多い。このような問題を解決するにはユーザの作成許可の範囲にあるすべてのオブジェクトに文書を添付できるジェネリックな（一般的な）フレームワークが必要となる。ユーザはローカルシステムのファイルの中からサーバ上において制御される共有領域（controlled shared area）にアップロードすべきファイルを識別できなければならない。プライマリオブジェクトを閲覧する許可を持つすべてのユーザは添付情報も閲覧することができる。１つのオブジェクトが持つことができる添付情報の数には制限がない。ローカルシステムはビューアが添付情報を表示できるようにしている。
【００６７】
アプリケーションプログラマはライフサイクル管理のため、オブジェクトの種類を登録できる。この登録によりその種類のすべてのオブジェクトが会計監査証跡を持つことが確保される。プラットフォームを将来公開する際には、ユーザインタフェースを使ってオブジェクトを再現することができる。また会計監査証跡に収集されるすべてのオブジェクトの種類を、システム内の一箇所で決定できる。
【００６８】
システム５のすべてのオブジェクトはそれぞれ日時スタンプを有している。このスタンプは秒単位の正確度を有している。ユーザがどの場所にいるかにかかわらず、システム内のすべてのオブジェクトに対するスタンプは、同じ時間帯の時間を記録する。発生するイベントの順番に不明瞭なことがあってはならない。
【００６９】
コアモジュール１０００のデータモデル層はシステム５のアプリケーション開発者やシステムの主なオブジェクトを決めるエンドユーザに高い自由度を与える。データモデル層はフレームを提供し、これによりシステムの展開後（after deployment）であっても拡張を必要とするシステムの様々な要素（dimensions）を構築することができる。システム５は新しいオブジェクトのセットを定義する機能を提供し、それらに属する分類階層（hierarchy）を生成する。アプリケーションプログラマーはジェネリックなアクセス機能を使ってオブジェクトを操作したり、専門化したビジネス理論を適応するための特異的なオブジェクトを定義したりすることができる。この層に存在するアプリケーション内の機能を実行するために、再利用可能なユーザインタフェース要素も用意されている。
【００７０】
階層のどの位置でも新しいオブジェクトのジャンルを加えることが可能である。新しいジャンルを加えるにはそのジャンルの階層における位置を同定し、独自の識別子を与えることが必要になる。ジャンルの名前は、属する階層において固有の名前でなければいけない。
【００７１】
階層に新しいジャンルが加わると、このジャンルの属性を定義することが可能になる。ユーザは属性の名、データの種類やサイズ、属性の値が固有のものであるか否かの識別、属性のデフォルト値の定義を提供する必要があり、また列挙された正当な値、ならびに値の範囲を定義する必要がある。一般的には、新しいジャンルはその階層の属性を引き継ぐことになる。
【００７２】
システム内のオブジェクトに関してそれぞれの次元ごとに情報があるのは有用であるが、その次元間の関連付けが可能であることも重要な要件である。システム５は電子開発記録の倉庫であり、様々な次元の関係を追跡することが主な役割のひとつである。アプリケーションプログラマーはオブジェクト間の関係やその関係の属性を登録することができる。このコンセプトを拡張して適用することで、追加の関係を展開タスク（deployment task）の一部として生成することが可能となる。
【００７３】
コアモジュール１０００とそれに基づいて生成されたアプリケーションの動作はシステムに設定された操作モードによって異なる。操作モードはオブジェクトに関連したワークフロー、オブジェクトが通過する状況、またはデータの検証規則を決定するひとつのキーファクタである。コアモジュール１０００はシステム５の数々の操作モードを定義する。アプリケーションは操作モードを用いて動作を判定する。
【００７４】
属性についてのデフォルト値と正当値は様々な次元のデータモデル層に対して定義することができる。しかし、これらの値は操作モードによって変更される場合がある。さらに、取引にかかわるデータの検証も操作モードに依存するものである。これによって、操作モードによる検証基準を定義するサービスを提供するプラットフォームが必要になる。そのような基準がこの層において提供されない場合は、データモデル層の基準に初期設定することになる。
【００７５】
ワークフローを通過する必要があるすべてのオブジェクトは状況変化の順番を定義することができる。状況の順番は操作モードや場所によって異なることがある。また状況の順番もかえることができる。そのような変化が生じると、オブジェクトの過去の状況の順番を正確に測定するため、その変化が起きた順番をひとつのバージョンとして記録しておく。
【００７６】
電子開発記録のような巨大データセットに必要なレポートや計算などを予測するのは難しい。コアモジュール１０００はこの複雑なデータにアクセスするための様々な簡略な方法を提供するための‘位置決め（locate）’機能を有している。多くの業界ではＥｘｃｅｌを好んで使用されているため、これらのサーチから得られたデータをＥｘｃｅｌにエクスポートできる機能を備えている。
【００７７】
システム５内のそれぞれのアプリケーションはレポートを定義することができ、ある役割と関連付けることが必要である。これらのレポートはこの役割を割り当てられたユーザが利用できるようになっている。レポートは一般的に外部レポートライターによって定義され、対応するレポートジェネレータによって実行される。新たなレポートのニーズは大半の会社で定期的に生じる。したがって、システムに継続的に新たなレポートを加えることができること、ならびに、それらのレポートとシステムにおいて定義された役割との関連付けが可能であること、が要求される。これによって、ユーザがログインすると確実にユーザ選択のレポートが自動的にアップデートされる。
【００７８】
ユーザは要求されるレポートのサーチ基準を提供できるようにする必要がある。これによってユーザは所望のサブセットに対するレポートを受け取ることができる。システム５のアプリケーションは、関連のあるデータパッケージをアプリケーションにあらかじめ定義することができる。これらのパッケージは所定のレポートのコレクションであり、システム内のスコアカード、チェックリスト、サーチ基準を含んでいてもよい。パッケージが定義されると、公表も可能になり、プラットフォームのジェネリックな公表／閲覧サービスを利用して公表、閲覧ができる。
【００７９】
コアモジュール１０００はダッシュボードを定義するジェネリックフレームワークを提供する。これらのダッシュボードはシステムにあるオブジェクトの種類に基づいて総計視界（aggregate visibility）を提供する。ダッシュボードのプライマリオブジェクトは、特定の場所に固定された設備、特定の場所において現在アクティブなチケット、特定の場所のアクティブなプロジェクト、特定の場所の原料ステージ要求、特定のキャンペンの様々なステップなどのオブジェクトである。
【００８０】
ユーザは、ダッシュボードから任意のオブジェクトの詳細な情報に関して掘り下げることができる。ダッシュボードは他の関係するオブジェクトにつながるリンクを表示し、ユーザが関係のある情報を検討できるようになっている。どのアプリケーションへのアクセスに対しても最も一般的なポイントであるように使い勝手や情報集合が設定されている。
【００８１】
システム５のアプリケーションは世界的な経営を行う大企業に使われる。これにより世界の様々な場所で定められた現場の基準によるばらつきをサポートするという要求に対応することができる。コアモジュール１０００とシステム５のアプリケーションは国際化され、ユーザ指定のデータ形式（ｄｄ／ｍｍ／ｙｙｙｙ、ｍｍ／ｄｄ／ｙｙｙｙ、ｄｄ−ｍｍ−ｙｙｙｙ）、ユーザ指定の時間形式とゾーン、ユーザ指定の１０００ｓ分離機や基数点、またはユーザ指定の測定のユニットをサポートできる。このシステムは設定の自由度が高く、ユーザインタフェースの固定的な部分となるすべての設定情報は、特定地域に適用できるように変更可能である。
【００８２】
コアモジュール１０００とそれに関係するアプリケーションによって収集された情報は、分類される情報間の関連付けが可能となるデータモデル層に保存され、分類される。具体的に、データはすべての主な開発活動を代表する複数の次元に則して保存される。図４に示すように複数の次元としては人４００ａ、素材４００ｂ、工程４００ｃ、環境／施設４００ｄ、設備４００ｅと基準（標準）４００ｆがある。次元の違うラベルを与えることは当業者には簡単にできることである。それぞれの次元はシステム５で記録された情報の種類、属性、状況を分類する。たとえば、設備次元４００ｅと素材次元４００ｂは種類を分類し、設備と素材の属性と階層を定義する。さらに、設備次元４００ｅと素材次元４００ｂは設備と素材のデフォルト限度と正当値を設定する。人次元４００ａは人の役割やグループを分類し、役割の階層や特権アクセスなどを定義する。工程次元４００ｃは工程を分類し階層を定義する。さらに、工程次元４００ｃはワークフローやビジネス規則をセットし、ワークフローのテンプレートを作成する。環境次元４００ｄは環境の種類を分類し、属性や階層を定義する。これは工程が実行される実際の施設も含む。デフォルトの限度や値または環境参考基準は、この環境次元４００ｄに設定されている。基準次元４００ｆは基準を分類し構成データ基準を作ることができる。さらに、基準次元は参考文献や所定の工程などを分類できる。
【００８３】
異なる次元間において関連性を持たせることで、データを取捨選択することができる。たとえば関連性は、関連情報、比較、検証、レビュー状況、コンテキストなどのサーチに使われる。この関連性の情報のコンテキストを把握するため、多くのイベントにおいて、あるいは長時間にわたって使用できる。たとえば、図４の人、工程、環境、設備の次元４００は情報のコンテキストを与えるため関連付けられている。あるイベント（例：条件）に関する情報はいつでも見つけることができる。コンテキスト、関連性、次元データ構成は素材の電子開発記録（ｅＤＲ）のサーチを容易にする。この点において電子開発記録は警報や通知、製造過程の操作管理、知識管理、開発履歴記録を提供する。
【００８４】
ｅＤＲは時間とともに工程の理解と、工程固有のステップ、素材、化学的または生物学的物質の構造とを関連付ける。
【００８５】
図５はコアモジュール１０００のプラットフォーム概観５０１を図示したものである。プラットフォーム概観５０１はコアモジュール１０００のための４層のアーキテクチャを図示している。具体的に、コアモジュール１０００は分析層５００、トランザクション層５０２、データモデリング層５０４、共有サービス層５０６を有している。コアモジュール１０００は商品記録のベースのためのサービス、機能、データモデルを提供する企業全体のプラットフォームを開設する。このアーキテクチャはオープンスタンダードで複層的な企業のアーキテクチャのためＪ２ＥＥテクノロジを活用する。さらに、このアーキテクチャはアプリケーションの開発のため公開されたインタフェースを提供し、オープンインタフェース、ウェブサービス、ＸＭＬを介しての相互運用性を確保する。
【００８６】
分析層５００はデータパッケージ５１０、ダッシュボード５１２、スコアカード５１４、レポート５１６を含む。分析層５００は所定のレポート、データパッケージ、スコアカードを提供する。さらに、分析層５００はダッシュボードの見易さとルールベースのレポートやインジケータを確保する。
【００８７】
トランザクション層５０２はコンテキスト管理５１８、操作モードマネジメント５２０、トランザクション管理５２２を有する。トランザクション層５０２は所定のビジネス課程、書式テンプレートを提供し、最良の実施形態を実行する。さらに、トランザクション層５０２はシングルユーザ用のインタフェース、製造中のロット追跡性、進行中の視認性を提供する。
【００８８】
データモデル層５０４は相互関係モデリング５２４と次元モデリング４００を含む。データモデル層５０４は一回のみ設定する必要があり、マスタライブラリを含むものである。データモデル層５０４は拡張、延長が可能であり、関連するコンテンツの中央収納を提供する。この点において、データモデル層５０４はすばやく展開され再利用を推進する。
【００８９】
共有サービス層５０６は、安全性、データ管理、公表と閲覧サービス、サーチサービス、フレームワーク融合を提供する。
【００９０】
図２は規制された業界に対するサプライチェーン解決法を実現するインフラを提供する本発明の一実施形態における操作を示す概念図である。サプライチェーン解決案１０は、ユーザが心配せずに在庫や、製造などの管理ができる１以上のアプリケーションを提供し、ウェブサイト１２とともに使われる。システム２２を持つユーザはウェブブラウザ２６を用いてインターネット１６や他のネットワークを介してウェブサイト１２とオンラインで（または他の方法で）インタラクションができ、製造の状況などに関する情報を得ることができる。
【００９１】
図３は規制された業界のサプライチェーン解決案を可能にするシステム１０を実行させるための典型的なハードウェアコンポーネントのブロック図である。システム３０はユーザマシン３８をインターネットなどのネットワーク６０で結ぶユーザシステム３７を含み、該ユーザシステム３７は、ＩＰオーダーリング（IP ordering）に参加するためのネットワーク接続を提供する。他のユーザシステム、たとえばユーザシステム５６などもネットワーク６０に接続し、製造状況を得ることができる。ユーザシステム５６や他のユーザシステムはユーザシステム３７と同じコンポーネントを含む。
【００９２】
ユーザシステム３７と５６はサーバ７６とインタラクションし、状況情報を得る。サーバ７６はユーザが情報を取得し共有するためのアプリケーションに接続するネットワークを提供するために、ウェブサイト１２を提供し、管理する。システム３０はさらに、必要であればＷｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂからコンテンツを得るためのウェブサイトサーバ５８を１つ以上含むものとする。説明のため２つのユーザシステムのみ表しているが、システム３０は多数のユーザマシンを含む。また、ネットワークにユーザマシンを追加したり、ネットワークからユーザマシンを消去したりすることができるよう拡張性を有する。
【００９３】
ユーザマシン３８はユーザマシンの典型的なコンポーネントを示している。ユーザマシン３８は典型的にメモリ４０、第二記憶装置５０、プロセッサ５２、入力装置５４、ディスプレイ装置４８、出力装置４６を含む。メモリ４０は随時書き込み読み出しメモリ（ＲＡＭ）や類似のメモリを含み、プロセッサ５２によって実行されるアプリケーション４４、ウェブブラウザ４２などを保存することができる。第二記憶装置５０はハードディスクドライブ、フロッピディスクドライブ、ＣＤ−ＲＯＭドライブ、または他の不揮発性記憶装置を含む。プロセッサ５２はメモリ４０や第二記憶装置５０に保存されたアプリケーションやプログラム、またはインターネットや他のネットワーク６０から受信したアプリケーションやプログラムを実行する。
【００９４】
入力装置５４はキーボード、マウス、カーサコントロール装置、タッチスクリーン、マイク、ディジタルカメラ、ビデオカメラなどのマシン３８に情報を入力するための装置を含む。ディスプレイ装置４８はコンピュータモニタやフラットスクリーンディスプレイなどの視覚的な情報を示す装置を含む。出力装置４６はプリンタなどの情報のハードコピーを提供する装置やスピーカなどの音声的な情報の提供装置を含む。
【００９５】
ウェブブラウザ４２はウェブサイト１２を介してアプリケーションにアクセスするために使われ、ユーザが複数の情報を取得するためのウェブページを表示する。当該ウェブページの例は以下に説明する。ウェブブラウザの例としてはネットスケープナビゲータプログラム、マイクロソフト  インターネットエクスプローラプログラムを含む。任意のウェブブラウザやコブラウザ（co-browser）あるいは、ネットワークからのコンテンツの取得ならびにページ表示または画面表示が可能な他のアプリケーションを利用しても良い。
【００９６】
ウェブサイト１２とインタラクションするユーザマシンの例としては、パーソナルコンピュータ、ラップトップコンピュータ、ノートブックコンピュータ、パームトップコンピュータ、ネットワークコンピュータ、またはウェブブラウザや他のシステムとインタラクションするアプリケーションを実行可能な装置を含む。
【００９７】
サーバ７６は典型的にメモリ６２、第二記憶装置７４、プロセッサ７２、入力装置７０、ディスプレイ装置６８、出力装置６６を含む。メモリ６２はＲＡＭあるいは類似のメモリを含む。またプロセッサ７２によって実行される１以上のアプリケーション６４を保存する。第二記憶装置７４はハードディスクドライブ、フロッピディスクドライブ、ＣＤ−ＲＯＭドライブ、または他の不揮発性記憶装置を含む。プロセッサ７２はメモリ６２や第二記憶装置７４に保存されたアプリケーション、またはインターネットや他のネットワーク６０から受信したアプリケーションを実行する。入力装置７０はキーボード、マウス、カーサコントロール装置、タッチスクリーン、マイク、ディジタルカメラ、ビデオカメラなどのサーバ７６に情報を入力可能な装置を含む。ディスプレイ装置６８はコンピュータモニタやフラットスクリーンディスプレイなどの視覚的な情報を示す装置を含む。出力装置６６はプリンタなどの情報のハードコピーを提供する装置やスピーカなどの音声的な情報を提供する装置を含む。
【００９８】
また、プロセッサ７２は本明細書に記載されている機能を提供するために１以上のソフトウェアアプリケーション６４を実行する。当該処理はソフトウェアモジュールなど、コンピュータや他の装置が実行するためのソフトウェアに組み込まれていても良い。当該処理は本明細書に記載されているウェブページ、またはユーザのコンピュータと関連するディスプレイ装置での表示を提供し、サポートする。“スクリーン”とは情報や形を表示する全ての視覚要素や複数の視覚要素の組み合わせを意味する：例としてはディスプレイ装置に表示されるユーザインタフェースやウェブページに表示される情報、ディスプレイ装置に表示されるウィンドウなどがあるが、これらに限らない。スクリーンは、たとえば、ウェブページとしてハイパーテキストマークアップ言語（ＨＴＭＬ）や拡張マークアップ言語（ＸＭＬ）、または他のディスプレイ装置に表示するために（ユーザがシステムとのインタラクションのため使用するアプリケーションによって）使用する形に適切にフォーマットされる。
【００９９】
下記のようにスクリーンは情報受信と提供、コマンドの受信のために様々なセクションに分けられている。“スクリーンに関するセクション”とはスクリーンの特定のセクション（部分）を意味したり、スクリーン全体を意味することも出来る。情報やコマンドの入力、または情報の取り出し、他のスクリーンへのアクセスなどのために、セクションを選択する。セクションの選択はカーサコントロール装置を用いて“クリックオン”または“ダブルクリックオン”で選択することができる。代わりに、キーボード操作や音声コマンド、またはタッチスクリーンなどでもセクションを選択することできる。さらに、下記のスクリーンは特定のセクションの配置や数の例であるが、他のセクションの配置や数も同じまたは似た情報表示と受信、コマンドの受信の目的を達成するために使用することができる。また、同じセクションを複数の機能（例：同時に情報の表示とコマンドの受信）の実行に利用することができる。
【０１００】
システム３０は１つのサーバだけではなく、ユーザサポートに必要な数のサーバを利用することができ、サーバの障害に備えバックアップサーバや予備のサーバを利用することができる。また、マシン３７とサーバ７６は多数のコンポーネントと共に表現されているが、これらのマシンやサーバに他のコンポーネントが追加されたり、異なるコンポーネントの組み合わせで生成したりすることが可能であることは、当業者にとっては設計上の単純な設定に過ぎない。また、保存の媒体としてメモリが記載されているが、ハードディスク、フロッピディスク、ＣＤ−ＲＯＭなど第二記憶装置のような他のコンピュータプログラム商品、コンピュータ可読の媒体も使用可能であることは当業者にとって自明である。インターネットや他のネットワークのキャリヤウェーブ、他の形のＲＡＭやＲＯＭも保存の媒体として使うことができる。コンピュータ可読媒体はマシン３７とサーバ７６などのコンピュータシステムを制御し、特定の方法を実施するための指示を含む。
【０１０１】
薬物の例に限定されるものではなく、また、リピンスキーの５の法則を満たすものに限定されるものでもない。５の法則とは、：（ｉ）水素結合供与体（例：ＯＨ、ＮＨグループ）が５以下のもの、（ｉｉ）水素結合受容体（例：Ｎ、Ｏ）が１０以下のもの、（ｉｉｉ）分子量が５００ダルトン以下のもの、（ｉｖ）Ｌｏｇ  Ｐが５以下のもの、である。“５つの法則”は４つの規準が数字の５を含むことに由来する名である。詳しくはリピンスキー，１９９７，Ａｄｖ．Ｄｒｕｇ  Ｄｅｌ．Ｒｅｖ．２３，３に記載されており、これを引用することにより、当該文献の内容をここに合体する。ある実施例では、リピンスキーの５の法則に加え、他の基準も設けられている。たとえば、実施例によって薬物が持つ芳香環の数は５つ以下から４つ以下、３つ以下、２つ以下までがある。また、ある実施例では薬物は分子量２０００ダルトン以下の有機化合物となっている。さらに、ある実施例では、薬物は「Ａｐｐｒｏｖｅｄ  Ｄｒｕｇ  Ｐｒｏｄｕｃｔｓ  ｗｉｔｈ  Ｔｈｅｒａｐｅｕｔｉｃ  Ｅｑｕｉｂａｌｅｎｃｅ  Ｅｖａｌｕａｔｉｏｎｓ  ２５ｔｈ  Ｅｄｉｔｉｏｎ，  Ｕ．Ｓ．  Ｄｅｐａｒｔｍｅｎｔ  ｏｆ  Ｈｅａｌｔｈ  ａｎｄ  Ｈｕｍａ  Ｓｅｒｖｉｃｅｓ，  Ｆｏｏｄ  ａｎｄ  Ｄｒｕｇ  Ａｄｍｉｎｉｓｔｒａｔｉｏｎ，  Ｃｅｎｔｅｒ  ｆｏｒ  Ｄｒｕｇ  Ｅｖａｌｕａｔｉｏｎ  ａｎｄ  Ｒｅｓｅａｒｃｈ，  ２００５」に記載されているすべての化合物を含んでおり、これを引用することにより、ここに合体する。
【０１０２】
本発明のシステムや方法は可溶化した薬物、またはキャリアとミックスされた、あるいは散在した薬物を分析するために利用できる。ここでの“キャリア”とは希釈剤、補助剤、賦形剤または媒体物を意味する。キャリアは水や石油、動物性、植物性、化合性のオイルなどの液体を利用でき、たとえばピーナッツオイル、大豆油、ミネラルオイル、ごま油などがある。媒体物（例：賦形薬）は塩水、アラビアゴム、ゼラチン、でんぷん糊、タルク、ケラチン、コロイドシリカ、尿素などがある。更に、補助物、安定剤、増粘剤、平滑剤、着色剤なども使うことができる。患者に投入される場合、キャリアは中性的なものが望ましい。薬物が静脈内に投与される場合は、キャリアは水を使用できる。液体媒体物、特に注射用溶液には塩水、水性Ｄ型ブドウ糖、グリセロールなども使用できる。適切な媒体物は、でんぷん、ブドウ糖、乳糖、スークロス、ゼラチン、モルト、米、小麦粉、チョーク、シリカゲル、ステアリン酸ナトリウム、グリセロールモノステアレート、タルク、塩化ナトリウム、脱脂粉乳、グリセロール、プロピレングリコール、水、エタノールなどの賦形剤を含む。合成物質は必要に応じて湿潤剤、乳化剤、ｐＨ緩衝剤を少量含むことができる。
【０１０３】
実施例
１．イントロダクション
Ｒｉｖａ  Ｃｏｍｍｅｒｓｅ，ＩＮＣ（Ｒｉｖａ）は２０００年５月に設立され、国際的な飲料業界に企業規模のサプライチェーン管理解決策を提供することを計画している。Ｒｉｖａはサプライチェーン管理解決案のアプリケーションサービスプロバイダ（ＡＳＰ）であり、規制や規則順守管理などの複雑な機能を統合するスマートインベントリ、倉庫管理策などを専門的に扱う。
【０１０４】
最初の２年間の初期的な焦点は国際的なワイン業界であるが、Ｒｉｖａのモデルは厳しく規制された業界にも適応できる。顧客が在庫と倉庫を管理できるようにすることによってＲｉｖａのウェブベースサプライチェーン解決策は視認性を上げることができ、リアルタイム情報に安全にアクセスし、詳細な情報を得た上での決断を可能にする。
【０１０５】
飲料業界はまだ全体的に古いシステムを使用している。この業界が直面している最も困難な問題のひとつはこのような古い環境の中での飲料製造に伴う複雑な規制、規則順守過程の管理である。Ｒｉｖａ  Ｃｏｍｍｅｒｃｅは自動化が進んでいない業界において支配的な技術提供者になることができる立場にいる。
【０１０６】
Ｒｉｖａ  Ｃｏｍｍｅｒｃｅはサプライチェーン解決策の作成のためＷｉｐｒｏ  Ｔｅｃｈｎｏｌｏｇｉｅｓ（Ｗｉｐｒｏ）のパートナーになっている。本明細書は商品の必要条件を理解するために行ったＷｉｐｒｏのスタディの結果である。
【０１０７】
２．システム概観
２．１  イントロダクション
飲料業界はまだ全体的に古いシステムを使用している。この業界が直面している最も困難な問題の１つはこのような古い環境の中での飲料製造に伴う複雑な規制、規則順守過程の管理である。ここに提案されている商品はこれらの重要な問題を扱い、ワイン業界に総合的な解決策を提供するために、今後拡大していく。
【０１０８】
２．２  課題
下記の課題はワイン業界が直面しているいくつかの重要な課題であり、本商品が解決しようとする課題である。
【０１０９】
１．現在、多くのワイン醸造所はすべての場所にある統合された在庫の一覧を持っていない。この原因は主にワイン醸造所で使われている原始的なＩＴシステムが融合がされていないためである。本商品はすべての場所にある在庫のスナップショット一覧を提供する。
【０１１０】
２．購買部は統合された一覧がないため適切なタイミングで購買を開始することができない。本商品は警報を発生させる閾値をユーザが設定できるメカニズムを提供する。
【０１１１】
３．現在のほとんどのワイン醸造所において弱点となっているのは規則順守のための記録管理である。規模の小さいワイン醸造所は台帳を使用して記録管理を行っている。これは手作業であり各過程は別々に行われるため、ブドウからワインまでのすべてのサイクルを追跡するのは難しい。
【０１１２】
４．規制当局はすべてのワイン醸造所に対し周期的なデータを定められた形式で整理することを要求する。ワイン醸造所にとっては規制書類を作成するために必要なデータを収集するのは困難な作業である。いくつかの大規模なワイン醸造所は外部のコンサルタントにこの作業を依頼している。本発明は在庫モジュールと工程モジュールから発生したデータを利用し規制書類を作成する。
【０１１３】
５．ワイン醸造所は厳しく規制されるため、ぶどうからワインまでの追跡方法が必要になる。これは特に会計監査の際の重要な特性である。本商品はぶどうからワインまでのすべての製造工程を追跡することを援助する。
【０１１４】
６．ワイン醸造所は瓶、コルク、たるなどのワイン醸造に関わる物を提供する数多くのサプライヤを持っている。現在のところサプライヤ記録は台帳に手作業で管理されている。このように管理された記録から必要なサプライヤを探し出すことは難しい。本商品は電子的にサプライヤやカタログを管理する。
【０１１５】
７．ワイン醸造所の従業員とサプライヤ、ラベル作成代理店などの従業員の間ではたくさんのコミュニケーションが行われる。現在のところ、このインタラクションは電話やファクス、メールなどを介して行われている。しかし、後日、追跡することはできない。本発明は組織内部であっても外部であっても書類の共有を可能にする機能を持っている。
【０１１６】
２．３  モジュール方式
本商品は下記の理由によってモジュラである必要がある。
【０１１７】
１．顧客の予算や機能的制約によって購入するモジュールが異なる。
【０１１８】
２．後日、モジュールを加えることによって商品の性能が上昇する。
【０１１９】
下記の事項は本商品の様々なモジュールである。必要条件の簡略な説明が提供されている。必要条件の詳細については次の章に詳しく記載されている。
【０１２０】
２．３．１  コアモジュール
コアモジュールはシステム全体の基礎をなすモジュールである。コアモジュールは商品全体で共通する機能を実行する。コアモジュールに必要となる機能は：
−ユーザ管理
−役割と安全管理
−組織構造管理
−システム陣営
−アイテムマスタやサプラヤマスタなどの機能マスタ
−警報機能
である。
【０１２１】
２．３．２  工程モジュール
工程モジュールはワイン製造の様々な段階から発生するデータを取得する。取得されたデータは活動記録や実験分析記録などである。これらの記録は会計監査や規制順守のため必要な追跡機能の実現に重要な役割を果たす。
【０１２２】
２．３．３  在庫モジュール
在庫モジュールは顧客が在庫を管理できる機能を提供する。下記の機能がモジュールの一部として予想される：
−正常な受け取りや発行
−物品の移動
−物理的な検証。
【０１２３】
２．３．４  サプライヤモジュール
サプライヤモジュールはサプライヤとカタログを管理できる機能を提供する。下記の機能がモジュールの一部として予想される：
−サプライヤ情報の管理
−カタログ情報の管理。
【０１２４】
２．３．５  コンテンツモジュール
コンテンツモジュールはコンテンツを管理するに必要な機能を持つ。コンテンツは、
−新聞記事
−業界申立書
−Ｒｉｖａ  Ｃｏｍｍｅｒｃｅ  アップデート
などがある。
【０１２５】
コンテンツモジュールは組織内や外部のユーザとコンテンツを共有したり送信したりすることができるような機能を提供する。この機能は生成チームやサプライヤとそれぞれラベルに関する書類を共有したり商品に関する書類を共有したりするのに便利である。
【０１２６】
２．３．６  規則モジュール
規則モジュールは規制順守のために必要な機能を提供する。ＢＡＴＦ必要条件による法定のレポートなどを作成する機能を有する。
【０１２７】
２．４  融合した解決策
工程、在庫、サプライヤ、コンテンツ、規則モジュールが自立的、または密接に働くようにアプリケーションが構成されている。すべてのモジュールを購入した場合、これらのモジュールの融合が可能である。
【０１２８】
２．５  コンテキストに基づいたヘルプ
コンテキストに基づいてヘルプをサポートする機能が提供される。各ページはそれぞれ異なるコードで識別される。ヘルプのコンテンツは最初に実行する際に設定する必要がある。ユーザは各ウェブページからヘルプページに進むことができる。ヘルプページはコンテキスト依存であり、ユーザが見る各ウェブページに関連する。すべてのウェブページは関連するヘルプページを持つ。二つ以上のウェブページが共有のヘルプページを持つこともあり得る。
【０１２９】
２．６  警報
ユーザは警報を通じて様々なシステムイベントに関する情報を受け取る。警報はユーザが興味を持つイベントに注目させるのに役立つ。
【０１３０】
２．６．１  登録
ユーザはシステムによって誘発される様々な警報を登録する機能を持つ。たとえば、ニュース警報などに関してはユーザ好みの分野を設定することができる。
【０１３１】
２．６．２  警報の配達
警報は複数のチャンネルを介して送達することができる：
Ａ．ログイン後のウェブサイト
Ｂ．メール
Ｃ．ＳＭＳ  メッセージ
これらのチャンネルを介して送達されるものの性質とコンテンツは、商品コンサルティングの際に決定される。
【０１３２】
２．７  報告
下記の項目はシステムによってサポートされるべき様々な種類の報告である：
１．管理上の報告
２．機能的報告。
【０１３３】
３．コアモジュール
３．１  イントロダクション
コアモジュールはシステム全体の基礎をなすモジュールである。コアモジュールは商品全体で共通する機能を実行する。コアモジュールは他のモジュールの基礎をなすインフラを提供する。
【０１３４】
３．２  概念設計
この商品は二つの異なったユーザインタフェースを持つように設計されている。
【０１３５】
１．設定インタフェース
２．機能インタフェース
設定インタフェースは商品の使用のための設定事項を処理し、機能インタフェースはマスタと取引モジュールに分類される。
【０１３６】
３．３  設定インタフェース
設定インタフェースは設定要素をサポートするモジュールを格納する。これらの機能はＲｉｖａ  Ｃｏｍｍｅｒｃｅの実行チームと管理チームがクライアントのシステムをＡＳＰモードに設定することを可能にする。また、Ｒｉｖａ  Ｃｏｍｍｅｒｃｅがシステムを所有する場合は、クライアント組織の主要ユーザらが設定を管理することになる。
【０１３７】
システムへの認証を持つ主要ユーザらは管理者が設定したアクセス権利に基づいて下記のモジュールへのアクセス権利を持つ。
【０１３８】
設定インタフェースはコーディングなどの技術的な知識がなくても設定をできる機能をユーザに与える。
【０１３９】
上記モジュールとは：
１．全般的な設定
２．機能的な設定
である。
【０１４０】
３．３．１  全般的な設定：
これらは基本的な設定要素であり、最初にユーザによって設定される。ここで設定されるパラメータは通貨、言語、国、州、ＵＯＭなどがある。上記のパラメータは設定後から機能的な面でスムーズなシステムの動作を可能にする。
【０１４１】
３．３．２  機能設定：
機能設定分野は機能的な面でモジュールごとに分離される。すべてのパラメータやドロップダウンメニューはこの空間で設定される。たとえば、記録の番号付けの範囲、ワークオーダの活動、場所、購入者コード、アイテム種類、タンク番号、タル番号、ロット番号、組成などがある。
【０１４２】
設定の段階で要求される典型的な設定のセットは下記に記載されている。
【０１４３】
１．活動：ワイン製造工程は原料の受け取り、圧搾、茎取り、発酵、仕分け及び除去、高品質を維持させるための濾過、瓶詰めなどの様々な活動を含んでいる。これらの活動はワークオーダ活動の詳細に記録された取引に対する入力を形成するように構成される。これにより、１つのワークオーダフォーマットで、ワイン製造工程におけるすべての活動の記録を提供することが可能となる。
【０１４４】
２．番号の範囲:アイテムマスタの各アイテム、サプライヤマスタの各サプライヤ、工程管理モジュールの各ロットと書類は内部的に生成された番号をそれぞれ持つ。
【０１４５】
３．アイテムマスタ構成要素はアイテム種類、ビンテージ、購入者コード、物理的な在庫検証種類、カタログレベルの数、階層などがある。
【０１４６】
アイテムはそれぞれの種類に分類される。この種類は階層的である必要はない。種類を作り、管理する機能はシステムによってサポートされることになる。種類は一般に名前、説明、親識別子（parent identifier）がある。在庫データは種類によって問い合わせることができる。
【０１４７】
ビンテージはぶどう収穫の年度を表すもので、構成要素は１９９８、１９９９、２０００のような形で年度を提供する。そのようなビンテージフィギュアは、ぶどうを受け取ってロットを作成する際に抽出されることになる。
【０１４８】
購入者コードは購買責任者のユーザＩＤである。アイテムマスタのアイテムに購入者コードを割り当てることは、コードに基づいて在庫データを調べることを促進するだけではなく、コードに基づいて情報提供を制限することもできる。
【０１４９】
組成構造はユーザにとってぶどうの品種や名称をアイテムマスタに百分率で作成する機会を与える。たとえば；品種−カベルネ（cabernet）（１００％）、名称−カベルネ（Ｄｒｙ  Ｃｒｅｅｋ  ８０％  Ｎａｐａ  ２０％）などである。
【０１５０】
４．サプライヤマスタ構成要素は、カタログが提供された場合に、階層的、かつ階層展開可能な機能を提供するカテゴリである。
【０１５１】
５．場所はタンクやたるのある区域の物理的な境界を示す。
【０１５２】
６．機能的なモジュールはタンク番号、たる番号、サービス状況、グループの作成のために設定が必要になる。
【０１５３】
タンク番号やたる番号はタンクやたるを一意に識別するのに使われる。
【０１５４】
サービス状況はたるが使用中であるか空であるかについての情報を提供する。
【０１５５】
３．４  機能インタフェース
機能インタフェースはマスタおよびトランザクションとを含む様々なモジュールを格納する。マスタはデータの主要倉庫である。トランザクションモジュールはワイン醸造所の中でユーザが各種の機能を実行することを許可する。ユーザはログイン／パスワードを通じて認証された後、システムのこのセクションにアクセスできるようになる。ユーザはアクセス権が与えられた関連するタスクを実行することができる。
【０１５６】
３．４．１  ユーザ管理
システムのユーザ管理モジュールはユーザ及びその役割を作成、編集、消去するために使用される。また、許可を与えたり、無効にするためにも使用される。
【０１５７】
１．本システムはユーザの名前、称号、電話番号、ファクス番号、メール、場所、部署などの詳細を取得するためにユーザインタフェースを提供する。場所、部署などはユーザをワイン醸造所の組織構造にマッピングして割り当てる。本システムは組織構造に基づいてユーザにツリー表示を提供する。主要管理者らはこの機能を利用しユーザをシステム内で見つけ、彼らの詳細情報を監視、編集、消去する。
【０１５８】
２．ユーザはＩＤとパスワードが与えられ、それを使ってシステムにログインできる。ユーザはパスワード番号を変えることができる。
【０１５９】
３．システムは、アクセス権をもってシステム内の役割をモジュール内の細かいレベル（granular level）で作成、編集、消去するインタフェースを提供する。当該アクセス権は、作成、編集、閲覧型のモジュール内の細かいレベルでの権利となる。アクセス権はある期間設定可能である。特定の役割についての詳しい説明はその役割を選択すると見ることができる。
【０１６０】
４．それぞれのユーザシステム内でデフォルトのアクセス権を持つ役割をもらうことができる。ここではユーザのアクセス権の設定は変更可能であり、役割のアクセス権より優先される。
【０１６１】
５．グループユーザに対する機能がサポートされている。グループユーザの追加や消去はシステムから可能である。
【０１６２】
６．管理者によって設定されたグループは在庫管理（警報）モジュールとコンテンツ管理（書類共有）モジュールにおいて関わってくる。
【０１６３】
７．ユーザは独自のグループを作成することができる。このグループはそのユーザにのみ適用できる。
【０１６４】
８．アクセス制御の細かさは下記の通りである：
−モジュール（例：在庫機能）
−取引（例：在庫状況）
−権利（例：追加、編集、消去）
−データバウンド（例：在庫アイテムＸ、書類Ｙ)
モジュール：アクセスは特定のモジュールだけに限って与えられる。ワイン醸造所は選択してモジュールを購入することができる。よってこの機能が必要になる。
【０１６５】
取引：ワイン醸造所の管理者は取引に権利を与える。
【０１６６】
権利：ひとつのトランザクション内に、ユーザはそれぞれ異なる権利を有する。少数のユーザが完全な支配権利を持ち、残りは閲覧する権利だけを有する。
【０１６７】
データバウンド：権利は特定のデータアイテムに限られる。たとえば、ユーザの権利は在庫のアイテムＸとアイテムＹだけに限られる。権利はデフォルトではすべてのアイテムに対して与えられるが、必要に応じて制限することもある。
【０１６８】
レポート
管理者は管理レポートを生成する。このレポートは下記のような管理機能のためである：
Ａ.ユーザレポート
Ｂ.役割やアクセス権レポート
次のような次元に基づいてレポートを生成することが可能であることが必要である：
−データの範囲
−場所
−グループ
−部署。
【０１６９】
３．４．２  システム管理
このモジュールの一部はＣＳＶフォーマットからカタログデータをアップロードするために、マスタやツールのためのすべてのバッチ的なアップロードを実行できるよう管理者にすべてのシステムツールを提供する。
【０１７０】
３．４．３  組織構造
ワイン醸造所の典型的な構造は図６に示すとおりである。本システムは階層的な組織構造をキャプチャするように設計される。構造はこの機能を用いて管理できる。新しいノードが構造に加わるとそのノードの種類（例：プラント、倉庫、購買組織）を指定する。各自のノードは親子関係によって関連付けられる。
【０１７１】
３．４．４  アイテムマスタ
アイテムマスタモジュールは取引のためシステムで使用された各素材を定義するパラメータやデータを保管している。
【０１７２】
アイテムマスタのビューは一般情報、購買情報、倉庫在庫情報に基づいて分類される。このビューに固有のすべての情報は、該当のビューにキャプチャされ、機能面においてユーザのトランザクション画面にデフォルト値として使用される。システムは今のところ３つのビューがあるが、更なる機能のためにアプリケーションを拡張する場合にはセールス、会計、コストなどのビューまで拡張されるであろう。
【０１７３】
アイテムマスタの図面の説明は図７に記載されている。
【０１７４】
１．概略のビュー：概略のビューはアイテム説明、計測の基本単位、計測の変換単位、ＵＯＭの換算率、物理的な規模（当てはまる場合）、重量、容積、重量と容積の単位、長いテキスト、アーカイブ／削除フラッグ、組成、アイテム種類、カタログ階層などの情報をキャプチャする。
【０１７５】
２．購買ビュー：購買ビューはアイテムカテゴリ、調達時間、ロットインジケータ（アイテムがロットで管理されているか）、検査フラッグ、購入者コード（調達にかかわる人物と許可されたサプライヤ）などの情報をキャプチャする。
【０１７６】
３．保管ビュー：保管ビューは出荷（issue）計測単位、物理的な在庫確認形式、在庫商品の有効期間データ、保管所の数量（入荷、出荷によってダイナミックに調整される）、温度、湿度などの保管条件などをキャプチャする。
【０１７７】
アイテムマスタはすべてのアイテムの作成、編集、マーキングの機能を提供する。
【０１７８】
レポート
下記の次元にしたがってアイテムマスタレポートを作成できる：
−日付範囲
−組織単位（例：保管場所）
−種類
−購入者コード。
【０１７９】
３．４．５  サプライヤマスタ
素材マスタが素材を定義することが求められるように、サプライヤマスタはサプライヤを定義することが求められる。同様に、サプライヤマスタもさまざまなビューが提供される。
【０１８０】
サプライヤマスタビューは、一般的な情報のみに基づいて分類される。このビューに対する固有のすべての情報は、それぞれ関連するフィールドにキャプチャされ、機能面におけるユーザトランザクション画面にデフォルト値として使われる。このシステムは今のところ１つのビューしかもっていないが更なる機能のためにアプリケーションを拡張するときには購買、会計などのビューに拡張されるであろう。
【０１８１】
概略のビュー：概略のビューはサプライヤ名、住所、電話番号、ファックス番号、メール、種類と下位種類、サプライヤ管理モジュールのユーザサーチのためのメタデータ要素、フラッグを介してのアクティブか非アクティブかについてのサプライヤの状況などの情報をキャプチャする。
【０１８２】
レポート
下記の次元にしたがってサプライヤマスタレポートを作成できることが必要である：
−日付範囲
−組織単位
−種類。
【０１８３】
４．工程管理モジュール
４．１  イントロダクション
このモジュールはワイン醸造所のぶどうの購買から最終的な瓶詰めまでのさまざまな工程を記録するためにユーザを補助する。このような記録管理はＢＡＴＦユーザの記録に関する会計監査を可能にする。このモジュールは下記のような過程のためにデータをキャプチャすることができる：
１．工程追跡
２．工程パラメータの事後分析
３．ＢＡＴＦのような取締期間のための会計検査記録に使用
４．フォーム７０２の作成の補助
ワイン作りの工程はワインの種類による作業、ワインの種類とは関係ない作業があり、これらの工程から発生する記録は４つに分類することができる。
【０１８４】
１．ワークオーダ
２．分析記録
３．在庫記録
４．タンク／たる記録。
【０１８５】
４．２  工程の流れ
ワイン醸造所の工程の流れと発生するデータは図８のようになる。ここにアウトラインされた工程の流れは非常に一般的であって包括的ではない。ワインの種類（たとえばスパークリングワイン、ポートワインなど）によって異なることもある。また、大規模なワイン醸造所は複雑な工程を持つと考えられる。
【０１８６】
これらの各ボックスはワイン醸造作業のひとつであり、関連するワークオーダを持っている。また、これらの作業中に実験検査を行うことも考えられる。制御記録もさまざまな作業中に生成される。
【０１８７】
このモジュールはユーザにさまざまな作業をワークオーダ、実験検査、または工程制御記録の入力のために提供する。
【０１８８】
このシステムは瓶詰めから遡りぶどうの種類まで追跡できるような機能を提供する。このロット管理機能はロットが通過する工程の作業の流れを識別し、ロットをワークオーダと結びつける。
【０１８９】
在庫データも工程のさまざまな段階で記録を介して生成される。
【０１９０】
４．３  ロット管理
ワイン醸造工程は追跡できるようロットで管理される。ぶどうが入荷するとインタフェースを介してすべての種類に対するロットが作成される。ロットはそれぞれ独自のロット番号が配される。収穫／調達年度も参照できる。ロットは、化学的な分析によって必要になれば、さらにサブロットに分けることも可能である。ロットごとの概要記録はサプライヤ、品質、有効期間、アクティブか非アクティブかに関するロットの状況、他のコメントなどの詳細な情報を提供する。この書類はロットの履歴として使われる。
【０１９１】
ワイン醸造工程の各作業に入ると、ワークオーダはさまざまな段階を記録することによって作業に取り込まれるロットの数量が記録される。この作業は工程の最後の作業に至るまで続けられる。この時点でロットは瓶に詰められる。
【０１９２】
ブレンドの作業を行う場合は、さまざまなロットのワインがひとつのタンク／たるで一緒になり、更なる工程を経る。そのような場合には、トレーサビリティのために出力に新しいロット番号が配される。
【０１９３】
４．４  記録管理
システムは工程のさまざまな段階で下記の項目を記録をするようにインタフェースを提供する。
【０１９４】
１：作業ワークオーダ
記録は工程の作業前後で作成される。記録は作業内容、処理されたロット、作業へのインプット、インプットの起点、設備／タンク番号や作業が行われている場所などを記録する。各作業はそれぞれ特異的なワークオーダと関連付けられ、瓶はロット番号を用いてロット追跡ができる。入荷、圧搾、発酵などの作業はワークオーダを含む。ワークオーダは日付、以前のレファレンス、シフトなどに関して作られる。ワークオーダの各ラインアイテムは、ロット番号、元の場所、移動される場所、数量、追加（＋）／除去（−）、品質などの詳細な情報を含む作業のひとつの段階をあらわしている。
【０１９５】
たとえば、１２５ガロンのカベルネを瓶詰めする作業は次の二つの段階に記録される：
段階１：カベルネを瓶に詰める
ロット番号：Ｌ９９−１２３
元の場所：タンク４００
移動される場所：ビル１
追加（＋）／除去（−）:＋
数量：１２５ガロン
品質：ＯＫ
段階２：瓶を閉める
数量：５２ケース
元の場所：ビル１
この作業の記録作成により１２５ガロンのケース商品ワインの増加、５２ケースの空瓶の減少、タンク４００からの加工中のワインの減少という効果がある。
【０１９６】
発酵の工程でも同様なワークオーダを作成することができる。この場合は各段階でのさまざまな品質の酒石酸、二酸化硫黄などの添加物に触れることもできる。添加物は在庫アイテムとして追加される。“ぶどうの入荷”のような作業ではサプライヤやキャリアなどの情報もキャプチャする。他の場合はキャリア情報は必要でない。
【０１９７】
システムはすべての追加されたラインアイテムの在庫の有効性がワークオーダから確認できる機能を提供する。ポップアップは手元にある在庫、ＷＩＰなどを重量、容積によって報告する。
【０１９８】
また、ワークオーダに追加または除去される量の迅速な分析も可能である。この変化（除去−追加）はワークオーダを送信する前に、ユーザが再検討できるように、重量、容積などの項目において報告される。
【０１９９】
システムはさらに記入されたワークオーダをテンプレートとして後日保存する機能を提供する。そのようなテンプレートは、作業詳細が頻繁に使われ、ユーザのデータ入力を減らすことができるような場合に使われる。
【０２００】
２．分析記録
実験記録：この記録は分析のログとして保存され、評価はワイン醸造所の分析室（実験室）で行われる。ワイン醸造所のファイルでぶどうやほかの果物の出所、種類、重量を記載することは必須である。商品生産の追跡やラベルに書いてある内容の信憑性の追跡のために、ＢＡＴＦはこの情報を要求する。そのような分析と記録管理（Ｂｒｉｘ−Ｂａｌｌ、ｐＨなど）は、ぶどうの入荷の時に、あるいはタンクの内容物のさまざまな化学的パラメータ（ＡＬＴ、ＴＡなど）を分析する際に行われる。
【０２０１】
工程記録：工程記録の例としてはタンク、ロット、化学的なパラメータ（ＡＬＴ、ＴＡなど）を日付、時間帯で記録する発酵制御記録がある。
【０２０２】
３．在庫記録
重量タグ（計量チケット）の形式でのぶどうの記録管理と、他のワイン醸造添加物、瓶、コルクなどの直接購買材料の記録管理はシステムによってサポートされる。すべての貯蔵室で使われる素材、バルクワイン、ケースに包まれた商品の帳簿在庫に関する物理的な在庫検証記録もユーザによってシステム内で実行される。
【０２０３】
４．タンク／たる記録
タンクとたるは発酵、熟成、高品質、安定性などの作業に継続的に使われる設備である。タンクとたるの履歴を管理することは利用できる最大容積を追跡するだけではなく、交換や改正のために物理的な状態を検討することも可能にする。たとえば、たるはさまざまな種類の木材からなり、その中で熟成されるワインに何らかの特徴を与える。また、特徴を与える性質は時間とともに減るため、一定の時間がたつと、たるは処分されるか処置を受けるため別のところに運ばれる。処置は一般的に再トースト（re-toasting）という工程を含み、新たな寿命を与える。本システムは各タンクとたるに配されたそれぞれの番号と場所を用いて１つ１つ追跡できる機能を提供する。タンク／たるの種類、状況（空など）、関連する作業（検査、満タンにする補充、トーストなど）の情報が後日の追跡のためにユーザによって保存される。
【０２０４】
４．５  レポート
システムは取引レポートの作成をサポートする。
【０２０５】
Ａ．作業レポート
Ｂ．実験解析
Ｃ．制御レポート
下記の次元にしたがってレポートを作成できることが必要である：
−日付範囲
−場所
−タンク
−たる
−ロット
−種類。
【０２０６】
５．在庫モジュール
５．１  イントロダクション
このモジュールはさまざまな倉庫の場所のアイテム在庫状況をサーチすることを補助する。また、ユーザはアイテムのキーワードを用いてサーチすることができ、さまざまな倉庫の場所から在庫状況を得ることができる。ユーザは一箇所あるいは複数の倉庫の組み合わせのアイテムのために閾値を設定でき、それに基づいてほかのユーザやグループに警報を発信できる。在庫データは工程モジュールにて作成された工程記録を介してシステムに取り込まれる。
【０２０７】
５．２  モジュール必要条件
モジュールは次のような機能を持つ：
１．倉庫選択：システムの構造側の組織ユニットは掘り下げ（drill down）モードで表示され、ユーザは在庫状況を確認したい倉庫をクリックし、選択することができる。
【０２０８】
２．アイテムの選択：アイテムマスタからのアイテムはカタログ形式でユーザに表示される。カタログはアイテムマスタで定義されているアイテム種類を含む階層的な表示である。ユーザはカタログの最下層まで展開し、アイテムを選択することができる。
【０２０９】
３．キーワードに基づいたサーチ：この機能はアイテムマスタの所定のメタデータに対するキーワードサーチをユーザに提供する。サーチはユーザが選択できるようにアイテムを表示する。
【０２１０】
４．アイテムや倉庫の選択は在庫状況とともに所定のパラメータをユーザに表示する。
【０２１１】
５．ユーザは１つの倉庫または複数の倉庫の組み合わせに対して在庫の限界を設定することができる。ユーザはまた警報を受信するユーザ／グループを指定することができる。在庫状況が限界設定より下がると、システムはすぐに警報レポートを発生させ、指定されたユーザ／グループに送る。警報のコンテンツはあらかじめ決まっており、ログインした時、警報モジュールで見ることができる。
【０２１２】
６．ユーザインタフェースは貯蔵室で使われる素材、バルクワイン、ケースに包まれた商品を記録できるようにする。物理的な在庫数字は帳簿在庫に比較され、ユーザの許可があれば調整される。
【０２１３】
５．３  在庫警報
在庫警報はユーザ自身によって、あるいは、他のユーザによって不可欠と判断された項目を含むように設定できる。
【０２１４】
在庫警報は一箇所以上のひとつのアイテムに対して在庫レベルの最低限度と最大限度に基づいて設定できる。場所をグループで結びつけたり警報を設定したりする機能が提供される。
【０２１５】
５．４  レポート
下記の次元にしたがって在庫状況レポートを作成できることが必要である：
−データ範囲
−場所
−タンク
−たる
−ロット
−種類。
【０２１６】
６．サプライヤモジュール
６．１  イントロダクション
このモジュールはアイテムやサプライヤに基づいてサプライヤの詳細についてサーチできる機能をユーザに（特に購買を行うユーザに）提供する。サプライヤモジュールはサプライヤ情報とカタログ情報の二つの異なる部分を持つ。サプライヤ情報はサプライヤに関する詳細な情報を含み、カタログはサプライするアイテムの詳細を含む。サプライヤ情報はカタログがアップデートされなくても独自に使用することができる。
【０２１７】
１．サプライヤを選択：この機能はユーザがサプライヤカタログから展開し、特定のサプライヤを選択できるようにする。カタログはある階層をカテゴリとして生成され、このカテゴリはシステムのサプライヤマスタにインプットされる。
【０２１８】
２．アイテムを選択：アイテムカタログのアイテムはカタログ形式でユーザに提供される。カタログはアイテムのカテゴリが定義された階層的な表示である。ユーザはカタログの最下層まで展開し、アイテムを選択できる。このカタログの階層的な構成はアイテムマスタのカテゴリの構成とは異なる。カテゴリを整理、管理するためにはユーザインタフェースが必要である。
【０２１９】
３．サプライヤカタログをシステムにアップロードできる機能が提供される。カタログはアップロードのため所定のＣＳＶ形式である必要がある。キャプチャされる典型的なデータ要素は商品識別子、概要、画像などがある。
【０２２０】
４．サプライヤマスタに定義されたデータ要素からサプライヤによってサプライされるアイテムのサーチ：サーチはサーチ条件にマッチするサプライヤのリストを表示する。特定のサプライヤを選択するとそのサプライヤに関する詳細を見ることができる。
【０２２１】
６．２  サプライヤ警報
サプライヤ警報はシステムで起こる動作によって発生する。たとえば、新しいサプライヤがシステムに加わったり、カタログが変わったりするとサプライヤイベントが発生する。他のサプライヤ警報をもたらすイベントは：
ａ．サプライヤに関連するニュースアイテム
ｂ．場所変更
がある。コンテンツ管理モジュールを使ってコンテンツが発行されると、それをサプライヤ警報としてフラッグをつける機能が存在する。
【０２２２】
６．３  レポート
下記の次元にしたがって在庫状況レポートを作成することができる：
−データ範囲
−場所
−カテゴリ
−アイテム。
【０２２３】
７．規則モジュール
７．１  イントロダクション
フォーム７０２はワイン醸造所によって周期的に提出され、ワインの在庫状態の詳細を含むものである。また、ＢＡＴＦの規則により消費税フォームも定期的に提出される。
【０２２４】
７．２  モジュール必要条件
１．フォーム５１２０．１７（７０２）はワイン醸造所によって毎月提出され、ワインの在庫位置の詳細を含むものである。報告はある日付の範囲（主に毎月）を報告し、独自な登録番号によって識別される。レポートのパート１は、バルクワインとボトルワインという二つのセクションを含む。製造、使用中のさまざまなタスクの報告は主にワインのアルコール度数によって分類されたカテゴリにおいて行われる（＜＝１４％、１４〜２１％、２１〜２４％、人工的に炭酸ガスを飽和させたワイン、スパークリングワイン）。発酵、甘み調整、ブレンド、改善などの工程中の製造やテスト、改善、トッピング、ラッキング、輸出などのためのワインの使用が記録される主要な要素である。蒸留酒やぶどう素材、特別ナチュラルワインの報告は、フォーマットのパートＩＩからＩＸで行われる。パートＸはコメント用にとっておく。
【０２２５】
２．システムはこれらのフォームにデータを書き込むためのインタフェースを提供し、後日の記録のためにこれらのアーカイブを管理する。フォーム７０２に入力できる他のモジュールからの取引データはシステムに準拠する。
【０２２６】
３．データのキャプチャは工程モジュールと在庫モジュールの様々な取引を介して行われる。システムはすべてのデータ要素とキャプチャされたすべての取引データから計算されたそれぞれのデータを含む報告用の基礎集計シートを作成する機能を提供する。ユーザはこの基礎レポートをレビューし、修正を行う。システムが工程取引の際、キャプチャしなかったものでもユーザによってエントリすることが可能である。ユーザがすべての修正やエントリを終え、レビューを完成すると、ＢＡＴＦに提出するフォーム７０２を作成することができる。
【０２２７】
４．また、ＢＡＴＦの規則によって消費税フォーム（Ｆ５０００．２４）も周期的に報告する必要がある。このフォーマットはワイン醸造所のすべての納税や税金に関する要素をキャプチャする。システムはこれらのフォームにデータを書き込むためのインタフェースを提供し、後日の記録のためにこれらのアーカイブを管理する。
【０２２８】
しかし、データは主に金銭的なものでありシステムの内部から作られることはない。
【０２２９】
７．３  レポート
下記の次元にしたがって順守レポートを作成できることが必要である：
−データ範囲
−組織単位
−登録番号。
【０２３０】
８．コンテンツモジュール
８．１  イントロダクション
コンテンツモジュールは独自のモジュールで下記の機能をサポートする：
１．業界概要、ニュース記事、他のコンテンツアイテムを管理
２．書類をアップロード、共有する機能の提供
コンテンツモジュールの二つのサブコンポーネントはどれも独立して機能できるように論理的に分離される必要がある。
【０２３１】
８．２  コンテンツ管理
下記の項目はサポートされるさまざまなコンテンツのカテゴリである；
１．業界ニュース
２．最善の実行（Best Practice）
３．ホワイトペイパーズ
４．イベント
５．会社ニュース
６．Ｒｉｖａ  Ｃｏｍｍｅｒｃｅ情報
最上位のｎ個のアイテム（ユーザによる指定）のみ表示される。アイテムは日付、優先順位などのユーザが設定できる項目に基づいて表示される。他のコンテンツはアーカイブセクションに表示される。コンテンツがアップロードされると、それを警報として通知するか否か、どのような警報の種類か（ニュース警報、サプライヤ警報）を指定できる機能が提供される。
【０２３２】
８．２．１  業界ニュース
業界ニュースを表示する機能が提供される。業界ニュースの提供に際しては、コンテンツプロバイダとのタイアップが予想される。コンテンツプロバイダとの融合はＵＲＬリンクを介して行われると予想される。コンテンツはコンテンツプロバイダのサーバ内に存在し、ＵＲＬを介してリンクされる。
【０２３３】
業界ニュースを提供する機能はＡＳＰモデルに限定される。この商品が購入された場合は、ユーザはこのサービスに申し込むことができる。その場合は、ＡＳＰサービスを介することによってアクセス可能であるウェブページはワイン醸造所に提供される。ワイン製造所のユーザはインターネットへのアクセスが可能であり、ＡＳＰ環境でホストされたウェブページをアクセスすることが可能であることを前提としている。
【０２３４】
８．２．２  最善の実行（Best Practice）
Ｒｉｖａ  Ｃｏｍｍｅｒｃｅは最善の実行（Best Practice）を発行するような社内シンクタンクを持っている。
発行のためには下記の機能が要求される：
１．コンテンツのアップロード
２．タイトル、筆者、キーワード、説明などのコンテンツのメタデータの入力
３．コンテンツの除去
４．コンテンツのアーカイブ化
発行されたコンテンツはＡＰＩモデルのすべての購読者に提供される。買収されたモデル（bought-out model）の場合は、購読者はインターネットを介してホストされたＡＰＩから直接アクセスする。
【０２３５】
８．２．３  ホワイトペイパーズ
Ｒｉｖａ  Ｃｏｍｍｅｒｃｅはホワイトペイパーズを発行するような社内シンクタンクを持っている。要求される特徴や機能は最善の実行と同様である。
【０２３６】
８．２．４  イベント
Ｒｉｖａ  Ｃｏｍｍｅｒｃｅはワイン業界に関連するイベントのリストを発行することを前提とする。要求される特徴や機能は最善の実行と同様である。
【０２３７】
８．２．５  会社ニュース
会社の内部ニュースはここに掲示される。会社の従業員のみに表示される。このセクションに掲示できる権利は会社の少数の人に限定される。アップロード、メタデータ、アーカイブなどのいくつかの機能は最善の実行と同様である。
【０２３８】
８．２．６  Ｒｉｖａ  Ｃｏｍｍｅｒｃｅ情報
このセクションはＲｉｖａ  Ｃｏｍｍｅｒｃｅに関する情報を含む。これは新たなサービス、商品販売などを含む。
【０２３９】
このセクションは一般的にすべての会社に提供される。アップロード、メタデータ、アーカイブなどのいくつかの機能は最善の実行と同様である。
【０２４０】
８．３  書類共有
書類を組織のユーザ間、またはサプライヤや創作チーム（ラベルデザイン用）と共有する機能はもっとも重要な機能である。このモジュールはさまざまな団体の書類共有を補助する。このモジュールの主要な条件は以下の通りである。
【０２４１】
１．ユーザは主要倉庫に書類をアップロードすることができる。
【０２４２】
２．ユーザはキーワード、説明などのメタデータ情報を入力しなければならない。収集されたメタデータはすべての書類に同様である。
【０２４３】
３．ユーザはカテゴリが保存される階層的なフォルダを作成することができる。
【０２４４】
４．ユーザが書類を共有する場合は、フォルダ構成も共有される。筆者の名前はフォルダ名の前に付けられ、他のローカルフォルダと区別される。
【０２４５】
５．ラベルは“ラベル”と名付けられたフォルダに保存される。
【０２４６】
６．ユーザは、選択されたユーザ／グループのみが利用できるように、文書に対する権利を許可することができる。
【０２４７】
７．すべてのアップロードされた書類は筆者と日付情報とを有するスタンプがなされている。
【０２４８】
８．４  書類の見方
書類はオーナや許可を持つユーザだけが見ることができる。許可を持たない人は見ることができない。見る権利は書類レベルで与えられるもので、フォルダレベルでは与えられない。書類が共有されると、その書類への参照が可能となる。複数のコピーされた書類が作成されることなく、これにより資源が節約される。
【０２４９】
書類は日付とともに筆者／送信者の情報でインデックスをつけられる。書類はライブラリから掘り下げ形式で提供される。
【０２５０】
８．５  書類のサーチ
ユーザはメタデータ値に基づいて書類をサーチすることができる。サーチはキーワードに基づく単純なサーチからさまざまなメタデータ要素に基づく高度はサーチがある。すべての書類は標準セットのメタデータ要素を持つ。
【０２５１】
８．６  レポート
コンテンツレポートはシステムにアップロードされたさまざまなコンテンツに関する詳細（メタデータ）を含む：
−日付範囲
−種類
−筆者
−キーワード。
【０２５２】
８．７  警報
８．７．１  ニュース警報
ユーザが関心のあるニュースアイテムは警報として表示される。警報セクションに表示されるニュース警報はユーザによって設定可能である。ユーザの関心領域を選択することができ、その内容と一致するコンテンツが発行されると警報が発生する。ニュース警報はどの種類のコンテンツ（コンテンツ管理に説明されている）が発行されても発生する。
【０２５３】
８．７．２  書類警報
書類警報は主要な書類が他のユーザ／グループと共有されるときに発生する。書類が共有されると書類警報が発生される。警報が発生されると書類警報で見ることができる。
【０２５４】
９．追加的な必要条件
予想できる追加的な条件で初期商品販売には適用されないいくつかの項目がこの章に記載されている。
【０２５５】
下記は提案された商品に関する追加的な条件の一部である。
【０２５６】
９．１  携帯機器
本システムの目的の１つは、システムの利用をなるべくシンプルで便利にすることである。現在市場に存在する数多くの解決策の失敗原因は、面倒なデータ入力過程にある。そこで、工場に持ち込むことができる携帯機器を、データ収集のための便利な装置として使うことができるようにしてもよい。
【０２５７】
機能的な必要条件は下記のようなものがある：
１．携帯機器はバーコードリーダを持つ。在庫のたる、タンク、ロットはバーコードがついているものとする。
【０２５８】
２．バーコードリーダは、もしデータ入力のためキーボードを使用することになっても、アプリケーションの変更が必要にならないよう、データを標準入力に導く。
【０２５９】
３．携帯機器は、仕事場に持ち込むことができるような無線機器である。
【０２６０】
４．携帯機器はＷＡＰのような無線プロトコル、あるいはＲＦシグナルでシステムと通信する。その選択は商品相談の際に決める。
【０２６１】
５．ＷＡＰが使われる場合、携帯機器はＷＡＰが使用可能なものである。
【０２６２】
６．ＲＦシグナルの場合、工場ごとに伝達信号の受信やシステムとインタフェースができるサーバが必要になる。通信を処理する別のアプリケーションも要求される。
【０２６３】
７．携帯機器のデータ（例：タンクのリスト）は常に中央システムと同期化されている必要がある。新しいタンクが加わると携帯機器はドロップダウン内にタンク番号を保持する。
【０２６４】
９．２  選択されたＥＲＰのアダプタ
すでにＥＲＰシステムを持っている大規模なワイン醸造所では本システムとの融合を促進するアダプタをつくることが必要である。そのようなアダプタを作る前に、使用中のシステムの分析が必要である。最初の段階で、バックエンドシステムからＣＳＶファイルが生成され、バッチプロセスを介してアップロードがなされなければならない。
【０２６５】
９．３  外国語サポート
複数の言語をサポートできるシステムが必要である。最初の商品販売は英語のシステムであり、次回の商品販売はフランス語のシステムが予想される。
【０２６６】
９．４  外貨サポート
ソフトウェアの初期バージョンはＵＳドルのみサポートする。しかし後期バージョンは複数の外貨をサポートする必要がある。
【０２６７】
９．５  フローティングライセンス
本商品が大規模なワイン醸造所に向けて販売される場合、ライセンスを管理するためにフローティングライセンス管理機能が必要になる。フローティングライセンス管理機能はユーザ、接続、ログインなどに基づいてさまざまなライセンシングメカニズムをサポートする。
【図面の簡単な説明】
【０２６８】
【図１】図１は第１の実施形態によるシステムのブロック図である。
【図２】図２はサプライ側のチェーン管理アプリケーション実施例の操作を説明する図である。
【図３】図３はウェブベースサプライチェーン管理アプリケーションを導入するためのハードウェア要素を説明する図である。
【図４】図４は収集して分析するデータの種類（dimension）を説明する図である。
【図５】図５はシステムのコアモジュールのプラットフォーム概観を示す図である。
【図６】図６は先行技術によるワイン醸造所の一般的な構造を示す図である。
【図７】図７は本発明によるアイテムマスタを示す図である。
【図８】図８は本発明によるワイン醸造所の工程の流れとさまざまな記録を説明する図である。
【図１】
2008525895.tif 000003
【図２】
2008525895.tif 000004
【図３】
2008525895.tif 000005
【図４】
2008525895.tif 000006
【図５】
2008525895.tif 000007
【図６】
2008525895.tif 000008
【図７】
2008525895.tif 000009
【図８】
2008525895.tif 000010
【手続補正書】
【提出日】平成19年7月3日(2007.7.3)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
薬の開発及び製造を管理する方法であって、
薬に関する情報を記録する工程と、
複数のデータ次元（data dimensions）に含まれる所定のデータ次元に、前記情報を割り当てる工程と、
前記複数のデータ次元に含まれる所定のデータ次元間の相互関係を決定する工程と、
前記情報のコンテキストを決定する工程と、
前記コンテキストに対応して、前記複数のデータ次元に含まれる所定のデータ次元間の相互関係をサーチする工程と、
前記コンテキストに基づいて、薬の開発及び製造に関する情報を抽出し、該抽出した情報により、薬の開発及び製造を管理する工程と
を備えることを特徴とする管理方法。
【請求項２】
前記情報は素材、人、標準、設備、環境／施設、工程のグループから選択された少なくとも１つのデータ次元に割り当てられることを特徴とする請求項１に記載の方法。
【請求項３】
前記コンテキストは、時間とイベントにわたって情報の変化を規定することを特徴とする請求項１に記載の方法。
【請求項４】
前記相互関係は、前記薬に対する異なるデータ次元における共通の情報に関連することを特徴とする請求項１に記載の方法。
【請求項５】
医薬品の開発及び製造過程を管理するシステムであって、
長時間にわたり医薬品の開発履歴及び医薬品の製造履歴を記録する複数の記録モジュールと、
前記複数の記録モジュールと通信を行うことにより、複数のデータ次元にわたって情報追跡ができるプラットフォームを提供するように構成されているコアモジュールと
を備えることを特徴とする管理システム。
【請求項６】
前記コアモジュールは１つのデータ次元に前記情報を割り当てるように構成されていることを特徴とする請求項５に記載のシステム。
【請求項７】
前記コアモジュールは、前記情報を素材、人、標準、設備、環境／施設、工程のグループから選択された少なくとも１つのデータ次元に割り当てるように構成されていることを特徴とする請求項５に記載のシステム。
【請求項８】
コンピュータを用いて医薬品の製造過程を決定する方法であって、
コンピュータを用いて前記医薬品の開発に関連する情報を記録する工程と、
コンピュータを用いて前記医薬品と関連する情報を記録する工程と、
コンピュータを用いて複数の次元におけるデータを相互に関連付けることで、関連付けがなされたデータを生成する工程と、
複数の次元に基づいて長時間にわたって前記医薬品の製造に使われる複数の過程を決定するために、長時間にわたって相互関係のあるデータをサーチすることで、前記医薬品の製造過程を決定していく工程と
を備えることを特徴とする決定方法。
【請求項９】
前記医薬品の製造に使われる過程を決定するため、相互関係のあるデータをコンテキストを用いて長時間にわたってサーチする工程を更に備えることを特徴とする請求項８に記載の方法。
【請求項１０】
前記医薬品の製造に使われる過程を追跡するために、前記相互関係のあるデータをサーチする工程を更に備えることを特徴とする請求項８に記載の方法。
【請求項１１】
前記医薬品の製造と開発に使われる過程を追跡するために、前記相互関係のあるデータをサーチする工程を更に備えることを特徴とする請求項８に記載の方法。
【請求項１２】
前記医薬品の開発に使われる過程を追跡するために、前記相互関係のあるデータをサーチする工程を更に備えることを特徴とする請求項８に記載の方法。
【請求項１３】
前記複数の過程は、前記医薬品の製造と開発に使われる複数の素材を含むことを特徴とする請求項８に記載の方法。
【請求項１４】
コンピュータを用いて医薬品の商品履歴を記録する方法であって、
コンピュータを用いて前記医薬品の開発履歴をキャプチャする工程と、
コンピュータを用いて前記医薬品の製造履歴をキャプチャする工程と、
コンピュータを用いて前記開発履歴及び前記製造履歴を記録する工程と、
前記医薬品の商品履歴である前記医薬品の製造履歴及び開発履歴の多次元データセットを作成する工程と
を備えることを特徴とする記録方法。
【請求項１５】
前記医薬品の商品履歴を追跡するために、前記多次元データセットをサーチする工程を更に備えることを特徴とする請求項１４に記載の方法。
【国際調査報告】
2008525895.tif 000011