(57)【要約】【課題】サービス管理モデルを介して法的拘束力を持つ業務契約を実現する。【解決手段】相対する当事者間のビジネス相互作用を管理する方法および装置。ビジネス相互作用はサービス契約にマップされる。サービス契約は機械可読コードにマップされる。機械可読コードは、商取引パターンおよびサービス相互作用パターンによって定義される。機械可読コードはＩＴシステムによって消費される。ビジネス相互作用によって必要とされる義務を履行することに関連付けられる管理タスクが生成される。【選択図】図１
2006146892.tif 000002
【特許請求の範囲】
【請求項１】
相対する当事者間のビジネス相互作用を管理する方法であって、
前記ビジネス相互作用を１つまたは複数のサービス契約にマップする動作と、
前記１つまたは複数のサービス契約を、１つまたは複数の商取引パターンおよび１つまたは複数のサービス相互作用パターンによって定義される機械可読コードにマップする動作と、
前記機械可読コードをＩＴシステムで消費する動作と、
前記ビジネス相互作用によって必要とされる義務を履行することに関連付けられる管理タスクを生成する動作と
を含むことを特徴とする方法。
【請求項２】
管理タスクの実行を監視する動作をさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記商取引パターンは、提案および受諾パターン、照会／応答パターン、要求／応答パターン、要求／確認パターン、情報配布パターンおよび通知パターンの少なくとも１つを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記商取引パターンは、管理タスクの有限集合を含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記１つまたは複数のサービス契約を機械可読コードにマップする動作は、前記１つまたは複数のサービス契約をＷｅｂサービスで使用するためのＸＭＬコードブロックにマップする動作を含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記ビジネス相互作用を１つまたは複数のサービス契約にマップする動作は、前記ビジネス相互作用を定型文書にマップする動作を含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記ビジネス相互作用を１つまたは複数のサービス契約にマップする動作は、契約の諸条件、ならびに規制および慣習法上の要件の少なくとも１つを前記１つまたは複数のサービス契約にマップする動作を含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記ビジネス相互作用を１つまたは複数のサービス契約にマップする動作は、標準化された法的要件および最善の商習慣の少なくとも１つを前記１つまたは複数のサービス契約にマップする動作を含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記標準化された法的要件および／または最善の商習慣は、ＵＮＥＣＥ  ＵＮ／ＣＥＦＡＣＴモデル化法（ＵＭＭ）およびＩＳＯ／ＩＥＣ  ＪＴＣ１  ＳＣ３２  ＷＧ１業務契約の意味的記述法ＩＳＯ／ＩＥＣ  ＦＣＤ１５９４４−３の少なくとも１つに成文化されていることを特徴とする請求項８に記載の方法。
【請求項１０】
前記機械可読コードをＩＴシステムで消費する動作は、前記コードを使ってＩＴサービスライフサイクルの１つまたは複数の段階を実施する動作を含むことを特徴とする請求項１に記載の方法。
【請求項１１】
前記ＩＴサービスライフサイクルの前記段階は、設計段階、開発段階、検査段階、配置段階、運用段階、および変更管理段階を含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記１つまたは複数のサービス契約を機械可読コードにマップする動作は、サービス定義およびサービス管理モデルの少なくとも１つにマップする動作を含むことを特徴とする請求項１に記載の方法。
【請求項１３】
前記ビジネス相互作用を１つまたは複数のサービス契約にマップする動作は、サービス定義およびサービス義務を生成する動作を含むことを特徴とする請求項１に記載の方法。
【請求項１４】
前記サービス定義はサービス実装形態を定義し、前記サービス実装形態は、サービスポリシー、サービス設定およびサービス計測の少なくとも１つを定義することを特徴とする請求項１３に記載の方法。
【請求項１５】
前記サービス計測は、実行されるタスクを定義するイベント、デバッグおよび診断のためのデータを提供するトレース、プローブ、およびシステム健全性を定義する性能カウンタの少なくとも１つを定義することを特徴とする請求項１４に記載の方法。
【請求項１６】
前記サービス義務は、前記サービス実装形態によって消費されるサービス運用規則およびサービス履行規則の少なくとも１つを定義することを特徴とする請求項１３に記載の方法。
【請求項１７】
前記サービス運用規則およびサービス履行規則の少なくとも１つは、パラメータ、前記サービス契約で指定される前記諸条件を反映する条件、および処置の少なくとも１つを含むことを特徴とする請求項１６に記載の方法。
【請求項１８】
前記動作は、サービス計測からのデータに基づいて管理タスクをトリガする警報および電子メールの少なくとも１つを含むことを特徴とする請求項１７に記載の方法。
【請求項１９】
ビジネス相互作用を１つまたは複数のサービス契約にマップする動作と、
前記１つまたは複数のサービス契約を、１つまたは複数の商取引パターンおよび１つまたは複数のサービス相互作用パターンによって定義される機械可読コードにマップする動作と、
前記機械可読コードをＩＴシステムで消費する動作と、
前記ビジネス相互作用によって必要とされる義務を履行することに関連付けられる管理タスクを生成する動作と
を実行するコンピュータ実行可能命令を持つことを特徴とするコンピュータ可読媒体。
【請求項２０】
ＩＴシステムが消費可能なサービス契約のモデルを形成する複数のデータフィールドを含むコンピュータ可読媒体であって、
サービスポリシーと、
サービス設定と、
実行されるタスクを定義するイベント、
デバッグおよび診断のためのデータを提供するトレース、
プローブ、および
システム健全性イベントを定義する性能カウンタ
を含むサービス計測と
を含むサービス実装形態と、
パラメータ、
前記サービス契約で指定される諸条件を反映する条件、および
サービス計測からのデータに基づいて管理タスクをトリガする警報および電子メールの少なくとも１つを含む動作
を含むサービス運用規則およびサービス履行規則を含むサービス義務と
を含むことを特徴とするコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、商取引および業務管理タスクをモデル化することに関する。より詳細には、本発明は、業務管理タスクを円滑化するためにＩＴシステムによって使用され得る、商取引を記述する機械可読コードを作成することに関する。
【背景技術】
【０００２】
現代のビジネスは、２つの非常に重要な側面、すなわち業務管理とＩＴを含む。業務管理には、企業をうまく運営するために実行される日々の活動が含まれる。例えば、業務管理には、宣伝、販売、交渉および契約締結、契約上の義務の履行、他の当事者が企業に負っている義務の管理などが含まれ得る。ビジネス相互作用には、一度引き受けると、残存義務(residual obligation)を生じるものがある。例えば、拘束力を持つ契約を結ぶと、その結果として、契約を結ぶ当事者によって実行されなければならない残存義務を生じる。これらの義務は、契約で明示的に定義されることもあり、法の定めにより存在することもある。業務管理においては、義務が確実に履行されるようにする必要がある。義務が確実に履行されるようにするには、タスクを追跡すること、実行指標を生成することなどの管理タスクを実行する必要がある。
【０００３】
ＩＴは、これまで、業務機能を行う企業にとって有用なツールであった。例えば、ＩＴを使って、契約を起草し、相手側当事者に契約を送付し、相手側当事者と交渉し、義務を確認し、在庫を管理し、マーケティング作業を実行することができる。また、ＩＴを使ってタスクを追跡し、実行指標を生成することもできる。
【０００４】
業務管理とＩＴは、通常、（特定の目的のために）随時連結される。具体的には、通常、特定の企業のニーズが評価され、それら特定のニーズを満たすためにＩＴが設計され、実施される。ゆえに、企業が新しい財源を拡大し、または生み出そうとするときには、しばしば、新しい機能を遂行するためにさらなるＩＴが開発され、実施されなければならない。これは、新しい財源を拡大し、または生み出すことによって実現される任意の競争上の優位性の少なくとも一部を帳消しにするほど、高くつき、時間を要することもある。
【０００５】
【非特許文献１】UNECE UN/CEFACT Modeling Methodology (UMM) Revision 10
【非特許文献２】ISO/IEC JTC1 SC32 WG1 Business Agreement Semantic Descriptive Techniques ISO/IEC FCD 15944-3
【発明の開示】
【発明が解決しようとする課題】
【０００６】
したがって、ビジネス相互作用に関連するデータの入力に基づいて管理タスクを生成し、実行し得るＩＴシステムを実施すれば役に立つはずである。
【課題を解決するための手段】
【０００７】
一実施形態は、相対する当事者間のビジネス相互作用を管理する方法を含む。この方法は、ビジネス相互作用を１つまたは複数のサービス契約にマップすることを含む。この方法は、さらに、１つまたは複数のサービス契約を機械可読コードにマップすることを含む。機械可読コードは、１つまたは複数の商取引パターンおよび１つまたは複数のサービス相互作用パターンによって定義される。機械可読コードはＩＴシステムで消費される。この方法は、さらに、ビジネス相互作用によって必要とされる義務を履行することに関連付けられる管理タスクを生成することを含む。
【０００８】
別の実施形態は、コンピュータ実行可能命令を持つコンピュータ可読媒体を含む。コンピュータ実行可能命令は、様々な動作の実行を円滑化するように設計される。動作には、ビジネス相互作用を１つまたは複数のサービス契約にマップすることが含まれる。動作には、さらに、１つまたは複数のサービス契約を、１つまたは複数の商取引パターンおよび１つまたは複数のサービス相互作用パターンによって定義される機械可読コードにマップすることが含まれる。機械可読コードはＩＴシステムで消費される。コンピュータ実行可能命令によって円滑化される動作には、ビジネス相互作用によって必要とされる義務を履行することに関連付けられる管理タスクを生成することが含まれる。
【０００９】
別の実施形態は、いくつかのデータフィールドを含むコンピュータ可読媒体を含む。これらのデータフィールドは、ＩＴシステムが消費可能なサービス契約のモデルを形成する。コンピュータ可読媒体はサービス実装形態を含む。サービス実装形態は、サービスポリシー、サービス設定、およびサービス計測(service instrumentation)を含む。サービス計測には、実行されるタスクを定義するイベント、デバッグおよび診断のためのデータを提供するトレース、プローブ、システム健全性イベントを定義する性能カウンタが含まれる。コンピュータ可読媒体は、さらに、サービス義務(service commitment)を含む。サービス義務は、サービス運用規則およびサービス履行規則を持つ。サービス運用規則およびサービス履行規則には、パラメータ、サービス契約で指定される諸条件を反映する条件、および処置が含まれる。処置には、サービス計測からのデータに基づいて管理タスクをトリガする警報および電子メールの少なくとも１つが含まれる。
【００１０】
前述の実施形態は、変化するビジネス相互作用で使用するためにＩＴシステムを迅速に適合させることを可能にする。これは、企業体が、業務タスクを実行し、または新しい商機の領域を調査するときにリソースを効率よく利用することを可能にする。
【００１１】
本発明の上記その他の利点および特徴は、以下の説明および添付の特許請求の範囲を読めばより詳細に明らかになり、あるいは以下で説明する本発明の実施によって知ることができる。
【００１２】
本発明の上記その他の利点および特徴が獲得される方法を提供するために、添付の図面に示す本発明の具体的実施形態を参照して、簡単に前述した本発明のより詳細な説明を行う。これらの図面は本発明の典型的な実施形態を示すものにすぎず、したがって、本発明の範囲を限定するものとみなすべきでないことを理解した上で、次に、本発明を、添付の図面を使ってより具体的かつ詳細に記述し、説明する。
【発明を実施するための最良の形態】
【００１３】
一実施形態では、当事者間の業務契約などの相互作用が、商取引パターンおよびサービス相互作用パターンを使って、サービス指向のモデルを実施するための１つまたは複数のサービス契約を形成するようにマップされる。サービス指向のモデルは、分散システムを構築することを可能にする。サービス契約は、契約上の義務を履行し、または様々な取引によって必要とされる他の義務を満たすために実行される管理タスクを記述する情報を含む。現在、業務契約および取引は、１つまたは複数の商取引パターンを使って記述され得る。この実施形態は、業務契約および取引をモデル化するのに使用される有限数の商取引パターンを利用する。また、この実施形態は、サービス契約で指定される義務を履行するために様々な組み合わせで使用される有限数の管理活動も使用する。
【００１４】
ゆえに、サービス契約は、商取引パターンおよびサービス相互作用パターンを使ってモデル化され得る。商取引パターンは、機械可読コードブロックのパラメータとして使用される有限数の管理タスクを持つ機械可読コードブロックの観点から記述され得る。例をあげると、それだけに限らないが、Ｗｅｂサービス記述言語（ＷＳＤＬ）で使用されるようなＸＭＬコードブロックを使ってサービス契約の諸条件が記述され得る。
【００１５】
相対する当事者間のビジネスプロセスおよび取引は、１つまたは複数の特定の二者間取引パターンを使ってモデル化され得る。現在、広く認識されている６つの二者間取引パターンがある。これらのパターンには、（１）提案および受諾パターン、（２）照会／応答パターン、（３）要求／応答パターン、（４）要求／確認パターン、（５）情報配布パターン、および（６）通知パターンが含まれる。
【００１６】
提案および受諾パターンは、各当事者が履行すべき残存義務を生じる。提案および受諾取引が完了した後、各当事者は、履行すべき義務（残存義務）を持つ。例えば、第１の当事者が特定の価格である商品を販売しようと申し出る。第２の当事者がこの提案を受け入れる。様々な法的要件が、その提案および受諾に関して十分に満たされる限り、第１の当事者は、今や、商品を納入する義務を負い、第２の当事者は指定された価格を支払う義務を負う。具体的には、提案および受諾パターンは、一度業務活動メッセージが妥当性検査を通ると、その業務活動メッセージの承認を必要とする。この承認は、実体的で、受諾の条件を含むものとすることもでき、非実体的で、一般の監査可能な取引信号(business signal)を含むものとすることもできる。
【００１７】
照会／応答パターンは、一方の当事者から情報を持つ相手側当事者への情報を求める照会をモデル化するのに使用される。照会／応答取引が発生した後には、どちらの当事者にも残存義務が生じない。一例としては、第１の当事者が、第２の当事者により販売される製品を説明する情報を求める照会を提出することが含まれ得る。第２の当事者は、その照会に応答して、製品説明を含むカタログを送付することができる。このパターンは、監査可能な取引信号も、受信確認も、取引受諾確認も容認しない。
【００１８】
要求／応答パターンは、相手側当事者が持つ情報を求める正式な要求をモデル化するのに使用される。このパターンは、当事者の一方に残存義務を生じる。例えば、第１の当事者が第２の当事者に商品またはサービスの見積もりを要求するとする。次いで、第２の当事者は見積もりを提供し、その結果として販売の提案が生じる。第２の当事者は、今や、その提案を妥当な期間有効にしておく残存義務、販売の提案を撤回する残存義務、あるいは他のそのような義務を持つ。
【００１９】
要求／確認パターンは、以前に締結された契約から、あるいは相手側当事者の業務規則に対して存在する何らかの義務の確認または状況を求める要求をモデル化するのに使用される。例えば、一方の当事者が、相手側当事者が義務を否認しておらず、または義務を履行し得ることを保証するために、納品の最新状況を要求することがある。
【００２０】
情報配布パターンは、非公式の情報交換をモデル化するのに使用される。この非公式の交換は、結果として否認防止要件を生じない。多くのマーケティング活動が情報配布の例である。
【００２１】
通知パターンは、正式な情報交換をモデル化するのに使用される。正式な交換は、結果として否認防止要求を生じる。通知パターンの一例には、小包郵便の移動を追跡することが含まれる。
【００２２】
前述の６つの商取引パターンのそれぞれは、特定のサービス管理タスクによってさらにモデル化され得る。管理タスクのそれぞれは、その取引を完了するために行うべき処置を記述する。一実施形態では、管理タスクの有限集合を利用する。ゆえに、商取引パターンの有限集合、および管理タスクの有限集合を使って、事実上、どんなビジネス相互作用もモデル化され得る。このモデルは、ＩＴシステムによって使用可能な機械可読コードとして直列化され得る。
【００２３】
例をあげると、通知パターンには、情報を収集すること、情報の正確さを検証すること、情報の正確さを立証すること、および情報を送信することというタスクが含まれる。情報を収集することは、特定の小包郵便パッケージの場所を判定するために情報を収集すること含み得る。例えば、ユーザは、バーコード走査を使って場所情報が入力されるデータベースをサーチすることができる。情報を検証することは、収集された情報が正確であることを確認するステップを含み得る。例えば、担当者は、物理的に、パッケージを検査することができる。情報の正確さを立証することには、その情報が正確であると表明することが伴う。例えば、担当者は、そのパッケージの場所を表明する手紙または電子メールを送ることができる。情報を送信することは、その情報を相手側当事者に送ることを含む。例えば、その手紙または電子メールが相手側当事者に送られる。その他の商取引パターンのそれぞれが、他の様々なサーバコンピュータ管理タスクを含む。
【００２４】
前述の説明は、１つの非常に限定された例を使って構成されているが、他の動作も、情報を収集すること、情報の正確さを検証すること、情報の正確さを立証すること、および情報を送信することを履行し得ることを当分野の技術者は理解するであろう。他の商取引パターンは、実行すべき他の管理タスクを含む。
【００２５】
次に図１を参照すると、サービス消費者１０２とサービス提供者１０４の間のビジネス相互作用が業務サービスモデル１００の一部として示されている。サービス指向のモデルにおいて、サービス提供者は、いくつかの異なるサービスまたは組織のいずれか１つを含み得る。例えば、それだけに限らないが、サービス提供者は、メインフレームアプリケーション、プリンタ、社内従業員など、内部のものとすることができる。サービス提供者は、船会社、ドック職員、商品納入業者など、外部のものとすることもできる。サービス提供者は、インターフェースを介してその諸機能を公開する。前述のように、サービス消費者１０２とサービス提供者１０４の間の相互作用は、１つまたは複数の商取引パターンおよび１つまたは複数のサービス相互作用パターンを使ってモデル化され得る。１つまたは複数の商取引パターンおよび１つまたは複数のサービス相互作用パターンをパターン１０６として図１に示す。パターン１０６を使って、ビジネス相互作用が１つまたは複数のサービス契約１０８に変換される。サービス契約１０８中の情報は、一例では、定型文書(form document)として編成され得る。
【００２６】
注目すべきことに、本明細書で示すサービス契約１０８は、必ずしも、実際の業務契約の諸条件に直接変換されるとは限らない。実際の業務契約を使ってサービス契約１０８を形成することもできるが、特定の規制要件や慣習法上の要件など他の情報も、実際の業務契約には明示されないが、サービス契約には明示的に表明され得る。これらの要件は、図１に示すパターン入力１０６によって提供され得る。一実施形態では、パターン入力１０６には、成文化されている、標準化された法的要件または最善の商習慣（例えば、非特許文献１、非特許文献２参照）が含まれる。さらに、米国弁護士協会、国際商工会議所、国連などの諸組織も、商取引を規定する国際規則を承認している。これらの規則はパターン入力１０６に含まれ得る。パターン入力１０６は、例えば、電子文書交換に伴う経験または他のビジネス相互作用経験によって実現される規則なども含み得る。
【００２７】
必ずしも業務契約に基づくとは限らない他のビジネス相互作用もサービス契約１０８の形成に使用され得る。例えば、サービス契約１０８を使って、見積もりの要求、カタログの要求、出荷および納入の確認などが記述され得る。要約すると、サービス契約１０８は、サービス消費者１０２およびサービス提供者１０４が合意する様々なパラメータを定義する。これらのパラメータには、例えば、応答時間、時間切れおよび可用性、開発、検査、および生産環境、優先度およびキーワード、法的強制力要件などが含まれ得る。
【００２８】
定型文書として編成されるとき、サービス契約１０８を、ＩＴシステムによって消費される機械可読コードに変換することは容易なタスクである。機械可読コードは、ＩＴサービスライフサイクル１１０で使用され得る。ＩＴサービスライフサイクル１１０の設計段階１１２では、サービス契約１０８を使ってサービス定義１１４およびサービス管理モデル１１６が形成される。サービス管理モデル１１６は、健全性モデルとも呼ばれ得る。サービス定義１１４およびサービス管理モデル１１６は、ＩＴサービスライフサイクル１１０の残りの部分全体を通じて、サービス契約で指定される義務を履行する際に必要とされる管理タスクの実行を円滑化するのに使用される。
【００２９】
設計段階１１２において、設計者は、システムを使用する業務ユーザの機能的ニーズ、およびサービスが運用され、維持され、時間の経過とともにアップグレードされることを可能にする非機能的属性を考慮すべきである。サービス管理モデル１１６を設計するときには、いくつかの問題を考慮すべきである。設計者は、例えば、システムおよびネットワークパラメータを含むサービス構成、メッセージセキュリティポリシーならびに業務規則、識別情報および資格付与、サービス編成、セキュリティデータ（信任状および資格付与）の管理およびサービス構成およびポリシーの管理を含むディレクトリサービスの役割、インフラストラクチャとの整合性、運用プロセスなどを考慮すべきである。
【００３０】
次に図２を参照して、サービス定義１１４動作をより詳細に考察する。図２には、さらに、図１に示すサービス管理モデル１１６の一部とすることのできるサービス義務２０２が示されている。図２には、サービス定義１１４がサービス実装形態２０４を定義し、それがさらに、サービスポリシー２０６、サービス設定２０８、およびサービス計測２１０によって定義されることが示されている。サービス計測は、さらに、イベント２１２、トレース２１４、プローブ２１６および性能カウンタ２１８を定義する。
【００３１】
イベント２１２、トレース２１４、プローブ２１６および性能カウンタ２１８は、サービス管理モデル１１６（図１）によって使用され得るデータを生成する。具体的には、イベント２１２は、実行される必要のあるタスクを定義する管理イベントを定義する。トレース２１４は、システムのデバッグおよび診断のためのデータを提供する。性能カウンタ２１８は、システムが健全に動作しているかどうか示す。プローブ２１６は、管理アプリケーションによって照会され、制御され得る内部サービス状態である。
【００３２】
サービス義務２０２には、サービス実装形態２０４によって生成されるデータを消費する様々な規則が含まれる。サービス義務２０２には、サービス運用規則２２０およびサービス履行規則２２２が含まれる。これらの規則は、パラメータ２２４、条件２２６および処置２２８を持つ。条件２２６は、サービス契約１０８で指定される諸条件を反映する。処置２２８は、サービス実装形態２１０からのデータに基づいて管理タスクをトリガする警報、電子メールなどの項目を含み得る。
【００３３】
図１に戻ると、サービス管理モデル１１６は、図では単一のモデルとして示されているが、一実施形態では、いくつかの異なるモデルを含み得る。例えば、サービス管理モデル１１６には、技術サービスの健全性を含む健全性モデル、技術サービスのために変更され得る設定を記述する構成モデル、業務イベントおよび取り込まれる必要のあるデータおよびデータを消費する規則などをモデル化するサービスレベル管理モデルが含まれ得る。
【００３４】
引き続き図１を参照すると、サービス定義１１４およびサービス管理モデル１１６は、ＩＴサービスライフサイクル１１０の他の段階への入力として使用される。開発段階１２０では、設計段階１１２で識別されているサービス計測２１０（図２）からの計測データがプログラムコードとしてまとめられる。具体的には、開発段階１２０の間に、いくつかの問題が対処される。これらの問題には、アプリケーションを検査可能にすること、アプリケーションを配置可能かつ構成可能にすること、バージョン管理を処理すること、セキュリティを処理すること、イベント２１２（図２）を公開するようアプリケーションに書き込むこと、健全性命令またはプローブ２１６（図２）を処理するようアプリケーションに書き込むこと、および廃止予定(deprecation)を処理することが含まれる。
【００３５】
検査段階１２２では、サービス義務２０２（図２）によって定義されるサービス管理モデル１１６パラメータに対する検査が実行される。具体的には、検査段階１２２では、アプリケーションが統制に従うことを検証するための検査が実行される。アプリケーションは、機能性能、限界検査、およびセキュリティ侵入を含む検査を受けることができる。検査段階１２２の間に対処される問題には、単体検査、データセンタ配置可能性、サービス契約適合性、および管理の容易性が含まれる。
【００３６】
配置段階１２４では、サービス管理モデル１１６に何が含まれているかに従って構成データを設定する必要がある。アプリケーションを配置するために、ネットワークインフラストラクチャ、ハードウェアおよびオペレーティングシステムが準備され得る。次いで、アプリケーションが実動環境に配置される。配置段階１２４で対処される問題には、プロビジョニング、バージョン管理、発見可能性、更新ロールアウトのウィンドウ生成(windowing of update rollout)、クラスタ管理、およびインフラストラクチャ変更管理との統合が含まれる。
【００３７】
運用段階１２６では、健全性や性能といった項目が許容可能な限界内にあることを確認するために、すべてのサービス計測２１０（図２）およびサービス義務２０２（図２）中の規則が作用し始める。運用段階１２６での、他の問題には、根本原因の分析、計測および課金、サービス制御構成が含まれる。運用段階１２６は、サービス管理モデル１１６およびサービス定義１１４を利用して、どんな業務上の異常も正しく処理されるよう保証する。
【００３８】
変更管理段階１２８は、サービス定義１１４およびサービス管理モデル１１６を使って、リリースされる必要のあるサービスの新規バージョンがある場合など技術サービスへの変更がある場合に、同じレベルの業務サービスが提供されるようにそれらの変更を処理する。変更管理段階１２８は、サービス契約メトリック、廃止予定、スケーリングのためのインフラストラクチャ調整などの問題に対処し得る。
【００３９】
図１には単一のＩＴサービスライフサイクル１１０が示されているが、複数のＩＴサービスライフサイクル１１０も本明細書で説明する実施形態の範囲内で実施され得ることを当分野の技術者は理解するであろう。例えば、サービス消費者１０２およびサービス提供者１０４は、それぞれ、独自のＩＴシステムにおいて本発明の諸態様を実施することができる。したがって、各ＩＴシステムの特定の機能および要件が考慮されるべきであり、それらは、並列だが別個のＩＴサービスライフサイクル１１０によって表され得る。
【００４０】
同様に、図１に示す業務サービスモデル１００は、ＩＴサービスライフサイクル１１０に示すような設計、開発、検査、配置、運用、変更管理の各段階を含むライフサイクルを明示的に示さないが、業務サービスモデル１００でも同じ、または類似の段階が実施され得る。当然ながら、業務運営を変更し、または微調整する必要、または要求が生じ得る。変更または微調整を円滑に行わせるために、ＩＴサービスライフサイクル１１０などのライフサイクルが、業務モデルの一部として実施され得る。各当事者、すなわちサービス消費者１０２およびサービス提供者１０４がそれぞれ独自のＩＴサービスライフサイクル１１０を実施することができるように、各当事者は、それぞれ独自の業務ライフサイクルを実施することもできる。各企業は、それぞれの独自の業務ライフサイクルで考慮に入れられる個別のリソース、制約条件、課題などを持つ可能性が高い。
【００４１】
図１に示すように、サービス契約１０８からサービス定義１１４およびサービス管理モデル１１６への変換ではポリシー入力１１８が使用される。このポリシー入力１１８は、サービス定義１１４およびサービス管理モデル１１６の具体的詳細の定義を支援するのに使用され得る。例えば、ポリシー入力１１８は、ディレクトリリストエンティティおよび関連する役割を含み得る。ゆえに、所与の役割を持つ個人が所与の管理タスクを実行することを必要とされる場合、サービス管理モデル１１６は、その必要とされる特定の情報を含み得る。例えば、サービス契約が、その企業の重役が週ごとの状況最新情報を提供することを必要とする場合、サービス管理モデル１１６は、重役の職務を有する特定の個人を識別する情報を含み、それらの個人の１人または複数に週ごとの要件を通知する処置を指定する。前述のように、この情報は、サービス契約１０８およびポリシー入力１１８を使ってサービス管理モデル１１６に形成され得る。
【００４２】
サービス管理モデル１１６は、一実施形態では、管理タスクを記述する直列化データブロックである。例えば、管理モデルは、実行されるべきタスク、それらのタスクが実行されるべき時刻、タスクが確実に実行されるよう保証するための追跡などを記述し得る。サービス管理モデル１１６は、さらに、タスクが署名されなければならないかどうか、どんな種類の署名および／または証明書が使用される必要があるか、どんな職務が署名する必要があるかなどを示す情報も含み得る。サービス管理モデル１１６は、健全性モデル化、ライフサイクルなども含み得る。
【００４３】
健全性モデル化は、システムによって何が健全である（正常な条件内で動作している）とされ、または不健全である（障害がある、または機能低下している）とされるかを定義する。アプリケーションを実行し続けるために、アプリケーション健全性メトリックが監視され、問題の徴候が検出され、問題の原因が診断され、好ましくはアプリケーションが不適格に動作する前に、問題が修正される。これを達成するために、アプリケーションに関する適切な情報が適切な時に提供され、機能低下した動作状態を検出し、検証し、診断し、そこから回復するためのステップが識別され、これらのステップを自動化するコードが書き込まれ、アプリケーションの挙動が、その遷移および依存関係と共に文書化される。
【００４４】
他の実施形態を制限するものではないが、１つの具体的実施形態では、サービス定義１１４およびサービス管理モデル１１６は、ＸＭＬ文書などの直列化機械可読コードとして実施され得る。直列化機械可読コードは、例えば、Ｗｅｂサービスアプリケーションで使用するためのＷＳＤＬ文書とすることができる。
【００４５】
次に、図３および４を参照すると、サービス契約からのパラメータを含む直列化機械可読コードで実施され得る属性値を含む２つの表が示されている。属性値を列に示し、商取引パターンを行に示してある。具体的には、図３には、要求側業務活動の直列化機械可読コードに含まれる属性値が示されている。図４には、応答側業務活動の機械可読コードに含まれる属性値が示されている。
【００４６】
次に、図３を参照すると、商取引のサービス提供者は、（ａ）受信を確認する時間（列３０２）、（ｂ）受諾を確認する時間（列３０４）、（ｃ）実行する時間（列３０６）、（ｄ）必要な許可（列３０８）、（ｅ）発信および内容の否認防止（列３１０）、（ｆ）受信の否認防止（列３１２）、および（ｇ）反復（列３１４）を含むパラメータを提供する。
【００４７】
受信を確認する時間（列３０２）は、指定される（すなわちヌルでない）とき、時間間隔を指定する値を含む。この時間間隔は、要求側業務文書をその時間間隔内に検証することに対する両当事者の合意を表す。
【００４８】
受諾を確認する時間（列３０４）は、指定されるとき、時間間隔を指定する値を含む。この時間間隔は、要求側業務文書が１組の業務規則に合格した後、応答側当事者によって業務受諾文書が返されるという両当事者の合意を表す。
【００４９】
実行する時間（列３０６）は、時間間隔を指定する値を含む。この時間間隔は、両当事者がビジネス相互作用全体を実行することに合意する全体時間を表す。
【００５０】
必要な許可（列３０８）は、２進の真または偽の値を含む。この値が真であるとき、送信側職務の識別情報が検証される。
【００５１】
発信および内容の否認防止（列３１０）は、２進の真または偽の値を含む。この値が真であるとき、業務活動はその元の形で業務文書を格納する。
【００５２】
受信の否認防止（列３１２）は、指定されるとき、２進の真または偽の値を含む。この値が真であるとき、両当事者は、要求側業務文書の受信を相互に確認することに同意する。
【００５３】
反復（列３１４）は、送信が試みられる所定の回数を指定する数値を含む。この値は、時間切れ例外条件が通知されるときの取引を再試行する回数への合意を表す。
【００５４】
次に、図４を参照すると、商取引のサービス消費者は、（ａ）受信を確認する時間（列４０２）、（ｂ）受諾を確認する時間（列４０４）、（ｃ）実行する時間（４０６）、（ｄ）必要な許可（列４０８）、および（ｅ）発信および内容の否認防止（列４１０）を含むパラメータを提供する。
【００５５】
受信を確認する時間（列４０２）は、指定される（すなわちヌルでない）とき、時間間隔を指定する値を含む。この時間間隔は、要求側業務文書をその時間間隔内に検証することに対する両当事者の合意を表す。
【００５６】
受諾を確認する時間（列４０４）は、指定されるとき、時間間隔を指定する値を含む。この時間間隔は、要求側業務文書が１組の業務規則に合格した後、応答側当事者によって業務受諾文書が返されるという両当事者の合意を表す。
【００５７】
実行する時間（列４０６）は、時間間隔を指定する値を含む。この時間間隔は、両当事者がビジネス相互作用全体を実行することに合意する全体時間を表す。
【００５８】
必要な許可（列４０８）は、２進の真または偽の値を含む。この値が真であるとき、送信側職務の識別情報が検証される。
【００５９】
発信および内容の否認防止（列４１０）は、２進の真または偽の値を含む。この値が真であるとき、業務活動はその元の形で業務文書を格納する。
【００６０】
図５を参照すると、本発明を実施する例示的システムは、処理装置５２１、システムメモリ５２２、およびシステムメモリ５２２を含む様々なシステム構成要素を処理装置５２１に結合するシステムバス５２３を含む、コンピュータ５２０の形で汎用コンピューティングデバイスを含む。システムバス５２３は、様々なバスアーキテクチャのいずれかを使用したメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む数種類のバス構造のいずれでもよい。システムメモリには、読取り専用メモリ（ＲＯＭ）５２４およびランダムアクセスメモリ（ＲＡＭ）５２５が含まれる。基本入出力システム（ＢＩＯＳ）５２６は、始動時などに、コンピュータ５２０内の諸要素間での情報転送を支援する基本ルーチンを含み、ＲＯＭ５２４に格納され得る。
【００６１】
コンピュータ５２０は、磁気ハードディスク５３９との間で読取りまたは書込みを行う磁気ハードディスクドライブ５２７、着脱式磁気ディスク５２９との間で読取りまたは書込みを行う磁気ディスクドライブ５２８、およびＣＤ−ＲＯＭや他の光媒体などの着脱式光ディスク５３１との間で読取りまたは書込みを行う光ディスクドライブ５３０も含み得る。磁気ハードディスクドライブ５２７、磁気ディスクドライブ５２８、および光ディスクドライブ５３０は、それぞれ、ハードディスクドライブインターフェース５３２、磁気ディスクドライブインターフェース５３３、および光ドライブインターフェース５３４によってシステムバス５２３に接続される。各ドライブおよびそれに関連するコンピュータ可読媒体は、コンピュータ５２０のためのコンピュータ実行可能命令、データ構造、プログラムモジュールおよびその他のデータの不揮発性記憶を提供する。本明細書で説明する例示的環境は、磁気ハードディスク５３９、着脱式磁気ディスク５２９および着脱式光ディスク５３１を用いるが、磁気カセット、フラッシュメモリカード、ディジタル多用途ディスク、ベルヌーイカートリッジ、ＲＡＭ、ＲＯＭなどを含む、データを格納する他の種類のコンピュータ可読媒体も使用され得る。
【００６２】
１つまたは複数のプログラムモジュールを備えるプログラムコード手段は、ハードディスク５３９、磁気ディスク５２９、光ディスク５３１、ＲＯＭ５２４またはＲＡＭ５２５上に格納され、オペレーティングシステム５３５、１つまたは複数のアプリケーションプログラム５３６、他のプログラムモジュール５３７、およびプログラムデータ５３８を含み得る。ユーザは、キーボード５４０、ポインティングデバイス５４２、またはマイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナといった他の入力装置（図示せず）を介してコンピュータ５２０にコマンドおよび情報を入力することができる。上記その他の入力装置は、しばしば、システムバス５２３に結合されたシリアルポートインターフェース５４６を介して処理装置５２１に接続される。代替として、入力装置は、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）といった他のインターフェースによっても接続され得る。モニタ５４７または別の表示装置も、ビデオアダプタ５４８などのインターフェースを介してシステムバス５２３に接続される。モニタ以外に、パーソナルコンピュータは、通常、スピーカやプリンタなど、他の周辺出力装置（図示せず）も含む。
【００６３】
コンピュータ５２０は、リモートコンピュータ５８３、５９３など、１つまたは複数のコンピュータへの論理接続を使用するネットワークで接続された環境で動作し得る。リモートコンピュータ５８３および５９３は、それぞれ、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の一般のネットワークノードとすることができ、通常、コンピュータ５２０に関連して前述した要素の多くまたはすべてを含む。図５に示す論理接続には、ローカルエリアネットワーク（ＬＡＮ）５５１および広域ネットワーク（ＷＡＮ）５５２が含まれるが、これらは例として示すものであり、限定するためのものではない。そのようなネットワーク環境は、事業所規模または企業規模のコンピュータネットワーク、イントラネットおよびインターネットでは一般的なものである。
【００６４】
ＬＡＮネットワーク環境で使用されるとき、コンピュータ５２０は、ネットワークインターフェースまたはアダプタ５５３を介してローカルネットワーク５５１に接続される。ＷＡＮネットワーク環境で使用されるとき、コンピュータ５２０は、モデム５５４、無線リンク、またはインターネットなどの広域ネットワーク５５２を介して通信を確立する他の手段を含み得る。モデム５５４は、内蔵とすることも外付けとすることもでき、シリアルポートインターフェース５４６を介してシステムバス５２３に接続される。ネットワークで接続された環境では、コンピュータ５２０に関連して示すプログラムモジュール、またはその一部は、リモートメモリ記憶装置にも格納することができる。図示のネットワーク接続は例示であり、広域ネットワーク５５２を介して通信を確立する他の手段も使用され得ることが理解されるであろう。
【００６５】
本発明は、法的拘束力を持つ業務契約を実現する方法とシステムの両方に適用される。本発明の実施形態は、詳細に前述したような様々なコンピュータハードウェアを含む、１つまたは複数の専用および／または１つまたは複数の汎用コンピュータを備え得る。
【００６６】
本発明は、機能的ステップおよび／または非機能的動作を含む方法の観点からも説明され得る。以下は、本発明を実施する際に実行され得る動作およびステップの説明である。普通、機能的ステップは、達成される結果の観点から本発明を記述し、非機能的動作は、特定の結果を達成するより具体的な動作を記述する。機能的ステップおよび非機能的動作は、特定の順序で記述され、特許請求され得るが、本発明は、必ずしも、どれか特定の順序、あるいは動作および／またはステップの組み合わせに限定されるとは限らない。
【００６７】
本発明の範囲内の実施形態には、コンピュータ実行可能命令またはデータ構造を搬送し、または格納しているコンピュータ可読媒体も含まれる。そのようなコンピュータ可読媒体は、汎用または専用コンピュータによってアクセスされ得る任意の利用可能な媒体とすることができる。例をあげると、それだけに限らないが、そのようなコンピュータ可読媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭなどの光ディスク記憶、磁気ディスク記憶などの磁気記憶装置、または所望のプログラムコード手段をコンピュータ実行可能命令またはデータ構造の形で搬送または格納するのに使用することができ、汎用または専用コンピュータによってアクセスされ得る他の任意媒体が含まれ得る。情報が、ネットワークまたは別の通信接続（有線、無線、あるいは有線または無線の組み合わせ）を介してコンピュータに転送され、あるいは提供されるとき、コンピュータは、その接続を適切にコンピュータ可読媒体として見る。ゆえに、任意のそのような接続は、適切に、コンピュータ可読媒体と呼ばれる。上記の組み合わせも、コンピュータ可読媒体の範囲内に含むべきである。コンピュータ実行可能命令には、例えば、汎用コンピュータ、専用コンピュータ、または専用処理装置に、一定の機能または機能グループを実行させる命令およびデータが含まれる。
【００６８】
本発明は、その精神または本質的特性から逸脱することなく、他の特定の形で実施され得る。前述の実施形態は、あらゆる点において、例示にすぎず、非限定的なものであるとみなすべきである。したがって、本発明の範囲は、前述の説明によってではなく、添付の特許請求の範囲によって指示されるものである。特許請求の範囲と等価の意味および範囲に含まれるすべての変更は、特許請求の範囲内に包含すべきものである。
【図面の簡単な説明】
【００６９】
【図１】本発明の様々な態様による業務サービスモデルおよびＩＴサービスライフサイクルの相互作用を示す図である。
【図２】管理タスクの実行を円滑化する様々なＩＴコンポーネントの相互作用を示すブロック図である。
【図３】要求側業務活動のメッセージでの属性値を示す表である。
【図４】応答側業務活動のメッセージでの属性値を示す表である。
【図５】本発明の諸態様が実施され得る１つの典型的なシステムを示す図である。
【符号の説明】
【００７０】
１００  業務サービスモデル
１０２  サービス消費者
１０４  サービス提供者
１０６  パターン
１０８  サービス契約
１１０  ＩＴサービスライフサイクル
１１２  設計
１１４  サービス定義
１１６  サービス管理モデル
１１８  ポリシー
１２０  開発
１２２  検査
１２４  配置
１２６  運用
１２８  変更管理
【図１】
2006146892.tif 000003
【図２】
2006146892.tif 000004
【図３】
2006146892.tif 000005
【図４】
2006146892.tif 000006
【図５】
2006146892.tif 000007