▶ セールスフォース ドット コム インコーポレイティッドの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-11-22
(45)【発行日】2023-12-01
(54)【発明の名称】コマース・アーキテクチャのためのユーザインタフェース
(51)【国際特許分類】
G06F 3/04847 20220101AFI20231124BHJP
G06F 3/04842 20220101ALI20231124BHJP
G06F 3/0482 20130101ALI20231124BHJP
G06F 16/21 20190101ALI20231124BHJP
G06F 8/34 20180101ALI20231124BHJP
【ＦＩ】
G06F3/04847
G06F3/04842
G06F3/0482
G06F16/21
G06F8/34
【請求項の数】
23
【外国語出願】
(21)【出願番号】P 2019173421
(22)【出願日】2019-09-24
(65)【公開番号】P2020053052
(43)【公開日】2020-04-02
【審査請求日】2022-05-06
(31)【優先権主張番号】62/735671
(32)【優先日】2018-09-24
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】16/264391
(32)【優先日】2019-01-31
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】506332063
【氏名又は名称】セールスフォース インコーポレイテッド
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100091214
【弁理士】
【氏名又は名称】大貫 進介
(72)【発明者】
【氏名】デイヴィッド ジェームズ ウッドワード
(72)【発明者】
【氏名】アビナフ チャッダ
(72)【発明者】
【氏名】デイヴィッド ハッカー
(72)【発明者】
【氏名】スティーブン ネス
(72)【発明者】
【氏名】マット ラグロッテ
(72)【発明者】
【氏名】ジェイソン ムーディ
(72)【発明者】
【氏名】クリストファー ビル
(72)【発明者】
【氏名】カウストゥバ バーデ
(72)【発明者】
【氏名】リディア ロドヴィージ
(72)【発明者】
【氏名】サラ フラミオン
(72)【発明者】
【氏名】ジャミン ホール
【審査官】上田 泰
(56)【参考文献】
【文献】米国特許第０９４３０１１４（ＵＳ，Ｂ１）
【文献】特開２００２－０４１７８１（ＪＰ，Ａ）
【文献】特開２００５－０４４１１５（ＪＰ，Ａ）
【文献】米国特許第０８５６０４９４（ＵＳ，Ｂ１）
【文献】特開２００６－０３９５９７（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１６／０３５８３５４（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１２／０２４６５１９（ＵＳ，Ａ１）
【文献】特開２００４－２５９０６６（ＪＰ，Ａ）
【文献】特開２００７－１３３５０３（ＪＰ，Ａ）
【文献】特開２０１０－１９８２９６（ＪＰ，Ａ）
【文献】特表２００８－５１１９３４（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１３／０２９０２４４（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１７／０２８６５２５（ＵＳ，Ａ１）
【文献】米国特許第０８８０５９４６（ＵＳ，Ｂ１）
【文献】米国特許出願公開第２０１８／０２５３６６９（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１７／０２２０６９８（ＵＳ，Ａ１）
【文献】特表２０１１－５０１８３４（ＪＰ，Ａ）
【文献】米国特許出願公開第２００５／０１３１９２０（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ ３／０４８２ － ３／０４８４７
Ｇ０６Ｆ １６／１３
Ｇ０６Ｆ １６／１７
Ｇ０６Ｆ １６／２１
Ｇ０６Ｆ １６／９０３８－１６／９０４
Ｇ０６Ｆ ８／３４
(57)【特許請求の範囲】
【請求項1】
コンピューティングデバイスによって、第１データソースを追加するための第１ボタンと、第２データソースを追加するための第２ボタンとを備えるグラフィカルユーザインタフェース（ＧＵＩ）を提供するステップであって、前記第１及び第２データソースは、共通の顧客に関連する顧客レコードを備える、ステップと；前記コンピューティングデバイスによって、前記第１ボタンを介して前記第１データソースを追加するための第１応答と、前記第２ボタンを介して前記第２データソースを追加するための第２応答を受け取るステップと；
前記コンピューティングデバイスによって、前記ＧＵＩ内に第１データスキーマ及び第２データスキーマのビューを提供するステップであって、前記第１データスキーマは、前記第１又は第２データソースからの前記顧客レコードの第１量を示す第１値を表示する少なくとも１つの第１オブジェクトを含み、前記第２データスキーマは、前記顧客レコードのカノニカルデータモデルであるステップと；
前記コンピューティングデバイスによって、前記ＧＵＩ内で１つ以上のビジュアル論理コネクタを用いて、属性定義に基づいて、前記第１データスキーマの前記第１量の前記顧客レコードを前記第２データスキーマの前記顧客レコードの前記カノニカルデータモデルの少なくとも１つの第２オブジェクトにマッピングするステップであって、前記１つ以上のビジュアル論理コネクタは、前記第１データスキーマの前記少なくとも１つの第１オブジェクトと、前記第２データスキーマの前記少なくとも１つの第２オブジェクトとの間でマッピングされた顧客レコードの第２量を表示する、ステップと；
前記コンピューティングデバイスによって、前記ＧＵＩ内において、前記第１量の前記顧客レコードのうち、前記第１量と前記第２量との間の差により、マッピングされていない顧客レコードを識別するステップと；
前記コンピューティングデバイスによって、前記ＧＵＩ内において、前記マッピングされていない顧客レコードが現れるように、前記第１量の前記顧客レコードを有する前記少なくとも１つの第１オブジェクトを展開するステップと；
前記コンピューティングデバイスによって、前記ＧＵＩ内において、前記マッピングされていない顧客レコードに対応する新たなレコードを、前記第２データスキーマの前記少なくとも１つの第２オブジェクトに追加するステップと；
を含む、方法。
【請求項2】
前記コンピューティングデバイスによって、前記カノニカルデータモデルの前記少なくとも１つの第２オブジェクトにおいて、前記少なくとも１つの第２オブジェクト内の前記顧客レコードの数を示す第３量を表示するステップを更に含む、
請求項１に記載の方法。
【請求項3】
前記コンピューティングデバイスによって、前記共通の顧客について前記第２データスキーマの前記少なくとも１つの第２オブジェクトの単一のエンティティビューを提供するステップであって、前記単一のエンティティビューは、前記共通の顧客に関連する前記第１及び第２データソースからの前記顧客レコードと、前記顧客レコードに対応する前記第１及び第２データソースを含む、ステップ、を更に含む、請求項１に記載の方法。
【請求項4】
単一のエンティティビューを提供するステップは、複数のフォーマッティングルールに基づいて、前記第１データスキーマの前記少なくとも１つの第１オブジェクトを変換するステップと、
複数のマッチングルールに基づいて、前記第１データスキーマの前記顧客レコードの前記少なくとも１つの第１オブジェクトと前記第２データスキーマの前記顧客レコードの前記カノニカルデータモデルの前記少なくとも１つの第２オブジェクトとの間の一致を決定するステップと、
複数の更新ルールに基づいて、前記第１データスキーマの前記顧客レコードの前記少なくとも１つの第１オブジェクトのマスターレコードとして前記第２データスキーマの前記顧客レコードの前記カノニカルデータモデルの前記少なくとも１つの第２オブジェクトを更新するステップと、
を更に含む、請求項３に記載の方法。
【請求項5】
前記コンピューティングデバイスによって、データ管理要求に応答して、前記ＧＵＩにおいて、前記第２データスキーマの前記顧客レコードの前記カノニカルデータモデルの前記少なくとも１つの第２オブジェクトを管理するステップ、を更に含む、請求項１に記載の方法。
【請求項6】
前記データ管理要求は、前記共通の顧客のプライバシ情報を管理するために要求者によって提示される、請求項５に記載の方法。
【請求項7】
前記データ管理要求は、前記カノニカルデータモデルにおける前記共通の顧客に関連する２つの顧客レコードを、前記共通の顧客の単一のプロファイルに統合するために要求者によって提示される、請求項５に記載の方法。
【請求項8】
前記コンピューティングデバイスによって、前記共通の顧客に関連する第三者データソースを追加するための第３ボタンを前記ＧＵＩに提供するステップ、を更に含む、請求項１に記載の方法。
【請求項9】
アプリケーション・プログラミング・インタフェース（ＡＰＩ）を介して前記第三者データソースを追加するステップ、を更に含む、請求項８に記載の方法。
【請求項10】
前記コンピューティングデバイスによって、前記共通の顧客に対するデータソースのカテゴリのマッピングを前記ＧＵＩ内に表示するステップを更に含み、前記カテゴリは、該カテゴリ内のデータソースの量を視覚的に表示する、請求項１に記載の方法。
【請求項11】
前記コンピューティングデバイスによって、前記第１及び第２データソースから追加された合計顧客レコードの量と、前記顧客レコードの前記カノニカルデータモデルの固有の顧客レコードの量を表示するステップ、を更に含む、請求項１に記載の方法。
【請求項12】
前記コンピューティングデバイスによって、検索要求に応答して複数のレコードを表示するステップであって、前記複数のレコードの各々は、対応するデータソースを表示する、請求項１に記載の方法。
【請求項13】
メモリと；前記メモリに結合される少なくとも１つのプロセッサと；
を備え、前記少なくとも１つのプロセッサは、
第１データソースを追加するための第１ボタンと、第２データソースを追加するための第２ボタンとを備えるグラフィカルユーザインタフェース（ＧＵＩ）を提供することであって、前記第１及び第２データソースは、共通の顧客に関連する顧客レコードを備え、
前記第１ボタンを介して前記第１データソースを追加するための第１応答と、前記第２ボタンを介して前記第２データソースを追加するための第２応答を受け取り、
前記ＧＵＩ内に第１データスキーマ及び第２データスキーマのビューを提供することであって、前記第１データスキーマは、前記第１又は第２データソースからの前記顧客レコードの第１量を示す第１値を表示する少なくとも１つの第１オブジェクトを含み、前記第２データスキーマは、前記顧客レコードのカノニカルデータモデルであり、
前記ＧＵＩ内で１つ以上のビジュアル論理コネクタを用いて、属性定義に基づいて、前記第１データスキーマの前記第１量の前記顧客レコードを前記第２データスキーマの前記顧客レコードの前記カノニカルデータモデルの少なくとも１つの第２オブジェクトにマッピングすることであって、前記１つ以上のビジュアル論理コネクタは、前記第１データスキーマの前記少なくとも１つの第１オブジェクトと、前記第２データスキーマの前記少なくとも１つの第２オブジェクトとの間でマッピングされた顧客レコードの第２量を表示し、
前記ＧＵＩ内において、前記第１量の前記顧客レコードのうち、前記第１量と前記第２量との間の差により、マッピングされていない顧客レコードを識別し、
前記ＧＵＩ内において、前記マッピングされていない顧客レコードが現れるように、前記第１量の前記顧客レコードを有する前記少なくとも１つの第１オブジェクトを展開し、
前記ＧＵＩ内において、前記マッピングされていない顧客レコードに対応する新たなレコードを、前記第２データスキーマの前記少なくとも１つの第２オブジェクトに追加する、
ように構成される、システム。
【請求項14】
前記少なくとも１つのプロセッサは、前記共通の顧客について前記第２データスキーマの前記少なくとも１つの第２オブジェクトの単一のエンティティビューを提供するように更に構成され、前記単一のエンティティビューは、前記共通の顧客に関連する前記第１及び第２データソースからの前記顧客レコードと、前記顧客レコードに対応する前記第１及び第２データソースを含む、
請求項１３に記載のシステム。
【請求項15】
前記単一のエンティティビューを提供することは、複数のフォーマッティングルールに基づいて、前記第１データスキーマの前記少なくとも１つの第１オブジェクトを変換し、
複数のマッチングルールに基づいて、前記第１データスキーマの前記顧客レコードの前記少なくとも１つの第１オブジェクトと前記第２データスキーマの前記顧客レコードの前記カノニカルデータモデルの前記少なくとも１つの第２オブジェクトとの間の一致を決定し、
複数の更新ルールに基づいて、前記第１データスキーマの前記顧客レコードの前記少なくとも１つの第１オブジェクトのマスターレコードとして前記第２データスキーマの前記顧客レコードの前記カノニカルデータモデルの前記少なくとも１つの第２オブジェクトを更新すること、
を含む、請求項１４に記載のシステム。
【請求項16】
前記少なくとも１つのプロセッサは、データ管理要求に応答して、前記ＧＵＩにおいて、前記第２データスキーマの前記顧客レコードの前記カノニカルデータモデルの前記少なくとも１つの第２オブジェクトを管理するように更に構成される、請求項１３に記載のシステム。
【請求項17】
前記共通の顧客に関連する第三者データソースを追加するための第３ボタンを前記ＧＵＩに提供する、請求項１３に記載のシステム。
【請求項18】
アプリケーション・プログラミング・インタフェース（ＡＰＩ）を介して前記第三者データソースを追加する、請求項１７に記載のシステム。
【請求項19】
コンピューティングデバイスによって実行されると、該コンピューティングデバイスに、第１データソースを追加するための第１ボタンと、第２データソースを追加するための第２ボタンとを備えるグラフィカルユーザインタフェース（ＧＵＩ）を提供する動作であって、前記第１及び第２データソースは、共通の顧客に関連する顧客レコードを備える、動作と；
前記第１ボタンを介して前記第１データソースを追加するための第１応答と、前記第２ボタンを介して前記第２データソースを追加するための第２応答を受け取る動作と；
前記ＧＵＩ内に第１データスキーマ及び第２データスキーマのビューを提供する動作であって、前記第１データスキーマは、前記第１又は第２データソースからの前記顧客レコードの第１量を示す第１値を表示する少なくとも１つの第１オブジェクトを含み、前記第２データスキーマは、前記顧客レコードのカノニカルデータモデルである動作と；
前記ＧＵＩ内で１つ以上のビジュアル論理コネクタを用いて、属性定義に基づいて、前記第１データスキーマの前記第１量の前記顧客レコードを前記第２データスキーマの前記顧客レコードの前記カノニカルデータモデルの少なくとも１つの第２オブジェクトにマッピングする動作であって、前記１つ以上のビジュアル論理コネクタは、前記第１データスキーマの前記少なくとも１つの第１オブジェクトと、前記第２データスキーマの前記少なくとも１つの第２オブジェクトとの間でマッピングされた顧客レコードの第２量を表示する動作と；
前記ＧＵＩ内において、前記第１量の前記顧客レコードのうち、前記第１量と前記第２量との間の差により、マッピングされていない顧客レコードを識別する動作と；
前記ＧＵＩ内において、前記マッピングされていない顧客レコードが現れるように、前記第１量の前記顧客レコードを有する前記少なくとも１つの第１オブジェクトを展開する動作と；
前記ＧＵＩ内において、前記マッピングされていない顧客レコードに対応する新たなレコードを、前記第２データスキーマの前記少なくとも１つの第２オブジェクトに追加する動作と；
を含む動作を実行させる命令を有する、有形のコンピュータ読取可能デバイス。
【請求項20】
前記動作は、前記共通の顧客について前記第２データスキーマの前記少なくとも１つの第２オブジェクトの単一のエンティティビューを提供する動作であって、前記単一のエンティティビューは、前記共通の顧客に関連する前記第１及び第２データソースからの前記顧客レコードと、前記顧客レコードに対応する前記第１及び第２データソースを含む動作、を更に含む、請求項１９に記載のコンピュータ読取可能デバイス。
【請求項21】
前記単一のエンティティビューを提供する動作は、複数のフォーマッティングルールに基づいて、前記第１データスキーマの前記少なくとも１つの第１オブジェクトを変換する動作と、
複数のマッチングルールに基づいて、前記第１データスキーマの前記顧客レコードの前記少なくとも１つの第１オブジェクトと前記第２データスキーマの前記顧客レコードの前記カノニカルデータモデルの前記少なくとも１つの第２オブジェクトとの間の一致を決定する動作と、
複数の更新ルールに基づいて、前記第１データスキーマの前記顧客レコードの前記少なくとも１つの第１オブジェクトのマスターレコードとして前記第２データスキーマの前記顧客レコードの前記カノニカルデータモデルの前記少なくとも１つの第２オブジェクトを更新する動作と、
を更に含む、請求項２０に記載のコンピュータ読取可能デバイス。
【請求項22】
前記動作は、前記コンピューティングデバイスによって、データ管理要求に応答して、前記ＧＵＩにおいて、前記第２データスキーマの前記顧客レコードの前記カノニカルデータモデルの前記少なくとも１つの第２オブジェクトを管理する動作、を更に含む、請求項１９に記載のコンピュータ読取可能デバイス。
【請求項23】
前記動作は、前記共通の顧客に関連する第三者データソースを追加するための第３ボタンを前記ＧＵＩに提供する動作を更に含む、請求項１９に記載のコンピュータ読取可能デバイス。
【発明の詳細な説明】
【背景技術】
【0001】
関連出願の相互参照
本出願は、２０１８年９月２４日に出願された米国仮特許出願第６２／７３５，６７１号の優先権の利益を主張し、参照によってその全体が組み込まれる。
本出願は、２０１８年９月２４日に出願された米国仮特許出願第６２／７３５，６７１号の優先権の利益を主張し、参照によってその全体が組み込まれる。
【0002】
企業は、自社の製品やサービスの消費者についてのこれまで以上に多くのデータにアクセスできる。顧客関係管理（ＣＲＭ）システムの目的は、サプライチェーン内のすべてのサービスレベルで、このデータを効率的に管理し、容易にアクセスして共有できるようにすることである。しかしながら、従来のデータベース又はＣＲＭシステムでは、異なる分離されたソースからの顧客データを統合し、消費者についてのマスターレコードを作成することはできない。また、従来のシステムは、マルチテナントシステムにおいて、クエリを実行し、データを読み出し又は書き込むために、どこからデータを得るかを決定することも困難である。従来のシステムの別の問題は、データの起源（data provenance）、すなわち、レコード内のデータの１つ以上のソースを決定することである。さらに、従来のシステムは、データのための監査ログを提供することに苦労してきた。データの起源と監査ログは、プライバシー法を遵守するために不可欠である。従来のシステムはまた、異なる時間スケールのデータを統合し、異なるソースからのデータにアクセスし、データを比較し、それを調和（reconciling）させるという問題にも直面する。
【発明の概要】
【0003】
典型的なコマース／マーケティングシステムは、高ボリュームで低品質の消費者データを低ボリュームで高品質のデータに変換するために、管理者がコードを作成することを必要とする。このプロセスは、時間がかかり、高価で、エラーを起こしやすい可能性がある。顧客がオンライン・チェックアウト・カートにアイテムを残したままにするとき、すなわち、カートを放置するとき、管理者は、そのようなイベントを追跡して消費者へのフォローアップの電子メールを生成するために、大量のデータを解析するために特定のコードを書かなければならない。さらに、データは、独自のアプリケーション・プログラミング・インタフェース（ＡＰＩ）を有する異なるソースから来るので、管理者は、従来的に、各システムのＡＰＩを学んで、異なるシステムとインタフェースしてデータを取り出すためのクエリをプログラムしなければならないであろう。加えて、ほとんどのコマース・アーキテクチャシステムは、ポイントアンドクリック・ユーザインタフェースを提供する代わりに、システム管理者が多くの機能をプログラムする必要がある。本明細書に提示された実施形態は、特に、少なくともこれらの問題に対する解決策を提供する。
【図面の簡単な説明】
【0004】
本明細書に組み込まれ、明細書の一部を構成する添付の図面は、本実施形態を例示しており、以下の説明とともに、本実施形態の原理を説明し、当業者が本実施形態を作成して使用することを可能にするために更に役立つ。
【0005】
【図1】いくつかの実施形態による、Salesforce（登録商標）Customer 360のホームページのグラフィカルユーザインタフェース（ＧＵＩ）スクリーンショットを示す図である。
【0006】
【図2】いくつかの実施形態による、Salesforceデータソースと接続している、Salesforce Customer 360のＧＵＩスクリーンショットを示す図である。
【0007】
【図3】いくつかの実施形態による、統合ガイド（Integration Guides）を使用してクロスクラウドユースケースをセットアップするSalesforce Customer 360のＧＵＩスクリーンショットを示す図である。
【0008】
【図4】いくつかの実施形態による、統合ガイド（Integration Guides）を使用してコマース用サービスの有効化（Enable Service for Commerce）をセットアップするコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0009】
【図5】いくつかの実施形態による、コマース用サービスの有効化（Enable Service for Commerce）をセットアップするためにデータソースを接続するコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0010】
【図6】いくつかの実施形態による、例示の顧客のためにデータソースを接続するためのアクセスを認証するコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0011】
【図7】いくつかの実施形態による、例示の顧客のための接続されたデータソースについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0012】
【図8】いくつかの実施形態による、データソース・スキーマとカノニカルデータモデルとの間のデータマッピングのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0013】
【図9】いくつかの実施形態による、データソース・スキーマの１つの展開されたオブジェクトの下の例示のフィールドについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0014】
【図10】いくつかの実施形態による、カノニカルデータモデルの１つの展開されたエンティティの下の例示の属性についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0015】
【図11】いくつかの実施形態による、カノニカルデータモデルの展開されたエンティティに対する１つの属性の追加についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0016】
【図12】いくつかの実施形態による、データソース・スキーマの１つの展開されたオブジェクトの下の１つのフィールドを、カノニカルデータモデルのマップされたオブジェクトの下の追加された対応する属性にマッピングする、コマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0017】
【図13】いくつかの実施形態による、データソース・スキーマの１つの展開されたオブジェクトの下のフィールドと、カノニカルデータモデルのマッピングされたオブジェクトの下の追加された対応する属性との間のタイプ不一致についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0018】
【図14】いくつかの実施形態による、データソース・スキーマの下のフィールドと、カノニカルデータモデルの下の対応する属性との間のタイプ不一致を解決するための変換ルールセットアップについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0019】
【図15】いくつかの実施形態による、データ不一致を解決した後のデータソース・スキーマとカノニカルデータモデルとの間のデータマッピングについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0020】
【図16】いくつかの実施形態による、単一エンティティビューのためのデータ準備のコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0021】
【図17】いくつかの実施形態による、データ準備のための例示のデフォルト値をセットアップするコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0022】
【図18】いくつかの実施形態による、データ準備のために必要なセットアップを完了するコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0023】
【図19】いくつかの実施形態による、単一エンティティビューのマッチングルールについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0024】
【図20】いくつかの実施形態による、１つのマッチングルールに対する例示のマッチング基準のセットアップについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0025】
【図21】いくつかの実施形態による、１つのマッチングルールを編集するコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0026】
【図22】いくつかの実施形態による、マッチングルールの編集後のマッチプレビューについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0027】
【図23】いくつかの実施形態による、編集後のマッチングルールについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0028】
【図24】いくつかの実施形態による、単一エンティティビューのためのデータ調和ルールについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0029】
【図25】いくつかの実施形態による、１つの例示属性に対するデータ調和ルールについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0030】
【図26】いくつかの実施形態による、例示の属性に対するデータ調和ルールを編集するコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0031】
【図27】いくつかの実施形態による、例示の属性に対するデータ調和ルールの編集後のコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0032】
【図28】いくつかの実施形態による、データスチュワードシップについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0033】
【図29】いくつかの実施形態による、データスチュワードシップに対する例示の要求タイプの詳細についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0034】
【図30】いくつかの実施形態による、データスチュワードシップに対する例示の要求の詳細についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0035】
【図31】いくつかの実施形態による、データスチュワードシップの検索機能についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0036】
【図32】いくつかの実施形態による、データスチュワードシップの検索結果についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0037】
【図33】データスチュワードシップのための例示の顧客プロファイルについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0038】
【図34】いくつかの実施形態による、データソースとシステムとの間の接続についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0039】
【図35】いくつかの実施形態による、例示の第三者データをシステムに接続するコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0040】
【図36】いくつかの実施形態による、ＡＰＩを介して例示の第三者データをシステムに追加する詳細についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0041】
【図37】いくつかの実施形態による、第三者データソースとＡＰＩの接続についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0042】
【図38】いくつかの実施形態による、システムと、第三者データソースを含むデータソースとの間の接続についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す図である。
【0043】
【図39】いくつかの実施形態による、コマース・アーキテクチャＧＵＩをセットアップするためのフローチャートの例を示す図である。
【0044】
【図40】本明細書で提示される様々な実施形態を実施するために使用され得る例示のコンピュータシステムを示す図である。
【0045】
本実施形態の特徴及び利点は、図面と併せて考えると、以下で説明される詳細な説明からより明らかになるであろう。図面では、全体を通して同様の参照符号が対応する要素を識別する。図面において、同様の参照番号は一般に、同一の要素、機能的に類似の要素及び／又は構造的に類似の要素を示す。要素が最初に現れる図面は、対応する参照番号の左端の数字で示される。
【発明を実施するための形態】
【0046】
本明細書では、コマース・アーキテクチャ・ユーザインタフェースのための方法、システム及び／又はコンピュータプログラム製品の実施形態及び／又はそれらの組合せ及び副次的組合せが提供される。
【0047】
本明細書に開示されるコマース・アーキテクチャのグラフィカルユーザインタフェース（ＧＵＩ）を使用して、ユーザは、ポイント・アンド・コネクトＡＰＩを介して第三者データソースを含む様々なデータソースを接続し、様々なデータソースからの消費者データをカノニカルデータモデルのレコードにマッピングし、ポイント・アンド・クリック・ユーザインタフェース及びアウト・オブ・ボックス機能を介して単一エンティティビューのためにマッチングルール及びデータ調和ルールを定義することができる。また、データスチュワードシップ（data stewardship）は、顧客要求又はシステム推奨に応じて、カノニカルデータモデルにおける消費者データのマスターレコードのクエリ結果だけでなくデータ管理を提供することができる。図１～図３８は、いくつかの実施形態による、コマース・アーキテクチャＧＵＩをセットアップするステップを提供する。
【0048】
本明細書において、「カノニカル（canonical）」とは、ソフトウェア内のオブジェクト又はオブジェクトのリストのように、データの順序又は構造を表現する標準的な形式又は標準的な方法を指す。ここで、「カノニカル」は、一般的に、カノニカルデータスキーマを記述するために、より具体的には、他のデータスキーマのためのテンプレートを提供するカノニカルデータモデルを記述するために使用されてもよい。対照的に、「アカノニカル（acanonical）」とは、テナント固有のデータソース・スキーマのように、データの順序又は構造が一意又は非標準的な表現を有するような表現を指す。また、次の用語を使用してデータスキーマ内の要素を記述することができる。
【0049】
データソース：顧客情報のデータベースを管理する部門、子会社又はベンダー、あるいは一般的にテナント等の企業組織；テナントからの顧客情報の特定のデータベース
【0050】
テナント：ＣＲＭシステムで管理されるデータセンターを有する企業組織
【0051】
スキーマ：例えばモデルの形式のデータの表現（例えば構造及び／又はデータベース編成）
【0052】
オブジェクト：顧客データのカテゴリ、例えば具体的には連絡先情報又はアカウント情報等のように、ＣＲＭシステムにおいてコンピュータによって使用され得る何かの記述を提供するデータ構成又はレコード；オブジェクトは、情報のサブカテゴリのいくつかのフィールドを含んでよい
【0053】
フィールド：カノニカルエンティティの属性やデータソースオブジェクト内のデータのセクション等のように、情報のプレースホルダとして機能するデータレコードの一部
【0054】
属性：カノニカルスキーマのエンティティ内のように、フィールドの特性又は内容を決定する情報の断片
【0055】
エンティティ：関連する又は類似の属性のフィールドを含むデータレコード
【0056】
グループ：一緒に近接して配置されるもの及び／又は一緒にクラス分類されるもののように、接続された関係にある複数のエンティティ
【0057】
図１は、いくつかの実施形態による、エンプティ状態、すなわち、コマース・アーキテクチャをセットアップするプロセスの開始時における、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のＧＵＩは、従来のシステムでは管理者が機能をセットアップするために多くをプログラムする必要がある、ほとんどのコマース・アーキテクチャシステムについて、ポイント・アンド・クリックのユーザインタフェースを顧客に提供することができる。
【0058】
図２は、いくつかの実施形態による、Salesforceデータソースと接続している、Salesforce Customer 360のＧＵＩのスクリーンショットを示す。図２の例では、Salesforceデータ（Salesforce Data）２０１は、セールスクラウド（Sales Cloud）２１１、コミュニティクラウド（Community Cloud）２１３、マーケティングクラウド（Marketing Cloud）２１５、コマースクラウド（Commerce Cloud）２１７及びサービスクラウド（Service Cloud）２１９のような異なるソースからのデータを統合することができる。戻る（Back）ボタン２０３をクリックした後、ＧＵＩは、図１に図示されるホーム画面に戻ることができる。
【0059】
統合ガイド
図３は、いくつかの実施形態による、統合ガイド（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）をクリックすると、ＧＵＩはコマース・アーキテクチャのセットアップを開始することができる。
図３は、いくつかの実施形態による、統合ガイド（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）をクリックすると、ＧＵＩはコマース・アーキテクチャのセットアップを開始することができる。
【0060】
図４は、いくつかの実施形態による、統合ガイドを使用してコマース用サービスの有効化をセットアップするコマース・アーキテクチャＧＵＩスクリーンショットを示す。コマース用サービスの有効化の現在のステップが４０１に示されており、コマース用サービスの有効化４０１の下のガイド変更（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）」といった、次のアクションを強調表示することができる。
【0061】
データソースの追加
図５～図７は、いくつかの実施形態による、データソースに接続しているコマース・アーキテクチャＧＵＩスクリーンショットを示す。図５は、いくつかの実施形態による、コマース用サービスの有効化をセットアップするためにデータソースを接続するコマース・アーキテクチャＧＵＩスクリーンショットを示す。セットアップ５０５のデータソース（Data Sources）タブが強調表示されており、情報ヘッダ５０２もデータソースの追加（Add a Data Source）に更新されている。コマース用サービスの有効化をセットアップする例では、少なくとも２つのデータソース、すなわちコマースクラウド（Commerce Cloud）５０３とサービスクラウド（Service Cloud）５０７に接続する必要がある。コマースクラウド５０３の接続（Connect）をクリックすると、コマースクラウドを追加するプロセスが開始されることになる。
図５～図７は、いくつかの実施形態による、データソースに接続しているコマース・アーキテクチャＧＵＩスクリーンショットを示す。図５は、いくつかの実施形態による、コマース用サービスの有効化をセットアップするためにデータソースを接続するコマース・アーキテクチャＧＵＩスクリーンショットを示す。セットアップ５０５のデータソース（Data Sources）タブが強調表示されており、情報ヘッダ５０２もデータソースの追加（Add a Data Source）に更新されている。コマース用サービスの有効化をセットアップする例では、少なくとも２つのデータソース、すなわちコマースクラウド（Commerce Cloud）５０３とサービスクラウド（Service Cloud）５０７に接続する必要がある。コマースクラウド５０３の接続（Connect）をクリックすると、コマースクラウドを追加するプロセスが開始されることになる。
【0062】
図６は、いくつかの実施形態による、例示の顧客のためにデータソースを接続するためのアクセスを認証するコマース・アーキテクチャＧＵＩスクリーンショットを示す。データソースに接続することは、ユーザからの認証を必要とする。図６の例では、Crocs（登録商標） USのコマースクラウドに接続するには、ユーザの基本情報へのアクセス、ユーザのデータへのアクセス及び管理等のような、認証データ６０１へのアクセスのユーザの許可が必要である。拒否（Deny）６０３をクリックすると、アクセスを許可せずに統合プロセスを終了する。許可（Allow）６０７をクリックすると、Crocs USのコマースクラウドからのアクセスを許可し、データをシステムに統合することになる。
【0063】
図７は、いくつかの実施形態による、例示の顧客のための接続されたデータソースのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図７の例では、接続されたデータソースが、データソース（Data Sources）７０３内に列挙されている。データソースの合計数及びデータソースのソートが、すべてのデータソース（All Data Sources）７０７の下に表示されている。各データソース７０９は、データソースの名前（Name）、タイプ（Type）、ドメイン（Domain）及びプロダクション（Production）を含むことができる。また、各データソース７０９は、名前フィールド内に、データソースのタイプを示す関連アイコン、例えばコマースクラウドに対するショッピングカート及びサービスクラウドに対するハートを有することができる。図像は、ＧＵＩ内での選択に利用可能な多数のデータソースに基づくことができる。データソースは、ＣＲＭシステムの様々なアプリケーションに基づいてよく、各アプリケーション及び各データソースは、異なる及び／又は特有の目的を有してよい。データソースの追加（Add Data Source）７１１をクリックすることによって、より多くのデータソースをシステムに追加することができる。いくつかの実施形態によると、コマース・アーキテクチャを設定するために、少なくとも１つのコマースクラウド及び１つのサービスクラウドをシステムに接続する必要がある。少なくとも１つのコマースクラウド及び１つのサービスクラウドを追加した後、次のステップは、情報ヘッダ７０２に示されているように、データをマップ（Map Data）７１３をクリックすることによってデータをマッピングすることである。
【0064】
データマッピング
図８～図１５は、いくつかの実施形態による、データマッピングを設定するコマース・アーキテクチャＧＵＩスクリーンショットを示す。データマッピング及び変換の例は、参照によってその全体が本明細書に組み込まれる２０１８年７月１７日出願の米国特許出願第１６／０３７，４３５号にみられる。
図８～図１５は、いくつかの実施形態による、データマッピングを設定するコマース・アーキテクチャＧＵＩスクリーンショットを示す。データマッピング及び変換の例は、参照によってその全体が本明細書に組み込まれる２０１８年７月１７日出願の米国特許出願第１６／０３７，４３５号にみられる。
【0065】
図８は、いくつかの実施形態による、データソース・スキーマとカノニカルデータモデルとの間のデータマッピングのコマース・アーキテクチャＧＵＩスクリーンショットを示す。このステップでは、ＧＵＩの左側にあるセットアップ８０５の下のデータマッピング（Data Mapping）タブを強調表示することができる。そして、ＧＵＩの最上部にある情報ヘッダ８０２は、マッピング推奨に関するガイダンスをユーザに提供することができる。図８の例では、ユーザには、標準属性定義に基づいて一束のデフォルトマッピングが行われること、追加のカスタム・フィールドをユーザがマッピングする必要があることが知らされる。図８のデータマッピング（Data Mapping）８０３には、いくつかのデフォルトマッピングが示されている。ＧＵＩの中央列の変換（Transformation）８０９内の複数のピル８２１は、データソース・スキーマ（Data Source Schema）８０７の１つ以上のオブジェクトから、カノニカルデータモデル（Canonical Data Model）８１１の１つ以上のエンティティ又は複数のエンティティのグループとそれらの属性への既存のデータマッピングの数を示す。例えばデータソース・スキーマ８０７のデータソース：Crocs Service US８１３のオブジェクト：Person８１７は、カノニカルデータモデル８１１のエンティティグループ：Consumer８１５のエンティティ：Individual８２５にマッピングされる。データソース・スキーマ８０７のオブジェクト：Person８１７は、例えば「電子メール：個人（Email: Personal）」及び「電話：モバイル（Phone: Mobile）」を含む複数の属性を有するエンティティ：CONTACT POINTS８２７にもマッピングされる。コマース・アーキテクチャＧＵＩは、ユーザが前述のような属性を検索することを可能にする検索ボックス８２９も有する。
【0066】
ＧＵＩのデータマッピング８０３は、データソース・スキーマ８０７とカノニカルデータモデル８１１との間で作成されたデータマッピングの数に関して、ユーザに有用な情報を提供することができる。例えばデータマッピング情報は、複数のピル８２１、オブジェクト、ピル及びエンティティ表現の内側に、並びにオブジェクト、ピル、エンティティ表現の間にこれらの表現を結ぶ線の形態で提供され得る。例えばデータソース・スキーマ８０７のオブジェクト：Person８１７の表現は、オブジェクト：Person８１７の１４個のフィールド８１８がカノニカルデータモデル８１１に接続される必要があることを示し、データソース・スキーマ８０７のオブジェクト：Account８１９は、オブジェクト：Account８１９の１３個のフィールドがカノニカルデータモデル８１１に接続される必要があることを示す。オブジェクト：Person８１７からの線に従うことにより、ユーザは、ＧＵＩの左側のこのオブジェクトとＧＵＩの右側のエンティティとの間の関係コネクタを見ることができる。
【0067】
これらの関係コネクタは、「ビジュアル論理コネクタ」とも呼ばれ、ユーザについて、そのオブジェクトからのマッピングの数又は量を要約することができる。例えばオブジェクト：Person８１７の１４個のフィールド８１８は、データソース・スキーマ８０７のオブジェクト：Person８１７から複数のピル８２１のうちの１４個のピルへの接続を示す。複数のピル８２１の各々は、カノニカルデータモデル８１１内のエンティティに対して行われたデータマッピングの数を列挙する。例えば一番上のピル８２３は、エンティティ：Individual８２５への９個の接続又はマッピングを示す。これらの９個の接続は、マップされるエンティティ：Individual８２５内の属性の数又は量を表す。また、エンティティ：Individual８２５は、このエンティティを展開した場合にエンティティ：Individual８２５の下で見ることができる９個のマップされた属性が存在することを示すために、数字９を表示している。全体では、（一番上のピル８２３から下に読むと）９＋１＋１＋１＋１（＝１３）の接続がある。オブジェクト：Person８１７について、レコード：Personの１４個のフィールドと、オブジェクト：Personに接続される１３個の接続ピルとの間に、接続差が１つ存在する。これは、マップすべき、ファイルされた追加のカスタムが１つあることを示す。
【0068】
多数のマッピングが存在する可能性があるため、ユーザは各オブジェクト又はエンティティを展開することができ、これは、ユーザが、フィールドレベルでそれぞれのオブジェクト又はエンティティの下のマッピングを見ることを可能にする。
【0069】
図９は、いくつかの実施形態による、データソース・スキーマの１つの展開されたオブジェクトの下の例示のフィールドについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図９に図示されるように、データソース・スキーマ９０７のデータソース：Crocs Service US９１３のオブジェクト：Person９１７を展開して、スキーマ内のオブジェクトに関する更なる詳細、例えばオブジェクト９１７のReward Level９１９、Customer No、Creation Date、First Name及びLast Nameを明らかにすることができる。データソース・スキーマ９０７のデータソース：Crocs Service US９１３からのオブジェクト：Person９１７のReward Level９１９は、カノニカルデータモデル９１１のいかなる属性にもマップされていないことが分かる。
【0070】
図１０は、いくつかの実施形態による、カノニカルデータモデルの１つの展開されたエンティティの下の例示の属性についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図１０の例では、カノニカルデータモデル１０１１のエンティティグループ：Consumer１０１５のエンティティ：Individual１０２５を展開して、展開された属性の下部に、エンティティに関する更なる詳細、例えばSource Guide、Create Date、First Name、Last Name及びEdit List（リストの編集）１０２７を明らかにすることができる。Edit List（リストの編集）１０２７をクリックすることによって、新しい属性を属性リストに追加し、データソース・スキーマ１００７のマップされていないフィールドに接続することができる。
【0071】
図１１は、いくつかの実施形態による、カノニカルデータモデルの展開されたエンティティに対する１つの属性の追加についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。カノニカルデータモデルのエンティティの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)である。属性リストの編集が終了すると、ユーザは出口１１３５をクリックしてデータマッピングに戻ることができる。
【0072】
図１２は、いくつかの実施形態による、データソース・スキーマの１つの展開されたオブジェクトの下の１つのフィールドを、カノニカルデータモデルのマップされたオブジェクトの下の追加された対応する属性にマッピングする、コマース・アーキテクチャＧＵＩスクリーンショットを示す。カノニカルデータモデル１２１１に新しい属性を追加した後、データソース・スキーマ１２０７内のマップされていないフィールドは、マップされていないフィールドと、対応する新しい属性を単にクリックすることによって、新しい属性に接続され得る。例えば図１２において、エンティティ：Individual１２２５は、Reward Score１２３１の追加による属性の更新された数を示すために、数字９を数字１０に更新する。そして、オブジェクト：Person１２１７のReward Level１２１９と、エンティティ：Individual１２２５のReward Score１２３１をクリックした後、破線１２３３はそれらを接続して、Reward Level１２１９のReward Score１２３１へのマッピングを示す。
【0073】
図１３は、いくつかの実施形態による、データソース・スキーマの１つの展開されたオブジェクトの下のフィールドと、カノニカルデータモデルのマッピングされたオブジェクトの下の追加された対応する属性との間のタイプ不一致についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図１３の例では、新しいピル１３３３が、オブジェクト：Person１３１７のReward Level１３１９とエンティティ：Individual１３２５のReward Score１３３１のマッピングとともに追加されている。そして、ピル１３３３内の数字１は、エンティティ１３１５の属性：Reward Score１３３１への１つの接続又はマッピングを示し、ピル１３３３内のエクスクラメーションマークは、接続エラーを示す。
【0074】
ユーザがピル、例えばピル１３３３をクリックすると、ＧＵＩは、変換エディタ１３３４を開くことができる。変換エディタ１３３４は、１つのエラーメッセージ１３３５、変換ルールエディタボックス１３３６、データソース・スキーマ１３０７のフィールドとカノニカルデータモデル１３１１のマッピングされた属性との間の現在のデータ変換の表示、そして変換されたデータのサンプルを有する変換プレビューウィンドウ１３３９を有する。例えばピル１３３３について、エラーメッセージ１３３５は、フィールドタイプの不一致（Field type mismatch）を示している。そして、データソース・スキーマのReward LevelのフィールドタイプはString(255) １３３７であり、カノニカルデータモデルのReward ScoreのフィールドタイプはInteger(5) １３３８である。
【0075】
図１４は、いくつかの実施形態による、データソース・スキーマの下のフィールドと、カノニカルデータモデルの下の対応する属性との間のタイプ不一致を解決するための変換ルールセットアップについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。変換ルールエディタ１４３６は、データソース・スキーマの１つのフィールドとカノニカルデータモデルの対応する属性との間の不一致を解決するように編集することができる。図１４に示されるように、変換ルールエディタ１４３６では、簡単なコードを使用してフィールドタイプの不一致を解消する。いくつかの実施形態では、コードを書く代わりに、基本的な不一致解決機能を提供することができる。変換プレビュー（Transformation Preview）ウィンドウ１４３９は、変換されたデータのリストを、レコードＩＤ（Record ID）、各レコードＩＤの名前を示すソースデータ（Source Data）及びカノニカルデータモデル１４１１に現れるような各レコードＩＤのReward Scoreを示す変換されたデータ（Transformed Data）の特定の列とともに表示する。例えばReward Levelのフィールドタイプとしてソースデータ（Source Data）列内にSilverを含むレコード８９２０７は、変換されたデータ（Transformed Data）列内のカノニカルデータモデル１４１１のReward Score：２５にマップされる。
【0076】
図１５は、いくつかの実施形態による、データ不一致を解決した後のデータソース・スキーマとカノニカルデータモデルとの間のデータマッピングについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図１５に図示されるように、フィールドタイプの不一致が解決された後、データソース・スキーマ１５０７の下のデータソース：Crocs Service US１５１３内のエンティティ：Person１５１７のReward Level１５１９は、カノニカルデータモデル１５１１の下のエンティティグループ：Consumer１５１５内のエンティティ：Individual１５２５内のReward Score１５３１にマッピングされる。ピル１５３３は、Reward Level１５１９とReward Score ５３１との間の１つの接続又はマッピングを示しており、エクスクラメーションマークはない。
【0077】
単一エンティティビュー
図１６～図２６は、いくつかの実施形態による、単一顧客ビューとも呼ばれる単一エンティティビューを構築するためのデータ準備、マッチングルール、データ調和ルール及び顧客更新ルールを示す。図１６は、いくつかの実施形態による、単一エンティティビューのためのデータ準備のコマース・アーキテクチャＧＵＩスクリーンショットを示す。このステップでは、セットアップ１６０５の下のデータ準備（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（セットアップ要求）１６２７を示している。
図１６～図２６は、いくつかの実施形態による、単一顧客ビューとも呼ばれる単一エンティティビューを構築するためのデータ準備、マッチングルール、データ調和ルール及び顧客更新ルールを示す。図１６は、いくつかの実施形態による、単一エンティティビューのためのデータ準備のコマース・アーキテクチャＧＵＩスクリーンショットを示す。このステップでは、セットアップ１６０５の下のデータ準備（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（セットアップ要求）１６２７を示している。
【0078】
図１７は、いくつかの実施形態による、データ準備のための例示のデフォルト値をセットアップするコマース・アーキテクチャＧＵＩスクリーンショットを示す。図１６のセットアップ要求（Setup Required）１６２７をクリックした後、新たなエディタウィンドウ１７０３は、要求されるセットアップを表示することができる。例えば図１７では、接続されたデータソースについてデフォルトの国のセットアップを要求する、デフォルトの国の設定（Set Default County）ウィンドウ１７０３がＧＵＩに表示されている。データソース１７０７と、アドレス用のデフォルトの国（Default Country for Address）１７０９が、デフォルトの国を設定するために含まれる。例えばNTO North America１７３３は、カナダ又は米国から選択してデフォルトの国を設定する必要がある。各データソースのデフォルトの国をセットアップした後、ユーザは、保存及びアクティベート（Save & Activate）１７１５をクリックして、各データソースのデフォルトの国の設定を終了することができる。
【0079】
図１８は、いくつかの実施形態による、データ準備のために必要なセットアップを完了するコマース・アーキテクチャＧＵＩスクリーンショットを示す。図１８に図示される例では、Address Cleansing and Normalization１８１５が、図１７の必要なデフォルト国のセットアップを完了した後、ステータス１８１１が、セットアップ要求（Setup Required）１６１９からアクティブ（Active）１８１９に更新される。また、Phone Cleansing and Normalization１８２３は、メッセージボックス１８３１に示されるようなデフォルトの国の値の必要なセットアップを完了する。Phone Cleansing and Normalization１８２３のステータス１８１１も、アクティブ（Active）１８２７に更新される。
【0080】
データ準備が完了した後、マッチングルールを設定して、同じ顧客に関連する異なる顧客レコードを識別することができる。デフォルトのマッチングルールのうちの少なくとも１つを、システムによってアクティブにすることができ、追加のマッチングルールが、ユーザによって設定又は更新されてよい。図１９は、いくつかの実施形態による、単一エンティティビューのマッチングルールについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。マッチングルールのセットアップ中に、セットアップ１９０５の下のマッチングルール（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）１９２３をクリックすると、新しいマッチングルールを追加することもできる。
【0081】
図２０は、いくつかの実施形態による、１つのマッチングルールに対する例示のマッチング基準のセットアップについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。１つのマッチングルールをクリックされてＧＵＩに詳細が表示された後、そのマッチングルールについてのマッチング基準（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２００３を編集することができる。
【0082】
図２１は、いくつかの実施形態による、１つのマッチングルールを編集するコマース・アーキテクチャＧＵＩスクリーンショットを示す。図２１に図示される例では、マッチングルール（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）２１０３を閉じることもできる。
【0083】
図２２は、いくつかの実施形態による、マッチングルールの編集後のマッチプレビューについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。マッチングルールを編集した後、図２２に図示されるように、マッチプレビュー（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）２２２５をクリックして、マッチングルールを保存してアクティブにすることができる。
【0084】
図２３は、いくつかの実施形態による、編集後のマッチングルールについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図２３では、メッセージボックス２３０７は、マッチングルールが保存されてアクティブにされたことを示している。そして、ＧＵＩは、マッチングルール（Matching Rules）ウィンドウ１９０３と同様のマッチングルール（Matching Rules）ウィンドウ２３０３に戻る。マッチングルール：Name with Exact Phone２３１５は、更新されたステータス：Active２３１７と、更新された最終修正「09/19/2018, 1:05PM」２３２１を有する。
【0085】
図２４は、いくつかの実施形態による、単一エンティティビューのためのデータ調和ルールについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。異なるデータソースから利用可能な値が複数存在する場合、いずれかの属性は１つの値しか有さないため、調和ルールは、１つのマスターファイルに対してどの値を使用するかを決定するために必要とされる。図２４に図示されるように、セットアップ２４０５の下のデータ調和ルール（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）２４２３をクリックすることよって、新たなデータ調和ルールを追加することもできる。
【0086】
図２５は、いくつかの実施形態による、１つの例示属性に対するデータ調和ルールについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。１つの調和ルールをクリックすると、ルールの詳細がＧＵＩに表示される。図２５に図示される例では、データ調和ルール：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）２５３５をクリックすることによって、アクティブルール２５１１を編集することもできる。
【0087】
図２６は、いくつかの実施形態による、例示の属性に対するデータ調和ルールを編集するコマース・アーキテクチャＧＵＩスクリーンショットを示す。図２６に図示すように、アクティブルール２５１１の編集２５３５をクリックした後、調和ルール（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）２６１１をクリックして調和ルールを保存することができる。
【0088】
図２７は、いくつかの実施形態による、例示の属性に対するデータ調和ルールの編集後のコマース・アーキテクチャＧＵＩスクリーンショットを示す。編集されたデータ調和ルールを保存した後、メッセージボックス２７０４を表示して、新しいデータ調和ルールのセットアップを示すことができる。また、詳細（Details）２７０７内のアクティブルール（Active Rule）２７１１の最終修正（Last Modified）２７１９も、新しいタイムスタンプで更新することができる。
【0089】
データスチュワードシップ
データスチュワードシップは、顧客との対話及びシステムインテリジェント推奨に基づいて、データの品質を改善するのを助けることができる。データ改善の要求を、優先順位によってソートすることができる。データスチュワードシップはまた、ユーザ又は管理者がマスターレコードを編集又は削除することを可能にする。例えば一般データ保護規則（ＧＤＰＲ：General Data Protection Regulation）のようなプライバシー法の遵守のために、消費者が自身の情報を削除したい場合、データスチュワードシップモジュールを使用して、システム内の消費者のレコードを削除することができる。また、データスチュワードシップは、ユーザが、プロファイルに対してクエリを実行し、プロファイル内のデータのソースを決定することも可能にする。
データスチュワードシップは、顧客との対話及びシステムインテリジェント推奨に基づいて、データの品質を改善するのを助けることができる。データ改善の要求を、優先順位によってソートすることができる。データスチュワードシップはまた、ユーザ又は管理者がマスターレコードを編集又は削除することを可能にする。例えば一般データ保護規則（ＧＤＰＲ：General Data Protection Regulation）のようなプライバシー法の遵守のために、消費者が自身の情報を削除したい場合、データスチュワードシップモジュールを使用して、システム内の消費者のレコードを削除することができる。また、データスチュワードシップは、ユーザが、プロファイルに対してクエリを実行し、プロファイル内のデータのソースを決定することも可能にする。
【0090】
図２８は、いくつかの実施形態による、データスチュワードシップについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図２８では、セットアップ２８０５の下のデータスチュワードシップ（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（プライバシー削除）２８２７等の要求タイプをクリックすることにより、要求の更なる情報を提供することができる。
【0091】
図２９は、いくつかの実施形態による、データスチュワードシップに対する例示の要求タイプの詳細についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図２９に図示されるように、要求キュー（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）２９３５を含む。
【0092】
図３０は、いくつかの実施形態による、データスチュワードシップに対する例示の要求の詳細についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図３０の例では、図２８内の要求ＩＤ：２７２５３が、図２８のプロファイルマージ２８２９についてクリックされると、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）３００７をクリックすることによってレコードをマージすることができる。
【0093】
図３１は、いくつかの実施形態による、データスチュワードシップの検索機能についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図３１において、データスチュワードシップ３１０３のレコード検索機能は、図２８の検索２８０９タブをクリックすると、ＧＵＩに表示される。検索機能は、Name（名前）等のレコードを検索するためのドロップダウンメニュー３１１１及びテキスト入力のための検索ボックス３１１３を提供する。ユーザは、検索（Search）３１１５をクリックして、レコード検索を実行すうことができる。
【0094】
図３２は、いくつかの実施形態による、データスチュワードシップの検索結果についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図３２に図示されるように、名前（Name）３２１１のレコード検索のために検索ボックス３２１３内にSampleが入力されると、２つの検索結果が表示されている。これらの２つのレコードは、関連性によってソートされてＧＵＩの検索ボックスの下に列挙される。各レコードは、ＩＤ３２１７、名前（Name）３２１９、電子メール（Email）３２２１、電話（Phone）３２２３及びアドレス（Address）３２２５を含む。ユーザは、レコードのＩＤをクリックしてレコードの更なる詳細を表示することができる。
【0095】
図３３は、データスチュワードシップのための例示の顧客プロファイルについてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図３３の例では、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を与える。
【0096】
図３４は、いくつかの実施形態による、データソースとシステムとの間の接続についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。コマース・アーキテクチャのセットアッププロセスの終了後、ＧＵＩのホーム画面は、図３４のように、システムに接続されたデータソースを示すことになる。例えばデータソース３４０１は、サービスクラウド３４０３、コマースクラウド３４０７、セールスクラウド３４１５及びマーケティングクラウド３４１７を含み、これらはすべてシステム３４１１に接続されている。各クラウドの右下の数字は、サービスクラウドに対する数字３（３４１９で示される）のように、クラウド内のデータソースの数を示すことができる。３４１９で示される数字３は、３つのサービスクラウドデータソースが接続されていることを意味する。ユーザは、Salesforceデータ３４０９をクリックすることによって、Salesforceから更なるデータソースを、他のデータ３４１３をクリックすることによって、第三者からの更なるデータソースを追加することができる。ＧＵＩの右側において、接続されたデータの分析（Analytics）３４２１は、入力顧客レコード（Input Consumer Records）３４２３及び固有の顧客レコード（Unique Consumer Records）３４２５を提供する。例えば図３４において、入力顧客レコードは２８．３Ｍであり、固有の顧客レコードは７．１Ｍである。また、異なるレコード及び異なるクラウドに対する凡例３４２７とともに、各データソースについてのTotal Qualified Records及びUnique Recordsがチャート３４２９内に示されている。
【0097】
第三者データソース
第三者データソースは、企業資源計画（ＥＲＰ：Enterprise Resource Planning）システム等のように第三者に属するデータベース及びシステムである。例えばCrocsのような顧客は、イベントデータ分析のようなサービスを提供するため又は消費者のためにマーケティング・メールを生成するため、本明細書の実施形態によって使用することができるデータを有する。従来、顧客は、第三者のデータソースと接続するために、システム固有のアプリケーション・プログラミング・インタフェース（ＡＰＩ）を使用し、固有のコードを使用しなければならなかった。本明細書に提示される実施形態は、ユーザ又は管理者としての顧客が、別個のＡＰＩ及びコードの使用を差し控えることを可能にし、複数の異なる切断されたシステムを横断するクエリのための、単一の統合されたポイント・アンド・クリックＡＰＩを提供し、それにより、そのような変換に必要とされた時間及びコストを大幅に削減することができる。
第三者データソースは、企業資源計画（ＥＲＰ：Enterprise Resource Planning）システム等のように第三者に属するデータベース及びシステムである。例えばCrocsのような顧客は、イベントデータ分析のようなサービスを提供するため又は消費者のためにマーケティング・メールを生成するため、本明細書の実施形態によって使用することができるデータを有する。従来、顧客は、第三者のデータソースと接続するために、システム固有のアプリケーション・プログラミング・インタフェース（ＡＰＩ）を使用し、固有のコードを使用しなければならなかった。本明細書に提示される実施形態は、ユーザ又は管理者としての顧客が、別個のＡＰＩ及びコードの使用を差し控えることを可能にし、複数の異なる切断されたシステムを横断するクエリのための、単一の統合されたポイント・アンド・クリックＡＰＩを提供し、それにより、そのような変換に必要とされた時間及びコストを大幅に削減することができる。
【0098】
図３５は、いくつかの実施形態による、例示の第三者データをシステムに接続するコマース・アーキテクチャＧＵＩスクリーンショットを示す。図３５の例において、ＧＵＩは、ユーザが図３４の他のデータ３４１３をクリックした後に、MuleSoft３５０７を含むデータソース３５０１を提供する。また、MuleSoft３５０７をクリックすることにより、MuleSoft Anypoint Platformのメッセージボックス３５０９が引き出される。Anypoint Platformで作成されたＡＰＩをシステムに接続し、顧客情報を更に充実させることができる。ユーザは、より多くのＡＰＩと接続するために、Anypoint Platform３５１１をクリックするか、図３４に示すように、データソースのホームページに戻るために、戻る（Back）３５０３をクリックすることができる。
【0099】
図３６は、いくつかの実施形態による、ＡＰＩを介して例示の第三者データをシステムに追加する詳細についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図３６において、Anypoint Platformをクリックした後に、Anypoint Exchangeプラットフォーム３６０３がＧＵＩに表示される。ユーザは、ドロップダウンメニュー３６０７から任意のカテゴリのＡＰＩを選択し、検索ボックス３６０９内でカスタマＡＰＩを検索することができる。顧客ＡＰＩには、例えばEmployee Profile Process ＡＰＩ、Customer Membership ＡＰＩ、Customer Onboarding Process ＡＰＩが含まれる。ユーザは、ＡＰＩ ３６１１の右上隅にある情報マーク３６１３をクリックすることによって、Customer Membership ＡＰＩ３６１１に関する更なる情報を取得することができる。ポップアップ・メッセージボックス３６１７は、Customer Membership ＡＰＩの基本的な機能を紹介しており、ユーザは、Learn More３６１９をクリックすることによって、更なる詳細を知ることができる。接続（Connect）３６１５をクリックした後、Customer Membership ＡＰＩがシステムと接続される。
【0100】
図３７は、いくつかの実施形態による、第三者データソースとＡＰＩの接続についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。Customer Membership ＡＰＩが接続された後、図３７のデータソース（Data Sources）３７０１は、Customer Membership ＡＰＩ３７０９とMuleSoft３７０７の接続を更新する。ユーザは、更に追加（Add More）３７１１をクリックして第三者のＡＰＩを更に追加するか、戻る（Back）をクリックして、Data Sourcesのホームページに戻ることができる。分析（Analytics）３７２１は、Input Consumer Records３７２３、Unique Consumer Records３７２５、Legend３７２７及びanalytics chart３７２９についても更新される。
【0101】
図３８は、いくつかの実施形態による、システムと、第三者データソースを含むデータソースとの間の接続についてのコマース・アーキテクチャＧＵＩスクリーンショットを示す。図３８に図示されるように、第三者データソースを追加した後、データソース３８０１は、サービスクラウド３８０３、コマースクラウド３８０７、セールスクラウド３８１５、マーケティングクラウド３８１７及びMuleSoft第三者データソース３８２１を含み、MuleSoft第三者データソース３８２１は、接続された第三者ＡＰＩを示す数字１（３８１９）を有する。これらのデータソースは、システム３８１１に接続されている。ユーザは、Salesforceデータ３８０９をクリックすることによって更なるSalesforceデータソースを追加することができ、あるいは他のデータ３８１３をクリックすることによって更なる第三者データソースを追加することができる。
【0102】
コマース・アーキテクチャＧＵＩフローチャート
図３９は、いくつかの実施形態による、コマース・アーキテクチャＧＵＩをセットアップするためのフローチャートの例を示す。方法３９００は、ハードウェア（例えば回路、専用論理、プログラマブル論理、マイクロコード等）、ソフトウェア（例えば処理デバイス上で実行される命令）又はそれらの組合せを含み得る処理ロジックによって実行され得る。本明細書で提供される開示を実施するために必ずしもすべてのステップが必要とされるわけではないことを認識されたい。さらに、当業者によって理解されるように、ステップのいくつかは、同時に実行されてもよく、図３９に示されるものとは異なる順序で実行されてもよい。方法３９００は図１～図３８を参照して説明される。しかしながら、方法３９００は、例示の実施形態に限定されない。
図３９は、いくつかの実施形態による、コマース・アーキテクチャＧＵＩをセットアップするためのフローチャートの例を示す。方法３９００は、ハードウェア（例えば回路、専用論理、プログラマブル論理、マイクロコード等）、ソフトウェア（例えば処理デバイス上で実行される命令）又はそれらの組合せを含み得る処理ロジックによって実行され得る。本明細書で提供される開示を実施するために必ずしもすべてのステップが必要とされるわけではないことを認識されたい。さらに、当業者によって理解されるように、ステップのいくつかは、同時に実行されてもよく、図３９に示されるものとは異なる順序で実行されてもよい。方法３９００は図１～図３８を参照して説明される。しかしながら、方法３９００は、例示の実施形態に限定されない。
【0103】
３９１０において、コマース・アーキテクチャＧＵＩが、第１及び第２データソースを追加するための第１及び第２ボタンを表示するために提供される。例えば図１のＧＵＩは、Salesforceデータソース又は第三者データソースを追加するために使用することができるSalesforceデータ１０１及び他のデータ１０２を含む。第１及び第２ボタンは、異なるSalesforceクラウド２１１、２１３、２１７又は２１９を参照することもできる。ＧＵＩは、従来のプログラムコードや様々なＡＰＩの代わりに、データソースを追加するためのポイント・アンド・クリック・ユーザインタフェースを提供する。
【0104】
３９２０において、第１及び第２応答が、第１及び第２ボタン上でのクリックを通して受け取られる。図７に図示されるように、Salesforceデータソースを追加した後、すべての認証済みデータソースがＧＵＩ内に列挙される。
【0105】
３９３０において、第１データスキーマ及び第２データスキーマのビューが、コマース・アーキテクチャＧＵＩに提供される。例えば図８～図１６は、左側に第１データスキーマとしてデータソース・スキーマ（Data Source Schema）を示し、右側に第２データスキーマとしてカノニカルデータモデル（Canonical Data Model）を示している。データソース・スキーマは、接続されたデータソースのすべてのデータを含む。また、カノニカルデータモデルは、接続されたデータソースのデータのマスターレコードとすることができる。
【0106】
３９４０において、第１データスキーマの少なくとも１つのオブジェクトが、第２データスキーマの少なくとも１つのオブジェクトにマッピングされる。例えば図１０において、第１データスキーマ：データソース・スキーマの第１オブジェクト：Birthdayは、第２データスキーマ：カノニカルデータモデルの第２オブジェクトであるDate of Birthにマッピングされる。
【0107】
３９５０において、第２データスキーマの第２オブジェクトの単一エンティティビューが、データ準備（Data Preparation）、マッチングルール（Matching Rules）、データ調和ルール（Data Reconciliation Rules）及び顧客更新ルール（Customer Update Rules）を通して提供される。図１６～図２７は、単一のエンティティビューのセットアップを示す。データ準備（Data Preparation）の間に、データ品質を向上させて、最良の顧客プロファイル統合を確実にすることができる。マッピングルールのうちの少なくとも１つをアクティブにすることによって、同じ顧客に関連する異なる顧客レコードを識別することができる。一部のデータソースにデフォルト値を追加することができる。また、１つの値しか持たない属性についてデータ調和ルールを構成することができる。調和ルールは、異なるデータソースから利用可能な複数の値が存在するとき、どの値を使用するかを決定する。
【0108】
コンピュータシステム実装
図４０は、本明細書で提示される様々な実施形態を実装するために使用され得る例示のコンピュータシステムを図示している。図１～図３８に図示される様々な実施形態は、図４０に図示されるコンピュータシステム４０００のような１つ以上の周知のコンピュータシステムを使用して実装されてよい。１つ以上のコンピュータシステム４０００を使用して、例えば本明細書で説明された実施形態のいずれか、並びにそれらの組合せ及び副次的組合せを実装してよい。
図４０は、本明細書で提示される様々な実施形態を実装するために使用され得る例示のコンピュータシステムを図示している。図１～図３８に図示される様々な実施形態は、図４０に図示されるコンピュータシステム４０００のような１つ以上の周知のコンピュータシステムを使用して実装されてよい。１つ以上のコンピュータシステム４０００を使用して、例えば本明細書で説明された実施形態のいずれか、並びにそれらの組合せ及び副次的組合せを実装してよい。
【0109】
コンピュータシステム４０００は、プロセッサ４００４のような１つ以上のプロセッサ（中央処理ユニット又はＣＰＵとも呼ばれる）を含んでもよい。プロセッサ４００４は、通信インフラストラクチャ又はバス４００６に接続されてよい。
【0110】
コンピュータシステム４０００はまた、モニタ、キーボード、ポインティングデバイス等のユーザ入力／出力デバイス４００３も含んでよい。ユーザ入力／出力デバイス４００３は、ユーザ入力／出力インタフェース４００２を介して通信インフラストラクチャ４００６と通信することができる。
【0111】
プロセッサ４００４の１つ以上は、グラフィックス処理ユニット（ＣＰＵ）であってもよい。一実施形態では、ＧＰＵは、数学的集約アプリケーションを処理するように設計された専用の電子回路であるプロセッサであってもよい。ＧＰＵは、コンピュータ・グラフィックス・アプリケーション、画像、ビデオ等に共通の数学的集約データのような、データの大きなブロックの並列処理に効率的な並列構造を有してもよい。
【0112】
コンピュータシステム４０００はまた、ランダムアクセスメモリ（ＲＡＭ）のようなメイン（又は一次）メモリ４００８を含んでもよい。メインメモリ４００８は、キャッシュの１つ以上のレベルを含んでもよい。メインメモリ４００８は、その中に制御ロジック（すなわち、コンピュータソフトウェア）及び／又はデータを格納しておくことができる。
【0113】
コンピュータシステム４０００はまた、１つ以上の二次ストレージデバイス又はメモリ４０１０も含んでよい。二次メモリ４０１０は、例えばハードディスクドライブ４０１２又は取り外し可能ストレージデバイス又はドライブ４０１４を含むことができる。取り外し可能ストレージドライブ４０１４は、フロッピーディスクドライブ、磁気テープドライブ、コンパクトディスクドライブ、光ストレージデバイス、テープバックアップデバイス又は任意の他のストレージデバイス／ドライブであってもよい。
【0114】
取り外し可能ストレージドライブ４０１４は、取り外し可能ストレージユニット４０１８と対話することができる。取り外し可能ストレージユニット４０１８は、その上にコンピュータソフトウェア（制御ロジック）又はデータを記憶した、コンピュータ使用可能又は読み取り可能なストレージデバイスを含んでもよい。取り外し可能ストレージユニット４０１８は、フロッピーディスク、磁気テープ、コンパクトディスク、ＤＶＤ、光ストレージディスク又は任意の他のコンピュータデータストレージデバイスであってよい。取り外し可能ストレージドライブ４０１４は、取り外し可能ストレージユニット４０１８との間で読み取り又は書き込みを行うことができる。
【0115】
二次メモリ４０１０は、コンピュータプログラムあるいは他の命令又はデータがコンピュータシステム４０００によってアクセスされることを可能にする他の手段、デバイス、コンポーネント、機器又は他のアプローチを含んでもよい。そのような手段、デバイス、コンポーネント、機器又は他のアプローチは、例えば取り外し可能ストレージユニット４０２２及びインタフェース４０２０を含んでもよい。取り外し可能ストレージユニット４０２２及びインタフェース４０２０の例は、プログラムカートリッジ及びカートリッジインタフェース（ビデオゲームデバイス内で見られるもの等）、取り外し可能メモリチップ（ＥＰＲＯＭ又はＰＲＯＭ等）及び関連ソケット、メモリスティック及びＵＳＢポート、メモリカード及び関連メモリカードスロット又は他の取り外し可能ストレージユニット及び関連インタフェースを含んでもよい。
【0116】
コンピュータシステム４０００は、通信又はネットワークインタフェース４０２４を更に含むことができる。通信インタフェース４０２４は、コンピュータシステム４０００が、（参照番号４０２８によって個々に、かつ、集合的に参照される）外部デバイス、外部ネットワーク、外部エンティティ等の任意の組合せと通信して対話することを可能にし得る。例えば通信インタフェース４０２４は、コンピュータシステム４０００が通信経路４０２６を介して外部又はリモートデバイス４０２８と通信することを可能にしてよい。通信経路４０２６は、有線又は無線（又はそれらの組合せ）であってもよく、ＬＡＮ、ＷＡＮ、インターネット等の任意の組合せを含んでもよい。制御ロジック又はデータは、通信経路４０２６を介してコンピュータシステム４０００との間で送信されてよい。
【0117】
コンピュータシステム４０００は、いくつかの非限定的な例を挙げると、パーソナル・デジタル・アシスタント（ＰＤＡ）、デスクトップ・ワークステーション、ラップトップ又はノートブックコンピュータ、ネットブック、タブレット、スマートフォン、スマート・ウォッチ又は他のウェアラブル、アプライアンス、モノのインターネット（Internet-of-Things）の一部又は組み込みシステム、あるいはそれらの任意の組合せのいずれかとすることもできる。
【0118】
コンピュータシステム４０００は、任意の配信パラダイムを通して任意のアプリケーション又はデータにアクセスするかホストする、クライアント又はサーバであってよく、限定ではないが：リモート又は分散クラウド・コンピューティング・ソリューション；ローカル又はオンプレミス（on-premises）ソフトウェア（「オンプレミス」クラウド・ベースのソリューション）；「アズ・ア・サービス（as a service）」モデル（例えばコンテンツ・アズ・ア・サービス（ＣａａＳ）、デジタルコンテンツ・アズ・ア・サービス（ＤＣａａＳ）、ソフトウェア・アズ・ア・サービス（ＳａａＳ）、管理ソフトウェア・アズ・ア・サービス（ＭＳａａＳ）、プラットフォーム・アズ・ア・サービス（ＰａａａＳ）、デスクトップ・アズ・ア・サービス（ＤａａＳ）、フレームワーク（ＦａａＳ）、バックエンド・アズ・ア・サービス（ＢａａＳ）、モバイルバックエンド・アズ・ア・サービス（ＭＢａａＳ）、インフラストラクチャ・アズ・ア・サービス（ＩａａＳ）；又は上記の例又は他のサービス又は配信パラダイムの任意の組合せを含むハイブリッド・モデルを含む。
【0119】
コンピュータシステム４０００における任意の適用可能なデータ構造、ファイル・フォーマット及びスキーマは、JavaScript（登録商標） Object Notification（ＪＳＯＮ）、ＸＭＬ（Extensible Markup Language）、ＹＡＭＬ（Yet Another Markup Language）、ＸＨＴＭＬ（Extensible Hypertext Markup Language）、ＷＭＬ（Wireless Markup Language）、MessagePack、ＸＵＬ（ＸＭＬ User Interface Language）又は任意の他の機能的に類似した表現を単独で又は組合せで含むが、これらに限定されない規格から導出されてよい。あるいは、専用のデータ構造、フォーマット又はスキーマが排他的に、あるいは既知の又はオープンな規格との組合せで使用されてもよい。
【0120】
いくつかの実施形態において、その上に記憶された制御ロジック（ソフトウェア）を有する、有形の非一時的なコンピュータ使用可能又は読取可能な媒体を含む、有形の非一時的な装置又は製品は、本明細書において、コンピュータプログラム製品又はプログラムストレージデバイスと称されることもある。これは、コンピュータシステム４０００、メインメモリ４００８、二次メモリ４０１０及び取り外し可能ストレージユニット４０１８及び４０２２、並びに上記のいずれかの組合せを具体化する有形の製品が含まれるが、これらに限定されない。そのような制御ロジックは、１つ以上のデータ処理デバイス（コンピュータシステム４０００等）によって実行されるとき、本明細書で記載されるように、そのようなデータ処理デバイスを動作させることができる。
【0121】
本開示に含まれる教示に基づいて、図４０に示されるもの以外のデータ処理デバイス、コンピュータシステム又はコンピュータ・アーキテクチャを用いて、本開示の実施形態をどのように作製し、使用するかは、当業者に明らかであろう。特に、実施形態は、本明細書に記載されているもの以外のソフトウェア、ハードウェア及び／又はオペレーティングシステムの実装で動作することができる。
【0122】
結論
詳細な説明のセクションは、他のセクションではなく、クレームを解釈するために使用されるように意図されていることが理解されよう。他のセクションは、本発明者によって考慮される、すべてではないが１つ以上の例示の実施形態を説明することができ、したがって、本開示又は添付の特許請求の範囲をいかなるようにも限定するようには意図されていない。
詳細な説明のセクションは、他のセクションではなく、クレームを解釈するために使用されるように意図されていることが理解されよう。他のセクションは、本発明者によって考慮される、すべてではないが１つ以上の例示の実施形態を説明することができ、したがって、本開示又は添付の特許請求の範囲をいかなるようにも限定するようには意図されていない。
【0123】
本開示は、例示の分野及び用途の例示の実施形態を記載しているが、本開示はそれに限定されないことを理解されたい。他の実施形態及びそれに対する修正が可能であり、本開示の範囲及び精神内にある。例えば本段落の一般性を制限することなく、実施形態は、図面に図示されるか、本明細書で説明されるソフトウェア、ハードウェア、ファームウェア又はエンティティに限定されない。さらに、実施形態（本明細書で明示的に説明されているか否かにかかわらず）は、本明細書で説明される実施例を超える分野及び用途に対して有意な有用性を有する。
【0124】
本明細書では、特定の機能の実施及びそれらの関係を例示する機能的構築ブロックを用いて、実施形態を説明した。これらの機能的構成要素の境界は、説明の便宜上、本明細書中で任意に定義されている。特定の機能と関係（又はその均等物）が適切に実施される限り、別の境界を定義することができる。また、代替の実施形態は、本明細書で説明されるものとは異なる順序を使用して、機能ブロック、ステップ、動作、方法等を実行することができる。
【0125】
本明細書において、「一実施形態」、「ある実施形態」、「例示の実施形態」又は類似のフレーズへの言及は、説明された実施形態が特定の特徴、構造又は特性を含むことができるが、すべての実施形態が必ずしも特定の特徴、構造又は特性を含まない可能性があることを示す。そのようなフレーズは、必ずしも同一の実施形態を指していない。さらに、特定の特徴、構造又は特性がある実施形態に関連して説明されるとき、このような特徴、構造又は特性を、本明細書に明示的に記載又は説明されているか否かにかかわらず、他の実施形態に組み込むことは当業者の知識の範囲内であろう。さらに、いくつかの実施形態は、「結合された（coupled）」及び「接続された（connected）」という表現をそれらの派生語とともに使用して説明される可能性がある。これらの用語は、必ずしも互いに同義語として意図されているわけではない。例えばいくつかの実施形態は、２つ以上の要素が互いに直接的に物理的又は電気的に接触していることを示すために、「接続された」又は「結合された」という用語を使用して説明されることができる。しかしながら、用語「結合された」は、２つ以上の要素が互いに直接接触していないが、依然として相互に協働又は相互作用していることも意味する可能性がある。
【0126】
本開示の広さ及び範囲は、上述の例示の実施形態のいずれによっても制限されるべきではなく、以下の特許請求の範囲及びそれらの均等物に従ってのみ定義されるべきである。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【図39】
【図40】