▶ インターナショナル・ビジネス・マシーンズ・コーポレーションの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-11-17
(54)【発明の名称】ワークフローパッチング
(51)【国際特許分類】
G06F 9/50 20060101AFI20231110BHJP
【ＦＩ】
G06F9/50 120Z
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023526625
(86)(22)【出願日】2021-10-28
(85)【翻訳文提出日】2023-05-01
(86)【国際出願番号】 CN2021126861
(87)【国際公開番号】W WO2022100439
(87)【国際公開日】2022-05-19
(31)【優先権主張番号】16/949,741
(32)【優先日】2020-11-12
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】390009531
【氏名又は名称】インターナショナル・ビジネス・マシーンズ・コーポレーション
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【住所又は居所原語表記】Ｎｅｗ Ｏｒｃｈａｒｄ Ｒｏａｄ， Ａｒｍｏｎｋ， Ｎｅｗ Ｙｏｒｋ １０５０４， Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】100112690
【弁理士】
【氏名又は名称】太佐 種一
(74)【代理人】
【識別番号】100120710
【弁理士】
【氏名又は名称】片岡 忠彦
(74)【復代理人】
【識別番号】100104880
【弁理士】
【氏名又は名称】古部 次郎
(74)【復代理人】
【識別番号】100118108
【弁理士】
【氏名又は名称】久保 洋之
(72)【発明者】
【氏名】ジョンストン、マイケル
(72)【発明者】
【氏名】ヴァシレイアディス、ヴァシレイオス
(57)【要約】
コンピューティングシステム内の１つ以上のプロセッサによって、コンピューティング環境におけるワークフローのパッチングを行うための方法が提供される。１つ以上のパッチをソースワークフローから抽出してもよい。１つ以上のパッチを、複数のノードにおけるターゲットワークフローに適用することによって、ターゲットワークフローを静的または動的に修正してもよい。１つ以上のパッチの適用に従って、ターゲットワークフローがアクティブである間に、複数のノードのうちの１つ以上をターゲットワークフローにおいて追加、削除、または修正してもよい。
【特許請求の範囲】
【請求項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】
１つ以上のプロセッサによってコンピューティング環境におけるワークフローのパッチングを行うための方法であって、ソースワークフローから１つ以上のパッチを抽出することと、
前記１つ以上のパッチを、複数のノードにおけるターゲットワークフローに適用することによって、当該ターゲットワークフローを静的または動的に修正することと、
前記１つ以上のパッチの適用に応じて、前記ターゲットワークフローにおける前記複数のノードのうちのノードの構成を修正することと、
前記１つ以上のパッチの適用に応じて、前記ターゲットワークフローにおける前記複数のノードのうちのノード、およびアクティブまたは非アクティブな依存ノードを特定し、削除することと、
を含む、方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、一般にコンピューティングシステムに関し、より具体的には、コンピューティングシステムにおけるコンピューティング環境において、コンピューティングプロセッサによってワークフローの静的または動的パッチングを行うための種々の実施形態に関する。
【発明の概要】
【0002】
本発明の一実施形態によれば、コンピューティングシステムにおいてワークフローの静的または動的パッチングを行うための方法が提供される。ソースワークフローから抽出された１つ以上のパッチを、複数のノードにおけるターゲットワークフローに適用してもよい。１つ以上のパッチの適用に応じて、ターゲットワークフローがアクティブである間に、ターゲットワークフローにおける複数のノードのうちの１つ以上を追加、削除、または修正してもよい。
【0003】
さらなる実施形態において、１つ以上のパッチは、ソースワークフローから抽出されてもよい。複数のノードにおけるターゲットワークフローに１つ以上のパッチを適用することによって、ターゲットワークフローを静的または動的に修正してもよい。１つ以上のパッチの適用に応じて、ターゲットワークフローがアクティブである間に、複数のノードのうちの１つ以上をターゲットワークフローにおいて追加、削除、または修正してもよい。
【0004】
別の実施形態において、１つ以上のパッチがソースワークフローから抽出されてもよい。１つ以上のパッチを複数のノードにおけるターゲットワークフローに適用することによって、ターゲットワークフローを静的または動的に修正してもよい。１つ以上のパッチの適用に応じて、ターゲットワークフローにおける複数のノードのうちのノードの構成を修正してもよい。１つ以上のパッチの適用に応じて、ターゲットワークフローにおける複数のノードのうちのノード、およびアクティブまたは非アクティブな依存ノードを特定し、選択的に削除してもよい。
【0005】
一実施形態は、コンピュータ使用可能プログラム製品を含む。コンピュータ使用可能プログラム製品は、コンピュータ可読ストレージデバイスと、ストレージデバイスに記憶されたプログラム命令とを含む。
【0006】
一実施形態は、コンピュータシステムを含む。コンピュータシステムは、プロセッサと、コンピュータ可読メモリと、コンピュータ可読ストレージデバイスと、メモリを介してプロセッサが実行するためにストレージデバイスに記憶されたプログラム命令とを含む。
【0007】
したがって、上述した例示的な方法実施形態に加えて、コンピューティング環境におけるワークフローの静的または動的パッチングを行うための他の例示的なシステムおよびコンピュータ製品実施形態が提供される。
【図面の簡単な説明】
【0008】
【図1】本発明の一実施形態に係る、クラウドコンピューティングノードの一例を示すブロック図である。
【図2】本発明の一実施形態に係る、クラウドコンピューティング環境を示す図である。
【図3】本発明の一実施形態に係る、抽象化モデルレイヤを示す図である。
【図4】本発明の種々の態様間での機能的関係の一例を示す追加ブロック図である。
【図5A】本発明の態様を実現可能なプロセッサによって、コンピューティング環境においてワークフローの静的または動的パッチングを行うための一例としてのシステムおよび機能を示すブロックフローチャートである。
【図5B】本発明の態様を実現可能なプロセッサによって、コンピューティング環境においてワークフローの静的または動的パッチングを行うための一例としてのシステムおよび機能を示すブロックフローチャートである。
【図5C】本発明の態様を実現可能なプロセッサによって、コンピューティング環境においてワークフローの静的または動的パッチングを行うための一例としてのシステムおよび機能を示すブロックフローチャートである。
【図5D】本発明の態様を実現可能なプロセッサによって、コンピューティング環境においてワークフローの静的または動的パッチングを行うための一例としてのシステムおよび機能を示すブロックフローチャートである。
【図5E】本発明の態様を実現可能なプロセッサによって、コンピューティング環境においてワークフローの静的または動的パッチングを行うための一例としてのシステムおよび機能を示すブロックフローチャートである。
【図6】本発明の態様を実現可能なプロセッサによって、コンピューティング環境においてワークフローの静的または動的パッチングを行うための一例としての方法のフローチャートである。
【図7】本発明の態様を実現可能なプロセッサによって、コンピューティング環境においてワークフローの静的または動的パッチングを行うための一例としての方法のフローチャートである。
【図8】本発明の態様を実現可能なプロセッサによって、コンピューティング環境においてワークフローの静的または動的パッチングを行うための一例としての方法のフローチャートである。
【発明を実施するための形態】
【0009】
コンピューティングリソースは通常、ベンダによって固定レベルの構成で事前に構成されている。１つの側面として、メモリサイズ、ＣＰＵの数、ディスクサイズなどの個々のコンピューティングリソースは、限られた境界を有している。別の側面として、各コンピューティングプラットフォームは、物理的なカスタマイズオプションの数が制限されている。今日のワークロードはこれらの制限の中で実行されており、これがひいては、メモリスワッピングやキャッシュ最適化などの技術がコンピューティング環境で使用される理由となっている。
【0010】
例えば、クラウドコンピューティングは概して、あたかも無限に思われるリソースプールを提供し、リソースをユーザに対して弾力的にプロビジョニングおよびプロビジョニング解除（de-provision）する。この動的なプロビジョニングは、例えば、深層学習トレーニングやハイパフォーマンスコンピューティング（「ＨＰＣ」）などの、パフォーマンス依存型（performance-sensitive）のワークロードにとってはコストとなる。これらのワークロードは、最適な実行時間を達成するために、プロビジョニングされたリソースを可能な限り近くに配置する必要がある。これらのワークロードは、計算サイクルと通信サイクルが交互に繰り返される。そして、計算サイクルが最も遅く、かつ他のマシンとの通信サイクルが最も長いマシンによって、進行速度が制限される。
【0011】
ワークフロー管理は、ワークフローとして配置可能なプロセスにおける定義されたタスクのセットアップ、実行および監視を行うためのインフラストラクチャを提供する。現在のワークフローシステムは、プロセスのモデルが利用可能であることを前提としており、システムの主なタスクは、すべてのアクティビティが正しい順序で実行され、プロセスが正常に終了するようにすることである。ワークフロープロセスの個々のタスクは、後続タスクを開始し完了する前に、先行タスクが完了していることに依存する場合がある。プロセスのどの段階でも、先行タスクの完了が遅れると、連鎖的に後続タスクの完了が遅れ、したがってプロセス全体の完了が遅れる可能性がある。
【0012】
いくつかのアプリケーションは、例えば科学者の研究速度などのジョブパフォーマンスを速めるために、ワークフロースケジューラを使用してきた。例えば、ワークフロースケジューラは、エンドユーザ（例えば、科学者）が、ハイパフォーマンスコンピューティング（ＨＰＣ）／クラウドコンピューティングに関する専門知識を必要とすることなく、ＨＰＣおよびクラウドリソースを使用して特定の主題（例えば、科学者の研究）に集中することを可能にする。また、ワークフローは、再現可能かつ移植可能（pipelines）なパイプラインという考え方を推進するものである。その結果、ユーザ（科学者、研究者など）は、例えば科学者の研究などの情報を他のエンティティ（研究チームなど）と共有することが可能になる。直感的に分かることであるように、ワークフローは、クラウドコンピューティングに対してコンテナが与える影響と同じく、研究にとって大きなインパクトを与えるものである。もちろん、例えば科学者のようなエンドユーザは、ワークフローを使用することのみに限定されない。ユーザは、自分のニーズに合わせてワークフローを修正することも可能であり、一般的にそうしている。ワークフローは、ライブラリから取得されてもよい。いくつかのＨＰＣ／クラウドインフラストラクチャ上でワークフローを開始する前に、ワークフローを調整してノードを追加、削除、修正してもよい。ワークフローが終了すると、研究者／ツールはワークフローの出力を分析し、この情報を使用してワークフローを改善してもよい。このフィードバックループは、望ましい結果に達するまで何度も繰り返すことができる。
【0013】
ワークフローを用いた作業は、エンドユーザがアクティブワークフローの修正を望む場合に複雑になる。これは特に困難な操作であり、ワークフローユーザが、一般的に静的パッチング（static patching）を介してワークフローを停止、修正、再開する理由となっている。静的パッチングの方がはるかに簡単ではあるが、ワークフローを停止するとノードのタスクが即座に終了する可能性があるため、進捗が失われる可能性がある。そのため、ユーザがワークフローを静的に（すなわち、ワークフローがアクティブでない状態で）、あるいは動的に変更できることが求められている。
【0014】
したがって、本発明の種々の実施形態は、ワークフローの静的または動的パッチングを可能にする。一態様において、パッチをソースワークフロー（source workflow）から抽出し、ターゲットワークフロー（target workflow）に適用してもよい。静的パッチは、１）新たなノードを注入し、２）ターゲットワークフローからノードを削除し、３）ターゲットワークフロー内の任意のノードを修正してもよい。動的パッチは、１）ワークフローの停止および再開を必要とせずに適用してもよく、もしくは、２）ターゲットワークフロー内のノード（例えば、動的パッチング時にアクティブもしくは非アクティブであるノード、またはそのライフタイムにわたって複数のタスクをアクティブに生成するノード）の将来のタスクを修正してもよく、またはその両方を行ってもよい。一態様において、（静的または動的な）「パッチ」とは、コンピュータプログラムの問題を修正／対処するように設計されたソフトウェアの一部としてのコンピュータアプリケーションパッチであってもよい。例えば、パッチを使用して、セキュリティ脆弱性の修正、プログラミングバグ（エラー）の修正、既存の機能の改善、またはコンピュータプログラムのソフトウェア動作の変更を行ってもよい。パッチは、ハイパーバイザ、オペレーティングシステム、ミドルウェア、その他様々なコンピュータソフトウェアアプリケーションに適用してもよい。
【0015】
一態様において、ワークフローは、機械学習動作（例えば、人工知能）を使用して、静的に（すなわち、ワークフローが非アクティブのときに）修正されてもよいし、動的に修正されてもよい。機械学習動作によって、ソースワークフローからターゲットワークフローに抽出されたパッチを静的または動的に修正することを学習してもよい。ターゲットワークフローは、機械学習動作によって特定されてもよい。
【0016】
さらなる態様において、例示される実施形態のメカニズムは、ソースワークフローからロバストパッチ（robust patches）を抽出し、この抽出したパッチを静的パッチングまたは動的パッチングを介して適用することを可能にする。動的パッチングは、動的パッチングの実行時に、アクティブなターゲットワークフローの停止もしくは再開またはその両方を必要とせずに、ターゲットワークロードに適用することができる。このように、ソースワークフローからターゲットワークフローへのワークフローの静的または動的パッチングを実現することにより、ＨＰＣおよびクラウドインフラストラクチャを使用したテストやデバッグの時間（例えば、開発時間）、もしくは、生産サイクル中にワークフローを利用する研究／製品の「市場投入までの時間」、またはその両方を短縮する。これらの改善により、研究開発のコストを削減することもできる。
【0017】
本明細書において、ワークフローは有向非巡回グラフ（directed acyclic graph）であってもよい。グラフのノードは、アプリケーション／サービスであってもよく、グラフのエッジは、ノード間の１つ以上の依存関係を示してもよい。タスク（例えば、ワークフローのタスク）は、アプリケーション／サービスの実行であってもよい。ワークフローオーケストレータ／マネージャは、ワークフローおよびそのノードの構成を解釈して、グラフのノードを作成、管理、および監視するフレームワークであってもよい。
【0018】
スケジューラ（例えば、ワークフロースケジューラ）は、ワークフローオーケストレータ／マネージャから命令を受け取り、タスクのスケジューリング、管理、および監視の処理、操作、もしくは調整またはその組み合わせを行うことができる。ノードの構成、すなわち「ノード構成」は、ノードの動作およびノードのタスクを規定する情報とすることができる。情報は、実行可能タスク、実行可能タスクへの引数、コンテナイメージ、環境変数、ファイル依存関係、他のノードへの入力依存関係、バックエンドオプション（すなわち、キュー、クラスタセレクタなど）、スケジューリングを改善するメタデータ、もしくはエラー検出および修正、またはその組み合わせを含む（ただし、これらに限定されない）。
【0019】
さらに、別の態様において、本発明は、パッチされる（patched-in）ノードの入力を、ターゲットワークフロー内のノードの出力に自動的に接続できるようにする。パッチされるノードに入力を提供するターゲットノードの構成と、パッチされるノードへの入力ノードの予想構成（expected configuration）との間で、１つ以上の競合（conflict）が検出され、解決されてもよい。例示される実施形態のメカニズムは、ワークフローに対する外部依存の様々な概念（例えば、ファイルシステム上に存在すべきファイル、ワークフローの実行時にワークフローに提供されるファイルなど）をさらに理解する。本明細書に記載するような動的パッチングはまた、パッチング動作のために実装される追加のソフトウェア／アプリケーションコードを必要とせず、さらに、動的パッチングは、パッチング動作を実行するためにアクティブワークフローを停止および再開することを必要としない。このように、動的パッチングは、アクティブターゲットワークフロー内のアクティブノードの修正をサポートし可能にすると同時に、アクティブターゲットワークフローから既存のノードを削除することをサポートし可能にする。したがって、動的パッチングは、アクティブターゲットワークロードを開始、停止、または再開することなく、ａ）新たなノードの追加、ｂ）既存のノードの修正、ｃ）既存のノードの削除によってワークフローを動的に修正することができる。
【0020】
さらなる態様において、ワークフローの静的または動的パッチングは、結果として生じるワークフローを、新たなワークフローとして考える。新たなワークフローは、アーティファクト／ノードを再利用してもよい。これにより、ワークフローの静的または動的パッチングは、より大きな自由度を持って動作することができ、ターゲットワークフローに対してより大胆な変更を実行することができる。ワークフローの静的または動的パッチングは、任意のサブワークフローに新たなノードを追加してもよい。サブワークフローは、その入力をターゲットワークフローの既存のノードに自動的にマッピングし、ターゲットワークフローの任意のノードを削除し、もしくは、ターゲットワークフロー全体の署名／構造および機能を変更し、またはその組み合わせなどを行う。
【0021】
また、ワークフローの静的または動的パッチングは、以下の一連の規則および定義に基づいて動作することができる。「バックエンド」は、いくつかの物理的／仮想的ハードウェアを使用してプロセスまたはサービスを実行する。バックエンドは、例えば、ＯｐｅｎＳｈｉｆｔ、Ｋｕｂｅｒｎｅｔｅｓ、クラウド／ハイブリッドクラウド、負荷分散機構（「ＬＳＦ：load sharing facility」）などであってもよい。タスクは、バックエンド上で実行されるプロセスまたはサービスであってもよい。ワークフローノードは、バックエンドがタスクの実行に使用する情報を含んでもよい。ワークフローマネージャは、ワークフローの実行を調整し、ワークフローノードの個々のタスクのスケジューリング決定をスケジューラに委任する。スケジューラは、ワークフローのノード間の依存関係を理解する。スケジューラは、ノードが実行可能になるタイミングを判断し、そのノードのタスクをバックエンドで実行するタイミングを決定する。オンライン／動的パッチングは、ワークフローがアクティブな状態（すなわち、ノードの少なくとも１つが、実行可能であるか、バックエンドでタスクをアクティブに実行中であるかのいずれか）のときに、ワークフローを修正するプロセスを指してもよい。パッチングは、ワークフローグラフに新たなノードを追加したり、ワークフロー内の既存のノードを修正したり、ワークフロー内の既存のノードを削除したりしてもよい。修正された既存のノードは、将来（すなわちパッチアプリケーションの終了後に）実行されるタスクにのみ修正が反映される。
【0022】
本開示は、クラウドコンピューティングに関する詳細な説明を含むが、本明細書に記載された教示の実装形態は、クラウドコンピューティング環境に限定されないことがあらかじめ理解される。むしろ、本発明の実施形態は、現在知られている又は後に開発される任意の他のタイプのコンピューティング環境と組み合わせて実施することが可能である。
【0023】
クラウドコンピューティングは、設定可能なコンピューティングリソースの共有プール（例えばネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、記憶装置、アプリケーション、仮想マシンおよびサービス）へ、簡便かつオンデマンドのネットワークアクセスを可能にするためのサービス提供のモデルであり、リソースは、最小限の管理労力または最小限のサービスプロバイダとのやり取りによって速やかに準備（provision）およびリリースできるものである。このクラウドモデルは、少なくとも５つの特性、少なくとも３つのサービスモデル、および少なくとも４つの展開モデルを含むことができる。
【0024】
特性は以下の通りである。
【0025】
オンデマンド・セルフサービス：クラウドの消費者は、サービスプロバイダとの人的な対話を必要することなく、必要に応じて自動的に、サーバ時間やネットワークストレージなどのコンピューティング能力を一方的に準備することができる。
【0026】
ブロード・ネットワークアクセス：コンピューティング能力はネットワーク経由で利用可能であり、また、標準的なメカニズムを介してアクセスできる。それにより、異種のシンまたはシッククライアントプラットフォーム（例えば、携帯電話、ラップトップ、ＰＤＡ）による利用が促進される。
【0027】
リソースプーリング：プロバイダのコンピューティングリソースはプールされ、マルチテナントモデルを利用して複数の消費者に提供される。様々な物理リソースおよび仮想リソースが、需要に応じて動的に割り当ておよび再割り当てされる。一般に消費者は、提供されたリソースの正確な位置を管理または把握していないため、位置非依存（location independence）の感覚がある。ただし消費者は、より高い抽象レベル（例えば、国、州、データセンタ）では場所を特定可能な場合がある。
【0028】
迅速な柔軟性（elasticity）：コンピューティング能力は、迅速かつ柔軟に準備することができるため、場合によっては自動的に、直ちにスケールアウトし、また、速やかにリリースされて直ちにスケールインすることができる。消費者にとって、準備に利用可能なコンピューティング能力は無制限に見える場合が多く、任意の時間に任意の数量で購入することができる。
【0029】
測定されるサービス：クラウドシステムは、サービスの種類（例えば、ストレージ、処理、帯域幅、アクティブユーザアカウント）に適したある程度の抽象化レベルでの測定機能を活用して、リソースの使用を自動的に制御し最適化する。リソース使用量を監視、制御、および報告して、利用されるサービスのプロバイダおよび消費者の両方に透明性を提供することができる。
【0030】
サービスモデルは以下の通りである。
【0031】
サービスとしてのソフトウェア（ＳａａＳ）：消費者に提供される機能は、クラウドインフラストラクチャ上で動作するプロバイダのアプリケーションを利用できることである。当該そのアプリケーションは、ウェブブラウザ（例えばウェブメール）などのシンクライアントインタフェースを介して、各種のクライアント装置からアクセスできる。消費者は、ネットワーク、サーバ、オペレーティングシステム、ストレージや、個別のアプリケーション機能さえも含めて、基礎となるクラウドインフラストラクチャの管理や制御は行わない。ただし、ユーザ固有の限られたアプリケーション構成の設定はその限りではない。
【0032】
サービスとしてのプラットフォーム（ＰａａＳ）：消費者に提供される機能は、プロバイダによってサポートされるプログラム言語およびツールを用いて、消費者が作成または取得したアプリケーションを、クラウドインフラストラクチャに展開（deploy）することである。消費者は、ネットワーク、サーバ、オペレーティングシステム、ストレージを含む、基礎となるクラウドインフラストラクチャの管理や制御は行わないが、展開されたアプリケーションを制御でき、かつ場合によってはそのホスティング環境の構成も制御できる。
【0033】
サービスとしてのインフラストラクチャ（ＩａａＳ）：消費者に提供される機能は、オペレーティングシステムやアプリケーションを含む任意のソフトウェアを消費者が展開および実行可能な、プロセッサ、ストレージ、ネットワーク、および他の基本的なコンピューティングリソースを準備することである。消費者は、基礎となるクラウドインフラストラクチャの管理や制御は行わないが、オペレーティングシステム、ストレージ、および展開されたアプリケーションを制御でき、かつ場合によっては一部のネットワークコンポーネント（例えばホストファイアウォール）を部分的に制御できる。
【0034】
展開モデルは以下の通りである。
【0035】
プライベートクラウド：このクラウドインフラストラクチャは、特定の組織専用で運用される。このクラウドインフラストラクチャは、当該組織または第三者によって管理することができ、オンプレミスまたはオフプレミスで存在することができる。
【0036】
コミュニティクラウド：このクラウドインフラストラクチャは、複数の組織によって共有され、共通の関心事（例えば、ミッション、セキュリティ要件、ポリシー、およびコンプライアンス）を持つ特定のコミュニティをサポートする。このクラウドインフラストラクチャは、当該組織または第三者によって管理することができ、オンプレミスまたはオフプレミスで存在することができる。
【0037】
パブリッククラウド：このクラウドインフラストラクチャは、不特定多数の人々や大規模な業界団体に提供され、クラウドサービスを販売する組織によって所有される。
【0038】
ハイブリッドクラウド：このクラウドインフラストラクチャは、２つ以上のクラウドモデル（プライベート、コミュニティまたはパブリック）を組み合わせたものとなる。それぞれのモデル固有の実体は保持するが、標準または個別の技術によってバインドされ、データとアプリケーションの可搬性（例えば、クラウド間の負荷分散のためのクラウドバースティング）を実現する。
【0039】
クラウドコンピューティング環境は、ステートレス性（statelessness）、低結合性（low coupling）、モジュール性（modularity）および意味論的相互運用性（semantic interoperability）に重点を置いたサービス指向型環境である。クラウドコンピューティングの中核にあるのは、相互接続されたノードのネットワークを含むインフラストラクチャである。
【0040】
ここで図１に、クラウドコンピューティングノードの一例の概略図を示す。なお、クラウドコンピューティングノード１０は、好適なクラウドコンピューティングノードの一例に過ぎず、本明細書に記載する本発明の実施形態の使用範囲または機能に関するいかなる限定も示唆することを意図していない。いずれにせよ、クラウドコンピューティングノード１０は、本明細書に記載の機能のいずれかを実装すること、もしくは実行すること、またはその両方を行うことが可能である。
【0041】
クラウドコンピューティングノード１０内には、コンピュータシステム／サーバ１２が存在する。コンピュータシステム／サーバ１２は、他の多くの汎用または専用コンピューティングシステム環境または構成とともに動作可能である。コンピュータシステム／サーバ１２とともに使用するのに適している可能性がある周知のコンピューティングシステム、環境、もしくは構成またはその組み合わせの例としては、パーソナルコンピュータシステム、サーバコンピュータシステム、シンクライアント、シッククライアント、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル家電、ネットワークＰＣ、ミニコンピュータシステム、メインフレームコンピュータシステム、および、これらのシステムまたはデバイスのいずれかを含む分散型クラウドコンピューティング環境などが挙げられる（ただし、これらに限定されない）。
【0042】
コンピュータシステム／サーバ１２は、コンピュータシステムによって実行されるプログラムモジュールなどの、コンピュータシステム実行可能命令との一般的な関連において説明できる。一般に、プログラムモジュールは、特定のタスクを実行するかまたは特定のデータ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、ロジック、データ構造などを含むことができる。コンピュータシステム／サーバ１２は、通信ネットワークを介してリンクされたリモート処理装置によってタスクが実行される分散型クラウドコンピューティング環境で実施することができる。分散型クラウドコンピューティング環境において、プログラムモジュールは、メモリ記憶装置を含む、ローカルおよびリモート両方のコンピュータシステム記憶媒体に記憶することができる。
【0043】
図１に示すように、クラウドコンピューティングノード１０内のコンピュータシステム／サーバ１２は、汎用コンピューティングデバイスとして示されている。コンピュータシステム／サーバ１２のコンポーネントは、１つ以上のプロセッサまたは処理ユニット１６、システムメモリ２８、および、システムメモリ２８を含む様々なシステムコンポーネントをプロセッサ１６に接続するバス１８を含んでもよい（ただし、これらに限定されない）。
【0044】
バス１８は、様々なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、アクセラレーテッドグラフィックスポート（ＡＧＰ）、およびプロセッサまたはローカルバスを含む複数種類のバス構造のうち１つ以上の任意のものを表す。非限定的な一例として、このようなアーキテクチャは、インダストリスタンダードアーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオエレクトロニクススタンダーズアソシエーション（ＶＥＳＡ）ローカルバス、およびペリフェラルコンポーネントインターコネクト（ＰＣＩ）バスを含む。
【0045】
コンピュータシステム／サーバ１２は一般的に、様々なコンピュータシステム可読媒体を含む。このような媒体は、コンピュータシステム／サーバ１２がアクセス可能な任意の利用可能な媒体とすることができ、揮発性媒体および不揮発性媒体の両方と、取り外し可能媒体および取り外し不可能媒体の両方とを含む。
【0046】
システムメモリ２８は、揮発性メモリとしてのコンピュータシステム可読媒体（ＲＡＭ３０もしくはキャッシュメモリ３２またはその両方など）を含むことができる。コンピュータシステム／サーバ１２はさらに、他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータシステム可読媒体を含んでもよい。あくまでも一例として、ストレージシステム３４は、取り外し不可能な不揮発性磁気媒体（不図示。一般的に「ハードドライブ」と呼ばれる）への読み書きのために設けることができる。また、図示は省略するが、取り外し可能な不揮発性磁気ディスク（例えば、「フロッピーディスク」）への読み書きのための磁気ディスクドライブ、および取り外し可能な不揮発性光学ディスク（ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭや他の光学媒体など）への読み書きのための光学ディスクドライブを設けることができる。これらの例において、それぞれを、１つ以上のデータ媒体インタフェースによってバス１８に接続することができる。以下でさらに図示および説明するように、システムメモリ２８は、本発明の実施形態の機能を実行するように構成されたプログラムモジュールのセット（例えば、少なくとも１つ）を有する少なくとも１つのプログラム製品を含んでもよい。
【0047】
非限定的な一例として、プログラムモジュール４２のセット（少なくとも１つ）を有するプログラム／ユーティリティ４０は、オペレーティングシステム、１つ以上のアプリケーションプログラム、他のプログラムモジュール、およびプログラムデータと同様に、システムメモリ２８に記憶することができる。オペレーティングシステム、１つ以上のアプリケーションプログラム、他のプログラムモジュール、およびプログラムデータ、またはそれらのいくつかの組み合わせの各々は、ネットワーク環境の実装形態を含むことができる。プログラムモジュール４２は、一般に、本明細書に記載する本発明の実施形態の機能もしくは方法またはその両方を実施する。
【0048】
また、コンピュータシステム／サーバ１２は、キーボード、ポインティングデバイス、ディスプレイ２４などの１つ以上の外部装置１４、ユーザと、コンピュータシステム／サーバ１２とのインタラクションを可能にする１つ以上のデバイス、もしくはコンピュータシステム／サーバ１２と１つ以上の他のコンピューティングデバイスとの通信を可能にする任意の装置（例えば、ネットワークカードやモデムなど）またはこれらの組み合わせと通信することができる。このような通信は、入力／出力（Ｉ／Ｏ）インタフェース２２を介して行うことができる。さらに、コンピュータシステム／サーバ１２は、ネットワークアダプタ２０を介して１つ以上のネットワーク（ローカルエリアネットワーク（ＬＡＮ）、汎用広域ネットワーク（ＷＡＮ）、もしくはパブリックネットワーク（例えばインターネット）またはこれらの組み合わせなど）と通信することができる。図示するように、ネットワークアダプタ２０は、バス１８を介してコンピュータシステム／サーバ１２の他のコンポーネントと通信することができる。なお、図示は省略するが、他のハードウェアコンポーネントもしくはソフトウェアコンポーネントまたはその両方を、コンピュータシステム／サーバ１２と併用することができる。それらの一例としては、マイクロコード、デバイスドライバ、冗長化処理ユニット、外付けディスクドライブアレイ、ＲＡＩＤシステム、テープドライブ、データアーカイブストレージシステムなどがある（ただし、これらに限定されない）。
【0049】
ここで、図２に例示的なクラウドコンピューティング環境５０を示す。図示するように、クラウドコンピューティング環境５０は１つ以上のクラウドコンピューティングノード１０を含む。これらに対して、クラウド消費者が使用するローカルコンピュータ装置（例えば、ＰＤＡもしくは携帯電話５４Ａ、デスクトップコンピュータ５４Ｂ、ラップトップコンピュータ５４Ｃ、もしくは自動車コンピュータシステム５４Ｎまたはこれらの組み合わせなど）は通信を行うことができる。ノード１０は互いに通信することができる。ノード１０は、例えば、上述のプライベート、コミュニティ、パブリックもしくはハイブリッドクラウドまたはこれらの組み合わせなど、１つ以上のネットワークにおいて、物理的または仮想的にグループ化（不図示）することができる。これにより、クラウドコンピューティング環境５０は、サービスとしてのインフラストラクチャ、プラットフォームもしくはソフトウェアまたはこれらの組み合わせを提供することができ、クラウド消費者はこれらについて、ローカルコンピュータ装置上にリソースを維持する必要がない。なお、図２に示すコンピュータ装置５４Ａ～Ｎの種類は例示に過ぎず、コンピューティングノード１０およびクラウドコンピューティング環境５０は、任意の種類のネットワークもしくはネットワークアドレス指定可能接続（例えば、ウェブブラウザの使用）またはその両方を介して、任意の種類の電子装置と通信可能であることを理解されたい。
【0050】
ここで、クラウドコンピューティング環境５０（図２）によって提供される機能的抽象化レイヤのセットを図３に示す。なお、図３に示すコンポーネント、レイヤおよび機能は例示に過ぎず、本発明の実施形態はこれらに限定されないことをあらかじめ理解されたい。図示するように、以下のレイヤおよび対応する機能が提供される。
【0051】
デバイスレイヤ５５は、クラウドコンピューティング環境５０において様々なタスクを実行するための物理的デバイスもしくは仮想デバイスまたはその両方、埋め込み式もしくはスタンドアロンまたはその両方の電子機器、センサ、アクチュエータ、およびその他のオブジェクトを含む。デバイスレイヤ５５内のデバイスの各々は、他の機能的抽象化レイヤへのネットワーク接続能力を組み込むことによって、これらのデバイスから得られた情報が他の機能的抽象化レイヤに提供されてもよいし、他の抽象化レイヤからの情報がデバイスに提供されてもよいし、その両方が行われてもよい。一実施形態において、デバイスレイヤ５５を含む様々なデバイスは、「モノのインターネット」（ＩｏＴ）として集合的に公知である、エンティティのネットワークを組み込んでもよい。当業者であれば認識できるように、こうしたエンティティのネットワークは、多様な目的を達成するためのデータの相互通信、収集、および普及を可能にする。
【0052】
図示のデバイスレイヤ５５は、図示のようにセンサ５２、アクチュエータ５３、一体型の処理電子機器、センサ電子機器、およびネットワーク接続電子機器を有する「学習」サーモスタット５６、カメラ５７、制御可能な家庭用コンセント／レセプタクル５８、ならびに制御可能な電気スイッチ５９を含む。他に考えられるデバイスとしては、様々な追加のセンサデバイス、ネットワーク接続デバイス、電子機器デバイス（例えば、リモートコントロールデバイス）、追加のアクチュエータデバイス、冷蔵庫または洗濯機／乾燥機などのいわゆる「スマート」家電、およびその他各種の相互接続されたオブジェクトが挙げられる（ただし、これらに限定されない）。
【0053】
ハードウェアおよびソフトウェアレイヤ６０は、ハードウェアコンポーネントおよびソフトウェアコンポーネントを含む。ハードウェアコンポーネントの例には、メインフレーム６１、縮小命令セットコンピュータ（ＲＩＳＣ）アーキテクチャベースのサーバ６２、サーバ６３、ブレードサーバ６４、記憶装置６５、ならびにネットワークおよびネットワークコンポーネント６６が含まれる。いくつかの実施形態において、ソフトウェアコンポーネントは、ネットワークアプリケーションサーバソフトウェア６７およびデータベースソフトウェア６８を含む。
【0054】
仮想化レイヤ７０は、抽象化レイヤを提供する。当該レイヤから、例えば、仮想サーバ７１、仮想ストレージ７２、仮想プライベートネットワークを含む仮想ネットワーク７３、仮想アプリケーションおよびオペレーティングシステム７４、ならびに仮想クライアント７５などの仮想エンティティを提供することができる。
【0055】
一例として、管理レイヤ８０は以下の機能を提供することができる。リソース準備８１は、クラウドコンピューティング環境内でタスクを実行するために利用されるコンピューティングリソースおよび他のリソースの動的な調達を可能にする。計量および価格設定８２は、クラウドコンピューティング環境内でリソースが利用される際のコスト追跡、およびこれらのリソースの消費に対する請求またはインボイス送付を可能にする。一例として、これらのリソースはアプリケーションソフトウェアのライセンスを含んでもよい。セキュリティは、データおよび他のリソースに対する保護のみならず、クラウド消費者およびタスクの識別確認を可能にする。ユーザポータル８３は、消費者およびシステム管理者にクラウドコンピューティング環境へのアクセスを提供する。サービスレベル管理８４は、要求されたサービスレベルが満たされるように、クラウドコンピューティングリソースの割り当ておよび管理を可能にする。サービス品質保証（ＳＬＡ）の計画および履行８５は、ＳＬＡに従って将来必要になると予想されるクラウドコンピューティングリソースの事前手配および調達を可能にする。
【0056】
ワークロードレイヤ９０は、クラウドコンピューティング環境の利用が可能な機能の例を提供する。このレイヤから提供可能なワークロードおよび機能の例には、マッピングおよびナビゲーション９１、ソフトウェア開発およびライフサイクル管理９２、仮想教室教育の配信９３、データ分析処理９４、取引処理９５、ならびに、本発明の例示される実施形態に関連して、コンピューティング環境（例えば、ニューラルネットワークアーキテクチャ）におけるワークフローの静的または動的パッチングを行うための種々のワークロードおよび機能９６が含まれる。さらに、コンピューティング環境におけるワークフローの静的または動的パッチングを行うためのワークロードおよび機能９６は、分析、深層学習、（さらに後述するように）ユーザおよびデバイス管理機能などの動作を含むことができる。当業者であれば理解できるように、コンピューティング環境におけるワークフローの静的または動的パッチングを行うためのワークロードおよび機能９６は、ハードウェアおよびソフトウェア６０、仮想化７０、管理８０、および他のワークロード９０（例えば、データ分析処理９４など）におけるものなど、様々な抽象化レイヤにおける他の部分と連携して、本発明の例示される実施形態の様々な目的を達成してもよい。
【0057】
前述したように、本発明は、コンピューティングシステムにおけるコンピューティング環境でのワークフローの静的または動的パッチングを実現するための新規なソリューションを提供する。１つ以上のパッチがソースワークフローから抽出されてもよい。複数のノードにおけるターゲットワークフローは、１つ以上のパッチをターゲットワークフローに適用することによって静的または動的に修正されてもよい。１つ以上のパッチの適用に応じて、複数のノードのうちの１つ以上のノードが、ターゲットワークフローがアクティブである間にターゲットワークフローにおいて追加、削除、または修正されてもよい。
【0058】
ここで、図４は、例示される実施形態の様々なメカニズムに従って、コンピューティング環境（例えば、ニューラルネットワークアーキテクチャ）におけるワークフローの静的または動的パッチングを行うためのシステム４００の機能コンポーネントの例を示すブロック図である。一態様において、図１～３で説明したコンポーネント、モジュール、サービス、アプリケーション、もしくは機能またはその組み合わせのうちの１つ以上を、図４にて使用してもよい。このことから分かるように、機能ブロックの多くは、図１～３にて前述したのと同じ説明的な意味において、機能の「モジュール」または「コンポーネント」と見なすこともできる。
【0059】
ワークフローパッチングサービス４１０が示されている。ワークフローパッチングサービス４１０は、本発明の様々な態様に従って様々な計算、データ処理および他の機能を実行する処理ユニット４２０（「プロセッサ」）を組み込んでいる。一態様において、プロセッサ４２０およびメモリ４３０は、ワークフローパッチングサービス４１０の内部もしくは外部またはその両方に存在してもよく、コンピューティングシステム／サーバ１２の内部もしくは外部またはその両方に存在してもよい。図１で説明したように、ワークフローパッチングサービス４１０は、コンピュータシステム／サーバ１２に含まれてもよいし、外部に存在してもよいし、その両方であってもよい。処理ユニット４２０は、メモリ４３０と通信していてもよい。ワークフローパッチングサービス４１０は、マネージャコンポーネント４４０（例えば、オーケストレータ）、構成コンポーネント４５０、スケジューラコンポーネント４６０、およびノードコンポーネント４７０を含んでもよい。
【0060】
一態様において、システム４００は、仮想化コンピューティングサービス（すなわち、仮想化コンピューティング、仮想化ストレージ、仮想化ネットワーキングなど）を提供してもよい。より具体的には、システム４００は、ハードウェア基板上で実行される仮想化コンピューティング、仮想化ストレージ、仮想化ネットワーキングおよび他の仮想化サービスを提供してもよい。
【0061】
一態様において、マネージャコンポーネント４４０は、ノードコンポーネント４７０に関連して、ノードまたはノードのグループにおける１つ以上のソースワークフロー（例えば、１つ以上のタスクを有するソースワークフロー）を特定してもよい。マネージャコンポーネント４４０は、ソースワークフローから１つ以上のパッチを抽出してもよい。マネージャコンポーネント４４０は、ソースワークフローから抽出した１つ以上のパッチを、複数のノードにおけるターゲットワークフローに適用してもよい。すなわち、マネージャコンポーネント４４０は、１つ以上のパッチをターゲットワークフローに動的または静的に適用してもよい。
【0062】
マネージャコンポーネント４４０は、ノードコンポーネント４７０に関連して、１つ以上のパッチを適用する１つ以上のスプライス点（splice point）を特定してもよい。スプライス点は、１つ以上のパッチ内で特定されるノードに入力を提供するターゲットワークフロー内のノードであってもよい。
【0063】
マネージャコンポーネント４４０は、構成コンポーネント４５０に関連して、１つ以上のパッチの適用に応じて、ターゲットワークフローがアクティブである間に、ターゲットワークフロー内の複数のノードのうちの１つ以上を追加、削除、または修正してもよい。
【0064】
マネージャコンポーネント４４０は、スケジューラコンポーネント４６０に関連して、ノードまたはノードのグループにおける各ワークフロータスクをスケジュールしてもよい。マネージャコンポーネント４４０は、スケジューラコンポーネント４６０に関連して、１つ以上のパッチを適用している間、複数のノードに対する追加のノードのスケジューリングを制限してもよい。
【0065】
マネージャコンポーネント４４０は、構成コンポーネント４５０もしくはノードコンポーネント４７０またはその両方に関連して、１つ以上のパッチ内で定義されたメタデータと、ターゲットワークフローにおける複数のノードのメタデータとの間の競合を特定してもよい。マネージャコンポーネント４４０は、構成コンポーネント４５０もしくはノードコンポーネント４７０またはその両方に関連して、特定した競合を解決するための１つ以上の解決アクションを生成して、１つ以上のパッチがターゲットワークフローに適合するようにしてもよい。
【0066】
マネージャコンポーネント４４０は、構成コンポーネント４５０もしくはノードコンポーネント４７０またはその両方に関連して、１つ以上のパッチに含まれる複数のノードを、ターゲットワークフローに含まれるように初期化してもよい。一態様において、ターゲットワークフローは、アクティブワークフローである。マネージャコンポーネント４４０は、スケジューラコンポーネント４６０もしくはノードコンポーネント４７０またはその両方に関連して、１つ以上のパッチに関連するターゲットワークフローにおけるアクティブなノードまたはノードのグループをスケジュールしてもよい。
【0067】
あくまでも例示として、動作時には、図４に記載したワークフローパッチングサービス４１０およびワークフローパッチングサービス４１０の１つ以上のコンポーネントを使用して、以下のステップを実行してもよい。ステップ１にて、ワークフローパッチングサービス４１０は、ソースワークフローからパッチを抽出してもよい。ステップ２にて、ワークフローパッチングサービス４１０は、（マネージャコンポーネント４４０（例えば、オーケストレータ）を介して）スケジューラコンポーネント４６０に対して、新たなノードをスケジュールしないように指示してもよい。ステップ３にて、ワークフローパッチングサービス４１０は、「削除対象」（to-delete）ノード（例えば、ワークフローから削除する必要のあるノード）および「削除対象ノード」に関連する下流ノードをターゲットワークフローから削除してもよい。ステップ４にて、ワークフローパッチングサービス４１０は、ターゲットワークフローにおける１つ以上のスプライス点（例えば、パッチで定義されたノードに入力を提供する、ターゲットワークフローのノード）を特定してもよい。ステップ５にて、ワークフローパッチングサービス４１０は、抽出したパッチ内で定義されたメタデータと、ターゲットワークフロー内のノードとの間の競合を特定してもよい（これは、競合を放置するとパッチの適用が妨げられるためである）。ステップ６にて、ワークフローパッチングサービス４１０は、競合を解決してもよい（例えば、パッチがターゲットワークフローに適合できるようにするアクションを生成する）。ステップ７にて、ワークフローパッチングサービス４１０は、パッチに存在するがアクティブワークフローに存在しないノードを初期化してもよい。ステップ８にて、ワークフローパッチングサービス４１０は、パッチと競合するターゲットワークフロー内のノードの構成を修正してもよい。ステップ９にて、ワークフローパッチングサービス４１０は、（マネージャコンポーネント４４０（例えば、オーケストレータ）を介して）スケジューラコンポーネント４６０に対して、実行可能（ready-to-execute）なノードをスケジュールするように指示してもよい。
【0068】
なお、動的パッチングの場合、上述のステップの各々が実行されてもよい。一方、静的パッチングアルゴリズムは、ステップ１、３、４、５、６、７、８（この順序、またはステップ１、３、４、５、６、７、８の任意の他の選択／配置された順序）だけを含んでもよい。また、一実施形態において、ソースワークフローおよびターゲットワークフローは、同じワークフローであってもよい。ただし、別の実施形態において、ソースワークフローとターゲットワークフローは、異なるワークフローであってもよい。
【0069】
次に、図５Ａ～５Ｅを参照して、上記のステップ１～９からワークフローの静的または動的パッチングを行うための一例としてのシステムおよび機能をさらに図示するブロックフローチャート５００、５１５、５２５、５３５、５４５を詳細に説明する。一態様において、図１～３で説明したコンポーネント、モジュール、サービス、アプリケーション、もしくは機能またはその組み合わせのうちの１つ以上を、図４にて使用してもよい。このことから分かるように、機能ブロックの多くは、図１～３にて前述したのと同じ説明的な意味において、機能の「モジュール」、「コンポーネント」、または「ノード」と見なすこともできる。
【0070】
ここで、図５Ａ、５Ｂを参照する。ワークフローチャート５００は、ソースワークフロー５００からパッチを抽出するためのステップ１を説明する一例としてのソースワークフローである。
【0071】
まず、例えば、ノード５０２Ａ～Ｇおよびノード５０４Ａ～Ｃなどの１つ以上のノードを有するソースワークフローを特定してもよい。
【0072】
第２に、ワークフローにおける抽出用のサブグラフを特定する。例えば、サブグラフは、ノード５０２Ａ～Ｇを含む。これは、コンポーネントセット「Ａ」と「Ｂ」を結ぶサブグラフに存在するノード（例えば、ノード５０２Ａ～Ｇ）を選択するものである。ここで、Ａの出力は、Ｂによって（最終的に）消費される（サブグラフは、セットＡおよびＢを含む）。また、抽出されずパッチに含まれないノードは、例えばノード５０４Ａ～Ｃのように識別してラベル付けしてもよい。
【0073】
第３に、ステップ１は、ソースワークフロー５００のサブグラフに対する、例えばノード５０２Ａなどの１つ以上の入力ノード（Ｉ）を特定することも含んでもよい。
【0074】
第４に、サブグラフの依存関係（sub-graph dependencies）を、内部依存関係（internal dependencies）５１２と外部依存関係（external dependencies）５１０（例えば、外部依存関係のメタデータ）とに分割してもよい。すなわち、内部依存関係５１２は、ソースワークフローパッケージに含まれるデータ／ファイル／バイナリへの参照であってもよい。外部依存関係５１０は、ソースワークフローパッケージの一部ではないデータ、ファイル、バイナリへの参照であってもよい（例えば、実行プラットフォームファイルシステムへの絶対パス、または実行時に提供される入力データへの参照）。
【0075】
第５に、サブグラフの１つ以上のワークフロー要素（例えば、コンポーネント構成、環境変数定義、ノード変数など）を特定してもよい。第６に、収集した情報を、ａ）サブグラフのノード定義、およびサブグラフのプロデューサノード（producer nodes）への依存関係を表すメタデータ、ｂ）サブグラフノードへの入力の定義、ならびにｃ）ソースワークフローの内部の依存関係（例えば、バイナリ、データファイル）を含むファイルのセットに変換してもよい。
【0076】
なお、新たなノードをスケジュールしないようにスケジューラコンポーネント４６０に指示するステップ２は、オンライン／動的パッチング動作用に限定されるか、またはそのためのみに使用されてもよい。そのため、新たなノードをスケジュールしないようにスケジューラコンポーネント４６０に指示するステップ２を実行するための動作は、以下の動作を含んでもよい。
【0077】
まず、ターゲットワークフローのオーケストレータ／マネージャ（例えば、図４のマネージャコンポーネント４４０）は、パッチが適用されていることをスケジューラ（例えば、図５のスケジューラコンポーネント４６０）に通知してもよい。スケジューラはこれに応じて、ａ）ノードの上流ノードへの入力依存関係（input dependencies）が満たされると、ノードを「準備完了（ready）」としてタグ付け、ラベル付け、または識別することを延期し（例えば、既存のアクティブノード、および関連タスクが何らの影響も受けない）、ｂ）パッチが完了するまで、完了ノードからのスケジューリングイベント（scheduling events）の処理を延期する。
【0078】
新たなノードについてのタスクは、その実行がスケジュールされている間に「タスクの構成」が変化しないようにするために、ノード間の依存関係が満たされていても、パッチが行われている間は、実行がスケジュールされない。また、タスクが実行用バックエンドにサブミット済みのノードも影響を受けない。スケジューラは、あたかもパッチが行われていないかのように、ノードに代わってタスクをサブミットし続けてもよい。このようにすることで、ターゲットワークフローは、パッチングプロセスによる速度低下を経験することはない。
【0079】
次に、図５Ｃは、「削除対象」ノード（例えば、ワークフローから削除する必要があるノード）および「削除対象ノード」に関連する下流ノードをターゲットワークフローから削除するためのステップ３を説明するブロックフローチャート５２５である。
【0080】
図５Ｃに示すように、例示される実施形態のメカニズムは、ターゲットワークフローに新たなノードを追加するとともに既存のノードを修正する能力だけでなく、ワークフローグラフからノードを削除する能力も実現する。例えば、「削除対象」ノードの初期リスト（例えば、ノードを削除対象として識別、タグ付け、ラベル付け）は、ステップ１で説明したサブグラフを定義するプロセスと同様に指定することができるが、ソースワークフローのノードを参照する代わりに、参照ノードはターゲットワークフローにおいて特定される。この動作中、オーケストレータ／マネージャは、ターゲットワークフローにおいて、削除対象ノードのリストと依存関係のあるすべてのノードを発見および特定し、それらを「削除対象」ノードのリストに追加する。
【0081】
スケジューラは、ターゲットワークフローのオーケストレータ／マネージャ（例えば、図４のマネージャコンポーネント４４０）によって、ノード（例えば、「削除対象」ノードのリスト）に関連するタスクがターゲットワークフローにおいて終了することを通知または報告される。そして、スケジューラは、「削除対象」ノードのリストを通常の終了と見なすように通知または報告される。言い換えると、スケジューラは、「削除対象」ノードのリストを異常終了およびエラーとは見なさない。スケジューラによって依存関係分析を行ってもよく、これにより、最初の「削除対象」ノード（例えば、ノード５０２Ｆ、５０２Ｉ、５０２Ｊ、５０２Ｋなど、ユーザ／機械学習システムがターゲットワークフローから削除することを望む／意図するノード）の出力が、特定した「削除対象」ノードリストの入力に伝播することを確認する。スケジューラは、ターゲットワークフローのオーケストレータ／マネージャ（例えば、図４のマネージャコンポーネント４４０）によって、「削除対象」ノードリストに関連するタスクをシャットダウンして終了するように通知または報告される。例えばノード５０２Ａ～Ｈなどの、結果として残るターゲットワークフロー（「結果」）を図５Ｃに示す。
【0082】
なお、「初期削除対象（initial-to-delete）」ノードは、ユーザもしくは機械学習システムまたはその両方がターゲットワークフローから削除することを望むノードの１つ以上のセットであってもよい。依存関係分析の完了後、「削除対象」ノードには、「初期削除対象」ノードと、「初期削除対象」ノードの出力を直接的／間接的に消費する他のノードとが含まれる。
【0083】
例えば、図５Ｃの「初期削除対象」ノードは、ノード５０２Ｄ（例えば、削除／除去の対象として選択されたノード）である。依存関係分析（すなわち、ノード５０２Ｄの出力をその下流ワークフローノードにわたって追跡する）を適用した結果、ノード５０２Ｆ、５０２Ｉ、５０２Ｊ、５０２Ｋがすべて、５０２Ｄに直接的／間接的に依存していることが発見される。具体的には、ノード５０２Ｆはノード５０２Ｄの出力を直接消費し、それ以外のノードは間接的に消費する（すなわち、ノード５０２Ｄとこれらのノードのいずれかを結ぶ経路は、少なくとも１つ以上のノードを含む）。
【0084】
次に、図５Ｄは、ターゲットワークフローにおける１つ以上のスプライス点（例えば、パッチ内で定義されたノードに入力を提供する、ターゲットワークフローのノード）を特定するためのステップ４を説明するブロックフローチャート５３５である。
【0085】
一態様において、１つ以上のスプライス点は、ターゲットワークフローのノードである。１つ以上のスプライス点は、例えば、機械学習になどによって自動的に特定されてもよい。スプライス点とは、パッチ内に存在するノードへの入力ノードとして機能するノードである。例えば、スプライス点の自動特定は、以下の動作のうち１つ以上を含んでもよい。まず、パッチ内に含まれる、または特定されるノードのすべての入力ノード（例えば、以下「新規ノードの入力（inputs of novel nodes）」と称し、ラベル付けする）について特徴ベクトルを生成してもよい。特徴ベクトルは、例えば、［ノードの名前空間（namespace）」、「ノード名」、「実行可能（executable）」、「引数」］などのフィールドのセットであってもよい。
【0086】
次に、ターゲットワークフローグラフのすべてのノードについて、特徴ベクトルを生成してもよい。さらなる実施形態において、パッチの１つ以上のルートノード（root nodes）から１つ以上の入力－特徴ベクトルを生成し、ターゲットにおける１つ以上の出力－特徴ベクトルと比較してもよい（例えば、ドメインをコドメインとマッチングする）。（機械学習で使用されるように）「特徴」は、例えば、任意のエンティティの特性と見なされてもよい。「特徴ベクトル」は、特徴の集合であってもよい。演算を実行して、ターゲットワークフローにおけるノードであって、選択された閾値（例えば、「特徴ベクトル一致」閾値）よりも高い類似度係数を有する、「新規ノードの入力」の特徴ベクトルと特徴ベクトルが類似するノードを識別、発見、特定してもよい。特定した一致ペア（例えば、類似の特徴ベクトルを有するノード）を記録してもよい。さらに、ユーザもしくは機械学習動作またはその両方は、ターゲットワークフローノード識別子（名前空間および名前）および「新規ノードの入力」識別子のペアを提供することによって、ターゲットワークフローのノードのうち、パッチに含まれるノードへの入力として使用するノードを指定してもよい。
【0087】
このように、図５Ｄに示すように、パッチ内のノード（例えば、ノード５０２Ｑ～Ｗ）の構成とその入力ノード（例えば、ノード５０２Ｑ）が特定される。例えば、ターゲットワークフローのノード５０２Ｅは、パッチに含まれるノード５０２Ｑと一致する特徴ベクトルを有する。ノード５０２Ｑは、ノード５０２Ｑのノード依存関係のそれぞれを含み、かつ特定される。
【0088】
なお、この時点で、パッチには、ソースワークフローから抽出された、「新規ノードの入力」と、パッチされたノードとの情報が含まれている。パッチ内のノードのいずれかがターゲットワークフローに既に存在する場合、競合（conflict）が発生する可能性がある。また、「新規ノードの入力」の定義と、ステップ４で発見した一致ノードとの間にも、競合が発生する可能性がある。一態様において、あくまでも例示として、競合とは、２つのノードのうちの一方のノードがパッチの一部であり、他方のノードがターゲットワークフローの一部である場合に、これら２つのノードの構成の差である。したがって、ステップ４に続いて、ステップ５の動作を実行して、抽出したパッチで定義されたメタデータと、ターゲットワークフローのノードとの間の競合を特定してもよい。また、ステップ５は、ターゲットワークフローのノードをトラバースし、ターゲットワークフローとパッチとの間の競合を記録してもよい。
【0089】
ステップ５に続いて、再び、ステップ６を実行して、ワークフローパッチングサービス４１０が競合を解決してもよい（例えば、パッチがターゲットワークフローに適合できるようにするアクションを生成する。この場合、このような競合を解決する複数の方法が存在する。例えば、意味的知識（semantic knowledge）および言語処理技術を用いたツール（例えば、機械学習動作ツール）を使用して、２つのノードの競合する構成を適切にマージする方法を決定してもよい。さらなる態様において、機械学習動作を使用して、競合する情報を検査し、以下のいずれかを行うことによって競合を解決する方法を決定してもよい：１）ターゲットノードの構成を受け入れる、２）ソースノードの構成を受け入れる、または、３）２つのノードを組み合わせた新たな構成を入力する。したがって、ステップ６の目的は、パッチのコンポーネント／ノードと、ターゲットワークフローの既存のノードとが、それぞれの各タスクを正常に実行できるようにすることである。
【0090】
次に、図５Ｅは、パッチには存在するがアクティブワークフローには存在しないノードを初期化するためのステップ７を説明するブロックフローチャート５４５である。静的パッチングの場合、各新たなノードをターゲットワークフローに挿入してもよい。動的パッチング動作では、パッチに含まれるが、ターゲットワークフローには存在しないノードのリストを提供する。オーケストレータ／マネージャは、自身の内部データ構造を更新し、「新規ノードの入力」を、以下を含む（ただし、これらに限定されない）ステップにて初期化してもよい：ａ）バックエンドの初期化、ｂ）ファイルシステム上のファイルの変更（例えば、パッチからの「内部依存関係」のコピー（ステップ１または詳細情報を参照））、ｃ）ターゲットワークフローのメタデータの更新、もしくは、ｄ）スケジューラのデータ構造の更新、またはその組み合わせなど。
【0091】
ステップ７に続いて、再び、ステップ８を行って、パッチと競合するターゲットワークフロー内のノードの構成を修正してもよい。ステップ８の一部として、ターゲットワークフローのオーケストレータ／マネージャは、パッチに含まれる情報と競合するノードの構成を修正してもよい。ターゲットワークフローのオーケストレータ／マネージャは、ステップ６にて行った決定を再現（replay）し、検討してもよい。オーケストレータ／マネージャは、その内部データ構造を更新し、競合するノードの各々について、以下を含む（ただし、これらに限定されない）初期化ステップを実行してもよい：ａ）バックエンドの初期化、ｂ）ファイルシステム上のファイルの変更（例えば、パッチからの「内部依存関係」のコピー（ステップ１または詳細情報を参照））、ｃ）ターゲットワークフローのメタデータの更新、もしくは、ｄ）スケジューラのデータ構造の更新、またはその組み合わせなど。このようにして、ステップ８は、パッチに符号化された情報を含むように、ターゲットワークフローの変換を完了する。
【0092】
また、スケジューラコンポーネント４６０に対して、実行可能なノードをスケジュールするように指示するステップ９は、動的パッチング動作にのみ適用可能であってもよい。ステップ９の一部として、ターゲットワークフローのオーケストレータ／マネージャは、動的パッチングが完了したことをスケジューラに通知してもよい。スケジューラは、ａ）ステップ２で延期されたスケジューリングイベントを遡及的に処理し、ｂ）動的パッチングプロセスの開始前に実行準備ができていなかったノードのスケジューリングタスクに対する禁止／制限を解除してもよい。
【0093】
次に図６は、プロセッサによってコンピューティング環境におけるワークフローのパッチングを行うための方法６００を示す図である。この方法によって、例示される実施形態の様々な態様を実施することができる。機能６００は、マシン上で命令として実行される方法（例えば、コンピュータ実装方法）として実装することができる。ここで、命令は、少なくとも１つのコンピュータ可読媒体または少なくとも１つの非一時的機械可読記憶媒体に含まれる。機能６００は、ブロック６０２から開始してもよい。
【0094】
ブロック６０４のように、ソースワークフローから抽出した１つ以上のパッチを、複数のノードにおけるターゲットワークフローに適用してもよい。ブロック６０６のように、１つ以上のパッチの適用にしたがって、ターゲットワークフローがアクティブである間に、ターゲットワークフローにおける複数のノードのうちの１つ以上を追加、（機械学習を介して、もしくはユーザ／管理者によって、またはその両方の指示によって）削除、または修正してもよい。機能６００は、ブロック６０８にて終了してもよい。
【0095】
次に、図７は、プロセッサによってコンピューティング環境におけるワークフローの静的または動的パッチングを行うためのさらなる方法７００を示す図である。機能７００は、マシン上で命令として実行される方法（例えば、コンピュータ実装方法）として実装することができる。ここで、命令は、少なくとも１つのコンピュータ可読媒体または少なくとも１つの非一時的機械可読記憶媒体に含まれる。機能７００は、ブロック７０２から開始してもよい。
【0096】
ブロック７０４のように、１つ以上のパッチをソースワークフローから抽出してもよい。ブロック７０６のように、１つ以上のパッチをターゲットワークフローに適用することによって、複数のノードにおけるターゲットワークフローを静的または動的に修正してもよい。ブロック７０８のように、１つ以上のパッチの適用にしたがって、ターゲットワークフローがアクティブである間に、複数のノードのうちの１つ以上をターゲットワークフローにおいて追加、削除、または修正してもよい。機能７００は、ブロック７１０にて終了してもよい。
【0097】
次に、図８は、プロセッサによってコンピューティング環境におけるワークフローの静的または動的パッチングを行うためのさらなる方法８００を示す図である。機能８００は、マシン上で命令として実行される方法（例えば、コンピュータ実装方法）として実装することができる。ここで、命令は、少なくとも１つのコンピュータ可読媒体または少なくとも１つの非一時的機械可読記憶媒体に含まれる。機能８００は、ブロック８０２から開始してもよい。
【0098】
ブロック８０４のように、１つ以上のパッチをソースワークフローから抽出してもよい。ブロック８０６のように、１つ以上のパッチをターゲットワークフローに適用することによって、複数のノードにおけるターゲットワークフローを静的または動的に修正してもよい。ブロック８０８のように、１つ以上のパッチの適用にしたがって、ターゲットワークフローにおける複数のノードのうちのノードの構成を修正してもよい。ブロック８１０のように、１つ以上のパッチの適用に応じて、ターゲットワークフローにおける、複数のノードのうちのノード、および依存関係を有するアクティブまたは非アクティブなノードを特定および削除してもよい。一態様において、アクティブまたは非アクティブなノード（例えば、望ましくないノード）は、ノードが本質的に非アクティブであるという理由だけでなく、機械学習やユーザの好みに基づいて削除されてもよい。機能８００は、ブロック８１２にて終了してもよい。
【0099】
一態様において、図６～８の少なくとも１つのブロックに関連して、もしくはその一部として、またはその両方として、６００、７００、もしくは８００またはその組み合わせにおける動作は、以下の各々を含んでもよい。６００、７００、もしくは８００またはその組み合わせにおける動作は、ソースワークフローから１つ以上のパッチを抽出し、１つ以上のパッチをターゲットワークフローに動的または静的に適用してもよい。
【0100】
６００、７００、もしくは８００またはその組み合わせにおける動作は、１つ以上のパッチを適用する間、複数のノードに対する追加ノードのスケジューリングを制限し、１つ以上のパッチを適用するスプライス点を特定してもよい。スプライス点とは、１つ以上のパッチ内で特定される１つ以上のノードに入力を提供する、ターゲットワークフロー内のノードであってもよい。６００、７００、もしくは８００またはその組み合わせにおける動作は、１つ以上のパッチ内で定義されたメタデータと、ターゲットワークフロー内の複数のノードのメタデータとの間の競合を特定するとともに、特定した競合を解決して１つ以上のパッチがターゲットワークフローに適合できるようにするための１つ以上の解決アクションを生成してもよい。
【0101】
６００、７００、もしくは８００またはその組み合わせにおける動作は、ターゲットワークフローグラフのすべてのノードについて特徴ベクトルを生成してもよい。さらなる実施形態において、６００、７００、もしくは８００またはその組み合わせにおける動作は、パッチの１つ以上のルートノードから１つ以上の入力－特徴ベクトルを生成し、この１つ以上の入力－特徴ベクトルを、ターゲットにおける１つ以上の出力－特徴ベクトルと比較してもよい（例えば、ドメインをコドメインにマッチングする）。
【0102】
６００、７００、もしくは８００またはその組み合わせにおける動作は、１つ以上のパッチに含まれる複数のノードのうちのノードを、ターゲットワークフロー（ここで、ターゲットワークフローはアクティブである）に含まれるように初期化するとともに、ターゲットワークフローにおいてアクティブな複数のノードのうち、１つ以上のパッチに関連するノードをスケジュールしてもよい。
【0103】
本発明は、システム、方法もしくはコンピュータプログラム製品またはそれらの組み合わせとすることができる。コンピュータプログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を記憶したコンピュータ可読記憶媒体を含んでもよい。
【0104】
コンピュータ可読記憶媒体は、命令実行デバイスによって使用される命令を保持し、記憶することができる有形のデバイスとすることができる。コンピュータ可読記憶媒体は、一例として、電子ストレージデバイス、磁気ストレージデバイス、光ストレージデバイス、電磁ストレージデバイス、半導体ストレージデバイスまたはこれらの適切な組み合わせであってもよい。コンピュータ可読記憶媒体のより具体的な一例としては、ポータブルコンピュータディスケット、ハードディスク、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ（またはフラッシュメモリ）、ＳＲＡＭ、ＣＤ－ＲＯＭ、ＤＶＤ、メモリスティック、フロッピーディスク、パンチカードまたは溝内の隆起構造などに命令を記録した機械的に符号化されたデバイス、およびこれらの適切な組み合せが挙げられる。本明細書で使用されるコンピュータ可読記憶媒体は、電波もしくは他の自由に伝播する電磁波、導波管もしくは他の伝送媒体を介して伝播する電磁波（例えば、光ファイバケーブルを通過する光パルス）、またはワイヤを介して送信される電気信号のような、一過性の信号それ自体として解釈されるべきではない。
【0105】
本明細書に記載のコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピューティングデバイス／処理デバイスへダウンロード可能である。あるいは、ネットワーク（例えばインターネット、ＬＡＮ、ＷＡＮもしくはワイヤレスネットワークまたはこれらの組み合わせ）を介して、外部コンピュータまたは外部記憶装置へダウンロード可能である。ネットワークは、銅製伝送ケーブル、光伝送ファイバ、ワイヤレス伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータもしくはエッジサーバまたはこれらの組み合わせを備えることができる。各コンピューティングデバイス／処理デバイス内のネットワークアダプタカードまたはネットワークインタフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、当該コンピュータ可読プログラム命令を、各々のコンピューティングデバイス／処理デバイスにおけるコンピュータ可読記憶媒体に記憶するために転送する。
【0106】
本発明の動作を実施するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、または、スモールトークやＣ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語や類似のプログラミング言語などの手続き型プログラミング言語を含む、１つ以上のプログラミング言語の任意の組み合わせで記述されたソースコードもしくはオブジェクトコードのいずれかとすることができる。コンピュータ可読プログラム命令は、スタンドアロン型ソフトウェアパッケージとして完全にユーザのコンピュータ上で、または部分的にユーザのコンピュータ上で実行可能である。あるいは、部分的にユーザのコンピュータ上でかつ部分的にリモートコンピュータ上で、または、完全にリモートコンピュータもしくはサーバ上で実行可能である。後者の場合、リモートコンピュータは、ＬＡＮやＷＡＮを含む任意の種類のネットワークを介してユーザのコンピュータに接続してもよいし、外部コンピュータに（例えば、インターネットサービスプロバイダを使用してインターネットを介して）接続してもよい。いくつかの実施形態において、例えばプログラマブル論理回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブル論理アレイ（ＰＬＡ）を含む電子回路は、本発明の態様を実行する目的で当該電子回路をカスタマイズするために、コンピュータ可読プログラム命令の状態情報を利用することによって、コンピュータ可読プログラム命令を実行することができる。
【0107】
本発明の態様は、本明細書において、本発明の実施形態に係る方法、装置（システム）、およびコンピュータプログラム製品のフローチャートもしくはブロック図またはその両方を参照して説明されている。フローチャートもしくはブロック図またはその両方における各ブロック、および、フローチャートもしくはブロック図またはその両方における複数のブロックの組み合わせは、コンピュータ可読プログラム命令によって実行可能である。
【0108】
これらのコンピュータ可読プログラム命令は、機械を生産するために、汎用コンピュータ、専用コンピュータ、または他のプログラマブルデータ処理装置のプロセッサに提供することができる。これにより、このようなコンピュータまたは他のプログラマブルデータ処理装置のプロセッサを介して実行されるこれらの命令が、フローチャートもしくはブロック図またはその両方における１つ以上のブロックにて特定される機能／動作を実行するための手段を創出する。これらのコンピュータ可読プログラム命令はさらに、コンピュータ、プログラマブルデータ処理装置もしくは他のデバイスまたはこれらの組み合わせに対して特定の態様で機能するよう命令可能なコンピュータ可読記憶媒体に記憶することができる。これにより、命令が記憶された当該コンピュータ可読記憶媒体は、フローチャートもしくはブロック図またはその両方における１つ以上のブロックにて特定される機能／動作の態様を実行するための命令を含む製品を構成する。
【0109】
また、コンピュータ可読プログラム命令を、コンピュータ、他のプログラマブル装置、または他のデバイスにロードし、一連の動作ステップを当該コンピュータ、他のプログラマブル装置、または他のデバイス上で実行させることにより、コンピュータ実行プロセスを生成してもよい。これにより、当該コンピュータ、他のプログラマブル装置、または他のデバイス上で実行される命令が、フローチャートもしくはブロック図またはその両方における１つ以上のブロックにて特定される機能／動作を実行する。
【0110】
図面におけるフローチャートおよびブロック図は、本発明の種々の実施形態に係るシステム、方法およびコンピュータプログラム製品の可能な実装形態のアーキテクチャ、機能性、および動作を示している。この点に関して、フローチャートまたはブロック図における各ブロックは、特定の論理機能を実行するための１つ以上の実行可能な命令を含む、命令のモジュール、セグメント、または部分を表すことができる。他の一部の実装形態において、ブロック内に示した機能は、各図に示す順序とは異なる順序で実行されてもよい。例えば、関係する機能に応じて、連続して示される２つのブロックが、実際には、略同時に実行されてもよいし、ブロックが場合により逆順で実行されてもよい。なお、ブロック図もしくはフローチャートまたはその両方における各ブロック、および、ブロック図もしくはフローチャートまたはその両方における複数のブロックの組み合わせは、特定の機能もしくは動作を行う、または専用ハードウェアとコンピュータ命令との組み合わせを実行する、専用ハードウェアベースのシステムによって実行可能である。
【0111】
本発明の種々の実施形態を例示として説明してきたが、網羅的であることや、これらの実施形態に限定することを意図したものではない。当業者には明らかなように、記載した各実施形態の範囲から逸脱することなく、多くの変更および変形が可能である。本明細書で用いられる用語は、各実施形態の原理、実際の用途、または市場で確認される技術に対する技術的な改善を最もよく説明するために、または、他の当業者が本明細書に開示する各実施形態を理解できるように選択されたものである。
【図1】
【図2】
【図3】
【図4】
【図5A】
【図5B】
【図5C】
【図5D】
【図5E】
【図6】
【図7】
【図8】
【国際調査報告】