JP6900421B2 - ウェブサイト構築システムのための装置 - Google Patents

Description

本発明は、オンラインアプリケーションと、特に、含まれるサードパーティアプリケーションと組み合わせての使用方法とに関する。

ウェブサイトおよび他のオンラインアプリケーションを作成および編集する目的に使用することのできる数多くのウェブサイト構築システムや、その他の対話型のアプリケーション構築ツールが市販されている。エンドユーザは、通常のパーソナルコンピュータ、スマートフォン、タブレット、および他のデスクトップまたはモバイルデバイスなどの幅広いプラットフォーム上のクライアントソフトウェアを使用して、このようなウェブサイトにアクセスすることができる。

これらのウェブサイト構築システムは、さまざまな形態で提供され、例えば、インターネットに接続されている１つまたは複数のサーバ上でホストされ、ＨＴＴＰ（ハイパーテキスト転送プロトコル）などのインターネット通信プロトコルを使用してアクセスされる完全にオンラインのウェブサイト構築システムなどである。これらのウェブサイト構築システムの作成、編集、およびデプロイは、すべてサーバによる直接的なオンライン動作によって実行される。

ウェブサイト構築システムは、部分的にオンラインとする、または完全にオンラインとすることもできる。部分的にオンラインのシステムの場合、ウェブサイトの編集をユーザのマシン上でローカルに実行し、後から中央の１つまたは複数のサーバにアップロードしてデプロイする。ウェブサイトがアップロードされると、これらのウェブサイト構築システムは、完全にオンラインのウェブサイト構築システムと同じように機能する。

ウェブサイト構築システムは、システム内のデータおよび要素を体系化する目的で、内部のデータアーキテクチャを有する。このアーキテクチャは、ユーザから見える対象のサイトの外観とは異なることがあり、さらに、一般的なＨＴＭＬ（ハイパーテキストマークアップ言語）ページがブラウザに送られる方式とも異なることがある。例えば、内部のデータアーキテクチャは、ページ上の各要素の追加のプロパティ（作成者、作成日時、アクセス許可、テンプレートへのリンクなど）を含むことができ、これらの追加のプロパティは、ウェブサイト構築システム内でサイトを編集および維持管理するうえで欠かせないものであるが、外部のエンドユーザ（場合によっては編集を行う一部のユーザ）には見えない。ウェブサイト構築システムに基づくサイトの一般的なアーキテクチャは、コンポーネント（例えば、形状コンポーネント、写真コンポーネント、テキストコンポーネントのほか、ミニページを含むシングルページコンテナおよびマルチページコンテナなど）を含むページから構成することができる。

コンポーネントは、内部コンテンツを持たない星形などのコンテンツレスとすることができ（ただし色、大きさ、位置、およびその他の属性は有する）、あるいは、テキストパラグラフコンポーネントなど内部コンテンツを有することができ、このようなコンポーネントの内部コンテンツには、表示されるテキストに加えて、フォント、書式、レイアウトの情報が含まれる。当然ながら、このコンテンツは、テキストパラグラフコンポーネントごとに異なりうる。

このようなウェブサイト構築システムを使用するデザイナーは、何もない状態から新しいサイトをデザインする（空白の画面から開始する）、または、デザイナー自身、システムクリエーター、またはデザイナーのコミュニティによって作成された事前定義されたアプリケーションテンプレートを利用することができる。ウェブサイト構築システムは、単なるコンポーネントの集合であるテンプレート、完全なページ（またはミニページ）または一連のページであるテンプレート、および完全なウェブサイトであるテンプレートをサポートすることができる。

アプリケーションのテンプレートが提供されるときには、デザイナーは、それを自由にカスタマイズすることができ、テンプレートのすべての要素の追加、削除、または修正を行って、デザイナー自身のテンプレートのバージョンを作成する。このようなカスタマイズは、テンプレートの修正されたバージョン（テンプレートとは異なる個別のバージョン）を作成することによって実施することができる。あるいは、ウェブサイト構築システムが、継承型メカニズム（inheritance-type mechanism）を通じてカスタマイズを適用することができ、継承型メカニズムは、元のテンプレートへのリンクを維持し、したがってテンプレートに対して後から行われる変更が反映される。

さらに、ウェブサイト構築システムは、サードパーティアプリケーションおよびその中に埋め込まれているコンポーネントを使用して、拡張することができる。このようなサードパーティアプリケーションは、ウェブサイト構築システムのデザイン環境に含まれていることがあり、または、さまざまな配布機構を通じて、例えばウェブサイト構築システムに組み込まれているアプリケーションストア（ＡｐｐＳｔｏｒｅ）から、またはウェブサイト構築システム（ＷＢＳ）のベンダーまたは別の組織によって運営されているウェブベースまたは独立したアプリケーションリポジトリ（またはＡｐｐＳｔｏｒｅ）から、個別に購入する（または他の方法で取得する）ことができる。さらに、サードパーティアプリケーションは、サードパーティアプリケーションのベンダーから（ＡｐｐＳｔｏｒｅを通じて、または通じずに）直接取得することもでき、この場合、ベンダーは、実際のインストールモジュールを提供する、またはアクティベーションコードまたはアクセスコードのみを提供する。

サードパーティアプリケーションには、フロントエンド（表示）要素とバックオフィス要素の任意の組合せ（これらはウェブサイトには表示されない）が含まれることがある。サードパーティアプリケーションは、全体がバックオフィスである（すなわち表示要素を含まない）、または全体がフロントエンドである（すなわちウェブサイトで使用されるときのみ起動される）、または２つの組合せであることがある。

サードパーティアプリケーションのバックオフィス要素には、データベース通信オプションや外部更新オプションなどの機能が含まれることがある。例えば、ブログのサードパーティアプリケーションには、人以外の発信元（例えば、大手のニュースサービスからのＲＳＳニュース配信）からと、ウェブサイトに関係ない人の発信元（例えば、ブログエントリを投稿できるスタンドアロンのスマートフォンアプリケーション）から、更新を受信することのできるバックオフィス要素が含まれることがある。

サードパーティアプリケーションの視覚要素を、それらが含められるウェブサイトに組み込む処理は、さまざまな方法で行うことができる。ウィジェットタイプのサードパーティアプリケーションは、ウェブサイトのページの内側にコンポーネントとして埋め込むことができるのに対して、セクションタイプのサードパーティアプリケーションは、ウェブサイトに１つまたは複数の追加のページとして加えることができる。

さらには、サードパーティアプリケーション（ウィジェットタイプおよびセクションタイプの両方）は、シングルページのサードパーティアプリケーション、またはマルチページのサードパーティアプリケーション（内部ＵＲＬ構造として表される内部ミニページを有する）とすることができる。システムは、４つの可能な組合せ（ウィジェットまたはセクション、シングルページまたはマルチページ）のうちの１つまたは複数、あるいはすべてを実装することができる。

マルチページのサードパーティアプリケーションは、通常ではデフォルトの「ランディング」ミニページを提供し、このミニページは、オープニングページ、特定の内部のミニページ（例えばブログのサードパーティアプリケーションにおける最新のブログエントリ）、ミニページ選択画面、またはその他のミニページである。

ウェブサイト構築システムに基づくウェブサイトにおけるサードパーティアプリケーションの使用は、サードパーティアプリケーションのインスタンスを通じて行われる。ウェブサイト構築システムは、複数のレベルにおけるサードパーティアプリケーションの複数の使用法をサポートすることができ、例えば、ウェブサイト全体においてサードパーティアプリケーションの１つのインスタンスを許可する、ウェブサイトの内側で複数のサードパーティアプリケーションのインスタンスを作成することを許可する（ただし１つのサードパーティアプリケーションあたり１つのインスタンスのみ）、複数のサードパーティアプリケーションの複数のインスタンスを作成することを許可する（ただし１ページあたり１つのインスタンスのみ）が挙げられる。さらに、コンポーネント型サードパーティアプリケーション（セクションタイプのサードパーティアプリケーションではない）のページあたり複数のインスタンスを許可することもでき、さらに、サードパーティアプリケーションのインスタンスの数、多重度、または位置の制限なしに、複数のサードパーティアプリケーションの複数のインスタンスを作成することを許可することもできる。

サードパーティアプリケーションのインスタンスは、インスタンスに固有なコンテンツを有することができる。例えば、オンラインショップ（e-Shop）のサードパーティアプリケーションは、特定のインスタンスに関連付けられる製品データベースを有することができ、この製品データベースは、（同じサイトまたは別のサイト内の）同じオンラインショップのサードパーティアプリケーションの別のインスタンスに関連付けられる製品データベースとは異なる。

説明を目的として、サードパーティアプリケーションおよびそのミニページや要素を含むウェブサイトページ（またはミニページ）（すなわち「ラッパーページ」）は、含有ウェブページ（containing web page）と称するものとし、ウェブサイト全体にメインサイトとして既知であるものとする。ユーザに示される統合されたページ（メインページおよび埋め込まれたＴＰＡミニページ／コンポーネントを含む）を、合成ページと称する。セクションタイプのサードパーティアプリケーションの場合、サードパーティアプリケーションを含む「仮想ページ」が、含有ウェブページの役割を果たす。

サードパーティアプリケーションは、通常では、ウェブサイト構築システムのベンダーのサーバ上、サードパーティアプリケーションのベンダーのサーバ上、外部（フォースパーティ）のサーバ上、またはこれらのサーバの任意の組合せ上にデプロイされる。サードパーティアプリケーションは、エンドユーザのマシン上で実際に実行される要素（例えば、静的にインストールされるブラウザエクステンションや、図１に示したようにウェブサイト構築システムのクライアント側コードの内側で動的に実行されるＪａｖａＳｃｒｉｐｔ（登録商標）コンポーネントなど）も含むことができる。以下ではこの図１を参照する。

ウェブサイト構築システムのベンダーのサーバは、エンドユーザのための連絡口として機能し、要求に応答する（場合によってはサードパーティアプリケーションのベンダーのサーバに接続して必要な情報を受け取る）。ウェブサイト構築システムは、例えばビデオストリーミングが要求されるとき、クライアントのコンピュータとサードパーティアプリケーションのベンダーのサーバとの間に（必要に応じて）直接的な接続を形成することができる。

含まれているサードパーティアプリケーションのインスタンスは、通常のコンポーネントが内部コンテンツを含むのと同様に、自身の内部コンテンツを有することができる。図２を参照し、この図に示したように、サードパーティアプリケーションは、ウェブサイト構築システムと、ウェブサイト構築システムを使用して生成されたウェブサイトとは無関係に、このコンテンツを管理することができる。１つまたは複数のサードパーティアプリケーションの複数のインスタンスは、共有コンテンツを有することができ、例えば、２つの個別のウェブサイトページにおける２つのオンラインショップのインスタンスが、同じ製品データベースを参照することができる。

含まれているサードパーティアプリケーションからの出力は、例えば以下のようなさまざまな方法で、含有ウェブページに組み込むことができる。

サーバ側の処理： （以下では図３を参照する。）図３に示したこの方法においては、サードパーティアプリケーション［ａ］（デザイン要素および表示要素を含む）と、ユーザに固有なサードパーティアプリケーションのデータ［ｂ］とが、サードパーティアプリケーションのベンダーのサーバ［ｄ］上で実行されているサードパーティアプリケーションのサーバコード［ｃ］によってマージされる。これらは通信媒体［ｅ］を介してウェブサイト構築システムのサーバコード［ｆ］に送られ、サーバコード［ｆ］は、これらを含有ウェブページの情報［ｇ］とマージした後、これらをユーザのクライアントステーション［ｈ］に表示できるように送る。

クライアント側の処理： （以下では図４を参照する。）図４に示したこの方法においては、サードパーティアプリケーション［ａ］（デザイン要素および表示要素を含む）と、ユーザに固有なサードパーティアプリケーションのデータ［ｂ］とが、サードパーティアプリケーションのベンダーのサーバ［ｄ］上で実行されているサードパーティアプリケーションのサーバコード［ｃ］によってマージされる。これらは通信媒体［ｅ］を介してクライアント側の処理コンポーネント［ｈ］に送られる。ウェブサイト構築システムのサーバコード［ｆ］は、含有ウェブページの情報［ｇ］を、このクライアント側の処理コンポーネント［ｈ］に送る。クライアント側の処理コンポーネント［ｈ］は、２つの情報源のマージを実行し、統合されたアプリケーションをブラウザ（または他のクライアントエージェント）［ｉ］に提示する。

ｉＦｒａｍｅのインクルージョン（inclusion）： （以下では図５を参照する。）図５に示した方法においては、サードパーティアプリケーション［ａ］（デザイン要素および表示要素を含む）と、ユーザに固有なサードパーティアプリケーションのデータ［ｂ］とが、サードパーティアプリケーションのベンダーのサーバ［ｄ］上で実行されているサードパーティアプリケーションのサーバコード［ｃ］によってマージされる。これらは、ユーザエージェント（例えばウェブブラウザ）［ｉ］の内側で実行されているブラウザベースのアプリケーション［ｈ］に、通信媒体［ｅ］を介して送られる。ウェブサイト構築システムのサーバコード［ｆ］は、含有ウェブページの情報［ｇ］を、このブラウザベースのアプリケーション［ｈ］に送る。含有ウェブページは、サードパーティアプリケーションのサーバ［ｄ］からのコンテンツを含める１つまたは複数のｉｆｒａｍｅディレクティブを含むウェブページとして作成される。追加の方法および代替方法も適用可能である。

米国特許出願第１３／７７１，１１９号

本発明の好ましい実施形態によると、ウェブサイト構築システムのための装置が提供される。本装置は、少なくとも１つのサードパーティアプリケーションのウェブサイトのインスタンスを含むページを作成するためのページコンポーザと、ページと少なくとも１つのサードパーティアプリケーションとの間、または少なくとも１つのサードパーティアプリケーションと少なくとも１つの別のサードパーティアプリケーションとの間の双方向通信バックチャネルを定義するための構成器（configurer）と、を含む。さらに、本装置は、ページが閲覧またはアクセスされるときに通信バックチャネルに従って通信を調整するためのコーディネータを含む。

さらに、本発明の好ましい実施形態によると、本装置は、クライアント上に実装可能である。

さらに、本発明の好ましい実施形態によると、本装置はサーバ上に実装可能である。

さらに、本発明の好ましい実施形態によると、通信バックチャネルは、ＨＴＭＬ５（ハイパーテキストマークアップ言語５）のＰｏｓｔＭｅｓｓａｇｅ、メッセージのＵＲＬフラグメント識別子、専用の通信ウェブサービス、ＨＴＭＬ５のローカルストレージ、ＨＴＭＬ５のローカルファイルシステムアクセスＡＰＩ、専用のブラウザプラグインのうちの少なくとも１つである。

さらに、本発明の好ましい実施形態によると、コーディネータは、ｉｆｒａｍｅを使用してページに埋め込まれている。

さらに、本発明の好ましい実施形態によると、少なくとも１つのサードパーティアプリケーションは、ｉｆｒａｍｅを使用してページに埋め込まれる。

さらに、本発明の好ましい実施形態によると、少なくとも１つのサードパーティアプリケーションは、マルチパートサードパーティアプリケーションとモジュール式サードパーティアプリケーションのうちの少なくとも一方である。

さらに、本発明の好ましい実施形態によると、コーディネータは、事前定義された少なくとも１つのサードパーティアプリケーションのインスタンスを監視するための構成マネージャを含む。

さらに、本発明の好ましい実施形態によると、コーディネータは、通信の発信元または発信先のシンボリックアドレスおよび絶対アドレスを識別および変換するためのスマート識別子／アドレッサ（smart identifier and addresser）を含む。

さらに、本発明の好ましい実施形態によると、コーディネータは、ウェブサイト構築システムと少なくとも１つのサードパーティアプリケーションとの間の通信ポリシーを適用する通信ポリシーエンフォーサを含む。

さらに、本発明の好ましい実施形態によると、コーディネータは、少なくとも１つのサードパーティアプリケーションへの通信メッセージ、および少なくとも１つのサードパーティアプリケーションからの通信メッセージを、ウェブサイト構築システム内で経路変更するリダイレクタを含む。

さらに、本発明の好ましい実施形態によると、コーディネータは、少なくとも１つのサードパーティアプリケーションからの入力メッセージの信頼性を確認する発信元確認器を含む。

さらに、本発明の好ましい実施形態によると、コーディネータは、ウェブサイト構築システムと少なくとも１つのサードパーティアプリケーションとの間、およびサードパーティアプリケーションと少なくとも１つの別のサードパーティアプリケーションとの間のプロトコル互換性問題を解決するためのプロトコル変換器を含む。

さらに、本発明の好ましい実施形態によると、コーディネータは、ページと少なくとも１つのサードパーティアプリケーションとの間、少なくとも１つのサードパーティアプリケーションとページとの間、少なくとも１つのサードパーティアプリケーションと少なくとも１つの別のサードパーティアプリケーションとの間、のうちの少なくとも１つの間で動的レイアウト変更を更新するための動的レイアウト更新器を含む。

さらに、本発明の好ましい実施形態によると、コーディネータは、ウェブサイト構築システムのグローバル属性、少なくとも１つのサードパーティアプリケーションの制御許可、ページの要素のレイアウト、スタイルおよびコンテンツ、のうちの少なくとも１つを更新するための更新器を含む。

本発明の好ましい実施形態によると、ウェブサイト構築システムのための装置が提供され、本装置は、外部の取得元からウェブサイト構築システムの少なくとも１つのテンプレートを受信するサードパーティアプリケーションの受信器であって、サードパーティアプリケーションがウェブサイト構築システムの少なくとも１つのテンプレートに関連付けられる、サードパーティアプリケーションの受信器、を含む。さらに、本装置は、少なくとも１つのサードパーティアプリケーションのインスタンスがウェブサイトページ内に作成されるときに、テンプレートをそのページ内にインストールするためのインストーラ、を含む。

さらに、本発明の好ましい実施形態によると、本装置は、サーバおよびクライアントの少なくとも一方に実装可能である。

さらに、本発明の好ましい実施形態によると、テンプレートは編集可能である。

さらには、本発明の好ましい実施形態によると、テンプレートは、ウェブサイト構築システムのコンポーネントとマルチパートサードパーティアプリケーションのうちの少なくとも一方を含む。

さらに、本発明の好ましい実施形態によると、ウェブサイトページは、既存のページ、既存のミニページ、新たに作成されるページ、新たに作成されるミニページ、のうちの少なくとも１つである。

さらに、本発明の好ましい実施形態によると、受信器は、参照整合性を維持し、少なくとも１つのサードパーティアプリケーションとページとの間のインタフェース解決（interface resolution）を実行する。

本発明の好ましい実施形態によると、ウェブサイト構築システムのための方法が提供される。本方法は、少なくとも１つのサードパーティアプリケーションのウェブサイトのインスタンスを含むページを作成するステップと、ページと少なくとも１つのサードパーティアプリケーションとの間、または少なくとも１つのサードパーティアプリケーションと少なくとも１つの別のサードパーティアプリケーションとの間の双方向通信バックチャネルを定義するステップと、を含む。さらに、本方法は、ページが閲覧またはアクセスされるときに通信バックチャネルに従って通信を調整するステップを含む。

さらに、本発明の好ましい実施形態によると、少なくとも１つのサードパーティアプリケーションは、マルチパートサードパーティアプリケーションとモジュール式サードパーティアプリケーションの少なくとも一方である。

さらに、本発明の好ましい実施形態によると、調整するステップは、事前定義された少なくとも１つのサードパーティアプリケーションのインスタンスを監視するステップ、を含む。

さらに、本発明の好ましい実施形態によると、調整するステップは、通信の発信元または発信先のシンボリックアドレスおよび絶対アドレスを識別および変換するステップ、を含む。

さらに、本発明の好ましい実施形態によると、調整するステップは、ウェブサイト構築システムと少なくとも１つのサードパーティアプリケーションとの間の通信ポリシーを適用するステップ、を含む。

さらに、本発明の好ましい実施形態によると、調整するステップは、少なくとも１つのサードパーティアプリケーションへの通信メッセージ、および少なくとも１つのサードパーティアプリケーションからの通信メッセージを、ウェブサイト構築システム内で経路変更するステップ、を含む。

さらに、本発明の好ましい実施形態によると、調整するステップは、少なくとも１つのサードパーティアプリケーションからの入力メッセージの信頼性を確認するステップ、を含む。

さらに、本発明の好ましい実施形態によると、調整するステップは、ウェブサイト構築システムと少なくとも１つのサードパーティアプリケーションとの間、およびサードパーティアプリケーションと少なくとも１つの別のサードパーティアプリケーションとの間のプロトコル互換性問題を解決するステップ、を含む。

さらに、本発明の好ましい実施形態によると、調整するステップは、ページと少なくとも１つのサードパーティアプリケーションとの間、少なくとも１つのサードパーティアプリケーションとページとの間、少なくとも１つのサードパーティアプリケーションと少なくとも１つの別のサードパーティアプリケーションとの間、のうちの少なくとも１つの間で動的レイアウト変更を更新するステップ、を含む。

さらに、本発明の好ましい実施形態によると、調整するステップは、ウェブサイト構築システムのグローバル属性、少なくとも１つのサードパーティアプリケーションの制御許可、ページの要素のレイアウト、スタイルおよびコンテンツ、のうちの少なくとも１つを更新するステップ、を含む。

さらに、本発明の好ましい実施形態によると、更新するステップは、スタイルシートをカスケード処理するステップ、を含む。

本発明の好ましい実施形態によると、ウェブサイト構築システムのための方法が提供される。本方法は、外部の取得元からウェブサイト構築システムの少なくとも１つのテンプレートを受信するステップであって、サードパーティアプリケーションがウェブサイト構築システムの少なくとも１つのテンプレートに関連付けられる、ステップ、を含む。さらに、本方法は、少なくとも１つのサードパーティアプリケーションのインスタンスがウェブサイトページ内に作成されるときにテンプレートをページ内にインストールするステップ、を含む。

さらに、本発明の好ましい実施形態によると、テンプレートは編集可能である。

さらに、本発明の好ましい実施形態によると、テンプレートは、ウェブサイト構築システムのコンポーネントとマルチパートサードパーティアプリケーションのうちの少なくとも一方を含む。

さらに、本発明の好ましい実施形態によると、ウェブサイトページは、既存のページ、既存のミニページ、新たに作成されるページ、新たに作成されるミニページ、のうちの少なくとも１つである。

さらに、本発明の好ましい実施形態によると、受信するステップは、参照整合性を維持し、少なくとも１つのサードパーティアプリケーションとページとの間のインタフェース解決を実行する。

本発明とみなされる主題は、本明細書の結論部分に具体的に指摘して明確に記載してある。しかしながら、添付の図面を参照しながら以下の詳細な説明を読み進めることによって、本発明について、その編成および動作方法の両方に関してと、本発明の目的、特徴、および利点とを、深く理解することができる。

ウェブサイト構築システムとサードパーティアプリケーションとの間のデプロイ構成の概略図 サードパーティアプリケーションの内部コンテンツ管理の概略図 サーバ側の処理によって含有ウェブページにサードパーティアプリケーションを含めるときの概略図 クライアント側の処理によって含有ウェブページにサードパーティアプリケーションを含めるときの概略図 ｉｆｒａｍｅのインクルージョンによって含有ウェブページにサードパーティアプリケーションを含めるときの概略図 ページレイアウトの変更時における既存の非最適なサードパーティアプリケーションの表示の概略図 本発明に従って構築されて動作する、ウェブサイト構築システムと１つまたは複数のサードパーティアプリケーションとを統合するシステムの概略図 本発明に従って構築されて動作する、ウェブサイト構築システムと１つまたは複数のサードパーティアプリケーションとを統合するシステムの概略図 コンポーネントモデルと比較してのドキュメントオブジェクトモデルの概略図 ブログのマルチパートサードパーティアプリケーションの例の概略図 販売用のモジュール式サードパーティアプリケーションの例の概略図 本発明に従って構築されて動作する通信ハブの異なる実装の概略図 本発明に従って構築されて動作する通信ハブの異なる実装の概略図 本発明に従って構築されて動作する図１１Ａおよび図１１Ｂの通信ハブの要素の概略図 本発明に従って構築されて動作する図１１Ａおよび図１１Ｂの通信ハブによって実行される通信変換処理の概略図 本発明に従って構築されて動作する、関連付けられるテンプレートを有するサードパーティアプリケーションを扱う含有ウェブページの概略図 本発明に従って構築されて動作する、関連付けられるテンプレートを有するサードパーティアプリケーションをミニページの内側に含む含有ウェブページの概略図

図を簡潔かつ明瞭にするため、図面に示した要素は必ずしも正しい縮尺で描かれていないことを理解されたい。例えば、明瞭さのため、いくつかの要素の寸法が別の要素よりも誇張されていることがある。さらに、適切と考えられる場合、複数の図面において対応する要素または類似する要素を同じ参照数字によって表してある。

以下の詳細な説明においては、本発明を完全に理解できるようにする目的で、膨大な具体的な細部を記載してある。しかしながら、これらの具体的な細部なしでも本発明を実施できることが、当業者には理解されるであろう。さらには、本発明が曖昧になることがないように、周知の方法、手順、およびコンポーネントについては、詳細には説明していない。

出願人は、サードパーティアプリケーションが一般にウェブサイト構築システムに統合される現在の方法と、統合されたサードパーティアプリケーションとウェブサイト構築システムとが対話する現在の方法には、多くの制限が存在することを認識した。

このような制限としては、サードパーティアプリケーションの表示が、含有ウェブページの内側の１つの長方形領域（この領域はｉｆｒａｍｅに含まれる）に制限されることが挙げられる。さらなる制限として、サードパーティアプリケーションのウィンドウのサイズおよび位置と、サードパーティアプリケーションの実際の表示ウィンドウの外側である視覚要素（例えば、サードパーティアプリケーションのウィンドウの周囲の専用の表示フレーム）を、サードパーティアプリケーションが制御する能力が挙げられる。

サードパーティアプリケーションは、自身の表示スタイル（配色、フォント、文字サイズなど）を有しうる。これらのスタイルは、いくつかの含有ウェブページには適合するが、別の含有ウェブページでは視覚的に問題があったり調和しないことがある。

別の制限は、含有サイトの観点からのサードパーティアプリケーションの表示に柔軟性がないことである。（例えば、画面サイズの異なるプラットフォームにデプロイするため、あるいは動的レイアウトイベントに起因して）サイトを視覚的に修正しなければならない場合、サードパーティアプリケーションに割り当てられているウィンドウのサイズを変更するように含有ウェブページに要求されることがある。このような場合、サードパーティアプリケーションの表示が途中で切り取られ、サードパーティアプリケーションにおけるさまざまなサブ領域に達するためにはスクロールバーを介してスクロールすることが要求される。図６を参照し、この図は、含有ウェブページ［ａ］をリサイズしたときに起こりうる状況の例を示している。オンラインショップのサードパーティアプリケーション［ｂ］に割り当てられる領域が減少し、「購入」ボタン［ｃ］を、ショッピングカート［ｄ］の内容と一緒に表示させることができないため、購入を完了するためには何回かのスクロール操作が要求され、実際に購入が完了される可能性が大幅に減少する。

サードパーティアプリケーションは含有ウェブページ内の別のコンポーネントと対話することができず、複雑な機能を達成するためにはこのような対話が必要となりうることを理解されたい。特に、サードパーティアプリケーションは、含有ウェブページ内のコンポーネントのタイプおよびコンテンツに従って異なる動作を実行することはできない。この１つの例は、オンライン料理教室をストリーミングするウェブサイトである。ユーザは、動画を観ているバックグラウンドにおいて、画面の別の領域に、最新のニュースおよび天気情報（例えばＣＮＮからのライブストリームなど）を配信するための専用の小さい画面領域を表示させたいことがある。ユーザは、自分が住む地域の天気予報が始まったときに、学習セッションを自動的に一時停止させることを望むことがある。

さらには、特に、複数のサードパーティアプリケーションが異なるベンダーによって提供されている場合、これらのサードパーティアプリケーションが互いに協力するための明確かつ標準的な方法は存在しない。したがって、デザイナーには、異なるベンダーからの複数のサードパーティアプリケーションを組み合わせる明確な方法がない。この１つの例は、サードパーティの発注システムのモジュールと、出荷システムの異なるモジュールとを実行する電子商取引のウェブサイトの場合である。出荷スケジュールなどに従って商品を発注することが望ましいことがある。

出願人は、ウェブサイト構築システムと、その中に含まれるサードパーティアプリケーションインスタンスとの間と、同じ含有ページ内に実装することのできる複数の異なるサードパーティアプリケーションインスタンスの間の、構造化された双方向通信チャネルを使用することによって、この統合を達成できることを認識した。これらのチャネルは、レイアウト、スタイル、および追加の情報に関する情報を転送することもできる。

以下の説明は、ｉｆｒａｍｅインクルージョン法に焦点を当てており、この方法は、最近のブラウザに内蔵されたり統合されたりしており、専用の統合コードを作成する必要がないため、好ましい方法であることを理解されたい。さらに、ｉｆｒａｍｅインクルージョン法では、ブラウザによってサポートされるカプセル化およびサンドボックス機能が提供されるほか、悪意のあるサードパーティアプリケーションによって採用されうるクロスサイトスクリプティング攻撃などのハッキング技術に対する本質的な保護も提供される。

次に、図７Ａおよび図７Ｂを参照し、これらの図は、本発明の実施形態による、ウェブサイト構築システムと１つまたは複数のサードパーティアプリケーションとを統合するシステム１００を示している。図７Ａは、デザイン段階におけるシステム１００を示しており、図７Ｂは、実行時におけるシステム１００を示している。図７Ａにおいて理解できるように、システム１００は、クライアント１０と、ウェブサイト構築システム（ＷＢＳ）サーバ２０にインストールされているウェブサイト構築システム３０と、１つまたは複数のサードパーティアプリケーションサーバ５０にインストールされている１つまたは複数のサードパーティアプリケーション４０とを備えている。ウェブサイト構築システム３０は、ＷＢＳコーディネータ２１と、アプリケーションリポジトリ２２と、ＷＢＳ側ＴＰＡプロパティシート２３と、サードパーティアプリケーション（ＴＰＡ）コーディネータ２４と、ＡｐｐＳｔｏｒｅ ２５（サーチャー２６を含むことができる）とを備えている。クライアント１０は、ページコンポーザ１２と、ＴＰＡプロパティシート２３のクライアント側表示とを備えている。いくつかの実施形態においては、クライアント１０は、ＡｐｐＳｔｏｒｅ ２５のクライアント側表示をさらに備えていることができる。ページコンポーザ１２は、後からさらに詳しく説明するリンカ１３を備えている。サードパーティサーバ５０は、サードパーティアプリケーション４０と、外部ＴＰＡコーディネータ５１と、ＴＰＡデータベース５２とを備えており、ＴＰＡデータベース５２は、サードパーティアプリケーション４０のコンポーネントやテンプレートなどを使用できるように格納している。なお、システム１００は、サードパーティアプリケーション４０の複数のベンダーに属する複数のサードパーティサーバ５０を含むことができる。

ＴＰＡプロパティシート２３は、サードパーティアプリケーション４０のインスタンスの属性が指定されるときに呼び出すことができることを理解されたい。さらには、呼び出されたとき、ＴＰＡプロパティシート２３は、クライアント１０においてはＴＰＡプロパティシート２３のクライアント側表示として表示されることを理解されたい。さらには、オフラインの実施形態は、インストールされているクライアントソフトウェアの一部として自身のプロパティシートを有することができ、したがって、アプリケーションＴＰＡプロパティシート２３やリポジトリは存在しないことを理解されたい。

クライアント１０の前に座っているデザイナーまたはエンドユーザ５は、ページコンポーザ１２を使用してウェブサイトページおよび対話（インタラクション）（ページ間対話およびページ内対話）を作成することで、自身のウェブサイト（または他のオンラインアプリケーション）を作成することができることを理解されたい。デザイナー５は、アプリケーションリポジトリ２２に格納されている、ウェブサイト構築システム３０の一部であるコンポーネントやテンプレートなどを、ＷＢＳコーディネータ２１を介して選択することができる。さらに、デザイナー５は、サードパーティアプリケーション４０からのサードパーティアプリケーション４０インスタンスを埋め込む含有ウェブページ２０３を作成することができ、サードパーティアプリケーション４０は、あらかじめ購入することができ、そのテンプレートやコンポーネントなどをアプリケーションリポジトリ２２に格納しておくことができる。代替実施形態においては、購入したテンプレートやコンポーネントなどは、ＴＰＡデータベース５２に格納しておき、外部ＴＰＡコーディネータ５１を介してアクセスすることができる。さらに別の実施形態においては、サードパーティアプリケーション４０のテンプレートやコンポーネントなどを、必要に応じてＡｐｐＳｔｏｒｅ ２５を介して購入することができる。プロパティシート２３は、デザイナー５によって指定することができ、後からさらに詳しく説明するように、購入したサードパーティアプリケーション４０のインスタンスに関する情報（許可、インストールガイド、支払いなど）を保持することができる。さらに、デザイナー５は、リンカ２３を使用して、含まれる複数のサードパーティアプリケーション４０の間の通信チャネル（必要な場合）を手操作で指定することができる。さらに、デザイナー５は、リンカ２３を使用することで、構築している含有ウェブページと、そこに含まれるサードパーティアプリケーション４０のインスタンスとの間の固有の通信接続および規則を指定できることを理解されたい（上述したように動画やＣＮＮニュースレポートが同時に表示されるなど）。リンカ２３によって作成されたリンクは、ウェブサイトが存続している限り修正できることを理解されたい。

デザイナー５は、サードパーティアプリケーション４０のベンダーまたは外部業者によって運営されている外部のＡｐｐＳｔｏｒｅなど、ＡｐｐＳｔｏｒｅ ２５の外部のチャネルを通じて、サードパーティアプリケーション４０を取得することができることを理解されたい。このような場合、ウェブサイト構築システム３０は、デザイナー５によってウェブサイト構築システム３０を通じて作成されたウェブサイトにそのサードパーティアプリケーション４０を最初にインストールするときに、サードパーティアプリケーション４０およびその構成データ（configuration data）を登録することができる。

必要な場合にリンカ２３が通信チャネルを確立できるようにするためには、サードパーティアプリケーション４０は、（自身が通信しようとする）含有ウェブページ２０３内のコンポーネント（別のサードパーティアプリケーション４０のインスタンスを含む）を正しく認識および識別できる必要があることを理解されたい。関連付けられるテンプレートに基づくコンポーネント（後からさらに詳しく説明する）の場合、この識別は、サードパーティアプリケーション４０のベンダーによってあらかじめ実行される。関連付けられるテンプレート内のコンポーネントには、固有の参照ＩＤを与えることができ、サードパーティアプリケーション４０は、これらのコンポーネントと通信するときに、これらのＩＤを使用することができる。

さらに、（後からさらに詳しく説明する）マルチパートサードパーティアプリケーション４０（すなわち複数のｉｆｒａｍｅにわたり分散する１つのサードパーティアプリケーション４０）の場合、複数のパートは、互いに通信する方法を自動的に認識することができることを理解されたい。

関連付けられるテンプレートに含まれていない、含有ウェブサイトページのコンポーネント（後からさらに詳しく説明する）については、サードパーティアプリケーション４０は、自身が機能するために存在しているべき要求される（必須またはオプションの）含有ウェブページ２０３のコンポーネントのリストを含むことができる。このリストは、プロパティシート２３の中に格納することができ、一意のＩＤと、説明と、コンポーネントの詳細（例えば、テキストコンポーネントでなければならない、ブログの応答（talkback）ラベルとして使用される）とを含むことができる。このリストは、ＡｐｐＳｔｏｒｅ ２５へのサードパーティアプリケーション４０のエントリに列挙することができ、デザイナー５は、サードパーティアプリケーション４０の要件を満たす含有ウェブページ２０３の中のコンポーネント（フィールド）を、リンカ２３を使用して指定することができる。ウェブサイト構築システム３０は、サードパーティアプリケーション４０のインスタンスが作成されたときに、含有ウェブページ２０３の不足しているコンポーネントを動的に作成することができ、デザイナー５は、後からこれらのコンポーネントを移動する、リサイズする、および完全に指定することができることを理解されたい。

これに代えて、ウェブサイト構築システム３０は、含有ウェブページ２０３のコンポーネントモデル全体または一部を、含有ウェブページ２０３に含まれるサードパーティアプリケーション４０に公開することができる。この場合のコンポーネントモデルは、含有ウェブページ２０３のコンポーネントモデルであり、ドキュメントオブジェクトモデル（ＤＯＭ）ではないことを理解されたい。含有ウェブページ２０３のドキュメントオブジェクトモデル（ＤＯＭ）は、コンポーネントモデルよりもずっと複雑かつ詳細なモデルであることがあり、なぜなら実際の含有ウェブページ２０３には、ウェブサイト構築システム３０のインフラストラクチャの一部である、または含有ウェブページ２０３のコンポーネントをサポートする、膨大なＨＴＭＬ要素（非表示要素および可視要素の両方）が含まれうるためである。したがって、コンポーネントモデルはずっと単純である。

次に、図８を参照し、図８は、複数のＨＴＭＬコンストラクト（一部を囲むｄｉｖタグ［ｂ］、内部ｄｉｖタグ［ｃ］、フレーム「ミニウィジェット」［ｄ１］．．［ｄ５］など）を使用してテキストコンポーネント［ａ］を実装する方法を示している。含有ウェブページ２０３のＤＯＭモデル［ｅ］は、これらのサブ要素それぞれに対する個別のＤＯＭツリーノードを含むことができる。コンポーネントモデル［ｆ］はずっと単純にすることができ、１つのコンポーネントノード［ｇ］のみを含む。

システム１００は、選択的なコンポーネントの公開をサポートすることもでき、デザイナー５は、どのコンポーネントをサードパーティアプリケーション４０に公開するべきかをリンカ２３を介して指定することができ、これらのコンポーネント（場合によってはこれらのコンポーネントに通じる「含有経路（containment path）」を含む）のみを、サードパーティアプリケーション４０から可視である単純化されたコンポーネントモデルに含めることができることを理解されたい。この指定は、含まれているコンポーネントを、それらのタイプや、ウェブサイト構築システム３０の他の属性に従って、明示的にマークすることによって実行することができる。これにより、サードパーティアプリケーション４０は、含有ウェブページ２０３のコンポーネントモデルをたどって、要求されるコンポーネントを特定することができる。

さらに、含有ウェブページ２０３とサードパーティアプリケーション４０のインスタンスとの間のリンク（例えばブロードキャストリンク）を自動的に作成することもでき、ブロードキャストリンクでは、サードパーティアプリケーション４０は、実行時に通信を送って特定のイベントを記録することができることを理解されたい。この通信は、オプションまたは必須とすることができる（すなわちサードパーティアプリケーション４０は、このようなメッセージを受信するためにリンクされている対応するサードパーティアプリケーション４０が存在しない限り、機能しない、またはインストールしない）。例えば、サードパーティアプリケーション４０は、自身が実行する動作・機能に関する情報パケットをブロードキャストすることができ、インストールされているロギングのサードパーティアプリケーション４０は、これらの情報パケットを受信することができる。

このようにして設定が完了した新たに作成されたページは、後からさらに詳しく説明するように、実行時に呼び出すことができるように、（ＷＢＳコーディネータ２１を介して）アプリケーションリポジトリ２２に格納しておくことができる。

次に、図７Ｂを参照する。この実施形態においては、要素は、クライアント１０の要素を除いて、図７Ａにおける要素と同じである。実行時、クライアント１０は、含有ウェブページ２０３を表示するためのビューア２０１を備えている。ビューア２０１は、それぞれがサードパーティアプリケーション４０の異なるインスタンス（１つまたは複数のサードパーティアプリケーション４０から派生するインスタンス）を表示させるための複数のビューポート２０２を備えていることができることを理解されたい。さらに、クライアント１０は通信ハブ２０５を備えており、通信ハブ２０５は、通信を促進するものであり、含有ウェブページ２０３と、含有ウェブページ２０３がホストしているサードパーティアプリケーション４０との間のバックチャネルと、ホストされている複数のサードパーティアプリケーション４０の間で要求される通信とを、関連する含有ウェブページ２０３に接続することなく、提供する。ハブ２０５の機能については、後からさらに詳しく説明する。

ハブ２０５はクライアント１０に実装することができ、なぜなら、含有ウェブページ２０３とサードパーティアプリケーション４０のインクルージョンの両方が、可視のウェブサイトの対話部分であり、これらの通信を、クライアントとサーバの間の往復によって遅延させるべきではないためであることを理解されたい。代替実施形態においては、サードパーティアプリケーションサーバ５０が大量のデータを交換する必要があり、これらのデータをクライアント１０を経由させないことが好ましい場合、ハブ２０５を、ウェブサイト構築システムのサーバ２０に実装することができる。

通信ハブ２０５は、ウェブサイト構築システム３０と１つまたは複数のサードパーティアプリケーション４０との間の通信と、複数のサードパーティアプリケーション４０の間の通信のさまざまな組合せをサポートすることができることを理解されたい。例えば、ハブ２０５によって、サードパーティアプリケーション４０が、メインサイト内の別のページに切り替えるようにウェブサイト構築システム３０に要求することが可能になる。さらに、通信ハブ２０５によって、サードパーティアプリケーション４０が、自身のウィンドウをリサイズする（場合によっては含有ページのレイアウトに影響しうる）ように要求することが可能になる。このリサイズは、後からさらに詳しく説明する動的レイアウト処理を通じて行うことができる。あるいは、（例えば）表示の変更に対応するためにはサードパーティアプリケーション４０が別のバージョンに切り替えることが要求される場合、含有ウェブページ２０３は、この切り替えを要求することができる。この双方向通信は、サードパーティアプリケーション４０のコンポーネントと、サードパーティアプリケーション４０に関連するウェブサイト構築システム３０の（追加の情報を表示する）コンポーネントとの間と、上述したようにマルチパートサードパーティアプリケーション４０の要素とモジュール式サードパーティアプリケーションとの間に、確立することもできることを理解されたい。

さらに、システム１００は、オンラインおよびオフラインのウェブサイト構築システム３０の両方を使用して実装することもでき、また、システム１００は、ホスティング方法（例えば、クライアント側要素、ウェブサイト構築システム３０のベンダーのサーバ、サードパーティアプリケーション４０のベンダーのサーバ、他のフォースパーティのサーバなど）の任意の組合せを使用できることを理解されたい。上述したオフラインの実施形態の場合であっても、サーバはシステム１００を実装することが要求されうることを理解されたい。

さらに、システム１００は、大きな組織におけるプライベートサイトホスティングシステムなど、（ウェブサイト構築システムのベンダーによって運営されていない）別のサーバセット上でホストすることもできる。

さらに、システム１００は、上述したサードパーティアプリケーション４０からのインスタンスのインクルージョンオプションのすべてをサポートすることができる。しかしながら、システム１００は、これらのオプションのサブセットのみをサポートすることもでき、あるいは、サードパーティアプリケーション４０のインスタンスのインクルージョンオプションに制限を課すことができる。

さらに、システム１００は、マルチパートサードパーティアプリケーション４０を実装することもできる。マルチパートサードパーティアプリケーション４０は、それぞれが個別のｉｆｒａｍｅを使用して処理される複数の表示領域を含むことができる。これらの領域は、後からさらに詳しく説明するように、通信ハブ２０５を通じて（必要に応じて）協力することもできる。

次に、図９を参照し、この図は、マルチパートサードパーティアプリケーション４０の例を示している。図示したように、ＡｐｐＳｔｏｒｅ［ｂ］から取得されたブログのサードパーティアプリケーション［ａ］が、含有ウェブページ２０３［ｃ］に配置されている。ブログのサードパーティアプリケーション［ａ］は、３つの領域、すなわち、ブログエントリ領域［ｄ］と、タグクラウド領域［ｅ］と、ニュース更新領域［ｆ］とを含む。マルチパートサードパーティアプリケーションは、自身の複数の領域をさまざまな方法で使用することができ、例えば、（上のブログの例におけるように）１つのアプリケーションの同時に存在する複数の部分として、あるいは、１つのアプリケーションのオプションとして存在する複数の部分（つねに表示される複数の領域と、要求されるときにのみ表示されるオプションの複数の領域とを含む）として、使用することができることを理解されたい。オプションの領域の表示は、サードパーティアプリケーション４０によって、または（サードパーティアプリケーションを含めるときにそれをどのように構成するかを決定する）デザイナー５によって、制御することができる。さらに、表示は、構成領域や追加ダイアログ領域などのサポート機能領域として制御することもできる。代替として、（例えば、サードパーティアプリケーションのスモールバージョンおよびラージバージョンを有する、またはサードパーティアプリケーションのポートレートバージョンおよびランドスケープバージョンを有する）マルチバージョンのサードパーティアプリケーションの表示についても同様である。

上述した機能は、サードパーティアプリケーション４０の要素の表示にｉｆｒａｍｅを使用して実装することができ、したがって、ｉｆｒａｍｅベースのアーキテクチャのカプセル化およびセキュリティの利点が得られることを理解されたい。

さらに、マルチパートサードパーティアプリケーション４０を実装するには、（それぞれのｉｆｒａｍｅの内側の）サードパーティアプリケーション４０が、さまざまなｉｆｒａｍｅの表示（例えば、ｉｆｒａｍｅの可視性、サイズ、位置）を制御できることが要求される。さらに、後からさらに詳しく説明するように、通信ハブ２０５によって、この表示を可能にできることを理解されたい。

さらに、マルチパートサードパーティアプリケーション４０が（視覚的に）複数の要素および領域からなるときでも、（例えばＡｐｐＳｔｏｒｅ ２５における）購入、インストール、設定などの点において、このアプリケーション４０は依然として１つのサードパーティアプリケーション４０とみなされることを理解されたい。

既存のシステムにおいては、サードパーティアプリケーション４０それぞれが個別のエンティティとみなされ、（同じベンダーからの、または提携しているベンダーからの）２つのサードパーティアプリケーション４０の間の協力関係は、ケースバイケースでシステムごとに開発しなければならない。システム１００は、個別に購入およびインストールすることのできる協力する複数のサブモジュールからなるモジュール式サードパーティアプリケーション４０をサポートすることもできることを理解されたい。

次に、図１０を参照し、この図は、販売管理のモジュール式サードパーティアプリケーション［ａ］が、サブモジュールとして、顧客管理（ＣＲＭ）モジュール［ｂ］と、リードマネージメントモジュール［ｃ］と、電子商取引モジュール［ｄ］とを、どのように含むことができるかを示している。この１つのサードパーティアプリケーションのベンダーは、必要なサードパーティアプリケーションモジュールすべてを提供することができる。これに代えて、サードパーティアプリケーションのベンダーは、サードパーティアプリケーション４０のモジュール（および機能）のサブセットを提供することができ、デザイナーは、補足的なサードパーティアプリケーションモジュールを、同じかまたは別のサードパーティアプリケーションベンダーから購入してインストールすることができる。マルチパートサードパーティアプリケーションは、１つのベンダーからの１つのサードパーティアプリケーションとして取得およびインストールされるのに対して（マルチパートサードパーティアプリケーションは複数の画面領域を占有するにすぎない）、モジュール式サードパーティアプリケーションは、個別に取得およびインストールすることのできる複数のモジュールを含み、場合によっては複数のサードパーティアプリケーションベンダーからのモジュールを含むことを理解されたい。複数のベンダーからの複数のサードパーティアプリケーションモジュールを統合できるようにするためには、サードパーティアプリケーションモジュールそれぞれが、自身が必要とするインタフェース／機能と、自身が提供するインタフェース／機能のリストを提供しなければならない。リストの提供は、例えば、ドットで区切られた階層的な名前表記法に基づくインタフェース名のリスト（例えば、Ｍｙ＿ＣＲＭ＿ＴＰＡ．ＮｅｗＣｌｉｅｎｔ．ＧｅｔＩｎｆｏ）と、インタフェースパラメータの指定を使用することによって、行うことができる。

サードパーティアプリケーション４０のモジュールは、必須として要求されるインタフェース（すなわちそれがないとモジュールが機能しないインタフェース）、またはオプションとして要求されるインタフェース（すなわちそれがなくてもモジュールは機能するが提供される機能が制限されたり変化するインタフェース）を指定することができる。したがって、各インタフェースに提供されるパラメータは、一意のインタフェース名、インタフェースの説明（デザイナー５が（例えば）不足しているインタフェースによって扱われる機能を認識できるようにデザイナー５に示される）、必須／オプションのステータス、インタフェースパラメータのリストおよびタイプである。サードパーティアプリケーションモジュールそれぞれは、依然として個別のｉｆｒａｍｅ（またはｉｆｒａｍｅのセット）に属すことを理解されたい。インタフェースの動作は、後からさらに詳しく説明する通信チャネルに基づく。

サードパーティアプリケーション４０のモジュールは、ウェブサイトのデザイン段階においてアセンブルすることができることを理解されたい。ウェブサイト構築システム３０は、サードパーティアプリケーション４０の追加モジュールが追加されるため、インタフェース参照（interface references）を解決することができ、この場合、サードパーティアプリケーション４０の新しいモジュールが既存の必要なインタフェースを解決するが、場合によっては新しい（解決されていない）必要なインタフェースを追加する。

さらに、デザイナー５は、必須（およびオプションの）インタフェースが依然として解決していない間に、完成したウェブサイトを編集して実行することができることを理解されたい。しかしながら、デザイナー５は、必須のインタフェースすべてが解決されるまでは、作成したウェブサイトを公開することはできず、解決していない必須のインタフェースを依然として有するサードパーティアプリケーションモジュールをハブ２０５が起動することを要求する機能を試みると、メッセージが表示される。

さらに、ＡｐｐＳｔｏｒｅ ２５は、要求されるサードパーティアプリケーションモジュールのインタフェースを解決するサードパーティアプリケーションモジュールを特定することを試みるサーチャー２６を備えていることができることを理解されたい。サーチャー２６は、特定のサードパーティアプリケーションモジュールまたはすべてのサードパーティアプリケーションモジュールを、解決されていないインタフェースに基づいて検索することができる。さらに、サーチャー２６は、現時点で解決していないインタフェース、またはすでに解決したインタフェースに基づいて検索することができ、さらには、必須のインタフェース、オプションのインタフェース、または両方のタイプのインタフェースに基づいて検索することができる。さらに、サーチャー２６を、特定のサードパーティアプリケーションの解決していないインタフェースを解決することと、特定のサードパーティアプリケーションベンダーを検索することに限定することができることを理解されたい。サーチャー２６は、第１のレベルの検索（すなわち現時点で解決されていないインタフェースを満たすモジュール）、または複数レベルの検索（すなわち反復検索を実行し、前の検索によって見つかったサードパーティアプリケーションモジュールを考慮するときに加わる解決していないインタフェースを満たすモジュールも探す）のいずれかを実行することができる。

システム１００は、インタフェースの説明を使用して、いくつかの不足しているインタフェースを提供することの重要性に関する情報をデザイナー５に提供することができる。ハブ２０５は、依然として通信する必要のある非互換性のサードパーティアプリケーションの間のインタフェース変換を提供することができる。この変換は、ウェブサイト構築システム３０の供給元または外部業者によって追加されるアダプタモジュールによって行うことができ、アダプタモジュールは、要求される指定のインタフェースを別のフォーマットに適合させる。

さらに、システム１００をオンラインアプリケーション編集システムに適用することができ、オンラインアプリケーション編集システムは、インターネット（または任意の別のネットワーク接続）と、ブラウザではないクライアント側ソフトウェアを使用して、作成されたオンラインアプリケーションを表示させる。このようなシステムでは、通常のウェブインフラストラクチャによって使用される特定の技術（例えば、ＩＰ通信、ＨＴＴＰ、ＨＴＭＬなど）を使用する必要がない。

この技術分野において公知である標準的なクロスドメイン通信方法を使用して、クロスドメイン通信を容易にすることができることを理解されたい。クロスドメイン通信方法としては以下が挙げられる。

ＨＴＭＬ５ ＰｏｓｔＭｅｓｓａｇｅ： ＨＴＭＬ５の標準的な機能であり、この機能を使用することで、安全なクロスドメインメッセージングを提供することができる。ＨＴＭＬ５ Ｗｉｎｄｏｗｓ．Ｐｏｓｔｍｅｓｓａｇｅを使用すると、たとえ異なるドメインに属していても、ウィンドウ、ｉｆｒａｍｅ、およびメインＨＴＭＬドキュメントの間で安全にメッセージを送ることができる。ＰｏｓｔＭｅｓｓａｇｅでは、送信側ｉｆｒａｍｅがメッセージの送信先のドメインを指定するためのツールと、受信側ｉｆｒａｍｅがメッセージの送信元のドメインを確認するためのツールが提供される。

メッセージのＵＲＬフラグメント識別子： この方法では、ＵＲＬフラグメント識別子を使用して、１つのエンドポイントから別のエンドポイントにメッセージデータを送る。データをプレーンテキストに符号化し、ターゲットのエンドポイントドメインにおけるサービス、またはターゲットのエンドポイントｉｆｒａｍｅの内側の非表示ｉｆｒａｍｅを呼び出すために使用されるＵＲＬに、（フラグメント識別子として）加える。フラグメント識別子を、ターゲットのサービスまたはｉｆｒａｍｅにおけるコードによって復号化する。

専用の通信ウェブサービス： ウェブサイト構築システム３０は、ウェブサイト構築システムのサーバ２０上でホストされる専用ウェブを提供する。さまざまな通信エンドポイントがこのサーバに接続し、メッセージを送る、あるいは待機中のメッセージがないかチェックする。この方法は、ｐｒｅ−ＨＴＭＬ５ Ｃｏｍｅｔセットオブテクノロジ、ＨＴＭＬ５ベースのＷｅｂＳｏｃｋｅｔ、または任意の他のキューイング、ポーリング、サーバプッシュ、または類似する手法など、この技術分野において公知の方法によって行うことができる。

ＨＴＭＬ５のローカルストレージ： ＨＴＭＬ５では、構造化されたローカルストレージ機能が提供され、この機能を使用することで、キューに入っているメッセージを格納することができる。しかしながら、ローカルストレージにアクセスできるのは、格納しているｉｆｒａｍｅと同じドメインに属するウェブコンテンツのみである。この技術分野において開発された解決策としては、Ｍｅｅｂｏ ＸＡｕｔｈ製品（現在はＧｏｏｇｌｅ社が所有）によって使用されている基礎技術などが挙げられ、この技術では、小型のサーバが、要求される中間ｉｆｒａｍｅを作成するためのサポートを提供し、これにより、ドメインに固有なローカルストレージに、外部ドメインに属するｉｆｒａｍｅからアクセスすることができる。

ＨＴＭＬ５ローカルファイルアクセスＡＰＩ（アプリケーションプログラミングインタフェース）： 上述したローカルストレージを使用する方法に似ており、ＨＴＭＬ５のファイルアクセスＡＰＩ（Ｆｉｌｅ ＡＰＩ、ＦｉｌｅＷｒｉｔｅｒ ＡＰＩ、ＦｉｌｅＲｅａｄｅｒ ＡＰＩ）を通じてアクセスされるユーザエージェントのローカルストレージ上のローカルファイルを使用して、クロスｉｆｒａｍｅ通信チャネル（cross-iframe communication channel）を構築することができる。ただし、ＨＴＭＬ５のファイルシステムアクセスＡＰＩによって作成されるサンドボックス化されたローカルファイルシステムは、依然としてオリジン内からのみアクセス可能であり（origin-private）、したがって、同一オリジンという制限を克服するために中間ｉｆｒａｍｅ／サーバコンポーネントが要求される。

専用のブラウザプラグイン： クロスｉｆｒａｍｅメッセージキューを管理するための、専用のブラウザ（または他のユーザエージェント）プラグインを作成することができる。このようなプラグインは、（すべてのレベルにおける）ウェブサイト構築システム３０のユーザがインストールしなくてはならないが、すべてのｉｆｒａｍｅと、ウェブサイト構築システム３０のメインページに、必要なサービスを提供する。

通信ハブ２０５は、上述した転送方法のいずれかを使用するｉｆｒａｍｅ間通信すべてにおいてブローカーとして機能することができることを理解されたい。さらに、ハブ２０５は、含有ウェブページ２０３の構造と、サードパーティアプリケーション４０のベンダーによって提供されてプロパティシート２３に格納されているサードパーティアプリケーション４０の詳細情報を、完全に認識することができることを理解されたい。さらに、サードパーティアプリケーション４０は、複数の異なるアプリケーションに含まれているときと、（上述したように）同じアプリケーション内に含められる複数の異なるインスタンスにおいて、異なるパラメータを有することができる。このようなパラメータとしては、（後からさらに詳しく説明する）スマートアドレッシング（smart addressing）に使用することのできる一意のインスタンス名が挙げられる。さらに、ハブ２０５は、プロパティシート２３に格納されていない、サードパーティアプリケーション４０の追加の詳細情報を認識することもできることを理解されたい。

さらに、ハブ２０５は、スマートアドレッシングおよびスマート識別を容易にする、通信元を確認する、通信ポリシーを適用する、サードパーティアプリケーション４０の非互換性の問題を解決する、さらにはサードパーティアプリケーション４０からコンポーネントにリダイレクトすることができることを理解されたい。さらに、ハブ２０５は、後からさらに詳しく説明するように、含有ウェブページ２０３に行われた変更に基づいて、サードパーティアプリケーション４０におけるレイアウトの動的な更新を可能にすることができる。

次に、図１１Ａ、図１１Ｂ、および図１１Ｃを参照する。図１１Ａおよび図１１Ｂは、ハブ２０５の異なる実施形態を示しており、図１１Ｃは、ハブ２０５のさまざまな要素の機能を示している。

ハブ２０５は、スマート識別子／アドレッサ３１０、発信元確認器３２０、通信ポリシーエンフォーサ３３０、プロトコル変換器３４０、リダイレクタ３５０、動的レイアウト更新器３６０、構成マネージャ３７０、一般更新器３８０、およびホストされているＡＰＩ（アプリケーションプログラミングインタフェース）のラッパー３９０を備えていることができる。これらの要素の機能については、後から詳しく説明する。すべての機能を、すべてのクロスドメイン通信チャネル（例えば、サードパーティアプリケーション４０からウェブサイト構築システム３０へのチャネル、サードパーティアプリケーション４０から別のサードパーティアプリケーション４０へのチャネル）に適用することができることを理解されたい。

次に、図１１Ａを参照し、この図は、中間ｉｆｒａｍｅ［ａ］を通じてのハブ２０５の一般的な実施形態を示しており、中間ｉｆｒａｍｅは、内部通信ＡＰＩ（アプリケーションプログラミングインタフェース）を使用してウェブサイト構築システム３０と通信する。このようにすることで、（例えば）ＴＰＡ（サードパーティアプリケーション）［ｄ］（通信ＡＰＩモジュール［ｆ］を使用する）からＴＰＡ［ｅ］（通信ＡＰＩモジュール［ｇ］を使用する）に送られるメッセージ［ｃ］を、アプリケーションに固有な情報を適用する方法において、分析、確認、または修正することができる。

次に、図１１Ｂを参照し、この図は代替実施形態を示しており、この実施形態では、中間ｉｆｒａｍｅを使用せずに、（サードパーティアプリケーション［ｃ］に埋め込まれている）通信ＡＰＩモジュール［ａ］と、（サードパーティアプリケーション［ｄ］に埋め込まれている）通信ＡＰＩモジュール［ｂ］の一方または両方において、クロスドメイン通信を使用する。モジュール［ａ］およびモジュール［ｂ］は、通信メッセージ［ｆ］を扱うとき、ウェブサイト構築システム３０と直接対話してアプリケーションに固有な情報を受信し、この情報を使用する。（図１１Ａに示した実施形態と比較したときの）この実施形態の欠点として、ウェブサイト構築システム３０のレベルの相当な量の情報が、サードパーティアプリケーションに含まれているモジュールの内側で処理されることがあり、これらの情報が、悪意のあるサードパーティアプリケーションによってアクセスされる（場合によっては修正される）ことがある。

上述したように、上に説明したすべてのクロス通信方法においては、ｉｆｒａｍｅのアドレッシングは、ｉｆｒａｍｅのオリジン（ソースドメイン、ソースプロトコル、ソースポートなど）に基づき、すなわち、（受信側を指定するための）メッセージを送るときと、（受信側に提供される送信側の名前としての）メッセージを受信するときに、サードパーティアプリケーション４０のダイレクトアドレッシングを使用する。さらに、メッセージを送るためには、送信側は、（ＪａｖａＳｃｒｉｐｔのdocument.getElementById(“...”).contentWindowコールまたは任意の他のメソッドを使用して）ターゲットのｉｆｒａｍｅウィンドウを指定することが要求される。したがって、既存のシステムにおいては、サードパーティアプリケーション４０それぞれが、自身が通信する先の別のサードパーティアプリケーション４０の具体的な詳細情報すべて（ドメイン、プロトコル、ポート、ｉｆｒａｍｅ ＩＤを含む）を含んでいなければならない。

このタイプのダイレクトアドレッシングは、システム１００の環境において扱いにくいことがあることを理解されたい。たとえデザイナー５が、提携していない複数のサードパーティアプリケーション４０ベンダーからの複数のサードパーティアプリケーション４０を統合しても、サードパーティアプリケーション４０ベンダーによって供給されるサードパーティアプリケーション４０が、最初は特定のドメインにおいてホストされるが、後から別のドメインまたはサブドメインに移動することがある。サードパーティアプリケーション４０ベンダーは、特定のサードパーティアプリケーションと通信するために使用されるプロトコルまたはポートを変更することがある。デザイナー５には、サードパーティアプリケーション４０を含む含有ウェブページ２０３のデザインを修正することが要求されうる。これらのすべては、運営中であり膨大なユーザによってアクセスされるウェブサイトにおいて使用されているサードパーティアプリケーション４０において起こりうる。さらに、１つの含有ウェブページ２０３が、異なる機能を果たすことのできる、１つのサードパーティアプリケーション４０の複数のインスタンスを含むことがある。例えば、製品サポートのウェブサイト内の１つのページに、チャットのためのサードパーティアプリケーション４０の２つのインスタンス（１つはユーザ同士のチャットおよびフォーラムのためのインスタンス、もう１つは、連絡可能なときにベンダーのサポート担当者に相談するために使用されるインスタンス）が含まれることがある。

アドレッサ／識別子３１０は、含有ウェブページ２０３の構造と、（サードパーティアプリケーション４０のベンダーによってウェブサイト構築システム３０に提供される）サードパーティアプリケーション４０の詳細情報とを完全に認識していることができることを理解されたい。アドレッサ／識別子３１０は、送信元サードパーティアプリケーション４０または送信先サードパーティアプリケーション４０のアドレッシングを、（ＡｐｐＳｔｏｒｅ ２５に登録されている）サードパーティアプリケーション４０の一意の名前と、含有ウェブページ２０３におけるサードパーティアプリケーション４０の各インスタンスに加えられ、したがって同じサードパーティアプリケーション４０の複数のインスタンスのアドレッシングを可能にする、サードパーティアプリケーション４０のインスタンスの記述ＩＤ（descriptive ID）と、要求されるサードパーティアプリケーションのタイプ／クラスの一般識別子（generic identifier）（例：「含有ウェブページ２０３におけるイベントロギングのサードパーティアプリケーション４０のインスタンスにメッセージ＜ｘ＞を送りたい」）、のうちのいずれかを使用して、互いに提供することができる。このような識別子は、サードパーティアプリケーション４０によってサポートされるべき特定のサービスを記述することもできる。さらに、アドレッサ／識別子３１０は、バージョンの指示情報を使用することができる（例：「会計パッケージ＜ｙ＞がバージョン＜ｚ＞である場合のみ、会計パッケージ＜ｙ＞のインスタンスにトランザクション＜ｘ＞を送りたい」）。

実行時、サードパーティアプリケーション４０は、ハブ２０５と通信するのみであり、したがって、ハブ２０５の直接アドレスを認識しているのみでよく、他のサードパーティアプリケーション４０のアドレスは認識している必要がないことを理解されたい。この１つの直接アドレスを、ウェブサイト構築システム３０によってサードパーティアプリケーション４０の提供業者に提供される通信ＡＰＩラッパーによってカプセル化することができる（図１１Ａに示した通信モジュールｆおよびｇ、図１１Ｂに示した通信モジュールａおよびｂなど）。呼出し側のサードパーティアプリケーション４０は、アプリケーションが認識している自身の（上述した）記述アドレスを提供することができ、アドレッサ／識別子３１０は、これらのアドレスを、サードパーティアプリケーション４０の直接アドレスに変換してルーティングを実行することができる。このようにすることで、サードパーティアプリケーション４０は、自身が通信しうるすべてのサードパーティアプリケーション４０の絶対アドレスのテーブルを維持する必要がない。

メッセージの発信元の確認は重要であり、確認を行わないと、受信側のサードパーティアプリケーション４０が、敵意のあるサードパーティアプリケーション４０からのメッセージを受信しうることを理解されたい。すべての通信はハブ２０５を介して行われるため、発信元確認器３２０は、サードパーティアプリケーションからの入力メッセージすべての信頼性をチェックすることができる。さらに、発信元確認器３２０は、メッセージに追加することのできる追加情報を提供することができ、この追加情報を使用して追加の確認を行うことができる。ＡｐｐＳｔｏｒｅ ２５に含まれておりシステム１００によって使用されるすべてのサードパーティアプリケーション４０それぞれは、ウェブサイト構築システム３０に登録されるため、ハブ２０５は、メッセージに含まれている発信元の一意のＩＤがメッセージの発信元（ドメイン、ポートなど）に合致するかを、ウェブサイト構築システム３０によって確認することができることを理解されたい。

サードパーティアプリケーション４０は、外部情報や含有ウェブページ２０３の情報などに依存しうる一般的な通信ポリシーを定義することができる。通信ポリシーエンフォーサ３３０は、仕様に準拠しない通信を扱う必要がないように、該当する通信ポリシーが適用されるようにすることができる。例えば、機密情報を扱うウェブサイトにおいては、サードパーティアプリケーションに、それらのプロファイル内の機密レベルフィールドを付与することができる。機密レベルＸを扱うことが許可されている、バックエンドのイベントロギングデータベースを提供するサードパーティアプリケーション４０は、Ｘより高い機密レベルを有するイベントを受け入れてロギングしないというポリシーを定義することができる。このような状況において、通信ポリシーエンフォーサ３３０は、必要な事前フィルタリングを実行して、機密レベルの高いメッセージが、低い機密レベルしか扱うことのできないアプリケーションに到達することさえも防止することができる。

さらには、デザイナー５は、協力することは可能であるがプロトコル互換性の問題のために実際には協力することのない２つ（またはそれ以上）のサードパーティアプリケーションを、作成した同じウェブサイトに含めることを望むことがあることを理解されたい。ここで図１２を参照し、例えばこの図に示したように、オンラインショップのサードパーティアプリケーション［ａ］は、（異なるベンダーから提供されている）サードパーティアプリケーション［ｂ］などの調達・出荷のサードパーティアプリケーションに、購入注文メッセージを送信する機能を有することがある。しかしながら、サードパーティアプリケーション［ａ］によって提供される情報に、サードパーティアプリケーション［ｂ］において必要ないくつかのフィールドが含まれていないことがある。このような状況は、一般には、関与するサードパーティアプリケーションのベンダーによって解決されるべきであるが、場合によってはこのような解決を行うことができない（例えば、２つのサードパーティアプリケーションの一方が何らかの理由で現時点で更新されていない）。プロトコル変換器３４０は、［ａ］から［ｂ］への関連するメッセージを、（例えば必要な追加のフィールドを提供することによって）変換することができる。このような変換は、プロトコル変換器３４０によって実行することができる、または、アプリケーションが埋め込まれているウェブサイトおよび含有ウェブページ２０３との対話を伴うことがある（例えば追加情報が必要である場合）。

さらには、サードパーティアプリケーション４０は、別のサードパーティアプリケーション４０にメッセージを送信する、またはこのようなサードパーティアプリケーション４０からメッセージを受信することが要求される機能を有することがあることを理解されたい（例えば、上述したオンラインショップ／調達のサードパーティアプリケーション４０のペア）。しかしながら、場合によってはソリューションの一部が存在しないことがあり、上の例においては、対応する、または適切な調達のサードパーティアプリケーション４０が存在しないことがある。このような場合、リダイレクタ３５０を使用することによって、デザイナー５は、特定のメッセージを含有ウェブページ２０３のコンポーネントにルーティングする、または含有ウェブページ２０３のコンポーネントからの特定のメッセージをルーティングするようにと、匹敵する機能を、含有ウェブページ２０３のコンポーネントと、コンポーネントが提供することのできる機能とによって解決するように指定することができる。これにより、専用のサードパーティアプリケーション４０を構築する必要なしに、完全なウェブサイトを構築することができる。したがって、トランザクションをデータベースにロギングすることのできるウェブサイト構築システム３０のコンポーネントにトランザクションを送信することができ、このデータベースを後から（別のプログラムによって）使用して、オフラインでの調達および出荷を実行することができる。

サードパーティアプリケーション４０は、同じコードベースを使用するが異なる機能が有効になる、異なる能力を有する複数の構成を提供することができる。例えば、サードパーティアプリケーション４０は、無料バージョンを通じて基本的な機能を提供し、購入するプレミアムバージョン、複数の有料バージョン、またはサードパーティアプリケーション４０の購入する追加機能を通じて、追加の機能を提供することができる。

システム１００は、ユーザごとの（実際にはデザイナーごとの）サードパーティアプリケーション４０の購入状況を管理する、ウェブサイト構築システム３０をベースとする機能を含むことができることを理解されたい。さらに、すべてのデザイナーを、ウェブサイト構築システム３０の登録ユーザとすることができ、したがって、ウェブサイト構築システム３０は、各デザイナー５のサードパーティアプリケーション４０の購入状況のデータベースを管理することができることを理解されたい。この情報は、デザイン段階においてはＴＰＡコーディネータ２４によって、実行時には構成マネージャ３７０によって、プロパティシート２３に格納することができる。例えば、サードパーティアプリケーション４０は、ウェブサイト構築システム３０のクライアント側要素にバージョン問い合わせメッセージを送ることができる。ウェブサイト構築システム３０のクライアント側要素は、リポジトリ２２、またはローカルにキャッシュされているリポジトリのコピーに照会して、サードパーティアプリケーション４０が提供するべき能力に関する情報を含む応答メッセージをサードパーティアプリケーション４０に返す。

代替実装においては、ウェブサイト構築システム３０は、サードパーティアプリケーション４０の必要な構成情報（暗号化されたｉｆｒａｍｅパラメータなど）を、事前の問い合わせメッセージを必要とすることなしに、代替チャネルを介してサードパーティアプリケーション４０に提供することができる。

上述したように、サードパーティアプリケーション４０は、含有ウェブページ２０３の特定のコンポーネントと直接通信することができる。サードパーティアプリケーション４０は、通信先のコンポーネントを、さまざまな方法で識別することができ、すなわち、（後からさらに詳しく説明するように）関連付けられるテンプレートに基づいてコンポーネントを直接的に識別する、またはデザイナー５によって含有ウェブページ２０３の特定のコンポーネントに明示的に指定されるアクセスＩＤを通じて識別する、または含有ウェブページ２０３によってサードパーティアプリケーション４０に提供される（場合によっては選択的な）コンポーネントモデルをたどることによって識別する。

実行時、更新器３８０は、含有ウェブページ２０３のコンポーネントとサードパーティアプリケーション４０との間のメッセージおよび応答を実装することができることを理解されたい。例えば、サードパーティアプリケーション４０は、含有ウェブページ２０３のコンポーネントの視覚・表示属性（コンポーネントの位置、サイズ、色、透明度など）を変更・修正する、または問い合わせることができる。さらに、更新器３８０によって、サードパーティアプリケーション４０は、含有ウェブページ２０３のコンポーネントのコンテンツを読み取るまたは書き込むことを可能になり、さらには、サードパーティアプリケーション４０が、メディア機能（例えば、指定のオーディオセグメントまたはビデオセグメントをメディアプレイヤーコンポーネントに渡す、あるいは指定の期間にわたり再生を一時停止するようにメディアプレイヤーコンポーネントに要求する）を実行するコンポーネントに指示することが可能になる。

さらに、更新器３８０によって、ウェブサイト構築システム３０のコンポーネントが、サードパーティアプリケーション４０に許可するアクセスのタイプを指定することが容易になり、この場合、最近のオペレーティングシステムにおいてファイルを保護するためにアクセス許可ビットやアクセス制御リスト（ＡＣＬ）が機能するのと類似する方法による。このような許可は、すべてのサードパーティアプリケーション４０、特定のベンダーからのサードパーティアプリケーション４０、または特定のサードパーティアプリケーション４０に適用されるように、各コンポーネントに対して定義することができる。例えば、サードパーティアプリケーション４０が、含有ウェブページ２０３の中の、サードパーティアプリケーション４０の外側のテキストフィールドにアクセスできるようにすることができる。ブログのサードパーティアプリケーション４０の場合、このテキストフィールドを使用してブログエントリを編集することができ、ブログのサードパーティアプリケーション４０の領域自体の内側に提供することのできる画面領域よりも広い画面領域が提供される。マルチページコンテナの内側の特定のミニページに埋め込まれているサードパーティアプリケーション４０の場合、ウェブサイト構築システム３０は、サードパーティアプリケーション４０からのアクセスを、その特定のミニページ内のコンポーネントのみに制限することができることを理解されたい。

さらに、更新器３８０によって、サードパーティアプリケーション４０がサイト全体の要素に影響を与えることが可能になることを理解されたい。例えば、サイト内の現在のページ、サードパーティアプリケーション４０を含むコンテナ内の現在のミニページ、ページ履歴などの属性を取得して設定する処理が挙げられる。さらに、更新器３８０は、このような要求をフィルタリングまたは制限することができる。

さらに、更新器３８０によって、ウェブサイト構築システム３０がサードパーティアプリケーション４０のスタイルおよび表示を変更・修正することが可能になる。更新器３８０は、ウェブサイト構築システム３０がフォーマッティングおよびスタイルのガイドラインをサードパーティアプリケーション４０に提供するときに使用する呼出しを実施することができる。ガイドラインは、色および配色、フォント、文字サイズ、透明度、アニメーションおよび特殊効果（例：ぼかし）などのプロパティを含むことができる。配色としては、特に、一般的配色（例えば以下のｘ色を使用する）や、ハイレベル配色（例えば、テキストに色ｘを使用し、フレームに色ｙを使用する）が挙げられる。

複雑なスタイル情報を表現するための１つの好ましい方法は、カスケードスタイルシート（ＣＳＳ）を使用することであり、カスケードスタイルシートは、フォントやサイズ、色などの複数のスタイルディレクティブの組合せを表現することができることを理解されたい。更新器３８０は、このようなＣＳＳベースのメッセージをサードパーティアプリケーション４０に送ることができる。スタイルシートは、本質的に汎用とする、または、サードパーティアプリケーション４０によって定義される固有のスタイル名を含むことができ、したがってウェブサイト構築システム３０は、より適切なガイドラインをサードパーティアプリケーション４０に提供することができる（例えば、スタイルシートは、特定のサードパーティアプリケーション４０の要素を参照して、これらのガイドラインを提供することができる）。

これにより、サードパーティアプリケーション４０は、これらのガイドラインを使用して、含有ウェブページ２０３に良好に適合した自身の外観／操作感（ルックアンドフィール）を生み出すことができる。このことは、同じサイト内の複数の含有ウェブページ２０３に含まれる、または複数の含有ウェブページ２０３から可視である（上述したマルチポートインクルージョン）サードパーティアプリケーション４０にとって、特に重要である。複数の含有ウェブページが、異なる配色や基本デザインを採用することができる。サードパーティアプリケーション４０は、これらのスタイルメッセージを通じて提供される情報を使用して、自身の表示色およびスタイルを、含有ページそれぞれに良好に合うように適合させ、含有ウェブページと比較して調和しない配色が表示されたり外観／操作感が生じることを回避することができる。

動的レイアウト更新器３６０は、動的レイアウトイベントの結果としての表示の変更を処理するときに、ウェブサイト構築システム３０とサードパーティアプリケーション４０、あるいはサードパーティアプリケーション４０と補助的なサードパーティアプリケーションが、協力することを可能にすることを理解されたい。ウェブサイト構築システム３０は、ページ内のコンポーネントのいくつかを変更するイベント発生時に、ページデザインを維持する目的で、そのページ内のコンポーネントのサイズおよび位置を変更することができる。これらの動的レイアウトイベントとしては、例えば、異なるサイズを有する画面上でウェブサイトを閲覧する、ポートレートモードとランドスケープモードの間で表示装置を回転させる、いくつかのコンポーネントのサイズや位置を変更する、特定のコンポーネントのコンテンツを変更する（結果としてコンポーネントのサイズ変更が要求される）、が挙げられる。さらに、動的レイアウトイベントとしては、（例えばデータフィード（data feed）からの情報を表示するコンポーネントにおける）サーバベースのコンテンツの更新、あるいは同じウェブサイトの別の同時利用者によるコンテンツの変更による、コンポーネントの更新が挙げられる。さらに、動的レイアウトイベントは、デザイン環境のみならず実行時環境においても起こりうることを理解されたい。特に、コンポーネントおよびサードパーティアプリケーション４０によっては、デザイナーによってのみならず、実行時に（すなわちエンドユーザによって）コンポーネントのコンテンツやサイズ／位置を変更することができる。

さらに、動的レイアウトイベントは、サードパーティアプリケーション４０によっても発生しうることを理解されたい。例えば、オンラインショップのサードパーティアプリケーション４０では、ユーザが製品カタログの表示から（異なるサイズを有する）ショッピングカートの表示に移動するときに、サイズの変更が要求されることがある。別の例として、製品カタログのサードパーティアプリケーション４０は、製品を強調表示するためのオプションを含むことがあり、このオプションに起因して、サードパーティアプリケーション４０は、より多くのコンテンツを含むより大きなカタログページを表示する。さらなる例としては、追加領域の表示を開始または停止させることができるマルチ領域のサードパーティアプリケーション４０が挙げられる。

ここで前出の図６を参照する。既存のシステムでは、このような状況は、たとえ扱うにしても、一般には、サードパーティアプリケーションの表示を途中で切り取り、表示にスクロールバーを追加する、または図６に示したようにページの他のコンポーネントを隠すポップアップウィンドウとして単に表示をリサイズすることによって処理する。動的レイアウト更新器３６０は、協力的な動的レイアウトを実装することができ、この場合、ウェブサイト構築システム３０とサードパーティアプリケーション４０とが協力して動的レイアウトを実行し、含有ウェブページ２０３の基本的なデザインを維持する。動的レイアウトの機能は、特許文献１（出願日：２０１３年２月２０日、本発明の共通の譲受人に譲渡されている）にさらに記載されている。しかしながら、たとえ協力的な動的レイアウトをサポートするシステムにおいても、含有ウェブページ２０３における動的レイアウトメカニズムは、サードパーティアプリケーション４０の内部レイアウトを完全には制御しない。さらには、ウェブサイト構築システム３０のウィジェットは、（特定の範囲内で）任意のサイズにリサイズできるように設計されることがあるが、サードパーティアプリケーション４０が任意のリサイズをサポートしないことがある。サードパーティアプリケーション４０は、例えば、異なるサイズを有する複数の表示設定（例：より多くの、またはより少ない詳細情報を表示する）、サードパーティアプリケーション４０の内部要素のいくつかをリサイズする機能、サードパーティアプリケーション４０のテキスト要素のいくつかを複数のフォントサイズを使用して表示する機能、の任意の組合せを提供することがある。

さらに、サードパーティアプリケーション４０は、提供される可能な表示サイズの数が限られていることがあり、可能なサイズの範囲全体を有することがある。したがって、含有ウェブページ２０３からサードパーティアプリケーション４０へのリサイズ要求は、サードパーティアプリケーション４０が最も近い可能なサイズに切り替えることによって、またはサードパーティアプリケーション４０の可能なサイズのリストを提供する（これによりウェブサイト構築システム３０は使用する適切なサイズを選択することができる）ことによって、解決することができる。

動的レイアウト更新器３６０は、［含有ウェブページ２０３からサードパーティアプリケーション４０への］協力的な動的レイアウトを、次のシーケンスを使用して実装することができる。

例えば、含有ウェブページ２０３に埋め込まれているサードパーティアプリケーション４０を、特定の所望のサイズ（例：Ｘ１＊Ｙ１ピクセル）にリサイズすることが必要となることがある。動的レイアウト更新器３６０は、サードパーティアプリケーション４０が自身のコンテンツを特定の所望のサイズ（例：Ｘ１＊Ｙ１ピクセル）にリサイズするように要求するメッセージを、サードパーティアプリケーション４０に送ることができる。サードパーティアプリケーション４０は、代替の表示設定、内部でのリサイズ処理、内部での動的レイアウト処理、または任意の他の手段を使用することによって、指定のサイズに調整することができる。さらには、含有ウェブページ２０３が、サードパーティアプリケーション４０を含む外部ｉｆｒａｍｅウィンドウを新しいサイズ（Ｘ１＊Ｙ１）にリサイズできることを理解されたい。

さらに、サードパーティアプリケーション４０は、可能なサイズの限られたセットにリサイズ処理できるのみでありうることを理解されたい（例えば特定のユーザインタフェース構成）。したがって、動的レイアウト更新器３６０は、サードパーティアプリケーション４０が可能なサイズのセットを提供することができる次の代替アルゴリズムを使用することができる。

含有ウェブページ２０３がリサイズされ、動的レイアウト更新器３６０は、サードパーティアプリケーション４０が自身のコンテンツを特定の所望のサイズ（Ｘ１＊Ｙ１）にリサイズするように要求するメッセージを、サードパーティアプリケーション４０に送る。サードパーティアプリケーション４０は、最も近い可能なサイズ（例：Ｘ２＊Ｙ２ピクセル）を求め、代替の表示設定、内部でのリサイズ処理、内部での動的レイアウト処理、または任意の他の手段を使用することによって、そのサイズにリサイズする。次いで、更新器３８０は、リサイズ処理を確認する応答メッセージを含有ウェブページ２０３に送り、実際の新しいサイズ（Ｘ２＊Ｙ２）を提供することができる。含有ウェブページ２０３は、サードパーティアプリケーション４０を含む外部ｉｆｒａｍｅウィンドウを実際の新しいサイズ（Ｘ２＊Ｙ２）にリサイズすることができる。含有ウェブページ２０３は、実際の新しいサイズ（Ｘ２＊Ｙ２）に基づいて動的レイアウト処理を続行することができる。

特に、含有ウェブページ２０３内に複数のサードパーティアプリケーション４０（またはマルチ領域サードパーティアプリケーション４０）が存在する場合、別の実施形態も適用可能であることを理解されたい。この実施形態においては、含有ウェブページ２０３は、埋め込まれているサードパーティアプリケーション４０が複数のサードパーティアプリケーション４０の複数のオプションを考慮して外観／操作感を最適化することを試みることができるように、埋め込まれているサードパーティアプリケーション４０に問い合わせて表示サイズのリストを取得することができる。この実施形態は、サードパーティアプリケーション４０が複数の領域にわたり表示される場合にも関連する。

含有ウェブページ２０３は、動的レイアウト処理を実行して、１つまたは複数のサードパーティアプリケーション４０（ＴＰＡ［１］〜ＴＰＡ［ｎ］）が含有ウェブページ２０３に埋め込まれており次のアルゴリズムを使用してリサイズするべきであることを認識する。

ｉについて１からｎまでループする。

各ＴＰＡ［ｉ］について、以下を求める。

最小サイズＸｍｉｎ［ｉ］＊Ｙｍｉｎ［ｉ］、
最大サイズＸｍａｘ［ｉ］＊Ｙｍａｘ［ｉ］、
最適サイズＸｏｐｔ［ｉ］＊Ｙｏｐｔ［ｉ］、
動的レイアウト更新器３６０は、上記の最小／最大／最適サイズを列挙するメッセージをＴＰＡ［ｉ］に送り、サードパーティアプリケーション４０の可能なサイズに関する情報を要求することができる。

サードパーティアプリケーション４０は、自身が採用することのできる可能なサイズオプションのセット（Ｘｐｏｓｓ［ｉ］［ｊ］＊Ｙｐｏｓｓ［ｉ］［ｊ］）を動的更新器３６０に提供することができる。

含有ウェブページ２０３は、上記のようにして集めたＸｐｏｓｓ［］［］／Ｙｐｏｓｓ［］［］情報に基づき、（例えば）サードパーティアプリケーションの可能なサイズの組合せすべての完全な評価、線形計画法、または動的レイアウトアルゴリズムによって使用される任意の他の手法を使用することによって、動的レイアウト計算の解を計算することができる。

すべてのＴＰＡについて結果をＸｆｉｎａｌ［ｉ］／Ｙｆｉｎａｌ［ｉ］に格納する。

ｉについて１からｎまでループする。

含有ウェブページ２０３が、Ｘｆｉｎａｌ［ｉ］／Ｙｆｉｎａｌ［ｉ］を含むリサイズメッセージをＴＰＡ［ｉ］に送る。

含有ウェブページ２０３が、ＴＰＡ［ｉ］を含む外部ｉｆｒａｍｅウィンドウをＸｆｉｎａｌ［ｉ］／Ｙｆｉｎａｌ［ｉ］にリサイズする。

含有ウェブページ２０３が、実際の新しいサイズに基づいて動的レイアウト処理を続行する。

動的レイアウト処理では、一般に、サードパーティアプリケーション４０を単にリサイズするだけではなく、サードパーティアプリケーション４０を移動させることが要求されうることを理解されたい。しかしながら、サードパーティアプリケーション４０は、含有ウェブページ２０３の内側の自身のフレームの正確な位置に対して不変であるべきである。

上述したように、サードパーティアプリケーション４０は、その表示ウィンドウのサイズを変更する必要もときおり生じうる。ｉｆｒａｍｅを表示するウィンドウのサイズは、ホスティングページ（すなわち含有ウェブページ２０３）によって管理されるため、サードパーティアプリケーション４０のウィンドウサイズの変更は含有ウェブページ２０３によって実行されなければならず、この場合、サードパーティアプリケーション４０はウィンドウサイズを変更するように含有ウェブページ２０３に（動的レイアウト更新器３６０を介して）要求する。

さらに、サードパーティアプリケーション４０は、含有ウェブページ２０３の内側の自身の位置を変更するように（動的レイアウト更新器３６０を介して）要求することもできることを理解されたい。この場合には、（サイズ変更のときのように）内部的にサードパーティアプリケーション４０が影響されることはないが、含有ウェブページ２０３内の表示の変更が要求される。動的レイアウト更新器３６０は、この要求と動的レイアウトとを統合することができる。含有ウェブページ２０３は、動的レイアウト更新器３６０を起動して、サードパーティアプリケーション４０のウィンドウサイズ（および場合によってはウィンドウの位置）を変更し、サイズおよび位置の変更の確認をサードパーティアプリケーション４０に送ることができる。

ハブ２０５は、サードパーティアプリケーション４０のクラスに固有な追加のメッセージ、またはサードパーティアプリケーション４０に固有な追加のメッセージとして、ウェブサイト構築システム３０自体、または特定の含有ウェブページ２０３、または補助的なサードパーティアプリケーション４０がサードパーティアプリケーション４０に影響を与えることのできる追加のメッセージ、を実装することもできることを理解されたい。例えば、ブログのサードパーティアプリケーション４０は、新しいブログエントリ、または現在のブログエントリへの新しい応答を投稿することのできる入力メッセージを定義することがある。このようなメッセージは、（例えば、サードパーティアプリケーションの領域の外側の大きな編集フィールドからブログエントリを投稿するための方法として）含有ウェブページ２０３によって使用することができる。さらに、このようなメッセージは、上位レベルのアプリケーション間のリンクに使用することもでき、これにより例えば、サポートのサードパーティアプリケーションがブログのサードパーティアプリケーションにブログエントリを投稿することができる。

サードパーティアプリケーション４０では、自身のサイト内でサードパーティアプリケーション４０を使用しているデザイナーがサードパーティアプリケーション４０の内部で使用する、または下流で使用するための幅広い複雑なサービスがしばしば要求されることを理解されたい。このようなサービスとしては、ユーザ管理や請求・出荷管理が挙げられる。ウェブサイト構築システム３０のベンダーは、（例えば技術的な問題またはビジネス上の理由で）ウェブサイト構築システムの一部としてこのようなサービスを提供できないことがある。さらには、これらのサービスは、単独でサードパーティアプリケーション４０として「パッケージ化」するのに適していないことがある。さらに、サードパーティアプリケーション４０のベンダーは、サードパーティアプリケーション４０を使用するデザイナーに複数のそのようなサービス（例：サードパーティの複数の請求ＡＰＩ）を提供して、デザイナー５が適切なサービスを選択して使用できるようにするオプションを必要とすることがある。

例えば、ウェブサイト構築システム３０において、Ｐａｙｐａｌ^TMによってホストされるＡＰＩを提供することができ、このＡＰＩをサードパーティアプリケーション４０によって直接使用する、またはこのＡＰＩを使用するデザイナー５にサードパーティアプリケーション４０によって提供することができる。さらに、サードパーティアプリケーション４０は、自身のオプションのセット（すなわち特定の請求タイプ、例えば一回単位請求、自動継続請求、レベニューシェア（revenue sharing）を使用する）を提供し、ホストされているＰａｙｐａｌのＡＰＩを呼び出すことによってこれらのオプションを実装することもできる。

したがって、ウェブサイト構築システム３０を使用しているデザイナー５は、前払請求（advanced billing）を使用する固有のサービス（楽曲を販売するオンラインショップなど）を開発することができる。デザイナー５は、ホストされている請求ＡＰＩを、直接的に使用する、または追加の抽象レベル（または抽象層）を提供するサードパーティアプリケーション４０を通じて使用することによって、請求ＡＰＩの提供者との特定の清算協定や取引合意（merchant agreement）を交渉する必要性を回避することができる。この意味で、ウェブサイト構築システム３０は、ホストされているＡＰＩのベンダーの代理店となりうる。

ホストされているＡＰＩのラッパー３９０は、システムの複数の異なる部分（例えば、ウェブサイト構築システム３０、ホストされているＡＰＩコード、含まれているサードパーティアプリケーション４０）の間のこの通信を容易にすることができる。ＡＰＩのラッパー層と、実際のＡＰＩの実装は、ウェブサイト構築システム３０自体または別のサードパーティアプリケーション４０に属することができることを理解されたい。サードパーティアプリケーション４０のベンダー（またはデザイナー５）は、実際の下層のＡＰＩの実装方法を認識することなく、ホストされているＡＰＩのラッパー３９０を通じて、ホストされているＡＰＩを使用することができる。

本発明の補足的な代替実施形態においては、出願人は、ウェブサイト構築システムの追加のテンプレートおよびコンポーネントが、ＡｐｐＳｔｏｒｅ ２５のレベルにおけるサードパーティアプリケーションと、関連するサードパーティアプリケーションのインスタンスとに関連付けられる統合モデルを使用することによって、ウェブサイト構築システム３０と１つまたは複数のサードパーティアプリケーション４０との間のスマートな統合を達成できることをさらに認識した。サードパーティアプリケーション４０は、これらのコンポーネント（および関連付けられていないコンポーネント）と通信して、データおよび制御メッセージを交換することもできる。上述したように、含有ウェブページ２０３内のサードパーティアプリケーション領域４０は、メインサイトがホストされているドメインとは異なる個別のドメイン（サードパーティアプリケーションのベンダーのドメインまたはそれ以外）においてコンテンツがホストされる個別のｉｆｒａｍｅである。したがって、複数の異なるｉｆｒａｍｅ間の通信には、ブラウザの「同一オリジンポリシー」が適用され、上述した手法を使用することが要求される。

既存のシステムでは、サードパーティアプリケーション４０を、含有ウェブページ２０３に含まれるがそれ以外の点では含有ウェブページ２０３自体の外観／操作感には影響しない、一体的な柔軟性の低いオブジェクトとして実装する。サードパーティアプリケーション４０のインスタンスは、（一般には長方形の）領域内に配置され、その動作・機能のすべてをこの領域内で実行する。

さらに、出願人は、サードパーティアプリケーション４０に関連付けられる、ウェブサイト構築システム３０の（オプションの）追加のテンプレート（本発明の実施形態によると、関連付けられるテンプレートと称する）を有することによって、この概念を拡張できることを認識した。この関連付けは、サードパーティアプリケーション４０の開発時または公開時に実行することができ、（ＡｐｐＳｔｏｒｅ ２５からの）サードパーティアプリケーション４０の選択／購入プロセスおよびサードパーティアプリケーション４０のインスタンス作成の一部として、デザイナー５に提示することができることを理解されたい。サードパーティアプリケーション（ＴＰＡ）コーディネータ２４は、サードパーティアプリケーション４０に関連付けられるテンプレートを、（ＡｐｐＳｔｏｒｅ ２５によって管理される、またはサードパーティアプリケーション４０のベンダーによって提供されるアプリケーションリポジトリの一部として）取得して、上述したように、後から使用できるようにテンプレートをリポジトリ２２に格納することができる。

システム１００は、複数の関連付けられるテンプレートを有するサードパーティアプリケーション４０の公開をサポートすることができ、これによりデザイナー５は、必要に応じて最適なテンプレートを選択することができることを理解されたい。

含有ウェブページ２０３の中にサードパーティアプリケーション４０のインスタンスを作成するとき、関連付けられるテンプレート内のコンポーネントを、含有ウェブページ２０３とマージすることができ、含有ウェブページ２０３の中の他のコンポーネントと一緒に表示することができることを理解されたい。

次に、図１３を参照し、この図は、本発明の実施形態による、関連付けられるテンプレートの使用例を示している。図示したように、サードパーティアプリケーション［ａ］は、コンポーネント［ｄ］および［ｅ］を含む関連付けられるテンプレート［ｃ］とともに、ＡｐｐＳｔｏｒｅ［ｂ］の中に配置されている。サードパーティアプリケーション［ａ］が含有ウェブページ２０３［ｆ］に含まれているとき、サードパーティアプリケーション［ａ］を、ページ［ｆ］の内側の指定された領域［ｇ］に表示することができ、コンポーネント［ｄ］および［ｅ］のインスタンス［ｄ’］および［ｅ’］を、前から存在するコンポーネント［ｈ］および［ｉ］とともにページ［ｆ］に表示することができることを理解されたい。

システム１００は、関連付けられるテンプレートコンポーネントのインスタンス（例えば上記の［ｄ’］および［ｅ’］）を含有ウェブページ２０３［ｆ］の中に配置する複数の方法をサポートすることができることを理解されたい。配置方法としては、絶対的な配置（すなわち、関連付けられるテンプレート［ｃ］に指定されている、元のコンポーネント［ｄ］および［ｅ］のサイズおよび位置を使用する）、ターゲットを基準とする配置（すなわち、含有ウェブページ２０３［ｆ］に従って新しいインスタンス［ｄ’］および［ｅ’］のサイズおよび位置を調整する）、サードパーティアプリケーション４０を基準とする配置（すなわち、含有ウェブページ２０３［ｆ］の内側のサードパーティアプリケーションのインスタンス［ｇ］に指定されるサイズおよび位置を基準として、新しいインスタンス［ｄ’］および［ｅ’］のサイズおよび位置を調整する）、が挙げられる。採用する配置方法は、関連付けられるテンプレート［ｃ］とともに含まれている設定に基づいて決定することができ、デザイナー５は、必要であれば別の配置方法を使用することができる。

さらに、デザイナー５は、テンプレート［ｃ］から継承される、［ｆ］の中のコンポーネント［ｄ］および［ｅ］のインスタンスを修正することができることを理解されたい。変更は、［ｆ］（および場合によっては、ページ間継承（inter-page inheritance）をサポートするウェブサイト構築システム３０の中から継承するページ）の中での［ｄ］および［ｅ］の使用に適用されるのみであり、ＡｐｐＳｔｏｒｅ［ｂ］内のサードパーティアプリケーション［ａ］に関連付けられる「元の」テンプレート［ｃ］には影響しない。

上記の［ｄ］および［ｅ］のインスタンスへの変更としては、特に、フィールドのインスタンスに特定のコンテンツ（テキスト、画像など）を割り当てることや、通常の属性を変更することが挙げられることを理解されたい。さらに、図１４を参照し、サードパーティアプリケーション４０がミニページの内側に含まれる場合、図１４に示したように、関連付けられるテンプレートは、サードパーティアプリケーション４０が含まれている特定のミニページに適用されることを理解されたい。図示したように、サードパーティアプリケーション４０はミニページ［ｘ］に含まれており、したがってコンポーネント［ｄ］および［ｅ］は［ｘ］に追加されるが、同じマルチページコンテナ［ｇ］のさらなるミニページ［ｙ］および［ｚ］には追加されない。

さらに、セクションタイプのミニページの場合、関連付けられるテンプレート（存在時）は、サードパーティアプリケーション４０を含むために作成された仮想の（かつ空の）含有ウェブページ２０３に適用されることを理解されたい。

代替実施形態においては、あらかじめ作成される関連付けられるテンプレートを、含有ウェブページ２０３に「並列」である新たに作成されるページまたはミニページに適用することができる。この新たに作成されるページまたはミニページをテンプレートによって初期化し、それを必要に応じて修正することができる。

さらに、ウェブサイト構築システム３０では、マルチポートインクルージョンも可能になり、この場合、サードパーティアプリケーション４０の同じインスタンスがメインサイトの複数のページから可視であり、これらのページに「属する」。マルチポートインクルージョンは、メインサイト内の特定のサードパーティアプリケーション４０の複数のインクルージョン（サードパーティアプリケーション４０の複数のインスタンスを作成する）とは異なる。したがって、サードパーティアプリケーション４０のコンテンツ（インスタンスに固有である）が、同じマルチポートサードパーティアプリケーション４０の複数の表示の間で共有される。

このようなマルチポートインクルージョンにおいては、関連付けられるテンプレートを、サードパーティアプリケーション４０のインスタンスが追加されるページおよびミニページのそれぞれに個別に適用することができる。

上述したように、システム１００は、含有ウェブページ２０３の中のサードパーティアプリケーション４０とコンポーネントとの間の双方向通信リンクを提供することができる。このようなコンポーネントとしては、サードパーティアプリケーションからの関連付けられるテンプレートをマージする結果としての、含有ウェブページ２０３のコンポーネントと、このような関連付けられるテンプレートに関連しないコンポーネントとが含まれることを理解されたい。

したがって、サードパーティアプリケーション４０のベンダーは、一般に、ベンダーによって提供されるサードパーティアプリケーション４０に関連付けられる複数のテンプレートを作成することができることを理解されたい。これらのテンプレートとしては、実際に配布されている（すなわちその時点で配布されているサードパーティアプリケーションバージョンに関連付けられる）テンプレートに加えて、テストテンプレート、開発テンプレート、およびその他のテンプレートが挙げられる。

上述したように、サードパーティアプリケーション４０は、ＡｐｐＳｔｏｒｅ ２５を通じて配布することができ、さらには、ウェブサイト構築システム３０のベンダーには関連しない、またはベンダーによって管理されない代替経路を通じて配布することもできる。しかしながら、サードパーティアプリケーション４０とともに配布される関連付けられるテンプレートは、アプリケーションリポジトリ２２に強く関連して結合されていることがあり、なぜなら関連付けられるテンプレートは、ウェブサイト構築システム３０によって管理されるコンポーネント、ベーステンプレート、および他の要素を使用して構築されるためである。

さらには、このような個別に配布される関連付けられるテンプレートの基礎をなす、ウェブサイト構築システム３０の要素を、修正または削除しなければならないことがある（これにより場合によっては関連付けられるテンプレートが「壊れる」）。この問題を解決するため、システム１００は、これらの関連付けられるテンプレートを、アプリケーションリポジトリ２２の内側の（場合によってはサードパーティアプリケーション４０のベンダーごとの）個別の領域に実装することができる。ウェブサイト構築システム３０は、これらのテンプレートを、ウェブサイト構築システム３０の他のテンプレートと同様に管理することができる。

さらに、サードパーティアプリケーション４０のベンダーに、作成される各テンプレートの一意のＩＤ（開発ＩＤ）を提供することができ、サードパーティアプリケーション４０のベンダーは、サードパーティアプリケーション４０の開発およびテストプロセス時にこのＩＤを使用することができることを理解されたい。サードパーティアプリケーション４０が公開／配布される時点で、サードパーティアプリケーション４０のベンダーには、代わりの一意のＩＤ（公開ＩＤ）を適用および受信することが要求されることがあり、ベンダーは、公開されるサードパーティアプリケーション４０においてそのＩＤを参照することができる。公開ＩＤが提供されると、テンプレートの個別のロックされたコピーが作成される。このコピーは、サードパーティアプリケーション４０によって参照され、サードパーティアプリケーション４０のインスタンスを作成するときに使用されるコピーである。このようにすることで、サードパーティアプリケーション４０のベンダーは、（デザイナーによって含められている）「生の」サードパーティアプリケーション４０に関連付けられるテンプレートを誤って修正することができなくなり、参照整合性が維持される。さらには、システム１００は、このようなロックされたテンプレートと、基礎をなすコンポーネントおよびベーステンプレートとの間の関係を、相互参照させることができる。この相互参照を使用することで、例えば、このようなロックされたテンプレートに含まれている、ウェブサイト構築システム３０のコンポーネントやベーステンプレートが修正されようとする（そしてこのような修正によってテンプレートまたはサードパーティアプリケーション４０が何らかの形で壊れうる）場合に、ウェブサイト構築システム３０のスタッフに警告することができる。

したがって、システム１００は、サードパーティアプリケーション４０と、含有ウェブページ２０３の中のコンポーネントと、ウェブサイト構築システム３０との間の双方向通信チャネルを提供することができる。含有ウェブページ２０３のコンポーネントは、サードパーティアプリケーションに関連付けられる（１つまたは複数の）テンプレートをベースとする、またはウェブサイト構築システム３０の別のテンプレートをベースとする、またはテンプレートには無関係とすることができる。

本明細書に記載されているプロセスおよび表示は、本質的に特定のコンピュータまたは他の装置に関連するものではない。さまざまな汎用システムを、本明細書における教示内容によるプログラムと組み合わせて使用することができ、あるいは、所望の方法を実行するための専用装置を構築することが好都合でありうる。さまざまなこれらのシステムの所望の構造は、上記の説明から明らかであろう。さらに、本発明の実施形態は、特定のプログラミング言語に関連して説明していない。本明細書に記載されている本発明の教示内容を実施する目的に、さまざまなプログラミング言語を使用することができることを理解されたい。

特に明記していない限り、ここまでの説明から明らかであるように、本明細書全体を通じて、「処理する」、「計算する」、「求める」などの用語を使用した説明部分は、コンピュータ、コンピューティングシステム、または同様の電子コンピューティング装置（物理量として表されるデータ、例えばコンピューティングシステムのレジスタやメモリ内の電子量を、コンピューティングシステムのメモリ、レジスタ、または他のそのような情報記憶装置、送信装置、表示装置内の物理量として同様に表される別のデータに操作したり変換したりする装置）の動作や処理を意味することを理解されたい。

本発明の実施形態は、本明細書に記載されている動作・操作を実行する装置を含むことができる。この装置は、所望の目的のために専用に構築することができる、または、この装置は、コンピュータに格納されるコンピュータプログラムによって選択的に起動または再構成される汎用コンピュータ、を備えていることができる。このようなコンピュータプログラムは、コンピュータ可読記憶媒体、例えば、以下に限定されないが、任意のタイプのディスク（フロッピー（登録商標）ディスク、光ディスク、光磁気ディスクなど）、読み取り専用メモリ（ＲＯＭ）、コンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、電気的プログラマブル読み取り専用メモリ（ＥＰＲＯＭ）、電気的消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）、磁気カードまたは光カード、フラッシュメモリ、または電子的命令を格納するのに適しておりコンピュータシステムバスに結合することのできる任意の他のタイプの媒体、に格納することができる。

ここまで本発明の特定の特徴を図示および説明してきたが、この技術分野における通常の技能を有する者には、数多くの修正、置き換え、変更、および等価物が明らかであろう。したがって、添付の請求項は、本発明の実質的な概念に含まれるそのような修正および変更すべてを包含するように意図されていることを理解されたい。

Claims (22)

1. ウェブサイト構築システムのための装置であって、
   前記ウェブサイト構築システムによって構築されるウェブサイトのページに埋め込まれ、異なるベンダーからの少なくとも２つのサードパーティアプリケーションの間のダイレクトアドレッシングを用いた双方向のクロスドメイン通信を実装し、前記少なくとも２つのサードパーティアプリケーションはそれぞれ前記ページ内にインスタンスを有する通信ハブであって、
   発信元又は前記少なくとも２つのサードパーティアプリケーションのうちの発信先のサードパーティアプリケーションの前記ダイレクトアドレッシングを識別及び提供し、前記双方向のクロスドメイン通信のためのすべての絶対アドレスのテーブルを維持するためのスマート識別子及びアドレッサと、
   前記ウェブサイト構築システムと前記少なくとも２つのサードパーティアプリケーションとの間の通信ポリシーを適用し、前記通信ポリシーに従って非互換の通信をフィルタリングする、通信ポリシーエンフォーサと、
   を含む、通信ハブと、
   前記少なくとも２つのサードパーティアプリケーションの間の双方向のインタフェース変換を提供する、プロトコル変換器と、
   を含む、装置。
2. 前記装置は、クライアントおよびサーバのうちの少なくとも１つに実装可能である、
   請求項１に記載の装置。
3. 前記クロスドメイン通信は、ＨＴＭＬ５（ハイパーテキストマークアップ言語５）のＰｏｓｔＭｅｓｓａｇｅ、メッセージのＵＲＬフラグメント識別子、専用の通信ウェブサービス、ＨＴＭＬ５のローカルストレージ、ＨＴＭＬ５のローカルファイルアクセスＡＰＩ、及び、専用のブラウザプラグインのうちの少なくとも１つである、
   請求項１に記載の装置。
4. 前記少なくとも２つのサードパーティアプリケーションは、ｉｆｒａｍｅを使用して前記ページに埋め込まれる、
   請求項１に記載の装置。
5. 前記少なくとも２つのサードパーティアプリケーションは、少なくともマルチパートサードパーティアプリケーション及びモジュール式サードパーティアプリケーションのうちの少なくとも１つである、
   請求項１に記載の装置。
6. 前記通信ハブは、
   前記少なくとも２つのサードパーティアプリケーションの一方が利用できないときに、前記少なくとも２つのサードパーティアプリケーションの他方と前記ウェブサイトの前記ページの間で、前記ウェブサイト構築システムのユーザが通信メッセージを経路変更できるためのリダイレクタと、
   固有の発信元ＩＤを使用して、前記少なくとも２つのサードパーティアプリケーションからの入力通信メッセージの信頼性を確認し、敵意のあるサードパーティアプリケーションを止めるための発信元確認器と、
   を含む、
   請求項１に記載の装置。
7. ウェブサイト構築システムのための方法であって、
   前記ウェブサイト構築システムによって構築されるウェブサイトのページに、異なるベンダーからの少なくとも２つのサードパーティアプリケーションの間のダイレクトアドレッシングを用いた双方向のクロスドメイン通信を実装し、前記少なくとも２つのサードパーティアプリケーションはそれぞれ前記ページ内にインスタンスを有する、実装ステップであって、
   発信元又は前記少なくとも２つのサードパーティアプリケーションのうちの発信先のサードパーティアプリケーションの前記ダイレクトアドレッシングを識別及び提供し、前記双方向のクロスドメイン通信のためのすべての絶対アドレスのテーブルを維持するステップと、
   前記ウェブサイト構築システムと前記少なくとも２つのサードパーティアプリケーションとの間の通信ポリシーを適用し、前記通信ポリシーに従って非互換の通信をフィルタリングする、ステップと、
   のうちの少なくとも１つを含む、実装ステップと、
   前記少なくとも２つのサードパーティアプリケーションの間の双方向のインタフェース変換を提供する、提供ステップと、
   を含む、方法。
8. 前記クロスドメイン通信は、ＨＴＭＬ５（ハイパーテキストマークアップ言語５）のＰｏｓｔＭｅｓｓａｇｅ、メッセージのＵＲＬフラグメント識別子、専用の通信ウェブサービス、ＨＴＭＬ５のローカルストレージ、ＨＴＭＬ５のローカルファイルアクセスＡＰＩ、及び、専用のブラウザプラグインのうちの少なくとも１つである、
   請求項７に記載の方法。
9. 前記少なくとも２つのサードパーティアプリケーションは、ｉｆｒａｍｅを使用して前記ページに埋め込まれる、
   請求項７に記載の方法。
10. 前記少なくとも２つのサードパーティアプリケーションは、少なくともマルチパートサードパーティアプリケーション及びモジュール式サードパーティアプリケーションのうちの少なくとも１つである、
    請求項７に記載の方法。
11. 前記実装ステップは、
    前記少なくとも２つのサードパーティアプリケーションの一方が利用できないときに、前記少なくとも２つのサードパーティアプリケーションの他方と前記ウェブサイトの前記ページの間で、前記ウェブサイト構築システムのユーザが通信メッセージを経路変更できるステップと、
    固有の発信元ＩＤを使用して、前記少なくとも２つのサードパーティアプリケーションからの入力通信メッセージの信頼性を確認し、敵意のあるサードパーティアプリケーションを止めるステップと、
    を含む、
    請求項７に記載の方法。
12. ウェブサイト構築システムのための装置であって、
    前記ウェブサイト構築システムによって構築されるウェブサイトのページに埋め込まれ、異なるベンダーからの少なくとも２つのサードパーティアプリケーションの間のダイレクトアドレッシングを用いた双方向のクロスドメイン通信を実装し、前記少なくとも２つのサードパーティアプリケーションはそれぞれ前記ページ内にインスタンスを有する通信ハブであって、
    前記少なくとも２つのサードパーティアプリケーションの一方が利用できないときに、前記少なくとも２つのサードパーティアプリケーションの他方と前記ウェブサイトの前記ページの間で、前記ウェブサイト構築システムのユーザが通信メッセージを経路変更できるためのリダイレクタと、
    固有の発信元ＩＤを使用して、前記少なくとも２つのサードパーティアプリケーションからの入力通信メッセージの信頼性を確認し、敵意のあるサードパーティアプリケーションを止めるための発信元確認器と、
    を含む、通信ハブと、
    前記少なくとも２つのサードパーティアプリケーションの間の双方向のインタフェース変換を提供する、プロトコル変換器と、
    を含む、装置。
13. 前記装置は、クライアントおよびサーバのうちの少なくとも１つに実装可能である、
    請求項１２に記載の装置。
14. 前記クロスドメイン通信は、ＨＴＭＬ５（ハイパーテキストマークアップ言語５）のＰｏｓｔＭｅｓｓａｇｅ、メッセージのＵＲＬフラグメント識別子、専用の通信ウェブサービス、ＨＴＭＬ５のローカルストレージ、ＨＴＭＬ５のローカルファイルアクセスＡＰＩ、及び、専用のブラウザプラグインのうちの少なくとも１つである、
    請求項１２に記載の装置。
15. 前記少なくとも２つのサードパーティアプリケーションは、ｉｆｒａｍｅを使用して前記ページに埋め込まれる、
    請求項１２に記載の装置。
16. 前記少なくとも２つのサードパーティアプリケーションは、少なくともマルチパートサードパーティアプリケーション及びモジュール式サードパーティアプリケーションのうちの少なくとも１つである、
    請求項１２に記載の装置。
17. 前記通信ハブは、
    発信元又は前記少なくとも２つのサードパーティアプリケーションのうちの発信先のサードパーティアプリケーションの前記ダイレクトアドレッシングを識別及び提供し、前記双方向のクロスドメイン通信のためのすべての絶対アドレスのテーブルを維持するためのスマート識別子及びアドレッサと、
    前記ウェブサイト構築システムと前記少なくとも２つのサードパーティアプリケーションとの間の通信ポリシーを適用し、前記通信ポリシーに従って非互換の通信をフィルタリングする、通信ポリシーエンフォーサと、
    を含む、
    請求項１２に記載の装置。
18. ウェブサイト構築システムのための方法であって、
    前記ウェブサイト構築システムによって構築されるウェブサイトのページに、異なるベンダーからの少なくとも２つのサードパーティアプリケーションの間のダイレクトアドレッシングを用いた双方向のクロスドメイン通信を実装し、前記少なくとも２つのサードパーティアプリケーションはそれぞれ前記ページ内にインスタンスを有する、実装ステップであって、
    前記少なくとも２つのサードパーティアプリケーションの一方が利用できないときに、前記少なくとも２つのサードパーティアプリケーションの他方と前記ウェブサイトの前記ページの間で、前記ウェブサイト構築システムのユーザが通信メッセージを経路変更するステップと、
    固有の発信元ＩＤを使用して、前記少なくとも２つのサードパーティアプリケーションからの入力通信メッセージの信頼性を確認し、敵意のあるサードパーティアプリケーションを止めるステップと、
    のうちの少なくとも１つを含む、実装ステップと、
    前記少なくとも２つのサードパーティアプリケーションの間の双方向のインタフェース変換を提供する、提供ステップと、
    を含む、方法。
19. 前記クロスドメイン通信は、ＨＴＭＬ５（ハイパーテキストマークアップ言語５）のＰｏｓｔＭｅｓｓａｇｅ、メッセージのＵＲＬフラグメント識別子、専用の通信ウェブサービス、ＨＴＭＬ５のローカルストレージ、ＨＴＭＬ５のローカルファイルアクセスＡＰＩ、及び、専用のブラウザプラグインのうちの少なくとも１つである、
    請求項１８に記載の方法。
20. 前記少なくとも２つのサードパーティアプリケーションは、ｉｆｒａｍｅを使用して前記ページに埋め込まれる、
    請求項１８に記載の方法。
21. 前記少なくとも２つのサードパーティアプリケーションは、少なくともマルチパートサードパーティアプリケーション及びモジュール式サードパーティアプリケーションのうちの少なくとも１つである、
    請求項１８に記載の方法。
22. 前記実装ステップは、
    発信元又は前記少なくとも２つのサードパーティアプリケーションのうちの発信先のサードパーティアプリケーションの前記ダイレクトアドレッシングを識別及び提供し、前記双方向のクロスドメイン通信のためのすべての絶対アドレスのテーブルを維持するステップと、
    前記ウェブサイト構築システムと前記少なくとも２つのサードパーティアプリケーションとの間の通信ポリシーを適用し、前記通信ポリシーに従って非互換の通信をフィルタリングする、ステップと、
    のうちの少なくとも１つを含む、
    請求項１８に記載の方法。

Images