(57)【要約】      （修正有）【課題】コマース・アーキテクチャのためのグラフィカルユーザインタフェース（ＧＵＩ）をセットアップするためのユーザインタフェースを提供する。【解決手段】第１データソースを追加するための第１ボタンと、第２データソースを追加するための第２ボタンとを表示するＧＵＩを提供するステップ３９１０、第１及び、第２ボタンを通し応答をうけとるステップ３９２０、第１データスキーマ及び第２データスキーマのビューを提供するステップ３９３０、第１データスキーマの少なくとも１つのオブジェクトを、第２データスキーマの少なくとも１つのオブジェクトとマッピングするステップ３９４０と、第２データスキーマの少なくとも１つのオブジェクトの単一のエンティティビューを提供するステップ３９５０から構成される。【選択図】図３９
2020053052.tif 000002
【特許請求の範囲】
【請求項１】
コンピューティングデバイスによって、第１データソースを追加するための第１ボタンと、第２データソースを追加するための第２ボタンとを備えるグラフィカルユーザインタフェース（ＧＵＩ）を提供するステップと；
前記コンピューティングデバイスによって、前記第１ボタンを介して前記第１データソースを追加するための第１応答と、前記第２ボタンを介して前記第２データソースを追加するための第２応答を受け取るステップと；
前記コンピューティングデバイスによって、第１データスキーマ及び第２データスキーマのビューを提供するステップであって、前記第１データスキーマは、前記第１又は第２データソースからの少なくとも１つのオブジェクトを含み、前記第２データスキーマは、カノニカルデータモデルであるステップと；
前記コンピューティングデバイスによって、前記第１データスキーマの前記少なくとも１つのオブジェクトを前記第２データスキーマの少なくとも１つのオブジェクトにマッピングするステップと；
を含む、方法。
【請求項２】
前記コンピューティングデバイスによって、前記第２データスキーマの前記少なくとも１つのオブジェクトにマッピングされた前記第１データスキーマの前記少なくとも１つのオブジェクトのビジュアル論理コネクタを表示するステップを更に含み、前記ビジュアル論理コネクタは、前記第２データスキーマの前記少なくとも１つのオブジェクトに対する前記第１データスキーマの前記少なくとも１つのオブジェクトの関係を示す、
請求項１に記載の方法。
【請求項３】
前記コンピューティングデバイスによって、前記第２データスキーマの前記少なくとも１つのオブジェクトの単一のエンティティビューを提供するステップ、
を更に含む、請求項１に記載の方法。
【請求項４】
単一のエンティティビューを提供するステップは、
複数のフォーマッティングルールに基づいて、前記第１データスキーマの前記少なくとも１つのオブジェクトを変換するステップと、
複数のマッチングルールに基づいて、前記第１データスキーマの前記少なくとも１つのオブジェクトと前記第２データスキーマの前記少なくとも１つのオブジェクトとの間の一致を決定するステップと、
複数の更新ルールに基づいて、前記第１データスキーマの前記少なくとも１つのオブジェクトのマスターレコードとして前記第２データスキーマの前記少なくとも１つのオブジェクトを更新するステップと、
を更に含む、請求項３に記載の方法。
【請求項５】
前記コンピューティングデバイスによって、データ管理要求に応答して、前記第２データスキーマの前記少なくとも１つのオブジェクトを管理するステップ、
を更に含む、請求項１に記載の方法。
【請求項６】
前記データ管理要求は、要求者によって提示される、
請求項５に記載の方法。
【請求項７】
前記データ管理要求は、システム推奨によって提示される、
請求項５に記載の方法。
【請求項８】
前記第２データソースを追加するための前記第２ボタンを含むＧＵＩを提供し、前記第２データソースは第三者データソースである、
請求項１に記載の方法。
【請求項９】
前記第２ボタンを介して前記第２応答を受け取り、アプリケーション・プログラミング・インタフェース（ＡＰＩ）を介して前記第三者データソースを追加する、
請求項８に記載の方法。
【請求項１０】
前記コンピューティングデバイスによって、顧客に対するデータソースのカテゴリのマッピングを表示するステップを更に含み、前記カテゴリは、該カテゴリ内のデータソースの量を視覚的に表示する、
請求項１に記載の方法。
【請求項１１】
前記コンピューティングデバイスによって、前記第１及び第２データソースについての合計レコード及び固有レコードを表示するステップ、
を更に含む、請求項１に記載の方法。
【請求項１２】
前記コンピューティングデバイスによって、検索要求に応答して複数のレコードを表示するステップであって、前記複数のレコードの各々は、対応するデータソースを表示する、
請求項１に記載の方法。
【請求項１３】
メモリと；
前記メモリに結合される少なくとも１つのプロセッサと；
を備え、前記少なくとも１つのプロセッサは、
第１データソースを追加するための第１ボタンと、第２データソースを追加するための第２ボタンとを備えるグラフィカルユーザインタフェース（ＧＵＩ）を提供し、
前記第１ボタンを介して前記第１データソースを追加するための第１応答と、前記第２ボタンを介して前記第２データソースを追加するための第２応答を受け取り、
第１データスキーマ及び第２データスキーマのビューを提供することであって、前記第１データスキーマは、前記第１又は第２データソースからの少なくとも１つのオブジェクトを含み、前記第２データスキーマは、カノニカルデータモデルであり、
前記第１データスキーマの前記少なくとも１つのオブジェクトを前記第２データスキーマの少なくとも１つのオブジェクトにマッピングする、
ように構成される、システム。
【請求項１４】
前記少なくとも１つのプロセッサは、前記第２データスキーマの前記少なくとも１つのオブジェクトの単一のエンティティビューを提供するように更に構成される、
請求項１３に記載のシステム。
【請求項１５】
前記単一のエンティティビューを提供することは、
複数のフォーマッティングルールに基づいて、前記第１データスキーマの前記少なくとも１つのオブジェクトを変換し、
複数のマッチングルールに基づいて、前記第１データスキーマの前記少なくとも１つのオブジェクトと前記第２データスキーマの前記少なくとも１つのオブジェクトとの間の一致を決定し、
複数の更新ルールに基づいて、前記第１データスキーマの前記少なくとも１つのオブジェクトのマスターレコードとして前記第２データスキーマの前記少なくとも１つのオブジェクトを更新すること、
を含む、請求項１４に記載のシステム。
【請求項１６】
前記少なくとも１つのプロセッサは、データ管理要求に応答して、前記第２データスキーマの前記少なくとも１つのオブジェクトを管理するように更に構成される、
請求項１３に記載のシステム。
【請求項１７】
前記第２データソースを追加するための前記第２ボタンを含むＧＵＩを提供し、前記第２データソースは第三者データソースである、
請求項１３に記載のシステム。
【請求項１８】
前記第２ボタンを介して前記第２応答を受け取り、アプリケーション・プログラミング・インタフェース（ＡＰＩ）を介して前記第三者データソースを追加する、
請求項１７に記載のシステム。
【請求項１９】
コンピューティングデバイスによって実行されると、該コンピューティングデバイスに、
第１データソースを追加するための第１ボタンと、第２データソースを追加するための第２ボタンとを備えるグラフィカルユーザインタフェース（ＧＵＩ）を提供する動作と；
前記第１ボタンを介して前記第１データソースを追加するための第１応答と、前記第２ボタンを介して前記第２データソースを追加するための第２応答を受け取る動作と；
第１データスキーマ及び第２データスキーマのビューを提供する動作であって、前記第１データスキーマは、前記第１又は第２データソースからの少なくとも１つのオブジェクトを含み、前記第２データスキーマは、カノニカルデータモデルである動作と；
前記第１データスキーマの前記少なくとも１つのオブジェクトを前記第２データスキーマの少なくとも１つのオブジェクトにマッピングする動作と；
を含む動作を実行させる命令を有する、有形のコンピュータ読取可能デバイス。
【請求項２０】
前記第２データスキーマの前記少なくとも１つのオブジェクトの単一のエンティティビューを提供する動作、
を更に含む、請求項１９に記載のコンピュータ読取可能デバイス。
【請求項２１】
前記単一のエンティティビューを提供する動作は、
複数のフォーマッティングルールに基づいて、前記第１データスキーマの前記少なくとも１つのオブジェクトを変換する動作と、
複数のマッチングルールに基づいて、前記第１データスキーマの前記少なくとも１つのオブジェクトと前記第２データスキーマの前記少なくとも１つのオブジェクトとの間の一致を決定する動作と、
複数の更新ルールに基づいて、前記第１データスキーマの前記少なくとも１つのオブジェクトのマスターレコードとして前記第２データスキーマの前記少なくとも１つのオブジェクトを更新する動作と、
を更に含む、請求項２０に記載のコンピュータ読取可能デバイス。
【請求項２２】
前記コンピューティングデバイスによって、データ管理要求に応答して、前記第２データスキーマの前記少なくとも１つのオブジェクトを管理する動作、
を更に含む、請求項１９に記載のコンピュータ読取可能デバイス。
【請求項２３】
前記第２データソースを追加するための前記第２ボタンを含むＧＵＩを提供し、前記第２データソースは第三者データソースである、
請求項１９に記載のコンピュータ読取可能デバイス。
【発明の詳細な説明】
【背景技術】
【０００１】
関連出願の相互参照
本出願は、２０１８年９月２４日に出願された米国仮特許出願第６２／７３５，６７１号の優先権の利益を主張し、参照によってその全体が組み込まれる。
【０００２】
企業は、自社の製品やサービスの消費者についてのこれまで以上に多くのデータにアクセスできる。顧客関係管理（ＣＲＭ）システムの目的は、サプライチェーン内のすべてのサービスレベルで、このデータを効率的に管理し、容易にアクセスして共有できるようにすることである。しかしながら、従来のデータベース又はＣＲＭシステムでは、異なる分離されたソースからの顧客データを統合し、消費者についてのマスターレコードを作成することはできない。また、従来のシステムは、マルチテナントシステムにおいて、クエリを実行し、データを読み出し又は書き込むために、どこからデータを得るかを決定することも困難である。従来のシステムの別の問題は、データの起源（data  provenance）、すなわち、レコード内のデータの１つ以上のソースを決定することである。さらに、従来のシステムは、データのための監査ログを提供することに苦労してきた。データの起源と監査ログは、プライバシー法を遵守するために不可欠である。従来のシステムはまた、異なる時間スケールのデータを統合し、異なるソースからのデータにアクセスし、データを比較し、それを調和（reconciling）させるという問題にも直面する。
【発明の概要】
【０００３】
典型的なコマース／マーケティングシステムは、高ボリュームで低品質の消費者データを低ボリュームで高品質のデータに変換するために、管理者がコードを作成することを必要とする。このプロセスは、時間がかかり、高価で、エラーを起こしやすい可能性がある。顧客がオンライン・チェックアウト・カートにアイテムを残したままにするとき、すなわち、カートを放置するとき、管理者は、そのようなイベントを追跡して消費者へのフォローアップの電子メールを生成するために、大量のデータを解析するために特定のコードを書かなければならない。さらに、データは、独自のアプリケーション・プログラミング・インタフェース（ＡＰＩ）を有する異なるソースから来るので、管理者は、従来的に、各システムのＡＰＩを学んで、異なるシステムとインタフェースしてデータを取り出すためのクエリをプログラムしなければならないであろう。加えて、ほとんどのコマース・アーキテクチャシステムは、ポイントアンドクリック・ユーザインタフェースを提供する代わりに、システム管理者が多くの機能をプログラムする必要がある。本明細書に提示された実施形態は、特に、少なくともこれらの問題に対する解決策を提供する。
【図面の簡単な説明】
【０００４】
本明細書に組み込まれ、明細書の一部を構成する添付の図面は、本実施形態を例示しており、以下の説明とともに、本実施形態の原理を説明し、当業者が本実施形態を作成して使用することを可能にするために更に役立つ。
【０００５】
【図１】いくつかの実施形態による、Salesforce（登録商標）Customer  360のホームページのグラフィカルユーザインタフェース（ＧＵＩ）スクリーンショットを示す図である。
【０００６】
【図２】いくつかの実施形態による、Salesforceデータソースと接続している、Salesforce  Customer  360のＧＵＩスクリーンショットを示す図である。
【０００７】
【図３】いくつかの実施形態による、統合ガイド（Integration  Guides）を使用してクロスクラウドユースケースをセットアップするSalesforce  Customer  360のＧＵＩスクリーンショットを示す図である。
【０００８】
【図４】いくつかの実施形態による、統合ガイド（Integration  Guides）を使用してコマース用サービスの有効化（Enable  Service  for  Commerce）をセットアップするコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【０００９】
【図５】いくつかの実施形態による、コマース用サービスの有効化（Enable  Service  for  Commerce）をセットアップするためにデータソースを接続するコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００１０】
【図６】いくつかの実施形態による、例示の顧客のためにデータソースを接続するためのアクセスを認証するコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００１１】
【図７】いくつかの実施形態による、例示の顧客のための接続されたデータソースについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００１２】
【図８】いくつかの実施形態による、データソース・スキーマとカノニカルデータモデルとの間のデータマッピングのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００１３】
【図９】いくつかの実施形態による、データソース・スキーマの１つの展開されたオブジェクトの下の例示のフィールドについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００１４】
【図１０】いくつかの実施形態による、カノニカルデータモデルの１つの展開されたエンティティの下の例示の属性についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００１５】
【図１１】いくつかの実施形態による、カノニカルデータモデルの展開されたエンティティに対する１つの属性の追加についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００１６】
【図１２】いくつかの実施形態による、データソース・スキーマの１つの展開されたオブジェクトの下の１つのフィールドを、カノニカルデータモデルのマップされたオブジェクトの下の追加された対応する属性にマッピングする、コマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００１７】
【図１３】いくつかの実施形態による、データソース・スキーマの１つの展開されたオブジェクトの下のフィールドと、カノニカルデータモデルのマッピングされたオブジェクトの下の追加された対応する属性との間のタイプ不一致についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００１８】
【図１４】いくつかの実施形態による、データソース・スキーマの下のフィールドと、カノニカルデータモデルの下の対応する属性との間のタイプ不一致を解決するための変換ルールセットアップについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００１９】
【図１５】いくつかの実施形態による、データ不一致を解決した後のデータソース・スキーマとカノニカルデータモデルとの間のデータマッピングについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００２０】
【図１６】いくつかの実施形態による、単一エンティティビューのためのデータ準備のコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００２１】
【図１７】いくつかの実施形態による、データ準備のための例示のデフォルト値をセットアップするコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００２２】
【図１８】いくつかの実施形態による、データ準備のために必要なセットアップを完了するコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００２３】
【図１９】いくつかの実施形態による、単一エンティティビューのマッチングルールについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００２４】
【図２０】いくつかの実施形態による、１つのマッチングルールに対する例示のマッチング基準のセットアップについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００２５】
【図２１】いくつかの実施形態による、１つのマッチングルールを編集するコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００２６】
【図２２】いくつかの実施形態による、マッチングルールの編集後のマッチプレビューについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００２７】
【図２３】いくつかの実施形態による、編集後のマッチングルールについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００２８】
【図２４】いくつかの実施形態による、単一エンティティビューのためのデータ調和ルールについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００２９】
【図２５】いくつかの実施形態による、１つの例示属性に対するデータ調和ルールについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００３０】
【図２６】いくつかの実施形態による、例示の属性に対するデータ調和ルールを編集するコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００３１】
【図２７】いくつかの実施形態による、例示の属性に対するデータ調和ルールの編集後のコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００３２】
【図２８】いくつかの実施形態による、データスチュワードシップについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００３３】
【図２９】いくつかの実施形態による、データスチュワードシップに対する例示の要求タイプの詳細についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００３４】
【図３０】いくつかの実施形態による、データスチュワードシップに対する例示の要求の詳細についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００３５】
【図３１】いくつかの実施形態による、データスチュワードシップの検索機能についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００３６】
【図３２】いくつかの実施形態による、データスチュワードシップの検索結果についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００３７】
【図３３】データスチュワードシップのための例示の顧客プロファイルについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００３８】
【図３４】いくつかの実施形態による、データソースとシステムとの間の接続についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００３９】
【図３５】いくつかの実施形態による、例示の第三者データをシステムに接続するコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００４０】
【図３６】いくつかの実施形態による、ＡＰＩを介して例示の第三者データをシステムに追加する詳細についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００４１】
【図３７】いくつかの実施形態による、第三者データソースとＡＰＩの接続についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００４２】
【図３８】いくつかの実施形態による、システムと、第三者データソースを含むデータソースとの間の接続についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【００４３】
【図３９】いくつかの実施形態による、コマース・アーキテクチャＧＵＩをセットアップするためのフローチャートの例を示す図である。
【００４４】
【図４０】本明細書で提示される様々な実施形態を実施するために使用され得る例示のコンピュータシステムを示す図である。
【００４５】
本実施形態の特徴及び利点は、図面と併せて考えると、以下で説明される詳細な説明からより明らかになるであろう。図面では、全体を通して同様の参照符号が対応する要素を識別する。図面において、同様の参照番号は一般に、同一の要素、機能的に類似の要素及び／又は構造的に類似の要素を示す。要素が最初に現れる図面は、対応する参照番号の左端の数字で示される。
【発明を実施するための形態】
【００４６】
本明細書では、コマース・アーキテクチャ・ユーザインタフェースのための方法、システム及び／又はコンピュータプログラム製品の実施形態及び／又はそれらの組合せ及び副次的組合せが提供される。
【００４７】
本明細書に開示されるコマース・アーキテクチャのグラフィカルユーザインタフェース（ＧＵＩ）を使用して、ユーザは、ポイント・アンド・コネクトＡＰＩを介して第三者データソースを含む様々なデータソースを接続し、様々なデータソースからの消費者データをカノニカルデータモデルのレコードにマッピングし、ポイント・アンド・クリック・ユーザインタフェース及びアウト・オブ・ボックス機能を介して単一エンティティビューのためにマッチングルール及びデータ調和ルールを定義することができる。また、データスチュワードシップ（data  stewardship）は、顧客要求又はシステム推奨に応じて、カノニカルデータモデルにおける消費者データのマスターレコードのクエリ結果だけでなくデータ管理を提供することができる。図１〜図３８は、いくつかの実施形態による、コマース・アーキテクチャＧＵＩをセットアップするステップを提供する。
【００４８】
本明細書において、「カノニカル（canonical）」とは、ソフトウェア内のオブジェクト又はオブジェクトのリストのように、データの順序又は構造を表現する標準的な形式又は標準的な方法を指す。ここで、「カノニカル」は、一般的に、カノニカルデータスキーマを記述するために、より具体的には、他のデータスキーマのためのテンプレートを提供するカノニカルデータモデルを記述するために使用されてもよい。対照的に、「アカノニカル（acanonical）」とは、テナント固有のデータソース・スキーマのように、データの順序又は構造が一意又は非標準的な表現を有するような表現を指す。また、次の用語を使用してデータスキーマ内の要素を記述することができる。
【００４９】
データソース：顧客情報のデータベースを管理する部門、子会社又はベンダー、あるいは一般的にテナント等の企業組織；テナントからの顧客情報の特定のデータベース
【００５０】
テナント：ＣＲＭシステムで管理されるデータセンターを有する企業組織
【００５１】
スキーマ：例えばモデルの形式のデータの表現（例えば構造及び／又はデータベース編成）
【００５２】
オブジェクト：顧客データのカテゴリ、例えば具体的には連絡先情報又はアカウント情報等のように、ＣＲＭシステムにおいてコンピュータによって使用され得る何かの記述を提供するデータ構成又はレコード；オブジェクトは、情報のサブカテゴリのいくつかのフィールドを含んでよい
【００５３】
フィールド：カノニカルエンティティの属性やデータソースオブジェクト内のデータのセクション等のように、情報のプレースホルダとして機能するデータレコードの一部
【００５４】
属性：カノニカルスキーマのエンティティ内のように、フィールドの特性又は内容を決定する情報の断片
【００５５】
エンティティ：関連する又は類似の属性のフィールドを含むデータレコード
【００５６】
グループ：一緒に近接して配置されるもの及び／又は一緒にクラス分類されるもののように、接続された関係にある複数のエンティティ
【００５７】
図１は、いくつかの実施形態による、エンプティ状態、すなわち、コマース・アーキテクチャをセットアップするプロセスの開始時における、Salesforce（登録商標）Customer  360のグラフィカルユーザインタフェース（ＧＵＩ）のスクリーンショットを示す。エンプティ状態では、ユーザは、接続するデータソース、例えばSalesforceデータ（Salesforce  Data）１０１又は他のデータ（Other  Data）１０３を選択することができる。他のデータ１０３は、MuleSoft（登録商標）等の第三者データとすることができる。セットアップ（Setup）１０５は、現在のセットアップステップが強調表示されたコマース・アークテキチャのセットアップステップを含むことができる。そのようなセットアップステップには、例えばホーム（Home）、統合ガイド（Integration  Guides）、データソース（Data  Sources）、データマッピング（Data  Mapping）、データスチュワードシップ（Data  Stewardship）、並びにデータ準備（Data  Preparation）、マッチングルール（Matching  Rules）、データ調和ルール（Data  Reconciliation  Rules）及び顧客更新ルール（Customer  Update  Rules）を含む単一エンティティ／カスタマービュー（Single  entity/customer  view）がある。ＧＵＩの最上部にある情報ヘッダ１０２は、現在のセットアップステップに関連するメッセージを提示することができ、例えばHomeステップでは、セットアップをガイドするために「Welcome  to  Salesforce  Customer  360」というメッセージを提示することができる。開始（Get  Started）ボックス１０７には、ワールドワイドサービスの有効化（Enable  Worldwide  Service）、コマースジャーニーの有効化（Enable  Commerce  Journeys）、健康コミュニティの有効化（Enable  Health  Communities）といった、共通のユースケースを有効にする統合ガイドを含めることができる。そして、対応するガイド上のワン・クリックにより、サービスのセットアップをすぐに開始することができる。共通パートナー（Common  Partners）１０９は、接続することができる共通パートナー、例えばLoyaltyMe及びAmadeusを表示することができる。Salesforce  Customer  360のＧＵＩは、従来のシステムでは管理者が機能をセットアップするために多くをプログラムする必要がある、ほとんどのコマース・アーキテクチャシステムについて、ポイント・アンド・クリックのユーザインタフェースを顧客に提供することができる。
【００５８】
図２は、いくつかの実施形態による、Salesforceデータソースと接続している、Salesforce  Customer  360のＧＵＩのスクリーンショットを示す。図２の例では、Salesforceデータ（Salesforce  Data）２０１は、セールスクラウド（Sales  Cloud）２１１、コミュニティクラウド（Community  Cloud）２１３、マーケティングクラウド（Marketing  Cloud）２１５、コマースクラウド（Commerce  Cloud）２１７及びサービスクラウド（Service  Cloud）２１９のような異なるソースからのデータを統合することができる。戻る（Back）ボタン２０３をクリックした後、ＧＵＩは、図１に図示されるホーム画面に戻ることができる。
【００５９】
統合ガイド
図３は、いくつかの実施形態による、統合ガイド（Integration  Guides）を使用してクロスクラウドユースケースをセットアップするSalesforce  Customer  360のＧＵＩスクリーンショットを示す。統合ガイドは、図３の中央に示されるように、コマース用サービスの有効化（Enable  Service  for  Commerce）３０１、コマースジャーニーの有効化（Enable  Commerce  Journeys）３０３、経験洞察の有効化（Enable  Experience  Insights）３０７、オンボーディングの有効化（Enable  Onboarding）３０９、従業員アプリケーションの有効化（Enable  Employee  Apps）３１１及びゲストジャーニーの有効化（Enable  Guest  Journeys）３１３を含むことができる。このステップでは、セットアップ３０５内の統合ガイド（Integration  Guides）を強調表示することができる。統合ガイドは、ユーザが、ユーザとユーザの消費者について評価する時間を短縮することを助けることができる。合理化された統合ガイドにより、小売、ヘルスケア、金融サービス等における共通のクロスクラウドのユースケースを可能にすることができる。また、情報ヘッダ３０２は、統合ガイドのためのメッセージを更新することができる。コマース用サービスの有効化３０１のガイド開始（Start  Guide）をクリックすると、ＧＵＩはコマース・アーキテクチャのセットアップを開始することができる。
【００６０】
図４は、いくつかの実施形態による、統合ガイドを使用してコマース用サービスの有効化をセットアップするコマース・アーキテクチャＧＵＩスクリーンショットを示す。コマース用サービスの有効化の現在のステップが４０１に示されており、コマース用サービスの有効化４０１の下のガイド変更（Change  Guide）をクリックすると、ユーザは他の統合ガイドに変更することができる。完了したタスク及び完全に必要とされるタスクが、進行を示すバー４０７とともに４０３で表示され得る。次の推奨アクション（Next  Recommended  Action）４０９は、サービスをセットアップするための次のアクション、例えば図４の例では「データソースに接続（Connect  Data  Sources）」を提供することができる。追加のアクション（Additional  Actions）４１１は、サービスをセットアップするのに必要なアクションを列挙し、例えば強調表示されている「データソースの追加（Add  your  data  sources）」、「カノニカルデータモデルへのレビュー及びマップ（Review  and  map  to  the  canonical  data  model）」、「データイベントの構成（Configure  Data  Events）」、「統合ルールのレビュー及びカスタマイズ（Review  and  Customize  Integration  Rules）」並びに「テスト、展開及びインポート（Test,  Deploy,  and  Import）」といった、次のアクションを強調表示することができる。
【００６１】
データソースの追加
図５〜図７は、いくつかの実施形態による、データソースに接続しているコマース・アーキテクチャＧＵＩスクリーンショットを示す。図５は、いくつかの実施形態による、コマース用サービスの有効化をセットアップするためにデータソースを接続するコマース・アーキテクチャＧＵＩスクリーンショットを示す。セットアップ５０５のデータソース（Data  Sources）タブが強調表示されており、情報ヘッダ５０２もデータソースの追加（Add  a  Data  Source）に更新されている。コマース用サービスの有効化をセットアップする例では、少なくとも２つのデータソース、すなわちコマースクラウド（Commerce  Cloud）５０３とサービスクラウド（Service  Cloud）５０７に接続する必要がある。コマースクラウド５０３の接続（Connect）をクリックすると、コマースクラウドを追加するプロセスが開始されることになる。
【００６２】
図６は、いくつかの実施形態による、例示の顧客のためにデータソースを接続するためのアクセスを認証するコマース・アーキテクチャＧＵＩスクリーンショットを示す。データソースに接続することは、ユーザからの認証を必要とする。図６の例では、Crocs（登録商標）  USのコマースクラウドに接続するには、ユーザの基本情報へのアクセス、ユーザのデータへのアクセス及び管理等のような、認証データ６０１へのアクセスのユーザの許可が必要である。拒否（Deny）６０３をクリックすると、アクセスを許可せずに統合プロセスを終了する。許可（Allow）６０７をクリックすると、Crocs  USのコマースクラウドからのアクセスを許可し、データをシステムに統合することになる。
【００６３】
図７は、いくつかの実施形態による、例示の顧客のための接続されたデータソースのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図７の例では、接続されたデータソースが、データソース（Data  Sources）７０３内に列挙されている。データソースの合計数及びデータソースのソートが、すべてのデータソース（All  Data  Sources）７０７の下に表示されている。各データソース７０９は、データソースの名前（Name）、タイプ（Type）、ドメイン（Domain）及びプロダクション（Production）を含むことができる。また、各データソース７０９は、名前フィールド内に、データソースのタイプを示す関連アイコン、例えばコマースクラウドに対するショッピングカート及びサービスクラウドに対するハートを有することができる。図像は、ＧＵＩ内での選択に利用可能な多数のデータソースに基づくことができる。データソースは、ＣＲＭシステムの様々なアプリケーションに基づいてよく、各アプリケーション及び各データソースは、異なる及び／又は特有の目的を有してよい。データソースの追加（Add  Data  Source）７１１をクリックすることによって、より多くのデータソースをシステムに追加することができる。いくつかの実施形態によると、コマース・アーキテクチャを設定するために、少なくとも１つのコマースクラウド及び１つのサービスクラウドをシステムに接続する必要がある。少なくとも１つのコマースクラウド及び１つのサービスクラウドを追加した後、次のステップは、情報ヘッダ７０２に示されているように、データをマップ（Map  Data）７１３をクリックすることによってデータをマッピングすることである。
【００６４】
データマッピング
図８〜図１５は、いくつかの実施形態による、データマッピングを設定するコマース・アーキテクチャＧＵＩスクリーンショットを示す。データマッピング及び変換の例は、参照によってその全体が本明細書に組み込まれる２０１８年７月１７日出願の米国特許出願第１６／０３７，４３５号にみられる。
【００６５】
図８は、いくつかの実施形態による、データソース・スキーマとカノニカルデータモデルとの間のデータマッピングのコマース・アーキテクチャＧＵＩスクリーンショットを示す。このステップでは、ＧＵＩの左側にあるセットアップ８０５の下のデータマッピング（Data  Mapping）タブを強調表示することができる。そして、ＧＵＩの最上部にある情報ヘッダ８０２は、マッピング推奨に関するガイダンスをユーザに提供することができる。図８の例では、ユーザには、標準属性定義に基づいて一束のデフォルトマッピングが行われること、追加のカスタム・フィールドをユーザがマッピングする必要があることが知らされる。図８のデータマッピング（Data  Mapping）８０３には、いくつかのデフォルトマッピングが示されている。ＧＵＩの中央列の変換（Transformation）８０９内の複数のピル８２１は、データソース・スキーマ（Data  Source  Schema）８０７の１つ以上のオブジェクトから、カノニカルデータモデル（Canonical  Data  Model）８１１の１つ以上のエンティティ又は複数のエンティティのグループとそれらの属性への既存のデータマッピングの数を示す。例えばデータソース・スキーマ８０７のデータソース：Crocs  Service  US８１３のオブジェクト：Person８１７は、カノニカルデータモデル８１１のエンティティグループ：Consumer８１５のエンティティ：Individual８２５にマッピングされる。データソース・スキーマ８０７のオブジェクト：Person８１７は、例えば「電子メール：個人（Email:  Personal）」及び「電話：モバイル（Phone:  Mobile）」を含む複数の属性を有するエンティティ：CONTACT  POINTS８２７にもマッピングされる。コマース・アーキテクチャＧＵＩは、ユーザが前述のような属性を検索することを可能にする検索ボックス８２９も有する。
【００６６】
ＧＵＩのデータマッピング８０３は、データソース・スキーマ８０７とカノニカルデータモデル８１１との間で作成されたデータマッピングの数に関して、ユーザに有用な情報を提供することができる。例えばデータマッピング情報は、複数のピル８２１、オブジェクト、ピル及びエンティティ表現の内側に、並びにオブジェクト、ピル、エンティティ表現の間にこれらの表現を結ぶ線の形態で提供され得る。例えばデータソース・スキーマ８０７のオブジェクト：Person８１７の表現は、オブジェクト：Person８１７の１４個のフィールド８１８がカノニカルデータモデル８１１に接続される必要があることを示し、データソース・スキーマ８０７のオブジェクト：Account８１９は、オブジェクト：Account８１９の１３個のフィールドがカノニカルデータモデル８１１に接続される必要があることを示す。オブジェクト：Person８１７からの線に従うことにより、ユーザは、ＧＵＩの左側のこのオブジェクトとＧＵＩの右側のエンティティとの間の関係コネクタを見ることができる。
【００６７】
これらの関係コネクタは、「ビジュアル論理コネクタ」とも呼ばれ、ユーザについて、そのオブジェクトからのマッピングの数又は量を要約することができる。例えばオブジェクト：Person８１７の１４個のフィールド８１８は、データソース・スキーマ８０７のオブジェクト：Person８１７から複数のピル８２１のうちの１４個のピルへの接続を示す。複数のピル８２１の各々は、カノニカルデータモデル８１１内のエンティティに対して行われたデータマッピングの数を列挙する。例えば一番上のピル８２３は、エンティティ：Individual８２５への９個の接続又はマッピングを示す。これらの９個の接続は、マップされるエンティティ：Individual８２５内の属性の数又は量を表す。また、エンティティ：Individual８２５は、このエンティティを展開した場合にエンティティ：Individual８２５の下で見ることができる９個のマップされた属性が存在することを示すために、数字９を表示している。全体では、（一番上のピル８２３から下に読むと）９＋１＋１＋１＋１（＝１３）の接続がある。オブジェクト：Person８１７について、レコード：Personの１４個のフィールドと、オブジェクト：Personに接続される１３個の接続ピルとの間に、接続差が１つ存在する。これは、マップすべき、ファイルされた追加のカスタムが１つあることを示す。
【００６８】
多数のマッピングが存在する可能性があるため、ユーザは各オブジェクト又はエンティティを展開することができ、これは、ユーザが、フィールドレベルでそれぞれのオブジェクト又はエンティティの下のマッピングを見ることを可能にする。
【００６９】
図９は、いくつかの実施形態による、データソース・スキーマの１つの展開されたオブジェクトの下の例示のフィールドについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図９に図示されるように、データソース・スキーマ９０７のデータソース：Crocs  Service  US９１３のオブジェクト：Person９１７を展開して、スキーマ内のオブジェクトに関する更なる詳細、例えばオブジェクト９１７のReward  Level９１９、Customer  No、Creation  Date、First  Name及びLast  Nameを明らかにすることができる。データソース・スキーマ９０７のデータソース：Crocs  Service  US９１３からのオブジェクト：Person９１７のReward  Level９１９は、カノニカルデータモデル９１１のいかなる属性にもマップされていないことが分かる。
【００７０】
図１０は、いくつかの実施形態による、カノニカルデータモデルの１つの展開されたエンティティの下の例示の属性についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図１０の例では、カノニカルデータモデル１０１１のエンティティグループ：Consumer１０１５のエンティティ：Individual１０２５を展開して、展開された属性の下部に、エンティティに関する更なる詳細、例えばSource  Guide、Create  Date、First  Name、Last  Name及びEdit  List（リストの編集）１０２７を明らかにすることができる。Edit  List（リストの編集）１０２７をクリックすることによって、新しい属性を属性リストに追加し、データソース・スキーマ１００７のマップされていないフィールドに接続することができる。
【００７１】
図１１は、いくつかの実施形態による、カノニカルデータモデルの展開されたエンティティに対する１つの属性の追加についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。カノニカルデータモデルのエンティティのEdit  List（リストの編集）をクリックした後、ＧＵＩ内のカノニカルデータモデル１１１１の右側にカノニカル詳細（Canonical  Details）１１２７を表示することができる。図１１に示される例において、エンティティ：Consumer１１１５のカノニカル詳細１１２７は、Reward  Score１１３１、Block  Geolocation  Tracking、Create  Date、Date  of  Birth及びDo  Not  Market  Update  Date等のような更なる属性を含む。各属性は、可視範囲（Visibility）、属性レベル（Attribute  Label）、データタイプ（Data  Type）、説明（Description）列を含むことができる。Visibility列では、ボックス内の灰色のチェックマークは、カノニカルデータモデルのエンティティに含まれ、データソース・スキーマのフィールドにマッピングされていることを示す。また、可視範囲（Visibility）ボックスをチェックすることで、新しい属性を追加することができる。例えば可視範囲（Visibility）ボックス１１２９は、エンティティ：Individual１１２５に含まれるべきReward  Score１１３１についてチェックされる。属性：Reward  Score１１３１のデータタイプは５桁の整数：Integer(5)である。属性リストの編集が終了すると、ユーザは出口１１３５をクリックしてデータマッピングに戻ることができる。
【００７２】
図１２は、いくつかの実施形態による、データソース・スキーマの１つの展開されたオブジェクトの下の１つのフィールドを、カノニカルデータモデルのマップされたオブジェクトの下の追加された対応する属性にマッピングする、コマース・アーキテクチャＧＵＩスクリーンショットを示す。カノニカルデータモデル１２１１に新しい属性を追加した後、データソース・スキーマ１２０７内のマップされていないフィールドは、マップされていないフィールドと、対応する新しい属性を単にクリックすることによって、新しい属性に接続され得る。例えば図１２において、エンティティ：Individual１２２５は、Reward  Score１２３１の追加による属性の更新された数を示すために、数字９を数字１０に更新する。そして、オブジェクト：Person１２１７のReward  Level１２１９と、エンティティ：Individual１２２５のReward  Score１２３１をクリックした後、破線１２３３はそれらを接続して、Reward  Level１２１９のReward  Score１２３１へのマッピングを示す。
【００７３】
図１３は、いくつかの実施形態による、データソース・スキーマの１つの展開されたオブジェクトの下のフィールドと、カノニカルデータモデルのマッピングされたオブジェクトの下の追加された対応する属性との間のタイプ不一致についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図１３の例では、新しいピル１３３３が、オブジェクト：Person１３１７のReward  Level１３１９とエンティティ：Individual１３２５のReward  Score１３３１のマッピングとともに追加されている。そして、ピル１３３３内の数字１は、エンティティ１３１５の属性：Reward  Score１３３１への１つの接続又はマッピングを示し、ピル１３３３内のエクスクラメーションマークは、接続エラーを示す。
【００７４】
ユーザがピル、例えばピル１３３３をクリックすると、ＧＵＩは、変換エディタ１３３４を開くことができる。変換エディタ１３３４は、１つのエラーメッセージ１３３５、変換ルールエディタボックス１３３６、データソース・スキーマ１３０７のフィールドとカノニカルデータモデル１３１１のマッピングされた属性との間の現在のデータ変換の表示、そして変換されたデータのサンプルを有する変換プレビューウィンドウ１３３９を有する。例えばピル１３３３について、エラーメッセージ１３３５は、フィールドタイプの不一致（Field  type  mismatch）を示している。そして、データソース・スキーマのReward  LevelのフィールドタイプはString(255)  １３３７であり、カノニカルデータモデルのReward  ScoreのフィールドタイプはInteger(5)  １３３８である。
【００７５】
図１４は、いくつかの実施形態による、データソース・スキーマの下のフィールドと、カノニカルデータモデルの下の対応する属性との間のタイプ不一致を解決するための変換ルールセットアップについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。変換ルールエディタ１４３６は、データソース・スキーマの１つのフィールドとカノニカルデータモデルの対応する属性との間の不一致を解決するように編集することができる。図１４に示されるように、変換ルールエディタ１４３６では、簡単なコードを使用してフィールドタイプの不一致を解消する。いくつかの実施形態では、コードを書く代わりに、基本的な不一致解決機能を提供することができる。変換プレビュー（Transformation  Preview）ウィンドウ１４３９は、変換されたデータのリストを、レコードＩＤ（Record  ID）、各レコードＩＤの名前を示すソースデータ（Source  Data）及びカノニカルデータモデル１４１１に現れるような各レコードＩＤのReward  Scoreを示す変換されたデータ（Transformed  Data）の特定の列とともに表示する。例えばReward  Levelのフィールドタイプとしてソースデータ（Source  Data）列内にSilverを含むレコード８９２０７は、変換されたデータ（Transformed  Data）列内のカノニカルデータモデル１４１１のReward  Score：２５にマップされる。
【００７６】
図１５は、いくつかの実施形態による、データ不一致を解決した後のデータソース・スキーマとカノニカルデータモデルとの間のデータマッピングについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図１５に図示されるように、フィールドタイプの不一致が解決された後、データソース・スキーマ１５０７の下のデータソース：Crocs  Service  US１５１３内のエンティティ：Person１５１７のReward  Level１５１９は、カノニカルデータモデル１５１１の下のエンティティグループ：Consumer１５１５内のエンティティ：Individual１５２５内のReward  Score１５３１にマッピングされる。ピル１５３３は、Reward  Level１５１９とReward  Score  ５３１との間の１つの接続又はマッピングを示しており、エクスクラメーションマークはない。
【００７７】
単一エンティティビュー
図１６〜図２６は、いくつかの実施形態による、単一顧客ビューとも呼ばれる単一エンティティビューを構築するためのデータ準備、マッチングルール、データ調和ルール及び顧客更新ルールを示す。図１６は、いくつかの実施形態による、単一エンティティビューのためのデータ準備のコマース・アーキテクチャＧＵＩスクリーンショットを示す。このステップでは、セットアップ１６０５の下のデータ準備（Data  Preparation）タブを強調表示することができ、情報ヘッダ１６０２をデータ準備（Data  Preparation）に更新することができる。カノニカルデータモデルの単一のエンティティビューを構築するには、まず顧客プロファイル統合のためにデータを準備する必要がある。図１６の例において、データ準備（Data  Preparation）１６０３は、データ操作（Data  Operation）１６０７、属性の数（Number  of  Attributes）１６０９、ステータス（Status）１６１１及び最終修正（Last  Modified）１６１３を含むであろう。例えばデータ操作１６０７のAddress  Cleansing  and  Normalization１６１５は８個の属性１６１７を有し、ステータスはセットアップ要求（Setup  Required）１６１９を示しており、これは、Address  Cleansing  and  Normalizationはセットアップが必要であることを示している。データ操作１６０７のPhone  Cleansing  and  Normalization１６２３は、３つの属性１６２５を有し、また、ステータスはSetup  Required（セットアップ要求）１６２７を示している。
【００７８】
図１７は、いくつかの実施形態による、データ準備のための例示のデフォルト値をセットアップするコマース・アーキテクチャＧＵＩスクリーンショットを示す。図１６のセットアップ要求（Setup  Required）１６２７をクリックした後、新たなエディタウィンドウ１７０３は、要求されるセットアップを表示することができる。例えば図１７では、接続されたデータソースについてデフォルトの国のセットアップを要求する、デフォルトの国の設定（Set  Default  County）ウィンドウ１７０３がＧＵＩに表示されている。データソース１７０７と、アドレス用のデフォルトの国（Default  Country  for  Address）１７０９が、デフォルトの国を設定するために含まれる。例えばNTO  North  America１７３３は、カナダ又は米国から選択してデフォルトの国を設定する必要がある。各データソースのデフォルトの国をセットアップした後、ユーザは、保存及びアクティベート（Save  &  Activate）１７１５をクリックして、各データソースのデフォルトの国の設定を終了することができる。
【００７９】
図１８は、いくつかの実施形態による、データ準備のために必要なセットアップを完了するコマース・アーキテクチャＧＵＩスクリーンショットを示す。図１８に図示される例では、Address  Cleansing  and  Normalization１８１５が、図１７の必要なデフォルト国のセットアップを完了した後、ステータス１８１１が、セットアップ要求（Setup  Required）１６１９からアクティブ（Active）１８１９に更新される。また、Phone  Cleansing  and  Normalization１８２３は、メッセージボックス１８３１に示されるようなデフォルトの国の値の必要なセットアップを完了する。Phone  Cleansing  and  Normalization１８２３のステータス１８１１も、アクティブ（Active）１８２７に更新される。
【００８０】
データ準備が完了した後、マッチングルールを設定して、同じ顧客に関連する異なる顧客レコードを識別することができる。デフォルトのマッチングルールのうちの少なくとも１つを、システムによってアクティブにすることができ、追加のマッチングルールが、ユーザによって設定又は更新されてよい。図１９は、いくつかの実施形態による、単一エンティティビューのマッチングルールについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。マッチングルールのセットアップ中に、セットアップ１９０５の下のマッチングルール（Matching  Rules）タブを強調表示し、情報ヘッダ１９０２をマッチングルール（Matching  Rules）に更新することができる。図１９の例において、マッチングルール１９０３は、マッチングルールの名前（Name）１９０７、ステータス（Status）１９０９、説明（Description）１９１１及び最終修正（Last  Modified）１９１３を含む。例えばマッチングルール：Name  with  Exact  Phone１９１５は、Inactive１９１７のステータス、「Fuzzy  First  Name,  Exact  Last  Name,  Exact  Phone」１９１９の説明を有し、「9/18/2018,  1:01PM」１９２１に最後に修正された。Name  with  Exact  Phone１９１５等のマッチングルールをクリックした後、マッチングルールの詳細をレビューして編集することができる。新規ルール（New  Rule）１９２３をクリックすると、新しいマッチングルールを追加することもできる。
【００８１】
図２０は、いくつかの実施形態による、１つのマッチングルールに対する例示のマッチング基準のセットアップについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。１つのマッチングルールをクリックされてＧＵＩに詳細が表示された後、そのマッチングルールについてのマッチング基準（Matching  Criteria）２００７とマッチングロジック（Matching  Logic）２０２７の詳細を見ることができる。例えば図２０において、Name  with  Exact  Phone２００３は、マッチング基準（Matching  Criteria）２００７とマッチングロジック（Matching  Logic）２０２７だけでなく、図１９における説明（Description）、ステータス（Status）及び最終修正（Last  Modified）のルール情報を有する。マッチング基準２００７は、エンティティ（Entity）２００９、属性（Attribute）２０１１、マッチング方法（Matching  Method）、ファジー性（Fuzziness）２０１５及びマッチブランクフィールド（Match  Blank  Fields）２０１７を含む。最初のマッチング基準は、エンティティ：Customer２０１９、属性：First  Name２０２１、マッチング方法：Fuzzy  First  Name２０２３及びファジー性：Similar  Spelling２０２５を有する。最初のマッチング基準にはマッチブランクフィールドのエントリはない。また、マッチングルール：Name  with  Exact  Phone２００３のマッチング基準２００７のマッチングロジック２０２７は、「All  of  the  conditions  are  met  (AND)（すべての条件が満たされる）」である。ＧＵＩの右上にある編集（Edit）２０３１、削除（Delete）２０３３、複製（Clone）２０３５又はアクティベート（Activate）２０３７をクリックすることによって、マッチングルールを更新することができる。例えば編集２０３１をクリックした後、マッチングルール：Name  with  Exact  Phone２００３を編集することができる。
【００８２】
図２１は、いくつかの実施形態による、１つのマッチングルールを編集するコマース・アーキテクチャＧＵＩスクリーンショットを示す。図２１に図示される例では、マッチングルール（Matching  Rule）エディタ２１０３は、ルール情報（Rule  Information）２１０７及びマッチング基準（Matching  Criteria）２１１３を含む。ルール情報２１０７は、ユーザの入力によって編集することができる名前（Name）２１０９と説明（Description）２１１１を有する。名前２１０９の前にあるアスタリスク２１０８は、この情報が必要であることを示す。マッチング基準２１１３は、ドロップダウンメニュー「All  Conditions  Met」２１１５のようなアクションをいつとるべきかを設定することができる。実施形態によっては、ドロップダウンメニュー２１１５から、他の条件を選択することもできる。各マッチング条件は、カノニカルエンティティ（Canonical  Entity）ドロップダウンメニュー２１１７、カノニカル属性（Canonical  Attribute）ドロップダウンメニュー２１２１、マッチング方法（Matching  Method）ドロップダウンメニュー２１２５及びマッチブランクフィールド（Match  Blank  Fields）チェックボックス２１３１を含むことができる。また、ゴミ箱アイコン２１３３をクリックすることによって、あるマッチング条件を削除することができ、あるいは条件追加（Add  Condition）２１３７をクリックすることによって新たなマッチング条件を追加することができる。各条件間のマッチングロジックは、AND２１２３のように、２行目から始まる各条件の各行の先頭に示される。パラメータを入力した後、ユーザは次（Next）２１４３をクリックして編集を続けることができる。インジケータバー２１４１は、ラインに沿って円を移動させることによってマッチングルールを編集するプロセスステップを示すことができる。また、ユーザは、キャンセル（Cancel）２１３９又は「×」２１４５をクリックして、編集されたマッチングルールを保存することなく、マッチングルール編集（Edit  Matching  Rule）２１０３を閉じることもできる。
【００８３】
図２２は、いくつかの実施形態による、マッチングルールの編集後のマッチプレビューについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。マッチングルールを編集した後、図２２に図示されるように、マッチプレビュー（Match  Preview）２２０９がマッチング結果のサンプルを列挙することになる。マッチプレビュー２２０９は、サンプルレコード（Sample  Record）２２１５、潜在マッチレコード（Potential  Match  Record）２２１７、フィールドマッチ（Field  Match）２２１９及びマッチ結果（Match  Results）２２２１を含むことができる。サンプル情報バー２２２３は、ＧＵＩ内に示されるサンプル及びサンプルの総数を示すことができる。また、ユーザは、異なるサンプルをレビューするために、サンプル情報バー２２２３の左右矢印をクリックすることもできる。ルール情報（Rule  Information）２２０７及びマッチング基準（Matching  Criteria）２２１３も、ＧＵＩの右側に表示される。図２２の例では「First  name:  Joe,  Last  Name:  Smith,  Phone:  (303)603-4211」を有する最初のサンプルレコードが、マッチング基準２２１３の下の潜在マッチレコード「“First  Name:  Joseph,  Last  name:  Smith,  Phone:  (303)603-4211”」と一致する。ユーザがサンプルを確認してマッチングルールを確認した後、ユーザは、保存及びアクティベート（Save  &  Activate）２２２５をクリックして、マッチングルールを保存してアクティブにすることができる。
【００８４】
図２３は、いくつかの実施形態による、編集後のマッチングルールについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図２３では、メッセージボックス２３０７は、マッチングルールが保存されてアクティブにされたことを示している。そして、ＧＵＩは、マッチングルール（Matching  Rules）ウィンドウ１９０３と同様のマッチングルール（Matching  Rules）ウィンドウ２３０３に戻る。マッチングルール：Name  with  Exact  Phone２３１５は、更新されたステータス：Active２３１７と、更新された最終修正「09/19/2018,  1:05PM」２３２１を有する。
【００８５】
図２４は、いくつかの実施形態による、単一エンティティビューのためのデータ調和ルールについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。異なるデータソースから利用可能な値が複数存在する場合、いずれかの属性は１つの値しか有さないため、調和ルールは、１つのマスターファイルに対してどの値を使用するかを決定するために必要とされる。図２４に図示されるように、セットアップ２４０５の下のデータ調和ルール（Data  Reconciliation  Rules）タブを強調表示することができ、情報ヘッダ２４０２をデータ調和ルール（Data  Reconciliation  Rules）に更新することができる。ＧＵＩの中間において、データ調和ルール２４０３は、属性名（Attribute  Name）２４０７、エンティティ（Entity）２４０９、データタイプ（Data  Type）２４１１、属性タイプ（Attribute  Type）２４１３、調和ルール（Reconciliation  Rules）２４１５及び最終修正（Last  Modified）２４１７を含むことができる。例えば最初のデータ調和ルールには、属性名：First  Name２４１９、エンティティ：Individual、データタイプ：Test、属性タイプ：Standard、調和ルール：Last  Updated、最終修正：「09/18/2018,  1:01PM」を有する。First  Name２４１９等のデータ調和ルールをクリックした後、データ調和ルールの詳細をレビューして編集することができる。新規ルールセット（New  Ruleset）２４２３をクリックすることよって、新たなデータ調和ルールを追加することもできる。
【００８６】
図２５は、いくつかの実施形態による、１つの例示属性に対するデータ調和ルールについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。１つの調和ルールをクリックすると、ルールの詳細がＧＵＩに表示される。図２５に図示される例では、データ調和ルール：First  Name２５０３は、図２４のような説明（Description）、エンティティ（Entity）、属性タイプ（Attribute  Type）及びデータタイプ（Data  Type）のルール情報、並びに詳細（Details）２５０７及びソースマッピング（Source  Mappings）２５０９を有する。詳細２５０７は、アクティブルール（Active  Rule）２５１１、説明（Description）２５１３、一次タイ・ブレーカ（Primary  Tie  Breaker）２５１５、二次タイ・ブレーカ（Secondary  Tie  Breaker）及び最終修正が含まれる。例えば最終更新（Last  Updated）というアクティブルール２５１１は、「The  last  updated  value  is  reconciled（最終更新された値が調和される）」という説明２５１３を有する。一次タイ・ブレーカ２５１５はソース優先（Source  Priority）であり、二次タイ・ブレーカは頻度（Frequency）であり、ルールは、最終修正が「“09/18/2018,  1:01PM」である。ビュー・タイ・ブレーカルール（View  Tie  Breaker  Rule）２５２１は、優先順位（Priority）２５２３、データソース（Data  Source）２５２５、クラウド名（Cloud  Name）２５２７、ソースオブジェクト（Source  Object）  ２５２９、一次タイ・ブレーカ（Primary  Tie  Breaker）２５３１及び二次タイ・ブレーカ（Secondary  Tie  Breaker）２５３３を含む。タイ・ブレーカルールは、現在のルールについてタイ（tie）が存在するとき、どのルールに従うべきかを定義することができる。例えばFirst  Name２５０２の値が、同時に異なるデータソースで更新される場合、最終更新のアクティブルール２５１１についてタイが存在する。ソース優先順位（Source  Priority）の一次タイ・ブレーカ２５１５は、どの値を使用するかを決定することができる。優先順位２５２３は、異なるデータソースについて従うべき優先順位をリストする。この場合、データソースCrocs  Globalからのファーストネームの値が更新に使用される。同時に更新されたCrocs  Globalからのファーストネームの値が２つある場合、一次タイ・ブレーカ２５１５及び二次タイ・ブレーカ２５３３を考慮して、どの値を使用すべきかを決定することになる。編集（Edit）２５３５をクリックすることによって、アクティブルール２５１１を編集することもできる。
【００８７】
図２６は、いくつかの実施形態による、例示の属性に対するデータ調和ルールを編集するコマース・アーキテクチャＧＵＩスクリーンショットを示す。図２６に図示すように、アクティブルール２５１１の編集２５３５をクリックした後、調和ルール（Reconciliation  Rule）エディタ２６０３：Choose  Data  Reconciliation  Rule  for  First  NameがＧＵＩに表示される。調和ルールエディタは、ルールタイプ（Rule  Type）２６０７及び説明（Description）２６０９が含まれる。例えば最終更新（Last  Updated）のルールタイプは、対応する「Choose  the  last  record  or  data  element  within  the  designated  data  set（指定されたデータセット内の最後のレコード又はデータ要素を選択する）」という説明を有する。ユーザが調和ルールエディタ２６０３のルールを更新した後、ユーザは、保存（Save）２６１１をクリックして調和ルールを保存することができる。
【００８８】
図２７は、いくつかの実施形態による、例示の属性に対するデータ調和ルールの編集後のコマース・アーキテクチャＧＵＩスクリーンショットを示す。編集されたデータ調和ルールを保存した後、メッセージボックス２７０４を表示して、新しいデータ調和ルールのセットアップを示すことができる。また、詳細（Details）２７０７内のアクティブルール（Active  Rule）２７１１の最終修正（Last  Modified）２７１９も、新しいタイムスタンプで更新することができる。
【００８９】
データスチュワードシップ
データスチュワードシップは、顧客との対話及びシステムインテリジェント推奨に基づいて、データの品質を改善するのを助けることができる。データ改善の要求を、優先順位によってソートすることができる。データスチュワードシップはまた、ユーザ又は管理者がマスターレコードを編集又は削除することを可能にする。例えば一般データ保護規則（ＧＤＰＲ：General  Data  Protection  Regulation）のようなプライバシー法の遵守のために、消費者が自身の情報を削除したい場合、データスチュワードシップモジュールを使用して、システム内の消費者のレコードを削除することができる。また、データスチュワードシップは、ユーザが、プロファイルに対してクエリを実行し、プロファイル内のデータのソースを決定することも可能にする。
【００９０】
図２８は、いくつかの実施形態による、データスチュワードシップについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図２８では、セットアップ２８０５の下のデータスチュワードシップ（Data  Stewardship）タブをクリックした後、データスチュワードシップタブが強調表示され、情報ヘッダ２８０２がデータスチュワードシップ（Data  Stewardship）に更新される。ＧＵＩの中央において、データスチュワードシップ２８０３は、要求キュー（Request  Queue）２８０７及び検索（Search）２８０９を含むことができ、ここで、要求キュー２８０７は、関連性によってソートされた要求のリストを表示している。各要求は、優先度（Priority）２８１１、要求タイプ（Request  Type）２８１３、要求者（Requestor）２８１５、名前（Name）２８１７、ステータス（Status）２８１９、要求日（Request  Date）２８２１及び要求ＩＤ（Request  ID）２８２３を含むことができる。優先度２８１１の列は、優先度レベルのテキスト説明に加えて、優先度レベルを示すためにゲージアイコン２８２５を含むこともできる。例えば要求ＩＤ：６２４２８は、高優先度で要求タイプがPrivacy  Delete（プライバシー削除）である。これは、２０１８年９月１９日（09/18/2018）に要求された、顧客であるFarrah  Nicholsに対して要求者であるAndy  Wilsonからの新たな要求である。要求キュー２８０７内のPrivacy  Delete（プライバシー削除）２８２７等の要求タイプをクリックすることにより、要求の更なる情報を提供することができる。
【００９１】
図２９は、いくつかの実施形態による、データスチュワードシップに対する例示の要求タイプの詳細についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図２９に図示されるように、要求キュー（Request  Queue）２９０７の最初の要求に対するプライバシー削除（Privacy  Delete）２９２７というリクエストタイプをクリックした後、ポップアップ・メッセージボックス２９２９は、プライバシー削除の詳細を提供することができる。例えば図２９において、プライバシー削除（Privacy  Delete）２９２９のメッセージボックスは、NTO  North  Americaという要求データソース（Request  Data  Source）２９３１及び「Farrah  request  her  information  be  deleted  except  for  orders（Farrahが注文以外の彼女の情報の削除を要求）」という要求者からのメモ（Note  From  Requestor）２９３５を含む。
【００９２】
図３０は、いくつかの実施形態による、データスチュワードシップに対する例示の要求の詳細についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図３０の例では、図２８内の要求ＩＤ：２７２５３が、図２８のプロファイルマージ２８２９についてクリックされると、Samantha  Smith-Jones３００３についてのプロファイルマージ要求がＧＵＩ内で開かれる。Samantha  Smith-Jones３００３の詳細情報は、Records、Request  By、Requested  From、Priority、Status及びNote  from  Requestorに提供される。例えばSamantha  Smith-Jones３００３は、Andy  Wilsonによって、システム内の彼女の２つのプロファイルのために、Samの報酬レベルの２つのレコードを統合するように要求されている。各レコードは、ＩＤ３００９、名前（Name）３０１１、電子メール（Email）３０１３、電話（Phone）３０１５及びアドレス（Address）３０１７の要求情報の下に表示される。ユーザは、これら２つのレコードの詳細を見て、レコードをマージ（Merge  Records）３００７をクリックすることによってレコードをマージすることができる。
【００９３】
図３１は、いくつかの実施形態による、データスチュワードシップの検索機能についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図３１において、データスチュワードシップ３１０３のレコード検索機能は、図２８の検索２８０９タブをクリックすると、ＧＵＩに表示される。検索機能は、Name（名前）等のレコードを検索するためのドロップダウンメニュー３１１１及びテキスト入力のための検索ボックス３１１３を提供する。ユーザは、検索（Search）３１１５をクリックして、レコード検索を実行すうことができる。
【００９４】
図３２は、いくつかの実施形態による、データスチュワードシップの検索結果についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図３２に図示されるように、名前（Name）３２１１のレコード検索のために検索ボックス３２１３内にSampleが入力されると、２つの検索結果が表示されている。これらの２つのレコードは、関連性によってソートされてＧＵＩの検索ボックスの下に列挙される。各レコードは、ＩＤ３２１７、名前（Name）３２１９、電子メール（Email）３２２１、電話（Phone）３２２３及びアドレス（Address）３２２５を含む。ユーザは、レコードのＩＤをクリックしてレコードの更なる詳細を表示することができる。
【００９５】
図３３は、データスチュワードシップのための例示の顧客プロファイルについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図３３の例では、Sample  Last３３０３の顧客プロファイルの詳細が、図３２のSample  Lastの検索結果ＩＤのクリックに応答して表示される。Customer360のＩＤ  ３３０７、寄与レコード（Contributing  Records）３３０９、寄与ソース（Contributing  Sources）３３１１及び最終修正（Last  Modified）３３１３が、Sample  Last３３０３のために提供される。また、Customer  Profile  Sample  Last３３０３の下に、属性（Attribute）３３１５、ソースレコード（Source  Records）３３１７、変更履歴（Change  History）３３１９もＧＵＩに表示される。ソースレコードの各々は、データソース（Data  Source）３３２１、ソースオブジェクト（Source  Object）３３２３、レコードＩＤ（Record  ID）３３２５、最後のトランザクション（Last  Transaction）３３２７、名前（Name）３３２９、電子メール（Email）３３３１及び電話（Phone）３３３３を含む。例えばSample  Lastの顧客プロファイルは、データソース：Brunello  Commerceから寄与される。Brunello  Commerceのソースオブジェクトプロファイルは、Sample  Lastの顧客プロファイルに対し、名前：S.Last、電子メール：S.last@gmail.com、電話：789  654-3210を与える。
【００９６】
図３４は、いくつかの実施形態による、データソースとシステムとの間の接続についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。コマース・アーキテクチャのセットアッププロセスの終了後、ＧＵＩのホーム画面は、図３４のように、システムに接続されたデータソースを示すことになる。例えばデータソース３４０１は、サービスクラウド３４０３、コマースクラウド３４０７、セールスクラウド３４１５及びマーケティングクラウド３４１７を含み、これらはすべてシステム３４１１に接続されている。各クラウドの右下の数字は、サービスクラウドに対する数字３（３４１９で示される）のように、クラウド内のデータソースの数を示すことができる。３４１９で示される数字３は、３つのサービスクラウドデータソースが接続されていることを意味する。ユーザは、Salesforceデータ３４０９をクリックすることによって、Salesforceから更なるデータソースを、他のデータ３４１３をクリックすることによって、第三者からの更なるデータソースを追加することができる。ＧＵＩの右側において、接続されたデータの分析（Analytics）３４２１は、入力顧客レコード（Input  Consumer  Records）３４２３及び固有の顧客レコード（Unique  Consumer  Records）３４２５を提供する。例えば図３４において、入力顧客レコードは２８．３Ｍであり、固有の顧客レコードは７．１Ｍである。また、異なるレコード及び異なるクラウドに対する凡例３４２７とともに、各データソースについてのTotal  Qualified  Records及びUnique  Recordsがチャート３４２９内に示されている。
【００９７】
第三者データソース
第三者データソースは、企業資源計画（ＥＲＰ：Enterprise  Resource  Planning）システム等のように第三者に属するデータベース及びシステムである。例えばCrocsのような顧客は、イベントデータ分析のようなサービスを提供するため又は消費者のためにマーケティング・メールを生成するため、本明細書の実施形態によって使用することができるデータを有する。従来、顧客は、第三者のデータソースと接続するために、システム固有のアプリケーション・プログラミング・インタフェース（ＡＰＩ）を使用し、固有のコードを使用しなければならなかった。本明細書に提示される実施形態は、ユーザ又は管理者としての顧客が、別個のＡＰＩ及びコードの使用を差し控えることを可能にし、複数の異なる切断されたシステムを横断するクエリのための、単一の統合されたポイント・アンド・クリックＡＰＩを提供し、それにより、そのような変換に必要とされた時間及びコストを大幅に削減することができる。
【００９８】
図３５は、いくつかの実施形態による、例示の第三者データをシステムに接続するコマース・アーキテクチャＧＵＩスクリーンショットを示す。図３５の例において、ＧＵＩは、ユーザが図３４の他のデータ３４１３をクリックした後に、MuleSoft３５０７を含むデータソース３５０１を提供する。また、MuleSoft３５０７をクリックすることにより、MuleSoft  Anypoint  Platformのメッセージボックス３５０９が引き出される。Anypoint  Platformで作成されたＡＰＩをシステムに接続し、顧客情報を更に充実させることができる。ユーザは、より多くのＡＰＩと接続するために、Anypoint  Platform３５１１をクリックするか、図３４に示すように、データソースのホームページに戻るために、戻る（Back）３５０３をクリックすることができる。
【００９９】
図３６は、いくつかの実施形態による、ＡＰＩを介して例示の第三者データをシステムに追加する詳細についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図３６において、Anypoint  Platformをクリックした後に、Anypoint  Exchangeプラットフォーム３６０３がＧＵＩに表示される。ユーザは、ドロップダウンメニュー３６０７から任意のカテゴリのＡＰＩを選択し、検索ボックス３６０９内でカスタマＡＰＩを検索することができる。顧客ＡＰＩには、例えばEmployee  Profile  Process  ＡＰＩ、Customer  Membership  ＡＰＩ、Customer  Onboarding  Process  ＡＰＩが含まれる。ユーザは、ＡＰＩ  ３６１１の右上隅にある情報マーク３６１３をクリックすることによって、Customer  Membership  ＡＰＩ３６１１に関する更なる情報を取得することができる。ポップアップ・メッセージボックス３６１７は、Customer  Membership  ＡＰＩの基本的な機能を紹介しており、ユーザは、Learn  More３６１９をクリックすることによって、更なる詳細を知ることができる。接続（Connect）３６１５をクリックした後、Customer  Membership  ＡＰＩがシステムと接続される。
【０１００】
図３７は、いくつかの実施形態による、第三者データソースとＡＰＩの接続についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。Customer  Membership  ＡＰＩが接続された後、図３７のデータソース（Data  Sources）３７０１は、Customer  Membership  ＡＰＩ３７０９とMuleSoft３７０７の接続を更新する。ユーザは、更に追加（Add  More）３７１１をクリックして第三者のＡＰＩを更に追加するか、戻る（Back）をクリックして、Data  Sourcesのホームページに戻ることができる。分析（Analytics）３７２１は、Input  Consumer  Records３７２３、Unique  Consumer  Records３７２５、Legend３７２７及びanalytics  chart３７２９についても更新される。
【０１０１】
図３８は、いくつかの実施形態による、システムと、第三者データソースを含むデータソースとの間の接続についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図３８に図示されるように、第三者データソースを追加した後、データソース３８０１は、サービスクラウド３８０３、コマースクラウド３８０７、セールスクラウド３８１５、マーケティングクラウド３８１７及びMuleSoft第三者データソース３８２１を含み、MuleSoft第三者データソース３８２１は、接続された第三者ＡＰＩを示す数字１（３８１９）を有する。これらのデータソースは、システム３８１１に接続されている。ユーザは、Salesforceデータ３８０９をクリックすることによって更なるSalesforceデータソースを追加することができ、あるいは他のデータ３８１３をクリックすることによって更なる第三者データソースを追加することができる。
【０１０２】
コマース・アーキテクチャＧＵＩフローチャート
図３９は、いくつかの実施形態による、コマース・アーキテクチャＧＵＩをセットアップするためのフローチャートの例を示す。方法３９００は、ハードウェア（例えば回路、専用論理、プログラマブル論理、マイクロコード等）、ソフトウェア（例えば処理デバイス上で実行される命令）又はそれらの組合せを含み得る処理ロジックによって実行され得る。本明細書で提供される開示を実施するために必ずしもすべてのステップが必要とされるわけではないことを認識されたい。さらに、当業者によって理解されるように、ステップのいくつかは、同時に実行されてもよく、図３９に示されるものとは異なる順序で実行されてもよい。方法３９００は図１〜図３８を参照して説明される。しかしながら、方法３９００は、例示の実施形態に限定されない。
【０１０３】
３９１０において、コマース・アーキテクチャＧＵＩが、第１及び第２データソースを追加するための第１及び第２ボタンを表示するために提供される。例えば図１のＧＵＩは、Salesforceデータソース又は第三者データソースを追加するために使用することができるSalesforceデータ１０１及び他のデータ１０２を含む。第１及び第２ボタンは、異なるSalesforceクラウド２１１、２１３、２１７又は２１９を参照することもできる。ＧＵＩは、従来のプログラムコードや様々なＡＰＩの代わりに、データソースを追加するためのポイント・アンド・クリック・ユーザインタフェースを提供する。
【０１０４】
３９２０において、第１及び第２応答が、第１及び第２ボタン上でのクリックを通して受け取られる。図７に図示されるように、Salesforceデータソースを追加した後、すべての認証済みデータソースがＧＵＩ内に列挙される。
【０１０５】
３９３０において、第１データスキーマ及び第２データスキーマのビューが、コマース・アーキテクチャＧＵＩに提供される。例えば図８〜図１６は、左側に第１データスキーマとしてデータソース・スキーマ（Data  Source  Schema）を示し、右側に第２データスキーマとしてカノニカルデータモデル（Canonical  Data  Model）を示している。データソース・スキーマは、接続されたデータソースのすべてのデータを含む。また、カノニカルデータモデルは、接続されたデータソースのデータのマスターレコードとすることができる。
【０１０６】
３９４０において、第１データスキーマの少なくとも１つのオブジェクトが、第２データスキーマの少なくとも１つのオブジェクトにマッピングされる。例えば図１０において、第１データスキーマ：データソース・スキーマの第１オブジェクト：Birthdayは、第２データスキーマ：カノニカルデータモデルの第２オブジェクトであるDate  of  Birthにマッピングされる。
【０１０７】
３９５０において、第２データスキーマの第２オブジェクトの単一エンティティビューが、データ準備（Data  Preparation）、マッチングルール（Matching  Rules）、データ調和ルール（Data  Reconciliation  Rules）及び顧客更新ルール（Customer  Update  Rules）を通して提供される。図１６〜図２７は、単一のエンティティビューのセットアップを示す。データ準備（Data  Preparation）の間に、データ品質を向上させて、最良の顧客プロファイル統合を確実にすることができる。マッピングルールのうちの少なくとも１つをアクティブにすることによって、同じ顧客に関連する異なる顧客レコードを識別することができる。一部のデータソースにデフォルト値を追加することができる。また、１つの値しか持たない属性についてデータ調和ルールを構成することができる。調和ルールは、異なるデータソースから利用可能な複数の値が存在するとき、どの値を使用するかを決定する。
【０１０８】
コンピュータシステム実装
図４０は、本明細書で提示される様々な実施形態を実装するために使用され得る例示のコンピュータシステムを図示している。図１〜図３８に図示される様々な実施形態は、図４０に図示されるコンピュータシステム４０００のような１つ以上の周知のコンピュータシステムを使用して実装されてよい。１つ以上のコンピュータシステム４０００を使用して、例えば本明細書で説明された実施形態のいずれか、並びにそれらの組合せ及び副次的組合せを実装してよい。
【０１０９】
コンピュータシステム４０００は、プロセッサ４００４のような１つ以上のプロセッサ（中央処理ユニット又はＣＰＵとも呼ばれる）を含んでもよい。プロセッサ４００４は、通信インフラストラクチャ又はバス４００６に接続されてよい。
【０１１０】
コンピュータシステム４０００はまた、モニタ、キーボード、ポインティングデバイス等のユーザ入力／出力デバイス４００３も含んでよい。ユーザ入力／出力デバイス４００３は、ユーザ入力／出力インタフェース４００２を介して通信インフラストラクチャ４００６と通信することができる。
【０１１１】
プロセッサ４００４の１つ以上は、グラフィックス処理ユニット（ＣＰＵ）であってもよい。一実施形態では、ＧＰＵは、数学的集約アプリケーションを処理するように設計された専用の電子回路であるプロセッサであってもよい。ＧＰＵは、コンピュータ・グラフィックス・アプリケーション、画像、ビデオ等に共通の数学的集約データのような、データの大きなブロックの並列処理に効率的な並列構造を有してもよい。
【０１１２】
コンピュータシステム４０００はまた、ランダムアクセスメモリ（ＲＡＭ）のようなメイン（又は一次）メモリ４００８を含んでもよい。メインメモリ４００８は、キャッシュの１つ以上のレベルを含んでもよい。メインメモリ４００８は、その中に制御ロジック（すなわち、コンピュータソフトウェア）及び／又はデータを格納しておくことができる。
【０１１３】
コンピュータシステム４０００はまた、１つ以上の二次ストレージデバイス又はメモリ４０１０も含んでよい。二次メモリ４０１０は、例えばハードディスクドライブ４０１２又は取り外し可能ストレージデバイス又はドライブ４０１４を含むことができる。取り外し可能ストレージドライブ４０１４は、フロッピーディスクドライブ、磁気テープドライブ、コンパクトディスクドライブ、光ストレージデバイス、テープバックアップデバイス又は任意の他のストレージデバイス／ドライブであってもよい。
【０１１４】
取り外し可能ストレージドライブ４０１４は、取り外し可能ストレージユニット４０１８と対話することができる。取り外し可能ストレージユニット４０１８は、その上にコンピュータソフトウェア（制御ロジック）又はデータを記憶した、コンピュータ使用可能又は読み取り可能なストレージデバイスを含んでもよい。取り外し可能ストレージユニット４０１８は、フロッピーディスク、磁気テープ、コンパクトディスク、ＤＶＤ、光ストレージディスク又は任意の他のコンピュータデータストレージデバイスであってよい。取り外し可能ストレージドライブ４０１４は、取り外し可能ストレージユニット４０１８との間で読み取り又は書き込みを行うことができる。
【０１１５】
二次メモリ４０１０は、コンピュータプログラムあるいは他の命令又はデータがコンピュータシステム４０００によってアクセスされることを可能にする他の手段、デバイス、コンポーネント、機器又は他のアプローチを含んでもよい。そのような手段、デバイス、コンポーネント、機器又は他のアプローチは、例えば取り外し可能ストレージユニット４０２２及びインタフェース４０２０を含んでもよい。取り外し可能ストレージユニット４０２２及びインタフェース４０２０の例は、プログラムカートリッジ及びカートリッジインタフェース（ビデオゲームデバイス内で見られるもの等）、取り外し可能メモリチップ（ＥＰＲＯＭ又はＰＲＯＭ等）及び関連ソケット、メモリスティック及びＵＳＢポート、メモリカード及び関連メモリカードスロット又は他の取り外し可能ストレージユニット及び関連インタフェースを含んでもよい。
【０１１６】
コンピュータシステム４０００は、通信又はネットワークインタフェース４０２４を更に含むことができる。通信インタフェース４０２４は、コンピュータシステム４０００が、（参照番号４０２８によって個々に、かつ、集合的に参照される）外部デバイス、外部ネットワーク、外部エンティティ等の任意の組合せと通信して対話することを可能にし得る。例えば通信インタフェース４０２４は、コンピュータシステム４０００が通信経路４０２６を介して外部又はリモートデバイス４０２８と通信することを可能にしてよい。通信経路４０２６は、有線又は無線（又はそれらの組合せ）であってもよく、ＬＡＮ、ＷＡＮ、インターネット等の任意の組合せを含んでもよい。制御ロジック又はデータは、通信経路４０２６を介してコンピュータシステム４０００との間で送信されてよい。
【０１１７】
コンピュータシステム４０００は、いくつかの非限定的な例を挙げると、パーソナル・デジタル・アシスタント（ＰＤＡ）、デスクトップ・ワークステーション、ラップトップ又はノートブックコンピュータ、ネットブック、タブレット、スマートフォン、スマート・ウォッチ又は他のウェアラブル、アプライアンス、モノのインターネット（Internet-of-Things）の一部又は組み込みシステム、あるいはそれらの任意の組合せのいずれかとすることもできる。
【０１１８】
コンピュータシステム４０００は、任意の配信パラダイムを通して任意のアプリケーション又はデータにアクセスするかホストする、クライアント又はサーバであってよく、限定ではないが：リモート又は分散クラウド・コンピューティング・ソリューション；ローカル又はオンプレミス（on-premises）ソフトウェア（「オンプレミス」クラウド・ベースのソリューション）；「アズ・ア・サービス（as  a  service）」モデル（例えばコンテンツ・アズ・ア・サービス（ＣａａＳ）、デジタルコンテンツ・アズ・ア・サービス（ＤＣａａＳ）、ソフトウェア・アズ・ア・サービス（ＳａａＳ）、管理ソフトウェア・アズ・ア・サービス（ＭＳａａＳ）、プラットフォーム・アズ・ア・サービス（ＰａａａＳ）、デスクトップ・アズ・ア・サービス（ＤａａＳ）、フレームワーク（ＦａａＳ）、バックエンド・アズ・ア・サービス（ＢａａＳ）、モバイルバックエンド・アズ・ア・サービス（ＭＢａａＳ）、インフラストラクチャ・アズ・ア・サービス（ＩａａＳ）；又は上記の例又は他のサービス又は配信パラダイムの任意の組合せを含むハイブリッド・モデルを含む。
【０１１９】
コンピュータシステム４０００における任意の適用可能なデータ構造、ファイル・フォーマット及びスキーマは、JavaScript（登録商標）  Object  Notification（ＪＳＯＮ）、ＸＭＬ（Extensible  Markup  Language）、ＹＡＭＬ（Yet  Another  Markup  Language）、ＸＨＴＭＬ（Extensible  Hypertext  Markup  Language）、ＷＭＬ（Wireless  Markup  Language）、MessagePack、ＸＵＬ（ＸＭＬ  User  Interface  Language）又は任意の他の機能的に類似した表現を単独で又は組合せで含むが、これらに限定されない規格から導出されてよい。あるいは、専用のデータ構造、フォーマット又はスキーマが排他的に、あるいは既知の又はオープンな規格との組合せで使用されてもよい。
【０１２０】
いくつかの実施形態において、その上に記憶された制御ロジック（ソフトウェア）を有する、有形の非一時的なコンピュータ使用可能又は読取可能な媒体を含む、有形の非一時的な装置又は製品は、本明細書において、コンピュータプログラム製品又はプログラムストレージデバイスと称されることもある。これは、コンピュータシステム４０００、メインメモリ４００８、二次メモリ４０１０及び取り外し可能ストレージユニット４０１８及び４０２２、並びに上記のいずれかの組合せを具体化する有形の製品が含まれるが、これらに限定されない。そのような制御ロジックは、１つ以上のデータ処理デバイス（コンピュータシステム４０００等）によって実行されるとき、本明細書で記載されるように、そのようなデータ処理デバイスを動作させることができる。
【０１２１】
本開示に含まれる教示に基づいて、図４０に示されるもの以外のデータ処理デバイス、コンピュータシステム又はコンピュータ・アーキテクチャを用いて、本開示の実施形態をどのように作製し、使用するかは、当業者に明らかであろう。特に、実施形態は、本明細書に記載されているもの以外のソフトウェア、ハードウェア及び／又はオペレーティングシステムの実装で動作することができる。
【０１２２】
結論
詳細な説明のセクションは、他のセクションではなく、クレームを解釈するために使用されるように意図されていることが理解されよう。他のセクションは、本発明者によって考慮される、すべてではないが１つ以上の例示の実施形態を説明することができ、したがって、本開示又は添付の特許請求の範囲をいかなるようにも限定するようには意図されていない。
【０１２３】
本開示は、例示の分野及び用途の例示の実施形態を記載しているが、本開示はそれに限定されないことを理解されたい。他の実施形態及びそれに対する修正が可能であり、本開示の範囲及び精神内にある。例えば本段落の一般性を制限することなく、実施形態は、図面に図示されるか、本明細書で説明されるソフトウェア、ハードウェア、ファームウェア又はエンティティに限定されない。さらに、実施形態（本明細書で明示的に説明されているか否かにかかわらず）は、本明細書で説明される実施例を超える分野及び用途に対して有意な有用性を有する。
【０１２４】
本明細書では、特定の機能の実施及びそれらの関係を例示する機能的構築ブロックを用いて、実施形態を説明した。これらの機能的構成要素の境界は、説明の便宜上、本明細書中で任意に定義されている。特定の機能と関係（又はその均等物）が適切に実施される限り、別の境界を定義することができる。また、代替の実施形態は、本明細書で説明されるものとは異なる順序を使用して、機能ブロック、ステップ、動作、方法等を実行することができる。
【０１２５】
本明細書において、「一実施形態」、「ある実施形態」、「例示の実施形態」又は類似のフレーズへの言及は、説明された実施形態が特定の特徴、構造又は特性を含むことができるが、すべての実施形態が必ずしも特定の特徴、構造又は特性を含まない可能性があることを示す。そのようなフレーズは、必ずしも同一の実施形態を指していない。さらに、特定の特徴、構造又は特性がある実施形態に関連して説明されるとき、このような特徴、構造又は特性を、本明細書に明示的に記載又は説明されているか否かにかかわらず、他の実施形態に組み込むことは当業者の知識の範囲内であろう。さらに、いくつかの実施形態は、「結合された（coupled）」及び「接続された（connected）」という表現をそれらの派生語とともに使用して説明される可能性がある。これらの用語は、必ずしも互いに同義語として意図されているわけではない。例えばいくつかの実施形態は、２つ以上の要素が互いに直接的に物理的又は電気的に接触していることを示すために、「接続された」又は「結合された」という用語を使用して説明されることができる。しかしながら、用語「結合された」は、２つ以上の要素が互いに直接接触していないが、依然として相互に協働又は相互作用していることも意味する可能性がある。
【０１２６】
本開示の広さ及び範囲は、上述の例示の実施形態のいずれによっても制限されるべきではなく、以下の特許請求の範囲及びそれらの均等物に従ってのみ定義されるべきである。
【図１】
2020053052.tif 000003
【図２】
2020053052.tif 000004
【図３】
2020053052.tif 000005
【図４】
2020053052.tif 000006
【図５】
2020053052.tif 000007
【図６】
2020053052.tif 000008
【図７】
2020053052.tif 000009
【図８】
2020053052.tif 000010
【図９】
2020053052.tif 000011
【図１０】
2020053052.tif 000012
【図１１】
2020053052.tif 000013
【図１２】
2020053052.tif 000014
【図１３】
2020053052.tif 000015
【図１４】
2020053052.tif 000016
【図１５】
2020053052.tif 000017
【図１６】
2020053052.tif 000018
【図１７】
2020053052.tif 000019
【図１８】
2020053052.tif 000020
【図１９】
2020053052.tif 000021
【図２０】
2020053052.tif 000022
【図２１】
2020053052.tif 000023
【図２２】
2020053052.tif 000024
【図２３】
2020053052.tif 000025
【図２４】
2020053052.tif 000026
【図２５】
2020053052.tif 000027
【図２６】
2020053052.tif 000028
【図２７】
2020053052.tif 000029
【図２８】
2020053052.tif 000030
【図２９】
2020053052.tif 000031
【図３０】
2020053052.tif 000032
【図３１】
2020053052.tif 000033
【図３２】
2020053052.tif 000034
【図３３】
2020053052.tif 000035
【図３４】
2020053052.tif 000036
【図３５】
2020053052.tif 000037
【図３６】
2020053052.tif 000038
【図３７】
2020053052.tif 000039
【図３８】
2020053052.tif 000040
【図３９】
2020053052.tif 000041
【図４０】
2020053052.tif 000042
【外国語明細書】
2020053052000001.pdf