JP4378524B2 - 階層メニューを有するインテリジェントなインターネットウエブサイト - Google Patents

Description

本発明は、インターネットウエブサイトに関し、特に、ポータルまたはゲートウエイとして一般的に知られている種類のインターネットウエブサイトに関し、そのウエブサイトはインターネットに最初に接続されたときユーザに対するスターティングサイトであるか、またはスターティングサイトとなることを申し出るウエブサイトである。主要なインターネットポータルの例はヤフー、エキサイト、およびネットスケープである。

インターネットサイトまたはサーバはほとんど常にユーザに階層メニュー構造を提供する。よく知られているように、トップレベルメニューページ、通常はホームページを含み、別のメニューページまたは“リンク”ページ（すなわち、ユーザに対して最終的に興味のあるページで、さらに別のポータルのメニュー構造のメニューオプションを含んでいない）のいずれかである複数のサブページへのリンク（選択可能なメニューオプション）を有している。さらに別のメニューページ自体はさらに複数の別のサブページに対するさらに別のメニューオプションを有しており、複数の別のサブページのそれぞれはさらに別のメニューページまたは別のリンクページを有してもよく、全てがリンクページである階層の一番下のレベルまで同様の構成を有している。リンクページ自体がメニューオプションを有していてもよく、例えばリンクページがそれ自体のメニュー構造を有する会計ウエブサイトのホームページであるならば、これらはインターネットサイトのオペレータの制御下にはなく、それ自体のメニュー構造の一部とは考えられない。

既存のポータルによる問題はメニュー構造が固定されていることである。これは、ユーザが関心のあるリンクページに到着するために、いくつかのメニューおよびサブメニューを通って“ドリルダウン”しなければならないが、しかしながら、ユーザはしばしば彼が常にそのプロセスを通って行かなければならないページにアクセスすることを意味している。もちろん、ユーザが関連するページを直接アクセスするために“ブックマーク”できるが、彼はそれを思い出さない可能性もあり、ブックマークによる方法はＷＡＰ装置において利用することはできないかも知れない。いずれにせよ、個々のページをブックマークする方法は固定されたメニュー構造を無視することはできず、それは全体的にユーザの所望のブラウジング特性と一致しない可能性がある。

問題は、無線インターネットおよび移動体電話情報にアクセスする方向に移行しているので悪化している。移動体電話のような新しい装置はその機能性およびスクリーンの大きさが制限され、その結果、情報アクセス装置としての有用性を制限している。例えば、移動体電話のスクリーンの大きさは典型的なＰＣのスクリーンの２００分の１であり、ユーザは情報のスペースに狭いアクセスウインドウが提供され、スクリーンのスペースの各画素がエンドユーザに適切な情報を伝達するために使用されるので全てがさらに重要になる。簡単に言うと、移動体ユーザが正しい時間に正しい情報に迅速で容易にアクセスすることを確実にするためには、現世代のＷＡＰエネーブルサービスおよび次世代の３Ｇ情報サービスを含む移動体／無線情報の将来のアクセスに対して重要なことである。

伝統的なＷＡＰポータルはホームページからそれらの情報目的地に映画、ＴＶリスト、ニュース、天候等をユーザに提供するために予め定められたナビゲーションメニューのセットをユーザに提供する。その時に存在する問題は、各ユーザが同じフロントエンドにより与えられ、典型的にあるスクロールのシーケンスにしたがわなければならず、所望の情報を位置させるために、“１つのサイズが全てに適合する”ナビゲーションソリューションをクリックすることである。

本発明は、この問題を克服し、緩和することを目的としている。

したがって、本発明は、ユーザに階層メニュー構造を与えるインターネットウエブサイトを提供する。そのウエブサイトはデフォルトメニュー構造を有しており、そのウエブサイトにおける少くともユーザの以前のブラウジング履歴にしたがってデフォルトメニュー構造を時間の経過と共に自動的に修正する手段を備えている。

本発明はさらに、ユーザに階層メニュー構造を与えるインターネットウエブサイトを動作させる方法を提供し、その方法は、少くともウエブサイトにおけるユーザの以前のブラウジング履歴にしたがって各ユーザに対するデフォルトメニュー構造を時間の経過と共に自動的に修正するステップを含んでいる。

本発明はさらに、ユーザに階層メニュー構造を与えるインターネットウエブサイトにおいて使用するためのコンピュータプログラムを提供し、その方法は少くともユーザのウエブサイトにおける以前のブラウジング履歴にしたがって、各ユーザに対するデフォルトメニュー構造を自動的に修正する。

ＷＡＰエネーブルされたポータルに関して主として利用されているが、本発明は一般的にインターネットポータル適用可能である効果を有する。

本発明の例示的な好ましい実施の形態を添付図面を参照にして以下詳細に説明する。本発明の実施の形態により説明される問題を充分に理解し、認識するために、図１に示されているＷＡＰ電話の使用の簡単な例について考える。ローカルな映画（ダブリンのスチロガンにおけるオルモンド映画）の現在の映画リストにアクセスするために、ユーザはつぎのような動作シーケンスを行わなければならない。

図１の（ａ）：スクロールしてホームページ（オプション７）の［娯楽］オプションを選択する。
図１の（ｂ）：スクロールして娯楽メニュー（オプション４）の［映画］オプションを選択する。
図１の（ｃ）：映画メニュー（オプション１）の中の［映画時間］オプションを選択する。
図１の（ｄ）：スクロールしてダブリン（オプション９）を選択する。
図１の（ｅ）：最後に［オルモンド］（オプション８）を選択する。
これは現在のＷＡＰポータルにおける典型的なユーザセッションを示しており、このユーザは規則的なベースでオルモンドの映画のリストを問合せる場合であっても、ＷＡＰポータルはこの特定のユーザをより良くサービスするためにその構造を変更することはできない。

図２を参照すると、オルモンドからの映画のリストのソースとしてユーザのＷＡＰ電話を使用するためのユーザの嗜好を与えるならば、以下説明される実施形態は、ＷＡＰメニュー構造内の高い順位の位置に［オルモンド］メニューオプションを格上げする。例えば［娯楽］オプションの最上位レベルはオプション７から上位３以内の位置（すなわちユーザが見る最初のスクリーン）へ格上げされる。図２の（ａ）参照。図２の（ｂ）は娯楽メニューのトップに格上げされた［オルモンド］オプションを示している（図２の（ｂ））。この例ではまた、映画に対するユーザの嗜好がＷＡＰサイトのＴＶリストから格上げされた［ＴＶ映画］オプションに反映されていることが認められる。もちろんユーザは残りの映画およびＴＶ選択のような他の関連するサイトセクションにより直接にアクセスを与えることができる。

図３はＷＡＰポータルに含まれた本発明の第１の実施形態のシステムアーキテクチャのブロック図である。実施形態を説明するために必要な素子だけが示され、ポータルの全体のアーキテクチャは示されていないことを認識するであろう。この実施形態は、メニュー管理装置10と、個人化エンジン14およびカスタム化エンジン16を含むメニューサーバ12とを含んでいる多数の異なったソフトウエアコンポーネントを含んでいる。

メニュー管理装置10は、ＷＡＰまたはウエブベースのいずれかの完全個人化された情報サービスを技術的スタッフ18なしに迅速に開発し、構成し、配備することを可能にするように設計されたユーザ対面アプリケーションである。個人化エンジン14は個人化されたメニューページの生成と、ユーザの性質のプロファイル処理を制御するためのサブシステムである。クライアント20は典型的に標準的なウエブンまたはウエブンブラウザである。カスタム化エンジン16は自動的な個人化を固定または無視するためにポータルの完全にカスタム化された部分にそれらを許容するようにクライアントアプリケーションをエンドユーザに提供するサブシステムである。クライアント24は典型的に標準的なウエブンブラウザである。

典型的に、メニュー管理装置10は以下の方法で使用される。オペレータ18は最初にコアコンテンツとデフォルト構造をメニュー管理装置の迅速なプロトタイプ装置（これは図４を参照に説明する）を使用するそれらのポータルに対して生成し、決定する。コアコンテンツはコンテンツデータベース26に記憶される。第２に、さらに、メニュー管理装置10を使用してオペレータ18は各レベルで見られるメニューオプションの数と個人化に対するポータルの感度（これは図５を参照に説明する）とを含んでいる基本的な個人化特性を規定する。第３に、最終的なポータルは配備され、エンドユーザ22に利用可能とされる。

ポータルが発行されると、ユーザはカスタム化エンジン16（これは図６を参照に説明する）と相互作用することによりポータル構造を手作業でカスタム化することができる。非常に簡単に説明すると、これはエンドユーザがポータルサイトのあるメニューオプションを予め選択し、これらをそのサイトのメニュー構造のより高い位置に格上げすることを可能にする。例えば映画ファンは、彼等のローカル映画へのメニューリンクが低いメニュー中に隠されているのではなく、トップレベルのメニュー内に含まれていることを指定する可能性がある。さらに、カスタム化エンジンはユーザの必要性とは関係のないポータルサイトの残りの部分をユーザが除去することを許容し、またサイトのある領域が自動的な個人化を受けてはならないことをユーザが指定することを可能にする。一般的に説明するとカスタム化エンジンは標準的なウエブンブラウザ24を通ってユーザに利用可能にされ、カスタム化された変化をそれらがすることを許容するために直観的なグラフィックユーザインターフェースを含んでいる。

ポータルが一度発行されると、個人化エンジン14は個々のユーザアクティビティの監視および追跡を開始して、ユーザのブラウジング履歴にしたがって各ブラウジング経験をアクティブに変更する。これは、ユーザがかれらのブラウザを介して新しいページをリクエストする都度、このページに表示されるメニュー（ナビゲーション）オプションはポータルオペレータによって示唆されたデフォルトオプションおよび個人化エンジン14により推薦された示唆されたオプションに基づいて実時間で計算される。実際に、ポピュラーなメニューオプション（ユーザに対して）は階層メニュー構造中の高い位置に格上げされ、それによりポータルサイトのこれらの領域は問題としているユーザにアクセス可能となる。

上述のコンポーネントのそれぞれについてさらに詳細に検討すると、メニュー管理装置10は直観的ＧＵＩインターフェースを有するユーザに対面したアプリケーションであり、このインターフェースは、経験者でないものが迅速に設計して熟練した情報ポータルを配備することを可能にする。ユーザはドラッグおよびドロップ機能を使用してメニューおよびコンテンツページを容易に規定することができる。メニュー管理装置10は自動的にソースファイル（．wml,.html,.xml）を生成し、発行し、それは最終的なポータルサイトを形成し、大規模なポータルでさえも数時間で配備し、テストされることができる、
使用におけるメニュー管理装置のスクリーンの画面が図４に示されている。主インターフェースは３つの主要なセクション、すなわち、サイト構造30と、ページプロパーティ32と、エラー報告34とに分割されている。サイト構造セクション30は、オペレータが直感的ツリーベース表示およびドニッグおよびドロップスタイルインターフェースを使用してポータルサイトの基本的階層メニュー構造を決定することを可能にし、それは個々のページが付加され、または消去され、またはサイトの異なった区域に移動されることを可能にする。

図４は“ｅマージホーム”と呼ばれるホームページに位置する特定のポータルサイトの構成を示している。

オペレータは第１および第２のレベルのリンクを含む多数の異なったページを規定する。例えば、“ｅマージホーム”ホームページは“Ｅメール＋Ｏｒｇ”と呼ばれるメニューページに対するリンクを含み、そのリンクは次に“メッセンジャ”“ＷＡＰメール”等と呼ばれる情報ページに対するリンクを含んでいる。

オペレータが基本的なサイト構造を規定するので、彼はセクション32において次のような各ページの詳細な特性を特定することができる。

＊タイトル名：メニュー管理装置に現れるページのタイトル
＊スクリーンラベル：タイトル名と異なっている場合に、ポータルが発行されるとクライアントブラウザ上に現れるページのタイトル。通常の場合のように、それらが内部ページコード化方式から得られた場合に特にスクリーンラベルとして使用するために非常にしばしばタイトル名が含まれる。

・プロモーション名：オペレータはあるページに対する別のプロモーション名を特定することができ、それは問題とするページがデフォルトメニュー位置の外部にプロモートされている場合に使用される。これはオペレータがあるページに対する付加的な内容の情報を提供することを可能にし、それはそれでなければその情報はプロモーション中に失われる。例えば、そのスクリーンラベルとして“トピックス”を有するポータルのＴＶセクションからの１つのページについて検討する。そのページは所定の日についてトップＴＶプログラムをリストにするように設計されるが、これはそのページがそのＴＶページからのリンクとして残されている場合のみクリアである。もしもこの“トピックス”ページがユーザにポピュラーなものであれば、それはより高いレベルに格上げされてその意味はもはや明らかである。この問題を解決するためにオペレータは“ＴＶ：トピックス”のようなプロモーション名を特定することができる。

・本体：このプロパティは、ページがエンドユーザに与えられる方法を制御するために現在のページに対する表現テンプレートをオペレータが特定することを可能にする。

・ＵＲＬ：問題とするページのＵＲＬである。

・広告：オペレータはページを有して（ウエブコンテンツに対して）含まれている広告挿入物、またはページの前に含まれている（ＷＡＰコンテンツて）広告挿入物に対するリンクを含むことができる。この特別の効果は、オペレータは関係するメニューによる特別の広告を関連されることができるから、これらの広告はユーザがこれらの広告が個人化されたメニュー中にプロモートされたこれらのメニューを有することにより関心のあるユーザによって頻繁に観察されることができると言う意味で、広告メッセージがターゲットとされることを可能にすることである。例えばライアン航空会社がトップレベルの旅行メニューにそれらの広告バナーを位置させることによってポータルの旅行セクションに広告スペースを購入してもよく、それは典型的に旅行関連サービスの全ホストに導かれる。ポイントはライアン社が旅行に関心のある人々をターゲットとしたいと考えていることである。その理由は、これらはその会社の航空便を購入する可能性が高いからである。通常ライアン航空会社の広告および旅行メニューはサイト内の静止位置に配置されるであろう。しかしながら、サイトが個人化されている現代では、旅行に関心のあるユーザはメニュー階層の高い位置にプロモートされた旅行セクションを見て、サイトの旅行部分に入り、ライアン航空会社の広告を見る可能性が高い。この広告を見ることに関して関係のないユーザに対する関係のあるユーザの比率は劇的に増加するであろう。

さらに、オペレータは問題のページが個人化された時、およびどのように個人化されるかを制御するために各ページに対してあるキーとなる個人化特性を特定することができる。例えば、図５の（ａ）は新しいメニューページの生成を示しており、図５の（ｂ）は新しいリンクページの生成を示しており、図５の（ｃ）はこれらのページに対する異なった個人化特性の設定を示している。図５の（ａ）および（ｂ）に示された“新しいページ”ウインドウは、図４のメニュー管理装置ウインドウ中の適切なボタンをクリックすることによってオープンされ、一方、図５の（ｃ）のプロパティウインドウは図５の（ａ）および（ｂ）の“進行”ボタンをクリックすることによってオープンされる。特に以下の用な個人化されたプロパティが設定される。

＊最大リンク：関係するメニューページに現れる最大のリンク数（これは明らかにリンクページに対しては適用可能ではない）。これは所定のページに対してどれだけの数の個人化されたサジェッションが行われたかを示す。例えば、問題のページが最大リンクを８に設定されているが、すでに５つのリンクはオペレータによって特定されている場合には、個人化装置は３つの追加のリンクしか推薦することはできない。もちろん、５つのオペレータリンクは付加的な個人化された推薦が行われたときプロモートされてもよい。この特性は特に移動体電話のようなスクリーンの制限された装置を使用して観察するポータルの開発に対して重要であり、それは各ページに対して最大のページサイズをオペレータが保証することを可能にするからである。

＊ヒットしきい値：ヒットしきい値はプロモーションを考慮される前にページが受信されなければならない最少ヒット数を示すために使用される数である。この場合の効果は、オペレータが信頼のある個人化を確実にするために充分な統計が収集できないときに、ユーザアクティビティの初期の段階中に疑似的な格上げ、格下げを制限することである。典型的にヒットしきい値は０と１０の間である（０はページが格上げ、格下げに常に利用可能であることを示している）。

＊格上げなし：オペレータは問題のページが格上げ特性を設定しないことにより個人化の一部として格上げされてはならないことを特定できる。

＊コピー格上げおよび移動格上げ：所定のページに対してコピー格上げが設定されたならば、このページ格上げされたときそれはもとのメニュー位置から消滅しない。例えば前述した例において、ＴＶメニューからの“トピックス”ページの格上げについて考慮する。コピー格上げが“トピックス”に設定されたならば、格上げ後にＴＶメニューは依然として“ＴＶトピックス”へのリンクを含んでいる。他方、移動格上げが設定されたならば、前述の例の“トピックス”は格上げ後には、ＴＶメニューからのリンクはもはや存在しない。

＊格上げ：格上げ特性は、ページが格上げされることのできる距離についての制限をオペレータが特定することを可能にする。例えば１への格上げの設定は、問題のページがその親メニューページとして同じレベルへしか格上げされることができないことを意味する。４への格上げの設定は、そのページが適切ならば４のレベルまで格上げされることができることを意味する。

一般的にメニュー管理装置10はオペレータが迅速に配備され個人化されたポータルを構成することを可能にする。アプリケーションはオペレータが多重ポータルを開発して管理することを可能にするフル投影管理設備を含んでいる。それはまた、異なったポータルビルディングパッケージを使用して設計された既存のポータル構造をオペレータが導入することを可能にする導入設備を含んでいる。この特徴は、既存の個人化されていないポータルをポータルコンテンツの再キーを必要とすることなく完全に個人化されたポータルとしてオペレータが再開発することを非常に容易にする。最後にポータルが一度設計されたならば、オペレータは編集して最終の内容コードを発行することができる。

カスタム化エンジンの仕事はポータルのメニュー構造を手作業でカスタム化する設備をエンドユーザに提供することである。

カスタム化エンジンは、標準的なブラウザクライアントを使用して操作するためにエンドユーザに対するポータル構造のグラフィック表示を生成することができる。その構造はユーザが見る構造を反映するように生成され、アクティブにポータルを使用し、すなわち、基本的なポータル構造（オペレータ規定）プラス任意の従来のカスタム化（ユーザ規定）プラス現在の個人化推奨（個人化エンジン14により与えられるような）を考慮に入れて生成される。

基本的なカスタム化動作は、所定のメニューページが新しい親メニューページの選択により示されるようにサイト内のそのデフォルト位置から新しい位置に移動されるリクエストをユーザに可能にする。全てのエンドユーザのカスタム化は図３のプロファイルデータベース28中のユーザのプロファイル構造の一部として記憶される。さらに、全てのカスタム化はポータルの設計中にオペレータによって特定された構成設定に一致しなければならない。例えば、ユーザは、そのページ中で許容される格上げレベルの最大数に違反するならば、ページをメニュー中に移動させることはできない。また、オペレータはあるページがカスタム化できないことを特定することができ、その場合にはこれらのページ再度位置を変更することはできない。

クライアントのスクリーンの表示の１例が図６の（ａ）に示されており、それは主ポータルサイトの一部を示している。図６の（ｂ）は、ユーザがポータルページ（この場合には“ＦＬＣ競合”ページ）上で選択するとき、付勢されるポップアップウインドウを示している。このポップアップウインドウはユーザがこのページの現在の位置を変更することを可能にする。このページの現在の位置（そのデフォルト位置）は“新＋クール”メニユーである。ユーザはポップアップウインドウ中の選択リストからこのページに対する新しい位置を選択することができる。例えば、“ｅマージホーム”の選択は“ｅマージホーム”ページ中に現れる“ＦＬＣ競合”リンクを生じる。その代りにユーザはポータルの彼等の観察からリンクを除去し、それは選択リストからの“トラッシュ”オプションを選択することによって達成することのできる。

個人化エンジン14はメニユーサーバ12の心臓部である。そのフェース面において、個人化エンジンは、正常なウエブサーバまたはＷＡＰサーバに類似した方法で動作する。すなわち：ページに対するクライアントのリクエストは受信されて処理され、リクエストされたページは急送される。しかしながら、ユーザ特性の概要を監視し、ポータルメニユー構造を修正して個々のユーザの学習した嗜好に最もよく適合させることもできる。すなわち個人化エンジンはコンテンツポータルを再構成することができ、それによりこれらのユーザに関係するページがホームページに近く現れるが、それ自体のポータルの適合性とは矛盾しない。簡単に言えば、個人化エンジンは次のような機能に応答可能である。

＊ユーザ特性の概要を追跡しその輪郭を描く。これはユーザがリクエストするページ（彼がどのリンクを選択するか）を監視し、予測に基づいてそれが使用できるプロファイルでこの情報を記憶する。

＊概要の特性をユーザで特定されたカスタム化と組合わせて単一化されたユーザプロファイルを生成する。

＊リクエストベースで各ユーザに対する個々のポータルのメニユー構造を調節して、それらのプロファイルの嗜好を考慮する。すなわち、ユーザが所定のページをリクエストしたとき、個人化エンジンは、学習された情報を有するページのデフォルト構造についての情報をユーザの嗜好およびそれらのカスタム化についての情報と組合わせることによりダイナミックにそのページに対する１組の最良のリンクを選択する。

個人化エンジンは、ユーザが以前のブラウジング特性に基づいて次に進ことを望んでいる可能性のあるユーザの嗜好を予測するための特有のアルゴリズムによってユーザの性質を記憶し、追跡するための新しいおよび効率のよい方法を組合わせる。

基本的なプロファイルデータ構造はヒットテーブルであり、その１例は図７乃至１０に示されている。それについて以下詳細に説明する。ヒットテーブルは子ノード（メニューページまたはリンクページ）に対する親ノード（メニューページ）と、各子ノードがユーザにより選択される回数に関係している。例えば、図９の右側において、メニューページＡは２０回アクセスされ、ＡからページＢへのリンクは１７回アクセスされ、ＢからＥのリンクへは３回アクセスされ、以下同様であることが認められる。

事実、この実施形態は２つのテーブルを使用している。すなわち、デフォルトポータル構造に関連して初期化されるスタティックヒットテーブルと、ポータルにおけるユーザの特定の履歴を記録しているユーザヒットテーブルである。前者は図７乃至１０のそれぞれにおいて左側に示されており、後者は右側に示されている。

スタティックテーブルはポータルオペレータ／設計者によって特定されたポータル構造を反映するためにメニュー管理装置によって規定される。それはポータルが早期の標準的なメニュー構造を配送することを許容するが、これはユーザの履歴が生成されると個人化されたメニューにより無効にされる。スタティックヒットテーブルに設定されているヒット値は個人化の潜伏を制御することが可能である。すなわち、低い値は個人化が非常に迅速に反応し、一方、大きい値はユーザアクティビティに対してシステムを鈍感にする。実効的にスタティックヒットテーブルは最初の時期の新しいユーザに対する仮定されたアクセス履歴である。ユーザがポータルをブラウズするとき、彼の選択はユーザヒットテーブルを更新するために使用され、それは彼のプロファイルの一部として記憶される。

サイトのオペレータによって課される何らかの制約（例えば、最大リンク、ヒットしきい値、格上げなし等）、またはユーザによって課される何らかの制約（例えば、カスタマイズ不可能なページ）を条件とし、ユーザがそのメニューページ情報から到達することを望んでいるｋ個の最も可能性の高いリンクを、すなわち、スタティックテーブルおよびユーザヒットテーブル中の現在の値に基づいたＰ（ｎ／ｍ）に対する最高の値を有するｋ個のページを、個人化エンジン14は、自動的に識別し、選択されたメニューページｍに対するメニューオプションとして提供する。記号Ｐ（ｎ／ｍ）は現在メニューｍ中にある所定のユーザにより最終的に選択されるべきｎのリンクの確率を示している。これはダイナミックに、すなわち、ユーザがそのメニューページを選択して予め計算されていないとき、実時間で行われる。したがってユーザの以前のブラウジング履歴に基づいて予め全体のメニュー構造を計算するために個人化エンジンは必要なく、関係するメニューページ選択するときにユーザがビジットすることを望むメニューの部分を計算するだけでよい。

ユーザが新しいメニューｍを選択するとき、個人化エンジンはｍからｋ個の最も可能性の高いリンクの位置を決定し、これらを使用してｍを構成する。これらのｋ個の最も可能性の高いリンクはそれらのブラウジング履歴にしたがって異なるユーザに対して異なっている。典型的に、ｋ個のリンクのいくつかはポータルオペレータによりｍからのリンクとして特定されているが、他のものは低いレベルから格上げされる。ｋ個の最も可能性の高いリンクを計算するために個人化エンジンはスタティックおよびユーザヒットテーブルを使用することによって過去におけるｍの子孫として現れる各リンクに対してＰ（ｎ／ｍ）を計算する。

Ｘ１はＸ２の子（すなわちＸ１はＸ２中にリンクされている）であるＰ（Ｘ１／Ｘ２）を計算するために、Ｘ２の子（スタティックおよびユーザヒットテーブルの合計）として受信されたヒットＸ１の数を受信されたヒットＸ２で割算する。

一般的に、Ｐ（Ｘ１／Ｘ２）を計算しようとするならば、ここでＸ１とＸ２は親と子の関係（Ｘ１，Ｘ２，…Ｘｎ）にしたがって接続されており、そのためＸ２はＸ１の親であり、Ｘ３はＸ２の親であり、いか同様の関係であり、次式で表される。
Ｐ（Ｘ１／Ｘｎ）＝Ｐ（Ｘ１／Ｘ２）×Ｐ（Ｘ２／Ｘ３）×…×Ｐ（Ｘn-1 ／Ｘn ）
さらに、Ｘ１もまたＸ３，…Ｘn の１つの子として発生するものと予想して同じ方法によりＰ（Ｘ１／Ｘｐ）を計算する。その場合に、ＸｐはＸ３，…Ｘn の１つであり、それらは子としてＸ１を有し、これらの確率を加算して全体の確率Ｐ（Ｘ１／Ｘｎ）を計算する。 各子ノードの確率は通常の方法で計算することができ、明瞭な方法でレベルごとに確率をキャリする（子が親になるように）。

重要なことは、このプロセスの終了するときを知ることである。理論的には、アルゴリズムがｍの子孫として現れる都度各ノードを検査しなければならないメニューｍに対してｋ個の最も可能性の高いリンクを正確に識別するようにできる。これは大きいメニュー構造では非常に高価なものとなるであろう。しかしながら、以下説明するような観察に基づいてもっと効率のよい技術が可能である。すなわち、ｎの全ての子に対して、
Ｐ（ｎ／ｍ）≧Ｐ（子（ｎ）／ｍ）
すなわち、ノードｎの子は、ノードｍに関してｎという子よりも低い確率を常に有する。特定のレベルにおけるリンクと関連する確率を計算するとき、それまでに発見したｋ番目の最良の確率よりも大きい確率が得られるリンクを介して次のレベルへ進むことだけが必要である。

これは、メニューｍに対してｋ個の最も可能性の高いノードを発見し、ｍにおいて根付いたメニューツリー上で深さの限定された幅の第１の検索によりユーザｕを発見することができる。ヒットテーブルは検索を行うために必要とされるツリー構造の情報を提供する。すなわち：
子（ｍ）＝スタティックヒットテーブル（ｍ）Ｕユーザヒットテーブル（ｍ，Ｕ）
スタティックヒットテーブル（ｍ）がそのスタティックヒットテーブル中のｍより下のインデックスされたノードを意味し、ユーザヒットテーブルがユーザｕに対するユーザヒットテーブル中のｍより下のインデックスされたノードを意味する。

以下の例は、単一のメニュー構造に関して時間にわたって個人化の進歩がどのように表示されるかにより詳細に個人化プロセスを示している。ここでヒットしきい値を３と仮定し、各メニューページはただ２つのリンクを含むように構成されると仮定する。

１．新しいユーザ
図７は最初の時期のユーザに対する状態を示している。ユーザヒットテーブルはノード（ページ）がどれもクリックされないために空である。
最初の時期のユーザに対してメニューページＡの構成を考える。ヒットテーブルは２つの直接の子供ＢとＣがノードＡに対して存在することを示す。
Ｐ（Ｂ／Ａ）＝（20＋0)／（40＋0)＝20／40＝0.5
Ｐ（Ｃ／Ａ）＝（20＋0)／（40＋0)＝20／40＝0.5
この点においてさらに処理する必要はない。その理由はＢもＣもしきい値３に到達しないからである（それらのユーザヒットテーブルのエントリーはそれぞれの場合に０のヒット値を示している空である）。したがって、リンクＢおよびＣはメニューページＡ中で使用され、それらの確率にしたがった順序で整列される（等しい確率の場合には、順序はスタティックヒットテーブル中のヒット値を基準にして計算される）。

２．非常に早期の段階のユーザ
図８に示されている状態について考慮する。同じユーザは非常に短い時間に対してはポータルを使用しており、したがって何らかのユーザヒット値が生成される。再びメニューページＡの構成について検討する。Ａに関するＢとＣに対する確率を計算する時、次の式が発見される。：
Ｐ（Ｂ／Ａ）＝（20＋3)／（40＋5)＝23／45＝0.511
Ｐ（Ｃ／Ａ）＝（20＋2)／（40＋5)＝22／45＝0.488
この点において、Ｂは３つのユーザヒットを受取りヒットしきい値を得る。さらに、各メニューページに対して２つのリンクを識別するために探すから、それまでに発見した第２の最良のノード確率よりも大きい確率の拡張されたノードだけを必要とする。これは定義により、子供またはメニューｍ中のメニューオプションｎの子孫リンクでｎよりも高い確率を有するものは何もないからである。この場合には、それまでに発見した第２の最良のノード確率は0.488 である。Ｂの確率はそれより大きい(0.511) から、また、Ｂはそのヒットしきい値に到達しているから、その子供の確率を計算するためにＢを拡張する必要がある。しかしながら、Ｂの子供でヒットしきい値を得ているものはないから、それらは格上げに利用されることはできない。したがってリンクＢおよびＣは再びメニューＡ中に存在し、Ｂはその確率が高いためにＣの前に現れる。

３．早期の段階のユーザ
図９は依然として非常に早い段階のユーザに対する状態を示しているが、個人化効果の発見を開始するために充分に使用情報が収集されている。

再びメニューページＡの構成を検討する。Ａに関するＢとＣに対する確率を計算して以下の式が得られる。：
Ｐ（Ｂ／Ａ）＝（20＋17) ／（40＋20) ＝37／60＝0.616
Ｐ（Ｃ／Ａ）＝（20＋3)／（40＋20) ＝23／60＝0.383
この点において、ＢとＣの両者共にヒットしきい値を得ている。メニューページＡに対する２つのリンクについて検討しているから、それまでに発見された第２に高い確率（Ｃに対する確率は0.383 である）の値を越えた確率を有している拡張されたノードが必要である。それ故、拡張されたノードＢ（その確率は0.616 である）だけが必要である。

Ｂを拡張するためにＡに関するその子供の確率を計算する。：
Ｐ（Ｄ／Ａ）＝Ｐ（Ｄ／Ｂ）×Ｐ（Ｂ／Ａ）＝（10＋14) ／（20＋17) ×0.616
＝24／37(0.616) ＝0.399
Ｐ（Ｅ／Ａ）＝Ｐ（Ｅ／Ｂ）×Ｐ（Ｂ／Ａ）＝（10＋3)／（20＋17)
＝13／37(0.616) ＝0.216
この点においてノードＤの確率はノードＣを追越して２つのノード全体のトップになることが発見される。したがって、この段階では、ＢおよびＤに対するリンクからなるメニューページＡを構成し、したがってＤはメニューＢからメニューＡに格上げされ、再びＢが最初に与えられ、Ｄが２番目に与えられる。

この段階では、どのノードが実際に選択され、メニューＡでユーザに与えられるか指令することができるさらに別のルールに注意することは価値がある。例えばネットワークオペレータはユーザがこれらのメニューオプションに対するアクセスを失うことを恐れるためにスタティックノードを抹消することを望まない可能性がある。これは後処理作業と見ることができ、個人化装置の動作には影響はなく、したがってここでは説明しない。

４．メニューユーザ
最後に、格上げが時間にわたって行われ、ユーザにより行われる場合の成熟したユーザに対する状況で説明する。図１０は、ユーザがＤからメニューＡへ格上げされることにより利益を受け、ユーザヒットテーブルに示されているようにその格上げされた位置において５回このリンクをクリックする状態を示している。図７乃至１０において、ユーザヒットテーブルはユーザアクティビティの単なる記録であり、それは関係する時間における実際のメニュー構造を表すものではない。例えば、図１０では、メニューページＡは３つのエントリ、Ｂ，Ｄ，Ｃを有することが示されているので、ユーザヒットテーブルを解釈するように唆す可能性がある。これはその場合ではない。

図１０でメニューＡを計算すると、以下のようなＡの子供に対する確率が得られる（この場合にＤはＡの可能な子供である）。
Ｐ（Ｂ／Ａ）＝（20＋17) ／（40＋25) ＝37／65＝0.569
Ｐ（Ｃ／Ａ）＝（20＋3)／（40＋25) ＝23／65＝0.353
Ｐ（Ｄ／Ａ）＝（0 ＋5)／（40＋25) ＝5 ／65＝0.076
Ｂはさらに拡張される。その理由はそれがそれまでに発見された最悪の許容可能な確率（Ｃに対する確率0.353 ）を越えるノードであるからである。

Ｂの拡張のために、Ａに関するその子供の確率を計算する。

Ｐ（Ｄ／Ａ）＝Ｐ（Ｄ／Ｂ）×Ｐ（Ｂ／Ａ）＋0.076
＝（10＋14) ／（20＋17) ×0.569 ＋0.076
＝24／37(0.569) ＋0.076 ＝0.444
Ｐ（Ｅ／Ａ）＝Ｐ（Ｅ／Ｂ）×Ｐ（Ｂ／Ａ）
＝（10＋3)／（20＋17) ×0.569
＝13／37（0.569 ) ＝0.199
ここで注意すべき重要なことは、ノードＤの確率の計算において、適当な確率を追加することによりＢ（そのスタティックな親）に対する確率およびＡ（その格上げされた親）に対する確率を考慮することである。

一般的に、ノードは時間の推移と共に格上げおよび格下げされるので、ユーザヒットテーブル中に多数のエントリを発生させ、確率の計算において、その多数の原形のエントリにわたって所定のノードに対する確率の合計を取り、原形により、我々の現在の計算点よりもメニュー構造で高い位置に現れるノードのエントリのみ確率を合計する。したがって、Ａに関するＤ（Ａにおける）に対する確率を計算するとき、Ｂに関するＤに対する第２のエントリを考慮することはない。それはＢがＡより低いからである。しかしながら、Ａに関するＤ（Ｂにおいて）の確率を計算するときには、両方の確率を考慮する。

それ故、それまでに発見された最良の２つの確率は0.589 と0.444 であり、それはそれぞれノードＢおよびＤに対応している。再びこれらのノードがメニューＡに対して、それらの確率にしたがった順序で選択されることができる。

以上の説明は非常に簡単なメニュー構造についてのみ記載したが、本発明は時間にわたって確率が構築されるとき、多数のレベルによって格上げが発生する多数のレベルおよびページを有するメニュー構造に適用可能である。一般的なアルゴリズムは付録Ａに記載されている。

コピー格上げ方式に上記アルゴリズムデフォルトを置くとき、メニューＢからメニューＡへノードＤを格上げすることは、ユーザがそれらがＣを選択したときにはＢ中のＤを観察しないことを意味するものではない。

図１０に示された例について検討すると、この場合にはメニューＡはＤおよびＢとのリンクを有して表示される。ユーザがメニューＢ（Ｄのもとの親）を選択したと考える。移動格上げ方式では、ＤがＢからの上位ｋ個のノードにある場合であっても、それは表示されてはならない。その理由はもとのメニュー（この場合には親のメニューであるが、祖父のメニュー等であってもよいことは容易に考えられる）においてユーザによってすでに観察されているからである。

移動格上げ方式を実行しようとする場合には、そのセッション中の格上げ、格下げを追跡するためにセッションごとのベースで２つの新しいテーブルを必要とする。音響は複雑であるが、実際には非常に簡単である。１つのテーブルは親と子の関係（およびユーザヒットテーブルのより簡単なバージョン）を管理する。他方のテーブルは反対に子と親の関係を捕捉する。各セッション中に、各個人化されたメニューに対して選択されたノードにしたがってこれらのテーブルを構築する。

再び図１０に示された例について検討し、ユーザが２つのリンクＤおよびＢを有するメニューＡをアクセスしたと想定する。ユーザの現在の子と親および親と子のテーブルは図１１に示された情報を含んでいる。

メニューＢを形成しようとするときには、所定のノードがノードツリーを反復的に逆行させ、それに続いて子と親のテーブルから子と親の関係を求め、それから親と子のテーブルから各レベルにおける子供をチェックすることにより、原形のメニュー中ですでに見られているか否かをテストすることができる。

例えば、最初に、Ｂの親にしたがう（もしも多数の親が存在する場合には、最も最近の親が親と子のテーブルの最初にリストされるように配置する）。ｎがこの親の子供のエレメントであるか否か（親と子のテーブルを使用することにより）を検査する。線形の深さを有する対数的な大きいメニューツリーであっても、これは特に廉価な動作である。それは単一のユーザセッションはメニュー構造の小部分に焦点をしぼる可能性があるからである。

上記の実施例の種々の変形および改良が可能である。例えば、確率計算にしたがってトップのｋページにある場合であっても、その確率があるしきい値、例えば0.4 を越えた場合にのみページが格上げされることを特定することが可能である。

また感度属性をノードに与えることもできる。ノードの感度は個人化される感度の程度を示す。低い感度値は個人化に対して比較的鈍感であり、したがって移動は遅い。高い感度値ではその反対である。これは、所定のノードが選択されるときのインクリメントとしてこの感度値を使用することによって実際に制御される。例えば、あるノードが値３の感度を有するならば、選択される都度、ヒットテーブル中の適当なエントリ中の現在の合計に３が追加される。この方式の有する１つの複雑さは、潜在的に親ノードのヒット値がもはやその子供のヒット値の合計ではない（もしも子供が親とは異なった感度値を有するならば）ことである。この理由で、子ノードのヒット値が親ノードのヒット値に等しいことを確実にするための簡単な正規化プロセスが使用される。簡単に説明すると、親ノードのヒット値は実際の子ノードのヒット値の比率にしたがって分配される。感度値はノードの確率を加重する本質的な方法である。

要約すると、本発明の実施形態は、ユーザが個人化された情報サービスを開発し展開することを可能にするアプリケーションを含み、すなわち、情報サービスはオンライン特性パターンに基づいて個々のユーザの必要性を自動的に修正する。構成されたポータルは、個々のオンラインユーザのナビゲーション嗜好およびこれらのユーザに対するより効率的で好ましい移動経験の究極的な分配のナビゲーション嗜好を自動的に修正することを可能にする。この実施形態は、短い“クリック距離”からそれらの好ましいコンテンツへの利点をユーザに提供する。

この実施形態は、ユーザの可能性のある（および共通の）情報を必要とする事前の予測のために個々のユーザのアクセスパターンにＷＡＰポータルをダイナミックに修正することを許容して、それによりＷＡＰポータルメニュー構造内のよりアクセス可能な位置に情報ターゲットを格上げすることによってこれらの効果を提供する。

図１２を参照すると、本発明の第２の実施形態は、上述した第１の実施形態の個人化された機能性を有しているが、さらに、ここで姻戚推薦技術と呼ばれているものに基づいた別の機能が追加されている。簡単にするために、図１２ではカスタム化エンジン16はメニューサーバ12では省略されており、またメニュー管理装置10、ブラウジングクライアント20、カスタム化クライアント24も同様である。しかしながら、それらは全て存在し、前述のように動作する。第１の実施形態と比較して図１２の実施形態は姻戚推薦エンジン40を備えており、それは以下説明するように動作する。

姻戚推薦技術によれば、メニューオプションは、それらがユーザの同じセットから共に多数のクリックを受取った場合には互いに匹敵するものとして認識される。この概念は、ユーザの同じセットが両方のメニューオプションに関心がある場合には、そのメニューオプションは同様の方法で個々のユーザに関係する可能性のあると言うことである。必要な概念的類似性がないメニューオプション間の類似性の合同した複雑なフィルタ技術とは異なる。例えば、姻戚推薦技術は技術的に新しいメニューオプションとＴＶ聴視メニューオプションの間の高い類似性を、それらが導かれるコンテンツに直接の類似性がなくても識別することができる。この類似性の値は技術ニュースを見るユーザのグループはまたＴＶを聴視することを意味しており、それ故それらは共にこれらのトピックスに同様の関心を有する。

姻戚推薦エンジン40はユーザナビゲーションパターンに基づいて動作する。本質的にこのナビゲーションは移動体ポータルにおけるメニューオプションを横切って発生し、ユーザのナビゲーションパターンはメニューオプションを共に集めるために使用される。

姻戚推薦技術の第１のステップは、どのユーザがメニューオプションのそれぞれについてクリックしたかを記録することである。これはユーザヒットテーブルを通して最初のパスを行い、メニューオプションによってキー入力された反転インデックスを構築することにより行われる。これらの各メニューオプションは関連するプロファイルのリストを有し、それはこれらのメニューオプションとそれらが所有者のプロファイルによりクリックされた回数を含んでいる。ユーザの数が増加するにつれて、この反転インデックスをメモリ中に記憶することが実行不可能になる。それ故、反転インデックス中の各エントリは別々のファイルに記憶される。各メニューオプションに対して、プロファイルの名称とプロファイルの所有者によりクリックされた回数を含んでいるファイル中の各ラインを有するファイルが生成される。

例えば、メニューオプションＭ1 に対するファイルは図１３に示されるデータを含むことができ、それはユーザ１がＭ１を１０回クリックし、ユーザ６がＭ１を５０回クリックし、以下同様に行われることを意味している。これらのファイルの数およびサイズを減少させるために、以下のようなしきい値が使用される。：
ヒットしきい値−Ｍ１のようなメニューオプションに対するファイルを形成するとき、ヒットしきい値に合致する、またはヒットしきい値を越えるクリック値のユーザだけを含む。ヒットしきい値は、ユーザのプロファイルがこれらのメニューオプションに対する姻戚値を計算するために有用であると考えられる前に、ユーザからメニューオプションが受信されなければならないたクリックの数についての下限を表している予め定められた数である。

ユーザしきい値−メニューオプションに関連するファイルに付加されるユーザの数がユーザしきい値を越えた場合にファイルへのユーザの追加を停止する。これらのファイルは全部除去されてもよく、それによりそれらは姻戚推薦とは関係がなくなる。それらを除去する理由は、メニューオプションが非常に普通のものであり、そのため、それはすでに多くのユーザの個人化されたメニュー構造で高くされているので姻戚推薦プロセスに付加的な利益を与える可能性がないからである。

反転インデックスファイルを更新するとき、前の更新以来アクセスされたユーザプロファイル内のヒットテーブルだけが検査される。プロファイルがアクセスされていないならば、そのプロファイルにおけるヒットテーブルに関連したクリックの数は変更されない。その結果プロファイルは更新されたファイルに影響を与えない。

他のメニューオプションに類似しているメニューオプションを推薦するために、メニューオプション間の類似性を計算する方法が必要である。これはメニューオプションに対するプロファイルの関係を使用する。図１４の２つのメニューオプションＭ１とＭ２との間の類似性について考える。Ｍ１はユーザ１，ユーザ３，ユーザ５，ユーザ１０，ユーザ１１によりクリックされ、Ｍ２はユーザ１，ユーザ４，ユーザ５，ユーザ１１，ユーザ２０によりクリックされている。Ｍ１とＭ２との間の類似性を計算するために、両者を共にクリックしているユーザ（すなわちユーザ１，ユーザ５，ユーザ１１）による各メニューオプションに対して与えられるヒット数だけが考える必要がある。

Ｍ１とＭ２との間の類似性は−１と＋１の間で値を反復するピアソンの補正係数を使用して計算することができる。値が高くなるほどメニューの類似性は増加し反対の場合も同じ傾向である。以下の例は図１４のＭ１とＭ２との間の類似性の計算を示している。結果的に得られた類似性は0.266 であり、それはメニューがあまり類似していないことを示唆している。

ピアソンの補正係数

上記の例について考えると、類似性は次のように計算される。式中のＸの値はすでにメニューオプションＭ１に関連するものに割当てられ、Ｙの値はメニューオプションＭ２に関連するものに割当てられる。ステップ・バイ・ステップで処理が行われる。

類似性は0.266 である。

メニューオプション間の類似性を計算するとき“オーバラップしきい値”が必要とされる。このしきい値は、ピアソンの補正係数（または任意の他の類似性技術）がメニューオプション間の類似性を測定するために使用されることができる前に、両方のメニューオプションにクリックする必要のあるユーザの最小値を表している。このしきい値よりも低い任意の数はメニューオプションが類似性がないことを示唆しており、したがって非常に僅かのユーザしか両方のメニューオプションに対して選択されない。

上記の例ではピアソンの補正係数がメニューオプション間の類似性を計算するために使用されている。しかしながら、これは類似性を計算するための可能な技術の１つに過ぎない。任意のよく規定された類似性の測定方法がメニューオプション間の類似性を測定するために使用されることができる。

姻戚推薦エンジン40はメニューオプション間の関係（すなわち姻戚関係）を維持するために使用される姻戚ファイルを構成する。各メニューオプションに対して姻戚ファイルが存在し、それは他のメニューオプションのリストおよびそれらと姻戚ファイルの所有者との間の関係を含んでいる。例えばＭ１に対する姻戚ファイルの内容は図１６に示され、それはＭ１とＭ２が0.266 の類似性値を有すること等を意味している。

インデックスファイルにより、姻戚ファイルのサイズは種々の方法で制限されることができる。

１．パートナー：姻戚ファイル中に含まれるメニューオプションのパートナーだけを考慮する。特定のメニューオプションのパートナーを選択する種々の方法がある。例えば図１７を参照すると、メニューオプションＢのパートナーは、
・メニューオプションの子孫（Ｄ，Ｅ，Ｈ，Ｉ）
・メニュー構造中のメニューオプションの子孫（Ｄ，Ｅ，Ｈ，Ｉ）を除く全てのノード
・メニューオプションの兄弟（ｃ）および子孫（Ｄ，Ｅ，Ｈ，Ｉ）
・リーフノード（すなわち外部コンテンツプロバイダに対するリンク）および子孫でないメニュー（Ｆ，Ｊ，Ｋ）である全てのメニューオプション。これはメニュー構造の他の区域からのリーフノードだけがメニューオプションと共に推薦されることを確実にする。これらはユーザが関心があるが、以前には見ていないメニューオプションである可能性があり、ユーザの現在のメニューオプションに類似しているために推薦される。

・メニュー構造中の他の全てのメニューオプション
・メニュー構造中の任意のノードの組合わせ
以上において、パートナーが選択されるメニュー構造はもちろんユーザに対するデフォルトメニュー構造である。何故ならば、個人化されたメニューはユーザがそれにクリックするときのみダイナミックに構成されるからである。しかしながら姻戚推薦技術は依存されないで、第１の実施形態に関連して記載された個人化技術と無関係に使用され、その場合にパートナーが決定されるメニュー構造はサイトのメニュー構造である。

２．姻戚関係しきい値：あるしきい値、すなわち姻戚関係しきい値より上り類似性の値を有するメニューオプションだけを含んでいる。この理由は、メニューオプションと共に推薦されることのできるメニューオプションに充分に類似しているメニューオプションだけが確実に得られるからである。

姻戚推薦は任意のメニュー構造と組合わされてて個人化された推薦を提供する。任意のメニューオプションに対して、充分に類似している（すなわち, 特定の姻戚関係しきい値より上である）任意の他のメニューオプションを推薦する潜在性が存在する。この実施形態のように、姻戚推薦が確率モデルを使用して構成されたメニューオプションと組合わされたとき、最も簡単な方法は個人化されたメニュー（確率モデルに基づいて）を構成し、それから図１８に示されているように個人化された姻戚推薦の別のリストを含めることである。なお、図１８で、Ｍ＝確率モデルに基づいたメニューオプションであり、Ａ＝姻戚推薦ある。

サイトオペレータは推薦の数を予め定めることができる。個人化された姻戚推薦のリストを生成するために姻戚関係ソースが識別される。姻戚関係ソースは姻戚推薦の生成に使用されるメニューまたはメニューのリストである。姻戚推薦スコアもまた使用され、それは姻戚推薦として現れるメニューオプションの尤度を表している。このスコアは単にメニューオプションと関係する姻戚関係値または確率および姻戚関係値のある組合わせであってもよい。以下、メニューページに現れるために姻戚推薦を選択するための多くの技術について説明する。

３つのメニューオプション，Ｍ１，Ｍ２，Ｍ３を有するメニューページＭについて検討する。作業はＭ上に現れるｋ個の姻戚推薦のリストを生成することである。以下の説明は姻戚推薦を選択するために使用されることのできる多数の技術を示している。すなわち、ＡおよびＢは姻戚推薦スコアとして姻戚関係値を使用する。

Ａ．姻戚関係ソースとしてのＭの使用
最も簡単な方法は姻戚推薦に対するソースとしてＭを使用するものである。メニューページＭに対する姻戚関係のリストは姻戚関係値の減少する順序で並べられ、上位ｋ個の姻戚関係に関連するメニューオプションが姻戚推薦として使用される。

Ｂ．姻戚関係ソースとしてのＭ１，Ｍ２，Ｍ３の使用
この方法によれば、Ｍ１，Ｍ２，Ｍ３に対する上位ｋ個の姻戚関係が組合わされる。この姻戚関係の組合せは次に姻戚関係値にもとづいた順序で並べられ、上位ｋ個が姻戚推薦として選択される。

ユニオン［姻戚関係（Ｍ１，Ｍ２，Ｍ３）＝（Ａ₁ ^M1…Ａ_k ^M1，Ａ₁ ^M2…Ａ_k ^M2，Ａ₁ ^M3…Ａ_k ^M3）］
ここで、Ａ₁ ^M1はＭ１に関する最高の姻戚関係を有するメニューであり、以下同様である。
姻戚推薦＝最高の姻戚関係を有する上記セットからの上位ｋ個のメニューオプション
である。

Ｃ．姻戚関係ソースとしてＭ１，Ｍ２，Ｍ３を使用するが姻戚推薦スコアを変化する
この方法は、上位ｋ個の姻戚推薦を選択するとき、姻戚関係ソースからの確率情報を含むことを除いては上記（Ｂ）と類似している。Ｍ１，Ｍ２，Ｍ３と関連している上位ｋ個の姻戚関係のそれぞれに対して、姻戚推薦スコアは次の式を使用して計算される。
スコア（Ａ₁ ^M1）＝確率（Ｍ１）＊
姻戚関係（Ａ₁ ^M1，Ｍ１）
ここで、確率（Ｍ１）はメニューページＭに現れるＭ１の確率（確率モデルに基づく）である。姻戚関係（Ａ₁ ^M1，Ｍ１）はＭ１と姻戚推薦Ａ₁ ^M1との間の姻戚関係である。

可能な姻戚関係は姻戚関係スコアの減少する順序で並べられ、その上位ｋ個が姻戚推薦として使用される。上記の式において、スコアは確率と姻戚関係値との積に基づいていることに注意する必要がある。その他の組合わせがスコアの計算に使用されてもよい。

Ｄ．Ｍ１，Ｍ２，Ｍ３の種々の組合わせの使用
上記のＢおよびＣで記載された技術は、次のようにＭ１，Ｍ２，Ｍ３の種々の組合わせで使用されることができる。

＊デフォルトメニューページＭの一部であるＭ１乃至Ｍ３からのメニューオプション
＊デフォルトメニューページＭの一部ではないが、確率モデルを使用するメニューページＭに格上げされているＭ１乃至Ｍ３からのメニューオプション
＊ダイナミックなメニューページＭの一部ではないが、ユーザによってメニューページにＭにカスタム化されているＭ１乃至Ｍ３からのメニューオプション。

方法Ａを使用して、または姻戚関係ソースとしてデフォルトメニューを使用して選択された姻戚推薦は全てのユーザに対して同じであることに注意しなければならない。しかしながら、特定のメニューページＭに現れる姻戚推薦を記述する他の技術により個人化されて、そのため推薦として選択されたメニューオプションは人から人へ変化してもよい。

それ故、最終結果として図１２の個人化されたメニュー42が得られ、それは確率計算により生成された個人化されたメニュー構造44からなり、さらに姻戚推薦46がそれに追加されている。

本発明はここに記載された実施形態に限定されるものではなく、本願発明の技術的範囲から逸脱することなく変形、変更されることが可能である。

付録Ａ

（ａ）乃至（ｅ）は従来技術によるＷＡＰ電話における情報の同じアイテムにアクセスするために必要なユーザの動作シーケンスの説明図。 （ａ）および（ｂ）は本発明を実施するＷＡＰポータルからのＷＡＰ電話における情報の同じアイテムにアクセスするため必要なユーザの動作シーケンスの説明図。 ＷＡＰポータルに含まれる本発明の第１の実施形態のシステムアーキテクチャのブロック図。 図３のメニュー管理装置に対するクラフィカルユーザインターフェース（ＧＵＩ）のスクリーンを示す図。 個人化された新しいページを生成し構成するためのメニュー管理装置の使用を表示したスクリーンを示す図。 図３のカスタム化エンジンの使用を表示したスクリーンを示す図。 簡単なメニュー構造に対する個人化エンジンの動作の説明図。 簡単なメニュー構造に対する個人化エンジンの動作の説明図。 簡単なメニュー構造に対する個人化エンジンの動作の説明図。 簡単なメニュー構造に対する個人化エンジンの動作の説明図。 子供と親および親と子供のテーブルを示す図。 本発明の第２の実施形態のブロック図。 本発明の第２の実施形態の動作を説明するテーブルを示す図。 本発明の第２の実施形態の動作を説明するテーブルを示す図。 本発明の第２の実施形態の動作を説明するテーブルを示す図。 本発明の第２の実施形態の動作を説明するテーブルを示す図。 本発明の第２の実施形態の動作を説明するテーブルを示す図。 本発明の第２の実施形態の動作を説明するテーブルを示す図。

Claims (12)

1. ユーザに階層メニュー構造を提供するインターネットウェブサイトコンピュータシステムにおいて、
   前記サイトはデフォルトメニュー構造と、前記サイトにおける各ユーザの以前のブラウジング履歴に少なくともしたがって前記各ユーザに対するデフォルトメニュー構造を時間の経過と共に自動的に修正する手段を有し、
   前記修正する手段は、前記サイトのオペレータまたは前記ユーザによって課される制約を条件とし、前記ユーザが選択されたメニューページｍから到達することを望んでいるｋ個の最も可能性の高いリンクを、前記選択されたメニューページｍに対するメニューオプションとして、上位の階層へ移動することにより、前記ユーザが前記メニューページｍを選択するときに前記メニュー構造の選択されたメニューページｍ上に現れる前記メニューオプションをダイナミックに決定し、
   前記ｋ個の最も可能性の高いリンクは、最も最近のメニュー構造における前記メニューページｍの直接的または間接的な階層の子孫であったリンクが選択される確率を前記履歴に基づいて計算することにより識別され、
   前記計算は、前記メニューページｍから派生している前記最も最近のメニュー構造の各分岐に対して、現在のリンクが選択される確率が、それまでに発見されたｋ番目に最良の確率よりも小さくなるまで、順次、前記分岐中のより下位のレベルにおいて、リンクが選択される確率を計算することにより実行されるインターネットウェブサイトコンピュータシステム。
2. 前記リンクが選択される確率は加重される請求項１記載のインターネットウェブサイトコンピュータシステム。
3. さらに、選択されたメニューページに対するメニューオプションとして、ユーザの指定したリンクを提供する手段を備えている請求項１記載のインターネットウェブサイトコンピュータシステム。
4. さらに、リンクが前記デフォルトメニュー構造内で上位の階層へ移動されることのできるメニューレベルの数を制限する手段を備えている請求項１記載のインターネットウェブサイトコンピュータシステム。
5. さらに、上位の階層へ移動されるリンクが、前記選択されたメニューページにコピーされるかまたは移動されるかを選択する手段を備えている請求項１記載のインターネットウェブサイトコンピュータシステム。
6. 前記修正する手段は、特定のメニューページに対する少なくとも１つの付加的なメニューオプションとして、予め定められた類似性決定により決定される、前記類似性決定以外により前記特定のメニューページ上に与えられる少なくとも１つのメニューオプションに類似している少なくとも１つのリンクを提供する手段を備え、前記類似性決定は、前記各ユーザと他のユーザとのブラウジング履歴の関数である請求項１記載のインターネットウェブサイトコンピュータシステム。
7. ２つのメニューオプションの間の類似性は、両者を選択したユーザにより各メニューオプションが選択された回数の関数の関数として決定される請求項６記載のインターネットウェブサイトコンピュータシステム。
8. 特定のメニューオプションのユーザの選択は、ユーザがそのメニューオプションを選択した回数が予め定められたしきい値に到達した場合にのみ前記類似性決定において考慮される請求項７記載のインターネットウェブサイトコンピュータシステム。
9. メニューオプションを選択するユーザの数が予め定められたしきい値を超える場合、前記メニューオプションは追加的なメニューオプションとしての提供を考慮されない請求項７記載のインターネットウェブサイトコンピュータシステム。
10. 前記類似性決定は、各メニューオプションが予め定められた最小数のユーザにより選択された場合にのみ２つのメニューオプションについて行われる請求項７記載のインターネットウェブサイトコンピュータシステム。
11. ユーザに階層メニュー構造を提供するインターネットウェブサイトを動作させる方法において、
    前記方法は、前記サイトにおける各ユーザの以前のブラウジング履歴に少なくともしたがって前記各ユーザに対するデフォルトメニュー構造を時間の経過と共に自動的に修正するステップを含み、
    前記修正するステップは、前記サイトのオペレータまたは前記ユーザによって課される制約を条件とし、前記ユーザが選択されたメニューページｍから到達することを望んでいるｋ個の最も可能性の高いリンクを、前記選択されたメニューページｍに対するメニューオプションとして、上位の階層へ移動することにより、前記ユーザが前記メニューページｍを選択するときに前記メニュー構造の選択されたメニューページｍ上に現れる前記メニューオプションをダイナミックに決定し、
    前記ｋ個の最も可能性の高いリンクは、最も最近のメニュー構造における前記メニューページｍの直接的または間接的な階層の子孫であったリンクが選択される確率を前記履歴に基づいて計算することにより識別され、
    前記計算は、前記メニューページｍから派生している前記最も最近のメニュー構造の各分岐に対して、現在のリンクが選択される確率が、それまでに発見されたｋ番目に最良の確率よりも小さくなるまで、順次、前記分岐中のより下位のレベルにおいて、リンクが選択される確率を計算することにより実行される方法。
12. ユーザに階層メニュー構造を提供するインターネットウェブサイトにおいて使用するためのコンピュータ読み取り可能媒体上に存在するコンピュータ実行可能プログラムコードにおいて、
    前記プログラムコードは、前記サイトにおける各ユーザの以前のブラウジング履歴に少なくともしたがって前記各ユーザに対するデフォルトメニュー構造を時間の経過と共に自動的に修正し、
    前記自動的な修正は、前記サイトのオペレータまたは前記ユーザによって課される制約を条件とし、前記ユーザが選択されたメニューページｍから到達することを望んでいるｋ個の最も可能性の高いリンクを、前記選択されたメニューページｍに対するメニューオプションとして、上位の階層へ移動することにより、前記ユーザが前記メニューページｍを選択するときに前記メニュー構造の選択されたメニューページｍ上に現れる前記メニューオプションをダイナミックに決定し、
    前記ｋ個の最も可能性の高いリンクは、最も最近のメニュー構造における前記メニューページｍの直接的または間接的な階層の子孫であったリンクが選択される確率を前記履歴に基づいて計算することにより識別され、
    前記計算は、前記メニューページｍから派生している前記最も最近のメニュー構造の各分岐に対して、現在のリンクが選択される確率が、それまでに発見されたｋ番目に最良の確率よりも小さくなるまで、順次、前記分岐中のより下位のレベルにおいてリンクが選択される確率を計算することにより実行されるコンピュータ実行可能プログラムコード。

Images