JP7387779B2 - ウェブサイトのためのシステムおよび方法 - Google Patents

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

米国特許出願公開第２０１３／０２１９２６３号明細書

本発明の好ましい実施形態によると、クライアント／サーバシステムを介してウェブサイト上に実装可能なシステムであって、クライアント／サーバシステムが、本システムを定義する命令を処理する少なくとも１つのプロセッサを有する、システム、を提供する。本システムは、ウェブサイトと少なくとも１つのサードパーティアプリケーションとの間の少なくとも１つのアクティビティメッセージを調整する少なくとも１つのハブであって、少なくとも１つのアクティビティメッセージが、標準化されたフォーマットを有する、少なくとも１つのハブ、を含む。さらに、本システムは、少なくとも１つのアクティビティメッセージをリスンし、これら少なくとも１つのメッセージから抽出されたデータを、識別されたコンタクトおよび匿名のコンタクトのうちの少なくとも一方に関連付けられるストリームに少なくとも加える、アクティビティコーディネータであって、識別されたコンタクトおよび匿名のコンタクトのうちの少なくとも一方が、ウェブサイトの利用者である、アクティビティコーディネータ、を含む。さらに、本システムは、コンタクト関連情報をストリームから取得および分析して、コンタクトの以前に保持された情報の質を高める、コンタクトコーディネータと、ウェブサイトおよびコンタクトによって使用できるように、アクティビティストリームおよびコンタクト関連情報を格納する少なくとも１つのデータベースと、を含む。

さらに、本発明の好ましい実施形態によると、少なくとも１つのハブは、ウェブサイトと少なくとも１つのサードパーティアプリケーションとの間の少なくとも１つのアクティビティメッセージをルーティングおよび追跡するルータ／追跡器（router and tracker）と、ウェブサイトと少なくとも１つのサードパーティアプリケーションとの間のプライバシーポリシーを実施するプライバシーポリシーエンフォーサと、ウェブサイトと少なくとも１つのサードパーティアプリケーションとの間の事前に指定される少なくとも１つのメッセージ変換／コンテンツ適合化規則を適用する変換器／適合器（translator and adapter）と、プライベートデータプロキシとプライベートデータ置換のうちの少なくとも一方を実施し、ウェブサイトと少なくとも１つのサードパーティアプリケーションとの間の利用者許可フィールドの制限を実施する、プライベートデータプロキシ（private data proxy）と、少なくとも１つのアクティビティメッセージの署名を、少なくとも１つのサードパーティアプリケーションの入力鍵を使用して検証し、少なくとも１つのアクティビティメッセージに関連付けられる外部ＩＤを内部ウェブサイトＩＤを使用して変換し、送出される少なくとも１つのアクティビティメッセージに、少なくとも１つのサードパーティアプリケーションの出力鍵を使用して署名する、検証器／署名器と、のうちの少なくとも１つ、を含む。

さらに、本発明の好ましい実施形態によると、アクティビティコーディネータは、少なくとも１つのアクティビティメッセージに関連付けられるコンタクトを識別し、関連付けられるコンタクトが存在しない場合にデータのストリームを作成する、ストリーム作成器と、少なくとも１つのアクティビティメッセージからのデータを既存のストリームにマージし、アクティビティストリームのうちの少なくとも２つからのデータを１つのストリームにマージする、ストリームマージャと、アクティビティストリームからのアクティビティデータを少なくとも１つのデータベースに記録するログ作成器と、のうちの少なくとも１つ、を含む。

さらに、本発明の好ましい実施形態によると、コンタクトコーディネータは、少なくとも１つのアクティビティメッセージ、ストリーム、別のコンタクト、外部ソースのうちの少なくとも１つから、コンタクト関連情報を抽出するデータ抽出器と、少なくとも２つのコンタクト情報レコードをマージし、抽出されたコンタクト関連情報を、事前に定義されるマージ規則に従って、既存のコンタクトの関連情報にマージする、データマージャであって、レコードが、同じ識別されたコンタクトとの関連性を有する、データマージャと、識別可能な新しいコンタクトおよび匿名のコンタクトの少なくとも一方を作成し、ウェブサイトのセッションの間、コンタクトのアクティビティを追跡する、コンタクトハンドラと、抽出されたコンタクト関連情報のプライバシー保護および許可を処理するデータ／許可ハンドラと、のうちの少なくとも１つ、を含む。

さらに、本発明の好ましい実施形態によると、ルータ／追跡器は、少なくとも１つのサードパーティアプリケーションによって指定されるリスニングクエリ（listening query）を使用して少なくとも１つのアクティビティメッセージをルーティングすることをサポートする。

さらに、本発明の好ましい実施形態によると、ストリームマージャは、データを、識別されたコンタクトに関連付けられるストリームにマージするアクティビティ－ストリームマージャと（activity-to-stream merger）、少なくとも２つの個別のストリームを１つのストリームにマージするストリーム－ストリームマージャ（stream-to-stream merger）と、を含む。

さらに、本発明の好ましい実施形態によると、ストリーム－ストリームマージャは、少なくとも２つの個別のストリームを、識別された共通のコンタクトに従ってマージする水平ストリームマージャ（horizontal stream merger）と、匿名のコンタクトと、登録されたコンタクトとが、ログイン時または登録時に結びつけられたときに、匿名のコンタクトに対して作成されたストリームを、登録されたコンタクトに関連付けられるストリームにマージする、垂直ストリームマージャ（vertical stream merger）と、のうちの少なくとも一方、を含む。

さらに、本発明の好ましい実施形態によると、データマージャは、コンタクト情報レコードのうちの少なくとも２つの中の同じプライマリＩＤフィールド値を特定する、コンタクト情報レコードのうちの少なくとも２つの中の、正規化されたときに同じであるプライマリＩＤフィールド値を特定する、クッキーを使用してサイト利用者を識別する、登録された利用者の場合にサイトログインを使用してサイト利用者を識別する、ソーシャルネットワークに関連付けられるアカウントを持つサイト利用者の場合にソーシャルログインを通じてサイト利用者を識別する、のうちの少なくとも１つを行うコンタクト識別器、を含む。さらに、データマージャは、言語解析、構文解析、およびテキスト解析のうちの少なくとも１つと、外部データソースおよび外部サービスの参照・利用とを用いて、コンタクト情報を結合する結合器と、コンタクトレコード間の矛盾を、事前に定義される規則に従って解消する矛盾解消器と、リスト値フィールドを作成し、コンタクトレコード間の明確な優先順位を定義する、リスト値作成器と、共通のプライマリＩＤが検出されたことにより、互いに関連しない２人のコンタクトをマージする水平コンタクトマージャ（horizontal contact merger）と、匿名のコンタクトと、登録された利用者に関連付けられるコンタクトとが、ログイン時または登録時に結びつけられたときに、匿名のコンタクトを、登録された利用者に関連付けられるコンタクトにマージする、垂直コンタクトマージャ（vertical contact merger）と、を含む。

さらに、本発明の好ましい実施形態によると、水平コンタクトマージャは、少なくとも２つのコンタクトレコードを個別のレコードとして維持し、これら２つのコンタクトレコードが同じコンタクトを表していることが示されるように２つのコンタクトレコードを互いにリンクする、仮想マージャ（virtual merger）、を含む。

さらに、本発明の好ましい実施形態によると、垂直コンタクトマージャは、匿名のコンタクトと、登録された利用者に関連付けられるコンタクトとを個別のコンタクトとして維持し、匿名のコンタクトおよび登録された利用者に関連付けられるコンタクトが同じコンタクトを表していることが示されるように互いにリンクする、仮想マージャ、を含む。

さらに、本発明の好ましい実施形態によると、利用者許可フィールドは、ウェブサイトもしくはウェブサイトのオーナーまたはその両方によって決定される。

さらに、本発明の好ましい実施形態によると、標準化されたフォーマットは、事前に定義されるスキーマによって定義されるフォーマット、継承によって定義されるフォーマット、コールバックリンクによって定義されるフォーマット、少なくとも１つのサードパーティアプリケーションによって符号化および定義されるフォーマット、外部の正式標準、業界標準、または事実上の標準に基づくフォーマット、のうちの少なくとも１つである。

本発明の好ましい実施形態によると、クライアント／サーバシステムを介してウェブサイト上に実装可能な方法であって、クライアント／サーバシステムが、本方法を定義する命令を処理する少なくとも１つのプロセッサを有する、方法、を提供する。本方法は、ウェブサイトと少なくとも１つのサードパーティアプリケーションとの間の少なくとも１つのアクティビティメッセージを調整するステップであって、少なくとも１つのアクティビティメッセージが、標準化されたフォーマットを有する、ステップと、少なくとも１つのアクティビティメッセージをリスンし、これら少なくとも１つのメッセージから抽出されたデータを、識別されたコンタクトおよび匿名のコンタクトのうちの少なくとも一方に関連付けられるストリームに少なくとも加えるステップであって、識別されたコンタクトおよび匿名のコンタクトのうちの少なくとも一方が、ウェブサイトの利用者である、ステップと、を含む。さらに、本方法は、コンタクト関連情報をストリームから取得および分析して、コンタクトの以前に保持された情報の質を高めるステップと、ウェブサイトおよびコンタクトによって使用できるように、アクティビティストリームおよびコンタクト関連情報を格納するステップと、を含む。

さらに、本発明の好ましい実施形態によると、調整するステップは、ウェブサイトと少なくとも１つのサードパーティアプリケーションとの間の少なくとも１つのアクティビティメッセージをルーティングおよび追跡するステップと、ウェブサイトと少なくとも１つのサードパーティアプリケーションとの間のプライバシーポリシーを実施するステップと、ウェブサイトと少なくとも１つのサードパーティアプリケーションとの間の事前に指定される少なくとも１つのメッセージ変換／コンテンツ適合化規則を適用するステップと、プライベートデータプロキシとプライベートデータ置換のうちの少なくとも一方を実施し、ウェブサイトと少なくとも１つのサードパーティアプリケーションとの間の利用者許可フィールドの制限を実施するステップと、少なくとも１つのアクティビティメッセージの署名を、少なくとも１つのサードパーティアプリケーションの入力鍵を使用して検証し、少なくとも１つのアクティビティメッセージに関連付けられる外部ＩＤを内部ウェブサイトＩＤを使用して変換し、送出される少なくとも１つのアクティビティメッセージに、少なくとも１つのサードパーティアプリケーションの出力鍵を使用して署名するステップと、のうちの少なくとも１つ、を含む。

さらに、本発明の好ましい実施形態によると、リスンして少なくとも加えるステップは、少なくとも１つのアクティビティメッセージに関連付けられるコンタクトを識別し、関連付けられるコンタクトが存在しない場合にデータのストリームを作成するステップと、少なくとも１つのアクティビティメッセージからのデータを既存のストリームにマージし、アクティビティストリームのうちの少なくとも２つからのデータを１つのストリームにマージするステップと、アクティビティストリームからのアクティビティデータを少なくとも１つのデータベースに記録するステップと、のうちの少なくとも１つを含む。

さらに、本発明の好ましい実施形態によると、取得および分析するステップは、少なくとも１つのアクティビティメッセージ、ストリーム、別のコンタクト、外部ソースのうちの少なくとも１つから、コンタクト関連情報を抽出するステップと、少なくとも２つのコンタクト情報レコードをマージし、抽出されたコンタクト関連情報を、事前に定義されるマージ規則に従って、既存のコンタクトの関連情報にマージするステップであって、レコードが、同じ識別されたコンタクトとの関連性を有する、ステップと、のうちの少なくとも１つを含む。さらに、取得および分析するステップは、識別可能な新しいコンタクトおよび匿名のコンタクトの少なくとも一方を作成し、ウェブサイトのセッションの間、コンタクトのアクティビティを追跡するステップと、抽出されたコンタクト関連情報のプライバシー保護および許可を処理するステップと、を含む。

さらに、本発明の好ましい実施形態によると、ルーティングおよび追跡するステップは、少なくとも１つのサードパーティアプリケーションによって指定されるリスニングクエリを使用して少なくとも１つのアクティビティメッセージをルーティングすることをサポートする。

さらに、本発明の好ましい実施形態によると、マージするステップは、データを、識別されたコンタクトに関連付けられるストリームにマージするステップと、少なくとも２つの個別のストリームを１つのストリームにマージするステップ、を含む。

さらに、本発明の好ましい実施形態によると、データを識別されたコンタクトに関連付けられるストリームにマージするステップと、少なくとも２つの個別のストリームを１つのストリームにマージするステップは、少なくとも２つの個別のストリームを、識別された共通のコンタクトに従って水平にマージする（horizontally merging）ステップと、匿名のコンタクトと、登録されたコンタクトとが、ログイン時または登録時に結びつけられたときに、匿名のコンタクトに対して作成されたストリームを、登録されたコンタクトに関連付けられるストリームに垂直にマージする（vertically merging）ステップと、のうちの少なくとも一方を含む。

さらに、本発明の好ましい実施形態によると、少なくとも２つのコンタクト情報レコードをマージするステップは、コンタクト情報レコードのうちの少なくとも２つの中の同じプライマリＩＤフィールド値を特定するステップ、コンタクト情報レコードのうちの少なくとも２つの中の、正規化されたときに同じであるプライマリＩＤフィールド値を特定するステップ、クッキーを使用してサイト利用者を識別するステップ、登録された利用者の場合にサイトログインを使用してサイト利用者を識別するステップ、ソーシャルネットワークに関連付けられるアカウントを持つサイト利用者の場合にソーシャルログインを通じてサイト利用者を識別するステップ、のうちの少なくとも１つを含む。さらに、少なくとも２つのコンタクト情報レコードをマージするステップは、言語解析、構文解析、およびテキスト解析のうちの少なくとも１つと、外部のデータソースおよび外部サービスの参照・利用とを用いて、コンタクト情報を結合するステップと、コンタクトレコード間の矛盾を、事前に定義される規則に従って解消するステップと、リスト値フィールドを作成し、コンタクトレコード間の明確な優先順位を定義するステップと、共通のプライマリＩＤが検出されたことにより、互いに関連しない２人のコンタクトを水平にマージするステップと、匿名のコンタクトと、登録された利用者に関連付けられるコンタクトとが、ログイン時または登録時に結びつけられたときに、匿名のコンタクトを、登録された利用者に関連付けられるコンタクトに垂直にマージするステップと、を含む。

さらに、本発明の好ましい実施形態によると、水平にマージするステップは、少なくとも２つのコンタクトレコードを個別のレコードとして維持し、これら２つのコンタクトレコードが同じコンタクトを表していることが示されるように２つのコンタクトレコードを互いにリンクして仮想的にマージする（virtual merging）ステップ、を含む。

さらに、本発明の好ましい実施形態によると、垂直にマージするステップは、匿名のコンタクトと、登録された利用者に関連付けられるコンタクトとを個別のコンタクトとして維持し、匿名のコンタクトおよび登録された利用者に関連付けられるコンタクトが同じコンタクトを表していることが示されるようにこれらを互いにリンクして仮想的にマージするステップ、を含む。

さらに、本発明の好ましい実施形態によると、利用者許可フィールドは、ウェブサイトもしくはウェブサイトのオーナーまたはその両方によって決定される。

さらに、本発明の好ましい実施形態によると、標準化されたフォーマットは、事前に定義されるスキーマによって定義されるフォーマット、継承によって定義されるフォーマット、コールバックリンクによって定義されるフォーマット、少なくとも１つのサードパーティアプリケーションによって符号化および定義されるフォーマット、外部の正式標準、業界標準、または事実上の標準に基づくフォーマット、のうちの少なくとも１つである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

デザイナー５は、サードパーティアプリケーション４０のベンダーまたは外部業者によって運営されている外部のＡｐｐＳｔｏｒｅなど、ＡｐｐＳｔｏｒｅ ２５の外部のチャネルを通じて、サードパーティアプリケーション４０を取得することができることを理解されたい。このような場合、ウェブサイト構築システム３０は、デザイナー５によってウェブサイト構築システム３０を通じて作成されたウェブサイトにそのサードパーティアプリケーション４０を最初にインストールするときに、サードパーティアプリケーション４０およびその構成データ（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）をサポートするウェブサイト構築システム３０の中から継承するページ）の中での［ｄ］および［ｅ］の使用に適用されるのみであり、ＡｐｐＳｔｏｒｅ［ｂ］内のサードパーティアプリケーション［ａ］に関連付けられる「元の」テンプレート［ｃ］には影響しない。

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

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

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

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

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

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

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

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

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

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

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

上述したように、通信ハブ２０５は、通信を促進することができ、含有ウェブページとサードパーティアプリケーション４０との間のバックチャネルを提供することができる。出願人は、含有ウェブページとサードパーティアプリケーション４０との間で双方向に送られるデータは、これらをいったん集めて処理し、統合した後に有用であることをさらに認識した。

例えば、ウェブサイトのオーナーは、自身のサイトあたりの利用者数やメンバーシップを管理する必要があり、これらは関連するウェブサイト構築システム３０の登録利用者をベースとする値とは異なる。ウェブサイトの利用者は、登録する、または登録しない（匿名）ことができ、ウェブサイトは、異なるレベルの利用者に異なるレベルの機能を提供することができる。さらには、利用者は（たとえ匿名利用者であっても）、インスタントメッセンジャーソフトウェアを起動してサイトのオーナーに連絡するときや、サイトでのアクティビティの一部としてソーシャルネットワークに接続するときに、個人情報や連絡先情報（例えばコンタクトフォームにおけるデータ）をしばしば提供する。これらの情報は、作成されたサイトに直接的に入力される、または、サイト内に埋め込まれているサードパーティアプリケーションとのインタラクションの一部として利用可能になることを理解されたい。

さらに、これらの情報は、組織化されておらず、互いに関連しておらず、場合によっては矛盾を含み、多くの場合には保存されないことを理解されたい。例えば、ある１人の利用者が、自分のプライベートな電子メールアドレスを、（サイトによって直接管理されている）コンタクトフォームに入力し、同じセッションにおいて、仕事用の電子メールアドレスを、（サードパーティアプリケーション４０によって管理されている）別のサブスクリプションフォームに入力することがある。

さらには、これらの「流動的な」情報には、その情報の使用に関する異なる許可が含まれることがある。例えば、サブスクリプションフォームに自分の電子メールアドレスを入力した利用者は、自分が加入した電子メールベースのサブスクリプションおよび場合によっては関連する電子メールニュースレターを受信することを予期する。これに対して、登録ＩＤとして電子メールアドレスを開示した利用者は、自分のアカウントの取扱いやセキュリティ警告などに関する電子メールを除いて、自分の登録アドレス宛の電子メールを受け取ることを望まないことがある。

次に図１５を参照し、この図は、ウェブサイト構築システム３０と１つまたは複数の埋め込まれたサードパーティアプリケーション４０との間で交換されるさまざまなメッセージからのデータを調整および収集するシステム２００を示している。システム２００は、クライアント２２０にインストールされているクライアントハブ２１０と、サーバ２６０にインストールされているサーバハブ２３０、コンタクトコーディネータ２４０、アクティビティコーディネータ２５０、コンタクトデータベース２４５、およびアクティビティストリームデータベース２５５とを備えている。ハブ２１０およびハブ２３０は、ハブ２０５に関連して上述したように、ウェブサイト構築システム３０と、サーバ２７０にインストールされている複数のサードパーティアプリケーションとの間の通信と、複数の異なるサードパーティアプリケーション４０間の通信とを促進できることを理解されたい。コンタクトデータベース２４５およびアクティビティストリームデータベース２５５は、後からさらに詳しく説明するように、コンタクト情報およびアクティビティ情報と、メッセージストリームから抽出される情報とを保持することができる。

次に図１６Ａおよび図１６Ｂを参照し、図１６Ａは、クライアントハブ２１０の要素を示しており、図１６Ｂは、サーバハブ２３０の要素と、コンタクトコーディネータ２４０の要素と、アクティビティコーディネータ２５０の要素とを示している。クライアントハブ２１０は、ルータ２１１と、変換器／適合器２１２と、プライバシーポリシーエンフォーサ２１３とを備えている。サーバハブ２３０は、ルータ／追跡器２３１と、変換器／適合器２３２と、プライバシーポリシーエンフォーサ２３３と、プライベートデータプロキシ２３４と、検証器／署名器２３５とを備えている。コンタクトコーディネータ２４０は、データ抽出器２４１と、コンタクトハンドラ２４２と、データマージャ２４３と、データ／許可ハンドラ２４４とを備えている。アクティビティコーディネータ２５０は、ストリーム作成器２５１と、ストリームマージャ２５２と、ログ作成器２５３とを備えている。これらの要素の機能については、後からさらに詳しく説明する。

次に図１６Ｃおよび図１６Ｄを参照し、図１６Ｃは、ストリームマージャ２５２の要素を示しており、図１６Ｄは、データマージャ２４３の要素を示している。ストリームマージャ２５２は、アクティビティ－ストリームマージャ２６１と、ストリーム－ストリームマージャ２６２とを備えている。ストリーム－ストリームマージャ２６２は、水平ストリームマージャ２６３と、垂直ストリームマージャ２６４をさらに備えている。データマージャ２４３は、コンタクト識別器２７２と、結合器２７３と、矛盾解消器２７４と、リスト値作成器２７５と、垂直コンタクトマージャ２７６と、水平コンタクトマージャ２７７とを備えている。水平コンタクトマージャ２７７は、仮想水平マージャ２７８をさらに備えている。垂直コンタクトマージャ２７６は、仮想垂直マージャ２７９をさらに備えている。これらの要素の機能については、後からさらに詳しく説明する。

システム２００は、システム２００と複数のサードパーティアプリケーションとの間のメッセージパッシングを可能にする一方で、さまざまな機能、すなわち、アクティビティメッセージをストリームによって組織化する、アクティビティメッセージの履歴を格納する、マルチレベルでのアクティビティメッセージのメッセージパッシング、アクティビティメッセージ用にサイドチャネル（side channel）を使用する、アクティビティメッセージを変換およびコンテンツを適合化する、アクティビティメッセージを検証およびアクティビティメッセージに署名する、リスナークエリ（listener query）を使用してアクティビティメッセージを動的にルーティングする、などの機能を提供することを理解されたい。これらの機能については後から詳しく説明する。

さらに、システム２００は、利用者に関連する情報を抽出してそれらをマージする（複数のソースからの情報およびシステム２００の中にすでに存在する情報を結合する）ことができる。マージは、異なる種類の、場合によっては互いに矛盾する情報を調整するマージ規則を通じて行うことができる。結合された情報は、コンタクトデータベース２４５に格納することができる。この情報には、後からさらに詳しく説明するように、集められた情報の許可される用途（allowed use）を制御する使用許可フィールドをさらに含めることができる。

本発明の代替実施形態においては、クライアントハブ２１０およびサーバハブ２３０のいずれかを単独で使用して、サーバ２７０にインストールされている複数のサードパーティアプリケーション４０と通信することができる。クライアントハブ２１０のみが使用される状況では、コンタクトコーディネータ２４０と、アクティビティコーディネータ２５０と、データベース２４５，２５５とを、関連するクライアントにローカルにインストールできることを理解されたい。

さらには、システム２００は、さらなるコンポーネントとして、サードパーティアプリケーション４０が、利用者自身によって設定される使用制限を実施しながら、利用者に連絡するアクティビティ（例えばニュースレターの大量送信）を管理することを可能にするコンポーネントを備えることができることを理解されたい。このようなコンポーネントは、利用者のプライベートデータをサードパーティアプリケーション４０から隔離することもできる（したがってサードパーティアプリケーション４０は、利用者のプライベートデータに実際にアクセスすることなくそれぞれの動作を実行することができる）。このような機能は、例えば、後からさらに詳しく説明するようにプライベートデータプロキシ２３４を使用して実施することができる。

さらに、コンタクトデータベース２４５は、各サイトに固有とすることができることを理解されたい。しかしながら、ウェブサイト構築システム３０では、（同じサイトオーナーによって所有される）ウェブサイトの集合を含むメタサイト／メタプロジェクトレベルを定義することができ、コンタクトが単一サイトレベルではなくメタサイトレベルで格納、処理、およびマージされることを指定することができる。サイトのそれ以外の要素（含まれているサードパーティアプリケーション４０など）も、サイトレベルではなくメタサイトレベルで定義することができる。メタサイトをサポートする以外は、一般にシステム２００は、異なるサイトの間または異なるサイトオーナーの間でコンタクトを共有することはなく（ただし後から説明する状況を除く）、コンタクト情報を統合することもない（したがって、あるエンドユーザによって１つのサイトに提供されたデータは別のサイトに漏れない）。

上述したように、システム２００は、ウェブサイト構築システム３０と１つまたは複数のサードパーティアプリケーション４０との間の複数のインタラクションをサポートすることができる。このようなインタラクションは、買物をする、アイテムをショッピングカートに追加する、連絡先情報を入力するなど、事前に定義されるアクティビティとすることができる。あるサードパーティアプリケーション４０が、自身がサポートするアクティビティを指定することができ、他のサードパーティアプリケーション４０が、特定のアクティビティを「リスン」して、受け取ったアクティビティおよびそれに関連付けられる情報に基づいて動作することができる。特定のサードパーティアプリケーション４０においてリスンされるアクティビティのリストは、明示的に１つまたは複数のアクティビティに設定する、または後からさらに詳しく説明するように、アクティビティリスニングクエリによって決定することができることを理解されたい。

各アクティビティは、メッセージと考えることができ、各メッセージはアクティビティデータ構造体を含むことができることを理解されたい。アクティビティデータ構造体は、事前に定義されるデータ型であるが、互いの間の継承を通じて定義する、あるいは（フィールドを追加することによってアクティビティデータ構造体を拡張するオプションを有する）サードパーティアプリケーション４０を通じて定義することもできる。アクティビティデータ構造体は、システムに固有とする、あるいは、標準化されているデータ構造に基づく、または標準化されているデータ構造を含むことができる。アクティビティデータ構造体は、何らかの方法（ＸＭＬ、ＪＳＯＮデータ、またはバイナリオブジェクト符号化方式を使用するなど）で符号化することもできる。

さらに、アクティビティデータ構造体は、サードパーティアプリケーション４０によって提供される「説明」フィールドを含むことができる。これは、サードパーティアプリケーション４０によって定義される、アクティビティの説明である（ウェブサイト構築システム３０に認識されている説明よりも詳細にすることができる）。例えば、ＶＯＩＰ通信のサードパーティアプリケーション４０は、「Call to John Smith at 999-555-1234 - 01:15（ジョンスミス（９９９－５５５－１２３４）に電話（０１：１５））」というアクティビティ説明テキストを提供することができる。

さらに、アクティビティデータ構造体は、コールバックリンク、例えば「さらなる情報」（アクティビティデータ構造体に戻る）を含むことができる。コールバックリンクは、追加の重要な情報を提供する目的に使用することができ、例えば、電子商取引のアクティビティデータ構造体の場合には、注文の完全な追跡情報や注文履歴などであり、チャットのアクティビティデータ構造体の場合には、完全なチャットログであり、電話のアクティビティデータ構造体の場合には、通話記録である。したがって、一例としての完全なアクティビティデータ構造体は、以下のフィールド、すなわち、作成時刻、アクティビティの種類、アクティビティの発生元（サードパーティアプリケーション４０／コンポーネントのＩＤ）、アクティビティストリームＩＤ、アクティビティの種類に固有な情報（アクティビティの種類に依存する）、作成サイトＩＤ、サイトメンバーデータベースＩＤ、アクティビティが行われたサイトページのＩＤ／ＵＲＬ、サードパーティアプリケーション４０によって提供されるアクティビティの説明、サードパーティアプリケーション４０によって使用されるさらなる情報リンクおよび取得された利用者の詳細情報など、を含むことができる。

アクティビティコーディネータ２５０は、ロギング要素と考えることができ、ハブ２３０から渡されるメッセージからデータを受け取る。ストリーム作成器２５１は、初期ストリーム（ログまたはチェーン状の構造と考えることができる）を作成することができ、ストリームマージャ２５２は、この初期ストリームに、それ以降に入ってくるアクティビティを加えることができ、このとき各ストリームはコンタクトに固有である。ストリーム作成器２５１は、異なるメッセージに含まれる個別のアクティビティごとに新しいストリームを作成しなくてよいことを理解されたい。さらには、ストリームに含まれる複数のアクティビティは、正しい順序でないことがある（例えばアクティビティの報告において、あるサードパーティアプリケーション４０が遅れることがある）ことを理解されたい。ストリームマージャ２５２は、動作時、複数のストリームが同じ１人のコンタクトに属している場合にそれらのストリームをマージすることができ、ログ作成器２５３は、それ以前に作成されたすべてのアクティビティストリームのアクティビティストリームデータベース２５５に、ログファイルを保存することができる。

図１６Ｃに関連して上述したように、ストリームマージャ２５２は、アクティビティ－ストリームマージャ２６１と、ストリーム－ストリームマージャ２６２とを備えている。アクティビティ－ストリームマージャ２６１は、アクティビティを、識別されたコンタクトに関連付けられるストリームに関連付けることができ、ストリーム－ストリームマージャ２６２は、２つの個別のストリームを１つのストリームに変換することができる。水平ストリームマージャ２６３は、共通のプライマリＩＤが検出されたことにより、互いに関連していない２つのストリームをマージすることができ、垂直ストリームマージャ２６４は、匿名のコンタクトに対して作成されたストリームと、登録された利用者に関連付けられるストリームとが、ログイン時または登録時に結びつけられたときに、これら２つのストリームをマージすることができる。ストリームマージャ２５２は、必要時に、アクティビティストリームデータベース２５５の中の以前に作成されたストリームにアクセスできることを理解されたい。

例えば、匿名利用者がサイト内でコンタクトフォームに入力する。ストリーム作成器２５１は、（ＩＤ「ａｎｏｎ１」を有する）新しいアクティビティストリームを作成し、コンタクトハンドラ２４２は、（後からさらに詳しく説明するようにＩＤ「ａｎｏｎ１」を有する）新しいコンタクトを作成する。次いで、この同じ利用者が、サイトのオーナーとチャットする。ストリームマージャ２５２は、このアクティビティを「ａｎｏｎ１」アクティビティストリームにマージし、（後からさらに詳しく説明するように）コンタクト「ａｎｏｎ１」が更新される。次に、この利用者は、別のブラウザを使用して、スケジュールフォーム（schedule form）に入力する。最初の利用者との相互関係がないため、ストリーム作成器２５１は、ＩＤ「ａｎｏｎ２」を有する新しいアクティビティストリームを作成し、コンタクトハンドラ２４２は、ＩＤ「ａｎｏｎ２」を有する新しいコンタクトを作成する。

次に、この利用者は、このサイトから買物をする。ストリームマージャ２５２は、この新しいアクティビティを「ａｎｏｎ２」アクティビティストリームにマージし、コンタクト「ａｎｏｎ２」を（例えば「顧客」タグを使用して）更新する。

この利用者は、さらに別のブラウザを使用して、このサイトに登録する。登録されると、すべての利用者は、サイトのメンバーシップハンドラからＩＤ「利用者ｘ」を受け取る。この時点で、ストリーム作成器２５１は、（ＩＤ「利用者ｘ」を有する）新しいアクティビティストリームを作成し、コンタクトハンドラ２４２は、（同じＩＤ「利用者ｘ」を有する）新しいコンタクトを作成する。

その後、この利用者は別のブラウザから再びサイトにアクセスし、サイトのオーナーとチャットする。このウェブサイトではクッキーが使用されないため、ストリーム作成器２５１は、さらに別の新しいストリームＩＤ「ａｎｏｎ３」を作成し、コンタクトハンドラ２４２は、新しいコンタクト「ａｎｏｎ３」を作成する。

次に、この利用者はこのウェブサイトにログインする。この時点で、ＩＤ「ａｎｏｎ３」およびＩＤ「利用者ｘ」を有するコンタクトが存在する。データマージャ２４３は、コンタクト「ａｎｏｎ３」を「利用者ｘ」にマージすることができ、したがって、「利用者ｘ」のストリームにおけるログインアクティビティと、コンタクト「利用者ｘ」のログインアクティビティの両方が、アクティビティストリーム「利用者ｘ」および「ａｎｏｎ３」を指している。ストリームマージャ２５２は、このセッションにおいて利用者によって実行された追加の動作を、「利用者ｘ」のアクティビティストリームにマージすることができる。ログ作成器２５３は、これらのストリームからのすべてのアクティビティデータをロギングし、ログのコピーをアクティビティデータベース２５５に保存することができる。

次に図１７を参照し、サイトのオーナーは、図１７に示した、ウェブサイト構築システム３０によって提供される関連するユーザインタフェースを通じて、特定のコンタクトのアクティビティストリームの履歴にアクセスできることを理解されたい。１人のコンタクト「Ｄａｎｉ Ｂｒｏｎｓｔｅｉｎ」について、ウェブサイトの利用履歴に容易にアクセスすることができる。さらに、ウェブサイト構築システム３０またはサードパーティアプリケーション４０は、ログ情報にアクセスするためのＡＰＩを提供することもできることを理解されたい。アクティビティのログは、最適化、ユーザインタフェースの改良、広告のターゲティングなどの目的に使用できることを理解されたい。

さらには、これと並行して、コンタクトコーディネータ２４０は、アクティビティストリーム（メッセージ）によって提供されるデータから情報を集めて、対象の利用者のコンタクトプロファイル（contact profile）を構築できることを理解されたい。データ抽出器２４１は、アクティビティメッセージおよびアクティビティストリームからデータを抽出することができ、データマージャ２４３は、関連するデータを特定のコンタクトにマージすることができ、このコンタクトの詳細情報は、コンタクトデータベース２４５に格納することができ、コンタクトデータベース２４５からアクセスすることができる。コンタクトハンドラ２４２は、新しいコンタクトを作成することができ、またサイト利用者の識別情報（匿名利用者など）を処理することができ、データ／許可ハンドラ２４４は、関連するデータのプライバシー保護および許可を処理することができる。データマージャ２４３は、上述したように、水平コンタクトマージャ２７７と、垂直コンタクトマージャ２７６とを備えている。水平コンタクトマージャ２７７は、共通のプライマリＩＤが検出されたことにより、互いに関連しない２人のコンタクトをマージすることができ、垂直コンタクトマージャ２７６は、匿名のコンタクトと、登録された利用者に関連付けられるコンタクトとが、ログイン時または登録時に結びつけられたときに、前記匿名のコンタクトを、登録された利用者に関連付けられる前記コンタクトにマージすることができる。水平コンタクトマージャ２７７は仮想水平マージャ２７８をさらに備えていることができ、この仮想水平マージャ２７８は、２人のコンタクトを個別のコンタクトとして維持するが、これら２人のコンタクトが同じコンタクトを表していることが示されるようにこれらを互いにリンクする（実際のコンタクト情報をマージする、またはマージしない）。垂直コンタクトマージャ２７６は仮想垂直マージャ２７９をさらに備えていることができ、この仮想垂直マージャ２７９は、匿名のコンタクトと、登録された利用者に関連付けられるコンタクトとを個別のコンタクトとして維持するが、これら２人のコンタクトが同じコンタクトを表していることが示されるようにこれらを互いにリンクする（実際のコンタクト情報をマージする、またはマージしない）。さらに、データマージャ２４３は、（一般にはデータ抽出器２４１から抽出された）コンタクト情報を、既存のコンタクトにマージすることができる。コンタクト識別器２７２は、クッキーを使用して利用者の識別情報を追跡することができ、マージするべきコンタクトを、後らからさらに詳しく説明するようにして認識できることを理解されたい。

再び図１５、図１６Ａ、および図１６Ｂを参照し、メッセージパッシングは、クライアント２２０もしくはサーバ２６０またはその両方において実行することができる。サードパーティアプリケーション４０は、一般には、クライアント側要素およびサーバ側要素を有する、または少なくとも、サードパーティアプリケーション４０のプロバイダのサーバ２７０とのサーバ側接続を有することを理解されたい。ハブ２１０は、クライアント２２０とサードパーティアプリケーション４０との間のメッセージを処理することができ、ハブ２３０は、サーバ２６０とサードパーティアプリケーション４０との間のメッセージを処理することができる。ハブ２１０によって受信されたデータは、処理した後、後からさらに説明するさらなる処理のためにハブ２３０に転送できることを理解されたい。

次に図１８を参照し、この図は、異なるプラットフォームの間でのメッセージパッシングのシナリオを示している。利用者のクライアントマシンＸを、サーバＹ上のウェブサイト構築システム３０に接続することができる。ウェブサイト構築システム３０は、ウェブサイト構築システム３０のクライアントコンポーネントＡ’と、ウェブサイト構築システム３０のサーバコンポーネントＡとを使用して実装することができる。作成されたサイトが表示されるとき、サイトはクライアント側要素（データ／コード）Ｂ’とサーバ側要素Ｂとを含むことができる。作成されたサイトは、さらに３つのサードパーティアプリケーション４０（ＴＰＡ１、ＴＰＡ２、およびＥＴＰＡ３）を含むことができる。

ＴＰＡ１は、クライアント側コンポーネントＤ’と、ＴＰＡ１のベンダーのサーバＨに接続されているサーバ側コンポーネントＤとによって実装することができる。ＴＰＡ２は、クライアント側コンポーネントＥ’と、ＴＰＡ２のベンダーのサーバＩに接続されているサーバ側コンポーネントＥによって実装することができる。しかしながら、ＥＴＰＡ３は、サーバ側コンポーネントＧによって実装されているサーバ側のみのサードパーティアプリケーション４０とすることができ、サーバ側コンポーネントＧはウェブサイト構築システム３０のサードパーティアプリケーション４０サポートバックエンドＦに接続されている。これら２つのコンポーネントは、サードパーティアプリケーション４０のベンダーのサーバＪと通信することができる。

ＴＰＡ１およびＴＰＡ２は、クライアント上で（コンポーネントＤ’とコンポーネントＥ’との間で）、もしくはサーバ上で（コンポーネントＤとコンポーネントＥとの間で）、またはクライアントおよびサーバの両方において、メッセージを交換できることを理解されたい。しかしながら、ＥＴＰＡ３との通信は、サーバ上でのみ行わなければならない。さらには、いずれか一方の方法を使用することにはメリットとデメリットがあることを理解されたい。クライアント側でのアクティビティメッセージの送信は、よりインタラクティブとすることができ、利用者の応答がより高速となる。サーバ側でのアクティビティメッセージの送信は、堅牢性および信頼性を高めることができ（例えば利用者はプロセスの途中でブラウザのウィンドウを閉じることができない）、メッセージが正しい順序で受信されるようにされ、さらには、バックエンドにインストールされているバックエンドサードパーティアプリケーション４０またはアプリケーションダッシュボードにアクティビティメッセージを送ることができる。これらのバックエンドサードパーティアプリケーション４０は、クライアント側には表示されないことを理解されたい。

複数のサードパーティアプリケーション４０を使用するケースとして、例えば、ある利用者がサードパーティアプリケーションＡにおいて商品をショッピングカートに追加する（アクティビティのタイプは「カートの変更」）。するとサードパーティアプリケーションＡは、商品が追加されたことに関するアクティビティメッセージをウェブサイト構築システム３０に送る。ウェブサイト構築システム３０は、「カートの変更」に登録されているすべてのサードパーティアプリケーション４０に、このアクティビティを転送する。サードパーティアプリケーションＢは登録されているため、このアクティビティを受信する。サードパーティアプリケーションＢは、「さらに商品Ｘも購入すると割引が適用されます」あるいは「このサイトをシェアすると割引が適用されます」などのメッセージを利用者に表示することができる。

別の例としては、ある利用者がサードパーティアプリケーションＡにおいて（例えばフェイスブックを介して）何かに対して「いいね！ボタンを押す」。するとサードパーティアプリケーションＡは、アクティビティのタイプ「フェイスブックのいいね！」に関するアクティビティメッセージをウェブサイト構築システム３０に送る。ウェブサイト構築システム３０は、「いいね！ボタンを押す」アクティビティに登録されているすべてのサードパーティアプリケーション４０に、このアクティビティを転送する。サードパーティアプリケーションＢは登録されているため、このアクティビティを受信する。サードパーティアプリケーションＢは、リエンゲージメント（re-engagement）ウィジェットを利用者に示し、「このサイトがお気に入りなら、サイトのオーナーに連絡してみませんか？」あるいは「割引クーポンをご希望ですか？」などのメッセージを表示することができる。

上述したように、すべての通信はハブ２１０およびハブ２３０を介して行うことができる。

ルータ２１１は、クライアント側メッセージをウェブサイトと任意のサードパーティアプリケーション４０との間でルーティングすることができる。さらに、ルータ２１１は、後からさらに詳しく説明するように、さらなる処理のためハブ２１０とハブ２３０との間でメッセージをルーティングすることができる。

ルータ／追跡器２３１は、ウェブサイトと任意のサードパーティアプリケーション４０との間でメッセージをルーティングすることができ、さらにメッセージを追跡することができる。さらに、サードパーティアプリケーション４０は、クライアントおよびサーバの両方においてメッセージをリスンすることができることを理解されたい。さらには、サードパーティアプリケーション４０は、自身がリスンする１つまたは複数のアクティビティを明示的に指定することができる（例えば、「ショッピングカート： アイテムを追加する」アクティビティすべてをリスンする）ことを理解されたい。さらに、サードパーティアプリケーション４０は、自身がリスンするアクティビティのクラスを指定することができる（例えば、フェイスブックに関連するすべてのアクティビティをリスンする）。さらには、サードパーティアプリケーションは、アクティビティをそのサードパーティアプリケーションに送るべきか否かを判定する目的に使用されるワイルドカード表現（アクティビティ名に適用される）を使用することができる。

さらに、サードパーティアプリケーション４０は、アクティビティリスナークエリを使用できることを理解されたい。このようなクエリは、サードパーティアプリケーション自体から通常では利用できない情報を含む、追加のシステム情報を参照し、例えば、利用者の属性（例：登録利用者のみ、ヨーロッパの利用者のみ）、ウェブサイトの属性または構造（例：特定のページテンプレートから作成されたページ上の特定のアクティビティのみをリスンする）、利用者履歴（例：利用者が過去にＸを超える買い物を行った場合にのみカート清算アクティビティをリスンする）などである。このようなクエリは、サードパーティアプリケーション４０によって指定することができるが、デザイナーによって編集可能とすることもできる。

したがって、ルータ／追跡器２３１は、サードパーティアプリケーション４０によってリスンされているメッセージを追跡することもできる。このようなアクティビティリスナークエリのアーキテクチャは、（サードパーティアプリケーション４０の内側のＡＰＩ呼出しによって実行されるのではなく）アクティビティのルーティングレベルにおいて実装するのが最良であり、なぜならこれによりウェブサイトのデザイナーは、サードパーティアプリケーション４０が高度にプログラム可能およびカスタマイズ可能である必要なしに、調整およびカスタマイズを実行できるためであることを理解されたい。さらに、ルータ／追跡器２３１は、利用者のプライバシーを保護するうえでも役立ち、なぜならウェブサイトのデザイナーは、（ルーティングの決定に必要な）追加の情報を、関与するサードパーティアプリケーション４０に提供する必要がないためである。さらに、ルータ／追跡器２３１は、サードパーティアプリケーション４０との不要な通信の実行（しばしば別のサーバによってホストされる）を抑制することができる。

ウェブサイトを訪問する、ウェブサイトに登録する、ウェブサイトに情報を提供するのは、利用者（ウェブサイト訪問者）であることを理解されたい。利用者は、自身がアクセスしているウェブサイトが、ウェブサイト構築システム３０、コンポーネント、作成されたウェブサイト、およびサードパーティアプリケーション４０の組合せを使用して構築されていることを実際には認識していないことがある。したがって、利用者のプライバシーに関する責任は、最終的にはウェブサイトのオーナーにある（さらにオーナーは、自身のウェブサイトに含まれているサードパーティアプリケーション４０によって行われるアクティビティに関する責任も負う）。

さらには、サードパーティアプリケーション４０（およびウェブサイト構築システム３０の他のコンポーネント）は、ウェブサイト構築システム３０によって定義されるプライバシー規則に基づき、ウェブサイト構築システム３０によって提供されるＡＰＩを通じて、利用者プロファイル情報にアクセスできることを理解されたい。さらには、含有側サイトおよびそこに含まれるサードパーティアプリケーション４０は、コンタクト情報を使用して（電子メールまたはその他の手段を介して）利用者と通信することができる。

プライバシーに関連する３つの大きな問題が存在しうることを理解されたい。最初の問題は、ウェブサイトおよびウェブサイト構築システム３０と、サードパーティアプリケーション４０のプロバイダとの間の相互関係である。ウェブサイト（およびウェブサイト構築システム３０）は、利用者データの使用に関してサードパーティアプリケーション４０を完全に信頼することができず、例えば、サードパーティアプリケーション４０が（サイトによって提供される利用者の電子メールアドレスを使用して）大量に電子メールを送信しないこと、メール配信リストから削除するように要求した利用者にスパムメールを送信しないこと、あるいは利用者の個人情報を他の第三者に譲渡しないことに関してである。しかしながら、この問題は以下の方法で解決することができる。

ウェブサイト構築システム３０のベンダーは、サードパーティアプリケーション４０のプロバイダをウェブサイト構築システム３０のアプリケーションマーケット（application market）に加えるときに、サードパーティアプリケーション４０のプロバイダに、利用規約（ＴｏＵ）同意書に署名するように要求することができる。このような同意書には、サードパーティアプリケーション４０（およびサードパーティアプリケーション４０のプロバイダ）が利用者の情報を不正に使用したり、第三者に開示したりしてはならないことを記載することができる。これにより、ウェブサイト構築システム３０のベンダーは、サードパーティアプリケーション４０のプロバイダが情報を不正に使用した場合に、そのプロバイダに罰則を適用することができる（例えば、サードパーティアプリケーション４０を無効にする、ウェブサイト構築システム３０のアプリケーションマーケットからサードパーティアプリケーション４０を削除する）。プライバシーポリシーエンフォーサ２１３，２３３およびプライベートデータプロキシ２３４は、後からさらに詳しく説明するように、サードパーティアプリケーション４０に対してプライバシーポリシーを実施することができる。

プライバシーに関連する２番目の問題は、ウェブサイトおよびウェブサイト構築システム３０と利用者（サイトの訪問者）との間の相互関係である。ウェブサイトは、利用者の個人データがどのように使用されるかに関する明確な認識を利用者に提示し、利用者からの同意を受け、利用者が同意した条項を遵守しなければならない。ウェブサイト構築システム３０は、利用者に属する個人情報の許可される用途を定義した利用規約文書を利用者に提示するように、公開されているすべてのサイトに要求し、この場合、利用者はその文書に電子署名するように要求される。サイトは、これらの条項および許可される用途を遵守しなければならない。さらに、ウェブサイト構築システム３０は、自身が提供するウェブサイトテンプレートそれぞれにサンプルの利用規約ページを含めることができる。プライバシーポリシーエンフォーサ２１３，２３３は、利用規約文書の利用規約が確実に守られるようにすることができる。さらに、プライバシーポリシーエンフォーサ２１３，２３３は、関連するデータを削除または再編成することによって、許可された情報のみがサードパーティアプリケーションに提供されるようにすることができる。

プライバシーに関連する３番目の問題は、配信停止要求をサポートすることである。サイトは、任意のマーケティング電子メールを配信停止するオプションを利用者に提供しなければならない。これは、後からさらに詳しく説明されているデータ／許可ハンドラ２４４によって処理することができる。

データ／許可ハンドラ２４４は、後からさらに詳しく説明するように、異なる利用者によって設定される異なる利用者許可を扱うこともできる。

ウェブサイト構築システム３０（およびその中に構築されたウェブサイト）では、プライベートデータプロキシ２３４によって、すべてまたは一部のプライベートデータを、ウェブサイト構築システム３０によって管理される安全なリポジトリの中に保持することができ、プライベートデータプロキシ２３４は、サードパーティアプリケーションに（プライベートデータの代わりに）代替の一意のＩＤを提供することができ、サードパーティアプリケーションは、このＩＤを使用して、隠されているプライベートデータを取得することができる。例えば、電子メールアドレスを代替の「電子メールアドレスＩＤ」に置き換えてサードパーティアプリケーション４０に提供され、したがってサードパーティアプリケーション４０は、実際の電子メールアドレスにはアクセスすることができない。

さらに、プライベートデータプロキシ２３４は、さまざまな通信方法（例えば電子メール、ソーシャルネットワークのメッセージング）のための一連のインタフェースを提供することができ、サードパーティアプリケーション４０は、これらのインタフェースを使用して利用者に連絡する、あるいはメッセージを送ることができ、このときサードパーティアプリケーション４０はその利用者に関連付けられるプライベートデータに実際にアクセスすることはない。このようなプライベートデータとしては、それを用いて利用者に連絡することのできるあらゆる詳細な識別情報（例えば、名前、住所、電子メールアドレス、電話番号（ＳＭＳ／ＭＭＳを含む）、統一された通信ＩＤ（スカイプなど）、ソーシャルネットワークＩＤ）が挙げられる。

したがって、プライベートデータプロキシ２３４は、利用者許可フィールドの制限を実施する、利用者の配信停止要求を実施する、および、利用者へのメッセージの送信を抑制する（例えば特定のサイトにおいて動作する特定のサードパーティアプリケーション４０に対して１日あたり１００通までの電子メールを許可する）ことができる。プライベートデータプロキシ２３４は、プロキシパラメータと、サードパーティアプリケーションに公開するプライベートデータおよび公開しないプライベートデータを（サードパーティアプリケーション４０ごとに）定義することができ、これらの設定はフィールド単位で行うことができる。

プライベートデータプロキシ２３４は、ウェブサイト構築システム３０のサーバ上でホストされるサードパーティアプリケーション４０に、元のプライベートデータに形が似ている代替の一意のＩＤを提供する（例えば、利用者の元のプライベートな電子メールアドレスの代わりに代替のダミー電子メールアドレスを提供する）ことができ、その情報を使用するコールを「捕捉」し、（この例では）その電子メールを正しいアドレスに転送する。この機能は、許可された特権を超えているサードパーティアプリケーション４０を検出する目的にも使用することができる。

ウェブサイトのオーナーが、特定のサードパーティアプリケーション４０に提供される情報を制限する、または修正することを望むことがあることを理解されたい。その理由として、例えば、一般的なセキュリティ上の懸念、利用者のデータの任意の要素に関する特定のプライバシーコミットメント、特定の業界またはアプリケーションに固有な規制要件が挙げられる。プライバシーポリシーエンフォーサ２１３，２３３は、ウェブサイトのオーナーによって行われるこのような変更を実施し、現在の設定を上書きすることができる。

一例として、医療情報を扱うウェブサイトでは、利用者の一般的な地理的分布を解析するサードパーティアプリケーション４０にコンタクト情報を渡すときに、コンタクト情報のうち詳細な個人情報の一部にアクセスできないようにすることを望むことがある。別の例として、あるサードパーティアプリケーション４０において、特定の種類のコンタクト情報を扱うときに問題が発生することがある。そのサードパーティアプリケーション４０を（バグが判明しているが）そのまま使用したいと考えるウェブサイトオーナーは、分かっている問題を引き起こすコンタクトを除外する、あるいは問題が発生しないようにデータを修正することを望むことがある。

変換器／適合器２１２，２３２は、メッセージを変換およびコンテンツを適合化するための事前に指定される規則を適用することができる。このような規則それぞれには、規則が適用されるサードパーティアプリケーション４０、規則が適用されるメッセージを選択するフィルタリング基準、変換規則（例えば（特定のサードパーティアプリケーション４０に関連する）特定のメッセージを破棄する）、アクティビティデータ構造体の中の特定の１つまたは複数のフィールドに適用される変換などの条件を含めることができる。

このようにすることで、ハブ２１０，２３０は、サイトのオーナーによって作成される仕様に従って、異なるサードパーティアプリケーション４０にアクティビティデータ構造体の異なるバージョンを提供する（またはまったく提供しない）ことができる。

さらに、関連するウェブサイト構築システム３０は、障害、および侵入の試み（サードパーティアプリケーション４０のメッセージのペイロードデータを改ざんすることを目的とする中間者攻撃など）に対してシステムを強化するため、メッセージの検証および署名をサポートすることができる。したがって、ウェブサイト構築システム３０に登録されているサードパーティアプリケーション４０それぞれは、２組の秘密鍵／公開鍵を持つことができ、１組は、サードパーティアプリケーション４０からウェブサイト構築システム３０に送られたメッセージを復号する目的に使用され（入力鍵）、１組は、ウェブサイト構築システム３０からサードパーティアプリケーション４０に送られるメッセージを符号化する目的に使用される（出力鍵）。

例えば、サードパーティアプリケーションＡがウェブサイト構築システム３０にメッセージを送る。このメッセージは、サイトにおけるサードパーティアプリケーションＩＤ（サードパーティアプリケーションの外部ＩＤ（サードパーティアプリケーションスコープを有する））を使用して送られ、メッセージはサードパーティアプリケーションによって署名される。ウェブサイト構築システム３０はこのメッセージを受信する。検証器／署名器２３５は、サードパーティアプリケーションＡの入力鍵を使用して署名を検証する。この検証に合格しない場合、検証器／署名器２３５はその入力メッセージを無効と報告し、そのメッセージはそれ以上送信されない。

検証器／署名器２３５は、メッセージに関連付けられる外部ＩＤを内部サイトＩＤを使用して変換することができる。検証器／署名器２３５は、どのサードパーティアプリケーション４０がそのメッセージを受信するべきかを確認することができる。

例えば、検証器／署名器２３５は、サードパーティアプリケーションＢ１～Ｂｎそれぞれについて、サードパーティアプリケーションＢの外部ＩＤを認識することができる。次いで、検証器／署名器２３５は、サードパーティアプリケーションＢへのメッセージを作成し、上述した適用可能なフィルタリングおよび変換規則を適用するように変換器／適合器２１２，２３２に命令する。次いで、検証器／署名器２３５は、サードパーティアプリケーションＢの出力鍵を使用してメッセージに署名し、そのメッセージをルータ／追跡器２３１（またはルータ２１１）を介してサードパーティアプリケーションＢに送る。サードパーティアプリケーションＢは、そのメッセージを受信し、署名を検証する。検証に合格しない場合、そのメッセージは無効と報告され、それ以上処理されない。検証器／署名器２３５は、秘密の検証データが信頼できないクライアントに送られることがないように、クライアント側の処理を実行せずにサーバ側の処理のみを実行することを理解されたい。

上述したように、システム２００は、ウェブサイト構築システム３０とサードパーティアプリケーション４０との間の複数のタイプの通信を採用することができる。このような通信としては、例えば、制御上の通信（例：ウェブサイト構築システム３０がサードパーティアプリケーション４０にシャットダウンするように命令する）や、機能上の通信（例：ショッピングカートのサードパーティアプリケーション４０が合計購入金額をウェブサイト構築システム３０を通じて課金のサードパーティアプリケーション４０に送る（したがって本出願において説明した例においては支払いまたはアクティビティの通信が修正される）、が挙げられる。これらの異なるタイプの通信は、（例えば、送られるメッセージの量、優先度、堅牢性、応答時間に関する）異なるプロファイルおよび要件を有することを理解されたい。

特に、システム２００では、極めて頻繁なアクティビティ報告が行われることがある（例えば、サードパーティアプリケーション４０のグラフィカルユーザインタフェース（ＧＵＩ）のイベントが、サードパーティアプリケーション４０のアクティビティとして報告される場合）。このような膨大なアクティビティ報告によって、より重要なメッセージを扱うシステムの部分が圧迫されることがある。したがって、システム２００は、各クラスのメッセージが個別のチャネルを介して送られるように、（例えば、異なるポートや複数の同時セッションを使用して）複数の通信チャネルを実装することができる。このようにすることで、アクティビティ報告にはサイドチャネルが使用され、命令の通信および機能上の通信と並行して行われ、後者の通信を妨げない。

上述したように、システム２００は、コンタクトコーディネータ２４０およびアクティビティコーディネータ２５０を介してコンタクト情報を作成およびその質を高める目的と、特定のコンタクトに関連付けられるアクティビティイベントを照合する目的で、アクティビティ情報を集めることができる。コンタクトコーディネータ２４０およびアクティビティコーディネータ２５０は、ハブ２１０およびハブ２３０を通じてルーティングされる各アクティビティメッセージごとに、情報を処理することができる。ストリーム作成器２５１は、アクティビティメッセージから、コンタクトに固有なデータストリームを作成することができ、コンタクトコーディネータ２４０の複数の要素は、データを抽出して処理した後、それをコンタクトデータベース２４５に格納することができる。

したがって、各アクティビティストリームに対して、それぞれに関連付けられるコンタクトを構築することができ、構築されたコンタクトを、それぞれのデータストリームの下で実行されるアクティビティから抽出されるデータを使用して徐々に質を高めることができる。コンタクトコーディネータ２４０は、互いに関連するコンタクト（同じ人を記述するものと判明した複数のコンタクトレコード）の存在を認識することもできることを理解されたい。コンタクト識別器２７２は、プライマリＩＤフィールド（電子メールアドレス、電話番号、ソーシャルセキュリティ番号、フェイスブックＩＤなど）のマッチングによって、このようなレコードを認識することができる。いくつかのプライマリＩＤフィールドは複数値フィールドである（例えば１人の人が、その人を識別する複数の電子メールアドレスを持つことができる）のに対して、いくつかのプライマリＩＤフィールドは厳密に単一値のフィールド（例えばソーシャルセキュリティ番号）であることを理解されたい。

したがって、データマージャ２４３は、新しいアクティビティから抽出されたコンタクトのフィールドを、現在の構築されているコンタクトにマージすることができ、匿名利用者がウェブサイトを使用している間にその匿名利用者に対して構築されたコンタクトを、匿名利用者がログイン動作を実行して識別された利用者になった時点で、すでに定義されて保存されているコンタクトにマージすることができる（これを「垂直マージ」と称することがある）。さらに、水平コンタクトマージャ２７７は、２人の異なるコンタクト（構築されたコンタクトまたは格納されているコンタクト）が、同じ利用者を表す互いに関連するコンタクトであることを検出したときに、これら２人のコンタクトの「水平」マージを実行することができる。上述したように、このようなマージは、実際にマージする（すなわち２人の個別のコンタクトを１人のコンタクトに変換する）、または１人のコンタクトを別のコンタクトにマージする、または仮想マージを通じて実行する（すなわち２人のコンタクトを個別のコンタクトとして維持するが、これらが同じ利用者を表していることが示されるように互いにリンクし、このとき実際のコンタクト情報およびアクティビティストリームをマージする、またはマージしない）ことによることができる。さらに、仮想マージの場合でも、仮想的にマージされてリンクされた複数のコンタクトにさらなる追加情報を追加できることを理解されたい。

したがって、データ抽出器２４１は、関連するアクティビティデータ構造体からコンタクトタイプの情報を抽出することができ、データマージャ２４３は、このコンタクトタイプの情報を、アクティビティストリームに関連付けられる（匿名または識別された）コンタクトに統合することができる。コンタクトタイプの情報ＩにプライマリＩＤフィールドが含まれている場合、データマージャ２４３は、互いに関連するコンタクトがないかをプライマリＩＤフィールドの値に基づいてチェックし、見つかった場合、これらのコンタクトをマージする。さらに、データマージャ２４３は、アクティビティによって、サイト内の利用者の識別情報が確立されるかをチェックすることができ（例えばサイトログインアクティビティ）、確立される場合、匿名のコンタクトを、その利用者に対して格納されている既存のコンタクトレコードとマージし、そのコンタクトを以降は識別されたコンタクトにする。

コンタクト識別器２７２は、サイト利用者を識別するための複数の方法を実施できることを理解されたい。例えば、（サイトにログインしていない）１人の匿名利用者によるセッションをクッキーを使用して追跡する、登録されている利用者の場合にサイトログインを使用する、アカウントがソーシャルネットワークに関連付けられるサイト利用者の場合にソーシャルログインを使用する、プライマリＩＤフィールド（電子メールアドレスや電話番号など）のマッチングを行って２つの利用者プロファイルが同じ利用者を記述していることを識別することによる。

さらには、詳細情報がコンタクトデータベース２４５に格納されているサイト利用者は、サイトに登録していない匿名利用者、登録されている利用者、および潜在的利用者（サイトに正式にはまだ登録されていないが、外部ソースからインポートされたレコードを有する）に分類できることを理解されたい。

関連するウェブサイトは、セッションが変わっても持続される永続的クッキーをインストールすることができるため、同じブラウザを使用して同じコンピュータ上で実行される複数の匿名セッションから、同じコンタクトレコードへの情報を取得し続けることができる。したがって、匿名利用者であっても、相当な量のコンテキスト情報およびコンタクト情報を有することができる。

登録される利用者は、その特定のサイトにおいて一意であるＩＤを提供しなければならない。複数のタイプのＩＤを使用することができ、例えば、個々のサイトに固有なＩＤ（例：利用者名）、外部識別子（電子メールアドレス、電話番号、ソーシャルセキュリティ番号など）、あるいは別のシステムによって提供された外部識別子（ソーシャルネットワークＩＤ、Ｇｏｏｇｌｅ ＩＤ、ＯｐｅｎＩＤのＩＤなど）である。

ソーシャルネットワークへのログインを通じての利用者登録では、サイトは、ソーシャルネットワークにおいて利用可能な個人情報を使用して、同じ利用者のサイトプロファイルに入力することができる。さらに、データ抽出器２４１は、ソーシャルネットワークのプロファイルに再アクセスして、その個人情報の変更があれば検出して、サイト利用者のプロファイルを更新することができる。

登録された利用者は、一般的には、自身の識別情報を確立するためシステムにログインしなければならないが、システムは、「このシステムに接続したままにする」オプションを提供することができる。このようなログイン手順は、明示的とする（利用者がログインダイアログを呼び出す）、または暗黙的とする（例えばブログに書き込みを追加するときに、何らかの識別情報を提供するように利用者に要求する）、または外部ログインに基づく（システムは、別のシステムに関連付けられるログイン手順（ソーシャルネットワークへのログインやＯｐｅｎＩＤログインなど）を呼び出す）ことができる。さらに、物理的デバイス（例えばシステムに直接または無線インタフェースを介して接続されるセキュリティトークン）を通じて、またはバイオメトリック情報の使用（利用者のバイオメトリックパラメータ（例：指紋、虹彩スキャン）および利用者挙動検出（タイピングパターン検出など）の両方を含む）を通じて、または上に詳述した方法の任意の組合せを通じて、ログイン手順を修正することもできる。

さらに、ソーシャルログイン手順と通常のログインとの間で双方向に情報をやりとりできることを理解されたい。例えば、ソーシャルＩＤがサイトメンバーＩＤに関連付けられ、したがってソーシャルログインすることは暗黙的にサイトにログインすることであり、あるいは、サイトメンバーＩＤを１つまたは複数のソーシャルネットワークＩＤに関連付けることができ、したがってサイトにログインすると、１つまたは複数のソーシャルネットワークにおいて利用者が識別される。

利用者が明示的なログアウトを実行するとき、コンタクトハンドラ２４２は、新しい匿名利用者のクッキーを生成し、したがって新しい匿名セッション（または一連のセッション）を開くことができ、このセッションのアクティビティはその新しい匿名のコンタクトの下で保存される。さらなるログイン時に、この新しい匿名のコンタクトを、そのログイン時に識別されるコンタクトとマージすることができる。

次に図１９を参照し、この図は、匿名利用者のログイン／ログアウトプロセスを示している。利用者は、システムの利用を匿名で開始することができる。利用者がサードパーティアプリケーションでの最初のアクティビティａｃｔ１を実行すると、コンタクトハンドラ２４２がコンタクトを作成し、ストリーム作成器２５１がアクティビティストリームａｎｏｎ１を自動的に作成する。ストリームマージャ２５２は、ａｃｔ１からの情報および次のアクティビティａｃｔ２およびａｃｔ３からの情報を、利用者ａｎｏｎ１にマージする。

同じ利用者が利用者Ｘとしてログインを実行した時点で、データマージャ２４３は、ａｎｏｎ１のコンタクト（およびアクティビティストリームから取得される他の関連するコンタクトデータ）を、利用者Ｘのコンタクト情報にマージする。さらに、ストリームマージャ２５２は、さらなるアクティビティａｃｔ４およびａｃｔ５から抽出される情報を１つのストリームにマージし、次いでデータ抽出器２４１が利用者Ｘのコンタクト情報を抽出することを理解されたい。利用者Ｘがログアウトを実行すると、コンタクトハンドラ２４２は、新しいクッキーを作成し、それ以降のアクティビティを利用者Ｘから切り離す。したがって、新しいアクティビティａｃｔ６が実行されると、コンタクトハンドラ２４２は新しい匿名のコンタクトａｎｏｎ２を作成し、データ抽出器２４１は、そのコンタクトの抽出されたコンタクト詳細情報（およびアクティビティ）を、新たに作成された匿名のコンタクトａｎｏｎ２の下で保存する。

（シナリオＡのように）利用者ａｎｏｎ２が２回目のログインを利用者Ｙとして実行する場合、データマージャ２４３は、（ａｃｔ６およびａｃｔ７によって更新された）利用者ａｎｏｎ２のコンタクト情報を、さらなるアクティビティと一緒に、識別された利用者Ｙのコンタクト詳細情報にマージする。

（シナリオＢのように）利用者ａｎｏｎ２が２回目のログインを利用者Ｘとして実行する場合、データマージャ２４３は、（ａｃｔ６およびａｃｔ７によって更新された）利用者ａｎｏｎ２のコンタクト情報を、さらなるアクティビティと一緒に、（すでに更新されてａｃｔ１～ａｃｔ５が反映された）利用者Ｘのコンタクト詳細情報にマージする。

アクティビティに関連付けられるアクティビティデータ構造体は、コンタクト詳細情報を含むこともできることを理解されたい。データ抽出器２４１は、この情報を抽出してデータマージャ２４３に転送することができ、データマージャ２４３は、この情報を、コンタクトデータベース２４５の中の既存のコンタクト情報と統合し、既存のコンタクト情報の質を高めることができる。さらには、データ抽出器２４１は、特定のアクティビティメッセージ、ストリーム全体、別のコンタクト、または外部ソース（後からさらに詳しく説明する、ＩＰから地理情報への住所変換サービスなど）から、詳細情報を抽出できることを理解されたい。上述したように、コンタクトデータベース２４５の中のコンタクトは、登録またはサインアッププロセスの一部として利用者が明示的に提供するコンタクト詳細情報、またはウェブサイトに（ソーシャルログイン／登録機能を介して）サインアップするときに利用者が使用するソーシャルネットワーキングアカウントから抽出されるコンタクト詳細情報、または利用者が自身の利用者プロファイルを更新するときに提供するコンタクト詳細情報を含むこともできる。さらに、データ抽出器２４１は、外部ソースからコンタクト情報を取得することもできる（例えば利用者が米国郵便番号のみを指定するとき、サイトはこの情報を使用して、郵便番号復号（zip code decoding）の外部ウェブサービスから完全な住所情報を取得する）。

上述したように、コンタクト識別器２７２は、２人のコンタクトを、プライマリＩＤフィールド（利用者名、電子メールアドレス、電話番号など）に基づいて、互いに関連しているものと認識することができる。コンタクトＡ（新規）とコンタクトＢ（既存）が互いに関連していることが判明すると、データマージャ２４３がＡをＢにマージすることができる（Ｂがマスター）。この処理は、例えば以下のようなフィールドマージ規則を使用して行う。

Ｂ１＝ＢまたはＡ（例えば「Ｂ｜｜Ａ」）： Ｂをとり、Ｂがヌルまたは空である場合、Ａをとる。

Ｂ１＝数学関数（Ａ，Ｂ）： プライベートデータの重要なケースは以下である。

Ｂ１＝Ａ＋Ｂ： 例えば、訪問回数、合計購入額
Ｂ１＝ｍｉｎ（Ａ，Ｂ）： 例えば、サイトへの登録日
Ｂ１＝ｍａｘ（Ａ，Ｂ）： 例えば、最後のアクティビティの日付

Ｂ１＝ｌｉｓｔ－ｕｎｉｔｅ（Ｂ，Ａ）： リストＢの最後にリストＡを連結し、Ａの要素のうちＢの要素と重複する要素を削除する（すなわちＢ１＝Ｂ＆（Ａ－Ｂ））。データマージャ２４３は、リストの要素間の重複を、以下の規則に従って判定することができる。

通常の値（すなわちスカラー）からなるリストの場合、通常の値の比較を使用する。

構造体からなるリストの場合、構造体の特定のサブフィールドを比較キーとして使用する。例えば、複数の住所をサポートするウェブサイト構築システム３０における住所のタイプ（自宅、会社、配送先など）。

正規化数の比較。（例えば）後述する電話番号の処理を参照。

構造体Ａが構造体Ｂのさらに詳細なバージョンである場合、ＡをＢに結合する（後からさらに詳しく説明する）。

より高い確実性スコア（certainty score）： 値に確実性スコアを付加することができる（例えば、利用者によって直接提供された情報と、利用者に関して推測された情報とに、異なる確実性スコアを付加する）。データマージャ２４３は、より高い確実性スコアを有する値を選択することができる。

いくつかのフィールドタイプは、正規化されたフォーマットを有することを理解されたい。例えば、電話番号を、正規化された米国形式（例：（９９９）５５５－１２３４）または国際形式（例：＋１－９９９－５５５－１２３４）に正規化することができる。データマージャ２４３は、例えばコンタクトのプライマリキー（電話番号など）を比較するときや、マージされたリストにおける重複をチェックするときに、比較できるようにフィールド値を正規化されたフォーマットに変換することができる。

データマージャ２４３は、同じ基本構造を有する２つの構造化された値（例えば、複数のサブフィールド（国、州、郵便番号、ストリート、番地など）からなる住所値）を比較することができる。構造体Ｘの中の空ではないフィールドそれぞれの値が、構造体Ｙの中の同じフィールドの値と等しい（すなわち、Ｙは、Ｘの空ではないフィールドの値すべてと、場合によってはいくつかのさらなるフィールドの値とを含む）場合、構造体Ｙは、構造体Ｘの詳細バージョンである。したがってデータマージャ２４３は、ＡがＢの詳細バージョンであり、かつＡがＢと同一ではない場合、ＡをＢに結合することができる。

データ抽出器２４１は、アクティビティの発生元であるＩＰアドレスから、コンタクトの住所を推測できることを理解されたい。この機能は、アクティビティの発生元がブラウザセッションであり、かつ利用者の住所が取得されていない場合にのみ使用される。したがって、データ抽出器２４１は、ＩＰアドレスの地理情報に従って州／国情報を抽出することができる。この場合、住所は、「推定された地理ＩＰアドレス」とマークされる。このようなマーキングが必要であるのは、ＩＰマッピングに基づく（場合によっては不正確な）住所が住所フィールドにすでに含まれているが故に、後からの住所のマージ処理と衝突し、これにより後からの詳細な（ただし基本的に異なる）住所をコンタクトデータベース２４５に保存することが妨げられないようにするためである。

データマージャ２４３は、マージされたリストにおけるタグの衝突を処理することもできる。リストをマージする場合、２つのエンティティ（１つはコンタクトＡから、他方はコンタクトＢから）が存在し、これらのエンティティは異なるが同じタグを有するという状況が起こりうることを理解されたい。このシナリオにおいては、データマージャ２４３は、同じタグを有する両方のエンティティをリストに含める。

したがって、［｛タグ：”自宅”，電子メール：”ａ＠ｂ．ｃｏｍ”｝］＋［｛タグ：”自宅”，電子メール：”ｃ＠ｄ．ｃｏｍ”｝］という結合を行うと、［｛タグ：”自宅”，電子メール：”ａ＠ｂ．ｃｏｍ”｝，｛タグ：”自宅”，電子メール：”ｃ＠ｄ．ｃｏｍ”｝］が作成される。この方法は、マージされるフィールドが、「一意でないリストタグを許可」としてマークされている場合に使用する。

さらに、データマージャ２４３は、コンタクト情報の結合を試みるとき、言語解析法、構文解析法、または他のテキスト解析法と、外部データソースまたは外部サービスの参照・利用を用いることができる。例えば利用者が、２つのアクティビティレコードに、自宅の住所のうちストリート名を２つの異なる様式で入力し、番地、市、および郵便番号は同じものを入力することがある。結合器２７３は、２つのエントリを比較するときにテキスト解析（例えばｓｏｕｎｄｅｘアルゴリズム）を適用することができ、さらに、ストリート名の２つのバージョンを、与えられた市および郵便番号に対する、外部ソースによるストリート名と比較することができる。このような場合、結合器２７３は、両方の住所が標準的なストリート名に似ており（ただし場合によっては同じではない）、かつ他のすべての住所データフィールドが正しい値を有する場合、その標準的なストリート名を選択することができる。

さらに、データマージャ２４３は、ログイン／セッション情報に従ってコンタクト情報をマージすることができる。利用者は、ログインまたは登録を実行せずにサイトを利用してセッションを開始し、そのセッションの一部としていくつかのアクティビティを実行し、後から登録またはログインすることがあり、したがってそのセッションは、新たに作成される利用者プロファイルまたは登録された利用者の既存のプロファイル（コンタクト情報を含む）に関連付けられる。

利用者が（匿名として）セッションを開始すると、コンタクト識別器２７２が、そのセッションの間、（クッキー、セッションＩＤなどを使用して）利用者を追跡することができ、コンタクトハンドラ２４２が、匿名セッション中に利用者によって実行されたアクティビティに基づいて、その特定の匿名利用者に対して、構築されたコンタクトを作成することができる。さらに、ルータ／追跡器２３１が、同じコンピュータからの複数のセッションにわたり、その匿名利用者の追跡を続けることができる。この追跡は、（セッションクッキーではなく）永続的クッキーを使用することによって行うことができる。

利用者が登録すると、データマージャ２４３は、構築されたコンタクトの情報を使用して、利用者プロファイルに最初の入力を行うことができる。利用者がログインする場合、データマージャ２４３は、構築されたコンタクトの情報を、既存の利用者プロファイルに最初に結合することができる。構築されたコンタクトの情報は、利用者のサイトＩＤに従ってマージされ、なぜならデータマージャ２４３は、サイトＩＤ以外には、マージするために使用するプライマリＩＤ（電子メールアドレスなど）を、構築されたコンタクトの情報の中に保持していないためであることを理解されたい。さらに、このようなマージでは、集められた情報において矛盾が生じうることを理解されたい。匿名の構築されたコンタクトを既存のプロファイルデータにマージするときには、回避できない矛盾が発生することがある。例えば、ある匿名利用者が、（何らかのサードパーティアプリケーション４０によって表示される）データフォームに、Ｊｏｈｎ Ｓｍｉｔｈという名前で入力し、その後、（同じかまたは別のブラウザセッションを使用して）Ｊａｎｅ Ｄｏｅという名前でアカウントにログインするとする。この場合、（例えば）後からのログインは、同じコンピュータを使用する実際に別の人によって行われたログインであるか、または、最初の利用者が自分のプライバシーを守るためコンタクトフォームにおいて偽名を使用した可能性がある。データマージャ２４３が、複数の匿名の構築されたコンタクトをマージするときにも、同じことがあてはまる。

矛盾解消器２７４は、一般には矛盾を自動的に処理することができ、なぜならほとんどのフィールド（電子メールアドレスや電話番号などのプライマリＩＤフィールドを含む）は、複数の値を含むことのできるリストフィールドであるためである。このことは、同じ下層サイト（underlying site）が複数回利用される場合にのみ適用することができる。（例えば複数の値をリスト値にマージすることによって）解消することのできない矛盾については、サイトのオーナーまたはエンドユーザによって手動で対処する（どの値を使用するかを決定することができる）、または別の手法を使用して対処することができるように、フラグを付しておくことができる。

したがって、構築されたコンタクト情報が、１人の人を反映するのではなく、同じコンピュータを介して同じサイトにアクセスする一連の利用者を反映することがありうる。

上述したように、データマージャ２４３は、複数のコンタクトが作成または修正されるとき、一般にプライマリＩＤフィールド（電子メールアドレスや電話番号など）に従ってコンタクトをマージする。

入力される情報は、１つまたは複数の値を有する１つまたは複数のプライマリＩＤフィールドを有するコンタクトレコード（入力されたコンタクトＣ）である（例えば、２つの電子メールアドレスおよび３つの電話番号を有するコンタクトレコード）。利用者は、（例えば）自宅／会社／携帯電話の各番号と、自宅／仕事用の電子メールアドレスを持つことがあり、利用者はこれらのいずれかをコンタクトフォームの中で入れ替えて使用することがあるため、複数のプライマリＩＤフィールドが要求されうる。

データマージャ２４３は、プライマリＩＤ値を正規化し、正規化されたプライマリＩＤ値のいずれかを含むコンタクトレコードを検索するクエリ（例えば、「（電話＝Ｐ１ ＯＲ 電話＝Ｐ２）」あるいは「（電子メール＝Ｅ１ ＯＲ 電子メール＝Ｅ２）」）を作成することができる。さらに、データマージャ２４３は、クエリの対象を、特定のサイトのコンタクトデータベース２４５に制限することができる。さらに、データマージャ２４３は、コンタクトデータベース２４５に対してクエリを実行し、一致したコンタクトのリストＬ（入力されたコンタクトＣを含む）を取得することができる。

入力されたコンタクトが（特定のサイトの）登録されたサイトメンバーである場合、データマージャ２４３は、リストＬからコンタクトＣを削除し、リストＬの中の残りのコンタクトすべてをコンタクトＣにマージすることができる。次いで、データマージャ２４３は、更新されたコンタクトＣをコンタクトデータベース２４５に再び保存し、リストＬの中の残りのコンタクトすべてをコンタクトデータベース２４５から削除することができる。これに代えて、データマージャ２４３は、上述したように仮想マージを実行することができ、すなわち、すべてのコンタクト情報を結合し（すなわち、利用可能なすべての情報が含まれるようにすべてのコンタクトレコードを更新する）、（「重複する」コンタクトレコードを削除する代わりに）一致したコンタクトレコードを、同じ人に属するものとマークする。このような処理が必要となるのは、例えば、サードパーティアプリケーション４０によって、コンタクトレコードに固有な内部ＩＤが格納または使用されており、したがってコンタクトレコードを削除するとこれらのサードパーティアプリケーション４０が正しく動作しない場合である。同じ処理（すなわちコンタクトを削除するのではなくコンタクトを互いに関連するものとマークする）は、後からさらに詳しく説明する別の場合にも適用することができる。

入力されたコンタクトが、登録されたサイトメンバー「ではない」場合、データマージャ２４３は、リストＬに含まれるサイトメンバーコンタクトの数をチェックすることができる。サイトメンバーが０である場合、データマージャ２４３はリストＬからコンタクトＣを削除し、リストＬの中の残りのコンタクトすべてをコンタクトＣにマージすることができる。次いでデータマージャ２４３は、更新されたコンタクトＣをコンタクトデータベース２４５に再び保存し、リストＬの中の残りのコンタクトすべてをコンタクトデータベース２４５から削除することができる。

１人のサイトメンバー（コンタクトＤ）が存在する場合、データマージャ２４３は、リストＬからコンタクトＤを削除し、リストＬの中の残りのコンタクトすべて（コンタクトＣを含む）をコンタクトＤにマージすることができる。次いでデータマージャ２４３は、更新されたコンタクトＤをコンタクトデータベース２４５に再び保存し、リストＬの中の残りのコンタクトすべてをコンタクトデータベース２４５から削除することができる。

２人以上のサイトメンバーコンタクト（Ｄ，Ｄ１，Ｄ２，．．．）が存在する場合、データマージャ２４３は、見つかったサイトメンバーコンタクト（Ｄ，Ｄ１，Ｄ２，．．．）からコンタクトＤを選択し、リストＬからコンタクトＤを削除することができる。次いでデータマージャ２４３は、リストＬの中のコンタクトのうちサイトメンバーではないコンタクトを含むサブリストＬＬを、リストＬから作成することができる。次いでデータマージャ２４３は、リストＬＬの中の残りのコンタクトすべてをコンタクトＤにマージすることができる。次いでデータマージャ２４３は、更新されたコンタクトＤをコンタクトデータベース２４５に再び保存し、リストＬＬの中の残りのコンタクトすべてをコンタクトデータベース２４５から削除することができる。

ログイン時のマージに関して上述したように、データに矛盾が発生することがある。しかしながら、リスト値作成器２７５が、（複数の値を有する）リスト値フィールドを作成することができ、さらにコンタクト間の明確な優先順位を定義することができるため、ほとんどの場合にこの問題は発生しない。

例えば、データマージャ２４３が以下のコンタクトをマージする。

コンタクト１＝［電話１，電子メール１］；
コンタクト２＝［電話１，電子メール２］；
コンタクト３＝［電話２，電子メール２］；

データマージャ２４３は、次のように結合されたコンタクトを生成することができる。

結合されたコンタクト＝［電話＝［電話１，電話２］，電子メール＝［電子メール１，電子メール２］］．

コンタクトデータベース２４５には、複数のソースからの、使用に関する異なるレベルの許可を有するコンタクト情報が含まれることがあることを理解されたい。以下の説明では電子メールを例にとるが、以下の説明および手法は、利用者に連絡するために使用される前述した任意のタイプの情報（電話番号、ＦＡＸ番号、スカイプＩＤ、インスタントメッセージングＩＤ、ソーシャルネットワークＩＤなど）にもあてはまる。

例えば、サイトに電子メールアドレスが提供された経路によって、その電子メールアドレスの使用に関する許可が異なることがある。電子メールアドレスのいくつかの可能な取得経路は、登録ＩＤ、コンタクトフォーム、ニュースレターのサインアップ、配信停止要求である。さらに、電子メールアドレスは、利用者によって電子署名される「許可される用途の同意」の点で異なることがある。

一般に、ウェブサイト構築システム３０は、与えられた電子メールの許可される用途に関する情報を有することを理解されたい。しかしながら、ウェブサイトのオーナーが、それとは異なる情報、個別の情報、または追加の情報を有することができる。例えば、サイト内の異なるサインアップフォームの性質に起因する、または追加の使用許可情報を含む異なるソースからのコンタクトが、ウェブサイトによってシステム内にインポートされる場合である。

データ／許可ハンドラ２４４は、この情報の管理に関してウェブサイトのオーナーを支援する目的で、サイト内で使用されるサードパーティアプリケーション４０に対して、正しい使用ポリシーを実施することができる。

したがって、関連するコンタクトのコンタクトレコードに、２つの情報フィールドを含めることができる。最初のフィールドは、利用者のアクティビティからウェブサイトによって計算されて導かれる許可または提案される許可を含むウェブサイト許可フィールドである。コンタクトフォームは、機能上の電子メールを暗黙的に指定するのみであるのに対して、サブスクリプションフォームは、反復性の電子メールを暗黙的に指定する。２番目のフィールドは、ウェブサイト許可フィールドの値に基づくサイトオーナー許可フィールドである。サイトのオーナーは、ウェブサイトの推奨許可を変更することができ、自身が望むように設定することができるが、ウェブサイト許可フィールドによって定義されている許可の範囲を超える使用に関して責任を負う。

ウェブサイト許可フィールドの値は、利用者の意図に関するウェブサイトの最良の認識を表すことを理解されたい。サイトオーナー許可フィールドの値は、ウェブサイトによって割り当てられてサードパーティアプリケーション４０およびシステムの他の部分によって（例えばニュースレター配信を提供するサードパーティアプリケーション４０によって）使用される値である。

データ／許可ハンドラ２４４は、これらの許可フィールドを使用して、複数の方法で許可を定義することができる。例えば、データ／許可ハンドラ２４４は、（電子メールアドレスおよびその他のコンタクトＩＤに対して）以下のコードのいずれかまたはその組合せ、およびこれらのバリエーションを実装することができる。

不明： 電子メールアドレスは不明なソースから抽出され、電子メールを送る目的に使用することはできない。

電子メールＩＤ： 登録する目的に提供された電子メールアドレス。登録に関連する内容（登録の確認、パスワードを忘れた場合、セキュリティ違反が疑われることの通知など）を除いて、電子メールを送る目的に使用することはできない。

機能上の電子メール： 特定の機能のために提供され、ワンタイム電子メールを許可する。例えば、購入確認の電子メールや、特定のコンタクトフォームに対して提供される電子メール。

反復性の電子メール： 特定のウェブサイトが複数回の定期的なサブスクリプションおよび広告を送ることを許可する。この場合には明示的なサブスクリプション／承認が要求される。

共有可能な電子メール： ウェブサイトおよびそのパートナー（サードパーティアプリケーション４０、他の第三者（４^ｔｈ ｐａｒｔｉｅｓ））が複数回の定期的なサブスクリプションおよび広告を送ることを許可する。この場合には明示的なサブスクリプション／承認が要求され、許可される共有に関する詳細な情報を含めることができる。

オプトアウト： 利用者が明示的に配信停止を行った。その利用者には電子メールを送ることができない（場合によってはオプトアウトの通知を除く）。

データ／許可ハンドラ２４４は、代替方法、例えば許可ビットマスク（ＵＮＩＸ（登録商標）システムおよびＬｉｎｕｘ（登録商標）システムで使用されるものに似ている）やＡＣＬ（アクセス制御リスト）メカニズムを使用できることを理解されたい。さらに、データ／許可ハンドラ２４４は、コンタクト情報の個別の部分（例えば、電子メールアドレス、インスタントメッセンジャーのアドレス、ソーシャルネットワークＩＤなど）を対象とする個別の許可フィールドを実装することができる。

代表的な使用のシナリオとして、コンタクトデータベース２４５には、コンタクトフォームから集められた第１のセットの電子メールアドレスと、サブスクリプション要求からの第２のセットの電子メールアドレスとが含まれる。ウェブサイトは、ニュースレター配信のサードパーティアプリケーション４０を呼び出すことができ、このとき、第２の利用者セットに属する利用者（サブスクリプション要求を送った利用者）「のみ」にサードパーティアプリケーション４０が電子メールを送ることを認識している。

このようなシステムの利点として、利用者に誤ってスパムメールが送信されることや個人情報が不正に使用されることに関して、ウェブサイトおよびウェブサイトオーナーの両方に対して（技術的および法律的な両面において）良好な保護が得られることと、上述したようにプライベートデータプロキシ２３４と組み合わせてシステムが使用されるときにプライバシーポリシーを実際に実施する機能が挙げられる。さらに、配信停止要求がさらに厳密に実施されるようにすることができる。

したがって、利用者に対して、関連するウェブサイト構築システム３０と任意の関連するサードパーティアプリケーション４０との間のアクティビティのストリームを生成することができる。これらのストリームは、アクティビティストリームと称することがある。各アクティビティストリームは、１人のコンタクトに関する情報源として使用することができる。さらに、異なるアクティビティストリームの発生源が同じであると判定される場合、個々のストリームのアクティビティデータ構造体をマージしてコンタクトを形成することができる。例えば、１人の利用者が、２つのデバイス（モバイルデバイスとパソコンなど）を通じて匿名としてアクティビティを行うことがある。このような利用者によって、２つの匿名ストリームが生成され、これらの匿名ストリームの下でメッセージが格納される。これらのストリームが同じ利用者に関連付けられるものと認識された時点で、これらのストリームをマージすることができる。

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

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

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

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

［関連出願］
本出願は、米国仮特許出願第６１／９１１，４８５号（出願日：２０１３年１２月４日）の優先権を主張し、この仮特許出願はその全体が参照によって本出願に組み込まれている。

Claims (10)

1. ウェブサイトのためのシステムであって、
   プロセッサと、
   前記プロセッサ上で動作し、前記ウェブサイトの利用者と、前記ウェブサイトのページにインスタンスとして埋め込まれた少なくとも１つのサードパーティアプリケーションとの間のインタラクションを捕捉し、前記利用者のコンタクトレコードを更新するために前記インタラクションを使用するユニットと、を備え、
   前記ユニットは、
   前記インタラクションからコンタクト関連情報を抽出するデータ抽出器と、
   少なくとも２つのコンタクトレコードをマージするデータマージャであって、前記少なくとも２つのコンタクトレコードが、同じ識別された利用者との関連性を有し、事前に定義されたマージ規則に従って、前記抽出されたコンタクト関連情報を前記識別された利用者の既存のコンタクトレコードのコンタクト関連情報にマージする、データマージャと、
   前記コンタクト関連情報のプライバシー保護および許可を処理するデータ／許可ハンドラと、
   を備える、システム。
2. サイトの利用者の識別情報を処理し、前記ウェブサイトのセッションの間に識別可能な新規利用者のプロファイルおよび匿名利用者のプロファイルの少なくとも１つを作成するためのコンタクトハンドラをさらに備える、請求項１に記載のシステム。
3. 前記データマージャは、
   前記少なくとも２つのコンタクトレコード内の同一のプライマリＩＤフィールド値、前記少なくとも２つのコンタクトレコード内の正規化したときに同一となるプライマリＩＤフィールド値、クッキーを使用するサイト利用者、登録利用者のためのサイトログインを使用するサイト利用者、ソーシャルネットワークに関連するアカウントを持つサイト利用者のためのソーシャルログインを介したサイト利用者、の少なくとも１つを識別するコンタクト識別器と、
   言語解析と構文およびテキスト解析と外部データソースまたは外部サービスの参照・利用とのうちの少なくとも１つを使用して、コンタクト関連情報を結合する結合器と、
   事前に定義された規則に従って、前記少なくとも２つのコンタクトレコードの間の矛盾を解消するための矛盾解消器と、
   前記少なくとも２つのコンタクトレコードの間にリスト値フィールドを作成し、前記矛盾を防ぐリスト値作成器と、
   検出された共通のプライマリＩＤにより互いに関連しない２つのコンタクトレコードをマージする水平コンタクトマージャと、
   匿名利用者のコンタクト関連情報と登録利用者のコンタクト関連情報とを、前記匿名利用者のコンタクト関連情報と前記登録利用者のコンタクト関連情報とを結びつけるログインまたは登録に応じてマージする垂直コンタクトマージャと、
   の少なくとも１つを備える、請求項１に記載のシステム。
4. 前記水平コンタクトマージャは、少なくとも２つのコンタクトレコードを個別のレコードとして維持し、同じ識別された利用者を表していることが示されるように前記少なくとも２つのコンタクトレコードを互いにリンクするための仮想水平マージャを備える、請求項３に記載のシステム。
5. 前記垂直コンタクトマージャは、ともに登録利用者に関連する匿名利用者と識別された利用者とを個別の利用者として維持し、それらが同じ利用者を表していることが示されるようにリンクする仮想垂直マージャを備える、請求項３に記載のシステム。
6. ウェブサイトの利用者と、前記ウェブサイトのページにインスタンスとして埋め込まれた少なくとも１つのサードパーティアプリケーションとの間のインタラクションを捕捉するステップと、
   前記利用者のコンタクトレコードを更新するために前記インタラクションを使用するステップと、を備え、
   前記捕捉するステップと前記使用するステップとは、
   前記インタラクションからコンタクト関連情報を抽出するステップと、
   少なくとも２つのコンタクトレコードをマージするステップであって、前記少なくとも２つのコンタクトレコードが同じ識別された利用者との関連性を有する、抽出するステップと、
   事前に定義されたマージ規則に従って、前記抽出されたコンタクト関連情報を前記識別された利用者の既存のコンタクトレコードにマージするステップと、
   前記コンタクト関連情報のプライバシー保護および許可を処理するステップと、を備える、ウェブサイトのための方法。
7. サイト利用者の識別情報を処理し、前記ウェブサイトのセッションの間に識別可能な新規利用者および匿名利用者の少なくとも１つを作成するステップをさらに備える、請求項６に記載の方法。
8. 前記少なくとも２つのコンタクトレコードをマージするステップは、以下の、
   前記少なくとも２つのコンタクトレコード内の同一のプライマリＩＤフィールド値、前記少なくとも２つのコンタクトレコード内の正規化したときに同一のプライマリＩＤフィールド値、クッキーを使用するサイト利用者、登録利用者のためのサイトログインを使用するサイト利用者、ソーシャルネットワークに関連するアカウントを持つサイト利用者のためのソーシャルログインを介したサイト利用者、の少なくとも１つを識別するステップと、
   言語解析と構文およびテキスト解析と外部データソースまたは外部サービスの参照・利用との少なくとも１つを使用して、コンタクト関連情報を結合するステップと、
   事前に定められた規則に従って、前記少なくとも２つのコンタクトレコードの間の矛盾を解消するステップと、
   前記少なくとも２つのコンタクトレコードの間にリスト値フィールドを作成し、前記矛盾を防ぐステップと、
   検出された共通のプライマリＩＤにより互いに関連しない２つのコンタクトレコードをマージするステップと、
   匿名利用者のコンタクト関連情報と登録利用者のコンタクト関連情報とを、前記匿名利用者のコンタクト関連情報と前記登録利用者のコンタクト関連情報とを結びつけるログインまたは登録に応じてマージするステップと、
   のうちの少なくとも１つを含む、請求項６に記載の方法。
9. 検出された共通のプライマリＩＤにより互いに関連しない２つのコンタクトレコードを前記マージするステップは、少なくとも２つのコンタクトレコードを個別のレコードとして維持し、同じ識別された利用者を表していることが示されるように前記少なくとも２つのコンタクトレコードを互いにリンクするステップを備える、請求項７に記載の方法。
10. 匿名利用者のコンタクト関連情報を前記マージするステップは、ともに登録利用者に関連する匿名利用者と識別された利用者とを個別の利用者として維持し、それらが同じ利用者を表していることが示されるようにリンクするステップを備える、請求項７に記載の方法。