JP2004518219A - ポータル構造におけるセッション管理に関する機構及び方法 - Google Patents

Abstract

本発明は、ポータルコア（１）及び複数のサービス／アプリケーション（２６）を有し、サービス／アプリケーション（２６）へのアクセスをエンドユーザ局（５）に提供するポータル構造に関する。ポータルコアはプレゼンテーション機構と、セッション関連情報、例えばセッションＩＤを生成するポータルセッション管理手段（１３）と、セッション管理情報を記憶するポータル記憶手段（５１）を有する。サービス／アプリケーション（２６）の少なくともいくつかは外部セッションＩＤとともに外部に存在する。セッション統一手段（５０）はポータルセッションＩＤと外部セッションＩＤとのマッピングを行うために設けられる。ポータルコア（１）と外部サービス／アプリケーション（２６）との通信には、外部ＩＤが用いられ、一方でエンドユーザ局（５）とポータルコア（１）との通信にはポータルセッションＩＤのみが用いられる。

Description

【０００１】
（技術分野）
本発明はエンドユーザ局にサービス／アプリケーションへのアクセスを提供する、セッション管理及びポータル構造、特に、インターネットポータルに関する。本発明はまた、セッション管理に用いられるポータル構造における機構に関する。本発明は更に、ポータル構造におけるセッション管理方法であって、エンドユーザが前記ポータル構造を介してサービス／アプリケーションにアクセスするためのセッション管理方法に関する。
【０００２】
本発明は特に、ポータル、サービス又はアプリケーションといった異なるエンティティが異なるセッション管理手段によって管理される際のセッション管理の取り扱いに関する。
【０００３】
（技術状況）
ポータルと言われる場合、それは一般にはインターネットポータルを意味する。インターネットポータルはエンドユーザと相互作用し、通常、エンドユーザのアクティビティの追跡及び制御維持を可能とし、また認証ステータス、起動されたアクション及びその結果の順番及びリスト等のユーザ固有情報を記憶するためのセッション管理を提供する。今日、ポータルは、他のソフトウェアシステムの機能や、他のポータルの機能すらも統合可能としなければならないことがしばしばある。しかし、そのような、サービス／アプリケーション又は他のポータルといった他のシステムは、独自のセッション管理を持つことがある。これは、ある意味では、異なるセッション管理手段によって提供されるような他のセッション管理を、統合又は結合する必要があることを意味する。
【０００４】
さらに、サービス又はアプリケーションの実際の位置や、プロバイダが誰かとは無関係に、エンドユーザがサービスにアクセス可能な方法をパーソナライズ又はカスタマイズすることに対する要求も増加している。さらに、モバイルインターネットサービスへのアクセス要求もその重要性を増している。すなわち、エンドユーザは高速かつ複雑でない方法で、どんなエンドユーザ局からも、すなわち移動端末からもサービスへアクセス可能であることを望むであろう。それは、例えば、ユーザフレンドリで、素早く簡単な方法により、固定エンドユーザ端末からだけでなく移動端末からも、電子メールの送受信、ショートメッセージ、ウェブベースの情報へのアクセスを行うことに関連するであろう。これはモバイルインターネットと呼ばれる。
【０００５】
しかしながら、移動端末はパーソナルコンピュータ（ＰＣ）と比較して入出力能力が限られているため、移動端末を用いたブラウジングは、ＰＣを用いたブラウジングよりも難しい。従って、これは、満足のいくパーソナライゼーションを移動ユーザに提供することがより困難であること、またセッション管理だけでなくサービスの管理もより複雑になることを意味する。いずれにせよ、常にアプリケーション及びサービスにアクセス可能であるよう、エンドユーザの立場にたった要求が強まっている。ポータルは、特にエンドユーザの好みに合うようにあつらえられるべきサービス及びアプリケーションのコンテンツへの戸口のようなものである。
【０００６】
ポータルコンテンツの例は情報サービスである（インターネット技術に関連し、インターネット技術を通じてユーザが購読している全ての情報や、サービスプロバイダ又はオペレータがユーザに配信すべきであると考える情報を自動的に配信するプッシュコンテンツを含む）。情報サービスの例には天気予報又は天気情報一般、ショッピングモールといった商用サービス、又は任意の種類の情報、ストリーミングオーディオ／ビデオといったマルチメディアサービス、ゲーム、インスタントメッセージ及びニュースグループ、ウェブメール（ｗｅｂ−ｂａｓｅｄ ｍａｉｌ）、チャットルームを通じた特定のコミニュティへのアクセスがある。
【０００７】
さらに、アプリケーション及びメニューをＰＣに呈示するための魅力的なグラフィカルユーザインタフェースを提供可能であること、また、特にポータルがモバイルである場合、ＷＡＰ利用可能な装置のための同様のグラフィカルユーザインタフェースを提供可能であることが望ましい。さらに、パーソナルポータルの構成及びコンテンツのパーソナライズに対し、またパーソナルプリファレンスの設定によって個々のサービス及びアプリケーションの動作及び挙動（ｉｎｔｅｒａｃｔｉｏｎ ａｎｄ ｂｅｈａｖｉｏｒ）の制御を可能とするために、多くの労力が払われる。しかしながら、エンドユーザが用いる端末の種類を問わすに満足のいくアクセス実現性を提供するのは困難である。特に、異なるシステムを統合する必要がある場合、セッション管理と言う点に関し、すなわち、異なるシステム（ポータル、サービス／アプリケーション、他のポータル等）が独自のセッション管理を有する場合、状況は非常に複雑なものになるであろう。
【０００８】
これまで、多くのアプリケーションは基本的に第２世代（２Ｇ）電気通信環境に特化して設計され、モノリシックなブロックとして、又は個々のアプリケーションに対する特定のサービス品質（ＱｏＳ）要求を取り扱うための独自サービス網によって実現されてきた。その結果、そのようなアプリケーションは孤立したアプリケーションとしては満足に機能するが、同じような方法で開発された他のアプリケーションと統合することは困難である。インターネット（インターネットプロトコル）環境用に開発されたアプリケーションは、異なるアプリケーションの広範囲に渡る統合をサポートする、確立されオープンなデファクトスタンダードに大方基づかねばならない。２Ｇ環境において用いられてきたそのような規格の多くは、実時間での処理が重要でないアプリケーションに対するものであった。しかし、第３世代（３Ｇ）ネットワーク（３ＧＰＰ）の導入を通じ、将来のアプリケーションはリアルタイム及び非リアルタイムトラフィックのみならず、高低ビットレートが混合した、音声通信及びデータ通信サービスの混合物を含むであろう。今日のサービスネットワークはそのような混合物を取り扱うようには設計されておらず、また既存のＩＰベースのアプリケーションは無線ネットワークに関する特定の特性に対して設計されていない。
【０００９】
このように、エンドユーザからサービスに対する満足のゆくアクセスを提供するには、多くの複雑な要因が存在し、特にセッション管理が、異なるシステム／エンティティ用の異なるセッションマネジャにより取り扱われる際は顕著である。
【００１０】
均質なポータル環境のセッション管理は、明確に規定することが可能であり、例えばサーブレットセッションＡＰＩ（Ａｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）仕様又はセッションＥＪＢ（Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ Ｂｅａｎｓ）仕様に基づいて実施することができる。これらの仕様はセッション管理のための基本的な動作、すなわちセッションの生成／破棄（ｃｒｅａｔｅ／ｄｅｓｔｒｕｃｔ）及び、構築されたセッションにおける鍵値ペアの取得、設定及び消去のための動作を規定する。
【００１１】
インターネットポータルには通常、エンドユーザが起動したアクションの追跡を可能にするセッション管理システムが設けられている。そのようなアクションには、例えばエンドユーザ入力システム、エンドユーザの認証、エンドユーザによるポータルサービスへのアクセス等が含まれる。エンドユーザがポータル内部でナビゲートしている限り、すなわち、そのポータル内のサービス／アプリケーション（ここでは、主にそのポータル内でセッション管理が処理されるサービス／アプリケーションを意味する）へのアクセスが要求されている限り、どのポータルサービスも主セッションマネジャ、すなわちポータルセッション管理手段に対し、そのエンドユーザのセッションに保存された情報の読み出しを要求可能であるため、セッション管理は容易に処理できる。
【００１２】
しかし、エンドユーザが外部システム又はポータルに統合されたサービス又はアプリケーション、又は外部サービス／アプリケーション（ここでは、外部セッション管理又は独自のセッション管理を有するサービス／アプリケーションを意味する）へのアクセスを要求した場合、状況は異なり、非常に複雑な状況になりうる。深刻な問題は、エンドユーザがあるポータル構造を介してアクセスを希望するサービス又はアプリケーション（又は他のポータル）が、独自のセッション管理を有する場合、その外部セッション管理がポータルセッション管理と非互換でありうることである。
【００１３】
これは、アプリケーションサービスプロバイダがポータルオーナにサービスを提供する際には良くあることである。様々な理由により、外部セッション管理がエンドユーザに見えることは望ましくない。さらに、外部セッション管理をも考慮して生成されたセッションは非常に長くなりがちである。すなわち、エンドユーザとの通信に用いられるセッションＩＤ（ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｔｙ）は、ポータルセッションＩＤだけでなく、それに加えて外部セッションＩＤをも含まなければならない。このように非常に長いセッションＩＤはポータルが提供するクライアントでは処理できない。これは、エンドユーザ局が、単純かつそのような大量のデータを処理できないであろう、ＷＡＰ端末のような移動端末である場合に特に深刻である。識別目的のみにそういった量のデータを処理可能なエンドユーザ局についても、リソース及び時間の無駄が生じる。
【００１４】
（発明の概要）
従って、アクセスされるシステム／サービス／アプリケーションのセッション管理が、他の、異なるセッション管理システムによって処理される場合であっても、簡単かつ効率的な方法でセッション管理を処理可能なポータル構造が必要である。特に、ポータル構造が独自のセッション管理手段を有し、エンドユーザがアクセスを要求した、サービス、アプリケーション及び他のポータルと言った他のシステムがその特有の（ここでは外部と表記される）、又は独自のセッション管理手段を有する場合、簡単かつ効率的なセッション管理が必要である。特にポータル及び外的にセッションが管理される（外部）システムとの間のセッション管理のシームレスな統一が必要である。さらに、第３者のセッション管理手段によってセッション管理される、サービス／アプリケーション又はポータルと言った他のシステム又は外部セッション管理手段に存在するセッション管理を、ポータルセッション管理と結合及び統合可能なポータル構造が必要とされている。
【００１５】
また、ポータル（内部）セッション管理及び、第３者又は外部セッション管理システムの様々なセッション管理方法を、統一セッション管理に統一可能な機構（ａｒｒｅｎｇｅｍｅｎｔ）が必要とされている。特に、内部サービス／アプリケーションのみならず、外部セッション管理手段（第３者セッション管理手段）、すなわちポータルセッション管理手段とは異なるセッション管理手段によってセッション管理が処理されるサービス／アプリケーションをもエンドユーザに提供することの可能なポータル構造が必要とされている。従って、エンドユーザは、サービス／アプリケーション（コンテンツ）がポータル構造そのものの内部に位置するか否か、又はアプリケーション／サービス及びそのコンテンツがポータルの外部にあるか、すなわち外部プロバイダによって提供される及び／又は外部セッション管理手段によってセッションが管理されるか否かとは無関係に、サービス等へのアクセスを提供されるはずである。
【００１６】
特に、アクセスされたサービス／アプリケーション等がセッション管理が内的になされるか外的になされるかに関わらず、（固定エンドユーザ局に加えて）モバイルエンドユーザ局からのアクセスを可能にするポータル構造が必要とされている。また、エンドユーザとの通信に使用しなければならないパラメータの数が、従来のポータル構造と比較して、またアクセスされたサービス／アプリケーションがポータル内部にあるか否か及び、それらが個別にあるいは外的にセッション管理されるか否かとは無関係に削減されるようなポータル構造が必要とされている。特に、インターネットに接続された任意のＰＣ、ＷＡＰ端末又は任意のモバイルアクセスネットワークを用いる他のいかなる移動端末からもアクセスが可能なように、インターネット及びＷＡＰベースのサービスを統合すると同時に、異なるセッション管理方法を統合可能なポータル構造が必要とされている。
【００１７】
また、上述の目的の１つかそれより多くを満足できる、ポータル構造におけるセッション管理処理及び統合のための機構が必要とされている。さらに、サービス／アプリケーションがポータルセッション管理手段又は外部セッション管理手段のいずれによってセッション管理されるかとは無関係に、ポータル構造内のセッション管理を処理するための方法及びエンドユーザにサービス／アプリケーションへのアクセスを提供する方法であって、上述の目的の１つかそれより多くを満足できる方法が必要とされている。
【００１８】
ポータルにおいて汎用マークアップ言語を用いることにより、アプリケーション及びサービスのコンテンツをユーザ局又はユーザ端末とは独立して記憶することが可能であり、アプリケーション又はサービスのコンテンツを呈示する前に、そのコンテンツをエンドユーザ端末が理解可能な形式、すなわちマークアップ言語に変換することが可能である。そのような汎用マークアップ言語の一例は、ＸＭＬ（Ｅｘｔｅｎｄｅｄ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）である。ＸＭＬベースのポータルにおけるナビゲーションのための標準としてＸＬｉｎｋ仕様が用いられ、この仕様においてはリソース間のリンクを生成及び記述するために、要素がＸＭＬ文書中に挿入されることを可能としている。ＸＬｉｎｋは基本的な単方向リンク及び、より複雑なリンク構成の両方を生成するためのフレームワークを提供する。さらに、ＸＬｉｎｋは、ＸＭＬ文書が、２つより多いリソース間のリンク関係をアサートすること、リンクにメタデータを関連付けること及び、リンクされたリソースから離れた場所にあるリンクを表現することを許可する。ＸＭＬは２０００年６月６日付けのＷ３Ｃ勧告、「拡張可能なマークアップ言語（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）（ＸＭＬ）１．０（第２版）」に記載されており、当該勧告は本明細書に引用して援用する。
【００１９】
以下、本明細書において使用するいくつかの概念について説明又は定義する。ポータルは、一般に、インターネットドメインにおける非物理的なエンティティであり、個人又は組織が所有する「電子出版スペース（ｅｌｅｃｔｒｏｎｉｃ ｐｕｂｌｉｓｈｉｎｇ ｓｐａｃｅ）」として説明することができる。そして、情報又はサービスに対する直接アクセス又は、認証されたエンドユーザに対して情報又はサービスを提供するインターネット又はプライベートイントラネットドメイン内の他のエンティティへのリンクを提供する。ポータルの最も単純な形態は通常のホームページ（ｒｅｇｕｌａｒ ｈｏｍｅ ｐａｇｅ）やリンクのリストである。これに対し、より高度な形態では、出版物の消費者のみならず、編集者自身及び編集者からポータル上での出版権を許可されている者に対し、そのポータルがどのように用いられるかの異なる見知に関するインタラクティブサービスを提供することが可能である。
【００２０】
無線エンドユーザは、「サービス」ポータルを通じてアクセスを得る。そのような「サービス」ポータルは、ＰＣ用の伝統的な、固定されたインターネットポータルとは異なり、またエンドユーザは、パーソナライズされたサービスが、少なくともオプションとして、自分の移動端末に対して配信され、また表示されることを要求する。以下の説明において、「サービス」ポータルという言葉は用いないが、本明細書においてポータル（ポータル構造）とは伝統的なポータル又は「サービス」ポータルのいずれかを意味する。
【００２１】
アプリケーションは１つ又はいくつかの協働ソフトウェアエンティティであり、機能的な焦点はエンドユーザのためのユーザインタラクション及び有用性である。アプリケーションプラットフォームは、構成成分の機能性及び品質によって特徴付けされるある種のアプリケーションを実施するために用いられるソフトウェア及びハードウェアエンティティの定義済み組み合わせ（ｄｅｆｉｎｅｄ ｃｏｍｂｉｎａｔｉｏｎ）である。
【００２２】
一般論として、ポータルインフラストラクチャとは、特定のポータルの主催（ｈｏｓｔ）、形成（ｐｒｏｄｕｃｅ）又は生成に必要とされるソフトウェア及びハードウェアエンティティを意味する。具体的には、ポータルインフラストラクチャはポータルコア、ＩＰインフラストラクチャ及びサービスイネーブラを含む。
【００２３】
サービスイネーブラとも呼ばれるサービスイネーブル手段は、ＡＰＩ（Ａｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を介してアクセスされるサポート機能であり、抽象化レベルの引き上げ及びアプリケーション開発者のタスクを単純化する。ポータルコアはポータルインフラストラクチャのコアであり、すなわちポータルコアは、内部のコンテンツ及びアプリケーションが、制御及び統一された方法によってエンドユーザによって開示又はアクセスされることの可能なポータルフレームワークを開発するために必要とされる、ポータル構造の中心部である。サービスネットワークは一般にはＩＰベースのネットワークを意味し、ノードホスティングアプリケーションサーバ、サービス機能サーバ（ｓｅｒｖｉｃｅ ｃａｐａｂｉｉｉｔｙ ｓｅｒｖｅｒ）、アプリケーションサポートサーバ、ＩＰインフラストラクチャサーバ等を含む。アプリケーションサポートサーバはサービスネットワークリソース又はコアネットワーク以外の他の外部リソースをインタフェースし、一方サービス機能サーバはコアネットワーク内のリソース及び機能をインタフェースする。
【００２４】
本願において、ポータル構造はポータルコア、複数のサービス及びアプリケーション及びそのコンテンツ、及びサービスイネーブル手段（サービスイネーブラ）を意味することが意図されている。通常は、さらに接続性及びデータベアラも含まれる。しかし、本発明の機能に重要なのはポータルコアの構成要素である。解決されるべき問題は、特にアクセスされたサービス／アプリケーションがポータル構造自身のセッション管理手段とは別の手段によってセッション管理されている場合に存在する。
【００２５】
従って、本発明は、エンドユーザ局にサービス／アプリケーションへのアクセスを提供し、ポータルコア（及びサービスイネーブル手段、エンドユーザアクセスを提供するための接続性手段）を有するポータル構造を提供する。ポータルコアはプレゼンテーション機構、セッション関連情報、例えばセッションＩＤを生成、処理するポータルセッション管理手段、及びセッション関連情報を格納する記憶手段を有する。ポータルコアはさらに、これ以上は説明されない加入者管理手段を含む。サービス／アプリケーションの少なくともいくつかは、外部サービス／アプリケーションを含む。外部サービス／アプリケーションは、外部アプリケーション／サービスセッション関連情報、例えば外部セッションＩＤを生成、処理する外部セッション管理手段によってセッション管理される。
【００２６】
ポータルセッション管理手段は、ポータルセッションＩＤと、外部サービス／アプリケーションセッションＩＤ情報とをマッピング又は変換するセッション統一機構を有する。ポータルコア及び外部サービス／アプリケーションとの通信には、外部サービス／アプリケーション外部（独自）セッションＩＤが用いられる。一方、エンドユーザ局とポータルコアとの通信には、ポータルセッションＩＤのみが用いられる。特にサービス／アプリケーションは汎用マークアップ言語、とりわけＸＭＬ言語を生成する。
【００２７】
好適な実装において、あるセッションにおいてアクティブな全ての外部サービス／アプリケーションに対する外部セッションＩＤ情報は、少なくとも個々のセッションの期間に渡って、もしくは所定期間ポータル記憶手段に記憶される。期間は例えば、所与の期間セッション内に動き（ａｃｔｉｖｉｔｙ）が無ければ、もはや情報を記憶しておく必要がないといったように定めることができる。
【００２８】
特定の実装において、ポータル構造はモバイルである。ここでは、固定式のエンドユーザ局のみならず、例えばＷＡＰ端末といった移動エンドユーザ局からのアクセスもサポートするということを意味する。ポータル構造は、汎用マークアップ言語形式のサービス／アプリケーションデータを、エンドユーザ局が用いる、又は理解可能な異なるマークアップ言語に翻訳するレンダリング手段を含む。汎用マークアップ言語、特にＸＭＬが用いられるとすると、サービス／アプリケーションのデータは、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を用いた文書型定義（Ｄｏｃｕｍｅｎｔ Ｔｙｐｅ Ｄｅｆｉｎｉｔｉｏｎ：ＤＴＤ）言語によって定義される。
【００２９】
ＤＴＤは（ここでは）、その特定のＤＴＤに属するものとして見ることのできる全ての文書において許される、全ての要素及びその属性を記述するＸＭＬ文書である。ある実装において、自身の、あるいは外部のセッション管理手段を有する外部システム（サービス／アプリケーション）は、他のポータルを構成する。ある特定の実装において、基本セッション管理動作を定義するため、ポータルセッション管理はサーブレットセッションＡＰＩ又はセッションＥＪＢ仕様に従って動作する。これは、これら仕様が外的にセッション管理されるシステムからセッションを得るために使用可能であることを意味する。本明細書において、このシステムはバックエンドシステムとも呼ばれ、従って、少なくとも外的にセッション管理されているという意味において、外部のサービス／アプリケーションであってもよい。他のポータルが自身の、外部（独自）セッション管理手段を有していても良い。
【００３０】
本発明によれば、ポータルセッション管理手段は、エンドユーザのポータルへの入場、エンドユーザ認証、エンドユーザのサービス／アプリケーションへのアクセス等、特にエンドユーザが起こしたアクションに関する情報を、ポータル記憶手段に記憶する。
【００３１】
本発明によれば、エンドユーザがポータルからサービス／アプリケーションを要求すると、ポータルセッション管理手段によって、ポータルセッションＩＤとともにセッションが生成される。要求は、要求されたサービス／アプリケーションへ転送され、このサービス／アプリケーションが内部サービス／アプリケーションであれば、ポータルセッションＩＤを用いる。一方、サービス／アプリケーションが外的にセッション管理されている場合には、そのエンドユーザに対して外部セッションＩＤが生成され、そのＩＤがポータルとサービス／アプリケーションとの間の通信で用いられる。外的にセッション管理されるサービス／アプリケーションについて、外部セッション管理手段は、要求を行ったエンドユーザに対して生成された外部セッションＩＤ情報を、所定の期間、例えばそのセッションを通じて、もしくはそのセッションが所与の期間「インアクティブ」となるまで記憶する。
【００３２】
そのポータルから次の呼び出し要求が受信されると、すなわち、同一のサービス／アプリケーションに対し、同一のセッション内で同一のエンドユーザから次の呼び出しが受信されると、そのサービス／アプリケーション内のセッションを見つけるため、生成された外部セッションＩＤが用いられる。アプリケーションデータが生成され、アプリケーション情報データが外部セッションＩＤを用いてポータルへ送信される。外部セッションＩＤは、ポータルセッション統一手段により、ポータルセッションＩＤに変換／マッピングされる。
【００３３】
一実施形態において、ポータルセッション内に名前空間（ｎａｍｅｓｐａｃｅ）が生成され、アクセスされた外部サービス／アプリケーションセッションの各々について、情報データが名前空間内に記憶される。特に有利な実施形態において、外部サービス／アプリケーション又は外部セッション管理手段は、外部（独自）セッションを、エンドユーザがその外部サービス／アプリケーションへのアクセスをポータルを介して要求するためのサービス／アプリケーション（独自）外部セッションＩＤをとともに生成する。さらに、ポータルコアへ送信する、少なくとも１つの独自又は外部セッションＩＤを含むメタ情報タグを生成する。特に、メタ情報タグの全データは、要求したユーザについての対応するポータルセッション内に記憶される。
【００３４】
ある特定の実施形態において、汎用マークアップ言語、例えばＸＭＬの形式による、サービス／アプリケーションデータへのメタリンクの導入を通じ、サービス／アプリケーションコンテンツがどこにあるか、すなわち内部か外部か、とは無関係に、エンドユーザに連続的なナビゲーションが提供される。このメタリンクには、ポータルセッションＩＤがパラメータとして付加される。この目的のため、ポータルコアは、サービス／アプリケーションデータに含まれるそのようなメタリンクを処理するための（第１の）変換手段を有する。ポータルコアはさらに、汎用マークアップ言語形式のデータを、要求元エンドユーザ局（モバイル又は固定）が理解するマークアップ言語へ変換する（第２の）変換手段を有するレンダリング手段を含む。
【００３５】
上述した連続的なナビゲーションは、本発明において説明記述されるような統一セッション管理と、利点とともに結合されうる特定の有利な実装に関連する。サービス／アプリケーションによる、サービス／アプリケーションデータへのメタリンクの導入による連続的ナビゲーションの提供は、本願出願人による、本願と同日出願された同時係属のスウェーデン出願、「アプリケーション／サービスのアクセスに関する機構及び方法」に記載されている。当該同時係属出願の内容は本明細書に引用して援用する。
【００３６】
このように、大部分の有利な実施形態において、ポータル構造はモバイルであり、例えばＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｎｉｃａｔｉｏｎ）、ＷＣＤＭＡ（広帯域符号分割多元接続：Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、ＧＰＲＳ（ＧＳＭ汎用パケット無線サービス：ＧＳＭ Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）、ブルートゥース（短距離無線技術）、ＷＡＰ（無線アプリケーションプロトコル：Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）等の移動通信ネットワークを通じて移動エンドユーザ局によるアクセスをサポートする。好適には、ポータル構造は、ＷＡＰ端末等の移動端末のみならず、ＰＣ等のブロードバンド端末や、より一般的な固定端末によるアクセスをもアクセスする。
【００３７】
換言すれば、ポータル構造は、ポータル構造との通信に異なるアクセス形式又は異なるマークアップ言語を用いる固定及び移動エンドユーザ局によるアクセスをサポートする。
【００３８】
ある特定の実施形態によれば、サービス又はアプリケーションは、外部セッションＩＤ情報を含むメタ情報タグに加え、１つまたはそれより多い他のメタ情報タグをオプションで備えても良い。
【００３９】
本発明はこれに限定されないが、もし汎用マークアップ言語が用いられる場合、汎用マークアップ言語はＸＭＬであろう。ＸＭＬデータ及びおそらくメタリンクは、文書型定義言語（ＤＴＤ：Ｄｏｃｕｍｅｎｔ Ｔｙｐｅ Ｄｅｆｉｎｉｔｉｏｎ ｌａｎｇｕａｇｅ）によって定義される。ＸＭＬデータ中のメタリンクタグは、メタリンク形式、参照及び、サービス／アプリケーション位置情報を含むアドレッシング属性（ＵＲＬ）を有する。（レンダリング手段の）変換手段は、変形（ｔｒａｎｓｆｏｒｍａｔｉｏｎ）（ＸＳＬ）を実行することにより、ＸＭＬデータを変換する。すなわち、ＸＭＬデータは出力形式、すなわちアクセス元ユーザ局に適したマークアップ言語（例えば、固定エンドユーザ局にはＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、移動ユーザ局にはＷＭＬ（Ｗｉｒｅｌｓｓｓ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ））を生成するため、変形スタイルシートとともに処理される（ＸＳＬ変形）。ＸＳＬは、１９９９年１１月１０日付けのＷ３Ｃ勧告である、「ＸＳＬ変形（ＸＳＬＴ）（ＸＳＬ Ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ （ＸＳＬＴ））」バージョン１．０及び、２０００年１２月１２日付のＷ３Ｃ暫定ドラフトである同バージョン１．１に記載されており、これらを本明細書に引用して援用する。
【００４０】
特に、同一セッション中における、同一エンドユーザによる同一サービス／アプリケーションのその後のアクセスにおいては、外部セッションＩＤによって示される外部セッションが見つけられるよう、外部（独自）セッションＩＤを含む、記憶されたメタ情報が、ポータルセッション管理手段からセッション統一手段によって外部サービス／アプリケーション（外部セッション管理手段）へ転送される。
【００４１】
本発明はさらに、プレゼンテーション機構を有するポータルコア、セッション関連情報、例えばセッションＩＤを生成、処理するポータルセッション管理手段及び、セッション関連情報を記憶する記憶手段を有する、ポータル構造内の機構をも開示する。この機構は更に、ポータルセッション及び、外部サービス／アプリケーションを管理する外部セッション管理手段によって生成された外部セッションの管理を統一するセッション統一機構を有する。このポータルと、アクセス元エンドユーザ局との通信には、ポータルセッションＩＤ（のみ）が用いられ、ポータルと外部サービス／アプリケーションとの通信には、外部セッションＩＤ情報が用いられる。
【００４２】
統一手段は、ポータルセッションＩＤと外部セッションＩＤとをマッピングする手段を有する。外部サービス／アプリケーションＩＤ情報は、個々のポータルセッションにおいて、規定の時間、例えばセッションの間中、ポータル記憶手段に記憶しておくと好都合である。この機構は、特に、汎用マークアップ言語形式のサービス／アプリケーションデータを、要求元エンドユーザ局の形式に依存する他のマークアップ言語形式に変換し、サービス／アプリケーションデータを、サービス／アプリケーションへのアクセスを要求したエンドユーザ局へ出力ならしめるレンダリング手段を有する。特に、そのような汎用マークアップ言語はＸＭＬである。
【００４３】
好ましい実施形態において、外部セッションＩＤ情報は外部サービス／アプリケーションデータに導入されるメタ情報タグ内に与えられ、より詳細にはポータルセッションにおいて、メタ情報データが、ポータルセッション情報を記憶するポータル記憶手段に記憶される。特にポータルセッションＩＤは、パラメータとして外部アプリケーション／サービスデータに付加される。
【００４４】
その後、継続中のセッション中、ポータルに、あるエンドユーザによって同一の外部サービス／アプリケーションについて要求があると、その要求を外部サービス／アプリケーションに転送する際、すなわち、ポータルから外部セッションＩＤにマッピング／変換した後に、セッション統一手段によってメタ情報が要求中に含ませられる。
【００４５】
本発明はさらに、外的にセッション管理される外部サービス／アプリケーションがアクセスされた際の、ポータル構造におけるセッション管理方法も開示する。ポータル構造は、プレゼンテーション機構を有するポータルコア、セッション関連情報を生成、処理するポータルセッション管理手段及び、セッション関連情報を記憶する記憶手段を有する、この方法は、ポータルセッションが既に存在していなければ、エンドユーザがサービス／アプリケーションへのアクセスを要求した際にポータルセッションをポータルセッションＩＤとともに生成し、要求された外部サービス／アプリケーションへ要求を転送し、外部セッション管理手段により、外部サービス内に、又は外部サービスに対し、外部サービス／アプリケーションセッションを生成し、その要求を行ったエンドユーザに対して既にセッションが存在していなければ、外部セッション管理手段によって、外部サービス／アプリケーションセッションＩＤを生成し、
サービス／アプリケーションにおいて、
サービス／アプリケーションデータを生成し、
外部セッションＩＤに関する情報をサービス／アプリケーションデータに導入し、
外部セッションＩＤを含んだサービス／アプリケーションデータをポータルに返し、
ポータルにおいて、
外部セッションＩＤをポータルセッションＩＤにマッピングし、
外部セッションＩＤをポータル記憶手段内のポータルセッションへ記憶し、
サービス／アプリケーションデータを、ポータルセッションＩＤのみを用いて要求したエンドユーザに送信する、
方法である。
【００４６】
この方法は更に、エンドユーザによる外部サービス／アプリケーションへのその後の要求に際し、ポータル記憶手段内でそのポータルセッションを探索し、ポータルセッション関連情報が外部セッションＩＤを含んでいるかどうかをしらべ、もし含んでいれば、外部セッションＩＤを含んだ要求を、要求された外部サービス／アプリケーションへ転送し、外部セッションＩＤを用いて、サービス／アプリケーション又は外部セッション管理手段で外部独自サービス／アプリケーションを探索し、サービス／アプリケーションデータを生成し、外部セッションＩＤをサービス／アプリケーションデータに付加し、サービス／アプリケーションデータを外部セッションＩＤとともにポータルセッション管理手段等に送信するステップを含む。好ましい実施形態において、外部サービス／アプリケーションは汎用マークアップ言語、例えばＸＭＬを生成する。好ましくは外部セッションＩＤを付加するステップが、少なくとも外部セッションＩＤを含むメタ情報タグを生成し、外部サービス／アプリケーションデータへ導入するステップを含む。
【００４７】
本発明はさらに、ポータルセッション管理を外的にセッション管理されるシステムの外部セッション管理と統合する方法を開示する。この方法は、ポータルセッションＩＤと外部セッションＩＤとをマッピングし、生成されたポータルセッションにおけるポータル記憶手段に、外部セッションＩＤに関する情報を記憶し、ポータルセッションＩＤをエンドユーザ局との通信において使用し、外部セッションＩＤに関する情報を外的にセッション管理されるシステムとの通信に使用する各ステップを有する。
【００４８】
以下、添付図面を参照して、本発明をそれに限定されない態様において更に説明する。
（発明の詳細な説明）
図１及び図２を参照して、典型的なポータル構造を極めて詳細に説明する。このようなポータル構造は、図３〜７を参照して説明する本発明のコンセプトの実施に利用することができる。ただし、本発明が図１及び図２に説明されるようなポータル上で実施すべきであるものとは決して限定されず、本明細書の本セクションは主に、１つのポータル構造の典型的な基本的コンセプト及びその機能の一部を説明するものとして含まれていることは明らかであろう。
【００４９】
従って、図１は、本発明に係るポータル構造１０の一例を示す図である。ポータル構造１０は、プレゼンテーション機能、加入（ｓｕｂｓｃｒｉｐｔｉｏｎ）及びセッション管理機能を処理するポータルコア１と、例えば個人通信サービス、個人情報サービス及びモバイルＥコマースサービスを含む複数のサービス及びアプリケーション２を有する。簡単に言えば、どの種類のサービスが提供されるかは重要でなく、本発明のコンセプトはどのような種類のサービス、コンテンツ及びアプリケーションに対しても適用可能である。本発明のコンセプトのより詳細な説明（図３〜７）において、エンドユーザがサービス又はアプリケーションへのアクセスを要求する際、任意のサービス又はアプリケーション（又はコンテンツ）は、たとえその一部が実際にはポータル構造の外部に位置し、外部サービスプロバイダによって提供される場合であっても、概念的にはポータル構造に含まれるものを意味し、またそのようなものとして見ることができる。しかしながら、本明細書において、任意のサービス又はアプリケーション（又はコンテンツ）は、それらが外的にセッション管理される場合、すなわちそれらがポータルセッション管理手段によってセッション管理されない場合には「外部」と表記される。
【００５０】
ポータルコアポータル構造１は、サービスイネーブラとも呼ばれる複数のサービスイネーブリング手段３１−３７、３８Ａ−３８Ｄを含むレイヤ３をさらに含む。サービスイネーブラは、とりわけゲートウエイ及びＩＰインフラストラクチャといった、認証及び基本サービスに関与する。本図において、サービスイネーブラのいくつかの例は、統一メッセージング（ｕｎｉｆｉｅｄ ｍｅｓｓａｇｉｎｇ）３１、ＩＰインフラストラクチャ３２、ＡＡＡ−サーバ３３、通知サポート３４、課金サポート３５及び動作及び維持サポート３６といったものとして与えられる。サービスイネーブラの他の例は、モバイルポジショニングシステム３７、ＷＡＰゲートウエイ３８Ａ、ＳＭＳ−Ｃゲートウエイ３８Ｂ、マルチメディアプロキシ３８Ｃ、モバイルＥペイ（ｍｏｂｉｌｅ Ｅ−ｐａｙ）３８Ｄ等である。これらサービスイネーブラの一部はおおよそ必須であり、それ以外はオプションである。
【００５１】
ここでポータル構造は、接続性（ｃｏｎｎｅｃｔｉｖｉｔｙ）又は、移動基地局及び、ＢＴＳ（無線基地局装置：Ｂａｓｅ Ｔｒａｎｓｃｅｉｖｅｒ Ｓｔａｔｉｏｎ）、ＢＳＣ（基地局コントローラ：Ｂａｓｅ Ｓｔａｔｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ）、ＭＳＣ（移動通信交換局：Ｍｏｂｉｌｅ Ｓｗｉｔｈｉｎｇ Ｃｅｎｔｅｒ）ノード等といった交換ノードを含む（移動）ベアラレイヤを含むものとして見ることもできる。どのノードであるかは、どの移動ネットワークアクセスが例えばＧＳＭ上で提供されるかに依存する。ＧＰＲＳ又はＵＭＴＳに対応するノード、例えばＧＧＳＮ（ゲートウエイＧＰＲＳサポートノード）はこのレイヤに含まれる。どちらのネットワークであっても、ネットワークはＷＡＰ（無線アプリケーションプロトコル）端末といった移動端末のアクセス用ポータルのためのデータベアラである。図１において、ＷＡＰ電話機５を含むエンドユーザ局のアクセスがサポートされている。
このようなポータル構造の一例は、エリクソンＷＩＳＥ（登録商標）ポータルである。
【００５２】
内部アプリケーション又はサービスは、例えばモバイルサービス、統一メッセージング又はメールサービスとしてのとしての個人通信、個人情報サービスのような様々なカテゴリのモバイルインターネットアプリケーションにアプリケーション特定の値を付加するために、サービスイネーブラ及び接続性レイヤを利用するアプリケーションとして見ることができる。情報はサーチを通じてユーザによって検索されうるが、プッシュ技術によってエンドユーザに供給されても良い。これはエンドユーザがカスタマイズ可能である。
【００５３】
好適には、移動ネットワークを介した、ＷＡＰ電話機５といった移動エンドユーザ局によるアクセスを、ポータルがサポートするものとされる。従って、関連する移動ネットワークのノード又は構成要素は移動ネットワーク接続性及びデータベアラレイヤ内に提供される必要がある。図１において、ＩＳＰネットワーク（インターネットサービスプロバイダネットワーク）と表記される構成要素が開示される。これは任意の構成要素であり、含まれていてもいなくても良い。
【００５４】
サービスイネーブラ３を含むレイヤにおいて、ある形式のサービスイネーブラは必須であり、それ以外は必須でない。サービスイネーブラの一部は、モバイルインターネット機能を提供するための重要な構成要素として見られる。サービスイネーブラの一部は、インターネットと移動ネットワークとのインタフェース構成要素の一部として見られる。１つの構成要素はここでＩＰインフラストラクチャ３２と表記されている。オプションのサービスイネーブラは、通知サポート３４を含む。これは、アプリケーションがフィルタリングされた通知をＳＭＳ（ショートメッセージサービス）チャネル（ＷＡＰ技術及び３Ｇ（３ＧＰＰ）技術をサポートする他のチャネルを含むように適合されても良い）を用いてエンドユーザに送信することを可能にする、一般にはオプションの構成要素である。
【００５５】
課金サポートイネーブラ３５は、課金イベントを柔軟に選択可能とするために提供されうる。別のサービスイネーブラ３６は動作及びメンテナンスサポートに関連し、一般に必至の構成要素である。サービスイネーブラＷＡＰゲートウエイ３８Ａは、無線の世界とインターネットの世界の間のアクセスポイントを形成する、オプションサービスイネーブラＷＡＰゲートウェイ／プロキシである。これは、ＧＳＭ回線交換データ又はＷＡＰオーバＳＭＳ（ＳＭＳオーバＭＡＰ（モバイルアプリケーションプロトコル））を用い、ＷＡＰゲートウェイ／プロキシにアクセスするモバイルクライアントをサポートする。クライアントは、所望のＷＡＰアプリケーションが存在するウェブサーバに接続するため、移動端末内のＷＡＰ利用可能なブラウザを用いる。
【００５６】
別のサービスイネーブラ（モバイルポジショニングシステム）３７は、要求したアプリケーションにユーザの位置を送信することを可能にするオプション構成要素である。他のサービスイネーブラは、マルチメディアデータのＧＰＲＳ又はＵＭＴＳ上での伝送を担うマルチメディアプロキシ３８Ｃである。しかし、これはオプションサービスイネーブリング手段である。ＳＭＳ−Ｃ（中央）ゲートウェイ３８Ｂもまたオプション構成要素であり、移動局及びサーバ間のショートメッセージを送信、受信、記憶又は転送を担う。
【００５７】
アプリケーションとの通信には独自（ｐｒｏｐｒｉｅｔａｒｙ）プロトコルが使用される。モバイルＥペイ３８ＤはモバイルＥコマース用の基本機能を提供する構成要素であり、オプション構成要素である。ＡＡＡサーバ３３は認証（ａｕｔｈｅｎｔｉｃａｉｔｏｎ）、承認（ａｕｔｈｏｒｉｚａｔｉｏｎ）及び会計（ａｃｃｏｕｎｔｉｎｇ）に関するサービスイネーブリング構成要素である。この３つの機能は他の方法によって提供されうるが、これらはまた、例えばトラフィックベースの課金又は期間課金を可能にする機能性サーバに統合されうる。そのような構成要素は、それが異なる構成要素に分割されていても、複数の機能に共通な１つの構成要素で形成されていても必須であり、有利な実装においてセッション管理機能に用いられる。
【００５８】
しかし、図１がサービスイネーブリングレイヤ３に提供されうるサービスイネーブリング手段の例を単に示しているに過ぎないことは明らかであろう。図示されたサービスイネーブラの一部は排除され得るし、残りは依然として含まれ得るなどである。
【００５９】
ポータルコア、又はポータルコアレイヤは、上述したように、プレゼンテーション、加入及びセッション管理、及び複数の内部（及び外部）アプリケーションサーバを含むサービスティア（ｓｅｒｖｉｃｅ ｔｉｒｅ）を取り扱う。コア１は、複数のプロトコルを用いて複数の装置上でモバイルポータルプレゼンテーションを可能にするプレゼンテーション機構１１を有する。プレゼンテーション機構１１は、例えばＸＭＬ駆動型であってよい（又は、より一般的には汎用マークアップ言語により駆動される）。１つの実施形態において、プレゼンテーション機構１１はＪａｖａ（登録商標）及びＸＭＬ駆動型の、複数マークアップ言語処理可能なプレゼンテーションモジュールである。
【００６０】
プレゼンテーション機構１１はレンダリング手段（レンダリングエンジン）を有し、１つの実施形態においてレンダリング手段は、ポータル構造にアクセスした際にポータル内のサービスによって呈示される情報が、エンドユーザの用いるエンドユーザ局（又はブラウザ）の形式とは無関係に、標準化された方法で表示されることを確保するため、ＸＭＬ／ＸＳＬＴ技術を用いる。汎用マークアップ言語、例えばＸＭＬ／ＸＳＬＴ、の利用を通じて、エンドユーザに呈示されるコンテンツの”ルックアンドフィール”がカスタマイズされうる。ＸＳＬは拡張可能なスタイルシート言語（Ｅｘｔｅｎｓｉｂｌｅ Ｓｔｙｌｅ Ｓｈｅｅｔ Ｌａｎｇｕａｇｅ）の略称である。その内容を本明細書に引用して援用する、本出願人が本出願と同時に出願したスウェーデン特許出願、「ポータル構造におけるプレゼンテーションカスタマイズ方法及び機構（Ａｎ ａｒｒａｎｇｅｍｅｎｔ ａｎｄ ａ ｍｅｔｈｏｄ ｆｏｒ ｐｒｅｓｅｎｔａｔｉｏｎ ｃｕｓｔｏｍｉｚａｔｉｏｎ ｉｎ ａ ｐｏｒｔａｌ ｓｔｒｕｃｔｕｒｅ）」は、ここで説明するようなポータル構造におけるユーザカスタマイズに関連し、特に”ルックアンドフィール”のカスタマイズに関するものである。
【００６１】
特にポータルコア１内部、及びプレゼンテーション機構１１を、図２を参照して更に詳細に説明する。
ポータルコア１はさらに加入マネジャを含む。一実施形態において、加入マネジャ構成要素情報はＬＤＡＰ（ライトウエイトディレクトリアクセスプロトコル：Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）ディレクトリに記憶され、加入マネジャと呼ばれるサービスによって管理される。加入マネジャは加入者データベース中の加入者情報を生成、維持及び削除するためのオペレータ用機能を含む。加入マネジャはまた、システムのエンドユーザがシステム内のサービスに加入することを可能にする。
【００６２】
特定の実施形態において、カスタマーケアセンタの負荷を最小化することによってコストを最小化するため、自己登録（ｓｅｌｆ−ｒｅｇｉｓｔｒａｔｉｏｎ）及びセルフサービスの考え方がサポートされる。利用可能なサービスに関する情報は、上述したディレクトリにおいても保持され、加入マネジャによって管理されても良い。ディレクトリに新たなサービスが入力されると、それは直ちにエンドユーザが加入可能になる。新しいサービスを規定のエンドユーザ群にのみ利用可能とすることを可能にするため、ディレクトリ中でエンドユーザをグループ化することができる。加入マネジャ１２は、自らが用いるアプリケーションプログラミングインタフェース（ＡＰＩ）を通じ、既存のカスタマーケアシステムと接続されても良い。
【００６３】
セッションマネジャ１３はアプリケーション及びサービスが利用可能な汎用機構である。セッションマネジャ１３は、ポータルへの全ビジタを追跡し、またビジタのプロファイル情報を提供するため、サブシステムへのインタフェースを有する。エンドユーザがシステム／アプリケーションに入場すると、セッションＩＤエンティティが割り当てられ、このＩＤエンティティは、エンドユーザがそのサービスからログアウトするまで、又はエンドユーザが規定の時間アイドル状態になるまで、その特定のエンドユーザ用に記憶される。共同アプリケーション（ｐａｒｔｉｃｉｐａｔｉｎｇ ａｐｐｌｉｃａｔｉｏｎ）が開始すると、まず、ある特定のユーザに対するアクティブセッションＩＤが存在するかチェックし、もしあれば、セッションが壊れた場所から復帰することが可能であろう。本発明に係るセッション管理機能は図３Ａ〜図７を参照して以下に説明する。
【００６４】
最後に、ここでのポータルコアポータル構造１は２つの”内部”アプリケーションサーバ１４Ａ、１４Ｂ及び、１つ又はそれより多い外部アプリケーション１４Ｃを有する。外部アプリケーションサーバ１４Ｃは既存のサービスが稼働する外部アプリケーションサーバへのリンクを有している。一実施形態において、サービスティアは３つのサービスクラスを有する。その第１はポータルコア環境を用いて実装されるポータルコア仕様に従って構築される。第２のサービスクラスは、例えばポータルコアプレゼンテーションを通じて自身を呈示するように適合されている非ポータルコア環境で稼働する外部電子メールシステムのような、ポータルコア環境において必ずしも実装する必要が無いサービスに関連する。第３のサービスクラスはポータルコアサービス開発（ｄｅｖｅｌｏｐｍｅｎｔ）又はプレゼンテーションアーキテクチャに準拠しない外部サービスに関連する。これは図２を参照してさらに説明する。
【００６５】
以下の説明において、ポータルコア、及び特にプレゼンテーションレイヤに含まれるプレゼンテーション機構を、まず図２を参照してより完全に説明する。
１つの好ましい実施形態におけるサービスティアは、３つのサービスクラスを有する。ポータルコアサービスサービスクラス（ｐｃｏｒｅサービス）は、ポータルコアの仕様に準拠し、ポータルコア特性を利用するために用いられる。一実施形態において、このサービスはＪ２ＥＥ ＩＢＭ ＷＥＢＳｐｈｅｒｅ環境（ロジック、アルゴリズム等を含む、プログラマチックサービスの開発に用いられるアプリケーションサーバ）を用いて実施される。このようなサービスは一般に、フロントエンドにＪＳＰ（Ｊａｖａ Ｓｅｒｖｅｒ Ｐａｇｅｓ）、ミドルレイヤにＪａｖａサーブレット及びエンタプライズＪａｖａビーンズ（ＥＪＢ）を、バックエンドに様々なエントリを配置する３つ又は４つのティアアーキテクチャを有する。第２のサービスクラスは、例えば、ポータルコアプレゼンテーションを通じて自身を呈示するように適合されている非ポータルコア環境で稼働する外部電子メールシステムのように、ｐｃｏｒｅプレゼンテーションサービスを用いるが、ポータルコアＪ２ＥＥ環境には必ずしも実装する必要のない統合ポータルコアサービス（統合ｐｃｏｒｅサービス）である。第３のサービスクラスは、ｐｃｏｒｅ外部サービスであり、ポータルコアサービス開発にも、プレゼンテーションアーキテクチャにも準拠しないが、このクラスに含まれるサービスは例えばポータルコアへトリガされうる。
【００６６】
一実施形態において、サービスレイヤ内部には利用可能な２つの形式のサービスオプションが存在する。１つは、ブロードビジョン（Ｂｒｏａｄｖｉｓｉｏｎ）（ＣＯＲＢＡ）によって提供される、最適化ルールに基づく、パーソナライズされた、商取引及び小売りに結びついたサービスであって、コンテンツ、プロファイル及びビジネスルール上で動作するマッチングエンジンによるコンテンツ配信に最適化されたサービスを生成するためのサービスから構成されうる。もう一つのサービス形式は例えばアルゴリズム、ロジック等を必要とする、最適化されたコンテンツ配信システムには容易に組み込めないサービスに関連する。これらがｐｃｏｒｅサービスクラスのサービスでなければ、ＩＢＭ ＷＥＢＳｐｈｅｒｅ Ｊ２ＥＥ環境用に産業化することが可能であろうし、またそれらが統合サービスクラスのサービスであり、外部サービスサーバ上で稼働している場合、それらはポータルコアプレゼンテーションに適合される。
【００６７】
サービスは、プレゼンテーションレイヤのレンダリング機能上の要素を含み、サービスレイヤ機能に関連する仕様（ｓｐｅｃｉｆｉｃａｔｉｏｎｓ）、即ちスキーム及びロジックを必要とする。ポータルコアプレゼンテーションアーキテクチャは、上述したように、好ましい一実施形態において、特定の要素内のサービスを生成及び利用する機構について、或いはサービスを定義するために、Ｊ２ＥＥアーキテクチャを使用しうる。しかし、本発明はＪ２ＥＥ及びブロードビジョンを用いるポータル構造に限定されず、それらは単なる例示である。
【００６８】
プレゼンテーションレイヤは概念的に、ポータルコア自身の内部に存在するレンダリングレイヤ及び、ポータルコアプレゼンテーションアーキテクチャを通じてそのコンテンツを呈示したい任意のサービスから利用可能なサービスレイヤの２つのティアに分割される。好ましい一実施形態において、レンダリングレイヤはＸＭＬ／ＸＳＬＴ技術を用いる。それによって、エンドユーザ局と無関係に、すなわち、エンドユーザがポータルにアクセスする際に用いるエンドユーザ局の種類と無関係に、ポータル内でサービスが呈示する情報が規格化された方法で表示可能であることを確保する。ＸＭＬ／ＸＳＬＴの利用を通じ、プレゼンテーション空間内部で、統一された”ルックアンドフィール”を有するコンテンツが呈示されることを確実にすることが可能である。
【００６９】
ＸＭＬが汎用マークアップ言語として利用される場合、サービスはｐｃｏｒｅＤＴＤからの構成情報を用いてフォーマットされたＸＭＬ文書形式で出力を生成する。そして、サービスからのＸＭＬ出力はプレゼンテーション機構のプレゼンテーションエンジンに供給される。プレゼンテーションエンジンは、サービスに供給されたＸＭＬ文書のｐｃｏｒｅＤＴＤに付随するｐｃｏｒｅＳＳ及びｐｃｏｒｅグリッド情報を用い、所望のインタフェースを生成する。ｐｃｏｒｅＤＴＤからＸＭＬを生成しないサービスは、プレゼンテーションサービスを通じて自らを呈示することも特に可能である。
【００７０】
先に述べたように、ポータル構造は、ＷＡＰ電話機等の端末及び、ＰＣ等のブロードバンド端末の異なった端末、又はそれらが用いるブラウザを取り扱うことが可能である。ポータルコアポータル構造プラットフォーム及び内部ロジックは特にはプレゼンテーションレイヤ機能と完全に独立しており、全ての異なる形式のクライアントはもとより、音声及び言語（ｖｏｉｃｅ ａｎｄ ｓｐｅｅｃｈ）合成器についてのサポートを非常に容易に実施することが可能である。例えばＸＭＬ／ＸＳＬを用いることで、例えば新しい形式のＷＡＰディスプレイサイズのためのサポート実施は非常に容易である。また、レンダリングプロセスを、様々なＷＥＢ端末、既存の又は将来のハンドヘルド端末、音声ブラウジング及びインタラクティブＴＶへ適合させることもまた可能である。
【００７１】
特定の一実施形態において、ＷＥＢインタフェースはブリックとも表記される四角形の要素から構成される。ブリックはサービス、画像又はアプリケーションのコンテナであり、エンドユーザ局の画面上に表示される。このようなブリック又はコンテナを用いることで、ポータルをカスタマイズすることが可能になる。このように、ブリックはポータル構造内部で使用されるべく作成されるアプリケーションであり、そのアプリケーションへのリンクを有する。アプリケーションはブリックをレンダリングしたい際は、ポータルへ表示情報を提供しなければならない。好適には、ブリックは複数の形式で現れることが可能である。ブリック又はコンテナの配列は、所謂ブリックインタフェースを呈示する。簡単なナビゲーションを可能にするため、一実施形態においてはＷＡＰインタフェースも同様に実施されて良い。ＷＥＢインタフェースにおいて、ユーザは利用可能なブリックのリストを呈示される。各ブリックはユーザが構築するＷＥＢサイトに含ませることのできるアプリケーション、サービス又は背景画像を含んでいる。ブリックはまた、外部の企業又はプロバイダから予め設定されたサービスであってもよい。ブリックグリッド（Ｂｒｉｃｋ−ｇｒｉｄ）はカスタマイズされたポータルの、画像のない表現（ｎｏｎ−ｖｉｓｕａｌ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）である。端末に応じ、ブリックグリッドは使用中のその端末に最適な方法で表示される。ブリックが例えばタグとともに表示されたり、タグによってまとめられるような方法のみならず、グリッドは多くの方法で設計されうる。ブリックグリッドは汎用形式で記憶され、端末／エンドユーザ局に依存しない。
【００７２】
好ましくは、エンドユーザはポータル内の全機能へのアクセスをユーザに与える１回のログインにより、ポータルに対して自らの認証を行う。接続された、或いは外部のコンテンツもしくはサービスプロバイダに対する任意の認証は、プラットフォームセキュリティシステムによって処理される。好適にはポータル内の各アプリケーション又はサービスがエンドユーザのニーズにフィットするようにパーソナライズ可能であり、各アプリケーションが異なる端末に対してパーソナライズ可能である。これはエンドユーザが、例えばＷＡＰ電話機のような、大量のデータを表示するための能力に限りがある他のエンドユーザ局へ送信されるデータの量を制限したい場合特に都合がよい。１つのアプリケーションを複数回選択し、異なるインスタンスの各々に固有のパーソナライズを与えることが可能である。
【００７３】
本発明の概念を実施可能なポータル構造の一例について説明してきた。しかし、もちろん本発明はそのようなポータルにおいて実施すべきものに限定されず、ポータルをアクセスするエンティティを、サービス／アプリケーションへのアクセスとともにエンドユーザに提供可能なポータル構造が与えられるという仮定に基づいている。各エンドユーザに対し、セッションがポータルによって生成され、各セッションはエンドユーザに特有なデータを含む。サービス／アプリケーションは外部であっても内部であっても良い。この点に関し、内部アプリケーション又はサービスはポータルのセッション管理を用いるアプリケーション又はサービスとして定義され、一方外部アプリケーション又はサービスは、外部セッション管理を用いるアプリケーション又はサービス（セッション管理そのものを提供しても良いし、第三者によってセッション管理されても良いことを意味する）として定義される。
【００７４】
以下、本発明の概念を図３Ａ〜６を参照して詳細に説明する。
図３Ａ、３Ｂはある実施形態を示し、ここでは、ポータル構造が固定エンドユーザ局のみならずモバイルエンドユーザ局によるアクセスもサポートすることが仮定されている。好適な一実施形態において、異なる形式のエンドユーザ局について、たとえその形式がポータル構造に未知であっても、ポータル構造そのものへのアクセスが可能とされている。これは、本願出願人による、本願と同日出願されたスウェーデン出願、「ポータルにアクセスするエンドユーザ局に関する機構及び方法」に記載されているように実行可能である。当該出願を引用し、その内容を本明細書に援用する。
【００７５】
図３Ａは、外部アプリケーション２６へのアクセスを取得するため、ポータル構造のポータルコア１にアクセスするエンドユーザ局５（ここではＷＡＰ端末）を模式的に示している。ポータルコアにおいては、本発明の機能に関連する手段すなわち、レンダリング手段１５を有するプレゼンテーション機構１１、要求ブローカ１６、ポータルセッション管理手段１３、セッション統一手段５０及びポータルセッション記憶手段５１のみが図示されている。
【００７６】
エンドユーザ局５が外部アプリケーション２６へのアクセスを希望する場合、セッション統一部５０へ要求（Ｉ_０）が供給される。実際にはそれが接続の最初のトランザクションであり（すなわち、外部アプリケーション２６に関し、エンドユーザ５に対して利用可能なセッションが存在しない）、セッションがポータルセッションマネジャ１３によって生成され、ポータルセッションマネジャ１３は要求（ＩＩ_０）をセッション統一部５０から受信する。セッションはユーザに特有のデータを含み、それはポータル記憶手段５１に記憶される。ポータルセッション識別子、又は簡単にポータルセッションＩＤが生成される。セッション統一部５０はまた、要求（ＩＩＩ_０）を要求ブローカ１６へ送り、要求ブローカはこの要求を外部アプリケーション２６へ渡す（ＩＶ_０）。
【００７７】
外部アプリケーションは要求元ユーザに他の（外部）セッションが無いことを検知し、データ（例えばＸＭＬ）を生成し、外部セッションＩＤとともに外部セッションを生成し、外部セッションＩＤを（ＸＭＬ）データへのメタ情報タグとして導入する。続いて、（ＸＭＬ）データはメタ情報タグを含む、ポータル要求ブローカ１６への返答として送信される（Ｖ_０）。メタ情報タグを有するデータはレンダリング手段１５へ渡され（ＶＩ_０）、レンダリング手段１５はメタ情報タグを検出してそれをセッション統一部５０へ渡す。セッション統一部５０は、メタ情報タグをポータルセッションＩＤに変換し、レンダリング手段１５に戻す（ＶＩＩ_０）。レンダリング処理において、ポータルセッションＩＤは応答データに書き込まれ、応答データは要求ブローカ１６に渡されて（ＩＸ_０）エンドユーザ局５へ送信される。
【００７８】
図３Ｂにおいては、既にセッションが存在し、同一セッション内でエンドユーザ局５が再度アプリケーション２６へアクセスを試行した（Ｉ）ものと仮定されている。セッション統一部５０はポータルセッションマネジャ１３（ポータル記憶手段）からユーザポータルセッションを検索する（ＩＩ）。セッション統一部５０はアクセスされようとしているサービス／アプリケーション用のサービス／アプリケーションデータ、例えば外部（バックエンド）セッションＩＤを取り出す（ＩＩＩ）。外部セッションＩＤは要求ブローカ１６へ渡され（ＩＶ）、要求ブローカ１６は外部アプリケーション２６を呼び出す（Ｖ）。アプリケーションは、メタ情報タグ中に外部セッションＩＤを含んだデータ（例えばＸＭＬ）を生成し、ポータルへ送信する（ＶＩ）。要求ブローカはデータをレンダリングのためにレンダリング手段１５へ転送する（ＶＩＩ）。レンダリング手段１５は、セッション統一部５０と通信し、セッション統一部５０は外部セッションＩＤをポータルセッションＩＤにマッピングして、ポータルセッションＩＤをレンダリング手段１５へ返送する（ＶＩＩＩ）。そして、レンダリング手段はポータルセッションＩＤをエンドユーザ局５に宛てられる応答へポータルセッションＩＤを書き込む（ＩＶ）。要求ブローカを開始、応答はエンドユーザ局５へ送信される（Ｘ）。
【００７９】
内部アプリケーションのアクセスについては、ポータル及び内部アプリケーション間の通信及び、エンドユーザ局及びポータルコア間の通信の両方にポータルセッションＩＤが用いられる。
【００８０】
アプリケーションが汎用マークアップ言語、例えばＸＭＬを生成する場合には、ＸＭＬデータもまたレンダリング手段１５において変換及びレンダリングされ、エンドユーザ局が理解可能なマークアップ言語、例えばエンドユーザがＰＣならＨＴＭＬ、ＷＡＰ端末ならＷＭＬによってエンドユーザ局５に出力される。
【００８１】
これは、エンドユーザ局及びポータル間の通信については、かつて割り当てされたポータルセッションＩＤのみが用いられ、一方でポータル及び外部アプリケーション間ではかつて生成された外部アプリケーションセッションＩＤのみが用いられるということを意味する。
【００８２】
本発明の概念を実施するポータル構造において、セッション統一部からなるセッション管理統一フレームワークが設けられる。セッション統一部は一般的な一対多のセッションマッピング機構、すなわち、独自のセッション管理を有する外部システム（アプリケーション、サービス、ポータル）が複数存在する場合、セッション統一部は複数のポータルセッションを複数の外部システムの複数のセッションへ、またその逆の変換を行うことが可能である。
【００８３】
図４のフローチャートを参照して、大まかに手順を説明する。従って、１００において、アプリケーションへの要求（Ｃと表記）がエンドユーザＵからポータルに受信されたものとする。１０１で、ポータルは、エンドユーザＵについて、アプリケーションＣに関する利用可能なセッションが記憶手段に存在するかどうかをチェックする。もしなければ、１０２において、ポータルセッションＩＤが割り当てられたポータルセッションが生成される。１０３では、アプリケーションが外的にセッション管理されているかが調べられる。もしそうでなければ、１０４で、アプリケーションはアプリケーションＣ及びエンドユーザＵとの通信にポータルセッションＩＤを用い、この場合セッションを統一する必要はない。
【００８４】
しかし、アプリケーションＣが外的にセッション管理されている場合には、１０６において要求はアプリケーションＣへ転送される（もちろん、アプリケーションが内的にセッション管理されている、すなわちポータルセッション管理を用いる場合にも、要求はアプリケーション等へ転送される。しかし、これは本発明の概念とは関連しないため、ここでこれ以上の説明は行わない）。１０７では、アプリケーションＣ（又はより一般的には外部システム）において、エンドユーザＵに対して利用可能なセッションが存在するかが調べられる。もし無ければ、１０８で、外部セッションＩＤ（外部（アプリケーション）ＩＤともいう）とともに外部アプリケーション独自セッションが生成される。外部セッションＩＤの情報を具えるアプリケーションデータが生成される。１０９で、アプリケーションデータ及び外部セッションＩＤに関する情報を含む応答がポータルへ送信される。
【００８５】
応答がポータル内部で受信されると、１１０において、アプリケーションＣについてのエンドユーザＵに対して生成されたポータルセッション内に、外部セッションＩＤ情報が記憶され、そのポータルセッションはポータルセッション記憶手段に記憶される。引き続き、その後のエンドユーザ及びポータル間の通信に対し、このポータルセッションＩＤが用いられる。１１１で、外部セッションＩＤの情報はアプリケーションＣとの通信に含ませられる。
【００８６】
上述のステップ１０１において、記憶手段内に利用可能なセッションが存在することが確かめられた場合、１０５で、外部アプリケーションについて、外部セッションＩＤに関する情報が特に検出される。そして、エンドユーザ及びポータル間の通信にはポータルセッションＩＤが用いられ、一方１１１で説明したように、ポータル及びアプリケーション間の通信には外部セッションＩＤが用いられる。しかし、１０５において、ポータル記憶手段に記憶されるポータルセッション中に外部セッションＩＤに関する情報が記憶されていなければ、そのアプリケーションは内部にあることが示され、アプリケーションＣとの通信及び、エンドユーザＵとの通信の両方にポータルセッションＩＤが用いられる。
【００８７】
上述のステップ１０３は、アプリケーションが外部アプリケーションかどうかに関する検出を独立して行わなければならない印象を与えるかもしれない。しかし、これは既存のセッションについてはポータルセッションが、ポータル記憶手段から、セッション統一手段によってポータルセッション管理手段を介してフェッチされた際に生得的に検出されうる。新しいセッションについては、応答がアプリケーションから受信され、その応答が外部セッションＩＤを有するメタ情報タグを含むものとして、特にレンダリング手段によって検出可能である。
【００８８】
図５はある特定の実施形態について、２００で、エンドユーザＵ１からの要求が、外部アプリケーションＡに関連するポータルで、最初に、すなわちセッションのない状態で受信された際の手順を、幾分詳細に説明するフローチャートである。２０１で、ポータルセッション管理手段は、アプリケーションＡに関し、Ｕ１についてセッションが存在しないことを検出する。そして、２０２で、ポータルはエンドユーザＵ１に対し、アプリケーションＡとのセッションをポータルセッションＩＤとともに生成する。続いて２０３で要求がアプリケーションＡへ転送される。２０４で、アプリケーションＡはＵ１に対するセッションが存在しないことを検出する。そして、２０５で、アプリケーションＡはＵ１に対して独自外部セッションを生成するとともに、少なくとも外部セッションＩＤを有する、すなわち生成されたセッションの識別子を有するメタ情報タグを生成する。２０６で、アプリケーションはさらに、アプリケーションデータを（本実施形態ではＸＭＬによって）生成し、メタ情報タグを有するアプリケーションデータをポータルコアへ送信する。従って、ＸＭＬデータ中には、アプリケーションセッションＩＤを含むメタ情報タグが存在する。これは例えば
＜ｍｅｔａｉｎｆｏ ｎａｍｅ＝”ａｐｐｌｉｃａｔｉｏｎ＿ｓｅｓｓｉｏｎ＿ｉｄ” ｖａｌｕｅ＝”４７１１” ／＞
というようなものである。
【００８９】
２０７で、ポータルセッション統一手段は、外部セッションＩＤをＵ１に対するポータルセッションＩＤにマッピングする。２０８において、ポータルセッション管理手段は、メタ情報データを、特に、好ましい実施形態においては、セッションＩＤに関するメタ情報だけが含まれるのではなく、他のデータも含まれている場合には、全てのメタ情報データを、ポータルセッションへ記憶する。一実施形態において、アプリケーションデータはさらに他のサービス／アプリケーションを参照するメタリンクを含み、このメタリンクは同時係属の特許出願、「アプリケーション／サービスのアクセスに関する機構及び方法」に更に詳細に記載されるように、変換手段によって処理、変換され、ポータルのセッションＩＤがパラメータとして付加される。
【００９０】
２０９で、ポータルコアのレンダリング手段はアプリケーションデータをレンダリング、すなわちエンドユーザ局に適切な形式へ変換し、ポータルセッションＩＤのみを用いてエンドユーザＵ１へ送信する。
【００９１】
図６は、エンドユーザＵ１が同一セッション中に再度アプリケーションＡへのアクセスを試みた際の手順を説明するフローチャートである。従って、ここでは２１０において、Ｕ１からアプリケーションＡについての次の要求がポータルで受信されたものと仮定されている。これは例えばエンドユーザＵ１が彼のブラウザにおいて、ポータルセッションＩＤへのパラメータを有する、アプリケーションＡへのリンクをクリックしたことを意味する。２１１で、セッション統一部を介し、ポータルセッション管理手段は、ポータルセッションＩＤを用いてＵ１に対するポータルセッションを調べる。２１２で、アプリケーションＡに関する、Ｕ１についてのポータルセッション中に含まれるメタ情報の存在が検出される。２１３で、ポータル要求ブローカはアプリケーションにコンタクトし、メタ情報をパラメータとして含ませ、要求をアプリケーションＡに転送する。メタ情報は外部セッションＩＤを含み、従って外部セッションＩＤはアプリケーションに送信される。すなわち、アプリケーションＡとの通信に用いられる。２１４で、アプリケーションＡは、メタ情報に含まされた自分の外部セッションＩＤを用い、エンドユーザＵ１に対する外部セッションを調べる。２１５で、アプリケーションは、アプリケーション（ＸＭＬ）データを生成し、メタ情報タグをＸＭＬデータへ含ませ、ＸＭＬデータをメタ情報タグとともにポータルへ送信する。そして、処理は図５のステップ２０７、２０８等と同様に進行する（２１６）。
【００９２】
一実施形態によれば、外部アプリケーション、又はより一般的には外部システム（バックエンドシステムとも表記される）は、セッション統一手段（セッション統一部）を機能させるために以下の操作を規定する。
１． ＢａｃｋｅｎｄＳｅｓｓｉｏｎ ｂｓ ＝ ｂａｃｋｅｎｄ， ｃｒｅａｔｅＳｅｓｓｉｏｎ （）
２． Ｂｓ． ｕｐｄａｔｅＳｅｓｓｉｏｎ （）
３． Ｓｔｒｅａｍ ｓ ＝ ｂａｃｋｅｎｄ． ｓｅｒｉａｌｉｚｅＳｅｓｓｉｏｎ （ＢａｃｋｅｎＳｅｓｓｉｏｎ ｂｓ）
【００９３】
セッション統一部は、以下の操作を実装する。
１． ＰｏｒｔａｌＳｅｓｓｉｏｎ ｐｓ ＝ Ｐｏｒｔａｌ． ｇｅｔＳｅｓｓｉｏｎ （）
２． ＢａｃｋｅｎｄＳｅｓｓｉｏｎ ｂｓ ＝
Ｐｓ． ｇｅｔＢａｃｋｅｎｄＳｅｓｓｉｏｎ （ｂａｃｋｅｎｄＳｅｒｖｉｃｅ）
３． ｐｓ． ｃａｌｌＢａｃｋｅｎｄＳｅｒｖｉｃｅ （ｂａｃｋｅｎｄＳｅｒｖｉｃｅ）， ｂｓ）
４． ｐｓ． ｓｔｏｒｅＢａｃｋｅｎｄＳｅｓｓｉｏｎ （ｂａｃｋｅｎｄＳｅｒｓｖｉｃｅ， ｂｓ）
【００９４】
従って、この実装によれば、セッション統一手順は、以下のように機能する。１．統一部はそのサービス／アプリケーション用の要求／コールに関連するポータルセッションを呼び出すため、ｐｓ． ｇｅｔＳｅｓｓｉｏｎ （）をコールする。
２．統一部はｂｓ ＝ ｐｓ． ｇｅｔＢａｃｋｅｎｄＳｅｓｓｉｏｎ （ｂａｃｋｅｎｄＳｅｒｖｉｃｅ）をコールする
３．統一部はｐｓ． ｃａｌｌＢａｃｋｅｎｄＳｅｒｖｉｃｅ （ｂａｃｋｅｎｄＳｅｒｖｉｃｅ， ｂｓ）をコールする
４．そのユーザに対するバックエンドセッションが存在しない（ｂｓ ＝ ０）ならば、バックエンドがｂｓ ＝ ｂａｃｋｅｎｄ， ｃｒｅａｔｅＳｅｓｓｉｏｎ （）をコールし、このセッションをポータルへの応答とともに送信する。さもなければ、バックエンドはｂｓ． ｕｐｄａｔｅＳｅｓｓｉｏｎ （）をコールし、これをポータルへの応答とともに送信する。バックエンドセッションの送信はｂａｃｋｅｎｄ． ｓｅｒｉａｌｉｚｅＳｅｓｓｉｏｎ （ｂｓ）のコールによって完結する。
５．ポータルは、ｐｓ． ｓｔｏｒｅＢａｃｋｅｎｄＳｅｓｓｉｏｎ （ｂａｃｋｅｎｄＳｅｒｖｉｃｅ， ｂｓ）をコールして、バックエンドセッションを記憶する。
【００９５】
図７は、上述のセッション統一手順のステップを説明する相互動作図である。
Ｐ． ｇｅｔＳｅｓｓｉｏｎ （）は、例えばサーブレットセッションＡＰＩ（Ｓｅｒｖｌｅｔ Ｓｅｓｓｉｏｎ ＡＰＩ）に従う任意のセッション管理システムによって実施可能である。
Ｐ． ｇｅｔＢａｃｋｅｎｄＳｅｓｓｉｏｎ （ｂａｃｋｅｎｄＳｅｒｖｉｃｅ）は、ｂａｃｋｅｎｄＳｅｒｖｉｃｅのアクセス毎にポータルセッション内部に名前空間を生成し、名前空間内にｂａｃｋｅｎｄＳｅｒｖｉｃｅ関連データを記憶することによって実施可能である。
帯域要求を削減するため、Ｂ． ｓｅｒｉａｌｉｓｅＳｅｓｓｉｏｎ （）はバックエンドシステムから単に識別子のみを送信することによって実施可能である。
【００９６】
本発明によれば、セッション統一の提供を通じ、異なるセッション管理システムを１つの統一されたセッション管理へシームレスに統合することが可能になるという利点がある。ポータル構造について、これはポータル及び外部アプリケーションサービスプロバイダとの間の統合時間を大幅に削減しうる。特に、移動局によるアクセスもサポートするモバイルポータルに対し、このようなセッション管理の統一は、非常に長いバックエンドセッションデータから短い統一されたセッションへの変換を通じて、無線エンドユーザ局へ送信しなくてはならないデータの量を削減するための強力な手段を提供する。さもなければ、ポータルセッションＩＤと外部セッションＩＤの両方をエンドユーザ局との通信に含ませる必要がある場合に転送しなければならなかった大量のデータに帰因して、ＷＡＰ端末といった移動エンドユーザ局による、外的にセッション管理されるシステムへのアクセスは、可能ですらないかもしれない。なぜなら、そのような量のデータはエンドユーザ局が受理できないおそれがあるからである。エンドユーザ局が識別目的のためだけにそのような量のデータを処理可能であったとしても、それは資源及び時間の浪費である。
【００９７】
本発明が具体的に説明した実施形態に限定されず、添付の特許請求の範囲の範囲内で、多くの方法によって変化させうることは明らかであろう。
【図面の簡単な説明】
【図１】
本発明の一実施形態に係るポータル構造の概要を模式的に示す図である。
【図２】
プレゼンテーション機構（レイヤ）の、レンダリング機能レイヤ及びサービス機能レイヤへの概念的な分割を示す図である。
【図３Ａ】
エンドユーザが外部アプリケーションへのアクセスを最初に要求するためのポータルのブロック図である。
【図３Ｂ】
エンドユーザが同一セッション中に同一アプリケーションへ再度アクセスした際の、図３Ａと同様の図である。
【図４】
本発明の概念の一般的な実装を模式的に説明するフローチャートである。
【図５】
セッションが存在しない状態で、エンドユーザがポータルにアクセスし、外部サービス／アプリケーションへのアクセス要求を行った際の処理の流れを説明するフローチャートである。
【図６】
エンドユーザが同一セッション中に同一アプリケーションへその後アクセスする際の手順を説明するフローチャートである。
【図７】
セッション統合手順における、セッションマッピングインタラクションを示す図である。

Claims (27)

1. ポータルコア（サービスイネーブル手段、エンドユーザアクセスを提供するための接続性手段）及び複数のサービス／アプリケーションとを有し、エンドユーザ局にサービス／アプリケーションへのアクセスを提供するポータル構造であって、
   前記ポータルコアが、
   プレゼンテーション機構と、
   セッション関連情報、例えばセッションＩＤを生成するポータルセッション管理手段と、
   セッション関連情報を格納する記憶手段を有し、
   前記サービス／アプリケーションの少なくともいくつかが外部サービス／アプリケーションを有するか、外部システムにより提供され、外部セッションＩＤを生成する外部セッション管理手段を用いるポータル構造において、
   ポータルセッションＩＤと外部セッションＩＤとをマッピングするセッション統一手段を有し、
   前記ポータルコア及び外部サービス／アプリケーション間の通信においては、前記外部サービス／アプリケーション外部ＩＤがセッションＩＤとして用いられ、一方、エンドユーザ局及び前記ポータルコア間の通信においては、前記ポータルセッションＩＤのみが用いられることを特徴とするポータル構造。
2. 前記サービス／アプリケーションが汎用マークアップ言語を生成することを特徴とする請求項１記載のポータル構造。
3. 前記汎用マークアップ言語がＸＭＬであることを特徴とする請求項２記載のポータル構造。
4. あるセッションにおいてアクティブな全ての外部サービス／アプリケーションに対する、外部サービス／アプリケーション独自外部セッションＩＤ情報が、定められた時間、例えば個々のセッションの間中、前記ポータル記憶手段内の対応するポータルセッションに記憶されることを特徴とする請求項１乃至請求項３のいずれか１項に記載のポータル構造。
5. 前記プレゼンテーション機構が、
   前記汎用マークアップ言語によるサービス／アプリケーションデータを、エンドユーザ局が用いる別のマークアップ言語に変換するレンダリング手段を有することを特徴とする請求項２記載のポータル構造。
6. 前記ポータル構造がモバイルである、すなわち、固定エンドユーザ局に加えて移動エンドユーザ局、例えばＷＡＰ端末からのアクセスをサポートすることを特徴とする請求項５記載のポータル構造。
7. 前記汎用マークアップ言語でサービス／アプリケーションを表すデータが、ＵＲＬ属性を用いる文書型定義（ＤＴＤ）言語によって定義されることを特徴とする請求項２記載のポータル構造。
8. 外部独自セッション管理手段を有する外部システムが、他のポータルを構成することを特徴とする請求項１乃至請求項７のいずれか１項に記載のポータル構造。
9. 前記ポータルセッション管理手段が、基本セッション管理操作を規定するサーブレットセッションＡＰＩ又はセッションＥＪＢの仕様にして違って動作することを特徴とする請求項１乃至請求項８のいずれか１項に記載のポータル構造。
10. 前記ポータルセッション管理手段は、エンドユーザの前記ポータルへの入場、エンドユーザの認証、エンドユーザのサービス／アプリケーションへのアクセス等といった、エンドユーザが起動したアクションに関する情報を、前記ポータル記憶手段に記憶することを特徴とする請求項１乃至請求項９のいずれか１項に記載のポータル構造。
11. サービス／アプリケーションへのエンドユーザ要求に応答して、前記ポータルセッション管理手段はセッションＩＤとともにポータルセッションを生成し、前記要求が前記サービス／アプリケーションへ転送されると、前記サービス／アプリケーションが内部サービス／アプリケーションであれば前記サービス／アプリケーションは前記ポータルセッションＩＤ情報用い、一方前記サービス／アプリケーションが外部セッション管理手段によって管理されている場合、前記サービス／アプリケーションは外部（独自）セッションＩＤを供給されることを特徴とする請求項１乃至請求項１０のいずれか１項に記載のポータル構造。
12. 外部セッション管理手段によって管理されるサービス／アプリケーションについて、前記外部セッション管理手段は、要求元エンドユーザに対して生成された外部セッションＩＤ情報を、定められた時間、例えば前記セッションの間中記憶し、前記セッション中に前記ポータルから次の呼び出し要求を受信すると、サービスアプリケーションデータが生成され、前記サービス／アプリケーションデータ及び前記外部セッションＩＤを有する応答が前記ポータルコアへ返送され、前記サービス／アプリケーションデータを前記ポータルセッションＩＤのみを用いて前記エンドユーザへ転送可能なように、前記外部セッションＩＤは、前記統一手段によって前記ポータルセッションＩＤへ変換／マッピングされることを特徴とする請求項１１記載のポータル構造。
13. アクセスされたサービス／アプリケーションのそれぞれに対する前記ポータルセッション内部に名前空間が生成され、少なくとも外部セッションＩＤを含む前記外部セッション情報が前記名前空間に記憶されることを特徴とする請求項１２記載のポータル構造。
14. 外部サービス／アプリケーションが、エンドユーザの、前記ポータルを介した外部サービス／アプリケーションへのアクセス要求について、外部サービス／アプリケーション外部（独自）ＩＤとともに外部独自セッションを生成し、少なくとも前記外部（独自）セッションＩＤを含むメタ情報タグを前記ポータルコアへ返送されるべき前記汎用マークアップ言語による前記サービス／アプリケーションデータに導入することを特徴とする請求項２、請求項１１又は請求項１２に記載のポータル構造。
15. 前記メタ情報タグの全データが、前記要求元エンドユーザに対応するポータルセッションに記憶されることを特徴とする請求項１４記載のポータル構造。
16. 前記ポータルコアが、
    前記ポータルセッションＩＤがパラメータとして付加された、前記汎用マークアップ言語による前記サービス／アプリケーションデータに含まれうるメタリンクを処理するための第１の変換手段と、
    前記汎用マークアップ言語による前記データを前記要求元エンドユーザ局が理解可能なマークアップ言語へ変換する第２の変換手段を有するレンダリング手段を有することを特徴とする請求項１５記載のポータル構造。
17. 前記外部サービス／アプリケーションが前記外部セッションを前記外部セッションＩＤによって示されるものとして見いだすことができるよう、同一セッション中における、同一エンドユーザによる同一サービス／アプリケーションへのアクセスに対しては、前記外部セッションＩＤを含む前記記憶されたメタ情報が前記ポータルセッション統一手段から前記外部サービス／アプリケーションへ転送されることを特徴とする請求項１６記載のポータル構造。
18. プレゼンテーション機構を有するポータルコア、セッション関連情報、少なくともセッションＩＤを生成するポータルセッション管理手段及び、ポータルセッション関連情報を記憶する記憶手段を有する、ポータル構造内の機構であって、
    ポータルセッション及び、外部サービス／アプリケーションを管理する外部セッション管理手段によって生成された外部セッションの管理を統一するセッション統一手段を有し、
    前記ポータルと、アクセス元エンドユーザ局との通信には、ポータルセッションＩＤのみが用いられ、前記ポータルコアと外部サービス／アプリケーションとの通信には、外部セッションＩＤ情報が用いられるとともに、前記統一手段はポータルセッションＩＤと外部サービス／アプリケーションの外部セッションＩＤとをマッピング／変換するために用いられることを特徴とする機構。
19. 前記外部サービス／アプリケーション独自の、外部セッションＩＤ情報は、それがマッピングされた前記ポータルセッションに、定められた時間、例えばセッションの間中記憶されることを特徴とする請求項１８記載の機構。
20. サービス／アプリケーションへのアクセスを要求したエンドユーザ局へ出力されるサービス／アプリケーションデータが、前記エンドユーザ局で理解可能なマークアップ言語になるよう、前記プレゼンテーション機構が、汎用マークアップ言語によるサービス／アプリケーションデータを、要求元エンドユーザ局の形式に依存する他のマークアップ言語に変換するレンダリング手段を有することを特徴とする請求項１８記載の機構。
21. 前記汎用マークアップ言語がＸＭＬであることを特徴とする請求項２０記載の機構
22. 外部サービス／アプリケーションデータに導入されるメタ情報タグ内に外部セッションＩＤ情報が与えられ、前記メタ情報データは、ポータルセッション情報を記憶するポータル記憶手段内の、前記対応するポータルセッション内に記憶され、また前記ポータルセッションＩＤは、前記エンドユーザ局との通信において、前記外部セッションＩＤを置き換えるパラメータとして外部アプリケーション／サービスデータに付加されることを特徴とする。請求項１８乃至請求項２１のいずれか１項に記載の機構。
23. あるセッション中、あるエンドユーザにより、前記ポータルへ、同一の外部サービス／アプリケーションへの次の要求があると、当該要求が前記ポータルコアから前記外部サービス／アプリケーションへ転送される際に、前記要求中に前記メタ情報が含ませられることを特徴とする請求項２２記載の機構。
24. プレゼンテーション機構を有するポータルコア、セッション関連情報を処理するポータルセッション管理手段及び、セッション関連情報を記憶する記憶手段を有するポータル構造におけるセッション管理方法であって、
    ポータルセッションが既に存在していなければ、エンドユーザがサービス／アプリケーションへのアクセスを要求した際にポータルセッションをポータルセッションＩＤとともに生成し、
    前記要求されたサービス／アプリケーションが外的にセッション管理されている場合には、前記要求された外部サービス／アプリケーションへ前記要求を転送し、
    既にセッションが存在していない限り、前記要求をしたエンドユーザに対し、外部サービス／アプリケーション独自セッションＩＤを外部セッション管理手段において生成し、
    前記サービス／アプリケーションにおいて、サービス／アプリケーションデータを生成し、
    前記外部セッションＩＤに関する情報を前記サービス／アプリケーションデータに導入し、
    前記外部セッションＩＤを含んだ前記サービス／アプリケーションデータを前記ポータルに返送し、
    前記外部セッションＩＤを前記ポータルセッションＩＤにマッピングし、
    前記外部セッションＩＤを前記対応するポータルセッション手段に記憶し、
    前記サービス／アプリケーションデータを、前記ポータルセッションＩＤのみを用いて前記要求をしたエンドユーザに送信する、
    ステップを有することを特徴とする方法。
25. 前記ポータルにおいて、
    前記セッション中における、エンドユーザによる外部サービス／アプリケーションへのその後の要求に際し、前記記憶手段内で前記ポータルセッションを探索し、
    前記ポータルセッション関連情報が外部セッションＩＤを含んでいるかどうかをしらべ、もし含んでいれば、
    前記外部セッションＩＤを含んだ前記要求を、前記要求された外部サービス／アプリケーションへ転送し、
    前記外部セッション管理手段又は前記外部サービス／アプリケーションにおいて、
    前記外部サービス／アプリケーションセッションを探索し、
    サービス／アプリケーションデータを生成し、
    前記外部セッションＩＤを前記サービス／アプリケーションデータに付加し、
    前記サービス／アプリケーションデータを前記外部セッションＩＤとともに前記ポータルセッション管理手段に返送し、
    前記ポータルにおいて、
    前記外部セッションＩＤを、前記対応するポータルセッションＩＤに置き換え、
    前記サービス／アプリケーションデータを前記エンドユーザ局へ、前記ポータルセッションＩＤのみを用いて送信する、
    ステップをさらに有することを特徴とする請求項２４記載の方法。
26. 前記外部サービス／アプリケーションが、汎用マークアップ言語、例えばＸＭＬを生成することを特徴とする請求項２４又は請求項２５記載の方法。
27. 前記外部セッションＩＤを付加するステップが、
    少なくとも外部セッションＩＤを含むメタ情報タグを生成し、前記サービス／アプリケーションデータへ導入するステップを含むことを特徴とする請求項２６記載の方法。

Images