特開 2024-44966 画像組み立て

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024044966

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

(54)【発明の名称】画像組み立て

(51)【国際特許分類】

   G06F 8/61 20180101AFI20240326BHJP

【ＦＩ】

G06F8/61

【審査請求】有

【請求項の数】20

【出願形態】ＯＬ

(21)【出願番号】P 2023012462

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

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

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

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

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．Ｌｉｎｕｘ

２．ＷＩＮＤＯＷＳ

３．ＵＮＩＸ

４．ＪＡＶＡ

５．ｄｏｃｋｅｒ

６．Ｋｕｂｅｒｎｅｔｅｓ

７．Ｓｗａｒｍ

８．Ｍｅｓｏｓ

９．ｒｕｎｃ

１０．Ｕｂｕｎｔｕ

(71)【出願人】

【識別番号】391007161

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

【氏名又は名称原語表記】ＮＣＲ ＣＯＲＰＯＲＡＴＩＯＮ

(74)【代理人】

【識別番号】100098589

【弁理士】

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

(74)【代理人】

【識別番号】100147599

【弁理士】

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

(72)【発明者】

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

【テーマコード（参考）】

5B376

【Ｆターム（参考）】

5B376AA07

5B376AD27

5B376AE04

5B376AE12

5B376FA01

5B376FA04

(57)【要約】

【課題】異なるオペレーティングシステム（Ｌｉｎｕｘ、Ｗｉｎｄｏｗｓなど）及び異なるソフトウェアアプリケーションを有するＳＳＴ（セルフサービス端末）やＰＯＳ端末でにおいても、ＳＳＴ又はＰＯＳ端末上で実行されているソフトウェアをアップグレード可能としたり、接続された周辺デバイスを変更することを可能とする。
【解決手段】ソフトウェアコンテナ要素として実行するために実行可能な画像ファイルを組み立てるためのコンピュータ実装方法であって、ソフトウェアコンテナ要素として実行するために、複数の事前定義されたモジュラー画像ファイルから実行可能な画像ファイルを組み立てるステップを含み、各事前定義されたモジュラー画像ファイルが、実行可能な命令を定義する少なくとも１つの層を含む。
【選択図】図１

【特許請求の範囲】

【請求項1】

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

【請求項2】

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

【請求項3】

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

【請求項4】

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

【請求項5】

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

【請求項6】

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

【請求項7】

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

【請求項8】

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

【請求項9】

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

【請求項10】

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

【請求項11】

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

【請求項12】

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

【請求項13】

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

【請求項14】

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

【請求項15】

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

【請求項16】

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

【請求項17】

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

【請求項18】

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

【請求項19】

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

【請求項20】

命令を含むコンピュータプログラムであって、前記命令が、コンピューティングデバイスによって実行されたときに、前記コンピューティングデバイスに、請求項１、１６、１８又は１９において定義される方法のステップを行わせる、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【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】