JP2002073673A - ユーザ嗜好共有方法、ユーザエージェント探索方法、およびユーザエージェント所在通知方法 - Google Patents

Abstract

(57)【要約】 【課題】 コンテンツを検出するためのユーザ嗜好キー
ワードを作成するユーザキーワード嗜好共有方法を提供
する。 【解決手段】 ユーザがライブ放送サービスの利用を
開始すると、ユーザに対するUAが起動される。UAは起動
されると、まずユーザ嗜好情報を検索する（ステップ１
１）。そしてライブ放送サービスとニュース配信サービ
スの２つのサービスのユーザ嗜好情報を検出する（ステ
ップ１２）。ライブ放送サービスの特徴とニュース配信
サービスの特性を抽出し（ステップ１３、１４）、両者
を比較する（ステップ１５）。異なることを検出する
と、ライブ放送サービスとニュース配信サービス間でユ
ーザ嗜好情報を共有しないと判断し（ステップ１６
Ａ）。ユーザ嗜好情報のうち、ニュース配信サービスに
おけるユーザ嗜好情報は用いずライブ放送サービスにお
けるユーザ嗜好情報のみを使用してユーザ嗜好キーワー
ドを作成する（ステップ１７Ａ）。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はユーザの嗜好にマッ
チしたコンテンツを提案するコンテンツ提案サービスシ
ステムに関する。

【０００２】

【従来の技術】ユーザの好みにマッチしたコンテンツを
提案する従来のマルチメディアサービスでは、図１１に
示すように、各サービスシステムは当該サービスにおけ
るユーザのサービス利用履歴などからユーザ嗜好を表す
情報を抽出して管理し、ユーザが次回サービスを利用す
る際に、当該サービスにおけるユーザ嗜好情報を利用
し、ユーザの好みにマッチングするコンテンツを検出し
ていた。

【０００３】

【発明が解決しようとする課題】このように、ユーザの
好みにマッチするコンテンツを提案する従来のサービス
では、ユーザの好みにマッチするコンテンツを検出する
ための、ユーザ嗜好を表現するキーワードを作成する際
に、当該サービス利用中に収集されたユーザ嗜好情報の
みが利用可能であり、他のサービスにおいて収集された
ユーザ嗜好情報を利用することは困難であった。このた
め、ユーザが始めたばかりのサービスにおいては、ユー
ザの代りにコンテンツを検出するためのユーザ嗜好キー
ワードの作成に利用できる情報が少なく、ユーザの好み
にマッチするコンテンツを入手するためには、ユーザが
自ら膨大な数のコンテンツの中から自身の好みに合うコ
ンテンツを抽出する必要がある。

【０００４】本発明の目的は、コンテンツを検出するた
めのユーザ嗜好キーワードを作成するユーザキーワード
嗜好共有方法を提供することにある。

【０００５】本発明の他の目的は、ユーザ嗜好情報を収
集し、管理するユーザエージェントの所在を探索するユ
ーザエージェント探索方法を提供することにある。

【０００６】本発明のさらに他の目的は、ユーザエージ
ェントの所在をサービスを提供するアプリケーションに
通知するユーザエージェント所在通知方法を提供するこ
とにある。

【０００７】

【課題を解決するための手段】前記目的を達成するた
め、本発明は、図１に示すように、ユーザがサービス利
用中にユーザのアクションなどから収集されるサービス
履歴情報が、当該サービスのアプリケーションプログラ
ムなどから登録を受け、登録情報をユーザ嗜好情報とし
て管理するソフトウェアであるユーザエージェント（U
A）を、異なるサービスに対して共通に使用し、マルチ
サービス間でユーザ嗜好を共有する。

【０００８】他にも、UAはユーザから直接ユーザ嗜好情
報の登録を受けたり、UA自身がユーザの閲覧中のWWWペ
ージ内の文章から、ユーザの興味を表すキーワードを抽
出し、ユーザー嗜好情報として自ら登録するなど、ユー
ザ嗜好情報を自動的に収集し、マルチサービス間で共通
に利用する。

【０００９】ユーザが、いかなるサービスを利用する場
合でも、ユーザ嗜好情報を管理するUAを一意に対応付け
る方法として、UAをユーザ端末にインストールし、ユー
ザはサービスを利用する際には必ずユーザ端末を用い
る。図２（a）に示すように、ユーザはユーザ端末から
サービスを受信するため、当該ユーザ端末においてクラ
イアントアプリケーションを起動し、サービスを提供す
るサーバアプリケーションとの接続を確立する。このと
き、クライアントアプリケーションは起動されたユーザ
端末内に存在するUAを探索し、検出したUAを以後利用す
る。あるいは図２（b）に示すように、クライアントア
プリケーションとサーバアプリケーション間の接続の際
に、サーバアプリケーションからプロキシと呼ばれるア
プリケーションがユーザ端末にダウンロードされて実行
され、プロキシが当該ユーザ端末内に存在するUAを検出
し、その所在を当該サーバアプリケーションに通知す
る。

【００１０】UAがユーザ端末にあるか否かに関わらず、
ユーザ嗜好情報を管理するUAをユーザに対応付ける方法
として、図３に示すように、UAを生成してユーザに提供
するUAファクトリサーバが存在し、ユーザは自身に対応
するUAを生成し取得するためのUAファクトリサーバの所
在とユーザIDを認識し、これを用いて自身のUAの所在を
意識する。ユーザは、サービスを利用する際に、サービ
スを提供するサーバアプリケーションあるいはクライア
ントアプリケーションに対して、UAの所在あるいは生成
・取得するための情報を通知し、いかなるサービスアプ
リケーションをいかなるユーザ端末から利用する場合に
おいても、共通のUAを使用して、ユーザ嗜好情報を共有
する。

【００１１】ユーザがUAを利用してサービス利用中、当
該サービスのクライアントアプリケーションまたはサー
バアプリケーションは、ユーザのサービス利用中のアク
ションや閲覧したコンテンツなどに基づいてユーザ嗜好
情報を抽出し、UAに登録する。このとき、UAはどのサー
ビスにおいて前記ユーザ嗜好情報が収集され登録された
かを、サービス毎に区別して管理する。サービスにはサ
ービス提供者が予め、サービスの用途（娯楽、教養、ビ
ジネスなど）や主に扱うコンテンツの分野（音楽、映
画、政治・経済、買い物情報など）、場所依存性（アウ
トドア用サービス、インドア用サービスなど）、サービ
ス時間帯などの特性を設定しておく。UAは個々のサービ
ス毎に登録されたユーザ嗜好情報を、どのサービス間で
共有すべきかに関して、サービスの特性の一致／不一致
を元に判定する。UAはユーザが利用中のサービスにおい
て収集されたユーザ嗜好情報のみでなく、サービスの用
途や分野が共通するサービスにおいて収集されたユーザ
嗜好情報を参照し、ユーザ嗜好キーワードを作成する。

【００１２】また、他の方法として、前記のようにUA
は、個々のサービス毎に収集されたユーザ嗜好情報を区
別して管理し、UAはこれらのユーザ嗜好情報を、どのサ
ービス間で共有すべきかに関して、収集されたユーザ嗜
好情報の類似度を元に判定する。収集されたユーザ嗜好
情報から当該サービスにおいて、ユーザがどのようなコ
ンテンツを受信し利用する傾向があるかが判断され、複
数の異なるサービスにおけるそれぞれのユーザのコンテ
ンツ利用傾向を比較するため、各サービス間のユーザ嗜
好情報の共通部分の割合を計算し、その割合が大きけれ
ば、ユーザのコンテンツ利用傾向が類似していると判断
し、当該サービス間でユーザ嗜好情報を共有することを
決定する。UAはユーザが利用中のサービスにおいて収集
されたユーザ嗜好情報のみでなく、前記のように共有す
ることを決定した他のサービスにおけるユーザ嗜好情報
を参照し、ユーザ嗜好キーワードを作成する。

【００１３】

【発明の実施の形態】次に、本発明の実施の形態につい
て図面を参照して説明する。

【００１４】図４は本発明の一実施形態のマルチメディ
アコンテンツ提案サービスシステムの構成図である。ユ
ーザがサービスを利用するため、クライアントアプリケ
ーションあるいはサーバアプリケーションを使用し、こ
のアプリケーションを用いて、コンテンツの選択や絞込
みを行う。これらのユーザアクションから当該アプリケ
ーションはユーザ嗜好情報を抽出する。図４では、ユー
ザが、クライアントアプリケーションを用いてコンテン
ツの選択などを行い、クライアントアプリケーション
は、ユーザがコンテンツを選択して利用した際に、当該
コンテンツにユーザは興味を持っていると判断し、当該
コンテンツに対してコンテンツ提供者あるいは作成者が
予め付与したタイトルやジャンルなどのヘッダ情報など
からユーザ嗜好情報を生成し、当該ユーザのUAに登録す
る。例として、ユーザは、タイトルが“プロ野球速
報”、ジャンルが“スポーツ／野球”というヘッダ情報
のニュース情報コンテンツを選択したとすると、クライ
ンアトアプリケーションは、当該ユーザのユーザ嗜好情
報として“スポーツ／野球”および“プロ野球速報”と
いう情報を当該ユーザに対応するユーザエージェント
（UA）に登録する（）。ユーザエージェントは、入力
された情報を、UAの取り扱える形式に変換して保存す
る。例えば、前記２つの情報が入力された際に、キーワ
ード“スポーツ／野球”のみをユーザ嗜好情報としてUA
内部に保存している。以後、ユーザが何らかのサービス
を利用する際に（）、当該サービスのクライアントア
プリケーション（あるいはサーバアプリケーション）は
UAに対してユーザ嗜好キーワードの生成を依頼すると
（）、UAは、過去に登録された情報（例えば“スポー
ツ／野球”）を利用して作成したユーザ嗜好キーワード
を提供する（）。クライアントアプリケーションはサ
ーバアプリケーションにユーザ嗜好キーワードを送信し
（）、サーバアプリケーションは、このユーザ嗜好キ
ーワードに合致するコンテンツ情報を抽出してユーザに
提案する（）。なお、クライアントアプリケーション
とサーバアプリケーションの役割分担は図４に示したも
のに限らない。

【００１５】図５（a）および図５（b）は、異なるサー
ビス間でUAを共通に利用するために、UAをユーザ端末に
配置し、いかなるサービスを利用する場合でも、ユーザ
の代理であるUAをユーザ端末において検出し、いかなる
サービスでも共通のUAを代理として使用する実施形態を
示す図である。図５（a）および図５（b）は、ユーザは
ユーザ端末にUAプログラムファイルがインストールされ
る契機を示しており、図５（a）では、ユーザがサービ
スを受信するためのクライアントアプリケーションをイ
ンストールCDなどからインストールする際に、ユーザ端
末にUAプログラムファイルがインストールされていなけ
れば、このときUAプログラムファイルも同時にインスト
ールされ、次にユーザ端末においてクライアントアプリ
ケーションがユーザ端末内のUAを検出し起動する。図５
（ｂ）では、ユーザがサーバアプリケーションにアクセ
スした際に、サーバアプリケーションから、アプレット
などで実現されるプロキシプログラムがユーザ端末にダ
ウンロードされ、このプロキシが、ユーザ端末において
UAプログラムファイルを捜索し、UAプログラムファイル
が存在しなければ、ＵＡダウンロードサーバからUAプロ
グラムファイルインストーラがダウンロードされ、イン
ストールされる。それから、プロキシによってUAが起動
され、UAの所在がサーバアプリケーションに通知され
る。前述のような方法で、ユーザ端末に存在するUAプロ
グラムファイルの存在が、ユーザのサービス利用時にチ
ェックされると同時に、UAが起動され、その所在をクラ
イアントアプリケーションあるいはサーバアプリケーシ
ョンが認識する。

【００１６】図６は、異なるサービス間でUAを共通に利
用するために、UAがユーザ端末にあるか否かに関わら
ず、ユーザがいかなるサービスを利用する場合でも、ユ
ーザの代理人であるUAを異なるサービス間で共通使用す
る実施形態を示す図である。図６では、UAをオブジェク
トとして生成するUAファクトリサーバが、UAファクトリ
サーバマシンにおいてUA運営者により運営され、ユーザ
は当該サーバのURLあるいはサーバ名などを意識する。
図６の例では、ユーザはクライアントアプリケーション
にUAファクトリのサーバ名（URL）とユーザIDを入力
し、UA生成依頼およびUAの所在の認識をさせる。ユーザ
はサービスを利用する際には、UAファクトリサーバに対
してユーザIDを通知し、自身に対応するUAオブジェクト
の生成および起動を依頼し、この生成および起動された
UAの所在をクライアントアプリケーションあるいはサー
バアプリケーションに対して通知して認識させる。以後
アプリケーションは当該UAにユーザ嗜好情報の登録やユ
ーザ嗜好キーワードの参照を行う。ユーザは、いかなる
サービスを利用する場合も、常に同一のUAファクトリサ
ーバから同一のユーザIDで生成および起動されたUAを使
用して、異なるサービス間で共通のUAを利用することを
実現する。

【００１７】図７は、UAが管理するユーザ嗜好情報の一
例を示す。UAは、ユーザがサービス利用中に抽出され、
UAに登録されたユーザ嗜好情報を、抽出元のサービス毎
に個別に管理する。図では、ライブ放送サービスとニュ
ース配信サービスにおいて収集したユーザ嗜好を、それ
ぞれ個別にUAが管理している。例えば、UAは“音楽”や
“野球”などのコンテンツの内容を表すキーワードをユ
ーザ嗜好情報として扱っている。ライブ放送サービス提
供者は、自身の提供するライブ放送サービスのサーバア
プリケーションを起動し、ユーザはライブ放送を受信す
るためのクライアントアプリケーションを起動する。ユ
ーザはライブ放送サービス利用時に、例えば、受信コン
テンツを選択すると、このコンテンツ選択アクションか
ら、選択したコンテンツに付与されたタイトルや内容に
関するキーワードよりユーザ嗜好情報がクライアントア
プリケーションあるいはサーバアプリケーションによっ
て抽出され、UAに登録される。このユーザ嗜好登録時
に、アプリケーションは、サービス名（例では“ライブ
放送サービス”）を同時にUAに通知し、UAはどのサービ
スにおけるユーザ嗜好情報が登録されたかを把握し、サ
ービス毎に管理する。また、前記アプリケーションはユ
ーザ嗜好情報登録以外に、サービスの特性をUAに登録す
るため、サービスの目的（例では“娯楽”）などをUAに
通知し、UAは当該サービスがどのような目的の利用者を
対象にしたものかを把握する。同様に、UAはまた、ニュ
ース配信サービスにおけるユーザ嗜好情報およびサービ
スの特性を、ニュース配信サービスアプリケーションか
らの入力によって把握する。

【００１８】図８は、ライブ放送サービスにおけるユー
ザ嗜好情報とニュース配信サービスにおけるユーザ嗜好
情報を共有するか否かをUAがサービスの特性の一致／不
一致を元に判断し、ユーザ嗜好キーワードを作成する処
理を示す。

【００１９】ユーザがライブ放送サービスの利用を開始
すると、ユーザに対するUAが起動される。UAは起動され
ると、まずユーザ嗜好情報を検索する（ステップ１
１）。そしてライブ放送サービスとニュース配信サービ
スの２つのサービスのユーザ嗜好情報を抽出する（ステ
ップ１２）。ライブ放送サービスの特徴とニュース配信
サービスの特性を抽出し（ステップ１３、１４）、両者
を比較する（ステップ１５）。両サービスの特性が異な
ると、ライブ放送サービスとニュース配信サービス間で
ユーザ嗜好情報を共有しないと判断する（ステップ１６
Ａ）。ユーザからのユーザ嗜好キーワード作成要求を受
け、ユーザ嗜好情報のうち、ニュース配信サービスにお
けるユーザ嗜好情報は用いず、ライブ放送サービスにお
けるユーザ嗜好情報のみを使用してユーザ嗜好キーワー
ドを作成する（ステップ１７Ａ）。両サービスの特性が
同じであれば、ライブ放送サービスとニュース配信サー
ビス間でユーザ嗜好情報を共有すると判断し（ステップ
１６Ｂ）、両サービスにおける嗜好情報を利用して、ユ
ーザ嗜好キーワードを作成する（ステップ１７Ｂ）。

【００２０】図９は、ライブ放送サービスにおけるユー
ザ嗜好情報とニュース配信サービスにおけるユーザ嗜好
情報を共有するか否かをUAが、サービス毎に抽出したユ
ーザ嗜好情報の類似度を元に判断し、ユーザ嗜好キーワ
ードを作成する処理を示す。

【００２１】ユーザがライブ放送サービスの利用を開始
すると、ユーザに対するＵＡが起動される（ステップ２
１）。そしてライブ放送サービスとニュース配信サービ
スの２つのサービスのユーザ嗜好情報を抽出する（ステ
ップ２２）。UAの把握しているユーザ嗜好情報がある程
度収集されているか否かを判断し（ステップ２３，２
４）、どちらか一方のサービスにおける抽出されたユー
ザ嗜好情報が少ない場合は、嗜好情報の類似度を計算で
きないため、図８のステップ１３に戻り、サービスの特
性の一致／不一致から共有の判断を行う。ライブ放送サ
ービスにおいてもニュース配信サービスにおいても、ユ
ーザ嗜好情報が十分収集されている場合、例えばそれぞ
れのユーザ嗜好情報間で共通に存在する情報と共通に存
在しない情報との割合を算出するなどの方法で、ユーザ
嗜好情報の類似度を算出する（ステップ２５）。この類
似度を閾値と比較し（ステップ２６）、類似度の数値が
ある閾値を越えた場合、両サービス間でユーザ嗜好情報
を共有すると判断する（ステップ２７Ｂ）。図１０で
は、共通に存在するユーザ嗜好情報の割合が過半数であ
るため、両サービス間でユーザ嗜好情報を共有するとUA
は判断する。その結果、ユーザがライブ放送サービスを
利用する際に、UAはライブ放送サービスにおいて抽出さ
れたユーザ嗜好情報だけでなく、ニュース配信サービス
において抽出されたユーザ嗜好情報をも使用してユーザ
嗜好キーワードを作成し（ステップ２８Ｂ）、ライブ放
送サービスにおいて、当該ユーザがまだ受信したことの
ない“ラグビー”の試合などの放送の提案を受けること
が可能となる。一方、ニュース配信サービスにおいて
は、当該ユーザがまだ受信したことのない“映画”に関
するニュースの提案を受けることが可能となる。この場
合、ライブ放送サービスの提供者とニュース配信サービ
スの提供者は、それぞれのサービスを互いに異なる目的
のユーザや異なる分野を対象としたサービスをサービス
を提供したのであるが、当該ユーザが受信するコンテン
ツはどちらのサービスにおいても類似しているため、ユ
ーザ嗜好情報が共有された。類似度の数値が閾値以下で
あれば、両サービス間でユーザ嗜好情報を共有しないと
判断し（ステップ２７Ａ）、ライブ放送サービスにおけ
るユーザ嗜好情報のみを利用してユーザ嗜好キーワード
を作成する（ステップ２８Ａ）。ユーザ毎にサービスの
利用の仕方が異なるため、ユーザ毎に、どのサービス間
でユーザ嗜好情報を共有するのが効果的かが異なるが、
この共有判断方法では、前述のように各々のユーザに特
化したサービスの利用方法に対応した共有判断が可能で
ある。

【００２２】

【発明の効果】以上説明したように、本発明によれば、
下記のような効果がある。

【００２３】１）エンドユーザが自身のユーザ嗜好を明
確に認識しなくても、ユーザの代理であるあるユーザエ
ージェント（UA）がユーザの代りにユーザ嗜好キーワー
ドを作成し、ユーザの興味に合致するコンテンツを検出
することができる。

【００２４】２）異なるサービス間でユーザ嗜好情報を
共有することができ、ユーザが利用開始して間もないサ
ービスにおいても、他のサービス利用時に収集されたユ
ーザ嗜好情報が反映され、ユーザの興味に合致したコン
テンツの提案を受けることができる。

【００２５】３）ユーザがUAの所在を意識しないでも、
同一の端末を使用する限り、異なるサービス間で当該UA
を共通に使用することができる。

【００２６】４）ユーザが異なる端末を使用しても、ユ
ーザに対応するUAの所在をユーザ自身が意識することに
より、異なるサービス間で当該UAを共通に使用すること
ができる。

【００２７】５）ユーザ嗜好情報を異なるサービス間で
共有する場合に、UAは効率的な共有の判断を行うことが
できる。

【００２８】６）各々のユーザに特化したサービスの利
用方法に対応した、ユーザ嗜好情報の共有を判断するこ
とができる。

【図面の簡単な説明】

【図１】本発明のマルチメディアコンテンツ提案サービ
スシステムの構成図である。

【図２】クライアントアプリケーションがユーザ端末に
おいてUAを検出する例（図２（a））と、サーバアプリ
ケーションからプロキシがユーザ端末にダウンロードさ
れ、プロキシがユーザ端末においてUAを検出する例（図
２（b)）を示す図である。

【図３】ユーザがUAの所在を意識し、UAがユーザ端末に
あるか否かに関わらず、ユーザに対応するUAをサービス
アプリケーションに通知する例を示す図である。

【図４】本発明の一実施形態のマルチメディアコンテン
ツ提案サービスシステムの構成図である。

【図５】クライアントアプリケーションをユーザ端末に
インストールする際に同じにUAをユーザ端末にインスト
ールする例（図５（a））と、サーバアプリケーション
からプロキシがユーザ端末にダウンロードされる際に、
同時にUAをユーザ端末にインストールする例（図５
（b））を示す図である。

【図６】ユーザがUAの所在を意識し、UAがユーザ端末に
あるか否かに関わらず、ユーザに対応するUAをサービス
アプリケーションに通知する、本発明のユーザUA対応付
け例を示す図である。

【図７】UAを管理するユーザ嗜好情報の一例を示す図で
ある。

【図８】本発明の、異なるサービス間のユーザ嗜好情報
の共有に関する、各々のサービス特性の一致／不一致に
よる判断処理のフローチャートである。

【図９】本発明の、異なるサービス間のユーザ嗜好情報
の共有に関する、各々のサービスにおいて抽出したユー
ザ嗜好情報の類似度による判断処理のフローチャートで
ある。

【図１０】本発明の、異なるサービス間のユーザ嗜好情
報の共有に関する、各々のサービスにおいて抽出された
ユーザ嗜好情報の類似度による判断の例を示す図であ
る。

【図１１】従来のマルチメディアコンテンツ提案システ
ムの構成図である。

【符号の説明】

１１〜１７Ｂ、２１〜２８Ｂ ステップ

Claims (5)

【特許請求の範囲】
1. 【請求項１】 ユーザの嗜好にマッチしたコンテンツを
   提案するコンテンツ提案サービスにおいて使用され、ユ
   ーザの嗜好にマッチしたコンテンツを検出するための、
   ユーザの嗜好を表す検索キーワードであるユーザ嗜好キ
   ーワードを作成するユーザキーワード嗜好共有方法であ
   って、 異なるサービス間で共通のユーザエージェントが、ユー
   ザ嗜好情報を、収集したサービス毎に別々に管理し、該
   ユーザエージェントがユーザ嗜好情報を管理しているサ
   ービスのうちで当該サービスの特性と、サービス提供者
   が定めた他のサービスの特性を比較し、一致すれば当該
   サービスのユーザ嗜好情報の他に前記他のサービスにお
   けるユーザ嗜好情報を利用してユーザ嗜好キーワードを
   作成するユーザキーワード嗜好共有方法。
2. 【請求項２】 ユーザの嗜好にマッチしたコンテンツを
   提案するコンテンツ提案サービスにおいて使用され、ユ
   ーザの嗜好にマッチしたコンテンツを検出するための、
   ユーザの嗜好を表す検索キーワードであるユーザ嗜好キ
   ーワードを作成するユーザキーワード嗜好共有方法であ
   って、 異なるサービス間で共通のユーザエージェントが、ユー
   ザ嗜好情報を、収集したサービス毎に別々に管理し、該
   ユーザエージェントがユーザ嗜好情報を管理しているサ
   ービスのうちで当該サービスにおけるユーザ嗜好情報
   と、サービス提供者が定めた他のサービスにおけるユー
   ザ嗜好情報を比較し、両者が類似していれば当該サービ
   スのユーザ嗜好情報の他に前記他のサービスにおけるユ
   ーザ嗜好情報を利用してユーザの嗜好キーワードを作成
   するユーザキーワード嗜好共有方法。
3. 【請求項３】 ユーザの嗜好にマッチしたコンテンツを
   提案する異なるコンテンツ提案サービス間で共通で、ユ
   ーザ嗜好情報を収集し、サービス毎に別々に管理するユ
   ーザエージェントの所在を探索する方法であって、 ユーザ端末内の起動されたクライアントアプリケーショ
   ンが、サービスを提供するサーバアプリケーションと接
   続する際に、該端末内に存在するユーザエージェントを
   探索するユーザエージェント探索方法。
4. 【請求項４】 ユーザの嗜好にマッチしたコンテンツを
   提案する異なるコンテンツ提案サービス間で共通で、ユ
   ーザ嗜好情報を収集し、サービス毎に別々に管理するユ
   ーザエージェントの所在を探索する方法であって、 ユーザ端末内の起動されたクライアントアプリケーショ
   ンが、サービスを提案するサーバアプリケーションと接
   続する際に、該サーバアプリケーションから前記ユーザ
   端末内にダウンロードされたプロキシが前記ユーザ端末
   内に存在するユーザエージェントを検出するユーザエー
   ジェント探索方法。
5. 【請求項５】 ユーザの嗜好にマッチしたコンテンツを
   提案する異なるコンテンツ提案サービス間で共通で、ユ
   ーザ嗜好情報を収集し、サービス毎に別々に管理するユ
   ーザエージェントの所在を通知する方法であって、 ユーザがクライアントアプリケーションに、ユーザアプ
   リケーションを生成してユーザに提供するユーザアプリ
   ケーションファクトリサーバのサーバ名とユーザIDを入
   力してユーザエージェントの生成を依頼し、ユーザはサ
   ービスを利用する際に、サービスを提供するアプリケー
   ションに対して前記ユーザエージェントの所在を通知す
   るエージェント所在通知方法。