(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023029983
(43)【公開日】2023-03-07
(54)【発明の名称】電力不正使用検出のための新しい非パラメトリック統計的挙動識別エコシステム
(51)【国際特許分類】
G06Q 50/06 20120101AFI20230228BHJP
【FI】
G06Q50/06
【審査請求】有
【請求項の数】19
【出願形態】OL
【外国語出願】
(21)【出願番号】P 2022195769
(22)【出願日】2022-12-07
(62)【分割の表示】P 2019542656の分割
【原出願日】2018-03-15
(31)【優先権主張番号】62/485,319
(32)【優先日】2017-04-13
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】15/820,326
(32)【優先日】2017-11-21
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】502303739
【氏名又は名称】オラクル・インターナショナル・コーポレイション
(74)【代理人】
【識別番号】110001195
【氏名又は名称】弁理士法人深見特許事務所
(72)【発明者】
【氏名】アッバス,フセイン
(57)【要約】 (修正有)
【課題】電力不正使用検出のための新しい非パラメトリック統計的挙動識別エコシステムを及び方法を提供する。
【解決手段】誤判定率を減らしつつ、電力不正の検出率を向上させるための挙動検出エコシステムを備える電力不正検出システムであって、、機械学習アルゴリズムは、順々に適用される2つの別個のモデルに有利になるように回避される。第1のモデルは、それぞれの顧客の需要プロフィールに基づいて疑わしい挙動に関与している顧客を識別するために、検出器を使用することによって電力不正の検出率を向上させる。第2のモデルは、任意の疑わしい挙動についての潜在的な正当な説明を識別することによって誤判定率を減らす。正当な説明を伴う疑わしい挙動を差し引くことにより、不正行為に関連付けられる可能性が極めて高い、識別済みであるが未説明である疑わしい挙動だけが残ることとなる。
【選択図】
図2A
【特許請求の範囲】
【請求項1】
電力不正を検出するための、コンピュータによって実現される方法であって、
既知のデータセットにアクセスするステップを含み、前記既知のデータセットは、電力不正の既知の事例に関連付けられた第1のデータ項目を含み、前記方法はさらに、
モデルの検出器挙動を前記第1のデータ項目に少なくとも適用することによって、疑わしい既知の事例のセットを判断するステップと、
前記モデルの1つ以上の誤判定説明に対して前記疑わしい既知の事例のセットにおける既知の事例の各々を分析することによって、前記疑わしい既知の事例のセットから、説明済みの既知の事例のセットを判断するステップとを含み、前記説明済みの既知の事例のセットは前記疑わしい既知の事例のセットのサブセットであり、前記方法はさらに、
前記疑わしい既知の事例のセットについての判断に基づいて前記モデルを検証するステップと、
未知のデータセットにアクセスするステップとを含み、前記未知のデータセットは、複数のサービスポイントにおける電力不正の未知の事例に関連付けられた第2のデータ項目を含み、前記複数のサービスポイントの各サービスポイントは電力メータに対応しており、前記第2のデータ項目は、各サービスポイントに対応する前記電力メータに関連付けられた電力需要を含み、前記方法はさらに、
前記検出器挙動を前記第2のデータ項目に少なくとも適用することによって、疑わしい未知の事例のセットを判断するステップと、
前記1つ以上の誤判定説明に対して前記疑わしい未知の事例のセットにおける未知の事例の各々を分析することによって、前記疑わしい未知の事例のセットから、説明済みの既知の事例のセットを判断するステップとを含み、前記説明済みの未知の事例のセットは前記疑わしい未知の事例のセットのサブセットであり、前記方法はさらに、
前記疑わしい未知の事例のセットから前記説明済みの未知の事例のセットを差し引くことによって未説明の未知の事例のセットを判断するステップを含み、前記未説明の未知の事例のセットは、前記説明済みの未知の事例のセットと重複しない前記疑わしい未知の事例のセットのサブセットである、コンピュータによって実現される方法。
【請求項2】
前記検出器挙動は、突然上昇した後に低いままとどまる電力需要を含む、請求項1に記載の、コンピュータによって実現される方法。
【請求項3】
前記検出器挙動は、緩やかに低下した後に低いままとどまる電力需要を含む、請求項1に記載の、コンピュータによって実現される方法。
【請求項4】
前記検出器挙動は、長期間にわたって緩やかに低下する電力需要を含む、請求項1に記載の、コンピュータによって実現される方法。
【請求項5】
前記検出器挙動は非常に低い電力需要を含む、請求項1に記載の、コンピュータによって実現される方法。
【請求項6】
前記検出器挙動は、予想通りに上昇しない電力需要を含む、請求項1に記載の、コンピュータによって実現される方法。
【請求項7】
前記検出器挙動は、異常に安定している電力需要を含む、請求項1に記載の、コンピュータによって実現される方法。
【請求項8】
コンピューティングシステムであって、
1つ以上のデータストアを備え、前記1つ以上のデータストアは、
電力不正の既知の事例に関連付けられた第1のデータ項目を含む既知のデータセット
と、
複数のサービスポイントにおいて電力不正の未知の事例に関連付けられた第2のデータ項目を含む未知のデータセットとを含み、前記複数のサービスポイントの各サービスポイントは電力メータに対応しており、前記第2のデータ項目は、各サービスポイントに対応する前記電力メータに関連付けられた電力需要を含み、前記コンピューティングシステムはさらに、
コンピュータプロセッサと、
プログラム命令を格納するメモリとを備え、前記プログラム命令は、前記コンピュータプロセッサに、
前記既知のデータセットにアクセスさせ、
モデルの検出器挙動を前記第1のデータ項目に少なくとも適用することによって、疑わしい既知の事例のセットを判断させ、
前記モデルの1つ以上の誤判定説明に対して前記疑わしい既知の事例のセットにおける既知の事例の各々を分析することによって、前記疑わしい既知の事例のセットから説明済みの既知の事例のセットを判断させ、前記説明済みの既知の事例のセットは前記疑わしい既知の事例のセットのサブセットであり、前記プログラム命令はさらに、前記コンピュータプロセッサに、
前記疑わしい既知の事例のセットについての判断に基づいて前記モデルを検証させ、
前記未知のデータセットにアクセスさせ、
前記検出器挙動を前記第2のデータ項目に少なくとも適用することによって、疑わしい未知の事例のセットを判断させ、
前記1つ以上の誤判定説明に対して前記疑わしい未知の事例のセットにおける未知の事例の各々を分析することによって、前記疑わしい未知の事例のセットから、説明済みの未知の事例のセットを判断させ、前記説明済みの未知の事例のセットは前記疑わしい未知の事例のセットのサブセットであり、前記プログラム命令はさらに、前記コンピュータプロセッサに、
前記疑わしい未知の事例のセットから前記説明済みの未知の事例のセットを差し引くことによって未説明の未知の事例のセットを判断させるように、
前記コンピュータプロセッサによって実行されるように構成されており、前記未説明の未知の事例のセットは、前記説明済みの未知の事例のセットと重複しない前記疑わしい未知の事例のセットのサブセットである、コンピューティングシステム。
【請求項9】
前記検出器挙動は、突然上昇した後に低いままとどまる電力需要を含む、請求項8に記載のコンピューティングシステム。
【請求項10】
前記検出器挙動は、緩やかに低下した後に低いままとどまる電力需要を含む、請求項8に記載のコンピューティングシステム。
【請求項11】
前記検出器挙動は、長期間にわたって緩やかに低下する電力需要を含む、請求項8に記載のコンピューティングシステム。
【請求項12】
前記検出器挙動は非常に低い電力需要を含む、請求項8に記載のコンピューティングシステム。
【請求項13】
前記検出器挙動は、予想通りに上昇しない電力需要を含む、請求項8に記載のコンピューティングシステム。
【請求項14】
前記検出器挙動は、異常に安定している電力需要を含む、請求項8に記載のコンピューティングシステム。
【請求項15】
プログラム命令を含む非一時的なコンピュータ読取り可能媒体であって、前記プログラム命令は、コンピュータプロセッサに、
電力不正の既知の事例に関連付けられた第1のデータ項目を含む既知のデータセットにアクセスさせ、
モデルの検出器挙動を前記第1のデータ項目に少なくとも適用することによって、疑わしい既知の事例のセットを判断させ、
前記モデルの1つ以上の誤判定説明に対して前記疑わしい既知の事例のセットにおける既知の事例の各々を分析することによって、前記疑わしい既知の事例のセットから説明済みの既知の事例のセットを判断させ、前記説明済みの既知の事例のセットは前記疑わしい既知の事例のセットのサブセットであり、前記プログラム命令はさらに、前記コンピュータプロセッサに、
前記疑わしい既知の事例のセットについての判断に基づいて前記モデルを検証させ、
複数のサービスポイントにおける電力不正の未知の事例に関連付けられた第2のデータ項目を含む未知のデータセットにアクセスさせ、前記複数のサービスポイントの各サービスポイントは電力メータに対応しており、前記第2のデータ項目は、各サービスポイントに対応する前記電力メータに関連付けられた電力需要を含み、前記プログラム命令はさらに、前記コンピュータプロセッサに、
前記検出器挙動を前記第2のデータ項目に少なくとも適用することによって、疑わしい未知の事例のセットを判断させ、
前記1つ以上の誤判定説明に対して前記疑わしい未知の事例のセットにおける未知の事例の各々を分析することによって、前記疑わしい未知の事例のセットから、説明済みの未知の事例のセットを判断させ、前記説明済みの未知の事例のセットは前記疑わしい未知の事例のセットのサブセットであり、前記プログラム命令はさらに、前記コンピュータプロセッサに、
前記疑わしい未知の事例のセットから前記説明済みの未知の事例のセットを差し引くことによって未説明の未知の事例のセットを判断させるように、
前記コンピュータプロセッサによって実行されるように構成されており、前記未説明の未知の事例のセットは、前記説明済みの未知の事例のセットと重複しない前記疑わしい未知の事例のセットのサブセットである、非一時的なコンピュータ読取り可能媒体。
【請求項16】
前記検出器挙動は、突然上昇した後に低いままとどまる電力需要を含む、請求項15に記載の非一時的なコンピュータ読取り可能媒体。
【請求項17】
前記検出器挙動は、緩やかに低下した後に低いままとどまる電力需要を含む、請求項15に記載の非一時的なコンピュータ読取り可能媒体。
【請求項18】
前記検出器挙動は、長期間にわたって緩やかに低下する電力需要を含む、請求項15に記載の非一時的なコンピュータ読取り可能媒体。
【請求項19】
前記検出器挙動は非常に低い電力需要を含む、請求項15に記載の非一時的なコンピュータ読取り可能媒体。
【請求項20】
前記検出器挙動は、予想通りに上昇しない電力需要を含む、請求項15に記載の非一時的なコンピュータ読取り可能媒体。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本願は、2017年11月21日付で提出された米国非仮出願第15/820,326号と、2017年4月13日付で提出されて「電力不正使用を検出するための新しい非パラメトリック統計的挙動識別エコシステム(NOVEL NON-PARAMETRIC STATISTICAL BEHAVIORAL IDENTIFICATION ECOSYSTEM FOR ELECTRICITY FRAUD DETECTION)」と題された米国仮出願第62/485,319号との利益および優先権を主張するものであって、その各々が全体として引用によりあらゆる目的のためにここに援用されている。
【背景技術】
【0002】
背景
電力会社の顧客の中には、しばしば、代金を支払うことなく電力を盗むことによって不正を働く顧客がいる。広範囲にわたる不正の検出が困難であるため、これは電力会社にとって深刻な問題となっている。
【0003】
従来、電力会社は不正を検出するための3つの方法のうちの1つに依存してきた。3つの方法とは、すなわち、(1)深層主題の専門知識を有するとともに住宅着工許可件数などのデータソースの多様な集合にアクセスできる人の分析者;(2)電力計測技術の製造業者によって提供されるルールベースのシステム;または(3)明らかな不正の事例(たとえば、隣人が電力を盗んでいることが明らかである)について他の顧客が電力会社に通知するという運ベースのシステム、である。これらの方法は信頼性が低いが、このことは、大多数の不正事例が運ベースのシステムによって識別されていることによって証明されている。
【発明の概要】
【発明が解決しようとする課題】
【0004】
これらの方法の信頼性の欠如は、検出率が低いことと、誤判定率が高いこととが組合わさったことに起因している。いくつかの推定では、これらの従来の方法の誤判定率が80%であり、検出された不正事例の大部分が実際には不正ではない。この結果、電力会社にとって高額の費用が発生することとなり、不正を捕らえることがコスト/利益の観点からもはや有益でないというレベルにまで達している。不正を捕らえることがこのように経済的に不可能であるため、既存の詐欺師が大胆になるとともに潜在的な詐欺師による不正の実行が助長されることによって問題がさらに複雑になった。
【0005】
このため、低い検出率および高い誤判定率を伴うことなく不正を検出することができるとともに、住宅用電力および工業用電力の不正使用の検出に適用するのに十分にロバストである、信頼性のある電力不正検出システムが必要とされている。本開示の実施形態は、少なくともこれらの必要性に対処することを目的としている。
【課題を解決するための手段】
【0006】
概要
いくつかの実施形態においては、1つ以上のデータストアを含むコンピューティングシステムが開示される。当該1つ以上のデータストアは、電力不正の既知の事例に関連付けられた第1のデータ項目を含む既知のデータセットと、複数のサービスポイントにおける電力不正の未知の事例に関連付けられた第2のデータ項目を含む未知のデータセットとを格納する。この場合、複数のサービスポイントのうちの各サービスポイントは電力メータ
に対応する。第2のデータ項目は、各サービスポイントに対応する電力メータに関連付けられた電力需要を含む。
【0007】
コンピューティングシステムはまた、コンピュータプロセッサと、複数のプログラム命令を格納しているコンピュータ読取り可能記憶媒体とを含み得る。複数のプログラム命令は、コンピュータプロセッサに、既知のデータセットにアクセスさせるとともに、モデルの検出器挙動を第1のデータ項目に少なくとも適用することによって疑わしい既知の事例のセットを判断させるために、コンピュータプロセッサによって実行されるように構成されている。いくつかの実施形態においては、複数の命令は、コンピュータプロセッサに、当該モデルの1つ以上の誤判定説明に対して疑わしい既知の事例のセット内の既知の事例の各々を分析することによって、疑わしい既知の事例のセットから、説明済みの既知の事例のセットを判断させてもよい。この場合、説明済みの既知の事例のセットは疑わしい既知の事例のセットのサブセットである。いくつかの実施形態においては、複数の命令は、コンピュータプロセッサに、疑わしい既知の事例のセットについての判断に基づいてモデルを検証させ、未知のデータセットにアクセスさせ、および/または、少なくとも検出器挙動を第2のデータ項目に適用することによって疑わしい未知の事例のセットを判断させてもよい。いくつかの実施形態においては、複数の命令は、コンピュータプロセッサに、1つ以上の誤判定説明に対して疑わしい未知の事例のセット内の未知の事例の各々を分析することによって、疑わしい未知の事例のセットから、説明済みの未知の事例のセットを判断させてもよい。説明済みの未知の事例のセットは疑わしい未知の事例のセットのサブセットである。いくつかの実施形態においては、複数の命令は、コンピュータプロセッサに、疑わしい未知の事例のセットから説明済みの未知の事例のセットを差し引くことによって、未説明の未知の事例のセットを判断させてもよい。未説明の未知の事例のセットは、説明済みの未知の事例のセットとは重複しない疑わしい未知の事例のセットのサブセットである。
【図面の簡単な説明】
【0008】
【
図1】本開示の実施形態に従った、電力不正検出についてのシステム図である。
【
図2A】本開示の実施形態に従った、電力不正を検出することを目的としたアルゴリズムについてのブロック図である。
【
図2B】本開示の実施形態に従った、電力不正を検出することを目的としたアルゴリズムについてのブロック図である。
【
図3A】本開示の実施形態に従った、電力不正検出のために使用できる需要データの例を示す図である。
【
図3B】本開示の実施形態に従った、電力不正検出のために使用できる不正データの例を示す図である。
【
図4A】本開示の実施形態に従った、電力不正検出のために使用できる例示的な分布テーブルを示す図である。
【
図4B】本開示の実施形態に従った、電力不正検出のために使用できる例示的な分布プロットを示す図である。
【
図5】本開示の実施形態に従った、電力不正検出のために使用できる例示的な分布テーブルを示す図である。
【
図6A】本開示の実施形態に従った、顧客の例示的な需要プロフィールを示す図である。
【
図6B】本開示の実施形態に従った、顧客の需要を示す例示的なグラフである。
【
図7】本開示の実施形態に従った例示的な結果テーブルを示す図である。
【
図8A】本開示の実施形態に従った、不正事例において検出された低い中間需要を示す例示的なグラフである。
【
図8B】本開示の実施形態に従った、不正事例において検出された低い中間需要を示す例示的なグラフである。
【
図9A】本開示の実施形態に従った、不正事例において検出されたゼロの中間需要を示す例示的なグラフである。
【
図9B】本開示の実施形態に従った、不正事例において検出されたゼロの中間需要を示す例示的なグラフである。
【
図10】本開示の実施形態に従った、疑わしい挙動の正当な説明に対応する例示的なフィールド活性フラグを示す図である。
【
図11】本開示の実施形態に従った、電力不正検出を実現するためのブロック図である。
【
図12】本開示の実施形態に従った、電力不正検出のためのハイブリッドシステム図である。
【
図13】本開示の実施形態に従った、突然低下した後に低いままとどまっている需要についての例示的な挙動パターンを示す図である。
【
図14】本開示の実施形態に従った、緩やかに低下した後に低いままとどまっている需要についての例示的な挙動パターンを示す図である。
【
図15】本開示の実施形態に従った、長期間にわたって緩やかに低下している需要についての例示的な挙動パターンを示す図である。
【
図16】本開示の実施形態に従った、非常に少ない需要についての例示的な挙動パターンを示す図である。
【
図17】本開示の実施形態に従った、上昇すると予想されていた場合に上昇しない需要についての例示的な挙動パターンを示す図である。
【
図18】本開示の実施形態に従った、過度に異常に安定している需要についての例示的な挙動パターンを示す図である。
【
図19】実施形態のうちの1つを実現するための分散型システムを示す簡略図である。
【
図20】本開示の一実施形態に従った、実施形態のシステムのコンポーネントによって提供されるサービスがクラウドサービスとして提供され得るシステム環境のコンポーネントを示す簡略ブロック図である。
【
図21】本発明のさまざまな実施形態が実現され得る例示的なコンピュータシステムを示す図である。
【発明を実施するための形態】
【0009】
詳細な説明
以下の記載においては、本発明の実施形態の充分な理解を提供するために、説明の目的で、具体的な詳細が述べられる。しかしながら、さまざまな実施形態がこれらの具体的な詳細なしでも実施され得ることは明らかであるだろう。図および記載は限定的なものとして意図されたものではない。
【0010】
図のうちのいくつかに示されるシステムは、さまざまな構成で提供され得る。いくつかの実施形態においては、システムは、システムのうちの1つ以上のコンポーネントがクラウドコンピューティングシステムにおける1つ以上のネットワークにわたって分散されている分散型システムとして構成されてもよい。いくつかの実施形態においては、システムは、仮想環境または非仮想環境において動作するように構成されてもよい。
【0011】
序論
先に述べたように、電力会社の顧客の中には、しばしば、代金を支払うことなく電力を盗むことによって不正を働く顧客がいる。検出率が低いことおよび誤判定率が高いことが組合わさることで、電力会社が現存のシステムでこの不正を検出するのは困難になっていた。言いかえれば、システムは、不正を検出することができない上に、実際には如何なる不正も発生していないのに不正として検出してしまうことが数回ある。
【0012】
不正検出に適用される機械学習アルゴリズムを使用しても、さまざまな理由でこれらの欠点に対処できる可能性は低い。第1に、顧客の挙動を不正であるかまたは不正でないものとして分類するように構成された、教師あり学習(supervised learning)方法(たと
えば、分類:SVM)などの機械学習アルゴリズムは、将来の予測に適用するために過去の観察結果からパターンを記憶する傾向がある。残念ながら、実際の不正についての過去の観察結果のうち限られた数の観察結果が機械学習アルゴリズムに関するコールドスタート問題を引起こす。機械学習アルゴリズムから信頼性のある予測をもたらすための、不正事例についての十分なデータはない。アルゴリズムは、アルゴリズムをトレーニングするのに用いられる限られた数の事例と同様の事例しか検出することができないので、潜在的には、トレーニングセットにおいて最初に識別されなかった場合、アルゴリズムによって検出されない多くの不正事例が存在することとなるだろう。機械学習アルゴリズムは、過去に既に起こったことしか検出することができないので、検出できるものが限られている。検出率が低いという問題は解消されないままとなる可能性があるだろう。
【0013】
さらに、機械学習アルゴリズムは、因果推論の説明に関して制限されていることが多い。因果関係や、モデルの入力同士の関係を理解することはロバストなモデルを構築するのに役立ち得る。より複雑なモデル(たとえば、より多くの想定を行なうモデル)はより多くのリスクを伴うものであり、このようなリスクの増加は、ある程度の統計的に有意な性能の向上もたらして、複雑さとロバスト性との間の適切なバランスを確実にするはずである。
【0014】
加えて、電力不正を働く者は、しばしば、調査されている場合または調査されていると疑っている場合に、自身の挙動を変更する。したがって、過去のパターンに基づいて不正な挙動を識別するための機械学習アルゴリズムのトレーニングには欠陥がある。なぜなら、挙動のパターンが時間とともに変化する可能性があるからである。
【0015】
これらの欠点を回避するために、電力不正検出システムは、低検出率および高誤判定率の問題を関連付けて取扱うのではなく別個に取扱うという見地から設計することができる。言いかえれば、電力不正検出の問題は2つの別個の副次的問題に分割することができる。2つの別個の副次的問題は、順々に適用することができる2つの別個のモデルを用いて対処される。2つの別個のモデルのうち一方のモデルは、不正を高検出率で検出することを目的としており、他方のモデルは、最初のモデルによって生成された結果をフィルタリングするために誤判定を減らすことを目的としている。
【0016】
概念的には、不正な挙動を検出する副次的問題を第1に優先させてもよい。なぜなら、低い検出率のままでは、不正の多くの事例が識別されないままとなるからであり(「未知であることによる未知」(unknown unknowns))、これは、電力会社にとって大幅なコストの追加となる。このため、第1のモデル(たとえば、検出器モデル)は、不正行為のためのさまざまな検出器を用いて、不正な挙動を検出するために構成されてもよい。しかしながら、それまでに識別されていない不正の事例を検出するために、このようなモデルは、それまでに識別された不正のトレーニングセットを用いて構築される検出器を用いるべきではない(なぜなら、これら検出器は未識別の不正を把握していないからである)。いくつかの実施形態においては、このモデルの検出器は、観察された過去の不正の事例ではなく顧客の需要、または顧客の電力使用に直接基づいていてもよい。これらの検出器は、結果として企業の収益を減少させることとなる需要プロフィール内の疑わしい挙動のさまざまな形態を検出するように構成されてもよい。
【0017】
次いで、第1のモデルによって検出される事例に関連付けられた疑わしい挙動についての正当で不正のない説明を見出そうと試みることによって、誤判定を減らすことに焦点を置いた第2のモデル(たとえば、誤判定モデル)があり得る。この第2のモデルは、正当
に説明された疑わしい挙動をいずれも除外して、不正である可能性が高い事例を残しておくために用いられる。
【0018】
言い換えれば、企業に対して収益の損失をもたらすパターンが特定される「パイプライン」(たとえば検出器)があってもよい。このパターンは「異常な挙動」または単に「挙動」と略して称されてもよい。挙動の例を識別するために検索を行なうことができる。誤判定ルールエンジンは、誤判定を除外するためにこれらの検索結果に対して実行される。残っている事例(たとえば、誤判定として除外されない検索結果)は、不正である可能性がより高い事例である。このパイプラインは、(1)既知の不正事例のセット、および(2)未知であることによる未知のセット(他のすべてのセット)両方に対して適用することができる。
【0019】
パイプラインが(1)既知の不正事例のセットに適用される場合、得られる結果は、(A)検出器が検出した既知の不正事例の数;(B)検出器が検出しなかった既知の不正事例の数;(C)検出された挙動のセット内における、誤判定ルールエンジンでうまく説明された事例の数とともに、これらの事例がうまく説明された理由についての数値的内訳、および、(D)検出された挙動のセット内における、誤判定ルールエンジンでうまく説明されなかった事例の数、を含む。
【0020】
パイプラインが(2)未知であることによる未知のセットに適用される場合、得られる結果は、(A)検出器が挙動を検出した事例の数、(B)検出器がいずれの挙動も検出しなかった事例の数、(C)検出された挙動のセット内における、誤判定ルールエンジンでうまく説明された事例の数とともに、説明された理由についての数値的内訳、および、(D)検出された挙動のセット内における、誤判定ルールエンジンでうまく説明されなかった事例の数、を含む。
【0021】
(1)既知の不正事例のセットおよび(2)未知であることによる未知のセット(他のすべてのセット)の両方にパイプラインを適用して、それらの結果における情報を分析することにより、検出器が如何に十分に動作するかと、既存の検出器の品質とについての理解が得られる。これによっても、検出能力を高めるように構築される必要がある可能性のある追加の検出器の数が把握されることとなる。たとえば、1000の事例をサーチすることで、20の検出された挙動が識別され得るが、20の検出器が捕らえるように設計されていない残りの980個の事例において依然として他の挙動が存在している可能性がある。これにより、追加の検出器を構築する必要があることを通知することができる。
【0022】
さらに、(1)既知の不正事例のセットおよび(2)未知であることによる未知のセット(他のすべてのセット)の両方にパイプラインを適用することによっても、誤判定ルールエンジンがどのように動作するかと、誤判定の数を減らすように追加の誤判定ルールを構築する必要があるかどうかと、についての理解が得られる。このことは重要であるが、それは、多種多様なソースからの情報に基づいて構築することができる膨大な数のさまざまな誤判定ルールが存在し得るからである。
【0023】
たとえば、誤判定ルールは、「小規模なアパートのサイズ(small apartment size)」、「顧客、太陽エネルギの顧客である(is customer a solar customer)」などを識別するために内部データソースから取得することができ、誤判定ルールも、Facebook(登録商標)、Twitter(登録商標)、LinkedIn、Glassdoor、またはニュース媒体などの外部データソースによって判断することができる。たとえば、LinkedInプロファイルは、顧客Xが電力不正を犯すのに必須のエンジニアリング知識を有していることを示してもよく、このため、異常な挙動が検出されている場合、その知識を有するとは予想され得ない人に関して、挙動が不正である確率が高まる可能性がある。同様に、Twitterのフォロー、YouTube
(登録商標)(ユーチューブ)/Facebookのコメント、およびグループアソシエーションを監視することができるとともに、個人がどのようなトピックに関与(共有、リンクまたはコメント)しているかについての情報も取込むことができる。この技術は、さまざまなオープンソースツール(open source tool)およびAPIをまとめることにより、またはオラクルマーケティングクラウド(Oracle Marketing Cloud)などのソフトウェアを介して取得することができる。
【0024】
さらに、誤判定ルールを作成するために用いられるこれらのさまざまなデータソース(たとえば、内部ソース(内部顧客データ)および外部ソース(ソーシャルメディア))からのデータは、コミュニティおよび複雑な関係を自動的かつ迅速に識別するために、グラフデータベースに供給することができる。たとえば、グラフデータベースは、不正に関与した人々が「X、Y、Z」を好んでいたこと、および「A、B、C」について話していたことを通知し得る。次いで、グラフデータベースは、同様の特徴を有していたがまだ不正に関与していないすべての人を復帰させるだろう。このため、誤判定ルールエンジンは、グラフデータベースに起因する推論および知識を用いて構築することができる。グラフデータベースを同様に用いることで、世界中の警察が、重要な政治家および抗議グループの活動に対する反感を(たとえば、群衆整理、バリケードなどの計画を立てるために)追跡することが可能となるとともに、クレジットカード詐欺を検出することも可能となる。
【0025】
これは、需要プロフィールからのデータが、数学的空間および物理地理的空間の点で既知である不正行為者に対する関係/関係の程度を示すソーシャルメディアからのデータと組み合わされるように、誤判定ルールエンジンが個人専用の不正システムに進化することを可能にする。これらのデータポイントは、顧客プロフィールの360度の視界を構築する役割を果たすことができる。たとえば、グリーンエネルギに関するものに対する顧客の興味(またはその効果に対するソーシャルメディアの投稿)は、需要の突然の低下が、不正を犯そうとする意図ではなく、気分の変化および好みの変化(たとえば、顧客が環境保護のために環境に優しい生活を送ろうとすること)に起因していたことを示す直接的な指標になり得る。ソーシャルメディアに耳を傾ける方法がなければ、このデータは取込まれず、誤判定ルールエンジンによって考慮されないため、理にかなった需要の低下をうまく説明することができなかったであろう。
【0026】
したがって、この明細書中に記載される電力不正検出システムは、不正に対する反応ではなく、不正防止のパラダイムに基づき得るものであって、最初に発生する不正の防止を可能にする。目標設定されたメーリングキャンペーンを受けることによって、または、不正を検出することができる会社を強調表示させるテキストメッセージによって、単純に、まだ不正に関与していないがグラフデータベースによって識別された人が不正に関与するのを断念させてもよくまたは思い留まらせてもよい。言いかえれば、不正に関与する可能性のある人を予測モデルが識別すると、いくつかのタイプのアウトリーチキャンペーンを用いてイベントが発生するのを防止することができる。これらのキャンペーンの成功は、単に、アウトリーチ処理を受取ったものの結局不正を犯してしまった人を監視することによって追跡することができる。このようなアウトリーチキャンペーンの目的は、いくつかのタイプの挙動修正を実行する(たとえば、誰かが何かを行なうことを防止する(不正を実行させない))ことである。これは、マーケティングにおける(顧客が購入する際に一連の段階(認識、意図および最終的に購入する決定)を経験する)「変換ファネル(conversion funnel)」に観念論的に類似している。同時に、本願における反応型の電力不正
検出システムは、「変換ファネル」におけるすべての段階を経験し、「変換」に到達した顧客、たとえば実際に不正に関与した顧客、の識別に対処するだろう。
【0027】
こうして、予防的プレ不正型のシステムは、変換ファネルに達したもののまだ変換していない(たとえば、不正が行なわれていない)すべての人を識別してこれに対処するだろ
う。さらに、反応型の不正検出システムは、変換後であるすべての人(たとえば、不正を犯した人々)に対処するだろう。これらのシステムをともに組合わせて、不正防止および不正に対する対応の分野における真の合同軍アプローチを構築してもよい。このため、顧客が変換ファネルに到達しているにもかかわらず、これらに対処するために数学的に具体的/厳密な方法が存在するだろう。
【0028】
電力不正検出システムにおいて用いられる検出器に関して、検出器は、設計によって誤判定ルールエンジンから意図的に切り離されている。なぜなら、誤判定ルールエンジンは、複数の検出器に適用可能であり得るかまたは1つの検出器のみに特有のものであり得るからである。検出器および誤判定ルールエンジンのこれらの組合せの数値的精度は、出力を格納することによって実証することができる。これにより、検出器および誤判定ルールエンジンを連続的に改良することが可能となる。さらに、このフレームワークは、原因解析を迅速かつ効率的に実行することを可能にする。検出器がその結論にどのように達したか(検出器が事前に規定されている)かまたは誤判定を引起こしたものが何であるか(誤判定ルールエンジンに含まれていなかったルールである)についての推測作業はない。このため、いずれの検出器/誤判定ルールエンジンにおける如何なる欠陥も、迅速に識別して修正することができる。
【0029】
検出器および誤判定ルールは、人の専門家、AIまたはこれら両方によって構築されてもよい。たとえば、自動誤判定ルールは機械学習関連付けルール/教師なし学習(unsupervised learning)を適用することによって構築されてもよい。別のアプローチにおいて
は、誤判定は、ソーシャルメディアおよび内部データを活用するためにグラフの上述のトラバース測量を用いて識別されてもよい。これらの2つの別個のアプローチは、さらに、人の専門家が認識しているが機械学習アルゴリズムによって実現される誤判定ルールで(たとえば、データに取込まれていない業務知識に依拠する推論を用いて)、単一の2方面からなるアプローチに組合わせることもできる。このエコシステム性能監視フレームワークは、ユーザが、機能しているものに影響を及ぼすことなく機能していないものを交換することを可能にすることによって電力不正検出システムを絶えず向上させることを可能にするとともに、一定のパラメータが最初に十分に作業を実行し得るのかについての理由をユーザが十分に理解することを可能にする。
【0030】
例示的な実施形態
図1は、本開示の実施形態に従った、電力不正についてのシステム図である。
【0031】
いくつかの実施形態においては、電力会社の顧客などの、自身の住居に電力が送達される1人以上の顧客102-1から102-nが存在し得る。各々の顧客が電力を用いると、彼らの電力使用量がそれぞれのメータ104-1から104-nで測定され得る。いくつかの実施形態においては、これらのメータは、特有の識別子(たとえば、サービスポイントid)に関連付けられてもよく、各々の顧客の住居/不動産が1つのメータに関連付けられてもよい。したがって、あるメータについての特有の識別子が、関連付けられた顧客を識別するために用いられてもよい。
【0032】
メータ104-1から104-nは、数ある情報の中でも特に、電力使用統計を電力不正検出(electricity fraud detection:EFD)システム110に報告し得る。さまざ
まな顧客102-1から102-nについての電力使用量が需要データベース112に格納されてもよい。いくつかの実施形態においては、代価を支払わずに電力を盗む顧客などの、それまでに観察された不正行為の事例に関連付けられたデータ項目を含む、観察された不正データベース114があってもよい。いくつかの実施形態においては、これらの観察された不正の事例は、フィードバックを行なって電力不正検出システム110の結果を実証するのを支援するために用いられてもよい。
【0033】
いくつかの実施形態においては、電力不正検出システム110は、1以上の顧客102-1から102-nの不正行為を検出することができるかもしれない。これは、この明細書中に記載されるように、顧客102-1から102-nの各々の、彼らの電力使用量に基づいた挙動プロフィールの判断を含むさまざまな方法によって行うことができる。いくつかの実施形態においては、電力不正検出システム110が1以上の顧客102-1から102-nによって実行されている不正行為を識別するかまたは検出すると、電力不正検出システム110はコンピューティングデバイス120を介して調査員122に通知し得る。次いで、調査員122は、不正が発生していることを実証するために顧客によって実行されているいずれの不正行為をも調査し得る。
【0034】
図2Aは、本開示の実施形態に従った、電力不正を検出することを目的としたアルゴリズムについてのブロック図を示す。
図2Bはまた、本開示の実施形態に従った、電力不正を検出することを目的としたアルゴリズムについてのブロック図を示す。
図2Aおよび
図2Bは一緒に記載されている。
【0035】
ブロック202において、顧客についての需要データおよび不正データを含むデータセット(たとえば、
図3Aおよび
図3Bに示されるデータテーブルの組合せ)は、既知の事例のセット(それまでに観察された実際の不正)およびそれらの既知の事例についての対応するデータ項目(たとえば、その不正を犯した顧客についての需要データ)を判断するために用いられてもよい。そのデータセットはまた、未知の事例のセットと、それらの未知の事例についての対応するデータ項目(たとえば、それまでに観察された実際の不正に関与していない顧客についてのすべてのデータ項目)とを判断するために用いられてもよい。より具体的な例として、すべての事例220のデータセットは、既知の事例222のデータセットと未知の事例224のデータセットとに分割することができる。既知の事例のセットは、電力不正検出システムにおいて用いられる複数モデルのうちの1つまたは両方の精度を検証するのに有用であり得る。
【0036】
ブロック204において、挙動のセットは、不正検出率を向上させるために疑わしい挙動を過度に包括するように設計されている、疑わしい挙動を検出するための第1のモデルにおいて検出器(たとえば、検出器226)として特定されている。上述したように、検出器は、各々の顧客毎に、時間の経過に応じて電力使用量に関連付けられている需要プロフィールまたはメトリクスに関連付けられた挙動に基づいていてもよい。これらの需要プロフィールは、
図1に示されるメータ104-1から104-nによってすべての顧客について集めることができる需要データに基づいて計算することができる。たとえば、1年の間にわたる顧客の毎日の電力需要は、その期間にわたる最大需要、最小需要および中間需要を計算するために用いることができる。これらのメトリクスは、その期間にわたる顧客の需要プロフィールの一部と見なすことができる。需要プロフィールは、
図2A、
図2Bおよび
図6に関連付けてより詳細に記載されている。需要プロフィールに関連付けられたグラフの例が
図8A、
図8B、
図9Aおよび
図9Bに示される。
【0037】
検出器は、収益の低下をもたらす可能性のある、需要プロフィールに関連付けられた予め規定された挙動パターンと見なすことができる。第1のモデルは複数の検出器で構成されてもよく、したがって、これらの予め規定されたパターンのセットにおける如何なるパターンにも該当する如何なる顧客需要プロフィールをも識別することができるだろう。検出器の一例は、さまざまな方法で規定することができる顧客の需要プロフィールについての低い中間需要であるだろう。たとえば、常に0である中間需要として規定されてもよく、常に0である最大需要として規定されてもよく、0である中間需要であるがゼロよりも大きい最大需要として規定されてもよく、すべての顧客についての中間需要のうち最下位から10パーセンタイル内である中間需要として規定されてもよい(たとえば、顧客の母
集団の少なくとも90%がより大きな需要を有していた)、等である。パーセンタイルに基づいた検出器の実現例が、
図4A、
図4Bおよび
図5に関連付けてさらに詳細に記載されている。なお、顧客の毎日の需要が外れ値を有し得る非常に変動し易い(たとえば、日常的に大幅に変化する)プロセスであり得るので、歪みの潜在的な問題を回避するのに中間値が有用であり得ることに留意されたい。このため、付加的な検出器を容易にモデルに追加することができ、これは、ロバストであるとともに厳格な「エコシステム」と称することができる。なぜなら、これは、需要プロフィールに関連付けられた特有の挙動に焦点を合わせた、高度に特化された多数の独立した検出器を含み得るからである。さらに、この態様で検出器を使用することにより、過去の挙動(たとえば、それまでに観察された不正)のパターンに依存することが回避されるとともに、トレーニングが不要となる。検出器のトレーニングが不要となり、検出器が挙動に焦点を合わせるので、同じ検出器を用いて、産業上の不正だけでなく住居での不正も同様に(いずれの事例にも特有のパターンが適用されないので)検出することができる。
【0038】
いくつかの実施形態においては、検出器に組込むことができる潜在的な疑わしい挙動パターンの他の例は、
(1)突然低下した後に低いままとどまる需要(
図13に図示)、
(2)緩やかに低下した後に低いままとどまる需要(
図14に図示)、
(3)長期間にわたって緩やかに低下する需要(
図15に図示)、
(4)非常に低い需要(
図16に図示)、
(5)上昇すると予想されていた場合に上昇しない需要(
図17に図示)、
(6)あまりにも異常に安定している需要(
図18に図示)、を含む。
【0039】
なお、
図13~
図18およびそれらの対応する記載ならびに特に
図16において、低い需要または非常に低い需要が所与の時点において対象となっている母集団のECDFからの分布によって規定することができるに留意されたい。たとえば、
図16においては、対象となっている母集団のECDFは、(たとえば、中間需要を含む)需要分布を取得するために用いられる。低い需要は、需要についての任意に選択されたしきい値(たとえば、10kwh)ではなく、その分布の左下側末尾(たとえば、複数分布のうちの1つの分布)として規定されるだろう。低い需要としてみなされる正確な量の需要は、時間およびその時間での母集団挙動に依存することとなる。たとえば、低い需要は、母集団にわたる典型的な需要に応じて10kwhであってもよく、または100kwhであってもよい。
図13~
図18は、挙動パターンに分類することができる顧客需要プロフィールを視覚化したものである。それらの視覚化されたデータは、中間値、最大値、最小値などの時間依存メトリクスを用いて定量化することができる。これらは、他のすべての人によって示されるメトリクスに対して相対的に、或る時間にわたってこれらのタイプのパターンを検出するための挙動検出器への入力になるだろう。
【0040】
ブロック206において、第1のモデルの検出器は、疑わしい挙動を伴った既知の事例を判断することによって、既知の事例(たとえば、それまでに観察された不正事例)のセットに対して検証される。たとえば、1年の期間中に38事例の不正がある場合、それらの38の不正事例に関与する各顧客についての需要プロフィールを生成することができるとともに、第1のモデルの検出器をそれらの需要プロフィールに適用することができる。より具体的な例として、第1のモデルが低い中間需要に基づいた検出器のセットを含むとすると(たとえば、中間需要が0であり、最大需要が0であり、中間需要が0であるが最大需要がゼロよりも大きく、中間需要がすべての顧客についての中間需要の最下位から10パーセンタイル内である)、38の需要プロフィールのうち15の需要プロフィールが、第1のモデルによって疑わしいものとして識別される。これは、検出器のこの限られたセットが既知の不正事例の約40%を把握したことを意味している。この精度は、付加的な独立した検出器をモデルに追加することによってさらに向上させることができる。
【0041】
ブロック208において、疑わしい挙動を伴った未知の事例を判断するために、第1のモデルの検出器が未知の事例(たとえば、既知の不正事例のセットに存在しない他のすべての顧客;顧客の大部分を表わす多くの事例があり得る)に適用されてもよい。これは、疑わしい挙動に関するフラグが立っているのがどの需要プロフィールであるのかを確かめるために、各々の顧客についての需要プロフィールを判断して、需要プロフィールの各々に対抗して検出器のセットを適用することを含み得る。たとえば、未知の事例を表わす400000を越える顧客に対応するデータから、34000を越える疑わしい挙動の事例が識別され得る。これらの事例はそれまでに既知となり実証された不正事例のセットから相互に排他的となるだろう。さらに、比較的多数のこれらの事例は、従来の方法を用いても検出されなかった不正(これらの疑わしい事例のごく一部だけが不正であったとしても)が行なわれる可能性が最も高いことを示唆している。
【0042】
このため、
図2Bから分かるように、複数の検出器226は、既知の事例222および未知の事例224の両方に別個に適用することができる。複数の検出器226は、疑わしい挙動を伴った既知の事例228を判断するために、モデルを検証する目的で既知の事例222に適用することができる。言いかえれば、既知の事例222は、複数の検出器226が既知の事例222の大部分またはすべてを疑わしい挙動であると正確に識別しているかどうかをチェックするために用いることができる。複数の検出器226はまた、顧客アカウントまたは疑わしい挙動に関連付けられた未知の事例230を識別するために使用して未知の事例224に適用することができる。
【0043】
ブロック210において、疑わしい挙動についての正当な説明が、代替的には誤判定ルールエンジンと称され得る第2のモデルにおいて特定され得る。疑わしい挙動を疑わしいものとして除外するために、なぜそれら疑わしい挙動が行なわれたかについての正当な説明を用いることによって、電力不正検出の誤判定率が高くなるという問題を解決することが、第2のモデルのジョブである。疑わしい挙動について考えられ得る正当な説明は以下のとおりである。具体的には、(1)顧客が、需要の低下した太陽電池パネルのユーザであった;(2)機器の故障があった;(3)嵐が発生した;(4)嵐ではなくグリッド過負荷があった;(5)電気事業が、電力会社によってもしくはユーザの要求によって停止された;(6)顧客の需要についての嗜好および好みに変化があった;(7)住居の母集団に変化があった;(8)販売促進キャンペーンもしくは支払請求周期の変更があった;または、(9)顧客がピーク時間中にお金を節約するために発電機を用いた。
【0044】
ブロック212において、未知の事例のいずれかをブロック210において特定された正当な説明のいずれかを用いて説明することができるかどうかを確かめるために、第2のモデルが疑わしい挙動を伴った未知の事例に適用され得る。サービスポイントに関する疑わしい挙動についての考えられ得る正当な説明を見出すことができない場合、そのサービスポイントは潜在的な不正行為の候補になる可能性がある。場合によっては、誤判定の説明232は、疑わしい挙動を伴った既知の事例228および疑わしい挙動を伴った未知の事例230の両方に適用することができる。これにより、結果として、未説明の疑わしい挙動を伴った既知の事例234のセット(実際の実証された不正を正当な挙動であると誤って判断したときに第2のモデルを検証するためにさらに用いることができる)と、さらなる調査のための未説明の疑わしい挙動を伴った未知の事例236のセットとが得られるだろう。したがって、ブロック214において、(ブロック208において判断された)疑わしい挙動を伴った未知の事例の合計リストから、それらの疑わしい挙動についての正当な説明を含むものと識別された未知の事例を差し引くことができる。残りの未知の事例は、如何なる正当な説明によっても説明することができず、このため、不正である可能性が極めて高い、疑わしい挙動を伴った事例である。ブロック216において、不正を実証するために、未説明の疑わしい挙動を伴った残りの未知の事例をいずれをもさらに調査す
ることができる。場合によっては、これは、電力不正検出システム110にコンピューティングデバイス120への通知の送信を実行させて、調査員122にどのサービスポイントまで出向いて調査するべきかを通知すること等によって、不正が行なわれていることを確認するために調査員に出向くように通知することを必要とするかもしれない。
【0045】
図3Aは、本開示の実施形態に従った、電力不正検出のために使用できる需要データの例を示す。
図3Bは、本開示の実施形態に従った、電力不正検出のために使用できる不正データの例を示す。
【0046】
上記図はともに、データテーブルの実際の見た目となり得るもののうち限られた部分だけを示している。実際には、データテーブルは、何十万または何百万ものエントリーを含んでいてもよい。データテーブルのサイズは、顧客の数が増えてそれらの毎日の需要がさらにより長い期間にわたって追跡されるのに応じて、幾何学的に増加し得る。場合によっては、データの合計サイズが、ギガバイトまたはテラバイトのデータを上回る可能性もあり、暗算するかまたは紙とペンとを用いて計算するために、人がデータをすべて利用することが不可能になるだろう。このため、本開示のシステムおよび方法は、従来の方法を用いて識別することができないであろう潜在的な不正の多数の事例を識別するために、膨大な量のデータについてのデータ駆動型分析を可能にする。
【0047】
上記図はともに値を指数表現で示している。これは、例示のみを目的としたものであって、実際には、データテーブルは如何なるタイプのフォーマットで値を格納していてもよい。いくつかの実施形態においては、データテーブルにおけるデータの処理は、データを読出してデータをクリーンにすることを含み得る。データをクリーンにすることは、値を指数表現で表示されるように変換するか、または、サービス日付を月/日/年のフォーマットに変換するなどの、値を異なるフォーマットに変換することを含み得る。
【0048】
図3Aに関して、この図は、複数の電気事業顧客に関連付けられた需要データを含むデータテーブルを未処理の状態で示している。いくつかの実施形態においては、1人の顧客によって毎日用いられる電力需要が既知となるように、各々の顧客ごとに毎日の需要データが存在してもよい。いくつかの実施形態においては、データテーブルは、欄302、欄304、欄306、欄308、欄310、欄312、欄314および欄316などの欄によって分類されるデータ項目の行を含んでもよい。図に示されない電気事業顧客に関する他のデータも、データテーブルに含まれていてもよい。
【0049】
いくつかの実施形態においては、(「sp_id」という見出しで示される)欄302は、サービスポイントの別個の識別番号に対応するサービスポイントidであってもよい。サービスポイントは特定の顧客についての電力メータであってもよい。したがって、サービスポイントidは特定の顧客を識別するために用いられてもよい。たとえば、400000の顧客を含むデータテーブルにおいては、400000の固有のサービスポイントidがあり得る。しかしながら、各々の顧客が追跡された各サービス日付についてのデータの行を有し得るので、400000を超える行がデータテーブルに存在し得ることに留意されたい。たとえば、100のサービス日付についてのデータを有していた顧客は、データテーブルにおける100の行のデータ(これらすべてがその顧客のサービスポイントidを有している)に関連付けられるだろう。さらに、顧客が電力サービスを受取る複数のアドレスを有している場合、その顧客に帰属する複数のサービスポイントが存在し得るだろう。これは有用である。なぜなら、1つの不動産に関して不正を犯している複数のアドレスを有する或る顧客が、それらの他の不動産に関して不正を犯している可能性が非常に高いからである。
【0050】
いくつかの実施形態においては、(「需要」という見出しで示される)欄304は、特
定のサービス日付についての顧客の需要または電力使用量であり得る。この需要は、如何なる好適な単位またはメトリックでも測定することができる。このような実施形態のうちのいくつかにおいては、この需要はキロワット時(kWh)で測定されてもよい。たとえば、データの行における「4.1」という需要値は、その行についての特定の顧客が(欄306において示された)その特定のサービス日付に4.1kWhを用いたことを表わし得る。したがって、データテーブルにおいて示される需要値は、毎日の使用量に対応していてもよい。しかしながら、他の実施形態においては、需要値は必ずしも日毎の分解能を有するわけではない。たとえば、需要値は、時間毎、分毎、週毎などの単位で追跡することができる。
【0051】
いくつかの実施形態においては、(「service_date」という見出しで示される)欄306は、日・月・年フォーマットのサービス日付であってもよい。たとえば、「01032017」の値は2017年1月3日に対応し得る。しかしながら、年/月/日フォーマット、月/日/年フォーマットなどを含むがこれらに限定されない特定のサービス日付に言及するために、他の如何なる好適なフォーマットが用いられてもよい。上述の例においては、「4.1」の需要値および「01032017」のサービス日付を有するデータの行は、その行のサービスポイントidに関連付けられた顧客が2017年1月3日に4.1kWhを利用したことを示すだろう。
【0052】
いくつかの実施形態においては、サービス日付はさらに、構文解析されてもよく、または、特定の四半期、月、週の数、およびその週の特定の日に分解されてもよい。たとえば、データクリーニングプロセス中に、サービス日付の年を決定して、(「yr」という見出しで示される)欄308において表示することができる。サービス日付の四半期を決定して、(見出し「qt」で示される)欄310において表示することができる。サービス日付の月を決定して、(「mn」という見出しで示される)欄312において表示することができる。サービス日付の週の数を決定して、(「wd」という見出しで示される)欄314において表示することができる。サービス日付の週の日を決定して、(「日」という見出しで示される)欄316において表示することができる。たとえば、サービス日付が日曜日(Sunday)である場合、欄316における値は「1」になり得るか、または、サービス日付が土曜日(Saturday)である場合、欄316における値は「7」になり得る。
【0053】
図3Bに関して、この図は、複数の電気事業顧客に関連付けられた不正データを含むデータテーブルを未処理の状態で示す。いくつかの実施形態においては、データテーブルは、欄320、欄322および欄324などの欄によって分類されるデータ項目の行を含んでいてもよい。したがって、このデータテーブルにおけるデータの各行は、不正(たとえば電力窃盗)の事例に関係し得る。図に示されない不正の発生率に関する他のデータも、データテーブルに含まれていてもよい。
【0054】
いくつかの実施形態においては、(「fraud_date」という見出しで示される)欄320は、不正の発生が検出されたサービス日付であってもよい。いくつかの実施形態においては、欄320における値のフォーマットは、欄306において示されるサービス日付の値(たとえば日・月・年フォーマット)と同じフォーマットであってもよい。たとえば、「01032017」の値は、データ行に示される特定の顧客について不正が検出されたサービス日付としての2017年1月3日に対応していてもよい。しかしながら、上述したように、他の如何なる好適なフォーマットが特定のサービス日付に言及するために用いられてもよい。
【0055】
いくつかの実施形態においては、(「合計」という見出しで示される)欄322は不正に関連付けられた合計のドル金額であってもよい。言いかえれば、欄322は、盗まれた電力量に基づいて、不正のせいで電力会社にどれだけの費用がかかったかを示していても
よい。
【0056】
いくつかの実施形態においては、(「sp_id」という見出しで示される)欄324は、不正が検出されたサービスポイントのサービスポイントidであってもよい。言いかえれば、このサービスポイントidは特定の顧客に対応していてもよい。欄324におけるこれらの値は、不正データ(たとえば
図3Bのテーブル)を、サービスポイントid(たとえば欄302)をも有する顧客の需要データ(たとえば
図3Aのテーブル)と結びつけるために用いられてもよい。たとえば、(検出された不正の発生に対応する)
図3Bのデータテーブルにおけるデータの行に関して、サービスポイントid(たとえば「1234567」)が示されている。そのサービスポイントidは、任意の利用可能なサービス日付について、そのサービスポイントidに関する日毎の需要データをすべて見出すために、対応する需要データ(たとえば、
図3A)において検索することができる。このクエリは、たとえば、そのサービスポイントidについての2015年における日毎の需要データを見出すためにさらに範囲を狭められてもよく、その基準に適合した365行もの需要データが存在するだろう。
【0057】
図4Aは、本開示の実施形態に従った、電力不正検出のために使用できる例示的な分布テーブルを示す。
【0058】
上述したように、顧客需要プロフィールから疑わしい挙動を識別するために、さまざまな検出器を用いることができる。上述の検出器の一例は、期間にわたる顧客についての中間需要がすべての顧客にわたる中間需要の最下位から10パーセンタイル内である挙動パターンを含んでいた(たとえば、顧客の母集団のうち少なくとも90%がより大きな中間需要を有していた)。静的な値ではなく分位数を用いて検出器を規定することに伴う利点がいくつか存在し得る。たとえば、10パーセンタイル、中間値、90パーセンタイルなどに関連付けられた値が時間とともに変化する可能性がある。顧客の母集団全体は、冬季の数か月(暖房用)または夏季の数か月(冷房用)などの間にわたって追加の電力を用いてもよい。このため、母集団レベルでの需要についての季節性および傾向が存在するかもしれない。10kWhの中間需要を有する顧客は、母集団における他の顧客の需要の変化に応じて、低需要または高需要と見なされてもよい。しかしながら、任意の分布のうちの10パーセンタイルは、その数学的定義(たとえば、時間のうち10%未満で発生する)に鑑みればまれなイベントであるかもしれない。したがって、総需要が母集団レベルにおいてどのように変化するかにかかわらず、母集団需要の10パーセンタイル未満の需要を呈する顧客は常に低需要を有するものとして見なされるだろう。なぜなら、母集団のうち90%がより大きな需要を有しているからである。
【0059】
言いかえれば、「10kWh」のしきい値を有する検出器を規定することにより、特定の顧客が有する需要が、日付に応じたしきい値未満であるか、季節に応じたしきい値未満であるか、または特定された期間に応じたしきい値未満であるかについて影響を及ぼす可能性がある。代替的には、パーセンタイルに基づいた検出器の使用は、顧客の需要プロフィールが必然的に他のすべての顧客の需要プロフィールと比較されることを意味しており、各々の顧客の挙動は、すべての人と比べて低い需要であるかまたはまれであると判断され得る。たとえば、すべての人の使用量が増加していたが、需要が増加しておらずそのアカウントがオフにされていなかった特定の顧客が1人いた場合、報告されたすべての人の電力使用量をフラットにするレギュレータを備えることにより、この特定の顧客が電力を盗むことが可能になるだろう。
【0060】
上述の例においては、10パーセンタイルは、どのような挙動が母集団においてまれであると見なされ得るかについてのしきい値として選択された。しかしながら、他のいずれのしきい値が用いられてもよい(たとえば、15パーセンタイルを下回る中間需要は低い
と見なされてもよい)。しきい値が低ければ低いほど、挙動は母集団においてよりまれなものとして示され得る。たとえば、10パーセンタイルを下回る中間需要を有する顧客よりも5パーセンタイルを下回る中間需要を有する顧客の方が少ない可能性があり、かつ、5パーセンタイルを下回る中間需要を有する顧客は不正を犯す可能性がより高くなり得る。しかしながら、しきい値をあまりに低く設定すると、結果として、そのしきい値内の挙動を伴う顧客をほんのわずかしか(または全く)見出せない可能性がある。たとえば、しきい値が1パーセンタイルと設定される場合、1パーセンタイル未満の中間需要を有する顧客がゼロになる可能性がある。しきい値を10パーセンタイルなどとより高く設定することで、モデルによって識別される顧客が十分に存在することが確実にされる。これにより、しきい値の設定に関してはトレードオフが得られる可能性がある。トレードオフは、潜在的に不正を行なう可能性のあるより少数の顧客を識別する(および、潜在的には極少数の顧客しか識別されない)こと、または、誤判定率の上昇を犠牲にして潜在的に不正を行なう可能性のより高い顧客を識別することとの間でなされる。
【0061】
いくつかの実施形態においては、自動的にしきい値を設定して、これらのさまざまな問題点のバランスを取るように構成されたアルゴリズムが存在し得る。いくつかの実施形態においては、アルゴリズムは、検出器を用いて疑わしい挙動を有するものとして識別されるように最小数の顧客に基づいてしきい値を設定するように構成されてもよい。言いかえれば、アルゴリズムは、疑わしい挙動を伴う最小数の顧客が選択され得るようにパーセンタイルを選択してもよい。たとえば、しきい値を下回る中間需要に基づいて疑わしい挙動を有するものと識別される最小限の20の顧客が存在するはずであることが規定され得る。顧客の母集団全体についての需要プロフィールの分布に基づいて、アルゴリズムは、少なくとも20の顧客がしきい値を下回る中間需要で識別されるように、当該しきい値を設定することができる。これは不正を調査する観点から有用になり得る。なぜなら、識別された潜在的に不正な顧客のうち何人を調査することができるかについては限界があるかもしれないからである。たとえば、
図1における調査員122は、12の顧客を訪問することができるリソースだけを有しているかもしれない。疑わしい挙動を伴う20の顧客を識別するためのしきい値を設定するようにアルゴリズムを構成した結果、未説明の疑わしい挙動を伴った顧客のリストがさらにより小さなものになる可能性がある(たとえば、識別された顧客のうち8の顧客が太陽エネルギのユーザである場合、未説明の疑わしい挙動を伴う12の顧客が残ることとなるだろう)。しかしながら、未説明の疑わしい挙動を伴う顧客のこのより小さなリストはすべて、場合によっては調査員122によって調査され得る。このため、当該アルゴリズムは、調査員122のリソースまたは稼働率に従って、疑わしい挙動を伴う識別された顧客の数と、未説明の疑わしい挙動を伴う識別された顧客の数とを調整するために用いることができる。
【0062】
なお、パーセンタイルを用いて規定される検出器を実現するために、顧客需要プロフィールの分布が、顧客の挙動を他の人すべてに対してランク付けすることを可能にするように決定されなければならないことに留意されたい。これは、或るセットにおける顧客のすべての需要プロフィールについての分位数分布および経験的累積分布関数(empirical cumulative distribution function:ECDF)を計算してプロット化することによって行うことができる。
【0063】
たとえば、
図4Aに関して、(分位数分布を示す)分布テーブルは、或る期間における(たとえば1年の間にわたる)38の不正な顧客のセットにおける各顧客の中間需要について示されている。図に示される分布テーブルは、各々の顧客についての中間要求(または需要プロフィールの他の任意のアスペクト)がどのようにさまざまなパーセンタイル範囲にバケット分割され得るかを示している。
【0064】
それらの38の不正事例についての対応するデータは、
図3Bに示されるのと同様のデ
ータテーブルに格納されるだろう。それらの38の不正事例についてのサービスポイントidは、その年にわたってそれらのサービスポイントに関連付けられた需要データ(たとえば、2015年における需要データ)を照会するために用いることができる。このため、2015年の日毎の日々の要求が、それらの38のサービスポイントidごとに識別されるだろう。各々のサービスポイントidごとに、そのサービスポイントidに関連付けられた挙動プロフィールを計算するためにその期間にわたる日毎の需要をさらに用いることができる。たとえば、各サービスポイントidは、アカウントがアクティブであった日数、当該期間にわたる中間要求、当該期間わたる最大需要、当該期間にわたる最小需要などに関連付けられるだろう。言いかえれば、「1234567」のサービスポイントidに関して、アカウントが500日間アクティブであったこと、その1年にわたって4kWhの中間需要があったこと、その1年にわたって0kWhの最小需要があったこと、およびその1年にわたって20kWhの最大需要があったことが判断され得る。
【0065】
図4Aを参照すると、不正事例は、それらの需要プロフィールのメトリックに基づいて分類して順序付けることができる。たとえば、38の不正事例はすべて、対応する38のサービスポイントidの各々に関連付けられた中間需要に基づいて、小さいものから大きいものへと順序付けることができる。最小需要または最大需要などの如何なるメトリックが用いられてもよいが、図は例示を目的として中間需要に基づいている。不正事例のすべてに対応する中間需要が分布を構成しており、これを用いて、各々の不正事例についての中間需要が分布のどこに位置しているかに基づいて、不正事例をさまざまなバケットに配置することができる。次いで、不正事例をさまざまなバケット内に配置した結果が、欄402、欄404および欄406によって分類された多数の行を有するものとして示される
図4Aに示されるデータテーブルにおいて報告されている。
【0066】
いくつかの実施形態においては、(「分位数」という見出しで示される)欄402が、場合によっては分布についての分位数であり得る、分布についての或るバケットを示すために用いられてもよい。たとえば、データテーブルの行「a」は、欄402の下の「0」の値を有しており、データテーブルのおよび行「b」は欄402の下の「1」の値を有している。このため、データテーブルの行「b」は、中間需要の「0」と「1」の分位数との間の中間需要を有する不正事例に関係している可能性がある。欄402の下の「100」の値を有する最後の行は、中間需要の「75」(先の行の値)の分位数と「100」の分位数との間の中間需要を有する不正事例の数を示すだろう。
【0067】
いくつかの実施形態においては、(「med_demand」という見出しで示される)欄404は、特定の分位数に関連付けられた中間需要を示していてもよい。たとえば、データテーブルの行「f」は、欄404の下の0の値を有しており、これは、不正事例の中間需要が20パーセンタイルのバケットにおいてゼロであることを示すだろう。上述のように、挙動プロフィールのうちの好適なメトリックをいずれも、最小需要、最大需要などを含め、中間需要の代わりに用いることができる。
【0068】
いくつかの実施形態においては、(「数」という見出しで示される)欄406は、テーブルの行によって示されるバケットに存在する観察結果の数を示していてもよい。このため、例示的なデータテーブルにおいては、ゼロであると判断される中間需要の20パーセンタイルのバケット内において19の観察結果が存在する。不正についての38の観察結果のうちの9つは、34.5145の値を有すると判断される、中間需要の75パーセンタイルのバケットの範囲内にある。
【0069】
図4Bは、本開示の実施形態に従った、電力不正検出のために使用できる例示的な分布プロットを示す。より具体的には、図は、
図4Aからの38の不正な顧客についての中間需要に対応する経験的累積分布関数(ECDF)の例示的なプロットを示す。
図4BのE
CDFおよび
図4Aの分布テーブルはともに、0%から100%の範囲にわたっており、100%は観察結果のすべてを示している。
【0070】
図4BのECDFは、不正事例についての累積分布関数を自動的に計算することに基づいており、各データポイント(たとえば、顧客についての中間需要)がどのように他のすべてのデータポイントと比べて低下するか(たとえば、その中間需要が如何に他のすべての観察結果からの中間需要に匹敵しているか)を表わしている。これは観察結果をランク付けするのに有用である。なお、各々の顧客の分布が時間とともに変化しており、需要が季節的なものであり、これは冬季、夏季などにおいて変化し得ることを意味していることに留意されたい。
【0071】
このため、ECDFでは、顧客の需要プロフィールを、1回の表示で、母集団の残りの需要プロフィールに対して比較することができる。上述したように、これは、まれなイベントの定義が時間とともに変化する可能性がある(たとえば、夏季におけるまれなイベントが冬季においては通常のイベントになり得るとともに、この逆の場合もまた同様に可能である)ので、有用である。これに比べて、機械学習アルゴリズムはこれらの変化を考慮に入れることができないだろう。なぜなら、機械学習アルゴリズムは、過去のパターンを将来に向けて予測するために記憶することしかできないからである。さらに、人々は、監視されると自身の挙動を変更し、結果として、機械学習アルゴリズムが説明することができない分布の変化がもたらされることとなる。
【0072】
ECDFはまた、顧客の電力使用量の特徴をランク付けするのに有用である。ECDFから、顧客の需要プロフィールが互いに対してどのようなランクに位置しているかと、それらの分布が時間とともにどのように変化するかとを判断することができる。顧客需要プロフィールのさまざまなメトリクスについてのECDFの変化は、たとえば、顧客母集団全体の挙動が12月から1月の間にどのように変化したか確かめるために閲覧することができる。顧客の母集団全体の挙動を追跡し、母集団の典型的な挙動と対照させて各々の顧客の挙動を考慮することにより、不正の検出を増やすことが可能となり得る。これは、不正の実行を可能にするさまざまな方法があることに起因している。すべての不正事例が、報告される使用量がゼロとなるように顧客が電力使用の計測を避けるかまたは停止させるというシナリオを含んでいるとは限らない。むしろ、顧客は、報告される需要の減少を防止するためにレギュレータを用いてもよいが、顧客は、実際には、報告されるよりも多くの電力を用いることができるだろう。この場合、その顧客の需要プロフィールを単に閲覧することによって不正を検出することは困難であるだろう。その顧客の需要プロフィールは、顧客の需要が増加したはずであるが不正行為のせいで増加しなかったことを判断するために、他の顧客の需要プロフィールと比較されなければならないだろう。この態様であれば、本開示の実施形態は、顧客(たとえば、上述の例においてレギュレータを使用し始める顧客)の挙動の変化を考慮に入れて、それらの挙動の変化を検出することができる。これらの挙動変化は不正行為の点でかなり共通しているが、これは、機械学習モデルを開始させるには正確でなく、それらのモデルを頻繁に更新させなければならない理由である。
【0073】
要約すると、パーセンタイルに基づいて検出器を規定することは、まれなイベントが事前に特定されているのではなく、むしろ、母集団にわたる需要プロフィールから派生されていることを意味している。たとえば、10パーセンタイルを下回る中間需要が、母集団の90%未満となるであろう10未満kWhの中間需要に対応していると判断されてもよい。
【0074】
図5は、本開示の実施形態に従った、電力不正検出のために使用できる例示的な分布テーブルを示す。
【0075】
より具体的には、406388の顧客のセット(たとえば、未知のセット)に関して例示的な分布テーブル500が示される。この場合、34719の需要プロフィールが、10未満kWHの中間需要に対応する母集団の10パーセンタイル未満である中間需要の検出器を用いて、既知の不正事例と同じ挙動特徴を有するものと識別された。なお、テーブル500における数をすべて合計した結果、(34000までのプロフィールとは異なる)約38000までのプロフィールが得られることとなる。これは、アカウントのいくつかインアクティブであることと、検出器がアクティブとインアクティブとの区別(FPルールエンジンのジョブである)を行なわないことと、によって説明することができる。
【0076】
このシナリオにおいては、母集団のうち98%未満の中間需要を有した18982の需要プロフィールが存在していることを行「c」において認識することができる。また、バケットが完全にスキップされると、母集団の1パーセンタイルにおいて需要プロフィールが存在しないことも、行「b」において認識することができる。
【0077】
図6Aは、本開示の実施形態に従った、顧客の例示的な需要プロフィールを示す。
図6Bは、本開示の実施形態に従った、顧客の需要についての例示的なグラフを示す。
【0078】
図6Bに示されるように、グラフ600は、顧客の需要データに基づいており、500日を越える期間にわたって日毎ベースのキロワット時(kWh)で顧客の需要(または電力使用量)を示している。顧客の需要が日毎に大幅に変化し得るので、その変化をグラフにおいて見ることができる。
【0079】
この需要データは、顧客の需要プロフィールに含まれる多数のメトリクスを計算するために用いることができる。たとえば、この特定の顧客の需要プロフィールは、その期間にわたる0kWhの最小需要、その期間にわたる1kWhの中間需要、その期間にわたる54kWhの最大需要、その期間にわたる6.704kWhの中間需要、その期間にわたる0kWhの第1分位数の需要、および、その期間にわたる5kWhの第3分位数の需要、によって規定されてもよい。これらの値は、
図6Aに示される顧客の需要プロフィールに反映されている。顧客の需要プロフィールにおける大きなスパイクが平均需要を歪める可能性があることが分かっており、このため、実際には、メトリックのような中間値を用いることが、歪みについての潜在的な問題を回避するのに有用となり得る。
【0080】
したがって、需要プロフィールのこのような生成は、1セットにおける顧客ごとに、その顧客についての需要データを用いて、ループにされて実行することができる。各顧客がアクティブであった日数は、特定された期間にわたって、それらの中間需要、それらの最大需要、それらの最小需要などとともに計算することができる。
【0081】
図7は、本開示の実施形態に従った例示的な結果テーブルを示す。
結果テーブル700は、既知の不正事例のうちどれが検出器によって識別されたかを判断するために、既知の不正事例に検出器を適用することなどによって、電力不正を検出する際に用いられるモデルを検証するために用いることができる。たとえば、(中間および最大の需要が常に0である、中間需要は0であるが最大需要がゼロよりも大きく、かつ、中間需要がゼロと10パーセンタイルとの間である)3つの検出器のセットが低い需要に関連付けられた需要プロフィールを識別するために用いられるシナリオについて検討する。これらの検出器は、それらの既知の事例のうちいくつが検出器についての疑わしい挙動を呈したかを確かめるために、123の既知の不正事例のセットに適用することができる。これらの検出器はまた、それらの未知の事例のうちいくつが検出器についての疑わしい挙動を呈したかを確かめるために、406388の顧客のセットに適用することができる。上述の例においては、既知の不正事例のうち同じ挙動特徴を呈した34719の需要プ
ロフィールが存在したことが述べられた。したがって、結果テーブル700においては、欄702、欄704および欄706は、3つの検出器のうちの1つを用いて検出された123の既知の不正事例の数に対応し得る。欄708、欄712および欄712は、3つの検出器のうちの1つを用いて識別された未知のもののうち34719の需要プロフィールの数に対応し得る。結果テーブル700の行724および行726は、顧客のロットサイズが500平方フィート未満であることに起因して、または顧客が太陽エネルギのユーザであることに起因して、その疑わしい挙動がうまく説明され得る検出された事例の数に対応し得る。顧客が太陽エネルギのユーザであることは、低い需要に関連付けられてもよい。なぜなら、その顧客は、電力を盗むのではなく太陽から電力を獲得し得るからである。500平方フィート未満のロットサイズを有する顧客も、低い需要に関連付けられるだろう。なぜなら、顧客の小規模な住居が、需要であり得るものに対して上限を加えるからである。
【0082】
(「fraud_always_zero」という見出し付きの)欄702は、123の既知の不正事例のうちいくつが、常にゼロである中間および最大の需要を有するものとして識別されたかを規定し得る。たとえば、結果テーブル700においては、123の既知の不正事例のうちの2つが、常にゼロである中間および最大の需要を有するものとして識別されたことが示されている。それらの2つの識別された既知の不正事例のいずれも、顧客が500平方フィート未満のロットサイズを有することまたは太陽エネルギのユーザであることに基づいて、説明可能とはならなかった。
【0083】
(「fraud_med_zero」という見出し付きの)欄704は、123の既知の不正事例のうちのいくつが、ゼロの中間需要を有するとともに0よりも大きい最大需要を有するものとして識別されたかを規定し得る。たとえば、結果テーブル700においては、123の既知の不正事例のうちの7つが、ゼロの中間需要を有するとともに0よりも大きい最大需要を有するものとして識別されたことが示されている。これらの識別された7つの既知の不正事例はいずれも、顧客が500平方フィート未満のロットサイズを有していること、または、太陽エネルギのユーザであることに基づいて、説明可能とはならなかった。
【0084】
(「fraud_near_zero」という見出し付きの)欄706は、123の既知の不正事例のうちいくつが、ゼロと10パーセンタイル(ここでは、10kWh)との間の中間需要を有するものとして識別されたかを規定し得る。たとえば、結果テーブル700においては、123の既知の不正事例のうちの6つが、ゼロと10パーセンタイルとの間の中間需要を有するものとして識別されたことが示されている。これらの識別された6つの既知の不正事例はいずれも、顧客が500平方フィート未満のロットサイズを有していること、または太陽エネルギのユーザであることに基づいて、説明可能とはならなかった。
【0085】
(「u_always_zero」という見出し付きの)欄708は、未知のセットから検出された34719の事例のうちいくつが、常にゼロである中間および最大の需要を有するものとして識別されたかを規定し得る。たとえば、結果テーブル700においては、34719の検出された不正事例のうちの6556が、常にゼロである中間および最大の需要を有するものとして識別されたことが示されている。これらの検出された不正事例のうちの6つは、顧客が500平方フィート未満のロットサイズを有することに基づく正当な説明を有していた。
【0086】
(「u_med_zero」という見出し付きの)欄710は、未知のセットから検出された34719の事例のうちのいくつが、ゼロの中間需要を有するとともに0よりも大きい最大需要を有するものとして識別されたかを規定し得る。たとえば、結果テーブル7
00においては、34719の検出された不正事例のうち6375がゼロの中間需要を有するとともに0よりも大きい最大需要を有するものとして識別されたことが示されている。これらの検出された不正事例のうちの2つは、顧客が500平方フィート未満のロットサイズを有することに基づく正当な説明を有していた。
【0087】
(「u_near_zero」という見出し付きの)欄712は、未知のセットから検出された34719の事例のうちいくつが、ゼロと10パーセンタイルとの間の中間需要を有するものとして識別されたかを規定し得る。たとえば、結果テーブル700においては、検出された34719の不正事例のうちの21788が、ゼロと10パーセンタイルとの間の中間需要を有するものとして識別されたことが示されている。これらの検出された不正事例のうち9つは、顧客が500平方フィート未満のロットサイズを有することに基づいた正当な説明を有しているとともに、検出された不正事例のうちの10は、顧客が太陽エネルギのユーザであることに起因していた。
【0088】
図8Aは、本開示の実施形態に従った、未知の不正事例において検出された低い中間需要の例示的なグラフを示す。
【0089】
より具体的には、図は、300日を越える期間にわたって非常に低い中間需要の挙動パターンに基づいて検出器を用いてフラグが立てられたサービスポイントにおける需要のグラフを示す。グラフは最大需要におけるスパイクを含んでいるが、中間需要は、大部分が比較的低いものと見なすことができる。これは、(
図8Bに示される)既知の不正インシデントと同様の挙動を伴う未知の事例(たとえば、不正であるとしてそれまで識別されていない顧客)のセットにおいてフラグが立てられている不正の事例であるとともに、これは、従来の方法に基づいたトレーニングデータセットを用いて識別されなかったであろう不正の事例の例を表わしている。
【0090】
図8Bは、本開示の実施形態に従った、既知の不正事例において検出された低い中間需要の例示的なグラフを示す。
【0091】
この図は、同様に、300日を越える期間にわたって非常に低い中間需要の挙動パターンに基づいて検出器を用いてフラグが立てられたサービスポイントにおける需要のグラフを示している。グラフは、初めはより高いレベルの需要を有しているが、約100日間のアカウント年に対応する不正の日付において、需要が劇的に低下し、グラフの残り部分においては非常に低いままである。これは、既知の事例(たとえば、不正なものとして既に実証された顧客)のセットにおいてフラグが立てられた不正の事例であって、このため、不正のこの事例に関連付けられた総収入の損失が既知となっている。検出器が不正のこの既知の事例にフラグを立てることは再確認をもたらす。なぜなら、検出器が従来の方法から識別された不正の検証された事例に正確にフラグを立てていることを示しているからである。
【0092】
図9Aは、本開示の実施形態に従った、未知の不正事例において検出されたゼロの中間需要の例示的なグラフを示す。
【0093】
より具体的には、図は、300日を越える期間にわたってゼロである中間需要の挙動パターンおよび0よりも大きい最大需要の挙動パターンに基づいて、検出器を用いてフラグが立てられたサービスポイントにおける需要のグラフを示している。グラフは、初めは比較的高い需要から始まっているが、需要は直ちにゼロにまで低下して、グラフの残りにおいてはそこに留まっている。これは、(
図9Bに示される)既知の不正インシデントと同様の挙動を伴った未知の事例(たとえば、不正なものとしてそれまでに識別されていない顧客)のセットにおいてフラグが立てられている不正の事例であって、これは、従来の方
法に基づいたトレーニングデータセットを用いて識別されなかったであろう不正の事例の例を表わしている。
【0094】
図9Bは、本開示の実施形態に従った、既知の不正事例において検出されたゼロの中間需要の例示的なグラフを示す。
【0095】
この図は、同様に、300日を越える期間にわたってゼロである中間需要の挙動パターンおよびゼロよりも大きい最大需要の挙動パターンに基づいて検出器を用いてフラグが立てられたサービスポイントにおける需要のグラフを示している。このグラフは、初めにより高いレベルの需要を有しているが、需要が劇的に低下する。これは、既知の事例(たとえば、実際の実証された既知の不正事例)のセットにおける検出器によってフラグが立てられた不正の事例であって、再確認をもたらしている。なぜなら、検出器が従来の方法から識別された実証された不正事例に正確にフラグを立てていることを示しているからである。このような既知の不正の事例の場合、従来の方法を用いて不正を実際に検出するには、疑わしい挙動が始まった日付から200日を上回る時間を要した。それに比べて、このタイプの挙動を検出するように構成された検出器は、疑わしい挙動が始まった後、はるかに迅速に不正を識別することができる可能性がある。
【0096】
図10は、本開示の実施形態に従った、疑わしい挙動の正当な説明に対応する例示的なフィールド活性フラグを示す。
【0097】
より具体的には、図は、或るアクティビティがサービスポイント上において実行されるたびにシステムによって生成され得るフィールド活性フラグを含むテーブルを示す。これらのアクティビティは電力会社、顧客または環境の結果として生成することができる。それらのアクティビティに対応する活性フラグは、不正の行なわれる前、最中および/または後に発生し得るとともに、疑わしい挙動を除外するための正当な説明を判断するために用いることができる有益な情報を提供し得る。このため、活性フラグを組込むことは、検出フレームワークを改善させ得るとともに、誤判定の識別を支援し得る。たとえば、不正の日付で発生し得る1つの活性フラグは「メータが切断-支払なし」であって、顧客の支払い不履行のせいで、関連付けられたサービスポイントのサービスがカットされたことを示すだろう。フィールド活性フラグの他の例を図において確認することができる。
【0098】
フィールド活性フラグ以外の他の情報が、誤判定(たとえば、疑わしい挙動についての正当な説明のソース)を識別し易くするために用いられてもよい。いくつかの実施形態においては、電力不正検出システムは、調査および/または国勢調査情報を用いることができてもよい。たとえば、調査表が顧客に送られてもよく、これら調査表から、特定の近隣に住んでいる特定の所得層の人々がより環境意識の高い(たとえば、環境に優しい)傾向があると判断され得る。加えて、このデータは、連続的にリアルタイムで顧客のソーシャルメディアから収集され得る。場合によっては、環境意識の高い人にとって典型的な需要プロフィールを判断して、比較の目的(たとえば、これは環境意識の高い人の挙動である)で用いることができる。いくつかの実施形態においては、この判断は機械学習アルゴリズムを用いて行うことができる。このため、疑わしい挙動を有する任意の識別された顧客の挙動は、疑わしい挙動についての正当な説明のうちの1つが顧客の環境意識が高いことであるかどうかを判断するために、環境意識が高い人であることが知られている顧客の挙動と比較することができる。したがって、誤判定を識別するためにシステムによって用いられる情報は、調査、ソーシャルメディア、需要プロフィールから集められた仮定の組合せから、および/または計測技術自体から、得られてもよい。
【0099】
いくつかの実施形態においては、この明細書中に開示される電力不正検出システムの出力は、全体的に新しいシステムの開発を可能にするように使用可能であり得る。これらの
システムが本質的に依存性を有しているために、既存の方法(たとえば、機械学習または専門家ベースのシステム)によってこのようなシステムが開発されるのが妨げられている。なぜなら、それら方法では、データ駆動型の数学的に厳密な態様で正確に確率に到達することができず、スケール変更されておらず、かつ、実際には不可能であるかもしれない(たとえば、人が有意義な影響をもたらす回答に達するのに時間がかかりすぎるであろう)からである。
【0100】
いくつかの実施形態においては、電力不正検出システムは、システムのユーザ(たとえば、検出器または誤判定の説明を規定する誰か)からのドメイン知識を必要することなく仮説が生成されてテストされ得るように、自動的な仮説生成を可能にするように構成されてもよい。先に述べたように、ユーザは、挙動のパターン(たとえば検出器)を、需要プロフィールにおいて検出する際の見え方で規定し得る。または、ユーザは、誤判定ルールエンジンにおける疑わしい挙動についての正当な説明を規定してもよい。自動的な仮説生成のために構成されたシステムの実施形態においては、ユーザは継続的に検出器および/もしくは誤判定ルールを規定してもよく、または、それらは、システムが、検出についての仮説に自動的に到達するとともにエンド・ツー・エンドで自律的にプロセス全体を実行することを可能にし得る(たとえば、システムは、疑わしい挙動を有する顧客の検出を自動的に実行し得るとともに、誤判定ルールエンジンを用いていずれの正当な挙動もうまく説明し、さらに、未説明の疑わしい挙動を伴う顧客の結果を生成し得る)。
【0101】
図11は、本開示の実施形態に従った、電力不正の検出を実現するためのブロック図である。
【0102】
いくつかの実施形態においては、電力不正検出システムについての解決実現例はビッグデータクラウドプラットフォーム1110を含み得る。いくつかの実施形態においては、ビッグデータクラウドプラットフォーム1110は、電気使用量データをすべて、標準フォーマット1122でオブジェクトストア1120に格納し得る。
【0103】
いくつかの実施形態においては、オブジェクトストア1120が維持されて、ビッグデータクラウドサービス1140を介して提供されてもよい。いくつかの実施形態においては、ビッグデータクラウドサービス1140は、Cloudera(登録商標)1142、オープンソースのApache Hadoop分布を含み得る。これにより、オブジェクトストア1120に
含まれるデータは、Apache Hadoop、分散型ストレージのために用いられるオープンソー
スソフトウェアフレームワーク、および大型のデータセットの処理を用いて格納されてもよい。オブジェクトストア1120に含まれるデータは分割されて、コンピューティングクラスタにおけるノードにわたって分散された大型のブロックに格納され得る。いくつかの実施形態においては、ビッグデータクラウドサービス1140はさらにエンタープライズR1144を含み得る。エンタープライズR1144は、オブジェクトストア1120内に含まれている大量のデータに関して、R、すなわちオープンソース統計プログラミング言語および環境、の使用を提供する。エンタープライズR1144は、顧客の電気使用パターンにおける不正な挙動の存在を検出するためにこの例において用いることができる自動化されたデータ分析の開発および展開を可能にし得る。
【0104】
図に示されるように、ビッグデータクラウドプラットフォーム1110は、バルクソースデータ1150およびストリーミングソースデータ1152を受信し得る。一般に、バルクソースデータ1150は、顧客の電気使用量および需要プロフィールなどの履歴データに加えて、それまでに観察された不正行為の事例に関連付けられたデータ項目をも含み得る。いくつかの実施形態においては、バルクソースデータ1150は、「データレイク(data lake)」と称され得るオブジェクトストア1120に格納されてもよい。オブジ
ェクトストア1120に格納されたデータはすべて、一様に、標準フォーマット1122
で格納されてもよい。いくつかの実施形態においては、標準フォーマット112は、Hadoop分散型ファイルシステム(Hadoop Distributed File System:HDFS)であってもよく、スケーラブルで信頼性の高いデータストレージを提供するために用いられるJava(登録商標)ベースのファイルシステムであってもよい。
【0105】
ストリーミングソースデータ1152は、リアルタイムで(たとえばメータから)受信される顧客の実際の電気使用量を含み得る。各顧客ごとに、それらのリアルタイムの電気使用量がビッグデータクラウドプラットフォーム1110に送られてもよい。いくつかの実施形態においては、ストリーミングソースデータ1152は、Kafka1130などの通信インターフェイスにおいて受信されてもよい。通信インターフェイスとして、Kafka1130はストリーミングソースデータ1152を受信し、そのデータ内の個々のメッセージを解析してもよい。それらのメッセージは、オブジェクトストア1120に(たとえば、標準フォーマット1122で)格納することができるデータに変換することができる。これにより、オブジェクトストア1120は、バルクソースデータ1150(たとえば、顧客についての履歴電気使用量)およびストリーミングソースデータ1152(たとえば、顧客についてのリアルタイムの電気使用量)からのデータを同じ一様なフォーマットで含んでいてもよい。
【0106】
いくつかの実施形態においては、Spark1134および/またはHive LLAP1136はさらに、オブジェクトストア1120内に含まれているデータをすべて(たとえば不正な挙動を検出するために)分析して処理するために用いられる。Spark1134(たとえば、Apache Spark)は、データのストリーミングおよび機械学習のために内蔵モジュールを介してビッグデータ処理のための高速かつ汎用のエンジンとして機能するクラスタコンピューティングフレームワークを提供し得る。言いかえれば、Spark1134は、コンピュータのクラスタにわたる大規模なデータセットの分散処理を用いてビッグデータ分析を実行するための特徴を提供し得るとともに、大量のデータを分散処理するためのベースとなるHadoop Map/Reduce技術を改善させ得る。Spark1134は、メモリに存続することによって固有のHadoop Map/Reduce機能を過剰にチャージし得る一方で、Map/Reduceはディスクに残存している。結果として、Spark1134は、メモリ動作の点でMap/Reduceよりも100倍高速であり得るとともに、ディスク動作の点でMap/Reduceよりも10倍高速であり得る。
【0107】
いくつかの実施形態においては、Spark1134は、Oracle R Advanced Analytics for Hadoop(ORAAH)を含み得る。Oracle R Advanced Analytics for Hadoopは、コンピュータのクラスタにわたる大型のデータセットの分散処理を用いて、ビッグデータ分析を実行するための特徴を提供する「スーパーチャージされた(supercharged)」バージョンのSparkとしての役割を果たし得る。ORAAHは、従来のSparkパッケージに勝る多数の利点を提供し得る。たとえば、ORAAHは、スパークより32倍高速の機械学習モデル(たとえば、分類、クラスタ化、回帰、特徴抽出などのための機械学習アルゴリズム)を提供し得る。ORAAHはまた、研究開発において開発された機械学習モデルを製造に向けて展開する能力を提供してもよい。ORAAHはまた、データレイクにおいてRスクリプトを直接実行する能力を提供してもよい。ORAAHはまた、HDFSおよび/またはHIVEを含む複数のデータフォーマットからのデータの読取り/書込みを可能にする単一のパッケージとしての役割を果たし得る。ORAAHはまた、R内に存在する任意の式を処理可能であり得るのに対して、Sparkは、制限された変換のサブセットで単純な属性を処理することができるだけであり得る。
【0108】
いくつかの実施形態においては、Hive LLAP1136は、Apache Hiveを含んでいてもよく、データ要約、クエリおよび分析のためにSQL様のインターフ
ェイスを提供するためのApache Hadoopプラットフォーム上に構築されたデータウェアハウスソフトウェアプロジェクトであり得る。Hive LLAP(低レイテンシ分析処理)1136は、より高速のSQL分析を提供することによってHiveアーキテクチャ上に構築されてもよい。これにより、Kafka1130を用いて、ストリーミングデータからのメッセージを解析して取得する。これらメッセージは次いで、オブジェクトストア1120における履歴データに追加される。オブジェクトストア1120に含まれるこの「データレイク」は、この明細書中に上述されてきた電力不正を検出するためのステップを実行するために、Spark1134およびHive LLAP1136を用いて処理される。
【0109】
いくつかの実施形態においては、オブジェクトストア1120は、コンピューティング効率の向上および必要なコンピューティングリソースの減少に関連付けられた特徴を、分離されたストレージに提供する態様で実現されてもよい。Hadoopは、典型的には、HDFSとMapReduceとの組合せから成る。しかしながら、HDFSに関する問題は、計算が各ノード(たとえば、分散型コンピューティングシステムのクラスタ)上にあって、付加的な計算を得るためにより多くのノードを追加する必要がある点である。各々のノードは計算および格納を行なうものであって、これは、より多くのノードを追加することによって、使用されていないストレージが有効に補償されていることを意味している。代替例として、HDFS以外のストレージ機構、たとえばAmazon S3またはオラクルオブジェクトストレージなどを用いることができる。たとえば、システムがオブジェクトストレージとMapReduceとの組合せで実現されるように、HDFSを交換することができる。この実現例の下では、ストレージは分離されており、ノードには最小限のストレージを追加することができ、そのストレージに関連付けられ得る追加コストを低減することができる。言いかえればオラクルのビッグデータクラウドサービスなどのサービス(計算エディション)は、追加のHadoopクラスタまたはSparkクラスタを要求に応じてプロビジョニングするために用いることができるが、データ自体は、Amazon S3またはオラクルオブジェクトストレージ内に保持されており、必要に応じてクラスタによって検索される。
【0110】
図12は、本開示の実施形態に従った、電力不正検出のためのハイブリッドシステム図を示す。
【0111】
図に示されるように、電力不正検出システム1220は、さまざまな顧客に関連付けられたリアルタイム電気使用量データ1232および履歴電気使用量データ1234を受信する。いくつかの実施形態においては、リアルタイム電気使用量データ1232は1つ以上の電気メータ1230から直接受信される。1つ以上の電気メータ1230は各々、顧客に関連付けられたリアルタイム使用量データを提供する。
【0112】
電力不正検出システム1220は、ブロック1242においてこのデータをすべて取込んでもよい。これは、1つ以上の電気メータ1230と通信するとともに1つ以上の電気メータ1230からデータを受信するように構成された特化された通信インターフェイス(たとえば、プログラミングインターフェイスまたはAPI)を含んでいてもよい。履歴電気使用量データ1234を格納するいずれかのコンピュータシステムまたはデバイスと通信するとともに履歴電気使用量データ1234を格納するいずれかのコンピュータシステムまたはデバイスからデータを受信するように構成された通信インターフェイスがあってもよい。たとえば、履歴電気使用量データ1234がクラウドコンピューティングネットワーク上に格納される場合、電力不正検出システム1220は、クラウドコンピューティングネットワークからそのデータをすべて検索するための通信インターフェイスを有していてもよい。
【0113】
データのすべてが電力不正検出システム1220内で統合されると、ブロック1244において、電力不正検出システム1220は、データをすべて単数の一様なフォーマットに(たとえば、日付/時間がすべて同じフォーマットに従うことを確実にして)変換し得ることにより、任意の顧客についての履歴電気使用量データおよびリアルタイム電気使用量データをともに組合わせて用いることができるようにする。
【0114】
ブロック1246において、電力不正検出システム1220は、データ(たとえば、すべての顧客についての履歴電気使用量データおよびリアルタイム電気使用量データ)をすべて
図11に示されるオブジェクトストア1120などのストレージに格納し得る。ブロック1248において、電力不正検出システム1220は、ストレージ内のデータのすべてに対してR分析を実行し得る。各顧客ごとに、電力不正検出システム1220は、顧客らの履歴電気使用量およびリアルタイム電気使用量に基づいて使用量需要プロフィールを決定し得る。ブロック1250において、電力不正検出システム1220は、1以上の顧客の不正を検出するために各顧客ごとに使用量を分析し得る。
【0115】
電力不正検出システム1220が潜在的な不正を識別すると、エグゼクティブチーム1290のメンバは、デバイス1280上のインターフェイス1282を介して、潜在的に不正行為を犯していると識別された顧客に関するレポートを閲覧することができるようになり得る。デバイス1280は、電力不正検出システム1220から生成されたこれらのレポートを受信してもよい。さらに、エグゼクティブチーム1290のメンバは、(たとえば、顧客の住居に関連付けられたサービスポイントidまたはアドレスに基づいて)任意の顧客についての使用量需要プロフィールを引き出して閲覧することができるかもしれない。これにより、人が、いずれかの異常を認識するために顧客の使用量需要プロフィールを閲覧することにより、識別されたいずれの潜在的な不正行為についても付加的に確認することができるようにする。エグゼクティブチーム1290のメンバが、顧客に関連付けられた識別されたいずれかの潜在的な不正行為をさらに確認すると、これらメンバは、現場スタッフ1210に対して、顧客の場所まで物理的に赴き、メータを調べて、不正が行なわれていることを確認するようにとの指示をインターフェイス1282内にて直接示してもよい。
【0116】
次いで、デバイス1280は、電力不正検出システム1220に命令を送信することとなり、さらに、電力不正検出システム1220は、顧客のアドレスに(たとえば地理的に)最も近くにいる現場スタッフ1210を判断するだろう。複数の不正行為の事例がある場合に複数の顧客が存在する場合、これらの顧客はまた、近隣に位置するか否かに基づいて現場スタッフ間で振り分けられる可能性がある(たとえば、現場スタッフ1210は、彼らの地理的位置にいる顧客のプールを受取ってもよい)。次いで、電力不正検出システム1220は現場スタッフ1210に関連付けられたデバイス1212に命令を転送し得る。現場スタッフ1210は、デバイス1212上のインターフェイス1214を介して命令および顧客のアドレスを閲覧することができてもよい。その後、現場スタッフ1210は、不正が行なわれていることを実証するために、顧客のアドレスまで物理的に訪れて、メータを調べて、顧客によって実行されているいずれの不正をも調査し得る。現場スタッフ1210は、不正がデバイス1212上のインターフェイス1214を介して実際に行なわれているかどうかを示すことができてもよい。この情報は、エグゼクティブチーム1290に報告し返すことができるか、または、不正を検出するための任意の既存の挙動モデルを更新するかもしくは向上させるために(たとえば、電力不正検出システム1220に格納されている)既存のデータに追加されてもよい。
【0117】
図13は、本開示の実施形態に従った、突然低下した後に低いままとどまっている需要についての例示的な挙動パターンを示す。
【0118】
図に示されるように、需要の突然の低下(たとえば、約25から5までの低下)は150日目前後で起こっており、需要が引続き(たとえば、平均5前後で)低いままとなる。需要が既にわずかに下方に傾いているが、需要の突然の低下は、依然として異常であると見なすことができ、進行中の電力不正使用の開始に特有のものであり得る。この挙動パターンは、潜在的な疑わしいアクティビティを識別するために検出器として用いられてもよい。
【0119】
図14は、本開示の実施形態に従った、緩やかに低下した後に低いままとどまっている需要についての例示的な挙動パターンを示す。
【0120】
図に示されるように、需要プロフィールは、永続的に低くなる(たとえば、平均で5前後に)までわずかに下方に傾斜している。電力需要が時間とともに低下し得る理由が数多く存在している(たとえば、ユーザの電力消費習慣が変化する可能性がある)が、これらの理由は、需要が徐々に緩やかに低下した後に継続的に低いままである需要プロフィールに何らかの形で対応するはずであるだろう。緩やかな低下は、進行中の電力不正に特有のものであり得るとともに、この挙動パターンは潜在的な疑わしいアクティビティを識別するために検出器として用いられてもよい。
【0121】
図15は、本開示の実施形態に従った、長期間にわたって緩やかに低下する需要についての例示的な挙動パターンを示す。
【0122】
図に示されるように、需要プロフィールは期間全体にわたって下降傾向を示す。
図14と同様に、電力需要が時間とともに低下し得る理由が数多く存在している(たとえば、ユーザの電力消費習慣が変化する可能性がある)が、需要プロフィールの長期間にわたる低下は進行中の電力不正に特有のものであり得るとともに、この挙動パターンは潜在的な疑わしいアクティビティを識別するために検出器として用いられてもよい。
【0123】
図16は、本開示の実施形態に従った、非常に低い需要についての例示的な挙動パターンを示す。
【0124】
図に示されるように、需要プロフィールは、持続期間全体にわたって非常に低い(たとえば、平均で2.5の)ままとどまっている。その期間にわたってユーザの電力消費が非常に低い可能性がある(たとえば、ユーザが国外に滞在しており、プラグが差込まれた機器が電力を引き出しているため電力が消費されている)が、長期間にわたる低需要は、進行中の電力不正および隠されている真の需要プロフィールに特有のものであり得る。この挙動パターンは、潜在的な疑わしいアクティビティを識別するために検出器として用いられてもよい。
【0125】
図17は、本開示の実施形態に従った、上昇すると予想されていた場合に上昇しない需要についての例示的な挙動パターンを示す。
【0126】
図に示されるように、ユーザの母集団全体の需要は、母集団全体が何を行っているかを観察するために策定することができる(たとえばECDF)。150日目に、母集団全体にわたって、突然、需要にスパイクが発生する(たとえば、55から70まで突然上昇する)。この需要の上昇は、250日目まで持続し、その後、母集団全体にわたって需要が突然低下する(たとえば、70から55まで突然低下する)。ユーザの母集団全体にわたって需要が一時的に上昇する理由が数多く存在し得る。たとえば、需要の上昇は、夏季における典型的な需要挙動を表わし得る。150日目と250日目との間の温度はより高くなっていたかもしれず、結果として、使用量のスパイクが発生することとなるが、これは、ユーザの母集団全体がエアコンディショナをオンにして起動させたことに起因している
。
【0127】
同時に、単一のユーザについての需要プロフィールが策定され、同じ期間にわたる母集団の需要と比較され得る。この比較は、(たとえば、ユーザが母集団全体と同様の挙動を行なった場合に)ユーザの需要プロフィールが呈示する「はずであった」が呈示しなかったものを明らかにするために用いることができる。たとえば、ユーザの需要プロフィールは、母集団全体わたるに需要において観察された150日目から250日目までの需要の上昇を呈していない。ユーザの需要プロフィールは、母集団とは実質的に異なっている。これについて多数の理由があり得る。たとえば、母集団における需要の上昇がより高い温度に起因するものであった場合、このユーザがエアコンディショナを使用せずに単に高温に耐えていたかもしれない。しかしながら、ユーザの需要プロフィールが進行中の電力不正のせいで正確ではない(たとえば、ユーザの需要が誤って報告されている)という別の説明もあり得る。したがって、この挙動パターンは、潜在的な疑わしいアクティビティ(ユーザが他のユーザと比較されていなかった場合には観察されないであろう特に疑わしいアクティビティ)を識別するために検出器として用いられてもよい。
【0128】
図18は、本開示の実施形態に従った、過度に異常に安定している需要についての例示的な挙動パターンを示す。
【0129】
図に示されるように、需要プロフィールは或る期間にわたって異常に安定している。150日目と200日目との期間の間に、ユーザの需要は50で一定にとどまっている。これは、(たとえば過渡信号のような)何らかの変動性を有するその期間外の通常の電力使用量と比較すると、かなり異常である。需要プロフィールの異常な安定性についての1つの説明として、ユーザの需要プロフィールが進行中の電力不正のせいで正確ではないということが挙げられる(たとえば、安定性が異常である期間にわたるユーザの需要が誤って報告されている)。したがって、この挙動パターンは、潜在的な疑わしいアクティビティを識別するために検出器として用いられてもよい。
【0130】
付加的な実現例の詳細
図19は、この明細書中に開示された実施形態のうちの1つを実現するための分散型システムを示す簡略図である。分散型システム1900は、上述したように、電力不正検出システムの実施形態を実現することができる。例示された実施形態においては、分散型システム1900は、1つ以上のネットワーク1910を介して、ウェブブラウザ、プロプライエタリクライアント(たとえばオラクルフォーム)などのクライアントアプリケーションを実行して動作させるように構成される1つ以上のクライアントコンピューティングデバイス1902、1904、1906および1908を含む。サーバ1912は、ネットワーク1910を介してリモートクライアントコンピューティングデバイス1902、1904、1906および1908と通信可能に結合されてもよい。
【0131】
さまざまな実施形態においては、サーバ1912は、システムの構成要素のうち1つ以上によって提供される1つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。サービスまたはソフトウェアアプリケーションは非仮想環境および仮想環境を含み得る。仮想環境は、2次元または3次元(three-dimensional:3
D)表現、ページベースの論理的環境などであろうとなかろうと、仮想イベント、トレードショー、シミュレータ、クラスルーム、購買商品取引および企業活動のために用いられるものを含み得る。いくつかの実施形態においては、これらのサービスは、ウェブベースのサービスもしくはクラウドサービスとして、またはソフトウェア・アズ・ア・サービス(Software as a Service:SaaS)モデルのもとで、クライアントコンピューティン
グデバイス1902,1904,1906および/または1908のユーザに供給されてもよい。そして、クライアントコンピューティングデバイス1902,1904,190
6および/または1908を動作させるユーザは、1つ以上のクライアントアプリケーションを利用して、サーバ1912と相互作用して、これらの構成要素によって提供されるサービスを利用し得る。
【0132】
図19に示されている構成では、システム1900のソフトウェアコンポーネント1918,1920および1922は、サーバ1912上に実装されるように示されている。また、他の実施形態においては、システム1900の構成要素のうちの1つ以上および/またはこれらの構成要素によって提供されるサービスは、クライアントコンピューティングデバイス1902,1904,1906および/または1908のうちの1つ以上によって実現されてもよい。その場合、クライアントコンピューティングデバイスを動作させるユーザは、1つ以上のクライアントアプリケーションを利用して、これらの構成要素によって提供されるサービスを使用し得る。これらの構成要素は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実現されてもよい。分散型システム1900とは異なり得るさまざまな異なるシステム構成が可能であることが理解されるべきである。したがって、
図19に示されている実施形態は、実施形態のシステムを実現するための分散型システムの一例であり、限定的であるよう意図されたものではない。
【0133】
クライアントコンピューティングデバイス1902,1904,1906および/または1908は、手持ち式携帯機器(たとえばiPhone(登録商標)、携帯電話、iPad(登録商標)、計算タブレット、パーソナルデジタルアシスタント(personal digital assistant:PDA))またはウェアラブル装置(たとえばグーグルグラス(登録商標)ヘッドマウントディスプレイ)であってもよく、当該装置は、マイクロソフト・ウィンドウズ(登録商標)・モバイル(登録商標)などのソフトウェアを実行し、および/または、iOS、ウィンドウズ・フォン、アンドロイド、ブラックベリー10、パームOSなどのさまざまなモバイルオペレーティングシステムを実行し、インターネット、eメール、ショート・メッセージ・サービス(short message service:SMS)、ブラックベリ
ー(登録商標)、または使用可能な他の通信プロトコルである。クライアントコンピューティングデバイスは、汎用パーソナルコンピュータであってもよく、当該汎用パーソナルコンピュータは、一例として、マイクロソフトウィンドウズ(登録商標)、アップルマッキントッシュ(登録商標)および/またはリナックス(登録商標)オペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび/またはラップトップコンピュータを含む。クライアントコンピューティングデバイスは、ワークステーションコンピュータであってもよく、当該ワークステーションコンピュータは、たとえばGoogle Chrome OSなどのさまざまなGNU/リナックスオペレーティングシステムを含むがこれらに限定されるものではないさまざまな市販のUNIX(登録商標)またはUNIXライクオペレーティングシステムのうちのいずれかを実行する。代替的には、または付加的には、クライアントコンピューティングデバイス1902,1904,1906および1908は、シン・クライアントコンピュータ、インターネットにより可能なゲームシステム(たとえばキネクト(登録商標)ジェスチャ入力装置を備えるかまたは備えないマイクロソフトXボックスゲーム機)、および/または、ネットワーク1910を介して通信が可能なパーソナルメッセージング装置などのその他の電子装置であってもよい。
【0134】
例示的な分散型システム1900は、4個のクライアントコンピューティングデバイスを有するように示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサを有する装置などの他の装置が、サーバ1912と相互作用してもよい。
【0135】
分散型システム1900におけるネットワーク1910は、さまざまな市販のプロトコルのうちのいずれかを用いてデータ通信をサポートすることができる、当業者になじみの
ある任意のタイプのネットワークであってもよく、当該プロトコルは、TCP/IP(伝送制御プロトコル/インターネットプロトコル)、SNA(システムネットワークアーキテクチャ)、IPX(インターネットパケット交換)、アップルトークなどを含むが、これらに限定されるものではない。単に一例として、ネットワーク1910は、イーサネット(登録商標)、トークンリングなどに基づくものなどのローカルエリアネットワーク(LAN)であってもよい。ネットワーク1910は、広域ネットワークおよびインターネットであってもよい。ネットワーク1910は、仮想ネットワークを含んでいてもよく、当該仮想ネットワークは、仮想プライベートネットワーク(virtual private network:
VPN)、イントラネット、エクストラネット、公衆交換電話網(public switched telephone network:PSTN)、赤外線ネットワーク、無線ネットワーク(たとえば米国電
気電子学会(Institute of Electrical and Electronics:IEEE)802.11の一
連のプロトコル、ブルートゥース(登録商標)および/またはその他の無線プロトコルのうちのいずれかのもとで動作するネットワーク)、および/またはこれらの任意の組合せ、および/または他のネットワークを含むが、これらに限定されるものではない。
【0136】
サーバ1912は、1つ以上の汎用コンピュータ、専用サーバコンピュータ(一例として、PC(パーソナルコンピュータ)サーバ、UNIX(登録商標)サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント式サーバなどを含む)、サーバファーム、サーバクラスタ、またはその他の適切な構成および/または組合せで構成され得る。サーバ1912は、仮想オペレーティングシステムを実行する1つ以上の仮想マシン、または仮想化を含む他のコンピューティングアーキテクチャを含み得る。論理記憶装置の1つ以上のフレキシブルプールは、サーバのための仮想記憶デバイスを維持するように仮想化することができる。仮想ネットワークは、ソフトウェア定義型ネットワーキングを用いて、サーバ1912によって制御することができる。さまざまな実施形態においては、サーバ1912は、上記の開示に記載されている1つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合され得る。たとえば、サーバ1912は、本開示の実施形態に係る上記の処理を実行するためのサーバに対応してもよい。
【0137】
サーバ1912は、上記のもののうちのいずれか、および、任意の市販のサーバオペレーティングシステムを含むオペレーティングシステムを実行し得る。また、サーバ1912は、HTTP(ハイパーテキスト転送プロトコル)サーバ、FTP(ファイル転送プロトコル)サーバ、CGI(共通ゲートウェイインターフェース)サーバ、JAVA(登録商標)サーバ、データベースサーバなどを含むさまざまな付加的サーバアプリケーションおよび/または中間層アプリケーションのうちのいずれかを実行し得る。例示的なデータベースサーバは、オラクル社(Oracle)、マイクロソフト社(Microsoft)、サイベース
社(Sybase)、IBM社(International Business Machines)などから市販されている
ものを含むが、これらに限定されるものではない。
【0138】
いくつかの実現例では、サーバ1912は、クライアントコンピューティングデバイス1902,1904,1906および1908のユーザから受信されたデータフィードおよび/またはイベント更新を分析および統合するための1つ以上のアプリケーションを含み得る。一例として、データフィードおよび/またはイベント更新は、1つ以上の第三者情報源および連続的なデータストリームから受信されるツイッター(登録商標)フィード、フェースブック(登録商標)更新またはリアルタイム更新を含み得るが、これらに限定されるものではなく、センサデータアプリケーション、金融ティッカ、ネットワーク性能測定ツール(たとえばネットワークモニタリングおよびトラフィック管理アプリケーション)、クリックストリーム分析ツール、自動車交通モニタリングなどに関連するリアルタイムイベントを含み得る。また、サーバ1912は、クライアントコンピューティングデバイス1902,1904,1906および1908の1つ以上の表示装置を介してデータフィードおよび/またはリアルタイムイベントを表示するための1つ以上のアプリケー
ションを含み得る。
【0139】
また、分散型システム1900は、1つ以上のデータベース1914および1916を含み得る。データベース1914および1916は、さまざまな場所に存在し得る。一例として、データベース1914および1916の1つ以上は、サーバ1912にローカルな(および/または存在する)非一時的な記憶媒体に存在していてもよい。代替的に、データベース1914および1916は、サーバ1912から遠く離れていて、ネットワークベースまたは専用の接続を介してサーバ1912と通信してもよい。一組の実施形態においては、データベース1914および1916は、記憶領域ネットワーク(storage-area network:SAN)に存在していてもよい。同様に、サーバ1912に起因する機能を実行するための任意の必要なファイルが、サーバ1912上にローカルに、および/または、リモートで適宜格納されていてもよい。一組の実施形態においては、データベース1914および1916は、SQLフォーマットコマンドに応答してデータを格納、更新および検索するように適合された、オラクル社によって提供されるデータベースなどのリレーショナルデータベースを含み得る。
【0140】
図20は、本開示の実施形態に係る、実施形態のシステムの1つ以上の構成要素によって提供されるサービスをクラウドサービスとして供給することができるシステム環境2000の1つ以上の構成要素の簡略化されたブロック図である。システム環境2000は、上述したように、電力不正検出システムの実施形態を含み得るかまたは実現し得る。示されている実施形態においては、システム環境2000は、クラウドサービスを提供するクラウドインフラストラクチャシステム2002と相互作用するようにユーザによって使用され得る1つ以上のクライアントコンピューティングデバイス2004,2006および2008を含む。クライアントコンピューティングデバイスは、クラウドインフラストラクチャシステム2002によって提供されるサービスを使用するためにクラウドインフラストラクチャシステム2002と相互作用するようにクライアントコンピューティングデバイスのユーザによって使用され得る、ウェブブラウザ、専有のクライアントアプリケーション(たとえばオラクルフォームズ)または他のアプリケーションなどのクライアントアプリケーションを動作させるように構成され得る。
【0141】
図20に示されているクラウドインフラストラクチャシステム2002が図示されている構成要素とは他の構成要素を有し得ることが理解されるべきである。さらに、
図20に示されている実施形態は、本発明の実施形態を組込むことができるクラウドインフラストラクチャシステムの一例に過ぎない。たとえば、クラウドインフラストラクチャシステム2002は、上述のように、電力不正検出システムのうちの1つ以上の要素を含み得るかまたは実現し得る。いくつかの他の実施形態においては、クラウドインフラストラクチャシステム2002は、
図20に示されているものよりも多いまたは少ない数の構成要素を有していてもよく、2つ以上の構成要素を組合せてもよく、または構成要素の異なる構成または配置を有していてもよい。
【0142】
クライアントコンピューティングデバイス2004,2006および2008は、1902,1904,1906および1908について上記したものと類似のデバイスであってもよい。
【0143】
例示的なシステム環境2000は3個のクライアントコンピューティングデバイスを有するように示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサなどを有する装置などの他の装置が、クラウドインフラストラクチャシステム2002と相互作用してもよい。
【0144】
ネットワーク2010は、クライアント2004,2006および2008とクラウド
インフラストラクチャシステム2002との間のデータの通信およびやりとりを容易にし得る。各々のネットワークは、ネットワーク1910について上記したものを含むさまざまな市販のプロトコルのうちのいずれかを用いてデータ通信をサポートすることができる、当業者になじみのある任意のタイプのネットワークであってもよい。
【0145】
クラウドインフラストラクチャシステム2002は、サーバ1912について上記したものを含み得る1つ以上のコンピュータおよび/またはサーバを備え得る。
【0146】
特定の実施形態においては、クラウドインフラストラクチャシステムによって提供されるサービスは、オンラインデータ記憶およびバックアップソリューション、ウェブベースのeメールサービス、ホスト型オフィススイートおよびドキュメントコラボレーションサービス、データベース処理、管理技術サポートサービスなどの、クラウドインフラストラクチャシステムのユーザがオンデマンドで利用可能な多数のサービスを含み得る。クラウドインフラストラクチャシステムによって提供されるサービスは、そのユーザのニーズを満たすように動的にスケーリング可能である。クラウドインフラストラクチャシステムによって提供されるサービスの具体的なインスタンス化は、本明細書では「サービスインスタンス」と称される。一般に、インターネットなどの通信ネットワークを介してクラウドサービスプロバイダのシステムからユーザが利用可能な任意のサービスは、「クラウドサービス」と称される。通常、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客自身のオンプレミスサーバおよびシステムとは異なっている。たとえば、クラウドサービスプロバイダのシステムがアプリケーションをホストしてもよく、ユーザは、インターネットなどの通信ネットワークを介してオンデマンドで当該アプリケーションを注文および使用してもよい。
【0147】
いくつかの例では、コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、ストレージ、ホスト型データベース、ホスト型ウェブサーバ、ソフトウェアアプリケーションへの保護されたコンピュータネットワークアクセス、またはクラウドベンダによってユーザに提供されるかもしくはそうでなければ当該技術分野において公知の他のサービスを含み得る。たとえば、サービスは、インターネットを介したクラウド上のリモートストレージへのパスワードによって保護されたアクセスを含み得る。別の例として、サービスは、ネットワーク化された開発者による私的使用のためのウェブサービスベースのホスト型リレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含み得る。別の例として、サービスは、クラウドベンダのウェブサイト上でホストされるeメールソフトウェアアプリケーションへのアクセスを含み得る。
【0148】
特定の実施形態においては、クラウドインフラストラクチャシステム2002は、セルフサービスの、サブスクリプションベースの、弾性的にスケーラブルな、信頼性のある、高可用性の、安全な態様で顧客に配信される一連のアプリケーション、ミドルウェアおよびデータベースサービス提供品を含み得る。このようなクラウドインフラストラクチャシステムの一例は、本譲受人によって提供されるオラクルパブリッククラウドである。
【0149】
時としてビッグデータとも称される大量のデータは、インフラストラクチャシステムによって、多数のレベルにおいて、および異なるスケールでホストおよび/または操作され得る。このようなデータが含み得るデータセットは、非常に大型で複雑であるので、典型的なデータベース管理ツールまたは従来のデータ処理アプリケーションを用いて処理するのが困難になる可能性がある。たとえば、テラバイトのデータはパーソナルコンピュータまたはそれらのラックベースの対応物を用いて格納、検索取得および処理することが難しいかもしれない。このようなサイズのデータは、最新のリレーショナルデータベース管理システムおよびデスクトップ統計ならびに視覚化パッケージを用いて機能させるのが困難である可能性がある。それらは、データを許容可能な経過時間内に捕捉しキュレーション
し管理し処理するよう、一般的に用いられるソフトウェアツールの構造を超えて、何千ものサーバコンピュータを動作させる大規模並列処理ソフトウェアを必要とし得る。
【0150】
大量のデータを視覚化し、トレンドを検出し、および/または、データと相互作用させるために、分析者および研究者は極めて大きいデータセットを格納し処理することができる。平行にリンクされた何十、何百または何千ものプロセッサがこのようなデータに対して作用可能であり、これにより、このようなデータを表示し得るか、または、データに対する外力をシミュレートし得るかもしくはそれが表しているものをシミュレートし得る。これらのデータセットは、データベースにおいて編制されたデータ、もしくは構造化モデルに従ったデータ、および/または、非体系的なデータ(たとえば電子メール、画像、データブロブ(バイナリ大型オブジェクト)、ウェブページ、複雑なイベント処理)などの構造化されたデータを必要とする可能性がある。目標物に対してより多くの(またはより少数の)コンピューティングリソースを比較的迅速に集中させるために実施形態の能力を強化することにより、ビジネス、政府関係機関、研究組織、私人、同じ目的をもった個々人もしくは組織のグループ、または他のエンティティからの要求に基づいて大量のデータセット上でタスクを実行するために、クラウドインフラストラクチャシステムがより良好に利用可能となる。
【0151】
さまざまな実施形態においては、クラウドインフラストラクチャシステム2002は、クラウドインフラストラクチャシステム2002によって供給されるサービスへの顧客のサブスクリプションを自動的にプロビジョニング、管理および追跡するように適合され得る。クラウドインフラストラクチャシステム2002は、さまざまなデプロイメントモデルを介してクラウドサービスを提供し得る。たとえば、クラウドインフラストラクチャシステム2002が、(たとえばオラクル社によって所有される)クラウドサービスを販売する組織によって所有され、一般大衆またはさまざまな産業企業がサービスを利用できるパブリッククラウドモデルのもとでサービスが提供されてもよい。別の例として、クラウドインフラストラクチャシステム2002が単一の組織のためだけに運営され、当該組織内の1つ以上のエンティティにサービスを提供し得るプライベートクラウドモデルのもとでサービスが提供されてもよい。また、クラウドインフラストラクチャシステム2002およびクラウドインフラストラクチャシステム2002によって提供されるサービスが、関連のコミュニティ内のいくつかの組織によって共有されるコミュニティクラウドモデルのもとでクラウドサービスが提供されてもよい。また、2つ以上の異なるモデルの組合せであるハイブリッドクラウドモデルのもとでクラウドサービスが提供されてもよい。
【0152】
いくつかの実施形態においては、クラウドインフラストラクチャシステム2002によって提供されるサービスは、ソフトウェア・アズ・ア・サービス(Software as a Service:SaaS)カテゴリ、プラットフォーム・アズ・ア・サービス(Platform as a Service:PaaS)カテゴリ、インフラストラクチャ・アズ・ア・サービス(Infrastructure
as a Service:IaaS)カテゴリ、またはハイブリッドサービスを含むサービスの他
のカテゴリのもとで提供される1つ以上のサービスを含み得る。顧客は、サブスクリプションオーダーによって、クラウドインフラストラクチャシステム2002によって提供される1つ以上のサービスを注文し得る。次いで、クラウドインフラストラクチャシステム2002は、顧客のサブスクリプションオーダーでサービスを提供するために処理を実行する。
【0153】
いくつかの実施形態においては、クラウドインフラストラクチャシステム2002によって提供されるサービスは、アプリケーションサービス、プラットフォームサービスおよびインフラストラクチャサービスを含み得るが、これらに限定されるものではない。いくつかの例では、アプリケーションサービスは、SaaSプラットフォームを介してクラウドインフラストラクチャシステムによって提供されてもよい。SaaSプラットフォーム
は、SaaSカテゴリに分類されるクラウドサービスを提供するように構成され得る。たとえば、SaaSプラットフォームは、一体化された開発およびデプロイメントプラットフォーム上で一連のオンデマンドアプリケーションを構築および配信するための機能を提供し得る。SaaSプラットフォームは、SaaSサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御し得る。SaaSプラットフォームによって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムで実行されるアプリケーションを利用することができる。顧客は、顧客が別々のライセンスおよびサポートを購入する必要なく、アプリケーションサービスを取得することができる。さまざまな異なるSaaSサービスが提供されてもよい。例としては、大規模組織のための販売実績管理、企業統合およびビジネスの柔軟性のためのソリューションを提供するサービスが挙げられるが、これらに限定されるものではない。
【0154】
いくつかの実施形態においては、プラットフォームサービスは、PaaSプラットフォームを介してクラウドインフラストラクチャシステムによって提供されてもよい。PaaSプラットフォームは、PaaSカテゴリに分類されるクラウドサービスを提供するように構成され得る。プラットフォームサービスの例としては、組織(オラクル社など)が既存のアプリケーションを共有の共通アーキテクチャ上で統合することを可能にするサービス、および、プラットフォームによって提供される共有のサービスを活用する新たなアプリケーションを構築する機能を挙げることができるが、これらに限定されるものではない。PaaSプラットフォームは、PaaSサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御し得る。顧客は、顧客が別々のライセンスおよびサポートを購入する必要なく、クラウドインフラストラクチャシステムによって提供されるPaaSサービスを取得することができる。プラットフォームサービスの例としては、オラクルJavaクラウドサービス(Java Cloud Service:JCS)、オラクルデータベースクラウドサービス(Database Cloud Service:DBCS)などが挙げられるが、これらに限定されるものではない。
【0155】
PaaSプラットフォームによって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムによってサポートされるプログラミング言語およびツールを利用することができ、デプロイされたサービスを制御することもできる。いくつかの実施形態においては、クラウドインフラストラクチャシステムによって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービル(たとえばオラクルフージョンミドルウェアサービス)およびJavaクラウドサービスを含み得る。一実施形態においては、データベースクラウドサービスは、組織がデータベースリソースをプールしてデータベースクラウドの形態でデータベース・アズ・ア・サービスを顧客に供給することを可能にする共有のサービスデプロイメントモデルをサポートし得る。ミドルウェアクラウドサービスは、クラウドインフラストラクチャシステムにおいてさまざまなビジネスアプリケーションを開発およびデプロイするために顧客にプラットフォームを提供し得るともに、Javaクラウドサービスは、クラウドインフラストラクチャシステムにおいてJavaアプリケーションをデプロイするために顧客にプラットフォームを提供し得る。
【0156】
さまざまな異なるインフラストラクチャサービスは、クラウドインフラストラクチャシステムにおけるIaaSプラットフォームによって提供されてもよい。インフラストラクチャサービスは、ストレージ、ネットワークなどの基本的な計算リソース、ならびに、SaaSプラットフォームおよびPaaSプラットフォームによって提供されるサービスを利用する顧客のための他の基礎的な計算リソースの管理および制御を容易にする。
【0157】
また、特定の実施形態においては、クラウドインフラストラクチャシステム2002は、クラウドインフラストラクチャシステムの顧客にさまざまなサービスを提供するために
使用されるリソースを提供するためのインフラストラクチャリソース2030を含み得る。一実施形態においては、インフラストラクチャリソース2030は、PaaSプラットフォームおよびSaaSプラットフォームによって提供されるサービスを実行するための、サーバ、ストレージおよびネットワーキングリソースなどのハードウェアの予め一体化された最適な組合せを含み得る。
【0158】
いくつかの実施形態においては、クラウドインフラストラクチャシステム2002におけるリソースは、複数のユーザによって共有され、デマンドごとに動的に再割り振りされてもよい。また、リソースは、異なる時間帯にユーザに割り振られてもよい。たとえば、クラウドインフラストラクチャシステム2030は、第1の時間帯におけるユーザの第1の組が規定の時間にわたってクラウドインフラストラクチャシステムのリソースを利用することを可能にし得るとともに、異なる時間帯に位置するユーザの別の組への同一のリソースの再割り振りを可能にし得ることによって、リソースの利用を最大化することができる。
【0159】
特定の実施形態においては、クラウドインフラストラクチャシステム2002のさまざまな構成要素またはモジュール、および、クラウドインフラストラクチャシステム2002によって提供されるサービス、によって共有されるいくつかの内部共有サービス2032が提供され得る。これらの内部共有サービスは、セキュリティおよびアイデンティティサービス、インテグレーションサービス、企業リポジトリサービス、企業マネージャサービス、ウイルススキャンおよびホワイトリストサービス、高可用性・バックアップおよび回復サービス、クラウドサポートを可能にするためのサービス、eメールサービス、通知サービス、ファイル転送サービスなどを含み得るが、これらに限定されるものではない。
【0160】
特定の実施形態においては、クラウドインフラストラクチャシステム2002は、クラウドインフラストラクチャシステムにおけるクラウドサービス(たとえばSaaSサービス、PaaSサービスおよびIaaSサービス)の包括的管理を提供し得る。一実施形態においては、クラウド管理機能は、クラウドインフラストラクチャシステム2002によって受信された顧客のサブスクリプションをプロビジョニング、管理および追跡などするための機能を含み得る。
【0161】
一実施形態においては、
図20に示されるように、クラウド管理機能は、オーダー管理モジュール2020、オーダーオーケストレーションモジュール2022、オーダープロビジョニングモジュール2024、オーダー管理および監視モジュール2026、ならびにアイデンティティ管理モジュール2028などの1つ以上のモジュールによって提供され得る。これらのモジュールは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、またはその他の適切な構成および/もしくは組み合わせであり得る1つ以上のコンピュータおよび/またはサーバを含み得るか、またはそれらを用いて提供され得る。
【0162】
例示的な動作2034において、クライアントデバイス2004,2006または2008などのクライアントデバイスを用いる顧客は、クラウドインフラストラクチャシステム2002によって提供される1つ以上のサービスを要求し、クラウドインフラストラクチャシステム2002によって供給される1つ以上のサービスのサブスクリプションについてオーダーを行うことによって、クラウドインフラストラクチャシステム2002と対話し得る。特定の実施形態においては、顧客は、クラウドユーザインターフェース(User
Interface:UI)、すなわちクラウドUI2012、クラウドUI2014および/またはクラウドUI2016にアクセスして、これらのUIを介してサブスクリプションオーダーを行い得る。顧客がオーダーを行ったことに応答してクラウドインフラストラクチャシステム2002によって受信されたオーダー情報は、顧客と、顧客がサブスクライブ
する予定のクラウドインフラストラクチャシステム2002によって提供される1つ以上のサービスとを特定する情報を含み得る。
【0163】
オーダーが顧客によって行われた後、オーダー情報は、クラウドUI2012,2014および/または2016を介して受信される。
【0164】
動作2036において、オーダーは、オーダーデータベース2018に格納される。オーダーデータベース2018は、クラウドインフラストラクチャシステム2018によって動作されるとともに他のシステム要素と連携して動作されるいくつかのデータベースのうちの1つであってもよい。
【0165】
動作2038において、オーダー情報は、オーダー管理モジュール2020に転送される。いくつかの例では、オーダー管理モジュール2020は、オーダーの確認および確認時のオーダーの予約などのオーダーに関連する請求書発行機能および会計経理機能を実行するように構成され得る。
【0166】
動作2040において、オーダーに関する情報は、オーダーオーケストレーションモジュール2022に通信される。オーダーオーケストレーションモジュール2022は、顧客によって行われたオーダーについてのサービスおよびリソースのプロビジョニングをオーケストレートするためにオーダー情報を利用し得る。いくつかの例では、オーダーオーケストレーションモジュール2022は、オーダープロビジョニングモジュール2024のサービスを用いてサブスクライブされたサービスをサポートするためにリソースのプロビジョニングをオーケストレートし得る。
【0167】
特定の実施形態においては、オーダーオーケストレーションモジュール2022は、各々のオーダーに関連付けられるビジネスプロセスの管理を可能にし、ビジネス論理を適用してオーダーがプロビジョニングに進むべきか否かを判断する。動作2042において、新たなサブスクリプションについてのオーダーを受信すると、オーダーオーケストレーションモジュール2022は、リソースを割り振って当該サブスクリプションオーダーを満たすのに必要とされるそれらのリソースを構成するための要求をオーダープロビジョニングモジュール2024に送る。オーダープロビジョニングモジュール2024は、顧客によってオーダーされたサービスについてのリソースの割り振りを可能にする。オーダープロビジョニングモジュール2024は、クラウドインフラストラクチャシステム2000によって提供されるクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理的実装層との間にあるレベルの抽象化を提供する。したがって、オーダーオーケストレーションモジュール2022は、サービスおよびリソースが実際に実行中にプロビジョニングされるか、事前にプロビジョニングされて要求があったときに割振られる/割当てられるのみであるかなどの実装の詳細から切り離すことができる。
【0168】
動作2044において、サービスおよびリソースがプロビジョニングされると、提供されたサービスの通知が、クラウドインフラストラクチャシステム2002のオーダープロビジョニングモジュール2024によってクライアントデバイス2004,2006および/または2008上の顧客に送られ得る。
【0169】
動作2046において、顧客のサブスクリプションオーダーが、オーダー管理および監視モジュール2026によって管理および追跡され得る。いくつかの例では、オーダー管理および監視モジュール2026は、使用される記憶量、転送されるデータ量、ユーザの数、ならびにシステムアップ時間およびシステムダウン時間などのサブスクリプションオーダーにおけるサービスについての使用統計を収集するように構成され得る。
【0170】
特定の実施形態においては、クラウドインフラストラクチャシステム2000は、アイデンティティ管理モジュール2028を含み得る。アイデンティティ管理モジュール2028は、クラウドインフラストラクチャシステム2000におけるアクセス管理および認可サービスなどのアイデンティティサービスを提供するように構成され得る。いくつかの実施形態においては、アイデンティティ管理モジュール2028は、クラウドインフラストラクチャシステム2002によって提供されるサービスを利用したい顧客についての情報を制御し得る。このような情報は、このような顧客のアイデンティティを認証する情報と、それらの顧客がさまざまなシステムリソース(たとえばファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど)に対してどのアクションを実行することを認可されるかを記載する情報とを含み得る。また、アイデンティティ管理モジュール2028は、各々の顧客についての説明的情報、ならびに、どのようにしておよび誰によってこの説明的情報がアクセスおよび変更され得るかについての情報の管理を含み得る。
【0171】
図21は、本発明のさまざまな実施形態を実現することができる例示的なコンピュータシステム2100を示す。システム2100は、上記のコンピュータシステムのうちのいずれかを実現するために使用され得る。たとえば、
図1に示される電力不正検出システムの要素のすべてまたはいくつかは、システム2100に含まれ得るかまたは実現され得る。
図21に示されているように、コンピュータシステム2100は、バスサブシステム2102を介していくつかの周辺サブシステムと通信する処理ユニット2104を含む。これらの周辺サブシステムは、処理加速ユニット2106と、I/Oサブシステム2108と、記憶サブシステム2118と、通信サブシステム2124とを含み得る。記憶サブシステム2118は、有形のコンピュータ読取可能な記憶媒体2122と、システムメモリ2110とを含む。
【0172】
バスサブシステム2102は、コンピュータシステム2100のさまざまな構成要素およびサブシステムに、意図されたように互いに通信させるための機構を提供する。バスサブシステム2102は、単一のバスとして概略的に示されているが、バスサブシステムの代替的な実施形態は、複数のバスを利用してもよい。バスサブシステム2102は、メモリバスまたはメモリコントローラ、周辺バス、およびさまざまなバスアーキテクチャのうちのいずれかを使用するローカルバスを含むいくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、このようなアーキテクチャは、IEEE P1386.1標準に合わせて製造されたメザニンバスとして実現可能な、業界標準アーキテクチャ(Industry Standard Architecture:ISA)バス、マイクロチャネルアーキテクチャ(Micro Channel Architecture:MCA)バス、拡張ISA(Enhanced ISA:EISA)バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション(Video Electronics Standards Association:VESA)ローカルバスおよび周辺機器相互接続(Peripheral Component Interconnect:PCI)バスを含み得る。
【0173】
1つ以上の集積回路(たとえば従来のマイクロプロセッサまたはマイクロコントローラ)として実現可能な処理ユニット2104は、コンピュータシステム2100の動作を制御する。処理ユニット2104には、1つ以上のプロセッサが含まれ得る。これらのプロセッサは、単一コアまたはマルチコアのプロセッサを含み得る。特定の実施形態においては、処理ユニット2104は、各々の処理ユニットに含まれる単一コアまたはマルチコアのプロセッサを有する1つ以上の独立した処理ユニット2132および/または2134として実現されてもよい。また、他の実施形態においては、処理ユニット2104は、2つのデュアルコアプロセッサを単一のチップに組み入れることによって形成されるクアッドコア処理ユニットとして実現されてもよい。
【0174】
さまざまな実施形態においては、処理ユニット2104は、プログラムコードに応答してさまざまなプログラムを実行し得るとともに、同時に実行される複数のプログラムまたはプロセスを維持し得る。任意の所与の時点において、実行されるべきプログラムコードのうちのいくつかまたは全ては、プロセッサ2104および/または記憶サブシステム2118に存在し得る。好適なプログラミングを通じて、プロセッサ2104は、上記のさまざまな機能を提供し得る。また、コンピュータシステム2100は、加えて、デジタル信号プロセッサ(digital signal processor:DSP)、特殊用途プロセッサなどを含み得る処理加速ユニット2106を含み得る。
【0175】
I/Oサブシステム2108は、ユーザインターフェイス入力装置と、ユーザインターフェイス出力装置とを含み得る。ユーザインターフェイス入力装置は、キーボード、マウスまたはトラックボールなどのポインティング装置、タッチパッドまたはタッチスクリーンを含んでいてもよく、これらは、音声コマンド認識システム、マイクロホンおよび他のタイプの入力装置とともに、ディスプレイ、スクロールホイール、クリックホイール、ダイアル、ボタン、スイッチ、キーパッド、オーディオ入力装置に組込まれている。ユーザインターフェイス入力装置は、たとえば、ジェスチャおよび話されたコマンドを用いてナチュラルユーザインターフェースを介してユーザがマイクロソフトXbox(登録商標)360ゲームコントローラなどの入力装置を制御して入力装置と対話することを可能にするマイクロソフトキネクト(登録商標)モーションセンサなどのモーション検知および/またはジェスチャ認識装置を含み得る。また、ユーザインターフェイス入力装置は、ユーザから眼球運動(たとえば撮影および/またはメニュー選択を行っている間の「まばたき」)を検出して、当該眼球ジェスチャを入力装置への入力として変換するグーグルグラス(登録商標)まばたき検出器などの眼球ジェスチャ認識装置を含み得る。また、ユーザインターフェイス入力装置は、ユーザが音声コマンドを介して音声認識システム(たとえばSiri(登録商標)ナビゲータ)と対話することを可能にする音声認識検知装置を含み得る。
【0176】
また、ユーザインターフェイス入力装置は、三次元(3D)マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、およびスピーカなどのオーディオ/ビジュアル装置、デジタルカメラ、デジタルカムコーダ、携帯型メディアプレーヤ、ウェブカム、画像スキャナ、指紋スキャナ、バーコードリーダ3Dスキャナ、3Dプリンタ、レーザレンジファインダ、および視線検出装置を含み得るが、これらに限定されるものではない。また、ユーザインターフェイス入力装置は、たとえば、コンピュータ断層撮影、磁気共鳴画像化、位置発光断層撮影、医療用超音波検査装置などの医療用画像化入力装置を含み得る。また、ユーザインターフェイス入力装置は、たとえばMIDIキーボード、デジタル楽器などのオーディオ入力装置を含み得る。
【0177】
ユーザインターフェイス出力装置は、ディスプレイサブシステム、表示灯、またはオーディオ出力装置などの非視覚的ディスプレイなどを含み得る。ディスプレイサブシステムは、陰極線管(cathode ray tube:CRT)、液晶ディスプレイ(liquid crystal display:LCD)またはプラズマディスプレイを使用するものなどのフラットパネルディスプレイ、投影装置、タッチスクリーンなどであってもよい。一般に、「出力装置」という用語の使用は、コンピュータシステム2100からの情報をユーザまたは他のコンピュータに出力するための全ての実現可能なタイプの装置および機構を含むよう意図されている。たとえば、ユーザインターフェイス出力装置は、モニタ、プリンタ、スピーカ、ヘッドホン、自動車のナビゲーションシステム、プロッタ、音声出力装置およびモデムなどの、テキスト、グラフィックスおよびオーディオ/ビデオ情報を視覚的に伝えるさまざまな表示装置を含み得るが、これらに限定されるものではない。
【0178】
コンピュータシステム2100は、現在のところシステムメモリ2110内に位置して
いるように示されているソフトウェア要素を備える記憶サブシステム2118を備え得る。システムメモリ2110は、処理ユニット2104上でロード可能および実行可能なプログラム命令と、これらのプログラムの実行中に生成されるデータとを格納し得る。
【0179】
コンピュータシステム2100の構成およびタイプに応じて、システムメモリ2110は、揮発性(ランダムアクセスメモリ(random access memory:RAM)など)であってもよく、および/または、不揮発性(リードオンリメモリ(read-only memory:ROM)、フラッシュメモリなど)であってもよい。RAMは、典型的には、処理ユニット2104が直ちにアクセス可能なデータおよび/またはプログラムモジュール、および/または、処理ユニット2104によって現在動作および実行されているデータおよび/またはプログラムモジュールを収容する。いくつかの実現例では、システムメモリ2110は、スタティックランダムアクセスメモリ(static random access memory:SRAM)または
ダイナミックランダムアクセスメモリ(dynamic random access memory:DRAM)などの複数の異なるタイプのメモリを含み得る。いくつかの実現例では、始動中などにコンピュータシステム2100内の要素間で情報を転送することを助ける基本ルーチンを含む基本入力/出力システム(basic input/output system:BIOS)が、典型的にはROM
に格納され得る。一例としておよび非限定的に、システムメモリ2110は、クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、リレーショナルデータベース管理システム(relational database management system:RDBMS)などを含
み得るアプリケーションプログラム2112、プログラムデータ2114およびオペレーティングシステム2116も示す。一例として、オペレーティングシステム2116は、マイクロソフトウィンドウズ(登録商標)、アップルマッキントッシュ(登録商標)および/もしくはリナックスオペレーティングシステムのさまざまなバージョン、さまざまな市販のUNIX(登録商標)もしくはUNIXライクオペレーティングシステム(さまざまなGNU/リナックスオペレーティングシステム、Google Chrome(登録商標)OSなどを含むが、これらに限定されるものではない)、ならびに/または、iOS、ウィンドウズ(登録商標)フォン、アンドロイド(登録商標)OS、ブラックベリー(登録商標)10OSおよびパーム(登録商標)OSオペレーティングシステムなどのモバイルオペレーティングシステムを含み得る。
【0180】
また、記憶サブシステム2118は、いくつかの実施形態の機能を提供する基本的なプログラミングおよびデータ構造を格納するための有形のコンピュータ読取可能な記憶媒体を提供し得る。プロセッサによって実行されたときに上記の機能を提供するソフトウェア(プログラム、コードモジュール、命令)が記憶サブシステム2118に格納され得る。これらのソフトウェアモジュールまたは命令は、処理ユニット2104によって実行され得る。また、記憶サブシステム2118は、本発明に従って使用されるデータを格納するためのリポジトリを提供し得る。
【0181】
また、記憶サブシステム2100は、コンピュータ読取可能な記憶媒体2122にさらに接続可能なコンピュータ読取可能な記憶媒体リーダ2120を含み得る。ともにおよび任意には、システムメモリ2110と組合せて、コンピュータ読取可能な記憶媒体2122は、コンピュータ読取可能な情報を一時的および/または永久に収容、格納、送信および検索するための記憶媒体に加えて、リモートの、ローカルの、固定されたおよび/または取外し可能な記憶装置を包括的に表わし得る。
【0182】
コードまたはコードの一部を含むコンピュータ読取可能な記憶媒体2122は、当該技術分野において公知のまたは使用される任意の適切な媒体を含み得る。当該媒体は、情報の格納および/または送信のための任意の方法または技術において実現される揮発性および不揮発性の、取外し可能および取外し不可能な媒体などであるが、これらに限定されるものではない記憶媒体および通信媒体を含む。これは、RAM、ROM、電子的消去・プ
ログラム可能ROM(electronically erasable programmable ROM:EEPROM)、フラッシュメモリもしくは他のメモリ技術、CD-ROM、デジタル多用途ディスク(digital versatile disk:DVD)、または他の光学式記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、または他の有形のコンピュータ読取可能な媒体などの有形の一時的なコンピュータ読取可能な記憶媒体を含み得る。また、これは、データ信号、データ送信などの無形の一時的なコンピュータ読取可能な媒体、または、所望の情報を送信するために使用可能であるとともに計算システム400によってアクセス可能である他の任意の媒体を含み得る。
【0183】
一例として、コンピュータ読取可能な記憶媒体2122は、取外し不可能な不揮発性磁気媒体から読取るまたは当該媒体に書込むハードディスクドライブ、取外し可能な不揮発性磁気ディスクから読取るまたは当該ディスクに書込む磁気ディスクドライブ、ならびに、CD ROM、DVDおよびブルーレイ(登録商標)ディスクまたは他の光学式媒体などの取外し可能な不揮発性光学ディスクから読取るまたは当該ディスクに書込む光学式ディスクドライブを含み得る。コンピュータ読取可能な記憶媒体2122は、ジップ(登録商標)ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス(universal serial bus:USB)フラッシュドライブ、セキュアデジタル(secure digital:SD)カード、DVDディスク、デジタルビデオテープなどを含み得るが、これらに限定されるものではない。また、コンピュータ読取可能な記憶媒体2122は、フラッシュメモリベースのSSD、企業向けフラッシュドライブ、ソリッドステートROMなどの不揮発性メモリに基づくソリッドステートドライブ(solid-state drive:SSD)、ソリッドステート
RAM、ダイナミックRAM、スタティックRAMなどの揮発性メモリに基づくSSD、DRAMベースのSSD、磁気抵抗RAM(magnetoresistive RAM:MRAM)SSD、およびDRAMとフラッシュメモリベースのSSDとの組合せを使用するハイブリッドSSDを含み得る。ディスクドライブおよびそれらの関連のコンピュータ読取可能な媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュールおよび他のデータをコンピュータシステム2100に提供し得る。
【0184】
通信サブシステム2124は、他のコンピュータシステムおよびネットワークとのインターフェイスを提供する。通信サブシステム2124は、他のシステムからデータを受信したり、コンピュータシステム2100から他のシステムにデータを送信するためのインターフェイスの役割を果たす。たとえば、通信サブシステム2124は、コンピュータシステム2100がインターネットを介して1つ以上の装置に接続することを可能にし得る。いくつかの実施形態においては、通信サブシステム2124は、(たとえば3G、4GまたはEDGE(enhanced data rates for global evolution)などの携帯電話技術、高度データネットワーク技術を用いて)無線音声および/またはデータネットワークにアクセスするための無線周波数(radio frequency:RF)トランシーバコンポーネント、W
iFi(IEEE1902.11ファミリ標準または他のモバイル通信技術またはそれらの任意の組合せ)、全地球測位システム(global positioning system:GPS)レシー
バコンポーネント、および/または、他のコンポーネントを含み得る。いくつかの実施形態においては、通信サブシステム2124は、無線インターフェイスに加えて、または無線インターフェイスの代わりに、有線ネットワーク接続(例えばイーサネット)を提供し得る。
【0185】
また、いくつかの実施形態においては、通信サブシステム2124は、コンピュータシステム2100を使用し得る1人以上のユーザを代表して、構造化されたおよび/または構造化されていないデータフィード2126、イベントストリーム2128、イベント更新2130などの形態で入力通信を受信し得る。
【0186】
一例として、通信サブシステム2124は、ツイッター(登録商標)フィード、フェー
スブック(登録商標)更新、リッチ・サイト・サマリ(Rich Site Summary:RSS)フ
ィードなどのウェブフィードなどのデータフィード2126をリアルタイムでソーシャルメディアネットワークおよび/または他の通信サービスのユーザから受信し、および/または、1つ以上の第三者情報源からリアルタイム更新を受信するように構成され得る。
【0187】
加えて、通信サブシステム2124は、連続的なデータストリームの形態でデータを受信するように構成され得る。当該データは、連続的である場合もあれば本質的に明確な端部をもたない状態で境界がない場合もあるリアルタイムイベントのイベントストリーム2128および/またはイベント更新2130を含み得る。連続的なデータを生成するアプリケーションの例としては、たとえばセンサデータアプリケーション、金融ティッカ、ネットワーク性能測定ツール(たとえばネットワークモニタリングおよびトラフィック管理アプリケーション)、クリックストリーム分析ツール、自動車交通モニタリングなどを含み得る。
【0188】
また、通信サブシステム2124は、構造化されたおよび/または構造化されていないデータフィード2126、イベントストリーム2128、イベント更新2130などを、コンピュータシステム2100に結合された1つ以上のストリーミングデータソースコンピュータと通信し得る1つ以上のデータベースに出力するように構成され得る。
【0189】
コンピュータシステム2100は、手持ち式携帯機器(たとえばiPhone(登録商標)携帯電話、iPad(登録商標)計算タブレット、PDA)、ウェアラブル装置(たとえばグーグルグラス(登録商標)ヘッドマウントディスプレイ)、PC、ワークステーション、メインフレーム、キオスク、サーバラックまたはその他のデータ処理システムを含むさまざまなタイプのうちの1つであってもよい。
【0190】
コンピュータおよびネットワークの絶え間なく変化し続ける性質のために、
図21に示されているコンピュータシステム2100の説明は、特定の例として意図されているに過ぎない。
図21に示されているシステムよりも多くのまたは少ない数の構成要素を有する多くの他の構成が可能である。たとえば、ハードウェア、ファームウェア、(アプレットを含む)ソフトウェア、または組合せにおいて、カスタマイズされたハードウェアが使用されてもよく、および/または、特定の要素が実装されてもよい。さらに、ネットワーク入力/出力装置などの他のコンピューティングデバイスへの接続が利用されてもよい。本明細書中に提供される開示および教示に基づいて、当業者は、さまざまな実施形態を実現するための他の手段および/または方法を理解するであろう。
【0191】
上述の明細書では、本発明の局面は、その具体的な実施形態を参照して記載されているが、本発明はこれに限定されるものではないことを当業者は認識するであろう。上述の発明のさまざまな特徴および局面は、個々にまたは一緒に使用されてもよい。さらに、実施形態は、明細書のより広い精神および範囲から逸脱することなく、本明細書に記載されているものを越えたいくつもの環境およびアプリケーションでも利用可能である。したがって、明細書および図面は、限定的ではなく例示的なものとみなされるべきである。
【手続補正書】
【提出日】2022-12-13
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
電力不正を検出するためのコンピューティングシステムであって、
1つ以上のプロセッサと、
複数の命令が格納されたメモリとを含み、前記複数の命令は、前記1つ以上のプロセッサによって実行されると、前記1つ以上のプロセッサに、
疑わしい既知の事例のセットおよび説明済みの既知の事例のセットを用いて、それぞれ、検出器モデルおよび説明モデルを検証させる命令を含み、前記疑わしい既知の事例のセットは不正に関連付けられた既知の事例を含み、前記不正に関連付けられた既知の事例は各々、前記検出器モデルを用いて識別された複数の疑わしいアクティビティのうち1つの疑わしいアクティビティを含み、前記説明済みの既知の事例のセットは、各々が、関連付けられた疑わしいアクティビティについての複数の正当な説明のうちの1つの正当な説明を有するとともに前記説明モデルを用いて識別される前記疑わしい既知の事例のサブセットであり、前記複数の命令はさらに、
未知の事例を含むデータアイテムに前記検出器モデルを適用して、疑わしい未知の事例のセットを生成させる命令を含み、前記データアイテムの各々は、それぞれのサービスポイントでそれぞれの電力メータに関連付けられた電力需要データを含み、前記疑わしい未知の事例のセットは、前記複数の疑わしいアクティビティのうちの1つの疑わしいアクティビティを含み、前記複数の命令はさらに、
前記疑わしい未知の事例のセットにおける前記未知の事例の各々に前記説明モデルを適用して、説明済みの未知の事例のセットを生成させる命令を含み、前記説明済みの未知の事例の各々は、前記関連付けられた疑わしいアクティビティについての前記複数の正当な説明のうちの1つの正当な説明を含み、前記複数の命令はさらに、
前記疑わしい未知の事例のセットから前記説明済みの未知の事例のセットを除去して、未説明の未知の事例のセットを生成させる命令を含む、コンピューティングシステム。
【請求項2】
未知の事例を含む前記データアイテムに前記検出器モデルを適用して前記疑わしい未知の事例のセットを生成させる命令はさらに、前記1つ以上のプロセッサによって実行されると、前記1つ以上のプロセッサに、
前記データアイテムを用いて各々の未知の事例ごとに需要プロフィールを計算させる命令と、
各々の未知の事例ごとに前記需要プロフィールに前記検出器モデルを適用させる命令とを含む、請求項1に記載のコンピューティングシステム。
【請求項3】
前記複数の疑わしいアクティビティは、突然低下した後に低いままとどまる需要、緩やかに低下した後に低いままとどまる需要、長期間にわたって緩やかに低下する需要、低い需要、異常に一定である需要、または、予想外に変化する需要のうちの少なくとも1つを含む、請求項1または2に記載のコンピューティングシステム。
【請求項4】
前記複数の正当な説明は、顧客による太陽電池パネルの使用、機器の故障、グリッド過負荷、電力会社の停止、それぞれの敷地における居住者の変化、極端な気候、および、顧客による発電機の使用のうちの少なくとも1つを含む、請求項1~3のいずれか1項に記載のコンピューティングシステム。
【請求項5】
前記メモリにはさらに、前記1つ以上のプロセッサによって実行されると、前記1つ以上のプロセッサに、
調査のために前記未説明の未知の事例のセットの前記未説明の未知の事例のうちの少なくとも1つを含む通知を送信させる命令が格納されている、請求項1~4のいずれか1項に記載のコンピューティングシステム。
【請求項6】
前記複数の疑わしいアクティビティは低い需要を含み、低い需要は、複数の顧客にわたる需要に基づいてしきい値百分率よりも低いものとして規定される、請求項1または2に記載のコンピューティングシステム。
【請求項7】
前記複数の疑わしいアクティビティは低い需要を含み、低い需要は、それぞれの敷地における電力使用の対価のバランスを取るように構成されたアルゴリズムに基づいて自動的に設定されるしきい値よりも低いものとして規定される、請求項1または2に記載のコンピューティングシステム。
【請求項8】
前記メモリにはさらに、前記1つ以上のプロセッサによって実行されると、前記1つ以上のプロセッサに、
前記データアイテムを用いて各々の未知の事例ごとに需要プロフィールを計算させる命令と、
各々の未知の事例ごとに前記需要プロフィールをランク付けさせる命令とが格納されている、請求項1~7のいずれか1項に記載のコンピューティングシステム。
【請求項9】
前記メモリにはさらに、前記1つ以上のプロセッサによって実行されると、前記1つ以上のプロセッサに、
外部データソースを用いて前記複数の正当な説明のうちの1つ以上の正当な説明を生成させる命令が格納されている、請求項1~8のいずれか1項に記載のコンピューティングシステム。
【請求項10】
電力不正を検出するための、コンピュータによって実現される方法であって、
疑わしい既知の事例のセットおよび説明済みの既知の事例のセットを用いて、それぞれ、検出器モデルおよび説明モデルを検証するステップを含み、前記疑わしい既知の事例のセットは不正に関連付けられた既知の事例を含み、前記不正に関連付けられた既知の事例は各々、前記検出器モデルを用いて識別された複数の疑わしいアクティビティのうち1つの疑わしいアクティビティを含み、前記説明済みの既知の事例のセットは、各々が、関連付けられた疑わしいアクティビティについての複数の正当な説明のうちの1つの正当な説明を有するとともに前記説明モデルを用いて識別される前記疑わしい既知の事例のサブセットであり、前記方法はさらに、
未知の事例を含むデータアイテムに前記検出器モデルを適用して、疑わしい未知の事例のセットを生成するステップを含み、前記データアイテムの各々は、それぞれのサービスポイントでそれぞれの電力メータに関連付けられた電力需要データを含み、前記疑わしい未知の事例のセットは、前記複数の疑わしいアクティビティのうちの1つの疑わしいアクティビティを含み、前記方法はさらに、
前記疑わしい未知の事例のセットにおける前記未知の事例の各々に前記説明モデルを適用して、説明済みの未知の事例のセットを生成するステップを含み、前記説明済みの未知の事例の各々は、前記関連付けられた疑わしいアクティビティについての前記複数の正当な説明のうちの1つの正当な説明を含み、前記方法はさらに、
前記疑わしい未知の事例のセットから前記説明済みの未知の事例のセットを除去して、未説明の未知の事例のセットを生成するステップを含む、コンピュータによって実現される方法。
【請求項11】
未知の事例を含む前記データアイテムに前記検出器モデルを適用するステップは、
前記データアイテムを用いて各々の未知の事例ごとに需要プロフィールを計算するステップと、
各々の未知の事例ごとに前記需要プロフィールに前記検出器モデルを適用するステップとを含む、請求項10に記載の、コンピュータによって実現される方法。
【請求項12】
前記複数の疑わしいアクティビティは、突然低下した後に低いままとどまる需要、緩やかに低下した後に低いままとどまる需要、長期間にわたって緩やかに低下する需要、低い需要、異常に一定である需要、または、予想外に変化する需要のうちの少なくとも1つを含む、請求項10または11に記載の、コンピュータによって実現される方法。
【請求項13】
前記複数の正当な説明は、顧客による太陽電池パネルの使用、機器の故障、グリッド過負荷、電力会社の停止、それぞれの敷地における居住者の変化、極端な気候、および、顧客による発電機の使用のうちの少なくとも1つを含む、請求項10~12のいずれか1項に記載の、コンピュータによって実現される方法。
【請求項14】
調査のために前記未説明の未知の事例のセットの前記未説明の未知の事例のうちの少なくとも1つを含む通知を送信するステップをさらに含む、請求項10~13のいずれか1項に記載の、コンピュータによって実現される方法。
【請求項15】
前記複数の疑わしいアクティビティは低い需要を含み、低い需要は、複数の顧客にわたる需要に基づいてしきい値百分率よりも低いものとして規定される、請求項10または11に記載の、コンピュータによって実現される方法。
【請求項16】
前記複数の疑わしいアクティビティは低い需要を含み、低い需要は、それぞれの敷地における電力使用の対価のバランスを取るように構成されたアルゴリズムに基づいて自動的に設定されるしきい値よりも低いものとして規定される、請求項10または11に記載の、コンピュータによって実現される方法。
【請求項17】
前記データアイテムを用いて各々の未知の事例ごとに需要プロフィールを計算するステップと、
各々の未知の事例ごとに前記需要プロフィールをランク付けするステップとをさらに含む、請求項10~16のいずれか1項に記載の、コンピュータによって実現される方法。
【請求項18】
外部データソースを用いて前記複数の正当な説明のうちの1つ以上の正当な説明を生成するステップをさらに含む、請求項10~17のいずれか1項に記載の、コンピュータによって実現される方法。
【請求項19】
1以上のプロセッサに請求項10~18のいずれか1項に記載の方法を実行させるプログラム。
【外国語明細書】