JP2007323225A - システム、端末、サーバ、及び、動的情報提供方法 - Google Patents

Abstract

【課題】ユーザ個々の嗜好に合わせた情報を端末装置に配信するのに好適なネットワークシステムを提供する。
【解決手段】端末は、ユーザのコンテキスト情報を収集して保持するコンテキスト情報保持手段と、該保持されたコンテキスト情報に基づいて当該コンテキスト情報に対応した所定の形式のベクトルデータを生成するベクトルデータ生成手段とを具備する。そして、ベクトルデータ生成手段により生成されたベクトルデータをサーバに送信する。またサーバは、受信した該ベクトルデータに基づいて該ユーザに提供すべき情報を生成する提供情報生成手段を具備する。そして、提供情報生成手段により生成された提供情報を端末に送信する。
【選択図】図５

Description

本発明は、サーバが端末に対して動的な情報を提供するシステムに関する。またこのようなシステムに好適な端末及びサーバに関する。また端末に動的な情報を提供するための動的情報提供方法に関する。

端末装置に実装された情報閲覧ソフトウェア（以下、ブラウザと記す）を用いてＷｅｂサーバにアクセスすることで、ユーザは、当該サーバにより提供されるサービスを受けることができる。近年、インターネットに代表されるネットワークの急速な普及やその技術の発展に伴って、ユーザは様々なサービスを受けることができるようになった。その一つに、例えばユーザ個々の嗜好に合わせた広告やコンテンツ等を端末装置に配信するサービスが挙げられる。

例えば下記特許文献１には、ユーザが閲覧したサイトやその検索履歴等を収集・分析してユーザ個々の嗜好に合わせた広告やコンテンツ等を端末装置に配信するサービスが開示されている。下記特許文献１に記載のシステムにおいては、端末装置がドメイン名及びユーザＩＤをサーバに送信する。次いで、サーバがそれらの情報に基づいて収集・分析処理等を実行する。そしてその処理結果を反映させた適切な広告を端末装置に配信する。これにより、ユーザ個々の嗜好に合致した広告等の配信が実現される。

また下記特許文献２にも、ユーザ個々の嗜好に合わせた広告やコンテンツ等を端末装置に配信するサービスが開示されている。下記特許文献２に記載のシステムにおいては、ユーザが閲覧したサイトの履歴情報が端末装置によりサーバに送信される。次いで、サーバが、その受け取った情報に基づいてユーザの情報収集の目的をベクトル形式でデータ化する。そしてそのベクトル化された情報に基づいて適切な広告を端末装置に配信する。これにより、先に説明された特許文献１と同様に、ユーザ個々の嗜好に合致した広告等の配信が実現される。
特表２００６−５０６７０７号公報 特開２００４−１０２９９６号公報

上述したように上記特許文献１及び２においては、サーバが、ユーザのコンテキスト情報を受け取り、その情報を用いて分析処理等を実行し、その処理結果を当該ユーザの嗜好に合わせた情報として端末装置に提供している。しかし、これら特許文献１及び２に記載のシステムでは以下に挙げられる問題が内在している。
（１）不特定多数の端末装置からサーバに対してコンテキスト情報が送信される。このためサーバと端末装置との間でやり取りされるコンテキスト情報には統一性がない。従って、例えばサーバ側で解釈できないコンテキスト情報が端末装置から送信されることもある。この場合、サーバが端末装置に対して適切な情報を提供することは極めて困難である。
（２）端末装置からサーバに送信されるコンテキスト情報によってはデータ量の多いものも存在する。データ量の多いコンテキスト情報の送受信は、トラフィックを増大させる要因の一つになり得るため望ましくない。
（３）コンテキスト情報そのものを送受信することは、ユーザのプライバシー保護の観点から望ましくない。

そこで、本発明は上記の事情に鑑みて、上記問題を解消し且つユーザ個々の嗜好に合わせた情報を端末装置に配信するのに好適なシステム及び動的情報提供方法を提供することを課題としている。またそのようなシステムに好適な端末及びサーバを提供することも課題としている。

上記の課題を解決する本発明の一態様に係るシステムは、相互通信可能なサーバと端末とを有したシステムである。このシステムの端末は、ユーザのコンテキスト情報を収集して保持するコンテキスト情報保持手段と、該保持されたコンテキスト情報に基づいて当該コンテキスト情報に対応した所定の形式のベクトルデータを生成するベクトルデータ生成手段とを具備する。そして、ベクトルデータ生成手段により生成されたベクトルデータをサーバに送信する。またサーバは、受信した該ベクトルデータに基づいて該ユーザに提供すべき情報を生成する提供情報生成手段を具備する。そして、提供情報生成手段により生成された提供情報を端末に送信する。

このような構成によれば、端末からサーバに送信されるコンテキスト情報は所定の形式のベクトルデータである。この所定の形式は、サーバの提供情報生成手段で解釈可能な形式である。このように、サーバと端末との間においてコンテキスト情報を所定の形式でやり取りするよう構成することで、サーバは、端末に対する情報提供を確実に実行することができるようになる。またやり取りされるデータがベクトル形式であるため、通信データ量を低減させるという効果も奏する。また更に、やり取りされるデータがコンテキスト情報そのものでない。これは、ユーザのプライバシーを保護するという観点から望ましいと言える。

なお上記システムにおいて、該ベクトルデータはサーバとのセッション確立をトリガーとしてサーバに送信されても良い。

また上記システムにおいてサーバは、例えば暫定的なパラメータ値を有する仮ベクトルデータを保持した仮ベクトルデータ保持手段を更に具備したものであっても良い。この場合サーバは、該保持された仮ベクトルデータを端末に送信するよう動作する。また端末は、例えばベクトルデータ生成手段により生成されたベクトルデータと該受信した仮ベクトルデータとを比較してその差分情報を生成する差分情報生成手段を更に具備したものであっても良い。この場合端末は、該生成された差分情報をサーバに送信するよう動作する。そして提供情報生成手段は、受信した該差分情報に基づいて該ユーザに提供すべき情報を生成するよう動作する。

また上記システムにおいてサーバは、例えば受信した該差分情報に基づいて該ベクトルデータを復元するベクトルデータ復元手段を更に具備したものであっても良い。

この仮ベクトルデータ保持手段は、例えば端末からの前回のベクトルデータを仮ベクトルデータとして保持することができる。

上記サーバは、端末からの所定のリクエストに呼応して該仮ベクトルデータを当該端末に送信するよう動作し得る。

また上記システムにおいて、該ベクトルデータはそれぞれ異なる複数種類の属性の情報から成る。この場合、ベクトルデータ生成手段は、例えばコンテキスト情報保持手段に保持されたコンテキスト情報に基づいて各属性の度合いを算出するよう動作する。

ここで、ベクトルデータ生成手段は、特定の属性に対して、所定期間中に収集されたコンテキスト情報に基づいてその詳細情報を取得してベクトルデータとすることができる。

また端末及びサーバは、該ベクトルデータを成す複数種類の属性の組み合わせ情報を複数セット保持したものであっても良い。

この場合、端末は、例えば該ベクトルデータをサーバに送信する際に当該ベクトルデータが何れのセットであるかを示す情報も送信するよう動作する。

またこの場合、ベクトルデータ生成手段は、例えばサーバのリクエストに応じた組み合わせの属性から成るベクトルデータを生成するよう動作する。

上記システムにおいて、該ユーザのコンテキスト情報には、例えばかな漢字変換処理の履歴、入力フォームへの入力履歴、アドレスバーに対するＵＲＬ、ＩＰアドレスの入力履歴のうちの少なくとも一つが含まれ得る。

上記システムにおいて、端末は例えば複数のアプリケーションを具備したものであっても良い。このような端末のコンテキスト情報保持手段は、該複数のアプリケーションから収集可能なコンテキスト情報を保持するよう動作する。

上記システムにおいて、端末は、例えば自己が現在位置する地域情報を取得する現在地域情報取得手段を更に具備したものであっても良い。この場合ベクトルデータ生成手段は、例えば該取得された地域情報を含むベクトルデータを生成するよう動作する。

この現在地域情報取得手段は、例えば地域に関する直近の履歴に基づいて、自己が現在位置する地域情報を取得するよう動作する。

上記システムにおいて、端末は例えばＧＰＳレシーバを更に具備したものであっても良い。この場合、現在地域情報取得手段は、ＧＰＳレシーバにより取得された現在位置情報に基づいて、自己が現在位置する地域情報を取得するよう動作する。

上記システムにおいて、サーバは例えば検索エンジンを有したサーバである。この場合、提供情報生成手段は、端末からの検索キーワード及び該ベクトルデータに基づいて検索結果を生成するよう動作する。

上記システムにおいて、サーバは、例えば検索結果を得るまでの検索処理の各段階に応じて、それぞれ異なるベクトルデータを端末にリクエストすることができる。

また上記の課題を解決する本発明の一態様に係る外部機器と相互通信可能な端末は、ユーザのコンテキスト情報を収集して保持するコンテキスト情報保持手段と、該保持されたコンテキスト情報に基づいて当該コンテキスト情報に対応した所定の形式のベクトルデータを生成するベクトルデータ生成手段とを具備し、該生成されたベクトルデータを該外部機器に送信することを特徴としたものである。

また上記の課題を解決する本発明の一態様に係るサーバは、外部機器から送信されるベクトルデータであって、所定のコンテキスト情報をベクトル形式でデータ化したベクトルデータを受信して処理するサーバである。このサーバは、受信した該ベクトルデータに基づいてユーザに提供すべき情報を生成する提供情報生成手段を具備し、該生成された提供情報を該外部機器に送信することを特徴としたものである。

また上記の課題を解決する本発明の一態様に係る動的情報提供方法は、端末に動的な情報を提供するための方法である。この動的情報提供方法は、該端末におけるユーザのコンテキスト情報を収集して保持するコンテキスト情報保持ステップと、該保持されたコンテキスト情報に基づいて当該コンテキスト情報に対応した所定の形式のベクトルデータを生成するベクトルデータ生成ステップと、該生成されたベクトルデータをサーバに送信するベクトルデータ送信ステップと、該サーバにおいて受信された該ベクトルデータに基づいて該ユーザに提供すべき情報を生成する提供情報生成ステップと、該生成された提供情報を該端末に送信する提供情報送信ステップとを含む。

このベクトルデータ送信ステップは、例えば該端末と該サーバとのセッション確立をトリガーとして実行される。

なお上記動的情報提供方法には、該サーバにおいて暫定的なパラメータ値を有する仮ベクトルデータを該端末に送信する仮ベクトルデータ送信ステップと、該端末において受信された仮ベクトルデータと、ベクトルデータ生成ステップで生成されたベクトルデータとを比較してその差分情報を生成する差分情報生成ステップと、該生成された差分情報を該サーバに送信する差分情報送信ステップとを更に含んだものも想定される。このような方法の提供情報生成ステップにおいては、受信された該差分情報に基づいて該ユーザに提供すべき情報が生成される。

上記動的情報提供方法には、例えば該端末からの該差分情報に基づいて該ベクトルデータを復元するベクトルデータ復元が更に含まれるものもある。

上記ベクトルデータ送信ステップは、例えば該端末からの所定のリクエストに呼応して実行される。

上記動的情報提供方法において、該ベクトルデータは例えばそれぞれ異なる複数種類の属性の情報から成るものである。このような場合ベクトルデータ生成ステップにより、コンテキスト情報保持ステップで保持されたコンテキスト情報に基づいて各属性の度合いが算出され得る。

上記動的情報提供方法においては、該サーバに送信すべきベクトルデータに含まれる属性の組み合わせが例えば当該サーバのリクエストに応じて決定される。

上記動的情報提供方法は、例えば端末が現在位置する地域情報を取得する現在地域情報取得ステップを更に含んだものであり得る。このような場合ベクトルデータ生成ステップにより、該取得された地域情報を含むベクトルデータが生成され得る。

また上記現在地域情報取得ステップにおいて、例えば地域に関する直近の履歴に基づいて、該端末が現在位置する地域情報が取得され得る。

本発明に係るシステム及び動的情報提供方法によれば、端末からサーバに送信されるコンテキスト情報は所定の形式のベクトルデータである。この所定の形式は、サーバの提供情報生成手段で解釈可能な形式である。このように、サーバと端末との間においてコンテキスト情報を所定の形式でやり取りするよう構成することで、サーバは、端末に対する情報提供を確実に実行することができるようになる。またやり取りされるデータがベクトル形式であるため、通信データ量を低減させるという効果も奏する。また更に、やり取りされるデータがコンテキスト情報そのものでない。これは、ユーザのプライバシーを保護するという観点から望ましいと言える。

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

図１は、本発明の実施の形態のネットワークシステムの構成を示したブロック図である。本実施形態のネットワークシステムは、例えば複数台の端末装置１０ａ乃至１０ｎ、及び、複数台のサーバ６０ａ乃至６０ｍで構築されている。各端末装置と各サーバは、例えばインターネットに代表される所定のネットワークを介して相互に接続される。

なお端末装置１０ａ乃至１０ｎは例えば所有者がそれぞれ異なるだけであり、構成としては実質的に同一であるものとする。またサーバ６０ａ乃至６０ｍも例えば配信するコンテンツや広告等が異なるだけであり、構成としては実質的に同一であるものとする。以下、説明の重複を避けるため、端末装置１０ａ及びサーバ６０ａの説明をもって、他の端末装置及びサーバ（すなわち端末装置１０ｂ乃至１０ｎ及びサーバ６０ｂ乃至６０ｍ）についての説明を省略する。

図２は、本発明の実施の形態の端末装置１０ａの構成を示したブロック図である。本実施形態の端末装置１０ａとしては、例えばデスクトップやラップトップ等のＰＣ（Personal Computer）や、携帯電話、ＰＤＡ（Personal Digital Assistance）或いはＰＨＳ（Personal Handy phone System）等の種々の形態のものが想定される。

図２に示されるように、端末装置１０ａはその全体を統括的に制御するＣＰＵ３を具備する。ＣＰＵ３にはバス１９を介して各構成要素が接続されている。これらの構成要素には、ＲＯＭ(Read-Only Memory)５、ＲＡＭ(Random-Access Memory)７、ネットワークインタフェース９、ディスプレイドライバ１１、インタフェース１５、ＨＤＤ（Hard Disk Drive）１６がある。ディスプレイドライバ１１、インタフェース１５はそれぞれ、ディスプレイ１３、ユーザインタフェースデバイス１７に接続されている。

ＲＯＭ５には各種プログラムや各種データが格納されている。ＲＯＭ５に格納されているプログラムには例えばブラウザ５０がある。このブラウザ５０は、所定のマークアップ言語で記述されたオンライン又はオフライン上の情報を閲覧するための情報閲覧ソフトウェアである。

ＲＡＭ７は例えばＲＯＭ５に格納されている各種プログラムの展開先である。ユーザインタフェースデバイス１７を用いたユーザ・オペレーション（以下、単に「ユーザ・オペレーション」と記す）にしたがって、ＲＯＭ５に格納されているプログラム（例えばブラウザ５０）が読み出されてＲＡＭ７の所定領域に展開されて実行される。これにより、ブラウザ５０が起動する。

ここで、ブラウザ５０の機能について説明する。図３を参照してブラウザ５０の基本的な構成要素であるブラウザエンジン３０について説明する。

図３は、ブラウザ５０に含まれるブラウザエンジン３０の機能ブロック図である。図３に示されるように、ブラウザエンジン３０は、パーサー３１、ページメーカ３２、およびフォーマッタ３３の各機能ブロックから構成される。

ユーザ・オペレーションによりＵＲＩ（Uniform Resource Identifier）を入力、或いはディスプレイ１３に表示中のページに含まれるＵＲＩをアンカータグの一つを選択することにより指定すると、ブラウザ５０は、インターネット上のＵＲＩ（例えばサーバ６０ａ）からＨＴＭＬ（Hyper Text Markup Language）文書２１（すなわちリクエストされたページ）を取得するよう動作する。

なお上記「ページ」とは、クライアント（ここではブラウザ５０）がサーバからネットワーク経由で取得するデータのまとまりであり、ユーザがあるＵＲＩを指定したときに表示されるべき内容全体を指す。ページは例えばＨＴＭＬ形式で記述されたものであり、テキストデータ、画像ファイル、音声データ等の種々のデータで構成される。

ここで、図４に、本発明の実施の形態のサーバ６０ａの構成をブロック図で示す。サーバ６０ａはその全体を統括的に制御するＣＰＵ６２を具備する。ＣＰＵ６２にはバス７２を介して各構成要素が接続されている。これらの構成要素には、ＣＰＵ６２、ＲＯＭ６４、ＲＡＭ６６、ネットワークインタフェース６８、ＨＤＤ７０がある。

ＲＯＭ６４には、クライアント（ここでは端末装置１０ａ乃至１０ｎ）からのリクエストに応じた処理を実行するための種々のプログラムやデータが格納されている。これらのプログラムはサーバ６０ａが起動している限り、例えばＲＡＭ６６に展開されて常駐した状態にある。すなわちサーバ６０ａはクライアントからのリクエストの有無を常に監視した状態にある。そして、リクエストがあればそれに対する処理を直ぐさま実行することができる。

サーバ６０ａは、ＨＴＭＬ文書２１を始めとする種々のページから成るコンテンツをＨＤＤ７０に格納している。ＣＰＵ６２は、所定のネットワーク及びネットワークインタフェース６８を介して端末装置１０ａからの上記リクエストを受け取ると、その指定されたＵＲＩに応じたページ（すなわちＨＴＭＬ文書２１）をＨＤＤ７０から読み出す。次いで、その読み出されたＨＴＭＬ文書２１をネットワークインタフェース６８及び所定のネットワークを介して端末装置１０ａに送信する。

サーバ６０ａから送出されたＨＴＭＬ文書２１は、所定のネットワーク及びネットワークインタフェース９を介して次にパーサー３１に渡される。

パーサー３１は、このＨＴＭＬ文書２１を解釈し、ＨＴＭＬ文書２１の文法構造がツリー構造で表されたドキュメントツリー２３を作成する。なお、ドキュメントツリー２３は、ＨＴＭＬ文書２１の文法構造を表現するのみであり、ドキュメントの表現に関する情報までは含んでいない。

次に、ページメーカ３２は、ドキュメントツリー２３及びタグに関する情報を基に、ＨＴＭＬ文書２１の表現形式、例えばblock, inline, table, list, item等を含むレイアウトツリー２５を作る。すなわち、レイアウトツリー２５は、block, inline, tableなどの順番に関する情報を含んでいる。なお、レイアウトツリー２５は、これらの要素（block, inline, table等）の画面上での位置やサイズについての情報は含んでいない。

フォーマッタ３３は、レイアウトツリー２５とディスプレイ１３の画面サイズに関する情報を基に、ディスプレイ１３の画面上に各項目をレイアウトする。つまり、フォーマッタ３３は、ディスプレイ１３の画面上に項目を配置し、各項目の画面上の位置、幅、高さや、ＨＴＭＬ文書２１内の文字の折り返し位置を決定する。

パーサー３１、ページメーカ３２、フォーマッタ３３による以上のような処理を経て、ＨＴＭＬ文書２１、すなわちリクエストされたページがディスプレイ１３に表示される。

次いで、ＲＯＭ５に格納されているプログラムについての更なる説明を行う。ＲＯＭ５には、ユーザベクトルＵを算出するためのユーザベクトル算出プログラムが格納されている。このユーザベクトル算出プログラムは、サーバ側と連携するよう機能して、ユーザに対する動的な情報提供を実現することができる。なおこのユーザベクトル算出プログラムは、端末装置１０ａがサーバ６０ａ等からダウンロードしてその後実装されたプログラムであっても良く、或いは、端末装置１０ａに予め実装されたプログラムであっても良い。

ユーザベクトル算出プログラムで算出される「ユーザベクトルＵ」とは、ユーザのコンテキスト情報を例えば１２８種類の属性に分類し、それらの各属性をベクトル化したデータである。すなわちユーザベクトルＵは、１２８次元のベクトルデータ（ｕ１、ｕ２、・・・、ｕ１２８）である。ユーザベクトルＵを成す１２８種類の属性には、例えば「男性」、「都内」、「ビジネスマン」、「サッカー」、「日本酒」、「読書」、「ＴＶ」、「ＰＣ」、「社交的」、「健康志向」等がある。なお本実施形態におけるコンテキスト情報には、ユーザの嗜好や生活習慣、プロフィール（氏名や出身地）等が含まれる。

１２８種類の属性をセットとしたデータ（以下、「属性データ」と記す）は例えばＨＤＤ１６に格納されている。附言するにＨＤＤ１６には、それぞれ異なる組み合わせの属性で構成された属性データが例えば１００セット格納されている。

ＨＤＤ１６には、ユーザ・オペレーションに応じたかな漢字入力を受け付けるためのかな漢字変換辞書が格納されている。かな漢字変換辞書に収録されている各単語には、何れの属性に該当するかを示す情報（以下、「単語属性情報」と記す）が関連付けて記録されている。かな漢字変換辞書において、例えば「東京」という単語のデータには「都内」の属性に該当することを示すフラグが立てられている。一方で「都内」以外の他の属性に対してはフラグが立てられていない。このようなデータ（すなわち単語属性情報）の追加に必要な容量は、例えばかな漢字変換辞書が６万語を収録したものである場合には１００Ｋバイト程度である。従ってこのような単語属性情報は、記録媒体の容量が比較的限定的な端末装置（例えば携帯電話等の携帯端末）においても十分に実装可能である。

またＨＤＤ１６には、ＵＲＬと所定のキーワードを関連付けて記憶したＵＲＬ辞書も格納されている。ＵＲＬ辞書に登録されている各ドメイン名には、何れの属性に該当するかを示す情報（以下、「ドメイン属性情報」と記す）が関連付けて記録されている。ＵＲＬ辞書において、例えば「www.○○○○○book.co.jp」というドメイン名のデータには「読書」の属性に該当することを示すフラグが立てられている。一方で「読書」以外の他の属性に対してはフラグが立てられていない。なおＵＲＬ辞書に登録されているドメイン名の数が多い場合、例えば６４ビットのハッシュテーブルを利用してドメイン属性情報の容量を圧縮するよう構成しても良い。

またＨＤＤ１６には、ＩＰアドレスと所定のキーワードを関連付けて記憶したＩＰアドレス辞書も格納されている。ＩＰアドレス辞書に登録されている各ＩＰアドレスには、何れの属性に該当するかを示す情報（以下、「ＩＰアドレス属性情報」と記す）が関連付けて記録されている。ＩＰアドレス辞書において、例えば「211.10.36.43」というＩＰアドレスのデータには「ＴＶ」の属性に該当することを示すフラグが立てられている。一方で「ＴＶ」以外の他の属性に対してはフラグが立てられていない。なおＩＰアドレス辞書に登録されているドメイン名の数が多い場合も、ＵＲＬ辞書の例と同様に、例えば６４ビットのハッシュテーブルを利用してＩＰアドレス属性情報の容量を圧縮するよう構成しても良い。

一単語（又は一ＵＲＬ、一ＩＰアドレス）に対して、上記例では該当する属性を一つとしているが、別の例では複数の属性に該当するようにしても良い。このような場合、例えばかな漢字変換辞書において「東京」という単語のデータに「都内」、「サッカー」、「ビジネスマン」等の複数の属性に対してフラグが立てられている。

１２８種類の属性の各々は、その「確からしさ」が例えば０％、２５％、５０％、７５％の４段階（すなわち２ビット）で表される。「確からしさ」は例えばユーザの嗜好を段階的に示したものである。すなわち１２８種類の属性がユーザベクトルＵの方向を示すのに対して、「確からしさ」はユーザベクトルＵの大きさを示す。このユーザベクトルＵによりユーザの嗜好等がベクトルで示される。

具体的には、例えばユーザベクトル算出プログラムによりユーザがサッカーに非常に興味を持っていると判断されたとき、「サッカー」の属性の「確からしさ」が７５％と算出される。一方、ユーザがサッカーに全く興味を持っていないと判断されたとき、「サッカー」の属性の「確からしさ」が例えば０％と算出される。なお「確からしさ」に関する設定は、端末装置とサーバとの間で予め合意されたものであれば如何なるものであっても良い。例えば「確からしさ」の数値を上記のものに限らず、それぞれ、１０％、３０％、６０％、９０％等に設定しても良い。また「確からしさ」の段階を２ビットでなく３ビット（すなわち８段階）で表すよう設定しても良い。

各属性の「確からしさ」の段階は、ＨＤＤ１６に蓄積されるコンテキスト情報に基づいて決定される。ＨＤＤ１６にはコンテキスト情報として、例えば「かな漢字変換パターン」、「フォームテキスト」、「ＵＲＬアドレスパターン」、「ＩＰアドレスパターン」が蓄積される。

「かな漢字変換パターン」は、ユーザ・オペレーションによるかな漢字変換処理の履歴である。ここで、ＲＡＭ７には、かな漢字変換辞書の各単語に対して関連付けをされたカウンタ（以下、「単語カウンタ」と記す）が保持されている。端末装置１０ａを用いた文書作成等において、かな漢字変換により例えば「社交的」という単語が入力された場合、かな漢字変換辞書の「社交的」という単語に関連付けられた単語カウンタが１インクリメントされる。すなわち端末装置１０ａにおいて、かな漢字変換処理された何らかの単語が入力される度に、当該単語に関連付けられた単語カウンタがインクリメント処理される。

「フォームテキスト」は、例えばページに含まれる入力フォームへの入力履歴である。なおここでいう入力フォームとは、例えばＨＴＭＬ文書において<form>〜</form>で記述された部分の解釈結果をレンダリングしたものである。ブラウザ５０上でレンダリングされた入力フォームにユーザ・オペレーションによりキーワードが入力されると、その入力キーワードが「フォームテキスト」としてＨＤＤ１６に蓄積される。更に、かな漢字変換辞書においてその入力キーワードに一致する単語に関連付けられた単語カウンタが１インクリメントされる。但し、その入力キーワードがかな漢字変換辞書に含まれないものである場合、何れの単語カウンタもインクリメントされない。

「ＵＲＬアドレスパターン」は、ブラウザ５０のアドレスバーに対するＵＲＬの入力履歴である。ここで、ＲＡＭ７には、ＵＲＬ辞書の各ＵＲＬに対して関連付けをされたカウンタ（以下、「ＵＲＬカウンタ」と記す）が保持されている。ユーザ・オペレーションによりアドレスバーにＵＲＬが入力されると、その入力ＵＲＬに関連付けられたＵＲＬカウンタが１インクリメントされる。なおその入力ＵＲＬがＵＲＬ辞書に含まれないものである場合、何れのＵＲＬカウンタもインクリメントされない。

「ＩＰアドレスパターン」は、ブラウザ５０のアドレスバーに対するＩＰアドレスの入力履歴である。ここで、ＲＡＭ７には、ＩＰアドレス辞書の各ＩＰアドレスに対して関連付けをされたカウンタ（以下、「ＩＰカウンタ」と記す）が保持されている。ユーザ・オペレーションによりアドレスバーにＩＰアドレスが入力されると、その入力ＩＰアドレスに関連付けられたＩＰカウンタが１インクリメントされる。なおその入力ＩＰアドレスがＩＰアドレス辞書に含まれないものである場合、何れのＩＰカウンタもインクリメントされない。

ここで、「入力」には文字列の入力によるものだけに限らず、ユーザの選択（選択肢の選択結果、ＵＲＬのクリック、コピー＆ペースト等）による入力も含まれる。

なお端末装置１０ａにおいて、各辞書の全ての単語、ＵＲＬ、ＩＰアドレスに関連付けられた単語カウンタ、ＵＲＬカウンタ、ＩＰカウンタのカウント値の総数（以下、「総数カウント値」と記す）も別途カウントされている。

端末装置１０ａは、各辞書のフラグ（すなわち各単語、ＵＲＬ、ＩＰアドレスが何れの属性であるかを示す情報）と各カウンタのカウント値に基づいて、属性データに含まれる各属性の「確からしさ」の段階を決定する。

より詳細には端末装置１０ａは、属性データに含まれる属性それぞれに対して以下の処理を行ってその「確からしさ」の段階を決定する。
（１）各辞書の全ての単語、ＵＲＬ、ＩＰアドレスを検索し、処理対象の属性についてフラグが立てられているものを抽出する。
（２）（１）で抽出された単語、ＵＲＬ、ＩＰアドレスに関連付けられた単語カウンタ、ＵＲＬカウンタ、ＩＰカウンタのカウント値を検索し、最も高いカウント値を抽出する。
（３）（２）で抽出されたカウント値を総数カウント値で割り、利用頻度確率を算出する。

ここで、ＨＤＤ１６には、各属性と、「確からしさ」に関する閾値とを関連付けた閾値テーブルが蓄積されている。この閾値テーブルの各レコードには、属性それぞれについて、それぞれ異なる三つの閾値ｎ_１、ｎ_２、ｎ_３（ｎ_１＜ｎ_２＜ｎ_３）が関連付けられてエントリされている。これらの閾値は、「確からしさ」を表す２ビットの値（すなわち０乃至３）が何％の利用頻度確率で切り替わるかを決定するための値である。端末装置１０ａは上記（３）の処理に次いで、下記（４）の処理を行う。
（４）検索対象の属性の「確からしさ」を表す２ビットの値を、閾値テーブルを参照して利用頻度確率に基づき算出する。

具体的には、上記（３）の処理で算出された利用頻度確率がｎ_１％より低い場合、「確からしさ」を表す２ビットの値は「０」とされる。また、利用頻度確率がｎ_１％以上で且つｎ_２％より低い場合、上記２ビットの値は「１」とされる。また利用頻度確率がｎ_２％以上で且つｎ_３％より低い場合、上記２ビットの値は「２」とされる。また、利用頻度確率がｎ_３％以上である場合、上記２ビットの値は「３」とされる。上記（４）の処理により、ユーザベクトルＵ（ｕ１、ｕ２、・・・、ｕ１２８）は例えば（０、３、・・・、２）等の値とされる。

以上説明したように属性データに含まれる各属性について上記（１）乃至（４）の処理が実行されると、１２８種類の属性の各々についてその「確からしさ」を２ビットで表したデータ、すなわちユーザベクトルＵが算出される。

なお利用頻度確率の算出には別の方法を採用しても良い。例えば上記（２）で検索された全てのカウント値の合計を総数カウント値で割り、利用頻度確率を算出する方法が挙げられる。

また上記（２）で検索された全てのカウント値の各々に対して重み付け処理を行い、利用頻度確率を算出しても良い。例えば上記（２）で検索されたカウント値それぞれについて、その値が大きいものから順にウェイトの高い重み付け係数を乗算する。具体的には、カウント値の大きいものから順に例えば１、０．９、０．８１、０．７２９・・・（以下、前出の値に０．９を乗じた値）の重み付け係数を乗算する。次いで、それらの乗算結果を加算してその総和を算出する。そしてその総和を総数カウント値で割り、利用頻度確率を算出する。

なお閾値テーブルの各レコードにエントリされるべき各閾値は、利用頻度確率の算出方法に応じて適宜設定する必要がある。

次に、本実施形態のネットワークシステムにおいて端末装置１０ａとサーバ６０ａとの間でやり取りされる処理について具体的に説明する。

図５に、本発明の第一の実施例において端末装置１０ａとサーバ６０ａとの間でやり取りされる処理の流れを示す。

本実施例１においては、先ず、端末装置１０ａとサーバ６０ａとのセッションが確立されると、端末装置１０ａがサーバ６０ａにユーザベクトルＵを送信する（ステップ１、以下の明細書及び図面においてステップを「Ｓ」と略記）。ここでいうセッションとは、ブラウザ５０によるサーバへのアクセスから、情報のリクエスト及びそれに対するレスポンス、切断までを一単位としたものである。従って上記セッションの確立は、例えばユーザ・オペレーションによりブラウザ５０のアドレスバーにＵＲＬが入力されたことで果たされる。つまりＳ１１の処理において端末装置１０ａは、ＵＲＬで指定したページのリクエストと共にユーザベクトルＵを送信する。

附言するにＳ１１の処理では、ユーザベクトルＵが、例えばセッションの確立と同時にユーザベクトル算出プログラムにより算出されてページのリクエストと共に送信される。しかし、端末装置の性能によってはユーザベクトルＵの算出処理に時間が掛かることも想定される。このような場合、ＵＲＬが入力された時点では、送信処理において例えばページのリクエストのみを送信し、それと並行してユーザベクトル算出処理を行う。そしてユーザベクトルＵが算出された時点で入力ＵＲＬ宛に当該ユーザベクトルＵを送信する。これにより、ブラウザ５０においてスムーズなページ・ブラウジングが実現される。

また端末装置１０ａがユーザベクトル算出プログラムを定期的に実行させて比較的新しいユーザベクトルＵをＲＡＭ７等で常に保持しておくようにしても良い。この場合、Ｓ１１の処理で送信されるユーザベクトルＵはＲＡＭ７等に予め保持されたものとなる。このためセッション確立時にユーザベクトルＵを算出する必要がない。このような場合もブラウザ５０におけるスムーズなページ・ブラウジングが実現されるようになる。

なおＳ１１の処理で送信されるユーザベクトルＵは、ＨＤＤ１６に格納された１００セットの属性データのうち、予め設定されている１セットの属性データを用いて算出されたものである。本実施例１では、ユーザベクトル算出処理に用いられる属性データが、例えばアクセス先に拘わらず常に同一となるように設定されている。一方、別の実施例では、ユーザベクトル算出処理に用いられる属性データが例えばアクセス先によって変わるように設定されていても良い。

サーバ６０ａのＨＤＤ７０にも、端末装置１０ａが保持する１００セットの属性データと同一のデータが格納されている。Ｓ１１の処理において端末装置１０ａはページのリクエスト等と共に、例えば何れのセットの属性データを用いてユーザベクトルＵを算出したかを報知する情報も送信することができる。この情報により、サーバ６０ａはユーザベクトルＵに含まれる各属性を詳細に知ることができる。

サーバ６０ａは、ページのリクエスト及びユーザベクトルＵを受信するとその旨を報知する確認通知を端末装置１０ａに送信する。そしてレスポンス（すなわちページ）を端末装置１０ａに送信する（Ｓ１２）。ＨＤＤ７０には、ユーザベクトルＵとその送信元とを関連付けたユーザ情報データベースが蓄積されている。サーバ６０ａは、受信したユーザベクトルＵを、その送信元に関連付けてユーザ情報データベースに蓄積する。

端末装置１０ａがＳ１２の処理で送信されたページを受け取ると、ブラウザ５０が当該ページを解釈してレンダリングする。ここで、サーバ６０ａは例えば検索エンジンを提供する端末である。従ってブラウザ５０上には、サーバ６０ａにより提供される検索エンジンが表示されることになる。ユーザ・オペレーションによりこの検索エンジンの入力フォームに検索キーワードが入力されると、ブラウザ５０は、その検索キーワードを含むＵＲＬをサーバ６０ａに送信する（Ｓ１３）。

サーバ６０ａはＳ１３の処理で送信されたＵＲＬを受け取ると、自己に実装されたＣＧＩ（Common Gateway Interface）プログラムを起動させて周知の検索処理を行う。

ここで、サーバ６０ａのＨＤＤ７０には、検索処理で検索された各サイトに対する検索キーワードの当てはまり度を算出するための式が保持されている。この式は例えば、
ｋ＝ｖ０＋ｖ１ｕ１＋ｖ２ｕ２＋ｖ３ｕ３＋・・・＋ｖｊｕｊ・・・（１）
で表される。「ｖ０」は所定の初期値であり、端末装置１０ａから送信されるユーザベクトルＵに依存しない値である。「ｖ１」乃至「ｖｊ」は所定の係数であり、例えばパイロットユーザから収集したコンテキスト情報等に基づいてその値が決定される。これら「ｖ１」乃至「ｖｊ」は正負何れの値をとることもできる。「ｕ１」乃至「ｕｊ」の各々はユーザベクトルＵの各属性に対応した変数である。なおｊは例えば１２８である。

ＨＤＤ７０には、上記式（１）に代入すべき初期値ｖ０と係数ｖ１乃至ｖｊの組み合わせが複数パターン保持されている。サーバ６０ａは例えば検索キーワードやユーザベクトルＵに含まれる属性の内容に応じて、適切な上記組み合わせをＨＤＤ７０より抽出する。そして上記検索処理で検索された各サイトに対する当てはまり度ｋを算出する。例えば抽出された組み合わせ内容が「初期値ｖ０＝０．７６、係数（ｖ１、ｖ２、ｖ３、・・・ｖｊ）＝（０．０２、０．０４、−０．０３、・・・０．１２）」であるとき、上記式（１）は、
ｋ＝０．７６＋０．０２ｕ１＋０．０４ｕ２−０．０３ｕ３・・・＋０．１２ｕｊ
となる。

検索されたサイトがユーザの嗜好等に合ったものである場合、当該サイトに対する当てはまり度ｋは上記式（１）による算出の結果、比較的高い確率で初期値Ｖ０よりも高い値になる。これに対して検索されたサイトがユーザの嗜好等に合ったものでない場合、当該サイトに対する当てはまり度ｋは上記式（１）による算出の結果、比較的高い確率で初期値Ｖ０よりも低い値になる。つまり、サイトの嗜好等がユーザに合ったものであればあるほど当てはまり度ｋも高い値となる。

上述したように「確からしさ」に関する設定は、端末装置とサーバとの間で予め合意されている。従ってサーバ６０ａは、この設定に基づいてユーザベクトルＵの各値を変換する。具体的にはユーザベクトルＵが例えば（０、１、３、２、・・・）であるとき、（０、０．２５、０．７５、０．５、・・・）に変換される。これら変換後の各値が上記式（１）の「ｕ１」乃至「ｕｊ」の各々に代入されて当てはまり度ｋが算出される。

次いでサーバ６０ａは、上記検索処理で検索された各サイトに対する当てはまり度ｋに基づいて、その検索結果に対する並べ替え処理を実行する。具体的には、当てはまり度ｋが高いサイトほど上位となるように並び替え処理を実行する。すなわちこの処理により、ユーザベクトルＵが示すユーザの嗜好等に合うサイト等が検索の上位に位置するように検索結果が並べ替えられる。サーバ６０ａは、この並べ替えられた検索結果のページを端末装置１０ａに送信する（Ｓ１４）。

端末装置１０ａがＳ１４の処理で送信された検索結果のページを受け取ると、ブラウザ５０において、ユーザの嗜好等に合ったサイトが検索の上位に位置する検索結果がレンダリングされる。つまり本実施例１によれば、ユーザは、その嗜好等が加味された動的な検索結果を得ることができる。

なおサーバ６０ａは上記並べ替え処理の代替として、検索結果に対する絞り込み処理を実行することもできる。この場合サーバ６０ａは、上記検索処理で検索された各サイトに対する当てはまり度ｋを参照して、当該当てはまり度ｋが所定の閾値以下であるサイトを検索結果から除外する。換言すると、その当てはまり度ｋが所定の閾値より高いサイトだけを残すよう検索結果を絞り込む。この処理により、ユーザベクトルＵが示すユーザの嗜好等に合うサイトだけが検索結果として残る。この場合もユーザは先と同様に、その嗜好等が加味された動的な検索結果を得ることができる。

またサーバ６０ａは上記並べ替え処理の代替として、初期値Ｖ０と当てはまり度ｋとの差が大きいサイトを上位に並べる、或いはハイライト表示させることもできる。

附言するに、検索エンジンを提供するサーバには広告収入等で運営されているものが多い。サーバ６０ａは、例えば端末装置１０ａからのユーザベクトルＵに基づいてそのユーザの嗜好等に合った広告（例えば広告画像や広告キーワード、そのリンク等）を取得するよう動作することもできる。そしてこの場合、取得された広告を検索結果のページに含めて端末装置１０ａに送信する。これによりブラウザ５０において、検索結果に加えて上記広告もレンダリングされる。このような形態によればそれぞれに対してメリットが享受される。すなわちユーザにはその嗜好等に合った広告が提供される。また広告業者には、各ユーザに対して適切な広告を提供し宣伝効果等を向上させることができる。またサーバには、広告業者から広告収入を得ることができる。

図６に、本発明の第二の実施例において端末装置１０ａとサーバ６０ａとの間でやり取りされる処理の流れを示す。

図６に示される処理は、例えば端末装置１０ａがサーバ６０ａに対してページのリクエスト等を行った（或いはセッションが確立した）時点で開始される。サーバ６０ａは、上記リクエストに呼応して仮ユーザベクトルＵ’を端末装置１０ａに送信する（Ｓ２１）。ここで送信される仮ユーザベクトルＵ’は、例えばユーザ情報データベースにおいて端末装置１０ａと関連付けされたユーザベクトルＵ（すなわち端末装置１０ａが前回送信したユーザベクトル）そのものである。なお、ユーザ情報データベースに端末装置１０ａのユーザベクトルＵが蓄積されていない場合には、例えば適当な仮ユーザベクトルＵ’を暫定的に生成して端末装置１０ａに送信する。

端末装置１０ａは、仮ユーザベクトルＵ’を受信するとその差分データを生成する。説明を加えると、端末装置１０ａは仮ユーザベクトルＵ’の受信をトリガーとしてユーザベクトル算出プログラムを起動させる。そしてユーザベクトルＵを算出する。次いで、その算出されたユーザベクトルＵと仮ユーザベクトルＵ’とを比較してその差分データを生成する。

端末装置１０ａは、生成された差分データをサーバ６０ａに送信する（Ｓ２２）。サーバ６０ａは、この差分データを受信するとその旨を報知する確認通知を端末装置１０ａに送信する。そしてレスポンス（すなわちページ）を端末装置１０ａに送信する（Ｓ２３）。またサーバ６０ａは、差分データに基づいてユーザ情報データベースに蓄積された端末装置１０ａのユーザベクトルＵを更新する。この更新処理により、ユーザ情報データベースには、上記において端末装置１０ａで生成されたユーザベクトルＵと同一のデータが蓄積されることになる。

端末装置１０ａがＳ２３の処理で送信されたページを受け取ると、本実施例１と同様にサーバ６０ａによる検索エンジンが表示される。ユーザ・オペレーションによりこの検索エンジンの入力フォームに検索キーワードが入力されると、ブラウザ５０は、その検索キーワードを含むＵＲＬをサーバ６０ａに送信する（Ｓ２４）。

サーバ６０ａは、Ｓ２４の処理で送信されたＵＲＬを受け取ると、更新されたユーザベクトルＵに基づいて、上述した一連の処理（すなわち検索処理、及び、並び替え処理（又は絞り込み処理））を実行する。そしてその検索結果のページを端末装置１０ａに送信する（Ｓ２５）。これによりユーザは本実施例１と同様に、その嗜好等が加味された動的な検索結果を得ることができる。

本実施例２によれば、端末装置１０ａはユーザベクトルＵの代替として差分データを送信する。このため送信データの容量が大幅に圧縮されるという効果が奏される。ユーザベクトルＵの次元やビット数が多ければ多いほどその効果は顕著となり得る。

図７に、本発明の第三の実施例において端末装置１０ａとサーバ６０ａとの間でやり取りされる処理の流れを示す。

図７に示される処理は、例えばサーバ６０ａが提供する検索エンジンの入力フォームに検索キーワードが入力された時点で開始される。本実施例３によれば、ユーザ・オペレーションにより検索エンジンの入力フォームに検索キーワードが入力されると、ブラウザ５０は、その検索キーワードを含むＵＲＬをサーバ６０ａに送信する（Ｓ３１）。

サーバ６０ａは、Ｓ３１の処理で送信されたＵＲＬを受け取ると周知の検索処理を実行して、その検索結果のページと共に仮ユーザベクトルＵ’を端末装置１０ａに送信する（Ｓ３２）。

端末装置１０ａがＳ３２の処理で送信された検索結果のページを受け取ると、ブラウザ５０において、ユーザの嗜好等を加味していない通常の検索結果がレンダリングされる。なおここでレンダリングされるページには、再検索処理をサーバ６０ａに実行させるためのボタンが含まれる。ユーザ・オペレーションにより当該ボタンがクリックされると、端末装置１０ａは、サーバ６０ａからの仮ユーザベクトルＵ’を用いてその差分データを生成する。次いで、その生成された差分データをサーバ６０ａに送信する（Ｓ３３）。

サーバ６０ａは、Ｓ３３の処理で送信された差分データを受け取ると、ユーザ情報データベースに蓄積された端末装置１０ａのユーザベクトルＵを更新する。次いで、更新されたユーザベクトルＵに基づいて、上述した一連の処理（すなわち検索処理、及び、並び替え処理（又は絞り込み処理））を実行する。そしてその検索結果のページを端末装置１０ａに送信する（Ｓ３４）。これによりユーザは本実施例１及び２と同様に、その嗜好等が加味された動的な検索結果を得ることができる。

本実施例３によれば、端末装置１０ａは通常の検索結果を得ることができる。そして必要とするのであればユーザの嗜好等が加味された動的な検索結果も得ることができる。

図８に、本発明の第四の実施例において端末装置１０ａとサーバ６０ａとの間でやり取りされる処理の流れを示す。

図８に示される処理は、例えばユーザ・オペレーションによりブラウザ５０がサーバ６０ａにログインした時点で開始される（Ｓ４１）。サーバ６０ａは、ログイン時に入力されたアカウント及びパスワードを受信すると、その確認通知をブラウザ５０に返信する（Ｓ４２）。次いでブラウザ５０は、この確認通知に呼応してユーザベクトルＵを送信する（Ｓ４３）。ここで送信されるユーザベクトルＵには、例えばユーザが現在位置する地域を表すための「現在地域」等の属性が含まれる。

「現在地域」の属性には「確からしさ」の代替として、地域を示すデータがエントリされる。エントリされる地域は例えば直近のコンテキスト情報に基づいて決定される。これについて、横浜在住のユーザが大阪に出張する場合を例に取り説明する。

このような場合ユーザは、例えば端末装置１０ａを用いて大阪に関する情報（街の情報や乗り換え案内等）をまとまった期間（例えば出張中）に集中的に検索・入力することが想定される。従って出張中における直近のコンテキスト情報によれば、大阪に関する情報の入力履歴等が一時的に多くなる。附言するに直近のコンテキスト情報に限れば、横浜に関する情報よりも大阪に関する情報の割合が高くなり得る。直近のコンテキスト情報を参照して各地域に関する情報を比較し、例えば最も出現回数の多い地域をユーザが現在位置する地域として推定することができる。このように推定された地域が例えば「現在地域」にエントリさせるべき地域とされる。

また携帯装置１０ａに周知のＧＰＳ（Global Positioning System）レシーバが搭載されている場合、当該ＧＰＳレシーバによる測位結果を参照して「現在地域」を決定することもできる。

サーバ６０ａはユーザベクトルＵを受信すると、当該ユーザベクトルＵをその送信元に関連付けてユーザ情報データベースに蓄積する。次いでその確認通知をページと共にブラウザ５０に送信する（Ｓ４４）。

端末装置１０ａがＳ４４の処理で送信されたページを受け取ると、ブラウザ５０上でサーバ６０ａによる検索エンジンが表示される。ユーザ・オペレーションによりこの検索エンジンの入力フォームに検索キーワードが入力されると、ブラウザ５０は、その検索キーワードを含むＵＲＬをサーバ６０ａに送信する（Ｓ４５）。

サーバ６０ａはＳ４５の処理で送信されたＵＲＬを受け取ると、上記ユーザベクトルＵに基づいて、上述した一連の処理（すなわち検索処理、及び、並び替え処理（又は絞り込み処理））を実行する。そしてその検索結果のページを端末装置１０ａに送信する（Ｓ４６）。これによりユーザは本実施例１と同様に、その嗜好等が加味された動的な検索結果を得ることができる。

サーバ６０ａは、本実施例４の如く「現在地域」の属性を含むユーザベクトルを用いて処理を行う場合、当該属性にエントリされた地域に重点を置いた検索結果をユーザに提供するよう動作する。例えば「現在地域」にエントリされたデータが「東京」を示す場合、サーバ６０ａは、検索処理において例えば都内全ての鉄道路線名を検索条件式に加えた絞り込みを行うよう動作する。

図９に、本発明の第五の実施例において端末装置１０ａとサーバ６０ａとの間でやり取りされる処理の流れを示す。ここで、説明の便宜上、１００セットの属性データの各々に「Ａ_１」乃至「Ａ_１００」を付す。また属性データＡ_１乃至Ａ_１００の各々を用いて生成された各ユーザベクトルに「Ｕ_Ａ１」乃至「Ｕ_Ａ１００」を付す。

図９に示される処理は、例えば端末装置１０ａとサーバ６０ａとのセッションが確立された時点で開始される。本実施例５によれば、端末装置１０ａとサーバ６０ａとのセッションが確立されると、端末装置１０ａは、属性データＡ_１に基づいてユーザベクトルＵ_Ａ１を生成しサーバ６０ａに送信する（Ｓ５１）。

サーバ６０ａは、ページのリクエスト及びユーザベクトルＵ_Ａ１を受信するとその旨を報知する確認通知を端末装置１０ａに送信する。そしてページを端末装置１０ａに送信する（Ｓ５２）。またサーバ６０ａは、受信したユーザベクトルＵ_Ａ１をその送信元に関連付けてユーザ情報データベースに蓄積する。

端末装置１０ａがＳ５２の処理で送信されたページを受け取ると、ブラウザ５０上でサーバ６０ａによる検索エンジンが表示される。ユーザ・オペレーションによりこの検索エンジンの入力フォームに検索キーワードが入力されると、ブラウザ５０は、その検索キーワードを含むＵＲＬをサーバ６０ａに送信する（Ｓ５３）。

サーバ６０ａは検索キーワードを受け取ると、次に、ユーザベクトルＵ_Ａ１０を端末装置１０ａにリクエストする（Ｓ５４）。端末装置１０ａはこのリクエストに呼応して、属性データＡ_１０に基づいてユーザベクトルＵ_Ａ１０を生成する。そしてこの生成されたユーザベクトルＵ_Ａ１０をサーバ６０ａに送信する（Ｓ５５）。

サーバ６０ａは、Ｓ５５の処理で送信されたユーザベクトルＵ_Ａ１０を受け取ると、ユーザベクトルＵ_Ａ１及びユーザベクトルＵ_Ａ１０に基づいて、上述した一連の処理（すなわち検索処理、及び、並び替え処理（又は絞り込み処理））を実行する。すなわちサーバ６０ａは、二つのユーザベクトルに含まれる属性に関して上述した一連の処理を実行する。そしてその検索結果のページを端末装置１０ａに送信する（Ｓ５６）。これによりユーザは本実施例１と同様に、その嗜好等が加味された動的な検索結果を得ることができる。

なお本実施例５においてサーバ６０ａがより多くのユーザベクトルをリクエストするよう動作しても良い。この場合、より多数の属性に関して上述した一連の処理が実行される。

またＳ５６の処理以降にサーバ６０ａが例えば更なる検索キーワードを端末装置１０ａから受け取った場合、当該サーバ６０ａは、更に別のユーザベクトルＵ_ｎ（ユーザベクトルＵ_Ａ１、Ｕ_Ａ１０以外）を端末装置１０ａにリクエストする。端末装置１０ａはこのリクエストに呼応してユーザベクトルＵ_ｎを生成してサーバ６０ａに送信する。サーバ６０ａはこれを受け取り、上記ユーザベクトルＵ_Ａ１、Ｕ_Ａ１０に加えてユーザベクトルＵ_ｎ（又はこれらのうちの少なくとも一つ）に基づいて、上述した一連の処理（すなわち検索処理、及び、並び替え処理（又は絞り込み処理））を実行する。すなわちサーバ６０ａは、検索のリクエストを同一セッションにおいて続けて受けたとき、前回とは異なるユーザベクトルを端末装置１０ａにリクエストするよう動作する。

これらの実施例によれば、サーバは、端末装置で生成されたベクトルデータを受け取り、これを用いることで動的な情報提供を実現している。このベクトルデータはサーバにとって既知のパラメータで構成されたデータである。このためサーバは、端末装置からのコンテキスト情報を完全に解釈することができる。これによりサーバは、動的な情報提供（例えば検索結果の並べ替えや絞り込み、又は、広告提供等）を確実に実施することができるようになる。

またこのようなベクトルデータについてサーバ側と端末装置側とで予め規定が設けられている場合、端末装置側におけるコンテキスト情報の生成処理、及び、サーバ側における動的な情報提供処理が容易に実現されるようになる。

またこのようなベクトルデータをサーバと端末装置との間でやり取りするようネットワークシステムを構築することにより、通信データ量を低減させることが可能となる。附言するにやり取りされる情報がコンテキスト情報そのものでない。これは、ユーザのプライバシーを保護するという観点から望ましいと言える。

また端末装置においてコンテキスト情報を生成するために、かな漢字変換処理の履歴、入力フォームへの入力履歴、アドレスバーに対するＵＲＬ又はＩＰアドレスの入力履歴が用いられている。これは、コンテキスト情報を生成するために、例えばメーラやブラウザを始めとする端末装置に実装された種々のアプリケーションにおける履歴を参照することを意味する。ユーザは端末装置に実装された種々のアプリケーションを利用する。このため、各アプリケーションにおける履歴を用いてコンテキスト情報を生成するようにしたことで、より精度の高いコンテキスト情報の提供が実現されるようになる。

以上が本発明の実施の形態である。本発明はこれらの実施形態に限定されるものではなく様々な範囲で変形が可能である。

例えばＨＤＤ１６に蓄積されるコンテキスト情報は、かな漢字変換処理の履歴等に限定されない。例えばブラウザ５０でページを閲覧したとき、当該ページに含まれる単語（テキストデータ）や、ページ、オブジェクト（画像や動画等）にメタデータとして付与されたｔａｇのテキストデータをコンテキスト情報として取得し、それに該当する単語カウンタをインクリメントしても良い。ここでいう「ｔａｇ」とは、オブジェクト等を分類するためのキーワードである。例えばモナリザの画像には「ｔａｇ」として、「モナリザ」、「ダビンチ」、「ルーブル美術館」等のメタデータが付与されている。

またＨＤＤ１６に蓄積されるコンテキスト情報には例えばフォームの選択情報も含まれ得る。「フォームの選択情報」とは、例えば規定事項の入力フォームにおける選択結果である。例えばユーザ情報を入力するフォームにおいて「男」又は「女」の何れかを選択したときの結果である。この選択結果の情報（単語）により単語カウンタをインクリメントしても良い。

本発明の実施の形態のネットワークシステムの構成を示したブロック図である。 本発明の実施の形態の端末装置の構成を示したブロック図である。 本発明の実施の形態のブラウザに含まれるブラウザエンジンの機能ブロック図である。 本発明の実施の形態のサーバの構成を示したブロック図である。 本発明の第一の実施例のネットワークシステムにおいて実行される処理の流れを示した図である。 本発明の第二の実施例のネットワークシステムにおいて実行される処理の流れを示した図である。 本発明の第三の実施例のネットワークシステムにおいて実行される処理の流れを示した図である。 本発明の第四の実施例のネットワークシステムにおいて実行される処理の流れを示した図である。 本発明の第五の実施例のネットワークシステムにおいて実行される処理の流れを示した図である。

符号の説明

１０ａ乃至１０ｎ 端末装置
３、６２ ＣＰＵ
５、６４ ＲＯＭ
７、６６ ＲＡＭ
９、６８ ネットワークインタフェース
１１ ディスプレイドライバ
１３ ディスプレイ
１５ インタフェース
１６、７０ ＨＤＤ
１７ ユーザインタフェースデバイス
３０ ブラウザエンジン
５０ ブラウザ
６０ａ乃至６０ｍ サーバ

Claims (29)

1. 相互通信可能なサーバと端末とを有したシステムにおいて、
   前記端末は、ユーザのコンテキスト情報を収集して保持するコンテキスト情報保持手段と、該保持されたコンテキスト情報に基づいて当該コンテキスト情報に対応した所定の形式のベクトルデータを生成するベクトルデータ生成手段とを具備し、該生成されたベクトルデータを前記サーバに送信し、
   前記サーバは、受信した該ベクトルデータに基づいて該ユーザに提供すべき情報を生成する提供情報生成手段を具備し、該生成された提供情報を前記端末に送信すること、を特徴とするシステム。
2. 該ベクトルデータは前記サーバとのセッション確立をトリガーとして前記サーバに送信されること、を特徴とする請求項１に記載のシステム。
3. 前記サーバは、暫定的なパラメータ値を有する仮ベクトルデータを保持した仮ベクトルデータ保持手段を更に具備し、該保持された仮ベクトルデータを前記端末に送信し、
   前記端末は、前記ベクトルデータ生成手段により生成されたベクトルデータと該受信した仮ベクトルデータとを比較してその差分情報を生成する差分情報生成手段を更に具備し、該生成された差分情報を前記サーバに送信し、
   前記提供情報生成手段は、受信した該差分情報に基づいて該ユーザに提供すべき情報を生成すること、を特徴とする請求項１に記載のシステム。
4. 前記サーバは、受信した該差分情報に基づいて該ベクトルデータを復元するベクトルデータ復元手段を更に具備したこと、を特徴とする請求項３に記載のシステム。
5. 前記仮ベクトルデータ保持手段は、前記端末からの前回のベクトルデータを仮ベクトルデータとして保持したこと、を特徴とする請求項３又は請求項４の何れかに記載のシステム。
6. 前記サーバは、前記端末からの所定のリクエストに呼応して該仮ベクトルデータを当該端末に送信すること、を特徴とする請求項３から請求項５の何れかに記載のシステム。
7. 該ベクトルデータはそれぞれ異なる複数種類の属性の情報から成り、前記ベクトルデータ生成手段は、前記コンテキスト情報保持手段に保持されたコンテキスト情報に基づいて各属性の度合いを算出すること、を特徴とする請求項１から請求項６の何れかに記載のシステム。
8. 前記ベクトルデータ生成手段は、特定の属性に対して、所定期間中に収集されたコンテキスト情報に基づいてその詳細情報を取得してベクトルデータとすること、を特徴とする請求項７に記載のシステム。
9. 前記端末及びサーバは、該ベクトルデータを成す複数種類の属性の組み合わせ情報を複数セット保持したこと、を特徴とする請求項７又は請求項８の何れかに記載のシステム。
10. 前記端末は、該ベクトルデータを前記サーバに送信する際に、当該ベクトルデータが何れのセットであるかを示す情報も送信すること、を特徴とする請求項９に記載のシステム。
11. 前記ベクトルデータ生成手段は、前記サーバのリクエストに応じた組み合わせの属性から成るベクトルデータを生成すること、を特徴とする請求項９又は請求項１０の何れかに記載のシステム。
12. 該ユーザのコンテキスト情報には、かな漢字変換処理の履歴、入力フォームへの入力履歴、アドレスバーに対するＵＲＬ、ＩＰアドレスの入力履歴のうちの少なくとも一つが含まれること、を特徴とする請求項１から請求項１１の何れかに記載のシステム。
13. 前記端末は複数のアプリケーションを具備し、前記コンテキスト情報保持手段は、該複数のアプリケーションから収集可能なコンテキスト情報を保持したこと、を特徴とする請求項１から請求項１２の何れかに記載のシステム。
14. 前記端末は、自己が現在位置する地域情報を取得する現在地域情報取得手段を更に具備し、前記ベクトルデータ生成手段は、該取得された地域情報を含むベクトルデータを生成すること、を特徴とする請求項１から請求項１３の何れかに記載のシステム。
15. 前記現在地域情報取得手段は、地域に関する直近の履歴に基づいて、自己が現在位置する地域情報を取得すること、を特徴とする請求項１４に記載のシステム。
16. 前記端末はＧＰＳレシーバを更に具備し、前記現在地域情報取得手段は、前記ＧＰＳレシーバにより取得された現在位置情報に基づいて、自己が現在位置する地域情報を取得すること、を特徴とする請求項１４に記載のシステム。
17. 前記サーバは検索エンジンを有したサーバであり、前記提供情報生成手段は、前記端末からの検索キーワード及び該ベクトルデータに基づいて検索結果を生成すること、を特徴とする請求項１から請求項１６の何れかに記載のシステム。
18. 前記サーバは、検索結果を得るまでの検索処理の各段階に応じて、それぞれ異なるベクトルデータを前記端末にリクエストすること、を特徴とする請求項１７に記載のシステム。
19. 外部機器と相互通信可能な端末において、
    ユーザのコンテキスト情報を収集して保持するコンテキスト情報保持手段と、
    該保持されたコンテキスト情報に基づいて当該コンテキスト情報に対応した所定の形式のベクトルデータを生成するベクトルデータ生成手段と、を具備し、
    該生成されたベクトルデータを該外部機器に送信すること、を特徴とする端末。
20. 外部機器から送信されるベクトルデータであって、所定のコンテキスト情報をベクトル形式でデータ化したベクトルデータを受信して処理するサーバであって、
    受信した該ベクトルデータに基づいてユーザに提供すべき情報を生成する提供情報生成手段を具備し、
    該生成された提供情報を該外部機器に送信すること、を特徴とするサーバ。
21. 端末に動的な情報を提供するための動的情報提供方法において、
    該端末における、ユーザのコンテキスト情報を収集して保持するコンテキスト情報保持ステップと、
    該保持されたコンテキスト情報に基づいて当該コンテキスト情報に対応した所定の形式のベクトルデータを生成するベクトルデータ生成ステップと、
    該生成されたベクトルデータをサーバに送信するベクトルデータ送信ステップと、
    該サーバにおいて受信された該ベクトルデータに基づいて該ユーザに提供すべき情報を生成する提供情報生成ステップと、
    該生成された提供情報を該端末に送信する提供情報送信ステップと、を含む動的情報提供方法。
22. 前記ベクトルデータ送信ステップは、該端末と該サーバとのセッション確立をトリガーとして実行される、請求項２１に記載の動的情報提供方法。
23. 該サーバにおいて暫定的なパラメータ値を有する仮ベクトルデータを該端末に送信する仮ベクトルデータ送信ステップと、
    該端末において受信された仮ベクトルデータと、前記ベクトルデータ生成ステップで生成されたベクトルデータとを比較してその差分情報を生成する差分情報生成ステップと、
    該生成された差分情報を該サーバに送信する差分情報送信ステップと、を更に含み、
    前記提供情報生成ステップにおいて、受信された該差分情報に基づいて該ユーザに提供すべき情報を生成する、請求項２１に記載の動的情報提供方法。
24. 該端末からの該差分情報に基づいて該ベクトルデータを復元するベクトルデータ復元を更に含む、請求項２３に記載の動的情報提供方法。
25. 前記ベクトルデータ送信ステップは、該端末からの所定のリクエストに呼応して実行される、請求項２３又は請求項２４の何れかに記載の動的情報提供方法。
26. 該ベクトルデータはそれぞれ異なる複数種類の属性の情報から成り、前記ベクトルデータ生成ステップにより、前記コンテキスト情報保持ステップで保持されたコンテキスト情報に基づいて各属性の度合いが算出される、請求項２１から請求項２５の何れかに記載の動的情報提供方法。
27. 該サーバに送信すべきベクトルデータに含まれる属性の組み合わせを当該サーバのリクエストに応じて決定する、請求項２６に記載の動的情報提供方法。
28. 前記端末が現在位置する地域情報を取得する現在地域情報取得ステップを更に含み、前記ベクトルデータ生成ステップにより、該取得された地域情報を含むベクトルデータが生成される、請求項２１から請求項２７の何れかに記載の動的情報提供方法。
29. 前記現在地域情報取得ステップにおいて、地域に関する直近の履歴に基づいて、該端末が現在位置する地域情報が取得される、請求項２８に記載の動的情報提供方法。

Images