(57)【要約】      （修正有）【課題】広告、電子商取引及びオンラインクライアントインターラクションのための統合、情報処理及び自己改善ファシリティ（ＩＳＩＣＩ）の装置、方法等を提供する。【解決手段】ＩＳＩＣＩは、マルチリンクメニューコンポーネントの作成及び維持、基底マルチリンク記録コンポーネントの登録及び更新、マルチリンクメニューコンポーネントの分配／シンジケーション、という３つのコンポーネントを有する。ＩＳＩＣＩは、マルチリンクメニューの作成を可能にする。これらのメニューは、リンク、広告、電子商取引などに出現可能である。ＩＳＩＣＩはユーザーがマルチリンクメニューを使用する方法を追跡する機構を与える。追跡情報はＩＳＩＣＩにフィードバックされ、実際の使用追跡に応答してメニュー構成を更に改良させる。ＩＳＩＣＩは、購入サイクルを月から瞬間に圧縮でき、購入サイクルの様々な段階に既にあるより広い範囲の将来のクライアントに役立つ。【選択図】図１
2012146319.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサが実行する方法において、
コンテンツにアクセスする要求クライアントからユニークパーシステント統一名称識別子の要求を受信し、ここで、前記要求はコンテンツのアクセスと当該コンテンツに埋め込まれたコードから誘起され、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子メニュー仕様が存在すればそれを取得し、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、
ユニークパーシステント統一名称識別子メニュー仕様を入手できなければユニークパーシステント統一名称識別子ディレクトリのメタデータから生成し、
前記ユニークパーシステント統一名称識別子メニュー仕様をユニークパーシステント統一名称識別子シンジケーターの前記ユニークパーシステント統一名称識別子ディレクトリに格納し、
ユニークパーシステント統一名称識別子メニュー仕様からユニークパーシステント統一名称識別子メニューを生成し、前記ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用されることを特徴とする方法。
【請求項２】
プロセッサが実行する方法において、
コンテンツにアクセスする要求クライアントからユニークパーシステント統一名称識別子の要求を受信し、ここで、前記要求はコンテンツのアクセスから誘起され、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子メニュー仕様を取得し、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、
ユニークパーシステント統一名称識別子メニュー仕様からユニークパーシステント統一名称識別子メニューを生成し、前記ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用されることを特徴とする方法。
【請求項３】
データベースは多数の広告プロバイダーからのメニュー仕様を変更し、各広告プロバイダーは、それ自身の広告者に対して異なるメニュー仕様を提供することができることを特徴とする請求項２に記載の方法。
【請求項４】
広告者は、ユニークパーシステント統一名称識別子多重識別子のスポンサーになることができることを特徴とする請求項３に記載の方法。
【請求項５】
インターリンクされたユニークパーシステント統一名称識別子に由来して増加した検索ランキングに対して費用が取得可能であることを特徴とする請求項４に記載の方法。
【請求項６】
前記ユニークパーシステント統一名称識別子は、キーワードに関連付けられていることを特徴とする請求項５に記載の方法。
【請求項７】
ユニークパーシステント統一名称識別子は、インターリンクされた他のユニークパーシステント統一名称識別子メニューを有することができることを特徴とする請求項３に記載の方法。
【請求項８】
ユニークパーシステント統一名称識別子プロバイダーは、ユニークパーシステント統一名称識別子メニュー提供に対して参照費用を受け取り可能であることを特徴とする請求項３に記載の方法。
【請求項９】
ユニークパーシステント統一名称識別子プロバイダーは、ユニークパーシステント統一名称識別子メニュー提供に対して参照費用を受け取り可能であることを特徴とする請求項３に記載の方法。
【請求項１０】
スポンサーのあるユニークパーシステント統一名称識別子メニューを表示するために広告費用が課されることを特徴とする請求項３に記載の方法。
【請求項１１】
ユニークパーシステント統一名称識別子メニューに対するコードを生成することを更に有することを特徴とする請求項２に記載の方法。
【請求項１２】
前記コードは頒布されることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記コードはＨＴＭＬであることを特徴とする請求項１２に記載の方法。
【請求項１４】
前記コードはＤＨＴＭＬであることを特徴とする請求項１２に記載の方法。
【請求項１５】
前記コードはジャバスクリプトであることを特徴とする請求項１２に記載の方法。
【請求項１６】
前記ターゲットコンテンツアセットに関するメタデータ情報がユニークパーシステント統一名称識別子ディレクトリ記録に格納されることを特徴とする請求項２に記載の方法。
【請求項１７】
前記メタデータ情報が前記ユニークパーシステント統一名称識別子ディレクトリ記録にハンドルバリューとして格納されることを特徴とする請求項１６に記載の方法。
【請求項１８】
前記ユニークパーシステント統一名称識別子は、人間を表すことを特徴とする請求項２に記載の方法。
【請求項１９】
前記ユニークパーシステント統一名称識別子は、人間の様々な側面を表す多重識別子コンポーネントを有することを特徴とする請求項１８に記載の方法。
【請求項２０】
前記ユニークパーシステント統一名称識別子は、多重識別子コンポーネントへのアクセスを制限するアクセス制御を有することを特徴とする請求項１９に記載の方法。
【請求項２１】
前記ユニークパーシステント統一名称識別子は、統一医師識別子として機能することを特徴とする請求項１８に記載の方法。
【請求項２２】
前記ユニークパーシステント統一名称識別子は、統一患者識別子として機能することを特徴とする請求項１８に記載の方法。
【請求項２３】
前記ユニークパーシステント統一名称識別子は、ボイスオーバーインターネットプロトコルを表すことを特徴とする請求項２に記載の方法。
【請求項２４】
前記ユニークパーシステント統一名称識別子は、インスタントメッセンジャー口座を表すことを特徴とする請求項２に記載の方法。
【請求項２５】
前記ユニークパーシステント統一名称識別子は、ＲＦＩＤを表すことを特徴とする請求項２に記載の方法。
【請求項２６】
前記ＲＦＩＤは、作成時にユニークパーシステント統一名称識別子として登録され、ユニークパーシステント統一名称識別子の一部としてＲＦＩＤ番号を含むことを特徴とする請求項２５に記載の方法。
【請求項２７】
前記ＲＦＩＤを含む取引は、前記ユニークパーシステント統一名称識別子のディレクトリ記録において追跡されることを特徴とする請求項２５に記載の方法。
【請求項２８】
前記ユニークパーシステント統一名称識別子は、健康管理記録を表すことを特徴とする請求項２に記載の方法。
【請求項２９】
前記ユニークパーシステント統一名称識別子は、イントラネットとして働くことを特徴とする請求項２に記載の方法。
【請求項３０】
前記イントラネットは、ユニークパーシステント統一名称識別子をローカル資源に対して解決させ、グローバルディレクトリへの解決を防止することを特徴とする請求項２９に記載の方法。
【請求項３１】
前記ユニークパーシステント統一名称識別子ディレクトリは、グローバルディレクトリであることを特徴とする請求項２に記載の方法。
【請求項３２】
前記要求は、当該コンテンツに埋め込まれたコードから誘起されることを特徴とする請求項２に記載の方法。
【請求項３３】
前記ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子ディレクトリから取得されることを特徴とする請求項２に記載の方法。
【請求項３４】
前記ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子シンジケーターから取得されることを特徴とする請求項２に記載の方法。
【請求項３５】
ユニークパーシステント統一名称識別子メニュー仕様を、それが入手不可能であれば、生成することを特徴とする請求項２に記載の方法。
【請求項３６】
前記ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子ディレクトリにおいてメタデータから生成されることを特徴とする請求項３５に記載の方法。
【請求項３７】
前記ユニークパーシステント統一名称識別子メニュー仕様を格納することを更に有することを特徴とする請求項３５に記載の方法。
【請求項３８】
前記ユニークパーシステント統一名称識別子メニュー仕様がユニークパーシステント統一名称識別子ディレクトリに格納されることを特徴とする請求項３７に記載の方法。
【請求項３９】
前記ユニークパーシステント統一名称識別子メニュー仕様がユニークパーシステント統一名称識別子シンジケーターに格納されることを特徴とする請求項３７に記載の方法。
【請求項４０】
前記ユニークパーシステント統一名称識別子メニューを前記要求クライアントに提供することを特徴とする請求項２に記載の方法。
【請求項４１】
コンテンツトラバースに応答して前記ユニークパーシステント統一名称識別子メニューを前記要求クライアントに表示することを特徴とする請求項４０に記載の方法。
【請求項４２】
前記メニューは、前記クライアントは広告でトラバースすると表示されることを特徴とする請求項４０に記載の方法。
【請求項４３】
前記メニューは、スポンサーのある検索エンジンクエリー結果に対して表示されることを特徴とする請求項４０に記載の方法。
【請求項４４】
前記要求クライアントのメニューナビゲーションに応答してユニークパーシステント統一名称識別子メニュートラバースを表示することを更に有することを特徴とする請求項４０に記載の方法。
【請求項４５】
前記ユニークパーシステント統一名称識別子メニューにおいてメニューアイテムのクライアント選択に応答してターゲット選択にトラバースすることを更に有することを特徴とする請求項４４に記載の方法。
【請求項４６】
プロセッサが実行する方法において、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、ユニークパーシステント統一名称識別子はターゲットコンテンツアセットに関係するコンテンツアイテムへの多重レファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子記録の階層構造に基づいてメニュー仕様を生成し、ここで、ユニークパーシステント統一名称識別子記録の第１レベル階層バリューは前記メニュー仕様のネストされたレベルを記述及び形成し、
ユニークパーシステント統一名称識別子メニュー仕様を格納し、前記ユニークパーシステント統一名称識別子はユニークパーシステント統一名称識別子シンジケーターに格納され、
前記ユニークパーシステント統一名称識別子メニュー仕様からユニークパーシステント統一名称識別子メニューを生成し、前記ユニークパーシステント統一名称識別子メニュー仕様は前記ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用されることを特徴とする請求項３５に記載の方法。
【請求項４７】
プロセッサが実行する方法において、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットに関係するコンテンツアイテムへの多重レファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子記録の階層構造に基づいてメニュー仕様を生成することを特徴とする方法。
【請求項４８】
データベースは、多数の広告プロバイダーからのメニュー仕様を変更し、各広告プロバイダーは、それ自身の広告者に対して異なるメニュー仕様を提供することができることを特徴とする請求項４７に記載の方法。
【請求項４９】
広告者は、ユニークパーシステント統一名称識別子多重識別子のスポンサーになることができることを特徴とする請求項４８に記載の方法。
【請求項５０】
インターリンクされたユニークパーシステント統一名称識別子に由来して増加した検索ランキングに対して費用が取得可能であることを特徴とする請求項４９に記載の方法。
【請求項５１】
前記ユニークパーシステント統一名称識別子は、キーワードに関連付けられていることを特徴とする請求項５０に記載の方法。
【請求項５２】
ユニークパーシステント統一名称識別子は、インターリンクされた他のユニークパーシステント統一名称識別子メニューを有することができることを特徴とする請求項４８に記載の方法。
【請求項５３】
ユニークパーシステント統一名称識別子プロバイダーは、ユニークパーシステント統一名称識別子メニュー提供に対して参照費用を受け取り可能であることを特徴とする請求項４８に記載の方法。
【請求項５４】
ユニークパーシステント統一名称識別子プロバイダーは、ユニークパーシステント統一名称識別子メニュー提供に対して参照費用を受け取り可能であることを特徴とする請求項４８に記載の方法。
【請求項５５】
スポンサーのあるユニークパーシステント統一名称識別子メニューを表示するために広告費用が課されることを特徴とする請求項４８に記載の方法。
【請求項５６】
前記ユニークパーシステント統一名称識別子メニューに対するコードを生成することを更に有することを特徴とする請求項２に記載の方法。
【請求項５７】
前記コードは頒布されることを特徴とする請求項５６に記載の方法。
【請求項５８】
前記コードはＨＴＭＬであることを特徴とする請求項５７に記載の方法。
【請求項５９】
前記コードはＤＨＴＭＬであることを特徴とする請求項５７に記載の方法。
【請求項６０】
前記コードはジャバスクリプトであることを特徴とする請求項５７に記載の方法。
【請求項６１】
ユニークパーシステント統一名称識別子仕様の生成は、コンテンツに埋め込まれた前記ユニークパーシステント統一名称識別子メニューの要求を有するサイト以外のサイトで発生することを特徴とする請求項４７に記載の方法。
【請求項６２】
ユニークパーシステント統一名称識別子仕様の生成は、ユニークパーシステント統一名称識別子メニューの要求を有するサイト以外のサイトで発生することを特徴とする請求項４７に記載の方法。
【請求項６３】
前記ターゲットコンテンツアセットに関するメタデータ情報がユニークパーシステント統一名称識別子ディレクトリ記録に格納されることを特徴とする請求項４７に記載の方法。
【請求項６４】
前記メタデータ情報が前記ユニークパーシステント統一名称識別子ディレクトリ記録にハンドルバリューとして格納されることを特徴とする請求項６３に記載の方法。
【請求項６５】
前記ユニークパーシステント統一名称識別子は、人間を表すことを特徴とする請求項４７に記載の方法。
【請求項６６】
前記ユニークパーシステント統一名称識別子は、人間の様々な側面を表す多重識別子コンポーネントを有することを特徴とする請求項６５に記載の方法。
【請求項６７】
前記ユニークパーシステント統一名称識別子は、多重識別子コンポーネントへのアクセスを制限するアクセス制御を有することを特徴とする請求項６６に記載の方法。
【請求項６８】
前記ユニークパーシステント統一名称識別子は、統一医師識別子として機能することを特徴とする請求項６５に記載の方法。
【請求項６９】
前記ユニークパーシステント統一名称識別子は、統一患者識別子として機能することを特徴とする請求項６５に記載の方法。
【請求項７０】
前記ユニークパーシステント統一名称識別子は、ボイスオーバーインターネットプロトコルを表すことを特徴とする請求項４７に記載の方法。
【請求項７１】
前記ユニークパーシステント統一名称識別子は、インスタントメッセンジャー口座を表すことを特徴とする請求項４７に記載の方法。
【請求項７２】
前記ユニークパーシステント統一名称識別子は、ＲＦＩＤを表すことを特徴とする請求項４７に記載の方法。
【請求項７３】
前記ＲＦＩＤは、作成時にユニークパーシステント統一名称識別子として登録され、ユニークパーシステント統一名称識別子の一部としてＲＦＩＤ番号を含むことを特徴とする請求項７２に記載の方法。
【請求項７４】
前記ＲＦＩＤを含む取引は、前記ユニークパーシステント統一名称識別子のディレクトリ記録において追跡されることを特徴とする請求項７２に記載の方法。
【請求項７５】
前記ユニークパーシステント統一名称識別子は、健康管理記録を表すことを特徴とする請求項４７に記載の方法。
【請求項７６】
ユニークパーシステント統一名称識別子記録の第１レベル階層バリューは、前記メニュー仕様のルートレベルを記述及び形成することを特徴とする請求項４７に記載の方法。
【請求項７７】
前記ユニークパーシステント統一名称識別子記録の後発ネスト階層バリューは、前記メニュー仕様のネストレベルを記述及び形成することを特徴とする請求項７６に記載の方法。
【請求項７８】
前記ユニークパーシステント統一名称識別子メニュー仕様を格納することを更に有することを特徴とする請求項４７に記載の方法。
【請求項７９】
前記ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子ディレクトリに格納されることを特徴とする請求項７８に記載の方法。
【請求項８０】
前記ユニークパーシステント統一名称識別子は、イントラネットとして機能することを特徴とする請求項７９に記載の方法。
【請求項８１】
前記イントラネットは、ユニークパーシステント統一名称識別子をローカル資源に対して解決させ、グローバルディレクトリへの解決を防止することを特徴とする請求項８０に記載の方法。
【請求項８２】
前記ユニークパーシステント統一名称識別子ディレクトリは、グローバルディレクトリであることを特徴とする請求項７９に記載の方法。
【請求項８３】
前記ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子シンジケーターに格納されることを特徴とする請求項７８に記載の方法。
【請求項８４】
前記ユニークパーシステント統一名称識別子メニュー仕様は、前記ユニークパーシステント統一名称識別子記録情報における第１の階層レベルに格納されることを特徴とする請求項７８に記載の方法。
【請求項８５】
前記メニュー仕様は、仕様として使用されて更なるメニュー仕様生成を防止する表示と共に格納されることを特徴とする請求項８４に記載の方法。
【請求項８６】
前記表示は、メニュー仕様の存在を知らせるブーリアン真値であることを特徴とする請求項８５に記載の方法。
【請求項８７】
ユニークパーシステント統一名称識別子記録の階層構造は、メニュー仕様の一部であるものを表すフィールド毎のフィールドバリューであることを特徴とする請求項４７に記載の方法。
【請求項８８】
ユニークパーシステント統一名称識別子記録の階層構造は、そのアクセス制御権を表すフィールド毎のフィールドバリューであることを特徴とする請求項４７に記載の方法。
【請求項８９】
前記ユニークパーシステント統一名称識別子メニュー仕様からユニークパーシステント統一名称識別子メニューを生成することを更に有することを特徴とする請求項４７に記載の方法。
【請求項９０】
前記ユニークパーシステント統一名称識別子メニュー仕様は、前記ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からバリューを特定するのに使用されることを特徴とする請求項８９に記載の方法。
【請求項９１】
前記ユニークパーシステント統一名称識別子メニューを要求クライアントに提供することを更に有することを特徴とする請求項４７に記載の方法。
【請求項９２】
要求クライアントに、コンテンツトラバースに応答して前記ユニークパーシステント統一名称識別子メニューを表示することを特徴とする請求項９１に記載の方法。
【請求項９３】
前記メニューは、前記クライアントが広告でトラバースすると表示されることを特徴とする請求項９２に記載の方法。
【請求項９４】
前記メニューは、スポンサーのある検索エンジンクエリー結果に対して表示されることを特徴とする請求項９２に記載の方法。
【請求項９５】
前記要求クライアントのメニューナビゲーションに応答するユニークパーシステント統一名称識別子メニュートラバースを表示することを更に有することを特徴とする請求項９１に記載の方法。
【請求項９６】
前記ユニークパーシステント統一名称識別子メニューにおいてメニューアイテムのクライアント選択に応答してターゲット選択にトラバースすることを更に有することを特徴とする請求項９５に記載の方法。
【請求項９７】
プロセッサが実行する方法において、
メタデータフィールドとバリューを取得し、
ユニークパーシステント統一名称識別子メニュー仕様を存在すれば取得し、
入手不能であれば、前記メタデータフィールド及びバリューからユニークパーシステント統一名称識別子メニュー仕様を生成し、
メタデータフィールドを前記メニュー仕様におけるフィールドに照合し、
照合されたフィールド及びフィールドバリューに基づいて前記メタデータを検索し、
前記照合されたフィールド及びフィールドバリューに基づいてターゲットレファレンスを形成し、
ユニークパーシステント統一名称識別子ディレクトリにおけるユニークパーシステント統一名称識別子記録に前記ターゲットレファレンスを格納することを特徴とする方法。
【請求項９８】
前記メタデータフィールド及びバリューは、イントラ接続されたシステムから取得されることを特徴とする請求項９７に記載の方法。
【請求項９９】
前記メタデータフィールド及びバリューは、イントラ接続されたシステムに接続されたコネクタを介して取得されることを特徴とする請求項９８に記載の方法。
【請求項１００】
前記メタデータフィールド及びバリューは、イントラ接続されたシステムからのマスターメタデータ格納部から取得及び選択されることを特徴とする請求項９８に記載の方法。
【請求項１０１】
メタデータ情報は前記ターゲットコンテンツアセットに関してユニークパーシステント統一名称識別子ディレクトリ記録に格納されることを特徴とする請求項９７に記載の方法。
【請求項１０２】
前記メタデータ情報が前記ユニークパーシステント統一名称識別子ディレクトリ記録にハンドルバリューとして格納されることを特徴とする請求項１０１に記載の方法。
【請求項１０３】
前記ユニークパーシステント統一名称識別子は、人間を表すことを特徴とする請求項９７に記載の方法。
【請求項１０４】
前記ユニークパーシステント統一名称識別子は、人間の様々な側面を表す多重識別子コンポーネントを有することを特徴とする請求項１０３に記載の方法。
【請求項１０５】
前記ユニークパーシステント統一名称識別子は、多重識別子コンポーネントへのアクセスを制限するアクセス制御を有することを特徴とする請求項１０４に記載の方法。
【請求項１０６】
前記ユニークパーシステント統一名称識別子は、統一医師識別子として機能することを特徴とする請求項１０３に記載の方法。
【請求項１０７】
前記ユニークパーシステント統一名称識別子は、統一患者識別子として機能することを特徴とする請求項１０３に記載の方法。
【請求項１０８】
前記ユニークパーシステント統一名称識別子は、ボイスオーバーインターネットプロトコルを表すことを特徴とする請求項９７に記載の方法。
【請求項１０９】
前記ユニークパーシステント統一名称識別子は、インスタントメッセンジャー口座を表すことを特徴とする請求項９７に記載の方法。
【請求項１１０】
前記ユニークパーシステント統一名称識別子は、ＲＦＩＤを表すことを特徴とする請求項９７に記載の方法。
【請求項１１１】
前記ＲＦＩＤは、作成時にユニークパーシステント統一名称識別子として登録され、ユニークパーシステント統一名称識別子の一部としてＲＦＩＤ番号を含むことを特徴とする請求項１１０に記載の方法。
【請求項１１２】
前記ＲＦＩＤを含む取引は、前記ユニークパーシステント統一名称識別子のディレクトリ記録において追跡されることを特徴とする請求項１１０に記載の方法。
【請求項１１３】
前記ユニークパーシステント統一名称識別子は、健康管理記録を表すことを特徴とする請求項９７に記載の方法。
【請求項１１４】
前記ユニークパーシステント統一名称識別子は、イントラネットとして機能することを特徴とする請求項９７に記載の方法。
【請求項１１５】
前記イントラネットは、ユニークパーシステント統一名称識別子をローカル資源に対して解決させ、グローバルディレクトリへの解決を防止することを特徴とする請求項１１４に記載の方法。
【請求項１１６】
前記ユニークパーシステント統一名称識別子ディレクトリは、グローバルディレクトリであることを特徴とする請求項９７に記載の方法。
【請求項１１７】
前記ユニークパーシステント統一名称識別子をコンテンツに埋め込むことを更に有することを特徴とする請求項９７に記載の方法。
【請求項１１８】
前記ターゲットコンテンツアセット及び前記ターゲットレファレンスへのリンクを有するユニークパーシステント統一名称識別子メニューを作成することを更に有することを特徴とする請求項９７に記載の方法。
【請求項１１９】
前記ユニークパーシステント統一名称識別子メニューを前記要求クライアントに提供することを更に有することを特徴とする請求項１１８に記載の方法。
【請求項１２０】
コンテンツトラバースに応答して前記ユニークパーシステント統一名称識別子メニューを前記要求クライアントに表示することを更に有することを特徴とする請求項１１９に記載の方法。
【請求項１２１】
前記メニューは、前記クライアントは広告でトラバースすると表示されることを特徴とする請求項１２０に記載の方法。
【請求項１２２】
前記メニューは、スポンサーのある検索エンジンクエリー結果に対して表示されることを特徴とする請求項１２０に記載の方法。
【請求項１２３】
前記要求クライアントのメニューナビゲーションに応答するユニークパーシステント統一名称識別子メニュートラバースを表示することを更に有することを特徴とする請求項１１９に記載の方法。
【請求項１２４】
前記ユニークパーシステント統一名称識別子メニューにおいてメニューアイテムのクライアント選択に応答してターゲット選択にトラバースすることを更に有することを特徴とする請求項１２３に記載の方法。
【請求項１２５】
前記ユニークパーシステント統一名称識別子メニュー仕様を格納することをと更に有することを特徴とする請求項９７に記載の方法。
【請求項１２６】
前記ユニークパーシステント統一名称識別子をコンテンツに埋め込むことを更に有することを特徴とする請求項１２５に記載の方法。
【請求項１２７】
前記ユニークパーシステント統一名称識別子メニュー仕様がユニークパーシステント統一名称識別子ディレクトリに格納されることを特徴とする請求項１２５に記載の方法。
【請求項１２８】
前記ユニークパーシステント統一名称識別子メニュー仕様がユニークパーシステント統一名称識別子シンジケーターに格納されることを特徴とする請求項１２５に記載の方法。
【請求項１２９】
ターゲットレファレンスは、コンピュータシステムをリバースエンジニアリングすることによって生成されることを特徴とする請求項９７に記載の方法。
【請求項１３０】
ターゲットレファレンスは、ウェブサイトマップを取得することによって生成されることを特徴とする請求項９７に記載の方法。
【請求項１３１】
ウェブサイトマップは、クローリングによって取得されることを特徴とする請求項１３０に記載の方法。
【請求項１３２】
ターゲットレファレンスは、ＲＳＳフィードを取得することによって生成されることを特徴とする請求項９７に記載の方法。
【請求項１３３】
ターゲットレファレンスは、ブログエントリによって生成されることを特徴とする請求項９７に記載の方法。
【請求項１３４】
ターゲットレファレンスは、ウェブサイトから主メニューを取得することによって生成されることを特徴とする請求項９７に記載の方法。
【請求項１３５】
主メニューは、クローリングを通じて取得されることを特徴とする請求項１３４に記載の方法。
【請求項１３６】
前記コンピュータシステムの検索クエリーシンタックスは、ターゲットコンテンツアセットと前記ターゲットコンテンツアセットに関連するアイテムを識別するのに使用されることを特徴とする請求項１２９に記載の方法。
【請求項１３７】
ターゲットレファレンスは、メタデータフィールドバリューが提供可能な、提供されたクエリープロンプトを通じて生成されることを特徴とする請求項９７に記載の方法。
【請求項１３８】
前記クエリープロンプトは検索エンジンであり、トップ検索結果はターゲットレファレンスとして使用されることを特徴とする請求項１３７に記載の方法。
【請求項１３９】
メタデータフィールド及びバリューはクライアントから取得することを特徴とする請求項９７に記載の方法。
【請求項１４０】
前記メタデータはタブ記述形式であることを特徴とする請求項１３９に記載の方法。
【請求項１４１】
前記メタデータはＸＭＬ形式であることを特徴とする請求項１３９に記載の方法。
【請求項１４２】
前記メタデータはスプレッドシート形式であることを特徴とする請求項１３９に記載の方法。
【請求項１４３】
プロセッサが実行する方法において、
ユニークパーシステント統一名称識別子とユニークパーシステント統一名称識別子メニューとの間の関係を確立し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
前記ターゲットレファレンスを形成し、ここで、前記ターゲットレファレンスはユニークパーシステント統一名称識別子ディレクトリにおけるユニークパーシステント統一名称識別子記録に格納され、
前記ターゲットコンテンツアセットと前記ターゲットレファレンスへのリンクを有するユニークパーシステント統一名称識別子メニューを作成することを特徴とする方法。
【請求項１４４】
前記ターゲットコンテンツアセットに関するメタデータ情報がユニークパーシステント統一名称識別子ディレクトリ記録に格納されることを特徴とする請求項１４３に記載の方法。
【請求項１４５】
前記メタデータ情報が前記ユニークパーシステント統一名称識別子ディレクトリ記録にハンドルバリューとして格納されることを特徴とする請求項１４４に記載の方法。
【請求項１４６】
前記ユニークパーシステント統一名称識別子は、人間を表すことを特徴とする請求項１４３に記載の方法。
【請求項１４７】
前記ユニークパーシステント統一名称識別子は、人間の様々な側面を表す多重識別子コンポーネントを有することを特徴とする請求項１４６に記載の方法。
【請求項１４８】
前記ユニークパーシステント統一名称識別子は、多重識別子コンポーネントへのアクセスを制限するアクセス制御を有することを特徴とする請求項１４７に記載の方法。
【請求項１４９】
前記ユニークパーシステント統一名称識別子は、統一医師識別子として機能することを特徴とする請求項１４６に記載の方法。
【請求項１５０】
前記ユニークパーシステント統一名称識別子は、統一患者識別子として機能することを特徴とする請求項１４６に記載の方法。
【請求項１５１】
前記ユニークパーシステント統一名称識別子は、ボイスオーバーインターネットプロトコルを表すことを特徴とする請求項１４３に記載の方法。
【請求項１５２】
前記ユニークパーシステント統一名称識別子は、インスタントメッセンジャー口座を表すことを特徴とする請求項１４３に記載の方法。
【請求項１５３】
前記ユニークパーシステント統一名称識別子は、ＲＦＩＤを表すことを特徴とする請求項１４３に記載の方法。
【請求項１５４】
前記ＲＦＩＤは、作成時にユニークパーシステント統一名称識別子として登録され、ユニークパーシステント統一名称識別子の一部としてＲＦＩＤ番号を含むことを特徴とする請求項１５３に記載の方法。
【請求項１５５】
前記ＲＦＩＤを含む取引は、前記ユニークパーシステント統一名称識別子のディレクトリ記録において追跡されることを特徴とする請求項１５３に記載の方法。
【請求項１５６】
前記ユニークパーシステント統一名称識別子は、健康管理記録を表すことを特徴とする請求項１４３に記載の方法。
【請求項１５７】
前記ユニークパーシステント統一名称識別子メニューをコンテンツに埋め込むことを更に有することを特徴とする請求項１４３に記載の方法。
【請求項１５８】
前記ターゲットレファレンスを前記ユニークパーシステント統一名称識別子ディレクトリにおけるユニークパーシステント統一名称識別子記録に格納することを更に有することを特徴とする請求項１４３に記載の方法。
【請求項１５９】
前記確立された関係は、メニュー仕様に埋め込まれることを特徴とする請求項１４３に記載の方法。
【請求項１６０】
前記ユニークパーシステント統一名称識別子メニュー仕様を格納することを更に有することを特徴とする請求項１５９に記載の方法。
【請求項１６１】
ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子ディレクトリに格納されることを特徴とする請求項１６０に記載の方法。
【請求項１６２】
ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子シンジケーターに格納されることを特徴とする請求項１６０に記載の方法。
【請求項１６３】
ターゲットレファレンスは、コンピュータシステムをリバースエンジニアリングすることによって生成されることを特徴とする請求項１４３に記載の方法。
【請求項１６４】
ターゲットレファレンスは、ウェブサイトマップを取得することによって生成されることを特徴とする請求項１４３に記載の方法。
【請求項１６５】
ウェブサイトマップは、クローリングによって取得されることを特徴とする請求項１６４に記載の方法。
【請求項１６６】
ターゲットレファレンスは、ＲＳＳフィードを取得することによって生成されることを特徴とする請求項１４３に記載の方法。
【請求項１６７】
ターゲットレファレンスは、ブログエントリによって生成されることを特徴とする請求項１４３に記載の方法。
【請求項１６８】
ターゲットレファレンスは、ウェブサイトから主メニューを取得することによって生成されることを特徴とする請求項１４３に記載の方法。
【請求項１６９】
主メニューは、クローリングを通じて取得されることを特徴とする請求項１６８に記載の方法。
【請求項１７０】
前記コンピュータシステムの検索クエリーシンタックスは、ターゲットコンテンツアセットと前記ターゲットコンテンツアセットに関連するアイテムを識別するのに使用されることを特徴とする請求項１６３に記載の方法。
【請求項１７１】
ターゲットレファレンスは、メタデータフィールドバリューが提供される、提供クエリープロンプトを通じて生成されることを特徴とする請求項１４３に記載の方法。
【請求項１７２】
前記クエリープロンプトは検索エンジンであり、トップ検索結果はターゲットレファレンスとして使用されることを特徴とする請求項１７１に記載の方法。
【請求項１７３】
前記ユニークパーシステント統一名称識別子メニューを前記要求クライアントに提供することを特徴とする請求項１４３に記載の方法。
【請求項１７４】
コンテンツトラバースに応答して前記ユニークパーシステント統一名称識別子メニューを前記要求クライアントに表示することを特徴とする請求項１７３に記載の方法。
【請求項１７５】
前記メニューは、前記クライアントは広告でトラバースすると表示されることを特徴とする請求項１７４に記載の方法。
【請求項１７６】
前記メニューは、スポンサーのある検索エンジンクエリー結果に対して表示されることを特徴とする請求項１７４に記載の方法。
【請求項１７７】
前記要求クライアントのメニューナビゲーションに応答するユニークパーシステント統一名称識別子メニュートラバースを表示することを更に有することを特徴とする請求項１７３に記載の方法。
【請求項１７８】
前記ユニークパーシステント統一名称識別子メニューにおいてメニューアイテムのクライアント選択に応答してターゲット選択にトラバースすることを更に有することを特徴とする請求項１７７に記載の方法。
【請求項１７９】
前記ユニークパーシステント統一名称識別子はイントラネットとして機能することを特徴とする請求項１４３に記載の方法。
【請求項１８０】
前記イントラネットは、ユニークパーシステント統一名称識別子をローカル資源に対して解決させ、グローバルディレクトリへの解決を防止することを特徴とする請求項１７９に記載の方法。
【請求項１８１】
プロセッサが実行する方法において、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子記録情報を表示し、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを追加し、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを削除し、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを変更し、
ユニークパーシステント統一名称識別子ディレクトリに、更新されたユニークパーシステント統一名称識別子記録情報を格納することを特徴とする方法。
【請求項１８２】
更新されたユニークパーシステント統一名称識別子記録情報を、それが編集されると表示することを更に有することを特徴とする請求項１８１に記載の方法。
【請求項１８３】
前記ターゲットコンテンツアセットに関するメタデータ情報がユニークパーシステント統一名称識別子ディレクトリ記録に格納されることを特徴とする請求項１８１に記載の方法。
【請求項１８４】
前記メタデータ情報が前記ユニークパーシステント統一名称識別子ディレクトリ記録にハンドルバリューとして格納されることを特徴とする請求項１８３に記載の方法。
【請求項１８５】
前記ユニークパーシステント統一名称識別子は、人間を表すことを特徴とする請求項１８１に記載の方法。
【請求項１８６】
前記ユニークパーシステント統一名称識別子は、人間の様々な側面を表す多重識別子コンポーネントを有することを特徴とする請求項１８５に記載の方法。
【請求項１８７】
前記ユニークパーシステント統一名称識別子は、多重識別子コンポーネントへのアクセスを制限するアクセス制御を有することを特徴とする請求項１８６に記載の方法。
【請求項１８８】
前記ユニークパーシステント統一名称識別子は、統一医師識別子として機能することを特徴とする請求項１８５に記載の方法。
【請求項１８９】
前記ユニークパーシステント統一名称識別子は、統一患者識別子として機能することを特徴とする請求項１８５に記載の方法。
【請求項１９０】
前記ユニークパーシステント統一名称識別子は、ボイスオーバーインターネットプロトコルを表すことを特徴とする請求項１８１に記載の方法。
【請求項１９１】
前記ユニークパーシステント統一名称識別子は、インスタントメッセンジャー口座を表すことを特徴とする請求項１８１に記載の方法。
【請求項１９２】
前記ユニークパーシステント統一名称識別子は、ＲＦＩＤを表すことを特徴とする請求項１８１に記載の方法。
【請求項１９３】
前記ＲＦＩＤは、作成時にユニークパーシステント統一名称識別子として登録され、ユニークパーシステント統一名称識別子の一部としてＲＦＩＤ番号を含むことを特徴とする請求項１９２に記載の方法。
【請求項１９４】
前記ＲＦＩＤを含む取引は、前記ユニークパーシステント統一名称識別子のディレクトリ記録において追跡されることを特徴とする請求項１９２に記載の方法。
【請求項１９５】
前記ユニークパーシステント統一名称識別子は、健康管理記録を表すことを特徴とする請求項１８１に記載の方法。
【請求項１９６】
前記ユニークパーシステント統一名称識別子は、イントラネットとして働くことを特徴とする請求項１８１に記載の方法。
【請求項１９７】
前記イントラネットは、ユニークパーシステント統一名称識別子をローカル資源に対して解決させ、グローバルディレクトリへの解決を防止することを特徴とする請求項１９６に記載の方法。
【請求項１９８】
前記ユニークパーシステント統一名称識別子ディレクトリは、グローバルディレクトリであることを特徴とする請求項１８１に記載の方法。
【請求項１９９】
前記更新されたユニークパーシステント統一名称識別子記録情報に基づいてメニュー仕様を生成することを更に有することを特徴とする請求項１８１に記載の方法。
【請求項２００】
前記更新されたユニークパーシステント統一名称識別子記録情報に基づいてユニークパーシステント統一名称識別子メニューを生成することを更に有することを特徴とする請求項１８１に記載の方法。
【請求項２０１】
プロセッサが実行する方法において、
ユニークパーシステント統一名称識別子のためのメニュー仕様の要求を受信し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
前記メニュー仕様をデータベースで検索し、
前記データベースにおいて見つからなければ、ユニークパーシステント統一名称識別子ディレクトリにおいてメタデータからの前記ユニークパーシステント統一名称識別子に対してメニュー仕様を生成し、
前記メニュー仕様をもし生成された場合には前記データベースに格納し、
前記ユニークパーシステント統一名称識別子メニュー仕様からユニークパーシステント統一名称識別子メニューを生成し、ここで、前記ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用され、
要求に応答して前記ユニークパーシステント統一名称識別子メニューを要求クライアントに提供することを特徴とする方法。
【請求項２０２】
データベースは多数の広告プロバイダーからのメニュー仕様を変更し、各広告プロバイダーは、それ自身の広告者に対して異なるメニュー仕様を提供することができることを特徴とする請求項２０１に記載の方法。
【請求項２０３】
広告者は、ユニークパーシステント統一名称識別子多重識別子のスポンサーになることができることを特徴とする請求項２０２に記載の方法。
【請求項２０４】
インターリンクされたユニークパーシステント統一名称識別子に由来して増加した検索ランキングに対して費用が取得可能であることを特徴とする請求項２０３に記載の方法。
【請求項２０５】
前記ユニークパーシステント統一名称識別子は、キーワードに関連付けられていることを特徴とする請求項２０４に記載の方法。
【請求項２０６】
ユニークパーシステント統一名称識別子は、インターリンクされた他のユニークパーシステント統一名称識別子メニューを有することができることを特徴とする請求項２０２に記載の方法。
【請求項２０７】
ユニークパーシステント統一名称識別子プロバイダーは、ユニークパーシステント統一名称識別子メニュー提供に対して参照費用を受け取り可能であることを特徴とする請求項２０２に記載の方法。
【請求項２０８】
ユニークパーシステント統一名称識別子プロバイダーは、ユニークパーシステント統一名称識別子メニュー提供に対して参照費用を受け取り可能であることを特徴とする請求項２０２に記載の方法。
【請求項２０９】
スポンサーのあるユニークパーシステント統一名称識別子メニューを表示するために広告費用が課されることを特徴とする請求項２０２に記載の方法。
【請求項２１０】
ユニークパーシステント統一名称識別子メニューに対するコードを生成することを更に有することを特徴とする請求項２に記載の方法。
【請求項２１１】
前記コードは頒布されることを特徴とする請求項２１０に記載の方法。
【請求項２１２】
前記コードはＨＴＭＬであることを特徴とする請求項２１１に記載の方法。
【請求項２１３】
前記コードはＤＨＴＭＬであることを特徴とする請求項２１１に記載の方法。
【請求項２１４】
前記コードはジャバスクリプトであることを特徴とする請求項２１１に記載の方法。
【請求項２１５】
前記ターゲットコンテンツアセットに関するメタデータ情報がユニークパーシステント統一名称識別子ディレクトリ記録に格納されることを特徴とする請求項２０１に記載の方法。
【請求項２１６】
前記メタデータ情報が前記ユニークパーシステント統一名称識別子ディレクトリ記録にハンドルバリューとして格納されることを特徴とする請求項２１５に記載の方法。
【請求項２１７】
前記ユニークパーシステント統一名称識別子は、人間を表すことを特徴とする請求項２０１に記載の方法。
【請求項２１８】
前記ユニークパーシステント統一名称識別子は、人間の様々な側面を表す多重識別子コンポーネントを有することを特徴とする請求項２１７に記載の方法。
【請求項２１９】
前記ユニークパーシステント統一名称識別子は、多重識別子コンポーネントへのアクセスを制限するアクセス制御を有することを特徴とする請求項２１８に記載の方法。
【請求項２２０】
前記ユニークパーシステント統一名称識別子は、統一医師識別子として機能することを特徴とする請求項２１７に記載の方法。
【請求項２２１】
前記ユニークパーシステント統一名称識別子は、統一患者識別子として機能することを特徴とする請求項２１７に記載の方法。
【請求項２２２】
前記ユニークパーシステント統一名称識別子は、ボイスオーバーインターネットプロトコルを表すことを特徴とする請求項２０１に記載の方法。
【請求項２２３】
前記ユニークパーシステント統一名称識別子は、インスタントメッセンジャー口座を表すことを特徴とする請求項２０１に記載の方法。
【請求項２２４】
前記ユニークパーシステント統一名称識別子は、ＲＦＩＤを表すことを特徴とする請求項２０１に記載の方法。
【請求項２２５】
前記ＲＦＩＤは、作成時にユニークパーシステント統一名称識別子として登録され、ユニークパーシステント統一名称識別子の一部としてＲＦＩＤ番号を含むことを特徴とする請求項２２４に記載の方法。
【請求項２２６】
前記ＲＦＩＤを含む取引は、前記ユニークパーシステント統一名称識別子のディレクトリ記録において追跡されることを特徴とする請求項２２４に記載の方法。
【請求項２２７】
前記ユニークパーシステント統一名称識別子は、健康管理記録を表すことを特徴とする請求項２０１に記載の方法。
【請求項２２８】
ユニークパーシステント統一名称識別子仕様の生成は、コンテンツに埋め込まれたユニークパーシステント統一名称識別子メニューの要求を有するサイト以外のサイトで発生することを特徴とする請求項２０１に記載の方法。
【請求項２２９】
ユニークパーシステント統一名称識別子仕様の生成は、ユニークパーシステント統一名称識別子メニューの要求を有するサイト以外のサイトで発生することを特徴とする請求項２０１に記載の方法。
【請求項２３０】
データベースは多数の広告プロバイダーからのメニュー仕様を変更し、各広告プロバイダーは、それ自身の広告者に対して異なるメニュー仕様を提供することができることを特徴とする請求項２０１に記載の方法。
【請求項２３１】
要求クライアントに提供される前記ユニークパーシステント統一名称識別子メニューは前記クライアントの識別表示に基づいていることを特徴とする請求項２０１に記載の方法。
【請求項２３２】
前記要求はコンテンツに埋め込まれたコードから誘起されることを特徴とする請求項２０１に記載の方法。
【請求項２３３】
要求クライアントに、コンテンツトラバースに応答して前記ユニークパーシステント統一名称識別子メニューを表示することを特徴とする請求項２０１に記載の方法。
【請求項２３４】
前記要求クライアントのメニューナビゲーションに応答してユニークパーシステント統一名称識別子メニュートラバースを表示することを更に有することを特徴とする請求項２０１に記載の方法。
【請求項２３５】
前記メニューは、前記クライアントは広告でトラバースすると表示されることを特徴とする請求項２３４に記載の方法。
【請求項２３６】
前記メニューは、スポンサーのある検索エンジンクエリー結果に対して表示されることを特徴とする請求項２３４に記載の方法。
【請求項２３７】
前記ユニークパーシステント統一名称識別子メニューにおいてメニューアイテムのクライアント選択に応答してターゲット選択にトラバースすることを更に有することを特徴とする請求項２３４に記載の方法。
【請求項２３８】
前記ユニークパーシステント統一名称識別子ディレクトリは、イントラネットとして機能することを特徴とする請求項２０１に記載の方法。
【請求項２３９】
前記イントラネットは、ユニークパーシステント統一名称識別子をローカル資源に対して解決させ、グローバルディレクトリへの解決を防止することを特徴とする請求項２３８に記載の方法。
【請求項２４０】
プロセッサが実行する方法であって、
ユニークパーシステント統一名称識別子のために通信ネットワークをクロールしてユニークパーシステント統一名称識別子のインデックスを生成し、ここで、前記要求はコンテンツのアクセスと当該コンテンツに埋め込まれたコードから誘起され、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
比較に基づいてターゲットユニークパーシステント統一名称識別子を取得し、
ウェブサイトをインデックスクロールしながらターゲットユニークパーシステント統一名称識別子を発見されたユニークパーシステント統一名称識別子と比較し、
ユニークパーシステント統一名称識別子と発見されたユニークパーシステント統一名称識別子との間の照合数と非照合数に着目することによってターゲットユニークパーシステント統一名称識別子のインターリンク度を決定し、
決定されたインターリンク度情報と共にユニークパーシステント統一名称識別子データベースにおいてユニークパーシステント統一名称識別子インデックスを更新することを特徴とする方法。
【請求項２４１】
比較に基づいてターゲットユニークパーシステント統一名称識別子を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、
ウェブサイトをインデックスクロールしながらターゲットユニークパーシステント統一名称識別子を発見されたユニークパーシステント統一名称識別子と比較し、
ユニークパーシステント統一名称識別子と発見されたユニークパーシステント統一名称識別子との間の照合数と非照合数に着目することによってターゲットユニークパーシステント統一名称識別子のインターリンク度を決定することを特徴とする方法。
【請求項２４２】
ユニークパーシステント統一名称識別子のために通信ネットワークをクロールしてユニークパーシステント統一名称識別子のインデックスを生成することを更に有することを特徴とする請求項２４１に記載の方法。
【請求項２４３】
決定されたインターリンク度情報によりユニークパーシステント統一名称識別子データベースにおいてユニークパーシステント統一名称識別子インデックスを更新することを更に有することを特徴とする請求項２４１に記載の方法。
【請求項２４４】
前記ユニークパーシステント統一名称識別子は、前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であることを特徴とする請求項２４１に記載の方法。
【請求項２４５】
前記ユニークパーシステント統一名称識別子は、前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であることを特徴とする請求項２４１に記載の方法。
【請求項２４６】
前記ターゲットユニークパーシステント統一名称識別子にはスポンサーがついていることを特徴とする請求項２４１に記載の方法。
【請求項２４７】
前記ターゲットユニークパーシステント統一名称識別子は個別に特定されていることを特徴とする請求項２４１に記載の方法。
【請求項２４８】
前記ターゲットユニークパーシステント統一名称識別子はインデックスされたユニークパーシステント統一名称識別子のデータベースから取得されることを特徴とする請求項２４１に記載の方法。
【請求項２４９】
インターリンク度の決定は、既知のユニークパーシステント統一名称識別子毎に行われることを特徴とする請求項２４１に記載の方法。
【請求項２５０】
インターリンクされたユニークパーシステント統一名称識別子のランキングを生成することを特徴とする請求項２４９に記載の方法。
【請求項２５１】
ランキングはインターリンクデータベースからユニークパーシステント統一名称識別子を選択することを特徴とする請求項２５０に記載の方法。
【請求項２５２】
前記選択は、ランキング結果をセクターに限定することを特徴とする請求項２５１に記載の方法。
【請求項２５３】
前記選択は、ランキング結果を製品に限定することを特徴とする請求項２５１に記載の方法。
【請求項２５４】
前記選択は、ランキングを期間に限定することを特徴とする請求項２５１に記載の方法。
【請求項２５５】
前記ランキングは、周期的に生成されることを特徴とする請求項２５０に記載の方法。
【請求項２５６】
前記ランキングは販売されることを特徴とする請求項２５０に記載の方法。
【請求項２５７】
前記インターリンク度情報は販売されることを特徴とする請求項２４１に記載の方法。
【請求項２５８】
内部関連データ種類を有するデータ構造を埋め込む信号状態を有するプロセッサがアクセス可能な媒体であって、
ユニークパーシステント統一名称識別子と、
ターゲットコンテンツアセットへのレファレンスと、
前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの多重レファレンスと、
メニュー仕様の一部であることを示すデータ種類毎のフィールドバリューと、を有し、正の表示は前記メニュー仕様の一部として使用されるデータ種類をもたらし、負の表示はデータ種類の無視をもたらすことを特徴とする媒体。
【請求項２５９】
アクセス権を特定するデータ種類毎にアクセス制御フィールドバリューを更に有する請求項２５８に記載の媒体。
【請求項２６０】
内部関連データ種類を有するデータ構造を埋め込む信号状態を有するプロセッサがアクセス可能な媒体であって、
ユニークパーシステント統一名称識別子と、
ターゲットコンテンツアセットへのレファレンスと、
前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの多重レファレンスと、
アクセス権を特定するデータ種類毎にアクセス制御フィールドバリューと、を有することを特徴とする媒体。
【請求項２６１】
メニュー仕様の一部であることを示すデータ種類毎のフィールドバリューと、を有し、正の表示は前記メニュー仕様の一部として使用されるデータ種類をもたらし、負の表示はデータ種類の無視をもたらすことを特徴とする請求項２６０に記載の媒体。
【請求項２６２】
内部関連データ種類を有するデータ構造を埋め込む信号状態を有するプロセッサがアクセス可能な媒体であって、
ユニークパーシステント統一名称識別子からのバリュー及びメタデータフィールドからの第１レベル階層バリュー、ここで、階層にある前記第１レベル階層バリューはユニークパーシステント統一名称識別子メニューのルートレベル構造を有し、
入手可能であれば、前記ユニークパーシステント統一名称識別子からのメタデータフィールド及びバリューからの後発ネストレベル階層バリューと、ここで、各後発ネストレベルは前記階層においてより高いレベルに関連し、
ターゲットコンテンツアセットに関連するコンテンツアイテムへのレファレンスと、を有し、コンテンツアイテムへのレファレンスは前記階層における端末レベルである各ネストレベル階層バリューに関連付けられていることを特徴とするプロセッサがアクセス可能な媒体。
【請求項２６３】
前記データ種類に基づいてメニューを生成する命令信号を更に有することを特徴とする請求項２６２に記載の媒体。
【請求項２６４】
メモリにおけるインターラクションインターフェースにおいて、
命令信号と、ここで、前記インターラクションインターフェースはユーザーとシステムイベント信号に応答し、前記命令信号は実施するのにプロセッサが発行可能で、
メタデータフィールドからのバリューとユニークパーシステント統一名称識別子からのバリューからの第１レベル階層メニューと、ここで、使用される前記フィールド及びバリューはメニュー仕様によって特定され、
入手可能であれば、メタデータフィールドからのバリューとユニークパーシステント統一名称識別子からのバリューからの後発ネストレベル階層メニューと、ここで、使用される前記フィールド及びバリューはメニュー仕様によって特定され、各後発ネストレベルメニューはその関連するより高いレベルのメニューから生まれ、
ターゲットコンテンツアセットに関連するコンテンツアイテムへのレファレンスと、ここで、コンテンツアイテムへのレファレンスは前記階層における端末レベルである各ネストレベル階層バリューに関連付けられ、非末端メニューは産まれた関連ネストメニューへのユーザー選択に応答し、末端メニューは前記レファレンスをナビゲートする命令信号を生成するためにユーザー選択に応答することを特徴とする媒体。
【請求項２６５】
メニュー生成のシステムにおいて、
ユニークパーシステント統一名称識別子の要求を受信する手段と、ここで、前記要求はコンテンツのアクセスから誘起され、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子メニュー仕様を取得する手段と、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得する手段と、
ユニークパーシステント統一名称識別子メニュー仕様からユニークパーシステント統一名称識別子メニューを生成する手段と、を有し、ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用されることを特徴とするシステム。
【請求項２６６】
仕様生成のシステムにおいて、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得する手段と、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子記録の階層構造に基づいてメニュー仕様を生成する手段と、
を有することを特徴とするシステム。
【請求項２６７】
レファレンスのシステムにおいて、
メタデータフィールドとバリューを取得する手段と、
ユニークパーシステント統一名称識別子メニュー仕様をもし存在すれば取得する手段と、
入手不能であれば、前記メタデータフィールド及びバリューからユニークパーシステント統一名称識別子メニュー仕様を生成する手段と、
メタデータフィールドを前記メニュー仕様におけるフィールドに照合する手段と、
前記照合されたフィールド及びフィールドバリューに基づいて前記メタデータを検索する手段と、
前記照合したフィールド及びフィールドバリューに基づいてターゲットレファレンスを形成する手段と、
ユニークパーシステント統一名称識別子ディレクトリにおけるユニークパーシステント統一名称識別子記録に前記ターゲットレファレンスを格納する手段と、
を有することを特徴とするシステム。
【請求項２６８】
レファレンスのシステムにおいて、
ユニークパーシステント統一名称識別子とユニークパーシステント統一名称識別子メニューとの間の関係を確立する手段と、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
前記ターゲットレファレンスを形成する手段と、ここで、ターゲットレファレンスはユニークパーシステント統一名称識別子ディレクトリにおけるユニークパーシステント統一名称識別子記録に格納され、
前記ターゲットコンテンツアセットと前記ターゲットレファレンスへのリンクを有するユニークパーシステント統一名称識別子メニューを作成する手段とを有することを特徴とするシステム。
【請求項２６９】
レファレンス編集のシステムにおいて、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得する手段と、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子記録情報を表示する手段と、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを追加する手段と、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを削除する手段と、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを変更する手段と、
ユニークパーシステント統一名称識別子ディレクトリに更新されたユニークパーシステント統一名称識別子記録情報を格納する手段と、
を有することを特徴とするシステム。
【請求項２７０】
レファレンス分配のシステムにおいて、
ユニークパーシステント統一名称識別子のためのメニュー仕様の要求を受信する手段と、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
前記メニュー仕様をデータベースで検索する手段と、
前記データベースにおいて見つからなければ、ユニークパーシステント統一名称識別子ディレクトリにおいてメタデータからの前記ユニークパーシステント統一名称識別子に対してメニュー仕様を生成する手段と、
前記メニュー仕様をもし生成された場合には前記データベースに格納する手段と、
前記ユニークパーシステント統一名称識別子メニュー仕様からユニークパーシステント統一名称識別子メニューを生成する手段と、ここで、前記ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用され、
要求に応答して前記ユニークパーシステント統一名称識別子メニューを要求クライアントに提供する手段と、
を有することを特徴とするシステム。
【請求項２７１】
インターリンク決定のシステムにおいて、
比較に基づいてターゲットユニークパーシステント統一名称識別子を取得する手段と、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、
ウェブサイトをインデックスクロールしながらターゲットユニークパーシステント統一名称識別子を発見されたユニークパーシステント統一名称識別子と比較する手段と、
ユニークパーシステント統一名称識別子と発見されたユニークパーシステント統一名称識別子との間の照合数と非照合数に着目することによってターゲットユニークパーシステント統一名称識別子のインターリンク度を決定する手段と、
を有することを特徴とするシステム。
【請求項２７２】
メニュー生成のためにプロセッサが可読な媒体において、
前記プロセッサ可読媒体の命令信号を有し、ここで、前記命令信号は前記プロセッサによって発行可能であり、
前記プロセッサは、
コンテンツにアクセスする要求クライアントからユニークパーシステント統一名称識別子の要求を受信し、ここで、前記要求はコンテンツのアクセスと当該コンテンツに埋め込まれたコードから誘起され、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子メニュー仕様を取得し、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、
ユニークパーシステント統一名称識別子メニュー仕様からユニークパーシステント統一名称識別子メニューを生成し、ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用されることを特徴とする媒体。
【請求項２７３】
仕様生成のためにプロセッサが可読な媒体において、
前記プロセッサ可読媒体の命令信号を有し、ここで、前記命令信号は前記プロセッサによって発行可能であり、
前記プロセッサは、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットに関係するコンテンツアイテムへの多重レファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子記録の階層構造に基づいてメニュー仕様を生成することを特徴とする媒体。
【請求項２７４】
レファレンスのためにプロセッサが可読な媒体において、
前記プロセッサ可読媒体の命令信号を有し、ここで、前記命令信号は前記プロセッサによって発行可能であり、
前記プロセッサは、
メタデータフィールドとバリューを取得し、
ユニークパーシステント統一名称識別子メニュー仕様をもし存在すれば取得し、
入手不能であれば、前記メタデータフィールド及びバリューからユニークパーシステント統一名称識別子メニュー仕様を生成し、
メタデータフィールドを前記メニュー仕様におけるフィールドに照合し、
照合されたフィールド及びフィールドバリューに基づいて前記メタデータを検索し、
前記照合されたフィールド及びフィールドバリューに基づいてターゲットレファレンスを形成し、
ユニークパーシステント統一名称識別子ディレクトリにおけるユニークパーシステント統一名称識別子記録に前記ターゲットレファレンスを格納することを特徴とする媒体。
【請求項２７５】
レファレンスのためにプロセッサが可読な媒体において、
前記プロセッサ可読媒体の命令信号を有し、ここで、前記命令信号は前記プロセッサによって発行可能であり、
前記プロセッサは、
ユニークパーシステント統一名称識別子とユニークパーシステント統一名称識別子メニューとの間の関係を確立し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
前記ターゲットレファレンスを形成し、ここで、ターゲットレファレンスはユニークパーシステント統一名称識別子ディレクトリにおけるユニークパーシステント統一名称識別子記録に格納され、
前記ターゲットコンテンツアセットと前記ターゲットレファレンスへのリンクを有するユニークパーシステント統一名称識別子メニューを作成することを特徴とする媒体。
【請求項２７６】
レファレンス編集のためにプロセッサが可読な媒体において、
前記プロセッサ可読媒体の命令信号を有し、ここで、前記命令信号は前記プロセッサによって発行可能であり、
前記プロセッサは、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子記録情報を表示し、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを追加し、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを削除し、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを変更し、
ユニークパーシステント統一名称識別子ディレクトリに更新されたユニークパーシステント統一名称識別子記録情報を格納することを特徴とする媒体。
【請求項２７７】
レファレンス分配のためにプロセッサが可読な媒体において、
前記プロセッサ可読媒体の命令信号を有し、ここで、前記命令信号は前記プロセッサによって発行可能であり、
前記プロセッサは、
ユニークパーシステント統一名称識別子のためのメニュー仕様の要求を受信し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
前記メニュー仕様をデータベースで検索し、
前記データベースにおいて見つからなければ、ユニークパーシステント統一名称識別子ディレクトリにおいてメタデータからの前記ユニークパーシステント統一名称識別子に対してメニュー仕様を生成し、
前記メニュー仕様をもし生成された場合には前記データベースに格納し、
前記ユニークパーシステント統一名称識別子メニュー仕様からユニークパーシステント統一名称識別子メニューを生成し、ここで、前記ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用され、
要求に応答して前記ユニークパーシステント統一名称識別子メニューを要求クライアントに提供することを特徴とする媒体。
【請求項２７８】
インターリンク決定のためにプロセッサが可読な媒体において、
前記プロセッサ可読媒体の命令信号を有し、ここで、前記命令信号は前記プロセッサによって発行可能であり、
前記プロセッサは、
比較に基づいてターゲットユニークパーシステント統一名称識別子を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、
ウェブサイトをインデックスクロールしながらターゲットユニークパーシステント統一名称識別子を発見されたユニークパーシステント統一名称識別子と比較し、
ユニークパーシステント統一名称識別子と発見されたユニークパーシステント統一名称識別子との間の照合数と非照合数に着目することによってターゲットユニークパーシステント統一名称識別子のインターリンク度を決定することを特徴とする媒体。
【請求項２７９】
メニューを生成する装置において、
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するように構成されたプロセッサと、ここで、前記命令は信号を生成し、
当該信号は、
コンテンツにアクセスする要求クライアントからユニークパーシステント統一名称識別子の要求を受信し、ここで、前記要求はコンテンツのアクセスと当該コンテンツに埋め込まれたコードから誘起され、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子メニュー仕様を取得し、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、
ユニークパーシステント統一名称識別子メニュー仕様からユニークパーシステント統一名称識別子メニューを生成し、ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用されることを特徴とする装置。
【請求項２８０】
メニューを生成する装置において、
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するにように構成されたプロセッサと、ここで、前記命令は信号を生成し、
当該信号は、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットに関係するコンテンツアイテムへの多重レファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子記録の階層構造に基づいてメニュー仕様を生成することを特徴とする装置。
【請求項２８１】
メニューを生成する装置において、
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するにように構成されたプロセッサと、ここで、前記命令は信号を生成し、
当該信号は、
メタデータフィールドとバリューを取得し、
ユニークパーシステント統一名称識別子メニュー仕様をもしそれが存在すれば取得し、
入手不能であれば、前記メタデータフィールド及びバリューからユニークパーシステント統一名称識別子メニュー仕様を生成し、
メタデータフィールドを前記メニュー仕様におけるフィールドに照合し、
照合されたフィールド及びフィールドバリューに基づいて前記メタデータを検索し、
前記照合されたフィールド及びフィールドバリューに基づいてターゲットレファレンスを形成し、
ユニークパーシステント統一名称識別子ディレクトリにおけるユニークパーシステント統一名称識別子記録に前記ターゲットレファレンスを格納することを特徴とする装置。
【請求項２８２】
メニューを生成する装置において、
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するにように構成されたプロセッサと、ここで、前記命令は信号を生成し、
当該信号は、
ユニークパーシステント統一名称識別子とユニークパーシステント統一名称識別子メニューとの間の関係を確立し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
前記ターゲットレファレンスを形成し、ここで、ターゲットレファレンスはユニークパーシステント統一名称識別子ディレクトリにおけるユニークパーシステント統一名称識別子記録に格納され、
前記ターゲットコンテンツアセットと前記ターゲットレファレンスへのリンクを有するユニークパーシステント統一名称識別子メニューを作成することを特徴とする装置。
【請求項２８３】
レファレンスを編集する装置において、
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するにように構成されたプロセッサと、ここで、前記命令は信号を生成し、
当該信号は、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子記録情報を表示し、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを追加し、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを削除し、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを変更し、
ユニークパーシステント統一名称識別子ディレクトリに更新されたユニークパーシステント統一名称識別子記録情報を格納することを特徴とする装置。
【請求項２８４】
レファレンスを分配する装置において、
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するにように構成されたプロセッサと、ここで、前記命令は信号を生成し、
当該信号は、
ユニークパーシステント統一名称識別子のためのメニュー仕様の要求を受信し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
前記メニュー仕様をデータベースで検索し、
前記データベースにおいて見つからなければ、ユニークパーシステント統一名称識別子ディレクトリにおいてメタデータからの前記ユニークパーシステント統一名称識別子に対してメニュー仕様を生成し、
前記メニュー仕様をもし生成された場合には前記データベースに格納し、
前記ユニークパーシステント統一名称識別子メニュー仕様からユニークパーシステント統一名称識別子メニューを生成し、ここで、前記ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用され、
要求に応答して前記ユニークパーシステント統一名称識別子メニューを要求クライアントに提供することを特徴とする装置。
【請求項２８５】
インターリンクを決定する装置において、
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するにように構成されたプロセッサと、ここで、前記命令は信号を生成し、
当該信号は、
比較に基づいてターゲットユニークパーシステント統一名称識別子を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、
ウェブサイトをインデックスクロールしながらターゲットユニークパーシステント統一名称識別子を発見されたユニークパーシステント統一名称識別子と比較し、
ユニークパーシステント統一名称識別子と発見されたユニークパーシステント統一名称識別子との間の照合数と非照合数に着目することによってターゲットユニークパーシステント統一名称識別子のインターリンク度を決定することを特徴とする装置。
【請求項２８６】
各メニューアイテムがレファレンスターゲット識別子を有するメニューアイテムの初期階層を作成し、ここで、メニューアイテムは複合媒体を含んでもよく、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされ、
メニュー閲覧者が検討するために前記初期階層を分配し、
前記初期階層のレファレンスターゲット識別子と関連メニューアイテム情報が有効であることを検証し、
前記初期階層の前記メニュー閲覧者の使用の追跡を有効にし、ここで、追跡はメニューアイテムによって作られる幾つかのインプレッションを含み、追跡はメニューアイテムが選択される回数を含み、
使用の追跡に基づいて前記初期階層において前記メニューアイテムを変更し、変更はより人気のあるメニューアイテムをより目立つように配列することを含み、変更は効力を増加するためにメニューアイテムを配置することを含むことを特徴とする方法。
【請求項２８７】
各メニューアイテムがレファレンスターゲット識別子を有するメニューアイテムの初期階層を作成し、
メニュー閲覧者が検討するために前記初期階層を分配し、
前記初期階層のメニュー閲覧者の使用表示を取得し、
前記使用の表示に基づいて前記初期階層において前記メニューアイテムを変更することを含むことを特徴とする方法。
【請求項２８８】
前記初期階層のレファレンスターゲット識別子及び関連メニューアイテム情報が有効であることを検証することを更に有することを特徴とする請求項２８７に記載の方法。
【請求項２８９】
メニューアイテムはグラフィックを含むことできることを特徴とする請求項２８７に記載の方法。
【請求項２９０】
メニューアイテムはビデオを含むことできることを特徴とする請求項２８７に記載の方法。
【請求項２９１】
メニューアイテムはフォームを含むことできることを特徴とする請求項２８７に記載の方法。
【請求項２９２】
メニューアイテムは複合媒体を含むことできることを特徴とする請求項２８７に記載の方法。
【請求項２９３】
メニューアイテムは政府情報に関係することを特徴とする請求項２８７に記載の方法。
【請求項２９４】
メニューアイテムは医療患者情報に関係することを特徴とする請求項２８７に記載の方法。
【請求項２９５】
メニューアイテムはコンテンツ管理情報に関係することを特徴とする請求項２８７に記載の方法。
【請求項２９６】
メニューアイテムはＲＦＩＤ情報に関係することを特徴とする請求項２８７に記載の方法。
【請求項２９７】
メニューアイテムは個人識別情報に関係することを特徴とする請求項２８７に記載の方法。
【請求項２９８】
メニューアイテムは軍事情報に関係することを特徴とする請求項２８７に記載の方法。
【請求項２９９】
メニューアイテムは内部製品情報に関係することを特徴とする請求項２８７に記載の方法。
【請求項３００】
メニューアイテムは外部情報に関係することを特徴とする請求項２８７に記載の方法。
【請求項３０１】
メニューアイテムは書類管理情報に関係することを特徴とする請求項２８７に記載の方法。
【請求項３０２】
メニューアイテムはバックエンドサーバーからの情報を含むことを特徴とする請求項２８７に記載の方法。
【請求項３０３】
前記バックエンドサーバーは知識管理システムであることを特徴とする請求項３０２に記載の方法。
【請求項３０４】
前記メニューアイテムは購入を有効にするリンクであることを特徴とする請求項３０２に記載の方法。
【請求項３０５】
前記メニューアイテムは生きた在庫品を含むことを特徴とする請求項３０２に記載の方法。
【請求項３０６】
前記メニューアイテムの階層はバナー広告によって引き起こされることを特徴とする請求項２８７に記載の方法。
【請求項３０７】
前記メニューアイテムの階層はスポンサー広告リンクによって引き起こされることを特徴とする請求項２８７に記載の方法。
【請求項３０８】
前記メニューアイテムの階層は書類によって引き起こされることを特徴とする請求項２８７に記載の方法。
【請求項３０９】
前記メニューアイテムの階層はメディアプレーヤーによって引き起こされることを特徴とする請求項２８７に記載の方法。
【請求項３１０】
前記初期階層はコンサルタントによって選択されるメニューアイテムを有することを特徴とする請求項２８７に記載の方法。
【請求項３１１】
前記コンサルタントは市場分析であることを特徴とする請求項３１０に記載の方法。
【請求項３１２】
前記閲覧者の使用表示はユーザーの購入行為を含むことを特徴とする請求項２８７に記載の方法。
【請求項３１３】
前記閲覧者の使用表示は独立して記録されるユーザーの嗜好情報を含むことを特徴とする請求項２８７に記載の方法。
【請求項３１４】
前記閲覧者の使用表示はユーザーの範疇に関連付けられた、独立して記録されるユーザーの嗜好情報を含むことを特徴とする請求項２８７に記載の方法。
【請求項３１５】
前記ユーザーの範疇は収入、利益、人口統計、嗜好によってユーザーの嗜好をプロファイルする匿名メトリックスのいかなるものをも含むことを特徴とする請求項３１４に記載の方法。
【請求項３１６】
前記閲覧者の使用表示は前記メニューをホストするサイトによって記録されるメトリックスを含むことを特徴とする請求項２８７に記載の方法。
【請求項３１７】
前記メトリックスは、日時に基づいてプロファイルすることを含むことを特徴とする請求項２８７に記載の方法。
【請求項３１８】
前記メトリックスは、サイト訪問者の地理的場所を含むことを特徴とする請求項３１６に記載の方法。
【請求項３１９】
前記閲覧者の使用表示は前記初期階層の前記メニュー閲覧者の使用の追跡によって有効とされることを特徴とする請求項２８７に記載の方法。
【請求項３２０】
追跡はメニューアイテムによって作られた幾つかのインプレッションを含むことを特徴とする請求項３１９に記載の方法。
【請求項３２１】
追跡はメニューアイテムが選択される回数を含むことを特徴とする請求項３１９に記載の方法。
【請求項３２２】
追跡はメニューアイテムが考慮される時間量を含むことを特徴とする請求項３１９に記載の方法。
【請求項３２３】
追跡はメニューアイテム上を通過された回数を含むことを特徴とする請求項３１９に記載の方法。
【請求項３２４】
変更は自動的に行われることを特徴とする請求項２８７に記載の方法。
【請求項３２５】
変更は手動で行われることを特徴とする請求項２８７に記載の方法。
【請求項３２６】
手動変更はメニューエディタにより行われることを特徴とする請求項３２５に記載の方法。
【請求項３２７】
メニューエディタは追跡統計を表示することを特徴とする請求項３２６に記載の方法。
【請求項３２８】
前記追跡統計は、メニューアイテムによって作られた幾つかのインプレッション、メニューアイテムが選択された回数、メニューアイテムが検討された時間量、メニューアイテム上を通過された回数のいかなるものをも含むことを特徴とする請求項３２７に記載の方法。
【請求項３２９】
前記メニューエディタはメニューアイテムが使用可能となる方法を制限する使用量制限を表示することを特徴とする請求項３２７に記載の方法。
【請求項３３０】
前記使用制限は、メニューアイテムによって作られた幾つかのインプレッション、メニューアイテムが選択された回数、メニューアイテムが検討された時間量、メニューアイテム上を通過された回数のいかなるものをも含むことを特徴とする請求項３２９に記載の方法。
【請求項３３１】
変更は、より人気のあるメニューアイテムをより目立つように配置することを含むことを特徴とする請求項２８７に記載の方法。
【請求項３３２】
より目立つようにすることは、メニュー階層におけるより高い配置、メニュー階層の層内におけるより高い配置のうちのいかなるものをも含むことを特徴とする請求項２８７に記載の方法。
【請求項３３３】
より人気のあるメニューアイテムはより頻繁に選択されてきたメニューアイテムであることを特徴とする請求項３３１に記載の方法。
【請求項３３４】
変更は人気の少ないメニューアイテムをより目立つように配置することを含むことを特徴とする請求項２８７に記載の方法。
【請求項３３５】
変更はメニューアイテムのスポンサー広告の配置を含むことを特徴とする請求項２８７に記載の方法。
【請求項３３６】
変更はコンテキストに基づいてメニューアイテムを配置することを含むことを特徴とする請求項３３５に記載の方法。
【請求項３３７】
変更は前記スポンサー広告の効率を増加するために前記メニューアイテムを配置することを含むことを特徴とする請求項３３５に記載の方法。
【請求項３３８】
変更は追跡を通じて最も効果的であると決定された場所においてスポンサー広告を配置することを含むことを特徴とする請求項３３５に記載の方法。
【請求項３３９】
スポンサー広告の配置はコンテキストに基づいていることを特徴とする請求項３３５に記載の方法。
【請求項３４０】
スポンサー広告の配置は広告配置のより高い指値に基づいていることを特徴とする請求項３３５に記載の方法。
【請求項３４１】
スポンサー広告の配置はより目立つことを特徴とする請求項３３５に記載の方法。
【請求項３４２】
スポンサー広告の配置は使用制限を受け易いことを特徴とする請求項３３５に記載の方法。
【請求項３４３】
変更は効率を増加するために前記メニューアイテムを配置することを含むことを特徴とする請求項２８７に記載の方法。
【請求項３４４】
変更は効率を増加するために前記メニューアイテムを配置することを含むことを特徴とする請求項２８７に記載の方法。
【請求項３４５】
スポンサー広告の配置はコンテキストに基づいていることを特徴とする請求項２８７に記載の方法。
【請求項３４６】
コンテキストはメニューアイテムの階層内の他のメニューアイテムに基づいていることを特徴とする請求項３４５に記載の方法。
【請求項３４７】
前記コンテキストはメニューアイテムの階層においてメニューアイテムによってターゲットにされたレファレンスのコンテンツに基づいていることを特徴とする請求項３４５に記載の方法。
【請求項３４８】
前記コンテキストはメニューアイテムの階層においてメニューアイテムによってターゲットにされたレファレンスのコンテンツに基づいていることを特徴とする請求項３４５に記載の方法。
【請求項３４９】
プロセッサが実行する方法において、
コンテンツにアクセスする要求クライアントからユニークパーシステント統一名称識別子の要求を受信し、ここで、前記要求はコンテンツのアクセスから誘起され、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子メニュー仕様を取得し、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、
前記ユニークパーシステント統一名称識別子メニュー仕様からメニューアイテムのユニークパーシステント統一名称識別子階層を生成し、ここで、前記ユニークパーシステント統一名称識別子メニュー仕様は前記ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用され、メニューアイテムは複合媒体を含んでもよく、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、
前記メニューアイテムの階層は広告によって引き起こされ、
前記ユニークパーシステント統一名称識別子メニューのレファレンスターゲット識別子と関連メニューアイテム情報が有効であることを検証し、
エンドユーザーからユニークパーシステント統一名称識別子メニュー仕様の追跡を有効にし、追跡はメニューアイテムによって作られた幾つかのインプレッションを含み、追跡はメニューアイテムが選択された回数を含み、
前記使用の追跡に基づいてユニークパーシステント統一名称識別子メニューアイテムを変更し、変更はより人気のあるメニューアイテムをより目立つように配置することを含み、変更は効率を増加するためにメニューアイテムを配置することを含むことを特徴とする方法。
【請求項３５０】
プロセッサが実行する方法において、
コンテンツにアクセスする要求クライアントからユニークパーシステント統一名称識別子の要求を受信し、ここで、前記要求はコンテンツのアクセスから誘起され、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子メニュー仕様を取得し、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、
前記ユニークパーシステント統一名称識別子メニュー仕様からメニューアイテムのユニークパーシステント統一名称識別子階層を生成し、ここで、前記ユニークパーシステント統一名称識別子メニュー仕様は前記ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用され、
エンドユーザーからユニークパーシステント統一名称識別子メニュー仕様の追跡を有効にし、
前記使用の追跡に基づいてユニークパーシステント統一名称識別子メニューアイテムを変更することを特徴とする方法。
【請求項３５１】
前記初期階層のレファレンスターゲット識別子及び関連メニューアイテム情報が有効であることを検証することを更に有することを特徴とする請求項３５０に記載の方法。
【請求項３５２】
メニューアイテムはグラフィックを含むことできることを特徴とする請求項３５０に記載の方法。
【請求項３５３】
メニューアイテムはビデオを含むことできることを特徴とする請求項３５０に記載の方法。
【請求項３５４】
メニューアイテムはフォームを含むことできることを特徴とする請求項３５０に記載の方法。
【請求項３５５】
メニューアイテムは複合媒体を含むことできることを特徴とする請求項３５０に記載の方法。
【請求項３５６】
メニューアイテムはバックエンドサーバーからの情報を含むことできることを特徴とする請求項３５０に記載の方法。
【請求項３５７】
前記メニューアイテムは購入を有効にするリンクであることを特徴とする請求項３５６に記載の方法。
【請求項３５８】
前記メニューアイテムは生きた在庫品を含むことを特徴とする請求項３５６に記載の方法。
【請求項３５９】
前記メニューアイテムの階層はバナー広告によって引き起こされることを特徴とする請求項３５０に記載の方法。
【請求項３６０】
前記メニューアイテムの階層はスポンサー広告リンクによって引き起こされることを特徴とする請求項３５０に記載の方法。
【請求項３６１】
前記メニューアイテムの階層は書類によって引き起こされることを特徴とする請求項３５０に記載の方法。
【請求項３６２】
前記メニューアイテムの階層はメディアプレーヤーによって引き起こされることを特徴とする請求項３５０に記載の方法。
【請求項３６３】
前記初期階層はコンサルタントによって選択されるメニューアイテムを有することを特徴とする請求項３５０に記載の方法。
【請求項３６４】
前記コンサルタントは市場分析であることを特徴とする請求項３６３に記載の方法。
【請求項３６５】
追跡はメニューアイテムによって作られた幾つかのインプレッションを含むことを特徴とする請求項３５０に記載の方法。
【請求項３６６】
追跡はメニューアイテムが選択される回数を含むことを特徴とする請求項３１９に記載の方法。
【請求項３６７】
追跡はメニューアイテムが考慮される時間量を含むことを特徴とする請求項３５０に記載の方法。
【請求項３６８】
追跡はメニューアイテム上を通過された回数を含むことを特徴とする請求項３５０に記載の方法。
【請求項３６９】
変更は自動的に行われることを特徴とする請求項３５０に記載の方法。
【請求項３７０】
変更は手動で行われることを特徴とする請求項３５０に記載の方法。
【請求項３７１】
手動変更はメニューエディタにより行われることを特徴とする請求項３７０に記載の方法。
【請求項３７２】
メニューエディタは追跡統計を表示することを特徴とする請求項３７１に記載の方法。
【請求項３７３】
前記追跡統計は、メニューアイテムによって作られた幾つかのインプレッション、メニューアイテムが選択された回数、メニューアイテムが検討された時間量、メニューアイテム上を通過された回数のいかなるものをも含むことを特徴とする請求項３７２に記載の方法。
【請求項３７４】
前記メニューエディタはメニューアイテムが使用可能となる方法を制限する使用量制限を表示することを特徴とする請求項３７１に記載の方法。
【請求項３７５】
前記使用制限は、メニューアイテムによって作られた幾つかのインプレッション、メニューアイテムが選択された回数、メニューアイテムが検討された時間量、メニューアイテム上を通過された回数のいかなるものをも含むことを特徴とする請求項３７４に記載の方法。
【請求項３７６】
変更は、より人気のあるメニューアイテムをより目立つように配置することを含むことを特徴とする請求項２８７に記載の方法。
【請求項３７７】
より目立つようにすることは、メニュー階層におけるより高い配置、メニュー階層の層内におけるより高い配置の幾つかのうちのいかなるものをも含むことを特徴とする請求項３５０に記載の方法。
【請求項３７８】
より人気のあるメニューアイテムは、より頻繁に選択されてきたメニューアイテムであることを特徴とする請求項３７６に記載の方法。
【請求項３７９】
変更は人気の少ないメニューアイテムをより目立つように配列することを含むことを特徴とする請求項３５０に記載の方法。
【請求項３８０】
変更はメニューアイテムのスポンサー広告の配置を含むことを特徴とする請求項３５０に記載の方法。
【請求項３８１】
変更は状況に基づいてメニューアイテムを配置することを含むことを特徴とする請求項３８０に記載の方法。
【請求項３８２】
変更は前記スポンサー広告の効率を増加するために前記メニューアイテムを配置することを含むことを特徴とする請求項３８０に記載の方法。
【請求項３８３】
変更は追跡を通じて最も効果的であると決定された場所においてスポンサー広告を配置することを含むことを特徴とする請求項３８０に記載の方法。
【請求項３８４】
スポンサー広告の配置はコンテキストに基づいていることを特徴とする請求項３８０に記載の方法。
【請求項３８５】
スポンサー広告の配置は広告配置のより高い指値に基づいていることを特徴とする請求項３８０に記載の方法。
【請求項３８６】
スポンサー広告の配置はより顕著であることを特徴とする請求項３８０に記載の方法。
【請求項３８７】
スポンサー広告の配置は使用制限を受け易いことを特徴とする請求項３８０に記載の方法。
【請求項３８８】
変更は効率を増加するために前記メニューアイテムを配置することを含むことを特徴とする請求項３５０に記載の方法。
【請求項３８９】
スポンサー広告の配置はコンテキストに基づいていることを特徴とする請求項３５０に記載の方法。
【請求項３９０】
コンテキストはメニューアイテムの階層内で他のメニューアイテムに基づいていることを特徴とする請求項３８９に記載の方法。
【請求項３９１】
前記コンテキストはメニューアイテムの階層においてメニューアイテムによってターゲットにされたレファレンスのコンテンツに基づいていることを特徴とする請求項３８９に記載の方法。
【請求項３９２】
前記コンテキストはメニューアイテムの階層においてメニューアイテムによってターゲットにされたレファレンスのコンテンツに基づいていることを特徴とする請求項３８９に記載の方法。
【請求項３９３】
プロセッサが実行する方法において、購入サイクルを圧縮する階層メニューを生成することを特徴とする方法。
【請求項３９４】
ユーザーインターフェースを生成する、プロセッサが実行する方法において、
メニューアイテムの階層を生成するトリガーと共に埋め込まれた関与コンテンツに応答してメニューアイテムの使用を追跡し、ユーザーからのフィードバックとメニュー仕様からメニューアイテムの階層を生成し、メニューアイテムは複合媒体を含むことができ、メニューアイテムはバックエンドサーバーからの情報を含むことができ、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされることを特徴とする方法。
【請求項３９５】
ユーザーインターフェースを生成する、プロセッサが実行する方法において、
メニューアイテムの階層を生成するトリガーと共に埋め込まれた関与コンテンツに応答してメニューアイテムの使用を追跡し、ユーザーからのフィードバックとメニュー仕様からメニューアイテムの階層を生成することを特徴とする方法。
【請求項３９６】
メニューアイテムはグラフィックを含むことできることを特徴とする請求項３９５に記載の方法。
【請求項３９７】
メニューアイテムはビデオを含むことできることを特徴とする請求項３９５に記載の方法。
【請求項３９８】
メニューアイテムはフォームを含むことできることを特徴とする請求項３９５に記載の方法。
【請求項３９９】
メニューアイテムは複合媒体を含むことできることを特徴とする請求項３９５に記載の方法。
【請求項４００】
メニューアイテムはバックエンドサーバーからの情報を含むことできることを特徴とする請求項３９５に記載の方法。
【請求項４０１】
前記メニューアイテムは購入を有効にするリンクであることを特徴とする請求項４００に記載の方法。
【請求項４０２】
前記メニューアイテムは生きた在庫品を含むことを特徴とする請求項４００に記載の方法。
【請求項４０３】
前記メニューアイテムの階層はバナー広告によって引き起こされることを特徴とする請求項３９５に記載の方法。
【請求項４０４】
前記メニューアイテムの階層はスポンサー広告リンクによって引き起こされることを特徴とする請求項３９５に記載の方法。
【請求項４０５】
前記メニューアイテムの階層は書類によって引き起こされることを特徴とする請求項３９５に記載の方法。
【請求項４０６】
前記メニューアイテムの階層はメディアプレーヤーによって引き起こされることを特徴とする請求項３９５に記載の方法。
【請求項４０７】
ユーザーインターフェースを生成する、プロセッサが実行する方法において、
セグメント選択部とターゲット中間層階層メニューを識別する情報を含む第１層の階層メニューレベルを生成し、
ブランド選択部とターゲット後層階層メニューを識別する情報を含む中間層の階層メニューレベルを生成し、
情報とターゲット同一ブランド取引を含む後層階層メニューレベルを生成し、
メニューアイテムは階層内に複合媒体を含んでもよく、前記メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、メニューアイテムの階層は広告によって引き起こされることを特徴とする方法。
【請求項４０８】
ユーザーインターフェースを生成する、プロセッサが実行する方法において、
セグメント選択部とターゲット中間層階層メニューを識別する情報を含む第１層の階層メニューレベルを生成し、
ブランド選択部とターゲット後層階層メニューを識別する情報を含む中間層の階層メニューレベルを生成し、
情報とターゲット同一ブランド取引を含む後層階層メニューレベルを生成することを特徴とする方法。
【請求項４０９】
メニューアイテムはグラフィックを含むことできることを特徴とする請求項４０８に記載の方法。
【請求項４１０】
メニューアイテムはビデオを含むことできることを特徴とする請求項４０８に記載の方法。
【請求項４１１】
メニューアイテムはフォームを含むことできることを特徴とする請求項４０８に記載の方法。
【請求項４１２】
メニューアイテムは複合媒体を含むことできることを特徴とする請求項４０８に記載の方法。
【請求項４１３】
メニューアイテムはバックエンドサーバーからの情報を含むことできることを特徴とする請求項４０８に記載の方法。
【請求項４１４】
前記メニューアイテムは購入を有効にするリンクであることを特徴とする請求項４１３に記載の方法。
【請求項４１５】
前記メニューアイテムは生きた在庫品を含むことを特徴とする請求項４１３に記載の方法。
【請求項４１６】
前記メニューアイテムの階層はバナー広告によって引き起こされることを特徴とする請求項４０８に記載の方法。
【請求項４１７】
前記メニューアイテムの階層はスポンサー広告リンクによって引き起こされることを特徴とする請求項４０８に記載の方法。
【請求項４１８】
前記メニューアイテムの階層は書類によって引き起こされることを特徴とする請求項４０８に記載の方法。
【請求項４１９】
前記メニューアイテムの階層はメディアプレーヤーによって引き起こされることを特徴とする請求項４０８に記載の方法。
【請求項４２０】
メニューを作成するシステムにおいて、購入サイクルを圧縮する階層メニューを生成することを特徴とするシステム。
【請求項４２１】
メニューを作成するシステムにおいて、
各メニューアイテムがレファレンスターゲット識別子を有するメニューアイテムの初期階層を作成する手段と、ここで、メニューアイテムは複合媒体を含むことができ、メニューアイテムはバックエンドサーバーからの情報を含むことができ、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされ、
メニュー閲覧者が検討するために前記初期階層を分配する手段と、
前記初期階層のレファレンスターゲット識別子と関連メニューアイテム情報が有効であることを検証する手段と、
前記初期階層の前記メニュー閲覧者の使用の追跡を有効にする手段と、ここで、追跡はメニューアイテムによって作られる幾つかのインプレッションを含み、追跡はメニューアイテムが選択される回数を含み、
使用の追跡に基づいて前記初期階層において前記メニューアイテムを変更する手段と、変更はより人気のあるメニューアイテムをより目立つように配列することを含み、変更は効力を増加するためにメニューアイテムを配置することを含むことを特徴とする方法。
【請求項４２２】
メニューを作成するシステムにおいて、
コンテンツにアクセスする要求クライアントからユニークパーシステント統一名称識別子の要求を受信する手段と、ここで、前記要求はコンテンツのアクセスから誘起され、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子メニュー仕様を取得する手段と、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得する手段と、
ユニークパーシステント統一名称識別子メニュー仕様からユニークパーシステント統一名称識別子メニューを生成する手段と、ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用され、メニューアイテムは複合媒体を含む場合があり、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされ、
前記初期階層のレファレンスターゲット識別子と関連メニューアイテム情報が有効であることを検証する手段と、
エンドユーザーからユニークパーシステント統一名称識別子メニュー仕様の追跡を有効にする手段と、追跡はメニューアイテムによって作られた幾つかのインプレッションを含み、追跡はメニューアイテムが選択された回数を含み、
前記使用の追跡に基づいてユニークパーシステント統一名称識別子メニューアイテムを変更する手段と、変更はより人気のあるメニューアイテムをより目立つように配置することを含み、変更は効率を増加するためにメニューアイテムを配置することを含むことを特徴とするシステム。
【請求項４２３】
ユーザーインターフェースを生成するシステムにおいて、
メニューアイテムの階層の生成のためのトリガーと共に埋め込まれた関与コンテンツに応答してメニューアイテムの使用を追跡し、ユーザーからのフィードバックとメニュー仕様からメニューアイテムの階層を生成する手段を有し、
メニューアイテムは複合媒体を含む場合があり、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされることを特徴とするシステム。
【請求項４２４】
ユーザーインターフェースを生成するシステムにおいて、
セグメント選択部とターゲット中間層階層メニューを識別する情報を含む第１層の階層メニューレベルを生成する手段と、
ブランド選択部とターゲット後層階層メニューを識別する情報を含む中間層の階層メニューレベルを生成する手段と、
情報とターゲット同一ブランド取引を含む後層階層メニューレベルを生成する手段とを有し、
メニューアイテムは複合媒体を含む場合があり、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされることを特徴とするシステム。
【請求項４２５】
インターラクションインターフェースを使用するためにプロセッサが可読な媒体において、
前記プロセッサが可読な媒体に命令信号を有し、当該命令信号は購入サイクルを圧縮する階層メニューを使用するためにユーザーとシステムイベントシグナルに応答して前記プロセッサによって発行可能であることを特徴とする媒体。
【請求項４２６】
メニューを作成するためにプロセッサが可読な媒体において、
前記プロセッサが可読な媒体に命令信号を有し、当該命令信号は前記プロセッサによって発行可能であり、
当該プロセッサは、
各メニューアイテムがレファレンスターゲット識別子を有するメニューアイテムの初期階層を作成し、ここで、メニューアイテムは複合媒体を含んでもよく、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされ、
メニュー閲覧者が検討するために前記初期階層を分配し、
前記初期階層のレファレンスターゲット識別子と関連メニューアイテム情報が有効であることを検証し、
前記初期階層の前記メニュー閲覧者の使用の追跡を有効にし、ここで、追跡はメニューアイテムによって作られる幾つかのインプレッションを含み、追跡はメニューアイテムが選択される回数を含み、
使用の追跡に基づいて前記初期階層において前記メニューアイテムを変更し、変更はより人気のあるメニューアイテムをより目立つように配置することを含み、変更は効力を増加するためにメニューアイテムを配置することを含むことを特徴とする媒体。
【請求項４２７】
メニューを作成するためにプロセッサが可読な媒体において、
前記プロセッサが可読な媒体に命令信号を有し、当該命令信号は前記プロセッサによって発行可能であり、
当該プロセッサは、
コンテンツにアクセスする要求クライアントからユニークパーシステント統一名称識別子の要求を受信し、ここで、前記要求はコンテンツのアクセスから誘起され、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子メニュー仕様を取得し、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、
前記ユニークパーシステント統一名称識別子メニュー仕様からメニューアイテムのユニークパーシステント統一名称識別子階層を生成し、ここで、前記ユニークパーシステント統一名称識別子メニュー仕様は前記ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用され、メニューアイテムは複合媒体を含んでもよく、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされ、
前記ユニークパーシステント統一名称識別子メニューのレファレンスターゲット識別子と関連メニューアイテム情報が有効であることを検証し、
エンドユーザーからユニークパーシステント統一名称識別子メニュー仕様の追跡を有効にし、追跡はメニューアイテムによって作られた幾つかのインプレッションを含み、追跡はメニューアイテムが選択された回数を含み、
前記使用の追跡に基づいてユニークパーシステント統一名称識別子メニューアイテムを変更し、変更はより人気のあるメニューアイテムをより目立つように配置することを含み、変更は効率を増加するためにメニューアイテムを配置することを含むことを特徴とする媒体。
【請求項４２８】
インターラクションインターフェースを使用するプロセッサが可読な媒体において、
前記プロセッサが可読な媒体に命令信号を有し、当該命令信号はユーザーとシステムイベント信号に応答して前記プロセッサによって発行可能であり、
メニューアイテムの階層を発生するためのトリガーと共に埋め込まれた関与コンテンツに応答してメニューアイテムの使用を追跡し、ユーザーからのフィードバックとメニュー仕様からメニューアイテムの階層を引き起こし、
メニューアイテムは複合媒体を含んでもよく、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされることを特徴とする媒体。
【請求項４２９】
インターラクションインターフェースを使用するプロセッサが可読な媒体において、
前記プロセッサが可読な媒体に命令信号を有し、当該命令信号はユーザーとシステムイベント信号に応答して前記プロセッサによって発行可能であり、
メニューアイテムの階層を発生するためのトリガーと共に埋め込まれた関与コンテンツに応答してメニューアイテムの使用を追跡し、ユーザーからのフィードバックとメニュー仕様からメニューアイテムの階層を生成することを特徴とする媒体。
【請求項４３０】
インターラクションインターフェースを使用するプロセッサが可読な媒体において、
前記プロセッサが可読な媒体に命令信号を有し、当該命令信号はユーザーとシステムイベント信号に応答して前記プロセッサによって発行可能であり、
セグメント選択部とターゲット中間層階層メニューを識別する情報を含む第１層の階層メニューレベルと、
ブランド選択部とターゲット後層階層メニューを識別する情報を含む中間層の階層メニューレベルと、
情報とターゲット同一ブランド取引を含む後層階層メニューレベルとを引き起こし、
メニューアイテムは複合媒体を含む場合があり、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされることを特徴とする媒体。
【請求項４３１】
インターラクションインターフェースを使用するプロセッサが可読な媒体において、
前記プロセッサが可読な媒体に命令信号を有し、当該命令信号はユーザーとシステムイベント信号に応答して前記プロセッサによって発行可能であり、
前記プロセッサが可読な媒体に命令信号を有し、当該命令信号はユーザーとシステムイベント信号に応答して前記プロセッサによって発行可能であり、
セグメント選択部とターゲット中間層階層メニューを識別する情報を含む第１層の階層メニューレベルと、
ブランド選択部とターゲット後層階層メニューを識別する情報を含む中間層の階層メニューレベルと、
情報とターゲット同一ブランド取引を含む後層階層メニューレベルとを使用することを特徴とする媒体。
【請求項４３２】
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するように構成されたプロセッサとを有し、
前記命令は購入サイクルを圧縮する階層メニューを使用するためにユーザー及びシステムイベント信号に応答して前記プロセッサによって発行可能であることを特徴とする装置。
【請求項４３３】
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するように構成されたプロセッサとを有し、
前記命令は信号を発行し、当該信号は、
各メニューアイテムがレファレンスターゲット識別子を有するメニューアイテムの初期階層を作成し、ここで、メニューアイテムは複合媒体を含んでもよく、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされ、
メニュー閲覧者が検討するために前記初期階層を分配し、
前記初期階層のレファレンスターゲット識別子と関連メニューアイテム情報が有効であることを検証し、
前記初期階層の前記メニュー閲覧者の使用の追跡を有効にし、ここで、追跡はメニューアイテムによって作られる幾つかのインプレッションを含み、追跡はメニューアイテムが選択される回数を含み、
使用の追跡に基づいて前記初期階層において前記メニューアイテムを変更し、変更はより人気のあるメニューアイテムをより顕著に配列することを含み、変更は効力を増加するためにメニューアイテムを配置することを含むことを特徴とする装置。
【請求項４３４】
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するように構成されたプロセッサとを有し、
前記命令は信号を発行し、当該信号は、
コンテンツにアクセスする要求クライアントからユニークパーシステント統一名称識別子の要求を受信し、ここで、前記要求はコンテンツのアクセスから誘起され、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子メニュー仕様を取得し、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、
前記ユニークパーシステント統一名称識別子メニュー仕様からメニューアイテムのユニークパーシステント統一名称識別子階層を生成し、ここで、前記ユニークパーシステント統一名称識別子メニュー仕様は前記ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用され、メニューアイテムは複合媒体を含んでもよく、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされ、
前記ユニークパーシステント統一名称識別子メニューのレファレンスターゲット識別子と関連メニューアイテム情報が有効であることを検証し、
エンドユーザーからユニークパーシステント統一名称識別子メニュー仕様の追跡を有効にし、追跡はメニューアイテムによって作られた幾つかのインプレッションを含み、追跡はメニューアイテムが選択された回数を含み、
前記使用の追跡に基づいてユニークパーシステント統一名称識別子メニューアイテムを変更し、変更はより人気のあるメニューアイテムをより目立つように配置することを含み、変更は効率を増加するためにメニューアイテムを配置することを含むことを特徴とする装置。
【請求項４３５】
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するように構成されたプロセッサとを有し、
前記命令は信号を発行し、当該信号は、
ユーザーとシステムイベント信号に応答して前記プロセッサによって発行可能であり、メニューアイテムの階層を使用するためのトリガーと共に埋め込まれた関与コンテンツに応答してのメニューアイテムの使用を追跡するユーザーからのフィードバックからとメニュー仕様からメニューアイテムの階層を使用することを特徴とする装置。
【請求項４３６】
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するように構成されたプロセッサとを有し、
前記命令はユーザー及びシステムイベント信号に応答して前記プロセッサによって発行可能であり、
セグメント選択部とターゲット中間層階層メニューを識別する情報を含む第１層の階層メニューレベルと、
ブランド選択部とターゲット後層階層メニューを識別する情報を含む中間層の階層メニューレベルと、
情報とターゲット同一ブランド取引を含む後層階層メニューレベルとを引き起こし、
メニューアイテムは複合媒体を含んでもよく、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされることを特徴とする装置。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願）
本出願は、２００１年２月１４日に米国特許商標庁に提出された仮特許出願番号第６０／２６８，７６６号、名称「情報アクセスに作用する多重解決用の装置、方法及びシステム」を、ここで参照して結合する。
【０００２】
また、本出願は、２００３年７月２４日に米国特許商標庁に提出された特許出願番号第１０／４７０，２０６号、名称「ピア環境における情報アクセス用の装置、方法及びシステム」を、ここで参照して結合する。
【０００３】
また、本出願は、２００３年７月２４日に米国特許商標庁に提出された特許出願番号第１０／４７０，２０７号、名称「ディレクトリ品質保証用の装置、方法及びシステム」を、ここで参照して結合する。
【０００４】
また、本出願は、２００３年７月２４日に米国特許商標庁に提出された特許出願番号第１０／４７０，２５８号、名称「デジタル管理情報にアクセスする装置、方法及びシステム」を、ここで参照して結合する。
【０００５】
また、本出願は、２００５年１月１１日に米国特許商標庁に提出された一部継続特許出願番号第６０／６４２，８０９号、名称「相互に関係するユニークパーシステント統一資源識別子、メニュー及び情報を保証、編集及び配置する装置、方法及びシステム」である。上述の出願の内容をここで明示的にレファレンスして結合する。
【０００６】
また、本出願は、２００５年１０月１４日に米国特許商標庁に提出された一部継続特許出願番号第６０／７２６，６８９号、名称「統合、情報処理及び自己改善広告、電子商取引及びオンラインクライアントインターラクションのための装置、方法及びシステム」である。上述の出願の内容をここで明示的にレファレンスして結合する。
【０００７】
本発明は一般に通信ネットワークの情報にアクセスする装置、方法及びシステムに係る。特に、開示された発明は、広告、電子商取引及びオンラインクライアントインターラクション（ＩＳＩＣＩ）のための統合、情報処理及び自己改善ファシリティへの装置、方法及びシステムに関する。
【背景技術】
【０００８】
インターネット
インターネットの利用が増えるにつれて、インターネット上で利用可能な情報の量も増加する。インターネット上に存在する情報は、コンピュータ・ソフトウェア、データベース、検討リスト、電子ジャーナル、ライブラリ・カタログ、オンライン情報サービス、メーリング・リスト、ニュース・グループ、ストリーミング・メディア等、数多くのフォーマットのドキュメントを含む様々な種類のものがある。幸いにもインターネット上のほとんどの情報には、ユーザーが利用しやすい方法でネットワークとインターラクションするためのウェブ・ブラウザーを用いワールド・ワイド・ウェブを介してアクセスすることができる。
【０００９】
ネットワーク
一般にネットワークは、クライアント、ピア、サーバー及びグラフ・トポロジーにおける中間のノードの相互接続と相互運用から成ると考えられている。注意すべきことは、ここでは「サーバー」という用語は通常、しばしば通信ネットワーク全体から、クライアントの要求を処理したりそれに応答したりするためのコンピュータ、その他の機器、ソフトウェア、及び／又は、それらの組み合わせを指すということである。また、「クライアント」の用語は一般にコンピュータ、その他の装置、ソフトウェア、ユーザー、及び／又は、役務要求を生成するその組み合わせを意味する。一般に、「クライアント」及び「ユーザー」の用語は相互に交換可能で同様に使用される。また、サーバーは要求するクライアントに情報を提供する。情報及び要求を促進処理及び／又はソース・ユーザーからデスティネーション・ユーザーへの情報の流れを支援するコンピュータ、その他の装置、ソフトウェア又はそれらの組み合わせは、通常「ノード」と呼ばれる。ネットワークは一般にソースポイントからデスティネーションへの情報の転送を促進するものと考えられている。
【００１０】
伝送制御プロトコル‐インターネット・プロトコル（ＴＣＰ／ＩＰ）
コンピュータ・システム、データベース及びコンピュータ・ネットワークの拡散と拡大は、一般的にインターネットと称されるそのようなシステムの相互接続と国境を越えた通信ネットワークによって促進されてきた。インターネットは伝送制御プロトコルとインターネット・プロトコル（ＴＣＰ／ＩＰ）を発展させ、またその大部分においてそれらを用いている。ＴＣＰ／ＩＰは様々な変化するネットワーク業者によって形成された複数のネットワークを、ネットワークのための基礎として相互接続するための、つまりインターネットのための米国国防総省（ＤｏＤ）の研究プロジェクトによって開発された。一つにはＤｏＤが、戦闘の最中に損害を受けても作動し続けることによって、通信ネットワークの損害を受けた部分を回避してデスティネーション・アドレスに情報を送るネットワークを必要としたことがＴＣＰ／ＩＰの開発の原動力となった。もちろん、ソース・アドレスの場所又はデスティネーション・アドレスの場所自体が動作不能になった場合は、そのような伝達は不可能である。
【００１１】
インターネットはパケット交換型のネットワークであるため、インターネット上の情報はパケットと呼ばれる幾つもの断片に分割され、パケット形式で送信される。パケットはヘッダーと呼ばれるＩＰアドレス情報を含み、それらはルーターがインターネット上の中間ノードを通してパケットをソースからデスティネーションへ配信することを可能にする。デスティネーションに到着すると、パケットは再構築されオリジナルのメッセージを形成し、欠落しているパケットがあれば、それらは再び要求される。
【００１２】
プロトコルのＩＰ部分は、４バイトのアドレス・メカニズムに基づいて情報パケットをルーティングする役目を担う。アドレスはドットによって分離された４つの数字であり、各数字は０から２５５の範囲内で、例えば、「１２３．２５５．０．１２３」というようになる。ＩＰアドレスはインターネット当局及び登録機関が指定し、それぞれ固有のものである。
【００１３】
プロトコルのＴＣＰ部分は情報のパケットがソースからデスティネーションに正確に受信されたかを確認し、またもし正確に受信されなかった場合は、間違ったパケットを再送信するために用いられる。ユーザー・データグラム・プロトコル（ＵＤＰ）等の、配信を保証しないその他の伝送制御プロトコルも一般的に利用されている。
【００１４】
ワールド・ワイド・ウェブ
インターネット、特にワールド・ワイド・ウェブ（ウェブ）が広く受け入れられ拡大し、膨大且つ多様な情報が集められた。情報技術システムを有するユーザー同士（つまりコンピュータ利用者）のインターラクションを可能にする様々なユーザー・インターフェースが現在利用されている。ＷｏｒｌｄＷｉｄｅＷｅｂ．ａｐｐ（ウェブ）と呼ばれる情報ナビゲーション・インターフェースは、１９９０年後半に開発された。その後、ウェブ・ブラウザー等の情報ナビゲーション・インターフェースがほぼ全てのコンピュータ・オペレーティング・システム・プラットフォームにおいて広く利用可能になった。
【００１５】
一般にウェブは、複数のユーザー・インターフェース（例えばウェブ・ブラウザー）、サーバー、配信された情報、プロトコル及び仕様の、相乗相互運用の発現でありその結果である。ウェブ・ブラウザーは情報へのナビゲーションとアクセスを促進するために設計され、一方情報サーバーは情報の供給を促進するために設計されている。通常ウェブ・ブラウザーと情報サーバーは通信ネットワークを介してお互いに交信するように配置してある。情報サーバーは、通常ウェブ・ブラウザーを用いて情報にアクセスするユーザーに対し情報を提供する機能を果たす。従って、情報サーバーは主にウェブ上の情報へのナビゲーションやアクセスにウェブ・ブラウザーを用いるユーザーに対し情報を提供する。ウェブ・ブラウザーの例としては、マイクロソフト社のインターネット・エクスプローラや、ネットスケープ・ナビゲーターがある。加えて、ウェブＴＶのようなナビゲーション・ユーザー・インターフェース機器もインターネットナビゲーションを容易にするために実現されている。ファイル転送プロトコル（ＦＴＰ）、電子メールインターフェース（例えば、メールトゥー）、サーチクエリー、データベースクエリー、スクリプト、ウェブサービス（マイクロソフト社のドットネットやサンマイクロシステムズのサンワン）など、多くの他のナビゲーション・インターフェースと装置もインターネットをナビゲートするのに存在する。マイクロソフト社の情報・サーバーやアパッチが情報サーバーの例である。
【００１６】
ユニバーサル・資源・ロケーター（ＵＲＬ）
ウェブの拡大は膨大な量の情報をもたらし、かかる膨大な情報はユニバーサル・資源・ロケーター（ＵＲＬ）及びその他のアドレスベース又は場所ベースの方法を利用することによりアクセス可能である。ＵＲＬとは通常ウェブ・ページ中にハイパーリンクとして組み入れられるアドレス、あるいはウェブ・ブラウザーにタイプ入力されるアドレスである。所与の資源（最も一般的には遠隔コンピュータ上にあるファイル）のＵＲＬはその資源のみを指す。一般的に、当該場所へのレファレンスは、例えば「ｈｔｔｐ：／／ｗｗｗ．ａＷｅｂＳｉｔｅ．ｃｏｍ／ａＦｏｌｄｅｒ／ａＦｉｌｅ／ａＦｉｌｅ．ｈｔｍｌ」というように、ディレクトリ・パス及びファイル名と併せて未解決のＩＰアドレスを用いて達成される。この例では、このＵＲＬが「ａＷｅｂＳｉｔｅ．ｃｏｍ」というドメインの「ｗｗｗ」という名前のコンピュータに接続し、そのコンピュータの「ａＦｏｌｄｅｒ」というディレクトリに保存されている「ａＦｉｌｅ．ｈｔｍｌ」という名前のファイルを要求するように、ブラウザーに命じることになる。
【００１７】
統一名識別子（ＵＮＩ）
Ｔｈｅ  Ｃｏｒｐｏｒａｔｉｏｎ  ｆｏｒ  Ｎａｔｉｏｎａｌ  Ｒｅｓｅａｒｃｈ  Ｉｎｉｔｉａｔｉｖｅは、情報の名前と所在を指定するハンドル・システムと呼ばれる新しい手段を創り出し実施した。ハンドル・システムは現在のＵＲＬの利用状況を改善するために設計された。
【００１８】
ハンドル・システムは、インターネット上で情報の所在を確認したり情報を配信するための間接指定のレベルを導入する。ハンドル・システムは、資源に名前を付けるための汎用システムである。特定の資源の現在の場所に基づくＵＲＬを指定する代わりに、資源に統一名識別子を指定する。ＵＮＩはユニバーサル・資源識別子（ＵＲＩ）の一形式である。ＵＲＩはＵＮＩとＵＲＬの両方を含む。ＵＮＩはＵＲＬと違い、資源の場所やその他の属性の変化に関わらず永続的な資源の名前として機能し、またこれ以降そのような名前であるものとみなす。言い換えると、ユニバーサル・資源・ネーム（ＵＲＮ）はＵＮＩの一種である（即ち、ＵＮＩはＵＲＮの概念を含む）。更に、ハンドルとはＵＲＮの一種である。またデジタル・オブジェクト識別子（ＤＯＩ）はハンドルの一種である。従って、ハンドル、ＵＲＮ、ＤＯＩ及び／又はその他が様々な形式のＵＮＩに含まれる。ＵＮＩの様々な用語及び／又は形式は、本文全体にわたって置換可能なように用いられ、特に明記しない限り置換可能と想定してよいものとする。ハンドルは、名付けられた資源の現在のネットワーク上の場所と共にハンドル・システムに登録される固有の名前である。この場所に関する情報は通常ＵＲＬの形式をとる。一般的なハンドルの種類の一つとしてデジタル・オブジェクト識別子（ＤＯＩ）が知られている。その場合ハンドルはＵＲＬの代わりにユーザーに配信され、表面上はハイパーリンクと同様に機能するかに見える。ユーザーがハンドルに遭遇すると、ユーザーのブラウザーにハンドル・要求を行う作成する機能がある限りは、ユーザーはＵＲＬハイパーリンクを選択したり入力したりするのと同様にハンドルを選択したり入力したりする。そのような遭遇により、資源の現在の場所を検索する自動のプロセスが始動する。資源の現在の場所は、ハンドル・システムが提供するディレクトリの中の資源のハンドルに関連付けられていて、ユーザーを資源の現在の場所へと導く。ＵＲＬとは違い、資源が移動した場合、ハンドル・システムのディレクトリのエントリーは更新可能なので、ハンドルと、ハンドルが特定する資源との永続的な関連付けが確保される。これを現実の世界に喩えるならば、所与の資源のＵＲＬのみを知っているということは、ある人の住所だけ知っていて名前は知らないようなものである。もしその人が街の反対側へ引っ越した場合、名前を知らなければ探すのは非常に困難になる。ハンドル・システムにより、ハンドルを用いて資源に永続的な名前を付けることができ、ハンドル・システム・ディレクトリの中の資源の名前に基づいて、資源の現在の場所を検索することができる。
【００１９】
オンライン広告
広告技術はインターネットが、エンドユーザーの実際のインターラクションの測定機構がない又はエンドユーザーが広告を確かに見たことを検証する機構さえない伝統的媒体、例えば、テレビや印刷雑誌広告、では不可能な方法でエンドユーザーの行為を追跡可能であることを利用する努力において開発されてきた。企業は、ウェブページの内容を「読み」、その後、ページのコンテキスト（例えば、ページの特定の主題に応答して選択されてウェブページに配置されたグーグルの「スポンサードリンク」）に応答して、ある広告をそのページに配置する（グーグルのアドセンスなどの）コンテキスト広告を作成した。
【発明の開示】
【発明が解決しようとする課題】
【００２０】
デジタル・オブジェクト識別子（ＤＯＩ）はＩＰアドレス及びその他の場所に基づくアドレス方式の欠点の多くを克服するものである。ＤＯＩは定期的に移動する可能性のある情報に永続的な識別子を与えることによって、通信ネットワーク上の情報にアクセスすることを可能にする。ＤＯＩは、識別子を場所と関連付けるのではなく、更なるレベルの間接指定を加えて識別子を情報と関連付けるメカニズムを設けることによって、場所をアドレスで指定することに限定されたネットワーク・アドレス方式の限界を克服する。
【００２１】
ＤＯＩは、識別子を場所ではなく情報と関連付けることを可能にする機構を提供するが、ＤＯＩ自体は様々な使用コンテキストに基づいて、様々な場所、様々なフォーマットの情報の多重及び／又は様々なインスタンスのアクセス、あるいは所与の情報に関連する様々なサービスへのアクセス及び／又は追跡を可能にするものではない。
【課題を解決するための手段】
【００２２】
本発明の一実施例では、少なくとも一つのコンピュータを用いてレファレンスメニューを生成する方法が教示されている。本方法は、エンティティに関する情報（エンティティ情報）を収集することと、ユニークパーシステント統一名称識別子（ＵＰＵＮＩ）の要求を要求クライアントから受信し、内容を評価してＵＰＵＮＩメニューをＵＰＵＮＩメニュー仕様から生成することとを有し、ＵＰＵＮＩメニュー仕様は、ＵＰＵＮＩメニューを形成するＵＰＵＮＩ記録情報からバリューを特定するのに使用される。
【００２３】
更に、本開示は、広告、電子商取引及びオンラインクライアントインターラクション（ＩＳＩＣＩ）のための統合、情報処理及び自己改善ファシリティの装置、方法及びシステムを詳細に説明する。ＩＳＩＣＩの側面は既に、２００５年１月１１日に米国特許商標庁に提出され、名称「相互に関係するユニークパーシステント統一資源識別子、メニュー及び情報を保証、編集及び配置する装置、方法及びシステム」を有する特許出願番号第６０／６４２，８０９号に詳細に説明されている。ＩＳＩＣＩは、ここで説明されると共に本開示を通じて、ユニークパーシステント統一名称識別子のオートリンカー、シンジケーター及びカスタマイザー（ＡＳＣＵＰＵＲＩ）の様々な側面を使用する。ＩＳＩＣＩは、ＩＳＩＣＩとエンドユーザーとの実際のインターラクションによって駆動されてそれ自体の改良を可能にするフィードバックループを含む。これらのメニューと実際のエンドユーザーのインターラクションの追跡に基づいて、フィードバックループは、作成／維持サイクルにフィードバックされる経験的な追跡データに基づいてメニューが修正及び改善が可能となるように形成可能である。ＩＳＩＣＩの開示は、かかる追跡情報が作成／維持サイクルにフィードバック可能となる方法に関して様々な実施例を提供する。例えば、情報は、手動で（即ち、追跡結果の人間の検討と最も適当なメニューへの修正に関する人間の判断に基づいて、なお、その修正はマルチリンクエディタを介して手動で実行可能である）、メニューを修正／作成する自動「流れ作業」を通じて（即ち、順方向ベースで本システムは異なるメニューを自動的に作成及び維持するように）完全に自動で（例えば、メニューとインターラクションする際に実際のユーザーの行為を測定することによって把握されるように、メニューの選択肢の順番が異なるメニュー選択肢の相対的な人気に基づいて再編可能である）などフィードバック可能である。
【００２４】
これらの行為の測定は、様々なメニュー選択肢に関連付けられたクリックスルー速度を追跡し、購入その他の取引時間においてその後の行為（例えば、ポストクリックスルー）を追跡し、様々なメニュー選択肢の上を舞うユーザーが費やした時間の測定を追跡し、様々なメニュー選択肢が捲る頻度の測定を追跡することなどを含む。
【００２５】
また、メニュー作成／維持サイクルへのこのフィードバックは、メニューとインターラクションする際にエンドユーザーの行為に加えて他の原因に由来する場合もある。かかる原因は、（ユーザーのメニューのクリックスルー後又は全体的に無関係な）ユーザーの購入行為の独立した基準、独立して記録されたユーザーの嗜好情報（個別的又は集合的に）、ユーザーの範疇に関連する独立して記録されたユーザーの情報（例えば、収入、興味、人口統計、嗜好その他−かかる実施例はプロファイルされた情報をいかなる個人にも関連付けない）によるユーザーの種類をプロファイルする基準）、メニューをホストするサイトによって記録された基準（例えば、サイト訪問者の日時、地理的場所に基づくプロファイリング）などである。
【００２６】
このフィードバックループによって駆動されるメニューの改良は、メニューのリンクの順番の変化、異なるリンクの選択的追加又は削除（例えば、メニューを統一的に制御する主制御記録において中央的に、又は、特定のウェブサイトのメニューのローカルにカスタマイズされたバージョンにおいて単に）、メニューを異なって形成するためのバックエンドシステムからのデータの選択的検索、グラフィックスの包含又は削除又はビデオ又は他のマルチメディア努力などを含んでもよい。
【００２７】
メニューの改良は、購入行為を奨励する改良に限定される必要はなく、広告志向用途にも全く限定される必要はない。情報又はその他のサービスエンドユーザー又はコンピュータプログラムに仕えるサービスを提供するいかなるシステムも本発明を利用することができる。市、州又は連邦政府が情報をその市民に提供する情報システムは、殆どの市民が所与のコンテキストで実際に望む情報の種類の測定に基づいて連続的にメニューを改良するのに本発明を利用することができる。ある実施例では、収集された情報又は軍事兵站情報を提供する軍事システムが、起こりえるテロリスト攻撃に関して収集した情報、敵隊移動を監視するセンサーデータなどによってある容疑者テロリストに最高優先監視リストに設定したり、ビルや物理アセットを同様の高リスク監視リストに設定したりするなどの外的要因に基づいて最も有用な情報及びリンクを提供するのに本発明を利用することができた。別の実施例においては、ダイナミックベースでメニュー選択肢を改良するために、クライアントや、複雑かつ情報集中的な処理を通じてナビゲートする内部スタッフを助けることを希望する銀行又は保険会社が取引を希望するユーザーの行為から内部サービス優先順位までのソースデータを利用することができる。
【発明を実施するための最良の形態】
【００２８】
添付図面は、本開示に従う様々な非限定的で例示的な発明的側面を示している。
【００２９】
図面の各参照符号の先頭の番号は、参照符号が導入される最初の図を示している。同様に、参照符号１０１は図１に最初に導入される。参照符号２０１は図２などで最初に導入される。
【００３０】
広告、電子商取引及びオンラインクライアントインターラクションのための統合、情報処理及び自己改善ファシリティ
図１は、広告、電子商取引及びオンラインクライアントインターラクションの統合、情報処理及び自己改善（ＩＳＩＣＩ）ファシリティに対する装置、方法及びシステムの実施例を示す混合データ及び論理フロー図である。一般にＩＳＩＣＩは３つのコンポーネントから構成される。１）マルチリンクメニュー１８１の作成及び維持、２）基底マルチリンク記録１８２の登録及び更新、３）マルチリンクメニュー１８３の分配及びシンジケーションである。これら３つのコンポーネントは図１に見ることができ、それぞれは太い点線が横切るように図の１／３を略形成する。ＩＳＩＣＩもシンジケートされたマルチリンクメニューの追跡という特徴を有し、それはマルチリンクメニューが時間と共に最適化されるように分配／シンジケーションコンポーネント１８３から作成／維持コンポーネント１８１へのフィードバック１４０及び１７５である。オートリンカーは、最初の例１２０においてマルチリンクＤＩＯを作成する。その後、これらのＤＯＩはグローバルディレクトリ（例えば、ハンドルシステム）１１３に預けられる（即ち、登録される）１３０。その後、マルチリンクＤＯＩは、リンクその他の「要求部」によって通信ネットワーク（例えば、インターネット）において直ちに呼び起こし可能となる。シンジケーター１３５は、それらのリンクや要求部をウェブページその他の場所に分配させる機構である。シンジケーターは、フィルタリング、マルチリンクメニューとＤＩＯ記録１１３から検索されたデータを変更及び／又はその他のカスタマイズをする。
【００３１】
ＩＳＩＣＩの一構成要素であるオートリンカーは自動リンクを可能にする。オートリンカーは、ユーザーの（例えば、クライアントの）情報、サービス、取引などのインターリンクされたマルチリンクメニューをいかなるターゲットオブジェクト又はコンテンツに関連して自動的に作成する。マルチリンクメニューは、マルチリンクＤＯＩと、選択的に、メニューにおいて表示されるマルチリンクＤＩＯからのレイアウトとアイテムを記載したメニュー仕様という２つのコンポーネントを有する。メニュー仕様が与えられなければ、メニューを生成するための仕様として完全なＤＩＯマルチリンクが使用可能である。これらのマルチリンクは、顧客のサイトその他のどこを向いてもよい。例えば、マルチリンクは、購入のための様々な小売店、他の企業のサイトその他の企業のシステムにおける関連情報などに向いてもよい。
【００３２】
ある実施例においては、顧客メタデータがオートリンカー１０５によって使用される。顧客メタデータは様々なオブジェクトを更にターゲットとする。即ち、メタデータ自身はＤＯＩを含んでもよい。メタデータは幾つかのソースから取得してもよい。一般に、メタデータは顧客のデータ１１９からエクスポートしてもよい。データベースは、製品や顧客がマルチリンクされたＤＯＩを作成したい他のターゲットオブジェクトのためにクエリー可能である。例えば、発行顧客は、最高売上書籍と添付情報（例えば、題名、著者、年、ベストセラーランキング）を選択するそれら自身のデータベースにクエリー可能である。
【００３３】
これは、書籍のデータベース表をターゲットにしてかかるフィールドに選択するＳＱＬ選択コマンドと共に達成可能である。別の実施例においては、病院は、患者毎にそれ自身の患者の記録をクエリーしてマルチリンクを生成することができる。病院の記録にマルチリンクされたＤＩＯを作成することによって、データ交換の容易性は、様々な医療施設と機関間で大幅に強化される。医療管理費用は、患者と管理記録へのパーシステント統一レファレンスを有することによって相当低下することができる。同様の倹約は、保険会社などの補助企業に適用する。実際、マルチリンクを介して単一レファレンスを提供することによって、ヘルスケアプロバイダー、保険業者及び患者は電子医学記録と関連口座と保険情報の全てに単一のレファレンスでアクセス可能である。これは事務的なミス、幾つかのコピーとしばしば不正確な記録コピーを維持する際の管理間接費を大幅に削減可能である。別の実施例においては、小売店は無線ＩＤ（ＲＦＩＤ）装置活動を追跡することができる。かかる実施例においては、各ＲＦＩＤはユニークな識別子を与えられ、ハンドルシステムで登録される。このように、各ＲＦＩＤはそれ自身のＤＯＩを有する。ある実施例では、小売店はＤＯＩの組を登録し、ＲＦＩＤ製造時にＲＦＩＤの各々を登録されたＤＯＩの幾つかで埋め込むことができる。代替的に、ＲＦＩＤ番号はＲＦＩＤ製造時にＤＯＩとして登録可能であったが、ＲＦＩＤ自身には実際に埋め込まれなかった。その後、ＲＦＩＤ番号がリーダー装置に読まれると、リーダー装置は、ＤＯＩとして以前に登録されたであろうＲＦＩＤ番号を使用してそのハンドル要求を形成することによって、ハンドルシステムをアクセスすることができた。このため、ＲＦＩＤを走査するいかなるシステムもＤＯＩを取得し、ハンドルシステムにアクセスするであろう。このように、ハンドルシステムのＤＩＯ記録に関連付けられたマルチリンクは、ユーザー又はリーダー装置をそのＲＦＩＤに関するいかなる情報にも、永久的で永続的で総合的な方法でリンクさせることができるであろう。かかるシステムにおいて、ＲＦＩＤと共にアイテムがアクセスされる度に、即ち、アクセス点におけるシステムは、その当事者（例えば、当事者は編集をする適切なアクセス制御権を有する）によって変更可能なＲＦＩＤのＤＯＩ記録の取引のサブコンポーネントにおけるＤＯＩマルチリンク記録を変更してもよい。このため、ＤＯＩ記録はＲＦＩＤと共にアイテムに関連する完全な取引追跡を与えることができる。代替的に、小売店はそれ自身のシステムデータベース１１９を介してＤＯＩが可能にするＲＦＩＤを追跡してもよい。このため、小売店はエクスポートのためのＲＦＩＤ関連フィールドを選択することができる。それらのフィールドはメタデータ１０５としてその後オートリンカー１２０によって使用されるためにエクスポートされてもよい。ある実施例においては、ＲＦＩＤの取引に関するＧＰＳ情報及び／又は所在が各取引と共に保存可能である。情報に基づくこの取引と位置は、ＤＯＩが可能にするＲＦＩＤに対して取引と位置履歴を構成することができる。ここでの有用性は、単一の識別子が全取引と特定のアイテムに関する移動履歴を与えることができるであろうということである。
【００３４】
マイクロソフトエクセル、タブ描写フィールド及びバリュー、ＸＭＬなど幾つかのフォーマットが顧客メタデータをコード化するのに使用可能である。データベース選択に対する結果を取得すると、様々なデータベースは、選択されたデータベース記録が、オートリンカー１１０へのメタデータの提出としての様々なエクスポートフォーマットにエクスポートされることを許容する。ユーザーは、オートリンキング１２０を使用すること又はハンドルエディタ１１５と共に手動でマルチリンクを生成することを選択１１０することができる。ハンドルエディタは、図５及び図６において後で詳細に説明する。オートリンキング１２０は、図２において詳細に説明するが、マルチリンクＤＯＩとメニュー１２２との関係を設定し、マルチリンクＤＯＩ記録１２４に対するポインタを構成し、最終的にはマルチリンクメニュー１２６を生成することを有する。一旦メタデータがＤＯＩマルチリンク記録１３０の形式におかれると、ＤＯＩディレクトリ１１３に登録され、その後、ＤＯＩ解決サーバー１３３を介して識別、解決及びアクセス可能となる。ＤＯＩ解決サーバーは一般公衆にアクセス可能なグローバルサーバーであるか、それらはイントラネットにおけるローカルサーバーであってイントラネットのユーザーとシステムにのみアクセス可能であってもよいことに留意しなければならない。イントラネットの実施例においては、ローカルイントラネットの管理者は、ローカル「マスター」ＤＯＩ記録を、そのマスター記録の所有者であれば、修正及び／又はカスタマイズすることができる。ローカルイントラネットの管理者がその「マスター」ＤＯＩ記録の所有者でなければ、ローカル管理者は依然としてマスターＤＯＩ記録から戻されたデータ又はメニューを修正したり、ローカルプログラム又はシステムに修正させたりすることができ、ローカル環境において、それが原製作者の資源の代わりに又はそれに加えて、ローカル資源又はローカルに特定された資源を指す。代替的に、ローカルイントラネットの管理者は、グローバルハンドルサーバーへの解決から彼らのローカルに派生するＤＯＩ要求を維持することができ、代わりに、ローカル解決部に解決を命令することができる。選択的に、オートリンカー１２６によって生成可能であった１２６メニュー仕様は、それがＩＳＩＣＩデータベースに保存可能であれば、シンジケーター１３５に供給可能であろう。ある実施例においては、かかるデータベースは、シンジケートされたＤＯＩマルチリンクをカスタマイズするのに必要な特定情報を維持するのに使用可能である。代替的な実施例においては、オートリンカー１２０は、シンジケーター１３５がマルチリンクメニューを生成することを要求し、オートリンカーはその後メニューをＤＯＩ記録マルチリンク１３０の一部として保存する。
【００３５】
ある実施例においては、シンジケーター１３５は、マルチリンクメニュー及びメニューによってターゲットとされたレファレンスへのナビゲーションを可能にする。例示的なマルチリンクメニューを示す１７５。この場合、マルチリンクメニューは書籍のマルチリンクＤＯＩに対するものである。この例においては、マルチリンクメニューは既に生成されている。マルチリンクのＤＯＩ記録はＤＯＩディレクトリ１１３に既に格納されている。マルチリンクメニューに対するメニュー仕様は、ＩＳＩＣＩのデータベースに格納されている。ある実施例においては、マルチリンクメニューへのレファレンスはウェブページ１４０に埋め込まれている。ユーザーがウェブページ１４０をトラバースすると、レファレンスコード、例えば、マルチリンクメニューのジャバスクリプト表現を要求する参照コード、例えば、ＨＴＭＬコード、はシンジケーター１３５から適当なマルチリンクメニューを検索するために稼動とされる。例示的な埋め込みレファレンスコードは以下の形式を有してもよい。
（シンジケーターが提供するスクリプトへのリンク）
<script src="http://doi.contentdirections.com /syndicator/10.1570/dsidman"></script>
（所望のマルチリンクに対する識別子）
<noscript><a href="http://dx.doi.org/10.157 0/dsidman">DOK/ax/noscript>
本例においては、ウェブページはジャバスクリプトを取得することを期待し、ソースは関連ＤＯＩマルチリンクと共にシンジケーターへのレファレンスを供給される。スクリプトの要求は、例えば、ＨＴＴＰポスト要求を介して、シンジケーター１３５に与えられる。シンジケーターは、ＤＯＩマルチリンクと要求のソースをパースすることによってマルチリンクメニューの要求を解釈する。シンジケーターは、その後、ＤＯＩディレクトリ１１３からＤＯＩマルチリンク記録１３０を取得してもよい。次に、シンジケーターは、マルチリンク用のマルチリンクメニュー仕様に対してそれ自身の内部データベースをクエリーしてもよい。マルチリンクメニュー仕様は、それがユニークなバリューであるのでＤＯＩ自身にキーされてもよい。メニュー仕様が存在しなければ、シンジケーターはそれ自身のメニュー仕様を生成することができる。シンジケーターは図４において詳細に説明する。
【００３６】
ある実施例において、ＩＳＩＣＩは、その後、マルチリンクＤＯＩ記録及び／又はマルチリンクメニュー仕様を、マルチリンクＤＯＩのためにマルチリンクメニューを生成するのに使用することができ、例えば、ジャバスクリプトコードを生成する。ジャバスクリプト及びウェブブラウザー以外の多くのユーザーインターフェースプラットフォームがマルチリンクメニューを生成するのに使用可能であることに留意しなければならない。マルチリンクメニューを生成すると、シンジケーター１３５はマルチリンクメニューを要求ユーザーのウェブブラウザー１４０に返し、そこでメニューが表示される１７５。一旦メニューがユーザーのウェブブラウザーに表示されると、ユーザーはメニューをカーソルでトラバースして選択することができる。いかなる選択も、レファレンスコンテンツターゲット１５５への各々のＤＯＩマルチリンクレファレンスからの解決の要求となる。マルチリンクメニューとエンドユーザーのインターラクションを通じて、ユーザーのメニューとのインターラクションは追跡可能となる。追跡情報はウェブページ１４０、シンジケーター、ＤＯＩ解決サーバー、中央追跡サーバーなどをホストするウェブサーバーを含む幾つかの場所に保存される。この追跡情報は、その後マルチリンクメニュー１０７の作成／維持に影響を与えたり修正したりするのに使用される。情報はフィードバックされ、ハンドルエディタ１１５を使用するマルチリンクメニューを手動で編集１０７したり、既に説明したオートリンキング特徴１１０を使用したりする選択肢がある。追跡エンドユーザー情報に関する詳細とかかる情報がマルチリンクメニューの作成及び維持に影響を与えるのにいかに使用可能であるかは、図１６−２０において詳細に説明される。メニュー作成／維持サイクルへのこのフィードバックも、メニューとインターラクションする際に、エンドユーザーの行為に加えて、その他のソースに由来することができる。かかるソースは、ユーザーの購入行為（メニューのユーザーのクリックの後の又は全く無関係の）独立のメトリックス、独立に記録された（個別的又は集合的）ユーザーの嗜好情報、ユーザーの範疇に関連付けられ、独立して記録されたユーザー情報（例えば、ユーザーの種類を収入、興味、人口統計、嗜好などによってプロファイルする匿名のメトリックス、かかる実施例はまとめられた情報をいかなる個人にも関連付けない）、メニューをサイトホストすることによって記録されたメトリックス（例えば、サイト訪問者の日時、地理的場所など）に基づくプロファイルなど、を含んでもよい。
【００３７】
ある実施例においては、ジャバスクリプトはメニュー仕様におけるアイテム毎のメニューを生成するのに使用される。これは、矩形プリミティブを作成し、各々を仕様からのテキストでラベル付けすることによって達成される。矩形プリミティブはドロップダウンメニュー１７５の形態で表示される。矩形プリミティブは、カーソルがいずれか特定の矩形ラベルの周辺内に入ると強調可能となる座標画定ボックスを有する。カーソルの選択機構、例えば、マウスボタン、は、特定の矩形ラベルの境界内に使用される場合、それぞれのＤＯＩマルチリンクがユーザーによって選択されたと理解され、ユーザーのウェブブラウザーは、ターゲットコンテンツ１５６にアクセスするように、例えば、ジャバスクリプトで、命令される。多くの他のメニューフォーマットの実施例が使用可能である。マルチリンク情報は、どの考えられるメニュー形式でも表示可能であるし、メニュー形式を全く介さずに表示可能である。代わりに、メニューはページの個々のリンクのように表示されてもよい。かかる実施例においては、ウェブページ内で「ノースクリプト」タグを使用することによって、非ジャバスクリプトで可能にされたブラウザーが個々のリンクであるリンクをウェブページ上でドロップダウンメニューの代わりに表示することを可能にする。別の実施例においては、メニューアイテムは全マルチリンクメニュー選択肢の行き先を反映する別窓として表現されてもよい。更に別の実施例においては、メニューアイテムは、（例えば、盲目の人によって使用される）メニュー選択肢を形成するオーディオを形成したり、他の障害者によって使用されたりすることを企図されたレンダリングを作成するプログラムなどの不可視のユーザーインターフェースへの入力として伝えられてもよいが、ローカルプログラムによって入力として読まれてもよい。それは、次いで、提供された情報の結果として、例えば、取引を実行したり、身元を確認したり、アクセス権を検証したり、支払いを受け付けたり、他の目的で情報を格納又は処理するために、ある機能を実行することができる。
【００３８】
別の実施例においては、シンジケーターは、コンテンツプロバイダーのサーバーに統合される。この実施例は、ウェブページ１４０のコンテンツプロバイダーとはシンジケーターが別個のサーバー１３５であった先の例に類似している。しかし、この統合された実施例においては、シンジケーターは、コンテンツプロバイダーのサーバーで起動しており、ユーザーにとって取引はＤＯＩディレクトリ１１３からＤＯＩマルチリンク記録の単純な要求であるように見える。しかし、かかる例において、シンジケーターコンポーネントはコンテンツプロバイダーのサーバーで起動している。この実施例は幾つかの長所を有する。第１に、それは遠隔データにアクセスする必要がないのでより高速になり得る。第２に、シンジケーターソフトウェアは遠隔でのみ起動するので、それは、（例えば、原コンテンツプロバイダーなどの）第三者を代表してカスタマイズされる代わりに、ウェブページ１４０のコンテンツプロバイダーによって直接制御されるローカルカスタマイズを許容する。第３に、イントラネットの実施例においては、それは、原作成者の資源の代わりに又は加えて、公衆がＤＯＩマルチリンクにアクセスすることを許容又は禁止するように及び／又はローカル資源又はローカルに特定された資源を指すイントラネット制御を許容する。
【００３９】
多くのシンジケーターが存在し得ること及び各々が所与のＤＯＩマルチリンクに対するそれ自身のメニュー仕様を有してもよいことに留意すべきである。例えば、検索エンジンは、小売店Ａ、小売店Ａの子会社及び小売店Ｂをリストにする「別の購入場所」をターゲットとする選択肢を有する書籍のメニュー仕様を有してもよい。その方法においては、小売店Ａは、それ自身のシンジケーターを彼らのウェブサーバーに有してもよく、そのメニュー仕様は、「別の購入場所」メニュー選択肢の下で、小売店Ａと小売店Ａの子会社を有するのみである。このため、各々が多数のメニュー仕様を有する多数のシンジケーターを有することができる。その全ては同一のＤＯＩマルチリンク記録で無数の異なる適合されたビューを提供することができる。このため、シンジケーターは、同一のＤＯＩマルチリンクの別個の「カスタマイゼーション」又は「レンディション」を提供することができる。ある実施例においては、シンジケーターは、マルチリンクサーバーソフトウェアとして提供され、それはマルチリンクメニューをドロップダウンメニュー提供を介して作成すると共にマスターＤＯＩ記録において提供されたデフォルトを超えてメニューのカスタマイゼーションを許容する。マルチリンクサーバーソフトウェアがＤＯＩが配置されたウェブページを提供する同一のサーバー上にあればシンジケーターはローカルであることに留意しなければならない。代わりに、そのマルチリンクサーバーソフトウェアが別個のサーバーから惹起されると、サーバーが遠隔で提供する「シンジケーター」はマルチリンクメニューと、ＤＯＩが派生したウェブページサーバーからのいかなるカスタマイズをも提供することができる。
【００４０】
このように、別の実施例は、様々なビュー及び処理の需要を有する多数のエンティティに仕える単一のシンジケーターを有する。かかる実施例の一例は、図１４において詳細に説明され、ＩＳＩＣＩは広告プロバイダーによって使用可能となる。
【００４１】
ある実施例においては、シンジケーターが要求を受け取ると、シンジケーターは要求が派生した場所も決定する。その後、シンジケーターがメニュー仕様を調べると、それは、要求をしたエンティティのために特定のメニュー仕様を検索することによってそのクエリーを更に改良する。これは、特定のオーディエンスに対するマルチリンクＤＯＩのより大きな適合を可能にする。例えば、広告プロバイダーは広告に対して支払われ、特定の書籍の著者の作品を奨励したり販売したりしてもよい。ユーザーがバナー広告の形で、例えば、著者の作品に対して、マルチリンクに関与すると、マルチリンクメニューが、著者の名前と著者の書籍をリストするサブメニューを提供する「購入可能な書籍」を示して表示されてもよい。この適合実施例においては、ユーザーがNickelodeon.comなどの子供用ウェブサイトで広告を見ている場合には、「購入可能な書籍」サブメニューは、著者による子供の書籍のみをリストするように簡潔にされる。しかし、スリラー映画ファンのウェブサイトでは、「購入可能な書籍」サブメニューは、著者のスリラーの題名を有するのみとなるであろう。要求エンティティの決定は、幾つかの方法で達成可能である。ある実施例においては、発生要求アドレスがどのメニュー仕様が使用されるべきであるかを決定する根拠として使用される。かかる実施例においては、メニュー仕様に対するクエリーは、ＤＯＩと要求サイトからのウェブアドレスで作成される。別の実施例においては、埋め込まれたコードは要求コンテンツプロバイダーの身元を特定してもよい。コード自体は要求コンテンツプロバイダーを識別するＤＯＩであってもよく、また、メニュー仕様に対するクエリーの一部として使用されてもよい。
【００４２】
上述の実施例はマルチリンクメニュー仕様とメニューを生成するコードを格納するシンジケーターのデータベースを有するが、その情報を格納するデータベースはどこに配置されてもよいことを留意しなければならない。ある代替的な実施例においては、ＤＯＩマルチリンク記録はマルチリンクメニュー仕様の入力を有する。更に別の実施例においては、ＤＯＩマルチリンク記録はマルチリンクメニューを生成するジャバスクリプトコードの入力を有する。
【００４３】
オートリンカー
図２は、オートリンカーの実施例を示す混合データ及び論理フロー図である。図１において既述したように、オートリンキング１２０は、一般に、マルチリンクＤＯＩとメニュー１２２との関係を設定し、マルチリンクＤＯＩ記録１２４に対するポインタを作成し、最終的には、マルチリンクメニュー１２６を生成することを有する。
【００４４】
オートリンカーは、図１において既述１０５したように、様々なソースからメタデータフィールドとバリュー２０５を取得することができる。この点で、オートリンカーはメニュー仕様が提供されたか、及び／又は、存在するかどうかを見る検査をする。ある実施例においては、データを提供するユーザーは、それ自身のメニュー仕様を提供する。メニュー仕様は、マイクロソフトエクセル、タブ記述形式、ＸＭＬなどでもよい。図５に図示されているもの５２５のように、仕様フィールドラベル２７０、２８０、２７５及び関連記録フィールドラベル２８９、バリュー２９１及びレファレンス２８７などのアウトライン階層を表すいかなるフォーマットも満足する。多くの場合、かかるメニュー仕様は取り掛かられる。メニュー構造が入手可能であれば、オートリンカーはそれを取得する２１５。メニュー仕様が提供されていなければ、オートリンカーは最良の推察メニュー構造を生成するように努める。
【００４５】
ある実施例２２０においては、オートリンカーがメタデータフィールドとバリュー２６３しか有しない場合、それはメタデータ記録フィールドラベル２８９からメニュー仕様を生成するだろう。かかる実施例において、オートリンカーは各メタデータ記録フィールドラベル２８９（例えば、著者、題名）を取り上げてメニュー構造仕様フィールド２６５のレベルワン２７０でそれらを特定するだろう。その後、メニュー構造仕様フィールド２６５のレベルツーは、記録フィールドラベル２８９に関連付けられたバリュー２９１に由来するだろう。このように、一例として、メタデータ２６３からのフィールドラベル２８９は、マルチリンクメニューのレベルワンメニュー２６４、２６６を構成するのに使用され、メタデータ記録バリュー２９１はレベルツーメニュー２６８、２６９を構成するのに使用され、それらのサブメニュー２６８、２６９はそれらの各々の記録レファレンス２８７に関連付けられるだろう。このように、ユーザーがレファレンス２６９の一つを選択すれば、ユーザーは、レファレンスターゲットに到達するであろう。これらのエンドユーザー選択と動作は測定２２６され、図１６−２２において後で詳述されるように、メトリックスはマルチリンクメニューの作成／維持にフィードバック１２２される。別の実施例２２０においては、オートリンカーは、ウェブサイトマップ、ウェブサイトでメインメニュー、リアリーシンプルシンジケーション（ＲＳＳ）フィード及び／又はユーザーのウェブページサーバーから同様の構造を取得することができる。例えば、オートリンカーはもっとも頻繁にアクセスされたウェブサイトアドレス２８７に対するメタデータを検査して、そのウェブサイト情報をダウンロードすることができる。ある実施例においては、オートリンカーは、「メニュー」、「サイトマップ」などを一致するテキストのサイトによって与えられるウェブページにおいてＨＴＭＬ及び／又はＸＭＬタグを検索する。しばしば、ウェブサイトはそのウェブサイトの全テーマとしてメニュー構造を有し、この構造はメニュー仕様構造２６５に適当であるかもしれない。例えば、ウェブサイトは、「ホーム、製品、サポート、ヘルプ」を有するメニューを有することができる。それらのメニューの各々はサブメニューを同様に有してもよい。例えば、「サポート」は、「サポート」メニューに階層的に服従する「問い合わせ」メニューアイテムを有してもよい。かかる実施例においては、オートリンカーは、かかるウェブサイトメニューとサブメニューとをソノメタデータフィールド２８９の全てに比較する。オートリンカーは、その後、メニューアイテムに基づいてメタデータフィールド２８９に一致するウェブサイトから仕様２６５を作成するであろう。ある実施例においては、ウェブサイトサブメニューがメタデータフィールド２８９と一致すれば、メニュー仕様はウェブサイトマップ構造の階層を採用し、生成されたメニュー仕様２６５はそれらの一致したフィールドをサブメニューとして有するだろう。それらは一致する親メニューにとってどちらかのサブメニューとなる。
【００４６】
一時フロー図から離れると、自動ウェブサイトリンク構成を示す用途例を記載するのに有用であるかもしれない。かかる用途においては、オートリンカーはＲＳＳフィード識別子を与えられる。かかる識別子は、ＲＳＳリンクに対するウェブサイトをクロールすることによって供給可能となる。ＲＳＳリンクを取得すると、フィードコンポーネントは検索される。ＲＳＳフィードのコンポーネントはパースされる。ある例示的な実施例において、検索とパースはＰＥＲＬなどのスクリプト言語を使用することによって取得可能となる。
/* PRIMARY RESPONSE PAGE
*/
h.initNewHandle();
try {
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstanceO;
DocumentBuilder builder = factory .newDocumentBuilderO;
//Document document = builder.parse("http://www.thirdstation.com/blog/?flav=rss");
Document document = builder.parse(blog.openStream()); org.w3c.dom.Element feed = document.getDocumentElementO;
org.w3c.dom.NodeList channels = feed.getElementsByTagName("channel"); if(channels.getLength() > 0){
org.w3c.dom.Element channel = (org.wSc.dom.ElementJchannels.itemCO); 
org.w3c.dom.ElementblogTitle = (org.w3c.dom.Element)
(channel.getElementsByTagName("title"))-item(O);
org.w3c.dom.Element blogLink = (org.w3c.dom.Element)
(channel.getElementsByTagName("link")).item(O);
org.w3c.dom.Element pubDate = (org.w3c.dom.Element)
(channel.getElementsByTagName("pubDate"))-item(O);
org.w3c.dom.NodeList items = channel.getElementsByTagName("item");
ＲＳＳフィードをそのコンポーネントにパースすると、コンポーネントは識別されてコンポーネントバリューはオートリンカーによって要求される特定のバリューに基づいて取得される。ある実施例においては、メニュー仕様はどのコンポーネント及びバリューが取得されるべきであるかを設定するのに使用される。ある実施例においては、これは、スクリプトと共に達成可能となる。
if(blogLink !=null){
h.addValue(l ,"URL", blogLink.getFirstChild().getNodeValue());
Log.debugC Added primary response page for doi="+doi);
}
if( blogTitle != null && blogLink != null) {
h.addValue(indexCount, "MULTIRES",blogTitle.getFirstChild().getNodeValue().trimO + "=" +
blogLink.getFirstChild().getNodeValue0.trimO);
h.addMapEntry(0, indexCount++);
｝
if(pubDate != null){
h.addValue(indexCount, "MULTIRES", "Updated: " +pubDate.getFirstChild().getNodeValue() + "=#"); 
h.addMapEntiy(O, indexCount++);
}
int postsldx = indexCount;
h.addValue(indexCount, "MULTIRES", "Latest Entries=#");
h.addMapEntry(O, indexCount++);
for(int k = O; k < items.getLengthO; k++){
// Only take last ten entries
if(k = 10){ break; }
org.w3c.dom.Element currElement = (org.w3c.dom.Element) items.item(k); org.w3c.dom.Element titleEl = (org.w3c.dom.Element)
(currElement.getElementsByTagName("title")).item(O);
org.w3c.dom.Element lirikEl = (org.w3c.dom.Element) (currElement.getElementsByTagName("link")).item(O);
org.w3c.dom.Element descEl = (org.w3c.dom.Element)
(currElement.getElementsByTagName("description")).item(0);
String title = null;
String link = null;
String desc = null;
try{
title = titleEl.getFirstChild().getNodeValue0.trim();
}catch(NullPointerException npe){
title = null;
}
try{
link = linkEl.getFirstChild().getNodeValue0.trimO;
} catch(NullPointerException npe) {
link = null;
}
try{
desc = descEl.getFirstChild().getNodeValue().trim();
} catch(NullPointerException npe) {
desc = null;
}
一旦、コンポーネントとバリューが取得されると、それらのバリューはマルチリンクメニューの根拠を形成するために加算される。ある実施例においては、これは以下のスクリプトと共に達成される。
if(title != null && link != null){
h.addValue(indexCount, "MULTIRES", title + "=" + link);
h.addMapEntry(postsIdx, indexCount++);
}
if( title = null && link != null && desc != null){
h.addValue(indexCount, "MULTIRES", desc + "=" + link);
h.addMapEntry (postsldx, indexCount++);
}
}
}
}
catch (FactoryConflgurationError e) {
Log.debugC'Unable to get a factory instance.");
} catch (ParserConfigurationException e) {
Log.debugO'Unable to get a parser.");
} catch (SAXException e) {
Log.debugC'Error parsing feed");
}catch (IOException e) {
Log.debug("I/O exception");
}catch(Exception e){
Log.debug("ERROR: " + e.getMessage());
}
} //blog != null
// CDIHOME PAGE
h.addValue(indexCount, "MULTIRES", "Powered by Content Directions=http://doi.contentdirections.com/?doi=" + CDI_REF_ID);
h.addMapEntry(O, indexCount++);
//EMAIL
h.addValue(indexCount, "MULTIRES", "Email this Info to a Friend=mailto:?subject?=Thought you might be interested... &body=I thought you might be interested in this blog: http://dx.doi.org/"+doi);
h.addMapEntry(0,indexCount++);
Log.debugC'Setting index count to " + indexCount);
//LINK
h.addValue(indexCount,"MULTIRES"," Add this Link to Your
Site=http://doi.contentdirections.com/syndicator/?"+doi); h.addMapEntry(0,indexCount++);
Log.debugC'Setting index count to " + indexCount);
図２５３は、例えば、ニューヨークタイムズのウェブサイトからライブフィードのマルチリンクメニューを構成したオートリンカーを示すために進む。ユーザーが入力２５３の一つを選択すると、それらはライブフィード２５４のターゲットに運ばれる。同様に、上記ＲＳＳ実施例もブログ、ウェブサイトルートレベルメニューなどに適用可能である。
【００４７】
上記ＲＳＳの例示的な実施例から離れて、オートリンカーの関係生成１２２の議論に戻る。一旦オートリンカーが最良の推察メニュー仕様２２０を生成すると、それはメニュー構造２１５の仕様を取得する。メニュー仕様２１５とメタデータフィールド２０５を有すると、オートリンカーは両者２２５の照合を実行する。一旦オートリンカーがどのメタデータフィールド２０５、２６３、一致２２５、メニュー仕様フィールド２１５、２６５であるかを識別すると、オートリンカーはポインタの構成１２４を開始してもよい。
【００４８】
照合フィールド１２６に基づいて、オートリンカーはメタデータデータベースでフィールドバリュー２３０を検索する。例えば、著者２６４のメニューを構成する際に、オートリンカーが同一著者による全ての書籍をインターリンクするにつれて著者フィールドに基づいて照合は起こる。その後、オートリンカーはメニュー２６６を形成するために著者による各題名を発見するだろう。照合のために選択された実際のフィールドはメニュー仕様に依存する場合があり、いかなる数のメタデータフィールドを含んでもよい。このように、オートリンカーはメニュー仕様に基づいてメタデータと共にメニューサブメニューを形成するために検索をする。例えば、オートリンカーによってデータベースに格納可能であるメタデータ１０５、２６３は、照合されたメニュー仕様フィールド２２５を使用することによってオートリンカーによって検索される。例えば、メニュー仕様フィールド２６５とメタデータフィールド２６３との間の唯一の共通のフィールドは、「題名」フィールド２８３、２８１である。メニュー仕様２６５は、グラフィックメニューには示されていない仕様とサブメニュー２７５の一部として提供されたルートメニュー「メニュー種類」でメニューを規定するだろう。別のルートメニューは照合「題名」フィールド２８１を含む「著者の他の書籍」２８０である。この照合されたフィールド２２５に基づいて、オートリンカーは全記録で全バリューを検索し、戻された検索結果のバリューはサブメニュー２９５に示されている。
【００４９】
このように、一致フィールド２３５の各々に対して、オートリンカーは、マルチリンク２４０の根拠を形成する関連レファレンスポインタ２８７を取得する。オートリンカーは全照合２２５フィールドバリュー２３０に対してポインタ２４０を有するので、オートリンカーはマルチリンク作成１２６で開始することができる。この点において、メニュー構造は、メニュー仕様２６５とメタデータ２６３からの照合フィールド２８９バリュー２９１に基づいて形成されるが２９３、２９５、各メニューアイテムに対するレファレンスリンクは存在しなくてもよい。レファレンスポインタがメタデータ２６３の一部として提供され２８７、オートリンクによってマルチメニューのためにポインタ２４０を提供するのに使用される場合は既述されている。しかし、多くの場合、かかるレファレンスは、顧客１０５によって提供されないので、マルチリンクの作成を助長するために作成及び／又は供給されなければならないだろう。
【００５０】
ある実施例においては、各メニューアイテムは、ターゲットレファレンスポインタに加えて追跡ポインタ２８８を供給されるであろう。追跡ポインタは、様々なマルチリンクメニューがアクセスされる方法を登録するために、アクセスされるであろう。例えば、マルチリンクメニューが選択されるとウェブブラウザーは使用パラメータ２８８（例えば、エンドユーザーのＩＰアドレス、選択アイテム（例えば、ＤＯＩ、メニューアイテムＩＤ、サブメニューアイテムＩＤなど）、通過したメニューアイテムなど）を追跡サーバーにＨＴＴＰポストコマンドを介して送信するように命令され、エンドユーザーのウェブブラウザーはターゲットレファレンスアドレス２８７を受信してエンドユーザーにターゲットレファレンスアドレス２８７で材料をナビゲートして閲覧させる。ある実施例において、追跡リンクは追跡アドレス２８８に付属するパラメータを作成する。これらのパラメータは、エンドユーザーの追跡活動を助けるのに使用可能である。ある実施例において、オートリンカーは、ＤＯＩ、メニュー仕様ＩＤ、及び、各メニューアイテムに対する階層タグを含むパラメータを生成するだろう。例えば、
http://www.trackerserver.eom/postvalues7doi://10.1009/03959607897men uID: 12345?hover:4:menuTier: 1 :2?hover:2:menuTierClick: 1 :3
ここで、追跡サーバーは「www.trackerserver.com」であり、追跡されるＤＯＩはＸであり、ＤＯＩのメニュー仕様はＹのＩＤを有し、最後のタグはメニュー選択をレファレンスする。上記例では、メニューの最初の階のメニュー選択「著者」２６４は選択され、その第２の階の「ディケンス」２６９の第２のメニューアイテムは選択された。それは、追跡サーバーに「…?menuTierClick:1:3」パラメータの掲載をもたらす。この例では、「１」は、メニュー階層の第１の階における第１の階のマルチリンクメニューの第１の選択アイテムを表し、「３」はメニュー階層の第２の階のメニューの第３の選択アイテムを表す。パラメータの「hover:2」部分は、ユーザーが第３のメニュー選択のクリック前に２秒躊躇ったことを示している。同様に、パラメータの「hover:4」部分は、ユーザーが第２のメニュー階の第２のメニューアイテムで４秒間躊躇ったことを示している。このように、全メニューアイテムは所与の階においてその順番に対してコードを与えられ、階層におけるあらゆるメニューアイテムが識別可能となる。ある実施例において、これらのメニュー選択ＩＤはメニュー仕様の一部として格納される。追跡リンク２８８は図１６−２２において後で詳述する。
【００５１】
ある実施例において、供給されたリンク２８７と追跡リンク２８８がメニューアイテム２９５内に表示された２９０マルチメディアオブジェクトに埋め困れる場合、メディアコード２８９が使用されてもよい。例えば、フラッシュ、アニメーションＧＩＦ、ビデオファイルなどはメニューアイテム内で使用及び表示可能であり２９０、これによりメニューアイテムをより多く関与可能にする２９５。
【００５２】
ある実施例において、フラッシュアニメーションは、以下のように、メニューに埋め込み可能である（添付の例に対して図１６の１６０５をレファレンス）。
<object classid=\"clsid:D27CDB6E-AE6D-l lcf-96B8-4445535400Q0\" codebase=\"http://download.macromedia.com/pub/shockwave/cabs/flash/ swflash.cab#version=6,0,0,0\" width=\"185\" height=\"32\"
ID=\"Sliockwaveflashl\" VIEWASTEXT><param name=\"movie\" value=\"images/CrossFireAnimatioπ2.swf\"><paramname=\"quality\" value=\"high\"Xparam name=\"bgcolor\" value=\"#FFFFFF\"xembed name=\"CrossFireAnimation\" src=\"CrossFireAnimation.swf\" width=\"165\" height=\"32\" quality=\"high\" bgcolor=\"#FFFFFF\" type=\''aρplication/x-shockwave-flash\" pluginspage=\"http://www.macromedia.com/go/getflashplayer\"x/objeot>
ある実施例において、ビデオは以下のようにメニューに埋め込み可能である（添付の例に対して図１６の１６１０をレファレンス）。
<div id=\"divMovie\"><OBJECT id=\"moviel\"
onmouseover=\"ジャバスクリプト:PlayItO;\"
oπmouseout?=\"ジャバスクリプト:StopItO;\" codeBase=\http://www.appIe.com/qtactivex/qtplugin.cab\
height=\"120\"
width=\"180\"
classid=\"clsid:02BF25D5-SC17-4B23-BC80-D3488ABDDC6B\"
VIEWASTEXTXPARAM NAME=\"src\"
VALUE=V'http://www.damellworks.coπi/a52/media/crosfire.mov\''><embed width=\"180\"height=\"120\"target=\"myself\"bgcoloi=\"#000000\" 
border=\"0\" controllei=\"true\" EnableジャバSript=\"true\"
autoplay=\"false\" kioskmode=\"true\" src=\"http://www.darnellworks.com/a52/media/crosfire.mov\" pluginspage=\"http://www.apple.com/quicktime/download\"> </embed> </OBJECTx/div>
ある実施例において、メニューアイテムはメディアと情報の混合を以下のように組み合わせる（添付の例に対して図１６の１６１５をレファレンス）。
<div align=\"center\" style=\" width: 18Qpx; background-color:
#ffffff;\"><IMG height=\"48\" width=\"77\"
SRC=\"images/crossfirel .jpgV'xbrXfont size=\" 1\" color=\"black\">2005
Crossfire Coupe Limited<BR></fbnt><font size=\"2V color=\"black\"><B>$34,620.00</b></fon1XbrXfont size=\" 1\"
color=\"gray\">VIN: lC3AN69L15X035266</fontX/div>
この点、オートリンカーは、マルチリンクの作成を助長する少なくとも４つの方法を有する。その一つ２５０は既に説明した２４０。顧客がレファレンスリンク２８７にメタデータ２６３を供給する場合、オートリンカーは適当なレファレンス２５０を有するＤＯＩマルチリンク記録を生成するために、それらの供給されたリンクを使用することを単に選択する。
【００５３】
メタデータ記録２６３に関連するコンテンツへのレファレンスを取得する幾つかの他の方法がある。ある実施例においては、顧客のウェブサイト及び／又はデータベース構造がリバースエンジニアされる２４５。この実施例は、一般に、人間の分析を必要とする。この実施例においては、ウェブサイトの製品クエリーフォーマットは製品を発見するのに識別及び使用される。例えば、米国特許商標庁（ＵＳＰＴＯ）政府ウェブサイト、例えば、www.uspto.govはオブジェクトターゲットを発見するのに使用可能なシンタックスを有する。例えば、特許出願の発明の名称、例えば、「情報アクセスに影響を与える登録」と発明者名、例えば、「シドマン」に基づくターゲット特許にレファレンスが必要であれば、以下のレファレンスがＵＳＰＴＯから適当なレファレンスを取得するのに使用可能となる。
http://appftl.uspto.gov/netacgi/nph-
Parser?Sectl=PTO2&Sect2=HITOFF&u=%
2Fnetahtml%2FPTO%2Fsearch-
adv.html&r=l &p=l &f=G&l=50&d=PG01 & Sl=%28sidman.IN.+AND+%28%22registration+effecting+mformation+access%22.TTL
.%29%29&OS=in/sidman+and+ttl%22registration+effecting+information+access%22&
RS=(IN/sidman+AND+TTL%registration+effecting+information+access%22)
下線部は、適当な特許出願を参照するために、メタデータフィールドバリュー２９１が挿入される場所を示している。上記の場合、ＵＳＰＴＯのクエリー構造は、名称と発明者フィールドのバリューがメタデータ記録フィールドバリュー２９１から与えられると適当な特許出願レファレンスが取得されるように、リバースエンジニアされた。この場合、特許出願番号第２００４０１６３０２０号に対するレファレンスリンクである。多くのウェブサイトとデータベースは、例えば、Amazon.comの識別可能なクエリー形式を有する。
【００５４】
別の実施例において、顧客は、クエリーウェブページ及び／又はクエリープロンプトをメタデータフィールドバリューが提供可能な２５５ものに単に提供すればよい。クエリーフィールドは幾つかの方法で形成可能である。ある実施例では、それらは手動で形成される。別の実施例では、ウェブブラウザーの自動充填機能はＡＰＩを通じで充填され、ロードされているウェブページ形式に関与する。別の実施例では、プロンプト及び／又はウェブ形式がＡＰＩを介したアプリケーション間通信を通じて充填される。別の実施例では、マクロプレイバックユーティリティ（例えば、クイッキー）がファイルからバリューを引き出し可能で継続的にバリューをクエリーフィールドに供給し、レファレンスリンクの発送及び／又は保存を有効にすることができる。更に別の実施例において、ＰＨＰ、ジャバスクリプト、パイソン、ＴＣＬなどを介して提供されるスクリプト環境は、ファイルからフィールドバリューを引き、継続的にクエリーフィールドにバリューを供給し、レファレンスリンクの発送及び／又は保存を有効にするのに使用可能である。
【００５５】
更に別の実施例においては、所与のメタデータ記録に対するフィールドバリューの全ては応答２６０を生成する検索プロンプトに配置される。かかる実施例において、メタデータバリューは、より多くのタームが検索で遭遇されると、結果をより大きい重みでランク付けするために論理的ＯＲされるであろう。ある例において、メタデータバリューは検索エンジン、例えば、Goole.comに供給されてもよく、トップリンクはレファレンスリンク２６０として選択可能である。
【００５６】
イントラコネクタ
図３は、イントラコネクタの実施例を示す混合データと論理フロー図である。図３の部分３８０は、図２において記載されたシステムのより局所的な変数を示す。本実施例において、グローバルなＤＯＩディレクトリ１１３は、通信ネットワークを通じて多数のＤＯＩ解決サーバーに亘って依然として利用可能であり分配され、それはいかなる要求部からのＤＯＩをも解決する機能を有する。特に、顧客がローカルＤＯＩサーバー３３３において起動するそれ自身のローカルなＤＯＩディレクトリ３０５を有することができるイントラネットの実施例が示されている。ある実施例において、ローカルＤＯＩサーバーは、同様に、通信ゲートウェイとして働くか、及び／又は、通信ゲートウェイに接続され、より大きい通信ネットワーク、例えば、インターネットへのアクセスを与える。ここで、リンク作成１１０は、オートリンカー及び／又はハンドルエディタによって提供されるように、ＤＯＩをローカルディレクトリ３０５に提供し、グローバルディレクトリ１１３には提供しないことを理解する。このように、ローカルＤＯＩディレクトリはより大きなグローバルディレクトリ１１３からＤＯＩ解決を要求することができ、そのより大きなグローバルディレクトリはその解決要求に対する結果を与える。しかし、グローバルＤＯＩディレクトリ１１３又はその他のエンティティがローカルＤＯＩディレクトリ３０５の要求をなす場合、ローカルＤＯＩディレクトリは何の解決情報も提供しない。代替的な実施例において、ユーザーは彼らのイントラネットへのアクセスを外界に与えることを望むかもしれず、外での解決を、グローバルに及び／又はパスワードとアクセス制御によって、可能にすることができる。
【００５７】
アーキテクチャにおけるコンポーネントはマスターメタデータ保管庫３１９である。ある実施例において、マスターメタデータ保管庫は企業コンテンツカタログであってもよい。発行社とコンテンツカタログと発行フィールドはここで例示の目的で使用されているが、イントラコネクタはいかなるコンテキストにも適用でき、発行フィールドに限定されないことに留意しなければならない。例えば、イントラコネクタは、いかなる種類の情報を有するいかなる種類の企業にも使用可能である。例えば、製品カタログを有する製品企業、ヘルスケア企業（例えば、患者関連情報、施術関連、医療関連情報などを有する病院）、顧客記録を有するサービス企業、いかなる種類の情報をも有する政府機関などである。また、イントラコネクタは、多数の独立した部署、課、企業、組織、システム、技術プラットフォーム又はその他のインターリンクターゲットの、情報が相互に関連された範囲である状況で配置されてもよい。組織は、内部情報を関連付け、それが内部情報を関連付けることを望む外的情報に結合するのにイントラコネクタを使用してもよいし、そのユーザー又はプログラムにアクセス可能にしてもよい。例えば、組織が内部情報（例えば、Ｒ＆Ｄプロセスに使用される書類）及び／又は外部情報（例えば、このＲ＆Ｄ活動に関連する外部ニュース及び研究及び／又は競合者情報）を相互に関連付けたいかもしれない内部知識管理用途を含む。コンテンツカタログは少なくとも２種類の情報、即ち、カタログにおけるコンテンツアイテム毎のユニークな識別子と各コンテンツアイテムを記述するメタデータを含む。イントラコネクトアーキテクチャは、コンテンツ発行社が既にある形態、例えば、コンテンツカタログで有する現存するシステムを利用することができる。それは、コンテンツ発行社が、発行社の企業コンテンツ統合（ＥＣＩ）発展の根拠としてそれを使用することを望むかもしれない。別の実施例においては、マスターメタデータ保管庫は、カントキュムラス１７５、ドキュメンタム、ヴィグネット、アルテイシアタームスなどの現存するベンダー供給システムに基づいていてもよい。本システムは顧客自身の制御内でホストされて操作されてもよいし、それはアプリケーションサービスプロバイダー（ＡＳＰ）ベースで与えられてもよい。これは、新しいユーザーインターフェースの具体化を要求する通常のドキュメントアセットマネージメント（ＤＡＭ）ベースの手法の代わりに、ユーザーが既に快適で、その開発が既に資金提供されている、現存するシステムを使用する長所を発行社に与える。例えば、本発行社は典型的に製品カタログ、題名データベース、又は、ユニークな識別子としてのＩＳＢＮを使用し、書籍に関する様々な種類のメタデータを含むシステムを有する。ユーザーは、これらのシステムを検索して目を通すことができる。理解するように、かかるシステムは、イントラコネクトの実施例においてマスターメタデータ保管庫としての仕様に拡張可能である。もしコンテンツカタログが存在しなければ、又は、それが存在しても単なる体系化されていない情報保管庫であり（例えば、複数のコンピュータに分配された個々のファイルなど）、体系化されたデータベースとしてでなければ、それはマスターメタデータ保管庫として機能する目的で作製されてもよい。ここでの議論は書籍／発行を一例として使用するが、原理は他の種類のビジネスにも等しく適用され、その多くは、一連のＩＳＳＮ、音楽製品のＩＳＲＣ、株のＣＵＳＩＰ、物理製品のＵＰＳなどの標準識別体系を有している。他のビジネス又は組織は組織内部、技術システムやデータベース及び／又は他の内部システム内で意味を有する非標準の所有者識別体系を使用するかもしれない。また、他のビジネス又は組織は、イントラコネクタが、コンテンツを有しないが代わりにデータベース記録、個人記録、販売記録、商取引、認証、身元検証、センサーそのほかの種類のシステムを含む関連情報又はオブジェクトに連結されることを要求するかもしれない。
【００５８】
例示的な発行社はデータベースシステム１１９のアレイを有する。製品カタログは、マルチユーザーデータベースに構築されてウェブブラウザーベースのユーザーインターフェースを有してもよい。製品カタログに加えて、発行社は、各部門のＤＡＭシステム、ファイルサーバー、画像ライブラリなどの説明だけではなく実際のコンテンツを格納する一以上の種類のシステムを有してもよい。また、それらは、著者の契約や許可、ロイヤルティ、販売、市場取引情報ビジネスのコンテンツの側面を追跡するバックオフィスシステムを有するだろう。
【００５９】
イントラコネクタは、ＥＣＩ実現のために発行社の製品カタログをマスターメタデータ保管庫３１９に変更するコンポーネントを有する。アセットとメタデータ３７１を検索するためのＵＩエクステンション、マスターメタデータ保管庫３７２に格納されているＤＯＩ、及び、データベースシステム３２０へのリンク作成部１０１及びコネクタを有するコンポーネントは内部接続を与える。この結果、イントラコネクタは、ＤＯＩを発行社のコンテンツカタログへの入力に追加し、各ＤＯＩからリンクを形成するためにＤＯＩがレファレンスするアセットに関する情報を格納するシステムの全てにＤＯＩを追加する。このように、オートリンカーは実際のリンク２５０を与えられる。リンクは単純なＵＲＬであってもよいし、それらは情報を検索するためにシステムのプログラムインターフェースを呼ぶ複雑なスクリプトの引用であってもよい。イントラコネクタは、リレーショナルデータベース、ファイルサーバー、ＤＡＭシステムなど、一般に入手可能なシステムに対して後者の種類のインターフェースを実現するコネクタコンポーネント３２０を有する。リンク作成部１１０コンポーネントは、これらのリンクの全てを構築し、ローカルＤＯＩディレクトリにそれらを格納する。ある実施例において、リンク作成部１１０はオートリンカー１２０及び／又はハンドルエディタ１１５のどちらかであってもよい。また、リンク作成部はユニークなコンテンツのためにＤＯＩリンク作成を使用してもよい。一例として、本発行社はＩＳＢＮを含む題名データベースを有してもよい。発行社は実際の本の内容をＤＡＭシステムに格納してもよく、著者契約と販売追跡のために別個のシステムを有してもよい。ＤＯＩは、如何なる種類の既に存在する識別子からも作成可能であり、ＤＯＩディレクトリにおいて幾つかの異なるリンクに向く。
【００６０】
ある実施例においては、発行社はＤＯＩを題名データベースの各ＩＳＢＮから作成することができるだろう。それらのＤＯＩの各々に対して、それはＤＡＭシステムにおけるコンテンツへのリンクとし、契約システムにおける著者契約情報への別のリンク、及び、販売追跡システムにおける販売情報への第３のリンクを有することができるだろう。かかるＤＯＩの例は、図３の表形式で一般に示される３７０。ＤＯＩ３４２は、ＤＯＩディレクトリ１１３に格納されたその３つのリンク３４４に関連付けられる３４３。一端リンクの全てが作成されると、図１−２において既に表示したように１７５、２９３、２９５、そして、図５−６において後で詳述されるように、ユーザーは、それらが必要なシステムがどれであれ情報へのリンクを追跡するために拡張されたユーザーインターフェースを調べることができる。イントラコネクタユーザーインターフェースエクステンション３７１は、製品カタログを単純なメタデータ検索及びブラウズ機能を与えることを超えてうまくいくことを可能にする。ＤＯＩマルチリンクメニューを結合することによって、それらは、ＤＯＩディレクトリ１１３、３０５においてリンクを調べることによってユーザーが実際に所与のコンテンツアイテムに対してアセット及び他の種類のメタデータを検索することを可能にする。これは、発行社のコンテンツカタログを企業コンテンツ統合アプリケーションに変更する機能の幾つかを与え、これにより、その機能を劇的に増加する。イントラコネクタの別のコンポーネントはコネクタ３２０を有する。これらは、ＤＯＩリンクを所与のシステムに対して動作インターフェースに変更する「糊」である。例えば、ＤＡＭシステム３２２へのコネクタ３２０は、ＤＡＭシステムがコンテンツアイテムを内部的に識別してアセットを検索するためにＤＡＭシステムのＡＰＩ要求を使用するのに使用する識別子を入力として取り上げるだろう。図３は、３つのリンクを実現するのに使用される２つの異なるコネクタを示す。第１のリンクは、書籍のコンテンツを格納してＩＳＢＮ３４６によってそれを識別する「バーゴ」と呼ばれるＤＡＭシステム（例えば、アルテイシアタームス、ドキュメンタム、クワークＤＭＳ、カントキュマス１７５など）のコネクタ３４３を使用する。第２のリンクは、発行社が「リブラ」と名付けた契約管理システムを構築したプラットフォームとみなされるオラクルリレーショナルデータベース３４７のコネクタを使用する。コネクタのアーギュメントＲｅｔｒｉｅｖｅＣｏｎｔｒａｃｔＩｎｆｏは、この発行社の契約システムにおそらく特別に開発され、名前が与えられた書籍に対して名前が与えられる著者の契約に関する情報検索の適当なＳＱＬクエリーを使用する。契約システムは、所与の著者と題名に対する契約が多数のＩＳＢＮをカバーすることができるので、ＩＳＢＮではなく著者と題名による契約を格納する。また、第３のリンクは、「アクエリアス」と呼ばれる発行社の販売追跡システムにこの時あるオラクルコネクタ３４８を使用する。販売追跡システムは製品を識別するのにＩＳＢＮを使用する。
【００６１】
イントラコネクタは、発行社の以下の機構の幾つかを実現可能である。ある実施例において、ユーザーはそのユーザーインターフェース３７１を通じてメタデータをマスターメタデータ保管庫１１３において検索及びブラウズすることができる。ユーザーは、発行社の現存する製品カタログ又はその他のメタデータ保管庫の検索及びブラウズインターフェースを使用することができる。ユーザーが興味のある幾つかのコンテンツを識別し、それを検索したいと思うと、ＤＯＩマルチリンクであるメニュー選択肢を見るためにアセット名又は識別子で選択／クリックする。選択肢の一つは「アセットを検索」である。ユーザーがその選択肢を選択すると、「アセットを検索」機能に関連付けられたＤＯＩリンクは、（図３の３６０を通じて詳細に説明される）発行社のＤＡＭシステムのコネクタ３２０を、ＤＡＭシステムがアセットを内部的に識別するのに使用するＩＤと共に、呼び出す。アセットのＭＩＭＥ種類は、一旦それが検索されると、どのアプリケーションがユーザーの装置でアセットを閲覧、操作又は編集するのに使用されなければならないかを決定する。ユーザーは、その後、興味のある幾つかのコンテンツを識別し、そのプレビュー又はサムネイルを見たいと思うかもしれない。そうするために、ユーザーは、ＤＯＩマルチリンクであるメニュー選択肢を閲覧するためにアセット名又は識別子をクリックする。選択肢の一つは「サムネイル／プレビューを閲覧」であってもよい。ユーザーがその選択肢を選択すると、「サムネイル／プレビューを閲覧」機能に関連付けられたＤＯＩリンクは、ＤＡＭシステムがアセットを内部的に識別するのに使用するＩＤと共に、アセットのプレビュー又はサムネイルを格納する発行社のＤＡＭシステムのコネクタ３２０への呼び出しを含む。プレビュー又はサムネイルのＭＩＭＥ種類は、どのアプリケーションがユーザーの装置でプレビュー又はサムネイルを閲覧するのに使用されなければならないかを決定する。例えば、それがＧＩＦ画像サムネイルである場合、ユーザーのブラウザーはサムネイルを表示する新しい小さなウインドウを開くことができるであろう。発行社のＤＡＭシステムはサムネイルを格納しない場合には、編集アプリケーションの代わりに、リンクは「リードオンリー」アプリケーションをユーザーの装置で使用するために設定されることができるであろう。ユーザーが興味のある幾つかのコンテンツを識別して著者の契約情報を閲覧したい場合、ユーザーは、ＤＯＩマルチリンクであるメニュー選択肢を閲覧するためにアセットの名前又は識別子を選択／クリックすればよい。選択肢の一つは「契約情報を閲覧」であるかもしれない。ユーザーがその選択肢を選択すれば、「契約情報を閲覧」に関連付けられたＤＯＩリンクは、契約システムが作品を内部的に識別するのに使用するＩＤと共に、発行社の契約システムのコネクタ３２０を呼び出す。コネクタ３２０の実施例は、それに閲覧されるべき契約のＩＤを渡して、契約システムのユーザーインターフェース３７１を使用する。代替的な実施例においては、コネクタの実施例は契約システムから情報を読み出してユーザーのウェブブラウザーにそれを表示してもよい。
【００６２】
イントラコネクタ統合
例示的な配置３６０は一般に示され、顧客環境評価３３０、マスターメタデータ保管庫（ＭＭＲ）選択３３５、コンテンツ統合設定３４０、サーバー設置３４５、ＤＯＩ及びリンク作成１１０、３５０、及び、ＵＩ強化及びシステムテスティング３５５を有する。
【００６３】
顧客環境評価３３０に関して、発行社のデータ及びネットワークインフラストラクチャ１１９は、イントラコネクタを実現するに際して、手間と実現性のレベルを決定するために調べられる。ある実施例においては、これは、統合されるべきシステムの在庫３３１、統合の実現性の決定３３２、及び、ネットワーク環境の評価３３３を有する。システム３３１の在庫管理は、ＤＡＭシステム３２２、ファイルサーバーなどを含むマスターメタデータ保管庫３１９、アセット保管庫１１９として使用されるコンテンツカタログを識別することを含んでもよい。在庫管理されるべき他のシステムは、補助情報システム、例えば、権利、許可、契約、販売及び市場取引を含んでもよい。統合の実現性を決定することに関して、要求されるであろう手動リンク作成のレベルは、これらの基準３３２に従って発行社の識別子とメタデータの品質を評価することによって決定される。量（即ち、全関連システムでアセットと他の製品情報を識別するのに十分なメタデータがあるか？）、一貫性（即ち、システムを通じて同一の用語が同一の目的に使用されているか？）及び身元の画一性（即ち、共通の識別子又はメタデータキーが異なるシステムで同一物を識別しているか？）３３３としてのかかる基準に従って発行社のネットワーク環境を評価する。（即ち、統合されるシステムの全てが関連ユーザーのデスクトップの全てからアクセス可能であるか？）、（即ち、サブネットを通じてアセットの移動を妨げるであろうネットワーク性能の問題があるか？）
マスターメタデータ保管庫（ＭＭＲ）３３５を選択及び変更する際に、発行社はＭＭＲとして使用されるべきシステムを識別することを補助される。ある実施例においては、これは、発行社が、名称データベース、製品カタログ、ウェブ製品カタログ又は製品データを格納するＥＲＰシステムなどの製品情報及びキーコンテンツを格納及び維持するのに使用する現存するシステムである。アーキテクチャコンポーネントの集合に従うことはＭＭＲの作成を容易にする。アーキテクチャコンポーネントと考慮の幾つかは、リレーショナル又はその他のマルチユーザーデータベースを使用すること、ウェブブラウザーベースのユーザーインターフェースを使用すること、及び、殆ど又は全ての関連コンテンツの入力を有することを含む。ＭＭＲは各コンテンツアイテムに対してＤＯＩを格納するように変更されなければならない。実際にシステムを変更することが不可能であれば（即ち、フィールドをデータベース体系に加える）、現存するＩＤ体系に基づいて「仮想」ＤＯＩを作成することができる（例えば、ＩＳＢＮ）。かかる環境において、ローカルＤＯＩディレクトリ３０５は、固定された所定の方法でＩＳＢＮをＤＯＩに変更する規則を理解するために構築されてもよい。例えば、ある実施例において、ＤＯＩが使用されると顧客の組織はプールを割り当てられる。顧客は、その後、プールにおいてＩＳＢＮと個々のＤＯＩとの数値関連表を作成する。ある実施例において、ＩＳＢＮは数値選別され、選別されたプールのＤＯＩに数値的に関連付けられるだろう。この方法において、イントラコネクタは、発行社の製品カタログをＭＭＲに変更することを助けることができる。発行社が満足のいく製品カタログシステムを有しなければ、第三者のメタデータデータベースに基づいてそれが作成されてもよい（例えば、それはグローバルＤＯＩディレクトリにおける顧客のＤＯＩを登録するのに使用するコンテンツディレクション社のようなＤＯＩ登録機関）。
【００６４】
コンテンツ統合設定３４０に関して、コネクタ３２０は、ＤＯＩを発行社のアセット保管庫と補助情報システム１１９にリンクするために作成される。このため、統合されるべき各システムに対する幾つかのパラメータはコンパイルされる。これらのパラメータは、システムの種類（例えば、リレーショナルデータベース、ＤＡＭシステム、ファイルサーバーなど）、ソフトウェアの種類（例えば、オラクル、アルテシア、ＦＴＰサーバーなど）、サーバープラットフォーム（例えば、ローカルシステム名、オペレーティングシステム）、システムが入力を識別するのに使用する規則、及び、ユーザーが、特定のフィールドからデータを検索するなどリンクを使用するときに採られるべき措置である。一旦この情報がＥＣＩの実施例において各システムに対してコンパイルされると、それはリンク作成部１１０において表に格納されるだろう。ある実施例において、この情報は標準コネクタをオラクルデータベースに使用することによって自動的にコンパイルされる。このコネクタは、顧客のデータベースシステムのトポロジー全体に対してクエリーをすることができ、全ての表、フィールド名、及び、キーフィールドを含む完全なエンティティ関係のトポロジーをもたらす。ある実施例において、システムは、記録の最大数が存在する場所を記録カウントを通じて観察し、その後、キーフィールドをＤＯＩに関連する記録の種類に使用する。かかる実施例において、ＤＯＩはかかるキーフィールドの各々に対して生成されてもよい。ある実施例において、ＤＯＩフィールドは、データベース表に追加され、関連ＤＯＩはデータベースに直接追加され、データベースクエリーを通じて発見されてもよい。別の実施例においては、仲介表は、キーフィールド及びＤＯＩフィールドと共に作成され、顧客のデータベースで最大数の記録に責任のある表の記録に加わるか選択するのに使用されてもよい。かかる情報は、各システムに対してコネクタコードを例示するのに使用されてもよい。
【００６５】
サーバー設定３４５に関して、ある実施例において、ジャバアプリケーションを起動可能ないかなる装置も動作する。しかし、幾つかの開発構造が使用されてもよい。ある実施例において、サーバーはローカルＤＯＩディレクトリ３０５、上記パラメータ３２０による発行社の特別のシステムのために例示されるコネクタコード、リンク作成部１１０、及び、管理ツールでロードされる。
【００６６】
ＤＯＩ及びリンク作成は、図２において十分既述した。しかし、イントラコネクタもアセット保管庫と補助情報システムのためのリンク作成に関与してもよい。既述したように、オートリンカーは、マスターメタデータ保管庫の入力と他のシステムの入力との間の対応を発見することによって（既存のＩＤ番号又はその他のキー（題名や著者など）を一致させることによって）、リンク作成をできるだけ多く自動化する。リンク作成部が起動した後、イントラコネクタは、品質制御目的でＤＯＩとリンクの人力の検討の結果を提供することによって、発行社を補助することができる。高品質で一貫性のメタデータを有する発行社は、品質制御作業が殆ど時間がかからないことに気づくだろう。
【００６７】
ある実施例において、イントラコネクタはリンクのために維持スケジュールを設定することができる。２つの定期的な維持活動は、リンクハーベスト（例えば、リンク作成部を定期的に起動してＭＭＲ及び他のシステムで新しい入力を検索し、新しいＤＯＩ及びリンクをそれにより作成する）、及び、ピングテスト（例えば、リンクの全てをテストしてそれらが依然として有効であることを確認するプログラムを周期的に起動する）を有してもよい。品質確認とピングテストに関する詳細は米国特許出願第１０／４７０，２０６号及び１０／４７０，２０７号に記載されてここで参照して結合される。
【００６８】
図１−２及びその他で既述したように、強化ユーザーインターフェース、即ち、マルチリンクメニュー１７５が入手可能で、この場合、イントラコネクタによって同様に使用される。このように、ＭＭＲのユーザーインターフェースは、それがＤＯＩを介してユーザーが全ての他のリンクされたシステムに対してナビゲートすることができるように強化される３５５。検索及びブラウズのＭＭＲのユーザーインターフェースはブラウザーベースであり、その後、イントラコネクタはジャバスクリプトコードとしてＤＯＩリンクメニューを追加する。コードは、ＤＯＩディレクトリからＤＯＩを検索し、メニュー形式でリンクを表示する。
【００６９】
例えば、検索結果表示部３５６は、ユーザーが結果リストの入力をクリックするかその上をマウスが通ると、ＤＯＩリンクメニューが現れるように３５７変更され、ユーザーがアセット、プレビュー又はサムネイル、若しくはその他の情報にナビゲートすることを可能にする。直感的ユーザーインターフェース強化は、ユーザーの見方からイントラコネクトシステムを結合する「糊」の一種である。
【００７０】
また、イントラコネクタが配置された後、発行社は、ＤＯＩの幾つかを、グローバルＤＯＩディレクトリ１１３にプロセスの一部として登録したいと思うかもしれない。それらのＤＯＩによってレファレンスされたコンテンツアセットにとって、登録がそれらの発見可能性を強化して発行社が、発行社のコンテンツインフラストラクチャに直ちに統合されるであろう広範囲な可能なオンラインコンテンツサービスを実現することを助ける。
【００７１】
マルチリンクシンジケーション
図４は、マルチリンクシンジケーションの実施例を示す論理フロー図である。マルチリンクシンジケーションが進むためには、マルチリンクが生成される必要がある１２０。マルチリンクの生成は図１−２その他で１２０既に説明した（例えば、オートリンカー）。一旦マルチリンカーが生成されると、それらはハンドルシステム１３０に格納される。これらはグローバルＤＯＩディレクトリ１１３又はローカルＤＯＩディレクトリ３０５のどちらか又は両方に格納される。ローカルＤＯＩディレクトリの場合、シンジケーションはリンクを広く拡散することができるが、ローカルシステムへのアクセスを有する者のみがレファレンスコンテンツアセットにレファレンス及び／又はアクセスすることができる。リンク生成及び保存は、マルチリンクを生成する需要がある限り、独立して継続可能なそれ自身への活動である。このように、要求される限り、以下のシンジケーション４５０、４１５以下レファレンスのコンポーネントとは独立して、これは進行することができる４５０、１２０。マルチリンクが保存されると４５０、マルチリンクへのレファレンスが生成可能となる４１５。既述したように、スクリプトはマルチリンクへのレファレンスを与えるように生成可能である。ある実施例においては、レファレンスは、スクリプトの呼び出し、例えば、ジャバスクリプトにおいてシンジケーターにリンクを埋め込むことによって生成される。シンジケーター自体はＤＯＩで識別可能であることに留意しなければならない。また、ジャバスクリプトを呼び出すシンジケータリンクは、マルチリンクの識別子がレファレンスに挿入される。一旦マルチリンクレファレンスが生成されると４１５、レファレンスはコンテンツに埋め込み可能となる。例えば、それは、ＨＴＭＬとしてウェブページ４２０に埋め込み可能となる。別の実施例においては、レファレンスはＭＩＭＥ及び／又はＨＴＭＬ形式の電子メールに埋め込み可能となる。レファレンスをマルチリンクに埋め込むことによって、マルチリンクの伝達は開始することができる。この生成と埋め込みも、マルチリンクの広がりへの要求がある限り独立に継続可能な４５１それ自身への活動であり、それはシンジケーション４５１、５２５以下レファレンスの以下のコンポーネントとは独立である。しかし、一旦レファレンスが埋め込まれると４２０、４５１又はより多くのリンク４５１へのレファレンスがなければ、マルチリンクを通じたトラバースが可能となる４２５。
【００７２】
一旦マルチリンクレファレンスがコンテンツ４２０に埋め込まれると、ユーザー及び／又はシステムがコンテンツをレファレンスでトラバースし、コンテンツの検索及び閲覧は埋め込まれたレファレンスに従事してシンジケーター４２５を評価する。シンジケーターは、マルチリンクメニューを提供するために、マルチリンクレファレンスとスクリプトの要求を受け取る。ある実施例においては、要求を受信すると、シンジケーターはＤＯＩディレクトリをレファレンスされたマルチリンク４３０に対して評価する。それをする際に、シンジケーターはＤＯＩディレクトリからマルチリンク記録を要求する。シンジケーターは、その後、メニュー仕様がマルチリンクに対して入手可能であるかどうかを決定する。ある実施例においては、シンジケーターは、マルチリンクＤＯＩを検索クエリーとして使用することによって、それ自身のデータベースでマルチリンクメニュー仕様を検索する。図１６−２０に詳細に説明されるように、メニュー仕様はエンドユーザーの活動追跡４６７の仕様を形成することによって増大可能となる。ある実施例においては、追跡統計はダイナミックかつ継続的に把握され、自動的にメニュー仕様を増大するのに使用される。別の実施例においては、メニュー仕様の増大は周期的に起こる。例えば、クロンジョブと共に特定間隔で更新される。シンジケーターがメニュー仕様４６６を発見すると、それはマルチリンク４６８のメニュー仕様を検索する。または、シンジケーターは、その階層構造４７０に基づいてＤＯＩ記録のためにメニュー仕様を生成する。メニュー仕様及び生成は図２の２２０その他において既述した。メニュー仕様が生成された後で、それはシンジケーターのデータベースに保存可能となる。ある実施例においては、メニュー仕様は、マルチリンクメニューを作成するのに必要なジャバスクリプトコードと共にＤＯＩディレクトリのマルチリンク記録に保存されてもよい。これは、入力をメニュー仕様と図５−６及びその他において詳細に説明されるジャバスクリプトコードの各々に対するマルチリンク記録に追加することによって達成可能となる。一旦メニュー仕様が取得されると４６８、４７０、シンジケーターは、マルチリンクメニュー仕様によって特定されるように、それぞれマルチリンクで形成されたマルチリンクマルチリンクメニューを生成する。これは既に図２の２２７において説明した。その説明に先立ち、ジャバスクリプト、ジャバ、パイソン、パール及びいかなるスクリプト言語も、マルチリンクレファレンスに続くユーザー選択に対して、メニュー仕様からのメニューアイテムで形成されたポップアップメニューウィジットを実際に構築して表示するために、グラフィックスライブラリーで呼び出すのに使用可能である。メニューを呼び出すＵＩウィジットを呼び出すスクリプト言語を使用すると、メニュー仕様アイテムは、ＵＩポップアップメニューウィジットがマルチリンクメニュー仕様で特定されたアイテムを表示するように、ウィジットを読み出すコードに配置される。例えば、ピーターベレシス(<http://doi.contentdirections.com/mr/cdi.jsp? doi=10.1220/productl>, <http://www.hiermenuscentral.com >)によるハイアメニューがメニュー仕様で特定されるようにポップアップを生成するのに使用可能である。
【００７３】
一旦コードが生成されると、それは要求クライアントに戻され、クライアントのウェブブラウザーはコードを解釈してマルチリンクメニューを解決されたターゲット４３５と共に表示することができる。ユーザーがマルチリンクメニューをトラバースしてマルチリンクメニューアイテム４４０のいずれかに関係すると、ユーザーウェブブラウザーはアイテムの対応マルチリンクレファレンスにトラバースするように命令され、これによってマルチリンク４４５のターゲットを表示するウェブブラウザーをもたらす。ユーザーがより多くの埋め込まれたマルチリンクレファレンス４５２に遭遇すると、彼らはコンテンツ４２５のトラバースを継続することができ、又は、マルチリンクのシンジケーションが成功裏に達成された４８６.
シンジケーターの別の側面はマルチリンクとメニューを広い分配のために生成するその能力である。ある実施例において、ユーザーは、「このリンクをあなたのサイトに追加する」メニューアイテムを有するかもしれない。それは、どこかでＤＯＩに遭遇したエンドユーザーが生成されたＨＴＭＬ（図６の６６９を参照）をコピー／貼り付けすることによって彼らのサイトに単に「このリンクを追加」（図６の６６７を参照）することを可能にすることによってＤＯＩマルチリンクの仮想的分配を許容する。このように、ユーザーが「このリンクを追加」メニュー選択肢を選択すると、「シンジケーター」ページ（図６の６６９を参照）に移動される。そこで、ＤＯＩメニューがシンジケーターによって彼ら自身のサイトで作成されるようにＨＴＭＬを彼ら自身のサイトに配置／埋め込むために、彼らはＨＴＭＬの２行をコピー／貼り付けすることができる（図６の６６９を参照）。別の実施例において、「このＤＯＩを友人に電子メールで送信」メニュー選択（図１５の１５０７を参照）は、ユーザーにＤＯＩリンクを提供する（例えば、ＤＯＩをクリップボードメモリに配置、及び／又は、新しい電子メールを作成するためにユーザーの電子メールクライアントにメッセージを伝え、ＤＯＩを電子メールの題名及び／又は本文に貼り付けることによって）。バイラル及びＰ２Ｐ分配に関する詳細は米国特許出願第１０／４７０，２０６号に記載されており、ここで参照して結合する。例えば、コンテンツ自身（及び／又は、もしあればそのＤＲＭラッパー）はＤＯＩマルチリンクを含むことができ、従って、彼らのサイトに「このリンクを追加」することをユーザーを促すことができる。ある実施例においては、「このリンクを追加する」及び／又は「このＤＯＩを友人に電子メールする」選択肢がデフォルトによってマルチリンクメニューの一部として生成され、これにより、あらゆるマルチリンクがメニュー選択肢として彼らに提供されるだろう。かかる実施例において、これらの臨時の特徴が利用可能である多くの場面がある。即ち、既述したようにコンテンツ自身に埋め込まれること（及び／又はそのＤＲＭラッパー）、検索エンジン結果内でＤＯＩを発見すること、ウェブサイトでＤＯＩを見ること、ＤＯＩをダイレクトマーケティング電子メールを介して受信すること、病院及び／又は医者の連絡を介してＤＯＩを受信すること（図１５の１５０５を参照）、ＤＯＩを音楽プレーヤー又はビデオプレーヤーの「再生中」ウインドウで見ること（図１５の１５１０を参照）、それを誰かの連絡情報に埋め込むこと（例えば、電子メール内で又は履歴書又は提案などの文書内で）、それを個人の電子メール介して受信することである。
【００７４】
ハンドルエディタ
図５−６は、マルチリンクメニューエディタ及び個人ＤＯＩの実施例を示す図である。図は、埋め込まれたマルチリンク５１４、５１５と共にウェブページを閲覧するウェブブラウザー５０１を示している。埋め込まれたコード５１４は、マルチリンクメニュー５１０の生成に責任のある画像５１５を実際にもたらす。ユーザーが彼らのカーソルを画像５１５上で移動すると、マルチリンクメニュー５１０は、記述したように、それ自身を明示する。マルチリンクメニューの構造は、メニュー仕様とマルチリンクのＤＯＩ記録による大群で制御される。既述したように、メニュー仕様が存在しない場合、それはマルチリンクＤＯＩ記録から生成可能である。既述したように、オートリンカー及び／又はシンジケーターがマルチリンクメニュー仕様を必要があれば生成することができる。更に、マルチリンクエディタもメニュー仕様を生成することができ、それはＤＯＩディレクトリにおいてＤＯＩマルチリンク記録を変更することができる。
【００７５】
図５は、ウェブブラウザー５０１を介してアクセスされるように、マルチリンクエディタ５２０を導入している。ある実施例において、ユーザーは、ハンドル５７７を編集するためにそれらのウェブブラウザー５２０を適当な場所に導くことによってマルチリンクエディタ５２０に関与する。図１６−２０において詳述されるように、マルチリンクエディタは、エンドユーザー追跡、広告配置などによって駆動されるように、メニューエントリーを変更するのに使用可能である。マルチリンクメニューに責任を有する者が、追跡情報を反映すると手動でメニューを編集することができるようにすることはそれらの効力を改善する。マルチリンクエディタにおいて一度、ユーザーはＤＯＩ５７７を供給することによって彼らが編集したいハンドル記録を特定する。マルチリンクエディタに署名すると、（例えば、ＤＯＩディレクトリ内のＤＯＩ記録にアクセスするためにユーザー名とパスワードを提供することによって）、ユーザーはＤＯＩレファレンスを供給し、ＤＯＩディレクトリはＤＯＩマルチリンク記録にアクセスしてそれを５２５ウェブブラウザーで表示するだろう。エディタは、ＤＯＩマルチリンク記録５２５のコンポーネント５３０、５３５を編集及びアクセス５５５と変更する５２７、５４０、５４５ための様々なファシリティを提供する。
【００７６】
また、マルチリンクエディタはマルチリンクメニュー仕様を生成する機構、例えば、チェックボックス５３３を提供する。ある実施例において、チェックボックス５３３は、デフォルトで全て可能となる。このため、オートリンカー、シンジケーター又はマルチリンクエディタがマルチリンクメニューの生成に参加するために呼び出され、マルチリンクメニュー仕様が入手可能でなければ、チェックボックス５３３を可能にするマルチリンク記録５２５内の全エントリーはメニュー仕様を生成するのに使用され、一方、選択されないチェックボックス５３４はメニュー仕様の一部ではない。このように、メニュー_閲覧_仕様フィールド５３３をメニュー記録に加えることによって、あらゆるマルチリンク記録がマスターメニュー仕様を有することができる。代替及び／又は追加のメニュー仕様が更なるリンクとしてメニューリンクに単に追加されても「連絡情報」５３０リンクを加えることと大差ないことに留意すべきである。
【００７７】
また、マルチリンクエディタは、アクセス制御５４４のファシリティを提供する。マルチリンクの所有者は、あるグループのあるリンクへのアクセスを制限することができる。例えば、あるリンクは所有者にアクセスされるだけであり、他のリンクは所有者に知られた者のグループにアクセスされ、他のリンクは、皆にアクセス可能である。ある実施例において、これらは、リンクにアクセスすることを許された出発点を特定するリンクエントリーを提供することによって達成される。例えば、ユーザーが特定の企業の彼の全ての友人がリンクにアクセスすることを望む場合、www.friendscompany.comのドメインをリンクが表示される唯一の出発点として与えればよいだろう。このように、ＤＯＩディレクトリ及び／又はシンジケーターがマルチリンクの解決に関与すると、その要求が、マルチリンクが閲覧されるべき出発点から来ているか来ていないかを決定することができる。従って、メニュー仕様が、リンクのアクセス制御フィールドエントリーにおいて特定されていない出発点に対するエントリーを不能にするオンザフライ編集が可能となる。別の実施例において、ＩＰアドレスは出発点として使用可能である。更に別の実施例において、ユーザー名とパスワードはリンクに関連付けられてもよく、ユーザー名とパスワードを提供することができる者のみが表示されるリンクを有する。更に別の実施例において、出発点はパーソナルＤＯＩによって表現されてもよい。別の実施例は、有効性の根拠としてデジタル証明書及び／又はキーを使用することができる。デジタル著作権管理（ＤＲＭ）の実施例に関する詳細は米国特許出願第１０／４７０，２５８号に記載されており、ここで参照して結合される。５２５に示されるように、マルチリンク記録は、個人情報を示す様々なリンクを含むことによって人を表すことができる。このように、パーソナルＤＯＩはアクセス制御の出発点として特定可能であり、パーソナルＤＯＩにおいて特定された出発点に由来することが既知のアクセス制御されたリンクにアクセスするユーザーはアクセスを得ることができる。例えば、この種のアクセス制御は患者の記録の場合に重要となり、そこでは患者が自分の医療情報に誰がアクセスを有するかを制御することになる。
【００７８】
理解されるように、パーソナルＤＯＩ記録５２５は、ユーザーが自身を表すためにユーザーによって提供されるように、様々なリンクを含んでいる。マルチリンクエディタ５２０は、ユーザーが、いかなるマルチリンク記録をも編集することを可能にする。ある実施例において、エディタ５２０は、新しい記録フィールド５４０とフィールドバリュー５４５を追加する機構を与える。例えば、ユーザーが好みの法律事務所を示すエントリーを追加することを望む場合、かれらはエディタファシリティ、例えば、テキストボックス５４０に新しいフィールド名を特定することによって追加することができる。ラベル５４０をレファレンスリンク（例えば、ＵＲＬ５４１）なしで入力することによって、マルチリンクエディタはフィールドカテゴリーを提供されたラベル以外のバリューなしで作成する。このように、これは、サブメニューが出現可能な第１レベルのメニューアイテムを生成することができる。この結果、エディタ５２０は、サブフィールド５４５及びバリュー５４６を入力するファシィリティを与える。図において、ユーザーは「モルガン＆フィネガン」を「好みの法律事務所の一種のラベルとして入力し、レファレンスリンク「www.morganfinnegan.com」５６４も入力に与える。これらのエントリー５４０、５４５、５４６を受信し、ユーザーが「提出」ボタンを押すと、マルチリンクエディタ５２０は、供給された情報をＤＯＩディレクトリに適当なフィールドをユーザーのＤＯＩマルチリンク記録に追加する命令として送信する。図６において理解されるように、一旦新しいフィールド及びバリューが提出されると、それらはユーザーのＤＯＩマルチリンク記録５２５に追加されてマルチリンク記録の一部として現れる５４０、５４５、６０５。ある実施例において、ユーザーは、彼らの電子メール署名にパーソナルＤＯＩを追加することができ、これは他人にその者の連絡その他の情報へのアクセスを単一のリンクを通じて与える。
【００７９】
マルチリンクエディタ５２０は、幾つかの他の方法で同様にＤＯＩマルチリンク記録５２５を操作することができる。説明したように、エディタ５２０は、記録及びメタデータを編集するための様々なファシリティ５２２を提供する。ユーザーが記録５５５を編集することを選択した場合、幾つかの選択肢が提供される６０５、６１５、６２０、６２５、６３０。ユーザーは、一次応答ページを変更し、新しいアイテム６１５とメニュー６２０を記録に（既述のように）、追加し、記録のバリューを再整理し、様々な他の編集（切り取り、コピー、貼り付け）を実行することができる。例えば、ユーザーがマルチリンクエディタにおいてバリューを再整理し、これによりその後のメニュー仕様の順番に影響を与えたいと望めば、彼らは記録バリュー６２５を再整理する選択肢を使用し、バリュー順番６５０を再配置するファシリティを与えられる。記録バリューの隣の「アップ」又は「ダウン」ボタンを選択することによって、記録順番とその後のメニュー仕様とメニュー順番は影響を受ける。理解されるように、ＤＯＩ記録バリューの上記追加及び再整理の後で、ＤＯＩ記録に由来するメニュー仕様から生成されたメニューは、追加と適当なメニューアイテム整理６６５を有するだろう。
【００８０】
図１８にしばらく飛ぶ。それは、マルチリンクメニューエディタの図式的な実施例を示す図である。この代替的な実施例は、マルチリンクメニューエディタ１８０５と結果としてのマルチリンクメニュー８１０の構成を示す。エディタは、メニュー階層の各メニュー階１８３０における追加的なメニュー選択アイテム１８２５の作成を見込んでいる。メニューアイテムは単純に選択可能であり、コンテンツは編集可能である。また、使用制限がいかなる所与のメニューアイテム１８３５に対しても付加されることができる。例えば、メニューアイテムは、特定された期間に対してその位置に留まるように配置されてもよい（例えば、２５０インプレッション、５０クリック、２ヶ月等）１８３５。かかる一例において、一旦メニューアイテムが２５０エンドユーザーによって閲覧されるか５０回クリックされると、それはその位置から除去されて再配置される。かかる制限はモデルの広告と広告の回転に有用である。ある実施例において、これらの制限は、メニュー仕様の生成と共に「制限」フィールドに自動的に追加される。かかる実施例においては、オートリンカーはメニューアイテムのスポンサーの地位に基づいてインプレッションとクリックに対する制限を設定することができる。例えば、広告者は、メニューアイテム広告、広告の文言、マルチメディアコマーシャルなどの配置を命令するかもしれないだろう。オートリンカーは、広告に対する広告者の支払いに基づくメニューアイテムを与えられる。追跡情報が維持されると、使用統計は使用制限に比較されてメニューアイテムの変更を引き起こしてもよい。使用制限に到達すると何が起こるかについて規則が設定されてもよい。ある実施例においては、使用制限に到達すると、メニューアイテムはマルチリンクメニューから除去される。別の実施例に置いては、使用制限に到達すると、メニューアイテムはマルチリンクメニュー階層内でより目立たない場所に移動される（例えば、それは階層内で下に及び／又は深くに移動されてもよい）。
【００８１】
ＩＰアドレッシング
図１８から図７に戻って、ユーザーはアドレスを介して通信ネットワークにアクセスする。アドレスは場所を表す。ユーザーは通信ネットワークにおいて、情報を探し出すべく場所から場所へ移動する。一般的な通信アドレス方式はＩＰアドレスを用いる。ＩＰアドレスは現実の世界では住所に例えることができる。ＩＰアドレス自体は、例えば、２０９．５４．９４．９９といった一連の数字であり、通常は、例えば、www.contentdirections.comというような関連する名前を有する。分散型データベース・レジストリは名前とＩＰアドレスの関連するペアを維持し、関連する名前を対応するＩＰアドレスへと解決する役目を担う。これにより、ユーザーは、２０９．５４．９４．９９といった一連の数字を暗記して用いる代わりに、例えば、www.report.comといった名前を覚えておいて使用することが可能になる。ＩＰアドレスの名前解決を支援するこれらの分散型データベースは、一般的にドメイン・ネーム・サーバー（ＤＮＳ）と呼ばれている。
【００８２】
ＩＰアドレスを、アドレスに更なるナビゲーション情報を付加したユニバーサル・資源・ロケーター（ＵＲＬ）として具現することが一般的である。ユーザーは、ＨＴＴＰを用いてＵＲＬに保存されている情報をアクセスするためにソフトウェアを用いてもよい。一例を挙げると、ユーザーが「ｈｔｔｐ：／／ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／ｒｅｐｏｒｔｓ／１９９９／ＩｎｃｏｍｅＳｔａｔｅｍｅｎｔ．ｈｔｍｌ」とウェブ・ブラウザーに指定する。すると通常この更なるナビゲーション情報である「／ｒｅｐｏｒｔｓ／１９９９／ＩｎｃｏｍｅＳｔａｔｅｍｅｎｔ．ｈｔｍｌ」がコンピュータ・サーバー内の特定の保存場所を提示する。この更なるナビゲーション場所は、現実の世界では番地よりも詳しい、会社名や部署名、部屋番号等を含む住所に例えることができる。この更なるナビゲーション場所の取り扱いや解決は、通常ＤＮＳではなく解決されたＩＰアドレスにある情報サーバーにより行われる。例えば、ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍに対して解決したアドレスである１２３．１２３．１２３．１２３にある情報サーバーは、サーバー内のローカルの場所「／ｒｅｐｏｒｔｓ／１９９９／ＩｎｃｏｍｅＳｔａｔｅｍｅｎｔ．ｈｔｍｌ」にある情報を解釈し返送する。情報サーバーとは、通信ネットワークと特定のＩＰアドレスにあるコンピュータ・サーバーの間の通信を可能にする手段である。情報サーバーの商業的な例としては、アパッチが挙げられる。情報サーバーは、企業内の該当部署へ郵便物を仕分ける企業のメール室に例えることができる。
【００８３】
図７は、ＩＰアドレッシング・メカニズムは、情報が通信ネットワーク上で移動する間に、情報との関連を維持しないということを図示している。一般的にウェブ・ページのリンクにはＨＴＴＰを用い、ＨＴＴＰはＩＰアドレッシングに依存している。従って、ＵＲＬリンクは単に通信ネットワーク上の場所を示すだけで、必ずしも特定の情報と関連しているわけではない。例えば、ｗｗｗ．ｎｅｗｓ．ｃｏｍをレファレンスするＵＲＬリンクによってＵＲＬとｗｗｗ．ｎｅｗｓ．ｃｏｍで入手可能な情報を関連付けてもたらされる情報は、その場所では毎日情報が更新されるため、異なる情報となる。多くの場合、企業が情報を移動させたり、事業を移動させたり、廃業したりすると、場所そのものが消失する。
【００８４】
例えば、ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ７０８という場所に存在した「１９９９年度売り上げ」というタイトルのレポート７２２が、当該情報があるエンティティから別のエンティティに売られたり、アーカイブされたり、あるいはその他様々な理由で、例えばｗｗｗ．ｒｅｐｏｒｔ−ａｒｃｈｉｖｅｓ．ｃｏｍ／１９９９／Ｏｌｄ−ｒｅｐｏｒｔ．ｈｔｍｌ７１０という場所に移動することもある。ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ７０８という場所に存在したレポートは５００万ウェブ・ページ及び場所７４４をレファレンスするＵＲＬリンクを有したかもしれず、ユーザーが当該情報へのアクセスを試みると、その場所は既に存在しないため及び／又はその場所はユーザーが所望した情報を含まないため、ユーザーは「４０４ファイルがありません」のエラー７０９を受け取る可能性もある。結果としてエラーが出るのは、ＤＮＳは常にユーザーの要求を場所へと解決するよう設計されているためであり、またＤＮＳはＵＲＬと特定の情報のインスタンス化との関連を維持するように設計されていないためである。
【００８５】
図７の先頭はウェブ・ページ７０１、ユーザーが入力したアドレス７０２、ドキュメント７０３及びメモリ・デバイス７０４を描写し、それぞれ一つの情報（「１９９９年度売り上げ」のレポート７２２）をレファレンスするためにＵＲＬを、従ってＩＰアドレッシングを用いる。次に図７では、情報７２２は元の場所７０８（例えば、ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ）から図７の新しい場所７１０（例えばｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ａｒｃｈｉｖｅｓ．ｈｔｍｌ）へ移動する。図７において、この結果として当該の場所をレファレンスする全てのＵＲＬ２４４のブレーキング７０５−７０８が起こり、恐ろしい「４０４ファイルがありません」のエラー７０９を、当該の場所（ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ）７０８へレファレンスする全てのユーザーとＵＲＬに提示することになる。
【００８６】
ハンドルシステム
一旦一つの情報がＤＯＩに割り当てられ利用可能になると、ＤＯＩシステムはＤＯＩのユーザーがアクセスを望むものを解決できるようになる必要がある。ＤＯＩの解決を成し遂げるために用いる技術は、「ハンドル・システム」としてより広く知られており、以下により詳しく説明する。ＤＯＩハンドブックには基本的なＤＯＩの一般的な概要が記載されている。一言で言えば、ハンドル・システムはプロトコルのオープンなセット、ネームスペース及びプロトコルの実施化を含む。プロトコルは分散型コンピュータ・システムが、デジタル・コンテンツのハンドル（ＤＯＩ等）を保存し、コンテンツの所在を確認しアクセスするため、当該コンテンツに関係する情報の所在を確認しアクセスするため、あるいは当該コンテンツに関連するサービスの所在を確認しアクセスするために（即ちそのようなサービスへのインターフェースを提供するために）必要な情報へと、それらのハンドルを解決することを可能にする。必要に応じて、ＤＯＩを変更することなく識別されたコンテンツの現状を反映するために、この関連情報を変更することができるので、場所やその他の状況の情報の変更を経てもアイテムの名前が存続することが可能になる。一元管理されたＤＯＩ登録機関と共に、ハンドル・システムは長期にわたるネットワーク上の情報及びサービスの信頼性のある管理のための、汎用且つ分散型のグローバル・ネーミング・サービスを提供する。本開示全体にわたり、ＤＯＩシステムを介してアクセス可能になった「ソース」、「コンテンツ」及び／又は「情報」とは、特定が可能な全てのコンテンツ、ソース、情報、サービス、トランザクション及び記事、書籍、無形オブジェクト、音楽アルバムを含む著作物、人物、有形で物理的なオブジェクト、その他及び／又はそれらの選択された個別の部分及び／又はそれらの組み合わせを更に含む、から成り得ることに注意することが重要である。アクセス可能な情報は、サービスやトランザクションを開始するアプリケーションや、選択のメカニズム及び／又はその他を提供するアプリケーション等へのＵＲＬでもよい。
【００８７】
ある非限定的な例では、ＤＯＩは、ソーシャル・セキュリティ番号、電話番号及び／又はその他のある人物を識別する情報と関連付けられることすらあり得る。かかる実施例において、メタデータはＤＯＩ記録に格納されてもよい。
【００８８】
ある実施例では、メタデータは、特定種類のハンドルバリュー、例えば、ＤＣ．ＴｉｔｌｅとしてＤＯＩ記録に直接保存される。かかる実施例は、多数の要求が正しいバリューを必ず引くようにソフトウェアをキャッシュすることを不能にすることを要求する。その後、メタデータは、ハンドルバリューの検索を通じて特定種類を識別することによって検索可能となる。かかる方法において、メタデータは、パーソナルＤＯＩ、ＤＯＩ医療記録、ＤＯＩＲＦＩＤ、発行メタデータ、デジタル著作権管理メタデータなど、しかし、これらに限定されないＤＯＩの如何なる種類に対してＤＯＩ記録に格納されてもよく、全て、データの実際の保管庫としてＤＯＩ記録を使用することができる。
【００８９】
かかるＤＯＩ記録保存をパーソナルＤＯＩの状況で適用することによって、かかる実施例はユニバーサルに入手可能な個人識別子をもたらす。ある実施例において、人は幾つかのユニバーサル個人識別子を有してもよい。例えば、外科医はユニバーサル外科医識別子を有してもよい。この識別子は、外科医の雇用者番号、免許番号、連絡情報、専門化説明情報、社会保障番号などを有してもよい。同様に、患者は、氏名、連絡情報、医療記録参照、アレルギーリスト、医療状態のリスト、社会保障番号などの有するユニバーサル患者識別子を有してもよい。かかるユニバーサル識別子は、医者及び患者が単一の識別子を提供することを許容する際に、個人情報をフォームに記入する必要がなくなるので大変有用であろう。別の実施例においては、ユニバーサル個人識別子は、アクセス制御と共にマルチリンクの形態をとることができる。かかる実施例においては、人はそれ自身の一般情報と、異なる立場と役割において彼らが個人情報を提供することが必要である状況に対する情報を有することができる。例えば、ユニバーサル個人識別子は、マルチリンクの一側面としてのより一般的なユニバーサル個人識別子を有することができる。外科医の場合、マルチリンクの別の側面に含まれるユニバーサル外科医識別子情報を有することができる。更に、外科医は、同様に、時には、患者であり、このように、マルチリンクの別の側面として含まれるユニバーサル患者識別子を有してもよい。アクセス制御は、許可されたユーザにのみ様々なコンポーネントの側面へのアクセスを制限するのに使用可能である。アクセス制御は、図５及びその他で詳細に説明する。例えば、外科医は彼自身のユニバーサル個人識別子をウェブサイトに提供することができ、外科医の雇用者ではないそれにアクセスする人のグループは、マルチリンクのより一般的なユニバーサル個人識別子の側面のみを閲覧するに際して制限される。しかし、外科医がユニバーサル個人識別子を仕事で使用すると、マルチリンクのユニバーサル外科医識別子のコンポーネントは許可されたグループによってアクセス可能となるであろう。
【００９０】
別の非限定的な例においては、ＤＯＩはソフトウェア・モジュール、プログラミング「オブジェクト」またはその他のネットワークに基づく資源の何かと関連付けられたりもする。更に、実際の製品（現在ＵＰＣやバーコードで識別されている品物等）のオンラインでの表示を含むほとんど全てのものを表示するためにＤＯＩを用いることができる。そのような例では、ＤＯＩはある製品を説明したり販売したりしている製造者のカタログ・ページへと解決することができ、多重解決シナリオにおいては、ある品物を修理してもらうにはどこへ行けばよいか、交換用の部品はどこへ行けば見つかるか、新製品あるいは交換用の製品はどのようなものか、どのような価格またはリースのオプションがあるのか等、当該オブジェクトに関係する全てのサービスへと解決することができる。ＤＯＩを実施するその他の実施例に含まれるのは、通信ネットワークを介して分散型の方法で動作することができるソフトウェアの異なるモジュールの表示、ボイス・オーバーＩＰ技術のための電話番号、遺伝子配列、医療記録及び／又はその他の恒久的な記録（ＤＯＩは、証明書又は暗号解読鍵を呼び出すこともある暗号化及び／又はその他の方法で保護された恒久的な記録に特に有用）及び／又は同様のもの、である。別の実施例ではＤＯＩは、例えば現在の株価、（株及び／又はその他全てのオークション及び／又は為替の）最新の競売価格や売り出し価格、（別の過去の年次報告書には異なるＤＯＩが割り当てられているのに対して）企業の最新の年次報告書、及び／又はその他のようなもので、しかしこれらに限定されない一時的及び／又は動的なバリューの恒久的な場所を表す。
【００９１】
ユーザーはデジタル・オブジェクト識別子（ＤＯＩ）を介して情報にアクセスし得る。ＤＯＩは情報そのものに関連付けられている（即ち情報自体の名前である）。ＤＯＩは「ハンドル」のインスタンスであり、「ハンドル・システム」の枠組みの中で動作する。ＤＯＩは永続的に関連付けられた情報へのアクセスを可能にする。ＤＯＩは、一連の文字の後にセパレーターが付き、その更に後に一連の文字が付いたもので、例えば１０．１０６５／ａｂｃ１２３ｄｅｆというようになる。注意すべき、そして再び強調すべきことは、本開示は「ＵＲＮ」「ＤＯＩ」「ハンドル」といったＵＮＩの特定のサブ・タイプについて記載することもあるが、本開示はより一般的なタイプのＵＮＩにも同等に適用されるものであり、従って特に断りの無い限り本開示はＵＮＩのあるサブ・タイプに言及する場合はＵＮＩ全般にわたって適用されるものと見做されるべきものである。更に、今日使用されているハンドル・システム、ＤＯＩ及びそれらの支援技術や仕様は、本開示の意図したフォーラムではあるものの、本開示は最新の、または今後考案される仕様やシステムに基づいた他のフォーラムにも応用できることを意図していることに注意すべきである。
【００９２】
ＤＯＩ
情報にアクセスするためにＤＯＩを使用しているユーザーは、ＤＯＩが関連付けられた情報のみを解決しアクセスすることを知っている。場所をレファレンスするＵＲＬとは対照的に、ＤＯＩとは情報に対する名前であり、その情報の場所やその他の属性、と共に関係するサービスをも見るために用いることができる。情報とは、電子書籍、音楽ファイル、ビデオ・ファイル、電子ジャーナル、ソフトウェア及び前記のコンテンツの一部及び／又はそれらの組み合わせも含む情報と共にコンピュータで読み取り可能なファイル全てを含むと考えられる。電子コンテンツは通信ネットワーク上で利用可能となっているので、これ以降本出願書はそのような利用可能な情報は、通信ネットワーク上で発行されたものとみなすということに注意されたい。
【００９３】
ＤＯＩは、通信ネットワーク上で利用可能な情報に与えられた恒久的で永続的な識別子で、仮にコンテンツあるいは関連するデータの場所（即ちＵＲＬ）、フォーマット、所有権等が変更されたとしてもユーザーが関連データにアクセスすることができるように、電子的形態で登録されている。ＤＯＩまたはハンドルは、ＵＲＬの代わりにユーザーに配信できる。ユーザーは、ハンドル対応のウェブ・ブラウザーに、ＵＲＬハイパーリンクと同様にＤＯＩを選択したり入力したりすることにより、ある特定のＤＯＩに関連付けられた情報にアクセスする。例えばｗｗｗ．ｃｎｒｉ．ｏｒｇから入手可能なハンドル・システム・プラグイン等のブラウザー・プラグイン・ソフトウェアを用いて、数多くの種類のブラウザーをハンドル対応にすることが可能である。ＤＯＩに関連付けられた情報にアクセスするためのそのような試みにより、資源の現在の所在を確認する自動のプロセスが起動する。当該資源の現在の場所は、ハンドル・システムによって利用可能な一元管理されたディレクトリ内の当該資源のＤＯＩに関連付けられており、それが今度はユーザーを（即ちユーザーのウェブ・ブラウザーを）当該資源の現在の場所へと導く。この誘導はしばしば、選択されたＤＯＩに関連する現在のＵＲＬと、対応する情報を返信することによって実行される。
【００９４】
図８はＤＯＩを介した情報へのアクセスを上記の図７と対比して図示している。最初に、登録プロセスを経て情報（「１９９９年度売り上げ」のレポート２２２）にＤＯＩが与えられる。ＵＲＬを用いる代わりに、ユーザーはＤＯＩを用いウェブ・ページ８０１、ウェブ・ブラウザーへのタイプ入力８０２、ドキュメント８０３、デバイス８０４、バーコード８０６及び／又はその他を介して当該情報のレファレンス８４４を行う。ユーザーがＤＯＩリンク４４４を行うと、それらは一元管理されたＤＯＩディレクトリ８１１において解決され、要求したユーザーは情報７２２の最初の場所（ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ７０８）へのＵＲＬリンク７４４を与えられる。当該情報が最初の場所（ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ｒｅｐｏｒｔ．ｈｔｍｌ７０８）から新たな場所（ｗｗｗ．ｒｅｐｏｒｔ．ｃｏｍ／１９９９／Ａｒｃｈｉｖｅｓ．ｈｔｍｌ７１０）へ移動８３４すると、当該情報の発行社８１０は新たな場所をレファレンスする更新されたＵＲＬ２４５を送ることにより、ＤＯＩ一元管理ディレクトリ８４５に当該情報の新しい場所を知らせる。それ以降、ユーザー８０１−８０４がＤＯＩリンク８４４を介して当該情報にアクセスを試みると、ＤＯＩディレクトリは更新されたＵＲＬ７４５を通して適正に新しい場所７１０を提示する。
【００９５】
上記のように、ＤＯＩは情報のみならず、その一部を識別するために用いることもできる。例えば、ＤＯＩシステムによれば、１冊の書籍が一つのＤＯＩを有することが可能な一方、その書籍のそれぞれの章が別の、それぞれの章を識別するための固有のＤＯＩを有することもあり、更にはその書籍中の図面一つ一つがそれら図面を識別するための固有のＤＯＩを有することも可能である。言い換えれば、ＤＯＩシステムによると、コンテンツ発行社の希望通りに様々な細かさのデータの塊として情報を識別することができる。なお、ユニバーサル・プロダクト・コード（一般的には消費者向け製品の「バーコード」として表示されている）によって例えば、スーパーのレジ、在庫コンピュータ、財務システム及び流通業者が現実の世界でサプライ・チェーンを自動化することが可能になるように、本開示はＤＯＩを用いて世界中の全ての電子発行エージェントがインターネットを介したデジタル・コンテンツ（及び当該コンテンツに対する権利のライセンス）の販売を効率的な方法で自動化することを可能にするメカニズムを提供すると想定している。何故ならば、販売可能なコンテンツのそれぞれが世界で唯一のＤＯＩを有しており、それをエージェント同士の取引において製品の識別コードとして使用することが可能だからである。
【００９６】
ハンドル・システム
ハンドル・システムは、効率的でユーザーに分かり易い利用を可能にするための前もって決められた方針の一群を採っており、そのうち幾つかを以下に挙げる。発行社（又はより一般的にはＤＯＩ所有者又は登録者）がオペレーション・コストを負担して、ＤＯＩ解決のためのハンドル・システムの使用がユーザーには無料となるのが理想的である。ＤＯＩは全て世界的なＤＯＩ機関に登録される。登録者は、登録したＤＯＩに関する状態データ及びメタデータを維持する責任がある。ＤＯＩのシンタックスは標準化されたシンタックスに準じる。使用にあたっては、ＤＯＩはオペーク・ストリング（ダム・ナンバー）になる。ＤＯＩ登録機関はＤＯＩの指定、登録、ＤＯＩに関連するメタデータの申告を管理する。
【００９７】
図９は、ハンドル９００の概略図である。ハンドル９００は二つのコンポーネントである、プレフィックス９０１とサフィックス９０２を有する。プレフィックス９０１とサフィックス９０２は、フォワード・スラッシュ９０７により区切られている。ハンドル９００には、印刷できる文字であれば、今日書かれたり使用されたりしているほとんど全ての主要な言語のどれを取り入れてもよい。プレフィックス９０１にもサフィックス９０２にも特に長さの制限はない。結果として、利用可能なハンドルの数はほとんど無限であると想定される。プレフィックス９０１とサフィックス９０２の組み合わせを確実に唯一固有なものにすることが、ハンドル・システムの完全性を維持するためには重要である。そのため、ＤＯＩ登録機関は発行社に固有のプレフィックス９０１を与え、一実施例ではその登録機関が、指定するサフィックス９０２もまた確実に固有のものであるようにする責任を発行社に課す。これはユーザーのクライアント・コンピュータ・システム上で動作している登録ツールによって達成され得る。別の実施例では、本開示全体にわたって記載しているように、様々なサフィックス生成アルゴリズムを適用することによって、登録機関がサフィックス９０２が固有なものもであること確実にする。登録機関とハンドル・システム管理者は共に、新しいハンドルについては全てその固有性を確認してからハンドル・システムに入れる。登録機関はハンドル・システムにＤＯＩ記録を入れ、それを受けてハンドル・システムはＤＯＩディレクトリを介してＤＯＩ解決要求を処理する。
【００９８】
プレフィックス９０１自体は、プレフィックス・セパレーター９０６、即ちピリオドにより区切られる二つのコンポーネントを有する。ハンドル・プレフィックスの第一の部分はハンドル・タイプ９０４で、第二の部分はハンドル・クリエーター９０５である。ハンドル・タイプ９０４は、どのようなタイプのハンドル・システムが使用されているかを識別する。ハンドル・タイプ９０４が「１０」で始まる場合、当該ハンドルはＤＯＩであると識別され、ハンドル・システムの他の実施タイプではないと分かる。ピリオドにより区切られたプレフィックスの次のコンポーネントであるハンドル・クリエーター９０５は、ＤＯＩの登録を希望する団体に与えられる番号（または文字列）である。これら二つのコンポーネント９０４と９０５が一緒になり、ＤＯＩの固有の発行社プレフィックス部分を形成する。どの団体が申請するハンドル（より詳しくはＤＯＩ）プレフィックスの数にも制限はない。結果として、例えば発行社は一つのＤＯＩプレフィックス９０１を有してもよいし、ジャーナルごとに異なるプレフィックスを有することも、そのジャーナルの刷り込み毎に一つのプレフィックスを有することもできる。通常プレフィックス９０１は単純な数字列だが、ハンドル・システムの範囲はそれに限定されるものではない。従って、プレフィックス９０１にアルファベットやその他の文字を用いてもよい。
【００９９】
サフィックス９０２は固有の英数字列であり、特定のプレフィックスと共に、固有情報を識別する。発行社のプレフィックス９０１と発行社の提示する固有のサフィックス９０２の組み合わせにより、ＤＯＩ番号の一元割り当ての必要性を免れる。サフィックス９０２は、当該発行社がプレフィックスと共に登録した他のどのサフィックスとも異なる固有のものである限り、当該発行社の選択する如何なる英数字列でもよい。
【０１００】
図９は、ＤＯＩ９９０の別の実施例を示しており、図中ではテキストブックのＩＳＢＮ番号がサフィックス９０２として機能している。従って便宜上、元と成るコンテンツの発行社は、サフィックス９０２として元のコンテンツに合致する他のどのような識別コードを選択してもよい。
【０１０１】
強化ＤＯＩ
図９は更に、強化ＤＯＩ９１０グラマーを図示している。ＤＯＩグラマーを強化する非限定的な実施例は、強化されたプレフィックス９１１として具現される。しかしながら、別の及び／または相補的な強化されたサフィックス（図示はしていない）を同様にＤＯＩ９００に付けてもよいと、全面的に意図されている。強化されたサフィックス９１１は、強化グラマー・ターゲット９１７と強化セパレーター９１４から成る。強化セパレーター９１４は＠という記号であるが、当然のことながら、他の文字を強化セパレーターとして指定しても良い。強化グラマー・ターゲット９１７自体は、強化セパレーター９１４以外の任意の文字列である。強化グラマー・ターゲット９１７は、ＤＯＩ９００が特定の情報を多重の種類で解決する目的で用いられ、本開示の中で詳しく述べる。さらに強化された実施例では、強化グラマー・ターゲット９１７自体が更に、強化グラマー動詞５１２と、例えばピリオドのような強化ターゲット・セパレータ９１６によって分離される強化グラマー・ターゲット・オブジェクト９１３から成り得る。もちろん、強化ターゲット・セパレーター９１６は、任意の文字で指定できる。一実施例では、強化グラマー動詞９１２は修飾語として働き、一つのＤＯＩのための複数の多重解決ターゲットの中から選択し、強化グラマー・ターゲット・オブジェクト９１３は、更なるアクションのために、ターゲット・オブジェクト及び／またはハンドル・システム解決サーバーへと手渡される一つのバリューである。
【０１０２】
ハンドル・システム・メタデータ
ＤＯＩ９００は識別番号に過ぎず、必ずしもそれに関連付けられた情報について何らかの情報を伝達するわけではない。結果として、ＤＯＩにアドレスする情報に関する追加情報を補足して、ユーザーが効率的且つ分かり易いサーチを行い、所望のコンテンツを通信ネットワーク上で入手できるようにすることが望ましい。情報を識別し易くするために、本発明は識別される情報の説明的なデータであるメタデータを使用する。メタデータはＤＯＩに関連するどのようなデータ構造であってもよいが、一実施例によると、メタデータは発行された情報を正確且つ簡潔に識別できる幾つかの基本的なフィールドから成る。この実施例によれば、メタデータは書籍の国際標準図書番号（ＩＳＢＮ）等のレガシー識別スキームからのエンティティと関連する識別子、発行されたコンテンツのタイトル、発行されたコンテンツの種類（書籍、音楽、ビデオ等）、当該コンテンツはオリジナルか派生したものか、コンテンツの主要な著者、コンテンツ作成の際の主要著者の役割、発行社の名前及び／またはその他等から成る。異なる種類のコンテンツはそれを説明する異なるデータを必要とするため、異なる種類のコンテンツには異なるメタデータを使用することを想定しているということがＤＯＩシステムの特徴の一つである。
【０１０３】
一実施例によると、メタデータはＤＯＩシステムのユーザー全てに利用可能となっており、それによってユーザーは特定のＤＯＩが識別するエンティティの基本的な説明を検出することが可能である。この基本的な説明によりユーザーはコンテンツを発行したエンティティの、あるいはコンテンツ自体の、幾つかの基本的な事柄を理解することができる。
【０１０４】
結果として、ＤＯＩが何の情報を識別するのかを調べるには、それを解決した後、関連するメタデータをレビューすることが望ましい。何故ならばＤＯＩはメタデータを識別するコンテンツや、同じまたは関係するコンテンツに関する別のメタデータとリンクするからである。一実施例では、メタデータによりＤＯＩ９００が識別する情報と共に、その明確な仕様の認識が可能になる。またメタデータにより当該情報とネットワーク上のその他の情報（及びそれらのエンティティに関するメタデータ）とのインターラクションが可能になる。
【０１０５】
ＤＯＩ情報アクセス
図１０は、ＤＯＩハンドル・システムにＤＯＩを提示するだけでユーザーが所望の情報にアクセスできるようにする解決メカニズムの概要を示している。本状況での解決とは、識別子をネットワーク・サービスに提示し、引き換えに当該識別子に関連する最新の情報を一つ以上受け取ることを含む。図１０に示すＤＯＩシステムの一実施例では、ユーザーはウェブ・ブラウザー１００１クライアントし、特定のＤＯＩ１００２が識別するコンテンツを指す。このＤＯＩ１００２は関連するＵＲＬを一つしか持っていないため、そのＵＲＬへと解決されるはずである。その結果、ユーザーが特定のＤＯＩ１００２が識別する基底コンテンツを要求すると、ユーザーは所望のコンテンツがあるＵＲＬ１００３へと導かれる。
【０１０６】
従って、この機構により情報の場所が変更されても、アクション可能な識別子としてエンティティの名前を維持することが可能になる。発行社がコンテンツの場所を変更した場合、発行社はハンドル・システムのデータベース内のＤＯＩエントリーを更新するだけで既存のＤＯＩ１００２は確実にコンテンツの新しい場所を提示する。結果として、コンテンツの場所は変更されてもＤＯＩは変更されず、ユーザーは既存のＤＯＩを用いて新しい場所にある当該コンテンツにアクセスすることが可能である。
【０１０７】
図１０は、ユーザーがＤＯＩを用いて、同一のＤＯＩが識別した同一のコンテンツの利用可能な複数のコピーの中から、コンテンツへの要求と共にコンテンツについてのデータの場所と（例えばコンテンツの購入といった）当該コンテンツに関連するサービスを解決するＤＯＩシステムの概要を示している。従って、汎用コンピュータであるユーザーはウェブ・ブラウザー１０００を用いて必要なＤＯＩ１０３０を提示する。ＤＯＩ１０３０は、所望のサービス１０３５の種類を説明するように構築することもできる。その結果、ＤＯＩシステムはユーザーがアクセスを望む特定のコンテンツ１０４０へと解決することが可能になる。
【０１０８】
ある実施例において、ハンドルシステムにおいて所与のＤＯＩに対する多重解決選択肢を保存するフォーマットは、ＤＨＴＭＬ及びジャバスクリプトを使用してブラウザーに階層ドロップダウンメニューとして現れてもよい。
【０１０９】
マルチリンクメニューの一例を１０４３に示す。多重解決ハイパーリンク１０４４をクリックすると、ユーザーには、一以上の低い階層１０４３であるリンク選択肢のリストが提供される。例１０４３において、ユーザーは、Amazon.comで電子書籍のマイクロソフトリーダー版を買うリンクを選択するための２つのサブメニューをトラバースした。
【０１１０】
図示するように、このメニューはＤＨＴＭＬとジャバスクリプトで具体化されたウィジットである。ウィジットはハンドルシステムから取得されたデータでロードされ、以下に詳細に説明するように、ジャバスクリプトデータ構造に変換される。ある実施例において、ハンドル記録のフォーマットは以下の５つのコンポーネントを有する。
【０１１１】
１．  多重解決記録は、ＭＵＬＴＩＲＥＳとＭＵＬＴＩＲＥＳ＿ＭＡＰの２つの新しいハンドルデータ種類に割り当てられる。
【０１１２】
２．  所与のハンドルは、（異なるインデックスバリューで区別される）多重ＭＵＬＴＩＲＥＳを有し、選択的に一のＭＵＬＴＩＲＥＳ＿ＭＡＰを有することができる。
【０１１３】
３．  各ＭＵＬＴＩＲＥＳバリューは、等しい符号（ＡＳＣＩＩ０ｘ３Ｄ）によって確定された２つの論理ユニットとラベルとＵＲＬを有する。ラベル部は、ＵＲＬハイパーリンクのための表示されたテキストとして使用される。ＵＲＬが関連しない場合（例えば、サブメニュー名）、ＵＲＬ部は省略される。
【０１１４】
４．  ＭＵＬＴＩＲＥＳ＿ＭＡＰバリューは、メニューの階層と、ＭＵＬＴＩＲＥＳバリューによって規定されるサブメニューを記述する。ＭＵＬＴＩＲＥＳ＿ＭＡＰバリューは、カーリーブレイスによって規定された帰納的メニューリストを有する。リストされたアイテムはＭＵＬＴＩＲＥＳバリューのインデックスである。
【０１１５】
５．  ＭＵＬＴＩＲＥＳ＿ＭＡＰバリューがなければ、平坦な階層が仮定され（即ち、サブメニューのない）、アイテムはＭＵＬＴＩＲＥＳインデックスバリューの順番で表示される。
【０１１６】
以下の表は、１０４３で示される多重解決リンクに対するハンドル記録の抜粋を示している。ＤＯＩアプリケーションはこのハンドル記録を取得し、正しい多重解決選択肢をユーザーに提供するのに必要なラベルとＵＲＬを抽出することができる。
【０１１７】
種類            バリュー
.                  .     .
.                  .     .
.                  .     .
MULTIRES         1000  発行社のカタログページ＝http://…
MULTIRES         1001  無料抜粋を読む＝http://…
.                  .     .
.                  .     .
.                  .     .
MULTIRES         1007  この書籍を購入
MULTIRES         1008  マイクロソフト＿リーダー
MULTIRES         1009  Contentville.com=http://...
MULTIRES         1010  Amazon.com=http://...
MULTIRES         1011  アドビeBookリーダー
MULTIRES         1012  バーンズ&ノーブル=http://…
.                  .     . 
.                  .     .
.                  .     .
MULTIRES_MAP  1030  { 1000 1001 1002 1003 1004 { 1005 1006 } 1007 { 1008 
{ 1009 1010 } 1011 { 1012 1013 } ... } }
ある実施例において、マルチリンクの作成は、一連のウェブページ１０４５−１０７０を通じて達成される。理解されるように、マルチリンクの所有者は、マルチリンクの制御／作成を見込む所有者／口座情報を最初に入力することによって設定されなければならない１０４５。その後、ユーザーは、例えば、題名、著者、発行日、説明などのマルチリンクについてのメタデータを入力する。次に、ユーザーは、階層１０５５において多重解決例を提供する。例えば、作品はある場所１０５６に解決可能であり、書籍購入能力はどこでも解決可能である。一旦マルチリンク解決が形成されて提出されると、マルチリンクメニュー１０６０とメニューは生成される。ユーザーは、その後、メタデータ情報１０６５とマルチリンクＤＯＩ記録を、ハンドルシステムディレクトリに保存されるように、閲覧１０６３することができる。
【０１１８】
図１１は、本発明に基づき、ユーザーが情報にアクセスするために行う一連の行為の概要を示している。まず初めに、ユーザーはブラウザー・クライアント１１００をパソコン、携帯情報端末（ＰＤＡ）及び／又はその他のコンピューティング・デバイス１１０５上に立ち上げる。ユーザーはブラウザー１１００を用いてＤＯＩクエリーを作成する。ＤＯＩクエリーは通信ネットワークを通じてＤＯＩディレクトリ・サーバー１１１０に送られる。ＤＯＩディレクトリ・サーバー１１１０のシステムは、ＤＯＩをそこに保存されているエントリーに照らし合わせて調べ、正しいＵＲＬをユーザーのコンピュータ１１００上のブラウザー１１００に送るが、こうしたアクションはユーザーには見えないようになっている。結果として、ブラウザーは正しい発行社情報１１２０があるサーバー上の所望のコンテンツへと導かれる。最終的に、ユーザーのブラウザーからの要求を受け取ると、発行社１１２０は所望の情報をユーザーに送り、その情報にはブラウザー・クライアント１１００でアクセスすることができる。
【０１１９】
図１１は、ユーザーがコンテンツの情報にアクセスするために行う一連の行為をより詳しく継続している。上述したように、ユーザーはブラウザー・クライアント１１００をコンピューティング・デバイス１１０５上に立ち上げる。ユーザーはブラウザー１１００を用いてＤＯＩクエリーを作成する。ＤＯＩクエリーは通信ネットワーク上でＤＯＩディレクトリ・サーバー１１１０に送られる。ＤＯＩディレクトリ・サーバー１１１０のシステムは、ＤＯＩをそこに保存されているエントリーに照らし合わせて調べる。ＤＯＩをＤＯＩディレクトリ・サーバー１１１０に保存されているエントリーに照らし合わせて調べた結果、ユーザー１１２５をどこへ導くべきかをＤＯＩディレクトリ・サーバー１１１０は決定する。当該コンテンツの正しいＵＲＬは、何らの中間介入あるいはユーザーによるアクションなしに、自動的にユーザーのブラウザー１１００に送られる。その結果、ブラウザー１１００は元と成るＵＲＬによりアドレスされたサーバーを有する正しい発行社１１２０へと導かれる。当該ＵＲＬは発行社のサーバー１１２０によりユーザーの所望するコンテンツの厳密な場所を決定するために用いられ、発行社のサーバー１１２０は正しいコンテンツ１１３０をユーザーに送る。
【０１２０】
図１２は、本発明に基づいて、ＤＯＩを解決して所望のコンテンツが位置するＵＲＬを得ることにより、通信ネットワーク上で情報にアクセスするための幾つかの典型的な機構の概要を示している。一実施例によると、ユーザーは直接ＤＯＩを提示し、ＤＯＩシステムは正しいコンテンツを入手し単に正しいＵＲＬにリンクすることによりそれをユーザーに送信する。別の実施例によると、ユーザーはメタデータに含まれるフィールドの幾つかに関係する情報を提示し、するとＤＯＩルックアップ・サービスは正しいＤＯＩを識別し、それが今度は所望するコンテンツの場所を解決する。図１２に示すように、一実施例によれば、検索エンジン１２０１０をユーザーに提供してもよい。一実施例では、登録機関のＤＯＩとメタデータ・データベースとの通信において、検索エンジンを提供及び配備する。別の実施例では、ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍのような検索エンジンを用いて登録機関のデータベースにクエリーを出す。ユーザーは、検索エンジン１２０１０に何らかの識別情報を提示することにより正しいＤＯＩを検索する。検索エンジン１２０１０は提示された識別情報を用いてメタデータに関する自分のデータベースを検索し、提示されたメタデータの情報に関連するＤＯＩを入手する。従って、検索を行うユーザーには、メタデータ・データベースから返送したＤＯＩ及び／又は前記返送したＯＤＩから解決したＵＲＬを提示し得る。入手したＤＯＩはＤＯＩディレクトリ１２０１１に送られ、ＤＯＩディレクトリ１２０１１は所望のコンテンツを発行社１２０４０が置いている場所のＵＲＬを解決する。最終的に、ユーザーのブラウザーは正しいコンテンツ１２０６０へと導かれる。
【０１２１】
別の実施例によると、ユーザーはＤＯＩ１２０１５をブラウザー１２０２５のアドレス・ウィンドウ１２０２０に提示する。ユーザーのウェブ・ブラウザーが元々ＤＯＩを処理する能力がない場合、ＤＯＩ１２０１５はＤＯＩディレクトリ１２０１１用のプロキシ・サーバーのアドレスを含んでいてもよく、それは図１２においては「ｄｘ．ｄｏｉ．ｏｒｇ」である。その結果、ブラウザーはｄｘ．ｄｏｉ．ｏｒｇに位置するＤＯＩディレクトリ１２０１１へと導かれ、ＤＯＩディレクトリ１２０１１は所望のコンテンツを発行社１２０４０が置いている場所のＵＲＬを解決し、ユーザーのブラウザーをそこへと導く。
【０１２２】
別の実施例によれば、ＤＯＩはドキュメントあるいは何らかの形式の情報１２０３０の中に埋め込むこともでき、それによりＤＯＩをクリックすることによってユーザーを正しいＤＯＩディレクトリ１２０１１に導き、ＤＯＩディレクトリ１２０１１は所望のコンテンツを発行社１２０４０が置いている場所のＵＲＬ決定し、ユーザーのブラウザーをそこへと導く。
【０１２３】
別の実施例によると、ＤＯＩはＣＤ−ＲＯＭまたはフロッピー・ディスク等のメモリ１２０４０上に提示してもよく、するとメモリは自動的に、または起動されると、ユーザーを正しいＤＯＩディレクトリ１２０１１に導き、ＤＯＩディレクトリ１２０１１は所望のコンテンツを発行社１２０４０が置いている場所のＵＲＬを割り出し、ユーザーのブラウザーをそこへと導く。
【０１２４】
また別の実施例によれば、ＤＯＩは印刷物としてユーザーに提供してもよく、ユーザーは当該ＤＯＩを上記の如く光学的及び／または機械的周辺入力機器を用いてマニュアルで入力する。
【０１２５】
図１２は、通信ネットワーク上で情報を入手し、ＤＯＩシステムがＤＯＩを解決して所望の情報が位置するＵＲＬを得るための典型的なメカニズムの別の実施例の概要を示している。この一実施例によると、複数のＤＯＩディレクトリ１２１０が分散型ＤＯＩディレクトリとして存在し、ハンドル・システム１２００を形成している。一実施例では、分散型ＤＯＩディレクトリはあたかも単一のディレクトリ１２０１１であるかのように動作し、要求に応える。その点を除いては解決は図１２と同様に行われる。
【０１２６】
図１３は、本発明に基づいた典型的なＤＯＩシステムの概要であり、発行社、ＤＯＩ登録サービス及びハンドル・システムが連携して創り出す効率的なＤＯＩシステムの概要を示している。プレフィックス・ホルダー１３５５は、ＤＯＩ１３４２と関連するメタデータ１３６６から成るＤＯＩ登録サービス１３００に情報を提出する。既に固有のプレフィックス５０１を与えられているプレフィックス・ホルダーは、コンテンツ１３６６にサフィックス５０２を指定するように要求する。登録サービス１３００は、情報１３４２、ハンドル・システム１３５０内に次に預けるための情報１３６６、及び／またはメタデータ・データベース１３１０といったユーザーから提出された情報を解析及び／または再形式設定する役目を担う。上記のように、ＤＯＩを用いてアドレスできるコンテンツの範囲は無限である。その結果、コンテンツ１３６６は如何なる情報及び記事、書籍、音楽アルバムを含む著作物、またはそれらの選択された個別の部分から成ってもよい。ＤＯＩ５００を提供することに加え、発行社１３４２は、コンテンツ１３６６用のメタデータを収集する。当該メタデータは当該コンテンツのＤＯＩ５００、ＤＯＩジャンル、識別子、タイトル、タイプ、起源、主要エージェント、エージェントの役割及び／またはその他から成る。また、様々な相手から提供され識別された、コンテンツに関係のある関連サービスのリストから成っていてもよい。様々な相手とは例えば、コンテンツをオンラインで購入できるウェブ・ページの場所である。
【０１２７】
発行社１３４２がコンテンツ１３６６にサフィックス５０２を指定し必要なメタデータを収集すると、ＤＯＩ５００と当該メタデータはＤＯＩ登録サービス１３００に送信される。ＤＯＩ登録サービス１３００はＤＯＩ５００のデータベース、登録されたコンテンツ１３６６全てのメタデータと共にコンテンツ１３６６が位置するＵＲＬを維持する。本発明によると、ＤＯＩ登録サービス１３００は当該メタデータをメタデータ・データベース１３１０、図２２では２２１９に送信する。メタデータ・データベース１３１０はＤＯＩ登録サービス１３００が一元管理することもできるし、またそうしなくてもよい。
【０１２８】
ＤＯＩ登録サービス１３００は、収集されたメタデータを別のデータ・サービス１３２０に提供したり、付加価値を付けた資源１３３０をユーザーに提供したりするために利用することもできる。加えて、ＤＯＩ登録サービス１３００は正しいＤＯＩハンドル・データをハンドル・システム１３５０に送り、ハンドル・システムは複数のＤＯＩディレクトリ・サーバー１３４１から成っていてもよい。
【０１２９】
図１４は、広告シンジケーターが行う例示的な広告を示している。図１を参照して上述したように、シンジケーターは広告プロバイダーとして使用可能である。かかる実施例は、ウェブブラウザーのウィンドウ５０１に一連のウェブページ１４１１、１４２２、１４３３、１４４４を示す。一例１４１１において、ユーザーは、検索クエリーテキストボックス１４０５に検索用語を入力して検索を提出１４８６することによって航空関連情報を検索することができる。検索結果１４１８の幾つかはマルチリンク１４１０を含む。ユーザーがリンクを移動すると、ポップアップ１４４５するマルチリンクメニューからアイテムを選択することによってマルチリンクされたコンテンツ１４２０への更なるレファレンスを発見することができる。また、図１６−２０において詳細に説明するように、メニューアイテムの位置決めと出現はエンドユーザーの活動追跡に基づいて変更可能であることに留意しなければならない。例えば、「法律事務所を直ちに呼び出せ」選択肢は人気があるならば、「ホーム」選択肢１４４６の代わりに、上に移動して第１のメニューアイテム選択となることができる。マルチリンクメニューはテキスト結果１４１０から又はバナー広告１４３０、１４２２の一部としてポップアップしてもよい。
【０１３０】
別の実施例においては、ユーザーはマルチリンクメニューにより可能とされたスポンサーリンク１４１７、１４４４を入手することができる。本実施例においては、ユーザーは、検索プロバイダーからスポンサーリンクを入手した。例えば、ユーザーは検索会社ウェブページ（例えば、グーグル）に向かい、連絡情報を記入し、所望のスポンサーリンクを特定する情報を提供した。通常、ユーザーは、あるキーワードを特定し、スポンサーリンクと特性キーワードの検索に応答して表示されるであろう、ある関連テキストを提供するだろう。これは、オートリンカー及び／又はマルチリンクエディタによって拡張される。広告アイテムのマルチリンクは、例えば、オートリンカーによって既に形成された。正規のリンクを提供する代わりに、ユーザーは、マルチリンクを特定するであろう。更に、ユーザーは、上述したように、マルチリンクエディタをマルチリンクメニューを仕立てるのに使用することができる。このように、ユーザーは、単なるリンクの代わりに、今やマルチリンクメニューを検索会社に提供することができ、これは、ユーザーがカーソルを１４１０、１４１７、１４４５に横切ると、より多くの情報を有するマルチリンクメニューポップアップを有するプレミアムスポンサーリンクをもたらす。このように、一例を実施すると、ユーザーは「移民法の弁護士」の検索を検索フィールド１４０５、１４３３に入力すると、結果ウェブページ１４４４がプレミアムスポンサーリンク１４１７を含む結果１４１８を示す。ユーザーが、カーソルをマルチリンクされた結果１４１０を横切って移動すると、マルチリンクメニュー１４４５がポップアップし、より多くの情報にアクセスするのに使用される。同様に、メニューアイテムの位置決め及び出現は、エンドユーザーの活動に基づいてここで同様に変更可能である。例えば、都市の順序１４４７は、エンドユーザーの支払い頻度によって駆動されるように、配置に対して支払いをする広告者によって、変更可能である（例えば、ボストンの会社が多くのお金を支払えば彼らのメニューの入力は先頭位置に移動するだろう）。これらの実施例において、マルチリンクは情報が豊かであり、インター及びイントラリンクされるので、マルチリンクを使用する広告リンクは、多くの場合、検索結果としてより関連するように発見されるであろう。かかるマルチリンクは、正規の単一リンクＵＲＬよりもクリックスルー率が高くなり、広告の場面ではより価値が出るだろう。
【０１３１】
図１５は、例示的なマルチリンクの用途を示している。別の実施例では、マルチリンク広告は、コンテキスト的に、他の関連コンテンツ内に、例えば、記事又は製品批評、リサーチ研究、音楽ウェブサイトなどの中に配置される。ある例では、マルチリンクメニューは、歌の最新トップ４０チャートランク１５１０、６６７などの独立したソースデータによるクリックの多さによって駆動される順番で配置されてもよい。以下の例では、「ボーイング」に対するＤＯＩはビジネスウィーク記事内で表示され、ユーザーをマグローヒル世界航空辞書（即ち、ＤＯＩの所有者）に駆り立てる。そこでは、ユーザー１５１５からの所望の情報が購読又はペイパービュー取引を必要とする。以下の例では、ビジネスウィークの書籍の批評は、批評される書籍に対するＤＯＩを表示することができ、マルチリンクメニューはユーザーを購入のためにアマゾン又はその他の小売店に照会する。（このＤＯＩの所有者としての）発行社自身又は（そのメニューがビジネスウィーク内で出現する範囲でマルチリンクシンジケーターをそのメニューのローカル出現を変更するのに使用することによって）ビジネスウィークがマルチリンクメニューにおける配置に対する小売店から費用を求めることができる。費用は、照会手数料ベースなどの幾つかの形態、固定配置費用ベース及び／又は後述するもの及び／又は他の所を含む他のベースに依存する。例えば１５２５、ユーザーは書籍の版を購入及びバーンズ＆ノーブルを選択することを求めることができ、このため参照費用はバーンズ＆ノーブルからビジネスウィークによって受信するであろう。また、マルチリンクメニューは、広告が最も使用される物を決定するのにエンドユーザー活動追跡を使用することができる。更に、スポンサーリンクは使用に基づいてマルチリンクメニューにおいて特定のスポンサーを回転するのに使用可能である。このように、ウェブサイトは、エンドユーザー追跡は成功広告をより頻繁に晒してウェブサイトはクリックスルー率が増加するにつれてより多くのお金を稼げるので、広告歳入を増加することができる。
【０１３２】
別の実施例において、広告は、実際には、「不動産」画面及び／又は他の形態の広告在庫としてビルボードに似た方法でマルチリンクメニューを使用して他のアイテムに対してマルチリンクメニューに実際に配置可能である。一例において、ユーザーは、スポンサー資源１５３０を有するマルチリンクを有する「学習継続」アイテム上を動くことができるだろう。このように、マルチリンクメニューの配置は、スポンサー広告者に、メニューのフォントや色の優位性、グラフィック又はロゴの包含又は排除、又は、メニュー選択肢の順番のアイテムにおける配置に従って変動するであろう費用で提供可能であろう。配置は、所与の広告者のリンクの出現頻度に従って、又は、一日の回数、コンテキスト、ユーザーによる検索クエリーのある種類に応答して、ユーザーの地理的位置に従って、ユーザーの言語に従って、以前に保存された又はユーザーとの対話の一部として取得されたユーザープロファイル情報に従ってなど、変動する費用と共に異なる広告者の間で回転可能でもある。
【０１３３】
ある実施例において、スポンサーリンクを形成する機構は、ある数のユーザーインプレッションと特定の「キーワード」活動に対して広告者からの受信支払いに基づいている。このように、スポンサーが「糖尿病」キーワードに関連した１０００インプレッションに対して支払う場合、シンジケーターは、リンクへの支払いに基づいてメニュー仕様の生成を変動するかもしれない。ある例示的な実施例においては、プレースホルダタグが、例えば、スポンサーリンクが配置された＜Sponsored Link＞などのマルチリンク記録に配置される。ＩＳＩＣＩは、その後、コンテンツページにおいて、埋め込まれたマルチリンクに関連付けられたキーワードに基づいてデータベースクエリーを発行することができる。それは支払われたインプレッションを有するキーワードに対して選択する。かかるスポンサーアイテムを識別すると、シンジケーターは、その後、スポンサーのリンクをマルチリンクプレイスホルダに挿入する。ユーザーがマルチリンクメニューに対する呼び出しマウス操作すると、これがリアルタイムでなされるので、メニュー仕様の生成が広告データベースから選択された最新の広告者と共に要求に応じて提供可能である。メニューが表示されると、スポンサーリンクに対するインプレッションの欠点は広告データベースに記録可能であり、スポンサーに例えば、９９９インプレッションを残す。
【０１３４】
別の実施例において、ＤＯＩ所有者のオンラインパートナーを表し、関連資源又は製品又はパートナーによって提供されたサービスに関連する外部組織に配置がマルチリンクメニュー上で提供可能である。配置は、均一価格ベース又は相互のリンク取り決めの一部として若しくは一方又は双方の当事者が他の当事者のマルチリンクメニューを介して到着した訪問者によってなされる購入に対するお互いに照会手数料を補償することができる取り決めの一部として、クリック又は訪問者毎の照会ベースで、及び／又は、他のビジネスの取り決めで認められる。また、費用は、本出願で既述及び／又はその他の全ての実施例と変形例に従って変動可能であろう。一例において、２つの当事者が示される。まず、それ自身の独立のＤＯＩ１５３５を有し、その間１５３７のインターリンクを有する。理解されるように、スナップショットレポートマルチリンクメニュー１５３５は、スポンサーリンク１５３７としての、例えば、ＳＲＩの、マルチリンクメニューに統合される。インターリンクは２以上の当事者に起こり得ることに留意しなければならない。
【０１３５】
別の実施例において、小売店、分配者、統合者などの仲介者又は、ダイアログ、ファクティバ、レクシス・ネクシスなどのシンジケーターなどがＤＯＩマルチリンクをそのサービス内において表示するために選択し、マルチリンクに参照されたトラフィックが所有者のサイト及び／又は所有者によって指定された他のサイトに照会手数料又はマルチリンクの表示者が稼ぐその他の報酬と共に戻ることを可能にする。コンテンツ又は製品自身をロード及び再販売する代わりに、仲介者はそのオーディエンスとユーザーベースを貨幣化したり、販売をＤＯＩ所有者又はその指定された当事者に戻すように駆り立てて、管路としてその役割から利益を得てもよい。例えば、管路サイトは、トムソンゲイルによって所有されるＤＯＩ（例えば、ウイリアムクレイフォード）を表示してもよく、それはその後ユーザーを様々な伝記物１５４０などの販売可能なゲイル製品に指向させる。
【０１３６】
このように、マルチリンクは、広告又はその他のコンテキストに使用されても、「自然の」検索エンジンランキングに衝撃を与える。グーグルのような多くの検索システムは、所与のコンテンツアイテムへのリンク数に基づいて関連性をランク付けする。彼らがウェブをスパイダーすると、それらはウェブページをインデックス付けして所与のコンテンツアイテム又はウェブページへのリンク数を追跡する。この情報は、その後、ユーザーが所与の用語を検索するとその用語はコンテンツアイテムに関連付けられるのみならずそのアイテムをさすリンク数に従って（他の要因の中で）関連性のランク付けがなされるように、それらの関連性追跡アルゴリズムにおいて使用される。従って、マルチリンクＤＯＩがインターリンクを多くの関連アイテム間に与え、それらのアイテムが次に、（原アイテムを潜在的に含む）多くの他の関連アイテム間でインターリンクすると、正味の結果は、検索エンジンの検索結果又は検索結果を与える他のサイトの中でアイテムの関連性ランキングを高める場合がある。ユーザーの検索クエリーを発見された特定のアイテムに関連付けること自体は、ＤＯＩマルチリンクとそれが現れるウェブページの他の言葉の間、又は、ＤＯＩマルチリンク及びウェブページのヘッダー又はメタタグのキーワードのような独立の関連付け方法を要求又は要求しないかもしれないが、ランキングはＤＯＩマルチリンクを介した関連アイテムのインターリンクによって影響を受けるかもしれない。更に、より多くのアイテムがインターリンクされればされる程ランキングの影響は大きくなる。更に、ＤＯＩマルチリンクがインターネットの多数の場所に分配されると所有者のサイトのみの代わりに、この分配がマルチリンクシンジケーターの使用を介して又はウェブページでの手動臨時ポスティング又は他の方法を介して達成されるかどうかに拘わらず、ランキングの衝撃は更に多くの場所におけるこれらの多重マルチリンクの存在によって拡大される。
【０１３７】
検索エンジンのランキングへの衝撃はオートリンカーのコンポーネントを介して見積もり可能である。インターリンクアイテム数とインターリンク度が評価可能であり、検索エンジンランキングが、検索エンジンによるこれらのマルチリンクのスパイダーによって影響を受けるであろう範囲の見積もりを与える。検索エンジンが利用する特定のランキングアルゴリズムは一般には公衆に知られていないが、衝撃要因は見積もり可能である。この衝撃要因は、その後、それらのＤＯＩが検索エンジンスパイダーによって発見されるインターネットにその後分散可能な程度から発生する更なる衝撃を見積もるために、更に外挿可能である。スパイダーがＤＯＩに遭遇し、そのマルチリンクの全てをトラバースし、それらのＤＯＩに遭遇し、（原ＤＯＩを含む）それらのマルチリンクなどの全てをトラバースするであろう各場所は別の場所を表しているので、それらがより多くの場所を見つければ見つけるほどランキングの衝撃はより大きくなる。また、これらの見積もりは、ＤＯＩ所有者が、よりよく関連情報をインターリンクすることができる方法の理解補助に使用可能である。例えば、それらに関連付けられた（又は「マルチリンクオーファンレポート」に埋め込身可能であるように全く関連付けられていない）インターリンクを殆ど有しない識別アイテムは、次にＤＯＩ所有者の分類方法の失敗を識別することができ、その分類法又はその他の有用な診断結論の効率性又は正確性又は完全性における弱さを強調するかもしれない。
【０１３８】
以下は、かかる測定をすることができる例示的な一実施例である。
#!/usr/bin/perl -w
# add local libs to @DSfC path
use FindBin;
use lib $FindBin::RealDir."/../lib";
use strict;
use warnings;
=pod
=headl NAME
compute__statistics.pl - Compare crawler results to database
=headl SYNOPSIS
Crawl DOIs and process with compute_statistics.pl -
### Expects input from STDIN:
$ compute_statistics.pl -prefix IQ.1225 --verbose -verbose
### Wlien used in concert with doi__crawler.pl:
$ doi_crawler.pl -url http://doi.contentdirections.com/mr/hbsp.jsp?doi=10.1225/682025 \
|compute_statistics.pl -prefix 10.1225 -verbose -verbose
=headl DESCRIPTION
Based on output from doi_crawler.[rho]l, compute_statistics.pl will compare the results to the content of the database. This script will output the following:
* Count of matches
* Count of missing 
* Count of unknown DOIs
* List if matches, missing, and unknown DOIs (in verbose mode only)
=headl OPTIONS
The script takes the following options :
=over
=item -prefix
The DOI fragment against which to match results in the database.
This string will be used to select DOIs from the HANDLE table in the Oracle database where DOI LIKE '$prefix%'.
=item -verbose
This option increases the amount of information which is output. You may use this option more than once to increase output.
If specified once, this will cause compute_statistics.pl to list all the MISSING DOIs.
If specified twice, this will cause compute_statistics.pl to also list all the UNKNOWN DOIs.
If specified thrice, this will cause compute__statistics.pl to also list all the  MATCHING DOIs.
=item -help
=item -man
=back
=cut
use CDI-.-.DBH;
use Getopt::Long;
use Pod::Usage;
# Set up getopts
my ($help, Sman, Sprefix, Sverbose);
Sverbose = 0;
Get[theta]ptions( 'help' => \$help,
'man' => \$man, 'prefix=s' => \$prefix,
'verbose+' => \$verbose );
pod2usage(l) if$help;
pod2usage(-verbose => 2) if $man;
# Validate input
pod2usage("No DOI prefix specified") unless (Sprefix);
# Clean up prefix Sprefix =~ s[Lambda]'[Lambda]_/g;
# Select all DOIs from database which match prefix
my $dbh = CDI::DBH->new_oracle();
my $sth = $dbh->prepare("select DOI from HANDLE where DOI like '". Sprefix ."%"'); $sth->execute();
# Store found DOIs in hash for easy access
my %db_dois = 0;
while (my ($doi) = $sth->fetchrow_array()) {
$db_dois{$doi}++;
}
# Output URL summary line
my $url = <STDDSf>;
chomp(Surl);
print "Summary of connected DOIs\n \n$url\n\n\n";
# Compare found DOb to those passed in to STDIN.
# File into two buckets: matching, unknown
my (c)matching = 0;
my (c)unknown = ();
while (<STDDSf>) {
chompO;
my $doi = $_;
if (exists($db_dois{$doi})) {
[rho]ush(@matching, Sdoi);
delete($db_dois {Sdoi} );
} else {
push(@unknown, Sdoi);
}
}
# Derive third bucket: missing
my @missing = keys(%db_dois);
# Output details, if -verbose
if (Sverbose > 2) {
print "Matching DOIs\n \n";
foreach my Sdoi ((c)matching) {
print "$doi\n"; }
print "\n\n";
}
if (Sverbose) {
print "Missing DOIs\n \n";
foreach my Sdoi ((c)missing) {
print "$doi\n";
}
print "\n\n";
}
if($verbose> l) {
print "Unknown DOIs\n \n";
foreach my $doi (@unl[alpha]iown) {
print "$doi\n";
}
print "\n\n";
}
# Output summary
my $count_matching = scalar(@matching);
my $count_missing = scalar(@missing);
my $count_u[pi]known = scalar(@unknown);
print <<"EOF;
DOI Statistics
Matcliing: $count_matching
Missing: $count_missing
Unknown: $count_unknown
EOF
上述の実施例において、インターリンク度の測定は入手可能である。私のＤＯＩの比較は（例えば、スポンサー）ＤＯＩのデータベースに対してクロールすることを通じて発見された。このように、ＩＳＩＣＩはその埋め込まれたＤＯＩをインデックするウェブサイトをクロールする。その後、クロールに由来する結果は、データベースにインデックス結果に相当し、そのデータベースにスポンサーリンクを比較する。それをする際に、ＩＳＩＣＩは一致数と失った未知のＤＯＩを計数する。ある実施例において、一致と比較は、ＤＯＩのファミリーに対して一致度を監視するためのＤＯＩの一部を比較することによって達成可能である。ＩＳＩＣＩは、その後、発見されたＤＯＩをデータベースのＤＯＩに比較するか、又は、特定されたＤＯＩに比較する。ある実施例において、ＩＳＩＣＩはＤＯＩごとにかかる分析を実行し、それをインターリンク／インデックスとＩＳＩＣＩデータベース１５１８のランキング表に格納する。ある実施例において、多数の一致リンクは少数のそれよりも高い位置にランク付けされる。ランキングレポートは、ＤＯＩの人気を測るレポートをもたらす最高一致ＤＯＩに対して選択をすることによって生成される。かかるレポートは、自動的に及び／又は周期的に生成されて販売される。別の実施例において、かかるレポートはスポンサーリンクに対して作成可能である。かかる統計情報は、別個に販売可能か、及び／又は、スポンサーリンクのサービスの一部に含まれる。同様に、ランキングリストは一般公衆に周期的に提供可能であり、コンテンツの人気の尺度として機能する。例えば、ＤＯＩとコンテンツに対する最も人気のあるリストの一種のビルボードとして機能する。更に、かかる人気リストは興味のある多数の領域に分割可能である。ランキングは、単なる音楽コンテンツ、人気のある人を識別するパーソナルＤＯＩ、最も人気のあるサービスプロバイダーを識別するサービスに限定可能である。例えば、ＩＳＩＣＩは、例えば、法律事務所である単一のセクターのみを選択し、法律事務所に対して人気のあるインデックスを生成することができる。別の実施例においては、ＩＳＩＣＩはその選択を最近の封切映画の分野に限定することができる。更に別の実施例においては、選択は、ある範囲の製品、例えば、自動車、に限定可能である。更に、選択は時間パラメータによって制限可能である。ランキングの選択はある期間形成可能である。このように、最後の１２ヶ月自動車業界に対してＩＳＩＣＩがインターリンク統計を選択すると、ランキングはそのように限定される。別の実施例において、時間的制限がかかる選択になければ、形成は時間を通じて測定可能である。
【０１３９】
ある実施例において、検索エンジンランキングを最大にすることはＤＯＩをキーワード及び／又は分類法の用語及び／又は制御された語彙に割り当てることによって達成可能であり、マルチリンクは、その後、以下又はその他の資源の全て又は幾らか、分類法の他のキーワード、それらのキーワードに関連する全ての製品又は発行、それらのキーワードに関連付けられたサービス、売主又は小売店若しくはそれらのキーワードに関連付けられた他の種類のパートナーなどに向かうことが可能である。例えば、企業によって「アビオニクスリペア」の用語ＤＯＩは、これらの製品が、本、世界航空辞書のデータベース記録、ビジネスウィーク、又は、アビエーションウイーク記事、今後の会議、上述したようなスポンサーリンクなどであるかどうかに拘わらず、「アビオニクスリペア」の用語に関連する全てのビジネスラインの企業の全製品にマルチリンクされる。かかる例において、検索記録は、より大きなインターリンク度があるので、トップ１５４５に向かって重み付けられたマルチリンクを有する検索エンジンから戻るだろう。
【０１４０】
ある実施例において、検索エンジンランキングにおいて用語がより高く上がることをもたらすだろう同一の分類法用語とマルチリンクは、ＤＯＩが検索エンジン結果自体以外で現れるコンテキストにおいてさえ、マルチリンクメニューでパートナーリンクの配置のバリューを増加するのにも使用可能であろう。例えば、「真性糖尿病」に対する企業のＤＯＩは、マルチリンクがユーザーを企業のパートナー（例えば、ウェブＭＤ、アトキンス、オヴィッドによる科学誌読み物など）に行うリサーチ研究の中でコンテキスト的に見ることができ、かかるメニューの配置は、検索エンジンの用語ランキング（又は上述したものなど別のベース）に比例する費用で提供される。
【０１４１】
広告、電子商取引及びその他の顧客インターラクションオンラインのための統合、情報処理及び自己改善システム
ＩＳＩＣＩ以前には、ユーザーに、更なる情報、提案、購入取引、関連製品などへのアクセスを容易にする多重ディープリンクへの案内されたナビゲーション構成を与え、情報処理されたリンクメニューを表す広告フォーマットはなかった。広告の製品又は主題に関する完全なナビゲーション構造を全ての情報とインクに提供するその他のフォーマットはなかった。
【０１４２】
マルチリンクユーザーインターフェース
図１６は、例示的なマルチリンク用途及びユーザーインターフェースを示す。また、マルチリンクによって表されたナビゲーション構造は、これらのリンクを人間編集プロセス、又は、より典型的には、広告者から与えられた製品データに基づいてこれらのメニューを作成及び維持する自動「流れ作業」プロセスを介して、作成、維持及び中央制御する基底エンジンを有する。更に、マルチリンクにおいては、メニューは、広告の製品又はその他の主題に関する情報とリンクを埋め込むことを超える。メニューは、在庫管理情報、ローカルディーラー情報、様々な製品小売店からの特別の提供、及び／又は、他のオンライン又はオフラインシステムで複雑な統合を必要とするその他の種類の情報又は取引などバックエンドシステムデータに深く向くリンクを含むこともできる。この能力は自動統合度を変更することも含む。例えば、ある実施例では、マルチリンクメニューは、バックエンドシステム情報を向くディープリンクを含む。図２−３及び本開示のその他で既に説明されているように、かかるディープリンクはターゲットシステムの技術スタッフ、データベース管理者、ウェブマスターなどとの診断によって作成可能である。また、ディープリンクは、観察と推論を通じてリバースエンジニアが可能である。別の実施例では、マルチリンクメニュー作成／維持システムが、メニュー自体を作成する前に、実際にバックエンドシステムから情報検索することができる。換言すれば、マルチリンクのメニュー仕様は、バックエンドシステム（例えば、現在の在庫情報１６１５、特別価格又はバンドル（図１８の１８２０を参照）、クーポン、リベートなど）から情報検索することによって生成及び又は更新可能である。このように、これは、ＩＳＩＣＩがマルチリンクをダイナミックにバックエンドデータベースシステムから検索された情報に基づいてマルチリンクを作成及び／又は更新することを可能にする。これは、ユーザーが、実際のウェブページ及び／又はターゲットレファレンスをナビゲートする必要なしに、バックエンド情報を取得、ナビゲート及びインターラクションすることを可能にする。図１６は、特定の自動車１６１５の在庫と価格の詳細を示す複合情報を有するマルチリンクメニューを示している。エンドユーザーは、マルチリンクメニューに含まれる実際の基底ターゲットレファレンスをトラバースせずに、マルチリンクメニュー１６２５内でフォーム情報を入力することさえできる。代替的に、マルチリンクメニューは、メニュー選択１６２１を選択することによってユーザーにバックエンドシステム１６２０にナビゲートすることを可能にし、ユーザーが直接にバックエンドシステムとインターラクションする１６２２レファレンスアドレスをターゲットする。
【０１４３】
ＩＳＩＣＩ技術
図１７は、マルチリンクエコシステムの実施例を示す混合データフロー図である。一般に、ＩＳＩＣＩは、マルチリンクメニュー１７０５の作成と維持を見込んでいる。マルチリンクメニューの作成は、ＵＰＵＮＩグローバル登録所１７１５におけるマルチリンクの登録をもたらす。マルチリンクメニューのシンジケーションは発生し１７２０、マルチリンクとメニューがエンドユーザーによって伝播及び表示されると１７２５、マルチリンク追跡部は、所与のマルチリンクメニュー１７３５を使用してエンドユーザインターラクションに関する情報を収集し、マルチリンク追跡部データベース１７４０におけるその追跡情報を保存する。この追跡情報１７４０は、広告者及びその他のサービスプロバイダー１７５０が、マルチリンクメニューを洗練、修理及び／又は整備するために使用可能である。ある実施例においては、品質保証プロバイダー１７５０は、マルチリンクメニューが維持及び／又は作成されている時に１７０５、マルチリンク保全性１７０７を確認するのに追跡情報を使用することができる。例えば、特定のマルチリンクメニューエントリーは大変人気があり、そのメニューエントリーのターゲットレファレンスが多くのユーザーがアクセスを拒否されるように圧倒されると、品質保証サービスプロバイダー１７５０は、（例えば、新しいターゲットレファレンスを大きな容量を有する代替的なサーバーに提供したり、代替的なメニューエントリーを提供したりすることによって）更新ターゲットレファレンスを供給することによって、マルチリンクメニュー１７５５仕様を修理することができる。
【０１４４】
別の実施例においては、より多くの人気のあるメニュー選択がより顕著に表示されるように広告エージェンシーが追跡情報１７４５をマルチリンクメニューを改善するのに使用することができる。例えば、広告エージェンシーは、人気のあるメニュー選択を先頭に移動してそれがより簡単に選択されるようにしたり、人気のないメニュー選択を先頭に移動してその選択がより人気が出るようにしたり、メニュー選択にスポンサー広告を配置したり、広告の配置に値を付けることを広告者に見込んだりするなどをする。同様に、マルチリンクメニューは、スポンサー広告が全ての、一部の又はないメニューアイテムを含んでもよい。ある実施例において、特定数のマルチリンクメニューアイテムスロットは、スポンサー広告に対して保存可能である。アイテムスロット数は、ゼロからマルチリンクメニューアイテムの幾つか若しくは全てまでのどこでもよい。かかる実施例において、広告の指値及び／又は配置は、他のマルチリンクメニューアイテム、マルチリンクメニューアイテムのターゲットのコンテンツ、マルチリンクメニューアイテムの原因のコンテンツ（例えば、ハイパーリンク及び／又はそのレファレンス）、エンドユーザの現在のナビゲーション位置のコンテンツ（例えば、彼らの現在表示されているというウェブページ）などのコンテキストに基づいている。広告スロットはそれ自体追跡可能であることに留意する必要がある。例えば、マルチリンク追跡部はマルチリンクメニューにおいてより多くの広告の効率的配置の決定を見込んでいる。例えば、あるコンテキストにおいて、マルチリンクメニュー広告に向けられたスロットは、マルチリンクメニューを通じでより効果的に点在して動作し、別のコンテキストでは広告は、より目立った場所に特徴付けられると（例えば、マルチリンクメニューの先頭に）よりよく動作する。更に、マルチリンクメニュー広告のフォーマットは追跡を通じて改良可能である。例えば、あるコンテキストにおいては、（マルチリンクメニュー広告スロットに「ＡＤ」と前置きすることによって）それらが広告であることをはっきりと表現するマルチリンクメニューは、よりうまく動作するかもしれない。一方、マルチリンクを暗示するものと混合したマルチリンクメニュー広告を有する別のコンテキストにおいては、メニューはより効果的になるであろう。
【０１４５】
このように、広告者は、マルチリンク追跡データベース１７４０からの情報を追跡することに応答してマルチリンクメニュー仕様を変更することができるだろう。ある実施例において、診断業界は、全市場取引戦略１７６０の一部としてマルチリンクメニュー１７０５を最良に形成して設計する方法について市場取引及び製品戦略を与えることに従事するかもしれない。このように、市場取引コンサルタントは、データベース１７４０に格納されたエンドユーザー追跡情報から利益を享受してもよいだろう。
【０１４６】
上記フィードバックスープのより簡素化されたビュー１７７５は、上述のコンポーネントの各々がどのように一般にお互いに対話可能であるかを示している。この単純化されたビューにおいて、自己改良１７７５の継続的なサイクルを示している。フィードバックループは反時計回りに回転し、「診断」１７６０と共に先頭で開始する。本実施例においては、診断サービスは、彼らの製品と市場取引戦略及び彼らのターゲットクライアントの購入寿命を把握するために、クライアントと一緒に動作するビジネスプロセスを開始する。コンサルタントは、特定の市場取引運動に対してマルチリンクメニューを形成するアイテムの最初の原因を測定するように努める。この最初の原因は、既述したように（例えば、オートリンカーを使用して完全に自動化され、データ駆動される「流れ作業」プロセス又はマルチリンクエディタを使用する手動作成プロセスを介するものであるかどうかに拘わらず）、作成／維持コンポーネント１７０５と共にマルチリンクを実際に作成するのに使用可能である。マルチリンクサーバー１７２６は、マルチリンクメニューの表示／クリックレスのナビゲーションを可能にする。シンジケーター１７２０は、ローカルソフトウェアインストールを要求せずに、ウェブのどこにでもリンクを分配し、マルチリンクサーバーが丁度行うように例えば、それがローカルサイトにインストールされると、個々のローカルサイトのカスタマイズを見込む。品質保証コンポーネント１７５５は、マルチリンクの保全性を検査する。この点、マルチリンク追跡部１７３５は、エンドユーザーの行為を追跡して作成／維持コンポーネント１７０５及び／又は診断ファシリティ１７６０に報告することができる。
【０１４７】
マルチリンク追跡部
図１９は、マルチリンクメニュー追跡部の実施例を示す論理フロー図である。マルチリンク追跡部は、追跡情報を直接にマルチリンクメニュー１９０５とのエンドユーザーインターラクション（即ち、マルチリンク追跡部サーバーアドレスへのＨＴＴＰポストの関与をもたらすマルチリンクメニューアイテムをクリックすること）１９０５から受信することと、使用ログ１９１５のウェブサーバーをスパイダーすることなどの少なくとも２つの方法で、追跡情報を収集することができる。マルチリンク追跡部は、インターネット１９１５中のウェブで使用ログを検索するのにスパイダーを使用する。ある実施例では、これはあらゆるＩＰアドレスを統計ページ（例えば、http://123.123.123.123./statistics）にスパイダーすることによって達成される。別の実施例では、ＩＳＰとホストプロバイダーとＦＴＰポイントから使用ログを定期的に転送する取り決めがなされる。一旦使用ログが取得されると１９２０、マルチリンク追跡者は、ログ１９２５における個別の使用エントリーを分析することを開始する。ある実施例において、マルチリンク追跡部は各ログエントリー１９２５を（それが全てのウェブログの全てのエントリーを消費するまで）継続的に分析する。別の実施例においては、マルチリンク追跡者は特定された時に（例えば、クロンジョブを通じて開始されるように）ログを処理することができる１９２５。代替的に、マルチリンク追跡部は、（図２において既述したように）追跡情報を直接にエンドユーザー行為１９０５から受信することができる。マルチリンク追跡部が追跡情報を直接に受信すると１９０５、それは継続的及びダイナミックに分析されるべき各エンドユーザーの追跡アイテムを通過することができ１９２５、あるいは代替的に、マルチリンク追跡部は、他のログ１９２５と共に処理可能である、それ自身のウェブサーバーログ１９０７においてかかる追跡情報（例えばＨＴＴＰポスト）を格納することができる。
【０１４８】
一般に、ウェブサーバーは、ユーザーからの全要求をリストするウェブログを保持する。一般に、これらのリストは、完全なＨＴＴＰアドレス及び要求を書き写すアスキーリストである。このように、オートリンカーは、（図２で記載されたように）追跡アドレスに付属するパラメータを生成すると、ウェブログはかかる情報に対してパース可能となるリストを有するだろう。ある実施例では、ウェブログは、例えば、以下のようなエントリーを含むことができる。
【０１４９】
http://wwwxhryslerxom/bridge/full_inventory.html?linkstorm_path=cross fire
実際のウェブアドレスレファレンスは、「http://www.chrysler.com/bridge/fulMnventory.html」であり、マルチリンクメニューにおいて「クロスファイヤー」メニューアイテムを識別するパラメータが続く（図１６の１６０２）。代替的な実施例において、メニューアイテム番号は、図２において既に説明したように、パラメータとして使用される。
【０１５０】
http://www.trackerserver.eom/postvalues7doi://10.1009/03959607897men uID: 12345?hover:4:menuTier: 1 :2?hover:2:menuTierCHck: 1 :3
このように、ウェブログのかかる各エントリー１９２５はパースされる（例えば、キャリッジリターンによって分離されたアスキー列ごとにポップし、ＤＯＩ１９３０及びパラメータ値１９４０に対してパースする）。幾つかのパラメータ値が含まれてパースされる、ホーバー回数、メニューアイテム選択値、メニュー仕様ＩＤなどである。ある実施例においては、マルチリンクメニュー仕様ＩＤがパラメータとして通過されると、メニュー仕様は取得可能となり１９３５、パラメータ１９４０をパーすする際にダイナミックなテンプレートとして使用される。エンドユーザー追跡活動１９３０、１９４０をパースする際に、マルチリンク追跡部がそのデータベース１９１９にそのパースされた値を保存可能である。
【０１５１】
図２０は、マルチリンク追跡ユーザーインターフェースと追跡ログを示す。マルチリンク追跡部データベースは、マルチリンク追跡部インターフェース１２０５を介して個人によってクエリー可能である。マルチリンク追跡部インターフェースは、マルチリンクメニュー２０７１とそのサブメニューアイテム２０７２の各々に対して様々な活動追跡統計２０３０、２０３５、２０４０、２０５０を与えるために、そのサブメニューＳＱＬクエリーをデータベースに提供することができる。例えば、データ範囲２０５５は、様々なメトリックスがそのデータ範囲に制限されるように、データのＳＱＬをその後制限するのに使用されるインターフェースに与えられる。メニューアイテムロールオーバー２０３０、クリック２０３５、クリックスルーパーセント２０４０及びメニューサブアイテム２０５０に費やした平均時間のような様々な統計は認識可能である。これらの追跡値は、ウェブログに由来する。代替的に、ＤＯＩハンドル使用は、アクセスされたＤＯＩ２０１０、アクセス回数２０１５、タイトル２０２０、そしてその他の情報の種類を維持するウェブログ２０８０を介して追跡可能である。しかし、マルチリンク追跡部データベースは、ＳＱＬ要求にパースされたＨＴＴＰ要求を介してプログラムに基づいてクエリーされてアクセスされる場合がある。例えば、
http://www.trackerserver.com/query?doi:10.123/12345{?statistic type}
上記例において、ＤＯＩ「１０．１２３／１２３４５」は、選択コマンドの根拠として使用され、データベースは全ての一致データベース記録のＨＴＴＰポストを要求エージェントに返信するだろう。追跡情報量は、選択的な「?statistic type」パラメータの追加によって更に制限可能である。例えば、追加的なパラメータは「menuItem:1:3」であり、所与のＤＯＩに対する第２層メニューの第３のアイテムのみに対する統計を返信するだろう。このように、様々なエンティティがマルチリンク追跡部データベースからの追跡情報の最大限に利用している。
【０１５２】
購入サイクル圧縮
図２１は、購入サイクルを示している。ある実施例では、ＩＳＩＣＩアドレスは延長された購入サイクルと潜在的な購入者の減少の問題に着目する。購入サイクルは、高債務商品及び／又はサービス２１０５は多重層チャート２１０５に示されている。高債務購入は、様々な主観的及び客観的な要因に基づいた幾つかの決定を購入者に要求する。高債務購入は、自動車、船舶、家、専門的なサービス（例えば、医療、法律などのサービス）、ステレオシステム、テレビなどを含むかもしれない。図は、早期段階２１１０において、購入者が２−６ヶ月のいずれかを興味があるセグメントを決定するのに費やす場合があることを示している。例えば、車のショッピングの場合、購入者は自分がＳＵＶ、ミニバン、ステーションワゴンなどをほしいのかを決定するのに何ヶ月も費やす場合がある。セグメント２１１０を識別した後で、中間ステージ購入者は更なる１−３ヶ月のいずれかを彼らが興味があるブランド２１１５を決定するのに費やす場合がある。その後２１１５、購入の遅い段階で、購入者は、１週間から１ヶ月をブランド２１２０内の特定の製品及び／又は特徴を決定するのに費やす場合がある。例えば、購入者がドッジのクロスファイヤ車を買うことを決意した場合、サンルーフ、デラックスステレオパッケージ、特定の色などのオプションを欲しいかどうかを決定するのにある時間が必要となる場合がある。最終的に、遅い購入段階で、購入者は１−２週間を取引パートナー２１２２を見つけるのに費やす場合がある。例えば、購入者は、購入をするために、幾人もの自動車ディーラーの所に行く場合がある。図から理解されるように、潜在的な購入者数２１１１は、顧客の減少のため、各段階２１１６、２１２１、２１２３で減少する。多くの場合、この減少は、多段階購入サイクルに長い時間かかわることによって興味が失われることに起因する。
【０１５３】
ＩＳＩＣＩは、購入サイクルを数ヶ月から短い時間に圧縮する機能がある。図１６に示すように、購入者は、マルチリンクメニューにより可能にされた広告上で迷うと、様々な市場取引セグメント（例えば、購入者が入手可能な幾つかの車種をラインアップメニューアイテムの下で）１６１６、ブランド１６１７、様々なディーラー１６１５の在庫の情報を入手することができる。このように、購入サイクル全体は、最初の広告インプレッションから購入を通じて連続的に、単一のメニューをナビゲートすることによって達成可能となる。更に、広告者は、顧客が購入をすると彼らの行為は追跡されるから、メニューの効力を更に増加するために購入者によって好まれている情報とメニューアイテムを改良することができる。
【０１５４】
更なる追跡部の実施例
ＩＳＩＣＩの追跡サービスは、マルチリンクメニューの効力をエンドユーザーのこれらメニューとのインターラクションの結果を実際に監視することによって定量的に測定する能力を有する。ある実施例において、ＩＳＩＣＩシステムは、ＩＳＩＣＩシステムは、その他の方法でウェブサイトに辿り着いたヒットと訪問者に反して、ヒット数とユニークな訪問者がマルチリンクメニューを介して所与のウェブサイトに駆り立てられたかを決定することができる。これは、オフライン媒体広告の場合のように単に環境的に関連するよりも、特にかつ直接にメニューに起因するヒットと訪問者を測定することによって、メニューの効力の正確な監視を見込んでいる。また、ターゲットウェブサイトが参照コードを認識してクレジットすることができるショッピングカートを有する場合、システムはいくつの実際の販売、購読、その他の商業的な取引がマルチリンクメニューを介して参照されたかを決定することができる。この場合、現実の貨幣的な利益と投資の回収はマルチリンクメニューに起因することになる。また、システムは、訪問者及び購入を最初にメニューを見た原訪問者数と比較することによって、メニューのクリックスルー率とこれらの終局のヒットと販売変換率を測定することができる。
【０１５５】
新しい広告モデルにおけるマルチリンクメニューの役割はここで説明した。ＩＳＩＣＩは、エンドユーザーの決定プロセスの広告者の概念の実際の表現としてのマルチリンクメニューの効力を測定することができる（例えば、メニューの異なるブランチと進路が将来の顧客の決定寿命において異なる段階に対応する場合及びこの寿命の各段階がそれ自身の情報需要の集合をほのめかす場合）。システムは、メニューに埋め込まれているように、現実の顧客の振る舞いに適合する正確性を経験的に測定することによって、市場取引者の寿命概念の効力を実際に追跡することができる。このように、ある程度、市場取引者の効力はマルチリンクメニュー広告運動設計に影響を与える変更に基づいて測定可能である。意思決定サイクル全体を通じてエンドユーザーが必要とする全情報需要を単一のメニューで提供することによって意思決定サイクルを圧縮する方法を述べた。いずれか一人の顧客に対してサイクルを日付順に圧縮することに加えて、この手法は、多くの顧客の全てが決定サイクルの様々な段階で既に存在する多くの顧客が所与の時点でこの単一の広告を介してサービスを受けることができるので、広範囲な顧客にサービスを与える利益も有する。
【０１５６】
かかる測定は、メニューを介してユーザーによってナビゲートされた特定のパスを追跡することによって達成可能である。このように、ある実施例においては、集合に全体的としてマルチリンクの効力を単に測定する代わりに、マルチリンクのメニューの個別的なパスは、効力を決定するために、監視及び／又は測定可能である（例えば、メニュー全体がクリックスルー及び購入を行うかどうかがメニューの個別的なパスの関数として測定可能であるかどうか）。更に、ＩＳＩＣＩは、メニューを通じて書く別個のパスを関し及び別個に測定し、ユーザーがあるパスを何回選択したかを他と比較して報告することができる。
【０１５７】
かかる追跡が達成可能となる少なくとも２つの手法がある。１）ＩＳＩＣＩはメニュー自体と対話する際にユーザーの振る舞いを追跡することができる（即ち、特定のメニューリンクを通じてクリックすることを選択する前に）、及び／又は、２）システムは、ユーザーが特定のリンクを通じて現実にクリックし、ターゲットに到達すると、ユーザーのインターラクションの最終結果を追跡することができる（ウェブページ、ショッピングカート、ウエリー、及び／又はその他の取引）。幾つかの点で、それらが同一のユーザーの振る舞いを２つの異なる角度から測定する点で２つの手法は重なる。ユーザーのクリックスルーの２つの異なるエンドは、ａ）ターゲットサイトから遠ざかるようにクリックすることによってユーザーが開始する場合のメニューエンド、及び、ｂ）ユーザーが到着するターゲットサイトエンドとして閲覧可能である。この点において、２つの手法は異なる現象を測定可能である。
【０１５８】
１）「メニュー自体」［「メニュー自体」は単なる提案であり、自由に却下して欲しい。しかし、私は、後述の発生を変更した］手法はユーザーのメニュー自体とのインターラクションを追跡する（即ち、メニューの様々な拡張階層セクションのロールオーバーの頻度、個別的なセクション又は個別的なリンクの迷い時間、いかなるクリックスルーの前のメニュー全体の迷い時間など）。メニュー自体手法はユーザーが最終的に特定のメニュー選択肢をクリックスルーしたことを追跡することもできる。しかし、その後、一旦ユーザーが離れてターゲットサイトに行ってしまうと、自体手法は、一般に、（「メニュー自体」手法からの情報と後で統合可能である）第２の「ターゲット追跡」手法を使用しないで、更なるユーザーの活動情報を検索するのに適合しなくなる。
【０１５９】
２）第２の「ターゲット追跡」手法は、ターゲットサイト自体でユーザーの到着とその後の振る舞いを追跡するが、少なくともその情報が「メニュー自体」手法によって把握された情報に統合されるまでは、一般にユーザーがクリックスルー前にメニューで何をしていたかを追跡しない。しかし、クリックするー前にメニューでユーザーの振る舞いをターゲットサイトで把握された追跡統計に基づいて推測することによって一つの例外が起こる。例えば、同一のユーザーが、１）最初にターゲットサイトの一ページに到着し、その後、２）しばらく後、異なるページに到着し（メニューからそのページに再度到着し）、その後、３）しばらく後、異なるページに到着し（メニューに再度戻ってそうしているうちに）、その後、メニューにおけるユーザーの振る舞いに関して情報提供する統計を集めることが依然としてできる。推測可能な統計の幾つかは、メニューの異なるツリーに戻ってナビゲートするのに必要な時間、メニューで隣接してクリックするー自体を生成又は生成しない異なるメニュー選択肢の相対的な有用性などを含む。
【０１６０】
ある実施例において、追跡機構自体はより完全に以下のように説明することができる。
【０１６１】
手法１）「メニュー自体」追跡の場合、追跡、メニューの異なる部分に対するロールオーバーの頻度、メニューの異なる部分の迷い時間、メニューオープンからクリックスルーまでの平均時間などの統計は幾つかの機構のいくらかを通じて測定可能である。ある実施例において、ＨＲＥＦに関連付けられたピクセルはメニューラベル内に追跡ポインターとして埋め込み可能であり、そのメニューのマウスオーバーがＨＲＥＦに関連付けられたサーバーに登録される。別の実施例では、特定のメニューラベルはＨＴＴＰポストに関連付け可能であり、そのメニューラベル（例えば、それをクリックスルーするユーザー）に関連付けられた如何なるイベントも、ユーザー自身が実際に他のそのメニューラベル（即ち、ターゲットレファレンス（例えば、ＵＲＬ）はユーザにとってクリックするがあるとそれに飛ぶ）に関連付けられたターゲットレファレンスに送られても、（ＨＴＴＰポストのターゲットである）サーバーに記録可能である。
【０１６２】
手法２）「ターゲット追跡」の場合、メニューにおける各別個のクリックスルーポイント（即ち、ユーザーをターゲットレファレンス（例えば、ウェブサイト、ショッピングカート、プロセス、クエリー及び／又はその他の取引）に送ることができる各メニュー選択肢は前もってターゲットレファレンスに付属された参照コードなどの機構を有することができる。かかるコードは、マルチリンクメニューの作成／維持の間供給可能である。このように、ユーザーがターゲットレファレンスに到着すると、参照コードはユーザーを、マルチリンクメニューからだけでなくマルチリンクの特定のメニュー選択肢に由来するものとしてはっきりと識別する。例えば、ユーザーが図１６の「在庫検索」１６２１をクリックし、ユーザーが在庫を検索することができる図１６のクライスラーの汎用ウェブページ１６２２に行くと、「?linkstorm_path=crossfire」がメニュー選択肢を介してメニューの「クライスラーラインアップ＞クロスファイアー＞在庫検索」パスの下で、即ち、「クライスラーラインアップ＞ＰＴクルーザー＞在庫検索」のパスや、「クライスラーを所有＞購入＞在庫検索」のパス、又は、同一のターゲットＵＲＬに導かれる他のパスを通らずに、このユーザーがこのページに来たことを表す参照コード及びバリューであるとすると、メニューラベル「クライスラー在庫検索」は次のようになる。「http://www.chrysler.com/bridge/full_inventory.html?linkstorm_path=crossfire」
このように、異なるパスの相対的な人口が測定可能となる。同様に、ユーザーが到着するターゲットウェブサイトにおいて、サイトの標準サーバーログはこのユーザーがこのページ「http://www.chrysler.com/bridge/full_inventory.html」に来たことを、ＵＲＬ「http://www.chrysler.com/bridge/full_inventory.html?linkstorm_path=crossfire」
に実際に行くことによって記録し、後者のＵＲＬ（又は参照コード「?linkstorm_path=crossfire」を終わりに有するＵＲＬ）への訪問者の全記録を検索し、これらの統計をエクセルのスプレッドシートに、ＩＳＩＣＩデータベース及び／又は他の報告機構にコンパイルすることができる。また、同様に、ユーザーが購入まで進むと、殆どのウェブサイトの標準ショッピングカート機能は同一の参照コードを認識し、その参照を販売価格のａ％の手数料で貸方記録し又は単に参照の成功を追跡及び報告することができる。
【０１６３】
ターゲットサイトエンドからの結果は、クリックスルー率、販売変換率、図２０の２００５などの統合された分析的なメトリックスを生成するために、メニューエンドからの「メニュー自体」手法の結果に統合可能である。
【０１６４】
これらのメトリックスは、その後、図１のメニュー作成／維持システム１８１に（自動的に）送られる。前もって設定されたあるビジネスの規則に従って、これらのメトリックスは、前進するメニュー自身に対する変更を自動的に行うように設定可能である。ある実施例においては、前日に又は類型的に、実際の人口の順番でそれらをシャッフルすることによって一日一回メニューリンクの順番を変更する規則が作成可能である。例えば、図１４の「法律事務所に直ちに電話」１４４６は、それが最も人気があることを証明すればメニューの先頭に移動されて配置可能である。別の例では、図１５のメニュー１５３０の「スポンサー資源」リンクは自分の権利の広告であり、広告は、マルチリンクメニューの「不動産」にある。メニューは特定のスポンサーからのリンクで満たされているか、最初のスポンサーがより大きいクリックスルー率を引くことが分かった場合、他のスポンサーのリンクよりも頻繁にメニューに回転される。このマルチリンク広告メニューの実施例は、メニュにおいてより人気のあるメニュー選択肢をメニューをより頻繁に配置することは、より大きなクリックスルー率を引くことができ、これは、しばしば、ホストサイトの広告収入の直接的な行うものであるので、ホストするサイトの広告収入を最大限にする副産物を有する。
【０１６５】
別の例の規則は、それらが殆どインタラクトしかければメニュー全体からある選択肢を削除することである（例えば、１ヶ月クリックされなかったりその上で迷わなかったり）。別の例は、階層の下からメニュー選択肢をとり（例えば、図１６の「在庫検索」メニュー選択肢１６２１）、それが人気があることが判明したらメニュー階層１６３３の最初のレベルに移動する規則である。
【０１６６】
別の例において、メニュー一を変更すること（及び／又はリンクを追加又は削除すること）は、迷い時間とクリックスルーとの間の比、図１６のメニュー１６１０内で完全な動画視聴ビデオを見た後でユーザーがあるメニュー選択を通じてクリックする頻度のように複雑な測定などに基づいている場合がある。
【０１６７】
マルチリンクメニューは、特定のサイトでローカルにカスタマイズすることもできる。これは、特定のサイトでそのメニューの特定の状況に由来するように、参照を識別することができる異なる参照コードを特定することに拡張することができる。例えば、ある発行社のウェブサイトに配置された同一の広告は、そのサイトに特化した参照コードを含むように拡張可能である。一方、異なる発行社のサイトに配置された同一の広告はそのサイトに特化した参照コードを含むように補正可能である。
【０１６８】
このように、ＩＳＩＣＩ追跡機構は様々な組織を変更するのに特化した規則群と共に改良可能である。これは、各アフィリエートがアリフィエートに特化した参照コードをそれ自身の参照を識別するために使用し、それ自身の販売参照やクリックベースで報酬を得るかもしれない単なるクリックスルーのために販売クレジットを受信する参照コード関係ネットワークを作成する基礎となる。同一の特徴は、ある信用されたウェブサイトからの参照だけがターゲットサイトの機密情報、例えば患者の医療記録、軍事／監視情報、又は、閲覧に購読者の状況を要求する発行されたコンテンツを閲覧することを許される機密／アクセス制御コンテキストにおいても使用可能である。
【０１６９】
本出願のどこでも記載されているように、メニューの変更を行うソースデータは、メニューに結合されたユーザの現実の振る舞いに全く関係する必要はない。リストの先頭においてある車のモデルの配置を変更することは、代わりにこれは最もよく売れているモデルであることを示す独立して測定された販売記録によって駆り立てられるかもしれない。図１００（リアルプレイヤーの例）において、現在の歌のトップ４０チャートランキングなど独立したソースデータに従って、歌がメニューから追加又は除去されたり、順番が変更されたりすることができる。図９９（ＭＳＮ検索の例）では、法律事務所は、ユーザーがどれくらい頻繁に様々な法律事務所をクリックするかによって（我々の追跡機構を通じて監視される）駆り立てられる順番で実際に所与の都市内でリストになってもよいが、順番は、異なる法律事務所が広告に対する全支出やマーティンデール・ハッブルからのその他のサービスなどの独立したデータによって代替的に駆り立てられるであろう。
【０１７０】
クライスラーの車を有するある実施例において、ローカルディらーはクライスラーのバックエンドシステムから在庫情報は実際に検索され、図１６のメニューの最前１６１５に送られる。かかる情報は、個々のディーラーの販売実績に基づいて選択的に抽出可能である。このソースデータは、クライスラーのほかのバックエンドシステム（例えば、その販売データベース）に由来してもよい。代替的に、ローカルディーラーは、我々の追跡システム自体を通じて監視されるように、既に説明したように、エンドユーザーの振る舞いに全体的に基づいて表示用に選択されてもよい。
【０１７１】
独立したソースデータは、例えば、個別的か集合的かの、ユーザーの人口情報、ユーザーの嗜好、他の独立システムにおいて記録される利益、ユーザーの地理的場所、メニューが閲覧される日時などのように、多くの他の種類から構成される。
【０１７２】
結局、フィードバック機構は、マルチリンクメニューが実世界からのフィードバックに基づいて自己改善することを可能にする。そのフィードバックは、購入サイクルの広範囲な段階に亘って広範囲の顧客によって要求される顧客情報需要の全体の範囲の表現になり得る洗練された情報処理メニューにおける変更を行うことができる。このように、その表現は、広告者にとってより効果的であるのと同様に、それ自身の効力及びに関する現実の経験的な情報に基づいて、及び／又は、メニューをより関連性があり、顧客に有用になるようにする他の独立して収集される情報に基づいて、自己改善になり得る。これらの自己実現変更は、規則に基づいて完全に自動化が可能であるか、ユーザーの振る舞いに関するデータ及び／又は他のソースデータの人間の批評に基づいて手動で実現されてもよい。
【０１７３】
変更が人間の判断を使用する場合、ＩＳＩＣＩは、方法を大きく補助する自動機構を与える。マルチリンクエディタは、マルチリンクメニューの更新とその後に更新された記録のハンドルシステムへの掲載を許容する。他の如何なるメニューの更新、維持及び／又は整備のための「表示のレベル」は原則として等しく機能し、本発明によって等しくカバーされるであろうということに留意しなければならない。しかし、これらの他の代替的な手法は、ハンドルシステムからの標準ベースの恩恵と更なる拡張性を行うことができる。マルチリンクエディタは、これらの様々なメニュー選択肢に記録された相対的な人気（例えば、インプレッション１８３６、クリックスルー１８３７、クリックスルー率、迷い時間、ロールオーバーの頻度など）を示す統計の目に見える表示部を与える。このように、人間エディタは、変更が実際になされるマルチリンクエディタ内で経験的な追跡データを有する。
【０１７４】
様々な実施例
このように、ＩＳＩＣＩ以前には、この種のデータをとってそれをメニューが実際に作成されて最初に維持されるプロセスの最初に戻すフィードバックループを有するシステムがない。分配と維持の点で、ＩＳＩＣＩによって一旦配置される広告のフォーマットは、自動的に維持される。ＩＳＩＣＩが存在する前に、変更が必要になると、広告自体が変更されなければならず、その後すべての場所に再整備されなければならない。このように、広告の更新は、特に、広告の目的が大部分注意の把握であるリッチメディア広告の場合には時間がかかる。かかる広告は、独創性が高く、手間がかかり、画像に凝っている。その結果、それらは参照リンクを更新するのに長時間を要する。かかる古いスタイルの広告があると、それらが最終的に改善されると、新しい「マスター」コピーが広告整備機構に送られなければならず、それはその後全ての適当な場所に改訂された広告を送付される。これに対して、ＩＳＩＣＩは、あらゆる場所の広告の全てはそれらがロードされた時間毎に中央制御可能である。従って、マルチリンクメニューは、ウェブ上のマルチリンクメニューを使用して広告の全ての発生を直ちに外に伝播する。
【０１７５】
ＩＳＩＣＩ手法は、伝統的な広告整備機構に等しく同様に適用可能である（即ち、マルチリンクメニューはダブルクリックらを通じて整備可能である）。マルチリンクは、バナー、リッチメディア広告、コンテクスチュアル広告（例えば、グーグルのスポンサーリンク）、コンテクスチュアルリンク（例えば、バイブラントメディア）、ビデオファイル（例えば、クイックタイム）など現存する広告フォーマットの先頭にも積層可能である。これらの他の広告フォーマットは、マルチリンクメニューに対する配達機構として機能することができる。従って、マルチリンクメニューは、ハンドルシステムなどの中央ディレクトリへのＩＳＩＣＩの呼び出しに加えて及び／又は代わりに、現存する分配方法を通じて分配可能である。他の更新及び維持の「レベルの間接的行動」は、追加の拡張性と標準ベースの利益をハンドルシステムに与えることによって原則的に等しく上手に機能する。別の長所は、マルチリンクメニューによって可能された広告が処理、情報供給的になり、機能的になり、ナビゲート可能になり、中央制御可能になることである。更に、その中央制御は、メニューとユーザーとのインターラクションから追跡される経験的なユーザーの振る舞いデータに基づいてメニューを改善するフィードバックループと共に今や増大されている。
【０１７６】
このフィードバックは、このソースデータに基づいて人間の判断を介して達成可能である（例えば、メニューが手動で変更されるか、自動化された「流れ作業」プロセスが人間の判断に基づいて進む異なるメニュー作成規則に適用するように変更される場合）、又は、フィードバックの改良は、予め格納されたビジネス規則に基づいてデータがメニューにおける変更を直接的に行うことを可能にすることによって完全に自動化可能である（即ち、自動的に自己改善する）。例示的な規則は、より多くの選択数を有して追跡されるメニューアイテムがメニューの先頭に移動される、エンドユーザーのカーソルからより多くの迷い時間を有して追跡されるメニューアイテムはメニューの先頭に移動される、より高い指値を有するスポンサーリンクをメニューの高い位置に配置する、新しいメニューアイテムのエントリーをメニューの高い位置に配置する（例えば、新しい製品発表）、より少ない頻度のメニューアイテムをクリックスルーを増加する目的でメニューリストの先頭に配置する、外部リストのマッピングをメニューリンクの順番付けに使用する（例えば、トップ４０リストはメニューアイテムをランク付けするのに使用される）などである。
【０１７７】
それと共に、ＩＳＩＣＩにより表されたサービスの統合された組が、完全に新しい概念的手法がアプローチに広告及び顧客インターラクションオンラインを可能にする。例えば、マルチリンクメニューにより可能にされた広告はユーザーに広告に関連する広範囲な選択肢をとることを可能にするのみならず（例えば、しぶき／着水のページへのナビゲーションをもたらす単一のリンクのみの代わりに）、根本的に異なるユーザーにサービスする手法可能にする。
【０１７８】
以下は、これらの新しい手法の幾つかであり、それらが紹介する新しいビジネスプロセスは以下の通りである。
【０１７９】
ある実施例において、これらのマルチリンクはデープリンクの広いアレイをユーザーに提供するので（例えば、マルチリンクメニューがスクリーンサイズの実施によってのみ制限され、典型的には、階層的なドロップダウンメニューを介してきちんと展開する、少なくとも３０−４０の別個のリンクを有する）、それらはユーザーにそれらに利用可能な選択肢の全体的な領域を晒す。それはユーザーが単にマウスロールオーバーを通じてレファレンスターゲット（例えば、ウェブサイト）で入手可能な全選択肢を通じて潜在的に新規で見慣れないウェブサイトでスクリーンからスクリーンにクリックする必要なしにナビゲートする。ロールオーバーだけで利用可能な「クリックレスナビゲーション」は、ユーザーに直接に申し出、ショッピングカート、又は関連製品を提供する時間を徹底的に減少する。この「クリックレスナビゲーション」は、リンク（例えば、広告）を通じてウェブサイトに伝統的にクリックし、そのページがロードするまで待ち、そのページで新しい選択肢を読み、他の何かにクリックし、クリックが間違っていたと判断し、同様のナビゲーションの負担と再表示時間の問題を発生する別のパスを通ってクリックをしなければならないなどの手法よりも優れている。伝統的なプロセスは、断片、エラー、顧客の注意の喪失、クリックごとの遅延（新しいページをロードする）などの潜在性で満ちている。マルチリンクメニューはこれらの欠点の全てを解決している。
【０１８０】
従って、伝統的な広告フォーマットは、ユーザーのクリックを生成しようとするように志向し、クリックスルー（グーグルのアドワークス及びアドセンス）ペイパークリック広告モデルに基づいて報酬を得る点にさえ、本発明は、あらゆるクリックが機会であるが、あらゆるクリックがりすくでもあることが約束されている。マルチリンキングとクリックレスナビゲーションがあれば、ユーザーの注意を把握することと、ユーザーを本当に彼らが欲しいものに直接に向けることとの間の時間が劇的に減少されている。ロールオーバーを介した早く効率的な利用プロセス後に単一のクリックがユーザーが彼らが本当に欲しいものに直接に向ける。その結果、マルチリンクメニューは、通常のハイパーリンクよりも相当高いクリックスルー率を作成する。また、ユーザーがマルチリンクメニューを通じてクリックしてターゲット（例えば、ウェブサイト）に到着すると、そのユーザーは伝統的なウェブ広告を介してサイトに到達した訪問者よりも購入の可能性が高い。
【０１８１】
また、マルチリンクは、顧客の広いスペクトルと顧客の購入サイクル段階の広いスペクトルの両方にサービスを提供する機会を与える。顧客の購入プロセスには自然寿命サイクルがあり、特に、情報集約的な購入決定（例えば、車、コンシューマー電子部品、医者又は弁護士などの専門サービスなど）の場合にあり、サイクルの終わりよりも（彼らが欲しいものを作成、モデル化及び特徴付け、ローカルディーラーの中で誰がベストプライス又はインセンティブを有するか、及び、実際に車の在庫を有しているか）、サイクルの初めに（例えば、車の購入から６ヶ月後、ミニバン対ＳＵＶ対ステーションワゴンを求めているのかを単に決定すると）、顧客は異なる情報が必要である。また、マルチリンクは、購入サイクルのこれらの全段階における顧客スペクトラム全体にサービスを提供することができ、それをすること全ては単一のメニュー内で行うことができる。従って、マルチリンクメニューは購入サイクルを圧縮する。
【０１８２】
更に、マルチリンクメニューの設計及び実施の発見的方法は、その後、企業の市場取引戦略により服し、これによってサイクルの異なる段階の異なる顧客は、同一の広告を介して全て適当にサービスを提供されることができる。このプロセスは、サービスの診断と最良の実施の共有を介して容易になる。このように、マルチリンクメニューは、その特定の顧客及び彼らの購入サイクルの特定の段階に関して広告者の市場取引戦略を直接表現する。例えば、図１６において、第１のメニュー選択肢「クライスラー物語」１６０６は、異なるブランドに丁度慣れた早期段階の顧客に志向されたリンク群を表示するように拡張する。第２の選択肢「クライスラーの違い」は他のブランドに対するクライスラーの選択肢を支持するリンク群を生む。第３「クライスラーラインアップ」１６１８は、図において実際に拡張して表示されているが、様々なクライスラーモデルの詳細を提供する。また、マルチリンクメニューは、ユーザーをローカルディーラー在庫情報にわざわざ連れて行き、クライスラー及び／又はそのディーラーネットワークのバックエンド在庫システムからわざわざ送り出し、マルチリンクメニューの全面に表示する。
【０１８３】
更に、ユーザーの振る舞いが監視可能で前進型のマルチリンク作成／維持プロセスにフィードバックされるので、システムは自己改善型である。例えば、ローカルディーラーは、顧客が実際にそれら特定のディーラーを何回（又はどれくらい少なく）実際にクリックしたかに基づいてメニューに追加又は除去されることができる。あるいは、メニューの変更を行うソースデータは全体的に、どのディーラーが最高販売量を売買しているかを示すクライスラー自身の独立の販売記録など別のソースになり得る。あるいは、再び、メニューを改善するソースデータは、メニューとインターラクトする際に顧客の実際の振る舞いを把握する追跡データとなり得る。例えば、どのモデルが最も長く躊躇われたかに従ってメニューにおけるクライスラーのモデルの順番を変更したり、ユーザーのクリックスルーを実際に引き込んだかどうかに基づいて特定の販売インセンティブを追加又は削除することである。
【０１８４】
マルチリンクメニューは、広告及び実際にはウェブナビゲーションにおいて一般に新しい概念を表現する。それ自身の製品ラインアップとそのマーケティング戦略又は顧客サービスを知る結局専門家であるリンクの作成者は、ナビゲーション体系全体を定義するが、ユーザーがどこに行くべきかを選択する者である。ユーザーの注意に侵入したいと考える広告者と注意を乱すものを欲しないユーザーとの間の伝統的な争いと異なり、マルチリンクドリップダウンメニューは控えめで顧客フレンドリーである。マルチリンクメニューはユーザーのブラウザー状態を破壊しない。それらはロールオーバーされると現れ、ユーザーがマウスを離すと直ちに消える。ユーザーは、広告をクリックすることによって信用のジャンプをなす前でさえ、それらが情報提供的であり、有用で効率的であると考える。更に、ユーザーは、ここが自分が本当に生きたい場所であることを既に決定した後で、特定のリンクを通じてクリックするだけである。前もって選択肢の全範囲を見ることは、ガラスドアを見て、反対側に既に見えているものへそれを通じて行きたいかどうかを単に決定することのようである。これに対比されるのは、不透明な木製ドアを見て反対側には何か有用なものがあることを信用してジャンプしなければならないことである。これは、広告社がユーザーに以前よりも広範囲な情報と申し出を提供するので、安全であるが、ナビゲートと選択をすることができるものはユーザーである。
【０１８５】
このように、マルチリンクメニューは、広告、電子商取引及びユーザーインターラクションにおいて補助する、以下のいかなる数の機器をも使用することができる。
【０１８６】
マルチリンクによって可能にされたバナー広告（即ち、表示広告）（例えば、図１６の１６７７）。
【０１８７】
マルチリンクによって可能にされたスポンサーリンク（例えば、グーグルアドセンス又はアドワーズ）（例えば、図１４の１４１７）。
【０１８８】
図１５のマルチリンクによって可能にされたコンテクトに埋め込まれたリンク１５４５。
【０１８９】
コンテンツ志向のマルチリンクの混合（例えば、発行社がマルチリンクをそれ自身のコンテンツに対して作成したが、同一のマルチリンクメニューをそれがスポンサーとしての地位、特別の広告者リンクなどを販売することができる「不動産」として使用する場合）（例えば図１５の１５６５）。
【０１９０】
マルチリンクメニューを直接に文書、カタログ、ＰＤＦファイルなどに配置すること−それらの永続性のため、それらはマスター記録に維持されている現在／最新リンクを常に表示するだろう。
【０１９１】
マルチリンクメニューをビデオファイルなどのマルチメディアファイルに配置すること、エンドユーザーがカーソルをビデオファイル上で動かすとメニューが使用され、ユーザーがビデオを一時停止し、マルチリンクメニューが更にシーン、製品、広告などの情報を提供することができる。家庭用ビデオにおいて、フラッシュビデオは、ショー、アクセサリー、特徴付けられた販売製品などを提供する小売店から製品の使用に関するメニューアイテムを有するであろうマルチリンクメニューを使用することができる。
【０１９２】
マルチリンク広告をメディアプレーヤー及び製品レファレンスが行くことができるその他の場所に配置すること（例えば、図１５の６６７）。
【０１９３】
マルチリンクメニューを、実際のユーザーの振る舞いが進行中で、自己改善型で、内部資源に高効率アクセスを行うことができる、企業イントラネット又はその他の内部「企業環境」内に配置すること。
【０１９４】
広告、電子商取引及びオンライン顧客インターラクション制御部のための統合、情報処理及び自己改善ファシリティ
図２２は、広告、電子商取引及びオンライン顧客インターラクション（ＩＳＩＣＩ）制御部２２０１のための統合、情報処理、及び自己改善ファシリティの実施例を示すブロック図である。本実施例において、ＩＳＩＣＩ制御部２２０１は、マルチリンク関連データを追加、編集、処理、格納、検索、整備、識別、命令、生成、一致、提供、及び／又は、更新することができる。
【０１９５】
典型的に、ユーザーは、人及び／又はその他のシステムであるかもしれないが、情報処理を容易にするために情報技術システム（例えば、共通のコンピュータ）を使用する。代わって、コンピュータは、中央処理ユニット（ＣＰＵ）としばしば呼ばれ、情報を処理するプロセッサを使用する。プロセッサの共通形態は、マイクロプロセッサと呼ばれる。コンピュータオペレーティングシステムは、典型的にコンピュータ上でＣＰＵによって実行されるソフトウェアであるが、ユーザーがコンピュータ情報技術及び資源にアクセス及び操作することを可能にして容易にする。情報技術システムにおいて使用される共通の資源は、データがコンピュータに入って出て行くことができる入力及び出力機構、データが保存されるメモリストレージ、及び、情報を処理するプロセッサを含む。しばしば、情報技術システムは、データを収集して後で検索、分析、操作するのに使用され、データベースソフトウェアを通じて共通に容易にされる。情報技術システムは、ユーザーが様々なシステムコンポーネントにアクセス及び操作するのを許容するインターフェースを与える。
【０１９６】
ある実施例において、ＩＳＩＣＩ制御部２２０１は、ユーザー入力装置２２１１、周辺装置２２１２、及び／又は、通信ネットワーク２２１３からの一以上のユーザーであるがこれに限定されないエンティティに接続可能及び／又は通信可能である。ＩＳＩＣＩ制御部は、暗号プロセッサ装置２２２８に接続及び／又は通信可能でさえある。ＩＳＩＣＩ制御部は、通信ネットワークを介してクライアント２２３３と通信することができる。ＩＳＩＣＩは、多数のクライアント及び／又はユーザー２２３３に仕えるように構成されてもよい。ある実施例においては、ＩＳＩＣＩは、ＩＳＩＣＩ需要により良いサービスを提供するために、そして、負担及び／又はサービス要求をより良く均衡するために分配可能である。
【０１９７】
ネットワークは、グラフトポロジーにおけるクライアント、サーバー及び仲介者ノードの内部接続及び内部操作を共通に有するものと考えられている。本開示において使用される「サーバー」という用語は、一般に、ユーザーの要求を処理して応答し、通信ネットワークに頻繁にアクセスされるコンピュータ、その他の装置、ソフトウェア及び／又はそれらの結合を意味すると留意されるべきである。サーバーは、要求「クライアント」に情報を差し出す。ここで使用される「クライアント」という用語は、一般に、処理、要求、及び、サーバーからのいかなる応答をも取得及び処理することができるコンピュータ、その他の装置、ソフトウェア及び／又はそれらの結合を意味する。一般に、「クライアント」という用語と「ユーザー」は相互に変更可能であり、本開示に亘ってそのように使用される。情報及び要求を容易にして処理する、及び／又は、ソースユーザーからデスティネーションユーザーへの情報の通過を促進するコンピュータ、その他の装置、ソフトウェア及び／又はそれらの結合は一般に「ノード」と呼ばれている。ネットワークは、一般に、ソースポイントからデスティネーションまでの情報の移転を容易にするように考えられている。ソースからデスティネーションまでの情報の通過を容易にする機能を特に有するノードは、一般に「ルーター」と呼ばれる。ローカル・エリア・ネットワーク（ＬＡＮ）、ピコネットワーク、ワイド・エリア・ネットワーク（ＷＡＮ）、ワイヤレス・ネットワーク（ＷＬＡＮ）などのネットワークの多くの形態がある。例えば、インターネットは、多数のネットワークの内部接続であるとして一般に受け入れられており、リモートクライアント及びサーバーは互いにアクセス及び内部動作することができる。
【０１９８】
ＩＳＩＣＩ制御部２２０１は、メモリ２２２９に接続されたコンピュータ体系２２０２などのコンポーネントを有するが、これに限定されない通常のコンピュータシステムに基づいてもよい。
【０１９９】
コンピュータシステム
コンピュータシステム２２０２は、クロック２２３０、中央演算処理装置（ＣＰＵ）２２０３、読み出し専用メモリ（ＲＯＭ）２２０６、ランダム・アクセス・メモリ（ＲＡＭ）２２０５、及び／又は、インタフェースバス２２０７を有しており、必ずしもではないが最も頻繁には、全てが相互接続され、及び／又は、システムバス２２０４を介して通信している。随意に、コンピュータシステムは、内部電源２２８６に接続される。随意に、暗号プロセッサ２２２６は、システムバスに接続される。システムクロックは、通常、水晶発振器２２２６を有し、基準信号を供給する。クロックは、通常、システムバス、及び、コンピュータシステム内で相互接続された他の構成部品に与える基準動作周波数を増加又は減少させる各種のクロック乗算器に接続されている。クロック及びコンピュータシステムの各種構成部品は、システム全体の情報を統合する信号を駆動する。そのようなコンピュータシステム全体の情報を統合する信号の送信及び受信は、通常、通信と呼ばれる。これらの通信信号は、当該コンピュータシステムを超えて、さらに、通信ネットワーク、入力装置、他のコンピュータシステム、周辺機器などに対して、送信され、受信され、返信及び／又は応答信号通信を行う。もちろん、上記構成部品のいずれの部品も直接互いに接続され、ＣＰＵに接続され、及び／又は、各種のコンピュータシステムにより実証されたものとして用いられる非常に多くのバリエーションで組織化される。一つの随意的な実施例において、全地球測位システム（ＧＰＳ）受信機２２７５は、例えばシステムバス２２０４を介して、ＩＳＩＣＩ２２０１に接続される。モトローラ・インスタントＧＰＳチップのような単一のＧＰＳチップは、ＩＳＩＣＩ２２０１に位置を把握させるために用いられる。
【０２００】
ＣＰＵは、少なくとも、ユーザの要求、及び／又は、システムで発生した要求を実行するための構成部品による命令を実行するのに十分な、一つの高速データプロセッサを有する。ＣＰＵは、ＡＭＤのアスロン、デュロン、及び／又はオプテロン、ＩＢＭ及び／又はモトローラのパワーＰＣ、インテルのセレロン、アイテニアム、ペンティアム、ジーオン、及び／又は、エックススケールなどのようなマイクロプロセッサである。ＣＰＵは、通常のデータ処理技術に従い格納された命令コードを実行するため、導電性のコンジットを介した信号経路を介して、メモリと情報のやり取りを行う。そのような信号経路は、ＩＳＩＣＩコントローラ内部における通信、及び、各種インタフェースを介した通信を容易にする。処理に高速スピードが要求される場合には、並列、メインフレーム、及び／又は、超高速コンピュータのアーキテクチャが同じように用いられる。代わりに、配置に携帯性が要求される場合には、より小さな携帯情報端末（ＰＤＡ）が用いられる。
【０２０１】
電源
電源２２８６は、アルカリ、リチウムハイドライド、リチウムイオン、ニッケルカドミウム、太陽電池などの電池のように、小さな電子回路基板デバイスに電力を供給するためのものであればどのような標準型の種類でもよい。ＡＣ又はＤＣ電源の他の種類の電源も用いられる。太陽電池の場合、一つの実施例においては、太陽電池が光子エネルギーを捕獲するための開口が設けられる。電池２２８６は、ＩＳＩＣＩに相互接続された構成部品の少なくとも一つに接続され、電流をこれら全ての構成部品に供給する。一例では、電源２２８６は、システムバス構成部品２２０４に接続される。他の一例では、外部電源２２８６はＩ／Ｏ２２０８インタフェースを渡った接続部を介して供給される。例えば、ＵＳＢ及び／又はＩＥＥＥ１３９４接続は、データ及び電源の両方をその接続部を渡って伝え、従って、適切な電源である。
【０２０２】
インタフェースアダプタ
インタフェースバス２２０７は、通常、必ずしも入出力インタフェース（Ｉ／Ｏ）２２０８、ストレージインタフェース２２０９、ネットワークインタフェース２２１０など（ただし、これらには限定されない）のようなアダプタカードの形態ではないが、多くのインタフェースアダプタを受け入れ、接続し、及び／又は、通信する。随意に、暗号プロセッサインタフェース２２２７は、同じようにインタフェースバスに接続される。インタフェースバスは、インタフェースアダプタ同士及びインタフェースアダプタとコンピュータシステムの他の構成部品の通信を規定する。インタフェースアダプタは、互換性のあるインタフェースバスに適用される。インタフェースアダプタは、通常、スロットアーキテクチャを介してインタフェースバスに接続される。通常のスロットアーキテクチャは、ただし限定されるものではないが、アクセラレイティッド・グラフィックス・ポート（ＡＧＰ）、カードバス、（エクステンディッド）インダストリアル・スタンダード・アーキテクチャ（（Ｅ）ＩＳＡ）、マイクロ・チャネル・アーキテクチャ（ＭＣＡ）、ニューバス、ペリフェラル・コンポネント・インターコネクト（エクテンディッド）（ＰＣＩ（Ｘ））、ＰＣＩエクスプレス、パーソナル・コンピュータ・メモリカード・インターナショナル・アソシエーションＰＣＭＣＩＡ）などが用いられる。
【０２０３】
ストレージインタフェース２２０９は、これらに限定されないが、ストレージデバイス２２１４、取り外し可能なディスクデバイスなどのような多くのストレージデバイスを受け入れ、通信し、及び／又は、接続する。ストレージデバイスは、ただしこれらに限定されないが、（ウルトラ）（シリアル）アドバンスト・テクノロジー・アタッチメント（パケットインタフェース）（（ウルトラ）（シリアル）ＡＴＡ（ＰＩ））、（エンハンスト）インテグレイト・ドライブ・エレクトロニクス（（Ｅ）ＩＤＥ）、インスティチュート・オブ・エレクトリカル・アンド・エレクトロニクス・エンジニアズ（ＩＥＥＥ）１３９４、ファイバチャネル、スモール・コンピュータ・システムズ・インタフェース（ＳＣＳＩ）、ユニバーサル・シリアル・バス（ＵＳＢ）などの接続プロトコルを用いる。
【０２０４】
ネットワークインタフェース２２１０は、通信ネットワーク２２１３を受け入れ、通信し、及び／又は、接続する。ネットワークインタフェースは、ただしこれらに限定されないが、直接接続、イーサネット（シック，シン，ツイストペア１０／１００／１０００ベースＴなど）、トークンリング、ブルートゥース、携帯、ＩＥＥＥ８０２．１１ａ−ｘなどのワイヤレス通信のような通信プロトコルを用いる。通信ネットワークは、次のいずれか一つ、及び／又は、組み合わせからなる。すなわち、直接相互接続、インターネット、ローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、オペレーション・ミッションズ・アズ・ノーズ・オン・ザ・インターネット（ＯＭＮＩ）、セキュアドカスタムコネクション、ワイドエリアネットワーク（ＷＡＮ）、ワイヤレスネットワーク（例えば、ただしこれらに限定されないが、ワイヤレスアプリケーションプロトコル（ＷＡＰ）、Ｉモードなどのプロトコルを用いる）などである。
【０２０５】
入出力インタフェース（Ｉ／Ｏ）２２０８は、ユーザ入力装置２２１１、周辺機器２２１２、暗号プロセッサ装置２２２８などを受け入れ、通信し、及び／又は、接続する。Ｉ／Ｏは、ただしこれらに限定されないが、アップルディスクトップバス（ＡＤＢ）、アップルディスクトップコネクタ（ＡＤＣ）、オーディオ（アナログ、デジタル、モノラル、ＲＣＡ、ステレオなど）、ＩＥＥＥ１３９４ａ／ｂ、赤外線、ジョイスティック、キーボード、ミディ、オプティカル、ＰＣ  ＡＴ、ＰＳ／２、パラレル、ラジオ、シリアル、ＵＳＢ、ビデオインタフェース（ＢＮＣ、同軸、コンポジット、デジタル、デジタルビジュアルインタフェース（ＤＶＩ）、ＲＣＡ、ＲＦアンテナ、Ｓ−Ｖｉｄｅｏ、ＶＧＡなど）、ワイヤレスなどのような接続プロトコルを用いる。通常の出力装置は、ビデオインタフェースから信号を受け入れるテレビジョンセット１４５である。また、通常、ビデオインタフェースから信号を受け入れるインタフェース（ＤＶＩ回路及びケーブル）を備え、陰極線管（ＣＲＴ）又は液晶ディスプレイ（ＬＣＤ）をベースとしたモニタを有するビデオディスプレイも用いられる。ビデオインタフェースは、コンピュータシステムにより生成された情報を合成し、ビデオメモリフレーム中において、合成した情報に基づいてビデオ信号を生成する。通常、ビデオインタフェースは、ビデオディスプレイインタフェース（例えば、ＲＣＡ合成ビデオケーブルを受け入れるＲＣＡ合成ビデオコネクタ、ＤＶＩディスプレイケーブルを受け入れるＤＶＩコネクタなど）を受け入れるビデオ接続インタフェースを介して、合成ビデオ信号を供給する。
【０２０６】
ユーザ入力装置２２１１は、カードリーダ、ドングル、指紋リーダ、グローブ、グラフィックタブレット、ジョイスティック、キーボード、マウス、リモートコントロール、網膜リーダ、トラックボール、トラックパッドなどである。
【０２０７】
周辺機器２２１２は、Ｉ／Ｏ、及び／又は、ネットワークインタフェース、ストレージインタフェースなどのような他の装置に接続され、及び／又は、通信する。周辺機器は、オーディオ装置、カメラ、ドングル（例えば、デジタル署名を用いて取引の安全を確保するコピー防止のためなど）、外部プロセッサ（追加機能のため）、グーグル、マイクロホン、モニタ、ネットワークインタフェース、プリンタ、スキャナ、ストレージデバイス、ビデオデバイス、ビデオソース、バイザーなどである。
【０２０８】
ユーザ入力装置及び周辺機器が用いられているが、ＩＳＩＣＩコントローラは、組込みの、専用の、及び／又は、モニタレス（すなわちヘッドレス）デバイスとして組み入れられており、アクセスはネットワークインタフェース接続部を渡ってなされることに注意しなければならない。
【０２０９】
ただしこれらに限定されないが、マイクロコントローラ、プロセッサ２２２６、インタフェース２２２７、及び／又は、デバイス２２２８のような暗号ユニットは、ＩＳＩＣＩコントローラに取り付けられ、及び／又は、ＩＳＩＣＩコントローラと通信する。通常、モトローラ社により製造されるＭＣ６８ＨＣ１６マイクロコントローラは、暗号ユニットのために、及び／又は、暗号ユニットの中で用いられる。ＭＣ６８ＨＣ１６マイクロコントローラは、１６ＭＨｚ構成における１６ビット乗加算命令を活用し、５１２ビットＲＳＡプライベートキー動作を１秒未満で実行する。暗号ユニットは、匿名の取引を許可するとともに、相互エージェントからの通信認証の機能を有する。暗号ユニットは、また、ＣＰＵの一部として構成される。他の商用に特化した暗号プロセッサには、ＶＬＳＩテクノロジの３３ＭＨｚ  ６８６８、又は、セマフォコミュニケーションズの４０ＭＨｚロードランナ１８４がある。
【０２１０】
メモリ
一般に、プロセッサに情報を記憶及び／又は取り出させる機械ファシリティ及び／又は実施形態はメモリ２２２９と見なされる。しかし、メモリは代替可能な工芸品であり資源であり、従って、いかなる数のメモリ形態でも代わりとしてあるいは呼応して使用できる。ＩＳＩＣＩコントローラ及び／又はコンピュータシステムでは様々な形のメモリ２２２９が用いられることを理解されたい。例えば、あるコンピュータシステムの構成をオンチップＣＰＵメモリ（例えば、レジスタ）、ＲＡＭ、ＲＯＭ、及びその他の任意の記憶装置の機能を紙穿孔テープ機構あるいは紙穿孔カード機構で提供することもできる。もちろん、このような実施形態を行えば、きわめて速度の遅い操作になるであろう。典型的な構成には、メモリ２２２９には、ＲＯＭ２２０６、ＲＡＭ２２０５、記憶装置２２１４が含まれるのが普通である。記憶装置２２１４は、どのような従来のコンピュータシステムの記憶装置であってもかまわない。記憶装置には、ドラム、（固定及び／又は取り外し可能）磁気ディスクドライブ、磁気光ドライブ、光学ドライブ（ＣＤ  ＲＯＭ／ＲＡＭ／記録型（Ｒ））、書込型（ＲＷ）、ＤＶＤ  Ｒ／ＲＷ、等々が含まれる。従って、コンピュータシステムには一般にメモリが必要であり、使用される。
【０２１１】
コンポーネント集合
メモリ２２２９には、プログラム及び／又はデータベースコンポーネント及び／又はオペレーティング・システムコンポーネント２２１５（オペレーティング・システム）、情報サーバーコンポーネント２２１６（情報サーバー）、ユーザーインターフェースコンポーネント２２１７（ユーザーインターフェース）、ウェブブラウザーコンポーネント２２１８（ウェブブラウザー）、データベース２２１９、暗号サーバーコンポーネント２２２０（暗号サーバー）、情報アクセス多重解決サーバー（ＩＡＭＲＳ）コンポーネント、ＩＳＩＣＩコンポーネント２２３５などのような（これらに限らない）データの集合（つまり、集合的に、コンポーネント集合）が含まれる。これらのコンポーネントは記憶され、記憶装置から及び／又はインターフェースバスを介してアクセス可能な記憶装置からアクセスされる。コンポーネント集合内にあるような、従来ないソフトウェアコンポーネントは、ローカル記憶装置２２１４に記憶するのが普通であるが、それらもまた全体的にまたは部分的に、通信ネットワーク、ＲＯＭ，様々な形態のメモリなどを介して周辺装置、ＲＡＭ，遠隔の記憶装置などのようなメモリにロードし、記憶する。
【０２１２】
オペレーティングシステム
オペレーティングシステムは、ＩＳＩＣＩコントローラを簡易に作動させる実行可能なインストラクションコードである。通常、オペレーティングシステムは１７０、ネットワークインターフェース、周辺装置、記憶装置などに簡易にアクセスする。オペレーティングシステムは、例えばアップルマッキントッシュＯＳＸ（サーバー）、ＡＴ＆Ｔプラン９、ＢＥ  ＯＳ、リナックス、ＵＮＩＸなどのオペレーティングシステムのような高度にフォールトトレラント（耐障害性）な、スケーラブル（拡張可能）な、安全なシステムである。しかし、アップルマッキントッシュ  ＯＳ、マイクロソフト  ＤＯＳ、Ｐａｉｒ  ＯＳ、ウインドウズ２０００／２００３／３．１／９５／９８／ＣＥ／ミレニアム／ＮＴ／ＸＰ（サーバー）などのようなより制限のある、安全性の少ないものも使用される。オペレーティングシステムは、それ自体及び／又は類似のものを含めコンポーネント集合内の他のコンポーネントに通信したり、これらと通信し合ったりする。オペレーティングシステムは他のプログラムコンポーネント、ユーザーインターフェースなどと頻繁に通信する。例えば、オペレーティングシステムは、プログラムコンポーネント、システム、ユーザー及び／又はデータ通信、要求、情報及び／又は応答の包含、通信、生成、取得、提供を行う。オペレーティングシステムは、一旦ＣＰＵで実行されると、通信ネットワーク、データ、入出力（Ｉ／Ｏ），周辺装置、プログラムコンポーネント、メモリ、ユーザー入力装置などとのインターラクションを可能にする。オペレーティングシステムは、ＩＳＩＣＩコントローラが通信ネットワーク２２１３を通じて他のエンティティと通信し合えるようにする通信プロトコルを備えている。ＩＳＩＣＩコントローラは、インターラクションのためのサブキャリアトランスポートメカニズムとして、例えばマルチキャスト、ＴＣＰ／ＩＰ、ＵＤＰ、ユニキャストなど（但し、これらに限らない）の様々な通信プロトコルを使用する。
【０２１３】
情報サーバー
情報サーバーコンポーネント２２１６は、ＣＰＵ回路コンポーネントを作動させるストアドインストラクションコードシグナルで構成されている。情報サーバーは、アパッチソフトウェア財団のアパッチ、マイクロソフト社のインタネット情報サーバーなど（これらに限らない）のような従来からあるインタネット情報サーバーである。情報サーバー用いると、アクティブ・サーバー・ページ（ＡＳＰ）、アクティブＸ、（ＡＮＳＩ）（オブジェクティブ）Ｃ（＋＋）、コモン・ゲートウェイ・インターフェース（ＣＧＩ）スクリプト、ジャバ、ジャバスクリプト、プラクティカルエクストラクションレポートランゲージ（ＰＥＲＬ）、パイソン、ウェブオブジェクトなどのようなプログラムを介してプログラムコンポーネントを実行できる。情報サーバーは、ファイル・トランスファー・プロトコル（ＦＴＰ）、ハイパーテキストトランスファープロトコール（ＨＴＴＰ）、セキュアーハイパーテキストトランスファープロトコール（ＳＨＴＴＰＳ）、セキュア・ソケット・レイア（ＳＳＬ）など（但し、これらに限らない）の安全な通信プロトコルをサポートする。情報サーバーは、ウェブページの形式で結果をウェブブラウザーに提供し、他のプログラムコンポーネントとインターラクションを行って行き届いたウェブページを生成するようにする。ＨＴＴＰ要求のドメイン・ネーム・システム（ＤＮＳ）解決部分が特定の情報サーバーに対して解決されると、情報サーバーは情報要求をＨＴＴＰ要求の残りの部分に基づいてＩＳＩＣＩコントローラの指定された場所で解決する。例えば、ｈｔｔｐ：／／１２３．１２４．１２５．１２６／ｍｙｉｎｆｏｒｍａｔｉｏｎ．ｈｔｍｌという要求には、ＤＮＳサーバーがそのＩＰアドレスの情報サーバーに対して解決する要求のＩＰ部分”１２３．１２４．１２５．１２６”があって、その情報サーバーが次に、その要求の”／ｍｙｉｎｆｏｒｍａｔｉｏｎ．ｈｔｍｌ”の部分のためにＨＴＴＰ要求を解析し、”ｍｙｉｎｆｏｒｍａｔｉｏｎ．ｈｔｍｌ”という情報を含むメモリ内の場所に解決して入れる。更に、様々なポート（例えば、ポート２１でのＦＴＰ通信など）通じて、その他の情報サービスするプロトコルが用いられる。情報サーバーはそれ自体及び／又は同類の他のプログラムを含めコンポーネント集合内の他のコンポーネントに通信したり、それらのコンポーネントと通信し合ったりする。また、ユニバーサルディスクリプション，ディスカバリーアンドインテグレイション（ＵＤＤＩ）、ウェブサービスディスクリプションランゲージ（ＷＳＤＬ）  及びウェブサービスフローランゲージ（ＷＳＦＬ）をデータ転送及びコンポーネント更新の基盤として使用してもいい。情報サーバーは、ＩＳＩＣＩデータベース２２１９、オペレーティングシステム、他のプログラムコンポーネント、ユーザーインターフェース、ウェブブラウザーなどと頻繁に通信し合う。
【０２１４】
ＩＳＩＣＩデータベーへのアクセスは、以下に列挙するスクリプト言語（例えば、ＣＧＩ）及び以下に列挙するアプリケーション間通信チャネル（例えば、ＣＯＲＢＲＡ、ウェブオブジェクトなど）のようなデータベースブリッジ機構を介して行われる。ウェブブラウザーによるデータ要求は、全てブリッジ機構によってＩＳＩＣＩが要求する適切な文法に分析される。ある実施例では、情報サーバーが、ウェブブラウザーがアクセス可能なウェブ形式を備えている。ウェブ形式の供給フィールドに入れるアイテムには特定のフィールドに記入がなされたというタグが付けられ、そのように解析される。そして記入されたアイテムはフィールドタグと共に渡され、それらが、適切な表及び／又はフィールドに入れるクエリを生成するようパーザに指示させる。ある実施例では、パーザは、タグの付けられたテキストアイテムに基づき適切なジョイン／セレクトコマンドでサーチストリングをインスタンシエートすることにより標準のＳＱＬでクエリを生成し、そこでできたコマンドがブリッジ機構を通してＩＳＩＣＩにクエリとして提供される。クエリからのクエリ結果を生成すると、結果はブリッジ機構を通して渡されて、解析され、新しい結果のウェブページがブリッジ機構によりフォーマットされ、生成される。次に、この新しい結果のウェブページは情報サーバーに提供され、情報サーバーはそれを要求ウェブブラウザーへ供給する。
【０２１５】
また、情報サーバーは、プログラムコンポーネント、システム、ユーザー、及び／又はデータ通信、要求、情報、及び／又は応答の包含、通信、生成、取得、提供を行う。
【０２１６】
ユーザーインターフェース
コンピュータインターフェースの機能は、いくつかの点で自動車の運転のインターフェースに似ている。ハンドル、ギアチェンジ、スピードメータといった自動車運転の部品は、自動車の資源、機能、状態へのアクセス、操作、表示を行いやすくする。チェックボックス、カーソル、メニュー、スクローラ、ウインドウ（総称的かつ一般的にウィジェットと呼ばれる）のようなコンピュータとの対話インターフェースのコンポーネントも同様にデータ、コンピュータハードウェア、オペレーティングシステムの資源、機能、状態のアクセス、操作、表示を容易にしてくれる。操作インターフェースは、一般にユーザーインターフェースと呼ばれる。アップルマッキントッシュのオペレーティングシステムアクア、マイクロソフトウインドウズのＸＰまたはユニックスのＸウインドウズのようなグラフィカルユーザーインターフェース（ＧＵＩ）は、ユーザーに情報をグラフィックでアクセス、表示する基準及び手段を与えます。
【０２１７】
ユーザーインターフェースコンポーネント２２１７は、ＣＰＵ回路コンポーネントを作動させるストアドインストラクションコードシグナルで構成されている。ユーザーインターフェースは、アップルマッキントッシュＯＳ例えば、アクア、マイクロソフトウインドウズ（ＮＴ／ＸＰ）、ユニックスＸウインドウズ（ＫＤＥ、Ｇｎｏｍｅなど）、ｍｙｔｈＴＶなどのオペレーティングシステム及び／又はオペレーティング環境で及び／又はそれらといっしょに及び／又はそれらに加えて提供される従来のグラフィックユーザーインターフェースである。このユーザーインターフェースを使用することによってテキスト及び／又はグラフィック機能によりプログラムコンポーネント及び／又はシステムソフトの表示、実行、インターラクション、マニピュレーション、処理を行うことができる。ユーザーインターフェースは、ユーザーがコンピュータシステムを作動し、対話し、操作するための機能を備えている。ユーザーインターフェースは、それ自体及び／又は類似のソフトを含むコンポーネント集合の他のコンポーネントに通信したり、それらと通信し合ったりする。ユーザーインターフェースはオペレーティングシステム、他のプログラムコンポーネントなどと頻繁に通信し合う。ユーザーインターフェースは、プログラムコンポーネント、システム、ユーザー、及び／又はデータ通信、要求、情報及び／又は応答の包含、通信、生成、取得、提供を行う。
【０２１８】
ウェブブラウザー
ウェブブラウザーコンポーネント２２１８は、ＣＰＵ回路コンポーネントを作動させるストアドインストラクションコードシグナルで構成されている。ウェブブラウザーは、アップルサファリ、マイクロソフトインターネットエクスプローラー、モジラファイアフォックス、ネットエスケープナビゲーターなど従来のハイパーテキストビューイングアプリケーションである。安全なウェブブラウザーは、ＨＴＴＰＳ、ＳＳＬなどにより１２８ビット（またはそれ以上）の暗号化といっしょに供給される。いくつかのウェブブラウザーを用いると、ジャバ、ジャバスクリプト、アクティブＸなどのソフトによりプログラムコンポーネントが実行される。ウェブブラウザーと類似の情報アクセスツールをＰＤＡ，携帯電話、その他の移動装置に統合できる。ウェブブラウザーは、それ自体及び／又は類似のソフトを含むコンポーネント集合の他のコンポーネントに通信したり、それらと通信し合ったりする。ウェブブラウザーは、情報サーバー、オペレーティングシステム、統合プログラムコンポーネント（例えば、プラグイン）などと頻繁に通信し合う。例えば、ウェブブラウザーは、プログラムコンポーネント、システム、ユーザー、及び／又はデータ通信、要求、情報及び／又は応答の包含、通信、生成、取得、提供を行う。もちろん、ウェブブラウザーと情報サーバーの代わりに、結合されたアプリケーションを開発して、両方のプログラムが持つ同じ機能を実行しても良い。この結合アプリケーションも同様に、ユーザー、ユーザーエージェント等に対してＩＳＩＣＩ実行ノードから情報の取得及び提供ができるようにする。結合アプリケーションは、標準のウェブブラウザーを用いるシステムでは無意味である。
【０２１９】
メールサーバー
メールサーバーコンポーネント２２２１は、ＣＰＵ回路コンポーネントを作動させるストアドインストラクションコードシグナルで構成されている。メールサーバーは、メール送信（センドメール）、マイクロソフトエクスチェンジなど（これらに限らない）の従来のインターネットメールサーバーである。メールサーバーを用いると、ＡＳＰ、アクティブＸ、（ＡＮＳＩ）（オブジェクト）Ｃ（＋＋）、ＣＧＩスクリプト、ジャバ、ジャバスクリプト、ＰＥＲＬ、パイプス、パイソン、ウェブオブジェクトなどのソフトによりプログラムコンポーネントが実行される。メールサーバーは、インターネットメッセージアクセスプロトコル（ＩＭＡＰ）、マイクロソフトエクスチェンジ、ポストオフィスプロトコール（ＰＯＰ３）、簡易メール転送プロトコル（ＳＭＴＰ）など（これらに限らない）の通信プロトコルをサポートする。メールサーバーは、ＩＳＩＣＩ経由及び／又はＩＳＩＣＩに送信、中継、及び／又はその他の方法により横断した到着及び発信メールの送信、転送、処理を行う。
【０２２０】
ＩＳＩＣＩメールへのアクセスは、個々のウェブサーバーコンポーネント及び／又はオペレーティングシステムが備えるいくつかのＡＰＩを介して達成される。
【０２２１】
また、メールサーバーは、プログラムコンポーネント、システム、ユーザー、及び／又はデータ通信、要求、情報及び／又は応答の包含、通信、生成、取得、提供を行う。
【０２２２】
メールクライアント
メールクライアントコンポーネント２２２２は、ＣＰＵ回路コンポーネントを作動させるストアドインストラクションコードシグナルで構成されている。メールクライアントは、アップルメール、マイクロソフトエクスチェンジ、マイクロソフトアウトルックエクスプレス、モジラサンダーバードなどの従来のメールビューイングアプリケーションである。メールクライアントは、ＩＭＡＰ、マイクロソフトエクスチェンジ、ＰＯＰ３、ＳＭＴＰなどのいくつかの転送プロトコルをサポートする。メールクライアントは、それ自体及び／又は類似のソフトを含めコンポーネント集合の他のコンポーネントに通信したり、それらと通信し合ったりする。メールクライアントは、メールサーバー、オペレーティングシステム、他のメールクライアントなどと頻繁に通信し合う。例えば、メールクライアントは、プログラムコンポーネント、システム、ユーザー、及び／又はデータ通信、要求、情報及び／又は応答の包含、通信、生成、取得、提供を行う。一般に、メールクライアントは、電子メールメッセージを作成し、伝送するソフトを備えている。
【０２２３】
暗号サーバー
暗号サーバーコンポーネント２２２０は、ＣＰＵ回路コンポーネント２２０３、暗号プロセッサ２２２６、暗号プロセッサインターフェース２２２７、暗号プロセッサ装置２２２８などを作動させるストアドインストラクションコードシグナルで構成されている。暗号プロセッサインターフェースは、暗号コンポーネントによる暗号化及び／又は複合化の要求を迅速に行うが、暗号コンポーネントは従来のＣＰＵで実行してもいい。暗号コンポーネントは、与えられたデータの暗号化、複合化を行う。暗号コンポーネントは、対称・非対称両方の（例えば、プリティグッドプライバシー（ＰＧＰ））暗号化、複合化を行う。暗号コンポーネントは、デジタル証明書（例えば、Ｘ．５０９認証構造）、デジタル署名、連記式署名、エンベロッピング、パスワードアクセス保護、公開鍵管理など（但し、これらに限らない）暗号手法を用いる。暗号コンポーネントは、チェックサム、データ暗号化規格（ＤＥＳ）、楕円曲線暗号化（ＥＣＣ）、国際データ暗号アルゴリズム（ＩＤＥＡ）、メッセージダイジェスト５（ＭＤ５、これはハッシュ関数の一つの方法）、パスワード、リベストサイファー（ＲＣ５）、ラインドール、ＲＳＡ（これは１９７７年にロンリベスト，  Ａｄｉ  Ｓｈａｍｉｒ，  Ｌｅｏｎａｒｄ  Ａｄｅｌｍａｎにより開発されたアルゴリズムを用いるインターネット暗号化認証システムである）、Ｓｅｃｕｒｅ  Ｈａｓｈ  Ａｌｇｏｒｉｔｈｍ  （ＳＨＡ）、Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ  （ＳＳＬ）、Ｓｅｃｕｒｅ  Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰＳ）など（但し、これらに限らない）の数多くの（暗号化、複合化用）セキュリティプロトコルを容易に活用する。このような暗号化セキュリティプロトコルを用いて、ＩＳＩＣＩはすべての到着及び／又は発信通信を暗号化し、より広い通信ネットワークといっしょに仮想私的ネットワーク（ＶＰＮ）内のノードとしてサービスする。暗号コンポーネントは、資源へのアクセスをセキュリティプロトコルによって抑制する“セキュリティ認証”のプロセスを容易に行い、暗号コンポーネントは保護された資源への認証アクセスを行う。更に、暗号コンポーネントは、コンテンツの唯一識別子、例えば、デジタルオーディオファイルに対する唯一な署名を取得するためのＭＤ５ハッシュを使用する。暗号コンポーネントは、それ自体及び／又は類似のソフトを含め、コンポーネント集合の他のコンポーネントに通信したり、それらと通信し合ったりする。暗号コンポーネントは、通信ネットワークを通じて情報の安全な伝送を行う暗号化方式を支持し、必要であれば、ＩＳＩＣＩコンポーネントが安全なトランザクションに従事できるようにする。暗号コンポーネントは、ＩＳＩＣＩ上の資源への安全なアクセスを容易に実施し、また、遠隔システムの保護された資源へのアクセスを行う。つまり、保護された資源のクライアント及び／又はサーバーの働きをする。暗号コンポーネントは、情報サーバー、オペレーティングシステム、その他のプログラムコンポーネントなどと頻繁に通信する。暗号コンポーネントは、プログラムコンポーネント、システム、ユーザー、及び／又はデータ通信、要求、情報及び／又は応答の���含、通信、生成、取得、提供を行う。
【０２２４】
ＩＳＩＣＩデータベース
ＩＳＩＣＩデータベースコンポーネント２２１９は、データベース及びそのストアドデータの形に具体化される。データベースは、ＣＰＵ回路コンポーネントを作動させるストアドインストラクションコードシグナルで構成されている。つまり、ストアドデータを処理するようＣＰＵを構成するストアドインストラクションコードの部分である。データベースは、オラクルやＳｙｂａｓｅのような、通常の、フォールトトレラントな、リレーショナルな、拡張可能な安全なデータベースである。リレーショナルデータベースは、フラットファイルの延長である。リレーショナルデータベースは、一連の関連する表で構成される。表は、キーフィールドによって相互に接続されている。キーフィールドの使用によって、キーフィールドによる索引付けで表を組み合わせることができる。つまり、キーフィールドが様々な表からの情報を組み合わせる次元的回転軸の働きをする。関係は、一般に主キーをマッチさせて表間で維持されるリンクを識別する。主キーは、リレーショナルデータベース内の表の列を唯一無二に識別するフィールドを表す。更に正確に言うと、これらのキーは、１対多の関係の“ひとつの”側面上の表の列を表している。
【０２２５】
あるいは、配列、ハッシュ、（連結）リスト、ｓｔｒｕｃｔ、構造化テキストファイル（例えば、ＸＭＬ）、表などの様々な標準のデータ構造を用いてＩＳＩＣＩデータベースを構築する。このようなデータ構造をメモリ及び／又はファイルに記憶する。別の代替案としては、Ｆｒｏｎｔｉｅｒ、ＯｂｊｅｃｔＳｔｏｒｅ、Ｐｏｅｔ、Ｚｏｐｅなどのオブジェクト指向のデータベースを使用してもいい。オブジェクトデータベースには、共通の属性でいっしょにグループ化及び／又はリンクされたいくつかのオブジェクト集合体が含まれ、それらはいくつかの共通属性により別のオブジェクト集合体と関連付けられる。オブジェクト指向データベースは、オブジェクトが単にデータと言うだけでなく、あるオブジェクト内にカプセル化された別のタイプの機能を有すると言う点を除けば、リレーショナルデータベースと同じように実行される。ＩＳＩＣＩデータベースをあるデータ構造として実施しても、ＩＳＩＣＩデータベース２２１９の使用はＩＳＩＣＩコンポーネント２２３５のような別のコンポーネントに統合される。また、データベースをデータ構造、オブジェクト、リレーショナル構造の混合体として実施してもいい。データベースは、標準のデータ処理技法を使って無数の形態に統合され、配布される。データベースの部分、例えば、表を、エクスポート及び／又はインポートして、分散化したり統合したりする。
【０２２６】
ある実施例では、データベースコンポーネント２２１９には、記述されるデータベースの枠組み、表、構造、キー、エンティティ、関係を表すいくつかの表２２１９ａ−Ｉが含まれる。ＵＮＩ（例えば、ハンドル、ＤＯＩ，及び／又はその他のＵＮＩ）表２２１９には、ＤＯＩ，作成者名、作成者連絡情報、登記所、など（但し、これらに限らない）のフィールドが含まれる。ＵＲＬ表２２１９ｂには、ＤＯＩ，多重解決識別子、ＵＲＬなど（但し、これらに限らない）のフィールドが含まれる。メタデータ表２２１９ｃには、ＤＯＩ，多重解決識別子、ＵＲＬ、マルチリンクメニュー仕様、カスタムフィールド１、カスタムフィールド２など（但し、これらに限らない）のフィールドが含まれる。多重解決表２２１９ｄには、ＤＯＩ，メタデータなど（但し、これらに限らない）のフィールドが含まれる。ＲＦＩＤ表２２１９ｅには、ＲＦＩＤ番号、ＤＯＩ，多重解決識別子、ＧＰＳ座標、取引番号など（但し、これらに限らない）のフィールドが含まれる。メニュー仕様テ−ブル２２１９ｆには、ＤＯＩ、メタデータ、多重解決識別子、ビュー可能アイテム、マルチリンク仕様、メニューラベルなど（但し、これらに限らない）のフィールドが含まれる。私的な（ＤＯＩ情報の）表２２１９ｇには、ＤＯＩ、多重解決識別子、電話番号、ＩＰ  ＩＤを通じてのボイス（例えば、ＩＤユーザー名とパスワードインスタントメッセンジャＩＤ（例えば、ＩＤユーザー名とパスワード）、電子メール、メタデータなど（但し、これらに限らない）のフィールドが含まれる。アクセスコントロール表２２１９ｈには、ＤＯＩ、メタデータ、多重解決識別子、所有者、ユーザー、コントロール設定など（但し、これらに限らない）のフィールドが含まれる。リンク間インデックス表２２１９ｉには、ＤＯＩ、メタデータ、多重解決識別子、スポンサードリンク状況、相互リンク数、ミッシングリンク数、未知リンク数、人気ランキングなど（但し、これらに限らない）のフィールドが含まれる。トラッカ表２２１９ｉには、ＩＰアドレス、ＤＯＩ、多重解決識別子、メニューアイテム選択回数、メニューアイテム考慮回数、メニューアイテム未考慮回数など（但し、これらに限らない）のフィールドが含まれる。すべての表は、（機能強化された）ＤＯＩキーフィールドアイテムの唯一さに応じて関連付けられる。
【０２２７】
ある実施例では、ユーザープログラムにはＩＳＩＣＩ更新に役立つ様々なユーザーインターフェースプリミティブが含まれる。また、ＩＳＩＣＩがサービスしなければならない環境及びクライアントのタイプによって、種々のアカウントにカスタムデータベース表が要求される。データベース全体に亘って、いかなるフィールドもキーフィールドとして指定できる。別の実施例では、これらの表は、自分自身のデータベース及びそれぞれのデータベース管理者に分散化されている（つまり、上述の表のそれぞれに対して個々のデータベース管理者がいる）。更に、標準のデータ処理技法を用いて、データベースをいくつかのコンピュータシステム及び／又は記憶装置に配布する。同様に、分散化したデータベース管理者の構成を様々なデータベースコンポーネント２２１９ａ−ｉを統合及び／又は分散することにより多様化する。ＩＳＩＣＩは、様々なセッティング、入力、パラメータをデータベース管理者を介して追跡するように構成してもよい。
【０２２８】
ＩＳＩＣＩデータベースは、それ自体及び／又は類似のソフトを含むコンポーネント集合の他のコンポーネントに通信したり、それらと通信し合ったりする。ＩＳＩＣＩデータベースは、ＩＳＩＣＩコンポーネント、他のプログラムコンポーネントなどと頻繁に通信し合う。このデータベースは、他のノード及びデータに関する情報を包含、保持、提供する。
【０２２９】
情報アクセス多重解決サーバー（ＩＡＭＲＳ）
ＩＡＭＲＳコンポーネント２２２５は、ＣＰＵ回路コンポーネントを作動させるストアドインストラクションコードシグナルで構成されている。一般に、ＩＳＩＣＩは、通信ネットワーク上のノード間で情報のアクセス、入手、提供などを行う。ＩＡＭＲＳは、ＵＮＩを解析して複数のインスタンスにインスタンス化する機能を有する。一般には、ＩＡＭＲＳはある与えられた情報、そのＤＯＩ、及び現行の場所間でのアソシエーションを作成、維持、更新する検索プログラムの役割を果たす。ＩＡＭＲＳは、ＩＳＩＣＩデータベースと連携して、要求された情報のためにデータ転送を向上させ、要求する情報を種々のフォーマットに解析し、その情報に関するクエリを作成するための拡張機構を提供するのに役立つノードを識別する。ＩＡＭＲＳで実行されるノード間での情報アクセスは、Ｃ＋＋、シェルスクリプト、ジャバ、ジャバスクリプト、ＳＱＬコマンド、Ｗｅｂアプリケーションサーバー拡張機能、アパッチモジュール、ＰＥＲＬスクリプト、バイナリ・エグゼキュータブル、その他のマッピング・ツールなど（但し、これらに限らない）の標準的な開発ツールを利用して開発する。制約のない例の実施例では、ＩＡＭＲＳサーバーは、暗号サーバーを使用して、通信を暗号化し、復号化する。ＩＡＭＲＳは要求にサービスしたり、ＵＮＩ用にアソシエーション情報を更新したり、更に多くのことを行う。ＩＳＩＣＩモジュールは、それ自体及び／又は類似のプログラムを含めモジュール集合の中の他のモジュールに通信したり、それらと互いに通信し合ったりする。ＩＡＭＲＳモジュールは、ＩＳＩＣＩデータベース、オペレーティング・システム、他のプログラムモジュールなどと頻繁に通信し合います。ＩＡＭＲＳはプログラムモジュール、システム、ユーザー、データ通信、要求、応答などの包含、通信、生成、取得、提供を行う。
【０２３０】
ＩＳＩＣＩ
ＩＳＩＣＩコンポーネント２２３５は、種々のＣＰＵ回路コンポーネントを作動させるストアドインストラクションコードシグナルで構成されている。かかるものとして、ＩＳＩＣＩは、様々な通信ネットワーク上で、情報、サービス、トランザクションなどのアクセス、取得、提供を行う。
【０２３１】
ある実施例では、ＩＳＩＣＩコンポーネントはマルチリンク・メニューの要求側クライエントへの提供を促進する。ＩＳＩＣＩは、ある特定の要求側エンティティの場合マルチリンク・メニューがどのような外観をもつかを詳述するマルチリンク・メニュー仕様にアクセスする。当開示では、複数のＩＳＩＣＩがそれぞれ要求側によってまたＩＳＩＣＩのニーヅによって任意のマルチリンクについて複数のビューを提供することを述べている。ある実施例では、ＩＳＩＣＩはマルチリンクの広告ビュー（これは広告を誰に対して出そうとしているかによって変わる）を備えている。また、別の実施例では、ＩＳＩＣＩはコンテンツ・プロバイダーから分離しており、コンテンツ・プロバイダーのウェブ・ページとは別のマルチリンク・メニューを要求する。また、別の実施例では、ＩＳＩＣＩはコンテンツ・プロバイダーのシステムの中に統合される。更に別の実施例では、ＩＳＩＣＩは組織内のコンテンツへのアクセス及びレファレンスを制限するイントラコネクト（接続内）機能を備える。ＩＳＩＣＩはまた、マルチリンクＤＯＩレコード及びメニュー仕様の変形を行うマルチリンク・エディターに指示する。
【０２３２】
ＩＳＩＣＩが実行するノード間の情報のアクセスは、次のような標準の開発ツール（これらに限られる訳ではない）を用いて開発される。つまり、（ＡＮＳＩ）（Ｏｂｊｅｃｔｉｖｅ）  Ｃ  （＋＋）  、アパッチコンポーネント、バイナリー・エクゼキュ−タブルズ、データベース・アダプター、ジャバ、ジャバスクリプト、マッピング・ツール、手続き及びオブジェクト指向開発ツール、ＰＥＲＬ、パイソン、シェルスクリプト、ＳＱＬ  コマンド、Ｗｅｂアプリケーション・サーバー拡張機構、ＷｅｂＯｂｊｅｃｔｓ、等々である。ある実施例では、ＩＳＩＣＩは暗号サーバーを用いて、通信の暗号化、復号化を行う。ＩＳＩＣＩは、それ自体及び／又は類似のプログラムを含めコンポーネント集合内の他のコンポーネントに通信したり、それらと通信し合ったりする。ＩＳＩＣＩコンポーネントは、ＩＳＩＣＩデータベース、オペレーティング・システム、その他のプログラムコンポーネントなどと頻繁に通信し合う。ＩＳＩＣＩは、プログラムコンポーネント、システム、ユーザー、データ通信、要求、情報、応答などの包含、通信、生成、取得、提供を行う。
【０２３３】
分散ＩＳＩＣＩ
どのＩＳＩＣＩノード管理者コンポーネントの構成及び操作を何通りにも組み合わせ、統合し、配布して、開発、配置を行ってもかまわない。同様に、コンポーネント集合も何通りにも組み合わせて、開発、配置使用してもかまわない。これを達成するためには、コンポーネント群を要求に応じて統合された方法でダイナミックにロードできる共通のコード・ベースあるいはプログラムにまとめてもかまわない。
【０２３４】
コンポーネント集合は、標準のデータ処理技法及び開発技法により無数の形にまとめられ、配布される。プログラムコンポーネント集合体のどのプログラムコンポーネントの複数インスタンスでも一つのノード上あるいはいくつかのノードに亘ってインスタンス化して、ロード・バランス技法及び／又はデータ処理技法によりパフォーマンスの向上を図る。更に、単一のインスタンスを複数のコントローラ及び／又は記憶装置、例えば、データベースに亘って分散させてもかまわない。標準のデータ処理通信技法を用いることにより、連携して作動するすべてのプログラムコンポーネントのインスタンス及びコントローラがそのように作動する。
【０２３５】
ＩＳＩＣＩのコントローラ（管理プログラム）の構成は、システム展開の状況によって変わってきます。基本となるハードウェア資源の予算、容量、場所、使い方（これらに限らない）などの要因によって、展開の要件及び構成が変わってくる。結果的に構成がより整理、統合されたプログラムコンポーネントになるか、より分散されたプログラムコンポーネントの繋がりになるか、あるいは統合と分散の中間の組み合わせになるかに関係なく、データの通信、取得、提供が行われる。プログラムコンポーネント集合から共通のコード・ベースに統合されるコンポーネントのインスタンスがデータの通信、取得、提供を行う。このことは、データレファレンス（例えば、ポインター）、内部メッセージング、オブジェクトインスタンス可変通信、共用メモリースペース、変数渡しなど（但し、これらに限らない）のアプリケーション内データ処理通信技法により成就される。
【０２３６】
コンポーネント集合体のコンポーネントが互いに不連続で、分離した、外的なものであれば、他のコンポーネント部分との及び／又はそれらへのデータの通信、取得、提供は、アプリケーションプログラムインターフェース（ＡＰＩ）による情報渡し、（分散）コンポーネントオブジェクトモデル（（Ｄ）ＣＯＭ）、（分散）オブジェクトのリンクと埋め合わせ（（Ｄ）ＯＬＥ）、共通オブジェクト要求ブローカアーキテクチャ（ＣＯＲＢＡ）、ｐｒｏｃｅｓｓ  ｐｉｐｅ、共有ファイル、など（但し、これらに限らない）のアプリケーション間データ処理通信技法により成就される。アプリケーション間の通信のために不連続のコンポーネント部分間でのメッセージ送信、あるいはアプリケーション内での通信のために一つのコンポーネントのメモリー・スペース内でのメッセージ送信は文法の作成と分析によって容易に行われる。文法の開発は、ｌｅｘ、ｙａｃｃ、ＸＭＬ  などの標準的な開発ツールを使用して行われるが、これらのツールにより文法の生成と分析の機能を行い、次にこれがコンポーネント内及びコンポーネント間での通信メッセージの基礎をなす。繰り返して言うと、構成はシステム展開の状況次第で変わってくる。
【０２３７】
当開示の全体（表紙、発明の名称、見出し、本文、背景、要約、図面の簡単な記述、詳述、請求項、要約書、図、その他）が、請求項にある発明を実践する様々な実施例を解説している。発明の実施例の記述に際して、ある場合には、明晰さの目的で特定の専門用語が使用されているが、本発明はそのように選択した特定の用語に限られたり、それによって拘束されることを意図しておらず、各特定の用語が同じ目的を達成するために同じように動作するすべての技術上の事項を包含することを理解されたい。
【０２３８】
当開示での用語及び／又は言い回しがつぶさに完璧ではなく、厳格な定義として用いられていないことに注目されたい。むしろ、ここで用語は単に読者への補助として使われている。用語は当開示及び／又はその中の請求事項を限定するものでない。用語の使用に当っては、一般の使用、辞書、技術辞書、及び／又は工芸における実際の使用に見られるより広い、または多義の意味を熟考し、更に当開示全体に亘って意味の拡大を図っている。また、当開示の有利点及び特長は実施例の代表的事例のみを掲げており、包括的でも排他的でもない。これらは請求項の原理を理解・教示する上で助けとなる目的で記述説明しているだけである。それらが請求項にあるすべての発明を代表するものではないことを理解いただきたい。このような意味合いで、本開示のある側面は当明細の中で論じていない。当発明のある個所に対して代替の実施例を述べなかったこと、あるいは更に記述されていない代替実施例がある部分に対して述べられるかどうかはこれらの代替実施例のディスクレーマーと考えられるべきではない。これら未記述の実施例の多くが当発明の同じ原理原則を包含しており、その他のことも同様であることが理解されるであろう。従って、当開示の範囲・精神から逸脱することなく、他の実施例を利用したり、機能上、論理上、組立て、構成上、位相幾何学上の修正を行うことは理解されたい。このような意味合いで、全ての例及び／又は実施例は当開示を通じて全く制限しないものとみなされる。また、当開示の中で議論されている実施例に関して、紙面及び反復削除の目的から記述してない場合を除いて、議論してない実施例に関連して推論すべきではない。例えば、任意のプログラムコンポーネント（コンポーネント集合）の任意の組み合わせの論理的・位相幾何学的構造、図中で及び／又は開示を通して記述されているその他のコンポーネント及び／又は含まれている特徴群は、固定された動作順序及び／又は配列に限られるものではなく、むしろ、開示されている順序は例示的なものであり、同様なこともすべて順序とは無関係に、当開示で熟考されていることを理解されたい。更に、このような特徴（機能）はシリアルな実行に限られず、非同期に、同期に、平行に、同時に、同期的に実行される任意の数のスレッド（単位プログラム）、プロセス、サービス、サーバーなどが当開示で熟考されていることを理解されたい。このような意味で、これらのフィーチャのいくつかは同時に一つの実施例で存在できないと言う点で、互いに相反している。同様に、いくつかのフィーチャは当発明のある側面には適用可能だが、他の側面には適用不可である。更に、当発明には請求項に含まれていない他の発明が含まれている。特許出願人はここで請求されていないこれらの発明に対する全ての権利（かかる発明を請求し、追加の出願、継続、部分的な継続、その一部等を申請する権利を含む）を保留するものとする。この意味で、有利点、実施例、事例、特徴、機能的・論理的・組織的・構造的・位相的・その他の側面といった当開示のいくつかの側面が、請求項で定義されているように当開示に対する制限、あるいは請求項に相当することに対する制限と考えるべきでないことを理解されたい。
【図面の簡単な説明】
【０２３９】
【図１】広告、電子商取引及びオンラインクライアントインターラクションの統合、情報処理及び自己改善（ＩＳＩＣＩ）ファシリティの実施例を示す混合データと論理フロー図である。
【図１Ａ】広告、電子商取引及びオンラインクライアントインターラクションの統合、情報処理及び自己改善（ＩＳＩＣＩ）ファシリティの実施例を示す混合データと論理フロー図である。
【図２Ａ】オートリンカーの実施例を示す混合データ及び論理フロー図である。
【図２Ｂ】オートリンカーの実施例を示す混合データ及び論理フロー図である。
【図２Ｃ】オートリンカーの実施例を示す混合データ及び論理フロー図である。
【図３】イントラコネクタの実施例を示す混合データ及び論理フロー図である。
【図４】マルチリンクシンジケーションの実施例を示す論理フロー図である。
【図５Ａ】マルチリンクメニューエディタ及びパーソナルＤＯＩの実施例を示す図である。
【図５Ｂ】マルチリンクメニューエディタ及びパーソナルＤＯＩの実施例を示す図である。
【図６Ａ】マルチリンクメニューエディタ及びパーソナルＤＯＩの実施例を示す図である。
【図６Ｂ】マルチリンクメニューエディタ及びパーソナルＤＯＩの実施例を示す図である。
【図７】ＩＰアドレッシング機構を示す。
【図８】デジタル・オブジェクト識別子（ＤＯＩ）を通じた情報のアクセスを示す。
【図９】ハンドルと強化ＤＯＩグラマーの概略図である。
【図１０Ａ】ユーザーに所望の情報にアクセス可能にする解決機構の概観図である。
【図１０Ｂ】ユーザーに所望の情報にアクセス可能にする解決機構の概観図である。
【図１０Ｃ】ユーザーに所望の情報にアクセス可能にする解決機構の概観図である。
【図１０Ｄ】ユーザーに所望の情報にアクセス可能にする解決機構の概観図である。
【図１０Ｅ】ユーザーに所望の情報にアクセス可能にする解決機構の概観図である。
【図１０Ｆ】ユーザーに所望の情報にアクセス可能にする解決機構の概観図である。
【図１０Ｇ】ユーザーに所望の情報にアクセス可能にする解決機構の概観図である。
【図１１】ユーザーが情報にアクセスすることを実行する動作シーケンス図である。
【図１２】ＵＲＬを取得するためにＤＯＩを解決することによって通信ネットワークを通じて情報にアクセスする例示的な機構の幾つかの図である。
【図１３】例示的なＤＯＩシステムの図である。
【図１４Ａ】広告シンジケーターによって提供される広告の例を示す。
【図１４Ｂ】広告シンジケーターによって提供される広告の例を示す。
【図１４Ｃ】広告シンジケーターによって提供される広告の例を示す。
【図１５Ａ】例示的なマルチリンク用途を示す。
【図１５Ｂ】例示的なマルチリンク用途を示す。
【図１５Ｃ】例示的なマルチリンク用途を示す。
【図１５Ｄ】例示的なマルチリンク用途を示す。
【図１５Ｅ】例示的なマルチリンク用途を示す。
【図１６Ａ】例示的なマルチリンク用途とユーザーインターフェースを示す。
【図１６Ｂ】例示的なマルチリンク用途とユーザーインターフェースを示す。
【図１６Ｃ】例示的なマルチリンク用途とユーザーインターフェースを示す。
【図１６Ｄ】例示的なマルチリンク用途とユーザーインターフェースを示す。
【図１７Ａ】マルチリンクエコシステムの実施例を示す混合データフロー図である。
【図１７Ｂ】マルチリンクエコシステムの実施例を示す混合データフロー図である。
【図１８】マルチリンクメニューエディタの図式的な実施例を示す。
【図１９】マルチメニュー追跡部の実施例を示す論理フロー図である。
【図２０】マルチリンク追跡ユーザーインターフェースと追跡ログを示す。
【図２１】購入サイクルを示す
【図２２】広告、電子商取引及びオンラインクライアントインターラクション制御部のための統合、情報処理及び自己改善ファシリティのブロック図である。
【図６Ｂ】
2012146319.tif 000003
【図１０Ａ】
2012146319.tif 000004
【図１０Ｂ】
2012146319.tif 000005
【図１０Ｃ】
2012146319.tif 000006
【図１０Ｅ】
2012146319.tif 000007
【図１０Ｇ】
2012146319.tif 000008
【図１１】
2012146319.tif 000009
【図１５Ｂ】
2012146319.tif 000010
【図１６Ａ】
2012146319.tif 000011
【図１６Ｄ】
2012146319.tif 000012
【図１９】
2012146319.tif 000013
【図２０】
2012146319.tif 000014
【図１】
2012146319.tif 000015
【図１Ａ】
2012146319.tif 000016
【図２Ａ】
2012146319.tif 000017
【図２Ｂ】
2012146319.tif 000018
【図２Ｃ】
2012146319.tif 000019
【図３】
2012146319.tif 000020
【図４】
2012146319.tif 000021
【図５Ａ】
2012146319.tif 000022
【図５Ｂ】
2012146319.tif 000023
【図６Ａ】
2012146319.tif 000024
【図７】
2012146319.tif 000025
【図８】
2012146319.tif 000026
【図９】
2012146319.tif 000027
【図１０Ｄ】
2012146319.tif 000028
【図１０Ｆ】
2012146319.tif 000029
【図１２】
2012146319.tif 000030
【図１３】
2012146319.tif 000031
【図１４Ａ】
2012146319.tif 000032
【図１４Ｂ】
2012146319.tif 000033
【図１４Ｃ】
2012146319.tif 000034
【図１５Ａ】
2012146319.tif 000035
【図１５Ｃ】
2012146319.tif 000036
【図１５Ｄ】
2012146319.tif 000037
【図１５Ｅ】
2012146319.tif 000038
【図１６Ｂ】
2012146319.tif 000039
【図１６Ｃ】
2012146319.tif 000040
【図１７Ａ】
2012146319.tif 000041
【図１７Ｂ】
2012146319.tif 000042
【図１８】
2012146319.tif 000043
【図２１】
2012146319.tif 000044
【図２２】
2012146319.tif 000045
【手続補正書】
【提出日】平成24年4月5日(2012.4.5)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
プロセッサが実行する方法において、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットに関係するコンテンツアイテムへの多重レファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子記録の階層構造に基づいてメニュー仕様を生成することを特徴とする方法。
【請求項２】
プロセッサが実行する方法において、
メタデータフィールドとバリューを取得し、
ユニークパーシステント統一名称識別子メニュー仕様を存在すれば取得し、
入手不能であれば、前記メタデータフィールド及びバリューからユニークパーシステント統一名称識別子メニュー仕様を生成し、
メタデータフィールドを前記メニュー仕様におけるフィールドに照合し、
照合されたフィールド及びフィールドバリューに基づいて前記メタデータを検索し、
前記照合されたフィールド及びフィールドバリューに基づいてターゲットレファレンスを形成し、
ユニークパーシステント統一名称識別子ディレクトリにおけるユニークパーシステント統一名称識別子記録に前記ターゲットレファレンスを格納することを特徴とする方法。
【請求項３】
プロセッサが実行する方法において、
ユニークパーシステント統一名称識別子とユニークパーシステント統一名称識別子メニューとの間の関係を確立し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
前記ターゲットレファレンスを形成し、ここで、前記ターゲットレファレンスはユニークパーシステント統一名称識別子ディレクトリにおけるユニークパーシステント統一名称識別子記録に格納され、
前記ターゲットコンテンツアセットと前記ターゲットレファレンスへのリンクを有するユニークパーシステント統一名称識別子メニューを作成することを特徴とする方法。
【請求項４】
プロセッサが実行する方法において、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子記録情報を表示し、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを追加し、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを削除し、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを変更し、
ユニークパーシステント統一名称識別子ディレクトリに、更新されたユニークパーシステント統一名称識別子記録情報を格納することを特徴とする方法。
【請求項５】
プロセッサが実行する方法において、
ユニークパーシステント統一名称識別子のためのメニュー仕様の要求を受信し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
前記メニュー仕様をデータベースで検索し、
前記データベースにおいて見つからなければ、ユニークパーシステント統一名称識別子ディレクトリにおいてメタデータからの前記ユニークパーシステント統一名称識別子に対してメニュー仕様を生成し、
前記メニュー仕様をもし生成された場合には前記データベースに格納し、
前記ユニークパーシステント統一名称識別子メニュー仕様からユニークパーシステント統一名称識別子メニューを生成し、ここで、前記ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用され、
要求に応答して前記ユニークパーシステント統一名称識別子メニューを要求クライアントに提供することを特徴とする方法。
【請求項６】
プロセッサが実行する方法であって、
ユニークパーシステント統一名称識別子のために通信ネットワークをクロールしてユニークパーシステント統一名称識別子のインデックスを生成し、ここで、前記要求はコンテンツのアクセスと当該コンテンツに埋め込まれたコードから誘起され、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
比較に基づいてターゲットユニークパーシステント統一名称識別子を取得し、
ウェブサイトをインデックスクロールしながらターゲットユニークパーシステント統一名称識別子を発見されたユニークパーシステント統一名称識別子と比較し、
ユニークパーシステント統一名称識別子と発見されたユニークパーシステント統一名称識別子との間の照合数と非照合数に着目することによってターゲットユニークパーシステント統一名称識別子のインターリンク度を決定し、
決定されたインターリンク度情報と共にユニークパーシステント統一名称識別子データベースにおいてユニークパーシステント統一名称識別子インデックスを更新することを特徴とする方法。
【請求項７】
比較に基づいてターゲットユニークパーシステント統一名称識別子を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、
ウェブサイトをインデックスクロールしながらターゲットユニークパーシステント統一名称識別子を発見されたユニークパーシステント統一名称識別子と比較し、
ユニークパーシステント統一名称識別子と発見されたユニークパーシステント統一名称識別子との間の照合数と非照合数に着目することによってターゲットユニークパーシステント統一名称識別子のインターリンク度を決定することを特徴とする方法。
【請求項８】
内部関連データ種類を有するデータ構造を埋め込む信号状態を有するプロセッサがアクセス可能な媒体であって、
ユニークパーシステント統一名称識別子と、
ターゲットコンテンツアセットへのレファレンスと、
前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの多重レファレンスと、
メニュー仕様の一部であることを示すデータ種類毎のフィールドバリューと、を有し、正の表示は前記メニュー仕様の一部として使用されるデータ種類をもたらし、負の表示はデータ種類の無視をもたらすことを特徴とする媒体。
【請求項９】
内部関連データ種類を有するデータ構造を埋め込む信号状態を有するプロセッサがアクセス可能な媒体であって、
ユニークパーシステント統一名称識別子と、
ターゲットコンテンツアセットへのレファレンスと、
前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの多重レファレンスと、
アクセス権を特定するデータ種類毎にアクセス制御フィールドバリューと、を有することを特徴とする媒体。
【請求項１０】
内部関連データ種類を有するデータ構造を埋め込む信号状態を有するプロセッサがアクセス可能な媒体であって、
ユニークパーシステント統一名称識別子からのバリュー及びメタデータフィールドからの第１レベル階層バリュー、ここで、階層にある前記第１レベル階層バリューはユニークパーシステント統一名称識別子メニューのルートレベル構造を有し、
入手可能であれば、前記ユニークパーシステント統一名称識別子からのメタデータフィールド及びバリューからの後発ネストレベル階層バリューと、ここで、各後発ネストレベルは前記階層においてより高いレベルに関連し、
ターゲットコンテンツアセットに関連するコンテンツアイテムへのレファレンスと、を有し、コンテンツアイテムへのレファレンスは前記階層における端末レベルである各ネストレベル階層バリューに関連付けられていることを特徴とするプロセッサがアクセス可能な媒体。
【請求項１１】
メモリにおけるインターラクションインターフェースにおいて、
命令信号と、ここで、前記インターラクションインターフェースはユーザーとシステムイベント信号に応答し、前記命令信号は実施するのにプロセッサが発行可能で、
メタデータフィールドからのバリューとユニークパーシステント統一名称識別子からのバリューからの第１レベル階層メニューと、ここで、使用される前記フィールド及びバリューはメニュー仕様によって特定され、
入手可能であれば、メタデータフィールドからのバリューとユニークパーシステント統一名称識別子からのバリューからの後発ネストレベル階層メニューと、ここで、使用される前記フィールド及びバリューはメニュー仕様によって特定され、各後発ネストレベルメニューはその関連するより高いレベルのメニューから生まれ、
ターゲットコンテンツアセットに関連するコンテンツアイテムへのレファレンスと、ここで、コンテンツアイテムへのレファレンスは前記階層における端末レベルである各ネストレベル階層バリューに関連付けられ、非末端メニューは産まれた関連ネストメニューへのユーザー選択に応答し、末端メニューは前記レファレンスをナビゲートする命令信号を生成するためにユーザー選択に応答することを特徴とする媒体。
【請求項１２】
仕様生成のシステムにおいて、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得する手段と、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子記録の階層構造に基づいてメニュー仕様を生成する手段と、
を有することを特徴とするシステム。
【請求項１３】
レファレンスのシステムにおいて、
メタデータフィールドとバリューを取得する手段と、
ユニークパーシステント統一名称識別子メニュー仕様をもし存在すれば取得する手段と、
入手不能であれば、前記メタデータフィールド及びバリューからユニークパーシステント統一名称識別子メニュー仕様を生成する手段と、
メタデータフィールドを前記メニュー仕様におけるフィールドに照合する手段と、
前記照合されたフィールド及びフィールドバリューに基づいて前記メタデータを検索する手段と、
前記照合したフィールド及びフィールドバリューに基づいてターゲットレファレンスを形成する手段と、
ユニークパーシステント統一名称識別子ディレクトリにおけるユニークパーシステント統一名称識別子記録に前記ターゲットレファレンスを格納する手段と、
を有することを特徴とするシステム。
【請求項１４】
レファレンスのシステムにおいて、
ユニークパーシステント統一名称識別子とユニークパーシステント統一名称識別子メニューとの間の関係を確立する手段と、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
前記ターゲットレファレンスを形成する手段と、ここで、ターゲットレファレンスはユニークパーシステント統一名称識別子ディレクトリにおけるユニークパーシステント統一名称識別子記録に格納され、
前記ターゲットコンテンツアセットと前記ターゲットレファレンスへのリンクを有するユニークパーシステント統一名称識別子メニューを作成する手段とを有することを特徴とするシステム。
【請求項１５】
レファレンス編集のシステムにおいて、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得する手段と、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子記録情報を表示する手段と、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを追加する手段と、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを削除する手段と、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを変更する手段と、
ユニークパーシステント統一名称識別子ディレクトリに更新されたユニークパーシステント統一名称識別子記録情報を格納する手段と、
を有することを特徴とするシステム。
【請求項１６】
レファレンス分配のシステムにおいて、
ユニークパーシステント統一名称識別子のためのメニュー仕様の要求を受信する手段と、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
前記メニュー仕様をデータベースで検索する手段と、
前記データベースにおいて見つからなければ、ユニークパーシステント統一名称識別子ディレクトリにおいてメタデータからの前記ユニークパーシステント統一名称識別子に対してメニュー仕様を生成する手段と、
前記メニュー仕様をもし生成された場合には前記データベースに格納する手段と、
前記ユニークパーシステント統一名称識別子メニュー仕様からユニークパーシステント統一名称識別子メニューを生成する手段と、ここで、前記ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用され、
要求に応答して前記ユニークパーシステント統一名称識別子メニューを要求クライアントに提供する手段と、
を有することを特徴とするシステム。
【請求項１７】
インターリンク決定のシステムにおいて、
比較に基づいてターゲットユニークパーシステント統一名称識別子を取得する手段と、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、
ウェブサイトをインデックスクロールしながらターゲットユニークパーシステント統一名称識別子を発見されたユニークパーシステント統一名称識別子と比較する手段と、
ユニークパーシステント統一名称識別子と発見されたユニークパーシステント統一名称識別子との間の照合数と非照合数に着目することによってターゲットユニークパーシステント統一名称識別子のインターリンク度を決定する手段と、
を有することを特徴とするシステム。
【請求項１８】
仕様生成のためにプロセッサが可読な媒体において、
前記プロセッサ可読媒体の命令信号を有し、ここで、前記命令信号は前記プロセッサによって発行可能であり、
前記プロセッサは、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットに関係するコンテンツアイテムへの多重レファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子記録の階層構造に基づいてメニュー仕様を生成することを特徴とする媒体。
【請求項１９】
レファレンスのためにプロセッサが可読な媒体において、
前記プロセッサ可読媒体の命令信号を有し、ここで、前記命令信号は前記プロセッサによって発行可能であり、
前記プロセッサは、
メタデータフィールドとバリューを取得し、
ユニークパーシステント統一名称識別子メニュー仕様をもし存在すれば取得し、
入手不能であれば、前記メタデータフィールド及びバリューからユニークパーシステント統一名称識別子メニュー仕様を生成し、
メタデータフィールドを前記メニュー仕様におけるフィールドに照合し、
照合されたフィールド及びフィールドバリューに基づいて前記メタデータを検索し、
前記照合されたフィールド及びフィールドバリューに基づいてターゲットレファレンスを形成し、
ユニークパーシステント統一名称識別子ディレクトリにおけるユニークパーシステント統一名称識別子記録に前記ターゲットレファレンスを格納することを特徴とする媒体。
【請求項２０】
レファレンスのためにプロセッサが可読な媒体において、
前記プロセッサ可読媒体の命令信号を有し、ここで、前記命令信号は前記プロセッサによって発行可能であり、
前記プロセッサは、
ユニークパーシステント統一名称識別子とユニークパーシステント統一名称識別子メニューとの間の関係を確立し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
前記ターゲットレファレンスを形成し、ここで、ターゲットレファレンスはユニークパーシステント統一名称識別子ディレクトリにおけるユニークパーシステント統一名称識別子記録に格納され、
前記ターゲットコンテンツアセットと前記ターゲットレファレンスへのリンクを有するユニークパーシステント統一名称識別子メニューを作成することを特徴とする媒体。
【請求項２１】
レファレンス編集のためにプロセッサが可読な媒体において、
前記プロセッサ可読媒体の命令信号を有し、ここで、前記命令信号は前記プロセッサによって発行可能であり、
前記プロセッサは、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子記録情報を表示し、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを追加し、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを削除し、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを変更し、
ユニークパーシステント統一名称識別子ディレクトリに更新されたユニークパーシステント統一名称識別子記録情報を格納することを特徴とする媒体。
【請求項２２】
レファレンス分配のためにプロセッサが可読な媒体において、
前記プロセッサ可読媒体の命令信号を有し、ここで、前記命令信号は前記プロセッサによって発行可能であり、
前記プロセッサは、
ユニークパーシステント統一名称識別子のためのメニュー仕様の要求を受信し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
前記メニュー仕様をデータベースで検索し、
前記データベースにおいて見つからなければ、ユニークパーシステント統一名称識別子ディレクトリにおいてメタデータからの前記ユニークパーシステント統一名称識別子に対してメニュー仕様を生成し、
前記メニュー仕様をもし生成された場合には前記データベースに格納し、
前記ユニークパーシステント統一名称識別子メニュー仕様からユニークパーシステント統一名称識別子メニューを生成し、ここで、前記ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用され、
要求に応答して前記ユニークパーシステント統一名称識別子メニューを要求クライアントに提供することを特徴とする媒体。
【請求項２３】
インターリンク決定のためにプロセッサが可読な媒体において、
前記プロセッサ可読媒体の命令信号を有し、ここで、前記命令信号は前記プロセッサによって発行可能であり、
前記プロセッサは、
比較に基づいてターゲットユニークパーシステント統一名称識別子を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、
ウェブサイトをインデックスクロールしながらターゲットユニークパーシステント統一名称識別子を発見されたユニークパーシステント統一名称識別子と比較し、
ユニークパーシステント統一名称識別子と発見されたユニークパーシステント統一名称識別子との間の照合数と非照合数に着目することによってターゲットユニークパーシステント統一名称識別子のインターリンク度を決定することを特徴とする媒体。
【請求項２４】
メニューを生成する装置において、
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するにように構成されたプロセッサと、ここで、前記命令は信号を生成し、
当該信号は、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットに関係するコンテンツアイテムへの多重レファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子記録の階層構造に基づいてメニュー仕様を生成することを特徴とする装置。
【請求項２５】
メニューを生成する装置において、
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するにように構成されたプロセッサと、ここで、前記命令は信号を生成し、
当該信号は、
メタデータフィールドとバリューを取得し、
ユニークパーシステント統一名称識別子メニュー仕様をもしそれが存在すれば取得し、
入手不能であれば、前記メタデータフィールド及びバリューからユニークパーシステント統一名称識別子メニュー仕様を生成し、
メタデータフィールドを前記メニュー仕様におけるフィールドに照合し、
照合されたフィールド及びフィールドバリューに基づいて前記メタデータを検索し、
前記照合されたフィールド及びフィールドバリューに基づいてターゲットレファレンスを形成し、
ユニークパーシステント統一名称識別子ディレクトリにおけるユニークパーシステント統一名称識別子記録に前記ターゲットレファレンスを格納することを特徴とする装置。
【請求項２６】
メニューを生成する装置において、
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するにように構成されたプロセッサと、ここで、前記命令は信号を生成し、
当該信号は、
ユニークパーシステント統一名称識別子とユニークパーシステント統一名称識別子メニューとの間の関係を確立し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
前記ターゲットレファレンスを形成し、ここで、ターゲットレファレンスはユニークパーシステント統一名称識別子ディレクトリにおけるユニークパーシステント統一名称識別子記録に格納され、
前記ターゲットコンテンツアセットと前記ターゲットレファレンスへのリンクを有するユニークパーシステント統一名称識別子メニューを作成することを特徴とする装置。
【請求項２７】
レファレンスを編集する装置において、
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するにように構成されたプロセッサと、ここで、前記命令は信号を生成し、
当該信号は、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子記録情報を表示し、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを追加し、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを削除し、
命令があれば、前記ユニークパーシステント統一名称識別子記録にフィールド及びバリューを変更し、
ユニークパーシステント統一名称識別子ディレクトリに更新されたユニークパーシステント統一名称識別子記録情報を格納することを特徴とする装置。
【請求項２８】
レファレンスを分配する装置において、
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するにように構成されたプロセッサと、ここで、前記命令は信号を生成し、
当該信号は、
ユニークパーシステント統一名称識別子のためのメニュー仕様の要求を受信し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
前記メニュー仕様をデータベースで検索し、
前記データベースにおいて見つからなければ、ユニークパーシステント統一名称識別子ディレクトリにおいてメタデータからの前記ユニークパーシステント統一名称識別子に対してメニュー仕様を生成し、
前記メニュー仕様をもし生成された場合には前記データベースに格納し、
前記ユニークパーシステント統一名称識別子メニュー仕様からユニークパーシステント統一名称識別子メニューを生成し、ここで、前記ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用され、
要求に応答して前記ユニークパーシステント統一名称識別子メニューを要求クライアントに提供することを特徴とする装置。
【請求項２９】
インターリンクを決定する装置において、
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するにように構成されたプロセッサと、ここで、前記命令は信号を生成し、
当該信号は、
比較に基づいてターゲットユニークパーシステント統一名称識別子を取得し、ここで、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、
ウェブサイトをインデックスクロールしながらターゲットユニークパーシステント統一名称識別子を発見されたユニークパーシステント統一名称識別子と比較し、
ユニークパーシステント統一名称識別子と発見されたユニークパーシステント統一名称識別子との間の照合数と非照合数に着目することによってターゲットユニークパーシステント統一名称識別子のインターリンク度を決定することを特徴とする装置。
【請求項３０】
各メニューアイテムがレファレンスターゲット識別子を有するメニューアイテムの初期階層を作成し、ここで、メニューアイテムは複合媒体を含んでもよく、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされ、
メニュー閲覧者が検討するために前記初期階層を分配し、
前記初期階層のレファレンスターゲット識別子と関連メニューアイテム情報が有効であることを検証し、
前記初期階層の前記メニュー閲覧者の使用の追跡を有効にし、ここで、追跡はメニューアイテムによって作られる幾つかのインプレッションを含み、追跡はメニューアイテムが選択される回数を含み、
使用の追跡に基づいて前記初期階層において前記メニューアイテムを変更し、変更はより人気のあるメニューアイテムをより目立つように配列することを含み、変更は効力を増加するためにメニューアイテムを配置することを含むことを特徴とする方法。
【請求項３１】
各メニューアイテムがレファレンスターゲット識別子を有するメニューアイテムの初期階層を作成し、
メニュー閲覧者が検討するために前記初期階層を分配し、
前記初期階層のメニュー閲覧者の使用表示を取得し、
前記使用の表示に基づいて前記初期階層において前記メニューアイテムを変更することを含むことを特徴とする方法。
【請求項３２】
プロセッサが実行する方法において、
コンテンツにアクセスする要求クライアントからユニークパーシステント統一名称識別子の要求を受信し、ここで、前記要求はコンテンツのアクセスから誘起され、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子メニュー仕様を取得し、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、
前記ユニークパーシステント統一名称識別子メニュー仕様からメニューアイテムのユニークパーシステント統一名称識別子階層を生成し、ここで、前記ユニークパーシステント統一名称識別子メニュー仕様は前記ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用され、メニューアイテムは複合媒体を含んでもよく、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、
前記メニューアイテムの階層は広告によって引き起こされ、
前記ユニークパーシステント統一名称識別子メニューのレファレンスターゲット識別子と関連メニューアイテム情報が有効であることを検証し、
エンドユーザーからユニークパーシステント統一名称識別子メニュー仕様の追跡を有効にし、追跡はメニューアイテムによって作られた幾つかのインプレッションを含み、追跡はメニューアイテムが選択された回数を含み、
前記使用の追跡に基づいてユニークパーシステント統一名称識別子メニューアイテムを変更し、変更はより人気のあるメニューアイテムをより目立つように配置することを含み、変更は効率を増加するためにメニューアイテムを配置することを含むことを特徴とする方法。
【請求項３３】
プロセッサが実行する方法において、
コンテンツにアクセスする要求クライアントからユニークパーシステント統一名称識別子の要求を受信し、ここで、前記要求はコンテンツのアクセスから誘起され、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子メニュー仕様を取得し、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、
前記ユニークパーシステント統一名称識別子メニュー仕様からメニューアイテムのユニークパーシステント統一名称識別子階層を生成し、ここで、前記ユニークパーシステント統一名称識別子メニュー仕様は前記ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用され、
エンドユーザーからユニークパーシステント統一名称識別子メニュー仕様の追跡を有効にし、
前記使用の追跡に基づいてユニークパーシステント統一名称識別子メニューアイテムを変更することを特徴とする方法。
【請求項３４】
プロセッサが実行する方法において、購入サイクルを圧縮する階層メニューを生成することを特徴とする方法。
【請求項３５】
ユーザーインターフェースを生成する、プロセッサが実行する方法において、
メニューアイテムの階層を生成するトリガーと共に埋め込まれた関与コンテンツに応答してメニューアイテムの使用を追跡し、ユーザーからのフィードバックとメニュー仕様からメニューアイテムの階層を生成し、メニューアイテムは複合媒体を含むことができ、メニューアイテムはバックエンドサーバーからの情報を含むことができ、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされることを特徴とする方法。
【請求項３６】
ユーザーインターフェースを生成する、プロセッサが実行する方法において、
メニューアイテムの階層を生成するトリガーと共に埋め込まれた関与コンテンツに応答してメニューアイテムの使用を追跡し、ユーザーからのフィードバックとメニュー仕様からメニューアイテムの階層を生成することを特徴とする方法。
【請求項３７】
ユーザーインターフェースを生成する、プロセッサが実行する方法において、
セグメント選択部とターゲット中間層階層メニューを識別する情報を含む第１層の階層メニューレベルを生成し、
ブランド選択部とターゲット後層階層メニューを識別する情報を含む中間層の階層メニューレベルを生成し、
情報とターゲット同一ブランド取引を含む後層階層メニューレベルを生成し、
メニューアイテムは階層内に複合媒体を含んでもよく、前記メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、メニューアイテムの階層は広告によって引き起こされることを特徴とする方法。
【請求項３８】
ユーザーインターフェースを生成する、プロセッサが実行する方法において、
セグメント選択部とターゲット中間層階層メニューを識別する情報を含む第１層の階層メニューレベルを生成し、
ブランド選択部とターゲット後層階層メニューを識別する情報を含む中間層の階層メニューレベルを生成し、
情報とターゲット同一ブランド取引を含む後層階層メニューレベルを生成することを特徴とする方法。
【請求項３９】
メニューを作成するシステムにおいて、購入サイクルを圧縮する階層メニューを生成することを特徴とするシステム。
【請求項４０】
メニューを作成するシステムにおいて、
各メニューアイテムがレファレンスターゲット識別子を有するメニューアイテムの初期階層を作成する手段と、ここで、メニューアイテムは複合媒体を含むことができ、メニューアイテムはバックエンドサーバーからの情報を含むことができ、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされ、
メニュー閲覧者が検討するために前記初期階層を分配する手段と、
前記初期階層のレファレンスターゲット識別子と関連メニューアイテム情報が有効であることを検証する手段と、
前記初期階層の前記メニュー閲覧者の使用の追跡を有効にする手段と、ここで、追跡はメニューアイテムによって作られる幾つかのインプレッションを含み、追跡はメニューアイテムが選択される回数を含み、
使用の追跡に基づいて前記初期階層において前記メニューアイテムを変更する手段と、変更はより人気のあるメニューアイテムをより目立つように配列することを含み、変更は効力を増加するためにメニューアイテムを配置することを含むことを特徴とする方法。
【請求項４１】
メニューを作成するシステムにおいて、
コンテンツにアクセスする要求クライアントからユニークパーシステント統一名称識別子の要求を受信する手段と、ここで、前記要求はコンテンツのアクセスから誘起され、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子メニュー仕様を取得する手段と、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得する手段と、
ユニークパーシステント統一名称識別子メニュー仕様からユニークパーシステント統一名称識別子メニューを生成する手段と、ユニークパーシステント統一名称識別子メニュー仕様は、ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用され、メニューアイテムは複合媒体を含む場合があり、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされ、
前記初期階層のレファレンスターゲット識別子と関連メニューアイテム情報が有効であることを検証する手段と、
エンドユーザーからユニークパーシステント統一名称識別子メニュー仕様の追跡を有効にする手段と、追跡はメニューアイテムによって作られた幾つかのインプレッションを含み、追跡はメニューアイテムが選択された回数を含み、
前記使用の追跡に基づいてユニークパーシステント統一名称識別子メニューアイテムを変更する手段と、変更はより人気のあるメニューアイテムをより目立つように配置することを含み、変更は効率を増加するためにメニューアイテムを配置することを含むことを特徴とするシステム。
【請求項４２】
ユーザーインターフェースを生成するシステムにおいて、
メニューアイテムの階層の生成のためのトリガーと共に埋め込まれた関与コンテンツに応答してメニューアイテムの使用を追跡し、ユーザーからのフィードバックとメニュー仕様からメニューアイテムの階層を生成する手段を有し、
メニューアイテムは複合媒体を含む場合があり、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされることを特徴とするシステム。
【請求項４３】
ユーザーインターフェースを生成するシステムにおいて、
セグメント選択部とターゲット中間層階層メニューを識別する情報を含む第１層の階層メニューレベルを生成する手段と、
ブランド選択部とターゲット後層階層メニューを識別する情報を含む中間層の階層メニューレベルを生成する手段と、
情報とターゲット同一ブランド取引を含む後層階層メニューレベルを生成する手段とを有し、
メニューアイテムは複合媒体を含む場合があり、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされることを特徴とするシステム。
【請求項４４】
インターラクションインターフェースを使用するためにプロセッサが可読な媒体において、
前記プロセッサが可読な媒体に命令信号を有し、当該命令信号は購入サイクルを圧縮する階層メニューを使用するためにユーザーとシステムイベントシグナルに応答して前記プロセッサによって発行可能であることを特徴とする媒体。
【請求項４５】
メニューを作成するためにプロセッサが可読な媒体において、
前記プロセッサが可読な媒体に命令信号を有し、当該命令信号は前記プロセッサによって発行可能であり、
当該プロセッサは、
各メニューアイテムがレファレンスターゲット識別子を有するメニューアイテムの初期階層を作成し、ここで、メニューアイテムは複合媒体を含んでもよく、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされ、
メニュー閲覧者が検討するために前記初期階層を分配し、
前記初期階層のレファレンスターゲット識別子と関連メニューアイテム情報が有効であることを検証し、
前記初期階層の前記メニュー閲覧者の使用の追跡を有効にし、ここで、追跡はメニューアイテムによって作られる幾つかのインプレッションを含み、追跡はメニューアイテムが選択される回数を含み、
使用の追跡に基づいて前記初期階層において前記メニューアイテムを変更し、変更はより人気のあるメニューアイテムをより目立つように配置することを含み、変更は効力を増加するためにメニューアイテムを配置することを含むことを特徴とする媒体。
【請求項４６】
メニューを作成するためにプロセッサが可読な媒体において、
前記プロセッサが可読な媒体に命令信号を有し、当該命令信号は前記プロセッサによって発行可能であり、
当該プロセッサは、
コンテンツにアクセスする要求クライアントからユニークパーシステント統一名称識別子の要求を受信し、ここで、前記要求はコンテンツのアクセスから誘起され、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子メニュー仕様を取得し、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、
前記ユニークパーシステント統一名称識別子メニュー仕様からメニューアイテムのユニークパーシステント統一名称識別子階層を生成し、ここで、前記ユニークパーシステント統一名称識別子メニュー仕様は前記ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用され、メニューアイテムは複合媒体を含んでもよく、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされ、
前記ユニークパーシステント統一名称識別子メニューのレファレンスターゲット識別子と関連メニューアイテム情報が有効であることを検証し、
エンドユーザーからユニークパーシステント統一名称識別子メニュー仕様の追跡を有効にし、追跡はメニューアイテムによって作られた幾つかのインプレッションを含み、追跡はメニューアイテムが選択された回数を含み、
前記使用の追跡に基づいてユニークパーシステント統一名称識別子メニューアイテムを変更し、変更はより人気のあるメニューアイテムをより目立つように配置することを含み、変更は効率を増加するためにメニューアイテムを配置することを含むことを特徴とする媒体。
【請求項４７】
インターラクションインターフェースを使用するプロセッサが可読な媒体において、
前記プロセッサが可読な媒体に命令信号を有し、当該命令信号はユーザーとシステムイベント信号に応答して前記プロセッサによって発行可能であり、
メニューアイテムの階層を発生するためのトリガーと共に埋め込まれた関与コンテンツに応答してメニューアイテムの使用を追跡し、ユーザーからのフィードバックとメニュー仕様からメニューアイテムの階層を引き起こし、
メニューアイテムは複合媒体を含んでもよく、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされることを特徴とする媒体。
【請求項４８】
インターラクションインターフェースを使用するプロセッサが可読な媒体において、
前記プロセッサが可読な媒体に命令信号を有し、当該命令信号はユーザーとシステムイベント信号に応答して前記プロセッサによって発行可能であり、
メニューアイテムの階層を発生するためのトリガーと共に埋め込まれた関与コンテンツに応答してメニューアイテムの使用を追跡し、ユーザーからのフィードバックとメニュー仕様からメニューアイテムの階層を生成することを特徴とする媒体。
【請求項４９】
インターラクションインターフェースを使用するプロセッサが可読な媒体において、
前記プロセッサが可読な媒体に命令信号を有し、当該命令信号はユーザーとシステムイベント信号に応答して前記プロセッサによって発行可能であり、
セグメント選択部とターゲット中間層階層メニューを識別する情報を含む第１層の階層メニューレベルと、
ブランド選択部とターゲット後層階層メニューを識別する情報を含む中間層の階層メニューレベルと、
情報とターゲット同一ブランド取引を含む後層階層メニューレベルとを引き起こし、
メニューアイテムは複合媒体を含む場合があり、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされることを特徴とする媒体。
【請求項５０】
インターラクションインターフェースを使用するプロセッサが可読な媒体において、
前記プロセッサが可読な媒体に命令信号を有し、当該命令信号はユーザーとシステムイベント信号に応答して前記プロセッサによって発行可能であり、
前記プロセッサが可読な媒体に命令信号を有し、当該命令信号はユーザーとシステムイベント信号に応答して前記プロセッサによって発行可能であり、
セグメント選択部とターゲット中間層階層メニューを識別する情報を含む第１層の階層メニューレベルと、
ブランド選択部とターゲット後層階層メニューを識別する情報を含む中間層の階層メニューレベルと、
情報とターゲット同一ブランド取引を含む後層階層メニューレベルとを使用することを特徴とする媒体。
【請求項５１】
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するように構成されたプロセッサとを有し、
前記命令は購入サイクルを圧縮する階層メニューを使用するためにユーザー及びシステムイベント信号に応答して前記プロセッサによって発行可能であることを特徴とする装置。
【請求項５２】
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するように構成されたプロセッサとを有し、
前記命令は信号を発行し、当該信号は、
各メニューアイテムがレファレンスターゲット識別子を有するメニューアイテムの初期階層を作成し、ここで、メニューアイテムは複合媒体を含んでもよく、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされ、
メニュー閲覧者が検討するために前記初期階層を分配し、
前記初期階層のレファレンスターゲット識別子と関連メニューアイテム情報が有効であることを検証し、
前記初期階層の前記メニュー閲覧者の使用の追跡を有効にし、ここで、追跡はメニューアイテムによって作られる幾つかのインプレッションを含み、追跡はメニューアイテムが選択される回数を含み、
使用の追跡に基づいて前記初期階層において前記メニューアイテムを変更し、変更はより人気のあるメニューアイテムをより顕著に配列することを含み、変更は効力を増加するためにメニューアイテムを配置することを含むことを特徴とする装置。
【請求項５３】
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するように構成されたプロセッサとを有し、
前記命令は信号を発行し、当該信号は、
コンテンツにアクセスする要求クライアントからユニークパーシステント統一名称識別子の要求を受信し、ここで、前記要求はコンテンツのアクセスから誘起され、前記ユニークパーシステント統一名称識別子はターゲットコンテンツアセットを識別し、前記ユニークパーシステント統一名称識別子は前記ターゲットコンテンツアセットに関連するコンテンツアイテムへの複数のレファレンスを有する多重識別子であり、
ユニークパーシステント統一名称識別子メニュー仕様を取得し、
ユニークパーシステント統一名称識別子ディレクトリからユニークパーシステント統一名称識別子記録情報を取得し、
前記ユニークパーシステント統一名称識別子メニュー仕様からメニューアイテムのユニークパーシステント統一名称識別子階層を生成し、ここで、前記ユニークパーシステント統一名称識別子メニュー仕様は前記ユニークパーシステント統一名称識別子メニューを形成するユニークパーシステント統一名称識別子記録情報からのバリューを特定するのに使用され、メニューアイテムは複合媒体を含んでもよく、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされ、
前記ユニークパーシステント統一名称識別子メニューのレファレンスターゲット識別子と関連メニューアイテム情報が有効であることを検証し、
エンドユーザーからユニークパーシステント統一名称識別子メニュー仕様の追跡を有効にし、追跡はメニューアイテムによって作られた幾つかのインプレッションを含み、追跡はメニューアイテムが選択された回数を含み、
前記使用の追跡に基づいてユニークパーシステント統一名称識別子メニューアイテムを変更し、変更はより人気のあるメニューアイテムをより目立つように配置することを含み、変更は効率を増加するためにメニューアイテムを配置することを含むことを特徴とする装置。
【請求項５４】
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するように構成されたプロセッサとを有し、
前記命令は信号を発行し、当該信号は、
ユーザーとシステムイベント信号に応答して前記プロセッサによって発行可能であり、メニューアイテムの階層を使用するためのトリガーと共に埋め込まれた関与コンテンツに応答してのメニューアイテムの使用を追跡するユーザーからのフィードバックからとメニュー仕様からメニューアイテムの階層を使用することを特徴とする装置。
【請求項５５】
メモリと、
前記メモリと通信するように配置され、前記メモリに格納された複数の処理命令を発行するように構成されたプロセッサとを有し、
前記命令はユーザー及びシステムイベント信号に応答して前記プロセッサによって発行可能であり、
セグメント選択部とターゲット中間層階層メニューを識別する情報を含む第１層の階層メニューレベルと、
ブランド選択部とターゲット後層階層メニューを識別する情報を含む中間層の階層メニューレベルと、
情報とターゲット同一ブランド取引を含む後層階層メニューレベルとを引き起こし、
メニューアイテムは複合媒体を含んでもよく、メニューアイテムはバックエンドサーバーからの情報を含んでもよく、前記メニューアイテムは購入を有効にするリンクであり、前記メニューアイテムの階層は広告によって引き起こされることを特徴とする装置。
【外国語明細書】
APParatuses, methods and systems for integrated, information-engineered and self-improving advertising, E-commerce and online customer interactions
ReLated Applications
・  This application also hereby incorporates by reference the provisional application for letters patent, number 60/268,766, titled “APPARATUS, METHOD AND SYSTEM FOR MULTIPLE RESOLUTION AFFECTING INFORMATION ACCESS,” and filed in the United States Patent and Trademark Office on February 14, 2001.
・  This application also hereby incorporates by reference the application for letters patent, number 10/470,206, titled “APPARATUS METHOD AND SYSTEM FOR INFORMATION ACCESS IN A PEER ENVIRONMENT” and filed in the United States Patent and Trademark Office on July 24, 2003.
・  This application also hereby incorporates by reference the application for letters patent, number 10/470,207, titled “APPARATUS, METHOD AND SYSTEM FOR DIRECTORY QUALITY ASSURANCE,” and filed in the United States Patent and Trademark Office on July 24, 2003.
・  This application also hereby incorporates by reference the application for letters patent, number 10/470,258, titled “APPARATUS, METHOD AND SYSTEM FOR ACCESSING DIGITAL MANAGEMENT INFORMATION,” and filed in the United States Patent and Trademark Office on July 24, 2003.
・  This also is a continuation-in-part of the application for letters patent, number 60/642,809 titled “APPARATUSES, METHOD AND SYSTEM TO GENERATE, EDIT, DEPLOY AND MAINTAIN INTERRELATED UNIQUE PERSISTENT UNIVERSAL RESOURCE IDENTIFIERS, MENUS AND INFORMATION,” and filed in the United States Patent and Trademark Office on January 11, 2005. The entire contents of the aforementioned applications are herein expressly incorporated by reference.
・  This also is a continuation-in-part of the application for letters patent, number 60/726,689 titled “APPARATUSES, METHODS AND SYSTEMS FOR INTEGRATED, INFORMATION-ENGINEERED AND SELF-IMPROVING ADVERTISING, E-COMMERCE AND ONLINE CUSTOMER INTERACTIONS,” and filed in the United States Patent and Trademark Office on October 14, 2005. The entire contents of the aforementioned applications are herein expressly incorporated by reference.
FIELD
・  The present invention relates generally to an apparatuses, methods and systems to access information across a communications network. More particularly, the disclosed invention relates to an apparatuses, methods and systems to Integrated information-engineered and Self-Improving facility for advertising, e-commerce and online Customer Interactions (ISICI). 
BACKGROUND
Internet
・  As Internet usage increases, the amount of information available on the Internet also increases. The information that exists on the Internet is of many different types, including documents in many formats such as: computer software, databases, discussion lists, electronic journals, library catalogues, online information services, mailing lists, news groups, streaming media, and the like. Fortunately, much of the information on the Internet can be accessed through the World-Wide Web using a Web browser to interact with the network in a user-friendly way.
Network
・  Networks are commonly thought to consist of the interconnection and interoperation of clients, servers, and intermediary nodes in a graph topology. It should be noted that the term "server" as used herein refers generally to a computer, other device, software, and/or combination thereof that processes and responds to the requests of clients, often from across a communications network. The term “client,” in turn, generally refers to a computer, other device, software, user, and/or combination thereof that generates requests for service. Generally, the term “client” and “user” are interchangeable, and are used as such throughout. As such, servers serve their information to requesting clients. A computer, other device, software, or combination thereof that facilitates, processes information and requests, and/or furthers the passage of information from a source user to a destination user is commonly referred to as a “node.” Networks are generally thought to facilitate the transfer of information from source points to destinations.
TRANSMISSION CONTROL PROTOCOL-INTERNET PROTOCOL (TCP/IP)
・  The proliferation and expansion of computer systems, databases, and networks of computers has been facilitated by an interconnection of such systems and networks in an extraterritorial communications network commonly referred to as the Internet. The Internet has developed and largely employs the Transmission Control Protocol-Internet Protocol (TCP/IP). TCP/IP was developed by a Department of Defense (DoD) research project to interconnect networks made by various and varying network vendors as a foundation for a network of networks, i.e., the Internet. The development of TCP/IP was in part driven by a requirement by the DoD to have a network that will continue to operate even if damaged during battle, thus allowing for information to be routed around damaged portions of the communications network to destination addresses. Of course, if the source or destination address location itself is rendered inoperable, such delivery will not be possible.
・  The Internet is a packet-switched network and thus, information on the Internet is broken up into pieces, called packets, and transmitted in packet form. The packets contain IP addressing information called headers, which are used by routers to facilitate the delivery of the packets from a source to a destination across intermediary nodes on the Internet. Upon arrival at the destination, the packets are reassembled to form the original message, and any missing packets are requested again.
・  The IP component of the protocol is responsible for routing packets of information based on a four byte addressing mechanism; the address is written as four numbers separated by dots, each number ranging from 0 to 255, e.g., “123.255.0.123”. IP addresses are assigned by Internet authorities and registration agencies, and are unique.
・  The TCP portion of the protocol is used for verifying that packets of information are correctly received by the destination computer from the source, and if not, to retransmit corrupt packets. Other transmission control protocols are also commonly used that do not guarantee delivery, such as User Datagram Protocol (UDP).
World Wide Web
・  The proliferation and expansion of the Internet, and particularly the World Wide Web (the Web), have resulted in a vast and diverse collection of information. Various user interfaces that facilitate the interaction of users with information technology systems (i.e., people using computers) are currently in use. An information navigation interface called WorldWideWeb.app (the Web) was developed in late 1990. Subsequently, information navigation interfaces such as Web browsers have become widely available on almost every computer operating system platform. 
・  Generally, the Web is the manifestation and result of a synergetic interoperation between user interfaces (e.g., Web browsers), servers, distributed information, protocols, and specifications. Web browsers were designed to facilitate navigation and access to information, while information servers were designed to facilitate provision of information. Typically, Web browsers and information servers are disposed in communication with one another through a communications network. Information Servers function to serve information to users that typically access the information by way of Web browsers. As such, information servers typically provide information to users employing Web browsers for navigating and accessing information on the Web. Microsoft’s Internet Explorer and Netscape Navigator are examples of Web browsers. In addition, navigation user interface devices such as WebTV have also been implemented to facilitate Internet navigation. Many other navigation interfaces and devices also exist for navigating the Internet such as File Transmission Protocol (FTP), email interfaces (e.g., mailto:), search queries, database queries, scripts, Web Services (such as Microsoft’s .NET or Sun Microsystems’ SunONE), and the like. Some of these interfaces are intended for use by human beings, and some are intended for use directly by machines, devices, software programs, and the like. Microsoft’s Information Server and Apache are examples of information servers. 
UNIVERSAL RESOURCE LOCATOR (URL)
・  The expansion of the Web has resulted in an enormous quantity of information, which is accessible through the use of Universal Resource Locators (URLs) and other address-based or location-based methods. An URL is an address that is typically embodied as a hyperlink in a Web page or is typed into a Web browser. URLs for a given resource (most commonly a file located on a remote computer) refer only to a location for that resource. Typically, the reference to the location is achieved through the use of an unresolved IP address in conjunction with a directory path and file name; e.g., “http://www.aWebSite.com/aFolder/aFile.html”. In this example, the URL directs the browser to connect to the computer named “www” in the domain “aWebSite.com,” and to request the file named “aFile.html” stored in directory “aFolder” at that computer.
UNIVERSAL Resource IDENTIFIER (URI) 
・  The Corporation for National Research Initiatives has created and implemented a new means of naming and locating information, called the Handle System. The Handle System is designed to improve upon or replace the current use of URLs. 
・  The Handle System introduces a level of indirection to locating and distributing information over the Internet. The Handle System is a general-purpose system for naming resources. Instead of being assigned a URL based on a particular resource’s current network location, a resource may be assigned a Universal Name Identifier (UNI). A UNI is a form of Universal Resource Identifier (URI). URIs include both UNIs and URLs. A UNI, unlike a URL, serves and shall be regarded henceforth as a name for the resource that is persistent regardless of changes in the resource’s location or other attributes. In turn, a Universal Resource Name (URN) is a type of UNI (i.e., a UNI subsumes the concept of a URN). Furthermore, a Handle is a type of URN. And a Digital Object Identifier (DOI) is a type of Handle. Thus, various forms of UNIs include Handles, URNs, DOIs, and/or the like. The various terms and/or forms of URIs will be used interchangeably throughout this document, and may be assumed to be interchangeable unless stated otherwise. A Handle is a unique name, which is registered with the Handle System along with the current network location of the named resource. This location information commonly takes the form of a URL. One common type of Handle is known as a Digital Object Identifier (DOI). Handles may be then distributed to users in lieu of a URL, and superficially appear to function similarly to a hyperlink. When a user encounters a Handle, the user may select or enter the Handle much like a URL hyperlink, so long as the user’s Web browser is capable of making Handle requests. Such an encounter triggers an automated process to look up a resource’s current location. The current location of the resource is associated with the resource’s Handle in a directory made available by the Handle System, which in turn directs the user to the resource’s current location. Unlike with a URL, if the resource moves, the Handle System directory entry can be updated, thereby assuring a persistent association between a Handle and the resource it identifies. An analogy can be made to the physical world: knowing only a URL for a given resource is akin to knowing only a person’s street address, and not her name. If she were to move across town, it would be very difficult to locate her without knowing her name. The Handle System allows resources to be permanently named by way of a Handle, and it allows the current network location of resources to be looked up based on that name in a Handle System directory. 
online advertising
・  Advertising technologies have been developed in an effort to capitalize on the Internet’s ability to track end user behavior in ways not possible with traditional media: e.g., with television or print magazine ads, where there is no mechanism by which to measure the end user’s actual interaction, or even to verify that the end user has seen the ad at all. Companies have created “contextual ads” (such as Google’s AdSense) which “read” the content of a Web page and then place certain ads on that page in response to the page’s context (e.g., Google “Sponsored Links,” which are selected and placed in a Web page in response to the particular subject-matter of the page).
SUMMARY
・  Digital Object Identifiers (DOIs) overcome many of the shortcomings of IP addresses and other location-based addressing schemes. DOIs enable access to information over a communications network by providing a persistent identifier for information that may be regularly relocated. DOIs overcome the limitations of network addressing schemes limited to addressing locations by providing a mechanism to associate identifiers with information through an added level of indirection instead of associating identifiers with locations.
・  Although DOIs provide a mechanism that allows for the association of an identifier with information instead of a location, DOIs in and of themselves do not provide for the access of multiple and/or varying instances of a piece of information in various locations, formats, or the access and/or tracking of various services associated with a given piece of information, based on various contexts of use. 
・  In one embodiment of the present invention, a method is taught for using at least one computer to generate a reference menu. The method comprises receiving a request for a unique persistent universal name identifier (UPUNI) from a requesting client accessing content and generating an UPUNI menu from the UPUNI menu specification, wherein the UPUNI menu specification is used to specify values from UPUNI record information with which to populate the UPUNI menu. 
・  Furthermore, the disclosure details apparatuses, methods, and systems to Integrated information-engineered and Self-Improving facility for advertising, e-commerce and online Customer Interactions (ISICI). Aspects of the ISICI have already been detailed in the application for letters patent, number 60/642,809 titled “APPARATUSES, METHOD AND SYSTEM TO GENERATE, EDIT, DEPLOY AND MAINTAIN INTERRELATED UNIQUE PERSISTENT UNIVERSAL RESOURCE IDENTIFIERS, MENUS AND INFORMATION,” and filed in the United States Patent and Trademark Office on January 11, 2005; the ISICI employs various aspects of the Autolinker, Syndicator and Customizer of Unique Persistent Universal Resource Identifiers (ASCUPURI) as described therein and throughout this disclosure. The ISICI includes a feedback loop enabling improvement of itself as driven by the actual interaction of end-users with the ISICI. Based on the tracking of actual end-user interaction with these menus, a feedback loop can be created such that the menus can be revised and improved based on the empirical tracking data that is fed back into a creation/maintenance cycle. The disclosure of the ISICI provides numerous embodiments on how such tracked information may be fed back into the creation/maintenance cycle. For example, information may be fed back manually (i.e., based on human review of the tracking results and human judgment as to the most appropriate revisions to the menu and which revisions in turn may be implemented manually via the MultiLink editor), through an automated “assembly line” to revise/create a menu (i.e., so that on a going-forward basis, this system will automatically create and maintain different menus), fully automatically (for example, where the order of menu choices may be rearranged based on the relative popularity of the different menu choices, as captured by measuring actual user behavior in interacting with the menu), and/or the like.
・  These measurements of behavior may include tracking the click-through rates associated with various menu choices, tracking the subsequent behavior (e.g. post click-through) in terms purchasing or other transactions, tracking the measurements of the time spent by the user hovering over various menu choices, tracking the measurements of the frequency with which various menu choices are rolled over, and/or the like.
・  This feedback to the menu creation/maintenance cycle may also come from other sources besides the end user’s behavior in interacting with the menus. Such sources may include: independent metrics of the user’s purchasing behavior (either subsequent to the user’s click-through of the menus or entirely unrelated); independently-recorded user preference information (either individually or in aggregate); independently-recorded user information that is associated with a category of user (e.g., anonymized metrics profiling a type of user by income, interests, demographics, preferences, and/or the like-such an embodiment would not associate profiled information with any individual); metrics recorded by the site hosting the menu (e.g., profiling based on time of day, geographical location of site visitors, etc.), and/or the like.
・  The menu improvements driven by this feedback loop may include changes in the order of links on the menu, selective inclusion or suppression of different links (e.g., either centrally in the master control record controlling the menu universally, or solely in a locally-customized version of the menu on a particular web site), selective retrieval of data from back-end systems in order to populate the menus differently, the inclusion or suppression of graphics or video or other multimedia effects, and/or the like.
・  The menu improvements need not be limited to improvements to encourage purchasing behavior; nor does the system need to be limited to advertising-oriented applications at all. Any system that serves up information or otherwise services end users or even computer programs can utilize the present invention. An information system by which a city, state or federal government provides information to its citizens can utilize the present invention to continuously improve the menus based on measuring what kinds of information most citizens actually want in a given context. In one embodiment, a military system that serves up intelligence information or military logistics information could utilize the present invention to offer the most useful information and links based on external factors such as the elevation of a certain suspected terrorist onto a high-priority watch list, the elevation of a building or other physical asset onto a similar high-risk watch list due to intelligence gathered about a possible terrorist strike, sensor data monitoring enemy troop movements, and/or the like. In another embodiment, in order to improve the menu choices on a dynamic basis, a bank or insurance company that wishes to help its customers or even its internal staff to navigate through complex and information-intensive processes can use source data ranging from user behavior to internal prioritizations of services it wishes to market.
BRIEF DESCRIPTION OF THE DRAWINGS
・  The accompanying drawings illustrate various non-limiting, example, inventive aspects in accordance with the present disclosure:
・  FIGURE 1 is of a mixed data and logic flow diagram illustrating embodiments of a Integrated information-engineered and Self-Improving facility for advertising, e-commerce and online Customer Interactions (ISICI);
・  FIGURE 2 is of a mixed data and logic flow diagram illustrating embodiments of an Autolinker;
・  FIGURE 3 is of a mixed data and logic flow diagram illustrating embodiments of an IntraConnector;
・  FIGURE 4 is of a logic flow diagram illustrating embodiments of a MultiLink syndication;
・  FIGURES 5-6 are of diagrams illustrating embodiments of a MultiLink menu editor and personal DOI;
・  FIGURE 7 illustrates IP addressing mechanisms;
・  FIGURE 8 illustrates the access of information through Digital Object Identifiers (DOIs);
・  FIGURE 9 provides a schematic view of a Handle and an enhanced DOI grammar;
・  FIGURE 10 provides an overview of the resolution mechanism for allowing users to access the desired information;
・  FIGURE 11 provides an overview of the sequence of actions that a user performs to access information;
・  FIGURE 12 provides an overview of some of the exemplary mechanisms for accessing information over a communications network by resolving a DOI to obtain the URL;
・  FIGURE 13 provides an overview of an exemplary DOI system;
・  FIGURE 14 illustrates example advertisements served by an advertising Syndicator;
・  FIGURE 15 illustrates example MultiLink applications;
・  FIGURE 16 illustrates example MultiLink applications and user interfaces;
・  FIGURE 17 is of a mixed data flow diagram illustrating embodiments of a MultiLink eco-system;
・  FIGURE 18 is of a diagram illustrating graphical embodiments of a MultiLink menu editor;
・  FIGURE 19 is of a logic flow diagram illustrating embodiments of a MultiLink menu tracker;
・  FIGURE 20 shows a MultiLink tracking user interface and tracking log;
・  FIGURE 21 shows a purchase cycle;
・  FIGURE 22 is of a block diagram illustrating embodiments of a Integrated information-engineered and Self-Improving facility for advertising, e-commerce and online Customer Interactions controller;
・  The leading number of each reference number within the drawings indicates the first figure in which that reference number is introduced. As such, reference number 101 is first introduced in Figure 1. Reference number 201 is first introduced in Figure 2, etc.
DETAILED DESCRIPTION
Integrated information-engineered and Self-Improving facility for advertising, e-commerce and online Customer Interactions
・  FIGURE 1 is of a mixed data and logic flow diagram illustrating embodiments of apparatuses, methods and systems to Integrated information-engineered and Self-Improving facility for advertising, e-commerce and online Customer Interactions (ISICI). Generally, the ISICI is comprised of three components: 1) creation and maintenance of MultiLink menus 181; 2) registration and updating of the underlying multilink records 182; and 3) distribution/syndication of the MultiLink menus 183. These three components can be seen in Figure 1, each occupying approximately a third of the figure as transversed by the thick dashed lines. The ISICI also features the tracking of syndicated MultiLink menus, which are fed back 140, 175 from the distribution/syndication component 183 to the creation/maintenance component 181 so that MultiLink menus may be optimized over time. The Autolinker creates MultiLink DOIs in the first instance 120. Then these DOIs get deposited (i.e., registered) 130 into the global directory (e.g., the Handle System) 113. Then the MultiLink DOIs are ready to be invoked by links or other “requestors” out on the communications network (e.g., the Internet). The Syndicator 135 is a mechanism for getting those links or requestors distributed out onto Web pages and other places. The Syndicator can provide filtering, modifying and/or otherwise customizing MultiLink Menus and data that are retrieved from those DOI records 113.
・  One component of the ISICI, the Autolinker, enables autolinking. The Autolinker automatically creates interlinked MultiLink menus of a user’s (e.g., client’s) information, services, transactions, etc. in connection with any target object or content. The MultiLink menu comprises two components: a MultiLink DOI and, optionally, a menu specification describing the layout and items from the MultiLink DOI to be displayed in the menu. If no menu specification is provided, the full DOI MultiLink may be used as the specification for generating the menu. These MultiLinks may point to a customer’s site, or anywhere else. For example, the MultiLinks may point to various retailers for purchasing, to related information at other companies’ sites, in other companies’ systems, and/or the like.
・  In one embodiment, customer metadata is employed by the Autolinker 105. The customer metadata may further target various objects, i.e., the metadata itself may contain DOIs. The metadata may be obtained from a number for sources. Commonly, the metadata may be exported from a customer’s database 119. The database may be queried for products, or other target objects for which the customer would like to create MultiLinked DOIs. For example, a publishing customer may query their own database selecting top selling books and accompanying information (e.g., title, author, year, best seller ranking, etc.) 175. 
・  This may be achieved with an SQL select command targeting a database table of books, and selecting for such fields. In another example embodiment, a hospital may query its own patient records and generate MultiLinks for each patient. By creating MultiLinked DOIs for hospital records, the ease of data interchange as between various medical facilities and agents is greatly enhanced. The costs for medical administration can be significantly lowered by having persistent and universally accessible references to patient and administrative records. Similar economies would apply to ancillary companies such insurance companies. In fact, by providing a singular reference by way of a MultiLink, healthcare providers, insurers and patients can all access electronic medical records and related account and insurance information all with a single reference. This will greatly cut down on clerical errors, administrative overhead costs in maintaining numerous duplicate and often inaccurate record copies. In another embodiment, a retailer may track Radio Frequency Identification (RFIDs) device activity. In such an embodiment, each RFID is provided with a unique identifier and registered with the Handle system, thus, each RFID has its own DOI. In one embodiment, a retailer may register a block of DOIs and embed each of the RFIDs with any of the registered DOIs at the time of RFID manufacture. Alternatively, the RFID numbers could be registered as DOIs at the time of RFID manufacture but not actually embedded into the RFIDs themselves; then when an RFID number is read by a reader device, the reader device could access the Handle System by formulating its Handle request using the RFID number which would have been registered previously as a DOI. As such, any system scanning for an RFID would obtain a DOI and access the Handle system. In this manner, the MultiLinks associated with the Handle System’s DOI record could link the user or the reader device to any information relating to that RFID in a permanent, persistent and comprehensive manner. In such a system, each time an item with an RFID is accessed, i.e., the point of access, the system at the point of access may modify the DOI MultiLink record in a transaction’s sub-component of the RFID’s DOI record that is modifiable by that party (e.g., the party has appropriate access control rights to make such edits); as such, a DOI record can provide full transactional tracking related to the item with the RFID. Alternatively, the retailer may track DOI enabled RFIDs via its own system database 119; as such, the retailer may select RFID related fields for exporting; those fields may then be exported as metadata 105 for use by the Autolinker 120. In one embodiment, GPS information regarding RFID’s transaction and/or whereabouts may be saved with each transaction. This transaction and location based information may constitute a transaction and location history for the DOI enabled RFID. The utility here is that a single identifier would be able to provide a total transaction and movement history regarding a particular item.
・   A number of formats may be used to encode the customer metadata such as Microsoft Excel, tab delineated fields and values, XML, and/or the like. Upon obtaining the results for a database select, various databases allow for the export of selected database records into the various export formats as a metadata submission to the Autolinker 110. A user may opt 110 to employ autolinking 120 or to generate MultiLinks manually with the Handle Editor 115. The Handle Editor will be described in greater detail in Figures 5-6. Autolinking 120 will be described in greater detail in Figure 2, but generally comprises establishing relationships between the MultiLink DOI and menu 122, constructing pointers for the MultiLink DOI record 124 and ultimately generating the MultiLink menu 126. Once the metadata is put in the form of a DOI MultiLink record 130, it may be registered in a DOI directory 113 and thereafter identified and resolved and accessed via DOI resolution servers 133. It should be noted that the DOI resolution servers may be global servers accessible to the public at large, or they may be local servers on an intranet, and thus, only accessible to users and systems on the intranet. In the intranet embodiment, local intranet administrators may modify and/or customize the local “master” DOI record, if they are the owner of that master record. If the local intranet administrator is not the owner of that “master” DOI record, then the local administrator still has the ability to modify, or cause local programs or systems to modify, the data or menus that are returned from the master DOI record, so that in the local environment it points to local resources or locally-specified resources instead of or in addition to the original creator’s resources. Alternatively, local intranet administrators may keep their locally-originating DOI requests from resolving to the global Handle Servers, and instead direct resolution to a local resolver. Optionally, a menu specification that may have been generated 126 by the Autolinker 126 would be supplied to the Syndicator 135 where it may be saved in the ISICI database. In one embodiment, such a database may be used to hold specific information necessary to drive customization of syndicated DOI MultiIinks. In an alternative embodiment, the Autolinker 120 requests that the Syndicator 135 generate a MultiLink menu and the Autolinker then saves the menu as part of the DOI record MultiLink 130.
・  In one embodiment, the Syndicator 135 enables MultiLink menus and navigation to references targeted by the menus. An example MultiLink menu is illustrated 175, in this case the MultiLink menu is for a MultiLink DOI of a book. In this example, the MultiLink menu has already been generated. The MultiLink’s DOI record has already been stored in the DOI directory 113. A menu specification for the MultiLink menu has been stored in the ISICI’s database. In one embodiment, a reference to the MultiLink menu is embedded into a Web page 140. When a user traverses to the Web page 140, the reference code, e.g., HTML code calling for a Javascript representation of the MultiLink menu, is activated to retrieve the appropriate MultiLink menu from the Syndicator 135. An example embedded reference code may have the following form:
・   
(link to Syndicator providing script)
<script src="http://doi.contentdirections.com/syndicator/10.1570/dsidman"></script>
(identifier for desired MultiLink)
<noscript><a href="http://dx.doi.org/10.1570/dsidman">DOI</a></noscript>
・  In this example, the Web page expects to obtain Javascript and the source is supplied with a reference to the Syndicator along with an associated DOI MultiLink. The request for the script is provided to the Syndicator 135, e.g., by way of a HTTP post request. The Syndicator interprets the request for the MultiLink menu by parsing for the DOI MultiLink and the source of the request. The Syndicator may then obtain the DOI MultiLink record 130 from the DOI directory 113. Next, the Syndicator may query its own internal database for a MultiLink menu specification for the MultiLink. The MultiLink menu specification may be keyed on the DOI itself as it is a unique value. If no menu specification exists, then the Syndicator may generate its own menu specification. Syndicator operations will be described in greater detail in Figure 4. 
・  In one embodiment, the ISICI may then use the MultiLink DOI record and/or the MultiLink menu specification to generate the MultiLink menu for the MultiLink DOI, e.g., generating Javascript code. It should be noted that numerous user interface platforms other than Javascript and Web browsers may be employed to generate the MultiLink menu. Upon generating the MultiLink menu, the Syndicator 135 provides the MultiLink menu back to the requesting user’s Web browser 140 where the menu is displayed 175. Once the menu is displayed by the user’s Web browser, the user may traverse the menu with a cursor and engage selections. Any selections will result in a request for resolution from a respective DOI MultiLink reference to the references content target 155. Throughout an end-user’s interaction with the MultiLink menu, the user’s interaction with the menu may be tracked. The tracked information may be saved in a number of locations including the Web server hosting the web page 140, the Syndicator, the DOI resolution server, central tracking servers, and/or the like. This tracked information may then be used to affect and modify the creation/maintenance of MultiLink menus 107. The information is fed back, and there is an option to manually edit 107 the MultiLink menu using the Handle Editor 115, or, employ the auto-linking feature 110 as have already been discussed. Details regarding tracking end-user information and how such information may be used to affect the creation and maintenance of MultiLink menus will be discussed in greater detail in Figures 16-20. This feedback to the menu creation/maintenance cycle may also come from other sources besides the end user’s behavior in interacting with the menus. Such sources may include: independent metrics of the user’s purchasing behavior (either subsequent to the user’s click-through of the menus or entirely unrelated); independently-recorded user preference information (either individually or in aggregate); independently-recorded user information that is associated with a category of user (e.g., anonymized metrics profiling a type of user by income, interests, demographics, preferences, and/or the like-such an embodiment would not associate profiled information with any individual); metrics recorded by the site hosting the menu (e.g., profiling based on time of day, geographical location of site visitors, etc.), and/or the like.
・  In one embodiment, Javascript is used to generate a menu for each item in the menu specification. This may be achieved by creating rectangular primitives and labeling each with text from the specification, the rectangular primitives being displayed in the form of a drop-down menu 175. The rectangular primitives having coordinate bounding boxes which may be highlighted when a cursor enters within any particular rectangular label’s perimeter. If a cursor’s selection mechanism, e.g., a mouse button, is engaged within the boundaries of a particular rectangular label, the respective DOI MultiLink is understood to have been selected by the user, and the users Web browser is instructed, e.g., with Javascript, to access the target content 156. Numerous other menu format embodiments may be used. MultiLink information may be displayed in any conceivable menu format, or not via a menu format at all. Instead, the menu may be displayed as individual links on a page. In such an embodiment, by employing “NoScript” tags within a Web page allows non-Javascript enabled browsers to display the links as individual links on the Web page instead of as a drop-down menu. In another embodiment, menu items may be represented as separate windows reflecting the destinations of all the MultiLink menu choices. In yet another embodiment, menu items may be channeled as input to a non-visible user interface such as a program intended to produce an audio rendering of the menu choices (e.g. to be used by a blind person), or to produce a rendering intended for use by a person with any other form of handicap. In yet another embodiment, the MultiLink menu information may not be displayed at all, or rendered in any way intended for a human being, but may be read as input by a local program, which in turn may then execute certain functions as a result of the provided information, e.g., to execute a transaction, verify identity, verify access rights, accept payment, or store or process the information for any other purpose.
・  In another embodiment, the Syndicator is integrated into a content provider’s server. This embodiment is similar to the previous example where the Syndicator was a separate server 135 from the content provider of the Web page 140. However, in this integrated embodiment, the Syndicator is running on the content provider’s server, and to the user the transaction appears to be a simple request for a DOI MultiLink record from the DOI directory 113. However, in such an example, a Syndicator component is running at the content provider’s server. This embodiment has several advantages. First, it can be faster as there is no need to access remote data. Second, it allows for local customization directly controlled by the content provider of the Web page 140, instead of having to be customized on its behalf by a third party (e.g., by the original content provider) because the Syndicator software is only running remotely. Third, in the intranet embodiment, it allows for intranet controls so that the public may be allowed or prohibited from accessing DOI MultiLinks and/or in order to point to local resources or locally-specified resources instead of or in addition to the original creator’s resources.
・  It should be noted that there may be numerous Syndicators and each may have its own menu specification for a given DOI MultiLink. For example, a search engine may have a menu specification for a book that has an option of targeting “other places to buy,” which may list Retailer A, Retailer A Subsidiary, and Retailer B. In that vein, Retailer A may have its own Syndicator at their Web server, and its menu specification will only have Retailer A and Retailer A Subsidiary under the “other places to buy” menu option. As such, it is possible to have multiple Syndicators with each having multiple menu specifications all of which can provide a myriad of different and tailored views on the same DOI MultiLink record. As such, a Syndicator may provide separate “customizations” or “renditions” of the same DOI MultiLink. In one embodiment, a Syndicator is provided as MultiLink server software, which both renders MultiLink menus via this drop-down menu presentation and permits customization of the menu beyond the default that is present in the master DOI record. It should be noted, if the MultiLink server software is right on the same server as is serving up the Web page that the DOI is on, then that Syndicator is local. If, instead, that MultiLink server software is being invoked from a separate server, then the “Syndicator” the server is remotely serving may provide the MultiLink menu and any customization out to the Web page server from where the DOI originated.
・  As such, another embodiment has a single Syndicator servicing multiple entities with varying viewing or processing needs. One example of such an embodiment, which will be discussed in greater detail in Figure 14, a ISICI may be used by an advertising provider. 
・  In one embodiment, when the Syndicator receives a request, the Syndicator also determines from where the request originated. Then when the Syndicator looks up a menu specification, it further refines that query by retrieving a specific menu specification for the entity making the request. This allows for greater tailoring of MultiLink DOIs for a particular audience. For example, an advertising provider may get paid to advertise, promote and sell the works of a particular book author. When a user engages a MultiLink in the form of a banner ad, e.g., for an author’s works, a MultiLink menu may be displayed showing the author’s name, and “Books you can buy,” which would provide a sub-menu listing the author’s books. In this tailored embodiment, if the user was viewing the ad at a kids Web site like Nickelodeon.com, the “Books you can buy” sub-menu would be pruned to only list children’s books by the author. However, at a Web site for thriller movie enthusiasts, the “Books you can buy” sub-menu would only have that author’s thriller titles. Determination of the requesting entity may be achieved in several ways. In one embodiment, the address from where the request originated is used as a basis for determining which menu specification is to be used. In such an embodiment, the query for a menu specification is made with the DOI and the Web address from the requesting site. In another embodiment, the embedded code may specify the identity of the requesting content provider. The code itself may be a DOI identifying the requesting content provider and also may be used as part of a query for the menu specification.
・  It should be noted that although the above embodiments have the Syndicator’s database storing the MultiLink menu specification and code to generate the menu, the database storing that information, however, may be located elsewhere. In one alternative embodiment, the DOI MultiLink record has an entry for the MultiLink menu specification. In yet another embodiment, the DOI MultiLink record has an entry for the Javascript code to generate the MultiLink menu.
Autolinker
・  FIGURE 2 is of a mixed data and logic flow diagram illustrating embodiments of an Autolinker. As has already been discussed in Figure 1, autolinking 120 generally is comprised of establishing relationships between the MultiLink DOI and menu 122, constructing pointers for the MultiLink DOI record 124 and ultimately generating the MultiLink menu 126.
・  The Autolinker may obtain metadata fields and values 205 from a variety of sources as has already been discussed 105 in Figure 1. At this point, the Autolinker checks to see if a menu specification was provided and/or exists. In one embodiment, the user supplying the data provides their own menu specification. The menu specification may also be in Microsoft Excel, tab delineated format, XML, and/or the like. Any format that can represent an outline hierarchy of specification field labels 270, 280, 275 and associated record field labels 289, values 291, and references 287 like what is illustrated in Figure 5 525 will suffice. In many cases, such a menu specification will be hand tuned. If a menu structure is available, the Autolinker obtains it 215. If a menu specification has not been provided, the Autolinker will attempt to generate a best guess menu structure 220. 
・  In one embodiment 220, when the Autolinker has nothing more than metadata fields and values 263, it will generate the menu specification from the metadata record field labels 289. In such an embodiment, the Autolinker would take each metadata record field label 289 (e.g., Author, Title) and specify them as being at level one 270 of the menu structure specification fields 265. Then level two of the menu structure specification fields 265 would come from the values 291 associated with the record field labels 289. Thus, by way of example, the field labels 289 from the metadata 263 are used to construct the level one menus 264, 266 of the MultiLink menu, and the metadata record values 291 are used to construct the level two menus 268, 269 and those sub menus 268, 269 will be associated with their respective record references 287. As such, if a user selects one of the references 269, the user will be taken to the reference target. These end-user selections and actions may be measured 226 and the metrics may be fed back 122 into the creation/maintenance of MultiLink menus, as will be described in greater detail in Figures 16-20. In another embodiment 220, the Autolinker may obtain the Web site map, the main menu at a Web site, Really Simple Syndication (RSS) feed, and/or the like structure from a users Web page server. For example, the Autolinker may examine the metadata for the most frequently accessed Web site address 287 and download the Web site information. In one embodiment, the Autolinker searches for HTML and/or XML tags in the Web page provided by the site for text matching “menu,” “site map,” and/or the like. Often Web sites have a menu structure as an overall theme of their Web site and this structure may be suitable for menu specification structure 265. For example, a Web site may have a menu comprising “Home, Products, Support, Help.” Each of those menus may have submenus as well, e.g., “Support” may have a “Contacts” menu item hierarchically subordinate to the “Support” menu. In such an embodiment, the Autolinker would compare such Web site menus and submenus to all of its metadata fields 289. The Autolinker would then create a specification 265 based on menu items from the Web site that match the metadata fields 289. In one embodiment, if Web site submenus match metadata fields 289, then the menu specification will adopt the hierarchy of the Web site map structure and the menu specification 265 generated will have those matched fields as being a submenu; they will be a submenu either to a matching parent menu. 
・  Moving from the flow diagrams for a moment, it may be useful to describe an example application to illustrate such automated Web site link construction. With regard to such an application, the Autolinker is given an RSS feed identifier. Such an identifier may be supplied by crawling Web sites for RSS links. Upon obtaining the RSS link, the feed components are retrieved. The components of the RSS feed are parsed. In one example embodiment, retrieval and parsing may be obtained by using a scripting language such as PERL as such:
・   
/* PRIMARY RESPONSE PAGE
*/
h.initNewHandle();
try {
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
//Document document = builder.parse("http://www.thirdstation.com/blog/?flav=rss");
Document document = builder.parse(blog.openStream());
org.w3c.dom.Element feed = document.getDocumentElement();
org.w3c.dom.NodeList channels = feed.getElementsByTagName("channel");
if(channels.getLength() > 0){
org.w3c.dom.Element channel = (org.w3c.dom.Element)channels.item(0);
org.w3c.dom.Element blogTitle = (org.w3c.dom.Element) (channel.getElementsByTagName("title")).item(0);
org.w3c.dom.Element blogLink = (org.w3c.dom.Element) (channel.getElementsByTagName("link")).item(0);
org.w3c.dom.Element pubDate = (org.w3c.dom.Element) (channel.getElementsByTagName("pubDate")).item(0);
org.w3c.dom.NodeList items = channel.getElementsByTagName("item");
・  Upon parsing the RSS feed into its constituent components, the components are identified and the component values are obtained based on specified values required by the Autolinker. In one embodiment, a menu specification may be used to establish which components and values are to be obtained. In one embodiment, this may be achieved with a script as such:
if(blogLink != null){
h.addValue(1,"URL", blogLink.getFirstChild().getNodeValue());
Log.debug("Added primary response page for doi="+doi);
}
if( blogTitle != null && blogLink != null){
h.addValue(indexCount, "MULTIRES", blogTitle.getFirstChild().getNodeValue().trim() + "=" + blogLink.getFirstChild().getNodeValue().trim());
h.addMapEntry(0, indexCount++);
}
if(pubDate != null){
h.addValue(indexCount, "MULTIRES", "Updated: " + pubDate.getFirstChild().getNodeValue() + "=#");
h.addMapEntry(0, indexCount++);
}
int postsIdx = indexCount;
h.addValue(indexCount, "MULTIRES", "Latest Entries=#");
h.addMapEntry(0, indexCount++);
for(int k = 0; k < items.getLength(); k++){
// Only take last ten entries
if(k == 10){ break; }
org.w3c.dom.Element currElement = (org.w3c.dom.Element) items.item(k);
org.w3c.dom.Element titleEl = (org.w3c.dom.Element) (currElement.getElementsByTagName("title")).item(0);
org.w3c.dom.Element linkEl = (org.w3c.dom.Element) (currElement.getElementsByTagName("link")).item(0);
org.w3c.dom.Element descEl = (org.w3c.dom.Element) (currElement.getElementsByTagName("description")).item(0);
String title = null;
String link = null;
String desc = null;
try{
title = titleEl.getFirstChild().getNodeValue().trim();
}catch(NullPointerException npe){
title = null;
}
try{
link = linkEl.getFirstChild().getNodeValue().trim();
}catch(NullPointerException npe){
link = null;
}
try{
desc = descEl.getFirstChild().getNodeValue().trim();
}catch(NullPointerException npe){
desc = null;
}
・  Once the components and values are obtained, those values may be added to form the basis of a MultiLink menu. In one embodiment, this may be achieved with a script as such:
if(title != null && link != null){
h.addValue(indexCount, "MULTIRES", title + "=" + link);
h.addMapEntry(postsIdx, indexCount++);
}
if( title == null && link != null && desc != null){
h.addValue(indexCount, "MULTIRES", desc + "=" + link);
h.addMapEntry(postsIdx, indexCount++);
}
}
}
}
catch (FactoryConfigurationError e) {
Log.debug("Unable to get a factory instance.");
}catch (ParserConfigurationException e) {
Log.debug("Unable to get a parser.");
}catch (SAXException e) {
Log.debug("Error parsing feed");
}catch (IOException e) {
Log.debug("I/O exception");
}catch(Exception e){
Log.debug("ERROR: " + e.getMessage());
}
} // blog != null
// CDI HOME PAGE
h.addValue(indexCount, "MULTIRES", "Powered by Content Directions=http://doi.contentdirections.com/?doi=" + CDI_REF_ID);
h.addMapEntry(0, indexCount++);
// EMAIL
h.addValue(indexCount,"MULTIRES","Email this Info to a Friend=mailto:?subject=Thought you might be interested...&body=I thought you might be interested in this blog: http://dx.doi.org/"+doi);
h.addMapEntry(0,indexCount++);
Log.debug("Setting index count to " + indexCount);
// LINK
h.addValue(indexCount,"MULTIRES","Add this Link to Your Site=http://doi.contentdirections.com/syndicator/?"+doi);
h.addMapEntry(0,indexCount++);
Log.debug("Setting index count to " + indexCount);
・  The figure 253 goes on to show the Autolinker having constructed a MultiLink menu from the live feed from a Web site, e.g., the New York Times. Should the user make a selection of one of the entries 253, they would be taken to the target of such a live feed 254. Similarly, the above RSS embodiment may also be applied to blogs, Web site root-level menus, and/or the like.
・  Moving away from the above RSS example embodiment and back to the discussion of Autolinker relationship generation 122, once the Autolinker generates a best guess menu specification 220, it obtains the specification of the menu structure 215. Having the menu specification 215 and the metadata fields 205, the Autolinker performs a match as between the two 225. Once the Autolinker identifies which metadata fields 205, 263 match 225 the menu specification fields 215, 265, then the Autolinker may begin pointer construction 124. 
・  Based on the matching fields 126, the Autolinker then searches the metadata database for field values 230. For example, in constructing a menu for the author 264, a match will occur based on the author field as the Autolinker is interlinking all the books by the same author; thereafter, the Autolinker will find each title by the author to populate the menu 266. The actual fields chosen for matching may depend on the menu specification and may comprise any number of metadata fields. As such, the Autolinker is searching based on the menu specification to populate menu submenus with metadata. For example, the metadata 105, 263, which may be stored in a database by the Autolinker, is searched by the Autolinker by using the matched menu specification fields 225. For example, the only common field as between the menu specification fields 265 and the metadata fields 263 are the “Title” fields 283, 281. The menu specification 265 would define a menu with a root menu “Menu Type” that was provided as part of the specification and submenus 275, which are not shown in the graphical menu. Another root menu is “Other Books By Author” 280, which contains the matching “Title” field 281. Based on this matched field 225, the Autolinker searches all records for all values and the result is the search returned values are shown as submenus 295.
・   As such, for each of the matching fields 235, the Autolinker obtains an associated reference pointer 287 which will form the basis of the MultiLink 240. Now that the Autolinker has pointers 240 for all the matched 225 field values 230, the Autolinker may commence with MultiLink creation 126. At this point a menu structure is populated 293, 295 based on the menu specification 265 and the matching field 289 values 291 from the metadata 263, however, the reference links for each menu item may not exist. The case where reference pointers are provided 287 as part of the metadata 263 and used by the Autolinker to supply pointers 240 for the MultiLink menu has already been discussed. However, in many cases, such references will have to be created and/or supplied to further the creation of MultiLinks as they will not be supplied by the customer 105. 
・  In one embodiment, every menu item would be supplied with a tracking pointer 288 in addition to the target reference pointer. The tracking pointer would be accessed to register how various MultiLink menus are accessed. For example, when a MultiLink menu is selected, the Web browser will be instructed to send usage parameters 288 (e.g., the end-user’s IP address, the item being selected (e.g., DOI, menu item ID, sub menu item ID, etc.), passed over menu items, and/or the like) to the tracking server via HTTP post command, while the end-user’s Web browser receives the target reference address 287 and allows the end-user to navigate and view the material at the target reference address 287. In one embodiment, the tracking links create parameters that are appended onto the tracking address 288. These parameters may be used to assist in the tracking of end-user activities. In one embodiment, the Autolinker will generate parameters that include a DOI, a menu specification ID, and a hierarchical tag for each menu item. For example:
・  http://www.trackerserver.com/postvalues?doi://10.1009/0395960789?menuID:12345?hover:4:menuTier:1:2?hover:2:menuTierClick:1:3
・  Here the tracking server is “www.trackerserver.com,” the DOI being tracked is X, the DOI’s menu specification has an ID of Y, and the last tag refers to a menu selection. In the above example, the menu’s first tier’s menu selection “Author” 264 was selected and then its second menu item in the second tier “Dickens” 269 was selected, which resulted in the posting of the “…?menuTierClick:1:3” parameters to the tracking server. In this example, the “1” represents the MultiLink menu’s first selection item in the first tier of the menu hierarchy, and the “3” represents the menu’s third selection item in the second tier of the menu hierarchy. The “hover:2” portion of the parameter may indicate that the user hovered two seconds prior to clicking on the third menu selection. Similarly, the “hover:4” portion of the parameter may indicate that the end-user hovered over the second menu item in the second menu tier for four seconds. As such, every single menu item will be given a code relative to its order in a given tier and any menu item in the hierarchy may be identified. In one embodiment, these menu selection IDs are stored as part of the menu specification. The tracking links 288 will be discussed in greater detail in Figures 16-20. 
・  In one embodiment, media code 289 may be used where the supplied link 287 and any tracking links 288 are embedded within multimedia objects that displayed 290 within menu items 295. For example, Flash, animated gifs, video files, etc. may be used and displayed 290 within menu items thereby making the menu items more engaging 295.
・  In one embodiment, a Flash animation may be embedded in a menu as such (see 1605 of Figure 16 for the accompanying example):
<object classid=\"clsid:D27CDB6E-AE6D-11cf-96B8-444553540000\"
codebase=\"http://download.macromedia.com/pub/shockwave/cabs/flash/
swflash.cab#version=6,0,0,0\" width=\"185\" height=\"32\"
ID=\"Shockwaveflash1\" VIEWASTEXT><param name=\"movie\"
value=\"images/CrossFireAnimation2.swf\"><param name=\"quality\"
value=\"high\"><param name=\"bgcolor\" value=\"#FFFFFF\"><embed
name=\"CrossFireAnimation\" src=\"CrossFireAnimation.swf\"
width=\"165\" height=\"32\" quality=\"high\" bgcolor=\"#FFFFFF\"
type=\"application/x-shockwave-flash\"
pluginspage=\"http://www.macromedia.com/go/getflashplayer\"></object>
・  In one embodiment, a video may be embedded in a menu as such (see 1610 of Figure 16 for the accompanying example):
<div id=\"divMovie\"><OBJECT id=\"movie1\"
onmouseover=\"javascript:PlayIt();\"
onmouseout=\"javascript:StopIt();\"
codeBase=\"http://www.apple.com/qtactivex/qtplugin.cab\"
height=\"120\"
width=\"180\"
classid=\"clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B\"
VIEWASTEXT><PARAM NAME=\"src\"
VALUE=\"http://www.darnellworks.com/a52/media/crosfire.mov\"><embed
width=\"180\" height=\"120\" target=\"myself\" bgcolor=\"#000000\"
border=\"0\" controller=\"true\" EnableJavaSript=\"true\"
autoplay=\"false\" kioskmode=\"true\"
src=\"http://www.darnellworks.com/a52/media/crosfire.mov\"
pluginspage=\"http://www.apple.com/quicktime/download\"> </embed>
</OBJECT></div>
・  In one embodiment, a menu item may assemble a composite of media and information as such (see 1615 of Figure 16 for the accompanying example):
<div align=\"center\" style=\"width: 180px; background-color:
#ffffff;\"><IMG height=\"48\" width=\"77\"
SRC=\"images/crossfire1.jpg\"><br><font size=\"1\"
color=\"black\">2005
Crossfire Coupe Limited<BR></font><font size=\"2\"
color=\"black\"><B>$34,620.00</b></font><br><font size=\"1\"
color=\"gray\">VIN: 1C3AN69L15X035266</font></div>
・  At this point the Autolinker has at least four ways of furthering the creation of MultiLinks, one of which 250 was already discussed 240. In the instances where the customer supplied reference links 287 with the metadata 263, the Autolinker may simply choose to use those supplied links to generate the DOI MultiLink record with appropriate references 250. 
・  There are several other ways to obtain references to content related to the metadata records 263. In one embodiment, a customer’s Web site and/or database structure is reverse engineered 245. This embodiment, generally, requires human analysis. In this embodiment, a Website’s product querying format is discerned and used to find products. For example, the United States Patent and Trademark Office (USPTO) government Web site, e.g., www.uspto.gov, has a syntax that may be employed to find object targets. For example, if a reference is needed for a target patent based on a patent application title, e.g., “Registration effecting information access” and the inventor’s name, e.g., “Sidman,” then the following reference may be used to obtain the appropriate reference from the USPTO:
・   
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.html&r=1&p=1&f=G&l=50&d=PG01&S1=%28sidman.IN.+AND+%28%22registration+effecting+information+access%22.TTL.%29%29&OS=in/sidman+and+ttl/%22registration+effecting+information+access%22&RS=(IN/sidman+AND+TTL/%22registration+effecting+information+access%22)
・  The underlined portions show where metadata field values 291 are inserted so as to reference the proper patent application. In the above case, the USPTO’s query structure was reverse engineered so that when a values for the title and inventor fields are supplied from the metadata record field values 291, the proper patent application reference is obtained; in this case, the reference link for Patent Application No. 20040163020. Numerous Web sites and database have such discernable query formats, e.g., Amazon.com. 
・  In another embodiment, a customer may simply provide a query Web page and/or query prompt into which metadata field values may be provided 255. The query fields may be populated in a number of ways. In one embodiment, they are populated manually. In another embodiment, a Web browser’s auto-fill functionality is filled through an API, and is engaged upon the Web page form being loaded. In another embodiment, the prompt and/or Web form is filled through interapplication communication via APIs. In another embodiment, a macro playback utility (e.g., Quickeys) may pull values from a file and repeatedly feed values into query fields and effect the forwarding and/or saving of reference links. In still another embodiment, a scripting environment as provided via PHP, Javascript, Python, TCL, and/or the like may be employed to pull field values from a file and repeatedly feed the values into query fields and effect the forwarding and/or saving of reference links. 
・  In yet another embodiment, all of the field values for a given metadata record are put into a search prompt to generate a response 260. In such an embodiment, the metadata values would be logically-OR’d so as to rank results with greater weight when more terms are encountered in the search. In one example, the metadata values may be fed into a search engine, e.g., Goole.com, and the top link can be selected as a reference link 260.
IntraConnector
・  FIGURE 3 is of a mixed data and logic flow diagram illustrating embodiments of an IntraConnector. A portion 380 of Figure 3 shows a more localized variant of the system described in Figure 2. In this embodiment, the global DOI directory 113 is still available and distributed over numerous DOI resolution servers available from across a communications network; it serving to resolve DOIs from any requesting entity. More specifically, an intranet embodiment where a customer may have their own local DOI directory 305 running on local DOI server(s) 333 is shown. In one embodiment, the Local DOI server also acts and/or is connected to a communications gateway out providing access to a larger communications network, e.g., the Internet. Here, we see that link creation 110 as provided by an Autolinker and/or Handle editor supplies DOIs to the local DOI directory 305 and not to the global directory 113. As such, although the local DOI directory may make requests for DOI resolution from the larger global directory 113, and that larger global directory may provide results for that resolution request, nevertheless, should the global DOI directory 113 or any other entity make requests of the local DOI directory 305, the local DOI directory would not provide any resolution information. In an alternative embodiment, users may wish to provide access to their intranet to the outside world and may enable outgoing resolution, either globally and/or by password and access control.
・  A component in the architecture is a master metadata repository 319. In one embodiment the master metadata repository may be an enterprise content catalog. It should be noted that although publishers and content catalogues and the publishing field are used herein for purposes of illustration, the IntraConnector may be employed in any number of contexts and is not limited to the publishing field. For example, the IntraConnector may be used in any kind of company with any kind of information, including: product companies with product catalogs; healthcare companies (e.g., hospitals with patient-related information, case-related medication-related information, etc.); service companies with customer records; government agencies with any kinds of records; and/or the like. The IntraConnector may also be deployed in situations where the information being interrelated spans multiple independent departments, divisions, companies, organizations, systems, technology platforms, or other interlinking targets. Organizations may use the IntraConnector to interrelate internal information and yet combine in with external information that it wishes to associate with its internal information, or to otherwise make accessible to its users or programs. Examples include internal knowledge management applications, where an organization may want to interrelate internal information (e.g. documents used in the R&D process) and/or external information (such as external news and research relevant to this R&D activity, and/or competitor information). A content catalog contains at least two types of information: unique identifiers for each content item in the catalog and metadata that describes each content item. The IntraConnect architecture may utilize an existing system that a content publisher already has in some form, e.g. a content catalog, and which the content publisher may wish to use it as the basis for the publisher’s enterprise content integration (ECI) deployment. In another embodiment, the master metadata repository may be based on an existing vendor-supplied system such as Canto Cumulus 175, Documentum, Vignette, Artesia TEAMS, etc. This system may be hosted and operated within the customer’s own control, or it may be provided on an Application Service Provider (ASP) basis. This gives publishers the advantage of using an existing system, with which users are already comfortable, and the development of which has already been funded, instead of the usual document asset management (DAM)-based approach which requires implementing a new user interface. For example, book publishers typically have product catalogs, title databases, or even systems that use ISBNs as the unique identifiers and contain various types of metadata about books. Users can search and browse these systems. As we will see, such systems can be extended into use as master metadata repositories in a IntraConnect implementation. If no content catalog exists, or if it exists but only as an unstructured repository of information (such as individual files distributed on multiple computers) and not as a structured database, then it may be created for the purpose of serving as the master metadata repository. Although discussions herein use books/publishing as an example, the principles apply equally to other types of businesses, many of which have standard identification schemes, such as ISSNs for serials, ISRCs for music products, CUSIPs for securities, UPCs for physical products. Other businesses or organizations may use non-standard, proprietary identification schemes that may only have meaning internally within the organization, within the technology system, database and/or other internal systems. Other businesses or organizations may also require an IntraConnector to interlink related information or objects that do not comprise content, but instead include database records, personnel records, sales records, commerce transactions, authentications, identity verifications, sensors, or any other kind of systems, information and/or objects.
・  An example publisher has an array of database systems 119. The product catalog may be built on a multi-user database and may have a Web browser-based user interface. In addition to the product catalog, publishers might have one or more types of systems that store actual content, not just descriptions of it, such as departmental DAM systems, file servers, image libraries, and so on. They will also have back-office systems that track business aspects of content, such as author contracts, rights and permissions, royalties, sales, and marketing information.
・  The IntraConnector includes components that turn the publisher’s product catalog into a Master Metadata Repository 319 for an ECI implementation, the components including: UI extensions to retrieve assets and metadata 371, DOIs stored in the master metadata repository 372, and the link creator 110 and connectors to their database systems 320 provide the intraconnections. To that end, the IntraConnector adds DOIs to the entries in the publisher’s content catalog and to create links from each DOI to all of the systems that store information about the asset that the DOI references. In this manner, the Autolinker may be supplied with actual links 250. Links can be simple URLs, or they can be invocations of complex scripts that make calls to a system’s programming interface in order to retrieve information. The IntraConnector includes a connector component 320 that implements the latter types of interfaces to commonly-available systems, such as relational databases, file servers, DAM systems, etc. The Link Creator 110 component builds all of these links and stores them in a Local DOI Directory. In one embodiment, the link creator 110 may be either the Autolinker 120 and/or Handle editor 115; in addition, the link creator may employ DOI link creation for unique content. As an example, a book publisher may have a title database that contains ISBNs. The publisher may store the actual book content in a DAM system and has separate systems for author contracts and sales tracking. A DOI can be created from any type of pre-existing identifier, and it can point to several different links in a DOI Directory. 
・  In one embodiment, the publisher could create a DOI from each ISBN in the title database. For each of those DOIs, it could have one link to the content in the DAM system, another to author contract info in the contract system, and a third to sales info in the sales tracking system. Examples of such DOIs are generally shown 370 in tabular form in Figure 3. The DOI 342 is associated 343 with its three links 344 stored in a DOI directory 113. Once all of the links have been created, then users can go through an extended user interface to follow the links to information in whichever systems they need, as has already been shown 175, 293, 295 in Figures 1-2 and will be discussed in greater detail in Figures 5-6. The IntraConnector User Interface Extensions 371 enable the product catalog to go well beyond providing simple metadata search and browse functionality: by incorporating DOI MultiLink menus, they enable users to actually retrieve the assets and other types of metadata for a given content item by going through the links in the DOI directory 113, 305. This provides some of the functionality to turns a publisher’s content catalog into an Enterprise Content Integration application, thereby dramatically increasing its functionality. Other components of the IntraConnector include connectors 320. These are the “glue” that turn a DOI link into a working interface to a given system. For example, a connector 320 to a DAM system 322 would take as input the identifier that the DAM system uses to identify a content item internally and invoke the DAM system’s API calls to retrieve that asset. Figure 3 shows two different connectors used to implement the three links. The first link uses a connector 343 for a DAM system (e.g., Artesia TEAMS, Documentum, QuarkDMS, Canto Cumulus 175 and/or the like) called “Virgo” that stores book content and identifies it by ISBN 346. The argument RetrieveAsset to the connector tells it to retrieve the actual content identified by the given ISBN. The second link invokes a connector for the Oracle relational database 347, which is presumed to be the platform on which the publisher has built its contract management system, which the publisher has named “Libra.” The connector’s argument RetrieveContractInfo, presumably developed specifically for this publisher’s contract system, invokes the appropriate SQL queries to retrieve info about the contract for the author whose name is given for the book whose name is given. Note that the contract system doesn’t store contracts by ISBN but rather by author and title, because a contract for a given author and title can cover multiple ISBNs. The third link also invokes the Oracle connector 348, this time on the publisher’s sales tracking system, which is called “Aquarius.” The sales tracking system uses ISBNs to identify products.
・  An IntraConnector may be implement some of the following mechanisms for a publisher. In one embodiment, a user may search and browse metadata in a master metadata repository 113 through its user interface 371. The user may invoke the search and browse interface of the publisher’s existing product catalog or other metadata repository. When the user identifies some content of interest and wants to retrieve it: the user can select/click on the asset’s name or identifier to view a menu of options, which are DOI MultiLinks. One of the options might be “Retrieve Asset.” If the user selects that option, then the DOI link associated with the “Retrieve Asset” function contains a call to the connector 320 for the publisher’s DAM system (which is described in greater detail throughout Figure 3 360), along with the ID that the DAM system uses internally to identify the asset. The asset’s MIME type determines which application should be invoked on the user’s machine to view, play, or edit the asset once it is retrieved. The user may then identify some content of interest and want to look at a preview or thumbnail of it. To do so, the user clicks on the asset’s name or identifier to view a menu of options, which are DOI MultiLinks. One of the options may be “View Thumbnail/Preview.” If the user selects that option, then the DOI link associated with the “View Thumbnail/Preview” function contains a call to the connector 320 for the publisher’s DAM system, which stores preview or thumbnail renditions of assets, along with the ID that the DAM system uses internally to identify the asset. The preview or thumbnail’s MIME type determines which application should be invoked on the user’s machine to view the preview or thumbnail. For example, if it’s a GIF image thumbnail, then the user’s browser could open a new small window displaying the thumbnail. If the publisher’s DAM system does not store thumbnails, then the link could be set up to invoke a “read-only” application on the user’s machine instead of an editing application. Then, should a user care to identify some content of interest and wish to view the author’s contract information, then the user may select/click on the asset’s name or identifier to view a menu of options, which are DOI MultiLinks. One of the options may be “View Contract Info.” If the user selects that option, then the DOI link associated with the “View Contract Info” function contains a call to the connector 320 for the publisher’s contract system, along with the ID that the contract system uses internally to identify the work. The connector 320 implementation invokes the user interface 371 of the contract system, passing it the ID of the contract to be viewed. In an alternative embodiment, the connector implementation may read information from the contract system and display it in the user’s Web browser.
IntraConnector Integration
・  An example deployment 360 is generally shown comprising: customer environment assessment 330, Master Metadata Repository (MMR) selection 335, content integration setup 340, server installation 345, DOI and link creation 110, 350, and UI enhancement and system testing 355. 
・  With regard to customer environment assessment 330, the publisher’s data and network infrastructure 119 are examined to determine levels of effort and feasibility in implementing the IntraConnector. In one embodiment, this may comprise of the following: inventory of the systems to be integrated 331, determining the feasibility of integration 332, and assessing the network environment 333. Inventorying the systems 331 may include identifying the content catalog to be used as the Master Metadata Repository 319, asset repositories 119, including DAM systems 322, file servers, etc. Other systems to be inventoried may include ancillary information systems, e.g., rights, permissions, contracts, sales, and marketing. With regard to determining the feasibility of integration, the level of manual link creation that will be required is determined by assessing the quality of the publisher’s identifiers and metadata according to these criteria 332: quantity (i.e., is there enough metadata to identify assets and other product information on all relevant systems?); consistency (i.e., are the same terms used for the same purposes across systems?); and identity uniformity (i.e., do common identifiers or metadata keys identify the same things on different systems?). Assess the publisher’s network environment according to such criteria as 333: (i.e., are all of the systems to be integrated accessible from all of the relevant users’ desktops); (i.e., are there any network performance issues that would hamper movement of assets across subnets?) 
・  In choosing and modifying the Master Metadata Repository (MMR) 335, the publisher is assisted in identifying a system to be used as the MMR. In one embodiment, this is an existing system that the publisher uses to store and maintain key content and product information, such as a title database, product catalog, Web product catalog, or even an ERP system that stores product data. Conforming to a set of architectural elements facilitates in the making of the MMR. Some of the architectural elements and considerations include: employing a relational or other multi-user database; employing a Web browser-based user interface; and having entries for most or all of the relevant content. The MMR should be modified to store DOIs for each content item. If it is not possible to actually modify the system (i.e., add a field to the database schema), then it is possible to create “virtual” DOIs that are based on an existing ID scheme (e.g., ISBNs). In such a circumstance, the Local DOI directory 305 may be built to understand a convention that turns ISBNs into DOIs in a fixed, predetermined way. For example, in one embodiment, the customer’s organization is assigned a pool if DOIs for use. The customer would then create a numerical association table of ISBNs to the individual DOIs in the pool. In one embodiment, ISBNs would be sorted numerically and associated to the sorted pool of DOIs numerically. In this manner, the IntraConnector can help to modify a publisher’s product catalog into an MMR. If the publisher does not have a satisfactory product catalog system, then one may be created based on a third party’s Metadata Database (e.g., a DOI registration agency like Content Directions Inc., which it uses for registering its customers’ DOIs in the Global DOI Directory). 
・  With regard to content integration setup 340, connectors 320 are created for linking DOIs with the publisher’s asset repositories and ancillary information systems 119. To this end, several parameters for each system to be integrated are compiled. These parameters include: type of system (e.g., relational database, DAM system, file server, etc.); type of software (e.g., Oracle, Artesia, FTP server, etc.); server platform (e.g., local system name, operating system); conventions that the system uses to identify entries; and the action to be taken when the user invokes the link, such as retrieve data from specific fields. Once this information is compiled for each system in the ECI implementation, it will be stored in a table in the Link Creator 110. In one embodiment, this information is automatically compiled by employing a standard connector for an Oracle database. This connector can query for the overall topology of a customer’s database system resulting in a complete entity-relationship topology including all tables, field names, and key fields. In one embodiment, the system observes where the greatest number of records exist through a record count and then employs the key field for that type of record for association with DOIs. In such an embodiment, DOIs may be generated for each such key field. In one embodiment, a DOI field is added to the database table and associated DOIs are added directly to the database and thus may be found through database queries. In another embodiment, an intermediary table is created with the key field and a DOI field, and may be used to join and select records in the table responsible for the greatest number of records on the customer’s database. Such information may then be used to instantiate connector code for each system. 
・  With regard to server setup 345, in one embodiment, any machine that can run Java applications will work. However, any number of development frameworks may be used. In one embodiment, the server is loaded with a Local DOI Directory 305; connector code, instantiated for the publisher’s specific systems according to the above parameters 320; Link Creator 110; and administrative tools. 
・  DOI and Link Creation has been discussed already in Figure 2 and throughout. However, the IntraConnector also may participate in link creation for asset repositories and ancillary information systems. As has been discussed, the Autolinker automates as much of the link creation as possible by finding correspondences between an entry in the Master Metadata Repository and entries in other systems - by matching pre-existing ID numbers or other keys (such as title and author). After the Link Creator runs, the IntraConnector can assist publishers by providing results for manual review of DOIs and links for quality control purposes. Publishers with high quality, consistent metadata will find that the quality control task takes little time. 
・  In one embodiment, the IntraConnector may establish a maintenance schedule for the links. Two regular basis maintenance activities may include: Link Harvesting (e.g., running the Link Creator periodically to search the MMR and other systems for new entries, and creating new DOIs and links accordingly); and Ping Testing (e.g., running a program periodically that tests all of the links to make sure they are still valid). Details regarding quality assurance and ping testing are described in US Patent Application Nos. 10/470,206 and 10/470,207 and are herein incorporated by reference. 
・  As has already been discussed in Figures 1-2 and elsewhere, an enhanced user interface, i.e., the MultiLink menu 175, is available and in this case used by the IntraConnector as well. As such, the user interface of the MMR may also be enhanced 355 so that it allows users to navigate through DOIs to all other linked systems. If the MMR’s user interface for searching and browsing is browser-based, then the IntraConnector adds DOI link menus as JavaScript code. The code retrieves the DOI from the DOI Directory and then displays the links in a menu format.
・  For example, search results display 356 are modified so that when the user clicks on an entry in the results list, or mouses over it, a DOI link menu appears 357, allowing the user to navigate to the asset, to a preview or thumbnail, or to other information. This intuitive user interface enhancement a type of “glue” that ties the IntraConnect system together from the user’s perspective. 
・  In addition, after the IntraConnector is deployed, a publisher may wish to register some of the DOIs created as part of the process to the Global DOI Directory 113. For the content assets referenced by those DOIs, registration will enhance their discoverability and help the publisher implement a wide range of possible online content services - all of which would then be readily integrated into the publisher’s content infrastructure. 
MultiLink Syndication
・  FIGURE 4 is of a logic flow diagram illustrating embodiments of an MultiLink syndication. For MultiLink syndication to proceed, MultiLinks need to be generated 120. Generation of MultiLinks has already been discussed (e.g., the Autolinker) in Figures 1-2 and throughout 120. Once the MultiLinks are generated, they are stored in the Handle system 130. These may be stored in either or both a global DOI directory 113 or a local one 305. In the case of a local DOI directory, syndication may spread the links widely, but only people with access to the local system will be able to reference and/or otherwise access the referenced content assets. Link generation and storage is an activity unto itself that may continue independently as long as there is a desire to generate MultiLinks for content assets; as such this may proceed 450, 120 as long as required and independent of the following components of syndication 450, 415, et seq.). If MultiLinks are stored 450, then references to the MultiLinks may be generated 415. As has already been discussed, scripts may be generated to provide a reference to the MultiLink. In one embodiment, the reference is generated by embedding a link to a Syndicator in a call for a script, e.g., Javascript. It should be noted that the Syndicator itself may be identified with a DOI. In addition to the Syndicator link calling Javascript, an identifier of the MultiLink is put into the reference. Once the MultiLink reference has been generated 415, the reference may be embedded into content; for example it may be embedded as HTML into a Web page 420. In another embodiment, the references may be embedded into MIME and/or HTML formatted email. By embedding references to the MultiLink, propagation of the MultiLink may commence. This generation and embedding is also an activity unto itself that may continue independently 451 as long as there is a desire to spread word of the MultiLink and it is independent of the following components of syndication 451, 525, et seq. However, once the references have been embedded 420, 451 or if there is no desire to reference more links 451, then traversal through MultiLinks becomes possible 425. 
・  Once the MultiLink references are embedded in content 420, when a user and/or system traverses upon the content with the reference, the retrieval and viewing of the content engages the embedded reference and accesses the Syndicator 425. The Syndicator receives a request for the MultiLink reference and for a script to provide the MultiLink menu. In one embodiment, upon receiving the request, the Syndicator accesses the DOI directory for the referenced MultiLink 430. In so doing, the Syndicator requests the MultiLink record from the DOI directory. The Syndicator then determines if a menu specification is available for the MultiLink. In one embodiment, the Syndicator searches its own database for a MultiLink menu specification by employing the MultiLink DOI as a search query. As will be discussed in greater detail in Figures 16-20, the menu specification may be augmented by making use of end-user activity tracking 467. In one embodiment, tracking statistics are captured dynamically and continuously and used to automatically augment menu specifications 467. In another embodiment, augmentation of menu specifications occurs periodically, e.g., updated at specified intervals with cron jobs. If the Syndicator finds a menu specification 466, then it retrieves the menu specification for the MultiLink 468, otherwise the Syndicator will generate a menu specification for the DOI record based on its hierarchical structure 470. The menu specification and generation was already discussed in Figure 2 220 and throughout. After the menu specification is generated it may be stored in the Syndicator’s database. In one embodiment, the menu specification may be saved in the MultiLink record in the DOI directory along with the Javascript code required to render the MultiLink menu. This may be achieved by adding the entries into the MultiLink record for the menu specification and the Javascript code each, which will be shown in greater detail in Figures 5-6 and throughout. Once a menu specification has been obtained 468, 470, the Syndicator will generate a MultiLink menu populated with the respective MultiLinks as specified by the MultiLink menu specification. This already has been discussed in Figure 2 277. Further to that discussion, Javascript, Java, Python, Perl, and any number of scripting languages may be used to call upon graphics libraries to actually build and display a pop-up menu widget populated with menu items from the menu specification, responsive to user selections following the MultiLink references. Using the scripting language call to a UI widget call for a menu, the menu specification items are placed into the code calling for the widget so that the UI pop-up menu widget displays the items specified by the MultiLink menu specification. For example, HierMenus (<http://doi.contentdirections.com/mr/cdi.jsp?doi=10.1220/product1>, <http://www.hiermenuscentral.com >) by Peter Belesis may be used to generate the pop-up as specified by the menu specification.
・  Once the code has been generated, it is provided back to the requesting client and the client’s Web browser may then interpret the code and display the MultiLink menu with resolved targets 435. Should the user traverse the MultiLink menu and engage any of the MultiLink menu items 440, then the users Web browser will be instructed to traverse to the item’s corresponding MultiLink reference, thereby, resulting in the Web browser displaying the target of the MultiLink 445. Should the user encounter more embedded MultiLink references 452, then they may continue traversing content 425, otherwise syndication of the MultiLink has been successfully achieved 486.
・  Another aspect of the Syndicator is its ability to generate MultiLinks and menus for wide distribution. In one embodiment, a user may have an “Add this Link to Your Site” menu item, which permits viral distribution of DOI MultiLinks by enabling any end user who encounters a DOI anywhere to simply “Add this Link” (see 667 of Figure 6) to their site by copying/pasting generated HTML (see 669 of Figure 6) to their own Web page. As such, when a user selects the “Add this Link” menu option, they are taken to the “Syndicator” page (see 669 of Figure 6) where they may then copy/paste the two lines of HTML (see 669 of Figure 6) in order to place/embed the HTML on their own site so that the DOI menu will now be rendered by the Syndicator on their own site. In another embodiment an “Email this DOI to a friend” menu selection (see 1507 of Figure 15) will provide the user with the DOI link (e.g., by placing the DOI into clipboard memory, and/or by messaging the user’s email client to make a new email and pasting the DOI into the subject and/or body of the email). Details regarding viral and P2P distribution are described in US Patent Application No. 10/470,206 and are herein incorporated by reference. For example, the content itself (and/or its DRM wrapper, if there is one) may contain a DOI MultiLink, and therefore being capable of prompting the user to “Add this Link” to their site. In one embodiment, the “Add this Link” and/or “Email this DOI to a friend” options are generated as part of the MultiLink menu specification by default, and as such, every MultiLink would offer them as menu options. In such an embodiment, there are many scenarios in which these ad-hoc features can be utilized, i.e.: embedded within content itself (and/or its DRM wrapper) as just described; finding a DOI within search engine results; seeing a DOI on a Web site; receiving a DOI via a direct-marketing email; receiving a DOI via a hospital and/or doctor’s notification (see 1505 of Figure 15); seeing a DOI within the “now playing” window of a music player or video player (see 1510 of Figure 15); embedding it in someone’s contact info (e.g., within an email or within a document such as a resume or a proposal); receiving it via a personal email. 
Handle Editor
・  FIGURES 5-6 are of diagrams illustrating embodiments of a MultiLink menu editor and personal DOI. The figure shows a Web browser 501 viewing a Web page with an embedded MultiLink 514, 515. The embedded code 514 actually results in the image 515 responsible for generating the MultiLink menu 510. As a user moves their cursor over the image 515, the MultiLink menu 510 will manifest itself as has already been described. The makeup of the MultiLink menu is controlled in large party by the menu specification and the MultiLink’s DOI record. As has already been discussed, should a menu specification not exists, one can be generated from the MultiLink DOI record. As has been discussed, an Autolinker and/or the Syndicator may generate a MultiLink menu specification as needed. Further, a MultiLink editor may also generate a menu specification and in addition, it may modify the DOI MultiLink record in the DOI directory.
・  Figure 5 introduces a MultiLink editor 520 as accessed via a Web browser 501. In one embodiment, the user engages the MultiLink editor 520 by directing their Web browser 520 to the appropriate location to edit a handle 577. As will be discussed in greater detail in Figures 16-20, the MultiLink editor may be used to modify menu entries as driven by end-user tracking, by advertising placement, and/or the like. Allowing those responsible for the MultiLink menus to hand-edit the menus upon reflecting on tracking information will improve their efficacy. Once at the MultiLink editor, the user may specify the handle record that they wish to edit by supplying a DOI 577. Upon signing into the MultiLink editor (e.g., by supplying a username and password to gain access to DOI records in the DOI directory), the user supplies a DOI reference and the DOI directory will access the DOI MultiLink record and display it 525 in the Web browser. The editor provides various facilities to edit and access 555 and make changes to 527, 540, 545 the constituent elements 530, 535 of the DOI MultiLink record 525. 
・  In addition, the MultiLink editor provides a mechanism, e.g., check boxes 533, to generate a MultiLink menu specification. In one embodiment, the checkboxes 533 are all enabled by default, and as such, when an Autolinker, Syndicator, or the MultiLink editor are called upon to participate in generating a MultiLink menu, and if there is no MultiLink menu specification available, all entries in the MultiLink record 525 that have enabled checkboxes 533 will be used to generate the menu specification, while all unselected checkboxes 534 will not be a part of the menu specification. As such, by adding a menu_view_specification field 533 in the MultiLink record, every MultiLink record may have a master menu specification. It should be noted, that alternative and/or added menu specifications may simply be added as additional links into the MultiLink no different than adding a “Contact Info” 530 link. 
・  In addition, the MultiLink editor provides a facility for access control 544. MultiLink owners may limit access to certain links to certain groups. For example, certain links may only be accessed by the owner, other links accessed by groups known to the owner, and yet other links may be accessed by everyone. In one embodiment, this is achieved by providing a link entry specifying origin points that are allowed to access the link. For example, if a user wants all his friends at a particular company to have access to a link, then they might provide a domain of www.friendscompany.com as being the only origin point for which the link will be displayed. Thus when a DOI directory and/or Syndicator is participating in the resolution of a MultiLink, it may determine that the request is, or is not coming from a point of origin for which a MultiLink should be viewed; and thus the menu specification may be edited on the fly disabling the entry for points of origin not specified in an access control field entry for a link. In another embodiment, an IP address may be used as the point of origin. In yet another embodiment, a user name and password may be associated with the link, and only those that can supply the username and password will have the link shown. In yet another embodiment, points of origin will be represented by personal DOIs. Another embodiment may use digital certificates and/or keys as a basis for validation; details regarding such digital rights management (DRM) implementations are described in US Patent Application Nos. 10/470,258 and are herein incorporated by reference. As is shown 525, a MultiLink record may represent a person by containing various links pointing to personal information. As such, personal DOIs may be specified as the points of origin for the access control, and users accessing the access controlled links that are known to be coming from points of origin specified in their personal DOIs may gain access. For example, this type of access control is important in the case of patient records, where patients want to control who has access to their medical information. 
・  As may be seen, the personal DOI record 525 contains various links as supplied by the user to represent their person. The MultiLink editor 520 allows a user to edit any MultiLink record. In one embodiment, the editor 520 provides a mechanism to add new record fields 540 and field values 545. For example, should a user wish to add an entry showing their favorite law firm, they may add by specifying the new field name in the editor facility, e.g., textbox, 540. By entering a label 540 and no reference link, e.g., URL 541, the MultiLink editor will create field category with no values other than the provided label. As such, this can generate a first level menu item, under which submenus may appear. To that end, the editor 520 provides a facility to enter subfields 545 and values 546. In the figure, the user entered “Morgan & Finnegan” as a label for a type of “Favorite Law Firm” and also provided a reference link “www.morganfinnegan.com” 546 for the entry. Upon receiving these entries, 540, 545, 546, and upon the user engaging a “Submit” button, the MultiLink editor 520 sends the supplied information to the DOI directory as an instruction to add the appropriate fields to the user’s DOI MultiLink record. As can be seen in Figure 6, once the new fields and values have been submitted, they have been added to the user’s DOI MultiLink record 525 and show up 540, 545, 605 as part of the MultiLink record. In one embodiment, a user may add a personal DOI to their email signature, and this would provide others with access to the person’s contact and other information through a single link.
・  The MultiLink editor 520 may manipulate the DOI MultiLink record 525 in a number of other ways as well. As has been mentioned, the editor 520 provides various facilities 555 to edit the record and any metadata. Should a user choose to edit the record 555, a number of options are provided 605, 615, 620, 625, 630. The user may change the primary response page 605, add new items 615 and menus 620 to the record (as has already been discussed), reorder the record’s values, and perform various other edits (e.g., cut, copy, paste) 630. For example, should the user wish to reorder the values in the MultiLink editor, and thus affect the ordering of any subsequent menu specifications, they may engage the option to reorder the record values 625 and will be presented with a facility to rearrange the value order 650. By selecting the “Up” or “Down” buttons next to record values, the record order and any subsequent menu specification and thus menu order will be affected. As can be seen, after the above additions and rearrangements of the DOI record values, a menu generated from the menu specification resulting from the DOI record will have the additions and proper menu item ordering 665.
・  Momentarily skipping to FIGURE 18; it shows a diagram illustrating graphical embodiments of a MultiLink menu editor. This alternative embodiment shows the MultiLink menu editor 1805 and the construction of a resulting MultiLink menu 1810. The editor allows for the creation of additional menu selection items 1825 in each menu tier 1830 of the menu hierarchy. Menu items may simply selected and the contents may be edited. In addition, usage constraints may be placed on any given menu item 1835. For example, a menu item may be placed so that it will remain in its position for a specified duration (e.g., 250 impressions, 50 clicks, 2 months, etc.) 1835. In one such an example, once the menu item is viewed by 250 end-users or clicked 50 times, it will be removed from its position and replaced. Such constraints are useful for advertising models and the rotation of advertising. In one embodiment, these constrains are added automatically in a “Constraints” field with the generation of a menu specification. In such an embodiment, the Autolinker may set limits for impressions and click-throughs based on sponsorship of menu items. For example, advertisers might bid for placement of menu item ads, ad words, multimedia commercials, and/or the like. The Autolinker will be provided with menu items based on the advertiser’s payments for ads. As tracking information is maintained, usage statistics may be compared against the usage constraints, which will cause a change in menu items. Rules may be established as to what happens when usage constraints are reached. In one embodiment, when usage constraints are reached, the menu item is removed from the MultiLink menu. In another embodiment, when usage constraints are reached, the menu item is moved to a less prominent location within the MultiLink menu hierarchy (e.g., it may be moved down and/or deeper within the hierarchy).
IP ADDRESSING
・  Moving back from Figure 18 to Figure 7, users access communications networks through addresses. Addresses represent locations. Users traverse locations in a communications network hoping to find information. A common communications addressing scheme employs the IP address. The IP address may be likened to the real world by analogy to a street address. The IP address itself is a sequence of numbers, e.g., 209.54.94.99, and commonly has an associated name, e.g., www.contentdirections.com. A distributed database registry maintains the associated pairs of names and IP addresses and serves to resolve associated names into corresponding IP addresses. This allows people to remember and use names, e.g., www.report.com, instead of being forced to memorize and use a series of numbers, e.g., 209.54.94.99. These distributed databases assisting in the name resolution of IP addresses are commonly referred to as Domain Name Servers (DNS).
・  It is common for IP addresses to be embodied as Universal Resource Locators (URLs) that append even more navigation information into an address. Users may employ software to access information stored at URLs through the use of HTTP. An example is when a user specifies “http://www.report.com /reports/1999/IncomeStatement.html” in a Web browser. Typically this further navigation information, i.e., “/reports/1999/IncomeStatement.html,” provides a specific storage location within a computer server. This further navigation location may be likened to a real world address more specific than a street address that includes information such as a company name, department, and room number. This further navigation location is typically not Handled or resolved by DNSs, but instead by an information server at the resolved IP address. For example, an information server at the resolved address of 123.123.123.123 for www.report.com would interpret and return information at a local location of “/reports/1999/IncomeStatement.html” within the server. An Information Server is a means for facilitating communications between a communication network and the computer server at a particular IP address. Commercial examples of an Information Server include Apache. An Information Server may be likened to a mail department for a business that further routes correspondence to appropriate locations within the business.
・  FIGURE 7 illustrates IP addressing mechanisms; namely that they do not maintain an association with information as it moves across a communications networks. Web page links generally employ HTTP, which in turn relies on IP addressing. Thus, URL links simply point to a location on a communication network and are not necessarily associated with any specific information. For example, a URL link referencing www.news.com will have different information associated between the URL and the information made available at the www.news.com location as information at the location is updated daily. In many instances, locations themselves may disappear as companies move information, move their operations, go out of business, etc.
・  For example, a report entitled “Company Sales for 1999” 722 existing at a location www.report.com/1999/Report.html 708 may be moved to www.report-archives.com/1999/Old-report.html 710, e.g., because the information was sold from one entity to another, archived, or for many other reasons. The report at www.report.com/1999/Report.html 708 may have had 5 million Web pages and URL links referencing the location 744, and when users attempt to access the information they may well receive a “404 File not found” error 709 because that location no longer exists and/or no longer contains the desired information. The error results because the DNSs were designed to always resolve users’ requests to a location and because DNSs are not designed to maintain an association between URLs and a specific instantiation of information.
・  The top portion of Figure 7 depicts a Web page 701, a user entered address 702, a document 703, and a memory device 704 all employing URLs and consequently IP addressing in an attempt to reference a piece of information (the report “Company Sales for 1999”) 722. Then in Figure 7, the information 722 is moved from its original location 708 (for example at www.report.com/1999/Report.html) to a new location 710 of Figure 7 (for example www.report.com/1999/Archives.html). In Figure 7, this results in breaking 705-708 all the URLs 244 referencing the location and produces the dreaded “404 file not found” error 709 for all users and URLs making reference to the location (www.report.com/1999/Report.html) 708.
Handle System
・  Once a piece of information has been assigned a DOI and has been made available, the DOI system needs to be able to resolve what the user of the DOI wants to access. The technology that is used to manage the resolution of DOIs is better known as the “Handle System,” and will be described in more detail below. THE DOI HANDBOOK provides a general overview of basic DOIs. In a nutshell, the Handle System includes an open set of protocols, a namespace, and an implementation of the protocols. The protocols enable a distributed computer system to store Handles (such as DOIs) of digital content and resolve those Handles into the information necessary to locate and access the content, to locate and access information related to the content, or to locate and access (i.e., provide an interface to) services associated with the content. This associated information can be changed as needed to reflect the current state of the identified content without changing the DOI, thus allowing the name of the item to persist over changes of location and other state information. Combined with a centrally administered DOI registration agency, the Handle System provides a general-purpose, distributed global naming service for the reliable management of information and services on networks over long periods of time. It is important to note that throughout the present disclosure that “source,” “content” and/or “information” made accessible through the DOI system may comprise any identifiable content, source, information, services, transactions, and work of authorship, including articles, books, intangible objects, music albums, people, tangible physical objects, and/or the like further including selected discrete portions and/or combinations thereof. The accessible information may be a URL to an application that initiates a service, a transaction, provides a selection mechanism, and/or the like. 
・  In one non-limiting example, the DOI may even be associated with information identifying a human being such as a social security number, telephone number, and/or the like. In one such embodiment, metadata may be stored in a DOI record. 
・  In one embodiment, the metadata is stored directly in the DOI record as a handle value of a specified type, e.g., DC.Title. Such an embodiment may require the disabling of caching software so that multiple requests are sure to pull the correct value. Thereafter, the metadata may be retrieved by identifying the specified type through retrieval of the handle value. In such a manner, metadata may be stored in a DOI record for any type of DOI, such as but not limited to: personal DOIs, DOI medical records, DOI RFIDs, publication metadata, digital rights management metadata, and/or the like may all use the DOI record as an actual repository of data.
・  By applying such DOI record storage in the context of personal DOIs, such an embodiment results in a universally available personal identifier. In one embodiment a person may have several such universal personal identifiers. For example, a physician may have a universal physician identifier. This identifier may have a physician’s employee number, license number, name, contact information, descriptive specialist information, social security number, and/or the like. Similarly, a patient may have a universal patient identifier having their name, contact information, medical record reference, list of allergies, list of medical conditions, social security number, and/or the like. Such universal IDs would be very useful in allowing doctors and patients to provide a single identifier and not requiring them to repetitively fill out forms with their personal information. In another embodiment, a universal person identifier may take the form of a MultiLink with access controls. In such an embodiment, a person may have their own general information, and information for contexts in which they need to present personal information in different capacities and roles. For example, a universal person identifier can have the more general universal person identifier as one aspect of the MultiLink, and if the person is a physician, it may have the universal physician identifier information included in another aspect of the MultiLink. Further, the physician on occasion is also a patient, and as such may have the universal patient identifier included as another aspect of the MultiLink. Access controls may be used to limit access to various component aspects of the MultiLink only to authorized users; access controls are described in greater detail in Figure 5 and throughout. For example, the physician may provide his own universal person identifier on a Web site and groups of people accessing it that are not the physician’s employer will be limited in viewing only the more generalized universal personal identifier aspects of the MultiLink. However, when the physician uses the universal person identifier at work, the universal physician identifier components of the MultiLink may be accessed by such an authorized group. 
・  In another non-limiting example, the DOI may be associated with software modules, programming “objects,” or any other network-based resource. Furthermore, a DOI can be used to represent most anything including the online representation of physical products (e.g., items currently identified by UPC or bar codes). In such an example, DOIs could resolve to the manufacturer’s catalog page describing or offering the product, or even, in a multiple-resolution scenario, offer all services related to the object such as where to go to get the item repaired; where to find replacement parts; what the new or replacement product is; what kinds of pricing or leasing options are available, etc. Other example embodiments implementing DOIs include: representing different modules of software that may operate in distributed fashion across a communications network; telephone numbers for Voice-over-IP technology; gene sequences; medical records and/or other permanent records (DOIs will be especially useful with permanent records protected via encryption and/or other method that might invoke a certificate or decryption key); and/or the like. Another example embodiment for a DOI is to represent the permanent location of a temporary and/or dynamic value such as, but not limited to a current stock quote; current bid and offer prices (for stocks and/or any other kind of auction and/or exchange); a company’s current annual report (versus different DOIs for different prior-year annual reports); and/or the like.
・  Users may access information through Digital Object Identifiers (DOIs). DOIs are associated with (i.e., are names for) information itself. DOIs are instances of “Handles” and operate within the framework of the “Handle system.” A DOI allows for access to persistently associated information. The DOI is a string of characters followed by a separator further followed by a string of characters, e.g., 10.1065/abc123def. It should be noted and re-emphasized that although the present disclosure may make mention of specific sub-types of UNIs such as “URNs,” “DOIs” and “Handles,” the present disclosure applies equally well to the more generic types of UNIs, and as such, the present disclosure should be regarded as applying to UNIs in general where any UNI sub-type is mentioned, unless stated otherwise. Furthermore, although the Handle System, DOIs, and their supporting technologies and conventions, which are in use today, are a contemplated forum for the present invention, it should be noted that it is contemplated that the present invention may be applied to other forums based upon current and yet to be conceived conventions and systems.
DOIs
・  Users employing DOIs to access information know they will resolve and access only associated information. In contrast to URLs that reference locations, DOIs are names for information, which can be used to look up that information’s location and other attributes, as well as related services. It is envisioned that information may be any information as well as any computer-readable files, including e-books, music files, video files, electronic journals, software, smaller portions and/or combinations of any of the aforementioned content as well. It should be noted that since the electronic content will be made available over a communications network, hereinafter this application refers to such available information as being published on a communications network.
・  A DOI is a permanent and persistent identifier given to a piece of information made available on a communications network and registered in an electronic form, so that even if the location (i.e., URL), format, ownership, etc. of the content or associated data changes, users will be able to access the associated data. DOIs, or Handles, may be distributed to users in lieu of a URL. A user may access information associated with a particular DOI by selecting or entering the DOI in a Handle-enabled Web browser much like a URL hyperlink. Many types of browsers may be enabled by way of browser plug-in software such as the Handle System plug-in available from www.cnri.org. Such an attempt to access DOI associated information triggers an automated process to look up a resource’s current location. The current location of the resource is associated with the resource’s DOI in a centrally managed directory made available by the Handle System, which in turn directs the user (i.e., the user’s Web browser) to the resource’s current location. This direction is often accomplished by returning a current URL associated with the selected DOI and corresponding information. 
・  FIGURE 8 illustrates the access of information through DOIs in contrast to Figure 7 above. Initially, the information (report of “Company Sales for 1999) 222 is given a DOI through a registration process. Instead of employing URLs, users reference 844 the information using the DOI through Web pages 801, typed entry in a Web browser 802, documents 803, devices 804, barcodes 806, and/or the like. When users engage the DOI links 844, they are resolved in a centralized DOI directory 811 and the requesting users are given a URL link 744 to the information’s 722 initial location (www.report.com/1999/Report.html) 708. Upon the information being moved 834 from its initial location (www.report.com/1999/Report.html) 708 to a new location (www.report.com/1999/Archives.html) 710, the publisher of the information 810 would inform the DOI centralized directory 845 of the new location for the information by sending an updated URL 245 referencing the new location. Thereafter, if users 801-804 attempt to access the information through the DOI links 844, the DOI directory will properly provide the new location 710 by way of the updated URL 745.
・  As noted above, DOIs may not only be used to identify information, but also smaller portions thereof. For example, according to the DOI system, it is possible for a book to have one DOI, while each of its chapters would have other unique DOIs to identify them; furthermore, each figure in the book may have yet other unique DOIs to identify them. In other words, according to the DOI system, it is possible to identify information with variable granularity as desired by the content publishers. Furthermore, it is envisioned that just as Universal Product Codes (commonly expressed as ‘bar-codes’ on consumer products) allow, for example, a supermarket’s cash registers, inventory computers, financial systems, and distributors to automate the supply chain in the physical world, the present disclosure provides a mechanism for employing DOIs to empower all kinds of agents in the world of electronic publishing to automate the sale of digital content (and the licensing of rights to that content) across the Internet in an efficient manner, since each piece of saleable content would have associated with it a globally unique DOI, which could be used as a product identification code in transactions between agents.
Handle System
・  The Handle System employs a pre-determined set of policies for efficient and user-friendly utilization thereof, some of which of which are listed below. The use of the Handle System for DOI resolution should ideally be free to users, with the costs of operation of the system possibly borne by the publishers (or more generally, DOI owners or registrants). All DOIs are to be registered with a global DOI registry. Registrants are responsible for the maintenance of state data and metadata relating to DOIs that they have registered. The syntax of the DOI follows a standardized syntax. In use, the DOI will be an opaque string (dumb number). DOI registration agencies will manage the assignment of DOIs, their registration and the declaration of the metadata associated with them. 
・  FIGURE 9 provides a schematic view of a Handle 900. A Handle 900 has two components, the prefix 901 and the suffix 902. The prefix 901 and the suffix 902 are separated by a forward slash 907. The Handle 900 may incorporate any printable characters from almost every major language written or used today. There is no specified limitation on the length of either the prefix 901 or the suffix 902. As a result, it is envisioned that there are an almost infinite number of Handles available. It is important to ensure that the combination of the prefix 901 and the suffix 902 is unique for supporting the integrity of the Handle System. Thus, the DOI registration agency will award a unique prefix 901 to a publisher. In one embodiment, the registration agency may put the responsibility on these publishers for ensuring that the suffix 902 assigned is unique as well. This may be achieved with a registration tool running on the user’s client computer system. In another embodiment, the registration agency will ensure that the suffix 902 is unique by applying various suffix generation algorithms as discussed throughout this disclosure. The Registration Agency and the Handle System administrators will both verify uniqueness of any new Handle before depositing it in the Handle System. The Registration Agency deposits DOI records with the Handle System. The Handle System in turn services DOI resolution requests through a DOI directory. 
・  The prefix 901 itself has two components separated by a prefix separator 906, which is a period. The first part of the Handle prefix is the Handle type 904. The second part of the Handle prefix is the Handle creator 905. The Handle type 904 identifies what type of Handle system is being used. When the Handle type 904 starts with a “10” the Handle is distinguished as being a DOI as opposed to any other implementation type of the Handle System. The next element of the prefix, separated by a period, is the Handle creator 905, which is a number (or string of characters) that is assigned to an organization that wishes to register DOIs. Together, these two elements 904 and 905 form the unique publisher prefix portion of the DOI. There is no limitation placed on the number of Handle (or specifically DOI) prefixes that any organization may choose to apply for. As a result, a publishing company, for example, might have a single DOI prefix 901, or might have a different one for each of its journals, or one for each of its imprints. While generally a prefix 901 may be a simple numeric string, the scope of the Handle System is not limited thereby. Thus, a prefix 901 may also utilize alphabetical characters or any other characters.
・  The suffix 902 is a unique string of alphanumeric characters, which, in conjunction with a particular prefix 901, uniquely identifies a piece of information. It should be appreciated that the combination of the prefix 901 for a publisher and the unique suffix 902 provided by the publisher avoids the need for the centralized allocation of DOI numbers. The suffix 902 may be any alphanumeric string that the publisher chooses, so long as it is unique among all suffixes registered in conjunction with the publisher’s prefix.
・  Figure 9 also provides a view of another embodiment of the DOI 990, in which a textbook’s ISBN number serves as the suffix 902. Consequently, where it is convenient, the publisher of the underlying content may choose to select as the suffix 902 any other identification code accorded to the original piece of content.
Enhanced DOI 
・  Figure 9 further illustrates an enhanced DOI 910 grammar. One non-limiting example embodiment of an enhancement to the DOI grammar is embodied as an enhanced prefix 911. However, it is fully contemplated that an alternative and/or complimentary enhanced suffix (not illustrated) may be similarly appended to the DOI 900. The enhanced prefix 911 is comprised of an enhancement grammar target 917 and enhancement separator 914, which is an “@” symbol, but it is understood any other character may be designated as the enhancement separator. The enhancement grammar target 917 may itself be any string of characters other than the enhancement separator 914. The enhancement grammar target 917 may be employed for the purpose of having the DOI 900 resolve to multiple versions of a specified information as will be described in greater detail throughout this disclosure. In a further enhanced embodiment, the enhancement grammar target 917 may itself be further comprised of an enhancement grammar verb 912 and enhancement grammar target object 913 separated by an enhancement target separator 916, e.g., a period. Of course the enhancement target separator 916 may be designated as any character(s). In one example embodiment, the enhancement grammar verb 912 acts as a modifier to select amongst a plurality of multiple resolution targets for a DOI, and the enhancement grammar target object 913 is a value passed to the target object and/or a Handle system resolution server for further action.
Handle System Metadata
・  A DOI 900 is merely an identification number that does not necessarily convey any information about its associated information. As a result, it is desirable to supplement the DOI with additional information regarding the addressed information to enable users to perform efficient and user-friendly searches for retrieving the desired content over a communications network. To allow easy identification of information, the present invention provides for the use of metadata, which is descriptive data about the identified information. While metadata may be any data-structure that is associated with a DOI, according to one embodiment, the metadata will be comprised of a few basic fields that can accurately and succinctly identify the published information. According to this embodiment, the metadata will comprise an identifier associated with the entity from a legacy identifier scheme such as the International Standard Book Number (ISBN) for a book, title of the published content, type of content being published (such as book, music, video, etc.), whether the content is original or a derivation, a primary author of the content, the role of the primary author in creating the content, the name of the publisher, and/or the like. As different types of content may require different metadata for describing it, one aspect of the DOI system envisions the use of different metadata for different types of content.
・  According to one example embodiment, metadata will be made available to any user of the DOI system to enable them to find the basic description of the entity that any particular DOI identifies. This basic description will allow the user to understand some basic things about the entity that published the content or the content itself.
・  As a result, to find out what information the DOI identifies, it is desirable to resolve it, and then review associated metadata because the DOI links the metadata with the content it identifies and with other metadata about the same or related content. In one embodiment, the metadata allows for the recognition of the information identified by the DOI 900 as well as its unambiguous specification. The metadata will also allow for the interaction between the information and other contents in the network (and with metadata about those entities).
DOI INFORMATION ACCESS
・  FIGURE 10 provides an overview of the resolution mechanism for allowing users to access the desired information by merely providing the DOI to the DOI Handle system. Resolution in the present context includes the submitting of an identifier to a network service and receiving in return one or more pieces of current information related to the identifier. According to one embodiment of the DOI system, shown in Figure 10, the user uses her Web browser 1001 client to point to content identified by a particular DOI 1002. This DOI 1002 has only one URL associated with it, and must resolve to that URL. As a result, when the user makes a request for underlying content identified by a particular DOI 1002, the user is directed to URL 1003, where the desired content lies. 
・  As such, this mechanism allows the location of the information to be changed while maintaining the name of the entity as an actionable identifier. If the publisher changes the location of the content, the publisher must merely update the DOI’s entry in the Handle System database to ensure that the existing DOI 1002 points to the new location of the content. As a result, while the location of the content has changed, the DOI remains the same and users are able to access the content from its new location by using the existing DOI.
・  Figure 10 provides an overview of a DOI system where users may use a DOI for resolving a request for one piece of content, out of a plurality of available identical copies of the same piece of content that are identified by the same DOI, as well as the location of data about the piece of content, and services associated with the content (such as purchasing the content). Thus, the user uses the Web browser 1000 and provides the necessary DOI 1030. The DOI 1030 may be structured to describe the type of service desired 1035. As a result, the DOI system is able to resolve the particular piece of content 1040 that the user desires to access.
・  In one embodiment, the format for storing multiple resolution options for a given DOI in the Handle System may be expressed as a hierarchical dropdown menu in the browser using DHTML and JavaScript.
・  An example of a MultiLink menu is shown 1043. Upon clicking on a multiple resolution hyperlink 1044, the user is presented with a list of link choices which can be one or more layers deep 1043. In the example 1043, the user has traversed two submenus to choose a link to buy the Microsoft Reader version of an ebook at Amazon.com.
・  As shown, this menu is a widget implemented with DHTML and JavaScript. The widget is loaded with data obtained from the Handle System and converted into JavaScript data structure as is described in greater detail below. In one embodiment, the format of the Handle record is composed by the following five components:
・  1. Multiple resolution records are assigned two new Handle data type: MULTIRES and MULTIRES_MAP.
・  2. A given handle can have multiple MULTIRES values (differentiated by different index values), and can optionally have one MULTIRES_MAP.
・  3. Each MULTIRES value is comprised of two logical units delimited by an equal sign (ASCII 0x3D): a label and a URL. The label portion is used as the displayed text for the URL hyperlink. In the case where a URL is not relevant (e.g., a submenu name), the URL portion is omitted.
・  4. The MULTIRES_MAP value describes the hierarchy of the menus and submenus defined by the MULTIRES values. The MULTIRES_MAP value is comprised of recursive menu lists delimited by curly braces. The listed items are the indices of the MULTIRES values. 
・  5. In the absence of a MULTIRES_MAP value, then a flat hierarchy is assumed (i.e., no submenus), and items are displayed in the order of their MULTIRES index values.
・  The following table shows an excerpt of the handle record for the multiple resolution link depicted 1043. Any DOI application should be able to obtain this Handle Record and extract the labels and URLs necessary to present the correct multiple resolution options to the user.
・   
Type                 Value
.
.
.
MULTIRES      1000   Publisher’s Catalog Page=http://...
MULTIRES      1001   Read a Free Excerpt=http://...
.
.
.
MULTIRES      1007   Buy This Book
MULTIRES      1008   Microsoft_Reader
MULTIRES      1009   Contentville.com=http://...
MULTIRES      1010   Amazon.com=http://...
MULTIRES      1011   Adobe eBook Reader
MULTIRES      1012   Barnes &amp; Noble=http://...
.
.
.
MULTIRES_MAP  1030   { 1000 1001 1002 1003 1004 { 1005 1006 } 1007 { 1008 { 1009 1010 } 1011 { 1012 1013 } ... } }
・  In one embodiment, the creation of a MultiLink is achieved through a series of Web pages 1045-1070. As can be seen, an owner for the MultiLink must be established 1045 by first entering owner/account information, which allows for the control/creation of the MultiLink. Then the user may enter metadata regarding the MultiLink, e.g., Title, Author, publication date, descriptions, etc. 1050. Next, the user may provide multiple resolution instances in a hierarchy 1055. For example, reviews of the work may resolve to one location 1056, while the ability to purchase the book may resolve elsewhere 1057. Once the MultiLink resolutions are populated and submitted, a MultiLink 1060 and menu are generated. The user may then view 1063 the metadata information 1065 and MultiLink DOI record as stored in the handle system directory 1070.
・  FIGURE 11 provides an overview of the sequence of actions that a user performs to access information, in accordance with the present invention. Initially, the user launches the browser client 1100 on a computing device 1105, such as personal computer, personal digital assistant (PDA), and/or the like. The user engages the browser 1100 to make a DOI query. The DOI query is forwarded to the DOI Directory Server 1110 over a communications network. The system of the DOI Directory Server 1110 examines the DOI against the entries stored therein and forwards the appropriate URL to the browser 1100 on the user’s computer 1100, in a manner that is invisible to the user. As a result, the browser is pointed to the desired content on a server with the appropriate publisher information 1120. Finally, upon receipt of the request from the user’s browser, the publisher 1120 forwards the desired information to the user, which may be accessed in the browser client 1100.
・  Figure 11 continues to provide a more complete view of the sequence of actions that a user performs to access content information. As noted above, the user launches the browser client 1100 on a computing device 1105. The user engages the browser 1100 to make a DOI query. The DOI query is forwarded to the DOI Directory Server 1110 over the communications network. The system of the DOI Directory Server 1110 examines the DOI against the entries stored therein. As a result of the checking of the DOI against the entries stored in the DOI Directory Server 1110, the DOI Directory Server 1110 determines where the DOI must lead the user 1125. The appropriate URL for the content is automatically forwarded to the user’s browser 1100, without any intermediate intervention or action by the user. As a result, the browser 1100 is pointed to the appropriate publisher 1120 whose server is addressed by the underlying URL. The URL is used by the publisher’s server 1120 to determine the exact location for content desired by the user, and the publisher’s server 1120 forwards the appropriate content 1130 to the user.
・  FIGURE 12 provides an overview of some of the exemplary mechanisms for accessing information over a communications network by resolving a DOI to obtain the URL where the desired content is located, in accordance with the present invention. According to one embodiment, the user may directly provide the DOI and the DOI system retrieves and forwards the appropriate content to the user by simply linking to the appropriate URL. According to another embodiment, the user may provide information related to some of the fields included in the metadata, whereupon a DOI lookup service identifies the appropriate DOI, which in turn may be resolved to the desired content’s location. As shown in Figure 12, according to one embodiment, a search engine 12010 may be provided to a user. In one embodiment, the search engine is offered and disposed in communication with the registration agency’s DOI and metadata database. In an alternative embodiment, a search engine such as www.google.com may be adapted to submit queries to the registration agency’s databases. The user searches for the appropriate DOI by providing some identifying information to the search engine 12010. The search engine 12010 uses the identifying information provided and searches a database of metadata to retrieve the DOI associated with the provided metadata information. Thus the user conducting the search may be presented with returned DOIs from the metadata database and/or URLs resolved from said returned DOIs. The retrieved DOI is sent to the DOI directory 12011, which resolves the URL wherein the desired content is located by a publisher 12040. Finally, the user’s browser is pointed to the appropriate content 12060.
・  According to another embodiment, the user may provide the DOI 12015 in the address window 12020 of a browser 12025. If the user’s Web browser is not capable of natively processing DOIs, then the DOI 12015 may contain the address of a proxy server for the DOI directory 12011, which in Figure 12 is “dx.doi.org.” As a result, the browser is pointed to the DOI directory 12011 located at dx.doi.org, which resolves the URL at which the desired content is located by a publisher 12040 and points the user’s browser thereto.
・  According to another embodiment, the DOI may be embedded in a document or some form of information 12030, whereupon clicking the DOI directs the user to the appropriate DOI directory 12011, which determines the URL at which the desired content is located and points the user’s browser thereto.
・  According to another embodiment, the DOI may be provided on a memory 12040, such as a CD-ROM or a floppy disk, whereupon the memory may automatically, or upon being activated, direct the user to the appropriate DOI directory 12011, which resolves the URL at which the desired content is located and points the user’s browser thereto.
・  According to yet another embodiment, the DOI may be provided in printed form to a user, who enters the DOI manually as above or by way of optical and/or mechanical peripheral input device.
・  Figure 12 provides an overview of another embodiment of the exemplary mechanisms for retrieving information over a communications network, whereupon the DOI system resolves a DOI to obtain the URL where the desired information is located. According to this embodiment, a plurality of DOI directories 1210 exist as a distributed DOI directory and form a Handle System 1200. In one embodiment, the distributed DOI directory acts and responds to requests as if it were a singular directory 12011. Otherwise resolutions take place similarly as in Figure 12. 
・  FIGURE 13 provides an overview of an exemplary DOI system, in accordance with the present invention, wherein the publishers, the DOI registration service and the Handle System collaborate together to create an efficient DOI system. The prefix holder 1355 may submit information to a DOI registration service 1300 comprising a DOI 1342 and associated metadata 1366. The prefix holder who has already been assigned a unique prefix 501, requests that a suffix 502 be assigned to a piece of content 1366. The registration service 1300 is responsible for parsing and/or reformatting the user’s streams of submitted information 1342, 1366 for subsequent deposit in a Handle system 1350 and/or metadata database 1310. As noted above, the scope of the content that can be addressed using a DOI is unlimited. As a result, the content 1366 may comprise any information and work of authorship, including articles, books, music albums, or selected discrete portions thereof. In addition to providing a DOI 500, the publisher 1342 collects metadata for the content 1366. The metadata may comprise the content’s DOI 500, a DOI genre, an identifier, title, type, origination, primary agent, agent’s role, and/or the like. It may also comprise listings of associated services having to do with the identified piece of content offered by various parties, such as the locations of Web pages where a piece of content may be purchased online. 
・  Once the publisher 1342 has assigned the suffix 502 to the content 1366 and collected the necessary metadata, the DOI 500 and the metadata are transmitted to the DOI registration service 1300. The DOI registration service 1300 maintains a database of DOIs 500, metadata of all the registered content 1366, as well as the URL at which the content 1366 is located. According to the present invention, the DOI registration service 1300 forwards the metadata to a metadata database 1310, 2219 of Figure 22, which may or may not be integrally maintained by the DOI registration service 1300. 
・  The DOI registration service 1300 may use the collected metadata for providing it to other data services 1320 or for providing value added resources 1330 to the users. In addition, the DOI registration service 1300 sends the appropriate DOI Handle data to the Handle System 1350, which may comprise a plurality of DOI Directory Servers 1341.
・  FIGURE 14 illustrates example advertisements served by an advertising Syndicator. As discussed earlier in Figure 1, a Syndicator may be used as an advertising provider. Such an embodiment shows a series of Web pages 1411, 1422, 1433, 1444 in a Web browser window 501. In one example 1411, a user may conduct a search for information about aviation by entering search terms into a search query text box 1405 and submitting 1486 the search. Some of the search results 1418 include MultiLinks 1410. When a user moves over the links, they may find further references to the MultiLinked content 1420 by selecting items from the MultiLink menu that pops up 1445. It should also be noted that the positioning and appearance of menu items may change based on end-user activity tracking, as will be discussed in greater detail in Figures 16-20. For example, if the “Call Firm Now” option becomes popular, it may move up and become the first menu item selection instead of the “Home” option 1446. The MultiLink menus may pop up from text results 1410 or as part of a banner ad 1430, 1422.
・  In another embodiment, users may procure MultiLink menu enabled sponsored links 1417, 1444. In this embodiment, a user procured a sponsored link from a search provider. For example, the user went to a search company Web page (e.g., Google), filled in their contact information and provided information specifying the sponsored link they would like. Normally, a user would specify certain keywords and provide a sponsored link and some accompanying text that would be displayed in response to a search for the specified keywords. This is extended by the Autolinker and/or MultiLink editor. MultiLinks for an advertised item would have already been created, e.g., by the Autolinker. Instead of providing a regular link, the user could specify a MultiLink. Further, the user may employ the MultiLink editor to tailor a MultiLink menu as has already been discussed. As such, the user may now provide a MultiLink menu to the search company instead of a mere link, and this will result in premium sponsored links having MultiLink menus pop-up with more information when a user moves their cursor past 1410, 1417, 1445. Thus, carrying the example, when a user enters a search for “immigration lawyers” in a search field 1405, 1433, a results Web page 1444 will show results 1418 that include premium sponsored links 1417. When a user moves their cursor past the MultiLinked results 1410, a MultiLink menu 1445 pops up and may be used to access more information. Similarly, the positioning and appearance of menu items may change based on end-user activity here as well. For example, the order of the cities 1447 may change as driven by the frequency of end-user payment, by advertisers paying for placement (e.g., Boston firms may pay more and their menu entry would move to the top). In these embodiment, because the MultiLinks are so rich in information, and they are both inter and intra linked, any advertising links using MultiLinks will in many cases be found to be more relevant as search results. Such MultiLinks will have higher click-through rates than regular single-linking URLs, and thus would be more valuable in an advertising context.
・  FIGURE 15 illustrates example MultiLink applications. In another embodiment, a MultiLink advertisement may be placed contextually within other relevant content, such as within an article or a product review, a research study, a music Web site, and/or the like. In one example, MultiLink menus could be put in the order as driven by popularity of click-throughs by independent source data such as a song’s current top-40 chart rating 1510, 667. In the following example, a DOI for “Boeing” is displayed within a Business Week article, driving the user back to McGraw-Hill’s World Aviation Directory (i.e., the owner of the DOI) where the desired information may require a subscription or a pay-per-view transaction from the user 1515 . In the following example, a book review in Business Week may display the DOI for the book being reviewed, and the MultiLink menu could refer the user to Amazon or other retailers for purchase. Either the publisher itself (as the owner of this DOI), or Business Week (by using the MultiLink Syndicator to modify the local appearance of that menu insofar as that menu appears within Business Week) may seek fees from the retailers for placement on the MultiLink menu. The fees may take on a number of forms, such as on a referral-commission basis, on a flat placement fee basis and/or on any other basis including those described below and/or elsewhere. For example 1525, a user may seek to buy a version of the book and select Barnes & Noble, and as such a referral fee would be received by Business Week from Barnes & Noble. Also, MultiLink menus may employ end-user activity tracking to determine what ads are used most. Further, sponsored resources may be used to rotate particular sponsors in the MultiLink menus based on usage. As such, a Web site may increase ad revenues because the end-user tracking would expose winning ads more frequently and thus, the Web sites would earn more money as their click-through rates increased.
・  In another embodiment, an advertisement may actually be placed on the MultiLink menu for another item, in effect using the MultiLink menu in a similar way to a billboard as screen “real estate” and/or any other form of advertising inventory. In one example, a user could move over a “Learn More” item having a MultiLink with sponsored resources 1530. As such, placement on the MultiLink menu could be offered to sponsoring advertisers for a fee, which could vary according to prominence of the fonts and colors on the menu, inclusion or exclusion of graphics or logos, or placement in terms of the order of menu choices. Placement may also be rotated amongst different advertisers, with fees varying according to how frequently a given advertiser’s link(s) would appear, or what times of day, in what contexts, in response to certain kinds of search queries by the user, according to the geographical location of the user, according to the language of the user, according to user profile information which had been previously stored or had been captured as part of a dialogue with the user, and/or the like.
・  In one embodiment, the mechanism for populating sponsored links will be based on receiving payment from advertisers for a certain number of user impressions and for specified “key word” activities. As such, if a sponsor paid for 1,000 impressions related to “diabetes” keywords, then the Syndicator may vary the generation of menu specifications based on paid for links. In one example embodiment, a placeholder tag is put into a MultiLink record, e.g., <Sponsored Link>, into which a sponsored link may be placed. A ISICImay then issue a database query based on keywords associated with embedded MultiLinks in its content pages, wherein it selects for such keywords with paid for impressions. Upon identifying such sponsored items, the Syndicator may then insert the sponsor’s link into the MultiLink placeholder. As this may be done in real-time, as a user mousing over a call for a MultiLink menu, the generation of the menu specification may be provided on demand with the most current advertisers selected from an advertising database. As the menu will be displayed, a debit of impressions for the sponsored link may be recorded in the advertisement database, leaving the sponsor with, e.g., 999 impressions.
・  In another embodiment, placement may be provided on the MultiLink menu to external organizations that represent online partners of the DOI owner, and which may link to related resources or products or services offered by the partner. Placement could be granted on a flat-fee basis, or as part of a reciprocal linking arrangement, or as part of an arrangement whereby one or both parties may compensate each other via referral commissions for purchases made by visitors who arrived via the other party’s MultiLink menu, on a per-click or per-visitor referral basis, and/or any other business arrangement. Fees could also vary according to all the embodiments and variations described previously and/or elsewhere in this document. In one example, two parties are shown first with their own independent DOIs 1535, and then with interlinking between them 1537. As can be seen, the Snapshot reports MultiLink menu 1535 is integrated into the, e.g., SRI’s, MultiLink menu as a sponsored link 1537. It should be noted that interlinking may take place with two or more parties.
・  In another embodiment, an intermediary such as a retailer, distributor, aggregator or syndicator such as Dialog, Factiva, Lexis-Nexis, etc. could elect to display DOI MultiLinks within its service, thus enabling MultiLink-referred traffic back to the owner’s site and/or to any other site designated by the owner, with a referral commission or other compensation being earned by the displayer of the MultiLink. Rather than loading and re-selling content or products per se, the intermediary may monetize its audience or user base to drive sales back to the DOI owner or its designated parties, thus benefiting from its role as a conduit. For example, a conduit site may display a DOI (e.g., for “William Clay Ford”) owned by Thomson Gale, which would then direct users to saleable Gale products such as various Biography documents 1540. 
・  As such, MultiLinks have an impact upon “natural” search engine rankings, whether they are employed in advertisements or in any other context. Many searching systems, like Google, rank relevancy based on the number of links to a given content item. When they spider the Web, they index Web pages and track the number of links to a given content item or Web page. This information is then used in their relevance-ranking algorithms so that when a user searches for a given term, the term is not only associated with the content item but is relevance-ranked according to (among other factors) the number of links which point to that item. Therefore, when MultiLink DOIs provide interlinking between many related items, and when those items in turn interlink between many other related items (including potentially the original item), the net result is to boost the relevance ranking of the item within search results on search engines or other sites which provide search results. The association per se of a user’s search query with the particular item found may or may not require an independent association method such as between the DOI MultiLink and other words on the Web page on which it appears, or between the DOI MultiLink and keywords in the header or metatags of the Web page, or via any other mechanism by which a search becomes associated with a particular search result, but the ranking may be influenced by the interlinking of related items via the DOI MultiLink. Further, the more items are interlinked, the greater the ranking impact becomes. Further still, if the DOI MultiLink is distributed to multiple locations on the Internet, instead of only on the owner’s site, and regardless of whether this distribution is achieved via use of the MultiLink Syndicator or via manual ad-hoc postings on Web pages or via any other method, the ranking impact is further magnified by the presence of these multiple DOI MultiLinks in more locations.
・  The impact on search engine rankings can be estimated via a component of the Autolinker, wherein the number of interlinked items, and the degree to which they are interlinked, can be assessed to provide an estimate of the extent to which search engine rankings could be affected by the spidering of these MultiLinks by search engines. Although the specific ranking algorithms utilized by search engines are generally not publicly known, an impact factor can be estimated. This impact factor can then be further extrapolated to estimate the further impact accruing from the degree to which those DOIs may then become distributed around the Internet to be found by search engine spiders; the more places they are found, the greater the impact on rankings because each location represents yet another place in which the spiders will encounter a DOI, traverse all of its MultiLinks, encounter those DOIs, traverse all of their MultiLinks (including the original DOI), etc. These estimates can also be used to help the DOI owner understand how it could better interlink related information. For example identifying items which have very little interlinking associated with them (or none, as could be embodied in a “MultiLink orphan report”), which in turn could identify a failure of the DOI owner’s categorization process, and as such, may highlight a weakness in the effectiveness or accuracy or completeness of its taxonomy, or other useful diagnostic conclusions.
・  What follows is one example embodiment that can make such measurements:
#!/usr/bin/perl -w
# add local libs to @INC path
use FindBin;
use lib $FindBin::RealDir."/../lib";
use strict;
use warnings;
=pod
=head1 NAME
compute_statistics.pl -
Compare crawler results to database
=head1 SYNOPSIS
Crawl DOIs and process with compute_statistics.pl --
### Expects input from STDIN:
$ compute_statistics.pl --prefix 10.1225 --verbose --verbose
### When used in concert with doi_crawler.pl:
$ doi_crawler.pl --url http://doi.contentdirections.com/mr/hbsp.jsp?doi=10.1225/682025 \
| compute_statistics.pl --prefix 10.1225 --verbose --verbose
=head1 DESCRIPTION
Based on output from doi_crawler.pl, compute_statistics.pl will compare the
results to the content of the database. This script will output the following:
* Count of matches
* Count of missing
* Count of unknown DOIs
* List if matches, missing, and unknown DOIs (in verbose mode only)
=head1 OPTIONS
The script takes the following options:
=over
=item --prefix
The DOI fragment against which to match results in the database.
This string will be used to select DOIs from the HANDLE table
in the Oracle database where DOI LIKE '$prefix%'.
=item --verbose
This option increases the amount of information which is output. You 
may use this option more than once to increase output.
If specified once, this will cause compute_statistics.pl to list all the 
MISSING DOIs.
If specified twice, this will cause compute_statistics.pl to also list all the 
UNKNOWN DOIs.
If specified thrice, this will cause compute_statistics.pl to also list all the 
MATCHING DOIs.
=item --help
=item --man
=back
=cut
use CDI::DBH;
use Getopt::Long;
use Pod::Usage;
# Set up getopts
my ($help, $man, $prefix, $verbose);
$verbose = 0;
GetOptions( 'help' => \$help,
'man' => \$man,
'prefix=s' => \$prefix,
'verbose+' => \$verbose );
pod2usage(1) if $help;
pod2usage(-verbose => 2) if $man;
# Validate input
pod2usage("No DOI prefix specified") unless ($prefix);
# Clean up prefix
$prefix =~ s/\'/\_/g;
# Select all DOIs from database which match prefix
my $dbh = CDI::DBH->new_oracle();
my $sth = $dbh->prepare("select DOI from HANDLE where DOI like '". $prefix ."%'");
$sth->execute();
# Store found DOIs in hash for easy access
my %db_dois = ();
while (my ($doi) = $sth->fetchrow_array()) {
$db_dois{$doi}++;
}
# Output URL summary line
my $url = <STDIN>;
chomp($url);
print "Summary of connected DOIs\n-----------------------------------\n$url\n\n\n";
# Compare found DOIs to those passed in to STDIN.
# File into two buckets: matching, unknown
my @matching = ();
my @unknown = ();
while (<STDIN>) {
chomp();
my $doi = $_;
if (exists($db_dois{$doi})) {
push(@matching, $doi);
delete($db_dois{$doi});
} else {
push(@unknown, $doi);
}
}
# Derive third bucket: missing
my @missing = keys(%db_dois);
# Output details, if --verbose
if ($verbose > 2) {
print "Matching DOIs\n-------------------------\n";
foreach my $doi (@matching) {
print "$doi\n";
}
print "\n\n";
}
if ($verbose) {
print "Missing DOIs\n-------------------------\n";
foreach my $doi (@missing) {
print "$doi\n";
}
print "\n\n";
}
if ($verbose > 1) {
print "Unknown DOIs\n-------------------------\n";
foreach my $doi (@unknown) {
print "$doi\n";
}
print "\n\n";
}
# Output summary
my $count_matching = scalar(@matching);
my $count_missing = scalar(@missing);
my $count_unknown = scalar(@unknown);
print <<EOF;
DOI Statistics
-------------------------
Matching: $count_matching
Missing: $count_missing
Unknown: $count_unknown
EOF
・  In the above embodiment, a measure of the degree of interlinking may be obtained my comparing DOIs found through crawling against a database of (e.g., sponsored) DOIs. As such, the ISICI will crawl Web sites indexing their embedded DOIs. Then the results from crawling are compared to the index results in the database and also to sponsored links in that database. In so doing, the ISICI will count the number matches, missing and unknown DOIs. In one embodiment, matching and comparison may be achieved by comparing a fragment of a DOI to monitor the degree of matches for a family of DOIs. The ISICI may then compare found DOIs to any DOIs in the database or to any specified DOIs. In one embodiment, the ISICI performs such analysis for every DOI and stores it in an interlink/index and ranking table in the ISICI database 1519. In one embodiment, DOIs with a higher number of matching links are ranked higher than those with a lower amount. A rankings report may be generated by selecting for the highest matched DOIs resulting in a report gauging the popularity of DOIs. Such reports may be automatically and/or periodically generated and sold. In another embodiment, such reports may be produced for sponsored links. Such statistical information may be sold separately and/or included as part of a service of sponsored links. Also, a rankings list may be provided periodically to the general public acting as a gauge of content popularity, i.e., a sort of Billboard top most popular list for DOIs and content. Furthermore, such popularity lists may be broken down into multiple areas of interest. Rankings may be limited to just music content, to personal DOIs identifying popular people, to services which identify the most popular service providers. For example, the ISICI may select only a single sector, e.g., law firms, and generate a popularity index for law firms. In another embodiment, the ISICI may limit its selection to the field of current movie releases. In yet another embodiment, selections may be limited to a certain category of products, e.g., automobiles. Furthermore, the selections may be limited by time parameters. Selections on rankings may be made for a certain time period. As such, if the ISICI selects interlinking statistics for the automobile industry for the last 12 months, the rankings will be so limited. In another embodiment, if no time constraints are placed on such a selection, then popularity throughout time may be gauged.
・   In one embodiment, maximizing search engine rankings may be achieved by assigning DOIs to the keywords and/or terms of a taxonomy and/or controlled vocabulary, and the MultiLinks may then be directed to any or all of the following or any other resources: other keywords of the taxonomy; all products or publications relating to those keywords; services associated with those keywords; vendors or retailers or other kinds of partners associated with those keywords; and/or the like. For example, a DOI assigned by a company to the term “avionics repair” is MultiLinked to all of the company’s products across all its lines of business that are related to the term “avionics repair,” whether these products are books, company database records in the World Aviation Directory, Business Week or AviationWeek articles, upcoming conferences, sponsored links such as already described above, and/or the like. In such an example, search results would come back from any search engine with MultiLinks weighted towards the top 1545 as there is a greater degree of interlinking. 
・  In another embodiment, the same taxonomy term and MultiLinks that would cause the term to rise higher in the search engine rankings could also be used to increase the value of placement of partner links on the MultiLink menu, even in contexts where the DOI appears other than within search engine results per se. For example, a company’s DOI for “diabetes mellitus” could be seen contextually within a research study, wherein the MultiLink would drive users to the company’s partners (e.g., WebMD, Atkins, the scientific journal literature provided by Ovid, etc.), where such placement on the menu is offered for a fee proportional to that term’s ranking on search engines (or on any other basis, such as those described previously).
INTEGRATED, INFORMATION-ENGINEERED, SELF-IMPROVING SYSTEM FOR ADVERTISING, E-COMMERCE AND OTHER CUSTOMER INTERACTIONS ONLINE
・  Prior to the ISICI, there were no ad formats that represented information-engineered menus of links, which may provide the user with a guided navigation framework to multiple deep links that facilitate access to additional information, offers, purchase transactions, related products, etc. No other formats offered a complete navigation framework to all information and links relating to the product or subject of the ad.
MultiLink User Interfaces
・  FIGURE 16 illustrates example MultiLink applications and user interfaces. Further, the navigation framework represented by a MultiLink has an underlying engine that creates, maintains, and centrally controls these links, either via a human editing process or more typically via an automated “assembly line” process that creates and maintains these menus based on product data fed by the advertiser. Further still, in MultiLink menus go even further than embodying information and links relating to the product or other subject of the ad; the menus can also include links that point deeply to back-end system data such as in-stock inventory information, local dealer information, special offers from various retailers of the product, and/or other kinds of information or transactions that require sophisticated integration with other online or offline systems. This capability also encompasses varying degrees of automated integration. For example, in one embodiment, a MultiLink menu may contain a deep link pointing to back-end system information. As has already been discussed in Figures 2-3 and throughout this disclosure, such deep links may have been created by consultation with the target system’s technology staff, database administrators, Web masters and/or the like; also, the deep links may be reverse-engineered through observation and deduction. In another embodiment, the MultiLink menu creation/maintenance system may actually retrieve information from the back-end system in advance of creating the menu itself. In other words, the MultiLink’s menu specification may be generated and or updated by retrieving information from a back-end system (e.g., current inventory information 1615, special pricing or bundling (see 1820 of Figure 18), coupons, rebates, and/or the like). As such, this allows the ISICI to create and/or update MultiLinks based on information dynamically retrieved from back-end database systems. This allows a user to obtain, navigate and interact with back-end information without having to navigate through actual Web pages and/or target references. Figure 16 shows a MultiLink menu with composite information detailing the inventory and price of specific automobiles 1615. An end-user may even enter form information right within a MultiLink menu 1625 without having to traverse the actual underlying target reference links contained within the MultiLink menu. Alternatively, the MultiLink menu allows a user to navigate to the back-end system 1620 by selecting a menu selection 1621 targeting a reference address where the user may interact with the back-end system directly 1622.
ISICI Topology
・  FIGURE 17 is of a mixed data flow diagram illustrating embodiments of a MultiLink eco-system. Generally, the ISICI allows for the creation and maintains of MultiLink menus 1705. The creation of the MultiLink menus results in the registration of MultiLinks in an UPUNI global registry 1715. Syndication of the MultiLink menus take place 1720 and as the MultiLinks and menus are propagated and displayed 1725 by end-users, a MultiLink tracker collects information about the end-users interaction with a given MultiLink menu 1735 and stores that tracking information in a MultiLink tracker database 1740. This tracking information 1740 may be used by advertisers and other service providers 1750 to further refine, repair and/or otherwise service the MultiLink menus. In one embodiment, a quality assurance provider 1750 may use tracking information to assure MultiLink integrity 1707 as MultiLink menus are being maintained and/or created 1705. For example, if a particular MultiLink menu entry becomes very popular and the target reference of that menu entry becomes overwhelmed so that many users are denied access, the quality assurance service provider 1750 may repair the MultiLink menu 1755 specification by providing an updated target reference (e.g., providing a new target reference for an alternative server with greater capacity, providing an alternative menu entry, and/or the like). 
・  In another embodiment, an ad agency may use the tracking information 1745 to refine MultiLink menus so that more popular menu selections are more prominently displayed. For example, an ad agency might move a popular menu selection towards the top so it is more easily selected; move a less popular menu selection towards the top so it is more easily selected in an attempt to make that selection more popular; place sponsored advertising in menu selections; allow for advertisers to bid for placement of advertising; and/or the like. Also, the MultiLink menu may include menu items that are all, partially or devoid of sponsored advertising. In one embodiment, a specified number of MultiLink menu item slots may be reserved for sponsored advertising. The number of item slots may be anywhere from none, to some, to all of the MultiLink menu items. In such an embodiment, advertisers may bid for placement of their ads in the available spots. In one embodiment, the bidding and/or placement of ads is based on the context of: the other MultiLink menu items, the contents of the targets the MultiLink menu items, the contents of the cause of the MultiLink menu item (e.g., a hyperlink and/or its reference), the content of the end-user’s current point of navigation (e.g., their currently displayed Web page), and/or the like. It should be noted that the advertising slots may themselves be tracked. For example, the MultiLink tracker may allow for the determination of more effective placement of ads in a MultiLink menu. For example, in some context, slots devoted to MultiLink menu ads may work more effectively sprinkled throughout the MultiLink menu, while in other contexts ads may work better if featured in more prominent locations (e.g., at the top of the MultiLink menu). Furthermore, the format of MultiLink menu ads may be refined through tracking. For example, in some contexts MultiLink menus that prominently express they are ads (e.g., by preceding any text in a MultiLink menu ad slot with “AD:”) may work better, while in other contexts having MultiLink menu ads that blend in with the remainder of the MultiLink menus may be more effective.
・  As such, advertisers would be able to modify the Multilink menu specification upon in response to tracking information from the MultiLink tracking database 1740. In one embodiment, a consulting industry may be engaged to provide marketing and product strategies as to how to best populate and design MultiLink menus 1705 as part of an overall marketing strategy 1760. As such, the marketing consultants will also benefit from the end-user tracking information stored in the database 1740.
・  A more streamlined view 1775 of the above described feedback loop demonstrates how each of the aforementioned components may generally interact with one another. In this simplified view, shows a continuous cycle of self-improvement 1775. The feedback loop rotates counter-clockwise, starting at the top with “Consulting” 1760. In this embodiment, the consulting service begins the business process of working with clients to capture their product and marketing strategies and their understanding of their target customers’ purchasing life-cycle. The consultants can try to best gauge an initial seed of items to populate the MultiLink menu for a particular marketing campaign. This initial seed may be used to actually create the MultiLink with the creation/maintenance component 1705 as has already been described (e.g., via a fully-automated, data-driven, “assembly line” process using the Autolinker, or whether via a manual creation process using the MultiLink editor, and/or the like). The MultiLink server 1726 enables the display/clickless navigation the MultiLink menu. The Syndicator 1720 distributes the links anywhere on the Web without requiring a local software install, yet still allows for individual local-site customization just as the MultiLink server does, e.g., when it is installed on a local site. The quality assurance component 1755 checks the integrity of MultiLinks. At this point, the MultiLink tracker 1735 may track and report end-user behavior back to either the creation/maintenance component 1705 and/or to the consulting facility 1760.
MultiLink Tracker
・  FIGURE 19 is of a logic flow diagram illustrating embodiments of a MultiLink menu tracker. The MultiLink tracker may collect tracking information in at least two ways: receiving tracking information directly resulting from an end-user interaction with a MultiLink menu 1905 (i.e., clicking on a MultiLink menu item resulting in engagement of an HTTP post to the MultiLink tracker server address) 1905, spidering Web servers for usage logs 1915, and/or the like. The MultiLink tracker employs a spider to retrieve the usage logs at Websites across the Internet 1915. In one embodiment this is achieved by spidering to every IP address to a statistics page (e.g., http://123.123.123.123/statistics). In another embodiment, arrangements are made with ISPs and host providers to transfer usage logs on a regular basis from FTP points. Once the usage logs are obtained 1920, the MultiLink tracker may begin analyzing the individual usage entries in the logs 1925. In one embodiment, the MultiLink tracker will analyze each log entry 1925 continuously (until it exhausts all entries in all Web logs). In another embodiment, the MultiLink tracker may process the logs at specified times (e.g., as initiated through cron jobs) 1925. Alternatively, the MultiLink tracker may receive tracking information directly from end-user actions 1905 (as has already been discussed in Figure 2). When the MultiLink tracker receives tracking information directly 1905, it may pass each end-user tracking item on to be analyzed on a continuous and dynamic basis 1925, or alternatively, the MultiLink tracker may store such tracking information (i.e., HTTP posts) in its own Web server log 1907, which may be processed along with other logs 1925.
・  Generally, Web servers maintain Web logs that list every single request made by users. Generally, these lists are ASCII lists that transcribe the full HTTP address and request. As such, when the Autolinker generates parameters that are appended to a tracking address (as was described in Figure 2), the Web logs will have lists that may be parsed for such information. In one embodiment, the Web logs may contain entries such as this:
・  http://www.chrysler.com/bridge/full_inventory.html?linkstorm_path=crossfire
・  The actual Web address reference is “http://www.chrysler.com/bridge/full_inventory.html,” and is followed by a parameter that identifies the “crossfire” menu item (see 1602 of Figure 16) in the MultiLink menu. In an alternative embodiment, menu item numbers are used as parameters, as was already discussed in Figure 2, e.g.:
・     http://www.trackerserver.com/postvalues?doi://10.1009/0395960789?menuID:12345?hover:4:menuTier:1:2?hover:2:menuTierClick:1:3
・  Thus, each such entry 1925 in the Web log is parsed (e.g., popping every ASCII string that is separated by a carriage return and parsing for DOI 1930 and parameter values 1940). Numerous parameter values may be included and parsed such as: hover times, menu item selection values, menu specification ID, and/or the like. In one embodiment, when a MultiLink menu specification ID is passed as a parameter, the menu specification may be obtained 1935 and used as a dynamic template in parsing the parameters 1940. Upon parsing out end-user tracking activities 1930, 1940, the MultiLink tracker may save those parsed values to its database 1919.
・  FIGURE 20 shows a MultiLink tracking user interface and tracking log. The MultiLink tracker database may be queried by individuals through a MultiLink tracker interface 1205. The MultiLink tracker interface may provide SQL queries to the database to provide various activity tracking statistics 2030, 2035, 2040, 2050 for each MultiLink menu 2071 and its sub menu items 2072. For example, date ranges 2055 may be provided in the interface, which are then used to constrain the SQL select of data so that the various metrics are limited to that date range. Various statistics like menu item roll-overs 2030, clicks 2035, click through percentages 2040 and average time spent on a menu subitem 2050 may be discerned. These tracking values come from Web logs. Alternatively, DOI handle use may be tracked via a Web log 2080 that maintains the accessed DOI 2010, number of accesses 2015, title 2020 and other types of information. However, the MultiLink tracker database may also be queried and accessed programmatically through HTTP requests that are parsed into SQL requests. For example:
・  http://www.trackerserver.com/query?doi:10.123/12345{?statistic type}
・  In the above example, a DOI “10.123/12345” would be used as the basis of a select command and the database would send back an HTTP post of all the matching database records to the requesting agent. The amount of tracking information may be further limited with the addition of an optional “?statistic type” parameter. For example, the additional parameter might be “menuItem:1:3,” which would return statistics only for the third item in the second tier menu for a given DOI. Another search limiter is “clicked,” which would return only the total number of clicks for a given DOI. As such, various entities may make use of the tracking information from the MultiLink tracker database.
Purchase Cycle Compression
・  FIGURE 21 illustrates a purchase cycle. In one embodiment, the ISICI addresses the problem with prolonged purchase cycles and potential purchaser attrition. The purchase cycle for high-engagement goods and/or services 2105 is depicted in a multi-tier chart 2105. High-engagement purchases require a purchaser to make numerous decisions that are based on various objective and subjective factors. Examples of high-engagement purchase may include: automobiles, boats, homes, professional services (e.g., medical, legal, etc. services), stereo systems, televisions, and/or the like. The figure illustrates that in the early stages 2110, purchasers may spend anywhere from 2-6 months deciding on just which segment they are interested in. For example, when shopping for cars, purchasers may spend several months deciding if they want an SUV, a mini-van, a station wagon, etc. After identifying a segment 2110, in a middle stage purchasers may then spend anywhere from an additional 1-3 months deciding on which brands they are interested in 2115. After that 2115, in a late purchasing stage, purchasers may spend from 1 week to 1 month deciding on specific products and/or features within a brand 2120. For example, if purchasers decide on buying a Dodge Crossfire automobile, they may need some time to decide if they want various options like a sunroof, a deluxe stereo package, a particular color, etc. Finally, in a last purchasing stage, purchasers may spend 1-2 weeks finding a transaction partner 2122. For example, the purchasers may go to several automobile dealers in order to make a purchase. As can be seen in the figure, the number of potential purchasers 2111 decreases at each stage 2116, 2121, 2123 due to customer attrition. In many cases this attrition is caused by the loss of interest due to the long time involved in this multi-stage purchasing cycle. 
・  The ISICI manages to compress the purchasing cycle down from months to moments. As can be seen in Figure 16, when a purchaser hovers over an ad that is MultiLink menu enabled, they may obtain information about various market segments (e.g., numerous car types are available for the purchaser to examine under the line-up menu item) 1616, about the brand 1617, and even the inventory of various dealers 1615. Thus, the entire purchase cycle, from first ad impression straight through purchase may be achieved by navigating a single menu. Furthermore, as customers make purchases and their activities are tracked, advertisers may refine menu items and information that were favored by purchasers to further increase menu efficacy.
Additional Tracker Embodiments
・  The ISICI’s tracking services have the ability to quantitatively measure the effectiveness of the MultiLink menu by actually monitoring the results of end users’ interactions with these menus. In one embodiment, the ISICI system can determine how many hits and unique visitors are driven to a given Web site via the MultiLink menus, as opposed to hits and visitors that arrived at that Web site any other way. This allows for precise monitoring of the menu’s effectiveness by measuring the hits and visits that are specifically and directly attributable to the menu, rather than just circumstantially related as is the case with offline media advertising. In addition, if the target Web site has a shopping cart capable of recognizing and crediting a referral code, then the system can determine how many actual sales, subscriptions, or other commercial transactions were referred via that MultiLink menu. In this way, an actual monetary benefit and return-on-investment can be attributable to the MultiLink menu. The system can also measure the menu’s rate of click-through and rate of sales conversion by comparing these eventual hits, visits and purchases against the original number of visitors who were exposed to the menu in the first place.
・  The MultiLink menu’s role in the new advertising model as has been described herein. The ISICI can measure the effectiveness of a MultiLink menu as an actual expression of an advertiser’s conception of the end user’s decision-making process (e.g., where different branches and pathways of the menu correspond to different stages in the prospective customer’s decision life-cycle, and where each stage of this life-cycle implies its own set of information needs). The system can actually track the effectiveness of the marketer’s conception of the life-cycle, as embodied in the menu, by empirically measuring the accuracy of its fit with actual customer behavior. As such, to some extent even a marketer’s efficacy can be measured based on changes they effect on MultiLink menu ad campaign design. We have described how it is possible to compress the decision-making cycle by providing in a single menu all the information needs required by an end-user throughout the entire decision-making cycle. In addition to compressing the cycle chronologically for any one customer, this approach also has the benefit of servicing a wider range of customers because, at any given point in time, many customers exist who are already in various stages of the decision cycle, and yet all of them can be serviced via this single ad. 
・  Such measurement may be achieved by tracking the specific paths navigated by users through the menu. Thus, in one embodiment, instead of just measuring the effectiveness of the MultiLink as a whole in aggregate, the individual pathways on the MultiLink menu can be monitored and/or measured to determine effectiveness (e.g., whether or not the whole menu drives click-throughs and purchases may be measured as function of how the individual pathways on the menu). Further, the ISICI may monitor and separately measure each distinct pathway through the menu, and report back how many times users chose certain paths as compared with others.
・  There are at least two approaches by which such tracking may be accomplished: 1) the ISICI can track the user’s behavior in interacting with the menu per se (i.e., even before choosing to click through any particular menu link), and/or 2) the system can track the end result of the user’s interaction when the user actually clicks through a particular link and arrives at the target (e.g., Web page, shopping cart, query, and/or any other transaction). In some respects the two approaches overlap in that they measure the same user behavior but from two different angles. The two different ends of the user’s click-through may be viewed as a) the menu end where the user begins by clicking away to the target site, and b) the target-site end where the user arrives. In other respects, the two approaches measure phenomena differently:
・  1) The “menu per se” [“menu per se” is just a suggestion - feel free to reject. But I did change the subsequent occurrences]approach tracks the user’s interaction with the menu itself (i.e., the frequency of rollover on the various expanding hierarchical sections of the menu, the hover time on individual sections or individual links, the hover time on the menu overall prior to any click-through, etc). The menu per se approach can also track the fact that user eventually clicks through a particular menu choice. But then once the user has left and gone to the target site, the per se approach, generally, is not tailored to retrieve further user activity information without employing the second “target tracking” approach (which can be later integrated with information from the “menu per se” approach).
・  2) The second “target tracking” approach tracks the user’s arrival and subsequent behavior on the target site itself, but generally does not track what the user was doing on the menu prior to the click-through, at least until its information is integrated with the information captured by the “menu per se” approach. However, one exception occurs when by inferring the user’s behavior on the menu prior to the click-through based on tracking statistics captured on the target site. For example, if the same user (as identified by IP address, by parameter passed from the menu, and/or the like mechanism) were to 1) first arrive at one page on the target site, then 2) a moment later, arrive at a different page (having again reached that page from the menu), then 3) a moment later, arrive at yet a different page (again having gone back to the menu in the meantime), then it is still possible to gather statistics that are informative regarding the user’s behavior on the menu. Some of the statistics that may be inferred include: the time required to return and navigate down a different tree of the menu, the relative utility of different menu choices that might be adjacent on the menu and which either generated or did not generate additional click-throughs per se, and/or the like. 
・  In one embodiment, the tracking mechanisms themselves can be described more fully as follows: 
・  Approach 1) With “menu per se” tracking, statistics such as frequency of rollovers for different parts of the menu, hover times on different parts of the menu, average time from menu opening to click-through, etc. can measured through any of several mechanisms. In one embodiment, a pixel associated with an HREF can be embedded within a menu label as a tracking pointer, so that the mouse-over of that menu item is registered on the server associated with the HREF. In another embodiment, a particular menu label can be associated with HTTP Post, so that any event associated with that menu label (e.g., a user clicking through it) can be recorded by a server which is the target of the HTTP Post, even while the user herself is actually sent on to the other target reference associated with that menu label (i.e., the target reference (e.g., a URL) is intended for the user to go it upon click-through). 
・  Approach 2) With “target tracking,” each distinct click-through point on the menu (i.e., each menu choice which is capable of sending a user off to a target reference (e.g., Web site, shopping cart, process, query, and/or any other transaction) can have a mechanism such as a referral code which would have been appended or pre-pended to the target reference in advance. Such codes may be supplied during the creation/maintenance of MultiLink menus. As such, when a user arrives at the target reference, the referral code identifies the user unambiguously as having come not only from the MultiLink menu in general, but from a particular menu choice on the MultiLink. For example when the user clicks on “Search Inventory” 1621 of Figure 16 and goes to Chrysler’s general-purpose Web page 1622 of Figure 16 where a user can search inventory, the menu label “Search Chrysler Inventory” would have a URL of “http://www.chrysler.com/bridge/full_inventory.html?linkstorm_path=crossfire,” where “?linkstorm_path=crossfire” is the referral code and value indicating that this user came to this page via the menu choice under “The Chrysler Lineup -> Crossfire -> Search Inventory” pathway on the menu, and not from, say, the path “The Chrysler Lineup - PT Cruiser - Search Inventory” or the path “Owning a Chrysler - Purchasing - Search Inventory” or any other path that might also lead to that same target URL. In this way, the relative popularity of the different pathways can be measured. Similarly, on the target website where the user arrives, the site’s standard server logs will record the fact that this user came to the page http://www.chrysler.com/bridge/full_inventory.html by actually going to the URL http://www.chrysler.com/bridge/full_inventory.html?linkstorm_path=crossfire,” and thus it is possible to search and retrieve all records of visits to the latter URL (or any URL ending with the referral code “?linkstorm_path=crossfire”), and to compile these statistics into an Excel spreadsheet, the ISICI database, and/or any other reporting mechanism. Similarly, if the user proceeds to make a purchase, most web sites’ standard shopping cart functionality can also recognize that same referral code and credit that referral with a % commission of the sale price, or simply track and report on the success of the referral.
・  The results from the target-site-end can be integrated with the results of “menu per se” approach from the menu-end in order to produce consolidated analytical metrics such as click-through rates, sales conversion rates, and the like 2005 of Figure 20.
・  These metrics may then be (automatically) funneled back into the menu creation/maintenance system 181 of Figure 1. According to certain business rules established in advance, these metrics can be set up to automatically drive modifications to the menu itself going forward. In one embodiment, a rule may be created that changed the order of menu links once a day by shuffling them in order of actual popularity during the preceding day, or cumulatively. For example, the “Call Firm Now” 1446 of Figure 14 could place moved to the top of the menu if it proves the most popular. In another example, the “Sponsored Resources” link on the menu 1530 of Figure 15 is an ad in its own right; the ad lives on the “real estate” of a MultiLink menu. The menu can be filled with the link from a particular Sponsor, or rotated onto the menu more frequently than another Sponsor’s link, if the first Sponsor turns out to draw greater click-through rates. This MultiLink ad menu embodiment has the byproduct of maximizing ad revenue for the site hosting the menu because placing a more popular menu choice on the menu more frequently will draw greater click-through rates, and this is often a direct driver of the hosting site’s ad revenues.
・  Another example rule is to drop a certain choices from the menu entirely if they are rarely interacted with (i.e., they were never clicked on (or even hovered over) within a one-month period). Another example is a rule that took a menu choice from lower down in the hierarchy (e.g., the “Search Inventory” menu choice 1621 of Figure 16) and moving to the first level of the menu hierarchy 1633 if it proved to be popular.
・  In another embodiment, changing menu position (and/or adding or dropping links) may be based on complex measurements like the ratio between hover time and click-throughs, the frequency with which a user clicks through certain menu choices after viewing a full-motion audio-accompanied video within the menu 1610 of Figure 16, and/or the like.
・  MultiLink menus can also be locally customized on a particular site. This may extend to specifying different referral codes that may also identify the referrals as coming from a particular instance of that menu on a particular site. For example, the same ad placed on one publisher Web site could be amended to include a referral code specific to that site, whereas the same ad placed on a different publisher’s site may be amended to include a referral code specific to that site. 
・  As such, the ISICI tracking mechanisms can be elaborated with various rule sets specific to varying organizations. This may become a basis for creating affiliate networks, where each affiliate can use an affiliate-specific referral codes to identify its own referrals, and thus, receive sales credit for its own sales referrals or even for simple click-throughs that might be compensated on a per-click basis. The same feature can also be used in a security/access control context, where only referrals from a certain trusted web site will be allowed to view confidential information on the target site such as medical patient records, military/intelligence information, or published content requiring subscriber status in order to view.
・  As described elsewhere in this application, the source data that drives modifications of the menu need not be related at all to actual user behavior in connection with the menus. A modification to place a certain model of car at the top of the list could be driven instead by independently-measured sales records indicating that this was a fast-selling model. In Figure 100 (RealPlayer example), songs could be added or dropped from the menu, or their order changed, according to independent source data such as the songs’ current top-40 chart rankings. In Figure 99 (MSN Search example), law firms could be listed within a given city in an order that was driven by how frequently users actually click on the various firms (as monitored through our tracking mechanisms), but the order could alternatively be driven by independent data such as the overall spend of the different firms for advertising or other services from Martindale-Hubbell, the owner of the MultiLink menu.
・  In one embodiment with Chrysler cars, local dealer inventory information is actually retrieved from Chrysler’s back-end systems and brought forward right into the menu upfront 1615 of Figure 16. Such information may be pulled selectively based on the sales performance of the individual dealers. This source data may come from Chrysler’s other back-end systems (e.g., its sales database), or even from the individual dealers’ sales databases. Alternatively, the local dealer information may be selected for display based entirely on the end users’ behavior as measured through our tracking system itself, as has already been described. 
・  Independent source data may be comprised from many other types of sources such as: demographic information about the users, either individually or in aggregate; user preferences and interests as recorded in other independent systems; geographical location of the user, time of day when the menu is being viewed; and/or the like.
・  Overall, the feedback mechanism allows MultiLink menus to become self-improving based on feedback from the real world. That feedback can drive changes in a sophisticated, information-engineered menu that may be an expression of the whole range of customer information needs required by a wide range of customers across a wide range of stages of their purchasing cycle. As such, that expression may become self-improving based on actual empirical information regarding its own effectiveness, and/or based on other independently-collected information that can make the menu more relevant and useful to the customer, as well as more effective for the advertiser. These self-improving modifications can either be fully-automated based on rules, or manually implemented based on human review of the data on user behavior and/or other source data.
・  Even where modifications employ human judgment, the ISICI provides automated mechanisms to greatly assist the process. The MultiLink editor permits updating of the MultiLink menu and then the posting of the updated record to the Handle System; it should be noted that any other "level of indirection" for updating, maintaining and/or serving the menus would serve equally well in principle, and is equally covered by the present invention, however, any other such alternative approaches may derive additional scalability and standards-based benefits from the Handle System. The MultiLink editor may provide a visual indicator of the statistics indicating the relative popularity (e.g., impressions 1836, click throughs 1837, click-through rates, hover times, frequency of rollover, etc.) that has been recorded for these various menu choices. In this manner, the human editor has the empirical tracking data available right within the MultiLink editor where the changes are actually made. 
Numerous Embodiments
・  As such, prior to the ISICI there were no systems that had a feedback loop with takes this kind of data and feeds it back to the beginning of the process where the menus are actually created and maintained in the first place. In terms of distribution and maintenance, ad formats once placed by the ISICI are automatically maintained. Before the ISICI existed, when a change was required, the ad itself had to be changed and then re-served out to all locations. As such, updating ads involved a time delay, especially in the case of Rich Media ads where the purpose of the ad is primarily attention grabbing; such ads are creative-intensive, labor-intensive and graphics-intensive and as a consequence, they require significant amounts of time to update reference links. With such older style ads, even when they were finally revised, the new “master” copy had to be delivered to an ad serving mechanism, which then served the revised ad out to all appropriate locations. In contrast, the ISICI overcomes such limitations because all of the ads in every location may be controlled centrally every time they are loaded; therefore, a revision to a MultiLink menu propagates instantly out to all occurrences of the ad using the MultiLink menu on the Web.
・  Note that the ISICI approach can equally be applied to traditional ad serving mechanisms as well (i.e., MultiLink menus may be served through DoubleClick, et al.). MultiLinks can also be layered right on top of any existing ad format such as a banner, Rich Media ad, contextual ad (e.g., Google’s Sponsored Links), contextual links (e.g., Vibrant Media), video files (e.g., Quicktime), and/or the like. These other ad formats may serve as the delivery mechanism for MultiLink menus. Thus, the MultiLink menus may be distributed through existing distribution methods in addition to and/or in place of the ISICI’s call to a central directory such as the Handle System. Any other “level of indirection” for updating and maintenance would serve equally well in principle by providing additional scalability and standards-based benefits of the Handle System. Another advantage is that MultiLink menu enabled ads are engineered, informational, functional, navigable, and centrally controlled. Further, that central control is now augmented with a feedback loop that improves the menus based on empirical user behavior data as tracked from users’ interactions with the menus. 
・  This feedback may be achieved via human judgment based on this source data (e.g., where the menus are either modified manually, or the automated “assembly line” process is modified to apply different menu creation rules going forward based on human judgment), or the feedback improvements can be fully automated (i.e., become automatically self-improving) by allowed the data to drive changes in the menus directly, based on pre-stored business rules. Example rules include: menu items that are tracked having greater numbers of selections are moved to the top of a menu; menu items that are tracked having greater durations of hover time from an end-user’s cursor are moved to the top of menu; sponsored links with higher bids are placed higher in a menu; newer menu item entries are put higher in a menu (e.g., new product announcements); less frequent menu items are put to the top of a menu list to attempt to increase click throughs; mapping of outside lists are used to generate menu link orders (e.g., top-40 lists are used to rank menu items); and/or the like.
・  Taken together, the integrated suite of services represented by the ISICI enables entirely new conceptual approaches to advertising and customer interaction online. For example, the MultiLink menu enabled ad not only enables the user to pick from a wide variety of choices in relation to an ad (e.g., instead of only a single link resulting in navigation to a splash/landing page), it also enables a fundamentally different approach to servicing users. 
・  The following are some of these new approaches, and the new business processes that they introduce:
・  In one embodiment, because these MultiLinks provide such a wide array of deep links to the user (e.g., MultiLink menus are limited only by the practicalities of screen size, and typically comprise at least 30-40 separate links, neatly unfolding via hierarchical drop-down menus), they expose the user to the entire universe of options available to them; it allows users to navigate through all the choices available at reference target (e.g., a Web site) simply via a mouse rollover, without having to click through from screen to screen on a potentially new and unfamiliar Web site. This “clickless navigation,” which can be explored via rollover alone, radically reduces the amount of time required to bring a user directly to an offer, a shopping cart, or a related product. This “clickless navigation” is superior to the traditional approach of clicking through a link (e.g., to an ad) to a Web site, then waiting for that page to load, reading the new choices on that page, clicking through to something else, determining that the click was in error and having to click back to follow another path incurring similar navigation load and re-display time penalties, etc. The traditional process is rife with potential for frustration, errors, loss of customer attention, a delay for every single click (for a new page to load), and/or the like. MultiLink menus overcome all of these shortcomings.
・  Therefore while traditional ad formats are oriented toward trying to generate user clicks, even to the point of getting compensated based on click-throughs (pay-per-click advertising models such as Google’s AdWords and AdSense), the present invention is premised on the idea that while every click is an opportunity, every click is also a risk. With MultiLinking and clickless navigation, the time between capturing the user’s attention and bringing the user directly to what they really want is radically reduced. After a fast and efficient exploration process via rollover, a single click brings the user directly to what they really want. As a result, MultiLink menus produce significantly higher click-through rates than regular hyperlinks. In addition, when a user does click through a MultiLink menu and arrives at a target (e.g., a website), that user is more likely to make a purchase as compared with visitors who reached the site via traditional Web ads.
・  In addition, MultiLinking presents the opportunity to service both a wider spectrum of customers, and a wider spectrum of stages in customers’ purchasing cycles. There is a natural life cycle to the customer's purchase process, especially in the case of purchasing decisions which are information-intensive (e.g., cars, consumer electronics, professional services such as doctors or lawyers, etc.), and the customer has different information needs at the beginning of the cycle (e.g., 6 months away from buying a car, when they're simply deciding whether to look for a mini-van versus an SUV versus a station wagon) than at the end of the cycle (when they now know the make, model and features they want, and it has come down to who among their local dealers has the best price or incentives, and actually has the car in stock). MultiLinks are able to service the entire spectrum of customers in all these stages of the purchasing cycle, and to do it all within a single menu. Hence the MultiLink menu compresses the purchase cycle.
・  Further, the design and implementation heuristics for MultiLink menus may then becomes more subject to a company’s marketing strategy whereby different customers in different stages of the cycle can be serviced appropriately, yet all via the same ad. This process can be facilitated via consulting services and sharing of best practices. As such, a MultiLink menu directly expresses the advertiser’s marketing strategies with respect to its particular customers and the particular stages of their purchasing cycle. For example in Figure 16, the first menu choice “The Chrysler Story” 1606 expands to display a set of links oriented toward an early-stage customer just getting familiar with different brands. The second choice “The Chrysler Difference” spawns a set of links supporting the choice of Chrysler versus other brands. The third “The Chrysler Lineup” 1618, which is actually shown expanded in the figure, provides detail on the various Chrysler models; in addition, the MultiLink menu takes the user all the way to local dealer inventory information, which has been brought forward all the way from the back-end inventory systems of Chrysler and/or its dealer network, and displayed upfront on the MultiLink menu. 
・  Further, the system is self-improving because the user’s behavior can be monitored and then fed back into the MultiLink creation/maintenance process going forward. For example, local dealers could be added or removed from the menu based on how many (or few) customers actually click on those particular dealers. Or the source data that drives the modification of the menu can be another source entirely, such as Chrysler’s own independent sales records indicating which dealers are turning over the highest volume of sales. Or, once again, the source data that drives menu improvements can also be the tracking data that captures customers’ actual behavior in interacting with the menus: e.g. changing the order of Chrysler models on the menu depending on which models are hovered on the longest, or adding or dropping certain sales incentives based on whether or not they actually draw user click-throughs.
・  MultiLink menus represent a new concept in advertising and indeed in Web navigation generally. The creator of the link, who is after all the expert in knowing its own product line and its strategies for marketing or customer service, defines the overall navigation framework, yet the user is the one who chooses where to go. Unlike the traditional struggle between the advertiser who wants to intrude on the user’s attention, and the user who doesn’t want the distraction, MultiLink drop-down menus are unobtrusive and customer friendly. MultiLink menus are non-disruptive to a user’s browser state. They appear upon rollover and they disappear immediately when the user mouses away. The user finds them informative, useful and efficient, even before having to make a leap of faith by clicking through the ad. Further, the user only clicks through to particular links after already determining that this is where he/she really wants to go. Seeing the full range of choices in advance is like the seeing a glass door and simply deciding whether to go through it to what is already visible on the other side, versus seeing an opaque wooden door and having to make a leap of faith that there is something useful on the other side. This is a win/win, where the advertiser gets to expose the user to a wider variety of information and offers than before, yet it is the user who is empowered to navigate and choose.
・  As such, MultiLink menus may use any number of vehicles for aiding in advertising, ecommerce and user interactions, including:
・  MultiLink-enabled Banner Ads (i.e., display ads) (e.g., 1677 of Figure 16);
・  MultiLink-enabled Sponsored Links (e.g., Google AdSense or AdWords) (e.g., 1417 of Figure 14);
・  MultiLink-enabled contextually-embedded links 1545 of Figure 15;
・  Intermingling of content-oriented MultiLinks (e.g. where a publisher has created MultiLinks for its own content, but is then using the same MultiLink menu as “real estate” on which it can sell sponsorships, special advertiser links, etc.) (e.g., 1565 of Figure 15);
・  Placing of MultiLink menus directly into documents, brochures, PDF files, etc. - where due to their persistence, they will always display the current/up-to-date links that are maintained in the master record; 
・  Placing of MultiLink menus into multimedia files, such as in video files, so when an end-user moves a cursor over the video file, the menu is engaged and the user may pause the video, and the MultiLink menu may further provide information about the scene, products, ads, etc., e.g.; on a home improvement video, Flash video may engage a MultiLink menu, which will have menu items about a product’s specifications from the show, accessories, retailers that offer featured products for sale, etc.
・  Placing of MultiLink ads into Media Players and any other places where a product reference might go (e.g., 667 of Figure 15); and
・  Placing of MultiLinks within corporate intranets or other internal “enterprise environments,” where actual user behavior can drive ongoing, self-improving, highly-effective access to internal resources (e.g., Figure 9 and 175 of Figure 1). 
Integrated information-engineered and Self-Improving facility for advertising, e-commerce and online Customer Interactionscontroller 
・  FIGURE 22 is of a block diagram illustrating embodiments of an Integrated information-engineered and Self-Improving facility for advertising, e-commerce and online Customer Interactions(ISICI) controller 2201. In this embodiment, the ISICIcontroller 2201 may to add, edit, process, store, search, serve, identify, instruct, generate, match, provide and/or update MultiLink related data.
・  Typically, users, which may be people and/or other systems, engage information technology systems (e.g., commonly computers) to facilitate information processing. In turn, computers employ processors to process information; such processors are often referred to as central processing units (CPU). A common form of processor is referred to as a microprocessor. A computer operating system, which, typically, is software executed by CPU on a computer, enables and facilitates users to access and operate computer information technology and resources. Common resources employed in information technology systems include: input and output mechanisms through which data may pass into and out of a computer; memory storage into which data may be saved; and processors by which information may be processed. Often information technology systems are used to collect data for later retrieval, analysis, and manipulation, commonly, which is facilitated through database software. Information technology systems provide interfaces that allow users to access and operate various system components.
・  In one embodiment, the ISICI controller 2201 may be connected to and/or communicate with entities such as, but not limited to: one or more users from user input devices 2211; peripheral devices 2212; and/or a communications network 2213. The ISICI controller may even be connected to and/or communicate with a cryptographic processor device 2228. The ISICI controller may communicate with clients 2233 through the communications network. The ISICI may be configured to serve multiple clients and/or users 2233. In one embodiment, the ISICI may be distributed to better serve ISICI demands and better balance load and/or service requests.
・  Networks are commonly thought to comprise the interconnection and interoperation of clients, servers, and intermediary nodes in a graph topology. It should be noted that the term “server” as used throughout this disclosure refers generally to a computer, other device, software, and/or combination thereof that processes and responds to the requests of users; and is frequently accessed across a communications network. Servers serve their information to requesting “clients.” The term “client” as used herein refers generally to a computer, other device, software, or combination thereof that is capable of processing and making requests and obtaining and processing any responses from servers. Generally, the term “client” and “user” are interchangeable, and are used as such throughout. A computer, other device, software, or combination thereof that facilitates, processes information and requests, and/or furthers the passage of information from a source user to a destination user is commonly referred to as a “node.” Networks are generally thought to facilitate the transfer of information from source points to destinations. A node specifically tasked with furthering the passage of information from a source to a destination is commonly called a “router.” There are many forms of networks such as Local Area Networks (LANs), Pico networks, Wide Area Networks (WANs), Wireless Networks (WLANs), etc. For example, the Internet is generally accepted as being an interconnection of a multitude of networks whereby remote clients and servers may access and interoperate with one another.
・  A ISICI controller 2201 may be based on common computer systems that may comprise, but are not limited to, components such as: a computer systemization 2202 connected to memory 2229.
Computer Systemization
・  A computer systemization 2202 may comprise a clock 2230, central processing unit (CPU) 2203, a read only memory (ROM) 2206, a random access memory (RAM) 2205, and/or an interface bus 2207, and most frequently, although not necessarily, are all interconnected and/or communicating through a system bus 2204. Optionally, the computer systemization may be connected to an internal power source 2286. Optionally, a cryptographic processor 2226 may be connected to the system bus. The system clock typically has a crystal oscillator and provides a base signal. The clock is typically coupled to the system bus and various clock multipliers that will increase or decrease the base operating frequency for other components interconnected in the computer systemization. The clock and various components in a computer systemization drive signals embodying information throughout the system. Such transmission and reception of signals embodying information throughout a computer systemization may be commonly referred to as communications. These communicative signals may further be transmitted, received, and the cause of return and/or reply signal communications beyond the instant computer systemization to: communications networks, input devices, other computer systemizations, peripheral devices, and/or the like. Of course, any of the above components may be connected directly to one another, connected to the CPU, and/or organized in numerous variations employed as exemplified by various computer systems. In one optional embodiment, a global positioning system (GPS) receiver 2275 may be connected to the ISICI2201; for example through the system bus 2204. A single GPS chip such as the Motorola Instant GPS chip may be employed to provide the ISICI 2201 with location awareness.
・  The CPU comprises at least one high-speed data processor adequate to execute component instructions for executing user and/or system-generated requests. The CPU may be a microprocessor such as AMD’s Athlon, Duron and/or Opteron; IBM and/or Motorola’s PowerPC; Intel’s Celeron, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s). The CPU interacts with memory through signal passing through conductive conduits to execute stored instruction code according to conventional data processing techniques. Such signal passing facilitates communication within the ISICIcontroller and beyond through various interfaces. Should processing requirements dictate a greater amount speed, parallel, mainframe and/or super-computer architectures may similarly be employed.Alternatively, should deployment requirements dictate greater portability, smaller Personal Digital Assistants (PDAs) may be employed.
Power Source
・  The power source 2286 may be of any standard form for powering small electronic circuit board devices such as the following power cells: alkaline, lithium hydride, lithium ion, nickel cadmium, solar cells, and/or the like. Other types of AC or DC power sources may be used as well. In the case of solar cells, in one embodiment, the case provides an aperture through which the solar cell may capture photonic energy. The power cell 2286 is connected to at least one of the interconnected subsequent components of the ISICIthereby providing an electric current to all subsequent components. In one example, the power source 2286 is connected to the system bus component 2204. In an alternative embodiment, an outside power source 2286 is provided through a connection across the I/O 2208 interface. For example, a USB and/or IEEE 1394 connection carries both data and power across the connection and is therefore a suitable source of power.
Interface Adapters
・  Interface bus(ses) 2207 may accept, connect, and/or communicate to a number of interface adapters, conventionally although not necessarily in the form of adapter cards, such as but not limited to: input output interfaces (I/O) 2208, storage interfaces 2209, network interfaces 2210, and/or the like. Optionally, cryptographic processor interfaces 2227 similarly may be connected to the interface bus. The interface bus provides for the communications of interface adapters with one another as well as with other components of the computer systemization. Interface adapters are adapted for a compatible interface bus. Interface adapters conventionally connect to the interface bus via a slot architecture. Conventional slot architectures may be employed, such as, but not limited to: Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and/or the like.
・  Storage interfaces 2209 may accept, communicate, and/or connect to a number of storage devices such as, but not limited to: storage devices 2214, removable disc devices, and/or the like. Storage interfaces may employ connection protocols such as, but not limited to: (Ultra) (Serial) Advanced Technology Attachment (Packet Interface) ((Ultra) (Serial) ATA(PI)), (Enhanced) Integrated Drive Electronics ((E)IDE), Institute of Electrical and Electronics Engineers (IEEE) 1394, fiber channel, Small Computer Systems Interface (SCSI), Universal Serial Bus (USB), and/or the like.
・  Network interfaces 2210 may accept, communicate, and/or connect to a communications network 2213. Network interfaces may employ connection protocols such as, but not limited to: direct connect, Ethernet (thick, thin, twisted pair 10/100/1000 Base T, and/or the like), Token Ring, wireless connection such as Bluetooth, Cellular, IEEE 802.11a-x, and/or the like. A communications network may be any one and/or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), I-mode, and/or the like); and/or the like. Carrier mediums may include: cable, satellite, telephone, utility, and/or the like. A network interface may be regarded as a specialized form of an input output interface. Further, multiple network interfaces 2210 may be used to engage with various communications network types 2213. For example, multiple network interfaces may be employed to allow for the communication over broadcast, multicast, and/or unicast networks.
・  Input Output interfaces (I/O) 2208 may accept, communicate, and/or connect to user input devices 2211, peripheral devices 2212, cryptographic processor devices 2228, and/or the like. I/O may employ connection protocols such as, but not limited to: Apple Desktop Bus (ADB); Apple Desktop Connector (ADC); audio: analog, digital, monaural, RCA, stereo, and/or the like; IEEE 1394a/b; infrared; joystick; keyboard; midi; optical; PC AT; PS/2; parallel; radio; serial; USB; video interface: BNC, coaxial, composite, digital, Digital Visual Interface (DVI), RCA, RF antennae, S-Video, VGA, and/or the like; wireless; and/or the like. A common output device is a television set 145, which accepts signals from a video interface. Also, a video display, which typically comprises a Cathode Ray Tube (CRT) or Liquid Crystal Display (LCD) based monitor with an interface (e.g., DVI circuitry and cable) that accepts signals from a video interface, may be used. The video interface composites information generated by a computer systemization and generates video signals based on the composited information in a video memory frame. Typically, the video interface provides the composited video information through a video connection interface that accepts a video display interface (e.g., an RCA composite video connector accepting an RCA composite video cable; a DVI connector accepting a DVI display cable, etc.).
・  User input devices 2211 may be card readers, dongles, finger print readers, gloves, graphics tablets, joysticks, keyboards, mouse (mice), remote controls, retina readers, trackballs, trackpads, and/or the like.
・  Peripheral devices 2212 may be connected and/or communicate to I/O and/or other facilities of the like such as network interfaces, storage interfaces, and/or the like. Peripheral devices may be audio devices, cameras, dongles (e.g., for copy protection, ensuring secure transactions with a digital signature, and/or the like), external processors (for added functionality), goggles, microphones, monitors, network interfaces, printers, scanners, storage devices, video devices, video sources, visors, and/or the like.
・  It should be noted that although user input devices and peripheral devices may be employed, the ISICI controller may be embodied as an embedded, dedicated, and/or monitor-less (i.e., headless) device, wherein access would be provided over a network interface connection.
・  Cryptographic units such as, but not limited to, microcontrollers, processors 2226, interfaces 2227, and/or devices 2228 may be attached, and/or communicate with the ISICI controller. A MC68HC16 microcontroller, commonly manufactured by Motorola Inc., may be used for and/or within cryptographic units. Equivalent microcontrollers and/or processors may also be used. The MC68HC16 microcontroller utilizes a 16-bit multiply-and-accumulate instruction in the 16 MHz configuration and requires less than one second to perform a 512-bit RSA private key operation. Cryptographic units support the authentication of communications from interacting agents, as well as allowing for anonymous transactions. Cryptographic units may also be configured as part of CPU. Other commercially available specialized cryptographic processors include VLSI Technology’s 33 MHz 6868 or Semaphore Communications’ 40 MHz Roadrunner 184.
Memory
・  Generally, any mechanization and/or embodiment allowing a processor to affect the storage and/or retrieval of information is regarded as memory 2229. However, memory is a fungible technology and resource, thus, any number of memory embodiments may be employed in lieu of or in concert with one another. It is to be understood that a ISICI controller and/or a computer systemization may employ various forms of memory 2229. For example, a computer systemization may be configured wherein the functionality of on-chip CPU memory (e.g., registers), RAM, ROM, and any other storage devices are provided by a paper punch tape or paper punch card mechanism; of course such an embodiment would result in an extremely slow rate of operation. In a typical configuration, memory 2229 will include ROM 2206, RAM 2205, and a storage device 2214. A storage device 2214 may be any conventional computer system storage. Storage devices may include a drum; a (fixed and/or removable) magnetic disk drive; a magneto-optical drive; an optical drive (i.e., CD ROM/RAM/Recordable (R), ReWritable (RW), DVD R/RW, etc.); and/or other devices of the like. Thus, a computer systemization generally requires and makes use of memory.
Component Collection
・  The memory 2229 may contain a collection of program and/or database components and/or data such as, but not limited to: operating system component(s) 2215 (operating system); information server component(s) 2216 (information server); user interface component(s) 2217 (user interface); Web browser component(s) 2218 (Web browser); database(s) 2219; cryptographic server component(s) 2220 (cryptographic server); Information Access Multiple Resolution Server (IAMRS) component(s); ISICI component(s) 2235; and/or the like (i.e., collectively a component collection). These components may be stored and accessed from the storage devices and/or from storage devices accessible through an interface bus. Although non-conventional software components such as those in the component collection, typically, are stored in a local storage device 2214, they may also be loaded and/or stored, in full or in part, in memory such as: peripheral devices, RAM, remote storage facilities through a communications network, ROM, various forms of memory, and/or the like.
Operating System
・  The operating system component 2215 is executable instruction code facilitating the operation of a ISICI controller. Typically, the operating system facilitates access of I/O, network interfaces, peripheral devices, storage devices, and/or the like. The operating system may be a highly fault tolerant, scalable, and secure system such as Apple Macintosh OS X (Server), AT&T Plan 9, Be OS, Linux, Unix, and/or the like operating systems. However, more limited and/or less secure operating systems also may be employed such as Apple Macintosh OS, Microsoft DOS, Palm OS, Windows 2000/2003/3.1/95/98/CE/Millenium/NT/XP (Server), and/or the like. An operating system may communicate to and/or with other components in a component collection, including itself, and/or the like. Most frequently, the operating system communicates with other program components, user interfaces, and/or the like. For example, the operating system may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses. The operating system, once executed by the CPU, may enable the interaction with communications networks, data, I/O, peripheral devices, program components, memory, user input devices, and/or the like. The operating system may provide communications protocols that allow the ISICI controller to communicate with other entities through a communications network 2213. Various communication protocols may be used by the ISICI controller as a subcarrier transport mechanism for interaction, such as, but not limited to: multicast, TCP/IP, UDP, unicast, and/or the like.
Information Server
・  An information server component 2216 is comprised of stored instruction code signals that engage the CPU circuit components. The information server may be a conventional Internet information server such as, but not limited to Apache Software Foundation’s Apache, Microsoft’s Internet Information Server, and/or the. The information server may allow for the execution of program components through facilities such as Active Server Page (ASP), ActiveX, (ANSI) (Objective-) C (++), Common Gateway Interface (CGI) scripts, Java, JavaScript, Practical Extraction Report Language (PERL), Python, WebObjects, and/or the like. The information server may support secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), and/or the like. The information server provides results in the form of Web pages to Web browsers, and allows for the manipulated generation of the Web pages through interaction with other program components. After a Domain Name System (DNS) resolution portion of an HTTP request is resolved to a particular information server, the information server resolves requests for information at specified locations on a ISICI controller based on the remainder of the HTTP request. For example, a request such as http://123.124.125.126/myInformation.html might have the IP portion of the request “123.124.125.126” resolved by a DNS server to an information server at that IP address; that information server might in turn further parse the http request for the “/myInformation.html” portion of the request and resolve it to a location in memory containing the information “myInformation.html.” Additionally, other information serving protocols may be employed across various ports, e.g., FTP communications across port 21, and/or the like. An information server may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Also, universal Description, discover and Integration (UDDI), Web Services Description Language (WSDL), and Web Services Flow Language (WSFL) may be used as a basis for data transfer and component updates. Most frequently, the information server communicates with the ISICIdatabase 2219, operating systems, other program components, user interfaces, Web browsers, and/or the like.
・  Access to the ISICI database may be achieved through a number of database bridge mechanisms such as through scripting languages as enumerated below (e.g., CGI) and through inter-application communication channels as enumerated below (e.g., CORBA, WebObjects, etc.). Any data requests through a Web browser are parsed through the bridge mechanism into appropriate grammars as required by the ISICI. In one embodiment, the information server would provide a Web form accessible by a Web browser. Entries made into supplied fields in the Web form are tagged as having been entered into the particular fields, and parsed as such. The entered terms are then passed along with the field tags, which act to instruct the parser to generate queries directed to appropriate tables and/or fields. In one embodiment, the parser may generate queries in standard SQL by instantiating a search string with the proper join/select commands based on the tagged text entries, wherein the resulting command is provided over the bridge mechanism to the ISICI as a query. Upon generating query results from the query, the results are passed over the bridge mechanism, and may be parsed for formatting and generation of a new results Web page by the bridge mechanism. Such a new results Web page is then provided to the information server, which may supply it to the requesting Web browser.
・  Also, an information server may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses.
User Interface
・  The function of computer interfaces in some respects is similar to automobile operation interfaces. Automobile operation interface elements such as steering wheels, gearshifts, and speedometers facilitate the access, operation, and display of automobile resources, functionality, and status. Computer interaction interface elements such as check boxes, cursors, menus, scrollers, and windows (collectively and commonly referred to as widgets) similarly facilitate the access, operation, and display of data and computer hardware and operating system resources, functionality, and status. Operation interfaces are commonly called user interfaces. Graphical user interfaces (GUIs) such as the Apple Macintosh Operating System’s Aqua, Microsoft’s Windows XP, or Unix’s X-Windows provide a baseline and means of accessing and displaying information graphically to users.
・  A user interface component 2217 is comprised of stored instruction code signals that engage the CPU circuit components. The user interface may be a conventional graphic user interface as provided by, with, and/or atop operating systems and/or operating environments such as Apple Macintosh OS, e.g., Aqua, Microsoft Windows (NT/XP), Unix X Windows (KDE, Gnome, and/or the like), mythTV, and/or the like. The user interface may allow for the display, execution, interaction, manipulation, and/or operation of program components and/or system facilities through textual and/or graphical facilities. The user interface provides a facility through which users may affect, interact, and/or operate a computer system. A user interface may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the user interface communicates with operating systems, other program components, and/or the like. The user interface may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses.
Web Browser
・  A Web browser component 2218 is comprised of stored instruction code signals that engage the CPU circuit components. The Web browser may be a conventional hypertext viewing application such as Apple Safari, Microsoft Internet Explorer, Mozilla Firefox, Netscape Navigator, and/or the like. Secure Web browsing may be supplied with 128bit (or greater) encryption by way of HTTPS, SSL, and/or the like. Some Web browsers allow for the execution of program components through facilities such as Java, JavaScript, ActiveX, and/or the like. Web browsers and like information access tools may be integrated into PDAs, cellular telephones, and/or other mobile devices. A Web browser may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the Web browser communicates with information servers, operating systems, integrated program components (e.g., plug-ins), and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses. Of course, in place of a Web browser and information server, a combined application may be developed to perform similar functions of both. The combined application would similarly affect the obtaining and the provision of information to users, user agents, and/or the like from ISICI enabled nodes. The combined application may be nugatory on systems employing standard Web browsers.
Mail Server
・  A mail server component 2221 is comprised of stored instruction code signals that engage the CPU circuit components. The mail server may be a conventional Internet mail server such as, but not limited to sendmail, Microsoft Exchange, and/or the. The mail server may allow for the execution of program components through facilities such as ASP, ActiveX, (ANSI) (Objective-) C (++), CGI scripts, Java, JavaScript, PERL, pipes, Python, WebObjects, and/or the like. The mail server may support communications protocols such as, but not limited to: Internet message access protocol (IMAP), Microsoft Exchange, post office protocol (POP3), simple mail transfer protocol (SMTP), and/or the like. The mail server can route, forward, and process incoming and outgoing mail messages that have been sent, relayed and/or otherwise traversing through and/or to the ISICI. 
・  Access to the ISICI mail may be achieved through a number of APIs offered by the individual Web server components and/or the operating system.
・  Also, a mail server may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses.
Mail Client
・  A mail client component 2222 is comprised of stored instruction code signals that engage the CPU circuit components. The mail client may be a conventional mail viewing application such as Apple Mail, Microsoft Entourage, Microsoft Outlook, Microsoft Outlook Express, Mozilla Thunderbird, and/or the like. Mail clients may support a number of transfer protocols, such as: IMAP, Microsoft Exchange, POP3, SMTP, and/or the like. A mail client may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the mail client communicates with mail servers, operating systems, other mail clients, and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses. Generally, the mail client provides a facility to compose and transmit electronic mail messages.
Cryptographic Server
・  A cryptographic server component 2220 is comprised of stored instruction code signals that engage the CPU circuit components 2203, cryptographic processor 2226, cryptographic processor interface 2227, cryptographic processor device 2228, and/or the like. Cryptographic processor interfaces will allow for expedition of encryption and/or decryption requests by the cryptographic component; however, the cryptographic component, alternatively, may run on a conventional CPU. The cryptographic component allows for the encryption and/or decryption of provided data. The cryptographic component allows for both symmetric and asymmetric (e.g., Pretty Good Privacy (PGP)) encryption and/or decryption. The cryptographic component may employ cryptographic techniques such as, but not limited to: digital certificates (e.g., X.509 authentication framework), digital signatures, dual signatures, enveloping, password access protection, public key management, and/or the like. The cryptographic component will facilitate numerous (encryption and/or decryption) security protocols such as, but not limited to: checksum, Data Encryption Standard (DES), Elliptic Curve Encryption (ECC), International Data Encryption Algorithm (IDEA), Message Digest 5 (MD5, which is a one way hash function), passwords, Rivest Cipher (RC5), Rijndael, RSA (which is an Internet encryption and authentication system that uses an algorithm developed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA), Secure Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS), and/or the like. Employing such encryption security protocols, the ISICI may encrypt all incoming and/or outgoing communications and may serve as node within a virtual private network (VPN) with a wider communications network. The cryptographic component facilitates the process of “security authorization” whereby access to a resource is inhibited by a security protocol wherein the cryptographic component effects authorized access to the secured resource. In addition, the cryptographic component may provide unique identifiers of content, e.g., employing and MD5 hash to obtain a unique signature for an digital audio file. A cryptographic component may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. The cryptographic component supports encryption schemes allowing for the secure transmission of information across a communications network to enable a ISICI component to engage in secure transactions if so desired. The cryptographic component facilitates the secure accessing of resources on ISICIand facilitates the access of secured resources on remote systems; i.e., it may act as a client and/or server of secured resources. Most frequently, the cryptographic component communicates with information servers, operating systems, other program components, and/or the like. The cryptographic component may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses.
ISICI Database
・  A ISICI database component 2219 may be embodied in a database and its stored data. The database is comprised of stored instruction code signals that engage the CPU circuit components; the stored instruction code portion configuring the CPU to process the stored data. The database may be a conventional, fault tolerant, relational, scalable, secure database such as Oracle or Sybase. Relational databases are an extension of a flat file. Relational databases consist of a series of related tables. The tables are interconnected via a key field. Use of the key field allows the combination of the tables by indexing against the key field; i.e., the key fields act as dimensional pivot points for combining information from various tables. Relationships generally identify links maintained between tables by matching primary keys. Primary keys represent fields that uniquely identify the rows of a table in a relational database. More precisely, they uniquely identify rows of a table on the “one” side of a one-to-many relationship.
・  Alternatively, the ISICI database may be implemented using various standard data-structures, such as an array, hash, (linked) list, struct, structured text file (e.g., XML), table, and/or the like. Such data-structures may be stored in memory and/or in (structured) files. In another alternative, an object-oriented database may be used, such as Frontier, ObjectStore, Poet, Zope, and/or the like. Object databases can include a number of object collections that are grouped and/or linked together by common attributes; they may be related to other object collections by some common attributes. Object-oriented databases perform similarly to relational databases with the exception that objects are not just pieces of data but may have other types of functionality encapsulated within a given object. If the ISICI database is implemented as a data-structure, the use of the ISICIdatabase 2219 may be integrated into another component such as the ISICI component 2235. Also, the database may be implemented as a mix of data structures, objects, and relational structures. Databases may be consolidated and/or distributed in countless variations through standard data processing techniques. Portions of databases, e.g., tables, may be exported and/or imported and thus decentralized and/or integrated.
・  In one embodiment, the database component 2219 includes several tables 2219a-i, which are representative of the schema, tables, structures, keys, entities and relationships of the described database. A UNI (e.g., Handle, DOI and/or other UNIs) table 2219a includes fields such as, but not limited to: DOI, creator name, creator contact information, registration agency, and/or the like. An URL table 2219b includes fields such as, but not limited to: DOI, multiple resolution identifier, URL, and/or the like. A metadata table 2219c includes fields such as, but not limited to: DOI, multiple resolution identifier, URL, MultiLink menu specification, custom field 1, custom field 2, etc., and/or the like. A multiple resolution table 2219d includes fields such as, but not limited to: DOI, metadata, and/or the like. A RFID table 2219e includes fields such as, but not limited to: RFID number, DOI, multiple resolution identifier, GPS coordinates, transaction number, and/or the like. A menu specification table 2219f includes fields such as, but not limited to: DOI, metadata, multiple resolution identifier, viewable entry, MultiLink menu specification, menu label, and/or the like. An personal (DOI information) table 2219g includes fields such as, but not limited to: DOI, multiple resolution identifier, telephone number, Voice over IP ID (e.g., the ID user name and password), instant messenger ID (e.g., the ID user name and password), email, metadata, and/or the like. A access control table 2219h includes fields such as, but not limited to: DOI, metadata, multiple resolution identifier, owner, users, control setting, and/or the like. An interlink index table 2219i includes fields such as, but not limited to: DOI, metadata, multiple resolution identifier, sponsored link status, number of matched links, number of missing links, number of unknown links, popularity ranking, and/or the like. A tracker table 2219i includes fields such as, but not limited to: IP address, DOI, multiple resolution identifier, number of times menu item is selected, amount of time menu item is considered, number of time menu item is passed over, and/or the like. All the tables may be related by (enhanced) DOI key field entries as they are unique.
・  In one embodiment, user programs may contain various user interface primitives, which may serve to update the ISICI. Also, various accounts may require custom database tables depending upon the environments and the types of clients a ISICI may need to serve. It should be noted that any unique fields may be designated as a key field throughout. In an alternative embodiment, these tables have been decentralized into their own databases and their respective database controllers (i.e., individual database controllers for each of the above tables). Employing standard data processing techniques, one may further distribute the databases over several computer systemizations and/or storage devices. Similarly, configurations of the decentralized database controllers may be varied by consolidating and/or distributing the various database components 2219a-i. The ISICI may be configured to keep track of various settings, inputs, and parameters via database controllers.
・  A ISICI database may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the ISICI database communicates with a ISICI component, other program components, and/or the like. The database may contain, retain, and provide information regarding other nodes and data.
Information Access Multiple Resolution Server (IAMRS)
・  An IAMRS component 2225 is comprised of stored instruction code signals that engage the CPU circuit components. Generally, the ISICI affects accessing, obtaining and the provision of information, and/or the like between nodes on a communications network. The IAMRS has the ability to resolve UNIs to multiple instantiations. Generally, the IAMRS acts as a lookup facility to create, maintain, and update associations between a given piece of information, its DOI, and its current locations. The IAMRS coordinates with the ISICI database to identify nodes that may be useful for improving data transfer for requested information, for resolving to various formats of the requesting information, providing an enhanced mechanism to create queries regarding the information, and/or the like. An IAMRS enabling access of information between nodes may be developed by employing standard development tools such as, but not limited to: C++, shell scripts, Java, Javascript, SQL commands, Web application server extensions, Apache modules, Perl scripts, binary executables, and/or other mapping tools, and/or the like. In one non-limiting example embodiment, the IAMRS server employs a cryptographic server to encrypt and decrypt communications. The IAMRS may service requests, update association information for UNIs, and much more. A ISICI module may communicate to and/or with other modules in a module collection, including itself, and/or facilities of the like. Most frequently, the IAMRS module communicates with a ISICI database, operating systems, other program modules, and/or the like. The IAMRS may contain, communicate, generate, obtain, and/or provide program module, system, user, and/or data communications, requests, and/or responses
ISICI
・  An ISICI component 2235 is comprised of stored instruction code signals that engage the CPU circuit components. As such, the ISICI effects accessing, obtaining and the provision of information, services, transactions, and/or the like across various communications networks.
・  In one embodiment, the ISICI component may further the provision of MultiLink menus to requesting clients. A ISICImay have access to a MultiLink menu specification that details what appearance the MultiLink menu is to have for a particular requesting entity. The disclosure teaches that multiple ISICImay each provide multiple views of a given MultiLink depending upon the requesting entity and/or the ISICI’s needs. In one embodiment, a ISICI provides advertising views of MultiLinks that vary depending upon for whom the ad is being placed. In one embodiment, the ISICIis separate from the content provider, and facilitates requests for MultiLink menus apart from a content provider’s Web page. In another embodiment, the ISICI is integrated into a content provider’s system. In yet another embodiment, the ISICIprovides an IntraConnect facility that limits access and reference to content within an organization. The ISICI also teaches a MultiLink editor that allows the varying of MultiLink DOI records and menu specifications.. 
・  A ISICI component enabling access of information between nodes may be developed by employing standard development tools such as, but not limited to: (ANSI) (Objective-) C (++), Apache components, binary executables, database adapters, Java, JavaScript, mapping tools, procedural and object oriented development tools, PERL, Python, shell scripts, SQL commands, Web application server extensions, WebObjects, and/or the like. In one embodiment, the ISICI server employs a cryptographic server to encrypt and decrypt communications. A ISICIcomponent may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the ISICI component communicates with a ISICI database, operating systems, other program components, and/or the like. The ISICImay contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses.
Distributed ISICI
・  The structure and/or operation of any of the ISICI node controller components may be combined, consolidated, and/or distributed in any number of ways to facilitate development and/or deployment. Similarly, the component collection may be combined in any number of ways to facilitate deployment and/or development. To accomplish this, one may integrate the components into a common code base or in a facility that can dynamically load the components on demand in an integrated fashion.
・  The component collection may be consolidated and/or distributed in countless variations through standard data processing and/or development techniques. Multiple instances of any one of the program components in the program component collection may be instantiated on a single node, and/or across numerous nodes to improve performance through load-balancing and/or data-processing techniques. Furthermore, single instances may also be distributed across multiple controllers and/or storage devices; e.g., databases. All program component instances and controllers working in concert may do so through standard data processing communication techniques.
・  The configuration of the ISICI controller will depend on the context of system deployment. Factors such as, but not limited to, the budget, capacity, location, and/or use of the underlying hardware resources may affect deployment requirements and configuration. Regardless of if the configuration results in more consolidated and/or integrated program components, results in a more distributed series of program components, and/or results in some combination between a consolidated and distributed configuration, data may be communicated, obtained, and/or provided. Instances of components consolidated into a common code base from the program component collection may communicate, obtain, and/or provide data. This may be accomplished through intra-application data processing communication techniques such as, but not limited to: data referencing (e.g., pointers), internal messaging, object instance variable communication, shared memory space, variable passing, and/or the like.
・  If component collection elements are discrete, separate, and/or external to one another, then communicating, obtaining, and/or providing data with and/or to other component elements may be accomplished through inter-application data processing communication techniques such as, but not limited to: Application Program Interfaces (API) information passage; (distributed) Component Object Model ((D)COM), (Distributed) Object Linking and Embedding ((D)OLE), and/or the like), Common Object Request Broker Architecture (CORBA), process pipes, shared files, and/or the like. Messages sent between discrete component elements for inter-application communication or within memory spaces of a singular component for intra-application communication may be facilitated through the creation and parsing of a grammar. A grammar may be developed by using standard development tools such as lex, yacc, XML, and/or the like, which allow for grammar generation and parsing functionality, which in turn may form the basis of communication messages within and between components. Again, the configuration will depend upon the context of system deployment.
・  The entirety of this disclosure (including the Cover Page, Title, Headings, Field, Background, Summary, Brief Description of the Drawings, Detailed Description, Claims, Abstract, Figures, and otherwise) shows by way of illustration various embodiments in which the claimed inventions may be practiced. In describing embodiments of the invention, in some cases specific terminology has been used for the sake of clarity, however, the invention is not intended to be limited to and/or by the specific terms so selected, and it is to be understood that each specific term includes all technical equivalents which operate in a similar manner to accomplish a similar purpose. It should be noted that terms and or phraseology in this disclosure are not exhaustive in detail, and are not provided as definitive definitions. Rather, the terms are provided herein simply as an aid to the reader. The terms are not limiting of the disclosure and/or claims herein. The use of the terms may contemplate any of the broader, and/or multiple meanings found in common use, dictionaries, technical dictionaries, and/or in actual use in the technical arts, as well as any broadening made throughout this disclosure. Also, the advantages and features of the disclosure are of a representative sample of embodiments only, and are not exhaustive and/or exclusive. They are presented only to assist in understanding and teach the claimed principles. It should be understood that they are not representative of all claimed inventions. As such, certain aspects of the disclosure have not been discussed herein. That alternate embodiments may not have been presented for a specific portion of the invention or that further undescribed alternate embodiments may be available for a portion is not to be considered a disclaimer of those alternate embodiments. It will be appreciated that many of those undescribed embodiments incorporate the same principles of the invention and others are equivalent. Thus, it is to be understood that other embodiments may be utilized and functional, logical, organizational, structural and/or topological modifications may be made without departing from the scope and/or spirit of the disclosure. As such, all examples and/or embodiments are deemed to be non-limiting throughout this disclosure. Also, no inference should be drawn regarding those embodiments discussed herein relative to those not discussed herein other than it is as such for purposes of space and reducing repetition. For instance, it is to be understood that the logical and/or topological structure of any combination of any program components (a component collection), other components and/or any present feature sets as described in the figures and/or throughout are not limited to a fixed operating order and/or arrangement, but rather, any disclosed order is exemplary and all equivalents, regardless of order, are contemplated by the disclosure. Furthermore, it is to be understood that such features are not limited to serial execution, but rather, any number of threads, processes, services, servers, and/or the like that may execute asynchronously, concurrently, in parallel, simultaneously, synchronously, and/or the like are contemplated by the disclosure. As such, some of these features may be mutually contradictory, in that they cannot be simultaneously present in a single embodiment. Similarly, some features are applicable to one aspect of the invention, and inapplicable to others. In addition, the disclosure includes other inventions not presently claimed. Applicant reserves all rights in those presently unclaimed inventions including the right to claim such inventions, file additional applications, continuations, continuations in part, divisions, and/or the like thereof. As such, it should be understood that aspects of the disclosure such as advantages, embodiments, examples, features, functional, logical, organizational, structural, topological, and/or other aspects are not to be considered limitations on the disclosure as defined by the claims or limitations on equivalents to the claims.
CLAIMS
What is claimed is:
1.     A processor enabled method, comprising:
receiving a request for a unique persistent universal name identifier (UPUNI) from a requesting client accessing content,
wherein the request is triggered from the accessing of content and from code embedded in that content, 
wherein the UPUNI identifies a target content asset, and 
wherein the UPUNI is a multi-identifier having multiple references to content items related to the target content asset;
obtaining an UPUNI menu specification, if it exists;
obtaining UPUNI record information from an UPUNI directory;
generating an UPUNI menu specification from metadata in an UPUNI directory, if one is unavailable;
storing the UPUNI menu specification, in the UPUNI directory, in an UPUNI syndicator;
generating an UPUNI menu from the UPUNI menu specification, wherein the UPUNI menu specification is used to specify values from UPUNI record information with which to populate the UPUNI menu;
providing the UPUNI menu to the requesting client that is responsive to the request.
2.     A processor enabled method, comprising:
receiving a request for a unique persistent universal name identifier (UPUNI) from a requesting client accessing content,
wherein the request is triggered from the accessing of content, 
wherein the UPUNI identifies a target content asset, and 
wherein the UPUNI is a multi-identifier having multiple references to content items related to the target content asset;
obtaining an UPUNI menu specification;
obtaining UPUNI record information from an UPUNI directory;
generating an UPUNI menu from the UPUNI menu specification, wherein the UPUNI menu specification is used to specify values from UPUNI record information with which to populate the UPUNI menu.
3.     The method of claim 2, wherein a database has varied menu specifications from multiple advertisement providers, wherein each advertisement provider may provide differing menu specifications for its own advertisers.
4.     The method of claim 3, wherein advertisers may sponsor UPUNI multi-identifiers.
5.     The method of claim 4, wherein a fee may be obtained for increasing search ranking results from interlinked UPUNIs.
6.     The method of claim 5, wherein the UPUNI is associated with a keyword.
7.     The method of claim 3, wherein UPUNI menus may have other UPUNI menus interlinked.
8.     The method of claim 3, wherein UPUNI providers may receive a referral fee for UPUNI menu provision.
9.     The method of claim 3, wherein UPUNI providers may receive a referral fee for UPUNI menu provision.
10.    The method of claim 3, wherein an advertising fee is charged for displaying sponsored UPUNI menus.
11.    The method of claim 2, further, comprising:
generating code for the UPUNI menu.
12.    The method of claim 11, wherein the code is distributed. 
13.    The method of claim 12, wherein the code is HTML.
14.    The method of claim 12, wherein the code is DHTML.
15.    The method of claim 12, wherein the code is Javascript.
16.    The method of claim 2, wherein metadata information regarding the target content asset is stored in an UPUNI directory record.
17.    The method of claim 16, wherein the metadata information is stored as a handle value in the UPUNI directory record.
18.    The method of claim 2, wherein the UPUNI represents a human being.
19.    The method of claim 18, wherein the UPUNI has multi-identifier components representing various aspects of the human being.
20.    The method of claim 19, wherein the UPUNI has access controls limiting access to multi-identifier components.
21.    The method of claim 18, wherein the UPUNI acts as a universal physician identifier.
22.    The method of claim 18, wherein the UPUNI acts as a universal patient identifier.
23.    The method of claim 2, wherein the UPUNI represents a Voice over Internet Protocol account.
24.    The method of claim 2, wherein the UPUNI represents an instant messenger account.
25.    The method of claim 2, wherein the UPUNI represents an RFID.
26.    The method of claim 25, wherein the RFIDs are registered as UPUNIs at the time of manufacture and include an RFID number as part of the UPUNI.
27.    The method of claim 25, wherein transactions involving the RFID are tracked in the UPUNI’s directory record.
28.    The method of claim 2, wherein the UPUNI represents a healthcare record.
29.    The method of claim 2, wherein the UPUNI directory serves an intranet.
30.    The method of claim 29, wherein the intranet causes UPUNIs to resolve to local resources and prevents resolution to a global directory.
31.    The method of claim 2, wherein the UPUNI directory is a global directory.
32.    The method of claim 2, wherein the request is triggered from code embedded in that content.
33.    The method of claim 2, wherein the UPUNI menu specification is obtained from a UPUNI directory.
34.    The method of claim 2, wherein the UPUNI menu specification is obtained from a UPUNI syndicator.
35.    The method of claim 2, further, comprising:
generating an UPUNI menu specification, if one is unavailable.
36.    The method of claim 35, wherein the UPUNI menu specification is generated from metadata in an UPUNI directory.
37.    The method of claim 35, further, comprising:
storing the UPUNI menu specification.
38.    The method of claim 37, wherein the UPUNI menu specification is stored in an UPUNI directory.
39.    The method of claim 37, wherein the UPUNI menu specification is stored in an UPUNI syndicator.
40.    The method of claim 2, further, comprising:
providing the UPUNI menu to the requesting client.
41.    The method of claim 40, further, comprising:
displaying the UPUNI menu to the requesting client that is responsive to content traversal.
42.    The method of claim 40, wherein the menu is displayed when the client traverses over advertisements.
43.    The method of claim 40, wherein the menu is displayed for sponsored search engine query results.
44.    The method of claim 40, further, comprising:
displaying UPUNI menu traversal that is responsive to the requesting client’s menu navigation.
45.    The method of claim 44, further, comprising:
traversing to a target selection responsive to a clients selection of menu items in the UPUNI menu.
46.    A processor enabled method, comprising:
obtaining unique persistent universal name identifier (UPUNI) record information from an UPUNI directory, wherein the UPUNI identifies a target content asset, and wherein the UPUNI is a multi-identifier having multiple references to content items related to the target content asset;
generating a menu specification based on the hierarchical structure of an UPUNI record, wherein first level hierarchical values of a UPUNI record describe and populate a root level of the menu specification, and wherein subsequent nested hierarchical values of the UPUNI record describe and populate nested levels of the menu specification;
storing the UPUNI menu specification, wherein the UPUNI menu specification is stored in an UPUNI syndicator;
generating an UPUNI menu from the UPUNI menu specification, wherein the UPUNI menu specification is used to specify values from UPUNI record information with which to populate the UPUNI menu.
47.    A processor enabled method, comprising:
obtaining unique persistent universal name identifier (UPUNI) record information from an UPUNI directory,
wherein the UPUNI identifies a target content asset, and 
wherein the UPUNI is a multi-identifier having multiple references to content items related to the target content asset;
generating a menu specification based on a hierarchical structure of an UPUNI record.
48.    The method of claim 47, wherein a database has varied menu specifications from multiple advertisement providers, wherein each advertisement provider may provide differing menu specifications for its own advertisers.
49.    The method of claim 48, wherein advertisers may sponsor UPUNI multi-identifiers.
50.    The method of claim 49, wherein a fee may be obtained for increasing search ranking results from interlinked UPUNIs.
51.    The method of claim 50, wherein the UPUNI is associated with a keyword.
52.    The method of claim 48, wherein UPUNI menus may have other UPUNI menus interlinked.
53.    The method of claim 48, wherein UPUNI providers may receive a referral fee for UPUNI menu provision.
54.    The method of claim 48, wherein UPUNI providers may receive a referral fee for UPUNI menu provision.
55.    The method of claim 48, wherein an advertising fee is charged for displaying sponsored UPUNI menus.
56.    The method of claim 2, further, comprising:
generating code for the UPUNI menu.
57.    The method of claim 56, wherein the code is distributed. 
58.    The method of claim 57, wherein the code is HTML.
59.    The method of claim 57, wherein the code is DHTML.
60.    The method of claim 57, wherein the code is Javascript. 
61.    The method of claim 47, wherein the generation of an UPUNI specification occurs at a site other than one having the request for the UPUNI menu embedded in content.
62.    The method of claim 47, wherein the generation of an UPUNI specification occurs at a site other than one request for the UPUNI menu.
63.    The method of claim 47, wherein metadata information regarding the target content asset is stored in an UPUNI directory record.
64.    The method of claim 63, wherein the metadata information is stored as a handle value in the UPUNI directory record.
65.    The method of claim 47, wherein the UPUNI represents a human being.
66.    The method of claim 65, wherein the UPUNI has multi-identifier components representing various aspects of the human being.
67.    The method of claim 66, wherein the UPUNI has access controls limiting access to multi-identifier components.
68.    The method of claim 65, wherein the UPUNI acts as a universal physician identifier.
69.    The method of claim 65, wherein the UPUNI acts as a universal patient identifier.
70.    The method of claim 47, wherein the UPUNI represents a Voice over Internet Protocol account.
71.    The method of claim 47, wherein the UPUNI represents an instant messenger account.
72.    The method of claim 47, wherein the UPUNI represents an RFID.
73.    The method of claim 72, wherein the RFIDs are registered as UPUNIs at the time of manufacture and include an RFID number as part of the UPUNI.
74.    The method of claim 72, wherein transactions involving the RFID are tracked in the UPUNI’s directory record.
75.    The method of claim 47, wherein the UPUNI represents a healthcare record.
76.    The method of claim 47, wherein first level hierarchical values of a UPUNI record describe and populate a root level of the menu specification.
77.    The method of claim 76, wherein subsequent nested hierarchical values of the UPUNI record describe and populate nested levels of the menu specification.
78.    The method of claim 47, further, comprising:
storing the UPUNI menu specification.
79.    The method of claim 78, wherein the UPUNI menu specification is stored in an UPUNI directory.
80.    The method of claim 79, wherein the UPUNI directory serves an intranet.
81.    The method of claim 80, wherein the intranet causes UPUNIs to resolve to local resources and prevents resolution to a global directory.
82.    The method of claim 79, wherein the UPUNI directory is a global directory.
83.    The method of claim 78, wherein the UPUNI menu specification is stored in an UPUNI syndicator.
84.    The method of claim 78, wherein the UPUNI menu specification is stored into a first hierarchical level in the UPUNI record information.
85.    The method of claim 84, wherein the menu specification is stored with indicia that it is to be used as a specification and to prevent further menu specification generation.
86.    The method of claim 85, wherein the indicia is a BOOLEAN true value signifying the existence of a menu specification.
87.    The method of claim 47, hierarchical structure of an UPUNI record includes a field value for each field indicative of it being part of a menu specification.
88.    The method of claim 47, hierarchical structure of an UPUNI record includes a field value for each field indicative of its access control rights.
89.    The method of claim 47, further, comprising:
generating an UPUNI menu from the UPUNI menu specification.
90.    The method of claim 89, wherein the UPUNI menu specification is used to specify values from UPUNI record information with which to populate the UPUNI menu.
91.    The method of claim 47, further, comprising:
providing the UPUNI menu to a requesting client.
92.    The method of claim 91, further, comprising:
displaying the UPUNI menu to the requesting client that is responsive to content traversal.
93.    The method of claim 92, wherein the menu is displayed when the client traverses over advertisements.
94.    The method of claim 92, wherein the menu is displayed for sponsored search engine query results.
95.    The method of claim 91, further, comprising:
displaying UPUNI menu traversal that is responsive to the requesting client’s menu navigation.
96.    The method of claim 95, further, comprising:
traversing to a target selection responsive to a clients selection of menu items in the UPUNI menu.
97.    A processor enabled method, comprising:
obtaining metadata fields and values;
obtaining an UPUNI menu specification, if it exists;
generating an UPUNI menu specification from the metadata fields and values, if one is unavailable;
matching metadata fields to fields in the menu specification;
searching the metadata based on the matched fields for field values;
constructing the target references based on the matched fields and field values;
storing the target references in a UPUNI record in a UPUNI directory.
98.    The method of claim 97, wherein the metadata fields and values are obtained from intraconnected systems.
99.    The method of claim 98, wherein the metadata fields and values are obtained via connectors to the intraconnected systems.
100.   The method of claim 98, wherein the metadata fields and values are obtained are selected from a master metadata repository from the intraconnected systems.
101.   The method of claim 97, wherein metadata information regarding the target content asset is stored in an UPUNI directory record.
102.   The method of claim 101, wherein the metadata information is stored as a handle value in the UPUNI directory record.
103.   The method of claim 97, wherein the UPUNI represents a human being.
104.   The method of claim 103, wherein the UPUNI has multi-identifier components representing various aspects of the human being.
105.   The method of claim 104, wherein the UPUNI has access controls limiting access to multi-identifier components.
106.   The method of claim 103, wherein the UPUNI acts as a universal physician identifier.
107.   The method of claim 103, wherein the UPUNI acts as a universal patient identifier.
108.   The method of claim 97, wherein the UPUNI represents a Voice over Internet Protocol account.
109.   The method of claim 97, wherein the UPUNI represents an instant messenger account.
110.   The method of claim 97, wherein the UPUNI represents an RFID.
111.   The method of claim 110, wherein the RFIDs are registered as UPUNIs at the time of manufacture and include an RFID number as part of the UPUNI.
112.   The method of claim 110, wherein transactions involving the RFID are tracked in the UPUNI’s directory record.
113.   The method of claim 97, wherein the UPUNI represents a healthcare record.
114.   The method of claim 97, wherein the UPUNI directory serves an intranet.
115.   The method of claim 114, wherein the intranet causes UPUNIs to resolve to local resources and prevents resolution to a global directory.
116.   The method of claim 97, wherein the UPUNI directory is a global directory.
117.   The method of claim 97, further, comprising:
embedding the UPUNI into content.
118.   The method of claim 97, further, comprising:
creating an UPUNI menu with links to the target content asset and the target references. 
119.   The method of claim 118, further, comprising:
providing the UPUNI menu to the requesting client.
120.   The method of claim 119, further, comprising:
displaying the UPUNI menu to the requesting client that is responsive to content traversal.
121.   The method of claim 120, wherein the menu is displayed when the client traverses over advertisements.
122.   The method of claim 120, wherein the menu is displayed for sponsored search engine query results.
123.   The method of claim 119, further, comprising:
displaying UPUNI menu traversal that is responsive to the requesting client’s menu navigation.
124.   The method of claim 123, further, comprising:
traversing to a target selection responsive to a clients selection of menu items in the UPUNI menu.
125.   The method of claim 97, further, comprising:
storing the UPUNI menu specification.
126.   The method of claim 125, further, comprising:
embedding the UPUNI menu into content.
127.   The method of claim 125, wherein the UPUNI menu specification is stored in an UPUNI directory.
128.   The method of claim 125, wherein the UPUNI menu specification is stored in an UPUNI syndicator.
129.   The method of claim 97, wherein target references are generated by reverse engineering a computer system.
130.   The method of claim 97, wherein target references are generated by obtaining a Web site map.
131.   The method of claim 130, wherein Web site map is obtained through crawling.
132.   The method of claim 97, wherein target references are generated by obtaining an RSS feed.
133.   The method of claim 97, wherein target references are generated by blog entries.
134.   The method of claim 97, wherein target references are generated by obtaining a main menu from a Web site.
135.   The method of claim 134, wherein main menu is obtained through crawling.
136.   The method of claim 129, wherein the computer system’s search query syntax is used to identify target content assets and items related to the target content asset.
137.   The method of claim 97, wherein target references are generated through a provided query prompt into which metadata field values may be provided.
138.   The method of claim 137, wherein the query prompt is a search engine and top search results are will be used as target references.
139.   The method of claim 97, wherein metadata fields and values are obtained from clients.
140.   The method of claim 139, wherein the metadata is in tab delineated format.
141.   The method of claim 139, wherein the metadata is in XML format.
142.   The method of claim 139, wherein the metadata is in spreadsheet format.
143.   A processor enabled method, comprising:
establishing relationships between unique persistent universal name identifier (UPUNI) and an UPUNI menu,
wherein the UPUNI identifies a target content asset, and 
wherein the UPUNI is a multi-identifier having multiple target references to c湯整瑮椠整獭爠汥瑡摥琠⁯桴⁥慴杲瑥挠湯整瑮愠獳瑥㰻牢ਾ潣獮牴捵楴杮琠敨琠牡敧⁴敲敦敲据獥‬桷牥楥⁮桴⁥慴杲瑥爠晥牥湥散⁳牡⁥潴戠⁥瑳牯摥椠⁮⁡偕乕⁉敲潣摲椠⁮⁡偕乕⁉楤敲瑣牯㭹戼㹲挊敲瑡湩⁧湡唠啐䥎洠湥⁵楷桴氠湩獫琠⁯桴⁥慴杲瑥挠湯整瑮愠獳瑥愠摮琠敨琠牡敧⁴敲敦敲据獥㰮牢ਾ㐱⸴†吠敨洠瑥潨⁤景挠慬浩ㄠ㌴‬桷牥楥⁮敭慴慤慴椠普牯慭楴湯爠来牡楤杮琠敨琠牡敧⁴潣瑮湥⁴獡敳⁴獩猠潴敲⁤湩愠⁮偕乕⁉楤敲瑣牯⁹敲潣摲㰮牢ਾ㐱⸵†吠敨洠瑥潨⁤景挠慬浩ㄠ㐴‬桷牥楥⁮桴⁥敭慴慤慴椠普牯慭楴湯椠⁳瑳牯摥愠⁳⁡慨摮敬瘠污敵椠⁮桴⁥偕乕⁉楤敲瑣牯⁹敲潣摲㰮牢ਾ㐱⸶†吠敨洠瑥潨⁤景挠慬浩ㄠ㌴‬桷牥楥⁮桴⁥偕乕⁉敲牰獥湥獴愠栠浵湡戠楥杮㰮牢ਾ㐱⸷†吠敨洠瑥潨⁤景挠慬浩ㄠ㘴‬桷牥楥⁮桴⁥偕乕⁉慨⁳畭瑬⵩摩湥楴楦牥挠浯潰敮瑮⁳敲牰獥湥楴杮瘠牡潩獵愠灳捥獴漠⁦桴⁥畨慭⁮敢湩⹧戼㹲ㄊ㠴‮†桔⁥敭桴摯漠⁦汣楡⁭㐱ⰷ眠敨敲湩琠敨唠啐䥎栠獡愠捣獥⁳潣瑮潲獬氠浩瑩湩⁧捡散獳琠⁯畭瑬⵩摩湥楴楦牥挠浯潰敮瑮⹳戼㹲ㄊ㤴‮†桔⁥敭桴摯漠⁦汣楡⁭㐱ⰶ眠敨敲湩琠敨唠啐䥎愠瑣⁳獡愠甠楮敶獲污瀠票楳楣湡椠敤瑮晩敩⹲戼㹲ㄊ〵‮†桔⁥敭桴摯漠⁦汣楡⁭㐱眶敨敲湩琠敨唠啐䥎愠瑣⁳獡愠甠楮敶獲污瀠瑡敩瑮椠敤瑮晩敩⹲戼㹲ㄊㄵ‮†桔⁥敭桴摯漠⁦汣楡⁭㐱ⰳ眠敨敲湩琠敨唠啐䥎爠灥敲敳瑮⁳⁡潖捩⁥癯牥䤠瑮牥敮⁴牐瑯捯汯愠捣畯瑮㰮牢ਾ㔱⸲†吠敨洠瑥潨⁤景挠慬浩ㄠ㌴‬桷牥楥⁮桴⁥偕乕⁉敲牰獥湥獴愠⁮湩瑳湡⁴敭獳湥敧⁲捡潣湵⹴戼㹲ㄊ㌵‮†桔⁥敭桴摯漠⁦汣楡⁭㐱ⰳ眠敨敲湩琠敨唠啐䥎爠灥敲敳瑮⁳湡删䥆⹄戼㹲ㄊ㐵‮†桔⁥敭桴摯漠⁦汣楡⁭㔱ⰳ眠敨敲湩琠敨删䥆獄愠敲爠来獩整敲⁤獡唠啐䥎⁳瑡琠敨琠浩⁥景洠湡晵捡畴敲愠摮椠据畬敤愠⁮䙒䑉渠浵敢⁲獡瀠牡⁴景琠敨唠啐䥎㰮牢ਾ㔱⸵†吠敨洠瑥潨⁤景挠慬浩ㄠ㌵‬桷牥楥⁮牴湡慳瑣潩獮椠癮汯楶杮琠敨删䥆⁄牡⁥牴捡敫⁤湩琠敨唠啐䥎胢玙搠物捥潴祲爠捥牯⹤戼㹲ㄊ㘵‮†桔⁥敭桴摯漠⁦汣楡⁭㐱ⰳ眠敨敲湩琠敨唠啐䥎爠灥敲敳瑮⁳⁡敨污桴慣敲爠捥牯⹤戼㹲ㄊ㜵‮†桔⁥敭桴摯漠⁦汣楡⁭㐱ⰳ映牵桴牥‬潣灭楲楳杮㰺牢ਾ†††攠扭摥楤杮琠敨唠啐䥎洠湥⁵湩潴挠湯整瑮㰮牢ਾ㔱⸸†吠敨洠瑥潨⁤景挠慬浩ㄠ㌴‬畦瑲敨Ⱳ挠浯牰獩湩㩧戼㹲 †††瑳牯湩⁧桴⁥慴杲瑥爠晥牥湥散⁳湩琠敨唠啐䥎爠捥牯⁤湩琠敨唠啐䥎搠物捥潴祲㰮牢ਾ㔱⸹†吠敨洠瑥潨⁤景挠慬浩ㄠ㌴‬桷牥楥⁮桴⁥獥慴汢獩敨⁤敲慬楴湯桳灩⁳牡⁥浥潢楤摥椠⁮⁡敭畮猠数楣楦慣楴湯㰮牢ਾ㘱⸰†吠敨洠瑥潨⁤景挠慬浩ㄠ㤵‬畦瑲敨Ⱳ挠浯牰獩湩㩧戼㹲 †††瑳牯湩⁧桴⁥偕乕⁉敭畮猠数楣楦慣楴湯㰮牢ਾ㘱⸱†吠敨洠瑥潨⁤景挠慬浩ㄠ〶‬桷牥楥⁮桴⁥偕乕⁉敭畮猠数楣楦慣楴湯椠⁳瑳牯摥椠⁮湡唠啐䥎搠物捥潴祲㰮牢ਾ㘱⸲†吠敨洠瑥潨⁤景挠慬浩ㄠ〶‬桷牥楥⁮桴⁥偕乕⁉敭畮猠数楣楦慣楴湯椠⁳瑳牯摥椠⁮湡唠啐䥎猠湹楤慣潴⹲戼㹲ㄊ㌶‮†桔⁥敭桴摯漠⁦汣楡⁭㐱ⰳ眠敨敲湩琠牡敧⁴敲敦敲据獥愠敲朠湥牥瑡摥戠⁹敲敶獲⁥湥楧敮牥湩⁧⁡潣灭瑵牥猠獹整⹭戼㹲ㄊ㐶‮†桔⁥敭桴摯漠⁦汣楡⁭㐱ⰳ眠敨敲湩琠牡敧⁴敲敦敲据獥愠敲朠湥牥瑡摥戠⁹扯慴湩湩⁧⁡敗⁢楳整洠灡㰮牢ਾ㘱⸵†吠敨洠瑥潨⁤景挠慬浩ㄠ㐶‬桷牥楥⁮敗⁢楳整洠灡椠⁳扯慴湩摥琠牨畯桧挠慲汷湩⹧戼㹲ㄊ㘶‮†桔⁥敭桴摯漠⁦汣楡⁭㐱ⰳ眠敨敲湩琠牡敧⁴敲敦敲据獥愠敲朠湥牥瑡摥戠⁹扯慴湩湩⁧湡删卓映敥⹤戼㹲ㄊ㜶‮†桔⁥敭桴摯漠⁦汣楡⁭㐱ⰳ眠敨敲湩琠牡敧⁴敲敦敲据獥愠敲朠湥牥瑡摥戠⁹扯慴湩湩⁧汢杯攠瑮楲獥㰮牢ਾ㘱⸸†吠敨洠瑥潨⁤景挠慬浩ㄠ㌴‬桷牥楥⁮慴杲瑥爠晥牥湥散⁳牡⁥敧敮慲整⁤祢漠瑢楡楮杮愠洠楡⁮敭畮映潲⁭⁡敗⁢楳整㰮牢ਾ㘱⸹†吠敨洠瑥潨⁤景挠慬浩ㄠ㠶‬桷牥楥⁮慭湩洠湥⁵獩漠瑢楡敮⁤桴潲杵⁨牣睡楬杮㰮牢ਾ㜱⸰†吠敨洠瑥潨⁤景挠慬浩ㄠ㌶‬桷牥楥⁮桴⁥潣灭瑵牥猠獹整馀⁳敳牡档焠敵祲猠湹慴⁸獩甠敳⁤潴椠敤瑮晩⁹慴杲瑥挠湯整瑮愠獳瑥⁳湡⁤瑩浥⁳敲慬整⁤潴琠敨琠牡敧⁴潣瑮湥⁴獡敳⹴戼㹲ㄊㄷ‮†桔⁥敭桴摯漠⁦汣楡⁭㐱ⰳ眠敨敲湩琠牡敧⁴敲敦敲据獥愠敲朠湥牥瑡摥琠牨畯桧愠瀠潲楶敤⁤畱牥⁹牰浯瑰椠瑮⁯桷捩⁨敭慴慤慴映敩摬瘠污敵⁳慭⁹敢瀠潲楶敤⹤戼㹲ㄊ㈷‮†桔⁥敭桴摯漠⁦汣楡⁭㜱ⰱ眠敨敲湩琠敨焠敵祲瀠潲灭⁴獩愠猠慥捲⁨湥楧敮愠摮琠灯猠慥捲⁨敲畳瑬⁳牡⁥楷汬戠⁥獵摥愠⁳慴杲瑥爠晥牥湥散⹳㰠牢ਾ㜱⸳†吠敨洠瑥潨⁤景挠慬浩ㄠ㌴‬畦瑲敨Ⱳ挠浯牰獩湩㩧戼㹲 †††牰癯摩湩⁧桴⁥偕乕⁉敭畮琠⁯⁡敲畱獥楴杮挠楬湥⹴戼㹲ㄊ㐷‮†桔⁥敭桴摯漠⁦汣楡⁭㜱ⰳ映牵桴牥‬潣灭楲楳杮㰺牢ਾ†††搠獩汰祡湩⁧桴⁥偕乕⁉敭畮琠⁯桴⁥敲畱獥楴杮挠楬湥⁴桴瑡椠⁳敲灳湯楳敶琠⁯潣瑮湥⁴牴癡牥慳⹬戼㹲ㄊ㔷‮†桔⁥敭桴摯漠⁦汣楡⁭㜱ⰴ眠敨敲湩琠敨洠湥⁵獩搠獩汰祡摥眠敨⁮桴⁥汣敩瑮琠慲敶獲獥漠敶⁲摡敶瑲獩浥湥獴㰮牢ਾ㜱⸶†吠敨洠瑥潨⁤景挠慬浩ㄠ㐷‬桷牥楥⁮桴⁥敭畮椠⁳楤灳慬敹⁤潦⁲灳湯潳敲⁤敳牡档攠杮湩⁥畱牥⁹敲畳瑬⹳戼㹲ㄊ㜷‮†桔⁥敭桴摯漠⁦汣楡⁭㜱ⰳ映牵桴牥‬潣灭楲楳杮㰺牢ਾ†††搠獩汰祡湩⁧偕乕⁉敭畮琠慲敶獲污琠慨⁴獩爠獥潰獮癩⁥潴琠敨爠煥敵瑳湩⁧汣敩瑮胢玙洠湥⁵慮楶慧楴湯㰮牢ਾ㜱⸸†吠敨洠瑥潨⁤景挠慬浩ㄠ㜷‬畦瑲敨Ⱳ挠浯牰獩湩㩧戼㹲 †††牴癡牥楳杮琠⁯⁡慴杲瑥猠汥捥楴湯爠獥潰獮癩⁥潴愠挠楬湥獴猠汥捥楴湯漠⁦敭畮椠整獭椠⁮桴⁥偕乕⁉敭畮㰮牢ਾ㜱⸹†吠敨洠瑥潨⁤景挠慬浩ㄠ㌴‬桷牥楥⁮桴⁥偕乕⁉楤敲瑣牯⁹敳癲獥愠⁮湩牴湡瑥㰮牢ਾ㠱⸰†吠敨洠瑥潨⁤景挠慬浩ㄠ㤷‬桷牥楥⁮桴⁥湩牴湡瑥挠畡敳⁳偕乕獉琠⁯敲潳癬⁥潴氠捯污爠獥畯捲獥愠摮瀠敲敶瑮⁳敲潳畬楴湯琠⁯⁡汧扯污搠物捥潴祲㰮牢ਾ㠱⸱†䄠瀠潲散獳牯攠慮汢摥洠瑥潨Ɽ挠浯牰獩湩㩧戼㹲漊瑢楡楮杮甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⠠偕乕⥉爠捥牯⁤湩潦浲瑡潩⁮牦浯愠⁮偕乕⁉楤敲瑣牯ⱹ戼㹲 †††桷牥楥⁮桴⁥偕乕⁉摩湥楴楦獥愠琠牡敧⁴潣瑮湥⁴獡敳ⱴ愠摮戼㹲 †††桷牥楥⁮桴⁥偕乕⁉獩愠洠汵楴椭敤瑮晩敩⁲慨楶杮洠汵楴汰⁥敲敦敲据獥琠⁯潣瑮湥⁴瑩浥⁳敲慬整⁤潴琠敨琠牡敧⁴潣瑮湥⁴獡敳㭴戼㹲搊獩汰祡湩⁧桴⁥偕乕⁉敲潣摲椠普牯慭楴湯㰻牢ਾ摡楤杮映敩摬⁳湡⁤慶畬獥琠⁯桴⁥偕乕⁉敲潣摲‬晩椠獮牴捵整㭤戼㹲搊汥瑥湩⁧楦汥獤愠摮瘠污敵⁳潴琠敨唠啐䥎爠捥牯Ɽ椠⁦湩瑳畲瑣摥㰻牢ਾ污整楲杮映敩摬⁳湡⁤慶畬獥琠⁯桴⁥偕乕⁉敲潣摲‬晩椠獮牴捵整㭤戼㹲猊潴楲杮甠摰瑡摥唠啐䥎爠捥牯⁤湩潦浲瑡潩⁮湩愠⁮偕乕⁉楤敲瑣牯⹹戼㹲ㄊ㈸‮†桔⁥敭桴摯漠⁦汣楡⁭㠱ⰱ映牵桴牥‬潣灭楲楳杮㰺牢ਾ†††搠獩汰祡湩⁧灵慤整⁤偕乕⁉敲潣摲椠普牯慭楴湯愠⁳瑩椠⁳摥瑩摥㰮牢ਾ㠱⸳†吠敨洠瑥潨⁤景挠慬浩ㄠㄸ‬桷牥楥⁮敭慴慤慴椠普牯慭楴湯爠来牡楤杮琠敨琠牡敧⁴潣瑮湥⁴獡敳⁴獩猠潴敲⁤湩愠⁮偕乕⁉楤敲瑣牯⁹敲潣摲㰮牢ਾ㠱⸴†吠敨洠瑥潨⁤景挠慬浩ㄠ㌸‬桷牥楥⁮桴⁥敭慴慤慴椠普牯慭楴湯椠⁳瑳牯摥愠⁳⁡慨摮敬瘠污敵椠⁮桴⁥偕乕⁉楤敲瑣牯⁹敲潣摲㰮牢ਾ㠱⸵†吠敨洠瑥潨⁤景挠慬浩ㄠㄸ‬桷牥楥⁮桴⁥偕乕⁉敲牰獥湥獴愠栠浵湡戠楥杮㰮牢ਾ㠱⸶†吠敨洠瑥潨⁤景挠慬浩ㄠ㔸‬桷牥楥⁮桴⁥偕乕⁉慨⁳畭瑬⵩摩湥楴楦牥挠浯潰敮瑮⁳敲牰獥湥楴杮瘠牡潩獵愠灳捥獴漠⁦桴⁥畨慭⁮敢湩⹧戼㹲ㄊ㜸‮†桔⁥敭桴摯漠⁦汣楡⁭㠱ⰶ眠敨敲湩琠敨唠啐䥎栠獡愠捣獥⁳潣瑮潲獬氠浩瑩湩⁧捡散獳琠⁯畭瑬⵩摩湥楴楦牥挠浯潰敮瑮⹳戼㹲ㄊ㠸‮†桔⁥敭桴摯漠⁦汣楡⁭㠱ⰵ眠敨敲湩琠敨唠啐䥎愠瑣⁳獡愠甠楮敶獲污瀠票楳楣湡椠敤瑮晩敩⹲戼㹲ㄊ㤸‮†桔⁥敭桴摯漠⁦汣楡⁭㠱ⰵ眠敨敲湩琠敨唠啐䥎愠瑣⁳獡愠甠楮敶獲污瀠瑡敩瑮椠敤瑮晩敩⹲戼㹲ㄊ〹‮†桔⁥敭桴摯漠⁦汣楡⁭㠱ⰱ眠敨敲湩琠敨唠啐䥎爠灥敲敳瑮⁳⁡潖捩⁥癯牥䤠瑮牥敮⁴牐瑯捯汯愠捣畯瑮㰮牢ਾ㤱⸱†吠敨洠瑥潨⁤景挠慬浩ㄠㄸ‬桷牥楥⁮桴⁥偕乕⁉敲牰獥湥獴愠⁮湩瑳湡⁴敭獳湥敧⁲捡潣湵⹴戼㹲ㄊ㈹‮†桔⁥敭桴摯漠⁦汣楡⁭㠱ⰱ眠敨敲湩琠敨唠啐䥎爠灥敲敳瑮⁳湡删䥆⹄戼㹲ㄊ㌹‮†桔⁥敭桴摯漠⁦汣楡⁭㤱ⰲ眠敨敲湩琠敨删䥆獄愠敲爠来獩整敲⁤獡唠啐䥎⁳瑡琠敨琠浩⁥景洠湡晵捡畴敲愠摮椠据畬敤愠⁮䙒䑉渠浵敢⁲獡瀠牡⁴景琠敨唠啐䥎㰮牢ਾ㤱⸴†吠敨洠瑥潨⁤景挠慬浩ㄠ㈹‬桷牥楥⁮牴湡慳瑣潩獮椠癮汯楶杮琠敨删䥆⁄牡⁥牴捡敫⁤湩琠敨唠啐䥎胢玙搠物捥潴祲爠捥牯⹤戼㹲ㄊ㔹‮†桔⁥敭桴摯漠⁦汣楡⁭㠱ⰱ眠敨敲湩琠敨唠啐䥎爠灥敲敳瑮⁳⁡敨污桴慣敲爠捥牯⹤戼㹲ㄊ㘹‮†桔⁥敭桴摯漠⁦汣楡⁭㠱ⰱ眠敨敲湩琠敨唠啐䥎搠物捥潴祲猠牥敶⁳湡椠瑮慲敮⹴戼㹲ㄊ㜹‮†桔⁥敭桴摯漠⁦汣楡⁭㤱ⰶ眠敨敲湩琠敨椠瑮慲敮⁴慣獵獥唠啐䥎⁳潴爠獥汯敶琠⁯潬慣⁬敲潳牵散⁳湡⁤牰癥湥獴爠獥汯瑵潩⁮潴愠朠潬慢⁬楤敲瑣牯⹹戼㹲ㄊ㠹‮†桔⁥敭桴摯漠⁦汣楡⁭㠱ⰱ眠敨敲湩琠敨唠啐䥎搠物捥潴祲椠⁳⁡汧扯污搠物捥潴祲㰮牢ਾ㤱⸹†吠敨洠瑥潨⁤景挠慬浩ㄠㄸ‬畦瑲敨Ⱳ挠浯牰獩湩㩧戼㹲 †††敧敮慲楴杮愠洠湥⁵灳捥晩捩瑡潩⁮慢敳⁤湯琠敨甠摰瑡摥唠啐䥎爠捥牯⁤湩潦浲瑡潩⹮戼㹲㈊〰‮†桔⁥敭桴摯漠⁦汣楡⁭㠱ⰱ映牵桴牥‬潣灭楲楳杮㰺牢ਾ†††朠湥牥瑡湩⁧⁡偕乕⁉敭畮戠獡摥漠⁮桴⁥灵慤整⁤偕乕⁉敲潣摲椠普牯慭楴湯㰮牢ਾ〲⸱†䄠瀠潲散獳牯攠慮汢摥洠瑥潨Ɽ挠浯牰獩湩㩧戼㹲爊捥楥楶杮愠爠煥敵瑳映牯愠洠湥⁵灳捥晩捩瑡潩⁮潦⁲⁡湵煩敵瀠牥楳瑳湥⁴湵癩牥慳⁬慮敭椠敤瑮晩敩⁲唨啐䥎Ⱙ戼㹲 †††桷牥楥⁮桴⁥偕乕⁉摩湥楴楦獥愠琠牡敧⁴潣瑮湥⁴獡敳ⱴ愠摮戼㹲 †††桷牥楥⁮桴⁥偕乕⁉獩愠洠汵楴椭敤瑮晩敩⁲慨楶杮洠汵楴汰⁥敲敦敲据獥琠⁯潣瑮湥⁴瑩浥⁳敲慬整⁤潴琠敨琠牡敧⁴潣瑮湥⁴獡敳㭴戼㹲猊慥捲楨杮愠搠瑡扡獡⁥潦⁲桴⁥敭畮猠数楣楦慣楴湯㰻牢ਾ敧敮慲楴杮愠洠湥⁵灳捥晩捩瑡潩⁮潦⁲桴⁥偕乕⁉牦浯洠瑥摡瑡⁡湩愠⁮偕乕⁉楤敲瑣牯ⱹ椠⁦潮敮愠敲映畯摮椠⁮桴⁥慤慴慢敳㰻牢ਾ瑳牯湩⁧桴⁥敭畮猠数楣楦慣楴湯椠⁮桴⁥慤慴慢敳‬晩漠敮眠獡朠湥牥瑡摥㰻牢ਾ敧敮慲楴杮愠⁮偕乕⁉敭畮映潲⁭桴⁥偕乕⁉敭畮猠数楣楦慣楴湯‬桷牥楥⁮桴⁥偕乕⁉敭畮猠数楣楦慣楴湯椠⁳獵摥琠⁯灳捥晩⁹慶畬獥映潲⁭偕乕⁉敲潣摲椠普牯慭楴湯眠瑩⁨桷捩⁨潴瀠灯汵瑡⁥桴⁥偕乕⁉敭畮㰻牢ਾ牰癯摩湩⁧桴⁥偕乕⁉敭畮琠⁯⁡敲畱獥楴杮挠楬湥⁴桴瑡椠⁳敲灳湯楳敶琠⁯桴⁥敲畱獥⹴㰠牢ਾ〲⸲†吠敨洠瑥潨⁤景挠慬浩㈠㄰‬桷牥楥⁮⁡慤慴慢敳栠獡瘠牡敩⁤敭畮猠数楣楦慣楴湯⁳牦浯洠汵楴汰⁥摡敶瑲獩浥湥⁴牰癯摩牥ⱳ眠敨敲湩攠捡⁨摡敶瑲獩浥湥⁴牰癯摩牥洠祡瀠潲楶敤搠晩敦楲杮洠湥⁵灳捥晩捩瑡潩獮映牯椠獴漠湷愠癤牥楴敳獲㰮牢ਾ〲⸳†吠敨洠瑥潨⁤景挠慬浩㈠㈰‬桷牥楥⁮摡敶瑲獩牥⁳慭⁹灳湯潳⁲偕乕⁉畭瑬⵩摩湥楴楦牥⹳戼㹲㈊㐰‮†桔⁥敭桴摯漠⁦汣楡⁭〲ⰳ眠敨敲湩愠映敥洠祡戠⁥扯慴湩摥映牯椠据敲獡湩⁧敳牡档爠湡楫杮爠獥汵獴映潲⁭湩整汲湩敫⁤偕乕獉㰮牢ਾ〲⸵†吠敨洠瑥潨⁤景挠慬浩㈠㐰‬桷牥楥⁮桴⁥偕乕⁉獩愠獳捯慩整⁤楷桴愠欠祥潷摲㰮牢ਾ〲⸶†吠敨洠瑥潨⁤景挠慬浩㈠㈰‬桷牥楥⁮偕乕⁉敭畮⁳慭⁹慨敶漠桴牥唠啐䥎洠湥獵椠瑮牥楬歮摥㰮牢ਾ〲⸷†吠敨洠瑥潨⁤景挠慬浩㈠㈰‬桷牥楥⁮偕乕⁉牰癯摩牥⁳慭⁹敲散癩⁥⁡敲敦牲污映敥映牯唠啐䥎洠湥⁵牰癯獩潩⹮戼㹲㈊㠰‮†桔⁥敭桴摯漠⁦汣楡⁭〲ⰲ眠敨敲湩唠啐䥎瀠潲楶敤獲洠祡爠捥楥敶愠爠晥牥慲⁬敦⁥潦⁲偕乕⁉敭畮瀠潲楶楳湯㰮牢ਾ〲⸹†吠敨洠瑥潨⁤景挠慬浩㈠㈰‬桷牥楥⁮湡愠癤牥楴楳杮映敥椠⁳档牡敧⁤潦⁲楤灳慬楹杮猠潰獮牯摥唠啐䥎洠湥獵㰮牢ਾㄲ⸰†吠敨洠瑥潨⁤景挠慬浩㈠‬畦瑲敨Ⱳ挠浯牰獩湩㩧戼㹲朊湥牥瑡湩⁧潣敤映牯琠敨唠啐䥎洠湥⹵戼㹲㈊ㄱ‮†桔⁥敭桴摯漠⁦汣楡⁭ㄲⰰ眠敨敲湩琠敨挠摯⁥獩搠獩牴扩瑵摥‮戼㹲㈊㈱‮†桔⁥敭桴摯漠⁦汣楡⁭ㄲⰱ眠敨敲湩琠敨挠摯⁥獩䠠䵔⹌戼㹲㈊㌱‮†桔⁥敭桴摯漠⁦汣楡⁭ㄲⰱ眠敨敲湩琠敨挠摯⁥獩䐠呈䱍㰮牢ਾㄲ⸴†吠敨洠瑥潨⁤景挠慬浩㈠ㄱ‬桷牥楥⁮桴⁥潣敤椠⁳慊慶捳楲瑰㰮牢ਾㄲ⸵†吠敨洠瑥潨⁤景挠慬浩㈠㄰‬桷牥楥⁮敭慴慤慴椠普牯慭楴湯爠来牡楤杮琠敨琠牡敧⁴潣瑮湥⁴獡敳⁴獩猠潴敲⁤湩愠⁮偕乕⁉楤敲瑣牯⁹敲潣摲㰮牢ਾㄲ⸶†吠敨洠瑥潨⁤景挠慬浩㈠㔱‬桷牥楥⁮桴⁥敭慴慤慴椠普牯慭楴湯椠⁳瑳牯摥愠⁳⁡慨摮敬瘠污敵椠⁮桴⁥偕乕⁉楤敲瑣牯⁹敲潣摲㰮牢ਾㄲ⸷†吠敨洠瑥潨⁤景挠慬浩㈠㄰‬桷牥楥⁮桴⁥偕乕⁉敲牰獥湥獴愠栠浵湡戠楥杮㰮牢ਾㄲ⸸†吠敨洠瑥潨⁤景挠慬浩㈠㜱‬桷牥楥⁮桴⁥偕乕⁉慨⁳畭瑬⵩摩湥楴楦牥挠浯潰敮瑮⁳敲牰獥湥楴杮瘠牡潩獵愠灳捥獴漠⁦桴⁥畨慭⁮敢湩⹧戼㹲㈊㤱‮†桔⁥敭桴摯漠⁦汣楡⁭ㄲⰸ眠敨敲湩琠敨唠啐䥎栠獡愠捣獥⁳潣瑮潲獬氠浩瑩湩⁧捡散獳琠⁯畭瑬⵩摩湥楴楦牥挠浯潰敮瑮⹳戼㹲㈊〲‮†桔⁥敭桴摯漠⁦汣楡⁭ㄲⰷ眠敨敲湩琠敨唠啐䥎愠瑣⁳獡愠甠楮敶獲污瀠票楳楣湡椠敤瑮晩敩⹲戼㹲㈊ㄲ‮†桔⁥敭桴摯漠⁦汣楡⁭ㄲⰷ眠敨敲湩琠敨唠啐䥎愠瑣⁳獡愠甠楮敶獲污瀠瑡敩瑮椠敤瑮晩敩⹲戼㹲㈊㈲‮†桔⁥敭桴摯漠⁦汣楡⁭〲ⰱ眠敨敲湩琠敨唠啐䥎爠灥敲敳瑮⁳⁡潖捩⁥癯牥䤠瑮牥敮⁴牐瑯捯汯愠捣畯瑮㰮牢ਾ㈲⸳†吠敨洠瑥潨⁤景挠慬浩㈠㄰‬桷牥楥⁮桴⁥偕乕⁉敲牰獥湥獴愠⁮湩瑳湡⁴敭獳湥敧⁲捡潣湵⹴戼㹲㈊㐲‮†桔⁥敭桴摯漠⁦汣楡⁭〲ⰱ眠敨敲湩琠敨唠啐䥎爠灥敲敳瑮⁳湡删䥆⹄戼㹲㈊㔲‮†桔⁥敭桴摯漠⁦汣楡⁭㈲ⰴ眠敨敲湩琠敨删䥆獄愠敲爠来獩整敲⁤獡唠啐䥎⁳瑡琠敨琠浩⁥景洠湡晵捡畴敲愠摮椠据畬敤愠⁮䙒䑉渠浵敢⁲獡瀠牡⁴景琠敨唠啐䥎㰮牢ਾ㈲⸶†吠敨洠瑥潨⁤景挠慬浩㈠㐲‬桷牥楥⁮牴湡慳瑣潩獮椠癮汯楶杮琠敨删䥆⁄牡⁥牴捡敫⁤湩琠敨唠啐䥎胢玙搠物捥潴祲爠捥牯⹤戼㹲㈊㜲‮†桔⁥敭桴摯漠⁦汣楡⁭〲ⰱ眠敨敲湩琠敨唠啐䥎爠灥敲敳瑮⁳⁡敨污桴慣敲爠捥牯⹤戼㹲㈊㠲‮†桔⁥敭桴摯漠⁦汣楡⁭〲ⰱ眠敨敲湩琠敨朠湥牥瑡潩⁮景愠⁮偕乕⁉敭畮漠捣牵⁳瑡愠猠瑩⁥瑯敨⁲桴湡漠敮栠癡湩⁧桴⁥敲畱獥⁴潦⁲桴⁥偕乕⁉敭畮攠扭摥敤⁤湩挠湯整瑮㰮牢ਾ㈲⸹†吠敨洠瑥潨⁤景挠慬浩㈠㄰‬桷牥楥⁮桴⁥敧敮慲楴湯漠⁦湡唠啐䥎洠湥⁵捯畣獲愠⁴⁡楳整漠桴牥琠慨⁮湯⁥敲畱獥⁴潦⁲桴⁥偕乕⁉敭畮㰮牢ਾ㌲⸰†吠敨洠瑥潨⁤景挠慬浩㈠㄰‬桷牥楥⁮桴⁥慤慴慢敳栠獡瘠牡敩⁤敭畮猠数楣楦慣楴湯⁳牦浯洠汵楴汰⁥摡敶瑲獩浥湥⁴牰癯摩牥ⱳ眠敨敲湩攠捡⁨摡敶瑲獩浥湥⁴牰癯摩牥洠祡瀠潲楶敤搠晩敦楲杮洠湥⁵灳捥晩捩瑡潩獮映牯椠獴漠湷愠癤牥楴敳獲㰮牢ਾ㌲⸱†吠敨洠瑥潨⁤景挠慬浩㈠㄰‬桷牥楥⁮桴⁥偕乕⁉敭畮琠慨⁴獩瀠潲楶敤⁤潴愠爠煥敵瑳湩⁧汣敩瑮椠⁳慢敳⁤湯琠敨挠楬湥馀⁳摩湥楴祦湩⁧湩楤楣⹡㰠牢ਾ㌲⸲†吠敨洠瑥潨⁤景挠慬浩㈠㄰‬桷牥楥⁮桴⁥敲畱獥⁴獩琠楲杧牥摥映潲⁭潣敤攠扭摥敤⁤湩挠湯整瑮‮戼㹲㈊㌳‮†桔⁥敭桴摯漠⁦汣楡⁭〲ⰱ映牵桴牥‬潣灭楲楳杮㰺牢ਾ†††搠獩汰祡湩⁧桴⁥偕乕⁉敭畮琠⁯桴⁥敲畱獥楴杮挠楬湥⁴桴瑡椠⁳敲灳湯楳敶琠⁯潣瑮湥⁴牴癡牥慳⹬戼㹲㈊㐳‮†桔⁥敭桴摯漠⁦汣楡⁭〲ⰱ映牵桴牥‬潣灭楲楳杮㰺牢ਾ†††搠獩汰祡湩⁧偕乕⁉敭畮琠慲敶獲污琠慨⁴獩爠獥潰獮癩⁥潴琠敨爠煥敵瑳湩⁧汣敩瑮胢玙洠湥⁵慮楶慧楴湯㰮牢ਾ㌲⸵†吠敨洠瑥潨⁤景挠慬浩㈠㐳‬桷牥楥⁮桴⁥敭畮椠⁳楤灳慬敹⁤桷湥琠敨挠楬湥⁴牴癡牥敳⁳癯牥愠癤牥楴敳敭瑮⹳戼㹲㈊㘳‮†桔⁥敭桴摯漠⁦汣楡⁭㌲ⰴ眠敨敲湩琠敨洠湥⁵獩搠獩汰祡摥映牯猠潰獮牯摥猠慥捲⁨湥楧敮焠敵祲爠獥汵獴㰮牢ਾ㌲⸷†吠敨洠瑥潨⁤景挠慬浩㈠㐳‬畦瑲敨Ⱳ挠浯牰獩湩㩧戼㹲 †††牴癡牥楳杮琠⁯⁡慴杲瑥猠汥捥楴湯爠獥潰獮癩⁥潴愠挠楬湥獴猠汥捥楴湯漠⁦敭畮椠整獭椠⁮桴⁥偕乕⁉敭畮㰮牢ਾ㌲⸸†吠敨洠瑥潨⁤景挠慬浩㈠㄰‬桷牥楥⁮桴⁥偕乕⁉楤敲瑣牯⁹敳癲獥愠⁮湩牴湡瑥㰮牢ਾ㌲⸹†吠敨洠瑥潨⁤景挠慬浩㈠㠳‬桷牥楥⁮桴⁥湩牴湡瑥挠畡敳⁳偕乕獉琠⁯敲潳癬⁥潴氠捯污爠獥畯捲獥愠摮瀠敲敶瑮⁳敲潳畬楴湯琠⁯⁡汧扯污搠物捥潴祲㰮牢ਾ㐲⸰†䄠瀠潲散獳牯攠慮汢摥洠瑥潨Ɽ挠浯牰獩湩㩧戼㹲挊慲汷湩⁧捡潲獳愠挠浯畭楮慣楴湯⁳敮睴牯⁫潦⁲湵煩敵瀠牥楳瑳湥⁴湵癩牥慳⁬慮敭椠敤瑮晩敩獲⠠偕乕獉 湡⁤敧敮慲楴杮椠摮硥湩⁧景唠啐䥎ⱳ戼㹲 †††桷牥楥⁮桴⁥偕乕⁉摩湥楴楦獥愠琠牡敧⁴潣瑮湥⁴獡敳ⱴ愠摮戼㹲 †††桷牥楥⁮桴⁥偕乕⁉獩愠洠汵楴椭敤瑮晩敩⁲慨楶杮洠汵楴汰⁥敲敦敲据獥琠⁯潣瑮湥⁴瑩浥⁳敲慬整⁤潴琠敨琠牡敧⁴潣瑮湥⁴獡敳㭴戼㹲漊瑢楡楮杮琠牡敧⁴偕乕獉映牯戠獡獩漠⁦潣灭牡獩湯㰻牢ਾ潣灭牡湩⁧慴杲瑥唠啐䥎⁳潴唠啐䥎⁳潦湵⁤桷汩⁥湩敤⁸牣睡楬杮圠扥猠瑩獥㰻牢ਾ敤整浲湩湩⁧⁡敤牧敥漠⁦湩整汲湩楫杮映牯琠牡敧⁴偕乕獉戠⁹潮楴杮愠渠浵敢⁲景洠瑡档獥愠摮渠湯洭瑡档獥愠⁳敢睴敥⁮桴⁥慴杲瑥唠啐䥎⁳湡⁤潴映畯摮唠啐䥎ⱳ戼㹲甊摰瑡湩⁧湡唠啐䥎椠摮硥椠⁮湡唠啐䥎搠瑡扡獡⁥楷桴搠瑥牥業敮⁤敤牧敥漠⁦湩整汲湩楫杮椠普牯慭楴湯‮戼㹲㈊ㄴ‮†⁁牰捯獥潳⁲湥扡敬⁤敭桴摯‬潣灭楲楳杮㰺牢ਾ扯慴湩湩⁧慴杲瑥甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⁳唨啐䥎⥳映牯戠獡獩漠⁦潣灭牡獩湯‬桷牥楥⁮桴⁥偕乕⁉摩湥楴楦獥愠琠牡敧⁴潣瑮湥⁴獡敳㭴戼㹲挊浯慰楲杮琠牡敧⁴偕乕獉琠⁯偕乕獉映畯摮眠楨敬椠摮硥挠慲汷湩⁧敗⁢楳整㭳戼㹲搊瑥牥業楮杮愠搠来敲⁥景椠瑮牥楬歮湩⁧潦⁲慴杲瑥唠啐䥎⁳祢渠瑯湩⁧⁡畮扭牥漠⁦慭捴敨⁳湡⁤潮⵮慭捴敨⁳獡戠瑥敷湥琠敨琠牡敧⁴偕乕獉愠摮琠⁯潦湵⁤偕乕獉‮戼㹲㈊㈴‮†桔⁥敭桴摯漠⁦汣楡⁭㐲ⰱ映牵桴牥‬潣灭楲楳杮㰺牢ਾ牣睡楬杮愠牣獯⁳⁡潣浭湵捩瑡潩獮渠瑥潷歲映牯唠啐䥎⁳湡⁤敧敮慲楴杮椠摮硥湩⁧景唠啐䥎⹳戼㹲㈊㌴‮†桔⁥敭桴摯漠⁦汣楡⁭㐲ⰱ映牵桴牥‬潣灭楲楳杮㰺牢ਾ灵慤楴杮愠⁮偕乕⁉湩敤⁸湩愠⁮偕乕⁉慤慴慢敳眠瑩⁨敤整浲湩摥搠来敲⁥景椠瑮牥楬歮湩⁧湩潦浲瑡潩⹮戼㹲㈊㐴‮†桔⁥敭桴摯漠⁦汣楡⁭㐲ⰱ眠敨敲湩琠敨唠啐䥎椠⁳⁡畭瑬⵩摩湥楴楦牥栠癡湩⁧畭瑬灩敬爠晥牥湥散⁳潴挠湯整瑮椠整獭爠汥瑡摥琠⁯桴⁥慴杲瑥挠湯整瑮愠獳瑥㰮牢ਾ㐲⸵†吠敨洠瑥潨⁤景挠慬浩㈠ㄴ‬桷牥楥⁮桴⁥偕乕⁉獩愠洠汵楴椭敤瑮晩敩⁲慨楶杮洠汵楴汰⁥敲敦敲据獥琠⁯潣瑮湥⁴瑩浥⁳敲慬整⁤潴琠敨琠牡敧⁴潣瑮湥⁴獡敳⹴戼㹲㈊㘴‮†桔⁥敭桴摯漠⁦汣楡⁭㐲ⰱ眠敨敲湩琠敨琠牡敧⁴偕乕獉愠敲猠潰獮牯摥㰮牢ਾ㐲⸷†吠敨洠瑥潨⁤景挠慬浩㈠ㄴ‬桷牥楥⁮桴⁥慴杲瑥唠啐䥎⁳牡⁥湩楤楶畤污祬猠数楣楦摥㰮牢ਾ㐲⸸†吠敨洠瑥潨⁤景挠慬浩㈠ㄴ‬桷牥楥⁮桴⁥慴杲瑥唠啐䥎⁳牡⁥扯慴湩摥映潲⁭⁡慤慴慢敳漠⁦湩敤數⁤偕乕獉㰮牢ਾ㐲⸹†吠敨洠瑥潨⁤景挠慬浩㈠ㄴ‬桷牥楥⁮敤整浲湩瑡潩⁮景搠来敲⁥景椠瑮牥楬歮湩⁧獩瀠牥潦浲摥映牯攠敶祲欠潮湷唠啐䥎㰮牢ਾ㔲⸰†吠敨洠瑥潨⁤景挠慬浩㈠㤴‬畦瑲敨Ⱳ挠浯牰獩湩㩧戼㹲朊湥牥瑡湩⁧⁡慲歮湩⁧景椠瑮牥楬歮摥唠啐䥎⹳戼㹲㈊ㄵ‮†桔⁥敭桴摯漠⁦汣楡⁭㔲ⰰ眠敨敲湩琠敨爠湡楫杮猠汥捥獴唠啐䥎⁳牦浯愠⁮湩整汲湩⁫慤慴慢敳㰮牢ਾ㔲⸲†吠敨洠瑥潨⁤景挠慬浩㈠ㄵ‬桷牥楥⁮桴⁥敳敬瑣潩⁮楬業獴爠湡楫杮爠獥汵獴琠⁯⁡敳瑣牯㰮牢ਾ㔲⸳†吠敨洠瑥潨⁤景挠慬浩㈠ㄵ‬桷牥楥⁮桴⁥敳敬瑣潩⁮楬業獴爠湡楫杮爠獥汵獴琠⁯⁡牰摯捵⹴戼㹲㈊㐵‮†桔⁥敭桴摯漠⁦汣楡⁭㔲ⰱ眠敨敲湩琠敨猠汥捥楴湯氠浩瑩⁳慲歮湩⁧敲畳瑬⁳潴愠琠浩⁥数楲摯㰮牢ਾ㔲⸵†吠敨洠瑥潨⁤景挠慬浩㈠〵‬桷牥楥⁮桴⁥慲歮湩獧愠敲朠湥牥瑡摥瀠牥潩楤慣汬⹹戼㹲㈊㘵‮†桔⁥敭桴摯漠⁦汣楡⁭㔲ⰰ眠敨敲湩琠敨爠湡楫杮⁳牡⁥潳摬㰮牢ਾ㔲⸷†吠敨洠瑥潨⁤景挠慬浩㈠ㄴ‬桷牥楥⁮桴⁥敤牧敥漠⁦湩整汲湩楫杮椠普牯慭楴湯椠⁳潳摬㰮牢ਾ㔲⸸†䄠瀠潲散獳牯愠捣獥楳汢⁥敭楤浵栠癡湩⁧楳湧污猠慴整ⱳ眠敨敲湩琠敨猠杩慮⁬瑳瑡獥攠扭摯⁹⁡慤慴猠牴捵畴敲栠癡湩⁧湩整牲汥瑡摥搠瑡⁡祴数ⱳ挠浯牰獩湩㩧戼㹲愊甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⠠偕乕⥉㰻牢ਾ⁡敲敦敲据⁥潴愠琠牡敧⁴潣瑮湥⁴獡敳㭴戼㹲洊汵楴汰⁥敲敦敲据獥琠⁯潣瑮湥⁴瑩浥⁳敲慬整⁤潴琠敨琠牡敧⁴潣瑮湥⁴獡敳㭴戼㹲愊映敩摬瘠污敵映牯攠捡⁨慤慴琠灹⁥湩楤慣楴敶漠⁦敢湩⁧慰瑲漠⁦⁡敭畮猠数楣楦慣楴湯‬桷牥楥⁮潰楳楴敶椠摮捩慩眠汩⁬敲畳瑬椠⁮⁡慤慴琠灹⁥敢湩⁧獵摥愠⁳慰瑲漠⁦桴⁥敭畮猠数楣楦慣楴湯‬湡⁤敮慧楴敶椠摮捩慩眠汩⁬敲畳瑬椠⁮杩潮楲杮愠搠瑡⁡祴数㰮牢ਾ㔲⸹†吠敨洠摥畩⁭景挠慬浩㈠㠵‬畦瑲敨Ⱳ挠浯牰獩湩㩧戼㹲愊⁮捡散獳挠湯牴汯映敩摬瘠污敵映牯攠捡⁨慤慴琠灹⁥灳捥晩楹杮愠捣獥⁳楲桧獴映牯攠捡⁨慤慴琠灹⹥戼㹲㈊〶‮†⁁牰捯獥潳⁲捡散獳扩敬洠摥畩⁭慨楶杮猠杩慮⁬瑳瑡獥‬桷牥楥⁮桴⁥楳湧污猠慴整⁳浥潢祤愠搠瑡⁡瑳畲瑣牵⁥慨楶杮椠瑮牥敲慬整⁤慤慴琠灹獥‬潣灭楲楳杮㰺牢ਾ⁡湵煩敵瀠牥楳瑳湥⁴湵癩牥慳⁬慮敭椠敤瑮晩敩⁲唨啐䥎㬩戼㹲愊爠晥牥湥散琠⁯⁡慴杲瑥挠湯整瑮愠獳瑥㰻牢ਾ畭瑬灩敬爠晥牥湥散⁳潴挠湯整瑮椠整獭爠汥瑡摥琠⁯桴⁥慴杲瑥挠湯整瑮愠獳瑥㰻牢ਾ湡愠捣獥⁳潣瑮潲⁬楦汥⁤慶畬⁥潦⁲慥档搠瑡⁡祴数猠数楣祦湩⁧捡散獳爠杩瑨⁳潦⁲慥档搠瑡⁡祴数㰮牢ਾ㘲⸱†吠敨洠摥畩⁭景挠慬浩㈠〶‬畦瑲敨Ⱳ挠浯牰獩湩㩧戼㹲愊映敩摬瘠污敵映牯攠捡⁨慤慴琠灹⁥湩楤慣楴敶漠⁦敢湩⁧慰瑲漠⁦⁡敭畮猠数楣楦慣楴湯‬桷牥楥⁮潰楳楴敶椠摮捩慩眠汩⁬敲畳瑬椠⁮⁡慤慴琠灹⁥敢湩⁧獵摥愠⁳慰瑲漠⁦桴⁥敭畮猠数楣楦慣楴湯‬湡⁤敮慧楴敶椠摮捩慩眠汩⁬敲畳瑬椠⁮杩潮楲杮愠搠瑡⁡祴数㰮牢ਾ㘲⸲†䄠瀠潲散獳牯愠捣獥楳汢⁥敭楤浵栠癡湩⁧楳湧污猠慴整ⱳ眠敨敲湩琠敨猠杩慮⁬瑳瑡獥攠扭摯⁹⁡慤慴猠牴捵畴敲栠癡湩⁧湩整牲汥瑡摥搠瑡⁡祴数ⱳ挠浯牰獩湩㩧戼㹲昊物瑳氠癥汥栠敩慲捲楨慣⁬慶畬獥映潲⁭敭慴慤慴映敩摬⁳湡⁤慶畬獥映潲⁭⁡湵煩敵瀠牥楳瑳湥⁴湵癩牥慳⁬慮敭椠敤瑮晩敩⁲唨啐䥎Ⱙ眠敨敲湩琠敨映物瑳氠癥汥栠敩慲捲楨慣⁬慶畬獥椠⁮⁡楨牥牡档⁹牡⁥潴挠浯牰獩⁥⁡潲瑯氠癥汥猠牴捵畴敲漠⁦⁡偕乕⁉敭畮㰻牢ਾ畳獢煥敵瑮渠獥整⁤敬敶⁬楨牥牡档捩污瘠污敵⁳牦浯洠瑥摡瑡⁡楦汥獤愠摮瘠污敵⁳牦浯琠敨唠啐䥎‬晩愠慶汩扡敬㰬牢ਾ†††眠敨敲湩攠捡⁨畳獢煥敵瑮渠獥整⁤敬敶⁬獩爠汥瑡摥琠⁯⁡楨桧牥氠癥汥椠⁮桴⁥楨牥牡档㭹戼㹲爊晥牥湥散⁳潴挠湯整瑮椠整獭爠汥瑡摥琠⁯⁡慴杲瑥挠湯整瑮愠獳瑥‬桷牥楥⁮桴⁥敲敦敲据獥琠⁯潣瑮湥⁴瑩浥⁳牡⁥獡潳楣瑡摥眠瑩⁨慥档渠獥整⁤敬敶⁬楨牥牡档捩污瘠污敵琠慨⁴獩愠⁴⁡整浲湩污氠癥汥椠⁮桴⁥楨牥牡档⹹戼㹲㈊㌶‮†桔⁥敭楤浵漠⁦汣楡⁭㘲ⰲ映牵桴牥‬潣灭楲楳杮㰺牢ਾ湩瑳畲瑣潩⁮楳湧污⁳潴朠湥牥瑡⁥⁡敭畮戠獡摥漠⁮桴⁥慤慴琠灹獥㰮牢ਾ㘲⸴†䤠⁮敭潭祲‬湡椠瑮牥捡楴湯椠瑮牥慦散‬潣灭楲楳杮›戼㹲椊獮牴捵楴湯猠杩慮獬‬桷牥楥⁮桴⁥湩整慲瑣潩⁮湩整晲捡⁥獩爠獥潰獮癩⁥潴甠敳⁲湡⁤祳瑳浥攠敶瑮猠杩慮獬愠摮眠敨敲湩琠敨椠獮牴捵楴湯猠杩慮獬愠敲椠獳敵扡敬戠⁹⁡牰捯獥潳⁲潴椠癮歯㩥戼㹲昊物瑳氠癥汥栠敩慲捲楨慣⁬敭畮⁳牦浯瘠污敵⁳牦浯洠瑥摡瑡⁡楦汥獤愠摮瘠污敵⁳牦浯愠甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⠠偕乕⥉㰬牢ਾ†††眠敨敲湩琠敨映敩摬⁳湡⁤慶畬獥甠敳⁤牡⁥灳捥晩敩⁤祢愠洠湥⁵灳捥晩捩瑡潩㭮戼㹲猊扵敳畱湥⁴敮瑳摥氠癥汥栠敩慲捲楨慣⁬敭畮⁳牦浯瘠污敵⁳牦浯洠瑥摡瑡⁡楦汥獤愠摮瘠污敵⁳牦浯琠敨唠啐䥎‬晩愠慶汩扡敬㰬牢ਾ†††眠敨敲湩琠敨映敩摬⁳湡⁤慶畬獥甠敳⁤牡⁥灳捥晩敩⁤祢愠洠湥⁵灳捥晩捩瑡潩Ɱ愠摮戼㹲 †††桷牥楥⁮慥档猠扵敳畱湥⁴敮瑳摥氠癥汥洠湥⁵灳睡獮映潲⁭瑩⁳敲慬整⁤楨桧牥氠癥汥洠湥㭵戼㹲爊晥牥湥散⁳潴挠湯整瑮椠整獭爠汥瑡摥琠⁯⁡慴杲瑥挠湯整瑮愠獳瑥㰬牢ਾ†††眠敨敲湩琠敨爠晥牥湥散⁳潴挠湯整瑮椠整獭愠敲愠獳捯慩整⁤楷桴攠捡⁨敮瑳摥氠癥汥栠敩慲捲楨慣⁬慶畬⁥桴瑡椠⁳瑡愠琠牥業慮⁬敬敶⁬湩琠敨栠敩慲捲票‬戼㹲 †††桷牥楥⁮潮⵮整浲湩污洠湥獵愠敲爠獥潰獮癩⁥潴甠敳⁲敳敬瑣潩獮琠⁯灳睡⁮敲慬整⁤敮瑳摥洠湥獵‬湡⁤戼㹲 †††桷牥楥⁮整浲湩污洠湥獵愠敲爠獥潰獮癩⁥潴甠敳⁲敳敬瑣潩獮琠⁯敧敮慲整椠獮牴捵楴湯猠杩慮獬琠⁯慮楶慧整琠⁯桴⁥敲敦敲据獥㰮牢ਾ㘲⸵†䄠猠獹整⁭景洠湥⁵敧敮慲楴湯‬潣灭楲楳杮㰺牢ਾ敭湡⁳潴爠捥楥敶愠爠煥敵瑳映牯愠甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⠠偕乕⥉映潲⁭⁡敲畱獥楴杮挠楬湥⁴捡散獳湩⁧潣瑮湥ⱴ戼㹲 †††桷牥楥⁮桴⁥敲畱獥⁴獩琠楲杧牥摥映潲⁭桴⁥捡散獳湩⁧景挠湯整瑮‬戼㹲 †††桷牥楥⁮桴⁥偕乕⁉摩湥楴楦獥愠琠牡敧⁴潣瑮湥⁴獡敳ⱴ愠摮㰠牢ਾ†††眠敨敲湩琠敨唠啐䥎椠⁳⁡畭瑬⵩摩湥楴楦牥栠癡湩⁧畭瑬灩敬爠晥牥湥散⁳潴挠湯整瑮椠整獭爠汥瑡摥琠⁯桴⁥慴杲瑥挠湯整瑮愠獳瑥㰻牢ਾ敭湡⁳潴漠瑢楡⁮湡唠啐䥎洠湥⁵灳捥晩捩瑡潩㭮戼㹲洊慥獮琠⁯扯慴湩唠啐䥎爠捥牯⁤湩潦浲瑡潩⁮牦浯愠⁮偕乕⁉楤敲瑣牯㭹戼㹲洊慥獮琠⁯敧敮慲整愠⁮偕乕⁉敭畮映潲⁭桴⁥偕乕⁉敭畮猠数楣楦慣楴湯‬桷牥楥⁮桴⁥偕乕⁉敭畮猠数楣楦慣楴湯椠⁳獵摥琠⁯灳捥晩⁹慶畬獥映潲⁭偕乕⁉敲潣摲椠普牯慭楴湯眠瑩⁨桷捩⁨潴瀠灯汵瑡⁥桴⁥偕乕⁉敭畮㰮牢ਾ㘲⸶†䄠猠獹整⁭景猠数楣楦慣楴湯朠湥牥瑡潩Ɱ挠浯牰獩湩㩧戼㹲洊慥獮琠⁯扯慴湩甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⠠偕乕⥉爠捥牯⁤湩潦浲瑡潩⁮牦浯愠⁮偕乕⁉楤敲瑣牯ⱹ戼㹲 †††桷牥楥⁮桴⁥偕乕⁉摩湥楴楦獥愠琠牡敧⁴潣瑮湥⁴獡敳ⱴ愠摮㰠牢ਾ†††眠敨敲湩琠敨唠啐䥎椠⁳⁡畭瑬⵩摩湥楴楦牥栠癡湩⁧畭瑬灩敬爠晥牥湥散⁳潴挠湯整瑮椠整獭爠汥瑡摥琠⁯桴⁥慴杲瑥挠湯整瑮愠獳瑥㰻牢ਾ敭湡⁳潴朠湥牥瑡⁥⁡敭畮猠数楣楦慣楴湯戠獡摥漠⁮⁡楨牥牡档捩污猠牴捵畴敲漠⁦湡唠啐䥎爠捥牯⹤戼㹲㈊㜶‮†⁁祳瑳浥漠⁦敲敦敲据ⱥ挠浯牰獩湩㩧戼㹲洊慥獮琠⁯扯慴湩洠瑥摡瑡⁡楦汥獤愠摮瘠污敵㭳戼㹲洊慥獮琠⁯扯慴湩愠⁮偕乕⁉敭畮猠数楣楦慣楴湯‬晩椠⁴硥獩獴㰻牢ਾ敭湡⁳潴朠湥牥瑡⁥湡唠啐䥎洠湥⁵灳捥晩捩瑡潩⁮牦浯琠敨洠瑥摡瑡⁡楦汥獤愠摮瘠污敵ⱳ椠⁦湯⁥獩甠慮慶汩扡敬㰻牢ਾ敭湡⁳潴洠瑡档洠瑥摡瑡⁡楦汥獤琠⁯楦汥獤椠⁮桴⁥敭畮猠数楣楦慣楴湯㰻牢ਾ敭湡⁳潴猠慥捲⁨桴⁥敭慴慤慴戠獡摥漠⁮桴⁥慭捴敨⁤楦汥獤映牯映敩摬瘠污敵㭳戼㹲洊慥獮琠⁯潣獮牴捵⁴桴⁥慴杲瑥爠晥牥湥散⁳慢敳⁤湯琠敨洠瑡档摥映敩摬⁳湡⁤楦汥⁤慶畬獥㰻牢ਾ敭湡⁳潴猠潴敲琠敨琠牡敧⁴敲敦敲据獥椠⁮⁡偕乕⁉敲潣摲椠⁮⁡偕乕⁉楤敲瑣牯⹹戼㹲㈊㠶‮†⁁祳瑳浥漠⁦敲敦敲据ⱥ挠浯牰獩湩㩧戼㹲洊慥獮琠⁯獥慴汢獩⁨敲慬楴湯桳灩⁳敢睴敥⁮湵煩敵瀠牥楳瑳湥⁴湵癩牥慳⁬慮敭椠敤瑮晩敩⁲唨啐䥎 湡⁤湡唠啐䥎洠湥Ⱶ戼㹲 †††桷牥楥⁮桴⁥偕乕⁉摩湥楴楦獥愠琠牡敧⁴潣瑮湥⁴獡敳ⱴ愠摮㰠牢ਾ†††眠敨敲湩琠敨唠啐䥎椠⁳⁡畭瑬⵩摩湥楴楦牥栠癡湩⁧畭瑬灩敬琠牡敧⁴敲敦敲据獥琠⁯潣瑮湥⁴瑩浥⁳敲慬整⁤潴琠敨琠牡敧⁴潣瑮湥⁴獡敳㭴戼㹲洊慥獮琠⁯潣獮牴捵⁴桴⁥慴杲瑥爠晥牥湥散ⱳ眠敨敲湩琠敨琠牡敧⁴敲敦敲据獥愠敲琠⁯敢猠潴敲⁤湩愠唠啐䥎爠捥牯⁤湩愠唠啐䥎搠物捥潴祲㰻牢ਾ敭湡⁳潴挠敲瑡⁥湡唠啐䥎洠湥⁵楷桴氠湩獫琠⁯桴⁥慴杲瑥挠湯整瑮愠獳瑥愠摮琠敨琠牡敧⁴敲敦敲据獥㰮牢ਾ㘲⸹†䄠猠獹整⁭景爠晥牥湥散攠楤楴杮‬潣灭楲楳杮㰺牢ਾ敭湡⁳潴洠慥獮琠⁯扯慴湩甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⠠偕乕⥉爠捥牯⁤湩潦浲瑡潩⁮牦浯愠⁮偕乕⁉楤敲瑣牯ⱹ戼㹲 †††桷牥楥⁮桴⁥偕乕⁉摩湥楴楦獥愠琠牡敧⁴潣瑮湥⁴獡敳ⱴ愠摮戼㹲 †††桷牥楥⁮桴⁥偕乕⁉獩愠洠汵楴椭敤瑮晩敩⁲慨楶杮洠汵楴汰⁥敲敦敲据獥琠⁯潣瑮湥⁴瑩浥⁳敲慬整⁤潴琠敨琠牡敧⁴潣瑮湥⁴獡敳㭴戼㹲洊慥獮琠⁯楤灳慬⁹桴⁥偕乕⁉敲潣摲椠普牯慭楴湯㰻牢ਾ敭湡⁳潴愠摤映敩摬⁳湡⁤慶畬獥琠⁯桴⁥偕乕⁉敲潣摲‬晩椠獮牴捵整㭤戼㹲洊慥獮琠⁯敤敬整映敩摬⁳湡⁤慶畬獥琠⁯桴⁥偕乕⁉敲潣摲‬晩椠獮牴捵整㭤戼㹲洊慥獮琠⁯污整⁲楦汥獤愠摮瘠污敵⁳潴琠敨唠啐䥎爠捥牯Ɽ椠⁦湩瑳畲瑣摥㰻牢ਾ敭湡⁳潴猠潴敲甠摰瑡⁥偕乕⁉敲潣摲椠普牯慭楴湯椠⁮湡唠啐䥎搠物捥潴祲㰮牢ਾ㜲⸰†䄠猠獹整⁭景爠晥牥湥散搠獩牴扩瑵潩Ɱ挠浯牰獩湩㩧戼㹲洊慥獮琠⁯敲散癩⁥⁡敲畱獥⁴潦⁲⁡敭畮猠数楣楦慣楴湯映牯愠甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⠠偕乕⥉㰬牢ਾ†††眠敨敲湩琠敨唠啐䥎椠敤瑮晩敩⁳⁡慴杲瑥挠湯整瑮愠獳瑥‬湡㱤牢ਾ†††眠敨敲湩琠敨唠啐䥎椠⁳⁡畭瑬⵩摩湥楴楦牥栠癡湩⁧畭瑬灩敬爠晥牥湥散⁳潴挠湯整瑮椠整獭爠汥瑡摥琠⁯桴⁥慴杲瑥挠湯整瑮愠獳瑥㰻牢ਾ敭湡⁳潴猠慥捲⁨⁡慤慴慢敳映牯琠敨洠湥⁵灳捥晩捩瑡潩㭮戼㹲洊慥獮琠⁯敧敮慲整愠洠湥⁵灳捥晩捩瑡潩⁮潦⁲桴⁥偕乕⁉牦浯洠瑥摡瑡⁡湩愠⁮偕乕⁉楤敲瑣牯ⱹ椠⁦潮敮愠敲映畯摮椠⁮桴⁥慤慴慢敳㰻牢ਾ敭湡⁳潴猠潴敲琠敨洠湥⁵灳捥晩捩瑡潩⁮湩琠敨搠瑡扡獡ⱥ椠⁦湯⁥慷⁳敧敮慲整㭤戼㹲洊慥獮琠⁯敧敮慲整愠⁮偕乕⁉敭畮映潲⁭桴⁥偕乕⁉敭畮猠数楣楦慣楴湯‬桷牥楥⁮桴⁥偕乕⁉敭畮猠数楣楦慣楴湯椠⁳獵摥琠⁯灳捥晩⁹慶畬獥映潲⁭偕乕⁉敲潣摲椠普牯慭楴湯眠瑩⁨桷捩⁨潴瀠灯汵瑡⁥桴⁥偕乕⁉敭畮㰻牢ਾ敭湡⁳潴瀠潲楶敤琠敨唠啐䥎洠湥⁵潴愠爠煥敵瑳湩⁧汣敩瑮琠慨⁴獩爠獥潰獮癩⁥潴琠敨爠煥敵瑳‮戼㹲㈊ㄷ‮†⁁祳瑳浥漠⁦湩整汲湩⁫敤整浲湩瑡潩Ɱ挠浯牰獩湩㩧戼㹲洊慥獮琠⁯扯慴湩琠牡敧⁴湵煩敵瀠牥楳瑳湥⁴湵癩牥慳⁬慮敭椠敤瑮晩敩獲⠠偕乕獉 潦⁲慢楳⁳景挠浯慰楲潳Ɱ眠敨敲湩琠敨唠啐䥎椠敤瑮晩敩⁳⁡慴杲瑥挠湯整瑮愠獳瑥㰻牢ਾ敭湡⁳潴挠浯慰敲琠牡敧⁴偕乕獉琠⁯偕乕獉映畯摮眠楨敬椠摮硥挠慲汷湩⁧敗⁢楳整㭳戼㹲洊慥獮琠⁯敤整浲湩⁥⁡敤牧敥漠⁦湩整汲湩楫杮映牯琠牡敧⁴偕乕獉戠⁹潮楴杮愠渠浵敢⁲景洠瑡档獥愠摮渠湯洭瑡档獥愠⁳敢睴敥⁮桴⁥慴杲瑥唠啐䥎⁳湡⁤潴映畯摮唠啐䥎⹳㰠牢ਾ㜲⸲†䄠洠摥畩⁭敲摡扡敬戠⁹⁡牰捯獥潳⁲潦⁲敭畮朠湥牥瑡潩Ɱ挠浯牰獩湩㩧戼㹲椊獮牴捵楴湯猠杩慮獬椠⁮桴⁥牰捯獥潳⁲敲摡扡敬洠摥畩Ɑ眠敨敲湩琠敨椠獮牴捵楴湯猠杩慮獬愠敲椠獳慵汢⁥祢琠敨瀠潲散獳牯琠㩯戼㹲爊捥楥敶愠爠煥敵瑳映牯愠甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⠠偕乕⥉映潲⁭⁡敲畱獥楴杮挠楬湥⁴捡散獳湩⁧潣瑮湥ⱴ戼㹲 †††桷牥楥⁮桴⁥敲畱獥⁴獩琠楲杧牥摥映潲⁭桴⁥捡散獳湩⁧景挠湯整瑮‬戼㹲 †††桷牥楥⁮桴⁥偕乕⁉摩湥楴楦獥愠琠牡敧⁴潣瑮湥⁴獡敳ⱴ愠摮㰠牢ਾ†††眠敨敲湩琠敨唠啐䥎椠⁳⁡畭瑬⵩摩湥楴楦牥栠癡湩⁧畭瑬灩敬爠晥牥湥散⁳潴挠湯整瑮椠整獭爠汥瑡摥琠⁯桴⁥慴杲瑥挠湯整瑮愠獳瑥㰻牢ਾ扯慴湩愠⁮偕乕⁉敭畮猠数楣楦慣楴湯㰻牢ਾ扯慴湩唠啐䥎爠捥牯⁤湩潦浲瑡潩⁮牦浯愠⁮偕乕⁉楤敲瑣牯㭹戼㹲朊湥牥瑡⁥湡唠啐䥎洠湥⁵牦浯琠敨唠啐䥎洠湥⁵灳捥晩捩瑡潩Ɱ眠敨敲湩琠敨唠啐䥎洠湥⁵灳捥晩捩瑡潩⁮獩甠敳⁤潴猠数楣祦瘠污敵⁳牦浯唠啐䥎爠捥牯⁤湩潦浲瑡潩⁮楷桴眠楨档琠⁯潰異慬整琠敨唠啐䥎洠湥⹵戼㹲㈊㌷‮†⁁敭楤浵爠慥慤汢⁥祢愠瀠潲散獳牯映牯猠数楣楦慣楴湯朠湥牥瑡潩Ɱ挠浯牰獩湩㩧戼㹲椊獮牴捵楴湯猠杩慮獬椠⁮桴⁥牰捯獥潳⁲敲摡扡敬洠摥畩Ɑ眠敨敲湩琠敨椠獮牴捵楴湯猠杩慮獬愠敲椠獳慵汢⁥祢琠敨瀠潲散獳牯琠㩯戼㹲漊瑢楡⁮湵煩敵瀠牥楳瑳湥⁴湵癩牥慳⁬慮敭椠敤瑮晩敩⁲唨啐䥎 敲潣摲椠普牯慭楴湯映潲⁭湡唠啐䥎搠物捥潴祲㰬牢ਾ†††眠敨敲湩琠敨唠啐䥎椠敤瑮晩敩⁳⁡慴杲瑥挠湯整瑮愠獳瑥‬湡⁤戼㹲 †††桷牥楥⁮桴⁥偕乕⁉獩愠洠汵楴椭敤瑮晩敩⁲慨楶杮洠汵楴汰⁥敲敦敲据獥琠⁯潣瑮湥⁴瑩浥⁳敲慬整⁤潴琠敨琠牡敧⁴潣瑮湥⁴獡敳㭴戼㹲朊湥牥瑡⁥⁡敭畮猠数楣楦慣楴湯戠獡摥漠⁮⁡楨牥牡档捩污猠牴捵畴敲漠⁦湡唠啐䥎爠捥牯⹤戼㹲㈊㐷‮†⁁敭楤浵爠慥慤汢⁥祢愠瀠潲散獳牯映牯爠晥牥湥散‬潣灭楲楳杮㰺牢ਾ湩瑳畲瑣潩⁮楳湧污⁳湩琠敨瀠潲散獳牯爠慥慤汢⁥敭楤浵‬桷牥楥⁮桴⁥湩瑳畲瑣潩⁮楳湧污⁳牡⁥獩畳扡敬戠⁹桴⁥牰捯獥潳⁲潴㰺牢ਾ扯慴湩洠瑥摡瑡⁡楦汥獤愠摮瘠污敵㭳戼㹲漊瑢楡⁮湡唠啐䥎洠湥⁵灳捥晩捩瑡潩Ɱ椠⁦瑩攠楸瑳㭳戼㹲朊湥牥瑡⁥湡唠啐䥎洠湥⁵灳捥晩捩瑡潩⁮牦浯琠敨洠瑥摡瑡⁡楦汥獤愠摮瘠污敵ⱳ椠⁦湯⁥獩甠慮慶汩扡敬㰻牢ਾ慭捴⁨敭慴慤慴映敩摬⁳潴映敩摬⁳湩琠敨洠湥⁵灳捥晩捩瑡潩㭮戼㹲猊慥捲⁨桴⁥敭慴慤慴戠獡摥漠⁮桴⁥慭捴敨⁤楦汥獤映牯映敩摬瘠污敵㭳戼㹲挊湯瑳畲瑣琠敨琠牡敧⁴敲敦敲据獥戠獡摥漠⁮桴⁥慭捴敨⁤楦汥獤愠摮映敩摬瘠污敵㭳戼㹲猊潴敲琠敨琠牡敧⁴敲敦敲据獥椠⁮⁡偕乕⁉敲潣摲椠⁮⁡偕乕⁉楤敲瑣牯⹹戼㹲㈊㔷‮†⁁敭楤浵爠慥慤汢⁥祢愠瀠潲散獳牯映牯爠晥牥湥散‬潣灭楲楳杮㰺牢ਾ湩瑳畲瑣潩⁮楳湧污⁳湩琠敨瀠潲散獳牯爠慥慤汢⁥敭楤浵‬桷牥楥⁮桴⁥湩瑳畲瑣潩⁮楳湧污⁳牡⁥獩畳扡敬戠⁹桴⁥牰捯獥潳⁲潴㰺牢ਾ獥慴汢獩⁨敲慬楴湯桳灩⁳敢睴敥⁮湵煩敵瀠牥楳瑳湥⁴湵癩牥慳⁬慮敭椠敤瑮晩敩⁲唨啐䥎 湡⁤湡唠啐䥎洠湥Ⱶ戼㹲 †††桷牥楥⁮桴⁥偕乕⁉摩湥楴楦獥愠琠牡敧⁴潣瑮湥⁴獡敳ⱴ愠摮㰠牢ਾ†††眠敨敲湩琠敨唠啐䥎椠⁳⁡畭瑬⵩摩湥楴楦牥栠癡湩⁧畭瑬灩敬琠牡敧⁴敲敦敲据獥琠⁯潣瑮湥⁴瑩浥⁳敲慬整⁤潴琠敨琠牡敧⁴潣瑮湥⁴獡敳㭴戼㹲挊湯瑳畲瑣琠敨琠牡敧⁴敲敦敲据獥‬桷牥楥⁮桴⁥慴杲瑥爠晥牥湥散⁳牡⁥潴戠⁥瑳牯摥椠⁮⁡偕乕⁉敲潣摲椠⁮⁡偕乕⁉楤敲瑣牯㭹戼㹲挊敲瑡⁥湡唠啐䥎洠湥⁵楷桴氠湩獫琠⁯桴⁥慴杲瑥挠湯整瑮愠獳瑥愠摮琠敨琠牡敧⁴敲敦敲据獥㰮牢ਾ㜲⸶†䄠洠摥畩⁭敲摡扡敬戠⁹⁡牰捯獥潳⁲潦⁲敲敦敲据⁥摥瑩湩Ⱨ挠浯牰獩湩㩧戼㹲椊獮牴捵楴湯猠杩慮獬椠⁮桴⁥牰捯獥潳⁲敲摡扡敬洠摥畩Ɑ眠敨敲湩琠敨椠獮牴捵楴湯猠杩慮獬愠敲椠獳慵汢⁥祢琠敨瀠潲散獳牯琠㩯戼㹲漊瑢楡⁮湵煩敵瀠牥楳瑳湥⁴湵癩牥慳⁬慮敭椠敤瑮晩敩⁲唨啐䥎 敲潣摲椠普牯慭楴湯映潲⁭湡唠啐䥎搠物捥潴祲㰬牢ਾ†††眠敨敲湩琠敨唠啐䥎椠敤瑮晩敩⁳⁡慴杲瑥挠湯整瑮愠獳瑥‬湡㱤牢ਾ†††眠敨敲湩琠敨唠啐䥎椠⁳⁡畭瑬⵩摩湥楴楦牥栠癡湩⁧畭瑬灩敬爠晥牥湥散⁳潴挠湯整瑮椠整獭爠汥瑡摥琠⁯桴⁥慴杲瑥挠湯整瑮愠獳瑥㰻牢ਾ楤灳慬⁹桴⁥偕乕⁉敲潣摲椠普牯慭楴湯㰻牢ਾ摡⁤楦汥獤愠摮瘠污敵⁳潴琠敨唠啐䥎爠捥牯Ɽ椠⁦湩瑳畲瑣摥㰻牢ਾ敤敬整映敩摬⁳湡⁤慶畬獥琠⁯桴⁥偕乕⁉敲潣摲‬晩椠獮牴捵整㭤戼㹲愊瑬牥映敩摬⁳湡⁤慶畬獥琠⁯桴⁥偕乕⁉敲潣摲‬晩椠獮牴捵整㭤戼㹲猊潴敲甠摰瑡⁥偕乕⁉敲潣摲椠普牯慭楴湯椠⁮湡唠啐䥎搠物捥潴祲㰮牢ਾ㜲⸷†䄠洠摥畩⁭敲摡扡敬戠⁹⁡牰捯獥潳⁲潦⁲敲敦敲据⁥楤瑳楲畢楴湯‬潣灭楲楳杮㰺牢ਾ湩瑳畲瑣潩⁮楳湧污⁳湩琠敨瀠潲散獳牯爠慥慤汢⁥敭楤浵‬桷牥楥⁮桴⁥湩瑳畲瑣潩⁮楳湧污⁳牡⁥獩畳扡敬戠⁹桴⁥牰捯獥潳⁲潴㰺牢ਾ敲散癩⁥⁡敲畱獥⁴潦⁲⁡敭畮猠数楣楦慣楴湯映牯愠甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⠠偕乕⥉㰬牢ਾ†††眠敨敲湩琠敨唠啐䥎椠敤瑮晩敩⁳⁡慴杲瑥挠湯整瑮愠獳瑥‬湡㱤牢ਾ†††眠敨敲湩琠敨唠啐䥎椠⁳⁡畭瑬⵩摩湥楴楦牥栠癡湩⁧畭瑬灩敬爠晥牥湥散⁳潴挠湯整瑮椠整獭爠汥瑡摥琠⁯桴⁥慴杲瑥挠湯整瑮愠獳瑥㰻牢ਾ敳牡档愠搠瑡扡獡⁥潦⁲桴⁥敭畮猠数楣楦慣楴湯㰻牢ਾ敧敮慲整愠洠湥⁵灳捥晩捩瑡潩⁮潦⁲桴⁥偕乕⁉牦浯洠瑥摡瑡⁡湩愠⁮偕乕⁉楤敲瑣牯ⱹ椠⁦潮敮愠敲映畯摮椠⁮桴⁥慤慴慢敳㰻牢ਾ瑳牯⁥桴⁥敭畮猠数楣楦慣楴湯椠⁮桴⁥慤慴慢敳‬晩漠敮眠獡朠湥牥瑡摥㰻牢ਾ敧敮慲整愠⁮偕乕⁉敭畮映潲⁭桴⁥偕乕⁉敭畮猠数楣楦慣楴湯‬桷牥楥⁮桴⁥偕乕⁉敭畮猠数楣楦慣楴湯椠⁳獵摥琠⁯灳捥晩⁹慶畬獥映潲⁭偕乕⁉敲潣摲椠普牯慭楴湯眠瑩⁨桷捩⁨潴瀠灯汵瑡⁥桴⁥偕乕⁉敭畮㰻牢ਾ牰癯摩⁥桴⁥偕乕⁉敭畮琠⁯⁡敲畱獥楴杮挠楬湥⁴桴瑡椠⁳敲灳湯楳敶琠⁯桴⁥敲畱獥⹴㰠牢ਾ㜲⸸†䄠洠摥畩⁭敲摡扡敬戠⁹⁡牰捯獥潳⁲潦⁲湩整汲湩⁫敤整浲湩瑡潩Ɱ挠浯牰獩湩㩧戼㹲椊獮牴捵楴湯猠杩慮獬椠⁮桴⁥牰捯獥潳⁲敲摡扡敬洠摥畩Ɑ眠敨敲湩琠敨椠獮牴捵楴湯猠杩慮獬愠敲椠獳慵汢⁥祢琠敨瀠潲散獳牯琠㩯戼㹲漊瑢楡⁮慴杲瑥甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⁳唨啐䥎⥳映牯戠獡獩漠⁦潣灭牡獩湯‬桷牥楥⁮桴⁥偕乕⁉摩湥楴楦獥愠琠牡敧⁴潣瑮湥⁴獡敳㭴戼㹲挊浯慰敲琠牡敧⁴偕乕獉琠⁯偕乕獉映畯摮眠楨敬椠摮硥挠慲汷湩⁧敗⁢楳整㭳戼㹲搊瑥牥業敮愠搠来敲⁥景椠瑮牥楬歮湩⁧潦⁲慴杲瑥唠啐䥎⁳祢渠瑯湩⁧⁡畮扭牥漠⁦慭捴敨⁳湡⁤潮⵮慭捴敨⁳獡戠瑥敷湥琠敨琠牡敧⁴偕乕獉愠摮琠⁯潦湵⁤偕乕獉‮戼㹲㈊㤷‮†湁愠灰牡瑡獵琠⁯敧敮慲整洠湥Ⱶ挠浯牰獩湩㩧戼㹲愊洠浥牯㭹戼㹲愊瀠潲散獳牯搠獩潰敳⁤湩挠浯畭楮慣楴湯眠瑩⁨慳摩洠浥牯ⱹ愠摮挠湯楦畧敲⁤潴椠獳敵愠瀠畬慲楬祴漠⁦牰捯獥楳杮椠獮牴捵楴湯⁳瑳牯摥椠⁮桴⁥敭潭祲‬桷牥楥⁮桴⁥湩瑳畲瑣潩獮椠獳敵猠杩慮獬琠㩯戼㹲爊捥楥敶愠爠煥敵瑳映牯愠甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⠠偕乕⥉映潲⁭⁡敲畱獥楴杮挠楬湥⁴捡散獳湩⁧潣瑮湥ⱴ戼㹲 †††桷牥楥⁮桴⁥敲畱獥⁴獩琠楲杧牥摥映潲⁭桴⁥捡散獳湩⁧景挠湯整瑮‬戼㹲 †††桷牥楥⁮桴⁥偕乕⁉摩湥楴楦獥愠琠牡敧⁴潣瑮湥⁴獡敳ⱴ愠摮㰠牢ਾ†††眠敨敲湩琠敨唠啐䥎椠⁳⁡畭瑬⵩摩湥楴楦牥栠癡湩⁧畭瑬灩敬爠晥牥湥散⁳潴挠湯整瑮椠整獭爠汥瑡摥琠⁯桴⁥慴杲瑥挠湯整瑮愠獳瑥㰻牢ਾ扯慴湩愠⁮偕乕⁉敭畮猠数楣楦慣楴湯㰻牢ਾ扯慴湩唠啐䥎爠捥牯⁤湩潦浲瑡潩⁮牦浯愠⁮偕乕⁉楤敲瑣牯㭹戼㹲朊湥牥瑡⁥湡唠啐䥎洠湥⁵牦浯琠敨唠啐䥎洠湥⁵灳捥晩捩瑡潩Ɱ眠敨敲湩琠敨唠啐䥎洠湥⁵灳捥晩捩瑡潩⁮獩甠敳⁤潴猠数楣祦瘠污敵⁳牦浯唠啐䥎爠捥牯⁤湩潦浲瑡潩⁮楷桴眠楨档琠⁯潰異慬整琠敨唠啐䥎洠湥⹵戼㹲㈊〸‮†湁愠灰牡瑡獵琠⁯敧敮慲整猠数楣楦慣楴湯‬潣灭楲楳杮㰺牢ਾ⁡敭潭祲㰻牢ਾ⁡牰捯獥潳⁲楤灳獯摥椠⁮潣浭湵捩瑡潩⁮楷桴猠楡⁤敭潭祲‬湡⁤潣普杩牵摥琠⁯獩畳⁥⁡汰牵污瑩⁹景瀠潲散獳湩⁧湩瑳畲瑣潩獮猠潴敲⁤湩琠敨洠浥牯ⱹ眠敨敲湩琠敨椠獮牴捵楴湯⁳獩畳⁥楳湧污⁳潴㰺牢ਾ扯慴湩甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⠠偕乕⥉爠捥牯⁤湩潦浲瑡潩⁮牦浯愠⁮偕乕⁉楤敲瑣牯ⱹ戼㹲 †††桷牥楥⁮桴⁥偕乕⁉摩湥楴楦獥愠琠牡敧⁴潣瑮湥⁴獡敳ⱴ愠摮㰠牢ਾ†††眠敨敲湩琠敨唠啐䥎椠⁳⁡畭瑬⵩摩湥楴楦牥栠癡湩⁧畭瑬灩敬爠晥牥湥散⁳潴挠湯整瑮椠整獭爠汥瑡摥琠⁯桴⁥慴杲瑥挠湯整瑮愠獳瑥㰻牢ਾ敧敮慲整愠洠湥⁵灳捥晩捩瑡潩⁮慢敳⁤湯愠栠敩慲捲楨慣⁬瑳畲瑣牵⁥景愠⁮偕乕⁉敲潣摲㰮牢ਾ㠲⸱†䄠⁮灡慰慲畴⁳潴爠晥牥湥散‬潣灭楲楳杮㰺牢ਾ⁡敭潭祲㰻牢ਾ⁡牰捯獥潳⁲楤灳獯摥椠⁮潣浭湵捩瑡潩⁮楷桴猠楡⁤敭潭祲‬湡⁤潣普杩牵摥琠⁯獩畳⁥⁡汰牵污瑩⁹景瀠潲散獳湩⁧湩瑳畲瑣潩獮猠潴敲⁤湩琠敨洠浥牯ⱹ眠敨敲湩琠敨椠獮牴捵楴湯⁳獩畳⁥楳湧污⁳潴㰺牢ਾ扯慴湩洠瑥摡瑡⁡楦汥獤愠摮瘠污敵㭳戼㹲漊瑢楡⁮湡唠啐䥎洠湥⁵灳捥晩捩瑡潩Ɱ椠⁦瑩攠楸瑳㭳戼㹲朊湥牥瑡⁥湡唠啐䥎洠湥⁵灳捥晩捩瑡潩⁮牦浯琠敨洠瑥摡瑡⁡楦汥獤愠摮瘠污敵ⱳ椠⁦湯⁥獩甠慮慶汩扡敬㰻牢ਾ慭捴⁨敭慴慤慴映敩摬⁳潴映敩摬⁳湩琠敨洠湥⁵灳捥晩捩瑡潩㭮戼㹲猊慥捲⁨桴⁥敭慴慤慴戠獡摥漠⁮桴⁥慭捴敨⁤楦汥獤映牯映敩摬瘠污敵㭳戼㹲挊湯瑳畲瑣琠敨琠牡敧⁴敲敦敲据獥戠獡摥漠⁮桴⁥慭捴敨⁤楦汥獤愠摮映敩摬瘠污敵㭳戼㹲猊潴敲琠敨琠牡敧⁴敲敦敲据獥椠⁮⁡偕乕⁉敲潣摲椠⁮⁡偕乕⁉楤敲瑣牯⹹戼㹲㈊㈸‮†湁愠灰牡瑡獵琠⁯敲敦敲据ⱥ挠浯牰獩湩㩧戼㹲愊洠浥牯㭹戼㹲愊瀠潲散獳牯搠獩潰敳⁤湩挠浯畭楮慣楴湯眠瑩⁨慳摩洠浥牯ⱹ愠摮挠湯楦畧敲⁤潴椠獳敵愠瀠畬慲楬祴漠⁦牰捯獥楳杮椠獮牴捵楴湯⁳瑳牯摥椠⁮桴⁥敭潭祲‬桷牥楥⁮桴⁥湩瑳畲瑣潩獮椠獳敵猠杩慮獬琠㩯戼㹲攊瑳扡楬桳爠汥瑡潩獮楨獰戠瑥敷湥甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⠠偕乕⥉愠摮愠⁮偕乕⁉敭畮㰬牢ਾ†††眠敨敲湩琠敨唠啐䥎椠敤瑮晩敩⁳⁡慴杲瑥挠湯整瑮愠獳瑥‬湡⁤戼㹲 †††桷牥楥⁮桴⁥偕乕⁉獩愠洠汵楴椭敤瑮晩敩⁲慨楶杮洠汵楴汰⁥慴杲瑥爠晥牥湥散⁳潴挠湯整瑮椠整獭爠汥瑡摥琠⁯桴⁥慴杲瑥挠湯整瑮愠獳瑥㰻牢ਾ潣獮牴捵⁴桴⁥慴杲瑥爠晥牥湥散ⱳ眠敨敲湩琠敨琠牡敧⁴敲敦敲据獥愠敲琠⁯敢猠潴敲⁤湩愠唠啐䥎爠捥牯⁤湩愠唠啐䥎搠物捥潴祲㰻牢ਾ牣慥整愠⁮偕乕⁉敭畮眠瑩⁨楬歮⁳潴琠敨琠牡敧⁴潣瑮湥⁴獡敳⁴湡⁤桴⁥慴杲瑥爠晥牥湥散⹳戼㹲㈊㌸‮†湁愠灰牡瑡獵琠⁯摥瑩爠晥牥湥散‬潣灭楲楳杮㰺牢ਾ⁡敭潭祲㰻牢ਾ⁡牰捯獥潳⁲楤灳獯摥椠⁮潣浭湵捩瑡潩⁮楷桴猠楡⁤敭潭祲‬湡⁤潣普杩牵摥琠⁯獩畳⁥⁡汰牵污瑩⁹景瀠潲散獳湩⁧湩瑳畲瑣潩獮猠潴敲⁤湩琠敨洠浥牯ⱹ眠敨敲湩琠敨椠獮牴捵楴湯⁳獩畳⁥楳湧污⁳潴㰺牢ਾ扯慴湩甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⠠偕乕⥉爠捥牯⁤湩潦浲瑡潩⁮牦浯愠⁮偕乕⁉楤敲瑣牯ⱹ戼㹲 †††桷牥楥⁮桴⁥偕乕⁉摩湥楴楦獥愠琠牡敧⁴潣瑮湥⁴獡敳ⱴ愠摮戼㹲 †††桷牥楥⁮桴⁥偕乕⁉獩愠洠汵楴椭敤瑮晩敩⁲慨楶杮洠汵楴汰⁥敲敦敲据獥琠⁯潣瑮湥⁴瑩浥⁳敲慬整⁤潴琠敨琠牡敧⁴潣瑮湥⁴獡敳㭴戼㹲搊獩汰祡琠敨唠啐䥎爠捥牯⁤湩潦浲瑡潩㭮戼㹲愊摤映敩摬⁳湡⁤慶畬獥琠⁯桴⁥偕乕⁉敲潣摲‬晩椠獮牴捵整㭤戼㹲搊汥瑥⁥楦汥獤愠摮瘠污敵⁳潴琠敨唠啐䥎爠捥牯Ɽ椠⁦湩瑳畲瑣摥㰻牢ਾ污整⁲楦汥獤愠摮瘠污敵⁳潴琠敨唠啐䥎爠捥牯Ɽ椠⁦湩瑳畲瑣摥㰻牢ਾ瑳牯⁥灵慤整唠啐䥎爠捥牯⁤湩潦浲瑡潩⁮湩愠⁮偕乕⁉楤敲瑣牯⹹戼㹲㈊㐸‮†湁愠灰牡瑡獵琠⁯楤瑳楲畢整爠晥牥湥散‬潣灭楲楳杮㰺牢ਾ⁡敭潭祲㰻牢ਾ⁡牰捯獥潳⁲楤灳獯摥椠⁮潣浭湵捩瑡潩⁮楷桴猠楡⁤敭潭祲‬湡⁤潣普杩牵摥琠⁯獩畳⁥⁡汰牵污瑩⁹景瀠潲散獳湩⁧湩瑳畲瑣潩獮猠潴敲⁤湩琠敨洠浥牯ⱹ眠敨敲湩琠敨椠獮牴捵楴湯⁳獩畳⁥楳湧污⁳潴㰺牢ਾ敲散癩⁥⁡敲畱獥⁴潦⁲⁡敭畮猠数楣楦慣楴湯映牯愠甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⠠偕乕⥉㰬牢ਾ†††眠敨敲湩琠敨唠啐䥎椠敤瑮晩敩⁳⁡慴杲瑥挠湯整瑮愠獳瑥‬湡㱤牢ਾ†††眠敨敲湩琠敨唠啐䥎椠⁳⁡畭瑬⵩摩湥楴楦牥栠癡湩⁧畭瑬灩敬爠晥牥湥散⁳潴挠湯整瑮椠整獭爠汥瑡摥琠⁯桴⁥慴杲瑥挠湯整瑮愠獳瑥㰻牢ਾ敳牡档愠搠瑡扡獡⁥潦⁲桴⁥敭畮猠数楣楦慣楴湯㰻牢ਾ敧敮慲整愠洠湥⁵灳捥晩捩瑡潩⁮潦⁲桴⁥偕乕⁉牦浯洠瑥摡瑡⁡湩愠⁮偕乕⁉楤敲瑣牯ⱹ椠⁦潮敮愠敲映畯摮椠⁮桴⁥慤慴慢敳㰻牢ਾ瑳牯⁥桴⁥敭畮猠数楣楦慣楴湯椠⁮桴⁥慤慴慢敳‬晩漠敮眠獡朠湥牥瑡摥㰻牢ਾ敧敮慲整愠⁮偕乕⁉敭畮映潲⁭桴⁥偕乕⁉敭畮猠数楣楦慣楴湯‬桷牥楥⁮桴⁥偕乕⁉敭畮猠数楣楦慣楴湯椠⁳獵摥琠⁯灳捥晩⁹慶畬獥映潲⁭偕乕⁉敲潣摲椠普牯慭楴湯眠瑩⁨桷捩⁨潴瀠灯汵瑡⁥桴⁥偕乕⁉敭畮㰻牢ਾ牰癯摩⁥桴⁥偕乕⁉敭畮琠⁯⁡敲畱獥楴杮挠楬湥⁴桴瑡椠⁳敲灳湯楳敶琠⁯桴⁥敲畱獥⹴㰠牢ਾ㠲⸵†䄠⁮灡慰慲畴⁳潴搠瑥牥業敮椠瑮牥楬歮湩Ⱨ挠浯牰獩湩㩧戼㹲愊洠浥牯㭹戼㹲愊瀠潲散獳牯搠獩潰敳⁤湩挠浯畭楮慣楴湯眠瑩⁨慳摩洠浥牯ⱹ愠摮挠湯楦畧敲⁤潴椠獳敵愠瀠畬慲楬祴漠⁦牰捯獥楳杮椠獮牴捵楴湯⁳瑳牯摥椠⁮桴⁥敭潭祲‬桷牥楥⁮桴⁥湩瑳畲瑣潩獮椠獳敵猠杩慮獬琠㩯戼㹲漊瑢楡⁮慴杲瑥甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⁳唨啐䥎⥳映牯戠獡獩漠⁦潣灭牡獩湯‬桷牥楥⁮桴⁥偕乕⁉摩湥楴楦獥愠琠牡敧⁴潣瑮湥⁴獡敳㭴戼㹲挊浯慰敲琠牡敧⁴偕乕獉琠⁯偕乕獉映畯摮眠楨敬椠摮硥挠慲汷湩⁧敗⁢楳整㭳戼㹲搊瑥牥業敮愠搠来敲⁥景椠瑮牥楬歮湩⁧潦⁲慴杲瑥唠啐䥎⁳祢渠瑯湩⁧⁡畮扭牥漠⁦慭捴敨⁳湡⁤潮⵮慭捴敨⁳獡戠瑥敷湥琠敨琠牡敧⁴偕乕獉愠摮琠⁯潦湵⁤偕乕獉‮戼㹲 戼㹲 戼㹲㈊㘸‮†⁁敭桴摯‬潣灭楲楳杮㰺牢ਾ牣慥楴杮愠⁮湩瑩慩⁬楨牥牡档⁹景洠湥⁵瑩浥⁳桷牥⁥⁡慥档洠湥⁵瑩浥栠獡愠爠晥牥湥散琠牡敧⁴摩湥楴楦牥戼㹲 †††桷牥楥⁮敭畮椠整獭洠祡椠据畬敤挠浯潰楳整洠摥慩㰬牢ਾ†††眠敨敲湩洠湥⁵瑩浥⁳慭⁹湩汣摵⁥湩潦浲瑡潩⁮牦浯愠戠捡⵫湥⁤敳癲牥㰬牢ਾ†††眠敨敲湩琠敨洠湥⁵瑩浥⁳牡⁥楬歮⁳潴攠晦捥⁴⁡異捲慨敳‬湡㱤牢ਾ†††眠敨敲湩琠敨栠敩慲捲票漠⁦敭畮椠整獭椠⁳牢畯桧⁴扡畯⁴祢愠⁮摡敶瑲獩浥湥㭴戼㹲搊獩牴扩瑵湩⁧桴⁥湩瑩慩⁬楨牥牡档⁹潦⁲潣獮摩牥瑡潩⁮祢洠湥⁵楶睥牥㭳戼㹲瘊牥晩楹杮琠慨⁴桴⁥湩瑩慩⁬楨牥牡档馀⁳敲敦敲据⁥慴杲瑥椠敤瑮晩敩獲愠摮愠獳捯慩整⁤敭畮椠整⁭湩潦浲瑡潩⁮牡⁥慶楬㭤戼㹲攊晦捥楴杮琠慲正湩⁧景琠敨洠湥⁵楶睥牥馀甠慳敧漠⁦桴⁥湩瑩慩⁬楨牥牡档ⱹ戼㹲 †††桷牥楥⁮牴捡楫杮椠据畬敤⁳⁡畮扭牥漠⁦浩牰獥楳湯⁳慭敤戠⁹敭畮椠整獭㰬牢ਾ†††眠敨敲湩琠慲正湩⁧湩汣摵獥愠渠浵敢⁲景琠浩獥愠洠湥⁵瑩浥椠⁳敳敬瑣摥㰻牢ਾ潭楤祦湩⁧桴⁥敭畮椠整⁭湩琠敨椠楮楴污栠敩慲捲票戠獡摥漠⁮桴⁥牴捡楫杮漠⁦獵条ⱥ戼㹲 †††桷牥楥⁮潭楤楦慣楴湯椠据畬敤⁳牡慲杮湩⁧潭敲瀠灯汵牡洠湥⁵瑩浥⁳潭敲瀠潲業敮瑮祬㰬牢ਾ†††眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥瀠慬楣杮洠湥⁵瑩浥⁳潴椠据敲獡⁥晥楦慣祣‮戼㹲㈊㜸‮†⁁敭桴摯‬潣灭楲楳杮㰺牢ਾ牣慥楴杮愠⁮湩瑩慩⁬楨牥牡档⁹景洠湥⁵瑩浥⁳桷牥⁥⁡慥档洠湥⁵瑩浥栠獡愠爠晥牥湥散琠牡敧⁴摩湥楴楦牥㰻牢ਾ楤瑳楲畢楴杮琠敨椠楮楴污栠敩慲捲票映牯挠湯楳敤慲楴湯戠⁹敭畮瘠敩敷獲㰻牢ਾ扯慴湩湩⁧敭畮瘠敩敷獲胢ₙ獵条⁥湩楤楣⁡景琠敨椠楮楴污栠敩慲捲票㰻牢ਾ潭楤祦湩⁧桴⁥敭畮椠整⁭湩琠敨椠楮楴污栠敩慲捲票戠獡摥漠⁮桴⁥湩楤楣⁡景甠慳敧㰮牢ਾ㠲⸸†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬畦瑲敨Ⱳ挠浯牰獩湩㩧戼㹲瘊牥晩楹杮琠慨⁴桴⁥湩瑩慩⁬楨牥牡档馀⁳敲敦敲据⁥慴杲瑥椠敤瑮晩敩獲愠摮愠獳捯慩整⁤敭畮椠整⁭湩潦浲瑡潩⁮牡⁥慶楬⹤戼㹲㈊㤸‮†桔⁥敭桴摯漠⁦汣楡⁭㠲ⰷ眠敨敲湩洠湥⁵瑩浥⁳慭⁹湩汣摵⁥牧灡楨獣㰮牢ਾ㤲⸰†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬桷牥楥⁮敭畮椠整獭洠祡椠据畬敤瘠摩潥㰮牢ਾ㤲⸱†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬桷牥楥⁮敭畮椠整獭洠祡椠据畬敤映牯獭㰮牢ਾ㤲⸲†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬桷牥楥⁮敭畮椠整獭洠祡椠据畬敤挠浯潰楳整洠摥慩㰮牢ਾ㤲⸳†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬桷牥楥⁮敭畮椠整獭爠汥瑡⁥潴朠癯牥浮湥⁴湩潦浲瑡潩⹮戼㹲㈊㐹‮†桔⁥敭桴摯漠⁦汣楡⁭㠲ⰷ眠敨敲湩洠湥⁵瑩浥⁳敲慬整琠⁯敭楤慣⁬慰楴湥⁴湩潦浲瑡潩⹮戼㹲㈊㔹‮†桔⁥敭桴摯漠⁦汣楡⁭㠲ⰷ眠敨敲湩洠湥⁵瑩浥⁳敲慬整琠⁯潣瑮湥⁴慭慮敧敭瑮椠普牯慭楴湯㰮牢ਾ㤲⸶†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬桷牥楥⁮敭畮椠整獭爠汥瑡⁥潴删䥆⁄湩潦浲瑡潩⹮戼㹲㈊㜹‮†桔⁥敭桴摯漠⁦汣楡⁭㠲ⰷ眠敨敲湩洠湥⁵瑩浥⁳敲慬整琠⁯数獲湯污椠敤瑮瑩⁹湩潦浲瑡潩⹮戼㹲㈊㠹‮†桔⁥敭桴摯漠⁦汣楡⁭㠲ⰷ眠敨敲湩洠湥⁵瑩浥⁳敲慬整琠⁯業楬慴祲椠普牯慭楴湯㰮牢ਾ㤲⸹†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬桷牥楥⁮敭畮椠整獭爠汥瑡⁥潴椠瑮牥慮⁬牰摯捵⁴湩潦浲瑡潩⹮戼㹲㌊〰‮†桔⁥敭桴摯漠⁦汣楡⁭㠲ⰷ眠敨敲湩洠湥⁵瑩浥⁳敲慬整琠⁯硥整湲污椠普牯慭楴湯㰮牢ਾ〳⸱†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬桷牥楥⁮敭畮椠整獭爠汥瑡⁥潴搠捯浵湥⁴慭慮敧敭瑮椠普牯慭楴湯㰮牢ਾ〳⸲†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬桷牥楥⁮敭畮椠整獭洠祡椠据畬敤椠普牯慭楴湯映潲⁭⁡慢正攭摮猠牥敶⹲戼㹲㌊㌰‮†桔⁥敭桴摯漠⁦汣楡⁭〳ⰲ眠敨敲湩琠敨戠捡⵫湥⁤敳癲牥椠⁳⁡湫睯敬杤ⵥ慭慮敧敭瑮猠獹整⹭戼㹲㌊㐰‮†桔⁥敭桴摯漠⁦汣楡⁭〳ⰲ眠敨敲湩琠敨洠湥⁵瑩浥⁳牡⁥楬歮⁳潴攠晦捥⁴⁡異捲慨敳㰮牢ਾ〳⸵†吠敨洠瑥潨⁤景挠慬浩㌠㈰‬桷牥楥⁮桴⁥敭畮椠整獭椠据畬敤氠癩⁥湩敶瑮牯⹹戼㹲㌊㘰‮†桔⁥敭桴摯漠⁦汣楡⁭㠲ⰷ眠敨敲湩琠敨栠敩慲捲票漠⁦敭畮椠整獭椠⁳牢畯桧⁴扡畯⁴祢愠戠湡敮⁲摡敶瑲獩浥湥⹴戼㹲㌊㜰‮†桔⁥敭桴摯漠⁦汣楡⁭㠲ⰷ眠敨敲湩琠敨栠敩慲捲票漠⁦敭畮椠整獭椠⁳牢畯桧⁴扡畯⁴祢愠猠潰獮牯摥愠癤牥楴楳杮氠湩⹫戼㹲㌊㠰‮†桔⁥敭桴摯漠⁦汣楡⁭㠲ⰷ眠敨敲湩琠敨栠敩慲捲票漠⁦敭畮椠整獭椠⁳牢畯桧⁴扡畯⁴祢愠搠捯浵湥⹴戼㹲㌊㤰‮†桔⁥敭桴摯漠⁦汣楡⁭㠲ⰷ眠敨敲湩琠敨栠敩慲捲票漠⁦敭畮椠整獭椠⁳牢畯桧⁴扡畯⁴祢愠洠摥慩瀠慬敹⹲戼㹲㌊〱‮†桔⁥敭桴摯漠⁦汣楡⁭㠲ⰷ眠敨敲湩琠敨椠楮楴污栠敩慲捲票椠⁳潣灭獯摥漠⁦敭畮椠整獭猠汥捥整⁤祢挠湯畳瑬湡獴㰮牢ਾㄳ⸱†吠敨洠瑥潨⁤景挠慬浩㌠〱‬桷牥楥⁮桴⁥潣獮汵慴瑮⁳牡⁥慭歲瑥湩⁧湡污獹獴㰮牢ਾㄳ⸲†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬桷牥楥⁮桴⁥楶睥牥馀甠慳敧椠摮捩慩椠据畬敤⁳獵牥馀瀠牵档獡湩⁧敢慨楶牯㰮牢ਾㄳ⸳†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬桷牥楥⁮桴⁥楶睥牥馀甠慳敧椠摮捩慩椠据畬敤⁳湩敤数摮湥汴⵹敲潣摲摥甠敳⁲牰晥牥湥散椠普牯慭楴湯㰮牢ਾㄳ⸴†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬桷牥楥⁮桴⁥楶睥牥馀甠慳敧椠摮捩慩椠据畬敤⁳湩敤数摮湥汴⵹敲潣摲摥甠敳⁲湩潦浲瑡潩⁮桴瑡椠⁳獡潳楣瑡摥眠瑩⁨⁡慣整潧祲漠⁦獵牥⹳戼㹲㌊㔱‮†桔⁥敭桴摯漠⁦汣楡⁭ㄳⰴ眠敨敲湩琠敨挠瑡来牯⁹景甠敳獲椠据畬敤愠祮漠⁦湡湯浹穩摥洠瑥楲獣瀠潲楦楬杮愠琠灹⁥景甠敳⁲祢椠据浯ⱥ椠瑮牥獥獴‬敤潭牧灡楨獣‬牰晥牥湥散⹳戼㹲㌊㘱‮†桔⁥敭桴摯漠⁦汣楡⁭㠲ⰷ眠敨敲湩琠敨瘠敩敷獲胢ₙ獵条⁥湩楤楣⁡湩汣摵獥洠瑥楲獣爠捥牯敤⁤祢愠猠瑩⁥潨瑳湩⁧桴⁥敭畮㰮牢ਾㄳ⸷†吠敨洠瑥潨⁤景挠慬浩㌠㘱‬桷牥楥⁮桴⁥敭牴捩⁳湩汣摵⁥牰景汩湩⁧慢敳⁤湯琠浩⁥景搠祡㰮牢ਾㄳ⸸†吠敨洠瑥潨⁤景挠慬浩㌠㘱‬桷牥楥⁮桴⁥敭牴捩⁳湩汣摵⁥敧杯慲桰捩污氠捯瑡潩⁮景猠瑩⁥楶楳潴獲㰮牢ਾㄳ⸹†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬桷牥楥⁮桴⁥楶睥牥馀甠慳敧椠摮捩慩椠⁳晥敦瑣摥戠⁹牴捡楫杮漠⁦桴⁥敭畮瘠敩敷獲胢ₙ獵条⁥景琠敨椠楮楴污栠敩慲捲票㰮牢ਾ㈳⸰†吠敨洠瑥潨⁤景挠慬浩㌠㤱‬桷牥楥⁮牴捡楫杮椠据畬敤⁳⁡畮扭牥漠⁦浩牰獥楳湯⁳慭敤戠⁹敭畮椠整獭㰮牢ਾ㈳⸱†吠敨洠瑥潨⁤景挠慬浩㌠㤱‬桷牥楥⁮牴捡楫杮椠据畬敤⁳⁡畮扭牥漠⁦楴敭⁳⁡敭畮椠整⁭獩猠汥捥整⹤戼㹲㌊㈲‮†桔⁥敭桴摯漠⁦汣楡⁭ㄳⰹ眠敨敲湩琠慲正湩⁧湩汣摵獥愠⁮浡畯瑮漠⁦楴敭愠洠湥⁵瑩浥椠⁳潣獮摩牥摥㰮牢ਾ㈳⸳†吠敨洠瑥潨⁤景挠慬浩㌠㤱‬桷牥楥⁮牴捡楫杮椠据畬敤⁳⁡畮扭牥漠⁦楴敭⁳⁡敭畮椠整⁭獩瀠獡敳⁤癯牥㰮牢ਾ㈳⸴†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬桷牥楥⁮桴⁥潭楤楦慣楴湯椠⁳数晲牯敭⁤畡潴慭楴慣汬⹹戼㹲㌊㔲‮†桔⁥敭桴摯漠⁦汣楡⁭ㄳⰹ眠敨敲湩琠敨洠摯晩捩瑡潩⁮獩瀠牥潦浲摥洠湡慵汬⹹戼㹲㌊㘲‮†桔⁥敭桴摯漠⁦汣楡⁭㈳ⰵ眠敨敲湩琠敨洠湡慵⁬潭楤楦慣楴湯椠⁳数晲牯敭⁤楷桴愠洠湥⁵摥瑩牯㰮牢ਾ㈳⸷†吠敨洠瑥潨⁤景挠慬浩㌠㘲‬桷牥楥⁮桴⁥敭畮攠楤潴⁲楤灳慬獹琠慲正湩⁧瑳瑡獩楴獣㰮牢ਾ㈳⸸†吠敨洠瑥潨⁤景挠慬浩㌠㜲‬桷牥楥⁮桴⁥牴捡楫杮猠慴楴瑳捩⁳湩汣摵⁥湡⁹景›⁡畮扭牥漠⁦浩牰獥楳湯⁳慭敤戠⁹敭畮椠整獭‬⁡畮扭牥漠⁦楴敭⁳⁡敭畮椠整⁭獩猠汥捥整Ɽ愠⁮浡畯瑮漠⁦楴敭愠洠湥⁵瑩浥椠⁳潣獮摩牥摥‬⁡畮扭牥漠⁦楴敭⁳⁡敭畮椠整⁭獩瀠獡敳⁤癯牥㰮牢ਾ㈳⸹†吠敨洠瑥潨⁤景挠慬浩㌠㘲‬桷牥楥⁮桴⁥敭畮攠楤潴⁲楤灳慬獹甠慳敧挠湯瑳慲湩獴琠慨⁴楬業⁴潨⁷⁡敭畮椠整⁭慭⁹敢甠敳⹤戼㹲㌊〳‮†桔⁥敭桴摯漠⁦汣楡⁭㈳ⰹ眠敨敲湩琠敨甠慳敧挠湯瑳慲湩獴椠据畬敤愠祮漠㩦愠渠浵敢⁲景椠灭敲獳潩獮洠摡⁥祢洠湥⁵瑩浥ⱳ愠渠浵敢⁲景琠浩獥愠洠湥⁵瑩浥椠⁳敳敬瑣摥‬湡愠潭湵⁴景琠浩⁥⁡敭畮椠整⁭獩挠湯楳敤敲Ɽ愠渠浵敢⁲景琠浩獥愠洠湥⁵瑩浥椠⁳慰獳摥漠敶⹲戼㹲㌊ㄳ‮†桔⁥敭桴摯漠⁦汣楡⁭㠲ⰷ†桷牥楥⁮潭楤楦慣楴湯椠据畬敤⁳牡慲杮湩⁧潭敲瀠灯汵牡洠湥⁵瑩浥⁳潭敲瀠潲業敮瑮祬㰮牢ਾ㌳⸲†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬眠敨敲湩朠敲瑡牥瀠潲敭慮据⁥湩汣摵獥愠祮漠㩦栠杩敨⁲汰捡浥湥⁴湩愠洠湥⁵楨牥牡档ⱹ栠杩敨⁲汰捡浥湥⁴楷桴湩愠琠敩⁲景愠洠湥⁵楨牥牡档⹹㰮牢ਾ㌳⸳†吠敨洠瑥潨⁤景挠慬浩㌠ㄳ‬桷牥楥⁮潭敲瀠灯汵牡洠湥⁵瑩浥⁳牡⁥敭畮椠整獭琠慨⁴慨敶戠敥⁮敳敬瑣摥洠牯⁥牦煥敵瑮祬㰮牢ਾ㌳⸴†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥愠牲湡楧杮氠獥⁳潰異慬⁲敭畮椠整獭洠牯⁥牰浯湩湥汴⹹戼㹲㌊㔳‮†桔⁥敭桴摯漠⁦汣楡⁭㠲ⰷ眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥瀠慬散敭瑮漠⁦灳湯潳敲⁤摡敶瑲獩湩⁧景洠湥⁵瑩浥⹳戼㹲㌊㘳‮†桔⁥敭桴摯漠⁦汣楡⁭㌳ⰵ†桷牥楥⁮潭楤楦慣楴湯椠据畬敤⁳牡慲杮湩⁧桴⁥敭畮椠整獭戠獡摥漠⁮潣瑮硥⹴戼㹲㌊㜳‮†桔⁥敭桴摯漠⁦汣楡⁭㌳ⰵ†桷牥楥⁮潭楤楦慣楴湯椠据畬敤⁳牡慲杮湩⁧桴⁥敭畮椠整獭琠⁯湩牣慥敳攠晦捩捡⁹景琠敨猠潰獮牯摥愠癤牥楴楳杮㰮牢ਾ㌳⸸†吠敨洠瑥潨⁤景挠慬浩㌠㔳‬眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥瀠慬楣杮猠潰獮牯摥愠癤牥楴楳杮椠⁮潬慣楴湯⁳桴瑡栠癡⁥敢湥搠瑥牥業敮⁤潴戠⁥潭瑳攠晦捥楴敶琠牨畯桧琠慲正湩⹧戼㹲㌊㤳‮†桔⁥敭桴摯漠⁦汣楡⁭㌳ⰵ眠敨敲湩琠敨瀠慬散敭瑮漠⁦灳湯潳敲⁤摡敶瑲獩湩⁧獩戠獡摥漠⁮潣瑮硥⹴戼㹲㌊〴‮†桔⁥敭桴摯漠⁦汣楡⁭㌳ⰵ眠敨敲湩琠敨瀠慬散敭瑮漠⁦灳湯潳敲⁤摡敶瑲獩湩⁧獩戠獡摥漠⁮楨桧牥戠摩⁳潦⁲摡瀠慬散敭瑮㰮牢ਾ㐳⸱†吠敨洠瑥潨⁤景挠慬浩㌠㔳‬桷牥楥⁮桴⁥汰捡敭瑮漠⁦灳湯潳敲⁤摡敶瑲獩湩⁧獩洠牯⁥牰浯湩湥⹴戼㹲㌊㈴‮†桔⁥敭桴摯漠⁦汣楡⁭㌳ⰵ眠敨敲湩琠敨瀠慬浣湥⁴景猠潰獮牯摥愠癤牥楴楳杮椠⁳畳橢捥⁴潴甠慳敧挠湯瑳慲湩獴㰮牢ਾ㐳⸳†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥愠牲湡楧杮琠敨洠湥⁵瑩浥⁳潴椠据敲獡⁥晥楦慣祣㰮牢ਾ㐳⸴†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥瀠慬楣杮洠湥⁵瑩浥⁳潴椠据敲獡⁥晥楦慣祣㰮牢ਾ㐳⸵†吠敨洠瑥潨⁤景挠慬浩㈠㜸‬眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥瀠慬楣杮洠湥⁵瑩浥⁳慢敳⁤湯挠湯整瑸㰮牢ਾ㐳⸶†吠敨洠瑥潨⁤景挠慬浩㌠㔴‬眠敨敲湩琠敨挠湯整瑸椠⁳慢敳⁤湯漠桴牥洠湥⁵瑩浥⁳楷桴湩琠敨栠敩慲捲票漠⁦敭畮椠整獭㰮牢ਾ㐳⸷†吠敨洠瑥潨⁤景挠慬浩㌠㔴‬眠敨敲湩琠敨挠湯整瑸椠⁳慢敳⁤湯挠湯整瑮漠⁦敲敦敲据獥琠牡敧整⁤祢洠湥⁵瑩浥⁳湩琠敨栠敩慲捲票漠⁦敭畮椠整獭㰮牢ਾ㐳⸸†吠敨洠瑥潨⁤景挠慬浩㌠㔴‬眠敨敲湩琠敨挠湯整瑸椠⁳慢敳⁤湯挠湯整瑮漠⁦敲敦敲据獥琠牡敧整⁤祢洠湥⁵瑩浥⁳湩琠敨栠敩慲捲票漠⁦敭畮椠整獭㰮牢ਾ㐳⸹†䄠瀠潲散獳牯攠慮汢摥洠瑥潨Ɽ挠浯牰獩湩㩧戼㹲爊捥楥楶杮愠爠煥敵瑳映牯愠甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⠠偕乕⥉映潲⁭⁡敲畱獥楴杮挠楬湥⁴捡散獳湩⁧潣瑮湥ⱴ戼㹲 †††桷牥楥⁮桴⁥敲畱獥⁴獩琠楲杧牥摥映潲⁭桴⁥捡散獳湩⁧景挠湯整瑮‬戼㹲 †††桷牥楥⁮桴⁥偕乕⁉摩湥楴楦獥愠琠牡敧⁴潣瑮湥⁴獡敳ⱴ愠摮㰠牢ਾ†††眠敨敲湩琠敨唠啐䥎椠⁳⁡畭瑬⵩摩湥楴楦牥栠癡湩⁧畭瑬灩敬爠晥牥湥散⁳潴挠湯整瑮椠整獭爠汥瑡摥琠⁯桴⁥慴杲瑥挠湯整瑮愠獳瑥㰻牢ਾ扯慴湩湩⁧湡唠啐䥎洠湥⁵灳捥晩捩瑡潩㭮戼㹲漊瑢楡楮杮唠啐䥎爠捥牯⁤湩潦浲瑡潩⁮牦浯愠⁮偕乕⁉楤敲瑣牯㭹戼㹲朊湥牥瑡湩⁧湡唠啐䥎栠敩慲捲票漠⁦敭畮椠整獭映潲⁭桴⁥偕乕⁉敭畮猠数楣楦慣楴湯‬桷牥楥⁮桴⁥偕乕⁉敭畮猠数楣楦慣楴湯椠⁳獵摥琠⁯灳捥晩⁹慶畬獥映潲⁭偕乕⁉敲潣摲椠普牯慭楴湯眠瑩⁨桷捩⁨潴瀠灯汵瑡⁥桴⁥偕乕⁉敭畮㰬牢ਾ†††眠敨敲湩洠湥⁵瑩浥⁳慭⁹湩汣摵⁥潣灭獯瑩⁥敭楤ⱡ戼㹲 †††桷牥楥⁮敭畮椠整獭洠祡椠据畬敤椠普牯慭楴湯映潲⁭⁡慢正攭摮猠牥敶Ⱳ戼㹲 †††桷牥楥⁮桴⁥敭畮椠整獭愠敲氠湩獫琠⁯晥敦瑣愠瀠牵档獡ⱥ㰠牢ਾ†††眠敨敲湩琠敨栠敩慲捲票漠⁦敭畮椠整獭椠⁳牢畯桧⁴扡畯⁴祢愠⁮摡敶瑲獩浥湥㭴戼㹲瘊牥晩楹杮琠慨⁴桴⁥偕乕⁉敭畮胢玙爠晥牥湥散琠牡敧⁴摩湥楴楦牥⁳湡⁤獡潳楣瑡摥洠湥⁵瑩浥椠普牯慭楴湯愠敲瘠污摩㰻牢ਾ晥敦瑣湩⁧牴捡楫杮漠⁦偕乕⁉敭畮甠慳敧映潲⁭湥ⵤ獵牥ⱳ戼㹲 †††桷牥楥⁮牴捡楫杮椠据畬敤⁳⁡畮扭牥漠⁦浩牰獥楳湯⁳慭敤戠⁹敭畮椠整獭㰬牢ਾ†††眠敨敲湩琠慲正湩⁧湩汣摵獥愠渠浵敢⁲景琠浩獥愠洠湥⁵瑩浥椠⁳敳敬瑣摥㰻牢ਾ潭楤祦湩⁧偕乕⁉敭畮椠整獭戠獡摥漠⁮桴⁥牴捡楫杮漠⁦獵条ⱥ戼㹲 †††桷牥楥⁮潭楤楦慣楴湯椠据畬敤⁳牡慲杮湩⁧潭敲瀠灯汵牡洠湥⁵瑩浥⁳潭敲瀠潲業敮瑮祬‬湡㱤牢ਾ†††眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥瀠慬楣杮洠湥⁵瑩浥⁳潴椠据敲獡⁥晥楦慣祣‮戼㹲㌊〵‮†⁁牰捯獥潳⁲湥扡敬⁤敭桴摯‬潣灭楲楳杮㰺牢ਾ敲散癩湩⁧⁡敲畱獥⁴潦⁲⁡湵煩敵瀠牥楳瑳湥⁴湵癩牥慳⁬慮敭椠敤瑮晩敩⁲唨啐䥎 牦浯愠爠煥敵瑳湩⁧汣敩瑮愠捣獥楳杮挠湯整瑮㰬牢ਾ†††眠敨敲湩琠敨爠煥敵瑳椠⁳牴杩敧敲⁤牦浯琠敨愠捣獥楳杮漠⁦潣瑮湥ⱴ㰠牢ਾ†††眠敨敲湩琠敨唠啐䥎椠敤瑮晩敩⁳⁡慴杲瑥挠湯整瑮愠獳瑥‬湡⁤戼㹲 †††桷牥楥⁮桴⁥偕乕⁉獩愠洠汵楴椭敤瑮晩敩⁲慨楶杮洠汵楴汰⁥敲敦敲据獥琠⁯潣瑮湥⁴瑩浥⁳敲慬整⁤潴琠敨琠牡敧⁴潣瑮湥⁴獡敳㭴戼㹲漊瑢楡楮杮愠⁮偕乕⁉敭畮猠数楣楦慣楴湯㰻牢ਾ扯慴湩湩⁧偕乕⁉敲潣摲椠普牯慭楴湯映潲⁭湡唠啐䥎搠物捥潴祲㰻牢ਾ敧敮慲楴杮愠⁮偕乕⁉楨牥牡档⁹景洠湥⁵瑩浥⁳牦浯琠敨唠啐䥎洠湥⁵灳捥晩捩瑡潩Ɱ眠敨敲湩琠敨唠啐䥎洠湥⁵灳捥晩捩瑡潩⁮獩甠敳⁤潴猠数楣祦瘠污敵⁳牦浯唠啐䥎爠捥牯⁤湩潦浲瑡潩⁮楷桴眠楨档琠⁯潰異慬整琠敨唠啐䥎洠湥㭵戼㹲攊晦捥楴杮琠慲正湩⁧景唠啐䥎洠湥⁵獵条⁥牦浯攠摮甭敳獲㰻牢ਾ潭楤祦湩⁧偕乕⁉敭畮椠整獭戠獡摥漠⁮桴⁥牴捡楫杮漠⁦獵条⹥㰠牢ਾ㔳⸱†吠敨洠瑥潨⁤景挠慬浩㌠〵‬畦瑲敨Ⱳ挠浯牰獩湩㩧戼㹲瘊牥晩楹杮琠慨⁴桴⁥偕乕⁉敭畮胢玙爠晥牥湥散琠牡敧⁴摩湥楴楦牥⁳湡⁤獡潳楣瑡摥洠湥⁵瑩浥椠普牯慭楴湯愠敲瘠污摩㰮牢ਾ㔳⸲†吠敨洠瑥潨⁤景挠慬浩㌠〵‬桷牥楥⁮敭畮椠整獭洠祡椠据畬敤朠慲桰捩⹳戼㹲㌊㌵‮†桔⁥敭桴摯漠⁦汣楡⁭㔳ⰰ眠敨敲湩洠湥⁵瑩浥⁳慭⁹湩汣摵⁥楶敤⹯戼㹲㌊㐵‮†桔⁥敭桴摯漠⁦汣楡⁭㔳ⰰ眠敨敲湩洠湥⁵瑩浥⁳慭⁹湩汣摵⁥潦浲⹳戼㹲㌊㔵‮†桔⁥敭桴摯漠⁦汣楡⁭㔳ⰰ眠敨敲湩洠湥⁵瑩浥⁳慭⁹湩汣摵⁥潣灭獯瑩⁥敭楤⹡戼㹲㌊㘵‮†桔⁥敭桴摯漠⁦汣楡⁭㔳ⰰ眠敨敲湩洠湥⁵瑩浥⁳慭⁹湩汣摵⁥湩潦浲瑡潩⁮牦浯愠戠捡⵫湥⁤敳癲牥㰮牢ਾ㔳⸷†吠敨洠瑥潨⁤景挠慬浩㌠㘵‬桷牥楥⁮桴⁥敭畮椠整獭愠敲氠湩獫琠⁯晥敦瑣愠瀠牵档獡⹥戼㹲㌊㠵‮†桔⁥敭桴摯漠⁦汣楡⁭㔳ⰶ眠敨敲湩琠敨洠湥⁵瑩浥⁳湩汣摵⁥楬敶椠癮湥潴祲㰮牢ਾ㔳⸹†吠敨洠瑥潨⁤景挠慬浩㌠〵‬桷牥楥⁮桴⁥楨牥牡档⁹景洠湥⁵瑩浥⁳獩戠潲杵瑨愠潢瑵戠⁹⁡慢湮牥愠癤牥楴敳敭瑮㰮牢ਾ㘳⸰†吠敨洠瑥潨⁤景挠慬浩㌠〵‬桷牥楥⁮桴⁥楨牥牡档⁹景洠湥⁵瑩浥⁳獩戠潲杵瑨愠潢瑵戠⁹⁡灳湯潳敲⁤摡敶瑲獩湩⁧楬歮㰮牢ਾ㘳⸱†吠敨洠瑥潨⁤景挠慬浩㌠〵‬桷牥楥⁮桴⁥楨牥牡档⁹景洠湥⁵瑩浥⁳獩戠潲杵瑨愠潢瑵戠⁹⁡潤畣敭瑮㰮牢ਾ㘳⸲†吠敨洠瑥潨⁤景挠慬浩㌠〵‬桷牥楥⁮桴⁥楨牥牡档⁹景洠湥⁵瑩浥⁳獩戠潲杵瑨愠潢瑵戠⁹⁡敭楤⁡汰祡牥㰮牢ਾ㘳⸳†吠敨洠瑥潨⁤景挠慬浩㌠〵‬桷牥楥⁮桴⁥偕乕⁉敭畮椠⁳潣灭獯摥漠⁦敭畮椠整獭猠汥捥整⁤祢挠湯畳瑬湡獴㰮牢ਾ㘳⸴†吠敨洠瑥潨⁤景挠慬浩㌠㌶‬桷牥楥⁮桴⁥潣獮汵慴瑮⁳牡⁥慭歲瑥湩⁧湡污獹獴㰮牢ਾ㘳⸵†吠敨洠瑥潨⁤景挠慬浩㌠〵‬桷牥楥⁮牴捡楫杮椠据畬敤⁳⁡畮扭牥漠⁦浩牰獥楳湯⁳慭敤戠⁹敭畮椠整獭㰮牢ਾ㘳⸶†吠敨洠瑥潨⁤景挠慬浩㌠〵‬桷牥楥⁮牴捡楫杮椠据畬敤⁳⁡畮扭牥漠⁦楴敭⁳⁡敭畮椠整⁭獩猠汥捥整⹤戼㹲㌊㜶‮†桔⁥敭桴摯漠⁦汣楡⁭㔳ⰰ眠敨敲湩琠慲正湩⁧湩汣摵獥愠⁮浡畯瑮漠⁦楴敭愠洠湥⁵瑩浥椠⁳潣獮摩牥摥㰮牢ਾ㘳⸸†吠敨洠瑥潨⁤景挠慬浩㌠〵‬桷牥楥⁮牴捡楫杮椠据畬敤⁳⁡畮扭牥漠⁦楴敭⁳⁡敭畮椠整⁭獩瀠獡敳⁤癯牥㰮牢ਾ㘳⸹†吠敨洠瑥潨⁤景挠慬浩㌠〵‬桷牥楥⁮桴⁥潭楤楦慣楴湯椠⁳数晲牯敭⁤畡潴慭楴慣汬⹹戼㹲㌊〷‮†桔⁥敭桴摯漠⁦汣楡⁭㔳ⰰ眠敨敲湩琠敨洠摯晩捩瑡潩⁮獩瀠牥潦浲摥洠湡慵汬⹹戼㹲㌊ㄷ‮†桔⁥敭桴摯漠⁦汣楡⁭㜳ⰰ眠敨敲湩琠敨洠湡慵⁬潭楤楦慣楴湯椠⁳数晲牯敭⁤楷桴愠洠湥⁵摥瑩牯㰮牢ਾ㜳⸲†吠敨洠瑥潨⁤景挠慬浩㌠ㄷ‬桷牥楥⁮桴⁥敭畮攠楤潴⁲楤灳慬獹琠慲正湩⁧瑳瑡獩楴獣㰮牢ਾ㜳⸳†吠敨洠瑥潨⁤景挠慬浩㌠㈷‬桷牥楥⁮桴⁥牴捡楫杮猠慴楴瑳捩⁳湩汣摵⁥湡⁹景›⁡畮扭牥漠⁦浩牰獥楳湯⁳慭敤戠⁹敭畮椠整獭‬⁡畮扭牥漠⁦楴敭⁳⁡敭畮椠整⁭獩猠汥捥整Ɽ愠⁮浡畯瑮漠⁦楴敭愠洠湥⁵瑩浥椠⁳潣獮摩牥摥‬⁡畮扭牥漠⁦楴敭⁳⁡敭畮椠整⁭獩瀠獡敳⁤癯牥㰮牢ਾ㜳⸴†吠敨洠瑥潨⁤景挠慬浩㌠ㄷ‬桷牥楥⁮桴⁥敭畮攠楤潴⁲楤灳慬獹甠慳敧挠湯瑳慲湩獴琠慨⁴楬業⁴潨⁷⁡敭畮椠整⁭慭⁹敢甠敳⹤戼㹲㌊㔷‮†桔⁥敭桴摯漠⁦汣楡⁭㜳ⰴ眠敨敲湩琠敨甠慳敧挠湯瑳慲湩獴椠据畬敤愠祮漠㩦愠渠浵敢⁲景椠灭敲獳潩獮洠摡⁥祢洠湥⁵瑩浥ⱳ愠渠浵敢⁲景琠浩獥愠洠湥⁵瑩浥椠⁳敳敬瑣摥‬湡愠潭湵⁴景琠浩⁥⁡敭畮椠整⁭獩挠湯楳敤敲Ɽ愠渠浵敢⁲景琠浩獥愠洠湥⁵瑩浥椠⁳慰獳摥漠敶⹲戼㹲㌊㘷‮†桔⁥敭桴摯漠⁦汣楡⁭㔳ⰰ眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥愠牲湡楧杮洠牯⁥潰異慬⁲敭畮椠整獭洠牯⁥牰浯湩湥汴⹹戼㹲㌊㜷‮†桔⁥敭桴摯漠⁦汣楡⁭㔳ⰰ眠敨敲湩朠敲瑡牥瀠潲敭慮据⁥湩汣摵獥愠祮漠㩦栠杩敨⁲汰捡浥湥⁴湩愠洠湥⁵楨牥牡档ⱹ栠杩敨⁲汰捡浥湥⁴楷桴湩愠琠敩⁲景愠洠湥⁵楨牥牡档⹹戼㹲㌊㠷‮†桔⁥敭桴摯漠⁦汣楡⁭㜳ⰶ眠敨敲湩洠牯⁥潰異慬⁲敭畮椠整獭愠敲洠湥⁵瑩浥⁳桴瑡栠癡⁥敢湥猠汥捥整⁤潭敲映敲畱湥汴⹹戼㹲㌊㤷‮†桔⁥敭桴摯漠⁦汣楡⁭㔳ⰰ眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥愠牲湡楧杮氠獥⁳潰異慬⁲敭畮椠整獭洠牯⁥牰浯湩湥汴⹹戼㹲㌊〸‮†桔⁥敭桴摯漠⁦汣楡⁭㔳ⰰ眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥瀠慬散敭瑮漠⁦灳湯潳敲⁤摡敶瑲獩湩⁧景洠湥⁵瑩浥⹳戼㹲㌊ㄸ‮†桔⁥敭桴摯漠⁦汣楡⁭㠳ⰰ眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥愠牲湡楧杮琠敨洠湥⁵瑩浥⁳慢敳⁤湯挠湯整瑸㰮牢ਾ㠳⸲†吠敨洠瑥潨⁤景挠慬浩㌠〸‬桷牥楥⁮潭楤楦慣楴湯椠据畬敤⁳牡慲杮湩⁧桴⁥敭畮椠整獭琠⁯湩牣慥敳攠晦捩捡⁹景琠敨猠潰獮牯摥愠癤牥楴楳杮㰮牢ਾ㠳⸳†吠敨洠瑥潨⁤景挠慬浩㌠〸‬桷牥楥⁮潭楤楦慣楴湯椠据畬敤⁳汰捡湩⁧灳湯潳敲⁤摡敶瑲獩湩⁧湩氠捯瑡潩獮琠慨⁴慨敶戠敥⁮敤整浲湩摥琠⁯敢洠獯⁴晥敦瑣癩⁥桴潲杵⁨牴捡楫杮㰮牢ਾ㠳⸴†吠敨洠瑥潨⁤景挠慬浩㌠〸‬桷牥楥⁮桴⁥汰捡浥湥⁴景猠潰獮牯摥愠癤牥楴楳杮椠⁳慢敳⁤湯挠湯整瑸㰮牢ਾ㠳⸵†吠敨洠瑥潨⁤景挠慬浩㌠〸‬桷牥楥⁮桴⁥汰捡浥湥⁴景猠潰獮牯摥愠癤牥楴楳杮椠⁳慢敳⁤湯栠杩敨⁲楢獤映牯愠⁤汰捡浥湥⹴戼㹲㌊㘸‮†桔⁥敭桴摯漠⁦汣楡⁭㠳ⰰ眠敨敲湩琠敨瀠慬浣湥⁴景猠潰獮牯摥愠癤牥楴楳杮椠⁳潭敲瀠潲業敮瑮㰮牢ਾ㠳⸷†吠敨洠瑥潨⁤景挠慬浩㌠〸‬桷牥楥⁮桴⁥汰捡敭瑮漠⁦灳湯潳敲⁤摡敶瑲獩湩⁧獩猠扵敪瑣琠⁯獵条⁥潣獮牴楡瑮⹳戼㹲㌊㠸‮†桔⁥敭桴摯漠⁦汣楡⁭㔳ⰰ眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥瀠慬楣杮洠湥⁵瑩浥⁳潴椠据敲獡⁥晥楦慣祣㰮牢ਾ㠳⸹†吠敨洠瑥潨⁤景挠慬浩㌠〵‬桷牥楥⁮潭楤楦慣楴湯椠据畬敤⁳汰捡湩⁧敭畮椠整獭戠獡摥漠⁮潣瑮硥⹴戼㹲㌊〹‮†桔⁥敭桴摯漠⁦汣楡⁭㠳ⰹ眠敨敲湩琠敨挠湯整瑸椠⁳慢敳⁤湯漠桴牥洠湥⁵瑩浥⁳楷桴湩琠敨栠敩慲捲票漠⁦敭畮椠整獭㰮牢ਾ㤳⸱†吠敨洠瑥潨⁤景挠慬浩㌠㤸‬桷牥楥⁮桴⁥潣瑮硥⁴獩戠獡摥漠⁮潣瑮湥⁴景爠晥牥湥散⁳慴杲瑥摥戠⁹敭畮椠整獭椠⁮桴⁥楨牥牡档⁹景洠湥⁵瑩浥⹳戼㹲㌊㈹‮†桔⁥敭桴摯漠⁦汣楡⁭㠳ⰹ眠敨敲湩琠敨挠湯整瑸椠⁳慢敳⁤湯挠湯整瑮漠⁦敲敦敲据獥琠牡敧整⁤祢洠湥⁵瑩浥⁳湩琠敨栠敩慲捲票漠⁦敭畮椠整獭㰮牢ਾ㤳⸳†䄠瀠潲散獳牯攠慮汢摥洠瑥潨Ɽ挠浯牰獩湩㩧戼㹲朊湥牥瑡湩⁧⁡楨牥牡档捩污洠湥⁵桴瑡挠浯牰獥敳⁳⁡異捲慨敳挠捹敬㰮牢ਾ㤳⸴†䄠瀠潲散獳牯攠慮汢摥洠瑥潨⁤潦⁲敧敮慲楴杮愠甠敳⁲湩整晲捡ⱥ挠浯牰獩湩㩧戼㹲朊湥牥瑡湩⁧⁡楨牥牡档⁹景洠湥⁵瑩浥⁳牦浯愠洠湥⁵灳捥晩捩瑡潩⁮湡⁤牦浯映敥扤捡⁫牦浯甠敳⁲牴捡楫杮漠⁦獵条⁥景琠敨洠湥⁵瑩浥⁳湩爠獥潰獮⁥潴攠杮条湩⁧潣瑮湥⁴浥敢摤摥眠瑩⁨⁡牴杩敧⁲潴椠癮歯⁥桴⁥楨牥牡档⁹景洠湥⁵瑩浥ⱳ㰠牢ਾ†††眠敨敲湩洠湥⁵瑩浥⁳慭⁹湩汣摵⁥潣灭獯瑩⁥敭楤ⱡ戼㹲 †††桷牥楥⁮敭畮椠整獭洠祡椠据畬敤椠普牯慭楴湯映潲⁭⁡慢正攭摮猠牥敶Ⱳ戼㹲 †††桷牥楥⁮桴⁥敭畮椠整獭愠敲氠湩獫琠⁯晥敦瑣愠瀠牵档獡ⱥ愠摮戼㹲 †††桷牥楥⁮桴⁥楨牥牡档⁹景洠湥⁵瑩浥⁳獩戠潲杵瑨愠潢瑵戠⁹湡愠癤牥楴敳敭瑮㰮牢ਾ㤳⸵†䄠瀠潲散獳牯攠慮汢摥洠瑥潨⁤潦⁲敧敮慲楴杮愠甠敳⁲湩整晲捡ⱥ挠浯牰獩湩㩧戼㹲朊湥牥瑡湩⁧⁡楨牥牡档⁹景洠湥⁵瑩浥⁳牦浯愠洠湥⁵灳捥晩捩瑡潩⁮湡⁤牦浯映敥扤捡⁫牦浯甠敳⁲牴捡楫杮漠⁦獵条⁥景琠敨洠湥⁵瑩浥⁳湩爠獥潰獮⁥潴攠杮条湩⁧潣瑮湥⁴浥敢摤摥眠瑩⁨⁡牴杩敧⁲潴椠癮歯⁥桴⁥楨牥牡档⁹景洠湥⁵瑩浥⹳戼㹲㌊㘹‮†桔⁥敭桴摯漠⁦汣楡⁭㤳ⰵ眠敨敲湩洠湥⁵瑩浥⁳慭⁹湩汣摵⁥牧灡楨獣㰮牢ਾ㤳⸷†吠敨洠瑥潨⁤景挠慬浩㌠㔹‬桷牥楥⁮敭畮椠整獭洠祡椠据畬敤瘠摩潥㰮牢ਾ㤳⸸†吠敨洠瑥潨⁤景挠慬浩㌠㔹‬桷牥楥⁮敭畮椠整獭洠祡椠据畬敤映牯獭㰮牢ਾ㤳⸹†吠敨洠瑥潨⁤景挠慬浩㌠㔹‬桷牥楥⁮敭畮椠整獭洠祡椠据畬敤挠浯潰楳整洠摥慩㰮牢ਾ〴⸰†吠敨洠瑥潨⁤景挠慬浩㌠㔹‬桷牥楥⁮敭畮椠整獭洠祡椠据畬敤椠普牯慭楴湯映潲⁭⁡慢正攭摮猠牥敶⹲戼㹲㐊㄰‮†桔⁥敭桴摯漠⁦汣楡⁭〴ⰰ眠敨敲湩琠敨洠湥⁵瑩浥⁳牡⁥楬歮⁳潴攠晦捥⁴⁡異捲慨敳㰮牢ਾ〴⸲†吠敨洠瑥潨⁤景挠慬浩㐠〰‬桷牥楥⁮桴⁥敭畮椠整獭椠据畬敤氠癩⁥湩敶瑮牯⹹戼㹲㐊㌰‮†桔⁥敭桴摯漠⁦汣楡⁭㤳ⰵ眠敨敲湩琠敨栠敩慲捲票漠⁦敭畮椠整獭椠⁳牢畯桧⁴扡畯⁴祢愠戠湡敮⁲摡敶瑲獩浥湥⹴戼㹲㐊㐰‮†桔⁥敭桴摯漠⁦汣楡⁭㤳ⰵ眠敨敲湩琠敨栠敩慲捲票漠⁦敭畮椠整獭椠⁳牢畯桧⁴扡畯⁴祢愠猠潰獮牯摥愠癤牥楴楳杮氠湩⹫戼㹲㐊㔰‮†桔⁥敭桴摯漠⁦汣楡⁭㤳ⰵ眠敨敲湩琠敨栠敩慲捲票漠⁦敭畮椠整獭椠⁳牢畯桧⁴扡畯⁴祢愠搠捯浵湥⹴戼㹲㐊㘰‮†桔⁥敭桴摯漠⁦汣楡⁭㤳ⰵ眠敨敲湩琠敨栠敩慲捲票漠⁦敭畮椠整獭椠⁳牢畯桧⁴扡畯⁴祢愠洠摥慩瀠慬敹⹲戼㹲㐊㜰‮†⁁牰捯獥潳⁲湥扡敬⁤敭桴摯映牯朠湥牥瑡湩⁧⁡獵牥椠瑮牥慦散‬潣灭楲楳杮㰺牢ਾ敧敮慲楴杮愠⁮楦獲⁴楴牥栠敩慲捲楨慣⁬敭畮氠癥汥挠湯慴湩湩⁧湩潦浲瑡潩⁮扡畯⁴摩湥楴祦湩⁧敳浧湥⁴敳敬瑣牯⁳湡⁤慴杲瑥⁳業摤敬琠敩⁲楨牥牡档捩污洠湥獵㰻牢ਾ敧敮慲楴杮愠洠摩汤⁥楴牥栠敩慲捲楨慣⁬敭畮氠癥汥挠湯慴湩湩⁧湩潦浲瑡潩⁮扡畯⁴摩湥楴祦湩⁧牢湡⁤敳敬瑣牯⁳湡⁤慴杲瑥⁳慬整⁲楴牥栠敩慲捲楨慣⁬敭畮㭳戼㹲朊湥牥瑡湩⁧⁡慬整⁲楴牥栠敩慲捲楨慣⁬敭畮氠癥汥挠湯慴湩湩⁧湩潦浲瑡潩⁮湡⁤慴杲瑥⁳慳敭戠慲摮琠慲獮捡楴湯ⱳ㰠牢ਾ†††眠敨敲湩洠湥⁵瑩浥⁳楷桴湩琠敨栠敩慲捲票洠祡椠据畬敤挠浯潰楳整洠摥慩㰬牢ਾ†††眠敨敲湩琠敨洠湥⁵瑩浥⁳慭⁹湩汣摵⁥湩潦浲瑡潩⁮牦浯愠戠捡⵫湥⁤敳癲牥㰬牢ਾ†††眠敨敲湩琠敨洠湥⁵瑩浥⁳牡⁥楬歮⁳潴攠晦捥⁴⁡異捲慨敳‬湡㱤牢ਾ†††眠敨敲湩琠敨栠敩慲捲票漠⁦敭畮椠整獭椠⁳牢畯桧⁴扡畯⁴祢愠⁮摡敶瑲獩浥湥⹴戼㹲㐊㠰‮†⁁牰捯獥潳⁲湥扡敬⁤敭桴摯映牯朠湥牥瑡湩⁧⁡獵牥椠瑮牥慦散‬潣灭楲楳杮㰺牢ਾ敧敮慲楴杮愠⁮楦獲⁴楴牥栠敩慲捲楨慣⁬敭畮氠癥汥挠湯慴湩湩⁧湩潦浲瑡潩⁮扡畯⁴摩湥楴祦湩⁧敳浧湥⁴敳敬瑣牯⁳湡⁤慴杲瑥⁳業摤敬琠敩⁲楨牥牡档捩污洠湥獵㰻牢ਾ敧敮慲楴杮愠洠摩汤⁥楴牥栠敩慲捲楨慣⁬敭畮氠癥汥挠湯慴湩湩⁧湩潦浲瑡潩⁮扡畯⁴摩湥楴祦湩⁧牢湡⁤敳敬瑣牯⁳湡⁤慴杲瑥⁳慬整⁲楴牥栠敩慲捲楨慣⁬敭畮㭳戼㹲朊湥牥瑡湩⁧⁡慬整⁲楴牥栠敩慲捲楨慣⁬敭畮氠癥汥挠湯慴湩湩⁧湩潦浲瑡潩⁮湡⁤慴杲瑥⁳慳敭戠慲摮琠慲獮捡楴湯⹳戼㹲㐊㤰‮†桔⁥敭桴摯漠⁦汣楡⁭〴ⰸ眠敨敲湩洠湥⁵瑩浥⁳楷桴湩琠敨栠敩慲捲票洠祡椠据畬敤朠慲桰捩⹳戼㹲㐊〱‮†桔⁥敭桴摯漠⁦汣楡⁭〴ⰸ眠敨敲湩洠湥⁵瑩浥⁳楷桴湩琠敨栠敩慲捲票洠祡椠据畬敤瘠摩潥㰮牢ਾㄴ⸱†吠敨洠瑥潨⁤景挠慬浩㐠㠰‬桷牥楥⁮敭畮椠整獭眠瑩楨⁮桴⁥楨牥牡档⁹慭⁹湩汣摵⁥潦浲⹳戼㹲㐊㈱‮†桔⁥敭桴摯漠⁦汣楡⁭〴ⰸ眠敨敲湩洠湥⁵瑩浥⁳楷桴湩琠敨栠敩慲捲票洠祡椠据畬敤挠浯潰楳整洠摥慩㰮牢ਾㄴ⸳†吠敨洠瑥潨⁤景挠慬浩㐠㠰‬桷牥楥⁮敭畮椠整獭眠瑩楨⁮桴⁥楨牥牡档⁹慭⁹湩汣摵⁥湩潦浲瑡潩⁮牦浯愠戠捡⵫湥⁤敳癲牥㰮牢ਾㄴ⸴†吠敨洠瑥潨⁤景挠慬浩㐠㌱‬桷牥楥⁮桴⁥敭畮椠整獭愠敲氠湩獫琠⁯晥敦瑣愠瀠牵档獡⹥戼㹲㐊㔱‮†桔⁥敭桴摯漠⁦汣楡⁭ㄴⰳ眠敨敲湩琠敨洠湥⁵瑩浥⁳湩汣摵⁥楬敶椠癮湥潴祲㰮牢ਾㄴ⸶†吠敨洠瑥潨⁤景挠慬浩㐠㠰‬桷牥楥⁮桴⁥楨牥牡档⁹景洠湥⁵瑩浥⁳獩戠潲杵瑨愠潢瑵戠⁹⁡慢湮牥愠癤牥楴敳敭瑮㰮牢ਾㄴ⸷†吠敨洠瑥潨⁤景挠慬浩㐠㠰‬桷牥楥⁮桴⁥楨牥牡档⁹景洠湥⁵瑩浥⁳獩戠潲杵瑨愠潢瑵戠⁹⁡灳湯潳敲⁤摡敶瑲獩湩⁧楬歮㰮牢ਾㄴ⸸†吠敨洠瑥潨⁤景挠慬浩㐠㠰‬桷牥楥⁮桴⁥楨牥牡档⁹景洠湥⁵瑩浥⁳獩戠潲杵瑨愠潢瑵戠⁹⁡潤畣敭瑮㰮牢ਾㄴ⸹†吠敨洠瑥潨⁤景挠慬浩㐠㠰‬桷牥楥⁮桴⁥楨牥牡档⁹景洠湥⁵瑩浥⁳獩戠潲杵瑨愠潢瑵戠⁹⁡敭楤⁡汰祡牥㰮牢ਾ㈴⸰†䄠猠獹整⁭潴洠歡⁥⁡敭畮‬潣灭楲楳杮㰺牢ਾ敭湡⁳潴朠湥牥瑡⁥⁡楨牥牡档捩污洠湥⁵桴瑡挠浯牰獥敳⁳⁡異捲慨敳挠捹敬㰮牢ਾ㈴⸱†䄠猠獹整⁭潴洠歡⁥⁡敭畮‬潣灭楲楳杮㰺牢ਾ敭湡⁳潴挠敲瑡⁥湡椠楮楴污栠敩慲捲票漠⁦敭畮椠整獭眠敨敲愠攠捡⁨敭畮椠整⁭慨⁳⁡敲敦敲据⁥慴杲瑥椠敤瑮晩敩㱲牢ਾ†††眠敨敲湩洠湥⁵瑩浥⁳慭⁹湩汣摵⁥潣灭獯瑩⁥敭楤ⱡ戼㹲 †††桷牥楥⁮敭畮椠整獭洠祡椠据畬敤椠普牯慭楴湯映潲⁭⁡慢正攭摮猠牥敶Ⱳ戼㹲 †††桷牥楥⁮桴⁥敭畮椠整獭愠敲氠湩獫琠⁯晥敦瑣愠瀠牵档獡ⱥ愠摮戼㹲 †††桷牥楥⁮桴⁥楨牥牡档⁹景洠湥⁵瑩浥⁳獩戠潲杵瑨愠潢瑵戠⁹湡愠癤牥楴敳敭瑮㰻牢ਾ敭湡⁳潴搠獩牴扩瑵⁥桴⁥湩瑩慩⁬楨牥牡档⁹潦⁲潣獮摩牥瑡潩⁮祢洠湥⁵楶睥牥㭳戼㹲洊慥獮琠⁯敶楲祦琠慨⁴桴⁥湩瑩慩⁬楨牥牡档馀⁳敲敦敲据⁥慴杲瑥椠敤瑮晩敩獲愠摮愠獳捯慩整⁤敭畮椠整⁭湩潦浲瑡潩⁮牡⁥慶楬㭤戼㹲洊慥獮琠⁯晥敦瑣琠慲正湩⁧景琠敨洠湥⁵楶睥牥馀甠慳敧漠⁦桴⁥湩瑩慩⁬楨牥牡档ⱹ戼㹲 †††桷牥楥⁮牴捡楫杮椠据畬敤⁳⁡畮扭牥漠⁦浩牰獥楳湯⁳慭敤戠⁹敭畮椠整獭㰬牢ਾ†††眠敨敲湩琠慲正湩⁧湩汣摵獥愠渠浵敢⁲景琠浩獥愠洠湥⁵瑩浥椠⁳敳敬瑣摥㰻牢ਾ敭湡⁳潴洠摯晩⁹桴⁥敭畮椠整⁭湩琠敨椠楮楴污栠敩慲捲票戠獡摥漠⁮桴⁥牴捡楫杮漠⁦獵条ⱥ戼㹲 †††桷牥楥⁮潭楤楦慣楴湯椠据畬敤⁳牡慲杮湩⁧潭敲瀠灯汵牡洠湥⁵瑩浥⁳潭敲瀠潲業敮瑮祬㰬牢ਾ†††眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥瀠慬楣杮洠湥⁵瑩浥⁳潴椠据敲獡⁥晥楦慣祣‮戼㹲㐊㈲‮†⁁祳瑳浥琠⁯慭敫愠洠湥Ⱶ挠浯牰獩湩㩧戼㹲洊慥獮琠⁯敲散癩⁥⁡敲畱獥⁴潦⁲⁡湵煩敵瀠牥楳瑳湥⁴湵癩牥慳⁬慮敭椠敤瑮晩敩⁲唨啐䥎 牦浯愠爠煥敵瑳湩⁧汣敩瑮愠捣獥楳杮挠湯整瑮㰬牢ਾ†††眠敨敲湩琠敨爠煥敵瑳椠⁳牴杩敧敲⁤牦浯琠敨愠捣獥楳杮漠⁦潣瑮湥ⱴ㰠牢ਾ†††眠敨敲湩琠敨唠啐䥎椠敤瑮晩敩⁳⁡慴杲瑥挠湯整瑮愠獳瑥‬湡⁤戼㹲 †††桷牥楥⁮桴⁥偕乕⁉獩愠洠汵楴椭敤瑮晩敩⁲慨楶杮洠汵楴汰⁥敲敦敲据獥琠⁯潣瑮湥⁴瑩浥⁳敲慬整⁤潴琠敨琠牡敧⁴潣瑮湥⁴獡敳㭴戼㹲洊慥獮琠⁯扯慴湩愠⁮偕乕⁉敭畮猠数楣楦慣楴湯㰻牢ਾ敭湡⁳潴漠瑢楡⁮偕乕⁉敲潣摲椠普牯慭楴湯映潲⁭湡唠啐䥎搠物捥潴祲㰻牢ਾ敭湡⁳潴朠湥牥瑡⁥湡唠啐䥎栠敩慲捲票漠⁦敭畮椠整獭映潲⁭桴⁥偕乕⁉敭畮猠数楣楦慣楴湯‬桷牥楥⁮桴⁥偕乕⁉敭畮猠数楣楦慣楴湯椠⁳獵摥琠⁯灳捥晩⁹慶畬獥映潲⁭偕乕⁉敲潣摲椠普牯慭楴湯眠瑩⁨桷捩⁨潴瀠灯汵瑡⁥桴⁥偕乕⁉敭畮㰬牢ਾ†††眠敨敲湩洠湥⁵瑩浥⁳慭⁹湩汣摵⁥潣灭獯瑩⁥敭楤ⱡ戼㹲 †††桷牥楥⁮敭畮椠整獭洠祡椠据畬敤椠普牯慭楴湯映潲⁭⁡慢正攭摮猠牥敶Ⱳ戼㹲 †††桷牥楥⁮桴⁥敭畮椠整獭愠敲氠湩獫琠⁯晥敦瑣愠瀠牵档獡ⱥ愠摮戼㹲 †††桷牥楥⁮桴⁥楨牥牡档⁹景洠湥⁵瑩浥⁳獩戠潲杵瑨愠潢瑵戠⁹湡愠癤牥楴敳敭瑮㰻牢ਾ敭湡⁳潴瘠牥晩⁹桴瑡琠敨唠啐䥎洠湥馀⁳敲敦敲据⁥慴杲瑥椠敤瑮晩敩獲愠摮愠獳捯慩整⁤敭畮椠整⁭湩潦浲瑡潩⁮牡⁥慶楬㭤戼㹲洊慥獮琠⁯晥敦瑣琠慲正湩⁧景唠啐䥎洠湥⁵獵条⁥牦浯攠摮甭敳獲㰬牢ਾ†††眠敨敲湩琠慲正湩⁧湩汣摵獥愠渠浵敢⁲景椠灭敲獳潩獮洠摡⁥祢洠湥⁵瑩浥ⱳ戼㹲 †††桷牥楥⁮牴捡楫杮椠据畬敤⁳⁡畮扭牥漠⁦楴敭⁳⁡敭畮椠整⁭獩猠汥捥整㭤戼㹲洊慥獮琠⁯潭楤祦唠啐䥎洠湥⁵瑩浥⁳慢敳⁤湯琠敨琠慲正湩⁧景甠慳敧㰬牢ਾ†††眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥愠牲湡楧杮洠牯⁥潰異慬⁲敭畮椠整獭洠牯⁥牰浯湩湥汴ⱹ戼㹲 †††桷牥楥⁮潭楤楦慣楴湯椠据畬敤⁳汰捡湩⁧敭畮椠整獭琠⁯湩牣慥敳攠晦捩捡⹹㰠牢ਾ㈴⸳†䄠猠獹整⁭潴朠湥牥瑡⁥⁡獵牥椠瑮牥慦散‬潣灭楲楳杮㰺牢ਾ敭湡⁳潴朠湥牥瑡⁥⁡楨牥牡档⁹景洠湥⁵瑩浥⁳牦浯愠洠湥⁵灳捥晩捩瑡潩⁮湡⁤牦浯映敥扤捡⁫牦浯甠敳⁲牴捡楫杮漠⁦獵条⁥景琠敨洠湥⁵瑩浥⁳湩爠獥潰獮⁥潴攠杮条湩⁧潣瑮湥⁴浥敢摤摥眠瑩⁨⁡牴杩敧⁲潴椠癮歯⁥桴⁥楨牥牡档⁹景洠湥⁵瑩浥ⱳ㰠牢ਾ†††眠敨敲湩洠湥⁵瑩浥⁳慭⁹湩汣摵⁥潣灭獯瑩⁥敭楤ⱡ戼㹲 †††桷牥楥⁮敭畮椠整獭洠祡椠据畬敤椠普牯慭楴湯映潲⁭⁡慢正攭摮猠牥敶Ⱳ戼㹲 †††桷牥楥⁮桴⁥敭畮椠整獭愠敲氠湩獫琠⁯晥敦瑣愠瀠牵档獡ⱥ愠摮戼㹲 †††桷牥楥⁮桴⁥楨牥牡档⁹景洠湥⁵瑩浥⁳獩戠潲杵瑨愠潢瑵戠⁹湡愠癤牥楴敳敭瑮㰮牢ਾ㈴⸴†䄠猠獹整⁭潴朠湥牥瑡⁥⁡獵牥椠瑮牥慦散‬潣灭楲楳杮㰺牢ਾ敭湡⁳潴朠湥牥瑡⁥湡映物瑳琠敩⁲楨牥牡档捩污洠湥⁵敬敶⁬潣瑮楡楮杮椠普牯慭楴湯愠潢瑵椠敤瑮晩楹杮猠来敭瑮猠汥捥潴獲愠摮琠牡敧獴洠摩汤⁥楴牥栠敩慲捲楨慣⁬敭畮㭳戼㹲洊慥獮琠⁯敧敮慲整愠洠摩汤⁥楴牥栠敩慲捲楨慣⁬敭畮氠癥汥挠湯慴湩湩⁧湩潦浲瑡潩⁮扡畯⁴摩湥楴祦湩⁧牢湡⁤敳敬瑣牯⁳湡⁤慴杲瑥⁳慬整⁲楴牥栠敩慲捲楨慣⁬敭畮㭳戼㹲洊慥獮琠⁯敧敮慲整愠氠瑡牥琠敩⁲楨牥牡档捩污洠湥⁵敬敶⁬潣瑮楡楮杮椠普牯慭楴湯愠摮琠牡敧獴猠浡⁥牢湡⁤牴湡慳瑣潩獮‬戼㹲 †††桷牥楥⁮敭畮椠整獭眠瑩楨⁮桴⁥楨牥牡档⁹慭⁹湩汣摵⁥潣灭獯瑩⁥敭楤ⱡ戼㹲 †††桷牥楥⁮桴⁥敭畮椠整獭洠祡椠据畬敤椠普牯慭楴湯映潲⁭⁡慢正攭摮猠牥敶Ⱳ戼㹲 †††桷牥楥⁮桴⁥敭畮椠整獭愠敲氠湩獫琠⁯晥敦瑣愠瀠牵档獡ⱥ愠摮戼㹲 †††桷牥楥⁮桴⁥楨牥牡档⁹景洠湥⁵瑩浥⁳獩戠潲杵瑨愠潢瑵戠⁹湡愠癤牥楴敳敭瑮㰮牢ਾ㈴⸵†䄠洠摥畩⁭敲摡扡敬戠⁹⁡牰捯獥潳⁲潴椠癮歯⁥湡椠瑮牥捡楴湯椠瑮牥慦散‬潣灭楲楳杮㰺牢ਾ湩瑳畲瑣潩⁮楳湧污⁳湩琠敨瀠潲散獳牯爠慥慤汢⁥敭楤浵‬桷牥楥⁮桴⁥湩瑳畲瑣潩⁮楳湧污⁳牡⁥獩畳扡敬戠⁹桴⁥牰捯獥潳⁲湩爠獥潰獮⁥潴甠敳⁲湡⁤祳瑳浥攠敶瑮猠杩慮獬琠⁯湩潶敫㰺牢ਾ⁡楨牥牡档捩污洠湥⁵桴瑡挠浯牰獥敳⁳⁡異捲慨敳挠捹敬㰮牢ਾ㈴⸶†䄠洠摥畩⁭敲摡扡敬戠⁹⁡牰捯獥潳⁲潴洠歡⁥⁡敭畮‬潣灭楲楳杮㰺牢ਾ湩瑳畲瑣潩⁮楳湧污⁳湩琠敨瀠潲散獳牯爠慥慤汢⁥敭楤浵‬桷牥楥⁮桴⁥湩瑳畲瑣潩⁮楳湧污⁳牡⁥獩畳扡敬戠⁹桴⁥牰捯獥潳⁲潴㰺牢ਾ牣慥整愠⁮湩瑩慩⁬楨牥牡档⁹景洠湥⁵瑩浥⁳桷牥⁥⁡慥档洠湥⁵瑩浥栠獡愠爠晥牥湥散琠牡敧⁴摩湥楴楦牥戼㹲 †††桷牥楥⁮敭畮椠整獭洠祡椠据畬敤挠浯潰楳整洠摥慩㰬牢ਾ†††眠敨敲湩洠湥⁵瑩浥⁳慭⁹湩汣摵⁥湩潦浲瑡潩⁮牦浯愠戠捡⵫湥⁤敳癲牥㰬牢ਾ†††眠敨敲湩琠敨洠湥⁵瑩浥⁳牡⁥楬歮⁳潴攠晦捥⁴⁡異捲慨敳‬湡㱤牢ਾ†††眠敨敲湩琠敨栠敩慲捲票漠⁦敭畮椠整獭椠⁳牢畯桧⁴扡畯⁴祢愠⁮摡敶瑲獩浥湥㭴戼㹲搊獩牴扩瑵⁥桴⁥湩瑩慩⁬楨牥牡档⁹潦⁲潣獮摩牥瑡潩⁮祢洠湥⁵楶睥牥㭳戼㹲瘊牥晩⁹桴瑡琠敨椠楮楴污栠敩慲捲票胢玙爠晥牥湥散琠牡敧⁴摩湥楴楦牥⁳湡⁤獡潳楣瑡摥洠湥⁵瑩浥椠普牯慭楴湯愠敲瘠污摩㰻牢ਾ晥敦瑣琠慲正湩⁧景琠敨洠湥⁵楶睥牥馀甠慳敧漠⁦桴⁥湩瑩慩⁬楨牥牡档ⱹ戼㹲 †††桷牥楥⁮牴捡楫杮椠据畬敤⁳⁡畮扭牥漠⁦浩牰獥楳湯⁳慭敤戠⁹敭畮椠整獭㰬牢ਾ†††眠敨敲湩琠慲正湩⁧湩汣摵獥愠渠浵敢⁲景琠浩獥愠洠湥⁵瑩浥椠⁳敳敬瑣摥㰻牢ਾ潭楤祦琠敨洠湥⁵瑩浥椠⁮桴⁥湩瑩慩⁬楨牥牡档⁹慢敳⁤湯琠敨琠慲正湩⁧景甠慳敧㰬牢ਾ†††眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥愠牲湡楧杮洠牯⁥潰異慬⁲敭畮椠整獭洠牯⁥牰浯湩湥汴ⱹ戼㹲 †††桷牥楥⁮潭楤楦慣楴湯椠据畬敤⁳汰捡湩⁧敭畮椠整獭琠⁯湩牣慥敳攠晦捩捡⹹㰠牢ਾ㈴⸷†䄠洠摥畩⁭敲摡扡敬戠⁹⁡牰捯獥潳⁲潴洠歡⁥⁡敭畮‬潣灭楲楳杮㰺牢ਾ湩瑳畲瑣潩⁮楳湧污⁳湩琠敨瀠潲散獳牯爠慥慤汢⁥敭楤浵‬桷牥楥⁮桴⁥湩瑳畲瑣潩⁮楳湧污⁳牡⁥獩畳扡敬戠⁹桴⁥牰捯獥潳⁲潴㰺牢ਾ敲散癩⁥⁡敲畱獥⁴潦⁲⁡湵煩敵瀠牥楳瑳湥⁴湵癩牥慳⁬慮敭椠敤瑮晩敩⁲唨啐䥎 牦浯愠爠煥敵瑳湩⁧汣敩瑮愠捣獥楳杮挠湯整瑮㰬牢ਾ†††眠敨敲湩琠敨爠煥敵瑳椠⁳牴杩敧敲⁤牦浯琠敨愠捣獥楳杮漠⁦潣瑮湥ⱴ㰠牢ਾ†††眠敨敲湩琠敨唠啐䥎椠敤瑮晩敩⁳⁡慴杲瑥挠湯整瑮愠獳瑥‬湡⁤戼㹲 †††桷牥楥⁮桴⁥偕乕⁉獩愠洠汵楴椭敤瑮晩敩⁲慨楶杮洠汵楴汰⁥敲敦敲据獥琠⁯潣瑮湥⁴瑩浥⁳敲慬整⁤潴琠敨琠牡敧⁴潣瑮湥⁴獡敳㭴戼㹲漊瑢楡⁮湡唠啐䥎洠湥⁵灳捥晩捩瑡潩㭮戼㹲漊瑢楡⁮偕乕⁉敲潣摲椠普牯慭楴湯映潲⁭湡唠啐䥎搠物捥潴祲㰻牢ਾ敧敮慲整愠⁮偕乕⁉楨牥牡档⁹景洠湥⁵瑩浥⁳牦浯琠敨唠啐䥎洠湥⁵灳捥晩捩瑡潩Ɱ眠敨敲湩琠敨唠啐䥎洠湥⁵灳捥晩捩瑡潩⁮獩甠敳⁤潴猠数楣祦瘠污敵⁳牦浯唠啐䥎爠捥牯⁤湩潦浲瑡潩⁮楷桴眠楨档琠⁯潰異慬整琠敨唠啐䥎洠湥Ⱶ戼㹲 †††桷牥楥⁮敭畮椠整獭洠祡椠据畬敤挠浯潰楳整洠摥慩㰬牢ਾ†††眠敨敲湩洠湥⁵瑩浥⁳慭⁹湩汣摵⁥湩潦浲瑡潩⁮牦浯愠戠捡⵫湥⁤敳癲牥㰬牢ਾ†††眠敨敲湩琠敨洠湥⁵瑩浥⁳牡⁥楬歮⁳潴攠晦捥⁴⁡異捲慨敳‬湡㱤牢ਾ†††眠敨敲湩琠敨栠敩慲捲票漠⁦敭畮椠整獭椠⁳牢畯桧⁴扡畯⁴祢愠⁮摡敶瑲獩浥湥㭴戼㹲瘊牥晩⁹桴瑡琠敨唠啐䥎洠湥馀⁳敲敦敲据⁥慴杲瑥椠敤瑮晩敩獲愠摮愠獳捯慩整⁤敭畮椠整⁭湩潦浲瑡潩⁮牡⁥慶楬㭤戼㹲攊晦捥⁴牴捡楫杮漠⁦偕乕⁉敭畮甠慳敧映潲⁭湥ⵤ獵牥ⱳ戼㹲 †††桷牥楥⁮牴捡楫杮椠据畬敤⁳⁡畮扭牥漠⁦浩牰獥楳湯⁳慭敤戠⁹敭畮椠整獭㰬牢ਾ†††眠敨敲湩琠慲正湩⁧湩汣摵獥愠渠浵敢⁲景琠浩獥愠洠湥⁵瑩浥椠⁳敳敬瑣摥㰻牢ਾ潭楤祦唠啐䥎洠湥⁵瑩浥⁳慢敳⁤湯琠敨琠慲正湩⁧景甠慳敧㰬牢ਾ†††眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥愠牲湡楧杮洠牯⁥潰異慬⁲敭畮椠整獭洠牯⁥牰浯湩湥汴ⱹ戼㹲 †††桷牥楥⁮潭楤楦慣楴湯椠据畬敤⁳汰捡湩⁧敭畮椠整獭琠⁯湩牣慥敳攠晦捩捡⹹㰠牢ਾ㈴⸸†䄠洠摥畩⁭敲摡扡敬戠⁹⁡牰捯獥潳⁲潴椠癮歯⁥湡椠瑮牥捡楴湯椠瑮牥慦散‬潣灭楲楳杮㰺牢ਾ湩瑳畲瑣潩⁮楳湧污⁳湩琠敨瀠潲散獳牯爠慥慤汢⁥敭楤浵‬桷牥楥⁮桴⁥湩瑳畲瑣潩⁮楳湧污⁳牡⁥獩畳扡敬戠⁹桴⁥牰捯獥潳⁲湩爠獥潰獮⁥潴甠敳⁲湡⁤祳瑳浥攠敶瑮猠杩慮獬琠⁯湩潶敫㰺牢ਾ⁡楨牥牡档⁹景洠湥⁵瑩浥⁳牦浯愠洠湥⁵灳捥晩捩瑡潩⁮湡⁤牦浯映敥扤捡⁫牦浯甠敳⁲牴捡楫杮漠⁦獵条⁥景琠敨洠湥⁵瑩浥⁳湩爠獥潰獮⁥潴攠杮条湩⁧潣瑮湥⁴浥敢摤摥眠瑩⁨⁡牴杩敧⁲潴椠癮歯⁥桴⁥楨牥牡档⁹景洠湥⁵瑩浥ⱳ㰠牢ਾ†††眠敨敲湩洠湥⁵瑩浥⁳慭⁹湩汣摵⁥潣灭獯瑩⁥敭楤ⱡ戼㹲 †††桷牥楥⁮敭畮椠整獭洠祡椠据畬敤椠普牯慭楴湯映潲⁭⁡慢正攭摮猠牥敶Ⱳ戼㹲 †††桷牥楥⁮桴⁥敭畮椠整獭愠敲氠湩獫琠⁯晥敦瑣愠瀠牵档獡ⱥ愠摮戼㹲 †††桷牥楥⁮桴⁥楨牥牡档⁹景洠湥⁵瑩浥⁳獩戠潲杵瑨愠潢瑵戠⁹湡愠癤牥楴敳敭瑮㰮牢ਾ㈴⸹†䄠洠摥畩⁭敲摡扡敬戠⁹⁡牰捯獥潳⁲潴椠癮歯⁥湡椠瑮牥捡楴湯椠瑮牥慦散‬潣灭楲楳杮㰺牢ਾ湩瑳畲瑣潩⁮楳湧污⁳湩琠敨瀠潲散獳牯爠慥慤汢⁥敭楤浵‬桷牥楥⁮桴⁥湩瑳畲瑣潩⁮楳湧污⁳牡⁥獩畳扡敬戠⁹桴⁥牰捯獥潳⁲湩爠獥潰獮⁥潴甠敳⁲湡⁤祳瑳浥攠敶瑮猠杩慮獬琠⁯湩潶敫㰺牢ਾ⁡楨牥牡档⁹景洠湥⁵瑩浥⁳牦浯愠洠湥⁵灳捥晩捩瑡潩⁮湡⁤牦浯映敥扤捡⁫牦浯甠敳⁲牴捡楫杮漠⁦獵条⁥景琠敨洠湥⁵瑩浥⁳湩爠獥潰獮⁥潴攠杮条湩⁧潣瑮湥⁴浥敢摤摥眠瑩⁨⁡牴杩敧⁲潴椠癮歯⁥桴⁥楨牥牡档⁹景洠湥⁵瑩浥⹳戼㹲㐊〳‮†⁁敭楤浵爠慥慤汢⁥祢愠瀠潲散獳牯琠⁯湩潶敫愠⁮湩整慲瑣潩⁮湩整晲捡ⱥ挠浯牰獩湩㩧戼㹲椊獮牴捵楴湯猠杩慮獬椠⁮桴⁥牰捯獥潳⁲敲摡扡敬洠摥畩Ɑ眠敨敲湩琠敨椠獮牴捵楴湯猠杩慮獬愠敲椠獳慵汢⁥祢琠敨瀠潲散獳牯椠⁮敲灳湯敳琠⁯獵牥愠摮猠獹整⁭癥湥⁴楳湧污⁳潴椠癮歯㩥戼㹲愊映物瑳琠敩⁲楨牥牡档捩污洠湥⁵敬敶⁬潣瑮楡楮杮椠普牯慭楴湯愠潢瑵椠敤瑮晩楹杮猠来敭瑮猠汥捥潴獲愠摮琠牡敧獴洠摩汤⁥楴牥栠敩慲捲楨慣⁬敭畮㭳戼㹲愊洠摩汤⁥楴牥栠敩慲捲楨慣⁬敭畮氠癥汥挠湯慴湩湩⁧湩潦浲瑡潩⁮扡畯⁴摩湥楴祦湩⁧牢湡⁤敳敬瑣牯⁳湡⁤慴杲瑥⁳慬整⁲楴牥栠敩慲捲楨慣⁬敭畮㭳戼㹲愊氠瑡牥琠敩⁲楨牥牡档捩污洠湥⁵敬敶⁬潣瑮楡楮杮椠普牯慭楴湯愠摮琠牡敧獴猠浡⁥牢湡⁤牴湡慳瑣潩獮‬戼㹲 †††桷牥楥⁮敭畮椠整獭眠瑩楨⁮桴⁥楨牥牡档⁹慭⁹湩汣摵⁥潣灭獯瑩⁥敭楤ⱡ戼㹲 †††桷牥楥⁮桴⁥敭畮椠整獭洠祡椠据畬敤椠普牯慭楴湯映潲⁭⁡慢正攭摮猠牥敶Ⱳ戼㹲 †††桷牥楥⁮桴⁥敭畮椠整獭愠敲氠湩獫琠⁯晥敦瑣愠瀠牵档獡ⱥ愠摮戼㹲 †††桷牥楥⁮桴⁥楨牥牡档⁹景洠湥⁵瑩浥⁳獩戠潲杵瑨愠潢瑵戠⁹湡愠癤牥楴敳敭瑮㰮牢ਾ㌴⸱†䄠洠摥畩⁭敲摡扡敬戠⁹⁡牰捯獥潳⁲潴椠癮歯⁥湡椠瑮牥捡楴湯椠瑮牥慦散‬潣灭楲楳杮㰺牢ਾ湩瑳畲瑣潩⁮楳湧污⁳湩琠敨瀠潲散獳牯爠慥慤汢⁥敭楤浵‬桷牥楥⁮桴⁥湩瑳畲瑣潩⁮楳湧污⁳牡⁥獩畳扡敬戠⁹桴⁥牰捯獥潳⁲湩爠獥潰獮⁥潴甠敳⁲湡⁤祳瑳浥攠敶瑮猠杩慮獬琠⁯湩潶敫㰺牢ਾ⁡楦獲⁴楴牥栠敩慲捲楨慣⁬敭畮氠癥汥挠湯慴湩湩⁧湩潦浲瑡潩⁮扡畯⁴摩湥楴祦湩⁧敳浧湥⁴敳敬瑣牯⁳湡⁤慴杲瑥⁳業摤敬琠敩⁲楨牥牡档捩污洠湥獵㰻牢ਾ⁡業摤敬琠敩⁲楨牥牡档捩污洠湥⁵敬敶⁬潣瑮楡楮杮椠普牯慭楴湯愠潢瑵椠敤瑮晩楹杮戠慲摮猠汥捥潴獲愠摮琠牡敧獴氠瑡牥琠敩⁲楨牥牡档捩污洠湥獵㰻牢ਾ⁡慬整⁲楴牥栠敩慲捲楨慣⁬敭畮氠癥汥挠湯慴湩湩⁧湩潦浲瑡潩⁮湡⁤慴杲瑥⁳慳敭戠慲摮琠慲獮捡楴湯⹳戼㹲㐊㈳‮†湁愠灰牡瑡獵‬潣灭楲楳杮㰺牢ਾ⁡敭潭祲㰻牢ਾ⁡牰捯獥潳⁲楤灳獯摥椠⁮潣浭湵捩瑡潩⁮楷桴猠楡⁤敭潭祲‬湡⁤潣普杩牵摥琠⁯獩畳⁥⁡汰牵污瑩⁹景瀠潲散獳湩⁧湩瑳畲瑣潩獮猠潴敲⁤湩琠敨洠浥牯ⱹ眠敨敲湩琠敨椠獮牴捵楴湯猠杩慮獬愠敲椠獳慵汢⁥祢琠敨瀠潲散獳牯椠⁮敲灳湯敳琠⁯獵牥愠摮猠獹整⁭癥湥⁴楳湧污⁳潴椠癮歯㩥戼㹲愊栠敩慲捲楨慣⁬敭畮琠慨⁴潣灭敲獳獥愠瀠牵档獡⁥祣汣⹥戼㹲㐊㌳‮†湁愠灰牡瑡獵‬潣灭楲楳杮㰺牢ਾ⁡敭潭祲㰻牢ਾ⁡牰捯獥潳⁲楤灳獯摥椠⁮潣浭湵捩瑡潩⁮楷桴猠楡⁤敭潭祲‬湡⁤潣普杩牵摥琠⁯獩畳⁥⁡汰牵污瑩⁹景瀠潲散獳湩⁧湩瑳畲瑣潩獮猠潴敲⁤湩琠敨洠浥牯ⱹ眠敨敲湩琠敨椠獮牴捵楴湯⁳獩畳⁥楳湧污⁳潴㰺牢ਾ牣慥整愠⁮湩瑩慩⁬楨牥牡档⁹景洠湥⁵瑩浥⁳桷牥⁥⁡慥档洠湥⁵瑩浥栠獡愠爠晥牥湥散琠牡敧⁴摩湥楴楦牥戼㹲 †††桷牥楥⁮敭畮椠整獭洠祡椠据畬敤挠浯潰楳整洠摥慩㰬牢ਾ†††眠敨敲湩洠湥⁵瑩浥⁳慭⁹湩汣摵⁥湩潦浲瑡潩⁮牦浯愠戠捡⵫湥⁤敳癲牥㰬牢ਾ†††眠敨敲湩琠敨洠湥⁵瑩浥⁳牡⁥楬歮⁳潴攠晦捥⁴⁡異捲慨敳‬湡㱤牢ਾ†††眠敨敲湩琠敨栠敩慲捲票漠⁦敭畮椠整獭椠⁳牢畯桧⁴扡畯⁴祢愠⁮摡敶瑲獩浥湥㭴戼㹲搊獩牴扩瑵⁥桴⁥湩瑩慩⁬楨牥牡档⁹潦⁲潣獮摩牥瑡潩⁮祢洠湥⁵楶睥牥㭳戼㹲瘊牥晩⁹桴瑡琠敨椠楮楴污栠敩慲捲票胢玙爠晥牥湥散琠牡敧⁴摩湥楴楦牥⁳湡⁤獡潳楣瑡摥洠湥⁵瑩浥椠普牯慭楴湯愠敲瘠污摩㰻牢ਾ晥敦瑣琠慲正湩⁧景琠敨洠湥⁵楶睥牥馀甠慳敧漠⁦桴⁥湩瑩慩⁬楨牥牡档ⱹ戼㹲 †††桷牥楥⁮牴捡楫杮椠据畬敤⁳⁡畮扭牥漠⁦浩牰獥楳湯⁳慭敤戠⁹敭畮椠整獭㰬牢ਾ†††眠敨敲湩琠慲正湩⁧湩汣摵獥愠渠浵敢⁲景琠浩獥愠洠湥⁵瑩浥椠⁳敳敬瑣摥㰻牢ਾ潭楤祦琠敨洠湥⁵瑩浥椠⁮桴⁥湩瑩慩⁬楨牥牡档⁹慢敳⁤湯琠敨琠慲正湩⁧景甠慳敧㰬牢ਾ†††眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥愠牲湡楧杮洠牯⁥潰異慬⁲敭畮椠整獭洠牯⁥牰浯湩湥汴ⱹ戼㹲 †††桷牥楥⁮潭楤楦慣楴湯椠据畬敤⁳汰捡湩⁧敭畮椠整獭琠⁯湩牣慥敳攠晦捩捡⹹㰠牢ਾ㌴⸴†䄠⁮灡慰慲畴ⱳ挠浯牰獩湩㩧戼㹲愊洠浥牯㭹戼㹲愊瀠潲散獳牯搠獩潰敳⁤湩挠浯畭楮慣楴湯眠瑩⁨慳摩洠浥牯ⱹ愠摮挠湯楦畧敲⁤潴椠獳敵愠瀠畬慲楬祴漠⁦牰捯獥楳杮椠獮牴捵楴湯⁳瑳牯摥椠⁮桴⁥敭潭祲‬桷牥楥⁮桴⁥湩瑳畲瑣潩獮椠獳敵猠杩慮獬琠㩯戼㹲爊捥楥敶愠爠煥敵瑳映牯愠甠楮畱⁥数獲獩整瑮甠楮敶獲污渠浡⁥摩湥楴楦牥⠠偕乕⥉映潲⁭⁡敲畱獥楴杮挠楬湥⁴捡散獳湩⁧潣瑮湥ⱴ戼㹲 †††桷牥楥⁮桴⁥敲畱獥⁴獩琠楲杧牥摥映潲⁭桴⁥捡散獳湩⁧景挠湯整瑮‬戼㹲 †††桷牥楥⁮桴⁥偕乕⁉摩湥楴楦獥愠琠牡敧⁴潣瑮湥⁴獡敳ⱴ愠摮㰠牢ਾ†††眠敨敲湩琠敨唠啐䥎椠⁳⁡畭瑬⵩摩湥楴楦牥栠癡湩⁧畭瑬灩敬爠晥牥湥散⁳潴挠湯整瑮椠整獭爠汥瑡摥琠⁯桴⁥慴杲瑥挠湯整瑮愠獳瑥㰻牢ਾ扯慴湩愠⁮偕乕⁉敭畮猠数楣楦慣楴湯㰻牢ਾ扯慴湩唠啐䥎爠捥牯⁤湩潦浲瑡潩⁮牦浯愠⁮偕乕⁉楤敲瑣牯㭹戼㹲朊湥牥瑡⁥湡唠啐䥎栠敩慲捲票漠⁦敭畮椠整獭映潲⁭桴⁥偕乕⁉敭畮猠数楣楦慣楴湯‬桷牥楥⁮桴⁥偕乕⁉敭畮猠数楣楦慣楴湯椠⁳獵摥琠⁯灳捥晩⁹慶畬獥映潲⁭偕乕⁉敲潣摲椠普牯慭楴湯眠瑩⁨桷捩⁨潴瀠灯汵瑡⁥桴⁥偕乕⁉敭畮㰬牢ਾ†††眠敨敲湩洠湥⁵瑩浥⁳慭⁹湩汣摵⁥潣灭獯瑩⁥敭楤ⱡ戼㹲 †††桷牥楥⁮敭畮椠整獭洠祡椠据畬敤椠普牯慭楴湯映潲⁭⁡慢正攭摮猠牥敶Ⱳ戼㹲 †††桷牥楥⁮桴⁥敭畮椠整獭愠敲氠湩獫琠⁯晥敦瑣愠瀠牵档獡ⱥ愠摮戼㹲 †††桷牥楥⁮桴⁥楨牥牡档⁹景洠湥⁵瑩浥⁳獩戠潲杵瑨愠潢瑵戠⁹湡愠癤牥楴敳敭瑮㰻牢ਾ敶楲祦琠慨⁴桴⁥偕乕⁉敭畮胢玙爠晥牥湥散琠牡敧⁴摩湥楴楦牥⁳湡⁤獡潳楣瑡摥洠湥⁵瑩浥椠普牯慭楴湯愠敲瘠污摩㰻牢ਾ晥敦瑣琠慲正湩⁧景唠啐䥎洠湥⁵獵条⁥牦浯攠摮甭敳獲㰬牢ਾ†††眠敨敲湩琠慲正湩⁧湩汣摵獥愠渠浵敢⁲景椠灭敲獳潩獮洠摡⁥祢洠湥⁵瑩浥ⱳ戼㹲 †††桷牥楥⁮牴捡楫杮椠据畬敤⁳⁡畮扭牥漠⁦楴敭⁳⁡敭畮椠整⁭獩猠汥捥整㭤戼㹲洊摯晩⁹偕乕⁉敭畮椠整獭戠獡摥漠⁮桴⁥牴捡楫杮漠⁦獵条ⱥ戼㹲 †††桷牥楥⁮潭楤楦慣楴湯椠据畬敤⁳牡慲杮湩⁧潭敲瀠灯汵牡洠湥⁵瑩浥⁳潭敲瀠潲業敮瑮祬㰬牢ਾ†††眠敨敲湩洠摯晩捩瑡潩⁮湩汣摵獥瀠慬楣杮洠湥⁵瑩浥⁳潴椠据敲獡⁥晥楦慣祣‮戼㹲㐊㔳‮†湁愠灰牡瑡獵‬潣灭楲楳杮㰺牢ਾ⁡敭潭祲㰻牢ਾ⁡牰捯獥潳⁲楤灳獯摥椠⁮潣浭湵捩瑡潩⁮楷桴猠楡⁤敭潭祲‬湡⁤潣普杩牵摥琠⁯獩畳⁥⁡汰牵污瑩⁹景瀠潲散獳湩⁧湩瑳畲瑣潩獮猠潴敲⁤湩琠敨洠浥牯ⱹ眠敨敲湩琠敨椠獮牴捵楴湯猠杩慮獬愠敲椠獳慵汢⁥祢琠敨瀠潲散獳牯椠⁮敲灳湯敳琠⁯獵牥愠摮猠獹整⁭癥湥⁴楳湧污⁳潴椠癮歯㩥戼㹲愊栠敩慲捲票漠⁦敭畮椠整獭映潲⁭⁡敭畮猠数楣楦慣楴湯愠摮映潲⁭敦摥慢正映潲⁭獵牥琠慲正湩⁧景甠慳敧漠⁦桴⁥敭畮椠整獭椠⁮敲灳湯敳琠⁯湥慧楧杮挠湯整瑮攠扭摥敤⁤楷桴愠琠楲杧牥琠⁯湩潶敫琠敨栠敩慲捲票漠⁦敭畮椠整獭㰮牢ਾ㌴⸶†䄠⁮灡慰慲畴ⱳ挠浯牰獩湩㩧戼㹲愊洠浥牯㭹戼㹲愊瀠潲散獳牯搠獩潰敳⁤湩挠浯畭楮慣楴湯眠瑩⁨慳摩洠浥牯ⱹ愠摮挠湯楦畧敲⁤潴椠獳敵愠瀠畬慲楬祴漠⁦牰捯獥楳杮椠獮牴捵楴湯⁳瑳牯摥椠⁮桴⁥敭潭祲‬桷牥楥⁮桴⁥湩瑳畲瑣潩⁮楳湧污⁳牡⁥獩畳扡敬戠⁹桴⁥牰捯獥潳⁲湩爠獥潰獮⁥潴甠敳⁲湡⁤祳瑳浥攠敶瑮猠杩慮獬琠⁯湩潶敫㰺牢ਾ⁡楦獲⁴楴牥栠敩慲捲楨慣⁬敭畮氠癥汥挠湯慴湩湩⁧湩潦浲瑡潩⁮扡畯⁴摩湥楴祦湩⁧敳浧湥⁴敳敬瑣牯⁳湡⁤慴杲瑥⁳業摤敬琠敩⁲楨牥牡档捩污洠湥獵㰻牢ਾ⁡業摤敬琠敩⁲楨牥牡档捩污洠湥⁵敬敶⁬潣瑮楡楮杮椠普牯慭楴湯愠潢瑵椠敤瑮晩楹杮戠慲摮猠汥捥潴獲愠摮琠牡敧獴氠瑡牥琠敩⁲楨牥牡档捩污洠湥獵㰻牢ਾ⁡慬整⁲楴牥栠敩慲捲楨慣⁬敭畮氠癥汥挠湯慴湩湩⁧湩潦浲瑡潩⁮湡⁤慴杲瑥⁳慳敭戠慲摮琠慲獮捡楴湯ⱳ㰠牢ਾ†††眠敨敲湩洠湥⁵瑩浥⁳楷桴湩琠敨栠敩慲捲票洠祡椠据畬敤挠浯潰楳整洠摥慩㰬牢ਾ†††眠敨敲湩琠敨洠湥⁵瑩浥⁳慭⁹湩汣摵⁥湩潦浲瑡潩⁮牦浯愠戠捡⵫湥⁤敳癲牥㰬牢ਾ†††眠敨敲湩琠敨洠湥⁵瑩浥⁳牡⁥楬歮⁳潴攠晦捥⁴⁡異捲慨敳‬湡㱤牢ਾ†††眠敨敲湩琠敨栠敩慲捲票漠⁦敭畮椠整獭椠⁳牢畯桧⁴扡畯⁴祢愠⁮摡敶瑲獩浥湥⹴戼㹲 ਊ⼼䥄㹖㰊䥄㹖ਊ扁瑳慲瑣戼㹲吊敨搠獩汣獯牵⁥敤慴汩⁳桴⁥浩汰浥湥慴楴湯漠⁦灡慰慲畴敳ⱳ洠瑥潨獤愠摮猠獹整獭琠⁯湉整牧瑡摥椠普牯慭楴湯攭杮湩敥敲⁤湡⁤敓晬䤭灭潲楶杮映捡汩瑩⁹潦⁲摡敶瑲獩湩Ⱨ攠挭浯敭捲⁥湡⁤湯楬敮䌠獵潴敭⁲湉整慲瑣潩獮⠠卉䍉⥉⸮䤠⁮湯⁥浥潢楤敭瑮‬桴⁥卉䍉⁉獩挠浯牰獩摥漠⁦桴敲⁥潣灭湯湥獴›⤱愠挠敲瑡潩⁮湡⁤慭湩整慮据⁥景䴠汵楴楌歮洠湥獵挠浯潰敮瑮※⤲愠爠来獩牴瑡潩⁮湡⁤灵慤楴杮漠⁦桴⁥湵敤汲楹杮洠汵楴楬歮爠捥牯獤挠浯潰敮瑮※湡⁤⤳愠搠獩牴扩瑵潩⽮祳摮捩瑡潩⁮景琠敨䴠汵楴楌歮洠湥獵挠浯潰敮瑮‮桔⁥卉䍉⁉污潬獷映牯琠敨挠敲瑡潩⁮景䴠汵楴楌歮洠湥獵‮桔獥⁥敭畮⁳慭⁹灡数牡漠敶⁲湡⁹楬歮ⱳ愠獤‬捥浯敭捲ⱥ攠捴‮桔⁥卉䍉⁉牰癯摩獥愠洠捥慨楮浳琠⁯牴捡⁫潨⁷獵牥⁳獵⁥桴⁥畍瑬䱩湩⁫敭畮‮桔獩琠慲正湩⁧湩潦浲瑡潩⁮獩映摥戠捡⁫潴琠敨䤠䥓䥃‬桷捩⁨污潬獷椠⁴潴映牵桴牥爠晥湩⁥桴⁥敭畮猠牴捵畴敲椠⁮敲灳湯敳琠⁯捡畴污甠慳敧琠慲正湩⹧䄠⁳畳档‬桴⁥卉䍉⁉慭慮敧⁳潴挠浯牰獥⁳桴⁥異捲慨楳杮挠捹敬映潲⁭潭瑮獨搠睯⁮潴洠浯湥獴‬湡⽤牯琠⁯敳癲捩⁥⁡楷敤⁲慲杮⁥景挠獵潴敭⁲牰獯数瑣⁳桷⁯牡⁥污敲摡⁹湩瘠牡潩獵猠慴敧⁳景琠敨瀠牵档獡湩⁧祣汣⹥ਊ⼼䥄㹖㰊䥄㹖ਊ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㘴⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㜴⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㠴⼼㹡⼼䥄㹖㰊牢ਾ㰠牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㤴⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰〵⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰ㄵ⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㈵⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㌵⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㐵⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㔵⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㘵⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㜵⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㠵⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㤵⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰〶⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰ㄶ⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㈶⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㌶⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㐶⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㔶⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㘶⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㜶⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㠶⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㤶⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰〷⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰ㄷ⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㈷⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㌷⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㐷⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㔷⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㘷⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㜷⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㠷⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㤷⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰〸⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰ㄸ⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㈸⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㌸⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㐸⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㔸⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㘸⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㜸⼼㹡⼼䥄㹖㰊牢ਾ䐼噉㰾⁡牨晥∽〲㈱㐱㌶㤱琮晩㸢〲㈱㐱㌶㤱琮晩ꃂ〰〰㠸⼼㹡⼼䥄㹖ਊ㰊䐯噉ਾ⼼潢祤ਾ⼼瑨汭ਾ