(57)【要約】ネットワークベースまたはインターネットベースのソフトウェア配布のための方法とシステムを説明する。一実施形態では、アプリケーションプログラムまたはソフトウェアプラットフォームはクライアント上に置かれる。このプログラムまたはプラットフォームは、インターネットなどのネットワーク経由で配布可能なソフトウェア拡張機能に基づき拡張できるように構成されている。第三者開発者は、プログラムまたはプラットフォームに組み込むさまざまな拡張機能を開発することができる。前記実施形態では、ソフトウェア拡張機能を備える拡張機能ファイルは、インターネットサーバ上でホスティングされる。また、追加ファイルもインターネットサーバ上でホスティングされ、ソフトウェア拡張機能の態様を記述する。追加ファイルには、プログラムまたはプラットフォームの拡張機能の論理的付加を記述するファイルと、拡張機能ファイルの記憶場所を記述するファイルが含まれる。拡張機能にアクセスするために使用できる特定のインターネットサイトにナビゲートすることにより、拡張機能がクライアント上に組み込まれる。拡張機能ファイルを記述するファイルがクライアント上にダウンロードされる。これらのファイルは、特定の拡張機能をプラグインとして組み込む場所、さらに適切な拡張機能ファイルが置かれている場所、そのダウンロード方法を記述しており、クライアントはこれを利用する。拡張機能ファイルがダウンロードされ、プログラムまたはプラットフォームに組み込まれる。【特許請求の範囲】
【請求項１】
ネットワークを介してソフトウェアを配布する方法であって、
記述を使用して１つまたは複数のソフトウェア拡張機能を記述するステップであって、前記拡張機能はクライアント上で実行されるソフトウェアプラットフォームに組み込まれるように構成されるステップと、
前記１つまたは複数の拡張機能の前記記述を前記ネットワークを介して前記クライアントに配布するステップであって、前記ネットワークを介して前記ソフトウェア拡張機能のダウンロードに使用するように前記記述が構成されるステップとを備えることを特徴とする方法。
【請求項２】
前記ネットワークはインターネットを備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記記述はタグベースの階層型言語を備えることを特徴とする請求項１に記載の方法。
【請求項４】
前記記述はＸＭＬ記述を備えることを特徴とする請求項１に記載の方法。
【請求項５】
前記ネットワークはインターネットを備え、前記記述はＸＭＬ記述を備えることを特徴とする請求項１に記載の方法。
【請求項６】
前記ソフトウェア拡張機能は前記ソフトウェアプラットフォームの動作をコンテキストに基づいて変更するように構成され、前記コンテキストに基づく変更をユーザのコンピューティングコンテキストと関連付けることを特徴とする請求項１に記載の方法。
【請求項７】
前記ソフトウェアプラットフォームは複数の異なるタスクをユーザが実施できるようにする複数の異なる機能を有する単一のアプリケーションプログラムを提供するように構成されることを特徴とする請求項１に記載の方法。
【請求項８】
前記ソフトウェア拡張機能は、特定の機能と関連するタスクをユーザが遂行する方法を変更する前記複数の異なる機能のうちの１つまたは複数の機能の動作をコンテキストに基づいて変更するように構成されることを特徴とする請求項７に記載の方法。
【請求項９】
前記ソフトウェア拡張機能はユーザインターフェース要素を備えることを特徴とする請求項１に記載の方法。
【請求項１０】
前記ソフトウェア拡張機能はビヘイビア、コンポーネント、またはオブジェクトを備えることを特徴とする請求項１に記載の方法。
【請求項１１】
前記ソフトウェア拡張機能はストア要素を備えることを特徴とする請求項１に記載の方法。
【請求項１２】
前記ソフトウェア拡張機能はユーザ定義要素を備えることを特徴とする請求項１に記載の方法。
【請求項１３】
前記ソフトウェア拡張機能は
ユーザインターフェース要素、
ビヘイビア、コンポーネント、またはオブジェクト、
ストア要素、および
ユーザ定義要素のうちの１つまたは複数を備えることを特徴とする請求項１に記載の方法。
【請求項１４】
少なくとも１つの拡張機能が新しい拡張ポイントを追加する能力を備えることを特徴とする請求項１に記載の方法。
【請求項１５】
前記１つまたは複数のソフトウェア拡張機能を記述するステップは前記ソフトウェアプラットフォームへの論理的付加を記述するＸＭＬファイルを備える拡張機能記述ファイル（ＥＤＦ）を使用して前記拡張機能を記述するステップを備えることを特徴とする請求項１に記載の方法。
【請求項１６】
前記記述の１つまたは複数は拡張機能の機能性の全部または一部を実施するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１７】
コンピュータ読取り可能命令を格納する１つまたは複数のコンピュータ読取り可能媒体であって、前記コンピュータシステムが命令を実行したときに、
拡張可能マークアップ言語（ＸＭＬ）を使用して１つまたは複数のソフトウェア拡張機能を記述することであって、単一のアプリケーションプログラムを備えるソフトウェアプラットフォームに組み込まれるように前記拡張機能を構成し、前記単一のアプリケーションプログラムはユーザが複数の異なるタスクを遂行できるようにする異なる複数の機能を有することと、
前記１つまたは複数の拡張機能のＸＭＬ記述を前記インターネットを介して前記クライアントに配布することであって、前記インターネットを介して前記ソフトウェア拡張機能のダウンロードに使用するように前記記述が構成されることとを実施することを特徴とする媒体。
【請求項１８】
ネットワークを介してソフトウェアを配布する方法であって、
１つまたは複数の記述ファイルを使用して１つまたは複数のソフトウェア拡張機能を記述するステップであって、前記拡張機能がクライアント上で実行されるソフトウェアプログラムに組み込まれるように構成されるステップと、
前記１つまたは複数の記述ファイルをプログラム機能を提供するために使用可能な１つまたは複数の関連する拡張機能ファイルと関連付けるステップと、
前記記述ファイルと関連する拡張機能ファイルをネットワークアクセス可能な記憶場所に格納するステップと、
前記記述ファイルおよび前記１つまたは複数の拡張機能の関連する拡張機能ファイルをネットワークを介して前記クライアントに配布するステップとを備えることを特徴とする方法。
【請求項１９】
前記記述するステップは、前記ソフトウェアプログラムへの論理的付加の記述、およびソフトウェア拡張機能で使用される１つまたは複数の物理ファイルおよび／またはリソースの記述を含む、少なくとも１つのＸＭＬファイルで個々のソフトウェア拡張機能を記述するステップを備えることを特徴とする請求項１８に記載の方法。
【請求項２０】
前記ソフトウェア拡張機能は前記ソフトウェアアプリケーションの動作をコンテキストに基づいて変更するように構成され、前記状況に基づく変更をユーザのコンピューティングコンテキストと関連付けることを特徴とする請求項１８に記載の方法。
【請求項２１】
前記ソフトウェアプログラムは複数の異なるタスクをユーザが遂行できるようにする異なる複数の機能を備え、前記１つまたは複数のソフトウェア拡張機能は特定の機能と関連するタスクをユーザが遂行する方法を変更する前記異なる機能のうちの１つまたは複数の機能の動作をコンテキストに基づいて変更するように構成されることを特徴とする請求項１８に記載の方法。
【請求項２２】
前記ソフトウェアプログラムは、ユーザがナビゲートにより異なる機能を選べる単一のナビゲーション可能ウィンドウを備えることを特徴とする請求項２１に記載の方法。
【請求項２３】
前記１つまたは複数のソフトウェア拡張機能はユーザインターフェース要素を備えることを特徴とする請求項１８に記載の方法。
【請求項２４】
前記１つまたは複数のソフトウェア拡張機能はビヘイビア、コンポーネント、またはオブジェクトを備えることを特徴とする請求項１８に記載の方法。
【請求項２５】
前記１つまたは複数のソフトウェア拡張機能はストア要素を備えることを特徴とする請求項１８に記載の方法。
【請求項２６】
前記１つまたは複数のソフトウェア拡張機能はユーザ定義要素を備えることを特徴とする請求項１８に記載の方法。
【請求項２７】
前記１つまたは複数のソフトウェア拡張機能は
ユーザインターフェース要素、
ビヘイビア、コンポーネント、またはオブジェクト、
ストア要素、および
ユーザ定義要素のうちの１つまたは複数を備えることを特徴とする請求項１８に記載の方法。
【請求項２８】
コンピュータ読取り可能命令を格納する１つまたは複数のコンピュータ読取り可能媒体であって、コンピュータが前記命令を実行したときに、前記命令が請求項１８に記載の方法を実行することを特徴とするコンピュータ読取り可能媒体。
【請求項２９】
ネットワークを介してソフトウェアを配布する方法であって、
ソフトウェアアプリケーションプログラムへの論理的付加を記述する１つまたは複数の拡張機能定義ファイル（ＥＤＦ）を格納するステップと、
前記１つまたは複数のＥＤＦに対応し、前記ソフトウェアアプリケーションプログラムを拡張する１つまたは複数の拡張機能ファイルを格納するステップと、
ネットワークを介して少なくとも１つのＥＤＦをクライアントに配布するステップと、
ネットワークを介して前記少なくとも１つのＥＤＦに対応する少なくとも１つの拡張機能ファイルをクライアントに配布するステップとを備えることを特徴とする方法。
【請求項３０】
前記ＥＤＦは階層型言語で定義されることを特徴とする請求項２９に記載の方法。
【請求項３１】
前記ネットワークはインターネットを備えることを特徴とする請求項２９に記載の方法。
【請求項３２】
インターネットサーバで前記ファイルをホスティングすることにより前記格納動作を実施することを特徴とする請求項２９に記載の方法。
【請求項３３】
前記ＥＤＦはＸＭＬファイルを備えることを特徴とする請求項２９に記載の方法。
【請求項３４】
前記ＸＭＬファイルは前記アプリケーションプログラムに追加される機能タイプと関連付けられている定義済みタグを備えることを特徴とする請求項３３に記載の方法。
【請求項３５】
前記定義済みタグの１つまたは複数はユーザインターフェース要素に対応することを特徴とする請求項３４に記載の方法。
【請求項３６】
前記定義済みタグの１つまたは複数はビヘイビア、コンポーネント、またはオブジェクトであるサービスに対応することを特徴とする請求項３４に記載の方法。
【請求項３７】
前記定義済みタグの１つまたは複数はストア要素に対応することを特徴とする請求項３４に記載の方法。
【請求項３８】
前記ＸＭＬファイルは前記アプリケーションプログラムに追加されるユーザ定義機能と関連付けられているユーザ定義タグを備えることを特徴とする請求項３４に記載の方法。
【請求項３９】
コンピュータ読取り可能命令を格納する１つまたは複数のコンピュータ読取り可能媒体であって、コンピュータが前記命令を実行したときに、前記命令が請求項２９に記載の方法を実施することを特徴とするコンピュータ読取り可能媒体。
【請求項４０】
コンピュータ読取り可能媒体上に実現されたデータ構造であって、
ソフトウェアアプリケーションプログラムに組み込まれるソフトウェア拡張機能を示す第１の下位構造と、
前記第１の下位構造と関連付けられ、前記アプリケーションプログラムへの拡張機能により追加できる機能タイプを示す１つまたは複数の第２の下位構造と、
前記１つまたは複数の第２の下位構造と関連付けられ、前記拡張機能により追加できる関連する機能タイプの機能を示す１つまたは複数の第３の下位構造とを備えることを特徴とするデータ構造。
【請求項４１】
前記１つまたは複数の第２の下位構造は前記第１の下位構造の子であることを特徴とする請求項４０に記載のデータ構造。
【請求項４２】
前記１つまたは複数の第３の下位構造は前記１つまたは複数の第２の下位構造の子であることを特徴とする請求項４０に記載のデータ構造。
【請求項４３】
前記１つまたは複数の第２の下位構造は前記第１の下位構造の子であり、前記１つまたは複数の第３の下位構造は前記１つまたは複数の第２の下位構造の子であることを特徴とする請求項４０に記載のデータ構造。
【請求項４４】
前記下位構造はＸＭＬタグを備えることを特徴とする請求項４０に記載のデータ構造。
【請求項４５】
前記機能タイプは、
ユーザインターフェース要素、
ビヘイビア、コンポーネント、またはオブジェクト、
ストア要素、および
ユーザ定義要素の機能タイプうちの１つまたは複数を備えることを特徴とする請求項４０に記載のデータ構造。
【請求項４６】
前記データ構造は拡張できるオープンＸＭＬスキーマを備えることを特徴とする請求項４０に記載のデータ構造。
【請求項４７】
前記データ構造は、第三者が拡張できるオープンＸＭＬスキーマを備えることを特徴とする請求項４０に記載のデータ構造。
【請求項４８】
ネットワークを介してソフトウェアを配布する方法であって、
少なくとも１つのソフトウェアアプリケーションプログラムを保持しているネットワークサイトにナビゲートするステップと、
前記ネットワークサイトからソフトウェアアプリケーションプログラムをダウンロードするステップであって、前記アプリケーションプログラムは異なるタスクを実施するユーザを補助することができる複数の異なる機能を備え、前記ソフトウェアアプリケーションプログラムはネットワークを介して配布可能で、少なくとも１つのネットワーク配布可能ファイルにより記述されるソフトウェア拡張機能で拡張されるように構成されるステップとを備えることを特徴とする方法。
【請求項４９】
前記アプリケーションプログラムは、複数の異なる機能の間でユーザがナビゲート可能な機能を選べる単一のナビゲーション可能ウィンドウを備えることを特徴とする請求項４８に記載の方法。
【請求項５０】
前記アプリケーションプログラムに少なくとも１つの拡張機能を追加することにより前記ソフトウェアアプリケーションプログラムを拡張するステップをさらに備えることを特徴とする請求項４８に記載の方法。
【請求項５１】
前記拡張するステップは、
前記拡張機能を記述する１つまたは複数のＸＭＬファイルおよび前記拡張機能を実施するために使用される拡張機能ファイルのホストとして機能する異なるネットワークサイトにナビゲートするリンクを使用するステップと、
前記１つまたは複数のＸＭＬファイルおよび拡張機能ファイルをクライアントにダウンロードするステップとを備えることを特徴とする請求項５０に記載の方法。
【請求項５２】
前記ＸＭＬファイルのうちの１つは拡張機能を論理的に記述するファイルを備え、前記ＸＭＬファイルのうちの１つは前記拡張機能ファイルを記述するファイルを備えることを特徴とする請求項５１に記載の方法。
【請求項５３】
前記リンクはユーザプリファレンスに格納されることを特徴とする請求項５１に記載の方法。
【請求項５４】
コンピュータ読取り可能命令を格納する１つまたは複数のコンピュータ読取り可能媒体であって、コンピュータが前記命令を実行したときに、前記コンピュータが
少なくとも１つのソフトウェアアプリケーションプログラムを保持しているネットワークサイトにナビゲートすることと、
異なるタスクを実施するユーザを補助することができる複数の異なる機能を備えるソフトウェアアプリケーションプログラムをダウンロードすることであって、前記ソフトウェアアプリケーションプログラムはネットワークを介して配布可能で、少なくとも１つのネットワーク配布可能ファイルにより記述されるソフトウェア拡張機能で拡張されるように構成されることと、
少なくとも１つの拡張機能を前記アプリケーションプログラムに追加することにより前記ソフトウェアアプリケーションプログラムを拡張することであって、前記拡張機能は前記拡張機能を記述する１つまたは複数のファイルおよび前記拡張機能を実施するために使用される拡張機能ファイルのホストとなる異なるネットワークサイトにナビゲートするリンクを使用して追加され、前記１つまたは複数のファイルおよび前記拡張機能ファイルをクライアントにダウンロードすることとを実施することを特徴とする媒体。
【請求項５５】
ネットワークを介してソフトウェアを配布する方法であって、
Ｗｅｂサイトにアクセスして１つまたは複数のソフトウェア拡張機能を取得するステップと、
ソフトウェアアプリケーションプログラムへの前記ソフトウェア拡張機能の論理的付加を記述する階層型言語を使用して少なくとも１つのソフトウェア拡張機能を記述する少なくとも１つのファイルを受け取るステップと、
１つまたは複数のソフトウェア拡張機能ファイルを受け取るステップと、
少なくとも一部は、前記少なくとも１つのファイルに含まれている前記記述に基づき前記１つまたは複数のソフトウェア拡張機能ファイルをインストールするステップとを備えることを特徴とする方法。
【請求項５６】
前記ソフトウェア拡張機能の論理的付加を記述する前記階層型言語はタグベースの言語を備えることを特徴とする請求項５５に記載の方法。
【請求項５７】
前記ソフトウェア拡張機能の論理的付加を記述する前記階層型言語は拡張可能マークアップ言語（ＸＭＬ）を備えることを特徴とする請求項５５に記載の方法。
【請求項５８】
前記インストールするステップがクライアントレジストリまたは前記クライアントマシン上に永続的に存在するレジストリキーを操作することなくインストールを行うステップを備えることを特徴とする請求項５５に記載の方法。
【請求項５９】
ソフトウェア拡張機能の更新が利用できるかどうかを判別し、もし利用できれば、更新拡張機能ファイルを受け取るステップをさらに備えることを特徴とする請求項５５に記載の方法。
【請求項６０】
前記判別するステップは拡張機能カタログをポーリングするステップを備えることを特徴とする請求項５９に記載の方法。
【請求項６１】
前記判別するステップはＸＭＬファイルを備える拡張機能カタログをポーリングするステップを備えることを特徴とする請求項５９に記載の方法。
【請求項６２】
コンピュータ読取り可能命令を格納する１つまたは複数のコンピュータ読取り可能媒体であって、コンピュータが前記命令を実行したときに、前記コンピュータが請求項５５に記載の方法を実施することを特徴とする媒体。
【請求項６３】
ネットワークを介する配布でソフトウェアを提供する方法であって、
１つまたは複数の拡張可能マークアップ言語（ＸＭＬ）ファイルを使用して１つまたは複数のソフトウェア拡張機能を記述するステップであって、前記拡張機能はクライアント上で実行されるソフトウェアプログラムに組み込まれるように構成されるステップと、
前記１つまたは複数のＸＭＬファイルをプログラム機能を提供するために使用可能な１つまたは複数の関連する拡張機能ファイルと関連付けるステップと、
前記ＸＭＬファイルと関連する拡張機能ファイルをネットワークアクセス可能な保存先に格納するステップとを備えることを特徴とする方法。
【請求項６４】
ネットワークサイトであって、クライアントが該ネットワークサイトを介して
ソフトウェアアプリケーションプログラムに組み込まれるように構成され、ネットワークを介して配布される１つまたは複数のソフトウェア拡張機能ファイルと、
前記１つまたは複数のソフトウェア拡張機能ファイルと関連付けられ、前記拡張機能ファイルを記述する１つまたは複数のファイルであって、前記ソフトウェアアプリケーションプログラムへの前記１つまたは複数のソフトウェア拡張機能ファイルの論理的付加を記述する１つまたは複数のファイルとを備えるソフトウェアファイルにアクセスすることができるネットワークサイト。
【請求項６５】
前記階層型言語は拡張可能マークアップ言語（ＸＭＬ）を備えることを特徴とする請求項６４に記載のネットワークサイト。
【請求項６６】
ネットワークベースのソフトウェア拡張機能を管理する方法であって、
ネットワークアクセス可能な記憶場所にあるカタログに複数のソフトウェア拡張機能記述をグループとしてまとめるステップと、
前記ネットワークアクセス可能な記憶場所にアクセスするステップと、
前記カタログを使用してコンピューティングデバイス上に常駐するソフトウェア拡張機能を更新するステップとを備えることを特徴とする方法。
【請求項６７】
前記カタログに問合せを行って拡張機能の記述を確認するステップをさらに備えることを特徴とする請求項６６に記載の方法。
【請求項６８】
ユーザの個人設定に基づき前記カタログに問合せを行うステップをさらに備えることを特徴とする請求項６６に記載の方法。
【請求項６９】
前記拡張機能記述はＸＭＬで定義されることを特徴とする請求項６６に記載の方法。
【発明の詳細な説明】
【０００１】
（技術分野）
本発明は、ネットワークを介してソフトウェアを提供するための方法とシステムに関する。より具体的に述べると、本発明は、インターネットベースのソフトウェア配布に関する。
【０００２】
（発明の背景）
従来のＰＣアプリケーションをインストールするには、ソフトウェアをユーザのコンピュータにロードをするためディスクやＣＤ−ＲＯＭなどの物理的媒体が必要であり、これをコンピュータに実際に挿入しなければならない。通常、このプロセスではユーザが設定情報を入力する必要があり、ユーザにとっては分かりにくい作業となっている。ソフトウェアのインストールが済むと、その場所と機能に関して固定されるのがふつうである。ソフトウェアを更新する場合、ユーザは通常、物理的媒体を追加購入し、インストールプロセスを繰り返さないと、更新されたソフトウェアを使用することはできない。このモデルでは、ソフトウェアはインストールされたコンピュータとの関連で固定されている。ユーザが別のコンピュータに移った場合、インストールプロセスを繰り返さなければそのマシンで特定のソフトウェアを使用できなくなる。
【０００３】
コンピューティングがインターネットなどのコンピュータネットワークの環境へと発展するにつれ、上述の従来のソフトウェア配布モデルは柔軟性、適応性のある動的なソフトウェアオンデマンドを望む消費者のニーズに応えるには不適切であることが明白となってきた。ネットワークベースのソフトウェア配布は、ソフトウェアの開発および配布を行う人々の高い関心を誘う対象となっている。ネットワークベースのソフトウェア配布の潜在的能力を解き放つには、特に帯域幅が制限されるような状況において、洗練された革新的で合理化されたソリューションが必要である。
【０００４】
そこで、本発明は、特に、ネットワークベースのソフトウェア配布、たとえばインターネット経由の配布に最も適した新しいソフトウェア配布モデルを提供することに関連する関心から生まれた。
【０００５】
（発明の要約）
ネットワークベースのソフトウェア配布のための方法とシステムを説明する。一実施形態では、アプリケーションプログラムまたはソフトウェアプラットフォームはクライアント上に置かれる。このプログラムまたはプラットフォームは、インターネットなどのネットワーク経由で配布可能なソフトウェア拡張機能に基づき拡張できるように構成されている。サードパーティーの開発者は、プログラムまたはプラットフォームに組み込むさまざまな拡張機能を開発することができる。
【０００６】
説明している一実施形態では、ソフトウェア拡張機能を含む拡張機能ファイルは、インターネットサーバなどのネットワークサーバ上でホスティングされる。これらの拡張機能ファイルに、ソフトウェア拡張機能の態様を記述するディスクリプタファイルがある。このディスクリプタファイルは、プログラムまたはプラットフォームの拡張機能を論理的に記述し、他の拡張機能ファイルの記憶場所を指定する。拡張機能にアクセスするために使用できる特定のネットワークまたはインターネットサイトにナビゲートすることにより、拡張機能がクライアント上に組み込まれる。拡張機能ファイルを記述するファイルがクライアント上にダウンロードされる。これらのファイルはクライアントに、特定の拡張機能をプログラムまたはプラットフォームにプラグインとして組み込む場所、その時期、およびその方法、さらに適切な拡張機能ファイルが置かれている場所、そのダウンロード方法を知らせる。拡張機能ファイルをダウンロードして、プラットフォームに組み込む。
【０００７】
一実施形態では、さまざまな拡張機能に関連する特定の種類の記述ファイルを処理し整理するための本発明のソフトウェアアーキテクチャが提供されている。アタッチメントポイントと呼ばれるフィルタ処理メカニズムを使用して、ソフトウェア拡張機能を定義するさまざまな記述型のファイル用のハンドラを作成する。各ハンドラは、アタッチメントマネージャと呼ばれる。拡張可能機能タイプごとにアタッチメントマネージャが用意される。アタッチメントマネージャはアタッチメントポイントによって供給される拡張機能ファイルのデータを解釈する。定義済みアタッチメントマネージャのほかに、アタッチメントポイントからのデータを使用してカスタムアタッチメントマネージャを作成することができる。拡張機能により特定の機能タイプが拡張される場合、このアタッチメントポイントにより、適切なアタッチメントマネージャのみが通知されることが保証され、その機能タイプをプログラムまたはプラットフォームに効率よく組み込むことができる。
【０００８】
（好ましい実施形態の詳細な説明）
概要
後述の方法およびシステムは、アプリケーションプログラムまたはソフトウェアプラットフォームに機能を動的に追加するためのメカニズムを実現する。機能つまり「拡張機能（ｅｘｔｅｎｓｉｏｎ）」は、その名のとおり、インターネットなどのネットワークを介して追加すると有利である。新しい機能を実施したり既存の機能に追加したりするための拡張機能は、拡張機能のインストールを行うための基盤としてＵＲＬなどのネットワークアドレスのみを使用して追加することができる。つまり、拡張機能を含むファイルはすべて、ネットワーク上に保持し、１つまたは複数のネットワークサイトを介してアクセスすることができる。
【０００９】
拡張機能はいろいろな方法で記述できる。ある方法では、さまざまな拡張機能の処理および使用を簡単にする階層型タグ対応言語を利用する。具体的な一実施態様では、さまざまな機能を組み込むことができるソフトウェアプラットフォームを提示している。ソフトウェアプラットフォームおよび後述の本発明のアーキテクチャを使用すると、第三者および第四者の開発者はホスティングサービスについて知識がなくても（または関係がなくても）プラットフォームに簡単に継ぎ目なく組み込むことができるプラットフォームの拡張機能を開発できる。第三者開発者とは、プラットフォームの拡張機能を開発する開発者のことである。第四者開発者は、第三者開発者の拡張機能への拡張機能を開発する開発者とすることができる。したがって、第三者および第四者拡張機能の組込みは、開発者に関する限り本質的に透過的なプロセスである。
【００１０】
たとえば、図１を考えると、ユーザのコンピュータ１００および複数のいわゆる拡張機能のソース１０２、１０４、および１０６を示している。拡張機能のソースは、ネットワークを介してソフトウェア拡張機能の送り元となる任意のエンティティを備えることができる。実施例では、ネットワークとしては、インターネットを使用できるが、他のネットワーク（たとえば、ＬＡＮおよびＷＡＮ）を利用することも確かにできる。拡張機能のソースとしては、ネットワークサイトを維持できる小売店などの企業体が考えられるがそれらに限定されない。一実施態様では、ユーザはアプリケーションプログラムまたはソフトウェアプラットフォームを提供するコンピュータ上でソフトウェアを実行できる。本明細書では、「アプリケーションプログラム」および「ソフトウェアプラットフォーム」という用語を等価な用語として使用する。異なる拡張機能のソース１０２−１０６はそれぞれ、ユーザのマシン上で実行されているソフトウェアプラットフォームにプラグインとして付加できるソフトウェア拡張機能を提供できる。これらの拡張機能は、インターネットなどのネットワークを介して配布可能であり、これにより、ユーザのマシン上で実行できるアプリケーションを提供しやすくなる。前記実施形態では、これらの拡張機能は、新しく登場した業界標準を踏まえてＸＭＬにより論理的に記述されている。さらに、ＸＭＬを使用すると、ＸＭＬ ＤＯＭプロパティをインターネットにプロモートすることにより将来、拡張機能を発見しやすくなる。ただし、拡張機能を記述するための任意の適当な形式があればそれも使用でき、たとえばバイナリ記述を使用できることも理解されるであろう。
【００１１】
拡張機能は、さまざまな拡張機能のソースから配布でき、それらのソースの数はいくつあってもよい。本発明の方法およびシステムでは、提供される拡張機能を処理する合理化され整理された方法を実現する。ＸＭＬを使用すると、複数の異なる拡張機能のソースから得た拡張機能を効率よく処理することができ、しかも拡張機能の特定の部分を利用するソフトウェアコンポーネントに過度の負担をかけずに済み有利である。
【００１２】
具体的な一実施態様では、ユーザのマシン上のソフトウェアプラットフォームは、異なるドキュメント中心の作業をユーザが遂行できるようにするさまざまな異なる統合機能を提供する。システム例が、上で参照により組み込まれている「Ｓｉｎｇｌｅ Ｗｉｎｄｏｗ Ｎａｖｉｇａｔｉｏｎ Ｍｅｔｈｏｄｓ ａｎｄ Ｓｙｓｔｅｍｓ」という表題の米国特許出願で説明されている。
【００１３】
コンピュータ環境の例
後述の実施形態は、さまざまなコンピュータシステムに関連して使用することができる。本書の目的に関して、コンピュータシステムは、ある種のプロセッサ、つまりマイクロプロセッサと、ある種のオペレーティングシステムを含む任意のコンピューティングデバイスとみなすことができる。したがって、コンピュータシステムは、従来のデスクトップコンピュータ、さらに高機能のサーバ、携帯電話、ポケットコンピュータデバイスなどのさまざまな携帯型デバイスなどを含むがそれらに限定されないものとして解釈できる。
【００１４】
図２は、本明細書で説明している実施形態を実施するのに使用できるコンピュータシステム例を示しているに過ぎない。コンピュータ１３０は、１つまたは複数のプロセッサまたは処理装置１３２、システムメモリ１３４、およびシステムメモリ１３４などの各種システムコンポーネントをプロセッサ１３２に結合するバス１３６を含む。バス１３６は、メモリバスまたはメモリコントローラ、周辺バス、グラフィック専用高速バス、およびさまざまなバスアーキテクチャを使用するプロセッサまたはローカルバスを含めて数種のバス構造の任意のもの１つまたは複数を表している。システムメモリ１３４は、読取り専用メモリ（ＲＯＭ）１３８およびランダムアクセスメモリ（ＲＡＭ）１４０を含む。起動時などにコンピュータ１３０内の要素間の情報転送を助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１４２は、ＲＯＭ １３８に格納される。
【００１５】
コンピュータ１３０はさらに、ハードディスク（図には示されていない）への読み書きを行うハードディスクドライブ１４４、取外し可能磁気ディスク１４８への読み書きを行う磁気ディスクドライブ１４６、およびＣＤ ＲＯＭやその他の光媒体などの取外し可能光ディスク１５２への読み書きを行う光ディスクドライブ１５０を含む。ハードディスクドライブ１４４、磁気ディスクドライブ１４６、および光ディスクドライブ１５０は、ＳＣＳＩインターフェース１５４または他の何らかの適切なインターフェースによりバス１３６に接続されている。ドライブおよび関連コンピュータ読取り可能媒体は、コンピュータ１３０用のコンピュータ読取り可能命令、データ構造、プログラムモジュール、およびその他のデータを格納する不揮発性ストレージを備える。本明細書で説明している環境例ではハードディスク、取外し可能磁気ディスク１４８、および取外し可能光ディスク１５２を採用しているが、当業者であれば、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）などのコンピュータからアクセス可能なデータを格納できる他のタイプのコンピュータ読取り可能媒体も例示のオペレーティング環境で使用できることを理解するであろう。
【００１６】
ハードディスク１４４、磁気ディスク１４８、光ディスク１５２、ＲＯＭ １３８、またはＲＡＭ １４０には、オペレーティングシステム１５８、１つまたは複数のアプリケーションプログラム１６０、その他のプログラムモジュール１６２、およびプログラムデータ１６４などのいくつかのプログラムモジュールを格納できる。ユーザは、キーボード１６６やポインティングデバイス１６８などの入力デバイスを介してコンピュータ１３０にコマンドおよび情報を入力できる。他の入力デバイス（図に示されていない）としては、マイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらの入力デバイスやその他の入力デバイスは、バス１３６に結合されているインターフェース１７０を通じて、処理装置１３２に接続されている。モニタ１７２やその他のタイプの表示デバイスも、ビデオアダプタ１７４などのインターフェースを介してバス１３６に接続される。モニタに加えて、パーソナルコンピュータは通常、スピーカやプリンタなどの他の周辺出力デバイス（図に示されていない）を含む。
【００１７】
コンピュータ１３０は、一般に、リモートコンピュータ１７６などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク環境で動作する。リモートコンピュータ１７６は、他のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたはその他の共通ネットワークノードでもよく、通常は、コンピュータ１３０に関係する上述の要素の多くまたはすべてを含むが、メモリストレージデバイス１７８のみが図２に示されている。図２に示されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）１８０とワイドエリアネットワーク（ＷＡＮ）１８２を含む。このようなネットワーキング環境は、事務所、企業規模のコンピュータネットワーク、イントラネットおよびインターネットではよくある。
【００１８】
ＬＡＮネットワーキング環境で使用する場合は、コンピュータ１３０はネットワークインターフェースまたはアダプタ１８４を介してローカルネットワーク１８０に接続される。ＷＡＮネットワーキング環境で使用する場合は、コンピュータ１３０は通常、モデム１８６またはインターネットなどのワイドエリアネットワーク１８２上で通信を確立するためのその他の手段を含む。モデム１８６は、内蔵でも外付けでもよいが、シリアルポートインターフェース１５６を介してバス１３６に接続される。ネットワーク環境では、パーソナルコンピュータ１３０またはその一部に関して述べたプログラムモジュールは、リモートメモリストレージデバイスに格納できる。図に示されているネットワーク接続は例であり、コンピュータ間に通信リンクを確立するのにその他の手段を使用できることは理解されるであろう。
【００１９】
一般に、コンピュータ１３０のデータプロセッサは、コンピュータのさまざまなコンピュータ読取り可能記憶媒体に異なる時期に格納されている命令を使ってプログラムされる。プログラムおよびオペレーティングシステムは、通常、たとえば、フロッピー（登録商標）ディスクまたはＣＤ−ＲＯＭで配布される。それらの媒体からコンピュータの補助記憶装置にインストールまたはロードされる。これらのプログラムは、実行時にコンピュータの主記憶装置に少なくとも一部はロードされる。本明細書で説明している発明は、これらの種類やその他のさまざまな種類のコンピュータ読取り可能記憶媒体を含み、これらの媒体にはマイクロプロセッサまたはその他のデータプロセッサと連動して後述のステップを実施する命令またはプログラムが格納されている。本発明はさらに、後述の方法および手法によりプログラムしたときにコンピュータ自体も含む。
【００２０】
例示のため、プログラムおよびオペレーティングシステムなどの他の実行可能なプログラムコンポーネントはここでは別個のブロックに示されているが、このようなプログラムおよびコンポーネントはさまざまな時期に、コンピュータの異なるストレージコンポーネント内に置かれ、コンピュータのデータプロセッサにより実行されることは理解されるであろう。
【００２１】
拡張機能
本書で使用している「拡張機能」は、アプリケーションプログラムまたはソフトウェアプラットフォームに追加することができるソフトウェア機能およびコンテンツを含むものとみなされるがそれらに限定されない。これらの追加により、通常、拡張機能を組み込む前にはアプリケーションプログラムにはなかったある種の機能を与えるか、あるいは少なくとも１つの既存の機能の動作を変更する。拡張機能がアプリケーションプログラムに組み込まれるか、または直接統合されると、ある程度、アプリケーションプログラムのビヘイビアまたは動作が変化する。拡張機能は、動的に追加されたコンテンツを提供し、たとえば、アプリケーション（電子メールアプリケーションなど）、既存のアプリケーションを拡張するためのプラグイン（電子メールアプリケーションへのＦＡＸプラグインなど）、または単なるＷｅｂページを提供することができる。
【００２２】
前記の実施形態では、業界標準のテキストベースのマークアップ言語であるＸＭＬを使用して拡張機能を記述している。ＸＭＬを使用すると、ソフトウェアコンテンツの拡張性が大幅に向上する。特に、第三者がさまざまな拡張機能をオーサリングし、ＸＭＬで記述することにより、拡張機能をアプリケーションプログラムに容易に統合することができる。ただし、ＸＭＬは拡張機能を記述し、使用する１つの方法例を構成するに過ぎないことは理解されるであろう。もちろん、他の方法も使用できる。
【００２３】
拡張機能の編成例
前記の実施形態では、拡張機能は３つの別々の、ただし関連する部分、拡張機能定義ファイル（ＥＤＦ）、パッケージマニフェスト（ＰＫＧ）、および拡張機能を構成するまたは定義するコード、コンポーネント、または「ビット」で編成される。ＥＤＦは、クライアントがＥＤＦにアクセスするための手段となるＵＲＬ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）とすることもできるが、ＵＲＬと関連している必要はない。慣例によりまた選択により、ＰＫＧファイルはＥＤＦと同じＵＲＬに置かれる。前記のＥＤＦおよびＰＫＧは、それぞれ、他方を使用するのに必要なわけではないことは理解されるであろう。たまたま、本書で提示した例では、その２つがともに使用されているだけである。その目的のために、これらの機能はそれぞれ別々にかつ独立に使用することができる。
【００２４】
ＥＤＦでは、アプリケーションプログラムまたはソフトウェアプラットフォームへの論理的アタッチメントを記述するが、ＰＫＧでは、拡張機能で使用される物理的ファイルおよびリソースを指定する。ＥＤＦとＰＫＧの間には一対一の対応関係がありえる。
【００２５】
図３は、ＥＤＦ ３０２と、対応するパッケージマニフェスト（ＰＫＧ）３０４を含む編成例３００を示している。図示の例では、ＥＤＦ ３０２はＸＭＬを使用して、アプリケーションプログラムの論理的アタッチメントまたは拡張機能を記述する。対応するＰＫＧ ３０４では、特定の拡張機能と関連付けられた物理的ファイルおよびリソースを指定する。ファイルタイプの例がＰＫＧ ３０４の右に示されているが、これは、ＨＴＭ、ＧＩＦ、ＵＤＯ、ＸＭＬ、ＤＬＬ、および他の各種ファイルタイプを含むがそれらに限定されない。
【００２６】
拡張機能定義ファイル（ＥＤＦ）
前記の例では、ＥＤＦは拡張機能を論理的に記述するＸＭＬファイルである。たとえば、ＥＤＦでは、ユーザインターフェース（ＵＩ）を構成するＨＴＭＬ、さまざまな機能を実施するコードを含むオブジェクトなどを記述できる。ＥＤＦは、さらに、拡張機能を含む機能のすべてまたは一部を含むこともできる。たとえば、ツールバーを記述するＨＴＭＬを直接、ＥＤＦファイルに取り込み、ツールバーアタッチメントマネージャがＵＲＬからではなくＥＤＦファイルから読み込むようにできる。ＥＤＦに含まれる情報は処理され、（ＰＫＧに含まれる情報とともに）、適切なファイルがユーザのコンピュータに自動的にインストールされる。これは、ユーザのシステムレジストリに見られるように、コンピュータの永続的設定を操作せずに控えめに行われる。
【００２７】
ＥＤＦは、ＸＭＬで実施され、さまざまな拡張機能と関連するさまざまなタグを含む。さまざまなタグは以下のものに対応できる。
・　ユーザインターフェース要素
・　ビヘイビア／コンポーネント／オブジェクト
・　ストア要素
・　ユーザ定義オブジェクト
・　あるいは、アプリケーションまたはプラットフォーム内の拡張可能なポイントを表す何か他のもの
【００２８】
ＥＤＦは、「オープンスキーマ」を有すると有利であり、これは、第三者開発者が拡張メカニズムを拡張し、独自タグを作成することにより独自拡張機能を含めるようにできることを意味する。さらに、拡張機能はそれ自体、他の開発者によって拡張することができる。ＥＤＦはさらに、１つまたは複数の定義済みタグを備えることもできる。ユーザインターフェース要素用の定義済みＸＭＬタグの例は、ツールバー、アクセラレータ、メニュー項目、テーマなどの機能タイプ用のタグを含むことができる。これらの機能タイプは、上の参照で取り込まれ、すぐ下の表で定義している単一のナビゲーション可能ウィンドウアプリケーションで使用する。
【００２９】
【表１】
2004512578.tif 000002
【００３０】
ビヘイビア／コンポーネント／オブジェクトの定義済みＸＭＬタグの例には、サービスのタグが含まれる。これらの機能タイプは、上の参照で取り込まれ、すぐ下の表で定義している単一のナビゲーション可能ウィンドウアプリケーションで使用する。
【００３１】
【表２】
2004512578.tif 000003
【００３２】
ストア要素の定義済みＸＭＬタグの例は、コンテンツクラスおよびオフラインデータソース用のタグを含む。これらの機能タイプは、上の参照で取り込まれ、すぐ下の表で定義している単一のナビゲーション可能ウィンドウアプリケーションで使用する。
【００３３】
【表３】
2004512578.tif 000004
【００３４】
ＥＤＦスキーマ
前記の実施形態では、ＥＤＦは利用される特定のＸＭＬスキーマを有する。このスキーマは、ある種の拡張機能を必要とするソフトウェアコンポーネントに情報を簡単に配布できるように階層編成に配列したＸＭＬタグの収集を備える。前記の実施形態では、ＥＤＦの外側（囲むタグ）は「拡張機能」タグである。
【００３５】
図４は、拡張機能タグの例を示している。「拡張機能」タグは次の属性のうち１つまたは複数を含むことができる。属性はすべてオプションである。
【００３６】
【表４】
2004512578.tif 000005
【００３７】
「拡張機能」外部タグ内で、１つまたは複数の子タグは、「最上位タグ」とも呼ばれる。最上位タグはそれぞれ、特定の拡張機能により追加可能な機能タイプと関連付けられている。機能タイプの例については、上の表１−３について説明している。各最上位タグの下に、１つまたは複数の子タグがあり、これらは個別に、特定の拡張機能により追加される機能タイプの特定の機能と関連付けられる。
【００３８】
図５は、この実施形態によるＸＭＬスキーマ編成例を示す。ＥＤＦ内の最上位タグごとに、タグと関連するデータを受け取り、そのデータを使用してプラットフォームまたはアプリケーションプログラムに拡張機能を組み込むことができるソフトウェアコンポーネントである関連アタッチメントマネージャがある。異なるアタッチメントマネージャが異なる方法でタグから受け取ったデータを解釈して、異なる種類の拡張性を提供できるため、異なる最上位タグは異なる構造の異なる種類のデータを含むことができる。これは、以下の「アーキテクチャ」の項でさらに明らかになるであろう。「ｅｄｆ ：」ＸＭＬネームスペース修飾子が、拡張機能で独自のタグおよび対応するアタッチメントマネージャを用意できるオープンスキーマをサポートできることに留意されたい。ｅｄｆネームスペース内のタグは、アプリケーションまたはソフトウェアプラットフォームの内蔵アタッチメントマネージャで使用する。他のネームスペース内のタグは、追加拡張ポイントを用意するために第三者が使用する。
【００３９】
パッケージマニフェスト（ＰＫＧファイル）
パッケージマニフェスト（ＰＫＧ）は、インターネットなどのネットワークを介してソフトウェアを複数ファイルの形に編成してダウンロードする作業を支援するものである。本書に取り上げている例では、ＰＫＧはＥＤＦとともに採用すると有利である。ただし、上で指摘したように、ＰＫＧと関連して説明する手法は、ＥＤＦから独立してまたインターネットなどのネットワークを経由してソフトウェアを配布することが望ましい場合に任意の適当なシナリオで展開することができる。ＥＤＦでは拡張機能をアプリケーションプログラムまたはプラットフォームに論理的に付加する方法を記述するが、パッケージマニフェストの役割は、編成された配布、妥当性確認および／または提供することができるさまざまな拡張機能と関連するファイルの更新などを補助することである。
【００４０】
ソフトウェアコンテンツまたはファイルのＷｅｂ補助配布の配布メカニズムを設計する際に、いくつかの事項を考慮することが重要である。
【００４１】
できる限り、更新およびインストールの作業中に必要なダウンロードのサイズを小さくすることが望ましい。この考慮事項に対処するため、ソフトウェアコンテンツを複数のパッケージに分割する。各パッケージは、共通のまたは正しく定義された機能を実施する１つまたは複数のファイルからなるグループを含む。コンテンツを個別のパッケージに分割することにより、インストールおよび更新時に必要なダウンロードのサイズを最小限に抑えることができる。各パッケージは、パッケージマニフェスト（ＰＫＧ）により記述され、このパッケージマニフェストに、妥当性確認またはセキュリティおよびバージョニングに使用できるファイル記憶場所およびハッシュ値などのファイル情報が含まれる。
【００４２】
また、エンドユーザはＷｅｂでの操作と同様の操作を行えることが望ましい。そのためには、ユーザがパッケージ全体のロードの終了を待ちそれから対話的に操作する従来のソフトウェアパッケージではなく、Ｗｅｂページをロードしている感覚で拡張機能をロードできるようにする。前記の実施形態では、ユーザは拡張機能ファイルをストリーミングによりクライアントにダウンロードして、ソフトウェアアプリケーションプログラム全体のロードが完了するのを待たなければならなかった場合に比べてかなり速くアプリケーションプログラムとの対話操作を開始できるため、Ｗｅｂでの操作と変わらない操作を行える。たとえば、ユーザインターフェース（ＵＩ）のイメージファイルをストリーミングによりダウンロードする場合、ユーザはそのユーザインターフェースをファイルのストリームインとみなすことができる。たとえば、上記の参照により組み込まれている特許出願で説明されている複数の異なる機能を持つ単一のアプリケーションプログラムを考察する。ユーザは、電子メール機能を検索し、電子メール機能を対話操作するのに必要なファイルをダウンロードすることができる。他の異なる機能と関連するファイルは、電子メール機能と関連するファイルの後にダウンロードされることになる。このようにして、ユーザはすべての他の機能と関連するすべてのファイルを待つことなく特定の機能内で操作を開始することができる。
【００４３】
注目している他の考慮事項は、拡張機能ファイルまたは「ビット」をクライアントに配布する際の効率に関係する。この考慮事項に対処するため、前記の実施形態では、２つの異なるダウンロード方式、すなわちスロットルダウンロードとバックグラウンドダウンロードを利用する。スロットルダウンロードでは、ファイルの転送に利用する有効な帯域幅および媒体の種類を考慮しながらダウンロード操作を実行する。任意の適当なスロットルダウンロードプロセスを採用できるが、これは、当業者であれば理解するだろう。バックグラウンドダウンロードは、ユーザがアプリケーションプログラム操作している間に実行され、ユーザがその作業を継続できるようにバックグラウンドスレッドを割り振ることにより実施される。使用する最適化手法の１つは、ユーザによる作業に応じてパッケージに優先順位をつけて配布するというものである。
【００４４】
別の考慮事項は、ユーザによるコンピュータ操作を最適化することに関連している。ここで、ユーザによる操作は、ユーザ向けの最も一般的なシナリオを用意することにより最適化される。これは、最初に必要とする機能をユーザに提供し、次に、バックグラウンドダウンロードプロセスで、将来ユーザが使用すると思われる機能を実施するコードを提供するようにすることを効果的に指向している。ユーザが最初に必要と考える機能を判別するために、自動化されたシナリオベースのパッケージングプロセスを用意し、スクリプト化されたシナリオのファイル使用状況ログと突き合わせてそのプロセスを実行する。
【００４５】
以下の項では、これらの考慮事項およびその考慮事項に対処することを目的とする本発明の解決方法について詳述する。
【００４６】
パッケージマニフェスト定義
前記の実施形態では、パッケージマニフェスト（ＰＫＧファイル）はパッケージ内で使用されるファイルのリストを備える。このリストは、多少圧縮し、デジタル署名を入れると有利である。各パッケージマニフェストには、１つまたは複数のファイルのリストが格納され、それぞれのファイルは関連するハッシュおよびファイルのキャッシングを制御するダウンロードディレクティブを含むことができる。拡張機能のオーサリングが行われると、ソフトウェアツールを使用してパッケージマニフェストを生成することができる。
【００４７】
さらに、パッケージマニフェストにより、他の複数の情報も指定することができる。
【００４８】
・　ファイルグループ
拡張機能のすべてのファイルに、いくつかの定義済みファイルグループに応じてラベルを付けることができる。特定のファイルのファイルグループにより、特定のファイルをダウンロードする時期、クライアント上の格納先、パッケージング方法が決定される。前記の実施形態では、４種類の定義済みファイルグループが用意されており、これを以下の表に一覧としてまとめた。
【００４９】
【表５】
2004512578.tif 000006
【００５０】
・　ファイルダウンロードの優先度
各グループ内のファイルは、ダウンロードする順序で並んでいる。このダウンロード順序は、図６に例が示されている、パッケージマニフェスト内のファイルの順序で暗黙のうちに設定されている。
【００５１】
・　セキュリティ／バージョニングのハッシュ値
パッケージマニフェスト内の個々のファイルに、関連するハッシュ値を割り当てることができる。それぞれのハッシュ値は、暗号化アルゴリズムによりファイルを処理することにより生成される。暗号化アルゴリズムの例として、ＭｉｃｒｏｓｏｆｔのＣｒｙｐｔｏＡＰＩがある。図示の例では、それぞれのファイルをｂａｓｅ ６４−ｅｎｃｏｄｅｄハッシュ値とともにリストし、クライアントにコンテンツが届いたときにファイルの妥当性を確認することができる。特に、パッケージマニフェストは安全にクライアントに送信される（つまり、電子署名されているということである）。パッケージマニフェストには、個々のファイルに対するハッシュ値が含まれる。個々のファイルをクライアントが受け取ると、それぞれのファイルを、パッケージマニフェスト内にハッシュ値を設定するのに使用したのと同じＣｒｙｐｔｏＡＰＩで処理することができる。特定のファイルのハッシュ値が比較してまずいところがなければ、そのファイルは改変されておらず、安全である。
【００５２】
ファイルを更新するときに、ハッシュ値は拡張機能の異なるバージョン間で変更されていないファイルを識別するという有用な目的に使用できる。たとえば、図７を考察する。そこで、クライアントパッケージキャッシュ内の以前のディレクトリ７００にハッシュ＝ｘのファイル１とハッシュ＝ｙのファイル２の２つのファイルを含むパッケージＡが置かれている。このパッケージは旧いバージョンの拡張機能と関連していると想定する。更新されたバージョンを生成すると、そのパッケージマニフェストがクライアントに配布される。更新された拡張機能バージョンは、コードまたはＷｅｂサーバ７０４のソースディレクトリ上に表現される。パッケージマニフェストには新しい拡張機能バージョンのすべてのファイルに対するハッシュ値が記述される。新しいクライアント宛先ディレクトリ７０２は、新しい拡張機能のすべてのファイルについて定義されている。新しい拡張機能のファイルに対するハッシュ値がどれも旧いディレクトリ７００内にあるファイルのハッシュ値と同じである場合、それらのファイルを旧いディレクトリ７００から新しい宛先ディレクトリ７０２に直接コピーすることができる。この例では、ファイル１のハッシュ値はソースディレクトリ７０４のファイル１のハッシュ値と同じであり、新しい宛先ディレクトリ７０２にコピーできる。しかし、ファイル２のハッシュ値はソースディレクトリ上のファイル２のハッシュ値と異なるため、旧いディレクトリ７００からコピーされない。むしろ、ファイル２はコードサーバからダウンロードされる。新しいファイル３が追加されており、また、コードサーバからダウンロードされる。したがって、この例では、新しいバージョンの拡張機能の結果、拡張バージョンのすべてのファイルよりも少ないダウンロードとなっている。これは、旧い拡張バージョンのそれぞれのファイルに対するハッシュ値を新しい拡張バージョンのファイルのハッシュ値と比較できたからである。同じ値であるハッシュ値は、バージョン間で変更されていないファイルを示す。
【００５３】
バージョニングにハッシュ値を使用する方法には、従来のバージョニング方式に比べて２つの大きな利点がある。１つは、更新プロセスが自動化されるということである。つまり、明示的なバージョン番号により、ファイルの新しいリリースの出荷時にバージョン番号の更新を忘れる可能性がある。ハッシュ値を使用するとこの問題を回避できる。２つ目は、バージョニングはファイルタイプに依存していないという点である。特に、従来のバージョニング方式では、一般に、バージョン情報をファイル内に埋め込むが、すべてのファイル（たとえば、ＧＩＦファイル）が埋め込まれたバージョン情報をサポートするわけではない。この例では、バージョニングにハッシュ値を使用する方法は特定のファイルタイプが埋め込まれたバージョン情報をサポートしているかいないかということに依存しない。さらに、バージョン情報は、ファイル自体とは別に格納することができる。したがって、最新かどうかを調べるために実際のファイルにアクセスする必要はなくなる。
【００５４】
・　パッケージの総格納サイズ
パッケージの総格納サイズをダウンロード時に使用し、ユーザ側に十分なディスク領域のあることを確認する。
【００５５】
・　ＤＬＬのＣｌａｓｓＩＤ
スクリプト作成者がＯＭと突き合わせてクラスを作成できるようにするためには各ＤＬＬのＣｌａｓｓＩＤのリスティングが必要である。さらに、これにより、特定のクラスに対するコードがどのパッケージに含まれているかを調べることができる。
【００５６】
・　ＤＬＬロード依存関係
依存関係セクションがあるのは、他のｄｌｌの検索パス内にあるという理由でロードされるということに依存するレガシコードを使用できるようにするためである。この場合、依存ｄｌｌをロードをする前に依存ｄｌｌがパッケージキャッシュディレクトリ内にあることを確認する必要がある。図６は、階層型タグベース言語で定義されているパッケージマニフェスト例６００を示している。タグベース言語は拡張可能性および柔軟性の点で望ましいＸＭＬを採用していると有利である。この例では、いくつかのタグを階層配列で用意している。「ｐａｃｋａｇｅ」タグには、パッケージのサイズに関する情報が含まれている。「ｆｉｌｅｓ」タグは、「ｐａｃｋａｇｅ」タグの子であり、特定のパッケージに含まれているファイルグループに関する情報が格納される。「ｆｉｌｅ」タグは、「ｇｒｏｕｐ」タグの子であり、拡張機能を備える特定のファイルに関する情報、つまりファイル名とハッシュ値を含む。「ｄｅｐｅｎｄｅｎｃｙ」タグは、「ｆｉｌｅ」タグの子として提供され、上述のように依存関係をリストする。「ＣＯＭＣｌａｓｓ」タグも「ｆｉｌｅ」タグの子として提供され、上述のようにＩＤを含む。この方式のファイルグループの順序により、暗黙のうちに、ファイルのダウンロード順序が定義されている。
【００５７】
パッケージ配布
最適なパッケージ配布を行うために、２つの異なる配布方式を使用する。１つは、知られているスロットルダウンロード手法を使用してスロットルダウンロード方式を利用することである。ここで、拡張機能を提供する際に使用する有効な帯域幅と媒体などの考慮事項を取り上げる。
【００５８】
２つ目は、バックグラウンドダウンロード方式を使用することである。バックグラウンドダウンロードでは、ユーザはコンテンツのダウンロード中もアプリケーションプログラム内で作業を続けることができる。フォアグラウンドダウンロードは、ユーザが、たとえば、拡張機能リンクをクリックしてファイル／拡張機能を明示的に要求したときに、または、たとえば、「Ｃｏｍｐｏｓｅ」メールボタンをクリックしてローカルでは利用できないファイルのダウンロードが必要なアクションを要求したときに使用される。
【００５９】
バックグラウンドダウンロードとともに、キュー管理機能も得られる。特に、拡張機能をインストールしたり更新したりする必要があるときに、本質的にはパッケージを管理するソフトウェアコンポーネントであるパッケージマネージャに以下の情報を供給する。
・　コードサーバに関するパッケージマニフェスト情報のＵＲＬ
・　クライアントのパッケージキャッシュ内のパッケージ宛先ディレクトリのＵＲＮ
・　（オプション）パッケージキャッシュ内の旧いパッケージディレクトリ（存在している場合）のＵＲＮ
【００６０】
この情報から、パッケージマネージャはパッケージオブジェクトを作成し、そのパッケージオブジェクトをダウンロードキューに追加する。ダウンロードキューは、パッケージダウンロード順序の再配列を行いやすいように設計されている。たとえば、２つのパッケージオブジェクト、パッケージオブジェクト８０２（パッケージＡに対応する）とパッケージオブジェクト８０４（パッケージＢに対応する）が格納されているダウンロードキュー８００の一部を示している図８を考察する。パッケージオブジェクトは、ダウンロードまたはインストールされている対応するパッケージのファイルのリストを保持する。この例では、パッケージＡのファイル１および２はインストールされているがファイル３はインストールされていない、またパッケージＢのファイル１、２、および３はインストールされていない。ダウンロードキューは、ユーザの行う作業に基づいて再配列することができる。つまり、ユーザの取るアクションに基づき、ダウンロードするファイルの優先度を変更できるということである。この例では、パッケージマネージャはダウンロードキューの先頭にあるパッケージ内の最初のアンインストールファイルを処理するように考案されている。ただし、ユーザはファイルがダウンロードキューの先頭にある拡張機能と異なる拡張機能のファイルを使用し始める場合、ユーザが使い始めたファイルの対応するパッケージをダウンロードキューの先頭に移動することができる。ファイルのパッケージはそのＵＲＮによって指定されるため、ファイルのパッケージはダウンロードキュー内ですばやく識別され見つけられる。たとえば、図８を考えると、パッケージＢ内のファイルの１つがパッケージマネージャがパッケージＡの３番目のファイルをインストールし始める前に要求された場合、パッケージＢはダウンロードキューの先頭に移動される。
【００６１】
図９は、前記実施例によるダウンロードキュー管理方法の複数のステップを説明する流れ図である。この方法は、任意の適当なハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せにより実施することができる。この例では、この方法をソフトウェアで実施している。
【００６２】
ステップ９００では、拡張機能の１つまたは複数の要求を受け取る。要求は、任意の適当な方法で生成できる。ステップ９０２で、ダウンロードするそれぞれの拡張パッケージに対応するパッケージオブジェクトを生成する。ステップ９０４で、ダウンロードキュー内にパッケージオブジェクトを配列する。次いでステップ９０６で、ダウンロードキュー内のパッケージオブジェクトに対応するファイルをダウンロードする。このステップは、たとえば、ダウンロードキューの先頭から始め、パッケージオブジェクトのすべてのファイルがダウンロードされるまでファイルをダウンロードし、ダウンロードし終えたら次のパッケージオブジェクトに移動することにより実施できる。ステップ９０８で、ユーザアクションが現在のパッケージオブジェクト内に記述されていないファイルを必要とするかどうかを確認する。ユーザのアクションが現在のパッケージオブジェクトによって記述されていないファイルを必要としない場合、この方法はステップ９０６に分岐して戻り、現在のパッケージオブジェクトと関連するファイルのダウンロードを続ける。他方、ユーザのアクションが現在のパッケージオブジェクトで記述されていないファイルを必要とする場合、ステップ９１０で、必要なファイルと関連するパッケージオブジェクトをダウンロードキューの先頭に移動し、この新たに再配置されたパッケージオブジェクトと関連するファイルのダウンロードを開始する。このステップは、ファイルと関連ＵＲＮを確認することによりどのパッケージオブジェクトが必要なファイルと関連するかを確認することにより実施できる。このＵＲＮにより、ファイルのパッケージを指定して、パッケージオブジェクトをすばやく見つけ、ダウンロードキューの先頭に移動することができる。
【００６３】
パッケージ作成
前記の実施形態の革新的特長の１つに拡張性がある。つまり、ソフトウェアプラットフォームを、さまざまな第三者ユーザ定義拡張機能により拡張できるアプリケーションプログラムの形で提供する。これらの拡張機能は、Ｗｅｂ上で配布され、ソフトウェアプラットフォームに直接統合される。編成された配布プロセスを提供するために、パッケージを統一された方法で作成し、予測できる形で処理し、ソフトウェアプラットフォームに統合するようにする。
【００６４】
前記の実施形態により、各パッケージはエンドユーザ機能に対応する必要がある。たとえば、上記の参照により組み込まれている特許出願では、電子メール、連絡先、ドキュメントオーサリング、およびプランナー機能ごとに別々のパッケージを用意している。互いに依存しないパッケージが依存関係を共有する場合、この共有されている依存関係を専用パッケージとする必要がある。たとえば、電子メールおよびドキュメントオーサリング機能が互いに依存している必要がある理由はないが、両方ともコンテンツをパブリッシュする機能は必要である。パブリッシュする機能を分離して専用パッケージにすることにより、ダウンロード順序の柔軟性がある程度確保される。ユーザが取り組み始める内容に応じて、電子メール機能またはドキュメントオーサリングに対応するファイルを最初にダウンロードすることができる。
【００６５】
図１０は、前記実施例によるパッケージ作成方法の複数のステップを説明する流れ図である。この方法は、任意の適当なハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せにより実施することができる。ただし、この方法の各部分は手動で実施できる。
【００６６】
ステップ１０００で、拡張機能として提供するエンドユーザ機能を識別する。ステップ１００２で、エンドユーザ機能間の共有されている依存関係を識別する。ステップ１００４で、エンドユーザ機能の個別のパッケージを作成する。ステップ１００６で、エンドユーザ機能間の共有されている依存関係に対して個別のパッケージを作成する。
【００６７】
自動化パッケージマニフェスト作成ツール
一実施態様により、自動化パッケージマニフェストツールを提供するが、これは、さまざまな入力パラメータを受け取り、パッケージマニフェストを自動的に作成するので有利である。このツールは、第三者がパッケージマニフェストを作成する作業を補助するために利用できる。
【００６８】
図１１は、望ましくはソフトウェアで実施されるパッケージマニフェスト作成ツール例１１００を示している。この特定の例では、このツールは以下の入力パラメータを受け取ることができる（一部はオプションである）。
・　拡張機能ディレクトリ
・　ファイルグループ情報およびＤＬＬロード依存関係（オプション）
・　シナリオ実行結果のファイル使用統計量（オプション）
【００６９】
拡張機能ディレクトリの入力パラメータにより、パッケージマニフェストによって記述されるすべてのファイルを含むディレクトリを指定する。これが唯一のパラメータであれば、ツール１１００は、ディレクトリ内のＥＤＦおよびＤＬＬが「Ｒｅｑｕｉｒｅｄ」セット内にリストされ、他のすべてのコンテンツが「Ｏｆｆｌｉｎｅ」であるマニフェストを生成する。
【００７０】
ファイルグループ情報およびロード依存関係パラメータはオプションである。拡張機能作成者が自分のファイルの置かれるべきカテゴリを知っている場合は、そのカテゴリをここで指定する必要がある。たとえば、以下に示すテンプレートマニフェストの作成者は、自分のエラー処理ＧＩＦをパッケージ必須セットに含めたいことを知っている。ここでの選択は常に、最終的なマニフェスト内で尊重される。さらに、拡張機能作成者がＤＬＬロード依存関係について知っている場合、それもここで指定する必要がある。
【００７１】
2004512578.tif 000007
【００７２】
シナリオ実行結果からのファイル使用統計量パラメータはオプションパラメータである。このパラメータにより、シナリオ実行結果に基づいてファイルダウンロードの優先度を決定できる。シナリオとは、平均的ユーザが通常、製品を使用している期間の特定の部分において製品を使用するときに従うタスクのスクリプトのことである。たとえば、電子メールメッセージの送信に関わるタスクに関係するシナリオがある（つまり、「新規メール」ボタンをクリックする、「送信先」フィールドに入力する、「件名」フィールドに入力するなど）。前記の実施形態では、シナリオ実行結果からのファイル使用統計量をさまざまなシナリオについてＩＩＳログを取ることで収集する。シナリオが異なれば、ある程度の確率的なサポートでファイルダウンロード順序が何らかの形でユーザが最初に使用する可能性の高いファイルを反映することを保証する方向に向かう。
【００７３】
ファイル使用統計量は、ユーザが通常遂行する実際の作業を記述する知識ベースを構築することにより動的に提供できることは理解されるであろう。その後、知識ベースに保持されている情報を使用してユーザベース上で確立されているパターンに実際に適合するダウンロードシナリオを生成し適応させることができる。
【００７４】
拡張機能作成者がパッケージマニフェスト作成ツール１１００にこの情報を渡そうとする場合、ログディレクトリとともに、ツールで分析するログのセクションの開始日と終了日を指定する必要がある。第三者向けには、グループ内のダウンロード優先度順序はすべてのシナリオにわたってグループのファイルをログで要求された順序となる。
【００７５】
一実施態様では、この方法はいく分高度である。追加情報（スクリプトステップに加えて）がＩＩＳログに格納され、シナリオ優先度およびチェックポイントを含む。シナリオ優先度は、それぞれのシナリオに割り当てられた優先度である。したがって、たとえば、１つのシナリオが他のシナリオよりも１０倍重要な場合、この情報を保持することができる。優先度（たとえば、１から１００の格付けで、１００を最高優先度とする）は、ともかく拡張機能を使用すると仮定して、ユーザがシナリオを１ステップずつ実行するときのパーセンテージとして最良の推測に等しくなければならない。チェックポイントは、一方のシナリオを他方のシナリオから区別するための手段である。たとえば、「Ｏｆｆｌｉｎｅ」および「Ｓｈｕｔｄｏｗｎ」と指定されているチェックポイントは、それぞれ、シナリオの先頭と末尾に自動的に追加することができ、ログ内のシナリオ実行結果を区別できる。さらに、スクリプト作成者は、オプションにより、チェックポイント中間シナリオを使用して、グループ優先度の変更を示すことができ、たとえば、シナリオスクリプトの一部に「Ｏｎ ｄｅｍａｎｄ」機能というラベルを付け、他の部分には「Ｏｆｆｌｉｎｅ」というラベルを付けることもできる。
【００７６】
図１２は、前記実施例によるパッケージマニフェスト作成方法の複数のステップを説明する流れ図である。この方法は、任意の適当なハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せにより実施することができる。前記の例では、この方法のさまざまなステップを、ソフトウェアで実施されているマニフェスト作成ツールにより実施した。
【００７７】
ステップ１２００で、パッケージマニフェスト作成ツールを提供する。このツールは、拡張機能作成者のマシン上に置かれているソフトウェアツールであってよい。ステップ１２０２で、拡張機能ディレクトリに関係する情報を第１の入力パラメータとして受け取る。ステップでは、拡張機能作成者によって提供されているファイルグループ情報またはロード依存関係情報があるかどうかを判別する。もしあれば、ステップ１２０６で、情報を入力パラメータとして受け取る。ステップ１２０８で、ファイル使用統計量情報があるかどうかを判別する。一実施形態では、このような情報を、上述のようにシナリオ実行結果を使用して得ることができる。このような情報が得られると、ステップ１２１０で、情報を入力パラメータとして受け取る。ステップ１２１２で、得られた情報すべてを入力パラメータとして使用し、マニフェストを自動的に生成する。
【００７８】
ファイル使用統計量に基づくファイル順序付け発見的手法の例
図１３は、前記実施形態によるファイル順序付けまたは並べ替え発見的手法を１つだけ説明する流れ図である。この特定の実施例はダウンロード対象のファイルの順序付けの一手段に過ぎないことを理解されたい。したがって、請求されている主題の精神と範囲から逸脱することなく他の発見的手法を使用することができる。
【００７９】
ステップ１３００で、ファイルをファイルグループ別に並べ替える。上で示した例では、ファイルはグループ化により、Ｒｅｑｕｉｒｅｄ、Ｏｆｆｌｉｎｅ、Ｏｎ Ｄｅｍａｎｄ、およびＯｎｌｉｎｅ Ｏｎｌｙの４つのグループのうちの１つに入れることができる。ファイルのグループは、まず、マニフェストによって判別され、グループ情報を提供していなければ、ログ内のチェックポイント情報に応じて、使用している最高の優先度グループにより判別する。「Ｒｅｑｕｉｒｅｄ」セット内のファイルは、その順序がすでに知られているため考慮する必要はない。ファイルに関するグループ情報が含まれていない場合、ＥＤＦおよびＤＬＬが「Ｒｅｑｕｉｒｅｄ」ファイルであり、ディレクトリ内の他のすべてのファイルは「Ｏｆｆｌｉｎｅ」であるという仮定を置く。
【００８０】
たとえば、３つの異なるシナリオについて次の初期ファイル使用状況情報を考える。
シナリオ１ファイル使用状況： １） ＦｉｌｅＡ．ｇｉｆ， ２） ＦｉｌｅＢ．ｘｍｌ， ３） ＦｉｌｅＥ．ｄｌｌ
シナリオ２ファイル使用状況： １） ＦｉｌｅＣ．ｘｍｌ， ２） ＦｉｌｅＡ．ｇｉｆ
シナリオ３ファイル使用状況： １） ＦｉｌｅＤ．ｊｓ， ２） ＦｉｌｅＡ．ｇｉｆ
シナリオ１＝優先度８０
シナリオ２＝優先度８０
シナリオ３＝優先度４０
【００８１】
この例では、関連するファイルを持つシナリオが３つある。それぞれのシナリオには、関連する優先度が割り当てられている。ファイルは最初に、グループ別に並べ替えられる（ステップ１３００）。この順序付け発見的手法では、ＤＬＬは「Ｒｅｑｕｉｒｅｄ」で、他のすべてのファイルは「Ｏｆｆｌｉｎｅ」とみなされることに注意されたい。これにより、次の並べ替えられたファイルが得られる。
必須（Ｒｅｑｕｉｒｅｄ）ファイル
ＦｉｌｅＥ
オフライン（Ｏｆｆｌｉｎｅ）ファイル
ＦｉｌｅＡ、ＦｉｌｅＢ、ＦｉｌｅＣ、ＦｉｌｅＤ
【００８２】
ステップ１３０２で、シナリオ優先度に基づいて（最高から最低へ）ファイルを並べ替える。高い優先度のファイルは、最初にダウンロードされるように順序付けられる。このステップで、次の並べ替えられたファイルが得られる。
必須（Ｒｅｑｕｉｒｅｄ）ファイル
ＦｉｌｅＥ
オフライン（Ｏｆｆｌｉｎｅ）ファイル
優先度８０グループ： シナリオ１ ＆ ２で使用されるファイル＝ ＦｉｌｅＡ、ＦｉｌｅＢ、およびＦｉｌｅＣ
優先度４０グループ： シナリオ３で使用されるファイル（すでにリストされていない）＝ ＦｉｌｅＤ
【００８３】
次に、ステップ１３０４で、シナリオ実行結果内のファイル使用順序によりファイルが並べ替えられる。複数のファイルを使用する優先度グループ化ごとに、ラベル付けされた優先度のシナリオの範囲内でダウンロードされた平均的順序に基づいてファイルが並べ替えられる。平均使用順序が小さいシナリオが先にダウンロードされる。シナリオが入力ファイル内に現れる順序に基づきタイが破棄される。たとえば、以下を考える。
ＦｉｌｅＡ： 平均的順序＝ （シナリオ１順序＋シナリオ２順序）／２＝（１＋２）／２＝１．５
ＦｉｌｅＢ： 平均的順序＝ （シナリオ１順序）／１＝（２）／１＝２
ＦｉｌｅＣ： 平均的順序＝ （シナリオ２順序）／１＝（１）／１＝１
【００８４】
ここで、ファイルＡは、シナリオ１によって最初に使用され、シナリオ２によって２番目に使用され、平均１．５などとなる。ファイルＣはＯｆｆｌｉｎｅファイルのうち最小の順序番号を持つので、最初に送られる。最後のファイル順序を以下に示す。必須（Ｒｅｑｕｉｒｅｄ）ファイル
ＦｉｌｅＥ
オフライン（Ｏｆｆｌｉｎｅ）ファイル
ＦｉｌｅＣ， ＦｉｌｅＡ， ＦｉｌｅＢ， Ｆｉｌｅ Ｄ
【００８５】
コード、コンポーネント、および「ビット」
以下のファイルおよびリソースは、拡張機能に付属させることができるが、必要というわけではない。このリストは、排他的ではなく、もちろん他のリソースを拡張機能に組み込むこともできる。
・　カスタマイズされたＵＩおよびキーボードショートカット
・　コンポーネント／ビヘイビア
・　ＸＭＬブラウズおよび編集コンポーネント（ＸＳＬおよびビジネスロジックオブジェクトを含む）
・　静的ページまたはその他のリソース
・　第三者定義カスタムコンテンツ
【００８６】
ユーザは、拡張機能を探しにネットワークサイトへナビゲートして拡張機能をインストールする。インターネット実施態様では、ユーザは適切なＵＲＬにナビゲートして拡張機能を探す。ホスティング管理者はさらに、拡張機能を「プッシュ」して、ユーザが適切なユーザの「プリファレンス」設定にエントリを追加することにより自動的に受け取るようにできる。
【００８７】
プラットフォームのセットアップと拡張機能のインストール
図１４は、前記実施形態によるセットアップおよび拡張機能インストールプロセスの複数のステップ例を説明する流れ図である。この例では、インターネットベースの例を説明する。図示の例では、さまざまなインターネットサイトに保持され、そこを通じてアクセス可能なさまざまな拡張機能がある。これらの拡張機能は、インターネットを介してクライアントに配布可能である。図に示されているコンピュータの分割は、必ずしも実在しているわけではないことは理解されるであろう。たとえば、コンピュータによって実現されているすべての機能を１つのマシンに常駐させたり、拡張機能をローカルに置いたり、あるいはプラットフォームおよび拡張機能を同一マシン上に配置するといったことが可能である。
【００８８】
この例では、３つの別々の「ゾーン」に関して流れ図が示されており、そのうち１つはクライアントを表し、もう１つは「プラットフォーム」インターネットサーバを表し、最後の１つは第三者インターネットサーバを表す。異なるゾーンに関して説明されている動作は、この例では、ゾーンに割り当てられたエンティティによって実行される。いくつかの構成では、これらのゾーンの１つまたは複数が重なっていてもよい。たとえば、プラットフォームサーバは拡張機能をサーバと同じデバイスであってよい。
【００８９】
ステップ１４００で、ユーザは後述の拡張機能インストールの基盤として使用されるソフトウェアプラットフォームと関連する特定のインターネットサイトにナビゲートする。ステップ１４０２で、ユーザは「インストール」ボタンをクリックし、ソフトウェアプラットフォームのインストールをユーザが望んでいることを示すメッセージをソフトウェアプラットフォームサーバに送る。このステップは、オプションステップとすることができる。ステップ１４０４および１４０５で、ソフトウェアプラットフォームと関連するソフトウェアをクライアントにダウンロードする。図示の例では、ステップ１４０４で、単一のナビゲーション可能ウィンドウアプリケーションのパッケージファイルをダウンロードし、ファイルのコンテンツに基づきステップ１４０５で他のコンポーネントおよびファイルをユーザのコンピュータにダウンロードする。ステップ１４０６で、ソフトウェアコードをクライアントマシン上にインストールし、アプリケーションキャッシュ、ローカルストア、およびプリファレンス用のローカルディレクトリを作成することができる。ただし、ローカルディレクトリまたはプリファレンスは必ずしも必要ないことは理解されるであろう。ステップ１４０８で、ソフトウェアプラットフォームが起動する。
【００９０】
上で説明したステップは、単一のナビゲーション可能ウィンドウアプリケーションのソフトウェアコードをクライアントマシンに配布しインストールするための初期セットアップと関連するステップである。後述のステップは、拡張機能インストールと関連する。
【００９１】
ステップ１４１０で、拡張機能と関連するリンクを使用して拡張機能にアクセスする。このステップでは、ユーザがブラウザで特定のインターネットサイトにナビゲートし、１つまたは複数の拡張機能にアクセスすることができる。それとは別に、リンクへの参照をユーザのプリファレンスまたはユーザが関連付けられているコンピューティンググループのプリファレンス内に配置することができる（たとえば、システム管理者がグループのプリファレンス内に参照を配置することができる）。このリンクは、第三者インターネットサーバまたはインターネットサイトに関連付けると有利である。ステップ１４１２で、ＥＤＦと関連付けられているＰＫＧに従って拡張機能ファイルをダウンロードする。ファイルはクライアントに配布され、ステップ１４１４で、拡張機能ファイルをＰＫＧ仕様により指定されているローカルストアに格納する。この時点で、拡張機能がインストールされ、ユーザはこの拡張機能によって提供される機能を利用することができる。ステップ１４１６で、拡張機能更新が利用できるかどうかを判別する。これは、定期的に拡張機能カタログ（下の「拡張機能カタログ」の項で説明する）をポーリングし、さまざま拡張機能の更新があるかどうかを確認するという形で行う。それとは別に、クライアントに更新を知らせる通知を自動的にクライアントに送ったり、または更新が利用できるかどうかを判別する他の方法を使用することもできる。更新が利用できる場合、ステップ１４１８はステップ１４１２に分岐し、更新と関連する拡張機能ファイルをダウンロードし、それらをクライアント上にインストールする。
【００９２】
拡張機能の開発
特定のソフトウェアプラットフォーム向けに拡張機能を開発する作業は、比較的直接的なプロセスである。開発者は、メモ帳などのツールやＶｉｓｕａｌ Ｓｔｕｄｉｏなどの他のツールを使用して拡張機能のコンテンツを開発する。その後、ＥＤＦおよびＰＫＧで拡張機能を記述し、ＰＫＧに電子署名を入れ、オプションによりこれを圧縮する。次いで特定のネットワークサーバ上で拡張機能をホスティングできる。
【００９３】
図１５は、前記実施形態による拡張機能開発方法の複数のステップを説明する流れ図である。特定の拡張機能を作成するソフトウェア開発者または組織はこれらのステップのうち１つまたは複数を実行できる。ステップのうちいくつかはソフトウェアで実施される。ステップ１５００で、拡張機能を開発する。拡張機能の開発に任意の適当なツールを使用できる。ステップ１５０２で、その拡張機能用の拡張機能定義ファイル（ＥＤＦ）を作成する。この例では、ＥＤＦは、上述のようにＸＭＬを使って定義されている。もちろん、ＥＤＦの記述に他の形式も使用できる。ステップ１５０４で、拡張機能用のパッケージマニフェスト（ＰＫＧ）を作成する。この例では、ＰＫＧは、上述のようにＸＭＬを使って定義されている。ステップ１５０６で、インターネットサーバなどのネットワークサーバ上でＥＤＦおよびＰＫＧのホスティングを行う。さらに、ＰＫＧに記述されている関連する拡張機能ファイルも、ネットワークまたはインターネットサーバでホスティングできる（ステップ１５０８）。上記を遂行したユーザは、次にＥＤＦに直接ナビゲートし（たとえば、関連するＵＲＬまたは他の何らかのネットワークアドレスを使用して）、必要なファイルをローカルでキャッシュし、拡張機能への参照をユーザのプリファレンス内に置くことにより拡張機能をインストールする。
【００９４】
特に、ステップ１５１０では、ＥＤＦおよびＰＫＧファイルをクライアントに配布する。このステップでは、ユーザが適切なファイルがホスティングされている特定のインターネットサイトにナビゲートし、ファイルをダウンロードすることができる。ステップ１５１２で、ＥＤＦおよびＰＫＧファイルと関連する拡張機能ファイルをクライアントに配布し、その後、インストールして使用できる。
【００９５】
拡張機能カタログ
図１４に関して簡単に説明されている最適化の一例では、拡張機能またはＥＤＦカタログでＥＤＦにあるレベルのインダイレクションを追加する。ＥＤＦカタログを使用すると、組織が拡張機能をグループ化し、拡張機能が変更された場合にそのことを判別するための単一の場所を用意することができる。所望の拡張機能は、ユーザの設定に基づきソフトウェアプラットフォームによりカタログから自動的に選択できる。カタログに対し、どの拡張機能がユーザに最も適しているかを判別する問合せを行うことができる。
【００９６】
前記の実施形態では、カタログは、言語、バージョン、またはその他の属性に基づき拡張機能のＵＲＮから１つまたは複数のパッケージのＵＲＮへのマッピングを含むＸＭＬファイルである。ただし、カタログは、任意の適当な形式を使用して定義できる。カタログには次のような機能を持たせることができる。
・　ホスティング組織が単一の場所で１つまたは複数のホスティングされている拡張機能に関するバージョン情報を更新することができる。
・　ユーザの設定に基づき正しいバージョンへのオプションの自動的インダイレクションを使用できる。たとえば、カタログに異なる言語に対する複数のバージョンの拡張機能をリストできる。カタログファイルは、ユーザの言語設定と一致するバージョンの拡張機能に対する変更を検索するように処理することができる。
・　新しいバージョンの拡張機能が利用できるようになったときにその新しいバージョンの拡張機能にオプションで自動的にアップグレードできる。
【００９７】
ＥＤＦと同様、カタログは、圧縮し、電子署名を入れることで、改ざんを防止することができる。カタログにサブスクライブして１つまたは複数のホスティングされた拡張機能に対する変更を検出することにより、拡張機能の更新を発見するためにクライアントから必要なサーバのｐｉｎｇの回数（またはクライアントへの通知）を減らすことができる。
【００９８】
図１６は、ＸＭＬカタログ構造の例を示している。カタログ内のエントリの構造は次のとおりである。
【００９９】
【表６】
2004512578.tif 000008
【０１００】
この特定の例では、次のとおりである。
・　ｎｅｔｄｏｃｓ−ｐｌａｎｎｅｒのデフォルト言語は、英語バージョンである。
・　デフォルト英語バージョンは１．１である。デフォルトフランス語バージョンは１．０である。プラットフォーム上でユーザの指定言語に利用できるバージョンがない場合、デフォルトで英語バージョン１．１を取得する。
・　英語バージョンのｎｅｔｄｏｃｓ−ｐｌａｎｎｅｒは、Ｖ１からＶｌ．１にアップグレードされている。
・　フランス語バージョンもある。拡張機能のＵＲＮは英語バージョンと同じである。フランス語バージョンには１．１リリースはなく、１．０がフランス語ユーザの最新バージョンである。
・　カタログに対し問合せを実行しても、言語がユーザの言語プリファレンスと一致する行のみが返される。また、言語がユーザの言語またはｄｅｆａｕｌｔ ＝ ｙｅｓ’のすべての行も返され、同じ名前の重複は捨てられる。
【０１０１】
アーキテクチャ
前記の実施形態では、望ましいユーティリティを備える態様の１つに、ソフトウェアプラットフォームの拡張性がある。つまり、第三者および第四者開発者は自由に、ソフトウェアプラットフォームのフレームワーク内で使用できる独自拡張機能を開発することができる。拡張機能は、ソフトウェアに直接統合され、プラットフォームの機能の変更は拡張機能によって行われる。拡張機能を備えるためには、開発者は単純に拡張機能をオーサリングし、ＥＤＦおよびＰＫＧに拡張機能を記述し、ネットワークサーバ上でＥＤＦ、ＰＫＧ、および関連ファイルをホスティングするだけであることに注意されたい。
【０１０２】
ＥＤＦは、上で指摘したように、ルートノード（つまり、「ｅｘｔｅｎｓｉｏｎ」タグ）および１つまたは複数の子ノードを含むＸＭＬスキーマで定義できる。この特定の例では、子ノードは、一般に、ソフトウェアプラットフォームに組み込むことが望まれている個々の拡張機能の機能タイプに対応する。たとえば、上の表１−３では、定義済みＸＭＬスキーマを使用して拡張機能により追加できるさまざまな定義済み機能タイプの例を説明していることに注意されたい。
【０１０３】
そこで、開発者は２つのメニューおよび１つのツールバーをソフトウェアプラットフォームに追加したいとする。メニューおよびツールバーは、顧客向けにＷｅｂサイトを保守している小売店と関連付けることができる。小売店では、Ｗｅｂサイトを訪れる顧客に、その小売店に独自のＵＩを見せたい場合があり、その店舗に合わせて特に手直ししたサービスを提供する。そのために、開発者は、２つの異なるメニューを開発し、その１つを一番最近の目玉商品を表示することと関連付け、もう１つを、ユーザが特定の商品を検索するための検索メカニズムを提供することと関連付けることができる。ツールバーは、その小売店に独自の固有のボタンを備えることができる。小売店の拡張機能用の”ｒｅｔａｉｌ． ｅｄｆ”という名前の簡単なＥＤＦをすぐ下に示す。
【０１０４】
2004512578.tif 000009
【０１０５】
ここで、外側の「ｅｘｔｅｎｓｉｏｎ」タグは、このＸＭＬファイルを拡張機能として指定している。内側の「ｍｅｎｕｓ」タグと「ｔｏｏｌｂａｒｓ」タグは、最上位タグであり、これらのタグ間の情報がそれぞれ、開発者が追加した拡張機能に対応するメニューとツールバーに関係することを示している。太字の「ｍｅｎｕ」タグと「ｔｏｏｌｂａｒ」タグは、実際の拡張機能に関するデータを記述し、上記の各拡張機能と関連するＵＲＬを含む。上のＥＤＦは、２つのメニューおよび１つのツールバーを含むように用意されている拡張機能を論理的に記述する。
【０１０６】
また、上のＥＤＦはシステムにロードされる多数のＥＤＦのうちの１つに過ぎないことも考慮されたい。各ＥＤＦは、１つまたは複数の最上位タグを含むことができ、それぞれソフトウェアプラットフォームに追加される１つまたは複数の特定の拡張機能に関連付けられている。
【０１０７】
図１７は、複数の異なるＥＤＦを処理するように構成されているソフトウェアアーキテクチャ例のブロック図であり、各特定の拡張機能をソフトウェアプラットフォームに組み込む役割を持つソフトウェアコンポーネントはその拡張機能に固有の適切な情報を受け取る。この例は、本書全体を通して説明しているＸＭＬ実施態様に固有のものである。請求項の主題の精神と範囲から逸脱することなく、後述のものと機能の面で似ている他のアーキテクチャを他の実施態様で使用できることを理解されたい。
【０１０８】
ここでアタッチメントポイントと呼んでいるユーティリティオブジェクトを使用して、複数のＥＤＦからの情報を処理する。アタッチメントポイントは、登録されているリスナーへのイベントを起動する単なるオブジェクトの収集であり、イベントの起動はオブジェクトをその収集に追加したり削除したりするときに行われる。多くの種類のアタッチメントポイントを作成できるが、すべてソース（多くの場合、他のアタッチメントポイント）からデータを取り出し、処理し（動的にまたは静的に）、その処理結果を公開する。最も単純なアタッチメントポイントとして次のものがある。
・　ＸＭＬファイルをロードし、ＸＭＬの最上位ノードをその収集内のオブジェクトとして公開するＸＭＬアタッチメントポイント。
・　他のアタッチメントポイントに接続し、そこから何らかの基準を満たすオブジェクトのみを公開するフィルタアタッチメントポイント。
・　１つまたは複数の他のアタッチメントポイントに接続し、そのすべてのオブジェクトをオブジェクトの１つのマージされた収集として公開するマージアタッチメントポイント。
【０１０９】
図示の例では、アーキテクチャには、ＥＤＦＨｕｂ １７００と呼ばれるファネル構造、アタッチメントポイントマネージャ１７０２、および複数のアタッチメントマネージャ１７０４を含む、１つまたは複数のアタッチメントポイントの収集が含まれる。ＥＤＦＨｕｂ １７００は、ＥＤＦのすべてを受け取り、それをマージして一緒にし、単一のリストとして公開する。他の個別アタッチメントポイントは、ＥＤＦＨｕｂ １７００によって公開される単一リストを操作する（フィルタ、マージ、および展開を含む）メカニズムを備える。新しい拡張機能またはＥＤＦをＥＤＦＨｕｂに追加したり削除したりした場合、さまざまなアタッチメントポイントが、適切なアタッチメントマネージャに通知するよう手配する。これは、適切なアタッチメントマネージャへのイベントを起動することにより行われる。アタッチメントポイントマネージャ１７０２は、システム内のさまざまなアタッチメントポイントの作成、破棄、および管理を行い、同一のアタッチメントポイントの再利用を簡単に行えるようになっている。
【０１１０】
各最上位タグ（つまり、「ｍｅｎｕｓ」タグと「ｔｏｏｌｂａｒｓ」タグ）について、アタッチメントポイントによって提供されるデータを使用してソフトウェアプラットフォーム内に特定の機能タイプを組み込む、対応するアタッチメントマネージャ１７０４がある。各アタッチメントマネージャは、１組のアタッチメントポイントをアタッチメントポイントマネージャ１７０２に要求する。これらは、ＥＤＦＨｕｂ １７００によって公開されているデータを操作する。図示の例では、アタッチメントポイントは、アタッチメントポイントマネージャがＥＤＦＨｕｂ １７００によって公開されるデータに作用する１組のアタッチメントポイントを作成し構築するために使用する述語チェーン（ｐｒｅｄｉｃａｔｅ ｃｈａｉｎ）として要求できる。
【０１１１】
図１８は、前記実施形態による方法の複数のステップを説明する流れ図である。この方法は、ソフトウェアで、またこの例では図１７のソフトウェアコンポーネントにより実施される。
【０１１２】
ステップ１８００は、複数のＥＤＦを受け取る。それらのファイルは、任意の適当な方法で受け取ることができる。たとえば、ユーザはオンラインになったときにロードしたい特定の拡張機能をそのプリファレンス内で指定することができる。それとは別に、ユーザは、動的に拡張機能を追加するように構成されているソフトウェアプラットフォームをユーザが実行中であることを認識する特定のインターネットサイトへのリンクを使用してナビゲートすることができる。この例では、ＥＤＦは、アタッチメントポイントを使用してＥＤＦを組み合わせる（ステップ１８０２）ＥＤＦＨｕｂ １７００に流し込まれる。この例では、ＥＤＦは、ＸＭＬファイルとして定義され、ノードは単一のＸＭＬリストに組み合わされる。ステップ１８０４は、組み合わされたＥＤＦを公開する。この特定の例では、ＥＤＦは、さらにそのデータを操作する（ステップ１８０６）さまざまな他のアタッチメントポイントに公開される単一のＸＭＬリストに組み合わされる。アタッチメントポイントの１つの目標は、拡張機能をシステムに追加したりシステムから削除したりするごとにアタッチメントマネージャ１７０４がシステム全体に繰り返し問合せを行うのを回避することである。したがって、拡張機能を追加または削除する場合、アタッチメントポイントにより、拡張機能の特定の追加または削除が該当するアタッチメントマネージャ１７０４にのみ通知されるようにする。たとえば、ＥＤＦがメニューの追加を指示している場合、メニューと関連するアタッチメントマネージャだけに通知される。したがって、ステップ１８０８で、アタッチメントマネージャの要件と合致する新しいデータが該当するアタッチメントマネージャに通知される。
【０１１３】
アタッチメントポイントとアタッチメントポイントマネージャ
アタッチメントポイントは、順序付けられたオブジェクトの収集を公開し、新規オブジェクトが挿入または削除されたときに通知を起動するオブジェクトである。システム例では、オブジェクトはＸＭＬノードであるが、どのような種類のオブジェクトでもかまわない。アタッチメントポイントはさまざまな種類のものがあるが、すべて次のような類似のプロセスに従う。
１）　最初に１つまたは複数のデータソースに接続する。これらは、ファイルまたは、一般に、その他のアタッチメントポイントとすることができる。
２）　何らかのロジックに基づきデータを処理する。通常、このロジックはまったく単純なもので、何らかの基準に基づきオブジェクトをフィルタ処理するような操作を伴う場合がある。
３）　新しいオブジェクトの収集で処理ステップ２の結果を公開する。
４）　オブジェクトの公開された収集がどのように変更されたか（ＯｎＩｎｓｅｒｔｅｄ（ｉｎｄｅｘ，ｃｏｕｎｔ）またはＯｎＲｅｍｏｖｅｄ（ｉｎｄｅｘ，ｃｏｕｎｔ）を示すイベントを起動する。
５）　オプションにより、データソースの変更に注意し続け、変更が発生したときにステップ２−４を繰り返す。
【０１１４】
ただ、それぞれのアタッチメントポイントは極めて単純であるが、異なる種類のアタッチメントポイントを組み合わせて「チェーン」を形成したときに、一方のアタッチメントポイントで第２のアタッチメントポイントからのデータを処理する場合、この処理は極めて強力なものとなる可能性がある。特に、アタッチメントポイントがステップ２で変更されたデータを処理するだけの場合、一度に少量の単純な作業をこなすだけなので、このことは正しい。システム例では、このインクリメンタル処理により、新しい拡張機能をインストールしたとき、または既存の拡張機能を削除したときに、システム全体に再度問合せを行う必要がないことを示している。さらに、システム例の各アタッチメントマネージャでは、特定のアタッチメントポイントのチェーンを使用するため、拡張可能な領域に影響を及ぼす変更を通知するだけである。
【０１１５】
アタッチメントポイントマネージャは、アタッチメントポイントのチェーンを構築するときに２つの重要な機能を実行する。１つは、チェーンを述語文字列として記述する機能である。アタッチメントポイントマネージャは、それらの文字列を解釈し、アタッチメントポイントの必要なチェーンを構築する。もう１つは、同一のアタッチメントポイントを再利用する機能であり、これによりシステムの効率が高まる。アタッチメントポイントマネージャがアタッチメントポイントの各チェーンを作成するときに、どの述語文字列がどのアタッチメントポイントに対応するかを追跡する。その述語文字列が後で再び要求された場合に、新規に作成せずに既存のアタッチメントポイントを簡単に再利用する。
【０１１６】
たとえば、メニューと関連するアタッチメントマネージャが上のｒｅｔａｉｌ．ｅｄｆファイルを利用するアタッチメントポイントの次のような述語チェーンを要求したとする（注：この例では、ＥＤＦＨｕｂアタッチメントポイントの存在を仮定していない）。
【０１１７】
Ｅｘｐｌｏｄｅ（Ｆｉｌｔｅｒ（”ｍｅｎｕｓ”， Ｅｘｐｌｏｄｅ （ＵＲＬ （”ｒｅｔａｉｌ．ｅｄｆ”））））
【０１１８】
この文字列は、ｒｅｔａｉｌ．ｅｄｆファイル内のすべてのメニューを表す。ｒｅｔａｉｌ．ｅｄｆに置かれているＸＭＬファイルは、ＸＭＬファイルのルートノードをその収集内の唯一のオブジェクトとして公開するＵＲＬアタッチメントポイントによりロードされる。内側のエクスプロードアタッチメントポイントでは、ＵＲＬアタッチメントポイントをそのデータソースとして使用し、ソース収集内にあるオブジェクトのすべての子を公開する。この場合、ルートノードの子は、最上位のＸＭＬタグ「ｍｅｎｕ」および「ｔｏｏｌｂａｒｓ」である。フィルタアタッチメントポイントでは、エクスプロードアタッチメントポイントをそのデータソースとして使用し、「ｍｅｎｕｓ」であるノードのみを探す公開されているオブジェクトをフィルタ処理する。外側のエクスプロードアタッチメントポイントでは、フィルタアタッチメントポイントをそのデータソースとして使用し、フィルタ処理されたメニューノードのすべての子を公開し、拡張機能によって追加された２つのメニューを含むリストを出力する。この特定のＸＭＬファイルにはメニューアタッチメントマネージャと関連するアタッチメントポイントにより識別されたメニューが含まれているため、そのアタッチメントマネージャは、拡張機能により２つのメニューが追加されたことを通知される。
【０１１９】
このプロセスは、図式的に図１９に示されているが、アタッチメントポイント１９００、１９０２、１９０４、および１９０６を示している。各アタッチメントポイントは、ＸＭＬノードのリストを公開する。ＵＲＬアタッチメントポイント１９００は入力（ＸＭＬファイル−たとえば、ｒｅｔａｉｌ．ｅｄｆ−へのＵＲＬ）を受け取り、ＸＭＬノードのリストを公開する。このリストには、ルートノード「＜ｅｄｆ：ｅｘｔｅｎｓｉｏｎ＞」のみが含まれる。エクスプロードアタッチメントポイント１９０２は入力としてアタッチメントポイント１９００を受け取り、ソースＸＭＬノードの子であるＸＭＬノードのリストを公開する。この例では、アタッチメントポイント１９０２によって公開されたＸＭＬノードのリストは、「＜ｍｅｎｕｓ＞」ノードと「＜ｔｏｏｌｂａｒｓ＞」ノードである。フィルタアタッチメントポイント１９０４はアタッチメントポイント１９０２を入力として受け取り、「ｍｅｎｕｓ」でフィルタ処理する。次に、「＜ｍｅｎｕｓ＞」ノードのみを含むＸＭＬリストを公開する。エクスプロードアタッチメントポイント１９０６は入力としてアタッチメントポイント１９０４を受け取り、「＜ｍｅｎｕｓ＞」ノード−ここでは「＜ｍｅｎｕ＞」ノードの両方−に含まれるＸＭＬノードを含むリストを公開する。
【０１２０】
さらに、ツールバーアタッチメントマネージャが、ＵＲＬアタッチメントポイント、エクスプロードアタッチメントポイント、および「ｔｏｏｌｂａｒｓ」でフィルタ処理するフィルタアタッチメントポイント１９０４も使用するアタッチメントポイントの述語チェーンを要求することを考える。したがって、対応するエクスプロードアタッチメントポイント１９０６は「＜ｔｏｏｌｂａｒ＞」ノードのみを含むＸＭＬリストを公開する。しかし、アタッチメントポイントマネージャでは、ＵＲＬアタッチメントポイントと内側エクスプロードアタッチメントポイントの共通性を検出し、メニューアタッチメントマネージャに対し作成したのと同じアタッチメントポイントを再利用する。ツールバーアタッチメントマネージャとメニューアタッチメントマネージャによって使用されるフィルタアタッチメントポイントは、そのデータソースと同じエクスプロードアタッチメントポイントを使用するが、それらは異なる基準に基づいてフィルタ処理を行っていたため異なるノード収集を公開する。
【０１２１】
ＥＤＦＨｕｂアタッチメントポイント２０００を組み込む図２０を考察する。このアタッチメントポイントは、上述のように、ＥＤＦのすべてを受け取り、それを組み合わせて単一のＸＭＬリストにする。次にＥＤＦＨｕｂは、すべてのＥＤＦのルートノードを公開する。エクスプロードアタッチメントポイント２００２は、すべてのＥＤＦの最上位ノードのすべてを含むＸＭＬリストを公開する。たとえば、それぞれが最上位メニューノード、ツールバーノード、アクセラレータノードなどを含む複数のＥＤＦが考えられる。エクスプロードアタッチメントポイント２００２は、すべてのＥＤＦのそれらの最上位ノードのすべてを含むＸＭＬリストを公開する。次にフィルタアタッチメントポイント２００４は、任意の適当なパラメータに従ってエクスプロードアタッチメントポイント２００２により公開されているＸＭＬリストをフィルタ処理できる（つまり、メニューノード、ツールバーノード、アクセラレータノードなどでフィルタ処理する）。最後のエクスプロードアタッチメントポイント２００６では、フィルタアタッチメントポイント２００４により公開されたリストの個々の子ノードのリストを公開する。このリストには、すべてのＥＤＦによって追加された特定の機能（フィルタ処理された特定の種類の）すべてが記述されている。
【０１２２】
以下の表は、前記実施形態により利用できるが、さらに多くを容易に作成できるいくつかの異なるアタッチメントポイントを一覧にしたものである。
【０１２３】
【表７】
2004512578.tif 000010
【０１２４】
結論
上述の実施形態では、第三者開発者が容易に理解できる一貫性のある論理的な拡張性メカニズムとオブジェクトモデルを通じてカスタマイズ機能と拡張性を実現するプラットフォームソリューションを提供している。インターネットベースでダウンロードを実行するのに、ユーザの介入はほとんど必要なく、しかもユーザの永続的設定の操作も無用である。ユーザのコンピューティング状況に基づき動的に、拡張機能をソフトウェアプラットフォームまたはアプリケーションプログラムに付加することができる。
【０１２５】
本発明は構造的機能および／または方法論的ステップに固有の言語で説明されているが、付属の請求項で定義されている発明は、説明した特定の機能またはステップに必ずしも限られないことは理解されるであろう。むしろ、特定の機能およびステップは請求されている発明を実施する好ましい形態として開示されている。
【図面の簡単な説明】
【図１】
記載の一実施形態により利用できるシステムの高水準の図である。
【図２】
前記実施形態により利用できるコンピュータシステム例の図である。
【図３】
記載の一実施形態によるＥＤＦおよびＰＫＧの例の図である。
【図４】
前記実施形態によるＥＤＦの一部の図である。
【図５】
前記実施形態によるＥＤＦスキーマの一部の図である。
【図６】
前記一実施形態によるＰＫＧの一部の図である。
【図７】
一実施形態によりファイルハッシュをバージョニングに使用する方法を示すブロック図である。
【図８】
一実施形態により２つのパッケージオブジェクト例を示すブロック図である。
【図９】
記載の一実施形態による方法の複数のステップを説明する流れ図である。
【図１０】
記載の一実施形態による方法の複数のステップを説明する流れ図である。
【図１１】
記載の一実施形態によるパッケージマニフェスト作成ツール例を示すブロック図である。
【図１２】
記載の一実施形態による方法の複数のステップを説明する流れ図である。
【図１３】
記載の一実施形態による方法の複数のステップを説明する流れ図である。
【図１４】
前記実施形態による方法の複数のステップの流れ図である。
【図１５】
前記実施形態による方法の複数のステップの流れ図である。
【図１６】
前記実施形態によるカタログ構造例の一部の図である。
【図１７】
前記実施形態によるソフトウェアアーキテクチャのブロック図である。
【図１８】
前記実施形態による方法の複数のステップの流れ図である。
【図１９】
前記実施形態によるアタッチメントポイントアーキテクチャの一態様を示す図である。
【図２０】
図１７のアーキテクチャの一態様を示す図である。
【図１】
2004512578.tif 000011
【図２】
2004512578.tif 000012
【図３】
2004512578.tif 000013
【図４】
2004512578.tif 000014
【図５】
2004512578.tif 000015
【図６】
2004512578.tif 000016
【図７】
2004512578.tif 000017
【図８】
2004512578.tif 000018
【図９】
2004512578.tif 000019
【図１０】
2004512578.tif 000020
【図１１】
2004512578.tif 000021
【図１２】
2004512578.tif 000022
【図１３】
2004512578.tif 000023
【図１４】
2004512578.tif 000024
【図１５】
2004512578.tif 000025
【図１６】
2004512578.tif 000026
【図１７】
2004512578.tif 000027
【図１８】
2004512578.tif 000028
【図１９】
2004512578.tif 000029
【図２０】
2004512578.tif 000030
【国際公開パンフレット】
2004512578.tif 000031
2004512578.tif 000032
2004512578.tif 000033
2004512578.tif 000034
2004512578.tif 000035
2004512578.tif 000036
2004512578.tif 000037
2004512578.tif 000038
2004512578.tif 000039
2004512578.tif 000040
2004512578.tif 000041
2004512578.tif 000042
2004512578.tif 000043
2004512578.tif 000044
2004512578.tif 000045
2004512578.tif 000046
2004512578.tif 000047
2004512578.tif 000048
2004512578.tif 000049
2004512578.tif 000050
2004512578.tif 000051
2004512578.tif 000052
2004512578.tif 000053
2004512578.tif 000054
2004512578.tif 000055
2004512578.tif 000056
2004512578.tif 000057
2004512578.tif 000058
2004512578.tif 000059
2004512578.tif 000060
2004512578.tif 000061
2004512578.tif 000062
2004512578.tif 000063
2004512578.tif 000064
2004512578.tif 000065
2004512578.tif 000066
2004512578.tif 000067
2004512578.tif 000068
2004512578.tif 000069
2004512578.tif 000070
2004512578.tif 000071
2004512578.tif 000072
2004512578.tif 000073
2004512578.tif 000074
2004512578.tif 000075
2004512578.tif 000076
2004512578.tif 000077
2004512578.tif 000078
2004512578.tif 000079
2004512578.tif 000080
2004512578.tif 000081
2004512578.tif 000082
2004512578.tif 000083
2004512578.tif 000084
2004512578.tif 000085
2004512578.tif 000086
2004512578.tif 000087
2004512578.tif 000088
2004512578.tif 000089
2004512578.tif 000090
2004512578.tif 000091
2004512578.tif 000092
2004512578.tif 000093
2004512578.tif 000094
2004512578.tif 000095
2004512578.tif 000096
2004512578.tif 000097
2004512578.tif 000098
2004512578.tif 000099
2004512578.tif 000100
2004512578.tif 000101
2004512578.tif 000102
2004512578.tif 000103
2004512578.tif 000104
2004512578.tif 000105
2004512578.tif 000106
2004512578.tif 000107
2004512578.tif 000108
2004512578.tif 000109