本発明は、サーバが端末に対して動的な情報を提供するシステムに関する。またこのようなシステムに好適な端末及びサーバに関する。また端末に動的な情報を提供するための動的情報提供方法に関する。
端末装置に実装された情報閲覧ソフトウェア(以下、ブラウザと記す)を用いてWebサーバにアクセスすることで、ユーザは、当該サーバにより提供されるサービスを受けることができる。近年、インターネットに代表されるネットワークの急速な普及やその技術の発展に伴って、ユーザは様々なサービスを受けることができるようになった。その一つに、例えばユーザ個々の嗜好に合わせた広告やコンテンツ等を端末装置に配信するサービスが挙げられる。
例えば下記特許文献1には、ユーザが閲覧したサイトやその検索履歴等を収集・分析してユーザ個々の嗜好に合わせた広告やコンテンツ等を端末装置に配信するサービスが開示されている。下記特許文献1に記載のシステムにおいては、端末装置がドメイン名及びユーザIDをサーバに送信する。次いで、サーバがそれらの情報に基づいて収集・分析処理等を実行する。そしてその処理結果を反映させた適切な広告を端末装置に配信する。これにより、ユーザ個々の嗜好に合致した広告等の配信が実現される。
また下記特許文献2にも、ユーザ個々の嗜好に合わせた広告やコンテンツ等を端末装置に配信するサービスが開示されている。下記特許文献2に記載のシステムにおいては、ユーザが閲覧したサイトの履歴情報が端末装置によりサーバに送信される。次いで、サーバが、その受け取った情報に基づいてユーザの情報収集の目的をベクトル形式でデータ化する。そしてそのベクトル化された情報に基づいて適切な広告を端末装置に配信する。これにより、先に説明された特許文献1と同様に、ユーザ個々の嗜好に合致した広告等の配信が実現される。
特表2006−506707号公報
特開2004−102996号公報
上述したように上記特許文献1及び2においては、サーバが、ユーザのコンテキスト情報を受け取り、その情報を用いて分析処理等を実行し、その処理結果を当該ユーザの嗜好に合わせた情報として端末装置に提供している。しかし、これら特許文献1及び2に記載のシステムでは以下に挙げられる問題が内在している。
(1)不特定多数の端末装置からサーバに対してコンテキスト情報が送信される。このためサーバと端末装置との間でやり取りされるコンテキスト情報には統一性がない。従って、例えばサーバ側で解釈できないコンテキスト情報が端末装置から送信されることもある。この場合、サーバが端末装置に対して適切な情報を提供することは極めて困難である。
(2)端末装置からサーバに送信されるコンテキスト情報によってはデータ量の多いものも存在する。データ量の多いコンテキスト情報の送受信は、トラフィックを増大させる要因の一つになり得るため望ましくない。
(3)コンテキスト情報そのものを送受信することは、ユーザのプライバシー保護の観点から望ましくない。
そこで、本発明は上記の事情に鑑みて、上記問題を解消し且つユーザ個々の嗜好に合わせた情報を端末装置に配信するのに好適なシステム及び動的情報提供方法を提供することを課題としている。またそのようなシステムに好適な端末及びサーバを提供することも課題としている。
上記の課題を解決する本発明の一態様に係るシステムは、相互通信可能なサーバと端末とを有したシステムである。このシステムの端末は、ユーザのコンテキスト情報を収集して保持するコンテキスト情報保持手段と、該保持されたコンテキスト情報に基づいて当該コンテキスト情報に対応した所定の形式のベクトルデータを生成するベクトルデータ生成手段とを具備する。そして、ベクトルデータ生成手段により生成されたベクトルデータをサーバに送信する。またサーバは、受信した該ベクトルデータに基づいて該ユーザに提供すべき情報を生成する提供情報生成手段を具備する。そして、提供情報生成手段により生成された提供情報を端末に送信する。
このような構成によれば、端末からサーバに送信されるコンテキスト情報は所定の形式のベクトルデータである。この所定の形式は、サーバの提供情報生成手段で解釈可能な形式である。このように、サーバと端末との間においてコンテキスト情報を所定の形式でやり取りするよう構成することで、サーバは、端末に対する情報提供を確実に実行することができるようになる。またやり取りされるデータがベクトル形式であるため、通信データ量を低減させるという効果も奏する。また更に、やり取りされるデータがコンテキスト情報そのものでない。これは、ユーザのプライバシーを保護するという観点から望ましいと言える。
なお上記システムにおいて、該ベクトルデータはサーバとのセッション確立をトリガーとしてサーバに送信されても良い。
また上記システムにおいてサーバは、例えば暫定的なパラメータ値を有する仮ベクトルデータを保持した仮ベクトルデータ保持手段を更に具備したものであっても良い。この場合サーバは、該保持された仮ベクトルデータを端末に送信するよう動作する。また端末は、例えばベクトルデータ生成手段により生成されたベクトルデータと該受信した仮ベクトルデータとを比較してその差分情報を生成する差分情報生成手段を更に具備したものであっても良い。この場合端末は、該生成された差分情報をサーバに送信するよう動作する。そして提供情報生成手段は、受信した該差分情報に基づいて該ユーザに提供すべき情報を生成するよう動作する。
また上記システムにおいてサーバは、例えば受信した該差分情報に基づいて該ベクトルデータを復元するベクトルデータ復元手段を更に具備したものであっても良い。
この仮ベクトルデータ保持手段は、例えば端末からの前回のベクトルデータを仮ベクトルデータとして保持することができる。
上記サーバは、端末からの所定のリクエストに呼応して該仮ベクトルデータを当該端末に送信するよう動作し得る。
また上記システムにおいて、該ベクトルデータはそれぞれ異なる複数種類の属性の情報から成る。この場合、ベクトルデータ生成手段は、例えばコンテキスト情報保持手段に保持されたコンテキスト情報に基づいて各属性の度合いを算出するよう動作する。
ここで、ベクトルデータ生成手段は、特定の属性に対して、所定期間中に収集されたコンテキスト情報に基づいてその詳細情報を取得してベクトルデータとすることができる。
また端末及びサーバは、該ベクトルデータを成す複数種類の属性の組み合わせ情報を複数セット保持したものであっても良い。
この場合、端末は、例えば該ベクトルデータをサーバに送信する際に当該ベクトルデータが何れのセットであるかを示す情報も送信するよう動作する。
またこの場合、ベクトルデータ生成手段は、例えばサーバのリクエストに応じた組み合わせの属性から成るベクトルデータを生成するよう動作する。
上記システムにおいて、該ユーザのコンテキスト情報には、例えばかな漢字変換処理の履歴、入力フォームへの入力履歴、アドレスバーに対するURL、IPアドレスの入力履歴のうちの少なくとも一つが含まれ得る。
上記システムにおいて、端末は例えば複数のアプリケーションを具備したものであっても良い。このような端末のコンテキスト情報保持手段は、該複数のアプリケーションから収集可能なコンテキスト情報を保持するよう動作する。
上記システムにおいて、端末は、例えば自己が現在位置する地域情報を取得する現在地域情報取得手段を更に具備したものであっても良い。この場合ベクトルデータ生成手段は、例えば該取得された地域情報を含むベクトルデータを生成するよう動作する。
この現在地域情報取得手段は、例えば地域に関する直近の履歴に基づいて、自己が現在位置する地域情報を取得するよう動作する。
上記システムにおいて、端末は例えばGPSレシーバを更に具備したものであっても良い。この場合、現在地域情報取得手段は、GPSレシーバにより取得された現在位置情報に基づいて、自己が現在位置する地域情報を取得するよう動作する。
上記システムにおいて、サーバは例えば検索エンジンを有したサーバである。この場合、提供情報生成手段は、端末からの検索キーワード及び該ベクトルデータに基づいて検索結果を生成するよう動作する。
上記システムにおいて、サーバは、例えば検索結果を得るまでの検索処理の各段階に応じて、それぞれ異なるベクトルデータを端末にリクエストすることができる。
また上記の課題を解決する本発明の一態様に係る外部機器と相互通信可能な端末は、ユーザのコンテキスト情報を収集して保持するコンテキスト情報保持手段と、該保持されたコンテキスト情報に基づいて当該コンテキスト情報に対応した所定の形式のベクトルデータを生成するベクトルデータ生成手段とを具備し、該生成されたベクトルデータを該外部機器に送信することを特徴としたものである。
また上記の課題を解決する本発明の一態様に係るサーバは、外部機器から送信されるベクトルデータであって、所定のコンテキスト情報をベクトル形式でデータ化したベクトルデータを受信して処理するサーバである。このサーバは、受信した該ベクトルデータに基づいてユーザに提供すべき情報を生成する提供情報生成手段を具備し、該生成された提供情報を該外部機器に送信することを特徴としたものである。
また上記の課題を解決する本発明の一態様に係る動的情報提供方法は、端末に動的な情報を提供するための方法である。この動的情報提供方法は、該端末におけるユーザのコンテキスト情報を収集して保持するコンテキスト情報保持ステップと、該保持されたコンテキスト情報に基づいて当該コンテキスト情報に対応した所定の形式のベクトルデータを生成するベクトルデータ生成ステップと、該生成されたベクトルデータをサーバに送信するベクトルデータ送信ステップと、該サーバにおいて受信された該ベクトルデータに基づいて該ユーザに提供すべき情報を生成する提供情報生成ステップと、該生成された提供情報を該端末に送信する提供情報送信ステップとを含む。
このベクトルデータ送信ステップは、例えば該端末と該サーバとのセッション確立をトリガーとして実行される。
なお上記動的情報提供方法には、該サーバにおいて暫定的なパラメータ値を有する仮ベクトルデータを該端末に送信する仮ベクトルデータ送信ステップと、該端末において受信された仮ベクトルデータと、ベクトルデータ生成ステップで生成されたベクトルデータとを比較してその差分情報を生成する差分情報生成ステップと、該生成された差分情報を該サーバに送信する差分情報送信ステップとを更に含んだものも想定される。このような方法の提供情報生成ステップにおいては、受信された該差分情報に基づいて該ユーザに提供すべき情報が生成される。
上記動的情報提供方法には、例えば該端末からの該差分情報に基づいて該ベクトルデータを復元するベクトルデータ復元が更に含まれるものもある。
上記ベクトルデータ送信ステップは、例えば該端末からの所定のリクエストに呼応して実行される。
上記動的情報提供方法において、該ベクトルデータは例えばそれぞれ異なる複数種類の属性の情報から成るものである。このような場合ベクトルデータ生成ステップにより、コンテキスト情報保持ステップで保持されたコンテキスト情報に基づいて各属性の度合いが算出され得る。
上記動的情報提供方法においては、該サーバに送信すべきベクトルデータに含まれる属性の組み合わせが例えば当該サーバのリクエストに応じて決定される。
上記動的情報提供方法は、例えば端末が現在位置する地域情報を取得する現在地域情報取得ステップを更に含んだものであり得る。このような場合ベクトルデータ生成ステップにより、該取得された地域情報を含むベクトルデータが生成され得る。
また上記現在地域情報取得ステップにおいて、例えば地域に関する直近の履歴に基づいて、該端末が現在位置する地域情報が取得され得る。
本発明に係るシステム及び動的情報提供方法によれば、端末からサーバに送信されるコンテキスト情報は所定の形式のベクトルデータである。この所定の形式は、サーバの提供情報生成手段で解釈可能な形式である。このように、サーバと端末との間においてコンテキスト情報を所定の形式でやり取りするよう構成することで、サーバは、端末に対する情報提供を確実に実行することができるようになる。またやり取りされるデータがベクトル形式であるため、通信データ量を低減させるという効果も奏する。また更に、やり取りされるデータがコンテキスト情報そのものでない。これは、ユーザのプライバシーを保護するという観点から望ましいと言える。
以下、図面を参照して、本発明の実施の形態について説明する。
図1は、本発明の実施の形態のネットワークシステムの構成を示したブロック図である。本実施形態のネットワークシステムは、例えば複数台の端末装置10a乃至10n、及び、複数台のサーバ60a乃至60mで構築されている。各端末装置と各サーバは、例えばインターネットに代表される所定のネットワークを介して相互に接続される。
なお端末装置10a乃至10nは例えば所有者がそれぞれ異なるだけであり、構成としては実質的に同一であるものとする。またサーバ60a乃至60mも例えば配信するコンテンツや広告等が異なるだけであり、構成としては実質的に同一であるものとする。以下、説明の重複を避けるため、端末装置10a及びサーバ60aの説明をもって、他の端末装置及びサーバ(すなわち端末装置10b乃至10n及びサーバ60b乃至60m)についての説明を省略する。
図2は、本発明の実施の形態の端末装置10aの構成を示したブロック図である。本実施形態の端末装置10aとしては、例えばデスクトップやラップトップ等のPC(Personal Computer)や、携帯電話、PDA(Personal Digital Assistance)或いはPHS(Personal Handy phone System)等の種々の形態のものが想定される。
図2に示されるように、端末装置10aはその全体を統括的に制御するCPU3を具備する。CPU3にはバス19を介して各構成要素が接続されている。これらの構成要素には、ROM(Read-Only Memory)5、RAM(Random-Access Memory)7、ネットワークインタフェース9、ディスプレイドライバ11、インタフェース15、HDD(Hard Disk Drive)16がある。ディスプレイドライバ11、インタフェース15はそれぞれ、ディスプレイ13、ユーザインタフェースデバイス17に接続されている。
ROM5には各種プログラムや各種データが格納されている。ROM5に格納されているプログラムには例えばブラウザ50がある。このブラウザ50は、所定のマークアップ言語で記述されたオンライン又はオフライン上の情報を閲覧するための情報閲覧ソフトウェアである。
RAM7は例えばROM5に格納されている各種プログラムの展開先である。ユーザインタフェースデバイス17を用いたユーザ・オペレーション(以下、単に「ユーザ・オペレーション」と記す)にしたがって、ROM5に格納されているプログラム(例えばブラウザ50)が読み出されてRAM7の所定領域に展開されて実行される。これにより、ブラウザ50が起動する。
ここで、ブラウザ50の機能について説明する。図3を参照してブラウザ50の基本的な構成要素であるブラウザエンジン30について説明する。
図3は、ブラウザ50に含まれるブラウザエンジン30の機能ブロック図である。図3に示されるように、ブラウザエンジン30は、パーサー31、ページメーカ32、およびフォーマッタ33の各機能ブロックから構成される。
ユーザ・オペレーションによりURI(Uniform Resource Identifier)を入力、或いはディスプレイ13に表示中のページに含まれるURIをアンカータグの一つを選択することにより指定すると、ブラウザ50は、インターネット上のURI(例えばサーバ60a)からHTML(Hyper Text Markup Language)文書21(すなわちリクエストされたページ)を取得するよう動作する。
なお上記「ページ」とは、クライアント(ここではブラウザ50)がサーバからネットワーク経由で取得するデータのまとまりであり、ユーザがあるURIを指定したときに表示されるべき内容全体を指す。ページは例えばHTML形式で記述されたものであり、テキストデータ、画像ファイル、音声データ等の種々のデータで構成される。
ここで、図4に、本発明の実施の形態のサーバ60aの構成をブロック図で示す。サーバ60aはその全体を統括的に制御するCPU62を具備する。CPU62にはバス72を介して各構成要素が接続されている。これらの構成要素には、CPU62、ROM64、RAM66、ネットワークインタフェース68、HDD70がある。
ROM64には、クライアント(ここでは端末装置10a乃至10n)からのリクエストに応じた処理を実行するための種々のプログラムやデータが格納されている。これらのプログラムはサーバ60aが起動している限り、例えばRAM66に展開されて常駐した状態にある。すなわちサーバ60aはクライアントからのリクエストの有無を常に監視した状態にある。そして、リクエストがあればそれに対する処理を直ぐさま実行することができる。
サーバ60aは、HTML文書21を始めとする種々のページから成るコンテンツをHDD70に格納している。CPU62は、所定のネットワーク及びネットワークインタフェース68を介して端末装置10aからの上記リクエストを受け取ると、その指定されたURIに応じたページ(すなわちHTML文書21)をHDD70から読み出す。次いで、その読み出されたHTML文書21をネットワークインタフェース68及び所定のネットワークを介して端末装置10aに送信する。
サーバ60aから送出されたHTML文書21は、所定のネットワーク及びネットワークインタフェース9を介して次にパーサー31に渡される。
パーサー31は、このHTML文書21を解釈し、HTML文書21の文法構造がツリー構造で表されたドキュメントツリー23を作成する。なお、ドキュメントツリー23は、HTML文書21の文法構造を表現するのみであり、ドキュメントの表現に関する情報までは含んでいない。
次に、ページメーカ32は、ドキュメントツリー23及びタグに関する情報を基に、HTML文書21の表現形式、例えばblock, inline, table, list, item等を含むレイアウトツリー25を作る。すなわち、レイアウトツリー25は、block, inline, tableなどの順番に関する情報を含んでいる。なお、レイアウトツリー25は、これらの要素(block, inline, table等)の画面上での位置やサイズについての情報は含んでいない。
フォーマッタ33は、レイアウトツリー25とディスプレイ13の画面サイズに関する情報を基に、ディスプレイ13の画面上に各項目をレイアウトする。つまり、フォーマッタ33は、ディスプレイ13の画面上に項目を配置し、各項目の画面上の位置、幅、高さや、HTML文書21内の文字の折り返し位置を決定する。
パーサー31、ページメーカ32、フォーマッタ33による以上のような処理を経て、HTML文書21、すなわちリクエストされたページがディスプレイ13に表示される。
次いで、ROM5に格納されているプログラムについての更なる説明を行う。ROM5には、ユーザベクトルUを算出するためのユーザベクトル算出プログラムが格納されている。このユーザベクトル算出プログラムは、サーバ側と連携するよう機能して、ユーザに対する動的な情報提供を実現することができる。なおこのユーザベクトル算出プログラムは、端末装置10aがサーバ60a等からダウンロードしてその後実装されたプログラムであっても良く、或いは、端末装置10aに予め実装されたプログラムであっても良い。
ユーザベクトル算出プログラムで算出される「ユーザベクトルU」とは、ユーザのコンテキスト情報を例えば128種類の属性に分類し、それらの各属性をベクトル化したデータである。すなわちユーザベクトルUは、128次元のベクトルデータ(u1、u2、・・・、u128)である。ユーザベクトルUを成す128種類の属性には、例えば「男性」、「都内」、「ビジネスマン」、「サッカー」、「日本酒」、「読書」、「TV」、「PC」、「社交的」、「健康志向」等がある。なお本実施形態におけるコンテキスト情報には、ユーザの嗜好や生活習慣、プロフィール(氏名や出身地)等が含まれる。
128種類の属性をセットとしたデータ(以下、「属性データ」と記す)は例えばHDD16に格納されている。附言するにHDD16には、それぞれ異なる組み合わせの属性で構成された属性データが例えば100セット格納されている。
HDD16には、ユーザ・オペレーションに応じたかな漢字入力を受け付けるためのかな漢字変換辞書が格納されている。かな漢字変換辞書に収録されている各単語には、何れの属性に該当するかを示す情報(以下、「単語属性情報」と記す)が関連付けて記録されている。かな漢字変換辞書において、例えば「東京」という単語のデータには「都内」の属性に該当することを示すフラグが立てられている。一方で「都内」以外の他の属性に対してはフラグが立てられていない。このようなデータ(すなわち単語属性情報)の追加に必要な容量は、例えばかな漢字変換辞書が6万語を収録したものである場合には100Kバイト程度である。従ってこのような単語属性情報は、記録媒体の容量が比較的限定的な端末装置(例えば携帯電話等の携帯端末)においても十分に実装可能である。
またHDD16には、URLと所定のキーワードを関連付けて記憶したURL辞書も格納されている。URL辞書に登録されている各ドメイン名には、何れの属性に該当するかを示す情報(以下、「ドメイン属性情報」と記す)が関連付けて記録されている。URL辞書において、例えば「www.○○○○○book.co.jp」というドメイン名のデータには「読書」の属性に該当することを示すフラグが立てられている。一方で「読書」以外の他の属性に対してはフラグが立てられていない。なおURL辞書に登録されているドメイン名の数が多い場合、例えば64ビットのハッシュテーブルを利用してドメイン属性情報の容量を圧縮するよう構成しても良い。
またHDD16には、IPアドレスと所定のキーワードを関連付けて記憶したIPアドレス辞書も格納されている。IPアドレス辞書に登録されている各IPアドレスには、何れの属性に該当するかを示す情報(以下、「IPアドレス属性情報」と記す)が関連付けて記録されている。IPアドレス辞書において、例えば「211.10.36.43」というIPアドレスのデータには「TV」の属性に該当することを示すフラグが立てられている。一方で「TV」以外の他の属性に対してはフラグが立てられていない。なおIPアドレス辞書に登録されているドメイン名の数が多い場合も、URL辞書の例と同様に、例えば64ビットのハッシュテーブルを利用してIPアドレス属性情報の容量を圧縮するよう構成しても良い。
一単語(又は一URL、一IPアドレス)に対して、上記例では該当する属性を一つとしているが、別の例では複数の属性に該当するようにしても良い。このような場合、例えばかな漢字変換辞書において「東京」という単語のデータに「都内」、「サッカー」、「ビジネスマン」等の複数の属性に対してフラグが立てられている。
128種類の属性の各々は、その「確からしさ」が例えば0%、25%、50%、75%の4段階(すなわち2ビット)で表される。「確からしさ」は例えばユーザの嗜好を段階的に示したものである。すなわち128種類の属性がユーザベクトルUの方向を示すのに対して、「確からしさ」はユーザベクトルUの大きさを示す。このユーザベクトルUによりユーザの嗜好等がベクトルで示される。
具体的には、例えばユーザベクトル算出プログラムによりユーザがサッカーに非常に興味を持っていると判断されたとき、「サッカー」の属性の「確からしさ」が75%と算出される。一方、ユーザがサッカーに全く興味を持っていないと判断されたとき、「サッカー」の属性の「確からしさ」が例えば0%と算出される。なお「確からしさ」に関する設定は、端末装置とサーバとの間で予め合意されたものであれば如何なるものであっても良い。例えば「確からしさ」の数値を上記のものに限らず、それぞれ、10%、30%、60%、90%等に設定しても良い。また「確からしさ」の段階を2ビットでなく3ビット(すなわち8段階)で表すよう設定しても良い。
各属性の「確からしさ」の段階は、HDD16に蓄積されるコンテキスト情報に基づいて決定される。HDD16にはコンテキスト情報として、例えば「かな漢字変換パターン」、「フォームテキスト」、「URLアドレスパターン」、「IPアドレスパターン」が蓄積される。
「かな漢字変換パターン」は、ユーザ・オペレーションによるかな漢字変換処理の履歴である。ここで、RAM7には、かな漢字変換辞書の各単語に対して関連付けをされたカウンタ(以下、「単語カウンタ」と記す)が保持されている。端末装置10aを用いた文書作成等において、かな漢字変換により例えば「社交的」という単語が入力された場合、かな漢字変換辞書の「社交的」という単語に関連付けられた単語カウンタが1インクリメントされる。すなわち端末装置10aにおいて、かな漢字変換処理された何らかの単語が入力される度に、当該単語に関連付けられた単語カウンタがインクリメント処理される。
「フォームテキスト」は、例えばページに含まれる入力フォームへの入力履歴である。なおここでいう入力フォームとは、例えばHTML文書において<form>〜</form>で記述された部分の解釈結果をレンダリングしたものである。ブラウザ50上でレンダリングされた入力フォームにユーザ・オペレーションによりキーワードが入力されると、その入力キーワードが「フォームテキスト」としてHDD16に蓄積される。更に、かな漢字変換辞書においてその入力キーワードに一致する単語に関連付けられた単語カウンタが1インクリメントされる。但し、その入力キーワードがかな漢字変換辞書に含まれないものである場合、何れの単語カウンタもインクリメントされない。
「URLアドレスパターン」は、ブラウザ50のアドレスバーに対するURLの入力履歴である。ここで、RAM7には、URL辞書の各URLに対して関連付けをされたカウンタ(以下、「URLカウンタ」と記す)が保持されている。ユーザ・オペレーションによりアドレスバーにURLが入力されると、その入力URLに関連付けられたURLカウンタが1インクリメントされる。なおその入力URLがURL辞書に含まれないものである場合、何れのURLカウンタもインクリメントされない。
「IPアドレスパターン」は、ブラウザ50のアドレスバーに対するIPアドレスの入力履歴である。ここで、RAM7には、IPアドレス辞書の各IPアドレスに対して関連付けをされたカウンタ(以下、「IPカウンタ」と記す)が保持されている。ユーザ・オペレーションによりアドレスバーにIPアドレスが入力されると、その入力IPアドレスに関連付けられたIPカウンタが1インクリメントされる。なおその入力IPアドレスがIPアドレス辞書に含まれないものである場合、何れのIPカウンタもインクリメントされない。
ここで、「入力」には文字列の入力によるものだけに限らず、ユーザの選択(選択肢の選択結果、URLのクリック、コピー&ペースト等)による入力も含まれる。
なお端末装置10aにおいて、各辞書の全ての単語、URL、IPアドレスに関連付けられた単語カウンタ、URLカウンタ、IPカウンタのカウント値の総数(以下、「総数カウント値」と記す)も別途カウントされている。
端末装置10aは、各辞書のフラグ(すなわち各単語、URL、IPアドレスが何れの属性であるかを示す情報)と各カウンタのカウント値に基づいて、属性データに含まれる各属性の「確からしさ」の段階を決定する。
より詳細には端末装置10aは、属性データに含まれる属性それぞれに対して以下の処理を行ってその「確からしさ」の段階を決定する。
(1)各辞書の全ての単語、URL、IPアドレスを検索し、処理対象の属性についてフラグが立てられているものを抽出する。
(2)(1)で抽出された単語、URL、IPアドレスに関連付けられた単語カウンタ、URLカウンタ、IPカウンタのカウント値を検索し、最も高いカウント値を抽出する。
(3)(2)で抽出されたカウント値を総数カウント値で割り、利用頻度確率を算出する。
ここで、HDD16には、各属性と、「確からしさ」に関する閾値とを関連付けた閾値テーブルが蓄積されている。この閾値テーブルの各レコードには、属性それぞれについて、それぞれ異なる三つの閾値n1、n2、n3(n1<n2<n3)が関連付けられてエントリされている。これらの閾値は、「確からしさ」を表す2ビットの値(すなわち0乃至3)が何%の利用頻度確率で切り替わるかを決定するための値である。端末装置10aは上記(3)の処理に次いで、下記(4)の処理を行う。
(4)検索対象の属性の「確からしさ」を表す2ビットの値を、閾値テーブルを参照して利用頻度確率に基づき算出する。
具体的には、上記(3)の処理で算出された利用頻度確率がn1%より低い場合、「確からしさ」を表す2ビットの値は「0」とされる。また、利用頻度確率がn1%以上で且つn2%より低い場合、上記2ビットの値は「1」とされる。また利用頻度確率がn2%以上で且つn3%より低い場合、上記2ビットの値は「2」とされる。また、利用頻度確率がn3%以上である場合、上記2ビットの値は「3」とされる。上記(4)の処理により、ユーザベクトルU(u1、u2、・・・、u128)は例えば(0、3、・・・、2)等の値とされる。
以上説明したように属性データに含まれる各属性について上記(1)乃至(4)の処理が実行されると、128種類の属性の各々についてその「確からしさ」を2ビットで表したデータ、すなわちユーザベクトルUが算出される。
なお利用頻度確率の算出には別の方法を採用しても良い。例えば上記(2)で検索された全てのカウント値の合計を総数カウント値で割り、利用頻度確率を算出する方法が挙げられる。
また上記(2)で検索された全てのカウント値の各々に対して重み付け処理を行い、利用頻度確率を算出しても良い。例えば上記(2)で検索されたカウント値それぞれについて、その値が大きいものから順にウェイトの高い重み付け係数を乗算する。具体的には、カウント値の大きいものから順に例えば1、0.9、0.81、0.729・・・(以下、前出の値に0.9を乗じた値)の重み付け係数を乗算する。次いで、それらの乗算結果を加算してその総和を算出する。そしてその総和を総数カウント値で割り、利用頻度確率を算出する。
なお閾値テーブルの各レコードにエントリされるべき各閾値は、利用頻度確率の算出方法に応じて適宜設定する必要がある。
次に、本実施形態のネットワークシステムにおいて端末装置10aとサーバ60aとの間でやり取りされる処理について具体的に説明する。
図5に、本発明の第一の実施例において端末装置10aとサーバ60aとの間でやり取りされる処理の流れを示す。
本実施例1においては、先ず、端末装置10aとサーバ60aとのセッションが確立されると、端末装置10aがサーバ60aにユーザベクトルUを送信する(ステップ1、以下の明細書及び図面においてステップを「S」と略記)。ここでいうセッションとは、ブラウザ50によるサーバへのアクセスから、情報のリクエスト及びそれに対するレスポンス、切断までを一単位としたものである。従って上記セッションの確立は、例えばユーザ・オペレーションによりブラウザ50のアドレスバーにURLが入力されたことで果たされる。つまりS11の処理において端末装置10aは、URLで指定したページのリクエストと共にユーザベクトルUを送信する。
附言するにS11の処理では、ユーザベクトルUが、例えばセッションの確立と同時にユーザベクトル算出プログラムにより算出されてページのリクエストと共に送信される。しかし、端末装置の性能によってはユーザベクトルUの算出処理に時間が掛かることも想定される。このような場合、URLが入力された時点では、送信処理において例えばページのリクエストのみを送信し、それと並行してユーザベクトル算出処理を行う。そしてユーザベクトルUが算出された時点で入力URL宛に当該ユーザベクトルUを送信する。これにより、ブラウザ50においてスムーズなページ・ブラウジングが実現される。
また端末装置10aがユーザベクトル算出プログラムを定期的に実行させて比較的新しいユーザベクトルUをRAM7等で常に保持しておくようにしても良い。この場合、S11の処理で送信されるユーザベクトルUはRAM7等に予め保持されたものとなる。このためセッション確立時にユーザベクトルUを算出する必要がない。このような場合もブラウザ50におけるスムーズなページ・ブラウジングが実現されるようになる。
なおS11の処理で送信されるユーザベクトルUは、HDD16に格納された100セットの属性データのうち、予め設定されている1セットの属性データを用いて算出されたものである。本実施例1では、ユーザベクトル算出処理に用いられる属性データが、例えばアクセス先に拘わらず常に同一となるように設定されている。一方、別の実施例では、ユーザベクトル算出処理に用いられる属性データが例えばアクセス先によって変わるように設定されていても良い。
サーバ60aのHDD70にも、端末装置10aが保持する100セットの属性データと同一のデータが格納されている。S11の処理において端末装置10aはページのリクエスト等と共に、例えば何れのセットの属性データを用いてユーザベクトルUを算出したかを報知する情報も送信することができる。この情報により、サーバ60aはユーザベクトルUに含まれる各属性を詳細に知ることができる。
サーバ60aは、ページのリクエスト及びユーザベクトルUを受信するとその旨を報知する確認通知を端末装置10aに送信する。そしてレスポンス(すなわちページ)を端末装置10aに送信する(S12)。HDD70には、ユーザベクトルUとその送信元とを関連付けたユーザ情報データベースが蓄積されている。サーバ60aは、受信したユーザベクトルUを、その送信元に関連付けてユーザ情報データベースに蓄積する。
端末装置10aがS12の処理で送信されたページを受け取ると、ブラウザ50が当該ページを解釈してレンダリングする。ここで、サーバ60aは例えば検索エンジンを提供する端末である。従ってブラウザ50上には、サーバ60aにより提供される検索エンジンが表示されることになる。ユーザ・オペレーションによりこの検索エンジンの入力フォームに検索キーワードが入力されると、ブラウザ50は、その検索キーワードを含むURLをサーバ60aに送信する(S13)。
サーバ60aはS13の処理で送信されたURLを受け取ると、自己に実装されたCGI(Common Gateway Interface)プログラムを起動させて周知の検索処理を行う。
ここで、サーバ60aのHDD70には、検索処理で検索された各サイトに対する検索キーワードの当てはまり度を算出するための式が保持されている。この式は例えば、
k=v0+v1u1+v2u2+v3u3+・・・+vjuj・・・(1)
で表される。「v0」は所定の初期値であり、端末装置10aから送信されるユーザベクトルUに依存しない値である。「v1」乃至「vj」は所定の係数であり、例えばパイロットユーザから収集したコンテキスト情報等に基づいてその値が決定される。これら「v1」乃至「vj」は正負何れの値をとることもできる。「u1」乃至「uj」の各々はユーザベクトルUの各属性に対応した変数である。なおjは例えば128である。
HDD70には、上記式(1)に代入すべき初期値v0と係数v1乃至vjの組み合わせが複数パターン保持されている。サーバ60aは例えば検索キーワードやユーザベクトルUに含まれる属性の内容に応じて、適切な上記組み合わせをHDD70より抽出する。そして上記検索処理で検索された各サイトに対する当てはまり度kを算出する。例えば抽出された組み合わせ内容が「初期値v0=0.76、係数(v1、v2、v3、・・・vj)=(0.02、0.04、−0.03、・・・0.12)」であるとき、上記式(1)は、
k=0.76+0.02u1+0.04u2−0.03u3・・・+0.12uj
となる。
検索されたサイトがユーザの嗜好等に合ったものである場合、当該サイトに対する当てはまり度kは上記式(1)による算出の結果、比較的高い確率で初期値V0よりも高い値になる。これに対して検索されたサイトがユーザの嗜好等に合ったものでない場合、当該サイトに対する当てはまり度kは上記式(1)による算出の結果、比較的高い確率で初期値V0よりも低い値になる。つまり、サイトの嗜好等がユーザに合ったものであればあるほど当てはまり度kも高い値となる。
上述したように「確からしさ」に関する設定は、端末装置とサーバとの間で予め合意されている。従ってサーバ60aは、この設定に基づいてユーザベクトルUの各値を変換する。具体的にはユーザベクトルUが例えば(0、1、3、2、・・・)であるとき、(0、0.25、0.75、0.5、・・・)に変換される。これら変換後の各値が上記式(1)の「u1」乃至「uj」の各々に代入されて当てはまり度kが算出される。
次いでサーバ60aは、上記検索処理で検索された各サイトに対する当てはまり度kに基づいて、その検索結果に対する並べ替え処理を実行する。具体的には、当てはまり度kが高いサイトほど上位となるように並び替え処理を実行する。すなわちこの処理により、ユーザベクトルUが示すユーザの嗜好等に合うサイト等が検索の上位に位置するように検索結果が並べ替えられる。サーバ60aは、この並べ替えられた検索結果のページを端末装置10aに送信する(S14)。
端末装置10aがS14の処理で送信された検索結果のページを受け取ると、ブラウザ50において、ユーザの嗜好等に合ったサイトが検索の上位に位置する検索結果がレンダリングされる。つまり本実施例1によれば、ユーザは、その嗜好等が加味された動的な検索結果を得ることができる。
なおサーバ60aは上記並べ替え処理の代替として、検索結果に対する絞り込み処理を実行することもできる。この場合サーバ60aは、上記検索処理で検索された各サイトに対する当てはまり度kを参照して、当該当てはまり度kが所定の閾値以下であるサイトを検索結果から除外する。換言すると、その当てはまり度kが所定の閾値より高いサイトだけを残すよう検索結果を絞り込む。この処理により、ユーザベクトルUが示すユーザの嗜好等に合うサイトだけが検索結果として残る。この場合もユーザは先と同様に、その嗜好等が加味された動的な検索結果を得ることができる。
またサーバ60aは上記並べ替え処理の代替として、初期値V0と当てはまり度kとの差が大きいサイトを上位に並べる、或いはハイライト表示させることもできる。
附言するに、検索エンジンを提供するサーバには広告収入等で運営されているものが多い。サーバ60aは、例えば端末装置10aからのユーザベクトルUに基づいてそのユーザの嗜好等に合った広告(例えば広告画像や広告キーワード、そのリンク等)を取得するよう動作することもできる。そしてこの場合、取得された広告を検索結果のページに含めて端末装置10aに送信する。これによりブラウザ50において、検索結果に加えて上記広告もレンダリングされる。このような形態によればそれぞれに対してメリットが享受される。すなわちユーザにはその嗜好等に合った広告が提供される。また広告業者には、各ユーザに対して適切な広告を提供し宣伝効果等を向上させることができる。またサーバには、広告業者から広告収入を得ることができる。
図6に、本発明の第二の実施例において端末装置10aとサーバ60aとの間でやり取りされる処理の流れを示す。
図6に示される処理は、例えば端末装置10aがサーバ60aに対してページのリクエスト等を行った(或いはセッションが確立した)時点で開始される。サーバ60aは、上記リクエストに呼応して仮ユーザベクトルU’を端末装置10aに送信する(S21)。ここで送信される仮ユーザベクトルU’は、例えばユーザ情報データベースにおいて端末装置10aと関連付けされたユーザベクトルU(すなわち端末装置10aが前回送信したユーザベクトル)そのものである。なお、ユーザ情報データベースに端末装置10aのユーザベクトルUが蓄積されていない場合には、例えば適当な仮ユーザベクトルU’を暫定的に生成して端末装置10aに送信する。
端末装置10aは、仮ユーザベクトルU’を受信するとその差分データを生成する。説明を加えると、端末装置10aは仮ユーザベクトルU’の受信をトリガーとしてユーザベクトル算出プログラムを起動させる。そしてユーザベクトルUを算出する。次いで、その算出されたユーザベクトルUと仮ユーザベクトルU’とを比較してその差分データを生成する。
端末装置10aは、生成された差分データをサーバ60aに送信する(S22)。サーバ60aは、この差分データを受信するとその旨を報知する確認通知を端末装置10aに送信する。そしてレスポンス(すなわちページ)を端末装置10aに送信する(S23)。またサーバ60aは、差分データに基づいてユーザ情報データベースに蓄積された端末装置10aのユーザベクトルUを更新する。この更新処理により、ユーザ情報データベースには、上記において端末装置10aで生成されたユーザベクトルUと同一のデータが蓄積されることになる。
端末装置10aがS23の処理で送信されたページを受け取ると、本実施例1と同様にサーバ60aによる検索エンジンが表示される。ユーザ・オペレーションによりこの検索エンジンの入力フォームに検索キーワードが入力されると、ブラウザ50は、その検索キーワードを含むURLをサーバ60aに送信する(S24)。
サーバ60aは、S24の処理で送信されたURLを受け取ると、更新されたユーザベクトルUに基づいて、上述した一連の処理(すなわち検索処理、及び、並び替え処理(又は絞り込み処理))を実行する。そしてその検索結果のページを端末装置10aに送信する(S25)。これによりユーザは本実施例1と同様に、その嗜好等が加味された動的な検索結果を得ることができる。
本実施例2によれば、端末装置10aはユーザベクトルUの代替として差分データを送信する。このため送信データの容量が大幅に圧縮されるという効果が奏される。ユーザベクトルUの次元やビット数が多ければ多いほどその効果は顕著となり得る。
図7に、本発明の第三の実施例において端末装置10aとサーバ60aとの間でやり取りされる処理の流れを示す。
図7に示される処理は、例えばサーバ60aが提供する検索エンジンの入力フォームに検索キーワードが入力された時点で開始される。本実施例3によれば、ユーザ・オペレーションにより検索エンジンの入力フォームに検索キーワードが入力されると、ブラウザ50は、その検索キーワードを含むURLをサーバ60aに送信する(S31)。
サーバ60aは、S31の処理で送信されたURLを受け取ると周知の検索処理を実行して、その検索結果のページと共に仮ユーザベクトルU’を端末装置10aに送信する(S32)。
端末装置10aがS32の処理で送信された検索結果のページを受け取ると、ブラウザ50において、ユーザの嗜好等を加味していない通常の検索結果がレンダリングされる。なおここでレンダリングされるページには、再検索処理をサーバ60aに実行させるためのボタンが含まれる。ユーザ・オペレーションにより当該ボタンがクリックされると、端末装置10aは、サーバ60aからの仮ユーザベクトルU’を用いてその差分データを生成する。次いで、その生成された差分データをサーバ60aに送信する(S33)。
サーバ60aは、S33の処理で送信された差分データを受け取ると、ユーザ情報データベースに蓄積された端末装置10aのユーザベクトルUを更新する。次いで、更新されたユーザベクトルUに基づいて、上述した一連の処理(すなわち検索処理、及び、並び替え処理(又は絞り込み処理))を実行する。そしてその検索結果のページを端末装置10aに送信する(S34)。これによりユーザは本実施例1及び2と同様に、その嗜好等が加味された動的な検索結果を得ることができる。
本実施例3によれば、端末装置10aは通常の検索結果を得ることができる。そして必要とするのであればユーザの嗜好等が加味された動的な検索結果も得ることができる。
図8に、本発明の第四の実施例において端末装置10aとサーバ60aとの間でやり取りされる処理の流れを示す。
図8に示される処理は、例えばユーザ・オペレーションによりブラウザ50がサーバ60aにログインした時点で開始される(S41)。サーバ60aは、ログイン時に入力されたアカウント及びパスワードを受信すると、その確認通知をブラウザ50に返信する(S42)。次いでブラウザ50は、この確認通知に呼応してユーザベクトルUを送信する(S43)。ここで送信されるユーザベクトルUには、例えばユーザが現在位置する地域を表すための「現在地域」等の属性が含まれる。
「現在地域」の属性には「確からしさ」の代替として、地域を示すデータがエントリされる。エントリされる地域は例えば直近のコンテキスト情報に基づいて決定される。これについて、横浜在住のユーザが大阪に出張する場合を例に取り説明する。
このような場合ユーザは、例えば端末装置10aを用いて大阪に関する情報(街の情報や乗り換え案内等)をまとまった期間(例えば出張中)に集中的に検索・入力することが想定される。従って出張中における直近のコンテキスト情報によれば、大阪に関する情報の入力履歴等が一時的に多くなる。附言するに直近のコンテキスト情報に限れば、横浜に関する情報よりも大阪に関する情報の割合が高くなり得る。直近のコンテキスト情報を参照して各地域に関する情報を比較し、例えば最も出現回数の多い地域をユーザが現在位置する地域として推定することができる。このように推定された地域が例えば「現在地域」にエントリさせるべき地域とされる。
また携帯装置10aに周知のGPS(Global Positioning System)レシーバが搭載されている場合、当該GPSレシーバによる測位結果を参照して「現在地域」を決定することもできる。
サーバ60aはユーザベクトルUを受信すると、当該ユーザベクトルUをその送信元に関連付けてユーザ情報データベースに蓄積する。次いでその確認通知をページと共にブラウザ50に送信する(S44)。
端末装置10aがS44の処理で送信されたページを受け取ると、ブラウザ50上でサーバ60aによる検索エンジンが表示される。ユーザ・オペレーションによりこの検索エンジンの入力フォームに検索キーワードが入力されると、ブラウザ50は、その検索キーワードを含むURLをサーバ60aに送信する(S45)。
サーバ60aはS45の処理で送信されたURLを受け取ると、上記ユーザベクトルUに基づいて、上述した一連の処理(すなわち検索処理、及び、並び替え処理(又は絞り込み処理))を実行する。そしてその検索結果のページを端末装置10aに送信する(S46)。これによりユーザは本実施例1と同様に、その嗜好等が加味された動的な検索結果を得ることができる。
サーバ60aは、本実施例4の如く「現在地域」の属性を含むユーザベクトルを用いて処理を行う場合、当該属性にエントリされた地域に重点を置いた検索結果をユーザに提供するよう動作する。例えば「現在地域」にエントリされたデータが「東京」を示す場合、サーバ60aは、検索処理において例えば都内全ての鉄道路線名を検索条件式に加えた絞り込みを行うよう動作する。
図9に、本発明の第五の実施例において端末装置10aとサーバ60aとの間でやり取りされる処理の流れを示す。ここで、説明の便宜上、100セットの属性データの各々に「A1」乃至「A100」を付す。また属性データA1乃至A100の各々を用いて生成された各ユーザベクトルに「UA1」乃至「UA100」を付す。
図9に示される処理は、例えば端末装置10aとサーバ60aとのセッションが確立された時点で開始される。本実施例5によれば、端末装置10aとサーバ60aとのセッションが確立されると、端末装置10aは、属性データA1に基づいてユーザベクトルUA1を生成しサーバ60aに送信する(S51)。
サーバ60aは、ページのリクエスト及びユーザベクトルUA1を受信するとその旨を報知する確認通知を端末装置10aに送信する。そしてページを端末装置10aに送信する(S52)。またサーバ60aは、受信したユーザベクトルUA1をその送信元に関連付けてユーザ情報データベースに蓄積する。
端末装置10aがS52の処理で送信されたページを受け取ると、ブラウザ50上でサーバ60aによる検索エンジンが表示される。ユーザ・オペレーションによりこの検索エンジンの入力フォームに検索キーワードが入力されると、ブラウザ50は、その検索キーワードを含むURLをサーバ60aに送信する(S53)。
サーバ60aは検索キーワードを受け取ると、次に、ユーザベクトルUA10を端末装置10aにリクエストする(S54)。端末装置10aはこのリクエストに呼応して、属性データA10に基づいてユーザベクトルUA10を生成する。そしてこの生成されたユーザベクトルUA10をサーバ60aに送信する(S55)。
サーバ60aは、S55の処理で送信されたユーザベクトルUA10を受け取ると、ユーザベクトルUA1及びユーザベクトルUA10に基づいて、上述した一連の処理(すなわち検索処理、及び、並び替え処理(又は絞り込み処理))を実行する。すなわちサーバ60aは、二つのユーザベクトルに含まれる属性に関して上述した一連の処理を実行する。そしてその検索結果のページを端末装置10aに送信する(S56)。これによりユーザは本実施例1と同様に、その嗜好等が加味された動的な検索結果を得ることができる。
なお本実施例5においてサーバ60aがより多くのユーザベクトルをリクエストするよう動作しても良い。この場合、より多数の属性に関して上述した一連の処理が実行される。
またS56の処理以降にサーバ60aが例えば更なる検索キーワードを端末装置10aから受け取った場合、当該サーバ60aは、更に別のユーザベクトルUn(ユーザベクトルUA1、UA10以外)を端末装置10aにリクエストする。端末装置10aはこのリクエストに呼応してユーザベクトルUnを生成してサーバ60aに送信する。サーバ60aはこれを受け取り、上記ユーザベクトルUA1、UA10に加えてユーザベクトルUn(又はこれらのうちの少なくとも一つ)に基づいて、上述した一連の処理(すなわち検索処理、及び、並び替え処理(又は絞り込み処理))を実行する。すなわちサーバ60aは、検索のリクエストを同一セッションにおいて続けて受けたとき、前回とは異なるユーザベクトルを端末装置10aにリクエストするよう動作する。
これらの実施例によれば、サーバは、端末装置で生成されたベクトルデータを受け取り、これを用いることで動的な情報提供を実現している。このベクトルデータはサーバにとって既知のパラメータで構成されたデータである。このためサーバは、端末装置からのコンテキスト情報を完全に解釈することができる。これによりサーバは、動的な情報提供(例えば検索結果の並べ替えや絞り込み、又は、広告提供等)を確実に実施することができるようになる。
またこのようなベクトルデータについてサーバ側と端末装置側とで予め規定が設けられている場合、端末装置側におけるコンテキスト情報の生成処理、及び、サーバ側における動的な情報提供処理が容易に実現されるようになる。
またこのようなベクトルデータをサーバと端末装置との間でやり取りするようネットワークシステムを構築することにより、通信データ量を低減させることが可能となる。附言するにやり取りされる情報がコンテキスト情報そのものでない。これは、ユーザのプライバシーを保護するという観点から望ましいと言える。
また端末装置においてコンテキスト情報を生成するために、かな漢字変換処理の履歴、入力フォームへの入力履歴、アドレスバーに対するURL又はIPアドレスの入力履歴が用いられている。これは、コンテキスト情報を生成するために、例えばメーラやブラウザを始めとする端末装置に実装された種々のアプリケーションにおける履歴を参照することを意味する。ユーザは端末装置に実装された種々のアプリケーションを利用する。このため、各アプリケーションにおける履歴を用いてコンテキスト情報を生成するようにしたことで、より精度の高いコンテキスト情報の提供が実現されるようになる。
以上が本発明の実施の形態である。本発明はこれらの実施形態に限定されるものではなく様々な範囲で変形が可能である。
例えばHDD16に蓄積されるコンテキスト情報は、かな漢字変換処理の履歴等に限定されない。例えばブラウザ50でページを閲覧したとき、当該ページに含まれる単語(テキストデータ)や、ページ、オブジェクト(画像や動画等)にメタデータとして付与されたtagのテキストデータをコンテキスト情報として取得し、それに該当する単語カウンタをインクリメントしても良い。ここでいう「tag」とは、オブジェクト等を分類するためのキーワードである。例えばモナリザの画像には「tag」として、「モナリザ」、「ダビンチ」、「ルーブル美術館」等のメタデータが付与されている。
またHDD16に蓄積されるコンテキスト情報には例えばフォームの選択情報も含まれ得る。「フォームの選択情報」とは、例えば規定事項の入力フォームにおける選択結果である。例えばユーザ情報を入力するフォームにおいて「男」又は「女」の何れかを選択したときの結果である。この選択結果の情報(単語)により単語カウンタをインクリメントしても良い。
本発明の実施の形態のネットワークシステムの構成を示したブロック図である。
本発明の実施の形態の端末装置の構成を示したブロック図である。
本発明の実施の形態のブラウザに含まれるブラウザエンジンの機能ブロック図である。
本発明の実施の形態のサーバの構成を示したブロック図である。
本発明の第一の実施例のネットワークシステムにおいて実行される処理の流れを示した図である。
本発明の第二の実施例のネットワークシステムにおいて実行される処理の流れを示した図である。
本発明の第三の実施例のネットワークシステムにおいて実行される処理の流れを示した図である。
本発明の第四の実施例のネットワークシステムにおいて実行される処理の流れを示した図である。
本発明の第五の実施例のネットワークシステムにおいて実行される処理の流れを示した図である。
符号の説明
10a乃至10n 端末装置
3、62 CPU
5、64 ROM
7、66 RAM
9、68 ネットワークインタフェース
11 ディスプレイドライバ
13 ディスプレイ
15 インタフェース
16、70 HDD
17 ユーザインタフェースデバイス
30 ブラウザエンジン
50 ブラウザ
60a乃至60m サーバ