(57)【特許請求の範囲】
【請求項１】
ネットワーク上のリソースに対する処理を実行するためのセッション管理方法であって、
ユーザシステムからの前記処理のリクエストを受け取るステップと、
前記リクエストの対象となるリソースに架空ディレクトリ名が含まれるか否かを判断するステップと、
前記判断ステップにおいて前記架空ディレクトリ名が含まれると判断される場合には、前記架空ディレクトリ名に関連付けて記録されている実体ディレクトリ名に当該架空ディレクトリ名を置き換えるステップと、
前記リクエストに、前記架空ディレクトリ名に関連付けて記録されている前記ユーザシステム毎のクッキーを付加するステップと、
そのリソースが前記実体ディレクトリ名に置き換えられ、前記クッキーが付加されたリクエストを、当該リソースを保持するサーバに送信するステップと、
前記リクエストに対するレスポンスを前記サーバから受け取るステップと、
前記レスポンスに前記クッキーを書き換える要求が含まれる場合には、前記クッキーを更新するステップと、
前記レスポンスを前記ユーザシステムに送信するステップと、
を含むセッション管理方法。
【請求項２】
前提として、前記ユーザシステムからのリクエストに応答してセッションを開始するステップをさらに含み、前記セッションを開始するステップには、
既発行の架空ディレクトリ名以外の架空ディレクトリ名を発行するステップと、
前記架空ディレクトリ名に関連付けて前記ユーザシステム毎のクッキーを生成するステップと、
前記セッションを開始する際のリクエストに応答すべきリソースが記録されている実体ディレクトリ名を前記架空ディレクトリ名で置き換えるステップと、
前記架空ディレクトリ名に置き換えられたリソースのロケーション情報を含むレスポンスを生成するステップと、を含み、
前記ロケーション情報を含むレスポンスは、前記レスポンスを受けた前記ユーザシステムが、前記ロケーション情報で特定されるリソースにリダイレクトするものである請求項１記載のセッション管理方法。
【請求項３】
前記架空ディレクトリ名は、所定の有効期限内において前記ユーザシステムを一意に表すものである請求項１記載のセッション管理方法。
【請求項４】
前記実体ディレクトリ名によるリソースは、外部からの直接アクセスが制限されている請求項１記載のセッション管理方法。
【請求項５】
前記実体ディレクトリ名によるリソースに含まれるリンク情報は、相対パスを用いて記述されている請求項１記載のセッション管理方法。
【請求項６】
ネットワーク上のリソースに対する処理を実行するためのセッション管理システムであって、
ユーザシステムからの前記処理のリクエストを受け取る手段と、
前記リクエストの対象となるリソースに架空ディレクトリ名が含まれるか否かを判断する手段と、
前記判断手段において前記架空ディレクトリ名が含まれると判断される場合には、前記架空ディレクトリ名に関連付けて記録されている実体ディレクトリ名に当該架空ディレクトリ名を置き換える手段と、
前記リクエストに、前記架空ディレクトリ名に関連付けて記録されている前記ユーザシステム毎のクッキーを付加する手段と、
そのリソースが前記実体ディレクトリ名に置き換えられ、前記クッキーが付加されたリクエストを、当該リソースを保持するサーバに送信する手段と、
前記リクエストに対するレスポンスを前記サーバから受け取る手段と、
前記レスポンスに前記クッキーを書き換える要求が含まれる場合には、前記クッキーを更新する手段と、
前記レスポンスを前記ユーザシステムに送信する手段と、
を含むセッション管理システム。
【請求項７】
前提として、前記ユーザシステムからのリクエストに応答してセッションを開始する手段をさらに含み、前記セッションを開始する手段には、
既発行の架空ディレクトリ名以外の架空ディレクトリ名を発行する手段と、
前記架空ディレクトリ名に関連付けて前記ユーザシステム毎のクッキーを生成する手段と、
前記セッションを開始する際のリクエストに応答すべきリソースが記録されている実体ディレクトリ名を前記架空ディレクトリ名で置き換える手段と、
前記架空ディレクトリ名に置き換えられたリソースのロケーション情報を含むレスポンスを生成する手段と、を含み、
前記ロケーション情報を含むレスポンスは、前記レスポンスを受けた前記ユーザシステムが、前記ロケーション情報で特定されるリソースにリダイレクトするものである請求項６記載のセッション管理システム。
【請求項８】
前記架空ディレクトリ名は、所定の有効期限内において前記ユーザシステムを一意に表すものである請求項６記載のセッション管理システム。
【請求項９】
前記実体ディレクトリ名によるリソースは、外部からの直接アクセスが制限されている請求項６記載のセッション管理システム。
【請求項１０】
前記実体ディレクトリ名によるリソースに含まれるリンク情報は、相対パスを用いて記述されている請求項６記載のセッション管理システム。
【請求項１１】
ネットワーク上のリソースに対する処理を実行するためのプログラムであって、
ユーザシステムからの前記処理のリクエストを受け取る手順と、
前記リクエストの対象となるリソースに架空ディレクトリ名が含まれるか否かを判断する手順と、
前記判断手順において前記架空ディレクトリ名が含まれると判断される場合には、前記架空ディレクトリ名に関連付けて記録されている実体ディレクトリ名に当該架空ディレクトリ名を置き換える手順と、
前記リクエストに、前記架空ディレクトリ名に関連付けて記録されている前記ユーザシステム毎のクッキーを付加する手順と、
そのリソースが前記実体ディレクトリ名に置き換えられ、前記クッキーが付加されたリクエストを、当該リソースを保持するサーバに送信する手順と、
前記リクエストに対するレスポンスを前記サーバから受け取る手順と、
前記レスポンスに前記クッキーを書き換える要求が含まれる場合には、前記クッキーを更新する手順と、
前記レスポンスを前記ユーザシステムに送信する手順と、
をコンピュータに実行させるためのプログラム。
【請求項１２】
前提として、前記ユーザシステムからのリクエストに応答してセッションを開始する手順をさらにコンピュータに実行させ、前記セッションを開始する手順には、
既発行の架空ディレクトリ名以外の架空ディレクトリ名を発行する手順と、
前記架空ディレクトリ名に関連付けて前記ユーザシステム毎のクッキーを生成する手順と、
前記セッションを開始する際のリクエストに応答すべきリソースが記録されている実体ディレクトリ名を前記架空ディレクトリ名で置き換える手順と、
前記架空ディレクトリ名に置き換えられたリソースのロケーション情報を含むレスポンスを生成する手順と、を含み、
前記ロケーション情報を含むレスポンスは、前記レスポンスを受けた前記ユーザシステムが、前記ロケーション情報で特定されるリソースにリダイレクトするものである請求項１１記載のプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、インターネットにおけるセッション管理方法、セッション管理システム、およびプログラムに関する。特に、クッキー等既存のユーザ識別あるいはセッション管理手法を用いることができない環境においても、ページサイズを増加させず、またサイト制作者の負担を増加させずに簡便にユーザ識別あるいはセッション管理を実現できる手法に適用して有効な技術に関する。
【０００２】
【従来の技術】
ＨＴＭＬ（Hypertext Markup Language）等のページ記述言語で記述されたページファイルの転送に標準的に利用されるＨＴＴＰ（Hypertext Transfer Protocol）は、クライアントシステムからのリクエスト（処理要求）が一回ごとに完結するプロトコルである。つまり、継続したセッションの概念を持たず、一連のリクエストを関連付けて処理することができない。単純なニュースの配信や商品情報提供等の場合には、単にリクエストの発信元にコンテンツ（ページファイル）を返送するだけで処理を完了させてよい。しかし、たとえばショッピングサイトにおけるショッピングカート機能の実現やウェブページをユーザ毎にカスタマイズする等の機能を実現するには、複数ページにまたがる操作におけるユーザ（参照者）の追跡管理が必要である。つまり、何らかの手段でユーザを追跡し、セッション管理の概念を導入する必要がある。
【０００３】
発信元を特定するために、たとえばＩＰ（Internet Protocol）アドレスを利用することが考え得る。しかし、ＮＡＴ（Network Address Translator）、プロキシサーバ、あるいはゲートウェイ等アドレス変換手段を利用することは今日では一般的であり、発信元のＩＰアドレスが真に発信元を示しているとは限らない。
【０００４】
よって、一般的にはクッキーを用いたセッション管理の手法が活用される。クッキーは、ウェブサイトからクライアント側に送信される情報をクライアントシステムのハードディスク等に記録する情報ファイルである。セッションの開始時にウェブサイトはクライアントに対しセッションＩＤ等識別情報を発行し、クライアント側のブラウザはこの識別情報をクッキーに記録する。クライアントがクッキーを発行したウェブページに再度アクセスした場合、保存されているクッキーの情報がウェブサイトに送信される。ウェブサイト（サーバ側）ではこのクッキー情報を利用してセッション管理や利用者毎のカスタマイズ等を行うことができる。
【０００５】
ただしクッキーを利用するには、ブラウザの稼働するクライアント側システムが、パーソナルコンピュータ等十分な記録領域（ハードウェア資源）を備える必要がある。しかしながら、たとえば携帯電話等メモリ領域が十分でない携帯端末の場合にはクッキーが利用できない場合がある。また、ブラウザ自体にクッキーの機能を備えない場合もある。さらに、ユーザがクッキーの利用を禁止する場合もある。クッキーにはユーザがそれと認識しないうちに、サーバにより勝手に情報が送りつけられ、その情報がサーバによって利用されるため、ユーザによってはプライバシーやセキュリティの保護の観点からその利用を希望しない場合がある。このような場合ブラウザのユーザ設定によりクッキーの利用が禁止される場合がある。
【０００６】
このように、何らかの理由でクッキーが利用できない場合があるので、クッキーの利用を前提にウェブサイト側のページ設計を行うことはできない。そこで、クッキーが利用できない場合を想定したページ設計が必要になる。クッキーを用いないＨＴＴＰにおけるセッション管理の手法として以下のような方法が知られている。
【０００７】
第１の方法は、ウェブアプリケーションレベルでセッション管理を行う方法である。たとえば、ページ間を移動する度にセッション情報をＣＧＩ（common gateway interface）パラメータとして渡す方法が例示できる。たとえば、ログイン時にセッションＩＤを生成し、そのセッションＩＤをパラメータとして最初のページにリダイレクトする。ＣＧＩはパラメータとして渡されたセッションＩＤを受け取り、ＣＧＩによってインタフェイスされたサーバ側のプログラムはセッションＩＤが埋め込まれたハイパーリンクを含むページを動的に生成する。生成されたページに含まれるハイパーリンクにはセッションＩＤがＣＧＩパラメータとして含まれるため、ユーザが次のリンク移動（ハイパーリンクの選択操作）を行う際に同様にセッションＩＤが渡される。このように一連のリンク移動に渡って固有のセッションＩＤが保持され、必要に応じてセッションＩＤを参照してユーザの追跡管理が行える。
【０００８】
第２の方法は、ウェブサーバの基本機能としてセッションＩＤを渡す処理を組み込む方法である。たとえばハイパーリンクのＵＲＬ（Uniform Resource Locator）末尾に識別情報（セッションＩＤ）を追加し、識別情報の取り出しはウェブサーバによって自動的に行う手法である。Ａｐａｃｈｅウェブサーバ等のウェブサーバでは、Ｊａｖａサーブレットを使用してウェブページを構築できるように設計されている。これらサーバでは、セッションＩＤをリンク先ＵＲＬの末尾に埋め込み、また、ページアクセス時のＵＲＬからセッションＩＤを取り出す機能、つまりＵＲＬリライティング機能が提供されている。このＵＲＬリライティング機能を利用すれば、前記第１の方法と同様にリンクページ間でのセッションＩＤの引き渡しが可能になり、ウェブアプリケーションではセッションＩＤの引き渡しを意識することなく動作が可能になる。なお、Ｊａｖａはサンマイクロシステムズ社の商標である。
【０００９】
【発明が解決しようとする課題】
前記したとおり、クッキーが利用できない環境でも、前記第１あるいは第２の方法を用いてセッション管理を行うことは可能である。しかし、これら既存の方法では、以下のような問題がある。
【００１０】
第１に、前記第１の方法あるいは第２の方法は、それを実現する機能を備えた技術の使用を前提とするページ設計が必要になる。たとえば、前記第１の方法の場合には、ＣＧＩパラメータの受け渡しができるようにページを設計する必要がある。前記第２の方法の場合には、リンク先ＵＲＬを必ずEncodeURL関数の戻り値とする必要があるのでＪＳＰ（Java Server Pages）の使用が前提となる。仮に静的ページによって既にウェブサイトが構成されている場合には、このような技術を前提としたページの再構築が必要になる。これらページの再構築はページ設計者の負担を増大する。
【００１１】
第２に、前記第１の方法および第２の方法の双方とも、セッションＩＤをリンク先のページに引き渡すために、サーバ側で動的にページを生成する必要がある。たとえば、単純な目次ページや商品紹介のページ等、特にユーザ毎の処理を行う必要が無いページ、つまり静的ページで十分にその目的が達成できるページにおいても、リクエストの度に動的なページを生成する必要がある。動的ページを取り扱う場合、以下のような不利益がある。つまり、リクエストの度に動的ページを生成するので、ページ生成処理を行うサーバの負担が大きくなる。また、ページ内の各リンクにセッションＩＤが含まれることになるので、ページサイズが増大する。仮にセッションＩＤのサイズが３０バイトであるとすると、ページ内に１０個のリンクが存在すれば３００バイト、１００個のリンクが存在すれば３０００バイトのサイズ増加を来たす。ページダウンロードの通信費用がユーザの負担になる場合はユーザの課金状況にも影響し、ユーザの利便性を図ることの障害要因になり得る。
【００１２】
第３に、たとえばユーザ端末がｉモード携帯電話のような場合、非公式サイトではセッションＩＤが送付されず、またクッキーも使用することができない。よってこのような端末からのセッション管理には前記した第１あるいは第２の方法を使用せざるを得ない。しかし、たとえばｉモード端末ではＨＴＭＬのサブセットであるコンパクトＨＴＭＬを用いる必要があるため、既存手法を簡便に用いるにはページサイズの制約が大きく障壁が高い。よって、さらに単純なセッション管理の手法が必要である。
【００１３】
本発明の目的は、極めて簡便なセッション管理手法、静的ページの利用が可能なセッション管理手法、既に構築されたウェブサイトの再構築負担を最小限に抑制したセッション管理手法、サーバの負担を軽減するセッション管理手法、ウェブページのページサイズが増大しないセッション管理手法、あるいは、ｉモード携帯端末のような機能が制限された環境においても簡便に実現できるセッション管理手法、を提供することにある。
【００１４】
【課題を解決するための手段】
本願の発明の概略を説明すれば、以下の通りである。すなわち、本願発明のセッション管理方法では、セッションの開始時に架空ディレクトリ名を発行し、その架空ディレクトリ名以下に位置するページにリダイレクトするように構成する。この架空ディレクトリは実際には存在せず、実体ディレクトリはサーバ内の他のディレクトリに存在させる。そして、セッションの追跡中はこの架空ディレクトリ以下の実体ディレクトリ内を移動するようにページを構築し、架空ディレクトリ名でアクセスしているユーザを特定するように構成する。なお、架空ディレクトリ以下に存在するように構成した実体ディレクトリ内の移動（つまりセッション管理中の移動）は相対パスによってリンク移動するように構成する。つまり見かけ上ユーザ毎に異なるパス（架空ディレクトリが異なる）に位置するファイルを参照することになるが、実際には同一のパス構造を有する実体ディレクトリ下のファイルを参照することになる。これにより、サーバ内の実体ディレクトリ以下のファイルは単純な静的ページを用いることができ、一方ユーザの追跡管理は架空ディレクトリを参照することにより行える。
【００１５】
本発明を列記すれば、以下のとおりである。本発明のセッション管理方法は、ネットワーク上のリソースに対する処理を実行するためのセッション管理方法であって、ユーザシステムからの処理のリクエストを受け取るステップと、リクエストの対象となるリソースに架空ディレクトリ名が含まれるか否かを判断するステップと、前記判断ステップにおいて架空ディレクトリ名が含まれると判断される場合には、架空ディレクトリ名に関連付けて記録されている実体ディレクトリ名に当該架空ディレクトリ名を置き換えるステップと、実体ディレクトリ名に置き換えられたリソースに対する処理結果のレスポンスをユーザシステムに送信するステップと、を含み、前記レスポンスの生成に際して、必要がある場合には架空ディレクトリ名に関連付けて記録されているユーザ識別情報もしくはセッション識別情報またはその両方を参照するものである。また、前提として、ユーザシステムからのリクエストに応答してセッションを開始するステップをさらに含み、セッションを開始するステップには、既発行の架空ディレクトリ名以外の架空ディレクトリ名を発行するステップと、セッションの識別情報もしくはユーザの識別情報またはその両方、架空ディレクトリ名、および、セッションを開始する際のリクエストに応答すべきリソースが記録されている実体ディレクトリ名を関連付けて記録するステップと、実体ディレクトリ名を架空ディレクトリ名で置き換えるステップと、架空ディレクトリ名に置き換えられたリソースのロケーション情報を含むレスポンスを生成するステップと、を含み、ロケーション情報を含むレスポンスは、レスポンスを受けたユーザシステムが、ロケーション情報で特定されるリソースにリダイレクトするものである。このようなセッション管理方法によれば、ユーザ毎の架空ディレクトリによりユーザを特定し、セッション内でのユーザの追跡管理を行える。架空ディレクトリをセッション管理情報として用いることによりＣＧＩやＪＳＰを前提とした動的ページを構成する必要がなく、セッション管理が必要な単純なページには静的ページを適用できる。
【００１６】
あるいは、本発明のセッション管理方法は、ネットワーク上のリソースに対する処理を実行するためのセッション管理方法であって、ユーザシステムからの処理のリクエストを受け取るステップと、リクエストの対象となるリソースに架空ディレクトリ名が含まれるか否かを判断するステップと、前記判断ステップにおいて架空ディレクトリ名が含まれると判断される場合には、架空ディレクトリ名に関連付けて記録されている実体ディレクトリ名に当該架空ディレクトリ名を置き換えるステップと、リクエストに、架空ディレクトリ名に関連付けて記録されているユーザシステム毎のクッキーを付加するステップと、そのリソースが実体ディレクトリ名に置き換えられ、クッキーが付加されたリクエストを、当該リソースを保持するサーバに送信するステップと、リクエストに対するレスポンスをサーバから受け取るステップと、レスポンスにクッキーを書き換える要求が含まれる場合には、クッキーを更新するステップと、レスポンスをユーザシステムに送信するステップと、を含む。また、前提として、ユーザシステムからのリクエストに応答してセッションを開始するステップをさらに含み、セッションを開始するステップには、既発行の架空ディレクトリ名以外の架空ディレクトリ名を発行するステップと、架空ディレクトリ名に関連付けてユーザシステム毎のクッキーを生成するステップと、セッションを開始する際のリクエストに応答すべきリソースが記録されている実体ディレクトリ名を架空ディレクトリ名で置き換えるステップと、架空ディレクトリ名に置き換えられたリソースのロケーション情報を含むレスポンスを生成するステップと、を含み、ロケーション情報を含むレスポンスは、レスポンスを受けたユーザシステムが、ロケーション情報で特定されるリソースにリダイレクトするものである。このようなセッション管理方法は、たとえばプロキシサーバやゲートウェイで実現できる。クッキーを有さない端末からのリクエストに対し、これら端末のセッション管理を前記同様に架空ディレクトリにより行う。この場合、プロキシサーバ等の内部にクッキーを定義し、セッションごとに固有のクッキーを管理する。このような方法を適用すれば、ウェブサーバ側ではクッキーの利用を前提としたページ構築が可能になり、クッキーが利用できない端末に対しても既に構築されているクッキー利用を前提としたウェブサーバでのサービスが可能になる。
【００１７】
なお、前記セッション管理方法において、架空ディレクトリ名は、所定の有効期限内においてユーザシステムを一意に表すものとすることができる。また、実体ディレクトリ名によるリソースは、外部からの直接アクセスが制限されているものとすることができる。これにより架空ディレクトを含むＵＲＬをたとえばブックマークやお気に入りフォルダに記録し、有効期限内ではそのセッションを継続することができるような柔軟な運用が可能になる。また、１ユーザに対して１つの架空ディレクトリを保証でき、架空ディレクトリとして容易に推定できないような名前を用いれば他のユーザによる意図的または偶発的なアクセスを制限できる。
【００１８】
また、実体ディレクトリ名によるリソースに含まれるリンク情報は、相対パスを用いて記述することができる。これにより架空ディレクトリ以下の実体ディレクトリはセッション情報を考慮して構築する必要がなく、設計者の負担を軽減できる。
なお、本発明は、前記した方法の発明に限らず、システムあるいはプログラムの発明として把握することも可能である。
【００１９】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。ただし、本発明は多くの異なる態様で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。なお、実施の形態の全体を通して同じ要素には同じ番号を付するものとする。
【００２０】
以下の実施の形態では、主に方法またはシステムについて説明するが、当業者であれば明らかなとおり、本発明はコンピュータで使用可能なプログラムとしても実施できる。したがって、本発明は、ハードウェアとしての実施形態、ソフトウェアとしての実施形態またはソフトウェアとハードウェアとの組合せの実施形態をとることができる。プログラムは、ハードディスク、ＣＤ−ＲＯＭ、光記憶装置または磁気記憶装置等の任意のコンピュータ可読媒体に記録できる。
【００２１】
また以下の実施の形態では、ウェブサーバあるいはプロキシサーバのシステムとして、一般的なコンピュータシステムを用いることができる。実施の形態で用いることができるコンピュータシステムは、中央演算処理装置（ＣＰＵ）、主記憶装置（メインメモリ：ＲＡＭ）、不揮発性記憶装置（ＲＯＭ）、コプロセッサ、画像アクセラレータ、キャッシュメモリ、入出力制御装置（Ｉ／Ｏ）等、一般的にコンピュータシステムに備えられるハードウェア資源を備える。また、ハードディスク装置等の外部記憶装置、インターネット等のネットワークに接続可能な通信手段を備える。コンピュータシステムには、パーソナルコンピュータ、ワークステーション、メインフレームコンピュータ等各種のコンピュータが含まれる。
【００２２】
（実施の形態１）
図１は、本発明の一実施の形態であるセッション管理方法が適用できるネットワークシステムの一例を示した概念図である。図示するネットワークシステムは、インターネット１にサーバシステム２と、クライアントであるコンピュータシステム３、携帯電話４およびＰＤＡ（personal digital assistants）５とが接続された構成を有する。
【００２３】
インターネット１は、たとえばＴＣＰ／ＩＰ（transmission control protocol / internet protocol）を利用してシステム間のトランスポート層での通信コネクションを確立する。本明細書において、インターネットには企業等グループ内で閉じたネットワークを構成するイントラネットも含む。また、以下に説明するＨＴＴＰは一般にＴＣＰ／ＩＰ上で利用されるが、ある程度信頼できるトランスポート層を構成できる限りＴＣＰ／ＩＰを前提とするわけではない。よって、本発明のセッション管理方法は、インターネット１を前提にするものではない。インターネット１は、本発明のセッション管理方法の実現に適したネットワークシステムの一例であり、その他のプロトコルによってトランスポート層が構成されてもよい。なお、本明細書において、ＨＴＴＰにはＨＴＴＰＳを含むものとする。
【００２４】
サーバシステム２は、コンピュータシステム３等クライアントからのリクエストを受けて、所定の処理（メソッド）を実行し、その結果をレスポンスとして返す情報処理システムである。本実施の形態で例示するＨＴＴＰの場合、Ａｐａｃｈｅ等のウェブサーバ機能を有する。また、以下に説明するように本実施の形態のセッション管理方法を実現する機能を備える。なお、サーバシステムの数は図示する数には限られない。サーバシステムは単一のハードウェアシステムとして実現されても良く、複数のハードウェアシステムによって分散的に実現されても良い。
【００２５】
コンピュータシステム３、携帯電話４およびＰＤＡ５は、サーバシステム２にリクエストを発し、サーバシステム２からのレスポンスを受け取るクライアントシステムである。コンピュータシステム３、携帯電話４およびＰＤＡ５は、レスポンスに含まれるＨＴＭＬ等エンティティボディの内容を解析し、これを表示等するユーザエージェント機能を持つ。代表的なユーザエージェントにウェブブラウザを例示できる。なお、コンピュータシステム３、携帯電話４およびＰＤＡ５はクライアントの例示であり、その他の情報機器がクライアントとして機能しても良い。また、クライアントのシステムおよびサーバシステムは図示する数には限られない。
【００２６】
クライアントシステム（コンピュータシステム３、携帯電話４およびＰＤＡ５）には、一般的なウェブブラウザあるいはｉモード携帯電話のようにコンパクトＨＴＭＬ文書を表示できる専用または汎用のブラウザを備えることができる。本実施の形態のセッション管理方法は、クッキーが使用できない携帯電話４等ハードウェア資源に乏しいクライアントシステムに適用して有用なものである。しかし、クッキーが使用できる、できないに関わらず本実施の形態の方法を適用できる。よって本発明をクッキーが使用できないクライアントシステムに限定して解釈するべきではない。すなわち、ＨＴＴＰリクエストを発することができ、そのレスポンスを処理できるシステムである限り本発明のクライアントシステムとすることができる。
【００２７】
なお、本実施の形態では、クライアントシステムのユーザエージェントとしてブラウザを例示する。しかし、ユーザエージェントはブラウザに限られず、ＨＴＴＰを利用できるクライアント側のソフトウェアあるいはシステムの全てを含む。
【００２８】
図１での図示および以下の説明では、サーバシステム２、コンピュータシステム３、携帯電話４およびＰＤＡ５とインターネット１との通信接続手段についての説明を省略する。一般的なハードウェアあるいはソフトウェア的な接続手段を有していることは言うまでもない。また、通信接続手段は有線、無線を問わない。
【００２９】
図２は、本実施の形態のセッション管理システムで利用できるクライアントシステムおよびサーバシステムの一例をその機能について示したブロック図である。図示するサーバシステム１０およびクライアントシステム１１は、以下の構成を有する。
【００３０】
サーバシステム１０には、ログインモジュール１３、ユーザ管理データベース１４、セッション管理データベース１５、ディレクトリ名変換モジュール１６、ウェブサーバ１７、ウェブページファイル１８を含む。また、クライアントシステム１１には、ブラウザ１２を含む。
【００３１】
ブラウザ１２は、前記した通り、ＨＴＭＬ等ページ記述言語で記述された文書を解析し、これを表示する機能を持つ。また、ページ内にたとえばアンカータグによって埋め込まれたハイパーリンクを選択することにより、指定されたリソースの取得要求等ＨＴＴＰメソッドを実行する。また、実行環境が整っている場合には、Ｊａｖａアプレット等プログラムを受け取り、これを実行する機能を持つ。
【００３２】
ログインモジュール１３は、クライアントからのログイン要求を受けて、後に説明するセッション開始処理を行う。また必要な場合はユーザ認証を行い、許可された場合にのみセッションの開始を行う。なお、ユーザ認証は本発明に必須の要件ではない。ユーザ認証を行わずに無条件でセッションを開始することもできる。
【００３３】
ユーザ管理データベース１４は、ユーザ認証を行う際に用いるユーザＩＤ、パスワード等を記録する。その他ユーザに関する情報を記録しても良い。
【００３４】
セッション管理データベース１５は、後に説明するように、セッションの開始によって生成された架空ディレクトリをセッションＩＤと関連付けて記録する。また、セッションＩＤには、そのユーザが参照するファイルが実際に記録されている実体ディレクトリを架空ディレクトリに関連付けて記録する。架空ディレクトリはそのセッションのために生成された架空のディレクトリであり実際に存在するものではない。ただし、後に説明するように、リクエストを受けたサーバはユーザからはあたかもそのようなディレクトリが実在するかのように振る舞う。なお、セッション管理データベース１５には、セッションＩＤ等と関連付けてユーザＩＤが記録されても良い。
【００３５】
ディレクトリ名変換モジュール１６は、ユーザからのリクエストを受け、そのリクエストに含まれるリソースのディレクトリ名を変換する機能を持つ。ユーザからのリクエストに含まれるディレクトリ名は、後に説明するように架空ディレクトリ名である。この架空ディレクトリ名の部分を検出し、実体ディレクトリ名に変換する。架空ディレクトリ名から実体ディレクトリ名への変換は、セッション管理データベース１５を参照して行う。受け取ったリクエストに含まれる架空ディレクトリ名に関連付けられている実体ディレクトリ名を、セッション管理データベース１５を検索して取得し、架空ディレクトリ名の部分を検索取得した実体ディレクトリ名で置き換える。
【００３６】
ウェブサーバ１７は、Ａｐａｃｈｅ等一般的なウェブサーバ機能を実現する各種コンポーネントからなるソフトウェア群である。良く知られているように、ユーザからのリクエストを受けて、このリクエストに含まれるリソースに対し、リクエストで指定されたメソッド（たとえばＧＥＴメソッドであればリソースを読み出しユーザに返送する）を実行する。なお、各種パラメータを生成しヘッダに含める機能を持つことは勿論である。また、ＣＧＩを介してプログラムを実行し、動的ファイルを生成する機能を有しても良い。
【００３７】
ウェブページファイル１８は、ユーザからのリクエストによってメソッドの対象になる実際のリソースである。たとえば、ＨＴＭＬやＸＭＬ等ページ記述言語で記述されたファイルである。なお、ウェブページファイル１８には、ウェブページで利用される画像ファイルやＪａｖａアプレットのようなプログラム等ページの部品も含まれる。ウェブページファイル１８は、ディレクトリ構造によって構造化され、一般公開ディレクトリ１９と保護ディレクトリ２０を持つ。
【００３８】
図３は、一般公開ディレクトリ１９と保護ディレクトリ２０とのディレクトリ構造の一例を示した概念図である。「／」で示すルートディレクトリの下に、一般公開ディレクトリ１９と保護ディレクトリ２０が設けられている。一般公開ディレクトリ１９は、外部からのアクセス制限がなく、一般に公開されるディレクトリである。「／ｉｍａｇｅ」で示すディレクトリ下にはたとえばウェブページで利用されるイメージデータファイルが記録される。「／ｐｕｂｌｉｃ」ディレクトリの下には一般に公開される汎用ファイルが記録される。「／ｌｏｇｉｎ」ディレクトリの下にはログイン処理に必要とされるファイルが記録される。また、「／ＳＥＣＤＩＲ−ｘｘｘｘ」、「／ＳＥＣＤＩＲ−ｙｙｙｙ」は架空ディレクトリである。この架空ディレクトリは、実際には存在せず、後に説明するように実体ディレクトリに変換される。保護ディレクトリ２０は、外部からの直接アクセスが制限されるディレクトリであり、ユーザからのリクエストの対象であるリソースが実際に記録されている。図示するように「／ＳＥＣＤＩＲ−・・・・」と同じ深さで「／ｓｅｃｕｒｅ」あるいは「／ｓｅｃｕｒｅ２」ディレクトリが配置され、その下のディレクトリは任意に構成される。なお、「／ｓｅｃｕｒｅ」あるいは「／ｓｅｃｕｒｅ２」以下のページファイルでそのディレクトリ下の他の実体ディレクトリにハイパーリンクを張る際には、相対ディレクトリでリンク先のリソースが指定される。このように相対ディレクトリで記述することにより、親ディレクトリ名が架空ディレクトリ名に置き換えられたとしても、親ディレクトリ（「／ｓｅｃｕｒｅ」あるいは「／ｓｅｃｕｒｅ２」）以下の相対ディレクトリで記述されているページファイル間では、ハイパーリンクのリソース名（ディレクトリ名）を親ディレクトリ名毎に変更する必要がない。これにより、既に構築されているウェブページファイルの流用を可能にし、また、ページファイルの構築を容易にする。
【００３９】
なお、図２においてウェブページファイル１８はサーバシステム１０内に記録されているように図示されている。しかし、ウェブページファイル１８が記録される場所はサーバシステム１０内に限られず、インターネット等通信ネットワークで接続された他のシステム内であってもよい。ただしＩＰアドレス等適切なアドレス特定手段によって記録場所が特定できる必要がある。また、ウェブページファイル１８の物理的な記録媒体として、ハードディスクドライブ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等の光あるいは光磁気記録媒体、磁気テープ、半導体装置等を例示できる。
【００４０】
図４は、本実施の形態のセッション管理方法におけるセッション開始の手順の一例を示したフローチャートである。図４において左側に示した各処理はクライアントシステムにおける操作または処理であり、右側はサーバシステムにおける処理である。
【００４１】
まずクライアントシステム１１はサーバシステム１０に対し、ログイン要求を送信する（ステップ３０）。ログイン要求は、たとえばサーバシステムの／ｌｏｇｉｎディレクトリ以下に記録されている特定のファイルのＧＥＴ要求である。ログイン要求を受けたサーバシステムはログイン用ファイルをクライアントに返送する（ステップ３１）。ログイン用ファイルには、たとえばユーザ識別用のＩＤおよび認証用のパスワードを入力する入力フィールドを有する。ログインファイルを受信したクライアントシステムはログイン画面を表示し、ユーザは前記フィールドに必要事項を入力し、これを送信する（ステップ３２）。サーバはユーザＩＤおよびパスワードを受信し（ステップ３３）、ユーザ管理データベース１４を参照して認証を行う（ステップ３４）。認証に成功した場合、サーバはステップ３６のセッション開始処理を行い、失敗した場合エラー処理を行う（ステップ３５）。
【００４２】
セッション開始処理（ステップ３６）は以下のステップからなる。まず、ユーザＩＤ、セッションＩＤ、および架空ディレクトリ名を生成する（ステップ３７）。ユーザＩＤは前記認証に用いたユーザＩＤを適用できる。セッションＩＤは、現在有効なセッションと区別するためのＩＤであり、現在有効な発行済みのセッションＩＤ以外の番号等を割り当てる。架空ディレクトリ名は、セッションＩＤと関連付ける架空のディレクトリ名である。本実施の形態では、この架空ディレクトリ名によってページ間移動の際のユーザの追跡を行う。また、架空ディレクトリ名は、前記したように「／ＳＥＣＤＩＲ−ｘｘｘｘ」のように表し、架空ディレクトリ名であることがわかる部分「ＳＥＣＤＩＲ−」とセッション毎に個別に生成する部分「ｘｘｘｘ」の部分よりなる。セッション毎に個別に生成する部分は、文字、数字、記号等の組合せであり、十分な長さを持つものである。少なくともセッションが有効な期間では、ユーザを一意に表すものであり、他者によって容易に推定できないものとする。これにより、セッションが有効な期間内での架空ディレクトリの重複を防止し、また、誤って、あるいは故意に他のユーザから特定のセッションで参照するウェブファイルにアクセスできないようにする。
【００４３】
次に、ユーザがアクセスしようとするページファイルの実体が記録されている実体ディレクトリ名を特定する（ステップ３８）。たとえば図３の例の場合、「／ｓｅｃｕｒｅ」ディレクトリや「／ｓｅｃｕｒｅ２」ディレクトリである。その後、関連付けたユーザＩＤ、セッションＩＤ、架空ディレクトリ名、実体ディレクトリ名をテーブルに記録する（ステップ３９）。表１は、生成されたテーブルの一例を示す表である。
【００４４】
【表１】
0003807961.tif 000002
このように、ログインの段階で、ユーザ毎に何れの実体ディレクトリにアクセスするかを制御できるので、ユーザ毎のカスタマイズ等柔軟なサーバの運用が可能になる。なお、生成されたテーブルはセッション管理データベース１５に記録される。
【００４５】
次に、サーバは、架空ディレクトリ名によるアクセスファイル（リソース）のロケーション指定を行い（ステップ４０）、クライアントからのリダイレクト要求となるようにステータスコードを３００番台に設定してレスポンスを送信する（ステップ４１）。レスポンスを受け取ったクライアントは、ロケーションで指定されたリソース、つまり架空ディレクトリ名で記述されたＵＲＩ（Uniform Resource Identifiers）にリダイレクトする（ステップ４２）。これにより、以降のクライアントからの処理では、そのリクエストは架空ディレクトリ経由で行われることになり。サーバは必要に応じてこのディレクトリ名を参照することによりセッション管理が可能になる。
【００４６】
なお、前記セッション開始処理において、ステップ３１〜３４までの認証処理は特に必要ではない。このような認証を経なくても、ユーザからのセッション開始要求（最初のリクエスト）によって、無条件にセッション開始処理（ステップ３６）を開始しても良い。
【００４７】
図５は、本実施の形態のセッション管理方法におけるサーバ側でのリクエスト処理の一例を示したフローチャートである。サーバがユーザからのリクエストを受信し、このリクエストのリソースに架空ディレクトリ名が含まれるかを判断する（ステップ５１）。架空ディレクトリ名を含むかの判断は、架空ディレクトリ名を表す「／ＳＥＣＤＩＲ−」のキーワードが含まれるかを判断することにより容易に行える。架空ディレクトリ名を含む場合はステップ５５以下の処理に進み、含まない場合はステップ５２の判断を行う。ステップ５２ではリクエストのリソースが公開ディレクトリ以下に記録されているリソースであるかを判断し（ステップ５２）、公開ディレクトリ以下にリソースが見つかった場合は、そのリソースへのメソッドを実行する（ステップ５３）。たとえばＧＥＴメソッドであればリソースを取得し、クライアントに送信する。リソースが見つからない場合はエラー処理を行う（ステップ５４）。
【００４８】
ステップ５１で架空ディレクトリ名を含むと判断した場合、その架空ディレクトリ名を抽出し、セッション管理データベース１５を検索する（ステップ５５）。セッション管理データベース１５の前記テーブルに架空ディレクトリ名が存在するかを判断し（ステップ５６）、存在しない場合はエラー処理を行い（ステップ５７）、存在する場合は、そのテーブルに記録されている対応する実体ディレクトリ名に架空ディレクトリ名を置き換える（ステップ５８）。たとえば、前記表１の場合、ユーザＡからのリクエストは、ルートディレクトリのＵＲＬが「//www.ibm.com」であった場合、そのＨＴＴＰリクエストは、
http://www.ibm.com/SECDIR-X03MO1qnZdYdgyfeulPmQ/index.html
のようになる。この場合の架空ディレクトリ名「/SECDIR-X03MO1qnZdYdgyfeulPmQ」を、表１の実体ディレクトリ名「/secure」に置き換える。つまり、
http://www.ibm.com/secure/index.html
のように変換する。
【００４９】
このように変換されたリソースはサーバシステムに実際に記録されているものであり、この実体ディレクトリのリソースに対して、所定のメソッドを実行する（ステップ５９）。このメソッド実行の際に、セッションＩＤを参照する必要があるときにはセッション管理データベース１５を参照し、セッションＩＤを取得できる（ステップ６０）。このように、本実施の形態の方法では、架空ディレクトリ名を参照することによって、必要に応じてセッション管理を行える。なおメソッド実行の結果として、単にリソース（ページファイル）を読み出してクライアントに返送するだけでなく、動的にページを生成しても良いことは勿論である。
【００５０】
図６は、本実施の形態の方法をたとえばインターネットショッピングに適用した場合の処理の一例を示した図である。図６において左側はクライアント側の処理であり、右側はサーバ側の処理である。
【００５１】
まず、クライアント側からログイン要求を発する（ステップ７０）。このとき、リクエストに含まれるＵＲＩはたとえば「http://www.ibm.com/index.html」というＵＲＬである。このようなＵＲＩのリソースは前記したログイン用のディレクトリ下に記録されているとする。前記リクエストを受けたサーバ側では、前記した通りのログイン処理を行い、セッションを開始する（ステップ７１）。このサーバからのレスポンスは、ロケーションに「http://www.ibm.com/SECDIR-xxxx・・・・/index.html」を含むステータスコード３ｘｘのレスポンスである。クライアントは、受け取ったレスポンスのステータスコードが３ｘｘであり、そのロケーションにＵＲＩが指定されているので、このＵＲＩにリダイレクトする（ステップ７２）。すなわち、クライアントは「http://www.ibm.com/SECDIR-xxxx・・・・/index.html」にＧＥＴ要求を発する。この時点からセッションが開始することになる。リクエストを受けたサーバは前記したアドレス変換（ディレクトリ名の変換）を行い、「/secure/index.html」を取得してこれをクライアントに返送する（ステップ７３）。このときのステータスコードは２００である。クライアントは「/secure/index.html」を受け取ってこれを表示する（ステップ７４）。このページは、たとえばインターネットショッピングサイトの総合目次ページである。なお、このような一連のＨＴＴＰリクエストとそのレスポンスは一回限りで完結し、プロトコル上の接続は切断される。
【００５２】
次に、ユーザは、たとえば総合目次ページ内の「outdoor/index.html」リンク（アウトドア用品）を選択したとする。なお、ページ内のハイパーリンクは相対パスで記述されている。このため、「outdoor/index.html」リンクを選択した時点で、クライアントのブラウザでは、その親ディレクトリを変更すること無く、次のＨＴＴＰリクエストを発する（ステップ７５）。
【００５３】
「http://www.ibm.com/SECDIR-xxxx・・・・/outdoor/index.html」
このリクエストを受けたサーバは、前記したアドレス変換を行い、「/secure/outdoor/index.html」ファイルを取得してこれをクライアントに返送する（ステップ７６）。クライアントは「/secure/outdoor/index.html」ファイルを受け取ってアウトドア用品のページを表示する（ステップ７７）。なお、この段階におけるリクエストとそのレスポンスもこれが完結した時点でその接続は終了する。しかしながら、ステップ７５のリクエストが、ステップ７２のリクエスト（リダイレクト）に続く同一ユーザからのリクエストであることは、架空ディレクトリ名を参照すれば容易に判明する。一方、本実施の形態では、クッキーを利用したりハイパーリンクにユーザ情報あるいはセッション情報を埋め込んだりすることなくユーザの追跡が可能である。
【００５４】
同様に、アウトドア用品のページ内に埋め込んだ相対パス表記の「tent.html」（テント画面）をユーザが選択することにより（ステップ７８）、クライアントから「http://www.ibm.com/SECDIR-xxxx・・・・/outdoor/tent.html」のリクエストが発せられ、サーバはアドレス変換することにより「/secure/outdoor/tent.html」ファイルを返送する（ステップ７９）。クライアントは、これを受け取ってテント画面を表示する（ステップ８０）。
【００５５】
ここで、ユーザはこのテントを購入するとする。この場合、相対パス指定された「../order.html」リンクを選択することになる。なお「..」は相対的に一つ上の親ディレクトリであることを示す。相対パス指定されているので、クライアントからのリクエストは「http://www.ibm.com/SECDIR-xxxx・・・・/」の部分は変化せず、「http://www.ibm.com/SECDIR-xxxx・・・・/order.html」が発せられる（ステップ８１）。
【００５６】
前記同様にサーバではアドレス変換が行われ、「/secure/order.html」ファイルが返送される（ステップ８２）。なお、この際、サーバでは誰からの注文であるかを把握する必要がある。このため、ユーザを特定し、たとえばショッピングカートに注文内容を記録する必要がある。この際、ユーザはセッション管理データベースを参照して架空ディレクトリ名から検索し、ユーザを特定できる。
【００５７】
これら一連のリクエストおよびそのレスポンスの処理を任意回数繰り返した後、ユーザはチェックアウト処理「checkout.html」を選択したとする。なお、ここでは相対パス指定されるため、ハイパーリンクの記載は正確にはファイル名の前に親ディレクトリとの関係を示す記述が入る可能性がある。前記例では、現ディレクトリが/SECDIR-xxxx・・・・/である場合を示している。よって、ユーザからのリクエストは「http://www.ibm.com/SECDIR-xxxx・・・・/checkout.html」に対して発せられ、サーバはオーダーの集計処理を行う（ステップ８５）。このオーダー集計処理の際に、架空ディレクトリ「/SECDIR-xxxx・・・・」を参照して、セッションＩＤ、ユーザが特定されることは勿論である。オーダー処理の結果は動的ページとして「/secure/chekout.html」ファイルを生成し、これをクライアントに返送する（ステップ８５）。クライアントでは、チェックアウト画面としてこれを表示する（ステップ８６）。なお、この後、ユーザが「/SECDIR-xxxx・・・・」より上位のファイルを参照する動作を行った場合にはセッションが終了する。また、「/SECDIR-xxxx・・・・」より下位の操作を行う限り、同一セッションとして任意の処理を継続することができる。
【００５８】
本実施の形態のセッション管理システムおよび方法によれば、ＵＲＩに含まれる架空ディレクトリ名によってセッション管理を行う。このため、ページファイル内のハイパーリンクにユーザ情報あるいはセッション情報を含める必要がない。また、ユーザ情報あるいはセッション情報を含むようなハイパーリンクを動的に生成する必要もない。このため、サーバの負荷を軽減し、また、ページファイルのサイズを増大させることがない。よってページファイルの転送による通信負荷を軽減することもできる。また、本実施の形態では、ページファイルは静的なファイルでもよい。ただし、前記したようにページファイル内のハイパーリンクは相対パスで記述する必要がある。このような相対パスによる記述はウェブ構築の際に通常行われる手法であり、ウェブサーバ設計者の構築負荷を増加させるものではない。前記したように本実施の形態のウェブサーバでは静的なページファイルによってセッション管理が可能であるため既に構築した静的ページがある場合には既構築の静的ページを流用してセッション管理が必要なシステムを容易に構築できる。
【００５９】
なお、本実施の形態では、セッション管理にユーザＩＤおよびセッションＩＤを用いているが、何れか一方のＩＤで管理することが可能である。
【００６０】
また、本実施の形態の架空ディレクトリは、セッション管理が終了した時点で消去することも可能であるが、所定の時間これを有効に保持しても良い。この場合、ユーザはたとえばお気に入りやブックマークに架空ディレクトリ名によるＵＲＩを記録し、ログイン処理を省略して本サービスを開始することができる。架空ディレクトリ名の有効期間はサーバによって任意に設定でき、その柔軟な運用が可能になる。
【００６１】
また、前記例では、あるユーザの場合は「/secure」以下の実体ファイルにアクセスする例を説明したが、同時に他のユーザによって同じ実体ディレクトリ名以下のファイルが参照されても良い。さらに他のユーザには、異なる実体ディレクトリ名（たとえば「/secure2」）以下のファイルにアクセスさせるようにしても良い。ユーザ毎にアクセスする実体ファイルを変更することができ、たとえばユーザ毎のカスタマイズ等、サーバの柔軟な運用にも本発明を適用できる。
【００６２】
（実施の形態２）
図７は、他の実施の形態として、プロキシサーバによって本発明を実現する場合のシステム構成の一例を示したブロック図である。クライアントシステム１１、プロキシサーバ９０内のログインモジュール９３，ユーザ管理データベース９４、セッション管理データベース９５、ディレクトリ名変換モジュール９６については、実施の形態１の対応する構成と同様である。また、ウェブサーバ１００のウェブページファイル１８も実施の形態１と同様である。
【００６３】
本実施の形態のプロキシサーバ９０には、ディレクトリ名変換モジュールによって参照されるクッキー９７を有する。
【００６４】
図８は本実施の形態のセッション管理方法におけるセッション開始の手順の一例を示したフローチャートである。ステップ１１０〜ステップ１１９までの処理は実施の形態１における対応する処理と同様である。ただし、これら処理はウェブサーバで行われるではなく、プロキシサーバ９０によって行われる。また本実施の形態では、テーブル生成後、架空ディレクトリ名毎にクッキーを生成する（ステップ１２０）。生成されたクッキーはクッキー情報９７として記録される。
【００６５】
ステップ１２１〜ステップ１２３は、実施の形態１の対応するステップと同様である。
【００６６】
図９は、本実施の形態のセッション管理方法におけるプロキシサーバにおけるリクエスト処理の一例を示したフローチャートである。ステップ１３０〜ステップ１３６までの処理は実施の形態１の対応する処理とほぼ同様である。ただし、ステップ１３１において架空ディレクトリ名を含まないと判断した時には、ディレクトリ名の変換を行わず、そのままのＵＲＩでリソースへのメソッドを実行する（ステップ１３２）。リソースの存在可否は、プロキシサーバではなく、リソースが要求されるサーバで判断されることになる。
【００６７】
ステップ１３６で実施の形態１と同様に実体ディレクトリ名に変換された後、リクエストにクッキーを付加する（ステップ１３７）。クッキーは、セッション開始の際に生成されたものであり、予めサーバからの通知によってその内容が記録されているものとする。
【００６８】
クッキーが付加されたリクエストをサーバ１００に転送する（ステップ１３８）。サーバはリクエストを受け取り、所定のメソッドを実行する。このリクエストにはクッキー情報が付加されているので、サーバでは、クッキー情報を参照して通常通りのセッション管理が行える。処理結果はレスポンスとしてプロキシサーバ９０に返送される。
【００６９】
プロキシサーバ９０はサーバ１００からのレスポンスを受け取り（ステップ１３９）、クッキーの変更があるかを判断する（ステップ１４０）。変更がある場合はクッキーの内容を更新し（ステップ１４１）、その後、レスポンスをクライアントに転送する（ステップ１４２）。なお、この段階でのクッキーの内容の削除は必須ではない。ただし通信負荷軽減のため、クッキー内容はレスポンスから削除することが好ましい。
【００７０】
本実施の形態によれば、プロキシサーバ９０によってクライアントからのセッション管理を行う。このセッション管理の際、架空ディレクトリ名を用いる点は実施の形態１と同様である。そして、本実施の形態のプロキシでは、架空ディレクトリ名に関連付けてクッキーを保持する。このため、クライアントから見れば架空ディレクトリ名によるＵＲＩを参照しているように見え、一方サーバ１００から見ればクッキーを有するクライアントからのリクエストを受けているように見える。このようにプロキシサーバによっても本発明のセッション管理方法あるいはシステムを実現できる。なお、プロキシサーバはゲートウェイ等に置き換えることもできる。
【００７１】
以上、本発明者によってなされた発明を発明の実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更することが可能である。
【００７２】
【発明の効果】
本願で開示される発明のうち、代表的なものによって得られる効果は、以下の通りである。すなわち、極めて簡便なセッション管理手法を提供できる。また、静的ページの利用が可能なセッション管理手法を提供できる。また、既に構築されたウェブサイトの再構築負担を最小限に抑制したセッション管理手法を提供できる。また、サーバの負担を軽減するセッション管理手法を提供できる。また、ウェブページのページサイズが増大しないセッション管理手法を提供できる。また、ｉモード携帯端末のような機能が制限された環境においても簡便に実現できるセッション管理手法を提供できる。
【図面の簡単な説明】
【図１】本発明の一実施の形態であるセッション管理方法が適用できるネットワークシステムの一例を示した概念図である。
【図２】本実施の形態のセッション管理システムで利用できるクライアントシステムおよびサーバシステムの一例をその機能について示したブロック図である。
【図３】一般公開ディレクトリ１９と保護ディレクトリ２０とのディレクトリ構造の一例を示した概念図である。
【図４】本実施の形態のセッション管理方法におけるセッション開始の手順の一例を示したフローチャートである。
【図５】本実施の形態のセッション管理方法におけるサーバ側でのリクエスト処理の一例を示したフローチャートである。
【図６】本実施の形態の方法をたとえばインターネットショッピングに適用した場合の処理の一例を示した図である。
【図７】プロキシサーバによって本発明を実現する場合のシステム構成の一例を示したブロック図である。
【図８】本実施の形態のセッション管理方法におけるセッション開始の手順の一例を示したフローチャートである。
【図９】本実施の形態のセッション管理方法におけるプロキシサーバにおけるリクエスト処理の一例を示したフローチャートである。
【符号の説明】
１…インターネット、２…サーバシステム、３…コンピュータシステム、４…携帯電話、５…ＰＤＡ、１０…サーバシステム、１１…クライアントシステム、１２…ブラウザ、１３…ログインモジュール、１４…ユーザ管理データベース、１５…セッション管理データベース、１６…ディレクトリ名変換モジュール、１７…ウェブサーバ、１８…ウェブページファイル、１９…一般公開ディレクトリ、２０…保護ディレクトリ、９０…プロキシサーバ、９３…ログインモジュール、９４…ユーザ管理データベース、９５…セッション管理データベース、９６…ディレクトリ名変換モジュール、９７…クッキー、１００…ウェブサーバ。
【図１】
0003807961.tif 000003
【図２】
0003807961.tif 000004
【図３】
0003807961.tif 000005
【図４】
0003807961.tif 000006
【図５】
0003807961.tif 000007
【図６】
0003807961.tif 000008
【図７】
0003807961.tif 000009
【図８】
0003807961.tif 000010
【図９】
0003807961.tif 000011