(57)【要約】      （修正有）【課題】システム異常を検出し、コンピューティングシステムを置換するために互換性のあるモジュールを検出するためのシステム及び方法を提供する。【解決手段】ユーザとの予防的インタラクションのシステムは、クライアント側２０１、サーバ側２０２及び第３の側２０３を含む。クライアント側には、観察対象であるシステム１００が配置される。システム１００は、システムの少なくとも１つの要素２１０と、インストールされたクライアント２０５とを含む。サーバ側は、クライアント２０５とインタラクトし、第３の側から開発されたモデルを取得する。サーバ側では、取得したモデルのテストとそのランク付け、クライアントに関する統計の収集、設定ファイルの生成とクライアントのためのその更新およびモデルの開発のためのインフラストラクチャの提供が行われる。【選択図】図２Ａ
2020109635.tif 000002
【特許請求の範囲】
【請求項１】
システム異常を検出するためのコンピュータにより実行される方法であって、
第１のコンピューティングシステムの機能を特定するシステムパラメータを受信することと、
受信したシステムパラメータを使用して、前記第１のコンピューティングシステム内の異常を検出するために、状態モデルを問い合わせることと、
前記状態モデルに基づく前記第１のコンピューティングシステム内の異常の検出に応じて、
少なくとも１つの候補モジュールであって、前記第１のコンピューティングシステムのシステムパラメータを置換する同等のシステムパラメータを有する候補モジュールに基づいて、前記状態モデルの再問い合わせをすることと、
前記候補モジュールが前記第１のコンピューティングシステムと互換性があり、前記候補モジュールのシステムパラメータを用いた状態モデルの再度の問い合わせ中に異常が検出されなかった、とする判定に基づき、前記少なくとも１つの候補モジュールを選択すること、
を含む方法。
【請求項２】
前記少なくとも１つの候補モジュールは複数の互換性のあるモジュールを備え、
前記第１のコンピューティングシステムのユーザプロファイルに基づいて前記複数の互換性のあるモジュールのうち１つを選択することをさらに含む、請求項１に記載の方法。
【請求項３】
前記第１のコンピューティングシステムは、インターネット接続された複数のデバイスとインタラクトする基本要素を備える、請求項１に記載の方法。
【請求項４】
前記第１のコンピューティングシステムは、無線ネットワークによって通信可能に接続された１つの基本要素と複数の要素とを備え、前記基本要素に接続される要素の数は、特定の時点および前記基本要素の空間内の位置によって決定され、前記無線ネットワークへのアクセスを提供する無線局のカバレッジのゾーン半径に依存する、請求項１に記載の方法。
【請求項５】
前記状態モデルは、
前記第１のコンピューティングシステム内のコンピューティング要素のパラメータの関数である異常状態を検出する第１の規則と、
前記第１のコンピューティングシステムの要素の異常状態を決定するパラメータの関数である異常状態を検出する第２の規則と、
前記コンピューティング要素の状態の時間関数である異常プロセスを検出する第３の規則と、
前記第１のコンピューティングシステムの状態の時間関数である異常プロセスを検出する第４の規則と、
を有する一連の規則を含む、請求項１に記載の方法。
【請求項６】
前記システムの状態モデルは、使用および信頼性の変形のモデルの集合である、請求項１に記載の方法。
【請求項７】
前記状態モデルは、前記第１のコンピューティングシステムの無線ネットワークインタフェースのチャネル速度を特定する前記受信したシステムパラメータに基づいてチャネル速度劣化状態の異常状態を検出する規則を含む、請求項１に記載の方法。
【請求項８】
前記状態モデルは、前記第１のコンピューティングシステムの記憶装置の再割り当てセクタ数を特定する前記受信したシステムパラメータに基づいてストレージセクタ劣化状態の異常状態を検出する規則を含む、請求項１に記載の方法。
【請求項９】
前記状態モデルは、前記第１のコンピューティングシステムの無線ネットワークインタフェースの信号パワー値を特定する前記受信したシステムパラメータに基づいて信号パワー劣化状態の異常状態を検出する規則を含む、請求項１に記載の方法。
【請求項１０】
前記状態モデルに基づく前記第１のコンピューティングシステムにおける異常の検出に応じ、さらに、データベースに格納された回復方法のモデルを問い合わせる、請求項１に記載の方法。
【請求項１１】
システム異常を検出するシステムであって、
状態モデルを記憶するメモリデバイスと、
当該メモリデバイスに接続されるハードウェアプロセッサと、を含み、
前記ハードウェアプロセッサは、
第１のコンピューティングシステムの機能を特定するシステムパラメータを受信し、
受信したシステムパラメータを使用して、前記第１のコンピューティングシステム内の異常を検出するために、状態モデルを問い合わせ、
前記状態モデルに基づく前記第１のコンピューティングシステム内の異常の検出に応じて、
少なくとも１つの候補モジュールであって、前記第１のコンピューティングシステムのシステムパラメータを置換する同等のシステムパラメータを有する候補モジュールに基づいて、前記状態モデルを再問い合わせし、
前記候補モジュールが前記第１のコンピューティングシステムと互換性があり、前記候補モジュールのシステムパラメータを用いた状態モデルの再度の問い合わせ中に異常が検出されなかった、とする判定に基づき、前記少なくとも１つの候補モジュールを選択する
よう構成される、システム。
【請求項１２】
前記少なくとも１つの候補モジュールは複数の互換性のあるモジュールを備え、
前記ハードウェアプロセッサはさらに、
前記第１のコンピューティングシステムのユーザプロファイルに基づいて前記複数の互換性のあるモジュールのうち１つを選択する、請求項１１に記載のシステム。
【請求項１３】
前記第１のコンピューティングシステムは、インターネット接続された複数のデバイスとインタラクトする基本要素を備える、請求項１１に記載のシステム。
【請求項１４】
前記第１のコンピューティングシステムは、無線ネットワークによって通信可能に接続された１つの基本要素と複数の要素とを備え、前記基本要素に接続される要素の数は、特定の時点および前記基本要素の空間内の位置によって決定され、前記無線ネットワークへのアクセスを提供する無線局のカバレッジのゾーン半径に依存する、請求項１１に記載のシステム。
【請求項１５】
前記状態モデルは、
前記第１のコンピューティングシステム内のコンピューティング要素のパラメータの関数である異常状態を検出する第１の規則と、
前記第１のコンピューティングシステムの要素の異常状態を決定するパラメータの関数である異常状態を検出する第２の規則と、
前記コンピューティング要素の状態の時間関数である異常プロセスを検出する第３の規則と、
前記第１のコンピューティングシステムの状態の時間関数である異常プロセスを検出する第４の規則と、
を有する一連の規則を含む、請求項１１に記載のシステム。
【請求項１６】
前記システムの状態モデルは、使用および信頼性の変形のモデルの集合である、請求項１１に記載のシステム。
【請求項１７】
前記状態モデルは、前記第１のコンピューティングシステムの無線ネットワークインタフェースのチャネル速度を特定する前記受信したシステムパラメータに基づいてチャネル速度劣化状態の異常状態を検出する規則を含む、請求項１１に記載のシステム。
【請求項１８】
前記状態モデルは、前記第１のコンピューティングシステムの記憶装置の再割り当てセクタ数を特定する前記受信したシステムパラメータに基づいてストレージセクタ劣化状態の異常状態を検出する規則を含む、請求項１１に記載のシステム。
【請求項１９】
前記状態モデルは、前記第１のコンピューティングシステムの無線ネットワークインタフェースの信号パワー値を特定する前記受信したシステムパラメータに基づいて信号パワー劣化状態の異常状態を検出する規則を含む、請求項１１に記載のシステム。
【請求項２０】
システム異常を検出するためのコンピュータ実行可能命令を含む非一時的コンピュータ可読媒体であって、前記命令は、
第１のコンピューティングシステムの機能を特定するシステムパラメータを受信し、
受信したシステムパラメータを使用して、前記第１のコンピューティングシステム内の異常を検出するために、状態モデルを問い合わせ、
前記状態モデルに基づく前記第１のコンピューティングシステム内の異常の検出に応じて、
少なくとも１つの候補モジュールであって、前記第１のコンピューティングシステムのシステムパラメータを置換する同等のシステムパラメータを有する候補モジュールに基づいて、前記状態モデルの再問い合わせをし、
前記候補モジュールが前記第１のコンピューティングシステムと互換性があり、前記候補モジュールのシステムパラメータを用いた状態モデルの再度の問い合わせ中に異常が検出されなかった、とする判定に基づき、前記少なくとも１つの候補モジュールを選択する
ための命令である、媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、デバイスおよびシステムにおいて、既存のまたは予想される状況（condition）または状態（state）を処理するための方法およびシステムに関する。
【背景技術】
【０００２】
企業や起業家は、自社の製品を宣伝するために広告サービスを利用する。広告とは、非パーソナライズされていて通常は有料の説得性のある広告主の商品およびサービスまたはアイデアに関する情報の、様々な媒体を介した配信である。インターネットの発展に伴い広告もインターネット上に進出している。最新のデータによると、広告の２０%以上がインターネット上で行われている。
【０００３】
広告は、通常、個人向けにカスタマイズされておらず、広告のターゲットを不特定多数の人々にしているため、有効性が実際に得られ得るものよりも低くなっている。このため、生産者は、ユーザ群全体から個々のグループを選び出し、グループごとに計算された自社の広告を各グループに提示するよう努めている。これは、ターゲット広告として知られている。ターゲット広告は、ウェブページのコンテンツではなく、ユーザの過去の行動または調査データに基づいて特定された特定のユーザグループに紐づけられた広告ステートメント（プレゼンテーション）である。適応ランタイム広告に対する既知のアプローチでは、検索クエリ、プロファイル、ユーザのネットワークアプリケーションからのデータなどの分析に基づいて広告メッセージを示す。しかしこの場合、広告は、実際のユーザの需要ではなく、その需要可能性に適応させたものである。このため、広告ステートメントの種類は、製品又はサービスの消費者の数よりも著しく少ない。
【０００４】
インターネットが発展していく中で、ユーザに対する広告配信方法自体も変化した。ユーザは、ネットサーフィン中だけでなく、ネットワークや情報ボードにアクセス可能なアプリケーションにおいて、通勤途中や帰宅途中にも広告に遭遇する。広告には、その広告されている製品を必要としないユーザには煩わしいものであるために、ユーザが広告を伴うアプリケーションおよびウェブリソースを回避しようとする、という重大な欠点がある。ユーザが実際に製品を必要とする場合でも、広告があまりにも侵襲的だと、ユーザは競合他社製品にリダイレクトするかもしれない。
【０００５】
このように既存の広告は効率が悪いため、ユーザに関する情報の収集および送信ならびにプロファイリングが行われているが、こうした行為は法的リスクを伴う可能性がある。広告はユーザを煩わせるため、ユーザは広告を伴うアプリケーションを避けようとするが、これは広告を通じて収益を得るアプリケーションにとって深刻な問題である。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本開示の態様は、状況（condition）を安定化するか、または要求される状態（state）にすることを可能にする製品を決定するように構成される。
【０００７】
本開示の技術的成果は、異常のあるシステムと互換性のあるモジュールを検出する方法を実行することによって、異常のあるシステムと互換性のあるモジュールを検出可能にすることであり、システムパラメータはシステムの機能を実現する要素から取得され、取得されたパラメータはシステムの状態モデルを問い合わせるために使用される（特定の例では、問い合わせ中に、収集されたパラメータとシステムの想定される状態との対応関係が確立される）。パラメータはリアルタイムで取得することができる。または、パラメータはシステムの要素のうちの１つ（基本要素）にインストールされたクライアントによって取得される。システムの要素は、ソフトウェア、ハードウェア、ハードウェア／ソフトウェア、および有機体であってもよい。１つの特定の例における基本要素は、システムのコンテキストにおいてIoTデバイスとインタラクトするパーソナルコンピュータデバイスであってもよい。１つの特定の例では、パラメータが取得されているシステムは、動的であり、無線ネットワークによって統合された要素から構成されている。基本要素に接続される要素の数は、特定の時点および基本要素の空間内の位置によって決定され、その時の無線ネットワークへのアクセスを提供する無線局のカバレッジのゾーン半径に依存する。状態モデルを問い合わせることによって、システムおよびその要素における状態およびプロセスの要件間の対応関係が評価される。モデルは、以下を検出するために一連の規則を制定することができる:
・要素のパラメータの関数である、要素の異常状態；
・システムの要素の異常状態を決定するパラメータの関数である、システムの異常状態；
・要素の状態の時間関数である、要素の異常なプロセス;
・システムの状態の時間関数である、システムの異常なプロセス。
【０００８】
別の例では、システムの状態モデルは、使用および信頼性の変形のモデルを集約したものである。
【０００９】
モデルの問い合わせの結果として、異常が検出され、異常が関数であるシステムパラメータが決定される。異常は少なくとも以下のものであってもよい:
・要求される状態から逸脱し、要素のパラメータの関数である要素の状態;
・要求される状態から逸脱し、要素の状態の関数であるシステムの状態;
・要求されるプロセスから逸脱し、要素の状態の時間関数である要素のプロセス;
・要求されるプロセスから逸脱し、システムの状態の時間関数であるシステムのプロセス;
・システムがインタラクトしている環境の状態であって、要求される状態から逸脱し、システムのパラメータによって記述可能な状態;
・システムがインタラクトしている環境のプロセスであり、要求されるプロセスから逸脱し、システムのパラメータによって記述可能なプロセス。
【００１０】
異常は例えば、そのパラメータが異常を定義するシステムのクラスまたは要素によって追加的に記述されてもよい。検出された異常は機能の異常に関連してもよい。ここでいう機能の異常とは、所定の機能を実行するシステムまたはシステムの要素の能力が低下または喪失することである。
【００１１】
異常を検出して対応するパラメータを決定した後、少なくとも１つの外部モジュールのパラメータを取得し、システムの要素から取得したパラメータを用いて状態モデルをもう一度問い合わせるが、この時、異常が関数であるシステムのパラメータは外部システムの同等のパラメータによって置換される。状態モデルの再度の問い合わせの結果として、（ｉ）システムと互換性があり、（ｉｉ）当該モジュールのパラメータを用いた状態モデルの再度の問い合わせ中に異常が検出されなかった、少なくとも１つの外部モジュールを検出する。なお、少なくとも２つのシステムを検出する際、モジュールは、システムのユーザプロファイル、モジュールのプロバイダの評判、または、モジュールの製造者の評判に基づいて選択されることに留意されたい。
【００１２】
上記の例示的な態様の簡略化された概略は、本開示の基本的な理解に役立つ。この概要は、すべての企図された態様の包括的な概観ではなく、すべての態様の重要なまたは重大な要素を識別することも、本開示のいずれかまたはすべての態様の範囲を画することも意図していない。その唯一の目的は、以下のより詳細な開示の説明の前置きとして、１つまたは複数の態様を単純化された形態で提示することである。前述のことを達成するために、本開示の１つまたは複数の態様は、特許請求の範囲に記載され例示的に指摘された特徴を含む。
【図面の簡単な説明】
【００１３】
本明細書に組み込まれ、その一部を構成する添付の図面は、本開示の１つまたは複数の例示的な態様を示し、詳細な説明とともに、それらの原理および実装を説明するものである。
【００１４】
【図１】図１は、観察可能な動的システムの変形例を示す図である。
【図２Ａ】図２Ａは、ユーザとの予防的インタラクションのシステムを示す図である。
【図２Ｂ】図２Ｂは、ユーザとの予防的インタラクションのシステムと観察可能な動的システムとの間の関係を示す図である。
【図３Ａ】図３Ａは、異常があるシステムと互換性のあるモジュールを決定する方法を示す図である。
【図３Ｂ】図３Ｂは、互換性のあるモジュールの検出方法を示す図である。
【図４】図４は、本開示の例示的な実施形態を示す図である。
【図５】図５は、コンピュータシステムの一例を示す図である。
【発明を実施するための形態】
【００１５】
本開示は、広告のランダムな性質を放棄し、課題および課題解決のための最も効果的な方法として、広告メッセージをユーザ通知に変換する。本開示の態様により、不確定性および蓋然性を回避することができる。このため、本提案は、広告というよりも、ユーザ通知予防システムであり、とりわけ、情報提供に費やされるリソースを低減し、情報を実際に必要とする人々のために実行する。広告はユーザの好みや見込まれるニーズを決定し、ユーザが関心を持ち、必要としそうな製品またはサービスに関する情報をユーザに送信する。本開示は、ユーザの環境を監視し、実際の問題（または今にも発生しそうな問題）および実際のニーズを発見し、これに関する情報を提供し、特定の製品またはサービスの取得を含む、実施できる可能な解決策を提案する。
【００１６】
平均的なユーザはデバイスに関する多くの技術的な問題を予測することができない。このようなユーザは、発生している又は発生した問題を解決するために製品の特性を評価できる程の十分な技術的知識がないが、製造業者はこのような情報を持っている。しかし、製造業者は、製品を必要とするユーザを把握していないため、確率的・統計的手法で市場調査を行って調査モデルを構築しなければならない。本開示は、デバイスおよびその環境（モノのインターネット（IoT）を含む）における問題を検出することができ、その問題に対する有効な予防的解決策を見つけることができる。このシステムは、追加モジュールのインストールを必要とせず、例えばアンチウィルスソフトウェアなどの実際のクライアントによって実現される。
【００１７】
本解決策は少なくとも、エレクトロニクス、情報技術（IT）プロバイダ、ITサービス、医療製品、ヘルスケア・プロバイダ、ヘルスケア製品およびサービスプロモーション、労働市場製品およびサービス、修理および建設の材料およびサービス、清掃サービス、ならびに食料品を販売促進するために使用することができる。
【００１８】
「システム」とは、互いに関係し接続された要素の集合であり、明確な全体または一体を形成する。システムは、設計上インタラクトする要素のセットであり、システムの要素はサブシステムとして知られる別のシステムであってもよい。システムは制御するシステムであっても制御されるシステムであってもよく、ハードウェア（例えばデバイス）、ソフトウェア（例えばプログラム）、および人間とのインタラクション（つまり人間はシステムの要素でありうる）または他の生物学的有機体とのインタラクションを含んでもよい。これらの要素は、全体としての機能的タスクを実行するように統合される。設計上、（例えば、FURPS＋分類ごとに）システムに要件が課される：
・機能性または機能要件：特性、性能、セキュリティ。これらは、ユースケース図を構築するために使用される主要な要件である。
・ユーザビリティまたは利便性（UX）に関する要件：ヒューマンファクター、美的外観、一貫性、文書化。
・信頼性またはディペンダビリティに関する要件：起こり得るクラッシュの頻度、故障に対する耐性、回復可能性、安定性の予測可能性。
・性能または生産性に関する要件：応答時間、資源使用、有効性、パワー、スケーラビリティ。
・サポート可能性またはサポートに関する要件：サポートの可能性、修復可能性、柔軟性、変更可能性、モジュール性、拡張可能性、ローカライゼーションの可能性。
【００１９】
設計に従って実現されるシステムは、その機能中に設計要件を満たさなければならない。要件の特定の例は、システム／要素が所与の時間に提供すべき性能（例えば、FPSに対する要件、または少なくとも１０人のユーザから毎秒１００個のリクエスト等）である。
【００２０】
「システムの要素の状態」は、所与の時間におけるシステムの要素の属性セットであり、要素のパラメータの関数である。
【００２１】
「システムの状態」は、所与の時間におけるシステムの属性セットであり、システムのパラメータの関数である。これはまた、所与の時間におけるシステムの要素の状態の集合として定義される。
【００２２】
「プロセス」は、所定の時間間隔におけるシステムの要素の属性の変化、または、システム全体の属性の変化であり、状態の時間関数である。
【００２３】
（要素、システム、またはプロセスの）「パラメータ」は、プロセス、現象、（デバイス、ソフトウェア、有機物を含む）要素、またはシステムの特定の属性を特徴付ける量である。定量的には、全ての所与のシステムは、２つのクラスに分類可能な定量の集合によって記述できる。２つのクラスとは、すなわち、システムの一次属性を記述する、システムの調査のための初期データであるパラメータ（п）と、システムの二次属性を記述する、システムのパラメータの関数として決定される特性（X）と、である：X=f(п)。
【００２４】
システムのパラメータは、システムの構造的及び機能的構成を記述するシステムの内部パラメータと、システムと（システムに関する）環境とのインタラクションを記述するシステムの外部パラメータとに細分される。内部パラメータは、システムの要素の構成およびその実際の構造を記述する構造パラメータと、システムの機能構成（機能プロセス）を記述する機能パラメータと、を含む。外部パラメータには、例えば、システムのリソースの使用頻度および使用量を示す作業負荷パラメータが含まれる。一般的な場合、これらが、システムとその環境とのインタラクションのパラメータである
【００２５】
システムの特性は、システム全体としての機能の有効性を示すグローバル特性と、システムの個々の要素の機能の質を記述するローカル特性とに分けられる。システムのグローバル特性は、システムの所望の目的を達成する速度を示すパワー特性または生産性特性と、システムの機能の時間的側面を記述する時間特性と、システムの機能の信頼性を定義する信頼性特性と、システムの使用の経済的実現可能性を示すコスト指標による経済特性とを含むことができる。
【００２６】
上述したことから、実際にはパラメータと特性とが区別されることは明らかである。特性は、少なくとも１つのパラメータの関数である。本出願では、パラメータおよび特性の双方に「パラメータ」という用語を使用しこれらを区別しないものとする。
【００２７】
「異常」とは、要件からの逸脱である。要件は例えば、ハードウェア／ソフトウェア複合体の設計要件、または公衆衛生要件とすることができる。要件からの逸脱は、状態またはプロセスであってもよい。したがって、異常な状態とプロセスとを区別する。異常なプロセスの特定の例は漸進的な故障であり、一方、異常な状態は、突然の故障またはクラッシュである。異常は、少なくとも１つのパラメータの要件からの逸脱によって引き起こされてもよく、そのパラメータはまた、異常または異常パラメータである。
【００２８】
「モデル」とは、特定の形式（例えば、数学的、物理的、記号的、図像的、または記述的な形式）での現実の抽象表現であり、その現実の特定の態様を表すように構成され、検討中である質問に対する答えを生成することができる。モデルは、状態、プロセス、異常（異常な状態、プロセス、およびパラメータ）、当業者（ユーザ）、および製品（デバイス、ソフトウェア、サービス）を記述することができる。この形式は、テンプレート、従来の式、規則（入力の出力へのマッピング）、ニューラルネット、決定木などを使用して表現することができる。
【００２９】
「動的システム」とは、その要素の数が一定ではなく、基準点（基本要素）としてとらえられる空間内の要素の位置、および、時分によって決定されるシステムである。例えば、動的システムは、無線ネットワークにより統合される（ハードウェア／ソフトウェアの形態で実現される）要素から構成され、基本要素に接続される要素の数は、時分と空間内の基本要素の位置とによって決定され、その時の無線ネットワークへのアクセスを提供する無線局のカバレッジのゾーン半径に依存する。動的システム１００の一例を示す図１については以下で説明する。
【００３０】
図２Ａは、ユーザとの予防的インタラクションのシステム２００を示す図である。システム２００は、クライアント側２０１、サーバ側２０２、および第３の側２０３を含む。クライアント側には、観察対象であるシステム１００が配置される。システム１００は、システムの少なくとも１つの要素２１０と、インストールされたクライアント２０５（基本要素２０４）とを含む。クライアント２０５は、システムのパラメータを収集し、サーバ側とインタラクトするように構成されてもよい。第３の側には、モデル開発、製品説明/仕様等のためのソフトウェア／ハードウェアが配置される。サーバ側は、クライアント２０５とインタラクトし、第３の側から開発されたモデルを取得する。サーバ側では、取得したモデルのテストとそのランク付け、クライアントに関する統計の収集、設定ファイルの生成とクライアントのためのその更新、および、モデルの開発のためのインフラストラクチャの提供が行われる。
【００３１】
クライアント２０５は、収集モジュール２０６と、分析モジュール２０７と、データベース２０８とを含む。クライアントは、インストールモジュール２０９を含んでもよい。収集モジュール２０６は、システム１００のパラメータ、特定の一例ではテレメトリを収集するように構成することができる。分析モジュール２０７は、パラメータを状態およびプロセスに変換し、パラメータ、状態、およびプロセスを分析して異常を発見する。分析モジュール２０７による分析は、状態モデルなどのモデルを問い合わせるモジュールによって行われる。このモジュール２０７はまた、異常を分析して回復方法を決定し、回復方法が実行されることを可能にするモジュールを発見し、そのためにモデルも問い合わせられる。分析モジュール２０７は、任意に、サーバ側に配置することができる。インストールモジュール２０９は、回復方法を実現するソフトウェアを実装するように構成されてもよい。データベース２０８はパラメータ及び状態を格納し、プロセスは時間に伴う状態の変化であるため、要素及びシステムにおけるプロセスに関する情報を分析モジュール２０７が取得することを可能にする。
【００３２】
第３の側では、開発モジュールは製品（サービスを含む）の説明を作成し、モデルを生成し、結果をサーバ側に送信する。開発モジュールは、サーバ側およびクライアント側のモジュールによってサポートされるフォーマットで人間によって容易に理解される製品の記述を形式化し、形式化された記述に基づくモデルを含むモデルを生成し、結果をサーバ側に送信するためのフレームワーク２１２および他のソフトウェアを含むことができる。
【００３３】
サーバ側は、クライアント側との通信のためのインタフェース２１４およびサードパーティ開発モジュールとの通信のためのインタフェース（２１６）を提供する。開発インフラストラクチャ２１８は、サーバ側で実現され、少なくとも、ランキングモジュール２２０、テストモジュール２２２、および統計収集モジュール２２４を含む。
【００３４】
ランキングモジュール２２０は、特定のクライアントに送信され、分析モジュール２０７によって問い合わせられるモデルを決定するように構成されてもよい。テストモジュール２２２は、開発モジュールから取得された新しいモデルをチェックするように構成されてもよい。モデルはモデルデータベース２２５に保持される。統計収集モジュール２２４は、収集されたパラメータ、問い合わせられたモデル、およびモデルの問い合わせの結果に従って、クライアントからデータを受信し、統計データベース２２６に保持される統計を生成する。累積された統計は、新しいモデルを開発したり、既存のモデルをデバッグしたりするために使用され、インタフェースを介して開発者がアクセスできる。
【００３５】
図１は、１つまたは複数のセンサ１０８によって観察される動的システム１００の変形例を示す図であり、その中核は、クライアントがインストールされる基本要素（BE）１０４（図２Ａの基本要素と同様）である。基本要素１０４は、ノートブック、スマートウォッチ、スマートフォン、パーソナルコンピュータ等であってもよい。基本要素１０４は、この例ではアクセスポイント１０６を介して他の要素にリンクされている。したがって、システムの要素の数は、そのカバレッジエリア内で基本要素が見つけられるアクセスポイント１０６の動作半径によって決定される。所与のシステム１００の場合、特定の例では人間は、制御／診断／監視の主体又は客体としてシステムの要素であると考えることができる。人間が制御／診断／監視（例えば、心電図の記録）の客体であると考えられる場合、システムの他の要素は制御の主体である。人間がシステムの要素である場合の異常の概念は、医療要件の場面においてプロセスが正常状態から逸脱することとして定義することができる。
【００３６】
別の場合には、人間及び環境の双方が制御／診断／監視の客体であると考えられるが、この場合これらはシステム１００に対して外部にある。所与の例では、システムの要素は示された分類に従って外部にあるパラメータを収集し、これらのパラメータに基づいて、制御／診断／監視の客体の状態およびプロセスが決定され、一方、回復の方法は、人間または環境のいずれかであり得る制御／診断／監視の客体に関して決定される。
【００３７】
システム２００と観察可能な動的システム１００との関係を図２Ｂで説明する。動的システム１００は、システム２００のサブシステムであってもよく、システム２００と要素が交差していてもよい。例えば、基本要素１０４は、（図２Ｂに示すように）システム２００の全体及びシステム１００の一部であってもよい。
【００３８】
システム２００は、異常を有するシステムのための互換性のあるモジュールを選択する方法を実施するように構成されてもよい（図３Ａ参照）。この場合、クライアント２０５の収集モジュール２０６はステップ３１０において、このシステム１００の指定された機能を実現する要素からシステム１００のパラメータを収集する。収集はまたリアルタイムで行われてもよい。収集されたパラメータはクライアントデータベースに保存され、ステップ３２０において、収集されたパラメータはシステムの状態モデルの問い合わせのために、クライアント２０５の分析モジュール２０７によって使用される。分析モジュール２０７は状態モデルを問い合わせる際に、システム１００およびその要素の状態の、システムの要件に対する適合性を評価する。状態モデルは、プロセスおよび状態がその要件を満たす場合は正常とし、例えば故障状態または故障プロセスを記述する場合は異常として記述することができる。状態モデルは、クライアントデータベース２０８に保持することができる。別の特定の例では、状態モデルはサーバ側によってオンデマンドでクライアントの分析モジュールに提示されてもよい。状態を記述するモデルは回帰、分類、カテゴリ化、および他のモデルなど、可能な限り多様であってもよい。状態を記述するモデルは、意思決定ツリー、ニューラルネット、またはIF（or/and/xor）THEN型の論理規則などに基づくことができる。
【００３９】
ステップ３３０において、モデルの問い合わせの結果として、システムにおいて異常が検出される。異常は少なくとも、要求される状態から逸脱し、要素のパラメータの関数である要素の状態、要求される状態から逸脱し、要素の状態の関数であるシステムの状態、要求されるプロセスから逸脱し、要素の状態の時間関数である要素のプロセス、要求されるプロセスから逸脱し、システムの状態の時間関数であるシステムのプロセス、システムがインタラクトする環境であって、要求される状態から逸脱し、システムのパラメータによって記述可能である環境の状態、およびシステムがインタラクトする環境であって、要求されるプロセスから逸脱し、システムのパラメータによって記述可能である環境のプロセスであってもよい。
【００４０】
異常を発見した後、発見された異常に関する情報は、さらなる処理のために形式化され、異常のクラス（および/または名称）と、異常が関数であるシステムパラメータとによって特徴付けることができる。さらに、パラメータが異常を決定するシステムの要素は、特性として示されてもよい。異常のクラスおよび名称は、どの要件から逸脱しているかに依存する。異常の例は、ルータの弱い信号、要素（CPU、HDD、SSD、RAMなど）の性能の劣化、不十分なRAM空間、データ損失/破損などであり得る。異常が漸進的な障害を伴う場合、異常は、特定された実際のデータ損失またはメモリ量不足ではなく、それらの発生が差し迫っていることをいう。特定の例では、異常には（FURPS＋分類における）機能クラスがあり、例えば、システムの機能を含む。機能異常は、システムの設計または目的によって定められる機能を実行するシステムまたはシステムの要素の性能の低下または損失である。
【００４１】
ステップ３４０で異常を検出し、異常に関する情報を使用して、回復方法のモデルが問い合わせられる。状態モデルと同様に、回復方法の異なるモデルが存在し得る。特定の例では、記述モデルが使用される。さらに、モデルの問い合わせの結果として、ステップ３５０において、実施されたときに、例えば、システムの要求された機能の回復を保証するなど、システムおよび要素の要件への適合性を保証する回復方法が決定される。このようにして発見された回復方法は、異常な状態またはプロセスを安定化させる（異常の進行を止める、これは漸進的な故障に有用である）とともに、異常な状態またはプロセスから要求される状態またはプロセスに要素またはシステムを切り替える（異常の排除）ことによってシステムの回復をもたらすことができる。要求される状態またはプロセスは、FURPS＋分類によるシステムの要件に適合する。回復方法が２つ以上検出される場合があるが、その場合は、性別、年齢、場所、マーケティングクラス、購買力（支払能力）、ITリテラシーのレベルなどの様々な特性を含み得る基本要素のユーザプロファイルに基づいて最終的な方法が選択される。
【００４２】
ステップ３６０では、サードパーティ互換モジュールが選択され（一例では、本方法はモジュールではなく製品を選択することができる。）、回復方法のモデルの問い合わせの結果として見出される回復方法の機能性を実現する。このために、モデルおよびデータベースの両方を使用することができ、回復方法の名称は、回復方法を実現することが保証されるモジュールに対応する。回復方法に関しては、利用可能な回復モジュールが複数あってもよい。その場合、モジュールはユーザのプロファイルに基づいて選択され、さらに、回復モジュールの製造者（ベンダ）の評判が考慮されてもよい。選択されたモジュールは、システム内の様々な方法によって実施することができ、方法の一つとして、クライアントのインストールモジュールによるソフトウェアのインストール方法がある。適合性は、システムまたはモジュールの仕様の分析に基づいて決定される。
【００４３】
特定の例では、回復方法は決定されず（ステップ３４０および３５０をスキップする）、モジュールは異常に関する情報に基づいて決定される。この場合、ステップ３３０を実行した後、ステップ３６０にジャンプする。
【００４４】
上述の方法は、システム２００によって他の方法で実行されてもよい（図３Ｂ参照）。ステップ３１０からステップ３３０までは上述の方法を繰り返すが、その後の処理は変化する。異常が関数である少なくとも要素またはシステムのパラメータによって特徴付けられる異常を検出した後、ステップ３６０ａにおいて、利用可能なサードパーティのシステムまたはモジュールのデータベースまたは少なくとも１つのモジュールに関する情報が取得される。次に、ステップ３２０ａにおいて、再度、システムの状態モデルが、ステップ３１０において収集されたパラメータセットを使用して問い合わせられるが、このパラメータセット中、異常が関数であるシステムのパラメータは、利用可能なサードパーティモジュールのデータベースのモジュールと同等のパラメータによって置き換えられる。ステップ３３０ａにおける状態モデルの問い合わせに基づいて、サードパーティモジュールのデータベースから少なくとも１つのモジュールを見出す。このモジュールは、システムと互換性があり、そのモジュールの置換パラメータを使用して状態モデルを問い合わせるときに異常が見出されない。
【００４５】
ステップ３３０ａでは、指示された基準を満たすモジュールを複数見つけることができ、その場合は、見つかったモジュールのうち一つのモジュールがステップ３６０ｂで選択される。例えば、特定の例では、基本要素のユーザのプロファイルおよび／または見つかったモジュールの製造業者/プロバイダの評判に基づいて、１つのモジュールが選択される。別の特定の例では、発見されたすべてのモジュールについてユーザに通知する（リストを最初にランク付けすることができる）。そのパラメータによって異常が決定されたシステムの要素を実現するモジュールの代わりに、またはそれに加えて、選択されたモジュールをインストールすることができる。
【００４６】
より良く理解するために、単純化された例（図４）を考える。クライアント４０２（クライアントソフトウェア）は、ノートブック４００にインストールされ、ノートブック４００はルータ４０１に接続されている。本開示の用語では、ノートブックは基本要素であり、他の要素、すなわちルータ４０１と共に、調査されるシステムを形成する。さらに、基本要素自体が要素から構成されており、調査されるシステムにおいてノートブックはサブシステムである。クライアント４０２は、システムおよび要素のパラメータを収集し、要素は、少なくとも中央処理装置４１０、RAM４１２、不揮発性記憶装置（NVRAM）４１４、無線通信モジュール４１６、およびルータ４０１である。本例では、NVRAMはSSD（solid  state  drive）によって実現され、ルータ４０１はWPA２ソフトウェア暗号化方式の外部ルータによって実現される。クライアント４０２は、以下のパラメータを収集する:  NVRAM（再割り当てセクタカウントなど）のS.M.A.R.T（自己監視、分析、および報告技術）属性；トラフィック暗号化に関するデータ（たとえば、yes/no、暗号化の種類）；両方向のトラフィック量、トラフィック密度（単位時間当たりの量）；チャネル速度；ルータ信号パワー；およびNVRAM（種類（Type）、量（Value）、フォームファクタ（FF）、インタフェース（Interface））などのモジュールの仕様;およびルータ（Wi-Fi（IEEE）規格、Wi-Fiデバイスの周波数範囲（Spectr）、ハードウェア暗号化サポート（HBE））。
【００４７】
以下の表１では、収集されたパラメータを集約している。この表から、プロセスSn→Sn+1  →...→Sn+...と、所与の時間Snにおける状態と、を得ることができる。
【表１】
2020109635.tif 000003
【００４８】
収集されたパラメータは、システムの状態モデルを問い合わせるためにクライアントの分析モジュール２０７によって使用される。分析モジュール２０７は状態モデルの問い合わせの際に、システム１００とその要素の状態の、システムの要件に対する適合性を評価する。この例では、以下のように要素の異常状態を記述する単純な論理モデルが使用される。
【００４９】
例えば、状態モデルは、所与の状態（Vn）におけるチャネル速度がしきい値速度Vkより著しく低いか、またはしきい値Vkより著しく高い場合に、ネットワークチャネルの劣化の状態を記述する異常状態SPEED_DEGRを使用するよう指定することができる（すなわち、IF  Vn  <<  Vk  or  Vn  >>  Vk  THEN  SPEED_DEGR）。
【００５０】
１つの例では、状態モデルは、所与の状態（RSCn）での再割り当てセクタ数がしきい値RSCk未満であり、第２の状態（RSCm）での再割り当てセクタ数未満である場合、ディスク表面の漸進的な欠陥という形でNVRAMの劣化を記述する、異常状態NVRAM_Sector_DEGRを使用するよう指定することができる。こうした劣化は、表面の摩耗の証拠となるセクタ再割り当て操作数の増加によって示される（すなわち、IF  RSCn    <  RSCk  <  RSCm    WHERE  Tn  <  Tk  <  Tm  THEN  NVRAM_Sector_DEGR)。
【００５１】
別の例では、状態モデルは、再割り当てされたセクタ数が２０より大きい場合、再割り当てセクタ数の臨界値２０に達したことによるNVRAMの障害を記述する異常状態NVRAM_FAULTを使用するよう指定することができる（すなわち、IF  RSC  >  20  THEN  NVRAM_FAULT)。
【００５２】
別の例では、所与の状態（Pn）での信号パワーがしきい値信号パワー値よりも大きく、別の状態（Pm）つまり第２の状態での信号パワーが１５dBm未満であると判定されたことに応じて、信号パワーの劣化の状態を記述する異常状態POWER_DEGRが使用され、臨界レベルである１５dBmまで時間の経過により信号レベルが低下したことを示す（すなわち、IF  Pn  >  Pk  >  Pm  and  Pm  <  15  WHERE  Tn  <  Tk  <  Tm  THEN  POWER_DEGR）。
【００５３】
以上のようなモデルの問い合わせの結果、クライアントは以下の様な特定の時点での異常を発見する：時刻T3でのネットワークチャネルの劣化、時刻T6でのNVRAMの劣化、時刻T9でのNVRAMの故障、時刻T5での信号パワーの劣化。
【００５４】
劣化は異常なプロセスであり、故障は異常な状態である。異常についての情報を有すると、回復方法のモデルが問い合わせられ（この例では論理モデルによっても表される）、回復方法は以下のように決定される:
・IF  POWER_DEGR  THEN  AREA_EXTEND
信号パワーの回復のためには、ルータの有効カバレッジの半径を拡大することが推奨される。
・IF  SPEED_DEGR  WHERE  ENCn  =  1  and  HBEi  =  0  THEN  HBE
接続速度の回復のためには、ハードウェア暗号化サポートを提供することが推奨される。
・IF  SSD_FAULT  THEN  NVRAM_CHANGE  
NVRAMの故障は、モジュール交換により対処するべきである。この例ではSSDを交換することで要素を実現する。
・IF  ROM_Sector_DEGR  THEN  NVRAM_CHANGE  or  BACKUP
表面劣化を特定した場合、その要素を実現しているモジュールがまだ動作可能であれば、モジュールの交換を検討しバックアップコピーを準備することが推奨される。
【００５５】
回復方法が決定されると、推奨される回復方法を実現可能なモジュールが決定される。この例では、これはデータベース２２７へのクエリによって行われ、データベース２２７では回復方法に従ってテーブルが指定される。推奨される方法を実現するだけでなく、問題のシステムと互換性があるモジュールを選択するため、クエリには問題のシステムのパラメータに基づいて形成された特定の条件（演算子WHERE）を含めている。クエリを実行した結果は、クエリ自体と共に提示される:
【表２】
2020109635.tif 000004
【００５６】
２つ以上のモジュールが見つかった場合、次に、ユーザの財務支払能力、ユーザのITリテラシーのレベル（すべてのモジュールが容易にインストールできるわけではない）、専門家に電話をかけるユーザの意欲、消費者間でのソリューションの認知度、製造者/供給者の評判などの追加の特徴を考慮して、見つかったモジュールに追加のフィルタを適用する。
【００５７】
特定の例では、回復方法のモデルは問い合わせられないことがある。例えば、再割り当てセクタ数が臨界値２０に達することによるNVRAMの障害を記述するモデル、IF  RSC  >  20  THEN  NVRAM_FAULTのトリガ時などである。
【００５８】
クエリは、モジュールのデータベースに対して行うことができ、ここで、テーブル属性は上記の例のように、回復方法ではなく、次のように異常に対応する:
【表３】
2020109635.tif 000005
図３Ｂに記載された方法を実行する場合、次の異常を検出した後:
【表４】
2020109635.tif 000006
パラメータが異常を決定しているシステム要素を実現することができる等、システム１００と互換性のあるサードパーティモジュールに関する情報が得られる:
【表５】
2020109635.tif 000007
【００５９】
見つかった互換性のあるモジュールの中で、モジュールの置換パラメータを使用して状態モデル(IF  RSC  >  20  THEN  NVRAM_FAULT)に問い合わせると、異常(RSC  >  20  =  False)が見つからないモジュールが選択される。この例では、明らかに、選択されるモジュールは、再割り当てセクタが存在しないという特性を有するようなモジュール、すなわち、RSC==０であるような、任意の適切に動作するモジュールである。
【００６０】
システム２００のモジュールとは、集積マイクロ回路（特定用途向け集積回路、ASIC）またはフィールドプログラマブルゲートアレイ（FPGA）などのハードウェアを使用して、あるいは例えば、マイクロプロセッサシステムおよびプログラム命令のセットなどのソフトウェアおよびハードウェアの組合せの形態で、また神経シナプスチップに基づいて実現される、実際のデバイス、システム、コンポーネント、コンポーネントのグループを意味する。示されたモジュールの機能は、ハードウェアによってのみ実現されてもよく、また、機能の一部がソフトウェアによって実現され、一部がハードウェアによって実現される組み合わせの形態で実現されてもよい。特定の変形実施形態では、モジュールをコンピュータのプロセッサ（図５に示すものなど）上に実装することができる。データベースは全ての可能な方法によって実現することができ、単一の物理的媒体上に、またはローカルまたはリモートのいずれかに位置する様々な媒体上に含めることができる。
【００６１】
図５は、例示的な態様に従って、異常を有するシステムのための互換性のあるモジュールを検出するシステムおよび方法の態様が実装され得るコンピュータシステム２０を示すブロック図である。コンピュータシステム２０は例えば、先に説明した基本要素１０４のいずれにも対応し得ることに留意されたい。コンピュータシステム２０は複数のコンピューティングデバイスの形態、または単一のコンピューティングデバイス、例えば、デスクトップコンピュータ、ノートブックコンピュータ、ラップトップコンピュータ、モバイルコンピューティングデバイス、スマートフォン、タブレットコンピュータ、サーバ、メインフレーム、埋め込みデバイス、および他の形態のコンピューティングデバイスの形態とすることができる。
【００６２】
図示のように、コンピュータシステム２０は、中央処理装置（CPU）２１と、システムメモリ２２と、中央処理装置２１に関連するメモリを含む様々なシステムコンポーネントを接続するシステムバス２３とを含む。システムバス２３は、バスメモリまたはバスメモリコントローラ、周辺バス、および他の任意のバスアーキテクチャとインタラクトすることができるローカルバスを含むことができる。バスの例は、PCI、ISA、PCI-Express、HyperTransport（登録商標）、InfiniBand（登録商標）、シリアルATA、I2C、および他の好適な相互接続を含むことができる。中央処理装置２１（プロセッサとも呼ばれる）は、単一または複数のコアを有するプロセッサの単一または複数のセットを含むことができる。プロセッサ２１は、本開示の技法を実施する１つまたは複数のコンピュータ実行可能コードを実行することができる。システムメモリ２２は、本明細書で使用されるデータおよび/またはプロセッサ２１によって実行可能なコンピュータプログラムを記憶するための任意のメモリとすることができる。システムメモリ２２は、ランダムアクセスメモリ（RAM）２５などの揮発性メモリ、および読取り専用メモリ（ROM）２４、フラッシュメモリなどの不揮発性メモリ、またはそれらの任意の組合せを含むことができる。基本入出力システム（BIOS）２６は、ROM２４を使用してオペレーティングシステムをロードするときのような、コンピュータシステム２０の要素間で情報を転送するための基本手順を記憶することができる。
【００６３】
コンピュータシステム２０は、１つまたは複数のリムーバブル記憶装置２７、１つまたは複数の非リムーバブル記憶装置２８、またはそれらの組合せなどの１つまたは複数の記憶装置を含むことができる。１つまたは複数のリムーバブル記憶装置２７および非リムーバブル記憶装置２８は、ストレージインタフェース３２を介してシステムバス２３に接続される。一態様では、記憶装置および対応するコンピュータ可読記憶媒体がコンピュータシステム２０のコンピュータ命令、データ構造、プログラムモジュール、および他のデータを記憶するための独立電源型モジュールである。システムメモリ２２、リムーバブル記憶装置２７、および非リムーバブル記憶装置２８は、様々なコンピュータ可読記憶媒体を使用することができる。コンピュータ可読記憶媒体の例は、キャッシュ、スタティックランダムアクセスメモリ（SRAM）、ダイナミックランダムアクセスメモリ（DRAM）、ゼロキャパシタRAM、ツイントランジスタRAM、強化ダイナミックランダムアクセスメモリ（eDRAM）、拡張データ出力ランダムアクセスメモリ（EDO  RAM）、ダブルデータレートランダムアクセスメモリ（DDR  RAM）、電気的消去可能プログラマブルリードオンリメモリ（EEPROM）、NRAM、抵抗性ランダムアクセスメモリ（RRAM（登録商標））、シリコン酸化物窒化物シリコン（SONOS）ベースのメモリ、相変化ランダムアクセスメモリ（PRAM）などの機械メモリ、ソリッドステートドライブ（SSD）またはフラッシュドライブなどのフラッシュメモリまたは他のメモリ技術、ハードディスクドライブまたはフロッピーディスクなどの磁気カセット、磁気テープ、および磁気ディスクストレージ、コンパクトディスク（CD-ROM）またはデジタル多用途ディスク（DVD）などの光ストレージ、ならびに所望のデータを格納するために使用され、コンピュータシステム２０によってアクセスされ得る任意の他の媒体を含む。
【００６４】
コンピュータシステム２０のシステムメモリ２２、リムーバブル記憶装置２７、および非リムーバブル記憶装置２８を使用して、オペレーティングシステム３５、追加のプログラムアプリケーション３７、他のプログラムモジュール３８、およびプログラムデータ３９を記憶することができる。コンピュータシステム２０はキーボード、マウス、スタイラス、ゲーム・コントローラ、音声入力装置、タッチ入力装置などの入力装置４０からデータを通信する周辺インタフェース４６、または、シリアルポート、パラレルポート、ユニバーサルシリアルバス（USB）などの１つまたは複数のI/Oポートを経由するプリンタもしくはスキャナなどの他の周辺デバイス、または他の周辺インタフェースを含むことができる。１つまたは複数のモニタ、プロジェクタ、または統合ディスプレイなどのディスプレイ装置４７も、ビデオアダプタなどの出力インタフェース４８を介してシステムバス２３に接続することができる。コンピュータシステム２０は、ディスプレイ装置４７に加え、ラウドスピーカ及び他のオーディオビジュアル装置のような他の周辺出力装置（図示せず）を装備することができる。
【００６５】
コンピュータシステム２０は、１つまたは複数のリモートコンピュータ４９へのネットワーク接続を使用して、ネットワーク環境で動作することができる。リモートコンピュータ４９は、コンピュータシステム２０の性質を説明する上述の要素の大部分またはすべてを含むローカルコンピュータワークステーションまたはサーバとすることができる。ルータ、ネットワーク局、ピアデバイス、または他のネットワークノードなどの他のデバイスも、コンピュータネットワーク内に存在し得るが、これらに限定されない。コンピュータシステム２０は、ローカルエリアコンピュータネットワーク（LAN）５０、ワイドエリアコンピュータネットワーク（WAN）、イントラネット、およびインターネットなどの１つまたは複数のネットワークを介してリモートコンピュータ４９と通信する１つまたは複数のネットワークインタフェース５１またはネットワークアダプタを含むことができる。ネットワークインタフェース５１としては、例えば、イーサネット（登録商標）インタフェース、フレームリレーインタフェース、SONETインタフェース、無線インタフェース等が挙げられる。
【００６６】
本開示の態様は、システム、方法、および/またはコンピュータプログラム製品であってもよい。コンピュータプログラム製品は、プロセッサに本開示の態様を実行させるためのコンピュータ可読プログラム命令を含むコンピュータ可読記憶媒体（１つ又は複数）を含むことができる。
【００６７】
コンピュータ可読記憶媒体は、コンピューティングシステム２０などのコンピューティングデバイスのプロセッサによってアクセスすることができる命令またはデータ構造の形態のプログラムコードを保持し、記憶することができる有形デバイスとすることができる。コンピュータ可読記憶媒体は、電子記憶デバイス、磁気記憶デバイス、光記憶デバイス、電磁記憶デバイス、半導体記憶デバイス、またはそれらの任意の適切な組合せとすることができる。例として、そのようなコンピュータ可読記憶媒体は、ランダムアクセスメモリ（RAM）、リードオンリメモリ（ROM）、EEPROM、ポータブルコンパクトディスクリードオンリメモリ（CD-ROM）、デジタル多用途ディスク（DVD）、フラッシュメモリ、ハードディスク、ポータブルコンピュータディスケット、メモリスティック、フロッピー（登録商標）ディスク、またはパンチカードまたは命令が記録された溝内の隆起構造などの機械的に符号化されたデバイスを含むことができる。本明細書で使用されるように、コンピュータ可読記憶媒体は、電波または他の自由に伝播する電磁波、導波管または伝送媒体を通って伝播する電磁波、または有線で伝送される電気信号など、一時的な信号そのものであると解釈されるべきではない。
【００６８】
本明細書で説明するコンピュータ可読プログラム命令は、例えば、インターネット、ローカルエリアネットワーク、ワイドエリアネットワーク、および/またはワイヤレスネットワークなどのネットワークを介して、コンピュータ可読記憶媒体からそれぞれのコンピューティングデバイスに、または外部コンピュータもしくは外部記憶デバイスにダウンロードすることができる。ネットワークは、銅線伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータ、および/またはエッジサーバを含むことができる。各コンピューティング装置内のネットワークインタフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、それぞれのコンピューティング装置内のコンピュータ可読記憶媒体に記憶するために、コンピュータ可読プログラム命令を転送する。
【００６９】
本開示の動作を実行するためのコンピュータ可読プログラム命令は、アセンブリ命令、命令セットアーキテクチャ（ISA）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、またはオブジェクト指向プログラミング言語および従来の手続き型プログラミング言語を含む１つまたは複数のプログラミング言語の任意の組合せで書かれたソースコードまたはオブジェクトコードのいずれかとすることができる。コンピュータ可読プログラム命令は、完全にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、スタンドアロンソフトウェアパッケージとして、部分的にユーザのコンピュータ上で、部分的にリモートコンピュータ上で、または完全にリモートコンピュータまたはサーバ上で実行することができる。後者のシナリオでは、リモートコンピュータは、LANまたはWANを含む任意のタイプのネットワークを介してユーザのコンピュータに接続されてもよく、または（例えば、インターネットを介して）外部コンピュータに接続されてもよい。いくつかの実施形態では、例えば、プログラマブル論理回路、フィールドプログラマブルゲートアレイ（FPGA）、またはプログラマブル論理アレイ（PLA）を含む電子回路は本開示の態様を実行するために、電子回路をパーソナル化するためにコンピュータ可読プログラム命令の状態情報を利用することによって、コンピュータ可読プログラム命令を実行することができる。
【００７０】
様々な態様では、本開示で説明されるシステムおよび方法がモジュールの観点から対処することができる。本明細書で使用される「モジュール」という用語は例えば、特定用途向け集積回路（ASIC）またはFPGAなどのハードウェアを使用して実装される、あるいは、マイクロプロセッサシステムおよび（実行されている間に）マイクロプロセッサシステムを専用デバイスに変換するモジュールの機能を実装するための命令セットなどのハードウェアおよびソフトウェアの組合せとして実装される、現実世界のデバイス、コンポーネント、または構成要素の構成を指す。また、モジュールは２つの組み合わせとして実装されてもよく、特定の機能はハードウェアのみによって促進され、他の機能はハードウェアとソフトウェアとの組み合わせによって促進される。いくつかの実装形態ではモジュールの少なくとも一部、および場合によってはすべてが、コンピュータシステムのプロセッサ（上記の図５でより詳細に説明したものなど）上で実行され得る。したがって、各モジュールは、様々な適切な構成で実現されてもよく、本明細書で例示される任意の特定の実装形態に限定されるべきではない。
【００７１】
明確にするために、態様のルーチンの特徴のすべてが本明細書に開示されるわけではない。本開示の任意の実際の実装の開発において、開発者の特定の目標を達成するために、多数の実装固有の決定が行われなければならず、これらの特定の目標は、異なる実装および異なる開発者によって異なることが理解されるのであろう。そのような開発努力は複雑で時間がかかる可能性があるが、それにもかかわらず、本開示の恩恵を受ける当業者にとっては日常的なエンジニアリングの仕事であることが理解される。
【００７２】
さらに、本明細書で使用される語法または用語は説明を目的としたものであり、限定を目的としたものではない。したがって、本明細書の語法または用語は、関連技術の当業者の知識と組み合わせて、本明細書で提示される教示およびガイダンスに照らして、当業者によって解釈されるべきであることを理解されたい。さらに、明細書または特許請求の範囲におけるいかなる用語も、そのように明示的に記載されていない限り、一般的ではない意味または特別な意味に帰することを意図していない。
【００７３】
本明細書で開示される様々な態様は、例示として本明細書で言及される既知のモジュールに対する現在および将来の既知の同等物を包含する。さらに、態様および用途が示され、説明されてきたが、本明細書に開示された発明概念から逸脱することなく、上記よりも多くの変形例が可能であることは本開示の恩恵を受ける当業者には明らかであろう。
【図１】
2020109635.tif 000008
【図２Ａ】
2020109635.tif 000009
【図２Ｂ】
2020109635.tif 000010
【図３Ａ】
2020109635.tif 000011
【図３Ｂ】
2020109635.tif 000012
【図４】
2020109635.tif 000013
【図５】
2020109635.tif 000014
【外国語明細書】
2020109635000001.pdf