JP4963129B2 - ナビゲーション・トポロジ内のナビゲーションを容易にし固定するためにショートカットを推薦する方法 - Google Patents

Description

本発明は、ネットワーク・コンピューティングの分野に関し、特に、ポータル・ページの階層構造体を含むウェブ・ポータル又は企業ポータル、及び、ポータルを介してアクセス可能なウェブ・コンテンツ又は企業コンテンツにアクセスするためのポートレットを設計する方法及びシステムに関する。

図１は、上記のような従来技術のウェブ・ポータルを実装するポータル・サーバの概略的なシステム図である。

例えば、上記のＩＢＭ ＷｅｂＳｐｈｅｒｅ Ｐｏｒｔａｌによって又はＪｅｔｓｐｅｅｄ２ Ｅｎｔｅｒｐｒｉｓｅ Ｐｏｒｔａｌ（ｗｗｗ．Ｐｏｒｔａｌｓ．ａｐａｃｈｅ．ｏｒｇ／ｊｅｔｓｐｅｅｄ−２／Ｐｏｒｔａｌ−ｄｅｓｉｇｎ．ｈｔｍｌ）によって表される従来技術のポータルは、ネットワーク・サーバ、例えば、ウェブ・サーバ１００上に実装される複合機能によって構築され、その機能の内の最も重要な要素は、ユーザ認証コンポーネント１０５と、状態処理コンポーネント１１０と、フラグメント集約コンポーネント１１５と、複数のポートレット１２０であって、後述のように、それらを共通のウェブ・ページ・コンテキスト内に設定するためのそれぞれのポートレット・コンテナ・ソフトウェア１３５へのそれぞれの複数のＡＰＩ１３０を用いてそれぞれのページ１２５に設けられる複数のポートレット１２０と、幾つかのポータル・ストレージ・リソース１４０とに関する論理コンポーネントである。論理コンポーネントは、要求に応じて単一のコンポーネント間でデータを交換できるように動作可能に接続される。これが概略的に図１に示される。

より詳細には、図１のウェブ・サーバのポータル・エンジンは、基礎となるポータル・モデル１５０、及び、セキュリティ設定、ユーザ役割、カスタマイズ設定、及びデバイス機能のようなポータル情報に基づいてポートレット１２０の集約を実行する。レンダリングされたページ内で、ポータルは、ポータル・モデルに基づいてナビゲーション要素の適切な組を自動的に生成する。ポータル・エンジンは、要求に応じて及び要求されたときに集約中にポートレットを呼び出し、キャッシングを用いてポートレットになされる要求の数を減少させる。従来技術のＩＢＭ ＷｅｂＳｐｈｅｒｅ Ｐｏｒｔａｌは、Ｊａｖａ Ｐｏｒｔｌｅｔ ＡＰＩ（アプリケーション・プログラミング・インターフェース）のようなオープン・スタンダードを採用するものである。これはまた、ＷＳＲＰスタンダードによるリモート・ポートレットの使用をサポートする。

ポートレット・コンテナ１３５は、全てのポートレット１２０に対して適格な単一の制御コンポーネントであり、これらのポートレットの各々の中にあるコードの実行を制御することができる。これは、ポートレットに対してランタイム環境を提供し、特に、イベント処理、ポートレット間メッセージング、並びに、ポートレット・インスタンス及び構成データへのアクセスを促進する。ポータル・リソース１４０は、具体的にはポートレット１２０自体及びページ１２５であり、その上にそれらポートレットがフラグメントの集約体の形態に集約される。ポータル・データベース１２８は、ポートレット記述をストアし、これは詳細には、ポートレット名、ポートレット記述、ポートレット・タイトル、ポートレット・ショート・タイトル、及びキーワードのような幾つかの属性を特徴付けるポートレット記述、並びに、ＷＳＤＬ文書の形態でストアされることが多いポートレット相互作用インターフェース記述である。ポータル・データベースはまた、ポータル・コンテンツ構造体、即ち、やはり入れ子形式のページを含むことができるポータル・ページの階層構造体と、ポートレットをストアする。このデータは、関係表のような従来技術に基づく適切な表現でデータベース１２８にストアされる。

前述の集約論理１１５は、ページをアセンブルするのに必要な全てのステップを含む。典型的には、これらのステップは、ストレージからコンテンツ構造体をロードすること、それをトラバースすること、及び構造体内で参照されるインスタンスを呼び出してそれらの出力を得ること、及びその出力を単一ページにアセンブルすることである。
コンテンツ構造体は、例えば、管理者によるポートレットのカスタマイズを通じて定めることができる。

ここで具体的に本発明に焦点を合わせると、ウェブ・ユーザがウェブ・アプリケーションを訪れたとき、通常、ユーザには、基礎となるコンテンツにアクセスするための幾つかの手段を提供するナビゲーション・メニューが表示される。ナビゲーション・メニューは、通常、ツリー状のトポロジに構造化され、ユーザは、ユーザが関心をもつコンテンツに適合するノードに到達するためにツリーをトラバースすることを強いられる。特に、ウェブ・ポータルは、そのウェブ・ポータルが提供する全てのコンテンツを通してナビゲートするように用いる必要があるようなナビゲーション・メニューを装備している。

実際には、すべてのユーザが同じコンテンツに関心をもつのではなく、従って、所与のポータル上に与えられた構造体は、特定のユーザ群の要求を満たすことができるが、多くの個々のユーザにとっては、所与のトポロジは彼らの要求を満たさない。従来技術は、トポロジの特定のノードを融合させる、即ち、ページ又はページの部分、基本的には幾つかのポートレット、を融合させることを可能にする。しかしながら、これは、ナビゲーション・ツリーをより良好にトラバースするためには非常に柔軟さのない手段である。

従って、本発明の目的は、改善されたウェブ・ポータル・ナビゲーションを与える方法及びシステムを提供することである。

この本発明の目的は、添付の特許請求の範囲における独立請求項に記載の特徴によって達成される。本発明のさらなる利点となる構成及び実施形態は、それぞれの従属請求項に記載される。ここで添付の特許請求の範囲を参照されたい。

手短に言えば、本発明の方法は、ナビゲーション・トポロジを通じてユーザが辿る経路を追跡して、ユーザが行うことを学習する。同じウェブ・ポータルの同じノードにおいてナビゲートするときの将来のセッション中に、本方法は、本発明の方法を実施するときにシステムが学習したことに基づいて、ユーザがショートカットを辿ってより速く、ユーザが興味をもつ可能性の高い最終目的ページ或いは図式的用語では目的ノードに達することを可能にする推薦を融合させる。

好ましい実施形態において、機能コンポーネントがユーザの行動を追跡し、さらに別のコンポーネントがユーザの行動を分析し、第３のコンポーネントが推薦をウェブ・ブラウザのユーザ・インターフェースに表示し、各々の推薦（ショートカット）に関連するリダイレクション機能を提供する。

本発明の方法は、ナビゲーション構造体における各々のページに対する一組の有用なショートカットを提供するが、このショートカットは、従来技術から公知のように通常の経路を通じてナビゲートするのに必要な時間及び労力を減らそうとするものである。ショートカットの組は、ユーザのナビゲーション中に動的に生成され、その際、ショートカットは、特に現在のノードに依存して、好ましくは過去に訪れたノードにも依存して生成される。次に、ショートカットの１つ又はリストが、目立つ位置に、好ましくはポータル・テーマ内に表示される。

上記を実行するために、本発明の方法は、ナビゲーション構造体内の各々のリンクをユーザが辿った回数に関する情報を配信するモデルを構築する。この情報は、ユーザが特定のページＰにナビゲートする確率を、ユーザが現在別のページＱにいる条件下で計算するのに用いられる。次に、これは、どれがユーザの現在のナビゲーションにおける最も可能性の高い最終目的となりうるかを予測する。このようにして、本発明の推薦方法は、各ユーザがどの経路を最も多く辿るかを追跡し、ユーザが現在ナビゲートする場所に応じて推薦を配置して、最もポピュラーなナビゲーション経路によりナビゲートするのに必要なクリック回数を減らす。

本発明の方法の有用性と推薦されるショートカットの数との間にはトレード・オフが存在する。本発明の方法によって与えられる推薦は、ナビゲーション距離においては非常に遠いが依然として最終目的となる高い確率を有するターゲット・ページの予測に特に焦点をあてるように編成される。従って、基本的に、本発明の方法は、ツリー状のナビゲーション・ツリーを通しての移動のためのクリック回数の最大の期待節約を達成しようとするものである。本発明の方法によって与えられる推薦が、現在使用されているウェブ・ページのテーマの中に融合されたショートカットのリストであるとき、ショートカットには、ユーザが非常に簡単に到達することができる。それゆえ、ショートカットの簡単なクリックのみで、ユーザはその所望の最終目的ページ、又はこのページのポートレットにナビゲートされる。

本発明はその最も広い態様により、ノード及びノード間を接続するエッジを含み、内部のウェブ・ポータル・ページが所定のトポロジ・レベルに対応し且つ１つ又は複数のポートレットを表示する、所与の階層的ナビゲーション・トポロジ内でのナビゲーションの際にユーザを支援するためのウェブ・ポータル環境における方法及びシステムを開示するものであり、この方法は、
ａ）ユーザのナビゲーション中に、ウェブ・ポータルのトポロジ内のナビゲーションを含む各々のページに対して、ユーザのナビゲーション行動に関する情報を自動的に検知するステップと、
ｂ）検知された情報から、別のページに到達するためにクリックされたページに関して定義されるページ・ヒットと、ページ固有タスクを実行するため又はあるページ固有情報を受信するためにユーザがクリックするページに関して定義されるページ・ターゲット・ヒットとを導出するステップと、
ｃ）検知された情報に基づく所定のメトリックを使用してユーザ・ナビゲーションを含むウェブ・ページに関する有用性ランキングを生成するステップであって、ここで、ページの有用性ランキング計算値は新しく使用されたページの時間に関連する加重優先順位付けを含む、ステップと、
ｄ）ユーザのナビゲーション中に現在のナビゲーション位置を追跡するステップと、
ｅ）現在の位置及び複数のターゲット・ページに対して、有用性ランキングによって得られるターゲット・ページのそれぞれ１つにナビゲートするための確率の大きさを計算するステップと、
ｆ）ターゲット・ページの有用性及び現在のページとターゲット・ページの間のナビゲーション距離に基づいて各々のターゲット・ページに対する期待節約因子を計算するステップと、
ｇ）高い期待節約因子を有する少なくとも１つのターゲット・ページへのそれぞれの直接リンクを含む少なくとも１つのショートカットを定めるステップと、
ｈ）ショートカットをクリック可能リンクとしてユーザに表示するステップと、
を含む。

情報を検知することは、「センサ」に対する全ての特定のインターフェースを使用して、それらによって与えられる情報を読み取ることを含むように意図されている。従って、時間情報はシステム・クロックから検知され、日付情報はウェブ・サーバ・システムの任意の日付ソースから検知され、ユーザＩＤは先行するログイン手続きから検知される、などとなる。

用いられるメトリックの例は、
ユーザがページ要素と相互作用した回数（即ち頻度）、又は、
ユーザがページを見た回数（即ち頻度）、又は、
ページを訪れた頻度、又は、
ユーザの現在位置、又は、
ヒット時刻、月及び曜日など、
である。

「有用性」という用語は、ユーザにとってのウェブ・ページの重要性を指すように意図されている。この重要性は、上記のメトリックによって捕捉されるように試みられる。もちろん、問題において何らかの使用が有用であると思われる場合には、上記のメトリックとは無関係のさらに別の重要性パラメータを用いることもできる。

時間に関連する加重は、ユーザの行動に僅かに、しかし通常は絶え間なく影響を及ぼす使用変化を反映する。

現在のナビゲーション位置は、ページのＵＲＬ又はポートレットのＵＲＬとして定義することができる。

確率の大きさは、特定のページ・ヒットと全体のページ・ヒットとの間の関係として数学的に定義することができる。さらに、それはまた、この手法に対する幾つかの拡張を含む異なる方法で定義することもできる。それは、ウェブ・ページの重要性を反映する基本理念に従う。

期待節約因子は、所望のターゲット・ページ又はターゲット・ポートレットに到達するためのユーザの作業と、それのユーザに対する関連性をコンピュータ・プログラムによって判断可能である限りその関連性とを反映する。他に対して特定の態様、例えば、時間が重要な状況においてユーザが選択する可能性の高いポートレットを強調することができる。

本発明は例証として説明され、図面の形態の形状によって限定されるものではない。

図面を一般的に参照し、特にここで図２を参照しながら、本発明の好ましい実施形態を以下により詳細に説明する。
図２は、従来技術のポータル・サーバに組み込まれ、それぞれのプログラミング・インターフェースを介して集約コンポーネント１７０と密接に協働する付加的な本発明のコンポーネント１７５を示す。

特に図３を参照すると、上記の集約コンポーネント１７０は、ボックス１７２、１７４、１７６、１７７及び１７８に示されたさらに別の機能を制御する。それはさらに、ポータルの所与のトポロジをポータル・ユーザに表示する。

ウェブ使用率マイニング・コンポーネント１７６は、ウェブ・サーバのインボックスへの読み取りインターフェースを有し、これはユーザが現在使用中のウェブ・ページ上で見えるリンクのどこかをクリックすることから生じるユーザ要求を受信する。さらに、コンポーネント１７６は、ウェブ・サーバのクロックへのインターフェースを有して、ユーザ要求の到着時刻をストアする。これらのインターフェースを介して、ウェブ使用率マイニング・コンポーネントは、ユーザがあるポータル・トポロジをナビゲートするときに実行する各々のユーザ相互作用について通知される。コンポーネント１７６は、ユーザがウェブ・ポータルと相互作用している間に、所与のウェブ・ページに関連し且つ所与のコンテキストに関連する前述のヒット値及びターゲット・ヒット値を計算し、データベース・ストレージ・コンポーネント１７４を呼び出して完了セット・オフ検知通知を実行する。

この実施形態により、コンテキスト属性を判断して現在使用中のコンテキストを定義するための、コンテキスト・オブザーバ・コンポーネント１７７が設けられる。そうするために、コンポーネント１７７は、正確な時刻情報、日付情報を要求してウェブ・ポータルの訪問者が現在使用中のデバイスのタイプ、及び場合によっては、導き出せるさらに別の情報、又は、例えばＧＰＳセンサ要素など任意の他のセンサ・デバイスによる入力を識別することが可能となるように、それぞれの機能インターフェースを有する。コンポーネント１７７は、コンポーネント１７６がそれぞれの正しいコンテキストを用いて現在の検知情報をストアすることを可能にするように、あらゆるコンテキスト情報をウェブ使用率マイニング・コンポーネント１７６に供給する。

各々のユーザに、この好ましい実施によるデータベース・ストレージ・コンポーネント１７４が提供され、これがユーザ指定のトポロジと、同様に基本的にウェブ・サーバ上に物理的にストアされる最初のトポロジとの間の差異をストアする。このタスクのために、従来技術のポータル・データベースの付加的なデータベース・テーブルを設けることが好ましい。このテーブルは１７８で示され、ここでデータベースは図１及び図２に１２８で示される。ユーザがログインに成功するたび毎に、この特定のデータベース・テーブル１７８にストアされたユーザ指定データが動的アセンブリ変換コンポーネント１７２によって読み取られて評価され、ユーザ指定ナビゲーション・トポロジが再構成される。

ここで図４をさらに参照しながら、ポータル訪問者（ユーザ又は行為者４１０）と前述のコンポーネント１７０乃至１７７との間の相互作用を、以下により詳細に説明する。

ユーザ４１０は、ウェブ・ポータルのウェブ・ページと相互作用する。この相互作用は、多数の繰り返し動作、例えば、リンクのクリック、ポータルのクリック、ウェブ・ページ上でクリックすることができる任意のリソースのクリックを含む。複数の相互作用を示すために、それぞれの矢印４２０はループ記号で表される。各々の相互作用に関して、以下の手続きが実行されることになる。

現在の相互作用は、ウェブ使用率マイニング・コンポーネント１７６に通知される。その通知は、現在のユーザのログイン後に取得可能なユーザＩＤを含み、またどのページのどのノードがクリックされたか、そしてこれがいつ起きたかの情報を含む。従って、それぞれのデータ・セットは、ユーザＩＤ、ノードＩＤ、ページＩＤ、並びに、時刻及び日付情報を含む。オプションとして、もちろんそれはまた、デバイス・タイプ情報を含むことができ、これからユーザがＰＤＡ、又はノートブック、或いはデスクトップ・コンピュータをそれぞれ使用しているかどうかを導くことができる。これはステップ４３０において実行される。

全てのデータは、コンテキスト・オブザーバ・コンポーネント１７７に送られ（ステップ４４０参照）、実際に用いられたコンテキストが判断される（ステップ４４０及び上のステップ４３０参照）。データ収集が完了したとき、それはステップ４５０においてデータベース１７８内に、データベース・ストレージ・コンポーネント１７４によってストアされる。

次いで、次のステップにおいて、同じユーザが再びログインすると仮定する（ステップ４６０参照）。この場合、集約コンポーネント１７０は、ユーザＩＤ、入手可能であれば現在使用されているデバイスＩＤ及び他のコンテキスト情報（上記参照）を評価する機構を呼び出す。

次に、集約コンポーネント１７０は、現在のウェブ・ページのテーマ内に推薦（本発明により生成される）を埋め込むことを要求する（ステップ４６５参照）。

次にステップ４７０で、変換コンポーネント１７２が、現在使用されているコンテキストの現在の判断を要求することになる。それは、それぞれの要求をコンテキスト・オブザーバ・コンポーネント１７７に指示し、これが最後の要求ヘッダから、及びシステム時刻のような他の入力ソースから現在のコンテキスト・データを読み取り、タイム・スタンプなどを配信する。コンポーネント１７２は、次のステップ４７５でこのコンテキストを受信する。

推薦コンポーネント１７２は次に、データベースからストアされフィルタされた相互作用シーケンスを読み取り（ステップ４８０、４８５参照）、そして推薦を生成する。これらの推薦がどのように生成されるかの詳細を、以下でより詳しく説明する。

次に、推薦コンポーネント１７２が、それらの推薦を集約コンポーネント１７０に戻し、集約コンポーネント１７０が、それを現在のウェブ・ページ・テーマに表示する。
次に、図５を参照しながら、ユーザ行動の観測の詳細を説明する。

一連のステップのうちのステップ５１０において、ユーザがナビゲーション・トポロジのノード部分にナビゲートされる。このノード部分は、ページ上の任意のクリック可能項目とすることができる。次にチェック５２０が実行されて、ユーザがある特定の選択されたノード上で相互作用するかどうかがテストされ、例えばユーザがポートレットをクリックするかどうかがテストされる。否（ＮＯ）の場合、この特定の選択されたノードに関連するいわゆる保持時間が、ステップ５２０でなされたクリックに関連する時刻と、次のユーザ要求に関連し、ウェブ・サーバのインボックスで受信された後続のクリックの時刻とに基づいて計算される。通常、両方の時刻の差となる保持時間が、予め計算された中央値保持時間よりも長い場合、ステップ５３０に分岐する。そうでない場合には、ステップ５１０に分岐して戻る。また、判断５２０で肯定（ＹＥＳ）の場合、ステップ５３０に進む。ステップ５３０において、選択されたノードに対するターゲット・ヒット値が、ウェブ使用率マイニング・コンポーネント１７６を用いて新たに計算される。

次いで、次のステップ５３５において、コンテキスト・オブザーバ・コンポーネント１７７を用いて現在のコンテキスト属性が判断される。最後に、ステップ５４０において、新しいターゲット・ヒット値が、データベース・ストレージ・コンポーネント１７４を用いて適切なコンテキスト区画にストアされる。次いで、次のユーザ相互作用を観測するために、ステップ５１０に分岐して戻る。

図６は、所与のナビゲーション・ノードに対するショートカット・リストを生成する際の、本発明の方法の最も本質的なステップを示す制御フロー図である。図６を参照しながら、ターゲット・ページへのショートカットを作成するときの制御フローを、より詳細に説明する。

集約コンポーネント１７０は、所与のポータル・ナビゲーション・トポロジをトラバースすると仮定される。これは、本発明の方法によって実行され送信されるユーザの動作に密接に関連して実行される（ステップ６１０参照）。各々のページに対して、以下の動作が実行される。

ステップ６２０において、ユーザがナビゲートされる全てのウェブ・ページに関して、以下のループ本体を行うために、ループ条件がテストされる。

ステップ６３０において、集約コンポーネント１７０が推薦コンポーネント１７２を呼び出す。

次いで、次のステップ６４０において、現在ログインしているユーザのユーザＩＤが検出されて評価され、ステップ６５０において、それぞれの現在のコンテキスト属性（日付、時刻、使用されたクライアント・デバイス）がコンテキスト・オブザーバ・コンポーネント１７７を用いて判断される。

次いで、次のステップ６６０において、現在のユーザ及び現在のコンテキスト区画に関する全てのノードのストアされたターゲット・ヒット値が読み取られ評価される。

ステップ６７０において、「期待節約」を計算する関数が呼び出される。この関数の出力は、トポロジのターゲット・ノードのリストである。

さらにステップ６７５において、ターゲット・ノードのこのリストが、それぞれのターゲット・ノードへのクリック可能なリンクに変換され、従って、場合により特定のリンク情報が与えられる。それにより、それぞれのショートカット・リストが生成され、ここで各々のリンクはそれぞれのショートカットに対応する。次に、ステップ６８０において、それらのショートカットが現在のウェブ・ページの好ましくはテーマの内部に表示される。

次に、図７の（Ａ）乃至（Ｈ）を参照しながら、前述の期待節約の計算の好ましい実施法を説明する詳細を与える。

最初に、ポータルを通してのユーザのナビゲーションをマルコフ連鎖として見ることが提案される。このモデルを用いて、ユーザが将来訪問することになるページが、現在のページ及び最近の訪問履歴によって判断されると仮定する。

従って、ｎ次のマルコフ・モデルが現在のページ及び最近のｎ−１個の訪問ページを考慮して、各ページが次に見られる確率を決定する。

このモデルは、確定経路ｐｉ−１、・・・ｐｉ−ｎをトラバースした後で、ページｐｉが何回訪問されたかをカウントすることによって訓練される。次に、リンクｐｉ−１からｐｉまで辿る確率が、図７（Ａ）に示すように計算される。

明らかに、このモデルの複雑さ、従って、必要な計算を行うのに費やされるリソースの量は、モデルの次数に伴って増大する。一次マルコフ・モデルの使用が良好な結果を与え、より高次のモデルを用いることは、モデルの複雑さの増加を考慮に入れると利益に値しないことが示唆される。従って、この実施形態においては、一次マルコフ・モデルを用いた。

これまでは、ユーザをモデル化するように説明された機構は、時間的に変化しないものであった。これは、ログ・ファイルが与えられると、これらのログが記録されたときに存在した状況下でのみ有効である利用可能なデータからユーザのモデルを生成することを意味する。ユーザの行動が時間と共に変化するのに伴って、これらのモデルは陳腐化する可能性があり、ログ・ファイルの現実的なバージョンを用いる或る種の再計算が必要となることを意味する。モデルが陳腐化する別の可能性は、管理者によるコンテンツの再構成である。その場合、コンテンツ構造の変更が行われるたび毎にモデルの再計算が必要となる。

時間感度を付加するために、以下のパラメータを用いた時間加重機構が設計された。

Ｔ−関連性。これは、ログ・ファイルからのデータが有効であると考えられる時間である。従って、それよりも古いデータは、モデルには考慮に入れない。

Ｎ−スロットは、関連性時間が分割されるスロットの数である。これらのスロットは、次にログ・ファイルからのデータに重みを付けるのに用いられる。従って、最近の時間スロット内で記録されたデータは、より古いものからのデータよりも大きな重みが与えられる。

次に、この機構は、ヒットの絶対数を単にカウントするのではなく、すべてのページ及びリンクに対するヒット率の推定を試みる。ヒット率は、各々の時間スロットに対するヒット率推定値の線形加重和を実行することによって計算される。そのため、時間スロットｉにおける要素ｅについてのヒット率は、図７（Ｂ）に示すように計算され、ここでＴ−スロット＝｛Ｔ−関連性／Ｎ−スロット｝は、スロットの持続時間であり、ｅはヒット率を計算しようとする要素（ページ又はリンク）であり、ヒット（ｅ，ｉ）は、この要素が時間スロットｉにおいて受けたヒット数である。
今後は、スロット０が最新のものであり、スロットＮ−１が最も古いものと仮定する。

各々の時間スロットについてのヒット率計算を行ったので、図７（Ｃ）に示すように、それらの線形加重和を実行することによって、グローバル・ヒット率計算値を得ることができる。

重み因子はｉと共に減少するので、より最新のヒット率計算値に、古いものよりも大きな重みが与えられる。和に掛けられる定数の商は、単に規格化因子として働く。図７（Ｂ）の式を図７（Ｃ）の式に代入することによって、最終的に図７（Ｄ）の式が得られる。

時間の経過と共にスロットはシフトする。より古いスロットは削除されて、新しいスロットにスペースが与える。ヒット率推定値は、新しいスロットが付加されるたびに再計算され、モデルは常に実際の状況に更新される。

次に、前の静的モデルにおける確率計算が、ページ／リンク毎のヒットの絶対値ではなくこのヒット率推定値を用いて、実行される。

条件なしのモデルの場合には、図７（Ｅ）による式が与えられる。

一次マルコフ・モデルの場合には、図７（Ｆ）による式が与えられる。

図７（Ｄ）、（Ｅ）、（Ｆ）の式を見てみると、（Ｄ）の和に掛けられる定数の商は、確率計算を実行するときには無関係となる。従って、このパラメータを無視して機構の最適化バージョンを得ることができ、ページ又はリンク・ヒットの時間加重バージョンを単に図７（Ｇ）に従って計算することができる。

スロットの持続時間は、要素のヒット率の推定のために非常に重要な因子である。非常に短い時間間隔を選択すると、モデルはＴ−スロットごとに更新されるので確かに迅速な適応がもたらされるが、モデルの分散が増加する。これは、ユーザ行動における急速な変化がモデルに大きな影響を与えるので、推定値の質が低下することを意味する。通常の条件においては、スロットは、およそ１日の持続時間を有する必要がある。

明らかに、関連性時間はまた、ここでの重要な因子である。それは、ユーザが実行する動作がなお有効であると考えられる時間を決定するだけでなく、それはまた、スロット数、Ｎ−スロット＝Ｔ−関連性／Ｔ−スロットを決定し、これに対してヒット率が計算されてグローバル・ヒット率の推定値が得られる。このようにスロット数が大きくなるとモデルの分散が小さくなる。

Ｔ−関連性パラメータの値の選択は、ポータルのタイプに依存する。そのため、コンテンツ又はサービスがすぐに古くなり、新しいものと置き換えられる非常に動的なポータルは、短い関連性時間を有する必要があり、一方、非常に静的な構造を有するポータルは、長い関連性時間を有する必要がある。

ここで、現在のユーザがナビゲートされたノードと、本発明の方法によってそこへのショートカットが生成されるターゲット・ノードとの間の、マウス・ポインタ移動を含まないクリック数だけのクリック距離ｄに関しては、可能性のあるターゲット・ノードはそのフロント・ページからさらに遠く、そのターゲット・ノードに到達するのはさらに困難であることを考慮に入れる必要がある。この態様を期待節約の計算に組み入れるために、期待節約を計算する式が図７（Ｈ）によって与えられ、ここで、ショートカットによって節約されるリンクは距離−１に等しく、またｐは、ユーザが現在のページからターゲット・ノードにナビゲートされる確率である。

この式において、距離は、確率の前に「区別」されており、一方、構造体内で１レベル深いノードに到達する確率は指数関数的に減少し、このノードと現在のノードとの間の距離は、指数ｎ＝１の場合に直線的にのみ増加する。このようにして、現在のページに近いノードは、それからさらに遠い他のノードよりも推薦される可能性が高くなる。

一方、ｎ＞１とすることにより、ショートカットによって節約されるリンク数により大きな重要性を与えることになる。これは、システムがより積極的な推薦、即ち、現在のページからさらに離れたノードへのショートカットを作成する結果としてである。

当業者であれば、特定の手続き及び提案されたステップ・シーケンスを示す前述の実施形態は、本来、本発明の方法を実施例により説明するために与えられたものであることを理解するであろう。従って、これらの実施例は、例えば、ステップの順序、ステップ間の並列化の程度、単一のステップの実施の詳細、データをストアする形態、ポートレットのグループ化を達成する方法などのような種々の態様において変化させることができ、それぞれのさらに別の実施形態を得ることができることを理解されたい。

本発明は、ハードウェア、ソフトウェア、又は、ハードウェアとソフトウェアの組合せにおいて実現することができる。本発明によるポートレット配置ツールは、１つのコンピュータ・システムに集中化された形態で、又は、異なる要素が幾つかの相互接続されたコンピュータ・システムにわたって分散された分散形態で実現することができる。本明細書で説明された方法を実行するように適合された任意の種類のコンピュータ・システム又他の装置が適切である。ハードウェアとソフトウェアの典型的な組合せは、ロードされ実行されるとき、本明細書で説明した方法を実行するようにコンピュータ・システムを制御するコンピュータ・プログラムを有する汎用コンピュータ・システムとすることができる。

本発明はまた、本明細書で説明した方法の実施を可能にする全ての特徴を含み、そしてコンピュータ・システムにロードされたとき、これらの方法を実行することができるコンピュータ・プログラムに組み込むことができる。

ここでの文脈において、コンピュータ・プログラム手段又はコンピュータ・プログラムは、直接に、又は
ａ）別の言語、コード、又は表記への変換、
ｂ）異なる材料形態での複製
のいずれか又は両方の後で、情報処理機能を有するシステムに特定の機能を実行させることを意図した一組の命令の、任意の言語、コード又は表記における任意の表現を意味する。

相互作用ラインを含む従来技術のポータル・サーバの構造的コンポーネントを示す概略図である。 本発明の特定の実施形態による、内部に実装された構造的コンポーネントを示すポータル・サーバの概略的なブロック図による表現である。 図２のボックス１７５へのズーム・インを示す概略図である。 ユーザ（行為者）によって実行される一連の動作と、図３に示されるような本発明の方法によって実装されるコンポーネントとを示す概略的相互作用図である。 ウェブ・ポータル・トポロジ上でナビゲートするときのユーザ行動を観測する際の、本発明の方法の好ましい実施形態の制御フローを示す概略図である。 ナビゲーション中に動的にショートカットが生成されてユーザに表示されるときの、本発明の方法の好ましい実施形態において実行される本質的なステップを示す概略的な制御フロー図である。 （Ａ）−（Ｈ）は、本発明による期待節約の計算の好ましい実行を示す式である。

１００：ウェブ・サーバ
１０５：ユーザ認証
１１０：状態処理
１１５：集約
１２０：ポートレット
１２５：ページ
１２８：ポータル・データベース
１３０：ポートレット（ＡＰＩ）
１３５：ポートレット・コンテナ・ソフトウェア
１４０：ポータル・ストレージ・リソース
１５０：ポータル・モデル
１７０：集約コンポーネント
１７２：推薦コンポーネント（変換コンポーネント）
１７４：データベース・ストレージ・コンポーネント
１７６：ウェブ使用率マイニング・コンポーネント
１７７：コンテキスト・オブザーバ・コンポーネント
１７８：データベース・テーブル
４１０：行為者（ユーザ）
４２０、４３０、４４０、４４０、４５０，４６０、４６５、４７０、４８０、４８５，４９０：ステップ
５１０、５２０、５２５、５３０、５３５、５４０：ステップ
６１０、６２０、６３０、６４０、６５０、６６０、６７０、６７５、６８０：ステップ

Claims (10)

1. ノード及び該ノード間を接続するエッジを含み、内部のウェブ・ポータル・ページ（１２５）が所定のトポロジ・レベルに対応し且つ１つ又は複数のポートレット（１２０）を表示する所与の階層的ナビゲーション・トポロジにおいて、ナビゲーション中にユーザを支援するためのウェブ・ポータル環境で用いられるサーバで行われる方法であって、
   前記サーバが、
   ａ）前記階層的ナビゲーション・トポロジにおけるユーザのナビゲーション中に、前記ナビゲーションを含む各々のページに対する前記ユーザのナビゲーション行動に関する情報を自動的に検知する第１のステップ（５２０、５２５）と、
   ｂ）前記検知された情報からページ・ヒット及びページ・ターゲット・ヒットを導出するステップであって、前記ページ・ヒットは別のページに到達するためにクリックされたページについて定義され、前記ページ・ターゲット・ヒットはページ指定タスクを実行するため又はあるページ指定情報を受信するためにユーザがクリックするページについて定義される、第２のステップ（５３０）と、
   ｃ）前記検知された情報に基づいて、ユーザがナビゲーションを行ったウェブ・ページについて所定のメトリックを用いてその重要性を示す有用性ランキングを生成するステップであって、前記ページの有用性ランキングの計算は新しく使用されたページのナビゲーション時間に関連した加重優先順位付けを含む、第３のステップと、
   ｄ）前記ユーザのナビゲーション中に現在のナビゲーション位置を追跡する第３のステップ（６２０）と、
   ｅ）前記現在のナビゲーション位置及び複数のターゲット・ページについて、前記有用性ランキングによって得られる前記ターゲット・ページのそれぞれ１つにナビゲートする確率の大きさを、現在のページ及び最近の訪問履歴に応じてマルコフ・モデルによって計算する第４のステップと、
   ｆ）前記ターゲット・ページの有用性、及び前記現在のページと前記ターゲット・ページの間のナビゲーション距離に基づいて、各々のターゲット・ページに対する期待節約因子を計算する第５のステップ（６７０）と、
   ｇ）所定の閾値よりも高い期待節約因子を有する前記ターゲット・ページの少なくとも１つへの、それぞれの直接リンクを含む少なくとも１つのショートカットを定めるステップ（６７５）と、
   ｈ）前記ショートカットをクリック可能リンクとして前記ユーザに表示する第６のステップ（６８０）とを行う方法。
2. 前記第２のステップにおいて、前記ページ・ヒットは、ページの最初のクリックと、該最初のクリック後の所定の時間範囲内でなされた次のクリックとによって定義され、前記ページ・ターゲット・ヒットは、ページの最初のクリックと、所定の第２の時間範囲が経過した後でなされた次のクリックとによって定義される、請求項１に記載の方法。
3. 前記第６のステップでは、前記期待節約因子の大きさに従って並べられた、クリック可能なショートカットのリストが表示される、請求項１に記載の方法。
4. 前記第５のステップにおいて、前記期待節約因子の計算値は、ターゲット・ページの有用性とナビゲーション距離の積を含む、請求項１に記載の方法。
5. 前記第５のステップにおいて、前記期待節約因子の計算値は、前記積の累乗を含む、請求項４に記載の方法。
6. 前記第６のステップで、前記ショートカットは、現在表示中のウェブ・ページのテーマの中に表示される、請求項１に記載の方法。
7. 前記サーバが、
   ａ）ａ１）現在の日付と、
   ａ２）現在の時刻と、
   ａ３）現在使用されているデバイスのタイプと
   からなる群からのコンテキストを観測するステップと、
   ｂ）現在のユーザ・セッションに関するそれぞれのコンテキスト情報をストアするステップと、
   ｃ）ショートカットの生成及び／又はショートカットの表示のためのフィルタとして前記コンテキスト情報を使用するステップと
   をさらに行う請求項１に記載の方法。
8. ノード及び該ノード間を接続するエッジを含み、内部のウェブ・ポータル・ページ（１２５）が所定のトポロジ・レベルに対応し且つ１つ又は複数のポートレット（１２０）を表示する所与の階層的ナビゲーション・トポロジにおいて、ナビゲーション中にユーザを支援するように配置されたウェブ・ポータル環境におけるウェブ・アプリケーション・サーバ・コンピュータ・システムであって、
   ａ）前記階層的ナビゲーション・トポロジにおけるユーザのナビゲーション中に、前記ナビゲーションを含む各々のページに対する前記ユーザのナビゲーション行動に関する情報を自動的に検知する第１のステップ（５２０、５２５）と、
   ｂ）前記検知された情報からページ・ヒット及びページ・ターゲット・ヒットを導出するステップであって、前記ページ・ヒットは別のページに到達するためにクリックされたページについて定義され、前記ページ・ターゲット・ヒットはページ指定タスクを実行するため又はあるページ指定情報を受信するためにユーザがクリックするページについて定義される、第２のステップ（５３０）と、
   ｃ）前記検知された情報に基づいて、ユーザがナビゲーションを行ったウェブ・ページについて所定のメトリックを用いてその重要性を示す有用性ランキングを生成するステップであって、前記ページの有用性ランキングの計算は新しく使用されたページのナビゲーション時間に関連した加重優先順位付けを含む、第３のステップと、
   ｄ）前記ユーザのナビゲーション中に現在のナビゲーション位置を追跡する第３のステップ（６２０）と、
   ｅ）前記現在のナビゲーション位置及び複数のターゲット・ページについて、前記有用性ランキングによって得られる前記ターゲット・ページのそれぞれ１つにナビゲートする確率の大きさを、現在のページ及び最近の訪問履歴に応じてマルコフ・モデルによって計算する第４のステップと、
   ｆ）前記ターゲット・ページの有用性、及び前記現在のページと前記ターゲット・ページの間のナビゲーション距離に基づいて、各々のターゲット・ページに対する期待節約因子を計算する第５のステップ（６７０）と、
   ｇ）所定の閾値よりも高い期待節約因子を有する前記ターゲット・ページの少なくとも１つへの、それぞれの直接リンクを含む少なくとも１つのショートカットを定めるステップ（６７５）と、
   ｈ）前記ショートカットをクリック可能リンクとして前記ユーザに表示する第６のステップ（６８０）とを実施する機能コンポーネント（１７５）を含むシステム。
9. ノード及び該ノード間を接続するエッジを含み、内部のウェブ・ポータル・ページ（１２５）が所定のトポロジ・レベルに対応し且つ１つ又は複数のポートレット（１２０）を表示する所与の階層的ナビゲーション・トポロジにおいて、ナビゲーション中にユーザを支援するように配置されたウェブ・ポータル環境におけるデータ処理システムにおいて実行のためのコンピュータ・プログラムであって、該プログラムが、データ処理システムに、
   ａ）前記階層的ナビゲーション・トポロジにおけるユーザのナビゲーション中に、前記ナビゲーションを含む各々のページに対する前記ユーザのナビゲーション行動に関する情報を自動的に検知する第１のステップ（５２０、５２５）と、
   ｂ）前記検知された情報からページ・ヒット及びページ・ターゲット・ヒットを導出するステップであって、前記ページ・ヒットは別のページに到達するためにクリックされたページについて定義され、前記ページ・ターゲット・ヒットはページ指定タスクを実行するため又はあるページ指定情報を受信するためにユーザがクリックするページについて定義される、第２のステップ（５３０）と、
   ｃ）前記検知された情報に基づいて、ユーザがナビゲーションを行ったウェブ・ページについて所定のメトリックを用いてその重要性を示す有用性ランキングを生成するステップであって、前記ページの有用性ランキングの計算は新しく使用されたページのナビゲーション時間に関連した加重優先順位付けを含む、第３のステップと、
   ｄ）前記ユーザのナビゲーション中に現在のナビゲーション位置を追跡する第３のステップ（６２０）と、
   ｅ）前記現在のナビゲーション位置及び複数のターゲット・ページについて、前記有用性ランキングによって得られる前記ターゲット・ページのそれぞれ１つにナビゲートする確率の大きさを、現在のページ及び最近の訪問履歴に応じてマルコフ・モデルによって計算する第４のステップと、
   ｆ）前記ターゲット・ページの有用性、及び前記現在のページと前記ターゲット・ページの間のナビゲーション距離に基づいて、各々のターゲット・ページに対する期待節約因子を計算する第５のステップ（６７０）と、
   ｇ）所定の閾値よりも高い期待節約因子を有する前記ターゲット・ページの少なくとも１つへの、それぞれの直接リンクを含む少なくとも１つのショートカットを定めるステップ（６７５）と、
   ｈ）前記ショートカットをクリック可能リンクとして前記ユーザに表示する第６のステップ（６８０）とを実行させる、コンピュータ・プログラム。
10. コンピュータ可読プログラム手段を含むコンピュータ使用可能媒体にストアされたコンピュータ・プログラムであって、該コンピュータ・プログラムがコンピュータ上で実行されるとき、請求項１乃至請求項７のいずれか１項に記載の方法をコンピュータに実行させる、コンピュータ・プログラム。

Images