(57)【要約】【課題】  属性情報を変換してクライアント側で保持することで、サーバ側が属性情報を保持することなく、属性情報に応じたコンテンツを配信することができる配信システムを提供する。【解決手段】  配信システム１００において、端末装置３は、取得した属性情報をクエリ文字列に変換した後、ホームＵＲＬに付加することで属性付加ＵＲＬを作成する。端末装置３は、ネットワーク２を介して属性付加ＵＲＬにアクセスすることで、サーバ５が管理するＷｅｂページにアクセスする。サーバ５は、取得した属性付加ＵＲＬのクエリ文字列から属性情報を抽出し、当該属性情報と、配信条件ＤＢ６とをマッチングする。さらに、サーバ５は、マッチングの結果に基づいて、配信条件ＤＢ６からコンテンツ情報を抽出する。そして、サーバ５は、抽出したコンテンツ情報を含む配信情報を作成し、端末装置３に送信する。この配信情報により、利用者は属性情報に応じたコンテンツを閲覧する。【選択図】    図５
2007072959.tif 000002
【特許請求の範囲】
【請求項１】
利用者が使用する端末装置と、ネットワークを介して前記端末装置と通信可能なサーバとを備える配信システムにおいて、
前記端末装置は、
前記利用者に関する属性情報を取得する属性情報取得手段と、
前記属性情報を、前記サーバが管理する第１ＵＲＬに付加することで新たな第２ＵＲＬを作成する第２ＵＲＬ作成手段と、
前記第２ＵＲＬにアクセスするアクセス手段と、
前記サーバから、コンテンツに関するコンテンツ情報を含む配信情報を取得する配信情報取得手段と、
前記配信情報に含まれるコンテンツ情報に基づいて、前記コンテンツの一部又は全部を表示するコンテンツ表示手段と、を備え、
前記サーバは、
前記コンテンツ情報と、前記コンテンツを配信するための前記属性情報における配信条件とを対応付けた配信条件情報を記憶する配信条件情報記憶手段と、
前記第２ＵＲＬを取得するＵＲＬ取得手段と、
取得した第２ＵＲＬから前記属性情報を抽出する属性情報抽出手段と、
抽出した属性情報と、前記配信条件情報とをマッチングするマッチング手段と、
前記マッチングの結果に基づいて、前記配信条件情報から前記コンテンツ情報を抽出するコンテンツ情報抽出手段と、
前記コンテンツ情報を含む配信情報を作成する配信情報作成手段と、
作成した配信情報を、前記端末装置へ送信する配信情報送信手段と、を備えることを特徴とする配信システム。
【請求項２】
前記端末装置は、データを暗号化するための公開鍵を有しており、
前記第２ＵＲＬ作成手段は、前記属性情報を前記公開鍵で暗号化し、暗号化した属性情報を前記第１ＵＲＬに付加することで新たな第２ＵＲＬを作成し、
前記サーバは、データを復号化するためのものであって、前記端末装置が有する公開鍵と対になる秘密鍵を有しており、
前記属性情報抽出手段は、取得した第２ＵＲＬに含まれる暗号化された属性情報を前記秘密鍵で復号することで、前記属性情報を取得することを特徴とする請求項１に記載の配信システム。
【請求項３】
前記端末装置は、前記コンテンツの一部又は全部を表示するための表示アプリケーションを有しており、
前記コンテンツ情報は、前記ネットワーク上における前記コンテンツの所在地を示す第３ＵＲＬを含むものであって、
前記コンテンツ表示機能は、前記表示アプリケーションにより、前記配信情報取得手段が取得した配信情報に含まれるコンテンツ情報が有する第３ＵＲＬにアクセスし、前記コンテンツを表示することを特徴とする請求項１又は２に記載の配信システム。
【請求項４】
前記アクセス手段は、前記表示アプリケーションにより、自動で定期的に前記第２ＵＲＬへアクセスするものであって、
前記サーバは、
前記端末装置が前記第２ＵＲＬにアクセスする度に、前記属性情報抽出手段、前記マッチング手段、前記コンテンツ抽出手段、前記配信情報作成手段及び前記配信情報送信手段による処理を行うことを特徴とする請求項３に記載の配信システム。
【請求項５】
前記表示アプリケーションは、前記配信情報取得手段が取得した配信情報に含まれるコンテンツ情報に基づいて前記コンテンツの一部又は全部を表示することが可能な汎用的なアプリケーションであることを特徴とする請求項２乃至４のいずれか一項に記載の配信システム。
【請求項６】
前記属性情報は、前記端末装置のスペック情報であって、
前記端末装置は、自動的に前記スペック情報を収集する収集アプリケーションを有しており、
前記属性情報取得手段は、前記収集アプリケーションにより、自動的に前記端末装置のスペック情報を属性情報として取得することを特徴とする請求項１乃至５のいずれか一項に記載の配信システム。
【請求項７】
ネットワークを介してサーバと通信可能であり、利用者によって使用される端末装置であって、
前記利用者に関する属性情報を取得する属性情報取得手段と、
前記属性情報を、前記サーバが管理する第１ＵＲＬに付加することで新たな第２ＵＲＬを作成する第２ＵＲＬ作成手段と、
前記第２ＵＲＬにアクセスするアクセス手段と、
前記サーバから、コンテンツに関するコンテンツ情報を含む配信情報を取得する配信情報取得手段と、
前記配信情報に含まれるコンテンツ情報に基づいて、前記コンテンツの一部又は全部を表示するコンテンツ表示手段と、を備えることを特徴とする端末装置。
【請求項８】
ネットワークを介してサーバと通信可能であり、利用者によって使用されるコンピュータにより実行されるプログラムであって、
前記利用者に関する属性情報を取得する属性情報取得手段、
前記属性情報を、前記サーバが管理する第１ＵＲＬに付加することで新たな第２ＵＲＬを作成する第２ＵＲＬ作成手段、
前記第２ＵＲＬにアクセスするアクセス手段、
前記サーバから、コンテンツに関するコンテンツ情報を含む配信情報を取得する配信情報取得手段、
前記配信情報に含まれるコンテンツ情報に基づいて、前記コンテンツの一部又は全部を表示するコンテンツ表示手段、としてを前記コンピュータを機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、利用者の属性に合ったコンテンツを配信する技術に関する。
【背景技術】
【０００２】
従来から、Ｗｅｂアプリケーションにおいて、利用者の属性情報を予め登録させ、その属性情報に応じて配信するコンテンツを切り替えたり、変換したりするサービスが知られている。
【０００３】
具体的には、商品を販売するＷｅｂアプリケーションにおいて、購買履歴に基づいて利用者に合った商品をページのトップに表示し、推奨することが挙げられる。また、利用者の趣味や嗜好に応じたメールマガジンを配信することが挙げられる。
【０００４】
このようなＷｅｂアプリケーションでは、サービスを提供する企業側のサーバに予め利用者の属性情報を登録しておく必要がある（例えば、特許文献１）。そのため、個人情報漏洩防止の観点から利用者の抵抗感を招くとともに、サービスを提供する企業側にとっても個人情報の管理コストやリスクが発生するといった問題が生じていた。
【０００５】
【特許文献１】特許第３５０２３５８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は、以上の点に鑑みてなされたものであり、属性情報を変換してクライアント側で保持することで、サーバ側が属性情報を保持することなく、属性情報に応じたコンテンツの配信を可能とする配信システムを提供することを課題とする。
【課題を解決するための手段】
【０００７】
本発明の１つの観点では、利用者が使用する端末装置と、ネットワークを介して前記端末装置と通信可能なサーバとを備える配信システムにおいて、前記端末装置は、前記利用者に関する属性情報を取得する属性情報取得手段と、前記属性情報を、前記サーバが管理する第１ＵＲＬに付加することで新たな第２ＵＲＬを作成する第２ＵＲＬ作成手段と、前記第２ＵＲＬにアクセスするアクセス手段と、前記サーバから、コンテンツに関するコンテンツ情報を含む配信情報を取得する配信情報取得手段と、前記配信情報に含まれるコンテンツ情報に基づいて、前記コンテンツの一部又は全部を表示するコンテンツ表示手段とを備え、前記サーバは、前記コンテンツ情報と、前記コンテンツを配信するための前記属性情報における配信条件とを対応付けた配信条件情報を記憶する配信条件情報記憶手段と、前記第２ＵＲＬを取得するＵＲＬ取得手段と、取得した第２ＵＲＬから前記属性情報を抽出する属性情報抽出手段と、抽出した属性情報と、前記配信条件情報とをマッチングするマッチング手段と、前記マッチングの結果に基づいて、前記配信条件情報から前記コンテンツ情報を抽出するコンテンツ情報抽出手段と、前記コンテンツ情報を含む配信情報を作成する配信情報作成手段と、作成した配信情報を、前記端末装置へ送信する配信情報送信手段と、を備える。
【０００８】
上記のように構成された配信システムにおける端末装置は、利用者が使用するＰＣ（Personal Computer）やＰＤＡ（Personal Digital Assistants）等である。一方、サーバは、予め配信条件情報を記憶している。端末装置は、属性情報を取得し、当該属性情報をクエリ文字列等に変換した後、第１ＵＲＬに付加することで新たな第２ＵＲＬを作成する。ここで、属性情報とは、利用者に関する情報であり、例えば、利用者の性別や年齢といった個人情報や興味のあるジャンルといった趣味・嗜好情報等が挙げられる。端末装置は、ネットワークを介して第２ＵＲＬにアクセスすることで、サーバが管理するＷｅｂページにアクセスする。これにより、サーバは、端末装置が作成した第２ＵＲＬを取得することができる。サーバは、取得した第２ＵＲＬのクエリ文字列から属性情報を抽出し、当該属性情報と、配信条件情報とをマッチングする。具体的に、サーバは、属性情報が、配信条件情報に含まれる配信条件に合致するか否かを検討する。さらに、サーバは、マッチングの結果に基づいて、配信条件情報からコンテンツ情報を抽出する。具体的に、サーバは、属性条件が配信条件に合致するコンテンツに関するコンテンツ情報を抽出する。そして、サーバは、抽出したコンテンツ情報を含む配信情報を作成し、端末装置に送信する。端末装置は、配信情報を取得する。この配信情報により、利用者は自身の属性情報に応じたコンテンツを閲覧する。ここで、コンテンツとは、商品の広告、リコール情報、サポート情報等が挙げられる。これによれば、第２ＵＲＬには属性情報が付加されているため、サーバは、個人情報である属性情報を保持することなく、従来のように、属性情報に応じたコンテンツを端末装置に配信することができる。
【０００９】
上記配信システムの一態様では、前記端末装置は、データを暗号化するための公開鍵を有しており、前記第２ＵＲＬ作成手段は、前記属性情報を前記公開鍵で暗号化し、暗号化した属性情報を前記第１ＵＲＬに付加することで新たな第２ＵＲＬを作成し、前記サーバは、データを復号化するためのものであって、前記端末装置が有する公開鍵と対になる秘密鍵を有しており、前記属性情報抽出手段は、取得した第２ＵＲＬに含まれる暗号化された属性情報を前記秘密鍵で復号することで、前記属性情報を取得する。
【００１０】
上記のように構成された配信システムにおいて、サーバはデータを復号するための秘密鍵を有しており、端末装置は当該秘密鍵と対をなす公開鍵を有している。よって、端末装置は、属性情報を公開鍵で暗号化して第２ＵＲＬを作成する。一方、サーバは、端末装置から取得した第２ＵＲＬを秘密鍵で復号して属性情報を取得する。これによれば、安全ではないネットワーク上でのデータのやり取りであっても、効果的に情報漏洩を防止することが可能となる。
【００１１】
上記配信システムの他の一態様では、前記端末装置は、前記コンテンツの一部又は全部を表示するための表示アプリケーションを有しており、前記コンテンツ情報は、前記ネットワーク上における前記コンテンツの所在地を示す第３ＵＲＬを含むものであって、前記コンテンツ表示機能は、前記表示アプリケーションにより、前記配信情報取得手段が取得した配信情報に含まれるコンテンツ情報が有する第３ＵＲＬにアクセスし、前記コンテンツを表示する。ここで、表示アプリケーションとは、コンテンツの一部又は全部を表示することが可能なブラウザ等であって、例えばＲＳＳ（Rich Site Summary）リーダ等が挙げられる。具体的に、端末装置は、サーバから配信情報を取得すると、ＲＳＳリーダ等により当該配信情報に含まれる第３ＵＲＬにアクセスすることによりコンテンツを表示する。つまり、コンテンツは、企業が予め保有している広告、リコール情報及びサポート情報等が掲載されたＷｅｂページとすることができる。換言すると、サーバは、利用者の属性情報に応じたコンテンツであるＷｅｂページを示す第３ＵＲＬを配信情報として端末装置に送信する。これによれば、サーバは、コンテンツ情報として第３ＵＲＬのみ保持しておけばよく、コンテンツ自体を記憶・管理する必要がない。よって、サーバの負荷を軽減することができる。また、コンテンツを提供する企業としては、既存のＷｅｂページをコンテンツとして利用することができる。即ち、企業は、既存のコンテンツのＵＲＬに配信条件を設定するだけで、当該コンテンツを希望するターゲット（利用者）へ配信することができるというメリットがある。
【００１２】
上記配信システムの他の一態様では、前記アクセス手段は、前記表示アプリケーションにより、自動で定期的に前記第２ＵＲＬへアクセスするものであって、前記サーバは、前記端末装置が前記第２ＵＲＬにアクセスする度に、前記属性情報抽出手段、前記マッチング手段、前記コンテンツ抽出手段、前記配信情報作成手段及び前記配信情報送信手段による処理を行う。これによれば、端末装置の表示アプリケーションは、自動で定期的に属性情報が付加された第２ＵＲＬにアクセスする。つまり、端末装置の表示アプリケーションは、毎回属性情報が付加された第２ＵＲＬによりサーバにアクセスする。換言すると、端末装置は、毎回属性情報をサーバに提示する。一方、サーバは、端末装置の表示アプリケーションによるアクセスがある度に、新たな配信情報を作成して送信する。このとき、サーバは、既に端末装置に配信した情報を除いた更新情報のみを配信情報として送信することとしてもよい。よって、利用者は、特に意識することなく、表示アプリケーションにより、属性情報に応じたコンテンツを定期的に閲覧することができる。
【００１３】
上記配信システムの他の一態様では、前記表示アプリケーションは、前記配信情報取得手段が取得した配信情報に含まれるコンテンツ情報に基づいて前記コンテンツの一部又は全部を表示することが可能な汎用的なアプリケーションである。具体的には、コンテンツ情報に含まれるコンテンツのタイトル等を表示するアプリケーションや、コンテンツ情報に含まれる第３ＵＲＬにアクセスすることでコンテンツ自体を表示するアプリケーション等任意のアプリケーションを使用することができる。つまり、本発明は専用のアプリケーションを必要とせず、任意のアプリケーションにより端末装置上のコンテンツの一部又は全部を表示させることができる。
【００１４】
上記配信システムのさらに他の一態様では、前記属性情報は、前記端末装置のスペック情報であって、前記端末装置は、自動的に前記スペック情報を収集する収集アプリケーションを有しており、前記属性情報取得手段は、前記収集アプリケーションにより、自動的に前記端末装置のスペック情報を属性情報として取得する。ここで、スペック情報とは、ＯＳ（Operating System）、ＣＰＵ（Central Processing Unit）、メモリ、ディスプレイ、ＨＤＤ（Hard Disc Drive）など端末装置の性能等を表す情報であり、任意に設定することができる。これによれば、端末装置は収集アプリケーションを使用して自動的に属性情報を収集することができる。つまり、端末装置は、利用者に負担をかけることなく、属性情報を取得することができる。また、属性情報をスペック情報とすることで、コンテンツを提供する企業が家電量販店やメーカーの場合、利用者が使用しているパソコンやプリンタ等の機器環境に応じて広告やサポート情報を配信することが可能となる。よって、コンテンツを提供する企業は、ターゲットを絞って効率的な販売促進を行うことが可能となる。一方、利用者は、自身が使用する端末装置のスペック情報に応じた広告やサポート情報を閲覧することができる。よって、モニタやメモリといった端末装置の一部を買い換える際に、自身の要求に応じた的確な広告やサポート情報を容易に閲覧することができる。
【００１５】
本発明の別の観点では、ネットワークを介してサーバと通信可能であり、利用者によって使用される端末装置であって、前記利用者に関する属性情報を取得する属性情報取得手段と、前記属性情報を、前記サーバが管理する第１ＵＲＬに付加することで新たな第２ＵＲＬを作成する第２ＵＲＬ作成手段と、前記第２ＵＲＬにアクセスするアクセス手段と、前記サーバから、コンテンツに関するコンテンツ情報を含む配信情報を取得する配信情報取得手段と、前記配信情報に含まれるコンテンツ情報に基づいて、前記コンテンツの一部又は全部を表示するコンテンツ表示手段と、を備える。これによれば、第２ＵＲＬには属性情報が付加されているため、コンテンツを提供するサーバ側は、個人情報である属性情報を保持することなく、従来のように、属性情報に応じたコンテンツを端末装置に配信することができる。
【００１６】
本発明のさらに別の観点では、ネットワークを介してサーバと通信可能であり、利用者によって使用されるコンピュータにより実行されるプログラムであって、前記利用者に関する属性情報を取得する属性情報取得手段、前記属性情報を、前記サーバが管理する第１ＵＲＬに付加することで新たな第２ＵＲＬを作成する第２ＵＲＬ作成手段、前記第２ＵＲＬにアクセスするアクセス手段、前記サーバから、コンテンツに関するコンテンツ情報を含む配信情報を取得する配信情報取得手段、前記配信情報に含まれるコンテンツ情報に基づいて、前記コンテンツの一部又は全部を表示するコンテンツ表示手段、としてを前記コンピュータを機能させる。
【００１７】
上記プログラムをコンピュータにより実行することにより、上述の端末装置を実現することができる。また、上述の端末装置の各態様も同様に実現することができる。
【発明の効果】
【００１８】
本発明によれば、属性情報を変換してクライアント側で保持することで、サーバ側が属性情報を保持することなく、属性情報に応じたコンテンツを配信することができる。
【発明を実施するための最良の形態】
【００１９】
以下、図面を参照して本発明の好適な実施の形態について説明する。
【００２０】
[第１実施形態]
（i）配信システム
まず、配信システムについて図１乃至図４を参照して説明する。図１は、配信システム１００の概略構成を示す。図２は、属性情報入力画面の例である。図３は、企業から提供されるコンテンツの例である。図４は、ＲＳＳ（Rich Site Summary）リーダを利用して、コンテンツを表示した画面例である。
【００２１】
ここで、ＲＳＳリーダとは、Ｗｅｂサイトを巡回してＲＳＳ形式の更新情報を受信し、リンク一覧の形で表示するアプリケーションのことである。また、ＲＳＳとは、ＸＭＬ（eXtensible Markup Language）ベースの書式の一種であり、Ｗｅｂサイトの更新情報を記述するのに用いられている。具体的に、ＲＳＳリーダは、指定したサイトのＲＳＳ情報を一定時間ごとに自動的にダウンロードし、更新があると記事（コンテンツ）へのリンクを表示して利用者に知らせる。利用者が、当該リンクをクリックするとＷｅｂブラウザのウィンドウが開いて目的の記事が表示される。
【００２２】
なお、本実施形態では、コンテンツを表示するためのアプリケーションとしてＲＳＳリーダを使用しているが、本発明はこれに限定されるものではなく、コンテンツの一部又は全部を表示可能なアプリケーションであれば任意のものを適用することができる。
【００２３】
配信システム１００は、利用者の属性情報を変換して付加したＵＲＬ（以下、「属性付加ＵＲＬ」と呼ぶ。）により、コンテンツ配信サーバ５が属性情報を管理することなく、容易に属性情報に応じたコンテンツを配信することができるシステムである。図１に示すように、配信システム１００は、ネットワーク２を介して、端末装置３、コンテンツ提供サーバ４及びコンテンツ配信サーバ５から構成される。ネットワーク２の１つの好適な例はインターネットである。
【００２４】
ここで、端末装置３は、利用者が使用するＰＣ（Personal Computer）やＰＤＡ（Personal Digital Assistants）、携帯電話等である。また、端末装置３は、コンテンツの一部又は全部を利用者が閲覧するためのアプリケーションとしてＲＳＳリーダを有している。具体的に、端末装置３は、利用者の属性情報を変換して付加した属性付加ＵＲＬに基づいて、コンテンツ配信サーバ５から配信情報を取得し、当該配信情報に基づいてＲＳＳリーダによりコンテンツを表示する端末である。
【００２５】
また、コンテンツ提供サーバ４は、商品の広告、リコール情報、サポート情報といったコンテンツを利用者に提供したい企業等が管理するサーバである。具体的に、コンテンツ提供サーバ４は、商品の広告やリコール情報を表示したＷｅｂページをコンテンツとして管理している。即ち、端末装置３は、当該Ｗｅｂページの所在位置を示すＵＲＬ（以下、「コンテンツＵＲＬ」と呼ぶ。）に、ネットワーク２を介してアクセスすることで、コンテンツを表示することができる。
【００２６】
また、コンテンツ配信サーバ５は、コンテンツ提供サーバ４から提示された配信条件と、コンテンツであるＷｅｂページを示すコンテンツＵＲＬとを対応付けて記憶した配信条件データベース（以下、「配信条件ＤＢ」と呼ぶ。）を有するサーバである。具体的に、コンテンツ配信サーバ５は、端末装置３から受信した属性付加ＵＲＬに含まれる利用者の属性情報と、配信条件ＤＢとをマッチングし、マッチング結果に基づいてコンテンツＵＲＬを含む配信情報を当該端末装置３へ送信する。
【００２７】
なお、本実施形態では、コンテンツ提供サーバ４及びコンテンツ配信サーバ５をそれぞれ異なるサーバとしているが、本発明はこれに限定されるものではなく、双方の機能を有する１つのサーバとしてもよい。
【００２８】
ここで、本システムによるコンテンツ配信方法の概要を述べておく。コンテンツ提供サーバ４は、コンテンツであるＷｅｂページを示すコンテンツＵＲＬと、当該コンテンツを提供するための配信条件とを対応付けた配信条件情報をコンテンツ配信サーバ５へ送信する。コンテンツ配信サーバ５は、配信条件情報を、対応するコンテンツを識別するコンテンツＩＤをキーとして配信条件ＤＢ６に記憶することによりコンテンツの登録を行う。ここで、コンテンツとは、図３に示すように、コンテンツ提供サーバ４が管理する企業等の商品広告、リコール情報、サポート情報等任意の情報を表示するＷｅｂページである。
【００２９】
一方、利用者は、端末装置３を使用して、図２に示すような属性情報入力画面から、個人の属性情報を入力する。具体的に、本実施形態における属性情報とは、利用者の性別や年齢といった個人情報及び興味のあるジャンルといった趣味・嗜好情報である。利用者は、図示のような属性情報入力画面から、性別、年齢、所在地の都道府県、職業及び興味のあるジャンルを入力する。このとき、都道府県、職業及び興味のあるジャンルは、項目右端の三角ボタンを押下することによりプルダウンメニューが表示され、その中から選択するものとする。ここで、興味のあるジャンルとは、個人の趣味・嗜好をカテゴライズしたものであり、例えば「旅行」や「グルメ」等が挙げられる。
【００３０】
属性情報入力画面により、端末装置３は、利用者の属性情報を取得することができる。そして、端末装置３は、取得した属性情報をクエリ文字列に変換し、コンテンツ配信サーバ５が管理しているＷｅｂページのＵＲＬ（以下、「ホームＵＲＬ」と呼ぶ。）に付加することで、属性付加ＵＲＬを作成する。このとき、端末装置３は、公開鍵を利用して、クエリ文字列を暗号化してからホームＵＲＬに付加する。さらに、端末装置３は、ＲＳＳリーダにおいて新たに作成した属性付加ＵＲＬを登録し、ネットワーク２を介して当該属性付加ＵＲＬにアクセスする。この属性付加ＵＲＬは、コンテンツ配信サーバ５が管理しているＷｅｂページのホームＵＲＬに、変換した属性情報が付加されているものであるため、端末装置３は、コンテンツ配信サーバ５が管理している当該Ｗｅｂページにアクセスする。
【００３１】
端末装置３がＷｅｂページにアクセスすることで、コンテンツ配信サーバ５は、端末装置３が作成した属性付加ＵＲＬを取得することができる。そして、端末装置３は、取得した属性付加ＵＲＬから暗号化されたクエリ文字列を抽出し、当該クエリ文字列を、秘密鍵を利用して復号することで、利用者の属性情報を取得する。ここで、秘密鍵とは、端末装置３がクエリ文字列を暗号化した際に利用した公開鍵と対になっているものであり、予めコンテンツ配信サーバ５のみが有しているものである。さらに、コンテンツ配信サーバ５は、取得した属性情報と、配信条件ＤＢに記憶された配信条件情報とをマッチングする。ここで、マッチングとは、取得した属性情報と、配信条件情報とを比較することにより、属性情報がどのコンテンツの配信条件に一致するかを判定することである。具体的には、ＸＳＬＴ（XML Stylesheet Language Transformations）やＸＭＬパーサ等により、ＸＭＬ化した属性情報及び配信条件情報を比較する。
【００３２】
なお、このとき取得した属性情報は、ＨＤＤ（Hard Disc Drive）やＤＢ等の永続的なデータとしては保存せず、メモリ上に保持するのみで、マッチング処理が終了したら消去される。
【００３３】
ここで、ＸＳＬＴとＸＭＬパーサについて説明する。ＸＳＬＴとは、ＸＭＬによって記述された文書を他のＸＭＬ文書に変換するための簡易言語である。具体的にＸＳＬＴは、ＸＭＬ文書の構造を別の形式に変形するための変換ルールを記述するもので、記述されたＸＳＬＴ文書は「スタイルシート」と呼ばれる。一方、ＸＭＬパーサとは、ＸＭＬ文書を、所定のアプリケーションが利用しやすい形に変換するものである。所定のアプリケーションでＸＭＬ文書を扱う場合には、直接ＸＭＬ文書を読むのではなく、ＸＭＬパーサを介するのが一般的である。なお、ＸＳＴＬを使用したマッチングについては、第２実施形態においてさらに詳しく説明する。
【００３４】
次に、コンテンツ配信サーバ５は、マッチングの結果に基づいて、コンテンツＵＲＬを含む配信情報を作成する。ここで、配信情報とは、マッチングの結果、属性情報が配信条件に一致したコンテンツのコンテンツＵＲＬや当該コンテンツのタイトル等の情報を有しており、具体的には端末装置３が解釈可能なＸＭＬにより記述されている。そして、コンテンツ配信サーバ５は、自身が管理しているＷｅｂアプリケーションにアクセスしている端末装置３へ、作成した配信情報を送信する。
【００３５】
端末装置３のＲＳＳリーダは、コンテンツ配信サーバ５から取得した配信情報を解釈し、図４に示すような表示画面において、当該配信情報に含まれるコンテンツのタイトルを日時等と共に記事一覧に表示する。また、ＲＳＳリーダは、タイトルがクリックされた場合には、当該配信情報に含まれるコンテンツＵＲＬにアクセスし、コンテンツを記事欄に表示する。ここで、記事欄に表示されるコンテンツとは、予めコンテンツ提供サーバ４が登録した図３に示すような広告やリコール情報等のＷｅｂページである。また、ＲＳＳリーダは、変換した属性情報を付加することで作成した属性付加ＵＲＬを登録しているため、サイト一覧には、当該属性付加ＵＲＬが表示されている。
【００３６】
なお、端末装置３のＲＳＳリーダは、ネットワーク２を介してデータの送受信が可能な環境であれば、自動で定期的に属性付加ＵＲＬにアクセスする。このときアクセスする属性付加ＵＲＬには、変換及び暗号化した属性情報が常に付加されている。そのため、コンテンツ配信サーバ５は、ＲＳＳリーダによるアクセスがある度に、属性付加ＵＲＬから取得した属性情報と、配信条件情報とをマッチングし、当該マッチングの結果に基づいて配信情報を作成する。そして、端末装置３のＲＳＳリーダは、コンテンツ配信サーバ５から取得した配信情報に基づいて、新たなコンテンツのタイトルを記事一覧に表示する。さらに、当該タイトルがクリックされた場合には、当該配信情報に含まれるコンテンツＵＲＬにアクセスし、コンテンツを記事欄に表示する。このようにＲＳＳリーダを利用して、利用者は、コンテンツを閲覧する。
【００３７】
これによれば、属性情報を変換した後暗号化してＵＲＬに付加するため、コンテンツ配信サーバ５は、個人情報である属性情報を保持することなく、従来のように、属性情報に応じたコンテンツを端末装置に配信することができる。このとき、端末装置３がコンテンツを表示するために使用するアプリケーションは、ＲＳＳリーダに限定されるものではなく、コンテンツ配信サーバ５が作成した配信情報を解釈し、コンテンツの一部又は全部を表示することができるものであればよい。即ち、専用アプリケーションである必要はなく、汎用的なアプリケーションを適用することができる。
【００３８】
また、利用者を識別する利用者ＩＤを使用していないため、利用者個人を識別することなく、属性情報に応じたコンテンツを端末装置に配信することができる。よって、安全ではないネットワーク２を介してのコンテンツの配信であっても、個人情報の漏洩を防止することができる。そのため、利用者は安心してコンテンツ配信サービスを受けることができる。
【００３９】
（ii）機能ブロック
次に、端末装置３、コンテンツ提供サーバ４及びコンテンツ配信サーバ５について、図５を参照して詳しく説明する。図５は、配信システム１００における端末装置３、コンテンツ提供サーバ４及びコンテンツ配信サーバ５の機能ブロック図である。
【００４０】
まず、端末装置３について説明する。図示のように、端末装置３は、端末配信プログラム１０１、属性情報取得機能１０２、属性情報変換機能１０３、属性付加ＵＲＬ作成機能１０４、属性付加ＵＲＬアクセス機能１０５、配信情報取得機能１０６及びコンテンツ表示機能１０７から構成されている。ここで、属性付加ＵＲＬアクセス機能１０５、配信情報取得機能１０６及びコンテンツ表示機能１０７は、端末装置３が有するＲＳＳリーダにより実現される。なお、各機能は、端末装置３が有するＣＰＵが予め用意されたプログラムを実行することにより実現される。
【００４１】
端末配信プログラム１０１は、利用者の属性情報を変換して付加した属性付加ＵＲＬを作成すると共に、コンテンツ配信サーバ５から属性情報に基づく配信情報を取得するプログラムである。また、端末配信プログラム１０１は、配信情報に基づいてＲＳＳリーダによりコンテンツを表示するプログラムである。
【００４２】
属性情報取得機能１０２は、利用者の個人情報や嗜好情報を属性情報として取得する機能である。具体的に、属性情報取得機能１０２は、図２に示すような属性情報入力画面において利用者が入力した情報を属性情報として取得する。
【００４３】
属性情報変換機能１０３は、属性情報取得機能１０２が取得した属性情報をクエリ文字列に変換する機能である。
【００４４】
属性付加ＵＲＬ作成機能１０４は、属性情報変換機能１０３が変換したクエリ文字列を、予め保有している公開鍵で暗号化する機能である。また、属性付加ＵＲＬ作成機能１０４は、暗号化したクエリ文字列を、コンテンツ配信サーバ５が管理するＷｅｂページのホームＵＲＬに付加することで、属性付加ＵＲＬを作成する機能である。
【００４５】
属性付加ＵＲＬアクセス機能１０５は、属性付加ＵＲＬ作成機能１０４が作成した属性付加ＵＲＬにネットワーク２を介してアクセスする機能である。具体的には、ＲＳＳリーダに属性付加ＵＲＬを登録することで、コンテンツ配信サーバ５が管理するＷｅｂページにアクセスする。これにより、コンテンツ配信サーバ５は、属性付加ＵＲＬを取得することができる。
【００４６】
配信情報取得機能１０６は、コンテンツ配信サーバ５が作成した配信情報を取得する機能である。詳細は後述するが、配信情報には、利用者の属性情報に応じたコンテンツのタイトルやコンテンツＵＲＬが含まれている。よって、配信情報取得機能１０６は、ＲＳＳリーダにより、図４に示すように、コンテンツのタイトルを記事一覧に表示する。
【００４７】
コンテンツ表示機能１０７は、図４に示すような画面において、コンテンツのタイトルがクリックされた場合に、配信情報に基づいて、対応するコンテンツのコンテンツＵＲＬにアクセスし、コンテンツを表示する機能である。
【００４８】
なお、属性付加ＵＲＬアクセス機能１０５、配信情報取得機能１０６及びコンテンツ表示機能１０７は、ＲＳＳリーダにより一定時間毎に定期的に繰り返し行われる。そのため、ＲＳＳリーダは、常に最新のコンテンツを表示することができる。このとき、属性付加ＵＲＬアクセス機能１０５が繰り返し送信する属性付加ＵＲＬは、常に最初に属性付加ＵＲＬ作成機能１０４が作成した属性付加ＵＲＬである。しかし、利用者により、図２に示すような属性情報入力画面上で属性情報が変更された場合には、属性情報取得機能１０２、属性情報変換機能１０３及び属性付加ＵＲＬ作成機能１０４により作成した別の属性付加ＵＲＬを送信する。
【００４９】
次に、コンテンツ提供サーバ４について説明する。図示のように、コンテンツ提供サーバ４は、提供プログラム２０１、配信条件情報送信機能２０２及びコンテンツ提供機能２０３から構成されている。なお、各機能は、コンテンツ提供サーバ４が有するＣＰＵが予め用意されたプログラムを実行することにより実現される。
【００５０】
提供プログラム２０１は、商品広告、リコール情報及びサポート情報等のＷｅｂページをコンテンツとしてコンテンツ配信サーバ５に登録することで、当該コンテンツを利用者に提供するプログラムである。
【００５１】
配信条件情報送信機能２０２は、商品広告、リコール情報及びサポート情報等のＷｅｂページであるコンテンツのコンテンツＵＲＬと、コンテンツのタイトルと、当該コンテンツを配信する利用者の属性情報の条件である配信条件とを、配信条件情報としてコンテンツ配信サーバへ送信する機能である。
【００５２】
コンテンツ提供機能２０３は、端末装置３のＲＳＳリーダが、コンテンツ配信サーバ５から取得した配信情報に基づいてコンテンツ提供サーバ４が管理するＷｅｂページにアクセスしてきた際に、当該Ｗｅｂページをコンテンツとして端末装置３へ提供する機能である。具体的には、ＲＳＳリーダの記事欄に、コンテンツ提供サーバ４が管理するＷｅｂページが表示される。
【００５３】
次に、コンテンツ配信サーバ５について説明する。図示のように、コンテンツ配信サーバ５は、サーバ配信プログラム２０４、コンテンツ登録機能２０５、属性付加ＵＲＬ受信機能２０６、属性情報抽出機能２０７、マッチング機能２０８、配信情報作成機能２０９及び配信情報送信機能２１０から構成されている。なお、各機能は、コンテンツ配信サーバ５が有するＣＰＵが予め用意されたプログラムを実行することにより実現される。
【００５４】
サーバ配信プログラム２０４は、コンテンツ提供サーバ４から受信した配信条件情報を配信条件ＤＢ６に記憶することでコンテンツの登録を行うプログラムである。また、サーバ配信プログラム２０４は、端末装置３が作成した属性付加ＵＲＬから抽出した属性情報と、配信条件情報とをマッチングすることにより、利用者の属性情報に応じたコンテンツを特定し、当該コンテンツに関する情報を含む配信情報を作成するプログラムである。
【００５５】
コンテンツ登録機能２０５は、各コンテンツを識別するコンテンツＩＤと、コンテンツ提供サーバ４から取得した配信条件情報とを対応付けて配信条件ＤＢ６に記憶する機能である。ここで、配信条件ＤＢについて、図６を参照して説明する。図６は、配信条件ＤＢ６のデータ構造を模式的に示す図である。図６に示すように、配信条件ＤＢ６は、コンテンツＩＤ、性別、年齢、ジャンル及びコンテンツＵＲＬから構成されている。なお、図示されていないが、コンテンツのタイトルも含まれているものとする。コンテンツＩＤとは、各コンテンツを識別する情報である。性別及び年齢とは、コンテンツの配信対象となる利用者の性別及び年齢である。ジャンルとは、コンテンツの配信対象となる利用者の趣味・嗜好をカテゴライズしたものであり、本実施形態では図２に示す属性情報入力画面において選択される「旅行」や「グルメ」等が挙げられる。コンテンツＵＲＬとは、コンテンツを表示するＷｅｂページのネットワーク２上における所在位置を示すＵＲＬである。
【００５６】
コンテンツ登録機能２０５は、コンテンツＩＤをキーとして、コンテンツのタイトル、コンテンツを表示するＷｅｂページを示すコンテンツＵＲＬ及びコンテンツを配信する利用者の属性情報における条件を、図６に示すように配信条件ＤＢ６に記憶することでコンテンツの登録を行う。換言すると、コンテンツ提供サーバ４は、コンテンツの配信条件として、利用者の性別、年齢及びジャンルといった情報を設定する。
【００５７】
ＵＲＬ受信機能２０６は、端末装置３が属性情報を変換して付加することにより新たに作成したＵＲＬを受信する機能である。具体的には、端末装置３のＲＳＳリーダが、新たに作成したＵＲＬに基づいてコンテンツ配信サーバ５が管理するＷｅｂページにアクセスすることにより、当該ＵＲＬを受信する。
【００５８】
属性情報抽出機能２０７は、属性付加ＵＲＬ受信機能２０６が受信した属性付加ＵＲＬからクエリ文字列を抽出し、秘密鍵を利用して復号することで、利用者の属性情報を抽出する機能である。
【００５９】
マッチング機能２０８は、属性情報抽出機能２０７が抽出した利用者の属性情報と、配信条件ＤＢ６に記憶された配信条件とをマッチングする機能である。具体的には、利用者の属性情報である性別、年齢及びジャンルと、配信条件ＤＢ６に記憶された性別、年齢及びジャンルと比較し、利用者の属性情報により配信条件を満たすコンテンツを特定する。
【００６０】
配信情報作成機能２０９は、マッチング機能２０８によるマッチング結果に基づいて、利用者の嗜好に応じたコンテンツに関するコンテンツ情報を含む配信情報を作成する機能である。具体的に、コンテンツ情報とは、マッチングの結果特定されたコンテンツのタイトルやコンテンツＵＲＬを含む情報であり、配信条件ＤＢ６から抽出する情報である。
【００６１】
配信情報送信機能２１０は、配信情報作成機能２０９が作成した配信情報を端末装置３に送信する機能である。具体的に、配信情報送信機能２１０は、端末装置３がＲＳＳリーダにより、コンテンツ配信サーバ５が管理するＷｅｂページにアクセスしている際、配信情報作成機能２０９が作成した配信情報を端末装置３に送信する。
【００６２】
（iii）配信処理
次に、図７を参照して、上記配信システム１００を構成する端末装置３、コンテンツ提供サーバ４及びコンテンツ配信サーバ５により実行される配信処理について説明する。図７は、配信システム１００による配信処理のフローチャートである。
【００６３】
まず、コンテンツ提供サーバ４は、広告、リコール情報及びサポート情報等のＷｅｂページをコンテンツとしてコンテンツ配信サーバ５に登録する。具体的に、コンテンツ提供サーバ４は、コンテンツのコンテンツＵＲＬと、コンテンツのタイトルと、コンテンツを提供する利用者の属性情報における配信条件とを配信条件情報としてコンテンツ配信サーバ５に送信する（ステップＳ１）。コンテンツ配信サーバ５は、コンテンツ提供サーバ４から配信条件情報を取得すると、各コンテンツを識別するコンテンツＩＤに対応付けて配信条件ＤＢ６に記憶する。このように、コンテンツＩＤに対応付けて配信条件情報を記憶することで、コンテンツの登録を行う（ステップＳ２）。
【００６４】
一方、端末装置３は、図２に示すような属性情報入力画面を利用して、利用者の属性情報を取得する（ステップＳ３）。そして、端末装置３は、取得した属性情報をクエリ文字列に変換し、公開鍵を使用して暗号化する（ステップＳ４）。さらに、端末装置３は、暗号化したクエリ文字列を、コンテンツ配信サーバ５が管理するＷｅｂページのホームＵＲＬに付加することにより、属性付加ＵＲＬを作成する（ステップＳ５）。そして、端末装置３が予め保有するＲＳＳリーダに、作成した属性付加ＵＲＬを登録する。ＲＳＳリーダは、自動で定期的に登録された属性付加ＵＲＬ、即ちコンテンツ配信サーバ５が管理するＷｅｂページにアクセスする。このように、コンテンツ配信サーバ５が管理するＷｅｂページにネットワーク２を介してアクセスすることで、端末装置３は、変換及び暗号化した属性情報を付加した属性付加ＵＲＬをコンテンツ配信サーバ５に送信する（ステップＳ６）。
【００６５】
コンテンツ配信サーバ５は、端末装置３がＲＳＳリーダにより、自身が管理するＷｅｂページにアクセスすることで、当該端末装置３が作成した属性付加ＵＲＬを受信する（ステップＳ７）。さらに、コンテンツ配信サーバ５は、受信した属性付加ＵＲＬからクエリ文字列を抽出し、予め保有する秘密鍵を利用して当該クエリ文字列を復号することにより利用者の属性情報を抽出する（ステップＳ８）。そして、コンテンツ配信サーバ５は、抽出した属性情報と、配信条件ＤＢ６に記憶された配信条件とをマッチングする（ステップＳ９）。マッチングの結果に基づいて、コンテンツ配信サーバ５は、配信情報を作成する（ステップＳ１０）。具体的に、コンテンツ配信サーバ５は、マッチングにより、利用者の属性情報が配信条件を満たすコンテンツのタイトルやコンテンツＵＲＬをコンテンツ情報として含む配信情報を作成する。コンテンツ配信サーバ５は、作成した配信情報を端末装置３に送信する（ステップＳ１１）。
【００６６】
端末装置３は、ＲＳＳリーダを使用してコンテンツ配信サーバ５が管理しているＷｅｂページにアクセスしている際、配信情報を取得する（ステップＳ１２）。そして、端末装置３は、取得した配信情報に含まれるコンテンツのタイトルを、図４に示すような画面における記事一覧に表示する。また、タイトルがクリックされた際に、取得した配信情報に含まれるコンテンツＵＲＬにアクセスすることで、コンテンツを、図４に示すような画面における記事欄に表示する。換言すると、コンテンツ提供サーバ４が提供するＷｅｂページを、コンテンツとして記事欄に表示する。これにより、利用者は、ＲＳＳリーダを使用して属性情報に応じたコンテンツを容易に閲覧することができる。
【００６７】
なお、ＲＳＳリーダは、自動で定期的に、属性付加ＵＲＬにより、コンテンツ配信サーバ５が管理するＷｅｂページにアクセスする。つまり、端末装置３及びコンテンツ配信サーバ５は、その度に、ステップＳ６乃至ステップＳ１３の処理を繰り返し行う。換言すると、利用者は図２に示すような属性情報入力画面における属性情報の入力は１回行うだけでよい。よって、利用者が何度も属性情報を入力するといった負担を軽減することができる。
【００６８】
また、本実施形態では、図７に示すように、コンテンツ提供サーバ４及びコンテンツ配信サーバ５によるコンテンツ登録処理（ステップＳ１及びＳ２）が、説明の便宜上、端末装置３のコンテンツ表示処理（ステップＳ３乃至Ｓ１３）の前に行われている。しかし、本発明はこれに限定されるものではなく、コンテンツ登録処理により１つ以上のコンテンツが予め登録されていれば、コンテンツを追加するコンテンツ登録処理とコンテンツ表示処理の順番は入れ替わっても構わない。つまり、コンテンツ登録処理と、コンテンツ表示処理とはそれぞれ独立の処理である。
【００６９】
このように、本発明によれば、端末装置３が利用者の個人情報や趣味・嗜好情報といった属性情報をクエリ文字列として暗号化してＵＲＬに付加し、当該ＵＲＬをアクセスする度にコンテンツ配信サーバ５へ送信する。よって、コンテンツ配信サーバ５が、利用者の属性情報を記憶・管理することなく、従来のように属性情報に応じたコンテンツの提供を容易に行うことができる。また、利用者個人を識別する利用者ＩＤを使用していないため、各利用者を識別することなく属性情報に応じたコンテンツの提供を行うことができる。よって、個人情報の漏洩を防止し、ネットワーク２を利用したデータのやり取りにおけるセキュリティを強化することができる。
【００７０】
また、本発明によれば、コンテンツ配信サーバ５が端末装置３に送信する配信情報にはコンテンツ自体は含まれていない。よって、コンテンツ配信サーバ５は、コンテンツに関する情報として最低限当該コンテンツのＵＲＬさえ保持しておけば、コンテンツ自体を記憶・管理する必要がない。よって、コンテンツ配信サーバ５の負荷を軽減することができる。また、コンテンツを提供する企業としては、既存のＷｅｂページをコンテンツとして利用することができる。即ち、企業は、既存のコンテンツのＵＲＬに配信条件を設定するだけで、当該コンテンツを希望するターゲットへ配信することができるというメリットがある。
【００７１】
なお、本実施形態では、利用者がコンテンツを閲覧する際に、端末装置３が予め保有するＲＳＳリーダを使用している。しかし、本発明はこれに限定されるものではなく、Ｗｅｂ上のコンテンツの一部又は全部を表示可能なアプリケーションであれば任意のものを適用することができる。よって、端末装置３はコンテンツを表示するための特別なアプリケーションをインストールする必要はなく、汎用的なブラウザ等を利用して本発明を適用することができる。
【００７２】
[第２実施形態]
上記の第１実施形態では、端末装置３は、図２に示すような属性情報入力画面を使用し、利用者の個人情報や趣味・嗜好情報を属性情報として取得している。このとき、利用者は、属性情報入力画面に任意の情報を入力する必要がある。しかし、本発明はこれに限定されるものではなく、属性情報は、利用者が使用する端末装置のスペック情報等であってもよい。また、端末装置３は、予め自身のスペック情報を自動的に収集する収集アプリケーションを保有しており、当該収集アプリケーションにより属性情報を取得することとしてもよい。これによれば、利用者が所定の情報を入力することなく、自動的に属性情報を取得することができるため、利用者の負担を軽減することができる。
【００７３】
なお、コンテンツ配信サーバ５からダウンロードする等、端末装置３は任意の方法により収集アプリケーションを取得するものとする。また、第２実施形態では、スペック情報としてＯＳ（Operating System）、ＣＰＵ、ディスプレイ、メモリ及びＨＤＤ等を挙げているが、本発明はこれに限定されるものではなく、「バグを修正したか否か」等任意に設定することができる。
【００７４】
ここで、第２実施形態における配信システムについて図８及び図９を参照して説明する。図８は、収集アプリケーションにより自動的に収集されたスペック情報を表示するスペック情報表示画面の例である。また、図９は、第２実施形態における配信条件ＤＢのデータ構造を模式的に示す図である。
【００７５】
なお、コンテンツ提供サーバ４が、コンテンツ配信サーバ５に対して配信条件情報を送信し、コンテンツを登録するコンテンツ登録処理は第１実施形態と同様であるため、便宜上説明を省略する。
【００７６】
利用者は、端末装置３が予め保有している収集アプリケーションを起動することにより、スペック情報を収集する。具体的に、収集アプリケーションは、端末装置３のスペック情報を収集すると、図８に示すようなスペック情報表示画面を表示する。収集アプリケーションは、ボタンの押下など任意の方法により起動することができるものとする。このとき、端末装置３は、収集アプリケーションが収集したスペック情報を属性情報として取得する。図示のように、スペック情報とは、端末装置３のＯＳ、ＣＰＵ、ディスプレイ、メモリ及びＨＤＤ等の情報である。そして、端末装置３は、取得した属性情報をクエリ文字列に変換し、コンテンツ配信サーバ５が管理しているＷｅｂページのホームＵＲＬに付加することで、属性付加ＵＲＬを作成する。このとき、端末装置３は、公開鍵を利用して、クエリ文字列を暗号化してからホームＵＲＬに付加する。さらに、端末装置３は、ＲＳＳリーダにおいて新たに作成した属性付加ＵＲＬを登録し、ネットワーク２を介して当該属性付加ＵＲＬにアクセスする。この属性付加ＵＲＬは、コンテンツ配信サーバ５が管理しているＷｅｂページのホームＵＲＬに、変換した属性情報が付加されているものであるため、端末装置３は、コンテンツ配信サーバ５が管理している当該Ｗｅｂページにアクセスする。なお、端末装置３が作成した属性付加ＵＲＬは、スペック情報表示画面に表示される。
【００７７】
端末装置３がＷｅｂページにアクセスすることで、コンテンツ配信サーバ５は、端末装置３が作成した属性付加ＵＲＬを取得することができる。そして、端末装置３は、取得した属性付加ＵＲＬから暗号化されたクエリ文字列を抽出し、当該クエリ文字列を、秘密鍵を利用して復号することで、利用者の属性情報を抽出する。ここで、秘密鍵とは、端末装置３がクエリ文字列を暗号化した際に利用した公開鍵と対になっているものであり、予めコンテンツ配信サーバ５のみが有しているものである。さらに、端末装置３は、抽出した属性情報と、配信条件ＤＢに記憶された配信条件情報とをマッチングする。マッチングとは、取得した属性情報と、配信条件情報とを比較することにより、属性情報がどのコンテンツの配信条件に一致するかを判定することである。
【００７８】
ここで、配信条件ＤＢについて図９を参照して説明する。図９に示すように、配信条件ＤＢは、コンテンツＩＤ、商品、条件、対象及びコンテンツＵＲＬ等から構成されている。なお、図示されていないが、コンテンツのタイトルも含まれているものとする。コンテンツＩＤとは、各コンテンツを識別する情報である。商品とは、広告、リコール情報及びサポート情報の対象となるデジタルカメラやＨＤＤといった商品のことである。条件及び対象とは、コンテンツ配信対象となる端末装置３のスペック情報における条件と対象である。具体的に、スペック情報において「条件」が「対象」と合致する場合、当該スペック情報は、配信条件を満たすものと判断される。例えば、図９に示すような配信条件ＤＢの場合、コンテンツ配信サーバ５は、端末装置３のスペック情報において「モニタ種類」が「ＣＲＴ型」の場合、商品「液晶モニタ」のコンテンツにおける配信条件を満たしていると判断する。よって、商品「液晶モニタ」のコンテンツを、当該端末装置３を使用する利用者に提供する。つまり、マッチングの結果に基づいて、コンテンツ配信サーバ５は、商品「液晶モニタ」の広告が掲載されたＷｅｂページであるコンテンツのタイトル及びコンテンツＵＲＬといったコンテンツ情報を含む配信情報を作成し、端末装置３に送信する。
【００７９】
具体的に、本実施形態におけるマッチングは、ＸＳＬＴを使用して、ＸＭＬ化した属性情報及び配信条件情報を比較することにより行われる。そこで、ＸＳＬＴを使用したマッチングについて、ここで詳しく説明する。
【００８０】
ＸＳＬＴを使用したマッチングの場合、配信条件ＤＢ６は、図１０に示すような形式で、コンテンツＩＤ、タイトル、コンテンツＵＲＬ、配信条件等から構成されている。図１０は、ＸＭＬ化された配信条件ＤＢ６を示す図である。配信条件ＤＢ６を構成するコンテンツＩＤとは、各コンテンツを識別する情報である。また、配信条件とは、コンテンツを配信する場合の条件を記述したものであり、端末装置３のスペック情報と照らし合わせるものである。具体的に、配信条件は、図１１に示すようにＸＳＬＴで記述され、マッチングの際に配信条件ＤＢ６から抽出される。
【００８１】
次に、ＸＳＬＴを使用したマッチング処理について、図１２を参照して説明する。図１２は、ＸＳＬＴを使用したマッチング処理を説明する図である。コンテンツ配信サーバ５は、収集アプリケーションによりスペック情報、即ち属性情報を取得する。この属性情報（スペック情報）は、事前に決められたスキーマに従って、図１３に示すようにＸＭＬ化される。また、コンテンツ配信サーバ５は、配信条件ＤＢ６に格納されているコンテンツＩＤで紐付けられた一連の情報を順次取り出し、さらにその一連の情報から、図１１に示すようなＸＳＬＴ形式の配信条件を抽出する。さらに、コンテンツ配信サーバ５は、図１３に示すようなＸＭＬ化された属性情報（スペック情報）を、配信条件ＤＢ６から抽出したＸＳＬＴ形式の配信条件によって変換することでマッチングを行う。
【００８２】
マッチングの結果、属性情報（スペック情報）と配信条件が合致していれば、コンテンツ配信サーバ５は、コンテンツのタイトルとコンテンツＵＲＬをコンテンツ情報として配信条件ＤＢ６から抽出し、図１４に示すようなＲＳＳ形式の配信情報を作成する。一方、マッチングの結果、属性情報（スペック情報）と配信条件が合致していなければ、コンテンツ配信サーバ５は、特に何も行わない。このような処理をコンテンツＩＤ毎に繰り返すことで、コンテンツ配信サーバ５は、属性情報（スペック情報）にマッチしたコンテンツ情報のみを配信条件ＤＢ６から抽出し、配信情報を作成することができる。
【００８３】
例えば、図１０に示すような配信条件ＤＢ６の場合、コンテンツ配信サーバ５は、端末装置３のスペック情報において「モニタの種類がＣＲＴ型の場合」且つ「モニタのサイズが１５インチ以下の場合」に、タイトル「１７インチ液晶モニタ」のコンテンツを、配信情報として当該端末装置３を使用する利用者に提供する。つまり、マッチングの結果に基づいて、コンテンツ配信サーバ５は、タイトル「１７インチ液晶モニタ」の項目が掲載されたＷｅｂページであるコンテンツのタイトル及びコンテンツＵＲＬを含む配信情報を作成し、端末装置３に送信する。
【００８４】
端末装置３のＲＳＳリーダは、コンテンツ配信サーバ５から取得した配信情報を解釈し、表示画面において図４に示すように、当該配信情報に含まれるコンテンツのタイトルを日時等と共に記事一覧に表示する。また、ＲＳＳリーダは、タイトルがクリックされた場合には、当該配信情報に含まれるコンテンツＵＲＬにアクセスし、コンテンツを記事欄に表示する。ここで、記事欄に表示されるコンテンツとは、予めコンテンツ提供サーバ４が登録した図３に示すような広告やリコール情報等のＷｅｂページである。また、ＲＳＳリーダは、変換した属性情報を付加することで作成した属性付加ＵＲＬを登録しているため、サイト一覧には、当該属性付加ＵＲＬが表示されている。
【００８５】
なお、ＲＳＳリーダは、自動で定期的に、変換及び暗号化された属性情報を付加した属性付加ＵＲＬに基づいて、コンテンツ配信サーバ５が管理するＷｅｂページにアクセスする。このときの属性情報は、収集アプリケーションが最初に取得したスペック情報である。よって、端末装置３を買い換える等によりスペック情報が変化した場合には、再度収集アプリケーションにより新たなスペック情報を収集する必要がある。
【００８６】
このように、第２実施形態によれば、端末装置３は、収集アプリケーションを使用して自動的且つ容易に利用者の属性情報であるスペック情報を取得することができる。よって、利用者が、図２に示すような属性情報入力画面において所定の情報を入力する手間を省略することができる。
【００８７】
また、配信条件を図１３に示すようにＸＳＬＴを使用して表現することにより、容易に複数の配信条件を指定することが可能となる。例えば、配信条件を表で管理する場合、「液晶モニタの種類がＣＲＴ型」という１つの条件しか原則として指定することができない。そのため、配信条件を追加する場合には、カラムを増加する必要があり困難である。これに対し、配信条件をＸＳＬＴで表現すれば、図１１に示すように、複数の条件を柔軟に記述することが可能となる。特に、属性情報がスペック情報の場合はデバイス毎に様々な属性をとるため、複数条件を取ることがしばしば考えられる。よって、このようなＸＳＬＴを使用した配信条件の記述が特に有用となる。
【００８８】
また、コンテンツを提供する企業が家電量販店やメーカーの場合、利用者が使用しているパソコンやプリンタ等の機器環境に応じて広告やサポート情報を配信することが可能となる。よって、コンテンツを提供する企業は、ターゲットを絞って効率的な販売促進を行うことが可能となる。一方、利用者は、自身が使用する端末装置３のスペック情報に応じた広告やサポート情報を閲覧することができる。よって、モニタやメモリといった端末装置３の一部を買い換える際に、自身の要求に応じた的確な広告やサポート情報を容易に閲覧することができる。
【００８９】
なお、上記第１及び第２実施形態において、配信システムを構成するコンテンツ提供サーバ４は１つとしているが、本発明はこれに限定されるものではなく、複数の企業がコンテンツを登録している場合、配信システムを構成するコンテンツ提供サーバ４は企業毎に複数存在することしてもよい。
【００９０】
また、上記第１及び第２実施形態において、コンテンツはコンテンツ提供サーバ４が管理するＷｅｂページにアクセスすることにより端末装置３上で表示されることとなっているが、本発明はこれに限定されるものではなく、コンテンツはコンテンツ配信サーバ５が予めＤＢ等で記憶・管理しており、当該コンテンツ配信サーバ５が直接配信することにより端末装置３上で表示されることとしてもよい。
【産業上の利用可能性】
【００９１】
本発明は、属性情報を変換してクライアント側で保持することで、サーバ側が属性情報を保持することなく、属性情報に応じたコンテンツを配信することができる配信システムとして利用することができる。
【図面の簡単な説明】
【００９２】
【図１】本発明における配信システムの概略構成を示す図である。
【図２】属性情報入力画面の例である。
【図３】コンテンツであるＷｅｂページの例である。
【図４】ＲＳＳリーダを利用してコンテンツを表示した画面例である。
【図５】配信システムの機能ブロック図である。
【図６】第１実施形態における配信条件ＤＢのデータ構造を模式的に示す図である。
【図７】配信処理のフローチャートである。
【図８】スペック情報表示画面の例である。
【図９】第２実施形態における配信条件ＤＢのデータ構造を模式的に示す図である。
【図１０】ＸＭＬ化された配信条件ＤＢを示す図である。
【図１１】ＸＳＬＴ形式の配信条件を示す図である。
【図１２】ＸＳＬＴを使用したマッチング処理を説明する図である。
【図１３】ＸＭＬ化されたスペック情報を示す図である。
【図１４】ＲＳＳ形式の配信情報を示す図である。
【符号の説明】
【００９３】
２…ネットワーク
３…端末装置
４…コンテンツ提供サーバ
５…コンテンツ配信サーバ
６…配信条件ＤＢ
【図１】
2007072959.tif 000003
【図２】
2007072959.tif 000004
【図３】
2007072959.tif 000005
【図４】
2007072959.tif 000006
【図５】
2007072959.tif 000007
【図６】
2007072959.tif 000008
【図７】
2007072959.tif 000009
【図８】
2007072959.tif 000010
【図９】
2007072959.tif 000011
【図１０】
2007072959.tif 000012
【図１１】
2007072959.tif 000013
【図１２】
2007072959.tif 000014
【図１３】
2007072959.tif 000015
【図１４】
2007072959.tif 000016