JP6383170B2 - 一般化された状況判断知能プラットフォーム - Google Patents

Description

本開示は、一般に状況判断知能に関する。より具体的には、本開示は、携帯機器の状況情報を集め、専用アプリケーションを一般の状況判断知能システムに対して、効率的に適用し易くする方法およびシステムに関する。

本発明の一実施形態では、リコメンダにユーザの情報を供給するシステムが提供される。動作中、このシステムは、コンテキストグラフの変更の通知に関する登録をリコメンダから受信する。コンテキストグラフには、ユーザの行動、および／またはユーザの関心に関する情報が含まれる。次に、このシステムは、携帯機器の物理的環境を検知する検知器を用いて、集められた状況データから得られたイベントデータを携帯機器から受信する。システムは、イベントデータに基づいて、コンテキストグラフを修正する。次いで、このシステムは、コンテキストグラの修正が登録と一致しているかどうかを判定し、コンテキストグラフの変更の通知をリコメンダに送信する。

この実施形態の一変形例では、このシステムは、携帯機器から、アプリケーションのイベントデータ、および／またはオペレーティングシステムのイベントデータを含む付加的なイベントデータを受信する。次いで、このシステムは、この付加的なイベントデータに基づいて、コンテキストグラフを修正する。システムは、コンテキストグラの修正が登録と一致しているかどうかを判定し、コンテキストグラフの変更の通知をリコメンダに送信する。

この実施形態の一変形例では、このイベントデータには、状況データから携帯機器により生成されたハイレベルのイベントデータが含まれる。

この実施形態の一変形例では、このシステムは、コンテキストグラフのデータに関するクエリーをリコメンダから受信し、コンテキストグラフのデータをリコメンダに送信する。

この実施形態の一変形例では、このシステムは、ＲＥＳＴｆｕｌ ＷｅｂＡＰＩを通して、リアルタイムのイベントデータを受け取り、この受信したリアルタイムのイベントデータに基づいて、このコンテキストグラフのデータを修正する。

この実施形態の一変形例では、このシステムは、イベント書き込みインターフェースを通して、一括してアップロードされたイベントデータを受信し、この受信した、一括してアップロードされたイベントデータに基づいて、コンテキストグラフのデータを修正する。

図１は、一実施形態による、イベントデータをサーバに通信する携帯機器を示すブロック図である。 図２は、一実施形態による、クライアント側のアーキテクチャを示すブロック図である。 図３は、一実施形態による、クライアント側でイベントを処理する構成要素とサーバ側でイベントを処理する構成要素との関係を示すブロック図である。 図４は、一実施形態による、イベント、マッパー、およびコンテキストグラフの間の関係を示すブロック図である。 図５は、一実施形態による、クライアント上でイベントデータを集め、かつ公開する例示的なプロセスを示すフローチャートである。 図６は、一実施形態による、サーバ上でのイベント処理の例示的なプロセスを示すフローチャートである。 図７は、本発明の一実施形態による、イベントデータを取り込むための例示的な携帯機器を示す図である。 図８は、本発明の一実施形態による、イベントを処理するための例示的なサーバを示す図である。

図面において、同様の参照符号は同じ番号の要素を指す。

本発明の実施形態では、特別なアプリケーションに適する一般の状況判断知能プラットフォームを提供することにより、状況認識システムを効率的に開発するという課題を解決する。このような状況判断知能システムにより、状況情報のリアルタイム処理が容易になり、ウェブおよびモバイルのアプリケーションに関する状況アプリケーションの開発を容易にする。

一般の状況判断知能プラットフォームは、クライアント側のアーキテクチャと、サーバ側のアーキテクチャとを含む。クライアント側のアーキテクチャは、状況データを集め、処理した状況データをイベントデータとしてサーバ側のアーキテクチャに送信する。状況データには、物理的環境の状況、および／またはアプリケーションの状況、および／またはオペレーティングシステムの状況など、携帯機器のクライアントにより検知されたコンピュータの状況が記述されている。サーバ側のアーキテクチャは、状況データを格納しその状況データを用いて、ユーザの行動および関心のある情報が含まれているグラフを修正する。アプリケーションは、グラフからの情報を用いてアプリケーション専用のユーザモデルを修正し、推薦を生成することができる。

クライアント側のアーキテクチャは、物理的環境の状況、アプリケーションの状況、およびオペレーティングシステムの状況を含むコンピュータの状況を検知することにより、状況データを集め、分析し、集めたデータを記憶装置に書き込む。クライアント側のアーキテクチャは、ハードウェアの検知器を通して検知された、アプリケーションからの状況、またはオペレーティングシステムからの状況を処理し、この処理された状況データをローレベルのイベントデータとして格納する。ローレベルのイベントデータとは、状況から検知されたイベントのことを示し、クライアント側のアーキテクチャによって生成されるデータではない。例えば、ローレベルのイベントは、加速度計により感知された歩行パターン、アプリケーション内、またはスクリーンキャプチャ内のボタンの選択であり得る。クライアント側のアーキテクチャは、状況データを用いてハイレベルのイベントを生成し、そのハイレベルのイベントをサーバに送信することができる。ハイレベルのイベントは、例えば、ユーザが読むＥメールであり得る。クライアント側のアーキテクチャはまた、クライアント上で実行するアプリケーションにイベントデータを送信することもできる。

サーバ側のアーキテクチャは、イベント情報をクライアントから受信し、そのイベント情報を分析してコンテキストグラフを修正することができる。コンテキストグラフとは、ユーザの行動および関心に関する事実およびアサーションを格納するインメモリモデルである。サーバは、出版／購読イベントシステムを用いてリコメンダにイベントを送信することもできる。リコメンダとは、ユーザに関するアイテムまたは行動を推薦するアプリケーションである。これらのリコメンダは、コンテキストグラフから得られたユーザの情報を用いてアプリケーション専用のユーザモデルを維持する。イベントデータのイベントが特定のリコメンダからの購読要求と一致すると、サーバはそのイベントデータをリコメンダに送信する。次いで、これらのリコメンダは、そのユーザの情報を用いて自分のアプリケーション専用のユーザモデルを修正し、そのアプリケーション専用のユーザモデルに基づいて推薦を作る。

開示された一般的なインフラクチャを専用のニーズに適用させるために必要なことは、専用の行動検知モジュール、専用のユーザモデル、および／または専用のリコメンダを供給するだけである。このインフラクチャはモジュール構造として設計され、異なる機能が区分されており、互いに依存しない。それらの特定のアプリケーションに関して１つ以上のモジュールをカスタマイズすることができ、かつ／または初期設定のモジュールを用いることも可能である。エンジニアは一般のインフラクチャを適用し、それらのアプリケーション内に状況判断知能機能を組み込むことができ、状況認識機能を用いて、このアプリケーションを収益化することさえ可能である。一般のインフラクチャを適用することにより、専用の状況判断知能システムの開発において、かなりの時間と費用を節約することができる。

図１には、実施形態による、イベントデータをサーバに通信する携帯機器のブロック図が示されている。図１では、携帯機器１０２、１０４、および１０６が、ＧＰＳ、加速度計、および／またはコンパスなどの検知器を用いて状況データを集める。そのような状況データには、ユーザが、例えば、歩く、走る、または携帯機器上でアプリケーションを開くなどの特定の行動をしていることが示され得る。この状況データには、オペレーティングシステムのローレベルのイベントデータも含まれ得る。これらの携帯機器は、状況データを処理し、ローレベルのイベントデータとして格納することができる。携帯機器はまた、ユーザが文書を書いていることを示すデータなどのハイレベルのイベントデータを生成することもできる。携帯機器は、ネットワーク１１０を通して、イベントデータをサーバ１０８に送信することができる。ある実施形態では、携帯機器がハイレベルのイベントだけをサーバに送信することができる。

サーバ１０８は、受信したイベントデータを格納し分析し公開する。サーバ１０８は、イベントデータを用いてコンテキストグラフを修正可能である。コンテキストグラフ内に収められたユーザの情報を用いて、アプリケーション専用のユーザモデルを修正可能である。このようなアプリケーション専用のユーザモデルにより、リコメンダのアプリケーションの実装が容易になる。

図２には、一実施形態による、クライアント側のアーキテクチャのブロック図が示されている。クライアント側のアーキテクチャ２００には、様々な構成要素が含まれ、これらの構成要素により、物理的状況データおよびアプリケーションの状況データが集められ、次いでそれらのデータが処理されデータベースに記録される。これらの構成要素は、データを分析し、それらの分析されたデータに基づいて、ハイレベルのイベントが生成される。クライアント側のアーキテクチャ２００は、それらのイベントをイベントクライアント上のアプリケーション、およびサーバ上に公開する。

クライアント側のアーキテクチャ２００は、ＧＰＳ２０２、加速度計２０４、およびコンパス２０６などの物理検知器を含む。これらの物理検知器が、携帯機器の周囲の物理的状況を検知する。そして、システムは、物理検知器を用いるためのアブストラクションを供給し、このアブストラクションには、ラットフォームのアプリケーションプログラミングインターフェース（ＡＰＩ）２０８が含まれる。このプラットフォームＡＰＩ２０８は、装置との通信を容易にし、状況データに対する予備処理を行うことができる。次いで、プラットフォームＡＰＩ２０８は、その出力をデータロガー２１０およびクライアントの分析パッケージ２１６に送信する。クライアントの分析パッケージ２１６は、物理的データおよびアプリケーションデータを分析し、ハイレベルのイベントを生成してサーバに転送する。複数の分析用の構成要素がクライアント上で動作可能である。このシステムはまた、取り込まれたアプリケーションデータ２０９をデータロガー２１０に送信することも可能である。なお、取り込まれたアプリケーションデータ２０９には、アプリケーション内で起こったユーザイベントが含まれる。データロガー２１０は、データベースのアブストラクションレイヤ２１４を介して、物理的状況データおよび取り込まれたアプリケーションデータをプラットフォームのデータベース２１２に書き込むことができる。プラットフォームのデータベース２１２は、データの分析を容易にするために、履歴トレースを格納している。

このシステムは、複数の異なる技術を用いて、状況データを集めることができる。このシステムは、クライアントのアプリケーションの内部から、あるいは特別なデータロガーのアプリケーションを介して、状況データを得ることができる。例えば、このシステムは、直接アプリケーションから、埋め込みフックを介して状況データを集めることができる。また、このシステムはオペレーティングシステムを通して、例えば、スクリーンを取り込むこと、クリックイベントを検知すること、イベントログファイルを送信することにより、状況データを集めることもできる。さらに、このシステムは、状況データをＧＰＳ受信機、加速度計などの装置から集めることもできる。

クライアント側のアーキテクチャ２００は、集中型リスナーパターンを実装し、これにより、接続したアプリケーションは状況イベントを登録して、分析システムから受信することができる。複数のアプリケーションおよびモジュールが存在し得、これらのアプリケーションおよびモジュールが状況情報を登録し利用する。集中型リスナーパターンを用いることにより、クライアントは、集中型サーバシステムにイベントを、ローレベルの行動トレース、または分析システムにより生成されたハイレベルのイベントのどちらかとして送信可能である。

インメモリの出版／購読システム２１８は、集中型リスナーパターンを実装して、状況イベントをクライアントのアプリケーション、およびＨＴＴＰのサーバスタブ２２０に供給する。このクライアント側のアーキテクチャ２００により、アプリケーションを特定の種類イベントに関して登録することができる。例えば、位置固有のイベントに関与するアプリケーションを選択して、ＧＰＳのイベントに関して登録することができる。クライアント側の分析と関与の登録により、このインフラクチャは大きなボリュームのイベントを有するマルチユーザシステムの影響を削減することができ、それによりサーバがオーバロードする可能性を低くする。

一実施形態では、ＨＴＴＰのサーバスタブ２２０により、ハイレベルのイベントの遠隔サーバへの送信が容易になる。ＨＴＴＰのサーバスタブ２２０は、出版／購読システム２１８からイベントを受け取り、ＨＴＴＰを用いてイベントを遠隔サーバシステムに送信することができる（例えば、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）の形式で）。なお、このスタブを設定してイベントの送信をカスタマイズすることができる。ある実施形態では、このスタブは、出版／購読システムに登録されたイベント中継するだけである。

サーバ側の処理により、ソーシャルアプリケーション、すなわち単一のクライアント上で実行可能なデータ処理よりもハイレベルのデータ処理を必要とするアプリケーション、またはサーバ側が持続状態であることが必要なアプリケーションの実行が容易になる。サーバ側の処理を必要とするこれらのケースに関して、クライアントは、リアルタイムでアップロードにより、あるいは一括のアップロードにより、サーバにデータをアップロードすることができる。

連続してリアルタイムにイベントをアップロードするために、クライアントは、サーバベースのＲＥＳＴｆｕｌ ＷｅｂＡＰＩにＪＳＯＮメッセージを書き込むことができる。ＲＥＳＴｆｕｌ Ｗｅｂ ＡＰＩとは、ＨＴＴＰ、およびＲＥＳＴの原理を用いて、実施されるウェブ上のサービスである。ＲＥＳＴとは、ワールド・ワイド・ウェブなどの分散システムに関するソフトウェアアーキテクチャの方式である。クライアントは、そのデータが関連するユーザに関するユーザＩＤを用いてリアルタイムのイベントを認識することができる。リアルタイムでイベントをアップロードすることにより、クライアントは、リアルタイムのアプリケーションに関して、ユーザの状態を絶えず更新することができる。

一括したアップロードに関して、クライアントは、ＨＴＴＰ ＰＯＳＴを用いて、大きなデータファイルを（例えば、データベースから）アップロードすることができる。アプリケーション特定コードにより、このように一括してアップロードしたデータを処理してサーバ側のデータストアに格納可能である。なお、機械学習技術を用いて分析されることを意図した、スクリーンショットまたは大量のローレベルのログファイルなどの大きなブロックのデータに関して、クライアントは一括してアップロードを行うことが可能である。

図３には、一実施形態による、クライアント側でイベントを処理する構成要素とサーバ側でイベントを処理する構成要素との関係を示すブロック図が示されている。図３には、サーバ内のイベント処理システムが、携帯機器からイベントデータを受信し、その後、そのイベントデータを分析し格納する様子が示されている。また、この図には、サーバの構成要素が、出版／購読イベントシステムとやり取りを行い、この出版／購読イベントシステムが、イベントデータをコンテキストグラフに送信する様子も示されている。コンテキストグラフは、アプリケーション専用のユーザモデルに適用可能である一般のユーザモデル情報を格納する。このユーザモデル情報に関しては、図４を参照してさらに詳しく説明する。

図３では、図２に関して説明した通り、最初に携帯機器３００が、ＧＰＳ２０２およびコンパス２０６を用いて、物理的状況データを集め、ユーザのやり取り３０１を含むアプリケーションイベントを検知する。携帯機器３００は、状況データを分析、かつ／または、クライアント側の分析パッケージ２１６を用いてハイレベルのイベントを生成し、そのイベントをサーバに送信することができる。クライアントは、イベント書き込みインターフェース３０２、および／または、ＲＥＳＴｆｕｌ ＷｅｂＡＰＩ（図４を参照されたい）を介して、ハイレベルのイベントおよびローレベルのイベントの両方をサーバに送信することができる。

サーバ側のＲＥＳＴｆｕｌ ＷｅｂＡＰＩでサーバがイベントを受信すると、サーバはそのイベントを内部のメッセージキューイベントに変換する。メッセージキューアーキテクチャをサーバ上で用いることにより、システムイベントの受信をイベント処理から切り離すことができる。サーバ上の全てのモジュールは、ユーザ識別子、またはその他の方法のどちらかを用いて、メッセージキューを購読することができる。

サーバは、記憶装置にイベントデータを書き込み、そのデータを分析し、かつ／または、そのイベントデータを公開することができる。サーバは、その後の分析のために、データを記憶装置に書き込むことができる。サーバは、イベント書き込みインターフェース３０２からデータストア・アダプタ３０４にイベント情報を送信することができる。そのようなイベント情報は、リアルタイムのイベントストリームを介して送信することができる、このリアルタイムのイベントストリームには、ユーザごとのリアルタイムのイベントストリームが含まれ得る。サーバは、データストア・アダプタ３０４を用いて、ローレベルのイベント履歴データベース３０６などのローレベルの記憶装置にイベントを記録することができる。ローレベルのイベント履歴データベース３０６は、例えば、ローレベルのイベント履歴情報を格納するＮｏＳＱＬデータベースでよい。

サーバ側分析ツール３１０には、イベントデータを分析するための機械学習モジュールが含まれ得る。サーバ側分析ツール３１０内の構成要素は、出版／購読イベントシステム３０８からのリアルタイムのデータ、またはローレベルのイベント履歴データベース３０６からの履歴データにアクセス可能である。一般には、このような構成要素は、リアルタイムでよりはむしろバッチモードで動作する。ある実装形態では、これらの構成要素は、ユーザモデルを最適化するために、低負荷期間中（例えば、夜間）に動作可能である。このシステムは、コンテキストグラフへ送信するために、処理出力をこれらの構成要素からイベント処理システムに転送し戻すことができる。このサーバはまた、サーバ側分析ツール３１０からローレベルのイベント履歴のデータベース３０６にこの出力を書き込むこともできる。

図４でさらに詳しく説明する通り、このサーバはイベントデータを購読者に公開することもでき、イベントデータのうちのいくつかを用いて、コンテキストグラフを修正することもできる。このサーバは、複数の並列のキューを用いる出版／購読イベントシステム３０８を通してイベントを公開することができる。サーバ側分析ツール３１０は、ハイレベルのイベントストリームを用いて、イベントを出版／購読イベントシステム３０８に送信することができる。

一実装形態では、このサーバはメッセージキュー機能に関して、ＲａｂｂｉｔＭＱを用いることができる。このサーバは、例えば、０ＭＱまたはメッセージ・パッシング・インターフェース（ＭＰＩ）に基づいたより大きなボリュームを送信するために高性能のイベント処理サブシステムを用いることもできる。０ＭＱとは、拡張可能な分散型のアプリケーションまたは並列処理のアプリケーションで使用するための高性能の同期メッセージング・ライブラリである。ＭＰＩとは、移植可能な、標準のメッセージ・パッシング・システムであり、並列コンピュータ上で機能する。ある実装形態では、このシステムは埋め込みスタブを含み、この埋め込みスタブにより、分析用構成要素はアプリケーションから、出版／購読イベントシステム３０８にデータを書き込むことができ、このデータはコンテキストグラフに送信される。

このサーバは、複数のクライアントからデータを受信し組合せてその大きな処理能力を利用することもできる。ある実施形態では、このサーバは、複数のクライアントから合計したデータを分析することができる。例えば、このサーバは、複数のクライアントのロケーションを含む同じロケーションのイベントを分析することができる。データをクライアントに送信し戻すため、サーバ側のアプリケーションは、ロングポールの持続性のあるプッシュ接続を用いてイベントをクライアントの出版／購読システム非同期的にプッシュすることができる。例えば、このサーバは、同じロケーションのイベント内に含まれるクライアントに通知をプッシュすることができる。なお、このシステムは、ロングポール接続を用いて、クライアントに推薦を配信することもできる。例えば、このシステムは、特別表示のメッセージとして推薦をイベント処理システムに注入することができ、このイベント処理システムが、ロングポールの接続を介して表示するために、そのメッセージをクライアントに送信することができる。なお、このシステムは、ロングポーリングに代り、従来のポーリングを使用することもできる。

本発明の一実施形態では、スタブを含む機械学習コンポーネントを開発するためのフレームワークを含むこともでき、このスタブにより、格納されたベントデータへのアクセスおよびリアルタイムのイベントへのアクセス、およびイベントをシステムに書き込むための出版／購読イベントシステム３０８へのアクセスが提供される。機械学習モジュールはデータを駆動するアプローチを使用することができ、そこではそのデータのパラメータがデータベースに直列化可能である。

一実施形態では、このシステムは、少ない数の関数呼び出しを用いるアプリケーション内で、機械学習の構成要素をインスタンス化する。このシステムは、データベースからのデータを用いて、好適な構成要素をインスタンス化することができる。次いで、このシステムは、その構成要素をイベント処理システムに接続し、特定のユーザに関してその構成要素を起動させることができる。ある実装形態では、ウェブベースのオーサリングシステムにより、そのような機能の設計およびプロビジョニングを容易にすることができる。

図４には、実施形態による、イベント、マッパー、およびコンテキストグラフの間の関係を示すブロック図が示されている。このサーバの動作には、クライアントからイベントを受信し、イベントを購読者に公開することが含まれる。購読者のうちのいくつかは機械学習モジュールであり、その他には、マッパーおよび従属システムが含まれる。マッパーおよびＲＥＳＴｆｕｌ ＷｅｂＡＰＩは、コンテキストグラフを修正し、従属システムは、コンテキストグラフの変更情報をリコメンダに供給する。リコメンダは、コンテキストグラフから受信したデータに基づいて、実装専用のユーザモデルを修正することができ、情報専用のユーザモデルに基づいて推薦を作成することができる。例えば、リコメンダは、ユーザモデルからのデータを用いて、推薦を判定するときのアイテムのスコアに影響を及ぼすことができる。

図４に示される通り、動作中、イベント書き込みインターフェース３０２は、クライアントから受信したイベントを出版／購読イベントシステム３０８に送信する。出版／購読イベントシステム３０８は、いくつかのイベントを機械学習モジュール（１）４０２および機械学習モジュール（２）４０４などの機械学習モジュールに送信することができ、これらの機械学習モジュール（１）４０２および機械学習モジュール（２）４０４によりサーバ側の分析ツール３１０の一部が形成される。これらの機械学習モジュールにより、イベントに対する適切な応答を決定することができる。このシステムは、複数の異なる種類の機械学習モジュールを用いることができ、その中には、分類子、強化学習子、およびその他の多種多様な種類の機械学習モジュールが含まれる。このシステムは、ローレベルのイベント履歴からの履歴データを用いて、分類子を訓練することができる。この分類子は検知の構成要素を含むことができ、この検知の構成要素はイベントストリーム上でリアルタイムに、または格納された履歴内のデータ上で定期的に動作することができる。強化学習子は、イベントの監視を通して、携帯機器の状況の変更を監視し、適切な応答を学習することができる。

一実施形態では、このシステムは、ユーザごとに状況データを格納することができる。各ユーザは、その現在の状態を記述したコンテキストグラフ４０６に関連する。コンテキストグラフ４０６は、ユーザごとの、インメモリのグラフベースのモデルであり、ユーザの行動および動作に関する事実およびアサーションを格納する。コンテキストグラフ４０６は、ユーザに関する情報のデータベースである。例えば、コンテキストグラフ４０６は、ユーザの個人的習慣に関するデータを含むことができる。そのようなデータには、ユーザは４時にコーヒーを飲む傾向があること、あるいはユーザは２時に仕事に出かける傾向があることが含まれ得る。

コンテキストグラフ４０６は、一般化されたユーザモデルの記憶部として機能する。ユーザモデルには、ユーザに関して予想される現在の行動および将来の行動、並びに関心が記述される。このシステムは、タイプレスアプローチを用いて、コンテキストグラフ４０６内のデータをデータ記憶装置に格納することができる。コンテキストグラフ４０６には、異なるデータモデルに関するデータが格納され得、その異なるデータモデルには、実体関連データおよび非構造化データに関するデータモデルが含まれる。なお、コンテキストグラフをユーザ間で共有することもできる。ある実施形態では、このシステムは、クロス・モジュール・インターセクションを有する多数のノードを用いてコンテキストグラフを管理することができる。

システムは、出版／購読イベントシステム３０８への購読を通してデータをコンテキストグラフ４０６に入力する。出版／購読イベントシステム３０８から情報を受信した後、マッパー３１４がコンテキストグラフ４０６を修正する。イベント情報をコンテキストグラフ４０６に送信する構成要素が特定なアプリケーションに関して特別に開発される。図２に関して説明した通り、クライアントは、ＲＥＳＴｆｕｌ ＷｅｂＡＰＩ４０８を用いて、コンテキストグラフ４０６と直接、情報を送受信することができる。

従属システム４１０は、リコメンダをコンテキストグラフ４０６に接続して、システムがコンテキストグラフの変更をリコメンダに通知できるようにする。コンテキストグラフ４０６内のデータを変更することにより、従属システム４１０を介して変更および警告が行われる。このような変更には、位相的な変更、および／または、コンテキストグラフ４０６内の対象（例えば、ノードおよびエッジ）に関する個々の特性の変更が含まれる。

従属システム４１０は、コンテキストグラフ４０６からのデータをアプリケーション専用のユーザモデルに送信することができる。そのようなアプリケーション専用のユーザモデルは、規則ベースまたは混合モデルベースのリコメンダまたはその他の全ての種類のリコメンダ内で使用可能である。

一実施形態では、従属システム４１０がグラフの変更を検知すると、この変更により、推薦できるアイテム、および／または行動、および／またはサービスに関するランキング、および／または、スコアをリコメンダが計算する。このリコメンダは、推薦を非同期的にクライアントにプッシュすることができる。

コンテキストグラフ４０６内のデータを用いるリコメンダは、従属システム４１０を用いてグラフ修正のコールバックを登録することができる。コンテキストグラフ４０６内でグラフデータが変更されると、リコメンダは、グラフクエリーおよびアサーションと併せて、このコールバックを用いて、アプリケーション専用モデルの値を更新することができる。次いで、このリコメンダは、アプリケーション専用モデルの値に基づいて、推薦を生成、かつ／または、修正することできる。

なお、コンテキストグラフ４０６内に格納されたデータおよび変更通知機構で、多くの推薦アプリケーションには十分であるが、混合モデル推薦システムなどの、より高性能なアプリケーションに対しては、コンテキストグラフ４０６からアプリケーション専用のユーザモデルに変更を伝えるためのインターフェースレイヤを加えることも可能である。さらに、このシステムにクエリー言語を加えて、リコメンダがこのクエリー言語を用いてコンテキストグラフに対するクエリーを出せるようすることができ、これにより、アプリケーション専用のユーザモデルの更新が容易になる。

アプリケーション専用のユーザモデルを用いる、２つの例示的なプロトタイプのアプリケーションを下記に説明する。第１の例は、従属システム４１０を用いてルールを更新するルールベースの推薦エンジンである。第２の例は、コンテキストグラフ４０６を購読し、それらの出力を用いて変更をその変数に影響させる混合モデルのコンテンツ推薦システムである。さらに、推薦を組合せるためのモジュールを下記に提案する。

一実施形態では、ルールベースの推薦エンジンを用いるシステムは従属システムを用いてルールの状態を更新することができ、これにより、推薦をクライアントにプッシュすることができる。コンテキストグラフが変更されることにより、ルールの状態が再評価される。ルールの状態が変更されると、推薦できるアイテムをこのルールと関連付けることにより、リコメンダは推薦を作成する。通常の場合、リコメンダがクライアントに推薦をプッシュする。より複雑なシステムは推薦に票を入れることができ、ランキングシステムを介してそれらの票が集められる。

別の実施形態では、混合モデルのコンテンツ推薦システムが離散変数を用いて、ユーザの具体的な主題における関心を示し、コンテンツ種類を示す同様の変数を有するコンテンツのスコアを付ける、あるいはランキングを付ける。混合モデルシステムは、コンテキストグラフを購読し、それらの出力を用いてその変数の変更に影響させる。推薦できる各アイテムは、ベクトル空間内の複数の変数により特徴付けることができる。変数により、例えば、レストランの民族性を示され得る。コンテキストグラフの変更が行われると、推薦ベクトルの変数を有するモデルの要因に関する計算を行うことにより、リコメンダは推薦を算出する。次いで、リコメンダは、推薦できる各アイテムを数値スコアに割り当てる。

本明細書に記載されるシステムは、組合せモジュールを含むことができ、この組合せモジュールにより、リコメンダからの出力が受け入れられ、それらの出力を組合せて推薦スコアが決定される。例えば、投票ベースのコンバイナはそれらが受けた投票の数により推薦にスコアを付ける。これは、複数のルールベースのリコメンダからの出力を組合せるのに適している。別の例として、コンバイナが複数の推薦スコアから最もよい推薦を選択して、出力の推薦スコアを決定することもできる。

図５には、一実施形態による、クライアント上でイベントデータを集め、かつ公開する例示的なプロセスを示すフローチャートが示されている。動作中、最初にクライアントは、物理的状況データ、アプリケーションの状況データ、およびオペレーティングシステムの状況データを集める（動作５０２）。例えば、クライアントは、ロケーション、移動、および／または、携帯機器のコンパス計測値などの物理的環境の状況データを集めることができる。次いで、クライアントは状況データを格納し、（そうでない場合には、ローレベルのイベントデータとして、その状況データを処理し）、ハイレベルのイベントを生成する（動作 ５０４）。例えば、このクライアントは、ユーザがウェブブラウザを用いていることを示すハイレベルのイベントを生成することができる。次いで、このクライアントは、イベントデータをクライアントおよびサーバ上で購読者に公開する（動作５０６）。クライアントは、イベント書き込みインターフェース３０２、および／または、ＲＥＳＴｆｕｌ ＷｅｂＡＰＩ４０８を用いて、イベントデータをサーバに送信することができる。

図６には、一実施形態による、サーバ上でのイベント処理の例示的なプロセスを示すフローチャートが示されている。動作中、サーバは、クライアントからイベントデータを受信する（動作６０２）。このサーバは、このイベントデータを処理のための待ち行列に入れることができる。次に、このサーバはイベントデータを格納し処理する（動作６０４）。リアルタイムでの分析、またはバッチモードでの分析のどちらかにより、このサーバはイベントデータを分析することができる。サーバは、出版／購読イベントシステムにイベントを公開することができる。さらに、このサーバは、同じロケーションのイベントを分析し、イベントをクライアントにプッシュすることができる。このサーバは、イベントデータを用いてコンテキストグラフ４０６を更新することができる（動作６０６）。サーバは、サーバの分析部からの出力を用いて、コンテキストグラフ４０６を修正可能である。従属システム４１０を用いることにより、このサーバは、コンテキストグラフ４０６のデータをリコメンダに送信することができる（動作６０８）。グラフが変更されると、このシステムは、新しいグラフデータを関連のあるリコメンダに送信することができる。次いで、リコメンダは、新しいグラフデータを用いて、推薦を作成することができる。

図７には、本発明の一実施形態による、イベントデータを取り込むための例示的な携帯機器を示す図が示されている。一実施形態では、コンピュータおよび通信システム７００は、プロセッサ７０２、メモリ７０４、随意的なディスプレイ７０５、および記憶装置７０６を含む。記憶装置７０６には、アプリケーション７０７および７０９などの複数のアプリケーションが格納されている。記憶装置７０６にはまた、プラットフォームＡＰＩ２０８、およびクライアント分析パッケージ２１６、データロガー２１０、および出版／購読システム２１８などのその他のアプリケーションも格納されている。動作中、これらのアプリケーションは記憶装置７０６からメモリ７０４に書き込まれ、プロセッサ７０２によりを実行される。プログラムが実行されている間、プロセッサ７０２は上述の機能を実行する。

図８には、本発明の一実施形態による、イベントを処理するための例示的なサーバを示す図が示されている。一実施形態では、コンピュータおよび通信システム８００は、プロセッサ８０２、メモリ８０４、および記憶装置８０６を含む。記憶装置８０６には、アプリケーション８１０および８１２などの複数のアプリケーションが格納されている。記憶装置８０６にはまた、機械学習モジュール４０２、マッパー３１４、従属システム４１０、コンテキストグラフ４０６、ＲＥＳＴｆｕｌ ＷｅｂＡＰＩ４０８、およびリコメンダ８２４も格納されている。動作中、１つ以上のアプリケーションは、記憶装置８０６からメモリ８０４に書き込まれ、プロセッサ８０２によりを実行される。プログラムが実行されている間、プロセッサ８０２は上述の機能を実行する。コンピュータおよび通信システム８００は、随意的なディスプレイ８１５、キーボード８１６、およびポインティングディバイス８１８に接続する。

Claims (10)

1. ユーザの情報をリコメンダに供給する、サーバにより行われる、コンピュータで実行可能な方法であって、
   コンテキストグラフの変更の通知に関する登録を前記リコメンダから受信するステップであって、前記コンテキストグラフには、ユーザの行動、および／または、ユーザの関心に関する情報が含まれる、ステップと、
   携帯機器の物理的環境を検知する検知器を用いて集められた状況データから得られたイベントデータを前記携帯機器から受信するステップと、
   前記イベントデータに基づいて、前記コンテキストグラフを修正するステップと、
   前記コンテキストグラフの前記修正が、前記登録と一致するかどうかを判定するステップと、
   コンテキストグラフの変更の通知を前記リコメンダに送信するステップと、を含む方法。
2. アプリケーションのイベントデータ、および／または、オペレーティングシステムのイベントデータを含む付加的なイベントデータを前記携帯機器から受信するステップと、
   前記付加的なイベントデータに基づいて、前記コンテキストグラフを修正するステップと、
   前記コンテキストグラフの前記修正が、前記登録と一致するかどうかを判定するステップと、
   コンテキストグラフの変更の通知を前記リコメンダに送るステップと、をさらに含む請求項１に記載の方法。
3. 前記イベントデータには、前記携帯機器により状況データから生成されたハイレベルのイベントデータが含まれる、請求項１に記載の方法。
4. コンテキストグラフのデータに関するクエリーを前記リコメンダから受信するステップと、
   前記コンテキストグラフのデータを前記リコメンダに送るステップと、をさらに含む請求項１に記載の方法。
5. ＲＥＳＴｆｕｌ ＷｅｂＡＰＩを通して、リアルタイムのイベントデータを受信するステップと、
   前記受信したリアルタイムのイベントデータに基づいて、前記コンテキストグラフのデータを修正するステップと、をさらに含む請求項１に記載の方法。
6. 一括してアップロードされたイベントデータを、イベント書き込みインターフェースを通して受信するステップと、
   前記受信した一括してアップロードされたイベントデータに基づいて、前記コンテキストグラフのデータを修正するステップと、をさらに含む請求項１に記載の方法。
7. コンピュータが実行すると、前記コンピュータにユーザの情報をリコメンダに供給する方法を実行させる命令を格納する、コンピュータ可読記憶媒体であって、
   前記命令には、
   コンテキストグラフの変更の通知に関する登録を前記リコメンダから受信するステップであって、前記コンテキストグラフには、ユーザの行動、および／または、ユーザの関心に関する情報が含まれる、ステップと、
   携帯機器の物理的環境を検知する検知器を用いて集められた状況データから得られたイベントデータを前記携帯機器から受信するステップと、 前記イベントデータに基づいて、前記コンテキストグラフを修正するステップと、
   前記コンテキストグラフの前記修正が、前記登録と一致するかどうかを判定するステップと、
   コンテキストグラフの変更の通知を前記リコメンダに送るステップと、が含まれる、コンピュータ可読記憶媒体。
8. ユーザの情報をリコメンダに供給するコンピュータシステムであって
   １つ以上のプロセッサと、
   その中に格納された命令を有する、前記１つ以上のプロセッサに接続したコンピュータ可読媒体であって、前記命令を前記１つ以上のプロセッサが実行すると、前記１つ以上のプロセッサが、
   コンテキストグラフの変更の通知に関する登録を前記リコメンダから受信する動作であって、前記コンテキストグラフには、ユーザの行動、および／または、ユーザの関心に関する情報が含まれる、動作と、
   携帯機器の物理的環境を検知する検知器を用いて集められた状況データから得られたイベントデータを前記携帯機器から受信する動作と、
   前記イベントデータに基づいて、前記コンテキストグラフを修正する動作と、
   前記コンテキストグラフの前記修正が、前記登録と一致するかどうかを判定する動作と、
   コンテキストグラフの変更の通知を前記リコメンダに送る動作と、を行う、コンピュータ可読媒体と、を含むコンピュータシステム。
9. 前記コンピュータ可読媒体が付加的な命令を格納し、前記付加的な命令を実行すると前記コンピュータが、付加的なステップを行い、前記付加的なステップには、
   アプリケーションのイベントデータおよび／またはオペレーティングシステムのイベントデータを含む付加的なイベントデータを前記携帯機器から受信するステップと、
   前記付加的なイベントデータに基づいて、前記コンテキストグラフを修正するステップと、
   前記コンテキストグラフの前記修正が、前記登録と一致するかどうかを判定するステップと、
   コンテキストグラフの変更の通知を前記リコメンダに送るステップと、が含まれる、請求項８に記載のコンピュータシステム。
10. 前記イベントデータには、前記携帯機器により、状況データから生成されたハイレベルのイベントデータが含まれる、請求項８に記載のコンピュータシステム。

Images