(57)【特許請求の範囲】
【請求項１】
処理状態を把握するウェブアプリケーションをイネーブルにするセッション復帰のための方法において、
終了したウェブアプリケーションのセッションに関する、クライアントからの終了ユーアールエル（ＵＲＬ）を受け取る段階と、
外部セッションＩＤ（ＥＳＩＤ）に関連した終了済みウェブアプリケーションのセッションに関した状態のうちセッション復帰に必要な永続的な部分のみを保存する段階と、
新しいウェブアプリケーションのセッションに対するクライアントからの要求を受け取る段階と、
要求に、終了したウェブアプリケーションのセッションのＥＳＩＤに対応した識別子が含まれるかどうかを決定する段階と、
もし、この識別子が、終了したウェブアプリケーションのセッションのＥＳＩＤに対応すると、終了したウェブアプリケーションのセッションに関した状態に従って、新しいウェブアプリケーションのセッションを提供する段階と
を含み、
前記終了ＵＲＬは、終了したウェブアプリケーションセッションを識別するＥＳＩＤを含み、
前記ウェブアプリケーションを最初に開始した時、終了した時、および再開した時に、前記クライアントから前記ＥＳＩＤを受け取ることを特徴とする方法。
【請求項２】
終了済みウェブアプリケーションに関した状態を保存する段階は、終了したウェブアプリケーションを識別するＥＳＩＤを保存する段階を含むことを特徴とする請求項１記載の方法。
【請求項３】
クライアントが使用するポータルからＥＳＩＤを受け取る段階を、さらに備えることを特徴とする請求項１記載の方法。
【請求項４】
新しいウェブアプリケーションの提供に応じてＥＳＩＤを受け取る段階を、さらに備えることを特徴とする請求項１記載の方法。
【請求項５】
新しいウェブアプリケーションセッションが始まる度にＥＳＩＤを受け取る段階を、さらに備えることを特徴とする請求項１記載の方法。
【請求項６】
前記要求には、開始ＵＲＬが含まれることを特徴とする請求項１記載の方法。
【請求項７】
もし前記識別子が、終了したウェブアプリケーションセッションのＥＳＩＤに対応していなければ、開始モードで新しいウェブアプリケーションセッションを提供する段階を、さらに備えることを特徴とする請求項１記載の方法。
【請求項８】
ＥＳＩＤをセッションメモリに保存する段階を、さらに備えることを特徴とする請求項１記載の方法。
【請求項９】
前記要求に、終了したウェブアプリケーションのセッションのＥＳＩＤに対応した識別子が含まれるかどうかを決定する段階は、セッションメモリに保存された１つ或いは２つ以上のＥＳＩＤに識別子をマッピングする段階を、さらに備えることを特徴とする請求項８記載の方法。
【請求項１０】
前記ＥＳＩＤは、ポータルのセッションマネージャによって生成されることを特徴とする請求項３記載の方法。
【請求項１１】
処理状態を把握するウェブアプリケーションをイネーブルにするセッション復帰のための方法において、
新しいウェブアプリケーションのセッションに対するクライアントからの要求を受け取る段階と、
要求に、メモリ内に保存され、終了したウェブアプリケーションのセッションを識別する、外部セッション識別子（ＥＳＩＤ）に対応した識別子が含まれるかどうかを決定する段階と、
もし、この識別子が、終了したウェブアプリケーションのセッションのＥＳＩＤに対応すると、終了したウェブアプリケーションのセッションに関した状態のうちセッション復帰に必要な永続的な部分のみに従って、新しいウェブアプリケーションのセッションを提供する段階と、
もし前記識別子が、終了したウェブアプリケーションセッションのＥＳＩＤに対応していなければ、開始モードで新しいウェブアプリケーションセッションを提供する段階と
を備え、
前記ウェブアプリケーションを最初に開始した時、終了した時、および再開した時に、前記クライアントから前記ＥＳＩＤを受け取ることを特徴とする方法。
【請求項１２】
終了したウェブアプリケーションセッションに関した状態を保存する段階を、さらに備えることを特徴とする請求項１１記載の方法。
【請求項１３】
クライアントから、終了ユーアールエル（ＵＲＬ）と共にＥＳＩＤを受け取る段階を、さらに備えることを特徴とする請求項１１記載の方法。
【請求項１４】
前記状態は、終了したウェブアプリケーションセッションに関した、セッション復帰状態であることを特徴とする請求項１２記載の方法。
【請求項１５】
前記要求に終了したウェブアプリケーションのセッションのＥＳＩＤに対応した識別子が含まれるかどうかを決定する段階は、セッションメモリに保存された１つ或いは２つ以上のＥＳＩＤに識別子をマッピングする段階を、さらに備えることを特徴とする請求項１１記載の方法。
【請求項１６】
前記要求には、開始ＵＲＬが含まれることを特徴とする請求項１１記載の方法。
【請求項１７】
ウェブアプリケーションのページ戻りを実行するためのシステムにおいて、
ウェブアプリケーションセッションに関した外部セッション識別子（ＥＳＩＤ）を生成するように構成され、また、ＥＳＩＤをサーバーに送るように構成されたポータルと、
サーバーを迎え、ＥＳＩＤと関連したセッションの状態のうちページ戻りに必要な永続的な部分のみを保存するように構成されたメモリ、及び新しいウェブアプリケーションセッションに対する要求をメモリ内の１つ或いは２つ以上のＥＳＩＤにマッピングするマッピングモジュールを持つサーバープラットフォームと
を備え、
前記サーバープラットフォームは、さらに、もし要求が１つのＥＳＩＤに対応するなら、１つのＥＳＩＤに関連した状態の新しいウェブアプリケーションセッションを提供するように構成される
前記ウェブアプリケーションを最初に開始した時、終了した時、および再開した時に、前記ポータルから前記ＥＳＩＤを受け取ることを特徴とするシステム。
【請求項１８】
前記サーバーは、ウェブアプリケーションサーバーであることを特徴とする請求項１７記載のシステム。
【請求項１９】
前記ポータルは、ＥＳＩＤを生成するセッションマネージャを、さらに備えることを特徴とする請求項１７記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、２００２年１２月２日出願の特許文献１の優先権を主張する。
【背景技術】
【０００２】
以下の説明は、サーバーセッション管理と、処理状態を把握できるサーバーセッションにおけるブラウザからの反対方向ナビゲーションとに関する。
【０００３】
ポータルとは、それによって様々なウェブコンテントが、クライアントに送られてクライアント上で実行されるブラウザアプリケーションで表示される、１つ或いは２つ以上のポータルページへとまとめられる機構である。ポータルページは、典型的には、サーバーから、ハイパーテキスト転送プロトコル（ＨＴＴＰ）に従って送られる。ウェブアプリケーションは、いずれかのサーバーに保存されて、呼び出すことのできる独立したユニットであり、典型的には、均一のユーアールエル（ＵＲＬ）アドレスを通して呼び出される。他のポータルのレベルでは、呼び出すことのできるユニットとそのコンテントは、時にポートレット（portlet）と呼ばれる（同様に、ページレット、iVIEW、ウェブパーツ等と呼ばれる）。そのような訳で、アプリケーションはポートレットとして存在し、ページのレイアウト方法に従って、１つ或いは２つ以上のウェブページへとまとめられる。ページは、ポータル内の単位である、即ちユーザーは常に或るページにナビゲートし、そのページにおいて全てのポートレットを呼び出す。
【０００４】
簡単化すると、ポートレットが分離されているとする、即ちコンテントがIFRAMEを呼び出すページ構造内部で実行されるとする。ユーザーは、マウス装置および／またはポインタを用いてポートレット内部で“クリック”するなどの幾つかの方法でポートレットの周囲をナビゲートすることができる。アプリケーション内のナビゲーション（例えば、“次の画面”へのナビゲーション）に対して、ユーザーは、ポートレットやアプリケーションの周囲でページレベルに影響を与えないアプリケーション“内部”にいると見なされる。ユーザーがポータルレベルをナビゲートする時、ユーザーは、新しいポータルレベルあるいは同じポータルページさえも対象として選択する。そのような場合、古いポータルページは、アプリケーションを備えたポートレットであるように、ブラウザ内で表示される。従って、アプリケーションを備えたポータルページを離れる時は、ユーザーは“アプリケーションを離れる”。
【０００５】
［ウェブアプリケーション内の状態］
インターネットを使ったアプリケーションは、サーバーからクライアントへ送られる一連のページから成る。ユーザーがページのシーケンスを通ってナビゲートする時、サーバーは、“状態”を維持する、即ち、既に閲覧したページでのユーザーの入力と、ナビゲーション履歴と、アプリケーションがユーザーに応答するのに必要なデータ等に関するデータを保持する。典型的には、状態は、サーバーによってセッション内で保たれ、サーバーが生成したセッション識別子（"セッションＩＤ"）によって各セッション毎に識別される。セッションＩＤは、ブラウザの“クッキー”（将来に使うために、サーバーによって送られ、クライアント上に保存される情報）内、あるいはサーバーの応答に含まれるＵＲＬ内に保持することができる。全ての重要なアプリケーションは、サーバーが、ユーザーの要求に迅速に応答できる状態であることを要する。従って、ウェブ上の殆どのビジネス用アプリケーションは、“処理状態を把握できる”ものである。
【０００６】
通常は、ユーザー当たりおよび／またはブラウザの処理当たり、１つのセッションのみがあり得る。ウェブアプリケーションは、ユーザーが同時に同じアプリケーションの２つ或いはそれ以上のインスタンスを実行できる時、極端な例では、同じブラウザウィンドウ内の２つのIFRAMEで並んでいる時に、“マルチセッションが可能”である。マルチセッションのアプリケーションは、セッションＩＤが無い"start-URL"で始まり、その後、サーバーは、セッションを作成し、セッションＩＤをＵＲＬ（ＵＲＬ書き換え）内、或いはクッキー内に置くことで、セッションの関連付けを維持する。真にマルチセッション可能なアプリケーションは、クッキーは、同じブラウザウィンドウ（処理）内でかち合った時に、互いに上書きするので、セッションＩＤのためにクッキーを用いることはできず、サーバーは、同じブラウザ内の２つのIFRAMEからの２つの並列した要求を区別する可能性はない。そうして、マルチセッション能力は、ＵＲＬに符号化されるセッションＩＤを必要とする。このことによって、後述する"session-return（セッション復帰）"が複雑になる。
【０００７】
マルチセッションとページ“戻り”ナビゲーションを組み合わせることで、１つの問題が発生する。マルチセッションの能力を認めるために、セッションＩＤは、ＵＲＬ内に符号化されなくてはならず、これは、ポータルページに開始ＵＲＬが含まれることを意味し、サーバーは各アプリケーションのインスタンスに対して、新しいセッションで応答する。しかし、ユーザーが同じページに“戻った”場合、同じ開始ＵＲＬが起動され、サーバーは、ページ上の２つのIFRAME内の２つのインスタンスを区別する可能性はない。
【０００８】
［基本セッション終了］
幾つかのセッション終了に対する１つの方法は、２０００年７月１１日出願の、関連する特許文献２に記載され、その発明の名称は、"Method, Apparatus and System for Network-Based Peer-to-PeerBusiness Transactions"であり、参考のためにここに組み入れる。システムのシナリオは、ポータル呼出型ウェブアプリケーションである。
【０００９】
ユーザーは、アプリケーションを入力し、サーバーを使ったアプリケーションからページ／スクリーンを要求する。アプリケーションには、オンライン処理で要求のあった対話を実行するために、“セッションの状態”のような資源が必要であり、おそらく、いくつかの部分を処理する間、鍵あるいは他の重要な資源を得る必要がある。ユーザーが処理の途中でアプリケーションを離れる場合は、ＨＴＴＰがコネクションレスであるため、サーバーは、理論的に気付かないが、これは、他のポータルページにナビゲートしたり、単にブラウザを閉じたりすることで発生する可能性がある。ユーザーが明白にアプリケーションを終了させなかった時、例えば、ユーザーがセッションからログオフした時には、サーバーのセッションの状態（おそらく鍵も）はサーバー上にあり続け、時間切れになるまで資源を消費する。従って、ポータルは、ユーザーがアプリケーションを離れる時に、サーバーおよび／またはアプリケーションに気付かなくてはならず、その結果、サーバーはアプリケーションに関連する資源を開放することができる。
【００１０】
基本セッションの終了は、以下のように動作する：ポータルはポータル／ブラウザ内に部分的に隠れて実行されるセッションマネージャ（ＳＭ）を提供する。アプリケーションが、ポータルページ内部で始まると、ハイパーテキストマークアップ言語内の応答の一部として、“セッション終了ＵＲＬ”をＳＭに送る。現在のページが置き換えられて、ＳＭが現在のページのためにセッション終了ＵＲＬを保存すると、このセッション終了ＵＲＬは、サーバーがセッションと全ての関連する資源を開放するように、サーバーに送り返される。これは、サーバーが、アプリケーションが終了してその資源が開放されるべきだと“気付く”様子を示している。
【００１１】
［セッションの復帰が可能であることへの要求］
上述した“基本セッションの終了”は、ユーザーがアプリケーションを離れるや否や、すなわちユーザーがナビゲーションあるいはブラウザの省略によって他のページへ飛ぶ時に、セッションを終了する。しかし、典型的には、ユーザーは、２番目のアプリケーションあるいはページの様々なページを探検し、前に訪れたページ／アプリケーションに戻って、そこでの作業を続けることができることを望む。要するにユーザーは、しばしばポータルに出される、処理状態を把握するアプリケーションが、ブラウザ内の“復帰”機能に関して、静的コンテントと殆ど同等に動作することを望む。
【００１２】
１つの問題は、ユーザーが最初のページ／アプリケーションに戻ってくるかどうかが不可知である点であり、つまりサーバーは、ユーザーがアプリケーションを離れる時に、すぐに知らされる必要があり、それによってその時点でセッションの状態を開放する。従って、１つの問題には、“セッションの復帰”を認める思想、すなわちユーザーがセッションを離れた時に、同じ状態の前に訪れたセッションへと戻る能力、「基本セッション終了」を変更することが含まれる。
【００１３】
以上のように、アプリケーションは、単に“待って”戻る、或いは後で継続することはできないが、ユーザーが離れた時にすぐに終了しなくてはならない。戻ることができるために、アプリケーションは、最初に、戻るのに必要な状態の一部を全て保存する必要がある。例えば全てのユーザーインターフェイス領域を保存するなどの、内部状態全部、あるいは何か他の形態の状態を保存するのは望ましくないさらに、アプリケーションは、いつでも現在の状態全てを保存すると考えるべきでなく、その結果、何らかの動作中間状態を完全に保存することができる。このように、セッションの状態の永続的な部分が保存され、過渡的な部分は破棄されるだろう。永続的に保存される状態は“セッション復帰状態”と呼ばれ、その中には、一般的に見せたり編集されたりするオブジェクトのＩＤが、おそらくどのタブがタブストリップ中でアクティブか、ツリーの開閉状態というような何らかのＩＤ状態と同様に、含まれている。セッション復帰状態から再ロードされたこれらのパラメータでアプリケーションを再開することで、希望する“戻り”或いはセッションが戻った認識をユーザーに与え、アプリケーションにそれで自身を再開するのに十分なデータを与える。
【００１４】
このように、アプリケーションは、終了要求を受け取ると、セッション復帰状態を保存することができ、またユーザーが離れた時に実質的に同じ出力を示すように、前のセッション復帰状態を再ロードするように再開することができると考えられる。しかし、これは、基本セッション終了の概念の終了要求の解釈が、“完全に終了”から“セッション復帰状態を保存し、しかる後に終了”へ変わったことを示す。新しい解釈は、“セッション最小化”と呼ぶことができる。どれほどアプリケーションがセッション復帰状態の中に保存したかは、可変であり、アプリケーションによっている。何も保持されない場合は、セッション最小化は、従来の完全な終了と同じであり、アプリケーションは毎度、ゼロから再開する。
【００１５】
アプリケーションが再開し“セッション復帰状態”がロードされると、アプリケーションの多数のインスタンスが同時にアクティブになる時に問題が発生する。サーバーは、アプリケーションが再開する時に、どの“セッション復帰状態”をロードするのかが分からないだろう。アプリケーションが、別個のブラウザウィンドウ内で、あるいは同じブラウザウィンドウ内で（すなわち、ポータルページ内の２つのIFRAME内部等）開始するかどうかに係わらず、問題は存在する。
【００１６】
【特許文献１】米国特許仮出願第６０／４３０，５０３号明細書
【特許文献２】米国特許出願第０９／６１４，１６７号明細書
【発明の開示】
【課題を解決するための手段】
【００１７】
本明細書は、ポータル環境にいるユーザーが、アプリケーション間を論理的に或いは“処理状態を把握する”方法でナビゲートする方法とシステムを開示している。この特徴が無いと、ウェブアプリケーションのユーザーは、他のアプリケーションへナビゲートしている時に、離れた際のアプリケーションの状態を失うだろう。一実施形態において、コンピューティングシステムが“セッション復帰可能”な状態で、すなわち、処理状態を把握するウェブアプリケーションが適切に“ブラウザ戻り”機能を支援したり、一般的に“どんな形式でも”戻ることができるような技術が構成されている。これはユーザーの経験全体を改善するのに、処理状態を把握するウェブアプリケーションをポータルに提供するために重要な特徴である。
【００１８】
サーバーがセッションＩＤを生成する代わりに、典型的にはポータル或いはブラウザを介したクライアントの呼出側は、開始時にセッションを参照したり、その後例えば終了や再開のために使用したい所定のセッションＩＤをサーバーに渡す。この所定のセッションＩＤは、外部セッションＩＤ（ＥＳＩＤ）と呼ばれるが、アプリケーションが始まる度に、望ましくはアプリケーションの開始ＵＲＬ内のＵＲＬパラメータとして渡される。
【００１９】
もし、復帰状態が保持されるアクティブ名セッション或いは最小化されたセッションをＥＳＩＤが参照しない場合、新しいセッションが作られて、ＥＳＩＤと結びつけられる。このセッション／アプリケーションの間、サーバーは、“新しい”ＥＳＩＤに加えて、ＵＲＬあるいはクッキー内で符号化された“古い”セッションＩＤを依然として保持しているので、ＥＳＩＤは無関係である。しかし、ユーザーがページ／アプリケーションを離れると、クライアントＳＭは、ＥＳＩＤを含む終了ＵＲＬをサーバーに送ることで、サーバーにこの事実を知らせる。その後、サーバーは、状態を最小化し、ＥＳＩＤキーの下でそれを保存する。アプリケーション開始ＵＲＬがＥＳＩＤと共にサーバーへ送られると、サーバーは、ＥＳＩＤのために保存された最小化セッション（すなわちセッション復帰状態）を持っていることを発見し、アプリケーションが始まり、初期パラメータ（"init parameters"）としてセッション復帰状態が与えられる。
【００２０】
処理状態を把握するウェブアプリケーションをイネーブルにするセッション復帰のための一方法には、終了したウェブアプリケーションのセッションに関する、クライアントからの終了ＵＲＬを受け取る段階が含まれ、前記終了ＵＲＬには、終了したウェブアプリケーションセッションを識別するＥＳＩＤが含まれる。さらに、この方法には、ＥＳＩＤに関連した終了済みウェブアプリケーションのセッションに関した状態を保存する段階と、新しいウェブアプリケーションのセッションに対するクライアントからの要求を受け取る段階とが含まれる。さらに、この方法には、要求に、終了したウェブアプリケーションのセッションのＥＳＩＤに対応した識別子が含まれるかどうかを決定する段階が含まれる。もし、この識別子が、終了したウェブアプリケーションのセッションのＥＳＩＤに対応すると、この方法には、終了したウェブアプリケーションのセッションに関した状態に従って、新しいウェブアプリケーションのセッションを提供する段階が含まれる。
【００２１】
もし、アプリケーションが同じＥＳＩＤを使って連続的に呼び出されると、そのアプリケーションは、ユーザーが離れた時に終了することができ、さらに再開する時には、終了した時と実質的に同じ位置から続けることができる。多数のインスタンスと、セッションの終了と、同じアプリケーションのセッションの復帰を可能にするために、サーバーでなくクライアントによってＥＳＩＤが繰り返して生成され送られなくてはならない。
【００２２】
こうして、ＥＳＩＤは、アプリケーションの開始時と、セッションの復帰に対してアプリケーションを再開する時にセッションを参照するのに使用される。これによって、処理状態を把握するアプリケーションがもたらされ、サーバーがアプリケーションのための状態を最小化することができる、或いは言い換えると、“セッション復帰”状態のみを維持するが、まだアプリケーションを完全に終了する。さらに、ＥＳＩＤを使用することで、アプリケーションは、重要なやり方で“続ける”ことができる。
【００２３】
ここに開示した技術による利点は、アプリケーションが終了すると、即ちユーザーが離れるとすぐに、サーバーがアプリケーションに関連する全ての資源を開放することである。しかし、ここに記載した技術によってユーザーは、アプリケーションに行く度に毎回再出発しなくて良い様に、アプリケーションに戻って続けることができ、またアプリケーションの多数のインスタンスが同時に区別されることができる。ＥＳＩＤを使用する技術は、これら全ての特徴を可能にする。
【００２４】
１つ或いは２つ以上の実施形態の詳細は、添付の図面と以下の説明で述べる。他の特徴と目的と利点とは、説明と図面と特許請求の範囲とから明らかとなるであろう。
【００２５】
これらの態様と他の側面とは、添付の図面を参照して詳細に説明される。
様々な図面の中の類似の参照番号は、類似の要素を示している。
【発明を実施するための最良の形態】
【００２６】
ここに記載したシステムと技術とは、ブラウザが戻って、前のセッションでアクセスした時と同じ状態で、前にアクセスしたアプリケーションのページに行くことができるようにすることに関する。
【００２７】
マルチセッションの能力を可能にするために、１つのページ上の２つのIFRAME内の２つのセッションを区別する機構に、ポータルページの開始ＵＲＬを“外部セッションＩＤ”（ＥＳＩＤ）と共に提供することが含まれる。ＥＳＩＤは、（同じページ上の）アプリケーションの２つのインスタンス間の差異である引数であり、サーバー内の異なる／独立したセッションをもたらす。こうして、ユーザーが同じページに戻る時に、ＥＳＩＤは個々のアプリケーション要求と共に再び渡され、サーバーは正しいセッションに論理的に再接続してユーザーに継続させることができる。
【００２８】
こうして、サーバーに任意にセッションＩＤを作らせる代わりに、ポータルあるいは呼出側は、サーバー上でアプリケーションを始める時（すなわち、最初の呼出し時）に、ＥＳＩＤを渡す。そしてこのＥＳＩＤは、ユーザーが他のアプリケーションに行くために離れてその後に再び戻る場合や、ユーザーがブラウザを閉じて後にアプリケーションを再開する場合などに、アプリケーションに戻るのに使用することができる。ＥＳＩＤは、以下にさらに詳細に説明する“セッション復帰”を可能にする。
【００２９】
ＥＳＩＤは、セッション管理（以下参照）及びポータルとから独立していることに注意したい。ＥＳＩＤはアプリケーションを開始する全てのＵＲＬ上で使用可能である。サーバーが、単にセッションあるいはアプリケーションに時間切れを待たせる（終了させる代わりに）時、ＥＳＩＤは、アプリケーションが再開する時に使用することができる（開始ＵＲＬ）。従って、待ちのセッション／アプリケーションのインスタンスが選択され、ユーザーは、そのセッションを継続することができる。
【００３０】
ＥＳＩＤは、例えば"page3/app1"や"page3/app2"のセッションを選ぶキーボードとして使用される任意のストリングで良い。ＥＳＩＤは、前の例でのような特定のページの文脈を表すために生成されない明示的な固定値でも良いし、あるいは離れる時にアプリケーションが完全に終了することを意味する“値無し”でも良く、ユーザーが再び入った時に常にスクラッチから始められる。これは必要に応じて最適に調整できる構成の問題である。また、アプリケーションのインスタンスと無関係に実行することのできる２つのブラウザウィンドウ内の２つのインスタンスのページを持つことができるように、"WindowID"のような要素を、ＥＳＩＤに付加することができる。
【００３１】
ＥＳＩＤを使用することで、基本的なセッション終了の機構を拡張することもできる。サーバーに、セッションマネージャにセッション終了ＵＲＬを送る要求をする代わりに、クライアント／ポータルは、ＥＳＩＤを通過する標準的な終了通知を送ることができる。これは、セッションマネージャがいかなる種類のＭＩＮＥも支援するという付加的な利点を持っている。サーバーはＥＳＩＤを使用した終了通知を理解し、サーバーへ来る（全てのユーザーに対する）全てのＥＳＩＤが異なることを理解する必要がある。
【００３２】
図１は、ウェブアプリケーションセッション１００のブロック図を示しており、その中には、サーバー１０８プラットフォーム、即ちアプリケーションサーバーか同等のものから供給される、アプリケーション１０４の１つ或いは２つ以上のインスタンスを表示するポータルページ１０２、即ち１つ或いは２つ以上のウェブページとそのコンテントが含まれる。アプリケーション１０４の各インスタンスは、クライアント１１０上で動作するブラウザ内で最終的に表示される。ウェブアプリケーションセッション１００のアプリケーション１０４を、ローカルクライアントアプリケーションから或いは他のアプリケーションサーバーからのコンテントのような別のウェブコンテントと同時に表示することもできる。ポータルページ１０２には、アプリケーション１０４の各インスタンスから受信したセッション情報に基づいて、各アプリケーションセッション１００を管理するためのセッションマネージャ（ＳＭ）１０６が含まれる。このＳＭ１０６は、ページレベルのスクリプト符号で良い。一実施形態において、ＳＭ１０６は、アプリケーション１０４の様々なページを通したユーザーのナビゲーションと動作に基づいてセッションを識別する。
【００３３】
ユーザーが以前に見たページを訪れるために、サーバープラットフォーム１０８は、例えユーザーがアプリケーションを離れてセッションマネージャに対して、終了通知をアプリケーションサーバー１１８へ送らせる時でも、セッションのいくつかの“状態”すなわちアプリケーションのインスタンスに関する情報を保持する。一実施形態において、サーバープラットフォーム１０８には、ユーザーが離れたアプリケーションのセッションの状態を保存するためのセッションメモリ１０９が含まれる。この状態には、インスタンス識別子が含まれ、その中には、さらにセッションの各頁のページ識別子が含まれる。インスタンス識別子は、セッション内の訪れた各ページに対して保存することができ、それによって、インスタンス識別子の番号を持ったメモリを提供する。セッションメモリ１０９は、コンピュータのメモリ内あるいはデータベース内にあって良い。
【００３４】
ポータルサーバー１１２には、ポータルページ１０２を生成するためのページ生成器１２２が含まれる。ポータルサーバー１１２には、ＵＲＬ生成器１２０も含まれる。ユーザーは、セッション内部とアプリケーションの外部へナビゲートするので、ポータルサーバー１１２のＵＲＬ生成器１２０は、ＥＳＩＤすなわちインスタンス識別子を提供する。ＥＳＩＤには、セッション内で訪れた各ページのページ識別子も含まれる。従って、ユーザーが或るセッションを再び訪れたい時、そして離れた時と同じ状態で表示されるセッションのページが欲しい時、ポータルページ１０２は、サーバープラットフォーム１０８に、要求されているページに関連したＥＳＩＤだけでなく、要求されているページに対する開始ＵＲＬを送る。
【００３５】
ユーザーがページを離れる時、ＥＳＩＤを用いて画面の状態が保存され、ユーザーが再び訪れた時に再度見ることになる。典型的には、ＥＳＩＤは、ページ識別子（ページＩＤ）を含むようにフォーマットすることができる。ユーザーは、ポータルページ１０２を通して或いはブラウザ／クライアント１１０上のいずれかで２つ以上のウィンドウを使用することができるので、ＥＳＩＤはウィンドウ識別子（ウィンドウＩＤ）を含むこともできる。代わりに、ＥＳＩＤは、そこで同じページが多くのポータルページ１０２によって共有されるようなセッションに進むように記述することができる。従って、同じＥＳＩＤを異なる場所から、そして多くのパス上で記述することができる。
【００３６】
ＥＳＩＤは、ページ特性として記述され、ＵＲＬを通してサーバープラットフォーム１０８へ渡すことができる。要求されたアプリケーションにＥＳＩＤが含まれていない時は、アプリケーションは、単に要求されるたびに新しく始まる。ユーザープラットフォーム１０８がＥＳＩＤと開始ＵＲＬを受け取ると、マッピングモジュール１１６は、ＥＳＩＤを特定のセッションにマップする、すなわち対応するＥＳＩＤが既にセッションメモリ１０９内に保存されているかどうかを調べる。もし、ＥＳＩＤが存在していなければ、サーバープラットフォーム１０８は、要求されたアプリケーション１０４のセッションの新しいインスタンスを作る。もしＥＳＩＤが存在していれば、サーバープラットフォーム１０８は、アプリケーション１０４を始めて、保存された状態で、それをポータルページ１０２へ渡す。
【００３７】
一実施形態において、ＥＳＩＤは、クライアントＳＭ１０６内に保持される。ポータルサーバー１１２は、一般的なＳＭ１０６を含んだポータルページ１０２と、アプリケーション１０４用のFRAMEを生成する。ＥＳＩＤも、ポータルサーバー１１２で生成され、FRAMEに対する開始ＵＲＬに加えられるので、アプリケーションへの要求は、アプリケーション１０４の各インスタンスのコンテントFRAMEから来る。ポータルサーバー１１２は、ＥＳＩＤを知っており、埋め込まれたスクリプト記述をポータルぺージ１０２へ生成して、ＥＳＩＤをＳＭ１０６に入力することができる。ページ１０２自身は、ページに対してＩＤが必要ないために、ＥＳＩＤを知らず、単にＥＳＩＤを含んだＳＭ１０６を運ぶだけである。
【００３８】
他の実施形態において、ＥＳＩＤは、開始ＵＲＬ上で渡されるが、ＳＭ１０６内に保持されることはなく、ポータルサーバー１１２内にのみ保持される。この時、ポータルぺージ１０２は、このページのために生成されたＥＳＩＤをポータルサーバー１１２が保存するときの固有ＩＤを得る。このページＩＤは、ユーザーが多数のブラウザウィンドウをポータルコンテントと同時に開くことができるために必要である。ユーザーがページを離れる時、ＳＭ１０６はポータルサーバー１１２に通知し、ページＩＤを渡す。ポータルサーバー１１２は、その後、一組の終了要求をＥＳＩＤと共に生成し、この“終了ページ”をクライアント１１０に送り、そこからこれらは、適切なサーバープラットフォーム１０８に送信される。
【００３９】
図２は、セッション復帰が可能な、処理状態を把握するウェブアプリケーションの方法２００のフローチャートである。２０２において、クライアントの呼出し側は、典型的にはポータルもしくはブラウザ経由で、例えば終了と再開のために、開始時とその後でセッションを参照するのに使用することを望む所定のＥＳＤをサーバーに渡す。ＥＳＩＤは、アプリケーションが始まる度に、望ましくはアプリケーションの開始ＵＲＬ内のＵＲＬパラメータとして渡されるが、ＥＳＩＤをサーバーに渡すという他の方法も使用することができる。
【００４０】
サーバーは、２０４でＥＳＩＤを受信する。各セッション／アプリケーションの間、ＥＳＩＤは無意味なものとなる。実際、サーバーは、“新しい”ＥＳＩＤに加えてＵＲＬあるいはクッキーの中で符号化された“古い”セッションＩＤを依然として保持する。しかし、ユーザーがページ／アプリケーションを離れると、クライアントＳＭはサーバーに終了ＵＲＬをＥＳＩＤと共に送るが、これは、その状態を最小なものにして、２０６においてＥＳＩＤキーの下で保存する。サーバーは、アプリケーションが終了すると、すなわちユーザーが離れるとすぐに、アプリケーションに関連する全ての資源を開放する。
【００４１】
２０８で、アプリケーション開始ＵＲＬがＥＳＩＤと共にサーバーへ送られると、サーバーは、２１０で以前に受信された１つ或いは２つ以上の保存済みＥＳＩＤと共に要求の中にＥＳＩＤをマッピングすることによって、このＥＳＩＤに対して保存された最小化されたセッション（すなわちセッション復帰状態）があるかどうかを決定する。もし要求ＥＳＩＤが、復帰状態が保持されるところの、動作中であるかもしくは最小化されたセッションを参照していなければ、２１２において、新しいセッションが作られて要求ＥＳＩＤと関連付けられる。もしサーバーが要求ＥＳＩＤに関したセッション復帰状態ならば、アプリケーションは、２１４において、開始されて、最初のパラメータ（“初期パラメータ”）のようなセッション復帰状態を与えられる。セッションは、２１６において、継続する。
【００４２】
従って、もしアプリケーションが継続的に同じＥＳＩＤを用いて呼び出されると、アプリケーションは、ユーザーが離れた時すぐに終了することができ、やがて再開した時には実質的に同じ位置で続けることができる。同じアプリケーションの多数のインスタンスとセッションの終了とセッションの復帰に対して、ＥＳＩＤは、クライアントによって繰り返し生成され送られなくてはならない。こうして、ＥＳＩＤは、アプリケーションの開始時と、セッション復帰のためのアプリケーションの再開時とにセッションを参照するのに使用される。
【００４３】
一実施形態において、ＥＳＩＤは内部構造を持たないキーストリングである。従って、ユーザーは、異なるＥＳＩＤで、例えばhttp://server/X?ESID=a のような種類のＵＲＬによってアプリケーションＸを３回呼び出すだけでよい。開示された技術では、クライアントＳＭの基本セッション管理（Basic Session Management）の機能を使うのが望ましく、これはユーザーがアプリケーションあるいはアプリケーションの或るページを離れる度に終了通知をサーバーに送る。
【００４４】
一例では、ポータルが、Basic Session Managemetを使用してＥＳＩＤを生成する。ポータルには、"/roles/salesrep/ovw_page4"等のような名前を持った多数のページが含まれる。次に、同じページ"od1"と"od2"上のポートレットとして、アプリケーション"orderdetail"の２つのインスタンスを考える。サーバーセッションＩＤのためのクッキーを用いて、両方のページが同じセッションＩＤを共有し、それによって同じサーバーセッションを参照する。従って、１つのページは常に他のもののデータを示すので、ユーザーは、od1とod2の中を独立して閲覧することはできない。もし、サーバー／アプリケーションがＵＲＬ符号化されたセッションＩＤを用いると、od1とod2は別々になることができるが、ユーザーが離れる時には終了しなくてはならない。ユーザーが復帰する時には、サーバーは要求がどこから来たのかを知らないので、ユーザーは、常にスクラッチから始めなくてはならず、開始ＵＲＬは新しいセッションを始める。そして、"/roles/salesrep/ovw_page4/od1"と"/roles/salesrep/ovw_page4/od2"のようなＥＳＩＤを用いてみると、それぞれのページ上のこれらのアプリケーションのインスタンスに対応する、２つの明確に定義されたサーバーセッションがある。ユーザーが片方或いは両方のページに復帰する時、両方のセッションは、離れたところで続けることができる。
【００４５】
ＥＳＩＤの値には、他の意味もある：同じアプリケーションが２つのページ上に提供され、上述したＥＳＩＤの一例として“ページパス”を使用するときに、２つの独立したセッションが提供される。このように、１つのアプリケーションは、ポータルナビゲーション内の２つの場所において独立して使用することができる。
【００４６】
ＥＳＩＤは、標準的なセッションＩＤの能力が足りないような別の状況も扱う。他の例では、ユーザーが"ctrl-N"機能で、しかし同じ共有クッキーのような同じ処理を用いて新しいブラウザウィンドウを開く時、同様の状況が隣り合った２つのアプリケーションにとって発生する。アプリケーションが同じサーバーセッションを参照し、その結果、互いに混乱するほど影響し合うか、新しいセッションが始まるが、ユーザーは決していずれかに戻ることはない。ウィンドウＩＤがＥＳＩＤに加わると、新しいウィンドウが自動的に新しいセッションおよび／またはアプリケーションインスタンスを参照する。こうして、新しいアプリケーションのための新しい並列かつ独立した作業空間を得ることができる。
【００４７】
上述したようなＥＳＩＤの機構を使うには、前提条件としてBasic ession Terminationを提供する状況が必要である。しかし、代わりに、別のシナリオでは、ＥＳＩＤは管理者が手動でアプリケーション開始ＵＲＬに加えることができる。ポータルの状況において、ＥＳＩＤの値は動的に生成され得るものであり、その中には、アプリケーションへのパス（例えば、"/roles/salesrep/ovw_page4/od1"）の静的な部分と、"<windowID>"のような動的な部分とが含まれる。ＥＳＩＤは、様々な動的な値を結合する定型ＵＲＬを用いて生成されるのが望ましい。
【００４８】
１つの方法では、サーバーは、ユーザーがアプリケーションを離れ、セッションマネージャが終了通知を送った時でさえ、いくつかの“状態”を保持する。この状態は、“読み出し専用／閲覧状態”（例えば、どのオブジェクトが選ばれたか、ツリーの状態、等々）として保持することができる。この状態は、典型的には、小さく、より長い時間保持することができる。ユーザーがアプリケーションの同じページを再び訪れた時、サーバーは、“閲覧状態”を再ロードして、ユーザーが離れた時と同じ状態にある同じページを見せる。
【００４９】
ＳＲＭの特徴に沿ったセッション復帰の特徴を可能にするために、ＣＬＯＳＥ命令を単に受信する代わりに、ＳＲＭの考えとサーバーがそれを解釈することで、以下のようなより詳細な異なる通知を受信することができる。
【００５０】
ＬＥＡＶＥ：例えば、ポータルを通ってナビゲートするなどにより、ユーザーがアプリケーションを離れたことを示す。これは、前のＣＬＯＳＥ命令と同じである。しかし、この場合、アプリケーションは“最小化”するべき、すなわち、終了するよりむしろ資源の使用を最小化するべきである。アプリケーションは、例えば対話状況を完全に書き出したり、読み出し専用モードへ行ったり、全てのロックとメモリを開放したり等々によって、最小化することができる。アプリケーションは、“復元”して同じ状態に戻ることができるのに十分な情報のみを保存することができる。アプリケーションは、アプリケーション内のユーザーの動作、例えばフィールド間のナビゲーションしてデータを入力したり、その後データを分析したりを記録することができる。これは、メモリがわずか２０〜３０ｋバイト必要なだけである。ユーザーは、絶対に帰ってくることがないかも知れず、それ以上の通知は無いだろう（ログオフまで）。結果としての状態は、最少の資源が使用されるため、長い間（時間切れ）存在することができるはずである。
【００５１】
ＲＥＳＴＯＲＥ：既存のＥＳＩＤと共にページの戻りの後に受信される。アプリケーションは、“最小化”処理を元に戻すべき、即ちデータを読み返して前の状態を復元するべきである。アプリケーションは“高価な”（資源の観点で）状態にある。
【００５２】
ＬＯＧＯＦＦ：ユーザーが実際にポータルを離れたときに送られる。これは、アプリケーションが、最小化の代わりに、即時に終了をすることができるという、ＬＥＡＶＥに追加する選択的な通知である。
【００５３】
ＬＥＡＶＥとＲＥＳＴＯＲＥとＬＯＧＯＦＦの通知は、アプリケーションがサーバーから受け取る通知であることに注意したい。ＳＲＭは、ＣＬＯＳＥ（今やＬＥＡＶＥにマッピングされている）を送っただけで、ＬＯＧＯＦＦする。サーバーは、“既存のＥＳＩＤを発見”の状態（セッション復帰）を認識し、アプリケーションにＲＥＳＴＯＲＥ通知を送る。
【００５４】
ここまでで、各ＥＳＩＤとアプリケーション（ユーザー毎の）に対して‘セッション復帰状態’を集めている。当然、新しいインスタンスをスクラッチから始めるにはどうするのかという疑問が湧く、ユーザーがアプリケーションポータルを共に離れた時、追加のＬＯＧＯＦＦイベントを定義することができる。サーバーがＥＳＩＤと共にＬＯＧＯＦＦ通知を受け取ると、それは、ＥＳＩＤに対するセッション復帰状態を放棄する。
【００５５】
ここに説明した様々なシステムと技術の実例は、ディジタル電子回路及び／または集積回路及び／または特別設計のＡＳＩＣ（特定用途向け集積回路）及び／またはコンピュータハードウェア及び／またはファームウェア及び／またはソフトウェア及び／またはそれらの組み合わせで実現できる。これらの様々な実例には、少なくとも１つのプログラム可能なプロセッサを含むプログラム可能なシステム上で実行可能及び／または翻訳可能な１つ或いは２つ以上のコンピュータプログラムでの実行が含まれ、上記プロセッサは、専用もしくは汎用のものであり、記憶システムと少なくとも１つの入力機器と少なくとも１つの出力機器からデータと命令とを受信し、またそれらへデータと命令とを送信するために結合される。
【００５６】
これらのコンピュータプログラム（プログラム或いはソフトウェア或いはソフトウェアアプリケーション或いはコードとしても知られる）には、プログラム可能なプロセッサに対する機械語命令が含まれ、高級手続き言語及び／またはオブジェクト指向プログラム言語及び／またはアッセンブリ／機械語で実現することができる。ここで使用されるように、“機械読み取り可能な媒体”という用語は、機械語命令及び／またはデータをプログラム可能なプロセッサに提供するのに使用される、何らかのコンピュータプログラム製品、装置及び／または装置（例えば磁気ディスク、光ディスク、メモリ、プログラム可能な論理素子（ＰＬＤ））を示しており、その中には、機械読み取り可能な信号として機械語命令を受け取る機械読み取り可能な媒体が含まれる。“機械読み取り可能な信号”は、機械命令及び／またはデータをプログラム可能なプロセッサに供給するのに使用される何らかの信号を示している。
【００５７】
ユーザーとのやり取りを提供するのに、ここに説明した本システムと技術は、情報をユーザーに表示するための表示装置（例えば、ＣＲＴ（陰極線管）あるいはＬＣＤ（液晶表示）モニター）と、ユーザーが入力をコンピュータに入力を提供できるキーボードと指示装置（例えば、マウスあるいはトラックボール）を持ったコンピュータ上に実現できる。ユーザーとのやり取りに備えて他の種類の装置を使うことができるのに加えて、例えば、ユーザーに与えられるフィードバックは、いかなる形式の感覚フィードバック（例えば、視覚フィードバックや聴覚フィードバックや触覚フィードバック）でも良く、またユーザーからの入力は、音響や音声や触覚の入力を含むいかなる形式でも受信することができる。
【００５８】
ここに説明したシステムと技術は、バックエンド部品（例えば、データサーバーとして）を含んだり、あるいはミドルウェア部品（例えば、アプリケーションサーバー）を含んだり、あるいはフロントエンド部品（例えば、グラフィカルユーザーインターフェイスを持ったクライアントコンピュータ、あるいはユーザーがそれを通してシステム及びここに説明した技術が実現されたものとやり取りできるウェブブラウザ）を含んだり、あるいはそのようなバックエンドやミドルウェアやフロントエンドの部品のあらゆる組み合わせによる、コンピュータシステム内で実現することができる。本システムの部品は、何らかの形式によって、あるいはディジタルデータ通信（例えば、通信ネットワーク）の媒体によって内部接続することができる。通信ネットワークの例の中には、ローカルエリアネットワーク（“ＬＡＮ”）と広域ネットワーク（“ＷＡＮ”）とインターネットが含まれる。
【００５９】
コンピュータシステムには、クライアントとサーバーとが含まれよう。クライアントとサーバーとは、一般に互いに離れており、典型的には、通信ネットワークを通してやり取りする。クライアントとサーバーとの関係は、それぞれのコンピュータ上で実行されるコンピュータプログラムに基づいて発生し、互いにクライアント−サーバーの関係を持っている。
【００６０】
いくつかの実施形態を今まで詳細に説明したが、他の変更は可能である。ここの一部ではポータルを通した処理について説明したが、多くのアクセスのシステムと方法のいずれもウェブアプリケーションセッションを扱うのに使用することができる。図２に描かれる論理フローは、望ましい結果を得るのに示された特定の順序であったり、あるいは順番である必要はない。他の実施形態は、添付の特許請求の範囲の範囲の中にあるであろう。
【図面の簡単な説明】
【００６１】
【図１】ウェブアプリケーションのブロック図である。
【図２】処理状態を把握するウェブアプリケーションを可能にするセッション復帰の方法を示すフローチャートである。
【符号の説明】
【００６２】
１００…ウェブアプリケーションセッション
１０２…ポータルページ
１０４…アプリケーション
１０６…セッションマネージャ（ＳＭ）
１０８…サーバープラットフォーム
１０９…セッションメモリ
１１０…クライアント
１１２…ポータルサーバー
１１６…マッピングモジュール
１２０…ＵＲＬ生成器
１２２…ページ生成器
【図１】
0004571509.tif 000002
【図２】
0004571509.tif 000003