(57)【要約】【課題】簡便な方法である特定の会員サイト以外のユーザが会員でないコンテンツサイトのコンテンツの閲覧を行なうことができるコンテンツサービス提供システムを提供する。【解決手段】インターネット上において、第１会員サイトのサーバであるサーバＡに登録したクライアントが、会員でない第２会員サイトのサーバであるサーバＢのコンテンツを閲覧するシステムにおいて、ユーザはクライアント機１０を用いてサーバＡに所望のコンテンツの閲覧をリクエストする（処理Ａ１）。サーバＡは、クライアント機１０を介してアクセスしてきたユーザが自分のサイトの会員であることを保証する保証情報をサーバＢへ送信する（処理Ａ２）。サーバＢは、保証情報に基づいてクライアント機１０にコンテンツの閲覧を許可するためのキーを渡し（処理Ａ４）、クライアント機１０はキーを用いてコンテンツにアクセスする（処理Ａ５〜Ａ７）。【選択図】　　　　図２
2004086510.tif 000002
【特許請求の範囲】
【請求項１】
インターネット上において、第１会員サイトに登録したクライアントが会員でない第２会員サイトのコンテンツを閲覧するシステムであって、
前記クライアントは、前記第１会員サイトの第１サーバに所望のコンテンツの閲覧をリクエストする手段を含み、
前記第１サーバは、前記クライアントが自分のサイトの会員であることを保証する保証情報を前記第２会員サイトの第２サーバへ送信する手段を含み、
前記第２サーバは、前記保証情報に基づいて前記クライアントに前記コンテンツの閲覧を許可する手段を含む、インターネット上のコンテンツサービス提供システム。
【請求項２】
前記クライアントにコンテンツの閲覧を許可する手段は所定のキーを出力する手段と、前記クライアントから前記所定のキーを受けて前記コンテンツの閲覧を許可する手段とを含む、請求項１に記載のインターネット上のコンテンツサービス提供システム。
【請求項３】
前記保証情報は前記クライアントを特定する情報を含む、請求項１に記載のインターネット上のコンテンツサービス提供システム。
【請求項４】
前記クライアントを特定する情報は前記クライアントのＩＤを含む、請求項２に記載のインターネット上のコンテンツサービス提供システム。
【請求項５】
前記クライアントを特定する情報は前記クライアントのＩＰアドレスを含む、請求項２に記載のインターネット上のコンテンツサービス提供システム。
【請求項６】
さらに前記クライアントは前記第２サーバからログアウトする手段を含み、前記ログアウトは前記第２サーバで行う、請求項２に記載のインターネット上のコンテンツサービス提供システム。
【請求項７】
さらに前記クライアントは前記第２サーバからログアウトする手段を含み、前記第１サーバで行う、請求項２に記載のインターネット上のコンテンツサービス提供システム。
【請求項８】
インターネット上において、第１会員サイトに登録したクライアントが会員でない第２会員サイトにアクセスして第２会員サイトの所望のコンテンツを閲覧するシステムであって、
前記クライアントは、前記第１会員サイトの第１サーバに前記所望のコンテンツの表示をリクエストする手段と、所定のキーをつけて第２会員サイトの第２サーバに前記所望のコンテンツを要求する手段とを含み、
前記第１サーバは、認証引継ぎに必要な情報を第２サーバへ送信する手段と、前記第２サーバのコンテンツメニューを前記所定のキーを埋込んで表示する手段とを含み、
前記第２サーバは、前記所定のキーを前記第１サーバに送信する手段と、前記所定のキーを埋込んで前記所望のコンテンツを前記クライアントに表示する手段とを含む、インターネット上のコンテンツサービス提供システム。
【請求項９】
前記所定のキーには有効期限が設けられている、請求項５に記載のインターネット上のコンテンツサービス提供システム。
【請求項１０】
インターネット上において、会員サイトに登録したクライアントが会員でない非会員サイトのコンテンツを閲覧するシステムにおける会員サイトのサーバであって、
前記クライアントからの、前記非会員サイトのコンテンツに対する閲覧リクエストを受ける手段と、
前記非会員サイトのサーバに、前記クライアントが自分のサイトの会員であることを保証する保証情報を送信する手段と、
前記非会員サイトのサーバからの前記コンテンツの閲覧許可情報を前記クライエントに送信する手段とを含む、インターネット上のコンテンツサービス用サーバ。
【請求項１１】
インターネット上において、会員サイトに登録したクライアントが会員でない非会員サイトのコンテンツを閲覧するシステムにおける会員用クライアント機であって、
前記会員サイトのサーバに、前記非会員サイトのコンテンツに対する閲覧リクエストを送信する手段を含み、
前記会員サイトのサーバは、前記非会員サイトのサーバに、前記クライアントが自分のサイトの会員であることを保証する保証情報を送信し、
前記非会員サイトのサーバからの前記コンテンツの閲覧許可情報を前記会員サイトのサーバから受信する手段とを含む、インターネット上のコンテンツサービスを受ける会員用クライアント。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明はインターネット上でユーザの所望のコンテンツを提供するコンテンツサービス提供システム、コンテンツサービス用サーバおよび会員用クライアントに関し、特にユーザが会員登録をしていない会員サーバからのコンテンツをセキュリティを確保しながら閲覧できるコンテンツサービス提供システム、コンテンツサービス用サーバおよび会員用クライアントに関する。
【０００２】
【従来の技術】
この発明に興味のあるネットワーク接続システムがたとえば特開平１０−２１５２８４号公報に開示されている。
【０００３】
同公報によれば、ネットワークへの接続回線設備を備えた複数のサーバを用意し、サーバは、ユーザに関する会員情報を有する認証側サーバと認証側サーバと所定の関係を有する接続側サーバとからなり、接続側サーバはユーザから送信されるユーザＩＤおよびパスワードを用いて認証側サーバにユーザ認証を求め、ネットワークへの接続を認証の結果に応じてユーザに提供するシステムを開示している。その結果、異なる複数のプロバイダのサーバ間で会員情報および回線接続設備を相互利用できる。
【０００４】
【発明が解決しようとする課題】
従来のコンテンツサービス提供システムは上記のように構成されていた。
【０００５】
会員の認証に必要な情報のやり取りをサーバ間で行なうことによって高いセキュリティを確保していたが、それを具体化する上では、認証側サーバとその認証側サーバと所定の関係を有する接続側サーバとの間で複雑な認証手続が必要となり、実装が困難であった。また、利用者に不便な面があった。
【０００６】
この発明は上記のような問題点を解消するためになされたもので、簡便な方法である特定の会員サイト以外のユーザが会員でないコンテンツサイトのコンテンツの閲覧を行なうことができるコンテンツ提供システム、コンテンツサービス用サーバ会員用および会員用クライアントを提供することを目的とする。
【０００７】
【課題を解決するための手段】
この発明にかかる、インターネット上において、第１会員サイトに登録したクライアントが会員でない第２会員サイトのコンテンツを閲覧するシステムにおいては、クライアントは、第１会員サイトの第１サーバに所望のコンテンツの閲覧をリクエストする手段を含み、第１サーバは、クライアントが自分のサイトの会員であることを保証する保証情報を第２会員サイトの第２サーバへ送信する手段を含む。第２サーバは、保証情報に基づいてクライアントにコンテンツの閲覧を許可する。
【０００８】
この発明においては、クライアントは第１会員サイトに登録されているため、第１会員サイトの第１サーバでは認証が完了している。第１サーバがクライアントを保証する情報を用いてその旨を第２サーバに伝えることで、依頼された側の第２会員サイトの第２サーバはクライアントの認証を省略して利用を許可させる。したがって、クライアントは自分が会員でない第２会員サイトへの登録等の手続きをすることなく、第２会員サイトのコンテンツにアクセスできる。
【０００９】
その結果、簡便な方法である特定の会員サイト以外のユーザが会員でないコンテンツサイトのコンテンツの閲覧を行なうことができるコンテンツ提供システムが提供できる。
【００１０】
また、このシステムでは、ユーザであるクライアントは第１会員サイトの第１サーバに所望のコンテンツの閲覧をリクエストする情報を入力するだけで、それ以外の個人情報等の情報の入力は不要である。
【００１１】
すなわち、この発明においては、ウェブで通常行なわれているコンテンツリクエストの仕組を利用するだけで非会員の閲覧要求にこたえるコンテンツ提供システムを提供することができる。このリクエストの仕組は会員制のウェブサイトを構築するにあたっては必須の技術要素であるため、会員制のウェブサイトができている時点で、技術的な問題は解決している。したがって、更新するデータの取決めを行なうだけで実装が可能である。
【００１２】
好ましくは、クライアントにコンテンツの閲覧を許可する手段は所定のキーを出力する手段と、クライアントから所定のキーを受けてコンテンツの閲覧を許可する手段とを含む。第２サーバは所定のキーを発行し、そのキーをクライアントが送信してきたときのみ自己の所有するコンテンツをクライアントに閲覧させる。所定のキーを用いて本人確認ができるため、簡単な構成で特定の会員サイト以外のユーザが会員でないコンテンツサイトのコンテンツの閲覧を行なうことができるコンテンツ提供システムが提供できる。
【００１３】
好ましくは、保証情報はクライアントを特定する情報を含む。クライアントを特定する情報はクライアントのＩＤであってもよいし、クライアントのＩＰアドレスであってもよい。
【００１４】
クライアントのＩＤやＩＰアドレスを用いて本人確認ができるため、安全性の高いシステムを提供できる。
【００１５】
なお、クライアント第２サーバからののログアウトは第１サーバで行ってもよいし、第２サーバで行ってもよい。
【００１６】
この発明の他の局面においては、インターネット上において、第１会員サイトに登録したクライアントが会員でない第２会員サイトにアクセスして第２会員サイトのコンテンツを閲覧するシステムにおいては、クライアントは、第１会員サイトの第１サーバに所望のコンテンツの表示をリクエストする手段と、所定のキーをつけて第２会員サイトの第２サーバに前記コンテンツを要求する手段とを含み、第１サーバは、認証引継ぎに必要な情報を第２サーバへ送信する手段と、第２サーバのコンテンツメニューを所定のキーを埋込んで表示する手段とを含む。第２サーバは、所定のキーを第１サーバに送信する手段と、所定のキーを受けて所望のコンテンツを表示する手段とを含む。
【００１７】
クライアントが自分が会員である第１会員サイトに所望のコンテンツの表示をリクエストすると、第１会員サイトは認証引継ぎに必要な情報を第２会員サイトの第２サーバへ送信する。第２サーバは所定のキーを発行し、コンテンツメニューを所定のキーを埋込んで表示する。これに対して、クライアントは所定のキーをつけて第２サーバにコンテンツを要求する。これに応じて第２サーバは所定のキーを受けてクッキーに埋込んでコンテンツを表示する。
【００１８】
クライアントが会員でない第２会員サイトが発行するキーを自分が会員である第１会員サイトを経由して受け取り、そのキーを用いて第２サーバはクライアントの特定を行うため、クライアントは大切な情報をネット上に入力することなく、必要な情報はサーバ間でやり取りしつつ、本人の確認ができる。
【００１９】
その結果、セキュリティの面で安全でかつ簡便に、ある特定の会員サイト以外のユーザが会員でないコンテンツサイトのコンテンツの閲覧を行なうことができるコンテンツ提供システムが提供できる。
【００２０】
なお、所定のキーには有効期限が設けることが好ましい。そうすれば、より安全性が高まる。
【００２１】
さらに、発行した所定のキーとクライアントのＩＰアドレスを結びつければハッキングの可能性も低減され、事実上成りすまし不可能となる。
【００２２】
この発明のさらに他の局面は、インターネット上において、第１会員サイトに登録したクライアントが会員でない第２会員サイトのコンテンツを閲覧するシステムのクライアントに関する。クライアントは、第１会員サイトの第１サーバに所望のコンテンツの閲覧をリクエストする手段を含み、第１サーバは、クライアントが自分のサイトの会員であることを保証する保証情報を第２会員サイトの第２サーバへ送信する手段を含み、第２サーバは、保証情報に基づいてクライアントにコンテンツの閲覧を許可する。
【００２３】
この発明のさらに他の局面は、インターネット上において、会員サイトに登録したクライアントが会員でない非会員サイトのコンテンツを閲覧するシステムにおける会員サイトのサーバに関する。サーバは、クライアントからの、非会員サイトのコンテンツに対する閲覧リクエストを受ける手段と、非会員サイトのサーバに、クライアントが自分のサイトの会員であることを保証する保証情報を送信する手段と、非会員サイトのサーバからのコンテンツの閲覧許可情報を前記クライエントに送信する手段とを含む。
【００２４】
この発明のさらに他の局面においては、インターネット上において、会員サイトに登録したクライアントが会員でない非会員サイトのコンテンツを閲覧するシステムにおける会員用クライアント機は、会員サイトのサーバに、非会員サイトのコンテンツに対する閲覧リクエストを送信する手段を含み、会員サイトのサーバは、非会員サイトのサーバに、クライアントが自分のサイトの会員であることを保証する保証情報を送信し、非会員サイトのサーバからのコンテンツの閲覧許可情報を会員サイトのサーバから受信する手段とを含む。
【００２５】
【発明の実施の形態】
以下この発明の実施の形態を図面を参照して説明する。
【００２６】
図１はこの発明に係るシステム全体の構成を示す模式図である。図１を参照して、この発明に係るコンテンツ提供システムはインターネット４０に接続されたクライアント機１０と、それぞれが所定のコンテンツを含むサーバＡとサーバＢ（以下、「コンテンツサイト」という場合がある）とを含む。
【００２７】
クライアント機１０のユーザはサーバＡ（第１会員サイトの第１サーバ）の会員であり、サーバＡに対して必要な登録を行ない、たとえば所定のＩＤとパスワードを有しているものとする。
【００２８】
図２は図１に示したシステムにおいてクライアント機１０を用いてユーザが自分が会員でないサーバＢ（第２会員サイトの第２サーバ）から所望のコンテンツを読出す場合の手続を模式化したブロック図である。図２において、上欄はクライアント機１０のディスプレイ上の表示状態を示す図であり、下欄はサーバＡとサーバＢとの処理手順を示す模式図である。図３はサーバＡにおける認証引継ぎ処理手順を示すフローチャートである。
【００２９】
まず、認証引継ぎ処理について説明する。図２および図３を参照して、ユーザはクライアント機１０を操作して自分が会員登録をしている会員サイトであるサーバＡにアクセスする（図２処理Ａ１）。具体的には、ユーザはクライアント１０に表示された会員サイトのコンテンツ１１の中の自分が会員でないサーバＢ内のコンテンツの閲覧を希望する旨の表示をクリックする。
【００３０】
その信号はサーバＡの認証引継ぎ処理部２１に送信される。サーバＡにおいては、ユーザの会員情報を会員管理データベース（以下会員管理ＤＢと略す）２２で確認を行なう（図３ステップＳ１１、以下ステップを略す）。
【００３１】
サーバＡは、ユーザが会員であることを確認すると、次にユーザが希望したコンテンツサイトであるサーバＢに対して認証引継ぎを行なう（処理Ａ２）。ここで認証引継ぎにおいては、ユーザの各種情報をサーバＢの認証応答処理部３１に送信する。
【００３２】
Ａ２〜Ａ３の処理が図３のステップＳ１２およびＳ１３に対応し、コンテンツサイトのサーバであるサーバＢはキー付きｈｔｍｌ文書を出力する（Ｓ１４）。
【００３３】
図４はコンテンツサイトにおける処理手順を示すフローチャートである。図４を参照して、サーバＢは会員サイト（サーバＡ）から情報を受信したときは、ＩＰアドレスが許可されたものか否か（Ｓ２２）および情報がそろっているか（Ｓ２３）を判断し、共に満たしている場合にのみその情報がセッション管理ＤＢ３３に登録され、上記キー付きｈｔｍｌ文書を出力する。Ｓ２２で許可されたＩＰアドレスで無いときや、情報がそろっていないときは、エラー処理が行なわれる（Ｓ２６、Ｓ２７）。
【００３４】
次に認証応答処理について図２を参照して説明する。コンテンツサイトのサーバであるサーバＢが発行した有効期限付きのキー（処理Ａ３）を用いてコンテンツメニュー１２にキーを埋込んで表示する（処理Ａ４）。
【００３５】
ユーザは表示されたコンテンツメニュー１２をクリックして所望のコンテンツをサーバＢに要求する（Ａ５）。このときユーザはキーをサブミットしてコンテンツをリクエストしていることになるが、ユーザはこれについては認識していない。
【００３６】
次にコンテンツサイトにおける認証確認処理について説明する。図５を参照して、まずクッキーまたはキーがあるか否かを判断する（Ｓ３１）。クッキーまたはキーがあれば、次に情報が揃っているか否かを判断し（Ｓ３２）、次に更新系か否かを判断する（Ｓ３３）。全てを満たしているときはセッション管理ＤＢ３３からセッション情報を取得し（Ｓ３４）、ＩＰアドレスが合っているか否かを判断し（Ｓ３５）、合っていれば処理を続行する。ここで、ＩＰアドレスが合っていない場合とは有効期限が切れている場合やデータが取得できなかった場合を含む。Ｓ３１やＳ３５でＮＯのときは、エラー処理を行なう（Ｓ３６、Ｓ３７）。
【００３７】
ここでセッション情報の取得について説明する。セッション管理は、ａＣＧＩと、ｂＣＧＩを表示したい人が同一人物であることを特定するための仕組である。しかし、それだけでは誰なのかわからないため、ａＣＧＩを見た、たとえば、１１１１番の人を特定する情報をサーバＢ内に持つ必要がある。この情報を含めて、会員サイトから送られてきた情報を記述しているのがセッション情報である。
【００３８】
一般に、通常会員を獲得する場合は、住所、氏名などの個人情報を入力させるが、サイト間で連携する場合は個人情報のやり取りは行なわないようにするのが好ましい。そのため、ここではセッション情報を最小限としている。
【００３９】
すなわち、この実施の形態に示すように、２つの会員サイトで行なっているセッション管理の橋渡しを行なう仕組であれば、セッション管理では必ずしも個人情報は不要である。精々どのサイトのどのユーザＩＤの人かがわかれば、両サイトが決済を伴うサイトであったとしても、その取引の実態は双方とも把握できるからである。
【００４０】
また、会員サイト側が公開されているものとは別の体系でＩＤを発行していれば、会員サイト側は、どの会員が何を買ったかはわかるが、その会員のカード番号はわからない。また、カード会社はある特定のカード番号の人がどこのサイトで何を買ったかはわかるが、その他のサイトに訪問してもどの人かを特定することはできない。つまり、個人情報を伴わずに、高い匿名性を伴いつつも、確実に個人を特定した処理が可能となる。
【００４１】
もちろん、個人情報を伴ってはいけないということではない。どのような情報をやり取りするかはそれぞれのサイトが自分で決めることができる。このようにすれば、セッション情報を少なくすることができる。
【００４２】
図５に戻って、Ｓ３２で情報がそろっていないときは（Ｓ３２でＮＯ）、Ｓ３４でセッション情報を取得する。情報が揃っていない場合にはクッキーに保存されない情報が必要な場合を含む。
【００４３】
Ｓ３３で更新系で無いときは認証確認処理を終了する。
以上の様にセッション情報の参照を最小限にすることにより、サーバに対する負担の軽減とレスポンスの向上を図ることができる。
【００４４】
なお、ここで、キーをサブミットしてコンテンツをリクエストするにあたっては、明示的にクリックによって移動させても良いし、自動的に行なわれるようにしても良い。ハッキングの危険性を考えれば、自動的に移動することが望ましく、サイトを移動することを伝える必要がある場合は、これよりも前の頁で告知するのが好ましい。
【００４５】
図２を参照して、サーバＢの認証確認処理部３２は、キーをサブミットしてコンテンツのリクエストがあったときは、クッキーにキーを添付してコンテンツをクライアントの表示装置にコンテンツページ１３として表示する（処理Ａ６）。その後コンテンツページ１３内のユーザによる閲覧はクッキーとキーを用いて行なう（処理Ａ７）。
【００４６】
以上のように、この実施の形態においては、認証に必要な情報のやり取りをサーバＡとサーバＢの間で行なうことにより、高いセキュリティを確保することができる。また、サーバ間のやり取りそのものはｈｔｔｐｓプロトコルを利用することにより、サーバ機能によるアクセス制限、プロトコルによる暗号化、ＣＧＩ開発だけの手軽さ、サーバが遠隔地にあってもファイアウォールを経由しても実現可能という、信頼性と生産性と汎用性とをすべて備えたシステムの構築が可能になる。
【００４７】
従来のように、専用のプロトコルで通信を行なう場合は、専門家による開発が必要になるし、専用のツールを用いる場合はそのツールが動作するＯＳでサーバを組む必要がある。しかしながら、この実施の形態によれば、基本的にはやり取りするデータに関する取り決めだけで非会員サイトの閲覧システムを実装することができる。
【００４８】
利用するＣＧＩはそもそも、ウェブサーバ上で動作するユーザが開発するプログラムのことであり、特定の言語を規定したものではない。ＡＳＰ、Ｊａｖａ（Ｒ）、ＪＳＰ、Ｐｅｒｌ、Ｃ、ｐｈｐなど、これらはすべてＣＧＩの一種であり、他の言語で作られたプログラムであっても、サーバ上で動作してｈｔｍｌデータを標準出力に出力できればＣＧＩとなる。この実施の形態では、ＣＧＩのみで実装できるため、専門家も必要なければ、プラットフォームに依存することもない。
【００４９】
なお、サーバ間の通信はＣＧＩでも可能というだけで、専用のプロトコルを用いてもよいのは言うまでもない。
【００５０】
また、ここで用いるｈｔｔｐｓプロトコルは、特にＶｅｒｉｓｉｇｎなどの外部認証機関にＩＤを発行してもらう必要がなく、テストＩＤなど自分で作成したものでよい。これは内容の証明が目的ではなく、暗号化目的だからである。
【００５１】
また、コンテンツサイトが発行するキーには有効期限を設けるのが好ましい。また、クッキーはセッション内だけで有効となるようにするのが好ましい。
【００５２】
また、上記実施の形態においては、会員サイト側にコンテンツメニューを用意するように記載したが、これに限らず、コンテンツサイト側でキーを埋込んだメニューを生成し、表示させてもよい。また、コンテンツメニューではなく、リダイレクトによることにより、キーの有効期限を数分にまで短縮するようなセキュリティの強化も可能である。ただし、リダイレクトを行なった場合はＧＥＴメソッドとなるため、キーがＵＲＬに含まれてしまう。したがって、新たなキーをコンテンツサイト内で発行し、そのキーでセッション管理を行なう必要がある。
【００５３】
ここで、リダイレクトについて説明する。キー発行後にユーザにクリックさせる場合、発行されてからクリックされるまでの間は脆弱な状態が生じる。実際には併せてＩＰアドレスの評価なども行なえるため、ある程度のセキュリティは確保できる。
【００５４】
サーバＢによるキー発行からクライアントによるキーのサブミットまでを迅速に行なうためには、自動的に行なった方がよく、そのうちの１つの方法がリダイレクトという手法である。但し、リダイレクトの場合はＧＥＴメソッドになり、キーがウェブのログに残るため、そのキーを流用してセッション管理を行なった場合、成りすましが発生する可能性もある。これを避けるため、会員を受入れた後は、独自のキーでセッション管理を行なう。
【００５５】
図６はサーバ間通信で用いられるＣＧＩの例を示す図である。（Ａ）はＡｐａｃｈｅを用いた例である。サーバ間通信には、上記したように、ｈｔｔｐｓプロトコルを用い、コンテンツサイト側に設けられた認証ＣＧＩを呼出すことで行なう。コンテンツサイト側に用意した認証ＣＧＩは、ＷＥＢサーバの設定により特定のアドレス以外からのアクセスを禁止しておくことによってセキュリティを高めることができる。
【００５６】
会員サイト（サーバＡ）側は、コンテンツサイト側が求める情報をＰＯＳＴメソッドで送り、承認を示すキー（またはキーが埋められたページそのもの）を受取る。また、Ｐｅｒｌを使用したＣＧＩでは、ｌｉｂｗｗｗ−ｐｅｒｌ（ＣＰＡＮライブラリ）を用いることでｈｔｔｐサーバへアクセスすることができるため、仕組みの実装が比較的容易である。
【００５７】
図７は認証に当たり、会員サイトのサーバであるサーバＡからコンテンツサイトへ送信される情報の一例を示す図である。図７に示すように、ｇｒｏｕｐ（グループ名）、ｕｉｄ（ユーザＩＤ）、ｎａｍｅ（名前）、ｒｅｔｕｒｎ（コンテンツ利用終了時に戻る先のＵＲＬ）、ｔａｒｇｅｔ（コンテンツをフレーム内で動作させていた場合に戻るフレーム先）およびＲＥＭＯＴＥ＿ＡＤＤＲ（クライアントのＩＰアドレス）等を含めるのが好ましい。これにより、コンテンツサイト側では、訪問者が何者であるかの認識はしないものの、訪問者がどのサイトの正規の会員であるかを判断することができる。
【００５８】
また、併せて終了時に会員サイトのどこに戻れればいいのかも通知しておくのが好ましい。
【００５９】
図８はクッキー（Ｃｏｏｋｉｅ）の書式を示す図である。図８を参照して、Ｃｏｏｋｉｅ名は任意に指定が可能である。保存するデータは、「キー：値」の組合せをカンマ区切りで指定する。キー名は、半角英数小文字と一部の記号（＿）だけで構成する。また、先頭文字は英字とする。値に含まれる記号類（スペースを含む）や全角文字は、すべてパーセント表記による１６進数にエンコードする。値に含まれる日本語はＥＵＣを基本とする（必須ではない、シフトＪＩＳである必要があれば対応は可能である）。セッション内でのみ有効とするため、「ｅｘｐｉｒｅｓ」は指定しない。
【００６０】
なお、ログアウト時には、図８（Ｂ）に示すＣｏｏｋｉｅを送信することにより、Ｃｏｏｋｉｅを無効とする。
【００６１】
図９はユーザが非会員サイトからログアウトする場合の手順を示す模式図である。図９を参照して、ここではケース１とケース２の２つの場合について説明する。
【００６２】
（１）　ケース１
ケース１は、コンテンツサイト側ではログアウト処理を行なわない例である。
【００６３】
まず、会員サイト（サーバＡ）からのログアウトのリクエストを行なう（処理Ｂ１）。次いで認証引継ぎに必要な各種情報をコンテンツサーバ（サーバＢ）に送信する（具体的には削除要求を行なう）（処理Ｂ２）。それに応じてクライアント機１０の表示画面に表示された会員サイトのコンテンツ１１上でログアウトの画面表示を行なう（処理Ｂ３）。
【００６４】
（２）　ケース２
ケース２はコンテンツサイト上で明示的にログアウトを行なう例である。
【００６５】
まずユーザのクライアント機１０におけるコンテンツページ１２において会員サイト（サーバＡ）に戻るためのリクエストを要求する部分をクリックする（処理Ｃ１）。このリクエストはコンテンツサイトへ送られ、コンテンツサイトは、削除用Ｃｏｏｋｉｅを発行し、会員サイトへリダイレクトを要求する（処理Ｃ２）。会員サーバへリダイレクトによるリクエストを発行し（処理Ｃ３）、会員サイトのコンテンツ１３がクライアント１０の表示部に表示される（処理Ｃ４）。
【００６６】
基本的には、キーはセッション内Ｃｏｏｋｉｅに埋込んでやり取りされるため、明示的なログアウト処理を挟まなくても、ブラウザが閉じられれば無効となる。しかしながら、サーバ上にはキーに対応した認証データが有効期限に達するまで保存されるため、１台のＰＣを複数の人間がブラウザを閉じずに使う場合などを想定し、明示的なログアウト画面を用意することが望まれる。その際、会員サイトのログアウト時にコンテンツサイトもログアウトする方法と、コンテンツサイト側だけをログアウトする方法が考えられる。しかしながら、基本的には前者を採用するのが好ましい。
【００６７】
なお、前者を選択した場合、サーバ間のデータのやり取りは、ログイン時と同一の手法で行なう。
【００６８】
また、ウェブで通常行なわれているリクエストを用いてサーバ間通信を行なえば、サーバ間はＳＳＬを用いた通信も可能である。
【００６９】
上記実施の形態においては、クライアントが会員でないコンテンツサーバからのコンテンツの閲覧する場合について説明したが、これに限らず、会員というものは何らかのセッション管理によって会員であることを補償する点に注目し、セッション管理を行なうあらゆる仕組に適用できる。
【００７０】
たとえば、会員サイトにコンテンツを販売するサイトがあれば、会員サイトからの訪問者にだけ利用可能なセッションを作ることができる。決済システムでは、会員サイトから決済情報を持ってきた人を自サイトで認証し、決済を行なうことができる。この場合、決済が行なわれたことを会員サイトに伝える必要があるが、その部分にも本件の仕組を利用すれば、決済後に元の会員サイトに返すことも可能である。また、会員サイトから受入れる側は、会員サイト毎に仕組を用意する必要はなく、１つの仕組で複数のサイトの会員を受入れることができるし、必ずしも訪問者がどこかの誰かを特定することはなく、利用させることが可能になる。
【００７１】
さらに、発行した所定のキーとクライアントのＩＰアドレスを結びつければハッキングの可能性も低減され、事実上成りすまし不可能となる。
【００７２】
今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【図面の簡単な説明】
【図１】インターネット上の認証システムの全体の概略構成を示すブロック図である。
【図２】複数サイト間での認証引継ぎ手順を示す模式図である。
【図３】認証引継ぎ処理の処理手順を示すフローチャートである。
【図４】認証応答処理の処理手順を示すフローチャートである。
【図５】認証確認処理の処理手順を示すフローチャートである。
【図６】コンテンツサイトに用意した認証ＣＧＩの一例を示す図である。
【図７】認証において必要な情報例を示す図である。
【図８】クッキーの書式を示す図である。
【図９】ログアウト手順を示す模式図である。
【符号の説明】
１０　クライアント機、１１　会員サイトのコンテンツ、１２　コンテンツメニュー、１３　コンテンツページ、２０　サーバＡ、２１　認証引継ぎ処理部、２２　会員管理データベース、３０　サーバＢ、３１　認証応答処理部、３２　認証確認処理部、３３　セッション管理データベース。
【図１】
2004086510.tif 000003
【図２】
2004086510.tif 000004
【図３】
2004086510.tif 000005
【図４】
2004086510.tif 000006
【図５】
2004086510.tif 000007
【図６】
2004086510.tif 000008
【図７】
2004086510.tif 000009
【図８】
2004086510.tif 000010
【図９】
2004086510.tif 000011