JP2023164829A - リビング文書の生成および対話型編集のためのシステムおよび方法 - Google Patents

Abstract

【課題】テキストコンテンツを生成するウェブサイト構築システムを提供する。【解決手段】システム２００において、ウェブサイト構築システム（ＷＢＳ）５は、少なくとも１つのプロセッサと、少なくとも１つのプロセッサに実装されたテキストコンテンツジェネレータ（ＴＣＧ）８０’およびリビング文書ジェネレータ（ＬＤＧ）３００と、含む。テキストコンテンツジェネレータは、記憶装置に記憶された複数の文書セクションからリビング文書を生成し、ウェブサイトデザイナ６２またはエンドユーザの属性の関数として文書セクションを選択する。リビング文書ジェネレータは、リビング文書に関連する法的環境、ビジネス環境およびウェブサイト環境の少なくとも１つに変更が生じた場合、リビング文書を更新する。【選択図】図１４

Description

本出願は、両方とも参照により本明細書に組み込まれる、２０１９年５月３０日に出願された米国仮特許出願第６２／８５４，３２４号および第６２／８５４，３２９号からの優先権を主張する。

本発明は、一般にウェブサイト構築システムに関し、特にテキストコンテンツ生成に関する。

ウェブサイト構築システムは、インタラクティブウェブサイトを作成するために、初心者および専門家の両方によって使用される。既存のウェブサイト構築システムは、ビジュアル編集モデルに基づいており、ほとんどのウェブサイト構築システムは、通常、完全なサンプルウェブサイト、ウェブサイトセクション、シングルページまたはページのセクションを含むテンプレートを備えた複数のテンプレートを提供する。

ウェブサイト構築システムユーザ（デザイナ、加入者、加入ユーザまたはサイトエディタとも呼ばれる）は、ウェブサイトを設計する可能性があり、ウェブサイトのエンドユーザ（「ユーザのユーザ」）は、ユーザが作成したウェブサイトにアクセスする可能性がある。エンドユーザは、通常、読み取り専用モードでシステムにアクセスするが、ウェブサイト構築システム（およびウェブサイト）は、エンドユーザが、データ記録の追加または編集、ニュース記事へのトークバックの追加、ブログへのブログエントリの追加などのウェブサイトへの変更を実行することを可能にすることができる。ウェブサイト構築システムは、実際には、複数のレベルのユーザ（すなわち、２つ以上のレベル）を許可し、各レベルに異なる許可と能力を割り当てることができる。ウェブサイト構築システムのユーザ（特に、以下に述べる完全または部分的なオンライン構成）は、ユーザ、そのウェブサイト、およびエンドユーザによるアクセスを管理するウェブサイト構築システムサーバに登録することができる。

ウェブサイト構築システムは、スタンドアロンシステムであってもよいし、より大きな編集システム内に組み込まれていてもよい。また、オンライン（すなわち、アプリケーションは、編集され、サーバ上に記憶される）、オフラインまたは部分的にオンライン（ウェブサイトは、ローカルで編集されるが、公開のために中央サーバにアップロードされる）であってもよい。ウェブサイト構築システムは、ウェブサイト構築システムベースのサイトを格納するために内部データアーキテクチャを使用することができ、このアーキテクチャは、取り扱われるサイトの内部データおよびシステム内部の要素を編成することができる。このアーキテクチャは、サイトの外部ビューとは異なる場合がある（エンドユーザなどから見た場合）。また、通常は、ブラウザに送信されるＨＴＭＬページの編成方法とは異なる。

例えば、内部データアーキテクチャは、ウェブサイト構築システムにおけるサイトの編集及びメンテナンスに関連するが、エンドユーザ（又は一部の編集ユーザ）にさえも外部から見えない、ページ内の各要素（作成者、作成時間、アクセス許可、テンプレートへのリンク、ＳＥＯ（ｓｅａｒｃｈ ｅｎｇｉｎｅ ｏｐｔｉｍｉｚａｔｉｏｎ）関連情報など）のための追加プロパティを含むことができる。ウェブサイト構築システムは、その機能の一部（編集とランタイム機能の両方を含む）をサーバまたはサーバセット上に実装し、その機能の一部をクライアント要素上に実装することができる。ウェブサイト構築システムは、サーバ上で何らかの機能を実行するか、クライアントプラットフォーム上で実行するかを動的に決定することもできる。

ウェブサイト構築システムは、通常、ページ、コンテナ、およびコンポーネントからなる視覚的に設計されたアプリケーション（ウェブサイトなど）の作成および編集を処理する。ページは別々に表示され、コンポーネントが含まれている場合がある。コンポーネントは、アトミックコンポーネントだけでなくコンテナも含むことができる。

ウェブサイト構築システムは、アトミックコンポーネント（テキスト、画像、形状、ビデオなど）、ならびに他のコンポーネントを含む様々なタイプのコンテナコンポーネント（例えば、通常のコンテナ、シングルページコンテナ、マルチページコンテナ、ギャラリコンテナなど）を使用するコンポーネントの階層的配置をサポートすることができる。コンテナコンポーネント内に含まれるサブページは、ミニページと呼ばれ、その各々は、複数のコンポーネントを含むことができる。コンテナコンポーネントによっては、ミニページを一度に１つだけ表示するものもあれば、複数のミニページを同時に表示するものもある。

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

ページでは、テンプレート、一般的なページテンプレート、またはコンポーネントテンプレートを使用できる。テンプレートの具体的なケースとしては、他のすべての通常のページで複製されたコンポーネントを含むアプリケーションマスターページの使用、アプリケーションヘッダーまたはフッター（すべてのページで繰り返される）の使用などがある。テンプレートは、ページ全体またはページセクションに使用できる。ウェブサイト構築システムは、テンプレート、ページ、またはコンポーネント間の継承を提供することができ、多重レベル継承、多重継承、およびダイヤモンド継承（すなわち、ＡがＢおよびＣから継承し、ＢおよびＣの両方がＤから継承する）を含む可能性がある。

ページ内のコンポーネントの視覚的な配置は、レイアウトと呼ばれる。ウェブサイト構築システムはまた、２０１３年８月２２日に公開され、本発明の共通の譲受人に譲渡され、参照により本明細書に組み込まれる「Ｗｅｂｓｉｔｅ Ｄｅｓｉｇｎ Ｓｙｓｔｅｍ Ｉｎｔｅｇｒａｔｉｎｇ Ｄｙｎａｍｉｃ Ｌａｙｏｕｔ ａｎｄ Ｄｙｎａｍｉｃ Ｃｏｎｔｅｎｔ」という名称の米国特許出願公開第２０１３／０２１９２６３号にさらに記載されるように、動的レイアウト処理、すなわち、所与のコンポーネントの編集（または外部駆動コンテンツ変更など、それに影響を及ぼす他の変更）が他のコンポーネントに影響を及ぼすことができるプロセスをサポートすることができる。

ウェブサイト構築システムは、サードパーティアプリケーションおよびそのコンポーネントならびにリストアプリケーション（２０１４年９月１８日に公開され、本発明の共通の譲受人に譲渡され、参照により本明細書に組み込まれる、「Ｗｅｂｓｉｔｅ Ｂｕｉｌｄｉｎｇ Ｓｙｓｔｅｍ Ｉｎｔｅｇｒａｔｉｎｇ Ｄａｔａ Ｌｉｓｔｓ ｗｉｔｈ Ｄｙｎａｍｉｃ Ｃｕｓｔｏｍｉｚａｔｉｏｎ ａｎｄ Ａｄａｐｔａｔｉｏｎ」という名称の米国特許出願公開第２０１４／０２８２２１８号に記載されているものなど）を使用して拡張することができる。これらのサードパーティアプリケーションやリストアプリケーションは、設計されたウェブサイトに追加および統合することができる。

そのようなサードパーティアプリケーションおよびリストアプリケーションは、ウェブサイト構築システムの設計環境に事前に含まれること、アプリケーションストア（ウェブサイト構築システムに統合されるか、またはそれの外部にある）から、またはサードパーティアプリケーションのベンダから直接、など、いくつかの配布メカニズムを介して購入（または取得）され得る。

サードパーティアプリケーションは、ウェブサイト構築システムベンダの独自のサーバ、サードパーティアプリケーションベンダのサーバ、またはフォースパーティのサーバインフラストラクチャでホストされる場合がある。

ウェブサイト構築システムはまた、手続きコードをシステムのエンティティの一部又は全部に追加することを可能にしてもよい。このようなコードは、標準言語（ＪａｖａＳｃｒｉｐｔなど）、標準言語の拡張バージョン、または特定のウェブサイト構築システム専用の言語で記述することができる。実行されたコードは、ウェブサイト構築システム自体または外部プロバイダから提供されたＡＰＩを参照する場合がある。コードは、ページ、コンポーネント、およびそれらの属性など、ウェブサイト構築システムの内部構造およびオブジェクトを参照することもできる。

手続きコード要素は、ユーザアクティビティ（マウスの移動やクリック、ページ遷移など）、他のユーザに関連するアクティビティ（基盤となるデータベースや、他のユーザによって更新される特定のデータベースレコードなど）、システムイベント、または他のタイプの条件に関連付けることができるイベントトリガを介してアクティブ化することができる。

アクティブ化されたコードは、ウェブサイト構築システムのクライアント要素内、サーバプラットフォーム上、または、２つまたは動的に決定された実行プラットフォームの組み合わせを使用して実行することができる。このようなシステムは、米国特許出願公開第２０１８／０２９３３２３号、名称「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｓｍａｒｔ Ｉｎｔｅｒａｃｔｉｏｎ Ｂｅｔｗｅｅｎ Ｗｅｂｓｉｔｅ Ｃｏｍｐｏｎｅｎｔｓ」（２０１８年１０月１１日公開）に記載されており、本発明の共通の譲受人に譲渡され、参照により本明細書に組み込まれる。

典型的なサイト作成は、図１に示されるような視覚編集モデル（ユーザが以前に作成されたサイトを編集する）および自動サイト生成モデルまたはそれらの組み合わせを含む、いくつかのモデルに基づくことができ、２０１８年９月１１日に付与され、本発明の共通の譲受人に譲渡され、参照により本明細書に組み込まれる「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ ｔｈｅ Ｃｒｅａｔｉｏｎ ａｎｄ Ｕｐｄａｔｅ ｏｆ Ｈｉｅｒａｒｃｈｉｃａｌ Ｗｅｂｓｉｔｅｓ Ｂａｓｅｄ ｏｎ Ｃｏｌｌｅｃｔｅｄ Ｂｕｓｉｎｅｓｓ Ｋｎｏｗｌｅｄｇｅ」という名称の米国特許第１０，０７３，９２３号に記載されている。

図１は、ＷＢＳベンダスタッフ６１、サイトデザイナ６２（すなわち、ユーザ）、サイトユーザ６３（すなわち、ユーザのユーザ）、および外部システム７０によって操作されるクライアントシステムと通信する典型的なウェブサイト構築システム５を備えるシステム１００を示す。ウェブサイト構築システム５は、ＷＢＳ（ｗｅｂｓｉｔｅ ｂｕｉｌｄｉｎｇ ｓｙｓｔｅｍ：ウェブサイト構築システム）サイトマネージャ１０と、オブジェクトマーケットプレイス１５と、ＷＢＳ ＲＴ（Ｒｕｎｔｉｍｅ：ランタイム）サーバ２０と、ＷＢＳ（ウェブサイト構築システム）エディタ３０と、サイトジェネレーションシステム４０と、ＷＢＳコンテンツ管理システム（ＣＭＳ：ｃｏｎｔｅｎｔ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ）５０とをさらに備えることができる。図１の要素は、米国特許第１０，０７３，９２３号に記載されているように機能し得ることが理解され得る。

ビジュアル編集モデルでは、ユーザ（デザイナ）は１つ以上のウェブサイトテンプレートに基づいてサイトを編集する。ウェブサイト構築システムのプロバイダは、複数のサイト（または他の）テンプレートを提供することができ、各テンプレートは、完全なサンプルウェブサイト、ウェブサイトセクション、シングルページまたはページセクションを含む可能性がある。ユーザは、空のサイト（基本的には「空白ページ」テンプレート）から開始するオプションを持つことができるが、通常は実際のサイトテンプレートから開始する。

ウェブサイト構築システムのプロバイダは、非常に一般的なもの（例えば、モバイルサイト、ｅストア）から、より具体的なもの（例えば、法律事務所、レストラン、花屋）まで、非常に具体的なもの（例えば、商業用不動産法律事務所又はスペイン語タパスレストラン）までの範囲のサイトテンプレートを提供することができる。そのようなテンプレートは、典型的には、ウェブサイト構築システムのユーザがアクセス可能なリポジトリに格納され、典型的には、ビジネスタイプ、サブタイプ、または業界に従って分類される。テンプレートは、ビジネスタイプだけでなく、スタイル、色範囲、または他のパラメータに従って作成（および分類）することもできる。サイトテンプレートは、ウェブサイト構築システムと統合された本格的な垂直ソリューションになるために、追加の（典型的にはバックエンド）機能、サービス、およびコードで拡張することができる。

したがって、ウェブサイト構築システムのビジュアルエディタを使用してサイトを作成するときのユーザの最初の経験は、典型的には、ユーザがテンプレート（例えば、スタイルまたは業界タイプ／サブタイプに従って）を選択し、場合によっては空白のテンプレートを選択し、その後、コンテンツ、ロジック、レイアウト、属性の編集を含むビジュアルエディタでテンプレートを編集することである。そのような編集は、（特に）テンプレートおよびその要素をユーザのビジネスの詳細に適合させることを含むことができる。その後、ユーザは変更されたサイトを公開することができる。

サイト生成モデルの下で、ウェブサイト構築システムは、選択されたテンプレートに基づいて、ユーザのための初期サイトを生成し、このテンプレートは、場合によっては、情報の共通要素を穴埋めすることによって修正され、場合によっては、生成されたサイトのフォローアップ編集を可能にする。この穴埋めは、テンプレートのページ内の複数の場所に、さまざまな情報（ビジネス名や管理チームの説明など）が含まれているために必要である。したがって、ユーザは、テンプレート全体の複数の場所でビジネス名（たとえば）を変更しなければならない場合がある。

さらに、いくつかのテンプレート要素（例えば、一般的な製品ページ）が複数回現れてもよく、各インスタンスは、基盤となるエンティティ（例えば、サイトで提供される異なる製品）の異なるインスタンスの詳細を表示する。そのような複数のインスタンスは、手動で指定されてもよいし（例えば、会社の管理チームにおける異なる人物の詳細）、または外部データベース（例えば、「販売中の製品」データベースからの製品詳細）から動的に導出されてもよい。このような構成は、しばしば「リピータ」として知られている。

テンプレートにはフィールドを含めることもできる。例えば、ウェブサイト構築システムは、テンプレートデザイナが、｛ＣｏｍｐａｎｙＮａｍｅ｝、｛ＰｒｏｄｕｃｔＮａｍｅ｝、｛ＰｒｏｄｕｃｔＰｒｉｃｅ｝などのテンプレート内に値を挿入するためのフィールド（「プレイスホルダー」とも呼ばれる）を指定することを可能にしてもよい。ユーザは、ウェブサイト用に選択されたテンプレートで定義されたフィールドの値を指定することもできる。

ウェブサイト構築システムは、ユーザが、単純な値又は複雑な値（例えば、テキスト及び画像）だけでなく、含まれるページ又はウェブサイト領域の選択、色、スタイル情報、リンク、書式設定オプション、ウェブサイト表示オプション、装飾要素（ボーダー及び背景等）等の追加（非フィールド）情報も入力できるようにすることができる。

ウェブサイト構築システムは、テンプレートを選択する前に、ユーザがこの追加情報のいくつかを入力し、この情報をテンプレートの選択に役立てることもできる（例えば、提案されたテンプレートのセットを絞り込むことによって）。例えば、ユーザは、ある汎用カラースキーム（例えば、パステルカラー）またはスタイル（例えば、ビジネス／フォーマル）を選択することができ、次いで、システムは、この選択を使用して、提案されたテンプレートのセットを絞り込むことができる。

システムはまた、一連のビューまたはアンケートを表示して、ユーザが（定義されたフィールドおよび上記の追加情報の両方について）値または選択を入力できるようにしてもよい。システムは、さらに、テンプレートの複数インスタンス要素（本明細書で先に説明した）と、表示されたインスタンスを生成するために使用されるデータインスタンスを提供する内部または外部データベースとの間の接続（またはバインド）を作成することができる。

テンプレートが選択され、そのフィールドおよび追加情報が指定されると（例えば、アンケートを通じて、またはデータソースへのバインディングを通じて）、ウェブサイト構築システムは、組み合わされた情報を含むウェブサイトを生成することができる。次いで、ユーザは、（ウェブサイト構築システムまたは他の方法を介して）サイトを公開することができる。

ウェブサイト構築システムは、米国特許第１０，０７３，９２３号に記載されているように、異なるモデルを使用して半自動サイト作成を実行することができる。このモデルの下で、システムは、例えば、ユーザ記入アンケート、既存のユーザプレゼンス（既存のウェブサイトまたはソーシャルメディアプレゼンスなど）、業界ソース（一般取引ウェブサイトなど）、オフライン情報、および特定の業種（弁護士、レストラン、配管工、グラフィックデザイナなど）の基本テンプレート情報などの特定の業種に関する情報を提供する内部システムリポジトリ（例えば、不動産弁護士と人身傷害弁護士とを区別する）を含むことができる複数のソースから、ユーザおよびユーザのウェブサイト要件に関する情報を収集する。

システムはまた、システムの内部および外部の両方で、他のサイトから外部情報を収集してもよい。そのような情報は、例えば、提供されたアンケートおよびレイアウト要素の選択、提案されたデフォルトなどに影響を及ぼし得る。そのような情報はまた、典型的には、任意の単一のユーザに属する情報を公開せず、ユーザのプライバシー、匿名性、および法的権利（著作権など）を保護するために、統計的または概略的に収集されてもよい。そのような情報は、直接的（例えば、既存のウェブサイトアドレス）または間接的（ビジネスに関する情報を見つけるために使用され得るビジネス名および地理的アドレス）であり得る、ユーザによって提供される情報に基づいて見つけられ得る。

収集された情報は、分析され、コンテンツ要素のリポジトリに配置され、コンテンツ要素からコンテンツを提示するレイアウト要素にマッピングされ、レイアウト要素を組み合わせてサイトを形成する。レイアウト要素マッピング、選択、および組み合わせプロセスは、完全自動または半自動（すなわち、ユーザ対話を含む）とすることができる。

上記の機能をサポートするために、ウェブサイト構築システムは、典型的には、１つ以上のサーバまたはサーバファーム上に格納された一連のリポジトリを維持する。このようなリポジトリは、典型的には、ユーザ情報／プロファイルリポジトリ、ＷＢＳ（ウェブサイト構築システム）コンポーネントリポジトリ、ＷＢＳサイトリポジトリ、ビジネスインテリジェンス（ＢＩ：Ｂｕｓｉｎｅｓｓ Ｉｎｔｅｌｌｉｇｅｎｃｅ）リポジトリ、編集履歴リポジトリ、サードパーティアプリケーションストアリポジトリなどを含むことができる。システムはまた、アンケートタイプリポジトリ、コンテンツ要素タイプリポジトリ、レイアウト要素タイプリポジトリ、設計キットリポジトリ、記入済みアンケートリポジトリ、コンテンツ要素リポジトリ、レイアウト要素リポジトリ、ルールリポジトリ、ファミリー／業界リポジトリなどのサイト／コンテンツ作成関連リポジトリを含むことができる。

したがって、本発明の好ましい実施形態によれば、ウェブサイト構築システム（ＷＢＳ）は、少なくとも１つのプロセッサと、少なくとも１つのプロセッサに実装されたテキストコンテンツジェネレータおよびリビング文書ジェネレータとを含む。テキストコンテンツジェネレータは、記憶装置に記憶された複数の文書セクションからリビング文書を生成する。テキストコンテンツジェネレータは、ウェブサイトのデザイナまたはエンドユーザの属性の関数として文書セクションを選択する。リビング文書ジェネレータは、リビング文書に関連する法的環境、ビジネス環境およびウェブサイト環境の少なくとも１つに変更が生じた場合、リビング文書を更新する。

さらに、本発明の好ましい実施形態によれば、リビング文書ジェネレータは、モニタリングエンジン、ポリシー知識エンジン（ＰＫＥ：ｐｏｌｉｃｙ ｋｎｏｗｌｅｄｇｅ ｅｎｇｉｎｅ）および通知エンジンを含む。モニタリングエンジンは、リビング文書に影響する変更について、内部および外部のデータソースをモニターする。ＰＫＥは、リビング文書に対する、外部の法律および／または規制ソースデータの影響の分析後、リビング文書のセクションテキストのコンテンツに対する変更を推奨し、通知エンジンは、ＰＫＥにより推奨される変更を、デザイナおよびＷＢＳベンダスタッフの少なくとも１つに通知する。

さらに、本発明の好ましい実施形態によれば、テキストコンテンツジェネレータは、ＨＤＳエディタを有する。ＨＤＳエディタは、１つのセクションテキストにおける、１つの、推奨された、セクションテキストのオプションをデザイナが選択することを可能にし、かつ、セクションテキストおよびセクションテキストのオプションの、事前公開編集および事後公開編集を可能にする。

さらに、本発明の好ましい実施形態によれば、リビング文書ジェネレータは、リビング文書に関するＷＢＳ情報およびビジネスオペレーショナル情報を決定するために、ＷＢＳの内部データソースと、外部オンラインデータソースおよび外部オフラインデータソースの少なくとも１つとを分析する分析エンジンを有する。

さらに、本発明の好ましい実施形態によれば、ビジネス環境は、デザイナのビジネスオペレーションおよびアクティビティと、類似のビジネスおよび製品ポートフォリオにおける他のデザイナのビジネスオペレーションとであり得る。法的環境は、適用可能な法律、法規、規制、指令、ガイドライン、規格、業界標準、および外部環境への配慮であり得る。ウェブサイト環境は、デザイナのウェブサイト、デザイナのウェブサイトについてのＷＢＳの情報、および、類似または同等のビジネスであるデザイナのウェブサイトであり得る。

さらに、本発明の好ましい実施形態によれば、ＰＫＥは、セクションテキストのコンテンツに対する変更を検出し、セクションテキストの変更を、関連ウェブサイトに対する変更と相関させる。

さらに、本発明の好ましい実施形態によれば、分析エンジンは、現在のウェブサイトと類似のビジネスにおけるデザイナのウェブサイトに対する変更を検出する。

さらに、本発明の好ましい実施形態によれば、リビング文書ジェネレータは、タグをセクションテキストコンテンツに関連付けるタグ付け装置を含む。タグは、セクションのタイプ、それが関連する地理、法律のタイプ、文書のタイプ、それに関連する法律コード、および／またはその法的ソースをリストする。

さらに、本発明の好ましい実施形態によれば、ＰＫＥは、セクションテキストコンテンツを更新するときにタグを更新する。

さらに、本発明の好ましい実施形態によれば、リビング文書ジェネレータは、属性をセクションテキストコンテンツに関連付けるために、関連付けテーブル、リンクされたエンティティグラフ、および／または機械学習エンジンを含む。

さらに、本発明の好ましい実施形態によれば、ＷＢＳの内部データソースは、デザイナに属するウェブサイトで用いられるＷＢＳ要素と、ＷＢＳ要素に関連するコードと、デザイナから収集された情報と、ウェブサイトに関するビジネス情報と、ウェブサイトのオペレーショナル情報と、ウェブサイトのクッキーと、サイト商用データベース情報とを含む。

さらに、本発明の好ましい実施形態によれば、外部オンラインデータソースおよび外部オフラインデータソースは、法律および規制オンラインおよびオフラインリポジトリを有する。

さらに、本発明の好ましい実施形態によれば、分析エンジンは、ウェブサイトに基づいて、セクションテキストのコンテンツを生成する機械学習エンジンを有する。

本発明の好ましい実施形態によれば、ＷＢＳのための方法も提供される。この方法は、複数の文書セクションからリビング文書を生成するステップを含み、このステップは、ウェブサイトのデザイナまたはエンドユーザの属性の関数として文書セクションを選択するステップを含む。方法は、リビング文書に関連する法的環境、ビジネス環境およびウェブサイト環境の少なくとも１つに変更が生じた場合、リビング文書を更新するステップも含む。

さらに、本発明の好ましい実施形態によれば、生成するステップは、リビング文書に影響する変更について、内部および外部のデータソースをモニターするステップと、リビング文書に対する、外部の法律および／または規制ソースデータの影響の分析後、リビング文書のセクションテキストのコンテンツに対する変更を推奨するステップと、変更を、デザイナおよびＷＢＳベンダスタッフの少なくとも１つに通知するステップと、を含む。

さらに、本発明の好ましい実施形態によれば、生成するステップは、１つのセクションテキストにおける、１つの、推奨された、セクションテキストのオプションをデザイナが選択することを可能にするステップと、セクションテキストおよびセクションテキストのオプションの、事前公開編集および事後公開編集を可能にするステップと、を含む。

さらに、本発明の好ましい実施形態によれば、更新するステップは、リビング文書に関するＷＢＳ情報およびビジネスオペレーショナル情報を決定するために、ＷＢＳの内部データソースと、外部オンラインデータソースおよび外部オフラインデータソースの少なくとも１つとを分析するステップを含む。

さらに、本発明の好ましい実施形態によれば、推奨するステップは、セクションテキストのコンテンツに対する変更を検出するステップと、セクションテキストの変更を、関連ウェブサイトに対する変更と相関させるステップと、を含む。

さらに、本発明の好ましい実施形態によれば、分析するステップは、現在のウェブサイトと類似のビジネスにおけるデザイナのウェブサイトに対する変更を検出するステップを含む。

さらに、本発明の好ましい実施形態によれば、更新するステップは、タグをセクションテキストコンテンツに関連付けるステップを含む。タグは、セクションのタイプ、それが関連する地理、法律のタイプ、文書のタイプ、それに関連する法律コード、および／またはその法的ソースをリストする。

さらに、本発明の好ましい実施形態によれば、推奨するステップは、セクションテキストコンテンツを更新するときにタグを更新するステップを含む。

さらに、本発明の好ましい実施形態によれば、推奨するステップは、属性をセクションテキストコンテンツに関連付けるために、関連付けテーブル、リンクされたエンティティグラフ、および／または機械学習エンジンを利用するステップを含む。

さらに、本発明の好ましい実施形態によれば、分析するステップは、ウェブサイトに基づいて、セクションテキストのコンテンツを、機械学習を用いて生成するステップを含む。

本発明と見なされる主題事項は、本明細書の最後の部分において特に指摘され、明確に特許請求される。しかしながら、本発明は、その目的、特徴、および利点と共に、構成および動作方法の両方に関して、添付の図面と共に読まれるときに、以下の詳細な説明を参照することによって最も良く理解され得る。
図１は、階層的ウェブサイトの作成および更新のためのシステムの概略図である。 図２は、本発明に従って構築され、動作する、ウェブサイト構築システムのためのテキストコンテンツの対話型生成および構造編集のためのシステムの概略図である。 図３は、本発明に従って構成され、動作する、図２のテキストコンテンツ生成システムの概略図である。 図４は、本発明に従って構成され、動作する、図３のＨＤＳ（ｈｉｅｒａｒｃｈｉｃａｌ ｄａｔａ ｓｔｒｕｃｔｕｒｅ）／ルールハンドラの要素の概略図である。 図５は、本発明に従って構成され、動作する図３の分析エンジンの要素の概略図である。 図６は、本発明に従って構成され、動作する、図３のＨＤＳエディタの要素の概略図である。 図７は、本発明に従って構成され、動作する、図３のコンテンツ管理システムの様々なリポジトリの概略図である。 図８は、本発明に従って構築され、動作する、編集セッション中の図３のシステムのワークフロー機能の概略図である。 図９は、本発明に従って構成され、動作する、図３のデータ収集部の要素の概略図である。 図１０は、本発明に従って構成され、動作する、図７のテキストＨＤＳリポジトリの構造の概略図である。 図１１は、本発明に従って構成され動作するサンプル階層データ構造の概略図である。 図１２Ａは、本発明に従って構成され、動作する、図３のＨＤＳエディタのための例示的なユーザインターフェースの概略図である。 図１２Ｂは、本発明に従って構成され、動作する、図３のＨＤＳエディタのための例示的なユーザインターフェースの概略図である。 図１２Ｃは、本発明に従って構成され、動作する、図３のＨＤＳエディタのための例示的なユーザインターフェースの概略図である。 図１３Ａは、本発明に従って構成され、動作する、コンテキストを保存するサンプル階層データ構造に対する変更の概略図である。 図１３Ｂは、本発明に従って構成され、動作する、コンテキストを保存するサンプル階層データ構造に対する変更の概略図である。 図１３Ｃは、本発明に従って構成され、動作する、コンテキストを保存するサンプル階層データ構造に対する変更の概略図である。 図１３Ｄは、本発明に従って構成され、動作する、コンテキストを保存するサンプル階層データ構造に対する変更の概略図である。 図１４は、本発明に従って構成され、動作する、ウェブサイト構築システムのための、リビング文書の対話型生成および構造化編集のためのシステムの概略図である。 図１５Ａは、本発明に従って構成され、動作する、ウェブサイト構築システムのためのリビング文書の対話型生成および構造化編集のためのシステムの要素の概略図である。 図１５Ｂは、本発明に従って構成され、動作する、ウェブサイト構築システムのためのリビング文書の対話型生成および構造化編集のためのシステムの要素の概略図である。 図１６は、本発明に従って構成され、動作するリビング文書の部分の概略図である。 図１７は、本発明に従って構成され、動作するＬＤＧタグの概略図である。 図１８は、本発明に従って構成され、動作する、リビング文書に対する更新の概略図である。

説明を簡単かつ明確にするために、図に示される要素は必ずしも一定の縮尺で描かれていないことが理解され得る。例えば、いくつかの要素の寸法は、明確にするために、他の要素に対して誇張されていることがある。さらに、適切であると考えられる場合、参照番号は、対応するまたは類似の要素を示すために、図面の間で繰り返され得る。

以下の詳細な説明では、本発明の完全な理解を提供するために多くの具体的な詳細について述べる。しかしながら、当業者には、本発明がこれらの特定の詳細なしに実施され得ることが理解され得る。他の例では、周知の方法、手順、およびコンポーネントは、本発明を曖昧にしないように詳細には説明されていない。

出願人は、既存のウェブサイト構築システムが、各テキストコンポーネントの実際のコンテンツの作成においてユーザをサポートせず、特定の目的のためにウェブサイトのコンテンツの作成において最良のプラクティスがどのようなものであるかについての十分なガイダンスおよび推奨を提供しないことに気付いた。通常、空のコンポーネントのみがテキストなしで提供されるか、プレイスホルダーテキストのみで提供される。非テキストコンテンツ（画像およびビデオなど）の場合、多くの入手可能なリポジトリ（ユーザが選択することができる）、またはそのようなコンテンツを生成する容易な方法（例えば、カメラを使用する）が存在することが多い。

テキストコンテンツの場合、単純な事前に書かれたテキストは、しばしば不十分である（かつ、非常に一般的である）ことが理解され得る。また、大量の標準テキストの中から迅速に見て選択する容易な方法はなく、「ブランクスクリーン」で始まることは、ほとんどのユーザにとって極めて困難である（「ライターのブロック」として知られる現象）。したがって、ほとんどのウェブサイト構築システムは、単に、テキストコンポーネントに無意味なサンプルテキスト（周知の「Ｌｏｒｅｍ Ｉｐｓｕｍ」など）を記入することができる。また、出願人は、ユーザが必要なテキスト要素を記入することができないか、またはユーザが書いたテキストに満足しないために、ユーザがサイトを全く公開しないことが多いことに気付いた。

自然言語生成（ＮＬＧ：Ｎａｔｕｒａｌ Ｌａｎｇｕａｇｅ Ｇｅｎｅｒａｔｉｏｎ）のための解決策（テンプレート、ルールエンジン、または機械学習を使用するものなど）は、当技術分野に存在する。既存のＮＬＧシステムは、典型的には、フォームレター、ニュース記事、天気予報、またはチャットボット応答などのスタンドアロンのテキストコンテンツの自動生成を提供することを目的とする。そのような解決策は、典型的には、非対話型であり、ウェブサイト作成での使用にはあまり適していない。

本出願人はまた、テキストの対話型生成および構造化編集をウェブサイト構築システム内部データ構造と統合し、それを上述の自動化サイト生成プロセスの一部として収集された情報（ユーザ自身のデータおよび他のウェブサイトのものを含む）に組み込むシステムによって、上述の不十分さを克服することができることを見出した。テキスト生成のプロセスは、以下に詳細に説明するように、データ収集、分析エンジン、ルールリポジトリおよびフォローアップテキストコンポーネント編集を含む対話型の代替テキスト選択プロセスと統合される。そのようなプロセスは、ウェブサイト構築システムのサイト作成および編集プロセス内で特に有用であり得る。

このシステムは、ウェブサイト構築システムベースのテキストコンテンツジェネレータを包含し、このウェブサイト構築システムベースのテキストコンテンツジェネレータは、（以下でより詳細に説明するように、所与のフィールド役割のための）テキスト要素代替物階層を記述する階層データ構造（ＨＤＳ：Ｈｉｅｒａｒｃｈｉａｌ Ｄａｔａ Ｓｔｒｕｃｔｕｒｅ）と、情報収集要素と、現在のユーザに関連する情報と他のユーザに関連するクラウドソース情報との両方を含む情報の収集をサポートする情報収集と、おそらくＡＩ／ＭＬエンジンおよび自然言語処理に基づくテキストハンドリングルールのためのルールセットおよび分析エンジンと、テキストオプションのフィルタリング、ランキング、多様化、順序付けおよび適応と、この階層データ構造に基づく対話型テキスト選択および順序付けをサポートすることができる対話型階層データ構造エディタと、分析エンジンと、ウェブサイト構築システムサイトのためのテキストコンテンツを作成するための収集された情報との組合せを統合する。階層データ構造は、以下でより詳細に論じるように、フィールドコンテンツ、テキスト段落、および文を記述するノードおよびサブツリーを有するものと見なすこともできることを理解されたい。

従って、最終テキストは、階層データ構造の事前定義コンテンツと、追加システム適応と、ユーザによる操作及び選択と、ユーザ情報及びクラウドソーシングデータと共に、ユーザによる書き込み又は編集に基づいてプレイスホルダー及び自由テキストに埋め込まれた情報と、の組合せである。

ここで図２を参照すると、図２は、本発明の一実施形態による、ウェブサイト構築システムのためのテキストコンテンツの対話型生成および構造編集のためのシステム２００を示す。テキスト生成プロセスは、基礎となるデータ収集サブシステム、分析エンジンおよびルールリポジトリ、および以下に詳細に説明するようなフォローアップテキストコンポーネント編集を備えた、対話型代替選択プロセスと統合されることが理解され得る。

以下に説明するシステム２００は、テキスト生成と共にウェブサイト構築を目的とすることが理解され得る。しかしながら、代替実施形態では、システム２００は、テキストストリーム内の要素（例えば、埋め込まれた画像を含むテキストフロー）や、セクションから構成可能な他のタイプの複合オブジェクト（例えば、音楽トラックのシーケンスから構成されるバックグラウンド音楽プレイリストのコンポーネント）など、他のオブジェクトタイプにも同じ技術を使用することができる。

システム２００は、テキストコンテンツジェネレータ（ＴＣＧ：Ｔｅｘｔ Ｃｏｎｔｅｎｔ Ｇｅｎｅｒａｔｏｒ）システム８０と共に米国特許第１０，０７３，９２３号に記載されているようなシステム１００の要素を含むことができる。典型的な実施形態では、構築されたサイトは、特定の目的を果たすセクション（レイアウト要素または部分ページセクションなど）からなり、オブジェクトの同様の構成（例えば、タイトル／サブタイトル／テキスト段落／ボタン／メディア［画像］からなる５タプル）からなることが理解され得る。いくつかのセクションは、複数のそのような５タプルを示すかもしれないリストを記述するセクションのような、複数のそのようなセットを含んでいてもよい。

各固有のテキストフィールド（例えば、セクション／ビジネスタイプの組み合わせ）について、ＷＢＳベンダスタッフ６１は、特定の階層データ構造（例えば、タイトル／サブタイトル／テキストパラグラフ／ボタン）において定義されたテキストコンテンツのオプションの役割および一致するセットを定義することができる。これらのテキスト要素のすべては、サイトジェネレーションシステム４０によって収集された情報から埋められるプレイスホルダーを含むことができる。

システム２００は、テキストライティング、編集、適応、レビュー、および翻訳サービスなどの外部テキスト関連サービスを含むことができる外部システム７０との統合も提供することができることを理解されたい。これは、従来のオフラインサービス（翻訳代理店など）、またはインターネットベースのサービスプロバイダ（ｆｉｖｅｒｒ．ｃｏｍからのＦＩＶＥＲＲなど）とすることができる。

次に、ＴＣＧシステム８０の要素を示す図３を参照する。ＴＣＧシステム８０は、役割決定部（ｒｏｌｅ ｄｅｔｅｒｍｉｎｅｒ）８１、ＨＤＳ（階層データ構造）／ルールハンドラ８２、分析エンジン８３、ＨＤＳエディタ８４、視覚編集コーディネータ８５、テキストジェネレータ８６、ＨＤＳ／ルールコーディネータ８７、ＨＤＳ ＳＥＯビルダー８８、テキストキットインターフェース８９およびデータ収集部（ｄａｔａ ｇａｔｈｅｒｅｒ）９５を含むことができる。

役割決定部８１は、テキストフィールドの役割を決定することができ、ＨＤＳ／ルールハンドラ８２は、役割の管理、それらの操作（定義およびインスタンスの処理）を含む階層データ構造およびルール、ならびにそれに応じてＣＭＳ５５内のそれらのリポジトリの更新に責任を負うことができる。ＨＤＳ／ルールハンドラ８２は、保存された（ＣＭＳ５５）ＨＤＳ／ルールデータ構造とインメモリ（ｉｎ－ｍｅｍｏｒｙ）構造の両方を処理することができる。分析エンジン８３は、（機械学習、人工知能、自然言語処理、または事前定義されたルールに基づいて）情報の分析に関連するサービスを提供して、テキストオプションの推奨をユーザに提示し、推奨を役割、ルール、および階層データ構造に変更することができる。視覚編集コーディネータ８５は、ＨＤＳエディタ８４とＷＢＳエディタ３０との間で調整することができる。ＨＤＳ／ルールコーディネータ８７は、上記の要素のすべての間と、役割決定部８１、ＨＤＳ／ルールハンドラ８２、分析エンジン８３およびデータ収集部９５と、ＣＭＳ５５内のリポジトリとの間とで、調整することができ、分析エンジン８３などのための階層データ構造定義および定義、ルールおよび人工知能情報を交換する。テキストジェネレータ８６は、さらなる編集およびサイト生成のために使用される最終テキストを生成することができる。ＨＤＳ ＳＥＯビルダー８８は、さらに、階層データ構造のインスタンスで利用可能な情報を使用して特定のＳＥＯ関連情報を生成することができ、テキストキットインターフェース８９は、テキストキット抽出およびキット再統合機能を提供することができ、データ収集部９５は、分析エンジン８３によって使用される情報を収集することができる。これらの要素の機能については、以下でより詳細に説明する。

ここで、ＨＤＳ／ルールハンドラ８２の要素を示す図４を参照する。ＨＤＳ／ルールハンドラ８２は、オーダラー（ｏｒｄｅｒｅｒ）８２１、デリーター（ｄｅｌｅｔｅｒ）８２２、クリエータ８２３、フィルタラー（ｆｉｌｔｅｒｅｒ）８２４、ランカー（ｒａｎｋｅｒ）８２５、ダバーサファイアー（ｄｉｖｅｒｓｉｆｉｅｒ）８２６、ノードアダプター８２７、およびルールアダプター８２８を含むことができる。これらの要素の機能については、以下でより詳細に説明する。

ここで、分析エンジン８３の要素を示す図５を参照する。分析エンジン８３は、ＡＩ（ａｒｔｉｆｉｃｉａｌ ｉｎｔｅｌｌｉｇｅｎｃｅ：人工知能）／ＭＬ（ｍａｃｈｉｎｅ ｌｅａｒｎｉｎｇ：機械学習）エンジン８３１、ＮＬＰ（ｎａｔｕｒｅ ｌａｎｇｕａｇｅ ｐｒｏｃｅｓｓｉｎｇ：自然言語処理）エンジン８３２、およびルールエンジン８３３を備えることができる。これらの要素の機能は、以下でより詳細に説明される。システム２００の異なる実施形態は、分析エンジン８３の要素のうちの１つまたは２つのみを実装することができることが理解され得る。次に、ＨＤＳエディタ８４の要素を示す図６を参照する。ＨＤＳエディタ８４は、さらに、分析ベースのテキストクリエータ８４１、ＨＤＳインスタンスクリエータ８４２、ＨＤＳクリエータ／エディタ８４３、ロールクリエータ／エディタ８４４およびルールクリエータ／エディタ８４５を含むことができる。これらの要素の機能については、以下でより詳細に説明する。

ＨＤＳエディタ８４は、階層データ構造における定義のセットアップ（例えば、ＷＢＳベンダスタッフ６１による）および階層データ構造におけるローカルインスタンスの編集（例えば、サイトデザイナ６２による）の両方のための統一された編集環境を提供してもよいことが理解され得る。代替実施形態では、システム２００は、例えば、ＨＤＳエディタ８４を別個の定義編集（場合によってはルール編集を統合する）およびインスタンス編集ツールに分割することによって、タスクのそれぞれに対して別個の編集環境を提供することができる。この定義編集環境は、ＨＤＳクリエータ／エディタ８４３を使用して、基本的な階層データ構造の定義作成を実施することができ、これは、手動または自動であっても、あるいは、これら２つの組み合わせであってもよいことが理解され得る。階層データ構造の定義の手動作成は、階層データ構造またはテキスト変形テーブル（以下で説明する「私たちについて」の例など）の作成をサポートする視覚編集環境に基づいてもよい（たとえば）。自動作成は、例えば、共通の構造及びサブストラクチャを検出し、それらをＨＤＳエディタ８４によって編集され得るオプションの提案された階層に配置するために、所与の役割のための相当数のテキストサンプルの分析に基づいてもよい。そのようなテキストサンプルは、データ収集部９５を使用して収集されてもよく、追跡分析は、分析エンジン８３（特にＮＬＰエンジン８３２を含む）を使用して行われてもよい。また、階層データ構造定義の作成および編集のための記述された手順は、生成された階層データ構造のアプリケーションおよび動作のための一致ルールのセットを作成するためにも使用され得ることが理解され得る。

（上述したようである）階層データ構造定義編集は、典型的には、ＷＢＳベンダスタッフ６１に保存されるが、システム２００は、この機能の一部または全部をサイトデザイナ６２に利用可能にすることができることが理解され得る。これは典型的には、所与のフィールド、ページ、ウェブサイト、ウェブサイト領域、または特定のユーザ（複数のサイト内で使用するため）に特有であることがある階層データ構造定義の私的変形の作成のコンテキストで行われる。そのような私的変形は、元の階層データ構造定義との継承関係を実装することができる。システム２００は、同様に、ユーザがローカルルールのバリエーションのためのルール編集を実行することを可能にしてもよい。このような私的変形は、例えば、特定の階層データ構造提供の私的変形に私的なパラグラフまたは文章の階層データ構造のサブ階層を追加したり、ユーザの好みをよりよく反映する他の変更を加えることを可能にする。システム２００はまた、ユーザがフルスケールの階層データ構造定義（おそらく、それらに固有のプライベートルールを含む）を作成することを可能にし得、これはまた、他のユーザに転送可能であり得るか、またはオブジェクトマーケットプレイス１５を介して販売され得る。

以下では、図７を参照し、上記のように、関連するウェブサイト構築システム（ＣＭＳ５５）のコンテンツ管理システム内に保持される可能性のある種類のリポジトリの典型的なグループを示す。米国特許第１０，０７３，９２３号に記載されているＣＭＳ５０のリポジトリに加えて、ＣＭＳ５５は、ＴＰＡ（Ｔｈｉｒｄ Ｐａｒｔｙ Ａｐｐｌｉｃａｔｉｏｎ：サードパーティアプリケーション）ストア５２１、ＡＡＩ（Ａｄｄｉｔｉｏｎａｌ Ａｄｍｉｎｉｓｔｒａｔｉｖｅ Ｉｎｆｏｒｍａｔｉｏｎ）リポジトリ５２２、テキストＨＤＳリポジトリ５２３、ＴＣＧフィールドロールリポジトリ５２４、およびＴＣＧ分析ルールリポジトリ５２５も備えることができることが理解され得る。当然のことながら、ＣＭＳ５５の様々なリポジトリはすべて、ウェブサイト作成プロセス中にＷＢＳエディタ３０およびサイトジェネレーションシステム４０によって使用することができる。

次に、編集セッション中のＴＣＧシステム８０の機能を示す図８を参照する。典型的な使用シナリオでは、ユーザは、サイト生成またはレビュープロセス中に、またはＷＢＳエディタ３０内で（以下でより詳細に説明するように）、ウェブサイト構築システムを使用しながら、ＴＣＧシステム８０を呼び出すことができることが理解され得る。上述したように、ユーザは、典型的には、ウェブサイトデザイナ６２である。ＷＢＳベンダスタッフ６１は、テンプレートを（例えば）編集するために実行時にＴＣＧシステムを使用してもよいことが理解され得る。さらに、サイトユーザ６３は、テキストの作成または編集（オークションサイト内の製品説明テキストを更新するユーザなど）を含む特定の編集権を与えられた場合には、ＴＣＧシステム８０を使用してもよいことが理解され得る。

ＴＣＧシステム８０は、ウェブサイト構築プロセス中に、ＷＢＳエディタ３０およびサイトジェネレーションシステム４０によって呼び出されてもよいことも理解され得る。代替実施形態では、ＴＣＧシステム８０は、独立型であり、関与するモジュールなしで動作することができる。

ユーザは、（例えば）ページ編集セッション中に、（ＨＤＳエディタ８４を介して）テキスト入力を必要とするテキストフィールドを選択することができる。役割決定部８１は、フィールドを受け取り、その役割を決定し（本明細書でより詳細に後述されるように）、それを分析エンジン８３に転送することができ、この分析エンジンは、その役割のための１つ以上の提案された階層データ構造定義を検索することができる。

分析エンジン８３は、提案された階層データ構造定義をＨＤＳ／ルールハンドラ８２に送ることができる。ＨＤＳ／ルールハンドラ８２は、ＨＤＳエディタ８４にそれらを提供することができる（これは、推奨される階層データ構造またはテキストオプションをユーザに提示することができる）。その後、ユーザは、必要に応じて（ＨＤＳエディタ８４を介して）階層データ構造を編集することができる。編集には、実際のテキスト編集と同様に、階層データ構造定義自体に対する変更（以下に詳細に説明するように、分岐の選択、要素の削除、ノードの並べ替えなど）が含まれてもよいことが理解され得る。ＨＤＳインスタンスクリエータ８４２は、階層データ構造定義（以下でさらに詳細に説明する）から階層データ構造インスタンスを作成することができる。フィールドロールとフィールドロールの関連付けは、リポジトリ５２３および５２４に保存できる。

編集には、プレイスホルダーテキスト値の入力も含まれることが理解され得る。ＨＤＳエディタ８４は、テキスト編集および階層データ構造変更の取扱いに関するガイドラインを提供するために、分析エンジン８３を参照しても良いし、またはＣＭＳ５５を直接参照してもよい。

ＨＤＳエディタ８４は、階層データ構造インスタンスをＨＤＳ／ルールハンドラ８２に送信し、テキストジェネレータ８６に送信して、フィールドの最終テキスト（場合によっては、バックリンクまたは基礎となる階層データ構造インスタンスとの他の関連付けを含む）を生成することができる。

ＨＤＳ／ルールハンドラ８２は、結果のテキストおよび更新された階層データ構造をＣＭＳ５５に記録することもできる（ＥＨ（ｅｄｉｔｉｎｇ ｈｉｓｔｏｒｙ：編集履歴）リポジトリ５１１およびテキストＨＤＳリポジトリ５２３の更新を含む）。

プレイスホルダーテキストは、ユーザ自身（ＨＤＳエディタ８４を介して）、ＣＭＳ５５、またはサイトジェネレーションシステム４０自体を含む複数の場所から来てもよく、したがって、ＨＤＳ／ルールハンドラ８２をテキストジェネレータ８６に直接バイパスしてもよいことがさらに理解され得る。

テキストフィールドはすでに決定された役割と階層データ構造を有するので、テキストフィールドの再編集は、（編集プロセスの後の段階で）減少されたワークフローパターンを使用することができることも理解され得る。これは、作成ワークフローではなく、メンテナンスワークフローと見なされる場合がある。

別のワークフローは、ロールクリエータ／エディタ８４４、ＨＤＳクリエータ８４３／エディタおよびルールクリエータエディタ８４５を使用して、初期の階層データ構造仕様、分析エンジン８３によって使用される初期の役割割り当ておよびルールを作成するときに、ＷＢＳベンダスタッフ６１によって使用されるセットアップワークフローであってもよい。

更新されたテキストはまた、ＳＥＯ（Ｓｅａｒｃｈ Ｅｎｇｉｎｅ Ｏｐｔｉｍｉｚａｔｉｏｎ：検索エンジン最適化）の一部として使用されてもよく、以下でより詳細に説明されるように、ＨＤＳ ＳＥＯビルダー８８に送信されてもよい。

ＴＣＧシステム８０のすべての要素が、編集セッション中に起動されてもよいわけではないことが理解され得る。例えば、分析エンジン８３は、フィールドに対する役割（非階層データ構造操作を必要とする）を選択するために起動されてもよく、ＨＤＳ／ルールハンドラ８２は、視覚編集コーディネータ８５によって起動されて、ＷＢＳエディタ３０のテキスト編集セッション（分析エンジン８３を含まない）の間に、ユーザによってテキストに対してなされた変更に階層データ構造を適合させてもよい。

また、テキストフィールドの役割（編集／実行時に使用される）は、ＷＢＳベンダスタッフ６１を介して（ロールクリエータ／エディタ８４４を介して）、ユーザ５によって、または以下に詳細に記載されるウェブサイト要素の分析を介して役割決定部８１によってセットアップされてもよいことが理解されるであろう。階層データ構造は、ＴＣＧ分析ルールリポジトリ５２５に記憶される分析エンジン８３によって使用されるルールと同様に、（ＨＤＳクリエータ／エディタ８４３を介して）ＷＢＳベンダスタッフ６１を介してセットアップすることができる。

次に、データ収集部９５の要素を示す図９を参照する。データ収集部９５は、（分析エンジン８３に関連して以下でより詳細に説明するように）内部および外部ソースからウェブサイト構築システムへ情報を収集するために、内部データ収集部９５１および外部データ収集部９５２を備えることができる。データ収集部９５は、階層データ構造のテストをサポートするために使用される集団ソース情報を収集することができる集団ソースデータ収集部９５３をさらに備えることができる。これらの要素の機能は、米国特許第１０，０７３，９２３号に記載されているように、内部データ収集部４４、外部収集部４３、および集団ソースデータアナライザ４２３の機能に類似している。内部データ収集部９５１、外部データ収集部９５２、および集団ソースデータアナライザ９５３は、同様のブラウザおよびデータ抽出技法を使用して同じデータソースにアクセスするが、収集されたデータは、以下でより詳細に説明するように、分析エンジン８３によって分析されることが理解され得る。

ユーザはまた、ＨＤＳエディタ８４と同様に、ＷＢＳエディタ３０で生成されたテキストを編集してもよいことが理解され得る。このシナリオでは、ユーザは、最終テキストを作成するために、視覚編集コーディネータ８５を介してＨＤＳエディタ８４と対話することができる。代替実施形態では、視覚編集コーディネータ８５は、ＨＤＳエディタ８４をバイパスしてＷＢＳエディタ３０に送ることによって、ＣＭＳ５５から直接階層データ構造を適応させることができる。また、ユーザは、テキストの構造化された編集から利益を得るために、将来、ＨＤＳエディタ８４に戻ってもよいことが理解され得る。視覚編集コーディネータ８５は、ＷＢＳエディタ３０で自由に編集されたテキストとその構造階層データ構造ベースの表現との間の統合を維持するために、必要な調整および編集履歴追跡を提供することができる。

代替の実施形態では、ＴＣＧシステム８０は、ウェブサイト構築システムの外部で（例えば、スタンドアロンの構成で、またはウェブサイト構築システムベンダのサーバ上で依然としてホストされている間に）使用されてもよい。このシナリオでは、ＴＣＧシステム８０は、限られたバージョンのシステム２００で動作することができ、直接（例えば、オンラインで）、またはウェブサイト構築システムによってそれに送信される情報を介して、必要な情報のためにウェブサイト構築システムと対話することができる。あるいは、ＴＣＧシステム８０は、システム２００のいくつかのサブ要素（ＣＭＳ５５またはＷＢＳエディタ３０の要素など）を含むことができる。このような構成は、例えば、本明細書で上述したような外部のテキスト作成／翻訳機関による大規模テキスト作成または編集に有用であり得る。

ＴＣＧシステム８０は、それ自体の専用ＵＩを介して直接使用されてもよく、または、必要なＵＩを提供する別のシステムによって使用されるか、それに組み込まれる（ＡＰＩまたはウェブサービスを介して）実装されてもよい。

以下の説明は、システム２００に関連する特徴に焦点を当てており、ウェブサイト構築システムに入手可能な全ての特徴を必ずしも含まないことが理解され得る。システム２００はまた、記述された特徴のサブセットを実装してもよく、必ずしも全ての記述された特徴を実装するとは限らない。

以下では、ウェブサイト構築システムによって作成され、エンドユーザがウェブサイトとしてアクセスするアプリケーションについて説明する。さらに、システム２００は、特定のクライアントソフトウェアを使用してアクセスされる他のカテゴリのオンラインアプリケーションに適用可能であることが理解され得る。このようなクライアントソフトウェアは、スタンドアロンで実行することも、ブラウザ（Ａｄｏｂｅ Ｆｌａｓｈプラグインなど）からアクティブ化することもできる。エンドユーザは、（図２に示すように）通常のＰＣ上のクライアントソフトウェアを使用してこれらのウェブサイトにアクセスすることができるが、スマートフォン、タブレットコンピュータ、およびその他のデスクトップ、モバイル、ウェアラブルデバイス上でもアクセスすることができる。あるいは、システム２００は、本発明の共通の譲受人に譲渡され、参照により本明細書に組み込まれる、２０１８年６月１２日に付与された「Ｖｉｓｕａｌ Ｄｅｓｉｇｎ Ｓｙｓｔｅｍ ｆｏｒ Ｇｅｎｅｒａｔｉｎｇ ａ Ｖｉｓｕａｌ Ｄａｔａ Ｓｔｒｕｃｔｕｒｅ Ａｓｓｏｃｉａｔｅｄ ｗｉｔｈ ａ Ｓｅｍａｎｔｉｃ Ｃｏｍｐｏｓｉｔｉｏｎ Ｂａｓｅｄ ｏｎ ａ Ｈｉｅｒａｒｃｈｙ ｏｆ Ｃｏｍｐｏｎｅｎｔｓ」という名称の米国特許第９，９９６，５６６号に記載されているように、ゲーム、モバイルアプリケーション、ネイティブアプリケーション、または他のアプリケーションタイプを生成するシステムに適用可能であってもよい。

特に、システム２００は、デスクトップアプリケーションの開発環境（例えば、パーソナルコンピュータと共に使用するため）、モバイルアプリケーションの開発環境（例えば、スマートフォン及びタブレットと共に使用するため）、クライアントサーバアプリケーションの開発環境及び非ブラウザウェブアプリケーションの開発環境（Ａｄｏｂｅのフラッシュプレーヤのような環境と共に使用するため）、プラグイン開発環境、他のシステム（ウェブブラウザ又はその他）のためのプラグイン及び他のアドオン要素を作成するシステム、及びショップビルダ、即ち、ｅショップ（又はｅコマースサイト）の作成に焦点を当てるシステム、のようなスタンドアロンアプリケーションの開発環境を作成するために使用される視覚デザインシステムに適用可能である。

さらに、システム２００は、アプリケーション内部の通常のテキストコンポーネントではないテキストコンテンツを生成するために使用されてもよい。例示的な使用は、ＵＩの一部として、または通信メッセージの一部として提供されるテキスト、例えば、本発明の共通の譲受人に譲渡され、参照により本明細書に組み込まれる、２０１８年６月２１日に公開された「Ａｃｔｉｏｎａｂｌｅ Ｗｉｄｇｅｔ Ｃａｒｄｓ」という名称の米国特許出願公開第２０１８／０１７４２２９号に記載されたアクション可能なウィジェット（ｗｉｄｇｅｔ）カードを含むことができる。これらは、複数の通信チャネル（電子メール、チャット、アプリケーションメッセージキューなど）を介してユーザに送信され得る情報／推奨（最近発売された製品または他のマーケティング資料のための推奨されたブログポストテキストなど）をユーザに提供するカードである。別の例は、ソーシャルネットワーク（Ｆａｃｅｂｏｏｋ（登録商標）やＴｗｉｔｔｅｒ（登録商標）のようである）に投稿するテキストであり、このシナリオでは、システム２００は、テキストを適応させるか、望ましい配信チャネルに基づいた適切な階層データ構造を提供することができる（例えば、Ｔｗｉｔｔｅｒ（登録商標）用には短いテキストを提供し、ブログ投稿用には長いテキストを提供する）。さらに別の例は、ビデオに埋め込まれるテキスト（例えば、キャプション又は表示されたテキスト）又はオーディオコンテンツ（例えば、テキストから音声）のような、非アプリケーション環境／コンテンツに統合されるテキストである。システム２００はまた、ページデザインまたはレイアウトシステムの一部として、印刷された材料の作成に有用であり得、この場合もまた、提供されたスペースまたは印刷された作成デザインに関連する他の考慮事項に適切なテキスト代替物を提供し得る。

以下の議論はまた、ウェブサイト構築システムのプロバイダによってホストされるウェブサイト、特に、ホテル、法律事務所およびレストランなどの中小企業のためのオンラインプレゼンスを提供するウェブサイトに焦点を当てる。このようなビジネスは、米国特許第１０，０７３，９２３号に記載されているように、ファミリーおよび業界によって分類されることが多い。ファミリーは、学校、診療所、法律事務所など、企業の一般的なタイプまたはカテゴリを定義する。業界は、特定の業界または知識ドメインタイプである。例えば、学校ファミリーの場合、システムは、アート、エンジニアリング、および音楽学校などの複数の業界（すなわち、学校タイプ）をサポートすることができる。当然のことながら、システム２００は、本明細書で上述したように、追加のタイプのウェブサイトおよび他の非ウェブデジタル作成にも適用することができる。

上述したように、システム２００は、生成されたウェブサイト内のテキストフィールドのテキストコンテンツをインタラクティブに作成する際に、ユーザをサポートする。このようなフィールドは、通常、それを含むページまたはページセクション内のフィールドとその機能に関連して、それに関連付けられた役割を持つことができる。役割は、サイト、ページ、またはページセクション内で一意である場合とそうでない場合がある。例えば、ビジネスを記述する「私たちについて」ページは、１つの「私たちのカンパニー」テキストフィールド、１つの「主なサービス」テキストフィールド、および複数の「チームメンバー」テキストフィールドを有することができる。

テキストフィールドの役割は、いくつかの方法で決定される可能性がある。１つの方法は、フィールドの役割が事前定義されることである。例えば、フィールドは、そのテキストフィールドの一部または全部に対する役割を定義するテンプレートの一部（例えば、サイト、ページまたはページセクションレベル）であってもよい。役割決定部８１は、ＷＢＳベンダスタッフ６１またはウェブサイトデザイナが、そのような事前定義された役割を関連するテキストフィールドに割り当てるのを支援することができる。

米国特許第１０，０７３，９２３号に記載されているようなサイトジェネレーションシステムのコンテキストでは、テキストフィールドは、サイトジェネレーションシステムによって所与のページを構築するために使用されるレイアウト要素、レイアウトグループ、またはプリセットページセクションの一部とすることができる。役割決定部８１は、与えられたレイアウト要素／レイアウトグループ／プリセットページセクションがマッチングされる、または（直接的に）レイアウト要素／レイアウトグループ／プリセットページセクション自体に、下層のコンテンツ要素に役割を割り当てることができる。このような割り当ては、ＨＤＳ定義レベル（ベンダスタッフ６１の場合）またはＨＤＳインスタンスレベル（ユーザ６２の場合）で行うことができる。

役割決定部８１はまた、ＨＤＳエディタ８４を介してユーザに可能な役割のリストを提供してもよく、そこからユーザは（例えば、セットアップ段階で）適切な役割を選択してもよい。システム２００は、（類似語検索などの）検索エンジンによって典型的に提供される動作を使用して、（潜在的な役割の数が非常に多い可能性があるので）役割選択のための検索エンジンをさらに提供することができることを理解されたい。

役割決定部８１はまた、ウェブサイト構築システムに利用可能な追加情報、または分析エンジン８３によって実行される分析に基づいて、可能な役割のセットを決定し、それらをランク付けすることができる（以下でより詳細に説明するように）。分析エンジン８３によるそのような情報および分析は、例えば、含まれるページまたはページセクションについての予め定義された情報またはユーザ指定の情報（例えば、「私たちについて」ページ内のテキストフィールドについては、「カンパニー説明」、「私たちのチーム」などの役割のみを提供する）を含み得ることが理解され得る。また、現在のフィールドやその他のフィールド（以前のテキストフィールド用に選択されたロールなど）に対してユーザが入力した情報も含まれる場合がある。分析エンジン８３はまた、現在の、または他のユーザとの以前の対話からの情報と、ユーザのプロフィール情報に従って評価される可能性がある、同じユーザおよび他のユーザから収集された情報とを使用することができる（例えば、米国の不動産弁護士は、典型的には、サイトのフロントページにおける「専門知識の領域」などの役割を使用する）。

分析エンジン８３によって実行される役割決定分析はまた、サイトのレイアウト、コンポーネント、コンポーネントコンテンツ、幾何学的または他のコンポーネント関係、ならびにサイト編集履歴の分析を場合によっては含む、現在の、または他のサイトエリアの他のタイプの分析を含むことができる。たとえば、ユーザが３セットの［画像＋テキスト］を作成し、３つのテキストフィールドのそれぞれにロール「マネージャーのバイオグラフィー」を割り当てる。次に、ユーザは、以前の３セットと幾何学的に整列された４番目の、そのような［画像＋テキスト］セットを作成する。この場合、４番目のテキストフィールドの役割も「マネージャーのバイオグラフィー」である可能性が非常に高い。

別の例では、役割決定部８１は、テキストフィールドが近くの画像フィールドに関連し、表示画像が人物の顔であると決定してもよい。これは、（たとえば）画像メタデータ／名前／説明、または画像コンテンツ分析に基づくことができる。このようなシナリオでは、テキストフィールドの役割が、人の詳細、情報、またはバイオグラフィーに関連することを期待することが合理的である。

また、役割決定部８１は、利用可能な情報（本明細書で上述した収集された情報など）を使用して、追加のユーザ対話を必要とせずに、自動フィールド役割決定を行うことができることも理解され得る。

あるいは、役割決定部８１は、ユーザ入力ベースの分析を実行してもよい。１つの特定のタイプの分析は、ユーザに、所望のタイプのコンテンツの自由形式の例を（フィールドに）タイプさせることである。次いで、役割決定部８１は、（分析エンジン８３に関連して以下でより詳細に説明するように）ＮＬＰエンジン８３２を使用してこのコンテンツを分析することができる。ＮＬＰエンジン８３２は、特定のフィールド役割（これが必要とされる場合）と、場合によっては、必要なコンテンツに関する追加情報とを認識して、同じ目的を果たす専門的に書かれたコンテンツ変形（以下でより詳細に説明する）をユーザに提供することができる。

ユーザが入力したテキストは、通常の検索キーとして（すなわち、検索エンジンで使用されているように）使用されないことが理解され得る。むしろ、役割決定部８１は、ＮＬＰエンジン８３２に、ユーザの意図を抽出し、次に、ユーザによって提供されたものとはまったく異なるまたは無関係なテキストを代替が使用している場合であっても、同じ意図を果たすテキスト代替を含む現在の役割または関連する役割をＨＤＳリポジトリ５２３で検索するように命令してもよい。

また、上述したもののような、役割決定部８１によって使用される分析方法は、米国特許第１０，０７３，９２３号のＮＬＰエンジン４２１１の機能、ならびに、２０１５年３月１２日に公開され、本発明の共通の譲受人に譲渡され、参照によって本明細書に組み込まれる、「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ａｕｔｏｍａｔｅｄ Ｃｏｎｖｅｒｓｉｏｎ ｏｆ Ｉｎｔｅｒａｃｉｖｅ Ｓｉｔｅｓ ａｎｄ Ａｐｐｌｉｃａｔｉｏｎｓ ｔｏ Ｓｕｐｐｏｒｔ Ｍｏｂｉｌｅ ａｎｄ Ｏｔｈｅｒ Ｄｉｓｐｌａｙ Ｅｎｖｉｒｏｎｍｅｎｔｓ」という名称の米国特許公開第２０１５／００７４５１６号のＰＯＳロケータ２５０に関して説明されているような様々なタイプの幾何学的および意味論的分析に類似し得ることも理解され得る。本明細書で上述した分析はまた、ＨＤＳ／ルールハンドラ８２によって使用されて、階層データ構造および階層データ構造ノード／サブツリーのリストを、それらが提示される順序（すなわち、それらの「検索ランク」）だけでなく、選択のためにユーザに表示されるようにランク付けすることができる。

本明細書で上述したように、テキストフィールドの役割が分かると、その知識をＴＣＧシステム８０が使用して、特定のフィールドのコンテンツを作成することができる。これは、分析エンジン８３によって決定された役割に関連する適切な階層データ構造を（ＨＤＳリポジトリ５２３から）取り出すことによって行うことができる。システム２００は、使用する階層データ構造を選択するために、（役割決定部８１および可能であればユーザの選択のために上述したように）追加の収集された情報を使用して、所与の役割に複数の階層データ構造を関連付けることを可能にしてもよい。

次に、ＨＤＳリポジトリ５２３のサブ要素を示す図１０を参照する。各階層データ構造に対して、ＨＤＳリポジトリ５２３は、そのフィールドロールアソシエーション５２３１、そのＨＤＳ定義５２３２、およびそのＨＤＳローカルインスタンス５２３３を格納することができる。単一の役割は、複数の階層データ構造定義を有することができ、ＨＤＳローカルインスタンス５２３３は、編集コンテキスト情報を含むことができることが理解され得る。したがって、ＨＤＳリポジトリ５２３は、現在のディスプレイに現れないが、ユーザが戻った場合に保持されるものを含めて、ユーザによってなされた現在の選択および修正を記憶することができる。

階層データ構造は、上記の様々な分析および選択要素に必要な情報を提供する追加属性を含む、テキストフィールドに配置される生成されたテキストの要素のための様々なオプションを記述することが理解され得る。階層レベルはノード構造に似ていてもよく、ノードのタイプは異なる。例えば、ノードは、「オプション選択ノード」（シングルノード）、ノードまたはエンドノードの兄弟関係をもつ「順序集合」から成る。「いずれかの」ノードの場合、ユーザは、提供された代替サブノードの１つを選択する必要がある（以下で詳細に説明するように決定され、ランク付けされる）。

「順序集合」ノードは、与えられたサブノードの順序列からなるサブツリーである。ユーザは、サブノードの順序の変更やサブノードの削除など、このシーケンスに対するさまざまな編集操作を実行できる。

ここで、ＨＤＳ／ルールハンドラ８２の要素を図示する図４に戻る。ＨＤＳ／ルールハンドラ８２を使用して、階層データ構造を修正し、以下でより詳細に説明するようにルールを適応させることができる。ユーザが編集するための最初のバージョンを作成するとき、ＨＤＳ／ルールハンドラ８２は、分析エンジン８３によってなされた推奨に基づいて（例えば、表示するノードを選択し、各表示された階層データ構造レベルでどのような順序で）、任意の順序付け／順位付け／多様化を実装することができることが理解され得る。

編集セッション中、ＨＤＳ／ルールハンドラ８２は、表示された階層データ構造のバックエンド処理を提供することができ、このバックエンド処理は、編集中の推奨について分析エンジン８３とのコンサルティングを含むことができる。このシナリオでは、ＨＤＳエディタ８４はフロントエンドであってもよく（クライアント、サーバ、またはその両方で実行されてもよいが）、ＨＤＳ／ルールハンドラ８２は、階層データ構造へのインターフェースを提供してもよい。

本明細書で上述したように、階層データ構造に対する修正は、例えば、複数のユーザによって行われた共通の変更を分析し、階層データ構造定義に対して永続的な変更が行われるべきであることを推論する、システムによって開始される分析を使用して行われてもよい。これは、完全にシステム開始されるか（例えば、所与の周波数で実行されるバックグラウンドプロセス）、または特定のユーザアクティビティによってトリガされる（例えば、Ｎ番目のユーザが同様の変更を行うとき）ことができることが理解され得る。

ＨＤＳ／ルールハンドラ８２は、テキストフィールドの階層データ構造に影響を与えるテキストフィールドにおける（ＴＣＧシステム８０が生成した）テキストの「通常の」編集に基づいて、視覚編集コーディネータ８５によって開始された階層データ構造変更を処理することもできる。

本明細書で上述したように、ＨＤＳ／ルールハンドラ８２は、役割、ルール、ノード、サブツリー、分析エンジン８３からの結果などのエンティティに対する操作および修正を処理することができる。ＨＤＳ／ルールハンドラ８２の機能性は、問題となっているハンドリングされたエンティティ、すなわち、役割、階層データ構造、またはノード自体に依存して適用され得ることが理解され得る。

オーダラー８２１は、一般に、エンティティを順序付けし、デリーター８２２は、一般に、エンティティを削除し、クリエータ８２３は、新規エンティティを作成し、フィルタラー８２４は、一般に、エンティティをフィルタリングし、ランカー８２５は、一般に、エンティティをランク付けし、ダバーサファイアー８２６は、エンティティを多様化し、ノードアダプター８２７は、ノードに変更を適応し、ルールアダプター８２８は、ＴＣＧ分析ルールリポジトリ５２５内のテキストコンテンツの生成分析ルールに変更を適応させ得る。

また、オーダラー８２１、フィルタラー８２４、ランカー８２５、およびダバーサファイアー８２６は、２０１７年８月２９日に付与され、本発明の共通の譲受人に譲渡され、参照により本明細書に組み込まれる「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ ｔｈｅ Ｃｒｅａｔｉｏｎ ａｎｄ ｕｓｅ ｏｆ Ｖｉｓｕａｌｌｙ－Ｄｉｖｅｒｓｅ Ｈｉｇｈ－Ｑｕａｌｉｔｙ Ｄｙｎａｍｉｃ Ｌａｙｏｕｔｓ」という名称の米国特許第９，７４７，２５８号に記載されているように、レイアウトランカーおよびフィルタ４５、ランカー４８、およびダバーサファイアー４９と同様に機能することができる。特に、ランカー８２５は、所定のオプションが選択される周波数（現在のユーザ、上記のような他のユーザまたは他の「類似の」ユーザによって）、特定の選択（使用された選択、保存された、または実際に公開された選択に基づいて生成されたテキスト）、他のフィールドに対してユーザによってなされた他の選択（例えば、フィールドの代替テキストを他のフィールドのためになされた選択と比較する）などのパラメータに従って実行することができる。オーダラー８２１は、米国特許第９，７４７，２５８号に記載されているように、ランキング情報とダイバーシティ情報とを組み合わせることに基づいて順序付けすることができる。

次に、階層データ構造の例を示す図１１を参照する。階層を使用することができる典型的な実施形態は、レベル１（Ｌ１）、文書（オプション選択ノード）、レベル２（Ｌ２）、パラグラフ（「順序集合」ノード）、レベル３（Ｌ３）、文の位置（「順序集合」ノード）、およびレベル４（Ｌ４）文の変形（オプション選択ノード）とすることができる。その他のレベルには、コンテンツ変形（「順序付きセット」ノード） や、エンドノードである単語／句読点、プレイスホルダー／追加要素などが含まれる場合がある。追加の終了ノード要素には、テキストに埋め込まれたオブジェクト（画像や図形など）、ハイパーリンク（ウェブサイト内またはウェブサイト外を指し示す）、および埋め込まれたウェブサイト要素（操作ボタン、「メール」リンクなど）も含まれる場合がある。したがって、所与の役割のためのテキストフィールドのコンテンツを作成するユーザ（「私たちの会社」）は、以下の表に（単なる例として）示されるように、可能なコンテンツ変形のうちの１つを選択することができ、その各々は、パラグラフの順序付けられたセットからなる。各パラグラフは、複数の文の位置から構成されてもよく、その各々は、文の変形のセットのうちの１つによって満たされてもよい。各文の変形は、単語、句読点、およびプレイスホルダーからなる。図１１はまた、以下の表に含まれるテキストオプションのいくつかを反映する部分的な階層データ構造と考えることもできる。

上の表は、“私たちについて”文書の単一のコンテンツ変形の単純化された例を示している（＊ＸＸＸ＊はプレイスホルダーである）。当然のことながら、この例は、（内部的に定義された、または外部ビジネス情報から収集された）企業のロケーションセットアップに応じて、「場所」の文（場所（任意の場所）、場所（複数）、および単一の場所）のための複数の変形を提供し、ユーザは、どの場所を保持するかを選択することができる。これはまた、以下でより詳細に論じられるように、ルールを使用して実行されてもよい。

階層は、典型的には、各レベルにおける順序付けられたシーケンスを自由に編集できるように作成されることが理解され得る。したがって、例えば、特定のパラグラフの文は、典型的には、上述の表に見られるように、任意の組み合わせまたは順序でうまく機能するように書かれる。実際、一実施形態では、オーダラー８２１は、兄弟関係の「順序集合」ノードのサブノードのいくつかまたはすべてをランダムに再配置することができる。これは、同じ階層データ構造に基づいて異なるサイトを互いにより明確にするという利点を有する。そのようなランダム化された段落／文の選択は、ＷＢＳベンダ６１の観点から（すなわち、作成されたサイトはより多様である）、また、検索エンジン最適化の観点から（検索エンジンは、類似して見える複数のサイトにペナルティを課すことがあるので）、より良好である。

また、階層データ構造は、「固定」要素、例えば、変更できない、移動できない、または代替物を有さない文を含むこともできることも理解され得る（ユーザが、そのような文を含むサブ階層を選択することを決定した場合）。しかしながら、このような要素は、ＷＢＳエディタ３０における通常のテキストフィールド編集の一部として修正することができる。

デリーター８２２は、ユーザ編集の結果としてノードを削除することができ、クリエータ８２３は、それに応じて、（ユーザ編集および入力されたテキストに基づいて）新しいノードを作成することができる。また、役割や完全な階層データ構造などの他のエンティティの削除や作成と同様の機能を提供する場合もある。

代替実施形態では、システム２００は、より多いまたはより少ないレベルを有する階層、または追加のまたは異なるノードタイプを使用する階層を含む、異なる階層を使用することができる。さらに、以下でより詳細に論じるように、階層は、分析エンジン８３によって行われる推奨に基づいて動作中に修正され得るので、動的であり得る。

いくつかの実施形態では、階層データ構造はまた、異なる場所にフックされ得る特定のサブツリーを再使用してもよい。したがって、階層データ構造の元のバージョン（ユーザ修正前）は、単一のルートの有向非巡回グラフであってもよい。

当然のことながら、プレイスホルダーは、本明細書で上述したように、会社名、人名などの情報によって満たすことができる内部フィールドマーカである。プレイスホルダーは、サイトグローバル（例えば、会社名）であってもよいし、所与のページまたはサイトエリア（マルチプロダクトサイトの特定のプロダクト詳細）に対してローカルであってもよい。システム２００は、米国特許第１０，０７３，９２３号に記載されているように、世代アンケートを通じてユーザとの以前の対話から、ウェブサイト内の他の場所から、または他のソース（例えば、ユーザのソーシャルネットワークの存在）から、この情報を有することができる。

上述したように、ユーザはＴＣＧシステム８０と対話し、所定のテキストフィールドに対して上記の階層データ構造操作の実行をサポートするＨＤＳエディタ８４を介して階層データ構造を編集することができる。テキストフィールドを入力するとき、ユーザは、ＷＢＳエディタ３０に追加された「ｈｅｌｐ ｍｅ ｗｒｉｔｅ」ボタンを使用して（例えば）ＨＤＳエディタ８４を起動することができる。

ＨＤＳエディタ８４は、ユーザが、ＨＤＳ／ルールハンドラ８２に関連して上述したフィルタリング／ランキング／多様化に従って、選択されたフィールドの階層構造に基づいて、分析エンジン８３によって生成された提案された代替案をプレビューすることを可能にすることができることを理解されたい。プレイスホルダーは、そのようなものとしてマークされ、初期値（既知の場合）で満たされてもよい。

ＨＤＳエディタ８４はまた、ユーザがすべてのレベルで代替をブラウズし選択することを可能にしてもよい（例えば、オプション選択ノードを介して複数の代替を有する文位置を有する）。

ＨＤＳエディタ８４の他の能力は、例えば、要素（文のようである）を削除したり移動したり、プレイスホルダー値を入力したり編集したりすることなど、ユーザがシーケンスを編集することを可能にする能力であることが理解され得る。システム２００のいくつかの実施形態は、ユーザが、以下でさらに詳細に論じられるように、ＷＢＳエディタ３０において別個の編集セッションに入らずに、ＨＤＳエディタ８４内に新しいテキストを挿入することを可能にしてもよい。

ＨＤＳエディタ８４はまた、フィールドに関連するローカル階層データ構造インスタンスにのみ実際に適用される階層の修正を可能にするオプションを提供してもよい。これは、例えば、ユーザが、１つのパラグラフから同じフィールドの別のパラグラフ（または別のフィールドの全体）に文を移動させたい場合であり得る。そのような移動は、移動された文に関連付けられた階層データ構造サブツリーをその元の位置（１つの段落の階層データ構造サブツリー内）から切り離し、それを別の段落の階層データ構造サブツリーに再び添付することができる。

代替実施形態では、ＨＤＳエディタ８４は、この時点で最終テキスト編集を可能にしてもよいが、この機能は、典型的には、ウェブサイト構築システムのテキストコンポーネントエディタ（ＷＢＳエディタ３０内）に予約されているが、このような編集は、追加テキストの挿入、ノードの削除、およびテキスト要素の任意の編集を含んでもよい。この実施形態では、ＨＤＳエディタ８４は、（例えば）テキストフィールドに関連する画像を（画像特徴分析エンジンを介して）分析し、特定の画像のための一致する書かれた記述またはキャプションを作成することに基づいて、分析ベースのテキストクリエータ８４１をさらに備えることができる。

編集モード（図８に戻って参照する）では、ＨＤＳエディタ８４は、本明細書で上述したように、ＨＤＳリポジトリ５２３から階層データ構造の初期バージョンをロードすることができることを理解されたい。しかしながら、ＨＤＳエディタ８４は、編集すべき階層データ構造の初期バージョンを作成するために、分析エンジン８３を起動して、初期テキストオファリング（本明細書に記載するように、ＨＤＳ／ルールハンドラ８２を介して、初期階層データ構造の要素のフィルタリング、ランキング、多様化、選択、順序変更および削除を含むことができる）を決定することができる。これは、ユーザが、ＴＣＧシステム８０が行うことができる最良のオファーから直ちに開始することができるように、最高ランクの組み合わせを選択することを含むことができる。上述したように、階層データ構造に対する実際の修正は、ＨＤＳ／ルールハンドラ８２（ＨＤＳエディタ８４のフロントエンドへのデータ管理バックエンドとして機能する）によって管理される。ユーザは、ＨＤＳエディタ８４を介して、この提案された階層データ構造を常に変更することができる。再編集の間、ＨＤＳエディタ８４は、以下により詳細に説明されるように、前のセッションからの保存された編集コンテキストを使用することができる。

ここで、ＨＤＳエディタ８４のための例示的なユーザインターフェースを示す図１２Ａ、１２Ｂ、および１２Ｃを参照する。図１２Ａは、会社のオファーされたサービス（［Ａ］）を示すプレイスホルダーの編集を示す。図１２Ｂは、ブラウジング画面を示す。「＜」および「＞」ボタン（［Ｂ］）は、異なる上面代替テキスト（すなわち、階層データ構造）に切り替えることができることが理解され得る。図１２Ｃは、選択肢が入手可能な文をマウスが通過するときの代替文選択を示し、ポップアップメニュー（［Ｃ］）は、この文に入手可能な異なる選択肢を示し、以下に説明するようにフィルタリングされ、ランク付けされ、表示された代替文は、入手可能なときに更新されたプレイスホルダー値を既に含むことも理解され得る。

さらに、特定のサブ要素（例えば、文）を再順序付けし、除去する能力が与えられると、ＨＤＳエディタ８４は、テキストキャプションを有するブロックが配置される子供のゲームと同様に、「物理的ビルディングブロック」ＵＩメタファーを提供することができることが理解され得る。

ＨＤＳエディタ８４は、ユーザが、所与のページの、所与のテキストフィールドに特有である役割毎の階層データ構造のインスタンスを編集することを可能にしてもよい。編集されたインスタンスは、役割ごとの階層データ構造を使用して初期化されるが（フィルタおよびランキングアルゴリズムに従って要素の選択が行われる）、後でこのフィールドの特定の階層データ構造インスタンスに変更が加えられる。

ＨＤＳエディタ８４はまた、編集コンテキストの保存を提供してもよい。次に、単純な階層データ構造に対する変更を示す図１３Ａ～図１３Ｄを参照する。図１３Ａでは、トップレベルは、Ａ、Ｂ、およびＣである３つの可能な選択肢（「選択１つ」ノードを介して）を有する。これらの各々は、サブノード（例えば、文）、Ａ１－Ａ３、Ｂ１－Ｂ２及びＣ１－Ｃ４のシーケンスから成る。

ユーザは、（例えば）例えば、Ａ２を削除し、残りのＡ１およびＡ３の順序を変更し、図１３Ｂに示すように（Ａ１、Ａ２、Ａ３の代わりに）最終シーケンスＡ３、Ａ１を生成することによって、代替Ａから開始することができる。この後、ユーザは、自分の意識を変更し、代替Ｃに切り替え、それを編集することができ、例えば、図１３Ｃに示すように、Ｃ２およびＣ３の順序を変更することができる。

ＨＤＳエディタ８４は、編集コンテキストを保存することができ、その結果、ユーザが代替Ｃを残し、代替物Ａに戻ることを決定した場合、ユーザは、図１３Ｄに示すように、元の代替Ａ（Ａ１、Ａ２、Ａ３）ではなく、編集された代替Ａ（すなわち、Ａ３、Ａ１）に戻ることになる。

コンテキストは、すべてのレベルで保存され、したがって、各サブツリーは、その変更と共に保存されることが理解され得る。コンテキストはフィールドごとのインスタンスであるため、（たとえば）ｅストアに複数の商品ページがあり、それぞれに商品説明が含まれている場合、コンテキストは商品説明のフィールドインスタンスごとに個別に保存される。ＨＤＳ／ルールハンドラ８２は、現在のユーザの選択を記述する「視覚コンテキスト」と共に、保存されたコンテキストをＨＤＳローカルインスタンスリポジトリ５２３３に保存してもよい。

本明細書で上述したように、階層データ構造の元のバージョンは、単純なツリーではなく、有向非巡回グラフ（複数フック／反復サブツリーを有する）とすることができる。ユーザが、ＨＤＳエディタ８４を介して階層データ構造の編集を開始すると、それらが参照される場所ごとに（ＨＤＳインスタンスクリエータ８４２によって）反復されたサブツリーが複製される。これは、繰り返されるサブツリーの異なるコピーが異なる方法で修正され得るために必要とされる。複製は、実際に繰り返されるサブツリーが実際に修正されるまで（すなわち、ＨＤＳインスタンスクリエータ８４２における遅延評価の形成を使用して）遅延させることができる。

ユーザは、編集を完了し、テキストをテキストフィールドに生成するようにテキストジェネレータ８６に指示するように、ＨＤＳエディタ８４に指示することができる。ＨＤＳエディタ８４はまた、必要なプレイスホルダーの一部が満たされていない場合、またはユーザのビジネスに関係のない（典型的には）元のサンプルテキストを含んでいる場合に、（ポップアップまたは他のユーザインターフェース要素を介して）ユーザに警告することができる。

本明細書で上述したように、ＨＤＳエディタ８４は、分析エンジン８３を呼び出して、関連するテキストフィールドのための適切な階層データ構造を決定することができる。

オプション選択ノードの場合、ＨＤＳ／ルールハンドラ８２は、提案されたサブノードをフィルタリングし、順序付けし、多様化することができ、任意の兄弟の「順序集合」ノードの場合、セットおよびその順序を提供することができることが理解され得る。プレイスホルダーの場合、分析エンジン８３は、本明細書で上述したように利用可能な情報から、プレイスホルダーのために選択された値を決定することができる。

明確にするために、所与の役割のための初期（記憶された）階層データ構造定義は、完全なノードタイプ情報（すなわち、どのサブノードが所与のノードに関連し、何がその順序であるか）を含むことが理解され得る。しかし、ＨＤＳエディタ８４は、分析エンジン８３を呼び出して、どの組み合わせを表示することができるかを決定することができ、ＨＤＳ／ルールハンドラ８２は、格納された階層データ構造インスタンスを修正することができ（本明細書で上述したように）、どの代替案を様々なレベルで、どの順序でユーザに提供するかを決定することができる。

上述したように、分析エンジン８３は、ＨＤＳエディタ８４が初期化されたとき（表示された初期選択のための推奨を提供するため）にアクティブ化され、また、ＨＤＳエディタ８４を介した階層データ構造編集中にオンラインで操作される。これは、ユーザに表示される選択肢に影響を与えるために行われ（例えば、ユーザが与えられた文章の代替案をレビューしたい場合）、また、おそらくは、推奨もしくは自動的に動作に影響を与えるために行われる（例えば、ユーザがある編集変更を行った場合、ルールは、自動的に追加の変更を提供したり、それに影響を与える可能性がある）。

ここで、分析エンジン８３の要素を示す図５を参照する。分析エンジン８３は、ＡＩ／ＭＬエンジン８３１、ＮＬＰエンジン８３２、およびルールエンジン８３３をさらに含んでもよい。上述のように、分析エンジン８３は、人工知能／機械学習、自然言語処理、および一般規則に基づいて、ＴＣＧシステム８０のためのすべてのサービスを提供する。そのタスクの中で、分析エンジン８３は、役割決定部８１がテキストフィールドの役割を選択するのを助け、所与のフィールドおよび役割のための階層データ構造を選択することができる。

ＨＤＳ／ルールハンドラ８２の要素は、以下でより詳細に説明するように、ＡＩ／ＭＬエンジン８３１、ＮＬＰエンジン８３２、またはルールエンジン８３３によって実行される分析の結果としてアクティブ化され得ることが理解され得る。

分析エンジン８３は、ＴＣＧ分析ルールリポジトリ５２５に格納されたルールを使用することができる。ルールは、ＷＢＳベンダスタッフ６１によって事前に定義されてもよく、または、以下でより詳細に説明されるように、人工知能、機械学習、ウェブサイト分析、集合ソーシングなどの結果として作成され、開発されてもよいことが理解され得る。

上述したように、例えば、テキストのまだ選択されていない要素を編集するときにユーザに提供される代替テキストオプションのランキングおよび表示順序を変更する分析エンジン８３によって評価される入力データに対する変更に起因して、各ツリーレベルにおける提案された代替案が、時間とともに変化し得るので、分析エンジン８３は、再編集において再び使用され得る。例としては、ユーザがまだ編集していない階層データ構造の領域に影響を与える（他のユーザが行った選択の分析に基づく）所定のテキストオプションの人気の変化が挙げられる。

ダバーサファイアー（ｄｉｖｅｒｓｉｆｉｅｒ）８２６は、ＨＤＳリポジトリ５２３から、これらの代替に基づく代替の階層データ構造を選択して、様々なテキストオプションのセット、即ち、互いにおよび現在選択されているテキストから異なるテキストオプションのセットを提供することができる。

ルールはまた、適応を推奨または影響を与える可能性があることが理解され得る。すなわち、ノードアダプター８２７は、既存のノードに対するテキスト変更の結果として、ノード／サブツリーの除去のような階層データ構造に対する変更を適用する可能性がある（そして、ルールアダプター８２８は、分析エンジン８３の結果として、それに応じてルールに対する変更を適応させる可能性もある）。したがって、分析エンジン８３は、ユーザが「私たちについて」フィールド内の「カンパニー説明」ノードを編集するときに、カンパニーアドレスを指定したので、別個の樺パニーアドレス文はもはや必要ではないと判断する可能性がある。

分析エンジン８３はまた、利用可能な入力情報に基づいて上記のいずれかを決定する１組のルールを適用してもよい。分析エンジン８３は、フィールドの役割ならびに追加情報（内部データ収集部９５１および外部データ収集部９５２によって収集されたものなど）を決定する際に使用するために、役割決定部８１について上で詳述した情報のいずれかを含む入力情報を分析することができる。そのような情報は、予め定義されたテンプレート情報、ユーザ指定情報、サイトジェネレーションシステム情報、および、現在のおよび他のフィールド（依然として分析され得る非テキストフィールド、例えば、画像理解アルゴリズムによって分析される画像フィールドを含む）のフィールド情報を含むことができる。分析エンジン８３によって考慮される（および収集部９５によって収集される）他の入力情報はまた、プロフィール情報、現在のおよび他のサイト（ウェブサイト構築システムの内部および外部の両方）の分析、関連するフィールド情報、ならびにフィールドに入力された任意のドラフトテキストを含む、ウェブサイト構築システムのユーザおよび他のユーザから収集される情報を含み得る。

分析エンジン８３はまた、サイトの成功に関する情報、収集されたビジネスインテリジェンス（ＢＩ）および使用統計、特定のページの人気に関する情報、および明示的なエンドユーザランキングに関する情報（例えば、ブログおよびサポート記事システムなどの「このページがどれくらい有用であったか」という質問を有するシステムにおいて）などの、現在のサイトのエンドユーザ、またはシステム２００の他のサイト（例えば、同じテンプレートまたは階層データ構造を使用するサイト）からの（集合ソースデータ収集部９５３によって収集された）集合ソース情報を含む情報を分析することができる。それはまた、ユーザの関与の測定に関する情報（例えば、読書時間、マウスの動き、ページスクロール、目の動き検出のようなユーザの生物学的フィードバック追跡）、およびコンテンツのユーザ理解を示す暗黙の試験に関する情報（システムまたは設計された）を分析してもよい。

当然のことながら、システム２００は、集合ソースデータの収集および分析のために、米国特許第１０，０７３，９２３号に記載されている技術のいずれかをさらに使用することができる。したがって、分析エンジン８３は、デザイナ情報およびエンドユーザ情報の両方を含む、他のユーザが行ったことからの情報を評価し、分析することができる。このような分析は、大規模な統計ベースで実行することができ、ユーザのプライバシー、匿名性、および法的権利に左右される。

また、分析エンジン８３は、ウェブページ、ウェブサイト、またはウェブサイト構築システムの要素に含まれる明示的なヒントを用いて（例えば、内部データ収集部９５１を介して）調べて、その動作をガイドすることもできる。そのようなヒントは、フィールド役割決定／選択、所与の役割／フィールドの階層データ構造選択、および特定の階層データ構造（最初と編集中の両方）の階層データ構造カスタマイズなど、分析エンジン８３によって実行される任意の分析および推奨に適用可能であり得る。このようなヒントは、ウェブサイトレベルのデータまたは設定において、追加のサイト情報（サイトに関連するコード、メタデータなど）とともに、サイトジェネレーションシステム４０のエンティティ（コンテンツ要素／タイプ、レイアウト要素／タイプなど）、テンプレート（すべてのレベルで、サイト、ページ、セクションなど）コンポーネント定義およびインスタンスおよび追加されたアプリケーション（サードパーティアプリケーションやリストアプリケーションなど）などを用いて、ユーザプロフィールに含めることができる。

したがって、例えば、ルールは、欧州の不動産弁護士と比較して、米国の不動産弁護士の「私たちのサービス」ページ内のパラグラフまたは特定の文に対する異なる好ましい順序を指定することができる。このようなルールは、あらかじめ定義されているか、または関連するユーザによる実際の使用パターンの分析に基づいて動的に作成される場合がある。

ルールはまた、水平であってもよいことが理解されるであろう。すなわち、与えられたフィールドＸに対する推奨は、選択された要素と、フィールドＸの他の領域または別のフィールドＹ（ウェブサイトの同じページまたは別のページ）に対するそれらの順序に依存してもよい。例えば、分析エンジン８３は、所与のフィールドに対するユーザの回答に基づいて、ユーザが特定のスタイルを好むことを検出し、そのスタイルを他のフィールドに対しても優先順位付けすることができる。ＴＣＧ分析ルールリポジトリ５２５はまた、文が一緒に最もよく機能するルールを含むことができる。

本明細書で上述したように、分析エンジン８３は、（ＷＢＳベンダスタッフ６１によって作成され、ＴＣＧ分析ルールリポジトリ５２５に格納される）事前定義ルールのリポジトリを使用することができ、これもまた、本明細書で以下でより詳細に説明するように動的に修正することができる。ＡＩ／ＭＬエンジン８３１は、人工知能および機械学習（および特にディープラーニング）を使用して、入力データおよびユーザアクティビティを分析し、ノードフィルタリング、ランキング、多様化、および順序付けに関するＨＤＳ／ルールハンドラ８２のための推奨を生成することができる。ＡＩ／ＭＬエンジン８３１は、システム２００との対話およびその学習プロセスに基づいて、それ自体のデータ構造（ニューラルネットワークモデルなど）を修正することができることを理解されたい。ＡＩ／ＭＬエンジン８３１は、このようなデータ構造の更新されたバージョンをＭＬ／ＡＩリポジトリ５１５またはＣＭＳ５５内の別個の一致する対応するリポジトリに保存することもできる。

また、システム２００の使用が増加するにつれて、入力情報は、母集団の追加の（より詳細である）セグメントに対して統計的に有意になることも理解され得る。したがって、例えば、いったん十分な数の建設関連ビジネスがシステム２００を使用すると、システム２００は、そのようなビジネスにより良い結果を提供することができる。このプロセスは、正のフィードバックループのセットを生成し、それによって、システム２００を改善する。

このシナリオでは、ウェブサイト構築システムとデザイナとの間およびデザイナとエンドユーザとの間の、２つのレベルのフィードバックループであり得ることも理解され得る。各レベルに対して、システム２００は、各ユーザセグメントに対してループが展開されるにつれて、複数のフィードバックループを展開することができる。フィードバックループは、システム２００の挙動の結果として、システム２００の一般的な対話（例えば、デザイナ６２とサイトユーザ６３との間の対話）の特性とみなされ得ることが理解される。したがって、これは、システム２００の特定のサブシステム要素によってサポートされる明示的な要素ではない。

本明細書で上述したように、分析エンジン８３は、ルールエンジン８３３、ならびにＡＩ／ＭＬエンジン８３１およびＮＬＰエンジン８３２に基づく分析、ならびにデータ収集部９５によって収集されたデータを使用して、ＨＤＳ／ルールハンドラ８２が、階層データ構造、ノード、および役割のフィルタリング、ランキング、および順序付けに関してどのように挙動するべきかに関する決定を行うことができる。しかしながら、システム２００は、ノードアダプター８２７およびルールアダプター８２８を使用して、階層データ構造および場合によってはそれに関連するルールを拡張または修正するために、収集されたデータを使用することもできる。

特に、システム２００のユーザの数（およびそれらから収集されたデータの量）が増加するにつれて、分析エンジン８３は、特定のパターンを検出するためにユーザ応答を分析することができる。これらには、特に、生成されたテキストに加えられた繰り返しの編集変更が含まれる場合がある。

例えば、所与の階層データ構造ノードＸ（例えばパラグラフ）は、この順序で３つのサブノードＡ、Ｂ、Ｃ（例えば文）のシーケンスから構成される。ノードＸを選択したユーザの編集操作に基づいて、それらの大部分は３つのサブノードの順序をＣ、Ａ、Ｂに変更することが分かった。さらに、この反復的な編集動作は、多数のユーザ（これも過半数である）間で一貫していると想定される。このようなシナリオでは、分析エンジン８３は、階層データ構造が、Ｃ、Ａ、Ｂシーケンスを最初に提示するために再配置されるべきであると判断し、ほとんどのユーザによって実行されるであろう余分な編集操作を節約し、それに応じてＨＤＳ／ルールハンドラ８２に指示することができる。

ユーザの数が増えるにつれて、分析エンジン８３は、ユーザの特定のパラメータ（ユーザのプロフィールの詳細またはユーザのサイトに関する情報など）を考慮に入れたより細かい分析を行うことができることが理解され得る。したがって、スペインの十分な数の写真家が所与の編集変更を行う場合、分析エンジン８３は、スペインの写真家でもある将来のユーザに、繰り返される変更を事前に適用することを決定することができる。

階層データ構造に対する変更は、サブノードの順序付け（またはオプションのフィルタリングとランキング）の変更に限定されないことが理解され得る。ノードアダプター８２７は、（場合によっては、デリーター８２２を使用して）サブノードを削除することもできる。

また、典型的な実施形態では、テキストの追加は、ＨＤＳエディタ８４（これは、典型的には、既存の階層データ構造の操作に限定される）を介して行うことができないことも理解され得る。しかしながら、ユーザは、視覚エディタコーディネータ８５を介して階層データ構造に組み込むことができるＷＢＳエディタ３０を介して追加テキストを追加することができる。

ＮＬＰエンジン８３２は、共通のテーマおよびテキストを検出するため、または共通の分母テキストを生成するために、複数のユーザによって同じ階層データ構造ノードに追加されたテキストを分析してもよく、このような分析の結果を使用して、ノードアダプター８２７およびルールアダプター８２８に、追加のノードおよび場合によっては関連するルールを追加する階層データ構造を拡張するように命令してもよい。

したがって、統計的に有意な数の写真家が、３つの可能な類似の文のうちの１つをそのビジネス説明に追加する場合、ＮＬＰエンジン８３２は、その自然言語分析を通してそのような発生を検出し、「ビジネス説明」ノードを拡張する追加のサブノードを作成するようにノードアダプター８２７に命令することができる。このシナリオでは、ノードアダプター８２７は、１つの「いずれかの」サブノードと３つの終了ノード（３つのセンテンス用）を作成することができる。

代替実施形態では、分析エンジン８３は、コンテンツオーサリング（ａｕｔｈｏｒｉｎｇ）（したがって、階層データ構造の作成および保守）を担当するＷＢＳベンダスタッフ６１に上記の分析の結果を提示することができる。次いで、ＷＢＳベンダスタッフ６１は、この情報を使用して、任意の階層データ構造を更新するかどうかを決定することができる。

そのような結果は、（例えば）使用統計、（上述のようなＢＩ（Ｂｕｓｉｎｅｓｓ Ｉｎｆｏｒｍａｔｉｏｎ）またはエンドユーザフィードバックに基づく）使用されるテキストの成功情報、または本明細書で上述したようなデータ収集部９５によって収集される他のタイプの情報を含むことができることが理解され得る。

また、情報には、特定の役割およびテンプレート内の特定のテキストコンポーネントのためにユーザが記述したテキストの共通の変形を含めることができる。このような情報は、ＨＤＳリポジトリ５２３の作成および保守を大幅に容易にすることができることが理解され得る。例えば、ＷＢＳベンダスタッフ６１はまた、人気のない、またはうまくいかないオプションを手動で削除したり、一般的に使用されるテキストに基づいて新しい代替テキストを作成したりすることができる。

ユーザは、ＷＢＳエディタ３０を使用して包含ページを編集するときに、生成されたテキストを編集することができることが理解され得る。このような編集は、生成されたテキストと元の階層データ構造と階層データ構造のサブ要素の選択と順序付けとの間の接続を切断する可能性がある。

ただし、このようなビジュアル編集が実行されると、テキストフィールドは、フィールドの保存された階層データ構造編集コンテキストと一致しない。ユーザがＨＤＳエディタ８４に戻り、テキストを再作業したい場合、ＷＢＳエディタ３０でなされた変更を失う可能性がある。さらに、可能性のある編集変更のいくつかは、例えば、２つの文を単一の結合文にマージするなど、階層データ構造で表現できない。

ＨＤＳエディタ８４に戻る能力は、場合によっては重要であり得ることが理解され得る。したがって、システムは、テキスト構造とＨＤＳ構造との間の対応を維持することを試みるために、視覚編集コーディネータ８５を使用してもよい（部分的にのみである場合）。

プレイスホルダーの場合、システム２００は、視覚編集中にプレイスホルダー情報の継続的な保守をサポートすることができる。したがって、視覚編集コーディネータ８５は、偶発的な変更に対してプレイスホルダーをロックすることができ、したがって、プレイスホルダーの値をリフレッシュすることができる（たとえば、基礎となるデータが変更された場合）。代替として、システム２００は、プレイスホルダーが基礎となる値の変更時にリフレッシュされることを可能にし得るが、ユーザに警告し、ＷＢＳエディタ３０において修正されたこれらのプレイスホルダーにフラグを立てる。

代替の実施形態では、ＨＤＳエディタ８４は、ＷＢＳエディタ３０と一体化されてもよい。単一結合エディタは、階層データ構造エディタサービスと視覚エディタサービスの両方を提供することができる。データ構造の基礎となる同じテキストフィールドは、階層的なデータ構造情報とテキストフィールド情報の両方を表す。一部の編集操作（文の結合など）では、このエリアの階層データ構造の関連付けが解除される場合がある。視覚編集コーディネータ８５は、編集変更のトラッキングを提供することができ、ユーザが（フィールド全体ではなく）特定のテキストエリアに対して「生成されたテキストに戻る」ことを適用することができる。

別の代替実施形態では、システム２００は、フィールド内テキスト構造から階層データ構造へのバックポインタを維持することができる。したがって、編集中になされた変更は、視覚編集コーディネータ８５にも送られ、（可能であれば）フィールドの階層データ構造インスタンスに適用される。これは、後で階層データ構造に再適用される一連の編集変更レコードを保存することによって実装することもできる。

コンテンツが最終化され、テキストフィールドについてユーザによって承認されると、テキストジェネレータ８６は、階層データ構造を線形化し、テキストフィールドについてのテキストを生成することができる。これは、サイトジェネレーションシステム４０を用いてサイトが生成されたとき、またはサイトデザイナ６２およびサイトユーザ６３に表示されるウェブページに他の方法で挿入されたときに、ウェブサイト上に表示されるテキストである。

また、システム２００は、同じテンプレートを使用して作成された異なるサイトが異なるテキストコンテンツを使用し、あまり類似していないので、構築されているウェブサイトのＳＥＯ（検索エンジン最適化）にも役立ち得ることが理解され得る。ＨＤＳ ＳＥＯビルダー８８は、さらに、サイトの階層データ構造インスタンスで利用可能な情報を使用して、特定のＳＥＯ関連情報（キーワードやメタデータなど）を、関連スパイダー／検索エンジンによってアクセスされるために、生成／編集されたサイトに注入することができる。

一実施形態では、階層データ構造は、すべてのレベルのノードに関連付けられた（例えば、文または段落の一部またはすべてに関連付けられた）ＳＥＯキーワードを含むことができる。指定されたノードを選択すると、そのノードに関連付けられたＳＥＯキーワードがページのＭＥＴＡヘッダに追加される。

ＮＬＰエンジン８３２は、ＷＢＳエディタ３０で生成されたテキストを編集する際に追加または修正されるテキストからＳＥＯキーワードを抽出することもできる。特に、システム２００は、ＴＣＧシステム８０によって生成されたテキストに対してＷＢＳエディタ３０で行われた変更が、現在のサイトに特定または関連してより重要であると想定してもよい。従って、このような特定のテキスト修正は、ページのＭＥＴＡヘッダのためのキーワード抽出の良い候補であり得る。

別の実施形態では、システム２００は、サイトの事前定義されたＳＥＯキーワードおよびメタデータからの情報を使用してもよい。これらは、ユーザ又はテンプレートの一部（サイト又はその他）によってユーザによって選択されることができる（例えば、ベーカリーテンプレートは“パン、ケーキ、・・・”を有することがある）。このような情報は、ＨＤＳ／ルールハンドラ８２によって階層データ構造ノードの任意のフィルタリング、ランキング、および順序付けを決定するために、データ収集部９５によって収集された情報に追加することができる。

システム２００はまた、ウェブサイト構築システムの外部のサービスを用いてテキストキット抽出およびキット再統合能力を提供することによって、統合をサポートしてもよい。テキストキットインターフェース８９は、ウェブサイト上のそれらの場所に関連するすべてのテキストフィールドコンテンツとアソシエーションを含むテキストキットを抽出し、再統合することができる。抽出されたテキストには、現在のフィールドコンテンツまたは関連する階層データ構造の拡張部分のみが含まれる場合がある。キットには、単一のテキストフィールドまたは複数のテキストフィールドに関する情報を含めることができる。

キットはまた、さらなる関連情報を含み得る。例えば、キットは、ビジネス分類情報（ビジネスファミリーおよび業界など）または他のメタデータを含むことができる。この情報は、翻訳市場サイト（Ｆｉｖｅｒｒ．ｃｏｍなど）によって使用されて、必要なサービス要求を分類し、市場内の正しい場所にルーティングすることができる。テキストキットの再統合は、修正されたテキストキットを抽出し、ウェブサイトに再統合することを必要とすることが理解され得る。

関連のあるウェブサイト構築システムはまた、並列に格納された複数のバージョン（例えば、言語ごと）を有するテキストフィールドを有することをサポートしてもよい。このようなシナリオでは、このような複数のバージョンをサポートするために、階層データ構造とテキストキットも必要になる場合がある。

ＴＣＧシステム８０（および特にそれと対話するときのユーザのアクティビティおよび選択）は、任意の特定のテキストフィールドに直接関連しない部品を含む、システム２００の他の部品に影響を及ぼし得ることが理解される。影響を受けるエリアは、システム２００の他の部分と同様に、ＷＢＳエディタ３０との追加のユーザ対話を含むことができる。

例えば、ＴＣＧシステム８０内のユーザのアクティビティは、システム２００が非テキストフィールドのためのコンテンツをユーザに提供する方法に影響を与え得る。したがって、「私たちについて」フィールドのテキストコンテンツを作成するときにユーザが行う選択は、非テキストフィールドに対してユーザに提供される画像、ビデオ、またはオーディオのタイプに影響を与える可能性がある。影響は、（例えば）提供されたメディアオブジェクトの選択およびランキングに対する変更すること、または提供されたメディアコレクションに追加のメディアソースを含めること、を含むことができる。所与のフィールド／役割について「私たちについて」の階層データ構造における、「サービス指向」のブランチを（例えば）選択したユーザ（所与のビジネス／業界において）に、人間の対話を強調するメディアを提供することができる。一方、この階層データ構造における「製品指向」のブランチを選択したユーザには、所与の業界に典型的な製品を強調するメディアを提供することができる。

このような「リバースヒント」のメカニズムには、組み合わせることもできる多くの可能な実施形態があり得ることが理解され得る。一実施形態では、ＴＣＧシステム８０の要素（ノードなど）は、ＷＢＳエディタ３０に提供されるリバースヒントを含むことができ、これらは、テキストジェネレータ８６を介して生成された線形化テキストと共にＷＢＳエディタ３０に提供することができる。別の実施形態では、ＷＢＳエディタ３０は、（例えば）提案されたメディアの推奨コンポーネントを含むことができる。リコメンダ（ｒｅｃｏｍｍｅｎｄｅｒ）は、分析エンジン８３と（またはＣＭＳ５５の適切な要素と直接）協議して、ＷＢＳエディタ３０内で作業する編集ユーザにメディア推奨を提供することができる。

したがって、システム２００は、階層データ構造の事前定義されたコンテンツ、追加のシステム適応、ユーザによる操作および選択、プレイスホルダーに入力された情報、およびユーザによる書き込みまたは編集に基づく自由テキストの組み合わせである最終的なテキストを有するウェブサイト構築を支援するために、テキストを生成することができる。

上述したように、ＴＣＧシステム８０は、ウェブサイト上に法律テキスト及び法律文書を生成する。ウェブサイト法律文書の例は、サイトポリシーである。ウェブサイトの作成中に、ＴＣＧシステム８０は、ウェブサイトおよびそのビジネスに関連する内部システムおよび外部環境データの両方を収集し、次いで、ウェブサイトテキストおよび法律文書を生成するために利用される。出願人は、ＴＣＧ、および他の最新技術のテキストおよび文書生成システムが、「押す時に正しい（ｃｏｒｒｅｃｔ ａｔ ｔｈｅ ｔｉｍｅ ｏｆ ｇｏｉｎｇ ｔｏ ｐｒｅｓｓ）」テキストおよび文書を生成するように設計されていることを認識した。

しかし、出願人は、サイトポリシー及びその他の法律文書は、適用され得る法律および法規の変更と、その他の外部環境上の考慮事項と、により頻繁に変更される可能性があるリビング（ｌｉｖｉｎｇ）文書であり、パラグラフの追加もしくは編集を必要としたり、文書全体に影響を与える可能性があることを認識している。ビジネスオーナーおよびウェブサイトデザイナ６２は、彼らのリビング法律文書のコンテンツに影響を及ぼす可能性があるこれらの変化を絶えずモニターしなければならない。

出願人はさらに、ＷＢＳ２００を使用して自身または他のビジネスオーナーのためのウェブサイトを構築し、ホストするウェブサイトデザイナ６２が、文書更新をトリガすることができる上述の法的環境のような外部環境への変更だけでなく、ビジネス環境およびウェブサイト環境への変更にも関心があることを認識した。ビジネス環境は、ビジネス操作、類似のビジネスにおける他のデザイナのビジネス操作、および製品ポートフォリオを包含することができ、例えば、カンパニーは、新しい製品ラインの販売を開始することができ、または新しい地理での操作を開始することができる。ウェブサイト環境は、デザイナのウェブサイトポートフォリオ、ＷＢＳ上の他のデザイナのウェブサイト、および／または外部ウェブサイトからの資料であってもよい。法的環境は、さらに、規制、指令、ガイドライン、標準、業界標準などを包含することができる。

次に、図１４および図１５Ａ、１５Ｂを参照する。図１４は、上記の図２と同様であるが、本発明の好ましい実施形態に従って構成され、動作するリビング文書ジェネレータ（ＬＤＧ：Ｌｉｖｉｎｇ Ｄｏｃｕｍｅｎｔ Ｇｅｎｅｒａｔｏｒ）３００を示す。ＬＤＧ３００は、ＷＢＳ２００内に実装され、ＴＣＧシステム８０と同様に、ＬＤＧエンジン３０１およびＴＣＧシステム８０’を備える。ＴＣＧシステム８０’はＴＣＧシステム８０と同じ要素の多くを利用するので、同様の要素は同様の参照番号を有する。

ＬＤＧ３００内で、ＴＣＧシステム８０’は、上述したような方法で、リビング文書３０２および他の法律文書のための初期ＬＤＧセクションテキスト３０３を生成することができる。本発明の好ましい実施形態によれば、ＬＤＧエンジン３０１は、リビング文書３０２内のＬＤＧセクションテキスト３０３の構成に影響を及ぼす可能性がある任意の変更について、内部ソースおよび外部ソースの両方をモニターすることができる。次に、ＬＤＧエンジン３０１は、以下で説明するように、影響を受けたユーザの通知と文書の更新とを調整することができる。

図１５Ａおよび図１５Ｂは、ＴＣＧシステム８０’及びＬＤＧエンジン３０１の詳細を示す。ＬＤＧエンジン３０１は、ＬＤＧコーディネータ３０５と、ポリシー知識エンジン（ＰＫＥ）３０６と、ＰＫＥリポジトリ３０８と、ＬＤＧタガー（ｔａｇｇｅｒ）３１５と、ＬＤＧタグリポジトリ３０９と、ＬＤＧユーザリポジトリ３１０と、モニタリングエンジン３１２と、通知エンジン３１３と、ワークフローエンジン３１４とを備える。ＬＤＧエンジン３０１は、ＴＣＧシステム８０’の複数の部分、特定ＨＤＳ／ルールハンドラ８２’、ＨＤＳ／ルールコーディネータ８７’、分析エンジン８３’、データ収集部９５’、ＨＤＳエディタ８４’、およびＣＭＳ５５とインターフェースすることができ、これについては以下でより詳細に説明する。

本明細書で上述したように、ＴＣＧシステム８０’は、ウェブサイトデザイナ６２が、サイトポリシー、使用文書の条件、条件文書、プライバシーポリシー文書、クッキーポリシー文書、配送ポリシー、ＧＤＰＲ関連の必要なサイト文書、ユーザ生成コンテンツポリシー、エンドユーザライセンス契約（ＥＵＬＡ：ｅｎｄ－ｕｓｅｒ ｌｉｃｅｎｓｅ ａｇｒｅｅｍｅｎｔｓ）、返品および返金ポリシーなどのリビング文書３０２を作成するのを助けることができる。これらの文書は、多数のＬＤＧセクションテキスト３０３を含み、その正確な数および内容は、前述したように、内部要因および外部要因に依存する。出願人は、リビング文書は政策文書に限定されるものではなく、ウェブサイトの一部である非法律文書にも限定されることをさらに認識している。

ＴＣＧ８０と同様に、ＴＣＧ８０’は、空のフィールドを含むテンプレートをデザイナ６２に提示することができ、これらのフィールドの各々を埋めるテキストブロックを選択するプロセスを通してデザイナを導くことができる。ＴＣＧシステム８０’は、多くの方法を利用して、ユーザに最良のテキスト選択を提供する。

ＬＤＧ３００は、ＴＣＧジェネレータ８０と同様の方法で動作し、ＬＤＧエンジン３０１を追加して、初期リビング文書を作成し、リビング文書３０２に影響を及ぼす可能性のある内部および外部環境変化をモニターし、リビング文書に対する影響および必要な変更を分析し、文書デザイナ６２およびＨＤＳクリエータ（通常はＷＢＳベンダスタッフ６１）に、それらの文書に影響を及ぼす可能性のあるマテリアル変更を通知し、ＨＤＳおよび文書に対する更新を調整する。

リビング文書３０のＬＤＧセクションテキスト３０３で使用することができる基礎となるＨＤＳテキスト構造は、本明細書で上述したプレイスホルダーと同様に、（例えば、ビジネス名のための）プレイスホルダーを含むことができる。ＴＣＧ８０’は、収集された情報を使用して文書を生成するときに、これらのプレイスホルダーを満たすことができる。

ＬＤＧ３００は、典型的には、初期推奨のみを形成するベース文書（例えば、ポリシー）又は文書のセットを出力する。ウェブサイトデザイナ６２は、典型的には、出力文書およびそれらの最終フォームの編集を担当する。そのような編集は、ＷＢＳベンダが、デザイナ６２によって編集された最終ポリシー文書のコンテンツに対して法的に責任を負わないことを確実にするために必要とされ得る。

ＬＤＧ３００は、特定の目的のために複数のリビング文書３０２を組み込んだサイトをサポートすることができる。例えば、ＬＤＧ３００は、異なる地理的または管制的区域から到着するサイトのエンドユーザに表示される複数の利用規約文書の作成をサポートしてもよい。この差異は、単純なローカリゼーション（ｌｏｃａｌｉｚａｔｉｏｎ、例えば、翻訳）から、異なる地域の法律および規則への適合までの範囲であり得る。この場合、ＬＤＧ３００は、ウェブサイトデザイナ６２が、彼のサイトが異なるエンドユーザに対して異なるバージョンを表示するルールを定義することを可能にすることができ、これらのルールは、アクセスしているエンドユーザから実行時に収集された情報を考慮することができる。あるいは、ＬＤＧ３００は、そのようなバージョン選択を制御するルールを指示することができる。

分析エンジン８３’およびＰＫＥ３０６は、ＬＤＧセクションテキスト３０３を追加するためにどのＨＤＳテキストセクションがデザイナ６２に提示されるか、およびそれらをどのように順序付けおよび選択するか（階層の複数のレベルを含む）を一緒に決定することができる。分析エンジン８３’およびＰＫＥ３０６は、さらに、ＡＩ／機械学習技術（ディープラーニングの使用を含む）を使用することができ、デザイナコミュニティ（現在のデザイナ６２および他のデザイナ）によって以前に提案されたリビング文書６２に対して行われた変更および編集について訓練されて、将来よりよい推奨を行うことができる。そのような訓練は、特定のデザイナカテゴリについてエンジンをより良く訓練するために、特定のデザイナパラメータ（ＡＩ訓練データ特徴として）を組み込むことができる。

ＬＤＧエンジン３０１は、デザイナ６２によって選択された要素（リビング文書３０２全体またはＬＤＧセクションテキスト３０３またはそのサブセクション）に注目することができ、後に、法律、規則および規制に対して行われた変更を追跡することができる。したがって、ＬＤＧエンジン３０１は、デザイナ６２によって実際に使用されるこのリビング文書３０２に関連する、基礎となる法律、規則、および規制の変更が行われた（または行われようとしている）ときに、ＷＢＳ２００の関連するデザイナ６２に警告することができる。そのような警告は、単に有益なものから、様々な関連するポリシーの新しいバージョンまたは修正されたバージョンを実際に示唆するものまでの範囲であってもよい。

同様に、ＬＤＧ３００は、デザイナ６２による直接的な（明示的である）報告を可能にするメカニズムを介して、またはユーザによって行われた編集および選択の（ルールまたはＡＩ／ＭＬベースの）分析を介して、規制に対する変更を検出することができる。例えば、国Ｘの多くのユーザが、新しい規制Ｙを参照するために、提案された利用規約文書を修正した場合、ＬＤＧ３００は、警告又はＷＢＳベンダスタッフ６１への他の通知を生成する可能性がある。そのような通知は、内部で分析され、提案されたテキストベース、ならびにテキスト選択および順序付けのための規則を改善するために使用され得る。デザイナ６２は、評価されるべき変更を報告するだけであって、基礎となるルールリポジトリを直接変更することは許されないことが理解され得る。代替実施形態では、ＬＤＧ３００は、特定のユーザが、ＷＢＳベンダスタッフ６１からの承認を条件として、ルールリポジトリの特定の部分を編集することを可能にすることができる。

ＬＤＧエンジン３０１は、デザイナ６２が異なるポリシー文書セクションおよびサブセクションを理解するのを助ける追加の説明資料または文書を生成することができる。このように生成された材料は、テキスト編集環境（一般的なＷＢＳエディタ３０またはＨＤＳエディタ８４’）でアクセス可能であってもよい。そのような材料は、デザイナ６２のパラメータ（例えば、デザイナ６２の熟練度レベルまたは他の詳細）に合わせて調整されてもよい。

データ収集部９５’は、分析エンジン８３’およびＰＫＥ３０６によって使用される追加の内部データ、外部データ、および派生データを収集して、どの要素を（生成されたリビング文書３０２に）含めるか、およびそれらをどのように配置するかを決定することができる。

内部データの例は、以下を含むことができる。
（１）デザイナ６２に属するウェブサイトで使用されるＷＢＳ要素の分析（ブログ、ｅコマース・・・）。これは、垂直要素または機能、サードパーティアプリケーション、ＷＣＡ、または挿入されたコンポーネントとすることができる。そのような要素は、関連する文書のためのそれら自体のヒントまたはサブセクションを提供することができる。例えば、ブログ要素またはＴＰＡは、使用文書の用語、プライバシーポリシーなどのために、それ自体のヒントおよび／または挿入されたテキスト要素を有することができる。ＷＢＳ要素は、所与の文書種別の異なった異種に対して異なった提案されたテキスト要素を提供することがある（例えば、プライバシーポリシーの複数のカテゴリがあることがあり、所与のＴＰＡは、これらのカテゴリの各々に挿入されるべき特定のテキストを持つことがある。
（２）ウェブサイト要素に関連するコードまたは他の機能要素の分析。
（３）フォーム、アンケートインターフェース、ビジュアルウィザード、チャットインターフェースまたは音声インターフェースなどの情報入力インターフェースを介してデザイナ６２から収集された情報。
（４）デザイナ６２に属するサイト、特にそのビジネス運営に関する情報。これは、例えば、本出願人が共有し、参照により本明細書に組み込まれる、２０１７年６月２９日に出願された「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＴＨＥ ＣＲＥＡＴＩＯＮ ＡＮＤ ＵＰＤＡＴＥ ＯＦ ＨＩＥＲＡＲＣＨＩＣＡＬ ＷＥＢＳＩＴＥＳ ＢＡＳＥＤ ＯＮ ＣＯＬＬＥＣＴＥＤ ＢＵＳＩＮＥＳＳ ＫＮＯＷＬＥＤＧＥ」という名称の米国特許第１０，０７３，９２３号に記載されているように、ビジネスの物理的位置（またはビジネスに適用される他の関連する管轄区域情報）、ビジネス名、およびビジネス上で入手可能または収集される他の情報を含むことができる。
（５）サイト自体から収集された情報、ならびにサイト使用情報、サイト要素、またはサイト属性などのオペレーショナル情報。一例として、ＬＤＧ３００は、既存のクッキーおよびクッキーパラメータを表示するクッキーポリシー文書内のテーブルにデータを移入するために、特定のサイト上のクッキーを分析するＡＰＩを使用してもよい。ＬＤＧ３００は、それらのクッキー（クッキーの目的など）についてＷＢＳ２００で入手可能な追加情報を（テーブル内のクッキーの一部または全部について）インポートし、それを表示されたテーブルに追加することができる。
（６）製品や販売情報など、基礎となるサイトの商用ＤＢ情報。特に、当該情報には、法律文書の作成に関連する現場のクライアントの地理的（および関連する管轄区域）に関する情報、およびＷＢＳ ＣＭＳ５５で入手可能な情報が含まれることがある。

外部データソースの例は、ＥＵウェブサイトの法律ページなどのオンライン法律および規制リポジトリ、ならびにオフライン法律および規制ソースを含むことができる。

派生データソースの例は、サイトによって提供されるコンテンツまたはサービスデータに基づいて（例えば、サイトによって提供される特定の製品、製品カテゴリ、またはサービスカテゴリに基づいて）適切なポリシーおよび用語を生成する特定のＡＩ／ＭＬエンジンであってもよい。そのような導出されたデータは、ＷＢＳ２００から（おそらく構造化された方法で）利用可能であってもよい。例示的なＡＩ／ＭＬエンジンは、２０２０年５月２０日に出願された「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＩＮＴＥＧＲＡＴＩＮＧ ＯＮ－ＬＩＮＥ ＭＡＣＨＩＮＥ ＬＥＡＲＮＩＮＧ ＦＥＥＤＢＡＣＫ ＬＯＯＰ ＩＮ ＴＯ ＷＥＢＳＩＴＥ ＢＵＩＬＤＩＮＧ ＳＹＳＴＥＭ ＳＥＲＶＩＣＥＳ」という名称の米国特許出願第１６／８７８，８３１号に記載されているものであってもよく、この特許出願は、本出願人によって共有され、参照によって本明細書に組み込まれる。これは、ＬＤＧ３００が、他のユーザから収集されたデータ（および他のユーザの特定のパラメータおよび特徴）に基づいて、デザイナ６２の法的ニーズを「理解」し、より良好でより具体的なポリシーを提案するのを助けることができる。

ここで、リビング文書およびＬＤＧタグを示す図１６を参照する。文書をリビング文書にするために、ＬＤＧタガー３１５は、デザイナ６２および／またはベンダスタッフ６１がＬＤＧタグ３０４をすべてのＬＤＧセクションテキスト３０３に追加することを可能にし、ＬＤＧタグをＬＤＧタグリポジトリ３０９に格納することができる。ＬＤＧエンジン３０１は、リビング文書３０２を生存し続けるために、ＬＤＧタグ３０４内のメタデータを利用することができる。ＬＤＧタグ３０４に含まれるメタデータは、どのデータソースが分析エンジン８３’およびＰＫＥ３０６によってセクションテキスト３０３の必要性を決定するために利用されたか、どのデータソースが分析エンジン８３’およびＰＫＥ３０６によってセクションテキスト３０３の内容を成形するために利用されたか、どの領域がセクションテキスト３０３の現在のバージョンを必要とするか、このセクションテキストを更新する必要がある場合にどのデザイナ６２およびＷＢＳスタッフ６１に通知する必要があるか、および他の関連メタデータを含むことができる。ユーザデータは、ＬＤＧユーザリポジトリ３１０に格納することができる。

ＬＤＧタグ３０４は、通常、リビング文書３０２の使用および更新に関連する属性のセットを含むことができる。例えば、図１６のＬＤＧタグ３０４は、ＬＤＧセクション（「イントロダクション」）、それが関連するジオグラフィー（「ＥＵ」）、法律タイプ（「製造物責任」）、文書タイプ（「ＥＵＬＡ」）、その法律コード（「Ｘ、Ｙ、Ｚ」）、およびその法律ソース（「ＷＷＷ．ＥＵＬＡＷ．ＣＯＭ」）をリストする。その更新に影響を与える可能性がある他の属性もリストされる可能性がある。

リビング文書３０２が作成され、ＬＤＧタグ３０４が作成され、格納されると、ＬＤＧコーディネータ３０５は、実行時に作動し、ＬＤＧエンジン３０１内のモニタリング、分析、通知および更新機能を調整することができる。最初に、モニタリングエンジン３１２は、データ収集部９５’と共に、法的環境およびビジネス環境の両方における重要な変化について、オリジナルデータソースおよび任意の新しいデータソースをモニターすることができる。データソースが更新されるか、または変更が観察されると、分析エンジン８３’およびＰＫＥ３０６は、変更が重要であり、文書更新を必要とするかどうか、それらが情報であり、ユーザへの情報通知を必要とするか、または重要な変更がなく、無視することができるかどうかを分析することができる。

このモニタリングフェーズの一例は、欧州連合および米国で動作するウェブサイトのためのものであり得る。この場合、モニタリングエンジン３１２およびデータ収集部９５’は、英国が「Ｂｒｅｘｉｔ」の一部としてＥＵを離れることに投票したことを発見することができる。この作用の結果として、いくつかのウェブサイト法律文書は、変更され、更新される必要があり得る。分析エンジン８３’は、セクションテキスト３０３が適用される地理的領域を識別するＬＤＧタグ３０４内のメタデータを分析することができる。また、ビジネスオペレーショナルデータを分析して、収益レベル、製品ポートフォリオ、人員配置レベル、および他のデータを識別することもできる。ＰＫＥ３０６は、法律コードおよび規制、ならびに各セクションテキスト３０３へのそれらの適用可能性、および分析エンジン８３’からの現在のオペレーショナルパラメータを分析するシステム弁護士のようなものである。ＰＫＥ３０６がテキストセクション３０３を更新する必要があることを示す場合、ＬＤＧコーディネータ３０５は、通知エンジン３１３を介してユーザ通知を開始し、ワークフローエンジン３１４を介して更新してもよい。

ここで図１７を参照すると、２つの異なる文書３０２およびそれらに関連するＬＤＧタグ３０４Ａおよび３０４ＢのＬＤＧコンテンツが示されている。前述のＢｒｅｘｉｔの例では、ＥＵＬＡのセクションテキスト３０３のＬＤＧタグ３０４は、それが適用される領域を示すことができる。したがって、ＵＳＡ ＥＵＬＡのＬＤＧタグ３０４Ａは、ＵＳをリストするジオグラフィータグを含むことができ、ＥＵ ＥＵＬＡのＬＤＧタグ３０４Ｂは、ＥＵをリストすることができ、ＬＤＧタグ３０４Ａは、法律コード属性のＵＳコードをリストすることもでき、ＬＤＧタグ３０４Ｂは、法律コード属性のＥＵコードをリストすることができる。

ＥＵ ＥＵＬＡの場合、ＵＫのＥＵ離脱により更新が必要となることがあるが、米国カリフォルニア州ＥＵＬＡの同様のセクションテキスト３０３は更新を必要としないことがある。

モニタリングフェーズのさらなる例は、デザイナ６２がウェブサイトポートフォリオに新しい製品を追加することができる場合であり得る。モニタリングエンジン３１２およびデータ収集部９５’は、変更データを分析エンジン８３’およびＰＫＥ３０６に渡すことができる。この場合、分析エンジン８３’は、これが、製品ポートフォリオに追加される最初の、潜在的に危険な「極限のスポーツ」製品であることを識別することができる。次いで、ＰＫＥ３０６は、製品カタログのそのような変更が、新しいセクションを用語および条件文書３０２に追加することを要求し得るか、または新しい文書３０２を生成する必要があり得るかどうかを決定し得る。

別の例として、ＰＫＥ３０６は、（様々なデザイナによってセットアップされた）複数のｅショップが、特定の規制要件に関連する特定の製品（例えば、喫煙関連商品）の運搬を開始したことを検出することができる（例えば、特定の年齢を超える人にのみ販売するか、または所与の時間帯にのみ販売する）。ＰＫＥ３０６は、これらの関連する規制要件に関する完全な情報を有していなくてもよく、また、異なるｅショップ間で異なっていてもよい（例えば、それらは、異なるロケール（ｌｏｃａｌｅｓ）に関連する規則の異なるバージョンに起因する）。しかしながら、ＰＫＥ３０６は、相関を検出することができ、例えば、ｅショップが特定の製品または製品カテゴリの運搬を開始する直前または直後に、いくつかのｅショップによって関連文書３０２に行われた変更を検出することができる。ＰＫＥ３０６は、（例えば）関連するデザイナまたはウェブサイトの他のパラメータを考慮しながら、そのような相関をさらにチェックすることができる。ＰＫＥ３０６は、ＷＢＳベンダスタッフ６１または関連する他のデザイナ６２に警告することができる（以下でさらに説明する）。

ここで、リビング文書３０２の更新を示す図１８を参照する。前述の例では、ＰＫＥ３０６および分析エンジン８３’は、ＬＤＧタグ３０４内のメタデータを分析して、どの現在の用語および条件文書セクションが使用されているかを識別することができる。新しいセクションが必要とされる場合、ＰＫＥ３０６は、すべての必要な文書３０２について必要なセクションテキスト３０３を作成し、それらをＬＤＧコーディネータ３０５に渡して、通知エンジン３１３を介してユーザ通知を開始し、ワークフローエンジン３１４を介して更新することができる。図１８は、異なる地域、この場合、米国およびＥＵのための文書３０２が、ＥＵのためのこのテキストバージョンＣおよび米国のためのバージョンＲにおいて、異なるセクションテキスト３０３の追加をどのように要求し得るかを示す。

分析エンジン８３’およびＰＫＥ３０６が、リビング文書に影響を及ぼす可能性がある重要な変更を識別することができる場合、ＬＤＧコーディネータ３０５は、通知エンジン３１３を介して影響を受けるデザイナに通知することができる。通知エンジン３１３は、ＬＤＧタグ３０４内のユーザメタデータをレビューして、セクションテキスト３０３を更新する必要があるすべてのデザイナを識別することができる。通知エンジン３１３は、緊急度レベル、タイムライン、影響を受ける文書３０２およびセクションテキスト３０３、ソースデータ、および推奨アクションを含む通知を送信することができる。更新が必要とされ得る場合、通知エンジン３１３は、更新されたテキストの配信のためのタイムライン情報を含み得る。デザイナ６２は、その後、独自の更新を作成するか、システムが生成した更新を待つか、または何らかの他の応答を待つかを決定することができる。通知エンジン３１３はまた、デザイナ６２のためにシステム全体の更新を作成する必要性、および文書３０２の初期作成およびその後の更新の間に使用されるＨＤＳセクションテキストを更新する必要性の通知をＷＢＳベンダスタッフ６１に作成することもできる。これらの通知は、デザイナ６２に送られたものと同じ情報を含むことができるが、任意のテキスト変更、内部優先順位レベル、および他のベンダ固有情報を検討するために必要とされる正しい内部法律エキスパートなどの追加情報を含むこともできる。更新が作成され、承認され、アップロードされると、通知システム３１３は、更新の利用可能性と、それらの文書をどのように更新するかに関する情報とをデザイナ６２に通知することができる。他の通知もまた、間接的かつ影響を受けないデザイナ６２に対して生成されてもよい。通知は、電子メール、アプリ通知などのいくつかのチャネルを介して、およびＷＢＳエディタ３０またはシステム１００の他の部分を介して配信され得る。

ワークフローエンジン３１４は、文書３０２およびセクションテキスト３０３の更新を調整することができる。データ収集部９５’によって収集される任意の適切なデータまたはメタデータは、分析エンジン８３’およびＰＫＥ３０６に渡され得る。次いで、このデータの一部または全部を、分析エンジン８３’およびＰＫＥ３０６によって生成されたデータと共にワークフローエンジン３１４に渡すことができる。これには、ＰＫＥ３０６によって生成された推奨編集や更新が含まれる場合がある。ＰＫＥ３０６は、いくつかの方法で編集を提案することができる。これらは、例えば、テキスト相関－テキストセクションＡが既存の法規制（外部ソースから入手可能）においてテキストセクションＢに置き換えられたことを検出し、テキストＡを既存のＬＤＧ文書３０２において使用されているテキストに相関させ、Ｂに変更することを提案すること（全部または一部）に基づいてもよい。相関は、デザイナからデザイナにも行うことができる。例えば、特定のデザイナが（上述のように）特定の変更を行ったことを検出し、これらの変更が相関している（例えば、多くのデザイナがＡのバージョンをＢのバージョンに変更した）ことを検出し、この変更をＡの他の関連する発生（例えば、同じビジネスラインにおける）に適用することを提案し、上述のように、そのような提案された編集は、通常、ＷＢＳベンダスタッフ６１またはデザイナ６２によってレビューされ、正確性を保証し、責任の問題によるものである。ワークフローエンジン３１４は、次に、このデータをデザイナ６２およびＷＢＳベンダスタッフ６１に配信して、文書テンプレート、文書３０２およびセクションテキスト３０３の生成および更新に利用することができる。

ワークフローエンジン３１４はまた、更新のために、影響を受ける文書３０２およびセクションテキスト３０３をモニターしてもよい。更新がデザイナによって行われない場合、ワークフローエンジン３１４は、作用が必要であることを、通知エンジン３１３を介してデザイナ６２に通知してもよい。次に、ワークフローエンジン３１４は、ウェブサイトに対してなされた変更（例えば、提案された編集の実装）をモニターすることができ、または、ワークフローエンジン３１４は、システムから通知を受信することができる（例えば、デザイナ６２は、メッセージを受信し、それに応答した）。同様に、ワークフローエンジン３１４は、ＨＤＳおよびテンプレートが更新を必要とすることをＷＢＳベンダスタッフ６１に通知し、そのような更新が行われるかまたは拒絶されるまでそれらをリマインドすることができる。

デザイナ６２またはＷＢＳベンダ６１のいずれかが、文書３０２またはセクションテキスト３０３を更新することを望む場合、それらは、ＷＢＳエディタ３０およびＨＤＳエディタ８４’を使用することができる。ＷＢＳエディタ３０は、後続の文書３０２またはセクションテキスト３０３の作成で使用するために、これらの更新がＨＤＳエディタ８１’に保存されることなく、デザイナ６２が文書３０２およびセクションテキスト３０３に直接更新を行うことを可能にしてもよい。文書３０２は、テキストジェネレータ８６およびサイトジェネレーションシステム４０によって、上述のように生成されてもよい。そのような直接更新が行われたとき、ＰＫＥ３０６は更新された文書を分析することができ、ＬＤＧタガー３１５はＬＤＧタグ３０４を更新することができる。デザイナ６２がＨＤＳを更新し、これらの更新を利用して文書３０２およびセクションテキスト３０３を更新し、後続の文書３０２およびセクションテキスト３０３を作成したい場合、それらはＷＢＳエディタ３０またはＨＤＳエディタ８４’のいずれかを利用することができる。この場合、ＰＫＥ３０６は、ＨＤＳエントリを分析することができ、ＬＤＧタガー３１５は、ＬＤＧタグ３０４を更新することができる。その後、デザイナ６２が更新されたＨＤＳを使用して文書３０２およびテキストセクション３０３を更新するとき、ＰＫＥ３０６は文書３０２に対する更新を分析し、ＬＤＧタグ３１５はＬＤＧタグ３０４を更新することができる。この場合も、文書３０２は、テキストジェネレータ８６およびサイトジェネレーションシステム４０によって、本明細書で上述したように生成することができる。ＨＤＳエディタ８４’は、ＨＤＳの事後編集を追加した点でＨＤＳエディタ８４とは異なることが理解され得る。

ＬＤＧ３００はタグを使用するが、これは単に１つの可能な実施形態であることが理解され得る。代替実施形態では、ＬＤＧ３００は、関連付けテーブル、リンクされたエンティティグラフ（例えば、関与する様々なエンティティのリンクされたグラフ）、非明示的メカニズム（例えば、接続、オンザフライテキスト分析／理解を提供するためにＭＬエンジンを使用する）、または任意の他のメカニズムを利用することができる。

特に明記しない限り、本明細書全体を通して、「処理する」、「計算する」、「算出する」、「決定する」などの用語を利用する議論は、コンピューティングシステムのレジスタおよび／またはメモリ内の物理量などの物理量を、コンピューティングシステムのメモリ、レジスタ、または他のそのような情報記憶、伝送、または表示デバイス内の物理量として同様に表される他のデータに操作および／または変換する、クライアント／サーバシステム、モバイルコンピューティングデバイス、スマートアプライアンス、または同様の電子コンピューティングデバイスなどの任意のタイプの汎用コンピュータの作用および／またはプロセスを指すことが理解される。

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

本明細書で提示されるプロセスおよびディスプレイは、本質的に、任意の特定のコンピュータまたは他の装置に関連するものではない。様々な汎用システムが、本明細書の教示によるプログラムと共に使用されてもよく、または、所望の方法を実行するために、より特殊化された装置を構築することが便利であることが判明してもよい。様々なこれらのシステムのための所望の構造は、以下の説明から明らかになるであろう。さらに、本発明の実施形態は、任意の特定のプログラミング言語を参照して説明されない。本明細書に記述されるように、本発明の教示を実装するために、様々なプログラミング言語が使用され得ることが理解される。

本発明の特定の特徴が本明細書に例示され、説明されてきたが、多くの修正、置換、変更、および同等なが、当業者には今や思い浮かぶであろう。従って、特許請求の範囲は、そのような修正及び変更全てを本発明の技術思想及び技術的範囲に含まれるものとして保護することを意図していることを理解されたい。

Claims (18)

1. ウェブサイト構築システム（ＷＢＳ）であって、
   前記ＷＢＳのウェブサイト用のリビング文書を生成するリビング文書ジェネレータであって、前記リビング文書は、前記リビング文書の少なくとも１つのセクションの使用および更新に関連する属性のセットを表すための少なくとも１つのタグであって、メタデータを含む少なくとも１つのタグを含む、リビング文書ジェネレータと、
   前記ＷＢＳの内部および外部のソースから前記リビング文書の変更をモニターするモニタリングエンジンと、
   前記メタデータをレビューし、前記モニタリングエンジンの出力に従って前記リビング文書を更新する必要があるデザイナであって、前記ＷＢＳを使用するデザイナを識別する通知エンジンであって、更新されたリビング文書の配信用のタイムラインおよび緊急度レベルも提供する、通知エンジンと、
   を備えるウェブサイト構築システム。
2. 前記少なくとも１つのタグは、セクションのタイプ、それが関連する地理、法律のタイプ、文書のタイプ、それに関連する法律コード、および／またはその法的ソースをリストするタグのうちの１つである、
   請求項１に記載のウェブサイト構築システム。
3. 前記リビング文書ジェネレータは、前記少なくとも１つのタグを前記少なくとも１つのセクションに関連付けるタグ付け装置を含む、
   請求項１に記載のウェブサイト構築システム。
4. 前記リビング文書、前記デザイナについての情報、および、前記少なくとも１つのタグを格納する少なくとも１つのデータベースをさらに含む、
   請求項１に記載のウェブサイト構築システム。
5. 前記モニタリングエンジンの出力に従って、前記リビング文書のセクションテキストコンテンツに対する変更を推奨するポリシー知識エンジンをさらに含む、
   請求項１に記載のウェブサイト構築システム。
6. 前記ポリシー知識エンジンは、前記セクションテキストコンテンツに対する変更に従って前記少なくとも１つのタグを更新する、
   請求項５に記載のウェブサイト構築システム。
7. 前記リビング文書ジェネレータは、前記リビング文書に関するＷＢＳ情報およびビジネスオペレーショナル情報を決定するために、前記ＷＢＳの内部データソースと、外部オンラインデータソースおよび外部オフラインデータソースの少なくとも１つと、を分析する分析エンジンを含む、
   請求項１に記載のウェブサイト構築システム。
8. 前記外部オンラインデータソースおよび外部オフラインデータソースの少なくとも１つは、法律および規制オンラインおよびオフラインリポジトリのうちの少なくとも１つを含む、
   請求項７に記載のウェブサイト構築システム。
9. 前記分析エンジンは、分析に従ってセクションテキストコンテンツを生成する機械学習エンジンを含む、
   請求項７に記載のウェブサイト構築システム。
10. ウェブサイト構築システム（ＷＢＳ）用の方法であって、
    前記ＷＢＳのウェブサイト用のリビング文書を生成するステップであって、前記リビング文書は、前記リビング文書の少なくとも１つのセクションの使用および更新に関連する属性のセットを表すための少なくとも１つのタグであって、メタデータを含む少なくとも１つのタグを含む、生成するステップと、
    前記ＷＢＳの内部および外部のソースから前記リビング文書の変更をモニターするステップと、
    前記メタデータをレビューし、前記モニターするステップの出力に従って前記リビング文書を更新する必要があるデザイナであって、前記ＷＢＳを使用するデザイナを識別するステップであって、更新されたリビング文書の配信用のタイムラインおよび緊急度レベルも提供する、ステップと、
    を有する方法。
11. 前記少なくとも１つのタグは、セクションのタイプ、それが関連する地理、法律のタイプ、文書のタイプ、それに関連する法律コード、および／またはその法的ソースをリストするタグのうちの１つである、
    請求項１０に記載の方法。
12. 前記生成するステップは、前記少なくとも１つのタグを前記少なくとも１つのセクションに関連付けるステップを含む、
    請求項１０に記載の方法。
13. 前記リビング文書、前記デザイナについての情報、および、前記少なくとも１つのタグを格納する少なくとも１つのデータベースをさらに含む、
    請求項１０に記載の方法。
14. 前記モニターするステップの出力に従って、前記リビング文書のセクションテキストコンテンツに対する変更を推奨するステップをさらに含む、
    請求項１０に記載の方法。
15. 前記推奨するステップは、前記セクションテキストコンテンツに対する変更に従って前記少なくとも１つのタグを更新する、
    請求項１４に記載の方法。
16. 前記生成するステップは、前記リビング文書に関するＷＢＳ情報およびビジネスオペレーショナル情報を決定するために、前記ＷＢＳの内部データソースと、外部オンラインデータソースおよび外部オフラインデータソースの少なくとも１つと、を分析するステップを含む、
    請求項１０に記載の方法。
17. 前記外部オンラインデータソースおよび外部オフラインデータソースの少なくとも１つは、法律および規制オンラインおよびオフラインリポジトリのうちの少なくとも１つを含む、
    請求項１６に記載の方法。
18. 前記分析するステップは、分析に従ってセクションテキストコンテンツを、機械学習を用いて生成するステップを含む、
    請求項１６に記載の方法。