(57)【特許請求の範囲】
【請求項１】
コンピュータで実現される方法において、
第１の接続を介してポータルサーバーにおいてブラウザから受け取られた第１のポータルページに関する要求に応じて、前記ブラウザにセッションの一部として読み込まれた前記ポータルページにコンテントサーバーから送られるべきコンテントを指定するコンテントＵＲＬを含む前記第１のポータルページと、セッション終了エージェントとを、前記第１の接続を介して前記ポータルサーバーから前記ブラウザに送り、前記コンテントサーバーが、前記コンテントとセッション終了ＵＲＬとを、前記ブラウザと前記コンテントサーバーとの間の第２の接続を介して前記ブラウザに送り、前記ブラウザ内の前記セッション終了エージェントが、前記セッション終了ＵＲＬを受け取る段階と、
前記ポータルサーバーにおいて、新しいポータルページ要求ＵＲＬと前記セッション終了ＵＲＬとを含む新しいポータルページに関する要求を、前記第１の接続を介して前記ブラウザから受け取る段階と、
前記セッション終了ＵＲＬを、前記第１の接続及び前記第２の接続から独立した、前記ポータルサーバーと前記コンテントサーバーとの間の第３の接続を介して、前記ポータルサーバーから前記コンテントサーバーに送る段階とを備え、
前記セッション終了ＵＲＬが、前記ブラウザと前記ポータルサーバーとの間の前記第１の接続または前記ブラウザと前記コンテントサーバーとの間の前記第２の接続に影響を与えずに、前記コンテントサーバーにセッションを終了させる
ことを特徴とする方法。
【請求項２】
前記新しい要求に応じて、新しいポータルページを、前記第１の接続を介して前記ポータルサーバーから前記ブラウザに送る段階を、さらに備える
ことを特徴とする請求項１記載の方法。
【請求項３】
前記セッション終了ＵＲＬは、前記ブラウザから前記ポータルサーバーに、前記新しいポータルページ要求ＵＲＬ内の過去のパラメータとして送られる
ことを特徴とする請求項１記載の方法。
【請求項４】
前記コンテントサーバーによって、前記第２の接続を介して前記ブラウザから新しいコンテントＵＲＬを受け取る段階を、さらに備える
ことを特徴とする請求項２記載の方法。
【請求項５】
前記コンテントサーバーによって、新しいコンテントに対する要求を受け取るのに応じて、新しいコンテントを前記ブラウザに送る段階を、さらに備える
ことを特徴とする請求項４記載の方法。
【請求項６】
前記セッションを確立する段階を、さらに備える
ことを特徴とする請求項１記載の方法。
【請求項７】
前記セッションを確立する段階は、さらに、
前記ポータルサーバーによって、前記セッション終了エージェントを生成する段階を備える
ことを特徴とする請求項６記載の方法。
【請求項８】
前記ポータルサーバーによって、前記セッションを始めるために前記ブラウザから前記第１のポータルページに関する要求を受け取る段階を、さらに備える
ことを特徴とする請求項７記載の方法。
【請求項９】
クライアント装置において動作するブラウザと、
ポータルサーバーと前記クライアント装置との間の第１の接続を介して前記ブラウザから受け取られた第１のポータルページに関する要求に応じて、前記第１のポータルページを介してアクセスされるべきコンテントを指定するコンテントＵＲＬを含む前記第１のポータルページと、セッション終了エージェントとを、前記第１の接続を介して前記ブラウザに提供し、前記ブラウザがセッションを確立するために前記第１のポータルページを読み込む、ポータルサーバーと、
前記ブラウザが前記コンテントＵＲＬをコンテントサーバーと前記クライアント装置との間の第２の接続を介してコンテントサーバーに送った後で、前記コンテントとセッション終了ＵＲＬとを、前記第２の接続を介して前記ブラウザにおける前記第１のポータルページに提供するコンテントサーバーとを備え、
前記ポータルサーバーが、前記セッション終了ＵＲＬを含む、前記ブラウザによる新しいポータルページの新しい要求を、前記第１の接続を介して受け取ると共に、それに応じて、前記セッションを終了するために、前記セッション終了ＵＲＬを、第３の接続を介して前記コンテントサーバーに送り、
前記セッション終了ＵＲＬが、前記ブラウザと前記ポータルサーバーとの間の前記第１の接続または前記ブラウザと前記コンテントサーバーとの間の前記第２の接続に影響を与えずに、前記コンテントサーバーにセッションを終了させる
ことを特徴とするセッション管理システム。
【請求項１０】
前記ポータルサーバーは、さらに、前記第１のポータルページに関する要求に応じて、応答を生成して前記第１の接続を介して前記ブラウザに送ると共に、
前記応答は、前記第１のポータルページと、前記セッション終了エージェントと、前記ブラウザに対する少なくとも１つのコンテントとを含む
ことを特徴とする請求項９記載のシステム。
【請求項１１】
クライアント／サーバーのセッションを制御する方法において、
クライアントは、ブラウザを用いて、コンテントサーバーからコンテントを要求し、
前記方法は、
前記ブラウザにおいて、前記ブラウザと前記コンテントサーバーとの間の第２の接続を介して、セッション終了ＵＲＬと共に、前記コンテントサーバーから前記コンテントを受け取り、前記コンテントと前記セッション終了ＵＲＬが、第１のポータルページに関する第１の要求に応じて前記ブラウザにおいてポータルサーバーから前記ブラウザと前記ポータルサーバーとの間の第１の接続を介して受け取られた第１のポータルページへ渡される段階と、
前記セッション終了ＵＲＬを含んだ、新しいセッションに対するブラウザからの新しい要求を、前記第１の接続を介して前記ポータルサーバーへ送る段階とを備え、
前記ポータルサーバーが、前記セッションを終了するために、前記セッション終了ＵＲＬを、前記ポータルサーバーと前記コンテントサーバーとの間の第３の接続を介して前記コンテントサーバーへ渡すと共に、
前記セッション終了ＵＲＬが、前記ブラウザと前記ポータルサーバーとの間の前記第１の接続または前記ブラウザと前記コンテントサーバーとの間の前記第２の接続に影響を与えずに、前記コンテントサーバーにセッションを終了させる
ことを特徴とする方法。
【請求項１２】
前記セッションを始めるために、前記第１のポータルページに関する第１の要求を前記ポータルサーバーへ送る段階を、さらに備える
ことを特徴とする請求項１１記載の方法。
【請求項１３】
前記第１のポータルページに関する前記第１の要求に基づいて、前記ポータルサーバーから前記第１のポータルページを受け取る段階を、さらに備える
ことを特徴とする請求項１２記載の方法。
【請求項１４】
前記第１のポータルページは、前記ポータルページに関する要求に関連付けられたコンテントに対するコンテントＵＲＬと共に受け取られ、
前記コンテントＵＲＬは、セッションに関連した前記コンテントサーバー内の或るページを表す
ことを特徴とする請求項１１記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットプロトコル（ＩＰ）通信セッションのセッション管理に関する。インターネット共同処理のためにポータルを使用する企業が増えてきた。例えば、標準的なインターネットブラウザを用いてポータルを通ってクライアントへと至る、アプリケーションサービスプロバイダ（ＡＳＰ）のアプリケーションとコンテントである。目標の１つは、企業或いはグループ或いは関連ユーザーの各クライアントのコンピュータにインストールされた専用クライアントソフトウェアを持たないことである。
【背景技術】
【０００２】
そのような筋書きでは、クライアントのブラウザは、あるアプリケーションにアクセスするのに使われる、即ちクライアントブラウザは１つ或いは２つ以上の要求を、そのアプリケーションを呼び出してアプリケーション内でいくつかの段階を実行するサーバーへ送る。そのアプリケーションは、ユーザーの要求にサービスしなくてはならないいくつかの資源（メモリ、接続、データロック、他）を必要とする。これらの資源の全て或いは一部は、サービス／アプリケーションが、ユーザーからの次の要求を待っている間、サーバーによって拘束されているに違いない。これは“サーバー状態”あるいは、より特化して“セッション”または“ユーザーセッション”（即ち、特定のユーザーのためにデータを拘束する）として知られる。
【０００３】
クライアントのブラウザとサーバー或いはポータルとの間の通信のための、標準的なインターネットプロトコルは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）である。ＨＴＴＰは、処理状態を把握しない／コネクションレスであり、つまり通常はアプリケーションから“離れる”ことはなく、ユーザーは実際にサーバーに気付かせずにブラウザを閉じることができることになる。ここでは、この考えは、最初にポータルを用いるという状況で説明され、そこでユーザーは、ポータルページをナビゲートして、通常はＩＦＲＡＭＥ内のＵＲＬを介して始められるアプリケーションにアクセスする。これに関連して、“アプリケーションを離れる”というのは、単に、そのアプリケーションを含んだ、あるいはそのアプリケーションを始めたポータルページを離れるという意味である。しかし、この考え方は、必ずしもポータルの場合に限定されるものではないことに注意したい。
【０００４】
アプリケーションがサーバーからアクセスされると、サーバーは、資源を保持して、ユーザーが“戻る”かどうかを知らぬまま、特定のユーザーセッションに対して準備を整えておいて、その代わりに時間切れまで待つ。サーバー上にそのような資源を得ること、或いは複雑な交換動作には典型的なものである書込みロックを得ることは、非常に犠牲が大きく、受け入れ難い結果を招くことがある。従って、ユーザーがアプリケーションを離れた時、あるいはユーザーがブラウザを閉じた時にサーバーに知らせる機構が必要である。
【０００５】
そのような機構の１つには、ユーザーがサーバーによって与えられたコンテント或いはアプリケーションを“離れる”時に開放されなくてはならない状態及び／または資源をサーバーが拘束している時に、応答内に埋め込まれる特別なセッション終了ＵＲＬ（ＳＴＵ）をサーバーが送る動作が含まれる。ＳＴＵは、特定のユーザーの特定のセッションを終了させるためにサーバーが与える終了ＵＲＬである。ユーザーがポータルページを離れる時に、サーバーが直ちにユーザーセッションを終了して、そのユーザーのためのアプリケーション用に拘束していた全ての資源を開放するように、ＳＴＵはサーバーへ送られる。このＳＴＵは、セッション終了エージェント（ＳＴＡ）によって受け取られて、スクリプトがブラウザとポータルの一部で待機し、その後ＳＴＡ内で呼び戻される。ＳＴＡは、アプリケーションを含んだフレームの外部にあるフレーム内に置かれる。
【０００６】
２つのイベントが、上述した機構に従った効果的なセッション管理に不可欠である。第１に、サーバーがＳＴＵを応答の一部として送り、ＳＴＵを受け取りそれを呼び戻すブラウザ内でＳＴＡが待つことである。第２に、ＳＴＵを送る引き金となる現在のページが離されたと、クライアントが認識することである。上述した機構において、上記２番目の段階は、ブラウザによって発生した“ページの未ロード”イベントを検出することによって実行が可能である。これには、ポータルに関連した３種の“ページを離れた”場合を１つの技術で捕捉できるという利点がある。それは、（１）ユーザーが他のポータルページへ移動する（ポータルナビゲーションによって）場合と、（２）ユーザーが気に入ったブラウザを選択し、ポータル（アプリケーションを含む）を置き換える場合と、（３）ユーザーが単にブラウザを閉じる場合である。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
欠点の１つは、各ポータルページの要求（即ち、新しいページへ行く要求）に対して、最後のページがセッション終了を必要とするアプリケーションを含んでいれば、ブラウザ内のＳＴＡからの第２の要求もある点である。これは、サーバーセッション終了を頻繁に使用する場合、各ポータルページの要求に対して、ブラウザから２つの要求が来る。第１は、コンテントサーバーに対するセッションを終了する要求（ＳＴＡは保存されたＡＴＵを送る）であり、第２は、“次のページ”に対する、ポータルサーバーへの要求である。ブラウザには使用できる帯域幅と接続部の数に制限があるため、終了の要求が事実上その“次のページ”のコンテントを遅延させる。
【課題を解決するための手段】
【０００８】
クライアント／サーバーセッションを管理するシステムと方法が開示されるが、そこでは、クライアントがブラウザを使ってコンテントサーバーからコンテントを要求する。セッションに関係するコンテントは、コンテントサーバーからのセッション終了ＵＲＬと共にブラウザで受け取られ、そのコンテントとセッション終了ＵＲＬは、ポータルサーバーからブラウザで受け取ったポータルページへと渡される。新しいセッションに対する要求は、ブラウザからポータルサーバーへ送られ、この要求には、セッション終了ＵＲＬが含まれる。セッション終了ＵＲＬは、セッションを終了するために、ポータルサーバーによって、コンテントサーバーへ送られる。
【０００９】
一実施形態に従って、ブラウザと、ブラウザへポータルページを与えるポータルサーバーと、ポータルページへコンテントを与えるコンテントサーバーとの間のセッションを管理するための一方法が記載される。この方法には、ポータルサーバーにおいて、ブラウザによる新しいポータルページの要求を受け取る動作が含まれる。本方法は、さらに、コンテントサーバーへのポータルサーバーによって、セッション終了ＵＲＬを送って、セッションを終了する動作が含まれる。
【００１０】
他の実施形態に従って、セッション管理システムには、ポータルページをブラウザへ与えるポータルサーバーと、コンテントをポータルページに与えるコンテントサーバーとが含まれる。一態様において、ポータルサーバーはブラウザによる新しいポータルページに対する要求を受け取り、応答において、セッション終了ＵＲＬを送ってセッションを終了するように構成されている。
【００１１】
１つ或いは２つ以上の実施形態が、添付の図面と以下の記載によって説明される。他の特徴と利点とは、記載と図面および特許請求の範囲から明らかになるだろう。
【００１２】
下記の図面を参照して、以上に述べた側面とその他の側面とが詳細に説明される。
【００１３】
様々な図面における近似した参照記号は、近似した要素を示している。
【発明を実施するための最良の形態】
【００１４】
本明細書には、セッション管理のシステムと方法とが記載され、それらは、ユーザーがセッションベースのアプリケーションを離れた時、或いはアプリケーションがサーバーから読み出された際に通るブラウザを閉じた時に、サーバーへの通知が可能である。ページ要求と同じ時にブラウザから終了要求ＳＴＵを送る代わりに、ページ要求のみがポータルサーバーへ送られ、ポータルサーバーはＳＴＵをアプリケーションサーバーへ送る。従って、全ての終了要求は、ポータルサーバーから送られる。ブラウザが同時に扱うことができる要求は２つだけなので、ブラウザ側からのＳＴＵは最早必要なく、ポータルサーバーからブラウザへコンテントをより簡単により速くロードするために、通信の制限を解くことになる。こうして、ＳＴＵは、新しいページに対するページ要求と共に、パラメータとしてポータルサーバーへ渡される。
【００１５】
セッションの終了は、ユーザーが、ブックマークやブラウザに記憶された同様のものなどの“お気に入り”の一覧表から何かを選択し、これによってポータルのフレームワークページを置き換える時、あるいは単にブラウザアプリケーションがクライアント上で閉じられた時に起きることがある。これらの終了の場合は、依然としてフレームワークのレベルで“未ロード”機構によって扱われる。
【００１６】
図１は、ウェブアプリケーションセッションを実行するための、企業通信システム１００を示している。このシステムには、ブラウザ１０４を使い接続部１０５を経由してポータルサーバー１０６と通信するクライアント１０２と、接続部１０７を経由するアプリケーション／コンテントのサーバー１０８（以降“コンテントサーバー”と呼ぶ）とが含まれる。コンテントサーバー１０８は、ＡＳＰの一部であり得る。ポータルサーバー１０６は、企業や共同のツールのようなポータルページをクライアント１０２中のブラウザ１０４に差し出す。ポータルサーバー１０６とコンテントサーバー１０８は、同じサーバーコンピュータの一部であったり、別個のコンピュータの中に置くことができる。
【００１７】
一実施形態に従って、ブラウザ１０４は、接続部１０５を通ってポータルサーバー１０６から１つのページを要求するのに使われ、通信（１）で示される。ポータルサーバー１０６は、（２）において、要求したページを送ることによって応答する。ページには、ポータルサーバー１０６によって生成された、１つ或いは２つ以上のＵＲＬを持ったＩＦＲＡＭＥが含まれ、それは指名されたコンテントサーバー１０８を示す。コンテントサーバー１０８への少なくとも１つのＵＲＬが、（３）において、接続部１０７を通ってブラウザ１０４から要求される。
【００１８】
新しいページがブラウザ１０４から要求され、この時に、ユーザーは第１のアプリケーション、そしておそらく関連するセッションを“離れ”ようとする。前もってＳＴＡ１１２によって受け取られているＳＴＵ１１０は、次に引数として、ブラウザ１０４によって生成されたページ要求ＵＲＬ（５）へと渡される。
【００１９】
従って、ＳＴＵ１１０は、ＵＲＬパラメータとして、ブラウザによって、次のページに対する要求へ渡され、“ユーザーがページを離れた”ことを表すトリガーは、ブラウザ１０４のページ未ロードのイベントによってでなく、“次のページが要求された”ことを表す情報によって、現れる。これによって、ＳＴＵ１１０がポータルサーバー１０６から送られることが可能になり、ブラウザ１０４を解き放って、コンテントをロードするのに接続部１０５と１０７の両方を用いることができるようになる。
【００２０】
図２は、一実施形態による、インターネットセッションを管理するための方法２００を示している。段階２０２において、ブラウザは、ポータルサーバーからポータルページを要求する。ポータルページは、共同ツールのような何らかの情報を含むこと或いは、ウェブベースのアプリケーションに対する要求であることが可能である。段階２０４において、ポータルサーバーは、要求されたポータルページと、ブラウザに対する関連したＳＴＡとを、コンテントサーバー内の適切なページに対する少なくとも１つのＵＲＬと共に送る。段階２０６において、ブラウザは、ＵＲＬに関連したコンテントサーバーからコンテントを要求する。そのコンテントは、アプリケーション或いは、アプリケーションが使うデータであろう。段階２０８において、ブラウザは、コンテントサーバーからセッションに対するＳＴＵと共に要求されたコンテントを受け取る。段階２１０において、ブラウザは、ＳＴＵを、ブラウザ内で予め生成され受け取られたＳＴＡへと渡す。
【００２１】
セッション管理方法２１１の特定の実施形態に従って、ブラウザは、段階２１２において、ポータルサーバーから新しいページを要求することができる。ブラウザは、ＳＴＵを新しいページ要求ＵＲＬへ、引数或いはＵＲＬのパラメータの種類として渡す。段階２１４において、ポータルサーバーは、ＳＴＵを、ブラウザから独立して、ポータルサーバーとコンテントサーバーとの間の接続部上をコンテントサーバーへと送る。段階２１６において、ブラウザは、要求を送ることと、ポータルサーバーとコンテントサーバーの両方からコンテントとデータとを受け取ることを続けて、ポータルサーバーとコンテントサーバーの接続を、より効率的に利用するようにする。
【００２２】
図３は、別の実施形態に従って、ウェブアプリケーションセッションを実行する、企業通信システム３００を示している。システム３００には、ページ生成器３２２によって生成されて、ポータルサーバー３１２によって配付される、ポータルページ３０２が含まれる。ポータルページ３０２は、コンテントサーバー３０８から配られた、アプリケーション３０４の１つ或いは２つ以上のインスタンス、即ち、１つ或いは２つ以上のウェブページとそのコンテントを表示する。
【００２３】
アプリケーション３０４の各インスタンスは、最終的に、クライアント３１０上で動作するブラウザ内に表示される。ウェブアプリケーションセッション３００のアプリケーション３０４も、ローカルクライアントアプリケーションから、或いは他のコンテントまたはアプリケーションサービスからのコンテントのような、他のウェブコンテントと同時に表示される。ポータルページ３０２には、アプリケーションセッション情報に基づいた各アプリケーションセッションを管理するためのＳＴＡ３０６が含まれる。ＳＴＡ３０６は、ページレベルのスクリプトコードであって良い。
【００２４】
ユーザーが前に閲覧したページを訪れるために、サーバープラットフォーム３０８は、セッションのいくつかの“状態”、即ちユーザーが前に閲覧したページを訪れることができるような、アプリケーションのインスタンスに関する情報を保持する。一実施形態において、サーバープラットフォーム３０８には、ユーザーが離れたアプリケーションのセッションの状態を保存するためのセッションメモリ３０９が含まれる。その状態には、インスタンス識別子が含まれ、さらにその中には、セッションの各ページのページ識別子が含まれる。インスタンス識別子は、セッション内の訪れた各ページに対して保存することができ、従って、多くのインスタンス識別子を持ったメモリを提供する。それゆえ、サーバーの状態から、セッションの“現在のページ”が分かる。
【００２５】
ポータルサーバー３１２には、ＵＲＬ生成器３２０も含まれる。ユーザーは、セッション内とアプリケーション外部をナビゲートするので、ポータルサーバー３１２のＵＲＬ生成器３２０は“外部セッションＩＤ”（ＥＳＩＤ）を提供する。ＥＳＩＤは、アプリケーションの２つのインスタンス間の差である引数であり、サーバー内の異なる／独立したセッションへと導く。ページを再訪するためのＵＲＬは、アプリケーションと、アプリケーションのインスタンスを識別するＥＳＩＤを識別するが、他の点では“目標のページ”に関する情報は持っていない。コンテントサーバー３０８は、どのページを見せるか、セッションはどこにいるのかに関する情報を保存する。従って、ユーザーが同じページへ戻ると、ＥＳＩＤは個々のアプリケーション要求と共に再び渡され、コンテントサーバー３０８は、その後、正しいセッションに論理的に再接続して、ユーザーに継続させることができる。
【００２６】
ユーザーがセッションを再訪問することを望み、そのセッションを離れた時と同じ状態で表示されるセッションのページを持っている時は、ポータルページ３０２は、サーバープラットフォーム３０８へ、要求されたページに関連するＥＳＩＤと同様に、要求されたページに対する開始ＵＲＬを送る。
【００２７】
ＥＳＩＤを用いることで、ユーザーがページを離れた時に、閲覧状態が保存され、ユーザーが再訪するときに再び見付けられる。ＥＳＩＤは、ＥＳＩＤが共有されている時以外は、ページ識別子（pageID）を含むようにフォーマットすることができる。ユーザーは、ポータルページ３０２を通して、あるいはブラウザ／クライアント３１０上のいずれかで２つ以上のウィンドウを使用することができるので、ＥＳＩＤもウィンドウ識別子（windowID）を備えるだろう。代わりに、ＥＳＩＤは、同じページが多くのポータルページ３０２によって共有されるようなセッションへと導くように明記することができる。従って、同じＥＳＩＤを異なる場所から、また多くの経路上において指定することができる。
【００２８】
ＥＳＩＤは、ページの所有するものとして明記され、サーバープラットフォーム３０８へＵＲＬ経由で渡すことができる。要求のあったアプリケーションがＥＳＩＤ内にない場合は、アプリケーションは単に要求のある度にやり直す。サーバープラットフォーム３０８がＥＳＩＤと開始ＵＲＬを受け取ると、マッピングモジュール３１６は、ＥＳＩＤを特定のセッションにマップする、即ち、対応するＥＳＩＤが既にセッションメモリ３１９内に記憶されているかどうかを調べる。もしＥＳＩＤが存在しなければ、サーバープラットフォーム３０８は、要求されたアプリケーション３０４のセッションの新しいインスタンスを作る。もしＥＳＩＤが存在すれば、サーバープラットフォーム１０８はアプリケーション１０４を開始し、それをポータルページ１０２へと保存された状態で渡す。
【００２９】
ＥＳＩＤは、ポータルサーバー３１２に計算され定義されて、コンテントサーバー３０８上のアプリケーションを開始する要求と共に渡される。このＥＳＩＤは、特定のセッションに対して、コンテントサーバー３０８上に“インスタンス／セッション”を定義する。ＥＳＩＤの使用法の１つに、多数の後方セッション（backend session）を管理して、ユーザーに戻って来させるものがあり、これは“後方許可（backend enabling）”として知られる。ＥＳＩＤは、また、セッション管理を簡素化する。コンテントサーバー３０８は、同じＥＳＩＤが後にそのコンテントサーバー３０８に対する単一の定義済み終了ＵＲＬへの引数として再度使われるだけなので、終了ＵＲＬを送る必要は全くない。その後、サーバーは所定のＥＳＩＤでセッションを閉じる。
【００３０】
ポータルの面から言うと、知っておくべき情報は、現在表示されているページ上で、どのＥＳＩＤが使用されているかであり、この情報はポータルサーバー３１２内に保持される。そして、“新しいページ要求”の情報／イベントが、サーバーセッション終了（即ち、ＳＴＵの送出）を引き起こすことができる。こうして、ポータルサーバー３１２の側で、ページ提供側（renderer）は新しいページが要求される度にセッションマネージャ３０６に知らせるだけであり、セッションマネージャ３０６は、ポータルサーバー３１２から直接来たＥＳＩＤを含むＳＴＵを送る。こうして、ＳＴＡを持ち、ＳＴＵを受け取り、ＳＴＵを次のページに対する要求と共に渡すという必要性は無くなった。
【００３１】
従って、“現在のセッションを終了する”ことを定義するイベントは、ブラウザ３１０から別個のＵＲＬを渡される（ＩＦＲＡＭＥ内で“未ロード”によって引き起こされる）ことはないが、“新しいページ”に対して尋ねられてポータルサーバー３１２内で管理されるところのページ提供側によって引き起こされる。
【００３２】
これまで、少しの実施形態を詳細に説明したが、他の変更も可能である。図２に描いた論理フローは、必ずしも、望ましい結果を達成するのを示す特定の順序を必要としない。他の実施形態が、添付の特許請求の範囲の範囲内に入るであろう。
【図面の簡単な説明】
【００３３】
【図１】一実施形態に従ったインターネットセッションを実行するためのシステムの図である。
【図２】インターネットセッションとセッションを管理するための技術の図である。
【図３】他の実施形態に従ったウェブアプリケーションセッションを実行するためのシステムの図である。
【符号の説明】
【００３４】
１００…企業通信システム
１０２…クライアント
１０４…ブラウザ
１０５，１０７…接続部
１０６…ポータルサーバー
１０８…コンテントサーバー
１１０…セッション終了ＵＲＬ（ＳＴＵ）
１１２…セッション終了エージェント（ＳＴＡ）
【図１】
0005043331.tif 000002
【図２】
0005043331.tif 000003
【図３】
0005043331.tif 000004