以下、発明を実施するための最良の形態について図面を参照して説明する。
実施形態1.
図1は、本発明の第1の実施形態の仮名通信アドレス提供システムの構成例を示すブロック図である。図1に示す仮名通信アドレス提供システムは、ユーザ端末10と、メールサーバ20と、HTTPプロキシサーバ30と、Webサーバ41と、通信サービス提供サーバ42とを備えている。また、ユーザ端末10と、メールサーバ20と、HTTPプロキシサーバ30と、Webサーバ41と、通信サービス提供サーバ42とは、それぞれインターネットやNGN(Next Generation Network)などのネットワーク60を介して接続されている。ネットワークへの接続は、有線方式でも無線方式でもよい。
ユーザ端末10は、パーソナルコンピュータ(以下、PCという。)や携帯電話機などの情報処理端末であり、電子メールの送受信が行えるメールクライアント12(より具体的には、メールクライアント・アプリケーション12を実行する処理部)と、ホームページなどのコンテンツの取得を行うラウザ11(より具体的には、ブラウザ・アプリケーション11を実行する処理部)とを有している。
メールクライアント12は、SMTP(Simple Mail Transfer Protocol)プロトコルやPOP(Post Office Protocol)などのプロトコルを用いて、後述するメールサーバ20との間で電子メールの送受信を行うアプリケーションである。
ブラウザ11は、HTTP(Hypertext Transfer Protocol)プロトコルを用いて、後述するWebサーバ41からホームページなどのコンテンツを取得して表示するアプリケーションである。
メールサーバ20は、SMTPプロトコルやPOPなどのプロトコルを用いて、他のメールサーバおよびメールクライアントとの間で電子メールの送受信を行うサーバ装置である。また、本実施形態では、通信アドレス管理部21と通信アドレス変換部22とを有している。
通信アドレス変換部22は、電子メールの送信先または送信元を示すメールアドレスについて、後述するHTTPプロキシサーバ30の仮名通信アドレス管理部33が生成する仮名通信アドレスとユーザ端末のメールクライアントが使用する実通信アドレスとを変換する。
本実施形態では、仮名通信アドレスおよび実通信アドレスの形式が、メールアドレスの形式であるとして説明する。なお、仮名通信アドレスおよび実通信アドレスの形式は、これに限らず、電話番号やIMS(IP Multimedia Subsystems)で使用されるSIP−URI(Session Initiation Protocol−Uniform Resource Identifier)の形式であってもよい。
通信アドレス管理部21は、各ユーザのユーザ端末のアプリケーションが利用する実通信アドレスを保持する。本実施の形態の例において、各ユーザのユーザ端末の通信アプリケーションはメールクライアントであり、実通信アドレスをメールアドレスとする。通信アドレス管理部21は、例えば、RDBMS(Relational DataBase Management System:リレーショナルDB管理システム)などのデータベースシステムで実現できる。
HTTPプロキシサーバ30は、HTTPプロトコル情報取得部31と、仮名通信アドレス提供部32と、仮名通信アドレス管理部33とを有している。
HTTPプロトコル情報取得部31は、一般的なHTTPプロキシサーバが具備する機能に加えて、ブラウザから受信したHTTPプロトコルによる通信データから、ユーザIDとWebサーバIDの情報を取得するとともに、あるユーザ端末10のブラウザ11からあるWebサーバ41へのアクセス状況を検出する。また、あるユーザ端末10のブラウザ11があるWebサーバ41と接続中の間、取得したユーザIDとWebサーバIDとを対応づけて保持する。
ここで、一般的なHTTPプロキシサーバが具備する機能とは、例えば、企業内のネットワークとインターネットとの間に設置され、企業内のPCからホームページへアクセスさせるときに必ずHTTPプロキシサーバを経由させることによって、高速なアクセスを確保するためのデータキャッシュや安全な通信を確保するためのフィルター処理などである。
ユーザIDは、ユーザまたはユーザ端末を識別するための情報であり、例えば、ユーザ端末が携帯電話機ならばSIM(Subscriber Identitiy Module)カードによって付与され、電話番号やメールアドレスを特定するための固有のIDであるIMSI(International Mobile Subscriber Identitiy)などが利用できる。また、PCの場合は、HTTPプロトコルのユーザ認証を利用して、ユーザIDを特定してもよい。
HTTPプロトコルのユーザ認証は、インターネットで利用されるプロトコル技術の標準化を策定するIETF(Internal Engineering Task Force)でHTTPプロトコルの標準仕様であるRFC2068で定義されており、ユーザにPCの画面上でユーザ名とパスワードを入力させることによって、ユーザを特定することでHTTPプロキシサーバの利用を特定のユーザのみに限定するなどの用途に用いられている。
WebサーバIDは、後述するWebサーバを識別するための情報であり、例えば、WebサーバのDNS(Domain Name Server)で使用される完全修飾ドメイン名であるFQDN(Fully Qualified Domain Name)や、FQDNの一部であるドメイン名,サブドメイン名,ホスト名や、WebサーバのIPアドレスなどが利用できる。
また、本実施形態では、HTTPプロトコルの情報を取得する通信装置の例としてHTTPプロシキサーバ30を示しているが、HTTPプロトコルの情報を取得する通信装置は、これに限らず、OSI7階層モデルにおけるトランスポート層(レイヤ4)からアプリケーション層(レイヤ7)のプロトコルを監視するDPI(Deep Packet Inspection)などで実現してもよい。
仮名通信アドレス提供部32は、HTTPプロトコル情報取得部31が検出するユーザ端末10からWebサーバ41へのアクセス状況に基づいて、仮名通信アドレス管理部33に仮名通信アドレスを生成させたり、生成させた仮名通信アドレスを通信サービス提供サーバ42に提供したり、または削除させたりする。
仮名通信アドレス管理部33は、仮名通信アドレス提供部32からの要求に従って、指定されたユーザIDとWebサーバIDとの組み合わせに対して、仮名通信アドレスを生成する。また、仮名通信アドレス管理部33は、仮名通信アドレスが有効である間、生成する際に指定されたユーザIDとWebサーバIDとの組み合わせに関連付けて仮名通信アドレスを保持する。仮名通信アドレスを保持する機能については、例えば、RDBMSなどのデータベースシステムで実現できる。
また、本実施形態では、HTTPプロキシサーバで仮名通信アドレスを発行し、メールサーバで実通信アドレスへの変換を行うことにより、サービス事業者にのみユーザまたはユーザ端末とのコミュニケーションを可能とする仮名通信アドレスを提供しているが、仮名通信アドレスと実通信アドレスの対応づけを行うことなしに、ユーザ端末と通信サービス提供サーバの両方へ仮名通信アドレスを提供することも可能である。
Webサーバ41は、ユーザ端末10からのHTTPプロキシサーバ30を経由して受信するHTTPのリクエストに応じて、ホームページなどのコンテンツを出力する。
通信サービス提供サーバ42は、HTTPプロキシサーバ30の仮名通信アドレス提供部32から提供される仮名通信アドレスを利用して、広告やインフォメーションなどの情報をユーザ端末に向けて送信する。本実施形態では、提供された仮名通信アドレスを宛て先アドレスとする電子メールをメールサーバ20に送信する。
また、本実施形態では、通信サービス提供サーバ42を、広告メールを送信するメール送信サーバとして説明するが、通信サービス提供サーバは、これに限らず、ユーザ端末であってもよい。例えば、ブログ(Blog)の開設者をサービス事業者として捉え、該開設者が使用するユーザ端末を通信サービス端末とみなして、該ユーザ端末(ブログ開設者の端末)に、該ブログを閲覧したユーザまたはユーザ端末(ブログ閲覧者の端末)へのコミュニケーションを可能とする仮名通信アドレスを提供することもできる。このような場合には、ブログ閲覧者がブログ開設者に現実の通信アドレス(実通信アドレス)を開示することなく、ブログ開設者からブログ閲覧者への電子メールの送付などの通信サービスが可能となる。
図2は、仮名通信アドレス管理部33が保持するデータの例を示す説明図である。図2では、仮名通信アドレス管理部33が保持するデータの構成として、ユーザID(331)とWebサーバID(332)と仮名通信アドレス(333)の項目を有する例が示されている。
また、図3は、通信アドレス管理部21が保持するデータの例を示す説明図である。図3では、通信アドレス管理部21が保持するデータの構成として、ユーザID(211)と、実通信アドレス(212)の項目を有する例が示されている。
本実施形態の例では、メールサーバ20とHTTPプロキシサーバ30を携帯会社や固定電話会社などの同じ通信事業者が運営するものとして説明する。従って、メールサーバ20が保持するユーザID(211)と、HTTPプロキシサーバ30が保持するユーザID(331)とは、同一のユーザまたはユーザ端末を示すものとする。
ただし、メールサーバ20とHTTPプロキシサーバ30の運営者は、これに限らず、異なる事業主であってもよい。この場合、メールサーバ20が保持するユーザID(211)と、HTTPプロキシサーバ30が保持するユーザID(331)とは同一のユーザまたはユーザ端末を指し示す場合であっても異なる値となるが、このような場合には、事業者が異なるユーザID同士で予め関連づけを行えばよい。例えば、メールサーバ20の事業者とHTTPプロキシサーバ30の事業者との間で同一のユーザまたはユーザ端末を指し示す新たな仮名のユーザIDを提示し、お互いの事業者でこの仮名のユーザIDと本来のユーザIDを関連付けてもよい。このような仕組みは、標準化団体であるOASISによって策定されたIDやパスワードを安全にやり取りされるXML仕様であるSAML(Security Assertion Markup Language)などを用いて一般的に利用されている。
次に、HTTPプロトコル情報取得部31によるユーザ端末からWebサーバへのアクセス状況の検出方法について説明する。本実施形態では、説明を簡単にするために、ユーザ端末10は、ブラウザ11の機能を利用して、Webサーバ毎に1本のHTTP Keep Aliveを使用するものとする。そして、HTTPプロトコル情報取得部31は、取得した通信データにより示されるHTTP Keep Aliveがユーザ端末(ブラウザ)とWebサーバ間に確立している間をホームページ接続中、HTTP Keep Aliveの切断をホームページからの切断として検出する。HTTP Keep Aliveは、1回のTCP(Transmission Control Protocol)接続で複数のHTTPリクエストを処理する機能であり、その仕様はRFC2616で規定されている。
また、ホームページへの接続中および切断の検出方法の別の例として、ユーザが一度認証を受けるだけで許可されているすべてのWebサーバが利用できるようになるシングルサインオンと連携して、ホームページへの接続およびホームページからの切断を検出してもよい。シングルサインオンを実現するために、既に説明したSAMLなどを利用できる。
例えば、事前に通信事業者(ここでは、HTTPプロキシサーバとメールサーバの運用事業者)と、Webサービス事業者(Webサーバの運用者や通信サービス提供サーバの運用者)の各ユーザIDをID Federationという技術で紐付けする。その際、テンポラリーな仮ユーザIDが発行される。また、ユーザ端末から通信事業者へのログイン操作がされた場合には、通信事業者側でその旨を保持しておく。その後、ユーザ端末からWebサービス事業者へのアクセスを契機に、Webサービス事業者から通信事業者へ仮ユーザIDを指定してログイン済みのユーザか否かの問い合わせが行われる。通信事業者は、仮ユーザIDに紐付けたログイン状態をWebサービス事業者へ提示する。
このようなシングルサインオンの動作において、ユーザ端末に、HTTPプロキシサーバを利用する前提としてシングルサインオンのログインを求め、Webサービス事業者(より具体的には、Webサーバ)から通信事業者(より具体的には、HTTPプロキシサーバ)へのログイン状況の問い合わせにより、ホームページのアクセス開始を認識することができる。
また、シングルサインオンには、一括でログイン状態を解消するシングルサインオフという動作もあるので、シングルサインオフが実施されたときには、ホームページからの切断と判断することも可能である。
さらに、ホームページからの切断の検出方法は、これらに限らず、ユーザ端末が携帯電話機のような無線通信装置の場合は、ユーザ端末と無線基地局との間の無線リンクを制御するUTRAN(UMTS Terrestrial Radio Access Network)において検出される無線リンクの切断により判断してもよい。また、HTTPプロトコルのアクセス状況としてHTTPプロトコルの転送が一定時間行わなかったことを計時手段によって検出することで切断と判断してもよい。また、ユーザ端末から切断を示す信号を別途受信する方法で切断を検出してもよい。
次に、本実施形態の動作について説明する。図4および図5は、本実施形態の仮名通信アドレス提供システムの動作の一例を示すシーケンス図である。なお、図4は、仮名通信アドレスの発行に係る動作例を示すシーケンス図である。また、図5は、仮名通信アドレスの失効に係る動作例を示すシーケンス図である。なお、図4および図5において、破線矢印で示すメッセージは、受信したリクエストに対するレスポンスであることを表している。
図4に示すように、まず、ユーザ端末10のブラウザ11(より具体的には、ブラウザ・アプリケーション実行部11)は、ユーザ操作に応じて、指定されたホームページを取得するためのHTTPリクエストをWebサーバ41に向けて送信する(ステップS101)。本例では、ユーザIDとして”user0001”が割り当てられているユーザ端末10のブラウザ11から、URL”http://www.restaurant.co.jp/booking_service.html”にアクセスした場合を例に説明する。
ユーザ端末10から送信されたHTTPリクエストは、直接Webサーバ41に受信されるのではなく、HTTPプロキシサーバ30のHTTPプロトコル情報取得部31に受信される。HTTPプロキシサーバの経由方法としては、例えば、ブラウザの設定で直接HTTPプロキシサーバのアドレスやポート番号を指定してもよいし、ルータやブリッジにおいて特定のポート番号を監視して後段のHTTPプロキシサーバへプロトコルを転送(リダイレクト)することによって、ブラウザで特別な設定をせずにHTTPプロキシサーバを利用できるようにする透過型プロキシ(Transparent Proxy)として実現してもよい。
HTTPプロキシサーバ30のHTTPプロトコル情報取得部31は、ユーザ端末10からWebサーバ41へのHTTPプロトコルによる通信データ(ここでは、HTTPリクエスト)を受信すると、受信した通信データのHTTPプロトコルにより特定されるユーザIDとWebサーバIDを取得するとともに、本通信データがHTTPリクエストであることを検知し、取得したユーザIDで識別されるユーザ端末10(またはユーザが使用しているユーザ端末)から同じく取得したWebサーバIDで識別されるWebサーバ41へのアクセス状況をホームページ接続中として検出する(ステップS102)。そして、取得したユーザIDとWebサーバIDを含むホームページ接続通知により仮名通信アドレス提供部32へ該組み合わせにおけるアクセス状況を通知する(ステップS103)。本例では、ユーザIDとして”user0001”を、WebサーバIDとしてURL”http://www.restaurant.co.jp/booking_service.html”のFQDNである”www.restaurant.co.jp”を含むホームページ接続通知を仮名通信アドレス提供部32に出力する。
なお、HTTPプロトコル情報取得部31と仮名通信アドレス提供部32との間のデータのやりとりには、XML(Extensible Markup Language)とHTTPなどをベースとしたSOAP(Simple Object Access Protocol)などを利用してもよい。
その後、HTTPプロトコル情報取得部31は、送信元であるユーザ端末10のブラウザ11の代理として、アクセス先であるWebサーバ41にHTTPリクエストを送信する(ステップS104)。
Webサーバ41は、HTTPプロキシサーバ30を経由してユーザ端末10からのHTTPリクエストを受信する。Webサーバ41は、受信したHTTPリクエストを解析して、必要なホームページなどのコンテンツをHTTPレスポンスとして返信する(ステップS105)。
Webサーバ41から送信されるHTTPレスポンスは、HTTPプロキシサーバ30のHTTPプロトコル情報取得部31に受信される。HTTPプロトコル情報取得部31は、Webサーバ41から受信したHTTPレスポンスを本来の送信元であるユーザ端末10のブラウザに返信する(ステップS106)。
ユーザ端末10のブラウザ11は、HTTPレスポンスを受信すると、そのHTTPレスポンスに含まれるホームページなどのコンテンツをディスプレイに表示する。
また一方で、仮名通信アドレス提供部32は、HTTPプロトコル情報取得部31からホームページ接続通知を受信すると、そのホームページ接続通知に含まれるユーザIDとWebサーバIDとを指定して、仮名通信アドレス管理部33に仮名通信アドレスの生成を依頼する。本例では、受信したホームページ接続通知に含まれるユーザID”user0001”とWebサーバID”www.restaurant.co.jp”とを含む仮名通信アドレスの生成リクエストを仮名通信アドレス管理部33に送信する(ステップS107)。
仮名通信アドレスの生成リクエストを受信した仮名通信アドレス管理部33は、その取得リクエストに含まれているユーザIDとWebサーバIDの組み合わせに対して、仮名通信アドレスが既に関連づけられていなければ、新たに仮名通信アドレスを生成する(ステップS108)。例えば、仮名通信アドレス管理部33は、指定されたユーザIDとWebサーバIDの組み合わせに対して、新たな仮名通信アドレスの関連付けを行えばよい。関連づける仮名通信アドレスは、仮名通信アドレスの取得リクエストの受信を契機に、乱数を用いて生成してもよいし、事前に用意してある未使用の仮名通信アドレスから選択してもよい。本例では、ユーザID”user0001”とWebサーバID”www.restaurant.co.jp”の組み合わせに対して、仮名通信アドレス”temp0002@carrier.com”の関連付けを実施したとする。
仮名通信アドレスの関連づけを完了すると、仮名通信アドレス管理部33は、指定されたユーザIDとWebサーバIDに対して関連づけた仮名通信アドレス(本例では、”temp0002@carrier.com”)を含む仮名通信アドレスの生成レスポンスを仮名通信アドレス提供部32に返信する(ステップS109)。なお、仮名通信アドレス管理部33は、仮名通信アドレスの生成リクエストを受信した際に、既に指定されたユーザIDとWebサーバIDの組に対して仮名通信アドレスが関連づけられていた場合には、仮名通信アドレスが提供済みである旨を返信すればよい。
仮名通信アドレスの生成レスポンスを受信した仮名通信アドレス提供部32は、生成リクエストで指定したWebサーバIDに予め関連づけられている通信サービス提供サーバ42へ、生成された仮名通信アドレスを提供する。本例では、仮名通信アドレス提供部32は、仮名通信アドレス”temp0002@carrier.com”を含む仮名通信アドレスの払出通知を、WebサーバIDから求まる通信サービス提供サーバ42に送信する(ステップS110)。仮名通信アドレスの送信先となる通信サービス提供サーバ42は、例えば、WebサーバIDのFQDNから通信サービス提供サーバ42のFQDNを自動生成する規則を定義しておき、その規則に基づいて求めてもよい。
例えば、WebサーバIDがFQDNの場合、ホスト名である”www”を”pseudonym”に置換するという自動生成する規則を定義しておくことにより、WebサーバID”www.restaurant.co.jp”から通信サービス提供サーバのFQDNである” pseudonym.restaurant.co.jp”を求めることができる。
また、例えば、WebサーバIDが”192.168.122.139”といったIPアドレスであった場合、WebサーバIDのIPアドレスに対して、TCPのポート番号”:8090”を限定することにより、通知先の通信サービス提供サーバのアドレス(本例では、”192.168.122.139:8090”)とする自動生成の規則を提示してもよい。
通信サービス提供サーバ42では、仮名通信アドレス提供部32からの仮名通信アドレスの払出通知を受けて、その払出通知に含まれる仮名通信アドレスを、そのWebページに興味を示したユーザのアドレスとして利用することができるようになる。例えば、通信サービス提供サーバ42は、仮名通信アドレスを用いて広告メールなどの通信サービスを行ってもよい。本例では、仮名通信アドレス”temp0002@carrier.com”を電子メールの宛先アドレスに指定して送信する(ステップS111)。
通信サービス提供サーバ42から送信された電子メールは、メールサーバ20が受信する。電子メールを受信したメールサーバ20では、その電子メールの宛先アドレスが仮名通信アドレスであることを受けて、通信アドレス変換部22が、実通信アドレスへの変換を行う。本例では、通信アドレス変換部22は、電子メールの宛先アドレスから仮名通信アドレスを取得して、HTTPプロキシサーバ30の仮名通信アドレス管理部33へ、取得した仮名通信アドレス(ここでは、”temp0002@carrier.com”)を指定したユーザIDの取得リクエストを送信する(ステップS112)。
仮名通信アドレス管理部33は、自身で保持している、仮名通信アドレスとユーザIDとWebサーバIDとを関連付けた情報を検索して、指定された仮名通信アドレス”temp0002@carrier.com”に対応するユーザID”user0001”を解決して、要求元の通信アドレス変換部22に、得られたユーザID”user0001”を含むユーザIDの取得レスポンスを返信する(ステップS113)。なお、該当するユーザIDが存在しなければ、通信アドレス変換部22に、ユーザIDの取得が失敗した旨を通知する。
通信アドレス変換部22は、ユーザIDの取得レスポンスを受信すると、ユーザIDが解決したことを受けて、そのユーザIDから実通信アドレスを解決する。本例では、受信したユーザIDの取得レスポンスに含まれるユーザID(ここでは、”user0001”)を指定して、通信アドレス管理部21に実通信アドレスの取得リクエストを送信する(ステップS114)。なお、ユーザIDの取得に失敗した旨の返信を受けた場合には、通信サービス提供サーバ42(メールの送信元)に、メールの送信が失敗した旨を通知して処理を終了すればよい。
実通信アドレスの取得リクエストを受信した通信アドレス管理部21は、指定されたユーザID”user0001”を検索キーとして実通信アドレスを解決して、要求元の通信アドレス変換部22に、得られた実通信アドレスを含む実通信アドレスの取得レスポンスを返信する(ステップS115)。本例では、ユーザID”user0001”に対して、実通信アドレス”alice@carrier.com”が通信アドレス管理部21に関連づけられて保持されていたとする。通信アドレス管理部21は、実通信アドレスとして、実通信アドレス”alice@carrier.com”を含む実通信アドレスのレスポンスを通信アドレス変換部22に返信する(ステップS115)。
通信アドレス変換部22は、通信アドレス管理部21からの実通信アドレスのレスポンスを受けて、受信した電子メールの宛先アドレスとして付与されている仮名通信アドレス”temp0002@carrier.com”を、実通信アドレス”alice@carrier.com”に変換し、その実通信アドレスによって特定されるユーザ端末10に電子メールを到達させる(ステップS116,S117)。
ユーザ端末10では、メールクライアント12が、電子メールを受信し、その内容をディスプレイなどに表示する。これによって、ユーザは、自身が興味を示したホームページに関連するサービス事業者からの情報提供サービスを実通信アドレスを開示することなく受けることができる。
また、サービス事業者に提供した仮名通信アドレスは、次のように失効させてもよい。例えば、ユーザがブラウザ11でのホームページの閲覧を終了すると、ユーザ端末10のブラウザ11は、HTTPプロキシサーバ30へTCP切断通知を送信する(図5のステップS201)。
HTTPプロキシサーバ30のHTTPプロトコル情報取得部31は、ユーザ端末10からWebサーバ41へのHTTPプロトコルによる通信データ(ここでは、TCP切断通知)を受信すると、受信した通信データのHTTPプロトコルにより特定されるユーザIDとWebサーバIDを取得するとともに、本通信データがTCP切断通知であることを検知し、取得したユーザIDで識別されるユーザ端末10(またはユーザが使用しているユーザ端末)から同じく取得したWebサーバIDで識別されるWebサーバ41へのアクセス状況を切断として検出する(ステップS202)。そして、取得したユーザIDとWebサーバIDを含むホームページ切断通知により仮名通信アドレス提供部32へ該組み合わせにおけるアクセス状況を通知する。本例では、切断されるTCPセッションと現在関連づけられているユーザID”user0001”とWebサーバID”www.restaurant.co.jp”とを含むホームページ切断通知を仮名通信アドレス提供部32に送信する(ステップS203)。
また、HTTPプロトコル情報取得部31は、ユーザ端末10とWebサーバ41との間に張ったTCPセッションを切断する。ここでは、Webサーバ41へTCP切断通知を送信する(ステップS204)。なお、TCPセッションの完全な切断手順は、TCPセッションを張っている両方の装置からFINと呼ばれる終了信号を送信し合うことによって行われるが、ここでは説明を省略する。
ホームページ切断通知を受信した仮名通信アドレス提供部32は、通知されたユーザIDとWebサーバIDの組み合わせに対して現在関連づけられている仮名通信アドレスの削除を仮名通信アドレス管理部33に依頼する。本例では、通知されたユーザID”user0001”とWebサーバID”www.restaurant.co.jp”とを含む仮名通信アドレスの削除リクエストを仮名通信アドレス管理部33に送信する(ステップS205)。
仮名通信アドレスの削除リクエストを受信した仮名通信アドレス管理部33は、自身で保持している情報において、受信した仮名通信アドレスの削除リクエストに含まれるユーザID(ここでは、”user0001”)とWebサーバID(ここでは、”www.restaurant.co.jp”)の組に現時点で関連づけられている仮名通信アドレスを削除し、削除結果を仮名通信アドレス提供部32に返信する(ステップS205)。このとき、仮名通信アドレス管理部33は、関連付けられている仮名通信アドレスの情報のみを削除してもよいし、ユーザIDとWebサーバIDと仮名通信アドレスを含むレコード全体(行)を削除してもよい。
以上のように、本実施形態によれば、ユーザ端末10によるブラウザ11を用いたWebサーバへのHTTPプロトコルによるアクセスの状況に基づいて、仮名通信アドレスを、該Webサーバが公開しているWebページに関連する通信サービス提供サーバに提供することができる。
これにより、該通信サービス提供サーバを運用しているサービス事業者は、ユーザ端末がホームページに接続している間だけ、仮名通信アドレスを用いたユーザ端末への電子メール等による広告の配信が可能になる。また、ユーザにとっても、興味を示したWebページに関連するサービス事業者(例えば、該Webページを運用しているサービス事業者)から、個人情報を開示することなく、広告などの電子メールを受け取ることができる。
実施形態2.
次に、本発明の第2の実施形態について説明する。本実施形態では、HTTPプロキシサーバにおいて、ユーザ端末から送信されるHTTPリクエストに対して、仮名通信アドレスの提供有無や提供先とするサービス事業者を設定する。
図6は、第2の実施形態による仮名通信アドレス提供システムの構成例を示すブロック図である。図6に示す仮名通信アドレス提供システムは、第1の実施形態と比べて、HTTPプロキシサーバ30がさらに仮名通信アドレス提供条件管理部34を有する点が異なる。
仮名通信アドレス提供条件管理部34は、仮名通信アドレスを提供する条件となるアクセス元のWebサーバの情報を保持する。仮名通信アドレス提供条件管理部34は、例えば、RDBMSなどのデータベースシステムで実現できる。図7は、仮名通信アドレス提供条件管理部34が保持するデータの例を示す説明図である。図7では、仮名通信アドレス提供条件管理部34が保持するデータの構成として、WebサーバID(341)と、通信サービス提供サーバアドレス(342)の項目を有する例が示されている。
通信サービス提供サーバアドレス(342)は、仮名通信アドレスの提供先となる通信サービス提供サーバのネットワークアドレスを登録する。なお、通信サービス提供サーバアドレス(343)には、仮名通信アドレスを受信することができるネットワークアドレスを登録する。本例では、通信サービス提供サーバアドレスにFQDNおよびIPアドレスを格納した。もちろん通信サービス提供サーバアドレスは、これに限定されずに、SOAPで通信先のアドレスやサービスに用いられるメッセージのフォーマットやプロトコルなどを示すWSDL(Web Services Description Language)などのWebサービス記述言語のデータ形式で格納することも可能である。
なお、図7に示す例では、仮名通信アドレスの提供の契機となるWebサーバIDと仮名通信アドレスの提供先となる通信サービス提供サーバのアドレスとを直接に関連付けることにより、仮名通信アドレスの提供の契機となるWebサーバを絞り込む例である。なお、Webサーバの絞り込み方法はこれに限定されるものではなく、例えば、WebサーバIDに対して、提供の有無を示す情報を関連付けてもよい。また、Webサーバの事業主を示すIDを関連付けてもよい。
また、例えば、図8に示すように、仮名通信アドレスの提供の契機となるWebサーバIDと、仮名通信アドレスの提供先となる通信サービス提供サーバを運営している事業主を示すIDとを関連付けてもよい。図8は、仮名通信アドレス提供条件管理部34が保持するデータの他の例を示す説明図である。図8では、仮名通信アドレス提供条件管理部34が保持するデータの構成として、WebサーバID(341)と、サービス事業者ID(343)と、通信サービス提供サーバアドレス(342)の項目を有する例が示されている。
サービス事業者ID(343)は、WebサーバIDが示すホームページへのアクセスを契機に通信サービスを行うことを許可する事業者を識別するための情報であって、仮名通信アドレスの提供先となる通信サービス提供サーバを運営している事業者を識別するための情報である。このサービス事業者は、Webサーバの運営者と同じであっても、異なっていてもよい。また、本例のように、複数のWebサーバID”www.restaurant1.co.jp”と”www.restaurant2.co.jp”とに対して、1つのサービス事業者ID”service0001”を関連づけることも可能である。なお、1つのWebサーバIDに複数のサービス事業者を対応づけることも可能である。また、この例では、複数のWebサーバIDを格納するための区切り記号として、改行コードを入れて表現した。もちろん区切り記号はこれに限定されず、空白文字、句読点、特殊文字その他の区切りを示す記号であればよい。
また、図9は、本実施形態における仮名通信アドレス管理部33で保持されるデータの例を示す説明図である。本実施形態では、仮名通信アドレス管理部33は、図9に示すように、WebサーバID(332)に代えて、仮名通信アドレス提供条件管理部34により通信先の識別情報として用いられる通信サービス提供サーバアドレス(332B)の項目を有するデータ構成であってもよい。なお、通信サービス提供サーバアドレスではなく、サービス事業者IDとすることも可能である。
また、本実施形態では、仮名通信アドレス提供部32は、ユーザ端末がホームページにアクセスしたことを受けて、そのホームページを公開しているWebサーバの情報から無条件に仮名通信アドレスを提供するのではなく、仮名通信アドレス提供条件管理部34に保持されている情報に基づいて、そのWebサーバが仮名通信アドレスの契機となるWebサーバか否かを判断した上で、仮名通信アドレスを提供する。
次に、本実施形態の動作について説明する。図10は、本実施形態の仮名通信アドレス提供システムの動作の一例を示すシーケンス図である。なお、本例において、HTTPのリクエストを送信してWebサーバからホームページの情報を受信するまでのユーザ端末10、WebサーバおよびHTTPプロトコル情報取得部31の動作(ステップS301〜306)は、第1の実施形態(ステップS101〜106)と同様であるため、説明省略する。以下、本例では、ユーザID”user0001”のユーザ端末が、WebサーバID”www.restaurant.co.jp”のWebサーバにアクセスした場合を例に説明する。
ステップS307において、HTTPプロトコル情報取得部31からホームページ接続通知を受信した仮名通信アドレス提供部32は、仮名通信アドレス提供条件管理部34に、そのホームページ接続通知に含まれるWebサーバID(”ここでは、”www.restaurant.co.jp”)を指定した通信サービス提供サーバアドレスの取得リクエストを送信する。なお、仮名通信アドレス提供条件管理部34が保持するデータが図8に示すようなデータ構成であれば、サービス事業者IDの取得リクエストであってもよい。
通信サービス提供サーバアドレスの取得リクエストを受信した仮名通信アドレス提供条件管理部34は、保持しているデータの中から、指定されたWebサーバIDと対応づけられている通信サービス提供サーバアドレスを求めて、通信サービス提供サーバアドレスの取得レスポンスとして仮名通信アドレス提供部32に返信する(ステップS308)。例えば、図7に示す例では、WebサーバID”www.restaurant.co.jp”に対して、通信サービス提供サーバアドレス”adagency.restaurant.co.jp”を求めて、それを返信すればよい。
このとき、仮名通信アドレス提供条件管理部34において、仮名通信アドレス管理部33より通知されたWebサービスIDに対して、対応する通信サービス提供サーバアドレスが存在しなかった場合には、該当する通信サービス提供サーバアドレスが存在しなかった旨を仮名通信アドレス提供部32に返信すればよい。
通信サービス提供サーバアドレスの取得レスポンスを受信した仮名通信アドレス提供部32は、該当する通信サービス提供サーバアドレスが存在すれば、その通信サービス提供サーバアドレスに向けて、仮名通信アドレスの提供を行えばよい。なお、仮名通信アドレスの提供は、通信サービス提供サーバアドレスの取得レスポンスに含まれる通信サービス提供サーバアドレスに、仮名通信アドレス管理部33に生成させた仮名通信アドレスを送信することにより行えばよい。仮名通信アドレスの生成動作は、第1の実施形態と基本的には同様でよいが、ステップS309においては、仮名通信アドレスの生成リクエストにWebサーバIDを指定する代わりに、通信サービス提供サーバアドレス(またはサービス事業者ID)を指定して送信する。また、仮名通信アドレス管理部33では、ユーザIDと通信サービス提供サーバアドレス(またはサービス事業者ID)の組に対して仮名通信アドレスの関連づけを行い、関連づけた仮名通信アドレスを返信すればよい(ステップS310,S311)。なお、仮名通信アドレス管理部33は、仮名通信アドレスの取得リクエストを受信した際に、既に指定されたユーザIDと通信サービス提供サーバアドレス(またはサービス事業者ID)の組に対して既に仮名通信アドレスが存在していた場合には、仮名通信アドレスが提供済みである旨を返信すればよい。
一方、仮名通信アドレス提供条件管理部34からの通信サービス提供サーバアドレスの取得レスポンスにおいて、該当する通信サービス提供サーバアドレスが存在しなかった場合には、仮名通信アドレス提供部32は、以降の仮名通信アドレスの提供処理は行わずに処理を終了する。これにより、仮名通信アドレス提供条件管理部34に登録されていないWebサーバへのアクセスを仮名通信アドレスの提出の契機として扱わないようにことができる。
また、仮名通信アドレス提供部32は、仮名通信アドレスが提供済みである旨を仮名通信アドレス管理部33から返信された場合には、本処理における仮名通信アドレスの提供は行わずに、そのまま処理を終了する。同一のユーザについて再度の仮名通信アドレスの提供は不要だからである。これ以降の動作は、第1の実施形態と同じである。
以上のように、本実施形態によれば、ユーザ端末10によるブラウザ11を用いたWebサーバへのHTTPプロトコルによるアクセスのうち、仮名通信アドレスの提供先とするサービス事業者と、仮名通信アドレスの提出先としないサービス事業者を区別することを可能にする。
また、アクセス先となるWebサーバと通知先となる通信サービス提供サーバとの関連付けをシステム運営者側で自由に設定することができるので、仮名通信アドレスの提供先とするサービス事業者が、複数のFQDNによるWebサーバを運用していても、同一サービス事業者に対して仮名通信アドレスの重複した提供を除外することができる。なお、他の点に関しては、第1の実施形態と同様である。
実施形態3.
次に、本発明の第3の実施形態について説明する。本実施形態では、HTTPプロキシサーバにおいて、ホームページへのアクセス状況だけでなく、ユーザの嗜好情報とを基に、仮名通信アドレスの提供先とするサービス事業者を決定する。
図11は、第3の実施形態による仮名通信アドレス提供システムの構成例を示すブロック図である。図11に示す仮名通信アドレス提供システムは、第2の実施形態と比べて、HTTPプロキシサーバ30がさらにユーザ嗜好情報管理部35を有する点が異なる。
ユーザ嗜好情報管理部35は、ユーザの嗜好情報を保持する。ユーザ嗜好情報管理部35は、例えば、RDBMSなどのデータベースシステムで実現できる。図12は、ユーザ嗜好情報管理部35が保持するデータの例を示す説明図である。図12では、ユーザ嗜好情報管理部35が保持するデータの構成として、ユーザID(351)と、サービスカテゴリ(352)の項目を有する例が示されている。
ここで、ユーザID(351)は、HTTPプロトコル情報取得部31により取得されるユーザIDであって、本システムの利用者であるユーザまたはユーザ端末を識別するための情報である。また、サービスカテゴリ(352)は、ユーザが興味を持っている情報サービスのカテゴリを示す情報である。図12では、ユーザID”user0001”が興味を持っている情報サービスのカテゴリとして、”ディナー,車,カメラ,天体”が登録されている例が示されている。図12に示す例では、複数のサービスカテゴリを格納するための区切り記号として、「,」コードを入れて表現した。もちろん区切り記号はこれに限定されず、空白文字、句読点、特殊文字その他の区切りを示す記号であればよい。
また、図13は、本実施形態における仮名通信アドレス提供条件管理部34で保持されるデータの例を示す説明図である。本実施形態では、仮名通信アドレス提供条件管理部34は、図13に示すように、さらに仮名通信アドレスの提供条件として、WebサーバIDが示すホームページのサービスカテゴリ(344)の項目を追加している。サービスカテゴリ(344)は、そのWebサーバIDが示すホームページが提供している情報サービスのカテゴリを示す情報である。例えば、そのホームページがどのようなカテゴリの情報を提供するサービスを行うかが示される。
また、仮名通信アドレス提供部32は、ユーザ端末がホームページにアクセスしたことを受けて、そのホームページのサービスカテゴリが、アクセスしたユーザの嗜好情報に合致する場合にのみ仮名通信アドレスを提供する。
次に、本実施形態の動作について説明する。図14は、本実施形態の仮名通信アドレス提供システムの動作の一例を示すシーケンス図である。なお、本例においても、HTTPのリクエストを送信してWebサーバからホームページの情報を受信するまでのユーザ端末10、WebサーバおよびHTTPプロトコル情報取得部31の動作は、第1の実施形態(ステップS101〜106)と同様であるため、説明を省略する。以下、本例では、ユーザID”user0001”のユーザ端末が、WebサーバID”www.restaurant.co.jp”のWebサーバにアクセスした場合を例に説明する。
HTTPプロトコル情報取得部31からホームページ接続通知を受信した仮名通信アドレス提供部32は、まず、アクセス先となったWebサーバに関する仮名通信アドレスの提供条件を確認する。本例では、仮名通信アドレス提供条件管理部34に、そのホームページ接続通知に含まれるWebサーバID(”ここでは、”www.restaurant2.co.jp”)を指定した提供条件の取得リクエストを送信する(ステップS401)。
提供条件の取得リクエストを受信した仮名通信アドレス提供条件管理部34は、保持しているデータの中から、指定されたWebサーバIDと対応づけられている通信サービス提供サーバアドレス(342)およびサービスカテゴリ(344)を求めて、提供条件の取得レスポンスとして仮名通信アドレス提供部32に返信する(ステップS402)。例えば、図13に示す例では、WebサーバID”www.restaurant.co.jp”に対して、通信サービス提供サーバアドレス”adagency.restaurant.co.jp”とサービスカテゴリ”ディナー,ランチ”を求めて、それを返信すればよい。
また、仮名通信アドレス提供部32は、ユーザ嗜好情報管理部35に、ホームページ接続通知に含まれるユーザIDを指定して、ユーザ嗜好情報の取得リクエストを送信する(ステップS403)。なお、仮名通信アドレス提供条件管理部34からの返信において、該当する通信サービス提供サーバが存在しなかった場合には、ユーザ嗜好情報の取得リクエストを送信せずに処理を終了してもよい。
ユーザ嗜好情報の取得リクエストを受信したユーザ嗜好情報管理部35は、指定されたユーザID”user0001”に関連付けられているサービスカテゴリ(352)を求めて、ユーザ嗜好情報の取得レスポンスとして仮名通信アドレス提供部32に返信する(ステップS404)。例えば、図13に示す例では、ユーザID”user0001”に対して、サービスカテゴリ”ディナー,車,カメラ,天体”を求めて、それを返信すればよい。
仮名通信アドレス提供部32は、提供条件の取得レスポンスに含まれるWebサーバのサービスカテゴリの情報と、ユーザ嗜好情報の取得レスポンスに含まれるユーザの興味を示すサービスカテゴリの情報とを比較して、両者で一致するものを抽出する(ステップS405)。本例において、一致するサービスカテゴリは”ディナー”である。
そして、仮名通信アドレス提供部32は、比較した結果、一致するサービスカテゴリが存在するならば、当該のユーザIDと通信サービス提供サーバとの組み合わせに対して、仮名通信アドレス提供部32に、仮名通信アドレスの生成を依頼する。なお、仮名通信アドレスの生成に係る処理以降の動作は、第2の実施形態と同様である。一方、一致するサービスカテゴリが存在しない場合には、仮名通信アドレスの提供に係る以降の一連の動作は行わずに処理を終了すればよい。
なお、本実施形態では、仮名通信アドレス提供部32は、仮名通信アドレスを通信サービス提供サーバに提供する際に、その仮名通信アドレスを利用可能なサービスカテゴリを指定してもよい。例えば、ユーザが興味を示すカテゴリとして登録されているユーザのサービスカテゴリとサービス事業者のサービスカテゴリとの間で一致するサービスカテゴリについてのみ情報提供サービスを利用可能であるとして、そのサービスカテゴリ(本例では”ディナー”)を指定してもよい。
以上のように、本実施形態によれば、さらにユーザの嗜好情報を基に、仮名通信アドレスの提供先とするサービス事業者を決定するので、仮名通信アドレスを用いた通信サービスにおいてユーザが興味を示すカテゴリの情報を提供することができる。
実施形態4.
次に、本発明の第4の実施形態について説明する。本実施形態では、HTTPプロキシサーバにおいて、HTTPプロトコルによるホームページアクセスの履歴を保持し、そのアクセス履歴を基に、通信サービス提供サーバからのリクエストに応じて、仮名通信アドレスの払い出しを行う。
図15は、第4の実施形態による仮名通信アドレス提供システムの構成例を示すブロック図である。図15に示す仮名通信アドレス提供システムは、第3の実施形態と比べて、HTTPプロキシサーバ30がさらにアクセス履歴管理部36を有する点が異なる。
アクセス履歴管理部36は、HTTPプロトコル情報取得部31が検出するユーザ端末からWebサーバへのアクセスの状況を履歴にして保持する。アクセス履歴管理部36は、例えば、RDBMSなどのデータベースシステムで実現できる。図16および図17は、アクセス履歴管理部36が保持するデータの例を示す説明図である。図16および図17では、アクセス履歴管理部36が保持するデータの構成として、ホームページ接続時刻(361)と、ホームページ切断時刻(362)と、ユーザID(363)と、WebサーバID(364)の項目を有する例が示されている。なお、図16において、ホームページ切断(362)における”--”は、ホームページへのアクセスが以前接続中であることが示している。
ここで、ホームページ接続時刻(361)は、ユーザがホームページへのアクセス(接続)を開始した日時である。これは、例えば、HTTPプロトコル情報取得部31がホームページの接続を検出した日時でよい。また、例えば、仮名通信アドレス提供部32がHTTPプロトコル情報取得部31からホームページ接続通知を受け付けた日時であってもよい。
また、ホームページ切断時刻(362)は、ユーザがホームページへのアクセスを切断した日時である。これは、例えば、HTTPプロトコル情報取得部31がホームページからの切断を検出した日時でよい。また、例えば、仮名通信アドレス提供部32が、HTTPプロトコル情報取得部31からホームページ切断通知を受け付けた日時であってもよい。
また、ユーザID(363)は、ユーザまたはユーザ端末を識別する情報である。また、WebサーバID(364)は、Webサーバを識別する情報である。
また、図18は、本実施形態における仮名通信アドレス提供条件管理部34に保持されるデータの例を示す説明図である。本実施形態では、仮名通信アドレス提供条件管理部34は、図18に示すように、さらに仮名通信アドレスの提供条件として、アクセス時間による利用可能回数(345)の項目を追加している。アクセス時間による利用可能回数(345)は、仮名通信アドレスを利用可能な回数を示す情報であって、その仮名通信アドレスの提供の契機となったホームページのアクセス時間に応じて規定される情報である。
また、図19は、本実施形態における仮名通信アドレス管理部33に保持されるデータの例を示す説明図である。仮名通信アドレス提供条件管理部34において仮名通信アドレスの提供条件としてアクセス時間による利用可能回数が設けられている場合には、仮名通信アドレス提供部32は、仮名通信アドレスを生成してユーザIDと通信サービス提供サーバアドレス(またはサービス事業者ID)の組と関連づける際に、さらに利用可能回数(334)を保持する。この利用可能回数(334)の値によって、登録されている仮名通信アドレスがあとどれくらい利用可能かが示される。
また、仮名通信アドレス提供部32は、ユーザ端末10によるホームページのアクセスを契機に仮名通信アドレスを払い出すのではなく、通信サービス提供サーバからのリクエストに応じて、仮名通信アドレスの払い出しを行う。その際、アクセス履歴管理部36に保持されているアクセス履歴を基に、どのユーザに対する仮名通信アドレスを提供するか、また提供する仮名通信アドレスの利用制限について求める。
次に、本実施形態の動作について説明する。図20および図21は、本実施形態の仮名通信アドレス提供システムの動作の一例を示すシーケンス図である。なお、図20は、アクセス履歴の登録に係る動作例を示すシーケンス図である。また、図21は、仮名通信アドレスの提供に係る動作例を示すシーケンス図である。
まず、アクセス履歴の登録に係る動作について説明する。図20に示すように、本実施形態では、ユーザ端末10のブラウザ11より、ホームページの情報を取得するためのHTTPリクエストがWebサーバに向けて送信されると(ステップS501)、それを受信したHTTPプロキシサーバ30のHTTPプロトコル情報取得部31は、受信したHTTPリクエストからユーザIDとWebサーバIDを取得するとともに、ホームページ接続を検出し(ステップS502)、ホームページ接続通知をアクセス履歴管理部36に出力する(ステップS503)。本例では、HTTPリクエストからユーザID”user0001”とWebサーバID”www.restaurant.co.jp”とを取得したものとして説明する。
なお、HTTPプロトコル情報取得部31は、第1の実施形態と同様に、送信元であるユーザ端末10のブラウザ11の代理として、アクセス先であるWebサーバ41にHTTPリクエストを送信する(ステップS504)。HTTPリクエストに係る以降のWebサーバ41およびユーザ端末10の動作(ステップS505,S506)は、第1の実施形態と同様である。
一方、ホームページ接続通知を受信したアクセス履歴管理部36は、通知されたユーザIDとWebサーバIDとを用い、さらに現在日時をホームページ接続時刻(361)として、履歴情報を作成し、記憶領域に格納する(ステップS507)。なお、この時点では、ホームページ接続時刻(362)を空とする(図16参照。)。
また、ユーザがブラウザ11でのホームページの閲覧を終了すると、ユーザ端末10は、HTTPプロキシサーバ30へTCP切断通知を送信する(ステップS601)。
TCP切断通知を受信したHTTPプロキシサーバ30では、HTTPプロトコル情報取得部31が、TCPセッションを切断するとともに、ホームページへのアクセス状況を切断として検出し(ステップS602)、取得したユーザIDおよびWebサーバIDを指定したホームページ切断通知をアクセス履歴管理部36に送信する(ステップS603)。また、Webサーバ41へTCP切断通知を送信する(ステップS604)。
ホームページ切断通知を受信したアクセス履歴管理部36は、通知されたユーザIDとWebサーバIDとを用い、保持しているアクセス履歴の中から同じ組み合わせの現在接続中の履歴情報(行)を検索して、現在日時をホームページ切断時刻(362)として格納する(ステップS605)。なお、現在接続中か否かは、ホームページ接続時刻(362)の値が空になっているか否かで判断すればよい。
次に、仮名通信アドレスの提供に係る動作について説明する。図21に示すように、本実施形態では、通信サービス提供サーバ42から、HTTPプロキシサーバ30の仮名通信アドレス提供部32への仮名通信アドレスの取得リクエストの送信を契機に、仮名通信アドレスの提供を行う。なお、通信サービス提供サーバ42からの仮名通信アドレスの取得リクエストの送信タイミングは、任意である。
ステップS701において、通信サービス提供サーバ42から、当該通信サービス提供サーバ42のアドレス(またはサービス事業者ID)を含む仮名通信アドレスの取得リクエストが送信されると、HTTPプロキシサーバ30の仮名通信アドレス提供部32は、アクセス履歴管理部36に保持されているアクセス履歴を基に、どのユーザに対する仮名通信アドレスを提供するか、また提供する仮名通信アドレスの利用可能回数等について決定する。以下では、通信サービス提供サーバアドレスとして”adagency.restaurant.co.jp”が指定された場合を例に説明する。
まず、仮名通信アドレス提供部32は、仮名通信アドレスの取得リクエストに含まれる通信サービス提供サーバアドレスを指定して、仮名通信アドレス提供条件管理部34に、その通信サービス提供サーバアドレスを提出先とする際の提供条件の取得リクエストを送信する(ステップS702)。なお、ここでの提供条件には、少なくともその通信サービス提供サーバアドレスを提出先とするWebサーバIDの情報を含むものとする。
提供条件の取得リクエストを受信した仮名通信アドレス提供条件管理部34は、指定された通信サービス提供サーバアドレスが提出先(342)として登録されているWebサーバID(341)と、サービスカテゴリ(344)およびアクセス時間による利用可能回数(345)を取得して、提供条件の取得レスポンスとして仮名通信アドレス提供部32に返信する(ステップS703)。例えば、図18に示す例では、WebサーバID”www.restaurant.co.jp”と、サービスカテゴリ”ディナー,ランチ”と、アクセス時間による利用可能回数”15分”を含む提供情報の取得レスポンスが送信される。
返信を受けた仮名通信アドレス提供部32は、提供情報の取得レスポンスに含まれるWebサーバIDを指定して、アクセス履歴管理部36に、そのWebサーバIDによって識別されるホームページに係るアクセス履歴の取得リクエストを送信する(ステップS704)。
アクセス履歴の取得リクエストを受信したアクセス履歴管理部36は、保持しているアクセス履歴の中から、指定されたWebサーバIDと一致するアクセス履歴を取得し、アクセス履歴の取得レスポンスにして、仮名通信アドレス提供部32に返信する(ステップS705)。アクセス履歴の取得レスポンスは、返信先である仮名通信アドレス提供部32において、その履歴に登録されているアクセス者としてのユーザIDとホームページへのアクセス時間(接続時間)とが特定可能な情報を含んでいればよい。例えば、図17に示す例では、WebサーバID”www.restaunrant.co.jp”が一致するアクセス履歴として、1番目のレコードの情報と4番目のレコードの情報が通知されればよい。なお、現在も接続中である場合は、現時点までの時刻でアクセス時間が特定されるようにしてもよい。
アクセス履歴の取得レスポンスを受信した仮名通信アドレス提供部32は、アクセス履歴の取得レスポンスにより取得したアクセス履歴の中から、Webサーバへのアクセス者であるユーザID毎に、指定したWebサーバIDが示すWebサーバへの総合的なアクセス時間を計算する。本例では、ユーザID”user0001”について、1番目のレコードの情報からアクセス時間17分(2008/07/23 19:49−2008/07/23 19:32)と、4番目のレコードの情報からアクセス時間15分(2008/07/24 19:47−2008/07/24 19:32)の合計であるアクセス時間32分が計算で求まる。
次いで、求めたこの総合的なアクセス時間(本例では、32分)と、仮名通信アドレス提供条件管理部34から取得したアクセス時間による利用可能回数(345)とを基に、提供する仮名通信アドレスで可能とする利用可能回数を決定する。本例では、WebサーバID”www.restaurant.co.jp”に関連づけられているアクセス時間による利用可能回数は15分であるため、32分を15分で除算した結果、仮名通信アドレスの利用可能回数を2(小数点以下切り捨て)として定義する。ここで、求めた利用可能回数が1未満の場合は、当該ユーザIDに対応する仮名通信アドレスの提供は行わないこととする(ステップS706)。すなわち、求めた利用可能回数が1以上のユーザIDを仮名通信アドレスの対象候補として決定する。
次に、仮名通信アドレス提供部32は、アクセス履歴が示すアクセス時間によって仮名通信アドレスの対象候補となったユーザIDを指定して、ユーザ嗜好情報の取得リクエストを送信する(ステップS707)。本例では、ユーザID”user0001”を指定したユーザ嗜好情報の取得リクエストを送信する。なお、仮名通信アドレスの対象候補となったユーザIDが複数存在する場合には、それら全てのユーザIDを指定してユーザ嗜好情報の取得リクエストを送信してもよいし、ユーザID別にユーザ嗜好情報の取得リクエストを複数送信してもよい。
ユーザ嗜好情報の取得リクエストを受信したユーザ嗜好情報管理部35は、通知されたユーザIDと関連づけられているサービスカテゴリ(352)を検索して、返信する(ステップS708)。
返信を受けた仮名通信アドレス提供部32は、仮名通信アドレス提供条件管理部34から取得した要求元通信サービス提供サーバに関連づけられているWebサーバのサービスカテゴリと、ユーザ嗜好情報管理部35から取得した対象候補として決定したユーザIDと関連づけられちるサービスカテゴリとを比較し、一致するカテゴリがあるか否かを確認する(ステップS709)。ここで一致するカテゴリがない場合は、そのユーザIDについての仮名通信アドレスの提供は行わない。
一致するカテゴリがある場合には、仮名通信アドレス提供部32は、カテゴリが一致したユーザIDと、要求元である通信サービス提供サーバのアドレスと、利用可能回数とを指定して、仮名通信アドレス管理部33に仮名通信アドレスの生成リクエストを送信する(ステップS710)。なお、提供の対象とされるユーザIDが複数存在する場合には、複数のユーザIDを指定した仮名通信アドレスの生成リクエストを送信してもよいし、ユーザID別に仮名通信アドレスの生成リクエストを複数送信してもよい。
仮名通信アドレスの生成リクエストを受信した仮名通信アドレス管理部33は、指定されたユーザIDの数分、指定されたユーザIDと通信サービス提供サーバアドレスの組み合わせに対して、仮名通信アドレスを生成して関連づける(ステップS711)。さらに、利用可能回数が指定されている場合には、指定された利用可能回数も併せて関連づける。そして、生成した仮名通信アドレスを仮名通信アドレス提供部32に返信する(ステップS712)。
返信を受けた仮名通信アドレス提供部32は、生成された仮名通信アドレスを含む仮名通信アドレスの取得レスポンスを、通信サービス提供サーバに返信する(ステップS713)。なお、通信サービス提供サーバに、生成した仮名通信アドレスを提供する際に、併せて利用可能回数を通知してもよい。また、本実施形態においても、第3の実施形態と同様に、仮名通信アドレスを利用可能なサービスカテゴリを指定してもよい。
なお、生成した仮名通信アドレスの利用可能回数は、提供先である通信サービス提供サーバがその仮名通信アドレスを利用した際のメールサーバ20からのユーザIDの取得リクエストを受信した仮名通信アドレス管理部33にて制御される。
すなわち、電子メールを受信したメールサーバ20の通信アドレス変換部22が、電子メールの宛先アドレスから仮名通信アドレスを取得して、HTTPプロキシサーバ30の仮名通信アドレス管理部33へ、取得した仮名通信アドレスを指定したユーザIDの取得リクエストを送信する。仮名通信アドレス管理部33は、自身で保持している、仮名通信アドレスとユーザIDと通信サービス提供サーバアドレスとを関連付けた情報を検索して、指定された仮名通信アドレスに対応するユーザIDを解決して、要求元の通信アドレス変換部22に、得られたユーザIDを含むユーザIDの取得レスポンスを返信する。その際、仮名通信アドレス管理部33は、指定された仮名通信ドレスに対応するユーザIDが存在するならば、自身が保持している関連付け情報におけるその仮名通信アドレスに設定されている利用可能回数(334)を1削減すればよい。ここで、利用可能回数が0になった場合には、当該仮名通信アドレスの利用を停止させる。なお、関連付け情報において当該仮名通信アドレスの情報を削除してもよい。なお、仮名通信アドレスから実通信アドレスの変換に係る他の処理は、第1の実施形態と同様でよい。
以上のように、本実施形態によれば、ホームページへのアクセス履歴から仮名通信アドレスの提供を制御することにより、過去のアクセスにさかのぼって仮名通信アドレスの提供先を決定することが可能になる。また、通信サービス提供サーバ42側からの仮名通信アドレスの取得リクエストを契機に、仮名通信アドレスを提供することが可能になるため、使用する側による任意のタイミングで仮名通信アドレスの利用が可能になる。
また、本実施形態では、ホームページの総合的なアクセス時間から仮名通信アドレスの利用可能回数を決定したが、ホームページのアクセス履歴による利用可能回数の決定はこれに限定されるものではない。例えば、ホームページのアクセス回数によって決定してもよい。このような場合には、仮名通信アドレス提供条件管理部34に、アクセス頻度による利用回数というデータ項目を追加して、一定時間内のアクセス回数によって提供する仮名通信アドレスの利用可能回数を決定すればよい。
さらに、ホームページのアクセス履歴から算出できる総合的なアクセス時間やアクセス頻度は、仮名通信アドレスの利用可能回数の算出に限定されるものではない。例えば、総合的なアクセス時間やアクセス頻度に応じて仮名通信アドレスの有効期限(利用可能期間)を設定してもよい。例えば、通信サービス提供サーバが音声のストリーミングにより情報提供を行う場合、当該通信サービス提供サーバに関連づけられたホームページにアクセスした時間だけ、そのホームページにアクセスしたユーザ端末へ音声のストリーミングによる広告を更新することができるといった用法も可能である。
実施形態5.
次に、本発明の第5の実施形態について説明する。本実施形態では、マッシュアップサーバに情報を提供するWebサーバを運営する事業主に対しても仮名通信アドレスによるユーザ端末とのコミュニケーション手段を提供する。
本実施形態において、マッシュアップサーバとは、複数のWebサーバの情報を収集・加工(マッシュアップ)することによって、ユーザ端末に情報サービスを提供するサーバである。また、Webサービスサーバは、マッシュアップサーバに情報を提供するWebサーバである。Webサービスサーバと第1〜第4の実施形態におけるWebサーバとの違いは、提供する情報がユーザ端末のブラウザにおいてHTMLで記述されるホームページのように、ユーザに対して視覚的な可読性がなくてもよい点である。
例えば、天気の情報を提供するWebサービスサーバであれば、晴れを1,曇りを2,雨を3,雷を4などのように天候状態を数値で提供してもよい。これは、ユーザ端末のブラウザにとって理解不可能な情報であっても、マッシュアップサーバにとって理解可能な情報であればよいからである。
図22は、第5の実施形態による仮名通信アドレス提供システムの構成例を示すブロック図である。図22に示す仮名通信アドレス提供システムは、ユーザ端末10と、メールサーバ20と、HTTPプロキシサーバ30と、通信サービス提供サーバ42と、マッシュアップサーバ51と、Webサービスサーバ52と、Webサーバ用HTTPプロキシサーバ70とを備えている。また、ユーザ端末10と、メールサーバ20と、HTTPプロキシサーバ30と、通信サービス提供サーバ42と、マッシュアップサーバ51と、Webサービスサーバ52と、Webサーバ用HTTPプロキシサーバ70とは、ネットワーク60を介して接続されている。
なお、ユーザ端末10と、メールサーバ20と、通信サービス提供サーバ42とは、第1〜第4の実施形態と同様である。
また、HTTPプロキシサーバ30は、HTTPプロトコル情報取得部31が、HTTPプロトコル情報取得変換部37に置き換わっている点を除いて、第1〜第4の実施形態のいずれかと同様でよい。なお、図22に示す例では、第4の実施形態のHTTPプロキシサーバ30に対して、HTTPプロトコル情報取得部31をHTTPプロトコル情報取得変換部37に置き換えた例を示している。
HTTPプロトコル情報取得変換部37は、第1〜第4の実施形態におけるHTTPプロトコル情報取得部31の機能に加えて、受信したHTTPプロトコルの通信データのユーザIDを、一時的なユーザID(以下、一時ユーザIDという。)に変換して該通信データを送信する。
マッシュアップサーバ51は、HTTPプロキシサーバ30経由でユーザ端末10からのホームページの取得要求を受信するとともに、後述するWebサービスサーバ52から、ホームページの作成に必要な情報を取得し、ホームページを作成して要求元のユーザ端末10に該ホームページの情報を返信する。
本実施形態では、マッシュアップサーバ51は、ショッピングモールのホームページを作成する場合を例に説明する。
Webサービスサーバ52は、マッシュアップサーバ51に情報を提供するWebサーバであって、本実施形態では、ショッピングモール内のレストランの情報をマッシュアップサーバ51に提供する。
Webサーバ用HTTPプロキシサーバ70は、マッシュアップサーバ51とWebサービスサーバ52との間に設置されるプロキシサーバであって、Webサーバ用HTTPプロトコル情報取得変換部71と、一時ユーザID管理部72とを含む。
Webサーバ用HTTPプロトコル情報取得変換部71は、第1〜第4の実施形態におけるHTTPプロキシサーバ30のHTTPプロトコル情報取得部31の機能に加えて、マッシュアップサーバ51から受信したHTTPプロトコルの通信データの一時ユーザIDを、新たな一時ユーザIDに変換する。
一時ユーザID管理部72は、HTTPプロキシサーバ30およびWebサーバ用HTTPプロキシサーバ70を経由して送受信されるHTTPプロトコルの通信データから、サービス事業主間におけるユーザの個人情報の悪い意味での名寄せが行えないようにするために、同一のユーザを指し示すユーザIDをHTTPプロトコル毎に変換する一時ユーザIDを保持する。
ここで、ユーザの個人情報の悪い意味での名寄せとは、異なるサービス事業主が保有している断片的な個人情報が集まり最終的に個人が特定されてしまう問題のことである。
図23は、一時ユーザID管理部72が保持するデータの例を示す説明図である。図23では、一時ユーザID管理部72が保持するデータの構成として、受付ユーザID(721)と、WebサーバID(722)と、一時ユーザID(723)の項目を有する例が示されている。
受付ユーザID(721)には、HTTPプロトコル情報取得変換部37またはWebサーバ用HTTPプロトコル情報取得変換部71で受信したHTTPプロトコルによる通信データのユーザID(一時ユーザIDである場合もある。)を格納する。
WebサーバID(722)には、一時ユーザIDが割り当てられた際のアクセス先となったWebサーバのWebサーバIDを格納する。また、一時ユーザID(723)には、割り当てられた一時ユーザIDを格納する。
例えば、図23に示す例では、ユーザIDが”user0001”のユーザまたはユーザ端末10から、WebサーバIDが”www.shoppingmall.co.jp”のWebサーバへのアクセスの際に、該ユーザID”user0001”を一時ユーザID”temp0001”に変換した旨が示されている。また、例えば、ユーザID(ここでは、一時ユーザID)が”temp0001”のユーザまたはユーザ端末10から、WebサーバIDが”www.restaurant.co.jp”のWebサーバへのアクセスの際に、該ユーザID”temp0001”を一時ユーザID”temp0002”に変換した旨が示されている。
また、図24は、本実施形態におけるアクセス履歴管理部36が保持するデータの例を示す説明図である。図24に示すように、本実施形態におけるアクセス履歴管理部36が保持するデータは、第4の実施形態と同様でよい。ただし、アクセス履歴管理部36は、HTTPプロトコルによる通信データが示すユーザIDが一時ユーザIDであった場合には、一時ユーザID管理部72に問い合わせを行うことにより、その一時ユーザIDを現実のユーザID(実ユーザID)に変換した上で、登録する。
このようにすることにより、仮名通信アドレスを提供する契機となるタイミングにおいて、WebサーバIDとユーザIDとを関連づける際に、WebサービスサーバのWebサーバIDと実ユーザIDとを関連づけることができるので、Webサービスサーバに関連するサービス事業者に対しても、該実ユーザIDが指し示すユーザまたはユーザ端末へのコミュニケーションを可能とする仮名通信アドレスを提供することができる。なお、他の点に関しては、第4の実施形態と同様である。
次に、本実施形態の動作について説明する。図25は、本実施形態の仮名通信アドレス提供システムの動作の一例を示すシーケンス図である。
図25に示すように、本実施形態では、ユーザ端末10のブラウザ11より、ホームページの情報を取得するためのHTTPリクエストがWebサーバ(ここでは、マッシュアップサーバ51)に向けて送信されると(ステップS801)、それを受信したHTTPプロキシサーバ30のHTTPプロトコル情報取得変換部37は、受信したHTTPリクエストから、ユーザID(ここでは、実ユーザID)と、WebサーバIDを取得するとともに、ホームページ接続を検出し(ステップS802)、ホームページ接続通知をアクセス履歴管理部36に出力する(ステップS803)。本例では、該HTTPリクエストからユーザID”user001”とWebサーバID”www.shoppingmall.co.jp”とを取得したものとして説明する。なお、ステップS801〜S803の動作は、第4の実施形態のステップS501〜S503と同様でよい。
ホームページ接続通知を受信したアクセス履歴管理部36は、通知されたユーザIDとWebサーバIDとを用い、さらに現在日時をホームページ接続時刻(361)として、履歴情報を作成し、記憶領域に格納する(ステップS804)。なお、この時点では、ホームページ接続時刻(362)は、空とする(図24の2番目のレコード参照。)。
次に、HTTPプロトコル情報取得変換部37は、取得したユーザIDとWebサーバIDを指定してWebサーバ用HTTPプロキシサーバ70の一時ユーザID管理部72に、一時ユーザIDの生成リクエストを送信する(ステップS805)。
一時ユーザIDの生成リクエストを受信した一時ユーザID管理部72は、指定されたユーザIDに対して一時ユーザIDを割り当て、指定されたユーザIDとWebサーバIDと生成した一時ユーザIDとを関連づけて格納する(ステップS806)。このとき、関連付けられる一時ユーザIDは、乱数を用いて生成してもよいし、事前に用意してある未使用の一時ユーザIDの中から選択してもよい。そして、生成した一時ユーザIDを含む一時ユーザIDの生成レスポンスを、要求元であるHTTPプロキシサーバ30のHTTPプロトコル情報取得変換部37に返信する(ステップS807)。ここでは、図23の2番目のレコードに示すように、WebサーバID”www.shoppingmall.co.jp”への受付ユーザID”user0001”に対して一時ユーザID”temp0001”を割り当てたとする。
一時ユーザIDの生成レスポンスを受信したHTTPプロトコル情報取得変換部37は、ユーザ端末10から受信したHTTPリクエストのユーザIDを、受信した一時ユーザIDに変換して、アクセス先であるマッシュアップサーバ51に送信する(ステップS808)。
HTTPリクエストを受信したマッシュアップサーバ51は、他のWebサーバから収集・加工するための情報を取得するために、さらに収集先であるWebサービスサーバ52に向けて、受信したHTTPリクエストのユーザID(ここでは、一時ユーザID”temp0001”)を格納したHTTPリクエストを送信する(ステップS809)。本実施形態では、ショッピングモールのマッシュアップサーバ51が、レストランの情報を取得するために、レストラン事業主のWebサービスサーバ52であるWebサービスIDが”www.restaurant.co.jp”のWebサーバへHTTPリクエストを送信したとする。
また、本実施形態では、マッシュアップサーバ51から送信されたHTTPプロトコルによる通信データは、Webサーバ用HTTPプロキシサーバ70を経由して宛て先であるWebサービスサーバ52に転送される。
マッシュアップサーバ51から送信されたHTTPリクエストを受信したWebサーバ用HTTPプロキシサーバ70では、Webサーバ用HTTPプロトコル情報取得変換部71が、受信したHTTPプロトコルから、ユーザID(ここでは、一時ユーザID”temp0001”)とWebサーバID(”www.restaurant.co.jp”)とを取得する。Webサーバ用HTTPプロトコル情報取得変換部71は、取得したユーザIDが一時ユーザIDである場合には、取得した一時ユーザIDを指定して一時ユーザID管理部72に、実ユーザIDの取得リクエストを送信する(ステップS810)。
実ユーザIDの取得リクエストを受信した一時ユーザID管理部72は、指定された一時ユーザIDから、該一時ユーザIDが割り当てられた実ユーザIDを求めて返信する(ステップS811:実ユーザIDの取得レスポンスの送信)。一時ユーザID管理部72は、指定された一時ユーザIDが、ユーザID(723)に登録されているレコードの受付ユーザID(721)を求める処理を、受付ユーザID(721)が実ユーザIDになるまで繰り返して実行すればよい。
実ユーザIDの取得レスポンスを受信したWebサーバ用HTTPプロトコル情報取得変換部71は、解決した実ユーザID(ここでは、ユーザID”user0001”)と取得したWebサーバID(”www.restaurant.co.jp”)とを指定して、ホームページ接続通知をアクセス履歴管理部36に送信する(ステップS812)。
ホームページ接続通知を受信したアクセス履歴管理部36は、ステップS804と同様に、通知されたユーザIDとWebサーバIDとを用い、さらに現在日時をホームページ接続時刻(361)として、履歴情報を作成し、記憶領域に格納する(ステップS813。図24の3番目のレコード参照。)。
次に、Webサーバ用HTTPプロトコル情報取得変換部71は、アクセス先であるWebサービスサーバに開示するユーザID用に、受信した一時ユーザIDに対してさらに一時ユーザIDの生成を一時ユーザID管理部72に依頼する。Webサーバ用HTTPプロトコル情報取得変換部71は、ステップS805におけるHTTPプロトコル情報取得変換部37と同様に、取得したユーザID(ここでは、一時ユーザID”temp0001”)とWebサーバID(ここでは、”www.restaurant.co.jp”)を指定して一時ユーザID管理部72に、一時ユーザIDの生成リクエストを送信する(ステップS814)。
一時ユーザIDの生成リクエストを受信した一時ユーザID管理部72は、指定されたユーザIDに対して一時ユーザIDを割り当て、指定されたユーザIDとWebサーバIDと生成した一時ユーザIDとを関連づけて格納する(ステップS815)。そして、生成した一時ユーザIDを含む一時ユーザIDの生成レスポンスを、要求元であるWebサーバ用HTTPプロトコル情報取得変換部71に返信する(ステップS816)。ここでは、図23の3番目のレコードに示すように、WebサーバID”www.restaurant.co.jp”への受付ユーザID”temp0001”に対して一時ユーザID”temp0002”を割り当てたとする。
新しい一時ユーザIDを含む一時ユーザIDの生成レスポンスを受信したWebサーバ用HTTPプロトコル情報取得変換部71は、マッシュアップサーバ51から受信したHTTPリクエストのユーザID(ここでは、一時ユーザID”temp0001”)を、受信した一時ユーザID(”temp0002”)に変換して、アクセス先であるWebサービスサーバ52に送信する(ステップS817)。
本実施形態の例では、説明を簡単にするために、Webサービスサーバがさらに別のWebサービスサーバを呼び出すことはないが、Webサービスサーバがさらに別のWebサービスサーバを呼び出すことを考慮して、受信した一時ユーザIDからさらに新しい一時ユーザIDを生成している。
HTTPリクエストを受信したWebサービスサーバ52は、座席の空席情報やおすすめメニューなどのレストラン情報を含む通信データ(HTTPプロトコルに載せた通信データであればよく、必ずしもホームページの形式でなくてもよい。)を、Webサーバ用HTTPプロキシサーバ70経由で要求元のマッシュアップサーバ51に返信する(ステップS818,S819)。
Webサービスサーバ52からHTTPプロトコルによる返信データを受信したマッシュアップサーバ51は、受信した情報からホームページを加工して(ステップS820)、HTTPプロキシサーバ30経由で、生成したホームページの情報を当初のアクセス元であるユーザ端末10にHTTPレスポンスとして返信する(ステップS821)。このHTTPレスポンスには、ユーザIDとして、HTTPプロキシサーバ30から受信したHTTPリクエストにおけるユーザIDである一時ユーザID”temp0001”が指定されるが、当該HTTPレスポンスを経由させるHTTPプロキシサーバ30によって、実ユーザIDの解決が行われることによりユーザ端末10に転送される。
このように、ユーザ端末10からマッシュアップサーバ51のホームページへのアクセス状況がアクセス履歴管理部36にアクセス履歴として格納された後は、第4の実施形態と同様に、通信サービス提供サーバからの仮名通信アドレスの取得リクエストの送信を契機に、仮名通信アドレスの提供を行えばよい。
以上のように、本実施形態によれば、マッシュアップサーバに情報を提供するWebサービスサーバを運営する事業主に対しても仮名通信アドレスによるユーザまたはユーザ端末とのコミュニケーションを可能とする仮名通信アドレスを提供することができる。
なお、本実施形態による一時ユーザIDの解決手順は、第4の実施形態における仮名通信アドレスの提供方法だけでなく、第1の実施形態における仮名通信アドレスの提供方法に対しても適用可能である。例えば、HTTPプロキシサーバ30の仮名通信アドレス提供部32と同様の機能を有するWebサーバ用仮名通信アドレス提供部を、Webサーバ用HTTPプロキシサーバ70が備えることによって、マッシュアップサーバ51からWebサービスサーバ52へのアクセス状況に応じて、Webサービスサーバ52に関連するサービス事業者(本例では、レストラン事業主)に、マッシュアップサーバ51にアクセスしたユーザまたはユーザ端末へのコミュニケーション手段となる仮名通信アドレスを提供することも可能である。
次に、本発明の概要について説明する。図26は、本発明の概要を示すブロック図である。図26に示すように、本発明による情報処理装置1は、HTTPプロトコル情報取得手段101と、通信アドレス記憶手段102と、通信アドレス提供手段103とを備えたことを特徴とする。
HTTPプロトコル情報取得手段101(例えば、HTTPプロトコル情報取得部31)は、ユーザ端末のHTTPプロトコルによる通信の状況を示す情報を取得する。HTTPプロトコル情報取得手段101は、例えば、ユーザ端末のHTTPプロトコルによる通信のデータを取得して、該データによって示される通信の状況を特定することによって、その旨を示す情報を取得してもよい。
通信アドレス記憶手段102(例えば、仮名通信アドレス管理部33)は、通信アドレス提供手段101が提供する通信アドレスを、該通信アドレスで特定されるユーザまたはユーザ端末を識別できる情報と関連づけて記憶する。通信アドレス記憶手段102は、例えば、通信アドレスと、該通信アドレスの割り当て対象となったユーザ端末またはユーザを識別するためのユーザ識別子と、さらに該通信アドレスの提供の動因となったアクセス先としてのWebサーバを識別するためのWebサーバ識別子とを関連づけて保持してもよい。
通信アドレス提供手段103(例えば、仮名通信アドレス提供部32)は、通信サービスを提供するサーバである通信サービス提供サーバに対して、前記通信サービスの提供先となるユーザまたはユーザ端末を特定できる通信アドレスを提供する。本発明においては、通信アドレス提供手段103は、ユーザ端末のHTTPプロトコルによる通信の状況に基づいて、該HTTPプロトコルによる通信相手であるWebサーバに関連づけられた通信サービス提供サーバに、当該ユーザ端末または当該ユーザ端末を使用しているユーザを特定できる通信アドレスを提供する。なお、ユーザまたはユーザ端末を特定できるとは、より具体的には、該ユーザまたは該ユーザ端末に情報を伝達する際に宛先として特定されることが可能であることを意味する。
また、通信アドレス提供手段103は、ユーザ端末が前記WebサーバへHTTPプロトコルによるアクセスを開始すると、通信アドレスを提供してもよい。また、ユーザ端末が前記WebサーバへHTTPプロトコルによるアクセスを終了すると、通信アドレスを提供してもよい。
また、図27は、本発明による情報処理装置1の他の構成例を示すブロック図である。図27に示すように、情報処理装置1は、さらに通信状況履歴記憶手段104を備えていてもよい。通信状況履歴記憶手段104(例えば、アクセス履歴管理部36)は、ユーザ端末のHTTPプロトコルによる通信の状況の履歴を記憶する。そのような場合に、通信アドレス提供手段103は、通信サービス提供サーバからの通信アドレスの要求を示す情報を受け取ると、通信状況履歴記憶手段104に記憶されている通信の状況の履歴に基づいて、通信アドレスを提供してもよい。
また、情報処理装置1は、さらに、通信アドレス提供条件記憶手段105を備えていてもよい。通信アドレス提供条件記憶手段105(例えば、仮名通信アドレス提供条件管理部34)は、例えば、少なくともアクセス先となったWebサーバに対応する通信サービス提供サーバの情報を含む通信アドレスの提供条件を記憶する。そのような場合に、通信アドレス提供手段103は、ユーザ端末から送信されたHTTPリクエストのうち、前記通信アドレス提供条件記憶手段に記憶されている情報に基づいて、通信アドレスの提供の動因とするHTTPリクエストを決定してもよい。
そのような構成によれば、通信アドレスの提供先とするサービス事業者と、通信アドレスの提出先としないサービス事業者を区別することを可能にする。
また、通信アドレス提供条件記憶手段105は、例えば、通信アドレスの提供条件として、提供する通信アドレスの利用可能回数または有効期限に関する情報を含む情報を記憶してもよい。そのような場合に、通信アドレス提供手段103は、前記通信アドレス提供条件記憶手段に記憶されている通信アドレスの提供条件に基づいて、提供する通信アドレスの利用可能回数または有効期限を決定してもよい。
また、通信アドレス提供手段103は、ユーザ端末のHTTPプロトコルによる通信の状況、通信アドレスの利用回数または提供してからの経過時間のいずれかに基づいて、通信アドレスを失効させるための制御を行ってもよい。
また、情報処理装置1は、さらに、ユーザ嗜好情報記憶手段106(例えば、ユーザ嗜好情報管理部35)を備えていてもよい。ユーザ嗜好情報記憶手段106は、例えば、通信アドレスの割り当て対象となりうるユーザまたはユーザ端末を使用するユーザの嗜好を示す情報を記憶する。そのような場合に、通信アドレス提供条件記憶手段105は、少なくとも通信アドレスの提供の動因となるアクセス先としてのWebサーバのサービスカテゴリを示す情報を含む通信アドレスの提供条件を記憶していてもよい。また、通信アドレス提供手段103は、ユーザ嗜好情報記憶手段106に記憶されているユーザの嗜好の情報と、通信アドレス提供条件記憶手段105に記憶されているWebサーバのサービスカテゴリの情報とに基づいて、通信アドレスの提供先とする通信サービス提供サーバ、もしくは通信アドレスの割り当て対象とするユーザまたはユーザ端末を決定してもよい。
そのような構成によれば、通信サービス提供サーバによる通信アドレスを用いた通信サービスにおいてユーザが興味を示すカテゴリの情報を提供することができる。
また、情報処理装置1は、さらに、一時ユーザID生成手段107(例えば、HTTPプロトコル情報取得変換部37,一時ユーザID管理部72)と、一時ユーザID記憶手段108(例えば、一時ユーザID管理部72)とを備えていてもよい。一時ユーザID生成手段107は、ユーザまたはユーザ端末を識別できる情報としてのユーザ識別子と関連づけて、前記Webサーバが利用する一時的なユーザ識別子である一時ユーザIDを生成する。また、一時ユーザID記憶手段108は、ユーザ識別子と前記生成した一時ユーザIDとを関連づけて記憶する。そのような場合に、通信状況履歴記憶手段104は、通信に用いられた前記一時ユーザIDが前記ユーザ識別子に変換された履歴を記憶してもよい。
そのような構成によれば、マッシュアップサーバに情報を提供するWebサービスサーバを運営する事業主に対しても、ユーザまたはユーザ端末とのコミュニケーションを可能とする通信アドレスを提供することができる。
また、通信アドレス提供手段103が提供する通信アドレスは、仮名の通信アドレスであってもよい。
また、図28は、本発明による通信アドレス提供システムの概要を示すブロック図である。図28に示すように、本発明による通信アドレス提供システムは、通信サービスを提供するサーバである通信サービス提供サーバに対して、前記通信サービスの提供先となるユーザまたはユーザ端末を特定できる通信アドレスを提供するための通信アドレス提供システムであって、HTTPプロトコル情報取得手段101と、通信アドレス記憶手段102と、通信アドレス提供手段103とを備えたことを特徴とする。HTTPプロトコル情報取得手段101と、通信アドレス記憶手段102と、通信アドレス提供手段103とは、図28に示すように、例えば、通信アドレスの割り当て対象となりうるユーザ端末またはユーザが使用するユーザ端末のHTTPプロトコルによる通信の状況を示す情報を取得可能な第1の通信装置1に実装されていてもよい。第1の通信装置は、例えば、HTTPプロキシサーバである。
また、図28に示すように、本発明による通信アドレス提供システムは、通信アドレス提供手段103が提供する通信アドレスを宛先とする通信データの配送制御を行う際に、通信アドレス記憶手段102へ問い合わせを行って、宛先となるユーザまたはユーザ端末を特定する通信アドレス変換手段201(例えば、通信アドレス変換部22)を備えていてもよい。通信アドレス変換手段201は、例えば、提供される通信アドレスを宛て先として用いた通信データの配信制御を行う第2の通信装置2に実装されていてもよい。なお、第2の通信装置2は、例えば、メールサーバである。
また、図29は、本発明による通信アドレス提供システムの他の構成例を示すブロック図である。図29に示すように、通信アドレス提供システムとして、一時ユーザID生成手段107および一時ユーザID記憶手段108は、ユーザ端末3とアクセス先となるWebサーバ4の間に設定される第1の通信装置1とは別の第3の通信装置3に実装されていてもよい。第3の通信装置3は、例えば、アクセス先となるWebサーバ4がマッシュアップサーバである場合には、そのマッシュアップサーバと該マッシュアップサーバに情報を提供するWebサービスサーバとの間に設定されるHTTPプロキシサーバである。
なお、図示省略しているが、通信アドレス記憶手段102や、通信アドレス提供手段103、通信状況履歴記憶手段104、通信アドレス提供条件記憶手段105、ユーザ嗜好情報記憶手段106が、それぞれHTTPプロトコル情報取得手段101を備えた第1の通信装置1とは異なる装置によって実現されていてもよい。なお、そのような場合には、第1の通信装置1と該装置とが通信可能に接続されていることを前提とする。
以上、実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
この出願は、2008年11月26日に出願された日本特許出願2008−301143を基礎とする優先権を主張し、その開示の全てをここに取り込む。