(57)【要約】【課題】ルール処理を行うサーバの処理量の負荷を軽減することを目的とする。【解決手段】判定対象となるデータの種類毎に判定値が示された条件が複数設定されたルールを用いて、前記判定対象となるデータに対して前記ルールに設定された複数の条件のすべてが成立するか否かを判定する処理をコンピュータに実行させるための判定処理制御プログラムであって、判定したデータの前記複数の条件のそれぞれの通過率に基づき、前記複数の条件から前記判定対象となるデータに対して最初に判定する条件を選択し、選択した前記条件と他の条件とを組合せた場合の複数の組合せ条件のそれぞれの通過率に基づき、前記複数の条件から前記判定対象となるデータに対して次に判定する条件を選択する、判定処理制御プログラムが提供される。【選択図】図４
2017228119.tif 000002
【特許請求の範囲】
【請求項１】
判定対象となるデータの種類毎に判定値が示された条件が複数設定されたルールを用いて、前記判定対象となるデータに対して前記ルールに設定された複数の条件のすべてが成立するか否かを判定する処理をコンピュータに実行させるための判定処理制御プログラムであって、
判定したデータの前記複数の条件のそれぞれの通過率に基づき、前記複数の条件から前記判定対象となるデータに対して最初に判定する条件を選択し、
選択した前記条件と他の条件とを組合せた場合の複数の組合せ条件のそれぞれの通過率に基づき、前記複数の条件から前記判定対象となるデータに対して次に判定する条件を選択する、
判定処理制御プログラム。
【請求項２】
前記ルールに設定された複数の条件のうち、前記通過率に基づき選択された前記最初に判定する条件を前記ルール内の先頭に配置し、前記次に判定する条件を前記ルール内の先頭の条件の次に配置し、以前に選択した組合せ条件と他の条件とを組合せた場合の複数の組合せ条件のそれぞれの通過率に基づき選択された次に判定する条件を順に配置することを、前記ルールに設定された複数の条件がすべて配置されるまで繰り返して前記ルールに含まれる複数の条件の判定順序を設定し、
全てのルール間にて重複した同一条件が含まれる場合、前記同一条件の判定順を該同一条件が含まれるルール内の未判定状態の条件の先頭に配置し、
前記重複した同一条件のいずれかを前記最初に判定する条件として選択する、
請求項１に記載の判定処理制御プログラム。
【請求項３】
選択した前記条件の判定の結果による条件の成立状態の変化に応じて、前記ルールに含まれる複数の条件の判定順序を再設定する、
請求項１又は２に記載の判定処理制御プログラム。
【請求項４】
前記条件の成立状態が判定中状態から成立中状態に変化したことに応じて、前記複数の条件のそれぞれの通過率及び前記複数の組合せ条件のそれぞれの通過率に基づき前記ルールに含まれる複数の条件の判定順序を再設定する、
請求項３に記載の判定処理制御プログラム。
【請求項５】
前記複数の条件のそれぞれの通過率、前記複数の組合せ条件のそれぞれの通過率、前記同一条件の重複数及び単位時間当たりの判定コスト期待値指数に基づき判定コスト期待値を算出し、
算出した前記判定コスト期待値に基づき、前記ルールに含まれる複数の条件の判定順序を設定する、
請求項２に記載の判定処理制御プログラム。
【請求項６】
前記複数の条件のそれぞれの通過率は、前記判定したデータに対して前記複数の条件のそれぞれについて各条件が成立した割合を示し、
前記複数の組合せ条件のそれぞれの通過率は、前記判定したデータに対して前記複数の組合せ条件のそれぞれについて各組合せ条件に含まれるすべての条件が成立した割合を示す、
請求項１〜５のいずれか一方に記載の判定処理制御プログラム。
【請求項７】
判定対象となるデータの種類毎に判定値が示された条件が複数設定されたルールを用いて、前記判定対象となるデータに対して前記ルールに設定された複数の条件のすべてが成立するか否かを判定する処理をコンピュータに実行させるための判定処理制御方法であって、
判定したデータの前記複数の条件のそれぞれの通過率に基づき、前記複数の条件から前記判定対象となるデータに対して最初に判定する条件を選択し、
選択した前記条件と他の条件とを組合せた場合の複数の組合せ条件のそれぞれの通過率に基づき、前記複数の条件から前記判定対象となるデータに対して次に判定する条件を選択する、
処理をコンピュータが実行する判定処理制御方法。
【請求項８】
判定対象となるデータの種類毎に判定値が示された条件が複数設定されたルールを用いて、前記判定対象となるデータに対して前記ルールに設定された複数の条件のすべてが成立するか否かを判定する判定処理制御装置であって、
判定したデータの前記複数の条件のそれぞれの通過率に基づき、前記複数の条件から前記判定対象となるデータに対して最初に判定する条件を選択し、選択した前記条件と他の条件とを組合せた場合の複数の組合せ条件のそれぞれの通過率に基づき、前記複数の条件から前記判定対象となるデータに対して次に判定する条件を選択する条件判定順制御部を有する、
判定処理制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、判定処理制御プログラム、判定処理制御方法及び判定処理制御装置に関する。
【背景技術】
【０００２】
各家庭の家具、家電、携帯端末、スマートフォン等から発生するセンサデータや、ＳＮＳ（Social Networking Service）、気象、交通といったＷｅｂデータ等のビッグデータから、ユーザが欲しい情報を抽出する技術が知られている。
【０００３】
ユーザが欲しい情報は、ユーザ毎の「ルール」に定義される。ルールに基づきユーザ毎に異なる嗜好や状態に合わせて情報配信や家電制御などを行う処理を「ルール処理」と称する。ルール処理はサーバにより実行される。サーバは、ルールで定義される条件セット内の全条件が成立するか否かを判定し、全条件が成立した場合、その判定結果をＨＧＷ（ホームゲートウェイ）に通知する。ＨＧＷは、各家庭に設置され、家庭内の家電又は家具などのデバイスと連動するため、ルール処理の条件成立（例えば、晴れで３０℃以上）が成立すると、エアコンを作動させること等が可能になる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−２０６５６９号公報
【特許文献１】特開２０１１−９５８１３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記ルール処理では、全条件のうちの１つでも条件が成立しない間、他の条件が成立していたとしてもＨＧＷへの通知は行われない。よって、全条件のうちの１つでも条件が成立しない間、他の条件の判定処理を行っても無駄な処理となる。
【０００６】
そこで、一側面では、本発明は、ルール処理を行うサーバの処理量の負荷を軽減することを目的とする。
【課題を解決するための手段】
【０００７】
一つの案では、判定対象となるデータの種類毎に判定値が示された条件が複数設定されたルールを用いて、前記判定対象となるデータに対して前記ルールに設定された複数の条件のすべてが成立するか否かを判定する処理をコンピュータに実行させるための判定処理制御プログラムであって、判定したデータの前記複数の条件のそれぞれの通過率に基づき、前記複数の条件から前記判定対象となるデータに対して最初に判定する条件を選択し、選択した前記条件と他の条件とを組合せた場合の複数の組合せ条件のそれぞれの通過率に基づき、前記複数の条件から前記判定対象となるデータに対して次に判定する条件を選択する、判定処理制御プログラムが提供される。
【発明の効果】
【０００８】
一側面によれば、ルール処理を行うサーバの処理量の負荷を軽減することができる。
【図面の簡単な説明】
【０００９】
【図１】ルールの一例を示す図。
【図２】一実施形態に係るルール処理と判定結果の利用例を示す図。
【図３】一実施形態に係る条件判定の一例を示す図。
【図４】一実施形態に係る判定処理制御システムの一例を示す図。
【図５】一実施形態に係る全条件テーブルの一例を示す図。
【図６】一実施形態に係る条件タイプテーブルの一例を示す図。
【図７】一実施形態に係るデータ種テーブルの一例を示す図。
【図８】一実施形態に係る条件組合せ通過率テーブルの一例を示す図。
【図９】一実施形態に係る管理サーバのハードウェア構成の一例を示す図。
【図１０】一実施形態に係る条件の判定状態の遷移図。
【図１１】第１実施形態に係るルール判定順設定処理の一例を示すフローチャート。
【図１２】第１実施形態に係るルール判定順に応じたルール処理を説明するための図。
【図１３】第１実施形態に係るルール処理の一例を示すフローチャート。
【図１４】第２実施形態に係るルール処理の一例を示すフローチャート。
【図１５】第２実施形態に係るルール判定順に応じたルール処理を説明するための図。
【図１６】第２実施形態に係るルール判定順に応じたルール処理を説明するための図。
【図１７】第３実施形態に係るルール判定順設定処理の一例を示すフローチャート。
【図１８】第３実施形態に係る判定コスト期待値を説明するための図。
【発明を実施するための形態】
【００１０】
以下、本発明の実施形態について添付の図面を参照しながら説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複した説明を省く。
【００１１】
［はじめに］
近年大規模化するビッグデータを活用し、価値ある情報を抽出する技術が期待されている。この技術では、ビッグデータからユーザが要望する情報を抽出し、ユーザに提供する。ユーザが欲しい情報は、ユーザ毎の「ルール」に定義される。
【００１２】
図１にルールの一例を示す。ルールは、条件とアクションから成る。条件には、対象とするデータの種類（例：室温）と、その値や範囲（例：２８℃以上）とが指定される。アクションには、条件が成立した場合の処理内容が示される。
【００１３】
例えば、ルールが「天気が雨、かつ予定経路（運行情報）に遅延があるならば、メールにて通知する」であるとき、「天気」及び「運行情報」は、データの種類を示す。図１のルールＲは、２つの条件セットから定義される。条件Ａでは、天気のデータ種に対する判定値が「天気が雨」に設定され、条件Ｂでは、運行情報のデータ種に対する判定値が「予定経路に遅延」に設定される。このように、１つのルールに複数条件を指定することができる。
【００１４】
サーバは、入力される天気情報が条件Ａの判定値を満たすか否かを判定し、入力される運行情報が条件Ｂの判定値を満たすか否かを判定する。サーバは、判定の結果、条件Ａ及び条件Ｂの両方の条件が成立した場合、アクションを実行する。この例では、アクションは、「メールを通知する」である。
【００１５】
図２に、一実施形態に係るルール処理と判定結果の利用例を示す。処理サーバ５０が実行するルール処理の対象となる条件セットは、ＨＧＷ２０の所有者であるユーザが登録したルールの条件であり、複数の条件を設定できる。また、条件セットは、ユーザ毎のルールとして登録される。
【００１６】
処理サーバ５０は、天気情報や交通情報といったＷｅｂデータを入力し、入力データが各ルールに定義された条件を満たすか否かを判定する「ルール処理」を実行する。ルールは、管理サーバ１０により管理される。
【００１７】
処理サーバ５０は、ルールに定義される複数の条件のそれぞれに対して判定を行い、全条件が成立したら判定結果をＨＧＷ２０に通知する。つまり、一つでも条件が成立しない場合は判定結果はＨＧＷ２０に通知されない。
【００１８】
ＨＧＷ２０は、各家庭の宅内３０に設置されている。ＨＧＷ２０は、宅内３０の家電又は家具などのデバイスと接続されている。また、ＨＧＷ２０は、インターネット等のネットワーク４０を介して管理サーバ１０に接続され、各種データを中継する。ＨＧＷ２０は、家庭内の家電又は家具などのデバイスと連動するため、ルール処理の条件成立（例えば、晴れで３０℃以上）が成立すると、エアコンを作動させること等が可能になる。
【００１９】
なお、本実施形態において判定対象となるデータの一例としては、携帯端末、スマートフォン等から発生するデータや、ＳＮＳ（social networking service）、気象、交通といったＷｅｂデータ等のネットワーク４０を介して取得可能なデータが挙げられる。本実施形態では、宅内３０の家電や家具などのデバイスから発生するデータは、判定対象のデータから除外される。
【００２０】
処理サーバ５０は、ルール処理において全条件のうちの１つでも条件が成立しない間、他の条件が成立していたとしてもＨＧＷへの通知等のアクションは行わない。つまり、全条件のうちの１つでも条件が成立しない間、他の条件の判定結果に関係なく、結果は変わらない（アクションは出力しない）。よって、ルール処理において全条件のうちの１つでも条件が成立しない間、処理サーバ５０が他の条件の判定処理を行っても無駄な処理となってしまう。
【００２１】
例えば、図３に示すように、条件Ａ、Ｂ、Ｃの条件セットをもつルールＲについて、処理サーバ５０が、条件Ａの判定→条件Ｂの判定→条件Ａの判定→条件Ｃの判定→条件Ａの判定の順に条件判定を実行したとする。この場合、判定の途中で実行された条件Ａが不成立の間、処理サーバ５０は、他の条件を判定しても、アクションは出力されず、無駄な判定処理となる。アクションを出力するタイミングは、最後の条件Ａが成立したと判定されたときであり、このタイミングの判定だけが有効な判定機関となる。
【００２２】
処理サーバ５０は、ルール処理において多種多用なデータを入力して、ユーザ毎に定義されたルール内の条件の判定を行う。よって、全てのルール処理を処理サーバ５０上で行うと、処理が破綻したり、処理サーバ５０の利用のための金銭的コストが増大したりする場合がある。そこで、以下に説明する第１〜第３実施形態では、不成立の可能性の高い条件を優先して判定する制御を行うことで、処理サーバ５０の処理量の負荷を軽減する判定処理制御方法を提案する。
【００２３】
［判定処理制御システムの構成］
まず、本発明の一実施形態に係る判定処理制御システム１の構成について、図４を参照しながら説明する。図４は、本実施形態に係る判定処理制御システム１の一例を示す。判定処理制御システム１は、管理サーバ１０、ＨＧＷ２０及び処理サーバ５０を有する。管理サーバ１０と処理サーバ５０とは、イントラネットで接続されている。管理サーバ１０及び処理サーバ５０と複数のＨＧＷ２０とは、ＧＷ（ゲートウェイ）４５及びネットワーク４０を介して接続されている。ここでは、２つのＨＧＷ２０が示されているが、ＨＧＷ２０の数はこれに限定されず、１つであってもよいし、２以上であってもよい。ＨＧＷ２０は、ユーザ毎の宅内に配置される。
【００２４】
（管理サーバの機能構成）
管理サーバ１０は、不成立の可能性の高い条件を優先して判定する判定処理制御方法を実行する判定処理制御装置の一例である。管理サーバ１０は、ルール作成部１１、条件判定順制御部１２、記憶部１３及び算出部１８を有する。
【００２５】
ルール作成部１１は、ユーザ毎にプログラムからルールを作成するインターフェース（Ｉ／Ｆ）を提供し、作成されたルールを条件判定順制御部１２へ渡す。
【００２６】
条件判定順制御部１２は、ルール作成部１１から渡されたルールに対し、通過率、重複数、判定コスト期待値等に基づき、ルール内の条件順序を設定し、設定したルールを処理サーバ５０が実行可能なように配備する。条件判定順制御部１２は、処理サーバ５０から条件の成立状態が変更されたことの通知を受けると、通過率、重複数、判定コスト期待値等に基づき、判定する条件順序を再設定し、再設定したルールを処理サーバ５０が実行可能なように再配備する。
【００２７】
記憶部１３には、全条件テーブル１４、条件タイプテーブル１５、データ種テーブル１６及び条件組合せ通過率テーブル１７の各テーブルを記憶している。また、記憶部１３は、ルール判定順設定処理プログラムを記憶している。
【００２８】
図５は、本一実施形態に係る全条件テーブル１４の一例を示す。全条件テーブル１４は、ルールＩＤ１４１、条件ＩＤ１４２、ユーザＩＤ１４３、データ種１４４、演算子１４５、値１４６、条件タイプ１４７及び判定順序１４８の各情報を記憶する。条件タイプ１４７は、同一条件のとき同じタイプが付される。同じタイプか否かは、データ種１４４、演算子１４５及び値１４６から定まる。データ種１４４、演算子１４５及び値１４６が一致する場合、条件タイプ１４７が同一となる。条件タイプ１４７は、例えば、図１のルールＲの条件Ａや条件Ｂといった名称に相当し、実際にはハッシュなど一意に決まる値が付与される。
【００２９】
第１実施形態では、算出部１８が算出する通過率に基づき、判定順序１４８が決まる。通過率には、「複数の条件のそれぞれの通過率」と、「複数の条件のそれぞれの通過率に基づき選択した条件と組合せた場合の複数の条件のそれぞれの通過率」とが使用される。
【００３０】
図６は、本実施形態に係る条件タイプテーブル１５の一例を示す。条件タイプテーブル１５は、条件タイプ１５１、重複数１５２及び通過率１５３の各情報を記憶する。通過率１５３は、条件タイプ１５１で示される「複数の条件のそれぞれ」に対する「通過率」の一例である。例えば、図６では、複数の条件のそれぞれの通過率のうち最も低い通過率の条件タイプ１５１は「ＣＴ０００２」である。よって、図５の条件タイプ１４７が「ＣＴ０００２」の条件が先頭の判定順序（判定条件１４８にて「１」）になる。
【００３１】
図７は、本実施形態に係るデータ種テーブル１６の一例を示す。データ種テーブル１６は、データ種１６１、使用データの入力頻度（回／時間）１６２、１回当たりの判定コスト期待値指数（％／回）１６３及び単位時間当たりの判定コスト期待値指数（％／時間）１６４の各情報を記憶する。単位時間当たりの判定コスト期待値指数１６４は、使用データの入力頻度１６２×１回当たりの判定コスト期待値指数１６３により算出される。
【００３２】
図８は、本実施形態に係る条件組合せ通過率テーブル１７の一例を示す。条件組合せ通過率テーブル１７は、条件組合せ１７１と条件組合せ１７１に対する通過率１７２とを対応付けて記憶する。条件タイプテーブル１５に記憶されている条件タイプ１５１毎の通過率１５３の値が高くても、その条件タイプと他の条件タイプとを組合せた条件組合せ１７１に対する通過率１７２の値が低い場合があり、またその逆の場合もある。例えば、図６では条件タイプ１４７「ＣＴ０００１」の通過率は高い。しかし、図８に示すように、「ＣＴ０００１」の条件と組合せた（ＣＴ０００１、ＣＴ０００２）の条件組合せ１７１に対応する通過率１７２の値は低い。
【００３３】
第１実施形態では、判定したデータの複数の条件のそれぞれの通過率に基づき、複数の条件から判定対象となるデータに対して最初に判定する条件が選択される。例えば、図６では複数の条件タイプ１５１のそれぞれの通過率１５３に基づき、不成立の可能性の高い条件、つまり、通過率が最も低い条件タイプ１４７「ＣＴ０００２」が１番目の判定順序として選択される。
【００３４】
次に、選択した条件と組合せた場合の複数の条件のそれぞれの通過率に基づき、複数の条件から判定対象となるデータに対して次に判定する条件が選択される。例えば、図８では、図６にて通過率が最も低い条件「ＣＴ０００２」と組み合せた条件組合せ１７１は、（ＣＴ０００１、ＣＴ０００２）、（ＣＴ０００２、ＣＴ０００３）、（ＣＴ０００２、ＣＴ０００４）である。これらの条件組合せのそれぞれの通過率１７２に基づき、不成立の可能性の高い条件、つまり、通過率が最も低い（ＣＴ０００１、ＣＴ０００２）の条件が２番目の判定順序として選択される。
【００３５】
イベントログ１９は、天気・交通などの入力イベントとなる全データのログが記憶されている。イベントログ１９は、管理サーバ１０内の記憶領域に保持されてもよいし、管理サーバ１０外の記憶領域に保持されてもよい。
【００３６】
算出部１８は、イベントログ１９と全条件テーブル１４とから、各条件の通過率を算出する。また、算出部１８は、イベントログ１９と全条件テーブル１４とから、各組合せた条件の通過率を算出する。
【００３７】
ルールに定義される各条件によって成立のしやすさが異なる。算出部１８は、この各条件の成立のし易さを示す「通過率」を算出する。通過率は、成立回数÷入力データ回数により算出できる。しかし、複数の条件のそれぞれの通過率の算出は、この算出方法に限らない。この場合の通過率は、入力したデータ（つまり、各条件に対する通過率を判定したデータ）に対して複数の条件のそれぞれについて各条件が成立した割合を示す。通過率を判定したデータは、イベントログ１９に記憶される。
【００３８】
図５のデータ種１４４、演算子１４５及び値１４６は条件の一例を示す。例えば、データ種１４４が「Whether.Tokyo」、演算子１４５が「＝＝」、値１４６が「雨」で示される「東京都が雨ならば」という条件があり、その条件は、入力する天気データに対して、１０回に１回だけ成立するとした場合、通過率は１０％となる。一方、「東京都が晴れならば」という条件が、１０回に６回成立するとしたら、通過率は６０％となる。算出部１８は、条件毎の通過率を算出し、条件タイプテーブル１５に設定する。
【００３９】
通過率は、一の条件と他の条件との組合せ(以下、「組合せ条件」ともいう。)でも考えることができ、その場合、複数の組合せ条件が同時に成立するしやすさを示す。算出部１８は、「組合せ条件に対する通過率を算出し、条件組合せ通過率テーブル１７に設定する。
【００４０】
個々の条件に対する通過率は高くても、条件を組合せた場合の通過率は低くなる条件があるし、逆もある。例えば、「晴れ、かつ気温が２０℃以下※夏場」のように、「晴れ」も「２０℃以下」もどちらも十分起きうるが、両方の条件を満たそうと低くなる。前者が成立すると、後者が成立しにくくなる、と言える。逆の例は、「雨、かつ湿度が６０％以上」のように、両方の条件が同時にしやすい場合である。
【００４１】
つまり、組合せ条件に対する通過率は、個々の条件に対する通過率の掛け算にはならない、ということが言える。これは、他の条件の成立状態によって、通過率が変わることを意味する。
【００４２】
複数の条件を組合せた組合せ条件に対する通過率は、入力したデータ（つまり、前記組合せ条件に対する通過率を判定したデータ）に対して、複数の組合せ条件のそれぞれについて各組合せ条件に含まれるすべての条件が成立した割合を示す。組合せ条件は、２以上の条件の組合せである。
【００４３】
（処理サーバの機能構成）
図４に戻り、処理サーバ５０は、ルール処理部５１及びイベント転送部５２を有する。ルール処理部５１は、配備されたルールに基づき、入力されたイベント（入力データ）に対し配備されたルールの判定順序に従い、各条件の判定を行う。ルール処理部５１は、条件の成立状態に変化があれば、条件判定順制御部１２に通知する。イベント転送部５２は、イベントを転送する。なお、処理サーバ５０は、ルール処理プログラムを記憶している。
（ＨＧＷの機能構成）
ＨＧＷ２０は、ルール処理部２１及びイベント転送部２２を有する。イベント転送部２２は、ルール処理の条件が成立（例えば、晴れで３０℃以上）したとき、処理サーバ５０からアクションを受け付ける。ルール処理部２１は、アクションの受付に従い、宅内の機器を制御する。例えば、ルール処理部２１は、宅内に配置されたエアコンを作動させる等の制御を行う。
【００４４】
なお、図４は、管理サーバ１０、ＨＧＷ２０及び処理サーバ５０の機能に着目したブロック図を描いており、これらの機能ブロックで示した各部は、ハードウエアのみ、ソフトウエアのみ、またはハードウエアとソフトウエアとの組合せによって実現可能である。
【００４５】
［管理サーバのＨＷ構成］
次に、管理サーバ１０のハードウェア構成について、図９を参照して説明する。図９は、本実施形態に係る管理サーバ１０のハードウェア構成の一例を示す。なお、本実施形態に係る処理サーバ５０のハードウェア構成は、管理サーバ１０のハードウェア構成と同一であるため、ここでは説明を省略する。
【００４６】
管理サーバ１０は、入力装置１０１、表示装置１０２、外部Ｉ／Ｆ１０３、ＲＡＭ（Random Access Memory）１０４、ＲＯＭ（Read Only Memory）１０５、ＣＰＵ（Central Processing Unit）１０６、通信Ｉ／Ｆ１０７、及びＨＤＤ（Hard Disk Drive）１０８などを備え、それぞれがバスＢで相互に接続されている。
【００４７】
入力装置１０１は、キーボードやマウスなどを含み、管理サーバ１０に各操作信号を入力するために用いられる。表示装置１０２は、ディスプレイなどを含み、各種の処理結果を表示する。通信Ｉ／Ｆ１０７は、管理サーバ１０をネットワーク４０に接続するインターフェースである。これにより、管理サーバ１０は、通信Ｉ／Ｆ１０７を介して、処理サーバ５０やＨＧＷ２０等の機器とデータ通信を行うことができる。
【００４８】
ＨＤＤ１０８は、プログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータには、管理サーバ１０の全体を制御する基本ソフトウェア及びアプリケーションソフトウェアがある。例えば、ＨＤＤ１０８には、各種のデータベースやプログラム等が格納されてもよい。
【００４９】
外部Ｉ／Ｆ１０３は、外部装置とのインターフェースである。外部装置には、記録媒体１０３ａなどがある。これにより、管理サーバ１０は、外部Ｉ／Ｆ１０３を介して記録媒体１０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体１０３ａには、ＣＤ（Compact Disk）、及びＤＶＤ（Digital Versatile Disk）、ならびに、ＳＤメモリカード（SD Memory card）やＵＳＢメモリ（Universal Serial Bus memory）等がある。
【００５０】
ＲＯＭ１０５は、電源を切っても内部データを保持することができる不揮発性の半導体メモリ（記憶装置）である。ＲＯＭ１０５には、ネットワーク設定等のプログラム及びデータが格納されている。ＲＡＭ１０４は、プログラムやデータを一時保持する揮発性の半導体メモリ（記憶装置）である。ＣＰＵ１０６は、上記記憶装置（例えば「ＨＤＤ１０８」や「ＲＯＭ１０５」など）から、プログラムやデータをＲＡＭ１０４上に読み出し、処理を実行することで、装置全体の制御や搭載機能を実現する演算装置である。
【００５１】
かかる構成により、本実施形態に係る管理サーバ１０では、ＣＰＵ１０６が、ＲＯＭ１０５やＨＤＤ１０８内に格納されたルール判定順設定処理プログラムを用いてルール判定順設定処理を実行する。全条件テーブル１４、条件タイプテーブル１５、データ種テーブル１６及び条件組合せ通過率テーブル１７の各テーブルは、ＲＡＭ１０４、ＨＤＤ１０８又はネットワーク４０を介して管理サーバ１０に接続されるクラウド上のサーバ等の記憶領域に格納され得る。なお、本実施形態に係る処理サーバ５０では、ＣＰＵが、ＲＯＭやＨＤＤ内に格納されたルール処理プログラムを用いてルール処理を実行する。
【００５２】
［条件の判定状態の遷移］
次に、本実施形態に係るルール内の条件の判定状態の遷移について、図１０の一実施形態に係る条件の判定状態の遷移図を参照して説明する。処理サーバ５０は、ルール内の各条件が成立するかについて入力データの判定を行う。このときの条件の状態は、判定中状態である。ルール内の各条件の判定状態には、図１０に示す未判定状態、判定中状態、成立中状態があり、互いに遷移する関係にある。
【００５３】
未判定状態の条件の判定が開始されると、「判定中状態」に遷移する。「判定中状態」の条件の判定の結果、条件が成立すると判定されると、「成立中状態」に遷移する。また、「判定中状態」の条件の判定が取り消されると、「未判定状態」に遷移する。
【００５４】
「成立中状態」の条件であっても、判定処理は継続され、「成立中状態」の条件の判定の結果、条件が成立しないと判定されると、「判定中状態」に遷移する。また、「成立中状態」の条件の判定が取り消されると、「未判定状態」に遷移する。
＜第１実施形態＞
［ルール判定順設定処理］
次に、第１実施形態に係るルール判定順設定処理について図１１を参照して説明する。図１１は、第１実施形態に係るルール判定順設定処理を示したフローチャートである。図１１の処理は、主に管理サーバ１０の条件判定順制御部１２により実行される。
【００５５】
本処理が開始されると、条件判定順制御部１２は、ルール中に複数の条件があるかを判定する（ステップＳ１０）。条件判定順制御部１２は、複数の条件があると判定した場合、条件タイプテーブル１５を参照して、通過率が最も低い条件を選択し（ステップＳ１２）、選択した条件をルール内の先頭に配置する。条件判定順制御部１２は、複数の条件はないと判定した場合、直ちに本処理を終了する。
【００５６】
例えば、図１２（ａ）に示すように、ルールＲ内に複数の条件Ａ，Ｂ，Ｃ，Ｄが存在する場合、図１２（ｂ）に示す通過率が最も低い条件Ｂが選択され、ルールの判定順序を示す領域Ｓの先頭に配置される。
【００５７】
図１１に戻り、次に、条件判定順制御部１２は、選択済みの条件以外で未選択の条件が複数あるかを判定する（ステップＳ１４）。条件判定順制御部１２は、選択済みの条件以外で未選択の条件が複数あると判定した場合、選択済み条件と未選択の複数の条件のそれぞれとを組合せた場合の通過率が最も低い条件を選択し（ステップＳ１６）、その選択した条件を、ルールの判定順序を示す領域Ｓの２番目に配置する。条件判定順制御部１２は、選択済み条件以外で未選択の条件が複数ある間、ステップＳ１４、Ｓ１６を繰り返す。
【００５８】
例えば、図１２（ｂ）に示すように、選択済み条件以外で未選択の複数の条件Ａ，Ｃ，Ｄが存在する場合、選択済み条件と条件Ａ，Ｃ，Ｄのそれぞれとを組合せた場合の通過率が最も低い条件Ａが、図１２（ｃ）に示すようにルールの判定順序の２番目に配置される。
【００５９】
図１２（ｃ）に示す未選択の複数の条件Ｃ，Ｄが存在する場合、再度、ステップＳ１４、Ｓ１６の処理が繰り返される。その結果、選択済みの条件Ａ及び条件Ｂと組合せたときに通過率が最も低い条件Ｄが、図１２（ｄ）に示すようにルールの判定順序の３番目に配置される。
【００６０】
図１１に戻り、ステップＳ１４において、条件判定順制御部１２は、選択済み条件以外で未選択の条件は一つであると判定した場合、残った一つの条件を選択し、ルールの末尾に配置し（ステップＳ１８）、本処理を終了する。
【００６１】
例えば、選択済み条件以外で未選択の条件が条件Ｃのみである場合、条件Ｃがルールの末尾に配置される。このようにして、図１２（ｄ）に示すように、ルールの条件の判定順序が決定される。条件判定順制御部１２は、条件の判定順序が決定されたルールを、処理サーバ５０が利用可能な記憶領域内に該ルールを配備する。
【００６２】
［ルール処理］
次に、第１実施形態に係るルール処理について図１３を参照して説明する。図１３は、第１実施形態に係るルール処理を示したフローチャートである。図１３の処理は、主に処理サーバ５０のルール処理部５１により実行される。
【００６３】
本処理が開始されると、ルール処理部５１は、先頭の条件のみ「判定中状態」にし、それ以外の条件を「未判定状態」にする（ステップＳ２０）。これにより、例えば、図１２（ｅ）に示すように、配備されたルールの先頭の条件Ｂのみ「判定中状態」になり、後続の条件Ａ、Ｄ，Ｃは未判定状態となって、条件Ｂが成立するまで何もしない。各条件に対して判定を止めている間に到達した入力データに対しては、最新のデータはキャッシュしておき、順序付けにより判定結果に影響がないようにする。
【００６４】
次に、ルール処理部５１は、「判定中状態」または「成立中状態」の条件に対し、入力データがあるかを判定する（ステップＳ２２）。「判定中状態」または「成立中状態」の条件に対し、入力データがあるまでステップＳ２２の処理が繰り返される。ルール処理部５１は、「判定中状態」または「成立中状態」の条件に対し、入力データがあると判定した場合、条件の判定を行う（ステップＳ２４）。
【００６５】
次に、ルール処理部５１は、条件が成立したか否かを判定する（ステップＳ２６）。ルール処理部５１は、条件が成立したと判定した場合、成立した条件を「成立中状態」に変更する（ステップＳ２８）。例えば、図１２（ｅ）に示すように、入力データがキャッシュされると、条件Ｂの判定が行われ、条件が成立した場合、図１２（ｆ）に示すように条件Ｂは成立中状態に変更される。
【００６６】
次に、ルール処理部５１は、後続する条件はあるかを判定し（ステップＳ３０）、後続する条件がないと判定した場合、イベント転送部５２は、アクションをＨＧＷ２０に通知し（ステップＳ３２）、ステップＳ２２に戻る。ルール処理部５１は、後続する条件があると判定した場合、後続する条件を「判定中状態」に変更し（ステップＳ３８）、ステップＳ２２に戻る。
【００６７】
例えば、ステップＳ３８の処理により、図１２（ｆ）に示すように、条件Ａが「判定中状態」になる。このとき、条件Ａ、Ｂが判定され、後続の条件Ｄ、Ｃは未判定状態のまま、条件Ａ及び条件Ｂの両方の条件が成立するまで何もしない。
【００６８】
図１３の繰り返し処理が実行され、図１２（ｇ）に示すように、ルールの条件Ｂ及び条件Ａが「成立中状態」、条件Ｄが「判定中状態」になると、条件Ａ、Ｂ、Ｄが判定され、後続の条件Ｃは、条件Ａ、条件Ｂ及び条件Ｄのすべてが成立するまで何もしない。
【００６９】
更に図１３の繰り返し処理が実行され、図１２（ｈ）に示すように、ルールの条件Ｂ、条件Ａ及び条件Ｄが「成立中状態」、条件Ｃが「判定中状態」になると、条件Ａ、Ｂ、Ｄ、Ｃが判定される。
【００７０】
このようにしてルールの全条件が成立すると、ステップＳ３０において、後続する条件がないと判定される。これに応じて、イベント転送部５２は、アクションをＨＧＷ２０に通知する（ステップＳ３２）。
【００７１】
ステップＳ２６において、ルール処理部５１は、条件が成立しないと判定した場合、不成立となった条件を「判定中状態」に変更する。次に、ルール処理部５１は、不成立となった条件よりも後続の条件をすべて「未判定状態」に変更し（ステップＳ３６）、ステップＳ２２に戻る。
【００７２】
以上に説明したように、第１実施形態に係る管理サーバ１０によれば、通過率が低い条件を優先的に判定するように、ルールの条件の判定順序を定める。これにより、第１実施形態に係る処理サーバ５０は、配備されたルールに従い通過率が低い条件から判定し、条件のすべてが成立するまで、後段の条件の判定を行わない。
【００７３】
例えば、個々の条件の通過率は高くても、組合せた場合の通過率は低くなる条件がある。またその逆の場合もある。例えば、「晴れ、かつ気温が２０℃以下」のように、「晴れ」の条件、及び「２０℃以下」の条件はどちらも単独で十分起きうるが、両方の条件が同時に成立し難い場合がある。逆の例としては、「雨、かつ湿度が６０％以上」のように、両方の条件が同時に成立し易い場合がある。
【００７４】
例えば、あるルールの条件セットが条件Ａ、Ｂ、Ｃである場合において、個々の通過率がそれぞれ条件Ａ＝８０％、条件Ｂ＝４０％、条件Ｃ＝２０％であるとする。そして、条件Ｃ及び条件Ａの組み合わせの通過率が１０％、条件Ｃ及び条件Ｂの組み合わせの通過率が２０％であるとする。この場合、処理サーバ５０は、先ず初めに最も通過率が低い条件Ｃを判定する。
【００７５】
本実施形態では、次に判定するのは単独の条件で２番目に通過率が低い条件Ｂではなく、条件Ｃと同時に発生する確率が低い（条件Ｃと組合せた場合の通過率が低い）条件Ａが判定される。
【００７６】
これにより、処理サーバ５０が行う判定処理を、最低限の条件の判定にすることができ、処理サーバの処理量の負荷を軽減することができる。また、無駄な処理を行わないため、サーバコストを削減できる。
【００７７】
なお、条件判定順制御部１２が実行するルール判定順設定処理中のルールの配備と、ルール処理部５１が実行するルール処理とは別々の処理であり、連動しない。よって、新しいルールが配備されると、配備後の次のルール処理において、配備された新しいルールの判定順序が用いられる。これは、以下に説明する他の実施形態においても同様である。
＜第２実施形態＞
［ルール判定順設定処理］
次に、第２実施形態に係るルール処理について図１４を参照して説明する。図１４は、第２実施形態に係るルール処理の一例を示すフローチャートである。第１実施形態に係るルール処理では、全条件テーブル１４の条件ＩＤ１４２毎に状態管理が行われた。これに対して、第２実施形態に係るルール処理では、条件タイプ１４７毎に状態管理が行われる。
【００７８】
本処理が開始されると、ルール処理部５１は、ルール中に「判定中状態」の条件が存在するかを判定する（ステップＳ４０）。ルール処理部５１は、「判定中状態」の条件が存在すると判定した場合、ステップＳ２２に進む。
【００７９】
ルール処理部５１は、「判定中状態」の条件が存在しないと判定した場合、「未判定状態」の条件が存在するかを判定する（ステップＳ４２）。ルール処理部５１は、「未判定状態」の条件が存在しないと判定した場合、ステップＳ３２に進み、アクションを通知した後、ステップＳ４０に戻る。
【００８０】
ステップＳ４２において、ルール処理部５１は、「未判定状態」の条件が存在すると判定した場合、重複条件があるかを判定する（ステップＳ４４）。重複条件とは、システム内の全てのルール間で同一の条件である。例えば、二人のユーザが「東京都の天気が晴れならば」、と設定していたら、それは重複条件である。同一条件毎の重複する数を「重複数」とする。
【００８１】
ルール処理部５１は、全てのルール間において重複条件はないと判定した場合、「未判定状態」の条件中で最も前段の条件を「判定中状態」に変更し（ステップＳ４６）、ステップＳ２２に進む。
【００８２】
一方、ルール処理部５１は、全てのルール間において重複条件があると判定した場合、各ルール中の重複条件を先頭に並べ替える（ステップＳ４８）。次に、ルール処理部５１は、いずれかのルールの重複条件を「判定中状態」にし、残りのルールの重複条件を「未判定状態」にして（ステップＳ５０）、ステップＳ２２に進む。
【００８３】
例えば、図１５に示すように、ルールＲ１，Ｒ２，Ｒ３のルール間にて重複した同一条件が含まれる場合、条件判定順制御部１２は、同一条件の判定順を該同一条件が含まれるルール内の未判定状態の条件の先頭に並べ替える。これにより、同一条件が集約される。
【００８４】
ルール処理部５１は、ユーザ毎のルールＲ１，Ｒ２，Ｒ３の各条件を順番に判定する際、重複する条件Ｂのいずれか一つのルールの重複条件を「判定中状態」にし、残りのルールの重複条件を「未判定状態」にする。図１５の集約後のルールでは、ルールＲ１の条件Ｂが「判定中状態」になり、残りのルールＲ２，Ｒ３の条件Ｂが「未判定状態」になっている。これにより、ルールＲ２，Ｒ３では、条件Ｂの判定を行うことなく、ルールＲ１の条件Ｂの判定結果を利用することで、処理サーバ５０の処理量の負荷を軽減することができる。
【００８５】
図１４に戻り、ステップＳ２２において、ルール処理部５１は、「判定中状態」又は「成立中状態」の条件に対して入力データがあるか否かを判定する。ルール処理部５１は、「判定中状態」又は「成立中状態」の条件に対して入力データがないと判定した場合、ステップＳ４０に戻る。一方、ルール処理部５１は、「判定中状態」または「成立中状態」の条件に対し入力データがあると判定した場合、条件の判定を行う（ステップＳ２４）。
【００８６】
次に、ルール処理部５１は、条件が成立したか否かを判定する（ステップＳ２６）。ルール処理部５１は、条件が成立したと判定した場合、ステップＳ２８に進み、条件が成立しないと判定した場合、ステップＳ３４に進む。
【００８７】
ステップＳ２８において、ルール処理部５１は、成立した条件を「成立中状態」に変更する。次に、ルール処理部５１は、後続する条件はあるかを判定し（ステップＳ３０）、後続する条件がないと判定した場合、イベント転送部５２はアクションを通知し（ステップＳ３２）、ステップＳ４０に戻る。ステップＳ３０において、ルール処理部５１は、後続する条件があると判定した場合、ステップＳ４０に戻る。
【００８８】
ステップＳ２６において条件が成立しないと判定され、ステップＳ３４に進んだ場合、ルール処理部５１は、不成立となった条件を「判定中状態」に変更する。次に、ルール処理部５１は、不成立となった条件よりも後続の条件をすべて「未判定状態」に変更し（ステップＳ３６）、ステップＳ２２に戻る。
【００８９】
本実施形態に係るルール処理においては、以上に説明したステップＳ２２にて「Ｎｏ」の場合、ステップＳ３０にて「Ｙｅｓ」の場合、ステップＳ３２にて「アクションを通知」した場合のいずれも、ステップＳ４０に戻り、ステップＳ４０以降の処理が繰り返されるようになっている。
【００９０】
これにより、ルール処理部５１は、各条件の状態が変わったときには、ルール全体の条件の状態を再確認することができる。例えば、図１６（ａ）のルールＲ１〜ルールＲ４に示すように、各ルールの条件の判定順序が設定されていたとする。ルール処理部５１が、条件Ｂが成立すると判定した場合、図１６（ｂ）の状態になる。
【００９１】
しかしながら、最初に設定した図１６（ａ）のルールＲ１〜ルールＲ４の順序が適切とは限らない。また、どの条件から成立するかは、実際にルール処理を動作させてからでないと分からない。つまり、条件毎の成立状態によって、通過率が高くなったり低くなったりする条件が発生し、各条件の判定順番や判定が重複する条件の判定順番が変わる、よって、管理サーバ１０により、条件の成立状態の変化に応じて、各条件の通過率及び条件の組合せの通過率を元に条件順序の再設定が行われる。
【００９２】
再設定が行われ、図１６（ｃ）に示すように、ルールＲ３及びルールＲ４において条件の判定順序が変更された場合、ルールＲ２〜ルールＲ４の条件Ｃが重複条件であるため、ルール処理部５１は、集約して条件判定をいずれかのルールにおいて１回のみ行い、処理サーバの処理量の負荷を軽減することができる。
【００９３】
以上に説明したように、第２実施形態においても第１実施形態と同じ効果が得られる。また、第２実施形態では、重複条件に対するルール処理は集約していずれかのルールにおいて１回のみ行う。これにより、処理サーバの処理量の負荷を軽減することができる。
【００９４】
更に、条件の成立状態の変化に応じて、各条件の通過率及び条件の組合せの通過率に基づき、各ルールの条件の判定順序が再設定される。これにより、条件の成立状態に変化が生じても通過率が低い条件を優先的に判定するようにルールの条件の判定順序を変更することで、処理サーバ５０が行う判定処理を最低限の条件の判定にすることができる。これにより、どんな判定状態においても処理サーバの処理量の負荷を軽減することができる。
＜第３実施形態＞
［ルール判定順設定処理］
最後に、第３実施形態に係るルール判定順設定処理について図１７を参照して説明する。図１７は、第３実施形態に係るルール判定順設定処理の一例を示すフローチャートである。なお、第３実施形態に係るルール処理は、第１実施形態において説明したルール処理を実行してもよいし、第２実施形態において説明したルール処理を実行してもよい。
【００９５】
第１実施形態及び第２実施形態に係るルール判定順設定処理では、「通過率」を用いてルール内の条件の順序付けが行われた。これに対して、第３実施形態に係るルール判定順設定処理では、通過率等を用いて「判定コスト期待値」を算出し、判定コスト期待値に基づきルール内の条件の判定順序が定められる。
【００９６】
例えば、条件Ａは数値比較だけを行う軽い判定であり、条件Ｂは自然言語から単語抽出及び文字列を比較するような重い判定である場合を想定する。この場合、単純には軽い判定処理となる条件Ａから判定すべきであるが、通過率が条件Ｂの方が低いと、条件Ｂから判定してしまい、サーバの負荷が逆順よりも高くなってしまう場合がある。
【００９７】
そこで、本実施形態に係るルール判定順設定処理では、各条件の判定コスト期待値を算出し、最も低い判定コストとなる条件順序を選択する。判定コスト期待値は、条件が使用するデータの種類に依存し、また重複数で割った値が採用される。判定コスト期待値が、条件が使用するデータの種類に依存するのは、データ毎に入力頻度や処理内容が異なるためである。このため、単位時間当たりの判定コスト期待値指数が予め定められている。単位時間当たりの判定コスト期待値指数を重複数で割るのは、重複しているほど本来かかるコストを削減できるためである。
【００９８】
図１７に示すルール判定順設定処理が開始されると、算出部１８は、ルールの順序パターンを抽出する（ステップＳ５０）。例えば、図１８の条件Ａ，条件Ｂ，条件Ｃの条件セットを有するルールＲがある場合、条件順序のパターンは、パターンＰ１〜パターンＰ６の６通りが抽出される。
【００９９】
図１７に戻り、次に、算出部１８は、ルールの順序パターン毎の判定コスト期待値を算出する（ステップＳ５２）。例えば、算出部１８は、図１８のパターンＰ１（条件Ａ→条件Ｂ→条件Ｃの判定順序）の判定コスト期待値を以下の式に基づき算出する。
パターンＰ１の判定コスト期待値
＝条件Ａの単位時間当たりの判定コスト期待値指数／重複数
＋条件Ｂの単位時間当たりの判定コスト期待値指数／重複数×条件Ａの通過率
＋条件Ｃの単位時間当たりの判定コスト期待値指数／重複数×（条件Ａ、Ｂ）の組合せの通過率
同様にして、算出部１８は、パターンＰ２〜パターンＰ６の判定コスト期待値をそれぞれ算出する。
【０１００】
図１７に戻り、次に、条件判定順制御部１２は、判定コスト期待値が最低となる順序パターンのルールを採用し（ステップＳ５４）、本処理を終了する。これにより、判定コスト期待値が最低となる順序パターンのルールが配備される。
【０１０１】
以上に説明したように、第３実施形態に係る管理サーバ１０によれば、判定コスト期待値を算出し、判定コスト期待値が最も低い条件順序が設定されたルールが配備される。この結果、処理サーバ５０は、「通過率が低い」、かつ、「重複数が高い」、かつ、「判定コスト期待値が低い」条件ほど、先に判定することができる。これにより、処理サーバの処理量の負荷を軽減することができ、サーバコストを削減できる。
【０１０２】
［おわりに］
以上、判定処理制御プログラム、判定処理制御方法及び判定処理制御装置を上記実施形態により説明したが、本発明にかかる判定処理制御プログラム、判定処理制御方法及び判定処理制御装置は上記実施形態に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能である。また、上記実施形態及び変形例が複数存在する場合、矛盾しない範囲で組み合わせることができる。
【０１０３】
例えば、上記実施形態に係る判定処理制御システムの構成は一例であり、本発明の範囲を限定するものではなく、用途や目的に応じて様々なシステム構成例があることは言うまでもない。
【０１０４】
以上の説明に関し、更に以下の項を開示する。
（付記１）
判定対象となるデータの種類毎に判定値が示された条件が複数設定されたルールを用いて、前記判定対象となるデータに対して前記ルールに設定された複数の条件のすべてが成立するか否かを判定する処理をコンピュータに実行させるための判定処理制御プログラムであって、
判定したデータの前記複数の条件のそれぞれの通過率に基づき、前記複数の条件から前記判定対象となるデータに対して最初に判定する条件を選択し、
選択した前記条件と他の条件とを組合せた場合の複数の組合せ条件のそれぞれの通過率に基づき、前記複数の条件から前記判定対象となるデータに対して次に判定する条件を選択する、
判定処理制御プログラム。
（付記２）
前記ルールに設定された複数の条件のうち、前記通過率に基づき選択された前記最初に判定する条件を前記ルール内の先頭に配置し、前記次に判定する条件を前記ルール内の先頭の条件の次に配置し、以前に選択した組合せ条件と他の条件とを組合せた場合の複数の組合せ条件のそれぞれの通過率に基づき選択された次に判定する条件を順に配置することを、前記ルールに設定された複数の条件がすべて配置されるまで繰り返して前記ルールに含まれる複数の条件の判定順序を設定し、
全てのルール間にて重複した同一条件が含まれる場合、前記同一条件の判定順を該同一条件が含まれるルール内の未判定状態の条件の先頭に配置し、
前記重複した同一条件のいずれかを前記最初に判定する条件として選択する、
付記１に記載の判定処理制御プログラム。
（付記３）
選択した前記条件の判定の結果による条件の成立状態の変化に応じて、前記ルールに含まれる複数の条件の判定順序を再設定する、
付記１又は２に記載の判定処理制御プログラム。
（付記４）
前記条件の成立状態が判定中状態から成立中状態に変化したことに応じて、前記複数の条件のそれぞれの通過率及び前記複数の組合せ条件のそれぞれの通過率に基づき前記ルールに含まれる複数の条件の判定順序を再設定する、
付記３に記載の判定処理制御プログラム。
（付記５）
前記複数の条件のそれぞれの通過率、前記複数の組合せ条件のそれぞれの通過率、前記同一条件の重複数及び単位時間当たりの判定コスト期待値指数に基づき判定コスト期待値を算出し、
算出した前記判定コスト期待値に基づき、前記ルールに含まれる複数の条件の判定順序を設定する、
付記２に記載の判定処理制御プログラム。
（付記６）
前記複数の条件のそれぞれの通過率は、前記判定したデータに対して前記複数の条件のそれぞれについて各条件が成立した割合を示し、
前記複数の組合せ条件のそれぞれの通過率は、前記判定したデータに対して前記複数の組合せ条件のそれぞれについて各組合せ条件に含まれるすべての条件が成立した割合を示す、
付記１〜５のいずれか一方に記載の判定処理制御プログラム。
（付記７）
判定対象となるデータの種類毎に判定値が示された条件が複数設定されたルールを用いて、前記判定対象となるデータに対して前記ルールに設定された複数の条件のすべてが成立するか否かを判定する処理をコンピュータに実行させるための判定処理制御方法であって、
判定したデータの前記複数の条件のそれぞれの通過率に基づき、前記複数の条件から前記判定対象となるデータに対して最初に判定する条件を選択し、
選択した前記条件と他の条件とを組合せた場合の複数の組合せ条件のそれぞれの通過率に基づき、前記複数の条件から前記判定対象となるデータに対して次に判定する条件を選択する、
処理をコンピュータが実行する判定処理制御方法。
（付記８）
前記ルールに設定された複数の条件のうち、前記通過率に基づき選択された前記最初に判定する条件を前記ルール内の先頭に配置し、前記次に判定する条件を前記ルール内の先頭の条件の次に配置し、以前に選択した組合せ条件と他の条件とを組合せた場合の複数の組合せ条件のそれぞれの通過率に基づき選択された次に判定する条件を順に配置することを、前記ルールに設定された複数の条件がすべて配置されるまで繰り返して前記ルールに含まれる複数の条件の判定順序を設定し、
全てのルール間にて重複した同一条件が含まれる場合、前記同一条件の判定順を該同一条件が含まれるルール内の未判定状態の条件の先頭に配置し、
前記重複した同一条件のいずれかを前記最初に判定する条件として選択する、
付記７に記載の判定処理制御方法。
（付記９）
選択した前記条件の判定の結果による条件の成立状態の変化に応じて、前記ルールに含まれる複数の条件の判定順序を再設定する、
付記７又は８に記載の判定処理制御方法。
（付記１０）
前記条件の成立状態が判定中状態から成立中状態に変化したことに応じて、前記複数の条件のそれぞれの通過率及び前記複数の組合せ条件のそれぞれの通過率に基づき前記ルールに含まれる複数の条件の判定順序を再設定する、
付記９に記載の判定処理制御方法。
（付記１１）
前記複数の条件のそれぞれの通過率、前記複数の組合せ条件のそれぞれの通過率、前記同一条件の重複数及び単位時間当たりの判定コスト期待値指数に基づき判定コスト期待値を算出し、
算出した前記判定コスト期待値に基づき、前記ルールに含まれる複数の条件の判定順序を設定する、
付記８に記載の判定処理制御方法。
（付記１２）
前記複数の条件のそれぞれの通過率は、前記判定したデータに対して前記複数の条件のそれぞれについて各条件が成立した割合を示し、
前記複数の組合せ条件のそれぞれの通過率は、前記判定したデータに対して前記複数の組合せ条件のそれぞれについて各組合せ条件に含まれるすべての条件が成立した割合を示す、
付記７〜１１のいずれか一方に記載の判定処理制御方法。
（付記１３）
判定対象となるデータの種類毎に判定値が示された条件が複数設定されたルールを用いて、前記判定対象となるデータに対して前記ルールに設定された複数の条件のすべてが成立するか否かを判定する判定処理制御装置であって、
判定したデータの前記複数の条件のそれぞれの通過率に基づき、前記複数の条件から前記判定対象となるデータに対して最初に判定する条件を選択し、選択した前記条件と他の条件とを組合せた場合の複数の組合せ条件のそれぞれの通過率に基づき、前記複数の条件から前記判定対象となるデータに対して次に判定する条件を選択する条件判定順制御部を有する、
判定処理制御装置。
（付記１４）
前記条件判定順制御部は、前記ルールに設定された複数の条件のうち、前記通過率に基づき選択された前記最初に判定する条件を前記ルール内の先頭に配置し、前記次に判定する条件を前記ルール内の先頭の条件の次に配置し、以前に選択した組合せ条件と他の条件とを組合せた場合の複数の組合せ条件のそれぞれの通過率に基づき選択された次に判定する条件を順に配置することを、前記ルールに設定された複数の条件がすべて配置されるまで繰り返して前記ルールに含まれる複数の条件の判定順序を設定し、
全てのルール間にて重複した同一条件が含まれる場合、前記同一条件の判定順を該同一条件が含まれるルール内の未判定状態の条件の先頭に配置し、
前記重複した同一条件のいずれかを前記最初に判定する条件として選択する、
付記１３に記載の判定処理制御装置。
（付記１５）
選択した前記条件の判定の結果による条件の成立状態の変化に応じて、前記ルールに含まれる複数の条件の判定順序を再設定する、
付記１３又は１４に記載の判定処理制御装置。
（付記１６）
前記条件判定順制御部は、前記条件の成立状態が判定中状態から成立中状態に変化したことに応じて、前記複数の条件のそれぞれの通過率及び前記複数の組合せ条件のそれぞれの通過率に基づき前記ルールに含まれる複数の条件の判定順序を再設定する、
付記１５に記載の判定処理制御装置。
（付記１７）
前記条件判定順制御部は、前記複数の条件のそれぞれの通過率、前記複数の組合せ条件のそれぞれの通過率、前記同一条件の重複数及び単位時間当たりの判定コスト期待値指数に基づき判定コスト期待値を算出し、
算出した前記判定コスト期待値に基づき、前記ルールに含まれる複数の条件の判定順序を設定する、
付記１４に記載の判定処理制御装置。
（付記１８）
前記条件判定順制御部は、前記複数の条件のそれぞれの通過率は、前記判定したデータに対して前記複数の条件のそれぞれについて各条件が成立した割合を示し、
前記複数の組合せ条件のそれぞれの通過率は、前記判定したデータに対して前記複数の組合せ条件のそれぞれについて各組合せ条件に含まれるすべての条件が成立した割合を示す、
付記１３〜１７のいずれか一方に記載の判定処理制御装置。
【符号の説明】
【０１０５】
１    判定処理制御システム
１０  管理サーバ
１１  ルール作成部
１２  条件判定順制御部
１３  記憶部
１４  全条件テーブル
１５  条件タイプテーブル
１６  データ種テーブル
１７  条件組合せ通過率テーブル
１８  算出部
１９  イベントログ
２０  ＨＧＷ
４０  ネットワーク
５０  処理サーバ
５１  ルール処理部
５２  イベント転送部
【図１】
2017228119.tif 000003
【図２】
2017228119.tif 000004
【図３】
2017228119.tif 000005
【図４】
2017228119.tif 000006
【図５】
2017228119.tif 000007
【図６】
2017228119.tif 000008
【図７】
2017228119.tif 000009
【図８】
2017228119.tif 000010
【図９】
2017228119.tif 000011
【図１０】
2017228119.tif 000012
【図１１】
2017228119.tif 000013
【図１２】
2017228119.tif 000014
【図１３】
2017228119.tif 000015
【図１４】
2017228119.tif 000016
【図１５】
2017228119.tif 000017
【図１６】
2017228119.tif 000018
【図１７】
2017228119.tif 000019
【図１８】
2017228119.tif 000020