(57)【要約】【課題】  ネットワーク上に公開されたコンテンツのうち、有用なコンテンツ、および有用なコンテンツを含むサイトの情報が容易に判断可能に表示することが可能なサイト情報表示システムを提供する。【解決手段】  ユーザー端末１０から条件を指定した閲覧要求があると、事業者サーバー３０は、条件に従ったコンテンツを抽出すると共に、あらかじめ記録したコンテンツ間のリンク情報を抽出して、ユーザー端末１０に返信する。ユーザー端末１０では、受信したコンテンツおよびリンク情報を元にコンテンツ間の関係を２次元グラフィックス表示する。【選択図】  図７
2006343827.tif 000002
【特許請求の範囲】
【請求項１】
ユーザー端末から事業者サーバーへの要求に基づいて、前記ユーザー端末の画面上に、コンピュータネットワーク上で公開されているサイト間の関係を表示するシステムであって、
前記ユーザー端末は、閲覧要求を前記事業者サーバーに送信する機能を有すると共に、前記事業者サーバーから受信したサイト間情報をグラフィックス表示する機能を有するものであり、
前記事業者サーバーは、サイトが保有するコンテンツ間のリンク情報を記録した流通管理データベースを有し、前記ユーザー端末からの要求に適合するコンテンツを保有するサイト間情報を前記流通管理データベースから抽出して、前記ユーザー端末に送信する機能を有するものであることを特徴とするサイト間関係表示システム。
【請求項２】
前記サイト間の関係は、サイトに保有されるコンテンツ間の参照関係であることを特徴とする請求項１に記載のサイト間関係表示システム。
【請求項３】
前記ユーザー端末は、サイト間情報と同一の画面に広告コンテンツを表示するものであることを特徴とする請求項１に記載のサイト間関係表示システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータネットワーク上のサイト間の関係を表示するための技術に関する。
【背景技術】
【０００２】
最近、インターネット技術やサービスの普及・高度化に伴い、個人間での情報流通コストが低下すると共に、利便性が向上した結果、コミュニティサイトや掲示板、Ｗｅｂｌｏｇ（個人が運営する日記サイトであり、略してＢｌｏｇとも呼ばれる。）といった、いわゆるＣ２Ｃ型のコンテンツ流通が活発になってきている。
【０００３】
Ｂｌｏｇサイトにおいては、コンテンツのサマリー情報をＲＳＳ（RDF Site Summary、Rich Site Summary、Really Simple Syndication等の略）という形式で記述し、公開することが一般に行われており、このＲＳＳをＲＳＳリーダーと呼ばれるクライアントアプリケーションを利用することで定期巡回し、追加・更新があったら、クライアントに通知を行うことが可能になっている。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記従来のＲＳＳリーダーでは、ＲＳＳを公開しているサイト単位で、お気に入りリストに登録しておき、更新チェックを行うことができるが、インターネット上のあらゆるサイトを対象にして、特定のトピックに関連する情報の更新状況を確認するようなことができない。また、上記従来のＲＳＳリーダーでは、コンテンツはリスト化されて提示されるのみであり、何がより信頼のおける情報であるか、また、自分にとって本当に必要な情報がどれかは、すぐにはわからない。そのため、更新チェックはできるが、そこから本当に必要な情報が何であるかを探索する作業においては、必ずしも効率的な情報提示ができていないという問題がある。
【０００５】
上記のような点に鑑み、本発明は、ネットワーク上に公開されたコンテンツのうち、有用なコンテンツ、および有用なコンテンツを含むサイトの情報が容易に判断可能に表示することが可能なサイト情報表示システムを提供することを課題とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するため、ユーザー端末から事業者サーバーへの要求に基づいて、前記ユーザー端末の画面上に、コンピュータネットワーク上で公開されているサイト間の関係を表示するシステムであって、前記ユーザー端末は、閲覧要求を前記事業者サーバーに送信する機能を有すると共に、前記事業者サーバーから受信したサイト間情報をグラフィックス表示する機能を有し、前記事業者サーバーが、サイトが保有するコンテンツ間のリンク情報を記録した流通管理データベースを有し、前記ユーザー端末からの要求に適合するコンテンツを保有するサイト間情報を前記流通管理データベースから抽出して、前記ユーザー端末に送信する機能を有するサイト間関係表示システムを提供する。
【発明の効果】
【０００７】
本発明によれば、ネットワーク上に公開されたコンテンツのうち、コンテンツ間、もしくはコンテンツを有するサイト間の情報が表示されるので、利用者が有用な情報を見つけるのに役立つことになる。
【発明を実施するための最良の形態】
【０００８】
（１．システム構成）
以下、本発明の実施形態について図面を参照して詳細に説明する。図１は、本発明に係るサイト間関係表示システムの構成図である。図１において、１０はユーザー端末、２０は広告主端末、３０は事業者サーバー、４０はネットワークである。なお、図１の例では、ユーザー端末１０、広告主端末２０共に１つずつしか示してないが、現実には、多数のユーザー端末１０、広告主端末２０がネットワーク４０に接続されている。
【０００９】
ユーザー端末１０の詳細を図２に示す。図２において、１１はコンテンツ閲覧処理部、１２はコンテンツ入力・編集処理部、１３はコンテンツＤＢ、１４はコンテンツ配信処理部、１５は入力装置、１６は出力装置である。ユーザー端末１０は、ユーザーが利用する端末装置であり、インターネット接続機能を持たせた汎用のコンピュータにより実現可能である。コンテンツ閲覧処理部１１は、インターネット上に誰がどんなコンテンツを公開しているかの情報（メタデータ）を取得して表示し、さらに、コンテンツ本体も取得して、表示、閲覧する機能を有するものであり、ＷｅｂブラウザおよびＲＳＳリーダーにより実現可能である。コンテンツ入力・編集処理部１２は、コンテンツを制作し、インターネット上に公開できるように、データを配備する機能を有している。コンテンツＤＢ１３は、コンテンツ入力・編集処理部１２により制作されたコンテンツを格納したデータベースである。コンテンツＤＢ１３には、格納されているコンテンツから生成されたメタデータ（＝サマリー情報、具体的にはＲＳＳファイル）も格納する。コンテンツ配信処理部１４は、コンテンツＤＢ１３に格納されたコンテンツ（例えば、ＨＴＭＬで作成されたＷｅｂページや各種ファイル群）およびメタデータを、他の端末から要求があった場合に、配信する機能を有しており、Ｗｅｂサーバーソフトウェアにより実現可能である。
【００１０】
広告主端末２０の詳細を図３に示す。図３において、２１は広告コンテンツ閲覧処理部、２２は広告コンテンツ入力・編集処理部、２３は広告コンテンツ配信処理部、２４は広告コンテンツＤＢ、２５は入力装置、２６は出力装置である。である。広告主端末２０は、一般のユーザーではなく、広告主が用いる端末装置であるが、ユーザー端末１０において扱われるコンテンツに代えて、広告コンテンツを扱う点において異なるが、その他は、ユーザー端末１０と同一である。
【００１１】
事業者サーバー３０の詳細を図４に示す。図４において、３１は流通情報収集処理部、３２は流通評価計算処理部、３３はメタデータ配信処理部、３４は流通管理データベース（以後「流通管理ＤＢ」と記す）である。事業者サーバー３０は、本発明のコンテンツ流通システムを運用する事業者がユーザー（コンテンツ制作者とコンテンツ閲覧者）および広告主にサービスを提供するためのサーバーコンピュータである。
【００１２】
流通情報収集処理部３１は、公開されているコンテンツのメタデータ、各コンテンツのリンク（参照）関係、各コンテンツの閲覧数等の情報を定期的に収集して流通管理ＤＢ３４に格納する機能を有している。なお、ユーザー端末１０のコンテンツ配信処理部１４がコンテンツＤＢ１３に格納されたメタデータを定期的に（あるいは、コンテンツ追加・更新時に）、事業者サーバー３０に配信する構成としても良いが、その場合は、流通情報収集処理部３１は、受信したメタデータを流通管理ＤＢ３４に格納する。
【００１３】
流通評価計算処理部３２は、流通管理ＤＢ３４に格納されている、流通状況を表す情報（各コンテンツへのアクセス数、コンテンツ間のリンク関係等の情報）を参照して、コンテンツおよびサイトの評価値を算出する機能を有している。また、広告のアクセス数から広告主に請求する広告料を算出する機能も有している。
【００１４】
メタデータ配信処理部３３は、コンテンツ閲覧者からの検索要求があった場合に、それに適合するメタデータをコンテンツ閲覧者に配信する機能を有している。また、この配信の際には、単なるメタデータのリストだけでなく、各メタデータの重要度を表す情報や分類を表す情報、あるいはリンク構造を表す情報も付加して配信する。
【００１５】
流通管理ＤＢ３４は、流通情報収集処理部３１が収集したコンテンツのメタデータ、メタデータ検索を実現するインデックス、各コンテンツへのアクセス数、各コンテンツのリンク情報、コンテンツを有するサイトの評価値等が記録されている。これらは、図５に示すようなテーブル構造により管理されている。図５に示すように、流通管理ＤＢ３４は、記事情報テーブル、サイト情報テーブル、広告主情報テーブル、リンク情報テーブル、アクセス情報テーブルによりデータ管理を行っている。なお、本実施形態では、コンテンツとして記事を扱う場合を想定しており、図５に示す記事情報テーブルは、コンテンツ情報に関するテーブルを示している。
【００１６】
（２．処理動作）
続いて、図１に示したシステムの処理動作について説明する。図１に示したシステムの処理は、メタデータ収集処理、メタデータ検索・配信・閲覧処理に分けられるが、まず、メタデータ収集処理について説明する。
【００１７】
（２．１．メタデータ収集処理）
メタデータ収集処理は、ユーザー端末１０のコンテンツＤＢ１４、および広告主端末２０の広告コンテンツＤＢ２４に格納されているＲＳＳファイルを、事業者サーバー３０の流通情報収集処理部３１が定期的（例えば１時間に１回）に巡回し収集することにより行う。あるいは、ユーザー端末１０のコンテンツ配信処理部１３、広告主端末２０の広告コンテンツ配信処理部２３が、それぞれ定期的に、もしくは、コンテンツ、広告コンテンツの追加・更新があったときに事業者サーバー３０にＲＳＳファイルを配信するようにしても良い。流通情報収集処理部３１は、収集したＲＳＳファイルを流通管理ＤＢ３４に格納する。そして、流通管理ＤＢ３４に格納されているＲＳＳファイルから所定の情報を抽出し、図に示したようなテーブル構造に合わせて格納する。これらのテーブル構造は検索用インデックスとしての役割を果たすことになる。
【００１８】
（２．２．メタデータ検索・配信・閲覧処理）
続いて、メタデータ検索・配信・閲覧処理について説明する。ユーザー端末１０のコンテンツ閲覧処理部１１は、事業者サーバー３０のメタデータ配信処理部３３に対して検索要求を出す処理を定期的に行っている。このコンテンツ閲覧処理部１１は、常駐型のアプリケーションプログラムにより実現され、登録されている検索要求に従って定期的（例えば１時間に１回）に検索処理を実行するものである。なお、コンテンツ閲覧処理部１１における検索処理は、キーワード、コンテンツ（のアドレス）、コンテンツ制作者サイト（のアドレス）のいずれかを指定して関連コンテンツ情報を取得するものとなっている。また、キーワード、コンテンツ（のアドレス）、コンテンツ制作者サイト（のアドレス）のいずれかを指定して関連コンテンツ制作者サイトを取得する機能も有している。
【００１９】
メタデータ配信処理部３３は、コンテンツ閲覧処理部１１からの検索要求に適合するメタデータの集合に加え、各メタデータの重要度を表す情報（コンテンツ制作者のランキング情報）や、分類を表す情報（メタデータに含まれる概要情報からテキスト分類処理し抽出）や、参照関係構造（抽出されたメタデータ集合の参照関係情報）、あるいはサイト同士の依存関係を表す情報も抽出する。そして、抽出した情報をユーザー端末１０に送信する。
【００２０】
ユーザー端末１０では、コンテンツ閲覧処理部１１が、受信したメタデータ情報を、ユーザーによって指定された表示形式に従って可視化表示する。
【００２１】
ここで、表示形式として参照関係表示が指定された場合の、検索から可視化表示までの処理を図６に示すフローチャートに従って説明する。まず、キーワードが入力されると（Ｓ１）、コンテンツ閲覧処理部１１は、入力されたキーワードを事業者サーバー３０に送信する。事業者サーバー３０では、コンテンツ閲覧処理部１１からキーワードを受信すると、メタデータ配信処理部３３が、受信したキーワードに対応した文書ベクトルを算出する（Ｓ２）。続いて、メタデータ配信処理部３３は、記事情報テーブルに含まれる記事の文書ベクトルとの類似度をベクトルの内積をとることにより算出し、この内積がある閾値以上となる記事集合を抽出する（Ｓ３）。文書ベクトルの算出、および、文書ベクトルの内積を求めることによる類似度の算出の具体的手法は、公知の技術であり、本実施形態では、例えば、特開２００２−２６９１０６号公報に開示されている手法を用いることができる。
【００２２】
そして、抽出した記事集合の記事更新時間とリンク情報テーブルから抽出されるリンク情報を、ユーザー端末１０に送信する。ユーザー端末１０では、コンテンツ閲覧処理部１１が、事業者サーバー３０から取得した記事更新時間およびリンク情報から２次元グラフィックスデータを作成して画面に表示する（Ｓ４）。この結果、ユーザー端末１０に表示される画面の様子を図７に示す。図７において、網掛けされた丸印で示したのは、コンテンツ（記事）であり、矢印は、コンテンツ間の参照関係を示している。矢印は、リンク元からリンク先に向かう方向に設定されている。また、図７の例では、下部に、３つの広告が示されている。これらは、広告主端末２０の広告コンテンツＤＢ２４から別途抽出された広告コンテンツである。このようにして、参照関係が表示されることになる。
【００２３】
また、事業者サーバー３０では、コンテンツ閲覧処理部１１から記事ＵＲＬを受信した場合には、メタデータ配信処理部３３が、受信した記事ＵＲＬに対応した記事の文書ベクトルを記事情報テーブルから抽出する（Ｓ５、Ｓ６）。文書ベクトルが抽出できたら、上記キーワードの場合と同様に、Ｓ３、Ｓ４における処理を行って参照関係表示を行う。また、事業者サーバー３０では、コンテンツ閲覧処理部１１からサイトＵＲＬを受信した場合には、メタデータ配信処理部３３が、受信したサイトＵＲＬに対応したサイトの文書ベクトルをサイト情報テーブルから抽出する（Ｓ７、Ｓ８）。文書ベクトルが抽出できたら、上記キーワード、記事ＵＲＬの場合と同様に、Ｓ３、Ｓ４における処理を行って参照関係表示を行う。
【００２４】
ここで、表示形式としてサイト依存関係表示が指定された場合の、検索から可視化表示までの処理を図８に示すフローチャートに従って説明する。まず、キーワードが入力されると、コンテンツ閲覧処理部１１は、入力されたキーワードを事業者サーバー３０に送信する。事業者サーバー３０では、コンテンツ閲覧処理部１１からキーワードを受信すると、メタデータ配信処理部３３が、受信したキーワードに対応した文書ベクトルを作成する。続いて、メタデータ配信処理部３３は、サイト情報テーブルに含まれるサイトの文書ベクトルとの類似度をベクトルの内積をとることにより算出し、この内積がある閾値以上となるサイト集合を抽出する（Ｓ１３）。そして、抽出したサイト集合に含まれる記事集合を抽出すると共に、リンク情報テーブルを参照し、サイト間に張られているリンクの方向と数を算出し、２次元画面データを作成し、ユーザー端末１０に送信する。ユーザー端末１０では、コンテンツ閲覧処理部１１が、受信した２次元グラフィックスデータを作成して画面に表示する（Ｓ１４）。
【００２５】
なお、上記Ｓ１４においては、リンクの方向を以下のようにして決定する。例えば、サイトＡからサイトＢへのリンク数がＸ、サイトＢからサイトＡへのリンク数がＹだった場合、ある一定の値Ｎを設定し、Ｘ＞Ｎであれば、サイトＡからサイトＢ向きのリンクあり、と判断し、Ｙ＞Ｎであれば、サイトＢからサイトＡ向きのリンクあり、と判断する。それ以外の場合は、サイトＡ、Ｂ間のリンク無しと判断される。
【００２６】
この結果、ユーザー端末１０に表示される画面の様子を図９に示す。図９においては、網掛けされた丸印で示したのは、サイトであり、矢印は、サイト間の参照関係を示している。矢印は、リンク元からリンク先に向かう方向に設定されている。両方向に向かう矢印は互いにリンク元およびリンク先となっている場合を示している。また、図９の例でも、下部に、３つの広告が示されている。このようにして、サイト依存関係が表示されることになる。
【００２７】
また、事業者サーバー３０では、コンテンツ閲覧処理部１１から記事ＵＲＬを受信した場合には、メタデータ配信処理部３３が、受信した記事ＵＲＬに対応した記事の文書ベクトルを記事情報テーブルから抽出する（Ｓ１５、Ｓ１６）。文書ベクトルが抽出できたら、上記キーワードの場合と同様に、Ｓ１３、Ｓ１４における処理を行ってサイト依存関係表示を行う。また、事業者サーバー３０では、コンテンツ閲覧処理部１１からサイトＵＲＬを受信した場合には、メタデータ配信処理部３３が、受信したサイトＵＲＬに対応したサイトの文書ベクトルをサイト情報テーブルから抽出する（Ｓ１７、Ｓ１８）。文書ベクトルが抽出できたら、上記キーワード、記事ＵＲＬの場合と同様に、Ｓ１３、Ｓ１４における処理を行ってサイト依存関係表示を行う。
【００２８】
（２．３．コンテンツの閲覧およびアクセス情報収集）
図７に示したような状態で、画面に表示されている参照関係から欲しいコンテンツのリンクをクリックすると、まず、コンテンツ閲覧処理部１１から事業者サーバー３０に、コンテンツ（記事）の要求が伝えられる。事業者サーバー３０では、あるユーザー端末１０ａからコンテンツ要求を受信すると、流通情報収集処理部３１が、その旨を流通管理ＤＢ３４に記録する。具体的には、コンテンツ要求として受信した記事ＩＤのアクセス数をアクセス情報テーブルにおいて“１”加算することになる。
【００２９】
続いて、流通情報収集処理部３１は、コンテンツ要求があった記事を配信しているユーザー端末１０ｂに対して、コンテンツ要求があった旨の情報を送信する。ユーザー端末１０ｂでは、流通情報収集処理部３１からコンテンツ要求を受信すると、コンテンツ要求があった記事をコンテンツＤＢ１４ｂから抽出し、要求元のユーザー端末１０ａに送信する。
【００３０】
（２．４．リンク情報収集）
次に、リンク情報の収集について説明する。リンク情報の収集は、まず、流通情報収集処理部３１が、流通管理ＤＢ３４に格納されているメタデータ集合を取得する。そして、取得した各メタデータに含まれる情報から、それに対応するコンテンツに実際にアクセスしてリンク情報を取得する。リンク情報が得られたら、それを流通管理ＤＢ３４に格納する。具体的には、リンクしている側とリンクされている側の記事ＩＤをリンク情報テーブルに記録することになる。
【００３１】
（２．５．サイト評価値の算出）
次に、上記サイト評価値の算出について説明する。まず、流通評価計算処理部３２が、流通管理ＤＢ３４内のアクセス情報テーブルを参照し、アクセス数が所定数以上のページ（記事）の記事ＩＤを抽出する。アクセス数が所定数以上のものに限定することにより、人気の高い記事の記事ＩＤが抽出されることになる。続いて、流通評価計算処理部３２は、抽出した記事ＩＤにより流通管理ＤＢ３４内のリンク情報テーブルを参照し、対応するリンク記事ＩＤを抽出する。抽出されたリンク記事ＩＤは、人気の高い記事からリンクされている記事の記事ＩＤを示すことになる。
【００３２】
このようにして人気の高い記事からリンクされている記事の記事ＩＤが得られたら、この記事ＩＤで特定される記事にアクセスしている記事へのアクセス数等からページランク法（登録商標）を利用して記事ごとの評価値Ｒを算出し、記事ごとの評価値Ｒをサイトごとに集計することによりサイト評価値を算出する。評価値のサイトごとの集計は、記事ごとの評価値の総和、あるいは平均として集計される。
【００３３】
また、サイト評価値の算出手法については、他にもＷｅｂページのリンク数に基づく手法、Ｗｅｂページのアクセス数に基づく手法、Ｗｅｂページの作成時間に基づく手法、Ｗｅｂページのデータ量に基づく手法、Ｗｅｂページの更新頻度に基づく手法等を採用することも可能である。なお、ここでは、１つのＷｅｂページに１つの記事が記録されている場合を想定して説明する。したがって、１つのＷｅｂページに対して算出された評価値は、１つの記事に対して算出された評価値となる。
【００３４】
Ｗｅｂページのリンク数に基づく手法は、Ｗｅｂページからより多く参照されるＷｅｂページは重要度が高いという考え方に基づいて評価を行うものであり、あるサイトを評価する際に、そのサイトのサイトＩＤを有する記事ＩＤを記事情報テーブルを用いて抽出し、抽出した各記事ＩＤがリンク記事ＩＤとしてリンク情報テーブルに記録されている数Ｌを集計する。この総和（あるいは平均）をそのサイトのサイト評価値とする。この手法は、上記のページランク法を簡略化したものである。
【００３５】
上記、Ｗｅｂページのリンク数に基づく手法およびページランク法を用いた手法では、多くリンクされているが、ほとんどアクセスされていない古いサイトの評価値が大きくなってしまう可能性がある。その問題を回避する手法として、Ｗｅｂページのアクセス数に基づく手法がある。この手法では、アクセス数をａとした場合、非減少関数Ａ（ａ）で求まる値をページ評価値とするものである。このページ評価値のサイト別の総和（あるいは平均）がサイト評価値となる。
【００３６】
Ｗｅｂページの作成時間に基づく手法は、新しいＷｅｂページほど重要度が高いという考え方に基づいて評価を行うものであり、作成されてから現在までの経過時間をｔとして非増加関数Ｔ（ｔ）で求まる値をページ評価値とするものである。このページ評価値のサイト別の総和（あるいは平均）がサイト評価値となる。
【００３７】
Ｗｅｂページのデータ量に基づく手法は、データ量の多いＷｅｂページほど重要度が高いという考え方に基づいて評価を行うものであり、Ｗｅｂページの本文中に含まれる文字数やバイト数をｖとして非減少関数Ｖ（ｖ）で求まる値をページ評価値とするものである。このページ評価値のサイト別の総和（あるいは平均）がサイト評価値となる。
【００３８】
Ｗｅｂページの更新頻度に基づく手法は、更新頻度の高いＷｅｂページほど重要度が高いという考え方に基づいて評価を行うものであり、単位時間あたりに更新されるＷｅｂページ数をｕとして非減少関数Ｕ（ｕ）で求まる値をページ評価値とするものである。このページ評価値のサイト別の総和（あるいは平均）がサイト評価値となる。
【００３９】
上記の各手法により算出された評価値を組み合わせて、その関数としてページ評価値を算出することも可能である。具体的には、関数Ｆを用意し、ページ評価値＝Ｆ（Ｒ，Ａ（ａ），Ｔ（ｔ），Ｖ（ｖ），Ｕ（ｕ））、又は、ページ評価値＝Ｆ（Ｌ，Ａ（ａ），Ｔ（ｔ），Ｖ（ｖ），Ｕ（ｕ））、としてページ評価値を算出する。例えば、関数Ｆを、上記各手法により求まる値を全て乗算するものと定義した場合、ページ評価値＝Ｒ×Ａ（ａ）×Ｔ（ｔ）×Ｖ（ｖ）×Ｕ（ｕ）、又は、ページ評価値＝Ｌ×Ａ（ａ）×Ｔ（ｔ）×Ｖ（ｖ）×Ｕ（ｕ）、となる。
【００４０】
また、ページランクＲの計算には、処理時間がかかるため、Ａ（ａ），Ｔ（ｔ），Ｖ（ｖ），Ｕ（ｕ）に基づいて対象となるページを絞って（閾値を設け、それ以下のページを処理対象から除外する。）、その集合に対してページランク法を適用することにより計算コストを削減するようにすることも可能である。
【００４１】
以上、本発明の好適な実施形態について説明したが、本発明は上記実施形態に限定されず、様々な変形が可能である。例えば、上記実施形態では、説明の便宜上、ユーザー端末１０に、コンテンツＤＢ１３、コンテンツ配信処理部１４を備えた形式としたが、これらは、ネットワーク４０に接続された他のコンピュータに設けられていても良い。
【図面の簡単な説明】
【００４２】
【図１】本発明に係るサイト間関係表示システムの構成図である。
【図２】ユーザー端末１０の詳細を示す図である。
【図３】広告主端末２０の詳細を示す図である。
【図４】事業者サーバー３０の詳細を示す図である。
【図５】流通管理ＤＢ３４のテーブル構造を示す図である。
【図６】参照関係表示処理の概要を示すフローチャートである。
【図７】参照関係表示画面を示す図である。
【図８】サイト依存関係表示処理の概要を示すフローチャートである。
【図９】サイト依存関係表示画面を示す図である。
【符号の説明】
【００４３】
１０・・・ユーザー端末
１１・・・コンテンツ閲覧処理部
１２・・・コンテンツ入力・編集処理部
１３・・・コンテンツＤＢ
１４・・・コンテンツ配信処理部
１５・・・入力装置
１６・・・出力装置
２０・・・広告主端末
２１・・・広告コンテンツ閲覧処理部
２２・・・広告コンテンツ入力・編集処理部
２３・・・広告コンテンツＤＢ
２４・・・広告コンテンツ配信処理部
２５・・・入力装置
２６・・・出力装置
３０・・・事業者サーバー
３１・・・流通情報収集処理部
３２・・・流通評価計算処理部
３３・・・メタデータ配信処理部
３４・・・流通管理ＤＢ（流通管理データベース）
【図１】
2006343827.tif 000003
【図２】
2006343827.tif 000004
【図３】
2006343827.tif 000005
【図４】
2006343827.tif 000006
【図５】
2006343827.tif 000007
【図６】
2006343827.tif 000008
【図７】
2006343827.tif 000009
【図８】
2006343827.tif 000010
【図９】
2006343827.tif 000011