特許 7461521 コンピュータにおいてターゲットドライバを構築及びインストールする方法

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

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

(11)【特許番号】

(24)【登録日】2024-03-26

(45)【発行日】2024-04-03

(54)【発明の名称】コンピュータにおいてターゲットドライバを構築及びインストールする方法

(51)【国際特許分類】

   G06F 8/61 20180101AFI20240327BHJP

【ＦＩ】

G06F8/61

【請求項の数】 19

(21)【出願番号】P 2023008574

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

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

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

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

ソフトウェアコンテナエレメント内に包含された実行可能なソフトウェアを実行するように構成された１つ以上のプロセッサを備えるコンピューティングデバイスであって、前記ソフトウェアが、実行されたときに、
コンピューティングデバイスのカーネルから、前記カーネル上にインストールされている少なくとも１つのアクティブドライバを示す第１のデータを受信するステップと、
前記第１のデータを、前記カーネル上にインストールされるべき少なくとも１つの所定のターゲットドライバを示す第２のデータと比較するステップと、且つ、
前記所定のターゲットドライバのうちの少なくとも１つが前記カーネル上にインストールされていないかどうかを判定するステップと、
前記カーネル上にインストールされていない、前記所定のターゲットドライバのうちの少なくとも１つの選択されたターゲットドライバが存在すると判定することに応答して、前記ソフトウェアコンテナエレメント内に、前記選択されたターゲットドライバのうちの少なくとも１つを構築するステップと、
の各ステップを遂行するコンピューティングデバイス。

【請求項18】

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

【請求項19】

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

【発明の詳細な説明】

【技術分野】

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

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

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

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

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

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

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

【図7】カーネルの必要性に従ってカーネルドライバを構築するように構成されたソフトウェアコンテナがどのように提供されるかを説明するフローチャートを示す。

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

【0063】

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

【0064】

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

【0065】

メモリは、非一時的コンピュータ可読記憶媒体である。メモリ１１４は、ＳＳＴのプロセッサ１１２によって実行可能である実行可能なソフトウェアを記憶する。各ＳＳＴはまた、サーバと通信するための通信インターフェース（図示せず）、及び接続された周辺デバイスと通信するための１つ以上の通信インターフェース（図示せず）を含み得る。図１に示されるシステムでは、スキャナ周辺デバイス１２０_１及びスケール周辺デバイス１２０_２が、第１のＳＳＴ１１０_１に接続されている。また、プリンタ周辺デバイス１２０_３及びスキャナ周辺デバイス１２０_４が、第２のＳＳＴ１１０_２に接続されている。

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

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

【要約】

【課題】コンピューティングデバイスにおいて、ターゲットカーネルドライバを構築し、次いで、カーネルの必要性に従って、これらのターゲットカーネルドライバをカーネルに提供することか可能なソフトウェアコンテナを提供する。
【解決手段】コンピューティングデバイスの１つ以上のプロセッサ上で実行可能である実行可能なソフトウェアを包含する少なくとも１つのソフトウェアコンテナエレメントによって、コンピューティングデバイスのカーネルから、カーネル上にインストールされている少なくとも１つのアクティブドライバを示す第１のデータを受信し、第１のデータを、カーネル上にインストールされるべき少なくとも１つの所定のターゲットドライバを示す第２のデータと比較し、比較に基づいて所定のターゲットドライバのうちの少なくとも１つがカーネル上にインストールされていないかどうかを判定する。
【選択図】図３

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】