JP2011517494A - 行動パターンを検出する方法及び装置 - Google Patents

Abstract

ユーザの歴史的行動（たとえば、習慣）及びこのような行動が表示される具体的な状況に応じてデバイスの特性を予測的に適合させるシステム、装置、技術、及び方法が開示される。このような状況は、曜日、時刻、季節、潮流、気温、天候、ユーザの心的状態、前日の特定スポーツ競技の得点、月の相、ユーザの場所など、実質的にあらゆるものが考えられる。ソフトウェアによる観察に基づいて、ユーザの習慣及びこれらの習慣が生じる状況が観察され、デバイスはユーザの行動パターン及びその状況に基づいてカスタマイズされる。

Description

本発明は、行動データマイニングのソフトウェア及び方法に関する。

人間は習慣の生き物である。したがって、多くの現代の電子デバイス及び他のデバイスは、デバイスの所有者によって適合可能又はカスタマイズ可能であるように設計されて、これらの習慣の受入れに適合しうるようにすることによってデバイスの使用が簡素化される。たとえば、多くの携帯電話及び家庭用電話では、ユーザが短縮ダイアル番号をそれらにプログラムすることができ、電話番号全体をダイアルしなくても１つのキー又はボタンを押すだけで特定の電話番号をダイアルすることができる。同様に、多くのコンピュータプログラムでは、ユーザは自分の個人的な好みに合わせて１つ以上のグラフィカル・ユーザ・インターフェースをカスタマイズすることができる。たとえば、Ｍｉｃｒｏｓｏｆｔ Ｗｏｒｄなどの多くのプログラムにおいて、よく使用されるツールや機能をツールバー上でよりアクセスしやすくするために、ユーザはツールバーをカスタマイズすることができ、一方で、頻繁に使用しないツール及び機能はドロップ・ダウン・メニューなどのアクセスしにくい手段に格下げされる。

一部の最新の電子デバイスは、自動的にユーザの好みを予測してこのような予測に基づいてユーザの経験をカスタマイズしようとさえもする。たとえば、現在入手可能なあるディジタルビデオ記録デバイス（ＤＶＲ）は、それらのユーザによって記録する選択されたプログラムを監視するように適合され、その情報を用いた予測アルゴリズムに基づいてそのＤＶＲのユーザが関心を寄せる可能性のある他のプログラムを予測する。こうして、特定の実施形態に基づいて、ＤＶＲは自動的にこのようなプログラムをそのＤＶＲに記録し、かつ／又はメッセージをＤＶＲに送ってユーザが関心を寄せる可能性のあるプログラムの次回の放送をユーザに知らせてユーザがこれを記録したいかどうかをユーザに尋ねてもよい。

少々類似した経験の別の例が、様々な商業ウェブサイトに見られる。特に、ユーザが電子商取引ウェブサイトから特定の製品を購入する場合（又は、ウェブサイトで特定の製品を見ることによってそれに関心を示すだけの場合）、多くのウェブサイトは独自のデータベースを検索して特定の製品と他の製品の相関を判断して、消費者に見られるように同じウェブページにこれらの他の製品を提示することになる。本技術の１つの具体的な一般の実施形態において、ウェブサイトは、そのデータベースのクエリを追跡することができ、現在のユーザによって現在見られている製品を購入した、過去の顧客によって一般に購入されている他の製品を判断してから、これらの他の製品に関心を寄せる可能性のある現在のユーザに推奨することができる。

ユーザの歴史的行動（たとえば、習慣）及びこのような行動が表示される具体的な状況に応じてデバイスの特性を予測的に適合させるシステム、装置、及び方法が開示される。このような状況は、曜日、時刻、季節、潮流、気温、天候、ユーザの心的状態、前日の特定スポーツ競技の得点、月の相、ユーザの場所など、実質的にあらゆるものが考えられる。ソフトウェアによる観察に基づいて、ユーザの習慣及びこれらの習慣が生じる状況が観察され、デバイスはユーザの行動パターン及びその状況に基づいてカスタマイズされる。

１つの具体的なネットワークベースの実施形態におけるシステムの様々な構成要素のブロック図である。 システムで使用されるデータ要素の一部及びそれらの相互関係のグラフィック表示である。 システムに関係して使用される一部の他の概念及びそれらの相互関係のグラフィック表示である。 一実施形態に従って状況情報の連続収集に関するクライアント側ソフトウェアの動作を示すフローチャートである。 一実施形態に従って行動のトリガーに応答して行動情報及び状況情報の収集に関するクライアント側ソフトウェアの動作を示すフローチャートである。 一実施形態に従ってクライアント側ソフトウェアから受信した行動及び状況の処理情報に関するサーバ側ソフトウェアの動作を示すフローチャートである。 一実施形態に従って行動のトリガーに関係しない行動情報の収集に関するクライアント側ソフトウェアの動作を示すフローチャートである。 一実施形態に従ってクライアント側ソフトウェアによって提供される行動情報の処理に関するサーバ側ソフトウェアの動作を示すフローチャートである。 一実施形態に従って行動モデルの生成に関するサーバ側ソフトウェアの動作を示すフローチャートである。 一実施形態に従ってサーバ側ソフトウェアに対する推論クエリの発生に関するクライアント側ソフトウェアの動作を示すフローチャートである。 一実施形態に従ってクライアント側ソフトウェアから受け取った推論クエリの処理に関するサーバ側ソフトウェアの動作を示すフローチャートである。

ユーザの歴史的行動（たとえば、習慣）及びこのような行動が表示される具体的な状況に応じてデバイスの特性を予測的に適合させるシステム、装置、及び方法が開示される。このような状況は、曜日、時刻、気温、天候、ユーザの心的状態、ユーザの場所、時節、前日のスポーツの試合の得点、潮流、月の相など、実質的にあらゆるものが考えられる。

実質的にいかなるタイプのデバイスも本開示で議論される原則に従って適合されうる。これは、ソフトウェアシステム、ネットワークソフトウェア、機械システム、及び生物系を含む。

多くの携帯電話では、所有者が短縮ダイアル番号又は「ホットキー」をプログラムすることなどによってユーザインターフェースをカスタマイズすることができる。しかし、ユーザはインターフェースを手動でカスタマイズしなければならない。さらに、このようなカスタマイズは、ユーザが後でこれを手動で再び変更するまでインターフェースは同じ状態のままであるという意味では永久的である。

本明細書において開示される技術、ソフトウェア、システム、方法、及び装置は、最先端技術に大きな進歩をもたらす。特に、本技術に従って、携帯電話などの民生用デバイスのユーザインターフェース及び／又はその他の操作パラメータは、デバイスの使用履歴に関する観察及びこのような使用の状況に基づいて自動的にカスタマイズされる。換言すると、本明細書で開示されるソフトウェアによる観察に基づいて、ユーザの習慣及びこれらの習慣が観察される状況が記録され、デバイスはユーザの行動パターン及びその状況に基づいて自動的にカスタマイズされる。

説明と明確さのために、詳しく説明する前に、本明細書に開示される原理、装置、技術、方法、及びシステムのきわめて特殊な適用例を考えてみよう。特に、携帯電話／携帯端末（以後、「無線ＰＤＡ」と呼ぶ）の組合せを考えてみよう。多くの人々は、時刻に応じて、無線ＰＤＡについて彼ら特有の使用パターンを有する。たとえば、典型的な事務職の男性は平日の午前１２時〜午前６時の時間帯では自分の電話を稀にしか使用しないかもしれない（たとえば、彼は睡眠中であるため）。さらに、彼は午前６時〜午前９時の時間帯では電話を比較的稀に使用するかもしれないが、これらの時間帯に電話を使用するときは、通常、前日夕刻のプロのスポーツ試合の得点のチェックし、当日のスケジュール表のチェックし、自分の妻に携帯電話をかけ、あるいはこれらの組合せを行なう。一方、午前９時〜午後５時の時間帯では、電話は稀にしか使用されない（たとえば、彼は勤務中であるため）が、使用されるときは、一般に財務計算器として使用される（たとえば、彼は経理担当者であるため）。最後に、午後５時〜午前零時の時間帯では、携帯電話は多くの異なる人々との通話に頻繁に使用される。

携帯電話及び無線ＰＤＡは、待ち受け画面、すなわち、電話がスリープモードから最初に呼び起こされるときに表示される画面を有する。単なる一例として、本明細書で議論される技術、システム、装置、及び方法は、状況に基づいて無線ＰＤＡに対するカスタマイズされた待ち受け画面を提示するために使用されうる。したがって、平日の午前零時〜午前６時の時間帯では、携帯電話の待ち受け画面は工場出荷時設定値のままであってもよい。しかし、平日の午前６時〜午前９時の時間帯では、待ち受け画面は、画面のほとんどを占有するユーザのスケジュール表（及び特に１日分の表示）を示すように再プログラムされてもよいが、自分の妻の携帯電話の短縮ダイアルボタン及び前日のスポーツの得点を提供するスポーツウェブサイトに１つのキーでアクセスするホットキーを示すように再プログラムされてもよい。

この後、平日の午前９時〜午後５時の時間帯では、待ち受け画面が平日のこれらの時間中にユーザの典型的な行動を反映した異なる表示を示すようにプログラムされうる。したがって、平日の午前９時〜午後５時の時間帯では、待ち受け画面は無線ＰＤＡの財務計算器機能を表示するようにプログラムされてもよい。

この後、さらに、午後５時〜午前零時では、待ち受け画面は、そのデバイスの使用に関する１日の時間中にユーザで観察される習慣に応じて異なるユーザインターフェースを表示するように再プログラムされてもよい。上記の例において、インターフェースは従来の電話インターフェースであってもよい。

前述のように、１日の各時間に観察される行動のみに基づいて携帯電話／無線ＰＤＡの待ち受け画面をカスタマイズする上記の例示的な実施形態は例示にすぎない。テクノロジーは、そのソフトウェアが容易にプラグインされて、プラットフォームやプロトコルとは関係なく実質的に他のすべてのソフトウェアと関連した使用に適するように計画される。

ネットワークデバイスと関連して使用されるように特に適合された一実施形態において、ソフトウェアのある一部分は個々のネットワーク・クライアント・デバイスに格納されるが、ソフトウェアの他の部分はネットワークデバイスのすべてにアクセスできるネットワーク上の独立したサーバノードに格納される。このような実施形態では、ネットワークデバイス内の処理負荷が最小化されてバッテリ寿命が維持され、さらに、ネットワーク上の多くのデバイスが、ソフトウェアのネットワークベースの部分を使用することができる。したがって、たとえば、上記の無線ＰＤＡの例では、ネットワークベースのソフトウェアは、数千の異なるネットワーク加入者の無線ＰＤＡの待ち受け画面をカスタマイズするのに役立つように使用されうる。さらに、数千のユーザからデータを収集することによって、カスタマイズルーチンが誰にとっても改善されうる。さらに、本明細書で議論されるシステムは、多くの場合、ユーザが自分でカスタマイズする場合よりも、よりよくカスタマイズすることができるものと想定される。特に、人々は自分自身のデバイスのフル機能に気付いていないことが多い。さらに、人々は自分自身の習慣に十分に気付いていないことすら多い。

関連性のあるシステム、技術、装置、及び方法を、たとえば、上記のような無線ＰＤＡの待ち受け画面をカスタマイズするために使用されうるネットワークベースの実施形態と関連させてここでさらに詳しく説明する。

本明細書で議論される機能は、相互運用ソフトウェア・サブシステム・データ型、インターフェース、及びサービスの収集によって実施されてもよく、これらは、これらによって蓄積されたデータセットでパターンをまとめ、分析し、公開する。これは、提供するネットワークサービスとしてネットワーク内で使用され、ネットワーク加入者の（１）発現行動及び（２）環境状況に関係する複数のソース（デバイス、オペレーティングシステム、ソフトウェアアプリケーション、地理位置情報サイト、ネットワークサービスなど）からデータを収集して蓄積するように構成されてもよい。すなわち、（１）加入者が何を行なったか、及び（２）加入者がどんな状況下でそれを行なったかである。

前記機能は、実際には、ソフトウェアとして実施されるが、ソフトウェアは、その行動が修正又は管理される必要のあるデバイス上で少なくとも部分的に実行される実行されることが好ましいが、必ずしもそうでなくてよい。このシステムは、追跡されるユーザ行動に応じたユーザの好みと、その行動が観察されてそれに応じてデバイスの管理を手助けする状況を決定するソフトウェアエンジン（以下では、エンジンと呼ぶこともある）である。ソフトウェアエンジンは、デバイスの使用とこのような使用の状況とに関するデータを収集して処理し、加入者行動の数学モデルを特定の状況に関連するものとして生成する。このモデルは、この後、行動パターンに関して分析され、その分析結果は複数のソフトウェアインターフェースを介してクエリされる。ソフトウェアエンジン内部の他のソフトウェアインターフェースは、これらのクエリの結果を、このような情報を使用してこれらの行動パターンに応じてデバイスをカスタマイズできる、別のソフトウェアプログラムに提供してもよい。

ソフトウェアエンジンは、加入者に関する予測行動情報をその加入者のデバイス（複数も可）（たとえば、携帯電話又は無線ＰＤＡ）に提供する。この後、デバイス内のソフトウェアは、この情報によってデバイス自身を修正する権限が与えられて、デバイスを加入者にとってより「洗練された」もの、あるいはより有用なものにする。携帯電話の場合、電話のオペレーティングシステムは、月の第３週の火曜日に自動的に通話（もしかすると、実際に通話を開始するためにはユーザが「送信」キーを押すだけでよい程度にまで）を開始するように選定してもよいが、ニューヨークからフィラデルフィア行きの列車に乗っているとき、（１）受話器が取り上げられたことを検出していることと、（２）月の第３週の火曜日に自分のラップトップを閉じた後加入者が常に同じ番号を呼び出すソフトウェアエンジンによって知らされていることに応答する電話はニューヨークからフィラデルフィア行きの列車上にある。この種のデバイスは、人間の行動を予想するので「予想デバイス（anticipating device）」呼ばれる。この構成におけるシステムの適用は、デスクトップ・オペレーティング・システム、スタンドアロン・ソフトウェア・アプリケーション、社会的ネットワークなどに拡張されうる。

前述の内容に加えて、本発明によるソフトウェアは、「標準」規則エンジン及び／又はソフトウェア・エージェント・インターフェースを用いて増強され、指定された状況内での加入者行動パターンの出現の結果として、一連の「ネットワーク動作」（ウェブページの検索、料金の支払い、又はＨＤＴＶのチャネル変更）を開始するために使用されうる。

本明細書の残りの部分では、ソフトウェアエンジンの外部にあるが、ホストシステムとしてソフトウェアエンジンの影響を受ける任意のデバイス、オペレーティングシステム、ソフトウェアアプリケーション、社会的ネットワークなどに言及する。さらに、以下を正式に定義する。
１つ又は複数の行動ファクターによって電子的に捕捉されうる加入者によって明示される行動又は活動としての「発現行動」。たとえば、電子メールをチェックするための加入者による携帯電話の使用は、電子的手段、行動ファクターとしてメールサーバにネットワークトラフィックの適切な部分を格納することによって捕捉されうる。これを実施しようとする加入者の意図又は目的は、少なくとも本技術手段なしでは捕捉されえない。
加入者が行動を発現する可能性のある状況としての「環境状況」。状況は、領域が状況ファクターによる電子監視及びデータ収集に役立つ限り、地理空間的領域、時間的領域、情意的領域などの領域を包含しうる。

この議論の中心に、人間は習慣の生き物であるという仮定があることを、ここで述べておくべきである。これらの行動は、往々にして不規則に現われるが、実際には、多数の変数に支配される「規則性」を有する一連の動作であり、多数の変数は捕捉されて分析されうる。その分析へのアプローチは、機械学習アルゴリズムを利用する知識管理（ＫＭ）で行なわれる作業の一部にその基礎を有する。このアプローチはここで利用されてもよい。結果として、本明細書で議論されるシステム、技術、装置、及び方法の背景にある数学の一部は、当業者によってよく理解されるであろう。しかし、人間行動を予測する問題にこれらを適用することはありえないであろう。

システムの構成要素を加入者の発現行動を処理するものとし、自分の環境状況を自分の生活に関する「教科書」であると考えることは有用であるかもしれない。「戦争と平和」の教科書が機械学習法（又はさらに、グーグルのページランクなど、より新しいアルゴリズムによって）を用いてＫＭシステムによって主題パターンに関して分析されうるのと同様に、これらの人生教科書（life text）も分析されうる。また、Ａｍａｚｏｎ．ｃｏｍがかつて様々な書籍でテキストマイニング分析の結果を採用して、これらの書籍に関する検索可能な「タグクラウド」を生成したように、システムによって生成される分析の結果は有効に利用されうる。

とは言うものの、本明細書の残りの部分では、本明細書に開示される技術の例示的な構成要素及びその相互運用を説明する。
ここで、図１を参照してシステムをネットワークベースの実施形態で説明する。

１．クライアント及びサーバ
図１は、任意数のクライアントデバイス１０１ａ〜１０１ｄ及びサーバノード１０２ａ〜１０２ｄをサポートするインターネット又は携帯電話ネットワークなどのネットワーク１００を示す。クライアンドデバイスの中には、クライアントデバイス１０１ｄなど、本開示に従って構成されたクライアントデバイスがある。また、サーバノードの１つ、たとえば、サーバノード１０２ｄは、やはり、本開示に従って構成され、本開示において議論される機能を実施するためにクライアント側ソフトウェアと連携して働くように設計されたソフトウェアを具体化する。

一般に、ネットワークベースの実施形態を考えるための１つの方法は、クライアント−サーバの組合せとするものであり、この場合、クライアント側コード１０４は加入者のクライアントデバイス１０１ｄの中に組み込まれ、サーバ側コードはネットワークのどこかにあってサーバノード１０２ｄに存在し、クライアントデバイス１０１ｄによって何らかの方法でネットワーク１００を通じてアクセスされる。システムのこの分割は、サーバとクライアントが分離された状態にある必要がないので、純粋に便宜上のものである。しかし、これは、この構成によって単一サーバ１０２ｄに複数のクライアント１０１を管理させ、ネットワーク効果（新たなクライアント又はサーバをネットワークに加えることによってそのネットワーク上のクライアント及びサーバのすべてに便益をもたらす現象）によって加入者の経験全体をよりよいものにする場合である。さらに直接的には、本開示に従って構成される単一サーバは、複数のクライアントからの行動データ及び状況データをアルゴリズムによって活用して、各クライアントに対する推測をより正確なものにすることができることになる。実際には、各クライアントは、１つの新たなクライアントを追加し、その結果として行動データ及び状況データを追加することによってより「高性能な」ものになる。

クライアント側ソフトウェア１０４は、加入者の発現行動及び環境状況を監視し、これを捕捉し、これをサーバ１０２ｄに送信することに関与する。さらに、クライアントソフトウェア１０４は、加入者に起こりそうな行動を示す、サーバ側コードによって生成される数学モデルをクエリするために、加入者のホストシステム１１２によって使用されるエージェントである。

一方、サーバ側ソフトウェアは、捕捉された行動及び状況を収集して、数学的意味（すなわち、モデル）を有する形態に処理し、その処理されたデータに関する分析を開始し、クライアントからクエリを受け入れ、結果を返すことに関与する。ここで、クライアント及びサーバを構成するサブシステムのさらに詳細な議論に移る。

Ａ．クライアント
クライアント側ソフトウェア１０４は、６つの主要な構成要素に分解される。すなわち、
１．行動リスナー１０６
２．状況リスナー１０７
３．レバー１０８
４．行動サービス１０９
５．状況サービス１１０
６．推測サービス１１１
である。

本発明者らの議論は、これらの構成要素のすべてはコード１０４の単一収集の一部であり、クライアントデバイス１０１ｄ内に常駐するものと仮定しているが、互いにアクセス可能であることを必要とするすべての構成要素が本当にアクセス可能である限り、このような仮定は必要でない。

１．リスナー及びレバー
行動リスナー１０６、状況リスナー１０７、及びレバー１０８の構成要素は、加入者のホストシステム１１２に対するコードの最も侵襲的な部分であり、したがって、これらの各々の要素は実施ごとに非常に大きく変化を受ける可能性がある。状況リスナーの詳細な議論は後にゆずるものとするが、他の構成要素はここで議論するものとする。

ａ．行動リスナー
行動リスナー１０６のジョブは、加入者の行動を監視して１つ以上の行動ファクターを有するその行動を体系化する手段を確立することである。（行動ファクターは行動サービスの議論の一部として後で議論される。）行動リスナーの活動は、行動リスナー１０６が影響を与えるホストシステム１１２の部分と一致する枠組み内で達成されるべきである。

一実施において、行動リスナー１０６は、ほとんど常に待ち受け状態又は休止状態にあるホストシステム内のスレッドとして設計されてもよい。加入者によって実行される活動、すなわち、トリガー事象（そして、通常、これはホストのソースコードにある種の１行トリガーを入力することによって達成される）によって呼び起こされるとき、行動リスナースレッドは活動に関係する適切な活動情報（すなわち、活動のインスタンス）とともに有効な状況（状況サービス１１０によって提供される）を素早く獲得し、このデータ（未加工行動−状況デュプレと呼ばれ、これは後で説明される）を含むオブジェクトを行動サービス１０９内の待ち行列に入れる。一般に、行動リスナー１０６は、ホストシステム内でできる限り少ない資源で済み、できる限り素早くかつ効率的に実行するように設計される。

例として、本開示に従ってウェブログ、すなわち、「ブログ」で実行される簡単な活動を考えてみよう。ブロガーがポスト又はブログ用のメッセージを生成すると、すぐにＨＴＴＰ−ＰＯＳＴがブログサーバをヒットし、ブログサーバに埋め込まれた行動リスナー１０６が呼び起こされることになる。この後、行動リスナー１０６はブログポストの本文のテキストを行動ファクターとして関連するメタデータとともに捕捉し、次いで環境状況を取得する。このデータを取り込んだリスナーは、このデータを含む新たな未加工行動−状況デュプレを生成してこれを行動サービスに入れることになる。行動リスナーは、通常はブログポストがブログサーバに現われるときに開始される活動と並列にこれらの機能を実行することになる。

ｂ．レバー
レバー１０８は、これに対するコードがサーバ側構成要素から返されるデータの使用目的に応じて大幅に変るので、明確に定義することが少々困難である。クライアントデバイスにはレバーがいくつあってもよい。一言で言えば、レバーは、加入者に将来起こりそうな行動に関する情報を、サーバ側構成要素からクライアントデバイスに捕捉せしめると同時に、その情報が決定されるプロセスを取り除くアプリケーション、エージェント、又はソフトウェアである。このように、ホストシステムの設計者は、ソフトウェアがその便益を生かすためにどのように働くかについては何も知る必要がない。いくつか例を挙げると言わんとする内容が分かるであろう。

前述のダイナミックな待ち受け画面の実施において、レバー１０８は、携帯電話の最初の画面、すなわち、「待ち受け画面」（携帯業界用語）に対するコードの画面ペインティング部分を制御するソフトウェアである。この待ち受け画面レバーは、クライアント側推論サービス１１１と連携して働いてクライアントデバイス１０１ｄに推論クエリと呼ばれるオブジェクトを生成させて、これをサーバ１０２ｄのサーバ側構成要素に送ることができる。推論クエリの特異性は、推論サービス１１１の議論に関連して以下で議論される。しかし、この議論では、加入者の将来起こしそうな行動に関する情報の明確な要求を含むオブジェクトとしてこれを記述すれば十分であろう。

その推論クエリに対する応答は、エンジンのサーバ側構成要素によって返されるとき、加入者の現在の状況（たとえば、日付、時間、場所など）に適切なすべての行動のリスト（たとえば、呼び出されそうな電話番号、送られるＳＭＳメッセージ、及び呼び出されるアプリケーション）を含むであろう。待ち受け画面内のレバー１０８は、この後、このデータを表示するように待ち受け画面を設定し、加入者がその状況で自分にとって最も重要な人々、メッセージ、及びアプリケーションにワンクリックでアクセスできるようにする。したがって、待ち受け画面レバー１０８は、加入者が共通の窓口を探すために、若しくはメッセージアプリケーションを開いてメッセージにたどり着くためのアドレス帳の検索を最小限に留めるか、又はアドレス帳の検索をしなくて済むようにする。待ち受け画面レバー１０８は、待ち受け画面を「ダイナミック」にしてそのダイナミズムの達成方法を隠すことによって上記の内容を実現する。

第２の例示的なレバー実施において、ＲＳＳフィードは、加入者が所与の時点において得ることを最も望みそうなＵＲＬの状況に敏感なリストを提供するように制御される。この例において、レバーは、インターネットサーバで書き込まれ実行されるウェブサービスである。ブラウザーがＲＳＳフィードＵＲＬをヒットすると、このウェブ・サービス・レバーは、推論クエリを生成してこれをサーバ側構成要素に送る。応答が返されると、レバーはこれを適切なＸＭＬ形式に置き換えて結果をブラウザーに返す。

上記の２つの例において、ホストシステム１１２（携帯電話オペレーティングシステム及びブラウザー）は、そのデータを利用するためにエンジンソフトウェアの動作の形式又は明細に関して何も知る必要はない。たとえて言うと、クライアントデバイスは、レバー１０８を用いて「加入者は現時点で何に関心があるか？」と質問して回答を得る。

２．行動サービス（クライアント側）
行動サービス１０９は、クライアントデバイス及びホストシステム１１２とのインターフェース内に存在する必要性があるため、多くの非常に異なる実施を有する可能性がある。しかし、一般に、ホストシステム１１２からの行動データ及び状況データの捕捉を監視して、これをサーバ１０２ｄにおけるサーバ側構成要素に向けるように設計されるのは、スタンドアロンコード（アプリケーション、サービス、スレッド、又はプロセス）である。結果として、これは、ホストシステムの通常のプロセスから独立して存在し、ソフトウェアのサーバ側構成要素が常駐する同じネットワークにアクセスすることができる。

起動時、行動サービス１０９は、１つ又は複数の行動リスナー１０６を起動し、行動リスナー１０６は行動が捕捉されるホストシステム１１２の各部と情報をやり取りする。また、行動サービス１０９は、収集された行動をサービス１０９がエンジンのサーバ側構成要素に発送又は「公開」する頻度を設定するタイマーを起動する。この後、サービスは、１つ又は複数の行動リスナー１０６又はタイマーによって呼び起こされるまで待ち受け状態にある。行動リスナー１０６によって呼び起こされるときは、行動リスナー１０６は、一般に、行動リスナーが未加工行動−状況デュプレで加入者行動を捕捉していることを示しており、サービス１０９はデュプレを受け入れてこれを内部の待ち行列に加える。タイマーによって呼び起こされるときは、行動サービスは待ち行列に入れられた未加工行動−状況デュプレを一括してこれらをエンジンのサーバ側構成要素に公開する。

これまで、未加工行動−状況デュプレは、行動リスナーによって生成されているものとして議論されてきた。しかし、これは必ずしもそうとは限らない。エンジンのクライアント側コードの一部の実施において、行動リスナーは行動サービスに渡される未加工行動を生成するだけで、行動サービスは、この後、状況サービスから適切な状況を収集しデュプレを生成することに関与する。この活動は、捕捉されるデータの精度を維持するために、時間的にも場所的にも未加工行動のできる限り近くで起こることになる。同様に、行動サービス１０９の一部の実施は、行動リスナー１０６をトリガーのみとして用いて、未加工行動−状況デュプレを生成し待ち行列に入れるタスクのすべてを実行してもよい。未加工行動、状況、及び未加工行動−状況デュプレオブジェクトは、行動サービスのメカニズムの公開に関する議論の後、以下でさらに詳しく議論される。

前記エンジンは様々な種類のホストシステム及びネットワークに適用される可能性があるため、行動サービスの公開インターフェースは高度に柔軟に設計される。行動サービスの公開インターフェースは、エンジンのサーバ側構成要素とプッシュ及びプルの両モードでやり取りするように作られている。プッシュの実施において、クライアントはやり取りを開始し、データはＨＴＴＰ−ＰＯＳＴのようなメカニズムによって提供される。この場合、クライアントがデータをサーバにプッシュする。プルの実施において、クライアント側行動サービス１０９は、エンジンのサーバ側構成要素でのやり取りの開始を可能にするウェブサービスのようなメカニズムで実施される。この場合、サーバがデータをクライアントからプルする。

３．状況サービス（クライアント側）
行動サービスと同じ理由で、クライアント側状況サービスは、複数の異なる実施を有する。また、クライアント側状況サービスは、ホストシステムの通常のプロセスから独立して存在するスタンドアロンコード（アプリケーション、サービス、スレッド、又はプロセス）となる傾向がある。エンジンのサーバ側構成要素が常駐するネットワークと同じネットワークにアクセスできることは必ずしも必要でない。これら２つのネットワークの間には情報のやり取りがないからである。しかし、エンジンにおけるその他すべてと同様に、柔軟性が望まれる。

状況サービス１１０の主要な機能は、環境状況の電子的表現を確立してその表現をソフトウェアオブジェクト、すなわち、状況情報のインスタンスを表わす状況オブジェクトに取り込むことである。行動サービス１０９と同様に、状況サービス１１０は、ほとんど常に待ち受け状態又は休止状態にあり、他のサービスに費やされてための、そのオブジェクトを公開する。この場合、オブジェクトの消費は、行動リスナー１０６、レバー１０８、クライアント側行動サービス１０９、及び推論サービス１１１、ならびに状況オブジェクトに含まれる情報を利用したい場合のホストシステム１１２内の他のサービスによる。また、公開は、プッシュとプルの両モードを包含する。

ａ．状況リスナー及び状況サービス（クライアント側）
起動時、状況サービス１１０は、マスター状況オブジェクト、及び監視される各状況ファクターに対して１つの、１つ又は複数の状況リスナー１０７を生成する。状況ファクターは以下でさらに詳しく議論される。状況リスナー１０７の設計は、費やすホストシステム資源が少ないという点において行動リスナー１０６の設計によく似ており、ほとんど常に待ち受け状態又は休止状態にあり、待ち受け状態の状況サービス１１０を呼び起こすことに関与する。しかし、状況リスナーは、未加工行動を生成せず、代わりに、観察下にある状況ファクターに関する現在値を状況サービス１１０aに供給する。

例として、無線ＰＤＡ１０１ｃ上の状況リスナー１０７は、その無線ＰＤＡが基地局を通過するとき状況サービス１１０を呼び起こすように設計されうる。この場合、対象とする状況ファクターは携帯電話位置の局番及び基地局ＩＤとなる。これら２つのファクターのいずれかが変化すると、状況リスナー１０７は必ず状況サービス１１０を呼び起こし、これらのファクターに関する最新の値を状況サービス１１０に提供する。

状況ファクターの変化を受信すると、状況サービス１１０はマスター状況オブジェクトを更新して休止状態に戻る。しかし、マスター状況オブジェクト内に状況データが必要であることを別のサービスが状況サービスに警告すると、状況サービスはマスター状況オブジェクトのコピーを作成しこれを要求サービスに提供する。これはプルモデルである。また、状況サービスは、要求がなくても定期的に他のサービスに情報を提供してもよい。これはプッシュモデルである。

４．未加工行動、状況、及び未加工行動−状況デュプレ
ここで、引き続き推論サービス１１１を議論する前に、前述のシステムに使用される様々なデータ型を議論しよう。

ａ．未加工行動
未加工行動は、例示的な一実施において、行動リスナー１０６によって捕捉されている行動ファクターに適した具体的な未加工行動オブジェクトを生成するために副分類されるスーパークラス（オブジェクト指向プログラミング用語における）である。副分類された未加工行動は、ホストシステムの要求に応じてさらに副分類されうる。一般に、各行動リスナー１０６は、未加工行動オブジェクトの１つの型のみに基づいて動作するが、これを必要とする設計に制限はない。所与のホストシステム及び所与の１組の行動ファクターに対して、数多くの異なる型の未加工行動オブジェクトが要求されてもよい。現在又は計画中の未加工行動型の未完成リストは以下の通りである。
携帯電話発信（ＭＯ）音声及び携帯電話着信（ＭＴ）音声ならびにデータコールの捕捉用
ＭＯ及びＭＴテキストならびに２進メッセージ（ＳＭＳ及びＭＭＳ）の捕捉用
電子メール（受信及び送信）の捕捉用
メモ、リマインダー、タスクリストの捕捉用
ウェブログポストの捕捉用
ＵＲＬに掲示されて強調されたテキストの捕捉用
クリックストリーム（ウェブブラウザーからアクセスされるＵＲＬ）の捕捉用
メッセージ及びチャットを伝えるインスタントの捕捉用
チャットログの捕捉用
ウェブベースの音楽プレイヤーを含む音楽ソフトによって使用される音楽の捕捉用
ＰＩＭ機能（予定表、アドレス帳、アラームなど）の捕捉用
システムアクセス（ファイルを開く＆閉じるなど）の捕捉用
メディア捕捉及び使用（ビデオ、静止画像、アップロード及びダウンロード）の捕捉用
ゲーム活動の捕捉用
マップサービス利用の捕捉用
システム保守活動（バックアップ、同期（synching）、パスワード変更）の捕捉用
探索文字列の捕捉用
各未加工行動は、１つ又は複数の情報フィールド（行動ファクター）及びメタデータを含む。加入者行動の一部として捕捉されるフィールドの一部は、以下を含んでいてもよい。
１．加入者のＩＤ
２．加入者発信又は加入者着信の活動
３．発現行動の経過時間
４．ホストシステム名（パンドラ、ｉＴｕｎｅｓ、サファリ、ファイヤーフォックス、電子メール、文書）
５．発現行動内の活動の内部状態
ａ．音声電話に関して、これは、リンギング、通話保留、不在着信などであってもよい
ｂ．メッセージングに関して、これは、生成、読取り、削除、受信、保存であってもよい
６．文書又はソングトラックに関して
ａ．タイトル及び著者又はアーティスト
ｂ．長さ及び寸法
ｃ．カテゴリ又はジャンル
ｄ．収集名（書名又はアルバム）
ｅ．ＵＲＩ、必要に応じて
７．行動に関連する人（加入者でない）（発信元、送信先、会員名簿など）
８．関係者（加入者でない）の電話番号又は加入者ＩＤ
９．メッセージ、ポスト、メモ、ウェブログポストなどに関して
ａ．収集名（ブログタイトルなど）
ｂ．主題又はタイトル
ｃ．加入者定義のカテゴリ又はタグ
ｄ．メッセージ本文のテキスト
ｅ．メッセージの参考資料又は強調部分
ｆ．ＵＲＩ、必要に応じて
１０．行動（ビデオファイル、歌曲など）に関連するファイル名及びファイル型（ＭＩＭＥ型）
未加工行動の存在は、加入者の側の行動が発現されていることをエンジンに示す。しかし、消極的な行動（エンジンによって予測されたときに現われなかった行動）も電子的に生成され捕捉されうる。

さらに、行動リスナーによる行動情報の捕捉に関しては時間的限界がない。すなわち、ユーザによって示される行動は、設計上、エンジンによって捕捉されて使用される対応行動ファクターに関して実際に「既に起きている」必要性はない。たとえば、加入者が自分の無線ＰＤＡに翌日の会議の予定表イベントを入力している場合を考えてみよう。本発明の一実施形態において、この予定表イベントの入力は、予定表記入を生成する動作に対するトリガーと、翌日の会議に出席しているという、まだ行なわれていない動作に対する第２のトリガーとの２つの行動トリガーを生成することになる。

両方の行動は、これらの行動に関連する適切な行動ファクターを有しており、無線ＰＤＡへの予定表作成アプリケーションの関連する行動リスナーから行動−状況デュプレを生成することになる。余談として、このような実施形態は、現在の環境状況を用いて両方の行動−状況デュプレに知らせることに限定されないであろう。このような場合、第１の行動−状況デュプレ（予定表記入の生成を表わす行動を含むもの）は現在の状況を含んでいてもよいが、第２の行動−状況デュプレ（実施予定の動作を含むもの）は、予定表記入そのものなどの情報源から得られるような、未実施の動作が実施されるはずの時間、日付、及び場所をより正確に表わす状況を含んでいてもよい。

ｂ．状況オブジェクト
未加工行動と同様に、状況オブジェクトは、状況ファクターを提供するホストシステムの要求によって決定されるように、副分類されてスーパークラスとなる傾向がある。このことは、すべてのホストシステムが包括的な一連の状況ファクターを有するエンジンを提供できるわけではないので重要である。たとえば、ＧＰＳ無線を有する携帯電話や無線ＰＤＡは地理位置情報を提供することができるであろうが、このような無線を有しないデスクトップコンピュータのオペレーティングシステムはできないであろう。

ほとんどの実施において、状況サービスはマスター状況オブジェクトシングルトンを有するものとして定義され、マスター状況オブジェクトシングルトンは１つ又は複数の状況ファクターフィールド及び複数の読取り専用状況オブジェクトから成り、複数の読取り専用状況オブジェクトはエンジンの残るサービス又はホストシステムに必要に応じて生成されて展開される。各状況リスナーは、これが観察する状況ファクターに対する値を確立すると、マスター状況オブジェクト内の対応するフィールドが更新される。以下のリストは、状況サービスの採用において未完成の一連の状況ファクターを表わす。
１．場所（地理空間的、政治的、ネットワークの位置［ＩＰアドレス、仮想位置、携帯電話ネットワーク内の位置］）
２．ネットワーク特性（信号強度、ローミング状態、ＱｏＳ、帯域幅など）
３．時間［実時間、ネットワーク時間、仮想時間］
４．加入者心的状態（感情フィードバック）
５．使用デバイスの製造番号（ＩＭＥＩ、ＩＭＳＩ、ＭＡＣアドレスなど）
６．使用デバイスの特性（サイレント及びリンギング、有線及び無線ネットワーク採用など）
７．個人的な場所（家庭、オフィス、車両）
８．周辺デバイス（携帯電話、プリンター、ＲＦＩＤタグなど）
９．周辺ネットワーク（ブルートゥース、ジグビー、ＲＦＩＤ、ＮＦＣ）
１０．天候又は気温
１１．加入者の電話番号及び／又は加入者ＩＤ
ここで、状況ファクターの一部はホストシステムに対する実質的な変更によってのみ提供されうるが（番号４、加入者心的状態）、ほかの一部は番号７、個人的な場所と同様に、加入者によって主観的に定義されなければならないことは注目に値する。

たとえば、加入者心的状態の具体的な事例では、携帯デバイスに関する一実施は、電話ダイアラーアプリケーション「通話終了」ボタンに、拡張して２つのソフトキーを含めることができるかもしれず、したがって、３つのキーのいずれかを押すことによって電話が切られ可能性がある。このとき、各キーは、状態を示すための数値が割り当てられることになる。左のソフトキーは満足を示すために使用され、右のソフトキーは怒りを示すために使用され、通話終了ボタンは心的状態に変化がないことを示しうる。各キーの上方にあるアイコンは、どのボタンがどれであったかを加入者に示しうる。

加入者が電話を切るとき、通話の終了時にどのような気分であったかに応じて３つのボタンの１つを選択することになる。これによって、エンジンは加入者の心的状態を大まかに捉えることができるはずである。

ｃ．未加工行動−状況デュプレ
簡単に言うと、未加工行動−状況デュプレは、未加工行動と状況オブジェクトを分解せずに結合するオブジェクトにすぎない。ここで、これについて注目すべき理由は、エンジンのクライアント側コード１０４の実施の大部分で、未加工行動−状況デュプレはエンジンのサーバント側構成要素に単独で送られないことである。通常はアレイ又はリストの形態のラッパーはサーバ側ソフトウェアに一度に公開されうる。

５．推論サービス（クライアント側）
行動サービス１０９及び状況サービス１１０と同様に（また、まったく同じ理由で）、推論サービス１１１は、複数の異なる実施を有していてもよい。同様に、また、推論サービス１１１は、ホストシステムの通常のプロセスから独立して存在しうるスタンドアロンコード（アプリケーション、サービス、スレッド、又はプロセス）であるように設計される場合が多い。推論サービス１１１は、その主要機能がエンジンのサーバ側構成要素と通信するためにホストシステム１１２のルートの役目を果たすので、エンジンのサーバ側構成要素１０２が常駐するネットワークにアクセスすべきである。その通信用の手段は、次のセクションで議論される推論クエリと呼ばれるオブジェクトである。

動作中、推論サービス１１１は、ほとんど常に待ち受け状態又は休止状態にあり、レバー１０８から、あるいはホストシステム１１２から直接要求を受け入れるように呼び起こされる。受け取られる要求は、一般に、レバー又はホストシステムによって求められる行動データの型、要求に対する応答が置き換えられるべき形式、及びホストシステムのセキュリティ証明書を含む。

この情報は、転送されて推論クエリに適するように再フォーマットされ、情報に付加された最新の状況オブジェクト（状況サービス１１０によって提供される）を有することになる。

一部の実施において、レバー１０８及びホストシステム１１２は、それ自体の状況詳細を推論サーバ１１１に対する要求の一部として提供する。これが行なわれるとき、サーバ側構成要素によって返される行動データはこれらの状況詳細に関係しており、状況サービスによって提供されるような加入者の実際の環境状況には関係しない。このプロセスは、多くの場合、具体的又は歴史的な一連の加入者行動がレバー又はホストシステムによって求められるときに開始される。前述の例を参照すると、加入者が自分に起こりそうな行動が先週の火曜日であったか、それとも今から２時間後であるか、あるいは自分がほかの場所にいたかを自分のダイナミックな待ち受け画面で見たい場合、待ち受け画面レバーを指示して状況が要求の中で推論サービスに使用されるように設定し、先週の火曜日、若しくは今から２時間後、又は他の場所に一致するようにすることができる。推論サービスは状況サービスによって指定されていることになるので、推論サービスから返されるデータは、このとき、これらの状況パラメータに関連する行動を反映し、実際の現在の環境状況に関連しないことになる。

一実施形態において、推論サービスは過去の推論クエリを格納し、それに対応する、エンジンのサーバ側部分から受け取られたキャッシュを含む。このキャッシュは、指定期間内にエンジンのクライアント側部分によって作成された正確に一致する推論クエリの数を最小にするように設計される。キャッシュ内に残る項目の期間は、古すぎて信頼できない推論クエリに対する応答には頼らないように厳密に制御されてもよい。

この後、新たに生成された推論クエリは、過去の推論クエリ及び内部キャッシュに含まれる対応する応答と一致するかどうかが試験される。推論クエリがキャッシュ内の推論クエリと一致しなければ、推論サービス１１１によってエンジンのサーバ側部分に送出されて応答を待つことになる。

応答を受け取ると、結果は後で整合をとるためにキャッシュに入れられ、この後、レバー１０８及びホストシステム１１２によって初期の要求と一致するように再フォーマットされる。再フォーマットされた結果は、この後、通話サービス又は通話システムに提供される。

ａ．推論クエリ、行動アトム、データポイント、及び知識実体
推論クエリのより有意義な議論を続ける前に、最も基本的なエンジンのデータタイプである知識実体、及びその数学的に有意義な密接に関係する事項、行動アトム及びデータポイントを行動モデルの概念とともに最初に説明しなければならない。これらの様々な実体の相互関係の視覚表示に対して以下で議論する際に図２及び３を参照することができる。

知識実体２０１は、システムが捕捉して格納できる知識の最小ビットである。一般に、知識実体２０１は、以下の共通要素を含むオブジェクトと定義される。
１．実体の固有識別子
２．加入者の固有識別子
３．実体の記述（又は名前）
新たな要素が追加されてもよいが、すべての知識実体２０１は前述の要素を含む。とは言うものの、知識実体は、文字通り、電子的に表現されうるほとんど何であってもよい。一部の例として以下が挙げられる。
１．成句「誰がために鐘は鳴る」
２．アプリケーションｉＴｕｎｅｓ
３．電話番号＋１（２１２）５５５−１２３４
４．概念「平和」
５．１６進数０ｘ５３ＣＦ０Ｄ７７８７７８Ｄ
６．日付１９９７年９月２４日
７．ＵＲＬ ｈｔｔｐ：／ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍ
８．曲名「歴史は繰り返す」
９．地理空間座標「北緯３７°２４’５３．６４、東経１２２°５’３３．６」
１０．心的状態「満足」
１１．事象「母と食事」
１２．フランクが加入者の父親であることを指定する関係オペランド
１３．２００７年９月２４日は月曜日であることを指定するオペランド
１４．空は青いという常識
一般に、知識実体２０１は、以下のカテゴリの１つに分類される。（ただし、このリストは不完全であり、カテゴリ名は変更されることがある。）
１．人
２．場所（これは客観的な場所（たとえば、ワシントンＤ．Ｃ．ペンシルバニア通り、１７００））を示していてもよく、あるいは主観的な場所（たとえば、家庭）、さらには場所に固有でない状況データ（たとえば、現在、午前３時で電話は３時間移動していない）から推論されてもよい）
３．アプリケーション
４．概念
５．物
６．ＵＲＩ（クリックストリーム）
７．メディア文書（歌曲、ビデオ、書籍［音楽］）
８．事象
９．感情
１０．関係
１１．オペランド
１２．常識
図２を参照すると、状況オブジェクト２０３と結合されるときの知識実体２０１は、行動アトム２０５と呼ばれる。行動アトムは数学的意味を有するように数学アルゴリズム２０９によって変換されるとき、これはデータポイント２０７と呼ばれる。ここで、図３を参照すると、複数のデータポイント２０７は、単純ベイズなどの適当なモデリングアルゴリズム３０３を用いて数学的意味があるように配置され、その配置の数理解析を実行するソフトウェアエンジンと結合されると、まとめて行動モデル３１０と呼ばれる。モデルは、一般に、構成プロセスを通じて加入者によって主観的な名前が付けられる。

一部の実施において、行動アトム２０５は、複数の知識実体２０１及び／又は状況オブジェクト２０３を含むように設計される。例示的な実施において、知識実体及び状況オブジェクトに関する行動アトムの値が非決定性であるように、新たなファクター（ランダム性の程度を表わすパラメータ）がこのような行動アトムに追加されてもよい。このような例示的実施の値は、ある程度の「セレンディピティ」を行動モデルに取り込むか、あるいは「忘れやすさ」をエンジンに取り込むべきである。

これらのデータ型のさらに形式的な議論が、以下で、エンジンのサーバ側構成要素の議論において行なわれる。ただし、推論クエリを理解するための基礎を提供するには上記の説明で十分である。

したがって、上記が所与とすると、推論クエリ３０５は以下の要素を含むオブジェクトである。
１．固有の加入者ＩＤ
２．セキュリティトークン
３．一般に状況サービス１１０によって提供されるサーバに対する推論クエリ３０５の状況。状況は１つ又は複数の以下の状況ファクターからなる。
ａ．場所（地理空間、政治的、ネットワークの位置［ＩＰアドレス、仮想位置、携帯電話ネットワーク内の位置］）
ｂ．ネットワーク特性（信号強度、ローミング状態など）
ｃ．時間［実時間、ネットワーク時間、仮想時間］
ｄ．心的状態（感情フィードバック）
ｅ．使用デバイスの製造番号（ＩＭＥＩ、ＩＭＳＩ、ＭＡＣアドレスなど）
ｆ．使用デバイスの特性（サイレント及びリンギングモード、有線及び無線ネットワーク使用など）
ｇ．主観的な場所（家庭、オフィス、車両）
ｈ．周辺デバイス
ｉ．周辺ネットワーク（ブルートゥース、ジグビー、ＲＦＩＤ、ＮＦＣ）
ｊ．天候又は気温
ｋ．加入者の電話番号及び／又は加入者ＩＤ
４．推論クエリに対する応答を発生するために使用される行動モデルの名前
５．クエリの対象となる知識実体のカテゴリ。たとえば、以下の１つ。
ａ．人
ｂ．場所（これは客観的な場所又は主観的な場所、さらには場所に固有でない状況データから推論されてもよい）
ｃ．アプリケーション
ｄ．概念
ｅ．物
ｆ．ＵＲＩ（クリックストリーム）
ｇ．メディア文書（歌曲、ビデオ、書籍［音楽］）
ｈ．事象
ｉ．感情
ｊ．関係
ｋ．オペランド
ｌ．常識
６．クエリに対応して含まれる知識実体の数
これは、エンジンのクライアント側構成要素の記述を決定する。

ＩＩ．サーバ
エンジンのサーバ側コードは、以下の６つの要素に分類するよう検討されてもよい。
１．行動サービス１１７
２．モデラーサービス１１８
３．行動モデラー１１９
４．行動モデル１２０
５．推論サービス１２１
６．状況サービス１２２
以下の議論では、これらすべての構成要素はサーバコードの単一収集の要素であると仮定しているが、互いに応答しあう必要があるすべての構成要素が互いにアクセス可能である（すなわち、すべての構成要素が同じネットワークを共有する）限り、これらはサーバコードの単一収集の要素である必要がない。一部の実施において、モデラーサービス１１８は、その処理がコンピュータを駆使したものとなりがちなので、したがって、アクティブなときは他のサービスの性能に害を及ぼすので、拡張可能性のために他のサービスから明確に切り離されてもよい。

以下の議論では、さらに、上記の構成要素の各々を順に詳しく説明する。
Ａ．行動サービス（サーバ側）
エンジン内のサーバ側行動サービス１１７は、通常、様々なクライアント側行動サービスからの複数の同時接続を管理するように設計されるスタンドアロン・サーバ・プロセスとして実施される。一実施において、行動サービス１１７は、単一のＴＣＰ／ＩＰポートを占有するが、アーキテクチャにはこのような制限がない。行動サービスの主要な機能は、クライアント側行動サービスによって提供される未加工行動−状況デュプレをデータベースに格納される行動アトムに変換することである。これを行なうために、行動サービス１１７は、デュプレ内の各未加工行動をその様々な行動ファクターに分けてからこれらのファクターを知識実体に分類しなければならない。この後、実体は、デュプレの行動オブジェクトを適用して行動アトムに変換される。これらのタスクを実行するために、行動サービス１１７は外部システムに頼ってもよく（そして、多くの場合外部システムに頼る）、その一部についてここで述べることにする。

未加工行動−状況デュプレの行動ファクターへの変換に続く知識実体への変換はコンピュータ及びメモリ資源を駆使するものとなりうるので、この変換はデュプレ（クライアント側コード）を提供するクライアントデバイス１０１ｄ又はサービスで試みられないことが好ましい。さらに、前述のように、変換の一部はサーバ側行動サービス１１７の外部のサポートシステムによって提供される情報に依存し、したがって、デュプレを提供するクライアントデバイス１０１ｄ又はサービスには必ずしも役立たないことになる。それでもやはり、クライアントデバイス又はサービスが変換のコンピュータ及びメモリ資源要件をサポートすることができれば、このような変換はデュプレを提供するデバイスで達成されて未加工行動−状況デュプレの必要性を完全に排除することができる。

行動サービス１１７は、以下の複数の構成要素に分解される可能性がある。
１．クライアント側から未加工行動−状況デュプレのリスト又はアレイを受け入れるか、あるいはクライアント側から未加工行動−状況デュプレのリスト又はアレイを要求するウェブサービス１３１。
２．デュプレを一時的に受け取る待ち行列１３３。
３．各デュプレを調べてこれを１つ又は複数の行動アトムに分離する少なくとも１つの行動−状況プロセッサ１３５。行動アトムは、さらに、プロセッサによって知識実体に変換される。
４．待ち行列内のデュプレの存在が通知されたとき、各デュプレを処理するために起動されるべき行動−状況プロセッサを決定する待ち行列マネジャー１３７。
５．以下の３つのリレーショナルデータベース
・未加工行動−状況デュプレを格納する未加工行動−状況デュプレデータベース（ＲＢＣＤ ＤＢ）１３９
・処理された知識実体を格納する知識実体データベース（ＫＥ ＤＢ）１４１
・処理が終了した時点で行動アトムを格納する行動アトムデータベース（ＢＡ ＤＢ）１４３
動作中に、待ち行列マネジャー１３７は、ウェブサービス１３１が未加工行動−状況デュプレのリスト又はアレイを成功裡に受け入れてそのオブジェクトを待ち行列１３３に入れたことが通知されると、直ちにリスト又はアレイの内容を調べる。各未加工行動−状況デュプレに対して、マネジャー１３７は、適切な行動−状況プロセッサを決定してこのプロセッサ１３５の活動を開始する。

この後、プロセッサは、アレイ又はリストから各デュプレを抽出し、そのデュプレを調べ、この後、そのデュプレ内の個々の行動ファクターを抽出する。ほとんどの場合、単一のデュプレは多数の行動ファクターに変換される。これらのファクターは１つ又は複数の知識実体に分類される。この達成方法の詳細については、知識実体が知識実体データベース１４１に格納される前に知識実体で新たな処理が実施されるので簡潔に触れておく。

知識実体が生成された時点で、プロセッサは、これらの実体を試験中のデュプレからの状況オブジェクトとペアにする。これら２つのオブジェクトの組合せによって、実体は行動アトムになる。新たなメタデータ、たとえば、ＮＬＰ（自然言語処理）エンジンからの語幹関係（stem-relationship）メタデータが存在する場合（通常、デュプレ及び行動サービスとは別のソースからの）、これは行動アトムにこの段階で加えられる。

一部の例では、行動−状況プロセッサ１３５とやり取りするときのこれらの外部サービスは、行動−状況デュプレにおける知識実体とは別に新しい知識実体を生成する。何かの好循環があると、一部の行動−状況プロセッサからの知識実体は、外部サービスによって処理され、得られたデータは新たな処理のために行動−状況プロセッサ１３５に返される。このフィードバックループの最終結果は、新たな行動アトムの生成である。

このプロセスが完了した時点で、完成された行動アトムは行動アトムデータベース１４３に格納される。同様に、未加工行動−状況デュプレは、未加工行動−状況デュプレデータベース１３９に格納され、知識実体（新たな処理後の）は知識実体データベース１４１に格納される。未加工行動−状況デュプレの場合、この格納によって他のシステムによる最終的な処理が可能になるが、他のシステムのほとんどは本明細書の範囲外にある。

例として、加入者が本開示の原理に従って構成された電子書籍端末で一部のテキストを適切に「強調表示」又は選択した場合の活動から未加工行動−状況デュプレが生成された場合を考えてみよう。強調表示されたテキストは、「誰がために鐘は鳴る」であってもよく、この動作は６月１日、水曜日、午後３時に加入者の家庭で実施されてもよい。以下の行動アトムは、行動−状況プロセッサ１３５による処理の結果として生成されてもよい。
・行動が電子文書から生じたことを示すために、メタデータとしての「誰がために鐘は鳴る」に関するメディア文書アトム
・加入者の家庭を示す場所アトム（場合により、その場所のＧＰＳ座標に準拠した）
・「満足」（加入者の心的状態）に関する感情アトム
・電子書籍に関するアプリケーションアトム（すなわち、電子書籍がホストシステムであった）
・強調表示されたテキストの単語の各々に対する複数の個々の概念アトム（ほとんどの場合、定冠詞、“ｔｈｅ”のようなストップワードを差し引く）
上記の最後の概念アトムに対するメタデータは、一般に、全体として、行動−状況プロセッサ自体によってではなく、メタデータを生成するための語幹抽出及びＴＦ−ＩＤＦのような従来のテキストマイニング技法を適用する外部の自然言語処理エンジンによって生成されることになる。前述の好循環の例において、このＮＬＰエンジンは、この後、このメタデータを行動−状況プロセッサ１３５にフィードバックし、行動−状況プロセッサ１３５は、この後、そのメタデータを知識実体に変換し、さらに行動アトムに変換する。こうする理由は次のセクションで説明する。

１．行動−状況プロセッサ
行動−状況プロセッサ１３５の作業は、参照テーブルの行に沿って、行動ファクターから知識−実体への簡単な１対１又は１対複数の変換となる場合が多い。これは、人間が明確に読み取れる（人間がデータを検査しようとするとき）２つの領域のマッピングを行なうことと、高速処理の終了を容易にすることの両方に対して慎重に行なわれている。より複雑な変換メカニズムが要求されるとき、行動ファクターの要素である場合の一部の未加工の非構造化テキストを処理するために自然言語プロセッサが導入されるときと同様に、新たな領域固有のプロセッサが、通常、加えられる。

一実施において、この１対１又は１対複数の変換は、「ハードワイヤー」によるコード変換であってもよい。すなわち、どれか１つの行動ファクターが常に１つ又は複数の所定の知識実体にマッピングされ、行動ファクターはその知識実体と関連するメタデータによってのみ異なる。しかし、このプロセスは、ダイナミックに行なわれうるが、さもなければ、数学アルゴリズムの影響を受けることがある。このプロセスは、さらに、エンジン自体の出力の影響を受けて、行動ファクターの知識実体への変換が状況及び／又は行動の影響をきわめて受けやすくなる可能性がある。

新しい行動ファクターがシステムに導入されると、新しいファクターが既存の未加工行動の要素であるか否かにかかわらず、行動−状況プロセッサ１３５に対する変更が、通常、必要となる。これらの変更は、通常、知識−実体に対する行動ファクターの１対１又は１対複数のマッピングを変更することに限定される。

２．知識実体の後処理
前述のように、知識実体システムが捕捉する知識の最小ビットである。各実体は、固有であり、以下の共通要素からなる。
１．実体の固有識別子
２．加入者の固有識別子
３．実体の記述（又は名前）
さらに、知識実体は、未加工行動−状況デュプレに関係するが、必ずしも未加工行動−状況デュプレから抽出されないメタデータを含む可能性がある。例として（過去の例から構築した）、記述「誰がために鐘は鳴る」を含む知識−実体は、以下を含む可能性のある外部手段によって提供される新たな属性を有していてもよい。
１．著者
２．長さ（テキストが抽出された作品の）
３．ジャンル
４．ＩＳＢＮ番号
５．ＵＲＩ（必要に応じて）
行動−状況プロセッサ１３５は、エンジン内に現在一致する実体が存在しないことが明らかになると新しい知識−実体をダイナミックに生成する。ここで実施される一致は、前述の知識−実体データベース１４１に対する行動−状況プロセッサによって行なわれる。新しい知識−実体が生成されると、これらは「積極性」についての初期の重み又は属性を与えられる。この属性は、この知識−実体を含む行動アトムがエンジンのリマインダーによって最終的に生成される行動モデルに含まれるべきかあるいは含まれるべきでないかの程度を示すある種のフィルターとしての役割を果たす。本発明者らは、モデルサービス１１８の活動を議論する際にこの属性の使用をさらに具体的に議論しよう。

この「積極性」の属性の値は、ＴＦ−ＩＤＦアルゴリズムによって制御される場合の概念アトムの知識−実体の場合と同様に、加入者によって制御されうるが、数学アルゴリズムによってダイナミックに制御されうる。一実施において、すべての知識−実体（概念アトムに関するものを除く）は最大限度の「積極性」で設定される。別の実施において、「積極性」は、知識−実体が加入者の未加工行動に現われる頻度によって影響されることがある。

Ｂ．モデラーサービス
サーバ側行動サービス１１７と同様に、モデラーサービス１１８は、一般に、スタンドアロン・サーバ・プロセスとして実施される。モデラーサービス１１８は、行動アトムのデータベースからのデータセットの準備に関与して最終的に行動モデルと呼ばれるデータ構造を生成する。行動モデルは、以下で詳しく議論される特定範囲の状況によって記述される境界内の加入者の歴史的行動の数学的表現である。

モデラーサービス１１８は、以下の４つの要素に分けられる。
１．モデル構成１５５
２．モデル構成データベース１５３
３．タスク１５７
４．スケジューラ１５１
モデル構成１５５は、以下を詳しく説明する１組のパラメータである。
１．行動モデルの生成に最終的に使用されるデータセットの状況境界（これは、通常、状況属性の範囲として指定される）
２．不要な行動アトムをデータセットから除去するために使用される知識実体「積極性」の程度
３．行動モデルを生成するためにデータセットで使用されるアルゴリズム又は行動モデラー（行動モデラーの詳細は行動モデルについての本発明者らの議論においてフォローする）
４．行動モデラーに有用な情報を詳述する（後で説明される）変換テンプレート
５．行動モデルが生成される頻度。なお、この頻度は構成で指定される状況範囲から完全に独立している。

モデラーサービス１１７は、１つ又は複数の加入者に対する複数のモデル構成をモデル構成サービス１１７の第２の要素であるモデル構成データベースに格納する。
モデラーサービスの第３の要素は、タスクオブジェクト１５７である。これは、一般に、行動モデルを生成するのに必要な手順の実行に関与するスレッドとして実施される。生成されるタスクは、モデル構成及び行動アトムデータベースに対するＵＲＩを与えられ、このデータベースからそのデータセットを得る。実行されるタスク１１９は、必要不可欠なデータセットを捕捉し、モデル構成１５５で指定されたアルゴリズム又は行動モデラー１１９に渡す。モデラーが行動モデルの生成を完了した時点で、タスクオブジェクト１５７は行動モデルを独立したデータストアに格納する。一実施におけるこのストアは、リレーショナルデータベース又はファイルシステムのいずれかによって存続されるキャッシュである。

一実施形態において、モデル構成１５５は、そのパラメータがタスクオブジェクト１５７にそのデータセットを単一の行動モデラー１１９に無理に適用するように実施される。他の実施形態において、タスクオブジェクト１５７は、より柔軟であってもよく、タスクオブジェクトがそのデータセットを複数の行動モデラー１１９に渡せるようにそのモデル構成１５５を増強してもよい。このようなシナリオで生成される行動モデルの多様性を利用すると、サーバ側推論サービス１２１（これはまだ議論されていない）が一連のクエリをこの１組の行動モデルに対して実行することができる。これらのクエリは、ダイナミックにかつ同時に実施され、「最も納得のいく」結果をもたらすために使用する「最良の」モデルを決定することになる。「最良の」モデル及び「最も納得のいく」結果は、クエリの結果に対する本来の目的に大きく依存する。

モデラーサービス１１８の第４及び最後の要素は、スケジューラ１５１である。これは、タスクオブジェクト１５７にその動作の実行を定期的に許可することに関与するスレッドである。スケジューラ１５１の設計はきわめて一般的であるため、スケジューラ１５１は複数のタスクオブジェクトが同時に動作するように設計され、スケジューラ１５１はそのスケジューリングを管理するために各タスクオブジェクト１５７でモデル構成１５５を使用すると言うだけで、ここでは詳細に議論しない。

１．行動モデラー及び行動モデル
行動モデラー１１９は、前述のタスクオブジェクト１５７の状況内で実行されるオブジェクトである。行動モデラー１１９は、行動アトムデータベース１４３からのデータのサブセットとしてその初期状態からのタスクオブジェクト１５７によって得られたデータセットを行動モデルに変換することに関与するものであり、ここで、本発明者らは行動モデルを数学アルゴリズムによって扱うことができる「データポイントの集団」と定義する。「集団」が意味するものは、データポイントの構造の手短な表現である。このデータ変換は、次のように記述される３ステッププロセスであると考えられる。
１．状況を状況値に前処理すること
２．「集団（ｃｌｏｕｄ）」のデータポイントを生成すること
３．行動モデラーアルゴリズムを選択すること
行動モデラー１１９の作業が終了すると、加入者の歴史的行動及び環境状況の「数学的に意味のある」モデルが生成されていることになる。このモデルは、実際には、１つ又は複数の数学アルゴリズム又は機械学習アルゴリズムの実施形態であるアルゴリズムと結合された多次元の状況座標系を表わす複雑なデータ構造である。

２．行動モデラーアルゴリズム
モデラーサービス１１８は、これがサポートする行動モデラーアルゴリズムの各々に対して１つの、複数の行動モデラーを含む。エンジンの予測機能に対して複数のアルゴリズムをサポートするための選定は、あらゆる状況において単一のアルゴリズムは理想的でないと言わざるをえないので、入念に行なわれる。

適切な行動モデラーアルゴリズムは機械学習アルゴリズムを含むが、他のタイプのアルゴリズムもサポートされうる。行動モデラー設計によるサポートが想定される行動モデラーアルゴリズムとしては、以下が挙げられるが、これらに限定されない。
１．単純ベイズ
２．階層的単純ベイズ
３．隠れマルコフ
４．期待値最大化
５．最近傍
６．重心分類装置
７．フラクタル次元
各々が発散的なデータセット要件を有する複数の機械学習アルゴリズムを有するにもかかわらず、行動モデラー設計は、一般的な一連のＡＰＩを各行動モデラーアルゴリズム、及び行動モデラー１１９の基礎構造にさらしているという現実がある。このアプローチを採用すると、複数の行動モデラーアルゴリズムを生成することができ、すべての行動モデラーがモデラーサービス１１８に同じに見えるようにすることができ、各行動モデラーに対して一貫した構造の行動モデルを生成することができる。本発明者らはこのアプローチには非常に大きな独自性があると考えている。また、このアプローチは、エンジンのアプリケーションを超えて様々なアプリケーションに適用できる十分に一般的なものとなされうる。

３．データポイント及びその「集団（クラウド）」
行動アトムのデータセットを「データポイントの集団」に変換するプロセスは複雑である。まず、データセット内の各行動アトムは１つのデータポイントに変換され、その構造はタスクオブジェクトのモデル構成内の変換テンプレートによって定義される。一般的に、データポイントは、状況値のアレイと結合された行動アトムの知識実体部分であると言うことができ、状況値そのものはその同じ行動アトムから抽出されている。状況値の抽出は簡潔に議論されるが、その存在の背景にある意図は、行動アトム内で捕捉される環境状況を多次元状況座標系、すなわち、距離空間における座標と同じものに分解することであり、座標は数学的に定義されるからである。このような空間は、行動モデラーアルゴリズム内で特有の意味を有し、行動モデルが加入者の行動の推測に使用されるときこの座標系に依存する。

状況値の生成の詳細を議論する前に一歩退くと、前述のようなデータポイントを多次元の「集団」状況座標系内の状況値によって示される「座標」に置かれた「属性」と考えることができる。この例えは、サーバ側推論サービスについての今後の議論に特に有用であり、したがって、ここで少し詳しく説明するに値する。

単純化された例を用いて、色が三次元（Ｘ−Ｙ−Ｚ）座標系におけるデータポイントの属性として関連している場合を考えてみる。この座標系の各データポイントは、Ｘ、Ｙ、及びＺの座標値とある現実世界の特性（Ｘ１Ｙ１Ｚ１Ｑ）を表わす色、Ｑとを有する。数千個のこれらの着色されたデータポイントを有し、これらの各々を選定してプロットすると、色彩に富んだ「集団」データポイントを生成した可能性があることを理解するであろう。

例えを拡大すると、この「数多く」のＸ、Ｙ、Ｚの値は、各々がデータポイントの状況値に対応しており、知識実体は色に対応することになる。これを行動モデラー１１９の設計の詳細に拡大すると、「集団」データポイントは多次元データ構造であり、この場合、データポイントは状況値によって定義される軸に沿って配置される。これらの状況値は、行動アトムの最初のデータセットに対する境界としてタスクオブジェクトのモデル構成１５５によって示された状況属性に直接関係する。

このように状況値を定義すると、「集団」の座標系は有界のデータセットの一部であった状況属性を含むだけであるという制限が、行動モデラー１１９に設けられる。したがって、たとえば、モデラーサービス１１８内で、状況属性が加入者の行動を予測することに対して統計的に有意であっても、加入者がその状況属性をモデル構成１５５に含めることを怠ったがために最終的な行動モデル含まれないことがありうる。

例として、屋外は−５℃のとき加入者が「ｔｈｅｗｅａｔｈｅｒｃｈａｎｎｅｌ．ｃｏｍ」ウェブサイトを偶然に訪れるだけであるが（たとえば、自分はスキーをしたくて寒いときに雪が降っている場所に関心があるため）、気温がモデル構成内の状況属性の境界の１つとして含まれていなかった場合、行動モデラーのアルゴリズムは気温がその加入者の将来の行動において重要なファクターであったことを確証できなかったことになる。

４．状況値の前処理及び生成
状況値を抽出する多段階プロセスは、行動モデラー１１９によって行動アトムの状況部分内の各状況属性を調べることから始まる。第１ステップとして、状況属性はそれ自体の「数値」表現又は「公称」表現に変換される。

この数値又は公称値は、この後、その構造において、表現されている属性の特徴と属性の「数学的意味」の両方を捕捉するオブジェクトに再計算される。文字通りの意味で、これは、数値又は公称値が表現されている状況の種類又はタイプに固有の新しい状況値オブジェクト内に置かれることを意味する。たとえば、−５℃の気温に対する状況属性は、−５の数値の摂氏気温状況値に変換されることになる。

この変換の理由は、新しい状況値が「集団」に関連する行動モデラーアルゴリズムのソフトウェア技法と明確に一致するスカラー値の「数学的意味」を定義するソフトウェア技法をカプセル化することである。「数学的意味」では、事実上、状況値が明確な距離空間に属する（すなわち、距離空間は反射性、対称性、及び三角不等式に関する公理を満たす対応する距離関数を有することになる）ことになる。

行動アトムに関するすべての状況値が生成された時点で、これらの状況値は事実上アレイになる特定の順番で置かれる。このアレイは、行動モデラーアルゴリズムの多次元座標系内の状況属性の座標位置を定める。この座標は、この後、行動アトムの知識−実体に結合されてデータポイントになる。

このプロセスは、各行動アトムが変換されてしまうまで続く。得られる「集団」は新しい行動モデルに渡され、ここで、タスクのモデル構成１５５で定義された行動モデルアルゴリズムによって結合される。

Ｃ．推論サービス（サーバ側）
推論サービス１２１は以下の４つの要素を備える。
１．クライアントがエンジンの推論クエリを行なうことができるウェブ・サービス・インターフェース１６７
２．複数の推論クエリが同時に処理されうる待ち行列又はプール１６３
３．クエリ自体の実施手順を実行するクエリスレッド１６５
４．ある期間内に同じモデルで正確な複製クエリが実施されないようにするために各クエリと照合される推論クエリキャッシュ１６７
ウェブサービス１６１は、ネットワーク上で推論クエリを受け取るネットワーク・インターフェース・ソフトウェアの妥当な実施から作られうる。

動作中に、まず、ウェブサービス１６１は、クライアントコードから推論クエリを受け取る。前述のように、推論クエリは以下を含む。
１．固有の加入者ＩＤ
２．セキュリティトークン
３．クエリの状況。状況は１つ又は複数の以下の属性からなる。
ａ．場所（地理空間、政治的、ネットワークの位置［ＩＰアドレス、仮想位置、携帯電話ネットワーク内の位置］）
ｂ．ネットワーク特性（信号強度、ローミング状態など）
ｃ．時間［実時間、ネットワーク時間、仮想時間］
ｄ．心的状態（感情フィードバック）
ｅ．使用デバイスの製造番号（ＩＭＥＩ、ＩＭＳＩ、ＭＡＣアドレスなど）
ｆ．使用デバイスの特性（サイレント及びリンギングモード、有線及び無線ネットワーク使用など）
ｇ．主観的な場所（家庭、オフィス、車両）、常に加入者定義
ｈ．周辺デバイス又は周辺ネットワーク（ブルートゥース、ジグビー、ＲＦＩＤ、ＮＦＣ）
ｉ．天候又は気温
ｊ．加入者の電話番号又は加入者ＩＤ
４．クエリに使用されるモデルの名前
ａ．名前は、加入者がモデル構成を生成するとき加入者によって任意に選定される。モデル構成の名前はモデル自体の名前である。
５．クエリの対象となる行動−実体のタイプ。これは以下の１つである。
ａ．人
ｂ．場所（生成されないが状況データから推論されうる）
ｃ．アプリケーション
ｄ．概念
ｅ．物
ｆ．ＵＲＩ（クリックストリーム）
ｇ．メディア文書（歌曲、ビデオ、書籍［音楽］）
ｈ．事象
ｉ．感情
ｊ．関係
６．クエリに対応して含まれる行動実体の数
推論サービス１２１は、推論クエリを捕捉し、データポイントの生成に使用される適切なモデル構成１５５を参照するためにクエリ内にモデルの名前を使用する。推論サービス１２１がモデル構成を有した時点で、推論サービス１２１は、行動実態が空の新しいデータポイントを効果的に生成するための指針としてモデル構成を使用する。このデータポイントは、モデルに対するアプリケーションに適している。この新しいデータポイントに対する状況座標は、推論クエリから抽出される状況属性から生成される。すべての状況属性が生成されている各モデルに適しているわけではないので、状況属性について何らかのフィルタリングが実施されてもよい。行動実態が空のデータポイントが生成された時点で、推論サービス１２１は、データポイントを使用して推論クエリキャッシュ１６７を参照し、まさに実行されようとしているものと同じ結果をもたらす分析をシステムが最近実行しているか否かを判断する。参照の一致に関する基準は以下の通りである。
１．データポイントの状況座標
２．モデルの名前
３．求められる行動のタイプ
キャッシュ１６７の結果を使用するために、上記基準の各々に対して正確な一致があるべきである。正確な一致がない場合、推論サービス１２１は、モデル名と行動実体名を用いてモデルを捕捉し、データポイントをモデルのクエリインターフェースに適用する。生成されて名前が付けられたモデルは、単一の行動モデラーアルゴリズムを適用して唯一の行動実体型の１組の結果を生成することを目的としていることに留意しておくことが重要である。これは効率性を考えて行なわれる。先に議論された行動モデラーアルゴリズムは、モデルの適用されたデータポイントの状況座標を満たすデータポイントデュプレのランク付けリストを生成する。これらのデュプレは、データポイントが状況座標にいかに良く一致したかに関して０〜１の「信頼スコア」が付加された、文字通り、モデルからのデータポイントである。このスコアは、行動モデラーアルゴリズムによって実施される計算の副産物である。推論サービスは、この後、ランク付けリストを構文解析して最初の推論クエリで要求された行動実体の数を抽出する。実体のその数が得られた時点で、オブジェクトはウェブ・サービス・インターフェースを通じて呼出しクライアントに返される。

先に記載したばかりのサーバ側推論サービスによる使用において、データポイントの知識実体部分には何もない状態であり、したがって、そのデータポイントを行動モデルのクエリインターフェースに適用することによってデータが増える可能性がある。このアプローチの場合、データポイントは、行動モデルのクエリインターフェースに適用された時点で、状況値の格付けリスト及び「信頼スコア」によってデータが増えた状態になる。この方法を使用すると、エンジンは状況を所与としてもはや人間行動を予測しなくなり、加入者の人間行動を所与として状況を予測する。エンジンは、質問「どんな一連の状況下で加入者がこの行動又は一連の行動を実施すると期待すべきか？」に回答する。

この代替アプローチは、特に監視区域で多数のアプリケーションをもたらす。法律執行の例において、このような方式は、エンジンに格納されたデータへのアクセスが可能で、かつ行動追跡のリストが手元にあるという条件で、容疑者の場所を予測する有効な方法になる。たとえば、このようなアプローチを用いると、法律執行当局は、周知の重犯罪人が自分の母親の誕生日に母親に電話するという情報のみを所与として、予想されるその犯罪人の居所に気付くかもしれない。推論クエリは、このような電話がかけられたときに周知の重犯罪人が居合わせた場所一式を返すことができるようなデータから作られうる。

別の例において、広告代理店は、加入者に金融サービス広告を示す最も有効な時間帯を確認して、加入者が仲介業者に電話した後マーケティングメッセージの影響を最も受けやすいことを知りたい場合がある。記載された行動に関する推論クエリを生成することによって、広告代理店は、広告が最も有効と考えられる時間帯の格付けリストを受け取ることができる。

Ｄ．状況サービス（サーバ側）
状況サービス１２２は、クライアント側の対応プロセスとまさに同様に機能するスタンドアロンプロセスである。状況サービス１２２は、サーバ側状況サービス１２２がマスター状況オブジェクトを管理しないという点において注目すべき違いがある。状況サービス１２２は、代わりに状況データベース１７９を維持する。この状況データベース１７９は、すぐ後で説明する記録状況ファクター（Recorded Context Factor）と呼ばれる新しい状況関連オブジェクトが投入される。サーバ側状況サービス１２２の主要な機能は、ギャップを埋める参照テーブルとしての役目を果たすことであり、ギャップはサーバ側の推論サービス１２１及び行動サービス１１７から提供される様々な状況オブジェクトに時々現われる。

状況サービスは以下の５つの要素に分類される。
１．状況サービスのウェブサービス１７１
２．状況待ち行列１７３
３．状況待ち行列マネジャー１７５
４．記録状況ファクターインターフェース１７７
５．記録状況ファクターデータベース１７９
実際に、状況サービスのウェブサービス１７１は、様々なクライアント側状況サービス１１０から状況オブジェクトを定期的に受け取る。これらの状況オブジェクトは、各々がタイムスタンプなどの多数の状況ファクターを含む。ウェブサービス１７１は、これらの状況オブジェクトを受け取ると、これらのオブジェクトを状況待ち行列１７３に入れて、状況待ち行列マネジャー１７５に通知する。状況待ち行列マネジャー１７５は、このような通知を受け取ると、状況待ち行列１７３から状況オブジェクトを得て、これを「展開」し、独立した状況ファクターを抽出する。状況待ち行列マネジャー１７５は、この後、各状況ファクターに対して個別の記録状況ファクターオブジェクトを生成し、キーとして状況オブジェクト内のタイムスタンプを利用する。新しい記録状況ファクターは、この後、最初の状況ファクター及びこのキーを含む。

記録状況ファクターは記録状況ファクターデータベース１７９に格納され、記録状況ファクターデータベース１７９は、一部の実施において、さらに正確には永続的データストアと呼ばれ、リレーショナルデータベースの代わりにキャッシュ及び場合によりファイルシステムを含む。

未加工行動又は推論クエリ内の状況オブジェクトが１つ又は複数の状況ファクターを欠いていると、サーバ側行動サービス１１７若しくは推論サービス１２１が判断するとき、記録状況ファクターインターフェースを用いて記録状況ファクターデータベース１７９を参照する。欠けているファクターが異なるクライアントによって提供されていれば、これらのファクターは状況オブジェクトに対するギャップを埋めるために行動サービス１１７又は推論サービス１２１に返される。

例として、加入者が本開示の原理に従って構成された自分のデスクトップマシンでウェブを定期的にブラウジングしていてもよいと考えよう。そのマシンは、エンジンのサーバ側行動サービス１１７に未加工行動を定期的に提供する。しかし、ほとんどのデスクトップマシンは位置認識しないので、これらのマシン上でクライアントによって提供される状況オブジェクトは位置状況ファクターを欠いていることになる。しかし、加入者が本開示の原理に従って構成された位置認識を含む携帯電話機を携行している場合、その携帯電話機から定期的に提供される状況オブジェクトは位置状況ファクターを含むことになり、これらのファクターがギャップを埋めるために使用されることができる。サーバ側状況サービス１２２が生成されたのはこの理由による。

ＩＩＩ．数学的観点から
行動モデラーアルゴリズムは、前述のように、「集団」及び特定の推論クエリにおけるデータポイントに基づいて加入者の好みを予測する１つ又は複数の数学的アルゴリズム又は機械学習アルゴリズムの実施形態である。さらに具体的には、行動モデラーアルゴリズムは、特定の行動内で加入者の収集行動を表わす「データポイントの集団」と一緒にエンジンのモデルの一部を形成する。使用中、これらのアルゴリズムは、エンジンの推論サービスから行動実体が空のデータポイントを提供され、１組の行動実体及び信頼スコアを生成する。

クライアント側及びサーバ側のソフトウェア構成要素を説明してきたが、行動モデラーアルゴリズムについては整っている。データポイントの収集に基づいて物事の予測に一般的に使用される数多くの周知の統計モデルアルゴリズムがあり、事実上、これらはいずれも本システムにおいて行動モデラーアルゴリズムとして使用されうる。前述のように、種々の推論クエリが種々の統計モデルアルゴリズムによってより良い働きをするかもしれない（すなわち、１つの統計モデルアルゴリズムが所与のケースにおいて別の統計モデルアルゴリズムよりも加入者の好みをより正確に予測するかもしれない）。このようなアルゴリズムは、行動モデラーアルゴリズムの１つとして使用するために当業者によって容易に改作されうる。

ＩＶ．フローチャート
上記のように、本発明の様々な構成要素及び動作を説明してきたが、図４〜１０は、本発明の様々な態様に従う動作の流れの説明に役立つチャートを示す。

Ａ．状況情報の連続収集（クライアント側）
図４は、クライアント側ソフトウェアの進行している状況情報収集プロセスを示し、このソフトウェアは状況リスナー１０７によって検出される最新状況情報で状況サービス１１０を定期的に更新する。ステップ４０１において、トリガー状況事象が発生する。これは、２分ごとに切れるように設定されるタイマーにすぎなくてもよい。つぎに、ステップ４０３において、状況事象は状況リスナー１０７によって検出される。状況リスナー１０７は、この後、状況情報を状況ファクターの形で収集し、状況ファクターは、この後、ステップ４０５において、状況サービス１１０に報告される。最終ステップ４０７において、状況サービスは、新しい状況ファクターをマスター状況オブジェクト（その状況ファクターに対する値がまだ存在しない場合）に加えるか、あるいはマスター状況オブジェクト内の既存の状況ファクターを新たに報告されたデータで更新する。このプロセスはステップ４０９において終了する。

Ｂ．行動情報及び状況情報の収集（クライアント側）
図５は、モデルを生成するのに必要な行動及び状況データの収集に関係するクライアント側ソフトウェアの例示的なプロセスの流れを示す。プロセスは、トリガー行動、たとえば、加入者が無線ＰＤＡで通話することに応答して開始される。

したがって、ステップ５０１において、未加工行動のトリガーが発生する。つぎに、ステップ５０３において、行動リスナー１０６がトリガー行動を検出してその行動を表わす行動ファクターを収集する。ステップ５０５において、行動リスナー１０６は、検出された行動（図４のフローチャートに示されたプロセスによって収集されるような）の周囲の最新の行動情報を収集するために状況サービス１１０を呼び出す。ステップ５０９において、状況サービス１１０は、行動が発生した状況に関するロウデータを含む状況オブジェクトを生成する。状況サービス１１０は、状況オブジェクトを行動リスナー１０８に返し、ステップ５１１において、行動リスナーは、行動−状況デュプレを生成し、これを行動サービス１１７に提供する。

つぎに、ある時点において、１つ又は複数の格納された行動−状況デュプレがサーバ側ソフトウェアに送られる。たとえば、ステップ５１３において、行動サービス１０９は、１つ又は複数の行動−状況デュプレ（行動−状況デュプレリストと呼ばれる）を含むメッセージを生成して本発明のサーバ側部分に送る。このプロセスはステップ５１５において終了する
Ｃ．行動−状況デュプレ（サーバ側）
図６は、行動−状況デュプレリストを行動アトムに変えて行動アトムデータベース１４３に格納するために、クライアント側ソフトウェアから受け取った上記の行動−状況デュプレリストの処理に関係するプロセスの流れを示す。この流れは、行動−状況デュプレリストがクライアント側ソフトウェア（図５におけるステップ５１３参照）から受け取られると呼び出される（ステップ６０１）。行動−状況デュプレリストを受け取ると、流れはステップ６０３に進み、ここで、行動ウェブサービス１３１が呼び起こされる。ステップ６０５において、行動サービスのウェブサービスは受け取られたリストの未加工行動−状況デュプレを待ち行列１３３に書き込む。つぎに、ステップ６０７において、行動待ち行列マネジャー１３７がリストの内容を調べて各デュプレを抽出し、この後、適切な行動状況プロセッサ１３５を起動してデュプレの処理に使用する。

ステップ６０９において、具体的なプロセッサ１３５がそのデュプレ内の個々の行動ファクターを抽出する。ほとんどの場合、単一のデュプレが多数の行動ファクターに変換される。

つぎに、ステップ６１１において、これらの行動ファクターの各々は、１つ又は複数の知識実体に分解される。ステップ６１３において、行動状況プロセッサ１３５は、これらの知識実体を試験中のデュプレからの状況オブジェクトと組み合わせて行動アトムを生成する。ステップ６１５において、行動アトムは、行動アトムデータベース１４３に書き込まれる。さらに、行動状況プロセッサ１３５は、ステップ６０１において受け取られた最初の未加工行動−状況デュプレを未加工行動状況データベース１３９に格納する。ステップ６１９において、行動状況プロセッサ１３５は、さらに、抽出された知識実体（ステップ６１１参照）を知識実体データベース１４１に格納する。プロセスはステップ６２１において終了する。

Ｄ．状況情報の追加収集（クライアント側）
前述のように、図５のフローチャートに示されたプロセスと独立に状況情報を収集することが望ましいことがあり、その場合、このような収集は未加工行動の発生によってトリガーされる。トリガー行動と独立の状況情報の収集によって、一定の状況における、ある行動の欠如をモデル化できることになり、このことは加入者デバイスを行動情報としてカスタマイズするためにも同様に有用でありうる。したがって、図７は、図５（これは、未加工行動の検出に応答して状況情報を収集することに関係する）のフローチャートに示されるプロセスから独立した状況情報を収集するクライアント側ソフトウェアの第２の処理を示す。

ステップ７０１において、状況サービス１１０は、状況リスナー１０７を呼び出して状況情報を収集する。ステップ７０３において、状況リスナー１０７は、状況ファクターを検知して収集すべき状況データを決定し、この後、それを収集する。ステップ７０５において、状況リスナーは、収集されたデータを状況サービスに報告し、状況サービスは、この後、状況オブジェクトを生成する。ステップ７０７において、状況サービスは、状況オブジェクトをサーバ側ソフトウェアに送る。このプロセスはステップ７０９において終了する。

Ｅ．状況オブジェクトの処理（サーバ側）
図８は、クライアント側ソフトウェア（図４に示されるプロセスのステップ４１３において送られるような）から状況オブジェクトを受け取ることに対応するサーバ側動作を示す。ステップ８０１において、状況オブジェクトは、クライアント側ソフトウェアから受け取られる。ステップ８０３において、状況サービス１２２におけるウェブサービス１７１は、状況を処理するために呼び出される。ステップ８０５において、状況サービスのウェブサービス１７１は、状況オブジェクトを状況待ち行列１７３に書き込む。ステップ８０７において、状況待ち行列マネジャー１７５は、待ち行列１７３から状況オブジェクトを捕捉し、これを「展開」して独立した状況ファクターを抽出する。ステップ８０９において、待ち行列マネジャー１７５は、状況オブジェクト内でタイムスタンプをキーとして利用して各状況ファクターに対して独立した記録状況ファクターオブジェクトを生成する。

ステップ８１１において、状況待ち行列マネジャー１７５は記録状況ファクターオブジェクトを記録状況ファクターデータベース１７９に書き込む。このプロセスはステップ８１３において終了する。

Ｆ．行動モデルの生成（サーバ側）
図９は、行動モデルを生成するモデラーサービス１１８に関連するプロセスの流れを示す。これは、収集された行動及び状況情報から行動モデルを生成するプロセスであり、これによって、推論クエリは、応答、たとえば、状況に基づく１つ又は複数のユーザの好み（具体的なレバーに応じた）を得るために動作しうる。ステップ９０１において、モデルサービス１１８のスケジューラ１５１は、タスク１５７を呼び出し、さらに、モデル構成データベース１５３を閲覧して、行動モデルを生成するために使用される特定のモデル構成１５５を検索する。つぎに、ステップ９０３において、タスク１５７は、行動アトムデータベース１４３から適切なデータセットを検索し、このデータセットを行動モデラー１１９に渡す。ステップ９０５において、行動モデラー１１９は行動モデルを生成する。ステップ９０７において、タスク１５７は、上記の生成された行動モデルを行動モデル・データ・ストア１２０に格納させる。このプロセスはステップ９０９において終了する。

Ｇ．推論クエリの定式化（クライアント側）
図１０は、推論クエリの生成とサーバ側のソフトウェアへの伝達のための一例示的実施形態に従うクライアント側のソフトウェアのプロセスの流れを示す。ステップ１００１では、自動的又は何らかのユーザの行為のいずれかにより事象が発生し、それが関連するレバー１０８を起動する。たとえば、レバーが無線ＰＤＡの待ち受け画面のペインターである場合、このレバーは、デバイスのディスプレースクリーンを待ち受け画面のイメージで塗る必要があって、ユーザがＰＤＡを休止モードから起こすためにボタンを押すことであってよい。ステップ１００３では、レバー１０８は推論サービス１１１を呼び出す。ステップ１００５では、推論サービス１１１は状況サービス１１０を呼び出す。ステップ１００７では、状況サービス１１０は状況オブジェクト（図４との関連で上述された）を生成する。ステップ１００９では、状況サービス１１０状況オブジェクトを推論サービス１１１に戻す。ステップ１０１１では、推論サービス１１１は推論クエリを生成するために状況オブジェクトをレバー情報と組み合わせる。ステップ１０１３では、推論サービス１１１は推論クエリをサーバ側のソフトウェアに送り出す。このプロセスはステップ１０１５で終了する。

Ｈ．推論クエリ応答の生成（サーバ側）
図１０はクライアント側のソフトウェアからの推論クエリの受け取りに応答するサーバ側のプロセスの流れを示す（すなわち、図１０のステップ１０１３）。ステップ１１０１では、サーバ側のソフトウェアがクライアント側のソフトウェアから推論クエリを受け取る。ステップ１１０３では、推論サービス１２１のウェブサービス１６１が起こされる。ステップ１１０５では、ウェブサービス１６１が推論クエリを推論サービス待ち行列に書き込む。

次に、ステップ１１０７では、クエリスレッド１６５が呼び出され、適当なモデル構成を参照するために、推論クエリ内でモデルの名前を使用する。ステップ１１０９では、推論サービス１２１は、新しいデータポイントを空の行動実体とともに生成するためのガイドとして構成を使用する。ステップ１１１１では、クエリスレッド１６５は、最近同じデバイスからの同じ推論クエリを情報提供したかを決定するために、最初に推論サービス待ち行列１６３を確認する。そうであった場合、フローはステップ１１１３に進み、ここで対応する推論クエリ応答が推論クエリキャッシュ１６７から検索される。ついで、フローはステップ１１１５に進み、ここで推論クエリ応答が要求クライアント側のソフトウェアへ返される。このプロセスはステップ１１１７で終了する。

もし、一方で推論クエリが推論クエリキャッシュ１６７の中に見出されない場合、かわりにフローはステップ１１１１からステップ１１１９に進む。ステップ１１１９では、推論サービスは、この特定の推論クエリのための適切なモデルを検索するために、前述のモデルの名前及び行動実体の名前を用いて行動モデル・データ・ストア１２０に行く。次に、ステップ１１２１では、推論クエリへの回答を得るために、推論サービス１２１は前記モデルを起動して、このモデルの中でデータポイントを空の行動実体とともに稼動させる。次に、ステップ１１２３では、推論サービス１２１は推論クエリ応答を生成する。

ついで推論クエリ応答を要求クライアント側のソフトウェアに返すために、フローはステップ１１１５に進む。このプロセスはステップ１１１７で終了する。
このようないくつかの本発明の特定の実施形態を記載したが、当業者はさまざまな変更、修正、及び改良を容易に思いつくであろう。
この開示により明白にされたそのような変更、修正、及び改良は、ここで明示的に言明されてはいないが、この明細書の一部となることが意図され、及び本発明の精神と範囲に含まれることが意図されている。したがって、上述の記載は、単に例示のためのものであって、本発明を限定するものではない。本発明は、以下の請求項とその等価物において定義されるたようにのみ限定される。

Claims (22)

1. デバイスの状況の関数としてのデバイスの挙動を、少なくともそのデバイスの使用者の状況の関数としての行動の観察に基づいて修正する方法であって、
   デバイスに関連する状況情報を追跡すること、
   デバイスのユーザのデバイスに関連する行動情報を追跡すること、
   デバイスに関連するユーザの行動が示されたときの状況を決定するために、行動情報と状況情報を関連付けること、
   追跡した状況情報及び追跡した行動情報に基づいて、デバイスのユーザの、状況の関数としてのデバイスに関連する将来の行動の予測モデルを生成すること、並びに
   デバイスに関連する状況情報の関数としてのデバイスの動作に基づいて調整することを含む方法。
2. 前記状況情報の追跡が、所定のトリガー事象の生起についての状況情報の例を収集することを含み、
   前記行動情報の追跡が、ユーザのデバイスとの相互作用の例を収集することを含み、及び
   前記関連付けることが、行動情報の例について、行動情報の例の収集に先立つ最も新しい状況情報の例を検索することを含む、請求項１に記載の方法。
3. 前記行動情報の追跡が、ユーザのデバイスとの相互作用の例を検出すること、及びユーザの相互情報の行動情報の例を保存することを含み、並びに
   前記状況情報の追跡が、ユーザのデバイスとの相互作用の例の検出に応答する状況情報の例を収集することを含む、請求項１に記載の方法。
4. 前記デバイスがネットワーク上のノードであり、さらに状況情報の追跡及び行動情報の追跡がこのデバイスで遂行され、前記生成することがこのネットワークの別のサーバノードで遂行されるネットワーク環境内で前記方法が遂行され、
   状況情報及び行動情報がこのネットワークを介して前記サーバノードに伝達されることをさらに含み、
   前記調整することが、
   デバイスについての状況情報の例を含むデータセットを予測モデルに適用すること、
   状況情報の例を含むデータセットの関数としての予測されたユーザ行動を予測モデルから決定すること、並びに
   デバイスの作動パラメータを予測行動に基づいて調整することを含む、請求項２に記載の方法。
5. 前記デバイスの作動パラメータがデバイスの待ち受け画面のディスプレーの構成を含む、請求項４に記載の方法。
6. 前記予測モデルが、行動情報及びネットワーク上の他のデバイスの他のユーザの対応する状況情報の関数として生成される、請求項４に記載の方法。
7. 追跡された行動情報が、特定の状況での行動の欠如をさらに含む、請求項６に記載の方法。
8. 前記デバイスが複数のデバイスを含み、前記調整することが、第二のデバイスについて収集される情報に基づいて第一のデバイスの作動を調整することを含むことができる、請求項４に記載の方法。
9. 予測モデルを生成するための複数のモデリングアルゴリズムを提供すること、及び
   デバイスについての状況情報の例を含むデータのセットの関数として、１つのモデリングアルゴリズムを選択することをさらに含む、請求項４に記載の方法。
10. 予測モデルを生成するための複数のモデリングアルゴリズムを提供することをさらに含み、及び
    前記調整することが、
    デバイスについての状況情報の例を含むデータセットを少なくとも２つの予測モデルに適用すること、
    少なくとも２つの予測モデルのそれぞれから、状況情報の例を含むデータセットの関数としてのユーザの予測行動を決定すること、
    少なくとも２つのモデルから、よりよい予測行動を与えるものを１つ選択すること、及び
    デバイスの作動パラメータを選択された予測行動に基づいて調整することを含む、請求項４に記載の方法。
11. デバイスの状況の関数としてのデバイスの挙動を、少なくともそのデバイスのユーザの状況の関数としての行動の観察に基づいて修正する方法であって、
    デバイスに関連する状況情報を追跡すること、
    デバイスに関連するデバイスのユーザの行動情報を追跡すること、
    対応する状況情報の例と組み合わされた知識実体を含む行動アトムを生成し保存すること、
    状況の関数としての、デバイスのユーザの将来のデバイスに関連する行動の予測モデルを生成すること、
    組織化されたデータポイントのセットを生成するために、モデリングアルゴリズムを前記行動アトムに適用すること、
    行動情報を含まない状況情報のセットを含む空のデータポイントを生成すること、
    空のデータポイントを前記モデルに適用することにより、デバイスのユーザの予測行動を生成すること、及び
    予測行動の関数としてのデバイスの作動を調整することを含む方法。
12. 前記予測行動を生成することが、トリガー事象に応答して遂行され、
    トリガー事象を検出すること、及び
    前記トリガー事象に応答して状況情報の例及び予測されるべき少なくとも１つの行動タイプを含む推論クエリを生成することをさらに含み、
    前記推論クエリ中で特定される前記行動タイプの予測行動の生成が、前記推論クエリに応答して遂行される、請求項１１に記載の方法。
13. 推論クエリの記憶及びそれに対する回答を維持し、
    推論クエリへの回答による予測行動の生成に先立ち、推論クエリの記憶を確認して、同様の推論クエリが以前に情報提供されたかを決定するためにそれに回答し、及び
    同様の推論クエリが以前に情報提供されていた場合、対応する推論クエリ応答を用いることをさらに含む、請求項１２に記載の方法。
14. 前記推論クエリが、推論クエリに対する回答を生成するために用いられる予測モデルのアイデンティティをさらに含み、及び推論クエリにおいて特定される予測モデルが推論クエリ応答を生成するために用いられる、請求項１２に記載の方法。
15. デバイスの状況の関数としてのデバイスの挙動を、少なくともそのデバイスのユーザの状況の関数としての行動の観察に基づいて修正する方法であって、
    デバイスの使用の複数の例を含む行動情報を収集すること、
    その各状況が、以後、状況オブジェクトと称される、デバイスの使用の複数の例の１つの例に対応するデバイスの状況の複数の例を含む状況情報を収集すること、
    デバイスの使用の例を対応する状況オブジェクトとともに含む行動−状況デュプレを生成すること、
    それぞれの行動−状況デュプレから行動因子を抽出すること、
    それぞれの行動因子を少なくとも１つの知識実体に変換すること、
    それぞれの知識実体を、その知識実体が導出された行動−状況デュプレの状況オブジェクトと組み合わせること（この組み合わせは、以後、行動アトムと称される）、
    前記行動アトムから、行動アトムから導出された複数のデータポイントを含むデバイスに関連する使用行動の予測モデルを生成すること、
    状況オブジェクトを含む推論クエリを生成すること、
    推論クエリから、状況オブジェクトを含む空のデータポイントを生成すること、
    状況オブジェクトの関数としてのデバイスのユーザの推測行動を含む推論クエリ応答を生成するために、空のデータポイントを予測モデルに適用すること、及び
    推論クエリ応答の関数としてデバイスの作動を修正することを含む方法。
16. 推論クエリ及び対応する推論クエリ応答を記憶し、
    推論クエリの生成に応答して、同様の推論クエリへの推論クエリ応答が以前に記憶されているかを決定すること、及び
    同様の推論クエリが以前に記憶されている場合、即時の推論クエリへの推論クエリ応答を生成するために、以前に記憶されている推論クエリに対応する推論クエリ応答を用いることをさらに含む、請求項１５に記載の方法。
17. 状況の関数としてのデバイスに関する行動の欠如（以後、、空の状況オブジェクトと称される）を追跡する目的で、デバイスの付随する使用にかかわりなく状況オブジェクトを収集すること、及び
    前記モデルのための追加データポイントを生成するために、行動−状況デュプレと同様に空の状況オブジェクトを処理することをさらに含む、請求項１５に記載の方法。
18. 前記推論クエリが、
    サーバにおいて複数の予測モデルを提供し、及び
    対応する推論クエリの関数として予測モデルを１つ選択する、請求項１５に記載の方法。
19. 前記推論クエリが、さらに推論クエリと関連して用いる予測モデルの１つのアイデンティティをさらに含む、請求項１８に記載の方法。
20. 前記デバイスが複数のデバイスを含み、及び前記修正することが、第二のデバイスについて収集された情報に基づいて、第一のデバイスの作動を修正することを含む請求項１５に記載の方法。
21. 自発的行動が示される状況を、少なくともデバイスのユーザの状況の関数としての行動の観察に基づいて予測する方法であって、
    デバイスに関連する状況情報を追跡すること、
    デバイスに関連するデバイスのユーザの行動情報を追跡すること、
    デバイスに関連するユーザの行動が示される状況を決定するために、行動情報を状況情報と関係付けること、
    追跡した状況情報及び追跡した行動情報に基づいて、状況の関数としてのデバイスのユーザの将来のデバイスに関連する行動の予測モデルを生成すること、及び
    前記予測モデルに基づいて、デバイスに関連する行動の関数としてのデバイスのユーザの状況を予測することを含む方法。
22. 前記状況情報を追跡することが状況情報の例を収集することを含み、
    前記行動情報を追跡することが、ユーザのデバイスとの相互作用の例を収集することを含み、
    前記関係付けることが、行動情報の例について時間的に対応する状況情報を検索することを含み、並びに
    前記予測することが、
    デバイスに関連する行動情報の例を含むデータセットを予測モデルに適用すること、及び
    予測モデルから、行動情報の例を含むデータセットの関数としてのデバイスの状況情報の予測されたセットを決定することを含む、請求項２１に記載の方法。

Images