IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

<>
  • -周辺デバイス通信 図1
  • -周辺デバイス通信 図2
  • -周辺デバイス通信 図3
  • -周辺デバイス通信 図4
  • -周辺デバイス通信 図5
  • -周辺デバイス通信 図6
  • -周辺デバイス通信 図7
  • -周辺デバイス通信 図8
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024044967
(43)【公開日】2024-04-02
(54)【発明の名称】周辺デバイス通信
(51)【国際特許分類】
   G06F 8/60 20180101AFI20240326BHJP
【FI】
G06F8/60
【審査請求】有
【請求項の数】20
【出願形態】OL
(21)【出願番号】P 2023012464
(22)【出願日】2023-01-31
(31)【優先権主張番号】17/949,556
(32)【優先日】2022-09-21
(33)【優先権主張国・地域又は機関】US
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.Linux
2.WINDOWS
3.UNIX
4.JAVA
5.UBUNTU
6.KUBERNETES
7.SWARM
8.MESOS
9.DOCKER
(71)【出願人】
【識別番号】391007161
【氏名又は名称】エヌ・シー・アール・コーポレイション
【氏名又は名称原語表記】NCR CORPORATION
(74)【代理人】
【識別番号】100098589
【弁理士】
【氏名又は名称】西山 善章
(74)【代理人】
【識別番号】100147599
【弁理士】
【氏名又は名称】丹羽 匡孝
(72)【発明者】
【氏名】シモン ウォーターマン
【テーマコード(参考)】
5B376
【Fターム(参考)】
5B376AA07
5B376AA25
5B376AB06
(57)【要約】      (修正有)
【課題】周辺デバイス接続データによりソフトウェアコンテナ要素が複数の所定の各周辺デバイスにアクセスし、かつ、通信する方法、デバイス及びプログラムを提供する。
【解決手段】方法は、コンピューティングデバイスの1つ以上のプロセッサ上で実行可能である第1の実行可能なソフトウェアを含むモジュールから、前記コンピューティングデバイスに接続可能なクラスの周辺デバイスを示す第1のデータを受信するステップであって、各クラスが、複数の所定の周辺デバイスと関連付けられるステップと、前記1つ以上のプロセッサ上で実行可能である第2の実行可能なソフトウェアを包含するソフトウェアコンテナ要素を提供するステップと、を含む。ソフトウェアコンテナ要素は、周辺デバイス接続データと関連付けられ、周辺デバイス接続データにより、各クラスと関連付けられた複数の所定の各周辺デバイスにアクセス、かつ、通信する。
【選択図】図2
【特許請求の範囲】
【請求項1】
周辺デバイス接続データと関連付けられたソフトウェアコンテナ要素を提供するためのコンピュータ実装方法であって、前記周辺デバイス接続データにより、前記ソフトウェアコンテナ要素が複数の所定の周辺デバイスの各周辺デバイスにアクセスし、かつ前記各周辺デバイスと通信することを可能にし、前記方法が、
コンピューティングデバイスの1つ以上のプロセッサ上で実行可能である第1の実行可能なソフトウェアを含むモジュールから、前記コンピューティングデバイスに接続可能な少なくとも1つのクラスの周辺デバイスを示す第1のデータを受信するステップであって、それによって、各クラスが、複数の所定の周辺デバイスと関連付けられる、受信するステップと、
前記コンピューティングデバイスの前記1つ以上のプロセッサ上で実行可能である第2の実行可能なソフトウェアを包含するソフトウェアコンテナ要素を提供するステップであって、それによって、前記ソフトウェアコンテナ要素が、周辺デバイス接続データと関連付けられ、前記周辺デバイス接続データにより、前記ソフトウェアコンテナ要素が、各クラスと関連付けられた前記複数の所定の周辺デバイスの各周辺デバイスにアクセスし、かつ前記各周辺デバイスと通信することを可能にする、提供するステップと、を含む、方法。
【請求項2】
前記コンピューティングデバイスに接続可能な単一のクラスの周辺デバイスを示すデータとして前記第1のデータを受信することであって、それによって、前記単一のクラスが、セルフサービス端末又はポイントオブセール端末に接続可能な複数の所定の周辺デバイスと関連付けられる、請求項1に記載の方法。
【請求項3】
新しい周辺デバイスが前記コンピューティングデバイスに接続されること、又は周辺デバイスが前記コンピューティングデバイスに対して切断及び再接続されることに応答して、前記ソフトウェアコンテナ要素によって、前記新しい又は再接続された周辺デバイスが前記コンピューティングデバイスに接続されていると決定することを更に含む、請求項1又は2に記載の方法。
【請求項4】
各クラスと関連付けられた前記複数の所定の周辺デバイスを示す第2のデータを、前記コンピューティングデバイスによってアクセス可能なメモリに記憶することを更に含む、請求項3に記載の方法。
【請求項5】
前記第1のデータを受信する前に、どの周辺デバイスが前記コンピューティングデバイスに接続されているかを問い合わせるクエリを前記モジュールに送信することを更に含む、請求項4に記載の方法。
【請求項6】
前記コンピューティングデバイス上のソフトウェアコンテナ要素を管理する責任を有するソフトウェアアプリケーションにおいて前記第1のデータを受信することを更に含む、請求項5に記載の方法。
【請求項7】
接続された周辺デバイスと通信するように構成されたモジュールとして、前記モジュールを提供することを更に含む、請求項6に記載の方法。
【請求項8】
前記第1の実行可能なソフトウェアを包含するソフトウェアコンテナ要素として、前記モジュールを提供することを更に備え、任意選択的に、前記モジュールが、デバイスプラグインモジュールである、請求項7に記載の方法。
【請求項9】
前記第1のデータを受信することに応答して、前記ソフトウェアコンテナ要素への割り当てのために、各クラスと関連付けられた前記複数の所定の周辺デバイスの各々を準備するように前記モジュールに指令する少なくとも1つのコマンドを前記モジュールに送信することを更に含む、請求項8に記載の方法。
【請求項10】
前記モジュールから、各クラスと関連付けられた前記複数の所定の周辺デバイスの各々についての少なくともそれぞれの周辺デバイス経路を示す第3のデータを受信することを更に含む、請求項9に記載の方法。
【請求項11】
各クラスと関連付けられた前記複数の所定の周辺デバイスの各々についての少なくともそれぞれの周辺デバイス経路を表すデータとして、前記周辺デバイス接続データを提供することを更に含む、請求項10に記載の方法。
【請求項12】
前記ソフトウェアコンテナ要素と関連付けられた制御グループに前記周辺デバイス接続データを記憶することを更に含む、請求項11に記載の方法。
【請求項13】
第2の実行可能な命令の実行時に、前記ソフトウェアコンテナ要素によって、各クラスと関連付けられた前記複数の所定の周辺デバイスのうちのどの周辺デバイスが前記コンピューティングデバイスに接続されているかを決定することを更に含む、請求項12に記載の方法。
【請求項14】
決定することに応答して、前記ソフトウェアコンテナ要素によって、前記コンピューティングデバイスに接続された各周辺デバイスを初期化することを更に含む、請求項13に記載の方法。
【請求項15】
初期化することに応答して、前記ソフトウェアコンテナ要素によって、前記接続された周辺デバイスのうちの少なくとも1つに1つ以上のコマンドを送信することを更に含む、請求項14に記載の方法。
【請求項16】
コンピューティング環境に関係なく実行可能であるソフトウェアとして、前記第1の実行可能なソフトウェア及び前記第2の実行可能なソフトウェアを提供することを更に含む、請求項15に記載の方法。
【請求項17】
前記モジュール及び前記ソフトウェアコンテナ要素をそれぞれ介して、隔離されたコンピューティング環境で前記第1の実行可能なソフトウェア及び前記第2の実行可能なソフトウェアを実行することを更に含む、請求項16に記載の方法。
【請求項18】
コンピューティングデバイスであって、前記コンピューティングデバイス上のソフトウェアコンテナ要素を管理する責任を有するソフトウェアアプリケーションを実行するように構成された1つ以上のプロセッサを備え、前記ソフトウェアアプリケーションが、実行されたときに、
コンピューティングデバイスの1つ以上のプロセッサ上で実行可能である第1の実行可能なソフトウェアを含むモジュールから、前記コンピューティングデバイスに接続可能な少なくとも1つのクラスの周辺デバイスを示す第1のデータを受信することであって、それによって、各クラスが、複数の所定の周辺デバイスと関連付けられる、受信することと、
前記コンピューティングデバイスの前記1つ以上のプロセッサ上で実行可能である第2の実行可能なソフトウェアを包含するソフトウェアコンテナ要素を提供することであって、それによって、前記ソフトウェアコンテナ要素が、周辺デバイス接続データと関連付けられ、前記周辺デバイス接続データにより、前記ソフトウェアコンテナ要素が、各クラスと関連付けられた前記複数の所定の周辺デバイスの各周辺デバイスにアクセスし、かつ前記各周辺デバイスと通信することを可能にする、提供することと、を行うように構成されている、コンピューティングデバイス。
【請求項19】
前記コンピューティングデバイスが、ポイントオブセール端末又はセルフサービス端末である、請求項18に記載のコンピューティングデバイス。
【請求項20】
命令を含むコンピュータプログラムであって、前記命令が、コンピューティングデバイスによって実行されたときに、前記コンピューティングデバイスに、請求項1、18又は19において定義される方法のステップを行わせる、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、コンテナ要素が後で実行されるか、又は接続されるときに所定の周辺デバイスが接続されているかどうかに関係なく、特定のクラスと関連付けられた周辺デバイスの所定のセットの各周辺デバイスへのアクセスを有するように構成されている、
ソフトウェアコンテナ要素を提供するための方法及びコンピューティングデバイスに関する。特に、しかし排他的ではないが、本発明は、デバイスプラグインソフトウェアコンテナが、そのリソースを、セルフサービス端末又はポイントオブセール端末に接続可能な周辺デバイスのクラスとしてアドバタイズする方法論に関する。
【0002】
このクラスは、周辺デバイスの所定のセットと関連付けられている。次いで、ソフトウェアコンテナを、そのクラスの各周辺デバイスに対するデバイス経路を示すソフトウェアコンテナの周辺デバイス接続データと関連付けることによって、そのクラス内の全ての周辺デバイスに対するアクセスを有する端末上に提供することができる。
【背景技術】
【0003】
セルフサービス端末(SST)及び/又はポイントオブセール(POS)端末は、小売業界で適宜、使用されることが知られている。SST及びPOS端末は、通常、顧客が小売施設と取引を行うことを可能にするために使用される。任意の小売施設の各SST又はPOS端末を、異なる周辺デバイスに接続することができる。
【0004】
各SST又はPOS端末はまた、異なる基礎となるオペレーティングシステム(Linux、Windowsなど)及び異なるソフトウェアアプリケーションを有するなどの、異なるソフトウェアを実行し得る。これは通常、SST又はPOS端末が使用される小売施設、及び小売施設におけるSST又はPOS端末の使用目的に依存する。適宜、SST又はPOS端末上で実行されているソフトウェアをアップグレードすることもでき、又は接続された周辺デバイスを変更することができる。
【0005】
端末間で頻繁に存在するばらつきのため、ソフトウェア開発者は、SST又はPOS端末上で実行する必要のあるソフトウェアを包含するソフトウェアコンテナを使用し始めている。ソフトウェアコンテナは、走るソフトウェアを隔離するので、複雑なプラットフォーム依存性を回避するのに役立つ。
【0006】
つまり、ソフトウェアコンテナは、端末のコンピューティング環境に関係なく、端末の1つ以上のプロセッサ上で実行することができる。これは、ソフトウェアコンテナがソフトウェア(アプリケーションコード及び任意のソフトウェア依存性)の全てを包含し、任意のコンピューティング環境で実行可能である必要があるためである。
【0007】
更に、これらのコンテナは独自の隔離されたコンピューティング環境で動作するため(ソフトウェアコンテナの外側にある他のソフトウェア/ハードウェアとのある特定の事前定義された通信経路(特定のファイル、特定のポートへのアクセスなど)は例外)、これによりまた、当該コンテナが特に安全になる。このように、ソフトウェアコンテナは、SST及びPOS端末上で使用するためのソフトウェアをパッケージング及び配信する効果的な方法である。
【0008】
ソフトウェア又はハードウェアのアップグレードが端末上で行われると、これらのアップグレードを構成する新しいソフトウェアコンテナが端末上で実行され得る。また、コンテナが事前構築され得るので、これは、あらゆる端末上での複雑な構築を回避するのに役立つ場合がある。
【0009】
ソフトウェアコンテナは、コンピューティングデバイス上にハイパーバイザをインストールする必要がないという点において、仮想マシンとは異なることが留意される。ソフトウェアコンテナはまた、通常、仮想マシンよりも軽量であり、かつ仮想マシンよりも速く走る。更に、仮想マシンはコンピュータシステム全体を仮想化するのに対し、ソフトウェアコンテナはオペレーティングシステムを仮想化する。ソフトウェアコンテナはまた、単一のオペレーティングシステムを共有するが、各仮想マシンは独自のオペレーティングシステムを有する。
【0010】
ソフトウェアコンテナを展開する場合、(docker、RKT、CRI-O、及びLXDなどのような)コンテナエンジンが利用される。コンテナエンジンは、ユーザ要求、又は(Kubernetes、Swarm、Mesosなどのような)コンテナオーケストレータのAPIサーバからの要求を受け入れ、レジストリから(特定の画像形式の)画像ファイルを引き出し、コンテナマウントポイントを準備し、ソフトウェアコンテナを実行するのに必要なメタデータを準備し、かつコンテナランタイムを呼び出すことができる。
【0011】
コンテナランタイムは、コンテナエンジンの一部である。コンテナランタイム(runc、containerd、crun、railcar、katacontainersなどのような)は、コンテナ画像ファイルを実行し、かつそれによって、ソフトウェアコンテナを作成するために、マウントポイント、及びコンテナエンジンによって提供されるメタデータを使用し、コンピューティングデバイス上で走る(ホストOSの)カーネルと通信する。
【0012】
複数のコンピューティングデバイスにわたって複数のコンテナを実装する場合、ソフトウェアコンテナのオーケストレータプラットフォームがよく使用される。これらのプラットフォームは、複数のコンピューティングデバイス(例えば、SST又はPOS端末)にわたってコンテナのワークロードをスケジュールすることができ、かつ、また、標準化されたアプリケーション定義ファイル(例えば、kube YAML、docker composeなど)を提供することができる。Kubernetesは、コンテナオーケストレーションプラットフォームの一例である。
【0013】
Kubernetesコンテナオーケストレーションプラットフォームは、クラスタを管理する、Kubernetesマスタと呼ばれる制御ユニットを含む、ユニットのクラスタ、及びワークロード(コンテナ)を走らせる少なくとも1つのノード(又はワーカ)である。
【0014】
Kubernetesオーケストレータプラットフォームの1つの部分は、kubeletである。kubeletは、Kubernetesシステムの一部である、あらゆるワーカ上で走るエージェントである。動作中、kubeletは、どのコンテナをコンピューティングデバイス上で走らせるべきかをkubeletに通知する(Kubernetesマスタ上のAPIサーバからの)コマンドを受信する。Kubernetesでは、これらのコンテナは、「ポッド」内に提供される。
【0015】
通常、単一のポッドは、単一のコンテナを含むが、ポッド内に複数のコンテナを含むことが可能である。kubeletは、コンテナエンジン内のコンテナランタイムを介してソフトウェアコンテナを実行するために、どのコンテナをコンピューティングデバイス上で走らせるべきかに関する情報を(例えば、コンテナランタイムインターフェース(CRI)を介して)コンテナエンジンに渡す。
【0016】
コンテナランタイムが、実行可能なコンテナ画像ファイルを実行すると、ソフトウェアコンテナが作成される。そのため、ソフトウェアコンテナは本質的に、関連付けられた実行可能なコンテナ画像ファイルのランタイムインスタンスである。この意味で、実行可能なコンテナ画像ファイルは、ソフトウェアコンテナ要素として少なくとも実行可能である必要がある、ソフトウェアの全てを有する画像ファイルである。
【0017】
より詳細には、コンテナ画像ファイルは通常、ソフトウェアコンテナの必要性及び能力を記述する任意のメタデータに加えて、ソフトウェアコンテナを走らせるための全ての必要な要件を含むバイナリファイルである。コンテナ画像ファイル自体は、ソフトウェアコンテナを走らせるために必要な実行可能な命令を定義するいくつかの層から構成される。
【0018】
例えば、コンテナ画像ファイルは、ソフトウェアアプリケーションの実行可能なコードを定義するいくつかの層、ソフトウェアアプリケーションが依存する任意のソフトウェア依存性に対するコードを定義するいくつかの層、及び任意の必要な構成設定に対するコードを定義するいくつかの層を含み得る。
【0019】
コンテナ画像ファイルは、多くの場合、コンテナ画像レジストリに記憶される。各コンテナ画像ファイルは、コンテナ画像ファイル内の層及びメタデータを定義する特定のコンテナ画像形式で記憶される。例えば、オープンコンテナイニシアチブ(OCI)画像形式は、各層のtarファイル、及び画像ファイルと関連付けられたメタデータを指定するJSON形式のマニフェストファイルとして、画像ファイルを定義する。
【0020】
SST及びPOS端末上にソフトウェアコンテナを配置する場合、デバイスドライバ/取り扱いソフトウェアをコンテナ内で実行することが望ましい。これは、デバイスドライバ及びそれらの関連ソフトウェアを、コンテナ内の他の全てのソフトウェアと同様に配信、管理、及び維持することができることを意味する。
【0021】
しかしながら、このアプローチは通常、特権ありのコンテナを必要とし、これは、コンテナが、基となるホストコンピューティングデバイスのほとんどの又は全てのルート能力を有し、それによって、非特権付きコンテナでは利用できないであろうリソースへのアクセスを可能にすることを意味する。
【0022】
ゆえに特権アクセスを有するソフトウェアコンテナを提供することはセキュリティリスクであり、展開のベストプラクティスに反するものである。これは、SST及びPOS端末が堅牢なセキュリティを有する必要があることを考慮すると、特に小売において懸念される。
【0023】
特権的な操作を回避するために、現在の手法では、通常、事前にアクセスする必要のあるデバイスのセットを正確に知るために、コンテナを必要とする。すなわち、コンテナを実行するときに、コンテナには、動作中にアクセスする必要のある周辺デバイスのみを示すデータが提供される。このアプローチが成功するためには、これらのデバイスも、コンテナが最初に実行されたときに存在する必要があることに留意されたい。
【0024】
デバイスが存在しない場合(例えば、それらがプラグインされていない場合)、コンテナは、利用可能となった(例えば、一旦プラグインされると)これらのデバイスと通信できなくなる。したがって、このアプローチは、デバイスプラグアンドプレイ又はアンプラグ-リプラグのシナリオを防止することが理解されよう。
【発明の概要】
【0025】
本発明の目的は、上述の問題のうちの1つ以上を少なくとも部分的に軽減することである。
【0026】
本発明の特定の実施形態の目的は、どのデバイスが実際に接続されるかを予め指定することなく、SST又はPOS端末に接続可能な任意の所定の周辺デバイスと通信することができるソフトウェアコンテナを提供することを助けることである。
【0027】
本発明の特定の実施形態の目的は、異なる端末上の異なるハードウェア設定(例えば、異なる周辺デバイス)に適合する、カスタムコンテナセットアップ(例えば、Kubernetesポッドセットアップ)を提供する必要性を回避することを助けることである。
【0028】
本発明の特定の実施形態の目的は、端末上の異なるハードウェアセットアップ、又はソフトウェアコンテナの実行における特定のデバイスの存在若しくは不在に適応する必要がないコンテナ仕様を提供することを助けることである。
【0029】
本発明の特定の実施形態の目的は、ソフトウェアコンテナの初期実行後にプラグインされるか、又はソフトウェアコンテナの初期実行後にアンプラグされ、かつリプラグされる周辺デバイスと通信することができるソフトウェアコンテナを実行する、SST又はPOS端末を提供することを助けることである。
【0030】
本発明の特定の実施形態の目的は、ファームウェア更新により、検出されたデバイスの存在が一時的に消失し、その後再び現れる場合でも、ソフトウェアコンテナと周辺デバイスとの間の通信を維持することを助けることである。
【0031】
本発明の特定の実施形態の目的は、デバイスドライバソフトウェアを含むソフトウェアコンテナを提供することを助けることであり、ここで、コンテナは、特権アクセスを必要とせず、セキュリティを損なわずに配信及び管理され得る。
【0032】
本発明の特定の実施形態の目的は、ホットプラグ機能を有するソフトウェアコンテナを提供することを助けることであり、ここで、デバイスは、コンテナの起動時に存在する必要はなく、それらが後で追加又は除去される場合、システムは適合する。
【0033】
本発明の第1の態様によれば、ソフトウェアコンテナ要素が複数の所定の周辺デバイスの各周辺デバイスにアクセスし、かつそれと通信することを可能にする、周辺デバイス接続データと関連付けられたソフトウェアコンテナ要素を提供するためのコンピュータ実装方法が提供されている。
このような実装方法は、コンピューティングデバイスの1つ以上のプロセッサ上で実行可能である第1の実行可能なソフトウェアを含むモジュールから、コンピューティングデバイスに接続可能な周辺デバイスの少なくとも1つのクラスを示す第1のデータを受信するステップであって、各クラスが、複数の所定の周辺デバイスと関連付けられている。
【0034】
受信するステップと、コンピューティングデバイスのその1つ以上のプロセッサ上で実行可能である第2の実行可能なソフトウェアを含む、ソフトウェアコンテナ要素を提供するステップであって、ソフトウェアコンテナ要素が、ソフトウェアコンテナ要素が各クラスと関連付けられた複数の所定の周辺デバイスの各周辺デバイスにアクセスし、かつそれと通信することを可能にする、周辺デバイス接続データと関連付けられている、提供するステップと、を含む。
【0035】
好適には、方法は、コンピューティングデバイスに接続可能な周辺デバイスの単一のクラスを示すデータとして第1のデータを受信することであって、単一のクラスが、セルフサービス端末又はポイントオブセール端末に接続可能な複数の所定の周辺デバイスと関連付けられている、受信することを更に含む。
【0036】
好適には、方法は、コンピューティングデバイスに接続されている新しい周辺デバイス、又はコンピューティングデバイスに対して切断され、かつ再接続されている周辺デバイスに応答して、ソフトウェアコンテナ要素によって、新しい又は再接続された周辺デバイスがコンピューティングデバイスに接続されていると決定することを更に含む。
【0037】
好適には、方法は、各クラスと関連付けられた複数の所定の周辺デバイスを示す第2のデータを、コンピューティングデバイスによってアクセス可能なメモリに記憶することを更に含む。
【0038】
好適には、方法は、第1のデータを受信する前に、どの周辺デバイスがコンピューティングデバイスに接続されているかを問い合わせるクエリを、モジュールに送信することを更に含む。
【0039】
好適には、方法は、コンピューティングデバイス上のソフトウェアコンテナ要素を管理する責任を有するソフトウェアアプリケーションにおいて第1のデータを受信することを更に含む。
【0040】
好適には、方法は、接続された周辺デバイスと通信するように構成されたモジュールとして、モジュールを提供することを更に含む。
【0041】
好適には、方法は、第1の実行可能なソフトウェアを含むソフトウェアコンテナ要素として、モジュールを提供することであって、任意にモジュールがデバイスプラグインモジュールである、提供することを更に含む。
【0042】
好適には、方法は、第1のデータを受信することに応答して、モジュールを指令する少なくとも1つのコマンドをモジュールに送信して、ソフトウェアコンテナ要素への割り当てのために、各クラスと関連付けられた複数の所定の周辺デバイスの各々を準備することを更に含む。
【0043】
好適には、方法は、モジュールから、各クラスと関連付けられた複数の所定の周辺デバイスの各々についての少なくともそれぞれの周辺デバイス経路を示す第3のデータを受信することを更に含む。
【0044】
好適には、方法は、各クラスと関連付けられた複数の所定の周辺デバイスの各々について、少なくともそれぞれの周辺デバイス経路を表すデータとして、周辺デバイス接続データを提供することを更に含む。
【0045】
好適には、方法は、ソフトウェアコンテナ要素と関連付けられた制御グループに周辺デバイス接続データを記憶することを更に含む。
【0046】
好適には、方法は、第2の実行可能な命令の実行時に、ソフトウェアコンテナ要素によって、各クラスと関連付けられた複数の所定の周辺デバイスのうちのどの周辺デバイスがコンピューティングデバイスに接続されているかを決定することを更に含む。
【0047】
好適には、方法は、決定することに応答して、ソフトウェアコンテナ要素によって、コンピューティングデバイスに接続された各周辺デバイスを初期化することを更に含む。
【0048】
好適には、方法は、初期化することに応答して、ソフトウェアコンテナ要素によって、接続された周辺デバイスのうちの少なくとも1つに1つ以上のコマンドを送信することを更に含む。
【0049】
好適には、方法は、コンピューティング環境に関係なく実行可能であるソフトウェアとして、第1の実行可能なソフトウェア及び第2の実行可能なソフトウェアを提供することを更に含む。
【0050】
好適には、方法は、モジュール及びソフトウェアコンテナ要素をそれぞれ介して、隔離されたコンピューティング環境で第1の実行可能なソフトウェア及び第2の実行可能なソフトウェアを実行することを更に含む。
【0051】
本発明の第2の態様によれば、コンピューティングデバイス上のソフトウェアコンテナ要素を管理する責任を有するソフトウェアアプリケーションを実行するように構成された1つ以上のプロセッサを備える、コンピューティングデバイスが提供されており、ソフトウェアアプリケーションは、コンピューティングデバイスの1つ以上のプロセッサ上で実行可能である第1の実行可能なソフトウェアを含むモジュールから、コンピューティングデバイスに接続可能な周辺デバイスの少なくとも1つのクラスを示す第1のデータを受信することであって、各クラスが、複数の所定の周辺デバイスと関連付けられている、受信することと、コンピューティングデバイスのその1つ以上のプロセッサ上で実行可能である第2の実行可能なソフトウェアを含む、ソフトウェアコンテナ要素を提供することであって、ソフトウェアコンテナ要素が、ソフトウェアコンテナ要素が各クラスと関連付けられた複数の所定の周辺デバイスの各周辺デバイスにアクセスし、かつそれと通信することを可能にする、周辺デバイス接続データと関連付けられている、提供することと、を行うように構成されている。
【0052】
好適には、コンピューティングデバイスは、ポイントオブセール端末又はセルフサービス端末である。
【0053】
本発明の第3の態様によれば、命令を含むコンピュータプログラムが提供されており、命令は、コンピューティングデバイスによって実行されたときに、コンピューティングデバイスに、本発明の第1の態様によって定義される方法のステップを行わせる。
【0054】
本発明の特定の実施形態は、ソフトウェアコンテナ要素を、ソフトウェアコンテナ要素が、端末に接続され得る所定の周辺デバイスのセットのいずれかと通信することを可能にする、周辺デバイス接続データとともに提供する方法論を提供することを助けることである。
【0055】
本発明の特定の実施形態は、SST又はPOS端末に接続可能な周辺デバイスのクラスをアドバタイズする、デバイスプラグインコンテナを提供することを助けることであり、端末は、このクラス内の全てのデバイスにアクセスできるソフトウェアコンテナを実行する。
【0056】
本発明の特定の実施形態の目的は、アクセスが許可されている一連のダミーデバイスノードを表すデータを含む、ソフトウェアコンテナを提供することを助けることである。ダミーデバイスノードは、周辺デバイスの特定のクラスの現在及び将来の全てのデバイスに対して作成される。接続された周辺デバイスは、ダミーデバイスノードのうちの1つでアクセス可能であり、ソフトウェアコンテナは、どのノードが使用されているか、及びどのデバイスが接続されているかを決定する責任を有する。
【0057】
本発明の特定の実施形態の目的は、ソフトウェアコンテナを実行し、かつプラグアンドプレイ及びアンプラグ-リプラグ機能を有する、コンピューティングデバイスを提供することを助けることである。
【0058】
本発明の特定の実施形態の目的は、小売デバイスクラスと関連付けられた全ての周辺デバイスへのアクセスを有するように構成されたソフトウェアコンテナを提供することを助けることである。
【0059】
本発明の特定の実施形態の目的は、周辺デバイスが接続されている、又は接続され得る一連のデバイス経路へのアクセスを有するように構成されたソフトウェアコンテナを実行するために必要なデータをコンテナエンジンに提供することを助けることである。
【0060】
本発明の特定の実施形態の目的は、周辺デバイスの抽象的なセットへのアクセスを有するソフトウェアコンテナを提供することを助けることである。
【0061】
ここで、本発明の実施形態を、例としてのみ、添付図面を参照して以降で説明する。
【0062】
図面では、同様の参照番号は同様の部品を指す。
【図面の簡単な説明】
【0063】
図1】コンピューティングシステムを示す。
図2】Kubernetesオーケストレーションプラットフォームの制御下にあるコンピューティングシステムを示す。
図3】いくつかのソフトウェアコンテナを実行するセルフサービス端末のためのハードウェア及びソフトウェアアーキテクチャを示す。
図4】セルフサービス端末上で実行されるソフトウェアコンテナ要素を示す。
図5】複数のセルフサービス端末と通信するサーバ上で実行されるソフトウェアを示す。
図6】実行可能な画像ファイルの層を示す。
図7】周辺デバイス接続データを含むソフトウェアコンテナを提供する、コンピューティングシステムのいくつかの構成要素を示す。
図8】あるクラスの周辺デバイスの各周辺デバイスへのアクセス及び通信を有するように構成されたソフトウェアコンテナがどのように提供されるかを説明する、フローチャートを示す。
【発明を実施するための形態】
【0064】
図1は、コンピューティングシステム100を示す。コンピューティングシステム100には、3つのセルフサービス端末(SST)1101、1102、1103がある。SSTは、コンピューティングデバイスの一例である。
【0065】
本発明のある特定の他の実施形態では、コンピューティングデバイスは、ポイントオブセール(POS)端末、現金自動預け払い機(ATM)、パーソナルコンピュータ、ラップトップ、タブレットなどであってもよい。各SSTは、1つ以上のプロセッサ112、及び少なくとも1つのメモリ114を含む。メモリは、非一時的コンピュータ可読記憶媒体である。メモリ114は、SSTのプロセッサ112によって実行可能である実行可能なソフトウェアを記憶する。各SSTはまた、サーバと通信するための通信インターフェース(図示せず)、及び接続された周辺デバイスと通信するための1つ以上の通信インターフェース(図示せず)を含み得る。
【0066】
図1に示されるシステムでは、スキャナ周辺デバイス1201及びスケール周辺デバイス1202が、第1のSST1101に接続されている。また、プリンタ周辺デバイス1203及びスキャナ周辺デバイス1204が、第2のSST1102に接続されている。また、スケール周辺デバイス1205、プリンタ周辺デバイス1206、及びスキャナ周辺デバイス1207が、第3のSST1103に接続されている。
【0067】
本発明のある特定の他の実施形態では、各SSTは、周辺デバイスの異なる組み合わせに接続され得ることが理解されよう。各周辺デバイスは、有線インターフェース122を介して接続されるSSTと通信し得る。本発明のある特定の他の実施形態では、インターフェースは、無線、又は有線と無線との組み合わせであってもよいことが理解されよう。
【0068】
各SSTは、ネットワーク140を介してサーバ130と通信する。サーバもまた、コンピューティングデバイスの一例である。ネットワーク140は、有線、無線、又は有線と無線との組み合わせであってもよい。サーバ130もまた、1つ以上のプロセッサ132、及び少なくとも1つのメモリ134を含む。メモリ134もまた、非一時的コンピュータ可読記憶媒体である。メモリ134は、サーバのプロセッサによって実行可能である実行可能なソフトウェアを記憶する。SST及びサーバの実行可能なソフトウェアについて、以下でより詳細に説明する。
【0069】
図2は、コンピューティングシステム200を示す。コンピューティングシステムは、Kubernetesコンテナオーケストレーションプラットフォームの制御下にある、いくつかの構成要素を有する。そのため、本システムは、Kubernetesクラスタと称され得る。Kubernetesクラスタは、Kubernetesマスタ215を走らせるサーバ210と、それぞれのKubernetesワーカ2301、2302を走らせるセルフサービス端末(SST)2201、2202と、を含む。
【0070】
サーバ210は、物理サーバであっても、クラウドサーバであってもよいことが理解されよう。サーバ210及びSSTは、ローカルエリアネットワーク又はインターネットなどの、ネットワーク205を経由して通信する。ネットワークは、有線及び/又は無線であってもよい。SST以外のデバイスをネットワークに接続して、Kubernetesワーカを走らせることができることが理解されよう。
【0071】
サーバ210上で走るKubernetesマスタ215は、Kubernetesクラスタを管理するAPIサーバ216を含む。APIサーバ216は、マスタ215の他の内部構成要素から受信する情報に基づいてコマンドを発行し、かつKubernetesワーカ2301、2302上で走るkubectl212及びkubelet(SST2 2202上のkubelet231など)などの外部構成要素とインターフェース接続する。Etcd217は、クラスタの構成などの情報を記憶するKubernetesクラスタのための配信データベースである。
【0072】
Etcd217はまた、Kubernetesワーカ2301、2302の望ましい状態、及びKubernetesワーカ2301、2302の実際の状態を記憶する。ある状態は、クラスタ内の各Kubernetesワーカ2301、2302上で走っている、ポッド(SST2 2202上のポッド3 235など)及びポッドのコンテナ(ポッド235のコンテナ236など)の指標であると理解され得る。
【0073】
スケジューラ218は、新しいポッドをKubernetesワーカ上でいつ走らせるかを監視し、次いで、当該ポッドをどのKubernetesワーカ上に展開するかを決定する。コントローラマネージャ219は、etcd217に対して指定された望ましい状態に近づくようにKubernetesワーカ2301、2302の実際の状態を移動させることを試みるコントローラプロセスを走らせる。
【0074】
マスタ215はまた、kubectl212、APIサーバ216を介してKubernetesクラスタと通信するためのコマンドラインツール、及びオペレータインターフェース211を含む。
【0075】
Kubernetesクラスタ内に位置する各Kubernetesワーカ2301、2302は、SST上で走る。
【0076】
本発明のある特定の実施形態によれば、ワーカは、SSTの仮想マシン上で走らせることができる。ワーカ230は、ネットワーク205を介して、他のワーカ230及びマスタ215と通信することができる。各ワーカ230は、ワーカ230の動作を管理するkubeletを有する。kubelet(SST2202上のkubelet231など)は、ワーカ2302の他の構成要素にコマンドを発行し、ワーカ(ポッド235など)及びワーカのコンテナ(コンテナ236など)上で走るポッドを監視し、かつAPIサーバ216と通信する。kubelet231は、展開ファイルを受信し、これらの展開ファイルに記述されたコンテナ236が走っており、かつ正常であることを保証する。
【0077】
kube-proxy(kube-proxy232など)は、ポッドが、同じKubernetesワーカ及び異なるワーカの両方で通信することを可能にする、ネットワークプロキシである。
【0078】
コンテナエンジン(エンジン233など)は、コンテナを走らせ、かつ管理して、kubeletからのコマンド、及びレジストリからのコンテナ画像を受信する。コンテナエンジンは、内部にランタイムが位置するKubernetesワーカ内のコンテナを走らせることに関与するコンテナランタイム(コンテナランタイム234など)に渡されるコンテナメタデータを準備する。
【0079】
Kubernetesマスタ215のAPIサーバ216によってポッドがKubernetesワーカに展開された後、任意のKubernetesワーカ内にポッドが存在する。ポッドは一般に単一のコンテナを含むが、ポッドは、ストレージ及びネットワークリソースを共有することになる、類似の機能を有する複数のコンテナを含み得る。ポッドは、kubeletを介して、ワーカが利用可能な特定のリソースへのアクセスを要求するか、又はkube-proxyを使用することによって、他のポッドと通信することができる。
【0080】
図3は、いくつかのソフトウェアコンテナ要素を実行するように構成されたセルフサービス端末のためのハードウェア及びソフトウェアアーキテクチャ300を示す。図3では、基礎となるハードウェアは、SST310である。
【0081】
これは、図1又は図2に関して記述されるSSTのうちの1つであってもよい。上述のように、SSTは、1つ以上のプロセッサ、及び少なくとも1つのメモリを含む。メモリは、プロセッサによって実行可能である実行可能なソフトウェアを記憶する。
【0082】
実行可能なソフトウェアには、(Unix又はUbuntuなどのような)ホストオペレーティングシステムの一部であってもよい、Linuxカーネル320が含まれる。本発明のある特定の他の実施形態では、他のカーネル及び他のホストオペレーティングシステム(Windows、Macなど)を利用することができることが理解されよう。実行可能なソフトウェアの一部として、コンテナエンジン330も含まれる。
【0083】
コンテナエンジンは、ユーザ要求、又は(Kubernetes、Swarm、Mesosなどのような)コンテナオーケストレータのAPIサーバからの要求を受け入れ、レジストリから(特定の画像形式の)画像ファイルを引き出し、コンテナマウントポイントを準備し、ソフトウェアコンテナを実行するのに必要なメタデータを準備し、かつコンテナランタイムを呼び出すことに関与する。
【0084】
コンテナランタイム(図示せず)は、コンテナエンジンの一部である。コンテナランタイム(runc、containerd、crun、railcar、katacontainersなどのような)は、いくつかのコンテナ画像ファイルを実行し、かつそれによって、いくつかのソフトウェアコンテナを作成するために、マウントポイント、及びコンテナエンジンによって提供されるメタデータを使用し、コンピューティングデバイス上で走っているLinuxカーネル320と通信する。
【0085】
図3に示されるソフトウェアコンテナの各々についての実行可能な画像ファイルは、レジストリからダウンロードされ得る。図3では、4つのソフトウェアコンテナ要素が示されている。第1のソフトウェアコンテナ要素370は、デバイスプラグインコンテナと称される。デバイスプラグインコンテナは、アプリケーションソフトウェア372、並びに関連付けられたバイナリ及びライブラリ374を含む(バイナリ及びライブラリは、ソフトウェア依存性と称され得る)。
【0086】
デバイスプラグインコンテナ内で走るアプリケーションは、以下に説明するように、どの周辺デバイスがSSTに接続されているかを知らせることに関与する。デバイスプラグインコンテナは、単一の層のみを含み得る。したがって、デバイスプラグインコンテナは、全ての依存性が単一の(多くの場合、Golang)実行可能ファイルに組み込まれる、「ディストロレス」コンテナと呼んでもよい。
【0087】
第2のソフトウェアコンテナ要素340は、デバイスサーバコンテナと称される。デバイスサーバコンテナは、アプリケーションソフトウェア342、並びに関連付けられたバイナリ及びライブラリ344を含む(バイナリ及びライブラリは、ソフトウェア依存性と称され得る)。
【0088】
デバイスサーバコンテナ内で走るアプリケーションは、低いレベルで、SSTに接続された周辺デバイスのうちの1つ以上を制御すること、構成すること、又は別様に当該周辺デバイスにアクセスすること、並びにネットワークを横切って、SSTの他の構成要素に事業レベルの機能を公開することに関与する。例えば、デバイスサーバは、「USB」プロトコルを介して、スキャナ(低レベル)と通信し、スキャンされたバーコード(事業レベル)を他の構成要素に報告し得る。
【0089】
デバイスサーバコンテナ内のソフトウェアは、周辺デバイスパスにアクセスし、ひいては、周辺デバイスを使用するか、又は周辺デバイスと相互作用することができる。第3のソフトウェアコンテナ要素350は、INITコンテナと称される。INITコンテナは、アプリケーションソフトウェア352、並びと関連付けられたバイナリ及びライブラリ354を含む(バイナリ及びライブラリは、ソフトウェア依存性と称され得る)。
【0090】
INITコンテナで実行されるアプリケーションは、そのポッド内で初期化されてから、メイン(INITではない)コンテナを開始する。INITコンテナは、Kubernetesシステムの概念であるが、最初に(すなわち、他のコンテナの前に)実行されるように構成されたコンテナもまた、他のコンテナオーケストレーションプラットフォームにおいて利用され得ることが理解されよう。
【0091】
第4のソフトウェアコンテナ要素360は、エンドポイントコンテナと称される。エンドポイントコンテナは、アプリケーションソフトウェア362、並びに関連付けられたバイナリ及びライブラリ364を含む(バイナリ及びライブラリは、ソフトウェア依存性と称され得る)。エンドポイントコンテナ内で走るアプリケーションにより、マザーボードのユニバーサル固有識別子(UUID)などの、SSTに関する情報が、Kubernetesクラスタの残りの部分に対して利用可能になる。
【0092】
図3に見ることができるように、各ソフトウェアコンテナ要素は、独自のバイナリ及びライブラリ(bin/lib)を有する。しかしながら、本発明のある特定の他の実施形態によると、コンテナの任意の組み合わせは、bin/libを共有し得ることが理解されよう。
【0093】
ここで図4を参照すると、セルフサービス端末400、及びセルフサービス端末上で実行されるように構成された(SSTの1つ以上のプロセッサ上にある)ソフトウェアコンテナ要素が示されている。
【0094】
SST上のソフトウェアコンテナの各々は、(画像ファイルによって定義される)実行可能なソフトウェアを包含する。実行可能なソフトウェアは、隔離されたコンピューティング環境でソフトウェアが実行されるような方法で、コンテナ内で実行される。ソフトウェアは、動作するためにSST上で同様に実行される他のソフトウェアコンテナのいずれにも依存しないという意味において、隔離されている。
【0095】
ソフトウェアは、独自のコンピューティング環境で効果的に実行され、かつ事前定義された通信経路を介して、この環境の外側にあるハードウェア/ソフトウェアと通信する。ソフトウェアコンテナ内に実行可能なソフトウェアを提供することは、コンピューティング環境に関係なくソフトウェアを実行することができることを意味する。
【0096】
図4では、コンテナは、Kubernetesコンテナオーケストレーションプラットフォームを使用して管理されている。図4に示されるSSTは、上記の図1図3のいずれかを参照して説明されるSSTであってもよい。SST400は、ホストオペレーティングシステムの一部としてLinuxカーネル405を走らせる。
【0097】
当然のことながら、本発明のある特定の他の実施形態に従って、他のオペレーティングシステムを使用することができる。Kubernetesシステムを使用して、セルフサービス端末は、Kubernetesワーカ410と称されるソフトウェアを実行する。
【0098】
Kubernetesワーカはまた、ノードと称されることもある。第1のソフトウェアコンテナ要素450、第2のソフトウェアコンテナ要素430、第3のソフトウェアコンテナ要素420、及び第4のソフトウェアコンテナ要素440が、Kubernetesワーカ410内に含まれる。Kubernetesプラットフォームは、図2を参照して説明されるように、これらのコンテナを管理することに関与する。
【0099】
第1のソフトウェアコンテナ、第2のソフトウェアコンテナ、第3のソフトウェアコンテナ、及び第4のソフトウェアコンテナは、図3を参照して説明されるのと同じコンテナであってもよい。セルフサービス端末400はまた、Kubernetesワーカ410の外部を実行する追加のソフトウェア(図示せず)を含む。
【0100】
Kubernetesワーカ410では、第2のソフトウェアコンテナ430及び第3のソフトウェアコンテナ420は、デバイスサーバポッド425と称される単一のポッド内で実行される。第3のソフトウェアコンテナ420はINITタイプのものであるため、デバイスサーバポッド内で実行される(すなわち、デバイスサーバコンテナの前に実行される)第1のコンテナである。
【0101】
第4のソフトウェアコンテナ440は、エンドポイントポッド445と称される単一のポッド内で実行される。第1のソフトウェアコンテナ450は、デバイスプラグインポッド455と称される単一のポッド内で実行される。これらのポッドの各々の作成は、当業者によって理解されるように、3つの異なるポッド仕様ファイル(すなわち、deployment.YAMLファイル)によって定義される。
【0102】
ポッドは、共有ストレージ及びネットワークリソースを備えたコンテナ、並びにポッド内でコンテナをどのように走らせるかについての仕様を提供するために、Kubernetesで使用される。SST400の動作中、これらのポッド/コンテナの各々は、コンテナエンジン(図示せず)のコンテナランタイム(図示せず)によって実行される。これらのコンテナの各々と関連付けられた画像ファイルは、レジストリからダウンロードされ得る。
【0103】
図5は、Kubernetesマスタ及びKubernetesワーカを隔離して、走らせているサーバ500を示す。サーバは、複数のSST(図5には示されていない)と通信し得る。サーバは、1つ以上のプロセッサ(図示せず)、及び少なくとも1つのメモリ(図示せず)を有する。メモリは、ランタイム時にプロセッサによって実行される実行可能なソフトウェアを記憶する。
【0104】
実行可能なソフトウェアは、(ホストOSの)Linuxカーネル510を含む。本発明のある特定の他の実施形態では、他のオペレーティングシステムが使用され得ることが理解されよう。
【0105】
実行可能なソフトウェアはまた、Kubernetesマスタ520を含む。Kubernetesマスタは、図2を参照して上述したのと同様の構成要素を含む。これらは、APIサーバ522、スケジューラ524、コントローラマネージャ526、及びetcdデータベース528である。
【0106】
Kubernetesワーカ530もまた、サーバ上で実行される。Kubernetesワーカ530は、3つのポッドを含み、ポッド自体は、ソフトウェアコンテナ要素を含む。サーバ上の第1のポッドは、動的コンテナプロキシポッド532である。
【0107】
このポッドは、対応する動的コンテナプロキシソフトウェアコンテナを含む。動的プロキシソフトウェアコンテナは、実行可能な画像ファイルに対するコンテナエンジンからの要求を受信することに関与する。
【0108】
サーバ上の第2のポッドは、上流のコンテナレジストリポッド534である。このポッドは、対応する上流のコンテナレジストリソフトウェアコンテナを含む。レジストリコンテナは、画像ファイルを記憶し、かつ要求に応じて、これらの画像ファイルをコンテナエンジンに提供することに関与する。サーバ上の第3のポッドは、事業ロジックポッド536である。このポッドは、対応する事業ロジックソフトウェアコンテナを含む。
【0109】
図6は、ソフトウェアコンテナとして実行するための実行可能な画像ファイル600の概略図を示す。図6に示される画像ファイルは、図4のデバイスサーバコンテナを提供するために実行可能である。
【0110】
図6に見ることができるように、実行可能な画像ファイルは、ベースオペレーティングシステム層605、Java層610、ドライバ層615、共通層620、ユーティリティ層625、スキャナ層630、スケール層635、プリンタ層640、及びデバイスサーバ層645を有する。これらの層を有するこの画像ファイルは、レジストリに記憶され、かつ端末のコンテナエンジンからの要求に応じてダウンロードされ得る。ベースOS層は、ソフトウェアコンテナ(例えば、Ubuntu)内で利用されるオペレーティングシステムを定義する。
【0111】
しかしながら、ベースOS層は、本発明のある特定の他の実施形態で必要とされない場合がある。Java層は、Javaプログラミング言語を解釈するための実行可能な命令を定義する。しかしながら、本発明のある特定の他の実施形態では、他のプログラミング言語が使用されている場合、Java層は必要とされない場合があることが理解されよう。
【0112】
ドライバ層は、画像にユーザ空間ドライバをインストールすることに関与する実行可能な命令を定義する、任意選択の層である。ユーザ空間ドライバの一例は、低レベルのUSBヘルパであってもよい。
【0113】
一部の画像は、いずれのユーザ空間ドライバも必要としない場合があることが理解されよう。共通層は、他の層によって共有又は使用されるフレームワーク構成要素を包含する実行可能な命令を定義する。かかるフレームワークの一例は、他の構成要素からのログを制御及びキャプチャするために使用されるロギングフレームワークであってもよい。
【0114】
ユーティリティ層は、ユーザ向けユーティリティ及びツールを含む実行可能な命令を定義する、任意選択の層である。かかるツールの一例は、SST上にインストールされているデバイスのリストを閲覧し、かつ診断チェックを走らせるなどの動作により、これらのデバイスと相互作用するために使用され得る、システムメンテナンスユーティリティであってもよい。
【0115】
ドライバ層、共通層、及びユーティリティ層は、ソフトウェア依存性と集合的に称され得る。ドライバ層及び/又は共通層及び/又はユーティリティ層は、本発明のある特定の実施形態において必要とされない場合があることが理解されよう。
【0116】
スキャナ層は、スキャナ周辺デバイスと通信するための実行可能な命令を定義し、スケール層は、スケール周辺デバイスと通信するための実行可能な命令を定義し、プリンタ層は、プリンタ周辺デバイスと通信するための実行可能な命令を定義する。
【0117】
これらの層は、周辺デバイスドライバ画像層と称され得る。スキャナ、スケール、及びプリンタの層は、特定のスキャナ、スケール、又はプリンタと関連付けられた層であることが理解されよう。一例として、スキャナは、NCR2356ハンドヘルドスキャナであってもよく、スケールは、NCR(本願出願人の登録商標)8789スケールであってもよく、プリンタは、NCR7169サーマルレシートプリンタであってもよい。
【0118】
本発明のある特定の他の実施形態では、他の周辺デバイス(バーコードリーダ、カメラなど)と関連付けられた層が必要となる場合があることも理解されよう。
【0119】
図6に示される周辺デバイス画像層は、必ずしも必要ではない場合があることも理解されよう。デバイスサーバ層は、低いレベルで、SSTに接続された周辺デバイスのうちの1つ以上を制御し、構成し、又は別様に当該周辺デバイスにアクセスし、かつネットワークを横切って、SSTの他の構成要素に事業レベルの機能を公開するための実行可能な命令を定義する。
【0120】
図7は、コンピューティングシステム700の特定の構成要素を示す。図7に示す構成要素は、図1図4を参照して説明したSSTなどのSST又はPOS端末上に存在する。より詳細には、図7は、kubelet710、リソースマネージャ720、デバイスプラグイン要素730、コンテナ化されたランタイム要素740、及び特定の接続された周辺デバイス750を示す。kubeletは、Kubernetesオーケストレーションプラットフォームの一部としてSSTで使用されるソフトウェアアプリケーションである。
【0121】
このソフトウェアアプリケーションは、SST上で動作するソフトウェアコンテナの管理に使用される。リソースマネージャ(明確にするために別個に表示)は、kubeletの一部である。リソースマネージャは、ノード上で利用可能なリソースを列挙し、Kubernetesシステムの他の構成要素、特にKubernetesスケジューラへのKubeletを介してそれらを識別する責任を有する。リソースには、RAM、CPU、ローカル永続ストレージなどのリソースを含めることができ、カスタムリソースで拡張することができる。
【0122】
カスタムリソースは、低レベル又は汎用リソースとすることができる。例えば、カスタムリソースは、一般的に、バス2上のポート10にあるUSBデバイスであってもよく、又は、より機能的に明示的であってもよく、例えば、「バーコードスキャナ」であってもよい。リソースマネージャは、利用可能である特定のタイプのリソース数など、リソース容量の管理する責任をも有する。
【0123】
リソースマネージャはまた、コンテナに取り付けるためのデバイスを準備するか、コンテナから取り外した後にデバイスをきれいにする責任を有する。例えば、デバイスが、コンテナに取り付けられる前に、工場出荷時の状態にリセットされるときなどである。デバイスプラグインは、ソフトウェアコンテナとして実行されてもよい。
【0124】
しかしながら、本発明の特定の他の実施形態によれば、デバイスプラグインは、ソフトウェアコンテナとして実行される必要はないことが理解されよう。デバイスプラグイン要素は、SST又はPOS端末のプロセッサ(又は複数のプロセッサ)上で実行される実行可能な命令を含む、
モジュールである。デバイスプラグインは、カスタムリソースを管理する責任を有する。デバイスプラグインモジュールは、接続された周辺デバイス、及びkubeletのリソースマネージャと通信する。デバイスプラグインは、クラス内の全ての周辺デバイスにアクセスできるソフトウェアコンテナを提供できる情報を、Kubeletに提供する。
【0125】
これについては以下で詳しく説明する。コンテナ化されたランタイム要素は、コンテナエンジンの一部である、コンテナランタイムである。ランタイムは、画像ファイルをソフトウェアコンテナとして実行する。ランタイムには、いくつかの必要なソフトウェアコンテナを実行するために、kubeletからの情報が提供される。ここで、これらの構成要素がどのように相互作用するかについて説明する。
【0126】
SSTの起動時、及び図7に示すソフトウェア構成要素が実行され、SST上で行われた後、Kubelet710は、リソースマネージャを呼び出し、利用可能なリソースを見つける。
【0127】
リソースマネージャ720は、標準リソース(RAM、CPUなど)を報告し、デバイスプラグインを更に呼び出して、追加のカスタムリソースを検出する。1つ以上のデバイスプラグインが存在し得ることに留意されたい。
【0128】
リソースマネージャは、どのデバイスがSSTに物理的に接続されているかを問い合わせるクエリをデバイスプラグインに送信することで、これを行う。このクエリはデバイスプラグインで受信され、このクエリに対する応答として、デバイスプラグインは、カスタムリソースを列挙し、カスタムリソースが何であり、各リソースのうちいくつがKubeletに戻って利用可能であるかを報告する。
【0129】
特に、デバイスプラグイン730は、SSTに接続可能な全ての既知のプリンタ、スキャナ、計量器、ディスプレイ、及び小売デバイスなどの、1つ以上の、おそらくは重複した抽象的なクラスのデバイスを識別するデータを、リソースマネージャに提供する。この例では、小売デバイスクラスは、プリンタ、スキャナ、及び計量器を含む、単一のクラスであり得る。
【0130】
このクラスには、ディスプレイなどの特定のタイプのデバイスが含まれていない場合がある。kubeletは、Kubernetes APIサーバデータモデル内のKubernetesワーカオブジェクトに対するリソース(標準及びカスタム)を記録する。
【0131】
そこから、利用可能なリソースに関する情報を、Kubernetesスケジューラなどの構成要素が使用して、作業負荷(ポッド)スケジューリングに関する決定を行うことができる。例えば、作業負荷がバーコードスキャナが必要であると識別した場合、そのクラスに利用可能な少なくとも1つのデバイスがあるKubernetesワーカにスケジュールすることができる。
【0132】
クラス(小売デバイスクラスなど)と関連付けられた小売周辺デバイスの定義は、SST上のメモリに記憶される。これは、例えば、構成マップ(ConfigMap)に記憶された、特定のグループ(又はクラス)へのデバイスのメンバーシップを定義するルールの形態であり得る。構成マップ内のルールは、そのデバイス経路に基づいてクラスに入るデバイスを識別するための「正規表現」を含み得る。構成マップは、追加的又は代替的に、例えば、デバイスベンダー、クラス及びサブクラス(USB概念)によるフィルタリングをサポートしてもよい。
【0133】
本発明の特定の他の実施形態では、クラスと関連付けられた小売周辺デバイスのセットは、他の場所(例えば、サーバ上)に記憶され得ることが理解されよう。
【0134】
本発明の特定の他の実施形態では、デバイスプラグインは、複数のクラス(例えば、プリンタデバイスクラス、スキャナデバイスクラス、計量器デバイスクラスなど)を示すデータを、クエリに応答してリソースマネージャに送信し得ることがまた理解されよう。
【0135】
このような場合、リソースマネージャは、クラスの潜在的な重複の性質のために複雑であり得る特定のクラスにわたってリソースの可用性を管理する。例えば、ある作業負荷がすでに「スキャナ」に割り当てられており、別の作業負荷が「小売デバイス」を要求している場合、スキャナではない小売デバイスのサブセットを新しいコンテナに割り当てることのみが可能である。
【0136】
Kubernetesのスケジューラが、特定のKubernetesワーカに関する特定のリソースを必要とするワークロード(ポッド)をスケジュールすることを決定したら、kubernetesは、再びリソースマネージャに話し、ポッドに標準リソースとカスタムリソースを割り当てる。カスタムリソースの場合、リソースマネージャは、デバイスプラグインと通信し、(以前はリソースマネージャにアドバタイズされていた)周辺デバイスのクラスを作業負荷に割り当てる準備が整うように要求する。
【0137】
これを行うために、リソースマネージャは、デバイスプラグインにコマンドを送信する。送信されるコマンドによって、デバイスプラグインに指令し、小売デバイスクラスと関連付けられた周辺デバイスの各々をポッド/コンテナに割り当てる準備をする。要求の受信に応答して、デバイスプラグインはまた、ポッドに割り当てられるクラス内の各デバイスに対する経路(すなわち、周辺デバイスがアクセスすることができる経路)を識別するさらなるデータを送信し、この情報をリソースマネージャに渡す。
【0138】
したがって、プラグインコンテナは、多数のダミーデバイス経路又はノード(多くの経路には接続される周辺デバイスが存在しないため)をリソースマネージャに効果的に送信する。これらは、kubelet及びコンテナランタイムと共有される。
【0139】
ランタイムは、制御グループ(cグループ)内の可能性のあるデバイス経路の各々を示すデータを記憶し、かつこのcグループを、実行されるコンテナと関連付ける。これらの経路又はcグループは、周辺デバイス接続データと呼ばれ得る。経路は、例えば、形式189:0、189:1、189:2などのLinuxのデバイスメジャー:マイナー番号形式のcグループに記憶されてもよい。次に、コンテナランタイムはこの情報を使用して、ポッド内のコンテナが、コンテナの実行時にデバイスにアクセスするために必要な権限を持っていることを確実にする。
【0140】
この一例として、デバイスプラグインは、各々が、‘/dev/dummy/1’、‘/dev/dummy/2’などで終わる経路を提供してもよく、これらの経路は、デバイスメジャー及びマイナー番号形式(189:0)、(189:1)などのcグループに記憶されてもよい。
【0141】
これは、クラス内の必要な数の周辺デバイスに対して実行され得る。したがって、コンテナcgroupは、ダミーデバイス経路を記憶し、これは、接続されている実際のデバイスによって必要とされるときにのみ、コンテナから見えるようになる。言い換えれば、対応するUSBポートに物理的に接続されているデバイスがある場合、コンテナは、依然として、デバイス‘/dev/bus/usb/001/002’が(189:1)に等しいことだけを見ることになる。
【0142】
これらのステップが実行されると、kubeletは、特定のポッド仕様(展開ファイル)に従って、(スケジューラによって決定されるように)ソフトウェアコンテナ要素を実行するように、コンテナ化されたランタイム要素に指示する。
【0143】
次に、コンテナランタイムは、展開ファイルで指定された画像ファイルをダウンロードして実行することにより、ソフトウェアコンテナ要素を提供する。ソフトウェアコンテナ要素は、実行時に、コンテナが、ソフトウェアコンテナ要素が各クラスと関連付けられた複数の所定の周辺デバイスの各周辺デバイスにアクセスし、かつそれと通信することを可能にする、周辺デバイス接続データと関連付けられるように、cグループと関連付けられる。
【0144】
展開ファイルには、ソフトウェアコンテナ及び必要なリソースの実行可能画像ファイルの表示が含まれる。これには、小売デバイスクラスなどのカスタムリソースが含まれる場合がある。当然のことながら、ソフトウェアコンテナの開始後にデバイスが接続されても、新しいデバイスが位置する経路がコンテナのcグループに定義されるため、デバイスはコンテナからアクセス可能となる。
【0145】
ソフトウェアコンテナが実行された後は、各露出したデバイス経路が、使用したいデバイスを表すかどうかを決定する責任を有する。これは、デバイス検出プロセスを実装するソフトウェアを使用することによって行うことができる。
【0146】
このようにして、実行されたソフトウェアコンテナは、クラスと関連付けられているどのデバイスがSSTに実際に接続されているかを決定する。次に、ソフトウェアコンテナは、接続された周辺デバイスの各々を初期化する。接続された周辺デバイスが初期化されると、ソフトウェアコンテナ要素は次に、周辺デバイスの各々にコマンドを送信し得る。
【0147】
デバイス検出プロセスを実装するソフトウェアは、所定の間隔でソフトウェアコンテナ内で実行されるように構成されている。しかしながら、本発明の特定の他の実施形態では、デバイス検出プロセスがまた連続的に実行され得ることが理解されよう。
【0148】
したがって、新しい周辺デバイスがプラグインされる実施例では、デバイス検出プロセスを使用して、この新しいデバイスが存在していることを決定し、その後、デバイスを初期化する責任を有する。次に、新しいデバイスは、上述したように、コマンドを送信し得る。
【0149】
当然のことながら、上述のように、周辺デバイス接続データと関連付けられたソフトウェアコンテナ要素を提供することによって、ソフトウェアコンテナは、所定のクラスと関連付けられた周辺デバイスのセットの各々にアクセスすることができる。
【0150】
したがって、コンテナが最初に実行されたときに、経路がコンテナのcグループに既に定義されているためにコンテナは依然としてこれらのデバイスにアクセスできるため、周辺デバイスが接続されているかどうかは重要ではない。
【0151】
このアプローチを取ることによって、ソフトウェアコンテナはまた、後日(ソフトウェアコンテナの実行後)にプラグインされる、又は(ソフトウェアコンテナの実行後に)アンプラグされ、かつリプラグされる、新しい周辺デバイスと通信することができる。このアンプラグ-リプラグイベントは、ソフトウェアアップデートの結果として仮想イベントとなる場合がある。
【0152】
したがって、ソフトウェアコンテナは、特権ありのアクセスを必要とせず、かつセキュリティを犠牲にすることなく、所定のクラスと関連付けられた全ての周辺デバイスといつでも通信する柔軟性を有する。
【0153】
図8は、周辺デバイス接続データと関連付けられたソフトウェアコンテナ要素が、セルフサービス端末(SST)上で初期化されたときに行われる、ある特定のステップのブロック図800を示す。
【0154】
SSTは、図1図7に示されるSSTのいずれかであってもよい。周辺デバイス接続データと関連付けられたソフトウェアコンテナ要素は、第2のソフトウェアコンテナ要素と呼んでもよい。第2のソフトウェアコンテナ要素は、SSTのプロセッサ(又は複数のプロセッサ)上で実行される実行可能な命令を含む。
【0155】
SSTが最初に展開されるとき、第1のステップS805は、SSTのスタートアップ時に初期化されるべきコンテナのインスタンスの構成を指定する1つ以上の展開ファイルを作成することを伴う。展開ファイルは、他のものの中でも、ソフトウェアコンテナを提供するためにダウンロード及び実行される画像ファイルの名前を指定する。
【0156】
展開ファイルは、また、どのリソースがコンテナによってアクセス可能になるかを指定する。展開ファイルが作成されると、展開ファイルは、SSTと通信するサーバ上で走っているKubernetesマスタのAPIサーバにアップロードされる。
【0157】
Kubernetesマスタは、図2又は図5に関して示されるのと同じマスタであってもよい。APIサーバは、展開ファイルを受信し、かつ展開ファイルを、Kubernetesマスタのetcdデータベースに記憶する。SSTが最初に展開されたときに実行される別のステップS810は、SSTによってアクセス可能なメモリにデータを記憶することを伴う。データは、例えば、SST上又はSSTと通信するサーバ上に記憶されてもよい。データは、あるクラスの周辺デバイスと関連付けられた特定の所定の周辺デバイスを示す。データは、構成マップとして記憶されてもよい。
【0158】
次のステップS815は、SSTの電源を入れることである。これは、店舗の開店時又は端末の再始動時など、毎日行われる場合がある。次いで、ホストOS及びKubernetesワーカ構成を含む、SST上のソフトウェアが、SSTのメモリからロードされ、SSTのプロセッサによって実行される。Kubernetesワーカ構成がロードされると、最初、走っているポッドはない。
【0159】
次のステップS820は、Kubernetesマスタのコントローラマネージャによって、etcdに記憶されている展開ファイルで指定されるようにSST上で走らせる必要があるポッドと、SST上で現在走っているポッドとの間の差異を検出することを伴う。
【0160】
ポッドによって必要とされるリソースがKubernetesワーカで利用可能であることを決定するために、Kubernetesワーカで利用可能なリソースもチェックされることになる。これには、RAMやCPUなどの標準リソース、及びデバイスプラグインによって処理されるカスタムリソースのチェックが含まれる。
【0161】
SST上で実行する必要があるポッドがないこと、及び好適なリソースが利用可能であることを検出することに応答して、KubernetesマスタのAPIサーバは、この不一致を解決するためにSST上のkubeletに情報を送信する。この情報は、SST上で実行される各ポッドのための展開ファイルを含む。Kubernetesオーケストレーションプラットフォームを使用しない、本発明のある特定の他の実施形態によれば、コンテナは、ポッド内で走らせる必要なしに実行され得る(これは、Kubernetesシステムの特定の特徴である)ことが理解されよう。
【0162】
次のステップS825は、kubeletによって、APIサーバからの情報を受信し、かつ展開ファイルをSST上のコンテナエンジン要素に渡すことを伴う。
【0163】
展開ファイルを受信することに応答して、次のステップS830は、コンテナエンジンによって、展開ファイルを読み取り、かつコンテナ画像レジストリから、展開ファイルで指定された実行可能な画像ファイルを要求することを伴う。
【0164】
次のステップS835は、次に、コンテナエンジンによってSST上でデバイスプラグインポッドを実行することを伴う。デバイスプラグインポッドには、デバイスプラグインコンテナが含まれる。デバイスプラグインコンテナは、第1のソフトウェアコンテナ要素と称されてもよい。第1のソフトウェアコンテナ要素は、SSTのプロセッサ(又は複数のプロセッサ)上で実行され得る実行可能なソフトウェアを含む。
【0165】
デバイスプラグインコンテナは、1つ以上の抽象的なクラスのデバイスをカスタムリソースとして露出し、これらのクラス内の全てのデバイスのデバイス経路情報を提供し、プラグアンドプレイデバイスサポートを有効にする責任を有する。実行後、デバイスプラグインコンテナが(リソースマネージャによって)呼び出され、そのカスタムリソースが報告される。リソースマネージャは、デバイスプラグインコンテナがKubernetesワーカ上で利用できるカスタムリソースを追跡する。
【0166】
次のステップS835は、kubeletのリソースマネージャによって、どの周辺デバイスがSSTに接続されているか、及びいくつの周辺デバイスがSSTに接続されているかに関するクエリをデバイスプラグインコンテナに送信することを伴う。
【0167】
本発明の特定の他の実施形態によれば、デバイスプラグインコンテナに利用可能なリソースは、リソースマネージャに自動的にアドバタイズされ得ることが理解されよう。
【0168】
このクエリに対する応答として、次のステップS840は、SSTに接続可能な周辺デバイスのクラスを示すデータを、kubeletのリソースマネージャに送信することを伴う。
【0169】
データは、デバイスプラグインコンテナから送信される。このクラスは、周辺デバイスの所定のセットと関連付けられている。このクラスは、<retail-devices>と呼ばれ得るリソースとしてアドバタイズされる。
【0170】
上述のように、クラス内のデバイスは、SST上のメモリ内の構成マップ内に定義されてもよい。リソースマネージャがこのデータを受信すると、次のステップS845は、リソースマネージャが、(SSTで実行されるようにリソースがスケジュールされている必要があるポッドに応答して)周辺デバイスの抽象的なクラスをコンテナ/ポッドに割り当てる準備ができるように要求することを伴う。
【0171】
この要求は、リソースマネージャによって、プラグインコンテナによって解釈されるコマンドとして、デバイスプラグインコンテナに送信される。このコマンドに応答して、次のステップS850は、デバイスプラグインコンテナによって、クラス内の各周辺デバイスのデバイス経路を示すデータを送信することを伴う。
【0172】
言い換えれば、デバイスプラグインコンテナは、デバイスの抽象的なセット/クラスに対する要求を、抽象的なセット/クラス内のデバイスを表す経路のセットに変換する。
【0173】
デバイス経路は、OSによって事前に決定される。このデータは、リソースマネージャによって受信される。このデータは、クラスと関連付けられた各所定の周辺デバイスに対して1つである、全ての可能な(既存及び将来の)デバイス経路のダミーリストを効果的に表す。このデータは、周辺デバイス接続データと呼ばれてもよく、かつソフトウェアコンテナと関連付けられてもよい。
【0174】
次のステップ855は、制御グループ(cグループ)内の特定の形式で周辺デバイス接続データを記憶することを伴い得る。したがって、制御グループ内のデータは、周辺デバイス接続データとも呼ばれ得る。
【0175】
リソースマネージャがデバイス経路データを受信すると、次のステップS860は、Kubeletが、クラス内のデバイスを、Kubernetesクラスタ上のコンテナが要求することができる利用可能なデバイスリソースであるとアドバタイズすることを伴う。次のステップS865は、Kubeletが、(コンテナエンジンの)コンテナランタイムに、第2のソフトウェアコンテナ要素を実行するように指示することを伴う。
【0176】
これは、図4のデバイスサーバコンテナであり得る。ステップ865は、周辺デバイス接続データを、実行されたソフトウェアコンテナと関連付けるステップ(図示せず)を更に含む。これは、制御グループ(周辺デバイス経路を示すデータを含む)をコンテナと関連付けることによって達成され得る。
【0177】
ソフトウェアコンテナは、展開ファイルをコンテナエンジンに渡すことによって実行される。コンテナエンジンは、展開ファイルを解釈し、展開ファイルで指定された画像ファイルをダウンロードし、かつ実行のために画像ファイルをコンテナランタイムに渡す。コンテナランタイムが画像ファイルを実行すると、それによって、第2のソフトウェアコンテナ要素が提供される。第2のソフトウェアコンテナ要素が提供されるとき、それは、コンテナエンジンにKubeletによって提供される周辺デバイス接続データと関連付けられる。
【0178】
上述のように、これは、コンテナをcグループと関連付けることによって達成され得る。当然のことながら、周辺デバイス接続データは、クラスと関連付けられた所定の周辺デバイスの各々に対する経路を表し、これは、kubeletによってアクセス可能なリソースとしてアドバタイズされている。
【0179】
次のステップS870は、第2のソフトウェアコンテナ要素が、クラスと関連付けられたどの周辺デバイスがデバイス経路リスト上の場所の各々で物理デバイスとして接続されているかを決定することを伴う。
【0180】
次のステップS875は、第2のソフトウェアコンテナ要素が第2のソフトウェアコンテナと周辺デバイスとの間の通信リンクを確立することを含む。リンクが確立される場合、次のステップS880は、SSTに接続された周辺デバイスの初期化を伴う。これは、対応するデバイス経路に沿って周辺デバイスと通信する第2のソフトウェアコンテナによって達成され得る。したがって、第2のソフトウェアコンテナは、物理デバイスを検出して管理することができる。
【0181】
次のステップS885では、デバイスが再接続されるか、又はSSTが動作中に新しいデバイスがSSTに接続される場合、第2のソフトウェアコンテナ要素は、ステップS870~S880に記載されるものと同様のステップに従うことによって、新しい又は再接続されたデバイスを検出する。
【0182】
その後、第2のソフトウェアコンテナは、新しいデバイスが第2のソフトウェアコンテナの初期化時に存在しないか、又は第2のソフトウェアコンテナの実行中に取り外されているにもかかわらず、関連するデバイス経路を使用して、新たに接続(又は再接続)されたデバイスを初期化し、かつそれと通信することができる。
【0183】
展開ファイルは、Kubernetesマスタ又はSST上で動作するコンテナエンジンによって利用されて、図8で論じたステップの一部を促すことができる。すなわち、コンテナエンジンは、所定のクラスと関連付けられた各周辺デバイスへのアクセス、及びそれとの通信を有するように構成されたソフトウェアコンテナ要素を提供するステップを開始するために、この展開ファイルを処理する。
【0184】
展開ファイルは、Kubernetesクラスタ内のコンテナを走らせるポッドの数及び構成を指定する。ポッド内の各コンテナは、展開ファイルで定義された画像のランタイムインスタンスである。コンテナの構成の一部は、実行されると、展開ファイルで定義された「リソース」によって決定される。一例として、コンテナは、実行されると、「スキャナデバイス」及び「表示デバイス」クラス内の全てのデバイスにアクセスできる場合がある。
【0185】
本明細書の記述及び特許請求の範囲全体を通して、「備える(comprise)」及び「包含する(contain)」という言い回し及びこれらの変形例は、「を含むが、これらに限定されない」ことを意味し、他の部分、添加物、構成要素、整数、又はステップを除外する(及び除外しない)ことを意図するものではない。本明細書の記述及び特許請求の範囲全体を通して、文脈上別段の解釈が要求されない限り、単数形は複数形を包含する。特に、不定冠詞が使用される場合、文脈上別段の要求がない限り、本明細書は、複数及び単数を企図するものとして理解されるべきである。
【0186】
好ましい実施形態及びこれらの様々な態様を参照して、本開示を具体的に示し、説明してきたが、当業者は、本開示の趣旨及び範囲から逸脱することなく、様々な変更及び修正がなされ得ることを理解されよう。添付の特許請求の範囲は、本明細書に記載される実施形態、上述の代替案、及びこれら全ての等価物を含むものとして解釈されることが意図される。
【0187】
本発明の特定の態様、実施形態、又は実施例と併せて記載される特徴、整数、特性、又は群は、これらとの互換性がない場合を除き、本明細書に記載される任意の他の態様、実施形態、又は実施例に適用可能であると理解されるべきである。
【0188】
本明細書(任意の添付の特許請求の範囲、要約、及び図面を含む)に開示される全ての特徴、並びに/又はそのように開示される任意の方法若しくはプロセスの全てのステップは、特徴及び/又はステップのうちの少なくともいくつかが相互に排他的である組み合わせを除いて、任意の組み合わせで組み合わせられてもよい。
【0189】
本発明は、任意の前述の実施形態のいかなる詳細にも限定されない。本発明は、本明細書(任意の添付の特許請求の範囲、要約、及び図面を含む)に開示される特徴の任意の新しい1つ、又は新しい組み合わせ、あるいはそのように開示される任意の方法又はプロセスのステップの任意の新しい1つ、若しくは任意の新しい組み合わせに及ぶ。
【0190】
尚、本出願に関連して本明細書と同時に、又は本明細書の前に出願され、かつ本明細書に関して一般に閲覧される全ての論文及び文献に向けられ、かかる全ての論文及び文献の内容は、参照により本明細書に組み込まれる。
図1
図2
図3
図4
図5
図6
図7
図8