(58)【調査した分野】(Int.Cl.,DB名)
前記第2のデータ処理部は、前記パーソナルデータ格納部に格納されたパーソナルデータを読み出す場合に、パーソナルデータを読み込む旨をユーザに提示することを特徴とする請求項1乃至4のいずれか1項に記載の端末装置。
【背景技術】
【0002】
スマートフォンに代表される個人が所持する情報機器の普及に伴い、モバイル端末上でさまざまなオンラインサービスから提供される情報を表示することが一般的になっている。これらの情報表示サービスにおいては、ユーザにかかわる情報を利用して、ユーザにパーソナライズされた情報を表示することで、ユーザの利便性を高めているケースがある。たとえばユーザの現在地の情報をもとに周辺の地図データをサーバからダウンロードしてモバイル端末上に表示することによって、ユーザはわざわざ現在地を情報表示サービスに入力しなくても、現在地周辺の地図や関連情報を即座に閲覧することができる。
【0003】
このように、ユーザに最適化(パーソナライズ)されたサービスを提供するためには、ユーザ自身の情報(パーソナルデータ)を元に、その他の関連するデータを結びつけてユーザに提示する処理が必要である。なおパーソナルデータは、ユーザのある時点でのコンテキスト(現在地など)をあらわすコンテキストデータと、それ以外のデータに分けることができる。コンテキストデータは時間とともに変化する情報であり、それ以外のデータには、たとえば氏名・住所・性別などの個人情報やプロファイル情報、移動履歴や購買履歴などの履歴情報が含まれる。以降では、単にパーソナルデータと表記した場合は、後者の、コンテキストデータ以外の情報を指すものとする。
【0004】
個人に最適化された情報を表示する方法としては、現在主に二種類の方法が使われている。
一つは、端末上にインストールされたアプリケーションの形態としてユーザに情報を表示するものである。モバイル端末上の地図アプリケーションが、端末のGPS(位置)データを用いて現在地周辺の地図を表示するケースがこれに該当する。このアプリケーションの形態では、端末上に保存された任意のデータにアクセスできるため、個人情報を用いた表示情報の最適化(パーソナライズ)が自由に行える。一方、この形態ではアプリケーションが取得した任意のデータを外部のサーバに送信可能であるため、悪意のあるアプリケーションがパーソナルデータを悪用する危険性を抱えている。最近では、モバイル端末に保存されている個人情報やパーソナルデータを、モバイル端末にインストールされたアプリケーションが抜き取り、ユーザに無断で外部(アプリ開発会社が運営するサーバ等)に送信しているケースがあり、社会問題となっている。このような不正なアプリケーションが個人情報を勝手に収集し濫用することを、技術的に抑止するのは困難である。
【0005】
他の一つは、Webブラウザを用いてユーザに最適化された情報を表示する形態である。この形態では、Webサーバからダウンロードされたコンテンツ(HTMLファイルやJava(登録商標)Script(登録商標)プログラム)が、ブラウザに用意された機能 (API) を用いて現在地情報を取得し、サーバにその情報を送ることによって現在地周辺の地図データをダウンロードし、周辺地図を表示する(非特許文献1)。この形態では、ブラウザが用意したAPIの範囲でしか、ユーザ端末からパーソナルデータを自動的に取得することはできない。HTML規格ではユーザのプライバシー保護の観点から、ブラウザはユーザ端末内のデータには通常アクセスできず、ユーザの明示的な許可がある場合に限りいくつかのコンテキストデータへのアクセスを許容している。現在においては、ブラウザがユーザ端末から自動的に取得できるデータは位置情報程度である。このため、位置情報以外のパーソナルデータを用いて表示情報をパーソナライズするためには、パーソナルデータを何らかの形でWebサーバに蓄積しておく必要がある。しかし、位置情報履歴や購買履歴情報などのプライバシーにかかわる情報をサーバにすべて蓄積しておくのは、ユーザのプライバシー保護や情報セキュリティ確保にかかるコストが大きいため現実的ではない。
【発明の概要】
【発明が解決しようとする課題】
【0007】
上記の従来技術ではユーザのパーソナルデータを活用した高度なパーソナル情報表示サービスを提供したい場合、ユーザ端末上で動作するプログラムが端末内のパーソナルデータにアクセスできる場合においては、そのデータを外部に自由に送信され悪用されてしまうリスクがある。
【0008】
また、プログラムが端末内のパーソナルデータにアクセスできない場合においては、パーソナルデータをあらかじめサーバ上に保存しておく必要があり、個人情報管理上の高いコストが発生していた。
【0009】
本発明の目的は、パーソナルデータを保護しつつ、パーソナルデータと外部からのコンテキストデータの双方を活用した高度なパーソナルサービスの提供を可能とする端末装置、データ処理方法及びプログラムを提供することにある。
【課題を解決するための手段】
【0010】
上記の課題を解決するため、本発明ではプログラム実行のための二つのデータ処理部を設ける。
まず、端末内において外部(サーバなど)にデータを送受信できない領域(サンドボックス)を生成し(これをプライベートデータ処理部と呼ぶ)、プライベートデータ処理部内においてパーソナルデータを用いたデータ処理および表示データ生成を行う。プライベートデータ処理部内で実行されるプログラムは、端末内のパーソナルデータにアクセスできるが、外部にデータを送受信することはできない。
【0011】
次に、プライベートデータ処理部とは別に、自由に外部にアクセスできるパブリックデータ処理部を設けて、データ処理、外部とのデータ送受信および表示データの生成を行う。パブリックデータ処理部内で実行されるプログラムは、ブラウザと同様コンテキストデータ(現在位置情報等)にはアクセスできるが、パーソナルデータにはアクセスできない。
【0012】
最後に、表示部が、プライベートデータ処理部およびパブリックデータ処理部がそれぞれ作成した表示データを合成して最終的にユーザに提示する。
なお、本発明ではパブリックデータ処理部やプライベートデータ処理部はそれぞれ複数個存在していても良い。また、プライベートデータ処理部の外部アクセスに例外を設けて、特定の外部サーバにのみデータを送受信できるようにしても良い。この場合、プライベートデータ処理部は、信頼された特定のサーバにのみパーソナルデータを送信することが可能になる。なお、上記各発明は、可能な限り組み合わせることができる。
【発明の効果】
【0013】
本発明では、外部にデータを送受信できないプライベートデータ処理部内のプログラムのみがパーソナルデータを扱うため、パーソナルデータを外部サーバに送信して濫用される可能性を技術的に防いでいる。
また、一方でプライベートデータ処理部内のプログラムが自由にパーソナルデータにアクセスして個人に最適化した情報表示画面を作成することで、外部サーバにパーソナルデータを保管しない場合でもパーソナライズサービスの実現を可能としている。
【0014】
なお、プライベートデータ処理部しか存在しない場合は、コンテキストデータに基づく外部データの取得リクエストをサーバに送信することができない。例えば自分の現在位置をもとに周辺の地図データをダウンロードして表示することができない。本発明では、パブリックデータ処理部において地図の表示データを作り、プライベートデータ処理部においてパーソナルな表示データを作り、表示部においてそれらを合成することによって、パーソナルデータを保護しつつも、パーソナルデータとコンテキストデータの双方を活用した高度なパーソナルサービスの提供を可能とする。
【発明を実施するための形態】
【0016】
添付の図面を参照して本発明の実施形態を説明する。以下に説明する実施形態は本発明の実施の例であり、本発明は、以下の実施形態に制限されるものではない。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。
【0017】
本発明に係る実施形態を説明するに先立ち、その動作原理について説明する。
以前は、
図1に示すように、web上のサーバSVからダウンロードされたコンテンツ(HTMLファイルやJava(登録商標)Script(登録商標)プログラム)が、携帯端末MT内のブラウザに用意された機能(API)を用いて現在地情報を取得し、サーバSVにその情報を送信する。すると、サーバSVは、データ送信部1と、データ処理部2と、リクエスト受信部3と、パーソナルデータ記憶部4とを備えている。サーバSVは、リクエスト受信部3により携帯端末MTから送られた情報を受信すると、データ処理部2によりパーソナルデータ記憶部4からパーソナルデータを読み出してパーソナル化した表示データを生成し、データ送信部1により表示データを携帯端末MTへ送信する。
【0018】
ところで、
図1に示すシステムでは、位置情報履歴や購買履歴情報などのプライバシーに関わる情報をサーバSVに全て蓄積しておくため、ユーザのプライバシー保護や情報セキュリティ確保にかかるコストが大きい。
そこで、本発明は、
図2に示すように、ユーザ端末100内に、パーソナルデータ提供部130及びローカルサーバ140を設けるようにし、情報表示システム(ブラウザ)110内に、表示データ受信部111、表示部114及びリクエスト送信部115の他に、パブリックデータ処理部112と、プライベートデータ処理部113とを設けるようにしている。プライベートデータ処理部113は、パーソナルデータ提供部130に格納されたパーソナルデータを用いたデータ処理及び表示データ生成を行う。プライベートデータ処理部113内で実行されるプログラムは、パーソナルデータ提供部130にアクセスできるが、外部にデータを送受信することはできない。
【0019】
パブリックデータ処理部112は、データ処理、外部とのデータ送受信及び表示データの生成を行う。パブリックデータ処理部112内で実行されるプログラムは、ユーザ端末100内のコンテキストデータ提供部120にはアクセスできるが、パーソナルデータ提供部130にはアクセスできない。
【0020】
表示部114は、パブリックデータ処理部112及びプライベートデータ処理部113がそれぞれ作成した表示データを合成して最終的にユーザに提示する。
上記の原理に基づき、以下に本発明の実施形態について説明する。
【0021】
(第1の実施形態)
本第1の実施形態では、サービス提供者Xが、本発明の情報表示システムを用いてユーザに対してパーソナライズされたWebサービスを提供する、というシナリオを考える。具体的には、あるユーザ端末内にパーソナルデータとして過去の購買履歴が蓄積されているものとして、サービス提供者はユーザの現在地周辺にある店舗で売っている商品の中から、ユーザの買いそうな商品をセレクトしてユーザに対して提示(ユーザ端末上に表示)するケースを考える。
【0022】
図3は、本第1の実施形態に係るユーザ端末100とサーバSVとの接続構成例を示し、以下に各機能部について説明する。サーバSVは、本第1の実施形態のサービスを提供する事業者Xの所有するWebサーバである。サーバSVは、リクエスト受信部3、データ処理部2、データ送信部1をそれぞれ持つ。
【0023】
ユーザは、本サービスを受けるユーザであり、ユーザ端末100を所持している。ユーザ端末100はスマートフォンなどのモバイル端末であってもパソコンなどの据え置きの端末であっても良い。
ユーザ端末100には、現在地情報などのコンテキストデータを管理し、パブリックデータ処理部112に対して提供するコンテキストデータ提供部120と、電話帳情報や位置情報履歴、購買履歴などのパーソナルデータを管理するパーソナルデータ提供部130と、ローカルサーバ140と、情報表示システム110がある。本第1の実施形態では、コンテキストデータ提供部120およびパーソナルデータ提供部130は、ユーザ端末100がAPIないしデータベースとして実装しているものとし、ローカルサーバ140はユーザ端末100上で動作するWebサーバとする。
【0024】
情報表示システム110は、データ受信部111、パブリックデータ処理部112、プライベートデータ処理部113、表示部114、リクエスト送信部115で構成される。本第1の実施形態においては、情報表示システム110はWebブラウザを用いるものとし、パブリックデータ処理部112、プライベートデータ処理部113はWebページの<HTML>〜</HTML>の要素で示される単位(フレーム要素)とし、HTMLデータとともに提供されたJavaScript(登録商標)プログラムが動くものとする。
【0025】
ローカルサーバ140は、パーソナルデータ提供部130と接続され、ユーザ端末100内に保存されているパーソナルデータをパーソナルデータ提供部130に問い合わせる機能を持つ。パーソナルデータ提供部130は情報表示システム110とは接続されておらず、情報表示システム110は直接パーソナルデータにアクセスすることはできない。
【0026】
本実施形態のポイントは、パーソナルデータにアクセス可能な機能を持つローカルサーバ140をユーザ端末100内に設けた上で、後述する手順でWebページを構成することによって、パーソナルデータにアクセス可能でありつつ外部へのデータ送受信が不可能なプライベートデータ処理部113を生成すること、さらにプライベートデータ処理部113およびパブリックデータ処理部112がそれぞれ生成した表示データをブラウザの既存機能を用いて合成してユーザに提示することにある。
【0027】
以降は、
図3および
図4中のステップ番号に沿って説明する。
図4は、サーバSVとユーザ端末100の各部との間のデータの送受信動作を示すシーケンスである。
(ステップ1) リクエスト送信部115は、ユーザからサービス提供者の提供するWebサイト(特定のURL)にアクセスする指示を受けると、そのURLに対する接続要求を送信する。
【0028】
(ステップ2) 接続要求をリクエスト受信部3により受信したサーバSVは、リクエストの内容に対応したWebサイトデータ+クエリをデータ処理部2において作成し、データ送信部1から送信する。Webサイトデータは、通常のWebサイトで用いられるHTMLデータ及びJava(登録商標)Script(登録商標)プログラムであり、この例では現在地を読み出して周辺にある地図と店舗のアイコンを表示するプログラムが含まれるものとする。クエリは、
図5に示すように、HTML部分とデータ部分で構成される。この例ではデータ部分には、店舗の名前と売っている商品のリストが組になったものが、複数店舗分記載されているものとする。HTML部分には、指定された店舗名の店で売っている商品リストの中から、ユーザの一年前から現在までの購買履歴に含まれる商品をリストアップして、HTMLとして整形して出力するためのデータおよびプログラムが記載されているものとする。
【0029】
上記のWebサイトデータとクエリは、データ受信部111を経由して情報表示システム(ブラウザ)110に読み込まれ、Webページとなる(S2−1,S2−2)。このページをパブリックデータ処理部112とする。パブリックデータ処理部112は実際には通常のWebページであるため、端末外部のデータやブラウザがAPIとして提供するコンテキストデータに自由にアクセスできる一方、ブラウザがAPIを提供していない端末内部のパーソナルデータに対してはアクセスできない。
【0030】
(ステップ3) パブリックデータ処理部112は、サーバSVから渡されたクエリをローカルサーバ140に登録する(S3−1)。ローカルサーバ140は、クエリの内容を自身の記憶領域内に保存し(S3−2)、WebサーバとしてクエリのHTML部分およびデータ部分をホストする。このローカルサーバ140にホストされたWebサイトを情報表示システム(ブラウザ)110で読み込んだもの(Webページ)がプライベートデータ処理部113となる(S3−3)。
【0031】
なお、パブリックデータ処理部112は、クエリ登録の際の戻り値として、ローカルサーバ140上に展開されたプライベートデータ処理部113のURLを得る(S3−4)。
一般にHTMLを用いた情報表示システム110においては、一つのHTMLで構成されたWebページAの中において、別のHTMLで構成されたWebページBをインライン参照(<iframe>タグのsrc要素に別のHTMLを指すURLを指定)することによって、WebページAがWebページBを内包する形で入れ子のように表示することができる。
【0032】
本実施形態においても、戻り値として得たプライベートデータ処理部113のURLをインライン参照することによって、パブリックデータ処理部112内のWebページがプライベートデータ処理部113の生成するWebページを内包して表示することができる。なお、この際、<iframe>タグを用いた通常のHTMLの表記法によって、内包されるWebページの表示位置を指定することも可能である。
【0033】
ローカルサーバ140は、パーソナルデータ提供部130に対するパーソナルデータの問い合わせ機能を持ち、プライベートデータ処理部113のプログラムに対してJavaScript(登録商標) APIを提供する。このため、プライベートデータ処理部113はパーソナルデータに対してアクセスできる。
【0034】
一方で、ローカルサーバ140は、
図6に示すようなHTTPヘッダを付与してクエリの内容をホストすることによって、Content Security Policy(非特許文献2)の技術にしたがって、このWebページ(プライベートデータ処理部113)の機能を制限する。具体的には、このWebページからの外部へのリクエスト送信が不可能となる。これによって、プライベートデータ処理部113は、パーソナルデータにアクセス可能でありながら、外部へのデータ送受信は不可能なWebページとなる。
【0035】
(オプション1) なお、パブリックデータ処理部112は、サーバSVから複数のクエリを受け取って、クエリ登録処理を複数回行ってもよい。その場合、プライベートデータ処理部113は複数個生成される。
(オプション2) また、クエリに監査者Yによる電子署名を付与しても良い。監査者Yはクエリの内容(プログラム)を確認・検証し、パーソナルデータを適切に扱っていると判断した場合にクエリに電子署名を付与する。この署名によって、クエリの内容が適切であることを技術的に担保でき、またそれをユーザが確認することができる。
【0036】
(ステップ4) パブリックデータ処理部112では、Webサイトデータを用いて表示データを生成する。その際、Webサイトデータ内のプログラムの指示に従って、コンテキストデータ提供部に対してユーザ端末の現在地データを問合せ(S4−1)、現在地の緯度経度を得る(S4−2)。パブリックデータ処理部112は、リクエスト送信部115を経由して現在地情報(緯度経度)をサーバSVに対して送信する(S4−3)。サーバSVは、指定された緯度経度を中心とした地図データとともにその周辺の地域にある複数の店舗データ(店舗名、店舗位置)を返信する(S4−4,S4−5)。
【0037】
(ステップ5) パブリックデータ処理部112は、データ受信部111経由で地図データおよび店舗データを取得し、表示画面データ(HTML)を作成して(S5−1)、表示部114に渡す(S5−2)。表示部114では、受け取った表示データから画面イメージを構成して、ユーザに対して提示(表示)する。
図7に表示イメージを示す。
【0038】
(ステップ6) 上記ステップ5において
図7の表示画面を提示されたユーザが、画面上に表示された店舗から一つを選択して表示操作(クリックあるいはタップ)を行った場合(S6−1)、パブリックデータ処理部112は選択された店舗名を受け取る(S6−2)。そして、ローカルサーバ140経由でプライベートデータ処理部113に対して、店舗に対する詳細情報表示の依頼を行う(S6−3,S6−4)。これを受けとったプライベートデータ処理部113は、その店舗名を用いてローカルサーバ140に対して問い合わせを行う(S6−5)。ローカルサーバ140は、上記ステップ3で登録されたクエリデータを参照して、その店舗(
図7中ではMTストア)が販売している商品リストをプライベートデータ処理部113に対して返送する(S6−6)。
【0039】
(ステップ7) プライベートデータ処理部113は続けて、ローカルサーバ140に対して購買履歴問い合わせを行う(S7−1)。ローカルサーバ140は、パーソナルデータ提供部130に対し購買履歴問い合わせを行い(S7−2)、パーソナルデータ提供部130から購買履歴を取得すると(S7−3)、購買履歴をプライベートデータ処理部113に返送する(S7−4)。
【0040】
そして、プライベートデータ処理部113は、その店舗が販売している商品リストに対してパーソナルデータを用いて並べ替えを行う(S7−5)。具体的には、プライベートデータ処理部113は、購買履歴情報を用いて店舗の商品リストをユーザが買った回数の多い順に(すなわちそのユーザへのおすすめ順に)並べ替えて、表示データ(HTML)として生成する(S7−6)。
【0041】
(オプション3) ローカルサーバ140が、パーソナルデータ提供部130にアクセスしてユーザ端末100内のパーソナルデータの読み出しを行う際、ローカルサーバ140はユーザに対して、パーソナルデータを読み込む旨の注意喚起を行うオプトイン画面を表示しても良い。オプトイン画面を確認することによって、ユーザは自分のパーソナルデータがサービスに利用されることを認知することができるため、より安心してサービスを利用することができる。
【0042】
さらに、オプトインの際、ローカルサーバ140はユーザに対して、パブリックデータ処理部112がローカルサーバ140に登録したクエリの署名を表示してもよい。ユーザはクエリに対して監査者Yが署名したことを確認することによって、自分のパーソナルデータにアクセスしようとしているプログラムが適切な処理を行うのかどうか第三者が内容を検証したことを確認できるため、より安心してサービスを利用することができる。
【0043】
(オプション4) なお、本第1の実施形態では、店舗ごとの商品リストはクエリ内のデータ部分に記載され、プライベートデータ処理部113はローカルサーバ140経由で商品リストを取得することしたが、これはHTML部分やプログラム内に直接記載されていてもよいし、パブリックデータ処理部112がサーバSVから取得してプライベートデータ処理部113への店舗情報表示依頼の際に追加パラメタの形で提供してもよい。
【0044】
(ステップ8) 生成された表示データは、表示部114において、前に表示しているパブリックデータ処理部112の表示データに重ねあわされて表示される(
図8)。
図8に示す表示例では、例えばMTストアでおすすめの商品B、商品CがMTストアから吹き出しで表示されることになる。
【0045】
(第1の実施形態による効果の説明)
このような第1の実施形態を、従来のブラウザ技術を用いて実現する場合には、ブラウザ経由で購買履歴などのパーソナルデータにアクセスする手段は存在しないため、サービス提供者がユーザの購買履歴を既に持っていてそのデータをサーバSVに保管していない限りはこのようなサービスを提供できない。このため、既に多くの購買履歴を持っている大手事業者以外はこのようなサービスを提供することは困難であるし、大手事業者としてもユーザの全ての購買履歴を集めることは不可能であるため、十分なデータを用いたお勧め商品の提示は不可能である。
【0046】
一方で、従来のアプリケーションの形態で実現する場合、アプリケーションがユーザ端末100からパーソナルデータを読み出して外部サーバに送信してしまう、すなわちパーソナルデータの濫用が可能となってしまう。これを防ぐためにアプリケーションに一切のネットワーク通信機能・権限を持たせない場合は、地図データなどの外部データにアクセスできなくなるため、上記のような第1の実施形態は技術的に実現不可能である。
【0047】
本発明による第1の実施形態では、外部データにアクセス可能なパブリックデータ処理部112において地図の表示データを作成し、外部にはアクセスできないがパーソナルデータにアクセス可能なプライベートデータ処理部113において商品お勧めデータを作成し、表示部114においてそれらを合成することによって、上記のような課題を回避しつつ第1の実施形態を実現している。
【0048】
(第2の実施形態)
本第2の実施形態では、上記第1の実施形態をベースに、プライベートデータ処理部113に外部アクセスのための例外を設けて、複数ユーザの滞在店舗リストを集計して人気の店舗のランキングを作成し、地図・店舗データをカスタマイズしてユーザに提供するシナリオについて説明する。
【0049】
図9は、本第2の実施形態に係るユーザAのユーザ端末100、ユーザBのユーザ端末200とサーバSVXと集計サーバ300との接続構成例を示し、以下に各機能部について説明する。ユーザA,Bがそれぞれ端末100,200を所持している。各端末100,200内は、上記第1の実施形態で説明した各機能部に加えて、パーソナルデータ送信部116,212を持つ。
【0050】
また、サーバSVXを用いて本サービスを提供する事業者Xとは別の事業者Yが集計サーバ300を持ち、ユーザAおよびBの購買履歴データはこの集計サーバ300にのみ送られる。
【0051】
本第2の実施形態では、上記第1の実施形態のステップ3において、ローカルサーバがWebサーバとしてクエリのHTML部分およびデータ部分をホストする際に、
図10に示すようなHTTPヘッダを付与する。この場合、ローカルサーバのURLに続いて、集計サーバ300のURLが付加される。これにより、生成されるプライベートデータ処理部113は集計サーバ300とのみ通信が可能になる。端末100,200で動作するプライベートデータ処理部113,211は、クエリに記載のプログラム内容に従い、ローカルサーバ経由で各端末100,200内の位置情報履歴データにアクセスして、過去に滞在した店舗のリストを作成し、そのデータ(リスト)を集計サーバ300に送信する。
【0052】
集計サーバ300では、データ受信部313により複数のユーザから送られた滞在店舗リストのデータを受信し、データ集計部312により滞在店舗リストのデータを元に、滞在したユーザ数の多い店舗(即ち人気店舗)のランキングを作る処理(集計処理)を行い、データ送信部311により集計されたデータをサーバSVXに送る。これによりサーバSVXは、人気店舗ランキングをもとに、ユーザに提供するサービス内容をカスタマイズできる。具体的には、第1の実施形態のステップ4において、サーバSVXが位置情報を元に店舗データをユーザに返送する際に、人気店舗を優先して返送することによって、ユーザにはより最適化された地図・店舗データが表示される。
【0053】
本第2の実施形態では、サービスの提供事業者Xと集計サーバ300の提供事業者Yを分離し、プライベートデータ処理部113,211が唯一通信できる対象を集計サーバ300に限定することによって、サービスの提供事業者Xに直接パーソナルデータを送信しなくても、複数ユーザのパーソナルデータを用いてサービスをカスタマイズすることを可能としている。
【0054】
(その他の実施形態)
本発明の装置は、コンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。
要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。