(57)【要約】      （修正有）【課題】大規模ネットワーク用のスケーラブルでクラッシュ故障耐性を持つコンセンサスプロトコルのため、ネットワーク内でデータを暗号化し集約する方法及びリーダーノードを提供する。【解決手段】ネットワーク内でデータを暗号化し集約する方法は、リーダーノードが同期を実行する同期フェーズと、同期フェーズ後に実行する安定状態フェーズを含む。同期フェーズは、準備メッセージを送信するステップ、約束メッセージを受信するステップ、受け入れメッセージを送信するステップ、受け入れ済みメッセージを受信するステップを含む。安定状態フェーズは、第２の受け入れメッセージを送信するステップ、第２の受け入れ済みメッセージを受信するステップを含む。【選択図】図６
2019110531.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク内でデータを暗号化し集約する方法であって、
リーダーノードが同期を実行することを含み、該同期は、
提案番号を含み提案キーで暗号化され前記リーダーノードにより署名された準備メッセージを送信し、
各後続ノードから、前記提案番号、起動された命令番号、及びもしあれば最後の受け入れ済み提案を含み認証された暗号で暗号化された約束メッセージを受信し、
前記提案番号、前記起動された命令番号、及び前記最後の受け入れ済み提案を含み前記提案キーで暗号化され前記リーダーノードにより署名された受け入れメッセージを送信し、
前記提案番号及び前記命令番号のハッシュ並びに加法準同型暗号で暗号化された承認を含む受け入れ済みメッセージを受信し、
前記リーダーノードが安定状態フェーズを実行するステップを含み、前記安定状態フェーズは、
同期された前記提案番号、第２の増分された命令番号、及び前記要求からの取引値を含み前記提案キーで暗号化され前記リーダーノードにより署名された第２の受け入れメッセージを送信し、
同期された前記提案番号及び前記第２の命令番号のハッシュ並びに加法準同型暗号で暗号化された承認を含む第２の受け入れ済みメッセージを受信することを含む、方法。
【請求項２】
前記リーダーノードはツリートポロジーにおいて複数の後続ノードに接続されている、請求項１に記載の方法。
【請求項３】
前記リーダーノードはスタートポロジーにおいて複数の後続ノードに接続されている、請求項１に記載の方法。
【請求項４】
後続ノードが前記約束メッセージを送ることを更に含む、請求項１に記載の方法。
【請求項５】
第１の後続ノードが第２の後続ノードから副受け入れ済みメッセージを受信し、
前記副受け入れ済みメッセージのメッセージ認証コードを計算し前記第１の後続ノードの承認指標に前記副受け入れ済みメッセージの承認指標を付加することを更に含む、請求項１に記載の方法。
【請求項６】
前記ネットワークはブロックチェーンネットワークである、請求項１に記載の方法。
【請求項７】
前記リーダーノードが複数の後続ノードの証明書を保存することを更に含む、請求項１に記載の方法。
【請求項８】
前記リーダーノードは命令番号を記録するカウンターを備える、請求項１に記載の方法。
【請求項９】
単独で又は共同して以下のステップを実行する１つ又は複数のプロセッサを含むネットワーク内のリーダーノードであって、前記以下のステップは
前記リーダーノードが同期を実行することを含み、該同期は、
提案番号を含み提案キーで暗号化され前記リーダーノードにより署名された準備メッセージを送信し、
各後続ノードから、前記提案番号、起動された命令番号、及びもしあれば最後の受け入れ済み提案を含み認証された暗号で暗号化された約束メッセージを受信し、
前記提案番号、前記起動された命令番号、及び前記最後の受け入れ済み提案を含み前記提案キーで暗号化され前記リーダーノードにより署名された受け入れメッセージを送信し、
前記提案番号及び前記命令番号のハッシュ並びに加法準同型暗号で暗号化された承認を含む受け入れ済みメッセージを受信し、
安定状態フェーズを実行するステップを含み、前記安定状態フェーズは、
同期された前記提案番号、第２の増分された命令番号、及び前記要求からの取引値を含み前記提案キーで暗号化され前記リーダーノードにより署名された第２の受け入れメッセージを送信し、
同期された前記提案番号及び前記第２の命令番号のハッシュ並びに加法準同型暗号で暗号化された承認を含む第２の受け入れ済みメッセージを受信することを含む、リーダーノード。
【請求項１０】
更に複数の後続ノードの証明書を保存する、請求項９に記載のリーダーノード。
【請求項１１】
更に命令番号を数える、請求項９に記載のリーダーノード。
【請求項１２】
前記リーダーノードはツリートポロジーにおいて複数の後続ノードに接続されている、請求項９に記載のリーダーノード。
【請求項１３】
前記リーダーノードはスタートポロジーにおいて複数の後続ノードに接続されている、請求項９に記載のリーダーノード。
【請求項１４】
更に後続ノードにより送られた約束メッセージを受信する、請求項９に記載のリーダーノード。
【請求項１５】
前記ネットワークはブロックチェーンネットワークである、請求項９に記載のリーダーノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、大規模ネットワーク用のスケーラブルでクラッシュ故障耐性（crash fault-tolerant：CFT）を持つコンセンサスプロトコルのための方法及びシステムに関する。 
【背景技術】
【０００２】
ブロックチェーン技術は、分散されオープンでビザンチン故障耐性を持つ取引機構を提供する。ブロックチェーン技術は、匿名オンライン決済、送金、デジタル資産取引などの様々な種類のインターネット対話において一般的になりつつある。 
【０００３】
非常に多くの種類の異なるオープンブロックチェーンが存在する。様々な産業利用事例における許可ベースのブロックチェーンもまた一般的になりつつある。産業ブロックチェーンを含むブロックチェーンは、数百又は数千のノードをサポートするようにスケーラブルにされた強力なコンセンサス機構を有する分散型システムである。ただし、産業ブロックチェーンの場合一般的なブロックチェーンと比べてノードに対しより高い信頼を置く。このため、産業ブロックチェーンではノードはもっぱらクラッシュ故障していると仮定する場合がある。
【０００４】
複製サーバ間のコンセンサスを維持するため、信頼性を欠く通信路を持った分散型システムではクラッシュ故障耐性（ＣＦＴ）プロトコルが使用される。読み／書き操作におけるデータ整合性を保証するため、クラウドストレージのプロバイダーはPaxosコンセンサスアルゴリズムやRaftコンセンサスアルゴリズムなどのクラッシュ故障耐性を持つ変形物に依存する。しかしながら、既存のＣＦＴプロトコルは比較的小規模のネットワーク、すなわち、20以下のノードしか持たないネットワークにおけるアプリケーションにのみ適している。ブロックチェーンを用いた最近のアプリケーション及びシステムは、数千のノードからなる大規模ネットワークを有効に活用できる。 
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来のＣＦＴプロトコルをブロックチェーンネットワークに適用する際２つの主要な課題がある。 第１に、既存のＣＦＴプロトコルは全てリーダーノードを用いたブロードキャスト通信路に基づくものである。そのため、リーダーノードがネットワークにおいてボトルネックになる場合がある。第２に、ＣＦＴプロトコルを用いる場合、任意の２つのノード間のトランスポートレイヤーセキュリティ（Transport Layer Security：TLS）などの安全かつ認証された通信路が想定される。そのため、ノードの計算作業は他のノードへの接続回数とともに増加する。これは中継ネットワークでは特に煩わしくなる。中継ネットワークではノードの票をまず復号化し次の中継で再度暗号化する必要があるからである。
【課題を解決するための手段】
【０００６】
一実施形態では、ネットワーク内でデータを暗号化し集約する方法及びシステムが提供される。前記方法はリーダーノードが同期を実行することを含む。該同期は、提案番号を含み提案キーで暗号化され前記リーダーノードにより署名された準備メッセージを送信し、各後続ノードから、前記提案番号、起動された命令番号、及びもしあれば最後の受け入れ済み提案を含み認証された暗号で暗号化された約束メッセージを受信し、前記提案番号、前記起動された命令番号、及び前記最後の受け入れ済み提案を含み前記提案キーで暗号化され前記リーダーノードにより署名された受け入れメッセージを送信し、前記提案番号及び前記命令番号のハッシュ並びに加法準同型暗号で暗号化された承認を含む受け入れ済みメッセージを受信するステップを含む。前記方法は更に前記リーダーが安定状態フェーズを実行することを含む。前記安定状態フェーズは、同期された前記提案番号、第２の増分された命令番号、及び前記要求からの取引値を含み前記提案キーで暗号化され前記リーダーノードにより署名された第２の受け入れメッセージを送信し、同期された前記提案番号及び前記第２の命令番号のハッシュ並びに加法準同型暗号で暗号化された承認を含む第２の受け入れ済みメッセージを受信することを含む
【０００７】
別の実施形態では、ネットワーク内のリーダーノードであって、単独で又は共同して前記リーダーノードが同期を実行するステップを実行する１つ又は複数のプロセッサを含むリーダーノードが提供される。前記同期は、提案番号を含み提案キーで暗号化され前記リーダーノードにより署名された準備メッセージを送信し、各後続ノードから、前記提案番号、起動された命令番号、及びもしあれば最後の受け入れ済み提案を含み認証された暗号で暗号化された約束メッセージを受信し、前記提案番号、前記起動された命令番号、及び前記最後の受け入れ済み提案を含み前記提案キーで暗号化され前記リーダーノードにより署名された受け入れメッセージを送信し、前記提案番号及び前記命令番号のハッシュ並びに加法準同型暗号で暗号化された承認を含む受け入れ済みメッセージを受信するステップを含む。前記１つ又は複数のプロセッサは更に安定状態フェーズを実行する。前記安定状態フェーズは、同期された前記提案番号、第２の増分された命令番号、及び前記要求からの取引値を含み前記提案キーで暗号化され前記リーダーノードにより署名された第２の受け入れメッセージを送信し、同期された前記提案番号及び前記第２の命令番号のハッシュ並びに加法準同型暗号で暗号化された承認を含む第２の受け入れ済みメッセージを受信することを含む。
【図面の簡単な説明】
【０００８】
本発明を典型図に基づいて以下に更に詳細に説明する。 ただし、本発明は以下の典型的実施形態に限定されない。 本明細書で説明された特徴及び／又は図示された全ての特徴は、本発明の各実施形態において単独で用いてもよく、又は様々に組み合わせてもよい。本発明の様々な実施形態の特徴及び利点は、添付の図面を参照して以下の詳細な説明を読むことにより明らかになろう。
【０００９】
【図１】図１は、実施形態による検証ノードのシステム図を説明する。
【図２】図２は、実施形態によるツリーネットワークトポロジーを説明する。
【図３】図３は、実施形態によるスターネットワークトポロジーを説明する。
【図４】図４は、実施形態によるスーパーピアネットワークトポロジーを説明する。
【図５】図５は、一実施形態によるスケーラブルでクラッシュ故障耐性を持つプロトコルを示すシーケンス図である。
【図６】図６は、一実施形態によるスケーラブルでクラッシュ故障耐性を持つコンセンサスプロトコルを示すフローである。
【図７】図７は、一実施形態による処理システムのブロック図である。
【発明を実施するための形態】
【００１０】
コンピュータネットワークに固有で本発明の実施形態により解決される課題は、大規模ネットワーク用のスケーラブルで故障耐性を持つコンセンサスプロトコルを効率的に提供することである。実施形態はネットワーク用のスケーラブルでクラッシュ故障耐性を持つ（ＣＦＴ）プロトコルを提供する。いくつかの実施形態では、ネットワークはブロックチェーンネットワークである。ネットワークトポロジーはツリーであってもよくスーパースターであってもよい。これらの構成によりリーダーノードのネットワーク帯域幅などの計算負担が減少する。実施形態は、トランスポートレイヤーセキュリティ（ＴＬＳ）などの従来の安全な通信路を用いるのではなく、準同型に暗号化されたデータに基づく効率的なメッセージ集約方法を提供する。その結果、中継ノード間で認証さえ行えばよく、一方、ネットワークの票は再暗号化せずに直接集約することができる。更に、小規模ネットワークにのみ適合する既存のＣＦＴプロトコルに比べ、本発明の実施形態のスケーラブルなＣＦＴプロトコルは大規模ネットワークで用いることができ、特にブロックチェーンネットワークにおいてその課題にもかかわらず用いることができる。 
【００１１】
一実施形態では、システムはf個のクラッシュ故障した検証ノードを許容できると仮定すると、典型的なブロックチェーンネットワークはネットワークコンセンサスを維持するためにn=2f+1個の検証ノードを含んでいる。通信路に加えて、検証ノードはネットワーク内のノードの証明書を記録するキーストア、取引メッセージ内の命令を実行する状態機械、及び最新の命令番号を記録するカウンターを保持する。取引はネットワーク内にブロードキャストされ、検証ノードはコンセンサスアルゴリズムに従って次の取引（又は取引のブロック）に同意する。次の取引（又は取引のブロック）は台帳に記載される。各取引（又はブロック）は台帳内でその実行順を示す漸増命令番号Ikを有し、一方、取引（又はブロック）の内容はvkで表される。
【００１２】
図１は検証ノード１００を示す。検証ノード１００はキーストア１０２を含む。キーストア１０２はネットワーク内の各ノードの証明書を保存する。命令番号カウンター１０４は同じリーダーノードにより受信される取引メッセージ内の命令ごとに増分される。状態機械１０６は取引メッセージ内の命令を実行する。最後に、通信インターフェース１０８は検証ノード１００をネットワークに接続する。通信インターフェース１０８はEthernet、WiFi、セルラーなどの任意の適当なインターフェースであってよい。ネットワークはインターネット、ローカルエリアネットワーク、ワイドエリアネットワークなどの任意の適当なネットワークであってよい。
【００１３】
いくつかの実施形態では、（検証ノード１００などの）検証ノードはツリートポロジー又はスーパースタートポロジーに従って接続されてもよい。図２はツリートポロジー２００を示す。この実施形態では、リーダーノード２０２は検証ノードである。ネットワークツリー内のリーダーノードは検証ノード１００などの検証ノードである。残りのノード２０４はそれぞれこのツリーを形成する。ノード２０４は後続ノードとも呼ぶ。
【００１４】
本実施形態において、ポイント−ツーポイント接続のために、各検証ノード２０２は双方向認証用ペア単位メッセージ認証コード（ＭＡＣ）鍵数１を共有する。メッセージを提案し票を集める検証ノードはクラッシュ又は孤立化しない限り１つだけ存在する。検証ノードがクラッシュ又は孤立化した場合、後続ノードがネットワークを提案する、又は他のリーダーノードと新しいネットワークツリーを再構築する。このようにして、リーダーノード２０２はメッセージを提案し後続ノード２０４から票を集める。いくつかの実施形態では、リーダーノード２０２は、加法準同型暗号スキームの非対称鍵ペア(pk,sk)及び署名鍵ペア(pks,sks)を有しており、この場合、公開鍵は全ての後続ノード２０４に知られている。またリーダーノード２０２は全てのノードに共有される提案鍵kprを有する。この実施形態で、pk及びpksは公開鍵であり、sk及びsksは秘密鍵である。
【数１】
2019110531.tif 000003
【００１５】
一実施形態では、ノードは準備段階と受け入れ段階を持つ最後の状態において同期する。最後の状態とは、提案番号、命令番号、取引内の命令値などの受け入れ済み取引提案の状態を意味する。準備段階では、リーダーノード２０２は準備メッセージPrepare(n)（nは提案番号）を各後続ノード２０４に送る。提案番号はリーダーにより提案された過去のどのPrepareメッセージのものより大きくなくてはならない。準備メッセージは提案鍵kprで暗号化されリーダーノード２０２によりsksで署名される。このため、準備メッセージを伝搬する際静止したネットワークトポロジーに従う必要がなく、準備メッセージを任意のノードから転送して再処理を避けることができる。ただし、リーダーノード２０２だけが準備メッセージを起動することができる。一実施形態では、ある後続ノード２０４がPrepareメッセージを受信すると、当該後続ノードは受信した提案の番号が過去に約束されたどのメッセージのものより大きい場合にのみPromiseメッセージでリーダーノードに応答する。この約束メッセージは提案番号nを繰り返し（同じリーダーに対し）命令番号I0を初期設定する。また最後の受け入れ済み提案viがあればそれを含む。約束メッセージPromise(n,I0,vi)はペア型セッション鍵数１を用いる認証された暗号化手順に従う。
【００１６】
受け入れ段階では、リーダーノード２０２は、各後続ノードの約束から、最も大きな提案番号（第１鍵）及び命令番号（第２鍵）と関連付けられた値である最後の受け入れ済み提案値v０を引き出す。そしてリーダーノードは各後続ノード２０４が同期するように受け入れメッセージAccept(n,I0,v0)を後続ノード２０４に送る。準備メッセージと同様、受け入れメッセージはリーダーノードの署名とともに提案鍵kprで暗号化される。このメッセージが後続ノードの多数により受け入れられていることを確認するため、各後続ノードはメッセージAccepted(H(n,I0),bi)（biはノードiが受け入れた場合1になり拒否した場合0になる）で応答する。なお、H(・)はハッシュ関数であり、提案番号及び命令番号のハッシュだけが送られ、bは鍵を用いた加法準同型暗号（例えば、Paillierスキーム）で暗号化される。
【００１７】
また、受け入れ済みメッセージにはＭＡＣが付加される。あるノードがサブノードから受け入れ済みメッセージを受信した際それらは当該メッセージのＭＡＣを検証し再計算する必要があるのに対し、承認bは加法準同型暗号の結果としての暗号値を用いて要約することができる。最後にリーダーノードは票の合計を復号し、票が大多数である場合、システムはその時点で新しい命令を受け入れる用意ができている。
【００１８】
リーダーノード２０２が新しい要求を受信すると、受け入れメッセージAccept(n,Ik,wk)（命令番号Ikは新しい要求毎に増加する）の中で命令(Ik,wk)が後続ノード２０４に提案される。同期フェーズにおける受け入れ段階と同様、当該メッセージはリーダーの署名とともに提案鍵kprで暗号化される。その後各後続ノードがこのメッセージを受け入れると、受け入れ済みメッセージAccepted(H(n,Ik),b)で応答し同様のやり方で集約される。表１にはスケーラブルでクラッシュ故障耐性を持つプロトコルの一実施形態がまとめられている。
【００１９】
【表１】
2019110531.tif 000004
【００２０】
他のネットワークトポロジーを上記のスケーラブルでクラッシュ故障耐性のあるプロトコルとともに用いてもよい。例えば、図３はスタートポロジー３００を示す。リーダーノード３０２は後続ノード３０４に接続されている。同様に、図４はスーパーピアアーキテクチャ４００を示す。
【００２１】
図５は一実施形態によるスケーラブルでクラッシュ故障耐性を持つプロトコルを示すシーケンス図である。図示の実施形態はクライアント５０２、１つのリーダーノード５０４、及び２つの後続ノード５０６及び５０８を含む。クライアント５０２は取引を起動する。ただし、上記のように、様々な数のリーダーノード及び後続ノードを含む様々なネットワークトポロジーがサポートされる。
【００２２】
時刻tx0で、ノードの同期が始まる。リーダーノード５０４は準備メッセージPrepare(n)を後続ノード５０６及び５０８に送る。図示のように、後続ノード５０６はこの準備メッセージを受信しネットワーク内の次の後続ノードである後続ノード５０８に送信してもよい。
【００２３】
準備メッセージを受信すると、後続ノード５０６及び５０８はそれぞれ約束メッセージPromise(n,I0,v1 )及びPromise(n,I0,v2)をリーダーノード５０４に送信する。ただし、nより大きな提案番号を持つ提案は約束しない。本実施形態では、nは準備メッセージの提案番号である。ノードiが以前提案viを受け入れている場合、当該受け入れ済み提案viもノードiから送信される。図示のように、後続ノード５０６は約束メッセージの中で最後の受け入れ済み提案v1を、後続ノード５０８は約束メッセージの中で最後の受け入れ済み提案v2をリーダーノード５０４に送信してもよい。
【００２４】
約束メッセージを受信後、リーダーノード５０４は最後の受け入れ済み提案v0（v0={v1,v2}の中の最後）を引き出し、受け入れメッセージを後続ノード５０６及び５０８に送信する。
【００２５】
リーダーノード５０４は、約束メッセージを受信した後、受け入れメッセージAccept(n,I0,v0 )（nは準備メッセージの提案番号を表し、I0は命令番号を表し、vは最後の受け入れ済み提案を表す）を後続ノード５０６及び５０８に送信する。
【００２６】
受け入れメッセージを受信後、後続ノード５０６及び５０８は受け入れ済みメッセージAccepted(H(n,I0),bi)（nは準備メッセージの提案番号を表し、I0は命令番号を表し、承認biはノードiが受け入れた場合1、拒否した場合0である）を送信する。この場合、承認bは加法準同型暗号の結果としてのサブノードの暗号値で要約できるため、biは2である。この処理の後、リーダーノード５０４と後続ノード６０６及び５０８は同期する。
【００２７】
その後の時刻txjで、システムは安定状態にある。このとき、リーダーノード５０４は受け入れメッセージAccept(m,Ij,wj)（Mは安定フェーズにおける提案番号を表し、Ijは時刻txjにおける増加した命令番号を表し、wjは時刻txjにおける取引値を表す）を送信する。受け入れメッセージを受信後、後続ノード５０６及び５０８は受け入れ済みメッセージAccepted(H(m,Ij),bj)（Mは安定フェーズにおける提案番号を表し、Ijは時刻txjにおける命令番号を表し、承認bjはノードiが受け入れた場合1、拒否した場合0である）を送信する。この場合、承認bは加法準同型暗号の結果としてのサブノードの暗号値で要約できるため、biは2である。このように、図５における各メッセージは表１に示す暗号を用いて送信してもよい。
【００２８】
図６は一実施形態によるスケーラブルでクラッシュ故障耐性を持つコンセンサスプロトコルを示すフローである。段階６０２はプロトコルの同期フェーズにおけるステップを示す。段階６０４はプロトコルの安定状態フェーズにおけるステップを示す。
【００２９】
ステップ６０６で、リーダーノードは準備メッセージを送る。準備メッセージは提案鍵kprで暗号化され、リーダーノードによりsksで署名される。
【００３０】
ステップ６０８で、各後続ノードはこの準備メッセージを受信しリーダーノードに約束メッセージを返送する。約束メッセージは認証された暗号化ルーチンに従う。
【００３１】
ステップ６１０で、約束メッセージを受信したリーダーノードは各後続ノードへ受け入れメッセージを送信する。この受け入れメッセージはリーダーノードの署名とともに提案鍵kprで暗号化される。
【００３２】
ステップ６１２で、受け入れメッセージを受信した各後続ノードは受け入れ済みメッセージを返送する。この受け入れメッセージは鍵pkを用いた加法準同型暗号で暗号化される。また、受け入れメッセージにはＭＡＣが付加される。
【００３３】
プロトコルの同期フェーズが段階６０２で終了すると、プロトコルは段階６０４で安定状態フェーズに入る。ステップ６１４で、リーダーノードは各後続ノードに受け入れメッセージを送信する。上記のように、この受け入れメッセージはリーダーノードの署名とともに提案鍵kprで暗号化される。
【００３４】
ステップ６１６で、受け入れメッセージを受信した各後続ノードは受け入れ済みメッセージを返送する。この受け入れ済みメッセージは鍵pkを用いた加法準同型暗号で暗号化され、ＭＡＣが付加される。
【００３５】
図７は、一実施形態による処理システムのブロック図である。この処理システムを用いて上記のプロトコル、システム、及びノードを実装することができる。処理システムは計算装置や専用特定目的情報処理装置の中央処理装置（ＣＰＵ）などのプロセッサ７０４を含み、上記の機能及び方法を実行するシステムの実施形態を含むコンピュータ実行可能命令を実行する。実施形態では、これらのコンピュータ実行可能命令はローカルに保存され、ハードドライブやフラッシュドライブである場合がある非一時的コンピュータ可読媒体からアクセスされる。読み出し専用メモリ（ＲＯＭ）７０６はプロセッサ７０４を初期化するコンピュータ実行可能命令を含み、ランダムアクセスメモリ（ＲＡＭ）７０８はプロセッサ７０４により実行される命令を読み込み処理する主メモリである。ネットワークインタフェース７１２は、有線ネットワーク又はセルラーネットワーク及びローカルエリアネットワーク又はインターネットなどのワイドエリアネットワークに接続されてもよい。
【００３６】
本明細書で引用された出版物、特許出願、及び特許などの全ての参照文献は、各参照文献が参照により組み込まれていると個別にかつ具体的に示されその全体が本明細書に記載されている場合と同程度に参照により本明細書に組み込まれる。
【００３７】
本発明を図面及び上記説明において図示及び詳述したが、それらの図示や説明は一例又は典型例であり限定するものではないと解釈すべきである。 以下の請求の範囲内で当業者により変更及び修正が可能であることは理解されよう。 特に、本発明は上記及び下記の様々な実施形態の特徴の任意の組み合わせを有する更なる実施形態を含む。また、本発明を特徴づける本明細書の記述は本発明の一実施形態を意味し、必ずしも全ての実施形態を意味するものではない。
【００３８】
請求項で使われる用語は、上記の記述と一致する最も広い合理的な解釈で解釈されるべきである。例えば、構成要素を導入する際の冠詞「a」又は「the」の使用は複数の構成要素を除外するものと解釈すべきではない。同様に、「又は」の記載は、「A又はB」の記載がAとBのいずれかのみを意図することが文脈又は前述から明らかでない限り「A及びB」を除外しないように、包括的なものと解釈すべきである。また、「A、B、及びCのうちの少なくとも１つ」の記載は、A、B、及びCがカテゴリーその他として関連しているかどうかにかかわらず、A、B、及びCからなる構成要素の群のうちの１つ又は複数と解釈すべきであり、列挙した構成要素A、B、及びCのそれぞれの少なくとも１つを必要とすると解釈すべきではない。更に、「A、B、及び／又はC」若しくは「A、B、又はCのうちの少なくとも１つ」は、列挙された構成要素のうちの任意の単一の実体、例えば、A、列挙された構成要素のうちの任意のサブセット、例えば、A及びB、若しくは列挙された構成要素A、B、及びCの全体を含むと解釈すべきである。
【図１】
2019110531.tif 000005
【図２】
2019110531.tif 000006
【図３】
2019110531.tif 000007
【図４】
2019110531.tif 000008
【図５】
2019110531.tif 000009
【図６】
2019110531.tif 000010
【図７】
2019110531.tif 000011