特許 7596415 イメージ組み立て方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-11-29

(45)【発行日】2024-12-09

(54)【発明の名称】イメージ組み立て方法

(51)【国際特許分類】

   G06F 8/60 20180101AFI20241202BHJP

【ＦＩ】

G06F8/60

【請求項の数】 17

(21)【出願番号】P 2023012462

(22)【出願日】2023-01-31

(65)【公開番号】P2024044966

(43)【公開日】2024-04-02

【審査請求日】2023-01-31

(31)【優先権主張番号】17/949,546

(32)【優先日】2022-09-21

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】391007161

【氏名又は名称】エヌ・シー・アール・ヴォイクス・コーポレイション

(74)【代理人】

【識別番号】100098589

【弁理士】

【氏名又は名称】西山 善章

(74)【代理人】

【識別番号】100147599

【弁理士】

【氏名又は名称】丹羽 匡孝

(72)【発明者】

【氏名】シモン ウォーターマン

【審査官】福西 章人

(56)【参考文献】

【文献】欧州特許出願公開第０３９７１７４３（ＥＰ，Ａ１）

【文献】国際公開第２０２０／２３１９５２（ＷＯ，Ａ１）

【文献】米国特許出願公開第２０２２／０２９１９４６（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０２２／０２５５９６６（ＵＳ，Ａ１）

【文献】中国特許出願公開第１１２１５４６６４（ＣＮ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ８／００－８／７７

９／４４－９／４５５

(57)【特許請求の範囲】

【請求項1】

ソフトウェアコンテナ要素として実行するために実行可能なイメージファイルを組み立てるためのコンピュータ実装方法であって、
ソフトウェアコンテナ要素として実行するために、複数の事前定義されたモジュラーイメージファイルから実行可能なイメージファイルを組み立てるステップを含み、
各事前定義されたモジュラーイメージファイルが、実行可能な命令を定義する少なくとも１つの層を含み、
前記イメージファイルの組み立ての前に、実行可能なイメージファイルを実行するように構成されたコンテナエンジン要素を介して、前記ソフトウェアコンテナ要素として実行するために必要なイメージファイルを要求するステップと、
前記コンテナエンジン要素で、前記実行可能なイメージファイル内に含まれるべき各事前定義されたモジュラーイメージファイルを定義するコンテナイメージマニフェストを受信するステップを含む、方法。

【請求項2】

前記複数の事前定義されたモジュラーイメージファイルのうちの少なくとも１つの第１の事前定義されたモジュラーイメージファイル、及び前記複数の事前定義されたモジュラーイメージファイルのうちの少なくとも１つの第２の事前定義されたモジュラーイメージファイルから、前記実行可能なイメージファイルを組み立てることを更に含み、
それによって、前記第１の事前定義されたモジュラーイメージファイルのうちの少なくとも１つ又は各々が、実行可能な命令を定義する少なくとも１つの層を含み、前記実行可能な命令が、少なくとも１つの前記第２の事前定義されたモジュラーイメージファイルの少なくとも１つの層によって定義される実行可能な命令なしには、前記ソフトウェアコンテナ要素として実行することができない、請求項１に記載の方法。

【請求項3】

少なくとも１つの周辺デバイスドライバイメージファイルとして、前記少なくとも１つの第１の事前定義されたモジュラーイメージファイルを提供することと、
少なくとも１つのベースオペレーティングシステムイメージファイル及び少なくとも１つのソフトウェア依存性イメージファイルとして、前記少なくとも１つの第２の事前定義されたモジュラーイメージファイルを提供することと、を更に含む、請求項２に記載の方法。

【請求項4】

スキャナドライバイメージファイル、及び／又はプリンタドライバイメージファイル、及び／又はスケールドライバイメージファイル、及び／又はレーザスキャナドライバイメージファイルとして、前記少なくとも１つの周辺デバイスドライバイメージファイルを提供することを更に含む、請求項３に記載の方法。

【請求項5】

ドライバ層、及び／又は共通層、及び／又はユーティリティ層を含む、イメージファイルとして、前記ソフトウェア依存性イメージファイルを提供することを更に含む、請求項３又は４に記載の方法。

【請求項6】

前記実行可能なイメージファイルの実行に応答して、前記実行可能なイメージファイルによって定義された実行可能なソフトウェアを含み、かつコンピューティングデバイスの１つ以上のプロセッサ上で実行可能である、要素として、前記ソフトウェアコンテナ要素を提供することを更に含む、請求項５に記載の方法。

【請求項7】

コンピューティング環境に関係なく実行可能であるソフトウェアとして、前記実行可能なソフトウェアを提供することを更に含む、請求項６に記載の方法。

【請求項8】

前記ソフトウェアコンテナ要素を介して、隔離されたコンピューティング環境で、前記実行可能なソフトウェアを実行することを更に含む、請求項７に記載の方法。

【請求項9】

前記実行可能なイメージファイルについての前記要求を、コンテナイメージレジストリ、又はコンテナランタイム要素及び前記コンテナイメージレジストリと通信するように構成されたプロキシに送信することを更に含む、請求項８に記載の方法。

【請求項10】

前記コンテナイメージレジストリ及び／又は前記プロキシが、コンピューティングデバイス及び／又は少なくとも１つのサーバ上のローカルメモリに記憶されている、請求項９に記載の方法。

【請求項11】

前記コンテナエンジン要素及び前記コンテナイメージレジストリと通信するように構成されたプロキシから、前記コンテナイメージマニフェストを受信することを更に含む、請求項１０に記載の方法。

【請求項12】

前記コンテナイメージマニフェストの受信に応答して、前記コンテナエンジン要素を介して、前記実行可能なイメージファイルを組み立てることを更に含む、請求項１１に記載の方法。

【請求項13】

前記コンテナエンジン要素で、コンテナイメージレジストリから前記実行可能なイメージファイルを組み立てるために必要な各事前定義されたモジュラーイメージファイルを受信することと、
前記実行可能なイメージファイルを組み立てることと、を更に含む、請求項１２に記載の方法。

【請求項14】

実行可能なソフトウェアを実行するように構成された１つ以上のプロセッサを備えるコンピューティングデバイスであって、
前記実行可能なソフトウェアが、実行されたときに、ソフトウェアコンテナ要素として実行するために、複数の事前定義されたモジュラーイメージファイルから、実行可能なイメージファイルを組み立てるように構成されており、
各事前定義されたモジュラーイメージファイルが、実行可能な命令を定義する少なくとも１つの層を含み、
前記実行可能なイメージファイルの組み立ての前に、実行可能なイメージファイルを実行するように構成されたコンテナエンジン要素を介して、前記ソフトウェアコンテナ要素として実行するために必要なイメージファイルを要求し、
前記コンテナエンジン要素で、前記実行可能なイメージファイル内に含まれるべき各事前定義されたモジュラーイメージファイルを定義するコンテナイメージマニフェストを受信する、コンピューティングデバイス。

【請求項15】

前記コンピューティングデバイスが、ポイントオブセール端末又はセルフサービス端末である、請求項１４に記載のコンピューティングデバイス。

【請求項16】

ソフトウェアコンテナ要素として実行するために実行可能なイメージファイルを組み立てるためのコンピュータ実装方法であって、
実行可能なイメージファイルを実行するように構成されたコンテナエンジン要素から、実行可能なイメージファイルについての要求を受信するステップと、
前記実行可能なイメージファイルを組み立てるために使用可能な複数の事前定義されたモジュラーイメージファイルの各々がメモリ内でアクセス可能であると判定することに応答して、前記実行可能なイメージファイル内に含まれるべき各事前定義されたモジュラーイメージファイルを定義するコンテナイメージマニフェストを、前記実行可能なイメージファイルを組み立てるための前記コンテナエンジン要素に提供するステップと、を含む、コンピュータ実装方法。

【請求項17】

実行可能なソフトウェアを実行するように構成された１つ以上のプロセッサを備えるコンピューティングデバイスであって、前記実行可能なソフトウェアが、実行されたときに、
実行可能なイメージファイルを実行するように構成されたコンテナエンジン要素から、実行可能なイメージファイルについての要求を受信し、かつ
前記実行可能なイメージファイルを組み立てるために使用可能な複数の事前定義されたモジュラーイメージファイルの各々がメモリ内でアクセス可能であると判定することに応答して、前記実行可能なイメージファイル内に含まれるべき各事前定義されたモジュラーイメージファイルを定義するコンテナイメージマニフェストを、前記実行可能なイメージファイルを組み立てるための前記コンテナエンジン要素に提供するように構成されている、コンピューティングデバイス。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ソフトウェアコンテナとして実行するために実行可能なイメージファイルを組み立てるための方法及びコンピューティングデバイスに関する。

【0002】

特に、本発明は、特定のセルフサービス端末又はポイントオブセール端末のニーズに従って、実行可能なイメージファイルを動的に組み立てるための方法論に関するが、これに限定されない。ここで、実行可能なイメージファイルは、複数の事前定義されたモジュラーイメージファイルから組み立てられ、各々が、実行可能なイメージファイル全体を構成するために必要な実行可能な命令を表す特定の層を有する。

【背景技術】

【0003】

セルフサービス端末（ＳＳＴ）及び／又はポイントオブセール（ＰＯＳ）端末は、小売業界で適宜、使用されることが知られている。ＳＳＴ及びＰＯＳ端末は、通常、顧客が小売施設と取引を行うことを可能にするために使用される。任意の小売施設の各ＳＳＴ又はＰＯＳ端末を、異なる周辺デバイスに接続することができる。

【0004】

各ＳＳＴ又はＰＯＳ端末はまた、異なる基礎となるオペレーティングシステム（Ｌｉｎｕｘ、Ｗｉｎｄｏｗｓなど）及び異なるソフトウェアアプリケーションを有するなどの、異なるソフトウェアを実行し得る。これは通常、ＳＳＴ又はＰＯＳ端末が使用される小売施設、及び小売施設におけるＳＳＴ又はＰＯＳ端末の使用目的に依存する。適宜、ＳＳＴ又はＰＯＳ端末上で実行されているソフトウェアをアップグレードすることもでき、又は接続された周辺デバイスを変更することができる。

【0005】

端末間で頻繁に存在するばらつきのため、ソフトウェア開発者は、ＳＳＴ又はＰＯＳ端末上で実行する必要のあるソフトウェアを包含するソフトウェアコンテナを使用し始めている。ソフトウェアコンテナは、走るソフトウェアを隔離するので、複雑なプラットフォーム依存性を回避するのに役立つ。つまり、ソフトウェアコンテナは、端末のコンピューティング環境に関係なく、端末の１つ以上のプロセッサ上で実行することができる。

【0006】

これは、ソフトウェアコンテナがソフトウェア（アプリケーションコード及び任意のソフトウェア依存性）の全てを包含し、任意のコンピューティング環境で実行可能である必要があるためである。更に、これらのコンテナは独自の隔離されたコンピューティング環境で動作するため（ソフトウェアコンテナの外側にある他のソフトウェア／ハードウェアとのある特定の事前定義された通信経路（特定のファイル、特定のポートへのアクセスなど）は例外）、これによりまた、当該コンテナが特に安全になる。

【0007】

このように、ソフトウェアコンテナは、ＳＳＴ及びＰＯＳ端末上で使用するためのソフトウェアをパッケージング及び配信する効果的な方法である。ソフトウェア又はハードウェアのアップグレードが端末上で行われると、これらのアップグレードを構成する新しいソフトウェアコンテナが端末上で実行され得る。

【0008】

また、コンテナが事前構築され得るので、これは、あらゆる端末上での複雑な構築を回避するのに役立つ場合がある。ソフトウェアコンテナは、コンピューティングデバイス上にハイパーバイザをインストールする必要がないという点において、仮想マシンとは異なることが留意される。ソフトウェアコンテナはまた、通常、仮想マシンよりも軽量であり、かつ仮想マシンよりも速く走る。

【0009】

更に、仮想マシンはコンピュータシステム全体を仮想化するのに対し、ソフトウェアコンテナはオペレーティングシステムを仮想化する。ソフトウェアコンテナはまた、単一のオペレーティングシステムを共有するが、各仮想マシンは独自のオペレーティングシステムを有する。

【0010】

ソフトウェアコンテナを展開する場合、（ｄｏｃｋｅｒ、ＲＫＴ、ＣＲＩ－Ｏ、及びＬＸＤなどのような）コンテナエンジンが利用される。コンテナエンジンは、ユーザ要求、又は（Ｋｕｂｅｒｎｅｔｅｓ、Ｓｗａｒｍ、Ｍｅｓｏｓなどのような）コンテナオーケストレータのＡＰＩサーバからの要求を受け入れ、レジストリから（特定のイメージ形式の）イメージファイルを引き出し、コンテナマウントポイントを準備し、ソフトウェアコンテナを実行するのに必要なメタデータを準備し、かつコンテナランタイムを呼び出すことができる。

【0011】

コンテナランタイムは、コンテナエンジンの一部である。コンテナランタイム（ｒｕｎｃ、ｃｏｎｔａｉｎｅｒｄ、ｃｒｕｎ、ｒａｉｌｃａｒ、ｋａｔａｃｏｎｔａｉｎｅｒｓなどのような）は、コンテナイメージファイルを実行し、かつそれによって、ソフトウェアコンテナを作成するために、マウントポイント、及びコンテナエンジンによって提供されるメタデータを使用し、コンピューティングデバイス上で走る（ホストＯＳの）カーネルと通信する。

【0012】

複数のコンピューティングデバイスにわたって複数のコンテナを実装する場合、ソフトウェアコンテナのオーケストレータプラットフォームがよく使用される。これらのプラットフォームは、複数のコンピューティングデバイス（例えば、ＳＳＴ又はＰＯＳ端末）にわたってコンテナのワークロードをスケジュールすることができ、かつまた、標準化されたアプリケーション定義ファイル（例えば、ｋｕｂｅ ＹＡＭＬ、ｄｏｃｋｅｒ ｃｏｍｐｏｓｅなど）を提供することができる。

【0013】

Ｋｕｂｅｒｎｅｔｅｓは、コンテナオーケストレーションプラットフォームの一例である。ここで、Ｋｕｂｅｒｎｅｔｅｓコンテナオーケストレーションプラットフォームは、クラスタを管理する、Ｋｕｂｅｒｎｅｔｅｓマスタと呼ばれる制御ユニットを含む、ユニットのクラスタ、及びワークロード（コンテナ）を走らせる少なくとも１つのノード（又はワーカ）である。

【0014】

Ｋｕｂｅｒｎｅｔｅｓオーケストレータプラットフォームの１つの部分は、ｋｕｂｅｌｅｔである。ｋｕｂｅｌｅｔは、Ｋｕｂｅｒｎｅｔｅｓシステムの一部である、あらゆるワーカ上で走るエージェントである。動作中、ｋｕｂｅｌｅｔは、どのコンテナをコンピューティングデバイス上で走らせるべきかをｋｕｂｅｌｅｔに通知する（Ｋｕｂｅｒｎｅｔｅｓマスタ上のＡＰＩサーバからの）コマンドを受信する。

【0015】

Ｋｕｂｅｒｎｅｔｅｓでは、これらのコンテナは、「ポッド」内に提供される。通常、単一のポッドは、単一のコンテナを含むが、ポッド内に複数のコンテナを含むことが可能である。ｋｕｂｅｌｅｔは、コンテナエンジン内のコンテナランタイムを介してソフトウェアコンテナを実行するために、どのコンテナをコンピューティングデバイス上で走らせるべきかに関する情報を（例えば、コンテナランタイムインターフェース（ＣＲＩ）を介して）コンテナエンジンに渡す。

【0016】

コンテナランタイムが、実行可能なコンテナイメージファイルを実行すると、ソフトウェアコンテナが作成される。そのため、ソフトウェアコンテナは本質的に、関連付けられた実行可能なコンテナイメージファイルのランタイムインスタンスである。

【0017】

この意味で、実行可能なコンテナイメージファイルは、ソフトウェアコンテナ要素として少なくとも実行可能である必要があるソフトウェアの全てを有するイメージファイルである。より詳細には、コンテナイメージファイルは通常、ソフトウェアコンテナの必要性及び能力を記述する任意のメタデータに加えて、ソフトウェアコンテナを走らせるための全ての必要な要件を含むバイナリファイルである。

【0018】

コンテナイメージファイル自体は、ソフトウェアコンテナを走らせるために必要な実行可能な命令を定義するいくつかの層から構成される。例えば、コンテナイメージファイルは、ソフトウェアアプリケーションの実行可能なコードを定義するいくつかの層、ソフトウェアアプリケーションが依存する任意のソフトウェア依存性に対するコードを定義するいくつかの層、及び任意の必要な構成設定に対するコードを定義するいくつかの層を含み得る。

【0019】

コンテナイメージファイルは、多くの場合、コンテナイメージレジストリに記憶される。各コンテナイメージファイルは、コンテナイメージファイル内の層及びメタデータを定義する特定のコンテナイメージ形式で記憶される。例えば、オープンコンテナイニシアチブ（ＯＣＩ）イメージ形式は、各層のｔａｒファイル、及びイメージファイルに関連付けられたメタデータを指定するＪＳＯＮ形式のマニフェストファイルとして、イメージファイルを定義する。

【0020】

ＳＳＴ及びＰＯＳ端末上にソフトウェアコンテナを配備する場合、特定の端末のニーズに応じて、エンドユーザ（例えば、小売施設に関連するスタッフ）によってカスタマイズしたコンテナイメージがゼロから構築される場合、これにより、コンテナの構築方法に関する知識が必要以上に伝播される可能性が生じ、構築プロセス中に問題が発生すると、期待通りに機能しないコンテナイメージがもたらされるリスクが生じる。このアプローチを取ることはまた、現実世界の変化にうまく適合しないことが多く、これは、新しいコンテナイメージを構築することによってのみ適合可能である。

【0021】

したがって、事前に構築されたコンテナイメージファイルは、事前に準備することができる。任意の端末のために機能すべき事前に構築されたコンテナイメージファイルをユーザに提供するために、任意の所与の端末上で走るハードウェア／ソフトウェアから独立して、必要となる可能性があり得る全てのソフトウェアを含む、単一のコンテナイメージファイルを作成することができる。あるいは、端末上で必要とされ得る全ての可能なソフトウェアからの可能なソフトウェアのサブセットの順列を含む、各固有のイメージファイルを含む、一連の固有のコンテナイメージファイルを作成してもよい。

【0022】

しかしながら、単一のコンテナイメージファイルを作成することは、リソース（ディスク、ＲＡＭなど）の観点から最適ではないコンテナ（ひいては、走っているコンテナ）イメージを結果として生じるという問題を呈する。例えば、端末に接続可能な１０個の特定の周辺デバイスの各々に異なるコード部分が必要な場合、ソフトウェアコンテナイメージファイルには、特定の端末上で走るハードウェア／ソフトウェアから独立した、必要な全てが確実に含まれるようにするために、コードの１０個の部分を全てイメージファイルに含める必要がある。

【0023】

この結果、多くの端末（例えば、１つの周辺デバイスのみを持つ端末）に対して必要よりもはるかに大きいサイズのコンテナイメージファイルがもたらされる。このようなサイズを有することは、イメージファイルがダウンロード及びアップグレードされ得る速度、並びにコンテナを走らせる速度が、コンテナイメージファイルに特定の端末に必要なコードのみが含まれている場合よりも遅くなることをもたらし得る。現実には、端末に接続できる多数の異なる周辺デバイス（１０個超）があるため、事前に構築された単一イメージファイルのサイズは、著しく大きくなければならない場合がある。

【0024】

特定の端末上で必要なソフトウェアの各実世界の順列に対して、コンテナイメージファイルが作成される場合、これは、多くのコンテナイメージを構築、配布、及び管理する必要があり得るという問題を呈する。

【0025】

例えば、端末に接続可能な１０個の特定の周辺デバイスの各々に、異なるコード部分が必要な場合、各実世界の組み合わせに対してカスタムイメージファイルが確実に存在するようにするために、コードの１０個の部分のサブセット（例えば、イメージ１－部分１、イメージ２－部分１＋イメージ２、イメージ３－部分１＋部分３など）の順列を含む固有のイメージファイルを各々作成する必要がある。これにより、約１０００個の異なるイメージファイルがもたらされる。実際には、端末に接続することができる多数の異なる周辺デバイス（１０個超）があるため、必要となる固有のコンテナイメージの数は、１０００個をはるかに超える可能性がある。

【0026】

小売店舗のリソース制約のある「エッジ」環境では、これらのアプローチのいずれも許容できない。

【発明の概要】

【0027】

本発明の目的は、上述の問題のうちの１つ以上を少なくとも部分的に軽減することである。

【0028】

本発明のある特定の実施形態の目的は、ソフトウェアコンテナ要素として実行するために実行可能なイメージファイルを動的に組み立てることを助けることである。

【0029】

本発明のある特定の実施形態の目的は、各端末設置（端末タイプ、周辺デバイスセット、製品など）に対して特定のコンテナイメージを構築する必要を回避することを助けることである。

【0030】

本発明のある特定の実施形態の目的は、ＳＳＴ又はＰＯＳ端末の特定のニーズに従ってコンテナイメージファイルを組み立てる方法を最適化することを助けることである。

【0031】

本発明のある特定の実施形態の目的は、端末上のハードウェア又はソフトウェアのいくつかの変化に素早く適合し得るイメージファイルを組み立てる方法を提供することを助けることである。

【0032】

本発明のある特定の実施形態の目的は、複数の事前定義されたモジュラーイメージファイルを含むコンテナレジストリを提供することを助けることであり、各モジュラーイメージファイルは、ＳＳＴ又はＰＯＳ端末上で実行されるべきソフトウェアコンテナとして実行するために実行可能なイメージファイル内で必要とされ得る実行可能な命令を含む、単一の層を含む。

【0033】

本発明のある特定の実施形態の目的は、複数の事前定義されたモジュラーイメージファイルを提供することを助けることであり、各それぞれのモジュラーイメージファイルは、ＳＳＴ及び／又はＰＯＳ端末に接続可能であるそれぞれの周辺デバイスと通信するための実行可能な命令を定義する少なくとも１つの層を含む。

【0034】

本発明のある特定の実施形態の目的は、コンテナエンジンとコンテナレジストリとの間に通信的に配置されるプロキシを提供することを助けることであり、そのプロキシは、コンテナエンジンが複数の事前定義されたモジュラーイメージファイルから実行可能なイメージファイルを組み立てることを可能にする、コンテナイメージマニフェストを作成するように構成されている。

【0035】

本発明のある特定の実施形態の目的は、コンテナエンジン及びコンテナレジストリと通信するプロキシを提供することを助けることであり、そのプロキシは、コンテナ要件に従って、「オンザフライで」コンテナイメージのマニフェストを動的に作成するように構成されている。

【0036】

本発明の第１の態様によれば、ソフトウェアコンテナ要素として実行するために実行可能なイメージファイルを組み立てるためのコンピュータ実装方法であって、ソフトウェアコンテナ要素として実行するために、複数の事前定義されたモジュラーイメージファイルから、実行可能なイメージファイルを組み立てるステップを含み、各事前定義されたモジュラーイメージファイルが、実行可能な命令を定義する少なくとも１つの層を含む、コンピュータ実装方法が提供される。

【0037】

適切には、方法は、上記複数の事前定義されたモジュラーイメージファイルのうちの少なくとも１つの第１の事前定義されたモジュラーイメージファイル、及び上記複数の事前定義されたモジュラーイメージファイルのうちの少なくとも１つの第２の事前定義されたモジュラーイメージファイルから、実行可能なイメージファイルを組み立てることを更に含み、それによって、上記第１の事前定義されたモジュラーイメージファイルのうちの少なくとも１つ又は各々は、実行可能な命令を定義する少なくとも１つの層を含み、実行可能な命令は、少なくとも１つの上記第２の事前定義されたモジュラーイメージファイルの少なくとも１つの層によって定義される実行可能な命令なしには、ソフトウェアコンテナ要素として実行することができない。

【0038】

適切には、方法は、少なくとも１つの周辺デバイスドライバイメージファイルとして、少なくとも１つの第１の事前定義されたモジュラーイメージファイルを提供することと、少なくとも１つのベースオペレーティングシステムイメージファイル及び少なくとも１つのソフトウェア依存性イメージファイルとして、少なくとも１つの第２の事前定義されたモジュラーイメージファイルを提供することと、を更に含む。

【0039】

適切には、方法は、スキャナドライバイメージファイル及び／若しくはプリンタドライバイメージファイル並びに／又はスケールドライバイメージファイル及び／若しくはレーザスキャナドライバイメージファイルとして、少なくとも１つの周辺デバイスドライバイメージファイルを提供することを更に含む。

【0040】

適切には、方法は、ドライバ層及び／又は共通層及び／又はユーティリティ層を含むイメージファイルとして、ソフトウェア依存性イメージファイルを提供することを更に含む。

【0041】

適切には、方法は、実行可能なイメージファイルの実行に応答して、実行可能なイメージファイルによって定義された実行可能ソフトウェアを含み、かつコンピューティングデバイスの１つ以上のプロセッサ上で実行可能である要素として、ソフトウェアコンテナ要素を提供することを更に含む。

【0042】

適切には、方法は、コンピューティング環境に関係なく実行可能であるソフトウェアとして、実行可能なソフトウェアを提供することを更に含む。

【0043】

適切には、方法は、ソフトウェアコンテナ要素を介して、隔離されたコンピューティング環境で実行可能なソフトウェアを実行することを更に含む。

【0044】

適切には、方法は、組み立ての前に、実行可能なイメージファイルを実行するように構成されたコンテナエンジン要素を介して、ソフトウェアコンテナ要素として実行するために実行可能なイメージファイルを要求することを更に含む。

【0045】

適切には、方法は、実行可能なイメージファイルについての要求を、コンテナイメージレジストリ、又はコンテナランタイム要素及びコンテナイメージレジストリと通信するように構成されたプロキシに送信することを更に含む。

【0046】

適切には、コンテナイメージレジストリ及び／又はプロキシは、コンピューティングデバイス及び／又は少なくとも１つのサーバ上のローカルメモリに記憶されている。

【0047】

適切には、方法は、コンテナエンジン要素で、実行可能なイメージファイル内に含まれるべき各事前定義されたモジュラーイメージファイルを定義する、コンテナイメージマニフェストを受信することを更に含む。

【0048】

適切には、方法は、コンテナエンジン要素及びコンテナイメージレジストリと通信するように構成されたプロキシから、コンテナイメージマニフェストを受信することを更に含む。

【0049】

適切には、方法は、コンテナイメージマニフェストの受信に応答して、コンテナエンジン要素を介して、実行可能なイメージファイルを組み立てることを更に含む。

【0050】

適切には、方法は、コンテナエンジン要素で、コンテナイメージレジストリから実行可能なイメージファイルを組み立てるために必要な各事前定義されたモジュラーイメージファイルを受信することと、実行可能なイメージファイルを組み立てることと、を更に含む。

【0051】

本発明の第２の態様によれば、実行可能なソフトウェアを実行するように構成された１つ以上のプロセッサを備えるコンピューティングデバイスであって、実行可能なソフトウェアが、実行されたときに、ソフトウェアコンテナ要素として実行するために、複数の事前定義されたモジュラーイメージファイルから、実行可能なイメージファイルを組み立てるように構成されており、各事前定義されたモジュラーイメージファイルが、実行可能な命令を定義する少なくとも１つの層を含む、コンピューティングデバイスが提供される。

【0052】

適切には、コンピューティングデバイスは、ポイントオブセール端末又はセルフサービス端末である。

【0053】

本発明の第３の態様によれば、ソフトウェアコンテナ要素として実行するために実行可能なイメージファイルを組み立てるためのコンピュータ実装方法であって、コンピュータ実装方法が、実行可能なイメージファイルを実行するように構成されたコンテナエンジン要素から、実行可能なイメージファイルについての要求を受信するステップと、実行可能なイメージファイルを組み立てるために使用可能な複数の事前定義されたモジュラーイメージファイルの各々がメモリ内でアクセス可能であると判定することに応答して、実行可能なイメージファイル内に含まれるべき各事前定義されたモジュラーイメージファイルを定義するコンテナイメージマニフェストを、実行可能なイメージファイルを組み立てるためのコンテナエンジン要素に提供するステップと、を含む、コンピュータ実装方法が提供される。

【0054】

本発明の第４の態様によれば、実行可能なソフトウェアを実行するように構成された１つ以上のプロセッサを備えるコンピューティングデバイスであって、実行可能なソフトウェアが、実行されたときに、実行可能なイメージファイルを実行するように構成されたコンテナエンジン要素から、実行可能なイメージファイルについての要求を受信し、かつ実行可能なイメージファイルを組み立てるために使用可能な複数の事前定義されたモジュラーイメージファイルの各々がメモリ内でアクセス可能であると判定することに応答して、実行可能なイメージファイル内に含まれるべき各事前定義されたモジュラーイメージファイルを定義するコンテナイメージマニフェストを、実行可能なイメージファイルを組み立てるためのコンテナエンジン要素に提供するように構成されている、コンピューティングデバイスが提供される。

【0055】

本発明の第５の態様によれば、命令を含むコンピュータプログラムであって、命令が、コンピューティングデバイスによって実行されたときに、コンピューティングデバイスに、本発明の第１の態様又は第３の態様によって定義される方法のステップを行わせる、コンピュータプログラムが提供される。

【0056】

本発明のある特定の実施形態は、ＳＳＴ又はＰＯＳ端末上で実行されるべきソフトウェアコンテナのニーズに従って、「オンザフライで」コンテナイメージファイルを組み立てるための方法論を提供することを助ける。

【0057】

本発明のある特定の実施形態は、実行可能なイメージファイルを組み立てるために使用可能である複数の事前定義されたモジュールイメージファイルを提供することを助け、複数の事前定義されたモジュールイメージファイルの各々は、実行可能な命令を定義する単一のイメージ層を含む。

【0058】

本発明のある特定の実施形態は、ＳＳＴ又はＰＯＳ端末上で実行されるべきソフトウェアコンテナの要件に従って必要とされる実行可能な命令を定義する複数のイメージ層を有する実行可能なイメージファイルを提供することを助ける。実行可能なイメージファイルの各それぞれのイメージ層は、それぞれの事前定義されたモジュラーイメージファイル内に含まれる単一の層に対応する。

【0059】

本発明のある特定の実施形態は、コンテナエンジンが、コンテナレジストリ内に記憶された複数の事前定義されたモジュラーイメージファイルから実行可能なイメージファイルを組み立てることを可能にする、コンテナイメージマニフェストを提供することを助ける。

【0060】

本発明のある特定の実施形態は、ソフトウェアを実行するコンピューティングデバイスを提供し、それによって、実行可能なイメージファイルの組み立てをもたらすことを助ける。

【0061】

本発明のある特定の実施形態は、ソフトウェアを実行するコンピューティングデバイスを提供し、それによって、実行可能なイメージファイルの組み立てを可能にするコンテナイメージマニフェストの提供をもたらすことを助ける。

【0062】

本発明のある特定の実施形態は、特定の端末に対して固有のイメージファイル又は任意の端末上で必要とされ得る全てのソフトウェアを有するイメージファイルを有する必要性を回避する、特定のＳＳＴ又はＰＯＳ端末のソフトウェア／ハードウェア要件に従って実行可能なイメージファイルを動的に組み立てるための方法論を提供することを助ける。

【0063】

ここで、本発明の実施形態を、例としてのみ、添付図面を参照して以降で説明する。

【0064】

図面では、同様の参照番号は同様の部品を指す。

【図面の簡単な説明】

【0065】

【図1】コンピューティングシステムを示す。

【図2】Ｋｕｂｅｒｎｅｔｅｓオーケストレーションプラットフォームの制御下にあるコンピューティングシステムを示す。

【図3】いくつかのソフトウェアコンテナを実行するセルフサービス端末のためのハードウェア及びソフトウェアアーキテクチャを示す。

【図4】セルフサービス端末上で実行されるソフトウェアコンテナ要素を示す。

【図5】複数のセルフサービス端末と通信するサーバ上で実行されるソフトウェアを示す。

【図6】実行可能なイメージファイルの層を示す。

【図7】事前定義されたモジュラーイメージファイルからの実行可能なイメージファイルの組み立てを示す。

【図8】 イメージファイルの要求がどのように処理されるかを示す、コンピューティングシステムを示す。

【図9】サードパーティ周辺デバイスがセルフサービス端末に接続されている、コンピューティングシステムを示す。

【図10】サードパーティ周辺デバイスがセルフサービス端末に接続されている、別のコンピューティングシステムを示す。

【図11】実行可能なイメージファイルが、事前定義されたモジュラーイメージファイルからどのように組み立てられるかを説明する、フローチャートを示す。

【発明を実施するための形態】

【0066】

図１は、コンピューティングシステム１００を示す。コンピューティングシステム１００には、３つのセルフサービス端末（ＳＳＴ）１１０１、１１０２、１１０３がある。

【0067】

ＳＳＴは、コンピューティングデバイスの一例である。本発明のある特定の他の実施形態では、コンピューティングデバイスは、ポイントオブセール（ＰＯＳ）端末、現金自動預け払い機（ＡＴＭ）、パーソナルコンピュータ、ラップトップ、タブレットなどであってもよい。各ＳＳＴは、１つ以上のプロセッサ１１２、及び少なくとも１つのメモリ１１４を含む。メモリは、非一時的コンピュータ可読記憶媒体である。

【0068】

メモリ１１４は、ＳＳＴのプロセッサ１１２によって実行可能である実行可能なソフトウェアを記憶する。各ＳＳＴはまた、サーバと通信するための通信インターフェース（図示せず）、及び接続された周辺デバイスと通信するための１つ以上の通信インターフェース（図示せず）を含み得る。

【0069】

図１に示されるシステムでは、スキャナ周辺デバイス１２０１及びスケール周辺デバイス１２０２が、第１のＳＳＴ１１０１に接続されている。また、プリンタ周辺デバイス１２０３及びスキャナ周辺デバイス１２０４が、第２のＳＳＴ１１０２に接続されている。また、スケール周辺デバイス１２０５、プリンタ周辺デバイス１２０６、及びスキャナ周辺デバイス１２０７が、第３のＳＳＴ１１０３に接続されている。本発明のある特定の他の実施形態では、各ＳＳＴは、周辺デバイスの異なる組み合わせに接続され得ることが理解されよう。

【0070】

各周辺デバイスは、有線インターフェース１２２を介して接続されるＳＳＴと通信し得る。本発明のある特定の他の実施形態では、インターフェースは、無線、又は有線と無線との組み合わせであってもよいことが理解されよう。

【0071】

各ＳＳＴは、ネットワーク１４０を介してサーバ１３０と通信する。サーバもまた、コンピューティングデバイスの一例である。ネットワーク１４０は、有線、無線、又は有線と無線との組み合わせであってもよい。

【0072】

サーバ１３０もまた、１つ以上のプロセッサ１３２、及び少なくとも１つのメモリ１３４を含む。メモリ１３４もまた、非一時的コンピュータ可読記憶媒体である。メモリ１３４は、サーバのプロセッサによって実行可能である実行可能なソフトウェアを記憶する。ＳＳＴ及びサーバの実行可能なソフトウェアについて、以下でより詳細に説明する。

【0073】

図２は、コンピューティングシステム２００を示す。コンピューティングシステムは、Ｋｕｂｅｒｎｅｔｅｓコンテナオーケストレーションプラットフォームの制御下にある、いくつかのコンポーネントを有する。

【0074】

そのため、本システムは、Ｋｕｂｅｒｎｅｔｅｓクラスタと称され得る。Ｋｕｂｅｒｎｅｔｅｓクラスタは、Ｋｕｂｅｒｎｅｔｅｓマスタ２１５を走らせるサーバ２１０と、それぞれのＫｕｂｅｒｎｅｔｅｓワーカ２３０１、２３０２を走らせるセルフサービス端末（ＳＳＴ）２２０１、２２０２と、を含む。

【0075】

サーバ２１０は、物理サーバであっても、クラウドサーバであってもよいことが理解されよう。サーバ２１０及びＳＳＴは、ローカルエリアネットワーク又はインターネットなどの、ネットワーク２０５を経由して通信する。ネットワークは、有線及び／又は無線であってもよい。ＳＳＴ以外のデバイスをネットワークに接続して、Ｋｕｂｅｒｎｅｔｅｓワーカを走らせることができることが理解されよう。

【0076】

サーバ２１０上で走るＫｕｂｅｒｎｅｔｅｓマスタ２１５は、Ｋｕｂｅｒｎｅｔｅｓクラスタを管理するＡＰＩサーバ２１６を含む。ＡＰＩサーバ２１６は、マスタ２１５の他の内部コンポーネントから受信する情報に基づいてコマンドを発行し、かつＫｕｂｅｒｎｅｔｅｓワーカ２３０１、２３０２上で走るｋｕｂｅｃｔｌ２１２及びｋｕｂｅｌｅｔ（ＳＳＴ２ ２２０２上のｋｕｂｅｌｅｔ２３１など）などの外部コンポーネントとインターフェース接続する。

【0077】

Ｅｔｃｄ２１７は、クラスタの構成などの情報を記憶するＫｕｂｅｒｎｅｔｅｓクラスタのための配信データベースである。Ｅｔｃｄ２１７はまた、Ｋｕｂｅｒｎｅｔｅｓワーカ２３０１、２３０２の望ましい状態、及びＫｕｂｅｒｎｅｔｅｓワーカ２３０１、２３０２の実際の状態を記憶する。ある状態は、クラスタ内の各Ｋｕｂｅｒｎｅｔｅｓワーカ２３０１、２３０２上で走っている、ポッド（ＳＳＴ２ ２２０２上のポッド３ ２３５など）及びポッドのコンテナ（ポッド２３５のコンテナ２３６など）の指標であると理解され得る。

【0078】

スケジューラ２１８は、新しいポッドをＫｕｂｅｒｎｅｔｅｓワーカ上でいつ走らせるかを監視し、次いで、当該ポッドをどのＫｕｂｅｒｎｅｔｅｓワーカ上に展開するかを決定する。コントローラマネージャ２１９は、ｅｔｃｄ２１７に対して指定された望ましい状態に近づくようにＫｕｂｅｒｎｅｔｅｓワーカ２３０１、２３０２の実際の状態を移動させることを試みるコントローラプロセスを走らせる。

【0079】

マスタ２１５はまた、ｋｕｂｅｃｔｌ２１２、ＡＰＩサーバ２１６を介してＫｕｂｅｒｎｅｔｅｓクラスタと通信するためのコマンドラインツール、及びオペレータインターフェース２１１を含む。

【0080】

Ｋｕｂｅｒｎｅｔｅｓクラスタ内に位置する各Ｋｕｂｅｒｎｅｔｅｓワーカ２３０１、２３０２は、ＳＳＴ上で走る。本発明のある特定の実施形態によれば、ワーカは、ＳＳＴの仮想マシン上で走らせることができる。ワーカ２３０は、ネットワーク２０５を介して、他のワーカ２３０及びマスタ２１５と通信することができる。

【0081】

各ワーカ２３０は、ワーカ２３０の動作を管理するｋｕｂｅｌｅｔを有する。ｋｕｂｅｌｅｔ（ＳＳＴ２２０２上のｋｕｂｅｌｅｔ２３１など）は、ワーカ２３０２の他のコンポーネントにコマンドを発行し、ワーカ（ポッド２３５など）及びワーカのコンテナ（コンテナ２３６など）上で走るポッドを監視し、かつＡＰＩサーバ２１６と通信する。ｋｕｂｅｌｅｔ２３１は、展開ファイルを受信し、これらの展開ファイルに記述されたコンテナ２３６が走っており、かつ正常であることを保証する。

【0082】

ｋｕｂｅ－ｐｒｏｘｙ（ｋｕｂｅ－ｐｒｏｘｙ２３２など）は、ポッドが、同じＫｕｂｅｒｎｅｔｅｓワーカ及び異なるワーカの両方で通信することを可能にする、ネットワークプロキシである。コンテナエンジン（エンジン２３３など）は、コンテナを走らせ、かつ管理して、ｋｕｂｅｌｅｔからのコマンド、及びレジストリからのコンテナイメージを受信する。

【0083】

コンテナエンジンは、内部にランタイムが位置するＫｕｂｅｒｎｅｔｅｓワーカ内のコンテナを走らせることに関与するコンテナランタイム（コンテナランタイム２３４など）に渡されるコンテナメタデータを準備する。

【0084】

Ｋｕｂｅｒｎｅｔｅｓマスタ２１５のＡＰＩサーバ２１６によってポッドがＫｕｂｅｒｎｅｔｅｓワーカに展開された後、任意のＫｕｂｅｒｎｅｔｅｓワーカ内にポッドが存在する。ポッドは一般に単一のコンテナを含むが、ポッドは、ストレージ及びネットワークリソースを共有することになる、類似の機能を有する複数のコンテナを含み得る。

【0085】

ポッドは、ｋｕｂｅｌｅｔを介して、ワーカが利用可能な特定のリソースへのアクセスを要求するか、又はｋｕｂｅ－ｐｒｏｘｙを使用することによって、他のポッドと通信することができる。

【0086】

図３は、いくつかのソフトウェアコンテナ要素を実行するように構成されたセルフサービス端末のためのハードウェア及びソフトウェアアーキテクチャ３００を示す。

【0087】

図３では、基礎となるハードウェアは、ＳＳＴ３１０である。これは、図１又は図２に関して記述されるＳＳＴのうちの１つであってもよい。上述のように、ＳＳＴは、１つ以上のプロセッサ、及び少なくとも１つのメモリを含む。メモリは、プロセッサによって実行可能である実行可能なソフトウェアを記憶する。

【0088】

実行可能なソフトウェアには、（Ｕｎｉｘ、Ｕｂｕｎｔｕなどのような）ホストオペレーティングシステムの一部であってもよい、Ｌｉｎｕｘカーネル３２０が含まれる。本発明のある特定の他の実施形態では、他のカーネル及び他のホストオペレーティングシステム（Ｗｉｎｄｏｗｓ、Ｍａｃなど）を利用することができることが理解されよう。実行可能なソフトウェアの一部として、コンテナエンジン３３０も含まれる。

【0089】

コンテナエンジンは、ユーザ要求、又は（Ｋｕｂｅｒｎｅｔｅｓ、Ｓｗａｒｍ、Ｍｅｓｏｓなどのような）コンテナオーケストレータのＡＰＩサーバからの要求を受け入れ、レジストリから（特定のイメージ形式の）イメージファイルを引き出し、コンテナマウントポイントを準備し、ソフトウェアコンテナを実行するのに必要なメタデータを準備し、かつコンテナランタイムを呼び出すことに関与する。

【0090】

コンテナランタイム（図示せず）は、コンテナエンジンの一部である。コンテナランタイム（ｒｕｎｃ、ｃｏｎｔａｉｎｅｒｄ、ｃｒｕｎ、ｒａｉｌｃａｒ、ｋａｔａｃｏｎｔａｉｎｅｒｓなどのような）は、いくつかのコンテナイメージファイルを実行し、かつそれによって、いくつかのソフトウェアコンテナを作成するために、マウントポイント、及びコンテナエンジンによって提供されるメタデータを使用し、コンピューティングデバイス上で走っているＬｉｎｕｘカーネル３２０と通信する。

【0091】

図３に示されるソフトウェアコンテナの各々についての実行可能なイメージファイルは、本明細書に記載されるように組み立てられ得る。組み立てたら、それらは、ＳＳＴ上のメモリに記憶され得る。図３では、４つのソフトウェアコンテナ要素が示されている。第１のソフトウェアコンテナ要素３４０は、デバイスサーバコンテナと称される。

【0092】

デバイスサーバコンテナは、アプリケーションソフトウェア３４２、並びに関連付けられたバイナリ及びライブラリ３４４を含む（バイナリ及びライブラリは、ソフトウェア依存性と称され得る）。デバイスサーバコンテナ内で走るアプリケーションは、低いレベルで、ＳＳＴに接続された周辺デバイスのうちの１つ以上を制御すること、構成すること、又は別様に当該周辺デバイスにアクセスすること、並びにネットワークを横切って、ＳＳＴの他のコンポーネントに事業レベルの機能を公開することに関与する。

【0093】

例えば、デバイスサーバは、「ＵＳＢ」プロトコルを介して、スキャナ（低レベル）と通信し、スキャンされたバーコード（事業レベル）を他のコンポーネントに報告し得る。

【0094】

デバイスサーバコンテナ内のソフトウェアは、周辺デバイスパスにアクセスし、ひいては、周辺デバイスを使用するか、又は周辺デバイスと相互作用することができる。第２のソフトウェアコンテナ要素３５０は、ＩＮＩＴコンテナと称される。ＩＮＩＴコンテナは、アプリケーションソフトウェア３５２、並びに関連付けられたバイナリ及びライブラリ３５４を含む（バイナリ及びライブラリは、ソフトウェア依存性と称され得る）。

【0095】

ＩＮＩＴコンテナで走る実行されるアプリケーションは、そのポッド内で初期化されてから、メイン（ＩＮＩＴではない）コンテナを開始する。ＩＮＩＴコンテナは、Ｋｕｂｅｒｎｅｔｅｓシステムの概念であるが、最初に（すなわち、他のコンテナの前に）実行されるように構成されたコンテナもまた、他のコンテナオーケストレーションプラットフォームにおいて利用され得ることが理解されよう。

【0096】

第３のソフトウェアコンテナ要素３６０は、エンドポイントコンテナと称される。エンドポイントコンテナは、アプリケーションソフトウェア３６２、並びに関連付けられたバイナリ及びライブラリ３６４を含む（バイナリ及びライブラリは、ソフトウェア依存性と称され得る）。

【0097】

エンドポイントコンテナ内で走るアプリケーションにより、マザーボードのユニバーサル固有識別子（ＵＵＩＤ）などの、ＳＳＴに関する情報が、Ｋｕｂｅｒｎｅｔｅｓクラスタの残りの部分に対して利用可能になる。

【0098】

第４のソフトウェアコンテナ要素３７０は、デバイスプラグインコンテナと称される。デバイスプラグインコンテナは、アプリケーションソフトウェア３７２、並びに関連付けられたバイナリ及びライブラリ３７４を含む（バイナリ及びライブラリは、ソフトウェア依存性と称され得る）。デバイスプラグインコンテナ内で走るアプリケーションは、どの周辺デバイスがＳＳＴに接続されているかを知らせることに関与する。

【0099】

図３に見ることができるように、各ソフトウェアコンテナ要素は、独自のバイナリ及びライブラリ（ｂｉｎ／ｌｉｂ）を有する。しかしながら、本発明のある特定の他の実施形態によると、コンテナの任意の組み合わせは、ｂｉｎ／ｌｉｂを共有し得ることが理解されよう。

【0100】

ここで図４を参照すると、セルフサービス端末４００、及びセルフサービス端末上で実行されるように構成された（ＳＳＴの１つ以上のプロセッサ上にある）ソフトウェアコンテナ要素が示されている。

【0101】

ＳＳＴ上のソフトウェアコンテナの各々は、（イメージファイルによって定義される）実行可能なソフトウェアを包含する。実行可能なソフトウェアは、隔離されたコンピューティング環境でソフトウェアが実行されるような方法で、コンテナ内で実行される。

【0102】

ソフトウェアは、動作するためにＳＳＴ上で同様に実行される他のソフトウェアコンテナのいずれにも依存しないという意味において、隔離されている。ソフトウェアは、独自のコンピューティング環境で効果的に実行され、かつ事前定義された通信経路を介して、この環境の外側にあるハードウェア／ソフトウェアと通信する。

【0103】

ソフトウェアコンテナ内に実行可能なソフトウェアを提供することは、コンピューティング環境に関係なくソフトウェアを実行することができることを意味する。

【0104】

図４では、コンテナは、Ｋｕｂｅｒｎｅｔｅｓコンテナオーケストレーションプラットフォームを使用して管理されている。図４に示されるＳＳＴは、上記の図１～図３のいずれかを参照して説明されるＳＳＴであってもよい。

【0105】

ＳＳＴ４００は、ホストオペレーティングシステムの一部としてＬｉｎｕｘカーネル４０５を走らせる。当然のことながら、本発明のある特定の他の実施形態に従って、他のオペレーティングシステムを使用することができる。

【0106】

Ｋｕｂｅｒｎｅｔｅｓシステムを使用して、セルフサービス端末は、Ｋｕｂｅｒｎｅｔｅｓワーカ４１０と称されるソフトウェアを実行する。Ｋｕｂｅｒｎｅｔｅｓワーカは、また、ノードと称されることもある。

【0107】

第１のソフトウェアコンテナ要素４２０、第２のソフトウェアコンテナ要素４３０、第３のソフトウェアコンテナ要素４４０、及び第４のソフトウェアコンテナ要素４５０が、Ｋｕｂｅｒｎｅｔｅｓワーカ４１０内に含まれる。

【0108】

Ｋｕｂｅｒｎｅｔｅｓプラットフォームは、図２を参照して説明されるように、これらのコンテナを管理することに関与する。第１のソフトウェアコンテナ、第２のソフトウェアコンテナ、第３のソフトウェアコンテナ、及び第４のソフトウェアコンテナは、図３を参照して説明されるのと同じコンテナであってもよい。

【0109】

セルフサービス端末４００はまた、Ｋｕｂｅｒｎｅｔｅｓワーカ４１０の外部を実行する追加のソフトウェア（図示せず）を含む。Ｋｕｂｅｒｎｅｔｅｓワーカ４１０では、第１のソフトウェアコンテナ４２０及び第２のソフトウェアコンテナ４３０は、デバイスサーバポッド４２５と称される単一のポッド内で実行される。第１のソフトウェアコンテナ４２０はＩＮＩＴタイプのものであるため、デバイスサーバポッド内で実行される（すなわち、デバイスサーバコンテナの前に実行される）第１のコンテナである。

【0110】

第３のソフトウェアコンテナ４４０は、エンドポイントポッド４４５と称される単一のポッド内で実行される。

【0111】

第４のソフトウェアコンテナ４５０は、デバイスプラグインポッド４５５と称される単一のポッド内で実行される。

【0112】

これらのポッドの各々の作成は、当業者によって理解されるように、３つの異なるポッド仕様ファイル（すなわち、ｄｅｐｌｏｙｍｅｎｔ．ＹＡＭＬファイル）によって定義される。ポッドは、共有ストレージ及びネットワークリソースを備えたコンテナ、並びにポッド内でコンテナをどのように走らせるかについての仕様を提供するために、Ｋｕｂｅｒｎｅｔｅｓで使用される。

【0113】

ＳＳＴ４００の動作中、これらのポッド／コンテナの各々は、コンテナエンジン（図示せず）のコンテナランタイム（図示せず）によって実行される。これらのコンテナの各々に関連付けられたイメージファイルは、本明細書に記載されるように組み立てられてもよい。

【0114】

別の方法として、本発明のある特定の実施形態では、選択されたコンテナ（例えば、デバイスサーバコンテナ）のイメージファイルは、本明細書に記載されるように組み立てられてもよく、一方で、ＳＳＴ内の他のコンテナの他のイメージファイルは、コンテナイメージレジストリに記憶されてもよく、いかなる組み立ても必要とせずにＳＳＴで直接的に受信されてもよい。ソフトウェアコンテナの実行可能なイメージファイルを組み立てる方法論を、図１１に記載する。

【0115】

図５は、Ｋｕｂｅｒｎｅｔｅｓマスタ及びＫｕｂｅｒｎｅｔｅｓワーカを隔離して、走らせているサーバ５００を示す。

【0116】

サーバは、複数のＳＳＴ（図５には示されていない）と通信する。サーバは、１つ以上のプロセッサ（図示せず）、及び少なくとも１つのメモリ（図示せず）を有する。メモリは、ランタイム時にプロセッサによって実行される実行可能なソフトウェアを記憶する。

【0117】

実行可能なソフトウェアは、（ホストＯＳの）Ｌｉｎｕｘカーネル５１０を含む。本発明のある特定の他の実施形態では、他のオペレーティングシステムが使用され得ることが理解されよう。

【0118】

実行可能なソフトウェアはまた、Ｋｕｂｅｒｎｅｔｅｓマスタ５２０を含む。Ｋｕｂｅｒｎｅｔｅｓマスタは、図２を参照して上述したのと同様のコンポーネントを含む。

【0119】

これらは、ＡＰＩサーバ５２２、スケジューラ５２４、コントローラマネージャ５２６、及びｅｔｃｄデータベース５２８である。Ｋｕｂｅｒｎｅｔｅｓワーカ５３０もまた、サーバ上で実行される。Ｋｕｂｅｒｎｅｔｅｓワーカ５３０は、３つのポッドを含み、ポッド自体は、ソフトウェアコンテナ要素を含む。サーバ上の第１のポッドは、動的コンテナプロキシポッド５３２である。

【0120】

このポッドは、対応する動的コンテナプロキシソフトウェアコンテナを含む。動的プロキシソフトウェアコンテナは、実行可能なイメージファイルに対するコンテナエンジンからの要求を受信することと、アンテナエンジンが実行可能なイメージファイルを組み立てるために必要であろう事前定義されたモジュラーイメージファイルを定義するマニフェストを作成し、かつそれをコンテナエンジンに提供することとに関与する。

【0121】

プロキシコンテナの動作は、図９及び図１５を参照して以下でより詳細に説明される。サーバ上の第２のポッドは、上流のコンテナレジストリポッド５３４である。このポッドは、対応する上流のコンテナレジストリソフトウェアコンテナを含む。レジストリコンテナは、各事前定義されたモジュラーイメージファイルを記憶し、かつ要求に応じて、これらのイメージファイルをコンテナエンジンに提供することに関与する。

【0122】

レジストリコンテナの動作は、図８及び図１１を参照して以下でより詳細に説明される。サーバ上の第３のポッドは、事業ロジックポッド５３６である。このポッドは、対応する事業ロジックソフトウェアコンテナを含む。

【0123】

図６は、ソフトウェアコンテナとして実行するための実行可能なイメージファイル６００の概略図を示す。図６に示されるイメージファイルは、図４のデバイスサーバコンテナを提供するために実行可能である。

【0124】

実行可能なイメージファイルは、図１１に記載されるように組み立てられた。図６に見ることができるように、実行可能なイメージファイルは、ベースオペレーティングシステム層６０５、Ｊａｖａ層６１０、ドライバ層６１５、共通層６２０、ユーティリティ層６２５、スキャナ層６３０、スケール層６３５、プリンタ層６４０、及びデバイスサーバ層６４５を有する。

【0125】

図６の実行可能なイメージファイルは、各々が単一の層を有する一連のモジュラーイメージファイルから組み立てられているが、本発明のある特定の実施形態に従って、実行可能なイメージファイル中の層の任意の組み合わせを単一のモジュラーイメージファイルに組み合わせてもよいことが理解されよう。これは、例えば、ＢａｓｅＯＳ及びＪａｖａ層の場合である。

【0126】

これは、ドライバ、共通、及びユーティリティの層でも当てはまる場合がある。更に、図６では、実行可能なイメージファイルは一連の単層モジュラーイメージファイルから組み立てられているが、モジュラーイメージファイル（例えば、Ｊａｖａイメージファイル又はドライバイメージファイル）の各々は、本発明のある特定の他の実施形態では複数の層を有してもよい。

【0127】

図７は、一連の事前定義されたモジュラーイメージファイル７０５からの実行可能なイメージファイル７００の組み立てを示すことを助ける。

【0128】

図６に示されるイメージファイルは、図４のデバイスサーバコンテナを提供するために実行可能である。

【0129】

図７には、ベースオペレーティングシステム用の実行可能な命令を定義する１つの層、及びＪａｖａプログラミング言語を解釈するための実行可能な命令を定義する１つの層である、２つの層を有する第１の事前定義されたモジュラーイメージファイル７１０がある。これは、ベースＯＳイメージファイルと呼んでもよい。もちろん、本発明のある特定の他の実施形態では、ベースＯＳ層及びＪａｖａ層は、別個のモジュラーイメージファイルとして提供されてもよい。本発明のある特定の他の実施形態では、他のプログラミング言語が使用されている場合、Ｊａｖａ層は必要とされない場合があることが更に理解されよう。

【0130】

ベースＯＳ層は、ソフトウェアコンテナ（例えば、Ｕｂｕｎｔｕ）内で利用されるオペレーティングシステムを定義する。しかしながら、ベースＯＳ層は、本発明のある特定の他の実施形態で必要とされない場合がある。

【0131】

図７はまた、３つの層を有する第２の事前定義されたモジュラーイメージファイル７２０を示す。これは、ソフトウェア依存性イメージファイルと呼んでもよい。第１の層は、ドライバに対して実行可能な命令を定義する。ドライバ層は、イメージにユーザ空間ドライバをインストールすることに関与する実行可能な命令を定義する、任意選択の層である。ユーザ空間ドライバの一例は、低レベルのＵＳＢヘルパであってもよい。

【0132】

一部のイメージは、いずれのユーザ空間ドライバも必要としない場合があることが理解されよう。第２の層は、共通層である。共通層は、他の層によって共有又は使用されるフレームワークコンポーネントを包含する実行可能な命令を定義する。

【0133】

かかるフレームワークの一例は、他のコンポーネントからのログを制御及びキャプチャするために使用されるロギングフレームワークであってもよい。第３の層は、ユーティリティ層である。ユーティリティ層は、ユーザ向けユーティリティ及びツールを含む実行可能な命令を定義する、任意選択の層である。

【0134】

かかるツールの一例は、ＳＳＴ上にインストールされているデバイスのリストを閲覧し、かつ診断チェックを走らせるなどの動作により、これらのデバイスと相互作用するために使用され得る、システムメンテナンスユーティリティであってもよい。

【0135】

本発明のある特定の他の実施形態では、ドライバ、共通及びユーティリティ層の各々が、独自の事前定義されたモジュラーイメージファイル内に提供されてもよいことが理解されよう。ドライバ層及び／又は共通層及び／又はユーティリティ層は、本発明のある特定の実施形態において必要とされない場合があることが更に理解されよう。

【0136】

図７はまた、スキャナ周辺デバイスと通信するために実行可能な命令を定義する単一の層を有する第３の事前定義されたモジュラーイメージファイル７３０と、スケール周辺デバイスと通信するための実行可能な命令を定義する単一の層を有する第４の事前定義されたモジュラーイメージファイル７４０と、プリンタ周辺デバイスと通信するために実行可能な命令を定義する単一の層を有する第５の事前定義されたモジュラーイメージファイル７５０と、を示す。

【0137】

これらのイメージファイルは、周辺デバイスドライバイメージファイルと称され得る。スキャナ、スケール、及びプリンタのモジュラーイメージファイルは、特定のスキャナ、スケール、又はプリンタに関連付けられたイメージファイルであることが理解されよう。一例として、スキャナは、ＮＣＲ（本願出願人の登録商標）２３５６ハンドヘルドスキャナであってもよく、スケールは、ＮＣＲ８７８９スケールであってもよく、プリンタは、ＮＣＲ７１６９サーマルレシートプリンタであってもよい。

【0138】

本発明のある特定の他の実施形態では、他の周辺デバイス（バーコードリーダ、カメラなど）に関連付けられたモジュラーイメージファイルが必要となる場合があることも理解されよう。

【0139】

図７に示される周辺デバイスイメージファイルは、必ずしも必要ではない場合があることも理解されよう。図７では、低いレベルで、ＳＳＴに接続された周辺デバイスのうちの１つ以上を制御し、構成し、又は別様に当該周辺デバイスにアクセスし、かつネットワークを横切って、ＳＳＴの他のコンポーネントに事業レベルの機能を公開するための実行可能な命令を定義する単一のデバイスサーバ層を有する第６の事前定義されたモジュールイメージファイル７６０がまた存在する。

【0140】

図７はまた、単一の小売デバイスサーバ層を有するオプションの第７の事前定義されたモジュラーイメージファイル７７０を示す。モジュラーイメージファイル７７０は、コンテナがＰＯＳ端末上で実行されるときに、イメージファイル７６０の代わりに使用され得る。他の実行可能なイメージファイル（例えば、図４の他のコンテナ用）を組み立てるために使用可能な他の事前定義されたモジュラーイメージファイルは、組み立てられるべき特定の実行可能なイメージファイルのニーズに応じて定義され得ることが理解されよう。

【0141】

展開ファイルは、実行可能なイメージファイル用にどの層を組み立てるかを指定する１つの方法を提供する。展開ファイルは、コンテナ名で層をエンコードすることで実現され得る。例えば、名前の各要素は、含まれる層の名前であってもよい。組み立てられる層を定義する他の方法を使用してもよく、これは、例えば、ＣｏｎｆｉｇＭａｐは層を列挙し、層のリストを名前にし、その名前をイメージ名として参照することができる。

【0142】

展開ファイルは、Ｋｕｂｅｒｎｅｔｅｓマスタ又はＳＳＴ上で走るコンテナエンジンによって利用されて、図１１で論じたステップの一部を促すことができる。すなわち、コンテナエンジンは、一連の事前定義されたモジュラーイメージファイルから実行可能なイメージファイルを組み立てるために必要なステップを開始するために、この展開ファイルを処理する。展開ファイルは、Ｋｕｂｅｒｎｅｔｅｓクラスタ内のコンテナを走らせるポッドの数及び構成を指定する。

【0143】

図８は、フロントエンド８１０及びバックエンド８２０を有する、コンピューティングシステム８００を示す。フロントエンドには、ＳＳＴ８３０がある。これは、図１～図４に関して記述されるようなＳＳＴのうちの１つであってもよい。

【0144】

ＳＳＴは、３つの接続された周辺デバイス８３５を有する。ＳＳＴ８３０は、プロセッサ（図示せず）及びメモリ（図示せず）を有する。メモリは、プロセッサによって実行可能であり得る、実行可能なソフトウェアを記憶する。

【0145】

図８では、ＳＳＴは、Ｋｕｂｅｒｎｅｔｅｓフレームワーク内の第１のソフトウェアコンテナ８４０及び第２のソフトウェアコンテナ８５０を実行している。第１のソフトウェアコンテナは、図４のデバイスサーバコンテナであってもよい。第２のソフトウェアコンテナは、図４のエンドポイントコンテナであってもよい。

【0146】

また、ＳＳＴ内には、ＳＳＴのユーザインターフェースに関連付けられた実行可能ソフトウェア８６０が含まれる。これは、ウェブベースのユーザインターフェースである。しかしながら、他のブラウザが、本発明のある特定の他の実施形態で使用されてもよい。

【0147】

ＵＩは、ＭＱＴＴプロトコルを介して第１のソフトウェアコンテナ要素と通信する。ユーザがユーザインターフェースを介してＳＳＴと対話すると、コマンドは、コマンドを処理する第１のソフトウェアコンテナ要素に送信される。コマンドが処理されると、第１のソフトウェアコンテナは、サーバ及び／又は周辺デバイスと通信してもよく、及び／又は必要に応じて命令をユーザインターフェースに返してもよい。

【0148】

バックエンド８２０には、サーバペア８７０がある。本発明のある特定の他の実施形態では、単一のサーバ、又は一対のサーバよりも多いサーバが存在し得ることが理解されよう。サーバペアの各サーバは、１つ以上のプロセッサ（図示せず）と、サーバペアのプロセッサによって実行するために実行可能な命令を記憶する少なくとも１つのメモリ（図示せず）とを有する。

【0149】

サーバペアの実行可能なソフトウェアは、動的コンテナプロキシ８８０及び上流のコンテナレジストリ８９０を含む。プロキシ及びレジストリは、サーバペアの異なるサーバ上で実行されるが、本発明のある特定の他の実施形態では、同じサーバ上で実行され得ることが理解されよう。

【0150】

プロキシ及びレジストリはまた各々、Ｋｕｂｅｒｎｅｔｅｓフレームワーク内のソフトウェアコンテナとして提供される。プロキシは、ＳＳＴ上で走るコンテナエンジン（図示せず）からのコンテナイメージファイルの要求を処理する責任を負う。コンテナレジストリは、ＳＳＴのコンテナエンジンによってアクセス可能である、複数の事前定義されたモジュラーイメージファイルを記憶する責任を負う。

【0151】

モジュラーイメージファイルは、マイクロコンテナイメージファイル又は単にマイクロコンテナ（μコンテナ）と呼んでもよい。ＳＳＴの起動時に（コンテナが実行されていない場合）、コンテナエンジンは、ＳＳＴのプロセッサ上で実行され、その後、コンテナエンジンは、実行可能なイメージファイルに対する要求をプロキシ９８０に送信する。この要求は、実行可能なイメージファイルを組み立てるために必要な、事前定義されたモジュラーイメージファイルのリストを定義するイメージの名前を含む。

【0152】

これに応答して、プロキシは、レジストリと通信して、実行可能なイメージファイルに必要な事前定義されたモジュラーイメージファイルがその中に記憶されているかどうかを判定する。これは、レジストリ内に記憶されている事前定義されたモジュラーイメージファイルの各々に対してイメージマニフェストを引き出し、次に、実行可能なイメージファイルに必要な事前定義されたモジュラーイメージファイルの各々に対してイメージマニフェストが存在することを確認することによって行われる。

【0153】

プロキシが、必要なモジュラーイメージファイルが全てレジストリに記憶されていると判定した場合、プロキシは、コンテナエンジンが実行可能なイメージファイルを組み立てるために必要な、事前定義されたモジュラーイメージファイルの各々を定義する新しいイメージマニフェストを作成する。

【0154】

次に、プロキシは、このマニフェストをコンテナエンジンに送信する。このマニフェストを受信することに応答して、コンテナエンジンは、マニフェストを処理し、レジストリと通信して、実行可能なイメージファイルを組み立てるために必要な事前定義されたモジュラーイメージァイルを引き出すか、又は取得する。

【0155】

コンテナエンジンは、プロキシによって作成されたイメージマニフェストで定義されるため、どのモジュラーイメージファイルが必要かを把握する。必要なモジュラーイメージファイルが全て受信されると、コンテナエンジンは、これらを単一の実行可能なイメージファイルに組み立てる。これは、モジュラーイメージファイルが付加的であるために可能である。その後、コンテナエンジンは、ソフトウェアコンテナ要素を提供するために、実行可能なイメージファイルを実行する。

【0156】

図９は、サードパーティ周辺デバイス統合を備えたコンピューティングシステム９００を示す。図９には、フロントエンド９１０及びバックエンド９２０がある。フロントエンドには、ＳＳＴ９３０がある。

【0157】

ＳＳＴは、事前に構築された関連する事前定義されたモジュラーイメージファイルを有する、２つの接続された周辺デバイス９３５を有する。周辺デバイス９３５は、ＳＳＴ上で実行されるソフトウェアコンテナ要素９４０を提供するのと同じ企業によって提供される。

【0158】

また、ＳＳＴには、サードパーティ周辺デバイス９４５が接続されている。デバイスは、サードパーティから提供されているため、当初は事前に構築された関連する事前定義されたモジュラーイメージファイルはない。したがって、サードパーティデバイスを使用する場合、サードパーティは、関連する事前定義されたモジュラーイメージファイル（例えば、このデバイスと通信するための実行可能な命令を定義する単一の層のみ）を作成し、これをコンテナレジストリ（図示せず）に提供する。

【0159】

次に、ソフトウェアコンテナ要素９４０の実行に必要な実行可能なイメージファイルを、図１１に記載される方法論に従って、かつ図８を参照して上述したように、組み立てる。これは、図９に示すように、サードパーティデバイスは、他のモジュラーイメージファイルと同じベースＯＳを使用するモジュラーイメージファイル９４２を有する。バックエンド９２０には、サーバペア９６０がある。サーバペアは、ビジネス論理要素９７０を実行するプロセッサを含む。

【0160】

図１０は、サードパーティデバイス統合を有する別のコンピューティングシステム１０００を示す。このシステムは、上記の図９を参照して説明したものと類似している。しかしながら、コンテナレジストリ内に作成され、かつ記憶されたサードパーティ周辺デバイス用の事前定義されたモジュラーイメージファイルを、単一の組み立てられた実行可能なイメージファイルに組み込む代わりに、２つの実行可能なイメージファイルが、組み立てられる。

【0161】

１つの実行可能なイメージファイルには、サードパーティによって作成されていない周辺デバイスに関連付けられている事前定義されたモジュラーイメージファイルが含まれる。他の実行可能なイメージファイルには、サードパーティによって作成された周辺デバイスに関連付けられている事前定義されたモジュラーイメージファイルが含まれる。

【0162】

これは、図１０に示すように、サードパーティデバイスは、他のモジュラーイメージファイルと同じベースＯＳを使用するモジュラーイメージファイルを有する。これらのファイルの各々の組み立ては、図１１又は上記の図８を参照して説明したとおりである。言い換えれば、図１０は、それらを単一のコンテナに組み込むのではなく、新しいコンテナを作成するが、同じデバイスサーバ及びベースＯ／Ｓ層を、同じ方法で再利用及び組み立てることができるように、サードパーティデバイスを扱う異なる方法を表す。

【0163】

当然のことながら、周辺仮想化は、異なるＯＳ（例えば、Ｌｉｎｕｘ及びＷｉｎｄｏｗｓ）に関連付けられたドライバの統合を可能にするために使用されてもよく、その結果、Ｌｉｎｕｘを走らせているＰＯＳに接続されたデバイスは、Ｗｉｎｄｏｗｓ仮想マシン上で利用可能にされてもよく、又はその逆でもよい。

【0164】

図１１は、ＳＳＴ上で実行可能なソフトウェアコンテナ要素として実行するために実行可能なイメージファイルの組み立て中に行われる、ある特定のステップのフローチャート１１００を示す。

【0165】

ＳＳＴは、図１～図１３に示されるＳＳＴのいずれかであってもよい。ＳＳＴを最初に導入する際、ＳＳＴにどのソフトウェアをインストールするか、またどの周辺デバイスをＳＳＴに接続するかが分かっている。

【0166】

この情報を使用して、第１のステップＳ１１０５は、起動時にＳＳＴ上で実行されるべき各ソフトウェアコンテナに対する展開ファイルを作成する。展開ファイルは、特に、イメージファイルの名前を指定する。イメージファイルは、実行可能なイメージファイルに必要なイメージファイルのリストを定義するために命名される。

【0167】

上述したように、ＣｏｎｆｉｇＭａｐを使用して、イメージファイルのリストを定義することもできる。展開ファイルが作成されると、展開ファイルは、ＳＳＴと通信するサーバ上で走っているＫｕｂｅｒｎｅｔｅｓマスタのＡＰＩサーバにアップロードされる。Ｋｕｂｅｒｎｅｔｅｓマスタは、図２又は図５に関して示されるのと同じマスタであってもよい。ＡＰＩサーバは、展開ファイルを受信し、かつ展開ファイルを、Ｋｕｂｅｒｎｅｔｅｓマスタのｅｔｃｄデータベースに記憶する。

【0168】

次のステップＳ１１１０は、ＳＳＴの電源を入れることである。これは、例えば、端末がその日に初めて使用されるとき、例えば、店舗が閉鎖された期間の後などに発生する。また、端末が再起動するときなどの、他のときにも起こり得る。次いで、ホストＯＳ及びＫｕｂｅｒｎｅｔｅｓワーカ構成を含む、ＳＳＴ上のソフトウェアが、ＳＳＴのメモリからロードされ、ＳＳＴのプロセッサによって実行される。その後、次のステップＳ１１１５は、Ｋｕｂｅｒｎｅｔｅｓマスタのコントローラマネージャによって、ｅｔｃｄデータベースに従って指定されるようなＳＳＴに関連付けられたＫｕｂｅｒｎｅｔｅｓワーカ上で実行されるべきポッドと、実際にＳＳＴ上で実行されるポッドとの間の差異を検出することを伴う。

【0169】

ポッドによって必要とされるリソースがＫｕｂｅｒｎｅｔｅｓワーカで利用可能であることを判定するために、Ｋｕｂｅｒｎｅｔｅｓワーカで利用可能なリソースもチェックされることになる。ＳＳＴ上で実行する必要があるポッドがないこと、及び好適なリソースが利用可能であることを検出することに応答して、ＫｕｂｅｒｎｅｔｅｓマスタのＡＰＩサーバは、この不一致を解決するためにＳＳＴ上のｋｕｂｅｌｅｔに情報を送信する。

【0170】

この情報は、ＳＳＴ上で実行される各ポッドのための展開ファイルを含む。Ｋｕｂｅｒｎｅｔｅｓオーケストレーションプラットフォームを使用しない、本発明のある特定の他の実施形態によれば、コンテナは、ポッド内で走らせる必要なしに実行され得る（これは、Ｋｕｂｅｒｎｅｔｅｓシステムの特定の特徴である）ことが理解されよう。

【0171】

次のステップＳ１１２０は、ｋｕｂｅｌｅｔによって、ＡＰＩサーバからの情報を受信し、かつ展開ファイルをコンテナエンジン要素に渡すことを伴う。

【0172】

次のステップＳ１１２５は、コンテナエンジンによって、展開ファイルを読むことと、コンテナエンジンとコンテナレジストリ（複数の事前定義されたモジュラーイメージファイルを記憶する）との間に通信的に配置される動的コンテナプロキシに要求を送信することによって、実行可能なイメージファイルを要求することとを伴う。

【0173】

要求には、実行可能なイメージファイルに必要なイメージファイルのリストを定義する、（展開ファイルからの）イメージファイルの名前が含まれる。プロキシ及びレジストリは、サーバ上のメモリに、かつ／又はＳＳＴのローカルメモリ上に記憶されてもよい。次のステップＳ１１３０は、動的コンテナプロキシによって、イメージファイルの名前を解析して、実行可能なイメージファイルに必要な事前定義されたモジュラーイメージファイルをチェックすることを伴う。

【0174】

これは、イメージファイルの名前は事実上、必要な事前定義されたモジュラーイメージファイルの名前のエンコードされたリストであるため、達成され得る。

【0175】

次に、プロキシは、実行可能なイメージファイルに必要な全ての指定された事前定義されたモジュラーイメージファイルがメモリ内で利用可能であることをチェックするステップ（図示せず）を実施する。プロキシは、上流のコンテナレジストリから、各事前定義されたモジュラーイメージファイルに関連付けられたマニフェストを受信し、かつコンテナエンジンからプロキシに送信されたイメージファイルの名前で表される各事前定義されたモジュラーイメージファイルに対応するマニフェストが存在するかどうかを判定することによって、このチェックステップを実施する。

【0176】

プロキシが、プロキシに送信された名前で表される各イメージファイルに対してマニフェストが存在すると判定し、ひいては、全ての必要な事前定義されたモジュラーイメージファイルがレジストリ内に存在すると判定する場合、次のステップＳ１１３５は、プロキシによって、実行可能なイメージファイル内に含まれる各事前定義されたモジュラーイメージファイルを定義する、
コンテナイメージマニフェストを動的に作成することを伴う。マニフェストによって定義されるこれらのモジュラーイメージファイルは、実行可能なイメージファイルに必要な展開ファイルを指定するものである。

【0177】

次に、次のステップＳ１１４０は、プロキシによって、イメージマニフェストがコンテナエンジンによって受信されるように、イメージマニフェストを送信することを伴う。当然のことながら、プロキシによって実施されるステップは、本発明のある特定の他の実施形態によるＳＳＴ又はコンテナレジストリによって実施されてもよい。

【0178】

イメージマニフェストがコンテナエンジンによって受信されると、次のステップＳ１１４５は、実行可能なイメージファイルを組み立てるために必要な事前定義されたモジュラーイメージファイルの各々を、コンテナエンジンによって受信することを伴う。

【0179】

これらのモジュラーイメージファイルは、コンテナレジストリから受信される。受信される事前定義されたモジュラーイメージファイルは、コンテナエンジンによって受信されるイメージマニフェスト内に定義されたものである。モジュラーイメージファイルの受信はまた、イメージファイルの「引き出し」と呼んでもよい。

【0180】

モジュラーイメージファイルがコンテナエンジンによって受信されると、次のステップＳ１１５０は、受信した事前定義されたモジュラーイメージファイルの各々を使用して、実行可能なイメージファイルを組み立てることを伴う。組み立てられた実行可能なイメージファイルは、ソフトウェアコンテナ要素として実行され得る。したがって、イメージファイルは、ソフトウェアコンテナとして実行される能力を有するという意味で実行可能である。

【0181】

これは、独自のソフトウェアコンテナとして実行できない（すなわち、他の事前定義されたモジュラーイメージファイルと組み立てられることのない）、多くの事前定義されたモジュラーイメージファイルとは対照的である。次のステップ（図示せず）は、コンテナエンジンによって実行可能なイメージファイルを実行して、実行可能なイメージファイルのインスタンスをソフトウェアコンテナ要素として提供することを伴う。

【0182】

したがって、ソフトウェアコンテナ要素には、ＳＳＴのプロセッサ（又は複数のプロセッサ）上で実行され得る、実行可能なソフトウェアが含まれる。当然のことながら、コンテナエンジンによって実施される上述のステップは、本発明のある特定の実施形態では、コンテナエンジンのコンテナランタイムによって特異的に実施されてもよい。

【0183】

別のステップ（図示せず）は、実行可能なイメージファイルをＳＳＴ及び／又はコンテナレジストリのメモリに記憶することを伴う。次に、実行可能なイメージファイルは、ＳＳＴが再起動されるたびに上述のように組み立てる必要はない。しかしながら、イメージファイルの記憶にメモリを使用しないことが望ましい場合、実行可能なイメージファイルは、ＳＳＴが開始されるたびに上述のように組み立てられてもよい。

【0184】

上述の本発明のある特定の実施形態は、小売環境用のデバイスサーバイメージファイルの組み立てを記述するが、本発明のある特定の他の実施形態は、非小売特定のイメージファイルを組み立てるために使用され得ることが理解されよう。

【0185】

本発明は、プラグインを層として作成し、かつプラグインの異なる組み合わせを含む、走らせることができるコンテナに動的に組み立てることができる、「プラグインアーキテクチャ」を有する任意のソフトウェアに使用され得る。

【0186】

本明細書の記述及び特許請求の範囲全体を通して、「備える（ｃｏｍｐｒｉｓｅ）」及び「包含する（ｃｏｎｔａｉｎ）」という言い回し及びこれらの変形例は、「を含むが、これらに限定されない」ことを意味し、他の部分、添加物、コンポーネント、整数、又はステップを除外する（及び除外しない）ことを意図するものではない。

【0187】

本明細書の記述及び特許請求の範囲全体を通して、文脈上別段の解釈が要求されない限り、単数形は複数形を包含する。特に、不定冠詞が使用される場合、文脈上別段の要求がない限り、本明細書は、複数及び単数を企図するものとして理解されるべきである。

【0188】

好ましい実施形態及びこれらの様々な態様を参照して、本開示を具体的に示し、説明してきたが、当業者は、本開示の趣旨及び範囲から逸脱することなく、様々な変更及び修正がなされ得ることを理解されよう。添付の特許請求の範囲は、本明細書に記載される実施形態、上述の代替案、及びこれら全ての等価物を含むものとして解釈されることが意図される。

【0189】

本発明の特定の態様、実施形態、又は実施例と併せて記載される特徴、整数、特性、又は群は、これらとの互換性がない場合を除き、本明細書に記載される任意の他の態様、実施形態、又は実施例に適用可能であると理解されるべきである。本明細書（任意の添付の特許請求の範囲、要約、及び図面を含む）に開示される全ての特徴、並びに／又はそのように開示される任意の方法若しくはプロセスの全てのステップは、特徴及び／又はステップのうちの少なくともいくつかが相互に排他的である組み合わせを除いて、任意の組み合わせで組み合わせられてもよい。

【0190】

本発明は、任意の前述の実施形態のいかなる詳細にも限定されない。本発明は、本明細書（任意の添付の特許請求の範囲、要約、及び図面を含む）に開示される特徴の任意の新しい１つ、又は新しい組み合わせ、あるいはそのように開示される任意の方法又はプロセスのステップの任意の新しい１つ、若しくは任意の新しい組み合わせに及ぶ。

【0191】

また、本出願に関連して本明細書と同時に、又は本明細書の前に出願され、かつ本明細書に関して一般に閲覧される全ての論文及び文献に向けられ、かかる全ての論文及び文献の内容は、参照により本明細書に組み込まれる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】