JP4620721B2 - コンテキストデータのセマンティック分類を自動的に決定する方法及び装置 - Google Patents

Description

本発明は、コンテキストデータに対するセマンティック分類を自動的に決定する方法及び装置に関する。

コンテキストアウェアモバイルアプリケーションでは、多くの異なるタイプのコンテキスト情報をセンサから収集することができる。これらのセンサのほとんどは、温度、速度、または脈拍数を表す整数値及び浮動小数点値といった定量データを提供する。しかし技術のクオリティが高まり、このような生のコンテキストデータを収集して共有することから、その適切な解釈へと課題がシフトしている。データのパターン、類似性（similarity）及び傾向を検出するために機械学習の技術が適用されているが、この推論（infer）されたデータをどのように解釈するかという問題は未解決である。

これまでのところ、既存の解決策は、後の参照のために生のコンテキストデータに対してあるキーワードをタグ付けするだけに終わっている。一例として、地球上の特定の位置または特定の写真にタグ付けをして検索及びカテゴリー分類を可能にする実例としてGoogle Earth（http://earth.google.com参照）とFlickr（http://www.flickr.com参照）とが挙げられる。しかしながら、特定の地理位置（geo-locations）のタグに関する問題は、地理位置がＧＰＳまたは既知のビーコンから得られる場合にのみ、正確な位置（location）という意味で場所（place）が検出できるという点である。未知のビーコンによって指定される位置に関しては他のオプションを調べる必要がある。

他方、一般的なクラスタリング技術及び類似性検出もコンテキストデータストリームに対して適用されている（例えば非特許文献１参照）。しかし、斯かる技術は、クラスタの識別と実際の意味（meaning）というよりも、クラスタの検出により焦点を当てている。また未確認のコンテキストクラスタについては、例えばユーザの行動をそのクラスタに関連付けるためになお使用することができ、将来のリコメンデーションをユーザの行動の履歴に基づいて行うことができる。これに関する最も身近な例は、現在のコンテキストクラスタにおける使用履歴に基づいてブラウザのメニューまたはお気に入りの中でアプリケーションに優先順位を付けて順番に並べることである。
Flanagan, J A., Unsupervised clustering of context data and learning user requirements for a mobile device, in Proceedings of the 5th Conference on Modeling and Using Context (CONTEXT-05), pages 155-168, 2005

しかしながら、携帯機器においてコンテキストデータをクラスタリングし、自動的にネーミングする技術であって、ユーザによって行われるデータの「実世界（real-world）」タギングに似た直感的なネーミングアプローチをサポートする技術はまだ知られていない。

一実施形態によれば、ある携帯機器が１つ以上のコンテキストデータストリームを時間とともに（over time）サンプリングするステップと、
サンプリングされたコンテキストデータにおいて１つ以上のクラスタを特定するためにクラスタリングアルゴリズムを適用するステップと、
一連の所定の概念名（concept name）からある概念名を、１つ以上の前記クラスタのセマンティック分類として、自動的に決定するために推論エンジンを実行するステップと、
１つ以上の前記クラスタへ前記概念名を割当てるか、またはその割当てをユーザに提案するステップと、
前記推論エンジンを用いて状況に応じた推論を適用するステップであって、論理表現によりある概念名が割当てられている１つ以上の概念化されたクラスタを組み合わせ、ある概念名により表現されたタイプに属するものとして前記ユーザの状況を前記推論エンジンが自動的に分類できるようにし、これによって前記クラスタリングアルゴリズムにより見つかったクラスタの概念名または概念名の提案を決定するステップと
を含む、携帯機器によって得られたコンテキストデータに対してセマンティック分類を自動的に決定する方法が提供される。

クラスタリングを適用することにより、サンプリングされたデータに対してクラスタが決定されて、そのクラスタに名前が付けられる。このため推論エンジンは、名前が付けられていないクラスタの概念名を決定するために、既に名前が付けられたクラスタの概念名に基づいて論理的な推論を適用する。

推論エンジンは、受信した情報に基づいて所与の一連の公理の全ての結果を計算することができる。ここで、受信した情報は既に名前が付けられたクラスタの概念名とすることができる。次に斯かる概念名は、推論エンジンによって論理表現（logical expression）へ組み合わせることでき、それにより、名前が付けられていないクラスタの概念名に対する結論（conclusion）が得られる。

このようにして、名前が付けられていないクラスタの概念名は、既に名前が付けられているクラスタの概念名に基づいて決定することができる。決定された名前はユーザに提案することができ、あるいはクラスタに名前を付けるために自動的に使用することができる。

このようして、ユーザの行動を自動的に分類することができる。そして、ユーザの複数の状態または状況（位置、時間、他のコンピュータなどの他の機器との接続、ネットワーク、携帯電話基地局、オフィス環境）は、状況の高水準な記述または名付けるパラメータである「概念名」を用いて自動的に分類することができる。携帯機器はこのようにして高水準記述である概念名を使ってユーザの多くの状態を記述することにより、自動的にユーザの多くの状態をカテゴライズすることができる。ユーザがある概念名によって記述される状況にいる場合、この情報は例えばそれに基づいて結論を導くことができる他のユーザまたは他の機器にも伝達することができる。

一実施形態によれば上記方法は、ある形式言語（formal language）に関してクラスタコンテキストストリームに由来する既に名前が付けられたクラスタの概念名によって表された実際の定性的コンテキスト情報を組み合わせることによって名前が付けられていないクラスタの概念名を決定し、それにより名前が付けられていないクラスタの概念名を決定するために、前記推論エンジンを用いるステップを更に含む。

一実施形態によれば、上記方法は、名前が付けられていないクラスタが、既に名前が付けられた１つ以上の他のクラスタと１つ以上の座標において部分的または全体的にオーバーラップまたはインターセクトする場合に、前記名前が付けられていないクラスタの概念名を決定するステップであって、前記既に名前が付けられたクラスタの概念名を入力として用いて１つ以上の前記既に名前が付けられたクラスタの概念名を前記推論エンジンが論理的に組み合わせ、前記推論エンジンが公理を適用して前記名前が付けられていないクラスタの概念名を決定するステップを更に含む。

一実施形態によれば、前記携帯機器は複数のコンテキストデータストリームをサンプリングするものであり、
サンプリングデータは、コンテキスト状態ベクトルのベクトル成分が前記複数のコンテキストデータストリームの１つに対応するものとなるようにコンテキスト状態ベクトルを求める（populate）ために使用されるものであり、
前記サンプリングは定期的な間隔で実行されるものであり、
各サンプリングは、サンプリングされた値により求められた対応するコンテキスト状態ベクトルを生じさせるものであって、
コンテキスト状態ベクトルにより張られるクラスタを得るために、サンプリングされた一連のコンテキスト状態ベクトルに対して前記クラスタリングアルゴリズムを実行するステップを更に含む。

一実施形態によれば、前記クラスタリングアルゴリズムはマルコフ（Markov）クラスタリングアルゴリズムを含む。

一実施形態によれば、前記クラスタリングアルゴリズムによって見つけられたクラスタに対し、そのクラスタにおけるユーザの全滞在時間がある閾値を超える場合は、名前が付けられるかまたはユーザにネーミングが提案される。

一実施形態によれば上記方法は、前記クラスタに名前を付けるために使用することができる一連の定性的な表現の概念名を含むオントロジーを提供するステップと、
前記クラスタリングアルゴリズムから得られたクラスタを定義するパラメータを前記推論エンジンが受信するステップであって、該推論エンジンはどの条件に基づいてどの概念名をクラスタへ割当てるべきかに関するナレッジを有するものである、ステップと、
クラスタを定義する前記パラメータを前記推論エンジンが処理して、前記クラスタに対する概念名の提案を前記推論エンジンが返信するステップと
を更に含む。

一実施形態によれば、前記処理するステップは、前記クラスタを定義するパラメータに基づいて、どのルールが満たされていて、結論として概念名を得るためにどの結論を導くべきかを決定するために、一連のルールを参照するサブステップを含む。

一実施形態によれば、前記処理するステップは、前記クラスタが距離測定に基づいてある閾値を伴う近傍に他のクラスタを有する場合で、かつ前記他のクラスタ間である閾値を超えた尤度（likelihood）である概念名が選ばれている場合に、前記クラスタに実際に名付ける概念名として該概念名を提案するサブステップを含む。

一実施形態によれば上記方法は、一般的なワールドナレッジと、ある形式言語に関してクラスタコンテキストストリームに由来する実際の定性的なコンテキスト情報とを形式化することにより実現されるコンテキストモデルを提供するステップと、
受信した前記コンテキスト情報に基づいて所与の一連の公理の全ての結果（consequece）を計算することができる推論エンジンを提供するステップと
を更に含む。

一実施形態によれば上記方法は、論理表現によりある概念名が割当てられている１つ以上のコンテキスト要素又は１つ以上の概念化されたクラスタのうち少なくとも１つを組み合わせることによって状況に応じた推論を適用し、利用可能なコンテキスト情報に基づいてある概念名により表現されたタイプに属するものとして前記推論エンジンがユーザの状況を自動的に分類するステップを更に含む。

これにより、検知されたコンテキストデータに基づいて、状況に応じた推論（situational reasoning）が可能となる。

一実施形態によれば上記方法は、自動分類を適用して新たに割当てられた名前が概念空間（concept space）に加えられた場合に、該新たに割当てられた名前がオントロジー内で既にコード化されたナレッジに関してつじつまが合う（make sense）かどうかをチェックするためにコンシステンシーチェックを実行するステップを更に含む。

コンシステンシーチェックは、ユーザがワールドナレッジ全体を自己矛盾のない状態に保つのに役立つ。

一実施形態によれば、前記携帯機器は異なる複数のコンテキストデータストリームを受信するものであり、
コンテキストデータストリームごとに独立なクラスタを得るために、異なる前記コンテキストデータストリームに対してクラスタリングを独立に実行するステップを更に含む。

一実施形態によれば上記方法は、クラスタに割当てられた１つ以上の概念名により与えられたものとして前記携帯機器のユーザの定性的コンテキストを定性的コンテキスト履歴ストレージに記憶することにより、該定性的コンテキストを追跡するステップを更に含む。

一実施形態によれば上記方法は、
定性的コンテキスト履歴をクエリするかまたは解析するためのインタフェースを提供するステップと、
定性的に追跡されたユーザコンテキストの履歴に基づいて新たなドキュメントまたは情報の集合を生成するステップと
を更に含む。

一実施形態によれば上記方法は、
ある時間におけるユーザのコンテキストを示す概念名を監視することにより、ユーザのコンテキスト状況を監視するステップと、
１つ以上の概念名により示されたユーザのコンテキスト状況が、特定の定性的コンテキストを特定する所定の条件を満たす場合に、該ユーザの携帯機器により実行されるアクションをトリガするステップと
を更に含む。

一実施形態によれば上記方法は、
前記携帯機器の特定のモードまたは機能を起動することと、
通知または警告を送信することと、
類似した定性的コンテキストにおけるユーザをアドホックグルーピングすることと、
定性的コンテキストに基づいてユーザデータへ自動的なアノテーションを付加することと、
定性的に追跡されたユーザコンテキストの履歴に基づいて新たなドキュメントを自動生成することと
を含む。

一実施形態によれば、ある携帯機器が１つ以上のコンテキストデータストリームを時間とともに（over time）サンプリングするための手段と、
サンプリングされたコンテキストデータにおける１つ以上のクラスタを特定するためにクラスタリングアルゴリズムを適用する手段と、
一連の所定の概念名からある概念名を、１つ以上の前記クラスタのセマンティック分類として、自動的に決定するために推論エンジンを実行させる手段と、
前記概念名を１つ以上の前記クラスタへ割当てるか、またはその割当てをユーザに提案する手段と、
前記推論エンジンを用いて状況に応じた推論を適用する手段であって、論理表現によりある概念名が割当てられている１つ以上の概念化されたクラスタを組み合わせ、ある概念名により表現されたタイプに属するものとして前記推論エンジンがユーザの状況を自動的に分類できるようにし、これによって前記クラスタリングアルゴリズムにより見つかったクラスタの概念名または概念名の提案を決定する手段と
を備える、携帯機器によって得られたコンテキストデータのセマンティック分類を自動的に決定する装置が提供される。

一実施形態によれば、本発明の一実施形態に基づく方法として機能する手段を備える装置が更に提供される。

一実施形態によれば、本発明の一実施形態に基づく方法をコンピュータに実行させるプログラムコードを含むコンピュータプログラムが更に提供される。

以下、本発明の実施の形態について添付図面を参照して詳細に説明する。

本発明の実施形態によれば、エンドユーザは、機械学習の結果を簡単な方法でフォーマルナレッジベースへリンクすることにより、機械学習の結果に対してセマンティックな意味（semantic meaning）を割当てることができる。このようにして、推論された結果は、アプリケーションに対してそれらの動作を自動的な方法で適応させることができるよう解釈できるものとなる。そして、人間にとっては、例えば位置、身体データまたは現在のタスクなどのコンテキスト情報について定性的に話し、考えることができるよう解釈可能なものとなる。この後者のポイントは、あるユーザに対して現在のコンテキストを次のように尋ねることで非常に明確となる。
・「あなたはどこにいますか？」と尋ねられたら、「オフィスにいます」と答え、「私の所在はベーカー通り１０番です」とは答えない。
・「あなたの脈拍数はいくつですか？」と尋ねられたら、「高い」または「低すぎる」と答え、「７９ｂｐｍです」とは答えない。
・「何をしていますか？」と尋ねられたら、「エレベータで食堂に向かっています」と答え、「私の加速度は−１．３ｍ／ｓ²」とは答えない。

しかし、人間にとって定量的な情報から定性的な情報へのこうした変換がどんなに簡単ではあっても、自動化されたシステムにとってはこうした人間の能力にアプローチすることは至難の業である。

一実施形態によれば、上記の問題に対する解決法は次のようなことをカバーする。
・エンドユーザにとって価値と意味のあるコンテキストクラスタを与える機械学習アルゴリズムを提供する。一実施形態におけるクラスタリングは、コンテキスト情報の限られた時間窓とともにインクリメント方式で機能する。一実施形態におけるクラスタリングは経時的に劣化せず、クラスタの結合（joining）を可能にし、そしてユーザフィードバックに基づいて学習することができる。
・ユーザ入力に基づいて経時的に適応及び拡張する最も重要な概念をカバーするオントロジーを提供する。一実施形態におけるオントロジー上の推論（reasoning）は、例えば同等な概念を識別し、場合によっては結合するために、安定性と一貫性を保証する。
・ユーザが容易にクラスタをオントロジーと関係付け、異なるオントロジー概念を容易に閲覧し、検索できるようにする方法及び環境を提供する。
・更なる実施形態によれば、ユーザ間のクラスタリコメンデーションのためのアルゴリズムが提供される。その結果、友達及び仲間の既存のクラスタから新たなクラスタがブートストラップできるか、または名前と分類を転送及びパーソナライズできる。

提案された解決策によれば、ユーザは多次元のコンテキスト状況をオントロジーにおいて定義された概念へリンクすることができる。第１のステップでは、第２のステップにおいてセマンティックネームとリンクされるコンテキストクラスタが計算される。クラスタリングの結果は、図１に示されている後者のネーミングプロセスに影響を与える可能性があるので、これらの２つのプロセスは完全に独立ではない。例えば、クラスタの名前を決定する自動推論エンジンは、クラスタリングプロセスから得られたクラスタを入力として受け取り、続いてクラスタのパラメータに基づいて推論エンジンはそのクラスタにある名前を割当てる。このことは以下の説明からより明らかになる。

図２は、本発明の実施形態に基づくプロセスを説明するフローチャートである。本プロセスは携帯機器上で実行される。まずステップ１００において１つ以上の期間にわたってコンテキストデータをサンプリングする。コンテキストデータは、例えばＧＰＳ情報または携帯電話ネットワークのセルＩＤ情報などの位置情報とすることができる。コンテキストデータの１つ以上のストリームはこのようにしてサンプリングすることができる。

サンプリング期間が終了すると、ステップ１１０において、サンプリングされたデータにおけるクラスタを特定するためにクラスタリングアルゴリズムが適用される。クラスタリングアルゴリズムは公知であり、ステップ１１０では原則として任意のクラスタリングアルゴリズムを適用できる。クラスタリングアルゴリズムを適用すると、コンテキストデータのクラスタが得られる。例えば、１つ以上の特定の位置エリアが１つのクラスタとなって現れたり、または１つ以上のセルＩＤが１つのクラスタとなって現れることがある。このようにして得られたクラスタは、一実施形態によれば他のサンプリング期間で得られたクラスタと組み合せるか、またはマージすることができる。そして、クラスタリングは時間とともに発展する。

クラスタリングステップの後、ステップ１２０において、ステップ１１０で見つかったクラスタの１つ以上に対して概念名（concept name）が決定される。概念名は、サンプリングされたコンテキストパラメータの絶対的な値ではなく、定性的な表現によりクラスタのプロパティを表すラベルとすることができる。後で詳しく説明するが、概念名のこの自動決定は、所定のオントロジーのある特定の概念名がステップ１１０で見つかったクラスタにどの程度の蓋然性で割当てられるかについてのナレッジを表す一連の１つ以上のルールを含む推論エンジンを参照することによって行われる。よって推論エンジンは、ある意味において、クラスタが、名前のオントロジーから得られる定性的な名前タグを使ってどのようにラベル付けまたは「名前付け」されるかについての「ナレッジ」を表す。

ステップ１３０において、ステップ１２０で推論または決定された概念名がクラスタへ割当てられるか、または概念名をクラスタへ割当てるための提案がユーザに対して行われる。

斯かる仕組みによれば、例えば、長期間にわたって自動的に記録された所在（location）の軌跡から、ある人が頻繁に訪れた場所及び頻繁に移動した経路を検出することができる。所在は、ここでは地理位置または部屋番号の点で絶対的に表すことができるほかに、ＧＳＭアンテナ及びBluetoothビーコンのような移動するかまたは固定されたビーコンに対して相対的に表すことができることに留意されたい。多くの場合、ホーム（自宅）とオフィスの所在地は最初に検出されるものの中にある。これらの概念（ホーム及びオフィス）は両方ともフォーマルナレッジにおいてその表現を有するが、クラスタと概念名とを結びつけるための、複雑度と必要なデータ量が異なるいくつかの手法に分けることができる。これらの方法は全て、（例えば、ルールにより表されているか、または例えば公理（axiom）を用いてナレッジの別の機械表現により表されている）ナレッジの表現を利用し、クラスタのパラメータに基づいて（例えば、クラスタのパラメータを入力としてルールを適用することにより）ナレッジエンジンを実行して、一連の概念名の中からどれをクラスタの名前として選択すべきかの結論に到達する推論エンジンを使用するという点で共通している。斯かる推論エンジンを実装するためのいくつかのアプローチが存在している。それらのアプローチの一部を以下に挙げる。
・ルール駆動（rule driven）：経験則によって自動的または半自動的に割当てられる。例えば、あるユーザが日中時間のほとんどを過ごす場所はおそらくそのユーザのオフィスである。
・データ駆動（data driven）：以前の観測データから統計的プロセスによって自動的に割当てられる。例えば、ほとんどのユーザは、ミュンヘン（Munich）のマリエンプラーツ（Marienplatz）周辺のエリアにおけるクラスタに対してダウンタウン（downtown）を割当てた。
・モデル駆動（model driven）：形式化されたバックグラウンドナレッジに基づいて、関係のあるユーザ間で概念の割当てを転送し、場合によっては論理的分類結果に基づいて割当てを完全に自動化するために論理的推論（logical inference）を使用することができる。例えば、ユーザの社会的関係を通して推論することができるものに基づいて、推奨された場所（place）の概念の事前選択がユーザへ提供される。同僚ＡがユーザＢ宅に定期的に訪れるとき、これはある時点でＡに対して「同僚Ｂ宅」として推奨することができる。

推論エンジンが選ぶ概念名の集合はオントロジーの一部とすることができる。コンピュータサイエンスにおけるオントロジーは、概念化（conceptualization）の明示的な仕様（specification）と見なすことができる。それに対し、概念化は表現される世界の抽象的で単純化された見方（view）である。形式的に表現されたナレッジのいずれの部分も斯かる概念化に基づいており、オントロジーは斯かる概念化の仕様である。人工知能のコンテキストでは、一連の表現ターム（representational term）を定義することによりオントロジーを記述することができる。斯かるオントロジーにおいて、表現タームの定義は、エンティティ（本例では「クラスタ」）の名前を、名前が意味するもの（それらの「セマンティック意味（semantic meaning）」）を記述する人間が読取り可能なテキストと、これらのタームの解釈と適格な用途（well-formed use）とを制約する形式的な公理とへ関連付ける。従って形式的には、オントロジーは論理的理論のステートメントと見なすことができる。従って本発明の実施形態では、（概念名の集合を含む）オントロジーはコンテキストパラメータとそれらの意味の世界についてのナレッジを少なくとも部分的に表現する。

一実施形態によれば概念名についての「ナレッジ」は推論エンジンによって実装される。見つかったクラスタのパラメータ（例えば、時間的境界及び地理的位置）を入力として受け取ることにより、オントロジーによって表現された「ナレッジ」が事前に与えられた推論エンジンは、例えば、クラスタの時間的境界が一般的な就業時間内に入ることを決定することができる。それに対応するルールは、例えば、「時間的境界が毎就業日、午前８時から午後６時までで、所与の条件として毎日４時間以上の時間」とすることができ、これらの時間的境界を有するクラスタは「Office」とラベル付けする、と結論付けることができる。斯かる経験則は、他の更なる経験則と一緒に推論エンジンに実装することができる。

別の実装として、例えば、「近傍（close proximity）（一定の距離内）に他のクラスタが（閾値を超えて）かなり多く存在する場合、かつこれらのクラスタの一定の割合以上が同じラベル（例えばダウンタウン）を有する場合、かつこれらのクラスタのエリアがラベル付けすべき新たなクラスタと少なくとも一定のパーセンテージまでオーバーラップする場合には、その新たなクラスタに既存のクラスタの名前を割当てる」とすることができる。このようして、既に述べたデータ駆動型の統計的アプローチを実現することができる。

モデル駆動アプローチも一連のルールで実現することができる。ただ、この場合、モデルはより洗練されたものになることから、一連のルールはより複雑なものとなる。斯かるモデルの実現は単なるルールを超え、機械実装された公理に基づく論理的推論を含むものとすることができる。

別の（非自動）アプローチは概念名の手作業による決定である。この場合、新たに発見されたクラスタ（例えば場所（place））はユーザに通知され、ユーザはオントロジーから対応する概念を選択することによってセマンティックスを提供することが求められる。このアプローチは概念名の自動決定に失敗したり、あるいはユーザが修正する場合に有用である。好ましくは、このアプローチでは、現実的なナレッジベースが複雑になる傾向があるにもかかわらずユーザが含まれるよう、ユーザの相互作用はできる限り便利で自明なものとされる。

ルール駆動アプローチに関しては、システム開発者による適切なルールシステムの手作業による構築が必要である。実施形態と、できるだけ正確かつ完全なルールセットを定めてプログラムする努力とに応じて、概念名決定のパフォーマンスは変わる場合がある。しかしながら、初期段階ではこのアプローチはうまく機能する。

データ駆動アプローチは、大量のデータが既に利用できる場合に確実に機能するにすぎず、従ってブートストラッピングには適していない。

最後に、モデル駆動アプローチは、コンテキストドメインの精密化された論理的モデリングを必要とする。これはモデルを設計して実装するシステム設計者のタスクでもある。

前述の方法論によれば、このアプローチはクラスタの生成と定性的なレベルでのクラスタへの名前の割当てとをサポートすることから、ユーザが位置データを定性的なレベルでやり取りすることがさらに容易になる。自動的なクラスタリングとネーミング推奨（または完全に自動的なネーミング）を通じて、お気に入りの場所の個人的なコレクションを維持することが容易となり、これらはそれらの場所における現実の存在（real presence）及び他の人との社会的関係により決定される。

メンテナンスとソフトウェアの質にプラスの効果があることが知られているコアアルゴリズムから分離したリッチバックグラウンドモデルの使用により得られるフレキシビリティのほかに、形式的なモデリングによれば、所与のコンテキストデータ（及びモデルそれ自体）のコンシステンシーを確認し、洗練された説明技術（explaining technique）を適用することができる。コンシステンシーチェックは、多くの異なるコンテキスト入力と派生した高水準のコンテキストを持つシステムにおいて非常に役立つ。コンフリクトが起こる蓋然性が高いからである。例えば、Bluetoothスキャンによれば、ユーザは自宅にいると考えられるが、一方で、ＧＳＭにより得られた所在は数ブロック離れたところを特定するといったコンフリクトが起こる可能性がある。最も正確な解釈（reading）がこの場合は優先すると説明できる。

次に、更なる実施形態についてより詳しく説明する。

コンテキストクラスタは、次のようなトリプルとして定義することができる。
＜名前、タイプ、仕様＞
ここで名前（Name）はクラスタのユーザ定義名、タイプ（Type）はオントロジーで定義されたその定性的価値を明示する概念の参照、仕様（Specification）は、例えば離散空間における一連のコンテキスト状態ベクトルと追加のメタデータといった、クラスタを定義する全てのコンテキストデータを包含する構造を表す。メタデータは例えば、クラスタのユーザにとっての重要度、またはユーザが該クラスタで既に費やした時間量、またはクラスタをインクリメンタルに更新するために要求される任意の他のパラメータを含むことができる。

次に、場所（places）を定めるために使用することができる位置クラスタ（location cluster）を定義することによって、コンテキストクラスタの抽象的な構成を作る。しかしながら、位置データはここではコンテキストデータの１つの例に過ぎないことに留意されたい。本発明は、医療データ（心拍数など）、経済データ（支出、商品のＲＦＩＤチップからのデータなど）、ある特定の個人（またはその機器）を特定するビーコンのデータ、またはコンテキストデータとしてサンプリングされた他のデータといった、他のコンテキストデータを用いて実施することもできる。

当業者にとってみれば、携帯機器が、例えばＧＰＳ受信機、ＲＦＩＤ機器、またはサンプリングの実行を可能にする他の機器を使ってコンテキストデータをサンプリングすることができることは明らかであろう。サンプリングされたデータの処理は、携帯機器または遠隔のコンピュータによって実行することができる。

次に、コンテキストデータとして位置データ（location data）または「場所（place）」のデータの使い方について説明する。場所を特徴付ける様々な方法が存在するが、それらは多くの場合、互いに両立できない。それゆえ、タグ付け及びクラスタリングに使用される場所概念（place concept）を定義することが重要である。あらゆる定義はそれ自身の有利な点と不利な点とを有しており、１つの定義から別の定義への変更にはかなりの実施コストが伴い、データも両立せず、その結果、運用システムにおいてデータが損なわれる恐れがあるからである。

本実施形態では、場所の、第３次元を除いた２次元（２Ｄ）の分類に焦点を置く。定義された全ての場所は地球表面と一致すると仮定する。これは第３次元（高度、海抜、または階）を検出するための自動的な方法はあまり精度がよくなく、従って信頼度が低いという事実による。これは市街地におけるＧＰＳを用いた高度検出と、WiFiまたはBluetoothなどのビーコンベースの技術を用いた階数検出（floor detection）との両方に当てはまることである。この結果として、以下に説明する場所概念は、スカイタワーにおける２つの階を区別することができないか、あるいは城（castle）とその下の地下室とを区別できないことである。しかしながら、斯かるコンテキスト情報が高い信頼度で得られる場合、その概念はこのコンテキストデータも使用するよう拡張できる。

しかしながら、２次元だけを考えても、多くの異なる場所の定義が存在する。
１．ピンポイント（Pinpoint）−地理的位置（緯度、経度）だけで表される位置（度、度）
２．円（Circle）−ある半径を持つピンポイント（緯度、経度、半径）によって表される位置（度、度、メートル）
３．矩形（Rectangle）−南東のピンポイントと北西のピンポイントとで表される位置（ピンポイント、ピンポイント）
４．矩形群（Rectangles）−均一な矩形の集まり（rectangle［］）
５．多角形（Polygon）−一連のピンポイントにより定まる多角形で取り囲まれた領域（pinpoint［］）
６．ビーコン（Beacon）−ビーコンＩＤで定まる無線ビーコン（ＧＳＭ、ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ）によりカバーされる領域
７．ハイブリッド（Hybrids）−上記定義１〜６の集まりによって特定される領域。例えば領域（４）と一連のＧＳＭビーコン（６）とが集まった領域

図３は、異なる場所の概念を視覚化した図である。

各概念はそれ自体の有利な点と不利な点のほかに用途を持つ。以下、各概念を説明する。
（１）ピンポイントは、ユーザの簡易な手作業による場所（place）のタグ付けに有用である。これは距離または領域を推定（estimate）する人的スキルを要求せず、位置（location）のシンプルなピンポイントは十分である。精度推定（accuracy estimation）が欠落しているので、自動化の目的にはこれはあまり適していない。しかしながら、複数のユーザが同じ場所概念のピンポイントを提供することにより（事後的かつ増加する精度で）精度を得ることができる。
（２）円は、一定の精度で位置、例えばＧＰＳ受信機から得られる位置を提示する論理的方法である。オーバーラップが避けられないことから、より複雑なエリアをより小さな円の集まりとして提示することはあまり実現性がない。経度・緯度のあるペアが１つの円でカバーされる場合、あまり計算効率はよくない。
（３）矩形は、ピンポイントの集まりの最小の入れ物（container）を計算する論理的方法である。これは包含関係を計算する非常に有効な方法であり、矩形の集まりによって連続エリアを画定するために容易に使用することができる。場合によっては矩形の集まりは１つのより大きな矩形として表すことができることから、データを削減することができる。
（４）矩形群は、必ずしも連続的でないエリアを記述するフレキシブルで計算効率の高い方法である。包含計算（containment computation）は矩形の数に比例するが、圧縮によってもっと効率的にすることができる。全ての矩形がアトム矩形（atom rectangle）の整数倍である場合に最良の結果が得られる。アトムの大きさは粒度（granularity）を決定する。これは人間が適応するにはそれほど容易でないが、コンピュータ生成されたエリアには最適である。
（５）多角形は、連続エリアを記述するフレキシブルで直感的な方法である。人間が適応するには容易であるが、ピンポイントまたは円の集まりに対する最小の入れ物となる多角形を形成することはより複雑である。最悪ケースのシナリオでは、多角形の形状は非常に複雑になり、閉じ込め計算は多角形のノード数に比例する。これは多くのノードが存在するコンピュータ生成されたエリアにはあまり適さない。
（６）ビーコンは、ビーコンの信号が受信できるポジションによって定まる不定形エリアである。包含関係（containment relation）は非常にシンプルであるが、他の地理ベースの位置への変換はより複雑で、他のサンプルにも基づく。
（７）ハイブリッドは、基礎の技術及び利用できるデータにあまり依存しないエリアを表現するための強力な方法である。ハイブリッドな場所（place）内における存在は、基礎の技術（ＧＳＭ、ＧＰＳ、ＷｉＦｉ）の１つが（一時的に）利用できなくとも検出可能である。

上記の理由から、一実施形態として、本例ではハイブリッドプレース概念（hybrid place concept）を利用する。ここで、場所（place）は、ビーコンの一連のカバーエリアと一連の矩形群との組み合わせとして表現される。それゆえ、場所の構成と動的な拡張が容易であり、包含計算は計算効率が良い。場所のより複雑な人間の適応と（実行時間中は変更が難しい）所定の粒度を犠牲にすれば、場所をコンピュータベースで生成することは容易である。

一実施形態によれば、位置クラスタリングは、あるクラスタリングアルゴリズムを適用することにより、経度と緯度で表された誰かの地理的位置の軌跡を２Ｄで視覚化したものからピークを探し出すステップを含む。しかしながら、別の実施形態では、コンテキストデータのより複雑な集合が使用することができる。この場合、（１）ストリームの１つが一時的に欠落した場合にシステムをより頑強なものにするため、（２）異なるコンテキスト状況、例えば、「オフィスで仕事中」と「市内でディナー後にオフィスのそばを通り過ぎるとき」とを区別するために、例えば位置クラスタリングはいくつかのコンテキストストリームを含む。

上記の実施形態において、以下のようなコンテキストデータストリームが存在する。
・緯度と経度で表された地理的位置。これはＧＰＳセンサから直接得られるか、または検出された静的ビーコンの既知のポジションから間接的に得られる。
・検出されたビーコンまでの近さで表された相対的位置。これはＧＳＭアンテナまたはＷｉｆｉアクセスポイントとすることができるが、検出された友人の電話機でもよい。
・近くの友人の位置を要求できるときの、ユーザの位置の尺度でもある推論位置。
・クラスタ内に滞在しているのか、通過しているのかを区別するための速度。
・曜日。人々は週周期のパターンを有する傾向があるからである。
・時間帯。ほとんどの人々は、例えばオフィスにおける業務時間や夜間は在宅などの日周期のパターンを有するからである。

次に図４を参照して本発明の一実施形態による方法について説明する。コンテキストデータストリームは、時間の関数としてコンテキスト状態ベクトルで記述される。これらは（例えば最近のｎ日にわたる）コンテキスト測定から得られる。これらの測定はコンテキスト状態ベクトルを求めるために使用される。状態ベクトルの最後の２次元（すなわち曜日と時間）は、実際には解空間の複雑度を低減するために使用されるのこぎり波状の関数（sawtooth function）である。

各状態ベクトルはある測定期間（「サンプリング期間」）に対応し、ｉｄによって一意に特定される。状態ベクトルは欠落データのために相互関係を持つことができる。例えば一部の状態ベクトルは、他の状態ベクトルのより詳細な（または、より粗い）バージョンである。

状態ベクトルが求められると、実際のクラスタリングアルゴリズムが実行される前に何らかの事前処理を実行することができる。例えば、ＧＰＳから取得されたジオポジション（geoposition）は、例えば関心のあるエリアをカバーする所定のグリッドのデータへ変換することができる。その結果、位置（location）は、ピンポイント、矩形などのようなグリッドの要素として表され、そしてジオポジションはグリッド内のポジションに対応する。このようにして、データの粒度を幾分減らし、必要な計算能力も下げることができる。

状態ベクトルに基づいて、状態ベクトルのペア間の時間、距離、及び遷移確率を計算することができる。遷移行列及び距離行列の剪定（pruning）後、状態ＩＤの一次マルコフ行列Ａを構成することによって一次マルコフクラスタリングが実行される。これは詳細度が最小から最大まで異なるレベルで実行することができる。遷移確率は、
・遷移確率を確実に計算するには発生数が小さすぎるとき、
・ノイズを抑えるために遷移確率がゼロに近いとき、
・２つの状態の間の距離メトリックが大きすぎるとき、
にはゼロに剪定される。

２つのコンテキスト状態の間の距離メトリックは、コンテキスト状態値のほとんどについてバイナリである（０は同じ、１は異なる）。しかし、ジオグリッドポイントに対してはグリッド距離（隣のグリッドポイントに対しては１、そのまた隣のグリッドポイントに対しては２など）を使用する。２つの状態の間の距離は、それらの状態における値の間の距離の総和によって計算される。この結果、より効果的なクラスタリングを可能にするより疎なマルコフ行列が得られる。続いて状態ＩＤの一次マルコフ行列Ａを構成することによって一次マルコフクラスタリングが実行される。

欠落データによりコンテキスト状態は関係を持ち、状態Ａは状態Ｂと同じはずだが、実際の地理的位置が欠落すると、この場合ＡはＢより「具体的でなくなる」。マルコフ行列の累乗を計算し、行と列を並べ替えて対角方向にブロックする形成することにより、何らかの形でグループを成しブロック間の頻繁な遷移を有する状態のブロックを見つけることができる。斯かるブロックはコンテキストクラスタと呼ばれ、含む状態によって特徴付けられる。最も直近の期間内に検出されたクラスタは、（以前のサンプリング及びクラスタリングから得られる）既存のクラスタベースとマージされ、その結果、既存のクラスタの拡張またはマージが得られる。

こうして得られたクラスタは、推論エンジンを実行することによって得られる概念名によって名前付けされる。以下、このことについてより詳しく説明する。

本例では２つのコンテキスト状態ベクトルの間の距離尺度は、
・利用可能であれば、２つの状態の間の物理的距離、
・決定可能であれば、状態における２つのセルの間の距離、
・２つの状態の間の時間差、
に基づく。

後続の２つの状態ベクトルの間の計算された距離がある閾値を超えた場合、マルコフ行列における遷移としてカウントされない。このようにしてクラスタの無制限の成長とクラスタリングが防止できる。現実の（real-life）コンテキストデータを取り扱うアプリケーションでこの距離閾値を適用することが好ましい。コンテキストデータストリームは連続的であることが求められるが、ある時間ではデータが欠落している（例えばユーザがアプリケーションを閉じた）か、データ通信が失敗するか、またはユーザがトンネルを通過する事態が起こり得る。

一実施形態によれば、検出されたクラスタは、そのクラスタにおける全滞在時間がｄ日間でｈ時間という閾値を超えた場合に、ユーザに対してネーミングのために（概念名の提案とともに）提示される。実際には、全てのコンテキスト状態と遷移が利用できる限られたデータ量で１つのクラスタに直接割当てられるわけではないので、クラスタが提示される前にしばしばｈ時間より長く時間がかかる場合がある。ユーザは新たなクラスタを受け入れる（次にそれに名前を付け、それを分類する）ことができる、またはその新たなクラスタがユーザにとって無意味であればそのクラスタを無効にすることができるか、あるいはそのクラスタがより現実に即していればそのクラスタを既存のクラスタの１つとマージすることができる。一実施形態によればマージはクラスタリングメカニズムによっても提案される。例えば、新たなクラスタの候補が既存のコンテキストクラスタ間を橋渡しするようなものであればマージが提案される。このようにして、クラスタのマージはユーザにとって容易となるが、クラスタの望ましくないクラスタリングをもたらすことはない。

コンテキスト状態の異なる特質（dimension）により、これらの状態における存在を非常に正確に検出することができる。この結果、クラスタにおける実際の定期的な滞在と単なる通過とを区別することができるようになる。例えば、移動速度がコンテキスト状態の一成分であり、かつ、所在がオフィスまたはオフィスの近くであることを位置情報が示しているときにその速度が所定の閾値を超える場合、システムはユーザが単に通過しているだけであると結論付けることができる。加えて、このアルゴリズムは仲間との異なるタイプのミーティングの状況の検出をサポートするとともに、（１）仲間との静的な会合と、（２）仲間との旅行中と、（３）偶然の出会い（経路が仲間と衝突するとき）とを区別することができる。この区別も同様に、仲間が近くにいることを示す位置情報及びビーコン情報のほかに速度パラメータも基礎とすることができる。

次にクラスタリングアルゴリズムの具体例を説明する。

この幾分単純化した例では、４つのコンテキスト状態の間の遷移を示す。コンテキスト状態ベクトルも単純化され、［セルＩＤ、グリッドＩＤ、平日ＩＤ］のみを含む。セルＩＤは、例えばＧＳＭセルのＩＤであり、グリッドＩＤはユーザが現在位置するグリッド要素のＩＤである。そして、それはシステム設計者によって事前に定められているグリッドについての情報と関連してＧＰＳ情報から導き出される。以下、平日ＩＤが１に等しい通常の月曜日の例を示す。コンテキスト状態空間は次のような４つのコンテキストベクトルにより張られる（span）。

遷移行列Ｔは次式で与えられる。

これは以下に示す状態間の距離行列Ｄ
と一日あたりの滞在時間ベクトル
とに基づく。

状態１と状態２によって形成され、互いの最大の距離が１、全平均滞在時間が１５．２時間／日に等しい新たなクラスタが見つかる。この人為的な例では、これは新たなクラスタの滞在／退出比８５％／１５％を、調査した期間の６３％に相当する時間と組み合わせることにより生まれる。実際には現実のデータに基づき、２以上、一般的には５〜１５のコンテキスト状態からクラスタが形成される。しかしそれより多くてもよい。

ここで、マルコフクラスタリングを利用するアプローチは、サンプリングされたコンテキストデータにおいてクラスタを特定する１つの可能性に過ぎないことに言及しておきたい。コンテキスト状態ベクトルのクラスタを取得するために、他のクラスタリングアルゴリズムも利用することができる。

次に位置クラスタの定義を述べる。それは本発明の一実施形態によるアルゴリズムに使用されるものである。
・ユーザによって選ばれる名前（Name）
・空間オントロジーとの関係を表すタイプ（Type）
・クラスタを張る一連のコンテキスト状態ベクトル
・当該クラスタにおける全ての位置測定値の加重平均である、推定（estimate）された地理的位置
・クラスタのオーナーであるユーザ（user）
・当該クラスタにおける全滞在時間、最後の位置測定値の参照、マージの推奨などを含むメタデータ（Meta data）

以下、クラスタインスタンスの例について述べる。

最も一般的な２つのクラスタは、ホーム及びオフィスである。現実のシステムで利用できるクラスタ情報の実感を与えるため、表１にオランダのエンスヘーデ（Enschede）にいるユーザの例を示す。

これにより、ユーザは、名前（name）、タイプ（type）、オーナー（owner）及びステータス（status）に関して自分自身のクラスタ情報を適応させることができる。タイプはオントロジーにおいて利用可能な場所概念とリンクしている。ステータスは必要に応じて当該クラスタ内にいる間、存在の検出を抑えるよう休止状態に設定することができる。クラスタにおける最後の存在と現実のデータ（real-life data）から得られるクラスタ定義を含む追加情報がシステムによって生成される。本例から、このユーザは毎週金曜日の通常の業務時間には働かない普通の会社員であることが明らかである。また彼は一日の全ての時間帯、中でも夕方と夜間に在宅している（大きめのフォントは発生頻度がより高いことを示している）。家にいる間、ユーザは異なるオペレータの４つの異なるＧＳＭセル、中でも最も頻繁にＩＤ９９１６のセルに接続できる。各クラスタのジオグリッドは明らかに２つ以上のグリッドポイントをカバーするが、一部のグリッドポイントはその他のものよりも頻繁に検出される。この頻度は各クラスタの信頼できる平均的な地理的位置を計算するために使用される。例えばオフィスグリッドではＩＤ５６が最も頻度が高い。この情報は、データ駆動の個人的な勤務日（本例では月から木）または個人的な仕事時間（本例では０９：００−１８：００）を計算するために使用することができる。

次に、クラスタリングアルゴリズムから得られたクラスタの概念名を決定する推論エンジンがどのように働くかについて詳しく説明する。一実施形態において斯かる推論エンジンはオントロジーを利用する。これはシステム設計者によって事前に定義され、少なくともある程度は現実世界（real world）についてのナレッジを表現する。

コンテキストオントロジーは、関心のあるドメインを形式化し、異なる適用シナリオに共通の語彙を与えるために適用される。それゆえ、異なるコンテキストドメインは、対応するオントロジー内で表現された概念と関連付けされる。サブ概念はある現実世界オブジェクトのより広い理解をカバーするより高いレベルの概念を更に区別する。一例を述べると、考えられる１つのサブ概念関係は、Office#buildingがある特定のBuildingであるという想定であろう。これらの階層構造に加えて、概念定義は追加の論理ステートメント（例えばディスジョイントネス：「Office#buildingはPrivate#placeではない」）、または以下の概念定義に示されるような他の論理ステートメントも含むことができる。

上の定義は、検知されたBluetooth機器（bt#scan）の場所がOffice#environmentとして分類できることと、Office#hoursをofficeとして分類できることとを表している。

階層（father#ofは親類のサブプロパティである）の中で定義されたプロパティは特定の論理属性も有する。例えば、colleagueという関係を推移的に定義すると、ＡがＢのcolleague、ＢがＣのcolleagueであれば、ＡもＣのcolleagueであることを意味する。

手作業でクラスタに名前を付けて分類するため、ユーザは好ましくは分類についてのオントロジーのブラウジングについてサポートを受け、推奨の名前が提供される（次のセクションの推奨を参照）。オントロジーのブラウジングは、一実施形態によれば名前に基づくスマートキーワード照合技術と、（ほぼ同じ名前または地理的位置を使用する）他のユーザによる分類に基づく提案とによってサポートされる。この方法の威力は、ユーザがクラスタの正しい分類を見つけるのに数秒とかからないことである。これは携帯機器に実装されるときにより重要な長所となる。クラスタを分類するのに数秒以上要する場合、初期の入力を補正するだけの十分な長期的効果が明らかでないことから、ユーザはその努力を回避するだろう。

しかしながら、本発明は、手作業によるネーミングよりも、見つかったクラスタの概念名の自動決定に焦点を置いている。クラスタのネーミングと分類の最善の結果は、容易に適応させることのできる少数の推奨をユーザが取得するときに得られる。これらの推奨は、入力として見つかったクラスタを受け取り、それに基づいて概念名を決定する推論エンジンの実行の結果である。これは以下のものに基づくことができる。
・オーソリティ（Authority）： 地元の観光案内所、自治体または旅行代理店といったより信頼性の高い団体がいくつかの場所に名前を付ける。推論エンジンの内部では、よりオーソリティの高いソースからのデータが直接使用されるか、または例えば仲間の旅行者などのよりオーソリティの低いソースからのデータに最も低い優先順位が付けられる。
・経験則（Heuristics）： ほとんどの個人に有効な共通のルールの集合、例えば、あなたが日中過ごす場所は（夜間過ごす場所と異なる場合には）通常、オフィス、作業場または学校である。
・統計（Statistics）： 推奨は、他のユーザのより大きな集団がこの場所にどのように名前を付けて分類したかに基づく。例えば、８０％のユーザがこの場所に「聖メアリ教会（Saint Mary's church）」と名付け、それを「教会」または「宗教施設」に分類した場合、これは良い推奨でもある。オントロジー推論は、特異性（specificity）と信頼（trust）との間の正しいバランスを有する概念を見つけるために使用される。このタイプの推奨は、公共的な場所に対しての方が、より大きな人々の集団にとってはあまり関心がなくアルゴリズムをトレーニングするのに利用できる少ないデータを有する私的な場所に対してよりも、よりうまく機能することが明らかである。
・コンテキストモデル（Context models）： 形式化されたワールドナレッジ（world knowledge）が、ユーザ同士の間でクラスタを直接共有することをサポートし、関係したクラスタストリームの組み合わせからクラスタ推奨を直接導出するために使用される。例えば、社会的関係のある２人のユーザは、システムまたはユーザによって開始されたクラスタを共有する。例えば、ユーザが、彼の同僚によりホームとしてタグ付けされた場所を訪れるとき、この場所は「私の同僚であるマルコ（Marko）のホーム」としてタグ付けされ、またそのようにシステムによってユーザに推奨される。さらに、図５に示すように異なるドメイン（例えば、時間、位置及びBluetooth環境など）を表すいくつかのクラスタストリームがインターセクトしている場合、インターセクトしているクラスタの１つの欠落情報に対する提案が、対応する概念定義の論理分類によって導き出せる。例えば、位置概念Officeが上のように定義され、更に以下のような定義
を想定する場合、別のクラスタ概念リンク、例えば時間クラスタのOffice#hours（図５参照）、がその他の２つ（Office及びOffice#environment）から推論できる。

上に述べたことは、論理的推論を既に名前付けされたクラスタの概念名へ適用する。言い換えると、既に名前付けされたクラスタの概念名は、推論を実行する推論エンジンの入力として使用される。図５に示した実施形態ではBluetooth環境データは、既に「Office Envronment」（「オフィス環境」）と名前付けされたクラスタを導く。例えば、検出されたBluetooth機器のデータストリームが存在しており、このデータストリームは図５に示すように収集及びクラスタ化されている。そしてそれはユーザによって「Office Environment」と名前付けされている。さらに、図５に示すようにクラスタを有する位置データのデータストリームに基づく位置クラスタ（location cluster）も既に「Office」と名前付けされている。

図５はしかしながら更に時間クラスタ（time cluster）も示している。この時間クラスタはそのデータストリームの入力パラメータとして「時間（time）」、例えば電話の呼出、ユーザ機器の操作、または検出可能なその他のイベントといった特定のイベントまたはアクションの時間を有し、まだ名前が付けられておらず今度はその名前が決定される図５に示すようなクラスタをもたらしている。この時間クラスタは図５に示すように少なくとも部分的にクラスタ「Office」及び「Office environment」と「オーバーラップ」または「インターセクト」する。このオーバーラップにより、推論エンジンは上で示したような既に名前が付けられたクラスタ概念に基づいて推論を適用することができる。推論は、既に名前が付けられたクラスタの概念名を入力として使用し、推論エンジンの公理（axioms）を適用して、上で示したような結論、すなわち時間クラスタはその他の２つのクラスタが「Office environment」及び「Office」と名付けられていることから「Office time」と名付けることができるといった結論に達する。

従って推論エンジンは、本実施形態では既に名前が付けられたクラスタの所与の概念名を入力として使用し、推論エンジンによって実装された公理を適用することにより名前が付けられていないクラスタの概念名を決定するために、入力された概念名に基づいて導き出すことができる結論を見出す。斯かる公理は、所与の一連の概念名についての「ワールドナレッジ」を表している。これは事前に管理者によって実装が済んでいる場合があり、上述したようにそれは推論エンジンによって使用される。

定義間の循環依存（cyclic dependency）は論理的には問題ないことがわかる。

既に名前が付けられたクラスタの概念名及び決定されるべき概念名は全て、これらの概念名が論理的推論を使ってどのように組み合わせることができるかについてのナレッジを表す公理及び概念名のオントロジーの一部であることが更にわかる。このナレッジ及びオントロジーは事前に例えば管理者によって実装されている。

上記の例で述べたコンテキストモデルベースのアプローチは、一般的なワールドナレッジ、及び上記の例を形式化するために使用される例えばＯＷＬ（Web Ontology Language）（非特許文献「D. McGuinness and F. van Harmelen. OWL Web Ontology Language overview. W3C Recommendation, February 2004」参照）などの１つの形式言語に関するクラスタコンテキストストリームに由来する実際の定性的コンテキスト情報の両方を形式化する。形式的なナレッジ表現言語（ＯＷＬのサブ言語ＯＷＬ ＤＬの場合の記述論理（Description Logic））の基礎となるセマンティックは、ワールドナレッジを所与の実際の情報に適用して、インプリシットなナレッジをエクスプリシットにアクセス可能にする結果として追加の事実を導き出すために使用することができる。記述論理の概説については非特許文献「F. Baader et al. The Description Logic Handbook. Cambridge University Press, Cambridge, January 2003」を参照されたい。議論している形式言語の基礎をなすセマンティックが決定可能ならば（ＯＥＬ ＤＬに対してそうであるように）、全ての与えられた問題で終結し（終結性）、公理の所与の集合の全ての結果を計算し、ナレッジベースの矛盾を検出することが可能（完全性）な推論エンジンが実現できる。ＯＷＬ ＤＬに関しては、例えば、非特許文献「V. Haarslev and R. MOller.Racer: A core inference engine for the Semantic Web Ontology Language (OWL). In Proc. of the 2nd Int. Workshop on Evaluation of Ontology-based Tools, pages 27-36, 2003」、または非特許文献「E. Sirin and B. Parsia. Pellet: An OWL DL reasoner. In Proc. of the Int. Workshop on Description Logics, pages 212-213, 2004」、または非特許文献「D. Tsarkov and I. Horrocks. FaCT++ description logic reasoner: System description. In Proc. of the Int. Joint Conf. on Automated Reasoning (IJCAR 2006), volume 4130 of Lecture Notes in Artificial Intelligence, pages 292-297. Springer, 2006」に記述されているように、いくつかの斯かる推論エンジンが既に実現されている。

記述論理（例えばＯＷＬ ＬｉｔｅまたはＯＷＬ ＤＬ）の決定可能なフラグメント内の定性的なコンテキストのオントロジーベースの概念化を通じた自動化された推論を含む、オントロジーベースのモデリング及び推論の用途について次に説明する。本発明の実施形態によるオントロジーの自動分類の使用ケースを以下に述べる。

オントロジーによって表されるコンテキストモデルは、システム設計者によって実装されるユーザの状況（situation）についての「ワールドナレッジ」を表現することができる。それらは、サンプリングされたコンテキストパラメータによって検知される状況を仮定して、ユーザがある特定のコンテキスト名によって表すことができる状況に等しいことを結論付けるために状況に応じた推論（situational reasoning）に使用することができる。

次に、斯かる状況に応じた推論の分類についていくつかの例を使って詳しく説明する。例えば、概念化された（名前が付けられ、オントロジーの概念と関連付けられた）複数のクラスタ及び／または概念化された更なるコンテキスト要素は、ユーザの状況を反映するために１つの論理表現として（例えば論理結合を通して、しかし論理的組み合わせの他のストラテジーも可能である）組み合わせることができる。続いて、新たに構築された論理表現がオントロジーにおいて既にコード化されたナレッジに関して自動的に分類される。既存のクラスタがクラスタだけでなく満足すべきコンテキストパラメータの条件も含む論理表現によって関連付けられる場合、これは新たな概念名が割当てられる必要がある新たなクラスタをもたらすことがある。結果として、新たな状況に応じた論理表現に対しオントロジーにおける新たな概念名を割当てることによってその論理表現を分類することを通して、ユーザの状況についての定性的なステートメントが作り出せる。例えば、ある条件を仮定すると、ユーザは新たに割当てられた概念名によって表された状況にあると結論付けることができる。

これは以下の例から明らかとなる。

ユーザの現在の状況を表すための論理ベースの推論メカニズムの適用の１つの例は、次のように説明できる。ユーザの環境コンテキスト情報（例えば、近くいる人々または一日の時間）が、定性的なステートメントが作られるようにモデル化されたと仮定すると、一連のコンテキストデータはオントロジー内において記述され、組み合わされ、そして最終的に分類することができる。

具体例として、二人以上が参加する出来事として、ミーティング（meeting）が一人の個人的な「Office」クラスタにおいて「Office#hours」の間に起こるのであれば、これらの参加者の一人は中心のエンティティの監督者でなければならない状況（situation）を、十分に記述することができる。図６は、形式化されたワールドナレッジの表現を示す図で、コンテキストパラメータと概念名は論理表現によって組み合わされる。この図６に示すようにオントロジー内で概念化されたナレッジに基づいて、この状況は、この状況に応じたインスタンスを同名のオントロジー概念に割当てるための全ての必要な条件が満たされることから、「important#meeting」として分類される。

更なる実施形態によれば、オントロジーベースの推論は、導き出された情報のコンシステンシーを保証することができる。既に述べたように、異なるコンテキスト状態ベクトルの存在はユーザの周辺環境について更なる事実の推論を可能にする。次に図７を参照してより具体的な例を述べる。図７は、社会的な関係についての形式化されたワールドナレッジを示しており、このワールドナレッジは以下の例において推論を実行するために適用される。

例えば、ユーザのソーシャルコンテキスト（ユーザが定期的に会う人々とのユーザの社会的な関係）は、ユーザの社会的な関係のネットワークを補完するために予測できる。一例として、男性ユーザの履歴コンテキストデータが、彼は通常夜間をある女性（システムにとってこれまでは未知）と過ごすことを示していると仮定すると、この女性は彼の妻であると見なすことができる（図７参照）。しかしながら、別の女性が既に彼の妻と見なされている場合、こうした衝突は自動的に検出され、適宜に処理又は対処することができる。

従ってユーザコンテキストにおいて社会的な役割「Wife」（妻）は十分に定義されなくてはならない。より正確には、妻の関係はユニークな値を持つものとされる特徴を持つ機能的な（functional）ものとして定義されていなくてはならない（ＯＷＬ ＤＬ規格参照）。結果として、コンシステンシーチェックは予め確認されている既存の事実に基づいて自動推論を改善するのに更に役立つ。

上記の方法により、本発明の実施形態は、上記のように機能するとともにクラスタリングアルゴリズムの結果見つかったクラスタに対して概念名または概念名の提案を決定する推論エンジンを実現することを可能にする。

コンテキストモデルアプローチのこの論理ベースの実現の代わりに、ルールベースのシステムを適用することも可能である。この場合、ワールドナレッジはルールと事実のリストとして形式化される。ルールエンジンは、ルールの前提を前向き連鎖（forward chaining）または後向き連鎖（backward chaining）で所与の事実と照合し、対応する結論をファクトベースに加えることによって、インプリシットなナレッジ（暗黙のナレッジ）をイクスプリシット（明示的なナレッジ）にすることができる。しかしながら、ほとんどのルールシステムは適正に定義されたセマンティックスを欠き、それゆえ推論プロセスの完全性（completeness）と終結性（termination）はしばしば保証されず、使用されるルールエンジンに実装された具体的なストラテジーに推論結果が依存する状況がもたらされる。上記に例で意図された循環定義は、ここでは特に要求が厳しいが、論理ベースの設定には何の支障もきたさないことがわかる。

これまで、実生活（real-life）コンテキストデータをコヒーレントデータのより大きなクラスタにクラスタリングする方法と、更に、形式的なオントロジーに基づくこれらのクラスタのセマンティック意味のための方法について述べてきた。上述の例において、主な例としてこれらの技術を位置データに適用している。

ユーザの軌跡及び場所は、多くの場合、地図上にピンポイントで表すことができる詳細な位置だけでなく、定性的なレベルにとどまる領域（「ダウンタウン」とか「通勤途中」など）もある。加えて、場所は正確な地理的位置で記述されるだけでなく、固定された地理位置情報に対して経時的に変動する既存のビーコン（例えばＧＳＭアンテナまたはＷｉＦｉホットスポット）に関連して表すこともできる。この理由から、人間が個人的なお気に入りの場所を、そうした場所における彼または彼女の存在が自動化されたシステムによって検出できるような表現で記述することは少しも容易でも便利でもない。

しかしながら、上記の説明では、そうした重要な場所をユーザの過去の所在の軌跡（historic location tracks）から自動的に認識して、これらの検出された場所をユーザに提案し、そしてシステムからの提案に基づく簡単な方法、または完全に自動的にユーザが場所に名前を付けて分類することができるようにする方法について説明した。新たな場所が登録されると、それらの場所は（新たな軌跡に基づいて手動と自動の両方で）適応化され、かつ他のユーザと共有され、または場所の名前とタイプを他のユーザに推奨するために利用することができる。コンテキストオントロジーは、場所の管理と場所についての推論をサポートするために、不可欠で空間的な概念及びタイプを捕捉する。提案されたアプローチによれば、他のユーザにとっては重要性が低いかまたは全く無意味でさえある地理的位置または通り名のような生のコンテキストデータを交換するのとは対照的に、ユーザが定性的なレベルで位置データを交換することがより容易になる。

さらに、提案された方法を使用すると、コンテキストアウェア及びプレゼンスアウェアのモバイル用途をサポートするための定性的なコンテキスト情報を有することがより容易になる。コンテキスト情報はリアルタイム、かつリーダが解釈するのが容易なレベルにある。それと同時に、情報を提供するユーザの努力をほとんどまたは全く要しない。特に、ユーザプレゼンス（user presence）は基本的なレベルではあるが今日では既に広く認識かつ展開されている特徴である。例として、ＭＳＮまたはＬｉｎｋｅｄｌｎのような多くのインスタントメッセージ、またはモバイル及びソーシャルアプリケーションに共通する仲間のリストが含まれる。これらの仲間リストはユーザについてのリアルタイムの定性的なコンテキスト情報で拡張することができる。そのようにして携帯機器の機能性を大きく改善することが可能である。

上述の例はコンテキストデータとして位置データを使用した。しかしながら、任意のタイプのコンテキストデータは、上述の実施形態で説明したのと同じ方法で、すなわちデータの中からクラスタを検出してワールドナレッジを表す推論エンジンを実行してクラスタの概念名を取得することによって、取り扱うことができることは明らかであろう。クラスタ化され、自動的もしくは半自動的に分類、追跡または監視されるデータは、例えば、医療データ（心拍数など）、商業的データ（例えば、スーパマーケットの商品に添付されたＲＦＩＤチップ、公共の乗り物の特定の場所にあるタグ、観光地のような特定の場所にあるタグなどから読み取られたタグデータ）を含むことができる。この他のデータも、クラスタ化され、適切に定義、プログラムされた推論エンジンを提供することによって概念名で自動的に名前が付けられることがある。

本発明の実施形態はユーザの追跡と場所の簡単な分類に適用することができ、これらの場所における存在が自動的に検出できるような方法で特徴付けられる。これは個人的に重要な場所の自動検出のほかに、場所のセマンティック分類（オントロジーに基づいてこれらの場所に関する推論を含む）も含むことがある。定性的コンテキストは、コンテキスト状態ベクトルと、名前の付いたクラスタとに基づいて随時自動的に決定されるので、これはユーザの定性的コンテキストを決定するためにいつでも使用することができる。さらに、この定性的コンテキストはユーザのいるコンテキストに応じて行動するために使用することができる。これはユーザの関係する場所または他の関係するコンテキスト状況のような関係のあるコンテキスト状況の検出を含むことができる。

ユーザ追跡の目的のため、定性的コンテキストは、追跡されてデータベースに格納することができる。データベースの中に、ユーザの現在の状況を特定する概念名が時間と一緒に格納することができる。定性的コンテキスト情報は、複数のコンテキストデータストリーム、そして上述した論理的推論から導き出される単一または複数の概念名を含むことができる。このようして、ユーザの現在の状況は定性的な表現、つまり概念名によって記述されて特定される。これらの種類の「状況指標（situation indicator）」を格納することは、コンテキストヒストリをもたらし、これは定性的コンテキストで拡張され、後の参照のためにデータベースに格納される。こうして格納された定性的コンテキストヒストリは、例えば「Home」及び「Office」のような場所で費やされた時間を特定するためだけなく、例えば「Home」のような「特定のコンテキスト状況の間の全ての電話の呼出を見せて」のようなコンテキストに応じた状況とイベントを関連付けるより複雑な解析の目的のために、クエリーまたは解析される。コンテキスト情報の定性的な性格（地理座標の代わりに例えば「Home」または「Office」）により、過去のコンテキストのクエリーはより直感的または簡単に行うことができる。概念名のオントロジーまたは分類法（taxonomy）は、クエリーの入力でユーザを支援するためにクエリーインタフェースにより表示されることがある。定性的な表現を使用すると、例えば「important#business#meeting」のような状況に関係したコンテキストアイテムが検索できる。

しかしながら、斯かる定性的なコンテキストヒストリの追跡は、解析と検索だけでなく、他の用途にも有用である。定性的なコンテキストの追跡は例えば斯かる定性的追跡、すなわちユーザの状況の検出に基づいてアクションをトリガするのに使用されることがある。ユーザの（定性的な）状況またはコンテキスト、例えば「Office」または「Home」に基づいて、即時のユーザのコンテキストに依存するアクションを実行またはトリガすることができる。

一例として、ユーザ機器（電話機）上の特定のプロファイルを、例えば、電話機をミュートにする、または（例えば定性的コンテキストが「会議」であれば）呼出を転送するようにアクティブにすることが可能である。

別の例として、特定のプライバシー設定をユーザのためにアクティブにすることができる。例えば個人的なコンテキストのどの部分について誰に見られるかがユーザ状況に基づいて決定できる。例えば「Office」では、全ての同僚は全てのコンテキストへのアクセス権を有する。一方「Home」ではユーザ自身またはその家族のような「プライバシーグループ」の構成員に限られたアクセス権が存在する。より一般的に言えば、定性的コンテキスト情報または関連情報（ユーザＩＤ、及びユーザが共有したいと思う任意の情報など）は他者、例えば同じ定性的コンテキスト状況にあるアドホックネットワークのメンバと共有することができる。そのため、どの情報が誰とどんな条件で共有されるべきかを決定する一連のルールを規定することができる。

定性的コンテキスト追跡の更なる用途として、リマインダまたは通知がアクティブにできる。例えば、ユーザが特定の定性的コンテキスト（状況）、例えば「Office」または「Home」に入るとすぐに、リマインダを含むメッセージをそのユーザに届けることができる。

別の例として、同じような定性的コンテキストにあるユーザのアドホックなグループ分けが実行できる。例えば、仲間達が「Home」にいるのか「Office」にいるのかに基づいて重要なコンタクトの仲間リストがグループ分けできる。

一実施形態において、定性的コンテキストに基づく自動的なアノテーション（注釈）をユーザが撮った写真に付加することができる。例えば、タグ（時間、場所といったユーザコンテキストからの重要なデータアイテム）を、「Leisure#time」に撮られた全ての最近の写真に注釈を付けるために使用することができる。これはリアルタイムの設定によって、例えばユーザが余暇時間に写真を撮るごとに、行うことができる。あるいは、それは、コンテキストヒストリを問い合わせ、クエリー結果にタグ付けを実行することによって行うことができる。

更なる例として、ブログ（Blogs）（ウェブベースの日記）のような自動文書が、定性的に追跡されたユーザコンテキストの履歴に基づいて実現できる。例えば、個人的なブログは「at#a#Party」のような特定の定性的コンテキスト内に記録されたデータ（撮られた写真または記録されたその他のデータ）を強調表示することができる。

更なる例として、ＰＯＩ（Point-of-interest）フィルタリングがユーザの定性的コンテキストに基づいて実現できる。あるいは、ユーザの定性的コンテキストに基づいてサービスリコメンデーションを実現できる。

本発明の実施形態に関連して説明した方法、素子、ユニット及び装置は、ハードウェア、ソフトウェア、または両方の組み合わせで実施することができることは当業者にとってはすぐに明らかであろう。例えば、上記の機能は、適切なハードウェア（リアルタイムのコンテキスト情報を検出するためのセンサなど）と、携帯電話機を上述したように機能させる適切なソフトウェアとを備えた携帯電話機またはスマートフォンのような携帯機器に実装することが可能である。

特に、本発明の実施形態及び実施形態に関連して説明したモジュールの要素は、コンピュータもしくはマイクロプロセッサで実行される単一または複数のコンピュータプログラムによって実現することができる。当業者であれば、本発明の実施形態として説明した方法及び装置は、任意の標準的なコンピュータ及びコンピュータが本発明の方法、装置またはモジュールに従って機能するようにプログラムするための標準的なプログラミング言語を使用して実現することができる。本発明を実施する任意の装置は特に、例えば携帯電話機、スマートフォン、ＰＤＡなどの、携帯機器の形態を採ることができる。一方、斯かる機器上で走るソフトウェアは機能の一部のみを実現することもできる。また、より計算能力を必要とする複雑な作業を実行するために携帯機器は接続先となるサーバコンピュータを利用することができる。

本発明の実施形態によるプロセスの説明図である。 本発明の実施形態によるプロセスのフローチャートである。 本発明の実施形態による場所の異なる概念を視覚化した図である。 本発明の実施形態によるプロセスを示す説明図である。 本発明の更なる実施形態によるプロセスの説明図である。 ワールドナレッジの形式化された表現の一例を示す図である。 ワールドナレッジの形式化された表現の更なる一例を示す図である。

Claims (13)

1. コンテキストデータに対してセマンティック分類を自動的に決定する装置を用いて、コンテキストデータに対してセマンティック分類を自動的に決定する方法であって、前記装置は、サンプリング手段と、アルゴリズム適用手段と、推論エンジンと、割当て手段とを備えており、
   前記サンプリング手段が１つ以上のコンテキストデータストリームをある一定の時間にわたってサンプリングするステップと、
   前記アルゴリズム適用手段が、サンプリングされたコンテキストデータに対してクラスタリングアルゴリズムを適用して、１つ以上のクラスタを特定するステップと、
   前記推論エンジンが、一連の所定の概念名からある概念名を、１つ以上の前記クラスタのセマンティック分類として自動的に決定するステップと、
   前記割当て手段が、前記１つ以上のクラスタへ前記概念名を割当てるか、または当該概念名をユーザに提供するステップと、
   前記サンプリング手段が、ある時間におけるユーザのコンテキストを示す概念名を監視することにより、ユーザのコンテキスト状況を監視するステップと、
   １つ以上の概念名により示されたユーザのコンテキスト状況が、特定の定性的コンテキストを特定する所定の条件を満たす場合に、前記サンプリング手段が該ユーザの携帯機器により実行されるアクションをトリガするステップと
   を含み、前記アクションが、
   前記携帯機器の特定のモードまたは機能を起動することと、
   通知または警告を送信することと、
   類似した定性的コンテキストにおけるユーザをアドホックグルーピングすることと、
   定性的コンテキストに基づいてユーザデータへ自動的なアノテーションを付加することと、
   定性的に追跡されたユーザコンテキストの履歴に基づいて新たなドキュメントを自動生成することと
   のうちの１つ以上を含むものである、方法。
2. 名前が付けられていないクラスタが、既に名前が付けられた１つ以上の他のクラスタと１つ以上の座標において部分的または全体的にオーバーラップまたはインターセクトする場合に、前記推論エンジンが、前記名前が付けられていないクラスタの概念名を決定するステップであって、前記既に名前が付けられたクラスタの概念名を入力として用いて１つ以上の前記既に名前が付けられたクラスタの概念名を前記推論エンジンが論理的に組み合わせ、前記推論エンジンが公理を適用して前記名前が付けられていないクラスタの概念名を決定するステップを含む請求項１に記載の方法。
3. 前記サンプリング手段は複数のコンテキストデータストリームをサンプリングするものであり、
   サンプリングデータは、コンテキスト状態ベクトルのベクトル成分が前記複数のコンテキストデータストリームの１つに対応するものとなるようにコンテキスト状態ベクトルを求めるために使用されるものであり、
   前記サンプリングは定期的な間隔で実行されるものであり、
   各サンプリングは、サンプリングされた値により求められた対応するコンテキスト状態ベクトルを生じさせるものであって、
   前記コンテキスト状態ベクトルにより張られるクラスタを得るために、サンプリングされた一連のコンテキスト状態ベクトルに対して前記アルゴリズム適用手段が前記クラスタリングアルゴリズムを実行するステップを更に含む請求項１または２に記載の方法。
4. 前記推論エンジンが、前記クラスタに名前を付けるために使用することができる一連の定性的な表現の概念名を含むオントロジーを提供するステップと、
   前記クラスタリングアルゴリズムから得られたクラスタを定義するパラメータを前記推論エンジンが受信するステップであって、該推論エンジンはどの条件に基づいてどの概念名をクラスタへ割当てるべきかに関するナレッジを有するものである、ステップと、
   クラスタを定義する前記パラメータを前記推論エンジンが処理して、前記クラスタに対して提案された概念名を前記推論エンジンが返信するステップと
   を更に含む請求項１〜３のいずれか一項に記載の方法。
5. 前記処理するステップは、前記クラスタを定義するパラメータに基づいて、どのルールが満たされていて、結論として概念名を得るためにどの結論を導くべきかを決定するために、一連のルールを参照するサブステップを含むものである、請求項４に記載の方法。
6. 前記処理するステップは、前記クラスタが距離測定に基づいてある閾値を伴う近傍に他のクラスタを有する場合で、かつ前記他のクラスタ間である閾値を超えた尤度である概念名が選ばれている場合に、前記クラスタに実際に名付ける概念名として該概念名を提供するサブステップを含むものである、請求項１〜５のいずれか一項に記載の方法。
7. 前記推論エンジンが、一般的なワールドナレッジと、ある形式言語に関してクラスタコンテキストストリームに由来する実際の定性的コンテキスト情報とを形式化することにより実現されるコンテキストモデルを提供するステップと、
   前記推論エンジンが、受信した前記コンテキスト情報に基づいて所与の一連の公理の全ての結果を計算するステップと
   を更に含む請求項１〜６のいずれか一項に記載の方法。
8. 前記推論エンジンが、論理表現によりある概念名が割当てられている１つ以上のコンテキスト要素又は１つ以上の概念化されたクラスタのうち少なくとも１つを組み合わせることによって状況に応じた推論を適用し、利用可能なコンテキスト情報に基づいてある概念名により表現されたタイプに属するものとして前記推論エンジンがユーザの状況を自動的に分類するステップを更に含む請求項１〜７のいずれか一項に記載の方法。
9. 自動分類を適用して新たに割当てられた名前が概念空間に加えられた場合に、該新たに割当てられた名前がオントロジー内で既にコード化されたナレッジに関してつじつまが合うかどうかをチェックするために前記推論エンジンがコンシステンシーチェックを実行するステップを更に含む請求項１〜８のいずれか一項に記載の方法。
10. 前記サンプリング手段は異なる複数のコンテキストデータストリームを受信するものであり、
    コンテキストデータストリームごとに独立なクラスタを得るために、前記アルゴリズム適用手段が異なる前記コンテキストデータストリームに対してクラスタリングを独立に実行するステップを更に含む請求項１〜９のいずれか一項に記載の方法。
11. 前記サンプリング手段が、クラスタに割当てられた１つ以上の概念名により与えられたものとして前記ユーザの定性的コンテキストを定性的コンテキスト履歴ストレージに記憶することにより、該定性的コンテキストを追跡するステップを更に含む請求項１〜１０のいずれか一項に記載の方法。
12. ある携帯機器が１つ以上のコンテキストデータストリームをある一定の時間にわたってサンプリングするための手段と、
    サンプリングされたコンテキストデータに対してクラスタリングアルゴリズムを適用して、１つ以上のクラスタを特定する手段と、
    一連の所定の概念名からある概念名を、１つ以上の前記クラスタのセマンティック分類として自動的に決定する推論エンジンと、
    前記概念名を１つ以上の前記クラスタへ割当てるか、または当該概念名をユーザに提供する手段と、
    を備えており、
    前記サンプリングするための手段が、さらに、ある時間におけるユーザのコンテキストを示す概念名を監視することにより、ユーザのコンテキスト状況を監視するものであり、
    １つ以上の概念名により示されたユーザのコンテキスト状況が、特定の定性的コンテキストを特定する所定の条件を満たす場合に、前記サンプリングするための手段が該ユーザの携帯機器により実行されるアクションをトリガするものであり、
    前記アクションは、
    前記携帯機器の特定のモードまたは機能を起動することと、
    通知または警告を送信することと、
    類似した定性的コンテキストにおけるユーザをアドホックグルーピングすることと、
    定性的コンテキストに基づいてユーザデータへ自動的なアノテーションを付加することと、
    定性的に追跡されたユーザコンテキストの履歴に基づいて新たなドキュメントを自動生成することと
    のうちの１つ以上を含むものである、携帯機器によって得られたコンテキストデータのセマンティック分類を自動的に決定する装置。
13. 請求項１〜１１のいずれか一項に記載の方法をコンピュータに実行させるコンピュータプログラム。