【手続補正書】
【提出日】平成24年7月2日(2012.7.2)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
１つまたは複数の組織用の複数のテーブルを単一のマルチテナント・データ構造中に格納して管理する方法において、
プライマリ・キー列（２０２、２１２）、組織ｉｄ列（２０１、２１１）、および複数のデータ列（２０３、２１３）を有するマルチテナント・データ構造（２００）を定義する段階と、
第１のテナント（“組織＃１“）用の第１のテーブル（“組織＃１“）を定義する段階であって、この第１のテーブルは第１のデータ・フィールド（図３の“組織＃１“や”Ｖａｌ０“）を有し、前記第１のテナントは第１のテナントｉｄ（“組織＃１“）を有する、第１のテーブル定義段階と、
前記第１のテーブルに第１のテーブルｉｄを割り当てる段階と、
第２のテナント（“組織＃２“）用の第２のテーブル（“組織＃２“）を定義する段階であって、この第２のテーブルは第２のデータ・フィールド（図３の“組織＃２“や”Ｖａｌ０“）を有し、前記第２のテナントは第２のテナントｉｄ（“組織＃２“）を有する、第２のテーブル定義段階と、
前記第２のテーブルに第２のテーブルｉｄを割り当てる段階とを備える方法であって、
前記第１のテナントによって前記第１のテーブル用にレコードが作成されるときに、これら作成される各々のレコード毎に、
ａ）前記第１のテーブルの前記第１のデータ・フィールドの値を、前記マルチテナント・データ構造２００内の単一のデータ列（２１３）に記憶する段階と、
ｂ）前記第１のテナントｉｄを前記組織ｉｄ列（２０１、２１１）に記憶する段階と、
ｃ）前記第１のテーブルｉｄを前記プライマリ・キー列（２０２、２１２）に記憶する段階と、を具え、さらに、
前記第２のテナントによって前記第２のテーブル用のレコードが作成されるときに、作成される各々のレコード毎に、
ａ）前記第２のデータ・フィールドの値を前記データ構造内の前記単一のデータ列（２１３）に記憶する段階と、
ｂ）前記第２のテナントｉｄを前記組織ｉｄ列（２０１、２１１）に記憶する段階と、
ｃ）前記第２のテーブルｉｄを前記プライマリ・キー列（２０２、２１２）に記憶する段階と、
を具えることにより、前記第１および第２のテナントの前記第１および第２のテーブルが前記マルチテナント・データ構造（２００）に記憶される、ことを特徴とするコンピュータによって実現される方法。
【請求項２】
前記マルチテナント・データ構造が１つまたは複数のインデックス列（３２０）を含み、
前記第１のテナントからの、前記第１のデータ・フィールド内のデータに対するインデックス付け要求に応答して、前記第１のテーブル用の前記単一のデータ列２１３に記憶されているデータ値を、前記インデックス列（３２０）の第１の列にコピーするコピー段階をさらに具える、
請求項１記載の方法。
【請求項３】
前記コピー段階は、前記第１のテナントｉｄ（３１１）、前記第１のテーブルｉｄ（３１２）、および前記第１のデータ・フィールドに基づいて、コピーすべきデータ値を識別する段階を含む、請求項２記載の方法。
【請求項４】
前記第１のデータ・フィールドが第１のデータ・タイプ（図３の“組織＃１”の“データタイプ１“）を有し、前記第２のデータ・フィールドが前記第１のデータ・タイプとは異なる第２のデータ・タイプ（図３の“組織＃２”の“データタイプ２“）を有することにより、前記単一のデータ列（２１３）が前記第１および第２のデータ・タイプを有するデータ値を含むようにした、請求項１記載の方法。
【請求項５】
コンピュータによって実現され、１つまたは複数のテナント用の複数のテーブルを単一データ構造に記憶する方法において、
プライマリ・キー列（４０２）、組織ｉｄ列（４０１）、および複数のデータ列（４０３）を有するデータ構造（４００）を定義する段階と、
第１のテナント（“組織＃１”）用に、第１のデータフィールドを有する第１のテーブルを定義する段階であって、前記第１のデータフィールドが第１のデータタイプ（図５の “データタイプ１”）を有し、前記第１のテナントが第１のテナントｉｄを有する、第１テーブル定義段階と、
前記第１のテーブルに第１のテーブルｉｄ（４０２）を割り当てる段階と、
前記第１のテナント用に、第２のデータ・フィールドを有する第２のテーブルを定義する段階であって、前記第２のデータフィールドは、前記第１のデータ・タイプとは異なる第２のデータタイプ（“データタイプ２”）を有する、第２テーブル定義段階と、
前記第２のテーブルに、第２のテーブルｉｄを割り当てる段階と、
を含む方法であって、
前記第１のテーブル用のレコードが作成されるときに、作成される各々のレコード毎に、
ａ）前記第１のデータ・フィールドの値を、前記データ構造内の単一のデータ列（図５の４０３の“ｖａｌ０“列）に記憶する段階と、
ｂ）前記第１のテナントｉｄを、前記組織ｉｄ列（４０１）に記憶する段階と、
ｃ）前記第１のテーブルｉｄを、前記プライマリ・キー列（４０２）に記憶する段階と、
前記第２のテーブル用のレコードが作成されるときに、作成される各々のレコード毎に、
ａ）前記第２のデータ・フィールドの値を、前記単一のデータ列（４０３の“ｖａｌ０”列）に記憶する段階と、
ｂ）前記第１のテナントｉｄを、前記組織ｉｄ列（４０１）に記憶する段階と、
ｃ）前記第２のテーブルｉｄを、前記プライマリ・キー列（４０２）に記憶する段階と、
とを具備することにより、前記第１のテナントの前記第１および第２のテーブルが前記データ構造（４００）に記憶され、前記単一のデータ列（４０３）が、前記第１および第２のデータ・タイプを有するデータ値を含むようになる、ことを特徴とする方法。
【請求項６】
第２のテナント（“組織＃２）用に、第３のデータ・タイプを有する第３のデータ・フィールドを有する第３のテーブルを定義する段階であって、前記第２のテナントは第２のテナントｉｄ（“組織＃２”）を有する、第３テーブル定義段階と、
前記第３のテーブルに、第３のテーブルｉｄを割り当てる段階、とを具備し、さらに、
前記第３のテーブル用のレコードが作成されるときに、作成される各々のレコード毎に、
前記第３のデータ・フィールドの値を、前記データ構造内の前記単一のデータ列に記憶する段階と、
前記第２のテナントｉｄを、前記組織ｉｄ列に記憶する段階と、
前記第３のテーブルｉｄを、前記プライマリ・キー列に記憶する段階と、
を具備することにより、前記第１、第２および第３のテーブルが前記データ構造に記憶され、前記単一のデータ列が前記第１と第２のデータ・タイプおよび第３のデータ・タイプを有するデータ値を含む、請求項５記載の方法。
【請求項７】
前記第１と第２のテーブルｉｄが異なる、請求項５記載の方法。
【請求項８】
前記第１と第２のテーブルｉｄが異なり、前記第３のテーブルｉｄが、前記第１および第２のテーブルｉｄのうちの一方と同じである、請求項６記載の方法。
【請求項９】
前記データ構造が１つまたは複数のインデックス列を含み、
前記第１のテナントからの、前記第１のデータ・フィールド内のデータにインデックス付けする、という要求に応答して、前記第１のテーブル用の前記単一のデータ列に記憶されているデータ値を、前記インデックス列の第１の列にコピーするコピー段階をさらに含む、
請求項５記載の方法。
【請求項１０】
前記コピー段階は、コピーされたデータ値を修正されたフォーマットに変換する変換段階を含む、請求項９記載の方法。
【請求項１１】
前記変換段階は、ケース・フォールディング・アルゴリズムをデータ値に適用する段階を含む、請求項１０記載の方法。
【請求項１２】
前記第３のデータ・タイプは、前記第１のデータ・タイプと前記第２のデータ・タイプとこれら第１および第２のデータ・タイプとは異なるデータ・タイプとから成るデータタイプ群から選択される、請求項５記載の方法。
【請求項１３】
前記第１のテナントが前記第１のテーブル用のレコードを作成するときに、そのレコードについての前記第１のデータ・フィールド内のデータ値がしきい値基準を満たすかどうかを判定するプロセスを実行する段階と、データ値がしきい値基準を満たす場合に、アクションルールを処理する段階と、をさらに具える、請求項５記載の方法。
【請求項１４】
前記アクションルールが通知の受信側を示す場合には、当該通知メッセージを自動的に前記受信側に送信する段階をさらに含む、請求項１３記載の方法。
【請求項１５】
前記第１のデータ・テーブル用の所有者フィールドを定義する段階をさらに含み、
この所有者フィールドに格納されている各データ値は、夫々に関連するレコードに関する階層ユーザ・アクセス・レベルを示す、請求項５記載の方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００２
【補正方法】変更
【補正の内容】
【０００２】
セールスフォースドットコム・サービスなどのマルチテナント・データベース・システムでは、顧客組織（すなわち、テナント）が1つの論理データベース内のデータベース・リソースを共用するマルチテナント・アーキテクチャが使用される。通常、データベース・テーブル自体が共用され、データ・モデル内の各エンティティは通常、各テナントの行を識別する組織_id列を含む。テナントのコンテクスト内のすべての問合せおよびデータ操作はこの（インデックス付けされた）組織_idでフィルタリングされ、適切なセキュリティが確保されると共に仮想個人データベースが確実に表示される。セールスフォースドットコム・システムでは、たとえば、この方式を使用して、得意先エンティティ、連絡先エンティティ、リード・エンティティ、「好機」(opportunity)エンティティのような標準エンティティを顧客に示す。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００２７
【補正方法】変更
【補正の内容】
【００２７】
各データベースは一般に、定義済みの範疇に適合するデータを含む1組の論理テーブルのようなオブジェクトの集合とみなすことができる。「テーブル」は、データ・オブジェクトの一表現であり、本明細書では、本発明によるオブジェクトおよびカスタム・オブジェクトの概念的な記述を簡略化するために使用される。本明細書では「テーブル」および「オブジェクト」を相互交換可能に使用できることを理解されたい。各テーブルは一般に、表示可能なスキーマにおいて列またはフィールドとして論理的に構成された1つまたは複数のデータ範疇を含んでいる。テーブルの各行またはレコードは、フィールドによって定義される各範疇のデータのインスタンスを含んでいる。たとえば、CRMデータベースは、名前、住所、電話番号、ファックス番号のような基本的な連絡先情報用のフィールドで顧客を記述するテーブルを含んでよい。他のテーブルは、顧客、製品、販売価格、日付などの情報用のフィールドを含む購買注文を記述することができる。いくつかのマルチテナント・データベース・システムでは、標準エンティティ・テーブルを設けることができる。CRMデータベース・アプリケーションでは、このような標準エンティティには、各テーブルが定義済みのフィールドを含む得意先データ、連絡先データ、リード・データ、および「好機」などのデータのテーブルを含んでよい。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００２９
【補正方法】変更
【補正の内容】
【００２９】
図3は、メイン・テーブル200および関連するカスタム・フィールド・テーブル210として表されるオブジェクトの例を示している。図3に示されている特定の例では、メイン・テーブル200（「.」.得意先」）は、標準得意先エンティティを表しており、カスタム・フィールド・テーブル210（「.」.得意先_cfデータ」）は、メイン・テーブル200を使用して様々な組織（テナント）によって定義されるカスタム・フィールドを含んでいる。図示のように、メイン・テーブル200は、組織ID（「org id」）列201、およびテーブル200用のプライマリ・キーとして働くテーブルID（たとえば、得意先名を表す「得意先id」（２０２）を含んでいる。データ・テーブル200は、複数のデータ列203も含んでいる。図3の特定の例では、テーブルは標準エンティティを表し、データ列203は、テーブルを使用することのできる様々な組織に供給される定義済みデータ列または標準フィールドである。標準得意先エンティティの例では、このような標準フィールドは、名前列、サイト列、従業員数列、および得意先関連情報を記憶するうえで有用な他のフィールドを含んでよい。各データ列203は好ましくは、1列当たりに単一のデータ・タイプを記憶するように定義される。組織id列201は、マルチテナント得意先テーブル200を使用して組織同士を区別するために設けられている。図示のように、N個の異なる組織が、テーブル200に記憶されたデータを有している。列201の組織idは好ましくはChar(15)であるが、他のデータ・タイプを含んでよい。一態様では、組織idの最初の3文字は、「00d」のような定義済みのプレフィックスに設定される。ただし、必要に応じて組織id内の文字の他の部分集合を使用してこのようなプレフィックスを保持することができる。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００３１
【補正方法】変更
【補正の内容】
【００３１】
組織が最初に作成されて、データベース・テーブル200に関連付けられるときには、カスタム・フィールド列213はその組織については空である。しかし、メイン・テーブル（たとえば、「.」.得意先」）にレコード、すなわち、行が作成されるたびに、カスタム・フィールド・テーブルに対応する行が作成されていく。すべてのカスタム・フィールド列はヌルであり、したがって使用されるまで空間を占有することはない。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００３３
【補正方法】変更
【補正の内容】
【００３３】
図6aは、本発明の一例によるカスタム・フィールド定義のメタデータ(metadata)・テーブル500（「カスタム_フィールド_定義」）の一例を示している。カスタム_フィールド_定義のメタデータ・テーブル500は、各組織およびテーブル（たとえば、以下に詳しく説明する標準テーブルやカスタム・テーブル）について定義された各カスタム・フィールド列の名前、データ・タイプ、およびその他の情報を記録するのに使用される。図示のように、メタデータ・テーブル500は、カスタム_フィールド_定義_id（”custom_field_definition_id”）列510、組織_id(“organization_id”)列520、テーブル名(“table name”)またはテーブルid(”table id”)列530、フィールド名(“field name”)列540、フィールド・データタイプ(“filed data type”)列550、「is_インデックス付き」列560、および列_番号列570を含んでいる。組織_id列520は、カスタム・フィールドが作成される組織の「組織id」を記憶しおり、カスタム_フィールド_定義_id列５１０はテーブル500用のプライマリ・キーとして働く。テーブル名列530は、得意先のような標準エンティティ・テーブルの名前、または組織に関して作成されたカスタム・エンティティ・テーブルのidを記憶する。フィールド名列540は、カスタム・フィールドのテキスト名を記憶し、フィールド・データタイプ列550は、カスタム・フィールドのデータ・タイプを記憶する。データ・タイプの例にはテキスト、番号、日付、ピックリストなどが含まれる。ピックリスト・データ・タイプは、値の列挙リストから値が選択されるテキスト・フィールドである。ピックリストは通常、UIにおけるドロップダウンとして表示される。「is_インデックス付き」_列560は、このフィールドについて、以下に詳しく説明するインデックス付けされているか否かを示すフラグが立っているかどうかを示す値を記憶する。一態様では、列560は、ブール値を記憶する。列_番号列570は、カスタム・フィールド・テーブル210（図3）内のカスタム・フィールドに割り当てられた列番号（たとえば、"val0"）を記憶する。
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】００３５
【補正方法】変更
【補正の内容】
【００３５】
一態様では、基本的な物理ストレージは文字ベースであるにもかかわらず、これらのカスタム・フィールドには様々な仮想データ・タイプが許容される。組織のシステム管理者が、たとえば数値または日付カスタム・フィールド・タイプを定義すると、これらの値は、論理データ・タイプへの容易な再変換を可能にするフォーマットのテキストとして記憶される。前述のように、一態様では、好ましくはVARCHARというデータ・タイプが使用される。たとえば、この態様では、日付は、TO_DATE（＜列＞、'YYYYMMDD'）関数を介した変換を可能にすると共に変換を行わずに適切な記憶を可能にするYYYYMMDDフォーマットで記憶される。番号については、通常の10進フォーマットが使用され、オラクル関数「TO_NUMBER()」を使用して、ソート、演算、フィルタリングなどに関する数値に変換することができる。
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】００６４
【補正方法】変更
【補正の内容】
【００６４】
履歴追跡
セールスフォースドットコムにおける標準エンティティ（事例エンティティや「好機」エンティティなど）は、レコードに対するデータ変更の自動監査をサポートする。この監査は通常、すべてのデータがデータベースに書き込まれるアプリケーション・サーバにおいて低レベルで行われる。この同じコード・パスが好ましくはカスタム・エンティティに使用される。
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】００７５
【補正方法】変更
【補正の内容】
【００７５】
エンティティ・タイプ毎に複数のビジネス・プロセス
標準のエンティティは、複数の「レコード・タイプ」または複数のビジネス・プロセスの定義を可能にする。たとえば、「好機」エンティティは電話販売の「好機」と直接販売の「好機」の両方を有することができる。これらの「好機」の個々の行のレコード・タイプに応じて、「ピックリスト」（picklist）・フィールドに利用可能な値は、当該組織の管理者による構成に応じて変化する。
【手続補正１０】
【補正対象書類名】明細書
【補正対象項目名】００７７
【補正方法】変更
【補正の内容】
【００７７】
ワークフロー
一態様では、本発明は、特定のエンティティ・タイプのトリガ条件および処置の定義を可能にする。たとえば、「好機」の度合量が特定の値を超えた場合（トリガ条件）、eメールなどの通知が、前もって指定されていた個人またはグループへ、たとえば、その組織の販売のVPに送信される（処置）。