特許第6383170号(P6383170)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ パロ・アルト・リサーチ・センター・インコーポレーテッドの特許一覧

特許6383170一般化された状況判断知能プラットフォーム
<>
  • 特許6383170-一般化された状況判断知能プラットフォーム 図000002
  • 特許6383170-一般化された状況判断知能プラットフォーム 図000003
  • 特許6383170-一般化された状況判断知能プラットフォーム 図000004
  • 特許6383170-一般化された状況判断知能プラットフォーム 図000005
  • 特許6383170-一般化された状況判断知能プラットフォーム 図000006
  • 特許6383170-一般化された状況判断知能プラットフォーム 図000007
  • 特許6383170-一般化された状況判断知能プラットフォーム 図000008
  • 特許6383170-一般化された状況判断知能プラットフォーム 図000009
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6383170
(24)【登録日】2018年8月10日
(45)【発行日】2018年8月29日
(54)【発明の名称】一般化された状況判断知能プラットフォーム
(51)【国際特許分類】
   G06F 17/30 20060101AFI20180820BHJP
【FI】
   G06F17/30 340A
   G06F17/30 240A
【請求項の数】10
【全頁数】15
(21)【出願番号】特願2014-77262(P2014-77262)
(22)【出願日】2014年4月3日
(65)【公開番号】特開2014-216010(P2014-216010A)
(43)【公開日】2014年11月17日
【審査請求日】2017年3月31日
(31)【優先権主張番号】13/873,061
(32)【優先日】2013年4月29日
(33)【優先権主張国】US
(73)【特許権者】
【識別番号】502096543
【氏名又は名称】パロ・アルト・リサーチ・センター・インコーポレーテッド
【氏名又は名称原語表記】Palo Alto Research Center Incorporated
(74)【代理人】
【識別番号】100079049
【弁理士】
【氏名又は名称】中島 淳
(74)【代理人】
【識別番号】100084995
【弁理士】
【氏名又は名称】加藤 和詳
(72)【発明者】
【氏名】マイケル・ロバーツ
(72)【発明者】
【氏名】シェーン・ピー・アハーン
(72)【発明者】
【氏名】オリバー・ブルディクツカ
【審査官】 石田 信行
(56)【参考文献】
【文献】 特開2002−108918(JP,A)
【文献】 特表2004−535000(JP,A)
【文献】 特表2011−522331(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 17/30
(57)【特許請求の範囲】
【請求項1】
ユーザの情報をリコメンダに供給する、サーバにより行われる、コンピュータで実行可能な方法であって、
コンテキストグラフの変更の通知に関する登録を前記リコメンダから受信するステップであって、前記コンテキストグラフには、ユーザの行動、および/または、ユーザの関心に関する情報が含まれる、ステップと、
携帯機器の物理的環境を検知する検知器を用いて集められた状況データから得られたイベントデータを前記携帯機器から受信するステップと、
前記イベントデータに基づいて、前記コンテキストグラフを修正するステップと、
前記コンテキストグラフの前記修正が、前記登録と一致するかどうかを判定するステップと、
コンテキストグラフの変更の通知を前記リコメンダに送信するステップと、を含む方法。
【請求項2】
アプリケーションのイベントデータ、および/または、オペレーティングシステムのイベントデータを含む付加的なイベントデータを前記携帯機器から受信するステップと、
前記付加的なイベントデータに基づいて、前記コンテキストグラフを修正するステップと、
前記コンテキストグラフの前記修正が、前記登録と一致するかどうかを判定するステップと、
コンテキストグラフの変更の通知を前記リコメンダに送るステップと、をさらに含む請求項1に記載の方法。
【請求項3】
前記イベントデータには、前記携帯機器により状況データから生成されたハイレベルのイベントデータが含まれる、請求項1に記載の方法。
【請求項4】
コンテキストグラフのデータに関するクエリーを前記リコメンダから受信するステップと、
前記コンテキストグラフのデータを前記リコメンダに送るステップと、をさらに含む請求項1に記載の方法。
【請求項5】
RESTful WebAPIを通して、リアルタイムのイベントデータを受信するステップと、
前記受信したリアルタイムのイベントデータに基づいて、前記コンテキストグラフのデータを修正するステップと、をさらに含む請求項1に記載の方法。
【請求項6】
一括してアップロードされたイベントデータを、イベント書き込みインターフェースを通して受信するステップと、
前記受信した一括してアップロードされたイベントデータに基づいて、前記コンテキストグラフのデータを修正するステップと、をさらに含む請求項1に記載の方法。
【請求項7】
コンピュータが実行すると、前記コンピュータにユーザの情報をリコメンダに供給する方法を実行させる命令を格納する、コンピュータ可読記憶媒体であって、
前記命令には、
コンテキストグラフの変更の通知に関する登録を前記リコメンダから受信するステップであって、前記コンテキストグラフには、ユーザの行動、および/または、ユーザの関心に関する情報が含まれる、ステップと、
携帯機器の物理的環境を検知する検知器を用いて集められた状況データから得られたイベントデータを前記携帯機器から受信するステップと、 前記イベントデータに基づいて、前記コンテキストグラフを修正するステップと、
前記コンテキストグラフの前記修正が、前記登録と一致するかどうかを判定するステップと、
コンテキストグラフの変更の通知を前記リコメンダに送るステップと、が含まれる、コンピュータ可読記憶媒体。
【請求項8】
ユーザの情報をリコメンダに供給するコンピュータシステムであって
1つ以上のプロセッサと、
その中に格納された命令を有する、前記1つ以上のプロセッサに接続したコンピュータ可読媒体であって、前記命令を前記1つ以上のプロセッサが実行すると、前記1つ以上のプロセッサが、
コンテキストグラフの変更の通知に関する登録を前記リコメンダから受信する動作であって、前記コンテキストグラフには、ユーザの行動、および/または、ユーザの関心に関する情報が含まれる、動作と、
携帯機器の物理的環境を検知する検知器を用いて集められた状況データから得られたイベントデータを前記携帯機器から受信する動作と、
前記イベントデータに基づいて、前記コンテキストグラフを修正する動作と、
前記コンテキストグラフの前記修正が、前記登録と一致するかどうかを判定する動作と、
コンテキストグラフの変更の通知を前記リコメンダに送る動作と、を行う、コンピュータ可読媒体と、を含むコンピュータシステム。
【請求項9】
前記コンピュータ可読媒体が付加的な命令を格納し、前記付加的な命令を実行すると前記コンピュータが、付加的なステップを行い、前記付加的なステップには、
アプリケーションのイベントデータおよび/またはオペレーティングシステムのイベントデータを含む付加的なイベントデータを前記携帯機器から受信するステップと、
前記付加的なイベントデータに基づいて、前記コンテキストグラフを修正するステップと、
前記コンテキストグラフの前記修正が、前記登録と一致するかどうかを判定するステップと、
コンテキストグラフの変更の通知を前記リコメンダに送るステップと、が含まれる、請求項8に記載のコンピュータシステム。
【請求項10】
前記イベントデータには、前記携帯機器により、状況データから生成されたハイレベルのイベントデータが含まれる、請求項8に記載のコンピュータシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、一般に状況判断知能に関する。より具体的には、本開示は、携帯機器の状況情報を集め、専用アプリケーションを一般の状況判断知能システムに対して、効率的に適用し易くする方法およびシステムに関する。
【発明の概要】
【課題を解決するための手段】
【0002】
本発明の一実施形態では、リコメンダにユーザの情報を供給するシステムが提供される。動作中、このシステムは、コンテキストグラフの変更の通知に関する登録をリコメンダから受信する。コンテキストグラフには、ユーザの行動、および/またはユーザの関心に関する情報が含まれる。次に、このシステムは、携帯機器の物理的環境を検知する検知器を用いて、集められた状況データから得られたイベントデータを携帯機器から受信する。システムは、イベントデータに基づいて、コンテキストグラフを修正する。次いで、このシステムは、コンテキストグラの修正が登録と一致しているかどうかを判定し、コンテキストグラフの変更の通知をリコメンダに送信する。
【0003】
この実施形態の一変形例では、このシステムは、携帯機器から、アプリケーションのイベントデータ、および/またはオペレーティングシステムのイベントデータを含む付加的なイベントデータを受信する。次いで、このシステムは、この付加的なイベントデータに基づいて、コンテキストグラフを修正する。システムは、コンテキストグラの修正が登録と一致しているかどうかを判定し、コンテキストグラフの変更の通知をリコメンダに送信する。
【0004】
この実施形態の一変形例では、このイベントデータには、状況データから携帯機器により生成されたハイレベルのイベントデータが含まれる。
【0005】
この実施形態の一変形例では、このシステムは、コンテキストグラフのデータに関するクエリーをリコメンダから受信し、コンテキストグラフのデータをリコメンダに送信する。
【0006】
この実施形態の一変形例では、このシステムは、RESTful WebAPIを通して、リアルタイムのイベントデータを受け取り、この受信したリアルタイムのイベントデータに基づいて、このコンテキストグラフのデータを修正する。
【0007】
この実施形態の一変形例では、このシステムは、イベント書き込みインターフェースを通して、一括してアップロードされたイベントデータを受信し、この受信した、一括してアップロードされたイベントデータに基づいて、コンテキストグラフのデータを修正する。
【図面の簡単な説明】
【0008】
図1図1は、一実施形態による、イベントデータをサーバに通信する携帯機器を示すブロック図である。
図2図2は、一実施形態による、クライアント側のアーキテクチャを示すブロック図である。
図3図3は、一実施形態による、クライアント側でイベントを処理する構成要素とサーバ側でイベントを処理する構成要素との関係を示すブロック図である。
図4図4は、一実施形態による、イベント、マッパー、およびコンテキストグラフの間の関係を示すブロック図である。
図5図5は、一実施形態による、クライアント上でイベントデータを集め、かつ公開する例示的なプロセスを示すフローチャートである。
図6図6は、一実施形態による、サーバ上でのイベント処理の例示的なプロセスを示すフローチャートである。
図7図7は、本発明の一実施形態による、イベントデータを取り込むための例示的な携帯機器を示す図である。
図8図8は、本発明の一実施形態による、イベントを処理するための例示的なサーバを示す図である。
【発明を実施するための形態】
【0009】
図面において、同様の参照符号は同じ番号の要素を指す。
【0010】
本発明の実施形態では、特別なアプリケーションに適する一般の状況判断知能プラットフォームを提供することにより、状況認識システムを効率的に開発するという課題を解決する。このような状況判断知能システムにより、状況情報のリアルタイム処理が容易になり、ウェブおよびモバイルのアプリケーションに関する状況アプリケーションの開発を容易にする。
【0011】
一般の状況判断知能プラットフォームは、クライアント側のアーキテクチャと、サーバ側のアーキテクチャとを含む。クライアント側のアーキテクチャは、状況データを集め、処理した状況データをイベントデータとしてサーバ側のアーキテクチャに送信する。状況データには、物理的環境の状況、および/またはアプリケーションの状況、および/またはオペレーティングシステムの状況など、携帯機器のクライアントにより検知されたコンピュータの状況が記述されている。サーバ側のアーキテクチャは、状況データを格納しその状況データを用いて、ユーザの行動および関心のある情報が含まれているグラフを修正する。アプリケーションは、グラフからの情報を用いてアプリケーション専用のユーザモデルを修正し、推薦を生成することができる。
【0012】
クライアント側のアーキテクチャは、物理的環境の状況、アプリケーションの状況、およびオペレーティングシステムの状況を含むコンピュータの状況を検知することにより、状況データを集め、分析し、集めたデータを記憶装置に書き込む。クライアント側のアーキテクチャは、ハードウェアの検知器を通して検知された、アプリケーションからの状況、またはオペレーティングシステムからの状況を処理し、この処理された状況データをローレベルのイベントデータとして格納する。ローレベルのイベントデータとは、状況から検知されたイベントのことを示し、クライアント側のアーキテクチャによって生成されるデータではない。例えば、ローレベルのイベントは、加速度計により感知された歩行パターン、アプリケーション内、またはスクリーンキャプチャ内のボタンの選択であり得る。クライアント側のアーキテクチャは、状況データを用いてハイレベルのイベントを生成し、そのハイレベルのイベントをサーバに送信することができる。ハイレベルのイベントは、例えば、ユーザが読むEメールであり得る。クライアント側のアーキテクチャはまた、クライアント上で実行するアプリケーションにイベントデータを送信することもできる。
【0013】
サーバ側のアーキテクチャは、イベント情報をクライアントから受信し、そのイベント情報を分析してコンテキストグラフを修正することができる。コンテキストグラフとは、ユーザの行動および関心に関する事実およびアサーションを格納するインメモリモデルである。サーバは、出版/購読イベントシステムを用いてリコメンダにイベントを送信することもできる。リコメンダとは、ユーザに関するアイテムまたは行動を推薦するアプリケーションである。これらのリコメンダは、コンテキストグラフから得られたユーザの情報を用いてアプリケーション専用のユーザモデルを維持する。イベントデータのイベントが特定のリコメンダからの購読要求と一致すると、サーバはそのイベントデータをリコメンダに送信する。次いで、これらのリコメンダは、そのユーザの情報を用いて自分のアプリケーション専用のユーザモデルを修正し、そのアプリケーション専用のユーザモデルに基づいて推薦を作る。
【0014】
開示された一般的なインフラクチャを専用のニーズに適用させるために必要なことは、専用の行動検知モジュール、専用のユーザモデル、および/または専用のリコメンダを供給するだけである。このインフラクチャはモジュール構造として設計され、異なる機能が区分されており、互いに依存しない。それらの特定のアプリケーションに関して1つ以上のモジュールをカスタマイズすることができ、かつ/または初期設定のモジュールを用いることも可能である。エンジニアは一般のインフラクチャを適用し、それらのアプリケーション内に状況判断知能機能を組み込むことができ、状況認識機能を用いて、このアプリケーションを収益化することさえ可能である。一般のインフラクチャを適用することにより、専用の状況判断知能システムの開発において、かなりの時間と費用を節約することができる。
【0015】
図1には、実施形態による、イベントデータをサーバに通信する携帯機器のブロック図が示されている。図1では、携帯機器102、104、および106が、GPS、加速度計、および/またはコンパスなどの検知器を用いて状況データを集める。そのような状況データには、ユーザが、例えば、歩く、走る、または携帯機器上でアプリケーションを開くなどの特定の行動をしていることが示され得る。この状況データには、オペレーティングシステムのローレベルのイベントデータも含まれ得る。これらの携帯機器は、状況データを処理し、ローレベルのイベントデータとして格納することができる。携帯機器はまた、ユーザが文書を書いていることを示すデータなどのハイレベルのイベントデータを生成することもできる。携帯機器は、ネットワーク110を通して、イベントデータをサーバ108に送信することができる。ある実施形態では、携帯機器がハイレベルのイベントだけをサーバに送信することができる。
【0016】
サーバ108は、受信したイベントデータを格納し分析し公開する。サーバ108は、イベントデータを用いてコンテキストグラフを修正可能である。コンテキストグラフ内に収められたユーザの情報を用いて、アプリケーション専用のユーザモデルを修正可能である。このようなアプリケーション専用のユーザモデルにより、リコメンダのアプリケーションの実装が容易になる。
【0017】
図2には、一実施形態による、クライアント側のアーキテクチャのブロック図が示されている。クライアント側のアーキテクチャ200には、様々な構成要素が含まれ、これらの構成要素により、物理的状況データおよびアプリケーションの状況データが集められ、次いでそれらのデータが処理されデータベースに記録される。これらの構成要素は、データを分析し、それらの分析されたデータに基づいて、ハイレベルのイベントが生成される。クライアント側のアーキテクチャ200は、それらのイベントをイベントクライアント上のアプリケーション、およびサーバ上に公開する。
【0018】
クライアント側のアーキテクチャ200は、GPS202、加速度計204、およびコンパス206などの物理検知器を含む。これらの物理検知器が、携帯機器の周囲の物理的状況を検知する。そして、システムは、物理検知器を用いるためのアブストラクションを供給し、このアブストラクションには、ラットフォームのアプリケーションプログラミングインターフェース(API)208が含まれる。このプラットフォームAPI208は、装置との通信を容易にし、状況データに対する予備処理を行うことができる。次いで、プラットフォームAPI208は、その出力をデータロガー210およびクライアントの分析パッケージ216に送信する。クライアントの分析パッケージ216は、物理的データおよびアプリケーションデータを分析し、ハイレベルのイベントを生成してサーバに転送する。複数の分析用の構成要素がクライアント上で動作可能である。このシステムはまた、取り込まれたアプリケーションデータ209をデータロガー210に送信することも可能である。なお、取り込まれたアプリケーションデータ209には、アプリケーション内で起こったユーザイベントが含まれる。データロガー210は、データベースのアブストラクションレイヤ214を介して、物理的状況データおよび取り込まれたアプリケーションデータをプラットフォームのデータベース212に書き込むことができる。プラットフォームのデータベース212は、データの分析を容易にするために、履歴トレースを格納している。
【0019】
このシステムは、複数の異なる技術を用いて、状況データを集めることができる。このシステムは、クライアントのアプリケーションの内部から、あるいは特別なデータロガーのアプリケーションを介して、状況データを得ることができる。例えば、このシステムは、直接アプリケーションから、埋め込みフックを介して状況データを集めることができる。また、このシステムはオペレーティングシステムを通して、例えば、スクリーンを取り込むこと、クリックイベントを検知すること、イベントログファイルを送信することにより、状況データを集めることもできる。さらに、このシステムは、状況データをGPS受信機、加速度計などの装置から集めることもできる。
【0020】
クライアント側のアーキテクチャ200は、集中型リスナーパターンを実装し、これにより、接続したアプリケーションは状況イベントを登録して、分析システムから受信することができる。複数のアプリケーションおよびモジュールが存在し得、これらのアプリケーションおよびモジュールが状況情報を登録し利用する。集中型リスナーパターンを用いることにより、クライアントは、集中型サーバシステムにイベントを、ローレベルの行動トレース、または分析システムにより生成されたハイレベルのイベントのどちらかとして送信可能である。
【0021】
インメモリの出版/購読システム218は、集中型リスナーパターンを実装して、状況イベントをクライアントのアプリケーション、およびHTTPのサーバスタブ220に供給する。このクライアント側のアーキテクチャ200により、アプリケーションを特定の種類イベントに関して登録することができる。例えば、位置固有のイベントに関与するアプリケーションを選択して、GPSのイベントに関して登録することができる。クライアント側の分析と関与の登録により、このインフラクチャは大きなボリュームのイベントを有するマルチユーザシステムの影響を削減することができ、それによりサーバがオーバロードする可能性を低くする。
【0022】
一実施形態では、HTTPのサーバスタブ220により、ハイレベルのイベントの遠隔サーバへの送信が容易になる。HTTPのサーバスタブ220は、出版/購読システム218からイベントを受け取り、HTTPを用いてイベントを遠隔サーバシステムに送信することができる(例えば、JavaScript Object Notation(JSON)の形式で)。なお、このスタブを設定してイベントの送信をカスタマイズすることができる。ある実施形態では、このスタブは、出版/購読システムに登録されたイベント中継するだけである。
【0023】
サーバ側の処理により、ソーシャルアプリケーション、すなわち単一のクライアント上で実行可能なデータ処理よりもハイレベルのデータ処理を必要とするアプリケーション、またはサーバ側が持続状態であることが必要なアプリケーションの実行が容易になる。サーバ側の処理を必要とするこれらのケースに関して、クライアントは、リアルタイムでアップロードにより、あるいは一括のアップロードにより、サーバにデータをアップロードすることができる。
【0024】
連続してリアルタイムにイベントをアップロードするために、クライアントは、サーバベースのRESTful WebAPIにJSONメッセージを書き込むことができる。RESTful Web APIとは、HTTP、およびRESTの原理を用いて、実施されるウェブ上のサービスである。RESTとは、ワールド・ワイド・ウェブなどの分散システムに関するソフトウェアアーキテクチャの方式である。クライアントは、そのデータが関連するユーザに関するユーザIDを用いてリアルタイムのイベントを認識することができる。リアルタイムでイベントをアップロードすることにより、クライアントは、リアルタイムのアプリケーションに関して、ユーザの状態を絶えず更新することができる。
【0025】
一括したアップロードに関して、クライアントは、HTTP POSTを用いて、大きなデータファイルを(例えば、データベースから)アップロードすることができる。アプリケーション特定コードにより、このように一括してアップロードしたデータを処理してサーバ側のデータストアに格納可能である。なお、機械学習技術を用いて分析されることを意図した、スクリーンショットまたは大量のローレベルのログファイルなどの大きなブロックのデータに関して、クライアントは一括してアップロードを行うことが可能である。
【0026】
図3には、一実施形態による、クライアント側でイベントを処理する構成要素とサーバ側でイベントを処理する構成要素との関係を示すブロック図が示されている。図3には、サーバ内のイベント処理システムが、携帯機器からイベントデータを受信し、その後、そのイベントデータを分析し格納する様子が示されている。また、この図には、サーバの構成要素が、出版/購読イベントシステムとやり取りを行い、この出版/購読イベントシステムが、イベントデータをコンテキストグラフに送信する様子も示されている。コンテキストグラフは、アプリケーション専用のユーザモデルに適用可能である一般のユーザモデル情報を格納する。このユーザモデル情報に関しては、図4を参照してさらに詳しく説明する。
【0027】
図3では、図2に関して説明した通り、最初に携帯機器300が、GPS202およびコンパス206を用いて、物理的状況データを集め、ユーザのやり取り301を含むアプリケーションイベントを検知する。携帯機器300は、状況データを分析、かつ/または、クライアント側の分析パッケージ216を用いてハイレベルのイベントを生成し、そのイベントをサーバに送信することができる。クライアントは、イベント書き込みインターフェース302、および/または、RESTful WebAPI(図4を参照されたい)を介して、ハイレベルのイベントおよびローレベルのイベントの両方をサーバに送信することができる。
【0028】
サーバ側のRESTful WebAPIでサーバがイベントを受信すると、サーバはそのイベントを内部のメッセージキューイベントに変換する。メッセージキューアーキテクチャをサーバ上で用いることにより、システムイベントの受信をイベント処理から切り離すことができる。サーバ上の全てのモジュールは、ユーザ識別子、またはその他の方法のどちらかを用いて、メッセージキューを購読することができる。
【0029】
サーバは、記憶装置にイベントデータを書き込み、そのデータを分析し、かつ/または、そのイベントデータを公開することができる。サーバは、その後の分析のために、データを記憶装置に書き込むことができる。サーバは、イベント書き込みインターフェース302からデータストア・アダプタ304にイベント情報を送信することができる。そのようなイベント情報は、リアルタイムのイベントストリームを介して送信することができる、このリアルタイムのイベントストリームには、ユーザごとのリアルタイムのイベントストリームが含まれ得る。サーバは、データストア・アダプタ304を用いて、ローレベルのイベント履歴データベース306などのローレベルの記憶装置にイベントを記録することができる。ローレベルのイベント履歴データベース306は、例えば、ローレベルのイベント履歴情報を格納するNoSQLデータベースでよい。
【0030】
サーバ側分析ツール310には、イベントデータを分析するための機械学習モジュールが含まれ得る。サーバ側分析ツール310内の構成要素は、出版/購読イベントシステム308からのリアルタイムのデータ、またはローレベルのイベント履歴データベース306からの履歴データにアクセス可能である。一般には、このような構成要素は、リアルタイムでよりはむしろバッチモードで動作する。ある実装形態では、これらの構成要素は、ユーザモデルを最適化するために、低負荷期間中(例えば、夜間)に動作可能である。このシステムは、コンテキストグラフへ送信するために、処理出力をこれらの構成要素からイベント処理システムに転送し戻すことができる。このサーバはまた、サーバ側分析ツール310からローレベルのイベント履歴のデータベース306にこの出力を書き込むこともできる。
【0031】
図4でさらに詳しく説明する通り、このサーバはイベントデータを購読者に公開することもでき、イベントデータのうちのいくつかを用いて、コンテキストグラフを修正することもできる。このサーバは、複数の並列のキューを用いる出版/購読イベントシステム308を通してイベントを公開することができる。サーバ側分析ツール310は、ハイレベルのイベントストリームを用いて、イベントを出版/購読イベントシステム308に送信することができる。
【0032】
一実装形態では、このサーバはメッセージキュー機能に関して、RabbitMQを用いることができる。このサーバは、例えば、0MQまたはメッセージ・パッシング・インターフェース(MPI)に基づいたより大きなボリュームを送信するために高性能のイベント処理サブシステムを用いることもできる。0MQとは、拡張可能な分散型のアプリケーションまたは並列処理のアプリケーションで使用するための高性能の同期メッセージング・ライブラリである。MPIとは、移植可能な、標準のメッセージ・パッシング・システムであり、並列コンピュータ上で機能する。ある実装形態では、このシステムは埋め込みスタブを含み、この埋め込みスタブにより、分析用構成要素はアプリケーションから、出版/購読イベントシステム308にデータを書き込むことができ、このデータはコンテキストグラフに送信される。
【0033】
このサーバは、複数のクライアントからデータを受信し組合せてその大きな処理能力を利用することもできる。ある実施形態では、このサーバは、複数のクライアントから合計したデータを分析することができる。例えば、このサーバは、複数のクライアントのロケーションを含む同じロケーションのイベントを分析することができる。データをクライアントに送信し戻すため、サーバ側のアプリケーションは、ロングポールの持続性のあるプッシュ接続を用いてイベントをクライアントの出版/購読システム非同期的にプッシュすることができる。例えば、このサーバは、同じロケーションのイベント内に含まれるクライアントに通知をプッシュすることができる。なお、このシステムは、ロングポール接続を用いて、クライアントに推薦を配信することもできる。例えば、このシステムは、特別表示のメッセージとして推薦をイベント処理システムに注入することができ、このイベント処理システムが、ロングポールの接続を介して表示するために、そのメッセージをクライアントに送信することができる。なお、このシステムは、ロングポーリングに代り、従来のポーリングを使用することもできる。
【0034】
本発明の一実施形態では、スタブを含む機械学習コンポーネントを開発するためのフレームワークを含むこともでき、このスタブにより、格納されたベントデータへのアクセスおよびリアルタイムのイベントへのアクセス、およびイベントをシステムに書き込むための出版/購読イベントシステム308へのアクセスが提供される。機械学習モジュールはデータを駆動するアプローチを使用することができ、そこではそのデータのパラメータがデータベースに直列化可能である。
【0035】
一実施形態では、このシステムは、少ない数の関数呼び出しを用いるアプリケーション内で、機械学習の構成要素をインスタンス化する。このシステムは、データベースからのデータを用いて、好適な構成要素をインスタンス化することができる。次いで、このシステムは、その構成要素をイベント処理システムに接続し、特定のユーザに関してその構成要素を起動させることができる。ある実装形態では、ウェブベースのオーサリングシステムにより、そのような機能の設計およびプロビジョニングを容易にすることができる。
【0036】
図4には、実施形態による、イベント、マッパー、およびコンテキストグラフの間の関係を示すブロック図が示されている。このサーバの動作には、クライアントからイベントを受信し、イベントを購読者に公開することが含まれる。購読者のうちのいくつかは機械学習モジュールであり、その他には、マッパーおよび従属システムが含まれる。マッパーおよびRESTful WebAPIは、コンテキストグラフを修正し、従属システムは、コンテキストグラフの変更情報をリコメンダに供給する。リコメンダは、コンテキストグラフから受信したデータに基づいて、実装専用のユーザモデルを修正することができ、情報専用のユーザモデルに基づいて推薦を作成することができる。例えば、リコメンダは、ユーザモデルからのデータを用いて、推薦を判定するときのアイテムのスコアに影響を及ぼすことができる。
【0037】
図4に示される通り、動作中、イベント書き込みインターフェース302は、クライアントから受信したイベントを出版/購読イベントシステム308に送信する。出版/購読イベントシステム308は、いくつかのイベントを機械学習モジュール(1)402および機械学習モジュール(2)404などの機械学習モジュールに送信することができ、これらの機械学習モジュール(1)402および機械学習モジュール(2)404によりサーバ側の分析ツール310の一部が形成される。これらの機械学習モジュールにより、イベントに対する適切な応答を決定することができる。このシステムは、複数の異なる種類の機械学習モジュールを用いることができ、その中には、分類子、強化学習子、およびその他の多種多様な種類の機械学習モジュールが含まれる。このシステムは、ローレベルのイベント履歴からの履歴データを用いて、分類子を訓練することができる。この分類子は検知の構成要素を含むことができ、この検知の構成要素はイベントストリーム上でリアルタイムに、または格納された履歴内のデータ上で定期的に動作することができる。強化学習子は、イベントの監視を通して、携帯機器の状況の変更を監視し、適切な応答を学習することができる。
【0038】
一実施形態では、このシステムは、ユーザごとに状況データを格納することができる。各ユーザは、その現在の状態を記述したコンテキストグラフ406に関連する。コンテキストグラフ406は、ユーザごとの、インメモリのグラフベースのモデルであり、ユーザの行動および動作に関する事実およびアサーションを格納する。コンテキストグラフ406は、ユーザに関する情報のデータベースである。例えば、コンテキストグラフ406は、ユーザの個人的習慣に関するデータを含むことができる。そのようなデータには、ユーザは4時にコーヒーを飲む傾向があること、あるいはユーザは2時に仕事に出かける傾向があることが含まれ得る。
【0039】
コンテキストグラフ406は、一般化されたユーザモデルの記憶部として機能する。ユーザモデルには、ユーザに関して予想される現在の行動および将来の行動、並びに関心が記述される。このシステムは、タイプレスアプローチを用いて、コンテキストグラフ406内のデータをデータ記憶装置に格納することができる。コンテキストグラフ406には、異なるデータモデルに関するデータが格納され得、その異なるデータモデルには、実体関連データおよび非構造化データに関するデータモデルが含まれる。なお、コンテキストグラフをユーザ間で共有することもできる。ある実施形態では、このシステムは、クロス・モジュール・インターセクションを有する多数のノードを用いてコンテキストグラフを管理することができる。
【0040】
システムは、出版/購読イベントシステム308への購読を通してデータをコンテキストグラフ406に入力する。出版/購読イベントシステム308から情報を受信した後、マッパー314がコンテキストグラフ406を修正する。イベント情報をコンテキストグラフ406に送信する構成要素が特定なアプリケーションに関して特別に開発される。図2に関して説明した通り、クライアントは、RESTful WebAPI408を用いて、コンテキストグラフ406と直接、情報を送受信することができる。
【0041】
従属システム410は、リコメンダをコンテキストグラフ406に接続して、システムがコンテキストグラフの変更をリコメンダに通知できるようにする。コンテキストグラフ406内のデータを変更することにより、従属システム410を介して変更および警告が行われる。このような変更には、位相的な変更、および/または、コンテキストグラフ406内の対象(例えば、ノードおよびエッジ)に関する個々の特性の変更が含まれる。
【0042】
従属システム410は、コンテキストグラフ406からのデータをアプリケーション専用のユーザモデルに送信することができる。そのようなアプリケーション専用のユーザモデルは、規則ベースまたは混合モデルベースのリコメンダまたはその他の全ての種類のリコメンダ内で使用可能である。
【0043】
一実施形態では、従属システム410がグラフの変更を検知すると、この変更により、推薦できるアイテム、および/または行動、および/またはサービスに関するランキング、および/または、スコアをリコメンダが計算する。このリコメンダは、推薦を非同期的にクライアントにプッシュすることができる。
【0044】
コンテキストグラフ406内のデータを用いるリコメンダは、従属システム410を用いてグラフ修正のコールバックを登録することができる。コンテキストグラフ406内でグラフデータが変更されると、リコメンダは、グラフクエリーおよびアサーションと併せて、このコールバックを用いて、アプリケーション専用モデルの値を更新することができる。次いで、このリコメンダは、アプリケーション専用モデルの値に基づいて、推薦を生成、かつ/または、修正することできる。
【0045】
なお、コンテキストグラフ406内に格納されたデータおよび変更通知機構で、多くの推薦アプリケーションには十分であるが、混合モデル推薦システムなどの、より高性能なアプリケーションに対しては、コンテキストグラフ406からアプリケーション専用のユーザモデルに変更を伝えるためのインターフェースレイヤを加えることも可能である。さらに、このシステムにクエリー言語を加えて、リコメンダがこのクエリー言語を用いてコンテキストグラフに対するクエリーを出せるようすることができ、これにより、アプリケーション専用のユーザモデルの更新が容易になる。
【0046】
アプリケーション専用のユーザモデルを用いる、2つの例示的なプロトタイプのアプリケーションを下記に説明する。第1の例は、従属システム410を用いてルールを更新するルールベースの推薦エンジンである。第2の例は、コンテキストグラフ406を購読し、それらの出力を用いて変更をその変数に影響させる混合モデルのコンテンツ推薦システムである。さらに、推薦を組合せるためのモジュールを下記に提案する。
【0047】
一実施形態では、ルールベースの推薦エンジンを用いるシステムは従属システムを用いてルールの状態を更新することができ、これにより、推薦をクライアントにプッシュすることができる。コンテキストグラフが変更されることにより、ルールの状態が再評価される。ルールの状態が変更されると、推薦できるアイテムをこのルールと関連付けることにより、リコメンダは推薦を作成する。通常の場合、リコメンダがクライアントに推薦をプッシュする。より複雑なシステムは推薦に票を入れることができ、ランキングシステムを介してそれらの票が集められる。
【0048】
別の実施形態では、混合モデルのコンテンツ推薦システムが離散変数を用いて、ユーザの具体的な主題における関心を示し、コンテンツ種類を示す同様の変数を有するコンテンツのスコアを付ける、あるいはランキングを付ける。混合モデルシステムは、コンテキストグラフを購読し、それらの出力を用いてその変数の変更に影響させる。推薦できる各アイテムは、ベクトル空間内の複数の変数により特徴付けることができる。変数により、例えば、レストランの民族性を示され得る。コンテキストグラフの変更が行われると、推薦ベクトルの変数を有するモデルの要因に関する計算を行うことにより、リコメンダは推薦を算出する。次いで、リコメンダは、推薦できる各アイテムを数値スコアに割り当てる。
【0049】
本明細書に記載されるシステムは、組合せモジュールを含むことができ、この組合せモジュールにより、リコメンダからの出力が受け入れられ、それらの出力を組合せて推薦スコアが決定される。例えば、投票ベースのコンバイナはそれらが受けた投票の数により推薦にスコアを付ける。これは、複数のルールベースのリコメンダからの出力を組合せるのに適している。別の例として、コンバイナが複数の推薦スコアから最もよい推薦を選択して、出力の推薦スコアを決定することもできる。
【0050】
図5には、一実施形態による、クライアント上でイベントデータを集め、かつ公開する例示的なプロセスを示すフローチャートが示されている。動作中、最初にクライアントは、物理的状況データ、アプリケーションの状況データ、およびオペレーティングシステムの状況データを集める(動作502)。例えば、クライアントは、ロケーション、移動、および/または、携帯機器のコンパス計測値などの物理的環境の状況データを集めることができる。次いで、クライアントは状況データを格納し、(そうでない場合には、ローレベルのイベントデータとして、その状況データを処理し)、ハイレベルのイベントを生成する(動作 504)。例えば、このクライアントは、ユーザがウェブブラウザを用いていることを示すハイレベルのイベントを生成することができる。次いで、このクライアントは、イベントデータをクライアントおよびサーバ上で購読者に公開する(動作506)。クライアントは、イベント書き込みインターフェース302、および/または、RESTful WebAPI408を用いて、イベントデータをサーバに送信することができる。
【0051】
図6には、一実施形態による、サーバ上でのイベント処理の例示的なプロセスを示すフローチャートが示されている。動作中、サーバは、クライアントからイベントデータを受信する(動作602)。このサーバは、このイベントデータを処理のための待ち行列に入れることができる。次に、このサーバはイベントデータを格納し処理する(動作604)。リアルタイムでの分析、またはバッチモードでの分析のどちらかにより、このサーバはイベントデータを分析することができる。サーバは、出版/購読イベントシステムにイベントを公開することができる。さらに、このサーバは、同じロケーションのイベントを分析し、イベントをクライアントにプッシュすることができる。このサーバは、イベントデータを用いてコンテキストグラフ406を更新することができる(動作606)。サーバは、サーバの分析部からの出力を用いて、コンテキストグラフ406を修正可能である。従属システム410を用いることにより、このサーバは、コンテキストグラフ406のデータをリコメンダに送信することができる(動作608)。グラフが変更されると、このシステムは、新しいグラフデータを関連のあるリコメンダに送信することができる。次いで、リコメンダは、新しいグラフデータを用いて、推薦を作成することができる。
【0052】
図7には、本発明の一実施形態による、イベントデータを取り込むための例示的な携帯機器を示す図が示されている。一実施形態では、コンピュータおよび通信システム700は、プロセッサ702、メモリ704、随意的なディスプレイ705、および記憶装置706を含む。記憶装置706には、アプリケーション707および709などの複数のアプリケーションが格納されている。記憶装置706にはまた、プラットフォームAPI208、およびクライアント分析パッケージ216、データロガー210、および出版/購読システム218などのその他のアプリケーションも格納されている。動作中、これらのアプリケーションは記憶装置706からメモリ704に書き込まれ、プロセッサ702によりを実行される。プログラムが実行されている間、プロセッサ702は上述の機能を実行する。
【0053】
図8には、本発明の一実施形態による、イベントを処理するための例示的なサーバを示す図が示されている。一実施形態では、コンピュータおよび通信システム800は、プロセッサ802、メモリ804、および記憶装置806を含む。記憶装置806には、アプリケーション810および812などの複数のアプリケーションが格納されている。記憶装置806にはまた、機械学習モジュール402、マッパー314、従属システム410、コンテキストグラフ406、RESTful WebAPI408、およびリコメンダ824も格納されている。動作中、1つ以上のアプリケーションは、記憶装置806からメモリ804に書き込まれ、プロセッサ802によりを実行される。プログラムが実行されている間、プロセッサ802は上述の機能を実行する。コンピュータおよび通信システム800は、随意的なディスプレイ815、キーボード816、およびポインティングディバイス818に接続する。
図1
図2
図3
図4
図5
図6
図7
図8