JP4593290B2 - マスタデータ管理における配信 - Google Patents

Description

本発明は、データ処理に関し、データ管理システムにおけるデータの配信(distributing)に関する。

情報技術（“ＩＴ”）環境は、共通マスタデータ(common master data)上で、業務処理(business process)のような、処理を遂行する多くの異なるシステムから構成され得る。この異なるシステムは、ベンダー(vendor)または請負業者(contractor)のような、異なるエンティティ(entity)の一員であり、または同一のエンティティの一員であり得る。上記処理に使用されるマスタデータは、多くの異なる場所、システム、及び／又は互換性のないフォーマットで記憶される。会社の支社(branch office)は、極めて独立して活動することができ、採択会社(adopted companies)は、新たなソフトウェアソリューションを提携会社のグループに導入し、異なるベンダーからのシステムを連結することができる。異なるマスタデータモデルは、業務処理をこれらのシナリオに統合することを困難にする。

マスタデータは、異なるシステムに捕捉(trap)され貯蔵(silo)されるようになることができる。ＩＴ環境にわたって調整されていないマスタデータは、データ過剰および無意味な又は間違った情報をもたらす。例えば、もし国際企業の二つの地方支店がそれぞれ第２の国際企業の同一の地方支社を取引先として持っていれば、各国際取引先は、二つの“取引先”マスタデータオブジェクト間に何の相互関係もなく、２度も保持される。これは、冗長な多数のコンテンツメンテナンスのための高コストを招く。さらに、冗長または陳腐な情報を用いて実施されるビジネス分析論は貧弱なビジネス判断をもたらす。上述の例では、全社的な分析論処理(company-wide analytic process)は、“二つ”の取引先の間の相互関係を検出することに失敗し、そして、二つの地方支社と共に国際的取引先としてこれらの取引先を承認することから利用できるビジネス価値は失われるであろう。

本発明は、同種の環境(homogeneous environment)においてデータを共有(sharing)するためのコンピュータプログラムプロダクトを含む方法および装置を提供する。
概して、一つの態様において、本発明は、データ管理システムにおいてデータを配信するためのコンピュータプログラムプロダクトを含む方法および装置を特徴づける。本技術は、配信のためのセントラルデータストア(central data store)における１又は２以上のオブジェクトを識別するステップと、上記１又は２以上のオブジェクトのうちの少なくとも１つのオブジェクトのためにルーティング(routing)が存在するかを決定するステップと、上記ルーティングによって特定される１又は２以上の目標システムに上記少なくとも１つのオブジェクトを配信するステップとを含む。上記１又は２以上のオブジェクトは、データ管理システムにおける全てのシステムが使用するためのマスタデータオブジェクトを含み、上記１又は２以上の目標システムはデータ管理システムの一部である。

本発明は、１又は２以上の以下の有利な特徴を含むように実施され得る。上記少なくとも一つのオブジェクトは、即座に及び／又は定期的に配信され得る。１又は２以上のオブジェクトを識別するステップは、１又は２以上のオブジェクトのパケットを識別するステップを含み、ここで、上記少なくとも一つのオブジェクトを配信するステップは、上記１又は２以上のオブジェクトのパケットを配信するステップを含む。

上記少なくとも一つのオブジェクトのパケットは、即座に及び／又は定期的に配信され得る。また、本技術は、上記オブジェクトのどの部分が配信され得るかを決定するステップを含む。さらに、本技術は、どのオブジェクトが上記１又は２以上の目標システムによって要求されるかを示す上記１又は２以上の目標システムからの情報を受信するステップを含む。少なくとも一つのオブジェクトを供給すべき１又は２以上の目標システムを決定するステップは、上記１又は２以上の目標システムから受信された予約情報(subscription information)に基づき少なくとも一つのオブジェクトを供給すべき１又は２以上の目標システムを決定するステップを含むことができる。

頻度情報(frequency information)は、上記１又は２以上の目標システムから受信されることができ、どのくらいの頻度で上記少なくとも一つのオブジェクトを上記１又は２以上の目標システムに配信するかを示し、そして、上記少なくとも一つのオブジェクトを配信するステップは、上記受信された頻度情報により示される頻度で上記少なくとも一つのオブジェクトを配信するステップを含むことができる。配信日付情報(distribution date information)は、上記１又は２以上の目標システムから受信されることができ、何れの日から上記少なくとも一つのオブジェクトを上記１又は２以上の目標システムに配信すべきかを示し、そして、上記少なくとも一つのオブジェクトを配信するステップは、上記受信された配信日付情報によって示される日付から上記少なくとも一つのオブジェクトを配信するステップを含むことができる。

少なくとも一つのオブジェクトを供給すべき１又は２以上の目標システムを特定するユーザー入力は、受信されることができ、少なくとも一つのオブジェクトを供給すべき上記１又は２以上の目標システムを決定するステップは、上記ユーザー入力に応答して上記１又は２以上の目標システムを決定するステップを含むことができる。上記少なくとも一つのオブジェクトを供給すべき上記１又は２以上の目標システムの識別(identification)は、上記少なくとも一つのオブジェクトのための配信プロファイル(distribution profile)に格納されることができ、上記少なくとも一つのオブジェクトを配信するステップは、上記少なくとも一つのオブジェクトのための上記配信プロファイルに基づき上記少なくとも一つのオブジェクトを配信するステップを含むことができる。

上記１又は２以上の目標システムから受信された情報は、上記少なくとも一つのオブジェクトのための配信リストに格納されることができ、ここで、上記情報は、予約情報(subscription infoormation)、配信開始情報、頻度情報、および受信者タイプ情報のうちの１又は２以上を含む情報を含む。１又は２以上の上記識別されたオブジェクトは発行(publish)されることができ、ここで、上記１又は２以上の発行されたオブジェクトは、クライアントシステムによる予約(subscription)のために利用可能であり得る。

報告(report)が生成されることができる。該報告を生成するステップは、発行されたオブジェクト、オブジェクトの配信および予約のうちの少なくとも一つに関する情報を含む報告を生成するステップを含むことができる。オブジェクトの配信に関する報告を生成するステップは、オブジェクトの最後の配信およびオブジェクトのローカルな複製(local replicate)のうちの一つに関する情報を含む報告を生成するステップを含むことができる。また、上記報告は、処理モニタリング報告(process monitoring report)、またはステージング報告(staging report)を含むことができる。

概して、一態様において、本発明は、動的アクセスデータを受信するために、コンピュータプログラムプロダクトを含む方法および装置を特徴づける。本技術は、セントラルシステムに格納されたオブジェクトをクライアントシステムから検索するステップを含むことができ、ここで、上記オブジェクトは、上記クライアントシステムが予約を承認されたオブジェクトと、発行されたオブジェクトとを含み、利用可能なオブジェクトのリストから１又は２以上のオブジェクトを予約し、そして上記予約に応答して上記セントラルシステムからデータを受信する。

本発明は、１又は２以上の以下の有利な特徴を含むように実施されることができる。上記セントラルシステムからデータを受信するための配信頻度は定義されることができ、配信開始日付は定義されることができ、且つ、１又は２以上のオブジェクトを予約するステップは、利用可能なオブジェクトの上記リストから配信プロファイルを選択するステップを含むことができる。

概して、一態様において、本発明は、データを共有するためのシステムを特徴づける。本システムは、１又は２以上のクライアントシステムと、エンティティのセントラルモジュールとを備える。上記セントラルモジュールは、上記エンティティについてデータを格納するためのセントラルデータストア(central data store)を備え、ここで、上記データオブジェクトは、上記１又は２以上のクライアントシステムが使用するためのものである。上記セントラルモジュールは、データオブジェクトを選択して上記１又は２以上のクライアントシステムに配信するように構成されると共に、データオブジェクトの予約、データオブジェクトのヒストリックな予約、およびルールベースのルーティングのうちの１又は２以上に基づき、上記１又は２以上のクライアントシステムにデータオブジェクトを配信するように構成される。

本発明は、１又は２以上の以下の有利な特徴を含むように実施されることができる。また、本セントラルモジュールは、上記１又は２以上のクライアントシステムへのデータオブジェクトの配信に関する報告を生成するように構成されることができる。上記報告は、発行関連報告(publishing related report)、予約関連報告(subscription related report)、配信関連報告(distribution related report)、処理モニタリング報告およびステージング報告のうちの１又は２以上を含むことができる。

本発明は、１又は２以上の以下の利点を実現するように実施されることができる。マスタデータのための協調マスタデータ管理システム(collaborative master data management system)は、集中化されたマスタデータの管理を可能とする。集中されたデータ配信は、クライアントシステムへのマスタデータの一貫(consistent)した配信を可能にする。データ配信の方法および頻度において柔軟性が提供される。データは、個々のデータオブジェクトで、又はデータのパケットで配信されることができる。データは、即座に又は定期的に配信されることができる。データは、そのデータを必要とするシステムにのみ供給される。セントラルシステムは、データオブジェクトのコンテンツ又はクライアントシステムの要求(needs)に基づき、何のデータが何れのクライアントシステムに配信されるかを決定するであろう。いくつかのケースでは、クライアントシステムは、データ配信を予約(subscribe)することができる。

本発明の１又は２以上の実施例の詳細は、添付の図面と以下の説明において述べられる。本発明の他の特徴および利点は、その記載、図面および特許請求の範囲から明らかになるであろう。
種々の図面における同様の参照番号および記号表示は同様の要素を示す。

図１Ａに示されるように、協調マスタデータ管理（“ｃＭＤＭ”; collaborative Master Data Management）システムは、セントラルモジュール１００と１又は２以上のクライアントモジュール１１０とを備える。各クライアントモジュール１１０は、セントラルモジュール１１０に直接的に連結(link)されている。

セントラルモジュール１１０は、業務(bisiness)又は組織(organization)のようなエンティティ(entity)のためのデータ管理の集中化された制御を表すセントラルシステムを備える。クライアントモジュール１１０は、マスタデータに関する処理を実施するグループ又はシステムを備えることができる。例えば、クライアントモジュール１１０は、プロダクト作成処理(product creation process)に含まれるグループ及び／又はシステムを備えることができる。この例では、クライアントモジュール１１０は、レガシーモジュール(legacy module)、電子調達モジュール(e-procurement module)、電子販売モジュール(e-sale module)、調達モジュール(sourcing module)、協調エンジニアリングモジュール(collaborative engineering module)、製作モジュール(manufacturing module)、および統合業務ソフト(EPR; Enterprise Resoource Planning)モジュールを含むことができる。

マスタデータは、実施に応じて、クライアントモジュール１１０に、セントラルモジュール１００に、またはその両方に格納されることができる。セントラルモジュール１００は、各クライアント１１０によって使用されるマスタデータが全てのクライアント１１０によって共有されるマスタデータを含むことを可能にする。従来、クライアントモジュール１１０は、ポイント・ツー・ポイントアーキテクチャ(point-to-point archtecture)で互いに直接的に通信する。例えば、製作モジュールは、マスタデータを、とりわけ、電子調達モジュール、電子販売モジュール、および協調エンジニアリングモジュールと共有することを必要とするかもしれない。従来のシステムにおいて、上記製作モジュールは、適切なモジュールに対してデータを送受信し、これは、もし、共有のためにデータを送信するモジュールにおいてこのデータが更新されなければ、陳腐なデータの使用またはデータにおける不一致(inconsistency)を招く。図１Ａおよび１Ｂを参照して述べられるシステムにおいて、データは、セントラルモジュール１００を通して管理される。このセントラルモジュール１００は、一貫したマスタデータと、このマスタデータの配信を保証する。

図１Ｂに示されるように、ｃＭＤＭシステムは、複数のエンティティ１２０，１３０にわたって使用されるように実施されることができる。セントラルモジュール１００は、ベースエンティティ(base entity)１２０の一部であることができる。クライアントシステム１１０は、ベースエンティティ１２０の一部または外部エンティティ１３０の一部であることができる。例えば、ベースエンティティ１２０は、ＥＲＰ、レガシー、電子調達、および電子販売のためのクライアントモジュール１１０を備える企業(enterprise)を含むことができる。ベースエンティティは、ユニット１４０に分割されることができ、ここで、各ユニットは、１又は２以上のクライアント１１０を備えることができる。上記外部のエンティティ１３０は、製作のためのクライアント１１０を含む請負業者(contractor)、および協調エンジニアリング(collaborative engineering)および調達(sourcing)のためのクライアント１１０を備える供給業者(supplier)を含むことができる。

他の例では、ベースエンティティ１２０は、顧客サービスエンティティを含むことができる一方、外部のエンティティ１３０は企業を含むことができる。通常は複数のクライアントモジュール１１０に分散される顧客情報は、セントラルシステム１００を通して連結(consolidate)されることができる。

集中的に管理されるマスタデータは、グループ間共通の報告(cross-group report)、合併買収(mergers and acquisition)のためのデータ統合(data integration)、部品の多様性(diversity of parts)を低減すること、プロダクト保守の支援、顧客管理の簡略化のような処理(process)、および、目録コンテンツを併合すること及びより少ない数の小売店への購買活動(purchasing activity)の一括販売(bundling)を通じて行うような目録の支援のために使用されることができる。また、ｃＭＤＭシステムは、バージョニング(versioning)を支援すると共に管理を変えることができる。バージョンが作成され又は変更がなされると、そのバージョンのデータ又は変更されたデータは、以下に述べるように、セントラルモジュール１００を通じて管理されることができる。

ｃＭＤＭのセットアップは、ｃＭＤＭシステムとクライアントモジュール１１０との間でデータが交換される前に実施されることができる。識別属性(identification attribute)がマスタデータオブジェクトのために特定され、マッチングのためのルールが制定される。属性(attribute)のセットアップとマッチングのためのルールは、一般にオブジェクトの需要に関して、又はｃＭＤＭシステムを用いたエンティティに関して実施されることができる。クライアントモジュールから受信されたマスタデータオブジェクトについて実施されるマッチング処理は、マスタデータオブジェクトを管理するために使用されることができる。

属性の特定は、異なるクライアントアプリケーション又は異なるクライアントモジュール１１０からの異なるオブジェクトをマッチングすることを含むことができる。また、属性の特定は、異なるクライアントシステムから受信されたマスタデータオブジェクトが比較され得るように、マッチングされたストラクチャ(structure)の要素を互いに結合することを含むことができる。

また、特定された属性は、セットアップ中にランク付けされることもできる。属性のランク付けは、二つのマスタデータオブジェクトが同一かどうかを決定するためのマッチング処理中に使用されることができる。従って、もし、高くランク付けされた属性が二つのオブジェクト間でマッチングしなければ、リスト上で低くランク付けされた属性がマッチングしない場合よりも、それらは同一ではなく、または類似していない。

ｃＭＤＭシステムは、図２−７を参照して説明されるように、少なくとも３つの異なるシナリオで実施されることができる。このシナリオは、コンテンツ連結シナリオ(content consolidation scenario)から始めて、マスタデータ調和(master data harmonization)シナリオに移動し、またはマスタデータ調和シナリオからセントラルマスタデータ管理(central master data management)シナリオに移動することにより、個別に実施されることができ、または、斬新的な方法で導入されることができる。また、異なるシナリオは、一緒に使用されることができる。例えば、セントラルマスタデータ管理は幾つかのオブジェクトタイプに対して使用されることができる一方、マスタデータ調和はその残りに対して使用される。上記シナリオの混合は、以下で更に詳しく説明されるであろう。

＜コンテンツ連結(content consolidation)＞
図２は、ｃＭＤＭシステムのためのコンテンツ連結シナリオを図解するブロック図である。セントラルモジュール１００は、ロードモジュール(load module)２１０、ステージングモジュール(staging module)２２０、マッチモジュール(match module)２３０、およびＩＤマッピングモジュール(ID mapping module)２４０を備えることができる。セントラルモジュール１００で実施された処理で得られた連結コンテンツ(consolidated content)は、総合目録（例えば、供給業者プロダクト目録）の作成または経営分析(business analysis)（例えば、全体支出分析）のような処理２５０において使用されることができる。

ロードモジュール２１０では、マスタデータオブジェクトは、セントラルモジュール１００に受信される。マスタデータオブジェクトは、それらがそれらのローカルアプリケーション（クライアントモジュール１１０）に保持されていた形式でセントラルモジュール１００にアップロードされる。ステージングモジュール２２０では、セントラルモジュール１００のユーザーは、マスタデータオブジェクトが正しくロードされるか決定することができる。例えば、ユーザーは、ロードモジュール２１０にロードされたマスタデータオブジェクトのコンテンツをチェックして、マスタデータオブジェクトが正しいことを確かめることができる。マスタデータオブジェクトは、マスタデータオブジェクトのコンテンツを標準化(standardize)するためにステージングモジュール２２０においてクレンジング(cleanse)されることができる。例えば、もし、Ｎｅｗ Ｙｏｒｋを短縮するための標準形式が“ＮＹ”であり、且つ入力マスタデータオブジェクトのコンテンツの一つが、“Ｎ．Ｙ．”のような短縮形を有していれば、入力マスタデータオブジェクトのコンテンツは、“Ｎ”と“Ｙ．”との間のピリオドを削除することにより“ＮＹ”に変えられることができる。また、データクレンジング(data cleansing)は、過ち(mistake)と不一致(inconsistencies)を排除して、データを一層正確にすることができる。

また、ステージングモジュール２２０は、マスタデータクライアントのための受信されたマスタデータオブジェクトのために中間ストレージ(intermediate storage)として使用されることができる。中間ストレージは、マッチモジュール２３０およびマッピングモジュール２４０に関して以下でそれぞれ説明されるマッチングおよびマッピングの処理の期間中に使用されることができる。また、中間ストレージは、マスタデータオブジェクトのアップロード前の個々のユーザーのやりとり(interaction)の期間中に使用されることもできる。

また、マッチング処理は、ステージングモジュール２２０において完結されることができる。マスタデータオブジェクトは、マッチモジュール２３０に転送される。もし、マッチモジュール２３０が、識別された属性に基づきマスタデータオブジェクトを自動的にマッチ(match)させなければ、マスタデータオブジェクトは、そのマスタデータオブジェクトがマッチするかどうかを手動で決定するためにステージングモジュールに戻されることができる。

マッチモジュール２３０では、マッチング処理が同一または類似のデータオブジェクトを識別するために、アップロードされたマスタデータに関して実行されることができる。同一のデータオブジェクトは意味的(semantically)に同一であるマスタデータであり、それは異なるクライアントモジュール１１０から受信される。同一のデータオブジェクトは異なる二つのオブジェクトＩＤを持つことができる。複製データオブジェクト(duplicate data object)は、クライアントモジュール１１０のような、同一システム内の意味的に同一のマスタデータオブジェクトである。可能性のある複製(possible duplicate)は、自動的に認識されて報告される。１又は２以上の複製データオブジェクトは、クライアントシステムから除去されることができる。

マッチング処理は、マスタデータオブジェクト間の類似性を認識するステップを含む。マッチング処理は、データオブジェクトの属性を識別するステップと、この属性を比較するステップとを含むことができる。属性の内容がシステムごとに違っていても、同一または類似のデータオブジェクトが認識されることができるように、比較される属性は、マスタデータオブジェクトタイプについて妥当なエンティティ規模(valid entity-wide)である属性を含むことができる。従って、異なるデータ形式および構造が、異なるシステムにおいて保持されることができる。

もし、二つのマスタデータオブジェクト間のマッチ(match)の総量が或る範囲内であれば、マッチング処理の結果は未解決(unresolved)と考えられるかもしれない。例えば、もし二つのマスタデータオブジェクトが５０〜８０％だけマッチすれば、マッチング処理の結果は、未解決と考えられることができる。例えば、もしマッチされるマスタデータオブジェクトが取引先(business partner)であり、且つ５つの属性のうちの４つが他の取引先マスタデータオブジェクトとマッチすれば、マッチの総量は８０％であろう。従って、二つのオブジェクトがマッチするかどうかの問題は未解決と考えられる。マスタデータオブジェクトが他のマスタデータオブジェクトとマッチするかどうかをユーザが手動で決定するために、マスタデータオブジェクトはステージングモジュールに戻されることができる。

マッピングモジュール２４０は、マッチモジュール２３０からマッチング処理の結果を受信する。マッピングモジュール２４０では、類似または同一のオブジェクトは、互いにマッピングされることができる。例えば、一つのオブジェクトのオブジェクト識別（“ＩＤ”）は、類似または同一のオブジェクトのオブジェクトＩＤにマッピングされることができる。マッピング情報は、変化がデータオブジェクトになされる度に更新されることができる。マッピングは、マスタデータ管理システムのセットアップ中に確立されるルールに基づいて自動的に実行されることができる。マッピングは、マッピングテーブルに格納されることができる。マッピング情報は、マスタデータオブジェクトに対してなされる変化に基づき変わることができる。例えば、もし、マスタデータオブジェクトＡにおける“Ｎ．Ｙ．”が“ＮＹ”に変えられれば、マスタデータオブジェクトＡにマッピングされなかったマスタデータオブジェクトは、マスタデータオブジェクトＡと同一と考えることができ、そして、マスタデータオブジェクトＡにマッピングされたマスタデータオブジェクトは、変更される必要があるであろう。従って、クライアントモジュール１１０に利用可能なマッピング情報を作成することによりマッピング情報の更新とマッピング情報を通して変更が管理されることができる。同様に、データオブジェクトのグループからなる新たなバージョンが定義され、マッピング情報の更新とマッピング情報はバージョンを管理するために使用されることができる。

マッピング情報は、処理モジュール２５０に供給されることができる。処理モジュール２５０は、システム規模の報告(system-wide reporting)のために、企業情報ウェアハウス(business information warehouse)のようなデータウェアハウス(data warehouse)を備えることができる。処理モジュール２５０で実行される処理は、全体的支出分析又は合併・買収のような、企業規模の分析および報告または総合目録(central catalog)の作成を含むことができる。

図３は、データを連結するための方法を図解するフロー図である。データは、１又は２以上のクライアントモジュール１１０からセントラルモジュール１００に受信される。（ステップ３１０）もし、受信されたコンテンツデータがセントラルモジュール１００におけるセントラルシステムのコンテンツとそろわなければ、受信されたデータはクレンジングされることができる。

同一または類似のオブジェクトがセントラルシステムに存在するかを決定するために、マッチング処理は、セントラルシステムにおいてデータのオブジェクトに関して実行される。（ステップ３２０）このマッチング処理は、オブジェクトの属性を比較し識別するステップを含むことができる。また、マッチング処理は、複製を識別するステップを含むことができる。もし、二つ又はそれ以上のオブジェクトが複製オブジェクトであることがわかれば、１又は２以上の複製オブジェクトは、セントラルモジュールに入れられることを回避されることができる。複製マスタデータオブジェクトは、ステージングモジュール２２０に転送され、ここでは、複製マスタデータオブジェクトの一つが、セントラルモジュール１００から除去される。また、ｃＭＤＭは、複製オブジェクトが受信されたシステムからの１又は２以上の複製マスタデータの除去を支援することができる。

もし、同一または類似のオブジェクトが見つけられれば、セントラルモジュールは、マッピング処理を実行することができる。（ステップ３３０）同一オブジェクトのオブジェクトＩＤは互いにマッピングされることができ、且つ類似オブジェクトのオブジェクトＩＤは互いにマッピングされることができる。オブジェクトマッピング情報は、処理に供給されることができる。（ステップ３４０）上述したように、マッピング情報を処理に供給するステップは、システム規模の分析および報告における使用のために、企業情報ウェアハウスのように、マッピング情報をデータウェアハウスに供給するステップを含むことができる。また、マッピング情報は、クライアントモジュール１１０に供給されることができる。

＜マスタデータ調和(Master Data Harmonization)＞
図４は、ｃＭＤＭについての第２のシナリオを図解するブロック図である。この第２のシナリオは、マスタデータ調和の実施(master data harmonization implementation)を含む。このシナリオは、マスタデータストレージをコンテンツ連結の実施(content consolidation implementation)に加えることにより実施されることができる。このシナリオは、マスタデータの全体的属性(global attributions)の一貫した配信およびメンテナンスを可能にするために使用されることができる。セントラルモジュール１００において実行される処理によってもたらされた調和されたコンテンツは、クライアントモジュール１１０および処理モジュール２４０に配信されることができ、この処理モジュール２４０は、例えば、取引先管理(business partner administration)、売品(sales article)のセントラル供給(central provision)、非可変部品(non-variable parts)の管理および定義のような用途で使用されるものである。

マスタデータオブジェクトは、セントラルモジュール１００、セントラル作成モジュール４１０、またはクライアントモジュール１１０で作成されることができる。クライアントモジュール１１０で作成されたマスタデータオブジェクトは、ステージングモジュール４２０において受信される。一部のマスタデータオブジェクトと、マスタデータオブジェクト間のマッピングとは、セントラルモジュール１００に格納されることができる。格納されたマスタデータオブジェクトの一部は、このマスタデータオブジェクトの全体的属性を含むことができる。

セントラル作成モジュール４１０で作成されたマスタデータオブジェクトは、マスタデータオブジェクトの全体的属性のみを含むように作成されることができる。全体的属性は、識別属性(identifying attribute)を含むことができる。各オブジェクトタイプについてどの属性が保持されるべきかは、情報要件(information requirement)およびシステムランドスケープ(system landscape)に依存する。フレームワークはｃＭＤＭに加えられて、ローカルシステムにおいてマスタデータオブジェクトを作成するために使用されるソフトウェアの修正を何ら行うことなくオブジェクトモデルを拡大することができる。フレームワークは、新たな課題(issue)および新たな分野(field)を取り扱う。例えば、オブジェクトデスクリプション（オブジェクトのためのデータモデル）は、セントラルインスタンス(central instance)に合わされることができる。例えば、フィールドは、他のシステムのためのデータモデルには存在しない或るシステムにおけるモデルに存在してもよい。また、フレームワークは、異なる属性フィールドを有するマスタデータオブジェクトを受信するクライアントシステムのためのユーザーインターフェイスを更新することを支援することができる。以下に説明するように、オブジェクトの配信後、配信されたオブジェクトは、クライアントモジュール１１０における属性値を備えることができる。

ローカルに作成されたマスタデータオブジェクトは、クライアント１１０のローカルなアプリケーションを用いて作成されることができる。クライアントモジュール１１０は、ローカルに作成されたマスタデータオブジェクトの全体的属性をステージングモジュール４２０に配信することができる。クロスシステムサーチ(cross system search)は、クライアントモジュール１１０で作成される前にマスタデータオブジェクトのためになされることができる。マスタデータオブジェクトは、類似したマスタデータオブジェクトが存在しなければ作成される。もし、類似したマスタデータオブジェクトが存在すれば、セントラルモジュール１００は、類似したマスタデータオブジェクトをクライアントモジュール１１０のユーザーに利用可能にする。例えば、セントラルモジュール１００は、類似したマスタデータオブジェクトを、サーバーを通してクライアントモジュール１１０のユーザーに利用可能にすることができる。従って、類似したマスタデータオブジェクトは、セントラルモジュール１００におけるサーバーに転送され、そしてクライアントモジュール１１０でのクライアントシステムに送信されることができる。

ユーザーは、類似したマスタデータオブジェクトを予約することができ、そしてマッピング情報は、新たなローカルシステムを含むように更新されることができる。もし、類似したオブジェクトが見つからなければ、マスタデータオブジェクトの作成後、作成されたマスタデータオブジェクトは、他の目標システム(target system)に送信されることができる。

連続的なマッチング処理は、マッチング及びマッピングモジュール４３０で実行されることができる。例えば、マッピングは、セントラル作成モジュール４１０においてマスタデータオブジェクトを作成するための要求に応答して実行されることができる。連続的なマッチング処理は、同一および類似のデータオブジェクトを識別するために使用されることができる。この同一および類似のデータオブジェクトは、上述のように、互いにマッピングされることができる。

マッチング処理によって識別された複製オブジェクト(duplicate objects)は、ローカルシステムにおいて作成されることを回避される。例えば、もし、ローカルシステムが新たな取引先のためのマスタデータオブジェクトを要求すれば、セントラルモジュール１００のユーザーは、取引先マスタデータオブジェクトがセントラルモジュール１００に既に存在するかを確認することができる。もし、取引先マスタデータオブジェクトがセントラルモジュールに存在すれば、マスタデータオブジェクトは、新たなマスタデータオブジェクトを要求するクライアントシステムに配信されることができる。もし、既存の取引先マスタデータオブジェクトが目標システム(target system)に既に存在することをユーザーが認識すれば、複製マスタデータオブジェクトの作成が回避される。マッピング情報は、ビジネス規模の分析のような処理ために処理モジュール２４０に供給されることができる。

マッピング情報を含むマスタデータオブジェクトの全体的属性は、配信モジュール４４０を通して種々のクライアントモジュール１１０に配信されることができる。従って、全てのシステムは、配信後に同一の全体的属性が供給され、そして業務処理は安全に処理されることができる。論理的にグループをなすオブジェクトは、一緒に配信されると共に変更されることができる。例えば、マスタデータがプロダクトのためのマスタデータを備える場合、プロダクト構造(structure)および文書(document)のような、そのプロダクトに属するオブジェクトは、パケットに一緒に収集されて、一つのコンテキストで受信者のクライアントモジュール１１０に配信されることができる。パケットは、プロダクト構造におけるオブジェクトのように、依存性(dependencies)を含む関係を通して結合された個々のオブジェクトのグループを含む。パケットは、受信者のクライアントモジュール１１０の情報要件に従って収集されることができ、そして或るシーケンスで転送されることができる。

例えば、もし、ＢＯＭが変化し又は目標システムに配信されるのであれば、いくつかの特定のシステムのためのマッピングに関連したルールは、特定のシステムが材料(materials)のためのプロダクトＩＤを認識できるように、材料のためのプロダクトマスタがＢＯＭの前に特定のシステムに送信されなければならないことを示すことができる。従って、配信するオブジェクトの順序づけ(sequencing)は、目標システムの要件および動作(semantics)を満たすことを可能とされることができる。

クライアントモジュール１１０は、ローカルな環境において、受信されたマスタデータオブジェクトのためのマスタデータ情報を完成することができる。また、マスタデータへの変化は、セントラルモジュール１００において主に管理されることができる。この変化は受信され、承認され、そしてクライアントモジュール１１０に配信される。

セントラルモジュール１００で作成されたマスタデータは、クライアントモジュール１１０からの要求に応答して作成されることができる。例えば、クライアントシステムを使用するクライアントモジュール１１０でのビジネスユーザーは、新たなプロダクトマスタのための要求フォームに記入し、そしてそのフォームを、セントラルモジュール１００におけるセントラルシステムのユーザーに送信することができる。フォームは、このフォームが正しく記入されたことを保証するためにチェックされることができる。例えば、フォームは意味的にチェックされることができ、または、測定(measurement)のユニット(unit)は正しいユニットが使用されることを保証するためにチェックされることができる。セントラルシステムのユーザーは、要求を見て受諾(view and accept)することができる。そして、セントラルシステムでのユーザーは、複製のためにチェックし、与えられた情報を完成させ、そして新たなプロダクトマスタを作成して配信することができる。

図５Ａおよび５Ｂは、マスタデータ調和のための方法を図解するフロー図である。図１Ａ、１Ｂおよび５Ａを参照すると、マスタデータ調和は、クライアントモジュール１１０と同様にセントラルモジュール１００におけるマスタデータオブジェクトの作成を含むことができる。（ステップ５１０）

マスタデータオブジェクトは、マスタデータ調和における３つの方法で作成されることができる。新たなマスタデータオブジェクトは、セントラルモジュール１００で直接的に作成されることができ、または新たなマスタデータオブジェクトは、クライアントモジュール１１０からの要求に応答してセントラルモジュール１００において作成されることができる。また、マスタデータオブジェクトは、クライアントモジュール１１０においてローカルに作成され、そしてステージングモジュール４２０に転送されることができる。クライアントモジュール１１０においてローカルに作成されたマスタデータは、セントラルモジュール１００にアップロードされることができる。

作成されたオブジェクトは、セントラルモジュール１００に格納されることができる。セントラルモジュール１００に格納されたマスタデータオブジェクトは、マスタデータオブジェクトの全体的属性を含むことができる。

連続的マッチング処理は、格納されたマスタデータオブジェクトについて実施されることができる。（ステップ５２０）上記連続的マッチング処理は、複製、同一および類似のデータオブジェクトを識別するために使用されることができる。見つけられた複製オブジェクトが除去され、かつ、同一および類似のオブジェクトのオブジェクトＩＤがマッピングされることができる。

マスタデータオブジェクトの全体的属性およびマッピング情報を含むマスタデータオブジェクト情報は、クライアントモジュール１１０に配信されることができる。（ステップ５３０）クライアントシステムにおいて受信されたマスタデータオブジェクトのためのマスタデータ情報は、クライアントモジュール１１０において完成されることができる。（ステップ５４０）

図５Ｂは、上述のようにマスタデータがローカルに作成されるマスタデータ調和の方法を図解する。マスタデータオブジェクトはローカルに作成される。（ステップ５５０）。このローカルに作成されたマスタデータオブジェクトはステージ(stage)される。（ステップ５６０）。

＜セントラルマスタデータ管理＞
図６は、ｃＭＤＭシステムのセントラルマスタデータ管理の実施例を図解するブロック図である。セントラルマスタデータ管理シナリオにおいて、マスタデータは、セントラルモジュールにおいて完全に制御される。この実施例において、全てのマスタデータ情報は、主にセントラルモジュール１００に存在する。この実施例は、製造、組み立て、販売および配信のために複数の場所にプロダクトデータを供給するセントラルプロダクトデータプール(central product data pool)のような用途に使用されることができる。

セントラル作成モジュール６１０では、マスタデータオブジェクトが作成されることができる。この作成されたマスタデータオブジェクトは、完全なオブジェクト定義、オブジェクトマッピング情報およびオブジェクト依存性を含む完全なオブジェクト情報を含むことができる。マスタデータオブジェクトは、クライアントモジュール１１０からの要求に応答して作成されることができる。マッチング処理は、この要求に応答して実施され、そしてマッピング情報は、セントラルモジュール１００に格納されたデータオブジェクト情報に含まれることができる。もし同一のオブジェクトがセントラルモジュール１００に存在すれば、要求しているクライアントモジュール１１０は、同一のオブジェクトが存在し、且つ、新たなマスタデータオブジェクトが作成されず、または既存のオブジェクトにマッピングされることが通知されることができる。マッピング情報は更新されることができる。

配信モジュール６２０では、主に保持されるマスタデータ情報は、クライアントモジュール１１０で定義されるような個々のオブジェクトとして配信されることができる。このオブジェクトはパケットで配信されることができる。グループを成すオブジェクトは、変更され、そして一緒に配信されることができる。もしマスタデータがプロダクトモデルを含めば、ＢＯＭ(bills of material)およびドキュメントのプロダクトのようなグループを成すオブジェクトは、一貫したパケットに一緒に収集されて、一緒に配信される。オブジェクトは、受信者クライアントモジュール１１０の情報要件(information requirement)に従って収集されることができる。例えば、オブジェクトは、プロダクトの特別なビュー(view)を参照して収集されることができる。ビューは、購入日(purchasing date)のようなプロダクト関連属性(product relevant attribute)を含むことができる。従って、オブジェクトのグループは、使用法(usage)または場所(location)に応じて結合されることができる。例えば、販売ビューは、販売部門によって使用され又は販売部門に関連したオブジェクトのコンテンツまたは属性を含むことができる。

上述したように、シナリオは一緒に使用されることができる。例えば、セントラルマスタデータ管理は、取引先マスタデータオブジェクトのために使用されることができ、ここで、全ての取引先マスタデータオブジェクト情報はセントラルモジュール１００に保持される。セントラルモジュール１００は、プロダクトマスタデータオブジェクトのような、残りのデータオブジェクトのための全体的属性のみを格納することができる。

図７は、セントラルマスタデータ管理のための方法を図解するフロー図である。セントラルマスタデータ管理処理は、同質な環境(homogeneous environment)において実施されることができる。図１Ａ、１Ｂおよび６を参照すると、少なくとも一つのデータオブジェクトがセントラルモジュール１００において作成される（ステップ７１０）。セントラルモジュール１００は、ｃＭＤＭシステムのためのセントラルシステムを備えることができる。セントラルモジュール１００は、クライアントモジュール１１０に配信できる完全なデータオブジェクト情報を格納することができる。従って、作成されたデータオブジェクトは、完全なオブジェクト定義を含む完全なオブジェクト情報、データオブジェクトを他のオブジェクトにマッピングするマッピング情報、および他のオブジェクトに対する依存性を含むことができる。

データオブジェクトは、このデータオブジェクトを作成するためのクライアントモジュール１１０からの要求の受信に応答して作成されることができる。マッチング処理は、類似または同一のデータオブジェクトがセントラルシステムに存在するかどうかを判断するために上記要求に関して実施されることができる。もし類似または同一のデータオブジェクトが見つかれば、この同一のデータオブジェクトは、要求しているシステムに配信され、この配信されたオブジェクトは自動的にマッピングされるであろう。

セントラルシステムからのデータオブジェクトは、１又は２以上のクライアントモジュール１１０に配信されることができる。（ステップ７２０）データオブジェクトの配信は、このデータオブジェクトをクライアントモジュール１１０に配信することを含む。データオブジェクトは、パケットで配信されることができる。このパケットは、受信者クライアントモジュール１１０から受信された要件情報(requirement information)に基づきセントラルモジュール１００において定義されることができる。

また、セントラルマスタデータ管理の方法は、セントラルモジュール１００に格納されたデータオブジェクトの更新およびデータオブジェクトに対する変更を実施することを含むことができる。更新されたデータオブジェクトは、クライアントモジュール１１０に配信されることができる。

＜マスタデータ管理システム＞
図８は、セントラルモジュール１００の簡略化された構成を図解するブロック図である。セントラルモジュール１００は、交換インフラストラクチャー(exchange infrastructure)（“ＸＩ”）８１０、コンテンツインテグレータ（“ＣＩ”）８２０、およびマスタデータサーバー（“ＭＤＳ”）８３０を備えることができる。ＸＩ ８１０は、クライアントモジュール１１０とセントラルモジュール１００との間の通信に使用されることができる。

配信されるべきマスタデータはＸＩ ８１０において受信される。配信は、予約ベースの配信、ヒストリック配信(historic distribution)、およびコンテンツベースの配信を含む３つの異なる方法で実施されることができる。ルーティングモデル(routing model)（図示なし）は、どのシステムがマスタデータに興味を持っているかについての情報を格納する。そして、マスタデータは、ＸＩ ８１０から関連システムに送信される。キューイング(queuing)は、ＸＩ ８１０にわたる一貫したメッセージング(messaging)を確保するために使用されることができる。メッセージは、システム間をＸＭＬ(Extensible Markup Language)形式で送信されることができる。

ＣＩ ８２０は、各オブジェクトのための識別属性(identifying attribute)を定義することにより異なるシステムからのマスタデータを関連づけることができる。この識別属性は、クライアントモジュール１１０における異なるシステムからＣＩ ８２０に与えられ、そして、所定のルールに従って類似性(analogousness)についてスキャンされる。ＣＩ ８２０は、どのシステムに属していようとも、またはどのデータモデルに支配されようとも、システムランドスケープにおけるオブジェクトのためのオブジェクトＩＤを保存(save)する。クライアントモジュール１１０に格納されているマスタデータオブジェクトは、マスタデータオブジェクトを格納する各クライアントシステムにおいて定義されている同一性を保持する。ＣＩ ８２０は、各インスタンス化(instantiation)がシステムにおける或る他のオブジェクトに関連することを理解する（マッピング機能を用いて）。従って、ＣＩ ８２０は、結果として生じるＩＤの準備及びマッチング処理を実施する。

一例において、マッピングは、工業特定規格(industry specific standard)を用いて行われることができる。化学薬品(chemicals)、消費者製品（“ＣＰ”）／小売(Retail)などのような異なる工業は、どのようにオブジェクトがその要件のために記述されるべきかの規格を規定する。ある工業では、例えば、ＣＰにおいて、それは、プロダクト名、説明およびクラス（例えば‘スウィート(SWEETS)’）を記述するのに十分であるが、化学薬品(chemicals)ではクラスのみで十分である。従って、属性およびそれらの値は、化学薬品を十分に記述するために使用される。よって、属性は、工業のための言語のようであり得る。故に、ＭＤＭ標準ｘｍｌフォーマットの工業特定規格へのマッピングが支援される。工業特定規格は、例えば、ＣＩＤＥＸ、Ｐｉｄｘ、ＲｏｓｅｔｔａＮｅｔ、Ｐｒｉｃａｔを含む。

ＣＩ ８２０は、オブジェクトを作成するためのダブルチェック処理のためのマッピングを使用する。ＣＩ ８２０は、同一のオブジェクトについての要求をチェックする。もし、マッチ(match)しないことがわかれば、セントラルモジュールは新たなオブジェクトを発生する。そして、ＣＩ ８２０は、新たなオブジェクトについてチェックを実施する。もしマッチしないことがわかれば、セントラルモジュールは新たなマスタデータオブジェクトを格納する。従って、たとえ、最初のチェックがクライアントモジュール１１０によって提供された記述に基づき未完成であっても、マッチ(match)はオブジェクトが完全に作成されたときに見つけられるであろう。

併合ストラテジー(merge strategy)は、類似または同一であることが判明した二つまたはそれ以上のオブジェクトを結合するために使用されることができる。例えば、もしポンプ(pump)のためのマスタデータオブジェクトが、購買システム(purchasing system)、販売システム(sales system)、および製造システム(production system)において作られれば、一つのオブジェクトは、３つのマスタデータオブジェクトを併合(merge)することにより、セントラルモジュール１００において作成されることができる。例えば、新たなオブジェクトが作成されることができ、ここで、異なるシステムは、オブジェクトの異なる部分についての承認(authorization)を有する。従って、購買システムは、マスタデータオブジェクトのための購買情報を維持することができる。購買システムは販売および製造情報を眺める(view)ことはできるが、購買システムは、購買情報を維持するためにのみ承認(authorization)を与えられることができる。

ＭＤＳ ８３０は、データオブジェクトを格納するためのセントラルデータストアを備えることができる。ＭＤＳ ８３０は、オブジェクトの作成および変更の処理を実施することができる。ＭＤＳ ８３０は、また、統合バージョニング(unified versioning)のような変更管理(change management)およびステータス管理(status management)のためのサービスを提供することができる。また、配信のためのパケットに変更されたオブジェクトのグルーピングは、ＭＤＳ ８３０において実施されることができる。

＜配信(distribution)＞
データは、個々のオブジェクトまたはパケットとして配信されることができる。データは、配信目標(distribution target)が割当てられ、またはデータが変更された後に配信されることができる。データ配信の頻度は、オブジェクトが配信のために識別された後に定期的又は即座であることができる。一実施例において、個々のマスタデータオブジェクトは、データのパケットが定期的に配信される一方、即座に配信されることができる。例えば、もし取引先のアドレスがマスタデータオブジェクトにおいて間違っていれば、取引先の正しいアドレスを備えた更新されたマスタデータオブジェクトが即座に利用可能とされることができる。関連する又は相互依存性を有するデータオブジェクトは、オブジェクトが個々に配信された場合に発生するかもしれない矛盾(inconsistency)を防ぐため、パケットとして配信されることができる。例えば、クライアントモジュール１１０は、ビューのためのオブジェクトの全てを予約しないかもしれず、情報の欠損を招く。変化がパケットにおける個々のオブジェクトに対してその都度なされるパケットの即座の配信は現実的でない。従って、パケット配信頻度は定期的であるように設定されることができる。

もし、変化がパケットにおける予約されたオブジェクトに対してなされ、且つその変化が配信のために開放されれば、変化の配信のためのパケットは、予約されたオブジェクトの依存性および相互関係に従って決定されることができる。例えば、変化の配信は、オブジェクトのコンテンツに依存することができる。例えば、もしＢＯＭが新たな材料を含むように変更されれば、マッピングは、新たな材料がＢＯＭと共に送られるべきであることを示すことができる。配信は、また、目標システムがパケットデータをどのように処理するかに依存することができる。もし目標システムは全てのデータを一緒に処理すれば、オブジェクトの全ては、目標システムに送信されることができる。もし目標システムがパケットにおける変化のみを処理すれば、この変化は、一緒にグループ化され、そして配信されることができる。

ＭＤＳ ８３０は、どのオブジェクトが発行され（即ち配信のために利用可能であり）、且つどのシステムがそのオブジェクトを供給されることができるか（即ち目標システムであり得るか）を制御する。クライアントモジュール１１０におけるシステム、またはそれらの各データ管理者(data administrator)は、ＭＤＳ ８３０によって発行されたオブジェクトを予約することができる。

図９は、ｃＭＤＭシステムにおけるデータ配信のための方法の実施例を図解するフロー図である。図１Ａおよび１Ｂを参照すると、セントラルモジュール１００のセントラルシステムは、配信のためのマスタデータオブジェクトを識別する。（ステップ９１０）もし、マスタデータオブジェクトが定期的に配信されるのであれば、配信のためのマスタデータオブジェクトの識別は、マスタデータオブジェクトの作成、マスタデータオブジェクトに対する変化によって、または特定期間(specific time)によって起動(trigger)される。

セントラルシステムは、ルーティング(routing)が、配信されるマスタデータオブジェクトについて存在するかを決定する。（ステップ９２０）もし、マスタデータオブジェクトのためのルーティングが存在しなければ、セントラルシステムは、ステップ９１０に戻って、配信されるマスタオブジェクトを識別する。

マスタデータオブジェクトをルーティングすべき目標システムは、クライアントモジュール１１０から選択されることができる。目標システムがマスタデータオブジェクトルーティングのために決定されることができる３つの方法が存在する。目標システムは、予約ルーティング(subscription routing)、ヒストリックルーティング(historic routing)又はルールベースのルーティング(rule-based routing)に基づいて決定されることができる。予約ルーティングでは、目標システムは、発行されたマスタデータオブジェクト、または、目標システムが予約の承認(authorization)を有するマスタデータオブジェクトを受信することを予約することができる。

配信されるオブジェクトの割当て(assignment)は、図１０に示されるようなユーザーインターフェイス（“ＵＩ”）１０００を介したユーザー入力に応答して実施されることができる。ユーザーは、ＵＩ １０００のセクション１０１０において発行するためのオブジェクトを検索することができる。ユーザーは、例えば、プロダクトカテゴリー(product category)、プロダクトマスタ(product master)または取引先のような、オブジェクトタイプを選択することができる。そしてユーザーはオブジェクトタイプの記述(description)を特定することができる。例えば、もし、ユーザーが“プロダクトカテゴリー”のオブジェクトタイプを選択すれば、ユーザーは、“菓子屋(confectionary)”のような検索すべき記述(description)を特定することができる。そして、ユーザーは、発行するオブジェクトのリストを提示されることができる。各リスティング(listing)は、発行及び予約情報と同様に対応オブジェクトのための詳細なデータを含むことができる。マスタデータオブジェクトは、予約すべきマスタデータオブジェクトを検索するクライアントシステムによってデータオブジェクトを検索することを可能にするために発行されることができる。また、マスタデータオブジェクトは、配信のためのプロファイル(profile)をマスタデータオブジェクトに提供するために発行される。

目標システムは、プロファイルを有するマスタデータオブジェクトに割当てられることができる。図１０を参照すると、プロファイルは、ＵＩ １０００の検索結果セクション１０２０に表示されたオブジェクトに割当てられることができる。ユーザーは、リストにおいて１又は２以上のオブジェクトにプロファイルを割当てることができる。プロファイルは、オブジェクトを目標システムに配信するための基準(criteria)を含むことができる。この基準は、マスタデータオブジェクトのどの部分が配信されるべきかということを含むことができる。例えば、プロファイルは、マスタデータオブジェクトの販売ビューまたはマスタデータオブジェクトの一部であるところの或るプラントのような或る組織からのデータが配信されるべきであることを示すことができる。

また、プロファイルは、マスタデータオブジェクトが配信されるべきであるところのコンテキスト(context)を含むことができる。例えば、もし新たな材料のためのマスタデータオブジェクトが配信されれば、新たな材料を含むＢＯＭも配信されるべきである。プロファイルは、マスタデータオブジェクトからどれだけ離れて、他のオブジェクトがマスタデータオブジェクトと共にパケットで送信されるべきであるということを決定することに関係が拡大することを示すことができる。また、プロファイルは、即座または定期的のように、どれ程の頻度でマスタデータオブジェクトが送信されるかを含むことができる。また、このプロファイルは、どのステータス(status)または有効性(validity)でマスタデータオブジェクトが配信されるべきであるかを含むことができる。例えば、プロファイルは、マスタデータオブジェクトが、“製造準備完了(Ready for Production)”というステータスで配信されるべきであることを示すことができる。

例えば、配信プロファイルは、組織的な面(organizational aspect)に依存するデータまたは販売関連データであるように特定されることができる。ユーザーは、複数のオブジェクトを選択することにより、一度にプロファイルを複数のオブジェクトに割当てることができる。先に発行されたオブジェクトは、割当てられたプロファイルと共にリストに表示されることができる。

もし割当てがヒストリックルーティング(historic routing)に基づいていれば、既に、発行されたオブジェクトのための目標システムであるところの又は発行されたオブジェクトの複製を有するところの全てのクライアントモジュール１１０は、発行されたオブジェクトに対する変化を受信するために、発行オブジェクトのための目標システムであるように割当てられるであろう。

もし、割当てがルールベースのルーティングに基づいていれば、目標システムは、マスタデータオブジェクトのコンテンツに基づいて決定される。例えば、もし、マスタデータオブジェクトが販売ビューを有するオブジェクトであれば、ルールは、マスタデータオブジェクトが顧客関係モジュール(customer relations module)に受け渡されるべきであるということを指示することができる。このルールは、オブジェクトが顧客関係モジュールのような特定のシステムに行くべきであるかどうか、何のコンテンツがそれと共に行くべきであるかを決定することができる。このタイプの割当てが実施されると、クライアントモジュール１１０におけるユーザーは、目標システムでいることを予約しない。

もし、割当てが予約ルーティングに基づいていれば、クライアントモジュール１１０は、このクライアントモジュール１１０から受信された発行されたオブジェクトのための予約に基づき、この発行されたオブジェクトに割当てられる。予約ルーティングのために、配信目標は、クライアントモジュール１１０におけるユーザー選択のために開放されている。

図９を参照すると、割当てられた目標システムを有する発行されたオブジェクトは、この割当てられた（単数又は複数の）目標システムに配信される。（ステップ９３０）

図１１は、ｃＭＤＭシステムにおいて、配信されたマスタデータオブジェクトを受信するための方法の実施例を図解するフロー図である。図１Ａ、１Ｂおよび１１を参照すると、クライアントモジュールのユーザーは、セントラルシステムに格納された発行されたオブジェクトを検索する。（ステップ１１１０）図１２を参照すると、ユーザーは、ＵＩ １２００を介して、発行されたオブジェクトを検索することができる。

ユーザーは、ＵＩ １２００の検索セクション１２１０を通して検索に入ることができる。ユーザーは、ユーザーが検索しているオブジェクトの記述およびオブジェクトタイプを特定することができる。また、ユーザーは、検索結果が、全ての発行されたオブジェクト、全ての発行されたオブジェクト及び予約されたオブジェクト又は全ての発行及び非予約(non-subscribed)のオブジェクトを含むことを望むかどうかを特定することができる。ユーザーは、もしユーザーが非発行(non-published)のマスタデータオブジェクトを予約する承認(authorization)を有すれば、非発行(non-published)のマスタデータオブジェクトを予約することができる。

ユーザーは、ＵＩ １２００のセクション１２２０において、発行されたオブジェクトのリストから１又は２以上の発行されたオブジェクトを予約することができる。（ステップ１１２０）発行されたオブジェクトのリストは、検索に応答してセントラルモジュール１００によってユーザーに提示されることができる。ユーザーは、予約すべき複数のオブジェクトを選択することができる。また、ユーザーは、オブジェクトのためのプロファイルを特定する。例えば、ユーザーは、クライアントシステムが配信を開始する日付を入れることができる。また、ユーザーは、受信者システムのタイプを特定することができる。例えば、ユーザーは、マスタデータオブジェクトが“システムＡＢＣ”のような特定のシステムに行くべきことを特定することができる。他の例では、ユーザーは、目標クライアントシステムが、ヒストリックターゲット(historic target)、ルールベースのターゲット(rule-based target)、または組織的ユニットターゲット(organizational unit target)であることを特定することができる。

そして、クライアントモジュール１１０は、予約(subscription)に応答してセントラルモジュール１００からデータを受信する。（ステップ１１３０）

また、ｃＭＤＭの配信特性(distribution feature)は報告機能を備えることができる。セントラルモジュール１００は、オブジェクト発行情報、オブジェクト予約情報および配信関連情報に関する報告の生成を支援することができる。例えば、セントラルモジュール１００は、どのオブジェクトがまだ発行されていないか、どのオブジェクトが既に発行されたか、及び／又はどのプロファイルがどのオブジェクトのために使用されたかに関する報告の生成を可能にすることができる。また、セントラルモジュール１００は、どのオブジェクトのためにクライアントモジュール１１０が予約されたのか、どのクライアントモジュール１１０がどのオブジェクトのために予約されたのか、及び／又はどのオブジェクトが予約を有していないかに関する報告の生成を可能にすることができる。配信関連報告は、オブジェクトのローカルな複製(local replicate)及び／又は複数のオブジェクト又は単一のオブジェクトの最後の配信に関する報告を含むことができる。セントラルモジュール１００は、マスタデータオブジェクトのためのマッピング情報を用いて報告を生成することができる。

セントラルモジュール１００は、配信処理をモニタする性能に関する報告を生成することができる。例えば、セントラルモジュール１００は、何のエラーが発生したか、どこでエラーが発生したか、及び／又はなぜエラーが発生したかをリストアップした報告を生成する。また、この報告は、レビュー(review)および問題解決のためにエラーの場所(error location)へのリンクを含むことができる。

また、セントラルモジュール１００は、ステージング(staging)に関する報告を生成することができる。例えば、セントラルモジュール１００は、何のオブジェクトが同一であり、またはどのオブジェクトがエラーを有しているかに関する報告を生成することができる。

本発明は、デジタル電子回路において、またはコンピュータハードウェア、ファームウェア、ソフトウェアにおいて、またはそれらの組み合わせにおいて実施されることができる。本発明は、データ処理装置、例えばプログラマブルプロセッサ、コンピュータ、又はマルチプルコンピュータを制御するための、またはこれにより実行するための情報キャリアにおいて、例えばマシン読み取り可能な記憶装置において又は伝搬信号において明白に具現されたコンピュータプログラムとして実施されることができる。コンピュータプログラムは、コンパイル(compile)またはインタープリット(interpret)された言語を含む任意の形式のプログラミング言語で記述されることができ、それは、スタンドアローンプログラム(stand-alone program)、又はモジュール、コンポーネント、サブルーチン、またはコンピューティング環境における使用に適したその他のユニットを含む任意の形式で展開されることができる。コンピュータプログラムは、一つのサイトでの一つ又は複数のコンピュータ上で実行されるように展開されることができ、複数のサイトにわたって配信されることができ、そして通信ネットワークによって相互接続されることができる。

本発明の方法ステップは、入力データに関して動作して出力を生成することにより本発明の機能を実施するためのコンピュータプログラムを実行する１又は２以上のプログラマブルプロセッサにより実施されることができる。また、特殊用途の論理回路、例えばＦＰＧＡ(Field Programmable Gate Array)又はＡＳＩＣ(Application-Specific Integrated Circuit)として本発明の装置が実施されることができると共に、これにより方法ステップが実施されることができる。

コンピュータプログラムの実行に適したプロセッサは、一例として、汎用または特定用途のマイクロプロセッサ、および、任意の種類のデジタルコンピュータの任意の１又は２以上のプロセッサの両方を含む。一般に、プロセッサは、ＲＯＭ(Read-Only Memory)またはＲＡＭ(Random Access Memory)、又はその両方から命令とデータを受け取る。コンピュータの本質的な要素は、命令を実行するためのプロセッサと、命令およびデータを記憶するための１又は２以上のメモリである。また、一般に、コンピュータは、データを格納するための１又は２以上の大容量記憶装置、例えば、磁気、光磁気ディスク、或いは光ディスクを備え、又は、これらにデータを送受信するために動作可能に結合され、又はその両方である。コンピュータプログラム命令およびデータを具現するのに適した情報キャリアは、一例として、半導体メモリ、例えばＥＰＲＯＭ、ＥＥＰＲＯＭおよびフラッシュメモリ装置を含む全ての形式の不揮発性メモリ、内蔵ハードディスクおよびリムーバブルディスクのような磁気ディスク、光磁気ディスク、およびＣＤ−ＲＯＭ及びＤＶＤ−ＲＯＭディスクを含む。プロセッサおよびメモリは、特定用途の論理回路に組み込まれ、またはこれによって補完されることができる。

ユーザーとのやりとり(interaction)を提供するために、本発明は、ユーザーへの情報を表示するためのＣＲＴ(cathode ray tube)またはＬＣＤ(Liquid Crystal Display)モニタのような表示装置と、キーボードおよびユーザーが入力をコンピュータに供給することができるマウスまたはトラックボールのようなポインティングデバイスを備えたコンピュータ上で実施されることができる。同様にユーザーとのやりとりを提供するために、他の種類の装置が使用されることができる。例えば、ユーザーに提供されるフィードバックは、視覚的フィードバック、聴覚的フィードバック、触覚的フィードバックのような任意の形式の知覚的なフィードバックであることができ、且つ、ユーザーからの入力形式は、音響、音声、又は触覚的な入力を含む任意の形式で受信されることができる。

本発明は、例えばデータサーバーのようなバックエンドコンポーネントを備えた、またはミドルウェアコンポーネント、例えばアプリケーションサーバーを備えた、またはフロントエンドコンポーネント、例えばユーザーが本発明の実施例と双方向通信することができるグラフィカルユーザーインターフェイスまたはウェブブラウザを有するクライアントコンピュータ、またはこのようなバックエンド、ミドルウェア、またはフロントエンドコンポーネントの任意の組み合わせを備えたコンピューティングシステムにおいて実施されることができる。システムのコンポーネントは、デジタルデータ通信の媒体、例えば通信ネットワークまたは任意の形式によって双方向接続されることができる。通信ネットワークの例は、ローカルエリアネットワーク（“ＬＡＮ”）、ワイドエリアネットワーク（“ＷＡＮ”）、およびインターネットを含む。

コンピューティングシステムは、クライアントおよびサーバーを含むことができる。クライアントおよびサーバーは、一般に、互いに遠くに離れており、そして通常、通信ネットワークを介して双方向通信する。クライアントとサーバーとの関係は、各コンピュータ上で動作すると共に互いにクライアント−サーバー関係を有するコンピュータプログラムに基づいて発生する。
本発明は、特定の実施例の観点で説明された。他の実施例は、請求項の範囲内である。例えば、本発明のステップは、別の順序で実施されることができ、以前として所望の結果を達成することができる。

協調マスタデータ管理システムを図解するブロック図である。 協調マスタデータ管理システムを図解するブロック図である。 協調マスタデータ管理システムのコンテンツ連結実施例を図解するブロック図である。 データを連結(consolidating)するための方法を図解するフロー図である。 協調マスタデータ管理システムのマスタデータ調和実施を図解するブロック図である。 マスタデータ調和のための方法を図解するフロー図である。 マスタデータ調和のための方法を図解するフロー図である。 共同マスタデータ管理システムのセントラルマスタデータ管理実施例を図解するブロック図である。 セントラルマスタデータ管理のための方法を図解するフロー図である。 協調マスタデータ管理モジュールを図解するブロック図である。 協調マスタデータ管理システムにおけるデータ配信のための方法の実施例を図解するフロー図である。 発行されるべきオブジェクトを割当てるためのユーザインターフェイス（“ＵＩ”）のスクリーン画面を示す図である。 協調マスタデータ管理システムにおいて配信された受信するための方法の実施例を図解するフロー図である。 発行されたオブジェクトを予約するためのＵＩのスクリーン画面を示す図である。

符号の説明

１００ セントラルモジュール
１１０ クライアントモジュール

Claims (45)

1. セントラルデータストアを具備するセントラルモジュール（１００）と１又は２以上のクライアントモジュール（１１０）とを備えて構成されたデータ管理システム（ｃＭＤＭ）においてデータを配信する方法であって、
   前記セントラルモジュール（１００）が、配信のために、前記セントラルデータストアにおける１又は２以上のオブジェクトを識別するステップと、
   前記セントラルモジュール（１００）が、前記１又は２以上のオブジェクトのうちの少なくとも一つのオブジェクトについて、１又は２以上の目標システムを特定するためのルーティングが存在するかを決定するステップと、
   前記セントラルモジュール（１００）が、前記少なくとも一つのオブジェクトについての配信プロファイルに基づき、前記ルーティングによって特定される１又は２以上の目標システムに前記少なくとも一つのオブジェクトを配信するステップとを備え、
   前記１又は２以上のオブジェクトは、前記データ管理システム（ｃＭＤＭ）における全てのクライアントモジュール（１１０）が共有するためのマスタデータオブジェクトであり、
   前記１又は２以上の目標システムは前記データ管理システム（ｃＭＤＭ）の一部であり、
   前記配信プロファイルは、前記オブジェクトを目標システムに配信するための基準を含み、該基準は、前記マスタデータオブジェクトのどの部分を配信すべきかに関する情報と、前記マスタデータオブジェクトが配信されるべきコンテキストを含み、
   前記ルーティングは、ヒストリックルーティングと、ルールベースのルーティングと、予約ルーティングとのうちの１又は２以上を含み、ここで、前記ヒストリックルーティングでは、発行されたオブジェクトについて既に目標システムである全てのクライアントモジュール（１１０）または前記発行されたオブジェクトの複製を有する全てのクライアントモジュール（１１０）が、前記発行されたオブジェクトに対する変更を受信するために、前記発行されたオブジェクトについて目標システムであるように割り当てられ、前記ルールベースのルーティングでは、目標システムが、前記マスタデータオブジェクトのコンテンツに基づいて決定され、前記予約ルーティングでは、クライアントモジュール（１１０）が、該クライアントモジュール（１１０）から受信された発行されたオブジェクトについての予約に基づき、該発行されたオブジェクトに割り当てられる方法。
2. 前記少なくとも一つのオブジェクトを配信するステップは、該少なくとも一つのオブジェクトを識別後に即座に配信するステップを含む請求項１記載の方法。
3. 前記少なくとも一つのオブジェクトを配信するステップは、該少なくとも一つのオブジェクトを定期的に配信するステップを含む請求項１記載の方法。
4. 前記少なくとも一つのオブジェクトを配信するステップは、前記１又は２以上のオブジェクトをパケットで配信するステップを含む請求項１ないし３の何れか１項記載の方法。
5. 前記少なくとも一つのオブジェクトのパケットを配信するステップは、該少なくとも一つのオブジェクトのパケットを識別後に即座に配信するステップを含む請求項４記載の方法。
6. 前記少なくとも一つのオブジェクトのパケットを配信するステップは、該少なくとも一つのオブジェクトのパケットを定期的に配信するステップを含む請求項４記載の方法。
7. 前記オブジェクトのどの部分が配信されることができるかを決定するステップを更に備えた請求項１記載の方法。
8. 前記１又は２以上の目標システムによってどのオブジェクトが要求されたかを示す前記１又は２以上の目標システムからの情報を受信するステップを更に備え、少なくとも一つのオブジェクトを供給すべき１又は２以上の目標システムを決定するステップは、前記１又は２以上の目標システムから受信された予約情報であってオブジェクトの配信に関する予約情報に基づき少なくとも一つのオブジェクトを供給すべき１又は２以上の目標システムを決定するステップを含む請求項１記載の方法。
9. 前記少なくとも一つのオブジェクトを前記１又は２以上の目標システムに配信する頻度を示す前記１又は２以上の目標システムからの頻度情報を受信するステップを更に備え、前記少なくとも一つのオブジェクトを配信するステップは、前記受信された頻度情報によって示される頻度で前記少なくとも一つのオブジェクトを配信するステップを含む請求項１記載の方法。
10. 前記少なくとも一つのオブジェクトを前記１又は２以上の目標システムにどの日付から配信するかを示す前記１又は２以上の目標システムからの配信日付情報を受信するステップを更に備え、前記少なくとも一つのオブジェクトを配信するステップは、前記受信された配信日付情報によって示される日付から前記少なくとも一つのオブジェクトを配信するステップを含む請求項１記載の方法。
11. 少なくとも一つのオブジェクトを供給すべき１又は２以上の目標システムを特定するユーザー入力を受信するステップを更に備え、少なくとも一つのオブジェクトを供給すべき前記１又は２以上の目標システムを決定するステップは、前記ユーザー入力に応答して前記１又は２以上の目標システムを決定するステップを含む請求項１記載の方法。
12. 前記少なくとも一つのオブジェクトのための配信プロファイルに、前記少なくとも一つのオブジェクトを供給すべき前記１又は２以上の目標システムの識別を格納するステップを更に備え、前記少なくとも一つのオブジェクトを配信するステップは、前記少なくとも一つのオブジェクトのための前記配信プロファイルに基づき前記少なくとも一つのオブジェクトを配信するステップを含む請求項１記載の方法。
13. 前記少なくとも一つのオブジェクトのための配信リストに前記１又は２以上の目標システムから受信された情報を格納するステップを更に備え、前記情報は、オブジェクトの配信に関する予約情報、配信開始情報、頻度情報および受信者タイプ情報のうちの１又は２以上を含む請求項１２記載の方法。
14. １又は２以上の前記識別されたオブジェクトを発行するステップを更に備え、前記１又は２以上の発行されたオブジェクトは、クライアントシステムによる、オブジェクトの配信に関する予約のために利用可能である請求項１記載の方法。
15. 前記１又は２以上の目標システムへのオブジェクトの処理に関する報告を生成するステップを更に備えた請求項１記載の方法。
16. 前記報告を生成するステップは、発行されたオブジェクト、オブジェクトの配信およびオブジェクトの配信に関する予約のうちの少なくとも一つに関する情報を含む報告を生成するステップを含む請求項１５記載の方法。
17. オブジェクトの配信に関する報告を生成するステップは、オブジェクトの最後の配信およびオブジェクトのローカルな複製のうちの一つに関する情報を含む報告を生成するステップを含む請求項１６記載の方法。
18. 前記報告を生成するステップは、処理モニタリング報告を生成するステップを含む請求項１５記載の方法。
19. 前記報告を生成するステップは、ステージング報告を生成するステップを含む請求項１５記載の方法。
20. 請求項１の方法により配信される動的アクセスデータを受信するための方法であって、
    クライアントシステムから、セントラルシステムに格納されたオブジェクトを検索するステップと、
    前記検索された利用可能なオブジェクトのリストから１又は２以上のオブジェクトの配信を予約するステップと、
    前記セントラルシステムから前記予約に係るオブジェクトのデータを受信するステップとを含み、
    前記オブジェクトは、発行されたオブジェクトと、前記クライアントシステムが予約することを承認されたオブジェクトとを含む方法。
21. 前記セントラルシステムからデータを受信するための配信頻度を定義するステップを更に備えた請求項２０記載の方法。
22. 配信開始日付を定義するステップを更に備えた請求項２０記載の方法。
23. １又は２以上のオブジェクトを予約するステップは、利用可能なオブジェクトの前記リストから配信プロファイルを選択するステップを含む請求項２０記載の方法。
24. データを共有するためのシステムであって、
    １又は２以上のクライアントシステム（１１０）と、
    エンティティのためにデータオブジェクトを格納するセントラルデータストアを備えたセントラルモジュール（１００）であって前記エンティティをなすセントラルモジュール（１００）とを備え、
    前記データオブジェクトは、前記１又は２以上のクライアントシステム（１１０）が共有するためのものであり、前記セントラルモジュール（１００）は、前記１又は２以上のクライアントシステム（１１０）に配信するためにデータオブジェクトを選択すると共に、前記少なくとも一つのオブジェクトについての配信プロファイルに基づき、予約ルーティング、ヒストリックルーティング、およびルールベースのルーティングのうちの１又は２以上によって特定される前記１又は２以上のクライアントモジュール（１１０）にデータオブジェクトを配信するように構成され、
    前記配信プロファイルは、前記オブジェクトを目標システムに配信するための基準を含み、該基準は、前記マスタデータオブジェクトのどの部分を配信すべきかに関する情報と、前記マスタデータオブジェクトが配信されるべきコンテキストを含み、
    前記ヒストリックルーティングでは、発行されたオブジェクトについて既に目標システムである全てのクライアントモジュール（１１０）または前記発行されたオブジェクトの複製を有する全てのクライアントモジュール（１１０）が、前記発行されたオブジェクトに対する変更を受信するために、前記発行されたオブジェクトについて目標システムであるように割り当てられ、前記ルールベースのルーティングでは、目標システムが、前記マスタデータオブジェクトのコンテンツに基づいて決定され、前記予約ルーティングでは、クライアントモジュール（１１０）が、該クライアントモジュール（１１０）から受信された発行されたオブジェクトについての予約に基づき、該発行されたオブジェクトに割り当てられるシステム。
25. 前記セントラルモジュールは、前記１又は２以上のクライアントシステムへのデータオブジェクトの配信に関する報告を生成するように更に構成された請求項２４記載のシステム。
26. 前記報告は、発行関連報告、予約関連報告、配信関連報告、処理モニタリング報告、およびステージング報告のうちの１又は２以上を含む請求項２５記載のシステム。
27. セントラルデータストアを具備するセントラルモジュール（１００）と１又は２以上のクライアントモジュール（１１０）とを備えて構成されたデータ管理システム（ｃＭＤＭ）においてデータを配信するための、コンピュータ読み取り可能な記録媒体に明白に格納されたコンピュータプログラムであって、プログラマブルプロセッサに、
    前記セントラルモジュール（１００）において、配信のために、前記セントラルデータストアにおける１又は２以上のオブジェクトを識別させ、
    前記セントラルモジュール（１００）において、前記１又は２以上のオブジェクトのうちの少なくとも一つのオブジェクトについて、１又は２以上の目標システムを特定するためのルーティングが存在するかを決定させ、
    前記セントラルモジュール（１００）において、前記少なくとも一つのオブジェクトについての配信プロファイルに基づき、前記少なくとも一つのオブジェクトを前記ルーティングによって特定される１又は２以上の目標システムに配信させる
    ことができる命令を備え、
    前記１又は２以上のオブジェクトは、前記データ管理システム（ｃＭＤＭ）における全てのクライアントモジュール（１１０）が共有するためのマスタデータオブジェクトであり、
    前記１又は２以上の目標システムは前記データ管理システム（ｃＭＤＭ）の一部であり、
    前記配信プロファイルは、前記オブジェクトを目標システムに配信するための基準を含み、該基準は、前記マスタデータオブジェクトのどの部分を配信すべきかに関する情報と、前記マスタデータオブジェクトが配信されるべきコンテキストを含み、
    前記ルーティングは、ヒストリックルーティングと、ルールベースのルーティングと、予約ルーティングとのうちの１又は２以上を含み、ここで、前記ヒストリックルーティングでは、発行されたオブジェクトについて既に目標システムである全てのクライアントモジュール（１１０）または前記発行されたオブジェクトの複製を有する全てのクライアントモジュール（１１０）が、前記発行されたオブジェクトに対する変更を受信するために、前記発行されたオブジェクトについて目標システムであるように割り当てられ、前記ルールベースのルーティングでは、目標システムが、前記マスタデータオブジェクトのコンテンツに基づいて決定され、前記予約ルーティングでは、クライアントモジュール（１１０）が、該クライアントモジュール（１１０）から受信された発行されたオブジェクトについての予約に基づき、該発行されたオブジェクトに割り当てられるコンピュータプログラム。
28. プログラマブルプロセッサに前記少なくとも一つのオブジェクトを配信させることができる前記命令は、プログラマブルプロセッサに前記少なくとも一つのオブジェクトを識別後に即座に配信させることができる命令を含む請求項２７記載のコンピュータプログラム。
29. プログラマブルプロセッサに前記少なくとも一つのオブジェクトを配信させることができる前記命令は、プログラマブルプロセッサに前記少なくとも一つのオブジェクトを定期的に配信させることができる命令を含む請求項２７記載のコンピュータプログラム。
30. プログラマブルプロセッサに前記１又は２以上のオブジェクトを配信させることができる命令は、プログラマブルプロセッサに前記１又は２以上のオブジェクトをパケットとして配信させることができる命令を含む請求項２７記載のコンピュータプログラム。
31. プログラマブルプロセッサに前記少なくとも一つのオブジェクトのパケットを配信させることができる前記命令は、プログラマブルプロセッサに前記少なくとも一つのオブジェクトのパケットを識別後に即座に配信させることができる命令を含む請求項３０記載のコンピュータプログラム。
32. プログラマブルプロセッサに前記少なくとも一つのオブジェクトのパケットを配信させることができる前記命令は、プログラマブルプロセッサに前記少なくとも一つのオブジェクトのパケットを定期的に配信させることができる命令を含む請求項３０記載のコンピュータプログラム。
33. プログラマブルプロセッサに、前記オブジェクトのどの部分が配信されることができるかを決定させることができる命令を更に含む請求項２７記載のコンピュータプログラム。
34. プログラマブルプロセッサに、
    前記１又は２以上の目標システムによってどのオブジェクトが要求されるかを示す前記１又は２以上の目標システムからの情報を受信させることができる命令を更に含み、少なくとも一つのオブジェクトを供給すべき１又は２以上の目標システムを決定するステップは、前記１又は２以上の目標システムから受信された予約情報であってオブジェクトの配信に関する予約情報に基づき、少なくとも一つのオブジェクトを供給すべき１又は２以上の目標システムを決定するステップを含む請求項２７記載のコンピュータプログラム。
35. プログラマブルプロセッサに、前記少なくとも一つのオブジェクトを前記１又は２以上の目標システムに配信する頻度を示す前記１又は２以上の目標システムからの頻度情報を受信させることができる命令を更に含み、前記少なくとも一つのオブジェクトを配信するステップは、前記受信された頻度情報によって示される頻度で前記少なくとも一つのオブジェクトを配信するステップを含む請求項２７記載のコンピュータプログラム。
36. プログラマブルプロセッサに、どの日付から前記少なくとも一つのオブジェクトを前記１又は２以上の目標システムに配信するかを示す前記１又は２以上の目標システムからの配信日付情報を受信させることができる命令を更に含み、前記少なくとも一つのオブジェクトを配信するステップは、前記受信された配信日付情報によって示される日付から前記少なくとも一つのオブジェクトを配信するステップを含む請求項２７記載のコンピュータプログラム。
37. プログラマブルプロセッサに、少なくとも一つのオブジェクトを供給すべき１又は２以上の目標システムを特定するユーザー入力を受信させることができる命令を更に含み、少なくとも一つのオブジェクトを供給すべき前記１又は２以上の目標システムを決定するステップは、前記ユーザー入力に応答して前記１又は２以上の目標システムを決定するステップを含む請求項２７記載のコンピュータプログラム。
38. プログラマブルプロセッサに、前記少なくとも一つのオブジェクトのための配信プロファイルに、前記少なくとも一つのオブジェクトを供給すべき前記１又は２以上の目標システムの識別を格納させることができる命令を更に含み、前記少なくとも一つのオブジェクトを配信するステップは、前記少なくとも一つのオブジェクトのための前記配信プロファイルに基づき前記少なくとも一つのオブジェクトを配信するステップを含む請求項２７記載のコンピュータプログラム。
39. プログラマブルプロセッサに、前記少なくとも一つのオブジェクトのための配信リストに、前記１又は２以上の目標システムから受信された情報を格納させることができる命令を更に含み、前記情報は、オブジェクトの配信に関する予約情報、配信開始情報、頻度情報および受信者タイプ情報のうちの１又は２以上を含む請求項３８記載のコンピュータプログラム。
40. プログラマブルプロセッサに、１又は２以上の前記識別されたオブジェクトを発行させることができる命令を更に含み、前記１又は２以上の発行されたオブジェクトは、クライアントシステムにより、オブジェクトの配信に関する予約のために利用可能である請求項２７記載のコンピュータプログラム。
41. プログラマブルプロセッサに、前記１又は２以上の目標システムへのオブジェクトの処理に関する報告を生成させることができる命令を更に含む請求項２７記載のコンピュータプログラム。
42. プログラマブルプロセッサに前記報告を生成させることができる前記命令は、プログラマブルプロセッサに、発行されたオブジェクト、オブジェクトの配信に関する予約および配信のうちの少なくとも一つに関する情報を含む報告を生成させることができる命令を含む請求項４１記載のコンピュータプログラム。
43. プログラマブルプロセッサにオブジェクトの配信に関する報告を生成させることができる前記命令は、プログラマブルプロセッサに、オブジェクトの最後の配信と、オブジェクトのローカルな複製とのうちの一つに関する情報を含む報告を生成させることができる命令を含む請求項４２記載のコンピュータプログラム。
44. プログラマブルプロセッサに前記報告を生成させることができる前記命令は、プログラマブルプロセッサに処理モニタリング報告を生成させることができる命令を含む請求項４１記載のコンピュータプログラム。
45. プログラマブルプロセッサに前記報告を生成させることができる命令は、プログラマブルプロセッサにステージング報告を生成させることができる命令を含む請求項４１記載のコンピュータプログラム。

Images