サプライ・チェーン管理に関する業務データは、しばしば、理解又は可視化するために極めて詳細で複雑になる。利用可能なデータの総量は、しばしば、あまりにも大きすぎるので、1人がそれのすべてを読むことができない。非常に多くのデータがあるので、そのデータからの関連がある特徴を選定することは、時間がかかり、困難であり得る。
一般的な提示方法(たとえばスプレッドシート、チャート)は生の数値を示すのに対して、理解するための洞察(insight(s))は読者に委ねられているので、データの提示には課題がある。さらに、可視化及びグラフは、意味がある結果を解釈するために訓練された技能を必要とする。
したがって、最新の集計された業務データを容易に摘要可能な(easily-digestible)フォーマットで報告することは、サプライ・チェーンを補正及び/又は改善するために業務決定を行う際の効率を大いに改善するであろう。
現在、集計業務データを通信するには、書類報告、電話又は電子メール通信、及び対話型ダッシュボードの、3つの主要な手法がある。
書類報告には、それらがフレキシブルでないという問題がある。データは、さらにフィルタ処理、修正又は探査することができない。より多くの詳細が必要とされるか又は要求される場合、新しい報告を作成しなければならない。これは貴重な時間と財務資源とを使い尽くす。これらの報告では、しばしば与えられるデータが多すぎる結果、無関係な詳細が重要な態様及び洞察を不明瞭にする。しかしながら、与えられるデータが少なすぎる場合、管理職員はクリティカルな情報を見落とし得る。また、書類報告において与えられたデータはライブなものでない、すなわち、リアルタイムで更新されていかない。したがって、最も最新の業務メトリック(metric)が利用できなくなり、それにより意思決定プロセスが妨げられる。さらに、データは、しばしば、洞察を得るために訓練された技能を必要とするスプレッドシート、グラフ及び他の可視化の形態で表される。業務状況の意味がある知識を得るためにこれらの結果を解釈することを学習することは、時間がかかる困難なプロセスである。
電話又は電子メール通信は最新のメトリックの問題に対処することができる。しかしながら、その代わり、人的資源を使用コストがかかる。たとえば、そのような情報を報告するデータ・サイエンティストは、会話のために常に利用可能であるとは限らず、結果は遅延され得る。
対話型ダッシュボードは、それらが最新であり、フィルタ処理又は修正することができるので、普及している手法である。しかしながら、これらは、複雑な可視化の問題を解決せず、理解するためにより一層の訓練を必要とし得る。ダッシュボードはまた、すべての関連がある情報をデバイスのスクリーン上に収めるという新たな課題をもたらす。この手法はまた、ユーザがそれらの業務メトリックを消費する間、ユーザがマルチタスクすることを可能にしない。
US9977808B2は意図(intent)ベースのリアルタイム分析可視化を開示している。自然言語処理は、(可視化分析を生成するために使用される)受信された要件文から分析要件文を生成するために使用される。生成された可視化分析はコンピュータ生成のグラフィカル・ユーザ・インターフェース(GUI)上に表示される。
US2014351232A1は、自然言語ユーザ・インターフェースを使用して企業データにアクセスするための方法を開示している。モバイル・アプリケーションは、音声データをテキスト・データに変換し、これは、次いで業務アナリティクス・エンジンによる、又は企業検索エンジンによる使用のためのコマンドを生成するために使用される。いずれの場合にも、結果はユーザ・インターフェース上でユーザに提示される。
US9996531B1は、会話を管理するための方法、媒体及びシステムを開示している。そのシステムは、自然言語での情報を備える入力の受信のためのコンピュータ実装入力インターフェースと、入力の意図を決定し、意図を実現するための情報を決定するように構成されたダイアログ・マネージャと、意図及び識別された情報をドキュメント化する会話理解ドキュメントと、会話理解ドキュメントをダイアログ・マネージャとは独立した別個のタスク完了ハンドラに向けて転送する出力インターフェースとを含む。
US20180012163は、会話インターフェースによってセールス情報及び洞察を提供するための方法及びシステムを開示している。その方法及びシステムは、データ・ソースからのデータを処理し、業務のパフォーマンスをどのように改善するかについての示唆を提供するためにデータを分析する。
US10042882B2は、データ・ソースからアナリティクス・データを取り出すためのアナリティクス・プログラム・インターフェースを開示している。その方法は、アナリティクス・データを取り出すという要求を受信することと、第1のデータ・ソースからのアナリティクス・データについての第1のクエリを発行することと、第1のデータ・ソースとは異なる第2のデータ・ソースからのデータについての第2のクエリを発行することとを含む。その方法は、そのアナリティクス・データとそのデータとを提供することを含むことができる。
したがって、フレキシブルであり、常に利用可能であり、最新であり、理解することが容易であり、KPI、業務洞察などの関連情報のみを提供する、会話ツールを提供することと、将来の照会(すなわち将来のデータ/メトリックの要求)を予想することと、サプライ・チェーンにおける問題に対処するための協働を開始することとが有利である。
本開示は様々な変更及び代替形態を受けやすいが、特定の実施例又は実装形態が例として図面に示されており、それについて本明細書で詳細に説明する。しかしながら、本開示は開示されている特定の形態に限定されるものではないことが理解されるべきである。むしろ、本開示は、添付の特許請求の範囲によって定義されているように、発明の趣旨及び範囲内に入るすべての変更、等価物、及び代替物を包含するものである。
業務会話上で訓練される自然言語処理モデルと、業務洞察に優先度を付けるためのインテリジェント・アナリティクスと、洞察を会話様式で供給するデータ駆動型発話とを備える、会話業務ツールが本明細書で開示されている。
さらに、クラウド・サービスを使用することによって、メトリック会話業務は「常時オン」であり、ユーザが有する各照会についての最新メトリックを計算している。それは、任意の時刻に使用され得、即時の答えを提供する。そのツールは、ユーザの要求で、メトリックを再計算し、結果をフィルタリングし、さらなる詳細まで掘り下げることができる。関連があるデータが取得されると、それは自然な会話の流れを維持しながら、理解しやすい文に処理される。
会話業務ツールは、数だけでなく、結果の解釈を通信するためにデータ中のトレンド及びパターンを見つけるために、データの多くの可能なフィルタ組合せをチェックすることができる。多くの異なるシナリオ及び計画対象期間(time horizon)における予測をチェックすることによって、会話業務ツールはまた、ユーザに潜在的問題の早期検出を与え、問題の根本原因について示唆することが可能であり得る。会話業務ツールは、それの応答を構築し、ユーザ時間を節約することができる、次に尋ねられることを予想するために、議論されたことを追跡する。
会話の性質により、ユーザが取得することができる情報の量は、ほとんど無限であるが、ユーザは提示されているものを制御しているので、圧倒的なものでもない。言語は、特別な訓練又は課程が必要とされることなしに、誰でも直観的に理解することができるインターフェースである。同じインターフェース内で、ユーザは、協働を始めることによって会社内の他人にメッセージを送ることが可能であり得る。モバイル・デバイスへの統合により、ユーザは、KPIをチェックしながらマルチタスクを行うことができ、どこからでも業務データにアクセスすることができる。
図1は、会話業務ツール(10)の実施例のシステム・アーキテクチャの概観を示す。図2は、図1に示されたシステム・アーキテクチャのより詳細なビューを示す。
図1と図2の両方を参照すると、ユーザ(15)は、デバイス中の通信チャネル(20)を介して発声(utterance)を提供することによって会話を開始する。通信チャネルは、発声を自然言語プロセッサ(NLP)(25)に伝達する任意のタイプのチャネルであり得る。たとえば、通信チャネル(20)は会話仮想アシスタント(たとえばSiri(登録商標),Alexa(登録商標)、Cortana(登録商標)など)、Skype(登録商標)などであり得る。デバイスは、スマート・フォン、タブレット、ラップトップ、スマート・スピーカなどであり得る。NLP(25)は、意図及びエンティティなど、発声の態様を決定し、それらの態様は、次いで、実現アプリケーション・プログラミング・インターフェース(F-API)(30)に通信される。F-API(30)は意図を特定のデータ要求に変換し、それらのデータ要求は、次いで、業務データベース(35)と通信しているデータベースAPI(40)に通信される。データベースAPI(40)の例はRESTful APIを含む。特定の意図に関連するデータは、次いでデータベース(35)から取り出され、データベースAPI(40)を介してF-APIに送られ、F-APIは、洞察を引き出し、複数のケースをチェックし、目立つデータを見つける。F-APIは、次いで、この情報を会話形式に変換し、会話形式は、次いで、通信チャネル(20)を介してユーザ(15)に通信される。業務データベースは、より大きい業務ソフトウェア・プラットフォーム、たとえば、上記で定義されたような高速応答プラットフォームなど、サプライ・チェーン管理ソフトウェア・プラットフォームの一部であり得る。
図2Aは、NLPの機能を要約し、会話業務ツールの実施例の擬似コードを示す。NLPは、発声を正しい意図に分類するために訓練を受ける。訓練は、システムが意図を正しく識別したときは強化(reinforcement)を含み、それが誤っているときは負の強化(negative reinforcement)を含む。そのような訓練は、将来において会話業務ツールがユーザ発声を処理することを可能にする。
実現APIの擬似コードは、基本的にユーザ・クエリ(発声)を取り、意図を機能に一致させ、適切なデータを取得し、応答を形成し、その応答をユーザに送る。
図3は、複数の異なる顧客(55、60、65)が同時にツールを使用する、会話業務ツールの別の実施例のシステム・アーキテクチャ(50)を示す。特に、図3は、カスタマイズされた業務メトリックと複数の顧客とをサポートするためのスケーラブルなマルチテナント(multitenant)・アーキテクチャを示す。各顧客(55、60、65)は、その特定の顧客のためにカスタマイズされたそれぞれの個々のNLP(75、80、85)にアクセスする。各NLP(75、80、85)は、特定の顧客(76)のための識別で会話をマーキングしながら、共通の実現API(90)と通信し、F-APIは、それを使用して、それぞれの正しい顧客データベース(87、88、89)にデータ要求を正しくチャネリングする(95)。さらに、顧客のデータベースはエンティティ(91)の名前を顧客のNLP(75)に更新する。高速応答システムが使用される場合は、十分速く計算され得るデータ・リソースを生成するためにコマンド(92)が与えられる。
図4は、会話業務ツールの実施例のマスタ・フローチャートを示す。会話(100)は第1の発声(105)で始まり、第1の発声(105)は、データベースからのデータについての要求に変換され(110)、その後、第1の発声に対する応答(115)が続く。会話が不完全である場合、プロセスは、会話が終わるまで繰り返される。
図5は、5つのサブモジュール(200、205、210、215、220)を備える会話業務ツールの実施例の詳細なフローチャートを示す。ユーザ(225)は歓迎され、彼女又は彼が新規である場合は紹介(230)を与えられるか、又は、彼女又は彼が復帰である場合は再歓迎(235)される。現時点では、業務概要(200)を提供する会話モジュールと、特定のメトリック(205)に関する報告を提供する会話モジュールと、報告されたメトリックに寄与ファクタ(210)を提供する第3の会話モジュールとの、3つの利用可能な会話モジュールがある。モジュールは、ユーザ(225)の要求に応じて対話するように構成される。
たとえば、ユーザは、最初に業務概要(200)を要求し、その後、特定のメトリック(205)(たとえば収入、在庫など)について要求し、その後、そのメトリックのための寄与ファクタ(210)を要求し得る。又は、ユーザは、業務概要(200)を要求し、その後、特定のメトリックの寄与ファクタ(210)を要求し(すなわち、特定のメトリックについての要求をバイパスし)得る。又は、ユーザは、単に特定のメトリック(205)の概要を要求し、その後、そのメトリック(210)の詳細を要求し得る。
業務概要(200)は、メトリック(240)のリストを提供することができ、図8においてより詳細に説明するように、異なる範囲(245)におけるメトリックを分類し得る。
ユーザは、次いで、協働(220)が特定のメトリックに対処することを開始し得るように、特定のメトリックの責任者に連絡すること(235)を希望し得る。メッセージでの責任モジュール(215)は、ユーザによって確認され、次いで責任者に送られるメッセージを構成するために使用され得る。業務分析によって与えられた問題に対処する有資格者間の協働を開始するために、さらなる協働モジュール(220)が使用され得る。協働モジュール(220)は、サプライ・チェーン計画プラットフォームが協働をサポートするという条件で使用される。
図6は、図5に示されたモジュールがその中で使用される、会話業務ツールの一実施例における一連の会話ターンを備えるダイアログを示す。さらに、ツールは、業務メトリックとシナリオ・シミュレーションとの高速処理を行うサプライ・チェーン計画プラットフォーム、すなわち、上記で定義された「高速応答」プラットフォームと一体化される。
ユーザはその日の報告を要求した。概要は口頭で与えられるが、概要グラフィックは、ツールにアクセスするためにユーザによって使用されるデバイス上で与えられ得る。ユーザは、次いで、ツールと、上記で説明した高速返信サプライ・チェーン計画プラットフォームとの統合により、ツールが瞬時に提供することが可能である特定のメトリック(利用)の将来の予報を尋ねる。ユーザは、次いで、別の特定のメトリック(収入)の概要報告を要求し、その後、寄与ファクタを要求する。これは口頭で報告され、また、容易な可視化のためのグラフィック(すなわちパイ・チャート(pie chart))を含む。寄与ファクタに関するより多くの情報がユーザによって要求される。ツールはさらに2つのファクタで応答する。これらの応答は、ツールと上述のプラットフォームとの統合により、最新であり、瞬時である。
ユーザは、次いで、適切な要員に連絡するために要求の形態でアクションを要求する。ツールは、適切な連絡情報を与え、ユーザによる検討のためのドラフト・メッセージを構成する。確認されると、メッセージは送られる。ツールは、ユーザがさらに何かを要求するかどうかをチェックする。
図7は、図5に示された業務概要モジュール(200)を備えるサブルーチンのフローチャートを示す。このサブルーチンにおいて、基本的意図(305)が発声(300)から推論される。その意図は、意図の部類、たとえば、質問、データ取得のコマンド、応答などから選択され得る。意図(305)が推論されると、これが、データベース(310)からどのデータを取り出すかを確立するステップをトリガする。実現APIは最新のアップデートされたステータス・データをローカルに記憶する。意図(305)を識別した後、F-APIは、ステップ「ステータス更新」(315)によって示されているように、データベースへのコマンドを介してそれのデータのステータスを更新する。
データは、データ(320)の概観と、関連があるデータ(たとえば、収入、在庫、利用、マージン、KPIなどの業務メトリック)への洞察(insights)(325)との、2つの形態で取り出される。これは、次いで、通信チャネル(335)に伝達される会話応答(330)に設計される。応答に添付するグラフィック(340)を提供するオプションがある。ユーザは、次いで、会話を終了するべきか、さらなる質問を尋ね続けるべきかを決定する。
図8は、図7においてハイライトされたサブルーチン部分(350)のさらなる詳細を示す。業務概要ルーチンは一般的な口頭のクエリ(400)によって開始され、その例が上側ボックスに示されている。サブルーチンは、次いでメトリックのリストを取得し(405)、範囲によってメトリックをグループ化する(410)。例として、メトリックがオントラック(on track)(すなわちターゲットと比較して)であるかどうか、危険警告を是認するかどうか、又はクリティカルな状態にあるかどうかの3つの範囲(すなわち「オントラック」、「警告」、「クリティカル」)があり得る。各範囲におけるメトリックの内訳(415)が報告され得る。たとえば、所与の範囲にメトリックがない場合、この範囲はスキップされる(420)。その範囲に1つのメトリックがある場合(425)、ユーザ・インターフェースはその旨を返信する。その範囲に2つ以上のメトリックがある場合(430)、応答はその旨である。たとえば、範囲「オントラック」について、収入のみがオントラックである場合、会話ユーザ・インターフェースは「収入オントラック」と返信する。たとえば、収入及び在庫がオントラックである場合、会話ユーザ・インターフェースは「収入及び在庫がオントラック」と返信する。その後、サブルーチンは、それのターゲットに対して最も成績が低いメトリックについての詳細を取得する(435)。ユーザには、最も成績が悪いメトリックがターゲットを上回る(440)のか、ターゲットを下回る(445)のかが通知される。
図9は、図5に示されたメトリック詳細モジュール(205)を備えるサブルーチンのフローチャートを示す。
このモジュールにおいて、基本的意図(505)とエンティティ(510)の両方が発声(500)から識別される。たとえば、エンティティ(510)は収入であり得るが、意図(505)は、エンティティ(510)に関する「データ取得(get data)」であり得る。これは、エンティティ(510)に関する意図(505)機能を実行するようにツールに指令する。一例では、これは、収入についてのデータを取得することを意味し得る。たいていのエンティティは、異なる計画対象期間中に(たとえば、月間、四半期間、年間、現在、前年など)報告されるので、計画対象期間(515)は設定され、その後、ステータスが更新される(520)。
次いで、現在の計画対象期間についてデータが収集され(525)、将来の計画対象期間について計算されたデータも取り出される(530)。(計算されたデータを取得する)このステップは、将来のための適切なメトリックを計算するためにサプライ・チェーン計画プラットフォームにコマンドが送られることに依拠する。したがって、上記で説明したように、ツールが高速返信プラットフォームに一体化された場合に、意味がある結果が取得される。結果は、次いで比較され(535)、会話形式でユーザに中継される(540)。
図10は、図9において点線四角形によってハイライトされたサブルーチン部分(550)のさらなる詳細を示す。メトリック詳細サブルーチンは特定のメトリックについてのクエリ(600)によってトリガされ、エンティティはメトリック名である。メトリックの例は、収入、利用、マージン、在庫などを含む。サブルーチンは、連続的に実行される、計画対象期間を得るステップ(605)と、メトリック計算を得るステップ(610)と、年末計算を得るステップ(615)との、3つのステップを有することができる。最初に、計画対象期間が選定される(605)。計画対象期間は、月間、四半期間、年間、又は前年のデータであり得る。たとえば、バケットは、四半期間データ、年間データ、又は昨年のデータであり得る。「メトリック計算を得る」(610)は、メトリックについての計算された値をチェックし、実際の値と比較する。たとえば、「収入は620万ドルであるが、ターゲットは500万ドルである」。最後に、将来の予測(615)が、シナリオ・シミュレーションの結果を取り出すことによって与えられ、たとえば、「高速応答」などのサプライ・チェーン計画プラットフォーム中に見つけられ、ターゲット(620)と比較される。
図11は、図5に示されたメトリック寄与ファクタ・モジュール(210)を備えるサブルーチンのフローチャートを示す。
このモジュールは、メトリック(すなわちエンティティ)が識別されている(700)、業務概要モジュール(200)及び/又はメトリック詳細モジュール(205)のいずれかの後にアクセスされる。先行するダイアログは「コンテキスト」(705)として記憶されており、したがってエンティティ(700)はすでに識別されている。意図が推論される(710)。たとえば、意図(710)は質問(たとえば「なぜ」?)であり得る。推論されると、詳細な情報(715)がデータベースから取り出され、地域データ(720)及び製品ファミリー・データ(725)がそれぞれグループ化され、要約される。十分な概要及びグループ化は会話形式で報告され得るが、繰り返しを回避するために、前に伝達されていないデータ(730)のみが、会話形式(735)で、随意にグラフィック(740)とともにユーザに与えられる。
図12は、図11において点線四角形によってハイライトされたサブルーチン部分(750)のさらなる詳細を示す。意図及びエンティティ(800)は前に識別されており、したがって、メトリックのさらなる詳細/分析はこの寄与ファクタ・サブルーチンにおいて与えられる。メトリックがそれのターゲットから最も大きく外れているエリアを見つけるために、これらがユーザにとって最も関心が高いので、異なるフィルタ(たとえば地域ごとのフィルタ、部分ごとのフィルタなど)が、データに適用され得る。図12では、たとえば、地域フィルタ(805)及び部分フィルタ(810)が選択されている。選択されたメトリックについての、それらのそれぞれのターゲットから最も遠い地域及び部分(815)は、示されている発話例(820、825)によってユーザにハイライトされる。
図13は、図5に示された、メッセージでの責任モジュール(215)と協働モジュール(220)とを備えるサブルーチンのフローチャートを示す。この会話ターン中の発声(900)は、メトリック名と地域名と部分名のためのエンティティ(905)を含む。必要なパラメータ(910)が与えられると、モジュールは、データベース(920)に要求された責任者の名前を要求する(915)。そのような人(925)がデータベース(920)中に見つけられない場合、メッセージは送られない(935)。そのような人がデータベース(920)中に見つけられた場合(940)、ユーザによる検証(950)のためにドラフト・メッセージが構成される(945)。承認されると(955)、さらなるモジュールは、サプライ・チェーン計画プラットフォームが同時計画の形態で協働をサポートする(965)という条件で、任意のメトリック問題に対処するために、有資格者間の協働を開始することができる(960)。
図14は、図13において上側点線四角形(970)によってハイライトされたサブルーチン部分のさらなる詳細を示す。メッセージでの責任モジュールは、意図とメトリック名の特定のエンティティとの組合せ、及びメトリック(980)のフィルタ(図13では、地域フィルタ及び部分フィルタの例が使用されている)によってトリガされる。このモジュールのための発声(982)の例が最上部に与えられている。データベースから責任者(984)を取得することに成功した後、ツールは、情報をユーザに会話形式(986)で聞こえるように伝達する。この後に、(責任者に送る)ドラフト・メッセージ(988)、又は送られるメッセージを構成するためのユーザに対するクエリ(990)のいずれかが来る。
図15は、図13において下側点線四角形(975)によってハイライトされた協働サブルーチン部分のさらなる詳細を示す。協働モジュールは、意図と、メトリック名、地域名、部分名及びメッセージの特定のエンティティとの組合せによってトリガされる。このモジュールのための発声の例が最上部に与えられている。前のモジュールにおいて構成されたメッセージを送ることに成功した後、ツールは、協働が開始されたことの確認をユーザに伝達する。
開示された方法のうちのいくつかの動作は、便宜的なプレゼンテーションのために特定の順序で説明されるが、以下に記載する特定の文言によって特定の順序付けが必要とされない限り、説明のこの様式は並べ替えを包含することを理解されたい。たとえば、連続的に説明される動作は、場合によっては並べ替えられるか、又は同時に実行され得る。その上、簡潔のために、添付図は、開示された方法が他の方法とともに使用され得る様々な方法を示さないことがある。
上記のフローチャートに関するものを含む上記で説明したアルゴリズムについては別個に説明したが、本明細書で開示したアルゴリズムの任意の2つ又はそれ以上は任意の組合せで組み合わせられ得ることを理解されたい。本明細書で説明した方法、アルゴリズム、実装形態、又はプロシージャのいずれも、(a)プロセッサ、(b)コントローラ、及び/又は(c)他の好適な処理デバイスによる実行のための機械可読命令を含むことができる。本明細書で開示したどのアルゴリズム、ソフトウェア、又は方法も、たとえば、フラッシュ・メモリ、CD-ROM、フロッピー(登録商標)・ディスク、ハード・ドライブ、デジタル多用途ディスク(DVD)、又は他のメモリ・デバイスなど、非一時的有形媒体上に記憶されたソフトウェアにおいて実施され得るが、当業者は、アルゴリズム全体及び/又はそれの一部は、代替的に、コントローラ以外のデバイスによって実行され得、及び/又は、よく知られている様式でファームウェア又は専用のハードウェアにおいて実施され得る(たとえば、それは、特定用途向け集積回路(ASIC)、プログラマブル論理デバイス(PLD)、フィールド・プログラマブル論理デバイス(FPLD)、ディスクリート論理などによって実装され得る)ことを容易に諒解しよう。また、本明細書において示されたフローチャート中に表された機械可読命令のいくつかの又はすべては、コントローラ、プロセッサ、又は同様のコンピューティング・デバイス又は機械によって自動的に実装されるのとは反対に、手動で実装され得る。さらに、本明細書において示されたフローチャートを参照しながら特定のアルゴリズムについて説明したが、当業者は、例示的な機械可読命令を実装する多くの他の方法が代替的に使用され得ることを容易に諒解しよう。たとえば、ブロックの実行の順序は変更され得、及び/又は説明したブロックのいくつかは、変更、削除、又は組み合わせられ得る。
本明細書で示し、説明したアルゴリズムは、特定の機能を実行し、互いに対話する様々なモジュールを有することに留意されたい。これらのモジュールは、単に、説明のためにそれらの機能に基づいて分離され、また、コンピュータ・ハードウェア、及び/又は適切なコンピューティング・ハードウェア上での実行のためにコンピュータ可読媒体上に記憶された実行可能なソフトウェア・コードを表すことを理解されたい。異なるモジュール及びユニットの様々な機能は、ハードウェアとして、及び/又は任意の様式でモジュールとして上記のように非一時的コンピュータ可読媒体上に記憶されたソフトウェアとして組み合わせられるか又は分離され得、別個に又は組合せで使用され得る。
本開示の特定の実装形態及び適用を示し、説明したが、本開示は、本明細書で開示された正確な構成及び組成に限定されないこと、及び様々な変更、改変、及び変形は、添付の特許請求の範囲において定義されているように、発明の趣旨及び範囲から逸脱することなしに、上記の説明から明らかになり得ることを理解されたい。