(57)【要約】【課題】ユーザが参照している画面の情報と、処理対象となった情報とが一致し、かつ、ダブルクリックや複数画面を開いているときにも矛盾なく、ユーザのリクエストに応答する。【解決手段】クライアントマシンからの一連のリクエストおよび応答に関するセッションＩＤを保持するセッションオブジェクト２２が生成され、特定のリクエストに応答するために、セッションオブジェクト２２が、応答データおよびこれを一意的に特定するデータＩＤを生成し、データ記憶部１８に記憶される。クライアントマシンから、応答データからの異なるリクエストおよびそれに付与されたデータＩＤを受理すると、受理したデータＩＤと、一時的に記憶されたデータＩＤとを照合し、適切に照合できた場合に、セッションオブジェクト２２が、リクエストに応答した応答データを生成する。また、処理後の応答データを一意的に特定する新たなデータＩＤが生成される。【選択図】  図２
2004287899.tif 000002
【特許請求の範囲】
【請求項１】
クライアントマシンからのリクエストに応答して、所定の処理を実行して、処理結果を応答として、当該クライアントマシンに返送する情報処理方法であって、
サーバにおいて、クライアントマシンからの一連のリクエストおよび応答に関するセッションＩＤを保持するセッションオブジェクトを生成するステップと、
前記クライアントマシンからのリクエストに応答するために、前記セッションオブジェクトにおいて、応答データと、当該応答データを一意的に特定するデータＩＤとを生成するステップと、
前記応答データとデータＩＤとを前記クライアントマシンに伝達するとともに、当該データＩＤを、記憶手段に一時的に記憶するステップと、
前記クライアントマシンにおいて、前記応答データからの異なるリクエストに、当該応答データに関連したデータＩＤを付与して送信するステップと、
前記サーバにおいて、受理したデータＩＤと、前記記憶手段に一時的に記憶したデータＩＤとを照合し、適切に照合できた場合に、前記セッションオブジェクトにおいて、当該リクエストに応答した応答データを生成するステップと、
処理後の応答データを一意的に特定する新たなデータＩＤを生成するステップと、
いったん照合に利用されたデータＩＤを、当該照合以後のリクエストに応答した照合に利用しないようにするステップとを備えたことを特徴とする情報処理方法。
【請求項２】
前記照合に利用しないようにするステップが、
前記一時的に記憶したデータＩＤを消去するステップを有することを特徴とする請求項１に記載の情報処理方法。
【請求項３】
前記適切に照合できなかった場合に、前記リクエストに応答して、前記クライアントマシンにエラーメッセージを送信するステップを備えたことを特徴とする請求項２に記載の情報処理方法。
【請求項４】
前記照合に利用しないようにするステップが、
前記一時的に記憶したデータＩＤを移動させ、照合による確認済のデータＩＤとして、前記記憶手段の他の領域に記憶するステップを有することを特徴とする請求項１に記載の情報処理方法。
【請求項５】
さらに、受理したデータＩＤと、前記記憶手段に一時的に記憶したデータＩＤとを照合し、適切に照合ができなかった場合に、前記受理したデータＩＤと、前記確認済のデータＩＤとを二次的に照合するステップを備え、かつ、
適切に二次的照合ができた場合には、前記リクエストを無視し、その一方、適切に二次的照合ができなかった場合には、前記リクエストに応答して、前記クライアントにエラーメッセージを送信するステップを備えたことを特徴とする請求項４に記載の情報処理方法。
【請求項６】
クライアントマシンからのリクエストに応答して、所定の処理を実行して、処理結果を応答として、当該クライアントマシンに返送するためにサーバを動作させる情報処理プログラムであって、
クライアントマシンからの一連のリクエストおよび応答に関するセッションＩＤを保持するセッションオブジェクトを生成するステップと、
前記クライアントマシンからのリクエストに応答するために、前記セッションオブジェクトにおいて、応答データと、当該応答データを一意的に特定するデータＩＤとを生成するステップと、
前記応答データとデータＩＤとを前記クライアントマシンに伝達するとともに、当該データＩＤを、記憶手段に一時的に記憶するステップと、
前記クライアントマシンにおいて送信された、前記応答データからの異なるリクエストに、および、応答データに関連したデータＩＤを受理するステップと、
受理したデータＩＤと、前記記憶手段に一時的に記憶したデータＩＤとを照合し、適切に照合できた場合に、前記セッションオブジェクトにおいて、当該リクエストに応答した応答データを生成するステップと、
処理後の応答データを一意的に特定する新たなデータＩＤを生成するステップと、
いったん照合に利用されたデータＩＤを、当該照合以後のリクエストに応答した照合に利用しないようにするステップとを、前記コンピュータに実行させることを特徴とするプログラム。
【請求項７】
前記照合に利用しないようにするステップにおいて、
前記一時的に記憶したデータＩＤを消去するステップを、前記コンピュータに実行させることを特徴とする請求項６に記載のプログラム。
【請求項８】
前記適切に照合できなかった場合に、前記リクエストに応答して、前記クライアントマシンにエラーメッセージを送信するステップを、前記コンピュータに実行させることを特徴とする請求項７に記載のプログラム。
【請求項９】
前記照合に利用しないようにするステップにおいて、
前記一時的に記憶したデータＩＤを移動させ、照合による確認済のデータＩＤとして、前記記憶手段の他の領域に記憶するステップを、前記コンピュータに実行させることを特徴とする請求項６に記載のプログラム。
【請求項１０】
さらに、受理したデータＩＤと、前記記憶手段に一時的に記憶したデータＩＤとを照合し、適切に照合ができなかった場合に、前記受理したデータＩＤと、前記確認済のデータＩＤとを二次的に照合するステップを、前記コンピュータに実行させ、かつ、
適切に二次的照合ができた場合には、前記リクエストを無視し、その一方、適切に二次的照合ができなかった場合には、前記リクエストに応答して、前記クライアントにエラーメッセージを送信するステップを、前記コンピュータに実行させることを特徴とする請求項９に記載のプログラム。
【発明の詳細な説明】
【０００１】
【発明が属する技術分野】
本発明は、ウェブシステムにおけるセッション管理の手法に関する。
【０００２】
【従来の技術】
ＨＴＴＰプロトコルは、状態を保持しないステートレスな、また、通信路の確保や開放が不要なコネクションレスの通信手法である。このため、注文入力画面、注文の指定およびこれに応答した注文確認画面、さらに、確認の入力に応答した登録確認画面など、商品購入などにかかる一連のリクエストおよび応答の組を、同一のクライアントからのものであると判断し、かつ、当該クライアントの状態を把握するために、「Ｈｔｔｐ  Ｓｅｓｓｉｏｎ」（セッションキー）を利用することが知られている。
【０００３】
この手法では、サーバ側がクライアント固有の情報（セッションキー）を保持し、クライアントからのリクエストに対して、当該クライアント固有のセッションキーを付与してレスポンスを返している。クライアントのリクエストにも、上記セッションキーが付加されることにより、サーバは、どのクライアントからのリクエストかを判断することが可能となる。
【０００４】
たとえば、特許文献１には、しかしながら、ステートレスおよびコネクションレスであることから、種々の問題が生じうる。たとえば、特許文献１には、端末から長期間にわたってはなれた場合にも、他人のなりすましを防ぐために、セッション時間を管理し、画面の遷移が所定時間以内のものであるかを判断する技術が提案されている。
【０００５】
【特許文献１】特開２００２−２２９９４１号公報
【０００６】
【発明が解決しようとする課題】
上述した他人の成りすましのほか、セッションキーを利用する手法では、以下のような問題が生じ得る。
たとえば、ユーザが新たなウィンドウを開くことにより、同じセッションキーをもつ複数のブラウザが作られ得る。この場合に、どちらのブラウザ上の画面からのリクエストかを判断できなくなり、適切な応答ができないという問題点があった。
【０００７】
また、登録処理における二重登録の問題がある。たとえば、入力内容確認画面において、確認ボタンをダブルクリックすることにより、確認が二度登録されてしまうことである。また、確認ボタンをオンした後、戻りボタンで画面を元に戻して、再度確認ボタンをオンできる可能性もある。たとえば、商品購入の確認であれば、当該商品が二重に購入されたとサーバが判断してしまうおそれがあった。
上記問題点の対策として、従来、以下のような手法が実用化されている。
【０００８】
（１）クライアントからの入力ボタンのオンを受理すると、サーバにて確認情報を保持し、次に送られるクライアントからのボタン（たとえば、登録ボタン）のオンを受理すると、登録処理を実行するとともに、上記確認情報を消去する。これにより、二重登録の問題を解決することができる。
【０００９】
（２）画面が遷移するために、トークン（Ｔｏｋｅｎ）を発行してクライアントに返す。サーバは、最新のトークンが付与されたリクエストのみに応答して処理を実行する。これは、画面遷移ごとにセッションキーが変更されるのとほぼ同様になる。
【００１０】
しかしながら、（１）の手法では、同じセッションで複数のブラウザが開いている場合に、クライアントマシンに表示しているデータと、処理対象となるデータが異なる場合がある。たとえば、一方の画面で商品を注文し、入力内容を確認する画面を呼び出し、次いで、他方の画面（画面自体は上記一方の画面と同一）で、他の商品を注文し、入力内容を確認する画面を呼び出した状態を考える。ここで、一方の（先に注文した）内容を確認する画面で、登録ボタンをユーザがオンしたときに、サーバは、他方の画面からの登録ボタンのオンと判断する可能性がある。つまり、ユーザが商品Ａを購入しようとしているに、他方の画面で購入しようとしていた商品Ｂが登録されてしまう。
また、ユーザ情報などを変更する際の画面（変更画面）で、「戻る」ボタンを指定してもこれが無効になってしまう。たとえば、検索結果リストの表示においても同様の問題が生じ得る。
【００１１】
また、（２）の手法では、ブラウザの「戻る」ボタンを使えなくなる。「戻る」ボタンを押すと、これ以降の操作は無効になってしまう。また、同じセッションで複数のブラウザが開いている場合に、一方の画面を消してしまうと、ログインからやり直さなければならない。つまり、現在のトークンを持っている画面が消えてしまうと、操作を継続できないという問題点があった。さらに、登録ボタンなどをダブルクリックすると、エラーが表示されてしまう。
【００１２】
本発明は、ユーザが参照している画面の情報と、処理対象となった情報とが一致し、かつ、ダブルクリックや複数画面を開いているときにも矛盾なく、ユーザのリクエストに応答することができるシステムを提供することを目的とする。
【００１３】
【課題を解決するための手段】
本発明の目的は、クライアントマシンからのリクエストに応答して、所定の処理を実行して、処理結果を応答として、当該クライアントマシンに返送する情報処理方法であって、サーバにおいて、クライアントマシンからの一連のリクエストおよび応答に関するセッションＩＤを保持するセッションオブジェクトを生成するステップと、前記クライアントマシンからのリクエストに応答するために、前記セッションオブジェクトにおいて、応答データと、当該応答データを一意的に特定するデータＩＤとを生成するステップと、前記応答データとデータＩＤとを前記クライアントマシンに伝達するとともに、当該データＩＤを、記憶手段に一時的に記憶するステップと、前記クライアントマシンにおいて、前記応答データからの異なるリクエストに、当該応答データに関連したデータＩＤを付与して送信するステップと、前記サーバにおいて、受理したデータＩＤと、前記記憶手段に一時的に記憶したデータＩＤとを照合し、適切に照合できた場合に、前記セッションオブジェクトにおいて、当該リクエストに応答した応答データを生成するステップと、処理後の応答データを一意的に特定する新たなデータＩＤを生成するステップと、いったん照合に利用されたデータＩＤを、当該照合以後のリクエストに応答した照合に利用しないようにするステップとを備えたことを特徴とする情報処理方法により達成される。
【００１４】
本発明によれば、先行するリクエストに応じて作られた応答データに関連するデータＩＤが、サーバの記憶手段に記憶されるとともに、クライアントに伝達される。クライアントからは、応答データに基づく他のリクエストとともに、伝達されたデータＩＤが、サーバに返される。サーバに返されたデータＩＤは、記憶手段に記憶されたデータＩＤと照合される。記憶手段中に、クライアントからサーバに返されたデータＩＤと同一のものが存在する場合には、適切に照合されたとして、処理が継続される。いったん照合に利用されたデータＩＤは、それ以降の照合には利用されない。これにより、二重登録を防止することが可能となる。
【００１５】
また、データＩＤは、あるリクエストに対する応答データに関連している。したがって、クライアントにおいてブラウザの戻りボタンが押された後、再度、上記応答データに対応する画面に戻された場合、当該戻された画面からのリクエストには、応答データに関連付けられたデータＩＤが付加されているため、サーバにおいて、適切に処理することができる。
【００１６】
すなわち、本発明においては、従来のセッション管理のためのセッションＩＤとは別に、オブジェクトの保有するデータごとにデータＩＤを付与して管理している。このため、画面遷移状態やクライアントマシンからのＨＴＴＰリクエストとは依存せず、オブジェクトのもつデータの変更のみに注目して、データＩＤを付与することができる。これにより、上記二重登録の防止やブラウザの戻りボタンが押された後に、再度、画面が戻された場合などにおいても、サーバにおける適切な処理が実現できる。
【００１７】
なお、データＩＤは、推測が困難となるように、ランダムでかつ一意に生成されるのが望ましい。
【００１８】
好ましい実施態様においては、照合に利用しないようにするステップが、前記一時的に記憶したデータＩＤを消去するステップを有する。この実施態様において、適切に照合できなかった場合に、前記リクエストに応答して、前記クライアントマシンにエラーメッセージを送信するステップを備えていても良い。
【００１９】
別の好ましい実施態様においては、前記照合に利用しないようにするステップが、前記一時的に記憶したデータＩＤを移動させ、照合による確認済のデータＩＤとして、前記記憶手段の他の領域に記憶するステップを有する。より好ましくは、さらに、受理したデータＩＤと、前記記憶手段に一時的に記憶したデータＩＤとを照合し、適切に照合ができなかった場合に、前記受理したデータＩＤと、前記確認済のデータＩＤとを二次的に照合するステップを備え、かつ、適切に二次的照合ができた場合には、前記リクエストを無視し、その一方、適切に二次的照合ができなかった場合には、前記リクエストに応答して、前記クライアントにエラーメッセージを送信するステップを備えている。
【００２０】
また、本発明の目的は、クライアントマシンからのリクエストに応答して、所定の処理を実行して、処理結果を応答として、当該クライアントマシンに返送するためにコンピュータを動作させる情報処理プログラムであって、クライアントマシンからの一連のリクエストおよび応答に関するセッションＩＤを保持するセッションオブジェクトを生成するステップと、前記クライアントマシンからのリクエストに応答するために、前記セッションオブジェクトにおいて、応答データと、当該応答データを一意的に特定するデータＩＤとを生成するステップと、前記応答データとデータＩＤとを前記クライアントマシンに伝達するとともに、当該データＩＤを、記憶手段に一時的に記憶するステップと、前記クライアントマシンにおいて送信された、前記応答データからの異なるリクエストに、および、応答データに関連したデータＩＤを受理するステップと、受理したデータＩＤと、前記記憶手段に一時的に記憶したデータＩＤとを照合し、適切に照合できた場合に、前記セッションオブジェクトにおいて、当該リクエストに応答した応答データを生成するステップと、処理後の応答データを一意的に特定する新たなデータＩＤを生成するステップと、いったん照合に利用されたデータＩＤを、当該照合以後のリクエストに応答した照合に利用しないようにするステップとを、前記コンピュータに実行させることを特徴とするプログラムにより達成される。
【００２１】
好ましい実施態様においては、照合に利用しないようにするステップにおいて、前記一時的に記憶したデータＩＤを消去するステップを、前記コンピュータに実行させる。ここで、適切に照合できなかった場合に、前記リクエストに応答して、前記クライアントマシンにエラーメッセージを送信するステップを、前記コンピュータに実行させても良い。
【００２２】
別の好ましい実施態様においては、照合に利用しないようにするステップにおいて、前記一時的に記憶したデータＩＤを移動させ、照合による確認済のデータＩＤとして、前記記憶手段の他の領域に記憶するステップを、前記コンピュータに実行させる。さらに、受理したデータＩＤと、前記記憶手段に一時的に記憶したデータＩＤとを照合し、適切に照合ができなかった場合に、前記受理したデータＩＤと、前記確認済のデータＩＤとを二次的に照合するステップを、前記コンピュータに実行させ、かつ、適切に二次的照合ができた場合には、前記リクエストを無視し、その一方、適切に二次的照合ができなかった場合には、前記リクエストに応答して、前記クライアントにエラーメッセージを送信するステップを、前記コンピュータに実行させるのが望ましい。
【００２３】
【発明の実施の形態】
以下、添付図面を参照して、本発明の実施の形態につき説明を加える。図１は、本発明の第１の実施の形態にかかるサーバを含むシステムの概略を示すブロックダイヤグラムである。図１にいては、インターネット１２に、クライアントマシン１４−１、１４−２、・・・や、サーバ１６が接続されている。サーバ１６は、クライアントマシン１４からの種々のリクエストに対して、所定のコンテンツ（たとえば、画像）を提供することができる。無論、本発明は、クライアントマシン１４はインターネット１２を介してサーバ１６に接続できる形態に限定されるものではなく、ＬＡＮやＷＡＮなど任意のネットワークを介して接続されたものに適用できることは言うまでもない。また、サーバ１６には、クライアントマシン１４からのデータ授受に際して利用される、データＩＤを一時的に記憶するためのデータ記憶部１８が設けられている。
【００２４】
図２は、本実施の形態にかかる手法を用いた、サーバ１６による処理の概略を示す図である。ここでは、クライアントマシン１４とサーバ１６とのデータ授受により、クライアントマシン１４からサーバ１６にコマンドが伝達され、クライアントマシン１４において画面が遷移される状態を示している。
【００２５】
図２においては、商品購入サイトにおいて、商品を指定し、指定した商品を注文する注文入力画面２０１から、注文内容を確認する注文内容確認画面２０２を経て、注文内容を登録したことを示す登録内容確認画面２０３まで遷移している。サーバ１６は、サーブレットのオブジェクト２０が、クライアントマシン１４とのセッション開始に際して、セッションオブジェクト２２（たとえば、セッションＩＤ（ＳＩＤ）＝ＹＹＺＺＸ）を生成し、セッションオブジェクト２２が、データが変更されるときに、データＩＤを採番して、データとともに固有のデータＩＤが、クライアントマシン１４に伝達されるようになっている。なお、データＩＤは、推測が不可能或いは困難であるように、ランダムでかつ一意に採番される。
【００２６】
ユーザが、クライアントマシン１４の表示装置上の注文入力画面を参照して、ある商品を選択することにより、これがサーバ１６に伝達され（矢印２１１参照）、サーバ１６による処理の結果、必要なデータがクライアントマシン１４に与えられ（矢印２１２参照）、クライアントマシン１４の表示装置上には、入力内容確認画面２０２が表示される。次いで、ユーザによる入力装置の操作により、内容の確認を示すボタン等が指定されると、これがサーバ１６に伝達される（矢印２１３参照）。データ授受が繰り返されることにより（矢印２１３、２１４参照）、サーバ１６において、ユーザが購入する商品が登録される。
【００２７】
図３は、本実施の形態にかかるクライアントマシン１４およびサーバ１６にて実行される処理の例を示すフローチャートである。ここでは、図２に示す画面遷移に実行される処理が示されている。クライアントマシン１４からのアクセスにより（ステップ３０１）、サーバ１６においては、オブジェクト２０が、当該クライアントマシン１４とのセッションのためのセッションオブジェクト２２を生成する（ステップ３０２）。セッションオブジェクト２２は、セッションＩＤを発行し、クライアントマシン１４を識別できるようにする。また、これは、クライアントマシン１４とのセッションが終了するまで保持される。
【００２８】
クライアントマシン１４とサーバ１６との間のデータ授受により、クライアントマシン１４の表示装置上に注文入力画面が表示されていると考える。注文入力画面には、たとえば、複数の商品名がリストされ、リストされた商品名のいずれかに付随したボタンをクリックすることにより、当該商品が指定される。
【００２９】
ここで、ユーザが、ある商品を指定して、当該商品に付随したボタンをオンすると、注文入力ボタンをオンしたことを示すデータおよび所定の他のデータ（データＩＤ）が、入力データとして、サーバ１６のオブジェクト２０に伝達される（ステップ３０３）。実際には、クライアントマシンから、オブジェクトの「リスト選択」というメソッドの呼び出し（リクエスト）に、データＩＤと、指定された商品の番号に対応するパラメータとが付加されて、サーバ１６に与えられる。このデータＩＤについては、ステップ３１１以降において詳述する。
【００３０】
サーバ１６のオブジェクト２０は、必要な処理（これについても、ステップ３１１以降を参照して詳述する）の後、リクエストをセッションオブジェクト２２に伝達する（ステップ３０４）。セッションオブジェクト２２は、入力内容確認画面を生成するための注文データと、上記ステップ３０４のリクエストに対して一意的となるデータＩＤとを生成し、これをオブジェクト２０に返す（ステップ３１１）。したがって、ユーザ側に確認を求める確認データとして、上記注文データが、データＩＤ（確認ＩＤ）とともに、クライアントマシン１４に伝達される（ステップ３１２）。このデータＩＤは、前記注文データと関連付けてデータ記憶部１８に記憶される（ステップ３１３）。
【００３１】
クライアントマシン１４の表示装置上の入力内容確認画面を参照して、ユーザが入力装置を操作することにより、確認ボタンがオンされると、「確認要求」というリクエストに、ステップ３１２にて伝達されたデータＩＤが付加されて、サーバ１６に伝えられる（ステップ３１４）。サーバ１８においては、当該受理したデータＩＤと、注文データと関連付けてデータ記憶部１８に記憶しておいたデータＩＤとを照合する（ステップ３１５）。これらが一致する場合には、データ記憶部１８中のデータＩＤが消去され（ステップ３１６）、登録要求がセッションオブジェクト２２に伝達される（ステップ３１７）。
【００３２】
セッションオブジェクト２２は、登録確認画面を生成するための登録データと、当該ステップ３１７のリクエストに対して一意的となるデータＩＤとをオブジェクト２０に返す（ステップ３１８）。したがって、ユーザ側に確認を求める確認データとして、上記登録データが、そのデータＩＤとともに、クライアントマシン１４に伝達される（ステップ３１９）。つまり、応答データと、これを一意的に特定する新たなデータＩＤとが、クライアントマシン１４に与えられることになる。図３に示していないが、この登録データのデータＩＤも、データ記憶部１８に記憶され、次のクライアントマシン１４からのアクセスの際の照合に利用される。
【００３３】
ここで、クライアントマシンに、注文データに基づく画面（入力内容確認画面）が表示された状態で、確認ボタンが２度オンされたと考える。たとえば、本来マウスのシングルクリックの操作で足りるものを、ダブルクリックの操作をしてしまった場合が、これに該当する。図４に示すように、このときに、最初の確認ボタンのオンにより、登録要求および先の注文データとともに与えられたデータＩＤとが、オブジェクト２０に送信される。これは、図３のステップ３１４と同様である。したがって、オブジェクト２０は、データ記憶部１８を参照して、データＩＤを照合し（ステップ３１５）、照合の後にデータを消去する（ステップ３１６）。データＩＤの照合が上首尾に完了している（つまり、データＩＤが存在する）ため、当該登録要求は、セッションオブジェクトに伝達される（図３のステップ３１７参照）。
【００３４】
これに対して、２度目の確認ボタンのオンにより、オブジェクト２０に登録要求およびデータＩＤが与えられた場合（ステップ４０１）に、データ記憶部１８中の対応するデータＩＤは既に消去されているため、照合が失敗する（ステップ４０２）。したがって、２度目の確認ボタンのオンに基づく要求は、これ以降無視される（ステップ４０３参照）。或いは、上記ステップ４０１の要求に応答して、オブジェクト２０は、エラーメッセージを含む画像（エラーメッセージ画像）を伝達する。
【００３５】
このように、本実施の形態によれば、クライアントマシン１４のリクエスト（要求）に対して、当該リクエストに応答したデータ（確認データ）およびデータＩＤを、クライアントマシン１４に返し、クライアントマシン１４からの、当該応答したデータに関連する次のリクエストに、確認データに関連付けられていたデータＩＤを付与して送信している。サーバ１６においては、このデータＩＤを保持しておくことで、ユーザからのリクエストを特定することができる。
【００３６】
また、照合の後、データＩＤを消去することで、ダブルクリックにより、同一のリクエストおよびデータＩＤがサーバ１６に送信されても、当該リクエストを無視することができる。これにより、ダブルクリックによる二重登録や、複数画面表示などを防止することが可能となる。
【００３７】
また、本実施の形態によれば、同一のセッションにおいて複数のデータ（画面）を保持し、それぞれについて適切な処理を実行することも可能となる。図５は、このような画面遷移の例を示す図である。図５において、ユーザは、商品購入サイトにおいて、リクエストを入力する（符号５２１〜５２４参照）ことにより、注文入力画面５０１、入力内容確認画面５０２、登録内容確認画面５０３の順で、画面を遷移させる。これは、図２の画面２０１〜２０３にそれぞれ対応する。その一方、たとえば新たなウィンドウを開くことにより、他の注文入力画面５１１を表示させ、注文入力画面からリクエストを入力し（符号５３１参照）、リクエストおよび応答を繰り返して（符号５３２〜５３４参照）、他の入力内容確認画面５１２、登録内容確認画面５１３に画面遷移させている。本実施の形態では、それぞれを適切に画面遷移させ、かつ、ユーザの入力を適切に登録することができる。
【００３８】
図６および図７は、複数のデータ（画面）を保持する場合の処理の一例を示すフローチャートである。
まず、クライアントマシン１４からのアクセスにより（ステップ６００ａ）、サーバ１６内にセッションオブジェクト２２が生成される（ステップ６００ｂ）。クライアントマシン１６から注文入力画面要求、および、先のサーバからの応答において付与されていたデータＩＤが、サーバ１６のオブジェクト２０に伝達されると、図３のステップ３１５、３１６にて説明したように、データＩＤの照合よび消去が行なわれ（図示せず）、その後、注文入力画面要求が、セッションオブジェクト２２に伝達される（ステップ６０２）。
【００３９】
セッションオブジェクト２２は、当該リクエストに応答したデータ（注文入力画面を生成するための画面データ）と、前記リクエストに対して一意的となるデータＩＤ（たとえば、データＩＤ＝ａａａａ）とを、オブジェクト２０に返す。これにより、画面データおよびデータＩＤ（＝ａａａａ）が、クライアントマシンに伝達される（ステップ６０３）。また、このデータＩＤ（＝ａａａａ）がデータ記憶部１８に記憶される（ステップ６０４）。
【００４０】
その一方、同一のセッションにおいて、たとえば新たなウィンドウを開くことにより、第２の注文入力画面要求が、データＩＤとともにオブジェクト２０に伝達されると（ステップ６１１）、データＩＤの照合やデータＩＤの消去の後（図示せず）、これがセッションオブジェクト２２に伝達される。ここでは、適切にデータＩＤが照合されたと考える。したがって、第２の注文入力画面要求もセッションオブジェクト２２に伝達される（ステップ６１２）。
【００４１】
セッションオブジェクト２２は、当該リクエストに応答したデータ（注文入力画面を生成するための画面データ）と、前記リクエストに対して一意的となるデータＩＤ（たとえば、データＩＤ＝ｂｂｂｂ）とを、オブジェクト２０に返す。これにより、画面データおよびデータＩＤ（＝ｂｂｂｂ）が、クライアントマシンに伝達される（ステップ６１３）。また、このデータＩＤ（＝ｂｂｂｂ）がデータ記憶部１８に記憶される（ステップ６１４）。したがって、先のリクエストに応答した注文入力画面とは別個に、第２の注文入力画面を、クライアントマシン１４の表示装置上に表示することができる。
【００４２】
ユーザが、（第１の）注文入力画面を参照して、所望の商品に付随したボタンをオンすると、ボタンのオンを示すデータおよび先にステップ６０３で与えられたデータＩＤ（＝ａａａａ）が、サーバ１６に送られる（ステップ６０５）。オブジェクト２０により、データＩＤの照合および消去が行なわれ、（この場合は適切にデータ照合が行なわれているため）、セッションオブジェクト２２に注文入力要求が与えられる（ステップ６０８）。セッションオブジェクト２２は、これに応答して、入力内容確認画面を生成するための注文データ、および、対応するデータＩＤ（たとえば、データＩＤ＝ｃｃｃｃ）を、オブジェクト２０を介してクライアントマシン１４に伝達する（ステップ６０９）。ここでも、当該データＩＤ（＝ｃｃｃｃ）は、データ記憶部１８に記憶される（ステップ６１０）。この場合にも、応答データと、これを一意的に特定する新たなデータＩＤとが、クライアントマシン１４に与えられることになる。このようにして、リクエストにデータＩＤが付加されてサーバに伝達することにより、一方の画面遷移（図５の符号５０１〜５０３）を適切に実行することが可能となる。
【００４３】
その一方、ユーザが、第２の注文入力画面を参照して、所望の商品に付随したボタンをオンしたときにも、リクエストおよび先のステップ６１３で与えられたデータＩＤ（＝ｂｂｂｂ）がサーバ１６に伝達される（ステップ６１５）。これ以降、データＩＤ（＝ｂｂｂｂ）の照合、消去、セッションオブジェクトにおける第２の注文入力に応答した第２の注文データ、および、対応するデータＩＤ（＝ｄｄｄｄ）の伝達などが実行される（ステップ６１６〜６２０参照）。これらは、先に説明した図５のステップ５１６〜５２０と、データＩＤが異なることを除き同一である。このようにして、もう一方の画面遷移（図５の符号５１１〜５１３）も、適切に実行することが可能となる。
【００４４】
このように本実施の形態によれば、データＩＤの発行および記憶、クライアントマシンからのデータＩＤと記憶したデータＩＤとの照合、並びに、照合の後のデータＩＤの消去により、クライアントマシンからの要求に、一度だけ応答して、必要な処理（たとえば、データ登録や画面遷移）を実行している。したがって、同じ画面からの二度の要求（たとえば、データの登録要求など）があった場合でも、先の要求のみにしたがって適切な処理を実行することができる。また、同一のセッションにおいて同一の画面を同時に保持し、それぞれの画面において、なんらかの要求をした場合であっても、それぞれの要求に応えた適切な処理を実行することが可能となる。
【００４５】
次に、本発明の第２の実施の形態につき説明を加える。第２の実施の形態にかかるシステムにおいても、図１に示すように、インターネットに、クライアントマシン１４やサーバ１６が接続され、サーバ１６が、クライアントマシン１４からの種々のリクエストに対して、所定のコンテンツを提供できるようになっている。
【００４６】
第１の実施の形態においては、照合の終了後に、データ記憶部１８中のデータＩＤを消去し、これにより、重複した要求に応答した処理の実行を防止している。しかしながら、データＩＤを消去した場合には、要求がダブルクリックによるものであるか、或いは、まったく異なるものであるかを判断することができない。したがって、エラーメッセージ画像を伝達するなど、画一的な応答のみが可能であった。これに対して、第２の実施の形態においては、ダブルクリックによってサーバ１６に与えられた要求を無視し、その他の、不適切な要求に対してはエラーメッセージ画像をクライアント１４に伝達できるように構成されている。
【００４７】
図８は、第２の実施の形態にかかるクライアントマシン１４およびサーバ１６にて実行される処理の例を示すフローチャートである。図８において、ステップ８０１〜８０４、ステップ８１１〜８１５は、それぞれ、図３のステップ３０１〜３０４、ステップ３１１〜３１５に対応する。クライアント１４に、確認データおよび確認ＩＤが与えられた後（ステップ８１２参照）、ユーザによるクライアントマシン１４上の操作により、確認ボタンがオンされると、確認要求とともに、ステップ８１２にて受理されたデータＩＤ（たとえば、データＩＤ＝「ａａａａ」）が、クライアント１４からサーバ１６に伝達される（ステップ８１４）。
【００４８】
サーバ１６のオブジェクト２０は、第１の実施の形態と同様に、受理したデータＩＤと、ステップ８１３にて記憶された、注文データと関連付けられたデータＩＤとを照合し（ステップ８１５）、これらが一致した場合には、登録要求がセッションオブジェクト８１７に伝達される（ステップ８１７）。つまり、この場合には、ステップ８１４の要求が適切なものと判断され、さらに処理が進行する。
【００４９】
第２の実施の形態においては、照合の後、照合に利用したデータＩＤ（データＩＤ＝「ａａａａ」）を移動し、注文データと関連付けて、確認済ＩＤとして、データ記憶部１８に記憶する（ステップ８１６および符号８２０参照）。確認済ＩＤは、クライアントから伝達されたデータＩＤとの初期的な照合（たとえば、図８のステップ８１５）には利用されず、後述するように、初期的な照合が失敗した場合に実行される二次的な照合に利用される。
【００５０】
登録要求の伝達（ステップ８１７）に応答して、セッションオブジェクト２２は、登録確認画面を生成するための登録データと、当該ステップ３１７のリクエストに対して一意的となるデータＩＤとをオブジェクト２０に返す（ステップ８１８）。したがって、ユーザ側に確認を求める確認データとして、上記登録データが、そのデータＩＤとともに、クライアントマシン１４に伝達される（ステップ８１９）。図８に示していないが、第１の実施の形態と同様に、この登録データのデータＩＤも、データ記憶部１８に記憶され、次のクライアントマシン１４からのアクセスの際の照合に利用される。
【００５１】
図８において、ユーザのクライアントマシン１４の操作による確認ボタンのオン（ステップ８１４参照）が、ダブルクリックであった場合を考える。この場合には、図９（ａ）に示すように、同じ確認要求およびデータＩＤ（データＩＤ＝「ａａａａ」）が、再度、サーバに伝達される（ステップ９０１）。オブジェクト９００は、受理したデータＩＤと、データ記憶部１８に記憶された、注文データと関連付けられたデータＩＤとを初期的に照合する（ステップ９０２）。しかしながら、図８のステップ８１６において、照合に利用したデータＩＤが移動され、確認済ＩＤとして記憶されているため、ステップ９０２において、受理したデータＩＤと同一のデータＩＤが存在しない。この場合に、オブジェクト２０は、受理したデータＩＤと、確認済ＩＤとを二次的に照合する（ステップ９０３）。
【００５２】
図９（ａ）の例では、確認済ＩＤとして「ａａａａ」が記憶されているため、同一のデータＩＤが存在すると判断される。確認済ＩＤに、受理したデータＩＤと同一のものがある場合には、オブジェクト２０は、クライアント１４からの要求を無視する（符号９０４参照）。
その一方、図９（ｂ）に示すように、初期的な照合および二次的な照合（確認済ＩＤとの照合）においても、受理したデータＩＤと同一のデータＩＤが、データ記憶部１８中に見出せなかった場合には（ステップ９１１〜９１３参照）、オブジェクト２０は、エラーメッセージを含む画像（エラーメッセージ画像）を、クライアント１４に伝達する。
【００５３】
このように、第２の実施の形態によれば、初期的な照合および二次的な照合により、ダブルクリックによる要求であるか、他の不適切な要求であるかを判断することができ、要求の態様に応じた適切な処理（たとえば、無視或いはエラーメッセージの送付）を実行することが可能となる。
本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
【００５４】
【発明の効果】
本発明によれば、ユーザが参照している画面の情報と、処理対象となった情報とが一致し、かつ、ダブルクリックや複数画面を開いているときにも矛盾なく、ユーザのリクエストに応答することができる。
【図面の簡単な説明】
【図１】図１は、本発明の第１の実施の形態にかかるサーバを含むシステムの概略を示すブロックダイヤグラムである。
【図２】図２は、本実施の形態にかかる手法を用いたサーバによる処理の概略を示す図である。
【図３】図３は、本実施の形態にかかるクライアントマシンおよびサーバにて実行される処理の例を示すフローチャートである。
【図４】図４は、本実施の形態にかかるクライアントマシンおよびサーバにて実行される処理の例を示すフローチャートである。
【図５】図５は、本実施の形態にかかる画面遷移の例を示す図である。
【図６】図６は、本実施の形態において、複数のデータ（画面）を保持する場合の処理の一例を示すフローチャートである。
【図７】図７は、複数のデータ（画面）を保持する場合の処理の一例を示すフローチャートである。
【図８】図８は、第２の実施の形態にかかるクライアントマシンおよびサーバにて実行される処理の例を示すフローチャートである。
【図９】図９は、クライアントマシンおよびサーバにて実行される処理の例を示すフローチャートである。
【符号の説明】
１４    クライアントマシン
１６    サーバ
２０    オブジェクト
２２    セッションオブジェクト
【図１】
2004287899.tif 000003
【図２】
2004287899.tif 000004
【図３】
2004287899.tif 000005
【図４】
2004287899.tif 000006
【図５】
2004287899.tif 000007
【図６】
2004287899.tif 000008
【図７】
2004287899.tif 000009
【図８】
2004287899.tif 000010
【図９】
2004287899.tif 000011