JP2001243240A - 情報検索システム及び電子商取引システム - Google Patents

Abstract

(57)【要約】 【課題】 スキーマの属性が異なる商品やショップなど
の情報を、広大なネットワークの中からユーザが容易に
探し出すことができる情報検索システム及び電子商取引
システムを提供すること。 【解決手段】 各データベース（33a-c）からスキーマ
を収集し、収集した前記スキーマを標準スキーマに変換
して端末（10）に供給する第１のサーバ（50）と、前記
標準スキーマをもとに標準クエリーを生成して問合せを
行う端末（10）と、前記端末（10）から送られる標準ク
エリーを前記各データベース（33a-c）に対応するクエ
リーに変換して各データベース（33a-c）に対して同時
に問合せを行い、各データベース（33a-c）ごとに返さ
れるリザルトを標準リザルトに変換して前記端末(10)に
返す第２のサーバー(20)とを有することによる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワークを利
用した電子商取引システムに係り、特に、ユーザが広大
なネットの中から所望する商品やその情報を容易に探し
出すことができる情報検索システム、及び、所望する商
品やその情報を容易に探し出して発注等を行うことがで
きる電子商取引システムに関する。

【０００２】

【従来の技術】近年、初心者を含む家庭ユーザーへとイ
ンターネットの普及が進んだことにより、オンライン・
ショッピングなどの電子商取引（ＥＣ:Electronic Comm
erce）がユーザーの間に定着してきた。中でも、インタ
ーネット上で商品やサービスを販売する電子商店（Onli
ne Shop）は、出店コストが低いことから、地域名産品
などを扱う小規模ショップなどが次々と登場し、ＥＣ市
場全体を活性化している。

【０００３】このような電子商店のホームページはバー
チャル・ショップとも言い、ユーザーは商品の画像や説
明文の入った電子カタログのページから気に入った商品
を選択する。次に「購入」や「カゴに入れる」といった
ボタンをクリックすると、商品の送り先や個人情報を入
力するページに飛ぶ。そこで住所や氏名、電話番号、決
済方法などを指定し、そのデータを売り主に送ると購入
手続きである発注処理が完了するという仕組みが一般的
である。あるいは、商品がコンテンツである場合は、電
子配信でユーザに送ることができる。

【０００４】しかし一方で、ユーザは広大なネットワー
クの中から所望する商品やショップを探し出すことは難
しい。そのため、新規に出店した小規模ショップには、
なかなか客が訪れないという問題も見え始めている。

【０００５】インターネット上の情報を探し出すための
支援機能としては、世界中に分散しているＷＷＷホーム
ページの中から、キーワードに合致するものを検索する
検索エンジン（Search Engine ）が知られており、多く
のアクセスを集めることからポータルサイト（Portal S
ite ）とも呼ばれる。「portal」はもともと「入り
口」、「門」を意味する言葉であり、ユーザーがＷＷＷ
ブラウザを立ち上げて最初にアクセスするページのこと
をポータルサイトと呼ぶようになった。一般に、ポータ
ル・サイトは、検索サービス、ニュースなどの情報提供
サービス、チャットや掲示板のコミュニティ・サービ
ス、ブラウザから電子メールを送受信できるウエブ・メ
ールなどのサービスを一括提供している。インターネッ
トへの玄関口を握り、トラフィックを集約することで、
オンライン・ショッピングなど様々なビジネスの可能性
を確保できるメリットもある。また、電子配信を行うサ
イトは、得にダウンロードサイトと呼ばれ、注目されて
いる。

【０００６】図３２にインターネット上の情報を探し出
す典型的な例を示す。

【０００７】ユーザは、ネットワーク上に点在するＩＰ
（Information Provider：情報提供者）の情報を収集す
るために、端末１１０を用いてポータルサイトにアクセ
スする。ポータルサイトＡに対して問い合わせる場合に
は、ポータルサイトＡ用の検索メニュー画面が必要であ
り、その検索メニュー画面から検索式を入力して問い合
わせを行う。問い合わせ結果もポータルサイトＡ用の検
索結果画面として返送される。ポータルサイトＢに対し
ても同様に、ポータルサイトＢ用の検索メニュー画面と
検索結果画面によって行われる。

【０００８】

【発明が解決しようとする課題】このような検索エンジ
ンで情報検索を行うためには、検索スキーマの属性が一
致していなければならない。ここでスキーマとは、ある
カテゴリの商品やサービスの特徴情報を表現するために
必要な属性の集りのことをいう。例えば、「水産物」と
「日本酒」という２つの商品の生産地を表すための属性
として売り主が定義した属性は「水産物」の場合は「生
産地方」、「日本酒」の場合は「生産県」であったとす
る。これに対して、消費者であるユーザは、新潟の特産
品を探すために「生産地域＝新潟」として検索を行うか
もしれない。ところが、このままでは、上記「水産
物」、「日本酒」のいずれもヒットしない。データベー
スを検索するには、スキーマの属性が一致していなけれ
ばならないからである。

【０００９】特に、インターネットのようなオープンな
ネットワークでは、今後もスキーマの多様化が急ピッチ
で進むことが考えられる。

【００１０】更に、デジタル放送やインタラクティブ・
テレビ（Interactive Television）などの登場により、
視聴者とサービス提供者が対話をしながら、視聴者の希
望するサービスを提供する対話型システムが広がりつつ
ある。視聴者は、サービス提供者からＥＰＧ（Electron
ic Program Guide）と呼ばれる番組表データを受信す
る。ところが、サービス提供者ごとに異なった書式のＥ
ＰＧを配信しているのが現状であり、視聴者はサービス
提供者ごとのスキーマに合わせて番組等を検索しなけれ
ばならない。従って、異なる複数のサービス提供者の情
報を同時に検索したり、検索結果を並べて比較すること
ができなかった。

【００１１】このような異なるスキーマを統合する技術
として、例えば、特開平８−２４９３３８号に記載の技
術が知られている。この技術によれば、スキーマの属性
が異なる情報も検索できるものの、スキーマを統合する
ためにはユーザ自身が判断して行う必要があり、特に、
初心者を含む家庭ユーザーにとっては負担が大きいもの
であった。

【００１２】また、検索のための条件式を提示して、デ
ータ構造の異なる複数のデータベースを統合する技術と
して、例えば、特開平１１−１２６２０９号に記載の技
術が知られている。しかし、エージェントの派遣先や、
どの時点で検索を打ち切るかといった検索処理の制御を
ユーザ自身が判断し、その都度指示を与える必要があ
り、やはり一般のユーザーにとって負担が大きいもので
あった。

【００１３】また、単一のポータルサイトだけでは、所
望する商品やショップを探し出すことができず、複数の
ポータルサイトを渡り歩いて、ようやく見つけ出すこと
ができるという場合もある。例えば、図３２に例示した
ように、ポータルサイトＡに問い合わせただけではＩＰ
１４０ｆの情報を探し出せない。ポータルサイトＢに問
い合わせて初めてＩＰ１４０ｆの情報を収集することが
できる。

【００１４】このような問題に対して、例えば、特開平
１０−２１２５０号に記載の、複数のポータルサイトを
利用する技術がある。この技術によれば、それぞれのポ
ータルサイトから順に情報を検索し、その中から希望す
る情報を選択できる。しかし、複数のポータルサイトを
シリアルに検索する方式であるため、検索結果の商品情
報を比較するのに不便であり、また、複数のポータルが
互いに重複した情報を持ち合っている場合もあり、無駄
なアクセス時間がかかる、などの問題がある。

【００１５】本発明は、上記問題点に鑑みなされたもの
であって、スキーマの属性が異なる商品やショップなど
の情報を、広大なネットワークの中からユーザが容易に
探し出すことができ、また、スキーマの多様化にも柔軟
に対応することができる情報検索システム及び電子商取
引システムを提供することを目的とする。特に、複数の
ポータルサイトから所望する情報を探し出す際にも、短
時間で検索でき、更に、検索した商品情報などの比較・
検討を容易に行うことができる情報検索システム及び電
子商取引システムを提供することを目的とする。

【００１６】

【課題を解決するための手段】上記課題を解決するため
に、本発明の第１の特徴は、ネットワーク上に点在する
データベースを検索して情報の収集を行う情報検索シス
テムであって、前記各データベースからスキーマを収集
し、収集した前記スキーマを標準スキーマに変換して端
末に供給する第１のサーバと、前記標準スキーマをもと
に標準クエリーを生成して問合せを行う端末と、前記端
末から送られる標準クエリーを前記各データベースに対
応するクエリーに変換して各データベースに対して同時
に問合せを行い、各データベースごとに返されるリザル
トを標準リザルトに変換して前記端末に返す第２のサー
バーとを有することを特徴とする。

【００１７】本発明の第１の特徴によれば、ユーザが指
定する標準クエリーをネットワーク上の各データベース
に対応したクエリーに変換して、各データベースを同時
に或いは個別に検索するようにしたため、従来のデータ
ベースのスキーマ等を変更しなくても、スキーマが異な
るデータベースを確実に検索できる。

【００１８】また、検索結果を所定の標準形式に揃えて
ユーザに返すようにしているため、容易に比較・検討す
ることができる。

【００１９】本発明の第２の特徴は、前記第１のサーバ
は、前記各データベースのアドレスを収集し、収集した
前記アドレスを前記端末に供給し、前記端末は、供給さ
れた前記アドレスに基づいて問合せ先のデータベースを
決定することを特徴とする。

【００２０】本発明の第２の特徴によれば、端末はサー
バを介してどのデータベースにアクセスすれば良いか認
識することができ、即座に且つ確実に所望する情報を入
手することができる。

【００２１】本発明の第３の特徴は、利用者が、ネット
ワークに接続した端末を用いて、ネットワーク上に点在
するサイトのデータベースを検索して商品やサービスの
特徴情報を収集し、収集した情報を元にこの情報の提供
者に対して商品の発注を行う電子商取引システムであっ
て、前記利用者は、前記サイトに対して標準スキーマで
問合せを行うことで前記商品の特徴情報の収集を行い、
前記サイトは、オントロジ変換機能により前記標準スキ
ーマを、所定のルールに従って自サイトに対応するスキ
ーマに変換することを特徴とする。

【００２２】本発明の第３の特徴によれば、利用者が指
定する標準スキーマを自サイトに対応するスキーマに変
換して、データベース内の情報を同時に或いは個別に検
索するようにしたため、従来のデータベースのスキーマ
等を変更しなくても、スキーマが異なる情報を確実に検
索できる。

【００２３】本発明の第４の特徴は、利用者が、ネット
ワークに接続した端末を用いて、ネットワーク上に点在
するサイトのデータベースを検索して商品の特徴情報を
収集し、収集した情報を元にこの情報の提供者に対して
商品の発注を行う電子商取引システムであって、前記各
サイトのデータベースに格納されている情報を集約し、
且つ所定のルールに従って標準のスキーマに変換してデ
ータベース化する情報共有機能とを有する一般ポータル
サイトを有し、前記利用者は、前記一般ポータルサイト
に対して前記標準スキーマで問合せを行うことで前記商
品の特徴情報の収集を行うことを特徴とする。

【００２４】本発明の第４の特徴によれば、ネット上の
サイトにある情報を予め集約し標準のスキーマに変換し
てデータベース化した一般ポータルを備え、利用者は、
標準スキーマによってこの一般ポータルに対して問合せ
を行い、一般ポータルはこの標準のスキーマによりデー
タベース内の情報を同時に或いは個別に検索するように
している。従って、確実に且つ迅速に情報の収集を行う
ことができ、更に、重複した情報を収集するなどの無駄
な処理を省くことができる。

【００２５】本発明の第５の特徴は、利用者が、ネット
ワークに接続した端末を用いて、ネットワーク上に点在
するサイトのデータベースを検索して商品やサービスの
特徴情報を収集し、収集した情報を元にこの情報の提供
者に対して商品の発注を行う電子商取引システムであっ
て、前記サイトは、利用者の検索スキーマが標準スキー
マであるか判定し、前記検索スキーマが標準スキーマで
ない場合は、前記検索スキーマを所定のルールに従って
標準スキーマに変換するオントロジ変換機能を有するこ
とを特徴とする。

【００２６】本発明の第５の特徴によれば、スキーマが
異なる情報やカテゴリが異なる情報も確実に検索でき
る。

【００２７】本発明の第６の特徴は、ネットワーク上の
情報源からスキーマを収集し、収集したスキーマをもと
に前記所定のルールを更新し、収集した前記スキーマと
前記ルールを元に標準スキーマを生成するポータルエー
ジェントを有し、前記端末は、前記ポータルエージェン
トが生成した前記標準スキーマを取り込み、この標準ス
キーマによってポータルサイトに問合せを行うことを特
徴とする。

【００２８】本発明の第６の特徴によれば、ポータルエ
ージェントを備えることで、標準スキーマのルールセッ
トを管理することができ、また、端末は常に最新のルー
ルセットを用いることができ、スキーマの多様化等の変
化に対応することができる。

【発明の実施の形態】以下、本発明の実施形態について
図面を用いて説明する。

【００２９】図１は本発明に係る情報検索システム及び
電子商取引システムの一実施例を示す概略構成図であ
る。

【００３０】図１に示すように、ネットワーク上に売主
などのＩＰ（情報提供者）４０ａ〜４０ｎが点在してい
る。消費者であるユーザは、端末１０に内蔵するブラウ
ザ１５等を用いてネットワークに参加し、ポータルサイ
トにアクセスしてＩＰが提供する各種情報を入手し、収
集した情報をもとにその情報の提供者であるＩＰに対し
て商品やサービス等の発注などを行う。

【００３１】端末１０は、情報の入手先を案内する情報
を格納したローカルＤＢ（データベース）１２を内蔵し
ている。このローカルＤＢ１２には、例えば、商品やサ
ービスのカテゴリ別にどのポータルサイトにアクセスす
れば良いかといったルーティング情報など、情報を入手
するための探索経路の指針となる情報が格納されてい
る。この情報は、例えば、取扱品目とそれに対応するポ
ータルサイトのアドレス（ＵＲＬ:Uniform Resource Lo
cators）及びカテゴリ情報などからなる。

【００３２】ローカルＤＢ１２内の情報は、端末１０の
メーカや販売店などが端末１０の出荷時に予めインスト
ールしておいても良いし、あるいは、ユーザがデータ入
力機能１１を用いて情報を逐次追加・更新しても良い。
また、後で説明するポータルエージェント５０からダウ
ンロードすることもできる。

【００３３】ここで説明する端末１０は、パソコンに限
らず、例えば、ＰＤＡ（Personal Digital Assistants
）や携帯電話等のモバイル端末や、双方向型の情報家
電、例えばセットトップ・ボックス（Set-top Box）な
ども想定される。

【００３４】ユーザから商品やサービス等の情報検索を
指示されたブラウザ１５は、データ参照機能１２を用い
てローカルＤＢ１２の情報を参照し、その情報を元にポ
ータルサイトに対して問合せを行う。もちろん、ユーザ
はローカルＤＢの情報に依存しないで、独自の判断でポ
ータルサイトにアクセスしても良い。また、ユーザが商
品、サービスの情報やＩＰの情報を既に掌握しているよ
うな場合には、直接ＩＰにアクセスしても良い。ここで
いうブラウザ１５は、例えば、ＸＭＬ言語（extensible
markup language）に対応した閲覧ソフトである。対応
する言語は、ＸＭＬ言語に限らないが、文字列に意味を
付加するような独自のタグを拡張できる言語が望まし
い。

【００３５】各ＩＰが提供する情報は、バーチカルポー
タル３０ａ〜３０ｘと呼ばれるポータルサイトに属性検
索用情報として集められている。尚、本明細書では、ジ
ャンル別のポータルサイトを意味するポータルサイトと
して「バーチカルポータル」という表現を使用する。こ
れには、検索エンジン等を備えた既存のポータルサイト
も含まれる。

【００３６】バーチカルポータルに集められる属性検索
用情報は、各ＩＰが必要に応じてバーチカルポータルに
登録しても良いし、バーチカルポータルが定期的にネッ
ト上に広がるＩＰから収集するようにしても良いが、刻
々と変化する商品やサービスの内容を一番良く知ってい
るのは、それぞれのＩＰ自身であるので、ＩＰがバーチ
カルポータルに情報を提供するのが望ましい。

【００３７】この属性検索用情報で使用されるスキーマ
は、バーチカルポータル毎に独自のもの、例えば、生産
地を表すスキーマとして、バーチカルポータル３０ｎは
「生産地方」、バーチカルポータル３０ｘは「産地」と
いうように、ポータル毎のスキーマであって良いし、各
ＩＰが提供するスキーマ、即ち各ＩＰごとに独自のスキ
ーマであっても良い。もちろん、各バーチカルポータル
で同一のスキーマ（例えば「産地」に統一）を使用する
ようにしても構わない。

【００３８】バーチカルポータル３０ｘは、ＩＰ４０ｅ
〜４０ｎが提供する属性検索用情報を格納する属性検索
用ＤＢ３３ｘ、スキーマの差異を揃えるオントロジ変換
機能３１ｘ、属性検索用ＤＢ３３ｘを参照するデータ参
照機能３２ｘを備えている。

【００３９】オントロジ変換機能３１ｘは、予め策定さ
れたオントロジ変換のルールセット５５に基づいて処理
を行う。ここでオントロジとは、基本概念や語彙の集合
のことをいい、本明細書ではスキーマ間の概念関係のこ
とを表す。

【００４０】また、ネット上に点在するバーチカルポー
タル３３ａ〜３３ｎを束ねる役割をする一般ポータル２
０と呼ぶポータルサイトがあり、この一般ポータル２０
は、各バーチカルポータルのもつ属性検索用情報を集約
して（データの重複等を揃えて）属性検索用ＤＢ２３に
格納する情報共有機能２４と、スキーマの差異を標準ス
キーマに揃えるオントロジ変換機能２１、属性検索用Ｄ
Ｂ２３を参照するデータ参照機能２２とを備えている。
また、情報共有機能２４は、単に属性検索用データを集
約するフィルターとしての機能だけではなく、オントロ
ジ変換機能２１によりバーチカルポータル毎のスキーマ
の差異を標準スキーマに揃えた上で属性検索用データを
属性検索用ＤＢ２３に格納する。例えば、「生産地方」
「生産地」「産地」....というようにバーチカルポータ
ル毎に異なるスキーマを上位概念化した標準スキーマ
「産地」に揃える。つまり、バーチカルポータルごとの
スキーマの違いを吸収するのである。これによって、あ
たかも一つのデータベースのように扱うことができる。

【００４１】一般ポータル２０に集められる属性検索用
情報は、各バーチカルポータル３３ａ〜３３ｎが必要に
応じて一般ポータル２０に登録しても良いし、一般ポー
タル２０が定期的にネット上に点在するバーチカルポー
タル３３ａ〜３３ｎから収集するようにしても良い。

【００４２】一般ポータル２０内のオントロジ変換機能
２１とバーチカルポータル３０ｘ内のオントロジ変換機
能３１ｘは、予め策定されたオントロジ変換のルールセ
ット５５に基づいて処理を行う。このルールセット５５
は、ポータルエージェント５０が保有している。

【００４３】このポータルエージェント５０は、各バー
チカルポータル３０ａ〜３０ｎやＥＰＧ６０の情報を収
集する情報収集機能５４、収集した情報をルールセット
５５に反映させ、且つ、ユーザの端末１０のメニュー画
面用の標準スキーマや情報源のアドレス等を生成するオ
ントロジ変換機能５１、ユーザの端末１０に於ける検索
結果の表示フォーマットを規定する表示フォーマットセ
ット５６、標準スキーマや情報源のアドレス及び表示フ
ォーマット等のデータをポータルエージェント内のデー
タベース５３に蓄えるデータ蓄積機能５８、データベー
ス５３に蓄積した情報を端末１０等に伝送する出力手段
５９を備えている。また、データベース５３には上記デ
ータ以外にも、例えば、広告主７０が提供する広告用の
データなども蓄積することができ、これらの情報をユー
ザの端末１０などに配信することもできる。尚、ポータ
ルサイトで電子配信（ダウンロード）を行うサイトを特
にダウンロードサイトと呼び、両者を含めてサイトと呼
ぶ。

【００４４】図２は本発明に係る情報検索システム及び
電子商取引システムのデータの流れの概念を説明するた
めのイメージ図であり、図３はその流れを表したフロー
チャートである。

【００４５】サーバ１は、各データベース１〜３から予
め情報を収集する。即ち、データベース１からスキーマ
１を収集し（Ｓ0311）、データベース２からスキーマ２
を収集し（Ｓ0312）、データベース３からスキーマ３を
収集する（Ｓ0313）。これらの各スキーマから標準スキ
ーマを生成して（Ｓ0314）、内部のデータベースに保存
する（Ｓ0315）。

【００４６】クライアントは、予めサーバ１から標準ス
キーマをダウンロードし（Ｓ0301）、ユーザからの質問
をもとに標準スキーマに則って標準クエリーを生成し
（Ｓ0302）、サーバ２にアクセスする（Ｓ0303）。

【００４７】アクセスを受けた（Ｓ0321）サーバ２は、
オントロジ変換機能によってデータベースごとのクエリ
ー１〜３を発行し、データベースごとにリザルト１〜３
を回収する（Ｓ0322〜Ｓ034）。回収したリザルト１〜
３をもとに標準リザルトに変換し（Ｓ0325）、この標準
リザルトを端末に送る（Ｓ0326）。

【００４８】クライアントは、サーバ２から受取った標
準リザルトを表示フォーマットセットによって表示する
ことでユーザに回答する（Ｓ0304）。

【００４９】ここで、サーバ１とサーバ２は別々の機器
構成でも良いし、また、同一機器内に両方の機能を組み
込んでも良い。

【００５０】これによって、ユーザが指定する標準クエ
リーをネットワーク上の各データベースに対応したクエ
リーに変換して、各データベースを同時に或いは個別に
検索するようにしたため、従来のデータベースのスキー
マ等を変更しなくても、スキーマが異なるデータベース
を確実に検索できる。また、検索結果を所定の標準形式
に揃えてユーザに返すようにしているため、容易に比較
・検討することができる。

【００５１】次に、本発明の実施例を図面に基づいて説
明する。

【００５２】（第１実施例）図４は本実施例の問合せ処
理に関する構成図であり、図６はそれに対応する流れ図
である。

【００５３】ここで、データベース３３ａ〜３３ｎは異
なるスキーマ属性からなるデータベースである。例え
ば、「産地」という属性を示すスキーマとして、データ
ベース３３ａは「生産地域」、データベース３３ｂは
「生産地」、データベース３３ｎは「製造地」であると
する。

【００５４】ポータルエージェント５０は、標準スキー
マを生成するか判断し（Ｓ0606）、生成する場合には、
各データベース３３ａ〜３３ｎから情報を収集して（Ｓ
0607）スキーマ管理情報５５を更新すると共に標準スキ
ーマを生成し、生成した標準スキーマと情報源である各
データベース３３ａ〜３３ｎのアドレスを保存する（Ｓ
0608）。一般ポータル２０へスキーマ管理情報５５を送
る（Ｓ0609）。

【００５５】ユーザ１は、端末１０をネットワークに接
続し、ポータルエージェント５０から標準スキーマと各
データベース３３ａ〜３３ｎのアドレスをダウンロード
して端末１０内のローカルＤＢ１２に保存する（Ｓ060
2）。既に最新の情報がダウンロード済みの場合など、
必要がなければダウンロードしなくても良い。

【００５６】ユーザ１は、メニュー画面の中から、探し
ている商品やサービスのカテゴリを指定する。例えば
「地方の特産品」という指定をする。ここでメニュー画
面に表示するデータは、ポータルエージェント５０から
ダウンロードした情報である。

【００５７】次にユーザ１は、提供する商品やサービス
の情報をネットワークの中から探すかどうか判断する。
この判断は、ユーザ自身が経験則に基づいて判断しても
良いし、端末１０内のローカルＤＢ１２の情報に従って
も良い。

【００５８】商品やサービスの情報をネットワークの中
から探す場合、標準の検索用スキーマを指定して一般ポ
ータル２０にアクセスする（Ｓ0603）。検索用のスキー
マとして、例えば、「産地＝新潟」のように指定する。

【００５９】端末１０からのアクセスを受けた（Ｓ061
1）一般ポータル２０は、端末１０から送られてきたカ
テゴリの標準のスキーマ、日本酒の「産地」を、スキー
マ管理情報５５に従ってデータベースごとのクエリーに
オントロジ変換して、各データベースを検索する（Ｓ06
12〜Ｓ0614）。例えば、データベース３３ａを検索する
クエリーとして「生産地域＝新潟」を生成し、データベ
ース３３ｂを検索するクエリーとして「生産地＝新潟」
を生成し、データベース３３ｎを検索するクエリーとし
て「製造地＝新潟」を生成して、それぞれ検索を行う。
その後、各々のデータベース３３ａ〜３３ｎから検索結
果を得て（Ｓ0615〜Ｓ0617）、その結果を標準形式に変
換して端末１０に返す（Ｓ0618）。

【００６０】端末１０は、一般ポータル２０から受取っ
た標準形式の情報を表示フォーマットセットによって表
示することでユーザ１に回答する（Ｓ0604）。

【００６１】次に、以上説明した問合せ処理に対応する
回答処理について説明する。

【００６２】図５は図４の問合せ処理に対応する回答処
理に関する構成図であり、図７はその流れ図である。

【００６３】ポータルエージェント５０は、標準の表示
フォーマット、即ちスタイルシートを生成する場合には
（Ｓ0708）、各データベース３３ａ〜３３ｎから情報を
収集して（Ｓ0709）ＤＴＤ管理情報５６を更新すると共
に検索結果表示用の標準表示フォーマット５７を生成し
（Ｓ0710）、この情報を保存する（Ｓ0711）。また、必
要に応じて一般ポータル２０へＤＴＤ管理情報５６を送
る（Ｓ0712〜Ｓ0713）。ここで、ＤＴＤ（Document Typ
e Definition）とは、文書型定義のことで、表現方法の
指定や文章中の文字列に意味を付加するような独自のタ
グを拡張できる。この機能を利用して、標準表示用のＸ
ＭＬ文書の表示形式を定義し、スキーマの違いなどを吸
収して異なるデータも比較できるように表示する。例え
ば、検索結果を「産地」というスキーマで統一して分類
表示できるようにする。

【００６４】端末１０は、標準フォーマットによる表示
をしていない場合には（Ｓ0701）、ポータルエージェン
ト５０から標準フォーマットをダウンロードした上で
（Ｓ0704）、一般ポータルに対して問合せのアクセスを
行う（Ｓ0705）。

【００６５】ユーザからのアクセスを受けた（Ｓ0715）
一般ポータル２０は、各データベース３３ａ〜３３ｎの
それぞれ検索を行う。その後、各々のデータベース３３
ａ〜３３ｎからそれぞれ検索結果を得て（Ｓ0716）、そ
の各々の結果をＤＴＤ管理情報５６に従って標準表示用
のＸＭＬ文書に変換する（Ｓ0717）。標準フォーマット
に変換した各標準表示用ＸＭＬ文書を端末１０に返す
（Ｓ0718）。

【００６６】端末１０は、一般ポータル２０から受取っ
た（Ｓ0706）標準形式の情報を、表示フォーマットセッ
トによって表示することでユーザ１に回答する（Ｓ070
2）。

【００６７】（第２実施例）図８は本実施例の問合せ処
理に関する構成図であり、図１０はそれに対応する流れ
図である。また、図９は回答処理に関する構成図であ
り、図１１はその流れ図である。

【００６８】ここで、図８において、データベース３３
ａ〜３３ｎは同一又は類似のスキーマ属性からなるデー
タベースである。例えば、「産地」という属性を示すス
キーマとして、データベース３３ａ〜３３ｎは全て「生
産地域」又はその類似（生産地域グループ）であるとす
る。

【００６９】ポータルエージェント５０の処理、及び、
ユーザ１側の端末１０の処理については、第１実施例と
同様である。

【００７０】例えば、「産地＝新潟」のようにしてユー
ザからのアクセスを受けた（Ｓ1013）一般ポータル２０
は、属性情報共有機能２４によって同一又は類似の属性
情報を有するデータベースを選択する（Ｓ1014）。この
場合、データベース３３ａ〜３３ｎが選択される。端末
１０から送られてきた標準のスキーマ「産地＝新潟」
を、スキーマ管理情報５５（図８）に従ってデータベー
スごとのクエリーにオントロジ変換し、各データベース
を検索する（Ｓ1015）。この場合、クエリー「生産地域
グループ＝新潟」に変換してデータベースを検索して検
索結果を得る（Ｓ1016）。この処理を検索するデータベ
ースの数だけ繰り返す（Ｓ1017）。

【００７１】続いて、回答処理（Ｓ1018）を行う。図１
１を以って回答処理の具体例を説明する。全てのデータ
ベースの検索が終わったら（Ｓ1115）、その各データベ
ースごとの結果をＤＴＤ管理情報５６（図９）に従って
標準形式に変換し（Ｓ1116）、更に変換した結果をソー
ト・マージして（Ｓ1117）端末１０に返す（Ｓ1118）。

【００７２】端末１０は、一般ポータル２０から受取っ
た標準形式の情報を表示フォーマットセットによって表
示することでユーザ１に回答する（Ｓ1106）。

【００７３】その他は、図７とほぼ同様である。

【００７４】（第３実施例）第１乃至第２実施例との大
きな違いは、端末がアクセスするサーバはバーチカルポ
ータル３０であるということ、バーチカルポータル３０
は内部ＤＢ３３にＩＰ４０ａ〜４０ｎが提供する情報を
保有していること、ポータルエージェントから供給され
るアドレス等の情報はバーチカルポータルを経由して端
末に送られるということである。尚、バーチカルポータ
ル３０は各ＩＰが提供する情報を変換しないでそのまま
の形で内部ＤＢ３３に蓄積する。

【００７５】図１２は本実施例の問合せ処理に関する構
成図であり、図１３はそれに対応する流れ図である。

【００７６】ここで、ＩＰ４０ａ〜４０ｎはユーザ１の
使う端末１０とは異なる言語からなる情報を提供するＩ
Ｐある。例えば、ＩＰ４０ａ〜４０ｎは「英語」であ
り、端末１０側は「日本語」であるとする。

【００７７】ポータルエージェント５０は、各ＩＰ４０
ａ〜４０ｎから情報を収集して（Ｓ1306〜Ｓ1308）スキ
ーマ管理情報５５を更新すると共に標準スキーマを生成
し、情報源のアドレスをバーチカルポータル３０へ送信
する（Ｓ1310）。バーチカルポータル３０はポータルエ
ージェント５０からデータの送信があった場合には、受
信処理を割り込ませる（Ｓ1319）。

【００７８】また、ＩＰ４０ａ〜４０ｎから情報の提供
があった場合にも、提供された情報を受信して内部ＤＢ
３３に蓄積する処理を随時割り込ませる（Ｓ1320）。こ
の内部ＤＢ３３には、ＩＰ４０〜ＩＰ４０ｎが提供する
最新の情報がそのままの形で蓄積されている。

【００７９】ユーザ１は、端末１０をネットワークに接
続し、バーチカルポータル３０から各情報源のアドレス
をダウンロードして端末１０内のローカルＤＢ１３に保
存する（Ｓ1301）。

【００８０】端末１０は、問合せ用のクエリーを生成し
て（Ｓ1302）、バーチカルポータル３０にアクセスする
（Ｓ1303）。ユーザが使用する言語、例えば、日本語で
生成されたクエリーが使われる。

【００８１】端末１０からのアクセスを受けた（Ｓ131
3）バーチカルポータル３０は、端末１０から送られて
きた日本語のスキーマを英語に翻訳して（Ｓ1314）、内
部ＤＢ３３を検索する（Ｓ1315）。内部ＤＢ３３から検
索結果を回収し（Ｓ1316）、その結果を標準形式に変換
して（Ｓ1317）端末１０に返す（Ｓ1318）。

【００８２】（第４実施例）本実施例の特徴は、ＩＰ４
０ａ〜４０ｎが異なるスキーマ属性からなる情報を提供
することである。例えば、「産地」という属性を示すス
キーマとして、ＩＰ４０ａは「生産地域」、ＩＰ４０ｂ
は「生産地」、ＩＰ４０ｎは「製造地」というスキーマ
の情報を提供する。

【００８３】図１４は本実施例の問合せ処理に関する構
成図であり、図１６はそれに対応する流れ図である。ま
た、図１５は回答処理に関する構成図であり、図１７は
その流れ図である。

【００８４】ポータルエージェント５０は、各ＩＰ４０
ａ〜４０ｎから情報を収集して（Ｓ1607）スキーマ管理
情報５５を更新すると共に標準スキーマを生成し、情報
源のアドレスをバーチカルポータル３０へ送信する（Ｓ
1608〜Ｓ1609）。バーチカルポータル３０はポータルエ
ージェント５０からデータの送信があった場合には、受
信処理を割り込ませる（Ｓ1319と同様）。

【００８５】また、ＩＰ４０ａ〜４０ｎから情報の提供
があった場合にも、提供された情報を受信して内部ＤＢ
３３に蓄積する処理を随時割り込ませる（Ｓ1320と同
様）。従って、この内部ＤＢ３３には、ＩＰ４０〜ＩＰ
４０ｎが提供する最新の情報がそのままの形で蓄積され
ている。

【００８６】ユーザ１は、端末１０をネットワークに接
続し、バーチカルエージェント３０から情報源のアドレ
スをダウンロードする（Ｓ1602）。

【００８７】端末１０は、例えば、「地域＝新潟」とい
う問合せ用のクエリーを生成して、バーチカルポータル
３０にアクセスする（Ｓ1603）。

【００８８】端末１０からのアクセスを受けた（Ｓ161
1）バーチカルポータル３０は、端末１０から送られて
きた標準のスキーマ「産地＝新潟」を、スキーマ管理情
報５６に従ってＩＰ４０ａに対応するクエリー「生産地
域＝新潟」、ＩＰ４０ｂに対応するクエリー「生産地＝
新潟」、ＩＰ４０ｎに対応するクエリー「製造地＝新
潟」にそれぞれオントロジ変換して、内部ＤＢ３３を検
索する（Ｓ1612〜Ｓ1614）。

【００８９】次に端末に全ての結果を送る（Ｓ1618）。

【００９０】図１５をもとに回答処理を具体的に説明す
る。回答処理に移ると、検索結果をＤＴＤ管理情報５６
（図１５）に従って標準表示用のＸＭＬ文書に変換する
（Ｓ1716）。標準フォーマットに変換した各標準表示用
ＸＭＬ文書を端末１０に返す（Ｓ1717）。

【００９１】（第５実施例）第４実施例との違いは、Ｉ
Ｐ４０ａ〜４０ｎが同一のスキーマ属性からなる情報を
提供することである。例えば、「産地」という属性を示
すスキーマとして、ＩＰ４０ａ〜４０ｎは全て「生産地
域」というスキーマの情報を提供する。

【００９２】図１８は本実施例の問合せ処理に関する構
成図であり、図２０はそれに対応する流れ図である。ま
た、図１９は回答処理に関する構成図であり、図２１は
その流れ図である。

【００９３】図１８において、ユーザ１は、端末１０を
ネットワークに接続し、バーチカルポータル３０から情
報源のアドレスをダウンロードする（Ｓ2002）。

【００９４】端末１０は、例えば、「地域＝新潟」とい
う問合せ用のクエリーを生成して、バーチカルポータル
３０にアクセスする（Ｓ2003）。

【００９５】ユーザからのアクセスを受けた（Ｓ2013）
バーチカルポータル３０は、データベースを選択して
（Ｓ2014）、端末１０から送られてきた標準のスキーマ
「産地＝新潟」を、スキーマ管理情報５６に従って各Ｉ
Ｐに応じたクエリーにオントロジ変換し（Ｓ2015）、内
部ＤＢ３３を検索する（Ｓ2016）。この場合、クエリー
「生産地域＝新潟」に変換する。この処理を検索するデ
ータベースの数だけ繰り返す（Ｓ2017）。次に、端末１
０にすべての検索結果を送る（Ｓ2018）。

【００９６】図１９をもとに回答処理を具体的に説明す
る。回答処理に移ると、ＤＴＤ管理情報５６（図１９）
に従って、検索結果を標準形式に変換し（Ｓ2116）、更
に変換した結果をソート・マージして（Ｓ2117）端末１
０に返す（Ｓ2118）。

【００９７】（第６実施例）本実施例の特徴は、端末が
アクセスするサーバは一般ポータル２０であるというこ
と、一般ポータル２０は内部ＤＢ２３に、バーチカルポ
ータル３０ａ〜３０ｎが保有する属性検索用の情報を取
り込んでいるということである。この属性検索用の情報
を取り込む際には、情報共有機能２４は、単に属性検索
用データを集約するフィルターとしての機能だけではな
く、バーチカルポータル毎のスキーマの差異を標準スキ
ーマにオントロジ変換した上で属性検索用データを属性
検索用ＤＢ２３に格納する。

【００９８】図２２及び図２４は本実施例の問合せ処理
に関する構成図であり、図２３及び図２５は回答処理に
関する構成図である。尚、本実施例の処理内容は、ほぼ
図６〜７及び図１０〜１１のフローチャートの処理に対
応するので、フローチャートは省略する。

【００９９】ポータルエージェント５０は、各バーチカ
ルポータル３０ａ〜３０ｎから情報を収集して、スキー
マ管理情報５５を更新すると共に標準スキーマを生成
し、情報源のアドレスを一般ポータル２０へ送信する。
一般ポータル２０はポータルエージェント５０からデー
タの送信があった場合には、受信処理を割り込ませる
（Ｓ1319と同様）。

【０１００】また、バーチカルポータル３０ａ〜３０ｎ
から情報の提供があった場合にも、提供された情報を受
信して内部ＤＢ３３に蓄積する処理を随時割り込ませる
（Ｓ1320と同様）。従って、この内部ＤＢ２３には、バ
ーチカルポータル３０ａ〜３０ｎが保有する最新の情報
が蓄積されている。

【０１０１】ユーザ１は、端末１０をネットワークに接
続し、一般ポータル２０から情報源のアドレスをダウン
ロードする。

【０１０２】端末１０は、例えば、「地域＝新潟」とい
う問合せ用のクエリーを生成して、一般ポータル２０に
アクセスする。

【０１０３】端末１０からのアクセスを受けた一般ポー
タル２０は、端末１０から送られてきた標準のスキーマ
「産地＝新潟」を、スキーマ管理情報５５（図２２、図
２４）に従ってバーチカルポータル３０ａ〜３０ｎに対
応するクエリーにオントロジ変換して、内部ＤＢ２３を
検索する。

【０１０４】検索結果をＤＴＤ管理情報５６（図２３、
図２５）に従って標準表示用のＸＭＬ文書に変換し、標
準フォーマットに変換した各標準表示用ＸＭＬ文書を端
末１０に返す。

【０１０５】（第７実施例）本実施例の特徴は、図２６
に示すように、端末とポータルサイト（一般ポータルあ
るいはバーチカルポータル）との間で交わされる電文に
識別子を設けたことである。端末１０は、標準スキーマ
を用いてアクセスする場合にはその旨の符号をこの識別
子フィールドに設定してアクセスする。これにより、ポ
ータルサイト側は、この識別子を参照することで、端末
のスキーマが標準のスキーマであるかどうか認識するこ
とができる。

【０１０６】図２７に処理のフローチャートを示す。

【０１０７】端末１０からのアクセスを受けた（Ｓ270
1）ポータルサイトは、端末１０のスキーマが標準のス
キーマであるかどうか判定する（Ｓ2702）。

【０１０８】標準のスキーマである場合には、そのまま
データベースを検索し（Ｓ2703）、標準のスキーマでな
い場合には、端末から受けた情報を標準のスキーマに変
換して（Ｓ2706）データベースを検索し（Ｓ3708）、検
索結果のＸＭＬ文書を逆変換して、つまり通常の文書デ
ータにして端末に送る（Ｓ2710）。

【０１０９】（第８実施例）本実施例の特徴は、図２８
及び図２９に示すように、ユーザ情報の認証と課金の決
済処理を設けたことである。

【０１１０】端末１０のメーカ２は、端末にＩＣカード
１７ａと登録用紙を添付して出荷する。あるいは、販売
店がＩＣカード１７ａと登録用紙１８を添付して販売し
てもよい。

【０１１１】端末１０を購入したユーザ１は、記入した
登録用紙１８とＩＣカード１７ａを持って銀行３へ行っ
て、口座を開設やクレジット加入等の必要な手続きをと
る。口座の情報等が銀行３のＤＢ３ａとＩＣカード１７
ａに登録される。必要があれば、家族カードなどの追加
カード１７ｂも作成する。

【０１１２】次に、ユーザ１は、ＩＣカード１７ａを端
末１０に差し込み、ポータルエージェント５０にアクセ
スする。ＩＣカードの内容は、銀行が発行する秘密鍵と
ポータルエージェントの公開鍵で暗号化されている（銀
行とポータルエージェントとが対応づけられている）。

【０１１３】ポータルエージェント５０は、端末１０の
ハードウェア情報やＩＣカード１７ａに記録されている
銀行の情報などを内部ＤＢに登録し、ユーザＩＤ，パス
ワード、メールアドレスなどを発行してユーザ１に送信
する。この時、サーバの秘密鍵とユーザの公開鍵で暗号
化して送信する。これによって、ポータルエージェント
と端末とを対応づける。

【０１１４】端末１０は、受信したユーザＩＤやパスワ
ードなどをＩＣカード１７ａに書きこむ。これ以降、ユ
ーザ１は、このＩＣカード１７ａを用いてポータルエー
ジェントからユーザ認証を得て、電子商取引に参加す
る。商品やサービスの情報を入手し、ＩＰに対して発注
処理を行い、支払い等の課金処理を行う際には、ポータ
ルエージェント５０にアクセスして決済処理を行う。

【０１１５】（第９実施例）本実施例の特徴は、図３０
及び図３１に示すように、ユーザ情報の認証と課金の決
済処理を設けたことである。

【０１１６】図３０に示した端末１０は、例えば、セッ
トトップ・ボックス（Set-top Box）等の双方向型の接
続装置であって、ポータルエージェント５０の接続して
いる。ユーザ１は、リモコン１９を操作してこの端末１
０を操作することができる。

【０１１７】端末１０には、オンライン・ショッピング
やＥＰＧのための双方向通信機能、インターネット接続
機能などを搭載している。ＥＰＧの機能としては、番組
のタイトルや開始時刻の情報、あらすじなどの詳細情報
を画面で見ることができ、更に映画やスポーツ、音楽、
ニュースなど特定ジャンルのみを画面上に表示して番組
検索を容易に行うことができる。

【０１１８】図３１に示すように、従来、Ｗｅｂ型の情
報（データやプログラムなど）はパソコン型の端末で取
扱い、放送型の情報（ＡＶデータやプログラムなど）は
受信専用のＴＶ型の端末で取り扱っていたのを。ポータ
ルエージェントによってスキーマや表示形式の違いを吸
収することで、ユーザは図示するような端末により双方
の型の情報を同時に取扱うことができる。

【０１１９】以上、第１乃至第９実施例をもとに説明し
たように、ユーザが指定する標準クエリーをネットワー
ク上の各データベースに対応したクエリーに変換して、
各データベースを同時に或いは個別に検索するようにし
たため、従来のデータベースのスキーマ等を変更しなく
ても、スキーマが異なるデータベースを確実に検索でき
る。また、検索結果を所定の標準形式に揃えてユーザに
返すようにしているため、容易に比較・検討することが
できる。

【０１２０】また、バーチカルポータルは、ユーザが指
定する標準スキーマを検索するデータに対応するスキー
マに変換して、データベース内の情報を同時に或いは個
別に検索するようにしたため、従来のデータベースのス
キーマ等を変更しなくても、スキーマが異なる情報を確
実に検索できる。

【０１２１】また、ネット上のポータルサイトにある情
報を予め集約し標準のスキーマに変換してデータベース
化した一般ポータルを備え、利用者は、標準スキーマに
よってこの一般ポータルに対して問合せを行い、一般ポ
ータルはこの標準のスキーマによりデータベース内の情
報を同時に或いは個別に検索するようにしている。従っ
て、確実に且つ迅速に情報の収集を行うことができ、更
に、重複した情報を収集するなどの無駄な処理を省くこ
とができる。

【０１２２】また、スキーマが異なる情報やカテゴリが
異なる情報も確実に検索できる。従って、ＥＰＧの情報
などを受信して、異なった提供者による番組の検索など
を同時に行うこともできる。

【０１２３】以上、本発明の実施形態について詳細に説
明したが、本発明は本実施例に限定されず、本発明の主
旨を逸脱しない範囲において、種々の改良や変更を成し
得るであろう。

【０１２４】本発明には、第１実施例乃至第９実施例に
記載のシステム、及びそれらに対応する情報検索方法、
情報検索プログラム、電子商取引方法、電子商取引プロ
グラム、端末装置、ポータルエージェント、一般ポータ
ル、サイト等が含まれる。

【０１２５】従って、本発明はこの開示から妥当な特許
請求の範囲に係わる発明特定事項によってのみ限定され
るものでなければならない。

【０１２６】

【発明の効果】本発明によれば、ユーザが指定する標準
クエリーをネットワーク上の各データベースに対応した
クエリーに変換して、各データベースを同時に或いは個
別に検索するようにしたため、従来のデータベースのス
キーマ等を変更しなくても、スキーマが異なるデータベ
ースを確実に検索できる。また、検索結果を所定の標準
形式に揃えてユーザに返すようにしているため、容易に
比較・検討することができる。

【０１２７】また、バーチカルポータルは、ユーザが指
定する標準スキーマを検索するデータに対応するスキー
マに変換して、データベース内の情報を同時に或いは個
別に検索するようにしたため、従来のデータベースのス
キーマ等を変更しなくても、スキーマが異なる情報を確
実に検索できる。

【０１２８】また、ネット上のポータルサイトにある情
報を予め集約し標準のスキーマに変換してデータベース
化した一般ポータルを備え、利用者は、標準スキーマに
よってこの一般ポータルに対して問合せを行い、一般ポ
ータルはこの標準のスキーマによりデータベース内の情
報を同時に或いは個別に検索するようにしている。従っ
て、確実に且つ迅速に情報の収集を行うことができ、更
に、重複した情報を収集するなどの無駄な処理を省くこ
とができる。

【０１２９】また、スキーマが異なる情報やカテゴリが
異なる情報も確実に検索できる。従って、ＥＰＧの情報
などを受信して、異なった提供者による番組の検索など
を同時に行うこともできる。

【０１３０】また、ポータルエージェントをユーザ認証
エージェント及び決済エージェントとして機能させるこ
とで、電子商取引の信頼性や操作性が向上する。

【図面の簡単な説明】

【図１】本発明に係る電子商取引システムの一実施例を
示す概略構成図。

【図２】本発明に係る電子商取引システムの処理動作の
概念を示すイメージ図。

【図３】本発明に係る電子商取引システムの処理動作例
を示すフローチャート。

【図４】第１実施例の問合せ処理の概略を表す概略構成
図。

【図５】第１実施例の回答処理の概略を表す概略構成
図。

【図６】第１実施例の問合せ処理の流れを表すフローチ
ャート。

【図７】第１実施例の回答処理の流れを表すフローチャ
ート。

【図８】第２実施例の問合せ処理の概略を表す概略構成
図。

【図９】第２実施例の回答処理の概略を表す概略構成
図。

【図１０】第２実施例の問合せ処理の流れを表すフロー
チャート。

【図１１】第２実施例の回答処理の流れを表すフローチ
ャート。

【図１２】第３実施例の問合せ処理の概略を表す概略構
成図。

【図１３】第３実施例の問合せ処理の流れを表すフロー
チャート。

【図１４】第４実施例の問合せ処理の概略を表す概略構
成図。

【図１５】第４実施例の回答処理の概略を表す概略構成
図。

【図１６】第４実施例の問合せ処理の流れを表すフロー
チャート。

【図１７】第４実施例の回答処理の流れを表すフローチ
ャート。

【図１８】第５実施例の問合せ処理の概略を表す概略構
成図。

【図１９】第５実施例の回答処理の概略を表す概略構成
図。

【図２０】第５実施例の問合せ処理の流れを表すフロー
チャート。

【図２１】第５実施例の回答処理の流れを表すフローチ
ャート。

【図２２】第６実施例の問合せ処理の概略を表す概略構
成図。

【図２３】第６実施例の回答処理の概略を表す概略構成
図。

【図２４】第６実施例の問合せ処理の概略を表す概略構
成図。

【図２５】第６実施例の回答処理の概略を表す概略構成
図。

【図２６】第７実施例の問合せ処理の概略を表す概略構
成図。

【図２７】第７実施例の問合せ処理の流れを表すフロー
チャート。

【図２８】第８実施例の問合せ処理の認証処理及び決済
処理を表す概略構成図。

【図２９】第８実施例の問合せ処理の認証処理及び決済
処理を表す概略構成図。

【図３０】第９実施例の問合せ処理の放送受信処理を表
す概略構成図。

【図３１】第９実施例の問合せ処理の放送受信処理を表
す概略構成図。

【図３２】従来の典型的なネットワークの一例を示す概
略構成図。

【符号の説明】

１....ユーザ １０....端末 １２....データ参照機能 １３....ローカルＤＢ（データベース） １４....データ入力処理 １５....ブラウザ １６....課金処理 １７....ＩＣカード ２０....一般ポータル ２１....オントロジ変換処理 ２２....データ参照処理 ２３....属性検索用ＤＢ ２４....情報共有機能 ３０ａ，３０ｂ，３０ｎ，３０ｘ....バーチカルポータ
ル ３１ｘ....オントロジ変換処理 ３２ｘ....データ参照処理 ３３ａ，３０ｂ，３０ｎ，３０ｘ....属性検索用ＤＢ ４０ａ〜４０ｇ，４０ｎ....ＩＰ ５０....ポータルエージェント ５１....オントロジ変換処理 ５４....情報収集機能 ５５....オントロジ変換ルールセット ５６....表示フォーマットセット ５８....でーた蓄積機能 ５９....データ出力機能 １１０....端末 １３０ａ，１３０ｂ....ポータルサイト １４０ａ〜１４０ｆ....ＩＰ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 金子 格 東京都渋谷区代々木４丁目33番10号 株式 会社アスキー内 (72)発明者 柴本 猛 神奈川県横浜市神奈川区守屋町３丁目12番 地 日本ビクター株式会社内 (72)発明者 阿部 良三 神奈川県横浜市神奈川区守屋町３丁目12番 地 日本ビクター株式会社内 (72)発明者 田中 美昭 神奈川県横浜市神奈川区守屋町３丁目12番 地 日本ビクター株式会社内 Ｆターム(参考） 5B049 AA01 BB11 CC05 DD04 EE05 EE23 GG02 5B075 KK07 ND20 NK02 PP26 PP30 5B089 GA11 GA21 GA25 GB04 HA00 KB07 KB09

Claims (9)

【特許請求の範囲】
1. 【請求項１】 ネットワーク上に点在するデータベース
   を検索して情報の収集を行う情報検索システムであっ
   て、 前記各データベースからスキーマを収集し、収集した前
   記スキーマを標準スキーマに変換して端末に供給する第
   １のサーバと、 前記標準スキーマをもとに標準クエリーを生成して問合
   せを行う端末と、 前記端末から送られる標準クエリーを前記各データベー
   スに対応するクエリーに変換して各データベースに対し
   て同時に問合せを行い、各データベースごとに返される
   リザルトを標準リザルトに変換して前記端末に返す第２
   のサーバーと、 を有することを特徴とする情報検索システム。
2. 【請求項２】 前記第１のサーバは、前記各データベー
   スのアドレスを収集し、収集した前記アドレスを前記端
   末に供給し、 前記端末は、供給された前記アドレスに基づいて問合せ
   先を決定することを特徴とする情報検索システム。
3. 【請求項３】 利用者が、ネットワークに接続した端末
   を用いて、ネットワーク上に点在するサイトのデータベ
   ースを検索して商品やサービスの特徴情報を収集し、収
   集した情報を元にこの情報の提供者に対して商品の発注
   を行う電子商取引システムであって、 前記利用者は、前記サイトに対して標準スキーマで問合
   せを行うことで前記商品の特徴情報の収集を行い、 前記サイトは、オントロジ変換機能により前記標準スキ
   ーマを、所定のルールに従って自サイトに対応するスキ
   ーマに変換することを特徴とする電子商取引システム。
4. 【請求項４】 利用者が、ネットワークに接続した端末
   を用いて、ネットワーク上に点在するサイトのデータベ
   ースを検索して商品の特徴情報を収集し、収集した情報
   を元にこの情報の提供者に対して商品の発注を行う電子
   商取引システムであって、 前記各サイトのデータベースに格納されている情報を集
   約し、且つ所定のルールに従って標準のスキーマに変換
   してデータベース化する情報共有機能とを有する一般ポ
   ータルサイトを有し、 前記利用者は、前記一般ポータルサイトに対して前記標
   準スキーマで問合せを行うことで前記商品の特徴情報の
   収集を行うことを特徴とする電子商取引システム。
5. 【請求項５】 利用者が、ネットワークに接続した端末
   を用いて、ネットワーク上に点在するサイトのデータベ
   ースを検索して商品やサービスの特徴情報を収集し、収
   集した情報を元にこの情報の提供者に対して商品の発注
   を行う電子商取引システムであって、 前記サイトは、利用者の検索スキーマが標準スキーマで
   あるか判定し、前記検索スキーマが標準スキーマでない
   場合は、前記検索スキーマを所定のルールに従って標準
   スキーマに変換するオントロジ変換機能を有することを
   特徴とする電子商取引システム。
6. 【請求項６】 請求項３乃至請求項５のいずれかに記載
   の電子商取引システムであって、 ネットワーク上の情報源からスキーマを収集し、収集し
   たスキーマをもとに前記所定のルールを更新し、収集し
   た前記スキーマと前記ルールを元に標準スキーマを生成
   するポータルエージェントを有し、 前記端末は、前記ポータルエージェントが生成した前記
   標準スキーマを取り込み、この標準スキーマによってサ
   イトに問合せを行うことを特徴とする電子商取引システ
   ム。
7. 【請求項７】 請求項６に記載の電子商取引システムで
   あって、 前記ポータルエージェントは、前記端末から送られる利
   用者情報を認証し、前記端末からの課金情報を決済する
   決済エージェントとしての機能を有することを特徴とす
   る電子商取引システム。
8. 【請求項８】 請求項３乃至請求項７のいずれかに記載
   の電子商取引システムにおいて標準スキーマにより問合
   せまたは発注を行うことを特徴とする端末装置。
9. 【請求項９】 請求項３乃至請求項７のいずれかに記載
   の電子商取引システムを構成するサイト。