[0022]添付の図面に関連するいくつかの本発明の実施形態について、ここで説明する。以下の説明および図面は、本発明を例示するものであり、本発明を限定するものと解釈されるべきでない。本発明の様々な実施形態の完全な理解をもたらすために、多数の具体的な詳細が記載される。ただし、いくつかの事例では、本発明の実施形態の簡明な考察を提供するために、よく知られている、または従来の詳細については記載されない。
[0023]本明細書における「一実施形態」または「実施形態」への言及は、実施形態に関して説明する特定の特徴、構造、または特性が、本発明の少なくとも1つの実施形態中に含まれ得ることを意味する。本明細書中の様々な箇所における「一実施形態では」という句の出現は、必ずしもすべてが同じ実施形態を指すとは限らない。
[0024]本明細書で説明される実施形態は、コンピューティングシステム内のプラットフォームとして規則エンジンを提供するためのシステムと方法とを提供する。規則エンジンプラットフォームは、対象のコンテキストを識別するように構成され得、別のデバイスまたは要素によって決定されたコンテキストにアクセスすることが可能である。識別された対象のコンテキストから、規則エンジンプラットフォームは、対象のコンテキストに関連する規則または規則のセットを選択的に識別し得る。したがって、対象のコンテキストに無関連な規則または規則のセットは、評価から省かれ得る。同様に、対象のコンテキストに関連するファクトまたはファクトのセットが識別され得る。関連ファクトは、関連規則を評価するために使用され得、対象のコンテキストに関連しないファクトは無視され得る。
[0025]図1は、本発明の実施形態が実施され得るシステムを示すブロック図である。システムはポータブル電子デバイス100であってよく、デバイス100は、スマートフォン、セルラーフォン、携帯情報端末、タブレットコンピュータ、パーソナルメディアプレーヤなど、どのモバイルデバイスならびに同様または複合機能性を提供する、他のどんなタイプのポータブル電子デバイスであってもよい。デバイス100は、触覚ボタン、電力デバイス(たとえば、バッテリ)、ならびに通常はポータブル電子デバイスに関連付けられた他の構成要素も含み得ることを諒解されたい。したがって、図1は、いくつかの構成要素が省かれているので、限定的なものと解釈されるべきでない。
[0026]図1に示される実施形態において、デバイス100は、いくつかの構成要素における動作を実施するための命令を実行するように構成されたプロセッサ110を含み、たとえば、ポータブル電子デバイス内での実装に適した汎用プロセッサまたはマイクロプロセッサであってよい。プロセッサ110は、ポータブル電子デバイス100内の複数の構成要素と通信可能に結合される。いくつかの実施形態では、プロセッサ110は、ハードウェアモジュール101、102の内部に存在してよい。この通信結合を実現するために、プロセッサ110は、バス140を超えて、他の図示される構成要素と通信することができる。バス140は、デバイス100内でデータを転送するように適合されたどのサブシステムであってもよい。バス140は、複数のコンピュータバスであり、データを転送するための追加回路構成を含み得る。いくつかの実施形態では、バス140は、システムオンチップ(SoC)で実装され、チップ上の様々な要素もしくは構成要素および/または1つもしくは複数のプロセッサのコアを接続する。ハードウェアモジュール101、102は、例として、オーディオサブシステム、カメラサブシステム、センササブシステムなど、モバイルデバイス内の個々のサブシステムを指す場合もある。
[0027]ストレージ135とメモリ120の両方が、プロセッサ110向けの命令とデータとを含み得る。ストレージ135は、バス140(図示されている)を介してローカルに、またはセルラーデータ、Wi−FiもしくはWiMax(登録商標)ネットワーク(図示せず)などのネットワークを介してリモートに実装されてよい(たとえば、クラウドストレージ)。いくつかの実施形態では、ストレージ135は、たとえば読出し専用メモリ(ROM)、フラッシュメモリなどの不揮発性メモリを含む。さらに、ストレージ135は、セキュアデジタル(SD)カードなどの取外し可能記憶デバイスを含み得る。ストレージ135は、たとえば、従来の磁気ディスク、CD−ROMやDVDベースのストレージなどの光ディスク、磁気テープストレージ、光磁気(MO)記憶媒体、ソリッドステートディスク、フラッシュメモリベースのデバイス、またはデータを記憶するのに適した他のどのタイプの記憶デバイスであってもよい。
[0028]メモリ120は、短期記憶と長期記憶の両方を提供することができ、実際にはいくつかのユニットに分割され得る。メモリ120は、スタティックランダムアクセスメモリ(SRAM)および/または動的ランダムアクセスメモリ(DRAM)など、揮発性であってよい。メモリ120は、ポータブル電子デバイス100向けの、コンピュータ可読命令、データ構造、アプリケーションモジュール、および他のデータの記憶を提供することができる。そのようなデータは、ストレージ135からロードされ得る。メモリ120は、キャッシュに置かれたプロセッサ110などのキャッシュメモリも含み得る。いくつかの実施形態では、メモリ120は、異なるハードウェアモジュール101〜102に分散されてよい。
[0029]いくつかの実施形態では、メモリ120は、複数のアプリケーションモジュール105〜106を記憶する。アプリケーションモジュール105〜106は、プロセッサ110によって実行されるべき特定の命令を含む。メモリ120は、任意の数のアプリケーションモジュールを記憶することができる。アプリケーションモジュール105〜106は、たとえば、カレンダアプリケーション、ジオフェンシングアプリケーション、電力管理アプリケーション、スマートアラートアプリケーション、ソーシャルメディアアプリケーション(たとえば、Twitter(登録商標)やFacebook(登録商標))、またはプロセッサ110によって実行されるべき命令を有する、どのアプリケーションタイプモジュールであってもよい。
[0030]後述するように、本発明の実施形態は、デバイス100のプロセッサ110および/またはデバイス100の他の回路構成による命令の実行とともに実装可能であることを諒解されたい。詳細には、デバイス100の回路構成は、プロセッサ110を含むがこれに限定されず、プログラムの制御、ルーチン、または本発明の実施形態による方法もしくはプロセスを実行するための命令の実行の下で動作し得る。たとえば、アプリケーションモジュール105〜106は、ファームウェア、ソフトウェアまたはハードウェアで実装されてよく、プロセッサ110および/またはデバイス100の他の回路構成によって実行することができる。さらに、プロセッサ、マイクロプロセッサ、回路構成、コントローラなどの用語は、論理、コマンド、命令、ソフトウェア、ファームウェア、機能性などを実行することが可能な任意のタイプの論理または回路構成を指すことを諒解されたい。プロセッサ110の機能(複数可)は、多くの異なるサブモジュールおよびサブシステムにわたって分散されてもよく、必ずしも1つの物理エンティティにおいて全体が行われなければならないとは限らないことにも留意されたい。
[0031]いくつかの実施形態では、メモリ120はオペレーティングシステム123を含む。オペレーティングシステム123は、アプリケーションモジュール105〜106によって提供される命令の実行を開始し、ハードウェアモジュール101〜102を管理し、かつ/またはディスプレイモジュール103とユーザ入力モジュール104とを管理するように動作可能であり得る。オペレーティングシステム123は、スレッド化と、リソース管理と、データ記憶制御と、他の同様の機能性とを含む、デバイス100の構成要素にわたる他の動作を実施するように適合され得る。
[0032]いくつかの実施形態では、ポータブル電子デバイス100は、複数のハードウェアモジュール101〜102を含む。ハードウェアモジュール101〜102の各々は、デバイス100内の物理モジュールである。ただし、ハードウェアモジュール101〜102の各々は、構造として永続的に構成されるが、ハードウェアモジュール101〜102は、特定の機能を実施するように一時的に構成されるか、または一時的にアクティブ化されればよい。一般的な例が、シャッター解放(release)および画像キャプチャのためにカメラモジュール(すなわち、ハードウェアモジュール)をプログラムすることができるアプリケーションモジュールである。ハードウェアモジュール101〜102は、たとえば、加速度計、Wi−Fiトランシーバ、衛星ナビゲーションシステム受信機(たとえば、SPSモジュール)、圧力モジュール、温度モジュール、オーディオ出力および/または入力モジュール(たとえば、マイクロフォン)、カメラモジュール、近接センサ、周辺光センサ(ALS)モジュール、静電容量式タッチセンサ、近距離通信(NFC)モジュール、Bluetoothトランシーバ、セルラートランシーバ、磁力計、ジャイロスコープ、慣性センサ(たとえば、モジュール、コンバイン、加速度計およびジャイロスコープ)、周辺光センサ、相対湿度センサ、または感覚出力を提供し、かつ/または感覚入力を受信するように構成された他のどの同様のモジュールであってもよい。いくつかの実施形態では、ハードウェアモジュール101〜102の1つまたは複数の機能は、ソフトウェアで実装され得る。一実施形態では、ハードウェアモジュール101〜102は、たとえば、センサデータ(たとえば、未加工センサ出力)に加えて、いくつかの動作を実施するためのプロセッサと、メモリ(たとえば、キャッシュ)と、他の構成要素とを含むサブシステムとして実装され得る。
[0033]ハードウェアモジュール101〜102およびアプリケーションモジュール105〜106に加えて、ポータブル電子デバイス100は、ディスプレイモジュール103とユーザ入力モジュール104とを有し得る。ディスプレイモジュール103は、デバイス100からの情報を、ユーザに対してグラフィカルに提示する。この情報は、1つもしくは複数のアプリケーションモジュール105〜106、1つもしくは複数のハードウェアモジュール101〜102、それらの組合せ、またはユーザ向けのグラフィカルコンテンツを(たとえば、オペレーティングシステム123によって)分解する(resolving)ための、他のどの適した手段からも導出され得る。ディスプレイモジュール103は、液晶ディスプレイ(LCD)技術、発光ポリマーディスプレイ(LPD)技術、または他のディスプレイ技術であり得る。いくつかの実施形態では、ディスプレイモジュール103は、静電容量式または抵抗性タッチスクリーンであり、ユーザとの触覚(haptic)および/または触感(tactile)接触に感応し得る。そのような実施形態において、ディスプレイモジュール103は、マルチタッチセンシティブディスプレイを備え得る。
[0034]ユーザ入力モジュール104は、キーボード、トラックパッド、触覚ボタン、物理スイッチ、タッチスクリーン(たとえば、静電容量式タッチスクリーンや抵抗性タッチスクリーン)、オーディオ(たとえば、発話による)、カメラ(たとえば、ユーザが見ているロケーションを追跡することによる)、または同様のモジュールなど、ユーザからの入力を受諾するためのどの手段であってもよい。したがって、ユーザ入力モジュール104は、複数の構成要素に分散されてよい。ユーザ入力モジュール104がタッチスクリーンとして提供される実施形態において、ユーザ入力モジュール104は、ディスプレイモジュール103と統合され得る。別の実施形態においても、ユーザ入力モジュール104は、タッチスクリーンインターフェースと触覚ボタン(たとえば、キーボード)の両方を備え、したがって、ディスプレイモジュール103と部分的に統合されるだけである。ユーザ入力モジュール104は、ユーザ入力を、アプリケーションモジュール105〜106(たとえば、設定を変えることによって)およびハードウェアモジュール101〜102(たとえば、カメラモジュールのシャッター解放を引き起こすことによって)に提供することができる。いくつかの実施形態では、ユーザ入力モジュール104は、ユーザ入力が音(たとえば、ボイスコマンド)として受信され得るように、マイクロフォン(図示せず)を含む。
[0035]ポータブル電子デバイス100は、本実施形態では規則エンジンインターフェース131、規則エンジン132、規則リポジトリ133、および知識リポジトリ134として示される規則エンジンプラットフォーム130を含む。規則エンジンプラットフォーム130は、ハードウェアアーキテクチャおよびソフトウェアフレームワークの一方または両方を含むコンピューティングプラットフォームであってよい。いくつかの実施形態では、規則エンジンプラットフォーム130は、アーキテクチャ、1つまたは複数のランタイムシステムライブラリ、グラフィカルユーザインターフェースおよび/またはコンピューティングプラットフォームの他の構成要素を提供することによって、モジュール101〜106が稼動できるようにする。たとえば、規則エンジンプラットフォーム130の1つまたは複数の構成要素131〜134が、オペレーティングシステム123と統合されてよい。別の実施形態では、規則エンジンプラットフォーム130は、オペレーティングシステム123から利用可能なもの以外にも、モジュール101〜106にサービスを提供するミドルウェアプラットフォームである。サービスは、データ(たとえば、サンプル)または別法では利用不可能または制限される、別のモジュール101〜106によって提供される他の機能性へのアクセスを含み得る。
[0036]ここでは、メモリ120内に実装されるように示されているが、規則エンジンプラットフォーム130の構成要素131〜134は、必ずしも固く統合されるわけではなく、実際にはデバイス100内で別々に実装されてよい。たとえば、規則エンジン132は、特定用途向け集積回路(ASIC)に、またはプロセッサ110に存在し得るが、知識リポジトリ134は、メモリ120内に存在する。代替として、規則エンジン132は、モジュール101〜106にわたって分散された個々の構成要素に分割されてよく、モジュール101〜106に関連付けられた機能性およびデータへのアクセスを有し得る。いくつかの実施形態では、規則エンジンプラットフォーム130の1つまたは複数の構成要素131〜134が統合される。たとえば、規則エンジンインターフェース131のいくつかの機能性が、規則エンジン132と統合されてよく、他の機能性は、リポジトリ133〜134と統合されてよい。
[0037]規則エンジンインターフェース131は、規則エンジン132と、モジュール101〜106のうちの1つまたは複数との間の対話(interaction)を円滑にする。多くの実施形態において、モジュール101〜106と規則エンジン132との間の通信は、この時点で処理される。いくつかの実施形態では、規則エンジンインターフェース131は、アプリケーションプログラミングインターフェース(API)、動的リンクライブラリ(DLL)、またはモジュール101〜106のうちの1つもしくは複数が、規則エンジン132にデータを送り、および/またはそこからデータを受信することができるようにする他の通信リソースを提供する。
[0038]いくつかの実施形態では、規則エンジンインターフェース131は、モジュール101〜106から受信されたデータを、規則エンジン132によって解釈可能な形式に適合させる。規則エンジンインターフェース131において受信されたデータはサンプルであってよく、サンプルは、送り手のモジュール101〜106に関連付けられたどのデータであってもよい。受信サンプルは、記憶され、ファクトをアサートし、かつ/またはコンテキストを導出するのに使われ得る。規則エンジン132は、規則が評価されるように、ファクトを、規則ベースからの規則と突き合わせればよい。規則エンジン132は、規則エンジンインターフェース131を使用してサンプルを要求することができ、たとえば、規則エンジン132は、規則を評価するために追加サンプルを必要とする場合があり、サンプル要求を送り、応答としてサンプルを受信するために、規則エンジンインターフェース131を使用し得る。
[0039]いくつかの実施形態では、規則エンジンインターフェース131は、1つまたは複数のモジュール101〜106にサブスクライブする(subscribe)ように構成され、そうすることによって、サブスクライブされたモジュール101〜106から、1つまたは複数のサンプルが受信される。モジュール101〜106へサブスクライブすることは、サンプルについての要求など、規則エンジン132による要求への応答であり得る。規則エンジンインターフェース131は、APIなど、モジュールに関連付けられたインターフェースを通して、モジュール101〜106にサブスクライブするようにも構成され得る。規則エンジンインターフェース131は、受信サンプルに基づいてファクトをアサートし、および/またはサンプルをリポジトリ133〜134に記憶し得る。
[0040]広い意味で、ファクトをアサートすることは、ファクトをメモリ(たとえば、メモリ120および/またはストレージ135)に記憶することを指し、それにより、ファクトが、規則を識別し、評価するのに使われ得る。たとえば、ファクトは、そのファクトをメモリ120中の知識リポジトリ134に記憶することによって、アサートされ得る。ファクトをアサートすることにより、規則エンジン132は、1つまたは複数の規則を識別または評価し得る。一実施形態では、ファクトをアサートすることは、ファクトがメモリ120に存在するか、または古くないことを検証することを備える。いくつかの実施形態では、ファクトをアサートすることは、ファクトが、規則を識別し、評価するのに使われ得るように、ファクトを決定することを備え得る。
[0041]モジュール101〜106にサブスクライブする際、規則エンジンインターフェース131は、サンプルについての単一の要求(たとえば、単一のクエリ)を発行し得、または、モジュール101〜106に永続的にサブスクライブし得る(たとえば、サンプルストリームをポーリングまたは受信する)。そうする際、規則エンジンプラットフォーム130は、たとえば、いつおよび/またはどのように1つもしくは複数のモジュール101〜106が問い合わせされ、および/または使用されるかを制御することによって、1つまたは複数のリソースを監視し、管理し得る。いくつかの実施形態では、規則エンジンプラットフォーム130は、モジュール101〜106がサンプルを提供するのを受動的に待つのではなく、むしろ、そのモジュール101〜106の実施を能動的に指示し得る。
[0042]いくつかの実施形態では、規則エンジンプラットフォーム130は、規則エンジンインターフェース131を通してモジュール101〜106によってサブスクライブされる。たとえば、モジュール101〜106は、応答としてアクションを要求することによって、規則エンジンプラットフォーム130にサブスクライブし得る。規則エンジンインターフェース131は、たとえば規則エンジン132が規則を評価してアクションを決定する場合、規則インターフェース131が有意な応答を提供することができるように、いくつかのサブスクリプション(subscription)を、規則エンジン132によって解釈可能な形式に変換することができる。規則エンジンプラットフォーム130の特徴として、第2のモジュール101〜106についてのデータを要求する、モジュール101〜106のそれぞれの1つが、規則エンジンインターフェース131に要求を送り、規則エンジンインターフェース131からアクションを受信するであろう。一実施形態では、モジュール101〜106は、規則エンジンプラットフォーム130を有するデバイス100内で実装された結果として、規則エンジンインターフェース131に永続的にサブスクライブされている。
[0043]規則エンジンプラットフォーム130は、新たな規則を追加し、または既存の規則を更新もしくは削除するための要求など、規則ベースを更新する要求を受諾するように構成され得る。規則エンジンインターフェース131は、規則エンジン132による解釈のために、要求を変換する(translate)ように構成され得る。したがって、いくつかの実施形態では、規則エンジンインターフェース131は、コンパイラ、インタープリタまたは規則を変換するための同様のリソースであってよい規則変換器(図示せず)を含むか、または変換器と結合される。規則エンジンインターフェース131は次いで、規則エンジン132が、更新された規則を評価することができるように、規則リポジトリ133中の規則ベースを、要求に従って更新し得る。規則エンジンインターフェース131におけるこの変換により、規則ベースに対する更新が、ランタイムにおいて実装される。したがって、規則エンジンプラットフォーム130は、ランタイムカスタマイズと、コンテキスト認識と、スマートサービスと、デバイス100の同様の特徴とを可能にする。
[0044]モジュール101〜106は、規則ベースについての更新を規則エンジンインターフェース131に提供し得る。たとえば、ポータブル電子デバイス100のユーザが、音声ユーザ入力またはタッチユーザ入力として受諾された新たな規則などの規則を、ユーザ入力モジュール104を通して入力してよい。いくつかの実施形態では、たとえば、ユーザがモジュール101〜106の設定を変更する場合、ユーザは、モジュール101〜106のうちの1つを通して、規則を作成、修正または消去するパラメータを定義することができる。いくつかの実施形態では、ユーザは、ユーザ入力モジュール104を使って、高水準言語で書かれた規則を入力し得る。
[0045]規則エンジン132は、規則を評価するとともにアクションを決定するためのRETEアルゴリズム(たとえば、DROOLS規則エンジン)を実装し得る。簡潔には、規則エンジン132は、条件(たとえば、1つまたは複数のサンプルからアサートされたファクトまたはファクトのセット)を識別するとともに規則と突き合わせる(マッチングする)ように構成される。多くの実施形態において、規則は、条件と結果との間の条件付き関係を定義する。この関係はしばしば、口語では「if−thenステートメント」と呼ばれ、「if[条件]then[結果]」の形をとり得る。規則エンジン132は、ランタイムに規則リポジトリ133から、1つまたは複数の規則を、評価のために動的に選択または識別し得る。さらに、規則エンジン132は、アクセスおよび評価の持続時間を削減するために、頻繁に評価または期待される規則などの規則をキャッシュしてよい。規則エンジン132は、規則を評価した結果からアクションを決定してもよく、結果はアクションであってもよい。したがって、規則エンジン132は、宣言型であるとともに、有利には、ポータブル電子デバイス100内の論理(たとえば、規則)からの別々のデータ(たとえば、ファクトをアサートするのに使われるサンプル)であってよい。
[0046]規則エンジン132は、規則とファクトとを、効率的評価のために組織化することができる。いくつかの実施形態では、規則エンジン132は、規則リポジトリ133中で定義される規則の一部または全部に基づいて、組織的構造(organizational structure)を構築し得る。規則エンジン132は、この組織的構造を知識リポジトリ134に記憶し得る。組織的構造は、有向グラフまたはトライ(trie)(すなわち、プレフィックスツリー)と同様であってよい。規則エンジン132は、規則をその成分に分解し得、たとえば、複数のファクトを必要とする複合規則が、組織的構造にアクセスすることによって、素早く、効率的に評価され得る1つまたは複数の要件に分解され得る。規則エンジン132は、評価性能を最適化するために、組織的構造による索引付けとハッシュ化とを提供することができる。たとえば、規則エンジン132は、1つまたは複数の規則を効率的に評価するために、組織的構造中のファクトをハッシュすることができる。規則エンジン132は、要件が共有され得るように、組織的構造の同一の要件を識別し、まとめることによって、規則評価を最適化することもできる。規則エンジン132はしたがって、組織的構造にアクセスすることによって、モジュールにアクションを提供するように構成され得る。規則エンジンプラットフォーム130は、効率を増し、速度を増し、電力消費を減らし、システムリソース消費を減らし、および/またはポータブル電子デバイス100の性能を強化することを意図している同様の属性に影響を与えることによって、ポータブル電子デバイス100の性能を最適化することができる。したがって、「最適化」は、必ずしも「最良」または規則エンジンプラットフォーム130のただ1つの得られる効果/可能性があることを意味するとは限らない。したがって、規則エンジンプラットフォーム130は、効率を最大限にすることも、電力消費を最小限にすることも求められないが、これらの側面を向上させることができる。たとえば、規則エンジンプラットフォーム130は、速度を増すことができ、同時に、電力消費を増し、これらの増大は、増大した速度が望ましいようないくつかの実施形態では電力消費が直ちに問題となり得るわけではないので、いくつかの実施形態では最適と見なされ得る。いくつかの実施形態では、規則エンジンプラットフォーム130は、ポータブル電子デバイス100内に規則エンジンプラットフォーム130を実装しているユーザに、(たとえば、規則エンジンインターフェース131を通して)インターフェースを提供し、そうすることによって、速度、電力および他のそのような属性(たとえば、速度と電力との間のトレードオフ値)についての最適化設定またはパラメータが、手動で設定または較正され得る。
[0047]したがって、規則エンジン132は、1つまたは複数のサンプルを受信するとともにポータブル電子デバイス100内で1つまたは複数のアクションを提供することによって、省電力と性能(たとえば、処理速度)とを強化することができ、そうすることによって、モジュール101〜106の間での直接のデータの送信を最小限にする。図1に示される実施形態では、モジュール101〜106は、規則エンジンプラットフォーム130にサブスクライブし、そうすることによって、アクションが、規則エンジン132によって決定され、規則エンジンインターフェース131を通して送られる。有利には、モジュール101〜106のうちの1つはそれ以上、モジュール101〜106のうちの別の1つにサブスクライブする必要も、その1つに対して要求を行う必要もない。たとえば、モジュール101〜106のうちの2つが、ポータブル電子デバイス100のロケーションを求める場合がある。デバイス100のロケーションは、サンプルとして受信され、ロケーションファクトとしてアサートされ得る。ロケーションを要求する両方のモジュールは、規則エンジン132に対して(規則エンジンインターフェース131を通して)ロケーションを要求するだけでよく、規則エンジン132は、ロケーションファクトに素早くアクセスして、各要求側モジュールにロケーションを(たとえば、規則エンジンインターフェース131を通してアクションとして)提供することができる。したがって、衛星測位システム(SPS)モジュール(たとえば、モジュール101〜102のハードウェアモジュール)は、現在のロケーションを2回検出し、次いで、現在のロケーションを2回(各要求側モジュール向けに一度)送る必要はない。さらに、規則エンジンプラットフォーム130は、いくつかの規則と、それらにサブスクライブしているいくつかのモジュール101〜106とを扱うためのスケーラビリティを提供する。
[0048]いくつかの実施形態では、規則エンジン132は、規則を真と評価するが、アクションは何もしないことであると決定し得る。したがって、規則エンジン132は、規則エンジンインターフェース131にアクションを必ずしも提供しなくてよいか、または規則エンジンインターフェース131がどのアクションも送出しないように、ヌルアクションを提供すればよい。規則エンジン132は、アクションが、何もしないという応答であり得ると決定する場合もある。規則エンジンインターフェース131は次いで、何もしないという応答を受信側モジュール101〜106に提供し得、受信側モジュール101〜106にヌル値を提供し得る。
[0049]規則エンジンプラットフォーム130の補足構成要素として、規則リポジトリ133は、規則ベース、つまり、規則エンジン132が評価することができる規則を適切に記憶するように構成される。規則リポジトリ133は、ランタイムに、ストレージ135およびメモリ120にわたって分散され得る。他の実施形態では、規則リポジトリ133は、プロセッサ110にわたって分散され得、および/またはモジュール101〜106にわたって分散される個々の構成要素に分割され得、および/またはモジュール101〜106に関連付けられた機能およびデータへのアクセスを有し得る。規則に加えて、規則リポジトリ133は、テンプレートと、変数と、パラメータと、規則エンジン132がアクションを決定し、および/または決定されたアクションを遂行するのに必要とされる他の情報とを記憶し得る。規則リポジトリ133は、追加、更新、または消去された規則など、規則ベースに対する更新を受諾するように構成される。たとえば、モジュール101〜106は、ユーザ入力に応答して、規則ベースに対する更新を要求し得る。
[0050]規則リポジトリに加えて、規則実行は、プロセッサ110および異なるモジュール101〜106にわたって分散され得る。たとえば、知識ベース134は、プロセッサ110にわたって分散され得、および/またはモジュール101〜106にわたって分散される個々の構成要素に分割され得、および/またはモジュール101〜106に関連付けられた機能性およびデータへのアクセスを有し得る。
[0051]いくつかの実施形態では、規則ベースは、複数のセットに、または1つもしくは複数の階層に、ランタイムに動的に組織化され得、規則エンジン132は、階層のセットまたはレベルのうちの1つまたは複数を選択的に評価すればよい。たとえば、ユーザが自宅にいることをファクトが示すとき、規則エンジン132は、ユーザが自宅にいるときに適用する規則を評価し得、および/またはユーザが職場にいるときに適用する規則の評価を省いてよい。規則エンジン132が規則を真と評価した場合、規則エンジン132はアクションを決定する。続いて、規則エンジン132は、アクションが受信側モジュール101〜106に送られ得るか、または追加規則を真と評価させるファクトとしてアクションがアサートされ得るように、アクションを規則エンジンインターフェース131に提供し得る。
[0052]規則リポジトリ133中に記憶された規則ベースは、たとえば、新たな規則を受信し、または規則を自動作成することによって、ランタイムに動的に更新され得る。さらに、規則リポジトリ133は、デバイス100のコンテキスト認識をサポートするための、規則ベースに対する更新を受諾し得る。規則リポジトリ133は、リモートソースからの規則も受諾し得る。たとえば、規則更新は、ファイル(たとえば、SDカードからのバイナリファイル)、ユニフォームリソース識別子(URI)(たとえば、サーバから、もしくはクラウドからのバイナリ規則)、または資産(たとえば、資産ディレクトリからロードされた資産)からロードされ得る。これらの規則更新は、事前コンパイルされ得、規則変換器(図示せず)によってコンパイルされてもよい。
[0053]いくつかの実施形態では、規則エンジンプラットフォーム130は、知識リポジトリ134をさらに含む。知識リポジトリ134は、RAMなどのメモリ120中に含まれ得る。知識リポジトリ134は、メモリ120に加えて、プロセッサ110におけるキャッシュなどのキャッシュまたはバッファ中で分散され得ることを諒解されたい。知識リポジトリ134は、ファクトベース、つまり、規則エンジン132が規則を評価するのに使うことができるファクトを記憶し得る。ファクトベースは、規則エンジン132によって構築された組織的構造の一部であってよい。一実施形態では、モジュール101〜106からのファクトは、モジュール101〜106からの、センサ(たとえば、加速度計、カメラ、オーディオなど)サンプルなど、未処理の未加工データ、または処理済みの個々の情報(たとえば、歩行中、運転中、疾走中、休憩中、飛行中などのうちの1つであってもよい動き状態)を含む。ファクトは、モジュール101〜106のうちの1つまたは複数から受信されたサンプル、推論、予想サンプル(たとえば、まだ受信されていないサンプル)、コンテキスト、別の規則(たとえば、アクションもしくは結果)または規則エンジン132によって監視可能な他のどのデータからの、知識リポジトリ134中でアサートされる、ゼロ(たとえば、ヌル)以上のデータオブジェクトからなるデータタプルであってよい。
[0054]一実施形態では、たとえば、規則エンジン132が初期化された場合またはどのサンプルも受信されていない場合、1つまたは複数のファクトが、デフォルト(たとえば、ヌルまたは偽)にアサートされる。知識リポジトリ134中のファクトベースは、ランタイムに動的に更新され得る。たとえば、古くなったサンプルからアサートされたファクトは、現在のサンプルで更新され、デフォルト値から更新され、または新たなサンプルから新たなファクトがアサートされ得る。ファクトベースに対する更新に応答して、規則エンジン132は、規則リポジトリ133中の規則を識別および/または評価し得る。一実施形態では、受信サンプルがファクトに実質的に影響を与える場合、規則エンジン132は、そのファクトをアサートするだけでよい。たとえば、記憶されたロケーションファクトは、新たに受信されたロケーションサンプルについて、ロケーションが同じままである場合、繰り返しアサートされる必要はない。
[0055]一実施形態では、規則エンジン132は、1つまたは複数のファクトまたはサンプルを検査して、推論を行い、それらの推論を、知識リポジトリ134中のファクトとしてアサートしてよい。たとえば、規則エンジン132は、ユーザが職場にいることを示すロケーションサンプルを受信し、ユーザが、会議に出ると計画されておらず、動いていないことを示すファクトを使って、ユーザが職場で対応可能であるというファクトをアサートすることができる。ロケーションサンプルは、ファクトとして個々にアサートされ、記憶され、または破棄され得る。
[0056]さらに、規則エンジン132は、知識リポジトリ134中にコンテキストを記憶し得る。コンテキストは概して、デバイス100またはデバイス100のユーザの環境もしくは状況として理解される。例示的には、コンテキストは、デバイス100のユーザが、会議中、話し合い中、電話中、ジオフェンスの近くにいる、人の近くにいる、自宅にいる、運転中である、などであってよい。コンテキストは、デバイス100のユーザが現在、運転中であり、ジオフェンスに近づきつつあるというコンテキストなど、コンテキストまたは予期情報の集合体であり得る。一実施形態では、規則エンジン132は、1つまたは複数のサンプルまたはファクトから推論を行うことによって、コンテキストを決定する。代替として、規則エンジン132は、コンテキスト認識モジュールなどのモジュール101〜106から、コンテキストを、サンプルとして受信し得る。規則エンジン132は、コンテキストからのファクトをアサートし得、および/またはコンテキストに基づいて、ファクトと規則とを組織化し、評価し得る。
[0057]いくつかの実施形態では、規則エンジンプラットフォーム130は、たとえば、明示的定義なしに、デバイス100のユーザの意図、条件または環境を導出するための1つまたは複数のサンプル、ファクト、または規則を処理することによって、スマートサービスをサポートする。たとえば、モジュール101〜106は、規則を真と評価させる明示的条件を提供することなく、規則の追加を要求し得る。規則エンジンプラットフォーム130は、不確定またはあいまいな条件を有する規則を、評価可能規則に変換し得る。例示的には、知的パーソナルアシスタントアプリケーションモジュール105が、ユーザ入力に従って、「友人の誕生日に、ユーザに通知する」という新たな規則の追加を要求し得る。規則エンジンプラットフォーム130は、友人の誕生日(たとえば、12月20日)のカレンダ日付を含む連絡先/アドレス帳アプリケーションモジュール106に対してサンプルを要求することによって、規則を変換し得る。そのサンプルを使って、「日付が12月20日である場合、ユーザに、今日が友人の誕生日であると通知する」という明確な規則が規則リポジトリ133に追加され得る。別の例では、アプリケーションモジュール105が、「ユーザに、食料品を買うよう通知する」という新たな規則の追加を要求する。規則エンジンプラットフォーム130は、この規則を、食料品店を含むジオフェンスなど、規則に関連したコンテキストを決定することによって変換し得る。そのサンプルを使って、規則エンジンインターフェース131は、「ユーザがジオフェンスの近くにいる場合、ユーザに、食料品を買うよう通知する」という明確な規則を規則リポジトリ133に追加し得る。その後、ユーザのロケーションが、ジオフェンスの近くまたはフェンス内であることを示すサンプルが受信されると、規則エンジン132は、食料品を買うようユーザに通知するためのアクションを決定する。
[0058]いくつかの実施形態では、リポジトリ133〜134の一方または両方が、知識および展開の資産管理用のリポジトリとして作用する。リポジトリは、ある物理エンティティ中に集中されても、様々なハードウェアモジュールおよびサブシステムにわたって分散されてもよい。この資産管理は、モジュール101〜106が、データと、他の同様の制約とにアクセスするための許可を指定するアクセス制御ポリシーを含み得る。リポジトリ133〜134は、モジュール101〜106のうちの1つまたは複数が規則にどのように関連付けられているかなど、規則および/またはファクトに関連付けられたメタデータを維持し得る(たとえば、規則エンジンプラットフォーム130にサブスクライブしているモジュール101〜106のリストおよび/またはサンプルがファクトをアサートすることをそこから求められるモジュール101〜106のリスト)。一実施形態では、リポジトリ133〜134は、受信サンプルや過去のコンテキストなど、ファクトとしてアサートされないデータを記憶する。たとえば、ロケーションサンプルは、ファクトをアサートするのに使われないが、結果としてロケーションサンプルをモジュール101〜106に送ることになる規則に必要とされ得る。同様に、コンテキストは、規則エンジン132またはコンテキスト認識エンジン(図示せず)が、コンテキストの間の関係を導出するか、または今後のコンテキストを予期することができるように記憶され得る。
[0059]プラットフォーム130としての規則エンジン132の実装により、規則エンジン132は、リポジトリ133〜134に記憶された情報から、由来情報(provenance information)を提供し得る。規則エンジンプラットフォーム130は、由来情報を、ディスプレイモジュール103に向かっているユーザに提供し得る。由来情報を、そのような情報を監視するように適合されたモジュール101〜106に提供してもよい。一実施形態では、由来情報は、規則の評価および対応する、アクションの決定に関連した情報を含み得る。そのような由来情報は、規則を評価させたファクトまたはファクトをアサートするためのサンプルを提供したモジュール101〜106についての情報を含み得る。
[0060]いくつかの実施形態では、規則エンジン132は、由来に関連した情報を、リポジトリ133〜134に記憶するように構成される。たとえば、規則エンジン132は、規則が評価された時間、規則を評価させた条件(たとえば、ファクト)、規則の評価から決定されたアクション、規則を真と評価させた以前の規則、または他の関連情報を記憶し得る。いくつかの実施形態では、規則エンジン132は、アクションを受信したモジュール101〜106またはファクトがそれについてアサートされたサンプルを提供したモジュール101〜106など、モジュール101〜106に関連した情報をトレースする。たとえば、リッチサイトサマリ(RSS)アプリケーションモジュール105〜106によって提供されたサンプルに準じるニュースレポート通知が、ディスプレイモジュール103上に表示され得る。通知は、RSSアプリケーションモジュール105〜106の識別またはニュースレポートが、ユーザにとって興味のあるカテゴリでタグ付けされるという指示など、RSSアプリケーションモジュール105〜106についての由来情報で補足され得る。
[0061]一実施形態では、規則エンジン132は、モジュール101〜106のアクティビティに関連した情報を記憶する。多数のサンプルを送り、または多数のアクションを受信するモジュール101〜106は概して、よりアクティブでないモジュールよりも大量のリソースを消費する。規則エンジン132は、電力消費、プロセッサ110の負荷に対する影響、別のモジュールに対する影響(たとえば、eメールアプリケーションモジュール105〜106が、新たなeメールメッセージについてポーリングすることによって、セルラートランシーバモジュール101〜102のアクティビティを増し得る)、または他のリソース消費など、モジュール101〜106についてのアクティビティ情報または使用統計を、記憶された情報から導出し得る。
[0062]したがって、規則エンジン132は、たとえば、モジュール101〜106に送られるアクションの頻度もしくは量、モジュール101〜106向けの規則の評価、またはモジュール101〜106によって提供されるサンプルからアサートされたファクトを追跡することによって、モジュール101〜106を監視し得る。たとえば、ロケーションベースのソーシャルネットワーキングアプリケーションモジュール105〜106(たとえば、Foursquare(登録商標))が、「このアプリケーションモジュールが実行中である場合、このアプリケーションに現在のロケーションを送る」という規則を追加し得る。そのような規則は、真と永続的に評価し、したがって、アプリケーションモジュール105〜106が実行している間、大量のリソースを消費させ得る。規則エンジン132は、プロセッサ110またはSPSセンサモジュール101〜102における電力消費または影響など、アプリケーションモジュール105〜106のリソース消費に関連した情報を記憶し得る。記憶された情報から、規則エンジン132は、デバイス100にとってコストがかかるモジュールなど、モジュール101〜106についての使用情報を決定することができる。
[0063]図2は、ポータブル電子デバイス内で規則エンジンプラットフォームを提供するためのシーケンス200を示す。いくつかの実施形態では、シーケンス200の動作は、置き換えられても、同時発生であってもよい。図示されるシーケンスは、図1のポータブル電子デバイス100の実施形態において実施することができる。したがって、規則エンジンインターフェース230は、規則エンジンインターフェース131であっても、それを含んでもよく、規則エンジン240は、規則エンジン132であっても、それを含んでもよく、リポジトリ250は、規則リポジトリ133および知識リポジトリ134であっても、その一方または両方を含んでもよい。
[0064]図1において、モジュール101〜106は、モジュールの各々が、概念的に同様の機能を実施するように構成され得ることを示すように抽象的に表されている。この機能は、規則エンジンプラットフォーム130にデータを送ること、またはプラットフォーム130からデータを受信することであってよい。図2によると、サンプリングモジュール210および受信モジュール220は、それぞれ、図1に示されるモジュール101〜106のうちのいずれであっても、それを含んでもよい。いくつかの実施形態では、サンプリングモジュール210および受信モジュール220は同じモジュールである。
[0065]モジュール101〜106は、モジュール101〜106に関連付けられたデータを送ることができ、この送られるデータは、それぞれのモジュール101〜106についてのサンプルとして解釈され得る。したがって、サンプリングモジュール210は、サンプルを送るように構成されたどのモジュール101〜106であってもよい。サンプルは、センサモジュールからの未加工入力データ(たとえば、ジャイロスコープからの電圧)、センサモジュールからの処理済みデータ(たとえば、磁力計からの基本または順序方位)、アプリケーションモジュールからのデータ(たとえば、メッセージ通信アプリケーションからの通知)、またはモジュール101〜106によって提供され得る他のどのデータであってもよい。多くの実施形態において、規則エンジンインターフェース230は、サンプルが送られる前にサンプリングモジュール210にサブスクライブする。
[0066]例示的には、ハードウェアモジュール101が慣性センサである実施形態において、ハードウェアモジュール101は、測定された向きを含むサンプルまたは測定された向きが閾量を超えて変化したという指示であるサンプルを送ることができる。同様に、アプリケーションモジュール105がメッセージ通信アプリケーションである実施形態において、アプリケーションモジュール105は、新たなメッセージが受信されたという指示を含むサンプルまたは新たなメッセージのテキストを含むサンプルを送ることができる。両方の例において、モジュール101および105は、サンプリングモジュール210として動作する。したがって、モジュール101〜106の多くは、サンプリングモジュールとして同時に作用し得る。サンプリングモジュール210は、要求またはイベントに応答して(たとえば、所定の時間に)、規則エンジンインターフェース230にサンプルを送ることもでき、サンプルは送信請求されなくてもよい。
[0067]サンプルを送るのと同様に、モジュール101〜106は、アクションなどのデータを受信することができる。アクションを受信するように構成されたモジュール101〜106は、受信モジュール220であり得る。たとえば、ハードウェアモジュール101がカメラモジュールである実施形態において、ハードウェアモジュール101は、シャッターを解放するためのコマンドを含むアクションを受信し得る。同様に、アプリケーションモジュール105がカレンダアプリケーションである実施形態において、アプリケーションモジュール105は、新たなイベントをカレンダに追加するためのアクションを受信し得る。両方の例において、モジュール101および105は、受信モジュール220として動作する。したがって、モジュール101〜106の多くは、受信モジュールとして同時に動作し得る。多くの実施形態において、受信モジュール220は、アクションが送られる前に規則エンジンインターフェース230にサブスクライブする。
[0068]一実施形態では、シーケンス200は、規則エンジンインターフェース230がサンプリングモジュール210にサブスクライブし、またはモジュール210を監視した場合に始まる(動作251)。このサブスクリプションは、規則エンジン240からの要求に応答したものであってよい。サンプリングモジュール210にサブスクライブし、またはモジュール210を監視する際、規則エンジンインターフェース230は、サンプリングモジュール210から1つまたは複数のサンプルを受信し得る。一実施形態では、サブスクリプションは、規則エンジンインターフェース230による、サンプリングモジュール210に対するサンプルについての単独要求であり得る。他の実施形態では、規則エンジンインターフェース230は、たとえば、ポーリングし、サンプルのストリームを受信し、または1つもしくは複数のサンプルについてサンプリングモジュール210を繰り返し問い合わせる(query)ことによって、サンプリングモジュール210に永続的にサブスクライブすることができる。規則エンジンインターフェース230は、サンプリングモジュール210に関連付けられたインターフェース(たとえば、API)を通して、サンプリングモジュール210に永続的にサブスクライブするようにも構成され得る。
[0069]規則エンジンインターフェース230による、サンプリングモジュール210へのサブスクリプションは、実施形態によって変わり得る。いくつかの実施形態では、規則エンジンインターフェース230は、異なるサブスクリプションに対しては異なるサンプルが提供されるように、サンプリングモジュール210への2つ以上のサブスクリプションを有し得る。たとえば、サンプリングモジュール210がメッセージ通信アプリケーションである実施形態では、
サンプリングモジュール210が、メッセージのサブジェクトまたは本文を含むサンプルを提供するように、規則エンジンインターフェース230は、サンプリングモジュール210にサブスクライブすることができる。代替として、サンプルは単に、サンプリングモジュール210において新たなメッセージが受信されたという通知であるように、規則エンジンインターフェース230は、サンプリングモジュール210にサブスクライブすることができる。重要なこととして、規則エンジンインターフェース230は、サンプリングモジュール210を含む複数のサンプリングモジュールに同時にサブスクライブすることができる。
[0070]やはりシーケンス200の一部として、受信モジュール220は、規則エンジンインターフェース230にサブスクライブする(動作252)。受信モジュール220は、規則エンジンインターフェース230が送るように構成されている1つまたは複数のアクションにサブスクライブすることができる。たとえば、受信モジュール220は、受信モジュール220向けのアクションを生じる規則を含むように、規則ベースを更新し得、または受信モジュール220は、規則エンジンインターフェース230への特定の呼出しを行うことができる。また、受信モジュール220は一般的に、規則エンジンインターフェース230にサブスクライブすることができる。一実施形態では、サブスクリプションは、規則エンジンインターフェース230に対するアクションについての単独要求であってよい。他の実施形態では、受信モジュール220は、規則エンジンインターフェース230によって提供される1つまたは複数のアクションに永続的にサブスクライブができる。
[0071]例示的な一実施形態では、受信モジュール220は、ジオフェンスに基づいて、ユーザに通知する(たとえば、ディスプレイ上に通知を提示する)アプリケーションである。そのような実施形態において、シーケンス200を実施しているデバイスがジオフェンス外周(perimeter)を通り抜けるとき、受信モジュール220には、規則エンジンインターフェース230によってジオフェンスアクションが提供されるように、受信モジュール220は、規則エンジンインターフェース230によって提供されるジオフェンスアクションにサブスクライブする。
[0072]一実施形態では、受信モジュール220は、規則エンジンインターフェース230によって提供される1つまたは複数のアクションに自動的にサブスクライブされる。この自動サブスクリプションは、規則エンジンプラットフォームを有するポータブル電子デバイスにおいて実装されたことの結果であり得る。そのような実施形態において、規則エンジン240は、規則エンジンインターフェース230を通して(たとえば、一般的なメッセージ通信バスを経由して)アクションをブロードキャストし得、受信モジュール220は、そのアクションを受信するように構成される(たとえば、アクションは、受信モジュール220によって、1つまたは複数の他のモジュールと同時期に受信され得る)。
[0073]多くの実施形態において、サンプリングモジュール210は、サンプルが生成されるようにトリガされ得る(動作253)。たとえば、シーケンス200を実施しているデバイスが、特定の軸に対して向きを変えた場合、慣性センササンプリングモジュール210がトリガされ得る。検出された向きの変化が、慣性センササンプリングモジュール210がサンプルを送ることをトリガし得る。いくつかの実施形態では、たとえば、サンプリングモジュールがサンプルの連続ストリームを生じる場合、サンプリングモジュール210は、永続的にトリガされ得る。別の実施形態では、サンプリングモジュール210は、規則エンジンインターフェース230によるサブスクリプションに応答して、サンプルを生じるようにトリガされ得る(たとえば、サンプリングモジュールは、規則エンジンインターフェース230からの、問い合わせに対する応答を提供するようにトリガされ得る)。
[0074]サンプリングモジュール210が、サンプルを生じるようにトリガされた場合、サンプリングモジュール210は、規則エンジンインターフェース230にサンプルを送り、または提供するように構成される(動作254)。多くの実施形態において、サンプリングモジュール210によって規則エンジンインターフェース230に送られるサンプルは、サンプリングモジュール210への規則エンジンインターフェース230のサブスクリプション(動作251)に従う。
[0075]いくつかの実施形態では、サンプリングモジュール210から受信されるサンプル(動作254)は、規則エンジン240による解釈に適さない。したがって、規則エンジンインターフェース230は、サンプルを、規則エンジン240によって解釈可能な形式に適合させるように構成される(動作255)。サンプルの適合は、規則エンジンインターフェース230によって遂行され得る。たとえば、規則エンジンインターフェース230は、サンプルを無秩序化(unmarshal)し得る。他の実施形態では、規則エンジンインターフェース230は、規則エンジンアダプタ(図示せず)など、1つまたは複数の追加構成要素とともに、サンプルを規則エンジン240向けに適合させるように動作する。
[0076]いくつかの他の実施形態では、規則エンジン240は、所定のレートで規則エンジン240にサンプルを提供するAPIを含み得る。例によると、ユーザ入力モジュール(たとえば、モジュール210、220)は、ポータブル電子デバイスのロケーションが10分おきに更新されるべきであるか、または2分おきの最大周期で、モジュール(たとえば、モジュール210、220)によってeメールがダウンロードされるべきであると指定する、ユーザからの入力を受諾し得る。規則エンジン240は、ユーザからの入力に従って、サンプリングモジュール210のサンプリングレートを指定し得る。規則エンジンインターフェースに含まれるAPIは、ユーザインターフェースモジュール(たとえば、モジュール210または220)が、サンプルモジュール210のサンプリングレートに対するこの変更を行うことを可能にする。
[0077]いくつかの実施形態では、規則エンジン240は、異なるアプリケーションから取得される、起こり得る競合要件を扱うように構成され得る。たとえば、デバイス上で稼動しているソーシャルアプリケーションが、ロケーションが10分おき更新されることを求め、天気アプリケーションが、ロケーションフィックス(fix)を6分おきに求めるケースについて検討する。規則エンジン240は、それに応じて、2つのアプリケーションの要望を満たすように、サンプリングレートを適合させ、いくつかのそのような実施形態では、電力を削減するために、複数のアプリケーションにわたってロケーションフィックスを再利用し得る。
[0078]センサのサンプリングを変調する規則エンジンの一部は、集中型ユニットに物理的に存在し得、デバイス内の個々のサブシステムにわたって分散され得ることに留意されたい。
[0079]サンプルを適切に適合させると、規則エンジンインターフェース230は、適合されたサンプルを規則エンジン240に提供するように構成される(動作256)。いくつかの実施形態では、サンプルは、規則エンジン240からの要求に応答して提供される。規則エンジンインターフェース230は、受信モジュール220からのサブスクリプション(動作252)に従って、規則エンジン240に、サンプルを提供し得る。いくつかの実施形態では、追加サンプリングモジュールから受信され得るサンプル(たとえば、リポジトリ250に記憶されている受信サンプル)は、サンプルのセットに追加される。サンプルのフルセットまたは部分セットが次いで、規則エンジン240に提供され得る。
[0080]いくつかの実施形態では、規則エンジン240は、たとえば、ファクトを追加または更新することによって1つまたは複数の規則の評価に使われるファクトをアサートする(動作257)。規則エンジン240は、サンプルを、たとえばリポジトリ250中または他のメモリ中に記憶することによって、ファクトをアサートし得る。代替として、ファクトは、サンプルから導出された推論、および1つまたは複数の他のファクトまたはサンプルからアサートされ得る。他の実施形態では、規則エンジン240は、ファクトベースの規則または予想サンプル(たとえば、サンプルがないこと)をアサートする。一実施形態によると、規則エンジン240は、リポジトリ250中で定義される規則の一部または全部に基づいて、組織的構造を構築する。1つまたは複数のサンプルに応答して、規則エンジン240は、ファクトをアサートすることによって組織的構造を更新することができる。重要なこととして、ファクトは、まさにサンプルが提供される所を超えて、シーケンス200の異なる動作に続いてアサートされ得る。たとえば、規則の評価(動作259)および/またはアクションの決定(動作260)が、ファクトをアサートさせ得る(動作257)。いくつかの実施形態において、シーケンス200は、規則の評価またはアクションの決定からファクトがアサートされている(動作257)場合、関連規則を選択および評価すること(動作258〜259)、ならびにアクションを決定すること(動作260)によって再開する。
[0081]規則エンジン240は、アサートされたファクトについての1つまたは複数の関連規則を選択または識別するように構成される(動作258)。規則エンジン240は、リポジトリ250から、1つまたは複数の関連規則を選択し得る。いくつかの実施形態では、規則は、少なくとも1つのファクトと1つのアクションとの間の条件付き関係を定義する。したがって、規則エンジン240は、1つまたは複数の規則を選択または識別し、ここでファクトは、条件の全部または一部を満足する。関連規則を選択する際、規則エンジン240は、追加資産(additional assets)も選択し得る。いくつかの実施形態では、資産は、規則を特定のモジュール(たとえば、サンプリングモジュール210および/または受信モジュール220)に関連付けるメタデータを含む。資産は、いくつかの規則に関連付けられた許可についての1つまたは複数のアクセス制御リストも備え得る。
[0082]1つまたは複数の関連規則の選択または識別は、リポジトリ250への、規則についての実際の要求または問い合わせでなくてよい。いくつかの実施形態では、規則エンジン240は、リポジトリ250からすでに選択されている関連規則を識別する。たとえば、規則エンジン240は、評価を予期するコンテキストに基づいて、関連規則をキャッシュすることができる。
[0083]関連規則が選択されていると、規則エンジン240は、アサートされたファクトについて、関連規則を評価する(動作259)。重要なこととして、規則エンジン240による規則実行プロセスは、複雑であり、規則を評価するのに、ファクトとしてアサートされた複数のサンプル(または、1つもしくは複数のサンプルがないこと)を必要とし得る。たとえば、「ポータブル電子デバイスのユーザが会議中である場合、オーディオ通知を不能にする」という規則を評価するために、規則エンジン240は、カレンダサンプリングモジュールからの、ユーザが会議に出ると計画されているというサンプル、ならびにSPS(またはWi−Fi)サンプリングモジュールからの、会議のロケーション(または部屋)を含むジオフェンス内にデバイスがあるというサンプル、を受信し得る。規則エンジン240は、これらの2つのサンプルを、別々のファクトとして、またはユーザが「会議中」であることを示す1つのファクトとしてアサートし得る。アサートされた(1つまたは複数の)ファクトに応答して、オーディオ通知が不能にされる。さらに、規則エンジン240は、ファクトとしてアサートされた受信サンプルを、後で規則を評価するために維持するように構成される。
[0084]規則エンジン240による、ある規則の評価は、第2の規則の評価を要求し(mandate)得る。1つまたは複数の追加規則の識別および選択は、先行規則または規則のセットの評価に応答して行われ得る。規則エンジン240は、規則を評価し、アクションを決定するのに、追加ファクトも必要とし得る(推論からアサートされる例示のファクトが、図6に示されている)。たとえば、Bluetoothサンプリングモジュール210が、ポータブル電子デバイスがユーザの車のオーディオシステムとペアにされていることを示すサンプルを送る場合、規則エンジン240は、ユーザが車の中にいるというファクトをアサートできる。しかし、規則エンジン240は、ユーザが動いていることを示すロケーションサンプルが受信されるか、または加速度計サンプルが、車両の予想される速度での(すなわち、歩行速度ほど遅くなく、飛行機の速度ほど速くない)動きを示すまで、ユーザが運転中であるというファクトはアサートしない。その後、規則エンジン240は、ユーザが運転中であるという、アサートされたファクトについての規則を評価すればよい。運転中規則は、テキストメッセージング用のタッチ入力をディセーブルにし得、したがって、規則エンジン240は、規則に、テキストメッセージング用に発話入力をイネーブルにするように評価させるファクトをアサートし得る。
[0085]規則エンジン240が、1つまたは複数の関連規則を真と評価した場合、規則エンジン240は、1つまたは複数の関連規則に従ってアクションを決定するように構成される(動作260)。アクションは、関連規則を真と評価した結果から決定され得る。多くの実施形態において、決定されたアクションは、規則の結果である。
[0086]一実施形態では、規則エンジン240は、アクションは何もしないことであると決定し得る。それに応答して、規則エンジン240は、規則エンジンインターフェース230にアクションを提供しないか、または規則エンジンインターフェース230がどのアクションも送出しないように、ヌルアクションを提供し得る。規則エンジン240は、アクションが、どのアクションもとらないという応答であると決定する場合もある。規則エンジンインターフェース230は次いで、どのアクションもとらないという応答を、(たとえば、メッセージとして、またはヌル値を戻すことによって)受信モジュール220に提供し得る。
[0087]他の実施形態では、リポジトリ250から選択されるメタデータは、アクションを補足する。たとえば、規則エンジン240が、サンプリングモジュール210において新たなメッセージが受信されたというファクトについて、関連規則を真と評価した場合、メタデータは、決定されたアクションが、メッセージのテキスト、または代替として、新たなメッセージが受信されたという通知を送ることを規定し得る。メタデータは、決定されたアクションに従って通知されるべき、ポータブル電子デバイス内の受信モジュール220の識別も示し得る。メタデータは、時間または行為パラメータなどの補足パラメータも含み得る。いくつかの実施形態では、メタデータは、決定されたアクションに含まれ、そうすることによって、受信モジュール220は、サンプリングモジュール210、または受信モジュール220へ決定されたアクションを送ることをトリガした特定の規則、を識別することが可能である。
[0088]続いて、規則エンジン240は、決定されたアクションを規則エンジンインターフェース230に提供する(動作261)。規則エンジンインターフェース230は次いで、決定されたアクションを、受信モジュール220への送信およびモジュール220による受信に適した形式に適合させるように構成される(動作262)。他の実施形態では、規則エンジンインターフェース230は、規則エンジンアダプタなど、1つまたは複数の追加構成要素とともに、アクションを受信モジュール220に適合させるように動作する。一実施形態では、規則エンジンインターフェース230は、決定されたアクションを秩序化する(marshal)ことができる。シリアライゼーションなど、他の適した適合技法が、規則エンジンインターフェース230によって使われ得る。
[0089]規則エンジンインターフェース230は次いで、決定されたアクションを受信モジュール220に送る(動作263)。一実施形態では、受信モジュール220の識別は、規則エンジン240によって(たとえば、1つまたは複数の規則に関連付けられたメタデータを通して)提供される。いくつかの実施形態では、規則エンジンインターフェース230は、決定されたアクションを(たとえば、一般的なメッセージ通信バスを通じて)ブロードキャストし得、受信モジュール220は、ブロードキャストからアクションを受信し得る。したがって、受信モジュール220は、決定されたアクションを送るとき、具体的に識別され、目標とされる必要はない。受信モジュール220は、決定されたアクションを、受信モジュール220の実施形態に従って扱う。
[0090]図3Aは、本発明の一実施形態による、ポータブル電子デバイス内の規則エンジンプラットフォームによって実施される方法300の例を示す。図3Aの動作は、例示的であり、必ずしも図示される順序で実施されるとは限らない。方法300は、図1に示されるポータブル電子デバイス100の規則エンジンプラットフォーム130によって実施することができ、たとえば、動作は、規則エンジンインターフェース131および/または規則エンジン132によって実施することができる。方法300を実行する規則エンジンプラットフォームは、モジュールおよびプロセッサなど、規則エンジンプラットフォームが実装されるデバイスの他の構成要素と通信可能に結合され得る。一実施形態では、規則エンジンプラットフォームは、ハードウェア、ストレージ、1つまたは複数のプロセッサ、モジュールまたはポータブル電子デバイスの他の構成要素にわたって分散される個々の構成要素に分割され得る。規則エンジンプラットフォームは、そのような構成要素に関連付けられた機能性およびデータへのアクセスを有し得る。
[0091]最初に、規則エンジンプラットフォームは、規則エンジンプラットフォームと通信可能に結合された1つまたは複数のモジュールの挙動(behavior)に影響を及ぼし、または支配し得る複数の規則を受信する(動作305)。規則は、規則エンジンプラットフォームと通信可能に結合されたモジュール(たとえば、モジュール101〜106)から、リモートソース(たとえば、クラウドやURI)から、またはローカルソース(たとえば、メモリもしくは取外し可能フラッシュメモリデバイス内のディレクトリ)から、ランタイムに動的に受信され得るが、規則は、あらかじめ規定され(たとえば、規則エンジンプラットフォームのコンパイル時に受信され)てもよい。受信された規則は、規則リポジトリ(たとえば、規則リポジトリ133)中に記憶された既存の規則ベースを更新し得、または規則リポジトリの設計時もしくは他のコンパイル時に受信され得る。一実施形態では、複数の規則は、問い合わせ(クエリ)など、規則エンジンプラットフォームからの要求に応答して受信され得る。
[0092]規則エンジンプラットフォームは、受信された複数の規則に応答して、組織的構造を構築することができる。組織的構造は、規則エンジンプラットフォームが新たに初期化される開始状態を示すことができる。一実施形態では、組織的構造は、規則を真と評価させるいくつかのファクトを含む。ファクトは、最初に、ヌルまたは偽などのデフォルトにアサートされ得る。規則エンジンプラットフォームは、既存の組織的構造を更新する複数の規則も受信し得る。規則エンジンプラットフォームは次いで、既存の組織的構造を、たとえば、既存の要件を修正し、廃止された要件を削除し、新たに共有される要件を識別することによって、複数の受信された規則を組み込むように更新するように構成される。
[0093]複数の規則に加えて、方法300を実施する規則エンジンプラットフォームは、図1のモジュール101〜106など、少なくとも1つのサンプリングモジュールから少なくとも1つのサンプルを受信するように構成される(決定ブロック310)。ただし、サンプルは、すべての事例において受信されなくてもよい。たとえば、規則エンジンプラットフォームがモジュールに問い合わせしていない場合、またはモジュールによって提供されるサンプルストリームが存在しない場合、サンプルは受信され得ない。しかし、規則エンジンプラットフォームは、たとえば、サンプリングモジュールへのサブスクリプションに基づいて、サンプリングモジュールから受信されるべきサンプルを決定し得る。一実施形態では、規則エンジンプラットフォームは、組織的構造に基づいて、受信されるべきサンプルを決定し得、たとえば、規則エンジンプラットフォームは、規則を分解して、組織的構造を構築するための必要とされるファクトを識別し、そうする際、当該必要とされるファクトがそこからアサートされ得るサンプルを決定し得る。
[0094]サンプルが受信された場合、方法300を実施する規則エンジンプラットフォームは、ファクトが更新されるべきであることをサンプルが示すかどうか決定し得る(決定ブロック320)。たとえば、受信サンプルが新たなデータ(たとえば、新たなメッセージ)または環境の変化(たとえば、新たなコンテキスト)を示す場合、ファクトは、規則エンジンプラットフォームを実装するデバイスの現在の状態を反映するように更新され得る。たとえば、ソーシャルネットワーキングモジュールから新たなメッセージサンプルが受信された場合、新たなメッセージファクトが更新され得る。さらに、サンプルがファクトを全体的に修正した場合、当該ファクトの他の構成成分(たとえば、ファクトまたはサンプル)が有効なままであっても、当該ファクトが更新され得る。たとえば、サンプルまたはファクトの組合せ(たとえば、推論)は、ユーザが睡眠中であるというファクトをアサートさせ得るが、ユーザが動いていることを示す動き状態サンプルの受信は、ファクトが、ユーザが睡眠中でないことを示すように更新されることを求め得る。
[0095]必要に応じて、サンプル受信に準じるファクトが、リポジトリ(たとえば、リポジトリ133、134)中でアサートされる(動作325)。一実施形態では、サンプルまたはサンプルがないことがファクトを実質的に更新する(たとえば、ファクトの真の値を変更する)場合のみ、ファクトがアサートされる。ファクトは、RAM、キャッシュメモリ、バッファ、または瞬間的アクセスならびに今後のアクセスのための記憶ロケーションの組合せなどのメモリ中に記憶されることによって、リポジトリ中でアサートされ得る。ファクトは、リポジトリ中にすでに記憶されていてよい、サンプルまたはファクトの組合せ(たとえば、推論)としてアサートされ得る。一実施形態では、ファクトは、更新を反映するように組織的構造を更新することによってアサートされる。さらに、ファクトは、不揮発性メモリなどの持続記憶装置に追加され得る。
[0096]いくつかの実施形態では、サンプル受信に従って複数のファクトがアサートされ得、すなわち、受信サンプルまたは受信サンプルがないことは、2つ以上のファクトの同時期更新を要し得る。特に、これは、1つのサンプルからアサートされるファクトと、当該1つのサンプルを含む複数のサンプルまたはファクトからアサートされる1つまたは複数のファクトとについての場合であり得る。
[0097]リポジトリ中のファクトに従って、方法300を実施する規則エンジンプラットフォームは、1つまたは複数の規則を識別するように構成される(動作330)。図示されるように、規則エンジンプラットフォームは、アサートされたファクトに応答して、規則を識別し得る(たとえば、アサートされたファクトが、規則の条件を満足することを求められる場合)。代替として、規則エンジンプラットフォームの初期化時など、どのファクトも更新されない場合、または(たとえば、クロック信号に従って)特定の時間に規則が識別されるべきである場合、規則が識別され得る。規則は、識別され、続いて、たとえば規則エンジン132が規則リポジトリ133から規則を選択する場合、規則リポジトリから選択され得る。ただし、規則は、直ちに評価されなくてよいが、規則を真と評価させる追加ファクトがアサートされたとき、評価を迅速化するために、バッファリングまたはキャッシュされ得る。
[0098]いくつかの実施形態では、規則の階層または他の規則に関係した規則の顕著属性などの競合解決アジェンダに従って、規則が識別される。競合解決アジェンダに従って規則を識別することにより、真と評価されるとき、複数の規則がリポジトリ中のファクトに関連するが競合する結果を有し得る事例の出現を減らすことができる。さらに、コンテキストに従って規則が識別され得る。したがって、リポジトリ中のファクトに関連し得るが対象のコンテキスト(たとえば、瞬間的コンテキスト、期待されるコンテキストまたは頻発するコンテキスト)に無関連の規則はバイパスされ、対象のコンテキストに関連する規則を識別する。
[0100]いくつかの実施形態では、各規則が、規則の重要性を示唆する、関連付けられた重みを有する。たとえば、より高い重みをもつ規則は、その規則が、低い重みをもつ規則に優先することを含意する。競合があるケースでは、これらの重みは、競合を解決するのに使うことができ、より高い重みをもつ規則が評価される。
[0101]規則を識別すると、規則エンジンプラットフォームは次いで、規則を評価し得る(動作335)。識別された規則を評価することは、(たとえば、サンプルもしくは論理値について)アサートされたファクトまたは追加ファクトを検査することを含み得る。たとえば、ユーザが運転中であるというファクトがアサートされた場合、規則エンジンプラットフォームは、ユーザが運転中である場合について真値を決定する規則を評価し得る。概して、規則の条件(たとえば、ファクト)すべてが満足される場合、規則は真と評価される。一実施形態では、規則が偽と評価される場合、第1の規則よりも劣った顕著属性を有する規則など、別の規則が識別および評価され得る。
[0102]いくつかの実施形態では、複数のファクトが、規則を評価するのに使われる。たとえば、受信された複数のうちの1つの規則が、ユーザが睡眠中であることが真である場合、オーディオ出力がディセーブルにされることを示し得る。この規則は、規則エンジンプラットフォームが推論を行い、したがって、ユーザが睡眠中であるというファクトをアサートするのに、2つのサンプル、すなわち(1)時間および(2)動き状態を必要とし得る。したがって、規則エンジンプラットフォームは、現在時刻が午前2:00であることを示す時間サンプルについてのファクトをアサートし、デバイスが動いていないことを示す別のファクトをアサートする(またはユーザが睡眠中であるという単一のファクトをアサートする)。規則エンジンプラットフォームは次いで、早朝であるとともにデバイスが動いていないので、ユーザが睡眠中であるというファクトに基づいて、規則を評価すればよい。
[0103]一実施形態では、規則は、規則の要件に従って組織的構造をトラバースする(または、「たどる」)(traverse)ことによって評価され得る。たとえば、規則は、3つの要件を有してよく、すなわち、規則が真と評価されるためには、ファクトAおよびBが真でなければならず、ファクトCは偽でなければならない。組織的構造は、ファクトAを検査し、Aが真の場合、ファクトBに進み、Bが真の場合、ファクトCに進むことにより、トラバースされ得る。ファクトCが次いで、偽の場合、規則は真と評価される。ファクトA、B、およびCが、異なるレートで、異なる瞬間に生じることが可能である。そのようなケースにおいて、ファクトは、リポジトリ中にキャッシュされ、各新たなファクトが入ってくると、再読込みされ得る。
[0104]1つまたは複数の規則を評価した後、方法300を実施する規則エンジンプラットフォームは、評価を使って1つまたは複数のアクションを決定する(動作340)。いくつかの実施形態では、たとえば規則が真と評価される場合、このアクションは、規則を定義する条件付きステートメントの「then」クローズ中に含められる。代替として、決定されたアクションは、何もしないことであってよい。図1に関係して、規則エンジン132はアクションを決定し得る。
[0105]いくつかの実施形態では、規則が真と評価される場合、複数のアクションが決定され得る。規則の結果が、デバイス内の複数のモジュールに影響を与える場合、および/または規則の結果が、複数のモジュールにわたって異なるように実装されるべきである場合、複数のアクションが決定され得る。複数のアクションは概して、各モジュールがアクションを受信するようにブロードキャストされてよい。他の実施形態では、複数のうちのそれぞれのアクションが、特定のモジュールまたはモジュールのタイプ(たとえば、メッセージ通信アプリケーションモジュールやロケーションベースのアプリケーションモジュール)向けに適合される。それぞれのアクションが、たとえば、規則に関連付けられたメタデータに基づいて、特定のモジュールまたはモジュールタイプ向けに適合され得る。
[0106]一実施形態では、アクションは、アクセス制御リストなど、規則に関連付けられたメタデータと関連して決定される。したがって、アクションは、規則の結果が、デバイス内で構成され得る許可と競合しないように決定され得る。代替として、アクションは、規則の結果がそのような許可と一致されるように決定され得る。たとえば、真と評価される規則の結果は、ユーザに通知することであってよいが、デバイス内で構成された許可が、オーディオ通知をディセーブルにしており、したがって、アクションは、ユーザにグラフィカルに通知することと決定され得る。
[0107]デバイス上で稼動する異なるモジュールが、異なる規則セットを提供し得ることが可能である。そのようなケースにおいて、規則エンジンプラットフォームは、プライバシーの理由により、およびあるアプリケーションの規則が他のアプリケーションの規則と干渉しないように、規則セットを別々に評価することを選ぶことができる。たとえば、規則エンジンプラットフォーム132は、アクセス制御ポリシーに従って規則を評価し得る。
[0108]いくつかの実施形態では、決定されたアクションが、リポジトリにおけるファクトを更新する(決定ブロック345)。したがって、方法300を実施する規則エンジンプラットフォームは、決定されたアクションからファクトをアサートし得る(動作325)。したがって、上述したように、1つまたは複数の追加規則が識別および評価され得る。
[0109]アクションの決定に続いて、方法300を実施する規則エンジンプラットフォームは、決定されたアクションを送る(動作350)。決定されたアクションの送付は、たとえば、規則エンジンプラットフォームのインターフェース(たとえば、規則エンジンインターフェース131)によって円滑にされ得る。他の実施形態によると、決定されたアクションは、オペレーティングシステムまたはASICを使って送られ得る。いくつかの実施形態では、決定されたアクションが、デバイス内の複数のモジュールに影響を与える。したがって、規則エンジンプラットフォームは、決定されたアクションを、複数の形式で複数のモジュールに送るように構成され得る。
[0110]図3Bは、本発明の一実施形態による、ポータブル電子デバイス内の規則エンジンプラットフォームによって実施される方法360の例を示す。図3Bの動作は、例示的であり、必ずしも図示される順序で実施されるとは限らない。方法360は、図1に示されるポータブル電子デバイス100の規則エンジンプラットフォーム130によって実施することができ、たとえば、方法360の動作は、規則エンジンインターフェース131および/または規則エンジン132によって実施することができる。方法360を実行する規則エンジンプラットフォームは、モジュールおよびプロセッサなど、規則エンジンプラットフォームが実装されるデバイスの他の構成要素と通信可能に結合され得る。
[0111]最初に、規則エンジンプラットフォームは、規則エンジンプラットフォームと通信可能に結合された1つまたは複数のモジュールの挙動に影響し、または挙動を支配し得る複数の規則を受信する(動作365)。規則は、規則エンジンプラットフォームと通信可能に結合されたモジュールから、リモートソース(たとえば、クラウドやURI)から、またはローカルソース(たとえば、メモリもしくは取外し可能フラッシュメモリデバイス内のディレクトリ)から、ランタイムに動的に受信され得るが、規則は、あらかじめ規定され(たとえば、規則エンジンプラットフォームのコンパイル時に受信され)てもよい。受信された規則は、規則リポジトリ(たとえば、規則リポジトリ133)中に記憶された既存の規則ベースを更新することもでき、または規則リポジトリの設計時もしくは他のコンパイル時に受信されてもよい。一実施形態では、複数の規則は、問い合わせ(クエリ)など、規則エンジンプラットフォームからの要求に応答して受信され得る。
[0112]規則エンジンプラットフォームは、受信された複数の規則に応答して、組織的構造を構築し得る。組織的構造は、規則エンジンプラットフォームが新たに初期化される開始状態を示すことができる。一実施形態では、組織的構造は、規則を真と評価させるいくつかのファクトを含む。ファクトは、最初に、ヌルまたは偽などのデフォルトにアサートされ得る。規則エンジンプラットフォームは、既存の組織的構造を更新する複数の規則も受信し得る。規則エンジンプラットフォームは次いで、既存の組織的構造を、たとえば、既存の要件を修正し、廃止された要件を削除し、新たに共有される要件を識別することによって、複数の受信された規則を組み込むように更新するように構成される。
[0113]必要に応じて、モジュール101〜106から受信されたサンプルなど、受信サンプルおよび予想サンプルのうちの1つに従って、ファクトが、リポジトリ中でアサートされる(動作370)。一実施形態では、サンプルまたはサンプルがないことがファクトを実質的に更新する(たとえば、ファクトの真の値を変更する)場合、当該ファクトがアサートされるのみである。ファクトは、RAM、キャッシュメモリ、バッファ、または瞬間的アクセスならびに今後のアクセスのための記憶ロケーションの組合せなどのメモリ中に記憶されることによって、リポジトリ中でアサートされ得る。ファクトは、リポジトリ(たとえば、リポジトリ133、134)中にすでに記憶され得るサンプルまたはファクトの組合せ(たとえば、推論)としてアサートされ得る。一実施形態では、ファクトは、更新を反映するように組織的構造を更新することによってアサートされる。さらに、ファクトは、不揮発性メモリなどの持続記憶装置に追加され得る。
[0114]いくつかの実施形態では、受信または予想サンプルに従って、複数のファクトがアサートされ得、たとえば、受信サンプルまたは予想サンプルは、2つ以上のファクトの同時期更新を要し得る。特に、これは、1つのサンプルからアサートされるファクトと、当該1つのサンプルを含む複数のサンプルまたはファクトからアサートされる1つまたは複数のファクトとについての場合であり得る。
[0115]リポジトリ中のファクトに従って、方法300を実施する規則エンジンプラットフォームは、1つまたは複数の規則を識別するように構成される(動作375)。図示されるように、規則エンジンプラットフォームは、アサートされたファクトに基づいて、規則を識別し得る(たとえば、アサートされたファクトが、規則の条件を満足することを求められる場合)。代替として、規則エンジンプラットフォームの初期化時など、どのファクトも更新されない場合、または(たとえば、クロック信号に従って)特定の時間に規則が識別されるべきである場合、規則が識別され得る。規則が、識別され、続いて、規則リポジトリ(たとえば、規則リポジトリ133)から選択され得る。ただし、規則は、直ちに評価されなくてよいが、規則を真と評価させる追加ファクトがアサートされたとき評価を迅速化するために、バッファリングまたはキャッシュされ得る。
[0116]いくつかの実施形態では、規則の階層または他の規則に関係した規則の顕著(salience)属性などの競合解決アジェンダに従って、規則が識別される。競合解決アジェンダに従って規則を識別することにより、真と評価されるとき、複数の規則がリポジトリ中のファクトに関連するが競合する結果を有し得る事例の出現を減らすことができる。さらに、コンテキストに従って規則が識別され得る。したがって、リポジトリ中のファクトに関連し得るが対象のコンテキスト(たとえば、瞬間的コンテキスト、期待されるコンテキストまたは頻発するコンテキスト)に無関連の規則はバイパスされて、対象のコンテキストに関連する規則を識別する。
[0117]いくつかの実施形態では、各規則が、規則の重要性を示唆する、関連付けられた重みを有する。たとえば、より高い重みをもつ規則は、その規則が、低い重みをもつ規則に優先することを含意する。競合があるケースでは、これらの重みは、競合を解決するのに使うことができ、より高い重みをもつ規則が評価される。
[0118]規則を識別すると、規則エンジンプラットフォームは次いで、規則を評価し得る(動作380)。識別された規則を評価することは、(たとえば、サンプルもしくは論理値について)アサートされたファクトまたは追加ファクトを検査することを含み得る。たとえば、ユーザが運転中であるというファクトがアサートされた場合、規則エンジンプラットフォームは、ユーザが運転中である場合について真値に条件付けされた規則を評価すればよい。概して、規則の条件(たとえば、ファクト)すべてが満足される場合、規則は真と評価される。一実施形態では、規則が偽と評価される場合、第1の規則よりも劣った顕著属性を有する規則など、別の規則が識別および評価され得る。
[0119]いくつかの実施形態では、複数のファクトが、規則を評価するのに使われる。たとえば、受信された複数のうちのある規則が、ユーザが睡眠中であることが真である場合、オーディオ出力がディセーブルにされるべきであることを示し得る。この規則は、規則エンジンプラットフォームが推論を行い、したがって、ユーザが睡眠中であるというファクトをアサートするのに、2つのサンプル、すなわち(1)時間および(2)動き状態を必要とし得る。したがって、規則エンジンプラットフォームは、現在時刻が午前2:00であることを示す時間サンプルについてのファクトをアサートし、デバイスが動いていないことを示す別のファクトをアサートする(またはユーザが睡眠中であるという単一のファクトをアサートする)。規則エンジンプラットフォームは次いで、早朝であるとともにデバイスが動いていないので、ユーザが睡眠中であるというファクトに基づいて、規則を評価できる。
[0120]一実施形態では、規則は、規則の要件に従って組織的構造をトラバースすることによって評価され得る。たとえば、規則は、3つの要件を有してよく、すなわち、規則が真と評価されるためには、ファクトAおよびBが真でなければならず、ファクトCは偽でなければならない。組織的構造は、ファクトAを検査し、Aが真の場合、ファクトBに進み、Bが真の場合、ファクトCに進むことにより、トラバースされ得る。ファクトCが次いで、偽の場合、規則は真と評価される。ファクトA、B、およびCが、異なるレートで、異なる瞬間に生じることが可能である。そのようなケースにおいて、ファクトは、リポジトリ中にキャッシュされ、各新たなファクトが入ってくると、再読込みされ得る。
[0121]1つまたは複数の規則を評価した後、方法360を実施する規則エンジンプラットフォームは、評価から、1つまたは複数のアクションを決定する(動作385)。いくつかの実施形態では、たとえば規則が真と評価される場合、このアクションは、規則を定義する条件付きステートメントの「then」クローズ中に含められる。代替として、決定されたアクションは、何もしないことであってよい。
[0122]いくつかの実施形態では、規則が真と評価される場合、複数のアクションが決定され得る。規則の結果が、デバイス内の複数のモジュールに影響を与える場合、および/または規則の結果が、複数のモジュールにわたって異なるように実装されるべきである場合、複数のアクションが決定され得る。複数のアクションは概して、各モジュールがアクションを受信するようにブロードキャストされてよい。他の実施形態では、複数のうちのそれぞれのアクションが、特定のモジュールまたはモジュールのタイプ(たとえば、メッセージ通信アプリケーションモジュールやロケーションベースのアプリケーションモジュール)向けに適合される。それぞれのアクションが、たとえば、規則に関連付けられたメタデータに基づいて、特定のモジュールまたはモジュールタイプ向けに適合され得る。
[0123]一実施形態では、アクションは、アクセス制御リストなど、規則に関連付けられたメタデータと関連して決定される。したがって、アクションは、規則の結果が、デバイス内で構成され得る許可と競合しないように決定され得る。代替として、アクションは、規則の結果がそのような許可と一致されるように決定され得る。たとえば、真と評価される規則の結果は、ユーザに通知することであってよいが、デバイス内で構成された許可が、オーディオ通知をディセーブルにしており、したがって、アクションは、ユーザにグラフィカルに通知することと決定され得る。
[0124]図4および図5に移ると、規則ベースに対する更新を受信するためのシステムおよび方法が示されている。新たな規則を追加するためのシステム400について、まず始めに、規則エンジンプラットフォーム460は、図1の規則エンジンプラットフォーム130であってよい。それに応じて、規則エンジンインターフェース420は、規則エンジンインターフェース131であっても、それを含んでもよく、規則エンジン440は、規則エンジン132であっても、それを含んでもよく、規則ベース450は、図1の規則リポジトリ133中に記憶されてよい。
[0125]規則変換器430は、規則エンジンプラットフォーム460内で実装することができ、規則エンジンインターフェース420および/または規則エンジン440と統合されてよい。ただし、規則変換器430は、規則エンジンインターフェース420または規則エンジン440に通信可能に結合されてもよい。いくつかの実施形態では、規則変換器430は、コンパイラ、インタープリタまたは規則更新を、規則エンジン440によって解釈されるのに適した形式に変換するための他の同様の機構であってよい。
[0126]規則ソース410は、規則ベース450に対する更新についての生起ポイント(point of origination)である。規則ソース410は、静的であり、事前コンパイルされている規則を提供することができる。代替として、規則ソース410は、ユーザ入力に応答して作成されるか、または自動的に作成される動的規則を提供することができる。規則ソース410は、規則を追加、更新または消去することによって、規則ベース450についての更新を提供することができる。したがって、規則ベース450は、規則エンジンプラットフォーム460を実装するデバイスのカスタマイズとコンテキスト認識とをサポートするように、ランタイムに更新され得る。
[0127]いくつかの実施形態では、規則ソース410は、図1のモジュール101〜106のいずれかであっても、それらを含んでもよい。たとえば、ユーザが、新たな規則を作成するか、または既存の規則を修正する、アプリケーションモジュール105〜106のうちの1つを通して、パラメータを定義することができる。他の実施形態では、規則ソース410は、事前コンパイルされた規則を導入することができる。そのような実施形態において、規則ソース410は、ファイル(たとえば、SDカードからのバイナリファイル)、ユニフォームリソースロケータ(URL)(たとえば、URLからのバイナリ規則)、または資産(たとえば、資産ディレクトリからロードされる資産)であってよい。代替として、規則ソース410は、規則エンジンプラットフォーム460の一部として含まれる。たとえば、規則ソース410は、コンテキスト認識エンジンや周辺インテリジェンスエンジンなどの「スマート」エンジンであってよい。スマートエンジンは、コンテキストに基づいて規則を提供することができる。
[0128]図4のシステム400は、図5の方法500を実装することができる。最初に、規則ベースを更新するための要求が受信される(動作505)。図4の実施形態において、規則ソース410は、規則エンジンインターフェース420を通して、規則ベース450に対する更新を要求する。規則ベースを更新するための要求は、新たな規則、更新された規則、または規則を消去するための要求であってよい。要求は、コンテキストが変えられるか、またはユーザがモジュールと対話するときなど、ランタイムにおいて動的に受信され得る。
[0129]その後、要求は、規則エンジンに適した形式に変換される(動作510)。この変換動作は、図4の規則変換器430によって実施することができる。変換動作は、規則更新が直ちに効果を発揮するように、ランタイムにおいて動的に行われ得る。いくつかの実施形態では、事前コンパイルされた規則が受信された場合、要求は、変換をほとんどまたはまったく必要としない。代替として、要求は、ハイレベルコードとして受信され、規則エンジンによって解釈され得る形式にコンパイルされる。
[0130]一実施形態では、要求は、規則ベースを更新する前に有効にされる(決定ブロック515)。たとえば、規則を追加するための要求は、より高い優先権の別の規則と競合する場合も、アクセス制御ポリシーと競合するファクトを必要とする場合もある。いくつかの実施形態では、要求は、(たとえば、規則に関連付けられたアクセス制御ポリシーまたはメタデータに従って)消去することができない規則を消去することであり得る。
[0131]別の実施形態では、要求は、ユーザ入力に応答して有効にされる。たとえば、要求された規則更新の結果、SPSロケーションをアプリケーションモジュールに送り、したがって、ユーザは、アプリケーションモジュールがSPSロケーションを受信し得るかどうかを示す入力を促され得る。要求が無効の場合、要求は無視されてよい。一実施形態では、要求が受諾され得ないという要求のソースが通知される。
[0132]要求が有効である場合、要求に従って、規則ベースが更新される(動作520)。たとえば、新たな規則が追加されてもよく、既存の規則が修正または消去されてもよい。別の実施形態では、規則ベースは、規則の階層または規則の1つもしくは複数の顕著属性を更新することによって更新される。たとえば、あるコンテキストに関連する規則は、第2のコンテキストには無関連であり、したがって、規則選択/識別中、比較的顕著でない場合がある。さらに、組織的構造は、更新された規則ベースの結果として、更新され得る。たとえば、異なるファクトがアサートされるように、ファクトについての新たな要件が導入されてもよく、ファクトベースが更新されてもよい。いくつかの実施形態では、規則ベースは、要求が処理された後で更新される。要求は、規則ベースに対するその関係または影響を決定することによって処理され得る。新たな規則を追加するための要求について、新たな規則は、たとえば、規則の階層に割り当てられ、または顕著属性を割り当て得る。
[0133]図6は、デバイスのユーザの遷移中状態に従って規則を評価するための方法600の例の流れ図を示す。したがって、ユーザの遷移中状態は、複数のサンプルの出現またはないことに基づいて推論される。方法600は、たとえば、図1の規則エンジンプラットフォーム130によって実装することができ、動作は、規則エンジンインターフェース131および/または規則エンジン132によって実施することができる。方法600において、規則エンジンは、少なくとも2つのサンプリングモジュール、すなわち(1)動き状態モジュール(たとえば、慣性センサ)および(2)Wi−Fiモジュールにサブスクライブされる。したがって、動き状態モジュールは、動き状態についてのサンプルを提供するように構成され、Wi−Fiモジュールは、Wi−Fiについてのサンプル(たとえば、Wi−Fiシグネチャおよび/またはWi−Fi送信)を提供するように構成される。これらのモジュールのそれぞれの1つは、図1に示されるモジュール101〜106であっても、それを含んでもよい。
[0134]始めに、方法600を実装する規則エンジンプラットフォームは、モジュール101〜106から受信されたサンプルなど、新たな動き状態についてのサンプルが受信されているかどうか決定する(決定ブロック610)。いくつかの実施形態では、規則エンジンプラットフォームは、たとえば、ファクトの真の値を検査することによって、動き状態サンプル(たとえば、リポジトリ133、134)からアサートされたファクトを検査することができる。新たな動き状態サンプルが受信されたことをファクトが示す場合、規則エンジンプラットフォームは、別のファクト検査に進む。第2の検査において、規則エンジンプラットフォームは、動き状態についてのサンプルが、最後の5秒など、第1の時間フレーム内に受信されたかどうか決定する(決定ブロック620)。規則エンジンプラットフォームは、たとえば、ファクトのタイムスタンプを検査することによって、第1のファクトと同じファクトを検査して、動き状態サンプルがいつ受信されたか決定することができる。ただし、このファクトは、動き状態サンプルからアサートされた異なるファクトであってよい。
[0135]新たな動き状態が第1の時間フレーム内に受信された場合、方法600を実施する規則エンジンプラットフォームは、最後のWi−Fiシグネチャが、最後の33秒など、第2の時間フレーム内に受信されたかどうか決定する(決定ブロック630)。規則エンジンプラットフォームは、Wi−Fiシグネチャに関連したファクト(たとえば、リポジトリ133、134中に記憶されたファクト)を検査して、最後のWi−Fiシグネチャサンプルがいつ受信されたか決定すればよい。ここで、推論は、ポータブル電子デバイスが、最後に検出されたWi−Fiシグネチャの外で動いている場合、受信された動き状態サンプルは、デバイスが、ある距離内を移動しており、限られたエリアにおける劇的な動きを単に受けているのではないことを示す。このファクトは、Wi−Fiシグネチャサンプルからアサートされてもよく、Wi−Fiシグネチャサンプルがないこととしてアサートされてもよい。
[0136]最後のWi−Fiシグネチャが、少なくとも33秒の古さであると決定された場合、方法600を実施する規則エンジンプラットフォームは、最終評価を実施する。最終評価のために、規則エンジンプラットフォームは、現在の動き状態を評価する(決定ブロック640)。規則エンジンプラットフォームは、この評価を、第1のファクトと同じか、または異なるファクトであるファクトを検査することによって行うことができる。たとえば、第1のファクトは、新たな動き状態サンプルに従って、再度アサートされ(すなわち、更新され)てもよく(たとえば、ファクトに関連付けられたタイムスタンプが更新されてよい)、第1のファクトは、どの新たな動き状態サンプルも受信されていないことを示すように、再度アサートされてもよい。他の実施形態では、動き状態サンプルをファクトとしてアサートすることなく推論が行われ得るように、動き状態サンプルがキャッシュされる。
[0137]規則エンジンプラットフォームによる、動き状態サンプルの評価が、デバイスが静止していないことを示す場合、規則エンジンプラットフォームは、ユーザが遷移中であるという推論を行う(動作650)。規則エンジンプラットフォームは、この推論から、規則を評価するのに使われるファクトをアサートし得る。たとえば、ユーザが遷移中の場合に真と評価される規則について、規則エンジンプラットフォームは、アクションを決定し、および/または別の規則を評価させる別のファクトをアサートし得る。さらに、規則エンジンプラットフォームは、方法600を再度反復してよい。
[0138]逆に、先行評価のうちのいずれかが否定である場合、方法600を実装する規則エンジンプラットフォームは、ユーザが遷移中でないという推論を行う(動作660)。規則エンジンプラットフォームは、たとえば、ユーザの遷移状態についてのファクトを更新することによって、この推論からのファクトをアサートし得る。規則エンジンプラットフォームはその後、遷移中でないユーザに従って、アクションを決定し、および/または別の規則を評価することができる。さらに、規則エンジンプラットフォームは、方法600を再度反復してよい。
[0139]ここで図7Aを参照すると、ブロック図は、システムを最適化するための規則エンジンプラットフォームの実施形態を示す。システム700は、図1のポータブル電子デバイス100内で実装され得る。したがって、規則エンジンプラットフォーム705は規則エンジンプラットフォーム130であっても、それを含んでもよく、規則エンジンインターフェース710は規則エンジンインターフェース131であっても、それを含んでもよく、規則エンジン730は規則エンジン132であっても、それを含んでもよく、規則リポジトリ715は規則リポジトリ133であっても、それを含んでもよく、知識リポジトリ720は知識リポジトリ134であっても、それを含んでもよい。同様に、モジュール750、755は、モジュール101〜106であっても、それらを含んでもよく、サンプリングモジュールおよび/または受信モジュールとして動作することができる。
[0140]別の実施形態では、システム700は、パーソナルデスクトップまたはラップトップコンピュータなど、どのコンピューティングシステムに組み込まれてもよい。システム700は、ポータブル電子デバイス100とは異なり得るが、モジュール750、755は、図1のモジュール101〜106を参照して記載されたのと同じように、データを提供するとともに、データを受信するように構成され得る。したがって、モジュール750、755は、サンプリングモジュールおよび/または受信モジュールとして動作するように構成され得る。
[0141]規則エンジンプラットフォーム705に組み込まれない、図7Aの図示される構成要素は、コンピューティングシステム用の、どの適切な構成要素であってもよい。一実施形態では、これらの構成要素は、当技術分野において知られている。たとえば、ユーザインターフェースモジュール760は、ユーザが、スルー、モジュール750、755またはオペレーティングシステム775によって提供されるグラフィカルユーザインターフェース(GUI)など、システム700と対話できるようにし得る。これを実現するために、システム700は、ディスプレイおよびユーザ入力に適した1つまたは複数のデバイス(たとえば、キーボード、マウス、またはタッチスクリーン)など、1つまたは複数のハードウェアデバイス(図示せず)と通信可能に結合され得る。
[0142]いくつかの実施形態では、規則エンジン730は、コンテキスト認識エンジン735と最適化エンジン740の一方または両方を含む。コンテキスト認識エンジン735と最適化エンジン740の両方は、規則エンジン730内に組み込まれてもよく、規則エンジン730および/または規則エンジンプラットフォーム705とは別個であるとともにそれらと通信可能に結合されてもよい。
[0143]コンテキスト認識エンジン735は、システム700またはシステム700のユーザのコンテキストを決定するように構成され得る。コンテキストは、たとえば、システム700のユーザが「会議に遅れるだろう」または「映画館にいる」という推論など、複数のサンプルを必要とするか、または計算コストがかかる高度な推論であり得る。コンテキストは、ユーザが動いているという推論など、比較的小さいサンプル数を必要とするか、または計算上比較的コストがかからないローレベル推論であってもよい。コンテキスト認識エンジン735は、1つもしくは複数のサンプル、1つもしくは複数のファクト、1つもしくは複数の規則またはそれらの組合せから、コンテキストを導出することができる。
[0144]コンテキスト認識エンジン735は続いて、コンテキストを規則エンジン730に提供し得る。その後、規則エンジン730は、コンテキストに基づいて、規則またはファクトを評価または組織化し得る。たとえば、規則の階層またはそれぞれの顕著属性は、コンテキストに適用可能な規則が優先されるように修正され得る。同様に、コンテキストに従って、ファクトがアサートされ得る。一実施形態では、コンテキストに適用可能な規則および/またはファクトが、規則評価を、最適化するために(たとえば、バッファまたはキャッシュ中で)ロードされる。いくつかの実施形態では、コンテキストが、知識リポジトリ720中でファクトとしてアサートされる。
[0145]一実施形態では、コンテキスト認識エンジン735は、ファクトまたはコンテキストの間の関係を導出するように構成される。導出された関係は、それ自体がコンテキストであってよく、したがって、ファクトとしてアサートされ得る。さらに、導出された関係は、規則ベースを更新することができる。コンテキスト認識エンジン735は、2つのコンテキストまたはファクトの間の共通または反復パターンを決定することによって、コンテキストまたはファクトの間の関係を導出することができる。たとえば、コンテキスト認識エンジン735は、ユーザの自宅とオフィスとの間の関係を、(1)ユーザが自宅にいることを示す第1のコンテキスト、(2)ユーザが運転中であることを示す次のコンテキスト、および(3)ユーザがオフィスにいることを示す最終コンテキストから導出することができる。その後、コンテキスト認識エンジン735は、通勤時間(たとえば、第2のコンテキストの持続時間)を示す、自宅コンテキストとオフィスコンテキストとの間の関係を導出することができる。導出された関係から、コンテキスト認識エンジンは、「ユーザが5分後に、オフィスでの会議の約束があり、ユーザが自宅にいる場合、ユーザが約束に遅れるというファクトをアサートする」という規則を提供することができる。別の例では、コンテキスト認識エンジン735は、(1)ユーザが運転中であるという示す第1のコンテキスト、(2)一日のうちの特定の時刻、および(3)ユーザが自宅にいることを示す次のコンテキスト、の間の関係を導出することができる。コンテキスト認識エンジン735は、ユーザが一般に、一日のうちの特定の時刻に、運転中コンテキストから自宅コンテキストに遷移すると決定することができる。したがって、コンテキスト認識エンジン735は、ユーザがその特定の時刻に運転中の場合、ユーザが自宅に向かって運転中であるという関係を導出することができる。
[0146]いくつかの実施形態では、コンテキスト認識エンジン735は、コンテキストを導出するために、1つまたは複数のサンプルに関連した、記憶された情報にアクセスする。情報は、たとえば、リポジトリ715〜720またはストレージ770中に記憶され得る。一実施形態では、記憶される情報は、サンプルの、コンテキストへのマッピングを含む。たとえば、Wi−Fiシグネチャサンプルが、ユーザが職場にいることを示すコンテキストや、ユーザがオフィスビルの特定の部屋にいることを示すコンテキストなど、特定のコンテキストにマップされ得る。マッピングは、ユーザ入力として受信されても、コンテキスト認識エンジン735によって、受信サンプルから導出されてもよく、たとえば、ユーザが素早く遷移していることをSPSサンプルが示すとともに、コンテキスト認識エンジン735が、システム700がオーディオシステム(図示せず)とペアであることを示すBluetoothサンプルを頻繁に受信する場合、コンテキスト認識エンジン735は、オーディオシステムペアリングから、ユーザが運転中であることを示すコンテキストへのマッピングを導出することができる。
[0147]最適化エンジン740は、たとえば、プロセッサ765に対する計算負荷、メモリ120およびストレージ770のアクセスまたは電力源(図示せず)の使用を削減することによって、システム700の性能と電力消費とを最適化するように構成される。一実施形態では、最適化エンジン740は、規則の規則構造を分解して、規則が真と評価されるのに必要とされる構成要素を決定する。分解された規則構造から、最適化エンジン740は、モジュール750、755がサンプリングされるレートを指定する最適化方式など、リソースを節約するための最適化方式を計算することができる。たとえば、2つの異なるサンプリングモジュールXおよびYに対して求められる2つの異なるサンプルからアサートされる2つのファクトについて、規則は、真と評価することができる。最適化エンジン740はしたがって、規則を、Xサンプルについての第1の要件と、Yサンプルについての第2の要件とに分解する。第1の要件は、規則が真と評価されるためには、Xサンプルが、ファクトとして、毎分一度アサートされるだけでよいことを示し得る。有利には、最適化エンジン740は、Xサンプルが1分間隔で受信または処理される(たとえば、ファクトをアサートするのに使われる)だけのように、モジュールXのサンプリングレートを、第1の要件に基づく最適化方式に従って修正し得る。それに応じて、最適化エンジン740は、Xサンプルが最後の1分の間にファクトとしてアサートされる場合、Yサンプルが受信または処理される(たとえば、ファクトをアサートするのに使われる)だけのように、モジュールYのサンプリングレートを、最適化方式に従って修正し得る。さらに、Xサンプルがファクトとしてアサートされていない場合、最適化エンジン740は、規則が必ずしも偽と評価されるとは限らないので、規則を評価しなくてよい。
[0148]規則エンジンプラットフォーム705は、効率を増し、速度を増し、電力消費を減らし、システムリソース消費を減らすこと、およびシステム700の性能を強化することを意図している他の同様の属性によって、システム700の性能を最適化することができる。したがって、「最適化」は、必ずしも「最良」または規則エンジンプラットフォーム705のただ1つの得られる効果/可能性があることを意味するとは限らない。したがって、規則エンジンプラットフォーム130は、効率を最大限にすることも、電力消費を最小限にすることも求められないが、これらの側面を向上させることができる。たとえば、規則エンジンプラットフォーム130は、速度を増すことができ、同時に、電力消費を増し、これらの増大は、増大した速度が望ましいようないくつかの実施形態では電力消費が直ちに問題となり得るわけではないので、いくつかの実施形態では最適と見なされ得る。
[0149]規則リポジトリ715が複数の規則を含む事例において、複数のうちの各規則は、そのそれぞれの成分要件に分解され得る。最適化エンジンはその後、規則と、それらのそれぞれの要件との間の関係を識別することができる。したがって、最適化エンジン740は、複数の規則にわたって、競合するか、または共有される要件を調停する最適化方式を計算することができる。規則エンジンプラットフォーム705内での最適化エンジン740の実装は、最適化エンジン740が、明示的要件を含む規則についてさえも、ファクトが規則の要件をどのように満足するか指定することを可能にし得る。たとえば、3つの規則A、BおよびCが各々、真と評価されるために、サンプリングモジュール750からのサンプルからアサートされるファクトを必要とし得る。3つの規則についての要件はファクトを共有するが、3つの規則は、ファクトが必要とされるレートにおいて異なってよく、たとえば、規則Aはファクトを毎秒必要とし、規則Bは、ファクトを30秒おきに必要とし、規則Cは、ファクトを毎分必要とする。まったく異なるレートを有する、ファクトについての3つの要件から、最適化エンジン740は、たとえば、規則A、BおよびCの要件を満足したまま、サンプリングモジュール750のサンプリングレートを修正することによって、サンプリングモジュール750のサンプリングを最適化することができる。この例では、最適化エンジン740は、サンプリングモジュールの最適サンプリングレートが15秒であると決定してよく、したがって、サンプリングモジュール750からのサンプルは、15秒間隔でのみ受信または処理され(たとえば、ファクトをアサートするのに使われ)ればよい。
[0150]いくつかの実施形態では、最適化エンジン740は、モジュール750、755の一方または両方についての1つまたは複数の最適化パラメータを計算することができる。最適化エンジン740は、各個々のモジュール750、755についての特定の最適化パラメータを用いて最適化方式を計算することができるが、複数のモジュール750〜655に対して1つの最適化パラメータが適用可能である場合がある。たとえば、最適化方式は、モジュール750、755のサンプルに対する最適レート、またはモジュール750、755からの異なるタイプのサンプルが処理されるレートを定義するそれぞれの最適化パラメータを含み得る。
[0151]最適化方式の実装は、実施形態によって変わり得る。いくつかの実施形態では、最適化方式は、規則エンジンプラットフォーム705の一部として、最適化エンジン740によって実装される。たとえば、規則エンジンインターフェース710は、たとえば、受信サンプルが、最適化方式の最適化パラメータによって定義されるサンプリングレートを超える場合、不必要である、モジュール750、755から受信されたサンプルを無視して(たとえば、サンプルを破棄して)よい。同様に、規則エンジン730は、モジュール750、755へのそのサブスクリプションを、たとえば、モジュール750、755がポーリングされ、または必要とされるレートを低下させることによって、規則エンジンインターフェース710を通して修正してよい。さらに、ファクトは、最適化方式によって定義された最適レートでアサートされ得る。モジュール750、755へのサブスクリプションを修正することの追加利点として、モジュール750、755は、非アクティブ化またはスリープし、能動的に問い合わせられ、またはポーリングされたときにアクティブ化または起動する(wake)だけでよい。
[0152]一実施形態では、最適化方式のそれぞれの最適化パラメータが、1つまたは複数のモジュール750、755に提供され、そうすることによって、モジュール750、755は、そのサンプリングレートを、最適化パラメータに従って修正する。別の実施形態では、最適化エンジン740は、最適化パラメータに従って、モジュール750、755の状態に影響を与える。最適化方式が、モジュール750、755からのサンプルが不必要であることを示す場合、最適化エンジン740は、非アクティブ化し、またはスリープするための命令を含む最適化パラメータを、モジュールに提供すればよい。モジュール750、755からのサンプルが最適化方式に従って必要とされる場合、最適化エンジンは、アクティブ化し、または覚醒するための命令を含む最適化パラメータを、モジュールに提供すればよい。
[0153]最適化エンジン740は、ファクト、規則、コンテキストなどに対する変化など、システム700にわたる変化に応答して、ランタイムに、最適化方式を動的に更新することができる。最適化方式に対する動的更新は、たとえば、モジュール750、755用の最適化パラメータを修正することによって、ランタイムに実装されてよい。冗長動作を避けるために、最適化エンジン740は、影響を受ける最適化パラメータを更新するだけでよく、したがって、最適化方式全体を再度計算しなくてよい。
[0154]一実施形態では、最適化方式は、たとえば、1つのモジュールについての要件(requirement)が第2のモジュールについての要件に依存することを、分解された規則構造が示す場合、要件の間の関係を考慮に入れてよい。たとえば、ある受信サンプルが、異なるサンプルが、規則を評価するためのファクトをアサートする必要をトリガし得る。第1のサンプルが受信されると、最適化エンジン740は、第1の受信サンプルと、異なるサンプルとを提供する、モジュール750、755用の1つまたは複数の最適化パラメータを動的に更新する。
[0155]いくつかの実施形態では、最適化エンジン740は、規則リポジトリ715に記憶された規則ベースに対する更新を適合させるように適応され得る。追加され、消去され、または修正される規則に応答して、最適化エンジン740は、規則リポジトリ715中の現在の規則に対する必要に応じて、たとえば、モジュール750、755用の最適化パラメータを追加し、修正し、または消去することによって、最適化方式を更新することができる。規則ベースに対するいくつかの更新について、最適化エンジン740は、規則更新を分解して、修正された要件を決定することができる。最適化エンジン740はその後、修正された要件を使って、ランタイムに、最適化方式を更新することができる。
[0156]最適化エンジン740は、コンテキスト認識エンジン735から受信されたコンテキストまたはサンプルからアサートされたファクトなど、ファクトまたはコンテキストにおける変化に応答して、最適化方式を更新することもできる。コンテキストまたはアサートされたファクトにおける変化は、異なる規則を真と評価させ、その結果、1つまたは複数の規則の要件に影響を与え得る。他の規則は、コンテキストまたはアサートされたファクトにおける変化によって回避されてよく、したがって、最適化エンジン740が最適化方式を更新するとき、無関連規則についての要件が、考慮から除かれ得る。
[0157]一実施形態では、最適化エンジン740は、規則の階層またはそれぞれの顕著属性など、競合解決アジェンダに基づいて、最適化方式を計算する。最適化エンジン740は、規則についての要件がアジェンダに従って重みづけされるように、最適化方式を計算してよい。最初に選択または識別されるべき規則についての要件は、最適化方式を計算または更新する際、異なるように重みづけされ得る。たとえば、モジュール750、755用の最適化パラメータは最初に、要件を平均することによって、モジュール750、755からのサンプルが処理されるレートを設定し、その後、最適化パラメータを更新する際、ある要件に、より大きい重みが与えられるように階層または顕著属性が変化するサンプリングレートを修正し得る。
[0158]図7Bおよび図7Cは、それぞれ、本発明の一実施形態による、図7Aの規則リポジトリ715と知識リポジトリ720とを示す。規則リポジトリ715中に記憶されている規則ベースは、規則のセット717A〜Cに組織化され得る。概して、規則の各セット717A〜Cは、1つまたは複数のコンテキストに関連する。たとえば、ユーザが自宅にいることをファクトが示すとき、規則エンジン730は、ユーザが自宅にいるときに適用される第1の規則セット717Aを評価し、および/またはユーザが職場にいるときに適用される第2の規則セット717Cを無視することができる。常に評価されるべき基本規則セットなど、いくつかの規則セット717A〜Cは、すべてのコンテキストに関連する。さらに、コンテキストは、同時に関連する複数の規則セット717A〜Cを有してよい。必要はないが、規則リポジトリ715が、どのコンテキストにも関連しない規則の1つまたは複数のセット717A〜Cを記憶していることが可能である(これらの規則セットは、たとえば、最適化方式が計算される場合、無視されてよい)。
[0159]規則ベースは、すべての規則のセットと見なすことができ、各規則セット717A〜Cは、規則ベースのサブセットであり得る。ただし、たとえば、システム700の初期化時に、または規則716A〜Dのすべてがそのセットから削除されている場合、いくつかの規則セット717A〜Cが空であり得ることが企図される。いくつかの実施形態では、規則のセット717A〜Cは重複する場合があり、したがって、規則716A〜Dは、2つ以上の規則セット717A〜Cのメンバであり得る。
[0160]複数の規則716A〜Dおよびセット717A〜Cは、単一のコンテキストに関連することができ、規則716A〜Dおよびセット717A〜Cは、規則セット717A〜Cの階層などの競合解決アジェンダに従って組織化され得る。さらに、競合解決アジェンダは、規則716A〜Dについてのそれぞれの顕著属性を含み得る。規則エンジン730は、競合解決アジェンダに基づいて規則を評価するための順序を決定することができる。一実施形態では、規則716A〜Dの顕著属性は、規則セット717A〜Cの階層に従属する。ただし、別の実施形態では、規則716A〜Dは、それらのそれぞれの顕著属性に従って優先される。したがって、2つの規則が真と評価されるとともに競合している(たとえば、解決できないアクションの決定を生じる)場合、規則エンジン730は、競合解決アジェンダに基づいて、適切なアクションを決定してよい。一実施形態では、競合解決アジェンダは、たとえば、コンテキストが変化する場合、または規則ベースが更新される場合、ランタイムにおいて動的に更新可能である。
[0161]規則リポジトリ715中に記憶された規則ベースと同様に、知識リポジトリ720中に記憶されているファクトベースは、ファクトのセット722A〜Cに組織化され得る。概して、ファクトの各セット722A〜Cは、1つまたは複数のコンテキストにおける1つまたは複数の規則716A〜Dに関連する。たとえば、ユーザが運転中であることをコンテキストが示すとき、ファクトのセット722A〜Cは、ユーザが運転中であるときに適用される第1の規則セット717Aを評価することを求められ得る。同様に、ファクト721A〜Dは、コンテキストについてのすべての評価可能規則に無関連の場合、無視されてよい(たとえば、記憶されなくても、アサートされなくてもよい)。すべてのインスタンスにおいて評価されるべき規則についての基本ファクトセットなど、いくつかのファクトセット722A〜Cは、すべてのコンテキストに関連する。さらに、コンテキストは、同時に関連する複数のファクトセット722A〜Cを有してよい。必要はないが、知識リポジトリ720が、どのコンテキストにも関連しないファクトの1つまたは複数のセット722A〜Cを記憶していることが可能である。
[0162]ファクトベースは、すべての規則のセットと見なすことができ、各ファクトセット722A〜Cは、ファクトベースのサブセットであり得る。ただし、たとえばシステム700の初期化時に、いくつかのファクトセット722A〜Cが空であり得ることが企図される。いくつかの実施形態では、ファクトのセット722A〜Cは重複する場合があり、したがって、ファクト721A〜Dは、2つ以上のファクトセット722A〜Cのメンバであり得る。
[0163]いくつかの実施形態では、規則エンジン730は、コンテキスト認識エンジン735によって識別されたコンテキストについての1つまたは複数の関連規則716A〜Dを識別する。規則エンジン730は、瞬間的コンテキストまたは期待され、もしくは頻発するコンテキストなど、対象のコンテキストについての関連規則716A〜Dを識別することができる。関連規則716A〜Dを識別する際、規則エンジン730は、関連規則716A〜Dを(たとえば、キャッシュまたは他のRAMメモリ中に)ロードすることができる。一実施形態では、規則エンジン730は、コンテキストに関連する1つまたは複数の規則セット717A〜Cを識別することによって、関連規則716A〜Dを識別する。たとえば、コンテキスト認識エンジン735が、ユーザが運転中であると識別した場合、規則エンジン730は、すべてのコンテキストにおいて評価されるべき基本規則についての第1の規則セット717Aと、ユーザが運転中であるコンテキストに関連する第2の規則セット717Cとをロードすることができる。したがって、関連規則716A〜B、Dは、素早い評価のためにロードされる。
[0164]同様に、規則エンジン730は、コンテキスト認識エンジン735によって識別されたコンテキストに関連するファクト721A〜Dを識別することができる。一実施形態では、ただし、ファクト721A〜Dは、コンテキストについて間接的に識別され、つまり、コンテキストに関連する規則716A〜Dが最初に識別され、関連ファクト721A〜Dが、関連規則716A〜Dの要件から識別される。規則エンジン730は、瞬間的コンテキストまたは期待され、もしくは頻発するコンテキストなど、対象のコンテキストについてのファクト721A〜Dを識別することができる。ファクト721A〜Dを識別する際、規則エンジン730は、ファクト721A〜Dを(たとえば、キャッシュメモリ中に)ロードすることができる。一実施形態では、規則エンジン730は、1つまたは複数のファクトセット722A〜Cを識別することによって、ファクト721A〜Dを識別する。
[0165]ユーザが運転中である例示的な一実施形態では、規則エンジン730は、ユーザが運転中であるコンテキストに関連する第1の規則セット717Aをロードしてよい。関連規則セット717Aから、規則エンジン730は、瞬間的コンテキストについての関連規則716A〜Bを評価するのに必要とされる関連ファクトセット722Bを識別することができる。さらに、コンテキストに固有のファクト721A〜Dがアサートされてよく、たとえば、ユーザが遷移中であるというファクトが、ユーザが運転中であるというコンテキストに固有なので、アサートされてよい。
[0166]システム700の性能を最適化するために、規則エンジン730は、対象コンテキストに関連する規則716A〜Dを識別および/または評価するだけでよい。1つまたは複数の対象コンテキストに無関連な他の規則は、識別および評価中は無視されてよい。同様に、規則エンジン730は、対象のコンテキストに関連するファクト721A〜Dを識別および/またはアサートするだけでよい。1つまたは複数の対象コンテキストに無関連な他のファクトは、たとえば、それらのファクトをアサートしないか、または場合によっては処理しないことによって無視されてよい。一実施形態では、対象のコンテキストに関連する1つまたは複数のファクト721A〜Dは、識別されると更新される。したがって、1つまたは複数のモジュール750、755へのサブスクリプションは、関連ファクト721A〜Dがアサートされるように更新され得る。たとえば、ユーザが運転中であるというコンテキストを識別すると、ファクト721Aが、ユーザが遷移中であることを示すようにアサートされ得る。
[0167]対象のコンテキストに無関連である規則716A〜Dは、無視されてよい。たとえば、無関連規則716A〜Dは、たとえば、キャッシュメモリから無関連規則716A〜Dを削除することによってアンロードされてよい。さらに、興味をもたれているコンテキストに無関連または不正確であるファクト721A〜Dは、無視され(たとえば、キャッシュメモリから削除され、もしくは満了させられ)またはデフォルト(たとえば、ヌル値)にアサートし直され得る。したがって、システム700のリソースは、結局は重要度が低くなる規則およびファクトによって消費されない。
[0168]いくつかの実施形態では、規則716A〜Dとファクト721A〜Dのコンテキスト関連性は、最適化方式に対して補足的である。したがって、規則エンジン730は、関連規則716A〜Dおよび関連ファクト721A〜Dについてのサンプリング要件を識別し、これらのサンプリング要件を、たとえば、最適化パラメータのサブスクリプションまたはサンプリングレートを更新することによって、最適化方式を計算または更新するのに使えばよい。したがって、規則エンジン730は、対象のコンテキストに関連する異なる規則716A〜Dおよび/またはファクト721A〜Dに応答して、最適化方式をランタイムにおいて動的に更新することができる。
[0169]一実施形態では、規則エンジン730は、対象のコンテキストに応答して、サンプルを積極的に管理する。規則エンジン730は、古いまたは無関連サンプルをストレージから破棄する(たとえば、サンプルが記憶されているリポジトリ715、720からサンプルを消去する)ことによって、サンプルを管理することができる。さらに、規則エンジン730は、対象のコンテキストについて、モジュール750、755への1つまたは複数のサブスクリプションを修正することができる。たとえば、規則エンジン730は、対象のコンテキストにおいて頻繁にアサートされるファクト721Aを識別し、したがって、ファクト721Aがそこからアサートされるモジュール750へのサブスクリプションを、モジュール750がサンプルについてより頻繁にポーリングされるように修正することができる。
[0170]さらに、規則エンジン730は、スマートサービスを提供するために、サンプルを積極的に管理することができる。規則エンジン730は、コンテキスト認識エンジン735と対話して、スマートサービスを提供することができる。たとえば、コンテキスト認識エンジン735は、たとえば、BluetoothサンプルまたはNFCサンプルに基づいて、ユーザが人の近くにいることをコンテキストが示すことを識別することができる。コンテキスト認識エンジン735は続いて、ユーザが、他の人の名前、職業、雇用主の名前、誕生日などに素早くアクセスすることができるように、他の人についてのvCardなど、他の人についてのコンタクト情報をロードすることができる。
[0171]図8に移ると、規則エンジンプラットフォームを実装するシステムを最適化するための方法800が、一実施形態に従って図示されている。図8の動作は、例示的であり、必ずしも図示される順序で実施されるとは限らない。方法800は、図1に示されるポータブル電子デバイス100の規則エンジン132または図7に示される最適化エンジン740によって実施することができる。
[0172]始めに、方法800を実施するエンジンは、複数の規則を分解する(動作810)。複数の規則は、エンジンと通信可能に結合されたリポジトリ(たとえば、規則リポジトリ133または規則リポジトリ715)に記憶された規則ベースであってよい。いくつかの実施形態では、複数の規則は、現在のコンテキストに関連する規則のサブセットまたは規則の階層のサブセットなど、規則ベースのサブセットである。エンジンは、それぞれの規則の成分が別個に識別可能なように、複数の規則を分解して、各規則の条件の各成分を分解することができる。成分は、たとえば、ファクト、コンテキスト、または別の規則(たとえば、規則からのアクション)であってよい。
[0173]その後、エンジンは、各分解された規則の1つまたは複数のそれぞれのサンプリング要件を識別する(動作815)。いくつかの規則について、たとえば、単一のサンプルからアサートされるファクトを規則が必要とする場合、それぞれのサンプリング要件を識別することは直接的であり得る。ただし、他の規則は、複数のサンプルまたはファクトから推論されるコンテキストまたはファクトなど、より高度な条件付き成分を有し得る。したがって、エンジンは、コンテキストまたはファクトの構成サンプリング要件を決定することによって、規則のサンプリング要件を識別することができる。たとえば、規則は、ユーザが「自宅にいる」というファクトを条件としてよく、「自宅にいる」というファクトは、「自宅」Wi−Fiネットワークに接続しているWi−Fiトランシーバモジュールまたは「自宅」のロケーションを解決するSPSモジュールのいずれかによってアサートされ得る。したがって、エンジンは、Wi−FiトランシーバサンプルとSPSモジュールサンプルの両方として、要件を識別することができる。いくつかの実施形態では、エンジンは、コンテキスト認識エンジンと対話して、サンプリング要件を識別する。図1に関係して、サンプルが、モジュール101〜106から受信され、または予想され得る。同様に、図7に関係して、モジュール750、755からサンプルが受信され得る。
[0174]いくつかの実施形態では、規則は、1つまたは複数の他の規則に依存し、したがって、その規則のサンプリング要件は、直接識別可能でない。エンジンは、依存規則にとって基本的な1つまたは複数のサンプリング要件を識別するために、規則がそこから依存する規則の要件を識別することができる。たとえば、第1の規則は、第2の規則の評価によって決定されたアクションからアサートされるファクトなど、第2の規則からアサートされるファクトを必要とする。したがって、第1の規則のサンプリング要件を識別することは、第2の規則のサンプリング要件を識別することを必要とする。エンジンは、たとえば、依存規則が複数またはネストされた規則要件を含む場合、複数の規則を反復して、依存規則のサンプリング要件を識別すればよい。
[0175]複数のうちの各規則についての識別されたサンプリング要件を使って、エンジンは、エンジンが実装されるシステムに役立つ最適化方式を計算する(動作820)。一実施形態では、最適化方式は、1つまたは複数のモジュール用の1つまたは複数の最適化パラメータを含み得る。最適化パラメータは、サンプリングモジュールがサンプルを提供するレートまたはサンプルが記憶または処理される(たとえば、ファクトとしてアサートされる)レートを含み得る。この最適化パラメータは概して、そのようなサンプルを必要とする1つまたは複数の規則にとって満足でき、同時に、(たとえば、繰り返しファクトをアサートし、またはコンテキストを決定することによって)計算コストが高い動作または電力消費を最小限にする。
[0176]一実施形態では、最適化パラメータは、1つまたは複数のモジュールの状態を修正するための命令を含む。したがって、最適化方式は、たとえば、モジュールからのサンプルが不必要である場合、またはどのアクションもモジュールに提供されない場合、非アクティブ化し、またはスリープするための命令を含む最適化パラメータをモジュールに提供することができる。同様に、最適化方式は、モジュールをアクティブ化し、または起動する(awake)ための命令を含む最適化パラメータを提供することができる。そのような最適化パラメータは、最適化方式に従って、あらゆる状態変化について、モジュールに提供されてもよく、モジュールが遵守するポリシー(たとえば、いつ起動し、またはスリープするかというスケジュール)として、モジュールに提供されてもよい。
[0177]いくつかの実施形態では、方法800を実施するエンジンは、ローカルストレージ中など、エンジンに記憶され、または場合によってはアクセス可能でよい1つまたは複数のアルゴリズムを使って、最適化方式を計算することができる。アルゴリズムは、複数の規則にわたるサンプリング要件の間の関係を適合するように適応され得る。たとえば、2つ以上の規則が同じファクトを必要とし得るが、ファクトが必要とされるレートは変わり得る。単純な最適化方式は、ファクトが必要とされるレートの平均をとることによって計算することができ、そうすることによってファクトは、平均レートでアサートされるだけである。
[0178]最適化方式を計算するためのアルゴリズムは、任意の数の要因を考慮に入れることができる。一実施形態では、規則の間の関係が識別され、最適化方式のアルゴリズム計算において使われる。たとえば、真と評価される第1の規則の結果として、第2の規則が評価され得る。第1の規則がめったに真と評価されない場合、第2の規則の要件は、最適化方式に対して比較的影響がなくてよい(たとえば、他の要件が、第2の規則の要件よりも強調されてよい)。さらに、規則または規則のセットが、競合解決アジェンダ(たとえば、規則の階層または顕著性)に従って評価されてよく、最適化方式は、規則についての要件がアジェンダに従って重みづけされるように計算されてよい。
[0179]一実施形態では、最適化方式を計算するためのアルゴリズムは、瞬間的コンテキスト、期待されるコンテキスト、または頻発するコンテキストなど、1つまたは複数の対象コンテキストを組み込む。したがって、組込みコンテキストに無関連である規則は、最適化方式の計算から除外されてよい。さらに、規則の階層は、コンテキストによって変化してよく、したがって、規則は、異なるコンテキストに対して異なるように重みづけされ得る。さらに別の実施形態では、最適化方式は、コンテキストに従って、規則の間の競合を解決するためのアジェンダを更新する。たとえば、規則の階層は、コンテキストに従って変えられてもよく、規則の異なるサブセットが、最適化方式を更新するのに使われてもよい。
[0180]最適化方式は、関連最適化パラメータをモジュールに提供することによって実装され得る(決定ブロック825)。ただし、いくつかの実施形態では、1つまたは複数のモジュールにおいて最適化方式を実装することは、望ましくないか、または不利な場合がある(決定ブロック825)。したがって、最適化方式は、方法800を実施するエンジン(たとえば、規則エンジン132または規則エンジン730)において実装されてよい。一実施形態では、最適化方式は、エンジンおよび1つまたは複数のモジュールに分散される。したがって、いくつかのモジュールは、最適化パラメータを受信し、遵守してよく、他の最適化パラメータは、エンジンにおいて実装される。
[0181]最適化方式が、方法800を実施するエンジンによって実装される場合、1つまたは複数のサンプルの処理が、最適化方式に従って修正され得る(動作830)。一実施形態では、受信サンプルについての1つまたは複数の最適化パラメータに従って、ファクトが、サンプルからアサートされる。したがって、たとえば、受信サンプルが、最適化パラメータによって定義される、含まれる最適サンプリングレートを超える場合、いくつかの受信サンプルは無視(たとえば、却下または破棄)されてよい。
[0182]代替として、最適化方式の最適化パラメータは、方法800を実施するエンジンと通信可能に結合されている適用可能モジュールに提供されてよい(動作835)。応答して、モジュールは、提供された最適化パラメータを遵守する。たとえば、モジュールは、エンジンにサンプルを送るレートを、最適化パラメータに従って修正してよい。一実施形態では、最適化パラメータは、パラメータが提供されるモジュールの状態に影響する。たとえば、最適化パラメータは、非アクティブ化するか、またはスリープするための、モジュールへの命令を含み得る。同様に、最適サンプリングレートは、アクティブ化し、または起動するための、モジュールへの命令を提供し得る。
[0183]最適化方式に影響を与える変化は、最適化方式が計算された後に起こり得る(決定ブロック840)。最適化方式に影響を与える変化は、たとえば、コンテキスト、規則、ファクトに対する変化、または他の同様の変化であり得る。最適化方式に影響を与える何の変化も起こらない場合、既存の最適化方式が実装されたままであってよい。
[0184]現在の最適化方式に影響を与える変化が起きた場合、方法800を実施するエンジンは、変化に従って、最適化方式を更新するように構成される(動作845)。エンジンは、変化に応答して、最適化方式をランタイムに更新し、更新された最適化方式を動的に実装することができる。最適化方式を更新する際、エンジンは、変化に従って、1つまたは複数の最適化パラメータを追加、修正または削除してよい。ある最適化パラメータへの変更は、最適化方式を通して他の最適化パラメータに伝播し得る。一実施形態において、最適化方式は、たとえば、分解された規則構造が、あるサンプリング要件が、ファクトがアサートされるために別のサンプリング要件に依存することを示す場合、サンプリング要件の間の関係を考慮に入れることができる。たとえば、第1のモジュールから受信されたサンプルが、ファクトをアサートするために、第2のモジュールからのサンプルの必要をトリガし得るとともに、第1のモジュールからのさらなるサンプルの必要も一時的になくす。
[0185]同様に、エンジンは、追加、修正または消去された規則など、規則の変化に応答して、最適化方式を更新し得る。いくつかの実施形態では、新たな、または修正された規則が最初に分解され、そうすることによって、規則のサンプリング要件が識別され得る。その後、どの影響される最適化パラメータも更新され得る。
[0186]エンジンは、ファクトまたはコンテキストの変化に応答して、最適化方式を更新することもできる。ファクトまたはコンテキストにおける変化は、異なる規則を真と評価させ、その結果、1つまたは複数の規則のサンプリング要件に影響を与え得る。他の規則は、ファクトまたはコンテキストの変化によって除去され得、したがって、そのような規則に基づく最適化パラメータは、適用できないサンプリング要件が考慮から除かれるように更新され得る。
[0187]その後、更新された最適化方式は、実施形態に従って実装されてよい(決定ブロック825)。したがって、エンジンは、サンプルが処理されるやり方を修正してよい(動作830)。代替として、エンジンまたは、更新された最適化パラメータをモジュールに提供し、または最適化パラメータを消去することによって、モジュールに、最適化パラメータを遵守するのをやめるよう命令することができる(動作835)。
[0188]図9Aを参照すると、規則エンジンプラットフォームを実装するシステムを最適化するための方法900が、一実施形態に従って図示されている。図9Aの動作は、例示的であり、必ずしも図示される順序で実施されるとは限らない。方法900は、図1に示されるポータブル電子デバイス100の規則エンジン132によって実施することができる。方法900は、コンテキスト認識エンジン735と通信可能に結合され得る、図7の規則エンジン730によって実施することもできる。
[0189]最初に、方法900が実施されるシステムのユーザの状況または環境を示すサンプルが受信される(動作905)。サンプルは、たとえば、カレンダイベント、動き状態、Wi−Fiシグネチャ、または他のどのタイプのサンプルであってもよい。サンプルは、モジュール(たとえば、モジュール101〜106またはモジュール750、755)から受信されてよく、その元の形式から適合されてよい(たとえば、未加工センサデータが処理され得る)。一実施形態では、サンプルは、ファクトとして(たとえば、リポジトリ133、134またはリポジトリ715、720に)アサートされる。
[0190]サンプルから、対象のコンテキストが識別され得る(動作910)。対象のコンテキストは、瞬間的コンテキストでも、期待され、または頻発するコンテキストでもよい。コンテキストは、受信サンプルに加え、複数のサンプルから識別され得る。ただし、コンテキストの識別は、1つまたは複数のサンプルがないことを必要とし得る。
[0191]一実施形態では、サンプルから間接的にコンテキストが識別される。たとえば、コンテキストは、サンプルからアサートされるか、またはサンプルからまだアサートされていない(たとえば、ファクトがヌルである)ファクトから識別される。さらに、対象のコンテキストは、たとえば、1つのファクトに関係した1つのコンテキストの識別が第2のコンテキストを示す、コンテキストおよび/またはファクトの間の、導出された関係から識別され得る。
[0192]一実施形態によると、識別されたコンテキストに準じる適用可能情報が識別され得る。適用可能情報は、たとえば、識別されたコンテキストに準じる知識リポジトリ(たとえば、知識リポジトリ134や知識リポジトリ720)からの、サンプルまたはアサートされたファクトであってもよく、モジュール(たとえば、モジュール101〜106やモジュール750、755)から取り出してもよい。たとえば、ユーザが美術館に入ったことを示すコンテキストが識別されると、規則エンジンプラットフォームは、(たとえば、コンテキスト認識エンジン735またはモジュール750、755からのWi−Fiサンプルを通して)ユーザが入った美術館の中の部屋を決定し、応答として、その美術館の部屋の中のアーティファクトについての情報をロードすることが可能であり得る(たとえば、知識リポジトリ134や知識リポジトリ720)。別の例では、ユーザがユーザのオフィスに入ったことをコンテキストが示すとき、規則エンジンプラットフォームは、「オフィス」コンテキストに関連した情報または設定を、知識ベース(たとえば、知識リポジトリ134や知識リポジトリ720)にロードし得る。
[0193]対象のコンテキストを識別することによって、コンテキストに関連する規則が、続いて識別され得る(動作915)。1つまたは複数の関連規則は、たとえば、方法900が実施されるシステムにとって基本的な規則であってよい。追加関連規則は、識別されたコンテキストに対して一意であっても、共通ファクトを共有するコンテキストなど、いくつかのコンテキストに関連するだけであってもよい。関連規則は、各規則に関連付けられたそれぞれの顕著属性などの競合解決アジェンダに従って識別され得る。したがって、より高い優先権の関連規則と競合する規則は識別されなくてよい。
[0194]一実施形態によると、特定のコンテキスト向けの規則のセットのサブセットなど、あるコンテキストにおける規則が識別され得る。たとえば、コンテキストが、「職場」として識別されてよく、規則エンジンプラットフォームは、ユーザのオフィス用のジオフェンスにシステムが入ったことを示すサンプルを受信し得る。応答して、規則エンジンプラットフォームは、ユーザが職場にいることをコンテキストが示すとともにユーザがユーザのオフィスに入ったことをサンプルが示すというファクトに基づいて、ユーザのオフィスについての規則のセットを識別することができる。同様に、コンテキストは、ユーザが家庭状況(family situation)にある(たとえば、ユーザが「自宅」ジオフェンス内またはユーザの家族のメンバに属すと識別される複数のデバイスの近くにいる)ということであってよく、したがって、規則エンジンプラットフォームは、家庭状況に関連した規則または規則のセットを識別することができる。一実施形態では、家庭状況向けの規則は、「職場」コンテキスト用に識別される規則の補完(complement)として定義され得る。第3の例では、ユーザが運転中であることをコンテキストが示してよく、したがって、運転中に関連した規則のみが、規則エンジンプラットフォームによって識別され、ロードされ得る。
[0195]いくつかの実施形態では、関連規則は、直接識別されない。そうではなく、関連規則は、1つまたは複数の規則セットの選択を通して識別される。規則セットは、対象のコンテキストが識別された場合、関連規則セットが素早く識別され得るように、1つまたは複数のコンテキストに関連付けられ得る。さらに、規則セットは、識別されたコンテキストとの関連性の順で並べられている規則セットの階層などの競合解決アジェンダに従って識別され得る。
[0196]その後、コンテキスト、関連規則またはこれら2つの組合せが、アサートされるべき関連ファクトを決定するのに使われ得る。いくつかの関連ファクトがアサートされるために、1つまたは複数のモジュールへの1つまたは複数のサブスクリプションが、修正される必要があり得る(決定ブロック920)。一実施形態では、関連規則は、たとえば、決定されたアクションがサンプルを戻すべきである場合、アクションを決定するために、1つまたは複数のモジュールへの1つまたは複数のサブスクリプションの変更を必要とする(決定ブロック920)。したがって、方法900を実施するエンジンは、1つまたは複数のモジュールへのサブスクリプションを、関連規則の効率的評価を円滑にするように修正してよい(動作925)。
[0197]一実施形態では、モジュールへのサブスクリプションは、関連規則の評価によって決定され得るアクションに従って修正される。複数のコンテキストにわたって決定されるアクションは、異なる関連規則に準拠して変わり得る。したがって、あるモジュールからのサンプルは、対象のコンテキストには不必要であり得る。したがって、そのモジュールへのサブスクリプションは、そのモジュールからのサンプルが、記憶されないか、または、たとえば、モジュールがポーリングされるレートを削減すること、もしくはストリームからのサンプルが記憶される頻度を削減することによって、低いレートで記憶されるように修正され得る。別のモジュールについては、逆が成り立ってよく、したがって、その別のモジュールへのサブスクリプションは、モジュールがより頻繁に問い合わせされるか、またはサンプルがより頻繁に記憶されるように修正されてよい。
[0198]一実施形態では、モジュールへのサブスクリプションが、関連規則の評価のためにアサートされるべき関連ファクトに従って修正される。複数のコンテキストにわたってアサートされる関連ファクトは、異なる関連規則に準拠して変わり得る。したがって、モジュールへのサブスクリプションは、1つまたは複数の関連ファクトが、関連規則が評価されるのに必要とされる、そのモジュールから受信されたサンプルからアサートされ得るように修正されてよい。
[0199]1つまたは複数のサブスクリプションの修正にもかかわらず、1つまたは複数の関連ファクトがコンテキストに基づいてアサートされ得る(動作930)。関連ファクトは、アサートされる前に、最初に識別され得る。関連ファクトは、1つもしくは複数のコンテキストまたは1つもしくは複数の関連規則もしくはセットに関連付けられたファクトセットなど、1つまたは複数のファクトセットの選択を通して識別され得る。関連ファクトは、サンプルからのファクトもしくはそのファクトがないこと、対象のコンテキスト、またはもう1つの規則を更新することによってアサートされ得る。関連ファクトを識別または/またはアサートする際、関連ファクトは、より速いアクセスのためにロードされ(たとえば、キャッシュメモリ中にロードされ)得る。
[0200]いくつかのファクトは、1つまたは複数のコンテキストにわたって有効なままであるので、対象のコンテキストに基づいて、すべての関連ファクトがアサートされるべきであるとは限らない。たとえば、ファクトは、ユーザが可聴メッセージ通知を不能にしたことを示すサンプルについてアサートされてよく、このファクトは、ユーザが、自宅にいる、職場に向かって運転中、および職場にいるというコンテキストにわたって有効なままであり得る。
[0201]一実施形態では、関連しないファクトが、コンテキストの変化に従って、ヌルまたは偽などのデフォルトにアサートされる(動作930)。したがって、関連ファクトが識別されたとき、対象のコンテキストに関連しないファクトは、リソースを消費しない。代替として、無関連ファクトがアサートされない。たとえば、エンジンは、対象のコンテキストに関連するファクトセット中に含まれないファクトをアサートすることを拒絶し得る。したがって、そのような無関連ファクトがそこからアサートされるサンプルは無視されてよいが、これも、サブスクリプションに対する変更の帰結であり得る。
[0202]続いて、識別された関連規則が評価され得る(動作935)。有利には、関連規則および関連ファクトはすでに識別され、可能性としては高速アクセスのためにロードされ、またはキャッシュされている。したがって、エンジンは、関連ファクトを使って、識別された関連規則を評価する必要があるだけであり得る。したがって、エンジンが、すべての規則を評価し、次いで、コンテキストまたは競合解決アジェンダに基づいて、どのアクションをとるべきか決定するのにリソースを消費しないように、無関連な規則およびファクトは無視されてよい。関連ファクトで関連規則を評価する際、1つもしくは複数のアクションが決定されてよく、および/または1つもしくは複数のファクトがアサートされてよい。
[0203]図9Bを参照すると、規則エンジンプラットフォームを実装するシステムを最適化するための方法950が、一実施形態に従って図示されている。図9Bの動作は、例示的であり、必ずしも図示される順序で実施されるとは限らない。方法950は、図1に示されるポータブル電子デバイス100の規則エンジン132によって実施することができる。方法950は、コンテキスト認識エンジン735と通信可能に結合され得る、図7の規則エンジン730によって実施することもできる。
[0204]最初に、対象のコンテキストが、受信サンプルおよび予想サンプルのうちの少なくとも1つに基づいて決定され得る(動作955)。受信サンプルまたは予想サンプル(たとえば、サンプルがないこと)は、方法950が実施されるシステムのユーザの状況または環境を示し得る。サンプルは、たとえば、カレンダイベント、動き状態、Wi−Fiシグネチャ、または他のどのタイプのサンプルであってもよい。サンプルは、モジュール(たとえば、モジュール101〜106またはモジュール750、755)から受信されてよく、その元の形式から適合されてよい(たとえば、未加工センサデータが処理され得る)。
[0205]一実施形態では、サンプルはファクトとしてアサートされる。必要に応じて、モジュール101〜106から受信されたサンプルなど、受信サンプルおよび予想サンプルのうちの1つに準じるファクトが、リポジトリ中でアサートされる。一実施形態では、ファクトは、サンプルがファクトを実質的に更新する(たとえば、ファクトの真の値を変更する)場合のみ、アサートされる。ファクトは、リポジトリ133、134やリポジトリ715、720などのリポジトリ中でアサートされ得る。ファクトは、リポジトリ中にすでに記憶されていてよい、サンプルまたはファクトの組合せ(たとえば、推論)としてアサートされ得る。一実施形態では、ファクトは、更新を反映するように組織的構造を更新することによってアサートされる。さらに、ファクトは、不揮発性メモリなどの持続記憶装置に追加され得る。
[0206]いくつかの実施形態では、受信または予想サンプルに従って、複数のファクトがアサートされてよく、たとえば、受信サンプルまたは予想サンプルは、2つ以上のファクトの同時期更新を要し得る。特に、これは、1つのサンプルからアサートされるファクトと、複数のサンプルまたはその1つのサンプルを含むファクトからアサートされる1つまたは複数のファクトとに対して成り立ち得る。
[0207]対象のコンテキストは、瞬間的コンテキストでも、期待され、または頻発するコンテキストでもよい。コンテキストは、受信サンプルに加え、複数のサンプルから識別され得る。ただし、コンテキストの識別は、いくつかの実施形態では、1つまたは複数のサンプルがないことを必要とし得る。
[0208]一実施形態では、サンプルから間接的にコンテキストが識別される。たとえば、コンテキストは、サンプルからアサートされるか、またはサンプルからまだアサートされていない(たとえば、ファクトがヌルである)ファクトから識別され得る。さらに、対象のコンテキストは、たとえば、1つのファクトに関係した1つのコンテキストの識別が第2のコンテキストを示す、コンテキストおよび/またはファクトの間の、導出された関係から識別され得る。
[0209]対象のコンテキストを識別することによって、少なくとも1つの規則が複数の規則から識別されてよく、ここにおいて、少なくとも1つの規則は、対象のコンテキストに関連する(動作965)。1つまたは複数の関連規則は、たとえば、方法950が実施されるシステムにとって基本的な規則であってよい。追加関連規則は、識別されたコンテキストに対して一意であっても、共通ファクトを共有するコンテキストなど、いくつかのコンテキストに関連するだけであってもよい。関連規則は、各規則に関連付けられたそれぞれの顕著属性などの競合解決アジェンダに従って識別され得る。したがって、より高い優先権の関連規則と競合する規則は識別されなくてよい。いくつかの実施形態では、対象のコンテキストに関連する規則のサブセットが、複数の規則から識別され、少なくとも1つの規則は、規則のサブセットのメンバであり得る。
[0210]続いて、識別された関連規則は、コンテキストについて評価され得る(動作970)。有利には、少なくとも1つの関連規則は、すでに識別され、可能性としては高速アクセスのためにロードされ、またはキャッシュされている。したがって、エンジンは、識別された関連規則を評価する必要があるだけであり得る。したがって、エンジンが、すべての規則を評価し、次いで、コンテキストまたは競合解決アジェンダに基づいて、どのアクションをとるべきか決定するのにリソースを消費しないように、無関連な規則は無視されてよい(動作975)。関連規則を評価する際、1つもしくは複数のアクションが決定されてよく、かつ/または1つもしくは複数のファクトがアサートされてよい。一実施形態では、少なくとも1つの関連規則は、対象のコンテキストに関連する規則の識別されたサブセットからのものである。
[0211]本明細書に記載される、規則エンジンおよび/または規則エンジンプラットフォームの実施形態は、ポータブル電子デバイスなどのシステムのすべての機能を制御、監視および/または管理するのに使われ得る。そのような機能は、コンテキスト認識、モジュール機能(たとえば、センササブシステムやアプリケーション)、ならびに他のシステム機能(たとえば、電力管理、ユーザ入力受諾および処理など)を含み得るが、それらに限定されない。したがって、本明細書に記載される規則エンジンおよび/または規則エンジンプラットフォームは、センサ、アプリケーション、サブシステム、および他のモジュールまたは機能をどのように、および/またはいつ稼動するべきか決定するためのコントローラとして使われ得る。同様に、本明細書に記載される規則エンジンおよび/または規則エンジンプラットフォームは、システムのセンサ、アプリケーション、サブシステム、および他のモジュールまたは機能の較正、タイミング、活動状態(たとえば、オンまたはオフ)および他の関連機能に影響し得る。
[0212]本明細書で説明した実施形態は、記載される機能を提供するのに適した様々な異なる手段によって実装され得る。一実施形態では、本明細書に記載されるコンピューティングシステムは、複数の規則を規則リポジトリ中に記憶するための手段と、複数のサンプルを提供するように構成された複数のモジュールにサブスクライブするための手段と、サブスクライブする手段に基づいて、対象のコンテキストを識別するための手段と、対象のコンテキストに関連する規則の第1のセットを識別するための手段と、規則の第1のセットに含まれる少なくとも1つの規則を評価するための手段とを含む。
[0213]本明細書の教示は、コンピューティングシステムなどの装置に組み込まれ(たとえば、装置内に実装され、または装置によって実施され)て、その装置の性能を最適化することができる。本明細書に記載される実施形態は、キャッシュ化およびチップセット最適化に対応可能であり得る。いくつかの実施形態では、この最適化は、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROM(登録商標)メモリ、レジスタ、または装置上での実装に適した他の記憶ユニットなどのメモリを犠牲にして起こる。たとえば、本明細書において教示される1つまたは複数の態様は、電話(たとえば、セルラーフォン)、個人情報端末(PDA)、タブレットコンピュータ、モバイルコンピュータ、ラップトップコンピュータ、娯楽デバイス(たとえば、音楽もしくはビデオデバイス)、デスクトップコンピュータ、クライアントコンピューティングシステム、サーバコンピューティングシステムまたは他の同様のコンピューティングシステム中に組み込まれ得る。これらのシステムは、様々な電力要件およびデータ要件を有する場合がある。
[0214]情報および信号は様々な異なる技術および技法のいずれかを使用して表すことができることを、当業者は理解されよう。たとえば、上記の説明全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁界もしくは磁性粒子、光場もしくは光子、またはそれらの任意の組合せによって表され得る。
[0215]さらに、本明細書で開示した実施形態に関して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装できることを当業者なら諒解されよう。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップについて、上記では概してそれらの機能性に関して説明した。そのような機能がハードウェアとして実装されるか、ソフトウェアとして実装されるかは、特定の適用例および全体的なシステムに課される設計制約に依存する。当業者は、説明された機能を具体的な適用例ごとに多様な方法で実装し得るが、そのような実装の決定は、本発明の範囲からの逸脱を生じるものと解釈されるべきではない。
[0216]本明細書で開示される実施形態に関して説明される様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または、本明細書で説明される機能を実施するように設計されたそれらの任意の組合せによって、実装または実施され得る。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、またはマイクロコントローラであり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装され得る。
[0217]本明細書で開示されている実施形態に関して説明されている方法またはアルゴリズムのステップは、ハードウェアで直接、プロセッサにより実行されるソフトウェアモジュールにより、またはこれら2つの組合せにより具現化することができる。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、またはポータブル電子デバイスに適した、当技術分野で知られている任意の他の形態の記憶媒体中に常駐し得る。例示的な記憶媒体は、プロセッサがその記憶媒体から情報を読み取ることができ、その記憶媒体に情報を書き込むことができるように、プロセッサに結合可能である。代替として、記憶媒体はプロセッサに一体化され得る。プロセッサおよび記憶媒体はASIC内に存在することができ得る。ASICはユーザ端末中に常駐し得る。代替として、プロセッサおよび記憶媒体は、ユーザ端末内の個別構成要素として常駐することができる。
[0218]1つまたは複数の例示的な実施形態では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。コンピュータプログラム製品としてソフトウェアに実装された場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶されるか、またはコンピュータ可読媒体を介して送信され得る。コンピュータ可読媒体は、あるロケーションから別のロケーションへのコンピュータプログラムの転送を可能にする任意の媒体を含む、コンピュータ記憶媒体と通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体でよい。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、または所望のプログラムコードを、命令またはデータ構造の形で運び、または記憶するのに使われ得るとともに、コンピュータ(たとえば、コンピューティングデバイスとして構成されたポータブル電子デバイス)によってアクセスされ得る他のどの媒体も備え得る。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)およびBlu−ray(登録商標)ディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザーで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。コンピュータ可読媒体は、いくつかの実施形態では、非一時的であってよい。
[0219]開示した実施形態の前述の説明は、いかなる当業者も本発明を実施または使用できるようにするために提供されるものである。これらの実施形態への様々な修正は当業者には容易に明らかであり、本明細書で定義した一般原理は、本発明の趣旨または範囲から逸脱することなく他の実施形態に適用され得る。したがって、本発明は、本明細書に示す実施形態に限定されるものではなく、本明細書で開示する原理および新規の特徴と一致する最も広い範囲を与えられるべきある。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
[1] ユーザに関連付けられたシステムによって実行される、規則エンジンを適合させるための方法であって、
第1のサンプリングモジュールからの受信サンプルおよび予想サンプルのうちの少なくとも1つに基づいて、前記システムの第1のコンテキストを決定することと、
第1の複数の規則のうちの少なくとも1つの規則を識別することと、ここで、前記識別された少なくとも1つの規則は前記第1のコンテキストに関連し、
前記第1のコンテキストについての前記識別された関連規則を評価することと、
前記第1のコンテキストに無関連である、前記第1の複数の規則中の残りの少なくとも1つの規則を、前記少なくとも1つの規則が前記第1のコンテキストについて評価されないように無視することと、
を備える方法。
[2] 前記少なくとも1つの関連規則を識別することは、
前記第1の複数の規則から、前記少なくとも1つの規則を含む、前記第1のコンテキストに関連する第2の複数の規則を有する関連規則セットを識別することを備える、[1]に記載の方法。
[3] 前記関連規則セットの各規則を評価することをさらに備える、[2]に記載の方法。
[4] 前記第1の複数の規則から、前記第1のコンテキストに関連するとともに評価されるべきである第3の複数の規則を有する第2の規則セットを識別することをさらに備える、[2]に記載の方法。
[5] 前記第1のコンテキストは前記ユーザのオフィスであり、前記関連規則セットはオフィスコンテキストに関連する、[2]に記載の方法。
[6] 前記第1のコンテキストは、ロケーションおよびジオフェンスのうちの1つである、[1]に記載の方法。
[7] 前記第1のサンプリングモジュールは、セルラーモジュール、Bluetoothモジュール、Wi−Fiモジュール、ユーザ入力モジュール、ニアフィールド通信モジュール、衛星測位システムモジュール、または前記システムのメモリに記憶されたアプリケーションモジュールのうちの1つである、[6]に記載の方法。
[8] 前記第1のコンテキストに関連する少なくとも1つのファクトを識別することをさらに備える、[1]に記載の方法。
[9] 前記関連規則によって必要とされる前記少なくとも1つのファクトを識別するために、前記関連規則を分解することをさらに備える、[8]に記載の方法。
[10] 前記第1のコンテキストに関連する前記少なくとも1つのファクトを識別することは、
前記少なくとも1つのファクトを含む、前記第1のコンテキストに関連する複数のファクトを有する関連ファクトセットを識別することを備える、[8]に記載の方法。
[11] 前記第1のコンテキストに基づいて、前記少なくとも1つのファクトをアサートすることをさらに備える、[8]に記載の方法。
[12] 前記第1のコンテキストは、前記ユーザが運転中であることを示し、前記少なくとも1つのファクトは、前記第1のコンテキストに基づいて、前記ユーザが遷移中であることを示すようにアサートされる、[11]に記載の方法。
[13] 前記第1のコンテキストに関連しない第2のファクトをデフォルトにアサートすることをさらに備える、[8]に記載の方法。
[14] 前記第1のコンテキストに関連しない前記第2のファクトをアサートすることは、
前記第2のファクトを含む、前記第1のコンテキストに関連しない複数のファクトを有する第2のファクトセットを識別することと、
前記第2のファクトセット中の前記複数のファクトの各ファクトをデフォルトにアサートすることと、
を備える、[13]に記載の方法。
[15] 前記関連規則を満足することを求められる、第2のサンプリングモジュールによって提供される、第2の受信サンプルおよび第2の予想サンプルのうちの少なくとも1つについてのサンプリング要件を決定することと、
前記関連規則の前記サンプリング要件に基づいて、最適化方式を計算することと、
前記最適化方式に基づいて、前記第2のサンプリングモジュールのサンプリングレートを修正することと、
をさらに備える、[1]に記載の方法。
[16] 前記サンプリングレートを修正することは、
前記第2のサンプリングモジュールへのサブスクリプションを修正することを備える、[15]に記載の方法。
[17] 前記第1のコンテキストに関連する規則セットを満足することを求められる複数のサンプリング要件を決定することと、ここで、前記規則セットは、前記関連規則を含む複数の規則を備え、
前記関連規則のセットの前記複数のサンプリング要件に基づいて、最適化方式を計算することと、
前記最適化方式に基づいて、前記複数のサンプリング要件のそれぞれのサンプリング要件についての少なくとも1つのサンプルを提供するべきである第2のサンプリングモジュールのサンプリングレートを修正することと、
をさらに備える、[1]に記載の方法。
[18] 前記最適化方式を計算することは、
前記複数のサンプリング要件を評価することと、
前記複数のサンプリング要件の前記評価から、第1の規則の第1のサンプリング要件が、前記第2のサンプリングモジュールからのサンプルを第1のレートで必要とし、第2の規則の第2のサンプリング要件が、前記第2のサンプリングモジュールからの前記サンプルを、前記第1のレートとは異なる第2のレートで必要とすると決定することと、
前記第1の規則および前記第2の規則にとって満足できる、前記第2のサンプリングモジュールの最適サンプリングレートを指定する最適化パラメータを計算することと、
を備える、[17]に記載の方法。
[19] 前記第1のサンプリングモジュールによって提供されるサンプルを受信することを備え、決定することは、
提供されるべき前記サンプルと、記憶されたコンテキストとの間のマッピングを識別することと、
前記第1のコンテキストが、前記記憶されたコンテキストを含むと決定することとを備える、[1]に記載の方法。
[20] 前記サンプルはWi−Fiシグネチャであり、前記記憶されたコンテキストは建物内の部屋である、[19]に記載の方法。
[21] 前記第1のコンテキストと第2のコンテキストとの間の関係を導出することをさらに備える、[1]に記載の方法。
[22] 前記第1のコンテキストは、前記ユーザが自宅にいることを示し、前記第2のコンテキストは、前記ユーザがオフィスにいることを示し、前記導出された関係は、前記ユーザが前記自宅から前記オフィスに移動するための移動持続時間を含む、[21]に記載の方法。
[23] 少なくとも1つのサンプリングモジュールを含む複数のモジュールと、前記サンプリングモジュールは前記サンプリングモジュールに関連付けられたサンプルを送るように構成され、
複数の規則を記憶するように構成された規則リポジトリと、前記サンプリングモジュールからの受信サンプルおよび予想サンプルのうちの少なくとも1つに基づいて、前記コンピューティングシステムの対象のコンテキストを決定するように構成されたコンテキスト認識エンジンと、前記対象コンテキストに基づいて、前記対象コンテキストに関連する、前記複数の規則に含まれる規則の第1のセットを識別するとともに規則の前記第1のセットの少なくとも1つの規則を評価するように構成された規則エンジンと、を含む規則エンジンプラットフォームを実行するように動作可能なプロセッサと、
を備えるコンピューティングシステム。
[24] 前記プロセッサは、前記複数のモジュールのそれぞれのモジュールを実行するようにさらに構成される、[23]に記載のコンピューティングシステム。
[25] 前記規則エンジンは、
前記対象コンテキストに関連しない、前記複数の規則に含まれる規則の第2のセットを、前記第2のセットに含まれるどの規則も、前記対象コンテキストについて評価されないように、無視するようにさらに構成される、[23]に記載のコンピューティングシステム。
[26] 前記規則エンジンは、前記対象コンテキストに関連する、前記複数の規則に含まれる規則の第3のセットを識別するようにさらに構成される、[23]に記載のコンピューティングシステム。
[27] 前記規則エンジンは、競合解決アジェンダによる評価のために前記少なくとも1つの規則を識別するようにさらに構成され、ここで、前記少なくとも1つの規則は、前記対象コンテキストに関連する規則の前記第1および第3のセットのうちの1つに含まれる第2の規則と競合する、[26]に記載のコンピューティングシステム。
[28] 前記コンテキスト認識エンジンは、少なくとも1つのサンプルの受信と前記少なくとも1つのサンプルがないこととのうちの1つに基づいて、前記対象コンテキストを決定するように構成される、[23]に記載のコンピューティングシステム。
[29] 前記対象コンテキストは、前記コンピューティングシステムのユーザが、会議中、話し合い中、電話中、ジオフェンスの近くにいる、人の近くにいる、自宅にいる、会議に遅れる、および運転中のうちの1つであることを示す、[23]に記載のコンピューティングシステム。
[30] 前記対象コンテキストは、瞬間的コンテキスト、期待されるコンテキストおよび頻発するコンテキストのうちの1つである、[23]に記載のコンピューティングシステム。
[31] 前記サンプリングモジュールは、セルラーモジュール、Bluetoothモジュール、Wi−Fiモジュール、ユーザ入力モジュール、ニアフィールド通信モジュール、全地球測位システムモジュール、または前記コンピューティングシステムのメモリに記憶されたアプリケーションモジュールのうちの1つである、[23]に記載のコンピューティングシステム。
[32] 前記規則エンジンは、前記対象コンテキストに基づいて、前記対象コンテキストに関連する少なくとも1つのファクトを識別するようにさらに構成される、[23]に記載のコンピューティングシステム。
[33] 前記規則エンジンは、規則の前記第1のセットの前記少なくとも1つの規則によって必要とされる前記少なくとも1つのファクトを識別するために、前記対象コンテキストに基づいて識別される規則の前記第1のセットに含まれる前記規則を分解するように構成される、[32]に記載のコンピューティングシステム。
[34] 前記規則エンジンは、前記対象コンテキスト、少なくとも1つのサンプルの受信、および前記少なくとも1つのサンプルがないことのうちの1つから、前記識別されたファクトをアサートするようにさらに構成される、[32]に記載のコンピューティングシステム。
[35] 前記規則エンジンは、前記対象コンテキストに関連しない複数のファクトを、ヌルおよび偽のうちの1つにアサートするようにさらに構成される、[23]に記載のコンピューティングシステム。
[36] 前記規則エンジンは、第2のサンプリングモジュールにサブスクライブするように、および前記第2のサンプリングモジュールへの前記サブスクリプションを、前記対象コンテキストに基づいて修正するようにさらに構成される、[23]に記載のコンピューティングシステム。
[37] 前記規則エンジンは、前記第2のサンプリングモジュールが問い合わされるレート、前記第2のサンプリングモジュールがポーリングされるレート、および前記第2のサンプリングモジュールからのサンプリングストリーム中で受信された複数のサンプルが記憶されるレートのうちの1つを修正することによって、前記サブスクリプションを修正するように構成される、[36]に記載のコンピューティングシステム。
[38] 前記対象コンテキストは、前記コンピューティングシステムのユーザが人の近くにいることを示し、さらに、前記規則エンジンプラットフォームは、前記人についてのコンタクト情報を含むサンプルが受信されるように、前記第2のサンプリングモジュールへの前記サブスクリプションを修正するように構成される、[36]に記載のコンピューティングシステム。
[39] 前記規則エンジンプラットフォームは、
前記対象コンテキストに関連する、前記第1のセットの規則を満足することを求められる複数のサンプリング要件を決定し、
前記複数のサンプリング要件に基づいて最適化方式を計算し、および
前記最適化方式に基づいて、少なくとも1つの必要とされるサンプルを提供するように構成された第2のサンプリングモジュールのサンプリングレートを修正する
ように構成された最適化エンジンをさらに含む、[23]に記載のコンピューティングシステム。
[40] 前記規則エンジンは、前記対象コンテキストと第2のコンテキストとの間の関係を導出するようにさらに構成される、[23]に記載のコンピューティングシステム。
[41] 複数の規則を規則リポジトリに記憶するための手段と、
複数のサンプルを提供するように構成された複数のモジュールにサブスクライブするための手段と、
前記サブスクライブする手段に基づいて、対象のコンテキストを識別するための手段と、
前記対象コンテキストに関連する規則の第1のセットを識別するための手段と、
規則の前記第1のセットに含まれる少なくとも1つの規則を評価するための手段と、
を備えるコンピューティングシステム。
[42] 命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記命令は、コンピューティングシステムによって実行されると、前記コンピューティングシステムに方法を実施させ、前記方法は、
第1のサンプリングモジュールからの受信サンプルおよび予想サンプルのうちの少なくとも1つに基づいて、前記コンピューティングシステムの第1のコンテキストを決定することと、
第1の複数の規則のうちの少なくとも1つの規則を識別することと、ここで、前記識別された少なくとも1つの規則は前記第1のコンテキストに関連し、
前記第1のコンテキストについての前記識別された関連規則を評価することと、
前記第1のコンテキストに無関連である、前記第1の複数の規則中の残りの少なくとも1つの規則を、前記少なくとも1つの規則が前記第1のコンテキストについて評価されないように無視することと、
を備える非一時的コンピュータ可読記憶媒体。