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