JP7465939B2 - 電力不正使用検出のための新しい非パラメトリック統計的挙動識別エコシステム - Google Patents

Description

関連出願の相互参照
本願は、２０１７年１１月２１日付で提出された米国非仮出願第１５／８２０，３２６号と、２０１７年４月１３日付で提出されて「電力不正使用を検出するための新しい非パラメトリック統計的挙動識別エコシステム（NOVEL NON-PARAMETRIC STATISTICAL BEHAVIORAL IDENTIFICATION ECOSYSTEM FOR ELECTRICITY FRAUD DETECTION）」と題された米国仮出願第６２／４８５，３１９号との利益および優先権を主張するものであって、その各々が全体として引用によりあらゆる目的のためにここに援用されている。

背景
電力会社の顧客の中には、しばしば、代金を支払うことなく電力を盗むことによって不正を働く顧客がいる。広範囲にわたる不正の検出が困難であるため、これは電力会社にとって深刻な問題となっている。

従来、電力会社は不正を検出するための３つの方法のうちの１つに依存してきた。３つの方法とは、すなわち、（１）深層主題の専門知識を有するとともに住宅着工許可件数などのデータソースの多様な集合にアクセスできる人の分析者；（２）電力計測技術の製造業者によって提供されるルールベースのシステム；または（３）明らかな不正の事例（たとえば、隣人が電力を盗んでいることが明らかである）について他の顧客が電力会社に通知するという運ベースのシステム、である。これらの方法は信頼性が低いが、このことは、大多数の不正事例が運ベースのシステムによって識別されていることによって証明されている。

これらの方法の信頼性の欠如は、検出率が低いことと、誤判定率が高いこととが組合わさったことに起因している。いくつかの推定では、これらの従来の方法の誤判定率が８０％であり、検出された不正事例の大部分が実際には不正ではない。この結果、電力会社にとって高額の費用が発生することとなり、不正を捕らえることがコスト／利益の観点からもはや有益でないというレベルにまで達している。不正を捕らえることがこのように経済的に不可能であるため、既存の詐欺師が大胆になるとともに潜在的な詐欺師による不正の実行が助長されることによって問題がさらに複雑になった。

このため、低い検出率および高い誤判定率を伴うことなく不正を検出することができるとともに、住宅用電力および工業用電力の不正使用の検出に適用するのに十分にロバストである、信頼性のある電力不正検出システムが必要とされている。本開示の実施形態は、少なくともこれらの必要性に対処することを目的としている。

概要
いくつかの実施形態においては、１つ以上のデータストアを含むコンピューティングシステムが開示される。当該１つ以上のデータストアは、電力不正の既知の事例に関連付けられた第１のデータ項目を含む既知のデータセットと、複数のサービスポイントにおける電力不正の未知の事例に関連付けられた第２のデータ項目を含む未知のデータセットとを格納する。この場合、複数のサービスポイントのうちの各サービスポイントは電力メータ
に対応する。第２のデータ項目は、各サービスポイントに対応する電力メータに関連付けられた電力需要を含む。

コンピューティングシステムはまた、コンピュータプロセッサと、複数のプログラム命令を格納しているコンピュータ読取り可能記憶媒体とを含み得る。複数のプログラム命令は、コンピュータプロセッサに、既知のデータセットにアクセスさせるとともに、モデルの検出器挙動を第１のデータ項目に少なくとも適用することによって疑わしい既知の事例のセットを判断させるために、コンピュータプロセッサによって実行されるように構成されている。いくつかの実施形態においては、複数の命令は、コンピュータプロセッサに、当該モデルの１つ以上の誤判定説明に対して疑わしい既知の事例のセット内の既知の事例の各々を分析することによって、疑わしい既知の事例のセットから、説明済みの既知の事例のセットを判断させてもよい。この場合、説明済みの既知の事例のセットは疑わしい既知の事例のセットのサブセットである。いくつかの実施形態においては、複数の命令は、コンピュータプロセッサに、疑わしい既知の事例のセットについての判断に基づいてモデルを検証させ、未知のデータセットにアクセスさせ、および／または、少なくとも検出器挙動を第２のデータ項目に適用することによって疑わしい未知の事例のセットを判断させてもよい。いくつかの実施形態においては、複数の命令は、コンピュータプロセッサに、１つ以上の誤判定説明に対して疑わしい未知の事例のセット内の未知の事例の各々を分析することによって、疑わしい未知の事例のセットから、説明済みの未知の事例のセットを判断させてもよい。説明済みの未知の事例のセットは疑わしい未知の事例のセットのサブセットである。いくつかの実施形態においては、複数の命令は、コンピュータプロセッサに、疑わしい未知の事例のセットから説明済みの未知の事例のセットを差し引くことによって、未説明の未知の事例のセットを判断させてもよい。未説明の未知の事例のセットは、説明済みの未知の事例のセットとは重複しない疑わしい未知の事例のセットのサブセットである。

本開示の実施形態に従った、電力不正検出についてのシステム図である。 本開示の実施形態に従った、電力不正を検出することを目的としたアルゴリズムについてのブロック図である。 本開示の実施形態に従った、電力不正を検出することを目的としたアルゴリズムについてのブロック図である。 本開示の実施形態に従った、電力不正検出のために使用できる需要データの例を示す図である。 本開示の実施形態に従った、電力不正検出のために使用できる不正データの例を示す図である。 本開示の実施形態に従った、電力不正検出のために使用できる例示的な分布テーブルを示す図である。 本開示の実施形態に従った、電力不正検出のために使用できる例示的な分布プロットを示す図である。 本開示の実施形態に従った、電力不正検出のために使用できる例示的な分布テーブルを示す図である。 本開示の実施形態に従った、顧客の例示的な需要プロフィールを示す図である。 本開示の実施形態に従った、顧客の需要を示す例示的なグラフである。 本開示の実施形態に従った例示的な結果テーブルを示す図である。 本開示の実施形態に従った、不正事例において検出された低い中間需要を示す例示的なグラフである。 本開示の実施形態に従った、不正事例において検出された低い中間需要を示す例示的なグラフである。 本開示の実施形態に従った、不正事例において検出されたゼロの中間需要を示す例示的なグラフである。 本開示の実施形態に従った、不正事例において検出されたゼロの中間需要を示す例示的なグラフである。 本開示の実施形態に従った、疑わしい挙動の正当な説明に対応する例示的なフィールド活性フラグを示す図である。 本開示の実施形態に従った、電力不正検出を実現するためのブロック図である。 本開示の実施形態に従った、電力不正検出のためのハイブリッドシステム図である。 本開示の実施形態に従った、突然低下した後に低いままとどまっている需要についての例示的な挙動パターンを示す図である。 本開示の実施形態に従った、緩やかに低下した後に低いままとどまっている需要についての例示的な挙動パターンを示す図である。 本開示の実施形態に従った、長期間にわたって緩やかに低下している需要についての例示的な挙動パターンを示す図である。 本開示の実施形態に従った、非常に少ない需要についての例示的な挙動パターンを示す図である。 本開示の実施形態に従った、上昇すると予想されていた場合に上昇しない需要についての例示的な挙動パターンを示す図である。 本開示の実施形態に従った、過度に異常に安定している需要についての例示的な挙動パターンを示す図である。 実施形態のうちの１つを実現するための分散型システムを示す簡略図である。 本開示の一実施形態に従った、実施形態のシステムのコンポーネントによって提供されるサービスがクラウドサービスとして提供され得るシステム環境のコンポーネントを示す簡略ブロック図である。 本発明のさまざまな実施形態が実現され得る例示的なコンピュータシステムを示す図である。

詳細な説明
以下の記載においては、本発明の実施形態の充分な理解を提供するために、説明の目的で、具体的な詳細が述べられる。しかしながら、さまざまな実施形態がこれらの具体的な詳細なしでも実施され得ることは明らかであるだろう。図および記載は限定的なものとして意図されたものではない。

図のうちのいくつかに示されるシステムは、さまざまな構成で提供され得る。いくつかの実施形態においては、システムは、システムのうちの１つ以上のコンポーネントがクラウドコンピューティングシステムにおける１つ以上のネットワークにわたって分散されている分散型システムとして構成されてもよい。いくつかの実施形態においては、システムは、仮想環境または非仮想環境において動作するように構成されてもよい。

序論
先に述べたように、電力会社の顧客の中には、しばしば、代金を支払うことなく電力を盗むことによって不正を働く顧客がいる。検出率が低いことおよび誤判定率が高いことが組合わさることで、電力会社が現存のシステムでこの不正を検出するのは困難になっていた。言いかえれば、システムは、不正を検出することができない上に、実際には如何なる不正も発生していないのに不正として検出してしまうことが数回ある。

不正検出に適用される機械学習アルゴリズムを使用しても、さまざまな理由でこれらの欠点に対処できる可能性は低い。第１に、顧客の挙動を不正であるかまたは不正でないものとして分類するように構成された、教師あり学習（supervised learning）方法（たと
えば、分類：ＳＶＭ）などの機械学習アルゴリズムは、将来の予測に適用するために過去の観察結果からパターンを記憶する傾向がある。残念ながら、実際の不正についての過去の観察結果のうち限られた数の観察結果が機械学習アルゴリズムに関するコールドスタート問題を引起こす。機械学習アルゴリズムから信頼性のある予測をもたらすための、不正事例についての十分なデータはない。アルゴリズムは、アルゴリズムをトレーニングするのに用いられる限られた数の事例と同様の事例しか検出することができないので、潜在的には、トレーニングセットにおいて最初に識別されなかった場合、アルゴリズムによって検出されない多くの不正事例が存在することとなるだろう。機械学習アルゴリズムは、過去に既に起こったことしか検出することができないので、検出できるものが限られている。検出率が低いという問題は解消されないままとなる可能性があるだろう。

さらに、機械学習アルゴリズムは、因果推論の説明に関して制限されていることが多い。因果関係や、モデルの入力同士の関係を理解することはロバストなモデルを構築するのに役立ち得る。より複雑なモデル（たとえば、より多くの想定を行なうモデル）はより多くのリスクを伴うものであり、このようなリスクの増加は、ある程度の統計的に有意な性能の向上もたらして、複雑さとロバスト性との間の適切なバランスを確実にするはずである。

加えて、電力不正を働く者は、しばしば、調査されている場合または調査されていると疑っている場合に、自身の挙動を変更する。したがって、過去のパターンに基づいて不正な挙動を識別するための機械学習アルゴリズムのトレーニングには欠陥がある。なぜなら、挙動のパターンが時間とともに変化する可能性があるからである。

これらの欠点を回避するために、電力不正検出システムは、低検出率および高誤判定率の問題を関連付けて取扱うのではなく別個に取扱うという見地から設計することができる。言いかえれば、電力不正検出の問題は２つの別個の副次的問題に分割することができる。２つの別個の副次的問題は、順々に適用することができる２つの別個のモデルを用いて対処される。２つの別個のモデルのうち一方のモデルは、不正を高検出率で検出することを目的としており、他方のモデルは、最初のモデルによって生成された結果をフィルタリングするために誤判定を減らすことを目的としている。

概念的には、不正な挙動を検出する副次的問題を第１に優先させてもよい。なぜなら、低い検出率のままでは、不正の多くの事例が識別されないままとなるからであり（「未知であることによる未知」（unknown unknowns））、これは、電力会社にとって大幅なコストの追加となる。このため、第１のモデル（たとえば、検出器モデル）は、不正行為のためのさまざまな検出器を用いて、不正な挙動を検出するために構成されてもよい。しかしながら、それまでに識別されていない不正の事例を検出するために、このようなモデルは、それまでに識別された不正のトレーニングセットを用いて構築される検出器を用いるべきではない（なぜなら、これら検出器は未識別の不正を把握していないからである）。いくつかの実施形態においては、このモデルの検出器は、観察された過去の不正の事例ではなく顧客の需要、または顧客の電力使用に直接基づいていてもよい。これらの検出器は、結果として企業の収益を減少させることとなる需要プロフィール内の疑わしい挙動のさまざまな形態を検出するように構成されてもよい。

次いで、第１のモデルによって検出される事例に関連付けられた疑わしい挙動についての正当で不正のない説明を見出そうと試みることによって、誤判定を減らすことに焦点を置いた第２のモデル（たとえば、誤判定モデル）があり得る。この第２のモデルは、正当
に説明された疑わしい挙動をいずれも除外して、不正である可能性が高い事例を残しておくために用いられる。

言い換えれば、企業に対して収益の損失をもたらすパターンが特定される「パイプライン」（たとえば検出器）があってもよい。このパターンは「異常な挙動」または単に「挙動」と略して称されてもよい。挙動の例を識別するために検索を行なうことができる。誤判定ルールエンジンは、誤判定を除外するためにこれらの検索結果に対して実行される。残っている事例（たとえば、誤判定として除外されない検索結果）は、不正である可能性がより高い事例である。このパイプラインは、（１）既知の不正事例のセット、および（２）未知であることによる未知のセット（他のすべてのセット）両方に対して適用することができる。

パイプラインが（１）既知の不正事例のセットに適用される場合、得られる結果は、（Ａ）検出器が検出した既知の不正事例の数；（Ｂ）検出器が検出しなかった既知の不正事例の数；（Ｃ）検出された挙動のセット内における、誤判定ルールエンジンでうまく説明された事例の数とともに、これらの事例がうまく説明された理由についての数値的内訳、および、（Ｄ）検出された挙動のセット内における、誤判定ルールエンジンでうまく説明されなかった事例の数、を含む。

パイプラインが（２）未知であることによる未知のセットに適用される場合、得られる結果は、（Ａ）検出器が挙動を検出した事例の数、（Ｂ）検出器がいずれの挙動も検出しなかった事例の数、（Ｃ）検出された挙動のセット内における、誤判定ルールエンジンでうまく説明された事例の数とともに、説明された理由についての数値的内訳、および、（Ｄ）検出された挙動のセット内における、誤判定ルールエンジンでうまく説明されなかった事例の数、を含む。

（１）既知の不正事例のセットおよび（２）未知であることによる未知のセット（他のすべてのセット）の両方にパイプラインを適用して、それらの結果における情報を分析することにより、検出器が如何に十分に動作するかと、既存の検出器の品質とについての理解が得られる。これによっても、検出能力を高めるように構築される必要がある可能性のある追加の検出器の数が把握されることとなる。たとえば、１０００の事例をサーチすることで、２０の検出された挙動が識別され得るが、２０の検出器が捕らえるように設計されていない残りの９８０個の事例において依然として他の挙動が存在している可能性がある。これにより、追加の検出器を構築する必要があることを通知することができる。

さらに、（１）既知の不正事例のセットおよび（２）未知であることによる未知のセット（他のすべてのセット）の両方にパイプラインを適用することによっても、誤判定ルールエンジンがどのように動作するかと、誤判定の数を減らすように追加の誤判定ルールを構築する必要があるかどうかと、についての理解が得られる。このことは重要であるが、それは、多種多様なソースからの情報に基づいて構築することができる膨大な数のさまざまな誤判定ルールが存在し得るからである。

たとえば、誤判定ルールは、「小規模なアパートのサイズ（small apartment size）」、「顧客、太陽エネルギの顧客である（is customer a solar customer）」などを識別するために内部データソースから取得することができ、誤判定ルールも、Facebook（登録商標）、Twitter（登録商標）、LinkedIn、Glassdoor、またはニュース媒体などの外部データソースによって判断することができる。たとえば、LinkedInプロファイルは、顧客Ｘが電力不正を犯すのに必須のエンジニアリング知識を有していることを示してもよく、このため、異常な挙動が検出されている場合、その知識を有するとは予想され得ない人に関して、挙動が不正である確率が高まる可能性がある。同様に、Twitterのフォロー、YouTube
（登録商標）（ユーチューブ）／Facebookのコメント、およびグループアソシエーションを監視することができるとともに、個人がどのようなトピックに関与（共有、リンクまたはコメント）しているかについての情報も取込むことができる。この技術は、さまざまなオープンソースツール（open source tool）およびＡＰＩをまとめることにより、またはオラクルマーケティングクラウド（Oracle Marketing Cloud）などのソフトウェアを介して取得することができる。

さらに、誤判定ルールを作成するために用いられるこれらのさまざまなデータソース（たとえば、内部ソース（内部顧客データ）および外部ソース（ソーシャルメディア））からのデータは、コミュニティおよび複雑な関係を自動的かつ迅速に識別するために、グラフデータベースに供給することができる。たとえば、グラフデータベースは、不正に関与した人々が「Ｘ、Ｙ、Ｚ」を好んでいたこと、および「Ａ、Ｂ、Ｃ」について話していたことを通知し得る。次いで、グラフデータベースは、同様の特徴を有していたがまだ不正に関与していないすべての人を復帰させるだろう。このため、誤判定ルールエンジンは、グラフデータベースに起因する推論および知識を用いて構築することができる。グラフデータベースを同様に用いることで、世界中の警察が、重要な政治家および抗議グループの活動に対する反感を（たとえば、群衆整理、バリケードなどの計画を立てるために）追跡することが可能となるとともに、クレジットカード詐欺を検出することも可能となる。

これは、需要プロフィールからのデータが、数学的空間および物理地理的空間の点で既知である不正行為者に対する関係／関係の程度を示すソーシャルメディアからのデータと組み合わされるように、誤判定ルールエンジンが個人専用の不正システムに進化することを可能にする。これらのデータポイントは、顧客プロフィールの３６０度の視界を構築する役割を果たすことができる。たとえば、グリーンエネルギに関するものに対する顧客の興味（またはその効果に対するソーシャルメディアの投稿）は、需要の突然の低下が、不正を犯そうとする意図ではなく、気分の変化および好みの変化（たとえば、顧客が環境保護のために環境に優しい生活を送ろうとすること）に起因していたことを示す直接的な指標になり得る。ソーシャルメディアに耳を傾ける方法がなければ、このデータは取込まれず、誤判定ルールエンジンによって考慮されないため、理にかなった需要の低下をうまく説明することができなかったであろう。

したがって、この明細書中に記載される電力不正検出システムは、不正に対する反応ではなく、不正防止のパラダイムに基づき得るものであって、最初に発生する不正の防止を可能にする。目標設定されたメーリングキャンペーンを受けることによって、または、不正を検出することができる会社を強調表示させるテキストメッセージによって、単純に、まだ不正に関与していないがグラフデータベースによって識別された人が不正に関与するのを断念させてもよくまたは思い留まらせてもよい。言いかえれば、不正に関与する可能性のある人を予測モデルが識別すると、いくつかのタイプのアウトリーチキャンペーンを用いてイベントが発生するのを防止することができる。これらのキャンペーンの成功は、単に、アウトリーチ処理を受取ったものの結局不正を犯してしまった人を監視することによって追跡することができる。このようなアウトリーチキャンペーンの目的は、いくつかのタイプの挙動修正を実行する（たとえば、誰かが何かを行なうことを防止する（不正を実行させない））ことである。これは、マーケティングにおける（顧客が購入する際に一連の段階（認識、意図および最終的に購入する決定）を経験する）「変換ファネル（conversion funnel）」に観念論的に類似している。同時に、本願における反応型の電力不正
検出システムは、「変換ファネル」におけるすべての段階を経験し、「変換」に到達した顧客、たとえば実際に不正に関与した顧客、の識別に対処するだろう。

こうして、予防的プレ不正型のシステムは、変換ファネルに達したもののまだ変換していない（たとえば、不正が行なわれていない）すべての人を識別してこれに対処するだろ
う。さらに、反応型の不正検出システムは、変換後であるすべての人（たとえば、不正を犯した人々）に対処するだろう。これらのシステムをともに組合わせて、不正防止および不正に対する対応の分野における真の合同軍アプローチを構築してもよい。このため、顧客が変換ファネルに到達しているにもかかわらず、これらに対処するために数学的に具体的／厳密な方法が存在するだろう。

電力不正検出システムにおいて用いられる検出器に関して、検出器は、設計によって誤判定ルールエンジンから意図的に切り離されている。なぜなら、誤判定ルールエンジンは、複数の検出器に適用可能であり得るかまたは１つの検出器のみに特有のものであり得るからである。検出器および誤判定ルールエンジンのこれらの組合せの数値的精度は、出力を格納することによって実証することができる。これにより、検出器および誤判定ルールエンジンを連続的に改良することが可能となる。さらに、このフレームワークは、原因解析を迅速かつ効率的に実行することを可能にする。検出器がその結論にどのように達したか（検出器が事前に規定されている）かまたは誤判定を引起こしたものが何であるか（誤判定ルールエンジンに含まれていなかったルールである）についての推測作業はない。このため、いずれの検出器／誤判定ルールエンジンにおける如何なる欠陥も、迅速に識別して修正することができる。

検出器および誤判定ルールは、人の専門家、ＡＩまたはこれら両方によって構築されてもよい。たとえば、自動誤判定ルールは機械学習関連付けルール／教師なし学習（unsupervised learning）を適用することによって構築されてもよい。別のアプローチにおいて
は、誤判定は、ソーシャルメディアおよび内部データを活用するためにグラフの上述のトラバース測量を用いて識別されてもよい。これらの２つの別個のアプローチは、さらに、人の専門家が認識しているが機械学習アルゴリズムによって実現される誤判定ルールで（たとえば、データに取込まれていない業務知識に依拠する推論を用いて）、単一の２方面からなるアプローチに組合わせることもできる。このエコシステム性能監視フレームワークは、ユーザが、機能しているものに影響を及ぼすことなく機能していないものを交換することを可能にすることによって電力不正検出システムを絶えず向上させることを可能にするとともに、一定のパラメータが最初に十分に作業を実行し得るのかについての理由をユーザが十分に理解することを可能にする。

例示的な実施形態
図１は、本開示の実施形態に従った、電力不正についてのシステム図である。

いくつかの実施形態においては、電力会社の顧客などの、自身の住居に電力が送達される１人以上の顧客１０２－１から１０２－ｎが存在し得る。各々の顧客が電力を用いると、彼らの電力使用量がそれぞれのメータ１０４－１から１０４－ｎで測定され得る。いくつかの実施形態においては、これらのメータは、特有の識別子（たとえば、サービスポイントｉｄ）に関連付けられてもよく、各々の顧客の住居／不動産が１つのメータに関連付けられてもよい。したがって、あるメータについての特有の識別子が、関連付けられた顧客を識別するために用いられてもよい。

メータ１０４－１から１０４－ｎは、数ある情報の中でも特に、電力使用統計を電力不正検出（electricity fraud detection：ＥＦＤ）システム１１０に報告し得る。さまざ
まな顧客１０２－１から１０２－ｎについての電力使用量が需要データベース１１２に格納されてもよい。いくつかの実施形態においては、代価を支払わずに電力を盗む顧客などの、それまでに観察された不正行為の事例に関連付けられたデータ項目を含む、観察された不正データベース１１４があってもよい。いくつかの実施形態においては、これらの観察された不正の事例は、フィードバックを行なって電力不正検出システム１１０の結果を実証するのを支援するために用いられてもよい。

いくつかの実施形態においては、電力不正検出システム１１０は、１以上の顧客１０２－１から１０２－ｎの不正行為を検出することができるかもしれない。これは、この明細書中に記載されるように、顧客１０２－１から１０２－ｎの各々の、彼らの電力使用量に基づいた挙動プロフィールの判断を含むさまざまな方法によって行うことができる。いくつかの実施形態においては、電力不正検出システム１１０が１以上の顧客１０２－１から１０２－ｎによって実行されている不正行為を識別するかまたは検出すると、電力不正検出システム１１０はコンピューティングデバイス１２０を介して調査員１２２に通知し得る。次いで、調査員１２２は、不正が発生していることを実証するために顧客によって実行されているいずれの不正行為をも調査し得る。

図２Ａは、本開示の実施形態に従った、電力不正を検出することを目的としたアルゴリズムについてのブロック図を示す。図２Ｂはまた、本開示の実施形態に従った、電力不正を検出することを目的としたアルゴリズムについてのブロック図を示す。図２Ａおよび図２Ｂは一緒に記載されている。

ブロック２０２において、顧客についての需要データおよび不正データを含むデータセット（たとえば、図３Ａおよび図３Ｂに示されるデータテーブルの組合せ）は、既知の事例のセット（それまでに観察された実際の不正）およびそれらの既知の事例についての対応するデータ項目（たとえば、その不正を犯した顧客についての需要データ）を判断するために用いられてもよい。そのデータセットはまた、未知の事例のセットと、それらの未知の事例についての対応するデータ項目（たとえば、それまでに観察された実際の不正に関与していない顧客についてのすべてのデータ項目）とを判断するために用いられてもよい。より具体的な例として、すべての事例２２０のデータセットは、既知の事例２２２のデータセットと未知の事例２２４のデータセットとに分割することができる。既知の事例のセットは、電力不正検出システムにおいて用いられる複数モデルのうちの１つまたは両方の精度を検証するのに有用であり得る。

ブロック２０４において、挙動のセットは、不正検出率を向上させるために疑わしい挙動を過度に包括するように設計されている、疑わしい挙動を検出するための第１のモデルにおいて検出器（たとえば、検出器２２６）として特定されている。上述したように、検出器は、各々の顧客毎に、時間の経過に応じて電力使用量に関連付けられている需要プロフィールまたはメトリクスに関連付けられた挙動に基づいていてもよい。これらの需要プロフィールは、図１に示されるメータ１０４－１から１０４－ｎによってすべての顧客について集めることができる需要データに基づいて計算することができる。たとえば、１年の間にわたる顧客の毎日の電力需要は、その期間にわたる最大需要、最小需要および中間需要を計算するために用いることができる。これらのメトリクスは、その期間にわたる顧客の需要プロフィールの一部と見なすことができる。需要プロフィールは、図２Ａ、図２Ｂおよび図６に関連付けてより詳細に記載されている。需要プロフィールに関連付けられたグラフの例が図８Ａ、図８Ｂ、図９Ａおよび図９Ｂに示される。

検出器は、収益の低下をもたらす可能性のある、需要プロフィールに関連付けられた予め規定された挙動パターンと見なすことができる。第１のモデルは複数の検出器で構成されてもよく、したがって、これらの予め規定されたパターンのセットにおける如何なるパターンにも該当する如何なる顧客需要プロフィールをも識別することができるだろう。検出器の一例は、さまざまな方法で規定することができる顧客の需要プロフィールについての低い中間需要であるだろう。たとえば、常に０である中間需要として規定されてもよく、常に０である最大需要として規定されてもよく、０である中間需要であるがゼロよりも大きい最大需要として規定されてもよく、すべての顧客についての中間需要のうち最下位から１０パーセンタイル内である中間需要として規定されてもよい（たとえば、顧客の母
集団の少なくとも９０％がより大きな需要を有していた）、等である。パーセンタイルに基づいた検出器の実現例が、図４Ａ、図４Ｂおよび図５に関連付けてさらに詳細に記載されている。なお、顧客の毎日の需要が外れ値を有し得る非常に変動し易い（たとえば、日常的に大幅に変化する）プロセスであり得るので、歪みの潜在的な問題を回避するのに中間値が有用であり得ることに留意されたい。このため、付加的な検出器を容易にモデルに追加することができ、これは、ロバストであるとともに厳格な「エコシステム」と称することができる。なぜなら、これは、需要プロフィールに関連付けられた特有の挙動に焦点を合わせた、高度に特化された多数の独立した検出器を含み得るからである。さらに、この態様で検出器を使用することにより、過去の挙動（たとえば、それまでに観察された不正）のパターンに依存することが回避されるとともに、トレーニングが不要となる。検出器のトレーニングが不要となり、検出器が挙動に焦点を合わせるので、同じ検出器を用いて、産業上の不正だけでなく住居での不正も同様に（いずれの事例にも特有のパターンが適用されないので）検出することができる。

いくつかの実施形態においては、検出器に組込むことができる潜在的な疑わしい挙動パターンの他の例は、
（１）突然低下した後に低いままとどまる需要（図１３に図示）、
（２）緩やかに低下した後に低いままとどまる需要（図１４に図示）、
（３）長期間にわたって緩やかに低下する需要（図１５に図示）、
（４）非常に低い需要（図１６に図示）、
（５）上昇すると予想されていた場合に上昇しない需要（図１７に図示）、
（６）あまりにも異常に安定している需要（図１８に図示）、を含む。

なお、図１３～図１８およびそれらの対応する記載ならびに特に図１６において、低い需要または非常に低い需要が所与の時点において対象となっている母集団のＥＣＤＦからの分布によって規定することができるに留意されたい。たとえば、図１６においては、対象となっている母集団のＥＣＤＦは、（たとえば、中間需要を含む）需要分布を取得するために用いられる。低い需要は、需要についての任意に選択されたしきい値（たとえば、１０ｋｗｈ）ではなく、その分布の左下側末尾（たとえば、複数分布のうちの１つの分布）として規定されるだろう。低い需要としてみなされる正確な量の需要は、時間およびその時間での母集団挙動に依存することとなる。たとえば、低い需要は、母集団にわたる典型的な需要に応じて１０ｋｗｈであってもよく、または１００ｋｗｈであってもよい。図１３～図１８は、挙動パターンに分類することができる顧客需要プロフィールを視覚化したものである。それらの視覚化されたデータは、中間値、最大値、最小値などの時間依存メトリクスを用いて定量化することができる。これらは、他のすべての人によって示されるメトリクスに対して相対的に、或る時間にわたってこれらのタイプのパターンを検出するための挙動検出器への入力になるだろう。

ブロック２０６において、第１のモデルの検出器は、疑わしい挙動を伴った既知の事例を判断することによって、既知の事例（たとえば、それまでに観察された不正事例）のセットに対して検証される。たとえば、１年の期間中に３８事例の不正がある場合、それらの３８の不正事例に関与する各顧客についての需要プロフィールを生成することができるとともに、第１のモデルの検出器をそれらの需要プロフィールに適用することができる。より具体的な例として、第１のモデルが低い中間需要に基づいた検出器のセットを含むとすると（たとえば、中間需要が０であり、最大需要が０であり、中間需要が０であるが最大需要がゼロよりも大きく、中間需要がすべての顧客についての中間需要の最下位から１０パーセンタイル内である）、３８の需要プロフィールのうち１５の需要プロフィールが、第１のモデルによって疑わしいものとして識別される。これは、検出器のこの限られたセットが既知の不正事例の約４０％を把握したことを意味している。この精度は、付加的な独立した検出器をモデルに追加することによってさらに向上させることができる。

ブロック２０８において、疑わしい挙動を伴った未知の事例を判断するために、第１のモデルの検出器が未知の事例（たとえば、既知の不正事例のセットに存在しない他のすべての顧客；顧客の大部分を表わす多くの事例があり得る）に適用されてもよい。これは、疑わしい挙動に関するフラグが立っているのがどの需要プロフィールであるのかを確かめるために、各々の顧客についての需要プロフィールを判断して、需要プロフィールの各々に対抗して検出器のセットを適用することを含み得る。たとえば、未知の事例を表わす４０００００を越える顧客に対応するデータから、３４０００を越える疑わしい挙動の事例が識別され得る。これらの事例はそれまでに既知となり実証された不正事例のセットから相互に排他的となるだろう。さらに、比較的多数のこれらの事例は、従来の方法を用いても検出されなかった不正（これらの疑わしい事例のごく一部だけが不正であったとしても）が行なわれる可能性が最も高いことを示唆している。

このため、図２Ｂから分かるように、複数の検出器２２６は、既知の事例２２２および未知の事例２２４の両方に別個に適用することができる。複数の検出器２２６は、疑わしい挙動を伴った既知の事例２２８を判断するために、モデルを検証する目的で既知の事例２２２に適用することができる。言いかえれば、既知の事例２２２は、複数の検出器２２６が既知の事例２２２の大部分またはすべてを疑わしい挙動であると正確に識別しているかどうかをチェックするために用いることができる。複数の検出器２２６はまた、顧客アカウントまたは疑わしい挙動に関連付けられた未知の事例２３０を識別するために使用して未知の事例２２４に適用することができる。

ブロック２１０において、疑わしい挙動についての正当な説明が、代替的には誤判定ルールエンジンと称され得る第２のモデルにおいて特定され得る。疑わしい挙動を疑わしいものとして除外するために、なぜそれら疑わしい挙動が行なわれたかについての正当な説明を用いることによって、電力不正検出の誤判定率が高くなるという問題を解決することが、第２のモデルのジョブである。疑わしい挙動について考えられ得る正当な説明は以下のとおりである。具体的には、（１）顧客が、需要の低下した太陽電池パネルのユーザであった；（２）機器の故障があった；（３）嵐が発生した；（４）嵐ではなくグリッド過負荷があった；（５）電気事業が、電力会社によってもしくはユーザの要求によって停止された；（６）顧客の需要についての嗜好および好みに変化があった；（７）住居の母集団に変化があった；（８）販売促進キャンペーンもしくは支払請求周期の変更があった；または、（９）顧客がピーク時間中にお金を節約するために発電機を用いた。

ブロック２１２において、未知の事例のいずれかをブロック２１０において特定された正当な説明のいずれかを用いて説明することができるかどうかを確かめるために、第２のモデルが疑わしい挙動を伴った未知の事例に適用され得る。サービスポイントに関する疑わしい挙動についての考えられ得る正当な説明を見出すことができない場合、そのサービスポイントは潜在的な不正行為の候補になる可能性がある。場合によっては、誤判定の説明２３２は、疑わしい挙動を伴った既知の事例２２８および疑わしい挙動を伴った未知の事例２３０の両方に適用することができる。これにより、結果として、未説明の疑わしい挙動を伴った既知の事例２３４のセット（実際の実証された不正を正当な挙動であると誤って判断したときに第２のモデルを検証するためにさらに用いることができる）と、さらなる調査のための未説明の疑わしい挙動を伴った未知の事例２３６のセットとが得られるだろう。したがって、ブロック２１４において、（ブロック２０８において判断された）疑わしい挙動を伴った未知の事例の合計リストから、それらの疑わしい挙動についての正当な説明を含むものと識別された未知の事例を差し引くことができる。残りの未知の事例は、如何なる正当な説明によっても説明することができず、このため、不正である可能性が極めて高い、疑わしい挙動を伴った事例である。ブロック２１６において、不正を実証するために、未説明の疑わしい挙動を伴った残りの未知の事例をいずれをもさらに調査す
ることができる。場合によっては、これは、電力不正検出システム１１０にコンピューティングデバイス１２０への通知の送信を実行させて、調査員１２２にどのサービスポイントまで出向いて調査するべきかを通知すること等によって、不正が行なわれていることを確認するために調査員に出向くように通知することを必要とするかもしれない。

図３Ａは、本開示の実施形態に従った、電力不正検出のために使用できる需要データの例を示す。図３Ｂは、本開示の実施形態に従った、電力不正検出のために使用できる不正データの例を示す。

上記図はともに、データテーブルの実際の見た目となり得るもののうち限られた部分だけを示している。実際には、データテーブルは、何十万または何百万ものエントリーを含んでいてもよい。データテーブルのサイズは、顧客の数が増えてそれらの毎日の需要がさらにより長い期間にわたって追跡されるのに応じて、幾何学的に増加し得る。場合によっては、データの合計サイズが、ギガバイトまたはテラバイトのデータを上回る可能性もあり、暗算するかまたは紙とペンとを用いて計算するために、人がデータをすべて利用することが不可能になるだろう。このため、本開示のシステムおよび方法は、従来の方法を用いて識別することができないであろう潜在的な不正の多数の事例を識別するために、膨大な量のデータについてのデータ駆動型分析を可能にする。

上記図はともに値を指数表現で示している。これは、例示のみを目的としたものであって、実際には、データテーブルは如何なるタイプのフォーマットで値を格納していてもよい。いくつかの実施形態においては、データテーブルにおけるデータの処理は、データを読出してデータをクリーンにすることを含み得る。データをクリーンにすることは、値を指数表現で表示されるように変換するか、または、サービス日付を月／日／年のフォーマットに変換するなどの、値を異なるフォーマットに変換することを含み得る。

図３Ａに関して、この図は、複数の電気事業顧客に関連付けられた需要データを含むデータテーブルを未処理の状態で示している。いくつかの実施形態においては、１人の顧客によって毎日用いられる電力需要が既知となるように、各々の顧客ごとに毎日の需要データが存在してもよい。いくつかの実施形態においては、データテーブルは、欄３０２、欄３０４、欄３０６、欄３０８、欄３１０、欄３１２、欄３１４および欄３１６などの欄によって分類されるデータ項目の行を含んでもよい。図に示されない電気事業顧客に関する他のデータも、データテーブルに含まれていてもよい。

いくつかの実施形態においては、（「ｓｐ＿ｉｄ」という見出しで示される）欄３０２は、サービスポイントの別個の識別番号に対応するサービスポイントｉｄであってもよい。サービスポイントは特定の顧客についての電力メータであってもよい。したがって、サービスポイントｉｄは特定の顧客を識別するために用いられてもよい。たとえば、４０００００の顧客を含むデータテーブルにおいては、４０００００の固有のサービスポイントｉｄがあり得る。しかしながら、各々の顧客が追跡された各サービス日付についてのデータの行を有し得るので、４０００００を超える行がデータテーブルに存在し得ることに留意されたい。たとえば、１００のサービス日付についてのデータを有していた顧客は、データテーブルにおける１００の行のデータ（これらすべてがその顧客のサービスポイントｉｄを有している）に関連付けられるだろう。さらに、顧客が電力サービスを受取る複数のアドレスを有している場合、その顧客に帰属する複数のサービスポイントが存在し得るだろう。これは有用である。なぜなら、１つの不動産に関して不正を犯している複数のアドレスを有する或る顧客が、それらの他の不動産に関して不正を犯している可能性が非常に高いからである。

いくつかの実施形態においては、（「需要」という見出しで示される）欄３０４は、特
定のサービス日付についての顧客の需要または電力使用量であり得る。この需要は、如何なる好適な単位またはメトリックでも測定することができる。このような実施形態のうちのいくつかにおいては、この需要はキロワット時（ｋＷｈ）で測定されてもよい。たとえば、データの行における「４．１」という需要値は、その行についての特定の顧客が（欄３０６において示された）その特定のサービス日付に４．１ｋＷｈを用いたことを表わし得る。したがって、データテーブルにおいて示される需要値は、毎日の使用量に対応していてもよい。しかしながら、他の実施形態においては、需要値は必ずしも日毎の分解能を有するわけではない。たとえば、需要値は、時間毎、分毎、週毎などの単位で追跡することができる。

いくつかの実施形態においては、（「ｓｅｒｖｉｃｅ＿ｄａｔｅ」という見出しで示される）欄３０６は、日・月・年フォーマットのサービス日付であってもよい。たとえば、「０１０３２０１７」の値は２０１７年１月３日に対応し得る。しかしながら、年／月／日フォーマット、月／日／年フォーマットなどを含むがこれらに限定されない特定のサービス日付に言及するために、他の如何なる好適なフォーマットが用いられてもよい。上述の例においては、「４．１」の需要値および「０１０３２０１７」のサービス日付を有するデータの行は、その行のサービスポイントｉｄに関連付けられた顧客が２０１７年１月３日に４．１ｋＷｈを利用したことを示すだろう。

いくつかの実施形態においては、サービス日付はさらに、構文解析されてもよく、または、特定の四半期、月、週の数、およびその週の特定の日に分解されてもよい。たとえば、データクリーニングプロセス中に、サービス日付の年を決定して、（「ｙｒ」という見出しで示される）欄３０８において表示することができる。サービス日付の四半期を決定して、（見出し「ｑｔ」で示される）欄３１０において表示することができる。サービス日付の月を決定して、（「ｍｎ」という見出しで示される）欄３１２において表示することができる。サービス日付の週の数を決定して、（「ｗｄ」という見出しで示される）欄３１４において表示することができる。サービス日付の週の日を決定して、（「日」という見出しで示される）欄３１６において表示することができる。たとえば、サービス日付が日曜日（Sunday）である場合、欄３１６における値は「１」になり得るか、または、サービス日付が土曜日（Saturday）である場合、欄３１６における値は「７」になり得る。

図３Ｂに関して、この図は、複数の電気事業顧客に関連付けられた不正データを含むデータテーブルを未処理の状態で示す。いくつかの実施形態においては、データテーブルは、欄３２０、欄３２２および欄３２４などの欄によって分類されるデータ項目の行を含んでいてもよい。したがって、このデータテーブルにおけるデータの各行は、不正（たとえば電力窃盗）の事例に関係し得る。図に示されない不正の発生率に関する他のデータも、データテーブルに含まれていてもよい。

いくつかの実施形態においては、（「ｆｒａｕｄ＿ｄａｔｅ」という見出しで示される）欄３２０は、不正の発生が検出されたサービス日付であってもよい。いくつかの実施形態においては、欄３２０における値のフォーマットは、欄３０６において示されるサービス日付の値（たとえば日・月・年フォーマット）と同じフォーマットであってもよい。たとえば、「０１０３２０１７」の値は、データ行に示される特定の顧客について不正が検出されたサービス日付としての２０１７年１月３日に対応していてもよい。しかしながら、上述したように、他の如何なる好適なフォーマットが特定のサービス日付に言及するために用いられてもよい。

いくつかの実施形態においては、（「合計」という見出しで示される）欄３２２は不正に関連付けられた合計のドル金額であってもよい。言いかえれば、欄３２２は、盗まれた電力量に基づいて、不正のせいで電力会社にどれだけの費用がかかったかを示していても
よい。

いくつかの実施形態においては、（「ｓｐ＿ｉｄ」という見出しで示される）欄３２４は、不正が検出されたサービスポイントのサービスポイントｉｄであってもよい。言いかえれば、このサービスポイントｉｄは特定の顧客に対応していてもよい。欄３２４におけるこれらの値は、不正データ（たとえば図３Ｂのテーブル）を、サービスポイントｉｄ（たとえば欄３０２）をも有する顧客の需要データ（たとえば図３Ａのテーブル）と結びつけるために用いられてもよい。たとえば、（検出された不正の発生に対応する）図３Ｂのデータテーブルにおけるデータの行に関して、サービスポイントｉｄ（たとえば「１２３４５６７」）が示されている。そのサービスポイントｉｄは、任意の利用可能なサービス日付について、そのサービスポイントｉｄに関する日毎の需要データをすべて見出すために、対応する需要データ（たとえば、図３Ａ）において検索することができる。このクエリは、たとえば、そのサービスポイントｉｄについての２０１５年における日毎の需要データを見出すためにさらに範囲を狭められてもよく、その基準に適合した３６５行もの需要データが存在するだろう。

図４Ａは、本開示の実施形態に従った、電力不正検出のために使用できる例示的な分布テーブルを示す。

上述したように、顧客需要プロフィールから疑わしい挙動を識別するために、さまざまな検出器を用いることができる。上述の検出器の一例は、期間にわたる顧客についての中間需要がすべての顧客にわたる中間需要の最下位から１０パーセンタイル内である挙動パターンを含んでいた（たとえば、顧客の母集団のうち少なくとも９０％がより大きな中間需要を有していた）。静的な値ではなく分位数を用いて検出器を規定することに伴う利点がいくつか存在し得る。たとえば、１０パーセンタイル、中間値、９０パーセンタイルなどに関連付けられた値が時間とともに変化する可能性がある。顧客の母集団全体は、冬季の数か月（暖房用）または夏季の数か月（冷房用）などの間にわたって追加の電力を用いてもよい。このため、母集団レベルでの需要についての季節性および傾向が存在するかもしれない。１０ｋＷｈの中間需要を有する顧客は、母集団における他の顧客の需要の変化に応じて、低需要または高需要と見なされてもよい。しかしながら、任意の分布のうちの１０パーセンタイルは、その数学的定義（たとえば、時間のうち１０％未満で発生する）に鑑みればまれなイベントであるかもしれない。したがって、総需要が母集団レベルにおいてどのように変化するかにかかわらず、母集団需要の１０パーセンタイル未満の需要を呈する顧客は常に低需要を有するものとして見なされるだろう。なぜなら、母集団のうち９０％がより大きな需要を有しているからである。

言いかえれば、「１０ｋＷｈ」のしきい値を有する検出器を規定することにより、特定の顧客が有する需要が、日付に応じたしきい値未満であるか、季節に応じたしきい値未満であるか、または特定された期間に応じたしきい値未満であるかについて影響を及ぼす可能性がある。代替的には、パーセンタイルに基づいた検出器の使用は、顧客の需要プロフィールが必然的に他のすべての顧客の需要プロフィールと比較されることを意味しており、各々の顧客の挙動は、すべての人と比べて低い需要であるかまたはまれであると判断され得る。たとえば、すべての人の使用量が増加していたが、需要が増加しておらずそのアカウントがオフにされていなかった特定の顧客が１人いた場合、報告されたすべての人の電力使用量をフラットにするレギュレータを備えることにより、この特定の顧客が電力を盗むことが可能になるだろう。

上述の例においては、１０パーセンタイルは、どのような挙動が母集団においてまれであると見なされ得るかについてのしきい値として選択された。しかしながら、他のいずれのしきい値が用いられてもよい（たとえば、１５パーセンタイルを下回る中間需要は低い
と見なされてもよい）。しきい値が低ければ低いほど、挙動は母集団においてよりまれなものとして示され得る。たとえば、１０パーセンタイルを下回る中間需要を有する顧客よりも５パーセンタイルを下回る中間需要を有する顧客の方が少ない可能性があり、かつ、５パーセンタイルを下回る中間需要を有する顧客は不正を犯す可能性がより高くなり得る。しかしながら、しきい値をあまりに低く設定すると、結果として、そのしきい値内の挙動を伴う顧客をほんのわずかしか（または全く）見出せない可能性がある。たとえば、しきい値が１パーセンタイルと設定される場合、１パーセンタイル未満の中間需要を有する顧客がゼロになる可能性がある。しきい値を１０パーセンタイルなどとより高く設定することで、モデルによって識別される顧客が十分に存在することが確実にされる。これにより、しきい値の設定に関してはトレードオフが得られる可能性がある。トレードオフは、潜在的に不正を行なう可能性のあるより少数の顧客を識別する（および、潜在的には極少数の顧客しか識別されない）こと、または、誤判定率の上昇を犠牲にして潜在的に不正を行なう可能性のより高い顧客を識別することとの間でなされる。

いくつかの実施形態においては、自動的にしきい値を設定して、これらのさまざまな問題点のバランスを取るように構成されたアルゴリズムが存在し得る。いくつかの実施形態においては、アルゴリズムは、検出器を用いて疑わしい挙動を有するものとして識別されるように最小数の顧客に基づいてしきい値を設定するように構成されてもよい。言いかえれば、アルゴリズムは、疑わしい挙動を伴う最小数の顧客が選択され得るようにパーセンタイルを選択してもよい。たとえば、しきい値を下回る中間需要に基づいて疑わしい挙動を有するものと識別される最小限の２０の顧客が存在するはずであることが規定され得る。顧客の母集団全体についての需要プロフィールの分布に基づいて、アルゴリズムは、少なくとも２０の顧客がしきい値を下回る中間需要で識別されるように、当該しきい値を設定することができる。これは不正を調査する観点から有用になり得る。なぜなら、識別された潜在的に不正な顧客のうち何人を調査することができるかについては限界があるかもしれないからである。たとえば、図１における調査員１２２は、１２の顧客を訪問することができるリソースだけを有しているかもしれない。疑わしい挙動を伴う２０の顧客を識別するためのしきい値を設定するようにアルゴリズムを構成した結果、未説明の疑わしい挙動を伴った顧客のリストがさらにより小さなものになる可能性がある（たとえば、識別された顧客のうち８の顧客が太陽エネルギのユーザである場合、未説明の疑わしい挙動を伴う１２の顧客が残ることとなるだろう）。しかしながら、未説明の疑わしい挙動を伴う顧客のこのより小さなリストはすべて、場合によっては調査員１２２によって調査され得る。このため、当該アルゴリズムは、調査員１２２のリソースまたは稼働率に従って、疑わしい挙動を伴う識別された顧客の数と、未説明の疑わしい挙動を伴う識別された顧客の数とを調整するために用いることができる。

なお、パーセンタイルを用いて規定される検出器を実現するために、顧客需要プロフィールの分布が、顧客の挙動を他の人すべてに対してランク付けすることを可能にするように決定されなければならないことに留意されたい。これは、或るセットにおける顧客のすべての需要プロフィールについての分位数分布および経験的累積分布関数（empirical cumulative distribution function：ＥＣＤＦ）を計算してプロット化することによって行うことができる。

たとえば、図４Ａに関して、（分位数分布を示す）分布テーブルは、或る期間における（たとえば１年の間にわたる）３８の不正な顧客のセットにおける各顧客の中間需要について示されている。図に示される分布テーブルは、各々の顧客についての中間要求（または需要プロフィールの他の任意のアスペクト）がどのようにさまざまなパーセンタイル範囲にバケット分割され得るかを示している。

それらの３８の不正事例についての対応するデータは、図３Ｂに示されるのと同様のデ
ータテーブルに格納されるだろう。それらの３８の不正事例についてのサービスポイントｉｄは、その年にわたってそれらのサービスポイントに関連付けられた需要データ（たとえば、２０１５年における需要データ）を照会するために用いることができる。このため、２０１５年の日毎の日々の要求が、それらの３８のサービスポイントｉｄごとに識別されるだろう。各々のサービスポイントｉｄごとに、そのサービスポイントｉｄに関連付けられた挙動プロフィールを計算するためにその期間にわたる日毎の需要をさらに用いることができる。たとえば、各サービスポイントｉｄは、アカウントがアクティブであった日数、当該期間にわたる中間要求、当該期間わたる最大需要、当該期間にわたる最小需要などに関連付けられるだろう。言いかえれば、「１２３４５６７」のサービスポイントｉｄに関して、アカウントが５００日間アクティブであったこと、その１年にわたって４ｋＷｈの中間需要があったこと、その１年にわたって０ｋＷｈの最小需要があったこと、およびその１年にわたって２０ｋＷｈの最大需要があったことが判断され得る。

図４Ａを参照すると、不正事例は、それらの需要プロフィールのメトリックに基づいて分類して順序付けることができる。たとえば、３８の不正事例はすべて、対応する３８のサービスポイントｉｄの各々に関連付けられた中間需要に基づいて、小さいものから大きいものへと順序付けることができる。最小需要または最大需要などの如何なるメトリックが用いられてもよいが、図は例示を目的として中間需要に基づいている。不正事例のすべてに対応する中間需要が分布を構成しており、これを用いて、各々の不正事例についての中間需要が分布のどこに位置しているかに基づいて、不正事例をさまざまなバケットに配置することができる。次いで、不正事例をさまざまなバケット内に配置した結果が、欄４０２、欄４０４および欄４０６によって分類された多数の行を有するものとして示される図４Ａに示されるデータテーブルにおいて報告されている。

いくつかの実施形態においては、（「分位数」という見出しで示される）欄４０２が、場合によっては分布についての分位数であり得る、分布についての或るバケットを示すために用いられてもよい。たとえば、データテーブルの行「ａ」は、欄４０２の下の「０」の値を有しており、データテーブルのおよび行「ｂ」は欄４０２の下の「１」の値を有している。このため、データテーブルの行「ｂ」は、中間需要の「０」と「１」の分位数との間の中間需要を有する不正事例に関係している可能性がある。欄４０２の下の「１００」の値を有する最後の行は、中間需要の「７５」（先の行の値）の分位数と「１００」の分位数との間の中間需要を有する不正事例の数を示すだろう。

いくつかの実施形態においては、（「ｍｅｄ＿ｄｅｍａｎｄ」という見出しで示される）欄４０４は、特定の分位数に関連付けられた中間需要を示していてもよい。たとえば、データテーブルの行「ｆ」は、欄４０４の下の０の値を有しており、これは、不正事例の中間需要が２０パーセンタイルのバケットにおいてゼロであることを示すだろう。上述のように、挙動プロフィールのうちの好適なメトリックをいずれも、最小需要、最大需要などを含め、中間需要の代わりに用いることができる。

いくつかの実施形態においては、（「数」という見出しで示される）欄４０６は、テーブルの行によって示されるバケットに存在する観察結果の数を示していてもよい。このため、例示的なデータテーブルにおいては、ゼロであると判断される中間需要の２０パーセンタイルのバケット内において１９の観察結果が存在する。不正についての３８の観察結果のうちの９つは、３４．５１４５の値を有すると判断される、中間需要の７５パーセンタイルのバケットの範囲内にある。

図４Ｂは、本開示の実施形態に従った、電力不正検出のために使用できる例示的な分布プロットを示す。より具体的には、図は、図４Ａからの３８の不正な顧客についての中間需要に対応する経験的累積分布関数（ＥＣＤＦ）の例示的なプロットを示す。図４ＢのＥ
ＣＤＦおよび図４Ａの分布テーブルはともに、０％から１００％の範囲にわたっており、１００％は観察結果のすべてを示している。

図４ＢのＥＣＤＦは、不正事例についての累積分布関数を自動的に計算することに基づいており、各データポイント（たとえば、顧客についての中間需要）がどのように他のすべてのデータポイントと比べて低下するか（たとえば、その中間需要が如何に他のすべての観察結果からの中間需要に匹敵しているか）を表わしている。これは観察結果をランク付けするのに有用である。なお、各々の顧客の分布が時間とともに変化しており、需要が季節的なものであり、これは冬季、夏季などにおいて変化し得ることを意味していることに留意されたい。

このため、ＥＣＤＦでは、顧客の需要プロフィールを、１回の表示で、母集団の残りの需要プロフィールに対して比較することができる。上述したように、これは、まれなイベントの定義が時間とともに変化する可能性がある（たとえば、夏季におけるまれなイベントが冬季においては通常のイベントになり得るとともに、この逆の場合もまた同様に可能である）ので、有用である。これに比べて、機械学習アルゴリズムはこれらの変化を考慮に入れることができないだろう。なぜなら、機械学習アルゴリズムは、過去のパターンを将来に向けて予測するために記憶することしかできないからである。さらに、人々は、監視されると自身の挙動を変更し、結果として、機械学習アルゴリズムが説明することができない分布の変化がもたらされることとなる。

ＥＣＤＦはまた、顧客の電力使用量の特徴をランク付けするのに有用である。ＥＣＤＦから、顧客の需要プロフィールが互いに対してどのようなランクに位置しているかと、それらの分布が時間とともにどのように変化するかとを判断することができる。顧客需要プロフィールのさまざまなメトリクスについてのＥＣＤＦの変化は、たとえば、顧客母集団全体の挙動が１２月から１月の間にどのように変化したか確かめるために閲覧することができる。顧客の母集団全体の挙動を追跡し、母集団の典型的な挙動と対照させて各々の顧客の挙動を考慮することにより、不正の検出を増やすことが可能となり得る。これは、不正の実行を可能にするさまざまな方法があることに起因している。すべての不正事例が、報告される使用量がゼロとなるように顧客が電力使用の計測を避けるかまたは停止させるというシナリオを含んでいるとは限らない。むしろ、顧客は、報告される需要の減少を防止するためにレギュレータを用いてもよいが、顧客は、実際には、報告されるよりも多くの電力を用いることができるだろう。この場合、その顧客の需要プロフィールを単に閲覧することによって不正を検出することは困難であるだろう。その顧客の需要プロフィールは、顧客の需要が増加したはずであるが不正行為のせいで増加しなかったことを判断するために、他の顧客の需要プロフィールと比較されなければならないだろう。この態様であれば、本開示の実施形態は、顧客（たとえば、上述の例においてレギュレータを使用し始める顧客）の挙動の変化を考慮に入れて、それらの挙動の変化を検出することができる。これらの挙動変化は不正行為の点でかなり共通しているが、これは、機械学習モデルを開始させるには正確でなく、それらのモデルを頻繁に更新させなければならない理由である。

要約すると、パーセンタイルに基づいて検出器を規定することは、まれなイベントが事前に特定されているのではなく、むしろ、母集団にわたる需要プロフィールから派生されていることを意味している。たとえば、１０パーセンタイルを下回る中間需要が、母集団の９０％未満となるであろう１０未満ｋＷｈの中間需要に対応していると判断されてもよい。

図５は、本開示の実施形態に従った、電力不正検出のために使用できる例示的な分布テーブルを示す。

より具体的には、４０６３８８の顧客のセット（たとえば、未知のセット）に関して例示的な分布テーブル５００が示される。この場合、３４７１９の需要プロフィールが、１０未満ｋＷＨの中間需要に対応する母集団の１０パーセンタイル未満である中間需要の検出器を用いて、既知の不正事例と同じ挙動特徴を有するものと識別された。なお、テーブル５００における数をすべて合計した結果、（３４０００までのプロフィールとは異なる）約３８０００までのプロフィールが得られることとなる。これは、アカウントのいくつかインアクティブであることと、検出器がアクティブとインアクティブとの区別（ＦＰルールエンジンのジョブである）を行なわないことと、によって説明することができる。

このシナリオにおいては、母集団のうち９８％未満の中間需要を有した１８９８２の需要プロフィールが存在していることを行「ｃ」において認識することができる。また、バケットが完全にスキップされると、母集団の１パーセンタイルにおいて需要プロフィールが存在しないことも、行「ｂ」において認識することができる。

図６Ａは、本開示の実施形態に従った、顧客の例示的な需要プロフィールを示す。図６Ｂは、本開示の実施形態に従った、顧客の需要についての例示的なグラフを示す。

図６Ｂに示されるように、グラフ６００は、顧客の需要データに基づいており、５００日を越える期間にわたって日毎ベースのキロワット時（ｋＷｈ）で顧客の需要（または電力使用量）を示している。顧客の需要が日毎に大幅に変化し得るので、その変化をグラフにおいて見ることができる。

この需要データは、顧客の需要プロフィールに含まれる多数のメトリクスを計算するために用いることができる。たとえば、この特定の顧客の需要プロフィールは、その期間にわたる０ｋＷｈの最小需要、その期間にわたる１ｋＷｈの中間需要、その期間にわたる５４ｋＷｈの最大需要、その期間にわたる６．７０４ｋＷｈの中間需要、その期間にわたる０ｋＷｈの第１分位数の需要、および、その期間にわたる５ｋＷｈの第３分位数の需要、によって規定されてもよい。これらの値は、図６Ａに示される顧客の需要プロフィールに反映されている。顧客の需要プロフィールにおける大きなスパイクが平均需要を歪める可能性があることが分かっており、このため、実際には、メトリックのような中間値を用いることが、歪みについての潜在的な問題を回避するのに有用となり得る。

したがって、需要プロフィールのこのような生成は、１セットにおける顧客ごとに、その顧客についての需要データを用いて、ループにされて実行することができる。各顧客がアクティブであった日数は、特定された期間にわたって、それらの中間需要、それらの最大需要、それらの最小需要などとともに計算することができる。

図７は、本開示の実施形態に従った例示的な結果テーブルを示す。
結果テーブル７００は、既知の不正事例のうちどれが検出器によって識別されたかを判断するために、既知の不正事例に検出器を適用することなどによって、電力不正を検出する際に用いられるモデルを検証するために用いることができる。たとえば、（中間および最大の需要が常に０である、中間需要は０であるが最大需要がゼロよりも大きく、かつ、中間需要がゼロと１０パーセンタイルとの間である）３つの検出器のセットが低い需要に関連付けられた需要プロフィールを識別するために用いられるシナリオについて検討する。これらの検出器は、それらの既知の事例のうちいくつが検出器についての疑わしい挙動を呈したかを確かめるために、１２３の既知の不正事例のセットに適用することができる。これらの検出器はまた、それらの未知の事例のうちいくつが検出器についての疑わしい挙動を呈したかを確かめるために、４０６３８８の顧客のセットに適用することができる。上述の例においては、既知の不正事例のうち同じ挙動特徴を呈した３４７１９の需要プ
ロフィールが存在したことが述べられた。したがって、結果テーブル７００においては、欄７０２、欄７０４および欄７０６は、３つの検出器のうちの１つを用いて検出された１２３の既知の不正事例の数に対応し得る。欄７０８、欄７１２および欄７１２は、３つの検出器のうちの１つを用いて識別された未知のもののうち３４７１９の需要プロフィールの数に対応し得る。結果テーブル７００の行７２４および行７２６は、顧客のロットサイズが５００平方フィート未満であることに起因して、または顧客が太陽エネルギのユーザであることに起因して、その疑わしい挙動がうまく説明され得る検出された事例の数に対応し得る。顧客が太陽エネルギのユーザであることは、低い需要に関連付けられてもよい。なぜなら、その顧客は、電力を盗むのではなく太陽から電力を獲得し得るからである。５００平方フィート未満のロットサイズを有する顧客も、低い需要に関連付けられるだろう。なぜなら、顧客の小規模な住居が、需要であり得るものに対して上限を加えるからである。

（「ｆｒａｕｄ＿ａｌｗａｙｓ＿ｚｅｒｏ」という見出し付きの）欄７０２は、１２３の既知の不正事例のうちいくつが、常にゼロである中間および最大の需要を有するものとして識別されたかを規定し得る。たとえば、結果テーブル７００においては、１２３の既知の不正事例のうちの２つが、常にゼロである中間および最大の需要を有するものとして識別されたことが示されている。それらの２つの識別された既知の不正事例のいずれも、顧客が５００平方フィート未満のロットサイズを有することまたは太陽エネルギのユーザであることに基づいて、説明可能とはならなかった。

（「ｆｒａｕｄ＿ｍｅｄ＿ｚｅｒｏ」という見出し付きの）欄７０４は、１２３の既知の不正事例のうちのいくつが、ゼロの中間需要を有するとともに０よりも大きい最大需要を有するものとして識別されたかを規定し得る。たとえば、結果テーブル７００においては、１２３の既知の不正事例のうちの７つが、ゼロの中間需要を有するとともに０よりも大きい最大需要を有するものとして識別されたことが示されている。これらの識別された７つの既知の不正事例はいずれも、顧客が５００平方フィート未満のロットサイズを有していること、または、太陽エネルギのユーザであることに基づいて、説明可能とはならなかった。

（「ｆｒａｕｄ＿ｎｅａｒ＿ｚｅｒｏ」という見出し付きの）欄７０６は、１２３の既知の不正事例のうちいくつが、ゼロと１０パーセンタイル（ここでは、１０ｋＷｈ）との間の中間需要を有するものとして識別されたかを規定し得る。たとえば、結果テーブル７００においては、１２３の既知の不正事例のうちの６つが、ゼロと１０パーセンタイルとの間の中間需要を有するものとして識別されたことが示されている。これらの識別された６つの既知の不正事例はいずれも、顧客が５００平方フィート未満のロットサイズを有していること、または太陽エネルギのユーザであることに基づいて、説明可能とはならなかった。

（「ｕ＿ａｌｗａｙｓ＿ｚｅｒｏ」という見出し付きの）欄７０８は、未知のセットから検出された３４７１９の事例のうちいくつが、常にゼロである中間および最大の需要を有するものとして識別されたかを規定し得る。たとえば、結果テーブル７００においては、３４７１９の検出された不正事例のうちの６５５６が、常にゼロである中間および最大の需要を有するものとして識別されたことが示されている。これらの検出された不正事例のうちの６つは、顧客が５００平方フィート未満のロットサイズを有することに基づく正当な説明を有していた。

（「ｕ＿ｍｅｄ＿ｚｅｒｏ」という見出し付きの）欄７１０は、未知のセットから検出された３４７１９の事例のうちのいくつが、ゼロの中間需要を有するとともに０よりも大きい最大需要を有するものとして識別されたかを規定し得る。たとえば、結果テーブル７
００においては、３４７１９の検出された不正事例のうち６３７５がゼロの中間需要を有するとともに０よりも大きい最大需要を有するものとして識別されたことが示されている。これらの検出された不正事例のうちの２つは、顧客が５００平方フィート未満のロットサイズを有することに基づく正当な説明を有していた。

（「ｕ＿ｎｅａｒ＿ｚｅｒｏ」という見出し付きの）欄７１２は、未知のセットから検出された３４７１９の事例のうちいくつが、ゼロと１０パーセンタイルとの間の中間需要を有するものとして識別されたかを規定し得る。たとえば、結果テーブル７００においては、検出された３４７１９の不正事例のうちの２１７８８が、ゼロと１０パーセンタイルとの間の中間需要を有するものとして識別されたことが示されている。これらの検出された不正事例のうち９つは、顧客が５００平方フィート未満のロットサイズを有することに基づいた正当な説明を有しているとともに、検出された不正事例のうちの１０は、顧客が太陽エネルギのユーザであることに起因していた。

図８Ａは、本開示の実施形態に従った、未知の不正事例において検出された低い中間需要の例示的なグラフを示す。

より具体的には、図は、３００日を越える期間にわたって非常に低い中間需要の挙動パターンに基づいて検出器を用いてフラグが立てられたサービスポイントにおける需要のグラフを示す。グラフは最大需要におけるスパイクを含んでいるが、中間需要は、大部分が比較的低いものと見なすことができる。これは、（図８Ｂに示される）既知の不正インシデントと同様の挙動を伴う未知の事例（たとえば、不正であるとしてそれまで識別されていない顧客）のセットにおいてフラグが立てられている不正の事例であるとともに、これは、従来の方法に基づいたトレーニングデータセットを用いて識別されなかったであろう不正の事例の例を表わしている。

図８Ｂは、本開示の実施形態に従った、既知の不正事例において検出された低い中間需要の例示的なグラフを示す。

この図は、同様に、３００日を越える期間にわたって非常に低い中間需要の挙動パターンに基づいて検出器を用いてフラグが立てられたサービスポイントにおける需要のグラフを示している。グラフは、初めはより高いレベルの需要を有しているが、約１００日間のアカウント年に対応する不正の日付において、需要が劇的に低下し、グラフの残り部分においては非常に低いままである。これは、既知の事例（たとえば、不正なものとして既に実証された顧客）のセットにおいてフラグが立てられた不正の事例であって、このため、不正のこの事例に関連付けられた総収入の損失が既知となっている。検出器が不正のこの既知の事例にフラグを立てることは再確認をもたらす。なぜなら、検出器が従来の方法から識別された不正の検証された事例に正確にフラグを立てていることを示しているからである。

図９Ａは、本開示の実施形態に従った、未知の不正事例において検出されたゼロの中間需要の例示的なグラフを示す。

より具体的には、図は、３００日を越える期間にわたってゼロである中間需要の挙動パターンおよび０よりも大きい最大需要の挙動パターンに基づいて、検出器を用いてフラグが立てられたサービスポイントにおける需要のグラフを示している。グラフは、初めは比較的高い需要から始まっているが、需要は直ちにゼロにまで低下して、グラフの残りにおいてはそこに留まっている。これは、（図９Ｂに示される）既知の不正インシデントと同様の挙動を伴った未知の事例（たとえば、不正なものとしてそれまでに識別されていない顧客）のセットにおいてフラグが立てられている不正の事例であって、これは、従来の方
法に基づいたトレーニングデータセットを用いて識別されなかったであろう不正の事例の例を表わしている。

図９Ｂは、本開示の実施形態に従った、既知の不正事例において検出されたゼロの中間需要の例示的なグラフを示す。

この図は、同様に、３００日を越える期間にわたってゼロである中間需要の挙動パターンおよびゼロよりも大きい最大需要の挙動パターンに基づいて検出器を用いてフラグが立てられたサービスポイントにおける需要のグラフを示している。このグラフは、初めにより高いレベルの需要を有しているが、需要が劇的に低下する。これは、既知の事例（たとえば、実際の実証された既知の不正事例）のセットにおける検出器によってフラグが立てられた不正の事例であって、再確認をもたらしている。なぜなら、検出器が従来の方法から識別された実証された不正事例に正確にフラグを立てていることを示しているからである。このような既知の不正の事例の場合、従来の方法を用いて不正を実際に検出するには、疑わしい挙動が始まった日付から２００日を上回る時間を要した。それに比べて、このタイプの挙動を検出するように構成された検出器は、疑わしい挙動が始まった後、はるかに迅速に不正を識別することができる可能性がある。

図１０は、本開示の実施形態に従った、疑わしい挙動の正当な説明に対応する例示的なフィールド活性フラグを示す。

より具体的には、図は、或るアクティビティがサービスポイント上において実行されるたびにシステムによって生成され得るフィールド活性フラグを含むテーブルを示す。これらのアクティビティは電力会社、顧客または環境の結果として生成することができる。それらのアクティビティに対応する活性フラグは、不正の行なわれる前、最中および／または後に発生し得るとともに、疑わしい挙動を除外するための正当な説明を判断するために用いることができる有益な情報を提供し得る。このため、活性フラグを組込むことは、検出フレームワークを改善させ得るとともに、誤判定の識別を支援し得る。たとえば、不正の日付で発生し得る１つの活性フラグは「メータが切断－支払なし」であって、顧客の支払い不履行のせいで、関連付けられたサービスポイントのサービスがカットされたことを示すだろう。フィールド活性フラグの他の例を図において確認することができる。

フィールド活性フラグ以外の他の情報が、誤判定（たとえば、疑わしい挙動についての正当な説明のソース）を識別し易くするために用いられてもよい。いくつかの実施形態においては、電力不正検出システムは、調査および／または国勢調査情報を用いることができてもよい。たとえば、調査表が顧客に送られてもよく、これら調査表から、特定の近隣に住んでいる特定の所得層の人々がより環境意識の高い（たとえば、環境に優しい）傾向があると判断され得る。加えて、このデータは、連続的にリアルタイムで顧客のソーシャルメディアから収集され得る。場合によっては、環境意識の高い人にとって典型的な需要プロフィールを判断して、比較の目的（たとえば、これは環境意識の高い人の挙動である）で用いることができる。いくつかの実施形態においては、この判断は機械学習アルゴリズムを用いて行うことができる。このため、疑わしい挙動を有する任意の識別された顧客の挙動は、疑わしい挙動についての正当な説明のうちの１つが顧客の環境意識が高いことであるかどうかを判断するために、環境意識が高い人であることが知られている顧客の挙動と比較することができる。したがって、誤判定を識別するためにシステムによって用いられる情報は、調査、ソーシャルメディア、需要プロフィールから集められた仮定の組合せから、および／または計測技術自体から、得られてもよい。

いくつかの実施形態においては、この明細書中に開示される電力不正検出システムの出力は、全体的に新しいシステムの開発を可能にするように使用可能であり得る。これらの
システムが本質的に依存性を有しているために、既存の方法（たとえば、機械学習または専門家ベースのシステム）によってこのようなシステムが開発されるのが妨げられている。なぜなら、それら方法では、データ駆動型の数学的に厳密な態様で正確に確率に到達することができず、スケール変更されておらず、かつ、実際には不可能であるかもしれない（たとえば、人が有意義な影響をもたらす回答に達するのに時間がかかりすぎるであろう）からである。

いくつかの実施形態においては、電力不正検出システムは、システムのユーザ（たとえば、検出器または誤判定の説明を規定する誰か）からのドメイン知識を必要することなく仮説が生成されてテストされ得るように、自動的な仮説生成を可能にするように構成されてもよい。先に述べたように、ユーザは、挙動のパターン（たとえば検出器）を、需要プロフィールにおいて検出する際の見え方で規定し得る。または、ユーザは、誤判定ルールエンジンにおける疑わしい挙動についての正当な説明を規定してもよい。自動的な仮説生成のために構成されたシステムの実施形態においては、ユーザは継続的に検出器および／もしくは誤判定ルールを規定してもよく、または、それらは、システムが、検出についての仮説に自動的に到達するとともにエンド・ツー・エンドで自律的にプロセス全体を実行することを可能にし得る（たとえば、システムは、疑わしい挙動を有する顧客の検出を自動的に実行し得るとともに、誤判定ルールエンジンを用いていずれの正当な挙動もうまく説明し、さらに、未説明の疑わしい挙動を伴う顧客の結果を生成し得る）。

図１１は、本開示の実施形態に従った、電力不正の検出を実現するためのブロック図である。

いくつかの実施形態においては、電力不正検出システムについての解決実現例はビッグデータクラウドプラットフォーム１１１０を含み得る。いくつかの実施形態においては、ビッグデータクラウドプラットフォーム１１１０は、電気使用量データをすべて、標準フォーマット１１２２でオブジェクトストア１１２０に格納し得る。

いくつかの実施形態においては、オブジェクトストア１１２０が維持されて、ビッグデータクラウドサービス１１４０を介して提供されてもよい。いくつかの実施形態においては、ビッグデータクラウドサービス１１４０は、Cloudera（登録商標）１１４２、オープンソースのApache Hadoop分布を含み得る。これにより、オブジェクトストア１１２０に
含まれるデータは、Apache Hadoop、分散型ストレージのために用いられるオープンソー
スソフトウェアフレームワーク、および大型のデータセットの処理を用いて格納されてもよい。オブジェクトストア１１２０に含まれるデータは分割されて、コンピューティングクラスタにおけるノードにわたって分散された大型のブロックに格納され得る。いくつかの実施形態においては、ビッグデータクラウドサービス１１４０はさらにエンタープライズＲ１１４４を含み得る。エンタープライズＲ１１４４は、オブジェクトストア１１２０内に含まれている大量のデータに関して、Ｒ、すなわちオープンソース統計プログラミング言語および環境、の使用を提供する。エンタープライズＲ１１４４は、顧客の電気使用パターンにおける不正な挙動の存在を検出するためにこの例において用いることができる自動化されたデータ分析の開発および展開を可能にし得る。

図に示されるように、ビッグデータクラウドプラットフォーム１１１０は、バルクソースデータ１１５０およびストリーミングソースデータ１１５２を受信し得る。一般に、バルクソースデータ１１５０は、顧客の電気使用量および需要プロフィールなどの履歴データに加えて、それまでに観察された不正行為の事例に関連付けられたデータ項目をも含み得る。いくつかの実施形態においては、バルクソースデータ１１５０は、「データレイク（data lake）」と称され得るオブジェクトストア１１２０に格納されてもよい。オブジ
ェクトストア１１２０に格納されたデータはすべて、一様に、標準フォーマット１１２２
で格納されてもよい。いくつかの実施形態においては、標準フォーマット１１２は、Ｈａｄｏｏｐ分散型ファイルシステム（Hadoop Distributed File System：ＨＤＦＳ）であってもよく、スケーラブルで信頼性の高いデータストレージを提供するために用いられるJava（登録商標）ベースのファイルシステムであってもよい。

ストリーミングソースデータ１１５２は、リアルタイムで（たとえばメータから）受信される顧客の実際の電気使用量を含み得る。各顧客ごとに、それらのリアルタイムの電気使用量がビッグデータクラウドプラットフォーム１１１０に送られてもよい。いくつかの実施形態においては、ストリーミングソースデータ１１５２は、Ｋａｆｋａ１１３０などの通信インターフェイスにおいて受信されてもよい。通信インターフェイスとして、Ｋａｆｋａ１１３０はストリーミングソースデータ１１５２を受信し、そのデータ内の個々のメッセージを解析してもよい。それらのメッセージは、オブジェクトストア１１２０に（たとえば、標準フォーマット１１２２で）格納することができるデータに変換することができる。これにより、オブジェクトストア１１２０は、バルクソースデータ１１５０（たとえば、顧客についての履歴電気使用量）およびストリーミングソースデータ１１５２（たとえば、顧客についてのリアルタイムの電気使用量）からのデータを同じ一様なフォーマットで含んでいてもよい。

いくつかの実施形態においては、Ｓｐａｒｋ１１３４および／またはＨｉｖｅ ＬＬＡＰ１１３６はさらに、オブジェクトストア１１２０内に含まれているデータをすべて（たとえば不正な挙動を検出するために）分析して処理するために用いられる。Ｓｐａｒｋ１１３４（たとえば、Ａｐａｃｈｅ Ｓｐａｒｋ）は、データのストリーミングおよび機械学習のために内蔵モジュールを介してビッグデータ処理のための高速かつ汎用のエンジンとして機能するクラスタコンピューティングフレームワークを提供し得る。言いかえれば、Ｓｐａｒｋ１１３４は、コンピュータのクラスタにわたる大規模なデータセットの分散処理を用いてビッグデータ分析を実行するための特徴を提供し得るとともに、大量のデータを分散処理するためのベースとなるＨａｄｏｏｐ Ｍａｐ／Ｒｅｄｕｃｅ技術を改善させ得る。Ｓｐａｒｋ１１３４は、メモリに存続することによって固有のＨａｄｏｏｐ Ｍａｐ／Ｒｅｄｕｃｅ機能を過剰にチャージし得る一方で、Ｍａｐ／Ｒｅｄｕｃｅはディスクに残存している。結果として、Ｓｐａｒｋ１１３４は、メモリ動作の点でＭａｐ／Ｒｅｄｕｃｅよりも１００倍高速であり得るとともに、ディスク動作の点でＭａｐ／Ｒｅｄｕｃｅよりも１０倍高速であり得る。

いくつかの実施形態においては、Ｓｐａｒｋ１１３４は、Oracle R Advanced Analytics for Hadoop（ＯＲＡＡＨ）を含み得る。Oracle R Advanced Analytics for Hadoopは、コンピュータのクラスタにわたる大型のデータセットの分散処理を用いて、ビッグデータ分析を実行するための特徴を提供する「スーパーチャージされた（supercharged）」バージョンのＳｐａｒｋとしての役割を果たし得る。ＯＲＡＡＨは、従来のＳｐａｒｋパッケージに勝る多数の利点を提供し得る。たとえば、ＯＲＡＡＨは、スパークより３２倍高速の機械学習モデル（たとえば、分類、クラスタ化、回帰、特徴抽出などのための機械学習アルゴリズム）を提供し得る。ＯＲＡＡＨはまた、研究開発において開発された機械学習モデルを製造に向けて展開する能力を提供してもよい。ＯＲＡＡＨはまた、データレイクにおいてＲスクリプトを直接実行する能力を提供してもよい。ＯＲＡＡＨはまた、ＨＤＦＳおよび／またはＨＩＶＥを含む複数のデータフォーマットからのデータの読取り／書込みを可能にする単一のパッケージとしての役割を果たし得る。ＯＲＡＡＨはまた、Ｒ内に存在する任意の式を処理可能であり得るのに対して、Ｓｐａｒｋは、制限された変換のサブセットで単純な属性を処理することができるだけであり得る。

いくつかの実施形態においては、Ｈｉｖｅ ＬＬＡＰ１１３６は、Ａｐａｃｈｅ Ｈｉｖｅを含んでいてもよく、データ要約、クエリおよび分析のためにＳＱＬ様のインターフ
ェイスを提供するためのＡｐａｃｈｅ Ｈａｄｏｏｐプラットフォーム上に構築されたデータウェアハウスソフトウェアプロジェクトであり得る。Ｈｉｖｅ ＬＬＡＰ（低レイテンシ分析処理）１１３６は、より高速のＳＱＬ分析を提供することによってＨｉｖｅアーキテクチャ上に構築されてもよい。これにより、Ｋａｆｋａ１１３０を用いて、ストリーミングデータからのメッセージを解析して取得する。これらメッセージは次いで、オブジェクトストア１１２０における履歴データに追加される。オブジェクトストア１１２０に含まれるこの「データレイク」は、この明細書中に上述されてきた電力不正を検出するためのステップを実行するために、Ｓｐａｒｋ１１３４およびＨｉｖｅ ＬＬＡＰ１１３６を用いて処理される。

いくつかの実施形態においては、オブジェクトストア１１２０は、コンピューティング効率の向上および必要なコンピューティングリソースの減少に関連付けられた特徴を、分離されたストレージに提供する態様で実現されてもよい。Ｈａｄｏｏｐは、典型的には、ＨＤＦＳとＭａｐＲｅｄｕｃｅとの組合せから成る。しかしながら、ＨＤＦＳに関する問題は、計算が各ノード（たとえば、分散型コンピューティングシステムのクラスタ）上にあって、付加的な計算を得るためにより多くのノードを追加する必要がある点である。各々のノードは計算および格納を行なうものであって、これは、より多くのノードを追加することによって、使用されていないストレージが有効に補償されていることを意味している。代替例として、ＨＤＦＳ以外のストレージ機構、たとえばＡｍａｚｏｎ Ｓ３またはオラクルオブジェクトストレージなどを用いることができる。たとえば、システムがオブジェクトストレージとＭａｐＲｅｄｕｃｅとの組合せで実現されるように、ＨＤＦＳを交換することができる。この実現例の下では、ストレージは分離されており、ノードには最小限のストレージを追加することができ、そのストレージに関連付けられ得る追加コストを低減することができる。言いかえればオラクルのビッグデータクラウドサービスなどのサービス（計算エディション）は、追加のＨａｄｏｏｐクラスタまたはＳｐａｒｋクラスタを要求に応じてプロビジョニングするために用いることができるが、データ自体は、Ａｍａｚｏｎ Ｓ３またはオラクルオブジェクトストレージ内に保持されており、必要に応じてクラスタによって検索される。

図１２は、本開示の実施形態に従った、電力不正検出のためのハイブリッドシステム図を示す。

図に示されるように、電力不正検出システム１２２０は、さまざまな顧客に関連付けられたリアルタイム電気使用量データ１２３２および履歴電気使用量データ１２３４を受信する。いくつかの実施形態においては、リアルタイム電気使用量データ１２３２は１つ以上の電気メータ１２３０から直接受信される。１つ以上の電気メータ１２３０は各々、顧客に関連付けられたリアルタイム使用量データを提供する。

電力不正検出システム１２２０は、ブロック１２４２においてこのデータをすべて取込んでもよい。これは、１つ以上の電気メータ１２３０と通信するとともに１つ以上の電気メータ１２３０からデータを受信するように構成された特化された通信インターフェイス（たとえば、プログラミングインターフェイスまたはＡＰＩ）を含んでいてもよい。履歴電気使用量データ１２３４を格納するいずれかのコンピュータシステムまたはデバイスと通信するとともに履歴電気使用量データ１２３４を格納するいずれかのコンピュータシステムまたはデバイスからデータを受信するように構成された通信インターフェイスがあってもよい。たとえば、履歴電気使用量データ１２３４がクラウドコンピューティングネットワーク上に格納される場合、電力不正検出システム１２２０は、クラウドコンピューティングネットワークからそのデータをすべて検索するための通信インターフェイスを有していてもよい。

データのすべてが電力不正検出システム１２２０内で統合されると、ブロック１２４４において、電力不正検出システム１２２０は、データをすべて単数の一様なフォーマットに（たとえば、日付／時間がすべて同じフォーマットに従うことを確実にして）変換し得ることにより、任意の顧客についての履歴電気使用量データおよびリアルタイム電気使用量データをともに組合わせて用いることができるようにする。

ブロック１２４６において、電力不正検出システム１２２０は、データ（たとえば、すべての顧客についての履歴電気使用量データおよびリアルタイム電気使用量データ）をすべて図１１に示されるオブジェクトストア１１２０などのストレージに格納し得る。ブロック１２４８において、電力不正検出システム１２２０は、ストレージ内のデータのすべてに対してＲ分析を実行し得る。各顧客ごとに、電力不正検出システム１２２０は、顧客らの履歴電気使用量およびリアルタイム電気使用量に基づいて使用量需要プロフィールを決定し得る。ブロック１２５０において、電力不正検出システム１２２０は、１以上の顧客の不正を検出するために各顧客ごとに使用量を分析し得る。

電力不正検出システム１２２０が潜在的な不正を識別すると、エグゼクティブチーム１２９０のメンバは、デバイス１２８０上のインターフェイス１２８２を介して、潜在的に不正行為を犯していると識別された顧客に関するレポートを閲覧することができるようになり得る。デバイス１２８０は、電力不正検出システム１２２０から生成されたこれらのレポートを受信してもよい。さらに、エグゼクティブチーム１２９０のメンバは、（たとえば、顧客の住居に関連付けられたサービスポイントｉｄまたはアドレスに基づいて）任意の顧客についての使用量需要プロフィールを引き出して閲覧することができるかもしれない。これにより、人が、いずれかの異常を認識するために顧客の使用量需要プロフィールを閲覧することにより、識別されたいずれの潜在的な不正行為についても付加的に確認することができるようにする。エグゼクティブチーム１２９０のメンバが、顧客に関連付けられた識別されたいずれかの潜在的な不正行為をさらに確認すると、これらメンバは、現場スタッフ１２１０に対して、顧客の場所まで物理的に赴き、メータを調べて、不正が行なわれていることを確認するようにとの指示をインターフェイス１２８２内にて直接示してもよい。

次いで、デバイス１２８０は、電力不正検出システム１２２０に命令を送信することとなり、さらに、電力不正検出システム１２２０は、顧客のアドレスに（たとえば地理的に）最も近くにいる現場スタッフ１２１０を判断するだろう。複数の不正行為の事例がある場合に複数の顧客が存在する場合、これらの顧客はまた、近隣に位置するか否かに基づいて現場スタッフ間で振り分けられる可能性がある（たとえば、現場スタッフ１２１０は、彼らの地理的位置にいる顧客のプールを受取ってもよい）。次いで、電力不正検出システム１２２０は現場スタッフ１２１０に関連付けられたデバイス１２１２に命令を転送し得る。現場スタッフ１２１０は、デバイス１２１２上のインターフェイス１２１４を介して命令および顧客のアドレスを閲覧することができてもよい。その後、現場スタッフ１２１０は、不正が行なわれていることを実証するために、顧客のアドレスまで物理的に訪れて、メータを調べて、顧客によって実行されているいずれの不正をも調査し得る。現場スタッフ１２１０は、不正がデバイス１２１２上のインターフェイス１２１４を介して実際に行なわれているかどうかを示すことができてもよい。この情報は、エグゼクティブチーム１２９０に報告し返すことができるか、または、不正を検出するための任意の既存の挙動モデルを更新するかもしくは向上させるために（たとえば、電力不正検出システム１２２０に格納されている）既存のデータに追加されてもよい。

図１３は、本開示の実施形態に従った、突然低下した後に低いままとどまっている需要についての例示的な挙動パターンを示す。

図に示されるように、需要の突然の低下（たとえば、約２５から５までの低下）は１５０日目前後で起こっており、需要が引続き（たとえば、平均５前後で）低いままとなる。需要が既にわずかに下方に傾いているが、需要の突然の低下は、依然として異常であると見なすことができ、進行中の電力不正使用の開始に特有のものであり得る。この挙動パターンは、潜在的な疑わしいアクティビティを識別するために検出器として用いられてもよい。

図１４は、本開示の実施形態に従った、緩やかに低下した後に低いままとどまっている需要についての例示的な挙動パターンを示す。

図に示されるように、需要プロフィールは、永続的に低くなる（たとえば、平均で５前後に）までわずかに下方に傾斜している。電力需要が時間とともに低下し得る理由が数多く存在している（たとえば、ユーザの電力消費習慣が変化する可能性がある）が、これらの理由は、需要が徐々に緩やかに低下した後に継続的に低いままである需要プロフィールに何らかの形で対応するはずであるだろう。緩やかな低下は、進行中の電力不正に特有のものであり得るとともに、この挙動パターンは潜在的な疑わしいアクティビティを識別するために検出器として用いられてもよい。

図１５は、本開示の実施形態に従った、長期間にわたって緩やかに低下する需要についての例示的な挙動パターンを示す。

図に示されるように、需要プロフィールは期間全体にわたって下降傾向を示す。図１４と同様に、電力需要が時間とともに低下し得る理由が数多く存在している（たとえば、ユーザの電力消費習慣が変化する可能性がある）が、需要プロフィールの長期間にわたる低下は進行中の電力不正に特有のものであり得るとともに、この挙動パターンは潜在的な疑わしいアクティビティを識別するために検出器として用いられてもよい。

図１６は、本開示の実施形態に従った、非常に低い需要についての例示的な挙動パターンを示す。

図に示されるように、需要プロフィールは、持続期間全体にわたって非常に低い（たとえば、平均で２．５の）ままとどまっている。その期間にわたってユーザの電力消費が非常に低い可能性がある（たとえば、ユーザが国外に滞在しており、プラグが差込まれた機器が電力を引き出しているため電力が消費されている）が、長期間にわたる低需要は、進行中の電力不正および隠されている真の需要プロフィールに特有のものであり得る。この挙動パターンは、潜在的な疑わしいアクティビティを識別するために検出器として用いられてもよい。

図１７は、本開示の実施形態に従った、上昇すると予想されていた場合に上昇しない需要についての例示的な挙動パターンを示す。

図に示されるように、ユーザの母集団全体の需要は、母集団全体が何を行っているかを観察するために策定することができる（たとえばＥＣＤＦ）。１５０日目に、母集団全体にわたって、突然、需要にスパイクが発生する（たとえば、５５から７０まで突然上昇する）。この需要の上昇は、２５０日目まで持続し、その後、母集団全体にわたって需要が突然低下する（たとえば、７０から５５まで突然低下する）。ユーザの母集団全体にわたって需要が一時的に上昇する理由が数多く存在し得る。たとえば、需要の上昇は、夏季における典型的な需要挙動を表わし得る。１５０日目と２５０日目との間の温度はより高くなっていたかもしれず、結果として、使用量のスパイクが発生することとなるが、これは、ユーザの母集団全体がエアコンディショナをオンにして起動させたことに起因している
。

同時に、単一のユーザについての需要プロフィールが策定され、同じ期間にわたる母集団の需要と比較され得る。この比較は、（たとえば、ユーザが母集団全体と同様の挙動を行なった場合に）ユーザの需要プロフィールが呈示する「はずであった」が呈示しなかったものを明らかにするために用いることができる。たとえば、ユーザの需要プロフィールは、母集団全体わたるに需要において観察された１５０日目から２５０日目までの需要の上昇を呈していない。ユーザの需要プロフィールは、母集団とは実質的に異なっている。これについて多数の理由があり得る。たとえば、母集団における需要の上昇がより高い温度に起因するものであった場合、このユーザがエアコンディショナを使用せずに単に高温に耐えていたかもしれない。しかしながら、ユーザの需要プロフィールが進行中の電力不正のせいで正確ではない（たとえば、ユーザの需要が誤って報告されている）という別の説明もあり得る。したがって、この挙動パターンは、潜在的な疑わしいアクティビティ（ユーザが他のユーザと比較されていなかった場合には観察されないであろう特に疑わしいアクティビティ）を識別するために検出器として用いられてもよい。

図１８は、本開示の実施形態に従った、過度に異常に安定している需要についての例示的な挙動パターンを示す。

図に示されるように、需要プロフィールは或る期間にわたって異常に安定している。１５０日目と２００日目との期間の間に、ユーザの需要は５０で一定にとどまっている。これは、（たとえば過渡信号のような）何らかの変動性を有するその期間外の通常の電力使用量と比較すると、かなり異常である。需要プロフィールの異常な安定性についての１つの説明として、ユーザの需要プロフィールが進行中の電力不正のせいで正確ではないということが挙げられる（たとえば、安定性が異常である期間にわたるユーザの需要が誤って報告されている）。したがって、この挙動パターンは、潜在的な疑わしいアクティビティを識別するために検出器として用いられてもよい。

付加的な実現例の詳細
図１９は、この明細書中に開示された実施形態のうちの１つを実現するための分散型システムを示す簡略図である。分散型システム１９００は、上述したように、電力不正検出システムの実施形態を実現することができる。例示された実施形態においては、分散型システム１９００は、１つ以上のネットワーク１９１０を介して、ウェブブラウザ、プロプライエタリクライアント（たとえばオラクルフォーム）などのクライアントアプリケーションを実行して動作させるように構成される１つ以上のクライアントコンピューティングデバイス１９０２、１９０４、１９０６および１９０８を含む。サーバ１９１２は、ネットワーク１９１０を介してリモートクライアントコンピューティングデバイス１９０２、１９０４、１９０６および１９０８と通信可能に結合されてもよい。

さまざまな実施形態においては、サーバ１９１２は、システムの構成要素のうち１つ以上によって提供される１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。サービスまたはソフトウェアアプリケーションは非仮想環境および仮想環境を含み得る。仮想環境は、２次元または３次元（three-dimensional：３
Ｄ）表現、ページベースの論理的環境などであろうとなかろうと、仮想イベント、トレードショー、シミュレータ、クラスルーム、購買商品取引および企業活動のために用いられるものを含み得る。いくつかの実施形態においては、これらのサービスは、ウェブベースのサービスもしくはクラウドサービスとして、またはソフトウェア・アズ・ア・サービス（Software as a Service：ＳａａＳ）モデルのもとで、クライアントコンピューティン
グデバイス１９０２，１９０４，１９０６および／または１９０８のユーザに供給されてもよい。そして、クライアントコンピューティングデバイス１９０２，１９０４，１９０
６および／または１９０８を動作させるユーザは、１つ以上のクライアントアプリケーションを利用して、サーバ１９１２と相互作用して、これらの構成要素によって提供されるサービスを利用し得る。

図１９に示されている構成では、システム１９００のソフトウェアコンポーネント１９１８，１９２０および１９２２は、サーバ１９１２上に実装されるように示されている。また、他の実施形態においては、システム１９００の構成要素のうちの１つ以上および／またはこれらの構成要素によって提供されるサービスは、クライアントコンピューティングデバイス１９０２，１９０４，１９０６および／または１９０８のうちの１つ以上によって実現されてもよい。その場合、クライアントコンピューティングデバイスを動作させるユーザは、１つ以上のクライアントアプリケーションを利用して、これらの構成要素によって提供されるサービスを使用し得る。これらの構成要素は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実現されてもよい。分散型システム１９００とは異なり得るさまざまな異なるシステム構成が可能であることが理解されるべきである。したがって、図１９に示されている実施形態は、実施形態のシステムを実現するための分散型システムの一例であり、限定的であるよう意図されたものではない。

クライアントコンピューティングデバイス１９０２，１９０４，１９０６および／または１９０８は、手持ち式携帯機器（たとえばｉＰｈｏｎｅ（登録商標）、携帯電話、ｉＰａｄ（登録商標）、計算タブレット、パーソナルデジタルアシスタント（personal digital assistant：ＰＤＡ））またはウェアラブル装置（たとえばグーグルグラス（登録商標）ヘッドマウントディスプレイ）であってもよく、当該装置は、マイクロソフト・ウィンドウズ（登録商標）・モバイル（登録商標）などのソフトウェアを実行し、および／または、ｉＯＳ、ウィンドウズ・フォン、アンドロイド、ブラックベリー１０、パームＯＳなどのさまざまなモバイルオペレーティングシステムを実行し、インターネット、ｅメール、ショート・メッセージ・サービス（short message service：ＳＭＳ）、ブラックベリ
ー（登録商標）、または使用可能な他の通信プロトコルである。クライアントコンピューティングデバイスは、汎用パーソナルコンピュータであってもよく、当該汎用パーソナルコンピュータは、一例として、マイクロソフトウィンドウズ（登録商標）、アップルマッキントッシュ（登録商標）および／またはリナックス（登録商標）オペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを含む。クライアントコンピューティングデバイスは、ワークステーションコンピュータであってもよく、当該ワークステーションコンピュータは、たとえばＧｏｏｇｌｅ Ｃｈｒｏｍｅ ＯＳなどのさまざまなＧＮＵ／リナックスオペレーティングシステムを含むがこれらに限定されるものではないさまざまな市販のＵＮＩＸ（登録商標）またはＵＮＩＸライクオペレーティングシステムのうちのいずれかを実行する。代替的には、または付加的には、クライアントコンピューティングデバイス１９０２，１９０４，１９０６および１９０８は、シン・クライアントコンピュータ、インターネットにより可能なゲームシステム（たとえばキネクト（登録商標）ジェスチャ入力装置を備えるかまたは備えないマイクロソフトＸボックスゲーム機）、および／または、ネットワーク１９１０を介して通信が可能なパーソナルメッセージング装置などのその他の電子装置であってもよい。

例示的な分散型システム１９００は、４個のクライアントコンピューティングデバイスを有するように示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサを有する装置などの他の装置が、サーバ１９１２と相互作用してもよい。

分散型システム１９００におけるネットワーク１９１０は、さまざまな市販のプロトコルのうちのいずれかを用いてデータ通信をサポートすることができる、当業者になじみの
ある任意のタイプのネットワークであってもよく、当該プロトコルは、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネットプロトコル）、ＳＮＡ（システムネットワークアーキテクチャ）、ＩＰＸ（インターネットパケット交換）、アップルトークなどを含むが、これらに限定されるものではない。単に一例として、ネットワーク１９１０は、イーサネット（登録商標）、トークンリングなどに基づくものなどのローカルエリアネットワーク（ＬＡＮ）であってもよい。ネットワーク１９１０は、広域ネットワークおよびインターネットであってもよい。ネットワーク１９１０は、仮想ネットワークを含んでいてもよく、当該仮想ネットワークは、仮想プライベートネットワーク（virtual private network：
ＶＰＮ）、イントラネット、エクストラネット、公衆交換電話網（public switched telephone network：ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえば米国電
気電子学会（Institute of Electrical and Electronics：ＩＥＥＥ）８０２．１１の一
連のプロトコル、ブルートゥース（登録商標）および／またはその他の無線プロトコルのうちのいずれかのもとで動作するネットワーク）、および／またはこれらの任意の組合せ、および／または他のネットワークを含むが、これらに限定されるものではない。

サーバ１９１２は、１つ以上の汎用コンピュータ、専用サーバコンピュータ（一例として、ＰＣ（パーソナルコンピュータ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント式サーバなどを含む）、サーバファーム、サーバクラスタ、またはその他の適切な構成および／または組合せで構成され得る。サーバ１９１２は、仮想オペレーティングシステムを実行する１つ以上の仮想マシン、または仮想化を含む他のコンピューティングアーキテクチャを含み得る。論理記憶装置の１つ以上のフレキシブルプールは、サーバのための仮想記憶デバイスを維持するように仮想化することができる。仮想ネットワークは、ソフトウェア定義型ネットワーキングを用いて、サーバ１９１２によって制御することができる。さまざまな実施形態においては、サーバ１９１２は、上記の開示に記載されている１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合され得る。たとえば、サーバ１９１２は、本開示の実施形態に係る上記の処理を実行するためのサーバに対応してもよい。

サーバ１９１２は、上記のもののうちのいずれか、および、任意の市販のサーバオペレーティングシステムを含むオペレーティングシステムを実行し得る。また、サーバ１９１２は、ＨＴＴＰ（ハイパーテキスト転送プロトコル）サーバ、ＦＴＰ（ファイル転送プロトコル）サーバ、ＣＧＩ（共通ゲートウェイインターフェース）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバなどを含むさまざまな付加的サーバアプリケーションおよび／または中間層アプリケーションのうちのいずれかを実行し得る。例示的なデータベースサーバは、オラクル社（Oracle）、マイクロソフト社（Microsoft）、サイベース
社（Sybase）、ＩＢＭ社（International Business Machines）などから市販されている
ものを含むが、これらに限定されるものではない。

いくつかの実現例では、サーバ１９１２は、クライアントコンピューティングデバイス１９０２，１９０４，１９０６および１９０８のユーザから受信されたデータフィードおよび／またはイベント更新を分析および統合するための１つ以上のアプリケーションを含み得る。一例として、データフィードおよび／またはイベント更新は、１つ以上の第三者情報源および連続的なデータストリームから受信されるツイッター（登録商標）フィード、フェースブック（登録商標）更新またはリアルタイム更新を含み得るが、これらに限定されるものではなく、センサデータアプリケーション、金融ティッカ、ネットワーク性能測定ツール（たとえばネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通モニタリングなどに関連するリアルタイムイベントを含み得る。また、サーバ１９１２は、クライアントコンピューティングデバイス１９０２，１９０４，１９０６および１９０８の１つ以上の表示装置を介してデータフィードおよび／またはリアルタイムイベントを表示するための１つ以上のアプリケー
ションを含み得る。

また、分散型システム１９００は、１つ以上のデータベース１９１４および１９１６を含み得る。データベース１９１４および１９１６は、さまざまな場所に存在し得る。一例として、データベース１９１４および１９１６の１つ以上は、サーバ１９１２にローカルな（および／または存在する）非一時的な記憶媒体に存在していてもよい。代替的に、データベース１９１４および１９１６は、サーバ１９１２から遠く離れていて、ネットワークベースまたは専用の接続を介してサーバ１９１２と通信してもよい。一組の実施形態においては、データベース１９１４および１９１６は、記憶領域ネットワーク（storage-area network：ＳＡＮ）に存在していてもよい。同様に、サーバ１９１２に起因する機能を実行するための任意の必要なファイルが、サーバ１９１２上にローカルに、および／または、リモートで適宜格納されていてもよい。一組の実施形態においては、データベース１９１４および１９１６は、ＳＱＬフォーマットコマンドに応答してデータを格納、更新および検索するように適合された、オラクル社によって提供されるデータベースなどのリレーショナルデータベースを含み得る。

図２０は、本開示の実施形態に係る、実施形態のシステムの１つ以上の構成要素によって提供されるサービスをクラウドサービスとして供給することができるシステム環境２０００の１つ以上の構成要素の簡略化されたブロック図である。システム環境２０００は、上述したように、電力不正検出システムの実施形態を含み得るかまたは実現し得る。示されている実施形態においては、システム環境２０００は、クラウドサービスを提供するクラウドインフラストラクチャシステム２００２と相互作用するようにユーザによって使用され得る１つ以上のクライアントコンピューティングデバイス２００４，２００６および２００８を含む。クライアントコンピューティングデバイスは、クラウドインフラストラクチャシステム２００２によって提供されるサービスを使用するためにクラウドインフラストラクチャシステム２００２と相互作用するようにクライアントコンピューティングデバイスのユーザによって使用され得る、ウェブブラウザ、専有のクライアントアプリケーション（たとえばオラクルフォームズ）または他のアプリケーションなどのクライアントアプリケーションを動作させるように構成され得る。

図２０に示されているクラウドインフラストラクチャシステム２００２が図示されている構成要素とは他の構成要素を有し得ることが理解されるべきである。さらに、図２０に示されている実施形態は、本発明の実施形態を組込むことができるクラウドインフラストラクチャシステムの一例に過ぎない。たとえば、クラウドインフラストラクチャシステム２００２は、上述のように、電力不正検出システムのうちの１つ以上の要素を含み得るかまたは実現し得る。いくつかの他の実施形態においては、クラウドインフラストラクチャシステム２００２は、図２０に示されているものよりも多いまたは少ない数の構成要素を有していてもよく、２つ以上の構成要素を組合せてもよく、または構成要素の異なる構成または配置を有していてもよい。

クライアントコンピューティングデバイス２００４，２００６および２００８は、１９０２，１９０４，１９０６および１９０８について上記したものと類似のデバイスであってもよい。

例示的なシステム環境２０００は３個のクライアントコンピューティングデバイスを有するように示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサなどを有する装置などの他の装置が、クラウドインフラストラクチャシステム２００２と相互作用してもよい。

ネットワーク２０１０は、クライアント２００４，２００６および２００８とクラウド
インフラストラクチャシステム２００２との間のデータの通信およびやりとりを容易にし得る。各々のネットワークは、ネットワーク１９１０について上記したものを含むさまざまな市販のプロトコルのうちのいずれかを用いてデータ通信をサポートすることができる、当業者になじみのある任意のタイプのネットワークであってもよい。

クラウドインフラストラクチャシステム２００２は、サーバ１９１２について上記したものを含み得る１つ以上のコンピュータおよび／またはサーバを備え得る。

特定の実施形態においては、クラウドインフラストラクチャシステムによって提供されるサービスは、オンラインデータ記憶およびバックアップソリューション、ウェブベースのｅメールサービス、ホスト型オフィススイートおよびドキュメントコラボレーションサービス、データベース処理、管理技術サポートサービスなどの、クラウドインフラストラクチャシステムのユーザがオンデマンドで利用可能な多数のサービスを含み得る。クラウドインフラストラクチャシステムによって提供されるサービスは、そのユーザのニーズを満たすように動的にスケーリング可能である。クラウドインフラストラクチャシステムによって提供されるサービスの具体的なインスタンス化は、本明細書では「サービスインスタンス」と称される。一般に、インターネットなどの通信ネットワークを介してクラウドサービスプロバイダのシステムからユーザが利用可能な任意のサービスは、「クラウドサービス」と称される。通常、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客自身のオンプレミスサーバおよびシステムとは異なっている。たとえば、クラウドサービスプロバイダのシステムがアプリケーションをホストしてもよく、ユーザは、インターネットなどの通信ネットワークを介してオンデマンドで当該アプリケーションを注文および使用してもよい。

いくつかの例では、コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、ストレージ、ホスト型データベース、ホスト型ウェブサーバ、ソフトウェアアプリケーションへの保護されたコンピュータネットワークアクセス、またはクラウドベンダによってユーザに提供されるかもしくはそうでなければ当該技術分野において公知の他のサービスを含み得る。たとえば、サービスは、インターネットを介したクラウド上のリモートストレージへのパスワードによって保護されたアクセスを含み得る。別の例として、サービスは、ネットワーク化された開発者による私的使用のためのウェブサービスベースのホスト型リレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含み得る。別の例として、サービスは、クラウドベンダのウェブサイト上でホストされるｅメールソフトウェアアプリケーションへのアクセスを含み得る。

特定の実施形態においては、クラウドインフラストラクチャシステム２００２は、セルフサービスの、サブスクリプションベースの、弾性的にスケーラブルな、信頼性のある、高可用性の、安全な態様で顧客に配信される一連のアプリケーション、ミドルウェアおよびデータベースサービス提供品を含み得る。このようなクラウドインフラストラクチャシステムの一例は、本譲受人によって提供されるオラクルパブリッククラウドである。

時としてビッグデータとも称される大量のデータは、インフラストラクチャシステムによって、多数のレベルにおいて、および異なるスケールでホストおよび／または操作され得る。このようなデータが含み得るデータセットは、非常に大型で複雑であるので、典型的なデータベース管理ツールまたは従来のデータ処理アプリケーションを用いて処理するのが困難になる可能性がある。たとえば、テラバイトのデータはパーソナルコンピュータまたはそれらのラックベースの対応物を用いて格納、検索取得および処理することが難しいかもしれない。このようなサイズのデータは、最新のリレーショナルデータベース管理システムおよびデスクトップ統計ならびに視覚化パッケージを用いて機能させるのが困難である可能性がある。それらは、データを許容可能な経過時間内に捕捉しキュレーション
し管理し処理するよう、一般的に用いられるソフトウェアツールの構造を超えて、何千ものサーバコンピュータを動作させる大規模並列処理ソフトウェアを必要とし得る。

大量のデータを視覚化し、トレンドを検出し、および／または、データと相互作用させるために、分析者および研究者は極めて大きいデータセットを格納し処理することができる。平行にリンクされた何十、何百または何千ものプロセッサがこのようなデータに対して作用可能であり、これにより、このようなデータを表示し得るか、または、データに対する外力をシミュレートし得るかもしくはそれが表しているものをシミュレートし得る。これらのデータセットは、データベースにおいて編制されたデータ、もしくは構造化モデルに従ったデータ、および／または、非体系的なデータ（たとえば電子メール、画像、データブロブ（バイナリ大型オブジェクト）、ウェブページ、複雑なイベント処理）などの構造化されたデータを必要とする可能性がある。目標物に対してより多くの（またはより少数の）コンピューティングリソースを比較的迅速に集中させるために実施形態の能力を強化することにより、ビジネス、政府関係機関、研究組織、私人、同じ目的をもった個々人もしくは組織のグループ、または他のエンティティからの要求に基づいて大量のデータセット上でタスクを実行するために、クラウドインフラストラクチャシステムがより良好に利用可能となる。

さまざまな実施形態においては、クラウドインフラストラクチャシステム２００２は、クラウドインフラストラクチャシステム２００２によって供給されるサービスへの顧客のサブスクリプションを自動的にプロビジョニング、管理および追跡するように適合され得る。クラウドインフラストラクチャシステム２００２は、さまざまなデプロイメントモデルを介してクラウドサービスを提供し得る。たとえば、クラウドインフラストラクチャシステム２００２が、（たとえばオラクル社によって所有される）クラウドサービスを販売する組織によって所有され、一般大衆またはさまざまな産業企業がサービスを利用できるパブリッククラウドモデルのもとでサービスが提供されてもよい。別の例として、クラウドインフラストラクチャシステム２００２が単一の組織のためだけに運営され、当該組織内の１つ以上のエンティティにサービスを提供し得るプライベートクラウドモデルのもとでサービスが提供されてもよい。また、クラウドインフラストラクチャシステム２００２およびクラウドインフラストラクチャシステム２００２によって提供されるサービスが、関連のコミュニティ内のいくつかの組織によって共有されるコミュニティクラウドモデルのもとでクラウドサービスが提供されてもよい。また、２つ以上の異なるモデルの組合せであるハイブリッドクラウドモデルのもとでクラウドサービスが提供されてもよい。

いくつかの実施形態においては、クラウドインフラストラクチャシステム２００２によって提供されるサービスは、ソフトウェア・アズ・ア・サービス（Software as a Service：ＳａａＳ）カテゴリ、プラットフォーム・アズ・ア・サービス（Platform as a Service：ＰａａＳ）カテゴリ、インフラストラクチャ・アズ・ア・サービス（Infrastructure
as a Service：ＩａａＳ）カテゴリ、またはハイブリッドサービスを含むサービスの他
のカテゴリのもとで提供される１つ以上のサービスを含み得る。顧客は、サブスクリプションオーダーによって、クラウドインフラストラクチャシステム２００２によって提供される１つ以上のサービスを注文し得る。次いで、クラウドインフラストラクチャシステム２００２は、顧客のサブスクリプションオーダーでサービスを提供するために処理を実行する。

いくつかの実施形態においては、クラウドインフラストラクチャシステム２００２によって提供されるサービスは、アプリケーションサービス、プラットフォームサービスおよびインフラストラクチャサービスを含み得るが、これらに限定されるものではない。いくつかの例では、アプリケーションサービスは、ＳａａＳプラットフォームを介してクラウドインフラストラクチャシステムによって提供されてもよい。ＳａａＳプラットフォーム
は、ＳａａＳカテゴリに分類されるクラウドサービスを提供するように構成され得る。たとえば、ＳａａＳプラットフォームは、一体化された開発およびデプロイメントプラットフォーム上で一連のオンデマンドアプリケーションを構築および配信するための機能を提供し得る。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御し得る。ＳａａＳプラットフォームによって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムで実行されるアプリケーションを利用することができる。顧客は、顧客が別々のライセンスおよびサポートを購入する必要なく、アプリケーションサービスを取得することができる。さまざまな異なるＳａａＳサービスが提供されてもよい。例としては、大規模組織のための販売実績管理、企業統合およびビジネスの柔軟性のためのソリューションを提供するサービスが挙げられるが、これらに限定されるものではない。

いくつかの実施形態においては、プラットフォームサービスは、ＰａａＳプラットフォームを介してクラウドインフラストラクチャシステムによって提供されてもよい。ＰａａＳプラットフォームは、ＰａａＳカテゴリに分類されるクラウドサービスを提供するように構成され得る。プラットフォームサービスの例としては、組織（オラクル社など）が既存のアプリケーションを共有の共通アーキテクチャ上で統合することを可能にするサービス、および、プラットフォームによって提供される共有のサービスを活用する新たなアプリケーションを構築する機能を挙げることができるが、これらに限定されるものではない。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御し得る。顧客は、顧客が別々のライセンスおよびサポートを購入する必要なく、クラウドインフラストラクチャシステムによって提供されるＰａａＳサービスを取得することができる。プラットフォームサービスの例としては、オラクルＪａｖａクラウドサービス（Java Cloud Service：ＪＣＳ）、オラクルデータベースクラウドサービス（Database Cloud Service：ＤＢＣＳ）などが挙げられるが、これらに限定されるものではない。

ＰａａＳプラットフォームによって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムによってサポートされるプログラミング言語およびツールを利用することができ、デプロイされたサービスを制御することもできる。いくつかの実施形態においては、クラウドインフラストラクチャシステムによって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービル（たとえばオラクルフージョンミドルウェアサービス）およびＪａｖａクラウドサービスを含み得る。一実施形態においては、データベースクラウドサービスは、組織がデータベースリソースをプールしてデータベースクラウドの形態でデータベース・アズ・ア・サービスを顧客に供給することを可能にする共有のサービスデプロイメントモデルをサポートし得る。ミドルウェアクラウドサービスは、クラウドインフラストラクチャシステムにおいてさまざまなビジネスアプリケーションを開発およびデプロイするために顧客にプラットフォームを提供し得るともに、Ｊａｖａクラウドサービスは、クラウドインフラストラクチャシステムにおいてＪａｖａアプリケーションをデプロイするために顧客にプラットフォームを提供し得る。

さまざまな異なるインフラストラクチャサービスは、クラウドインフラストラクチャシステムにおけるＩａａＳプラットフォームによって提供されてもよい。インフラストラクチャサービスは、ストレージ、ネットワークなどの基本的な計算リソース、ならびに、ＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用する顧客のための他の基礎的な計算リソースの管理および制御を容易にする。

また、特定の実施形態においては、クラウドインフラストラクチャシステム２００２は、クラウドインフラストラクチャシステムの顧客にさまざまなサービスを提供するために
使用されるリソースを提供するためのインフラストラクチャリソース２０３０を含み得る。一実施形態においては、インフラストラクチャリソース２０３０は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームによって提供されるサービスを実行するための、サーバ、ストレージおよびネットワーキングリソースなどのハードウェアの予め一体化された最適な組合せを含み得る。

いくつかの実施形態においては、クラウドインフラストラクチャシステム２００２におけるリソースは、複数のユーザによって共有され、デマンドごとに動的に再割り振りされてもよい。また、リソースは、異なる時間帯にユーザに割り振られてもよい。たとえば、クラウドインフラストラクチャシステム２０３０は、第１の時間帯におけるユーザの第１の組が規定の時間にわたってクラウドインフラストラクチャシステムのリソースを利用することを可能にし得るとともに、異なる時間帯に位置するユーザの別の組への同一のリソースの再割り振りを可能にし得ることによって、リソースの利用を最大化することができる。

特定の実施形態においては、クラウドインフラストラクチャシステム２００２のさまざまな構成要素またはモジュール、および、クラウドインフラストラクチャシステム２００２によって提供されるサービス、によって共有されるいくつかの内部共有サービス２０３２が提供され得る。これらの内部共有サービスは、セキュリティおよびアイデンティティサービス、インテグレーションサービス、企業リポジトリサービス、企業マネージャサービス、ウイルススキャンおよびホワイトリストサービス、高可用性・バックアップおよび回復サービス、クラウドサポートを可能にするためのサービス、ｅメールサービス、通知サービス、ファイル転送サービスなどを含み得るが、これらに限定されるものではない。

特定の実施形態においては、クラウドインフラストラクチャシステム２００２は、クラウドインフラストラクチャシステムにおけるクラウドサービス（たとえばＳａａＳサービス、ＰａａＳサービスおよびＩａａＳサービス）の包括的管理を提供し得る。一実施形態においては、クラウド管理機能は、クラウドインフラストラクチャシステム２００２によって受信された顧客のサブスクリプションをプロビジョニング、管理および追跡などするための機能を含み得る。

一実施形態においては、図２０に示されるように、クラウド管理機能は、オーダー管理モジュール２０２０、オーダーオーケストレーションモジュール２０２２、オーダープロビジョニングモジュール２０２４、オーダー管理および監視モジュール２０２６、ならびにアイデンティティ管理モジュール２０２８などの１つ以上のモジュールによって提供され得る。これらのモジュールは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、またはその他の適切な構成および／もしくは組み合わせであり得る１つ以上のコンピュータおよび／またはサーバを含み得るか、またはそれらを用いて提供され得る。

例示的な動作２０３４において、クライアントデバイス２００４，２００６または２００８などのクライアントデバイスを用いる顧客は、クラウドインフラストラクチャシステム２００２によって提供される１つ以上のサービスを要求し、クラウドインフラストラクチャシステム２００２によって供給される１つ以上のサービスのサブスクリプションについてオーダーを行うことによって、クラウドインフラストラクチャシステム２００２と対話し得る。特定の実施形態においては、顧客は、クラウドユーザインターフェース（User
Interface：ＵＩ）、すなわちクラウドＵＩ２０１２、クラウドＵＩ２０１４および／またはクラウドＵＩ２０１６にアクセスして、これらのＵＩを介してサブスクリプションオーダーを行い得る。顧客がオーダーを行ったことに応答してクラウドインフラストラクチャシステム２００２によって受信されたオーダー情報は、顧客と、顧客がサブスクライブ
する予定のクラウドインフラストラクチャシステム２００２によって提供される１つ以上のサービスとを特定する情報を含み得る。

オーダーが顧客によって行われた後、オーダー情報は、クラウドＵＩ２０１２，２０１４および／または２０１６を介して受信される。

動作２０３６において、オーダーは、オーダーデータベース２０１８に格納される。オーダーデータベース２０１８は、クラウドインフラストラクチャシステム２０１８によって動作されるとともに他のシステム要素と連携して動作されるいくつかのデータベースのうちの１つであってもよい。

動作２０３８において、オーダー情報は、オーダー管理モジュール２０２０に転送される。いくつかの例では、オーダー管理モジュール２０２０は、オーダーの確認および確認時のオーダーの予約などのオーダーに関連する請求書発行機能および会計経理機能を実行するように構成され得る。

動作２０４０において、オーダーに関する情報は、オーダーオーケストレーションモジュール２０２２に通信される。オーダーオーケストレーションモジュール２０２２は、顧客によって行われたオーダーについてのサービスおよびリソースのプロビジョニングをオーケストレートするためにオーダー情報を利用し得る。いくつかの例では、オーダーオーケストレーションモジュール２０２２は、オーダープロビジョニングモジュール２０２４のサービスを用いてサブスクライブされたサービスをサポートするためにリソースのプロビジョニングをオーケストレートし得る。

特定の実施形態においては、オーダーオーケストレーションモジュール２０２２は、各々のオーダーに関連付けられるビジネスプロセスの管理を可能にし、ビジネス論理を適用してオーダーがプロビジョニングに進むべきか否かを判断する。動作２０４２において、新たなサブスクリプションについてのオーダーを受信すると、オーダーオーケストレーションモジュール２０２２は、リソースを割り振って当該サブスクリプションオーダーを満たすのに必要とされるそれらのリソースを構成するための要求をオーダープロビジョニングモジュール２０２４に送る。オーダープロビジョニングモジュール２０２４は、顧客によってオーダーされたサービスについてのリソースの割り振りを可能にする。オーダープロビジョニングモジュール２０２４は、クラウドインフラストラクチャシステム２０００によって提供されるクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理的実装層との間にあるレベルの抽象化を提供する。したがって、オーダーオーケストレーションモジュール２０２２は、サービスおよびリソースが実際に実行中にプロビジョニングされるか、事前にプロビジョニングされて要求があったときに割振られる／割当てられるのみであるかなどの実装の詳細から切り離すことができる。

動作２０４４において、サービスおよびリソースがプロビジョニングされると、提供されたサービスの通知が、クラウドインフラストラクチャシステム２００２のオーダープロビジョニングモジュール２０２４によってクライアントデバイス２００４，２００６および／または２００８上の顧客に送られ得る。

動作２０４６において、顧客のサブスクリプションオーダーが、オーダー管理および監視モジュール２０２６によって管理および追跡され得る。いくつかの例では、オーダー管理および監視モジュール２０２６は、使用される記憶量、転送されるデータ量、ユーザの数、ならびにシステムアップ時間およびシステムダウン時間などのサブスクリプションオーダーにおけるサービスについての使用統計を収集するように構成され得る。

特定の実施形態においては、クラウドインフラストラクチャシステム２０００は、アイデンティティ管理モジュール２０２８を含み得る。アイデンティティ管理モジュール２０２８は、クラウドインフラストラクチャシステム２０００におけるアクセス管理および認可サービスなどのアイデンティティサービスを提供するように構成され得る。いくつかの実施形態においては、アイデンティティ管理モジュール２０２８は、クラウドインフラストラクチャシステム２００２によって提供されるサービスを利用したい顧客についての情報を制御し得る。このような情報は、このような顧客のアイデンティティを認証する情報と、それらの顧客がさまざまなシステムリソース（たとえばファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に対してどのアクションを実行することを認可されるかを記載する情報とを含み得る。また、アイデンティティ管理モジュール２０２８は、各々の顧客についての説明的情報、ならびに、どのようにしておよび誰によってこの説明的情報がアクセスおよび変更され得るかについての情報の管理を含み得る。

図２１は、本発明のさまざまな実施形態を実現することができる例示的なコンピュータシステム２１００を示す。システム２１００は、上記のコンピュータシステムのうちのいずれかを実現するために使用され得る。たとえば、図１に示される電力不正検出システムの要素のすべてまたはいくつかは、システム２１００に含まれ得るかまたは実現され得る。図２１に示されているように、コンピュータシステム２１００は、バスサブシステム２１０２を介していくつかの周辺サブシステムと通信する処理ユニット２１０４を含む。これらの周辺サブシステムは、処理加速ユニット２１０６と、Ｉ／Ｏサブシステム２１０８と、記憶サブシステム２１１８と、通信サブシステム２１２４とを含み得る。記憶サブシステム２１１８は、有形のコンピュータ読取可能な記憶媒体２１２２と、システムメモリ２１１０とを含む。

バスサブシステム２１０２は、コンピュータシステム２１００のさまざまな構成要素およびサブシステムに、意図されたように互いに通信させるための機構を提供する。バスサブシステム２１０２は、単一のバスとして概略的に示されているが、バスサブシステムの代替的な実施形態は、複数のバスを利用してもよい。バスサブシステム２１０２は、メモリバスまたはメモリコントローラ、周辺バス、およびさまざまなバスアーキテクチャのうちのいずれかを使用するローカルバスを含むいくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、このようなアーキテクチャは、ＩＥＥＥ Ｐ１３８６．１標準に合わせて製造されたメザニンバスとして実現可能な、業界標準アーキテクチャ（Industry Standard Architecture：ＩＳＡ）バス、マイクロチャネルアーキテクチャ（Micro Channel Architecture：ＭＣＡ）バス、拡張ＩＳＡ（Enhanced ISA：ＥＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（Video Electronics Standards Association：ＶＥＳＡ）ローカルバスおよび周辺機器相互接続（Peripheral Component Interconnect：ＰＣＩ）バスを含み得る。

１つ以上の集積回路（たとえば従来のマイクロプロセッサまたはマイクロコントローラ）として実現可能な処理ユニット２１０４は、コンピュータシステム２１００の動作を制御する。処理ユニット２１０４には、１つ以上のプロセッサが含まれ得る。これらのプロセッサは、単一コアまたはマルチコアのプロセッサを含み得る。特定の実施形態においては、処理ユニット２１０４は、各々の処理ユニットに含まれる単一コアまたはマルチコアのプロセッサを有する１つ以上の独立した処理ユニット２１３２および／または２１３４として実現されてもよい。また、他の実施形態においては、処理ユニット２１０４は、２つのデュアルコアプロセッサを単一のチップに組み入れることによって形成されるクアッドコア処理ユニットとして実現されてもよい。

さまざまな実施形態においては、処理ユニット２１０４は、プログラムコードに応答してさまざまなプログラムを実行し得るとともに、同時に実行される複数のプログラムまたはプロセスを維持し得る。任意の所与の時点において、実行されるべきプログラムコードのうちのいくつかまたは全ては、プロセッサ２１０４および／または記憶サブシステム２１１８に存在し得る。好適なプログラミングを通じて、プロセッサ２１０４は、上記のさまざまな機能を提供し得る。また、コンピュータシステム２１００は、加えて、デジタル信号プロセッサ（digital signal processor：ＤＳＰ）、特殊用途プロセッサなどを含み得る処理加速ユニット２１０６を含み得る。

Ｉ／Ｏサブシステム２１０８は、ユーザインターフェイス入力装置と、ユーザインターフェイス出力装置とを含み得る。ユーザインターフェイス入力装置は、キーボード、マウスまたはトラックボールなどのポインティング装置、タッチパッドまたはタッチスクリーンを含んでいてもよく、これらは、音声コマンド認識システム、マイクロホンおよび他のタイプの入力装置とともに、ディスプレイ、スクロールホイール、クリックホイール、ダイアル、ボタン、スイッチ、キーパッド、オーディオ入力装置に組込まれている。ユーザインターフェイス入力装置は、たとえば、ジェスチャおよび話されたコマンドを用いてナチュラルユーザインターフェースを介してユーザがマイクロソフトＸｂｏｘ（登録商標）３６０ゲームコントローラなどの入力装置を制御して入力装置と対話することを可能にするマイクロソフトキネクト（登録商標）モーションセンサなどのモーション検知および／またはジェスチャ認識装置を含み得る。また、ユーザインターフェイス入力装置は、ユーザから眼球運動（たとえば撮影および／またはメニュー選択を行っている間の「まばたき」）を検出して、当該眼球ジェスチャを入力装置への入力として変換するグーグルグラス（登録商標）まばたき検出器などの眼球ジェスチャ認識装置を含み得る。また、ユーザインターフェイス入力装置は、ユーザが音声コマンドを介して音声認識システム（たとえばＳｉｒｉ（登録商標）ナビゲータ）と対話することを可能にする音声認識検知装置を含み得る。

また、ユーザインターフェイス入力装置は、三次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、およびスピーカなどのオーディオ／ビジュアル装置、デジタルカメラ、デジタルカムコーダ、携帯型メディアプレーヤ、ウェブカム、画像スキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザレンジファインダ、および視線検出装置を含み得るが、これらに限定されるものではない。また、ユーザインターフェイス入力装置は、たとえば、コンピュータ断層撮影、磁気共鳴画像化、位置発光断層撮影、医療用超音波検査装置などの医療用画像化入力装置を含み得る。また、ユーザインターフェイス入力装置は、たとえばＭＩＤＩキーボード、デジタル楽器などのオーディオ入力装置を含み得る。

ユーザインターフェイス出力装置は、ディスプレイサブシステム、表示灯、またはオーディオ出力装置などの非視覚的ディスプレイなどを含み得る。ディスプレイサブシステムは、陰極線管（cathode ray tube：ＣＲＴ）、液晶ディスプレイ（liquid crystal display：ＬＣＤ）またはプラズマディスプレイを使用するものなどのフラットパネルディスプレイ、投影装置、タッチスクリーンなどであってもよい。一般に、「出力装置」という用語の使用は、コンピュータシステム２１００からの情報をユーザまたは他のコンピュータに出力するための全ての実現可能なタイプの装置および機構を含むよう意図されている。たとえば、ユーザインターフェイス出力装置は、モニタ、プリンタ、スピーカ、ヘッドホン、自動車のナビゲーションシステム、プロッタ、音声出力装置およびモデムなどの、テキスト、グラフィックスおよびオーディオ／ビデオ情報を視覚的に伝えるさまざまな表示装置を含み得るが、これらに限定されるものではない。

コンピュータシステム２１００は、現在のところシステムメモリ２１１０内に位置して
いるように示されているソフトウェア要素を備える記憶サブシステム２１１８を備え得る。システムメモリ２１１０は、処理ユニット２１０４上でロード可能および実行可能なプログラム命令と、これらのプログラムの実行中に生成されるデータとを格納し得る。

コンピュータシステム２１００の構成およびタイプに応じて、システムメモリ２１１０は、揮発性（ランダムアクセスメモリ（random access memory：ＲＡＭ）など）であってもよく、および／または、不揮発性（リードオンリメモリ（read-only memory：ＲＯＭ）、フラッシュメモリなど）であってもよい。ＲＡＭは、典型的には、処理ユニット２１０４が直ちにアクセス可能なデータおよび／またはプログラムモジュール、および／または、処理ユニット２１０４によって現在動作および実行されているデータおよび／またはプログラムモジュールを収容する。いくつかの実現例では、システムメモリ２１１０は、スタティックランダムアクセスメモリ（static random access memory：ＳＲＡＭ）または
ダイナミックランダムアクセスメモリ（dynamic random access memory：ＤＲＡＭ）などの複数の異なるタイプのメモリを含み得る。いくつかの実現例では、始動中などにコンピュータシステム２１００内の要素間で情報を転送することを助ける基本ルーチンを含む基本入力／出力システム（basic input/output system：ＢＩＯＳ）が、典型的にはＲＯＭ
に格納され得る。一例としておよび非限定的に、システムメモリ２１１０は、クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、リレーショナルデータベース管理システム（relational database management system：ＲＤＢＭＳ）などを含
み得るアプリケーションプログラム２１１２、プログラムデータ２１１４およびオペレーティングシステム２１１６も示す。一例として、オペレーティングシステム２１１６は、マイクロソフトウィンドウズ（登録商標）、アップルマッキントッシュ（登録商標）および／もしくはリナックスオペレーティングシステムのさまざまなバージョン、さまざまな市販のＵＮＩＸ（登録商標）もしくはＵＮＩＸライクオペレーティングシステム（さまざまなＧＮＵ／リナックスオペレーティングシステム、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ（登録商標）ＯＳなどを含むが、これらに限定されるものではない）、ならびに／または、ｉＯＳ、ウィンドウズ（登録商標）フォン、アンドロイド（登録商標）ＯＳ、ブラックベリー（登録商標）１０ＯＳおよびパーム（登録商標）ＯＳオペレーティングシステムなどのモバイルオペレーティングシステムを含み得る。

また、記憶サブシステム２１１８は、いくつかの実施形態の機能を提供する基本的なプログラミングおよびデータ構造を格納するための有形のコンピュータ読取可能な記憶媒体を提供し得る。プロセッサによって実行されたときに上記の機能を提供するソフトウェア（プログラム、コードモジュール、命令）が記憶サブシステム２１１８に格納され得る。これらのソフトウェアモジュールまたは命令は、処理ユニット２１０４によって実行され得る。また、記憶サブシステム２１１８は、本発明に従って使用されるデータを格納するためのリポジトリを提供し得る。

また、記憶サブシステム２１００は、コンピュータ読取可能な記憶媒体２１２２にさらに接続可能なコンピュータ読取可能な記憶媒体リーダ２１２０を含み得る。ともにおよび任意には、システムメモリ２１１０と組合せて、コンピュータ読取可能な記憶媒体２１２２は、コンピュータ読取可能な情報を一時的および／または永久に収容、格納、送信および検索するための記憶媒体に加えて、リモートの、ローカルの、固定されたおよび／または取外し可能な記憶装置を包括的に表わし得る。

コードまたはコードの一部を含むコンピュータ読取可能な記憶媒体２１２２は、当該技術分野において公知のまたは使用される任意の適切な媒体を含み得る。当該媒体は、情報の格納および／または送信のための任意の方法または技術において実現される揮発性および不揮発性の、取外し可能および取外し不可能な媒体などであるが、これらに限定されるものではない記憶媒体および通信媒体を含む。これは、ＲＡＭ、ＲＯＭ、電子的消去・プ
ログラム可能ＲＯＭ（electronically erasable programmable ROM：ＥＥＰＲＯＭ）、フラッシュメモリもしくは他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（digital versatile disk：ＤＶＤ）、または他の光学式記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、または他の有形のコンピュータ読取可能な媒体などの有形の一時的なコンピュータ読取可能な記憶媒体を含み得る。また、これは、データ信号、データ送信などの無形の一時的なコンピュータ読取可能な媒体、または、所望の情報を送信するために使用可能であるとともに計算システム４００によってアクセス可能である他の任意の媒体を含み得る。

一例として、コンピュータ読取可能な記憶媒体２１２２は、取外し不可能な不揮発性磁気媒体から読取るまたは当該媒体に書込むハードディスクドライブ、取外し可能な不揮発性磁気ディスクから読取るまたは当該ディスクに書込む磁気ディスクドライブ、ならびに、ＣＤ ＲＯＭ、ＤＶＤおよびブルーレイ（登録商標）ディスクまたは他の光学式媒体などの取外し可能な不揮発性光学ディスクから読取るまたは当該ディスクに書込む光学式ディスクドライブを含み得る。コンピュータ読取可能な記憶媒体２１２２は、ジップ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（universal serial bus：ＵＳＢ）フラッシュドライブ、セキュアデジタル（secure digital：ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含み得るが、これらに限定されるものではない。また、コンピュータ読取可能な記憶媒体２１２２は、フラッシュメモリベースのＳＳＤ、企業向けフラッシュドライブ、ソリッドステートＲＯＭなどの不揮発性メモリに基づくソリッドステートドライブ（solid-state drive：ＳＳＤ）、ソリッドステート
ＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭなどの揮発性メモリに基づくＳＳＤ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（magnetoresistive RAM：ＭＲＡＭ）ＳＳＤ、およびＤＲＡＭとフラッシュメモリベースのＳＳＤとの組合せを使用するハイブリッドＳＳＤを含み得る。ディスクドライブおよびそれらの関連のコンピュータ読取可能な媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュールおよび他のデータをコンピュータシステム２１００に提供し得る。

通信サブシステム２１２４は、他のコンピュータシステムおよびネットワークとのインターフェイスを提供する。通信サブシステム２１２４は、他のシステムからデータを受信したり、コンピュータシステム２１００から他のシステムにデータを送信するためのインターフェイスの役割を果たす。たとえば、通信サブシステム２１２４は、コンピュータシステム２１００がインターネットを介して１つ以上の装置に接続することを可能にし得る。いくつかの実施形態においては、通信サブシステム２１２４は、（たとえば３Ｇ、４ＧまたはＥＤＧＥ（enhanced data rates for global evolution）などの携帯電話技術、高度データネットワーク技術を用いて）無線音声および／またはデータネットワークにアクセスするための無線周波数（radio frequency：ＲＦ）トランシーバコンポーネント、Ｗ
ｉＦｉ（ＩＥＥＥ１９０２．１１ファミリ標準または他のモバイル通信技術またはそれらの任意の組合せ）、全地球測位システム（global positioning system：ＧＰＳ）レシー
バコンポーネント、および／または、他のコンポーネントを含み得る。いくつかの実施形態においては、通信サブシステム２１２４は、無線インターフェイスに加えて、または無線インターフェイスの代わりに、有線ネットワーク接続（例えばイーサネット）を提供し得る。

また、いくつかの実施形態においては、通信サブシステム２１２４は、コンピュータシステム２１００を使用し得る１人以上のユーザを代表して、構造化されたおよび／または構造化されていないデータフィード２１２６、イベントストリーム２１２８、イベント更新２１３０などの形態で入力通信を受信し得る。

一例として、通信サブシステム２１２４は、ツイッター（登録商標）フィード、フェー
スブック（登録商標）更新、リッチ・サイト・サマリ（Rich Site Summary：ＲＳＳ）フ
ィードなどのウェブフィードなどのデータフィード２１２６をリアルタイムでソーシャルメディアネットワークおよび／または他の通信サービスのユーザから受信し、および／または、１つ以上の第三者情報源からリアルタイム更新を受信するように構成され得る。

加えて、通信サブシステム２１２４は、連続的なデータストリームの形態でデータを受信するように構成され得る。当該データは、連続的である場合もあれば本質的に明確な端部をもたない状態で境界がない場合もあるリアルタイムイベントのイベントストリーム２１２８および／またはイベント更新２１３０を含み得る。連続的なデータを生成するアプリケーションの例としては、たとえばセンサデータアプリケーション、金融ティッカ、ネットワーク性能測定ツール（たとえばネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通モニタリングなどを含み得る。

また、通信サブシステム２１２４は、構造化されたおよび／または構造化されていないデータフィード２１２６、イベントストリーム２１２８、イベント更新２１３０などを、コンピュータシステム２１００に結合された１つ以上のストリーミングデータソースコンピュータと通信し得る１つ以上のデータベースに出力するように構成され得る。

コンピュータシステム２１００は、手持ち式携帯機器（たとえばｉＰｈｏｎｅ（登録商標）携帯電話、ｉＰａｄ（登録商標）計算タブレット、ＰＤＡ）、ウェアラブル装置（たとえばグーグルグラス（登録商標）ヘッドマウントディスプレイ）、ＰＣ、ワークステーション、メインフレーム、キオスク、サーバラックまたはその他のデータ処理システムを含むさまざまなタイプのうちの１つであってもよい。

コンピュータおよびネットワークの絶え間なく変化し続ける性質のために、図２１に示されているコンピュータシステム２１００の説明は、特定の例として意図されているに過ぎない。図２１に示されているシステムよりも多くのまたは少ない数の構成要素を有する多くの他の構成が可能である。たとえば、ハードウェア、ファームウェア、（アプレットを含む）ソフトウェア、または組合せにおいて、カスタマイズされたハードウェアが使用されてもよく、および／または、特定の要素が実装されてもよい。さらに、ネットワーク入力／出力装置などの他のコンピューティングデバイスへの接続が利用されてもよい。本明細書中に提供される開示および教示に基づいて、当業者は、さまざまな実施形態を実現するための他の手段および／または方法を理解するであろう。

上述の明細書では、本発明の局面は、その具体的な実施形態を参照して記載されているが、本発明はこれに限定されるものではないことを当業者は認識するであろう。上述の発明のさまざまな特徴および局面は、個々にまたは一緒に使用されてもよい。さらに、実施形態は、明細書のより広い精神および範囲から逸脱することなく、本明細書に記載されているものを越えたいくつもの環境およびアプリケーションでも利用可能である。したがって、明細書および図面は、限定的ではなく例示的なものとみなされるべきである。

Claims (19)

1. 電力不正を検出するためのコンピューティングシステムであって、
   １つ以上のプロセッサと、
   複数の命令が格納されたメモリとを含み、前記複数の命令は、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
   疑わしい既知の事例のセットおよび説明済みの既知の事例のセットを用いて、それぞれ、検出器モデルおよび説明モデルを検証させる命令を含み、前記疑わしい既知の事例のセットは不正に関連付けられた既知の事例を含み、前記不正に関連付けられた既知の事例は各々、前記検出器モデルを用いて識別された複数の疑わしいアクティビティのうち１つの疑わしいアクティビティを含み、前記説明済みの既知の事例のセットは、各々が、関連付けられた疑わしいアクティビティについての複数の正当な説明のうちの１つの正当な説明を有するとともに前記説明モデルを用いて識別される前記疑わしい既知の事例のサブセットであり、前記複数の命令はさらに、
   未知の事例を含むデータアイテムに前記検出器モデルを適用して、疑わしい未知の事例のセットを生成させる命令を含み、前記データアイテムの各々は、それぞれのサービスポイントでそれぞれの電力メータに関連付けられた電力需要データを含み、前記疑わしい未知の事例のセットは、前記複数の疑わしいアクティビティのうちの１つの疑わしいアクティビティを含み、前記複数の命令はさらに、
   前記疑わしい未知の事例のセットにおける前記未知の事例の各々に前記説明モデルを適用して、説明済みの未知の事例のセットを生成させる命令を含み、前記説明済みの未知の事例の各々は、前記関連付けられた疑わしいアクティビティについての前記複数の正当な説明のうちの１つの正当な説明を含み、前記複数の命令はさらに、
   前記疑わしい未知の事例のセットから前記説明済みの未知の事例のセットを除去して、未説明の未知の事例のセットを生成させる命令を含む、コンピューティングシステム。
2. 未知の事例を含む前記データアイテムに前記検出器モデルを適用して前記疑わしい未知の事例のセットを生成させる命令はさらに、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
   前記データアイテムを用いて各々の未知の事例ごとに需要プロフィールを計算させる命令と、
   各々の未知の事例ごとに前記需要プロフィールに前記検出器モデルを適用させる命令とを含む、請求項１に記載のコンピューティングシステム。
3. 前記複数の疑わしいアクティビティは、突然低下した後に低いままとどまる需要、緩やかに低下した後に低いままとどまる需要、長期間にわたって緩やかに低下する需要、低い需要、異常に一定である需要、または、予想外に変化する需要のうちの少なくとも１つを含む、請求項１または２に記載のコンピューティングシステム。
4. 前記複数の正当な説明は、顧客による太陽電池パネルの使用、機器の故障、グリッド過負荷、電力会社の停止、それぞれの敷地における居住者の変化、極端な気候、および、顧客による発電機の使用のうちの少なくとも１つを含む、請求項１～３のいずれか１項に記載のコンピューティングシステム。
5. 前記メモリにはさらに、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
   調査のために前記未説明の未知の事例のセットの前記未説明の未知の事例のうちの少なくとも１つを含む通知を送信させる命令が格納されている、請求項１～４のいずれか１項に記載のコンピューティングシステム。
6. 前記複数の疑わしいアクティビティは低い需要を含み、低い需要は、複数の顧客にわたる需要に基づいてしきい値百分率よりも低いものとして規定される、請求項１または２に記載のコンピューティングシステム。
7. 前記複数の疑わしいアクティビティは低い需要を含み、低い需要は、それぞれの敷地における電力使用の対価のバランスを取るように構成されたアルゴリズムに基づいて自動的に設定されるしきい値よりも低いものとして規定される、請求項１または２に記載のコンピューティングシステム。
8. 前記メモリにはさらに、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
   前記データアイテムを用いて各々の未知の事例ごとに需要プロフィールを計算させる命令と、
   各々の未知の事例ごとに前記需要プロフィールをランク付けさせる命令とが格納されている、請求項１～７のいずれか１項に記載のコンピューティングシステム。
9. 前記メモリにはさらに、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
   外部データソースを用いて前記複数の正当な説明のうちの１つ以上の正当な説明を生成させる命令が格納されている、請求項１～８のいずれか１項に記載のコンピューティングシステム。
10. 電力不正を検出するための、コンピュータによって実現される方法であって、
    疑わしい既知の事例のセットおよび説明済みの既知の事例のセットを用いて、それぞれ、検出器モデルおよび説明モデルを検証するステップを含み、前記疑わしい既知の事例のセットは不正に関連付けられた既知の事例を含み、前記不正に関連付けられた既知の事例は各々、前記検出器モデルを用いて識別された複数の疑わしいアクティビティのうち１つの疑わしいアクティビティを含み、前記説明済みの既知の事例のセットは、各々が、関連付けられた疑わしいアクティビティについての複数の正当な説明のうちの１つの正当な説明を有するとともに前記説明モデルを用いて識別される前記疑わしい既知の事例のサブセットであり、前記方法はさらに、
    未知の事例を含むデータアイテムに前記検出器モデルを適用して、疑わしい未知の事例のセットを生成するステップを含み、前記データアイテムの各々は、それぞれのサービスポイントでそれぞれの電力メータに関連付けられた電力需要データを含み、前記疑わしい未知の事例のセットは、前記複数の疑わしいアクティビティのうちの１つの疑わしいアクティビティを含み、前記方法はさらに、
    前記疑わしい未知の事例のセットにおける前記未知の事例の各々に前記説明モデルを適用して、説明済みの未知の事例のセットを生成するステップを含み、前記説明済みの未知の事例の各々は、前記関連付けられた疑わしいアクティビティについての前記複数の正当な説明のうちの１つの正当な説明を含み、前記方法はさらに、
    前記疑わしい未知の事例のセットから前記説明済みの未知の事例のセットを除去して、未説明の未知の事例のセットを生成するステップを含む、コンピュータによって実現される方法。
11. 未知の事例を含む前記データアイテムに前記検出器モデルを適用するステップは、
    前記データアイテムを用いて各々の未知の事例ごとに需要プロフィールを計算するステップと、
    各々の未知の事例ごとに前記需要プロフィールに前記検出器モデルを適用するステップとを含む、請求項１０に記載の、コンピュータによって実現される方法。
12. 前記複数の疑わしいアクティビティは、突然低下した後に低いままとどまる需要、緩やかに低下した後に低いままとどまる需要、長期間にわたって緩やかに低下する需要、低い需要、異常に一定である需要、または、予想外に変化する需要のうちの少なくとも１つを含む、請求項１０または１１に記載の、コンピュータによって実現される方法。
13. 前記複数の正当な説明は、顧客による太陽電池パネルの使用、機器の故障、グリッド過負荷、電力会社の停止、それぞれの敷地における居住者の変化、極端な気候、および、顧客による発電機の使用のうちの少なくとも１つを含む、請求項１０～１２のいずれか１項に記載の、コンピュータによって実現される方法。
14. 調査のために前記未説明の未知の事例のセットの前記未説明の未知の事例のうちの少なくとも１つを含む通知を送信するステップをさらに含む、請求項１０～１３のいずれか１項に記載の、コンピュータによって実現される方法。
15. 前記複数の疑わしいアクティビティは低い需要を含み、低い需要は、複数の顧客にわたる需要に基づいてしきい値百分率よりも低いものとして規定される、請求項１０または１１に記載の、コンピュータによって実現される方法。
16. 前記複数の疑わしいアクティビティは低い需要を含み、低い需要は、それぞれの敷地における電力使用の対価のバランスを取るように構成されたアルゴリズムに基づいて自動的に設定されるしきい値よりも低いものとして規定される、請求項１０または１１に記載の、コンピュータによって実現される方法。
17. 前記データアイテムを用いて各々の未知の事例ごとに需要プロフィールを計算するステップと、
    各々の未知の事例ごとに前記需要プロフィールをランク付けするステップとをさらに含む、請求項１０～１６のいずれか１項に記載の、コンピュータによって実現される方法。
18. 外部データソースを用いて前記複数の正当な説明のうちの１つ以上の正当な説明を生成するステップをさらに含む、請求項１０～１７のいずれか１項に記載の、コンピュータによって実現される方法。
19. １以上のプロセッサに請求項１０～１８のいずれか１項に記載の方法を実行させるプログラム。

Images