JP5392267B2 - 情報処理装置、通信アドレス提供システムおよびそれに用いる方法並びにプログラム - Google Patents

情報処理装置、通信アドレス提供システムおよびそれに用いる方法並びにプログラム Download PDF

Info

Publication number
JP5392267B2
JP5392267B2 JP2010540374A JP2010540374A JP5392267B2 JP 5392267 B2 JP5392267 B2 JP 5392267B2 JP 2010540374 A JP2010540374 A JP 2010540374A JP 2010540374 A JP2010540374 A JP 2010540374A JP 5392267 B2 JP5392267 B2 JP 5392267B2
Authority
JP
Japan
Prior art keywords
communication address
communication
user
user terminal
providing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2010540374A
Other languages
English (en)
Other versions
JPWO2010061600A1 (ja
Inventor
岳明 南澤
奈津子 加川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to JP2010540374A priority Critical patent/JP5392267B2/ja
Publication of JPWO2010061600A1 publication Critical patent/JPWO2010061600A1/ja
Application granted granted Critical
Publication of JP5392267B2 publication Critical patent/JP5392267B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/48—Message addressing, e.g. address format or anonymous messages, aliases
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/212—Monitoring or handling of messages using filtering or selective blocking

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、通信サービスを提供するサーバである通信サービス提供サーバに対して、前記通信サービスの提供先となるユーザまたはユーザ端末を特定できる電子メールアドレスや電話番号などの通信アドレスの提供を行う情報処理装置、通信アドレス提供システム、通信アドレス提供方法および通信アドレス提供用プログラムに関する。
アンケートや懸賞サイトなどでユーザのメールアドレスや電話番号などの通信アドレスを取得して、ユーザの許諾の元、広告メールの配信や電話による勧誘通信を行う通信サービスがある。
ところが、メールアドレスや電話番号などの個人情報をサービス事業者に提供してしまうと、サービス事業者の個人情報漏洩事故やサービス事業者自身に悪意がある場合などに、提供したメールアドレスや電話番号を使用した迷惑メールや迷惑電話が頻繁に発生するようになるという問題があった。
このような問題を防止するために一時的な通信アドレスを作成するシステムが提案されている。例えば、特許文献１には、ユーザ端末からの要求に応じてそのユーザの既存のメールアドレスと対応づけた新しい一時的なメールアドレスを作成する通信システムが記載されている。
また、例えば、特許文献２には、簡単な操作により、必要な期間のみ利用可能な一時的な電子メールアドレスを用いて電子メールを使用することのできるアドレス変換システムが記載されている。
また、ＨＴＴＰプロキシサーバにおいて取得できるユーザを識別する情報を利用する技術に関連する事項が記載された文献として特許文献３がある。また、嗜好情報を利用してマーケティングサーバから広告を送信することを可能にする技術に関連する事項が記載された文献として特許文献４がある。
特開２００３−１４１０４２号公報 特開２００５−７２７０７号公報 特開２００２−０７３４３１号公報 特開２００３−２８１１７７号公報
しかし、特許文献１に記載されている通信システムや特許文献２に記載されているアドレス変換システムでは、ホームページのサイト運営者側がユーザに自発的にメールを送りたい場合には、ホームページの入力エリアでユーザにメールアドレスを入力してもらうか、ホームページに記載されたメールアドレス宛に本文の無い空メールを送信してもらうなどの方法によって、そのユーザに割り当てられている現在有効な一時的な通信アドレスを入手する必要があった。すなわち、そのような操作なしでは、ホームページに興味を示しているユーザに対してサービス事業者側が能動的に広告メールや広告電話などの通信サービスを行うことができないという問題があった。
また、特許文献３に記載されている方法は、ＨＴＴＰプロキシサーバを用いてユーザ端末のＨＴＴＰクライアントとＷＷＷサーバとの間でＨＴＴＰプロトコルにより通信が行われるＷＷＷサービスにおける性能を測定する方法であって、これらの情報を利用して、サービス事業者に与える通信サービスの送信権限の制御を行おうということは考慮されていない。すなわち、ＨＴＴＰプロキシサーバにおいて取得可能な情報を利用して、ホームページに興味を示しているユーザに対してサービス事業者側が能動的に広告メールを配信したり広告電話などの通信サービスを行えるようにすることは考慮されていない。
また、特許文献４に記載されている方法では、広告メールのＵＲＬが利用者によって指定されると、広告提供装置において、匿名で該利用者を特定可能な識別情報を生成し、その生成された識別情報を暗号化してＵＲＬに埋め込むことにより、そのＵＲＬから広告主のＵＲＬと利用者とを特定する。そして、特定された利用者の公開範囲に基づき個人情報を埋め込んだ要求として、広告主のＵＲＬに対してリダイレクトする。従って、本方法によれば、通信経路上で利用者は匿名であるが、広告主に対しては制限された公開範囲であるが個人情報が提供されることになる。すると、広告主の不注意等に起因して、提供した個人情報を使用した迷惑メールの配信や迷惑電話が生じる可能性が発生する。
そこで、本発明は、ユーザが特別な操作を行うことなく、かつ安全に、興味を示したホームページに関連する通信サービスを受けることができるように、サービス事業者に対して該ユーザまたは該ユーザが使用するユーザ端末を特定できる通信アドレスの提供を行う情報処理装置、通信アドレス提供システム、通信アドレス提供方法および通信アドレス提供用プログラムを提供することを目的とする。
本発明による情報処理装置は、通信サービスを提供するサーバである通信サービス提供サーバに対して、通信サービスの提供先となるユーザまたはユーザ端末を特定できる通信アドレスを提供する通信アドレス提供手段と、ユーザ端末とＷｅｂサーバとの間の通信経路上において受信したＨＴＴＰプロトコルによる通信データから、ユーザ端末のＨＴＴＰプロトコルによる通信の状況を示す情報として、Ｗｅｂサーバへのアクセス状況を示す情報と、アクセス元のユーザ端末またはアクセス元のユーザ端末を使用しているユーザを識別できる情報と、アクセス先のＷｅｂサーバを識別できる情報とを取得するＨＴＴＰプロトコル情報取得手段と、通信アドレス提供手段が提供する通信アドレスを、該通信アドレスで特定されるユーザまたはユーザ端末を識別できる情報と関連づけて記憶する通信アドレス記憶手段とを備え、通信アドレス提供手段は、ＨＴＴＰプロトコル情報取得手段によって取得されたユーザ端末のＨＴＴＰプロトコルによる通信の状況を示す情報に基づいて、アクセス先のＷｅｂサーバに関連づけられた通信サービス提供サーバに、アクセス元のユーザ端末またはアクセス元のユーザ端末を使用しているユーザを特定できる通信アドレスを提供することを特徴とする。
また、本発明による仮名通信アドレス提供システムは、通信サービスを提供するサーバである通信サービス提供サーバに対して、通信サービスの提供先となるユーザまたはユーザ端末を特定できる通信アドレスを提供する通信アドレス提供手段と、ユーザ端末とＷｅｂサーバとの間の通信経路上において受信したＨＴＴＰプロトコルによる通信データから、ユーザ端末のＨＴＴＰプロトコルによる通信の状況を示す情報として、Ｗｅｂサーバへのアクセス状況を示す情報と、アクセス元のユーザ端末またはアクセス元のユーザ端末を使用しているユーザを識別できる情報と、アクセス先のＷｅｂサーバを識別できる情報とを取得するＨＴＴＰプロトコル情報取得手段と、通信アドレス提供手段が提供する通信アドレスを、該通信アドレスで特定されるユーザまたはユーザ端末を識別できる情報と関連づけて記憶する通信アドレス記憶手段とを備え、通信アドレス提供手段は、ＨＴＴＰプロトコル情報取得手段によって取得されたユーザ端末のＨＴＴＰプロトコルによる通信の状況を示す情報に基づいて、アクセス先のＷｅｂサーバに関連づけられた通信サービス提供サーバに、アクセス元のユーザ端末またはアクセス元のユーザ端末を使用しているユーザを特定できる通信アドレスを提供することを特徴とする。
また、本発明による仮名通信アドレス提供方法は、通信サービスを提供するサーバである通信サービス提供サーバに対して、通信サービスの提供先となるユーザまたはユーザ端末を特定できる通信アドレスを提供するための通信アドレス提供方法であって、ユーザ端末とＷｅｂサーバとの間の通信経路上において受信したＨＴＴＰプロトコルによる通信データから、通信アドレスの割り当て対象となるユーザ端末またはユーザが使用するユーザ端末のＨＴＴＰプロトコルによる通信の状況を示す情報として、Ｗｅｂサーバへのアクセス状況を示す情報と、アクセス元のユーザ端末またはアクセス元のユーザ端末を使用しているユーザを識別できる情報と、アクセス先のＷｅｂサーバを識別できる情報とを取得し、取得したユーザ端末のＨＴＴＰプロトコルによる通信の状況を示す情報に基づいて、アクセス先のＷｅｂサーバに関連づけられた通信サービス提供サーバに、アクセス元のユーザ端末またはアクセス元のユーザ端末を使用しているユーザを特定できる通信アドレスを提供し、提供する通信アドレスを、該通信アドレスで特定されるユーザまたはユーザ端末を識別できる情報と関連づけて記憶装置に記憶させることを特徴とする。
また、本発明による仮名通信アドレス提供用プログラムは、通信サービスを提供するサーバである通信サービス提供サーバに対して、通信サービスの提供先となるユーザまたはユーザ端末を特定できる通信アドレスを提供するための通信アドレス提供用プログラムであって、コンピュータに、ユーザ端末とＷｅｂサーバとの間の通信経路上において受信したＨＴＴＰプロトコルによる通信データから、通信アドレスの割り当て対象となるユーザ端末またはユーザが使用するユーザ端末のＨＴＴＰプロトコルによる通信の状況を示す情報として、Ｗｅｂサーバへのアクセス状況を示す情報と、アクセス元のユーザ端末またはアクセス元のユーザ端末を使用しているユーザを識別できる情報と、アクセス先のＷｅｂサーバを識別できる情報とを取得する処理、および取得したユーザ端末のＨＴＴＰプロトコルによる通信の状況を示す情報に基づいて、アクセス先のＷｅｂサーバに関連づけられた通信サービス提供サーバに、アクセス元のユーザ端末またはアクセス元のユーザ端末を使用しているユーザを特定できる通信アドレスを提供する処理を実行させることを特徴とする。
本発明によれば、ユーザは、特別な操作を行うことなく、かつ安全に、興味を示したホームページに関連する通信サービスを受けることができる。また、サービス事業者は、興味を示しているユーザに、能動的に、広告メールや電話による販促活動を実施することができる。
第１の実施形態の仮名通信アドレス提供システムの構成例を示すブロック図である。 仮名通信アドレス管理部３３が保持するデータの例を示す説明図である。 通信アドレス管理部２１が保持するデータの例を示す説明図である。 第１の実施形態の仮名通信アドレス提供システムの動作の一例を示すシーケンス図である。 第１の実施形態の仮名通信アドレス提供システムの動作の一例を示すシーケンス図である。 第２の実施形態による仮名通信アドレス提供システムの構成例を示すブロック図である。 仮名通信アドレス提供条件管理部３４が保持するデータの例を示す説明図である。 仮名通信アドレス提供条件管理部３４が保持するデータの他の例を示す説明図である。 第２の実施形態における仮名通信アドレス管理部３３で保持されるデータの例を示す説明図である。 第２の実施形態の仮名通信アドレス提供システムの動作の一例を示すシーケンス図である。 第３の実施形態による仮名通信アドレス提供システムの構成例を示すブロック図である。 ユーザ嗜好情報管理部３５が保持するデータの例を示す説明図である。 第３の実施形態における仮名通信アドレス提供条件管理部３４で保持されるデータの例を示す説明図である。 第３の実施形態の仮名通信アドレス提供システムの動作の一例を示すシーケンス図である。 第４の実施形態による仮名通信アドレス提供システムの構成例を示すブロック図である。 アクセス履歴管理部３６が保持するデータの例を示す説明図である。 アクセス履歴管理部３６が保持するデータの例を示す説明図である。 第４の実施形態における仮名通信アドレス提供条件管理部３４に保持されるデータの例を示す説明図である。 第４の実施形態における仮名通信アドレス管理部３３に保持されるデータの例を示す説明図である。 第４の実施形態の仮名通信アドレス提供システムの動作の一例を示すシーケンス図である。 第４の実施形態の仮名通信アドレス提供システムの動作の一例を示すシーケンス図である。 第５の実施形態による仮名通信アドレス提供システムの構成例を示すブロック図である。 一時ユーザＩＤ管理部７２が保持するデータの例を示す説明図である。 第５の実施形態におけるアクセス履歴管理部３６が保持するデータの例を示す説明図である。 第５の実施形態の仮名通信アドレス提供システムの動作の一例を示すシーケンス図である。 本発明の概要を示すブロック図である。 本発明による情報処理装置１の他の構成例を示すブロック図である。 本発明による仮名通信アドレス提供システムの概要を示すブロック図である。 本発明による仮名通信アドレス提供システムの構成例を示すブロック図である。
以下、発明を実施するための最良の形態について図面を参照して説明する。
実施形態１．
図１は、本発明の第１の実施形態の仮名通信アドレス提供システムの構成例を示すブロック図である。図１に示す仮名通信アドレス提供システムは、ユーザ端末１０と、メールサーバ２０と、ＨＴＴＰプロキシサーバ３０と、Ｗｅｂサーバ４１と、通信サービス提供サーバ４２とを備えている。また、ユーザ端末１０と、メールサーバ２０と、ＨＴＴＰプロキシサーバ３０と、Ｗｅｂサーバ４１と、通信サービス提供サーバ４２とは、それぞれインターネットやＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）などのネットワーク６０を介して接続されている。ネットワークへの接続は、有線方式でも無線方式でもよい。
ユーザ端末１０は、パーソナルコンピュータ（以下、ＰＣという。）や携帯電話機などの情報処理端末であり、電子メールの送受信が行えるメールクライアント１２（より具体的には、メールクライアント・アプリケーション１２を実行する処理部）と、ホームページなどのコンテンツの取得を行うラウザ１１（より具体的には、ブラウザ・アプリケーション１１を実行する処理部）とを有している。
メールクライアント１２は、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）プロトコルやＰＯＰ（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ）などのプロトコルを用いて、後述するメールサーバ２０との間で電子メールの送受信を行うアプリケーションである。
ブラウザ１１は、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）プロトコルを用いて、後述するＷｅｂサーバ４１からホームページなどのコンテンツを取得して表示するアプリケーションである。
メールサーバ２０は、ＳＭＴＰプロトコルやＰＯＰなどのプロトコルを用いて、他のメールサーバおよびメールクライアントとの間で電子メールの送受信を行うサーバ装置である。また、本実施形態では、通信アドレス管理部２１と通信アドレス変換部２２とを有している。
通信アドレス変換部２２は、電子メールの送信先または送信元を示すメールアドレスについて、後述するＨＴＴＰプロキシサーバ３０の仮名通信アドレス管理部３３が生成する仮名通信アドレスとユーザ端末のメールクライアントが使用する実通信アドレスとを変換する。
本実施形態では、仮名通信アドレスおよび実通信アドレスの形式が、メールアドレスの形式であるとして説明する。なお、仮名通信アドレスおよび実通信アドレスの形式は、これに限らず、電話番号やＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍｓ）で使用されるＳＩＰ−ＵＲＩ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ−Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）の形式であってもよい。
通信アドレス管理部２１は、各ユーザのユーザ端末のアプリケーションが利用する実通信アドレスを保持する。本実施の形態の例において、各ユーザのユーザ端末の通信アプリケーションはメールクライアントであり、実通信アドレスをメールアドレスとする。通信アドレス管理部２１は、例えば、ＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ ＤａｔａＢａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ：リレーショナルＤＢ管理システム）などのデータベースシステムで実現できる。
ＨＴＴＰプロキシサーバ３０は、ＨＴＴＰプロトコル情報取得部３１と、仮名通信アドレス提供部３２と、仮名通信アドレス管理部３３とを有している。
ＨＴＴＰプロトコル情報取得部３１は、一般的なＨＴＴＰプロキシサーバが具備する機能に加えて、ブラウザから受信したＨＴＴＰプロトコルによる通信データから、ユーザＩＤとＷｅｂサーバＩＤの情報を取得するとともに、あるユーザ端末１０のブラウザ１１からあるＷｅｂサーバ４１へのアクセス状況を検出する。また、あるユーザ端末１０のブラウザ１１があるＷｅｂサーバ４１と接続中の間、取得したユーザＩＤとＷｅｂサーバＩＤとを対応づけて保持する。
ここで、一般的なＨＴＴＰプロキシサーバが具備する機能とは、例えば、企業内のネットワークとインターネットとの間に設置され、企業内のＰＣからホームページへアクセスさせるときに必ずＨＴＴＰプロキシサーバを経由させることによって、高速なアクセスを確保するためのデータキャッシュや安全な通信を確保するためのフィルター処理などである。
ユーザＩＤは、ユーザまたはユーザ端末を識別するための情報であり、例えば、ユーザ端末が携帯電話機ならばＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｉｙ Ｍｏｄｕｌｅ）カードによって付与され、電話番号やメールアドレスを特定するための固有のＩＤであるＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｉｙ）などが利用できる。また、ＰＣの場合は、ＨＴＴＰプロトコルのユーザ認証を利用して、ユーザＩＤを特定してもよい。
ＨＴＴＰプロトコルのユーザ認証は、インターネットで利用されるプロトコル技術の標準化を策定するＩＥＴＦ（Ｉｎｔｅｒｎａｌ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）でＨＴＴＰプロトコルの標準仕様であるＲＦＣ２０６８で定義されており、ユーザにＰＣの画面上でユーザ名とパスワードを入力させることによって、ユーザを特定することでＨＴＴＰプロキシサーバの利用を特定のユーザのみに限定するなどの用途に用いられている。
ＷｅｂサーバＩＤは、後述するＷｅｂサーバを識別するための情報であり、例えば、ＷｅｂサーバのＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｅｒｖｅｒ）で使用される完全修飾ドメイン名であるＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）や、ＦＱＤＮの一部であるドメイン名，サブドメイン名，ホスト名や、ＷｅｂサーバのＩＰアドレスなどが利用できる。
また、本実施形態では、ＨＴＴＰプロトコルの情報を取得する通信装置の例としてＨＴＴＰプロシキサーバ３０を示しているが、ＨＴＴＰプロトコルの情報を取得する通信装置は、これに限らず、ＯＳＩ７階層モデルにおけるトランスポート層（レイヤ４）からアプリケーション層（レイヤ７）のプロトコルを監視するＤＰＩ（Ｄｅｅｐ Ｐａｃｋｅｔ Ｉｎｓｐｅｃｔｉｏｎ）などで実現してもよい。
仮名通信アドレス提供部３２は、ＨＴＴＰプロトコル情報取得部３１が検出するユーザ端末１０からＷｅｂサーバ４１へのアクセス状況に基づいて、仮名通信アドレス管理部３３に仮名通信アドレスを生成させたり、生成させた仮名通信アドレスを通信サービス提供サーバ４２に提供したり、または削除させたりする。
仮名通信アドレス管理部３３は、仮名通信アドレス提供部３２からの要求に従って、指定されたユーザＩＤとＷｅｂサーバＩＤとの組み合わせに対して、仮名通信アドレスを生成する。また、仮名通信アドレス管理部３３は、仮名通信アドレスが有効である間、生成する際に指定されたユーザＩＤとＷｅｂサーバＩＤとの組み合わせに関連付けて仮名通信アドレスを保持する。仮名通信アドレスを保持する機能については、例えば、ＲＤＢＭＳなどのデータベースシステムで実現できる。
また、本実施形態では、ＨＴＴＰプロキシサーバで仮名通信アドレスを発行し、メールサーバで実通信アドレスへの変換を行うことにより、サービス事業者にのみユーザまたはユーザ端末とのコミュニケーションを可能とする仮名通信アドレスを提供しているが、仮名通信アドレスと実通信アドレスの対応づけを行うことなしに、ユーザ端末と通信サービス提供サーバの両方へ仮名通信アドレスを提供することも可能である。
Ｗｅｂサーバ４１は、ユーザ端末１０からのＨＴＴＰプロキシサーバ３０を経由して受信するＨＴＴＰのリクエストに応じて、ホームページなどのコンテンツを出力する。
通信サービス提供サーバ４２は、ＨＴＴＰプロキシサーバ３０の仮名通信アドレス提供部３２から提供される仮名通信アドレスを利用して、広告やインフォメーションなどの情報をユーザ端末に向けて送信する。本実施形態では、提供された仮名通信アドレスを宛て先アドレスとする電子メールをメールサーバ２０に送信する。
また、本実施形態では、通信サービス提供サーバ４２を、広告メールを送信するメール送信サーバとして説明するが、通信サービス提供サーバは、これに限らず、ユーザ端末であってもよい。例えば、ブログ（Ｂｌｏｇ）の開設者をサービス事業者として捉え、該開設者が使用するユーザ端末を通信サービス端末とみなして、該ユーザ端末（ブログ開設者の端末）に、該ブログを閲覧したユーザまたはユーザ端末（ブログ閲覧者の端末）へのコミュニケーションを可能とする仮名通信アドレスを提供することもできる。このような場合には、ブログ閲覧者がブログ開設者に現実の通信アドレス（実通信アドレス）を開示することなく、ブログ開設者からブログ閲覧者への電子メールの送付などの通信サービスが可能となる。
図２は、仮名通信アドレス管理部３３が保持するデータの例を示す説明図である。図２では、仮名通信アドレス管理部３３が保持するデータの構成として、ユーザＩＤ（３３１）とＷｅｂサーバＩＤ（３３２）と仮名通信アドレス（３３３）の項目を有する例が示されている。
また、図３は、通信アドレス管理部２１が保持するデータの例を示す説明図である。図３では、通信アドレス管理部２１が保持するデータの構成として、ユーザＩＤ（２１１）と、実通信アドレス（２１２）の項目を有する例が示されている。
本実施形態の例では、メールサーバ２０とＨＴＴＰプロキシサーバ３０を携帯会社や固定電話会社などの同じ通信事業者が運営するものとして説明する。従って、メールサーバ２０が保持するユーザＩＤ（２１１）と、ＨＴＴＰプロキシサーバ３０が保持するユーザＩＤ（３３１）とは、同一のユーザまたはユーザ端末を示すものとする。
ただし、メールサーバ２０とＨＴＴＰプロキシサーバ３０の運営者は、これに限らず、異なる事業主であってもよい。この場合、メールサーバ２０が保持するユーザＩＤ（２１１）と、ＨＴＴＰプロキシサーバ３０が保持するユーザＩＤ（３３１）とは同一のユーザまたはユーザ端末を指し示す場合であっても異なる値となるが、このような場合には、事業者が異なるユーザＩＤ同士で予め関連づけを行えばよい。例えば、メールサーバ２０の事業者とＨＴＴＰプロキシサーバ３０の事業者との間で同一のユーザまたはユーザ端末を指し示す新たな仮名のユーザＩＤを提示し、お互いの事業者でこの仮名のユーザＩＤと本来のユーザＩＤを関連付けてもよい。このような仕組みは、標準化団体であるＯＡＳＩＳによって策定されたＩＤやパスワードを安全にやり取りされるＸＭＬ仕様であるＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などを用いて一般的に利用されている。
次に、ＨＴＴＰプロトコル情報取得部３１によるユーザ端末からＷｅｂサーバへのアクセス状況の検出方法について説明する。本実施形態では、説明を簡単にするために、ユーザ端末１０は、ブラウザ１１の機能を利用して、Ｗｅｂサーバ毎に１本のＨＴＴＰ Ｋｅｅｐ Ａｌｉｖｅを使用するものとする。そして、ＨＴＴＰプロトコル情報取得部３１は、取得した通信データにより示されるＨＴＴＰ Ｋｅｅｐ Ａｌｉｖｅがユーザ端末（ブラウザ）とＷｅｂサーバ間に確立している間をホームページ接続中、ＨＴＴＰ Ｋｅｅｐ Ａｌｉｖｅの切断をホームページからの切断として検出する。ＨＴＴＰ Ｋｅｅｐ Ａｌｉｖｅは、１回のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）接続で複数のＨＴＴＰリクエストを処理する機能であり、その仕様はＲＦＣ２６１６で規定されている。
また、ホームページへの接続中および切断の検出方法の別の例として、ユーザが一度認証を受けるだけで許可されているすべてのＷｅｂサーバが利用できるようになるシングルサインオンと連携して、ホームページへの接続およびホームページからの切断を検出してもよい。シングルサインオンを実現するために、既に説明したＳＡＭＬなどを利用できる。
例えば、事前に通信事業者（ここでは、ＨＴＴＰプロキシサーバとメールサーバの運用事業者）と、Ｗｅｂサービス事業者（Ｗｅｂサーバの運用者や通信サービス提供サーバの運用者）の各ユーザＩＤをＩＤ Ｆｅｄｅｒａｔｉｏｎという技術で紐付けする。その際、テンポラリーな仮ユーザＩＤが発行される。また、ユーザ端末から通信事業者へのログイン操作がされた場合には、通信事業者側でその旨を保持しておく。その後、ユーザ端末からＷｅｂサービス事業者へのアクセスを契機に、Ｗｅｂサービス事業者から通信事業者へ仮ユーザＩＤを指定してログイン済みのユーザか否かの問い合わせが行われる。通信事業者は、仮ユーザＩＤに紐付けたログイン状態をＷｅｂサービス事業者へ提示する。
このようなシングルサインオンの動作において、ユーザ端末に、ＨＴＴＰプロキシサーバを利用する前提としてシングルサインオンのログインを求め、Ｗｅｂサービス事業者（より具体的には、Ｗｅｂサーバ）から通信事業者（より具体的には、ＨＴＴＰプロキシサーバ）へのログイン状況の問い合わせにより、ホームページのアクセス開始を認識することができる。
また、シングルサインオンには、一括でログイン状態を解消するシングルサインオフという動作もあるので、シングルサインオフが実施されたときには、ホームページからの切断と判断することも可能である。
さらに、ホームページからの切断の検出方法は、これらに限らず、ユーザ端末が携帯電話機のような無線通信装置の場合は、ユーザ端末と無線基地局との間の無線リンクを制御するＵＴＲＡＮ（ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）において検出される無線リンクの切断により判断してもよい。また、ＨＴＴＰプロトコルのアクセス状況としてＨＴＴＰプロトコルの転送が一定時間行わなかったことを計時手段によって検出することで切断と判断してもよい。また、ユーザ端末から切断を示す信号を別途受信する方法で切断を検出してもよい。
次に、本実施形態の動作について説明する。図４および図５は、本実施形態の仮名通信アドレス提供システムの動作の一例を示すシーケンス図である。なお、図４は、仮名通信アドレスの発行に係る動作例を示すシーケンス図である。また、図５は、仮名通信アドレスの失効に係る動作例を示すシーケンス図である。なお、図４および図５において、破線矢印で示すメッセージは、受信したリクエストに対するレスポンスであることを表している。
図４に示すように、まず、ユーザ端末１０のブラウザ１１（より具体的には、ブラウザ・アプリケーション実行部１１）は、ユーザ操作に応じて、指定されたホームページを取得するためのＨＴＴＰリクエストをＷｅｂサーバ４１に向けて送信する（ステップＳ１０１）。本例では、ユーザＩＤとして”ｕｓｅｒ０００１”が割り当てられているユーザ端末１０のブラウザ１１から、ＵＲＬ”ｈｔｔｐ：／／ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ／ｂｏｏｋｉｎｇ＿ｓｅｒｖｉｃｅ．ｈｔｍｌ”にアクセスした場合を例に説明する。
ユーザ端末１０から送信されたＨＴＴＰリクエストは、直接Ｗｅｂサーバ４１に受信されるのではなく、ＨＴＴＰプロキシサーバ３０のＨＴＴＰプロトコル情報取得部３１に受信される。ＨＴＴＰプロキシサーバの経由方法としては、例えば、ブラウザの設定で直接ＨＴＴＰプロキシサーバのアドレスやポート番号を指定してもよいし、ルータやブリッジにおいて特定のポート番号を監視して後段のＨＴＴＰプロキシサーバへプロトコルを転送（リダイレクト）することによって、ブラウザで特別な設定をせずにＨＴＴＰプロキシサーバを利用できるようにする透過型プロキシ（Ｔｒａｎｓｐａｒｅｎｔ Ｐｒｏｘｙ）として実現してもよい。
ＨＴＴＰプロキシサーバ３０のＨＴＴＰプロトコル情報取得部３１は、ユーザ端末１０からＷｅｂサーバ４１へのＨＴＴＰプロトコルによる通信データ（ここでは、ＨＴＴＰリクエスト）を受信すると、受信した通信データのＨＴＴＰプロトコルにより特定されるユーザＩＤとＷｅｂサーバＩＤを取得するとともに、本通信データがＨＴＴＰリクエストであることを検知し、取得したユーザＩＤで識別されるユーザ端末１０（またはユーザが使用しているユーザ端末）から同じく取得したＷｅｂサーバＩＤで識別されるＷｅｂサーバ４１へのアクセス状況をホームページ接続中として検出する（ステップＳ１０２）。そして、取得したユーザＩＤとＷｅｂサーバＩＤを含むホームページ接続通知により仮名通信アドレス提供部３２へ該組み合わせにおけるアクセス状況を通知する（ステップＳ１０３）。本例では、ユーザＩＤとして”ｕｓｅｒ０００１”を、ＷｅｂサーバＩＤとしてＵＲＬ”ｈｔｔｐ：／／ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ／ｂｏｏｋｉｎｇ＿ｓｅｒｖｉｃｅ．ｈｔｍｌ”のＦＱＤＮである”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”を含むホームページ接続通知を仮名通信アドレス提供部３２に出力する。
なお、ＨＴＴＰプロトコル情報取得部３１と仮名通信アドレス提供部３２との間のデータのやりとりには、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）とＨＴＴＰなどをベースとしたＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）などを利用してもよい。
その後、ＨＴＴＰプロトコル情報取得部３１は、送信元であるユーザ端末１０のブラウザ１１の代理として、アクセス先であるＷｅｂサーバ４１にＨＴＴＰリクエストを送信する（ステップＳ１０４）。
Ｗｅｂサーバ４１は、ＨＴＴＰプロキシサーバ３０を経由してユーザ端末１０からのＨＴＴＰリクエストを受信する。Ｗｅｂサーバ４１は、受信したＨＴＴＰリクエストを解析して、必要なホームページなどのコンテンツをＨＴＴＰレスポンスとして返信する（ステップＳ１０５）。
Ｗｅｂサーバ４１から送信されるＨＴＴＰレスポンスは、ＨＴＴＰプロキシサーバ３０のＨＴＴＰプロトコル情報取得部３１に受信される。ＨＴＴＰプロトコル情報取得部３１は、Ｗｅｂサーバ４１から受信したＨＴＴＰレスポンスを本来の送信元であるユーザ端末１０のブラウザに返信する（ステップＳ１０６）。
ユーザ端末１０のブラウザ１１は、ＨＴＴＰレスポンスを受信すると、そのＨＴＴＰレスポンスに含まれるホームページなどのコンテンツをディスプレイに表示する。
また一方で、仮名通信アドレス提供部３２は、ＨＴＴＰプロトコル情報取得部３１からホームページ接続通知を受信すると、そのホームページ接続通知に含まれるユーザＩＤとＷｅｂサーバＩＤとを指定して、仮名通信アドレス管理部３３に仮名通信アドレスの生成を依頼する。本例では、受信したホームページ接続通知に含まれるユーザＩＤ”ｕｓｅｒ０００１”とＷｅｂサーバＩＤ”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”とを含む仮名通信アドレスの生成リクエストを仮名通信アドレス管理部３３に送信する（ステップＳ１０７）。
仮名通信アドレスの生成リクエストを受信した仮名通信アドレス管理部３３は、その取得リクエストに含まれているユーザＩＤとＷｅｂサーバＩＤの組み合わせに対して、仮名通信アドレスが既に関連づけられていなければ、新たに仮名通信アドレスを生成する（ステップＳ１０８）。例えば、仮名通信アドレス管理部３３は、指定されたユーザＩＤとＷｅｂサーバＩＤの組み合わせに対して、新たな仮名通信アドレスの関連付けを行えばよい。関連づける仮名通信アドレスは、仮名通信アドレスの取得リクエストの受信を契機に、乱数を用いて生成してもよいし、事前に用意してある未使用の仮名通信アドレスから選択してもよい。本例では、ユーザＩＤ”ｕｓｅｒ０００１”とＷｅｂサーバＩＤ”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”の組み合わせに対して、仮名通信アドレス”ｔｅｍｐ０００２＠ｃａｒｒｉｅｒ．ｃｏｍ”の関連付けを実施したとする。
仮名通信アドレスの関連づけを完了すると、仮名通信アドレス管理部３３は、指定されたユーザＩＤとＷｅｂサーバＩＤに対して関連づけた仮名通信アドレス（本例では、”ｔｅｍｐ０００２＠ｃａｒｒｉｅｒ．ｃｏｍ”）を含む仮名通信アドレスの生成レスポンスを仮名通信アドレス提供部３２に返信する（ステップＳ１０９）。なお、仮名通信アドレス管理部３３は、仮名通信アドレスの生成リクエストを受信した際に、既に指定されたユーザＩＤとＷｅｂサーバＩＤの組に対して仮名通信アドレスが関連づけられていた場合には、仮名通信アドレスが提供済みである旨を返信すればよい。
仮名通信アドレスの生成レスポンスを受信した仮名通信アドレス提供部３２は、生成リクエストで指定したＷｅｂサーバＩＤに予め関連づけられている通信サービス提供サーバ４２へ、生成された仮名通信アドレスを提供する。本例では、仮名通信アドレス提供部３２は、仮名通信アドレス”ｔｅｍｐ０００２＠ｃａｒｒｉｅｒ．ｃｏｍ”を含む仮名通信アドレスの払出通知を、ＷｅｂサーバＩＤから求まる通信サービス提供サーバ４２に送信する（ステップＳ１１０）。仮名通信アドレスの送信先となる通信サービス提供サーバ４２は、例えば、ＷｅｂサーバＩＤのＦＱＤＮから通信サービス提供サーバ４２のＦＱＤＮを自動生成する規則を定義しておき、その規則に基づいて求めてもよい。
例えば、ＷｅｂサーバＩＤがＦＱＤＮの場合、ホスト名である”ｗｗｗ”を”ｐｓｅｕｄｏｎｙｍ”に置換するという自動生成する規則を定義しておくことにより、ＷｅｂサーバＩＤ”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”から通信サービス提供サーバのＦＱＤＮである” ｐｓｅｕｄｏｎｙｍ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”を求めることができる。
また、例えば、ＷｅｂサーバＩＤが”１９２．１６８．１２２．１３９”といったＩＰアドレスであった場合、ＷｅｂサーバＩＤのＩＰアドレスに対して、ＴＣＰのポート番号”：８０９０”を限定することにより、通知先の通信サービス提供サーバのアドレス（本例では、”１９２．１６８．１２２．１３９：８０９０”）とする自動生成の規則を提示してもよい。
通信サービス提供サーバ４２では、仮名通信アドレス提供部３２からの仮名通信アドレスの払出通知を受けて、その払出通知に含まれる仮名通信アドレスを、そのＷｅｂページに興味を示したユーザのアドレスとして利用することができるようになる。例えば、通信サービス提供サーバ４２は、仮名通信アドレスを用いて広告メールなどの通信サービスを行ってもよい。本例では、仮名通信アドレス”ｔｅｍｐ０００２＠ｃａｒｒｉｅｒ．ｃｏｍ”を電子メールの宛先アドレスに指定して送信する（ステップＳ１１１）。
通信サービス提供サーバ４２から送信された電子メールは、メールサーバ２０が受信する。電子メールを受信したメールサーバ２０では、その電子メールの宛先アドレスが仮名通信アドレスであることを受けて、通信アドレス変換部２２が、実通信アドレスへの変換を行う。本例では、通信アドレス変換部２２は、電子メールの宛先アドレスから仮名通信アドレスを取得して、ＨＴＴＰプロキシサーバ３０の仮名通信アドレス管理部３３へ、取得した仮名通信アドレス（ここでは、”ｔｅｍｐ０００２＠ｃａｒｒｉｅｒ．ｃｏｍ”）を指定したユーザＩＤの取得リクエストを送信する（ステップＳ１１２）。
仮名通信アドレス管理部３３は、自身で保持している、仮名通信アドレスとユーザＩＤとＷｅｂサーバＩＤとを関連付けた情報を検索して、指定された仮名通信アドレス”ｔｅｍｐ０００２＠ｃａｒｒｉｅｒ．ｃｏｍ”に対応するユーザＩＤ”ｕｓｅｒ０００１”を解決して、要求元の通信アドレス変換部２２に、得られたユーザＩＤ”ｕｓｅｒ０００１”を含むユーザＩＤの取得レスポンスを返信する（ステップＳ１１３）。なお、該当するユーザＩＤが存在しなければ、通信アドレス変換部２２に、ユーザＩＤの取得が失敗した旨を通知する。
通信アドレス変換部２２は、ユーザＩＤの取得レスポンスを受信すると、ユーザＩＤが解決したことを受けて、そのユーザＩＤから実通信アドレスを解決する。本例では、受信したユーザＩＤの取得レスポンスに含まれるユーザＩＤ（ここでは、”ｕｓｅｒ０００１”）を指定して、通信アドレス管理部２１に実通信アドレスの取得リクエストを送信する（ステップＳ１１４）。なお、ユーザＩＤの取得に失敗した旨の返信を受けた場合には、通信サービス提供サーバ４２（メールの送信元）に、メールの送信が失敗した旨を通知して処理を終了すればよい。
実通信アドレスの取得リクエストを受信した通信アドレス管理部２１は、指定されたユーザＩＤ”ｕｓｅｒ０００１”を検索キーとして実通信アドレスを解決して、要求元の通信アドレス変換部２２に、得られた実通信アドレスを含む実通信アドレスの取得レスポンスを返信する（ステップＳ１１５）。本例では、ユーザＩＤ”ｕｓｅｒ０００１”に対して、実通信アドレス”ａｌｉｃｅ＠ｃａｒｒｉｅｒ．ｃｏｍ”が通信アドレス管理部２１に関連づけられて保持されていたとする。通信アドレス管理部２１は、実通信アドレスとして、実通信アドレス”ａｌｉｃｅ＠ｃａｒｒｉｅｒ．ｃｏｍ”を含む実通信アドレスのレスポンスを通信アドレス変換部２２に返信する（ステップＳ１１５）。
通信アドレス変換部２２は、通信アドレス管理部２１からの実通信アドレスのレスポンスを受けて、受信した電子メールの宛先アドレスとして付与されている仮名通信アドレス”ｔｅｍｐ０００２＠ｃａｒｒｉｅｒ．ｃｏｍ”を、実通信アドレス”ａｌｉｃｅ＠ｃａｒｒｉｅｒ．ｃｏｍ”に変換し、その実通信アドレスによって特定されるユーザ端末１０に電子メールを到達させる（ステップＳ１１６，Ｓ１１７）。
ユーザ端末１０では、メールクライアント１２が、電子メールを受信し、その内容をディスプレイなどに表示する。これによって、ユーザは、自身が興味を示したホームページに関連するサービス事業者からの情報提供サービスを実通信アドレスを開示することなく受けることができる。
また、サービス事業者に提供した仮名通信アドレスは、次のように失効させてもよい。例えば、ユーザがブラウザ１１でのホームページの閲覧を終了すると、ユーザ端末１０のブラウザ１１は、ＨＴＴＰプロキシサーバ３０へＴＣＰ切断通知を送信する（図５のステップＳ２０１）。
ＨＴＴＰプロキシサーバ３０のＨＴＴＰプロトコル情報取得部３１は、ユーザ端末１０からＷｅｂサーバ４１へのＨＴＴＰプロトコルによる通信データ（ここでは、ＴＣＰ切断通知）を受信すると、受信した通信データのＨＴＴＰプロトコルにより特定されるユーザＩＤとＷｅｂサーバＩＤを取得するとともに、本通信データがＴＣＰ切断通知であることを検知し、取得したユーザＩＤで識別されるユーザ端末１０（またはユーザが使用しているユーザ端末）から同じく取得したＷｅｂサーバＩＤで識別されるＷｅｂサーバ４１へのアクセス状況を切断として検出する（ステップＳ２０２）。そして、取得したユーザＩＤとＷｅｂサーバＩＤを含むホームページ切断通知により仮名通信アドレス提供部３２へ該組み合わせにおけるアクセス状況を通知する。本例では、切断されるＴＣＰセッションと現在関連づけられているユーザＩＤ”ｕｓｅｒ０００１”とＷｅｂサーバＩＤ”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”とを含むホームページ切断通知を仮名通信アドレス提供部３２に送信する（ステップＳ２０３）。
また、ＨＴＴＰプロトコル情報取得部３１は、ユーザ端末１０とＷｅｂサーバ４１との間に張ったＴＣＰセッションを切断する。ここでは、Ｗｅｂサーバ４１へＴＣＰ切断通知を送信する（ステップＳ２０４）。なお、ＴＣＰセッションの完全な切断手順は、ＴＣＰセッションを張っている両方の装置からＦＩＮと呼ばれる終了信号を送信し合うことによって行われるが、ここでは説明を省略する。
ホームページ切断通知を受信した仮名通信アドレス提供部３２は、通知されたユーザＩＤとＷｅｂサーバＩＤの組み合わせに対して現在関連づけられている仮名通信アドレスの削除を仮名通信アドレス管理部３３に依頼する。本例では、通知されたユーザＩＤ”ｕｓｅｒ０００１”とＷｅｂサーバＩＤ”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”とを含む仮名通信アドレスの削除リクエストを仮名通信アドレス管理部３３に送信する（ステップＳ２０５）。
仮名通信アドレスの削除リクエストを受信した仮名通信アドレス管理部３３は、自身で保持している情報において、受信した仮名通信アドレスの削除リクエストに含まれるユーザＩＤ（ここでは、”ｕｓｅｒ０００１”）とＷｅｂサーバＩＤ（ここでは、”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”）の組に現時点で関連づけられている仮名通信アドレスを削除し、削除結果を仮名通信アドレス提供部３２に返信する（ステップＳ２０５）。このとき、仮名通信アドレス管理部３３は、関連付けられている仮名通信アドレスの情報のみを削除してもよいし、ユーザＩＤとＷｅｂサーバＩＤと仮名通信アドレスを含むレコード全体（行）を削除してもよい。
以上のように、本実施形態によれば、ユーザ端末１０によるブラウザ１１を用いたＷｅｂサーバへのＨＴＴＰプロトコルによるアクセスの状況に基づいて、仮名通信アドレスを、該Ｗｅｂサーバが公開しているＷｅｂページに関連する通信サービス提供サーバに提供することができる。
これにより、該通信サービス提供サーバを運用しているサービス事業者は、ユーザ端末がホームページに接続している間だけ、仮名通信アドレスを用いたユーザ端末への電子メール等による広告の配信が可能になる。また、ユーザにとっても、興味を示したＷｅｂページに関連するサービス事業者（例えば、該Ｗｅｂページを運用しているサービス事業者）から、個人情報を開示することなく、広告などの電子メールを受け取ることができる。
実施形態２．
次に、本発明の第２の実施形態について説明する。本実施形態では、ＨＴＴＰプロキシサーバにおいて、ユーザ端末から送信されるＨＴＴＰリクエストに対して、仮名通信アドレスの提供有無や提供先とするサービス事業者を設定する。
図６は、第２の実施形態による仮名通信アドレス提供システムの構成例を示すブロック図である。図６に示す仮名通信アドレス提供システムは、第１の実施形態と比べて、ＨＴＴＰプロキシサーバ３０がさらに仮名通信アドレス提供条件管理部３４を有する点が異なる。
仮名通信アドレス提供条件管理部３４は、仮名通信アドレスを提供する条件となるアクセス元のＷｅｂサーバの情報を保持する。仮名通信アドレス提供条件管理部３４は、例えば、ＲＤＢＭＳなどのデータベースシステムで実現できる。図７は、仮名通信アドレス提供条件管理部３４が保持するデータの例を示す説明図である。図７では、仮名通信アドレス提供条件管理部３４が保持するデータの構成として、ＷｅｂサーバＩＤ（３４１）と、通信サービス提供サーバアドレス（３４２）の項目を有する例が示されている。
通信サービス提供サーバアドレス（３４２）は、仮名通信アドレスの提供先となる通信サービス提供サーバのネットワークアドレスを登録する。なお、通信サービス提供サーバアドレス（３４３）には、仮名通信アドレスを受信することができるネットワークアドレスを登録する。本例では、通信サービス提供サーバアドレスにＦＱＤＮおよびＩＰアドレスを格納した。もちろん通信サービス提供サーバアドレスは、これに限定されずに、ＳＯＡＰで通信先のアドレスやサービスに用いられるメッセージのフォーマットやプロトコルなどを示すＷＳＤＬ（Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）などのＷｅｂサービス記述言語のデータ形式で格納することも可能である。
なお、図７に示す例では、仮名通信アドレスの提供の契機となるＷｅｂサーバＩＤと仮名通信アドレスの提供先となる通信サービス提供サーバのアドレスとを直接に関連付けることにより、仮名通信アドレスの提供の契機となるＷｅｂサーバを絞り込む例である。なお、Ｗｅｂサーバの絞り込み方法はこれに限定されるものではなく、例えば、ＷｅｂサーバＩＤに対して、提供の有無を示す情報を関連付けてもよい。また、Ｗｅｂサーバの事業主を示すＩＤを関連付けてもよい。
また、例えば、図８に示すように、仮名通信アドレスの提供の契機となるＷｅｂサーバＩＤと、仮名通信アドレスの提供先となる通信サービス提供サーバを運営している事業主を示すＩＤとを関連付けてもよい。図８は、仮名通信アドレス提供条件管理部３４が保持するデータの他の例を示す説明図である。図８では、仮名通信アドレス提供条件管理部３４が保持するデータの構成として、ＷｅｂサーバＩＤ（３４１）と、サービス事業者ＩＤ（３４３）と、通信サービス提供サーバアドレス（３４２）の項目を有する例が示されている。
サービス事業者ＩＤ（３４３）は、ＷｅｂサーバＩＤが示すホームページへのアクセスを契機に通信サービスを行うことを許可する事業者を識別するための情報であって、仮名通信アドレスの提供先となる通信サービス提供サーバを運営している事業者を識別するための情報である。このサービス事業者は、Ｗｅｂサーバの運営者と同じであっても、異なっていてもよい。また、本例のように、複数のＷｅｂサーバＩＤ”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ１．ｃｏ．ｊｐ”と”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ２．ｃｏ．ｊｐ”とに対して、１つのサービス事業者ＩＤ”ｓｅｒｖｉｃｅ０００１”を関連づけることも可能である。なお、１つのＷｅｂサーバＩＤに複数のサービス事業者を対応づけることも可能である。また、この例では、複数のＷｅｂサーバＩＤを格納するための区切り記号として、改行コードを入れて表現した。もちろん区切り記号はこれに限定されず、空白文字、句読点、特殊文字その他の区切りを示す記号であればよい。
また、図９は、本実施形態における仮名通信アドレス管理部３３で保持されるデータの例を示す説明図である。本実施形態では、仮名通信アドレス管理部３３は、図９に示すように、ＷｅｂサーバＩＤ（３３２）に代えて、仮名通信アドレス提供条件管理部３４により通信先の識別情報として用いられる通信サービス提供サーバアドレス（３３２Ｂ）の項目を有するデータ構成であってもよい。なお、通信サービス提供サーバアドレスではなく、サービス事業者ＩＤとすることも可能である。
また、本実施形態では、仮名通信アドレス提供部３２は、ユーザ端末がホームページにアクセスしたことを受けて、そのホームページを公開しているＷｅｂサーバの情報から無条件に仮名通信アドレスを提供するのではなく、仮名通信アドレス提供条件管理部３４に保持されている情報に基づいて、そのＷｅｂサーバが仮名通信アドレスの契機となるＷｅｂサーバか否かを判断した上で、仮名通信アドレスを提供する。
次に、本実施形態の動作について説明する。図１０は、本実施形態の仮名通信アドレス提供システムの動作の一例を示すシーケンス図である。なお、本例において、ＨＴＴＰのリクエストを送信してＷｅｂサーバからホームページの情報を受信するまでのユーザ端末１０、ＷｅｂサーバおよびＨＴＴＰプロトコル情報取得部３１の動作（ステップＳ３０１〜３０６）は、第１の実施形態（ステップＳ１０１〜１０６）と同様であるため、説明省略する。以下、本例では、ユーザＩＤ”ｕｓｅｒ０００１”のユーザ端末が、ＷｅｂサーバＩＤ”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”のＷｅｂサーバにアクセスした場合を例に説明する。
ステップＳ３０７において、ＨＴＴＰプロトコル情報取得部３１からホームページ接続通知を受信した仮名通信アドレス提供部３２は、仮名通信アドレス提供条件管理部３４に、そのホームページ接続通知に含まれるＷｅｂサーバＩＤ（”ここでは、”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”）を指定した通信サービス提供サーバアドレスの取得リクエストを送信する。なお、仮名通信アドレス提供条件管理部３４が保持するデータが図８に示すようなデータ構成であれば、サービス事業者ＩＤの取得リクエストであってもよい。
通信サービス提供サーバアドレスの取得リクエストを受信した仮名通信アドレス提供条件管理部３４は、保持しているデータの中から、指定されたＷｅｂサーバＩＤと対応づけられている通信サービス提供サーバアドレスを求めて、通信サービス提供サーバアドレスの取得レスポンスとして仮名通信アドレス提供部３２に返信する（ステップＳ３０８）。例えば、図７に示す例では、ＷｅｂサーバＩＤ”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”に対して、通信サービス提供サーバアドレス”ａｄａｇｅｎｃｙ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”を求めて、それを返信すればよい。
このとき、仮名通信アドレス提供条件管理部３４において、仮名通信アドレス管理部３３より通知されたＷｅｂサービスＩＤに対して、対応する通信サービス提供サーバアドレスが存在しなかった場合には、該当する通信サービス提供サーバアドレスが存在しなかった旨を仮名通信アドレス提供部３２に返信すればよい。
通信サービス提供サーバアドレスの取得レスポンスを受信した仮名通信アドレス提供部３２は、該当する通信サービス提供サーバアドレスが存在すれば、その通信サービス提供サーバアドレスに向けて、仮名通信アドレスの提供を行えばよい。なお、仮名通信アドレスの提供は、通信サービス提供サーバアドレスの取得レスポンスに含まれる通信サービス提供サーバアドレスに、仮名通信アドレス管理部３３に生成させた仮名通信アドレスを送信することにより行えばよい。仮名通信アドレスの生成動作は、第１の実施形態と基本的には同様でよいが、ステップＳ３０９においては、仮名通信アドレスの生成リクエストにＷｅｂサーバＩＤを指定する代わりに、通信サービス提供サーバアドレス（またはサービス事業者ＩＤ）を指定して送信する。また、仮名通信アドレス管理部３３では、ユーザＩＤと通信サービス提供サーバアドレス（またはサービス事業者ＩＤ）の組に対して仮名通信アドレスの関連づけを行い、関連づけた仮名通信アドレスを返信すればよい（ステップＳ３１０，Ｓ３１１）。なお、仮名通信アドレス管理部３３は、仮名通信アドレスの取得リクエストを受信した際に、既に指定されたユーザＩＤと通信サービス提供サーバアドレス（またはサービス事業者ＩＤ）の組に対して既に仮名通信アドレスが存在していた場合には、仮名通信アドレスが提供済みである旨を返信すればよい。
一方、仮名通信アドレス提供条件管理部３４からの通信サービス提供サーバアドレスの取得レスポンスにおいて、該当する通信サービス提供サーバアドレスが存在しなかった場合には、仮名通信アドレス提供部３２は、以降の仮名通信アドレスの提供処理は行わずに処理を終了する。これにより、仮名通信アドレス提供条件管理部３４に登録されていないＷｅｂサーバへのアクセスを仮名通信アドレスの提出の契機として扱わないようにことができる。
また、仮名通信アドレス提供部３２は、仮名通信アドレスが提供済みである旨を仮名通信アドレス管理部３３から返信された場合には、本処理における仮名通信アドレスの提供は行わずに、そのまま処理を終了する。同一のユーザについて再度の仮名通信アドレスの提供は不要だからである。これ以降の動作は、第１の実施形態と同じである。
以上のように、本実施形態によれば、ユーザ端末１０によるブラウザ１１を用いたＷｅｂサーバへのＨＴＴＰプロトコルによるアクセスのうち、仮名通信アドレスの提供先とするサービス事業者と、仮名通信アドレスの提出先としないサービス事業者を区別することを可能にする。
また、アクセス先となるＷｅｂサーバと通知先となる通信サービス提供サーバとの関連付けをシステム運営者側で自由に設定することができるので、仮名通信アドレスの提供先とするサービス事業者が、複数のＦＱＤＮによるＷｅｂサーバを運用していても、同一サービス事業者に対して仮名通信アドレスの重複した提供を除外することができる。なお、他の点に関しては、第１の実施形態と同様である。
実施形態３．
次に、本発明の第３の実施形態について説明する。本実施形態では、ＨＴＴＰプロキシサーバにおいて、ホームページへのアクセス状況だけでなく、ユーザの嗜好情報とを基に、仮名通信アドレスの提供先とするサービス事業者を決定する。
図１１は、第３の実施形態による仮名通信アドレス提供システムの構成例を示すブロック図である。図１１に示す仮名通信アドレス提供システムは、第２の実施形態と比べて、ＨＴＴＰプロキシサーバ３０がさらにユーザ嗜好情報管理部３５を有する点が異なる。
ユーザ嗜好情報管理部３５は、ユーザの嗜好情報を保持する。ユーザ嗜好情報管理部３５は、例えば、ＲＤＢＭＳなどのデータベースシステムで実現できる。図１２は、ユーザ嗜好情報管理部３５が保持するデータの例を示す説明図である。図１２では、ユーザ嗜好情報管理部３５が保持するデータの構成として、ユーザＩＤ（３５１）と、サービスカテゴリ（３５２）の項目を有する例が示されている。
ここで、ユーザＩＤ（３５１）は、ＨＴＴＰプロトコル情報取得部３１により取得されるユーザＩＤであって、本システムの利用者であるユーザまたはユーザ端末を識別するための情報である。また、サービスカテゴリ（３５２）は、ユーザが興味を持っている情報サービスのカテゴリを示す情報である。図１２では、ユーザＩＤ”ｕｓｅｒ０００１”が興味を持っている情報サービスのカテゴリとして、”ディナー，車，カメラ，天体”が登録されている例が示されている。図１２に示す例では、複数のサービスカテゴリを格納するための区切り記号として、「，」コードを入れて表現した。もちろん区切り記号はこれに限定されず、空白文字、句読点、特殊文字その他の区切りを示す記号であればよい。
また、図１３は、本実施形態における仮名通信アドレス提供条件管理部３４で保持されるデータの例を示す説明図である。本実施形態では、仮名通信アドレス提供条件管理部３４は、図１３に示すように、さらに仮名通信アドレスの提供条件として、ＷｅｂサーバＩＤが示すホームページのサービスカテゴリ（３４４）の項目を追加している。サービスカテゴリ（３４４）は、そのＷｅｂサーバＩＤが示すホームページが提供している情報サービスのカテゴリを示す情報である。例えば、そのホームページがどのようなカテゴリの情報を提供するサービスを行うかが示される。
また、仮名通信アドレス提供部３２は、ユーザ端末がホームページにアクセスしたことを受けて、そのホームページのサービスカテゴリが、アクセスしたユーザの嗜好情報に合致する場合にのみ仮名通信アドレスを提供する。
次に、本実施形態の動作について説明する。図１４は、本実施形態の仮名通信アドレス提供システムの動作の一例を示すシーケンス図である。なお、本例においても、ＨＴＴＰのリクエストを送信してＷｅｂサーバからホームページの情報を受信するまでのユーザ端末１０、ＷｅｂサーバおよびＨＴＴＰプロトコル情報取得部３１の動作は、第１の実施形態（ステップＳ１０１〜１０６）と同様であるため、説明を省略する。以下、本例では、ユーザＩＤ”ｕｓｅｒ０００１”のユーザ端末が、ＷｅｂサーバＩＤ”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”のＷｅｂサーバにアクセスした場合を例に説明する。
ＨＴＴＰプロトコル情報取得部３１からホームページ接続通知を受信した仮名通信アドレス提供部３２は、まず、アクセス先となったＷｅｂサーバに関する仮名通信アドレスの提供条件を確認する。本例では、仮名通信アドレス提供条件管理部３４に、そのホームページ接続通知に含まれるＷｅｂサーバＩＤ（”ここでは、”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ２．ｃｏ．ｊｐ”）を指定した提供条件の取得リクエストを送信する（ステップＳ４０１）。
提供条件の取得リクエストを受信した仮名通信アドレス提供条件管理部３４は、保持しているデータの中から、指定されたＷｅｂサーバＩＤと対応づけられている通信サービス提供サーバアドレス（３４２）およびサービスカテゴリ（３４４）を求めて、提供条件の取得レスポンスとして仮名通信アドレス提供部３２に返信する（ステップＳ４０２）。例えば、図１３に示す例では、ＷｅｂサーバＩＤ”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”に対して、通信サービス提供サーバアドレス”ａｄａｇｅｎｃｙ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”とサービスカテゴリ”ディナー，ランチ”を求めて、それを返信すればよい。
また、仮名通信アドレス提供部３２は、ユーザ嗜好情報管理部３５に、ホームページ接続通知に含まれるユーザＩＤを指定して、ユーザ嗜好情報の取得リクエストを送信する（ステップＳ４０３）。なお、仮名通信アドレス提供条件管理部３４からの返信において、該当する通信サービス提供サーバが存在しなかった場合には、ユーザ嗜好情報の取得リクエストを送信せずに処理を終了してもよい。
ユーザ嗜好情報の取得リクエストを受信したユーザ嗜好情報管理部３５は、指定されたユーザＩＤ”ｕｓｅｒ０００１”に関連付けられているサービスカテゴリ（３５２）を求めて、ユーザ嗜好情報の取得レスポンスとして仮名通信アドレス提供部３２に返信する（ステップＳ４０４）。例えば、図１３に示す例では、ユーザＩＤ”ｕｓｅｒ０００１”に対して、サービスカテゴリ”ディナー，車，カメラ，天体”を求めて、それを返信すればよい。
仮名通信アドレス提供部３２は、提供条件の取得レスポンスに含まれるＷｅｂサーバのサービスカテゴリの情報と、ユーザ嗜好情報の取得レスポンスに含まれるユーザの興味を示すサービスカテゴリの情報とを比較して、両者で一致するものを抽出する（ステップＳ４０５）。本例において、一致するサービスカテゴリは”ディナー”である。
そして、仮名通信アドレス提供部３２は、比較した結果、一致するサービスカテゴリが存在するならば、当該のユーザＩＤと通信サービス提供サーバとの組み合わせに対して、仮名通信アドレス提供部３２に、仮名通信アドレスの生成を依頼する。なお、仮名通信アドレスの生成に係る処理以降の動作は、第２の実施形態と同様である。一方、一致するサービスカテゴリが存在しない場合には、仮名通信アドレスの提供に係る以降の一連の動作は行わずに処理を終了すればよい。
なお、本実施形態では、仮名通信アドレス提供部３２は、仮名通信アドレスを通信サービス提供サーバに提供する際に、その仮名通信アドレスを利用可能なサービスカテゴリを指定してもよい。例えば、ユーザが興味を示すカテゴリとして登録されているユーザのサービスカテゴリとサービス事業者のサービスカテゴリとの間で一致するサービスカテゴリについてのみ情報提供サービスを利用可能であるとして、そのサービスカテゴリ（本例では”ディナー”）を指定してもよい。
以上のように、本実施形態によれば、さらにユーザの嗜好情報を基に、仮名通信アドレスの提供先とするサービス事業者を決定するので、仮名通信アドレスを用いた通信サービスにおいてユーザが興味を示すカテゴリの情報を提供することができる。
実施形態４．
次に、本発明の第４の実施形態について説明する。本実施形態では、ＨＴＴＰプロキシサーバにおいて、ＨＴＴＰプロトコルによるホームページアクセスの履歴を保持し、そのアクセス履歴を基に、通信サービス提供サーバからのリクエストに応じて、仮名通信アドレスの払い出しを行う。
図１５は、第４の実施形態による仮名通信アドレス提供システムの構成例を示すブロック図である。図１５に示す仮名通信アドレス提供システムは、第３の実施形態と比べて、ＨＴＴＰプロキシサーバ３０がさらにアクセス履歴管理部３６を有する点が異なる。
アクセス履歴管理部３６は、ＨＴＴＰプロトコル情報取得部３１が検出するユーザ端末からＷｅｂサーバへのアクセスの状況を履歴にして保持する。アクセス履歴管理部３６は、例えば、ＲＤＢＭＳなどのデータベースシステムで実現できる。図１６および図１７は、アクセス履歴管理部３６が保持するデータの例を示す説明図である。図１６および図１７では、アクセス履歴管理部３６が保持するデータの構成として、ホームページ接続時刻（３６１）と、ホームページ切断時刻（３６２）と、ユーザＩＤ（３６３）と、ＷｅｂサーバＩＤ（３６４）の項目を有する例が示されている。なお、図１６において、ホームページ切断（３６２）における”--”は、ホームページへのアクセスが以前接続中であることが示している。
ここで、ホームページ接続時刻（３６１）は、ユーザがホームページへのアクセス（接続）を開始した日時である。これは、例えば、ＨＴＴＰプロトコル情報取得部３１がホームページの接続を検出した日時でよい。また、例えば、仮名通信アドレス提供部３２がＨＴＴＰプロトコル情報取得部３１からホームページ接続通知を受け付けた日時であってもよい。
また、ホームページ切断時刻（３６２）は、ユーザがホームページへのアクセスを切断した日時である。これは、例えば、ＨＴＴＰプロトコル情報取得部３１がホームページからの切断を検出した日時でよい。また、例えば、仮名通信アドレス提供部３２が、ＨＴＴＰプロトコル情報取得部３１からホームページ切断通知を受け付けた日時であってもよい。
また、ユーザＩＤ（３６３）は、ユーザまたはユーザ端末を識別する情報である。また、ＷｅｂサーバＩＤ（３６４）は、Ｗｅｂサーバを識別する情報である。
また、図１８は、本実施形態における仮名通信アドレス提供条件管理部３４に保持されるデータの例を示す説明図である。本実施形態では、仮名通信アドレス提供条件管理部３４は、図１８に示すように、さらに仮名通信アドレスの提供条件として、アクセス時間による利用可能回数（３４５）の項目を追加している。アクセス時間による利用可能回数（３４５）は、仮名通信アドレスを利用可能な回数を示す情報であって、その仮名通信アドレスの提供の契機となったホームページのアクセス時間に応じて規定される情報である。
また、図１９は、本実施形態における仮名通信アドレス管理部３３に保持されるデータの例を示す説明図である。仮名通信アドレス提供条件管理部３４において仮名通信アドレスの提供条件としてアクセス時間による利用可能回数が設けられている場合には、仮名通信アドレス提供部３２は、仮名通信アドレスを生成してユーザＩＤと通信サービス提供サーバアドレス（またはサービス事業者ＩＤ）の組と関連づける際に、さらに利用可能回数（３３４）を保持する。この利用可能回数（３３４）の値によって、登録されている仮名通信アドレスがあとどれくらい利用可能かが示される。
また、仮名通信アドレス提供部３２は、ユーザ端末１０によるホームページのアクセスを契機に仮名通信アドレスを払い出すのではなく、通信サービス提供サーバからのリクエストに応じて、仮名通信アドレスの払い出しを行う。その際、アクセス履歴管理部３６に保持されているアクセス履歴を基に、どのユーザに対する仮名通信アドレスを提供するか、また提供する仮名通信アドレスの利用制限について求める。
次に、本実施形態の動作について説明する。図２０および図２１は、本実施形態の仮名通信アドレス提供システムの動作の一例を示すシーケンス図である。なお、図２０は、アクセス履歴の登録に係る動作例を示すシーケンス図である。また、図２１は、仮名通信アドレスの提供に係る動作例を示すシーケンス図である。
まず、アクセス履歴の登録に係る動作について説明する。図２０に示すように、本実施形態では、ユーザ端末１０のブラウザ１１より、ホームページの情報を取得するためのＨＴＴＰリクエストがＷｅｂサーバに向けて送信されると（ステップＳ５０１）、それを受信したＨＴＴＰプロキシサーバ３０のＨＴＴＰプロトコル情報取得部３１は、受信したＨＴＴＰリクエストからユーザＩＤとＷｅｂサーバＩＤを取得するとともに、ホームページ接続を検出し（ステップＳ５０２）、ホームページ接続通知をアクセス履歴管理部３６に出力する（ステップＳ５０３）。本例では、ＨＴＴＰリクエストからユーザＩＤ”ｕｓｅｒ０００１”とＷｅｂサーバＩＤ”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”とを取得したものとして説明する。
なお、ＨＴＴＰプロトコル情報取得部３１は、第１の実施形態と同様に、送信元であるユーザ端末１０のブラウザ１１の代理として、アクセス先であるＷｅｂサーバ４１にＨＴＴＰリクエストを送信する（ステップＳ５０４）。ＨＴＴＰリクエストに係る以降のＷｅｂサーバ４１およびユーザ端末１０の動作（ステップＳ５０５，Ｓ５０６）は、第１の実施形態と同様である。
一方、ホームページ接続通知を受信したアクセス履歴管理部３６は、通知されたユーザＩＤとＷｅｂサーバＩＤとを用い、さらに現在日時をホームページ接続時刻（３６１）として、履歴情報を作成し、記憶領域に格納する（ステップＳ５０７）。なお、この時点では、ホームページ接続時刻（３６２）を空とする（図１６参照。）。
また、ユーザがブラウザ１１でのホームページの閲覧を終了すると、ユーザ端末１０は、ＨＴＴＰプロキシサーバ３０へＴＣＰ切断通知を送信する（ステップＳ６０１）。
ＴＣＰ切断通知を受信したＨＴＴＰプロキシサーバ３０では、ＨＴＴＰプロトコル情報取得部３１が、ＴＣＰセッションを切断するとともに、ホームページへのアクセス状況を切断として検出し（ステップＳ６０２）、取得したユーザＩＤおよびＷｅｂサーバＩＤを指定したホームページ切断通知をアクセス履歴管理部３６に送信する（ステップＳ６０３）。また、Ｗｅｂサーバ４１へＴＣＰ切断通知を送信する（ステップＳ６０４）。
ホームページ切断通知を受信したアクセス履歴管理部３６は、通知されたユーザＩＤとＷｅｂサーバＩＤとを用い、保持しているアクセス履歴の中から同じ組み合わせの現在接続中の履歴情報（行）を検索して、現在日時をホームページ切断時刻（３６２）として格納する（ステップＳ６０５）。なお、現在接続中か否かは、ホームページ接続時刻（３６２）の値が空になっているか否かで判断すればよい。
次に、仮名通信アドレスの提供に係る動作について説明する。図２１に示すように、本実施形態では、通信サービス提供サーバ４２から、ＨＴＴＰプロキシサーバ３０の仮名通信アドレス提供部３２への仮名通信アドレスの取得リクエストの送信を契機に、仮名通信アドレスの提供を行う。なお、通信サービス提供サーバ４２からの仮名通信アドレスの取得リクエストの送信タイミングは、任意である。
ステップＳ７０１において、通信サービス提供サーバ４２から、当該通信サービス提供サーバ４２のアドレス（またはサービス事業者ＩＤ）を含む仮名通信アドレスの取得リクエストが送信されると、ＨＴＴＰプロキシサーバ３０の仮名通信アドレス提供部３２は、アクセス履歴管理部３６に保持されているアクセス履歴を基に、どのユーザに対する仮名通信アドレスを提供するか、また提供する仮名通信アドレスの利用可能回数等について決定する。以下では、通信サービス提供サーバアドレスとして”ａｄａｇｅｎｃｙ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”が指定された場合を例に説明する。
まず、仮名通信アドレス提供部３２は、仮名通信アドレスの取得リクエストに含まれる通信サービス提供サーバアドレスを指定して、仮名通信アドレス提供条件管理部３４に、その通信サービス提供サーバアドレスを提出先とする際の提供条件の取得リクエストを送信する（ステップＳ７０２）。なお、ここでの提供条件には、少なくともその通信サービス提供サーバアドレスを提出先とするＷｅｂサーバＩＤの情報を含むものとする。
提供条件の取得リクエストを受信した仮名通信アドレス提供条件管理部３４は、指定された通信サービス提供サーバアドレスが提出先（３４２）として登録されているＷｅｂサーバＩＤ（３４１）と、サービスカテゴリ（３４４）およびアクセス時間による利用可能回数（３４５）を取得して、提供条件の取得レスポンスとして仮名通信アドレス提供部３２に返信する（ステップＳ７０３）。例えば、図１８に示す例では、ＷｅｂサーバＩＤ”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”と、サービスカテゴリ”ディナー，ランチ”と、アクセス時間による利用可能回数”１５分”を含む提供情報の取得レスポンスが送信される。
返信を受けた仮名通信アドレス提供部３２は、提供情報の取得レスポンスに含まれるＷｅｂサーバＩＤを指定して、アクセス履歴管理部３６に、そのＷｅｂサーバＩＤによって識別されるホームページに係るアクセス履歴の取得リクエストを送信する（ステップＳ７０４）。
アクセス履歴の取得リクエストを受信したアクセス履歴管理部３６は、保持しているアクセス履歴の中から、指定されたＷｅｂサーバＩＤと一致するアクセス履歴を取得し、アクセス履歴の取得レスポンスにして、仮名通信アドレス提供部３２に返信する（ステップＳ７０５）。アクセス履歴の取得レスポンスは、返信先である仮名通信アドレス提供部３２において、その履歴に登録されているアクセス者としてのユーザＩＤとホームページへのアクセス時間（接続時間）とが特定可能な情報を含んでいればよい。例えば、図１７に示す例では、ＷｅｂサーバＩＤ”ｗｗｗ．ｒｅｓｔａｕｎｒａｎｔ．ｃｏ．ｊｐ”が一致するアクセス履歴として、１番目のレコードの情報と４番目のレコードの情報が通知されればよい。なお、現在も接続中である場合は、現時点までの時刻でアクセス時間が特定されるようにしてもよい。
アクセス履歴の取得レスポンスを受信した仮名通信アドレス提供部３２は、アクセス履歴の取得レスポンスにより取得したアクセス履歴の中から、Ｗｅｂサーバへのアクセス者であるユーザＩＤ毎に、指定したＷｅｂサーバＩＤが示すＷｅｂサーバへの総合的なアクセス時間を計算する。本例では、ユーザＩＤ”ｕｓｅｒ０００１”について、１番目のレコードの情報からアクセス時間１７分（２００８／０７／２３ １９：４９−２００８／０７／２３ １９：３２）と、４番目のレコードの情報からアクセス時間１５分（２００８／０７／２４ １９：４７−２００８／０７／２４ １９：３２）の合計であるアクセス時間３２分が計算で求まる。
次いで、求めたこの総合的なアクセス時間（本例では、３２分）と、仮名通信アドレス提供条件管理部３４から取得したアクセス時間による利用可能回数（３４５）とを基に、提供する仮名通信アドレスで可能とする利用可能回数を決定する。本例では、ＷｅｂサーバＩＤ”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”に関連づけられているアクセス時間による利用可能回数は１５分であるため、３２分を１５分で除算した結果、仮名通信アドレスの利用可能回数を２（小数点以下切り捨て）として定義する。ここで、求めた利用可能回数が１未満の場合は、当該ユーザＩＤに対応する仮名通信アドレスの提供は行わないこととする（ステップＳ７０６）。すなわち、求めた利用可能回数が１以上のユーザＩＤを仮名通信アドレスの対象候補として決定する。
次に、仮名通信アドレス提供部３２は、アクセス履歴が示すアクセス時間によって仮名通信アドレスの対象候補となったユーザＩＤを指定して、ユーザ嗜好情報の取得リクエストを送信する（ステップＳ７０７）。本例では、ユーザＩＤ”ｕｓｅｒ０００１”を指定したユーザ嗜好情報の取得リクエストを送信する。なお、仮名通信アドレスの対象候補となったユーザＩＤが複数存在する場合には、それら全てのユーザＩＤを指定してユーザ嗜好情報の取得リクエストを送信してもよいし、ユーザＩＤ別にユーザ嗜好情報の取得リクエストを複数送信してもよい。
ユーザ嗜好情報の取得リクエストを受信したユーザ嗜好情報管理部３５は、通知されたユーザＩＤと関連づけられているサービスカテゴリ（３５２）を検索して、返信する（ステップＳ７０８）。
返信を受けた仮名通信アドレス提供部３２は、仮名通信アドレス提供条件管理部３４から取得した要求元通信サービス提供サーバに関連づけられているＷｅｂサーバのサービスカテゴリと、ユーザ嗜好情報管理部３５から取得した対象候補として決定したユーザＩＤと関連づけられちるサービスカテゴリとを比較し、一致するカテゴリがあるか否かを確認する（ステップＳ７０９）。ここで一致するカテゴリがない場合は、そのユーザＩＤについての仮名通信アドレスの提供は行わない。
一致するカテゴリがある場合には、仮名通信アドレス提供部３２は、カテゴリが一致したユーザＩＤと、要求元である通信サービス提供サーバのアドレスと、利用可能回数とを指定して、仮名通信アドレス管理部３３に仮名通信アドレスの生成リクエストを送信する（ステップＳ７１０）。なお、提供の対象とされるユーザＩＤが複数存在する場合には、複数のユーザＩＤを指定した仮名通信アドレスの生成リクエストを送信してもよいし、ユーザＩＤ別に仮名通信アドレスの生成リクエストを複数送信してもよい。
仮名通信アドレスの生成リクエストを受信した仮名通信アドレス管理部３３は、指定されたユーザＩＤの数分、指定されたユーザＩＤと通信サービス提供サーバアドレスの組み合わせに対して、仮名通信アドレスを生成して関連づける（ステップＳ７１１）。さらに、利用可能回数が指定されている場合には、指定された利用可能回数も併せて関連づける。そして、生成した仮名通信アドレスを仮名通信アドレス提供部３２に返信する（ステップＳ７１２）。
返信を受けた仮名通信アドレス提供部３２は、生成された仮名通信アドレスを含む仮名通信アドレスの取得レスポンスを、通信サービス提供サーバに返信する（ステップＳ７１３）。なお、通信サービス提供サーバに、生成した仮名通信アドレスを提供する際に、併せて利用可能回数を通知してもよい。また、本実施形態においても、第３の実施形態と同様に、仮名通信アドレスを利用可能なサービスカテゴリを指定してもよい。
なお、生成した仮名通信アドレスの利用可能回数は、提供先である通信サービス提供サーバがその仮名通信アドレスを利用した際のメールサーバ２０からのユーザＩＤの取得リクエストを受信した仮名通信アドレス管理部３３にて制御される。
すなわち、電子メールを受信したメールサーバ２０の通信アドレス変換部２２が、電子メールの宛先アドレスから仮名通信アドレスを取得して、ＨＴＴＰプロキシサーバ３０の仮名通信アドレス管理部３３へ、取得した仮名通信アドレスを指定したユーザＩＤの取得リクエストを送信する。仮名通信アドレス管理部３３は、自身で保持している、仮名通信アドレスとユーザＩＤと通信サービス提供サーバアドレスとを関連付けた情報を検索して、指定された仮名通信アドレスに対応するユーザＩＤを解決して、要求元の通信アドレス変換部２２に、得られたユーザＩＤを含むユーザＩＤの取得レスポンスを返信する。その際、仮名通信アドレス管理部３３は、指定された仮名通信ドレスに対応するユーザＩＤが存在するならば、自身が保持している関連付け情報におけるその仮名通信アドレスに設定されている利用可能回数（３３４）を１削減すればよい。ここで、利用可能回数が０になった場合には、当該仮名通信アドレスの利用を停止させる。なお、関連付け情報において当該仮名通信アドレスの情報を削除してもよい。なお、仮名通信アドレスから実通信アドレスの変換に係る他の処理は、第１の実施形態と同様でよい。
以上のように、本実施形態によれば、ホームページへのアクセス履歴から仮名通信アドレスの提供を制御することにより、過去のアクセスにさかのぼって仮名通信アドレスの提供先を決定することが可能になる。また、通信サービス提供サーバ４２側からの仮名通信アドレスの取得リクエストを契機に、仮名通信アドレスを提供することが可能になるため、使用する側による任意のタイミングで仮名通信アドレスの利用が可能になる。
また、本実施形態では、ホームページの総合的なアクセス時間から仮名通信アドレスの利用可能回数を決定したが、ホームページのアクセス履歴による利用可能回数の決定はこれに限定されるものではない。例えば、ホームページのアクセス回数によって決定してもよい。このような場合には、仮名通信アドレス提供条件管理部３４に、アクセス頻度による利用回数というデータ項目を追加して、一定時間内のアクセス回数によって提供する仮名通信アドレスの利用可能回数を決定すればよい。
さらに、ホームページのアクセス履歴から算出できる総合的なアクセス時間やアクセス頻度は、仮名通信アドレスの利用可能回数の算出に限定されるものではない。例えば、総合的なアクセス時間やアクセス頻度に応じて仮名通信アドレスの有効期限（利用可能期間）を設定してもよい。例えば、通信サービス提供サーバが音声のストリーミングにより情報提供を行う場合、当該通信サービス提供サーバに関連づけられたホームページにアクセスした時間だけ、そのホームページにアクセスしたユーザ端末へ音声のストリーミングによる広告を更新することができるといった用法も可能である。
実施形態５．
次に、本発明の第５の実施形態について説明する。本実施形態では、マッシュアップサーバに情報を提供するＷｅｂサーバを運営する事業主に対しても仮名通信アドレスによるユーザ端末とのコミュニケーション手段を提供する。
本実施形態において、マッシュアップサーバとは、複数のＷｅｂサーバの情報を収集・加工（マッシュアップ）することによって、ユーザ端末に情報サービスを提供するサーバである。また、Ｗｅｂサービスサーバは、マッシュアップサーバに情報を提供するＷｅｂサーバである。Ｗｅｂサービスサーバと第１〜第４の実施形態におけるＷｅｂサーバとの違いは、提供する情報がユーザ端末のブラウザにおいてＨＴＭＬで記述されるホームページのように、ユーザに対して視覚的な可読性がなくてもよい点である。
例えば、天気の情報を提供するＷｅｂサービスサーバであれば、晴れを１，曇りを２，雨を３，雷を４などのように天候状態を数値で提供してもよい。これは、ユーザ端末のブラウザにとって理解不可能な情報であっても、マッシュアップサーバにとって理解可能な情報であればよいからである。
図２２は、第５の実施形態による仮名通信アドレス提供システムの構成例を示すブロック図である。図２２に示す仮名通信アドレス提供システムは、ユーザ端末１０と、メールサーバ２０と、ＨＴＴＰプロキシサーバ３０と、通信サービス提供サーバ４２と、マッシュアップサーバ５１と、Ｗｅｂサービスサーバ５２と、Ｗｅｂサーバ用ＨＴＴＰプロキシサーバ７０とを備えている。また、ユーザ端末１０と、メールサーバ２０と、ＨＴＴＰプロキシサーバ３０と、通信サービス提供サーバ４２と、マッシュアップサーバ５１と、Ｗｅｂサービスサーバ５２と、Ｗｅｂサーバ用ＨＴＴＰプロキシサーバ７０とは、ネットワーク６０を介して接続されている。
なお、ユーザ端末１０と、メールサーバ２０と、通信サービス提供サーバ４２とは、第１〜第４の実施形態と同様である。
また、ＨＴＴＰプロキシサーバ３０は、ＨＴＴＰプロトコル情報取得部３１が、ＨＴＴＰプロトコル情報取得変換部３７に置き換わっている点を除いて、第１〜第４の実施形態のいずれかと同様でよい。なお、図２２に示す例では、第４の実施形態のＨＴＴＰプロキシサーバ３０に対して、ＨＴＴＰプロトコル情報取得部３１をＨＴＴＰプロトコル情報取得変換部３７に置き換えた例を示している。
ＨＴＴＰプロトコル情報取得変換部３７は、第１〜第４の実施形態におけるＨＴＴＰプロトコル情報取得部３１の機能に加えて、受信したＨＴＴＰプロトコルの通信データのユーザＩＤを、一時的なユーザＩＤ（以下、一時ユーザＩＤという。）に変換して該通信データを送信する。
マッシュアップサーバ５１は、ＨＴＴＰプロキシサーバ３０経由でユーザ端末１０からのホームページの取得要求を受信するとともに、後述するＷｅｂサービスサーバ５２から、ホームページの作成に必要な情報を取得し、ホームページを作成して要求元のユーザ端末１０に該ホームページの情報を返信する。
本実施形態では、マッシュアップサーバ５１は、ショッピングモールのホームページを作成する場合を例に説明する。
Ｗｅｂサービスサーバ５２は、マッシュアップサーバ５１に情報を提供するＷｅｂサーバであって、本実施形態では、ショッピングモール内のレストランの情報をマッシュアップサーバ５１に提供する。
Ｗｅｂサーバ用ＨＴＴＰプロキシサーバ７０は、マッシュアップサーバ５１とＷｅｂサービスサーバ５２との間に設置されるプロキシサーバであって、Ｗｅｂサーバ用ＨＴＴＰプロトコル情報取得変換部７１と、一時ユーザＩＤ管理部７２とを含む。
Ｗｅｂサーバ用ＨＴＴＰプロトコル情報取得変換部７１は、第１〜第４の実施形態におけるＨＴＴＰプロキシサーバ３０のＨＴＴＰプロトコル情報取得部３１の機能に加えて、マッシュアップサーバ５１から受信したＨＴＴＰプロトコルの通信データの一時ユーザＩＤを、新たな一時ユーザＩＤに変換する。
一時ユーザＩＤ管理部７２は、ＨＴＴＰプロキシサーバ３０およびＷｅｂサーバ用ＨＴＴＰプロキシサーバ７０を経由して送受信されるＨＴＴＰプロトコルの通信データから、サービス事業主間におけるユーザの個人情報の悪い意味での名寄せが行えないようにするために、同一のユーザを指し示すユーザＩＤをＨＴＴＰプロトコル毎に変換する一時ユーザＩＤを保持する。
ここで、ユーザの個人情報の悪い意味での名寄せとは、異なるサービス事業主が保有している断片的な個人情報が集まり最終的に個人が特定されてしまう問題のことである。
図２３は、一時ユーザＩＤ管理部７２が保持するデータの例を示す説明図である。図２３では、一時ユーザＩＤ管理部７２が保持するデータの構成として、受付ユーザＩＤ（７２１）と、ＷｅｂサーバＩＤ（７２２）と、一時ユーザＩＤ（７２３）の項目を有する例が示されている。
受付ユーザＩＤ（７２１）には、ＨＴＴＰプロトコル情報取得変換部３７またはＷｅｂサーバ用ＨＴＴＰプロトコル情報取得変換部７１で受信したＨＴＴＰプロトコルによる通信データのユーザＩＤ（一時ユーザＩＤである場合もある。）を格納する。
ＷｅｂサーバＩＤ（７２２）には、一時ユーザＩＤが割り当てられた際のアクセス先となったＷｅｂサーバのＷｅｂサーバＩＤを格納する。また、一時ユーザＩＤ（７２３）には、割り当てられた一時ユーザＩＤを格納する。
例えば、図２３に示す例では、ユーザＩＤが”ｕｓｅｒ０００１”のユーザまたはユーザ端末１０から、ＷｅｂサーバＩＤが”ｗｗｗ．ｓｈｏｐｐｉｎｇｍａｌｌ．ｃｏ．ｊｐ”のＷｅｂサーバへのアクセスの際に、該ユーザＩＤ”ｕｓｅｒ０００１”を一時ユーザＩＤ”ｔｅｍｐ０００１”に変換した旨が示されている。また、例えば、ユーザＩＤ（ここでは、一時ユーザＩＤ）が”ｔｅｍｐ０００１”のユーザまたはユーザ端末１０から、ＷｅｂサーバＩＤが”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”のＷｅｂサーバへのアクセスの際に、該ユーザＩＤ”ｔｅｍｐ０００１”を一時ユーザＩＤ”ｔｅｍｐ０００２”に変換した旨が示されている。
また、図２４は、本実施形態におけるアクセス履歴管理部３６が保持するデータの例を示す説明図である。図２４に示すように、本実施形態におけるアクセス履歴管理部３６が保持するデータは、第４の実施形態と同様でよい。ただし、アクセス履歴管理部３６は、ＨＴＴＰプロトコルによる通信データが示すユーザＩＤが一時ユーザＩＤであった場合には、一時ユーザＩＤ管理部７２に問い合わせを行うことにより、その一時ユーザＩＤを現実のユーザＩＤ（実ユーザＩＤ）に変換した上で、登録する。
このようにすることにより、仮名通信アドレスを提供する契機となるタイミングにおいて、ＷｅｂサーバＩＤとユーザＩＤとを関連づける際に、ＷｅｂサービスサーバのＷｅｂサーバＩＤと実ユーザＩＤとを関連づけることができるので、Ｗｅｂサービスサーバに関連するサービス事業者に対しても、該実ユーザＩＤが指し示すユーザまたはユーザ端末へのコミュニケーションを可能とする仮名通信アドレスを提供することができる。なお、他の点に関しては、第４の実施形態と同様である。
次に、本実施形態の動作について説明する。図２５は、本実施形態の仮名通信アドレス提供システムの動作の一例を示すシーケンス図である。
図２５に示すように、本実施形態では、ユーザ端末１０のブラウザ１１より、ホームページの情報を取得するためのＨＴＴＰリクエストがＷｅｂサーバ（ここでは、マッシュアップサーバ５１）に向けて送信されると（ステップＳ８０１）、それを受信したＨＴＴＰプロキシサーバ３０のＨＴＴＰプロトコル情報取得変換部３７は、受信したＨＴＴＰリクエストから、ユーザＩＤ（ここでは、実ユーザＩＤ）と、ＷｅｂサーバＩＤを取得するとともに、ホームページ接続を検出し（ステップＳ８０２）、ホームページ接続通知をアクセス履歴管理部３６に出力する（ステップＳ８０３）。本例では、該ＨＴＴＰリクエストからユーザＩＤ”ｕｓｅｒ００１”とＷｅｂサーバＩＤ”ｗｗｗ．ｓｈｏｐｐｉｎｇｍａｌｌ．ｃｏ．ｊｐ”とを取得したものとして説明する。なお、ステップＳ８０１〜Ｓ８０３の動作は、第４の実施形態のステップＳ５０１〜Ｓ５０３と同様でよい。
ホームページ接続通知を受信したアクセス履歴管理部３６は、通知されたユーザＩＤとＷｅｂサーバＩＤとを用い、さらに現在日時をホームページ接続時刻（３６１）として、履歴情報を作成し、記憶領域に格納する（ステップＳ８０４）。なお、この時点では、ホームページ接続時刻（３６２）は、空とする（図２４の２番目のレコード参照。）。
次に、ＨＴＴＰプロトコル情報取得変換部３７は、取得したユーザＩＤとＷｅｂサーバＩＤを指定してＷｅｂサーバ用ＨＴＴＰプロキシサーバ７０の一時ユーザＩＤ管理部７２に、一時ユーザＩＤの生成リクエストを送信する（ステップＳ８０５）。
一時ユーザＩＤの生成リクエストを受信した一時ユーザＩＤ管理部７２は、指定されたユーザＩＤに対して一時ユーザＩＤを割り当て、指定されたユーザＩＤとＷｅｂサーバＩＤと生成した一時ユーザＩＤとを関連づけて格納する（ステップＳ８０６）。このとき、関連付けられる一時ユーザＩＤは、乱数を用いて生成してもよいし、事前に用意してある未使用の一時ユーザＩＤの中から選択してもよい。そして、生成した一時ユーザＩＤを含む一時ユーザＩＤの生成レスポンスを、要求元であるＨＴＴＰプロキシサーバ３０のＨＴＴＰプロトコル情報取得変換部３７に返信する（ステップＳ８０７）。ここでは、図２３の２番目のレコードに示すように、ＷｅｂサーバＩＤ”ｗｗｗ．ｓｈｏｐｐｉｎｇｍａｌｌ．ｃｏ．ｊｐ”への受付ユーザＩＤ”ｕｓｅｒ０００１”に対して一時ユーザＩＤ”ｔｅｍｐ０００１”を割り当てたとする。
一時ユーザＩＤの生成レスポンスを受信したＨＴＴＰプロトコル情報取得変換部３７は、ユーザ端末１０から受信したＨＴＴＰリクエストのユーザＩＤを、受信した一時ユーザＩＤに変換して、アクセス先であるマッシュアップサーバ５１に送信する（ステップＳ８０８）。
ＨＴＴＰリクエストを受信したマッシュアップサーバ５１は、他のＷｅｂサーバから収集・加工するための情報を取得するために、さらに収集先であるＷｅｂサービスサーバ５２に向けて、受信したＨＴＴＰリクエストのユーザＩＤ（ここでは、一時ユーザＩＤ”ｔｅｍｐ０００１”）を格納したＨＴＴＰリクエストを送信する（ステップＳ８０９）。本実施形態では、ショッピングモールのマッシュアップサーバ５１が、レストランの情報を取得するために、レストラン事業主のＷｅｂサービスサーバ５２であるＷｅｂサービスＩＤが”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”のＷｅｂサーバへＨＴＴＰリクエストを送信したとする。
また、本実施形態では、マッシュアップサーバ５１から送信されたＨＴＴＰプロトコルによる通信データは、Ｗｅｂサーバ用ＨＴＴＰプロキシサーバ７０を経由して宛て先であるＷｅｂサービスサーバ５２に転送される。
マッシュアップサーバ５１から送信されたＨＴＴＰリクエストを受信したＷｅｂサーバ用ＨＴＴＰプロキシサーバ７０では、Ｗｅｂサーバ用ＨＴＴＰプロトコル情報取得変換部７１が、受信したＨＴＴＰプロトコルから、ユーザＩＤ（ここでは、一時ユーザＩＤ”ｔｅｍｐ０００１”）とＷｅｂサーバＩＤ（”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”）とを取得する。Ｗｅｂサーバ用ＨＴＴＰプロトコル情報取得変換部７１は、取得したユーザＩＤが一時ユーザＩＤである場合には、取得した一時ユーザＩＤを指定して一時ユーザＩＤ管理部７２に、実ユーザＩＤの取得リクエストを送信する（ステップＳ８１０）。
実ユーザＩＤの取得リクエストを受信した一時ユーザＩＤ管理部７２は、指定された一時ユーザＩＤから、該一時ユーザＩＤが割り当てられた実ユーザＩＤを求めて返信する（ステップＳ８１１：実ユーザＩＤの取得レスポンスの送信）。一時ユーザＩＤ管理部７２は、指定された一時ユーザＩＤが、ユーザＩＤ（７２３）に登録されているレコードの受付ユーザＩＤ（７２１）を求める処理を、受付ユーザＩＤ（７２１）が実ユーザＩＤになるまで繰り返して実行すればよい。
実ユーザＩＤの取得レスポンスを受信したＷｅｂサーバ用ＨＴＴＰプロトコル情報取得変換部７１は、解決した実ユーザＩＤ（ここでは、ユーザＩＤ”ｕｓｅｒ０００１”）と取得したＷｅｂサーバＩＤ（”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”）とを指定して、ホームページ接続通知をアクセス履歴管理部３６に送信する（ステップＳ８１２）。
ホームページ接続通知を受信したアクセス履歴管理部３６は、ステップＳ８０４と同様に、通知されたユーザＩＤとＷｅｂサーバＩＤとを用い、さらに現在日時をホームページ接続時刻（３６１）として、履歴情報を作成し、記憶領域に格納する（ステップＳ８１３。図２４の３番目のレコード参照。）。
次に、Ｗｅｂサーバ用ＨＴＴＰプロトコル情報取得変換部７１は、アクセス先であるＷｅｂサービスサーバに開示するユーザＩＤ用に、受信した一時ユーザＩＤに対してさらに一時ユーザＩＤの生成を一時ユーザＩＤ管理部７２に依頼する。Ｗｅｂサーバ用ＨＴＴＰプロトコル情報取得変換部７１は、ステップＳ８０５におけるＨＴＴＰプロトコル情報取得変換部３７と同様に、取得したユーザＩＤ（ここでは、一時ユーザＩＤ”ｔｅｍｐ０００１”）とＷｅｂサーバＩＤ（ここでは、”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”）を指定して一時ユーザＩＤ管理部７２に、一時ユーザＩＤの生成リクエストを送信する（ステップＳ８１４）。
一時ユーザＩＤの生成リクエストを受信した一時ユーザＩＤ管理部７２は、指定されたユーザＩＤに対して一時ユーザＩＤを割り当て、指定されたユーザＩＤとＷｅｂサーバＩＤと生成した一時ユーザＩＤとを関連づけて格納する（ステップＳ８１５）。そして、生成した一時ユーザＩＤを含む一時ユーザＩＤの生成レスポンスを、要求元であるＷｅｂサーバ用ＨＴＴＰプロトコル情報取得変換部７１に返信する（ステップＳ８１６）。ここでは、図２３の３番目のレコードに示すように、ＷｅｂサーバＩＤ”ｗｗｗ．ｒｅｓｔａｕｒａｎｔ．ｃｏ．ｊｐ”への受付ユーザＩＤ”ｔｅｍｐ０００１”に対して一時ユーザＩＤ”ｔｅｍｐ０００２”を割り当てたとする。
新しい一時ユーザＩＤを含む一時ユーザＩＤの生成レスポンスを受信したＷｅｂサーバ用ＨＴＴＰプロトコル情報取得変換部７１は、マッシュアップサーバ５１から受信したＨＴＴＰリクエストのユーザＩＤ（ここでは、一時ユーザＩＤ”ｔｅｍｐ０００１”）を、受信した一時ユーザＩＤ（”ｔｅｍｐ０００２”）に変換して、アクセス先であるＷｅｂサービスサーバ５２に送信する（ステップＳ８１７）。
本実施形態の例では、説明を簡単にするために、Ｗｅｂサービスサーバがさらに別のＷｅｂサービスサーバを呼び出すことはないが、Ｗｅｂサービスサーバがさらに別のＷｅｂサービスサーバを呼び出すことを考慮して、受信した一時ユーザＩＤからさらに新しい一時ユーザＩＤを生成している。
ＨＴＴＰリクエストを受信したＷｅｂサービスサーバ５２は、座席の空席情報やおすすめメニューなどのレストラン情報を含む通信データ（ＨＴＴＰプロトコルに載せた通信データであればよく、必ずしもホームページの形式でなくてもよい。）を、Ｗｅｂサーバ用ＨＴＴＰプロキシサーバ７０経由で要求元のマッシュアップサーバ５１に返信する（ステップＳ８１８，Ｓ８１９）。
Ｗｅｂサービスサーバ５２からＨＴＴＰプロトコルによる返信データを受信したマッシュアップサーバ５１は、受信した情報からホームページを加工して（ステップＳ８２０）、ＨＴＴＰプロキシサーバ３０経由で、生成したホームページの情報を当初のアクセス元であるユーザ端末１０にＨＴＴＰレスポンスとして返信する（ステップＳ８２１）。このＨＴＴＰレスポンスには、ユーザＩＤとして、ＨＴＴＰプロキシサーバ３０から受信したＨＴＴＰリクエストにおけるユーザＩＤである一時ユーザＩＤ”ｔｅｍｐ０００１”が指定されるが、当該ＨＴＴＰレスポンスを経由させるＨＴＴＰプロキシサーバ３０によって、実ユーザＩＤの解決が行われることによりユーザ端末１０に転送される。
このように、ユーザ端末１０からマッシュアップサーバ５１のホームページへのアクセス状況がアクセス履歴管理部３６にアクセス履歴として格納された後は、第４の実施形態と同様に、通信サービス提供サーバからの仮名通信アドレスの取得リクエストの送信を契機に、仮名通信アドレスの提供を行えばよい。
以上のように、本実施形態によれば、マッシュアップサーバに情報を提供するＷｅｂサービスサーバを運営する事業主に対しても仮名通信アドレスによるユーザまたはユーザ端末とのコミュニケーションを可能とする仮名通信アドレスを提供することができる。
なお、本実施形態による一時ユーザＩＤの解決手順は、第４の実施形態における仮名通信アドレスの提供方法だけでなく、第１の実施形態における仮名通信アドレスの提供方法に対しても適用可能である。例えば、ＨＴＴＰプロキシサーバ３０の仮名通信アドレス提供部３２と同様の機能を有するＷｅｂサーバ用仮名通信アドレス提供部を、Ｗｅｂサーバ用ＨＴＴＰプロキシサーバ７０が備えることによって、マッシュアップサーバ５１からＷｅｂサービスサーバ５２へのアクセス状況に応じて、Ｗｅｂサービスサーバ５２に関連するサービス事業者（本例では、レストラン事業主）に、マッシュアップサーバ５１にアクセスしたユーザまたはユーザ端末へのコミュニケーション手段となる仮名通信アドレスを提供することも可能である。
次に、本発明の概要について説明する。図２６は、本発明の概要を示すブロック図である。図２６に示すように、本発明による情報処理装置１は、ＨＴＴＰプロトコル情報取得手段１０１と、通信アドレス記憶手段１０２と、通信アドレス提供手段１０３とを備えたことを特徴とする。
ＨＴＴＰプロトコル情報取得手段１０１（例えば、ＨＴＴＰプロトコル情報取得部３１）は、ユーザ端末のＨＴＴＰプロトコルによる通信の状況を示す情報を取得する。ＨＴＴＰプロトコル情報取得手段１０１は、例えば、ユーザ端末のＨＴＴＰプロトコルによる通信のデータを取得して、該データによって示される通信の状況を特定することによって、その旨を示す情報を取得してもよい。
通信アドレス記憶手段１０２（例えば、仮名通信アドレス管理部３３）は、通信アドレス提供手段１０１が提供する通信アドレスを、該通信アドレスで特定されるユーザまたはユーザ端末を識別できる情報と関連づけて記憶する。通信アドレス記憶手段１０２は、例えば、通信アドレスと、該通信アドレスの割り当て対象となったユーザ端末またはユーザを識別するためのユーザ識別子と、さらに該通信アドレスの提供の動因となったアクセス先としてのＷｅｂサーバを識別するためのＷｅｂサーバ識別子とを関連づけて保持してもよい。
通信アドレス提供手段１０３（例えば、仮名通信アドレス提供部３２）は、通信サービスを提供するサーバである通信サービス提供サーバに対して、前記通信サービスの提供先となるユーザまたはユーザ端末を特定できる通信アドレスを提供する。本発明においては、通信アドレス提供手段１０３は、ユーザ端末のＨＴＴＰプロトコルによる通信の状況に基づいて、該ＨＴＴＰプロトコルによる通信相手であるＷｅｂサーバに関連づけられた通信サービス提供サーバに、当該ユーザ端末または当該ユーザ端末を使用しているユーザを特定できる通信アドレスを提供する。なお、ユーザまたはユーザ端末を特定できるとは、より具体的には、該ユーザまたは該ユーザ端末に情報を伝達する際に宛先として特定されることが可能であることを意味する。
また、通信アドレス提供手段１０３は、ユーザ端末が前記ＷｅｂサーバへＨＴＴＰプロトコルによるアクセスを開始すると、通信アドレスを提供してもよい。また、ユーザ端末が前記ＷｅｂサーバへＨＴＴＰプロトコルによるアクセスを終了すると、通信アドレスを提供してもよい。
また、図２７は、本発明による情報処理装置１の他の構成例を示すブロック図である。図２７に示すように、情報処理装置１は、さらに通信状況履歴記憶手段１０４を備えていてもよい。通信状況履歴記憶手段１０４（例えば、アクセス履歴管理部３６）は、ユーザ端末のＨＴＴＰプロトコルによる通信の状況の履歴を記憶する。そのような場合に、通信アドレス提供手段１０３は、通信サービス提供サーバからの通信アドレスの要求を示す情報を受け取ると、通信状況履歴記憶手段１０４に記憶されている通信の状況の履歴に基づいて、通信アドレスを提供してもよい。
また、情報処理装置１は、さらに、通信アドレス提供条件記憶手段１０５を備えていてもよい。通信アドレス提供条件記憶手段１０５（例えば、仮名通信アドレス提供条件管理部３４）は、例えば、少なくともアクセス先となったＷｅｂサーバに対応する通信サービス提供サーバの情報を含む通信アドレスの提供条件を記憶する。そのような場合に、通信アドレス提供手段１０３は、ユーザ端末から送信されたＨＴＴＰリクエストのうち、前記通信アドレス提供条件記憶手段に記憶されている情報に基づいて、通信アドレスの提供の動因とするＨＴＴＰリクエストを決定してもよい。
そのような構成によれば、通信アドレスの提供先とするサービス事業者と、通信アドレスの提出先としないサービス事業者を区別することを可能にする。
また、通信アドレス提供条件記憶手段１０５は、例えば、通信アドレスの提供条件として、提供する通信アドレスの利用可能回数または有効期限に関する情報を含む情報を記憶してもよい。そのような場合に、通信アドレス提供手段１０３は、前記通信アドレス提供条件記憶手段に記憶されている通信アドレスの提供条件に基づいて、提供する通信アドレスの利用可能回数または有効期限を決定してもよい。
また、通信アドレス提供手段１０３は、ユーザ端末のＨＴＴＰプロトコルによる通信の状況、通信アドレスの利用回数または提供してからの経過時間のいずれかに基づいて、通信アドレスを失効させるための制御を行ってもよい。
また、情報処理装置１は、さらに、ユーザ嗜好情報記憶手段１０６（例えば、ユーザ嗜好情報管理部３５）を備えていてもよい。ユーザ嗜好情報記憶手段１０６は、例えば、通信アドレスの割り当て対象となりうるユーザまたはユーザ端末を使用するユーザの嗜好を示す情報を記憶する。そのような場合に、通信アドレス提供条件記憶手段１０５は、少なくとも通信アドレスの提供の動因となるアクセス先としてのＷｅｂサーバのサービスカテゴリを示す情報を含む通信アドレスの提供条件を記憶していてもよい。また、通信アドレス提供手段１０３は、ユーザ嗜好情報記憶手段１０６に記憶されているユーザの嗜好の情報と、通信アドレス提供条件記憶手段１０５に記憶されているＷｅｂサーバのサービスカテゴリの情報とに基づいて、通信アドレスの提供先とする通信サービス提供サーバ、もしくは通信アドレスの割り当て対象とするユーザまたはユーザ端末を決定してもよい。
そのような構成によれば、通信サービス提供サーバによる通信アドレスを用いた通信サービスにおいてユーザが興味を示すカテゴリの情報を提供することができる。
また、情報処理装置１は、さらに、一時ユーザＩＤ生成手段１０７（例えば、ＨＴＴＰプロトコル情報取得変換部３７，一時ユーザＩＤ管理部７２）と、一時ユーザＩＤ記憶手段１０８（例えば、一時ユーザＩＤ管理部７２）とを備えていてもよい。一時ユーザＩＤ生成手段１０７は、ユーザまたはユーザ端末を識別できる情報としてのユーザ識別子と関連づけて、前記Ｗｅｂサーバが利用する一時的なユーザ識別子である一時ユーザＩＤを生成する。また、一時ユーザＩＤ記憶手段１０８は、ユーザ識別子と前記生成した一時ユーザＩＤとを関連づけて記憶する。そのような場合に、通信状況履歴記憶手段１０４は、通信に用いられた前記一時ユーザＩＤが前記ユーザ識別子に変換された履歴を記憶してもよい。
そのような構成によれば、マッシュアップサーバに情報を提供するＷｅｂサービスサーバを運営する事業主に対しても、ユーザまたはユーザ端末とのコミュニケーションを可能とする通信アドレスを提供することができる。
また、通信アドレス提供手段１０３が提供する通信アドレスは、仮名の通信アドレスであってもよい。
また、図２８は、本発明による通信アドレス提供システムの概要を示すブロック図である。図２８に示すように、本発明による通信アドレス提供システムは、通信サービスを提供するサーバである通信サービス提供サーバに対して、前記通信サービスの提供先となるユーザまたはユーザ端末を特定できる通信アドレスを提供するための通信アドレス提供システムであって、ＨＴＴＰプロトコル情報取得手段１０１と、通信アドレス記憶手段１０２と、通信アドレス提供手段１０３とを備えたことを特徴とする。ＨＴＴＰプロトコル情報取得手段１０１と、通信アドレス記憶手段１０２と、通信アドレス提供手段１０３とは、図２８に示すように、例えば、通信アドレスの割り当て対象となりうるユーザ端末またはユーザが使用するユーザ端末のＨＴＴＰプロトコルによる通信の状況を示す情報を取得可能な第１の通信装置１に実装されていてもよい。第１の通信装置は、例えば、ＨＴＴＰプロキシサーバである。
また、図２８に示すように、本発明による通信アドレス提供システムは、通信アドレス提供手段１０３が提供する通信アドレスを宛先とする通信データの配送制御を行う際に、通信アドレス記憶手段１０２へ問い合わせを行って、宛先となるユーザまたはユーザ端末を特定する通信アドレス変換手段２０１（例えば、通信アドレス変換部２２）を備えていてもよい。通信アドレス変換手段２０１は、例えば、提供される通信アドレスを宛て先として用いた通信データの配信制御を行う第２の通信装置２に実装されていてもよい。なお、第２の通信装置２は、例えば、メールサーバである。
また、図２９は、本発明による通信アドレス提供システムの他の構成例を示すブロック図である。図２９に示すように、通信アドレス提供システムとして、一時ユーザＩＤ生成手段１０７および一時ユーザＩＤ記憶手段１０８は、ユーザ端末３とアクセス先となるＷｅｂサーバ４の間に設定される第１の通信装置１とは別の第３の通信装置３に実装されていてもよい。第３の通信装置３は、例えば、アクセス先となるＷｅｂサーバ４がマッシュアップサーバである場合には、そのマッシュアップサーバと該マッシュアップサーバに情報を提供するＷｅｂサービスサーバとの間に設定されるＨＴＴＰプロキシサーバである。
なお、図示省略しているが、通信アドレス記憶手段１０２や、通信アドレス提供手段１０３、通信状況履歴記憶手段１０４、通信アドレス提供条件記憶手段１０５、ユーザ嗜好情報記憶手段１０６が、それぞれＨＴＴＰプロトコル情報取得手段１０１を備えた第１の通信装置１とは異なる装置によって実現されていてもよい。なお、そのような場合には、第１の通信装置１と該装置とが通信可能に接続されていることを前提とする。
以上、実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
この出願は、２００８年１１月２６日に出願された日本特許出願２００８−３０１１４３を基礎とする優先権を主張し、その開示の全てをここに取り込む。
本発明は、メールアドレスや電話番号などの個人情報をサービス事業者に提供せずに、興味を示したユーザ端末に対して能動的に広告メールや広告電話などの通信サービスを行う用途に好適に適用可能である。
１ 情報処理装置（第１の通信装置）
２ 第２の通信装置
３ ユーザ端末
４ Ｗｅｂサーバ
５ 通信サービス提供サーバ
６ ネットワーク
７ 第３の通信装置
１０ ユーザ端末
１１ ブラウザ（アプリケーションのための動作環境を含む）
１２ メールクライアント（アプリケーションのための動作環境を含む）
２０ メールサーバ
２１ 通信アドレス管理部
２２ 通信アドレス変換部
３０ ＨＴＴＰプロキシサーバ
３１ ＨＴＴＰプロトコル情報取得部
３２ 仮名通信アドレス提供部
３３ 仮名通信アドレス管理部
３４ 仮名通信アドレス提供条件管理部
３５ ユーザ嗜好情報管理部
３６ アクセス履歴管理部
３７ ＨＴＴＰプロトコル情報取得変換部
４１ Ｗｅｂサーバ
４２ 通信サービス提供サーバ
５１ マッシュアップ型Ｗｅｂサーバ
５２ Ｗｅｂサービスサーバ
６０ ネットワーク
７０ Ｗｅｂサーバ用ＨＴＴＰプロキシサーバ
７１ Ｗｅｂサーバ用ＨＴＴＰプロトコル情報取得変換部
７２ 一時ユーザ管理ＩＤ部
１０１ ＨＴＴＰプロトコル情報取得手段
１０２ 通信アドレス記憶手段
１０３ 通信アドレス提供手段
１０４ 通信状況履歴記憶手段
１０５ 通信アドレス提供条件記憶手段
１０６ ユーザ嗜好情報記憶手段
１０７ 一時ユーザＩＤ生成手段
１０８ 一時ユーザＩＤ記憶手段
２０１ 通信アドレス変換手段

Claims (24)

  1. 通信サービスを提供するサーバである通信サービス提供サーバに対して、前記通信サービスの提供先となるユーザまたはユーザ端末を特定できる通信アドレスを提供する通信アドレス提供手段と、
    ユーザ端末とＷｅｂサーバとの間の通信経路上において受信したＨＴＴＰプロトコルによる通信データから、ユーザ端末のＨＴＴＰプロトコルによる通信の状況を示す情報として、Ｗｅｂサーバへのアクセス状況を示す情報と、アクセス元のユーザ端末またはアクセス元のユーザ端末を使用しているユーザを識別できる情報と、アクセス先のＷｅｂサーバを識別できる情報とを取得するＨＴＴＰプロトコル情報取得手段と、
    前記通信アドレス提供手段が提供する通信アドレスを、該通信アドレスで特定されるユーザまたはユーザ端末を識別できる情報と関連づけて記憶する通信アドレス記憶手段とを備え、
    前記通信アドレス提供手段は、前記ＨＴＴＰプロトコル情報取得手段によって取得されたユーザ端末のＨＴＴＰプロトコルによる通信の状況を示す情報に基づいて、アクセス先のＷｅｂサーバに関連づけられた通信サービス提供サーバに、アクセス元のユーザ端末またはアクセス元のユーザ端末を使用しているユーザを特定できる通信アドレスを提供する
    ことを特徴とする情報処理装置。
  2. 前記通信アドレス提供手段は、ユーザ端末が前記ＷｅｂサーバへＨＴＴＰプロトコルによるアクセスを開始すると、通信アドレスを提供する
    請求項１に記載の情報処理装置。
  3. 前記通信アドレス提供手段は、ユーザ端末が前記ＷｅｂサーバへＨＴＴＰプロトコルによるアクセスを終了すると、通信アドレスを提供する
    請求項１または請求項２に記載の情報処理装置。
  4. ユーザ端末のＨＴＴＰプロトコルによる通信の状況の履歴を記憶する通信状況履歴記憶手段を備え、
    通信アドレス提供手段は、通信サービス提供サーバからの通信アドレスの要求を示す情報を受け取ると、前記通信状況履歴記憶手段に記憶されている通信の状況の履歴に基づいて、通信アドレスを提供する
    請求項１から請求項３のうちのいずれか１項に記載の情報処理装置。
  5. 前記ユーザまたはユーザ端末を識別できる情報は、ユーザまたはユーザ端末に対応するユーザ識別子であり、
    前記ユーザ識別子と関連づけて、前記Ｗｅｂサーバが利用する一時的なユーザ識別子である一時ユーザＩＤを生成する一時ユーザＩＤ生成手段と、
    前記ユーザ識別子と前記生成した一時ユーザＩＤとを関連づけて記憶する一時ユーザＩＤ記憶手段とを備え、
    通信状況履歴記憶手段は、通信に用いられた前記一時ユーザＩＤが前記ユーザ識別子に変換された履歴を記憶する
    請求項４に記載の情報処理装置。
  6. 少なくともアクセス先となったＷｅｂサーバに対応する通信サービス提供サーバの情報を含む通信アドレスの提供条件を記憶する通信アドレス提供条件記憶手段を備え、
    通信アドレス提供手段は、ユーザ端末から送信されたＨＴＴＰリクエストのうち、前記通信アドレス提供条件記憶手段に記憶されている情報に基づいて、通信アドレスの提供の動因とするＨＴＴＰリクエストを決定する
    請求項１から請求項５のうちのいずれか１項に記載の情報処理装置。
  7. 通信アドレスの割り当て対象となりうるユーザまたはユーザ端末を使用するユーザの嗜好を示す情報を記憶するユーザ嗜好情報記憶手段と、
    少なくとも通信アドレスの提供の動因となるアクセス先としてのＷｅｂサーバのサービスカテゴリを示す情報を含む通信アドレスの提供条件を記憶する通信アドレス提供条件記憶手段とを備え、
    通信アドレス提供手段は、前記ユーザ嗜好情報記憶手段に記憶されているユーザの嗜好の情報と、前記通信アドレス提供条件記憶手段に記憶されているＷｅｂサーバのサービスカテゴリの情報とに基づいて、通信アドレスの提供先とする通信サービス提供サーバ、もしくは通信アドレスの割り当て対象とするユーザまたはユーザ端末を決定する
    請求項１から請求項６のうちのいずれか１項に記載の情報処理装置。
  8. 通信アドレス提供条件記憶手段は、通信アドレスの提供条件として、提供する通信アドレスの利用可能回数または有効期限に関する情報を含む情報を記憶し、
    通信アドレス提供手段は、前記通信アドレス提供条件記憶手段に記憶されている通信アドレスの提供条件に基づいて、提供する通信アドレスの利用可能回数または有効期限を決定する
    請求項１から請求項７のうちのいずれか１項に記載の情報処理装置。
  9. 通信アドレス提供手段は、ユーザ端末のＨＴＴＰプロトコルによる通信の状況、通信アドレスの利用回数または提供してからの経過時間のいずれかに基づいて、通信アドレスを失効させるための制御を行う
    請求項１から請求項８のうちのいずれか１項に記載の情報処理装置。
  10. 前記通信アドレス提供手段が提供する通信アドレスは、仮名の通信アドレスである
    請求項１から請求項９のうちのいずれか１項に記載の情報処理装置。
  11. 通信サービスを提供するサーバである通信サービス提供サーバに対して、前記通信サービスの提供先となるユーザまたはユーザ端末を特定できる通信アドレスを提供する通信アドレス提供手段と、
    ユーザ端末とＷｅｂサーバとの間の通信経路上において受信したＨＴＴＰプロトコルによる通信データから、ユーザ端末のＨＴＴＰプロトコルによる通信の状況を示す情報として、Ｗｅｂサーバへのアクセス状況を示す情報と、アクセス元のユーザ端末またはアクセス元のユーザ端末を使用しているユーザを識別できる情報と、アクセス先のＷｅｂサーバを識別できる情報とを取得するＨＴＴＰプロトコル情報取得手段と、
    前記通信アドレス提供手段が提供する通信アドレスを、該通信アドレスで特定されるユーザまたはユーザ端末を識別できる情報と関連づけて記憶する通信アドレス記憶手段とを備え、
    前記通信アドレス提供手段は、前記ＨＴＴＰプロトコル情報取得手段によって取得されたユーザ端末のＨＴＴＰプロトコルによる通信の状況を示す情報に基づいて、アクセス先のＷｅｂサーバに関連づけられた通信サービス提供サーバに、アクセス元のユーザ端末またはアクセス元のユーザ端末を使用しているユーザを特定できる通信アドレスを提供する
    ことを特徴とする通信アドレス提供システム。
  12. 前記通信アドレス提供手段が提供する通信アドレスを宛先とする通信データの配送制御を行う際に、通信アドレス記憶手段へ問い合わせを行って、宛先となるユーザまたはユーザ端末を特定する通信アドレス変換手段を備えた
    請求項１１に記載の通信アドレス提供システム。
  13. ユーザ端末のＨＴＴＰプロトコルによる通信の状況の履歴を記憶する通信状況履歴記憶手段を備え、
    通信アドレス提供手段は、通信サービス提供サーバからの通信アドレスの要求を示す情報を受け取ると、前記通信状況履歴記憶手段に記憶されている通信の状況の履歴に基づいて、通信アドレスを提供する
    請求項１１または請求項１２に記載の通信アドレス提供システム。
  14. 前記ユーザまたはユーザ端末を識別できる情報は、ユーザまたはユーザ端末に対応するユーザ識別子であり、
    前記ユーザ識別子と関連づけて、前記Ｗｅｂサーバが利用する一時的なユーザ識別子である一時ユーザＩＤを生成する一時ユーザＩＤ生成手段と、
    前記ユーザ識別子と前記生成した一時ユーザＩＤとを関連づけて記憶する一時ユーザＩＤ記憶手段とを備え、
    通信状況履歴記憶手段は、通信に用いられた前記一時ユーザＩＤが前記ユーザ識別子に変換された履歴を記憶する
    請求項１１から請求項１３のうちのいずれか１項に記載の通信アドレス提供システム。
  15. 少なくともアクセス先となったＷｅｂサーバに対応する通信サービス提供サーバの情報を含む通信アドレスの提供条件を記憶する通信アドレス提供条件記憶手段を備え、
    通信アドレス提供手段は、ユーザ端末から送信されたＨＴＴＰリクエストのうち、前記通信アドレス提供条件記憶手段に記憶されている情報に基づいて、通信アドレスの提供の動因とするＨＴＴＰリクエストを決定する
    請求項１１から請求項１４のうちのいずれか１項に記載の通信アドレス提供システム。
  16. 通信アドレスの割り当て対象となりうるユーザまたはユーザ端末を使用するユーザの嗜好を示す情報を記憶するユーザ嗜好情報記憶手段と、
    少なくとも通信アドレスの提供の動因となるアクセス先としてのＷｅｂサーバのサービスカテゴリを示す情報を含む通信アドレスの提供条件を保持する通信アドレス提供条件記憶手段とを備え、
    通信アドレス提供手段は、前記ユーザ嗜好情報記憶手段に記憶されているユーザの嗜好の情報と、前記通信アドレス提供条件記憶手段に記憶されているＷｅｂサーバのサービスカテゴリの情報とに基づいて、通信アドレスの提供先とする通信サービス提供サーバ、もしくは通信アドレスの割り当て対象とするユーザまたはユーザ端末を決定する
    請求項１１から請求項１５のうちのいずれか１項に記載の通信アドレス提供システム。
  17. 通信サービスを提供するサーバである通信サービス提供サーバに対して、前記通信サービスの提供先となるユーザまたはユーザ端末を特定できる通信アドレスを提供するための通信アドレス提供方法であって、
    ユーザ端末とＷｅｂサーバとの間の通信経路上において受信したＨＴＴＰプロトコルによる通信データから、前記通信アドレスの割り当て対象となる前記ユーザ端末またはユーザが使用するユーザ端末のＨＴＴＰプロトコルによる通信の状況を示す情報として、Ｗｅｂサーバへのアクセス状況を示す情報と、アクセス元のユーザ端末またはアクセス元のユーザ端末を使用しているユーザを識別できる情報と、アクセス先のＷｅｂサーバを識別できる情報とを取得し、
    取得した前記ユーザ端末のＨＴＴＰプロトコルによる通信の状況を示す情報に基づいて、アクセス先のＷｅｂサーバに関連づけられた通信サービス提供サーバに、アクセス元のユーザ端末またはアクセス元のユーザ端末を使用しているユーザを特定できる通信アドレスを提供し、
    提供する通信アドレスを、該通信アドレスで特定されるユーザまたはユーザ端末を識別できる情報と関連づけて記憶装置に記憶させる
    ことを特徴とする通信アドレス提供方法。
  18. 通信サービス提供サーバからの通信アドレスの要求を示す情報を受け取ると、記憶装置に記憶されている、ユーザ端末のＨＴＴＰプロトコルによる通信の状況の履歴に基づいて、通信アドレスを提供する
    請求項１７に記載の通信アドレス提供方法。
  19. 予め記憶されている前記通信アドレスの提供条件に基づいて、提供する通信アドレスの利用可能回数または有効期限を決定する
    請求項１７または請求項１８に記載の通信アドレス提供方法。
  20. ユーザ端末のＨＴＴＰプロトコルによる通信の状況、通信アドレスの利用回数または提供してからの経過時間のいずれかに基づいて、通信アドレスを失効させるための制御を行う
    請求項１７から請求項１９のうちのいずれか１項に記載の通信アドレス提供方法。
  21. 通信サービスを提供するサーバである通信サービス提供サーバに対して、前記通信サービスの提供先となるユーザまたはユーザ端末を特定できる通信アドレスを提供するための通信アドレス提供用プログラムであって、
    コンピュータに、
    ユーザ端末とＷｅｂサーバとの間の通信経路上において受信したＨＴＴＰプロトコルによる通信データから、ＨＴＴＰプロトコルにより特定される情報であって、前記通信アドレスの割り当て対象となる前記ユーザ端末またはユーザが使用するユーザ端末のＨＴＴＰプロトコルによる通信の状況を示す情報として、Ｗｅｂサーバへのアクセス状況を示す情報と、アクセス元のユーザ端末またはアクセス元のユーザ端末を使用しているユーザを識別できる情報と、アクセス先のＷｅｂサーバを識別できる情報とを取得する処理、および
    取得した前記ユーザ端末のＨＴＴＰプロトコルによる通信の状況を示す情報に基づいて、アクセス先のＷｅｂサーバに関連づけられた通信サービス提供サーバに、アクセス元のユーザ端末またはアクセス元のユーザ端末を使用しているユーザを特定できる通信アドレスを提供する処理
    を実行させるための通信アドレス提供用プログラム。
  22. コンピュータに、
    通信サービス提供サーバからの通信アドレスの要求を示す情報を受け取ると、記憶装置に記憶されている、ユーザ端末のＨＴＴＰプロトコルによる通信の状況の履歴に基づいて、通信アドレスを提供する処理を実行させる
    請求項２１に記載の通信アドレス提供用プログラム。
  23. コンピュータに、
    予め記憶されている前記通信アドレスの提供条件に基づいて、提供する通信アドレスの利用可能回数または有効期限を決定する処理を実行させる
    請求項２１または請求項２２に記載の通信アドレス提供用プログラム。
  24. コンピュータに、
    ユーザ端末のＨＴＴＰプロトコルによる通信の状況、通信アドレスの利用回数または提供してからの経過時間のいずれかに基づいて、通信アドレスを失効させる処理を実行させる
    請求項２１から請求項２３のうちのいずれか１項に記載の通信アドレス提供用プログラム。
JP2010540374A 2008-11-26 2009-11-26 情報処理装置、通信アドレス提供システムおよびそれに用いる方法並びにプログラム Active JP5392267B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010540374A JP5392267B2 (ja) 2008-11-26 2009-11-26 情報処理装置、通信アドレス提供システムおよびそれに用いる方法並びにプログラム

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2008301143 2008-11-26
JP2008301143 2008-11-26
JP2010540374A JP5392267B2 (ja) 2008-11-26 2009-11-26 情報処理装置、通信アドレス提供システムおよびそれに用いる方法並びにプログラム
PCT/JP2009/006377 WO2010061600A1 (ja) 2008-11-26 2009-11-26 情報処理装置、通信アドレス提供システムおよびそれに用いる方法並びにプログラム

Publications (2)

Publication Number Publication Date
JPWO2010061600A1 JPWO2010061600A1 (ja) 2012-04-26
JP5392267B2 true JP5392267B2 (ja) 2014-01-22

Family

ID=42225486

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010540374A Active JP5392267B2 (ja) 2008-11-26 2009-11-26 情報処理装置、通信アドレス提供システムおよびそれに用いる方法並びにプログラム

Country Status (3)

Country Link
US (1) US20110219135A1 (ja)
JP (1) JP5392267B2 (ja)
WO (1) WO2010061600A1 (ja)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4857419B1 (ja) 2011-02-17 2012-01-18 楽天株式会社 情報登録装置、情報登録方法、情報登録プログラム及び記録媒体
JP5678772B2 (ja) * 2011-03-30 2015-03-04 富士通株式会社 権限管理方法および権限管理プログラム
KR101756709B1 (ko) * 2011-06-17 2017-07-11 삼성전자주식회사 데이터 관리 시스템 및 그 시스템에서 데이터 표시 방법
US20130097046A1 (en) * 2011-10-14 2013-04-18 Balachander Krishnamurthy System and Method of Providing Transactional Privacy
US9229740B1 (en) * 2011-11-02 2016-01-05 Amazon Technologies, Inc. Cache-assisted upload proxy
US8984162B1 (en) 2011-11-02 2015-03-17 Amazon Technologies, Inc. Optimizing performance for routing operations
US8726264B1 (en) 2011-11-02 2014-05-13 Amazon Technologies, Inc. Architecture for incremental deployment
US9602623B2 (en) * 2012-09-11 2017-03-21 Nokia Corporation Method and apparatus for caching local mashup service parameters
KR102090493B1 (ko) * 2013-01-22 2020-03-18 삼성전자주식회사 무선 통신 네트워크에서 http 프로토콜의 전송 지연과 http 서버의 프로세싱 부하를 줄이는 장치 및 방법
JP2015032275A (ja) * 2013-08-06 2015-02-16 キヤノン株式会社 システムおよびその制御方法、及びプログラム
US11196692B2 (en) * 2019-02-27 2021-12-07 A Social Company Social contract based messaging platform
US11178085B2 (en) 2019-02-27 2021-11-16 A Social Company Social media platform for sharing reactions to videos

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002189973A (ja) * 2000-12-20 2002-07-05 Nec Corp 認証・課金代行方法、認証・課金代行システム及び認証・課金代行プログラムを記憶した記憶媒体
JP2006309604A (ja) * 2005-04-28 2006-11-09 Nippon Telegr & Teleph Corp <Ntt> 通信システム、通信方法および通信プログラム
JP2007233711A (ja) * 2006-03-01 2007-09-13 Rakuten Inc メール転送システム
JP2008204442A (ja) * 2007-01-17 2008-09-04 Hiroto Yahagi ネットワーク顧客応対システム

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2001241777A1 (en) * 2000-02-29 2001-09-12 Iprivacy Llc Anonymous and private browsing of web-sites through private portals
JP2002366819A (ja) * 2001-05-31 2002-12-20 Hewlett Packard Co <Hp> 識別子に基づいた電子クーポンの配布システム
WO2006099583A2 (en) * 2005-03-16 2006-09-21 121 Media, Inc. Targeted advertising system and method

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002189973A (ja) * 2000-12-20 2002-07-05 Nec Corp 認証・課金代行方法、認証・課金代行システム及び認証・課金代行プログラムを記憶した記憶媒体
JP2006309604A (ja) * 2005-04-28 2006-11-09 Nippon Telegr & Teleph Corp <Ntt> 通信システム、通信方法および通信プログラム
JP2007233711A (ja) * 2006-03-01 2007-09-13 Rakuten Inc メール転送システム
JP2008204442A (ja) * 2007-01-17 2008-09-04 Hiroto Yahagi ネットワーク顧客応対システム

Also Published As

Publication number Publication date
JPWO2010061600A1 (ja) 2012-04-26
US20110219135A1 (en) 2011-09-08
WO2010061600A1 (ja) 2010-06-03

Similar Documents

Publication Publication Date Title
JP5392267B2 (ja) 情報処理装置、通信アドレス提供システムおよびそれに用いる方法並びにプログラム
US7958258B2 (en) Mobile communication device domain name system redirection
US8516550B2 (en) Systems and methods for enabling a service provider to obtain and use user information
US8364711B2 (en) Contact management system and method
EP3248364B1 (en) Network identification as a service
US20120291109A1 (en) User information utilization system, device, method, and program
JPH10254807A (ja) 匿名的にサーバサイトを閲覧する方法
US20120023247A1 (en) Anonymous communication system, anonymous communication method, communication control apparatus, terminal apparatus and communication control program
JP2019506692A (ja) データを処理する方法、装置、及びコンピュータプログラム、並びに階層ドメインネームシステムのゾーンファイル
CN101645854A (zh) 一种获取用户信息的方法、装置及系统
JPWO2010119626A1 (ja) Ｉｄ認証システム、方法及びプログラム
JP4932154B2 (ja) アイデンティティ管理ネットワークにおいてユーザーの認証をメンバーサイトに与える方法及びシステム、アイデンティティ管理ネットワークに属するホームサイトでユーザーの認証を行う方法、コンピュータ読み取り可能な媒体、ならびに、階層的分散アイデンティティ管理のためのシステム
JP2009217522A (ja) 個人属性情報提供システムおよび個人属性情報提供方法
US20160277339A1 (en) Electronic Communication System
JP2013135417A (ja) メッセージ中継システム、メッセージ中継方法及びプログラム
WO2011070726A1 (ja) 属性情報連携提供システム、アクセス情報管理装置、アクセス情報代理管理装置、方法、およびプログラム
WO2014118548A1 (en) Tracking system
JP5387862B2 (ja) メッセージ配信システムおよび配信方法
KR101096334B1 (ko) 고객 맞춤형 웹 페이지 송수신 시스템과, 그 시스템에 포함되는 이동통신사 서버 및 그 제어방법
JP2004056317A (ja) メール転送システム
EP2227892B1 (en) System and method of retrieving a service contact identifier
CN104427498B (zh) 无线通信协议业务管理方法、设备和系统
KR20100008043A (ko) 도메인 네임 시스템의 데이터베이스에 저장된 정보의 획득방법 및 장치
KR100845235B1 (ko) Ｅｎｕｍ 시스템 및 이에 적용되는 사용자 인증 방법
JP2006039680A (ja) サーバークライアントシステム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20121005

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130611

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130808

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130917

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130930

R150 Certificate of patent or registration of utility model

Ref document number: 5392267

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150