(57)【要約】【課題】ユーザが個々のサービスサイトに個人情報を渡さなくてもサービスを受けられるようにする。【解決手段】窓口サイト２０は、ユーザ端末１０からのアクセスに対しユーザ認証を行い、これが成功したユーザ端末１０からサービスサイト３０へのサービス利用要求を受け取った場合に、窓口サイト２０のアカウントを用いてサービスサイト３０にアクセスし、このアクセスに対してサービスサイト３０から受け取ったアクセスチケットをユーザ端末１０に送り、ユーザ端末１０に送ったアクセスチケットを送り先のユーザと対応づけて記録する。サービスサイト３０は、窓口サイト２０からのアクセスに対してアクセスチケットを生成してその窓口サイト２０に発行し、アクセスチケットを発行先の窓口サイト２０と対応づけて記録し、ユーザから受けたアクセス要求がアクセスチケットを伴う場合に、そのユーザからのアクセスを許可する。【選択図】図２
2007233690.tif 000002
【特許請求の範囲】
【請求項１】
窓口側の装置と、サービス提供側の装置とを含むサービス提供システムであって、
窓口側の装置は、
ユーザの端末からのアクセスに対しユーザ認証を行うユーザ認証部と、
ユーザ認証の成功したユーザの端末からサービス提供側の装置の提供するサービスの利用要求を受け取った場合に、サービス提供側の装置に対する窓口側の装置のアカウントを用いてサービス提供側の装置にアクセスし、このアクセスに対してサービス提供側の装置から受け取ったアクセスチケットをユーザの端末に送る要求代行部と、
ユーザの端末に送ったアクセスチケットの情報を送り先のユーザと対応づけて記録する第１記録部と、
を備え、
サービス提供側の装置は、
窓口側の装置からのアクセスに対してアクセスチケットを生成してその窓口側の装置に発行するチケット発行部と、
発行したアクセスチケットの情報を発行先の窓口側の装置と対応づけて記録する第２記録部と、
ユーザから受けたアクセス要求がアクセスチケットを伴う場合に、そのユーザからのアクセスを許可するアクセス制御部と、
を備える、サービス提供システム。
【請求項２】
請求項１記載のサービス提供システムであって、
サービス提供側の装置は、
ユーザからのアクセスチケットを伴うアクセス要求に応じてそのユーザに提供したサービスの料金を、そのアクセスチケットに対応づけて第２記録部に登録された窓口側の装置に対して課金する第１課金処理部、
を更に備える、サービス提供システム。
【請求項３】
請求項２記載のサービス提供システムであって、
窓口側の装置は、
アクセスチケットに対応した課金をサービス提供側の装置から受けた場合に、その課金に応じた額をそのアクセスチケットに対応づけて第１記録部に登録されたユーザに課金する第２課金処理部、
を更に備える、サービス提供システム。
【請求項４】
請求項３記載のサービス提供システムであって、
サービス提供側の装置は、
アクセスを許可したユーザが要求したサービスが課金を伴うものである場合に、課金要求を窓口側の装置に対して送る課金要求部と、
課金要求に対して窓口側の装置からユーザの課金確認を受け取った場合に、そのサービスをそのユーザに提供するサービス制御部と、
を備え、
窓口側の装置は、
サービス提供側の装置から課金要求を受けた場合に、ユーザの端末に対して課金の確認要求を行う確認要求部と、
課金の確認要求に対してユーザの端末から課金確認を受けた場合に、その課金確認をサービス提供側の装置に送る転送部と、
を備える、サービス提供システム。
【請求項５】
請求項３記載のサービス提供システムであって、
サービス提供側の装置のサービス制御部は、ユーザに対して提供するサービスのためのコンテンツを窓口側の装置に対して送信し、
窓口側の装置は、サービス提供側の装置から受け取ったコンテンツをユーザに対して提供するコンテンツ転送部を更に備える、
ことを特徴とするサービス提供システム。
【請求項６】
請求項３記載のサービス提供システムであって、
窓口側の装置の第２課金処理部は、サービス提供側の装置からの課金から所定の補助額を減額した額をユーザに課金する、
ことを特徴とするサービス提供システム。
【請求項７】
コンピュータを、
ユーザの端末からのアクセスに対しユーザ認証を行うユーザ認証部、
ユーザ認証の成功したユーザの端末からサービス提供側の装置の提供するサービスの利用要求を受け取った場合に、サービス提供側の装置に対する窓口側の装置のアカウントを用いてサービス提供側の装置にアクセスし、このアクセスに対してサービス提供側の装置から受け取ったアクセスチケットをユーザの端末に送る要求代行部、
ユーザの端末に送ったアクセスチケットの情報を送り先のユーザと対応づけて記録する第１記録部、
として機能させるためのプログラム。
【請求項８】
ユーザの端末からのアクセスに対しユーザ認証を行うユーザ認証部と、
ユーザ認証の成功したユーザの端末からサービス提供側の装置の提供するサービスの利用要求を受け取った場合に、サービス提供側の装置に対する窓口側の装置のアカウントを用いてサービス提供側の装置にアクセスし、このアクセスに対してサービス提供側の装置から受け取ったアクセスチケットをユーザの端末に送る要求代行部と、
ユーザの端末に送ったアクセスチケットの情報を送り先のユーザと対応づけて記録する第１記録部と、
を備える窓口側の装置。
【請求項９】
窓口側の装置がユーザからの要求を処理する要求処理方法であって、
ユーザ認証部がユーザの端末からのアクセスに対しユーザ認証を行い、
要求代行部が、ユーザ認証の成功したユーザの端末からサービス提供側の装置の提供するサービスの利用要求を受け取った場合に、サービス提供側の装置に対する窓口側の装置のアカウントを用いてサービス提供側の装置にアクセスし、このアクセスに対してサービス提供側の装置から受け取ったアクセスチケットをユーザの端末に送り、
第１記録部が、ユーザの端末に送ったアクセスチケットの情報を送り先のユーザと対応づけて記録する、
要求処理方法。
【請求項１０】
コンピュータを、
窓口側の装置からのアクセスに対してアクセスチケットを生成してその窓口側の装置に発行するチケット発行部、
発行したアクセスチケットの情報を発行先の窓口側の装置と対応づけて記録する第２記録部、
ユーザから受けたアクセス要求がアクセスチケットを伴う場合に、そのユーザからのアクセスを許可するアクセス制御部、
として機能させるためのプログラム。
【請求項１１】
窓口側の装置からのアクセスに対してアクセスチケットを生成してその窓口側の装置に発行するチケット発行部と、
発行したアクセスチケットの情報を発行先の窓口側の装置と対応づけて記録する第２記録部と、
ユーザから受けたアクセス要求がアクセスチケットを伴う場合に、そのユーザからのアクセスを許可するアクセス制御部と、
を備えるサービス提供側の装置。
【請求項１２】
ユーザからの要求に応じてユーザにサービスを提供するサービス提供側の装置が実行する要求処理方法であって、
チケット発行部が、窓口側の装置からのアクセスに対してアクセスチケットを生成してその窓口側の装置に発行し、
第２記録部が、発行したアクセスチケットの情報を発行先の窓口側の装置と対応づけて記録し、
アクセス制御部が、ユーザから受けたアクセス要求がアクセスチケットを伴う場合に、そのユーザからのアクセスを許可する、
要求処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザに対してネットワークを介してサービスを提供するシステムに関し、特にサービスを提供するサーバに対するユーザの情報の保護のための技術に関する。
【背景技術】
【０００２】
インターネットの普及により、ユーザはインターネットを介してＷＷＷやそれを利用したウェブサービスなどの様々な方式で様々なサービスを受けることができるようになっている。このようなサービスを提供するサーバのなかには、不特定多数の人にサービスを提供する開放型のものもあれば、あらかじめ登録されたユーザのみにサービスを提供する閉鎖型のものもある。
【０００３】
後者の閉鎖型のサーバは、一般的に、ユーザからのアクセスに対して、ユーザ名やパスワード等の認証情報の入力を求めて認証処理を実行し、認証が成功した場合にのみそのユーザからのアクセスを認める。ユーザ認証を実行するために、従来、サーバにはユーザ名やパスワード等の認証情報、或いはその他のユーザの個人情報が登録されていた。
【０００４】
また、サーバがユーザに料金を要するサービスを提供する場合、その料金の決済のために、ユーザのクレジットカード番号などの情報をサーバが要求する場合もあった。
【０００５】
このように、ネットワークを介してサービスを提供する従来のサーバには、サービスの利用のためにユーザの個人情報をあらかじめサーバに登録したり、あるいは必要に応じてサーバに送信したりする必要があるものがあった。
【０００６】
ところが、ユーザが利用するサーバが多くなると、そのそれぞれにユーザの個人情報を登録したり、必要に応じて送信したりするのは、煩雑な作業となる。また、個人情報保護の観点から見ても、多数のサーバに個人情報を渡すのは好ましくない。サーバも、不必要な個人情報を持たない方が、情報漏洩のリスクを低減できる。
【０００７】
このような状況に鑑み、サービスを提供するサーバに対してユーザの情報を登録したり渡したりしなくても、サーバが、ある限定されたユーザに対してサービスが提供できるような仕組みが望まれる。また、同様に、サーバに対してユーザの情報を登録したり渡したりしなくても、サーバが適切にサービスに対して課金できる仕組みが望まれる。
【０００８】
このような課題に関連して、特許文献１には、各サーバが個別のＩＤ体系でユーザ管理ができ、ユーザは従来から使用していたＩＤを使用できるシングルサインオンシステムが開示される。このシステムでは、ユーザのサービス要求を受けたサイトＡは、そのユーザが未登録である場合、要求があったことをユーザの認証済みＩＤを保有するサイトＢへ送信する。サイトＢは、ユーザの認証を行い、その結果をユーザＩＤと共にシングルサインオンサーバへ送信する。シングルサインオンサーバは、サイトＢから受信したユーザＩＤが登録されているかをチェックし、登録されていない場合は、サイトＡの未使用ＩＤを選択してそのユーザのＩＤとして採用する。シングルサインオンサーバは、サイトＢから受けた認証結果とサイトＡ用のユーザＩＤとをサイトＡへ送信し、サイトＡは、要求があった商品またはサービスをユーザへ提供する。
【０００９】
この関連技術では、ユーザ自身が、サイトＡに対して個人情報を提供する操作を行う必要はない。しかし、サイトＡは必要に応じてサイトＢから個人情報の提供を受けることが可能である。また、サイトＡはユーザに対する課金処理の代理をサイトＢに依頼するが、サイトＡ自身でユーザー個人の識別ができなければ、シングルサインオンサーバのＩＤマッピングを用いてもサイトＢでのそのユーザのＩＤを求めることができないため、課金することができないという問題がある。
【００１０】
【特許文献１】特開２００４−２３４３２９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明は、上記関連技術の問題の少なくとも１つを解決する。
【課題を解決するための手段】
【００１２】
本発明の１つの側面では、窓口側の装置と、サービス提供側の装置とを含むサービス提供システムであって、窓口側の装置は、ユーザの端末からのアクセスに対しユーザ認証を行うユーザ認証部と、ユーザ認証の成功したユーザの端末からサービス提供側の装置の提供するサービスの利用要求を受け取った場合に、サービス提供側の装置に対する窓口側の装置のアカウントを用いてサービス提供側の装置にアクセスし、このアクセスに対してサービス提供側の装置から受け取ったアクセスチケットをユーザの端末に送る要求代行部と、ユーザの端末に送ったアクセスチケットの情報を送り先のユーザと対応づけて記録する第１記録部と、を備え、サービス提供側の装置は、窓口側の装置からのアクセスに対してアクセスチケットを生成してその窓口側の装置に発行するチケット発行部と、発行したアクセスチケットの情報を発行先の窓口側の装置と対応づけて記録する第２記録部と、ユーザから受けたアクセス要求がアクセスチケットを伴う場合に、そのユーザからのアクセスを許可するアクセス制御部と、を備える、サービス提供システムを提供する。
【００１３】
この発明によれば、ユーザは、サービス提供側の装置にユーザの情報を登録しておかなくても、サービス提供側の装置にアクセスする際にアクセスチケットを提示すればアクセスが可能となる。また、窓口側の装置の第１記録部とサービス提供側の装置の第２記録部にそれぞれアクセスチケットとその発行先との対応関係を記録しているので、アクセスチケットが正しく利用されたか後で検証できる。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照して、本発明の実施の形態（以下「実施形態」と呼ぶ）について説明する。
【００１５】
まず図１を参照して、実施形態のシステム構成を説明する。この図に示すように、実施形態のシステムは、インターネット等のネットワーク４０に接続された１以上の窓口サイト２０Ｘ，２０Ｙ，・・・（以下「窓口サイト２０」と総称）と、１以上のサービスサイト３０Ａ，３０Ｂ，・・・（以下「サービスサイト３０」と総称）とを備える。
【００１６】
サービスサイト３０は、ユーザ端末１０に対してそれぞれ所定のサービスを提供するサーバである。サービスサイト３０は、例えばウェブサーバ等として構成される。サービスサイト３０は、例えば、商品やソフトウエア・コンテンツの通信販売サイトや、旅行代理店サイト等の商業的なサービスを提供するサイトである。
【００１７】
同様のサービスサイトは従来から存在するが、そのような従来のサービスサイトは、ユーザ端末１０に対してサービスを提供するにあたりユーザ登録を求めることが多く、ユーザはユーザ登録の際に氏名や住所、年齢、性別、クレジットカード番号等の個人情報をサービスサイトに知らせる必要があった。また、ユーザ登録を求めなくても、商品を販売する場合には、その商品の届け先やクレジットカード番号などの個人情報の入力を求める場合は多い。
【００１８】
これに対して実施形態のサービスサイト３０は、基本的には個人ユーザの個人情報の登録は求めない。それは、サービスサイト３０が個人ユーザを直接的に信頼してサービスを提供するのではなく、その個人ユーザをユーザ認証した窓口サイト２０を信頼してサービスを提供するからである。
【００１９】
窓口サイト２０には、ユーザの氏名、本システムにおけるユーザ名等のユーザ識別情報、クレジットカード番号等の決済用の情報、パスワード等の認証情報などといった個人情報が登録されるか、あるいは必要に応じてユーザから入力される。ユーザは、サービスサイト３０を利用したい場合、窓口サイト２０にアクセスする。窓口サイト２０は、アクセスしてきたユーザを、個人情報を用いて認証する。窓口サイト２０は、ユーザ認証が成功したユーザ（すなわち正しい登録ユーザ）からサービスサイト３０へのアクセス要求を受けると、その窓口サイト２０がそのサービスサイト３０に設けたその窓口サイト２０自身のユーザアカウントを用いてサービスサイト３０にアクセスし、そのユーザがそのサービスサイト３０を利用できるようにする。
【００２０】
このための仕組みを、図２を参照して更に詳しく説明する。
【００２１】
まず、（１）ユーザ端末１０（例えばウェブブラウザ）は、ユーザからの指示に従い、窓口サイトＸ２０Ｘに対し、例えばＨＴＴＰなどを用いてアクセスする。ここで、窓口サイトＸには、そのユーザがすでにユーザ登録されているものとする（ただし、これに限らず、必要に応じて窓口サイトＸがユーザ情報をユーザに要求し受け取るようにしてもよい）。窓口サイトＸは、そのアクセス要求に応じてユーザ認証のためのパスワード等の認証情報の入力を求め、これに対してユーザ端末１０から正しい認証情報が送られてくると、そのユーザが正当な登録ユーザであると判定する。窓口サイトＸは、正当な登録ユーザに対しては、１以上のサービスサイト３０へのリンクの情報（例えば、リンク群を表示したウェブページ）を提供する。ユーザは、ユーザ端末１０の画面でそのリンク群の情報を見、それらリンク群の中から、自分が利用したいサービスサイト３０（例えばサービスサイトＡ）のものを選択する。通常のウェブページの場合、そのようなリンクにはそのサービスサイト３０自身のＵＲＬが記述されているため、ユーザ端末１０は、そのサービスサイト３０にＨＴＴＰ要求を発することになるが、本実施形態ではそのリンクには窓口サイトＸが提供する要求の取り次ぎ処理を呼び出すためのＵＲＬが示されるので、ユーザ端末１０は、ユーザからのリンク選択に応じ、窓口サイトＸに対して要求を発することになる。
【００２２】
（２）このように正当なユーザからサービスサイトＡの利用要求を受けた場合、窓口サイトＸは、サービスサイトＡに予め登録してある窓口サイトＸ自身のユーザアカウントを用いてサービスサイトＡにアクセスする。このとき、サービスサイトＡは、窓口サイトＸに認証情報を求めるなどすることで、窓口サイトＸのユーザ認証を行う。この場合、窓口サイトＸはサービスサイトＡに登録済みであり、ユーザアカウントを持っているので、このユーザ認証は成功する。
【００２３】
（３）ユーザ認証が成功した場合、サービスサイトＡは、アクセスチケットを生成し、これを窓口サイトＸに送る。アクセスチケットは、サービスサイトＡへのアクセスを要求したユーザ端末１０がサービスサイトＡにアクセスする際に用いるデータであり、このデータがユーザ端末１０から示されることで、サービスサイトＡは、自分がすでに認めたユーザからのアクセスであると判断する。アクセスチケットは、そのサービスサイトＡが発行したものであることが分かるような情報を持っていればよい。この情報は、サービスサイトＡの識別情報などの明示的な情報であってもよいし、アクセスチケットに対してサービスサイトＡの電子署名を付すことによるものであってもよい。なお、アクセスチケットに電子署名を付すことは、アクセスチケットの改ざん防止の観点からも有効である。
【００２４】
また、アクセスチケットには、窓口サイトＸの識別情報など、窓口サイトＸを特定する情報を含めておくことも好適である。サービスサイトＡは、窓口サイトＸを認証しているので、窓口サイトＸを特定する情報をアクセスチケットに埋め込むことができる。このように窓口サイトＸを特定する情報を埋め込んでおくことで、アクセスチケットが利用された場合に、そのアクセスチケットがどの窓口サイトからの要求に応じて発行されたものかをサービスサイトＡが把握できる。また、あるデータ（例えばサービスサイトＡと窓口サイトＸとの間で固定的に、或いはその都度、取り決めたデータ）に対して窓口サイトＸの電子署名を付したものを窓口サイトＸから送ってもらい、それを窓口サイトＸを特定する情報としてアクセスチケットに組み込んでもよい。このようにすれば、そのアクセスチケットが窓口サイトＸの要求に応じて発行されたものであることを、窓口サイトＸが否認できなくすることができる。
【００２５】
また、アクセスチケットには、一意な識別情報（チケットＩＤと呼ぶ）を付与し、そのチケットＩＤの情報を組み込んでおく。
【００２６】
（４）窓口サイトＸは、サービスサイトＡから受け取ったアクセスチケットを、例えばサービス要求に対する応答として、ユーザ端末１０に返す。
【００２７】
（５）ユーザ端末１０は、窓口サイトＸから受け取ったアクセスチケットを用いてサービスサイトＡにアクセスする。このアクセスは、例えばＨＴＴＰリダイレクションを用いて実現することができる。すなわち、処理（４）で窓口サイトＸがユーザ端末１０にアクセスチケットを送る際、例えば302(Found)等のリダイレクトを示すステータスコードを含み、かつリダイレクト先のＵＲＬとしてのサービスサイトＡのＵＲＬとアクセスチケットのデータとをLocationフィールドに含んだリダイレクト情報を生成し、これをユーザ端末１０に返す。ユーザ端末１０では、ウェブブラウザがそのリダイレクト情報を解釈して、自動的にサービスサイトＡにアクセスし、アクセスチケットをサービスサイトＡに渡す。
【００２８】
（６）サービスサイトＡは、ユーザ端末１０からのアクセス要求に、自分の発行した正しいアクセスチケットが含まれていれば、そのユーザ端末１０からのアクセスを許可する。このとき、アクセスチケットの提示がユーザ認証の代わりとなる。したがって、ユーザ端末１０を操作するユーザは、サービスサイトＡにユーザ登録を行う必要はないし、またサービスサイトＡもユーザの個人情報を持たなくてよい。
【００２９】
サービスサイトＡは、ユーザ端末１０にアクセスを許可すると、その後はユーザ端末１０からのＨＴＴＰ要求などの要求に応じて、要求されたデータをユーザ端末１０に提供する。
【００３０】
なお、アクセスチケットには、有効期間又は有効期限を設定しておくことが好適である。有効期間又は有効期限を設定しておくことで、アクセスチケットが第三者にわたっても、有効期間又は有効期限が過ぎた後であればその第三者はサービスサイトＡにアクセスできないので、第三者による不正利用のリスクを低減できる。この仕組みでは、ユーザ端末１０が窓口サイトＸにアクセスした後は、窓口サイトＸがサービスサイトＡにアクセスし、アクセスチケットを受け取ってユーザ端末１０に送るという自動的な処理なので、ユーザ端末１０がサービスサイトＡにリダイレクトされるまでにそれほど時間はかからない。したがって、アクセスチケットに設定する有効期限又は有効期間は、比較的短いものでかまわない。仮にアクセスチケットの有効期限が切れたとしても、正当なユーザ本人であれば再度窓口サイトＸにアクセスしてアクセスチケットを取得し直せば足りるので、有効期限を短く設定しても問題は少ない。なお、有効期間又は有効期限の情報は、チケットＩＤと対応づけてサービスサイトＡで保持していてもよいし、アクセスチケット自体に含めてもよい。
【００３１】
以上のシステムにおいて、サービスサイト３０がどの窓口サイト２０にどのアクセスチケットを発行したかを記録しておき、窓口サイト２０がどのアクセスチケットをどのユーザに渡したかを記録しておくようにする。これにより、必要に応じサービスサイト３０の記録と窓口サイト２０の記録を照合することで、サービスサイト３０が発行したチケットが正当なユーザに送られたか否か等の検証ができる。
【００３２】
なお、以上では、サービスサイト３０には基本的には個人ユーザはユーザ登録をしないとしたが、サービスサイト３０が個人ユーザの登録を認め、個人ユーザ自身がそのサービスサイト３０に個人情報を登録することを許容するのであれば、サービスサイト３０に個人ユーザを登録してももちろんかまわない。
【００３３】
以上、実施形態の基本概念を説明したので、次により具体的な実施形態を説明する。以下で説明する実施形態では、サービスサイトＡがユーザ端末１０に対して提供するサービスに課金を行う場合を例に取る。
【００３４】
この実施形態では、サービスサイトＡは、ユーザ端末１０に直接課金を行うのではなく、窓口サイトＸに対して課金する。そして、ユーザへの課金は窓口サイトＸが行う。すなわち、この実施形態では、サービスの料金は、サービスサイトＡとユーザとの間で直接的に決済するのではなく、サービスサイトＡと窓口サイトＸとの間と、窓口サイトＸとユーザとの間で、それぞれ独立に決済する。このようにすることで、ユーザは、クレジットカード番号その他の決済に必要な情報は、自分が利用する窓口サイト２０にのみ知らせればよく、個々のサービスサイト３０には知らせずにすむ。また、個々のサービスサイト３０も、ユーザの個人情報を管理する責任を負わずに済む。
【００３５】
このような仕組みを実現するため、窓口サイト２０は図３に示すような管理情報を管理し、サービスサイト３０は図４に示すような管理情報を管理する。
【００３６】
サービスサイト３０が管理する管理情報は、図４に示すように、チケットＩＤと窓口サイトＩＤと課金額との組である。すなわち、サービスサイト３０は、窓口サイト２０からの要求に応じてアクセスチケットを発行した場合、そのアクセスチケットのチケットＩＤとその窓口サイト３０の識別情報（窓口サイトＩＤ）とを管理情報に登録する。そして、ユーザ端末１０に対して課金を要するサービスを提供した場合、管理情報において、そのユーザ端末１０がアクセス要求時に提示したアクセスチケットのチケットＩＤに対応するエントリを求め、そのエントリの課金額に必要な金額を登録する。サービスサイト３０は、この課金額をチケットＩＤと共に、そのエントリに登録された窓口サイトＩＤが示す窓口サイト２０に対して通知する。なお、サービスサイト３０と窓口サイト２０との間の課金決済は、従来からある決済手法を用いて行うことができる。
【００３７】
窓口サイト２０は、サービスサイト３０からアクセスチケットを受け取り、それを要求元のユーザに転送した場合、そのアクセスチケットのチケットＩＤと、転送先のユーザのユーザＩＤとのペアを管理情報（図３参照）に登録する。そして、サービスサイト３０からチケットＩＤと課金額の情報を受け取った場合、管理情報におけるそのチケットＩＤに対応するエントリにその課金額を登録し、そのエントリのユーザＩＤが示すユーザに対してその課金額を課金する。窓口サイト２０とユーザとの間での課金の決済は、従来と同様に行えばよい。
【００３８】
次に、図５及び図６を参照して、この実施形態の処理手順を説明する。
【００３９】
図５に示すように、ユーザはサービスサイト３０のサービスを利用する場合、窓口サイト２０にアクセス要求を行う（Ｓ１）。このアクセス要求は、例えば、ユーザ端末１０のウェブブラウザに対し、ユーザが窓口サイト２０のＵＲＬへのアクセスを要求することにより発行される。アクセス要求を受けた窓口サイト２０は、ユーザ端末１０に対して認証要求を発する（Ｓ２）。この認証要求の際に、窓口サイト２０は、例えばユーザＩＤとパスワード等の認証情報を入力するためのウェブページをユーザ端末１０に送る。ユーザは、その認証要求に応じ、ユーザＩＤやパスワード等の認証情報を入力し、それら認証情報が窓口サイト２０に送られる（Ｓ３）。窓口サイト２０は、その認証情報を、自身が管理しているユーザ情報と照らし合わせることで、ユーザ認証を行う。このユーザ認証により、そのユーザが登録済みの正当なユーザであると判明した場合、窓口サイト２０は、ユーザ端末１０に対して、アクセス要求に対する許可の情報を送信する（Ｓ４）。このときに送る許可の情報は、例えば、窓口サイト２０を介して利用可能なサービスサイト３０のリストを表示したウェブページであってもよい。なお、窓口サイト２０には、利用可能なサービスサイト３０のＵＲＬ等のリストが予め登録されている。また、窓口サイト２０は、それら利用可能な各サービスサイト３０に対し、自分自身のユーザアカウントを開設している。
【００４０】
ユーザ端末１０を操作するユーザは、窓口サイト２０から提示されたサービスサイト３０の一覧の中から、利用したいサービスサイト３０を選択する。ユーザ端末１０は、ユーザが選択したサービスサイト３０の利用要求を窓口サイト２０に送信する（Ｓ５）。このためには、例えば、窓口サイト２０は、個々のサービスサイト３０からアクセスチケットを取得してユーザ端末１０に転送する処理を実行するプログラムを備えており、個々のサービスサイト３０を示すリンクとして、そのプログラムを呼び出すためのＵＲＬを示したリンクをユーザ端末１０に提供すればよい。この場合、ユーザが、希望するサービスサイト３０のリンクをクリックすれば、ユーザ端末１０は、そのサービスサイト３０にアクセするためのプロセスを呼び出すための要求を窓口サイト２０に送信する。
【００４１】
この要求を受けた窓口サイト２０は、対象となるサービスサイト３０に対し、自分のユーザアカウントでアクセスする（Ｓ６）。窓口サイト２０はサービスサイト３０に対してユーザアカウントを持っているので、このアクセスの際のユーザ認証は成功する。
【００４２】
このようにユーザ認証が成功すると、サービスサイト３０は、一意なチケットＩＤを持つアクセスチケットを生成し、これをＳ６の要求に対する応答として窓口サイト２０に返す（Ｓ７）。このとき、サービスサイト３０は、発行したアクセスチケットのチケットＩＤと、発行先の窓口サイト３０のＩＤとを対応づけて管理情報に登録する。
【００４３】
アクセスチケットを受け取った窓口サイト２０は、Ｓ５の要求に対する応答として、サービスサイト３０へのリダイレクト情報をユーザ端末１０に送信する（Ｓ８）。このリダイレクト情報には、サービスサイト３０のＵＲＬと、アクセスチケットが含まれる。また、このとき窓口サイト２０は、転送したアクセスチケットのチケットＩＤと転送先のユーザのＩＤとのペアを管理情報に追加する。
【００４４】
ユーザ端末１０は、窓口サイト２０から受け取ったリダイレクト情報を用いてサービスサイト３０にアクセスする（Ｓ９）。このときユーザ端末１０は、アクセスチケットをサービスサイト３０に送る。
【００４５】
サービスサイト３０は、ユーザ端末１０からのアクセス要求にアクセスチケットが含まれている場合、そのアクセスチケットを検証する（Ｓ１０）。検証では、そのアクセスチケットが自分の発行したものかを判定し、またそのアクセスチケットの有効期間又は有効期限が切れていないかを確認する。例えば、そのアクセスチケットのチケットＩＤが、サービスサイト３０が管理する管理情報（図４参照）に記録されていれば、そのチケットはサービスサイト３０自身が発行したものと判定すればよい。また、アクセスチケットに対してサービスサイト３０自身の電子署名を付した場合は、その電子署名を検証し、その検証が成功した場合に、そのアクセスチケットはサービスサイト３０自身の発行したものであると判定してもよい。また管理情報にチケットＩＤが登録されており、かつ電子署名の検証が成功した場合に、そのアクセスチケットはサービスサイト３０自身の発行したものであると判定するようにしてもよい。そして、そのアクセスチケットがサービスサイト３０自身が発行したものであり、且つ有効期間又は有効期限が切れていないと判定された場合には、サービスサイト３０は、ユーザ端末１０からのアクセスを許可し、ユーザ端末１０に対してサービス提供のためのウェブページを送る（Ｓ１１）。サービスサイト３０からアクセス許可を受けたユーザ端末１０は、サービスサイト３０が許可する範囲内のウェブページに対してアクセスが許される。
【００４６】
ここでは、一例として、サービスサイト３０は、デジタルコンテンツ（文書データや音楽データ、プログラムなど）を販売するサイトであるとする。サービスサイト３０がユーザ端末１０に提供するウェブページには、例えば、販売するコンテンツの一覧が示される。ユーザは、そのウェブページ上で、自分が欲しいコンテンツを選択する。すると、ユーザ端末１０は、そのコンテンツを特定する情報を含んだ要求をサービスサイト３０に送信する（Ｓ１２）。
【００４７】
ここで、ユーザが要求したコンテンツが課金を必要とするものである場合（Ｓ１３）、サービスサイト３０は、課金額を示した課金要求を窓口サイト２０に送る（Ｓ１４）。ここで、課金要求の送り先の窓口サイト２０は、Ｓ９で受け取ったアクセスチケットのチケットＩＤに対応する窓口サイトＩＤを管理情報（図４参照）から検索することで、求めることができる。なお、サービスサイト３０は、その課金額を、管理情報のそのチケットＩＤに対応するエントリに登録する。
【００４８】
この課金要求を受け取った窓口サイト２０は、課金確認用のウェブページを用意する。また、課金額を、管理情報のそのチケットＩＤに対応するエントリに登録する。
【００４９】
また、サービスサイト３０は、ユーザ端末１０に対し、Ｓ１２のコンテンツ要求に対する応答として、その窓口サイト２０の課金確認用のウェブページへリダイレクトするためのリダイレクト情報をユーザ端末１０に送信する（Ｓ１５）。ユーザ端末１０が、そのリダイレクト情報に従い、窓口サイトの課金確認用のウェブページにアクセスすると（Ｓ１６）、窓口サイト２０は、そのウェブページのデータをユーザ端末１０に送って課金確認を要求する（Ｓ１７）。
【００５０】
ここで、例えば、サービスサイト３０が、Ｓ１４の課金要求に対し一意な識別情報を組み込んでおくとともに、Ｓ１５のリダイレクト情報にもその識別情報を含めておき。窓口サイト２０がその識別情報に対応づけて課金確認用のウェブページを用意しておくようにすれば、リダイレクト（Ｓ１５，Ｓ１６）によりユーザ端末１０が課金確認用のウェブページにアクセスできるようにすることができる。
【００５１】
課金確認用のウェブページには、例えば、課金額と、課金対象のコンテンツを示す情報（この情報は、Ｓ１４の課金要求に含まれているとする）とが示され、その課金を受け入れるか否かを入力するためのＧＵＩ（グラフィカル・ユーザ・インタフェース）部品（例えば了承又は拒絶を選択するためのボタンなど）が含まれる。ユーザが、このウェブページに対して課金を受け入れる旨の入力を行うと、ユーザ端末１０は、課金が了承された旨の情報を窓口サイト２０に返す（Ｓ１８）。これに応じ、窓口サイト２０は、課金が了承された旨の情報をサービスサイト３０に送る（Ｓ１９）。
【００５２】
サービスサイト３０は、窓口サイト２０から、課金が了承された旨の情報を受けて初めて、Ｓ１２でユーザが要求したコンテンツを提供する。ここで、本実施形態では、コンテンツはユーザ端末１０に直接ではなく、窓口サイト２０に送る（Ｓ２０）。そのとき、コンテンツは、チケットＩＤと対応づけて送る。これを受け取った窓口サイト２０は、そのチケットＩＤに対応するユーザＩＤを管理情報から求め、そのユーザＩＤが示すユーザに対してコンテンツを送信する（Ｓ２１）。コンテンツは、例えば電子メールを用いてユーザに送信すればよい（ユーザのメールアドレスは、ユーザＩＤと対応づけて予め窓口サイト２０に登録されているものとする）。また、窓口サイト２０が持つ格納領域にそのコンテンツを格納しておき、ユーザにはそのコンテンツの格納場所へのリンク（ＵＲＬなど）を電子メールで送信することで、ユーザがそのコンテンツをダウンロードできるようにしてもよい。このように、コンテンツを窓口サイト２０経由でユーザ端末１０に送るようにすれば、窓口サイト２０は、確かにサービスサイト３０からユーザにコンテンツが提供されたことを確認することができる。なお、バリエーションとして、サービスサイト３０からユーザ端末１０に直接コンテンツを送信してもかまわない。
【００５３】
なお、このシステムでは、ユーザと窓口サイト２０との間、及び窓口サイト２０とサービスサイト３０との間での課金の決済は、それぞれ個別にそれら両者間の取り決めに従って行われる。
【００５４】
以上のようにして、ユーザは、サービスサイト３０には個人情報を渡さなくても、サービスサイト３０にアクセスし、課金が必要なサービスを受けることができる。また、サービスサイト３０は、窓口サイト２０に認証されたユーザのみにサービスを提供するので、取引の安全性を期待できる。また、サービスサイト３０は、ユーザの個人情報を管理しなくても済むので、情報漏洩リスクが大幅に低減できる。
【００５５】
図５及び図６の例では、デジタルコンテンツを販売するサービスサイトを例にとったが、物理的な実体を持つ商品を販売するサービスサイトの場合にも、同様の仕組みが適用できる。この場合、サービスサイトはユーザが購入した商品を窓口サイトの運営者に送り、窓口サイトの運営者がその商品をユーザに送るようにすればよい。これにより、ユーザは、サービスサイトに自分の住所を登録しなくても、サービスサイトから商品を購入して受け取ることができる。
【００５６】
また、窓口サイト２０が複数ある場合において、同じサービスサイト３０がそれら複数の窓口サイト２０と取引することもできる。この場合、サービスサイト３０は、ユーザがどの窓口サイト２０を経由してアクセスしてきたかに応じて、そのユーザに対して提供するサービスの内容や質を変えることができる。例えば、窓口サイトごとに、提供するコンテンツのリストを変えてもよいし、また各コンテンツの提供価格を変えることもできる。また、窓口サイトごとに個別のキャンペーン用のウェブページを用意し、キャンペーンサービスを提供することもできる。このためには、例えば、サービスサイト３０に、図７に示すように窓口サイトごとに異なるサービス条件を登録しておけばよい。サービスサイト３０は、ユーザがＳ９で提示したアクセスチケットのチケットＩＤに対応する窓口サイトＩＤを管理情報から求めることで、そのユーザが経由した窓口サイト２０が特定でき、その窓口サイトに対応するサービス条件に応じたサービスをユーザに提供できる。
【００５７】
また、以上の例では、サービスサイト３０は、ユーザに対して提供したサービスの課金を窓口サイト２０に対して行い、窓口サイト２０は、その課金と同額をユーザに対して課金した。しかし、これはあくまで一例に過ぎない。窓口サイト２０は、場合によってはユーザに対して課金をしなくてもよいし、またサービスサイト３０からの課金額とは異なる額をユーザに課金してもよい。例えば窓口サイト２０が法人サイトである場合には、その法人の従業員がその窓口サイト２０を介してサービスサイト３０からコンテンツを購入した場合、窓口サイト２０は従業員に対してその課金を行わないようにすることもできる。また、窓口サイト２０が福利厚生サイトである場合、ユーザがそのサイト２０を介してコンテンツを購入した場合に、そのコンテンツの代金（すなわちサービスサイト３０からの課金額）の一部をそのサイト２０が負担することとし、ユーザに対してはその額より少ない額を課金するようにしてもよい。
【００５８】
以上に説明した窓口サイト２０又はサービスサイト３０は、典型的には、汎用のコンピュータにて以上に説明した各サイト２０又は３０の各要素の機能又は処理内容を記述したプログラムを実行することにより実現される。コンピュータは、ハードウエアとして、図８に示すように、ＣＰＵ（中央演算装置）５０、メモリ（一次記憶）５２、各種Ｉ／Ｏ（入出力）インタフェース５４等がバス５６を介して接続された回路構成を有する。また、そのバス５６に対し、例えばＩ／Ｏインタフェース５４経由で、ハードディスクドライブ５８やＣＤやＤＶＤ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体を読み取るためのディスクドライブ６０が接続される。このようなドライブ５８又は６０は、メモリに対する外部記憶装置として機能する。上記各例のシステムの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク経由で、ハードディスクドライブ５８等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがメモリに読み出されＣＰＵにより実行されることにより、上記各例の処理が実現される。
【図面の簡単な説明】
【００５９】
【図１】実施形態のシステム構成を示す図である。
【図２】実施形態の処理の流れを説明するための図である。
【図３】課金を伴う実施形態における窓口サイトの管理情報のデータ内容の例を示す図である。
【図４】課金を伴う実施形態におけるサービスサイトの管理情報のデータ内容の例を示す図である。
【図５】課金を伴う実施形態の処理の前半部を示す図である。
【図６】課金を伴う実施形態の処理の後半部を示す図である。
【図７】窓口サイト毎に異なるサービスを提供する実施形態におけるサービスサイトの管理情報のデータ内容の例を示す図である。
【図８】汎用コンピュータのハードウエア構成の一例を示す図である。
【符号の説明】
【００６０】
１０  ユーザ端末、２０，２０Ｘ，２０Ｙ  窓口サイト、３０，３０Ａ，３０Ｂ  サービスサイト、４０  ネットワーク。
【図１】
2007233690.tif 000003
【図２】
2007233690.tif 000004
【図３】
2007233690.tif 000005
【図４】
2007233690.tif 000006
【図５】
2007233690.tif 000007
【図６】
2007233690.tif 000008
【図７】
2007233690.tif 000009
【図８】
2007233690.tif 000010