JP2010108503A - サービスを見い出す方法及び装置 - Google Patents

Abstract

【課題】所与のデータに作用するサービスを効率良く検索する。
【解決手段】コンピュータを用いて、あるデータ・オブジェクトについて、該データ・オブジェクトを入力として利用することができるサービスを検出する方法は、タイプについてのタクソノミを提供するステップと、前記タクソノミに属するタイプを有するデータ・オブジェクトを受け取るステップ３００と、前記データ・オブジェクトのデータ・タイプと、前記１つ以上の属性のデータ・タイプとを得て、これらを前記データ・オブジェクトに関連付けられるタイプのリストに蓄積するステップ３５０と、前記関連付けられるタイプのリストに含まれる全てのタイプについて、それらのタイプを利用することのできるサービスを得て、入力されたデータを利用することができるサービスのリストを得るステップとを含む。
【選択図】図３

Description

本発明は、所与のデータに作用するサービスを見い出す方法及び装置に関する。本発明は、更に、所与のサービスが利用することのできるデータを見い出す方法及び装置に関する。

携帯電話機は、ユーザが自己の生活をナビゲートすることを手助けすることができるサービスを益々取り扱えるようになりつつある。そのようなサービスは、駐車料金の支払いや、娯楽や社交に向かうための公共交通機関のナビゲーションの支援など幅広いものである。しかし、ユーザは多くのサービスを利用できるにしても、現実にはこれらのサービスは相互に作用する関係を有するものではない。したがって、ユーザがある所与のアポイントメントに向かうために公共交通機関を利用することを望んでいるとした場合に、公共輸送サービスをそのアポイントメントと関連付けることは、不可能ではないにしても、非常に困難であり、このようなサービスをアポイントメントと関連付けて利用することは更に困難である。

したがって、アポイントメントなど何らかの所与のデータと関連してどのサービスが利用できるかをユーザへ知らせることのできる仕組みが求められている。これは、かかる仕組みが何らかの所与のデータ・オブジェクトに基づいてサービスを見い出すことができることを意味している。

サービスを見付け出すという課題に関する従来の解決策は、（１）サービスの入出力署名（input/output signature）、（２）サービスの前提条件又は効果、（３）いわゆる「非機能的（non functional）パラメータ」という３つの特徴に基づいて、サービス・リクエストをサービスの提供にマッチングすることに集中している。ここで、サービスの入出力署名とは、そのサービスから受け取る情報と生成される情報との間の対応関係を定めるものである。

上記（１）を用いた解決策は非特許文献１に基づいている。この非特許文献１は、非特許文献２と非特許文献３とを発展させたものである。これらの研究によれば、２つのサービスの間のマッチングを、制約条件としてサービスの入力と出力のみを用いるほかに、場合によっては追加の制約条件を用いて行うアルゴリズムを提案している。これらを用いても、データ・オブジェクトに基づいてサービスを見い出すという問題を解決することはできない。というのも、これらはサービスの機能を所望のサービスのプロトタイプについていかにしてマッチングさせるかという課題を解決しようとするものであるが、どのサービス群が所与のデータと関連して利用できるかという課題を解決するものではないからである。この従来技術と（後述する）本発明との違いは、「アポイントメント」などのデータ・オブジェクトと関連付けて見れば明らかである。アポイントメントは、（例えば時間や場所などの）複数の要素を有するが、アポイントメントは具体的にはそれらの要素のいずれか一つでもない。それゆえ、アポイントメントは特定の場所に関連付けることができるが、アポイントメント自体は場所ではない。したがって、従来技術のアプローチによれば、アポイントメント自体はナビゲーション・サービスの入力として認識されないことになる。同様に、アポイントメントは、会う人と関連付けられていても、ソーシャル・サービスへの入力として認識されない。結局のところ、従来技術によれば、ナビゲーション・サービス又はソーシャル・サービスをアポイントメントというオブジェクトへ関連付けることができない。

Ｉ／Ｏ署名（I/O signature、入出力署名）に基づいた検索アルゴリズムの問題点は、それらのアルゴリズムが入出力される異なった要素を独立して解析することができず、データ・オブジェクトを全体として扱わざるを得ないということである。この問題の代替的な解決策として、例えば非特許文献４は、マッチングを行う異なった方法を提案しているが、本質的には同じ問題に直面する。

サービスの前提条件と効果とを活用した解決策、例えば非特許文献５に記載の方法は、サービスによって作られる変換に着目している。これらは２つのタイプの問題を有する。１つ目の問題は、概して、これらは初期のフィルタとしてＩ／Ｏマッチング（I/O matching）に依存するということである。既に述べたように、フィルタとしてのＩ／Ｏマッチングは、当然のことながらサービスの様々な要素と、その結果として、所与のデータと関連して利用できるサービスとを認識することができない。２つ目の、より基本的な問題は、前提条件と効果とのマッチングがサービスの機能を所望の機能のプロトタイプとマッチングする問題の改良であることで、これはプロトタイプが与えられない本発明が解決すべき問題とは基本的に異なって（orthogonal）いる。３つ目の問題は、このタイプのマッチングは、サービスが処理できる情報を対象とするのではなく、そのサービスによって作られる変換のタイプを対象とすることである。例えば、一定数のユーザに限定されているカレンダーのように、ユーザが何らかの特別な許可を得ている場合にのみサービスが利用できるということを定めた前提条件である場合があり、その効果は、例えば会議への参加の約束といった何らかのプロパティがユーザに付随するということである。しかし、カレンダーを利用する許可も、その結果として生じる約束も、アポイントメントのプロパティではなく、カレンダーがイベントを記録するために利用できることを特定するためにこれらを用いることはできない。

「非機能的（non-functional）」パラメータを活用する解決策、例えば非特許文献６に記載の解決策は、提供されたサービスの品質という問題を扱っている。非機能的パラメータは、サービスのコスト、そのスピードその他を含むものである。それらはサービスが提供する機能についての品質であるが、それらは提供された機能については何も示さない。このように、アポイントメントといった所与の情報を処理するサービスとしてどのサービスが見つけられるかという問題を扱っていない。

Massimo Paolucci, Takahiro Kawamura, T. R. Payne, and K. Sycara, "Semantic Matching of Web Services Capabilities," in Proceedings of the 1st International Semantic Web Conference (ISWC2002) Katia Sycara, Seth Widoff, Matthias Klusch and Jianguo Lu, "LARKS: Dynamic Matchmaking Among Heterogeneous Software Agents in Cyberspace." Autonomous Agents and Multi-Agent Systems, 5, 173-203, 2002 Amy Moormann Zaremski, and Jeannette M. Wing; "Specification matching of software components"; ACM Transactions on Software Engineering and Methodology (TOSEM), Volume 6 Issue 4; October 1997 Klusch, M.; Fries, B.; Sycara, K. (2006): Automated Semantic Web Service Discovery with OWLS-MX. Proceedings of 5th International Conference on Autonomous Agents and Multi-Agent Systems (AAMAS), Hakodate, Japan, ACM Press Kaarthik Sivashanmugam, Kunal Verma, Amit Sheth, John Miller; Adding Semantics to Web Services Standards; The 2003 International Conference on Web Services (ICWS'03); 2003 Mohamed Hamdy, Birgitta Konig-Ries, Ulrich Kuster; "Non-functional Parameters as First Class Citizens in Service Description and Matchmaking - An Integrated Approach"; in Proceedings of the first "Non Functional Properties and Service Level Agreements in Service Oriented Computing" Workshop (NFPSLA-SOC 2007), Vienna, Austria, September 2007

サービス指向コンピューティングの分野の外に目を向けると、サービス、あるいはより一般的なコンピュータの機能をデータと関連付ける他の方法が存在する。最初の方法は、データのある特徴とアプリケーションとの決められた関連付けである。この場合、基本的には、見付け出すための手順は、２列のテーブルにおける検索に単純化される。このテーブルの一方の列は、データの特徴を列挙するために用いられ、もう一方の列は、対応するアプリケーションを列挙するために用いられる。このような決められた関連付けの最も一般的な事例は、ＯＳ（オペレーティングシステム）によって実行されるアプリケーション、電子メールリーダのほか、ブラウザなどの他のシステムにわたる、ファイル拡張子、より具体的にはＭｉｍｅタイプの利用である。Ｍｉｍｅタイプとアプリケーションとの関連付けは、所与のタイプに対応してどのアプリケーションが利用できるかを定めるテーブルを定義することによって行われる。このような対応関係は、例えば、「.doc」で終わる全てのファイルはアプリケーション「Microsoft Word」によって開かれるべきであり、「.odt」で終わる全てのファイルはアプリケーション「OpenOffice」によって開かれるべきであることを定める。さらに、一般的には、複数のアプリケーションを同じＭｉｍｅタイプと関連付けることが可能である。例えば、「.doc」は「Microsoft Word」と「OpenOffice」の両方に関連付けられる。この場合、見付け出すためのシステムは明確化の手順（disambiguation procedure）を利用するか、又はユーザに最良の選択を要求する必要がある。Ｍｉｍｅタイプとアプリケーションとの関連付けは、成功裏にアプリケーションとファイルタイプとを関連付けるが、重大な欠点がある。これらについては本発明の実施形態に関連して後述する。

コンピュータを用いて、あるデータ・オブジェクトについて、該データ・オブジェクトを入力として利用することができるサービスを検出する方法であって、タイプ・タクソノミ（type taxonomy、分類されたタイプの集まりあるいはタイプの分類）を提供するステップであって、前記タクソノミは、あるタイプがスーパータイプとサブタイプとを有する階層構造を持つものである、ステップと、前記タクソノミに属するタイプを有するデータ・オブジェクトを受け取るステップであって、該データ・オブジェクトは、その要素として１つ以上の属性を持ち、該属性は、前記タクソノミに属するタイプのものである、ステップと、前記データ・オブジェクトのデータ・タイプと、前記１つ以上の属性のデータ・タイプとを得て、これらを前記データ・オブジェクトに関連付けられるタイプのリストに蓄積するステップと、前記関連付けられるタイプのリストに含まれる全てのタイプについて、それらのタイプを利用することのできるサービスを得て、入力されたデータを利用することができるサービスのリストを得るステップとを含む方法が提供される。

前記タクソノミは検索のためのスキームを提供する。そして、関連するタイプを得ることで、検索がデータ・オブジェクト自体のタイプに基づくだけでなく、サービスが利用できるその「中味」にも基づいて行われる。このようにして、サービスを見付け出すことは、従来技術と比べて、より広い範囲をカバーするものとなる。

一実施形態によれば、上記方法は、前記関連付けられるタイプのリストに含まれる全てのデータ・タイプについて、前記タクソノミにおいて対応するスーパータイプと、それらに関連付けられるサービスとを見つけて、それらをサービスのリストへと追加するステップを更に含む。

検索にスーパータイプを含めることで、これらのスーパータイプを利用することができるサービスが得られる。また、それらのサービスは、検索の基礎となるデータ・オブジェクトを利用できるため、検出されるサービスの範囲と結果が広がる。

一実施形態によれば、上記方法は、前記関連付けられるタイプのリストに含まれる全てのデータ・タイプについて、前記タクソノミにおいて対応するサブタイプと、それらに関連付けられるサービスとを見つけて、それらをサービスのリストへと追加するステップを更に含む。

スーパータイプを含めることと同様に、検索にサブタイプを含めることで、それらのサブタイプを利用することのできるサービスが得られる。また、それらのサービスは検索の基礎となるデータ・オブジェクトを利用できるため、検出されるサービスの範囲と結果が広がる。

一実施形態によれば、上記方法は、見つかったサービスの入力として前記データが実際に利用できるかどうかをチェックするフィルタリングを見つかったサービスへと適用し、当該データが利用できない場合には、前記サービスのリストから対応するサービスを除外するステップを更に含む。

フィルタリングは、検索の手順により見つかったサービスであって当該検索が基礎としたデータ・オブジェクトを実際には利用することのできないサービスを除外することによって、リストを縮減することができる。

コンピュータを用いて、あるサービスについて、該サービスを入力として利用することのできる保存されたデータ・オブジェクトを検出する方法であって、
前記サービスが宣言されているデータの１つ以上のタイプのそれぞれについて、関連付けられるデータ・オブジェクトの集合を見つけるステップであって、前記サービスが宣言されている少なくとも１つのデータ・タイプ又はデータ・タイプのインスタンスを属性として持つデータ・オブジェクトを保存されたデータの中から見つけるサブステップを含み、該属性は保存されたデータ・オブジェクトの要素である、ステップと、
見つかったデータ・オブジェクトを、前記サービスが入力として利用するデータ・オブジェクトのリストへと追加するステップとを含む方法が提供される。

これにより、所与のサービスが作用しうるデータオブジェクト、又は所与のサービスが入力として利用することができるデータ・オブジェクトを検索することができるようになる。

一実施形態によれば、上記方法は、前記サービスが宣言されている全てのデータ・タイプについて、対応するスーパータイプを前記タクソノミにおいて見つけるステップと、見つかったスーパータイプのそれぞれについて、関連するデータ・オブジェクトの集合を見つけて、それを前記リストへと追加するステップとを更に含む。

検索をスーパータイプまで拡張することで、サービスの入力として利用することができるデータ・オブジェクトの集合が増大する。

一実施形態によれば、上記方法は、前記サービスが宣言されている全てのデータ・タイプについて、対応するサブタイプを前記タクソノミにおいて見つけるステップと、見つかったサブタイプのそれぞれについて、関連するデータ・オブジェクトの集合を見つけて、それを前記リストへと追加するステップとを更に含む。

検索をサブタイプまで拡張することで、サービスの入力として利用することができるデータ・オブジェクトの集合が増大する。

一実施形態によれば、上記方法は、所与のサービスについて、見つかったデータ・オブジェクトが実際に入力として利用できるかどうかをチェックするフィルタリングを見つかったデータ・オブジェクトへと適用し、当該データ・オブジェクトが利用できない場合には、前記データ・オブジェクトのリストから対応するデータ・オブジェクトを除外するステップを更に含む。

フィルタリングにより、入力として実際に利用することができるデータ・オブジェクトだけがリストに含まれることが保証される。

あるデータ・オブジェクトについて、該データ・オブジェクトを入力として利用することができるサービスを検出する装置であって、タイプ・タクソノミであって、該タクソノミは、あるタイプがスーパータイプとサブタイプとを有する階層構造を持つタクソノミを提供するモジュールと、前記タクソノミに属するタイプを有するデータ・オブジェクトを受け取るモジュールであって、該データ・オブジェクトはその要素として１つ以上の属性を有し、該属性は前記タクソノミに属するタイプのものである、モジュールと、前記データ・オブジェクトのデータ・タイプと、前記１つ以上の属性のデータ・タイプとを得て、それらを前記データ・オブジェクトに関連付けられるタイプのリストに蓄積するモジュールと、前記関連付けられるタイプのリストに含まれる全てのタイプについて、それらのタイプを利用することができるサービスを得して、入力されたデータを利用することができるサービスのリストを得るモジュールとを備えている装置が提供される。

このようにして、所与のデータ・オブジェクトに基づいてサービスを見い出すための装置が実現できる。

あるサービスについて、該サービスが入力として使用することのできるデータ・オブジェクトを検出する装置であって、タイプについてのタクソノミであって、あるタイプがスーパータイプとサブタイプとを有する階層構造を持つタクソノミを提供するモジュールであって、複数のデータ・オブジェクトがコンピュータに保存され、該データ・オブジェクトは、その要素として１つ以上の属性を持ち、該属性は、前記タクソノミに属するタイプのものである、モジュールと、前記コンピュータに保存されている全てのデータ・オブジェクトについて、該データ・オブジェクトのデータ・タイプと、該オブジェクトの要素である該オブジェクトの１つ以上の属性のデータ・タイプとを得て、関連するデータ・タイプの集合を得るモジュールと、前記関連するデータ・タイプの集合を、前記サービスが利用することのできるデータ・オブジェクトの集合として蓄積するモジュールとを備えている装置が提供される。

このようにして、所与のサービスに基づいてデータ・オブジェクトを見い出す装置が実現できる。

一実施形態によれば、上記装置は、上記いずれかの方法を実行するモジュールを更に備えている。

上記いずれかの方法をコンピュータに実行させるコンピュータ・プログラム・コードを含むコンピュータ・プログラムが提供される。

サービスを見い出す方法の手順の一例を示す説明図である。 データ・オブジェクトを見い出す方法の手順の一例を示す説明図である。 サービスを見い出す方法の一例を示すフローチャートである。 データ・オブジェクトを見い出す方法の一例を示すフローチャートである。

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

本発明の実施形態は、計算装置があるデータ（データ・オブジェクト）を受信すると、そのデータを利用することができるサービスを見い出すことに関する。計算装置は、例えばＰＣ又はＰＤＡなどの任意のコンピュータである。しかし、他の実施例では、携帯電話機、移動端末、スマートフォンである。以下、モバイル機器の場合について述べるが、他の任意の計算装置でもよいことを理解されたい。

モバイル機器は、例えば電子メールもしくはＳＭＳによって、あるいは任意の他の手段によって、任意のデータ・オブジェクトを受信する。この後、本発明の実施の一形態によるメカニズムは、このデータ・オブジェクトを利用できるサービスを見い出す。

ユーザデータを利用可能なサービスとマッチングさせるため、実施の一形態によれば、それぞれの情報は１つ以上の特徴（dimension）によって整理され、各サービスはこれらの特徴の１つ以上を扱う。一例として、アポイントメントは、時間という要素、場所という要素、誰がイベントに参加するかを表すための社会性を示す要素、コストを表す価値という要素などを有する。

モバイル機器が受信するデータ・オブジェクトは、それ自体があるタイプ（例えば、「アポイントメント」タイプ）を有し、このデータ・オブジェクトは、そのオブジェクト自体のタイプとは異なるタイプの１つ以上の個別の要素を持つ。これらの要素はある「値」を持つ。例えば、「時間」タイプの「時間」なる要素は、「９：３０ａｍ」を値として持ちうる。

以下の説明では、データ・オブジェクトの要素をそのデータ・オブジェクトの「属性」とも呼ぶ。既に説明したように、データ・オブジェクトの「属性」は、あるタイプのものであり、かつ、あるデータ値を持つと考えることができる。

データ・オブジェクトのこれらの要素又は属性に基づいて、そのデータ・オブジェクトに異なるサービスが適用される。データ・オブジェクトが「アポイントメント」タイプだとすると、カレンダーというサービスは、このデータ・オブジェクトの時間の部分（時間という要素）を利用することができ、ナビゲーションというサービスは場所の部分を利用することができ、「連絡先リスト」のようなサービスは社会性を示す要素へ適用できる。また、電子財布のようなサービスは「アポイントメント」タイプであるデータ・オブジェクトの（貨幣としての）価値という要素に適用できる。

後で詳しく説明するが、実施の一形態によれば、本メカニズムはデータ・オブジェクトの様々な要素を扱うサービスを探す。

処理側において、マッチングは、データから開始するのか、サービスから開始するのかに応じて２つのモードで実行できる。最初のケース（すなわち実施の一形態）では、携帯電話機（及びより一般的には計算装置）は、何らかのデータを受信すると、サービスをそのデータへと関連付ける。二番目のケース、つまりサービスから開始するモードでは、新たなサービスが利用可能になると、そのサービスは自動的にデータへと関連付けられる。これは、ユーザが、そして結果として携帯電話機が、新たなサービスが提供されている新たな環境に入るときに該当する。かかるサービスの一例は、マンチェスター空港におけるゲート情報サービスである。空港に入ると、携帯電話機は、ゲート情報サービスをフライトチケットと関連付ける。

無論、実施の一形態によれば、両方のメカニズムはともに実装される。

以下に説明する実施形態では、データは、オブジェクト指向プログラミング又はオントロジー仕様におけるタイプ・タクソノミ（type taxonomy、分類されたタイプの集まりあるいはタイプの分類）のような、タイプ・タクソノミによって分類又は整理される。これは、あるデータ・オブジェクトとその要素があったとき、それがこのタクソノミに属するあるタイプのものであることを意味する。

実施の一形態によれば、このタクソノミを実現するため、あるタイプをその直系（direct）のサブタイプとスーパータイプに関連付ける２つの関係、すなわち「SubType」と「SuperType」が存在すると仮定することができる。本実施形態の説明のため、集合論（set theory）的な解釈をこのタイプ・システムに適用する。この場合、タイプはデータ・インスタンスの集合として定義され、サブタイプという関係は２つの集合間の部分集合の関係として解釈される。タイプ・システムは、更なる特徴、例えば多重継承（multiple inheritance）、和（union）、積（intersection）、補集合（complement）のほかに、タイプに対する他の制約条件も有する場合がある。これらの追加的な特徴はメカニズムの結果を改善する可能性があるが、それらは厳密には必要とされない。より形式的には、Ｔをタイプの集合とすると、次の２つの関係を定義することができる。すなわち、SuperType:Ｔ×Ｔは、あるタイプをその直系のスーパータイプへとマッピングするものであり、SuperType(t,u)は、ｔがｕの直系スーパータイプである場合に成立する。同様に、あるタイプをその直系のサブタイプへとマッピングするSubType:Ｔ×Ｔを定義することができる。形式的に、「直系（direct）」とは、いくつかのスーパータイプがそれ同士でスーパータイプの関係にはないことを意味する。サブタイプに関しても同様である。

本発明は、実施の一形態によれば、所与のデータ・タイプについてそのサブタイプとスーパータイプを見つけることによって、このタクソノミを利用する。これについて以下に詳しく説明する。

説明を容易にするため、２つの関数、すなわちSuperTypes:Ｔ→２^Ｔと、SubTypes:Ｔ→２^Ｔを定める。ここで、２^Ｔはタイプの冪集合（集合の集合）であり、所与のタイプについて、その全てのスーパータイプとサブタイプをそれぞれ見い出すことができる。これらの２つの関数については直系に限られるという制約（direct restriction）は課されず、それゆえ、これらはタクソノミのルートまでの全てのスーパータイプと、タクソノミの下層（bottom）までの全てのサブタイプを見い出すことに留意されたい。これらの２つの関数は、２つの関係、すなわちSuperTypeとSubTypeから以下のように直接的に定義される。

平易な言葉で表現すれば、SuperTypeとSubTypeは入力された所与のタイプについて、タクソノミのルートまでの当該タイプの全てのスーパータイプと、タクソノミのリーフまでの当該タイプの全てのサブタイプを返すものである。

SuperType、SubTypeに加えて、タイプは「attribute（属性）」によっても関係付けられる。例えば、タイプAppointmentとタイプLocationとの間に関係atが存在し、タイプAppointmentとタイプTimeとの間に関係start_timeが存在する。

以下、本発明の実施の一形態において、SuperTypesをどのように実現できるかについて説明する。疑似的なコードにおいて以下のような手順となる。

SubTypesをハッシュテーブルとする。ただし、そのキーはタイプであり、その値はスーパータイプである（これはSuperType関係のある一つの可能な表現である）。

同様に、SubTypesの具体的な実装は以下のようになる。

SubTypesをハッシュテーブルとする。ただし、そのキーはタイプであり、値はスーパータイプである（これはSubTypeのある一つの可能な表現である）。

本発明の実施形態で用いるデータ・オブジェクトは、上述したタクソノミに属する。つまり、これらのデータ・オブジェクトはこのタクソノミに属するあるタイプのものである。このことについて次に詳しく説明する。

他の人々及びサービスとインタラクションすることによって、携帯電話機は上述したクラス・タクソノミ（class taxonomy）に基づいて分類されたデータ（又はデータ・オブジェクト）を得る。かかるデータは、１つ以上の属性を有する所与の（タクソノミに属する）タイプのデータ・オブジェクトとして表現される。これらの属性は、データ・オブジェクトの要素であるかもしれず、実施の一形態によれば、これらもこのタイプ・タクソノミに属する。形式的に、データ・オブジェクト（すなわち、データの集合Ｄに属するオブジェクト）をＴにおけるそれらの直系のタイプへとマッピングする関係type_of:Ｄ×Ｔが定義される。ここでも同様に、直系（direct）は、所与のデータｄについてｔ_１とｔ_２がｄのタイプである場合には、それらはスーパータイプという関係ではないことを意味する。

さらに、各データアイテムはタプルとしても表現される。ここで、タプルの各要素はデータのタイプの属性に対応するものである。例えば、アポイントメントａｐｐはタプル（tuple）＜ｌ，ｔ，ｐ，ａ，ｃ＞によって定義される。ここでｌはアポイントメントの場所（location）を示し、ｔはアポイントメントの時間（time）を示し、ｐはアポイントメントで会う人（peopele）を示し、ａはそこで行われる活動（activity）を示し、ｃはアポイントメントに関連するコスト（cost）を示す。同様に、このタプルの全ての要素は共有のタイプ・システム（タクソノミ）で定められたあるタイプのものである必要がある。

言い換えると、データ・オブジェクトはあるタイプを有し、それは、同じくあるタイプの更なる要素（属性）を有しており、それらのタイプは同一のタクソノミに属する。

所与のデータ・オブジェクトとその要素について、データ・オブジェクト又はその要素のタイプのそれぞれを返す関係又は関数type_ofが定義される。

関係type_ofに加えて、classifyと呼ばれる分類関数（classification function）を想定する。これは、所与のデータ（データ・オブジェクト）ｄについて、このｄがtype_ofという関係を通じて関係するタイプを返すものである。classify関数の計算は、メカニズムが実装されるフレームワークに依存する。オブジェクト指向プログラミングでは、あるデータのタイプはデータ生成の時点で明確に定義される。ロジック・ベースのフレームワーク、例えばDescription Logic（例えば非特許文献「F. Baader, D. Calvanese, D. McGuinness, D. Nardi and P. Patel-Schneider; “The Description Logic Handbook; Theory, Implementation and Applications" Cambridge University Press, 2003」）ベースのフレームワークでは、classify関数は自己推論（automatic inference）の形式として提供される。

当業者であれば、所与のデータ・オブジェクトについてデータのタイプを返す関数「classify」を容易に実装することができる。

最後に、２つの関数hasAttributesとattributesを定める。これらはそれぞれ、データが何らかの属性を有しているかどうかを検出し、そのデータ属性を抽出する。当業者であれば、当該システムを実装するために用いられる言語がサポートする形で既に実装されているこれらの関数を手に入れるであろう。一般に、どのタイプ・システムにも、データアイテムの属性にアクセスするための手段がある。例えば、あるタイプAppointmentが、属性として時間（time）、場所（location）、人（people）を有する場合には、どのアポイントメントデータappについても、例えばapp.time、app.location、app.peopleといったその属性を読み出すことができることになる。

既に定義した分類関数に加えて、実施の一形態によれば、データとタイプとの間のassociationという関係も必要となる。具体的には、ｄ＝＜ｋ_１，・・・，ｋ_ｎ＞の形式であるデータ・インスタンスｄは、以下の条件が成立する場合にのみ、タイプの集合Ａ＝ａｓｓｏｃｉａｔｅ（ｄ）⊆Ｔへと関連付けることができる。

最初の条件は、データ・インスタンスｄがそれ自体のタイプと関連していることを定めている。二番目の条件は、データ・インスタンスがタプルである場合には、データが、タプルの要素が関連付けられている全てのタイプと関連していることを定めている。

上記の定義は関数associateを再帰的な手順により計算するためのアルゴリズムも定義する。この再帰的手順は最初にデータの分類を計算し、二番目にデータの全ての属性を抽出し、三番目に各属性の関連（association）を計算する。

associationの一例として、タプルａｐｐ＝＜ｌ，ｔ，ｐ，ａ，ｃ＞として定義されるアポイントメントａｐｐについて説明する。このとき、associate(app)⊆{Appointment, Location, Time, People, Activity, Cost}である。関数associateは再帰的（recursive）であるため、Location、Time、People、Activity、Costの定義に応じて、集合内の他のタイプをもたらす可能性があるので、部分集合の関係が用いられていることに留意する。本例では、分類（classification）と関連付け（association）との違いも明確になる。アポイントメント自体は決して人（people）ではなく、だからPeopleというタイプに属するものとして分類することはできないが、かかるタイプに関連している。同様に、アポイントメントは場所（location）、又は時間（time）のインスタンスでないが、いずれにしてもそれらの概念と関連付けられる。

簡単に言えば、関数associationは、所与のデータ・オブジェクトについて、データ・オブジェクト自体のタイプに加えて、その属性又は要素のタイプも含むタイプの集合を返す。他方、分類関数（classifify関数）は、所与の入力データ・オブジェクトについて、このデータ・オブジェクト自体のタイプを返す。

全体のプロセスを再帰的なプロセス（recursive process）と見なすことができる。この再帰的なプロセスは、最初にあるデータ・オブジェクトに関してそのタイプを返し、次いでそのタイプの属性を見て、それらの属性のタイプを返し、続いて、返された（属性の）タイプに関して、それらがどの属性を有するかについて（もしあれば）再度見て、再びそれらのタイプが返され、関連するタイプの集合へと追加される。この再帰的な手順は、それ自体が更なる属性を有しないタイプに到達するまで繰り返される。

関数associateの具体的な実装例は、以下の疑似コードとして与えられる。

次に、本発明の実施の一形態によるサービス広告（service advertisements）について説明する。

サービスは、どのデータ・タイプについてモバイル・ユーザが当該サービスを利用するかを指定することにより、それ自体の広告を携帯電話機へ送る。例えば、ナビゲーションシステムは、Location又はRouteといったデータ・タイプと関連している。かかる指定は、サービスがタイプLocation又はタイプRouteの全てのデータと関連して利用できることを意味する。さらに、利用可能なデータの粒度（granularity）に合わせて、他の制約が表現される。例えば、ショッピング・モール（ＳＭ_１）などの所与の環境に限定されたナビゲーションシステムは、タイプSM₁∈subTypes(Location)の全てのデータを扱うことを指定することができる。この場合、ＳＭ_１はショッピング・モール内の様々な場所、例えば店舗、会合地点、飲食カウンタなどを示す。

形式的に、どのタイプのデータについてサービスが利用できるかを指定するためにサービスをタイプへとマッピングする利用関係ＵＳＥ：Ｓ×Ｔが定義される。上記の例で言えば、所与のモール内の場所と関連して用いられるモール・ナビゲーション・システムmallNavは、(ｍａｌｌＮａｖ ＵＳＥ ＳＭ)₁という式によりそれ自体を広告する。ＵＳＥの定義に関しては、サービスは必ずしも１つのタイプと利用を通じて関係していないことに留意すべきである。つまり、１つのサービスにつき複数の利用関係を定めることができる。

実施の一形態によれば、モバイル機器に実装又は提供されたサービスは、既に述べたように、どのタイプのデータをそのサービスが利用できるかを示すステートメントによってそれ自体を広告する。この広告を用いることにより、所与のデータ・タイプについて、例えば全ての利用関係を検索して、対象のデータ・タイプがそれらにおいて言及されているかどうかをチェックすることにより、どのサービスがこのデータ・タイプを利用できるかを決定することができる。代わりに、本システムはサービス広告に基づいてルックアップ・テーブルを構築及び保持する場合があり、これにより、どのサービスがあるデータ・タイプを利用できるかをチェックするための迅速な検索が可能となる。

既に述べた要素とオペレーション、すなわちタイプ・タクソノミ（type taxonomy）と、そのタクソノミに属するタイプ及び１つ以上の属性を有するデータ・オブジェクトと、データ・オブジェクトのタイプを返すclassify関数と、データ・オブジェクトに関連するタイプの集合を返すassociate関数と、サービスによって広告される利用ステートメントとを用いれば、以下に述べる実施の一形態による、見い出すためのメカニズムが実現される。ある意味において、見い出すためのメカニズムは、どのサービスがあるデータ・オブジェクトと適合するかを検出するマッチング・プロセスである。

実施の一形態において、マッチング・プロセスは２つの方向を有する。１つの方向は、データから始めてそのデータと関連して利用することができるサービスを見い出すものである。もう１つの方向は、サービスから始めてそのサービスに適用できるデータを見い出すものである。しかし、両者は独立しており、互いに独立して実装できる。まず、所与のデータ・オブジェクトに基づいてサービスを見い出すためのメカニズムについて説明する。

実施の一形態によれば、データからサービスへのこの第１のタイプのマッチングは以下のアルゴリズムに基づいている。

本アルゴリズムは、基本的には、ある所与のデータと関連して利用することができる全てのサービスを見つけるための、タイプ・タクソノミ全体にわたる検索である。より正確に言えば、第１行目は入力パラメータであるデータ・オブジェクトを指定し、第２行目は見つかったサービスを保存する変数（FoundList）を指定する。第３行目は検索の出発点となるタイプの集合を収集するための変数Ａを指定する。これらのタイプは定義２で述べたようなデータｄに関連するタイプである。第４行目は全ての関連するタイプ（関連タイプ）にわたる検索をトリガーし、第５行目はタイプの階層における検索の方向を定める。第６行目はタイプｕのデータを処理するために利用することができる全てのサービスを選択する。第７行目（オプション）は様々な基準に基づいてサービスを除外することができるフィルタを適用する。１つのこうしたタイプのフィルタについては後で説明する。最後に、第９行目は見つかったサービスのリストを返す。

タイプについて有限の集合が存在する場合には、本アルゴリズムの終了を常に容易に確認できる。なぜならば、最悪の場合、それらの全てがチェックされる必要があるが、いずれも２回以上チェックされることはないからである。

コンピュータ又は任意の類似のデバイスに実装可能な本アルゴリズムによれば、所与のデータ（データ・オブジェクト）と関連して利用することが可能なサービスを見い出すことができる。

次に、所与のサービスに基づいてデータを見い出すための更なる実施形態による第２のアルゴリズムについて説明する。

以下のアルゴリズム２によって詳しく示す二番目のタイプのマッチングは、先ほどのアルゴリズム１と同じような手順（アルゴリズム１との違いは、サービスｓが入力パラメータとして渡される点である）に基づいて、サービスをデータへとマッピングする。目的は、そのサービスが利用することのできるデータを見つけることである。

上記アルゴリズム２に詳しく示した二番目のタイプのマッチングは、associate関係に基づいて逆方向にサービスをデータへとマッピングする。より詳しく言えば、本アルゴリズムは、タイプｕと利用関係（第２行目）にあるサービスｓから出発し（第１行目）、保存のための変数FoundListを設定する（第３行目）。第４行目において検索を開始し、タイプｕのスーパータイプ及びサブタイプごとに、さらには、それらのタイプのデータ・インスタンスごとに（第５行目）、データがフィルタ・アウトされない場合には（第６行目）、そのタイプと関連するデータを見つけるためのプロシージャfindAssociatedが呼び出され（第７行目）、その結果がFoundListへと追加され、重複が全て取り除かれる（第８行目）。プロシージャfindAssociatedは、第１０行目から第１９行目に定義されている。このプロシージャは、逆方向に全ての属性関係をたどって、所与のデータｄを最初に導入したデータを見つけるためのものである。一例として、タイプappointmentの所与のオブジェクトappは、オブジェクトofficeによって特定される所与の場所となる属性locationを有する。次に、オブジェクトofficeから始めて逆方向に属性locationをたどり、オブジェクトappに戻る。当業者であれば本発明を実施する複数の方法を有する。例えば、あるデータｄが与えられたときに、dがその属性である全てのデータｇを検索するテーブルが保持される。より詳しく言えば、プロシージャfindAssociatedは、保存のための変数FoundListを定義し（第１１行目）、次に入力データｄから始めて、ｄがその属性である全てのオブジェクトｇを見つける（第１２行目）。かかるオブジェクトが見い出された場合には、ｇから開始してfindAssociatedを適用することによって見い出すことのできる全てのオブジェクトのリストが収集され（第１３行目）、FoundListのコンテンツに追加される（第１４行目）。次に、FoundListが空集合かどうかをチェックする。空集合は、データｄがどのオブジェクトの属性でもないことを意味する。したがって、ｄはFoundListに追加され、変数のコンテンツが返される。

実施の一形態によれば、リストへのデータｄの追加は、FoundListが空集合かどうかに関係なく行われる。これは、上記アルゴリズムにおける第１６行目をキャンセルすることで行うことができる。つまり、データｄのリストへの追加は、リストがそれまでの時点で空か否かに関係なく行われる。

次に、かかるアルゴリズムを実行する実施形態のより具体的な例を図２を参照して説明する。

図２を参照して説明する本実施形態は、アルゴリズム２の２つの利用ケースを提供する。第１の利用ケースでは、ユーザは、２００８年１０月２０日付のベルリンまでの鉄道のチケット（３０ユーロ）を既に持っているとする。この最初の利用ケースでは、鉄道の駅に到着した際に、ユーザの携帯電話機は、路線情報を通知するサービス（路線情報サービス）であって、宣言された利用がタイプ「鉄道チケット」であるサービスが存在することを検出する。アルゴリズム２を適用すると、第２行目は、サービスが利用するデータ、すなわち「鉄道チケット」を抽出する。第４行目と第５行目はタイプ「鉄道チケット」又はそのスーパータイプとサブタイプにおいて関連するデータの検索を行う。「鉄道チケット」のインスタンスである「ユーザ・チケット」が、見い出されたデータにおいて見つかる。「ユーザ・チケット」が第６行目でフィルタ・アウトされないとすると、それに関連するデータの検索が第７行目においてfindAssociatedの呼び出しによってトリガーされる。次いで最後に、第８行目において、見い出された全てのデータが、新たに見つかった路線情報サービスの候補データとして返される。このケースにおける関連するデータの計算は非常にシンプルである。第１２行目では、属性がユーザ・チケットである全てのデータｇを見つけ出す。このようなデータは何も見つからないので、第１２行目と第１５行目の間のループは決して実行されず、結果として、第１６行目における条件

が成立する。第１７行目において、ユーザ・チケットがFoundListに追加され、｛ユーザ・チケット｝が見い出されたデータの集合であることを報告することによって、その結果が第１９行目において最終的に返される。

第２の利用ケースでは、ユーザには新たなカレンダー・サービスが提供されるとする。この場合、カレンダーはその利用が「時間」オブジェクトであることを指定する。この場合、関連するデータの検索は先ほどのケースと同等である。具体的には、手順の最初として、タイプ「時間」又はそのスーパータイプもしくはサブタイプの全てのデータを探し出す。結果として、日付20.10.2008が恐らく他のデータ内に見つかる。第６行目においてそのデータがフィルタ・アウトされないとすると、第７行目において関連する全てのデータの検索がトリガーされる。今度はfindAssociatesがパラメータ20.10.2008について呼び出される。第１２行目では、日付20.10.2008を属性として持つ全てのデータｇを見つける。当然ながら、「ユーザ・チケット」が見つかる。第１３行目はfindAssociatesを「ユーザ・チケット」について再帰的に呼び出し、結果は、既に示したように集合｛ユーザ・チケット｝であり、これはｈに割り当てられる。第１４行目において、ｈの中味がFoundListに追加され、この時点でそのコンテンツは｛ユーザ・チケット｝であるという結果が得られる。もちろん、第１６行目における条件、すなわち

は成立せず、第１９行目においてFoundListのコンテンツが返される。

実施の一形態によれば、上記のアルゴリズムの第１２行目において実行される検索は、データｄを属性として有するタイプの検索といったものではなく、データｄのタイプを属性として有するタイプの検索といったものである。例えば、データｄが時間（例えば、Oct.20.2008）である場合には、属性としてタイプ「時間」を有する他のタイプの検索が存在する。この場合、上記のアルゴリズムの第１２行目は次のようになる。

更なる実施形態によれば、属性としてデータｄ自体又はデータｄのタイプを有するようなタイプ（及び／又はシステムに保存されたそれらの対応するオブジェクト）の検索が存在する。この場合、上記のアルゴリズムの第１２行目は次のようになる。

ここで、上記のアルゴリズムにおいて全てのサブタイプとスーパータイプが検索されることに留意すべきである。実施の一形態によれば、最初のアルゴリズムにおける検索はスーパータイプについてのみ行われる。なぜなら、それらについてのみ、スーパータイプに関連するサービスは、アルゴリズムの入力として利用されているデータのタイプも実際に利用できることが保証されるからであり、他方、サブタイプではこれは必ずしも当てはまらない。しかしながら、実施の一形態によれば、既に示したアルゴリズムは、利用される可能性のあるいずれのサービスもスクリーニング手順から外されないことを確実にするために、サブタイプも検索する。入力データ・オブジェクトを実際に利用しないようなサービスを除外するために、フィルタリング・アルゴリズム（既に「フィルタ」として述べたものである。詳しくは後述する。）が利用できる。

次に、実施の一形態によるフィルタ・アルゴリズムについてより詳しく説明する。

利用関係（usage relation）は、サービスが何に利用できるかを指定するが、そのサービスの呼び出し方は指定しない。結局のところ、利用関係はサービスが期待する入力及び出力へと変換される。このタスクを実行するため、「利用」からサービスの入力への下降関数（lowering function）を、ＳＡＷＳＤＬ（例えば、非特許文献「Joel Farrell, and Holger Lausen "Semantic Annotations for WSDL and XML Schema -W3C Recommendation 28 August 2007" Available at http://www.w3.org/TR/sawsdl/; Last viewed on October 1st 2008」参照）における入力下降関数（inputs lowering functions）と同じような方法で定めることができる。具体的には、サービスｓを所与として、Ｉをサービスｓの入力とし、Ｕをサービスの利用関係とすると、サービスの下降関数はｌｏｗｅｒ_s：Ｕ_ｓ→Ｉ_ｓで定義される。これは、Ｕ_ｓと整合するように定義されたデータを、サービスが必要とする入力の集合Ｉ_ｓにおいてどのように変換できるかを定める。例えば、アポイントメントを所与とすると、下降関数はルーティングサービスによって処理可能な方法で場所とフォーマットをどのように抽出するかを指定することができる。

かかる下降関数は、利用可能なデータから容易に呼び出すことができるサービスを見い出す（上記のアルゴリズム１とアルゴリズム２で用いた）メカニズムのフィルタとしても利用することができる。具体的には、何らかのデータｄと、所与のサービスｓについて定義された下降関数ｌｏｗｅｒ_ｓを所与として、ｌｏｗｅｒ_ｓの適用がｄをｓの入力へと変換することに成功する場合に、ｓはｄへ適用可能である。結果として、それは保持される。代わりにｌｏｗｅｒ_ｓが変換に失敗すると、ｓはｄに適用することができず、ｓは提案すべきサービスのリストから除外される。

実施の一形態によれば、下降関数はサービスを定めるときに同時に定められる。それゆえ、プログラマがサービスを生成するときに、プログラマはサービスをタイプへと関連付けることによってサービスの利用関係を指定し、それと同時に、プログラマはサービスへの入力を提供するためにそのタイプのデータがどのように利用できるかを指定する。後者の指定は下降関数の指定により行われる。

既に説明したように、マッチング・プロセスは、既に定めたアルゴリズム１とアルゴリズム２によって実行できる。具体的には、新たなデータｄを受信した際に、携帯電話機はアルゴリズム１に従って、このデータと関連して利用できる全てのサービスを見い出す。逆に、新たなサービスｓを見い出した際は、アルゴリズム２を用いてその新たなサービスが適用される全てのデータを見い出す。

例えば、航空チケットを受け取ると、アルゴリズム１は、フライトの時刻を記録するためのカレンダー（calendar）、又はチケットを保管するための電子財布（e-wallet）、空港へ行くためのナビゲーション（navigation）といったサービスを見つける。さらに、空港に入り、利用可能なゲート情報サービスが存在することを見い出すと、アルゴリズム２は、そのサービスがユーザの航空チケットと関連して利用できることを自動的に見い出す。

次に、図１を参照して検索メカニズムの一実施形態について詳しく説明する。図１において、丸印はユーザのシステムにおいて利用可能なタイプを表し、丸印と丸印との間のダウンリンク（下向きの実線矢印）は、それらのタイプ間のスーパータイプ関係・サブタイプ関係を表す。さらに、丸印のラベルが長い場合には、その丸印の上あるいはその隣にラベルを示している。また、本図の左側には３つのノードが示されている。左から１番目のノードは、タイプＭｏｎｅｙに対応するラベルＭを持ち、左から２番目のノードはタイプＴｉｍｅに対応するラベルＴを持ち、左から３番目のノードはタイプＬｏｃａｔｉｏｎに対応するラベルＬを持つ。図の右側には、「チケット」、「鉄道チケット」、「航空チケット」として示されている３つのノードが存在し、それらのラベルはそれぞれ、システムにとっては既知のチケットのタイプを表している。

タイプに加えて、図１は、ユーザにとっては既知の（かつ、既に述べたように広告されている）サービスを示している。図において、サービスはグレーで塗りつぶされた、ラベルを付した六角形で示されている。具体的には、図の中には、「電子財布」、「カレンダー」、「ナビゲーション」、「路線情報」、「チェックイン」として示されたサービスが存在する。サービスは、タイプと関連して利用されるように自らを広告宣伝する。かかる広告は対応するタイプに重なっている空の六角形で示されている。図に示した様に、電子財布サービスは、タイプ「金」のデータと関連して利用され、カレンダー・サービスは、タイプ「時間」のデータと関連して利用され、ナビゲーション・サービスは、タイプ「位置」のデータと関連して利用され、路線情報サービスは、タイプ「鉄道チケット」のデータと関連して利用され、チェックイン・サービスは、タイプ「航空チケット」のデータと関連して利用されるものである。

図１においてユーザのデータは、ラベルが付されたグレーの丸印で表されており、これらはtype_ofという関係を通じて、対応するタイプとリンクしている。本例では、ユーザは、「鉄道チケット」というタイプに指定されている、「ユーザ・チケット」というラベルが付された鉄道チケットを購入する。「ユーザ・チケット」は３つの属性を持つ。１つ目はタイプ「金」に指定された「３０ユーロ」のコストであり、２つ目は「時」というタイプである「20.10.2008」という旅行日であり、３つ目は旅行先、すなわち「位置」というタイプの「ベルリン中央駅」である。

概説したように、「ユーザ・チケット」は、その属性に対応するタプル＜３０ユーロ，20.10.2008，ベルリン＞として定義される。（例えば、ユーザがチケットを購入した後にＳＭＳによって、又はインターネットを通じて、）チケットがユーザのデータのデータに追加されるときに、アルゴリズム１が実行される。具体的には、最初のステップは、変数Ａに保存される関連するタイプのリストを計算することである。かかる計算は、定義２に明示された条件によって行われる。具体的には、タイプ「鉄道チケット」がＡに追加される。なぜなら、それは「ユーザ・チケット」の分類の結果であるため、定義２の最初の条件を満足するからである。それに対し、タイプ「金」、「時間」、「位置」は、「ユーザ・チケット」の属性のタイプであるので、定義２の二番目の条件によって追加される。後者の追加は、定義２の条件２に定義された再帰的呼び出しにより計算され、これはそれらのタイプを検索する全ての属性に対する定義２の条件１の再適用をもたらす。この計算の結果、変数Ａはタイプとして「鉄道チケット」、「金」、「時間」、「位置」を含むものとなる。

アルゴリズムにおける次のステップは、タイプ・システムの検索である。本例では、簡単にするためにタイプ分類はあまり条件が付いていないので、かかる検索は明らかなものである。それでもなお、アルゴリズム１の第５行目と第６行目に定義されたループを通じて、サービス「電子財布」、「カレンダー」、「ナビゲーション」、「路線情報」が検索される。それらのどれもが除外（フィルタリング）されないという仮定のもとで、それらはFoundListへと追加され、検索されたサービスとして返される。サービス検索の結果は、図１においてサービス名の下のアンダーラインで示している。サービス「チェックイン」は「ユーザ・チケット」に関連するものとして認識されないタイプで利用されるべきものであるため、サービス「チェックイン」は見い出されていないことが分かる。

アルゴリズム１の第７行目において一部のサービスがどのようにフィルタ・アウトされるかを示す例として、チケットの行き先、すなわち「ベルリン中央駅」のケースを考える。ナビゲーション・サービスは入力としてアドレスを要求するが、「ベルリン中央駅」にアドレスが全く与えられていない場合には、サービスの下降関数は場所をサービスの入力へとマッピングすることができず、その結果として「ナビゲーション」はフィルタ・アウトされる。このようなケースでは、FoundListは「電子財布」、「カレンダー」、「路線情報」だけを含む。

本発明の実施形態は、上記のメカニズムを用いて適切にプログラムされていれば、例えばＰＣ又は携帯電話機などの任意の計算装置で実施することができる。

上記のメカニズムは携帯電話機のソフトウェア・アーキテクチャに明示的な仮定を一切要求しないものの、様々なアプリケーションが互いにやり取りできる、あるいは実施の一形態によれば全てのアプリケーションが共用の空間にデータを一緒にプールするという、暗示的な仮定が存在する。これは、見い出すためのメカニズムが機能することを可能にする１つの実装例である。実際、チケットの行き先が他のアプリケーションにとって利用不可能なものである場合には、それに見合うサービスを見つけることは不可能であろう、ということは明らかである。

第２の暗示的な仮定は、タイプ・タクソノミが共通のものであるということである。実際、携帯電話機において場所の定義がまちまちなタイプが存在したとしたら、全ての場所を扱うサービスを見い出すことは不可能であろう。

ただ、システムが徐々に劣化すると、両方の仮定が破られる可能性がある。実際、アプリケーションがそれらのデータの一部をプライベート（自己のため）に保持する場合には、利用可能にしているものを除いては、検索するために利用することができなくなる可能性がある。同様に、携帯電話機に異なる２つの場所の定義が存在したとしたら、見い出すためのアルゴリズムはどの時点でも全てではなく一部のロケーションサービスしか見つけられない可能性がある。

上記のメカニズムの具体的な実装には様々な方法がある。特に、共にテスト版として実装した異なる２つの方法でアルゴリズムを実装することができる。第１の実装は分類関数を計算するＯＷＬ推論エンジンを利用する。結果として、アルゴリズム１とアルゴリズム２の第５行目で始まるループは、use(s)>classify(d)、かつclassify(d)>use(s)を満たすような全てのサービスｓのクエリーへと単純化される。ここで「＞」は、より一般的なクラスを意味する関係である。本実装の利点は常に正しいということであるが、コストが高くなる可能性のある２つのクエリーを実行する必要がある。

第２の実装は、タイプ・システムにおいて名前の付いたクラスごとに、そのクラスを処理するために利用することができるサービスを特定する前処理に基づいている。具体的には、サービスｓごとに、サービスの用途ｕを特定し、次に、対応（ｕ×ｓ）のほかに、ｃ＜ｕ又はｕ＜ｃを満たすようなクラスｃについて（ｃ×ｓ）も記録する。このときマッチングは、見い出されるサービスについて（classify(d)× s）が成立するテーブル検索に単純化される。

上記の実施形態では具体的かつ特定の実施形態を説明したが、以下、図３を参照して包括的な更なる実施形態について説明する。

ステップ３００において、タクソノミに属するデータ・オブジェクトであって、同じくタクソノミに属する１つ以上の属性を有するデータ・オブジェクトが入力される。

ステップ３１０において、オブジェクト自体のタイプを含むほかにその属性のタイプも含む関連するタイプの集合が決定される。このステップは、属性のタイプの属性についても、それら自体がこれ以上更なる属性を含まないタイプに到達するまで、再帰的に実行することができる。結果的に得られるタイプのリストは、入力されたデータ・オブジェクトの「関連するタイプ」である。

次にステップ３２０（オプションであるが本実施形態には含まれる）において、ステップ３１０で決定された関連するタイプのリストに含まれるタイプの全てのスーパータイプを見つける。

次にステップ３３０（これもオプションであるが本実施形態には含まれる）において、ステップ３１０で決定された関連するタイプのリストに含まれるタイプの全てのサブタイプを見つける。

次いでステップ３４０において、見つかった全てのタイプについて、見つかったタイプを利用することができるサービスが決定される。見つかったサービスは、次にステップ３５０において、見つかったサービスであって入力されたデータ・オブジェクトを活用できるか又は利用できるサービスを含む最終的なリストに蓄積される。

見つかったサービスが入力データを実際に利用できるか否かのチェックに基づいて、見つかったサービスをフィルタリングするフィルタリング・ステップがオプションとして含まれる。これは、先の実施形態に関連して説明した下降関数（lowering function）によって行うことができる。

次に、図４を参照して、所与のサービス（例えば、新規に導入されたサービス、又はある特定のエリアで急遽利用可能になったサービス）が利用することができるデータを見つける実施形態について説明する。

ステップ４００において、サービスが利用可能となる。

ステップ４１０において、サービスが宣言されているデータ・タイプが決定される。これらのタイプ及び／又はそれらのインスタンス（当該タイプのデータ・オブジェクト）は、当該サービスが利用することができるデータのリストへと追加される。例えば、保存されたデータの中から、サービスが宣言されている１つ以上のタイプに属するデータ・オブジェクトが検索される。

ステップ４２０において、見つかったタイプ及び／又はそれらのインスタンス（データ・オブジェクト）が、サービスが宣言されているタイプ及び／又はサービスが宣言されているタイプのデータ・オブジェクトを含む集合へと追加される。

次にステップ４３０において、いわゆる「関連するタイプ」及び／又は「関連するデータ・オブジェクト」が検索される。これらは、ステップ４２０で見つかったデータ・タイプ又はインスタンスの１つ以上を属性として有するタイプ又はデータ・オブジェクトである。

ステップ４４０において、関連するタイプ及び／又はインスタンスをリストへと追加する。

実施の一形態によれば、（関連するタイプ又はオブジェクトを見つける）ステップ４３０及び４４０は、サービスが宣言されているタイプのスーパータイプについても実行される。なお更なる実施形態によれば、それらはサービスが宣言されているタイプのサブタイプについても実行される。

サービスが宣言されたタイプは、実施の一形態によればサービスの広告から得られる。サービスは、何らかの宣言又は定義により、当該サービスが扱えるデータのタイプ（つまり扱えるのはどのタイプか）をシステムへ通知する。次いでそれに基づいて、図４を参照して述べた方法を実行する。

実施の一形態によれば、見つかった全てのタイプについて、そのデータがサービスによって利用可能かどうかがチェックされる。これは、フィルタ（例えば既に述べた下降関数など）が何も適用されないかどうかをチェックすることによって行われる。基本的に、これは、見つかったデータ・タイプをサービスが実際に利用できるかどうかのチェックである。下降関数を用いると、見つかったデータ・タイプがサービスによって利用できることとなる。

データ・タイプが利用可能である場合には、そのデータ・タイプは、サービスが利用することができるデータ・タイプ及び／又はオブジェクトの最終リストへと追加される。

このチェックの手順はオプションであり、省略可能である。しかし、省略した場合には、最終のリスト内のデータを利用しようとするときに多くのエラーが発生する可能性がある。

本発明の実施形態を説明し終わったところで、次に、これらの実施形態の効果と利点を従来技術と比較しながら説明する。まず、ＭＩＭＥタイプに基づくアプリケーションタイプの検出との比較を行う。

第１の違いは、本発明の実施形態では、あるデータを所与として、それを処理することができるアプリケーションを自動的に見つける検索、あるいは逆に、アプリケーションを所与として、それが適用される全てのデータを見つける検索を実行するという点にある。検索を定めることにより、所与のタイプを扱うアプリケーションが指定されない場合でも、上述のアルゴリズムはそのようなアプリケーションが利用可能な場合にそれを見つけ出して、適切に指定される。一例として、例えばルフトハンザ航空といった航空会社は、拡張子「.lh」を航空チケットと関連付け、ユーザはこの拡張子を「Microsoft Word」と関連付ける。例えば「OpenOffice」といった新たなワードプロセッサ（アプリケーション）がユーザのコンピュータにダウンロードされている場合には、たとえそれがタイプ「.lh」のファイルを開くことができたとしても、それがユーザに提示されることはない。さらに、ユーザが別の会社、例えば拡張子「.az」を有するアリタリア航空から新たな航空チケットを購入する場合には、タイプ「.az」とタイプ「.lh」のオブジェクトが同じタイプの情報を含むにもかかわらず、「.lh」ファイルについて利用されるアプリケーションは何も提示されないことになる。他方、本発明の実施形態によるメカニズムでは、「.az」ファイルと「.lh」ファイルが（「航空チケット」が両方のタイプのスーパータイプであるために）両方とも航空チケットを表していることを認識することにより、両方のワードプロセッサが両方のタイプのファイルへと自動的に関連付けられる。したがって、航空チケットに適用される全てのサービスが有効なサービスである可能性がある。

さらに、テーブルの利用は、上述のＭｉｍｅタイプ・システムの場合のように、ファイルのコンテンツに対してきめ細かく対応できるというわけではない。具体的には、ファイルタイプとアプリケーションとの間の関連付けは常に結果として、ファイル内の情報の中味に関係なく、同じ集合のアプリケーションをもたらす。他方、本発明の実施形態による検索アルゴリズムは、宣言されたタイプのファイル（又は宣言されたタイプのデータ）のみを利用するわけではなく、その中味も利用する。なぜならば、それはデータ・オブジェクトの属性（要素）も含むからである。それゆえ、データ情報を含む航空チケットなどのファイルは、宣言されたタイプのファイルとは無関係に、カレンダーと関連付けられる場合がある。これは、アプリケーションとタイプとの間に決まった関係が存在する場合は不可能である。

したがって、上記の実施形態による検索プロセスは、Ｍｉｍｅタイプと、メールクライアントなどのコンピュータ・オペレーティング・システムのアプリケーションとにマッチさせるために用いられるテーブルといった固定テーブルを利用することではマッチさせることのできない機能性を実現する。

既に述べたアプローチに加えて、あるサービスを何らかのデータと関連付ける問題は、コンピュータの機能をそのデータと関連付ける問題と見なすことができる。この場合、本発明が扱う問題は、オブジェクト指向システムにおける方法（method）をデータと関連付ける問題と類似している。これらのオブジェクト指向システムでは、データはタイプ・タクソノミに基づいて編成され、方法は異なるタイプと関連付けられる。所与のタイプのデータが与えられると、そのタイプのために作られているか、あるいはより一般的なタイプのために作られている全ての方法が適用できる。ｘを何らかのデータ、ｍを方法として、ｘ．ｍが呼び出されると、ｍのより具体的な定義が検索されて、ｘへと適用される。オブジェクト指向システムにおける方法検索は、本願が提案する検索とある程度類似していると考えることはできるが、根本的な相違点が存在する。

まず、オブジェクト指向システムにおける全ての検索は、より包括的なタイプを目指す上方検索のみが行われ、方法の第１番目の定義が見つかるとすぐに終了する。これに対し、本発明の実施形態では、利用可能な情報について見つかったサービスが適用できるという制約のある形態によれば、最も具体的なタイプを探す「下方」検索も可能である。

第２の相違点は、オブジェクト指向システムではプログラマは所与の時間においてどういった方法が適用されるかを指定し、適用可能な全ての方法を見つけるというよりも、その特定の方法だけの検索が実行されるという点である。他方、本発明の実施の一形態によれば、適用可能な全てのサービスが検索される。さらに、上記の検索は、プログラムを実行する際に動的にロードされた方法を認識することがある。本発明の実施の一形態によるメカニズムは、新たなサービスと新たなデータが利用可能となる実行時に機能するものである。

第３の相違点は、オブジェクト指向システムにおける検索は、データの中味を見ずに、データの一部だけを処理する追加の機能を探すという点である。例えば、オブジェクト指向システムは、「航空チケット」のためのタイプを有し、そのタイプのデータへ適用される全ての機能を探す。さらに、航空チケットの１つの要素は旅行日であり、このためカレンダリング法が適用可能である。その上、かかる方法はタクソノミの異なるブランチに存在することとなるため、それらは見い出すことができない。他方、本発明の実施の一形態によるメカニズムは、カレンダリング法に関連するサービスについて作成かつチェックされた関連するタイプのリストにより、このようなカレンダリング法を見つけることができる。

以上のことから、本発明の実施形態によるメカニズムは、より具体的なタイプのほかに、タイプもしくはタクソノミ・ツリーの関係のない他のブランチ上に存在するタイプの両方への、制御された拡張性を持つメカニズムを提供するものである。

当業者であれば、ここで述べた実施形態は、ハードウェア、ソフトウェア、ハードウェアとソフトウェアの組み合わせによって実施できることを理解するであろう。本発明の実施形態に関連して説明したモジュール及び機能は、その全体又は一部が、本発明の実施形態に関連して説明した方法に従って動作するように適切にプログラムされたマイクロプロセッサ又はコンピュータによって実現することができる。本発明の実施形態を実現する装置は、例えばコンピュータ、ＰＤＡ、携帯電話機、スマート・フォンその他の類似物を含む。

Claims (12)

1. コンピュータを用いて、あるデータ・オブジェクトについて、該データ・オブジェクトを入力として利用することができるサービスを検出する方法であって、
   タイプについてのタクソノミであって、あるタイプがスーパータイプとサブタイプとを有する階層構造を持つタクソノミを提供するステップと、
   前記タクソノミに属するタイプを有するデータ・オブジェクトを受け取るステップであって、該データ・オブジェクトは、その要素として１つ以上の属性を持ち、該属性は、前記タクソノミに属するタイプのものである、ステップと、
   前記データ・オブジェクトのデータ・タイプと、前記１つ以上の属性のデータ・タイプとを得て、これらを前記データ・オブジェクトに関連付けられるタイプのリストに蓄積するステップと、
   前記関連付けられるタイプのリストに含まれる全てのタイプについて、それらのタイプを利用することのできるサービスを得て、入力されたデータを利用することができるサービスのリストを得るステップと
   を含む方法。
2. 前記関連付けられるタイプのリストに含まれる全てのデータ・タイプについて、前記タクソノミにおいて対応するスーパータイプと、それらに関連付けられるサービスとを見つけて、それらをサービスのリストへと追加するステップを更に含む請求項１に記載の方法。
3. 前記関連付けられるタイプのリストに含まれる全てのデータ・タイプについて、前記タクソノミにおいて対応するサブタイプと、それらに関連付けられるサービスとを見つけて、それらをサービスのリストへと追加するステップを更に含む請求項１又は２に記載の方法。
4. 見つかったサービスの入力として前記データが実際に利用できるかどうかをチェックするフィルタリングを見つかったサービスへと適用し、当該データが利用できない場合には、前記サービスのリストから対応するサービスを除外するステップを更に含む請求項１〜３のいずれか一項に記載の方法。
5. コンピュータを用いて、あるサービスについて、該サービスを入力として利用することのできる保存されたデータ・オブジェクトを検出する方法であって、
   タイプについてのタクソノミであって、あるタイプがスーパータイプとサブタイプとを有する階層構造を持つタクソノミを提供するステップであって、複数のデータ・オブジェクトは前記コンピュータに保存されており、更に前記データ・オブジェクトはその要素として１つ以上の属性を持ち、該属性は、前記タクソノミに属するあるタイプのものである、ステップと、
   前記サービスが宣言されているデータの１つ以上のタイプのそれぞれについて、関連付けられるデータ・オブジェクトの集合を見つけるステップであって、前記サービスが宣言されている少なくとも１つのデータ・タイプ又はデータ・タイプのインスタンスを属性として持つデータ・オブジェクトを保存されたデータの中から見つけるサブステップを含み、該属性は保存されたデータ・オブジェクトの要素である、ステップと、
   見つかったデータ・オブジェクトを、前記サービスが入力として利用するデータ・オブジェクトのリストへと追加するステップと
   を含む方法。
6. 前記サービスが宣言されている全てのデータ・タイプについて、対応するスーパータイプを前記タクソノミにおいて見つけるステップと、
   見つかったスーパータイプのそれぞれについて、関連するデータ・オブジェクトの集合を見つけて、それを前記リストへと追加するステップと
   を更に含む請求項５に記載の方法。
7. 前記サービスが宣言されている全てのデータ・タイプについて、対応するサブタイプを前記タクソノミにおいて見つけるステップと、
   見つかったサブタイプのそれぞれについて、関連するデータ・オブジェクトの集合を見つけて、それを前記リストへと追加するステップと
   を更に含む請求項５又は６に記載の方法。
8. 所与のサービスについて、見つかったデータ・オブジェクトが実際に入力として利用できるかどうかをチェックするフィルタリングを見つかったデータ・オブジェクトへと適用し、当該データ・オブジェクトが利用できない場合には、前記データ・オブジェクトのリストから対応するデータ・オブジェクトを除外するステップを更に含む請求項５〜７のいずれか一項に記載の方法。
9. あるデータ・オブジェクトについて、該データ・オブジェクトを入力として利用することができるサービスを検出する装置であって、
   タイプについてのタクソノミであって、あるタイプがスーパータイプとサブタイプとを有する階層構造を持つタクソノミを提供するモジュールと、
   前記タクソノミに属するタイプを有するデータ・オブジェクトを受け取るモジュールであって、該データ・オブジェクトはその要素として１つ以上の属性を有し、該属性は前記タクソノミに属するタイプのものである、モジュールと、
   前記データ・オブジェクトのデータ・タイプと、前記１つ以上の属性のデータ・タイプとを得て、それらを前記データ・オブジェクトに関連付けられるタイプのリストに蓄積するモジュールと、
   前記関連付けられるタイプのリストに含まれる全てのタイプについて、それらのタイプを利用することができるサービスを得て、入力されたデータを利用することができるサービスのリストを得るモジュールと
   を備えている装置。
10. あるサービスについて、該サービスが入力として利用することのできる保存されたデータ・オブジェクトを検出する装置であって、
    前記サービスが宣言されているデータの１つ以上のタイプのそれぞれについて、関連付けられるデータ・オブジェクトの集合を見つけるモジュールであって、前記サービスが宣言されている少なくとも１つのデータ・タイプ又はデータ・タイプのインスタンスを属性として持つデータ・オブジェクトを保存されたデータの中から見つけるモジュールであり、該属性は保存されたデータ・オブジェクトの要素である、モジュールと、
    見つかったデータ・オブジェクトを、前記サービスが入力として利用するデータ・オブジェクトの集合へと追加するモジュールと
    を備えている装置。
11. 請求項２〜４、６〜８のいずれか一項に記載のステップを実行するモジュールを更に備えている請求項９又は１０に記載の装置。
12. 請求項１〜８のいずれか一項に記載の方法をコンピュータに実行させるコンピュータ・プログラム・コードを含むコンピュータ・プログラム。

Images