(57)【要約】      （修正有）【課題】モバイル機器のユーザの現在位置で最も望ましいサービスを推奨している場所に移動するときに、モバイル機器の近くで位置に結びつけられたサービスの利用を可能にする。【解決手段】１又は複数のサービス提供サーバからネットワークを介して端末装置に提供可能な複数のサービスのうち、利用可能なサービスを抽出し当該抽出したサービスに関する情報を前記端末装置に提供するサービス管理サーバであって、前記端末装置からの現在位置を伴う要求に応じて、当該現在位置にマッチしている複数のサービスを抽出するサービス抽出手段と、データベースに予め登録された前記端末装置のユーザのサービス利用履歴に基いて、前記抽出されたサービス毎に好み度を計算する好み度計算手段と、前記抽出されたサービスのうちの全部又は一部のサービスに関する情報と当該サービス毎の前記好み度を示す情報を前記端末装置に送信する情報送信手段と、を備える。【選択図】図１
2009145982.tif 000002
【特許請求の範囲】
【請求項１】
１又は複数のサービス提供サーバからネットワークを介して端末装置に提供可能な複数のサービスのうち、利用可能なサービスを抽出し当該抽出したサービスに関する情報を前記端末装置に提供するサービス管理サーバであって、
前記端末装置からの現在位置を伴う要求に応じて、当該現在位置にマッチしている複数のサービスを抽出するサービス抽出手段と、
データベースに予め登録された前記端末装置のユーザのサービス利用履歴に基いて、前記抽出されたサービス毎に好み度を計算する好み度計算手段と、
前記抽出されたサービスのうちの全部又は一部のサービスに関する情報と当該サービス毎の前記好み度を示す情報を前記端末装置に送信する情報送信手段と、
を備えることを特徴とするサービス管理サーバ。
【請求項２】
請求項１に記載のサービス管理サーバにおいて、
前記好み度計算手段は、前記ユーザのサービス利用履歴に基づき、前記抽出されたサービスの利用時間又は利用回数に基づく確率を計算し、当該確率と前記抽出されたサービスの価格に基づいて、前記好み度を計算することを特徴とするサービス管理サーバ。
【請求項３】
請求項２に記載のサービス管理サーバにおいて、
前記好み度計算手段は、前記確率と前記価格に基づくメンバーシップ関数を用いて前記好み度を計算することを特徴とするサービス管理サーバ。
【請求項４】
１又は複数のサービス提供サーバからネットワークを介して端末装置に提供可能な複数のサービスのうち、利用可能なサービスを抽出し当該抽出したサービスに関する情報を前記端末装置に提供するサービス管理サーバにおけるサービス情報提供方法であって、
前記端末装置からの現在位置を伴う要求に応じて、当該現在位置にマッチしている複数のサービスを抽出する工程と、
データベースに予め登録された前記端末装置のユーザのサービス利用履歴に基いて、前記抽出されたサービス毎に好み度を計算する工程と、
前記抽出されたサービスのうちの全部又は一部のサービスに関する情報と当該サービス毎の前記好み度を示す情報を前記端末装置に送信する工程と、
を備えることを特徴とするサービス情報提供方法。
【請求項５】
１又は複数のサービス提供サーバからネットワークを介して端末装置に提供可能な複数のサービスのうち、利用可能なサービスを抽出し当該抽出したサービスに関する情報を前記端末装置に提供するコンピュータを、
前記端末装置からの現在位置を伴う要求に応じて、当該現在位置にマッチしている複数のサービスを抽出するサービス抽出手段、
データベースに予め登録された前記端末装置のユーザのサービス利用履歴に基いて、前記抽出されたサービス毎に好み度を計算する好み度計算手段、及び、
前記抽出されたサービスのうちの全部又は一部のサービスに関する情報と当該サービス毎の前記好み度を示す情報を前記端末装置に送信する情報送信手段として機能させることを特徴とするサービス情報提供プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアアプリケーションのシステムに関し、特に、特定のサービスを提供するサーバから受信された特有のデータから構成され、動的に生成（作成）されるユーザインターフェイスを通して、ユーザの嗜好とモバイル機器上におけるサービス利用に基づく自動的な位置ベースのサービス発見及びサービス推奨の技術分野に関する。
【背景技術】
【０００２】
GPSを代表とする全世界的位置発見機能は、携帯電話、ＰＤＡ（Personal Data Assistants），ラップトップなどのモバイル機器の標準的な特徴になりつつある。
【０００３】
そのため、手持ちサイズのモバイル機器に対しては、位置発見機能を活用する新しいソウトウェアへの要望が増加しており、既に、世界中の多くの企業により多くのアプリケーションが開発されている。その一例として、ナビゲーションソフトウェアが挙げられ、これは市場に受け入れられている。
【０００４】
一方、前述した位置発見機能の領域における技術革新の多くは、モバイル機器の位置に応じて動作する機器内にインストールされたモバイル向けアプリケーションにより、利用者にある機能または情報を提供するサービスに過ぎない。つまり、ただ位置情報を活用したサービスの開発が注力されており、ユーザに事前のインストールを必要とするアプリケーションを作る代わりに、特定の位置と提供する個々のサービスを結びつけ、アプリケーションをインストールすることなく、それらサービスを端末の位置情報に応じて提供する方法はそれほど考えられていない。
【０００５】
例えば、特許文献１には、ユーザの位置情報、好み情報等に応じて適切な情報を適確に提供しうるモバイルユーザ向け情報案内方法が開示されているが、特定のユーザに対して、ある位置において最も好ましいサービスを自動的に提供する推薦機能は，この技術領域ではまだ開発されていない。
【０００６】
そこで、手持ちサイズのモバイル機器の持つグラフィック能力を活用し、さまざまなサービスを提供するアプリケーションをユーザに、動的かつ位置情報に応じて提供する必要性は間違いなく存在するといえる。
【特許文献１】特開平１１−０５５７２６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
現在、ユーザにさまざまなサービスを提供する方法として広く利用されているものはWorld Wide Webであろう。しかし、World Wide Webは位置情報を考慮して設計がされていないため、HTMLから生成される描画レイアウト情報を持つ各種サービスを提供するための枠組みには明らかに限界がある。また、World Wide Webはインターネットを介してどこからでもアクセスを可能とする連結されたハイパーテキストドキュメントから成るシステムである。つまり、World Wide Webによる個々のWebサービスにリンクされるものは何であれ、位置情報を持たないデータである。それ故、ユーザの位置情報に基づき、個々のサービスを発見することや、グループ化することができない。さらに重要な点は、それらのことに利用者の嗜好が反映されないことである。
【０００８】
それ故、ユーザはサービス利用に必要なURLを覚えておく、もしくはサーチエンジンを使うなどして、必要となるサービスを見つけるための方法が分からなくてはならない。つまり、World Wide Webでは、ユーザがサービスを見つけることは困難である。その上、ユーザが個々のサービスを使用する方法を自動追跡し、この情報に基づいて推薦を行うことは、ユーザ自身による自主的な申告などの行動を必要とせずに実践するには困難な課題である。
【０００９】
これら上述した制約を打開するシステムによりサービスを実施するために、位置情報と結び付けられたサービスに着目し、ユーザのサービス利用傾向を追跡する手法を初めからとる必要がある。これにより、ユーザは現状のWorld Wide Webの提供するサービスから自身のモバイル端末を通して、位置情報、嗜好情報により自動的に位置情報と結びついたサービスに移行することが可能となる。
【００１０】
本発明は、2つの課題を解決するものである。１つはモバイル機器がある場所から別の場所に移動した際に、モバイル機器を所持するユーザに、現在の位置における最も好ましいサービスを常に推薦するために、モバイル機器の近傍で有効な、位置情報と結び付けられたサービスを自動的に発見することである。もう1つは特定のモバイル機器のために調整されたユーザインターフェイスを自動的に生成し、これを使うことにより、個々のサービスを利用可能にすることである。
【課題を解決するための手段】
【００１１】
上記課題を解決するために、請求項１に記載の発明は、１又は複数のサービス提供サーバからネットワークを介して端末装置に提供可能な複数のサービスのうち、利用可能なサービスを抽出し当該抽出したサービスに関する情報を前記端末装置に提供するサービス管理サーバであって、前記端末装置からの現在位置を伴う要求に応じて、当該現在位置にマッチしている複数のサービスを抽出するサービス抽出手段と、データベースに予め登録された前記端末装置のユーザのサービス利用履歴に基いて、前記抽出されたサービス毎に好み度を計算する好み度計算手段と、前記抽出されたサービスのうちの全部又は一部のサービスに関する情報と当該サービス毎の前記好み度を示す情報を前記端末装置に送信する情報送信手段と、を備えることを特徴とする。
【００１２】
請求項２に記載の発明は、請求項１に記載のサービス管理サーバにおいて、前記好み度計算手段は、前記ユーザのサービス利用履歴に基づき、前記抽出されたサービスの利用時間又は利用回数に基づく確率を計算し、当該確率と前記抽出されたサービスの価格に基づいて、前記好み度を計算することを特徴とする。
【００１３】
請求項３に記載の発明は、請求項２に記載のサービス管理サーバにおいて、前記好み度計算手段は、前記確率と前記価格に基づくメンバーシップ関数を用いて前記好み度を計算することを特徴とする。
【００１４】
請求項４に記載の発明は、１又は複数のサービス提供サーバからネットワークを介して端末装置に提供可能な複数のサービスのうち、利用可能なサービスを抽出し当該抽出したサービスに関する情報を前記端末装置に提供するサービス管理サーバにおけるサービス情報提供方法であって、前記端末装置からの現在位置を伴う要求に応じて、当該現在位置にマッチしている複数のサービスを抽出する工程と、データベースに予め登録された前記端末装置のユーザのサービス利用履歴に基いて、前記抽出されたサービス毎に好み度を計算する工程と、前記抽出されたサービスのうちの全部又は一部のサービスに関する情報と当該サービス毎の前記好み度を示す情報を前記端末装置に送信する工程と、を備えることを特徴とする。
【００１５】
請求項５に記載のサービス情報提供プログラムの処理は、１又は複数のサービス提供サーバからネットワークを介して端末装置に提供可能な複数のサービスのうち、利用可能なサービスを抽出し当該抽出したサービスに関する情報を前記端末装置に提供するコンピュータを、前記端末装置からの現在位置を伴う要求に応じて、当該現在位置にマッチしている複数のサービスを抽出するサービス抽出手段、データベースに予め登録された前記端末装置のユーザのサービス利用履歴に基いて、前記抽出されたサービス毎に好み度を計算する好み度計算手段、及び前記抽出されたサービスのうちの全部又は一部のサービスに関する情報と当該サービス毎の前記好み度を示す情報を前記端末装置に送信する情報送信手段として機能させることを特徴とする。
【発明の効果】
【００１６】
本発明によれば、ある場所から、モバイル機器のユーザの現在位置で最も望ましい（最適な）サービスを常に推奨している他の場所に移動するときに、モバイル機器の近くで位置に結びつけられた利用可能なサービスを自動的に発見することができ、更に、特定のモバイル機器に適合するよう作られたユーザインターフェイスをダイナミックに使用することによりモバイルアプリケーションを通じてこれらのサービスの利用を可能にすることができる。 
【発明を実施するための最良の形態】
【００１７】
以下、本発明を実施するための最良の実施形態について、図面に基づいて説明する。
（１．システムの概略動作例）
先ず、本発明の一実施形態におけるシステムの概略動作例を説明する。
【００１８】
本実施形態におけるシステムでは、グローバル位置を得るために、モバイル機器（本発明における端末装置の一例）上で実行されているモバイルアプリケーションによりＧＰＳ衛星からの電波を受けることで、当該ＧＰＳ衛星からグローバル位置データがリアルタイムに受信される。モバイル機器の位置が変更されたとき、当該アプリケーションは、インターネット（ネットワークの一例）を介してサービスサーバに接続し、当該モバイル機器の現在位置における利用可能なサービスを要求する。かかる要求を扱うために、サービスサーバ（本発明におけるサービス管理サーバの一例）、上で実行されているサーバソフトウェアの一部が、上記モバイル機器の現在位置において利用可能な全てのサービスの情報を検索（抽出）し、抽出されたサービスのうちどのサービスがモバイル機器のユーザにより望ましいかを判断する。これは、抽出されたサービス毎に「好み度」を計算することによりなされ、抽出されたサービスを、モバイル機器のユーザのサービス利用履歴に基いて、ランキングする（順位つける）ことを意味する。この後、サービスサーバは、抽出されたサービスの情報をその好み度と共に、モバイル機器に返信する。
【００１９】
サービスサーバから返信された応答が受信された時、モバイル機器におけるアプリケーションは、受信されたサービス情報のリストを調べ、以前に受信されたサービス情報のリストがある場合にはこれを更新する。最も高い好み度を有するサービスは、モバイルプリケーションを通じてポップアップ表示による通知が用いられてユーザに推奨される。こうして、ユーザは、当該ユーザに推奨されたサービスのセット（組）から利用するサービスを選択したり、或いは、現在位置において利用可能な幾つかの他のサービスを選択することができる。そして、ユーザがサービスを選択すると、モバイルアプリケーションは、インターネットを介して特定のサービスを提供するサービスプロバイダーサーバ（本発明におけるサービス提供サーバの一例）に接続するために、前のサービス要求において受信されたサービス情報を使用する。そのアプリケーションが、上記サービスを提供しているサービスプロバイダーサーバへの接続が成功した後に、所望のサービスを要求し、当該サーバに対して当該モバイル機器に関するシステム情報を送信する。そして、そのサービスプロバイダーサーバは、そのシステム情報を検査し、そのサービスを要求している上記モバイル機器にユニークに適合されるユーザインターフェイス（表示画面を有する）に特有のデータを構成し返信する。
【００２０】
このユーザインターフェイスのデータが上記モバイル機器のアプリケーションにより受信されると、ユーザインターフェイスビューがそれに基いて構成され、モバイル機器のユーザは、この新たに作成された動的な（ダイナミックな）グラフィカル・ユーザインターフェイスを通してサービスを使用することができる。ユーザが、この動的に構成された、サービスのユーザインターフェイスにおいて動作させるときはいつも、モバイルアプリケーション（モバイル機器のアプリケーション）は、ユーザによりセットされるように、ユーザインターフェイスから全てのデータを収集し、サービスプロバイダーサーバにそれを送信する。そして、サービスプロバイダーサーバは、送信されたデータを検査し、サービスロジック（処理）に従って幾つかの動作を行い、新たなユーザインターフェイスビューを構成し、それを返信する。
【００２１】
モバイル機器がサービスの使用を終了し、サービスプロバイダーサーバとの接続を断つまで、このコミュニケーションパターンは継続する。そして、モバイル機器がサービスプロバイターサーバとの接続を断つ時、サービスサーバに上記サービス利用に関して報告する（レポートデータを送信する）。このように、サービスサーバに送信されるレポートデータは、どのサービスが、いつ、どの位長い期間使用されたかの情報からなる。そして、ユーザのモバイル機器が次回のサービスのために要求する時、より正確なランキング付けを行うことができるよう将来の利用のために、サービスサーバはこの受信された情報を記憶保存する。
（２．システムの構成及び詳細動作例）
次に、本実施形態におけるシステムの構成及び詳細動作例を説明する。 
【００２２】
図１は、本実施形態におけるシステムにおける概要構成例を示す図である。
【００２３】
本実施形態におけるシステムは、図１に示すように、１００〜５００の５つの構成要素を備えて構成される。
【００２４】
図１に示すモバイル機器２００のリアルタイム位置情報を得るためにＧＰＳ衛星１００が利用される。インターネット接続機能を有するモバイル機器２００は、インターネットに接続されているサービスサーバ３００及び多数のサービスプロバイダーサーバ５００などの多様なサーバと通信を行うことが可能になっている。
【００２５】
モバイル機器２００が、サービスサーバ３００及びサービスプロバイダーサーバ５００と通信するために、メッセージベースのインターフェイスが実行される。これは、幾つかのバイナリーメッセージからなり、メッセージの夫々は通信における特有のタスクのために設計される。そのメッセージインターフェイスは、例えばＭＩＦ（Message Interface Definition document）に記述される。ＭＩＦのドキュメント中にある４つのメッセージのペア（リクエスト（要求）とレスポンス（応答））が、本システムに関連するので、ここに詳細に述べる。
【００２６】
モバイル機器２００上で実行されるアプリケーションは、位置変更の度に、ＧＰＳ衛星１００からモバイル機器２００の新しい位置を取得する。
【００２７】
モバイル機器２００のアプリケーションは、アプリケーションのセッテッングから変更可能な数秒の間隔で、サービスサーチ要求メッセージを用いてサービスサーバ３００からの現在位置にマッチしているサービスを要求する。
【００２８】
サービスサーバ３００は、サービスサーチ応答メッセージを、モバイル機器２００に送信することにより応答する。当該サービスサーチ応答メッセージは、サービスデータベース４００に記憶された全ての情報を含んでいるサービスのリストと、夫々のサービス毎に計算された好み度を含んでいる。
【００２９】
モバイル機器２００のアプリケーションは、サービスサーバ３００からの応答メッセージを取り扱い、その応答の内容にしたがって現在のサービスのリストを更新し、ユーザインターフェイスを通してユーザに対して最も高い好み度を有するサービスを推奨する。この後、モバイル機器２００は、利用のために抽出されたサービスに接続することができる。当該接続を生成（確立）するために、受信されたサービスの情報（接続ＩＰアドレス及びポート番号）が要求される。
【００３０】
ところで、当該システムはユーザプロファイリングに基づくものであるので、モバイル機器２００のアプリケーションは、サービスサーチ要求メッセージによりサービスサーバ３００からのサービスを要求する前に、ユーザネーム（username）及びパスワード（password）を使用することによってサービスサーバ３００に登録する必要がある。これは、要求メッセージにおける記録（レジスタ）を使用することによってなされ、モバイル機器２００のアプリケーションは、サービスサーバ３００からの返答としての応答メッセージにおける記録を受け取る。この応答メッセージ内にセッションＩＤと呼ばれるサービスサーバ生成ＩＤがあり、当該ＩＤは、次のサービスサーチ要求メッセージにおけるユーザを確認（身元確認）するために使用される。当該セッションＩＤは、常に、モバイル機器２００により送信された次の要求メッセージ内に置かれる。
【００３１】
サービスサーバ３００の目的は、中央に集められた集中知識ベースとして働くことにあり、そのベースにモバイル機器２００が接続し、サービス接続、サービス推奨及び利用のためのサービス情報を受信するようになっている。
【００３２】
サービスサーバ３００上で実行されているサービスアプリケーション（ＣＰＵにより実行されることにより、本発明におけるサービス抽出手段、好み度計算手段、及び情報送信手段として機能する）があり、それは、接続に入るための確認を行い、モバイル機器２００が接続することによって送信されたメッセージに対して応答する。また、サービスサーバ３００は、サービスデータベース４００に接続されている。当該サービスデータベース４００は、全てのサービスのメタデータ、ユーザの情報、及びサービスデータベース４００から抽出（発見）可能な全てのユーザのサービス利用履歴を含んでいる。
【００３３】
図２は、サービスデータベース４００における各テーブルに登録された情報例を示す図である。
【００３４】
図２に示すように、「Service」（サービス）テーブル上のサービスメタデータは、５つのフィールド（言い換えれば、登録領域）からなる。サービスＩＤ（「service id」）は、データベースに登録（記憶）された各サービスのユニークな（固有の）識別子（識別情報）である。これは、サービスサーバ３００上で実行されているサービスサーバアプリケーションより割り当てられる。ネーム（name）はサービス名を表す文字列である。次の２つの情報（「address」及び「port」）は、モバイル機器３００が、これらのフィールドにおけるデータが常に必要とされるサービスを使用するために、最も重要な要素である。「address」のフィールドには、サービスを使用する時、モバイル機器２００がインターネットを介して接続するためのネームアドレス又はＩＰアドレス、つまり、サービスプロバイダーサーバ５００のアドレスが記述（登録）される。「port」のフィールドには、サービスプロバイダーサーバ５００への接続において使用されるべきポート（ポート番号）が記述される。最後の「price」のフィールドには、サービスの属性：価格が記述される。この情報は、サービスを使用するためにユーザがどのくらいのお金を支払わなければならないかを示している。「Service」テーブルにおける全てのこれらのフィールドに記述される情報は、モバイル機器２００がその位置にマッチしているサービスを要求する時、サービスサーチ応答メッセージ内に組み込まれ好み度と共にサービスのサービスメタデータとしてモバイル機器２００に返される。
【００３５】
このシステムは、サービスサーバ３００に対してモバイル機器２００によってなされる全ての要求がユーザにいつでも紐付けられるということを表すユーザ特有のプロファイリングに基づいている。従って、モバイル機器２００の全てのユーザは、身元確認と認証のためにユニークなユーザネームとパスワードを持たなければならない。このデータは、ユーザ特有のサービス利用傾向を追跡し、それらユーザの好みのランキンキングを作成するシステムを可能とする。
【００３６】
次に、ユーザデータは、サービスデータベース４００における「User」テーブルに記憶される。「User」テーブルは、システムの全てのユーザ情報を含み、４つのフィールドを有する。最初の一つ（username）は、システムにおけるユーザのユニークな識別子（識別情報）である。２番目のフィールドは、ユーザパスワード(password)を含む。３番目のフィールドは、ユーザのフルネーム(fullname)を記述する文字列を含み、最後の一つは、ユーザのｅメールアドレス(email)である。
【００３７】
「History」（履歴）テーブルは、各ユーザのサービス履歴に関する情報を有している。抽出されたサービスの好み度を計算するために、この「History」テーブルからサービスが使用された情報（いつ、どの位長い期間）が得ることできる。また、この「History」テーブルは、サーバアプリケーションにより割り当てられたユニークな識別子である履歴ＩＤ(history id)を有する。２番目及び３番目のフィールドには、キー（username, service id）が含まれ、それらは、どのユーザの履歴登録であるかとどのサービスがユーザにより使用されたかを示す。次のフィールドには、１９７０年１月のＵＴＣ（協定世界時）０時０分０秒からのミリセコンドで、サービス利用の開始時間(start)が記述される。最後のフィールドには、１９７０年１月のＵＴＣ（協定世界時）０時０分０秒からのミリセコンドで、サービス利用の終了時間(finish)が記述される。
【００３８】
１つのサービスが１つの場所以上で利用可能とされ、１つの場所が幾つかのサービスを持つことができるとき、２つの他のテーブルがサービスデータベース４００に導入される。
【００３９】
「Location」テーブルは、各サービスが置かれる全ての位置を保持する。この「Location」テーブルは、主要キーとしてロケーションＩＤ（location id）を有しており、これは、サービスサーバアプリケーションにより割り当てられる。「ネーム」(name)は、建物の名前やストリートのアドレスなどの位置を記述する文字列である。経度（longitude）と緯度（latitude）は、地球上にある位置の地理的な座標を意味する。
【００４０】
「Linked」（リンクド）テーブルは、サービスと位置との間の関連付けを行うために使用され、「Location」と「Service」テーブルからの主要キー（Service id, location id）を保持している。
【００４１】
モバイル機器２００がサービスサーバ３００に接続し、リクエストメッセージにおける記録が登録された時、サーバアプリケーションは、サービスデータベース４００から読み出したユーザネーム及びパスワードに対して、上記リクエストメッセージにおけるユーザネーム及びパスワードを照合する。受信されたパスワードが「User」テーブルに登録されたパスワードと一致する場合には、サーバアプリケーションは、モバイル機器２００のためのセッションＩＤを生成し、当該セッションＩＤを応答メッセージ内に組み込んでモバイル機器２００に返信する。これから、当該セッションＩＤは、セッションの記録のためのユニークな識別子となり、モバイル機器２００のユーザのためのより重要な固有識別子となる。また、そのセッションＩＤは、正常な動作をさせるために、サービスサーバ３００に対する次の要求において使用される。
【００４２】
サービスサーバ３００がモバイル機器２００からのサービスサーチ要求メッセージを受信すると、サービスサーバ３００は、要求メッセージ内から得られた座標に近い座標にリンクされた全てのサービスを発見するために、サービスデータベース４００上で検索を実行する。どのサービスが近いかを判断するために、どちらかというとシンプルな計算方法が適用される。サーバアプリケーションは、２つの座標点（要求メッセージから得られた機器の現在位置と、「Location」テーブルにおける場所の位置）の間の距離Ｄを計算する。もし、当該距離Ｄが予め決められた範囲Ｒ内にある場合（つまり、Ｄ＜Ｒ）、位置にリンクされた全てのサービスが選択され、「Service」テーブルからのそれらのサービス情報がサービスサーチ応答メッセージに付加され、それがモバイル機器２００に返信される。これは、応答メッセージが受信された時、データベースにおける全ての位置に対して適用される。距離Ｄ（大円距離）の計算は、以下の計算式（１），（２）を用いることによりなされる。
【００４３】
【数１】
2009145982.tif 000003
【００４４】
式（１）は、中心角度算出のための正確な式を記述する。ここで、φｓ,λｓ；φｆ,λｆは、２つの地点の地理的な経度及び緯度であり、Δλは経度差、Δσは球の角度差である。大円距離Ｄは、式（２）から得られる。ここで、ｒは球の半径であり、このシステムの場合、地球の半径である。
【００４５】
サービスサーバ３００がモバイル機器２００の位置に近い利用可能な全てのサービスを探索、抽出した後、サービスサーバ３００は、抽出された全てのサービスのユーザ好み度を計算する。これらの計算された好み度は、その後、サービスデータベース４００における「Service」テーブルから抽出されたサービスメタデータと共に、サービスサーチ応答メッセージ内に組み込まれ返信される。かかる計算方法は、後述する。
【００４６】
サービスの好み度の計算は、過去にユーザがどのようにサービスを使用したかの履歴に基づき行われる。この計算は、モバイル機器２００がサービスを使用するたびに行われることになる。モバイル機器２００のサービスの使用は、サービス利用要求メッセージによりサービスサーバ３００に報告される。
【００４７】
このメッセージ内の情報には、使用されたサービスのための識別子（サービスＩＤ）とサービス利用のための開始時間及び終了時間が含まれる。
【００４８】
サービスサーバ３００がサービス利用要求メッセージを受信すると、サービス利用要求メッセージ内から発見された情報を使用してデータベース４００における「履歴」テーブル中に新たな列を作成する。
【００４９】
サービス利用応答メッセージは、上記要求に対する返答としてサービスサーバ３００により送信される。
【００５０】
モバイル機器２００がその場所から発見されたサービスに接続したい場合、モバイル機器２００は、そのサービスのアドレスとポート番号を使用してサービスプロバイダーサーバ５００に接続する。そして、モバイル機器２００は、サービス獲得メッセージを送信する。サービス獲得メッセージには、サービス識別子（他のサービスメタデータの間から受け取られる）と、モバイル機器２００の画面（スクリーン）サイズに関する情報を有するＸＭＬデータが含まれる。サービスプロバイダーサーバ５００がサービスＩＤを認識した場合、サービスプロバイダーサーバ５００は、モバイル機器の画面サイズに基いてユーザインターフェイスを作成（生成）する。
【００５１】
その後、このユーザインターフェイスは、サービス獲得応答メッセージ内に組み込まれＸＭＬ文書としてモバイル機器２００に返信される。モバイル機器２００は、その文書を解析し、それからグラフィカル・ユーザインターフェイスを作成する。
【００５２】
図３は、モバイル機器２００とサービスプロバイダーサーバ５００が送信したＸＭＬ文書の例を示す図である。
【００５３】
図３の左側には、モバイル機器２００によってのみ送信されたＸＭＬデータを記述する２つのボックスが示されている。ナンバー１のボックスには、モバイル機器２００がサービスプロバイダーサーバ５００にはじめて接続する時に一回だけ送信されるＸＭＬデータが示される。その機器の画面サイズは、画面の構成要素内から発見することができる。
【００５４】
図３の右側のナンバー３のボックスには、サービスプロバイダーサーバ５００によってのみ送信されるＸＭＬデータが示されている。そのボックス内からわかるＸＭＬコードは、モバイル機器２００がサービスのためのユーザインターフェイスを作成するためにサポートされるそれからユーザインターフェイス構成要素を例示する。ナンバー３のボックスの場合において、３つの異なる構成要素が見られる。それらは、ラベル（label）、ボタン（button）、及びコンボボックス（combobox）項目である。
【００５５】
ラベルはユーザインターフェイス構成要素であり、機器の画面上に表示されるべきテキストのみを含む。その他の構成要素のように、それは、テキストのためにどのくらい大きなエリアが確保されるかと、その位置がどこであるかを示すためにエリア要素を内側に持っている。ラベル上に示されるべき実際の内容は、テキスト（text）タグ要素（＜text＞・・・＜/text＞）内から抽出される。テキストのフォントは、フォント（font）タグ要素（＜font＞・・・＜/font＞）を使用することにより設定される。
【００５６】
ボタン（button）タグ要素は、ラベルのように２つの同じ内部タグ要素を有し、テキストタグ要素内には、画面上のボタン要素上に書かれるテキストを記述する。コンボボックスは、幾つかの文字列要素を内部に含むドロップダウンメニューである。それは、選択された属性を有し、当該属性は内部要素のうちのどれがデフォルトにより選択されたかを示す。 
【００５７】
これらの３つの構成要素（レベル、ボタン、及びコンボボックス）全てはネーム属性を有し、夫々のネーム属性は夫々の構成要素のユニークな識別子である。
【００５８】
また、コンボボックス内のアイテム（item）タグ要素は、ドロップダウンメニューでユーザがどの項目を選択するかを示すために同様にこのネーム属性を有する。
【００５９】
図３においてナンバー３のボックスからわかるように、全ての構成要素はフォーム（form）と称するルートタグ要素内から抽出される。これも、同様に、ユニークな識別子としてのネーム属性を有する。
【００６０】
他の属性は、モバイル機器２００のためのサービスの状態を記憶することに必要とされるセッションである。
【００６１】
三番目の属性は、ＸＭＬ文書が記述するユーザインターフェイスビューのためのヘッドライン（head line）である。
【００６２】
ユーザが、モバイル機器２００を操作して、生成されたユーザインターフェイス上におけるボタンを押下すると、モバイル機器２００上のアプリケーションは、ユーザインターフェイス構成要素から全ての情報を収集し、その構成要素の状態に基づいてＸＭＬ文書を構成する。
【００６３】
また、ＸＭＬ文書を送られたサービスプロバイダーサーバ５００においてネーム（name）とセッション属性のvaluesは、正確にコピーされる必要がある。これは、サービスプロバイダーサーバ５００が、ＸＭＬデータがどの機器のフォームであるか、かつ、どのユーザインターフェイスビューにデータが対応するかを知るためである。
【００６４】
この属性のvalueは、上記ビューにおいてユーザが押下したボタンのネームである。これは、サービスプロバイダーサーバ５００がどのようにどのボタンが押下されたかを知って、それに応じて必要とされる動作を実行することができる。ボタンは押下されると、モバイル機器２００のアプリケーションは、ユーザによってvalueにセットされることが可能な各ユーザインターフェイス構成要素からアイテムタグ要素を生成する。
【００６５】
図３の場合において、そのようなコンポーネントは、ユーザがある特定の値を選択することが可能な場所としてのコンボボックスである。
【００６６】
アイテム内のキー属性は、その構成要素のネームである。そのvalue属性は、ユーザによってセットされた構成要素の実際の値である。
【００６７】
図３の例において、ラベルタグ要素は全くユーザ対話を持たないので、ラベルタグの要素は変更されないため、サービスプロバイダー側には必要とされない。
【００６８】
ユーザがボタンを押下すると、図３に示す２つのボックス内に記述されたＸＭＬデータがサービス獲得要求メッセージ内に置かれ、サービスプロバイダーサーバ５００に送信される。
【００６９】
サービスプロバイダーサーバ５００は、上記メッセージを受信すると、サービスのロジックに従って幾つかの動作を行い、新しいユーザインターフェイスビューを構成する（図３におけるナンバー３に類似する）。そして、サービスプロバイダーサーバ５００は、サービス獲得応答メッセージ内にユーザインターフェイスビューを入れてモバイル機器２００に返信する。そして再び、ユーザは機器を通じて新しいユーザインターフェイスに反応することができる。
【００７０】
その通信パターンは、モバイル機器２００がサービスを受けるのを終了しサービスプロバイダーサーバ５００から接続を断つまで、可能の限り多くの回数繰り返される。
【００７１】
モバイル機器２００上で実行されているアプリケーションは、サービス利用が開始された時、及びそれが終了した時にサービス利用記録に関する経過を維持する。
【００７２】
モバイル機器２００がサービスプロバイダーサーバ５００と接続を断つとき、そのサービスがどのようにユーザにより使用されたかを報告するために、サービス利用要求メッセージがサービスサーバ３００に送信される。このメッセージは、使用されたサービスのサービス識別子と、その利用のための開始及び終了時間とを含む。
【００７３】
モバイル機器２００は、サービスサーバ３００からの応答として、サービス利用応答メッセージを得る。
（３．好み度の計算例）
次に、好み度計算の詳細について説明する。
【００７４】
図４は、サービスサーバ３００における好み度計算処理を示すフローチャートである。
【００７５】
好み度の計算のために、ユーザ履歴の記録（どの位長くいつユーザがサービスを使用したか）がタイムゾーン（時間帯）として記述される。サービスサーバ３００のサーバアプリケーションは、上記計算を行うために、サービスデータベース４００における「History」テーブルから必要な全ての情報を得る。サービスの総利用時間は、１週の毎日及び毎時間に区分される。言い換えれば、総時間は、２４×７に区分される（１６８時間帯）。総時間は、複数の時間帯に区分されるばかりでなく、利用回数（サービスがどの位多くの数使用されたかをカウントすることを意味する）の総数でもある。
【００７６】
図５は、タイムゾーン（Time Zone）区分を記述するテーブル例を示す図である。
【００７７】
モバイル機器２００がサービス利用要求メッセージを使用してサービスサーバ３００にサービス利用について報告する度に、上記テーブルにおける状況が利用時間として変化し、タイムゾーン内の利用回数の番号が増加する。
【００７８】
図５において、３つの異なるサービス（Service Ａ，Service Ｂ，Service Ｃ）のタイムゾーン（Time Zone）におけるユーザの履歴が見られる。図５から、ユーザがService Ａを６回使用し、ユーザのサービスの総利用時間（TOTAL）は５７分３９秒であることがわかる。そして、この情報は、３つの異なるタイムゾーン上のサービスを使用することから構成される。
【００７９】
今、もし、ユーザが再度位置を入力した場合、例えば水曜日の１２時と１３時の間のタイムゾーンナンバー８５上で、２つの異なる確率を計算することができる。つまり利用時間に基づく確率Ｐtと、利用回数に基づく確率Ｐnとがある。これらの確率は、ユーザがサービスを使用したいことがどの程度ありそうかを示すために必要とされる。また、これらの確率から、最終の確率Ｐ(利用時間に基づく確率Ｐtと、利用回数に基づく確率Ｐnの高い方がＰ、以下、「Probability」という)であるための最も高い確率を常に選択する。従って、この場合の結果が５９．４％である。もし、ユーザがいくつかの時間帯にはじめてサービスを使用した場合、Probabilityは、０になるであろう。２つの確率を使用するための理由は、各時間帯内のサービスの利用回数は変わりうるからである。例えば、ある特定の時間帯上でユーザが何度もサービスを使用したのであるがそれがただ数秒だけであり、他の時間帯上で殆どサービスを使用しないのであるが長い時間使用するような場合がある。従って、正しい利用時間は、常に正確にサービスのユーザの要求を示しているわけではないので、利用回数に基づく確率を導入している。
【００８０】
システムにおけるサービスは、価格、支払い方法、セキュリティ方法、及びプライバシー方針などの多くの異なる属性を持つことができる。これらの全ての属性は、サービスを使用するためのユーザの決定に影響を及ぼし、それらは、好み度が判断される時、考慮に入れなければならない。
【００８１】
とはいえ、本明細書に記載された方法において、あるサービスが当該サービスの価格としての一つの属性のみを有すると仮定する。この属性は、サービスデータベース４００における「Service」テーブルから抽出可能である。また、ユーザが高価なサービスよりも安価なサービスにより興味（関心）があると仮定する。従って、サービスが安価か或いは高価と思われるかどうかを判断して、それに従って好みランキングを行う必要がある。ここで、ユーザのサービス利用履歴により、ユーザが以前にどのサービスを使用したか、ユーザが通常、どのくらいサービスに支払うかがわかる。
【００８２】
この情報は、より効果的になるよう、例えばファジー理論と共に用いられる。
【００８３】
サービスが、実際に、Probabilityとサービスの価格（各サービスのための「Service」テーブルから抽出される）から決定されるために、どのように好み度Ｐｒにファジー方法論を適用するかを次に説明する。
【００８４】
好み度を決定するために、その最終値を生成するためのファジー論理を用いる。
【００８５】
先ず、入力された変数（価格及びProbability）の値を、ファジー値に入れることができるように、ファジーメンバーシップ関数を定義する必要がある。
【００８６】
図６は、Probabilityのメンバーシップ関数のグラフ例を示す図である。
【００８７】
メンバーシップ関数は静的ではなくユーザ及び当該ユーザのサービス利用の履歴に従ってケースバイケースで変化するので、サービス価格のメンバーシップ関数を生成することは、より複雑とされる。メンバーシップ関数を生成するために、サービスデータベース４００における「History」テーブル及び「Service」テーブルから以下の（ａ）〜（ｄ）の４つの値を抽出する必要がある。
【００８８】
（ａ）ユーザが使用したサービスのために支払ったうちの最も低い価格Ｐci（「History」テーブルから取得）
（ｂ）ユーザが使用したサービスのために支払ったうちの最も高い価格Ｐei（「History」テーブルから取得）
（ｃ）「Service」テーブルにおける全てのサービス間のうち最も低い価格Ｐc
（ｄ）「Service」テーブルにおける全てのサービス間のうち最も高い価格Ｐe
これらの４つの値を用いて、図７に示されるように、サービス価格のメンバーシップ関数が構成される。
【００８９】
図７は、サービス価格のメンバーシップ関数のグラフ例を示す図であり、図８は、価格のメンバーシップ関数を計算するための式の一例である。また、図９は、好み度のメンバーシップ関数のグラフ例を示す図である。
【００９０】
最終の好み度の計算は、ファジー規則を用いることによりなされ、それから重みの中心を計算することによってその結果を得る。
【００９１】
ファジー規則は次のように定義される。
【００９２】
規則１：価格が高価かつProbabilityが低い場合、好み度が低い
規則２：価格が中間の場合、好み度が平均
規則３：価格が安価又はProbabilityが高い場合、好み度が高い
以上のメンバーシップ関数を用いて好み度の計算例について以下に説明する。なお、以下の説明では、一例として通貨単位＝６として計算する。
【００９３】
先ず、図４に示すように、現在時刻帯における利用時間に基づく確率Ｐtが計算され（ステップＳ１）、現在時刻帯における利用回数に基づく確率Ｐnが計算される（ステップＳ２）。
【００９４】
次いで、確率Ｐnより確率Ｐtが大きいか否かが判別され（ステップＳ３）、確率Ｐnより確率Ｐtが大きい場合には（ステップＳ３：ＹＥＳ）、確率ＰtがProbability（Ｐ）としてセットされる（ステップＳ４）。一方、確率Ｐnより確率Ｐtが大きくない場合には（ステップＳ３：ＮＯ）、確率ＰnがProbabilityとしてセットされる（ステップＳ５）。
【００９５】
次いで、Probabilityの所属度（メンバーシップ値）の決定処理が行われる（ステップＳ６）。例えば、図６に示すProbabilityのメンバーシップ関数が用いられ、例えばProbability＝０．６７（Ｘ軸）と仮定した場合、low（低い）曲線では、所属度（Ｙ軸）は「０」となり、high（高い）曲線では、所属度は「０．４５」となる。
【００９６】
次いで、サービス価格（Price）の所属度（メンバーシップ値）の決定処理が行われる（ステップＳ７）。例えば、図７に示すサービス価格のメンバーシップ関数が用いられ、通貨単位＝６（Ｘ軸）と仮定した場合、cheap（安価）曲線では、所属度（Ｙ軸）は「０」となり、medium（中間）曲線では、所属度は「１．０」となり、expensive（高価）曲線では、所属度は「０」となる。
【００９７】
次いで、好み度関数の作成処理が行われる（ステップＳ８）。例えば、上記決定された所属値と、図９に示す好み度のメンバーシップ関数とファジー規則とが用いられる。
【００９８】
上記ステップＳ６及びステップＳ７より、規則１は成立しないので、図９に示す好み度のlow曲線は使われない。
【００９９】
また、上記ステップＳ７より、規則２は成立するので、図９に示す好み度のaverage曲線が使われる。この時、サービス価格のmedium曲線は、所属度が「１．０」であるため、average曲線の全てが使われる。
【０１００】
また、上記ステップＳ６より、規則３は成立するので、図９に示す好み度のhigh曲線が使われる。この時、Probabilityのhigh曲線では、所属度は「０．４５」であるため、high曲線の所属度0.45以上はカットされる。
【０１０１】
こうして得られた好み度のメンバーシップ関数のグラフ例を図１０に示す。つまり、上記処理では、２つの入力値とそれぞれの関数から曲線と所属度が決定され、ファジー規則より、どの曲線をどれだけ使うかが決定される。なお、どれだけ使うかを決めるのが所属度である。
【０１０２】
そして、図１０に示すメンバーシップ関数のグラフから「重みの中心」を公知の計算手法で求め、最終的な好み度が算出される。図１０の例では、好み度は、約１９．０２となる。なお、上述したメンバーシップ関数のグラフは経験則に基いて決定されるものである。
【０１０３】
また、別の例として、通貨単位＝３、Probability＝０．１と仮定した場合、ステップＳ６の処理において、low曲線では、所属度は「０．６５」となり、high曲線では、所属度は「０」となる。次いで、ステップＳ７の処理において、cheap曲線では、所属度は「０．３５」となり、Medium曲線では、所属度は「０．６５」となり、expensive曲線では、所属度は「０」となる。次いで、ステップＳ８の処理において、規則１は成立せず（low曲線は使われない）、規則２は成立するので、好み度のaverage曲線が使われ、この時、サービス価格のmedium曲線は所属度が「０．６５」であるため、average曲線の0.65以上はカットされる。また、規則３は成立するので、好み度のhigh曲線が使われ、この時、Probabilityのhigh曲線では、所属度が「０．３５」であるため、high曲線の所属度0.35以上はカットされる。よって、好み度の最終的なpreference曲線は、low曲線は無、average曲線は0.65以上がカットされた台形、high曲線は0.35以上がカットされた台形となり、これら全体から重みの中心が、最終的な好み度として算出される。
【０１０４】
以上説明したように、上記実施形態によれば、ある場所から、モバイル機器のユーザの現在位置で最も望ましい（最適な）サービスを常に推奨している他の場所に移動するときに、モバイル機器の近くで位置に結びつけられた利用可能なサービスを自動的に発見することができ、更に、特定のモバイル機器に適合するよう作られたユーザインターフェイスをダイナミックに使用することによりモバイルアプリケーションを通じてこれらのサービスの利用を可能にすることができる。 
【０１０５】
また、ユーザのサービス利用履歴に基づき上記抽出されたサービスの利用時間及び利用回数に基づく確率を計算し、何れか一方の確率と上記抽出されたサービスの価格に基づいてサービス毎の好み度を計算、特に、確率と価格に基づくメンバーシップ関数を用いて好み度を計算するように構成したので、よりユーザの好みが正確に反映されたサービスを効果的に適用することができる。
【０１０６】
また、上記実施形態においては、ユーザの現在位置において利用可能な全てのサービスは常に自動的に抽出され、最も好みのサービスが自動的にユーザのモバイル機器に提供される。ユーザはモバイル機器を所持するだけでよく、ユーザの移動と共に利用可能なサービスも変化することとなる。つまり、全ユーザが必要とすることは、異なる場所で利用するサービスを選択することに集中するだけである。その上、ユーザ自身が使用するサービスにランクを付けているため、ユーザが余分な操作をする必要ない。つまり、上記実施形態により、ユーザに好みのサービスを提供するための新たな種類の効果を与えることが可能となる。
【０１０７】
また、上記実施形態によれば、ユーザのサービス利用パターンを正確に把握し、週のある特定の日の特定の時間の最適なサービス推奨を行うことができる。
【０１０８】
なお、上記実施形態においては、モバイル機器のアプリケーションは、それ自身で如何なるサービスも提供しなかったが、上記システムにおいて、モバイル機器が他のモバイル機器にサービスを提供するように構成しても良い。また、例えばモバイル機器が互いに近くにある場合、一方に提供されたサービスを他方のモバイル機器で利用できる様に構成しても良い。
【図面の簡単な説明】
【０１０９】
【図１】本実施形態におけるシステムにおける概要構成例を示す図である。
【図２】サービスデータベース４００における各テーブルに登録された情報例を示す図である。
【図３】モバイル機器２００とサービスプロバイダーサーバ５００が送信したＸＭＬ文書の例を示す図である。
【図４】サービスサーバ３００における好み度計算処理を示すフローチャートである。
【図５】タイムゾーン（Time Zone）区分を記述するテーブル例を示す図である。
【図６】Probabilityのメンバーシップ関数のグラフ例を示す図である。
【図７】サービス価格のメンバーシップ関数のグラフ例を示す図である。
【図８】価格のメンバーシップ関数を計算するための式の一例である。
【図９】好み度のメンバーシップ関数のグラフ例を示す図である。
【図１０】好み度のメンバーシップ関数のグラフ例を示す図である。
【符号の説明】
【０１１０】
１００  ＧＰＳ衛星
２００  モバイル機器
３００  サービスサーバ
４００  サービスデータベース
５００  サービスプロバイダーサーバ
【図１】
2009145982.tif 000004
【図２】
2009145982.tif 000005
【図３】
2009145982.tif 000006
【図４】
2009145982.tif 000007
【図５】
2009145982.tif 000008
【図６】
2009145982.tif 000009
【図７】
2009145982.tif 000010
【図８】
2009145982.tif 000011
【図９】
2009145982.tif 000012
【図１０】
2009145982.tif 000013