▶ セールスフォース ドット コム インコーポレイティッドの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024074934
(43)【公開日】2024-05-31
(54)【発明の名称】分散システムにわたる統合エンティティビュー
(51)【国際特許分類】
G06F 16/25 20190101AFI20240524BHJP
G06Q 30/02 20230101ALI20240524BHJP
【ＦＩ】
G06F16/25
G06Q30/02
【審査請求】有
【請求項の数】20
【出願形態】ＯＬ
【外国語出願】
(21)【出願番号】P 2024061214
(22)【出願日】2024-04-05
(62)【分割の表示】P 2019173412の分割
【原出願日】2019-09-24
(31)【優先権主張番号】62/735552
(32)【優先日】2018-09-24
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】16/264418
(32)【優先日】2019-01-31
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】506332063
【氏名又は名称】セールスフォース インコーポレイテッド
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】レオ デュイ トラン
(72)【発明者】
【氏名】デイヴィッド アングロ
(72)【発明者】
【氏名】デイヴィッド ジェームズ ウッドワード
(72)【発明者】
【氏名】アビナフ チャッダ
(72)【発明者】
【氏名】デイヴィッド ハッカー
(72)【発明者】
【氏名】スティーブン ネス
(72)【発明者】
【氏名】マット ラグロッテ
(72)【発明者】
【氏名】ジェイソン ムーディ
(72)【発明者】
【氏名】ダニエル マーチャント
(72)【発明者】
【氏名】マシュー ジェームズ モンドク
(72)【発明者】
【氏名】フェデリコ レシオ
(72)【発明者】
【氏名】メーメット ゴクメン オルン
(72)【発明者】
【氏名】スティーブン コストシェフスキー
(72)【発明者】
【氏名】クリストファー ビル
(72)【発明者】
【氏名】カウストゥバ バーデ
(72)【発明者】
【氏名】リディア ロドヴィージ
(72)【発明者】
【氏名】サラ フラミオン
(72)【発明者】
【氏名】ジャミン ホール
(72)【発明者】
【氏名】チャールズ ファインマン
(57)【要約】
【課題】顧客関係管理（ＣＲＭ）システムのための方法、システム及びコンピュータプログラム製品を本明細書において提供する。
【解決手段】本明細書で提示される実施形態は、異種の分散システム間のデータの交換；顧客データ変更イベントへのサブスクライブ及び／又はパブリッシュ；静的及びストリーミングソースを使用する消費者のためのマスターレコードの作成；複数のテナント及び第三者システムにわたるデータの起源、監査能力及びクエリを提供する。実施形態は、分散システム環境における顧客の単一ビューを提供する。
【選択図】図１Ａ
【解決手段】本明細書で提示される実施形態は、異種の分散システム間のデータの交換；顧客データ変更イベントへのサブスクライブ及び／又はパブリッシュ；静的及びストリーミングソースを使用する消費者のためのマスターレコードの作成；複数のテナント及び第三者システムにわたるデータの起源、監査能力及びクエリを提供する。実施形態は、分散システム環境における顧客の単一ビューを提供する。
【選択図】図１Ａ
【特許請求の範囲】
【請求項1】
コンピューティングデバイスによって、メッセージングプラットフォームを介して、第１スキーマを有する第１データソースからの第１消費者データと、第２スキーマを有する第２データソースからの第２消費者データとを受け取るステップであって、前記第１消費者データ及び前記第２消費者データは共通の消費者を有し、前記共通の消費者についての前記第２スキーマは、前記共通の消費者についての前記第１スキーマとは異なる、ステップと；
前記コンピューティングデバイスによって、前記共通の消費者についての前記第１スキーマ及び前記第２スキーマを、マスターレコード・カノニカルモデルの共通交換スキーマと調和させるステップであって、フィールドマッピング・レジストリが、前記第１スキーマ及び前記第２スキーマを前記マスターレコード・カノニカルモデルの前記共通交換スキーマに接続する、ステップと；
前記コンピューティングデバイスによって、前記第１消費者データのコンテキスト情報及び前記マスターレコード・カノニカルモデルにおける前記共通の消費者のカノニカル情報に基づいて第１変換ルールと、前記第２消費者データのコンテキスト情報及び前記マスターレコード・カノニカルモデルにおける前記共通の消費者のカノニカル情報に基づいて第２変換ルールとを決定するステップと；
前記コンピューティングデバイスによって、前記第１変換ルールに基づいて前記第１消費者データと、前記第２変換ルールに基づいて前記第２消費者データとを、前記マスターレコード・カノニカルモデルのカノニカルフォーマットに変換するステップであって、前記共通の消費者についての前記変換された第１及び第２消費者データの共通のフィールドは、異なるデータを含む、ステップと；
前記コンピューティングデバイスによって、前記共通のフィールド内の前記異なるデータを、前記変換された第１及び第２消費者データの統一されたビューに調和させるステップと；
前記コンピューティングデバイスによって、前記共通のフィールドの前記調和されたデータに基づいて、前記マスターレコード・カノニカルモデルの前記共通の消費者の単一のマスターレコードを作成するステップと；
前記コンピューティングデバイスによって、前記単一のマスターレコードの１以上の加入者に送信するために、前記共通の消費者の前記単一のマスターレコードの更新に応答して、該更新された単一のマスターレコードをメッセージングプラットフォームバスにパブリッシュするステップと；
を含む、方法。
前記コンピューティングデバイスによって、前記共通の消費者についての前記第１スキーマ及び前記第２スキーマを、マスターレコード・カノニカルモデルの共通交換スキーマと調和させるステップであって、フィールドマッピング・レジストリが、前記第１スキーマ及び前記第２スキーマを前記マスターレコード・カノニカルモデルの前記共通交換スキーマに接続する、ステップと；
前記コンピューティングデバイスによって、前記第１消費者データのコンテキスト情報及び前記マスターレコード・カノニカルモデルにおける前記共通の消費者のカノニカル情報に基づいて第１変換ルールと、前記第２消費者データのコンテキスト情報及び前記マスターレコード・カノニカルモデルにおける前記共通の消費者のカノニカル情報に基づいて第２変換ルールとを決定するステップと；
前記コンピューティングデバイスによって、前記第１変換ルールに基づいて前記第１消費者データと、前記第２変換ルールに基づいて前記第２消費者データとを、前記マスターレコード・カノニカルモデルのカノニカルフォーマットに変換するステップであって、前記共通の消費者についての前記変換された第１及び第２消費者データの共通のフィールドは、異なるデータを含む、ステップと；
前記コンピューティングデバイスによって、前記共通のフィールド内の前記異なるデータを、前記変換された第１及び第２消費者データの統一されたビューに調和させるステップと；
前記コンピューティングデバイスによって、前記共通のフィールドの前記調和されたデータに基づいて、前記マスターレコード・カノニカルモデルの前記共通の消費者の単一のマスターレコードを作成するステップと；
前記コンピューティングデバイスによって、前記単一のマスターレコードの１以上の加入者に送信するために、前記共通の消費者の前記単一のマスターレコードの更新に応答して、該更新された単一のマスターレコードをメッセージングプラットフォームバスにパブリッシュするステップと；
を含む、方法。
【請求項2】
前記コンピューティングデバイスによって、前記第１消費者データを正規化するステップ、
を更に含む、請求項１に記載の方法。
を更に含む、請求項１に記載の方法。
【請求項3】
前記異なるデータを調和させるステップは、
前記コンピューティングデバイスによって、タイブレーカー・ルールを用いて前記前記第１消費者データと前記第２消費者データの前記共通のフィールド内の前記異なるデータを調和させるステップ、
を更に含む、請求項１に記載の方法。
前記コンピューティングデバイスによって、タイブレーカー・ルールを用いて前記前記第１消費者データと前記第２消費者データの前記共通のフィールド内の前記異なるデータを調和させるステップ、
を更に含む、請求項１に記載の方法。
【請求項4】
前記コンピューティングデバイスによって、前記第１変換ルール又は前記第２変換ルールを用いてストリーミングデータを処理するステップ、
を更に含み、前記第１消費者データと前記第２消費者データのうちの一方は、前記ストリーミングデータを含む、
請求項１に記載の方法。
を更に含み、前記第１消費者データと前記第２消費者データのうちの一方は、前記ストリーミングデータを含む、
請求項１に記載の方法。
【請求項5】
前記コンピューティングデバイスによって、前記第１及び第２変換ルールを識別するために前記第１及び第２消費者データの前記コンテキスト情報を送信するステップ、
を更に含む、請求項４に記載の方法。
を更に含む、請求項４に記載の方法。
【請求項6】
前記コンピューティングデバイスによって、前記コンテキスト情報に基づいて、前記変換された第１消費者データの前記第１データソースと、前記変換された第２消費者データの前記第２データソースを決定するステップ、
を更に含む、請求項５に記載の方法。
を更に含む、請求項５に記載の方法。
【請求項7】
前記コンピューティングデバイスによって、前記共通の消費者の前記更新された単一のマスターレコードを、前記単一のマスターレコードにサブスクライブしている１つ以上のデータソースに送信するステップ、
を更に含む、請求項１に記載の方法。
を更に含む、請求項１に記載の方法。
【請求項8】
メモリと；
前記メモリに結合され、前記メモリ内に格納された命令に基づいて、
第１スキーマを有する第１データソースからの第１消費者データと、第２スキーマを有する第２データソースからの第２消費者データとを受け取り、前記第１消費者データ及び前記第２消費者データは、共通の消費者を有し、前記共通の消費者についての前記第２スキーマは、前記共通の消費者についての前記第１スキーマとは異なり、
前記共通の消費者についての前記第１スキーマ及び前記第２スキーマを、マスターレコード・カノニカルモデルの共通交換スキーマと調和させ、フィールドマッピング・レジストリが、前記第１スキーマ及び前記第２スキーマを前記マスターレコード・カノニカルモデルの前記共通交換スキーマに接続し、
前記第１消費者データのコンテキスト情報及び前記マスターレコード・カノニカルモデルにおける前記共通の消費者のカノニカル情報に基づいて第１変換ルールと、前記第２消費者データのコンテキスト情報及び前記マスターレコード・カノニカルモデルにおける前記共通の消費者のカノニカル情報に基づいて第２変換ルールを決定し、
前記第１変換ルールに基づいて前記第１消費者データと、前記第２変換ルールに基づいて前記第２消費者データとを、前記マスターレコード・カノニカルモデルのカノニカルフォーマットに変換し、前記共通の消費者についての前記変換された第１及び第２消費者データの共通のフィールドは、異なるデータを含み、
前記共通のフィールド内の前記異なるデータを、前記変換された第１及び第２消費者データの統一されたビューに調和させ、
前記共通のフィールドの前記調和されたデータに基づいて、前記マスターレコード・カノニカルモデルの前記共通の消費者の単一のマスターレコードを作成し、
前記単一のマスターレコードの１以上の加入者に送信するために、前記共通の消費者の前記単一のマスターレコードの更新に応答して、該更新された単一のマスターレコードをメッセージングプラットフォームバスにパブリッシュする、
ように構成される、プロセッサと；
を備える、システム。
前記メモリに結合され、前記メモリ内に格納された命令に基づいて、
第１スキーマを有する第１データソースからの第１消費者データと、第２スキーマを有する第２データソースからの第２消費者データとを受け取り、前記第１消費者データ及び前記第２消費者データは、共通の消費者を有し、前記共通の消費者についての前記第２スキーマは、前記共通の消費者についての前記第１スキーマとは異なり、
前記共通の消費者についての前記第１スキーマ及び前記第２スキーマを、マスターレコード・カノニカルモデルの共通交換スキーマと調和させ、フィールドマッピング・レジストリが、前記第１スキーマ及び前記第２スキーマを前記マスターレコード・カノニカルモデルの前記共通交換スキーマに接続し、
前記第１消費者データのコンテキスト情報及び前記マスターレコード・カノニカルモデルにおける前記共通の消費者のカノニカル情報に基づいて第１変換ルールと、前記第２消費者データのコンテキスト情報及び前記マスターレコード・カノニカルモデルにおける前記共通の消費者のカノニカル情報に基づいて第２変換ルールを決定し、
前記第１変換ルールに基づいて前記第１消費者データと、前記第２変換ルールに基づいて前記第２消費者データとを、前記マスターレコード・カノニカルモデルのカノニカルフォーマットに変換し、前記共通の消費者についての前記変換された第１及び第２消費者データの共通のフィールドは、異なるデータを含み、
前記共通のフィールド内の前記異なるデータを、前記変換された第１及び第２消費者データの統一されたビューに調和させ、
前記共通のフィールドの前記調和されたデータに基づいて、前記マスターレコード・カノニカルモデルの前記共通の消費者の単一のマスターレコードを作成し、
前記単一のマスターレコードの１以上の加入者に送信するために、前記共通の消費者の前記単一のマスターレコードの更新に応答して、該更新された単一のマスターレコードをメッセージングプラットフォームバスにパブリッシュする、
ように構成される、プロセッサと；
を備える、システム。
【請求項9】
前記プロセッサは、
前記第１消費者データを正規化するように更に構成される、
請求項８に記載のシステム。
前記第１消費者データを正規化するように更に構成される、
請求項８に記載のシステム。
【請求項10】
前記プロセッサは、
タイブレーカー・ルールを用いて前記第１消費者データと前記第２消費者データの前記共通のフィールド内の前記異なるデータを調和させるように更に構成される、
請求項８に記載のシステム。
タイブレーカー・ルールを用いて前記第１消費者データと前記第２消費者データの前記共通のフィールド内の前記異なるデータを調和させるように更に構成される、
請求項８に記載のシステム。
【請求項11】
前記プロセッサは、
前記第１変換ルール又は前記第２変換ルールを用いてストリーミングデータを処理するように更に構成され、
前記第１消費者データと前記第２消費者データのうちの一方は、前記ストリーミングデータを含む、
請求項８に記載のシステム。
前記第１変換ルール又は前記第２変換ルールを用いてストリーミングデータを処理するように更に構成され、
前記第１消費者データと前記第２消費者データのうちの一方は、前記ストリーミングデータを含む、
請求項８に記載のシステム。
【請求項12】
前記プロセッサは、
前記第１及び第２変換ルールを識別するために前記第１及び第２消費者データの前記コンテキスト情報を送信するように更に構成される、
請求項１１に記載のシステム。
前記第１及び第２変換ルールを識別するために前記第１及び第２消費者データの前記コンテキスト情報を送信するように更に構成される、
請求項１１に記載のシステム。
【請求項13】
前記プロセッサは、
前記コンテキスト情報に基づいて、前記変換された第１消費者データの前記第１データソースと、前記変換された第２消費者データの前記第２データソースとを決定するように更に構成される、
請求項１２に記載のシステム。
前記コンテキスト情報に基づいて、前記変換された第１消費者データの前記第１データソースと、前記変換された第２消費者データの前記第２データソースとを決定するように更に構成される、
請求項１２に記載のシステム。
【請求項14】
前記プロセッサは、
前記共通の消費者の前記更新された単一のマスターレコードを、前記単一のマスターレコードにサブスクライブしている１つ以上のデータソースに送信する、
ように更に構成される、請求項８に記載のシステム。
前記共通の消費者の前記更新された単一のマスターレコードを、前記単一のマスターレコードにサブスクライブしている１つ以上のデータソースに送信する、
ように更に構成される、請求項８に記載のシステム。
【請求項15】
コンピューティングデバイスによって実行されると、該コンピューティングデバイスに、
第１スキーマを有する第１データソースからの第１消費者データと、第２スキーマを有する第２データソースからの第２消費者データとを受け取ることであって、前記第１消費者データ及び前記第２消費者データは、共通の消費者を有し、前記共通の消費者についての前記第２スキーマは、前記共通の消費者についての前記第１スキーマとは異なることと；
前記共通の消費者についての前記第１スキーマ及び前記第２スキーマを、マスターレコード・カノニカルモデルの共通交換スキーマと調和させることであって、フィールドマッピング・レジストリが、前記第１スキーマ及び前記第２スキーマを前記マスターレコード・カノニカルモデルの前記共通交換スキーマに接続することと；
前記第１消費者データのコンテキスト情報及び前記マスターレコード・カノニカルモデルにおけるカノニカル情報に基づいて第１変換ルールと、前記第２消費者データのコンテキスト情報及び前記マスターレコード・カノニカルモデルにおけるカノニカル情報に基づいて第２変換ルールとを決定することと；
前記第１変換ルールに基づいて前記第１消費者データと、前記第２変換ルールに基づいて前記第２消費者データとを、前記マスターレコード・カノニカルモデルのカノニカルフォーマットに変換することであって、前記共通の消費者の前記変換された第１及び第２消費者データの共通のフィールドは、異なるデータを含むことと；
前記共通のフィールド内の前記異なるデータを、前記変換された第１及び第２消費者データの統一されたビューに調和させることと；
前記共通のフィールドの前記調和されたデータに基づいて、前記マスターレコード・カノニカルモデルの前記共通の消費者の単一のマスターレコードを作成することと；
前記単一のマスターレコードの１以上の加入者に送信するために、前記共通の消費者の前記単一のマスターレコードの更新に応答して、該更新された単一のマスターレコードをメッセージングプラットフォームバスにパブリッシュすることと；
を含む動作を実行させる命令を有する、非一時的なコンピュータ読み取り可能装置。
第１スキーマを有する第１データソースからの第１消費者データと、第２スキーマを有する第２データソースからの第２消費者データとを受け取ることであって、前記第１消費者データ及び前記第２消費者データは、共通の消費者を有し、前記共通の消費者についての前記第２スキーマは、前記共通の消費者についての前記第１スキーマとは異なることと；
前記共通の消費者についての前記第１スキーマ及び前記第２スキーマを、マスターレコード・カノニカルモデルの共通交換スキーマと調和させることであって、フィールドマッピング・レジストリが、前記第１スキーマ及び前記第２スキーマを前記マスターレコード・カノニカルモデルの前記共通交換スキーマに接続することと；
前記第１消費者データのコンテキスト情報及び前記マスターレコード・カノニカルモデルにおけるカノニカル情報に基づいて第１変換ルールと、前記第２消費者データのコンテキスト情報及び前記マスターレコード・カノニカルモデルにおけるカノニカル情報に基づいて第２変換ルールとを決定することと；
前記第１変換ルールに基づいて前記第１消費者データと、前記第２変換ルールに基づいて前記第２消費者データとを、前記マスターレコード・カノニカルモデルのカノニカルフォーマットに変換することであって、前記共通の消費者の前記変換された第１及び第２消費者データの共通のフィールドは、異なるデータを含むことと；
前記共通のフィールド内の前記異なるデータを、前記変換された第１及び第２消費者データの統一されたビューに調和させることと；
前記共通のフィールドの前記調和されたデータに基づいて、前記マスターレコード・カノニカルモデルの前記共通の消費者の単一のマスターレコードを作成することと；
前記単一のマスターレコードの１以上の加入者に送信するために、前記共通の消費者の前記単一のマスターレコードの更新に応答して、該更新された単一のマスターレコードをメッセージングプラットフォームバスにパブリッシュすることと；
を含む動作を実行させる命令を有する、非一時的なコンピュータ読み取り可能装置。
【請求項16】
前記動作は、前記共通の消費者の前記更新された単一のマスターレコードを、前記単一のマスターレコードにサブスクライブしている１つ以上のデータソースに送信すること、
を更に含む、請求項１５に記載の非一時的なコンピュータ読み取り可能装置。
を更に含む、請求項１５に記載の非一時的なコンピュータ読み取り可能装置。
【請求項17】
前記動作は、タイブレーカー・ルールを用いて前記第１消費者データと前記第２消費者データの前記共通のフィールド内の前記異なるデータを調和させること、
を更に含む、請求項１５に記載の非一時的なコンピュータ読み取り可能装置。
を更に含む、請求項１５に記載の非一時的なコンピュータ読み取り可能装置。
【請求項18】
前記動作は、前記第１変換ルール又は前記第２変換ルールを用いてストリーミングデータを処理すること、
を更に含み、前記第１消費者データと前記第２消費者データのうちの一方は、前記ストリーミングデータを含む、
請求項１５に記載の非一時的なコンピュータ読み取り可能装置。
を更に含み、前記第１消費者データと前記第２消費者データのうちの一方は、前記ストリーミングデータを含む、
請求項１５に記載の非一時的なコンピュータ読み取り可能装置。
【請求項19】
前記動作は、前記第１及び第２変換ルールを識別するために前記第１及び第２消費者データの前記コンテキスト情報を送信すること、
を更に含む、請求項１８に記載の非一時的なコンピュータ読み取り可能装置。
を更に含む、請求項１８に記載の非一時的なコンピュータ読み取り可能装置。
【請求項20】
前記動作は、前記コンテキスト情報に基づいて、前記変換された第１消費者データの前記第１データソースと、前記変換された第２消費者データの前記第２データソースを決定すること、
を更に含む、請求項１９に記載の非一時的なコンピュータ読み取り可能装置。
を更に含む、請求項１９に記載の非一時的なコンピュータ読み取り可能装置。
【発明の詳細な説明】
【背景技術】
【0001】
企業は、自社の製品やサービスの消費者についてのこれまで以上に多くのデータにアクセスできる。ＣＲＭシステムの目的は、サプライチェーン内のすべてのサービスレベルで、このデータを効率的に管理し、容易にアクセスして共有できるようにすることである。しかしながら、従来のデータベース又はＣＲＭシステムでは、異なる分離されたソースからの顧客データを統合し、消費者についてのマスターレコードを作成することはできない。また、従来のシステムは、マルチテナントシステムにおいて、クエリを実行し、データを読み出し又は書き込むために、どこからデータを得るかを決定することも困難である。従来のシステムの別の問題は、データの起源（data provenance）、すなわち、レコード内のデータの１つ以上のソースを決定することである。さらに、従来のシステムは、データのための監査ログを提供することに苦労してきた。データの起源と監査ログは、プライバシー法を遵守するために不可欠である。従来のシステムはまた、異なる時間スケールのデータを統合し、異なるソースからのデータにアクセスし、データを比較し、それを調和（reconciling）させるという問題にも直面する。
【発明の概要】
【0002】
典型的なコマース／マーケティングシステムは、高ボリュームで低品質の消費者データを低ボリュームで高品質のデータに変換するために、管理者がコードを作成することを必要とする。このプロセスは、時間がかかり、高価で、エラーを起こしやすい可能性がある。顧客がオンライン・チェックアウト・カートにアイテムを残したままにするとき、すなわち、カートを放置するとき、管理者は、そのようなイベントを追跡して消費者へのフォローアップの電子メールを生成するために、大量のデータを解析するために特定のコードを書かなければならない。さらに、データは、独自のアプリケーション・プログラミング・インタフェース（ＡＰＩ）を有する異なるソースから来るので、管理者は、従来的に、各システムのＡＰＩを学んで、異なるシステムとインタフェースしてデータを取り出すためのクエリをプログラムしなければならないであろう。本明細書に提示される実施形態は、特に、少なくともこれらの問題に対する解決策を提供する。
【図面の簡単な説明】
【0003】
本明細書に組み込まれ、明細書の一部を構成する添付の図面は、本実施形態を例示しており、以下の説明とともに、本実施形態の原理を説明し、当業者が本実施形態を作成して使用することを可能にするために更に役立つ。
【0004】
【0005】
【図2】本開示の一実施形態による統合型企業コマース・アーキテクチャを示す図である。
【0006】
【図3】本開示の一実施形態による消費者解決エンジン（ＣＲＥ：consumer resolution engine）を示す図である。
【0007】
【図4】本明細書で提示される様々な実施形態を実施するために使用され得る例示的なコンピュータシステムを示す図である。
【0008】
【0009】
【図7】本開示の一実施形態による例示的なユーザインタフェースを示す図である。
【0010】
本実施形態の特徴及び利点は、図面と併せて考えると、以下で説明される詳細な説明からより明らかになるであろう。図面では、全体を通して同様の参照符号が対応する要素を識別する。図面において、同様の参照番号は一般に、同一の要素、機能的に類似の要素及び／又は構造的に類似の要素を示す。要素が最初に現れる図面は、対応する参照番号の左端の数字で示される。
【発明を実施するための形態】
【0011】
例示的な動作環境
図１Ａは、オンデマンドデータベースサービスが使用され得る環境１１０のブロック図を示す。環境１１０は、顧客システム１１２、ネットワーク１１４、システム１１６、プロセッサシステム１１７、アプリケーションプラットフォーム１１８、ネットワークインタフェース１２０、テナントデータストレージ１２２、システムデータストレージ１２４、プログラムコード１２６及びプロセス空間１２８を含んでよい。他の実施形態では、環境１１０は、列挙された構成要素のすべてを有していなくてもよく、かつ／又は上に列挙された構成要素の代わりに又はそれに加えて、他の構成要素を有してもよい。本開示において、消費者は、顧客又はパトロンと同義に称されることがある。
図１Ａは、オンデマンドデータベースサービスが使用され得る環境１１０のブロック図を示す。環境１１０は、顧客システム１１２、ネットワーク１１４、システム１１６、プロセッサシステム１１７、アプリケーションプラットフォーム１１８、ネットワークインタフェース１２０、テナントデータストレージ１２２、システムデータストレージ１２４、プログラムコード１２６及びプロセス空間１２８を含んでよい。他の実施形態では、環境１１０は、列挙された構成要素のすべてを有していなくてもよく、かつ／又は上に列挙された構成要素の代わりに又はそれに加えて、他の構成要素を有してもよい。本開示において、消費者は、顧客又はパトロンと同義に称されることがある。
【0012】
環境１１０は、オンデマンドデータベースサービスが存在する環境である。顧客システム１１２は、データベース顧客システムにアクセスするために顧客によって使用される任意のマシン又はシステムであってよい。例えば顧客システム１１２のいずれかは、ハンドヘルド・コンピューティングデバイス、携帯電話、ラップトップ・コンピュータ、ワークステーション及び／又はコンピューティングデバイスのネットワークであってよい。図１Ａに（図１Ｂでより詳細に）図示されるように、顧客システム１１２は、ネットワーク１１４を介して、システム１１６であるオンデマンドデータベースサービスと対話することができる。
【0013】
システム１１６等のオンデマンドデータベースサービスは、外部顧客に利用可能にされるデータベースシステムである。外部顧客は、データベースシステムの構築及び／又は維持に必ずしも関与する必要はないが、代わりに、そのデータベースシステムは、外部顧客がそのデータベースシステムを必要とするときに（例えば顧客の要求に応じて）使用のために利用可能となり得る。いくつかのオンデマンドデータベースサービスは、共通データベースイメージのテーブルに格納された１つ以上のテナントからの情報を格納して、マルチテナントデータベースシステム（ＭＴＳ：multi-tenant database system）を形成することができる。したがって、「オンデマンドデータベースサービス１１６」及び「システム１１６」は、本明細書では互換的に使用される。データベースイメージは、１つ以上のデータベースオブジェクトを含んでよい。リレーショナルデータベース管理システム（ＲＤＭＳ：relational database management system）又はその均等物が、データベースオブジェクトに対する情報の格納と取り出しを実行してもよい。アプリケーションプラットフォーム１１８は、システム１１６のアプリケーションが、ハードウェア及び／又はソフトウェア、例えばオペレーティングシステムを実行することを可能にするフレームワークであってよい。一実施形態では、オンデマンドデータベースサービス１１６は、アプリケーションプラットフォーム１１８を含んでよい。アプリケーションプラットフォーム１１８は、オンデマンドデータベースサービスのプロバイダ、顧客システム１１２を介してオンデマンドデータベースサービスにアクセスする顧客、あるいは顧客システム１１２を介してオンデマンドデータベースサービスにアクセスする第三者アプリケーション開発者によって開発された、１つ以上のアプリケーションの作成、管理及び実行を可能にすることができる。
【0014】
顧客システム１１２のユーザは、それぞれのキャパシティ（capacity）が異なってもよく、特定の顧客システム１１２のキャパシティは、現在のユーザに対する許可（許可レベル）によって完全に決定されてもよい。例えば販売員が特定の顧客システム１１２を使用してシステム１１６と対話している場合、その顧客システム１１２は、その販売員に割り当てられたキャパシティを有する。しかしながら、管理者がその顧客システム１１２を使用してシステム１１６と対話している間は、その顧客システム１１２はその管理者に割り当てられたキャパシティを有する。階層的役割モデルを有するシステムでは、ある許可レベルのユーザは、より下位の許可レベルのユーザによってアクセス可能なアプリケーション、データ及びデータベース情報へのアクセスは有するが、より上位の許可レベルのユーザによってアクセス可能な特定のアプリケーション、データベース情報及びデータへのアクセスは有しないことがある。したがって、異なるユーザは、ユーザのセキュリティ又は許可レベルに依存して、アプリケーション及びデータベース情報をアクセス及び変更することに関して異なるキャパシティを有する。
【0015】
ネットワーク１１４は、互いに通信するデバイスのいずれかのネットワーク又はネットワークの組合せである。例えばネットワーク１１４は、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、電話ネットワーク、ワイヤレスネットワーク、ポイントツーポイントネットワーク、スターネットワーク、トークンリングネットワーク、ハブネットワーク又は他の適切な構成のうちのいずれか１つ又はいずれかの組合せであってよい。現在使用されているコンピュータネットワークの最も一般的なタイプは、例えば大文字の「Ｉ」を用いてしばしば「Internet（インターネット）」と呼ばれるネットワークのグローバル・インターネットワークのような、ＴＣＰ／ＩＰ（Transfer Control Protocol及びInternet Protocol）ネットワークであるので、本明細書の多くの例でこのネットワークを使用することにする。しかしながら、ＴＣＰ／ＩＰは頻繁に実装されるプロトコルであるが、１つ以上の実装が使用する可能性のあるネットワークはそのように限定されないことを理解すべきである。
【0016】
顧客システム１１２は、ＴＣＰ／ＩＰを使用してシステム１１６と通信することができ、より高いネットワークレベルでは、ＨＴＴＰ、ＦＴＰ、ＡＦＳ、ＷＡＰ等のような他の一般的なインターネットプロトコルを使用することができる。ＨＴＴＰが使用される例では、顧客システム１１２は、システム１１６でＨＴＴＰサーバとの間でＨＴＴＰメッセージを送受信するための「ブラウザ」と一般的に呼ばれるＨＴＴＰクライアントを含むことができる。このようなＨＴＴＰサーバは、システム１１６とネットワーク１１４との間の唯一のネットワークインタフェースとして実装されてもよいが、他の技術が同様に又は代わりに使用されてもよい。いくつかの実装形態では、システム１１６とネットワーク１１４との間のインタフェースは、複数のサーバにわたって負荷をバランスさせて着信ＨＴＴＰ要求を均等に分配する、ラウンドロビンＨＴＴＰ要求分配器のような負荷共有機能を含む。少なくとも、そのサーバにアクセスしているユーザと同様に、複数のサーバの各々は、ＭＴＳのデータへのアクセスを有するが、代わりに、他の代替構成が使用されてもよい。
【0017】
一実施形態では、図１Ａに図示されるシステム１１６は、ウェブベースの顧客関係管理（ＣＲＭ：customer relationship management）システムを実装する。例えば一実施形態において、システム１１６は、顧客システム１１２との間で関連データ、コード、フォーム、ウェブページ及び他の情報を提供し、データ、オブジェクト及びウェブページコンテンツに関連するデータベースシステムとの間で格納及び取り出しを行うだけでなく、ＣＲＭソフトウェアアプリケーションを実装及び実行するようにも構成される、アプリケーションサーバを含む。マルチテナントシステムでは、複数のテナントについてのデータが同一の物理的データベースオブジェクト内に格納されてもよいが、テナントデータは、典型的に、そのようなデータが明示的に共有されない限り、あるテナントが別のテナントのデータへのアクセスを有しないように、あるテナントのデータは他のテナントのデータと論理的に別個に保持されるよう配置される。特定の実施形態では、システム１１６は、ＣＲＭアプリケーション以外のアプリケーション又はこれに加えてアプリケーションを実装する。例えばシステム１１６は、ＣＲＭアプリケーションを含む複合ホスト（標準及びカスタム）アプリケーションへのテナントアクセスを提供することができる。顧客（又は第三者開発者）アプリケーションは、ＣＲＭを含んでいても含んでいなくてもよいが、アプリケーションプラットフォーム１１８によってサポートされる。アプリケーションプラットフォーム１１８は、アプリケーションの作成、１つ以上のデータベースオブジェクトへのアプリケーションの格納、そしてシステム１１６のプロセス空間内の仮想マシンにおけるアプリケーションの実行を管理する。
【0018】
システム１１６の複数の要素の一配置が図１Ｂに図示されている。この配置は、ネットワークインタフェース１２０、アプリケーションプラットフォーム１１８、テナントデータ１２３のためのテナントデータストレージ１２２、システム１１６及び潜在的に複数のテナントに対してアクセス可能なシステムデータ１２５のシステムデータストレージ１２４、システム１１６の様々な機能を実装するためのプログラムコード１２６、そしてアプリケーションホスティングサービスの一部としてアプリケーションを実行することのように、ＭＴＳシステムプロセス及びテナント固有のプロセスを実行するためのプロセス空間１２８を含む。システム１１６上で実行され得る追加のプロセスには、データベースインデックス付けプロセスが含まれる。
【0019】
図１Ａに図示されるシステムのいくつかの要素は、ここでは簡単にしか説明されない従来の周知の要素を含む。例えば顧客システム１１２の各々は、デスクトップ・パーソナル・コンピュータ、ワークステーション、ラップトップ、ＰＤＡ、携帯電話、あるいは任意のワイヤレス・アクセス・プロトコル（ＷＡＰ）対応デバイス、あるいはインターネット又は他のネットワーク接続に直接的又は間接的にインタフェースすることが可能な任意の他のコンピューティングデバイスを含むことができる。顧客システム１１２の各々は、典型的には、ＨＴＴＰクライアント、例えばMicrosoft（登録商標）のInternet Explorerブラウザ、Netscape（登録商標）のNavigatorブラウザ、Operaのブラウザ、あるいは携帯電話、ＰＤＡ又は他のワイヤレスデバイスの場合のＷＡＰ対応ブラウザ等のブラウジングプログラムを実行し、顧客システム１１２の顧客（例えばマルチテナントデータベースシステムのサブスクライバ（subscriber））が、ネットワーク１１４を介してシステム１１６からそれに利用可能な情報、ページ及びアプリケーションにアクセスし、処理し、表示することを可能にする。また、顧客システム１１２の各々は典型的に、システム１１６や他のシステム又はサーバによって提供されるページ、フォーム、アプリケーション及び他の情報と併せてディスプレイ（例えばモニタ画面、ＬＣＤディスプレイ等）上でブラウザによって提供されるグラフィカル・ユーザ・インタフェース（ＧＵＩ）と対話するために、キーボード、マウス、トラックボール、タッチパッド、タッチスクリーン、ペン等のような１つ以上のユーザインタフェースデバイスを含む。例えばユーザインタフェースデバイスは、システム１１６によってホストされるデータ及びアプリケーションにアクセスして、格納されたデータに対して検索を行うために使用されてよく、そうでなければ、ユーザが、該ユーザに提示され得る様々なＧＵＩページと対話することを可能にすることもできる。上述したように、実施形態は、ネットワークの特定のグローバルなインターネットワークを指すインターネットでの使用に適している。しかしながら、イントラネット、エクストラネット、仮想プライベートネットワーク（ＶＰＮ）、非ＴＣＰ／ＩＰベースのネットワーク、任意のＬＡＮ又はＷＡＮ等の他のネットワークが、インターネットの代わりに使用されてもよいことが理解されるべきである。
【0020】
一実施形態によると、顧客システム１１２の各々及びその構成要素のすべては、Intel Pentium（登録商標）プロセッサ等の中央処理ユニットを使用して実行されるコンピュータコードを含むブラウザ等のアプリケーションを使用してオペレータ構成可能である。同様に、システム１１６（及び複数が存在する場合、ＭＴＳの追加インスタンス）及びそれらの構成要素のすべては、Intel Pentium（登録商標）プロセッサ等を含み得るプロセッサシステム１１７等の中央処理ユニット及び／又は複数のプロセッサユニットを使用して実行するよう、コンピュータコードを含むアプリケーションを使用してオペレータ構成可能であってもよい。コンピュータプログラム製品の実施形態は、本明細書で説明される実施形態のプロセスのいずれかを実行するようコンピュータをプログラムするために使用され得る／その上に記憶された命令を有するマシン読取可能な記憶媒体（複数可）を含む。本明細書で説明されるように、ウェブページ、アプリケーション及び他のデータ及び媒体の内容を相互通信して処理するように、システム１１６を動作及び構成するためのコンピュータコードは、例えばダウンロードされてハードディスクに記憶されるが、そのプログラムコード全体又はその一部は、ＲＯＭ又はＲＡＭのような周知の任意の他の揮発性又は不揮発性のメモリ媒体又はデバイスに記憶されてもよく、あるいは、フロッピーディスク、光ディスク、デジタル多用途ディスク（ＤＶＤ）、コンパクトディスク（ＣＤ）、マイクロドライブ、磁気又は光カード、ナノシステム（分子メモリＩＣを含む）を含む任意のタイプの回転媒体等のプログラムコードを記憶することができる任意の媒体、あるいは命令及び／又はデータを記憶するのに適した任意のタイプの媒体又はデバイス上に提供されてもよい。加えて、プログラムコード全体又はその一部は、例えばインターネット等のような伝送媒体を介してソフトウェア・ソースから又は公知の別のサーバから伝送されてダウンロードされてよく、あるいは周知であるような任意の通信媒体及びプロトコル（例えばＴＣＰ／ＩＰ、ＨＴＴＰ、ＨＴＴＰＳ、Ethernet（登録商標）等）を使用して、公知の任意の他の従来的なネットワーク接続（例えばエクストラネット、ＶＰＮ、ＬＡＮ等）を介して伝送されてよい。また、実施形態を実施するためのコンピュータコードは、クライアントシステム及び／又はサーバ又はサーバシステムで実行され得る、例えばＣ、Ｃ＋＋、ＨＴＭＬ、他のマークアップ言語、Java（登録商標）、JavaScript（登録商標）、ActiveX、VBScript等の他の任意のスクリプト言語及び周知の他の多くのプログラミング言語で実行可能な任意のプログラミング言語で実装可能であることも理解されよう（JavaはSun Microsystems社の登録商標である）。
【0021】
一実施形態によれば、システム１１６は、システム１１６のテナントとして顧客システム１１２によるアクセスをサポートするために、ウェブページ、フォーム、アプリケーション、データ及びメディアコンテンツを顧客（クライアント）システム１１２に提供するように構成される。したがって、システム１１６は、データが共有されない限り、各テナントのデータを別個に保持するセキュリティ機構を提供する。２つ以上のＭＴＳが使用される場合、それらは互いに近接して配置されるか（例えば単一の建物又はキャンパス内に配置されるサーバファーム内）、互いに離れた位置に分散されてよい（例えばＡ市内に配置される１つ以上のサーバと、Ｂ市内に配置される１つ以上のサーバ）。本明細書で使用されるように、各ＭＴＳは、１つ以上の地理的位置にローカルに又はこれらにまたがって分散される、１つ以上の論理的及び／又は物理的に接続されるサーバを含むことができる。さらに、用語「サーバ」は、処理ハードウェア及びプロセス空間を含むコンピュータシステム、並びに本技術分野で周知の関連するストレージシステム及びデータベースアプリケーション（例えばＯＯＤＢＭＳ又はＲＤＢＭＳ）を含むように意図される。また、「サーバシステム」及び「サーバ」は、本明細書ではしばしば互換的に使用されることも理解されるべきである。同様に、本明細書で説明されるデータベースオブジェクトは、単一のデータベース、分散データベース、分散データベースの集合、冗長的なオンライン又はオフラインバックアップ又は他の冗長性を有するデータベース等として実装されてよく、分散データベース又はストレージネットワーク及び関連する処理インテリジェンスを含むことができる。
【0022】
図１Ｂも環境１１０を図示している。しかしながら、図１Ｂでは、システム１１６の要素と、一実施形態における様々な相互接続が更に図示されている。図１Ｂは、顧客システム１１２の各々が、プロセッサシステム１１２Ａ、メモリシステム１１２Ｂ、入力システム１１２Ｃ及び出力システム１１２Ｄを含み得ることを示している。図１Ｂは、ネットワーク１１４及びシステム１１６を示す。図１Ｂはまた、システム１１６がテナントデータストレージ１２２、テナントデータ１２３、システムデータストレージ１２４、システムデータ１２５、ユーザインタフェース１４４（ＵＩ）、アプリケーションプログラムインタフェース（ＡＰＩ）１４６、ＰＬ／ＳＯＱＬ １４８、保存ルーチン１５０、アプリケーションセットアップ機構１５２、アプリケーションサーバ１３０、システムプロセス空間１３２、テナントプロセス空間１３４、テナント管理プロセス空間１３６、テナントストレージエリア１３８、顧客ストレージ１４０及びアプリケーションメタデータ１４２を含み得ることも示している。他の実施形態において、環境１１０は、上記に列挙されたものと同じ要素を有さなくてもよく、かつ／又は上記に列挙されたものに代えて又はそれに加えて、他の要素を有してもよい。
【0023】
顧客システム１１２、ネットワーク１１４、システム１１６、テナントデータストレージ１２２及びシステムデータストレージ１２４は、図１Ａで上述した。顧客システム１１２に関して、プロセッサシステム１１２Ａは、１つ以上のプロセッサの任意の組合せであってよい。メモリシステム１１２Ｂは、１つ以上のメモリデバイス、短期及び／又は長期メモリの任意の組合せであってよい。入力システム１１２Ｃは、１つ以上のキーボード、マウス、トラックボール、スキャナ、カメラ及び／又はネットワークへのインタフェースのような入力デバイスの任意の組合せであってよい。出力システム１１２Ｄは、１つ以上のモニタ、プリンタ及び／又はネットワークへのインタフェースのような出力デバイスの任意の組合せであってよい。図１Ｂに図示されるように、システム１１６は、ＨＴＴＰアプリケーションサーバ１３０、（図１Ａの）アプリケーションプラットフォーム１１８、テナントデータストレージ１２２及びシステムデータストレージ１２４のセットとして実装される（図１Ａの）ネットワークインタフェース１２０を含んでもよい。また、個々のテナントプロセス空間１３４及びテナント管理プロセス空間１３６を含むシステムプロセス空間１３２も示されている。各アプリケーションサーバ１３０は、テナントデータストレージ１２２及びその中のテナントデータ１２３、並びにシステムデータストレージ１２４及びその中のシステムデータ１２５にアクセスして、顧客システム１１２の要求に応えるように構成されてよい。テナントデータ１２３は、個々のテナントストレージエリア１３８に分割されてよく、これはデータの物理的配置及び／又は論理的配置のいずれかであってよい。各テナントストレージエリア１３８内において、顧客ストレージ１４０及びアプリケーションメタデータ１４２は、各顧客に対して同様に割り当てられてもよい。例えば顧客の最も最近使用された（ＭＲＵ：most recently used）アイテムのコピーが顧客ストレージ１４０に記憶されてもよい。同様に、テナントである組織全体についてのＭＲＵアイテムのコピーが、テナントストレージエリア１３８に記憶されてもよい。ＵＩ１４４はユーザインタフェースを提供し、ＡＰＩ１４６はシステム１１６常駐プロセスに対するアプリケーション・プログラム・インタフェースを、顧客システム１１２の顧客及び／又は開発者に提供する。テナントデータ及びシステムデータは、１つ以上のデータベース等の様々なデータベースに記憶されてよい。
【0024】
アプリケーションプラットフォーム１１８は、アプリケーション開発者によるアプリケーションの作成及び管理をサポートするアプリケーションセットアップ機構１５２を含み、これは、例えばテナント管理プロセス１３６によって管理される１つ以上のテナントプロセス空間１３４として、サブスクライバによる実行のために、保存ルーチン１５０によってメタデータとしてテナントデータストレージ１２２に保存され得る。このようなアプリケーションに対する起動（Invocations）は、ＡＰＩ１４６に対するプログラミング言語スタイルインタフェース拡張を提供するＰＬ／ＳＯＱＬ１４８を使用してコード化されてよい。いくつかのＰＬ／ＳＯＱＬ言語の実施形態の詳細な説明は、「Method and system for allowing access to developed applications via a multi-tenant on-demand database service」という名称の２００７年９月２１日に出願された共通所有の米国特許第７,７３０,４７８号に記載されており、これはすべての目的のためにその全体が本明細書に組み込まれている。アプリケーションに対する起動は、１つ以上のシステムプロセスによって検出されてよく、このプロセスは、サブスクライバが起動を行うためにアプリケーションメタデータ１４２を取り出し、メタデータを仮想マシン内のアプリケーションとして実行することを管理する。
【0025】
各アプリケーションサーバ１３０は、異なるネットワーク接続を介して、例えばシステムデータ１２５及びテナントデータ１２３へのアクセスを有するデータベースシステムに通信可能に結合され得る。例えばあるアプリケーションサーバ１３０－１はネットワーク１１４（例えばインターネット）を介して結合されてよく、別のアプリケーションサーバ１３０－Ｎは直接ネットワークリンクを介して結合されてよく、別のアプリケーションサーバ１３０－Ｎは更に異なるネットワーク接続によって結合されてよい。転送制御プロトコル及びインターネットプロトコル（ＴＣＰ／ＩＰ）は、アプリケーションサーバ１３０とデータベースシステムとの間で通信するための典型的なプロトコルである。しかしながら、使用されるネットワーク相互接続に応じて、システムを最適化するために他のトランスポートプロトコルが使用されてもよいことは、当業者には明らかであろう。
【0026】
特定の実施形態では、各アプリケーションサーバ１３０は、テナントである任意の組織に関連付けられる任意のユーザの要求を処理するように構成される。何らかの理由でいつでもアプリケーションサーバをサーバプールに追加し、サーバプールから除去できることが望ましいため、特定のアプリケーションサーバ１３０に対する顧客及び／又は組織のためのサーバ・アフィニティは存在しない。したがって、一実施形態では、負荷分散機能（例えばＦ５ Ｂｉｇ－ＩＰロードバランサ）を実装するインタフェースシステムは、アプリケーションサーバ１３０と顧客システム１１２との間で通信可能に結合され、要求をアプリケーションサーバ１３０に分配する。一実施形態では、ロードバランサは、最小限の接続アルゴリズムを使用して、顧客要求をアプリケーションサーバ１３０にルーティングする。ラウンドロビン及び観測応答時間のような負荷分散アルゴリズムの他の例が使用されてもよい。例えば特定の実施形態では、同じ顧客からの３つの連続した要求が３つの異なるアプリケーションサーバ１３０に当たる可能性があり、異なる顧客からの３つの要求が同じアプリケーションサーバ１３０に当たる可能性がある。このように、システム１１６はマルチテナントであり、この場合、システム１１６は、異種の顧客及び組織にわたる異なるオブジェクト、データ及びアプリケーションのストレージ及びそれらへのアクセスを処理する。
【0027】
ストレージの例として、あるテナントは、各販売員がシステム１１６を使用して販売プロセスを管理する販売陣（sales force）を雇用する会社であり得る。したがって、顧客は、連絡先データ（contact data）、リードデータ（lead data）、消費者フォローアップデータ、パフォーマンスデータ、目標及び進捗データ等を維持してよく、これらすべてが（例えばテナントデータストレージ１２２内の）その顧客の個人販売プロセスに適用可能である。ＭＴＳ構成の例では、アクセス、表示、修正、報告、送信、計算等すべきデータ及びアプリケーションのすべてが、ネットワークアクセス以上のものを持たない顧客システムによって維持及びアクセスされ得るので、顧客は、多くの異なる顧客システムのいずれかから販売努力及びサイクルを管理することができる。例えば販売員が顧客を訪問しており、顧客がそのロビー内でインターネットアクセスを提供している場合、販売員は、顧客がロビーに到着するのを待っている間に、その顧客に関する重要な更新を得ることができる。
【0028】
各ユーザのデータは、各ユーザの雇用者に関わらず、他のユーザのデータから分離されてよいが、一部のデータは、テナントである所与の組織について、複数のユーザ又は全ユーザによって共有又はアクセス可能な組織全体にわたるデータであり得る。したがって、テナントレベルで割り当てられ、システム１１６によって管理されるいくつかのデータ構造が存在し、他のデータ構造は、ユーザレベルで管理されてよい。ＭＴＳは、潜在的な競合相手を含む複数のテナントをサポートする可能性があるため、ＭＴＳは、データ、アプリケーション及びアプリケーションの使用を別々に保持するセキュリティプロトコルを持つべきである。また、多くのテナントは独自のシステムを維持するのではなく、ＭＴＳへのアクセスを選択する可能性があるため、冗長性、アップタイム及びバックアップは、ＭＴＳで実装される可能性がある追加機能である。ユーザ固有のデータ及びテナント固有のデータに加えて、システム１１６は、複数のテナント又は他のデータによって使用可能なシステムレベルのデータも維持してよい。このようなシステムレベルのデータには、テナント間で共有可能な産業レポート、ニュース、投稿等が含まれる。
【0029】
特定の実施形態では、顧客システム１１２（クライアントシステムであってもよい）は、アプリケーションサーバ１３０と通信して、システム１１６からのシステムレベル及びテナントレベルのデータを要求及び更新する。これは、１つ以上のクエリをテナントデータストレージ１２２及び／又はシステムデータストレージ１２４に送信することを必要とすることがある。システム１１６（例えばシステム１１６内のアプリケーションサーバ１３０）は、所望の情報にアクセスするように設計される１つ以上のＳＱＬステートメント（例えば１つ以上のＳＱＬクエリ）を自動的に生成する。システムデータストレージ１２４は、データベースから、要求されたデータにアクセスするためのクエリプランを生成することができる。
【0030】
各データベースは、一般に、予め定義されたカテゴリに適合されたデータを含む、論理テーブルのセットのような、オブジェクトの集合として見ることができる。「テーブル」は、データオブジェクトの１つの表現であり、ここでは、オブジェクト及びカスタムオブジェクトの概念的な説明を簡略化するために、テーブルを使用することができる。「テーブル」及び「オブジェクト」は、本明細書において互換的に使用され得ることが理解されるべきである。各テーブルは、一般に、表示可能スキーマ内の列又はフィールドとして論理的に配置される１つ以上のデータカテゴリを含む。テーブルの各行又はレコードは、フィールドによって定義される各カテゴリのデータのインスタンスを含む。例えばＣＲＭデータベースは、名前、住所、電話番号、ファックス番号等の基本連絡先情報のためのフィールドを有する顧客を記述するテーブルを含むことができる。別のテーブルは、顧客、製品、販売価格、日付等の情報のフィールドを含む発注書（purchase order）を記述してよい。一部のマルチテナントデータベースシステムでは、すべてのテナントによる使用のために標準エンティティテーブルが提供されてよい。ＣＲＭデータベースアプリケーションでは、そのような標準エンティティは、予め定義されたフィールドを各々含む、アカウント、連絡先、リード（Lead）及び機会データ（Opportunity data）のテーブルを含んでよい。「エンティティ」という用語は、本明細書において「オブジェクト」及び「テーブル」と互換的に使用されることもあることを理解されたい。
【0031】
いくつかのマルチテナントデータベースシステムでは、テナントは、カスタムオブジェクトを作成及び格納することを許容されてもよく、あるいは例えばカスタムインデックスフィールドを含む標準オブジェクトのカスタムフィールドを作成することによって、標準エンティティ又はオブジェクトをカスタマイズすることが許容されてもよい。「Custom Entities and Fields in a Multi-Tenant Database System」という名称の２００４年４月２日に出願された米国特許第７，７７９，０３９号は、参照によって本明細書に組み込まれる。特定の実施形態では、例えばすべてのカスタムエンティティデータ行が、組織ごとに複数の論理テーブルを含み得る単一のマルチテナント物理テーブルに格納される。複数の「テーブル」が実際には１つの大きなテーブルに格納されていること、あるいは彼らのデータが他の顧客のデータと同じテーブルに格納される可能性があることが、顧客には見えない。
【0032】
本明細書において互換的に称される「顧客」、「会社」又は「クライアント」は、ＣＲＭサービスに加入している会社を指す。例えばCrocs（登録商標）のような企業は、ＣＲＭサービスに加入することができ、本明細書では顧客と称される。本明細書において称されるとき、消費者とは、顧客から、例えば顧客のウェブサイト、顧客の店舗又は顧客による対面販売から、製品又はサービスを購入する個人を指す。
【0033】
統合型企業コマース・アーキテクチャ（Integrated Enterprise Commerce Architecture）
図２は、本開示の一実施形態による統合型企業コマース・アーキテクチャ２０１を図示している。アーキテクチャ２０１は、図１Ａ～図１Ｂ内のシステム１１６及び環境１１０の一部である。
図２は、本開示の一実施形態による統合型企業コマース・アーキテクチャ２０１を図示している。アーキテクチャ２０１は、図１Ａ～図１Ｂ内のシステム１１６及び環境１１０の一部である。
【0034】
図２において、ローイベント（raw event）バス２００は、複数のソースからローイベント２０２－１～２０２－７を受け取る。例えばローイベントバス２００は、これに限定されないが、顧客ウェブページ２０４（例えば消費者によるウェブページ２０４上のクリック）、演算デバイス２０６から（例えば消費者のラップトップ又はデスクトップ）、モバイルデバイス２０８（例えば消費者のスマートフォン及びタブレット）、モノのインターネット（ＩｏＴ）２２４の機能を有するモバイルデバイス２１０、コアデータベース２１４、マーケティング・クラウド（「ＭＣ：marketing cloud」）２１６及びコマース・クラウド（「ＣＣ：commerce cloud」）２１８を含むものからデータを受け取る。一例として、顧客が、顧客ウェブサイト２０４上でアイテムをクリックしてそのアイテムを見る場合、顧客は、そのアイテムをオンラインカートに追加するか、あるいは、顧客がオンラインカートからアイテムを除去する場合、アクティビティのローイベントが生成され、制御タグに関連付けられる。制御タグ２２０－１～２２０－３、サーバイベント２２２－１～２２２－３及びＩＯＴ ２２４は、どのイベントがローイベントバス２００に送信されるかを決定するために使用される。顧客及びクライアント・デバイスは、rawevents.salesforce.comのような特定のインターネットプロトコル（ＩＰ）アドレスにローイベントを送信することによって、ローイベントをローイベントバス２００にパブリッシュすることができる。
【0035】
ローイベントは、典型的に、高ボリュームで低品質のデータである。本明細書で提示される実施形態は、高ボリュームで低品質のデータを低ボリュームで高品質のデータに変換する。従来、管理者は、高ボリュームで低品質のデータを低ボリュームで高品質のデータに変換するコードを作成しなければならなかった。本明細書で提示される実施形態は、この機能を実行するためのポイント・アンド・クリック・ソフトウェア（point-and-click software）を提供し、それにより、そのような変換に必要とされる時間及びコストを大幅に削減する。
【0036】
ローイベント計算器２２６は、マーケティング・クラウド予測インテリジェンス（ＭＣ ＰＩ（predictive intelligence））２２８、コマース・クラウド予測インテリジェンス（ＣＣ ＰＩ）２３０及びローイベントバス２００を介して受け取ったローイベントをソートするためのＫｒｕｘ ２３２のような複数のモジュールを含み、高ボリュームで低品質のデータを低ボリュームで高品質のデータに変換する。例えばＭＣ ＰＩ２２８は、ローイベントバス２００からのイベントを解析して、消費者によってオンライン・チェックアウト・カートに追加されているもの又はオンライン・チェックアウト・カートから削除されているものを決定する。イベントは、カートを識別するためのカート識別情報（ＩＤ）を含むことができる。放置カート・イベント（abandoned cart event）、すなわち、消費者がカートにアイテムを追加したが、チェックアウトせず、トランザクションを完了していないイベントがある場合、ＭＣ ＰＩ２２８は、放置カート・イベントを、企業メッセージングプラットフォーム（ＥＭＰ：Enterprise Messaging Platform）バス２３４に発行する。同様に、カートが、特定のプログラム可能な期間にわたって追加又は削除のようなイベントを見なかった場合、ＭＣ ＰＩ２２８は、そのイベントをＥＭＰバス２３４に出す。ローイベントバス２００及びＥＭＰバス２３４は、１つの大きなバスとすることができる。しかしながら、ローイベントバス２００は、データボリュームが高い可能性があり、顧客又はアプリケーションの所に直接行かない可能性のあるローイベントを処理し、一方、ＥＭＰバス２３４は、トランザクションの更なる詳細を有する可能性があるビジネスイベントを処理する。さらに、ローイベントバス２００は、誰がそれに対するアクセスを有するのか否かを定義することができるだけであるが、ＥＭＰバス２３４は、「誰が何のイベントをいつ取得することを許可されるか」を定義することができるセキュリティモデルを有する。ＥＭＰバス２３４は、異種の異なる顧客のための共通の抽象化層と、異なるシステムにわたるイベントのための共通の共有バスを提供することができる。ＥＭＰバス２３４に進むイベントは、プラットフォームを取り囲む任意のシステムに進むことができる。しかし、異なる顧客及び異なるシステムは、ＥＭＰバス２３４を介して互いに直接通信することはできない。ＥＭＰバス２３４上のイベントは、安全に相互から隔離される。
【0037】
ＥＭＰバス２３４は、イベント・パブリッシュ／イベント・サブスクライブルールを許可する。イベント・パブリッシュ／イベント・サブスクライブルールは、顧客によってＥＭＰバス２３４にパブリッシュされ得るイベントと、顧客によってＥＭＰバス２３４にサブスクライブされ得るイベントと、顧客がＥＭＰバス２３４上の特定のイベントにサブスクライブするときに起こることを提供する。パブリッシュルールをセットアップすると、例えば「ＥＭＥＡ」のRecordTypeを有するPersonAccountsのみを公開することのように、所与のイベントにフィルタ基準を適用して、どのように共有されるかを制限することができる。そして、所与のイベントについて、ＥＭＰバス２３４にパブリッシュする前に、追加情報でペイロードを充実させることができる。例えばRecordType情報を所与の顧客データ変更（ＣＤＣ：customer data change）イベントに追加し、それにより、サブスクライバはフィルタを適用することができる。同様に、サブスクリプション・ルールをセットアップするとき、共有ＥＭＰ２３４からイベントを取り出すときにフィルタ基準を適用することができる。例えばフィルタ基準は、「NorthAmerica」のRecordTypeを有するPersonal Accountのみを処理するようにセットアップすることができる。ＥＭＰバス２３４は、アクションを生成するために使用することができる顧客トリガイベントを提供することができる。例えば放置されたカートを例にとると、放置カート・イベントがＥＭＰバス２３４上でパブリッシュされた後、それをＥＭＰバス２３４にサブスクライブして、ＥＭＰバス２３４から取り出すことができる。放置カート・イベントは、トリガイベントとすることができる。そして、カートを放置した消費者にリマインドする電子メール・アクションを生成することができる。
【0038】
イベントルータ／バッファ２３６は、イベント・パブリッシュ／イベント・サブスクライブルールのサポートを提供する。ＥＭＰバス２３４上で発行されたイベントは、時系列順であり、７２時間のような一定の期間を超えるイベントを、ドロップオフすることができる。したがって、新たにパブリッシュされたイベントは、以前にパブリッシュされたイベントを下に、例えば図２に図示されるように左に押し下げることができる。異なる顧客は、その期間の異なる時点で互いに独立にＥＭＰバス２３４上のイベントにサブスクライブすることができる。例えば図２に図示されるように、Core２１４は、ＥＭＰバス２３４上で新たにパブリッシュされたイベントにサブスクライブすることができる。ＥＣｏｍｍ２５４は、システムのアップグレードのために２４時間停止（bring down）されることがある。ＥＣｏｍｍ２５４が立ち上がった（bring up）後、２４時間前にパブリッシュされたイベントにサブスクライブすることができる。
【0039】
イベント・パブリッシュ／イベント・サブスクライブルールは、イベントのスキーマ、バージョン及びセキュリティを定義することができる。異なる顧客がＥＭＰバスにパブリッシュ／サブスクライブする場合、異なる顧客のために別個の業務を分離することにより、開発ライフサイクルの効率を改善することができる。例えばイベントの新たなバージョンをパブリッシュすることのように、Core２１４に対する更新が存在する。従来的に、ＥＣｏｍｍ２５４、ＯＭＳ２５６、ＭＣ２１６及び第三者システム２５８は、互いに通信するために１対１の接続を有しているが、システムの故障を避け、Core２１４によって発行されるイベントの新しいバージョンを処理するために、同時にアップグレードし、すべて一度に立ち上げる必要がある。ＥＭＰバス２３４では、ＥＣｏｍｍ２５４、ＯＭＳ２５６、ＭＣ２１６及び第三者システム２５８のシステムは、Core２１４のアップグレードの後に異なる時点でアップグレードすることができ、その後、異なる時点でＥＭＰ２３４からの新しいバージョンのイベントにサブスクライブすることができる。ここに提示される実施例は、イベント・パブリッシュ／イベント・サブスクライブルールのためのポイント・アンド・クリック・ユーザインタフェース（ＵＩ）の簡単な使用を提供し、そのようなＵＩは、顧客の管理者がＥＭＰバス２３４にパブリッシュされるべきデータ及びＥＭＰバス２３４からサブスクライブされるべきデータを選択することを可能にする。
【0040】
ＣＣ ＰＩ２３０は、消費者のブラウジング履歴に基づいて製品推奨を提供する。例えば消費者が顧客ウェブサイト２０４でクリックし、オンラインカートに追加又はオンラインカートから削除したアイテムに基づいて、ＣＣ ＰＩ２３０は、第三者及び内部データソースに基づき、製品推奨を生成することができる。製品推奨はＥＭＰバス２３４上に配置される。
【0041】
Ｋｒｕｘ２３２はユーザトラフィックをセグメント化する。Ｋｒｕｘ２３２は、ユーザのクリックを追跡してトラフィックを異なるバケットにセグメント化することを可能にするＵＩを有する。例えばＫｒｕｘ２３２は、Ｋｒｕｘ関連制御タグに基づいてデータをセグメント化することができる。例えば制御タグは、例えばカリフォルニアのように、トラフィックが発生した一般的な場所や、消費者が男性アイテムをクリックしたか女性アイテムをクリックしたか等のようなデータを含むことができる。制御タグ２２０からのデータを用いて、Ｋｒｕｘは、位置、性別、年齢等によってデータをセグメント化することができる。したがって、ローイベント計算器２２６は、高ボリュームで低品質のデータを低ボリュームで高品質のデータに変換し、フィルタされたデータをＥＭＰバス２３４に配置する。
【0042】
クロスクラウド・アプリケーション・コンポーネント２３８は、システム間のシームレスな経験及びデータへのアクセスを提供することによって、統合システムの価値を強調する。クロスクラウド・アプリケーション・コンポーネント２３８は、コマース・ジャーニー（Commerce journeys）・イベントハンドラ２４０、ジャーニー・ビルダ（journey builder）２４２、ランタイム・コンポーネント２４４、仮想エンティティ２４６及びセットアップＵＩ２４８を含む。コマース・ジャーニー・イベントハンドラ２４０は、ローイベント計算器２２６によってフィルタされ、ＥＭＰバス２３４を介して受け取られたイベントに対してアクションをとる。例えばコマース・ジャーニー・イベントハンドラ２４０は、放置カート・イベントについてＥＭＰバス２３４をモニタし、消費者が購入したいかもしれないカート内に残されたアイテムについて消費者にリマインドする電子メールのデータを生成する。ジャーニー・ビルダ２４２は、コマース・ジャーニー・イベントハンドラ２４０によって生成されたデータに基づいて、電子メールを構築して送信する。
【0043】
例えば消費者がショッピングカートにアイテムを追加すると、「カートに追加」イベントがローイベントバス２００上に生成される。ＭＣ ＰＩ２２８は、消費者のショッピングカートに関連付けられる、放置カート・カウンタ・オペレーション（abandoned cart counter operation）を開始又は再開する。一定期間、例えば２日間が経過した後、ＭＣ ＰＩ２２８は、ＥＭＰ２３４に「放置カート」イベントを発行する。コマース・ジャーニー・イベントハンドラ２４０は、「放置カート」イベントをリッスンする。イベントを受け入れると、コマース・ジャーニー・イベントハンドラ２４０は、クエリハンドラ２６４を介して、消費者のアイデンティティ及び電子メールアドレスのように、放置されたカートに関連付けられる追加情報を要求する。この情報を利用して、ジャーニー・ビルダ２４２は消費者への通信を生成して送信する。例えばジャーニー・ビルダ２４２は、消費者に製品への関心を思い出させるため又は割引を提示するための電子メールを生成することができる。各ジャーニーの属性は、ポイント・アンド・クリック・ツールを使用してユーザが定義することができる。この点に関して、ジャーニー属性を決定するように追加の予測ロジックも構成されてもよい。例えばＣＣ ＰＩ２３０のような計算器はまた、テナントに対する消費者の商業的価値に基づく割引の金額等の情報を、ＥＭＰ２３４を介してコマース・ジャーニー・イベントハンドラ２４０に提供することができる。従来の方法は、顧客の管理者が、ローデータを通して解析し、放置カート・イベントを決定し、電子メールを生成するためのコードを書くことを必要とするが、本明細書で提示される実施形態は、このような電子メールをシームレスかつ透明に生成することを可能にするポイント・アンド・クリック・ツールを透明に提供する。クロスクラウド・アプリケーション・コンポーネント２３８によって処理される追加のコマース・ジャーニー・イベントは、カートの除去又は追加のような追加のコマース・イベントを含んでもよい。他のイベントには、消費者関連の変更イベント、メーリングリストの登録解除等の同意イベント、注文イベント（例えば注文のステータスに関する電子メールの生成）及び他のマーケティングイベントが含まれてよい。
【0044】
ランタイム・コンポーネント２４４（「小売ランタイム（retail runtime）ＵＩウィジェット」とも呼ばれる）は、カスタマイズされたＵＩツールのセットである。例えばランタイム・コンポーネント２４４は、イメージ・フレーム（IFrame）ＵＩツール（図示せず）を含み、これは、例えばマーケティング電子メール又は消費者に放置カートを思い出させる電子メールへの製品イメージの統合的な表示及び配置を可能にする。従来、製品イメージのこのような抽出は広範なコーディングを必要とするが、IFrameツールは、このようなイメージのポイント・アンド・クリック抽出を可能にする。ランタイム・コンポーネント２４４はまた、コマース・クラウド２１８及びマーケティング・クラウド２１６のような他のシステムからのデータのカスタマイズされたビューを提供するリストビューツール（図示せず）を含む。仮想エンティティ２４６は、第三者システムとの統合のために共通のクエリレイヤを提供する。仮想エンティティ２４６は、データ連携サービス（data federation service）に委任して、様々なシステムにわたってデータをクエリするための一貫したインタフェースを提供する。これにより、データを複数のシステムからクエリして、そのようなシステムにアクセスしようとするユーザのために複雑さを減少させることができる。
【0045】
セットアップＵＩ２４８（本明細書では「クロスクラウド・セットアップＵＩ」とも呼ばれる）は、ユーザがシステムによって提供される異なるアプリケーション間の接続性を構成することを可能にする、統合されたＵＩ体験を提供する。また、ユーザがスキーマをマッピングして、消費者解決エンジン（ＣＲＥ：Consumer Resolution Engine）２５０を構成することも可能にする。セットアップＵＩ２４８は、ビジネスユーザがユーザ側の高度な技術的能力を必要とすることなく、異なるアプリケーションを構成することを可能にする。セットアップＵＩ２４８を使用して行われた変更は、以下に更に説明されるメタデータサービス２５２に保存される。一実施形態では、セットアップＵＩ２４８は、プログラム開発者が独自のＵＩを作成することを可能にし、それにより、ＵＩフレームワークをマイクロサービスとして顧客に提供する。
【0046】
Core２１４は、コア製品及びサービスのデータベースである。Core２１４は、セールス・クラウド、サービス・クラウド、コミュニティサービス、産業サービス、プラットフォームサービスを含む。マーケティング・クラウド２１６とコマース・クラウド２１８は別個のクラウドとして示されているが、一例では、マーケティング・クラウド２１６とコマース・クラウド２１８はコア２１４の一部であってよい。
【0047】
Ｅコマース（E-commerce）データベース２５４は、店頭Webインタフェースを実行するために使用される情報を格納する。注文管理システム（ＯＭＳ：Order Management System）２５６は、消費者の注文データを格納し、発注後の物流（例えば出荷、返品等）を処理するデータベースである。
【0048】
第三者システム２５８は、企業リソース・プランニング（ＥＲＰ：Enterprise Resource Planning）システムのように第三者に属するデータベース及びシステムである。例えばAdidas（登録商標）のような顧客は、本明細書の実施形態によってイベント・データ分析のようなサービスを提供するため、あるいは消費者のためにマーケティング・メールを生成するために使用されことになるデータを有するであろう。
【0049】
イベントハンドラ２６０－１～２６０－５は、Core、ＭＣ、ＯＭＳ、Ｅコマース及び第三者システムに関連付けられ、ＥＭＰバス２３４からデータを読み出すため又はＥＭＰバス２３４上にデータを配置するために使用されるコードである。
【0050】
データ連携サービス（ＤＦＳ：Data Federation Service）２６２は、クエリを実行し、レコードからデータを読み出し、書き込み又は削除するために、システムのコンポーネントにプラグインするコネクタのセットを提供する。ＤＦＳ２６２は共通のクエリインタフェースを提供するので、顧客は複数のシステムからデータを取得することができる。例えば顧客はクエリを実行し、コマース・クラウド２１８からオンラインカート上のデータを取得することができる。従来、顧客は、クエリをプログラムしてデータを取り出すために、コマース・クラウド２１８のためのシステム固有のアプリケーション・プログラミング・インタフェース（ＡＰＩ）を使用しなければならないであろう。本明細書に提示される実施形態は、顧客が別個のＡＰＩの使用を差し控えることを可能にし、コア２１４、Ｅコマースデータベース２５４、ＯＭＳ２５６、ＭＣ２１６、第三者システム２５８、ＣＲＥ２５０等のような複数の異なる分離されたシステムにわたるクエリのための単一の統一されたＡＰＩを提供する。ＤＦＳでは、アップサート（upsert）／削除ハンドラ２６８は、異なるシステムからの読み出し及び書き戻しを可能にする。ＤＦＳキャッシュ２７０は、パフォーマンス改善のためにデータのローカルコピーを格納する。クエリ実行部（executor）２６６は、クエリの並列実行のために複数のシステムへ到達させることによってクエリを管理する。クエリハンドラ２６４は、クエリから生じるエラーシナリオに対処する。
【0051】
共通のクエリインタフェースを提供することによって、ＤＦＳ２６２は、仮想スキーマ、すなわち、ディスク上に存在しない目標形状（target shape）に対して、仮想エンティティ２４６からクエリを受け取ることができる。次に、ＤＦＳ２６２は、具体的な論理スキーマに対して実行されるべきクエリを解析することができる。ＤＦＳ２６２は、論理スキーマ上でクエリを実行し、目標形状を通して返される結果を提供する。加えて、ＤＦＳ２６２は、メタデータサービス２５２に格納されたメタデータモデル及び変換情報に依存するクエリを実行することができる。これにより、ＤＦＳ２６２は、変換情報を使用して、クエリをダウンストリームシステムのアドホック言語に書き換えることができる。例えば結合（join）又はフィールドを含むクエリを生成することができる。ダウンストリームシステムが結合をサポートするかどうかを知ることなく、ＤＦＳ２６２は、メタデータモデルに依存することによってクエリを実行することができる。例えばクエリは、別個のドメイン（例えば注文ドメイン及び製品ドメイン）に関連付けられる情報を探すことができる。クエリは、注文、注文明細行項目及びそれぞれの注文に関連付けられる製品情報を探すことができる。従来のクエリではダウンストリームシステムへの別々の呼び出しを介してそのような情報を得ることができる場合、ＤＦＳ２６２は、メタデータサービス２５２によって、単一のクエリ呼び出しでこの情報を取得することを可能にされる。
【0052】
従来のシステムは、マルチテナントシステムにおいて、クエリを実行し、データを読み出し又は書き込むために、どこからデータを得るべきかを決定することが困難である。図５及び図６は、マルチテナントのＵＩの例を示す。図５のＵＩは、４つのクラウド、すなわち、コマース・クラウド、サービス・クラウド、セールス・クラウド、マーケティング・クラウドを示している。クラウドの各インスタンスが「テナント」と呼ばれる。例えばCrocs（登録商標）はコマース・クラウドの契約を１件購入している（「Crocs US」）。Crocs USのコマース・クラウドはテナントの一例である。Crocsは、サービス・クラウドの３つの契約を購入している（Crocs North America、Crocs Canada及びCrocs Latin America）。３つのサービス・クラウド契約は、３つの異なるテナントで構成される。同様に、Crocsはセールス・クラウド契約とマーケティング・クラウド契約を購入しており、これらは２つの異なるテナントから構成される。テナントのグローバル・ディレクトリ２７２は、顧客のテナントを管理するためのソースと、テナントに接続するための認証構成を提供する。例えばCrocsは、北米、カナダ、ラテンアメリカ向けのサービス・クラウドテナントを有してよい。一実施形態では、テナントのグローバル・ディレクトリ２７２は信頼関係も管理する。例えばテナントのグローバル・ディレクトリ２７２は、北米とカナダ向けのCrocsサービス・クラウド間の信頼を可能にするが、ラテンアメリカはそうでないとするルールを提供することができる。信頼関係の管理は、一般データ保護規則（「ＧＤＰＲ：General Data Protection Regulation」）等のプライバシー法の遵守も可能にする。例えば顧客によって購入された欧州のクラウドは、欧州のプライバシー法を遵守するために、他の地域のクラウドとの信頼関係を持たない可能性がある。図５及び図６は、テナントの代替リストビューを示す。例えば図５のＵＩは、３つのサービス・クラウドのテナントが存在し、各々１つのマーケティング・クラウド、セールス・クラウド、コマース・クラウドが存在することを示している。「他のデータ（Other Data）」ボタン及び「セールスフォースデータ（Salesforce data）」ボタンは、顧客が、ＥＲＰシステム内の自身のデータ等、Salesforce以外のシステムからの他のデータソースを、Salesforce ＣＲＭデータとともに追加することを可能にする。
【0053】
メタデータサービス２５２は、システムの構成を作成、編集及び格納するためのメタデータ及びスキーマを提供する。マスターレコード・カノニカルモデル（master record canonical models）２８２は、異なるシステム間のスキーマを調和させる共通交換スキーマ（common exchange schema）を提供する。例えばいくつかのレコードは、ラストネームフィールドを「ラストネーム」の代わりに「ファミリーネーム」と呼ぶ。マスターレコード・カノニカルモデル２８２は、例えばファミリーネームが「ラストネーム」に解されるような、レコードのための共通スキーマを提供する。フィールドマッピング・レジストリ２７６は、異なるスキーマを接続する。エンティティスキーマ・レジストリ２７４は、各テナントの特定のスキーマへのアクセスを提供する。ＥＭＰメッセージスキーマ２８０は、どの種類のイベントがＥＭＰバス２３４に進むことができ、どの種類のイベントがＥＭＰバス２３４に進むことができないかについての属性を定義するイベント・レジストリを提供する。ＣＲＥサービスメタデータ２８４は、ＣＲＥ２５０がどのように動作すべきかを決定する。例えばＣＲＥ２５０がどのようにレコードをマッチングして正規化するべきかを決定する。ＣＲＥ２５０は、以下に更に詳細に説明される。ＤＦＳメタデータ２７８は、クエリを使用してＤＦＳ２６２からアクセスすることができる種類のデータを提供する。一実施形態では、メタデータサービス２５２は、スキーマメタデータのバージョニングのためのサポートも提供する。例えばユーザは、複数の異なるメタデータプロファイルを作成して保存することができる。
【0054】
一実施形態では、クエリハンドラ２６４は、複数のデータソースにわたってクエリを実行する要求を受け取ることがある。例えばクエリハンドラは、消費者データについてのクエリ要求を受け取ることがある。応答として、クエリハンドラ２６４は、クエリに関連する第１データソース及び第２データソースを決定する。第１データソース及び第２データソースは、異なるシステムからのものであってよい。クエリハンドラ２６４は、第１データソース、第２データソース及びマスターレコード・カノニカルモデル２８２等の共通交換スキーマに格納されたデータを取り出すことによって要求されたクエリを実行し、異なる第１データソースと第２データソースとの間のスキーマを調和させる。
【0055】
消費者解決エンジン（ＣＲＥ：Consumer Resolution Engine）
従来のデータベース又は顧客関係管理システムでは、特定のシステムにデータをコピーすることなく、異なる分離されたソースからの顧客データを統合して顧客についてのマスターレコードを作成することはできない。従来のシステムの別の問題は、データの起源、すなわち、レコード内のデータの１つ以上のソースを決定することである。さらに、従来のシステムは、データのための監査ログを提供することに苦労してきた。データの起源と監査ログは、プライバシー法を遵守するために不可欠である。例えば顧客がレコードを編集又は削除したい場合、顧客は編集や削除を行うことができる。本明細書で説明されるＣＲＥ２５０は、マルチテナント性、セキュリティ及び規制コンプライアンスを可能にする。実施形態は、データだけでなく、データの周囲のコンテキストも含む、消費者の全体的なビューを構築する。データのソースには、現在既知のタッチポイントと未来のタッチポイントの両方を含め、消費者が企業と接触する可能性のあるすべてのタッチポイントが含まれる。本明細書で言及されるタッチポイントには、例えばポイント・オブ・セール（point-of-sale）、顧客サービス、マーケティング等が含まれる。実施形態は、検索可能なプロファイルを可能にするために、システムを通してデータ起源のトレーサビリティを維持する。また、ＣＲＥ２５０は、データ要素のすべての入力、オペレーション及びアクセスに関する監査ログを維持することもできる。ＣＲＥ２５０はまた、管理者又は「データスチュワード」が、システムの挙動を完全に制御し、データ品質を監視し、必要に応じてデータを修正することを可能にする。
従来のデータベース又は顧客関係管理システムでは、特定のシステムにデータをコピーすることなく、異なる分離されたソースからの顧客データを統合して顧客についてのマスターレコードを作成することはできない。従来のシステムの別の問題は、データの起源、すなわち、レコード内のデータの１つ以上のソースを決定することである。さらに、従来のシステムは、データのための監査ログを提供することに苦労してきた。データの起源と監査ログは、プライバシー法を遵守するために不可欠である。例えば顧客がレコードを編集又は削除したい場合、顧客は編集や削除を行うことができる。本明細書で説明されるＣＲＥ２５０は、マルチテナント性、セキュリティ及び規制コンプライアンスを可能にする。実施形態は、データだけでなく、データの周囲のコンテキストも含む、消費者の全体的なビューを構築する。データのソースには、現在既知のタッチポイントと未来のタッチポイントの両方を含め、消費者が企業と接触する可能性のあるすべてのタッチポイントが含まれる。本明細書で言及されるタッチポイントには、例えばポイント・オブ・セール（point-of-sale）、顧客サービス、マーケティング等が含まれる。実施形態は、検索可能なプロファイルを可能にするために、システムを通してデータ起源のトレーサビリティを維持する。また、ＣＲＥ２５０は、データ要素のすべての入力、オペレーション及びアクセスに関する監査ログを維持することもできる。ＣＲＥ２５０はまた、管理者又は「データスチュワード」が、システムの挙動を完全に制御し、データ品質を監視し、必要に応じてデータを修正することを可能にする。
【0056】
従来のシステムはまた、異なる時間スケールのデータを統合し、異なるソースのデータにアクセスし、データを比較し、それを調和させるという問題にも直面する。本明細書で提示される実施形態は、これらの問題を解決する。ＣＲＥ２５０は、ソーシャルメディア・アプリケーションと統合して、消費者の活動を可視化し、それによって、異なる消費者のタッチポイントを提供することができる。システムは、あるイベントが以前の消費者によって生成されたのか、新しい消費者によって生成されたのかを決定するために、すべての入ってくるイベントの完全に統合されたビューを提供する。消費者の統合されたビューは、消費者に関するデータを調和させたので、消費者の完全な分析を可能にする。これとは対照的に、従来のシステムでは、消費者データの断片しか扱えなかった。例えば図７に示されるように、消費者のサマンサ・スミスは、コマース・クラウドを介して商品を購入し、サービス・クラウドを介して、購入した製品についてのサービスを要求し、コミュニティクラウドを介してセルフ・サービスを実施し、マーケティング・クラウドを介して更なる商品を販売することができる。加えて、Samantha Smithは、企業のTwitter（登録商標）アカウントにTwitterメッセージを送信することができ、また、企業に関連する他の第三者アプリケーションも使用することができる。これらのタッチポイントの各々は、Samantha Smithに関するデータを有するが、そのデータは別個のシステムに分散され、分離されている。さらに、Samantha Smithは、異なるタッチポイントのために、Sam Smith等の異なる名前や異なる電子メールアドレスを使用していることがある。図７に図示されるように、「Customer 360 via CRE（ＣＲＥによるCustomer 360）」は、すべてのタッチポイントからのデータを調和させ、Samantha Smithのマスターレコードを作成することによって、消費者のSamantha Smithについて統一されたビューを提供する。さらに、ＣＲＥは、テナントレコード・リンケージ、デジタルアイデンティティ・リンケージ及び第三者アイデンティティ・リンケージのような、データが来た場所のレコードを保持することによって、データ起源を提供する。顧客レコード調和の更なる詳細及び例は、２０１８年３月２９日に出願された米国特許出願第１５／９４０，４１９号及び２０１８年３月２９日に出願された米国特許出願第１５／９４０，４４８号に見出すことができ、それらの両方とも、参照によってそれぞれの全体が本明細書に組み込まれる。
【0057】
消費者の調和されたデータの統一されたビューは、将来のサービスとマーケティングについて消費者の挙動を分析することができる。例えば顧客は、企業のTwitter（登録商標）をツイートしたり、企業に関連するFacebook（登録商標）の投稿を作成したり、企業の広告が掲載されているウェブサイトを閲覧したり、企業の店舗を訪問したり、企業にリンクされている洗濯機／乾燥機のようなモノのインターネット（ＩＯＴ）デバイスを使用したりすることがある。さらに、データの起源は、プライバシー問題を引き起こすことなく、電子メールのような消費者データをマーケティング又は他の目的に使用することができるかどうかの判断を可能にする。
【0058】
ＣＲＥアーキテクチャ
図３に移ると、データソース３００はデータ獲得を表す。データソース３００は、コマース・クラウド２１８、マーケティング・クラウド２１６又は第三者システム２５８のような任意のデータソースを含むことができる。データソース３００からのデータは、データソースのすべてから、イベントバスを介してＣＲＥ２５０にリアルタイムで流れることができる。
図３に移ると、データソース３００はデータ獲得を表す。データソース３００は、コマース・クラウド２１８、マーケティング・クラウド２１６又は第三者システム２５８のような任意のデータソースを含むことができる。データソース３００からのデータは、データソースのすべてから、イベントバスを介してＣＲＥ２５０にリアルタイムで流れることができる。
【0059】
ストリームプロセッサ３０２は、入ってくるデータ・ストリーム及び出て行くストリーミングデータストリームを処理する。ストリーミングデータはすべて、内部ストリームプロセッサ３０２で処理される。ストリームプロセッサ３０２は、データの起源及び監査能力を提供する監査ハンドラ３０４を含む。メトリクスハンドラ３０６は、例えば新規顧客がどのくらいの数か、更新がどのくらいの数か等といった動作メトリクスを提供する。イベントハンドラ３０８は、流入するストリーミングデータを監視し、データをカノニカルフォーマットに変換する。換言すれば、イベントハンドラ３０８は、正しいコンテキストフォーマットで処理できるように、入力及び出力データのデータ構造を変換する。データマッピング及び変換の例は、２０１８年７月１７日出願の米国特許出願第１６／０３７，４３５号に見出され、これは、参照によってその全体が本明細書に組み込まれる。
【0060】
監査ハンドラ３０４は、更新に対して動作するかどうかを決定するためのオペレーションを実行することができる。例えば新しいイベントがトリガされると、監査ハンドラ３０４は、発生した特定の変更を識別して記録し、更新を処理のために後の段階に転送するかどうかを決定することができる。これにより、監査ハンドラ３０４は、ストリーミングデータに関連付けられるコンテキスト情報に基づいて、ストリーミングデータが追加の処理を必要とするかどうかを判断する。一実施形態では、監査ハンドラ３０４は、この決定に関連付けられる情報又はコンテキスト情報をダウンストリームに送ることができる。
【0061】
変換ルールは、ストリームプロセッサが取り込んだイベントに関するカノニカル情報によって定義され得る。イベントがＥＭＰ２３４からストリームプロセッサ３０２に到達すると、テナント又はイベントに関する他のメタデータのようなコンテキスト情報は、監査ハンドラ３０４が論理的決定を行うことを可能にする。そのような決定は、たとえイベントを取り込む前であっても、データがどのように到着するかについての情報を予測することができる。そのような論理情報は、ストリームプロセッサ３０２によって適用される変換ルールを決定することができる。
【0062】
特定の実施形態では、監査ハンドラ３０４によって取り込まれるデータは、データが単一又は複数のデータソースからデータが取り込まれるとき、異なる形状又は内容を有してよい。例えばストリームプロセッサ３０２は、国フィールド（country field）を有するデータを取り込むことがあり、この場合、国フィールドは、異なるデータ・タイプ又はコンテンツを有してよい。監査ハンドラ３０４は、テナントに関するメタデータ又は他のコンテキスト情報に基づいて、データに関する論理的決定を行うことができる。データには変換ルールを適用してもよい。したがって、外部カスタマイズ顧客開発に依存する代わりに、データが取り込まれて、最終的にＣＲＥエンジン３１４に向けられるときに、メタデータを活用して適切な変換ルールを適用することができる。
【0063】
変更パブリッシャ３１０は、顧客のマスタープロファイルに対する更新をＥＭＰバス２３４にパブリッシュする。例えばリンク又は電子メールアドレスがプロファイルに追加される場合、更新は、ＥＭＰバス２３４上でその顧客にサブスクライブしている誰にも送信される。データバッファ３１２は、ストリームプロセッサ３０２とＣＲＥエンジン３１４との間のデータをバッファする。
【0064】
ＣＲＥエンジン３１４は、入力データが正規化されるデータ準備モジュール３１６を含む。例えばデータのソースによっては、アドレス又は電話番号が誤ったフォーマットであったり、不完全であったりする可能性がある。また、データ準備モジュール３１６は、例えば欠落している可能性のある地域コード又は国コードを追加することによってデータを補充する。マッチングモジュール３１８は、各レコードについて、既存のマスタープロファイルへの接続があるかどうかを判断する。例えばサービス・クラウドからのサービスレコードに関連付けられている人物を、ゲストチェックアウト・コマースレコードに関連付けられている人物とマッチングすることができる。したがって、マッチングモジュール３１８は、分離されたレコードを接続するエッジを作成する。
【0065】
ＣＲＥエンジン３１４は、個々の消費者に向けられた関連する異なるデータソースから、異なる消費者データレコードを受け取り、関連付けることができる。マッチングモジュール３１８は、異なるデータソースから受け取った消費者レコードを標準フォーマットにフォーマットし、少なくとも１つの変換ルールに基づいて、その消費者データを既存のレコードとマッチングする。さらに、ＣＲＥエンジン３１４は、フォーマットされたデータ及び個々の消費者に関連付けられる既存のレコードを使用して、そのような方法で消費者のためのマスターレコードを作成することができる。
【0066】
図７に関して上述したように、異なるソースにおけるSamantha Smithのための異なるレコードは、マッチングモジュールによって接続されてもよい。複数のレコードから１つのレコードを作成するように、マッチングルールが構成されて最適化される。マッチングモジュール３１８は、基準の構成可能なセットを使用して、カノニカルデータモデル内のマッチングレコードを決定する。ＵＩの実施形態は、管理者がマッチングルールをセットアップして構成することを可能にする。マッチングルールは、基準（criteria）と、マッチングに使用できる条件（condition）の組合せとで構成される。データマッピングは、管理者が、顧客データとカノニカルフォーマットとの間のフィールドタイプにおける不一致を解決するコードを書くことを可能にすることができる。
【0067】
解決モジュール３２０は、レコード間の接続を分析して、どのレコードをクラスタ化すべきかを決定する。調和モジュール３２２は、異なるレコードのクラスタを使用してマスターレコードを作成する。また、マスタープロファイル内の特定の値の構成、例えばある人物についての所望の電子メールアドレスの構成も可能である。例えば図７の「Customer 360 via CRE」レコードは、例えばコマース・クラウド、セールス・クラウド、第三者ソース等からの他のレコードを使用して、調和モジュール３２２によって作成される。複数のマッチがある場合は、データ調和のための異なるルールを一次及び二次タイブレーカー・ルール（tiebreaker rules）とともに入力することができる。
【0068】
ＣＲＥ制御プレーン３２４は、ＣＲＥシステムの部分間のデータフローのオーケストレーション（orchestration）及びシステムの特定の部分で問題が発生した場合のエラー処理を管理する。バッチ・オーケストレーションモジュール３２６は、すべてのファイルが正しい位置にあり、処理リソースが利用可能であることを確実にすることによって、バッチ処理を監督し、処理が実施されたときに通知を提供する。ストリーミング・オーケストレーションモジュール３２８は、ＣＲＥ ２５０が正しい企業メッセージングプラットフォーム（Enterprise Messaging Platform）チャネルを聞いており、正しいチャネルにパブリッシングを行っていることを確実にする。障害回復（failure recovery）モジュール３３０は、システム内の障害を管理し、障害時に別のデータセンター内のリソースを割り当てることができる。システムワイド・オペレーション（System wide ops）モジュール３３２は、システムのソフトウェア・コンポーネントを開始及び停止する。一例では、ＣＲＥ制御プレーン３２４はまた、弾性インフラストラクチャにおいてハードウェア容量のプロビジョニングを行うこともできる。
【0069】
顧客ハブ３３４は、監査データ、メトリクスデータ及びレコードリンケージを含むすべてのマスタープロファイルが格納される場所である。顧客ハブ３３４はまた、プロファイルに使用され得るデータの要素、例えばコマース・クラウド又はサービス・クラウドから入ってくるリンケージ又は顧客連絡先データを格納する。
【0070】
ＣＲＥデータ３３６は、ＣＲＥ ＡＰＩ３３８を含む。ＣＲＥ ＡＰＩ３３８は、データスチュワードシップモジュール３４０を含む。データスチュワードシップモジュール３４０は、顧客又は管理者がマスターレコードを編集又は削除することを可能にする。例えばＧＤＰＲのようなプライバシー法の遵守のために、消費者が自身の情報を削除したい場合、データスチュワードシップモジュールを使用して、顧客ハブ３３４内の消費者のレコードを削除することができる。また、データスチュワードシップモジュール３４０は、監査及びメトリクスデータに対するユーザの可視性を与える。データスチュワードシップのためのＵＩは、レコードがまだ流れてきているかどうか、どのような速度で流れてきているか、どのくらいのレコードがエラーを発生しているか、どのような方法論（例えばファジーマッチングや正確なマッチング）がレコードとマッチングするために使用されているか等の情報を提供することができる。また、データスチュワードシップモジュール３４０は、顧客がプロファイルに対してクエリを実行し、プロファイル内のデータのソースを決定することを可能にする。例えばデータスチュワードシップモジュール３４０は、他のフィールドの中でも特に、入ってくる要求の優先レベル、要求のタイプ及び要求者に基づいて、ユーザがユーザインタフェースを介してデータを管理することを可能にする。ユーザインタフェースは、要求者からのメモとともに「プライバシー削除」のような要求タイプを表示することができる。さらに、データスチュワードシップモジュール３４０は、ユーザがフラグ付きレコードを単一のプロファイルレコードにマージすることを可能にする。データスチュワードシップモジュール３４０は、ユーザが、その中に含まれるデータに基づくレコードの検索を実行することを可能にする。
【0071】
ＣＲＥエクスポートモジュール３４２は、データ分析のため、そして外部使用のために顧客ハブ３３４から大きなデータセットを移動させるために使用される。ＣＲＥ検索モジュール３４４は、顧客ハブ３３４への同期アクセスを提供する。例えばＣＲＥ検索モジュール３４４は、顧客がマスタープロファイルの候補リストを検索することを可能にする。また、リアルタイムクエリやルックアップも可能である。管理者が顧客ハブ３３４からのデータをウェブページ上に置きたい場合、ウェブページをレンダリングするために、ＣＲＥ検索モジュールを使用してクエリを実行する。また、ＣＲＥデータ３３６は、ＤＦＳ ＣＲＥコネクタ３４６を介してＤＦＳ２６２から来るクエリに対する検索結果も提供する。上述のように、ＤＦＳ２６２はテナントにわたって及びＣＲＭシステム全体にわたってクエリする。
【0072】
顧客ハブ３３４を含むことに加えて、Ｈｂａｓｅ３４８は、構成データ３５０、メトリクスデータ３５２及び監査データ３５４を含む。ＨＢａｓｅは、顧客ハブのストレージレイヤとして使用されるＮｏＳＱＬ技術とすることができる。構成データ３５０は、ＣＲＥエンジン３１４で使用されるようなデータ準備、マッチング、解決及び調和のためのルールを格納する。メトリクスデータ３５２は、メトリクスハンドラ３０６から受け取ったデータを格納する。監査データ３５４は、監査データを格納する。
【0073】
セットアップモジュール３５６は、クラウド関連サービスのためのＵＩアプリケーションである。レポーティングモジュール３５８は、顧客が決定を行うのを助けるために、システムの動作ステータスを提供する。レポーティングモジュール３５８は、マスター消費者プロファイルが、顧客が望む方法で構築されていることを、顧客に決定させる。レポーティングモジュール３５８はまた、システムがどのように動作しているかについてのフィードバックも提供する。外部ローディング分析視覚化（External loading analytics visualization）モジュール３６０は、顧客が、彼らの好ましいフォーマットで、例えばグラフ又はチャートとして、データをエクスポートして視覚化することを可能にする。
【0074】
FileForce（登録商標）３６２は、バッチ出力３６４及びバッチ入力３６６のためのファイルを格納する。バッチ入力３６６は、ＣＲＥエンジン３１４によってストリームプロセッサ３０２からのストリーミングデータとマージすることができる、顧客について以前に格納されたすべてのデータを含む。バッチ出力３６４は、ＣＲＥエンジン３１４から受け取られた、洗練された顧客データ（refined customer data）である。バッチ入力３６６及びバッチ出力３６４内のデータは、「ｃｓｖ」フォーマットで格納されてよい。
【0075】
本明細書で開示されているソフトウェアモジュールのうちの１つ以上は、コンテナ化されたソフトウェアを利用することができることが理解されよう。コンテナ化されたソフトウェアモジュールは、複数の開発者からのソフトウェアを同じマシン上で動作させることを可能にする。同一の識別番号を有する特定の要素は、図示を容易にするために、複数の図で異なる場所に示されていることが理解されよう。しかし、これらは同じ要素である。
【0076】
コンピュータシステム実装
様々な実施形態は、図４に図示されるコンピュータシステム４００のような１つ以上の周知のコンピュータシステムを使用して実装されてよい。１つ以上のコンピュータシステム４００を使用して、例えば本明細書で説明された実施形態のいずれか、並びにそれらの組合せ及び副次的組合せを実装してよい。
様々な実施形態は、図４に図示されるコンピュータシステム４００のような１つ以上の周知のコンピュータシステムを使用して実装されてよい。１つ以上のコンピュータシステム４００を使用して、例えば本明細書で説明された実施形態のいずれか、並びにそれらの組合せ及び副次的組合せを実装してよい。
【0077】
コンピュータシステム４００は、プロセッサ４０４のような１つ以上のプロセッサ（中央処理ユニット又はＣＰＵとも呼ばれる）を含んでもよい。プロセッサ４０４は、通信インフラストラクチャ又はバス４０６に接続されてよい。
【0078】
コンピュータシステム４００はまた、モニタ、キーボード、ポインティングデバイス等のユーザ入力／出力デバイス４０３も含んでよい。ユーザ入力／出力デバイス４０３は、ユーザ入力／出力インタフェース４０２を介して通信インフラストラクチャ４０６と通信することができる。
【0079】
プロセッサ４０４の１つ以上は、グラフィックス処理ユニット（ＧＰＵ）であってもよい。一実施形態では、ＧＰＵは、数学的集約アプリケーションを処理するように設計された専用の電子回路であるプロセッサであってもよい。ＧＰＵは、コンピュータ・グラフィックス・アプリケーション、画像、ビデオ等に共通の数学的集約データのような、データの大きなブロックの並列処理に効率的な並列構造を有してもよい。
【0080】
コンピュータシステム４００はまた、ランダムアクセスメモリ（ＲＡＭ）のようなメイン（又は一次）メモリ４０８を含んでもよい。メインメモリ４０８は、キャッシュの１つ以上のレベルを含んでもよい。メインメモリ４０８は、その中に制御ロジック（すなわち、コンピュータソフトウェア）及び／又はデータを格納しておくことができる。
【0081】
コンピュータシステム４００はまた、１つ以上の二次ストレージデバイス又はメモリ４１０も含んでよい。二次メモリ４１０は、例えばハードディスクドライブ４１２又は取り外し可能ストレージデバイス又はドライブ４１４を含むことができる。取り外し可能ストレージドライブ４１４は、フロッピーディスクドライブ、磁気テープドライブ、コンパクトディスクドライブ、光ストレージデバイス、テープバックアップデバイス又は任意の他のストレージデバイス／ドライブであってもよい。
【0082】
取り外し可能ストレージドライブ４１４は、取り外し可能ストレージユニット４１８と対話することができる。取り外し可能ストレージユニット４１８は、その上にコンピュータソフトウェア（制御ロジック）又はデータを記憶した、コンピュータ使用可能又は読み取り可能なストレージデバイスを含んでもよい。取り外し可能ストレージユニット４１８は、フロッピーディスク、磁気テープ、コンパクトディスク、ＤＶＤ、光ストレージディスク又は任意の他のコンピュータデータストレージデバイスであってよい。取り外し可能ストレージドライブ４１４は、取り外し可能ストレージユニット４１８との間で読み取り又は書き込みを行うことができる。
【0083】
二次メモリ４１０は、コンピュータプログラムあるいは他の命令又はデータがコンピュータシステム４００によってアクセスされることを可能にする他の手段、デバイス、コンポーネント、機器又は他のアプローチを含んでもよい。そのような手段、デバイス、コンポーネント、機器又は他のアプローチは、例えば取り外し可能ストレージユニット４２２及びインタフェース４２０を含んでもよい。取り外し可能ストレージユニット４２２及びインタフェース４２０の例は、プログラムカートリッジ及びカートリッジインタフェース（ビデオゲームデバイス内で見られるもの等）、取り外し可能メモリチップ（ＥＰＲＯＭ又はＰＲＯＭ等）及び関連ソケット、メモリスティック及びＵＳＢポート、メモリカード及び関連メモリカードスロット又は他の取り外し可能ストレージユニット及び関連インタフェースを含んでもよい。
【0084】
コンピュータシステム４００は、通信又はネットワークインタフェース４２４を更に含むことができる。通信インタフェース４２４は、コンピュータシステム４００が、（参照番号４２８によって個々に、かつ、集合的に参照される）外部デバイス、外部ネットワーク、外部エンティティ等の任意の組合せと通信して対話することを可能にし得る。例えば通信インタフェース４２４は、コンピュータシステム４００が通信経路４２６を介して外部又はリモートデバイス４２８と通信することを可能にしてよい。通信経路４２６は、有線又は無線（又はそれらの組合せ）であってもよく、ＬＡＮ、ＷＡＮ、インターネット等の任意の組合せを含んでもよい。制御ロジック又はデータは、通信経路４２６を介してコンピュータシステム４００との間で送信されてよい。
【0085】
コンピュータシステム４００は、いくつかの非限定的な例を挙げると、パーソナル・デジタル・アシスタント（ＰＤＡ）、デスクトップ・ワークステーション、ラップトップ又はノートブックコンピュータ、ネットブック、タブレット、スマートフォン、スマート・ウォッチ又は他のウェアラブル、アプライアンス、モノのインターネット（Internet-of-Things）の一部又は組み込みシステム、あるいはそれらの任意の組合せのいずれかとすることもできる。
【0086】
コンピュータシステム４００は、任意の配信パラダイムを通して任意のアプリケーション又はデータにアクセスするかホストする、クライアント又はサーバであってよく、限定ではないが：リモート又は分散クラウド・コンピューティング・ソリューション；ローカル又はオンプレミス（on-premises）ソフトウェア（「オンプレミス」クラウド・ベースのソリューション）；「アズ・ア・サービス（as a service）」モデル（例えばコンテンツ・アズ・ア・サービス（ＣａａＳ）、デジタルコンテンツ・アズ・ア・サービス（ＤＣａａＳ）、ソフトウェア・アズ・ア・サービス（ＳａａＳ）、管理ソフトウェア・アズ・ア・サービス（ＭＳａａＳ）、プラットフォーム・アズ・ア・サービス（ＰａａａＳ）、デスクトップ・アズ・ア・サービス（ＤａａＳ）、フレームワーク（ＦａａＳ）、バックエンド・アズ・ア・サービス（ＢａａＳ）、モバイルバックエンド・アズ・ア・サービス（ＭＢａａＳ）、インフラストラクチャ・アズ・ア・サービス（ＩａａＳ）；又は上記の例又は他のサービス又は配信パラダイムの任意の組合せを含むハイブリッド・モデルを含む。
【0087】
コンピュータシステム４００における任意の適用可能なデータ構造、ファイル・フォーマット及びスキーマは、JavaScript（登録商標） Object Notification（ＪＳＯＮ）、ＸＭＬ（Extensible Markup Language）、ＹＡＭＬ（Yet Another Markup Language）、ＸＨＴＭＬ（Extensible Hypertext Markup Language）、ＷＭＬ（Wireless Markup Language）、MessagePack、ＸＵＬ（ＸＭＬ User Interface Language）又は任意の他の機能的に類似した表現を単独で又は組合せで含むが、これらに限定されない規格から導出されてよい。あるいは、専用のデータ構造、フォーマット又はスキーマが排他的に、あるいは既知の又はオープンな規格との組合せで使用されてもよい。
【0088】
いくつかの実施形態において、その上に記憶された制御ロジック（ソフトウェア）を有する、有形の非一時的なコンピュータ使用可能又は読取可能な媒体を含む、有形の非一時的な装置又は製品は、本明細書において、コンピュータプログラム製品又はプログラムストレージデバイスと称されることもある。これは、コンピュータシステム４００、メインメモリ４０８、二次メモリ４１０及び取り外し可能ストレージユニット４１８及び４２２、並びに上記のいずれかの組合せを具体化する有形の製品が含まれるが、これらに限定されない。そのような制御ロジックは、１つ以上のデータ処理デバイス（コンピュータシステム４００等）によって実行されるとき、本明細書で記載されるように、そのようなデータ処理デバイスを動作させることができる。
【0089】
本開示に含まれる教示に基づいて、図４に示されるもの以外のデータ処理デバイス、コンピュータシステム又はコンピュータ・アーキテクチャを用いて、本開示の実施形態をどのように作製し、使用するかは、当業者に明らかであろう。特に、実施形態は、本明細書に記載されているもの以外のソフトウェア、ハードウェア及び／又はオペレーティングシステムの実装で動作することができる。
【0090】
結論
詳細な説明のセクションは、他のセクションではなく、クレームを解釈するために使用されるように意図されていることが理解されよう。他のセクションは、本発明者によって考慮される、すべてではないが１つ以上の例示の実施形態を説明することができ、したがって、本開示又は添付の特許請求の範囲をいかなるようにも限定するようには意図されていない。
詳細な説明のセクションは、他のセクションではなく、クレームを解釈するために使用されるように意図されていることが理解されよう。他のセクションは、本発明者によって考慮される、すべてではないが１つ以上の例示の実施形態を説明することができ、したがって、本開示又は添付の特許請求の範囲をいかなるようにも限定するようには意図されていない。
【0091】
本開示は、例示的な分野及び用途の例示的な実施形態を記載しているが、本開示はそれに限定されないことを理解されたい。他の実施形態及びそれに対する修正が可能であり、本開示の範囲及び精神内にある。例えば本段落の一般性を制限することなく、実施形態は、図面に図示されるか、本明細書で説明されるソフトウェア、ハードウェア、ファームウェア又はエンティティに限定されない。さらに、実施形態（本明細書で明示的に説明されているか否かにかかわらず）は、本明細書で説明される実施例を超える分野及び用途に対して有意な有用性を有する。
【0092】
本明細書では、特定の機能の実施及びそれらの関係を例示する機能的構築ブロックを用いて、実施形態を説明した。これらの機能的構成要素の境界は、説明の便宜上、本明細書中で任意に定義されている。特定の機能と関係（又はその均等物）が適切に実施される限り、別の境界を定義することができる。また、代替の実施形態は、本明細書で説明されるものとは異なる順序を使用して、機能ブロック、ステップ、動作、方法等を実行することができる。
【0093】
本明細書において、「一実施形態」、「ある実施形態」、「例示的な実施形態」又は類似のフレーズへの言及は、説明された実施形態が特定の特徴、構造又は特性を含むことができるが、すべての実施形態が必ずしも特定の特徴、構造又は特性を含まない可能性があることを示す。そのようなフレーズは、必ずしも同一の実施形態を指していない。さらに、特定の特徴、構造又は特性がある実施形態に関連して説明されるとき、このような特徴、構造又は特性を、本明細書に明示的に記載又は説明されているか否かにかかわらず、他の実施形態に組み込むことは当業者の知識の範囲内であろう。さらに、いくつかの実施形態は、「結合された（coupled）」及び「接続された（connected）」という表現をそれらの派生語とともに使用して説明される可能性がある。これらの用語は、必ずしも互いに同義語として意図されているわけではない。例えばいくつかの実施形態は、２つ以上の要素が互いに直接的に物理的又は電気的に接触していることを示すために、「接続された」又は「結合された」という用語を使用して説明されることができる。しかしながら、用語「結合された」は、２つ以上の要素が互いに直接接触していないが、依然として相互に協働又は相互作用していることも意味する可能性がある。
【0094】
本開示の広さ及び範囲は、上述の例示的な実施形態のいずれによっても制限されるべきではなく、以下の特許請求の範囲及びそれらの均等物に従ってのみ定義されるべきである。
【図1A】
【図1B】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【外国語明細書】