(57)【要約】【課題】ユーザ毎に、コンテンツに対する同時アクセス数を制限することができるコンテンツ閲覧制限装置を提供する。【解決手段】Ｗｅｂサーバは、アクセス要求を受け付けると添付情報を確認し、セッションＩＤを伴っていなければ、生成する（Ｓ１００〜Ｓ１０２、Ｓ１１０）。続いて、タイムアウトしたセッション情報を抹消し（Ｓ１０３）、認証処理を実行する（Ｓ１０４、Ｓ１０５、Ｓ１１１）。認証成功の場合、セッションＩＤが有効なら、最終アクセス時刻を更新し、コンテンツを送信する。無効なら、セッション数を確認し、最大セッション数に達していたら、ログイン失敗通知コンテンツを返信する。さもなければ、セッション数を１だけ増やし、セッション情報を新たに登録して、コンテンツを送信する（Ｓ１０６〜Ｓ１０９、Ｓ１１２、Ｓ１１３）。【選択図】　図６
2004127172.tif 000002
【特許請求の範囲】
【請求項１】
所定のコンテンツに対するＷｅｂアクセスを、セッション識別子を用いて、制限するコンテンツ閲覧制限装置であって、
Ｗｅｂアクセスの要求を受け付けるアクセス要求受付手段と、
前記アクセス要求受付手段にて、受け付けたＷｅｂアクセスの要求がセッション識別子を伴っていない場合に、同時セッション数が所定値に一致するか否かを判定する同時セッション数判定手段と、
前記同時セッション数判定手段にて、同時セッション数が所定値に一致しないと判定した場合に、セッション識別子を生成して、前記Ｗｅｂアクセスの要求元に送信するセッション識別子発行手段と、
前記同時セッション数判定手段にて、同時セッション数が所定値に一致すると判定した場合に、前記Ｗｅｂアクセスの要求を拒絶する第１のアクセス要求拒絶手段と、
１のセッション識別子について所与の条件を判定して、当該セッション識別子を無効とするセッション識別子無効化手段と、
前記アクセス要求受付手段にて、受け付けたＷｅｂアクセスの要求がセッション識別子を伴っている場合であって、かつ、当該セッション識別子が無効である場合に、前記Ｗｅｂアクセスの要求を拒絶する第２のアクセス要求拒絶手段と
を備えることを特徴とするコンテンツ閲覧制限装置。
【請求項２】
前記セッション識別子無効化手段は、１のセッション識別子に係るＷｅｂアクセスの要求を最後に受信してから所定の時間を経過したら、当該セッション識別子を無効とする
ことを特徴とする請求項１に記載のコンテンツ閲覧制限装置。
【請求項３】
認証情報の登録を受け付ける認証情報登録手段を備え、
前記アクセス要求受付手段は、Ｗｅｂアクセスの要求を受け付けると、前記Ｗｅｂアクセスの要求元に認証情報を要求し、要求した前記認証情報を受け付けると、前記認証情報登録手段にて登録した認証情報と照合して、前記照合の結果、認証に失敗したら、前記Ｗｅｂアクセスの要求を拒絶し、
前記同時セッション数判定手段は、前記Ｗｅｂアクセスの要求に係る認証情報に対応する同時セッション数が所定値に一致するか否かを判定し、
前記セッション識別子発行手段は、前記同時セッション数判定手段にて、前記Ｗｅｂアクセスの要求に係る認証情報に対応する同時セッション数が所定値に一致しないと判定した場合に、セッション識別子を生成して、前記Ｗｅｂアクセスの要求元に送信し、
前記第１のアクセス要求拒絶手段は、前記同時セッション数判定手段にて、前記Ｗｅｂアクセスの要求に係る認証情報に対応する同時セッション数が所定値に一致すると判定した場合に、前記Ｗｅｂアクセスの要求を拒絶する
ことを特徴とする請求項１または請求項２に記載のコンテンツ閲覧制限装置。
【請求項４】
前記認証情報に対応する最大セッション数の登録を受け付ける最大セッション数登録手段を備え、
前記同時セッション数判定手段は、前記Ｗｅｂアクセスの要求に係る認証情報に対応する同時セッション数が最大セッション数に一致するか否かを判定することを特徴とする請求項３に記載のコンテンツ閲覧制限装置。
【請求項５】
前記セッション識別子発行手段は、Ｃｏｏｋｉｅを用いて前記セッション識別子を送信し、
前記アクセス要求受付手段は、Ｃｏｏｋｉｅを用いて前記セッション識別子を受信する
ことを特徴とする請求項１に記載のコンテンツ閲覧制限装置。
【請求項６】
所定のコンテンツに対するＷｅｂアクセスを、セッション識別子を用いて、制限するコンテンツ閲覧制限方法であって、
Ｗｅｂアクセスの要求を受け付けるアクセス要求受付ステップと、
前記アクセス要求受付ステップにて、受け付けたＷｅｂアクセスの要求がセッション識別子を伴っていない場合に、同時セッション数が所定値に一致するか否かを判定する同時セッション数判定ステップと、
前記同時セッション数判定ステップにて、同時セッション数が所定値に一致しないと判定した場合に、セッション識別子を生成して、前記Ｗｅｂアクセスの要求元に送信するセッション識別子発行ステップと、
前記同時セッション数判定ステップにて、同時セッション数が所定値に一致すると判定した場合に、前記Ｗｅｂアクセスの要求を拒絶する第１のアクセス要求拒絶ステップと、
１のセッション識別子について所与の条件を判定して、当該セッション識別子を無効とするセッション識別子無効化ステップと、
前記アクセス要求受付ステップにて、受け付けたＷｅｂアクセスの要求がセッション識別子を伴っている場合であって、かつ、当該セッション識別子が無効である場合に、前記Ｗｅｂアクセスの要求を拒絶する第２のアクセス要求拒絶ステップと
を含むことを特徴とするコンテンツ閲覧制限方法。
【請求項７】
前記セッション識別子無効化ステップは、１のセッション識別子に係るＷｅｂアクセスの要求を最後に受信してから所定の時間を経過したら、当該セッション識別子を無効とする
ことを特徴とする請求項６に記載のコンテンツ閲覧制限方法。
【請求項８】
認証情報の登録を受け付ける認証情報登録ステップを含み、
前記アクセス受付ステップは、Ｗｅｂアクセスの要求を受け付けると、前記Ｗｅｂアクセスの要求元に認証情報を要求し、要求した前記認証情報を受け付けると、前記認証情報登録ステップにて登録した認証情報と照合して、前記照合の結果、認証に失敗したら、前記Ｗｅｂアクセスの要求を拒絶し、
前記同時セッション数判定ステップは、前記Ｗｅｂアクセスの要求に係る認証情報に対応する同時セッション数が所定値に一致するか否かを判定し、
前記セッション識別子発行ステップは、前記同時セッション数判定ステップにて、前記Ｗｅｂアクセスの要求に係る認証情報に対応する同時セッション数が所定値に一致しないと判定した場合に、セッション識別子を生成して、前記Ｗｅｂアクセスの要求元に送信し、
前記第１のアクセス要求拒絶ステップは、前記同時セッション数判定ステップにて、前記Ｗｅｂアクセスの要求に係る認証情報に対応する同時セッション数が所定値に一致すると判定した場合に、前記Ｗｅｂアクセスの要求を拒絶することを特徴とする請求項６または請求項７に記載のコンテンツ閲覧制限方法。
【請求項９】
前記認証情報に対応する最大セッション数の登録を受け付ける最大セッション数登録ステップを含み、
前記同時セッション数判定ステップは、前記Ｗｅｂアクセスの要求に係る認証情報に対応する同時セッション数が最大セッション数に一致するか否かを判定する
ことを特徴とする請求項８に記載のコンテンツ閲覧制限方法。
【請求項１０】
前記セッション識別子発行ステップは、Ｃｏｏｋｉｅを用いて前記セッション識別子を送信し、
前記アクセス要求受付ステップは、Ｃｏｏｋｉｅを用いて前記セッション識別子を受信する
ことを特徴とする請求項６に記載のコンテンツ閲覧制限方法。
【請求項１１】
請求項６から請求項１０のいずれかに記載のコンテンツ閲覧制限方法をコンピュータに実行させるためのコンテンツ閲覧制限プログラム。
【請求項１２】
所定のコンテンツに対するＷｅｂアクセスを、セッション識別子を用いて、制限するコンテンツ閲覧制限装置であって、
Ｗｅｂアクセスの要求を受け付けるアクセス要求受付手段と、
前記アクセス要求受付手段にて、受け付けたＷｅｂアクセスの要求がセッション識別子を伴っていない場合に、セッション識別子を生成した回数が所定値に一致するか否かを判定する生成回数判定手段と、
前記生成回数判定手段にて、前記生成回数が所定値に一致しないと判定した場合に、セッション識別子を生成して、前記Ｗｅｂアクセスの要求元に送信するセッション識別子発行手段と、
前記生成回数判定手段にて、前記生成回数が所定値に一致すると判定した場合に、前記Ｗｅｂアクセスの要求を拒絶する第１のアクセス要求拒絶手段とを備えることを特徴とするコンテンツ閲覧制限装置。
【請求項１３】
認証情報の登録を受け付ける認証情報登録手段を備え、
前記アクセス受付手段は、Ｗｅｂアクセスの要求を受け付けると、前記Ｗｅｂアクセスの要求元に認証情報を要求し、要求した前記認証情報を受け付けると、前記認証情報登録手段にて登録した認証情報と照合して、前記照合の結果、認証に失敗したら、前記Ｗｅｂアクセスの要求を拒絶し、
前記生成回数判定手段は、前記Ｗｅｂアクセスの要求に係る認証情報に対応する前記生成数が所定値に一致するか否かを判定し、
前記セッション識別子発行手段は、前記生成回数判定手段にて、前記Ｗｅｂアクセスの要求に係る認証情報に対応する前記生成回数が所定値に一致しないと判定した場合に、セッション識別子を生成して、前記Ｗｅｂアクセスの要求元に送信する
ことを特徴とする請求項１２に記載のコンテンツ閲覧制限装置。
【請求項１４】
所定のコンテンツに対するＷｅｂアクセスを、セッション識別子を用いて、制限するコンテンツ閲覧制限方法であって、
Ｗｅｂアクセスの要求を受け付けるアクセス要求受付ステップと、
前記アクセス要求受付ステップにて、受け付けたＷｅｂアクセスの要求がセッション識別子を伴っていない場合に、セッション識別子を生成した回数が所定値に一致するか否かを判定する生成回数判定ステップと、
前記生成回数判定ステップにて、前記生成回数が所定値に一致しないと判定した場合に、セッション識別子を生成して、前記Ｗｅｂアクセスの要求元に送信するセッション識別子発行ステップと、
前記生成回数判定ステップにて、前記生成回数が所定値に一致すると判定した場合に、前記Ｗｅｂアクセスの要求を拒絶する第１のアクセス要求拒絶ステップと
を備えることを特徴とするコンテンツ閲覧制限方法。
【請求項１５】
認証情報の登録を受け付ける認証情報登録ステップを備え、
前記アクセス受付ステップは、Ｗｅｂアクセスの要求を受け付けると、前記Ｗｅｂアクセスの要求元に認証情報を要求し、要求した前記認証情報を受け付けると、前記認証情報登録ステップにて登録した認証情報と照合して、前記照合の結果、認証に失敗したら、前記Ｗｅｂアクセスの要求を拒絶し、
前記生成回数判定ステップは、前記Ｗｅｂアクセスの要求に係る認証情報に対応する前記生成数が所定値に一致するか否かを判定し、
前記セッション識別子発行ステップは、前記生成回数判定ステップにて、前記Ｗｅｂアクセスの要求に係る認証情報に対応する前記生成回数が所定値に一致しないと判定した場合に、セッション識別子を生成して、前記Ｗｅｂアクセスの要求元に送信する
ことを特徴とする請求項１４に記載のコンテンツ閲覧制限方法。
【請求項１６】
請求項１４または請求項１５に記載のコンテンツ閲覧制限方法をコンピュータに実行させるためのコンテンツ閲覧制限プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はコンテンツに対するアクセスを管理する技術に関し、特にユーザ毎に同時アクセス数を制限するコンテンツ閲覧制限装置、コンテンツ閲覧制限方法、およびコンテンツ閲覧制限プログラムに関する。
【０００２】
【従来の技術】
近年、情報通信技術の急速な発達とともに、インターネットを利用した様々なビジネスが展開されつつある。このようなインターネット・ビジネスは、Ｗｅｂサイトを窓口として、有償と無償との別を問わず、さまざまなデータやサービス（以下、単に「コンテンツ」という。）を提供するのが一般的である。そして、特に、有償でコンテンツを提供する際には、コンテンツへのＷｅｂアクセスを管理する技術が重要となってくる。
【０００３】
このようなＷｅｂアクセス管理技術には、従来、コンテンツにＷｅｂアクセスしようとする端末等の機器を特定して行う技術と、コンテンツにＷｅｂアクセスしようとするユーザを特定して行う技術とが知られている。
前者は、ドメイン名やホスト名、或いはＩＰ（Ｉｎｔｅｒｎｅｔ　ｐｒｏｔｏｃｏｌ）アドレスによって、コンテンツにＷｅｂアクセスしようとする機器を特定し、予め登録されている機器であるか否かによってＷｅｂアクセスの諾否を決定する。
【０００４】
後者は、コンテンツへのＷｅｂアクセスに先立って、ユーザ名やパスワードといった認証情報を受け付けて、当該認証情報が予め登録されている認証情報に合致するか否かによってＷｅｂアクセスの諾否を決定する。このようにユーザ認証を行うＷｅｂアクセス管理技術には、代表的なものとしてベーシック認証方式がある（例えば、特許文献１を参照）。
【０００５】
【特許文献１】
特開２００１−６９１７５
【０００６】
【発明が解決しようとする課題】
しかしながら、現在、インターネットを介して特に盛んに行なわれているＢｔｏＢ（ｂｕｓｉｎｅｓｓ　ｔｏ　ｂｕｓｉｎｅｓｓ）ビジネスにおいては、企業間で取引が行なわれるため、コンテンツにアクセスする機器を特定するタイプのＷｅｂアクセス管理技術は適当ではない。なぜなら、企業内で、コンテンツにＷｅｂアクセスするために使用されるであろう機器は多数に亘る場合が多く、しかも、企業内においてはかかる機器の入れ替えが頻繁に発生することが多いからである。
【０００７】
また、個人ユーザに対しては有効に機能するユーザ認証方式も、企業ユーザに対しては必ずしも有効ではない。例えば、企業内の部署毎に契約を結んで、コンテンツへのＷｅｂアクセス権を提供すれば、より高い収益をあげられるところ、企業全体でひとつの契約しかしていないのに、当該企業内でＷｅｂアクセス権が共有されてしまうことがある。
【０００８】
このような場合、複数部署からのＷｅｂアクセスの要求に応えてコンテンツを提供しているにも関わらず、コンテンツの提供回数に応じた収益を得ることができない。また、かかる場合においては、Ｗｅｂアクセスの要求が同時多発的に発生するためＷｅｂサーバの処理負荷が過大となるおそれもある。
本発明は、上記のような問題に鑑みて為されたものであって、コンテンツに対するＷｅｂアクセスを制限するコンテンツ閲覧制限装置、コンテンツ閲覧制限方法、およびコンテンツ閲覧制限プログラムであって、特にユーザ毎に同時アクセス数を制限することができるコンテンツ閲覧制限装置、コンテンツ閲覧制限方法、およびコンテンツ閲覧制限プログラムを提供することを目的とする。
【０００９】
【課題を解決するための手段】
上記目的を達成するため、本発明に係るコンテンツ閲覧制限装置は、所定のコンテンツに対するＷｅｂアクセスを、セッション識別子を用いて、制限するコンテンツ閲覧制限装置であって、Ｗｅｂアクセスの要求を受け付けるアクセス要求受付手段と、前記アクセス要求受付手段にて、受け付けたＷｅｂアクセスの要求がセッション識別子を伴っていない場合に、同時セッション数が所定値に一致するか否かを判定する同時セッション数判定手段と、前記同時セッション数判定手段にて、同時セッション数が所定値に一致しないと判定した場合に、セッション識別子を生成して、前記Ｗｅｂアクセスの要求元に送信するセッション識別子発行手段と、前記同時セッション数判定手段にて、同時セッション数が所定値に一致すると判定した場合に、前記Ｗｅｂアクセスの要求を拒絶する第１のアクセス要求拒絶手段と、１のセッション識別子について所与の条件を判定して、当該セッション識別子を無効とするセッション識別子無効化手段と、前記アクセス要求受付手段にて、受け付けたＷｅｂアクセスの要求がセッション識別子を伴っている場合であって、かつ、当該セッション識別子が無効である場合に、前記Ｗｅｂアクセスの要求を拒絶する第２のアクセス要求拒絶手段とを備えることを特徴とする。
【００１０】
また、本発明に係るコンテンツ閲覧制限装置は、前記セッション識別子無効化手段は、１のセッション識別子に係るＷｅｂアクセスの要求を最後に受信してから所定の時間を経過したら、当該セッション識別子を無効とすることを特徴とする。
また、本発明に係るコンテンツ閲覧制限装置は、認証情報の登録を受け付ける認証情報登録手段を備え、前記アクセス要求受付手段は、Ｗｅｂアクセスの要求を受け付けると、前記Ｗｅｂアクセスの要求元に認証情報を要求し、要求した前記認証情報を受け付けると、前記認証情報登録手段にて登録した認証情報と照合して、前記照合の結果、認証に失敗したら、前記Ｗｅｂアクセスの要求を拒絶し、前記同時セッション数判定手段は、前記Ｗｅｂアクセスの要求に係る認証情報に対応する同時セッション数が所定値に一致するか否かを判定し、前記セッション識別子発行手段は、前記同時セッション数判定手段にて、前記Ｗｅｂアクセスの要求に係る認証情報に対応する同時セッション数が所定値に一致しないと判定した場合に、セッション識別子を生成して、前記Ｗｅｂアクセスの要求元に送信し、前記第１のアクセス要求拒絶手段は、前記同時セッション数判定手段にて、前記Ｗｅｂアクセスの要求に係る認証情報に対応する同時セッション数が所定値に一致すると判定した場合に、前記Ｗｅｂアクセスの要求を拒絶することを特徴とする。
【００１１】
また、本発明に係るコンテンツ閲覧制限装置は、前記認証情報に対応する最大セッション数の登録を受け付ける最大セッション数登録手段を備え、前記同時セッション数判定手段は、前記Ｗｅｂアクセスの要求に係る認証情報に対応する同時セッション数が最大セッション数に一致するか否かを判定することを特徴とする。
【００１２】
また、本発明に係るコンテンツ閲覧制限装置は、前記セッション識別子発行手段は、Ｃｏｏｋｉｅを用いて前記セッション識別子を送信し、前記アクセス要求受付手段は、Ｃｏｏｋｉｅを用いて前記セッション識別子を受信することを特徴とする。
このような装置によれば、コンテンツに対するＷｅｂアクセスであって、特にユーザ毎に同時アクセス数を制限することができる。
【００１３】
また、本発明に係るコンテンツ閲覧制限方法は、所定のコンテンツに対するＷｅｂアクセスを、セッション識別子を用いて、制限するコンテンツ閲覧制限方法であって、Ｗｅｂアクセスの要求を受け付けるアクセス要求受付ステップと、前記アクセス要求受付ステップにて、受け付けたＷｅｂアクセスの要求がセッション識別子を伴っていない場合に、同時セッション数が所定値に一致するか否かを判定する同時セッション数判定ステップと、前記同時セッション数判定ステップにて、同時セッション数が所定値に一致しないと判定した場合に、セッション識別子を生成して、前記Ｗｅｂアクセスの要求元に送信するセッション識別子発行ステップと、前記同時セッション数判定ステップにて、同時セッション数が所定値に一致すると判定した場合に、前記Ｗｅｂアクセスの要求を拒絶する第１のアクセス要求拒絶ステップと、１のセッション識別子について所与の条件を判定して、当該セッション識別子を無効とするセッション識別子無効化ステップと、前記アクセス要求受付ステップにて、受け付けたＷｅｂアクセスの要求がセッション識別子を伴っている場合であって、かつ、当該セッション識別子が無効である場合に、前記Ｗｅｂアクセスの要求を拒絶する第２のアクセス要求拒絶ステップとを含むことを特徴とする。
【００１４】
また、本発明に係るコンテンツ閲覧制限方法は、前記セッション識別子無効化ステップは、１のセッション識別子に係るＷｅｂアクセスの要求を最後に受信してから所定の時間を経過したら、当該セッション識別子を無効とすることを特徴とする。
また、本発明に係るコンテンツ閲覧制限方法は、認証情報の登録を受け付ける認証情報登録ステップを含み、前記アクセス受付ステップは、Ｗｅｂアクセスの要求を受け付けると、前記Ｗｅｂアクセスの要求元に認証情報を要求し、要求した前記認証情報を受け付けると、前記認証情報登録ステップにて登録した認証情報と照合して、前記照合の結果、認証に失敗したら、前記Ｗｅｂアクセスの要求を拒絶し、前記同時セッション数判定ステップは、前記Ｗｅｂアクセスの要求に係る認証情報に対応する同時セッション数が所定値に一致するか否かを判定し、前記セッション識別子発行ステップは、前記同時セッション数判定ステップにて、前記Ｗｅｂアクセスの要求に係る認証情報に対応する同時セッション数が所定値に一致しないと判定した場合に、セッション識別子を生成して、前記Ｗｅｂアクセスの要求元に送信し、前記第１のアクセス要求拒絶ステップは、前記同時セッション数判定ステップにて、前記Ｗｅｂアクセスの要求に係る認証情報に対応する同時セッション数が所定値に一致すると判定した場合に、前記Ｗｅｂアクセスの要求を拒絶することを特徴とする。
【００１５】
また、本発明に係るコンテンツ閲覧制限方法は、前記認証情報に対応する最大セッション数の登録を受け付ける最大セッション数登録ステップを含み、前記同時セッション数判定ステップは、前記Ｗｅｂアクセスの要求に係る認証情報に対応する同時セッション数が最大セッション数に一致するか否かを判定することを特徴とする。
【００１６】
また、本発明に係るコンテンツ閲覧制限方法は、前記セッション識別子発行ステップは、Ｃｏｏｋｉｅを用いて前記セッション識別子を送信し、前記アクセス要求受付ステップは、Ｃｏｏｋｉｅを用いて前記セッション識別子を受信することを特徴とする。
このような方法を用いれば、コンテンツに対するＷｅｂアクセスであって、特にユーザ毎に同時アクセス数を制限することができる。
【００１７】
また、本発明に係るコンテンツ閲覧制限プログラムは、上述のようなコンテンツ閲覧制限方法をコンピュータに実行させることを特徴とする。従って、コンテンツに対するＷｅｂアクセスであって、特にユーザ毎に同時アクセス数を制限することをコンピュータに実行させることができる。
更に、本発明に係るコンテンツ閲覧制限装置は、所定のコンテンツに対するＷｅｂアクセスを、セッション識別子を用いて、制限するコンテンツ閲覧制限装置であって、Ｗｅｂアクセスの要求を受け付けるアクセス要求受付手段と、前記アクセス要求受付手段にて、受け付けたＷｅｂアクセスの要求がセッション識別子を伴っていない場合に、セッション識別子を生成した回数が所定値に一致するか否かを判定する生成回数判定手段と、前記生成回数判定手段にて、前記生成回数が所定値に一致しないと判定した場合に、セッション識別子を生成して、前記Ｗｅｂアクセスの要求元に送信するセッション識別子発行手段と、前記生成回数判定手段にて、前記生成回数が所定値に一致すると判定した場合に、前記Ｗｅｂアクセスの要求を拒絶する第１のアクセス要求拒絶手段とを備えることを特徴とする。
【００１８】
かかる装置によれば、最も早いＷｅｂアクセスから所定数だけのＷｅｂアクセスのみを許可することができる。
また、認証情報の登録を受け付ける認証情報登録手段を備え、前記アクセス受付手段は、Ｗｅｂアクセスの要求を受け付けると、前記Ｗｅｂアクセスの要求元に認証情報を要求し、要求した前記認証情報を受け付けると、前記認証情報登録手段にて登録した認証情報と照合して、前記照合の結果、認証に失敗したら、前記Ｗｅｂアクセスの要求を拒絶し、前記生成回数判定手段は、前記Ｗｅｂアクセスの要求に係る認証情報に対応する前記生成数が所定値に一致するか否かを判定し、前記セッション識別子発行手段は、前記生成回数判定手段にて、前記Ｗｅｂアクセスの要求に係る認証情報に対応する前記生成回数が所定値に一致しないと判定した場合に、セッション識別子を生成して、前記Ｗｅｂアクセスの要求元に送信することとすれば、上記のようなＷｅｂアクセスの制限を登録されたユーザ毎に実施することができる。
【００１９】
また、本発明に係るコンテンツ閲覧制限方法は、所定のコンテンツに対するＷｅｂアクセスを、セッション識別子を用いて、制限するコンテンツ閲覧制限方法であって、Ｗｅｂアクセスの要求を受け付けるアクセス要求受付ステップと、前記アクセス要求受付ステップにて、受け付けたＷｅｂアクセスの要求がセッション識別子を伴っていない場合に、セッション識別子を生成した回数が所定値に一致するか否かを判定する生成回数判定ステップと、前記生成回数判定ステップにて、前記生成回数が所定値に一致しないと判定した場合に、セッション識別子を生成して、前記Ｗｅｂアクセスの要求元に送信するセッション識別子発行ステップと、前記生成回数判定ステップにて、前記生成回数が所定値に一致すると判定した場合に、前記Ｗｅｂアクセスの要求を拒絶する第１のアクセス要求拒絶ステップとを備えることを特徴とする。
【００２０】
また、本発明に係るコンテンツ閲覧制限方法は、認証情報の登録を受け付ける認証情報登録ステップを備え、前記アクセス受付ステップは、Ｗｅｂアクセスの要求を受け付けると、前記Ｗｅｂアクセスの要求元に認証情報を要求し、要求した前記認証情報を受け付けると、前記認証情報登録ステップにて登録した認証情報と照合して、前記照合の結果、認証に失敗したら、前記Ｗｅｂアクセスの要求を拒絶し、前記生成回数判定ステップは、前記Ｗｅｂアクセスの要求に係る認証情報に対応する前記生成数が所定値に一致するか否かを判定し、前記セッション識別子発行ステップは、前記生成回数判定ステップにて、前記Ｗｅｂアクセスの要求に係る認証情報に対応する前記生成回数が所定値に一致しないと判定した場合に、セッション識別子を生成して、前記Ｗｅｂアクセスの要求元に送信することを特徴とする。
【００２１】
このような方法を用いれば、上記コンテンツ閲覧制限装置と同様に、所定のコンテンツへのＷｅｂアクセスを先着順に所定数だけ許諾することができる。
また、本発明に係るコンテンツ閲覧制限プログラムは、本発明に係るコンテンツ閲覧方法をコンピュータに実行させることを特徴とする。このようにすれば、所定のコンテンツへのＷｅｂアクセスを先着順に許諾するようにコンピュータを動作させることができる。
【００２２】
【発明の実施の形態】
以下、本発明に係るコンテンツ閲覧制限装置の実施の形態を、コンテンツ閲覧制限システムを例にとり、図面を参照しながら説明する。
［１］　システム構成
図１は、典型的なコンテンツ閲覧制限システムの構成を示す図であって、特に、ブラウザを搭載したＷｅｂ端末（Ｗｅｂクライアント）とＷｅｂサーバとをインターネット接続した場合について示している。図１において、コンテンツ閲覧制限システム１は、インターネット１３を介して、Ｗｅｂ端末１０、１１、１２とＷｅｂサーバ１４とを接続した構成となっている。当該Ｗｅｂサーバ１４が、本発明に係るコンテンツ閲覧制限装置に相当する装置である。
【００２３】
なお、Ｗｅｂ端末１０〜１２は、いわゆるプロキシ・サーバ（ｐｒｏｘｙ　ｓｅｒｖｅｒ）を介して、Ｗｅｂサーバ１４にＷｅｂアクセスするとしても良いし、プロキシ・サーバを解さずに直接Ｗｅｂサーバ１４にＷｅｂアクセスするとしても良い。Ｗｅｂ端末１０〜１２は、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）に従って、Ｗｅｂサーバ１４や、或いは、プロキシ・サーバにＷｅｂアクセスする。また、Ｗｅｂ端末はいずれもＷｅｂブラウザを搭載されており、その台数は３台に限定されない。
【００２４】
［１−２］　Ｗｅｂサーバ１４の構成
図２は、Ｗｅｂサーバ１４の機能構成を示す機能構成図である。Ｗｅｂサーバ１４は、図２に示すように、認証設定受付部２０、アクセス要求受付部２１、タイムアウト処理部２２、ユーザ認証部２３、セッション確認部２４、セッション登録部２５、コンテンツ送信部２６、認証設定情報記憶部２７、及び、コンテンツ記憶部２８を備えている。
【００２５】
認証設定受付部２０は、Ｗｅｂアクセスを許可されるユーザについての認証設定情報をＷｅｂ端末から受け付ける。本実施の形態においては、当該認証設定情報は、ユーザ名、認証ＩＤ、認証パスワード、最大セッション数、及び、有効期限である。ユーザは、Ｗｅｂサーバ１４に対するＷｅｂアクセスを開始するに先立って、認証ＩＤと認証パスワードとを入力して登録を要求する。認証設定受付部２０は、前記認証設定情報を受け付けると、これを認証設定情報記憶部２７に通知して、記憶させる。
【００２６】
アクセス要求受付部２１は、Ｗｅｂ端末から受け付けたＷｅｂアクセスの要求が認証ＩＤや認証パスワードといった認証情報を伴っているか否かを確認する。そして、当該Ｗｅｂアクセスの要求が認証情報を伴っていなければ、ユーザに認証情報の入力を促すためのユーザ認証用コンテンツを前記Ｗｅｂ端末に送信するように、コンテンツ送信部２６に依頼する。
【００２７】
また、アクセス要求受付部２１は、前記Ｗｅｂアクセスの要求がセッションＩＤを伴っているか否かを確認する。そして、当該Ｗｅｂアクセスの要求がセッションＩＤを伴っていなければ、セッションＩＤを生成する。
この場合において、例えば、セッションＩＤは３２桁の数値であるとしても良く、また、ＭＤ５（Ｍｅｓｓａｇｅ　Ｄｉｇｅｓｔ　５，　ＲＦＣ１３２１）やＳＨＡ−１（Ｓｅｃｕｒｅ　Ｈａｓｈｉｎｇ　Ａｌｇｏｒｉｔｈｍ　１，　ＮＩＳＴ　ＦＩＰＳ　ＰＵＢ　１８０−１）のような一方向ハッシュアルゴリズムによってセッションＩＤを生成するとしても良い。
【００２８】
タイムアウト処理部２２は、アクセス要求受付部２１が上記の処理を完了すると、認証設定情報記憶部２７に記憶されているセッション情報を参照する。ここで、セッション情報は、セッションＩＤ、認証ＩＤ、及び、最終アクセス時刻からなる情報であって、すべてのセッションについてセッション情報が認証設定情報記憶部２７に記憶されている。
【００２９】
タイムアウト処理部２２は、セッション情報毎に最終アクセス時刻を参照し、また、現在時刻を参照して、最終アクセス時刻から所定のタイムアウト時間を経過しているかを確認する。そして、タイムアウト時間を経過していたら、そのセッション情報を認証設定情報記憶部２７から抹消するとともに、認証ＩＤに対応するセッション数を１だけ減ずる。なお、タイムアウト時間を経過していないセッション情報については、タイムアウト処理部２２は何も処理を行わない。
【００３０】
ユーザ認証部２３は、Ｗｅｂ端末から受け付けた認証ＩＤと認証パスワードとに基づいて認証処理を実行する。すなわち、ユーザ認証部２３は、認証設定情報記憶部２７に記憶されている認証ＩＤと認証パスワードとを読み出して、これらの認証情報を照合する。そして、認証情報が合致しなかったら、認証を要求したＷｅｂ端末に対して、Ｗｅｂアクセスを許可しない旨を通知する認証失敗通知コンテンツを送信する。
【００３１】
認証情報が合致したら、ユーザ認証部２３は有効期限を確認する。すなわち、前記認証ＩＤに対応する有効期限を認証設定情報記憶部２７から読み出すとともに、現在日時を参照して、有効期限を経過しているか否かを確認する。そして、有効期限を経過していたら、ユーザ認証部２３は、認証を要求したＷｅｂ端末に対して、Ｗｅｂアクセスを許可しない旨を通知する認証失敗通知コンテンツを送信する。
【００３２】
セッション確認部２４は、タイムアウト処理部２２が上記の処理を完了した後、前記アクセス要求受付部にて受け付けたセッションＩＤが既に登録されているセッションＩＤであるか否かを確認する。すなわち、認証設定情報記憶部２７に記憶されているセッション情報を参照して、前記セッションＩＤを含むセッション情報が登録されているか否かを確認する。
【００３３】
そして、前記セッションＩＤが認証設定情報記憶部２７に登録されていたら、セッション確認部２４は、セッション登録部２５に依頼して、当該セッション情報に関する最終アクセス時刻を更新する。
前記セッションＩＤが認証設定情報記憶部２７に登録されていなければ、セッション確認部２４は、認証設定情報記憶部２７に記憶されているセッション数と最大セッション数であって、前記認証ＩＤに対応するセッション数と最大セッション数を参照する。そして、前記セッション数と前記最大セッション数とが一致していたら、セッション確認部２４は、認証を要求したＷｅｂ端末に対して、Ｗｅｂアクセスを許可しない旨を通知するために、ログイン失敗通知コンテンツを送信する。
【００３４】
前記セッション数が前記最大セッション数よりも小さかったら、セッション確認部２４は、前記セッション数を１だけ増やす。なお、上記のように、前記セッション数と前記最大セッション数とが一致している場合にはセッション数を増加させないので、前記セッション数が前記最大セッション数よりも大きくなることはない。そして、セッション確認部２４は、Ｗｅｂアクセスを許可する場合には、アクセス要求受付部２１が生成したセッションＩＤを含むセッション情報を、セッション登録部２５に依頼して、認証設定情報記憶部２７に登録する。
【００３５】
セッション登録部２５は、上述のように、セッション確認部２４の依頼を受けて、指定されたセッション情報に関する最終アクセス時刻を更新する。すなわち、セッション確認部２４からセッションＩＤと最終アクセス時刻との通知を受けると、セッション登録部２５は、通知されたセッションＩＤに対応するセッション情報の最終アクセス時刻として、通知された最終アクセス時刻を登録する。
【００３６】
セッション登録部２５は、また、上述のように、セッション確認部２４からの依頼を受けて、指定されたセッションＩＤに関して新たなセッション情報を生成する。そして、セッション登録部２５は、当該セッション情報を認証設定情報記憶部に登録する。
コンテンツ送信部２６は、上述のように、アクセス要求受付部２１からの依頼を受けて、前記コンテンツ記憶部２８からユーザ認証用コンテンツを読み出し、前記Ｗｅｂ端末に送信する。また、コンテンツ送信部２６は、ユーザ認証部２３からの依頼を受けて、前記コンテンツ記憶部２８から認証失敗通知コンテンツを読み出し、前記Ｗｅｂ端末に対して送信する。
【００３７】
更に、コンテンツ送信部２６は、セッション確認部２４からの依頼については、その依頼内容に応じて、前記コンテンツ記憶部２８からログイン失敗通知コンテンツを読み出して、前記Ｗｅｂ端末に送信し、或いは、前記Ｗｅｂ端末がＷｅｂアクセスを要求したコンテンツを前記コンテンツ記憶部２８から読み出して、当該Ｗｅｂ端末に送信する。
【００３８】
認証設定情報記憶部２７は、認証設定情報として、ユーザ名、認証ＩＤ、認証パスワード、最大セッション数、及び、有効期限を組として記憶する。また、認証設定情報記憶部２７は、当該認証設定情報に対応付けて、セッション情報を記憶する。当該セッション情報は、セッションＩＤ、認証ＩＤ、及び、最終アクセス時刻からなっている。
【００３９】
コンテンツ記憶部２８は、Ｗｅｂサーバ１４がＷｅｂ端末からの要求を受けて配信するコンテンツを記憶する。コンテンツ記憶部２８が記憶するコンテンツには、ユーザに認証情報の入力を促すためのユーザ認証用コンテンツや、ユーザ認証に失敗したためにＷｅｂアクセスを許可しない旨を通知する認証失敗通知コンテンツ、セッション数が最大セッション数に達しているためにＷｅｂアクセスを許可しない旨を通知するログイン失敗通知コンテンツ、或いは、Ｗｅｂアクセスの要求に係るコンテンツがある。
【００４０】
［２］　セッションの管理
ＨＴＴＰは状態を持たないプロトコルであるため、そのままでは複数のＷｅｂアクセスを互いに関連付けて、同時アクセス数の制限をすることができない。また、複数のコンテンツを関連付けてＷｅｂアクセスの制限をすることも、そのままではできない。従って、同時アクセス数を制限するためには、複数のＷｅｂアクセスを互いに関連付け、また、複数のコンテンツを関連付けるためのセッション管理が不可欠である。
【００４１】
セッションの管理に際しては、セッションの情報をＷｅｂサーバ側に保持する方法と、Ｗｅｂ端末側に保持する方法とがある。これらの方法のうち、Ｗｅｂ端末側にセッション情報を保持する方法は、セッション情報の大きさがＷｅｂ端末の記憶容量に制限され、また、セキュリティ上の問題があるとされている。このため、本実施の形態においては、セッション情報をＷｅｂサーバ側に保持する方法を採用した場合について説明する。
【００４２】
本実施の形態においては、セッション情報をＷｅｂサーバ側に保持する場合であって、セッションＩＤをＷｅｂ端末に通知し、当該セッションＩＤをキーとしてセッション毎のセッション情報にアクセスする方法を採用する。Ｗｅｂ端末にセッションＩＤを通知する方法としては、ＣｏｏｋｉｅやＧＥＴ引数などを用いればよい。
【００４３】
すなわち、Ｗｅｂサーバは、Ｗｅｂ端末からの新たなＷｅｂアクセスを受け付けると、セッションＩＤを生成し、例えば、Ｃｏｏｋｉｅとして、Ｗｅｂ端末に返信すると共に、当該セッションＩＤと当該セッションＩＤに係るセッション情報とをデータベースに保存する。
Ｗｅｂサーバは、Ｗｅｂ端末がセッションＩＤを指定してＷｅｂアクセスを要求してきた場合には、当該セッションＩＤをキーとして前記データベースを検索する。そして、前記セッションＩＤに該当するセッション情報が見つかった場合には、セッションＩＤを同じくするＷｅｂアクセスを同一セッション内のＷｅｂアクセスと判定する。セッションＩＤが異なるＷｅｂアクセスは互いに異なるセッションに属するＷｅｂアクセスと判定する。
【００４４】
また、本明細書において、同時セッション数とは、同時に存在する有効なセッションＩＤの数をいう。また、１の認証ＩＤに係る同時セッション数とは、同時に存在する有効なセッションＩＤであって、前記１の認証ＩＤに係るセッションＩＤの数をいう。ここで、有効なセッションＩＤとは、Ｗｅｂアクセスの要求が当該セッションＩＤを伴う場合にＷｅｂアクセスが直ちに許可されるようなセッションＩＤをいう。
【００４５】
従って、有効でないセッションＩＤを伴うＷｅｂアクセスの要求があった場合、Ｗｅｂアクセスは直ちには許可されず、認証処理の結果によってＷｅｂアクセスの許否が決定される。この場合において、Ｗｅｂアクセスが許可されるときには、新たにセッションＩＤが発行される。そして、当該セッションＩＤは、有効なセッションＩＤである。
【００４６】
［２−１］　通信シーケンス
上記のようなセッション管理に伴って、コンテンツ閲覧制限システム１において、実行される典型的な通信シーケンスについて、通信シーケンス図を参照しながら説明する。
（１）　通信シーケンスの例（その１）
図３は、コンテンツ閲覧制限システム１における、Ｗｅｂ端末とＷｅｂサーバ１４の間の典型的な通信シーケンスの例を示す図である。図３に示すように、Ｗｅｂサーバ１４は、Ｗｅｂ端末から、セッション管理の対象となっているコンテンツに対するＷｅｂアクセスの要求を受け付けると、認証用のコンテンツを返信する。
【００４７】
Ｗｅｂ端末は、受信した認証用のコンテンツを用いて、ユーザから認証情報として認証ＩＤと認証パスワードを受け付けると、Ｗｅｂサーバ１４に認証情報を送信する。
Ｗｅｂサーバ１４は、Ｗｅｂ端末から認証情報を受け付けると、認証処理を実行する。図３には、当該認証処理が成功した場合が示されている。Ｗｅｂサーバ１４は、認証処理が成功したらセッションＩＤを生成する。そして、Ｗｅｂ端末がＷｅｂアクセスを要求したコンテンツと当該セッションＩＤとをＷｅｂ端末に送信する。
【００４８】
Ｗｅｂ端末は、Ｗｅｂサーバ１４から受け取ったセッションＩＤを次回以降のＷｅｂアクセスの際にＷｅｂサーバ１４に送信する。すなわち、Ｗｅｂ端末は、Ｗｅｂサーバ１４にＷｅｂアクセスを要求する際に、併せて前記セッションＩＤをＷｅｂサーバ１４に送信する。
Ｗｅｂサーバ１４は、Ｗｅｂ端末からＷｅｂアクセスの要求とともにセッションＩＤを受け付けると、受け付けたセッションＩＤの有効性を確認する。図３には、受け付けたセッションＩＤが有効である場合が示されている。Ｗｅｂサーバ１４は前記セッションＩＤの有効性を確認すると、Ｗｅｂアクセスを要求されたコンテンツを、当該Ｗｅｂ端末に送信する。
【００４９】
その後、Ｗｅｂ端末からのＷｅｂアクセスを受け付けていない状態が所定時間継続するとタイムアウトが発生して、Ｗｅｂサーバ１４は前記セッションＩＤを抹消して、無効とする。
Ｗｅｂサーバ１４は、セッションＩＤを無効にしたことをＷｅｂ端末に通知しないので、Ｗｅｂ端末が無効にされたセッションＩＤを通知してＷｅｂアクセスを要求する場合がある。このような場合には、図３に示されるように、Ｗｅｂサーバ１４は、Ｗｅｂ端末にユーザ認証用コンテンツを送信して、認証情報を要求する。認証情報を要求した後の通信シーケンスについては、上に説明した通りである。
【００５０】
（２）　通信シーケンスの例（その２）
図４は、コンテンツ閲覧制限システム１における、Ｗｅｂ端末とＷｅｂサーバ１４の間の典型的な通信シーケンスの例であって、認証が失敗する場合の通信シーケンスを示す図である。
図４に示すように、Ｗｅｂサーバ１４は、Ｗｅｂ端末から、セッション管理の対象となっているコンテンツに対するＷｅｂアクセスの要求を受け付けると、認証用のコンテンツを返信する。
【００５１】
Ｗｅｂ端末は、Ｗｅｂサーバ１４から認証用のコンテンツを受信すると、当該コンテンツを利用して、ユーザから認証情報を受け付ける。そして、ユーザから受け付けた認証情報をＷｅｂサーバ１４に送信する。
Ｗｅｂサーバ１４は、Ｗｅｂ端末から認証情報を受け付けると、認証処理を実行する。図４においては、この認証処理が失敗する場合が示されている。認証処理が失敗するケースとしては、認証ＩＤが予め登録されたものとは異なっている場合と、認証ＩＤは正しいが、併せて受け付けた認証パスワードが認証ＩＤに対応するものと異なっている場合とがある。
【００５２】
Ｗｅｂサーバ１４は、認証処理が失敗した場合には、その旨を通知する認証失敗通知コンテンツをＷｅｂ端末に送信する。Ｗｅｂ端末は、Ｗｅｂサーバ１４から認証失敗通知コンテンツを受信すると、これを表示して、ユーザに認証情報が正しくなかった旨を通知する。
当該表示がなされた後もなお、ユーザがコンテンツの表示を希望する場合には、ユーザは正しい認証情報を入力しなおさなければならない。この認証情報の入力の便宜を図るため、認証失敗通知コンテンツに認証情報の入力を受け付けるためのフォームを設けるとしても良い。
【００５３】
（３）　通信シーケンスの例（その３）
図５は、コンテンツ閲覧制限システム１における、Ｗｅｂ端末とＷｅｂサーバ１４の間の典型的な通信シーケンスの例であって、セッションＩＤの生成が失敗する場合の通信シーケンスを示す図である。
図５に示すように、Ｗｅｂサーバ１４は、Ｗｅｂ端末から、セッション管理の対象となっているコンテンツに対するＷｅｂアクセスの要求を受け付けると、認証用のコンテンツを返信する。
【００５４】
Ｗｅｂ端末は、Ｗｅｂサーバ１４から認証用のコンテンツを受信すると、当該コンテンツを利用して、ユーザから認証情報を受け付ける。そして、ユーザから受け付けた認証情報をＷｅｂサーバ１４に送信する。
Ｗｅｂサーバ１４は、Ｗｅｂ端末から認証情報を受け付けると、認証処理を実行する。Ｗｅｂサーバ１４は、認証処理が成功すると、引き続いて、同時セッション数の確認を実行する。図４においては、同時セッション数が所定数に達している場合が示されており、Ｗｅｂサーバ１４は、新たなセッションＩＤの生成に失敗する。
【００５５】
Ｗｅｂサーバ１４は、新たなセッションＩＤの生成に失敗した場合には、セッションＩＤの生成に失敗した旨を通知するコンテンツをＷｅｂ端末に送信する。Ｗｅｂ端末は、Ｗｅｂサーバ１４から前記コンテンツを受信すると、これを表示して、ユーザにセッションＩＤの生成に失敗した旨を通知する。
当該表示がなされた場合には、ユーザがコンテンツの表示を希望する場合であって、現存しているセッションのうちの少なくとも１のセッションが終了しなければ、ユーザは希望するコンテンツにＷｅｂアクセスすることができない。
【００５６】
［３］　Ｗｅｂサーバ１４の動作
次に、Ｗｅｂサーバ１４の動作について説明する。図６は、Ｗｅｂサーバ１４の処理の流れを表すフローチャートであって、特に、通信シーケンスに関わる処理を表わすフローチャートである。
図６に示すように、Ｗｅｂサーバ１４は、Ｗｅｂ端末からＷｅｂアクセスの要求を受け付けると、前述のアクセス要求受付部２１にて、前記Ｗｅｂ端末から受け付けたＷｅｂアクセスの要求が認証情報を伴っているか否かを確認する。本実施の形態においては、例えば、この認証情報がｃｏｏｋｉｅに格納された状態でＷｅｂアクセスの要求がなされ、Ｗｅｂサーバ１４は当該ｃｏｏｋｉｅの内容を確認することによって、認証情報の有無を判定する。
【００５７】
そして、Ｗｅｂサーバ１４は、当該Ｗｅｂアクセスの要求が認証情報を伴っているものでなければ（ステップＳ１００：ＮＯ）、コンテンツ記憶部２８からユーザ認証用コンテンツを読み出す。そして、当該コンテンツを、コンテンツ送信部２６にて、前記Ｗｅｂ端末に対して送信する（ステップＳ１１０）。
前記Ｗｅｂアクセスの要求が認証情報を伴っているものであれば（ステップＳ１００：ＹＥＳ）、次に、当該Ｗｅｂアクセスの要求がセッションＩＤを伴っているか否かを確認する。そして、当該Ｗｅｂアクセスの要求がセッションＩＤを伴っていなければ（ステップＳ１０１：ＮＯ）、前述のようにして、新たなセッションＩＤを生成する（ステップＳ１０２）。
【００５８】
前記Ｗｅｂアクセスの要求がセッションＩＤを伴っている場合（ステップＳ１０１：ＹＥＳ）、または、新たなセッションＩＤを生成した後、Ｗｅｂサーバ１４は、前記タイムアウト処理部２２にて、タイムアウト処理を実行する。すなわち、タイムアウト処理部２２は、認証設定情報記憶部２７に記憶されているセッション情報を読み出して、個々のセッション情報について最終アクセス時刻を参照する。
【００５９】
そして、最終アクセス時刻から現時刻までの経過時間を算出して、当該経過時間が、所定のタイムアウト時間を超えている場合には、Ｗｅｂサーバ１４は、そのようなセッション情報を認証設定情報記憶部２７から抹消する（ステップＳ１０３）。
次に、Ｗｅｂサーバ１４は、ユーザの認証処理を実行する。すなわち、ユーザ認証部２３にて、認証設定情報記憶部２７を参照し、Ｗｅｂ端末から受け付けた前記認証情報に合致する認証情報が登録されているか否かを確認する。当該認証情報が合致しない場合には、認証処理は失敗したと判定して（ステップＳ１０４：ＮＯ）、認証処理が失敗した旨を通知する認証失敗通知コンテンツを前記コンテンツ記憶部２８から読み出す。そして、Ｗｅｂサーバ１４は、当該コンテンツを、前記コンテンツ送信部２６にて、当該Ｗｅｂ端末に対して送信する（ステップＳ１１１）。
【００６０】
前記の確認の結果、認証設定情報記憶部２７にて合致する認証情報が発見され、認証処理が成功したと判定された場合には（ステップＳ１０４：ＹＥＳ）、当該認証情報が有効期限切れとなっているか否かを確認する。そして、当該認証情報が有効期限切れとなっている場合には（ステップＳ１０５：ＹＥＳ）、やはり、認証失敗通知コンテンツを前記コンテンツ記憶部２８から読み出す。そして、当該コンテンツを、前記コンテンツ送信部２６にて、当該Ｗｅｂ端末に対し送信する（ステップＳ１１１）。
【００６１】
前記認証情報が有効期限切れとなっていない場合には（ステップＳ１０５：ＮＯ）、Ｗｅｂサーバ１４は、セッション確認処理に進む。すなわち、Ｗｅｂサーバ１４は、前記セッション確認部２４にて、セッション確認処理に係るセッションＩＤが認証設定情報記憶部２７に登録されているセッションＩＤと合致するか否かを確認する。
【００６２】
そして、合致するセッションＩＤを発見したら（ステップＳ１０６：ＹＥＳ）、前記セッション登録部２５にて、当該セッションＩＤに係るセッション情報の最終アクセス時刻を更新し（ステップＳ１１３）、前記Ｗｅｂ端末がＷｅｂアクセスを要求したコンテンツを前記コンテンツ記憶部から読み出す。そして、当該コンテンツを、前記コンテンツ送信部２６にて、前記Ｗｅｂ端末に対して送信する（ステップＳ１０９）。
【００６３】
合致するセッションＩＤを発見しなかった場合には（ステップＳ１０６：ＮＯ）、新たなセッションを開始することができるか否かを判断するために、セッション数を確認する。すなわち、Ｗｅｂサーバ１４は、前述のセッション確認部２４にて、認証設定情報記憶部２７に記憶されているセッション数と最大セッション数とを比較して、これらが一致するか否かを確認する。
【００６４】
この比較の結果、前記セッション数が前記最大セッション数に等しかったら（ステップＳ１１０：ＮＯ）、同時セッション数が上限値に達しているために、新たなセッションを開始することができない。そこで、Ｗｅｂサーバ１４は、前記コンテンツ記憶部２８から、同時セッション数の制限を理由としてコンテンツの送信を拒否する旨を通知するログイン失敗通知コンテンツを読み出す。そして、当該コンテンツを、前記コンテンツ送信部２６にて、前記Ｗｅｂ端末に対して送信する（ステップＳ１１２）。
【００６５】
前記の比較の結果、前記セッション数が前記最大セッション数よりも小さかったら（ステップＳ１０７：ＹＥＳ）、セッション確認部２４は、前記セッション数を１だけ増やす。続いて、セッション登録部２５は、前記Ｗｅｂ端末からＷｅｂアクセスの要求を受け付けた時刻を最終アクセス時刻とし、当該セッション確認処理に係るセッションＩＤを含むセッション情報を生成する。そして、セッション登録部２５は、生成したセッション情報を前記認証設定情報記憶部２７に登録する（ステップＳ１０８）。
【００６６】
セッション登録部２５がセッション情報の登録を完了すると、前記コンテンツ記憶部２８から、前記Ｗｅｂ端末がＷｅｂアクセスを要求したコンテンツを読み出す。そして、コンテンツ送信部２６は、当該コンテンツを前記Ｗｅｂ端末に対して送信する（ステップＳ１０９）。このようにすることによって、有効なセッションＩＤを伴わないＷｅｂアクセスを排除することができるので、同時セッション数を制限することができる。
【００６７】
なお、本フローチャートは一例に過ぎず、例えば、異なる認証ＩＤに係るＷｅｂアクセスについては上記処理を並列実行するとしても良い。このようにすれば、他の認証ＩＤに係るＷｅｂアクセスについての認証等の処理がされている最中であるか否かを問わず、Ｗｅｂアクセスを受け付けることができるので、より迅速にＷｅｂアクセスの処理を行うことができる。
【００６８】
［４］　変形例
以上、本発明を実施の形態に基づいて説明してきたが、本発明は、上述の実施の形態に限定されないのは勿論であり、以下のような変形例を実施することができる。
（１）　上記実施の形態においては、ユーザ毎の同時セッション数の上限値を設けてセッション管理を行う場合について説明したが、これに加えて次のようにするとしても良い。
【００６９】
すなわち、予め累積セッション数の上限値を設けておき、新たにセッションＩＤを発行した回数が当該上限値を超過したら、新たなＷｅｂアクセスを禁止するとしても良い。このようにすれば、予めユーザ毎の契約によって定められた累積セッション数の範囲内でＷｅｂアクセスを許可するといったサービス形態を実現することができる。
【００７０】
また、先着順に人数を限ってサービスを提供するような場合にも本発明は有効である。例えば、先着１００名に商品券をプレゼントするようなサービスは、条記のようにセッション管理を行うことでより容易に実現される。なお、このような場合においては、ユーザの認証を行わないとしても良い。また、この場合において、同一人が重複して商品券のプレゼントを受けることがないように、プレゼントの送り先など追加的な情報をユーザに入力させて、ユーザを識別することも有効である。
【００７１】
また、別の例としては、いわゆるチャットルームの人数制限がある。チャットは、オンライン・トーク、或いはリアルタイム会議室とも呼ばれ、ネットワーク上で複数人がリアルタイムにメッセージの交換を行うシステムである。従って、チャットルームの参加者が多くなり過ぎるとメッセージを交換するために要するネットワークの不可が増大したり、或いは、参加者からの発言数が多くなり過ぎて収拾がつかなくなったりといった事態が発生する。
【００７２】
このため、セッション管理をすることにより、同時セッション数に上限を設けて、Ｗｅｂアクセスを制限するとすれば、チャットルームに参加する人数を制限することができる。従って、参加人数が過大となることに起因する上述のような不都合を回避することができるので、チャットルームの円滑な運営を可能とすることができる。
【００７３】
（２）　上記の実施の形態に述べたような、同時セッション数の管理は、必ずしも単一の事業者によってなされるとは限らない。
例えば、ＩＳＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｒｖｉｃｅ　Ｐｒｏｖｉｄｅｒ）とその加入者とが一緒になって、同時セッション数を管理するといった実施形態をとるとしても良い。すなわち、ＩＳＰは、加入者に対して、当該加入者のコンテンツに係る認証設定情報をデータベースに登録するためのインタフェースを提供することによって、加入者が自己のコンテンツに対するＷｅｂアクセスを制限することができるようにするとしても良い。
【００７４】
（３）　上記実施の形態のようなセッション管理を実行するためには、例えば、ＰＨＰ（ＰＨＰ：　Ｈｙｐｅｒｔｅｘｔ　Ｐｒｅｐｒｏｃｅｓｓｏｒ）を用いるのが便利である。
ＰＨＰは、Ａｐａｃｈｅに組み込んで使用される、ＨＴＭＬ（Ｈｙｐｅｒｔｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）埋め込み型スクリプト言語である。ここで、Ａｐａｃｈｅとは、米イリノイ大学のＮＣＳＡ（Ｎａｔｉｏｎａｌ　Ｃｅｎｔｅｒ　ｆｏｒ　Ｓｕｐｅｒｃｏｍｐｕｔｉｎｇ　Ａｐｐｌｉｃａｔｉｏｎｓ）において開発されたＮＣＳＡ−ｈｔｔｐｄ１．３というプログラムを改良したＨＴＴＰサーバであって、現在、インターネット上で最も普及しているＨＴＴＰサーバである。
【００７５】
このＰＨＰの第４版であるＰＨＰ４においては、セッション機能がサポートされており、当該セッション機能を利用すれば、本発明を容易に実装することができる。この場合において、セッションＩＤは、Ｃｏｏｋｉｅ、またはＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）パラメータを用いてＷｅｂ端末側に保持される。また、ＰＨＰ４は、データベース・インタフェースを備えており、この点でも本発明の実施に好都合である。
【００７６】
更に、上記実施の形態において述べたタイムアウト処理についても、設定ファイルｐｈｐ．ｉｎｉにおいて、設定オプションｓｅｓｓｉｏｎ．ｇｃ＃ｍａｘｌｉｆｅｔｉｍｅで設定した時間が経過した変数を無効とし、削除対象とする機構がサポートされている。例えば、以下のように設定すると、セッション情報が最後に使用されてから１４４０秒後に無効とされる。
【００７７】
ｓｅｓｓｉｏｎ．ｇｃ＃ｍａｘｌｉｆｅｔｉｍｅ　＝　１４４０；
なお、セッションの有効期間をどの程度にするかは、コンテンツの内容に応じ、すべてのユーザについて一律に決めるとしても良いし、Ｗｅｂアクセスを要求するユーザとの契約に基づいてユーザ毎に決定するとしても良い。ただし、ＰＨＰでは、Ｗｅｂサーバ毎に上記ｓｅｓｓｉｏｎ．ｇｃ＃ｍａｘｌｉｆｅｔｉｍｅの設定を許す仕様となっているので、ユーザ毎に設定するなど、Ｗｅｂサーバ毎に設定しない場合には、然るべきプログラムを用意する必要がある。
【００７８】
このようなＰＨＰ４については、例えば、堀田倫英、石井達夫、廣川類、「ＰＨＰ４徹底攻略−Ｗｅｂとデータベースの連携プログラミング」、ソフトバンクパブリッシング社、２０００年、に詳しく紹介されている。
（４）　上記の実施の形態においては、認証設定情報記憶部２７に記憶されているセッション数の初期値をゼロとし、セッションＩＤを発行する毎にセッション確認部２４が当該セッション数を１ずつ増加させるとし、タイムアウトを検出する毎にタイムアウト処理部２２が当該セッション数を１ずつ減少させるとしたが、これに代えて次のようにするとしても良い。
【００７９】
すなわち、前記セッション数の初期値を最大セッション数として、セッションＩＤを発行する毎にセッション確認部２４が当該セッション数を１ずつ減少させるとし、タイムアウトを検出する毎にタイムアウト処理部２２が当該セッション数を１ずつ増加させるとしても良い。
この場合において、前記セッション数がゼロの場合には、新たなセッションＩＤの発行は行わないようにする。このようにしても、上記実施の形態と同様に本発明の効果を得ることができる。
【００８０】
（５）　上記実施の形態においては、タイムアウト処理部２２にて、タイムアウトの発生を検出したセッションを抹消するとしているが、これに加えて次のようにするとしても良い。
すなわち、Ｗｅｂ端末からセッション終了の通知を受けてセッションを抹消するとしても良い。このようにすれば、Ｗｅｂ端末にてユーザがコンテンツの利用を終了した後、タイムアウトが発生するまでの間、使用されないセッションが存在し続けるといった事態を回避することができる。
【００８１】
従って、使用されていないセッションがあるために、新たなＷｅｂアクセスの要求が拒絶されるといった不都合を解消して、より質の高いサービスを提供することができる。
（６）　本発明は、上記の実施の形態において説明したようなＷｅｂサーバ１４に代表されるコンテンツ閲覧制限装置であるとしても良いし、かかるコンテンツ閲覧制限装置が実行するコンテンツ閲覧制限方法であるとしても良い。また、当該コンテンツ閲覧制限方法をコンピュータに実行させるプログラムであるとしても良い。
【００８２】
ここで、当該コンテンツ閲覧制限プログラムはＣＤ−ＲＯＭその他の記録媒体に記録されて流通されて、コンピュータやコンピュータを内蔵した機器に導入されるとしても良い。更に、当該コンテンツ閲覧制限プログラムは、通信ネットワークを経由して配布されるとしても良い、上記のいずれの形態をとるにせよ本発明の技術的範囲に含まれることに変わりはない。
【００８３】
【発明の効果】
以上説明したように、本発明に係るコンテンツ閲覧制限装置によれば、認証情報を同じくするユーザからのアクセス要求に係る同時セッション数を制限するので、ユーザ毎に、コンテンツに対する同時アクセス数を制限することができる。また、本発明によれば、累積セッション数を制限するので、ユーザ毎にアクセス回数を制限することができる。
【００８４】
従って、コンテンツについてユーザ毎に閲覧有効期限を設けたり、同時にアクセス可能なユーザ数を管理、制限したりすることが可能となるので、これに応じて、きめ細かな課金設定を実現することができる。すなわち、コンテンツの利用実態に即したリーズナブルな課金が可能となるので、コンテンツを提供する事業者は、ユーザに不満感やストレスを与えることなく、合理的な収益をあげることができる。
【図面の簡単な説明】
【図１】典型的なコンテンツ閲覧制限システムの構成を示すシステム構成図であって、特に、ブラウザを搭載したＷｅｂ端末（Ｗｅｂクライアント）とＷｅｂサーバとをインターネット接続した場合について示している。
【図２】Ｗｅｂサーバ１４の機能構成を示す機能構成図である。
【図３】コンテンツ閲覧制限システム１における、Ｗｅｂ端末とＷｅｂサーバ１４の間の典型的な通信シーケンスの例を示す図である。
【図４】コンテンツ閲覧制限システム１における、Ｗｅｂ端末とＷｅｂサーバ１４の間の典型的な通信シーケンスの例であって、認証が失敗する場合の通信シーケンスを示す図である。
【図５】コンテンツ閲覧制限システム１における、Ｗｅｂ端末とＷｅｂサーバ１４の間の典型的な通信シーケンスの例であって、セッションＩＤの生成が失敗する場合の通信シーケンスを示す図である。
【図６】Ｗｅｂサーバ１４の処理の流れを表すフローチャートであって、特に、通信シーケンスに関わる処理を表わすフローチャートである。
【符号の説明】
１…………………コンテンツ閲覧制限システム
１０、１１、１２…Ｗｅｂ端末
１３…………………インターネット
１４…………………Ｗｅｂサーバ
２０…………………認証設定受付部
２１…………………アクセス要求受付部
２２…………………タイムアウト処理部
２３…………………ユーザ認証部
２４…………………セッション確認部
２５…………………セッション登録部
２６…………………コンテンツ送信部
２７…………………認証設定情報記憶部
２８…………………コンテンツ記憶部
【図１】
2004127172.tif 000003
【図２】
2004127172.tif 000004
【図３】
2004127172.tif 000005
【図４】
2004127172.tif 000006
【図５】
2004127172.tif 000007
【図６】
2004127172.tif 000008