JP2023036878A - ウェブサイトコンポーネント相互間におけるスマートインタラクションのためのシステム及び方法 - Google Patents

Abstract

【課題】ウェブサイトを構築するための拡張ウェブサイトコンポーネントを提供する。【解決手段】拡張ウェブサイトコンポーネントは、拡張ウェブサイトコンポーネントのスタイル、ロジック及びボディを表す要素と、拡張ウェブサイトコンポーネントがウェブサイト構築システム（ＷＢＳ）エディタによって処理される方法を制御するエディタ挙動ドライバと、拡張ウェブサイトコンポーネントがランタイム時にランタイムサーバによって処理される方法に影響を与えるランタイム挙動ドライバと、ＷＢＳエディタによる編集プレビュー中及びランタイム時に拡張ウェブサイトコンポーネントに対するレンダリング命令を提供するコンポーネントレンダリング機能と、所定のルール及びプロトコルレゾルーションに従って拡張ウェブサイトコンポーネントと第２の拡張ウェブサイトコンポーネントとの間のオーバライドリクエストを処理するオーバライドデータハンドラと、を有する。【選択図】図３

Description

本発明は、概してウェブサイト構築システム、特にスマートコンテナ及びコンポーネントに関する。

（関連出願のクロスリファレンス）
この出願は、参照により本明細書に組み込まれている、出願日が２０１７年６月８日の米国仮特許出願第６２／５１６６８２号及び出願日が２０１８年５月２日の米国仮特許出願第６２／６６５６２９号から得られる優先権及び利益を主張する。

ウェブサイト構築システムは、非常に普及しており、初心者用ウェブサイトビルダがプロによって作成されたような見栄えと機能を有するウェブサイトを構築することを可能にしている。これらのシステムの多くは、ゼロからウェブサイトを構築する初心者のユーザ向けの方法と経験豊富なユーザ向けの方法の両方を提供している。

ウェブサイトは、一般的に、複数のページから構成される視覚的に設計されたアプリケーションで構成されている。これらのページは、個別に表示され、コンポーネントを収容していることがある。ウェブサイト構築システムは、アトミックコンポーネント（テキスト、イメージ、形状、ビデオなど）と、他のコンポーネント（例えば、通常コンテナ、単一ページコンテナ、複数ページコンテナ、ギャラリコンテナなど）を収容する様々なタイプのコンテナコンポーネントと、を使用するコンポーネントの階層的な構成をサポートすることがある。コンテナコンポーネント内に収容されているサブページは、ミニページと呼ばれ、各々、複数のコンポーネントを収容していることがある。コンテナコンポーネントには、ミニページを一度に１枚だけ表示するものもあれば、複数のミニページを同時に表示するものもある場合がある。次に、図１を参照すると、これには、ウェブページ３を有するウェブサイト２から構成されるウェブサイト構築システム１の一般的な表現が示されており、ウェブページ３は、アトミックコンポーネント５とコンテナコンポーネント６とから構成されるコンポーネント４から構成され得る。更に、コンテナコンポーネント６は、様々な単一ページコンテナ７と複数ページコンテナ８とから構成されていることがあり、更に、複数ページコンテナ８にはミニページ９が収容されている。他のコンポーネントタイプには、セマンティックコンポジット１１、データ／テキストリピータ１２及びイメージリピータ１３が含まれていてもよい。

リピータコンテナ（例えば、データ／テキストリピータ１２及びイメージリピータ１３など）は、実際のページ編集プロセス及びコンポーネントの視覚的属性に関係しない情報及びデータソースを統合し得る。これらのデータソースは、内部データリスト又は外部ソースからのデータ、例えば、ウェブサイトと、そのページと、ウェブサイトの所有者（使用可能な場合）とに関するビジネス又はその他の情報などであり得る。このデータは、コンポーネント／レイアウト情報と組み合わされて、リピータコンテナ内の繰り返しコンポーネントの複数のインスタンスを形成し、これらは、基になるデータソースが変更されると自動的に更新される可能性がある。このような動的コンテンツリピータは、オーバーライド及びその他の操作もサポートし得る。

コンポーネントは、コンテンツレスであっても、あるいは、内部コンテンツを有していてもよい。第１のカテゴリの例は、星形コンポーネントであり、これは、（色、サイズ、位置及びその他のいくつかのパラメータを有しているが）内部コンテンツを有していない。第２のカテゴリの例は、テキスト段落コンポーネントであり、その内部コンテンツには、内部テキスト、及び、フォント、書式設定、レイアウトの情報が含まれている。もちろん、このコンテンツは、テキスト段落コンポーネントのインスタンスごとに異なる場合がある。コンテンツを有するコンポーネントは、多くの場合、フィールド（例えば、「テキストフィールド」など）と呼ばれる。

既存のウェブページは、一般的に、コンテンツ及びフォーマットを提供する宣言型ＨＴＭＬコードと、追加のスタイリングを提供するＣａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔｓ（ＣＳＳ）と、ページについての手続き基盤を提供する手続き型ＪａｖａＳｃｒｉｐｔ（ＪＳ）との組み合わせから構成される。

ウェブページのコンテンツは、単一のファイル又はファイルの組み合わせ（例えば、ＨＴＭＬ、ＣＳＳ及びＪＳファイル）内に存在してもよい。代表的な構成は、追加のＨＴＭＬ、ＣＳＳ及びＪＳファイルを含むメインＨＴＭＬファイルであり、それらの含まれるファイルの一部が複数のページに共通している（例えば、共通の一組のスタイル又はＪＳライブラリが複数のページ内で使用される）。

そのような含まれるファイルは、複数のソースに由来する場合がある。一部のファイルは一人のウェブページ作成者が作成する場合もあれば、複数の作成者が作成した様々な事前定義されたＨＴＭＬ、ＣＳＳ又はＪＳライブラリ又はプラグインモジュールから作成される場合もある。

ウェブサイトのページは静的に定義されていてもよく、即ち、それらのページの最終的な形態のファイルが、ウェブサーバに格納されており、ユーザによってブラウザ（又は他のユーザエージェントソフトウェア）を介してアクセスされる。このようなウェブページは、手動で作成してもよく、あるいは、ユーザ定義に基づいて（静的な）ウェブページを作成するシステム（例えば、ウェブページ編集又は生成ソフトウェアなど）を使用して作成してもよい。

また、ウェブサイトページは、ユーザによって要求された時に、動的に生成されてもよい、即ち、動的に（又は半動的に）構成されてもよい。このような動的な生成は、完全なページ生成を介して実施されてもよい。ページ全体は定義済みのサブ要素から作成されるが、その際、これらの要素をどのように組み合わせるべきかが個別に定義される。既存のページテンプレートを使用でき、その際、一部のプレースホルダを他のソースから得られるデータで満たすようにする。

オンラインウェブサイト構築システムを使用して、そのような動的ページを作成及び実施してもよい。ページ定義は、ウェブサイト構築システムを使用してデザイナが作成してもよく、その際、ページ作成環境を通じて組み立てられた様々な提供要素（例えば、コンポーネント、コンテナ、サードパーティアプリケーション及びページセグメントなど）を使用してページ定義を作成する。

ウェブサイト構築システムは、一般的に、ページ定義をリポジトリ内に保存している。これらのページ定義は、ランタイム期間中にウェブサイト構築システムによって読み取られ、サイトビューアに転送されるウェブページ情報に変換される。次に、これらは現在のビュー用にレンダリングされ、コンポーネントのインスタンスが作成される。

ウェブサイト構築システムには、例えば、生成されたページに埋め込まれており、アプリケーション内に含まれるクライアント側又はサーバ側のコードで実行されるＪＳアプリケーションセグメントのようなクライアント側コンポーネントが含まれている場合がある。

ページ定義のウェブサイト構築システムの内部表現を（ブラウザによって実行可能な）ＨＴＭＬ／ＣＳＳ／ＪＳコードに変換する処理は、サーバ上で実行されるウェブサイト構築システムの要素とクライアントとの間で、いくつかの態様で、分割してもよい。一実施形態では、変換作業全体がウェブサイト構築システムサーバ上で実施され、これによって、完全な実行可能ページがビューアのクライアントマシンに提供される。ここで「実行可能」とは、ブラウザクライアントによって直接処理され得る及びレンダリングされ得るページを意味している。

別の一実施形態において、ウェブサイト構築システムの内部フォーマットの定義は、クライアントに提供される（場合によっては、追加情報で拡張される）ものであり、クライアント常駐ブラウザアプリケーションが、変換及び動的ページ構築を実施してブラウザ表示ページを作成する。

更に別の一実施形態において、変換作業は、サーバとクライアントとの間で分割され、それらの各々が変換の一部分を実施する。

このようなクライアント側のアプリケーションは、（サーバを使用して、例えば、単に、基礎となるデータベースにインタフェース接続して）クライアント側での操作（イメージの移動／並べ替えなど）を可能にするイメージギャラリの処理などの更なる役割を果たしてもよい。

その処理及びレンダリングは、サーバとクライアントとの間のセッションの状況において実施されてもよい。そのようなセッションは、例えば、アプリケーションビューイングセッション（application viewing session）をサポートするために、サーバによって維持されてもよい。

ウェブサイト構築システムは、（参照により本明細書に組み込まれており、本発明の共通譲受人に譲渡され、２０１４年９月１８日に公開された「DEVICE, SYSTEM, AND METHOD OF WEBSITE BUILDING BY UTILIZING DATA LISTS」という名称の特許文献１に更に詳しく記載されているように）サードパーティのアプリケーション及びそれらのコンポーネント並びにリストアプリケーションを使用して拡張してもよい。

そのようなサードパーティアプリケーション及びリストアプリケーションは、例えばウェブサイト構築システムの設計環境に事前に含まれているような一部の配信メカニズムを通じて、（ウェブサイト構築システム内に組み込まれた又はその外部の）アプリケーションストアから、あるいは、直接、サードパーティアプリケーションのベンダ（販売業者）から購入（さもなければ、取得）してもよい。

ウェブサイト構築システムは、通常、ウェブサイト構築システムベンダによって提供される。ウェブサイト構築システムは、ウェブサイトを設計するユーザ（デザイナとも呼ばれる）によって使用される。そして、それらのウェブサイトは、ユーザのユーザ（users-of-users）（エンドユーザとも呼ばれる）によって使用される。

サードパーティアプリケーションは、ウェブサイト構築システムベンダ自身のサーバ上で、サードパーティアプリケーションベンダのサーバ上で、あるいは、フォース（4th）パーティサーバのインフラストラクチャ上で、ホストされてもよい。

既存のシステムは、通常、コンテナレベルを含むコンポーネントレベルでの編集の実施を可能にしている。従って、既存のシステムは、通常、（例えば、使用可能なコンポーネントタイプのメニューからコンポーネントを選択し、ドラッグアンドドロップを使用することによって）コンポーネントを追加すること、コンポーネントを削除すること、コンポーネントを移動及びサイズ変更すること、コンポーネントのコンテンツを変更すること、（例えば、編集中のコンポーネントに適用可能なフローティング又は固定属性パネルを通じて）コンポーネントの属性を変更すること、コンポーネントをコンテナ内に配置する、あるいは、コンテナ内からコンポーネントを除去すること、などの操作を提供する。

また、既存のシステムは、（例えば、コンポーネントの複数の選択を、グループ化／非グループ化操作と共に、使用することによって）コンポーネントをグループ化することを可能にしてもよい。次に、このシステムは、例えば、移動、サイズ変更、あるいは、属性（例えば、色など）の変更のような操作を、グループ内の全てのコンポーネントについて、実施できるようにしてもよい。

参照により本明細書に組み込まれており、本発明の共通譲受人に譲渡され、２０１８年２月１日に公開された「SYSTEM AND METHOD FOR IMPLEMENTING CONTAINERS WHICH EXTRACT AND APPLY SEMANTIC PAGE KNOWLEDGE」という名称の特許文献２には、コンテナが、如何にして、スマートボックスとして知られるウェブページのコンポーネントの分析の結果として（例えば、図１内のセマンティックコンポジット１１のような）セマンティックコンポジットを形成できる数組のコンポーネントから構成され得るかが記載されている。スマートボックスは、特定の変更を（場合によっては、複数の収容レベルにある）複数の被収容スマートボックスに適用できるようにするＵＩ又はインタフェースを提供してもよい。特許文献２には、厳密なセマンティックコンポジットのマッチング（スマートボックスに適合するタイプに対してのみ変更を適用すること）及びソフトマッチング（単に、特定のスマートボックスに適用可能な場合に、変更を適用すること）が記載されている。これらの変更には、スタイル変更、コンポーネントの追加／除去、レイアウト変更、装飾要素変更などが含まれていてもよい。また、特許文献２には、特定の機能と要件を有するコンポーネントセットを適合させる特殊な編集挙動についても記載されている。このような（ページ分析に基づいて定義される）スマートボックスコンテナは、オーバーライド及びその他の操作もサポートしてもよい。

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

本発明の望ましい一実施形態に従って、ウェブサイト構築システムを提供する。このシステムは、ウェブサイトコンポーネントとそれらに関連付けられたコンポーネント階層とを格納する少なくとも１つのデータベースであり、各々のコンポーネントがオーバーライド可能被パラメータ化挙動要素と非オーバーライド可能被パラメータ化挙動要素とデータハンドラとを含んでおり、このデータハンドラがコンポーネントについてのオーバーライドプロトコルを取り扱う、該少なくとも１つのデータベースと、現在のビューについて、及び、現在のコンポーネントについて、レンダリングされるべき全てのコンポーネントをレビューし、コンポーネント階層内において現在のコンポーネントと少なくとも１つの他のコンポーネントとの間の通信の要求を、少なくとも１つの他のコンポーネントからのオーバーライド要求を満たすために、処理し、このオーバーライド要求が現在のコンポーネントのオーバーライド可能被パラメータ化挙動要素に関係する場合にのみ、現在のコンポーネントのデータハンドラに従って、現在のコンポーネントを更新する要素ハンドラと、を備えている。

更に、本発明の望ましい一実施形態に従えば、このシステムは、現在のビューについての現在のコンポーネントについて要素ハンドラを起動するランタイムサーバを更に備えている。

更に、本発明の望ましい一実施形態に従えば、このシステムは、ユーザがコンポーネントを選択し、この選択されたコンポーネントに編集変更を適用できるようにする被パラメータ化挙動要素の情報を有するＷＢＳ（ウェブサイト構築システム）エディタを更に備えている。

更にまた、本発明の望ましい一実施形態に従えば、現在のコンポーネントは、事前定義済みコンポーネント、リピータコンポーネント及びセマンティックコンポジットのうちの少なくとも１つである。

更に、本発明の望ましい一実施形態に従えば、このシステムは、現在のコンポーネントについてコンポーネント階層を特定し、現在のコンポーネントがセマンティックコンポジットであるか否かを判定するページアナライザを更に備えている。

更に、本発明の望ましい一実施形態に従えば、要素ハンドラは、編集変更の結果としてＷＢＳエディタから、及び／又は、外部ソースによる現在のコンポーネントに対する変更の結果としてランタイムサーバから、現在のコンポーネントとオーバーライド要求とを受信する要求レシーバと、現在のコンポーネントのデータハンドラから現在のコンポーネントのどの被パラメータ化挙動要素がオーバーライド可能であるかを受信し、それに応じてオーバーライド要求の変更を適用し、階層内において現在のコンポーネントと少なくとも１つの他のコンポーネントとの間のオーバーライド競合を解決するコンポーネントリゾルバと、このコンポーネントリゾルバと少なくとも１つの他のコンポーネントについての事前定義済みオーバーライドルールに基づくプロトコルとに従って、現在のコンポーネントの少なくとも１つの被パラメータ化挙動要素と少なくとも１つの他のコンポーネントとの間の通信を可能にするネゴシエータと、を備えている。

更に、本発明の望ましい一実施形態に従えば、要素ハンドラは、ユーザアクティビティと他のウェブサイト及びページの分析とに基づいて、人工知能及び機械学習分析を実施して、前記分析に基づいて前記ウェブサイトコンポーネントについて修正のオーバーライドを推奨する人工知能／機械学習器を備えている。

更にまた、本発明の望ましい一実施形態に従えば、ＷＢＳエディタは、ユーザがウェブサイトコンポーネントの被パラメータ化挙動要素についてオーバーライドルールを作成及び定義できるようにするコンポーネントエディタと、ユーザがコンポーネントを選択できるようにするコンポーネントセレクタと、編集変更をこの選択されたコンポーネントに適用する編集挙動アプライヤと、を備えている。

更に、本発明の望ましい一実施形態に従えば、編集変更は、選択、ドラッグ、ドロップ、サイズ変更、コピー、貼り付け、及び、属性の修正のうちの少なくとも１つを含んでいる。

更に、本発明の望ましい一実施形態に従えば、被パラメータ化挙動要素は、前記現在のコンポーネントのスタイル、ボディ及びロジックのうちの少なくとも１つを表している。

更に、本発明の望ましい一実施形態に従えば、オーバーライド要求は、被パラメータ化挙動要素のオーバーライド可能なパラメータに対するものである。

更にまた、本発明の望ましい一実施形態に従えば、ウェブサイトコンポーネントは、ＷＢＳエディタによるコンポーネントの表現及び編集プロセスに影響を与えるエディタ挙動ドライバと、コンポーネントが、ランタイムにおいてランタイムサーバによって、如何に処理されるかに影響を与えるランタイム挙動ドライバと、現在のコンポーネントについてのレンダリング命令を、ＷＢＳエディタ及びランタイムサーバに、提供するコンポーネントレンダリング機能と、のうちの少なくとも１つを更に含んでいる。

本発明の望ましい一実施形態に従って、ウェブサイト構築システムのための方法であって、ウェブサイトコンポーネントとそれらに関連付けられたコンポーネント階層とを格納するステップであり、各々のコンポーネントがオーバーライド可能被パラメータ化挙動要素と非オーバーライド可能被パラメータ化挙動要素とデータハンドラとを含んでおり、データハンドラがコンポーネントについてのオーバーライドプロトコルを取り扱う、該格納するステップと、現在のビューについて、及び、現在のコンポーネントについて、レンダリングされるべき全てのコンポーネントをレビューし、コンポーネント階層内において現在のコンポーネントと少なくとも１つの他のコンポーネントとの間の通信の要求を、少なくとも１つの他のコンポーネントからのオーバーライド要求を満たすために、処理し、オーバーライド要求が現在のコンポーネントのオーバーライド可能被パラメータ化挙動要素に関係する場合にのみ、現在のコンポーネントのデータハンドラに従って、現在のコンポーネントを更新するステップと、を備えた、該方法を提供する。

更に、本発明の望ましい一実施形態に従えば、この方法は、ランタイムにおいて、現在のビューについての現在のコンポーネントについて、上述のレビューし、処理し、更新するステップを起動するステップを更に備えている。

更に、本発明の望ましい一実施形態に従えば、この方法は、編集セッション中に、ユーザがコンポーネントを選択し、この選択されたコンポーネントに編集変更を適用できるようにするステップを備えている。

更にまた、本発明の望ましい一実施形態に従えば、現在のコンポーネントは、事前定義済みコンポーネント、リピータコンポーネント及びセマンティックコンポジットのうちの少なくとも１つである。

更に、本発明の望ましい一実施形態に従えば、この方法は、現在のコンポーネントについてコンポーネント階層を特定するステップと、現在のコンポーネントがセマンティックコンポジットであるか否かを判定するステップと、を更に備えている。

更に、本発明の望ましい一実施形態に従えば、上述のレビューし、処理し、更新するステップは、編集変更の結果として、上述のユーザができるようにするステップから、及び／又は、外部ソースからの変更による現在のコンポーネントに対する変更の結果として、上述のランタイムにおける起動するステップから、現在のコンポーネントとオーバーライド要求とを受信するステップと、現在のコンポーネントのデータハンドラから現在のコンポーネントのどの被パラメータ化挙動要素がオーバーライド可能であるかを受信し、それに応じてオーバーライド要求の変更を適用し、階層内において現在のコンポーネントと少なくとも１つの他のコンポーネントとの間のオーバーライド競合を解決するステップと、この受信し、適用し、解決するステップと少なくとも１つの他のコンポーネントについての事前定義済みオーバーライドルールに基づくプロトコルとに従って、現在のコンポーネントの少なくとも１つの被パラメータ化挙動要素と少なくとも１つの他のコンポーネントとの間の通信を可能にするステップと、を備えている。

更にまた、本発明の望ましい一実施形態に従えば、上述のレビューし、処理し、更新するステップは、ユーザアクティビティと他のウェブサイト及びページの分析とに基づいて、人工知能及び機械学習分析を実施するステップと、分析に基づいてウェブサイトコンポーネントについて修正のオーバーライドを推奨するステップと、を更に備えている。

更にまた、本発明の望ましい一実施形態に従えば、ユーザがコンポーネントを選択し、編集変更を適用できるようにする上述のステップは、ユーザがウェブサイトコンポーネントの被パラメータ化挙動要素についてオーバーライドルールを作成及び定義できるようにするステップと、ユーザがコンポーネントを選択できるようにするステップと、編集変更をこの選択されたコンポーネントに適用するステップと、を備えている。

更に、本発明の望ましい一実施形態に従えば、編集変更は、選択、ドラッグ、ドロップ、サイズ変更、コピー、貼り付け、及び、属性の修正のうちの少なくとも１つを含んでいる。

更に、本発明の望ましい一実施形態に従えば、被パラメータ化挙動要素は、現在のコンポーネントのスタイル、ボディ及びロジックのうちの少なくとも１つを表している。

更に、本発明の望ましい一実施形態に従えば、オーバーライド要求は、被パラメータ化挙動要素のオーバーライド可能なパラメータに対するものである。

本発明と考えられる要旨は、本明細書の結論部分において詳しく示されており、且つ、明確に主張されている。しかしながら、本発明は、下記の添付図面を参照しながら次の詳細な説明を読むことによって、構成及び動作方法の両方に関して、それらの目的、特徴及び利点と共に、最も良く理解されるであろう。

ウェブサイト構築システムとこのウェブサイト構築システムを使用して作成されたページとの代表的な表現の概略的な説明図である。 本発明に従って構成されて動作するセマンティックコンポジット上の被パラメータ化挙動要素の適用の概略的な説明図である。 本発明に従って構成されて動作する被拡張コンポーネントの概略的な説明図である。 本発明に従って構成されて動作する被パラメータ化挙動要素を使用する２つのコンポーネント相互間の関係の概略的な説明図である。 本発明に従って構成されて動作する、ウェブサイトのコンポーネントとコンテナとの間のスマートインタラクション用のシステムの概略的な説明図である。 本発明に従って構成されて動作する図５の被拡張要素ハンドラの要素の概略的な説明図である。 本発明に従って構成されて動作する図５のコンテンツ管理システムの要素の概略的な説明図である。 本発明に従って構成されて動作する図５のＷＢＳエディタの要素の概略的な説明図である。 本発明に従って構成されて動作するコンポーネントの階層内のオーバーライドの例示的なフローの概略的な説明図である。 本発明に従って構成されて動作するＶボックススマートコンテナ内の垂直整列線についての構成の概略的な説明図である。 本発明に従って構成されて動作する被収容コンポーネントについての移動ハンドル、サイズ変更ハンドル及び追加のハンドルを管理する特別なコンテナコンポーネントの概略的な説明図である。

説明図を簡単明解にするために、図示の要素は必ずしも一定の縮小比では描かれていないことが理解されるであろう。例えば、一部の要素の寸法は、明解にするために他の要素に比べて誇張されている場合がある。更に、適切と考えられる場合、対応する又は類似する要素を示すために、参照番号を図相互間で繰り返すことがある。

以下の詳細な説明では、本発明の完全な理解のために、多くの具体的な詳細事項を記載している。しかしながら、当業者であれば、これらの具体的な詳細事項なしでも本発明を実施し得ることが分かるであろう。その他の場合、本発明を不明瞭にしないために、周知の方法、手順及び構成要素は、詳細には説明していない。

本願出願人は、従来技術のシステムが、内的な（即ち、ウェブサイトデザイナによって又は明示的に設計される）及び外的なファクタに基づいて常に更新を必要とするウェブサイトのルックアンドフィール（look and feel）を維持するためにしばしば必要とされる複雑な挙動及び複雑なコンポーネントインタラクションを考慮していないことに気付いた。これらの（コンポーネントレベルで固有な場合もある）更新は、これらを効率的に定義して簡単かつ効率的に実施するために、ウェブサイト構築システム自体の使用に関する詳細な知識を必要とすることが多い。更に、ウェブサイトコンポーネント（外部のサードパーティアプリケーションコンポーネントを含む）には、ウェブサイト構築システム環境内の複数の階層レベルに亘る同じ階層構成内の他のコンポーネントに影響することもある挙動が適用されることがある。

一般的なウェブサイト構築システムには、３つのタイプのユーザ、即ち、ウェブサイト構築システムベンダスタッフ又は（例えば、コンポーネントストア又はサードパーティアプリケーションストアを介する）別個のコンポーネントプロバイダの一部であり得るコンポーネントプロバイダ自身と、コンポーネントを使用してサイトを構築するウェブサイトデザイナ自身と、完成したサイトを使用するビューア又はエンドユーザと、があり得ることが理解されるであろう。また、クラス相互間に何らかの混合が存在する場合があることも理解されるであろう。特に、ウェブサイト構築システムは、デザイナ（又はその一部）が既存のコンポーネントを編集でき、あるいは、自分自身の新しいコンポーネントを追加することさえもでき、例えば、サイトデザイナが定義したコンポーネントコレクションを１つのコンポーネントとして保存して、特許文献２と、参照により本明細書に組み込まれており、本発明の共通譲受人に譲渡され、２０１７年２月１６日に公開された「METHOD AND SYSTEM FOR SECTION-BASED EDITING OF A WEBSITE PAGE」という名称の特許文献３と、に記載されたものと類似する他のサイトデザイナに利用可能となり得るようにしてもよい。

本願出願人は、（例えば）コンポーネントの動作的及び／又は視覚的挙動を定義してもよい被パラメータ化挙動要素を自己の中に有するウェブサイトコンポーネントを処理するシステムによってウェブサイト構築体験が改善され得ることを認識している。コンポーネントは、自己の被パラメータ化挙動要素を使用して他のコンポーネントとの一形態の通信を呼び出して、本明細書において更に詳細に後述する如く、パラメータを送受信できる場合がある。例えば、コンポーネントＡは、コンポーネントＢに通知してコンポーネントＢの被パラメータ化挙動要素Ｘを被パラメータ化挙動要素Ｙに置き換えさせてもよい。所与の被パラメータ化挙動要素は、所与のコンポーネントタイプ又はコンポーネントインスタンスのコンテキストにおいて、オーバーライド可能である又はオーバーライド可能ではない（その他においてはオーバーライド可能ではない）ように事前定義されてもよいことが理解されるであろう。従って、（例えば）（図１に示された）ウェブページの階層的性質によって、単一の現在のコンポーネントに加えられた動作上の変更が、全ての収容レベルの他のコンポーネントにも影響を及ぼす可能性がある（ことによると、この影響を及ぼす方のコンポーネントの同じサブ階層においてはその可能性はないかもしれない）、そして、その逆の場合も同様である。例えば、コンテナは、それらの中に在る複数のレベルの被収容コンポーネントとインタラクトしてもよく、その際、このインタラクションは、コンテナと被収容コンポーネントとの両方が、被収容コンポーネントのどの属性がどのような態様で（コンテナによって）影響を受けてもよいかを決定できるようにする事前定義済みルールのプロトコルに基づいて、行われる。このプロトコルについてのロジックには、例えばジオメトリ、セマンティクス、コンテンツ、編集履歴などのような他のコンポーネント／コンテナとのコンポーネント関係のアウェアネス（awareness）と共に、被パラメータ化挙動要素についての「交渉可能な(negotiable)」オーバーライドについてのルールが含まれていてもよい。被収容コンポーネントも、同様に、そのコンテナに影響を及ぼす可能性がある。オーバーライドは、被パラメータ化挙動要素の属性又はパラメータを変更することを意味し得るか、あるいは、本明細書において更に詳細に後述する如く、１つ又は複数の被パラメータ化挙動要素の完全な置き換えを意味し得ることが理解されるであろう。

本願出願人は、更に、上述の原理を拡張して、被収容コンポーネントのレイアウト構成について人工知能（ＡＩ）及び機械学習（ＭＬ）ベースの修正を提供し得るコンテナをサポートしてもよいことを認識している。そのような修正には、レイアウトのみ（例えば、位置とサイズとを選択すること）、被制限属性セット（例えば、コンテナは、その中に在るサブコンテナに、特定の背景イメージ／ビデオを提供してもよく、あるいは、単に色の選択などに影響を与えてもよい）、挙動、あるいは、例えば被収容コンポーネントの追加、除去、並べ替えなどのような任意の特定の被収容コンポーネントの挙動が含まれていてもよい。一部の実施形態において、これは、非コンテナコンポーネントにも適用されてもよい。

また、本願出願人は、上述の被パラメータ化挙動要素の使用によって、カスケードスタイルシート（Cascading Style Sheet）（ＣＳＳ）のような従来技術の方法よりも、ウェブページフォーマッティングが定義される態様を改善し得ることも認識している。既存のＣＳＳベースのシステムは、（ブラウザ、ユーザ及びサイト自体によって提供される）複数のスタイルシートからルールを収集して、これらのルールをサイト内の要素にマッチングすることによって、要素のスタイル又は挙動に影響を与える。このマッチングは、各々のルールが提供されるセレクタに基づいており、これらは、一般的に、ＨＴＭＬ要素タイプ（例えば、ＤＩＶなど）、クラス、ＩＤ、あるいは、それらの組み合わせに基づいている。従来技術のシステムは、デフォルトの挙動を有するコンポーネントと、それらをオーバーライドするオプションと、を更に備えている場合があるが、それは、被パラメータ化挙動要素の使用によってではない。要素は、暗示的な（デフォルトの）スタイル又は挙動を有している場合がある。例えば、ＤＩＶは、暗示的に、親要素の使用可能なスペースの１００％にまで拡張されるボックスである。

本願出願人は、更に、被パラメータ化挙動要素の使用が、コンポーネントが、誰が自分に影響を与えてもよいか、あるいは、否か（例えば、「ギャラリのみが自分のサイズを修正してもよい」）を規定できるようにする追加機能によって、ウェブページ全体に亘るスタイルを構築することを可能にすることを認識している。特に、この規定は、（例えば）コンポーネントのコンテンツ、ジオメトリ、タイプ、セマンティックタイプ、編集履歴、ビジネス情報（ＢI）、及び、コンポーネント間の関係、に関するコンポーネント分析に基づいていてもよい。このような分析は、追加のコンポーネント分類と（デザイナによって明示的には提供されなかった）関連情報とを提供してもよく、この情報を使用して、分析済みコンポーネントに対するスタイル（又はその他の属性）の適用可能性を判定してもよい。例えば、「コンテナ内の検出された全ての画像と表題とのペアに赤色のベベルを適用する」の場合には、表題と画像とのペアが、特許文献２に記載されているように、コンポーネント分析を通じて（事前定義されているのではなく）検出される。

次に、この検出及び分類を例示した図２を参照する。行１には、６つの無関係なオブジェクト、即ち、３つの笑顔と３つの表題とが示されている。行２には、本システムが、どのように、命令に従って、笑顔と表題のペアを（セマンティックコンポジットとして）認識して、各々の顔／表題ペアの周りにフレームを適用するか、が示されている。行３には、ユーザが右端の「ペア」の表題を移動した場合でも、どのように、それらの間の距離が依然として顔／表題ペアの定義内にあり、従って、フレームが依然として適用されているか、が示されている。次に、行４を参照すると、これには、表題をセマンティックコンポジット定義の要件の範囲外に移動した時に（従って、顔／表題ペアのセマンティックコンポジットとして認識されなくなった時に）、どのように、このペアの周囲からフレームが無くなったか、が示されている。行５では、右端の画像が変更されており、本システムはそれを笑顔として認識せず、従って、フレームを描画していない。この機能は、顔イメージと表題とのペアを識別できないので、通常のＣＳＳには適用できないことが理解されるであろう。

本願出願人は、この使用によって、収容しているコンポーネントが複数のレベル（コンポーネントコンテナ内にネストされた収容しているコンポーネント）に影響を与えることができるようになり、その結果、適用されるコンポーネント修正が「深く」なり得ることも認識している。例えば、「全ての収容レベルにおいて、全ての被収容ビデオプレーヤを、巻き戻しボタンなしで、現れるようにする」、あるいは、「ビデオＸを有するビデオ背景を全ての被収容サブコンテナに適用する」などである。

一般に、ウェブサイトのコンポーネントは、高度に設定可能であり、それらの属性と操作は、内部及び外部の両方のソース（例えば、通常のサイト階層の外側に在り、サイト内では見えないこともあるコンポーネント）から、それらが関連付けられているウェブサイト構築システムまで、影響を受け得ることが理解されるであろう。例えば、特定のサイトコンポーネントを時刻や季節に適合させるサービスなどである。（ページの所与のコンテナ内の）被収容コンポーネントのリストは、事前定義されてもよく、あるいは、動的に特定されてもよく、多数の様々なシナリオにおいて、例えば、コンポーネントがアクセス可能な属性で事前規定されているウェブサイト構築システムシナリオにおいて、あるいは、所与のウェブサイトページについて分析を実施して、そのページの、コンポーネント及びコンテナ並びにそれらの属性への区分を特定する非ウェブサイト構築システムシナリオにおいて、使用されてもよい。

ウェブサイトコンポーネントの定義には、一般的に、３つの主要なサブエンティティ、即ち、スタイル、ボディ及びロジックの要素（並びに本明細書において更に詳細に後述する如くの追加の要素）が含まれていることが理解されるであろう。コンポーネントのスタイルは、任意のスタイル定義言語又はその拡張バージョンによって定義されてもよい。コンポーネントのボディは、任意の標準的なコンテンツ定義言語（例えば、ＨＴＭＬ、ＸＭＬ又はＪＳＯＮなど）によって、あるいは、独自開発の又は非標準的な言語（例えば、ＪＳＸなど）によって、定義されてもよい。

コンポーネントのロジックは、任意の手続き型言語、例えばＪａｖａＳｃｒｉｐｔ又はＴｙｐｅＳｃｒｉｐｔによって、あるいは、ウェブサイトにおいてネイティブコード要素の使用を可能にする任意の通常のプログラミング言語によって、定義されてもよい。あるいは、それは、もしランタイムにおける関係するウェブサイト構築システムがネイティブクライアントを使用して実施されるならば、専用ブラウザ、ブラウザアドオン（browser add-on）又はモバイルアプリを通じて、定義されてもよい。それには、コンポーネントのビジネス／運用ロジックが収容されている。ロジック定義言語には、基礎となる言語に対する様々な言語拡張（例えば、通常のＪａｖａＳｃｒｉｐｔ言語を拡張するＥ－ＪＳ言語など）も含まれていてもよい。

（コンポーネント定義の一部分である）これらの要素は、コンポーネントのＳＢＬ（スタイル／ボディ／ロジック）要素として（一緒に）参照されてもよいことが理解されるであろう。このようなコンポーネント定義は、開発者（例えばエディタなど）に利用可能な通常のツールを使用してシステムの外部で作成されてもよい。その代わりに、システムは、（エディタと統合されても、あるいは、されなくてもよい）コンポーネント編集環境を提供してもよい。このようなコンポーネント編集環境は、ウェブサイト構築システムベンダのスタッフにのみ利用可能であってもよい。あるいは、このコンポーネント編集環境は、外部のコンポーネント開発者に、又はサイトデザイナに、利用可能であるようにして（それらが自分自身のコンポーネントを定義できるようにして）もよい。

コンポーネント定義には、追加情報も含まれていてもよく、例えば、相異なる条件下で使用される複数の構成及びバリアントと、システムエディタが、ウェブページ内の特定のコンポーネントのインスタンスの編集をサポートするために、使用し得る編集ドライバ及び追加の編集関連情報（例えば、動的レイアウトヒント）と、が含まれていてもよい。この追加情報には、本明細書において更に詳細に後述する如く、現在のビューについての編集プレビュー及びランタイムの両方の期間中に使用するコンポーネントレンダリング機能も含まれていてもよい。

ウェブサイトのページは、コンポーネント定義リファレンスの他に追加情報（例えば、コンテンツ、階層位置、画面位置、サイズ、様々なレイアウト、コンポーネントのメタデータ、及び、その他の属性）を含み得るコンポーネントインスタンスの階層を使用して、構築されてもよいことが理解されるであろう。

次に、図３を参照すると、これには、本発明の一実施形態に従って、代表的な拡張コンポーネント１０の定義が例示されている。拡張コンポーネント１０は、それに含まれている被パラメータ化挙動要素を介してスタイル、挙動及び動作の変更を通信することによって、関連コンポーネント相互間のスマートインタラクションを可能にし得ることが理解されるであろう。拡張コンポーネント１０は、従来技術の通常のウェブサイトコンポーネントの構造を超える拡張又は追加構造を備えていてもよい。拡張コンポーネントの定義には、本明細書に上述したようなスタイル、ボディ及びロジックの要素が含まれていてもよく、しかしながら、以下更に詳しく述べるような定義済みのルール及びプロトコルレゾリューションに従ってオーバーライドを許可する場合と許可しない場合とがある被パラメータ化挙動要素も含まれていてもよいことが理解されるであろう。

拡張コンポーネント１０は、また、エディタ挙動ドライバ１５Ａ、ランタイム挙動ドライバ１５Ｂ、コンポーネントレンダリング機能１５Ｃ、オーバーライドデータハンドラ１６、メタデータ１７及び固定領域１８も備えていてもよい。

エディタ挙動ドライバ１５Ａは、コンポーネント及びそれに収容されるコンポーネントが、使用中のエディタによって（例えば、動的レイアウトヒントを提供することによって）、処理される態様に影響を与え得る。

ランタイム挙動ドライバ１５Ｂは、コンポーネント及びそれに収容されるコンポーネントがランタイム期間中に処理される態様に影響を与え得る。コンポーネントレンダリング機能１５Ｃは、編集プレビューとランタイムの両方の期間中にレンダリング命令を与え得る。例えば、入力コンポーネントは、ウェブサイト構築システムのユーザに役立つフィードバックを提供するために、クイック応答レンダラを使用してもよい。

コンポーネントレンダリング機能１５Ｃは、通常、ウェブサイト構築システムのメインレンダリングプロセスと連携させてもよく、ウェブサイト構築システムの表示プロセスの任意の部分に（ウェブサイト構築システムの実施に応じて）影響を与え得る。例えば、ブラウザを通じてページを表示するウェブサイト構築システムについて、コンポーネントレンダリング機能１５Ｃは、保存済みページのＨＴＭＬ／ＣＳＳ／ＪＳへの変換と、ブラウザにおける生成済みＨＴＭＬ／ＣＳＳ／ＪＳのレンダリングと、の両方に影響を与え得る。

オーバーライドデータハンドラ１６は、コンポーネントについての上述の事前定義されたルール及びプロトコルレゾリューションに関する情報、即ち、オーバーライド条件が何であるかを通知し得る。メタデータ１７には、コンポーネントのメタデータ（例えば、作成者情報及び内部参照ＩＤなど）も含まれていてもよい。固定領域１８には、オーバーライドできないコンポーネントの要素、例えば、コンテンツが各々のコンポーネントインスタンスに格納されるコンポーネント内の領域など、が収容されている。

被パラメータ化挙動要素が通常のプログラミング言語における機能パラメータと同等にみなされ得ることが理解されるであろう。従って、単一の拡張コンポーネント１０は複数の被パラメータ化挙動要素を収容していてもよく、それらの各々が、相異なるタイプを有しており、拡張コンポーネント１０の相異なる部分に（許可されている場合）影響を与える。例えば、スタイルの被パラメータ化挙動要素タイプがスタイルを処理してもよく、レイアウトの被パラメータ化挙動要素タイプがレイアウトなどを処理してもよい。また、被パラメータ化挙動要素は、標準のＳＢＬ分類に必ずしも準拠しているわけではなく、複数のＳＢＬ要素及び他の要素をオーバーライドしてもよいことも理解されるであろう。

以下、説明の便宜上、ウェブサイトコンポーネントへの言及は、本明細書で上述した拡張コンポーネント１０を意味していることが理解されるであろう。

レイアウトの被パラメータ化挙動要素は、コンポーネントの内部（サブ）コンポーネント、例えば、スライダギャラリ対グリッドギャラリ対Ｖｂｏｘが配置される態様を定義してもよい。スタイルの被パラメータ化挙動要素は、コンポーネント又はそのサブ要素によって使用されるビジュアルパラメータを定義してもよい。

従って、例えば、ページデザイナは、所望のグリッドギャラリコンポーネントを埋め込んでもよいが、その内部挙動をオーバーライドして、スライダ配置を使用して（スライダレイアウトの被パラメータ化挙動要素をグリッドベースのギャラリの一部分として提供することによって）ギャラリのコンテンツを配置してもよい。

また、一部の被パラメータ化挙動要素タイプ（例えば、レイアウトの被パラメータ化挙動要素など）は、スタンドアロンのコンポーネントとして、即ち、別のコンポーネントに適用されることなく、機能し得ることも理解されるであろう。従って、グリッドレイアウトの被パラメータ化挙動要素は、単純なグリッドコンポーネントとして（単独で）機能してもよい。

また、コンポーネントは、コンポーネント定義と共に完全なコンポーネントを形成する複数の被パラメータ化挙動要素を含むことをサポートしてもよい。例えば、ボタンのコンポーネントは、背景の被パラメータ化挙動要素とレイアウトの被パラメータ化挙動要素とを含むことをサポートしてもよい。ボタンのコンポーネントは、単独でボタンについての基本的なフレームワークを提供してもよい（例えば、「押された」及び「押されていない」の構成とそれらに関連する「私は押された（I was pressed）」のイベントトリガとを有する被表示オブジェクトを提供してもよい）。これらの２つの含まれた被パラメータ化挙動要素は、ボタンについての背景と、ボタン上に記述される要素についての表示レイアウトと、を提供してもよい。

これらの２つの被パラメータ化挙動要素は、例えば、ビデオ背景被パラメータ化挙動要素（これはボタンについてのビデオ背景を表示する）と、Ｈｂｏｘ（水平ボックス）タイプのレイアウト被パラメータ化挙動要素（これは例えばラベルと小さなアイコンとのようなボタン表面要素を水平方向に並べて表示する）と、であってもよい。

（上述の例について）被パラメータ化挙動要素はボタンのコンポーネントに固有ではないことが理解されるであろう。同じビデオ背景被パラメータ化挙動要素とＨｂｏｘタイプのレイアウト被パラメータ化挙動要素とを、他のコンポーネントタイプ（例えばフォーム又はコンテナなど）について、別々に又は一緒に使用してもよい。更に、被パラメータ化挙動要素の呼び出しは、コンポーネントインスタンスの一部分であってもよく（その定義ではない）、その結果、あるボタンが（例えば）ビデオ背景の被パラメータ化挙動要素を使用してもよく、別のボタンがイメージ背景の被パラメータ化挙動要素を使用してもよい。

コンポーネント内で使用される被パラメータ化挙動要素は、コンポーネント自体のプロパティとパラメータとを使用してもよく、また、被パラメータ化挙動要素の特定の呼び出しについて、ホスト又は親コンポーネントのインスタンス定義の一部分として、提供される特定のプロパティとパラメータとを使用してもよいことも理解されるであろう。コンポーネントは、そのコンポーネントの相異なる部分について同じタイプの複数の被パラメータ化挙動要素を使用してもよい。例えば、２列コンポーネントは、第１の列について１つのレイアウト被パラメータ化挙動要素（例えばＶｂｏｘなど）を使用して、第２の列について別のレイアウト被パラメータ化挙動要素（例えばＨｂｏｘなど）を使用してもよい。

子コンポーネントインスタンスを含む親コンポーネントインスタンスは、本明細書で以下により詳細に説明するように被パラメータ化挙動要素の適用を通じて子コンポーネントインスタンスを修正してもよい（及び、その逆も同様である）ことが理解されるであろう。単一のコンポーネントが、コンポーネントの表示及び機能の様々な要素に影響を与える複数の被パラメータ化挙動要素タイプによって、修正されてもよい。そのような被パラメータ化挙動要素タイプは、コンポーネントのＳＢＬサブエンティティ、即ち、そのスタイル、ボディ及びロジックのいずれにも影響を与えてもよい。相異なる被パラメータ化挙動要素は、通常（常にではないが）、コンポーネントの相異なる様相（aspect）に影響を与え、従って、複数の被パラメータ化挙動要素がコンポーネントに「適用」される順序は、状況に応じて関係ある場合と関係ない場合とがある。単一の被パラメータ化挙動要素が、コンポーネントの複数のＳＢＬサブエンティティ、例えば、コンポーネントのスタイルとボディの両方に影響を与えてもよい。実際の被パラメータ化挙動要素の適用は、レンダリングプロセス中に実施してもよい。被パラメータ化挙動要素を実施するシステムは、（フォローアップ処理を節約するために）コンポーネント又はページ公開を呼び出している間に前処理を行ってもよい。

本明細書において上述した如く、被パラメータ化挙動要素タイプの１つのタイプはレイアウトであり、これは、例えば、内部要素を水平線に沿って表示する上述のＨｂｏｘ（水平ボックス）レイアウト被パラメータ化挙動要素のようなコンポーネントのサブ要素について使用されるレイアウト（位置及び場合によりサイズ）を制御する。

別の一例は、マトリックスギャラリレイアウトの被パラメータ化挙動要素を汎用ギャラリコンポーネントに適用することである。作成済みマトリックスギャラリコンポーネントは、その内部要素を行と列とのマトリックスで表示し、場合によっては、スクロールによって、基本的なマトリックスサイズで許容されるよりも多くの要素を示すこともある。

更に別の一例はユーザ移動可能レイアウトの被パラメータ化挙動要素であり、これは、内部要素を所定の初期位置の順序に配置しているが、アプリケーションのエンドユーザが（コンテナランタイム挙動ドライバ１５Ｂによって規定される）ランタイム中にコンテナ内でこれらの要素を移動することを可能にする。

本明細書において上述した如く、被パラメータ化挙動要素タイプの別のタイプはスタイルであり、これは、コンポーネントのビジュアル（視覚的）表現の要素（例えば、コンポーネントの色、余白など）を制御する。

スタイルの被パラメータ化挙動要素タイプは、例えば、背景の置換用に使用されてもよい。高度なビデオプレーヤコンポーネントには、カスタマイズ可能な複数のボタンと制御領域とが含まれていてもよい。スタイルの被パラメータ化挙動要素タイプは、ビデオプレーヤコンポーネントの個性化バージョンを作成するために、ボタンと制御領域の背景の色及びパターンを置き換えるのに使用されてもよい。

また、スタイルの被パラメータ化挙動要素タイプは、被収容コンポーネントの他の（非レイアウトの）パラメータにも影響を与えてもよい。これは、（コンポーネントに収容されているコンポーネントではなく）そのコンポーネント自体の表現に影響を与える被パラメータ化挙動要素とは異なる場合がある。

本明細書において上述した如く、コンポーネント定義は、（スタイル、ボディ及びロジックと追加の要素とを表す）複数のサブ要素で構成されていてもよい。アプリケーション内のコンポーネントインスタンス定義の一部分として、これらの要素の幾つかのものは、（適切なルールネゴシエーションに従う）被パラメータ化挙動要素によって、オーバーライドされてもよい。これらの置換の被パラメータ化挙動要素は、それら自体、自己の挙動又は機能を規定するパラメータを有していてもよい。そのようなパラメータが必要である（即ち、これらが提供されなければ、被パラメータ化挙動要素が機能しない）場合がある、あるいは、その代わりに、被パラメータ化挙動要素がそれらの値についてのデフォルトを提供してもよい。

例えば、ボタンコンポーネントは、ボタンの形状を制御するスタイルの被パラメータ化挙動要素の規定を可能にしてもよい。特定のスタイルの被パラメータ化挙動要素は、楕円のような形状を提供してもよく、その楕円の垂直方向及び水平方向の直径を規定するパラメータを受け入れてもよい。ボタンインスタンスは、この楕円の被パラメータ化挙動要素を呼び出してもよく、そして、特定のパラメータ値（例えば、垂直方向の直径について１００ピクセル、水平方向の直径について２００ピクセルなど）を提供してもよい。

次に、図４を参照すると、これにはアプリケーション内の２つのコンポーネント相互間の関係が例示されている。見て分かるように、アプリケーション内のＣＯＭＰ２のインスタンスには、そのコンポーネント定義用に、他のコンポーネント（このシナリオではＣＯＭＰ１）から得られる被パラメータ化挙動要素（Parameterized-Behavior Elements）と、これらの被パラメータ化挙動要素についての特定のパラメータと、が必要である。そして次に、これらの被パラメータ化挙動要素とパラメータは、コンポーネントのスタイル、ボディ、ロジック及びその他の要素に影響を与え得る。

図４に例示されているように、単一のコンポーネントが、他のコンポーネントから複数のパラメータ化挙動要素を受け入れてもよい。これは、（本明細書において以下により詳細に説明するように）ネゴシエーション要素を介してもよい。このような複数の被パラメータ化挙動要素は、相異なる又は累積的な効果を有していてもよい。例えば、ギャラリコンポーネントは、２つのスタイル被パラメータ化挙動要素、即ち、ギャラリフレームの背景領域に影響を与えるものと、ギャラリが管理するサブコンポーネントに影響を与えるものと、の使用を可能にしてもよい。

コンポーネントは、別のコンポーネントから、その他の（非被パラメータ化挙動要素の）複合の又は混成のパラメータ、例えば、アグレゲート（aggregate）タイプ（例えば、リスト、構造及びユニオン(union)など）に基づくパラメータも受け入れてもよいことが理解されるであろう。

また、ウェブライク（web-like）言語（即ち、Ｅ－ＨＴＭＬ／ＣＳＳ／ＪＳ）を使用してページ又はコンポーネントを定義する実施形態において、被パラメータ化挙動要素も、コンポーネントについて（本明細書において以下により詳細に説明する）呼び出しパラメータ／属性を使用して、あるいは、特定の被パラメータ化挙動要素タイプについての追加ルールを有するスタイルシート、例えば、

を通じて、規定されてもよいことも理解されるであろう。

被パラメータ化挙動要素タイプ（例えば、レイアウトの被パラメータ化挙動要素など）は、一般的に、限られた／特定の機能を有していることが理解されるであろう。これは、ギャラリ内における被収容コンポーネントの物理的なレイアウトのみを処理するだけ（例えば、マトリックス／スライダカルーセル配置を提供するなど）の場合があり、従って、通常、完全なＳＢＬ仕様を含んでいない。しかしながら、被パラメータ化挙動要素には特定の追加の属性が含まれている場合がある。例えば、特定のマトリックスレイアウトの被パラメータ化挙動要素タイプは、一部の視覚的属性も含んでいてもよく（例えば、ホストコンポーネントの一部のサブコンポーネントに黄色の背景を適用する）。しかしながら、レイアウトの被パラメータ化挙動要素タイプの通常の定義は、サブコンポーネントの配置に焦点を当てており、通常、追加の属性及びプロパティを含んでいない。

また、被パラメータ化挙動要素は、通常、ウェブサイト構築システムの（本明細書において以下により詳細に説明する）コンポーネント編集機能を通じて、あるいは、場合によっては、専用の被パラメータ化挙動要素固有のエディタによって、作成されることも理解されるであろう。

従って、拡張コンポーネントは、その標準のスタイル、ボディ及びロジックに加えて、コンポーネントのレイアウトと、構成と、エディタ駆動と、レンダリングプロセスと、ランタイム挙動とに関する情報を含む被パラメータ化挙動要素を備えていてもよい。拡張コンポーネントは、他の関連コンポーネントから（被パラメータ化挙動要素を介して）、ＳＢＬ要素又はそれらの一部分のいずれかを規定する、追加する、あるいは、修正することが可能なパラメータを受け入れてもよい。

次に、図５を参照すると、これには、本発明の一実施形態に従う、ウェブサイトコンポーネントとコンテナとの間のスマートインタラクションのためのシステム２００が例示されている。

システム２００には、ウェブサイト構築システム、被拡張要素ハンドラ２１０、ＷＢＳ（website building system：ウェブサイト構築システム）ランタイムサーバ２２０、ＷＢＳ（ウェブサイト構築システム）エディタ２３０、サイト生成システム２４０、コンテンツ管理システム２５０及びページアナライザ２６０が含まれていてもよい。ウェブサイト構築システム２０５は、ウェブサイト構築システムのベンダスタッフ２６１によって操作されるクライアントシステムと、サイトデザイナ２６２と、サイトビューア２６３と、及び、外部システム２７０と通信してもよい。

システム２００とその要素の機能とは、特許文献２に記載されたシステム１００のものと同様であってもよいことが理解されるであろう。

システム２００のワークフローは、３つのステージを有していてもよいことが更に理解されるであろう。第１ステージはコンポーネント定義であってもよく、第２ステージはページ定義であってもよく、第３ステージは、ＷＢＳエディタ２３０を使用したプレビュープロセスを介する、特許文献２に記載されたようにＷＢＳランタイムサーバ２２０によって実施されるランタイムプロセスの一部分としての、ページレゾリューションであってもよい。

被拡張要素ハンドラ２１０は、被パラメータ化挙動要素に関する関連ウェブサイトコンポーネント相互間の通信を処理してもよい。次に、図６を参照すると、これには被拡張要素ハンドラ２１０の要素が例示されている。被拡張要素ハンドラ２１０には、リクエストレシーバ２１１と、リゾルバ２１２と、ネゴシエータ２１３と、本明細書において以下により詳細に説明するＡＩ及び機械学習原理を組み込んでいてもよいＡＩ／機械学習器２１４と、が含まれていてもよい。

次に、図７を参照すると、これに例示されている如く、ＣＭＳ（content management system：コンテンツ管理システム）２５０は、ウェブサイト構築システム２０５に関係する全ての形態のコンテンツ及びレイアウトを保持していてもよい。コンテンツ管理システム２５０には、ウェブサイトコンポーネントタイプリポジトリ２５０１、ウェブサイト被パラメータ化挙動要素リポジトリ（website Parameterized-Behavior Elements repository）２５０２、ＷＢＳ（ウェブサイト構築システム）コンポーネントリポジトリ２５０３、ＷＢＳサイトリポジトリ２５０５、ビジネスインテリジェンスリポジトリ２５０６、編集履歴リポジトリ（Editing History repository）２５０７、ユーザ情報リポジトリ２５０８、ルールリポジトリ２５０９、ＭＬ／ＡＩ（機械学習／人工知能）リポジトリ２５１０、レイアウトリポジトリ２５１１、及び、コンテンツ管理システム２５０とシステム２００との間でデータを調整するコンテンツ管理システムコーディネータ（Content Management System COORDinator）２５１２が含まれていてもよい。ＣＭＳ２５０のセットアップ及び機能は特許文献２におけるＣＭＳ５０のものと同様であってもよいことが理解されるであろう。

ページアナライザ２６０は、２０１７年８月２９日に発行されており、本発明の共通譲受人に譲渡されている「SYSTEM AND METHOD FOR THE CREATION AND USE OF VISUALLY-DIVERSE HIGH-QUALITY DYNAMIC LAYOUTS」という名称の米国特許の明細書である特許文献４においてページアナライザ４４に関して記載されている如く、入来ウェブページを前処理及び分析して、データ構造とそれらの相互間の関係とを特定してもよい。このようにして、ページアナライザ２６０は、セマンティックコンポジット、リピータコンポーネント、及び、一般的なコンポーネント階層を識別してもよいことが理解されるであろう。

ＷＢＳエディタ２３０は、被パラメータ化挙動要素の処理の仕方と、特殊な編集挙動を提供する拡張コンポーネントについての能力と、を認識している通常のウェブサイト構築システムのビジュアルエディタであってもよい。ＷＢＳエディタ２３０は、編集中のページのデータ構造についても十分に認識していてもよい。ＷＢＳエディタ２３０は、ベンダスタッフ２６１及び／又はデザイナ２６２が、本明細書において以下により詳細に説明する如く、ウェブサイトページをインタラクティブに編集／作成できるようにしてもよい。次に、図８を参照すると、これにはＷＢＳエディタ２３０の要素が例示されている。ＷＢＳエディタ２３０は、コンポーネントセレクタ２３１、編集挙動アプライヤ２３２、及び、コンポーネント／コンテナエディタ２３３を備えていてもよい。

ＷＢＳエディタ２３０には、ビジュアル（視覚的）編集ステージと、１組のコンポーネント選択パネルと、各々のコンポーネント又はコンテナについて複数の（レイアウト関連又は非レイアウト関連の）プロパティを含むビジュアルプロパティエディタと、が含まれていてもよい。これらのビジュアルプロパティエディタは、プロパティシートプレゼンタを通じて表示されてもよい。ＷＢＳエディタ２３０は、（（ＣＭＳ２５０から）ウェブサイト構築システムのベンダによって、及び、サードパーティのコンポーネントプロバイダによって提供される）１組の利用可能なコンポーネントにアクセスして、ページ編集環境において、これらのコンポーネントから得られる情報を使用してもよい。

そのような使用の１つは、コンポーネントのメタデータ１７（例えば、コンポーネントの名称、記述、タイプ及びオリジン（origin）など）と、ＳＢＬ情報と、ページに含めるコンポーネントの選択を可能にするインタフェースを作成するＳＢＬインタフェース定義との使用である。コンポーネントセレクタ２３１は、更に、選択されたコンポーネントのＳＢＬ要素の各々についてインタフェースを構築してもよく、例えば、ページの１組のコンポーネント又はそれの選択済みサブセットに関係するスタイルを表示するスタイル選択ＵＩを提供してもよいことが理解されるであろう。

そのような使用の別の１つは、コンポーネントが、それらの対応するカスタマイズ／構成／プロパティ編集ＵＩを提供することであり、これは、ＷＢＳエディタ２３０に含まれており、ウェブサイトデザイナ２６２が特定のコンポーネントインスタンスをカスタマイズできるようにしてもよい。これは、幾つかの態様で実施できる。

コンポーネントは、完全な構成ＵＩ（ユーザインタフェース）を提供してもよく、即ち、コンポーネント定義は、コンポーネントを構成するためにＷＢＳエディタ２３０において使用される構成ＵＩを含んでいてもよい。これは、完全なＵＩコード（例えば、個別のｉＦｒａｍｅを使用して表示可能なＵＩ）であってもよく、あるいは、実際の構成ＵＩを生成して呈示するＷＢＳエディタ２３０に提供される１組のパラメータであってもよい。

そのような構成ＵＩは、コンポーネントのアスペクト及び属性をインプレース（in-place）で編集するために使用される代替コンポーネントバージョンの形態を取り、コンポーネントによって占められる同じ場所において編集機能及びＵＩを提供してもよい。また、コンポーネントは、コンポーネントの相異なるアスペクト又は属性を編集するために使用される複数のそのようなバージョンを提供してもよい。

コンポーネントは、１組のカスタマイズプロパティと（カスタマイズレコードとして知られている）関連情報とを提供してもよいことが理解されるであろう。次に、ＷＢＳエディタ２３０は、これらのカスタマイズレコードを収集し、必要に応じて複数のコンポーネントから得られるレコードを統合し、カスタマイズＵＩを生成することによって、カスタマイズダイアログを作成してもよい。このような機能は、参照により本明細書に組み込まれており、本発明の共通譲受人に譲渡されている２０１７年９月５日に発行された「SYSTEM AND METHOD FOR DIALOG CUSTOMIZATION」という名称の米国特許の明細書である特許文献５に更に詳しく説明されている。オーバーライドの被パラメータ化挙動要素が、これらのカスタマイズレコードをオーバーライドして、代替カスタマイズインタフェースを提供してもよいことが理解されるであろう。

コンポーネントには、ＷＢＳエディタ２３０にとって有用であり得る追加の非構成情報が含まれていてもよいことも理解されるであろう。そのような情報は、コンポーネントの内部に在ってもよく、コンポーネントのコンテンツに影響を与え得る、あるいは、（例えば、本明細書においてスマートコンテナに関連して以下により詳細に説明する）コンポーネント内に配置された影響を受けるコンポーネントに影響を与え得る。また、この情報は、コンポーネントの外部に在ってもよく、ＷＢＳエディタ２３０と収容しているコンポーネントとが所定のコンポーネントとインタラクトする態様（例えば、如何にしてコンポーネントをドラッグ又はサイズ変更し得るかについての特定のガイドライン）に影響を与え得る。

別の一例として、コンポーネントは、代替のコンポーネントバージョン又は構成を提供してもよい。一例は、コンポーネントの単純化された又は重みの軽いバージョンを提供することであり、このシナリオにおいては、システム２００は、（コンポーネントが静的な場合のコンポーネント表示とは対照的に）コンポーネントをドラッグ又はズームしながら（部分的に）「ライブ」のコンポーネントを表示してもよい。例えば、ビデオプレーヤコンポーネントは、コンポーネントをドラッグしながら及びサイズ変更しながら、使用すべき代替の重みの軽いバージョンを提供してもよい。そのようなバージョンでは、ドラッグ及びサイズ変更中の表示をより簡単にするために、（例えば）より低いレゾリューション、より低いフレームレート、あるいは、小さなビデオセクションの繰り返し表示を使用してもよい。

コンポーネントは、また、コンポーネントのレイアウトと編成とに関連する情報も提供してもよい。そのような情報には、（例えば）最小又は最大コンポーネントサイズ、許容レイアウト被パラメータ化挙動要素のホワイトリストなどが含まれていてもよい。

コンポーネント定義には、（参照により本明細書に組み込まれており、本発明の共通譲受人に譲渡され、２０１３年８月２２日に公開された「WEB SITE DESIGN SYSTEM INTEGRATING DYNAMIC LAYOUT AND DYNAMIC CONTENT」という名称の特許文献６に記載されているように）このコンポーネントが関与する動的レイアウトプロセスを指揮する特定のヒントも含まれていてもよく、あるいは、（参照により本明細書に組み込まれており、本発明の共通譲受人に譲渡され、２０１３年９月５日に公開された「METHOD AND SYSTEM FOR THE USE OF ADJUSTMENT HANDLES TO FACILITATE DYNAMIC LAYOUT EDITING」という名称の特許文献７に記載されているように）コンポーネントが編集される際に任意の動的レイアウト挙動と動的レイアウトルールの動作とに影響を与える所定のコンポーネントについての特別な編集ハンドルを作成するために使用される特定のガイドラインも含まれていてもよい。

本明細書において上述した如く、システム２００のプロセスには相異なる段階がある。コンポーネント定義ステージにおいて、ＷＢＳベンダスタッフ２６１（及び、多くの場合、デザイナ２６２）は、コンポーネント／コンテナエディタ２３３を使用して、どの被パラメータ化挙動要素タイプをオーバーライドしてもよいかと、どの条件下かと、を規定することを含めて、一部の標準的な被パラメータ化挙動要素を定義及び作成してもよい。コンポーネントを定義する人（ベンダ２６１／デザイナ２６２）は、関連する条件下で、（収容されているコンポーネント内でオーバーライドしたい被パラメータ化挙動要素を含む）コンテナコンポーネントと、場合によっては、特定のパラメータ値と、を定義してもよいことが理解されるであろう。

サイトデザイナ２６２は、これらのコンポーネント及びコンテナを使用して、ページ定義段階において自分のウェブサイトを設計してもよい。サイトデザイナは、また、任意の事前規定済みオーバーライドを修正してもよく、あるいは、場合によっては、編集挙動アプライヤ２３２を使用して自分自身のパラメータを規定してもよい。システム２００は、サイトデザイナが、コンテナ内のコンポーネントについて自分自身のオーバーライド要求を規定することなどを追加的にできるようにしてもよく、あるいは、コンポーネントとコンテナとの全ての部分を完全に編集できるようにしてもよいことが理解されるであろう。

編集挙動アプライヤ２３２は、マウス、キーボード又はその両方（及びその他の任意のユーザインタフェース入力手段）を使用して、通常、影響を受ける種々のオブジェクト編集操作を適用してもよいことが理解されるであろう。これらには、特許文献２に記載されている如く、選択、ドラッグ、ドロップ、サイズ変更、コピー、貼り付けなどが含まれていてもよい。

サイトデザイナ２６２は、ＷＹＳＩＷＹＧ（what you see is what you get：「あなたが見るものは、あなたが得るものである」）を使用して、作業してもよいことが理解されるであろう。従って、編集中にページをインタラクティブに解決して表示してもよい。しかしながら、関連するウェブサイトページも、ランタイムにおいて、ＣＭＳ２５０内のデータベース（基礎となるデータベース）への変更によって、あるいは、（これらのデータベースの変更を反映する、例えば、追加又は削除されたレコードを示す）リピータコンテナを介して表示される外部ソース内のデータベースへの変更によって、修正されてもよい。

本明細書において上述した如く、コンポーネントは、ＳＢＬ要素の任意のもの、例えば上述の被パラメータ化挙動要素などの任意のもの、を規定、追加又は修正できるパラメータを受け入れてもよい。更に、被パラメータ化挙動要素は、例えば「全ての収容されているコンポーネントを、Ｘ％だけ色を弱めるカラーモディファイヤ（color modifier）で、修正する」などの自己自身のパラメータを受け入れてもよい。

被拡張要素ハンドラ２１０は、被パラメータ化挙動要素に関する全ての機能を処理してもよい。例えば、サイトデザイナ２６２は、（ランタイムにおいて）コンポーネントセレクタ２３１を使用して（ユーザ選択コンポーネントとしても知られる）コンポーネントを選択して、編集挙動アプライヤ２３２を使用して必要な挙動を適用してもよい。この編集挙動アプライヤ２３２による適用は、選択されたコンポーネントの被パラメータ化挙動要素の１つ又は多数のパラメータを変更し得ることが理解されるであろう。

要素ハンドラ２１０は、（ページがロード又はリフレッシュされ得る前に）ＷＢＳランタイムサーバ２２０によって、あるいは、編集セッション中に現在のコンポーネントに編集変更が行われる際にＷＢＳエディタ２３０によって、トリガされ得る（それによって、完全な又は部分的なリフレッシュを生じさせる、あるいは、オーバーライド要求を直接生じさせる）ことが理解されるであろう。

リクエストレシーバ２１１は、（ページのロード／リフレッシュ／レンダリング中に、外部ソース２７０／ＣＭＳ２５０からの変更の結果として、ユーザ編集要求から又は自動システム要求から）オーバーライド要求を受信してもよい。リゾルバ２１２は、（要求コンポーネントによって規定された条件と選択ルールとに基づいて）関連収容レベル内でどのコンポーネントが影響を受けるかと、ページアナライザ２６０の結果と、を識別してもよく、データハンドラ１６から（各々のコンポーネントから）どの被パラメータ化挙動要素がオーバーライド可能であるかを受信してもよい。本明細書において上述した如く、ページアナライザ２６０は、完全なコンポーネント階層を特定してもよい。これには、オーバーライドの対象となる要素を有しており、且つ、階層の一部分であり得る（本明細書において上述した）セマンティックコンポジットの検出が含まれ得る。従って、完全な階層は、事前定義されたコンテナと、（データソースに基づいて定義された）リピータコンテナと、（ページ分析に基づいて定義された）セマンティックコンポジットと、に基づいていてもよい。

ネゴシエータ２１３は、リゾルバ２１２の出力に基づいて識別されたコンポーネントの各々について、ネゴシエーションプロトコルに基づいて、通信要求を満たし（変数及び決定ロジックを使用するなどの手続き型ネゴシエーションを含む）、選択されたコンポーネントの関係する被パラメータ化挙動要素と通信して、収容されているコンポーネントのオーバーライドを特定してもよい。このプロトコルは、（例えば）コンポーネントＡから得られるパラメータＸをコンポーネントＢ１に適用できるか否かを判定するために、２つのコンポーネントＡとＢ１との間の一通信形態と見なしてもよい。

レゾルバ２１２は、また、競合レゾリューション（conflict resolution）も処理してもよい。例えば、フォーマットを処理する被収容コンポーネントは、自己に提示されたデータに基づいて、自己のコンテナの要素をオーバーライドしてもよい。一方、そのコンテナは、その被収容コンポーネントの要素をオーバーライドしようとしている場合がある。従って、ループ又は競合が生じることがあり、これは、リゾルバ２１２によって（どのオーバーライド要求を無視するかを決定して、それによって、ループをブレークすることを通じて）解決され得る。

本明細書において上述した如く、被パラメータ化挙動要素は、オーバーライド可能として事前定義されているものもあれば、そのように事前定義されていないものもあり得る。プロトコルに従ってオーバーライドが許可され得る場合には、リゾルバ２１２は、そのオーバーライドを実施してもよい。

従って、コンポーネントの変更が結果的に階層の境界を越えるかもしれないが、レゾルバ２１２は、おおむねコンテナの階層に沿って流れるルールに基づいて、コンポーネントの変更を適用してもよい。リゾルバ２１２は、通常、ウェブサイト構築システムのデータベース構造をＨＴＭＬに変換している間に（そうでなければ、それを表示用に準備している間に）実施される完全なラン（run）の一部分であるが、トリガによって再ラン（re-run）してもよいことが理解されるであろう。これは、スタンドアロン段階であってもよいし、あるいは、完全な変換段階に統合されていてもよい。

この分析及び特定されたコンポーネント階層に基づいて、リゾルバ２１２は、ページ階層を横断して、様々なオーバーライドコンポーネントによって為された全てのオーバーライド要求を特定してもよい。オーバーライド要求には、被パラメータ化挙動要素の適用が含まれていてもよいが、被パラメータ化挙動要素を含まない単純な属性オーバーライド（「色を緑に設定する」）であってもよい。

リゾルバ２１２は、全てのオーバーライド要求と、あらゆる対応コンポーネント、即ち、それらのオーバーライド要求が適用されるべきコンポーネントと、のリストを特定してもよいことが理解されるであろう。また、リゾルバ２１２は、対応コンポーネント自身のホワイトリスト／ブラックリストによって、あるいは、オーバーライド要求を規定するその他の対応コンポーネント固有ルールによって、特定される、各対応コンポーネントに適用可能なそれぞれのオーバーライド要求に対する各対応コンポーネントの応答を受信してもよい。次に、図９を参照すると、これには、コンポーネントの階層内で生じ得るオーバーライドのフロー例が例示されている。例えば、コンポーネント（ｃｏｍｐ１）は、ｃｏｍｐ１と同じコンテナ内の、あるいは、その中に収容されている一連のコンポーネントの関連する被パラメータ化挙動要素（例えば、リピータ１を除く、コンポーネント２と３及びセマンティックコンポジット１など）をオーバーライドしてもよい。また、コンポーネント（ｃｏｍｐ１）は、ｃｏｍｐ４を、これは異なる収容レベル（即ち、ｃｏｍｐ３内に）在るが、オーバーライドしてもよい。

また、リゾルバ２１２は、オーバーライド要求が適用されるべき順序を決定してもよい。これは、ユーザ規定の順序（例えば、複数のオーバーライド要求を提供し、それらの順序又は優先度を規定するオーバーライドコンポーネント）に基づく、あるいは、（ＣＳＳルールが適用される順序を規定する特定性ルールに類似する）システムルールに基づくことができる。

次に、リゾルバ２１２は、決定された順序に従って、オーバーライド要求を、全ての対応コンポーネントに適用してもよい。オーバーライド要求を特定の対応コンポーネントに適用することは、（条件評価が相異なる結果を生じさせるので）影響を受けるコンポーネントが他のコンポーネントとインタラクトする態様に影響を与える場合があることが理解されるであろう。例えば、コンポーネントＡがコンポーネントＢに影響を与える場合、このコンポーネントＢに対する変更に起因して、コンポーネントＢがコンポーネントＣに影響を与える状況、あるいは、コンポーネントＤから影響を受ける状況が相異なる態様で解決されることになり得る。これは、例えば、コンポーネントＢに対する一部の又は全ての変更によって、コンポーネントＢによる他のコンポーネントのオーバーライドが更に開始されることになり得る、コンポーネントＢについての（オーバーライドデータハンドラ１６の一部分としての）、特別なルールのためであり得る。このようなオーバーライドのルールは、コンポーネント間で「連鎖反応」の現象を引き起こすことがあり、また、「オーバーライドサークル（overriding circle）」も引き起こすことがあり、これは、リゾルバ２１２によって検出されて解決され得ることが理解されるであろう。

一拡張実施形態において、オーバーライドコンポーネントと対応コンポーネントの両方が、互いに、インタラクトし、ネゴシエートして、オーバーライドが生じるべきか否かを判定できるコードスニペットを提供してもよい。これらのスニペットは、通常のプログラミング言語（例えば、JａｖａＳｃｒｉｐｔなど）又はそのようなネゴシエーションに適合した制限されたスクリプト言語を使用して作成できる。どちらにしても、ネゴシエータ２１３は、サンドボックス又は他の閉鎖実行環境において、そのようなコードスニペットを実行してもよい。

一般的に、（解決及びネゴシエーションを含む）被パラメータ化挙動要素のオーバーライドは、通常、ページのレンダリングステージ中に、即ち、ページが編集又はリフレッシュされる時に（編集時に及びランタイムにおいて）生じることが理解されるであろう。
被拡張要素ハンドラ２１０は、ウェブサイト構築システムＣＭＳ２５０の定義を処理してユーザへの出力を生成するシステム２００の一部分と統合されてもよいことが理解されるであろう。これは、（例えば、専用のクライアントアプリケーションを使用する）画面への物理的なレンダリングであってもよく、あるいは、サイトのＨＴＭＬバージョンの作成であってもよい。最終的なレゾリューションとレンダリングは、（編集目的用）ＷＢＳエディタ２３０とランタイムサーバ２２０とによって、あるいは、ユーザのブラウザによって、あるいは、それらの組み合わせによって、実施されてもよいことが理解されるであろう。

別の一実施形態において、ブラウザは、（場合によっては、ユーザインタラクションを含む）トリガの発生によって、ウェブサイト構築システムからＨＴＭＬへのプロセスを再アクティブ化して、レンダリングされるページの一部又は全体を再作成してもよい。これは、また、様々なトリガに基づいて動作するページ内の操作コード（ＪＳ）に基づいて実施されてもよい。

トリガには、動的レイアウトトリガ（データ変更、別のユーザからのサイト編集、サーバ通知）及びページ自体の操作トリガ（ユーザインタラクション、ＪＳ操作）として説明されるような様々なイベントが含まれ得る。

ネゴシエータ２１３を介するネゴシエーションプロトコルは、（例えば、相異なるｉＦｒａｍｅ、相異なるブラウザウィンドウ、サーバレンダリングされるサードパーティアプリケーション用の相異なるマシンのように）レンダリング境界を越えて実施されてもよいことが理解されるであろう。

また、コンポーネントに対する更新は、動的ページレゾリューションの一部分であるので、即ち、プレビューステージ（編集中）又はランタイムにおいて実施されるので、ＣＭＳ２５０内に保存されないことも理解されるであろう。更に、レゾリューションは、ランタイムにおいて／プレビュー時に実施される必要があり、その理由は、コンポーネント自体が（例えば）動的レイアウトトリガ及びコンポーネントロジックによりランタイム中に更に変化し得るためであることも理解されるであろう。更に、このような変化は、ジオメトリ／コンテンツ分析の結果を変えるなど、オーバーライドプロセスに更に影響を与え得ることも理解されるであろう。例えば、コンポーネントＡが（被パラメータ化挙動要素を介して）コンポーネントＢの属性Ｘを変更する（これによって、属性Ｘの値が更新されて、コンポーネントＢのバージョン２が作成される）場合、コンポーネントＢは、属性Ｘの新しい値ではＣＭＳ２５０に保存されず、その理由は、この変更が、次の使用時のコンポーネントＢに影響を与え得るからである。（例えば）次回コンポーネントＢが使用される場合、コンポーネントＡはコンポーネントＢをオーバーライドしない可能性があり、属性Ｘの元の値は失われる。１つの例外は、迅速なレンダリングのための、属性Ｘの新しい値を有するコンポーネントＢを備えたページのキャッシュバージョンの保存であってもよい。

本明細書において上述した如く、親コンポーネント又はページは、呼び出しラインパラメータによって、あるいは、特定のプロパティを設定するルールを含む関連スタイルシートによって、親コンポーネント内に収容されている事前定義済みコンポーネントのプロパティを設定（又は規定）してもよい。そのような規定には、一部のオーバーライドも含まれていてもよい。例えば、コンポーネントは事前定義済みデフォルト色を有していることがあり、この規定は、デフォルト色をオーバーライドしてもよい。これは、システム固有の属性にも適用されてもよい。例えば、コンポーネントはデフォルト又は組み込みのレイアウトの被パラメータ化挙動要素を備えていてもよく、呼び出しコンポーネントが代替レイアウトの被パラメータ化挙動要素を規定してもよい。

また、コンポーネントは、例えば、下記の如く、自己の親によって自己に提供される被管理コンポーネントの属性を明示的にオーバーライドしてもよい。

上記の例において、ギャラリコンポーネント（gallery1）は、コンテナコンポーネントであり、３つの子（grid1、image1、image2）を被管理コンポーネントとして受信する。div2内では、ギャラリコンポーネントは、受信子コンポーネントについてＣＳＳ‘color’ 属性をオーバーライドして、それを緑（green）に設定する。これは、grid1の子（これは、多分、背景色を有している）に関係するであろうが、imageの子（即ち、image1、image2、これらは背景色の定義を全く有していないであろう）には関係ないであろう。このようなオーバーライドは、事前定義済みボタンコンポーネントnav1及びnav2には適用されないことが理解されるであろう。

本明細書において上述した如く、要素ハンドラ２１０は、被パラメータ化挙動要素タイプ（例えば、レイアウトなど）を被管理要素（被収容コンポーネント）に適用してもよい。これは、例えば、コンポーネントの定義時に「child.toVdom({--display: Carousel})」のような呼び出し（call）を行うことによって実施されてもよい。上記の例において、このようなオーバーライドは、グリッドコンポーネント被管理要素（grid1）に関係するであろうが、イメージコンポーネント被管理要素には関係しないであろうことが理解されるであろう。

別の一例では、「child.toVdom({display: ‘block’})」のようなフォーマットを使用して、特定のレイアウトの被パラメータ化挙動要素パラメータ（即ち、イメージ表示方法）を、これが関係する場合、オーバーライドしてもよい。

Ｅ-ＨＴＭＬ／ＣＳＳページ仕様に基づくシステムにおいて、このようなオーバーライドは、また、例えば下記の如く、インラインクラスリファレンス又はクラス追加機能を通じて参照できる特定のスタイルを通じて、実現してもよい。

本明細書において上述した如く、ＷＢＳベンダ２６１／ウェブサイトデザイナ２６２は、ＷＢＳエディタ２３０を使用して、自己が事前定義した要素（即ち、サブコンポーネント）、自己が管理する要素（即ち、被収容子）、あるいは、それらの両方、の特定の属性を設定又はオーバーライドするコンポーネントの機能に制限を設定してもよい。その代表的な実施形態は、プロパティの設定又はオーバーライドを外側のレイアウト及びスタイルのプロパティに限定してもよく、（特に要素のコンテンツを含む）他の要素のプロパティの設定、オーバーライド又は修正を不許可にしてもよい。

本明細書において上述した如く、システム２００の機能には、被管理要素（即ち、コンテナ内のコンポーネント）の特別な処理が含まれていてもよい。

例えば、コンテナコンポーネントＸに包含／表示用の被管理要素のリスト（Ａ１．．Ａｎ）が渡されると、コンテナコンポーネントＸは、（例えば）Ｘのタイプ、特定のＸのインスタンスのパラメータ、あるいは、それらの被管理要素のパラメータ及び属性に基づいて、それらの被管理要素を表示する前に、いくつかの態様で、それらの被管理要素を変換してもよい。そのような変換には、表示の順序の変更と、特定の場所又は位置の設定とが含まれていてもよく、例えば、要素を垂直に配置して、あらゆる奇数番目のアイテムを右に、あらゆる偶数番目のアイテムを左に位置揃えて表示してもよい（これは、ジグザグ表示としても知られている）。これは、被管理要素の属性、コンテンツ又は構造に基づいていてもよく、例えば、被管理要素を、それらの明るさが所定値よりも高いか又は低いかに基づいて、上から右側又は左側に位置揃してもよい。

その他の変換には、被管理要素の属性を変更（オーバーライド）すること、例えば、それらの色及び境界線設定などをオーバーライドすることと、要素を省略すること、例えば、提供された被管理要素のサブセットのみを表示する、あるいは、完全で遥かにより大きなリストの特定の１０要素「ウィンドウ」のみを示すことと、要素を拡張すること、例えば、それら自体が特定の又は追加の被管理要素を備えたコンテナである被管理要素を提供することと、要素を複製する又は繰り返すこと、例えば、被管理要素を２回表示する、場合によっては、特定の被管理要素の相異なる複製を区別するために、それらの表示される被管理要素内の一部の属性をオーバーライドすることと、が含まれていてもよい。これは、例えば、選択用に複数のバリアントを表示するために、使用できる。

システム２００のＥ－ＨＴＭＬ／ＣＳＳベースの実施形態は、拡張可能スタイルシートの定義も可能にし、これによって、コンポーネントの要素をコンポーネントの外部から修正できる経路又はＡＰＩが提供され得ることが理解されるであろう。これは、例えば、被パラメータ化挙動要素又は通常の属性のオーバーライドに使用でき、（上乗せ分の被パラメータ化挙動要素をコンポーネントに追加することによって）ＣＳＳに拡張することもできる。

代表的な定義は、（例えば、ギャラリコンポーネントの定義内で使用される）次の形態を有している。

上記のレイアウトの被パラメータ化挙動要素タイプのＥ－ＣＳＳ定義及び使用によって、このコンポーネントのインスタンス（即ち、ギャラリ定義内のgrid1 ）に適用され得る１組の拡張可能及びオーバーライド可能なレイアウトプロパティを定義し得ること、更に、これにはgrid1のガター（gutter）、列及び色のプロパティの設定が含まれていることが理解されるであろう。

また、これは、上記の「レイアウトの被パラメータ化挙動要素タイプ」を、このギャラリコンポーネントを使用する外部コンポーネントからカスタマイズ又はオーバーライドできるカスタム擬似要素と、定義してもよい。

上記の「@extend」ステートメントは、このスタイルシートが親コンポーネントによって拡張又はオーバーライドされてもよいことをシステム２００に通知する。この「@extend」を収容するスタイルシート内に定義されたプロパティのリストは、オーバーライドされてもよいプロパティのホワイトリストとして機能する。更に、このスタイルシート自体は、その他のプロパティを追加することによって、拡張されてもよい。スタイルシート内において相異なる属性について規定される値（例えば、上記のgutter=3）は、親コンポーネントが特定の属性について値を規定しない場合には、デフォルト値として機能することが理解されるであろう。

一代替実施形態において、システム２００は、「@extend」ディレクティブ（directive）の代わりに、他のシステム固有のＣＳＳ属性に類似したディレクティブフォーマット（例えば、「-public： true」）を使用してもよい。

このシナリオにおいて、grid1の他のプロパティ、あるいは、grid2のプロパティは、「オープン（open）」ではなく、ギャラリコンポーネントの公開インタフェースの一部分でもない。本明細書において上述した如く、@extendベースのＡＰＩを通じたプロパティの潜在的な明示的なオーバーライドを除き、ギャラリコンポーネントの他のプロパティは、カスタムであろうと、あるいは、事前定義済みであろうと、コンポーネントの整合性を保持するために、収容するコンポーネントからは継承されない。

上記のワイルドカードプロパティ仕様の使用は、プレフィックスの「prop-gallery-*」で始まる全てのプロパティを表している。システム２００は、（色関連、背景関連などのプロパティグループに従うＣＳＳプロパティの仕様を含む）他のワイルドカード仕様もサポートしてもよい。仕様は、上記の‘color’ に対する参照の如く、通常のＣＳＳプロパティ（非拡張プロパティ）も表してもよいことが理解されるであろう。

本明細書において上述した如く、リゾルバ２１２は、「何がオーバーライドされ得るか」ではなく、「誰がオーバーライドできるか」（即ち、どの「親」コンポーネントが公開プロパティをオーバーライドしてもよいか）に従って、ホワイト／ブラックリスティングを更に実施してもよい。本明細書において上述した如く、この情報は、データハンドラ１６によって提供されてもよく、また、例えばコンポーネントのタイプ、名称、画面領域又は他の属性のような親コンポーネントの様々なパラメータ及びプロパティに（例えば、どのようなレイアウトの被パラメータ化挙動要素タイプを使用するかに）基づいていてもよい。このような仕様についてのシンタックス（syntax）は、例えば、次の通りであってもよい。

呼び出しに関しては、上述のギャラリコンポーネントを（オーナ（owner）として）含むコンポーネント又はページは、例えば、次の通りの公開プロパティをパラメータとして使用してもよい。

これは、上述の方法のうちの任意のものを使用して実施できる。呼び出しパラメータにおいて規定された列の数（４）は、５であるデフォルト値をオーバーライドする。このようなオーバーライド又は規定は、直接所有されるコンポーネント（例えば、上記の例におけるギャラリ）にのみ適用できる。オーバーライドは、共有ルートコンポーネントが関係する場合、間接的に所有されるコンポーネントに適用されてもよい。

本明細書において上述した如く、システム２００は、スマートコンテナをサポートしてもよく、即ち、コンテナ定義には、エディタインタラクションと、特別なハンドルと、編集及びランタイム挙動とが含まれていてもよい。

また、コンポーネント／コンテナエディタ２３３は、スマートコンテナの作成を可能にしてもよく、更に、スマートコンテナタイプに関連付けられ得る特定の編集ドライバ１５Ａとインタフェースを取ってもよい。

スマートコンテナは、自己が収容するコンポーネントを管理してもよく、レゾルバ２１２を介してそれらとインタラクトして、通常のコンテナには見られない１組の挙動を提供してもよいことが理解されるであろう。

特に、このコンテナは、コンポーネントタイプ又は他のパラメータに関する特定の制限又はルールを定義してもよい。例えば、アルバムコンテナは、イメージのコンポーネントのみ、あるいは、イメージ及びビデオのコンポーネントのみ、あるいは、所定サイズ未満のイメージのみ、を収容してもよく、また、特殊化されたコンテナは、それに収容された多様なコンポーネントを変換してもよく、例えば、全ての被収容ギャラリをスライダータイプのギャラリに変換してもよい。

このコンテナは、自己に収容されるコンポーネントのスタイルを規定してもよい。これは、例えば、それらのコンポーネントに適用できる１組の設定及び属性を介して実施してもよい。これらには、プレゼンテーション要素（例えば、色、ベベルなど）とＷＢＳエディタ２３０を作動させる機能要素（例えば、特定の操作を可能にする追加ハンドルなど）とが含まれていてもよい。

更に、このコンテナは、被収容コンポーネントタイプごとに異なる設定を定義してもよい（例えば、全ての被収容ギャラリを黄色に、全ての被収容テキストボックスを幅広に及び緑色になどしてもよい）ことが理解されるであろう。

このコンテナは、被収容コンポーネントがその中で配置される態様（例えば、ギャラリ、アコーディオン、ブックフォーマットなど）を決定してもよく、また、その中でサブコンポーネントレイアウトに特定の挙動を課してもよく、例えば、その中でドラッグとサイズ変更に影響を与えてもよい（例えば、グリッド又は特定の配置に対するスナップを要求してもよい）。このコンテナは、その中での動的レイアウトの処理も決定してもよく、これは、通常のコンテナに使用されるデフォルトの動的レイアウト処理方法とは異なっていてもよい。動的レイアウト処理は、本明細書において上述した如くの動的レイアウトのヒントに基づいていてもよいことが理解されるであろう。本明細書において上述した如くの機能は、エディタ挙動ドライバ１５Ａ及びランタイム挙動ドライバ１５Ｂを通じて定義されてもよいことが理解されるであろう。

上述の機能は、被収容コンポーネントタイプ、コンポーネントコンテンツ、コンポーネント有効期間（component age）、コンポーネント編集履歴、コンポーネント継承履歴、コンポーネントサイズ、コンポーネント形状、コンポーネントＺオーダ（component z-order）、アプリケーション内でのコンポーネント用途、コンポーネントフォーマット情報、コンポーネントのネイティブの読み取り順序、ページ相互間のコンポーネントの関連付け、ユーザ定義のヒント、及び、それらの任意の組み合わせ、に依存し得ることも理解されるであろう。これらのコンポーネント属性の一部は、参照により本明細書に組み込まれており、本発明の共通譲受人に譲渡され、２０１３年４月４日に公開された「Adaptive User Interface Creation in Multimedia Creative Design System」という名称の特許文献８に更に詳しく記載されている。

スマートコンテナは、また、ＷＢＳエディタ２３０とインタラクトして、ＷＢＳエディタ２３０にコンテナ固有のドライバ及びロジックを（エディタ挙動ドライバ１５Ａを介して）提供してもよい。そのようなドライバは、編集挙動のアスペクトを制御してもよい。そのようなアスペクトは、如何なるコンテナランタイム挙動とも別個のものであるが、最終的なコンテナ及びコンポーネントのプレゼンテーションに影響を与えてもよい。

そのようなアスペクトの１つは、編集中のエディタ内でのコンポーネントのドラッグ挙動である。実行可能な挙動にはＶＢｏｘ（垂直ボックス）挙動が含まれていてもよく、全てのドラッグが垂直線にスナップされる。コンポーネントは、この線上で、例えば、中央揃え又は左揃えに、自動整列されてもよい。そのようなアスペクトのもう１つは、ドラッグが、不連続になり、離散スライダ位置相互間を移動する場合のスライダ挙動であり、「見えない」位置にドラッグされたコンポーネントを適切に配置できるようにスライダがコンテンツをスライドさせる／スクロールするようにしてもよい。

そのようなアスペクトの更にもう１つは、ドラッグアンドドロップ挙動である。例えば、テキスト編集ボックスは、正確なドロップ位置を使用する代わりに、被ドロップコンポーネントが、このテキスト編集ボックス内に既にタイプされているテキストのフロー内に統合されるように、これらの被ドロップコンポーネントを適切な位置に配置するスマートコンテナとして実施されてもよい。

更に別の一例として、３Ｄコンテナタイプが、３Ｄ操作ハンドルと３Ｄ挙動とを被収容コンポーネントに追加してもよい。このコンテナは、関連するロジック及びＵＩ要素をＷＢＳエディタ２３０に提供して、そのような３Ｄ挙動をサポートしてもよい。ＷＢＳエディタ２３０は、新しいハンドルタイプと新しいハンドルとを追加し、被収容コンポーネントのサイズ変更及び移動を制御し、様々な編集アクションが実行される順序を制御してもよい。

このコンテナは、デザイナ２６２が、このコンテナの編集及びランタイム挙動を制御する一部のパラメータを定義できるようにしてもよく、場合によっては、一部の既存のコンポーネント属性をオーバーライドできるようにしてもよい。例えば、次に参照する図１０に例示されているように、ＶｂｏｘコンテナＡは、被収容コンポーネントＣ１～Ｃ４が整列する（垂直）線Ｌがコンテナの中心にあるデフォルトの挙動を定義していてもよい。このコンテナは、ユーザが、このパラメータをオーバーライドして、線Ｌについて絶対的な又はパーセントベースの（percentage-based）位置Ｒを規定することによって、垂直線Ｌについて別の位置を規定できるようにしてもよい。

上述の例とは別の一例として、ランタイム修正可能スマートコンテナが、その中に在るコンポーネントを（ランタイム挙動ドライバ１５Ｂによって規定されるように）ランタイム中に移動又はサイズ変更できるようにしてもよい。このようなスマートコンテナのＶｂｏｘバージョンは、移動された被収容コンポーネントを上述の如くコンテナ内の垂直線に整列させることを強化してもよい。

更に別の一例において、Ｖｂｏｘコンテナは、自己が収容するコンポーネントを垂直線に沿って配置する時に、ビジュアルエディタの「コンポーネントを適所に追加」機能を呼び出すコントロール（control）を、これらの子コンポーネント相互間に、置く。

更に別の一例において（次に、参照する図１１に示されているように）、スマートコンテナコンポーネントＡは、（例えば、この特別なコンテナをＸ×Ｙ個の等しい矩形に分割することによって）内部レイアウトを定義する機能を備えていてもよい。この特定の例では、Ａは４×５個の矩形に分割されている。

このスマートコンテナＡ内に配置されるコンポーネント（例えば、例示のイメージコンポーネントＢ）は、各縁端に在る複数のサイズ変更ハンドル、例えば上側縁端に在るハンドルｃ及びｄ（同様のハンドルペアがコンポーネントＢの４つの縁端の各々に在る）を「成長」させる。

スマートコンテナＡは、ハンドルｃを介するサイズ変更をＡの内部グリッドにスナップさせ、且つ、ハンドルｄを介するサイズ変更をＡの内部グリッドにはスナップしないようにさせる（ウェブサイト構築システムの視覚ステージ領域Ｅと共に機能する）追加コードを更に実施してもよい。このような様々な挙動とハンドルのタイプの追加例が、動的レイアウトのパラメータとルールに影響を与える挙動も含めて、特許文献７に詳しく記載されている。

ＷＢＳエディタ２３０は、実際のビジュアルハンドルの代わりに、「見えない（invisible）」ハンドル領域を実施してもよく、これらは、マウスがこれらとインタラクトする際に、特定の機能を提供することが理解されるであろう。ＷＢＳエディタ２３０は、ユーザがそのような目に見えないハンドルを使用している時を、例えばマウスポインタの形状を変更することによって、ユーザに知らせてもよい。

システム２００は、事前定義された位置に基づいてではなく、要素の配置の視覚的最適化に従って（例えば、コンポーネント配置ルールを使用して）、内部に要素を配置するコンテナをサポートしてもよい。

ドラッグの実施は、（例えば）ＷＢＳエディタ２３０とインタフェースを取るエディタ挙動ドライバ１５Ａと、コンテナＹによって提供されるスマートコンテナドライバと、に基づいていてもよい。例えば：
ＷＢＳエディタ２３０は、コンポーネントＸについてのマウスの移動を取得する。

ＷＢＳエディタ２３０は、コンポーネントＸを収容するコンテナＹのエディタ挙動ドライバ１５Ａにイベント記述（マウスの移動）を送ってもよい。

エディタ挙動ドライバ１５Ａは、マウス移動情報と既存のＸのレイアウト情報オブジェクトとを処理して、修正済みレイアウト情報オブジェクトを生成してもよい。

エディタ挙動ドライバ１５Ａは、ＷＢＳエディタ２３０とコンテナＹとを、この新しい情報で、更新する。

従って、エディタ挙動ドライバ１５Ａは、ＷＢＳエディタ２３０内で動作して、ユーザインタラクションをプロパティの更新に変換してもよい。これらのインタラクションには、ドラッグ、クリックなどが含まれていてもよい。これらは、より高いレベルのアクション（例えば「コンポーネントのドロップ」など）又はより低いレベルのアクション（各々のマウス位置更新の追跡）であってもよい。このドライバは、モノリシックであってもよく、あるいは、コンポーネント固有ドライバが汎用部分に組み込まれた汎用ドライバで構成されていてもよい。一部の実施形態において、エディタ挙動ドライバ１５ＡとＷＢＳエディタ２３０との間のインタラクションの一部はリゾルバ２１２を介して実施されてもよいことが理解されるであろう。例えば、新しいコンポーネントがコンテナに追加されてもよく、その新しいコンポーネントがそれ自身の被パラメータ化挙動要素のパラメータを送ってもよい。

その他の（非コンテナの）コンポーネントもエディタ挙動ドライバ１５Ａを備えていてもよいことが理解されるであろう。例えば、ラベルコンポーネントが、インプレース編集（in-place editing）の特定のバリアントをサポートするエディタ挙動ドライバ１５Ａを備えていてもよい。

別の一例として、画像表示コンポーネントが、表示イメージの編集中に関心領域ベースの処理を提供してもよい。そのようなスキームの下で、システム２００は、表示イメージ内の関心領域（例えば、イメージ内の所定のオブジェクトなど）を定義してもよい。このような定義は、ユーザ入力、他のファクタ（factor）のイメージコンテンツ分析に基づいていてもよい。関心領域が定義されると、システム２００は、イメージの関心領域の可視領域に焦点を合わせるために、イメージのサイズ変更の時（編集中）にイメージのポジショニング（positioning）とクロッピング（cropping）を修正してもよい。従って、ポジティング（positing）とクロッピングとの新しい組み合わせによって、新しいズームファクタについて関心領域に最適な焦点を合わせてもよい。

システム２００は、ＡＩ／機械学習器２１４を通じて、ＡＩ／機械学習ベースの修正を提供するコンテナに対して修正を推奨することか、あるいは、それらに収容されるコンポーネントについてのレイアウトの推奨か、を実施してもよいことも理解されるであろう。ＡＩ／機械学習器２１４の機能は、特許文献９に記載されているものと同様であってもよく、この特許文献９は、デザインの選択肢の推奨について記載しており、完全なレイアウトに加えてオーバーライド及びパラメータを推奨するＡＩベースの推奨について同じ原理を適用していることが理解されるであろう。

そのような推奨される修正には、レイアウトのみ（例えば、位置とサイズの選択など）、制限された属性セット（例えば、内部のサブコンテナに特定の背景イメージ／ビデオを提供するコンテナ、あるいは、単に色の選択などに影響を与えるコンテナなど）、挙動、あるいは、任意の特定の被収容コンポーネントのサブ要素が含まれていてもよい。

これは、（ページセクション、ページ及びページセットが「より高いコンテナレベル」である）単一のコンテナ内の被収容コンポーネントについて、あるいは、１組のコンテナ（例えば、相互間のカラーマッチングを提供するために一緒に処理される一定数の別個のページセクション）について、実施されてもよい。

本明細書において上述した如く、ＷＢＳベンダ２６１とデザイナ２６２は、コンポーネント／コンテナエディタ２３３を使用して、属性がどのように修正されてもよいかに関しての指示によって、コンポーネントを定義してもよい。

ＡＩ／機械学習器２１４は、何が良好なデザイン、カラーマッチングなどを構成するかに関して、ＷＢＳベンダ２６１／デザイナ２６２及び他のユーザについて収集されたこの情報（これには、ＣＭＳ２５０に保存された編集履歴、ＢＩ、他のウェブサイトなどが含まれている）を使用してもよい。ＡＩ／機械学習器２１４は、関係のあるユーザ及びサイトを、それらの属性（ビジネスタイプ、サブタイプ、地理的な所在、ユーザ体験、使用されるシステム機能など）に従って、分類してもよい。

ＡＩ／機械学習器２１４は、（編集履歴から得られる）大量の編集変更と被パラメータ化挙動要素のアプリケーションとが含まれていてもよい入力資料と、分析済みのサイト、ページ及びコンポーネントの人気及びランキングに関する情報と、を分析してもよい。この入力資料は、機械学習エンジン（例えば、ニューラルネットワークベースのエンジンなど）のトレーニングに使用されてもよく、この機械学習エンジンは、次に、修正の推奨を提供してもよい。この機械学習エンジンの現在の状態は、ＭＬ／ＡＩリポジトリ２５１０に保管されてもよい。

そのような推奨コンテナは、関係のあるプライバシー及び知的財産の法律（例えば、著作権法及び商標法など）、即ち、そのような情報の使用を規定し、他のユーザに属するデータのプライバシーが損なわれないことを保証する法律、の規制を受ける他の（通常の）コンテナと混在させてもよい。

特許文献２に記載されているように、ウェブサイトのコンポーネントの構造に対する変更は、検索エンジンのスパイダによるウェブサイトのインデックス付けに影響を与えることがあり、従って、検索エンジンの最適化に影響を与えることがある。システム２００は、参照により本明細書に組み込まれており、本発明の共通譲受人に譲渡されている２０１６年９月６日に発行された「SYSTEM FOR DEEP LINKING AND SEARCH ENGINE SUPPORT FOR WEB SITES INTEGRATING THIRD PARTY APPLICATION AND COMPONENTS」という名称の米国特許の明細書である特許文献１０に記載されている如く、インデックス付けされるべき更新済みコンテナ及びコンポーネントに関する情報を検索エンジンのスパイダに送信する検索エンジンにフレンドリなレンダラも備えていてもよいことが理解されるであろう。

従って、被パラメータ化挙動要素を使用して、オーバーライドプロトコルに基づいて、全ての収容レベル内のコンポーネントとコンテナとの視覚的及び動作的パラメータを自動的に変換してもよい。

特に別に明記しない限り、上述の記載から明らかなように、本明細書全体を通して、「処理」、「計算」、「算定」、「判定」などの用語を使用する記載は、例えばサーバ、クライアント、モバイルコンピューティングデバイス、スマートアプライヤンス又は同様の電子計算装置のような任意のタイプの汎用コンピュータ（即ち、コンピューティングシステムのレジスタ及び／又はメモリ内における例えば電子量のような物理量として表されるデータを操作し、及び／又は、このデータを、コンピューティングシステムのメモリ、レジスタ又は他のそのような情報記憶用、伝送用又は表示用装置内における物理量として同様に表される他のデータに、変換する汎用コンピュータ）のアクション及び／又はプロセスを意味している。

本発明の実施形態には、本明細書に記載されたオペレーションを実施する装置が含まれていてもよい。この装置は、所望の目的のために特別に構築されていてもよいし、汎用コンピュータ、あるいは、そのコンピュータに格納されたコンピュータプログラムによって選択的に起動又は再構成されるクライアント／サーバ構成を備えていてもよい。その結果として得られる装置は、ソフトウェアによって命令されると、その汎用コンピュータを本明細書に記載された発明の要素に変えてもよい。これらの命令は、必要な場合、コンピュータプラットフォームと共に動作する本発明のデバイスを規定してもよい。そのようなコンピュータプログラムは、コンピュータ可読記憶媒体、例えば、限定はしないが、光ディスクと光磁気ディスクとを含む任意のタイプのディスク、読み取り専用メモリ（ＲＯＭ）、揮発性及び不揮発性メモリ、ランダムアクセスメモリ（ＲＡＭ）、電気的にプログラム可能な読み取り専用メモリ（ＥＰＲＯＭ）、電気的に消去可能及びプログラム可能な読み取り専用メモリ（ＥＥＰＲＯＭ）、磁気又は光カード、フラッシュメモリ、ディスクオンキー（disk-on-key）、あるいは、電子的命令の記憶に適しており、コンピュータシステムバスに結合可能なその他の任意のタイプの媒体、に記憶されてもよい。

本明細書に提示されたプロセス及び表示は、如何なる特定のコンピュータ又は他の装置にも本質的に関係するものではない。様々な汎用システムを、本明細書の教示に従うプログラムと共に、使用してもよく、あるいは、より専用の装置を構築してこの所望の方法を実施することが便利な場合もある。これらの様々なシステムについて望ましい構造は上述の説明から明らかになるであろう。更に、本発明の実施形態は、如何なる特定のプログラミング言語に関しても説明されていない。様々なプログラミング言語を使用して本明細書に記載された本発明の教示事項を実施してもよいことが理解されるであろう。

本明細書において本発明の特定の特徴を例示及び説明してきたが、多くの修正、置換、変更、及び、等価物が当業者に思い浮かぶであろう。従って、最後に記載された特許請求の範囲は、本発明の真の精神の範囲内に在るそのような全ての修正及び変更を網羅することを意図していることを理解されたい。

Claims (7)

1. ウェブサイトのための拡張ウェブサイトコンポーネントであって、
   前記拡張ウェブサイトコンポーネントのスタイル、ロジック及びボディを表す要素と、
   前記拡張ウェブサイトコンポーネント及びそれに含まれるコンポーネントがウェブサイト構築システム（ＷＢＳ）エディタによって処理される方法を制御するエディタ挙動ドライバと、
   前記拡張ウェブサイトコンポーネントがランタイム時にランタイムサーバによって処理される方法に影響を与えるランタイム挙動ドライバと、
   前記ＷＢＳエディタによる編集プレビュー中及びランタイム時に前記拡張ウェブサイトコンポーネントに対するレンダリング命令を提供するコンポーネントレンダリング機能と、
   所定のルール及びプロトコルレゾルーションに従って前記拡張ウェブサイトコンポーネントと第２の拡張ウェブサイトコンポーネントとの間のオーバライドリクエストを処理するオーバライドデータハンドラと、
   を有し、
   前記オーバライドリクエストは、前記第２の拡張ウェブサイトコンポーネントに関するスタイル、挙動及び動作変更の少なくとも１つを実現するためのものである、拡張ウェブサイトコンポーネント。
2. 前記拡張ウェブサイトコンポーネントと前記第２の拡張ウェブサイトコンポーネントとの間のオーバライド競合を解決する変数及び決定ロジックを利用するネゴシエーションプロトコルを更に含む、請求項１に記載の拡張ウェブサイトコンポーネント。
3. 前記拡張ウェブサイトコンポーネントは、所定のリピータ及びセマンティックコンポジットの少なくとも１つである、請求項１に記載の拡張ウェブサイトコンポーネント。
4. オーバライド不可である前記拡張ウェブサイトコンポーネントの要素を含む固定領域を更に含む、請求項１に記載の拡張ウェブサイトコンポーネント。
5. 前記拡張ウェブサイトコンポーネントに関するメタデータを更に含み、
   前記メタデータは、前記拡張ウェブサイトコンポーネントの作成者情報、内部参照ＩＤ、コンポーネント名、記述、タイプ及びオリジンの少なくとも１つである、請求項１に記載の拡張ウェブサイトコンポーネント。
6. 前記要素は、前記拡張ウェブサイトコンポーネントの動作的及び視覚的挙動を規定する、請求項１に記載の拡張ウェブサイトコンポーネント。
7. 前記決定ロジックは、前記拡張ウェブサイトコンポーネントと前記第２の拡張ウェブサイトコンポーネントとの間の決定されたコンポーネント関係に従う、請求項２に記載の拡張ウェブサイトコンポーネント。
   

Images