パブリッシャ及び情報フィードを介してレコードとインタラクトするためのシステム及び方法

著者らは特許

G06F17/30 - 情報検索;そのためのデータベース構造

の所有者の特許 JP2016517596:

セールスフォース ドット コム インコーポレイティッド

 

単一のユーザインタフェースを介して1以上のレコードとインタラクトするための方法、装置、システム、及びコンピュータ読み取り可能記憶媒体が開示される。ユーザインタフェースは、パブリッシャ及び情報フィードを含む。ユーザは、パブリッシャから、第1のレコードとインタラクトすることをリクエストすることができる。第1のレコードとインタラクトしてレコードをアップデートするために、情報が、パブリッシャを通じて送信され得る。フィード項目が、アップデートに基づく情報フィードに含まれるように提示され得る。フィード項目は、第1のレコードへの参照を提供する1以上の実行可能なセレクションを含む。ユーザが、実行可能なセレクションのうちの1つを選択すると、ユーザは、第1のレコードとのさらなるインタラクションを実行することができる、あるいは、第2のレコードとの新たなインタラクションを実行することができる。

 

 

本特許文書は、一般に、データベースシステムを用いて、オンラインソーシャルネットワークにおいてオンデマンドサービスを提供することに関し、より詳細には、オンラインソーシャルネットワークにおいて、パブリッシャからレコード及びアプリケーションとインタラクトするための技術に関する。
(優先権及び関連出願データ)
本出願は、Beechukらによる「MULTI-DIMENSIONAL PUBLISHER」と題された2013年3月15日出願の同時係属中の同一出願人による米国特許仮出願第61/852089号と、Beechukらによる「SYSTEMS AND METHODS FOR INTERACTING WITH RECORDS VIA A PUBLISHER AND AN INFORMATION FEED」と題された2013年7月16日出願の同時係属中の同一出願人による米国特許出願第13/943657号と、Beechukらによる「SYSTEMS AND METHODS FOR CROSS-REFERENCING FEED ITEMS」と題された2013年7月16日出願の同時係属中の同一出願人による米国特許出願第13/943629号と、Beechukらによる「SYSTEMS AND METHODS FOR CREATING CUSTOM ACTIONS」と題された2013年7月16日出願の同時係属中の同一出願人による米国特許出願第13/943636号と、Beechukらによる「SYSTEMS AND METHODS FOR INTERACTING WITH AN APPLICATION IN A PUBLISHER」と題された2013年7月16日出願の同時係属中の同一出願人による米国特許出願第13/943640号と、Horenらによる「SYSTEMS AND METHODS FOR CROSS-REFERENCING FEED ITEMS」と題された2013年12月20日出願の同時係属中の同一出願人による米国特許出願第14/137202号と、Beechukらによる「SYSTEMS AND METHODS FOR INTERACTING WITH RECORDS VIA A PUBLISHER AND AN INFORMATION FEED」と題された2013年12月13日出願の同時係属中の同一出願人による米国特許仮出願第61/915649号と、の優先権を主張し、それらの全てが、それらの全体を参照することにより、全ての目的のために、本明細書に組み込まれる。
(著作権表示)
本特許文書の開示の一部は、著作権保護の対象となる内容を含む。著作権者は、特許文書又は特許開示が特許商標庁の特許ファイル又は記録に現れるものについては、何人によるこれらの複製に対して異議を持たないが、それ以外はどのようなものであっても全ての著作権を保有する。
「クラウドコンピューティング」サービスは、リクエストされると、共有リソース、ソフトウェア、及び情報を、コンピュータ及び他のデバイスに提供する。クラウドコンピューティング環境において、ソフトウェアは、インハウスコンピュータシステム上にローカルにインストールされる代わりに、インターネットを介してアクセス可能であり得る。クラウドコンピューティングは、通常、動的に拡張可能でしばしば仮想化されているリソースのインターネットを介した提供を伴う。ユーザから技術的な詳細を取り除くことができ、ユーザは、ユーザをサポートする「クラウド内の」技術インフラストラクチャの専門知識をもはや有する必要性がない、あるいは、そのような技術インフラストラクチャをもはや制御する必要性がない。
データベースリソースが、クラウドコンピューティングコンテキストにおいて提供され得る。しかしながら、従来のデータベース管理技術を用いると、クラウド又は他のネットワークにおけるデータベースシステムの他のユーザの行動について知ることは難しい。例えば、データベースリソース上の販売員等の特定のユーザのアクションは、そのユーザの上司にとって重要であり得る。ユーザは、ユーザが行ったことについてレポートを作成し、そのレポートを上司に送ることができるが、そのようなレポートは、役に立たないものであり、タイムリーでなく、不完全であり得る。また、レポート内の情報から恩恵を受ける可能性がある他のユーザを識別するのは難しいことであり得る。
添付の図面は、例示の目的のためにあり、オンラインソーシャルネットワークにおいて単一のユーザインタフェース内で1以上のレコードとインタラクトするための、開示される独創的なシステム、装置、及び方法のための可能な構造及びオペレーションの例を提供するに過ぎない。これらの図面は、開示される実施例の主旨及び範囲から逸脱することなく当業者によりなされ得る、形態及び詳細のいかなる変更も制限しない。
いくつかの実施例に従ってオンデマンドデータベースサービスが使用され得る環境10の一例のブロック図。 図1Aの要素とそれら要素間の種々の可能な相互接続とのいくつかの実装の例のブロック図。 いくつかの実施例に従ったオンデマンドデータベースサービス環境200のアーキテクチャコンポーネントの例を示すシステム図。 いくつかの実施例に従ったオンデマンドデータベースサービス環境のアーキテクチャコンポーネントの例をさらに示すシステム図。 いくつかの実施例に従って実行される、データベースシステムに記憶されたレコードに対するアップデートを追跡するための方法300の一例のフローチャート。 いくつかの実施例に従ってレコードに対するアップデートを追跡するための方法を実行するデータベースシステム構成400のコンポーネントの例のブロック図。 いくつかの実施例に従って実行される、データベースシステムのユーザのアクションを追跡するための方法500の一例のフローチャート。 いくつかの実施例に従って実行される、レコード又は別のユーザについてユーザにより作成されたメッセージからニュースフィードを作成するための方法600の一例のフローチャート。 いくつかの実施例に従ったグループページ上のグループフィードの一例を示す図。 いくつかの実施例に従った、フィード追跡アップデート、ポスト、及びコメントを含むレコードフィードの一例を示す図。 いくつかの実施例に従ってイベントを追跡しフィードを作成する際に使用され得る複数のテーブルの例を示す図。 いくつかの実施例に従って実行される、ユーザをデータベースシステムにおけるオブジェクトに自動的にサブスクライブさせるための方法900の一例のフローチャート。 いくつかの実施例に従って実行される、情報をフィード追跡テーブルに記録するための方法1000の一例のフローチャート。 いくつかの実施例に従って実行される、表示されるフィードを生成することの一部としてフィード項目を読み出すための方法1100の一例のフローチャート。 いくつかの実施例に従って実行される、表示されるプロフィールフィードのフィード項目を読み出すための方法1200の一例のフローチャート。 いくつかの実施例に従って実行される、フィード内に表示するためのフィード項目を効率的に生成するためにイベント情報を記憶する方法1300の一例のフローチャート。 いくつかの実施例に従って実行される、フィルタリング基準を用いて、データベースシステムのユーザのためのカスタムフィードを作成するための方法1400の一例のフローチャート。 いくつかの実施例に従って実行される、オンラインソーシャルネットワークにおいて単一のユーザインタフェースから1以上のレコードとインタラクトするための、コンピュータにより実施される方法1500の一例のフローチャート。 いくつかの実施例に従って実行される、オンラインソーシャルネットワークにおいて単一のユーザインタフェースから1以上のレコードとインタラクトするための、コンピュータにより実施される方法1600aの一例のフローチャート。 いくつかの実施例に従って実行される、オンラインソーシャルネットワークにおいて1以上のフォロワによりアクセスされる相互参照されているフィード項目を公開するための、コンピュータにより実施される方法1600bの一例のフローチャート。 いくつかの実施例に従って実行される、情報をオンラインソーシャルネットワークの情報フィードに公開するよう構成されたパブリッシャから1以上のデータオブジェクトとインタラクトするための、コンピュータにより実施される方法1700の一例のフローチャート。 いくつかの実施例に従って実行される、オンラインソーシャルネットワークにおいてパブリッシャを用いてアプリケーションとインタラクトするための、コンピュータにより実施される方法1800の一例のフローチャート。 いくつかの実施例に従った、パブリッシャ及び情報フィードを含むユーザインタフェースを伴うレコードの一例を示す図。 いくつかの実施例に従ったパブリッシャの一例を示す図。 いくつかの実施例に従った、モバイルデバイスアプリケーション用のパブリッシャ及び情報フィードを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、モバイルデバイスアプリケーション用のパブリッシャ及び情報フィードを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、モバイルデバイスアプリケーション用のパブリッシャ及び情報フィードを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、モバイルデバイスアプリケーション用のパブリッシャ及び情報フィードを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従ったフィード項目の一例を示す図。 いくつかの実施例に従った、モバイルデバイスアプリケーション用の、パブリッシャと、情報フィード内のフィード項目と、を含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、モバイルデバイスアプリケーション用の、パブリッシャと、情報フィード内のフィード項目と、を含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、パブリッシャ及び情報フィードを含むユーザインタフェースを伴うレコードの一例を示す図。 いくつかの実施例に従った、パブリッシャアクションが選択されたときの、複数の空データフィールドを表示しているユーザインタフェースを伴う、図24におけるレコードの一例を示す図。 いくつかの実施例に従った、ユーザ入力を受け入れたときの、複数の入力済みデータフィールドを表示しているユーザインタフェースを伴う、図25におけるレコードの一例を示す図。 いくつかの実施例に従った、パブリッシャからのアップデートされたデータを提示しているフィード項目と、子レコードへのリンクと、を含む情報フィードを含むユーザインタフェースを伴う、図26におけるレコードの一例を示す図。 いくつかの実施例に従った、パブリッシャ、カスタムアクション、及び情報フィードを含むユーザインタフェースを伴うレコードの一例を示す図。 いくつかの実施例に従った、パブリッシャ、カスタムアクション、及び情報フィードを含むユーザインタフェースを伴う、図28におけるレコードから変換されたレコードの一例を示す図。 いくつかの実施例に従った、パブリッシャ、カスタムアクション、及び情報フィードを含むユーザインタフェースを伴う、図29における変換されたレコードの子レコードの一例を示す図。 いくつかの実施例に従った、親レコードの情報フィード内にフィード項目を表示しているユーザインタフェースを伴うレコードの一例を示す図。 いくつかの実施例に従った、取引先ページの情報フィードを表示しているユーザインタフェースを伴うレコードの一例を示す図。 いくつかの実施例に従った、図32Aの取引先ページのレコード詳細を表示しているユーザインタフェースを伴うレコードの一例を示す図。 いくつかの実施例に従った、図32Aの取引先ページのレコード関連情報を表示しているユーザインタフェースを伴うレコードの一例を示す図。 いくつかの実施例に従った、パブリッシャからのアップデートされたデータを提示しているフィード項目を含むレコードフィードを伴う連絡先レコードの一例を示す図。 いくつかの実施例に従った、図33Aのフィード項目から相互参照されているフィード項目と連絡先レコードへのリンクとを含むニュースフィードを伴うユーザプロフィールの一例を示す図。 いくつかの実施例に従った、図33Aのフィード項目から相互参照されているフィード項目と連絡先レコードへのリンクとを含むニュースフィードを伴う別のユーザプロフィールの一例を示す図。 いくつかの実施例に従った、ユーザがカスタムアクションを作成するよう構成されたデータベースサービスのユーザインタフェースの一例を示す図。 いくつかの実施例に従った、ユーザがパブリッシャからカスタムアクションを作成するよう構成されたパブリッシャを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、カスタムアクションを作成するためのカスタムアクション定義領域を含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、カスタムアクションに関連付けられたデータフィールドを表示しているアクションレイアウトエディタ用のユーザインタフェースの一例を示す図。 いくつかの実施例に従った、カスタムアクションに関連付けられたさらなるデータフィールドを表示している、図37Aのアクションレイアウトエディタ用のユーザインタフェースの一例を示す図。 いくつかの実施例に従った、カスタムアクションに関連付けられたデータフィールドの表示をプレビューしているウィンドウの一例を示す図。 他の実施例に従った、カスタムアクションに関連付けられたデータフィールドの表示をプレビューしているウィンドウの一例を示す図。 いくつかの実施例に従った、レコードに関連付けられたパブリッシャアクションを表示しているページレイアウトエディタ用のユーザインタフェースの一例を示す図。 いくつかの実施例に従った、詳細、ページレイアウト、及び、カスタムアクションに関連付けられた予め定められたフィールド値を表示しているユーザインタフェースの一例を示す図。 いくつかの実施例に従った、カスタムアクションに関連付けられた予め定められたフィールド値を編集又は追加するためのユーザインタフェースの一例を示す図。 いくつかの実施例に従った、ユーザがグローバルアクションを作成するよう構成されたデータベースサービスのユーザインタフェースの一例を示す図。 いくつかの実施例に従った、グローバルアクションを作成するための複数のパラメータを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、オンデマンドデータベースサービス環境に関連付けられたパブリッシャアクションを表示しているページレイアウトエディタ用のユーザインタフェースの一例を示す図。 いくつかの実施例に従った、パブリッシャ内に表示されるパブリッシャアクションを選択するためのウィンドウの一例を示す図。 いくつかの実施例に従った、モバイルデバイスアプリケーション用の、カスタムアクションを伴うパブリッシャと情報フィードとを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、モバイルデバイスアプリケーション用の、カスタムアクションを伴うパブリッシャと情報フィードとを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、オンデマンドデータベースサービス環境のためのデータベースシステム内を検索するためのルックアップツールの一例を示す図。 いくつかの実施例に従った、オンデマンドデータベースサービス環境のためのデータベースシステム内を検索するためのルックアップツールの一例を示す図。 いくつかの実施例に従った、オンデマンドデータベースサービス環境のためのデータベースシステム内を検索するための検索クエリツールの一例を示す図。 いくつかの実施例に従った、オンデマンドデータベースサービス環境のためのデータベースシステム内を検索するための検索クエリツールの一例を示す図。 いくつかの実施例に従った、パブリッシャアクション用の複数のデータフィールドを表示しているパブリッシャを含むユーザインタフェースと、1以上のデータフィールドに関連付けられた妥当性検証ルールと、の一例を示す図。 いくつかの実施例に従った、バグのログを取るためのパブリッシャの一例を示す図。 いくつかの実施例に従った、図50Aにおいて提供されたパブリッシャデータから作成された対応するフィード項目の一例を示す図。 いくつかの実施例に従った、経費報告書をファイルするためのパブリッシャの一例を示す図。 いくつかの実施例に従った、図51Aにおいて提供されたパブリッシャデータからのフィード項目の一例を示す図。 いくつかの実施例に従った、図51Aにおける経費報告書のステータスをアップデートするための承認コントロールを含む別のフィード項目の一例を示す図。 Visualforceページとともにカスタムアクションを作成するためのカスタムアクション定義領域を含むユーザインタフェースの一例を示す図。 カスタマイズされたVisualforceページレイアウトを伴うレコードの一例を示す図。 カスタマイズされたVisualforceアクションレイアウトを伴うパブリッシャの一例を示す図。 いくつかの実施例に従った、オンデマンドサービス環境においてネイティブにホストされているカスタムアクション用のデータフィールドを公開しているパブリッシャを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、オンデマンドサービス環境の外部でホストされているウェブページからのコンテンツを公開しているパブリッシャを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、サードパーティプラットフォーム上でホストされているアプリケーションからのコンテンツを公開しているパブリッシャを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、図56Aにおけるサードパーティプラットフォーム上でホストされているアプリケーションからのコンテンツに関するユーザ入力に基づいてデータを表示しているフィード項目を含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、図56Aにおけるサードパーティプラットフォーム上でホストされているアプリケーションからのコンテンツに関するユーザ入力に基づいて承認コントロールを表示しているフィード項目を含むユーザインタフェースの一例を示す図。
開示される実施例に従ったシステム、装置、及び方法の例が、このセクションで説明される。これらの例は、開示される実施例の理解におけるコンテキスト及び助けを加えるためだけに提供されている。したがって、実施例は、そのような具体的な詳細の一部又は全てがなくても実施できることが当業者には明白であろう。他の例において、所定のプロセス/方法オペレーション(本明細書において「ブロック」とも呼ばれる)は、実施例を不必要に曖昧にするのを避けるために詳細に説明されていない。他の応用も可能であるので、以下の例は、範囲又は環境において限定的又は制限的であると解釈されるべきでない。
以下の詳細な説明において、説明の一部を形成し、例として特定の実施例が示されている添付の図面が参照される。これらの実施例は、当業者が開示される実施例を実施できるよう十分詳細に説明されるが、これらの例は限定的なものでなく、したがって、主旨及び範囲から逸脱することがなければ、他の実施例が使用されてもよいし、変更がなされてもよいことを理解されたい。例えば、図示され本明細書で説明される方法のブロックは、必ずしも示される順番で実行される必要はない。方法は、示されるブロックよりも多くのブロック又は少ないブロックを含んでもよいことも理解すべきである。いくつかの実施例において、別々のブロックとして本明細書で説明されるブロックは、組み合わされてもよい。反対に、単一のブロックとして本明細書で説明され得るブロックは、複数のブロックで実施されてもよい。
本明細書で説明又は参照される様々な実施例は、本明細書においてソーシャルネットワーキングシステムとも呼ばれるオンラインソーシャルネットワークにおいて単一のユーザインタフェース内で1以上のレコードとインタラクトするための様々な方法、装置、システム、及びコンピュータ読み取り可能記憶媒体を対象とする。オンラインソーシャルネットワークの一例は、カリフォルニア州サンフランシスコのsalesforce.com, inc.により提供されるChatter(登録商標)である。オンラインソーシャルネットワークは、人々及び人々のグループの間のコミュニケーションを円滑にする一般的な方法にますますなりつつあり、それらの人々の何人も、ソーシャルネットワーキングシステムのユーザとして認識され得る。いくつかのオンラインソーシャルネットワークは、例えば、会社又はビジネスパートナ等の企業といった組織、学術機関、又はそのような組織内のグループを含む様々な環境において実施され得る。例えば、Chatter(登録商標)は、様々な目的で、データを共有し、互いとコミュニケーションし、互いと協働するために、ビジネス組織の部門内の従業員ユーザにより使用され得る。
いくつかのオンラインソーシャルネットワークにおいて、ユーザは、1以上の情報フィードにアクセスすることができ、情報フィードは、その情報フィード内の項目又はエントリとして提示される情報アップデートを含む。そのようなフィード項目は、単一の情報アップデート又は個々の情報アップデートの集合を含み得る。フィード項目は、文字ベースのデータ、オーディオデータ、画像データ、及び/又はビデオデータを含む様々なタイプのデータを含み得る。情報フィードは、以下で説明されるように、コンピューティングデバイスのディスプレイ等のディスプレイデバイス上のグラフィカルユーザインタフェース(GUI)内に表示され得る。情報アップデートは、様々なソースからの様々なソーシャルネットワークデータを含み得、オンデマンドデータベースサービス環境に記憶され得る。いくつかの実施例において、開示される方法、装置、システム、及びコンピュータ読み取り可能記憶媒体は、マルチテナントデータベース環境における使用のために構成又は設計され得る。
いくつかの実施例において、オンラインソーシャルネットワークは、ユーザが、個々のユーザ及びユーザのグループをフォローすることに加えて、案件(case)、取引先(account)、又は商談(opportunity)等のレコードの形態のデータオブジェクトをフォローすることを可能にし得る。以下でより詳細に説明されるように、データベースに記憶されたレコードを「フォローする」ことにより、ユーザは、そのレコードの進捗を追跡することが可能になる。本明細書においてレコードに対する変更とも呼ばれるレコードに対するアップデートは、そのレコードにサブスクライブされているユーザのニュースフィード又はレコードフィード等の情報フィードに対して生じ得るものであり、且つそのような情報フィード上に記され得る1つのタイプの情報アップデートである。レコードアップデートの例は、レコードにおけるフィールド変更、レコードのステータスに対するアップデートに加えて、レコード自体の作成も含む。一部のレコードは、パブリックに(publicly)アクセス可能であるので、いかなるユーザもそのレコードをフォローできるのに対し、他のレコードは、プライベートであり(private)、適切なセキュリティクリアランス/パーミッションが、そのレコードをフォローするユーザへの必須条件である。
情報アップデートは、特定のレコードにリンクされていてもリンクされていなくてもよい様々なタイプのアップデートを含み得る。例えば、情報アップデートは、ユーザ送信メッセージであってもよいし、ユーザアクション又はイベントに応じて、別の形で生成されてもよい。メッセージの例は、ポスト、コメント、「いいね(like)」及び「良くないね(dislike)」等のユーザの個人的好みのインジケーション、ユーザのステータスに対するアップデート、アップロードファイル、及び、インターネット上の様々なウェブページ及び/又は文書等のソーシャルネットワークデータ又は他のネットワークデータへのハイパーリンクを含む。ポストは、単語、語句、文、質問、感情表現、及び/又は記号等の英数字のユーザ入力又は他の文字ベースのユーザ入力を含み得る。コメントは、一般に、単語、語句、文、回答、質問、及び応答的な感情表現、並びに/又は記号等の、ポストに対する応答を指す。マルチメディアデータは、ポスト又はコメントに含まれ得る、ポスト又はコメントにリンクされ得る、あるいは、ポスト又はコメントに添付され得る。例えば、ポストは、JPEG画像又はアニメーション画像と組み合わせたテキスト文を含み得る。いいね又は良くないねは、特定のポスト又はコメントに応じて送信され得る。アップロードファイルの例は、プレゼンテーション、文書、マルチメディアファイル、及び同様のものを含む。
ユーザは、上述したように、レコードにサブスクライブすることにより、そのレコードをフォローすることができる。ユーザはまた、他のタイプのデータオブジェクト、他のユーザ、及びユーザのグループ等の他のエンティティをフォローすることもできる。そのようなエンティティに関するフィード追跡アップデート(feed tracked update)は、受信されユーザのニュースフィードに含まれ得る1つのタイプの情報アップデートである。任意の数のユーザが、特定のエンティティをフォローでき、したがって、ユーザのそれぞれのニュースフィード上で、そのエンティティに関連する情報アップデートを閲覧することができる。いくつかのソーシャルネットワークにおいて、ユーザは、互いとのコネクションを確立することにより、互いをフォローすることができ、これは、時として「友達になる(friending)」と呼ばれる。そのようなコネクションを確立することにより、ユーザは、別のユーザにより生成された情報、別のユーザについて生成された情報、又は別のユーザに他の形で関連付けられた情報を見ることができ得る。例えば、第1のユーザは、第2のユーザにより第2のユーザのパーソナルソーシャルネットワークページにポストされた情報を見ることができ得る。そのようなパーソナルソーシャルネットワークページの一実装は、例えば、ユーザのプロフィールを表すウェブページの形態のユーザのプロフィールページである。一例において、第1のユーザが第2のユーザをフォローしている場合、第1のユーザのニュースフィードは、第2のユーザのプロフィールフィードに送信された、第2のユーザからのポストを受け取ることができ、これは、本明細書において、ユーザの「ウォール」とも呼ばれ、ユーザのプロフィールページ上に表示される情報フィードの一例である。
いくつかの実施例において、情報フィードは、オンラインソーシャルネットワークのユーザのグループに固有であり得る。例えば、ユーザのグループは、ニュースフィードを公開することができる。グループのメンバは、フィード及びグループのためのパーミッション構成に従って、このグループフィードを閲覧することができるとともに、このグループフィードにポストすることができる。グループコンテキストにおける情報アップデートはまた、グループステータス情報に対する変更も含み得る。
いくつかの実施例において、1人以上のユーザから入力されたポスト又はコメント等のデータが、オンラインソーシャルネットワーク内の特定のユーザ、グループ、オブジェクト、又は他の構成(construct)のための情報フィードに送信されたとき、ユーザのプロフィールフィード、ニュースフィード、又はレコードフィード等の1以上のフィード内のフィード項目としてのそのデータに含まれるもの(inclusion)に加えて、電子メール通知又は他のタイプのネットワーク通知が、ユーザ、グループ、又はオブジェクトをフォローしている全てのユーザに送信され得る。いくつかのオンラインソーシャルネットワークにおいて、そのような通知の発生は、より大きな会話(larger conversation)の一部を形成し得る、公開された入力の最初のインスタンス(instance)に限定される。例えば、通知は、最初のポストに関しては送信され得るが、そのポストに対するコメントに関しては送信されない。いくつかの他の実施例においては、そのような情報アップデートごとに、別々の通知が送信される。
開示されるシステム、装置、方法、及びコンピュータ読み取り可能記憶媒体のいくつかの実施例は、オンラインソーシャルネットワークにおいて単一のユーザインタフェースを介してレコード又はアプリケーションとインタラクトするよう構成される。単一のユーザインタフェースは、パブリッシャ及び情報フィードを含む統合ユーザインタフェースを提供する。パブリッシャは、レコード又はアプリケーションとインタラクトするよう構成された1以上のパブリッシャアクションを含み得る。いくつかの実施例において、レコードは、リード(lead)、案件、取引先、商談、タスク、連絡先(contact)、キャンペーン(campaign)、契約、イベント、カスタムオブジェクト、及びVisualforceページ等の顧客関係管理(CRM)オブジェクトであり得る。いくつかの実施例において、アプリケーションは、サードパーティプラットフォーム上でホストされるアプリケーションであり得る。
パブリッシャアクションのいくつかは、データオブジェクト又はアプリケーションとインタラクトするよう構成されたカスタムアクションであり得る。カスタムアクションは、カスタムアクション命令に従って、宣言的に(declaratively)、あるいはプログラム的に(programmatically)、定義され得る。カスタムアクション命令は、データオブジェクトと、データオブジェクトに対して実行されるインタラクションと、を定義し得る。カスタムアクション命令はまた、データオブジェクトに関連付けられたデータフィールド、1以上のデータフィールドに関連付けられた妥当性検証ルール、パブリッシャ内のカスタムアクションのページレイアウト、及びパブリッシャ内の1以上のデータフィールドのアクションレイアウトを含む、カスタムアクションの属性(attribute)も定義し得る。いくつかの例において、カスタムアクション命令は、Visualforce等のカスタマイゼーションツールを用いて定義され得る。これにより、ユーザ又は組織は、ビジネスニーズを満たすようにカスタマイズされたユーザインタフェースを作成することが可能になる。
パブリッシャは、情報を情報フィードに公開するよう構成される。いくつかの例において、レコード又はアプリケーションとのインタラクションが実行されると、フィード項目が作成される。そのようなフィード項目は、1以上の実行可能なセレクション(選択手段)(actionable selection)を含み得る。1以上の実行可能なセレクションは、レコード又はアプリケーションへの参照を提供し得る。そのような実行可能なセレクションのうちの1つが選択されると、パブリッシャに、さらなる情報を受け取るよう、且つ/あるいは、さらなるオペレーションをレコード又はアプリケーションに対して実行するよう動作させ得る。フィード項目内にそのような実行可能なセレクションを有することにより、ユーザは、異なるユーザインタフェース間を移動して切り替える必要なく、レコード又はアプリケーションに対してアクションを効率的に実行することが可能になる。例えば、ユーザは、共通ユーザインタフェースを離れることなく、複数のレコードとインタラクトすることができる。これは、パブリッシャ及び情報フィードを通じてCRMライフサイクル及び非CRMライフサイクルを効率的に進めるのに有用であり得る。
フィード項目は、操作されている子レコードの親レコード等の情報フィードに含まれるように提示され得る。しかしながら、フィード項目は、親レコードのレコードフィード内での表示のためだけでなく、他の関連フィード内での表示のために、伝播され(propagated)相互参照され得る。そのような関連フィードの識別は、例えば、ユーザがペイロード内に値を定義することにより、あるいはシステム管理者がそのような値をハードコードすることにより生じ得る。相互参照されているフィード項目に対して実行される任意のインタラクションもまた、単一の会話スレッドが保たれるように、全ての他の相互参照されているフィード項目上に提示される。これにより、ユーザ又は組織は、複数のページレイアウトから同じフィード項目を閲覧するとともに、複数のページレイアウトから同じフィード項目とインタラクトすることが可能になり得る。
パブリッシャは、データオブジェクトとインタラクトできるだけでなく、アプリケーションともインタラクトするよう構成され得る。そのようなアプリケーションは、オンデマンドサービス環境においてネイティブにホストされていてもよいし、サードパーティプラットフォーム上でホストされていてもよい。カスタムアクションは、APIを介してアプリケーションとインタラクトするよう定義され得る。アプリケーションがネイティブにホストされているかサードパーティプラットフォーム上でホストされているかにかかわらず、APIは、アプリケーションをオンデマンドサービス環境に統合することを可能にし得る。アプリケーションとのインタラクションは、情報フィードに対してアップデートされ得る。そのようなアップデートは、ユーザインタフェースをリフレッシュすることなく生じ得る。
より多くのユーザ及び組織が、コミュニケーションを取りながらビジネスを行うために、より協働的な共有モデルに向かっているので、より良く情報を公開、強化、及び利用する要望が存在する。従来、オンラインソーシャルネットワークにおいて、情報にアクセスし情報とインタラクトすることは、複数の異なるアプリケーション及びインタフェース間を移動して切り替えることを伴い得る。これは、面倒であり、時間を消費するものであり、非生産的であり得る。
上述したように、本明細書で説明される実施例のいくつかは、オンラインソーシャルネットワークにおいて、ユーザがデータオブジェクト又はアプリケーションとインタラクトすることを可能にする統合ユーザインタフェースを提供する機構を対象とする。そのようなインタラクションは、例えば、データオブジェクトを作成するリクエスト、データオブジェクトを削除するリクエスト、データオブジェクトをアップデートするリクエスト、データオブジェクトを変換するリクエスト、データオブジェクトからデータをダウンロードするリクエスト、データオブジェクトにデータをアップロードするリクエスト、データオブジェクトにファイルを添付するリクエスト、データオブジェクトに関連付けられた情報を閲覧するリクエスト、及びデータオブジェクトを参照するオペレーションを他の形で実行するリクエストを含み得る。統合ユーザインタフェースは、カスタムアクションを伴うパブリッシャ及び情報フィードを含み得る。ここで、カスタムアクションは、データオブジェクト又はアプリケーションに対して上述のインタラクションのうちの1つを実行するよう構成される。そのようなインタラクションは、APIを介して生じ、フィード項目の形で情報フィードに公開され得る。フィード項目は、単一の会話スレッドを提供するために、他の関連フィードにおいて相互参照され得、フィード項目は、データオブジェクトに対してさらなるオペレーションを実行するための実行可能なセレクションを有し得る。したがって、パブリッシャ及びフィード項目は、異なるアプリケーション及びインタフェース間を切り替える必要なく関連情報とインタラクトし関連情報を閲覧するためのメインインタフェースになる。
これらの実施例及び他の実施例は、様々なタイプのハードウェア、ソフトウェア、ファームウェア、及びこれらの組合せにより具現化され得る。例えば、本明細書で開示されるいくつかの技術は、本明細書で説明される様々なサービス及びオペレーションを実行するためのプログラム命令、状態情報等を含むコンピュータ読み取り可能媒体により、少なくとも部分的に実施され得る。プログラム命令の例は、コンパイラにより生成されるもの等のマシンコードと、インタプリタを用いるサーバ又は他のデータ処理装置等のコンピューティングデバイスにより実行され得る、より高水準のコードを含むファイルと、の両方を含む。コンピュータ読み取り可能媒体の例は、ハードディスク、フロッピディスク、及び磁気テープ等の磁気媒体、CD−ROMディスク等の光媒体、光磁気媒体、及び、読み取り専用メモリ(「ROM」)デバイス及びランダムアクセスメモリ(「RAM」)デバイス等の、プログラム命令を記憶するよう特別に構成されているハードウェアデバイスを含むが、これらに限定されるものではない。開示される実施例のこれらの特徴及び他の特徴が、関連する図面を参照して以下でより詳細に説明される。
用語「マルチテナントデータベースシステム」は、データベースシステムのハードウェア及びソフトウェアの様々な要素が1人以上の顧客により共用され得るシステムを指し得る。例えば、所与のアプリケーションサーバは、非常に多くの顧客のリクエストを同時に処理することができ、所与のデータベーステーブルは、潜在的に非常に多くの顧客のためのフィード項目等のデータの行を記憶することができる。用語「クエリプラン」は、一般に、データベースシステム内の情報にアクセスするために用いられる1以上のオペレーションを指す。
「ユーザプロフィール」又は「ユーザのプロフィール」は、一般に、データベースシステムの所与のユーザについてのデータを記憶及び保持するよう構成される。そのデータは、名前、肩書、電話番号等の一般情報、写真、略歴(biographical summary)、及びステータス、例えば、ユーザが現在行っていることを説明するテキストを含み得る。以下で述べられるように、そのデータは、他のユーザにより作成されたメッセージを含んでもよい。複数のテナントが存在する場合、ユーザは、通常、特定のテナントに関連付けられる。例えば、ユーザは、データベースサービスを提供するデータベースシステムのテナントである会社の販売員であり得る。
用語「レコード」は、一般に、例えば、特定の(実際の又は潜在的な)ビジネス関係又はプロジェクトについてデータベースサービスのユーザにより作成されたデータオブジェクトのインスタンス等のデータエンティティを指す。データオブジェクトは、データベースサービスにより定義されたデータ構造(標準オブジェクト)又はユーザにより定義されたデータ構造(カスタムオブジェクト)を有し得る。例えば、レコードは、ユーザのビジネスパートナ又は潜在的ビジネスパートナ(例えば、クライアント、ベンダ、ディストリビュータ等)に関するものであり得、会社全体、子会社(subsidiary)、又は会社の連絡先を説明する情報を含み得る。別の例として、レコードは、既存パートナとの商談(例えば、可能な販売)等のユーザが取り組んでいるプロジェクトであってもよいし、ユーザが得ようと試みているプロジェクトであってもよい。マルチテナントデータベースシステムの一実装において、テナントのための各レコードは、共通テーブルに記憶された一意な識別子を有する。レコードは、オブジェクトの構造により定義されるデータフィールドを有する(例えば、所定のデータ型及び目的のフィールド)。レコードはまた、ユーザにより定義されたカスタムフィールドを有してもよい。フィールドは、別のレコードであってもよいし、別のレコードへのリンクを含んでもよい。これにより、レコード間の親子関係を提供することができる。
用語「情報フィード」及び用語「フィード」は、本明細書において同じ意味で用いられ、一般に、フィード項目又はエントリと様々なタイプの情報及びデータとの組合せ(例えば、リスト)を指す。そのようなフィード項目は、表示されるフィードの一部として提示される関連情報を取得するためにアクセスされ得る1以上のデータベーステーブルに、例えば、行として、記憶及び保持され得る。用語「フィード項目」(又は、フィード要素)は、情報の項目を指し、ユーザにより送信されたポスト等、フィード内に提示され得る。例えば、ユーザについての情報のフィード項目は、データベースのユーザのプロフィールフィード内に提示され得るのに対し、レコードについての情報のフィード項目は、データベースにおけるレコードフィード内に提示され得る。プロフィールフィード及びレコードフィードは、様々な情報フィードの例である。第1のユーザ及びレコードをフォローしている第2のユーザは、別のタイプの情報フィードである第2のユーザのニュースフィード内に表示される、第1のユーザ及びレコードに関連付けられたフィード項目を受け取ることができる。いくつかの実施例において、任意の数のフォローされているユーザ及びレコードからのフィード項目は、特定のユーザの単一の情報フィードに結合され得る。
例として、フィード項目は、テキストデータのユーザにより作成されたポスト等のメッセージ、及び、レコードのフィールドに対する変更等のレコード又はプロフィールに対するフィード追跡アップデートであり得る。フィード追跡アップデートは、以下でより詳細に説明される。フィードは、メッセージとフィード追跡アップデートとの組合せであり得る。メッセージは、ユーザにより作成されたテキストを含み、他のデータを含んでもよい。メッセージの例は、ポスト、ユーザステータスアップデート、及びコメントを含む。メッセージは、ユーザのプロフィール又はレコードに対して作成され得る。ポストは、様々なユーザ、潜在的に全てのユーザにより作成され得るが、いくつかの制限が適用され得る。一例として、ポストは、ユーザのプロフィールページのウォールセクション(複数の最近のポストを含み得る)又は複数のポストを含むレコードのセクションに対してなされ得る。ポストは、ユーザのプロフィールフィードの一部として、例えば、ユーザのプロフィールページ上のグラフィカルユーザインタフェース(GUI)内に表示されるとき、時系列で編成され得る。ポストとは対照的に、ユーザステータスアップデートは、ユーザのステータスを変更するものであり、そのユーザ又は管理者によりなされ得る。レコードは、ステータスを有してもよく、そのアップデートは、そのレコードの所有者又はそのレコードに対する適切なライトアクセスパーミッション(write access permission)を有する他のユーザにより提供され得る。所有者は、1人のユーザであってもよいし、複数人のユーザであってもよいし、グループであってもよい。一実施例において、1レコードにつき1つのステータスのみ存在する。
いくつかの実施例において、コメントは、任意のフィード項目について作成され得る。いくつかの実施例において、コメントは、特定のフィード追跡アップデート、ポスト、又はステータスアップデートに明示的に関連付けられたリストとして編成される。いくつかの実施例において、コメントは、フィード項目の(階層上の)最初のレイヤにリストされなくてもよいが、特定の第1のレイヤのフィード項目から分岐した第2のレイヤとしてリストされ得る。
本明細書において「フィードアップデート」とも呼ばれる「フィード追跡アップデート」は、1つのタイプの情報アップデートであり、一般に、イベントを表すデータを指す。フィード追跡アップデートは、1以上のフィードに含まれ得る1以上のフィード項目として提供される、イベントに応じてデータベースシステムにより生成されるテキストを含み得る。一実施例において、このデータはまず記憶され得、次いで、データベースシステムは、その後にこのデータを使用して、イベントを説明するためのテキストを作成することができる。このデータ及び/又はこのテキストの両方が、本明細書で用いられるフィード追跡アップデートであり得る。様々な実施例において、イベントは、レコードのアップデートであってもよいし、且つ/あるいは、ユーザによる特定のアクションによってトリガされてもよい。どのアクションがイベントをトリガするのかは設定可能である。どのイベントがフィード追跡アップデートを作成させるか、及び、どのフィードアップデートがどのユーザに送信されるかも設定可能である。メッセージ及びフィードアップデートは、レコードの子オブジェクト又はフィールドとして記憶され得る。例えば、フィードは、レコードの子オブジェクトとして記憶され得る。
「グループ」は、一般に、ユーザの集合である。いくつかの実施例において、グループは、同じ属性又は類似する属性を有するユーザ群として定義され得る、あるいはメンバシップ(membership)により定義され得る。いくつかの実施例において、本明細書において「グループニュースフィード」とも呼ばれる「グループフィード」は、グループ内の任意のユーザについての1以上のフィード項目を含む。いくつかの実施例において、グループフィードはまた、グループ全体、グループの目的、グループの説明についての情報アップデート及び他のフィード項目、グループレコード、並びに、グループに関連付けられて記憶された他のオブジェクトも含む。ポスト、コメント、いいね等といったグループレコードアップデート及びメッセージを含む情報アップデートのスレッドは、グループ会話を定め得るものであり、時間とともに変化し得る。
「エンティティフィード」又は「レコードフィード」は、一般に、レコードに対する変更についてのフィード追跡アップデートやレコードについてユーザにより作成されたポスト等の、データベース内の特定のレコードについてのフィード項目のフィードを指す。エンティティフィードは、任意のタイプのフィード項目から構成され得る。そのようなフィードは、例えば、レコードのホームページといった、レコードに関連付けられたウェブページ等のページ上に表示され得る。本明細書で使用されるとき、「プロフィールフィード」又は「ユーザのプロフィールフィード」は、特定のユーザについてのフィード項目のフィードである。一例において、プロフィールフィード用のフィード項目は、他のユーザが特定のユーザについて作成した、あるいは他のユーザが特定のユーザに送信した、ポスト及びコメント、並びに、特定のユーザによりなされたステータスアップデートを含む。そのようなプロフィールフィードは、特定のユーザに関連付けられたページ上に表示され得る。別の例において、プロフィールフィード内のフィード項目は、特定のユーザにより作成されたポスト、及び、特定のユーザのアクションに基づいて生じたフィード追跡アップデートを含み得る。
I.一般的概要
企業レベルのソーシャル及びビジネス情報ネットワーキングを実装するためのシステム、装置、及び方法が提供される。そのような実装は、データベースシステムのより効率的な使用を提供し得る。例えば、データベースシステムのユーザは、例えば、プロジェクト又はクライアントについてのデータベース内の重要な情報がいつ変更されたかを容易に知ることはできない。実施例は、そのような変更及び他のイベントについてのフィード追跡アップデートを提供することができ、それにより、ユーザに知らせ続けることができる。
例えば、ユーザは、例えば、1000個のコンピュータの可能な販売等の商談といったレコードをアップデートすることができる。レコードのアップデートがなされると、次いで、レコードのアップデートについてのフィード追跡アップデートが、その商談又はそのユーザにサブスクライブしている全てのユーザに対して、例えばフィード内に、自動的に提供され得る。したがって、そのユーザは、その商談の変更に関してマネージャとコンタクトする必要がない。なぜならば、そのアップデートについてのフィード追跡アップデートが、フィードを介して、マネージャのフィードページ又は他のページに直ちに送信されるからである。
次いで、いくつかの実施例を参照して、企業レベルのソーシャル及びビジネス情報ネットワーキングを実装するシステムを提供するための機構及び方法が説明される。まず、データベースシステムの一例の概要が説明され、次いで、レコードに関するイベントの追跡、ユーザのアクションの追跡、及び、ユーザ又はレコードについてのメッセージの追跡の例が説明される。フィードのデータ構造、フィードのカスタマイズ、フォローするレコード及びユーザのユーザ選択、フィードの生成、及びフィードの表示についての様々な実施例も説明される。
II.システム概要
図1Aは、いくつかの実施例に従ってオンデマンドデータベースサービスが使用され得る環境10の一例のブロック図を示している。環境10は、ユーザシステム12、ネットワーク14、データベースシステム16、プロセッサシステム17、アプリケーションプラットフォーム18、ネットワークインタフェース20、テナントデータストレージ22、システムデータストレージ24、プログラムコード26、及びプロセススペース28を含み得る。他の実施例において、環境10は、これらのコンポーネントの全てを含まなくてもよいし、且つ/あるいは、上記で挙げたコンポーネントの代わりに、又は上記で挙げたコンポーネントに加えて、他のコンポーネントを含んでもよい。
環境10は、オンデマンドデータベースサービスが存在する環境である。ユーザシステム12は、データベースシステム16にアクセスするためにユーザにより使用されるマシン又はシステム等の任意の1以上のコンピューティングデバイス又は他のデータ処理装置として実装され得る。例えば、ユーザシステム12のいずれも、ハンドヘルドコンピューティングデバイス、携帯電話機、ラップトップコンピュータ、ワークステーション、及び/又はそのようなコンピューティングデバイスのネットワークであり得る。図1Aに示されるように(且つ図1Bにより詳細に示されるように)、ユーザシステム12は、ネットワーク14を介して、図1Aの例においてデータベースシステム16として実装されているオンデマンドデータベースサービスとインタラクトすることができる。
例えばシステム16を用いて実装されているオンデマンドデータベースサービスは、データベースシステムを構築及び/又は保守することに必ずしも関与している必要はない外部ユーザに利用可能になっているサービスである。代わりに、データベースシステムは、ユーザがデータベースシステムを必要とするときに、すなわち、ユーザの要求時に、ユーザによる使用のために利用可能であってもよい。いくつかのオンデマンドデータベースサービスは、1以上のテナントからの情報を、マルチテナントデータベースシステム(MTS)を形成するための共通データベースイメージのテーブルに記憶することができる。データベースイメージは、1以上のデータベースオブジェクトを含み得る。リレーショナルデータベース管理システム(RDBMS)又はその均等物は、1以上のデータベースオブジェクトに対して、情報の記憶及び取得を実行することができる。アプリケーションプラットフォーム18は、例えばオペレーティングシステムといったソフトウェア及び/又はハードウェア等、システム16のアプリケーションが動作することを可能にするフレームワークであり得る。いくつかの実施例において、アプリケーションプラットフォーム18は、オンデマンドデータベースサービスのプロバイダ、ユーザシステム12を介してオンデマンドデータベースサービスにアクセスするユーザ、又はユーザシステム12を介してオンデマンドデータベースサービスにアクセスするサードパーティアプリケーション開発者により開発される1以上のアプリケーションの作成、管理、及び実行を可能にする。
ユーザシステム12のユーザは、それぞれの能力の点で異なり得るものであり、特定のユーザシステム12の能力は、現在のユーザに対するパーミッション(パーミッションレベル)により完全に決定され得る。例えば、販売員が、システム16とインタラクトするために特定のユーザシステム12を使用している場合、そのユーザシステムは、その販売員に割り当てられた能力を有する。しかしながら、管理者が、システム16とインタラクトするためにそのユーザシステムを使用している間、そのユーザシステムは、その管理者に割り当てられた能力を有する。階層ロールモデルを有するシステムにおいて、あるパーミッションレベルのユーザは、より低いパーミッションレベルのユーザによりアクセス可能なアプリケーション、データ、及びデータベース情報にアクセスすることはできるが、より高いパーミッションレベルのユーザによりアクセス可能な所定のアプリケーション、データ、及びデータベース情報にはアクセスすることができない。したがって、アプリケーション及びデータベース情報にアクセスし、それらを変更することに関して、異なるユーザは、権限とも呼ばれるユーザのパーミッションレベル又はセキュリティレベルに応じて、異なる能力を有する。
ネットワーク14は、他のデバイスと通信するデバイスの任意のネットワーク又はネットワークの組合せである。例えば、ネットワーク14は、LAN(ローカルエリアネットワーク)、WAN(ワイドエリアネットワーク)、電話網、無線ネットワーク、ポイントツーポイントネットワーク、スター型ネットワーク、トークンリングネットワーク、ハブネットワーク、又は他の適切な構成のうちの任意の1つ又はこれらの任意の組合せであり得る。ネットワーク14は、「インターネット(Internet)」(「I」は大文字)と呼ばれることが多い、ネットワークの全世界的相互ネットワーク等のTCP/IP(伝送制御プロトコル及びインターネットプロトコル)ネットワークを含み得る。インターネットは、本明細書における例の多くで使用される。しかしながら、TCP/IPは、頻繁に実装されるプロトコルであるが、本実施例が使用できるネットワークは、これに限定されるものではないことを理解すべきである。
ユーザシステム12は、TCP/IPを使用してシステム16と通信することもできるし、より高いネットワークレベルでは、HTTP、FTP、AFS、WAP等の他の一般的なインターネットプロトコルを使用して通信することもできる。HTTPが使用される例において、ユーザシステム12は、システム16におけるHTTPサーバとの間でHTTP信号を送受信するための、一般に「ブラウザ」と呼ばれるHTTPクライアントを含み得る。このようなHTTPサーバは、システム16とネットワーク14との間の唯一のネットワークインタフェース20として実装され得るが、他の技術が併用又は代用されてもよい。いくつかの実施例において、システム16とネットワーク14との間のネットワークインタフェース20は、負荷を平衡させ、到来するHTTPリクエストを複数のサーバにわたって均等に分配するためのラウンドロビン式HTTPリクエストディストリビュータ等の負荷分散機能を含む。複数のサーバの各々は、少なくともシステム16にアクセスしているユーザに関しては、MTSのデータへのアクセスを有する。しかしながら、代わりに、他の代替構成が使用されてもよい。
一実施例において、図1Aに示されるシステム16は、ウェブベースの顧客関係管理(CRM)システムを実装する。例えば、一実施例において、システム16は、CRMソフトウェアアプリケーションを実装及び実行するとともに、関連データ、コード、フォーム、ウェブページ、及び他の情報をユーザシステム12との間で提供し、関連データ、オブジェクト、及びウェブページコンテンツをデータベースシステムに記憶してデータベースシステムから取得するよう構成されたアプリケーションサーバを含む。マルチテナントシステムにおいて、複数のテナントのためのデータは、テナントデータストレージ22内の同じ物理データベースオブジェクトに記憶され得るが、テナントデータは、明示的に共用される場合を除き、あるテナントが別のテナントのデータにアクセスすることのないように、あるテナントのデータが他のテナントのデータから論理的に別々に保持されるようテナントデータストレージ22の1以上の記憶媒体に通常は配置される。所定の実施例において、システム16は、CRMアプリケーションとは異なるアプリケーション又はCRMアプリケーションに追加されるアプリケーションを実装する。例えば、システム16は、CRMアプリケーションを含む複数のホストされた(標準及びカスタム)アプリケーションへのテナントアクセスを提供することができる。CRMアプリケーションを含んでも含まなくてもよいユーザアプリケーション(又は、サードパーティ開発者アプリケーション)は、アプリケーションプラットフォーム18によりサポートされ得る。アプリケーションプラットフォーム18は、アプリケーションの作成、1以上のデータベースオブジェクトへのアプリケーションの記憶、及びシステム16のプロセススペース内での仮想マシンにおけるアプリケーションの実行を管理する。
ネットワークインタフェース20、アプリケーションプラットフォーム18、テナントデータ23のためのテナントデータストレージ22、システム16及びおそらくは複数のテナントがアクセス可能なシステムデータ25のためのシステムデータストレージ24、システム16の様々な機能を実装するためのプログラムコード26、並びにMTSシステムプロセス及びテナント固有プロセスを実行するための、例えば、アプリケーションホスティングサービスの一部としてアプリケーションを実行するためのプロセススペース28を含む、システム16の要素の一構成が、図1A及び図1Bに示されている。システム16上で実行することができるさらなるプロセスは、データベースインデクシングプロセスを含む。
図1Aに示されるシステム内のいくつかの要素は、本明細書で簡略的に説明されるに過ぎない従来の周知要素を含む。例えば、各ユーザシステム12は、デスクトップパーソナルコンピュータ、ワークステーション、ラップトップ、PDA、携帯電話機、若しくは任意の無線アクセスプロトコル(WAP)対応デバイス、又はインターネット若しくは他のネットワーク接続と直接的又は間接的にインタフェースをとることができる任意の他のコンピューティングデバイスを含み得る。用語「コンピューティングデバイス」は、本明細書において単に「コンピュータ」とも呼ばれる。ユーザシステム12は、通常は、例えばブラウジングプログラムといった、Microsoft(登録商標)のInternet Explorer(登録商標)ブラウザ、Netscape(登録商標)のNavigatorブラウザ、Opera(登録商標)のブラウザ、又は、携帯電話機、PDA、若しくは他の無線デバイスの場合にはWAP対応ブラウザ等といったHTTPクライアントを実行して、ユーザシステム12のユーザ(例えば、マルチテナントデータベースシステムのサブスクライバ)が、システム16からネットワーク14を介してそのユーザが利用可能な情報、ページ、及びアプリケーションにアクセスし、それらを処理し、それらを閲覧することを可能にする。各ユーザシステム12はまた、通常は、システム16又は他のシステム若しくはサーバにより提供されるページ、フォーム、アプリケーション、及び他の情報とともにブラウザによりコンピューティングデバイスのディスプレイ(例えば、モニタスクリーン、LCDディスプレイ等)上に提供されるグラフィカルユーザインタフェース(GUI)とインタラクトするための、キーボード、マウス、トラックボール、タッチパッド、タッチスクリーン、ペン、又は同様のもの等の1以上のユーザ入力デバイスを含む。例えば、ユーザインタフェースデバイスは、システム16によりホストされているアプリケーション及びデータにアクセスし、記憶されているデータに対して探索を実行し、ユーザがユーザに提示され得る様々なGUIページとインタラクトすることを他の形で可能にするために使用され得る。上述したように、実施例は、インターネットとともに使用するのに適したものであるが、イントラネット、エクストラネット、仮想プライベートネットワーク(VPN)、非TCP/IPベースのネットワーク、任意のLAN若しくはWAN、又は同様のネットワーク等の他のネットワークが、インターネットの代わりに、あるいはインターネットに加えて、使用されてもよい。
一実施例に従うと、各ユーザシステム12及びそのコンポーネントの全ては、Intel(登録商標) Pentium(登録商標)プロセッサ又は同様のもの等の中央処理装置を用いて実行されるコンピュータコードを含む、ブラウザ等のアプリケーションを用いてオペレータ構成可能である。同様に、システム16(及び、複数存在する場合にはMTSのさらなるインスタンス)並びにそのコンポーネントの全ては、Intel(登録商標) Pentium(登録商標)プロセッサ若しくは同様のものを含み得る中央処理装置及び/又は複数のプロセッサ装置を含むよう実装され得るプロセッサシステム17を用いて実行されるコンピュータコードを含む1以上のアプリケーションを用いてオペレータ構成可能であり得る。非一時的なコンピュータ読み取り可能媒体は、命令を記憶することができ、そのような命令は、本明細書で説明される実施例の方法のいずれかを実行するコンピューティングデバイスにより実行され得る、あるいは本明細書で説明される実施例の方法のいずれかを実行するようコンピューティングデバイスをプログラムするために使用され得る。本明細書で説明されるように、ウェブページ、アプリケーション、並びに他のデータ及びメディアコンテンツを相互通信して、処理するようにシステム16を動作させ構成するための命令を実装するコンピュータプログラムコード26は、好ましくは、ダウンロード可能であり、ハードディスクに記憶されるが、プログラムコード全体又はその部分は、ROM又はRAM等の、周知である任意の他の揮発性又は不揮発性メモリ媒体又はデバイスに記憶されてもよいし、フロッピディスク、光ディスク、デジタル多用途ディスク(DVD)、コンパクトディスク(CD)、マイクロドライブ、及び光磁気ディスクを含む任意のタイプの回転媒体、磁気カード若しくは光カード、ナノシステム(分子メモリICを含む)、又は、命令及び/又はデータを記憶するのに適した任意の他のタイプのコンピュータ読み取り可能媒体又はデバイス等の、プログラムコードを記憶することができる任意の媒体に提供されてもよい。さらに、プログラムコード全体又はその部分は、例えば、インターネット等の伝送媒体を介してソフトウェアソースから、あるいは周知である別のサーバから送信されダウンロードされてもよいし、周知である任意の他の従来のネットワーク接続(例えば、エクストラネット、VPN、LAN等)を介して、周知である任意の通信媒体及びプロトコル(例えば、TCP/IP、HTTP、HTTPS、イーサネット(登録商標)等)を用いて送信されてもよい。また、クライアントシステム及び/又はサーバ若しくはサーバシステム上で実行され得る、開示される実施例のためのコンピュータコードは、例えば、C、C++、HTML、任意の他のマークアップ言語、Java(登録商標)、JavaScript(登録商標)、ActiveX(登録商標)、VBScript等の任意の他のスクリプト言語、及び、使用することができる周知である多くの他のプログラミング言語等の任意のプログラミング言語により実現され得ることも理解されよう(Java(登録商標)は、Sun Microsystems, Inc.の商標である)。
いくつかの実施例に従うと、各システム16は、ウェブページ、フォーム、アプリケーション、データ、及びメディアコンテンツをユーザシステム(クライアントシステム)12に提供して、システム16のテナントとしてのユーザシステム12によるアクセスをサポートするよう構成される。そのようなものとして、システム16は、データが共用される場合を除いて、各テナントのデータを別々に保持するためのセキュリティ機構を提供する。複数のMTSが使用される場合、それらは、互いに近接して(例えば、1つのビル又はキャンパス内に配置されたサーバファーム内に)配置されてもよいし、互いから離れた場所に分散されてもよい(例えば、1以上のサーバをA市に配置させ、1以上のサーバをB市に配置させる)。本明細書で使用されるように、各MTSは、局所的に、あるいは1以上の地理的場所にわたって分散された1以上の論理的及び/又は物理的に接続されたサーバを含み得る。さらに、用語「サーバ」は、当分野で周知である、処理ハードウェア及び1以上のプロセススペース、メモリデバイス又はデータベース等の関連する記憶媒体、並びに、いくつかの例ではデータベースアプリケーション(例えば、OODBMS又はRDBMS)を含むコンピューティングデバイス又はコンピューティングシステムを指すことが意図される。また、「サーバシステム」及び「サーバ」は、本明細書においてしばしば同じ意味で使用されることを理解すべきである。同様に、本明細書に記載されるデータベースオブジェクトは、単一のデータベース、分散データベース、分散データベースの集合、冗長オンラインバックアップ若しくは冗長オフラインバックアップ又は他の冗長性を有するデータベース等として実装され得、分散データベース又はストレージネットワーク、及び関連する処理インテリジェンス(processing intelligence)を含み得る。
図1Bは、図1Aの要素とそれら要素間の種々の可能な相互接続とのいくつかの実装の例のブロック図を示している。すなわち、図1Bも環境10を示している。しかしながら、図1Bでは、いくつかの実施例におけるシステム16の要素と種々の相互接続とが、さらに例示されている。図1Bは、ユーザシステム12が、プロセッサシステム12A、メモリシステム12B、入力システム12C、及び出力システム12Dを含み得ることを示している。図1Bは、ネットワーク14及びシステム16を示している。図1Bはまた、システム16が、テナントデータストレージ22、テナントデータ23、システムデータストレージ24、システムデータ25、ユーザインタフェース(UI)30、アプリケーションプログラムインタフェース(API)32、PL/SOQL34、記録ルーチン36、アプリケーションセットアップ機構38、アプリケーションサーバ100〜100、システムプロセススペース102、テナントプロセススペース104、テナント管理プロセススペース110、テナントストレージスペース112、ユーザストレージ114、及びアプリケーションメタデータ116を含み得ることを示している。他の実施例において、環境10は、上記で挙げた要素と同じ要素を有さなくてもよいし、且つ/あるいは、上記で挙げた要素の代わりに、又は上記で挙げた要素に加えて、他の要素を有してもよい。
ユーザシステム12、ネットワーク14、システム16、テナントデータストレージ22、及びシステムデータストレージ24は、図1Aにおいて上述されている。ユーザシステム12に関して、プロセッサシステム12Aは、1以上のプロセッサの任意の組合せであり得る。メモリシステム12Bは、1以上のメモリデバイス、短期メモリ、及び/又は長期メモリの任意の組合せであり得る。入力システム12Cは、1以上のキーボード、マウス、トラックボール、スキャナ、カメラ、及び/又はネットワークへのインタフェース等の入力デバイスの任意の組合せであり得る。出力システム12Dは、1以上のモニタ、プリンタ、及び/又はネットワークへのインタフェース等の出力デバイスの任意の組合せであり得る。図1Bに示されるように、システム16は、HTTPアプリケーションサーバ100のセットとして実装された(図1Aの)ネットワークインタフェース20、アプリケーションプラットフォーム18、テナントデータストレージ22、及びシステムデータストレージ24を含み得る。個々のテナントプロセススペース104及びテナント管理プロセススペース110を含むシステムプロセススペース102も示されている。各アプリケーションサーバ100は、ユーザシステム12のリクエストを処理するために、テナントデータストレージ22及びテナントデータストレージ22内のテナントデータ23、並びに、システムデータストレージ24及びシステムデータストレージ24内のシステムデータ25と通信するよう構成され得る。テナントデータ23は、データの物理構成及び/又は論理構成であり得る個々のテナントストレージスペース112に分割され得る。各テナントストレージスペース112内では、ユーザストレージ114及びアプリケーションメタデータ116が、ユーザごとに同様に割り当てられ得る。例えば、ユーザの直近に使用された(MRU:most recently used)項目のコピーは、ユーザストレージ114に記憶され得る。同様に、テナントである組織全体についてのMRU項目のコピーは、テナントストレージスペース112に記憶され得る。UI30は、システム16に存在するプロセスへのユーザインタフェースを、API32は、そのようなプロセスへのアプリケーションプログラマインタフェースを、ユーザシステム12におけるユーザ及び/又は開発者に提供する。テナントデータ及びシステムデータは、1以上のOracle(登録商標)データベース等の様々なデータベースに記憶され得る。
アプリケーションプラットフォーム18は、アプリケーション開発者のアプリケーションの作成及び管理をサポートするアプリケーションセットアップ機構38を含み、アプリケーションは、例えば、テナント管理プロセス110により管理される1以上のテナントプロセススペース104としてのサブスクライバによる実行のために、記録ルーチン36によりテナントデータストレージ22にメタデータとして記録され得る。そのようなアプリケーションへの呼び出しは、プログラミング言語形式のインタフェース拡張をAPI32に提供するPL/SOQL34を用いてコード化され得る。いくつかのPL/SOQL言語実装の詳細な説明は、Craig Weissmanによる「METHOD AND SYSTEM FOR ALLOWING ACCESS TO DEVELOPED APPLICATIONS VIA A MULTI-TENANT ON-DEMAND DATABASE SERVICE」と題された2010年6月1日に発行された同一出願人による米国特許第7730478号に記載されており、これは、その全体を参照することにより、全ての目的のために、本明細書に組み込まれる。アプリケーションへの呼び出しは、1以上のシステムプロセスにより検出され得、1以上のシステムプロセスは、サブスクライバが、アプリケーションを呼び出して、アプリケーションメタデータ116をアプリケーションとして仮想マシンにおいて実行するために、アプリケーションメタデータ116の取得を管理する。
各アプリケーションサーバ100は、データベースシステムに通信可能に接続され得、データベースシステムは、例えば、異なるネットワーク接続を介してシステムデータ25及びテナントデータ23にアクセスする。例えば、あるアプリケーションサーバ100は、ネットワーク14(例えば、インターネット)を介して接続され得、別のアプリケーションサーバ100N−1は、直接ネットワークリンクを介して接続され得、別のアプリケーションサーバ100は、さらに異なるネットワーク接続を介して接続され得る。伝送制御プロトコル及びインターネットプロトコル(TCP/IP)は、アプリケーションサーバ100とデータベースシステムとの間で通信するための典型的なプロトコルである。しかしながら、使用されるネットワーク相互接続に応じてシステムを最適化するために、他の転送プロトコルが使用されてもよいことが当業者には明らかであろう。
所定の実施例において、各アプリケーションサーバ100は、テナントである任意の組織に関連付けられた任意のユーザのリクエストを処理するよう構成される。任意の時点において任意の理由でアプリケーションサーバをサーバプールに追加でき、アプリケーションサーバをサーバプールから除去できることが望ましいので、好ましくは、特定のアプリケーションサーバ100に対するユーザ及び/又は組織のサーバアフィニティは存在しない。したがって、一実施形態において、リクエストをアプリケーションサーバ100に分配するために、アプリケーションサーバ100とユーザシステム12との間に、負荷平衡機能(例えば、F5 Big−IP負荷バランサ)を実装するインタフェースシステムが通信可能に接続される。一実施例において、負荷バランサは、ユーザリクエストをアプリケーションサーバ100にルーティングするために、最小接続アルゴリズムを使用する。ラウンドロビンの観測された応答時間等、負荷平衡アルゴリズムの他の例が使用されてもよい。例えば、所定の実施例において、同じユーザからの3つの連続したリクエストが、3つの異なるアプリケーションサーバ100に到達することがあり得、異なるユーザからの3つのリクエストが、同じアプリケーションサーバ100に到達することもあり得る。このように、例えば、システム16は、マルチテナント型であり、システム16は、異なるユーザ及び組織にわたる異なるオブジェクト、データ、及びアプリケーションの記憶、並びに異なるオブジェクト、データ、及びアプリケーションへのアクセスを処理する。
ストレージの一例として、あるテナントは、販売員を雇用する会社であり得、各販売員は、各自の販売プロセスを管理するためにシステム16を使用する。したがって、ユーザは、連絡先データ、リードデータ、顧客フォローアップデータ、実績データ、目標及び進捗データ等、そのユーザの個人販売プロセスに利用可能な全てを、(例えば、テナントデータストレージ22に)保持することができる。MTS構成の一例において、アクセス、閲覧、変更、報告、送信、計算等を行うためのデータ及びアプリケーションの全てが、ネットワークアクセスを有するに過ぎないユーザシステムにより保持されアクセスされ得るので、ユーザは、多くの異なるユーザシステムのいずれからも、自身の販売活動及び販売サイクルを管理することができる。例えば、販売員が顧客を訪問しており、顧客がロビーにおいてインターネットアクセスを有する場合、販売員は、顧客がロビーに到着するのを待ちながら、顧客に関する重大なアップデートを得ることができる。
各ユーザのデータは、各ユーザの雇用者にかかわらず、他のユーザのデータから分離され得るが、いくつかのデータは、テナントである所与の組織の複数のユーザ又は全てのユーザにより共用又はアクセスされる全組織的なデータであり得る。したがって、他のデータ構造がユーザレベルで管理され得る一方で、テナントレベルで割り当てられる、システム16により管理されるいくつかのデータ構造が存在し得る。MTSは、見込みコンペティタを含む複数のテナントをサポートできるので、MTSは、データ、アプリケーション、及びアプリケーション使用を独立して維持するセキュリティプロトコルを有するべきである。また、多くのテナントは、各自のシステムを維持するよりも、MTSにアクセスする方を選択することがあるので、冗長性、使用可能時間(up-time)、及びバックアップは、MTSにおいて実装され得る付加機能である。ユーザ固有データ及びテナント固有データに加えて、システム16は、複数のテナントにより使用可能なシステムレベルデータ、又は他のデータも保持することができる。そのようなシステムレベルデータは、テナント間で共有可能な業界レポート、ニュース、及びポスティング等を含み得る。
所定の実施例において、(クライアントシステムであり得る)ユーザシステム12は、システムレベルデータ及びテナントレベルデータをシステム16にリクエストして、アップデートするために、アプリケーションサーバ100と通信する。このリクエスト及びアップデートは、1以上のクエリをテナントデータストレージ22及び/又はシステムデータストレージ24に送信することを含み得る。システム16(例えば、システム16内のアプリケーションサーバ100)は、所望の情報にアクセスするために設計される1以上のSQL文(例えば、1以上のSQLクエリ)を自動的に生成する。システムデータストレージ24は、リクエストされたデータをデータベースから取得するためのクエリプランを生成することができる。
各データベースは、一般に、予め定義されたカテゴリに一致するデータを含む、論理テーブルのセット等のオブジェクトの集合とみなすことができる。「テーブル」は、データオブジェクトの1つの表現であり、いくつかの実施例に従ったオブジェクト及びカスタムオブジェクトの概念的説明を簡略化するために本明細書では使用され得る。「テーブル」及び「オブジェクト」は、本明細書において同じ意味で使用され得ることを理解すべきである。各テーブルは、一般に、閲覧可能なスキーマにおいて列すなわちフィールドとして論理的に配列される1以上のデータカテゴリを含む。テーブルの各行すなわちレコードは、フィールドにより定義される各カテゴリについてのデータのインスタンスを含む。例えば、CRMデータベースは、名前、住所、電話番号、ファックス番号等の基本連絡先情報用のフィールドを用いて顧客を記述するテーブルを含み得る。別のテーブルは、顧客、製品、販売価格、日付等の情報用のフィールドを含む発注を記述することができる。いくつかのマルチテナントデータベースシステムにおいて、全てのテナントにより使用するための標準エンティティテーブルが提供され得る。CRMデータベースアプリケーションの場合、そのような標準エンティティテーブルは、各々が予め定義されたフィールドを含む、案件、取引先、連絡先、リード、及び商談データオブジェクト用のテーブルを含み得る。用語「エンティティ」は、本明細書において「オブジェクト」及び「テーブル」と同じ意味で使用され得ることも理解すべきである。
いくつかのマルチテナントデータベースシステムにおいて、テナントは、カスタムオブジェクトを作成して記憶させることを許可され得る、あるいは、例えば、カスタムインデクスフィールドを含む、標準オブジェクト用のカスタムフィールドを作成することにより、標準エンティティ又はオブジェクトをカスタマイズすることを許可され得る。Weissmanらによる「CUSTOM ENTITIES AND FIELDS IN A MULTI-TENANT DATABASE SYSTEM」と題された2010年8月17日に発行された同一出願人による米国特許第7779039号(これは、その全体を参照することにより、全ての目的のために、本明細書に組み込まれる)は、マルチテナントデータベースシステムにおいてカスタムオブジェクトを作成するとともに標準オブジェクトをカスタマイズするためのシステム及び方法を教示している。例えば、所定の実施例において、全てのカスタムエンティティデータ行は、組織当たり複数の論理テーブルを含み得る単一のマルチテナント物理テーブルに記憶される。顧客の複数の「テーブル」が、実際には1つの大きなテーブルに記憶されること、又は、顧客のデータが、他の顧客のデータと同じテーブルに記憶されることがあることが、顧客に透過的である。
図2Aは、いくつかの実施例に従ったオンデマンドデータベースサービス環境200のアーキテクチャコンポーネントの例を示すシステム図を示している。本明細書で説明されるように、組み合わされた1以上のネットワークを一般に指すクラウド204内に配置されたクライアントマシンは、1以上のエッジルータ208及び212を介して、オンデマンドデータベースサービス環境と通信することができる。クライアントマシンは、上述したユーザシステム12の例のいずれかであり得る。エッジルータは、ファイアウォール216を介して、1以上のコアスイッチ220及び224と通信することができる。コアスイッチは、負荷バランサ228と通信することができ、負荷バランサ228は、ポッド240及び244等の異なるポッドに対してサーバ負荷を分散させることができる。各々が1以上のサーバ及び/又は他のコンピューティングリソースを含み得るポッド240及び244は、オンデマンドサービスを提供するために用いられるデータ処理及び他のオペレーションを実行することができる。ポッドとの通信は、ポッドスイッチ232及び236を介してなされ得る。オンデマンドデータベースサービス環境のコンポーネントは、データベースファイアウォール248及びデータベーススイッチ252を介して、データベースストレージ256と通信することができる。
図2A及び図2Bに示されるように、オンデマンドデータベースサービス環境にアクセスすることは、種々の異なるハードウェアコンポーネント及び/又はソフトウェアコンポーネント間で伝送される通信を含み得る。さらに、オンデマンドデータベースサービス環境200は、実際のオンデマンドデータベースサービス環境の単純化された表現である。例えば、図2A及び図2Bにおいて、各タイプの1つのデバイス又は2つのデバイスのみが示されているが、オンデマンドデータベースサービス環境のいくつかの実装は、各タイプの1つのデバイスから多数のデバイスの範囲を含んでもよい。また、オンデマンドデータベースサービス環境は、図2A及び図2Bに示される各デバイスを含む必要はないし、図2A及び図2Bに示されないさらなるデバイスを含んでもよい。
さらに、オンデマンドデータベースサービス環境200内のデバイスのうちの1以上は、同じ物理デバイス又は異なるハードウェア上に実装されてもよい。いくつかのデバイスは、ハードウェア又はハードウェアとソフトウェアとの組合せを用いて実装され得る。したがって、本明細書で使用される「データ処理装置」、「マシン」、「サーバ」、及び「デバイス」等の用語は、単一のハードウェアデバイスに限定されるものではなく、説明される機能を提供するよう構成された任意のハードウェア及びソフトウェアを含む。
クラウド204は、インターネットをしばしば含む、1つのデータネットワーク又は複数のデータネットワークを指すよう意図されている。クラウド204内に配置されたクライアントマシンは、オンデマンドデータベースサービス環境と通信して、オンデマンドデータベースサービス環境により提供されるサービスにアクセスすることができる。例えば、クライアントマシンは、オンデマンドデータベースサービス環境にアクセスして、情報を取得、記憶、編集、及び/又は処理することができる。
いくつかの実施例において、エッジルータ208及び212は、クラウド204とオンデマンドデータベースサービス環境200の他のコンポーネントとの間でパケットをルーティングする。エッジルータ208及び212は、ボーダゲートウェイプロトコル(BGP)を使用することができる。BGPは、インターネットのコアルーティングプロトコルである。エッジルータ208及び212は、インターネット上の自律システム間におけるネットワーク到達可能性を示す、IPネットワークのテーブル、すなわち、「プレフィックス」を保持することができる。
1以上の実施例において、ファイアウォール216は、インターネットトラフィックから、オンデマンドデータベースサービス環境200の内部コンポーネントを保護することができる。ファイアウォール216は、ルールのセット及び他の基準に基づいて、オンデマンドデータベースサービス環境200の内部コンポーネントへのアクセスをブロック、許可、又は拒否することができる。ファイアウォール216は、パケットフィルタ、アプリケーションゲートウェイ、ステートフルフィルタ、プロキシサーバ、又は任意の他のタイプのファイアウォールのうちの1以上として動作することができる。
いくつかの実施例において、コアスイッチ220及び224は、オンデマンドデータベースサービス環境200内でパケットを転送する高能力スイッチである。コアスイッチ220及び224は、オンデマンドデータベースサービス環境内の異なるコンポーネント間でデータを迅速にルーティングするネットワークブリッジとして構成され得る。いくつかの実施例において、2以上のコアスイッチ220及び224の使用は、冗長性及び/又は低減された待ち時間を提供することができる。
いくつかの実施例において、ポッド240及び244は、オンデマンドデータベースサービス環境により提供されるコアデータ処理及びサービス機能を実行することができる。各ポッドは、様々なタイプのハードウェアコンピューティングリソース及び/又はソフトウェアコンピューティングリソースを含み得る。ポッドアーキテクチャの一例は、図2Bを参照してより詳細に説明される。
いくつかの実施例において、ポッド240とポッド244との間の通信は、ポッドスイッチ232及び236を介してなされ得る。ポッドスイッチ232及び236は、例えば、コアスイッチ220及び224を介した、ポッド240及び244とクラウド204内に配置されたクライアントマシンとの間の通信を円滑にすることができる。また、ポッドスイッチ232及び236は、ポッド240及び244とデータベースストレージ256との間の通信を円滑にすることができる。
いくつかの実施例において、負荷バランサ228は、ポッド240及び244間で作業負荷を分散させることができる。ポッド間でオンデマンドサービスリクエストを平衡させることは、リソースの使用を向上させること、スループットを増大させること、応答時間を低減させること、及び/又はオーバーヘッドを低減させることに役立ち得る。負荷バランサ228は、トラフィックを解析して転送するためのマルチレイヤスイッチを含み得る。
いくつかの実施例において、データベースストレージ256へのアクセスは、データベースファイアウォール248により保護され得る。データベースファイアウォール248は、プロトコルスタックのデータベースアプリケーションレイヤで動作するコンピュータアプリケーションファイアウォールとして動作することができる。データベースファイアウォール248は、構造化クエリ言語(SQL)インジェクション、データベースルートキット、及び権限のない情報開示(unauthorized information disclosure)等のアプリケーション攻撃からデータベースストレージ256を保護することができる。
いくつかの実施例において、データベースファイアウォール248は、トラフィックをゲートウェイルータに渡す前にトラフィックをプロキシするリバースプロキシサービスの1以上の形態を使用するホストを含み得る。データベースファイアウォール248は、データベーストラフィックのコンテンツを調べて、所定のコンテンツ又はデータベースリクエストをブロックすることができる。データベースファイアウォール248は、データベース又はSQL管理インタフェースへのアプリケーションの接続を管理するとともにパケットをインターセプトしてパケットがデータベースネットワーク又はアプリケーションインタフェースとの間で伝送されるよう強いる、TCP/IPスタックの最上位の(atop)SQLアプリケーションレベルで動作することができる。
いくつかの実施例において、データベースストレージ256との通信は、データベーススイッチ252を介してなされ得る。マルチテナントデータベースストレージ256は、データベースクエリを処理するための複数のハードウェアコンポーネント及び/又はソフトウェアコンポーネントを含み得る。したがって、データベーススイッチ252は、オンデマンドデータベースサービス環境の他のコンポーネント(例えば、ポッド240及び244)により送信されたデータベースクエリを、データベースストレージ256内の適切なコンポーネントに向かわせることができる。
いくつかの実施例において、データベースストレージ256は、多くの異なる組織により共用されるオンデマンドデータベースシステムである。オンデマンドデータベースシステムは、マルチテナントアプローチ、仮想化アプローチ、又は任意の他のタイプのデータベースアプローチを使用することができる。オンデマンドデータベースシステムは、図1A及び図1Bを参照してより詳細に説明されている。
図2Bは、いくつかの実施例に従ったオンデマンドデータベースサービス環境のアーキテクチャコンポーネントの例をさらに示すシステム図を示している。ポッド244を使用して、オンデマンドデータベースサービス環境200のユーザにサービスを提供することができる。いくつかの実施例において、各ポッドは、様々なサーバ及び/又は他のシステムを含み得る。ポッド244は、1以上のコンテンツバッチサーバ264、コンテンツ検索サーバ268、クエリサーバ282、ファイルフォースサーバ(file force server)286、アクセス制御システム(ACS)サーバ280、バッチサーバ284、及びアプリケーションサーバ(app server)288を含む。また、ポッド244は、データベースインスタンス290、クイックファイルシステム(QFS)292、及びインデクサ294を含む。1以上の実施例において、ポッド244内のサーバ間の通信の一部又は全ては、スイッチ236を介して伝送され得る。
いくつかの実施例において、アプリケーションサーバ288は、ポッド244を介してオンデマンドデータベースサービス環境200により提供されるアプリケーションの構築をサポートするためのプロシージャ(例えば、プログラム、ルーチン、スクリプト)の実行に専用のハードウェアフレームワーク及び/又はソフトウェアフレームワークを含み得る。いくつかの実施例において、アプリケーションサーバ288のハードウェアフレームワーク及び/又はソフトウェアフレームワークは、図15〜図56Cを参照して説明される方法のブロックの実行を含め、本明細書で説明されるサービスのオペレーションを実行するよう構成される。代替実施例において、2以上のアプリケーションサーバ288が、含まれて、協働してそのような方法を実行してもよいし、本明細書で説明される1以上の他のサーバが、開示される方法を実行するよう構成されてもよい。
コンテンツバッチサーバ264は、ポッドの内部に存在するリクエストを処理することができる。このようなリクエストは、長期に及ぶものであってもよいし、且つ/あるいは、特定の顧客に関連付けられていなくてもよい。例えば、コンテンツバッチサーバ264は、ログマイニング、クリーンアップ作業、及び保守タスクに関連するリクエストを処理することができる。
コンテンツ検索サーバ268は、クエリ機能及びインデクサ機能を提供することができる。例えば、コンテンツ検索サーバ268により提供される機能は、ユーザが、オンデマンドデータベースサービス環境に記憶されたコンテンツを検索することを可能にし得る。
ファイルフォースサーバ286は、Fileforceストレージ298に記憶された情報を求めるリクエストを管理することができる。Fileforceストレージ298は、文書、画像、及びベーシックラージオブジェクト(BLOB)等の情報を記憶することができる。ファイルフォースサーバ286を用いて、情報を求めるリクエストを管理することにより、データベース上のイメージフットプリント(image footprint)を低減させることができる。
クエリサーバ282を使用して、1以上のファイルシステムから情報を取得することができる。例えば、クエリシステム282は、アプリケーションサーバ288から、情報を求めるリクエストを受信し、次いで、情報クエリを、ポッド外部に配置されたNFS296に送信することができる。
ポッド244は、異なる組織が同じデータベースへのアクセスを共有するマルチテナント環境として構成されたデータベースインスタンス290を共有することができる。さらに、ポッド244により提供されるサービスは、様々なハードウェアリソース及び/又はソフトウェアリソースを要求することができる。いくつかの実施例において、ACSサーバ280は、データ、ハードウェアリソース、又はソフトウェアリソースへのアクセスを制御することができる。
いくつかの実施例において、バッチサーバ284は、指定された時間にタスクを実行するために用いられるバッチジョブを処理することができる。したがって、バッチサーバ284は、バッチジョブをトリガするために、アプリケーションサーバ288等の他のサーバに命令を送信することができる。
いくつかの実施例において、QFS292は、カリフォルニア州サンタクララのSun Microsystems(登録商標)から入手可能なオープンソースファイルシステムであり得る。QFSは、ポッド244内の利用可能な情報を記憶しそのような情報にアクセスするためのラピッドアクセスファイルシステムとして機能することができる。QFS292は、多くのディスクがファイルシステムに一緒にグループ化されることを可能にする、いくつかのボリューム管理機能をサポートすることができる。ファイルシステムメタデータは、ディスクの別々のセット上で保持することができ、これは、長いディスクシークを許容できないアプリケーションをストリーミングするのに有用であり得る。したがって、QFSシステムは、1以上のコンテンツ検索サーバ268及び/又はインデクサ294と通信して、ネットワークファイルシステム296及び/又は他のストレージシステムに記憶されたデータを識別し、取得し、移動させ、且つ/あるいはアップデートすることができる。
いくつかの実施例において、1以上のクエリサーバ282は、NFS296と通信して、ポッド244の外部で記憶された情報を取得及び/又はアップデートすることができる。NFS296は、ポッド244内に配置されたサーバが、ローカルストレージにアクセスするのと同様の方法でネットワークを介してファイルにアクセスするために情報にアクセスすることを可能にし得る。
いくつかの実施例において、クエリサーバ282からのクエリは、負荷バランサ228を介してNFS296に伝送され得る。負荷バランサ228は、オンデマンドデータベースサービス環境内で利用可能な様々なリソースに対するリソースリクエストを分散させることができる。NFS296はまた、QFS292と通信して、NFS296に記憶された情報をアップデートすることができる、且つ/あるいは、ポッド244内に配置されたサーバによる使用のために情報をQFS292に提供することができる。
いくつかの実施例において、ポッドは、1以上のデータベースインスタンス290を含み得る。データベースインスタンス290は、情報をQFS292に送信することができる。情報がQFSに送信されると、さらなるデータベース呼び出しを用いることなく、ポッド244内のサーバによる使用のために、その情報が利用可能であり得る。
いくつかの実施例において、データベース情報は、インデクサ294に伝送され得る。インデクサ294は、データベース290及び/又はQFS292内の利用可能な情報のインデクスを提供することができる。インデクス情報は、ファイルフォースサーバ286及び/又はQFS292に提供され得る。
III.データベースに記憶されたレコードに対するアップデートの追跡
複数のユーザが、レコードのデータを変更でき得るので、レコードがアップデートされたときを所定のユーザに通知することが有用であり得る。また、ユーザが、レコードを変更する権限を有していないとしても、そのユーザは、それでも、レコードがアップデートされたときを知りたいかもしれない。例えば、ベンダは、テナントYに関連付けられたユーザである、会社Xの販売員と新価格について交渉することがある。新たな請求書を作成することの一部として、あるいは会計目的のために、その販売員は、データベースに記録された価格を変更することができる。価格が変更されたことを同僚が知ることは重要であり得る。その販売員は、電子メールを所定の人に送り得るが、これは面倒であり、その販売員は、知る必要がある、あるいは知りたいと望んでいる人の全てに電子メールを送らない可能性もある。したがって、開示される技術のいくつかの実施例は、レコードに対するアップデートについて知りたいと望んでいる他の人(例えば、同僚)に、自動的に通知することができる。
図3は、いくつかの実施例に従って実行される、データベースシステムに記憶されたレコードに対するアップデートを追跡するための方法300の一例のフローチャートを示している。方法300(及び、本明細書で説明される他の方法)は、例えば、情報を受信又は取得し、その情報を処理し、結果を記憶し、その結果を送信するよう構成された1以上のプロセッサにより、マルチテナントデータベースシステム16を用いて少なくとも部分的に実施され得る。他の実施例において、方法300は、シングルテナントデータベースシステムを用いて少なくとも部分的に実施され得る。様々な実施例において、ブロックは、除去されてもよいし、組み合わされてもよいし、方法300用のさらなるブロックに分割されてもよい。本明細書で説明される他の方法についても同様である。
ブロック310において、データベースシステムは、第1のレコードをアップデートするリクエストを受信する。一実施例において、このリクエストは、第1のユーザから受信される。例えば、ユーザは、第1のレコードに関連付けられたページにアクセス中であり得、表示されたフィールドを変更して記録することがある。別の実施例において、データベースシステムは、このリクエストを自動的に生成することができる。例えば、データベースシステムは、例えば、特定の日及び/又は時間に定期的に送信され得る、フィールドを変更するリクエスト、又は、別のフィールド若しくはオブジェクトに対する変更といった別のイベントに応じて、このリクエストを生成することができる。データベースシステムは、レコードの他のフィールドに基づいて、且つ/あるいはシステムにおけるパラメータに基づいて、新たな値を取得することができる。
レコードのフィールドのアップデートを求めるこのリクエストは、フィード追跡アップデートが作成され得る、第1のレコードに関連付けられたイベントの一例である。他の実施例において、データベースシステムは、レコードのフィールドに対するアップデートに加えて、他のイベントも識別することができる。例えば、イベントは、フィールドを変更する承認の送信であり得る。そのようなイベントはまた、関連するフィールド(例えば、変更が送信されたかどうかのステータスを示すフィールド)を有することもできる。イベントの他の例は、レコードの作成、レコードの削除、あるタイプから別のタイプへのレコードの変換(例えば、リードから商談への変換)、レコード(例えば、案件タイプのレコード)のクローズ、及びレコードの可能な任意の他の状態変更(state change)を含み得、これらのいずれもが、状態変更に関連付けられたフィールド変更を含み得る。これらのイベントのいずれもが、レコードのフィールド、レコードの状態、又はレコードの何らかの他の特性若しくは属性を変更することにより、レコードをアップデートさせる。一実施例において、フィード追跡アップデートを作成するためにサポートされるイベントのリストが、例えば、サーバ又はデータベースにおいて、データベースシステム内に保持され得る。
ブロック320において、データベースシステムは、新たなデータを第1のレコードに書き込む。一実施例において、新たなデータは、古いデータに取って代わる新たな値を含み得る。例えば、フィールドが、新たな値を用いてアップデートされる。別の実施例において、新たなデータは、以前にはデータを含んでいなかったフィールドの値であり得る。さらに別の実施例において、新たなデータは、レコードのフィールドとして記憶され得る、例えばレコードのステータスのためのフラグであり得る。
いくつかの実施例において、「フィールド」はまた、親子階層における第1のレコードの子オブジェクトであるレコードを含み得る。代替的に、フィールドは、子レコードに対するポインタを含んでもよい。子オブジェクト自体もさらなるフィールドを含み得る。したがって、子オブジェクトのフィールドが、新たな値を用いてアップデートされる場合、親レコードも、変更されるフィールドを有するとみなされ得る。一例において、フィールドは、関連リスト(related list)とも呼ばれる関連子オブジェクト(related child object)のリストであり得る。
ブロック330において、レコードに対するアップデートについてのフィード追跡アップデートが生成される。一実施例において、フィード追跡アップデートは、後に表示バージョンにアセンブルするために部分的に作成される。例えば、イベントエントリが、第1のテーブル内で作成されて追跡され得、変更されたフィールドエントリが、第1のテーブルと相互参照されている別のテーブル内で追跡され得る。そのような実施例のさらなる詳細は、例えば図9Aを参照して後で提供される。別の実施例において、フィード追跡アップデートは、データベースシステムにより自動的に生成される。フィード追跡アップデートは、第1のレコードがアップデートされたことを文字で伝え、レコードにおいて何がアップデートされたかと誰がアップデートを実行したかとについての詳細を提供することができる。いくつかの実施例において、フィード追跡アップデートは、所定のタイプのイベント及び/又は第1のレコードに関連付けられたアップデートに対してのみ生成される。
一実施例において、テナントは、(例えば、管理者を通じて、)所定のタイプのレコードのみに対するフィード追跡アップデートを作成する(有効にする)ようにデータベースシステムを構成することができる。例えば、管理者は、例えば、取引先及び商談等の指定されたタイプのレコードが有効にされることを指定することができる。有効にされたレコードタイプについてのアップデート(又は、他のイベント)が受信されると、フィード追跡アップデートが生成される。別の実施例において、テナントはまた、変更が追跡されるべきであり、フィード追跡アップデートが作成される、レコードのフィールドを指定することができる。一態様において、追跡するフィールドの最大数が指定され得、これにはカスタムフィールドが含まれ得る。一実施例において、例えば、フィールドの値変化が、閾値(例えば、絶対量又はパーセンテージ変化)よりも大きいといった変更のタイプも指定され得る。さらに別の実施例において、テナントは、どのイベントがフィード追跡アップデートを生成させるべきであるかを指定することができる。また、一実施例において、個々のユーザは、以下でより詳細に説明されるカスタムフィードを作成することができる、ユーザに固有の構成を指定することができる。
一実施例において、子オブジェクトのフィールドに対する変更は、親レコードに対するフィード追跡アップデートを作成するためには追跡されない。別の実施例において、子オブジェクトのフィールドに対する変更は、親レコードに対するフィード追跡アップデートを作成するために追跡され得る。例えば、親タイプの子オブジェクトが、追跡のために指定され得、子オブジェクトの所定のフィールドが、追跡のために指定され得る。別の例として、子オブジェクトが、追跡のために指定されたタイプである場合、子オブジェクトに対する追跡された変更が、子オブジェクトの親レコードに伝播される。
ブロック340において、フィード追跡アップデートが、第1のレコード用のフィードに追加される。一実施例において、フィード追跡アップデートをフィードに追加することは、イベントを、(レコードに固有であり得る、あるいはオブジェクトの全て又はオブジェクトのグループ用であり得る)テーブルに追加することを含み得、ユーザが、第1のレコード用のフィードをリクエストしたときに、フィード追跡アップデートの表示バージョンが、動的に生成されて、フィード項目としてGUI内に提示され得る。別の実施例において、レコードに関するレコードフィードが記憶され保持されるときに、フィード追跡アップデートの表示バージョンが追加されてもよい。上述したように、フィードは、所定のレコードに関してのみ保持され得る。一実施例において、レコードのフィードは、そのレコードに関連付けられたデータベースに記憶され得る。例えば、フィードは、そのレコードのフィールドとして(例えば、子オブジェクトとして)記憶され得る。そのようなフィールドは、フィード追跡アップデートに関して表示されるテキストに対するポインタを記憶することができる。
いくつかの実施例において、現在のフィード追跡アップデート(又は、他の現在のフィード項目)のみが、例えば、何らかの一時メモリ構造に、保持され得る、あるいは一時的に記憶され得る。例えば、任意の特定のフィールドに対する直近の変更のみについてのフィード追跡アップデートが保持される。他の実施例において、多くの以前のフィード追跡アップデートが、フィード内に保持されてもよい。各フィード追跡アップデートについての時間及び/又は日付が追跡され得る。本明細書において、レコードのフィードは、エンティティフィードとも呼ばれる。というのは、レコードは、データベースの特定のエンティティオブジェクトのインスタンスであるからである。
ブロック350において、第1のレコードのフォロワ(follower)が識別され得る。フォロワは、第1のレコードのフィードに対するサブスクライバ等、第1のレコードをフォローしているユーザである。一実施例において、ユーザが、特定のレコードのフィードをリクエストする場合、ブロック350のそのような識別は省略されてもよい。別の実施例において、レコードフィードが、(例えば、ニュースフィードの一部として、)ユーザにプッシュされる場合、そのユーザが、第1のレコードのフォロワとして識別され得る。したがって、このブロックは、特定のユーザによりフォローされているレコード及び他のオブジェクトの識別を含み得る。
一実施例において、データベースシステムは、特定のレコードについてのフォロワのリストを記憶することができる。様々な実施例において、このリストは、第1のレコードとともに、あるいはこのリストを取得するために識別子(例えば、ポインタ)を使用するレコードに関連付けられて、記憶され得る。例えば、このリストは、第1のレコードのフィールドに記憶され得る。別の実施例において、ユーザがフォローしているレコードのリストが使用される。一実施例において、データベースシステムは、各ユーザ用の、実行されるルーチンを有することができ、このルーチンは、リスト内のレコードをポーリングして、新たなフィード追跡アップデートがレコードのフィードに追加されたかどうかを判定する。別の実施例において、ユーザ用のこのルーチンは、ポーリングを実行するデータベースと通信するユーザデバイス上で少なくとも部分的に実行され得る。
ブロック360において、一実施例では、以下でより詳細に説明されるように、フィード追跡アップデートがテーブルに記憶され得る。ユーザがフィードを開いたときに、レコードに対するアップデートを取得するために、適切なクエリが、1以上のテーブルに送信される。このことも、以下でより詳細に説明される。いくつかの実施例において、フィードは、新しい順に(reverse chronological order)、フィード追跡アップデートを表示する。一実施例において、フィード追跡アップデートは、例えば、レコードに関連付けられたリストからレコードのフォロワを判別するルーチンにより、ユーザのフィードにプッシュされる。別の実施例において、フィード追跡アップデートは、例えばユーザデバイスにより、フィードにプルされる。このプルは、ブロック370で生じるように、ユーザがフィードをリクエストしたときに生じ得る。したがって、これらのアクションは、異なる順番で生じてもよい。プルされるフィードの作成は、リクエストしているユーザによりフォローされているレコードを識別する動的な作成であり得、記憶された情報(例えば、イベント及びフィールド変更)から、関連するフィード追跡アップデートの表示バージョンを生成し、フィード追跡アップデートをフィードに追加する。ユーザがフォローしているレコード及び他のオブジェクトのフィード追跡アップデートのフィードは、本明細書において、一般にニュースフィードとも呼ばれ、これは、ポスト等の他のタイプの情報アップデートが現れるより大きな情報フィードのサブセットであり得る。
さらに別の実施例において、フィード追跡アップデートは、フィード内に表示される代わりに、フォロワへの電子メールとして送信されてもよい。一実施例において、イベントについての電子メールアラートは、所定のイベントが発生したときに、人々に電子メールを送信することを可能にし得る。別の実施例において、ユーザプロフィールに対するポストが存在したときに、及びユーザがサブスクライブしているエンティティに対するポストが存在したときに、電子メールが送信されてもよい。一実施例において、ユーザは、全てのイベント又は一部のイベントについて、電子メールアラートをオン/オフにすることができる。一実施例において、ユーザは、このユーザがフォローしているレコードについて受信すべきフィード追跡アップデートの種類を指定することができる。例えば、ユーザは、このユーザがフォローしているレコードの所定のフィールドと、おそらくはどのような種類のアップデートが実行されたか(例えば、指定されたフィールドへの新たな値の入力、又は新たなフィールドの作成)と、についてのフィード追跡アップデートのみを受け取ることを選択することができる。
ブロック370において、フォロワは、自分のニュースフィードにアクセスして、フィード追跡アップデードを閲覧することができる。一実施例において、ユーザは、このユーザがフォローしているレコードの全てに対する1つのニュースフィードのみを有する。一態様において、ユーザは、データベースシステムへのインタフェースのページ上で特定のタブ又は他のオブジェクトを選択することにより、自分のフィードにアクセスすることができる。選択されると、フィードが、例えば、識別子(例えば、時間)を有するリスト又はフィード追跡アップデートのテキストの一部又は全てを含むリストとして、提供され得る。別の実施例において、ユーザは、フィード追跡アップデートがどのように表示されるべきか、及び/又は、フィード追跡アップデートがユーザにどのように送られるべきかを指定することができる。例えば、ユーザは、テキストのフォント、フィードを選択及び表示できる場所の位置、表示されるテキストの量、並びに表示される他のテキスト又は記号(例えば、重要度フラグ)を指定することができる。
図4は、いくつかの実施例に従ってレコードに対するアップデートを追跡するための方法を実行するデータベースシステム構成400のコンポーネントの例のブロック図を示している。データベースシステム構成400は、方法300の実施例及び本明細書で説明される他の方法の実施例を実行し得る。
第1のユーザ405は、データベースシステム416内のレコード425をアップデートするリクエスト1を送る。アップデートリクエストについて説明されるが、追跡されている他のイベントにも等しく適用可能である。様々な実施例において、リクエスト1は、ユーザインタフェース(例えば、図1Bの30)又はアプリケーションプログラムインタフェース(例えば、API32)を介して送信され得る。I/Oポート420は、任意の入力インタフェースを介したリクエスト1の信号を受け入れ、その信号を1以上のプロセッサ417に送信することができる。プロセッサ417は、リクエストを解析して、実行すべきオペレーションを判別することができる。本明細書において、プロセッサ417へのいかなる言及も、集合的にプロセッサ417と呼ばれ得る、データベースシステム416内の特定のプロセッサ又はプロセッサの任意のセットに対するものであり得る。
プロセッサ417は、レコード425の識別子を判別して、リクエストの新たなデータ2を含むコマンドを、レコード425をアップデートするレコードデータベース412に送信することができる。一実施例において、レコードデータベース412は、図1Bのテナントストレージスペース112が配置されている場所にある。リクエスト1及び新たなデータコマンド2が、単一のライトトランザクションにカプセル化され、レコードデータベース412に送信され得る。一実施例において、データベース内のレコードに対する複数の変更が、単一のライトトランザクションでなされ得る。
プロセッサ417はまた、リクエスト1を解析して、フィード追跡アップデートが作成されるべきであるかどうかを判定することができる。この判定は、この時点において、イベント(例えば、特定のフィールドに対する変更)が追跡されるべきであるかどうかを判定することを含み得る。この判定は、レコードデータベース412及び/又は他のデータベースとのインタラクション(すなわち、データの交換)に基づいてもよいし、プロセッサ417においてローカルに記憶された(例えば、キャッシュ又はRAMに記憶された)情報に基づいてもよい。一実施例において、追跡されているレコードタイプのリストが記憶され得る。このリストは、テナントごとに異なり得る。というのは、例えば、各テナントは、自身の仕様に合わせてデータベースシステムを構成し得るからである。したがって、レコード425が、追跡されているタイプのものではない場合、フィード追跡アップデートを作成すべきかどうかの判定は、ここで終了し得る。
同じリスト又は第2のリスト(同じ位置又は異なる位置に記憶され得る)はまた、第1のリスト内のレコードタイプのために追跡されるフィールド及び/又はイベントを含み得る。このリストは、イベントが追跡されているかどうかを判定するために検索される。リストはまた、追跡されるべき特定のレコードをリストする粒度(granularity)を有する情報を含み得る(例えば、テナントが、タイプそのものではない、追跡されるべき特定のレコードを指定できるかどうか)。
一例として、プロセッサ417は、おそらくはテナント識別子とともに、(例えば、リクエスト1又はデータベース412から、)レコード425に関連付けられた識別子を取得し、その識別子とフィード追跡アップデートが作成されるべきレコードのリストとを相互参照することができる。詳細には、このレコード識別子は、レコードタイプを判別するために使用され得、追跡されるタイプのリストが、照合のために検索され得る。特定のレコードはまた、そのような個別のレコード追跡が有効にされたかどうかチェックされ得る。変更されるフィールドの名前が、追跡が有効にされたフィールドのリストを検索するために使用され得る。フィールド及びイベントに加えて、例えばフィールドにおける変更のタイプといった他の基準が、フィード追跡アップデートが作成されるかどうかを判定するために使用され得る。フィード追跡アップデートが生成されるべきである場合、プロセッサ417は、フィード追跡アップデートを生成することができる。
いくつかの実施例において、フィード追跡アップデートは、フィード(例えば、レコード425のエンティティフィード)がリクエストされたときに動的に作成される。したがって、一実施例において、フィード追跡アップデートは、ユーザがレコード425のエンティティフィードをリクエストしたときに作成され得る。この実施例において、フィード追跡アップデートは、再作成を含め、エンティティフィードが任意のユーザに対して表示されるときに作成され得る(例えば、アセンブルされ得る)。一実施例において、1以上のイベント履歴テーブルは、フィード追跡アップデートが再作成され得るように、以前のイベントを追跡することができる。
別の実施例において、フィード追跡アップデートは、イベントが発生したときに作成され得、そのフィード追跡アップデートは、フィード項目のリストに追加され得る。フィード項目のリストは、レコード425に固有であってもよいし、多くのレコード用のフィード項目を含む、フィード項目の集約であってもよい。そのような集約リストは、レコード425のエンティティフィード用のフィード項目が容易に取得され得るように、レコード識別子を含み得る。例えば、フィード追跡アップデートが生成された後、プロセッサ417は、新たなフィード追跡アップデート3を、レコード425のフィードに追加することができる。上述したように、一実施例において、フィードは、レコード425のフィールドに(例えば子オブジェクトとして)記憶され得る。別の実施例において、フィードは、別の位置又は別のデータベースに記憶されてもよいが、その場合、レコード425へのリンク(例えば、コネクション識別子)を伴って記憶される。フィードは、例えば、リンク付きリスト(linked list)、配列、又は他のデータ構造として、様々な形で編成され得る。
第2のユーザ430は、様々な方法により、新たなフィード追跡アップデート3にアクセスすることができる。一実施例において、第2のユーザ430は、レコードフィードを求めるリクエスト4を送ることができる。例えば、第2のユーザ430は、(例えば、クエリを用いて、あるいはブラウジングにより)レコード425のホームページ(詳細ページ)にアクセスし、そのページ上のタブ、ボタン、又は他のアクティベーションオブジェクト(activation object)を介してフィードを取得することができる。
別の実施例において、プロセッサ417は、新たなフィード追跡アップデート5を、レコード425をフォローしているユーザのフィード(例えば、ニュースフィード)に追加することができる。一実施例において、プロセッサ417は、フォロワとして登録されているユーザのリストにアクセスすることにより、レコード425のフォロワの各々を判別することができる。この判別は、新たなイベント(例えば、アップデート1)ごとになされ得る。別の実施例において、プロセッサ417は、新たなフィード追跡アップデート(又は、他のフィード項目)が利用可能であるときを判定するために、(例えば、クエリを用いて)第2のユーザ430がフォローしているレコードをポーリングすることができる。プロセッサ417は、第2のユーザ430がフォローしているレコードのリストを含み得る、第2のユーザ430のフォロワプロフィール435を使用することができる。そのようなリストは、データベースの他の部分に含まれてもよい。その後、第2のユーザ430は、新たなフィード追跡アップデートを含むフィードを取得するために、リクエスト6を自分のプロフィール435に送ることができる。ユーザのプロフィール435は、データベース412と同じであっても異なってもよいプロフィールデータベース414に記憶され得る。
いくつかの実施例において、ユーザは、最大数に制限され得る、様々なレコードからの新たなフィード追跡アップデートを含むようにニュースフィードを定義することができる。一実施例において、各ユーザは1つのニュースフィードを有する。別の実施例において、フォロワプロフィール435は、フィードに加えて、(どのフィード追跡アップデートが提供されるべきであるかと、そのようなフィード追跡アップデートがどのように表示されるかと、に関する基準を含む、)フォローされるレコードの各々の仕様を含み得る。
いくつかの実施例は、様々なタイプのレコード(エンティティ)フィードを提供することができる。エンティティフィードは、取引先、商談、案件、及び連絡先のようなレコードタイプについて存在し得る。エンティティフィードは、特定のレコード又はその関連レコードに対して人々が取ったアクションについてユーザに知らせることができる。エンティティフィードは、誰がアクションを行ったか、どのフィールドが変更されたか、並びに、古い値及び新たな値を含み得る。一実施例において、エンティティフィードは、特定のレコードにリンクされているリストとして、全てのサポートされるレコードについて存在し得る。例えば、フィードは、リスト(例えば、リンク付きリスト)を許容するフィールドに、あるいは子オブジェクトとして記憶され得る。
IV.ユーザのアクションの追跡
特定のレコードに関連付けられたイベントについて知ることに加えて、ユーザが、特定のユーザが行っていることを知ることは有用であり得る。特に、ユーザがフィード追跡アップデートを生成する必要なく(例えば、ユーザが行ったことの概要を送ることなく)ユーザが行っていることを知ることは有用であり得る。したがって、実施例は、イベントをトリガするユーザのアクションを自動的に追跡することができ、フィード追跡アップデートが、所定のイベントに関して生成され得る。
図5は、いくつかの実施例に従って実行される、データベースシステムのユーザのアクションを追跡するための方法500の一例のフローチャートを示している。方法500は、方法300に加えて実行され得る。ブロックの順番を含め、方法300のオペレーションは、方法500及び本明細書で説明される他の方法と組み合わせて実行され得る。したがって、フィードは、レコードに対する変更とユーザのアクションとから構成され得る。
ブロック510において、データベースシステム(例えば、図1A及び図1Bの16)は、第1のユーザのアクションを識別する。一実施例において、このアクションはイベントをトリガし、このイベントが識別される。例えば、レコードに対するアップデートをリクエストするユーザのアクションが識別され得る。ここで、イベントは、リクエストを受信すること、又は、レコードの結果として生じるアップデートである。したがって、アクションは、結果として生じるイベントにより定義され得る。別の実施例において、所定のタイプのアクション(イベント)のみが識別される。どのアクションが識別されるかは、デフォルトとして設定されてもよいし、テナントにより設定可能であってもよいし、さらにはユーザレベルで設定可能であってもよい。このように、いくつかのアクションしか識別されないので、処理労力を低減させることができる。
ブロック520において、イベントがフィード追跡アップデートの対象であるかどうかが判定される。一実施例において、所定のアクションのみが識別されるように、(例えば、本明細書で説明される)イベントの予め定められたリストが作成され得る。一実施例において、テナントの管理者(又は、他のユーザ)は、フィード追跡アップデートが生成されるべきアクション(イベント)のタイプを指定することができる。このブロックは、方法300のためにも実行され得る。
ブロック530において、アクションについてのフィード追跡アップデートが生成される。一例において、アクションがレコードのアップデートである場合、フィード追跡アップデートは、そのレコードに関して作成されるフィード追跡アップデートと同様又は同一であり得る。記載は、レコードではなくユーザにフォーカスするよう変更され得る。例えば、「an opportunity has been closed for account XYX(商談は、取引先XYZに関してクローズされた)」ではなく、「John D. has closed a new opportunity for account XYX(John D.は、取引先XYZに関して新たな商談をクローズした)」といったようにである。
ブロック540において、例えば、第1のユーザが、ブラウザプログラムにおいてプロフィールフィードを表示するページを開くためのタブをクリックしたときに、フィード追跡アップデートが、第1のユーザのプロフィールフィードに追加される。一実施例において、特定のユーザ用のフィードは、レコードフィードがレコードの詳細ページ上でアクセスされ得るのと同様、ユーザのプロフィールのページ上でアクセスされ得る。別の実施例において、第1のユーザは、プロフィールフィードを有していないことがあり、フィード追跡アップデートは、進む前に一時的に記憶されるだけでよい。ユーザのプロフィールフィードは、ユーザのプロフィールに関連付けられて記憶され得る。このプロフィールフィードは、別のユーザのニュースフィードに追加され得る。
ブロック550において、第1のユーザのフォロワが識別される。一実施例において、ユーザは、他のユーザがフォローできるアクションのタイプを指定することができる。同様に、一実施例において、フォロワは、このフォロワがフォローしたいと望むユーザによるアクションを選択することができる。一実施例において、異なるフォロワが、異なるタイプのアクションをフォローする場合、どのユーザが、そのユーザ及び特定のアクションのフォロワであるかが、例えば、どのアクション及び基準が特定のユーザによりフォローされているかを追跡する様々なリストを用いて識別され得る。様々な実施例において、第1のユーザのフォロワは、ブロック350に関して上述したレコードのフォロワと同様に識別され得る。
ブロック560において、例えば、第1のユーザの各フォロワが、ニュースフィードを表示するページを開くためのタブをクリックしたときに、フィード追跡アップデートが、第1のユーザの各フォロワのニュースフィードに追加される。フィード追跡アップデートは、レコードフィードのフィード項目と同様に追加され得る。ニュースフィードは、ユーザ及びレコード両方についてのフィード追跡アップデートを含み得る。別の実施例において、ユーザは、このユーザがフォローしているユーザについて受信すべきフィード追跡アップデートの種類を指定することができる。例えば、ユーザは、特定のキーワードを含むフィード追跡アップデート、所定のタイプのレコードのフィード追跡アップデート、所定のユーザにより所有又は作成されたレコードのフィード追跡アップデート、特定のフィールド、及び、本明細書に記載される他の基準を指定することができる。
ブロック570において、フォロワは、ニュースフィードにアクセスして、フィード追跡アップデートを閲覧する。一実施例において、ユーザは、このユーザがフォローしているレコードの全てに対する1つのニュースフィードのみを有する。別の実施例において、ユーザは、データベースシステムへのインタフェースのページ上で特定のタブ又は他のオブジェクトを選択することにより、自分のフィード(すなわち、自分のアクションについてのフィード)にアクセスすることができる。したがって、フィードは、他のユーザがデータベースシステムにおいて行っていることについてのフィード追跡アップデートを含み得る。ユーザが、別のユーザの関連するアクションを認識すると、そのユーザは、同僚に連絡を取ることができ、それにより、チームワークを高めることができる。
V.フィード追跡アップデートの生成
上述したように、いくつかの実施例は、レコードに関して発生したイベント(例えば、アップデート)、及び、ユーザによる、イベントをトリガするアクションを説明するテキストを生成することができる。データベースシステムは、様々な方法により、様々なイベントのためのフィード追跡アップデートを生成するよう構成され得る。
一実施例において、フィード追跡アップデートは文章(grammatical sentence)であり、これにより、人は容易に理解することができる。別の実施例において、フィード追跡アップデートは、アップデートについての詳細な情報を提供する。様々な例において、フィールドの古い値及び新たな値が、フィード追跡アップデートに含まれ得、アップデートに関するアクションが提供され得(例えば、承認のために送信)、フィード追跡アップデートに応答する責任を担う、あるいはフィード追跡アップデートに従って行動する責任を担う特定のユーザの名前も提供され得る。フィード追跡アップデートはまた、管理者、アップデートをリクエストしている特定のユーザ、又はフィード追跡アップデートを受け取るフォローしているユーザにより選択された設定に基づく重要度のレベル、どのフィールドがアップデートされているか、フィールドにおける変化のパーセンテージ、イベントのタイプ、又はこれらのファクタの任意の組合せを有し得る。
システムは、イベント(例えば、アップデートするリクエスト)からフィード追跡アップデートを作成するためのヒューリスティックのセットを有することができる。例えば、主語は、ユーザ、レコード、又は、追加若しくは変更されているフィールドであり得る。動詞は、ユーザによりリクエストされたアクションに基づき得、(デフォルトとして、あるいは、テナントの管理者による入力として提供され得る)動詞のリストから選択され得る。一実施例において、フィード追跡アップデートは、フォーマット制限(formatting restriction)を有する汎用コンテナ(generic container)であり得る。
新たなレコードの作成のためのフィード追跡アップデートの一例として、「Mark Abramowitz created a new Opportunity for IBM- 20,000 laptops with Amount as $3.5M and Sam Palmisano as Decision Maker(Mark Abramowitzは、$3.5Mである総額と、意思決定者であるSam Palmisanoと、を含む、IBMの20000個のラップトップに関する新たな商談を作成した)」を考える。このイベントは、Mark Abramowitz用のプロフィールフィードと、IBMの20000個のラップトップに関する商談のレコード用のエンティティフィールドと、にポストされ得る。パターンは、新たな(ObjectName)(RecordName) with [ (FieldName) as (FieldValue) [, / and] ]* [ [added / changed / removed] (RelatedListRecordName) [as / to / as] (RelatedListRecordValue) [, / and] ]*を作成した(AgentFullName)により与えられ得る。同様のパターンが、変更されたフィールド(標準又はカスタム)と、関連リストに追加された子レコードと、に関して形成され得る。
VI.ユーザからのコメント又はユーザについてのコメントの追跡
いくつかの実施例はまた、データベースシステムがフィード追跡アップデートを生成する代わりに、ユーザ送信テキストを有することができる。このテキストは、メッセージの一部又は全てとしてユーザにより送られるので、このテキストは任意のトピックに関するものであり得る。したがって、ユーザのアクション及びレコードのイベントのみよりも詳細な情報が伝えられ得る。一実施例において、メッセージを使用して、特定のレコードについて質問することができ、そのレコードをフォローしているユーザは、コメント及び応答を提供することができる。
図6は、いくつかの実施例に従って実行される、レコード又は別のユーザについてユーザにより作成されたメッセージからニュースフィードを作成するための方法600の一例のフローチャートを示している。一実施例において、方法600は、方法300及び方法500と組み合わせることができる。一態様において、第1のユーザがメッセージ(例えば、レコード又は別のユーザについてのポスト又はコメント)を作成した場合、このメッセージが、第1のユーザに関連付けられ得る。別の態様において、メッセージが第1のユーザについてのものである場合(例えば、別のユーザにより第1のユーザのプロフィールフィード上にポストされた場合)、このメッセージが、第1のユーザに関連付けられ得る。
ブロック610において、データベースシステムは、第1のユーザに関連付けられたメッセージ(例えば、ポスト又はステータスアップデート)を受信する。このメッセージ(例えば、ポスト又はステータスアップデート)は、別のユーザ又は第1のユーザにより送られたテキスト及び/又はマルチメディアコンテンツを含み得る。一実施例において、ポストは、任意のユーザがポストを追加でき複数のポストが存在し得る、第1のユーザのプロフィールページのセクションに対するものである。したがって、ポストは、第1のユーザのプロフィールページ上に現れ得、第1のユーザのプロフィールに訪れたときに閲覧され得る。レコードについてのメッセージの場合、ポストは、レコードの詳細ページ上に現れ得る。メッセージは、他のフィード内に現れてもよいことに留意されたい。別の実施例において、第1のユーザについてのステータスアップデートは、第1のユーザのみにより追加され得る。一実施例において、ユーザは、1つのステータスメッセージのみ有することができる。
ブロック620において、以下でより詳細に説明されるように、メッセージがテーブルに追加される。フィードが開かれるとき、クエリは、1以上のテーブルをフィルタリングして、第1のユーザを識別し、ユーザがフォローしている他の人を識別し、メッセージを取得する。メッセージ及びレコードアップデートは、フィードとして結合されたリスト内に提供される。このように、一実施例において、メッセージは、第1のユーザのプロフィールに(例えば関連リストとして)関連付けられている、第1のユーザのプロフィールフィードに追加され得る。一実施例において、ポストは無制限にリストされる。別の実施例において、直近のポスト(例えば、直近の50個)のみが、プロフィールフィード内に保持される。このような実施例はまた、フィード追跡アップデートとともに使用されてもよい。さらに別の実施例において、メッセージは、このメッセージを追加したユーザのプロフィールに追加され得る。
ブロック630において、データベースシステムは、第1のユーザのフォロワを識別する。一実施例において、データベースシステムは、方法500に関して上述したようにフォロワを識別することができる。様々な実施例において、フォロワは、第1のユーザのアクションに関するフィード、第1のユーザについてのメッセージに関するフィード、又はこれら両方に関するフィード(同一のフィードであることが可能)をフォローすることを選択することができる。
ブロック640において、メッセージが、各フォロワのニュースフィードに追加される。一実施例において、メッセージが何らかの基準に合致する場合、例えば、メッセージが特定のキーワード又は他の基準を含む場合、メッセージは、特定のフォロワのニュースフィードにのみ追加される。別の実施例において、メッセージは、このメッセージを作成したユーザにより削除され得る。一実施例において、メッセージが作成者により削除されると、このメッセージは、このメッセージが追加された全てのフィードから削除される。
ブロック650において、フォロワは、ニュースフィードにアクセスして、メッセージを閲覧する。例えば、フォロワは、フォロワ自身のプロフィールページ上でニュースフィードにアクセスすることができる。別の例として、フォロワは、最初にホームページに行く必要のない、フォロワ自身のデスクトップに送られたニュースフィードを有することができる。
ブロック660において、データベースシステムは、メッセージについてのコメントを受信する。データベースシステムは、元のメッセージが追加されたのと同様に、このコメントを同じ第1のユーザのフィードに追加することができる。一実施例において、コメントはまた、このコメントを追加した第2のユーザのフィードにも追加され得る。一実施例において、ユーザはまた、コメントに返信することもできる。別の実施例において、ユーザは、コメントをフィード追跡アップデートに追加することができ、さらなるコメントが、フィード追跡アップデートに関連付けられ得る。さらに別の実施例において、コメント又はメッセージを作成することは、フィード追跡アップデートが作成されるアクションではない。したがって、このメッセージは、そのようなアクションから作成される唯一のフィード項目であり得る。
一実施例において、フィード追跡アップデート又はポストが削除される場合、その対応するコメントも削除される。別の実施例において、フィード追跡アップデート又はポストに対する新たなコメントは、フィード追跡アップデートのタイムスタンプをアップデートしない。また、指定された時間枠内に(例えば、前週内に)コメントがあった場合、フィード追跡アップデート又はポストは、フィード(プロフィールフィード、レコードフィード、又はニュースフィード)内に表示され続けられ得る。そうでなければ、一実施例において、フィード追跡アップデート又はポストは削除され得る。
いくつかの実施例において、全ての又はほとんどのフィード追跡アップデートに対して、コメントすることができる。他の実施例において、所定のレコード(例えば、案件又はアイディア)のフィード追跡アップデートに対しては、コメントすることができない。様々な実施例において、商談、取引先、連絡先、リード、及びカスタムオブジェクトの任意の1以上のレコードに対して、コメントを作成することができる。
ブロック670において、コメントが、各フォロワのニュースフィードに追加される。一実施例において、ユーザは、このユーザのニュースフィード内でコメントを作成することができる。そのようなコメントは、適切なプロフィールフィード又はレコードフィードに伝播し得、次いで、フォローしているユーザのニュースフィードに伝播し得る。したがって、フィードは、人が行っていることに加えて、人が話していることも含み得る。一態様において、フィードは、(例えば、ユーザ、商談等について)最新であり続けるための手段であるとともに、同僚/パートナと連絡を取り合って、共通の目標に向かって同僚/パートナを引き込むための好機である。
いくつかの実施例において、ユーザは、フィード追跡アップデート及び/又はメッセージ(コメントを含む)をランク付けすることができる。ユーザは、より高くランク付けされたフィード項目がディスプレイのより上の方に現れるように、フィードの表示の優先順位を付けることを選択することができる。例えば、一実施例において、コメントが特定の質問に対する回答である場合、ユーザは、最良の回答が識別され得るように、様々なステータスポストをランク付けすることができる。別の例として、最も重要なフィード項目がリストの一番上に表示され得るので、ユーザは、最も重要なフィード項目を迅速に識別することができる。フィード項目の順番は、(いくつかは本明細書において説明される様々なファクタを用いてデータベースシステムにより決定され得る)重要度レベルと、ユーザからのレーティングと、に基づき得る。一実施例において、このレーティングは、少なくとも3つの値を含む。別の実施例において、このレーティングは、2値に基づく。
ユーザのプロフィールに加えて、グループも作成され得る。様々な実施例において、グループは、ユーザらに共通する所定の属性に基づいて作成されてもよいし、ユーザを招待することにより作成されてもよいし、且つ/あるいは、ユーザから参加のリクエストを受信することにより作成されてもよい。一実施例において、グループフィードが作成され得、誰かが適切なユーザインタフェースを介してグループ全体にメッセージを送ったときに、メッセージがグループフィードに追加される。例えば、グループページは、グループフィード、又はグループフィード内のポスト用のセクションを有することができ、ユーザは、「共有(Share)」ボタン又は同様のボタンをクリックすることにより、ユーザインタフェース内のパブリッシャコンポーネントを介してポストを送ることができる。別の実施例において、メンバのうちのいずれか1人についてのメッセージが送信されたとき、そのメッセージがグループフィードに追加され得る。また、グループフィードは、グループ全体のアクション(例えば、管理者が、グループプロフィール内のデータ又はグループにより所有されているレコードを変更すること)についてのフィード追跡アップデート、又は、個々のメンバのアクションについてのフィード追跡アップデートを含み得る。
図7は、いくつかの実施例に従った、グループページ上のグループフィードの一例を示している。図示されるように、フィード項目710は、ユーザが文書をグループオブジェクトにポストしたことを示している。テキスト「Bill Bauer has posted the document Competitive Insights(Bill Bauerは、文書Competitive Insightsをポストした)」は、変更されたレコードについてのフィード追跡アップデートと同様に、データベースシステムにより生成され得る。フィード項目720は、グループへのポストとともに、Ella Johnson、James Saxon、Mary Moore、及びBill Bauerからのコメント730を示している。
図8は、いくつかの実施例に従った、フィード追跡アップデート、ポスト、及びコメントを含むレコードフィードの一例を示している。フィード項目810は、承認のためにディスカウントを送ったというイベントに基づくフィード追跡アップデートを示している。他のフィード項目は、例えば、Bill Bauerからの、レコードに対してなされたポストと、例えば、Erica Law及びJake Rappからの、ポストに対してなされたコメントと、を示している。
VII.フィードのためのインフラストラクチャ
A.フィードを作成するために使用されるテーブル
図9Aは、いくつかの実施例に従ってイベントを追跡しフィードを作成する際に使用され得る複数のフィード追跡アップデートテーブルの例を示している。図9Aのテーブルにおいて、フィード項目が作成される、あるいはフィード項目に対応する、データベースにおけるイベントを追跡することの一部として、エントリが追加され得る、あるいはエントリが潜在的に削除され得る。一実施例において、各テナントは、各テナントにより提供される基準に基づいて作成されるテーブルの独自のセットを有する。
イベント履歴テーブル910は、フィード項目が作成されるイベントのフィード追跡アップデートを提供することができる。一態様において、イベントは、追跡されているオブジェクトに対するものである。したがって、テーブル910は、フィードのためのフィード追跡アップデートを記憶及び変更することができ、この変更が維持され得る。様々な実施例において、イベント履歴テーブル910は、イベントID911の列、オブジェクトID912(親IDとも呼ばれる)の列、及びクリエイテッドバイID(created by ID)913の列を有することができる。イベントID911は、特定のイベントを一意に識別することができ、1(又は、他の数字若しくは値)で始まり得る。
新たなイベントの各々は、順番にインクリメントされ得る新たなイベントIDを用いて時系列に追加され得る。オブジェクトID912は、どのレコード又はユーザのプロフィールが変更されているかを追跡するために使用され得る。例えば、オブジェクトIDは、フィールドが変更されたレコード又はフィードがポストを受け入れたユーザに対応し得る。クリエイテッドバイID913は、イベントをもたらすアクションを実行しているユーザ、例えば、フィールドを変更している、あるいは別のユーザのプロフィールにメッセージをポストしているユーザを追跡することができる。
一実施例において、イベントの名前もテーブル910に記憶され得る。一実施例において、テナントは、追跡されることが望まれるイベントを指定することができる。一実施例において、イベント履歴テーブル910は、変更されたフィールド(例えば、古い値及び新たな値)の名前を含み得る。別の実施例において、フィールドの名前、及び値は、別のテーブルに記憶される。イベントについての他の情報(例えば、フィード追跡アップデート、ポスト、ステータスアップデート、又はコメントのテキスト)は、イベント履歴テーブル910に記憶されてもよいし、これより説明される他のテーブルに記憶されてもよい。
フィールド変更テーブル920は、フィールドに対する変更のフィード追跡アップデートを提供することができる。テーブル920の列は、イベントID921(イベントID911に関連付けられる)、フィールドの古い値922、及びフィールドの新たな値923を含み得る。一実施例において、イベントが、2以上のフィールド値を変更する場合、変更されるフィールドごとにエントリが存在し得る。図示されるように、イベントID921は、イベントE37について2つのエントリを有する。
コメントテーブル930は、例えば、ポストに対するコメント又はフィールド値の変更に対するコメントといった、イベントに関して作成されたコメントのフィード追跡アップデートを提供することができる。テーブル930の列は、イベントID931(イベントID911に関連付けられる)、コメントのテキストを記憶するコメント列932、及びコメントの時間/日付933を含み得る。一実施例において、各イベントに対して複数のコメントが存在し得る。図示されるように、イベントID931は、イベントE37について2つのエントリを有する。
ユーザサブスクリプションテーブル940は、ユーザによりフォローされている(ユーザにサブスクライブされている)オブジェクトのリストを提供することができる。一実施例において、各エントリは、フォローしているユーザのユーザID941と、フォローされているオブジェクトに対応する1つのオブジェクトID942と、を有する。一実施例において、フォローされているオブジェクトは、レコード又はユーザであり得る。図示されるように、ID U819を有するユーザは、オブジェクトID O615及びオブジェクトID O489をフォローしている。ユーザU819が、他のオブジェクトをフォローしている場合、ユーザU819に関してさらなるエントリが存在し得る。さらに図示されるように、ユーザU719もオブジェクトO615をフォローしている。ユーザサブスクリプションテーブル940は、ユーザが、フォローされるオブジェクトを追加したとき、又は、ユーザが、フォローされているオブジェクトを削除したときに、アップデートされ得る。
一実施例において、プロフィールフィード及びニュースフィードに関して、これらは、これらのフィードタイプに合わせて特殊化された、イベント履歴テーブル910上の読み取り専用ビュー(real-only view)である。概念的には、ニュースフィードは、ユーザのための、ユーザサブスクリプションテーブル940のオブジェクトID942と、イベント履歴テーブル910のオブジェクトID912と、の間の半結合(semi-join)であり得る。一態様において、これらのエンティティは、多態的な親(polymorphic parent)を有し得、例えば、共用チェック(sharing check)のコストを制限するため等といった、本明細書で詳述される複数の制限を受け得る。
一実施例において、エンティティフィードは、エンティティ関連フィード(feed associate entity)(例えば、取引先フィード(AccountFeed)、案件フィード(CaseFeed)等)として、APIにおいてモデル化される。エンティティ関連フィードは、1つの特定のレコードタイプのみのためのイベント(例えば、イベントID)から構成される情報を含む。このようなリストは、クエリ(及び、共用チェック)を特定のレコードタイプに制限し得る。一態様において、エンティティフィードをこのように構造化することにより、クエリをより速く実行させることができる。例えば、特定の取引先のフィードを求めるリクエストは、取引先のレコードタイプを含み得る。一実施例において、取引先レコードIDと、対応するイベントID、又は、イベント履歴テーブル910内の特定のイベントエントリに対するポインタと、を有する取引先フィードテーブルが、次いで検索され得る。取引先フィードテーブルは、レコードのうちの一部(全てではない)しか含まないので、クエリがより速く実行され得る。
一実施例において、レコードが追跡されているとしても、イベント履歴テーブル910内にリストされたイベントを有さないオブジェクトが存在することがある。この場合、データベースサービスは、フィード項目が存在しないことを示す結果を返すことができる。
フィード項目は、レコードの個々のフィールド変更、レコードの作成及び削除、又は、レコード若しくはユーザに関して追跡されている他のイベントを表すことができる。一実施例において、単一のトランザクション(イベント)におけるフィード項目の全てが、一緒にグループ化され得、同じイベントIDを有し得る。単一のトランザクションは、データベースとの1回の通信において実行され得るオペレーションに関連する。別の実施例において、フィードがデータベースのオブジェクトである場合、フィード項目は、プロフィールフィード、ニュースフィード、又はエンティティフィードの子であり得る。フィード項目が複数のフィードに追加される場合、そのフィード項目は、そのフィード項目が追加される各フィードの子として複製され得る。
いくつかの実施例において、コメントは、フィード追跡アップデート、ポスト、ステータスアップデート、及び他の項目に従属する項目として存在する。これらフィード追跡アップデート、ポスト、ステータスアップデート、及び他の項目は、互いから独立している。したがって、フィードコメントオブジェクトは、フィード項目オブジェクトの子オブジェクトとして存在し得る。例えば、コメントテーブル930は、イベント履歴テーブル910の子テーブルとみなすことができる。一実施例において、フィードコメントは、他のフィード項目から分離される、プロフィールフィード、ニュースフィード、又はエンティティフィードの子であり得る。
一実施例において、フィードを閲覧することは、直近のメッセージ又はフィード追跡アップデート(例えば、25個)を引き出して(pull up)、各フィード項目についての直近の(例えば、4個の)コメントを検索する。コメントは、コメントテーブル930を介して識別され得る。一実施例において、ユーザは、例えば、「see more link(より多くのリンクを見る)」を選択することにより、より多くのコメントを見ることをリクエストすることができる。
フィード項目が生成された後、特定のテナント及び/又はユーザに合わせて調整され得る所定のフィード項目のみが表示されるように、フィード項目はフィルタリングされ得る。一実施例において、ユーザは、例えば、このユーザに対して直接的に表示されるニュースフィード、又は、さらにはエンティティフィードといった、このユーザに対して表示されるフィード内にフィード項目が現れるための所定の基準を満たす、フィールドに対する変更を指定することができる。一実施例において、この基準は、どのフィード項目を表示するかを決定するための他のファクタ(例えば、フィード内のフィード項目の数)と組み合わせられ得る。例えば、(例えば、閾値未満の)少数のフィード項目が存在する場合、これらフィード項目の全てが表示され得る。
一実施例において、ユーザは、自分のニュースフィード内のフィード項目に対するクエリを介して、この基準を指定することができる。したがって、フィードは、所定のタイプのオブジェクト、所定のタイプのイベント、所定のフィールドについてのフィード追跡アップデート、及び本明細書に記載される他の基準のみを返し得る。メッセージもまた、クエリにおいて指定され得る何らかの基準に従ってフィルタリングされ得る。そのような追加クエリが、ユーザのためのニュースフィードを作成するために使用される標準クエリに追加され得る。第1のユーザは、このように第1のユーザがフォローしているユーザ及びレコードを指定することができるのに加えて、第1のユーザがフォローしたいと望む特定のフィード項目を識別することができる。クエリは、グラフィカルインタフェースを介して作成され得る、あるいは、ユーザにより直接的にクエリ言語で追加され得る。他の基準は、他のフィード項目ではなく、特定のユーザ又はレコードを対象とするポストのみを受け取ることを含み得る。
一実施例において、ユーザは、このユーザがレコードにアクセスすることができる場合、このレコードのフィードにアクセスすることができる。ユーザがレコードにアクセスできるかどうかを判定するためのセキュリティルールが、様々な方法により実行され得る。それらの方法のうちのいくつかは、Weissmanらによる「METHODS AND SYSTEMS FOR CONTROLLING ACCESS TO CUSTOM OBJECTS IN A DATABASE」と題された2012年1月10日に発行された同一出願人による米国特許第8095531号に記載されており、これは、その全体を参照することにより、全ての目的のために、本明細書に組み込まれる。
一実施例において、ユーザは、このユーザがレコードにアクセスすることができる場合、例えば、フィード項目を削除又は編集する等、このレコードのフィードを編集することができる。別の実施例において、(管理者に加えて)ユーザは、フィード項目が作成され得るアクションを実行することを除いて、フィード項目を編集することができない。一例において、ユーザは、まず、このユーザのアクションに基づいて作成されるべきフィード項目の特定のレコード及びフィールドにアクセスしなければならない。この場合、管理者は、MODIFY-ALL-DATAセキュリティレベル(全てのデータを変更するセキュリティレベル)を有するユーザであるとみなすことができる。さらに別の実施例において、レコードを作成したユーザは、フィードを編集することができる。
一実施例において、ポストのテキストは、イベント履歴テーブル910と相互参照され得る子テーブル(ポストテーブル950)に記憶される。ポストテーブル950は、(イベントID911と相互参照するための)イベントID951、ポストのテキストを記憶するためのポストテキスト952、及び時間/日付953を含み得る。ポストテーブル950内のエントリは、フィードポストオブジェクトとみなすことができる。
VIII.フォローするユーザ及びレコードに対するサブスクライブ
上述したように、ユーザは、ユーザ、グループ、及びレコードをフォローすることができる。実施例は、ユーザが、このユーザが現在フォローしているどのユーザ、グループ、及びレコードを管理するための機構を提供することができる。一実施例において、ユーザは、このユーザがフォローできるユーザ及びレコードの数(集合的又は個別的)に制限され得る。例えば、ユーザは、10人のユーザ及び15個のレコードのみをフォローするよう制限され得る、あるいは、別の例として、計25のみをフォローするよう制限され得る。代替的に、ユーザは、より多くのユーザ又はより少ないユーザをフォローすることが許可されてもよい。
一実施例において、ユーザは、レコードのページに行き、次いで、(例えば、「フォロー(follow)」又は「参加(join)」と記されたボタンにより、)オブジェクトをフォローすることを選択することができる。別の実施例において、ユーザは、レコードを検索して、合致するレコードをリスト内に表示させることができる。この検索は、ユーザがフォローしたいと望み得るレコードの基準を含み得る。このような基準は、所有者、作成日、最終コメント日、及び特定のフィールドの数値(例えば、10000ドル以上の値を有する商談)を含み得る。
次いで、フォローボタン(又は、他のアクティベーションオブジェクト)が、結果として生じるリスト内の各レコードの横に提供され得、レコードをフォローすることを開始するために、フォローボタンが選択され得る。同様に、ユーザは、ユーザのプロフィールページに行き、ユーザをフォローすることを選択することができる、あるいは、ユーザの検索が、リストを提供し得、1人以上のユーザが、フォローするために、このリストから選択され得る。サブスクライブ及びサブスクライブ解除(unsubscribing)の選択は、テーブル920に行を追加しテーブル920から行を削除し得る。
いくつかの実施例において、サブスクリプションセンタ(subscription center)は、ユーザがサブスクライブしているどのレコードを管理し、フィード追跡アップデートにおいてユーザが閲覧したいと望むどのフィールドアップデートを管理するために、データベースアプリケーション(例えば、アプリケーションプラットフォーム18)における中央環境(centralized place)として動作する。サブスクリプションセンタは、サブスクリプションテーブルを使用して、様々なユーザのサブスクリプションを追跡することができる。一実施例において、サブスクリプションセンタは、ユーザがサブスクライブされている全ての項目(ユーザ及びレコード)のリストを示す。別の実施例において、ユーザは、サブスクリプションセンタから、サブスクライブされているオブジェクトをサブスクライブ解除することができる。
A.自動サブスクリプション
図9Bは、いくつかの実施例に従って実行される、ユーザをデータベースシステムにおけるオブジェクトに自動的にサブスクライブさせるための方法900の一例のフローチャートを示している。以下のブロックのいずれも、データベースシステムを用いて全体的又は部分的に実行され、詳細には、データベースシステムの1以上のプロセッサにより実行され得る。
ブロック901において、データベースシステムに記憶されたオブジェクトの1以上の属性(property)が受信される。この属性は、データベースシステムの管理者から受信されてもよいし、データベースシステムのユーザ(顧客組織の管理者であり得る)から受信されてもよい。この属性は、レコード又はユーザであり得、データベースシステムに記憶されているオブジェクトのフィールドのうち任意のフィールドを含み得る。レコードの属性の例は、このレコードの所有者、このレコードを、あるレコードタイプから別のレコードタイプに変換したユーザ、第1のユーザがこのレコードを閲覧したかどうか、及び第1のユーザがこのレコードを閲覧した時間を含む。ユーザの属性の例は、このユーザがどの組織(テナント)に関連付けられているか、同じ組織における第2のユーザの地位、及びこのユーザがどの他のユーザに電子メールを送ったか、あるいはこのユーザがプロジェクトにおいてどの他のユーザと一緒に取り組んでいるかを含む。
ブロック902において、データベースシステムは、どのユーザがオブジェクトを自動的にフォローすべきかについての1以上の基準を受信する。この基準の例は、レコードの所有者又は作成者が、このレコードをフォローすること、レコードの所有者又は作成者の部下が、このレコードをフォローすること、及び、ユーザが、自分のマネージャ、このユーザの同僚、このユーザと同じビジネスグループにおける他のユーザ、及び、このユーザが電子メールを送った、あるいはこのユーザがプロジェクトにおいて一緒に取り組んでいる他のユーザをフォローすることを含み得る。この基準は、ユーザ又はユーザのグループ(例えば、テナントのユーザ)に固有であり得る。
ブロック903において、データベースシステムは、オブジェクトの1以上の属性が、第1のユーザに関して1以上の基準を満たすかどうかを判定する。一実施例において、この判定は、まず基準を取得し、次いでこの基準を満たすオブジェクトを判別することにより行われ得る。この判定は、定期的に行われてもよいし、オブジェクトの作成時に行われてもよいし、他の時間に行われてもよい。
ブロック904において、基準が満たされた場合、オブジェクトが第1のユーザに関連付けられる。この関連付けは、第1のユーザによりどのオブジェクトがフォローされているかに関する情報を記憶するリスト内に存在し得る。ユーザサブスクリプションテーブル940が、このようなリストの一例である。一実施例において、1以上の基準は、1つの属性が少なくとも1つの基準を満たす場合に満たされる。したがって、基準が、ユーザが自分のマネージャをフォローすることであり、オブジェクトが、ユーザのマネージャである場合、第1のユーザは、このオブジェクトをフォローするようになる。
一実施例において、ユーザはまた、例えば、所定のアクションが生じた場合に、自動的にサブスクライブ解除され得る。このアクションは、例えば、降格又は契約者(contractor)になることといった、組織内でのユーザの地位の変化であり得る。別の例として、案件がクローズした場合、この案件をフォローしているユーザは、自動的にサブスクライブ解除され得る。
IX.フィードへの項目の追加
上述したように、フィードは、フィード項目を含み、フィード項目は、本明細書で定義されるようなフィード追跡アップデート及びメッセージを含む。様々なフィードが生成され得る。例えば、フィードは、レコード又はユーザについて生成され得る。次いで、ユーザは、このようなフィードを閲覧することができる。ユーザは、例えば、レコード又はユーザ用のホームページに行くことにより、レコード又はユーザのフィードを別々に閲覧することができる。上述したように、ユーザはまた、別のレコード又はユーザをフォローして、別々のフィードアプリケーションを通じて、このようなフィードのフィード項目を受け取ることもできる。フィードアプリケーションは、ユーザがフォローしているフィードの各々を提供することができ、いくつかの例においては、単一の情報フィード内に様々なフィードを結合することができる。
フィードジェネレータは、フィード項目(例えば、フィード追跡アップデート又はメッセージ)を生成してこのようなフィード項目をフィードに結合することができる、プロセッサ若しくは専用プロセッサ(又は、これらの組合せ)上で実行される任意のソフトウェアプログラムを指し得る。一実施例において、フィードジェネレータは、フィード追跡アップデート又はメッセージを受信し、フィード項目がどのフィードに追加されるべきであるかを識別し、フィードを追加することにより、フィード項目を生成することができる。フィードを追加することは、さらなる情報(メタデータ)をフィード追跡アップデート又はメッセージに追加すること(例えば、文書、メッセージの送信者、決定された重要度等を追加すること)を含み得る。フィードジェネレータはまた、人が(例えば、共用ルールに従って)閲覧するためにアクセスしないデータについてフィード追跡アップデートを誰も閲覧しないことを確認することをチェックすることができる。フィードジェネレータは、フィードを事前算出するために、フィードを動的に算出するために、あるいはこれらの組合せのために、様々な時間において実行され得る。
一実施例において、図4におけるプロセッサ417は、フィード追跡アップデートのための基準を満たすイベントを識別し、次いで、フィード追跡アップデートを生成することができる。プロセッサ417はまた、メッセージを識別することもできる。例えば、アプリケーションインタフェースは、メッセージを送信するための所定の機構(例えば、プロフィールページ上の「送信」ボタン、レコードの詳細ページ上の「送信」ボタン、ポスト上の「コメント」ボタン)を有することができ、これらの機構は、フィードを作成するために使用されるテーブルに追加されるべきメッセージ又は表示の準備ができているフィード項目のリストに直接追加されるべきメッセージを識別するために使用され得る。
A.事前算出されているフィードへの項目の追加
いくつかの実施例において、フィード項目のフィードは、ユーザがこのフィードをリクエストする前に作成される。そのような実施例は、高速で動作し得るが、記憶のために高い全般的コストを有する。一実施例において、プロフィールフィード又はレコードフィードが作成されると、フィード項目(メッセージ及びフィード追跡アップデート)が、このようなフィードに追加され得る。このようなフィードは、データベースシステムにおいて、関連リスト等、様々な形で存在し得る。このようなフィードは、項目を追加することに加えて項目を除去するための機構を含み得る。
上述したように、ニュースフィードは、ユーザがサブスクライブしている全てのレコードフィード及びプロフィールフィードの集約フィードであり得る。ニュースフィードは、サブスクライブしているユーザのホームページ上に提供され得る。したがって、ニュースフィードは、特定のユーザにより作成され、特定のユーザのために存在し得る。例えば、ユーザは、このユーザが関心のある所定のレコードのエンティティフィードを受け取り、関心のある人(例えば、このユーザのために働く同じチームの人はこのユーザの上司である、等)のプロフィールフィードを受け取るようサブスクライブすることができる。ニュースフィードは、(上述した)サブスクリプションセンタを介して明示的(又は暗黙的)にサブスクライブされているユーザに、全てのレコード(及び人)にわたる全てのアクションについて通知することができる。
一実施例において、フィード追跡アップデートが、ユーザがサブスクライブされている複数のエンティティにおいて公開される場合であっても、各フィード追跡アップデートの1つのインスタンスのみが、ユーザのニュースフィード上に表示される。一態様において、ニュース記事を公開する際に遅延が存在し得る。例えば、遅延は、非同期のエンティティフィード追跡アップデートの持続のためにキューされた(queued up)メッセージに起因するものであり得る。異なるフィードは、異なる遅延を有し得る(例えば、ニュースフィードの遅延はあるが、プロフィールフィード及びエンティティフィードには遅延がない)。別の実施例において、サブスクライブされているプロフィールフィード又はエンティティフィードに関する所定のフィード追跡アップデートは、ユーザが、例えば、(どのユーザがどのデータを閲覧できるかを制限する)共用ルールのために、アクセスを許可されていなので、表示されない。また、一実施例において、アップデートされたレコード(作成を含む)のデータが、フィード内に提供され得る(例えば、フィードのアップデータされた値又はファイルが、フラッシュ表現として追加され得る)。
B.フィードの動的な生成
いくつかの実施例において、フィードジェネレータは、ユーザが、例えば、プロフィールフィード、エンティティフィード、又はユーザのニュースフィードといった特定のフィードを閲覧することをリクエストしたときにフィード項目を動的に生成することができる。一実施例において、直近のフィード項目(例えば、トップ50)が最初に生成される。一態様において、他のフィード項目が、例えば、フィードを閲覧するリクエストとは同調しないバックグラウンドプロセスとして生成され得る。しかしながら、バックグラウンドプロセスは、ユーザが次の50個のフィード項目に到達する前に完了する可能性が高いので、このフィード生成は同調的と思われるかもしれない。別の態様において、直近のフィード項目は、例えば、フィード追跡アップデート又はポストに関連付けられているコメントを含む場合もあるし含まない場合もある。
一実施例において、フィードジェネレータは、表示されるフィード項目を生成するために、図9Aに示されるテーブル及び/又は必要に応じて他のテーブルの適切なサブセットをクエリすることができる。例えば、フィードジェネレータは、特定のレコードについて生じたアップデートのために、イベント履歴テーブル910をクエリすることができる。特定のレコードのIDが、レコードのIDに対して照合され得る。一実施例において、レコードの全セットに対する変更は、1つのテーブルに記憶され得る。フィードジェネレータはまた、ステータスアップデート、ポスト、及びコメントのためにもクエリすることができ、これらステータスアップデート、ポスト、及びコメントの各々は、図9Aに示されるように、レコードの異なる部分又は別個のテーブルに記憶され得る。エンティティイベント履歴テーブルに何を記録させるか(及び、何が表示されるか)は、セットアップにおけるフィード設定ページにより制御され得、これは、管理者により設定可能であり得、カスタムフィードに関して上述されている組織全体についても同じであり得る。
一実施例において、2つのフィードジェネレータが存在し得る。例えば、1つのフィードジェネレータは、レコードフィード及びプロフィールフィードを生成することができ、別のフィードジェネレータは、ニュースフィードを生成することができる。前者に関して、フィードジェネレータは、レコード又はユーザプロフィールの識別子をクエリすることができる。後者に関して、ニュースフィードジェネレータは、例えば、ユーザサブスクリプションテーブル940等、サブスクライブされているプロフィールフィード及びレコードフィードをクエリすることができる。一実施例において、フィードジェネレータは、人のサブスクリプションセンタを調べて、クエリするフィードを判別し、フィード項目のリストをユーザに返す。例えば、フィールド名若しくはID、コメントID、又は他の情報等、それぞれのテーブルのイベント番号及び値を調べることにより、このリストから重複が除去され得る。
C.フィード追跡アップデートテーブルへの情報の追加
図10は、いくつかの実施例に従って実行される、情報をフィード追跡テーブルに記録するための方法1000の一例のフローチャートを示している。一実施例において、ブロックのいくつかは、特定のイベント又はイベントの一部(例えば、アップデートの1つのフィールドのみが追跡されている)が追跡されているかどうかにかかわらず実行され得る。様々な実施例において、(ハードワイヤードの、又はプログラムされた)プロセッサ又はプロセッサのセットは、方法1000と、本明細書で説明される任意の他の方法と、を実行することができる。
ブロック1010において、イベントを示すデータが受信される。このデータは、このイベントを識別する特定の識別子を有し得る。例えば、フィールドアップデートのための特定の識別子が存在し得る。別の実施例において、トランザクションが、このイベントを識別するキーワード(例えば、クローズ、フィールド変更、又は作成オペレーションを示すクエリ内の語)を探すために調べられ得る。
ブロック1020において、フィード追跡アップデートテーブルに含めるためにこのイベントが追跡されているかどうかが判定される。何が追跡されているかのこの判定は、上述したように、テナントの設定に基づき得る。一態様において、このイベントは、このイベントの行為者(イベントを実行する人)と、このイベントのオブジェクト(例えば、変更されているレコード又はユーザプロフィール)と、を有する。
ブロック1030において、このイベントが、イベント履歴テーブル(例えば、テーブル910)に書き込まれる。一実施例において、このフィード追跡オペレーションは、レコードをアップデートするための記録オペレーションを実行する同じトランザクションにおいて実行され得る。別の実施例において、トランザクションは、少なくとも2つのラウンドトリップデータベースオペレーションを含み、1つのラウンドトリップは、データベース記録(書き込み)であり、第2のデータベースオペレーションは、フィード追跡アップデートテーブルへのアップデートの記録である。一実施例において、イベント履歴テーブルは時系列である。別の実施例において、ユーザAが、ユーザBのプロフィール上にポストする場合、ユーザAは「クリエイテッドバイ」913下にあり、ユーザBはオブジェクトID912下にある。
ブロック1040において、フィールド変更テーブル(例えば、フィールド変更テーブル920)が、イベント識別子と、アップデートにおいて変更されたフィールドと、を有するエントリを用いてアップデートされ得る。一実施例において、フィールド変更テーブルは、イベント履歴テーブルの子テーブルである。このテーブルは、変更されるフィールドの各々についての情報を含み得る。例えば、口座レコードの名前及び残高を変更するイベントに関して、エントリは、イベント識別子と、古い名前及び新たな名前と、古い残高及び新たな残高と、を有することができる。代替的に、各フィールド変更は、同じイベント識別子を有する異なる行に存在してもよい。フィールド名又はIDはまた、値がどのフィールドに関連するかを判定するために含まれ得る。
ブロック1050において、このイベントがポストである場合、ポストテーブル(例えば、ポストテーブル950)が、イベント識別子とポストのテキストとを有するエントリを用いてアップデートされ得る。一実施例において、フィールド変更テーブルは、イベント履歴テーブルの子テーブルである。別の実施例において、このテキストは、トランザクション(例えば、クエリコマンド)において識別され、分離され、適切な列においてエントリに入れられ得る。本明細書で説明される様々なテーブルは、様々な形で組み合わされてもよいし、分離されてもよい。例えば、ポストテーブル及びフィールド変更テーブルは、同じテーブルの一部であってもよいし、別のテーブルであってもよいし、データのオーバーラップする部分を含んでもよい。
ブロック1060において、イベントについてのコメントが受信され、コメントが、コメントテーブル(例えば、コメントテーブル930)に追加される。コメントは、ポストに対するもの、又は、表示されるフィード追跡アップデートが生成され得るレコードのアップデートに対するものであり得る。一実施例において、テキストが、トランザクション(例えば、クエリコマンド)において識別され、分離され、適切な列においてエントリに入れられ得る。
D.フィード追跡アップデートテーブルからの情報の読み出し
図11は、いくつかの実施例に従って実行される、表示されるフィードを生成することの一部としてフィード項目を読み出すための方法1100の一例のフローチャートを示している。一実施例において、フィード項目は、レコードのためのフィードを作成することの一部として読み出され得る。
ブロック1110において、特定のレコードに関連するイベントのための、イベント履歴テーブル(例えば、イベント履歴テーブル910)に対するクエリが受信される。一実施例において、このクエリは、フィードがリクエストされているレコードの識別子を含む。様々な実施例において、クエリは、レコードの詳細ページ、レコードフィードをリクエストしているユーザのホームページ、又は(例えば、検索又はブラウジングから取得された)様々なレコードのリストから開始され得る。
ブロック1120において、ユーザがレコードフィードを閲覧できるかどうかを判定するために、ユーザのセキュリティレベルがチェックされ得る。通常、ユーザがレコードにアクセスできる場合、このユーザはレコードフィードを閲覧することができる。このセキュリティチェックは、様々な方法により実行され得る。一実施例において、ユーザがクラシフィケーション(classification)(例えば、ユーザが所与のタイプのレコードを閲覧することを許可するセキュリティレベル)を有するかどうかを確認するために、第1のテーブルがチェックされる。別の実施例において、ユーザが特定のレコードを閲覧することを許可されているかどうかを確認するために、第2のテーブルがチェックされる。第1のテーブルは第2のテーブルの前にチェックされ得、両テーブルは同じテーブルの異なるセクションであり得る。ユーザが、レコードの詳細ページからフィードをリクエストした場合、一実施例は、レコードのためのセキュリティレベルチェックをスキップすることができる。なぜならば、このチェックは、ユーザが詳細ページを閲覧することをリクエストしたときにすでに行われているからである。
一実施例において、セキュリティチェックは、レコードフィードを閲覧する各リクエストに対して判定される。したがって、フィード項目がユーザに対して表示されるか否かは、例えば、ユーザが、レコードのフィード又はこのユーザがフォローしている全てのオブジェクトのニュースフィードを閲覧することをリクエストしたときのアクセス権に基づいて判定される。このように、ユーザのセキュリティが変化する場合、フィードは、変化されたときのユーザのセキュリティレベルに自動的に適応する。別の実施例において、フィードは、リクエストされる前に算出され得、ユーザがフィード項目を閲覧するためのアクセス権をなお有しているかどうかを判定するために、次いでセキュリティチェックがなされ得る。このセキュリティ(アクセス)チェックは、レコードレベルであるとともにフィールドレベルであり得る。
ブロック1130において、ユーザがレコードにアクセスできる場合、ユーザが特定のフィールドを閲覧できるかどうかを判定するために、フィールドレベルセキュリティテーブルがチェックされ得る。一実施例において、このようなフィールドだけがユーザに対して表示される。あるいは、ユーザがアクセスできるこのようなフィールドのサブセットが表示される。フィールドレベルセキュリティチェックは、レコードレベルチェックと同時に、且つさらにはレコードレベルチェックと同じオペレーションを用いて、オプションで実行され得るものである。加えて、レコードタイプチェックも、このときに実行されてもよい。ユーザが所定のフィールドのみ閲覧できる場合、(例えば、フィールド変更テーブル920から決定された、)このようなフィールドに関連する任意のフィード項目が、表示されるフィードから除去され得る。
ブロック1140において、ユーザがアクセスできるフィード項目が表示される。一実施例において、予め定められた数(例えば、20個)のフィード項目が一度に表示される。この方法は、読むことが可能であると分かっている最初の20個のフィード項目を表示して、次いで、ユーザがこの最初の20個を閲覧している間に他のフィード項目を決定することができる。別の実施例において、ユーザが、例えば、「see more link(より多くのリンクを見る)」を作動させることにより、他のフィード項目を閲覧することをリクエストするまで、他のフィード項目は決定されない。
図12は、いくつかの実施例に従って実行される、表示されるプロフィールフィードのフィード項目を読み出すための方法1200の一例のフローチャートを示している。一実施例において、クエリは、リクエストされているユーザプロフィールフィードの識別子を含む。所定のブロックはオプションであり得、これは、本明細書で説明される他の方法についても同様である。例えば、セキュリティチェックは実行されてなくてもよい。
ブロック1210において、イベント(例えば、取引先の作成)の行為者として第1のユーザを有するイベント又はイベント(例えば、ユーザのプロフィールへのポスト)が生じたイベントのためのクエリが、イベント履歴テーブル(例えば、イベント履歴テーブル910)に向けられる。様々な実施例において、クエリは、ユーザのプロフィールページから、プロフィールフィードをリクエストしているユーザのホームページから(例えば、フォローされているユーザのリストから)、又は(例えば、検索又はブラウジングから取得された)様々なユーザのリストから、第2のユーザにより開始され得る。イベントの態様を判別してテーブルから情報を取得するための様々な機構は、本明細書で説明される方法のいずれに対しても同じものであり得る。
ブロック1220において、第2のユーザが第1のユーザのプロフィールを閲覧できるかどうかについて、セキュリティチェックが実行され得る。一実施例において、いかなるユーザも、同じテナントの別のユーザのプロフィールを閲覧することができ、ブロック1220はオプションである。
ブロック1230において、フィード追跡アップデートのためのセキュリティ(アクセス)チェックが、レコードタイプ、レコード、及び/又はフィールドに基づいて実行され得、メッセージのためのセキュリティチェックも同様に実行され得る。一実施例において、人がアップデートしたレコードに関連するフィード追跡アップデートだけが、セキュリティチェックを要するものである。というのは、ユーザについてのフィード項目は、同じテナントの任意のユーザにより読むことが可能だからである。他のテナントのユーザは、ナビゲート可能(navigable)でなく、したがって、セキュリティが、テナントレベルで実施され得る。別の実施例において、第2のユーザがアクセスできないレコード又はフィールドへのリンク又はキーワードを探すために、メッセージがチェックされ得る。
ユーザは、異なるセキュリティクラシフィケーションを有し得るので、低レベルのセキュリティを有するユーザが、高レベルのセキュリティを有するユーザにより行われたレコードに対する変更を閲覧できないことは重要である。一実施例において、各フィード項目がチェックされ、次いで閲覧可能な結果が表示され得るが、これは非効率的であり得る。例えば、このようなセキュリティチェックは、長い時間を要し得るものであり、第2のユーザは、いくつかの結果をより早く得たいと望み得る。以下のブロックは、多数のフィード項目を有する第1のユーザに関してセキュリティがどのようにチェックされ得るかの一実施例を示すが、第2のユーザは、そのようなフィード項目のほとんどを閲覧できない。この実施例は、全ての状況に対して使用され得るが、上記の状況において有効であり得る。
ブロック1231において、(例えば、イベント識別子から判別できる、直近から始まる)予め定められた数のエントリが、イベント履歴テーブルから取得される。取得されたエントリは、まさにクエリのユーザIDと合致するエントリであり得る。一実施例において、ユーザ及びレコードに関連付けられているエントリ(すなわち、ユーザアカウントに対するポストではない)を見つけるために、エントリがチェックされる。別の実施例において、ユーザに関連付けられたこのようなエントリが、閲覧されることを許可される。なぜならば、例えば、第2のユーザは、ブロック1220において判定されたように、第1のユーザのプロフィールを閲覧することができるからである。
ブロック1232において、レコード識別子が、タイプ別に編成され、第2のユーザがレコードタイプを閲覧できるかどうかについて、このタイプがチェックされる。レコードが(例えば、所有者により)手動で共有されたかどうか等の他のチェックが実行されてもよい。一実施例において、様々なタイプのためのクエリが、並行して行われ得る。
ブロック1233において、ユーザがレコードタイプを閲覧できる場合、チェックが、特定のレコードについて実行され得る。一実施例において、ユーザがあるレコードタイプを閲覧できる場合、このユーザは、このタイプのレコードの全てを閲覧することができるので、このブロックはスキップされ得る。別の実施例において、共用モデルは、第2のユーザより下のユーザ(例えば、第2のユーザはマネージャである)がレコードを閲覧できるかどうかを考慮に入れることができる。そのような実施例において、第2のユーザは、そのようなレコードを閲覧することができる。一実施例において、ユーザが特定のレコードを閲覧できない場合、そのレコードに対するコメントも閲覧できない。
ブロック1234において、フィールドレベル共用ルールを使用して、第2のユーザが、アップデートについての情報、すなわち、所定のフィールドの値を閲覧できるかどうかを判定することができる。一実施例において、特定のフィールド名への参照がなされるかどうかを判定するために、メッセージが解析され得る。特定のフィールド名への参照がなされる場合には、フィールドレベルセキュリティがメッセージに適用され得る。
ブロック1235において、終了基準(stopping criterion)が満たされるまで、ブロック1231〜ブロック1234が繰り返される。一実施例において、終了基準は、閲覧可能な最大数(例えば、100個)のエントリが識別されたときであり得る。別の実施例において、終了基準は、エントリが閲覧可能であるか否かにかかわらず、エンティティフィード追跡アップデートテーブルからの最大数(例えば、500個)のエントリが解析されたことであり得る。
一実施例において、ニュースフィードが、例えば上述したように、プロフィールフィードとエンティティフィードとの組合せとして生成され得る。一実施例において、ブロック1110及びブロック1210におけるクエリに関するレコード及びユーザプロフィールのリストが、ユーザサブスクリプションテーブル940から取得され得る。一実施例において、フォローされ得るオブジェクトの最大数が存在する。
E.フィードのための項目の部分的事前算出
図13は、いくつかの実施例に従って実行される、フィード内に表示するためのフィード項目を効率的に生成するためにイベント情報を記憶する方法1300の一例のフローチャートを示している。様々な実施例において、方法1300は、イベントがイベント履歴テーブルに書き込まれるたびに、あるいは何らかの他の基準に基づいて定期的に(例えば、1分おきに、5つのアップデートがなされた後に、等)、実行され得る。
ブロック1310において、イベントを示すデータが受信される。このデータは、ブロック1010に関して上述したものと同じであり得、ブロック1010に関して上述したのと同じ方法で識別され得る。このイベントは、イベント履歴テーブル(例えば、テーブル910)に書き込まれ得る。
ブロック1320において、このイベントに関連付けられた1以上のオブジェクトが識別される。様々な実施例において、オブジェクトは、レコードが変更されている、ユーザがレコードを変更している、ユーザがメッセージをポストしている、メッセージがユーザのプロフィールにポストされている等の様々な基準に従うことにより識別され得る。
ブロック1330において、このイベントをフォローしているユーザが判別される。一実施例において、このイベントに関連付けられている1以上のオブジェクトを使用して、このイベントをフォローしているユーザを判別する。一実施例において、サブスクリプションテーブル(例えば、テーブル940)を使用して、識別されるオブジェクトを見つけることができる。識別されたオブジェクトのエントリは、このオブジェクトをフォローしているユーザの各々の識別子(例えば、ユーザID941)を含み得る。
ブロック1340において、このイベントと、例えば(レコードアップデートの)レコード又は(ユーザにより生成されたポストの)ポストしたユーザといったこのイベントのソースと、が、イベント識別子とともに、ニュースフィードテーブルに書き込まれる。一実施例において、このような情報は、別個のエントリとして、イベントIDとともにニュースフィードテーブルに追加される。別の実施例において、ユーザのためのイベントの各々は、このユーザの行に関して、新たな列として追加される。さらに別の実施例において、より多くの列(例えば、他のテーブルからの列)が追加されてもよい。
ニュースフィードテーブル960は、ユーザID961と、イベントID又はポインタ962と、を有するそのようなテーブルの一例を示している。このテーブルは、任意の形で編成され得る。イベント履歴テーブル910との1つの差異は、ニュースフィードテーブル960においては、1つのイベントが複数のエントリ(サブスクライバごとに1つ)を有し得ることである。一実施例において、同じユーザのためのエントリの全ては、例えば示されるように、一緒にグループ化される。ユーザU819は、イベントE37及びイベントE90をフォローしているものとして示されており、したがって、これらのイベントから生じる個々のフィード項目のいずれもフォローしている。別の実施例において、任意の新たなエントリは、このテーブルの最後に追加される。したがって、新たなイベントのフォロワの全てが、グループとして追加され得る。そのような実施例において、イベントIDは、一般に、このテーブル内で一緒にグループ化される。もちろん、このテーブルは、任意の適切な方法でソートされてもよい。
一実施例において、ユーザの数が少ない場合、このようなテーブルのうちの1以上におけるフィード項目は、同じライトトランザクションの一部として書き込まれ得る。一実施例において、少ないことの判定は、イベントに関して実行されたアップデートの数(例えば、最大数のアップデートオペレーションが許容され得る)に依存し、より多くのオペレーションが実行される場合、フィード項目の追加が行われる。一態様において、オペレーションの数は、(アップデートイベントに依存する)レコードの行と、フォロワの数に依存し得るフィード追跡アップデートテーブルの行と、を含む、アップデートされる行の数によりカウントされ得る。別の実施例において、ユーザの数が多い場合、フィード項目の残りは、バッチにより作成され得る。一実施例において、フィード項目は、異なるトランザクションの一部として、すなわち、バッチジョブにより、書き込まれる。
一実施例において、エントリがニュースフィードテーブル960に追加される前に、セキュリティチェックが実行され得る。このように、セキュリティチェックは、バッチジョブ中に実行され得るものであり、ニュースフィードをリクエストしたときに実行される必要はない。一実施例において、イベントが解析され得、このイベントのフィード項目へのアクセスが許可されない場合、エントリは追加されない。一態様において、同じユーザのための複数のフィード項目は、同じイベントから生じなくてもよく(例えば、イベントがテーブル910内でどのように定義されているかにより)、したがって、ユーザが閲覧できるべきであるフィード項目をユーザが見逃す心配はない。
ブロック1350において、ニュースフィードを求めるリクエストが、ユーザから受信される。一実施例において、このリクエストは、ユーザがこのユーザのホームページに移動したときに得られる。別の実施例において、ユーザは、このリクエストを送信させるテーブル、リンク、又は他のページ項目を選択する。
ブロック1360において、ニュースフィードの表示可能なフィード項目を提供するために、ニュースフィードテーブル及び他のテーブルがアクセスされる。次いで、ニュースフィードが表示され得る。一実施例において、フィード項目を決定するために、ニュースフィードテーブルが、イベント履歴テーブルと結合され得る。例えば、特定のユーザIDを有するエントリを探すために、ニュースフィードテーブル960が検索され得る。このようなエントリを使用して、イベント履歴テーブル910内のイベントエントリを識別することができ、任意の子テーブルからの適切な情報を取得することができる。次いで、フィード項目(例えば、フィード追跡アップデート及びメッセージ)が、表示のために生成され得る。
一実施例において、直近のフィード項目(例えば、直近100個)がまず決定される。次いで、他のフィード項目が、バッチプロセスにおいて決定され得る。したがって、ユーザが閲覧する最も可能性が高いフィード項目が最初に現れ得、ユーザは、他のフィード項目がバッチで処理されていることを認識しなくてよい。一実施例において、直近のフィード項目は、イベント識別子により判別され得る。別の実施例において、最高重要度レベルを有するフィード項目が最初に表示されてもよい。最高重要度は、誰がフィード項目をポストしたか、フィード項目がどれくらい新しいか、フィード項目が他のフィード項目にどれくらい関連するか等の1以上の基準により決定される。
一実施例において、ユーザサブスクリプションテーブル940を使用してニュースフィードを動的に作成する場合、クエリは、サブスクリプションテーブルを検索し、次いで、オブジェクトIDを使用してイベント履歴テーブルを検索する(ユーザがフォローしているオブジェクトごとに1回の検索)。したがって、ニュースフィードのためのクエリは、ユーザがサブスクライブしていたオブジェクトの数に比例し得る。ニュースフィードテーブルは、関連するイベントが既知であるように、オブジェクトIDを判別する中間ブロックがより早い段階で実行されることを可能にする。したがって、フィードの決定は、フォローされているオブジェクトの数にもはや比例しない。
いくつかの実施例において、ニュースフィードテーブルは、ユーザによりフォローされているイベントごとに、イベント履歴テーブルに対するポインタ(イベント識別子ではない)を含み得る。このように、イベントエントリは、イベント履歴テーブルに対して検索を実行する必要なく、即座に取得され得る。このときにセキュリティチェックが実行され得、フィード追跡アップデートのテキストが生成され得る。
X.フィードの表示
フィードは、メッセージ及びフィード追跡アップデートを含み、データベースシステムとのアプリケーションインタフェース内の多くの場所に現れ得る。一実施例において、フィードは、フィードが表示されているページのコンテキストにスコープされ得る。例えば、フィード追跡アップデートがどのように提示されるかは、どのページでフィード追跡アップデートが表示されるか(例えば、レコードの詳細ページ上のニュースフィード内、及び、さらにはユーザが特定のページにおいてどのように終了したか)に応じて変わり得る。別の実施例において、限定された数(例えば50個)のフィード項目のみが表示される。一実施例において、特に表示されるフィード追跡アップデート又はメッセージの数に対する制限が存在し得る。代替的に、この制限は、特定のタイプのフィード追跡アップデート又はメッセージに適用されてもよい。例えば、フィールドの直近の変更(例えば、直近5個)のみが表示されてもよい。また、変更が表示されるフィールドの数が制限されてもよい。このような制限は、プロフィールフィード及びニュースフィードについても適用され得る。一実施例において、フィード項目は、例えば、以下で説明されるように、表示される前に、所定のフィルタリング基準の対象となり得る。
XI.フィードのフィルタリング及び検索
ユーザは、多くのユーザ及びレコードにサブスクライブすることが可能であり得るが、これは、ユーザのニュースフィードを非常に長くさせ、多くのフィード項目を含ませる。そのような例において、ユーザが全てのフィード項目を読むことは困難であり得、したがって、いくつかの重要なフィード項目又は関心のあるフィード項目は、読まれないことがある。いくつかの実施例において、フィルタを使用して、どのフィード項目がフィードに追加されるか、あるいはどのフィード項目がフィード内に表示されるかを決定することができる。
図14は、いくつかの実施例に従って実行される、フィルタリング基準を用いて、データベースシステムのユーザのためのカスタムフィードを作成するための方法1400の一例のフローチャートを示している。以下のブロックのいずれも、データベースシステムを用いて全体的又は部分的に実行され、詳細には、データベースシステムの1以上のプロセッサにより実行され得る。
ブロック1410において、どのフィード項目が第1のユーザに対して表示されるべきであるかを指定する1以上の基準が、テナントから受信される。一実施例において、基準は、どの項目をカスタムフィードに追加するかを指定する。例えば、基準は、レコードの所定のフィールドのためのフィード項目、所定のキーワードを含むメッセージ、及び本明細書に記載される他の基準のみを含むよう指定し得る。別の実施例において、基準は、どの項目をカスタムフィードから除去するかを指定する。例えば、基準は、所定のフィールドについてのフィード項目又は所定のキーワードを含むものを含まないよう指定し得る。
ブロック1420において、データベースシステムは、基準に合致する、1以上の選択されたオブジェクトのフィード項目を識別する。このフィード項目は、例えば、図9Aのテーブルのうちの1以上といったデータベースに記憶され得る。一実施例において、1以上の選択されたオブジェクトは、第1のユーザがフォローしているオブジェクトである。別の実施例において、1以上の選択されたオブジェクトは、第1のユーザがリクエストしているレコードフィードの1つのレコードである。
ブロック1430において、基準に合致するフィード項目が、カスタムフィード内で、第1のユーザに対して表示される。フィード追跡アップデートのテキストは、フィード項目(例えば、フィールド変更のデータ)の識別後であって、フィード項目の最終バージョンの表示前に、生成され得る。
一実施例において、基準は、フィード項目が作成される前に受信される。別の実施例において、基準は、第1のユーザから受信される。一態様において、基準は、第1のユーザに対して表示するフィードを決定するために使用されるだけである。さらに別の実施例において、基準は、第1のテナントから受信され、第1のテナントの全てのユーザに適用される。また、一実施例において、複数の基準が指定される場合、1つの基準が満たされるならば、これらの基準は、フィード項目に関して満たされ得る。
いくつかの実施例は、関心のあるフィード項目を検索するための機構を提供することができる。例えば、フィード項目は、例えば、ユーザにより入力されるキーワードにより検索され得る。別の例として、タブ(又は、他の選択デバイス)は、特定のユーザについてのフィード項目又は特定のユーザからのフィード項目を表示することができる。一実施例において、特定のユーザからのメッセージ(又は、さらにはコメント)のみが選択され得る。基準に合致するフィード項目を検索することに加えて、ユーザは、特定のフィード項目を検索することもできる。
XII.パブリッシャ及び情報フィードを介した複数のレコードとのインタラクション
図15は、いくつかの実施例に従って実行される、オンラインソーシャルネットワークにおいて単一のユーザインタフェースから1以上のレコードとインタラクトするための、コンピュータにより実施される方法1500の一例のフローチャートを示している。図15は、図19〜図30を参照して説明され得る。ブロック1504において、1つのコンピューティングデバイス、又は、方法1500を実行するために協働する任意の数のコンピューティングデバイスは、パブリッシャを含むユーザインタフェースを生成するためのデータを提供することができる。パブリッシャは、情報を情報フィードに公開するよう構成され得る。いくつかの実施例において、ユーザインタフェースは、パブリッシャ及び情報フィードを同時に表示することができる。ユーザインタフェースは、オンラインソーシャルネットワークにおけるユーザ、レコード、又は他のエンティティのためのページレイアウトの一部であり得る。
図19は、いくつかの実施例に従った、パブリッシャ1902及び情報フィード1904を含むユーザインタフェースを伴うレコードの一例を示している。図19において、Dell用の取引先ページ1906は、ディスプレイデバイス上に表示されるグラフィカルユーザインタフェース(GUI)の形態である。ユーザは、ユーザインタフェース内の複数のタブの中からタブ1908を選択することにより、取引先ページ1906に移動することができる。レコードとインタラクトするリクエストは、ユーザがパブリッシャ1902内のボタン、リンク、タブ、又はメニューセレクションを選択したことに応じて生成され得る。いくつかの実施例において、レコードは、取引先ページ1906に関連付けられている親レコードと関連し得る。パブリッシャは、ユーザがレコードとインタラクトするリクエストを行うことを可能にする1以上のパブリッシャアクション1910を含み得る。パブリッシャ1902内に表示されているそのようなパブリッシャアクション1910の例は、「Post(ポスト)」、「Log a Task(タスクのログを取る)」、及び「New Contact(新たな連絡先)」を含む。図19の例に示されるように、「More(さらに)」を選択することは、ユーザがレコードとインタラクトするためにさらなるパブリッシャアクション1910から選択することを可能にするドロップダウンメニュー1912を生じさせる。そのようなさらなるパブリッシャアクション1910は、「Link(リンク)」、「Create Case(案件を作成する)」、「File(ファイル)」、「Create Listening Campaign(リスニングキャンペーンを作成する)」、「DSR」、「New Oppty(新たな商談)」、及び「Poll(投票)」を含む。加えて、取引先ページ1906内のパブリッシャ1902は、メッセージの入力のためのテキストボックス1914を含む。パブリッシャ1902はまた、テキストボックス1912内のメッセージを含むデータを、パブリッシャ1902から1以上のコンピューティングデバイスに送信するためのShare(共有)ボタン1916を含み、このデータが1以上のデータベースシステムに記憶される。このデータの一部は、パブリッシャ1902からのデータの送信に応じて、情報フィード1904内のフィード項目内に提示され得る。
図20は、いくつかの実施例に従ったパブリッシャ2000の一例を示している。パブリッシャ2000は、ユーザが、公開されることになる情報をフィードに公開することを可能にするインタフェースである。パブリッシャ2000は、異なるプリファレンス又は要件に従ってプログラムされ得る多様なデザイン又はレイアウトのうちの任意の1つを表示するインタフェースを提供することができる。例えば、パブリッシャ2000のインタフェースは、パブリッシャ2000がウェブページ上で表示されるか、モバイルデバイス上で表示されるか、自動車用ディスプレイ上で表示されるか等に応じて変わり得る。インタフェースのデザイン又はレイアウトにかかわらず、パブリッシャ2000は、同じアプリケーションプログラミングインタフェース(API)と通信して、情報をフィードに公開するパブリッシャ2000の基本機能を実行することができる。
パブリッシャ2000のインタフェースの一例が図20に示されている。パブリッシャ2000は、複数のパブリッシャアクション2002、パブリッシャスペース2004、メッセージボディ2006、公開ボタン(publishing button)2008、及び共有ドロップダウンメニュー2010を含み得る。パブリッシャアクション2002の各々は、GUIボタン、リンク、タブ、チャンネル(channel)、又はメニュー項目の形態であり得る。パブリッシャアクション2002は、パブリッシャ2000のためのAPIにより有効にされ得る。さらに、パブリッシャアクション2002は、レコードのための作成オペレーション若しくはアップデートオペレーション、又はレコードを参照する作成オペレーション若しくはアップデートオペレーションを実行するよう構成され得る。
パブリッシャアクション2002のうちの1つの選択は、パブリッシャスペース2004に、選択されたパブリッシャアクション2002に関連付けられたデータを表示させ得る。例えば、パブリッシャスペース2004は、図20に示される新たな連絡先を作成するための複数のデータフィールド2012を有するフォームを含み得る。別の例において、パブリッシャスペース2004は、ウェブページ等の、1以上のデータソースからのコンテンツを含み得る。さらに別の例において、パブリッシャスペース2004は、Heroku(登録商標)等のサードパーティプラットフォーム上でホストされているアプリケーションからのデータを公開することができる。
パブリッシャスペース2004内に提供されたデータは、情報フィードに公開され得る。図20において、複数のデータフィールド2012は、ユーザが、新たな連絡先の作成に関連する情報を入力することを可能にする。データフィールド2012の一部は、デフォルト値が提供されてグレーアウトされ得る。データフィールド2012の一部は、それらが必須フィールドであることを示すために星印が付けられ得る。データフィールド2012内のそのような情報は、メッセージボディ2006内に提供されたメッセージとともに公開され得る。メッセージは、単語、語句、文、質問、感情表現、及び/又は記号等の任意の英数字のユーザ入力又は他の文字ベースのユーザ入力を含み得る。公開ボタン2008の選択により、データフィールド2012及びメッセージボディ2006内に提供された情報が適切な情報フィードに公開される。ユーザがそのような情報を共有したいと望むエンティティは、共有ドロップダウンメニュー2010からエンティティを選択することにより提供され得る。
図21A〜図21Dは、いくつかの実施例に従った、モバイルデバイスアプリケーション用のパブリッシャ2108及び情報フィード2104を含むユーザインタフェースの一例を示している。APIは、パブリッシャ2108が、モバイルデバイスアプリケーションを含む任意の数のアプリケーションのために、データベースシステムとインタフェースをとることを可能にする。いくつかの実施例において、エンティティは、任意の顧客、パートナ、組織、又は他のユーザがAPIを利用するアプリケーションを書くことができるように、パブリッシャ2108のためのAPIを開発することができる。
図21Aにおいて、モバイルデバイス用のユーザインタフェースは、パブリッシャボタン2102及び情報フィード2104を含み得る。パブリッシャボタン2102は、ユーザが図21Bに示されるパブリッシャ2108にアクセスすることを可能にする。パブリッシャ2108は、モバイルデバイスのユーザインタフェース内の情報フィード2104の一部の上に広がり得る。ユーザは、パブリッシャ2108内の複数のパブリッシャアクション2106の中から選択することができる。パブリッシャアクション2106は、「Post(ポスト)」、「Photo(写真)」、「Files(ファイル)」、「Task(タスク)」、「Contact(連絡先)」、及び「Check-In(チェックイン)」を含む。パブリッシャアクション2106の選択は、パブリッシャに、選択されたパブリッシャアクション2106に関連付けられたコンテンツ及び/又はデータフィールドを表示させ得る。図21Cに示されるように、Contact(連絡先)パブリッシャアクション2106の選択は、パブリッシャ2108に、メッセージをポストするためのテキストボックス2110と、新たな連絡先を作成するための複数のデータフィールド2112と、を表示させる。モバイルデバイスアプリケーションのいくつかの実装において、パブリッシャアクション2106の選択は、ユーザインタフェースにキーボード2114を表示させる。データフィールド2112及びテキストボックス2110に情報を入力した後、ユーザは、Share(共有)ボタン2116を選択して、この情報を1以上の適切なフィードに公開することができる。
パブリッシャは、フィード項目等のビジュアルフィードバック要素(visual feedback element)を作成することにより、情報を1以上の情報フィードに公開するよう構成され得る。図22は、いくつかの実施例に従ったフィード項目2200の一例を示している。フィード項目2200は、パブリッシャから送信されたデータを含み得る。フィード項目2200は、ユーザインタフェース内の情報フィードの一部として現れ得る。ここで、フィード項目2200は、レコードをアップデート又は作成したエンティティ2202のアイデンティティ(識別情報)(identity)と、パブリッシャからのデータに付随するメッセージ2204と、アップデート又は作成されたレコード2206の名前と、添付物(attachment)2208と、トピック2210と、を含む。パブリッシャからの他のデータも、フィード項目2200内に提示され得る。いくつかの実施例において、レコード2206の名前は、ユーザインタフェースにこのレコードのためのページレイアウトを表示させる実行可能なセレクション又はリンクであり得る。フィード項目2200内にどの情報が表示されるかは、フィード項目2200を閲覧するエンティティのプロフィール及びフィード項目2200が表示されるページレイアウト等のコンテキストファクタ(contextual factor)に依存し得る。
図23A〜図23Bは、いくつかの実施例に従った、モバイルデバイスアプリケーション用の、パブリッシャ2308と、情報フィード2304内のフィード項目2320と、を含むユーザインタフェースの一例を示している。図21A〜図21Dにおいて説明されたパブリッシャ2108と同様に、パブリッシャ2308は、ユーザが、情報をデータフィールド2312に入力して、Share(共有)ボタン2316を用いてそのような情報を情報フィード2304に公開することを可能にする。パブリッシャ2308は、公開される情報に付随させるための添付ボタン及びメッセージポストボタン等のさらなるパブリッシャボタン2318を含み得る。図23Bにおいて、パブリッシャ2308からの情報のうちの少なくとも一部を含むフィード項目2320が、情報フィード2304内に提示され得る。ここで、フィールドデータ2322は、パブリッシャ2308内のデータフィールド2312から提供されるタスクのためのフィード項目2320内に提供される。
図15に戻ると、ブロック1508において、第1のレコードとインタラクトするリクエストが、パブリッシャから、方法1500を実行するために協働する1以上のコンピューティングデバイスにおいて受信される。第1のレコードは、データベースシステムに記憶された親レコードに関連する。ブロック1508におけるリクエストは、オンラインソーシャルネットワークにおいてユーザプロフィールを有するユーザ等のエンティティから、このユーザのスマートフォン、デスクトップコンピューティングデバイス、ラップトップコンピューティングデバイス、タブレットコンピューティングデバイス、又は他のモバイルコンピューティングデバイスを経由して、パブリッシャを介して受信され得る。他の例において、このリクエストは、オンラインソーシャルネットワークにおけるグループ、組織、又はレコードから受信され得る。
いくつかの実施例において、方法1500は、エンティティが第1のレコードとインタラクトするためのパーミッションを有するかどうかを判定することをさらに含み得る。従来のように、CRMシステムは、レコードとのインタラクションを、システム管理者及びレコードの所有者に制限する。したがって、他のユーザ又はグループは、所有者又はシステム管理者の支援又は許可がないと、レコードと直接インタラクトすることができない。エンティティのアクセスパーミッションに応じて、エンティティがインタラクトできるレコードのタイプと、エンティティが特定のタイプのレコードに関して閲覧できるページレイアウトと、に対して制限が課され得る。
エンティティが第1のレコードとインタラクトするためのパーミッションを有するかどうかを判定することは、このエンティティのプロフィールの1以上のエンティティ属性を識別することを少なくとも含み得る。エンティティのプロフィールの属性は、例えば、エンティティの役割又は定義(definition)、エンティティの関連情報(relationship information)、エンティティのプリファレンス、エンティティの使用パターン(usage pattern)、及びエンティティのプロフィールに関連付けられる他のメタデータを含み得る。例えば、エンティティの役割は、所定の取引先レコードに対して協働するチームに対するメンバシップを示すことができ、レコードとインタラクトするためのパーミッションは、エンティティがその取引先レコードに対する協働者である場合に判別され得る。別の例において、エンティティの役割は、組織階層における職位を示すことができる。エンティティが組織階層において位置するポジションに応じて、このエンティティは、所定のレコードとインタラクトするためのパーミッションを有することもあるし、有さないこともない。
さらに、エンティティが第1のレコードとインタラクトするためのパーミッションを有するかどうかを判定することは、第1のレコードの1以上のレコード属性を識別することを少なくとも含み得る。第1のレコードの属性は、レコードがリードであるか、案件であるか、取引先であるか、商談であるか、タスクであるか、イベントであるか、連絡先であるか、又はカスタムオブジェクトであるか等のレコードのタイプを示すことができる。第1のレコードの属性はまた、レコードのついての他のメタデータを提供することもできる。例えば、レコードのタイプは案件であり得、この案件は、技術的問題案件(例えば、バグ)又は取引先のための注文処理案件(例えば、取引)であり得る。あるエンティティは、技術的問題案件とインタラクトすることを許可されるが、注文処理案件とインタラクトすることは許可されないこともあるし、この逆もある。
さらに、エンティティが第1のレコードとインタラクトするためのパーミッションを有するかどうかを判定することは、1以上のエンティティ属性を1以上のレコード属性と比較することを少なくとも含み得る。例えば、エンティティが、営業部の部長(Vice President)として識別された場合、このエンティティは、取引先の全ての案件にアクセスして、そのような全ての案件とインタラクトすることができる。エンティティが、一営業員(Sales Associate)として識別された場合、このエンティティは、例えば、特定の製品に関わる案件等、取引先の限定されたタイプの案件にアクセスして、そのような案件とインタラクトすることしかできない。
いくつかの実施例において、エンティティが第1のレコードとインタラクトするためのパーミッションを有する場合であっても、インタラクションのタイプが制限され得る。そのような制限は、例えば、とりわけ、システム管理者、第1のレコードの所有者、又は組織のセキュリティ/パーミッションポリシにより設定され得る。いくつかの実施例において、エンティティは、第1のレコードとインタラクトするために、所定のアクションしか実行できないよう制限され得る。したがって、ユーザインタフェース内のパブリッシャは、このエンティティに対して少なくとも一部のパブリッシャアクションを無効にすることができる、このエンティティから少なくとも一部のパブリッシャアクションを隠すことができる、あるいは別の形でこのエンティティに対して少なくとも一部のパブリッシャアクションを表示しないようにすることができる。例えば、あるエンティティは、取引先に関連する商談を閲覧、アップデート、及び作成することが可能であるが、別のエンティティは、同じ取引先に関連する商談を閲覧及びアップデートすることしか可能でないことがある。いくつかの実施例において、エンティティは、レコードとインタラクトするために、所定のタイプの情報又はオプションしか閲覧できないよう制限され得る。例えば、あるエンティティは、契約の全ての条項をアップデートできるが、別のエンティティは、同じ契約の所定の条項しかアップデートできないことがある。別の例において、あるエンティティは、取引先に関連する公的情報及び私的情報を閲覧することができるが、別のエンティティは、同じ取引先に関連する公的に利用可能な情報しか閲覧することができないことがある。
いくつかの実施例において、第1のレコードとインタラクトするリクエストは、レコードを作成するリクエスト、レコードを削除するリクエスト、レコードをアップデートするリクエスト、レコードを変換するリクエスト、レコードにファイルを添付するリクエスト、レコードからデータをダウンロードするリクエスト、レコードにデータをアップロードするリクエスト、レコードに関連付けられた情報を閲覧するリクエスト、及びレコードを参照するオペレーションを他の形で実行するリクエストを含み得る。例えば、そのようなオペレーションは、電子メールを下書きすること、ワークフロー承認を承認又は拒否すること、メモを書くこと、投票(poll)を作成すること、要求(call)のログを取ること、タスクのログを取ること、バグのログを取ること、イベントを作成すること、電子メールを送信すること、承認のための電子メールを送信すること、ポータルにポストすること、ソーシャルネットワークにポストすること、リンクを追加すること、「感謝(Thanks)」を追加すること等を含み得るが、これらに限定されるものではない。いくつかの実施例において、第1のレコードは、顧客関係管理(CRM)オブジェクトであり得る。CRMオブジェクトは、リード、案件、取引先、商談、タスク、連絡先、キャンペーン、契約、イベント、カスタムオブジェクト、及びVisualforceページを含み得るが、これらに限定されるものではない。第1のレコードとインタラクトするリクエストは、ユーザがユーザインタフェース内でパブリッシャアクション又はカスタムアクションを選択したことに応じて生成され得る。
第1のレコードとインタラクトするリクエストは、データベースシステムに記憶された親レコードに関連する子レコードとインタラクトするリクエストであり得る。ここで、この親子関係は、データベースシステムにおけるレコード間の階層関係を指す。例えば、商談は、取引先に関連付けられた子であり得るのに対し、この取引先は親である。別の例において、タスクは、リードに関連付けられた子であり得るのに対し、このリードは親である。
図24は、いくつかの実施例に従った、パブリッシャ2402及び情報フィード2404を含むユーザインタフェースを伴うレコードの一例を示している。パブリッシャ2402は、複数のパブリッシャアクション2406、メッセージのためのテキストボックス2408、さらなるパブリッシャアクション2406を表示するためのドロップダウンメニュー2410、及びShare(共有)ボタン2412を含む。パブリッシャ2402は、複数のパブリッシャアクション2406の中からの少なくとも1つのカスタムアクションを含み得る。カスタムアクションは、パブリッシャ2402のためのAPIにより有効にされるアクションであり得る。いくつかの実施例において、カスタムアクションは、APIを利用してエンティティによりカスタマイズされ得る。カスタムアクションのカスタマイゼーションに関するさらなる詳細は、以下のセクションIXにおいて提供される。
図24において、Cirrus, Inc.用の取引先ページ2416は、複数のパブリッシャアクション2406を伴うパブリッシャ2402を含む。いくつかの実施例において、同じパブリッシャ2402が、異なるレコード及びエンティティ用の他のページ内に現れ得る。いくつかの例において、パブリッシャアクション2406は、全く同じであってよい。ユーザは、単一のユーザインタフェース又は類似するユーザインタフェースを表示する、異なるレコード及びエンティティ用の複数のページ間を移動することができる。
ここで、ユーザは、新たな連絡先の作成を開始するためのパブリッシャアクション2406である「Contact(連絡先)」を選択することにより、レコードとインタラクトするリクエストを開始することができる。新たな連絡先は、取引先に関連付けられた子レコードであり、取引先は親レコードである。パブリッシャアクション2406のうちのいずれかを選択して、APIと通信し、レコードとインタラクトするリクエストを開始することができることを理解されたい。
図15に戻ると、ブロック1512において、第1のレコードに関連付けられた第1の情報が、パブリッシャから、1以上のコンピューティングデバイスにおいて受信される。第1のレコードは、データベースシステムに記憶されていてもよいし、データベースシステムに記憶されるよう構成されていてもよい。第1の情報は、ブロック1508において第1のレコードとインタラクトすることをリクエストしたエンティティ(例えば、ユーザ)により提供され得る。第1の情報は、例えば、図1A及び図1Bにおける信号ネットワーク14を介して、方法1500を実行する1以上のコンピューティングデバイスに伝送され得る。いくつかの実施例において、エンティティは、選択されたパブリッシャアクションに関連付けられた1以上のデータフィールド内にフィールドデータを提供することができる。例えば、イベントレコードは、イベントの日付及び時間、招待された人(invitee)の名前、並びに開催地(venue)等のフィールドデータを含み得る。別の例において、タスクは、タスクの名前、タスクに割り当てられた人(assignee)の1以上の名前、及び期限日等のフィールドデータを含み得る。
図25は、いくつかの実施例に従った、パブリッシャアクション2406が選択されたときの、複数の空データフィールド2418を表示しているユーザインタフェースを伴う、図24におけるレコードの一例を示している。図25に示されるように、新たな連絡先を作成するためのパブリッシャアクション2406の選択は、パブリッシャ2402に、First Name(名)、Last Name(姓)、Title(職位)、Account(取引先)、Phone(電話番号)、Email(電子メールアドレス)、LinkedIn(リンクトイン)、及びTwitter(ツイッター)を含むデータフィールド2418を表示させる。新たな連絡先を作成するための一部のデータフィールド2418には、デフォルト値が入力されていることもあるし、新たな連絡先を作成するための一部のデータフィールド2418は、セキュリティクリアランス/パーミッションモデルに従ってシステム管理者により指定された予め定められた値を有するよう制限されることさえある。例えば、Account(取引先)データフィールドは、新たな連絡先と、親レコード、すなわち、Cirrus, Inc.取引先と、のレコード関係を確立するように制限される。パブリッシャ2402は、パブリッシャ情報を1以上の選択されたエンティティと共有するための共有ドロップダウンメニュー2420とともに、パブリッシャ情報を少なくとも選択されたエンティティの1以上の情報フィードに公開するためのShare(共有)ボタン2412をさらに表示している。
図26は、いくつかの実施例に従った、ユーザ入力を受け入れたときの、複数の入力済みデータフィールド2418を表示しているユーザインタフェースを伴う、図25におけるレコードの一例を示している。ユーザは、データフィールド2418の各々に値を入力することができる。いくつかの実施例において、データフィールド2418の各々における値は、マシン又はシステムにより生成され得る。データフィールド2418の各々における値は、data.com又はdatabase.com等のデータベースサービスから取得されてもよい。データフィールド2418の各々における値を使用して、レコードとのリクエストされたインタラクションを実行する、すなわち、子レコードを作成する。さらに、データフィールド2418の各々における値は、データベースシステムに記憶される情報を提供する。ユーザはまた、新たな連絡先についてのさらなるコンテキスト情報を表し得る、コメント等のメッセージをテキストボックス2408内に入力することができる。これは、この連絡先が有用又は重要である理由を含み得る。このように、ユーザは、パブリッシャ2402を使用して、連絡先レコードを作成すると同時に、連絡先レコードの作成に付随するコメントを作成することができる。テキストボックス2408内のメッセージ及びデータフィールド2428内の情報は、Share(共有)ボタン2412を選択することにより、パブリッシャ2402を介して送信され得る。
図15に戻ると、ブロック1516において、データベースシステムが、第1のレコードに関連付けられた第1の情報に基づいてアップデートされる。第1のレコードに対するアップデートは、レコードの作成、レコードの削除、レコードに関連付けられたデータを編集すること、レコードにアクションを記録すること、レコードの変換、レコードへのファイルの添付、レコードからデータをダウンロードすること、レコードにデータをアップロードすること、レコードに関連付けられた情報を閲覧すること、及びレコードを参照するオペレーションを他の形で実行することを含み得る。すなわち、ブロック1516における第1のレコードに関連付けられた第1の情報を使用して、ブロック1508におけるリクエストされたインタラクションを実行する。第1の情報を受信すると、1以上のコンピューティングデバイスは、データベースシステムにおいて、第1のレコードを表す行を作成又はアップデートさせることができる。例えば、レコードにアクションを記録する際、電子メールが送信された後にアップデートが実行され、次いで、レコードに記録され得る、あるいは、ポストがTwitter(登録商標)又はFacebook(登録商標)のようなオンラインソーシャルネットワークに送信された後にアップデートが実行され、次いで、レコードに記録され得る。実際、パブリッシャは、レコードのネットワークドメインの外部での挙動を有するアクションを実行することができる。それでも、そのようなアクションは、レコードに記録される。
ブロック1520において、アップデートに関連付けられたフィード項目が、ユーザインタフェース内の情報フィードに含まれるように提示される。フィード項目は、第1のレコードへの参照を提供する1以上の実行可能なセレクションを含む。実行可能なセレクションは、メニュー、リンク、又はグラフィカルボタン等の表示コンポーネントを指し得る。いくつかの実施例において、第1のレコードへの参照は、ユーザインタフェース内で、第1のレコードのためのページを開かせ得る。このように、ユーザは、フィード項目から、直接第1のレコードに移動することができる。ユーザは、異なるユーザインタフェース間を移動することによりレコード間を移動する必要がない。
いくつかの実施例において、第1のレコードへの参照は、第1のレコードに対するさらなるアクションを実行させ得る。第1のレコードを開くことに加えて、そのようなアクションは、第2のレコードを作成すること、第1のレコードを削除すること、第1のレコードをアップデートすること、第1のレコードを変換すること、第1のレコードにファイルを添付すること、第1のレコードからデータをダウンロードすること、第1のレコードにデータをアップロードすること、第1のレコードに関連付けられた情報を閲覧すること、及び第1のレコードを参照するオペレーションを他の形で実行することを含み得るが、これらに限定されるものではない。より詳細には、そのようなアクションの例は、タスクを作成すること、タスクをアップデートすること、商談を作成すること、商談をアップデートすること、連絡先を作成すること、連絡先をアップデートすること、案件を作成すること、案件をアップデートすること、取引先を作成すること、取引先をアップデートすること、イベントを作成すること、イベントをアップデートすること、要求のログを取ること、タスクのログを取ること、バグのログを取ること、ワークフロー承認を承認すること、ワークフロー承認を拒否すること、電子メールを作成すること、メモを書くこと、投票を作成すること、案件をクローズすること、タスクを完了すること、バグをクローズすること、電子メールを送信すること、承認のための電子メールを送信すること、ポータルにポストすること、ソーシャルネットワークにポストすること、リンクを追加すること、「感謝」を追加することを含み得る。したがって、アクションは、別のページに移動することなく、第1のレコード上のフィード項目から直接実行され得る。
1以上の実行可能なセレクションは、パブリッシャに、ユーザが第1のレコードとさらにインタラクトすることを可能にするさらなるデータフィールドを提供させ得る。いくつかの実施例において、1以上の実行可能なセレクションを選択することは、パブリッシャに、第2の情報を受信するよう動作させ得る。第2の情報を使用して、第1のレコードに対して、オペレーションのうちの1つを実行することができる。あるいは、第2の情報を使用して、第2のレコードとインタラクトすることができる。第2のレコードは、第1のレコードと親子関係を有し得る。いくつかの実施例において、第2のレコードは、第1のレコードの子である。このように、フィード項目からさらなるアクションを実行するための参照を提供することにより、ユーザは、情報フィード自体の中で直接アクションを実行することが可能になる。
図27は、いくつかの実施例に従った、パブリッシャ2402からのアップデートされたデータを提示しているフィード項目2422と、子レコードへのリンク2424と、を含む情報フィード2404を含むユーザインタフェースを伴う、図26におけるレコードの一例を示している。フィード項目2422は、親レコードのための情報フィード2404の上部に提示されている。フィード項目2422は、レコードとの実行されたインタラクションに関する情報を含み得る。取引先ページ2416の情報フィード2404内に表示されている、図27のフィード項目2422は、「Daniel Cheng created a contact(Daniel Chengは連絡先を作成した)」を示している。いくつかの例において、フィード項目2422は、パブリッシャ2402内のデータフィールド2418内に提供されたさらなるデータを含み得る。しかしながら、データフィールド2418内に提供された全てのデータが、必ずしもフィード項目2422に含まれるわけではない。そのようなデータがフィード項目2422内にどのようにレンダリングされるかは、フィード項目2422を閲覧するユーザのプロフィール及びフィード項目2422が表示されるページレイアウト等のコンテキストファクタに依存し得る。フィード項目2422はまた、実行可能なセレクション、すなわち、作成又はアップデートされたレコードへのリンク2424を含む。図27において、新たに作成された連絡先レコードが、リンク2424「Chuy Santiago」として表示されている。ユーザはまた、コメントをフィード項目2422にポストすること、フィード項目2422にいいね又は良くないねを付すこと、又はフィード項目2422を共有することを含む様々なアクションをフィード項目2422に対して実行することができる。そのようなアクションは、他の関連フィード内に提示される同じフィード項目2422に影響を及ぼし得る。
ユーザは、リンク2424を選択して、Cirrus, Inc.用の取引先レコードから、Chuy Santiago用の連絡先レコードに移動することができる。これにより、ユーザは、情報フィード2404から直接別のレコードに効率的に移動することが可能になる。
図15に戻ると、ブロック1524において、1以上の実行可能なセレクションを選択したというユーザ入力が受信される。1以上の実行可能なセレクションは、第1のレコードへの参照を提供するよう構成されたメニュー、グラフィカルボタン、又はリンクであり得る。第1のレコードへの参照は、ユーザインタフェース内で第1のレコードを開くこと、第1のレコードから第2のレコードを作成すること、第1のレコードをアップデートすること、第1のレコードを削除すること、第1のレコードを変換すること、第1のレコードにファイルを添付すること、第1のレコードからデータをダウンロードすること、第1のレコードにデータをアップロードすること、第1のレコードに関連付けられた情報を閲覧すること、又は第1のレコードを参照するオペレーションを他の形で実行すること等、第1のレコードに対してアクションを実行させ得る。例えば、実行可能なセレクションは、電子メールに応答するための返信ボタンであり得る。別の例において、実行可能なセレクションは、ワークフロー承認リクエストに応答するための承認ボタンであり得る。いくつかの実施例において、第1のレコードへの参照は、パブリッシャに、第2のレコードに関連付けられた第2の情報を受信するよう動作させ得る。
ブロック1528において、第1のレコード又は第2のレコードに関連付けられた第2の情報が、パブリッシャから、1以上のコンピューティングデバイスにおいて受信される。第2のレコードは、第1のレコード又は親レコードの子レコードであり得る。第2のレコードは、データベースシステムに記憶されていてもよいし、データベースシステムに記憶されるよう構成されていてもよい。いくつかの実施例において、第2のレコードは、リード、案件、取引先、商談、タスク、連絡先、キャンペーン、契約、イベント、カスタムオブジェクト、及びVisualforceページ等のCRMオブジェクトであり得る。いくつかの実施例において、第2の情報は、第1のレコード又は第2のレコードに関連付けられた1以上のデータフィールド内に提供され得る。1以上のデータフィールドにおける値は、ユーザにより定められてもよいし、システムにより生成されてもよい。いくつかの実施例において、値は、data.com又はdatabase.com等のデータベースサービスから取得され得る。
ブロック1532において、データベースシステムが、第2の情報に基づいてアップデートされる。第1のレコード又は第2のレコードに対するアップデートは、パブリッシャ及び情報フィードを含み得るユーザインタフェースから離れることなく、パブリッシャを介してなされ得る。したがって、1以上のレコードとの複数回のインタラクションが、単一のユーザインタフェースから実行され得る。
図15において、一例では、図2A及び図2Bのオンデマンドサービス環境200におけるアプリケーションサーバ288は、ブロック1504〜ブロック1532の一部又は全てを実行するよう構成された1以上のプロセッサを含む。他の例では、さらなるサーバが、アプリケーションサーバ288と協働して、これらのブロックを実行する。例えば、ブロック1512において、第1の情報が受信される場合、このような情報は、図1A及び図1Bに示されるユーザシステム12を操作しているユーザから、データネットワークを介して、サーバにより受信され得る。他の例では、そのようなデータは、ユーザの代理であるプロキシサーバ又は他のデータソースから受信される。方法1500の様々な実装が可能であるので、図2Bを参照して上述したサーバ又は本明細書で開示される他のコンピューティングデバイスのいずれも、方法1500に従ってユーザ入力及び情報アップデートを受信して処理するよう構成され得る。
いくつかの実施例において、共通ユーザインタフェースを介した複数のレコードとのインタラクションは、図15の方法1500において実行され得る。そのようなインタラクションは、パブリッシャ及び情報フィードのコンテキストにおいて動作しながらCRMライフサイクル又は非CRMライフサイクルを進めることができる。CRMライフサイクルの一例は、本明細書で先に説明されたように、図24〜図27に示され得る。CRMライフサイクルの別の例は、図28〜図30に示され得る。
図28〜図30は、パブリッシャ及び情報フィードを含む単一のユーザインタフェースからCRMライフサイクルを進める段階の例を示している。図28は、いくつかの実施例に従った、パブリッシャ2802及び情報フィード2804を含むユーザインタフェースを伴うリードレコードの一例を示している。例えば、見込み客であるMr. JimBobと会った、あるいはMr. JimBobを知っているサービスエージェントは、図28に示されるようなMr.JimBob用のリードページ2816にアクセスすることができる。サービスエージェントがMr. JimBob用のリードにアクセスするためのパーミッションの判定は、サービスエージェントのプロフィールに基づき得る。適切なパブリッシャアクション及び情報が、サービスエージェントのプロフィールに従って、データベースシステムから取得され、Mr. JimBob用のリードページ2816上に表示され得る。本明細書で先に説明されたように、一部の情報及び/又はアクションは、所定のユーザに利用可能でないことがある。図28に示されるように、パブリッシャ2802内の複数のパブリッシャアクション2806が、Mr. JimBob用のリードに対してアクションを実行するためのチャンネルとして、左側のバー上に表示されている。パブリッシャアクション2806は、「Create a Task(タスクを作成する)」、「Create a Case(案件を作成する)」、「Convert Lead(リードを変換する)」、「Write Lead Note(リードメモを書く)」、及び「View Lead Details(リード詳細を閲覧する)」を含む。
サービスエージェントは、パブリッシャアクション2806のうちの任意の1つを選択して、パブリッシャ2802に、選択されたパブリッシャアクション2806に関連付けられたデータフィールド2818を表示させることができる。いくつかの実施例において、パブリッシャアクション2806の選択は、パブリッシャ2802に、データソースからのコンテンツ又はアプリケーションを表示させ得る。図28において、データフィールド2818のうちのいくつかは、文字ベースの値を受け入れるよう構成されたテキストボックスであり、データフィールド2818のうちの1つは、チェックボックスであり、データフィールド2818のうちのいくつかは、ドロップダウンメニューである。サービスエージェントは、パブリッシャ2802内のデータフィールド2818のうちのいくつかに値を入力することができる。データフィールド2818のうちのいくつかにおいて、サービスエージェントは、検索クエリを実行することができる、且つ/あるいは、値を入力するためにオートコンプリート機能(auto-complete function)を利用することができる。いくつかの実施例において、データフィールド2818のうちのいくつかにはデフォルト値が提供され得る。
サービスエージェントは、Convert Lead(リード変換)ボタン2810を選択することにより、データフィールド2818に入力された情報を公開することができる。パブリッシャ2802からの情報は、データベースシステムに送信され得る。Mr. JimBob用のリードが削除され、Mr. JimBob用の商談が作成され、Mr. JimBob用の商談がデータベースシステムに記憶される。いくつかの実施例において、別のレコードが、Mr. JimBob用の商談の作成に伴って同時にインタラクトされ得る。この例において、Mr. JimBob用のリードからMr. JimBob用の商談への変換に伴って、タスクが同時に作成されている。フィード項目(図示せず)が、情報フィード2804内での提示のために作成される。フィード項目は、Mr. JimBob用の商談ページに移動する機能、又は、情報フィード2804からMr. JimBob用の商談を参照する他のアクションを実行する機能を、ユーザインタフェース内に提供することができる。この移動及び/又はアクションは、ユーザインタフェースを離れることなく実行することができる。すなわち、サービスエージェント又は別のエンティティは、1以上のレコードに対してアクションを実行するために、異なるユーザインタフェース間を移動する必要がない。フィード項目は、相互参照を通じて、複数の関連フィード内に公開され得る。相互参照については、以下のセクションXIIIにおいてより詳細に説明される。
図29は、いくつかの実施例に従った、パブリッシャ2902及び情報フィード2904を含むユーザインタフェースを伴う、図28におけるリードレコードから変換された商談レコードの一例を示している。リードレコードは、データベースシステムから削除され、商談レコードに置換される。Mr. JimBob用の商談ページ2916に移動するために、サービスエージェントは、フィード項目内の実行可能なセレクションを選択することができる。これにより、適切なパブリッシャアクション及び情報が、サービスエージェントのプロフィールに従って、データベースシステムから取得され、Mr. JimBob用の商談ページ2916内に表示され得る。図29に示されるように、パブリッシャ2902内の複数のパブリッシャアクション2906が、Mr. JimBob用の商談に対してアクションを実行するためのチャンネルとして、左側のバー上に表示されている。パブリッシャアクション2906は、「Create a Task(タスクを作成する)」、「Log a Call(要求のログを取る)」、「Create a Case(案件を作成する)」、「Create a Service Contract(サービス契約を作成する)」、「Write Opportunity Note(商談メモを書く)」、及び「View Opportunity Details(商談詳細を閲覧する)」を含む。サービスエージェントは、パブリッシャアクション2906のうちの任意の1つを選択して、パブリッシャ2902に、選択されたパブリッシャアクション2906に関連付けられたデータフィールド2918を表示させることができる。
図29において、サービスエージェントは、サービス契約を作成するためのパブリッシャアクション2906を選択しており、Contract Name(契約名)、Start Date(開始日)、及びEnd Date(終了日)用のデータフィールド2918が表示されている。サービスエージェントは、パブリッシャ2902内のデータフィールド2918の各々に値を入力することができる。
サービスエージェントは、Create Contract(契約作成)ボタン2910を選択することにより、データフィールド2918に入力された情報を公開することができる。パブリッシャ2902からの情報は、データベースシステムに送信され得る。サービス契約レコードが作成され、データベースシステムに記憶される。これは、データベースシステム内のテーブル内の行により表され得る。サービス契約レコードは、親レコードに対する子レコードとして、Mr. JimBob用の商談に関連する。フィード項目(図示せず)が、情報フィード2904に含まれるように作成される。フィード項目は、サービス契約レコードに移動する機能、又は、情報フィード2904からサービス契約レコードを参照する他のアクションを実行する機能を、ユーザインタフェース内に含み得る。この移動及び/又はアクションは、ユーザインタフェースを離れることなく実行することができる。
図30は、いくつかの実施例に従った、パブリッシャ3002及び情報フィード3004を含むユーザインタフェースを伴う、図29における親レコードのサービス契約レコードの一例を示している。サービス契約ページ3016に移動するために、サービスエージェントは、フィード項目内の実行可能なセレクションを選択することができる。これにより、適切なパブリッシャアクション及び情報が、サービスエージェントのプロフィールに従って、データベースシステムから取得され、サービス契約ページ3016内に表示され得る。図30に示されるように、パブリッシャ3002内の複数のパブリッシャアクション3006が、サービス契約レコードに対してアクションを実行するためのチャンネルとして、左側のバー上に表示されている。パブリッシャアクション3006は、「Add a Product(製品を追加する)」、「Write Service Contract Note(サービス契約メモを書く)」、及び「View Service Contract Details(サービス契約詳細を閲覧する)」を含む。サービスエージェントは、パブリッシャアクション3006のうちの任意の1つを選択して、パブリッシャ3002に、選択されたパブリッシャアクション3006に関連付けられたデータフィールド3018を表示させることができる。
図30において、サービスエージェントは、製品を追加するためのパブリッシャアクション3006を選択しており、Product(製品)、Quantity(数量)、及びSales Price(販売価格)用のデータフィールド3018が表示されている。サービスエージェントは、パブリッシャ3002内のデータフィールド3018の各々に値を入力することができる。
サービスエージェントは、Add(追加)ボタン3010を選択することにより、データフィールド3018に入力された情報を公開することができる。パブリッシャ3002からの情報は、データベースシステムに送信され得る。製品の契約品目項目(contract line item)が作成され、データベースシステムに記憶される。これは、データベースシステム内のテーブル内の行により表され得る。製品の契約品目項目は、親レコードに対する子レコードとして、サービス契約レコードに関連する。フィード項目(図示せず)が、情報フィード3004内での提示のために作成される。フィード項目は、契約品目項目に移動する機能、又は、情報フィード3004から契約品目項目を参照する他のアクションを実行する機能を、ユーザインタフェース内に含み得る。この移動及び/又はアクションは、ユーザインタフェースを離れることなく実行することができる。
ユーザは、図28〜図30に示されるような単一の標準化されたユーザインタフェース(standardized user interface)内で、CRMライフサイクル間を移動し、CRMライフサイクルを進めることができる。したがって、ユーザは、CRMライフサイクルを通じてレコードの各々とインタラクトするために、複数のユーザインタフェースを移動し学習する必要がない。レコードが作成及び/又はアップデートされたときに、ユーザは、即座に移動して、情報フィード及びパブリッシャを介して、新たに作成又はアップデートされたレコードに対してアクションを実行することができる。すなわち、情報フィード及びパブリッシャを介して、CRMライフサイクルにおける全てを行うことができる。
いくつかの実施例において、パブリッシャ及び情報フィードはまた、非CRMライフサイクルを進めるための共通ユーザインタフェースとして利用され得る。例えば、金融サービスエージェントは、顧客から、投資に関する要求を受け取ることがある。金融サービスエージェントは、顧客情報を入力して、顧客の投資レコードにアクセスすることができる。顧客の投資レコードページにおいて、ユーザインタフェースは、パブリッシャ及び情報フィードを含み得る。金融サービスエージェントは、パブリッシャを介して、顧客の投資レコードに投資を追加することができ、顧客の投資レコードから投資を削除することができ、あるいは、顧客の投資レコード内の投資をアップデートすることができる。フィード項目が、投資に対する1以上の実行可能なセレクションとともに、顧客の投資レコードの情報フィード内に提示される。投資は、例えば、とりわけ、IRA、Roth IRA、又はモーゲージ(mortgage)を含み得る。金融サービスエージェントは、フィード項目を通じて投資にアクセスし、非CRMライフサイクルを進めるのを続けることができる。
別の例において、健康保険エージェントは、顧客から、顧客の保険の補償に関する要求を受け取ることがある。健康保険エージェントは、顧客情報を入力して、顧客の健康保険プランにアクセスすることができる。顧客の健康保険プランページにおいて、ユーザインタフェースは、パブリッシャ及び情報フィードを含み得る。いくつかの実施例において、健康保険プラン、補償、商品、制限、及び補償額を表すためのカスタムオブジェクトが、ユーザインタフェースに提供され得る。顧客が関心をもっている補償に応じて、健康保険エージェントは、パブリッシャを介して、顧客の健康保険プランを追加、削除、又はアップデートすることができる。これは、健康保険プランに商品を追加すること又は健康保険プランから商品を削除することを含み得る。これはまた、制限及び補償額をアップデートすることを含み得る。フィード項目が、商品又は補償に対する1以上の実行可能なセレクションとともに、顧客の健康保険プランの情報フィード内に提示される。健康保険エージェントは、フィード項目を通じて商品又は補償にアクセスし、非CRMライフサイクルを進めるのを続けることができる。
別の例において、ユーザは、取引先下の経費報告書をファイルしたいと望むことがある。ユーザは、取引先レコードにアクセスすることができる。取引先レコードのユーザインタフェースは、パブリッシャ及び情報フィードを含む。いくつかの実施例において、パブリッシャは、Concur(登録商標)等の、経費報告のためのサードパーティアプリケーションを公開することができる。いくつかの実施例において、パブリッシャは、「File New Expense Report(新たな経費報告書をファイルする)」等のカスタムアクションを含み得る。ユーザは、パブリッシャを介して、経費報告書をファイルし、情報をフィード項目として情報フィードに公開することができる。フィード項目は、新たに作成された経費報告書にリンクしている1以上の実行可能なセレクションを含み得る。ユーザは、フィード項目を通じて経費報告書にアクセスし、非CRMライフサイクルを進めることができる。
XIII.フィード項目の相互参照
図16Aは、いくつかの実施例に従って実行される、オンラインソーシャルネットワークにおいて単一のユーザインタフェースから1以上のレコードとインタラクトするための、コンピュータにより実施される方法1600aの一例のフローチャートを示している。図16Aは、図31、図32A〜図32C、及び図33A〜図33Cを参照して説明され得る。ブロック1604aにおいて、概して方法1500のブロック1504において上述したように、パブリッシャを含むユーザインタフェースを生成するためのデータが提供される。ブロック1608aにおいて、概して方法1500のブロック1508において上述したように、第1のレコードとインタラクトするリクエストが、パブリッシャから受信される。第1のレコードは、データベースシステムに記憶された親レコードに関連し得る。ブロック1612aにおいて、概して方法1500のブロック1512において上述したように、第1のレコードに関連付けられた第1の情報が、パブリッシャから受信される。ブロック1616aにおいて、概して方法1500のブロック1516において上述したように、データベースシステムが、第1のレコードに関連付けられた第1の情報に基づいてアップデートされる。
ブロック1620aにおいて、第1の情報に基づくアップデートに関連付けられたフィード項目が、ユーザインタフェース内の親レコードの情報フィードに含まれるように提示される。フィード項目は、親レコードの情報フィード内に、パブリッシャからの第1の情報を表すビジュアルフィードバック要素を提供することができる。以下でより詳細に説明されるように、フィード項目は、複数の異なるフィードに含まれるように提示され得るが、フィード項目は、少なくとも親レコードの情報フィードに含まれるように提示され得る。いくつかの実施例において、フィード項目は、第1のレコードへの参照を提供する1以上の実行可能なセレクションを含み得る。結果として、ユーザは、フィード項目から直接第1のレコードに移動することができる。いくつかの実施例において、第1のレコードへの参照は、第1のレコードに対するさらなるアクションを実行させ得る。そのようなアクションは、第2のレコードを作成すること、第1のレコードを削除すること、第1のレコードをアップデートすること、第1のレコードを変換すること、第1のレコードにファイルを添付すること、第1のレコードからデータをダウンロードすること、第1のレコードにデータをアップロードすること、第1のレコードに関連付けられた情報を閲覧すること、及び第1のレコードを参照するオペレーションを他の形で実行すること(例えば、要求のログを取ること、電子メールを作成すること、ワークフロー承認を承認又は拒否すること等)を含み得る。いくつかの例において、1以上の実行可能なセレクションを選択することは、パブリッシャに、第2の情報を受信するよう動作させ得る。
図31において、フィード項目3122が、取引先ページ3116内に示される親レコードの情報フィード3104に含まれるように提示されている。ユーザDaniel Chengが新たな連絡先(子レコード)を作成した後、フィード項目3122が、取引先(親レコード)の情報フィード3104の上部に公開される。フィード項目3122は、実行可能なセレクション、すなわち、新たに作成された連絡先「Chuy Santiago」へのリンク3124を含む。ユーザはまた、コメントをフィード項目3122に対してポストすること、フィード項目3122にいいね又は良くないねを付すこと、又はフィード項目3122を共有することを含む様々なアクションをフィード項目3122に対して実行することができる。そのようなアクションは、他の関連フィード内に提示される同じフィード項目3122に影響を及ぼし得る。ユーザは、リンク3124を選択して、Cirrus, Inc.用の取引先レコードから、Chuy Santiago用の連絡先レコードに移動することができる。
図16Aに戻ると、ブロック1624aにおいて、フィード項目と相互参照されている1以上のエンティティが識別される。フィード項目の相互参照は、複数の方法により実現され得る。相互参照されているエンティティのアイデンティフィケーション(識別情報)(identification)は、相互参照用データ(cross-referencing data)から取得され得る。いくつかの実施例において、そのような相互参照用データは、APIから受信され得る。相互参照されるエンティティの数は無制限であり得、相互参照されるエンティティの各々は、APIにおけるペイロードにより定められ得る。例えば、ユーザは、APIのペイロード内に相互参照用データを定めることができる。いくつかの実施例において、ペイロード及び相互参照用データを提供するために、APIがパブリッシャにより利用される。
いくつかの実施例において、第1のレコードとインタラクトするリクエストを受信した後、パブリッシャに、第1のレコードの1以上のデータフィールドを表示させることができる。1以上のデータフィールドは、第1のレコードに関連付けられた第1の情報を受け入れるよう構成される。1以上のデータフィールドのうちの少なくとも1つは、フィード項目と相互参照される1以上のエンティティを定める相互参照用データを受け入れるよう構成される。相互参照されるエンティティは、ユーザ、グループ、組織、及びレコードを含み得る。いくつかの実施例において、相互参照用データは、ペイロード内のユーザ入力値により定められる等、ユーザにより定められ得る。
いくつかの他の実施例において、相互参照用データは、マシン又はシステムにより定められてもよい。すなわち、相互参照されているエンティティのアイデンティフィケーション(識別情報)は、ハードコードされたものであり得る。例えば、システム管理者又は親レコードの所有者は、相互参照用データのデフォルト値を設定することができる。いくつかの例において、相互参照されているエンティティは、第1のレコード及び第1のレコードの親レコードを含み得る。いくつかの例において、相互参照されているエンティティは、第1のレコード、第1のレコードの親レコード、第1のレコードの子レコード、第1のレコードにサブスクライブしているユーザ、第1のレコードとインタラクトしているユーザ、及び第1のレコードとインタラクトしているユーザをフォローしているユーザを含み得る。前述のエンティティの任意の数の組合せが、フィード項目と相互参照され得ることを理解されたい。
相互参照されているエンティティの識別は、レコード関連情報に少なくとも部分的に基づき得る。レコード関連情報は、データベースシステムから取得され得る。レコード関連情報は、子レコードが1つの親レコード又は複数の親レコードに関連していることを示すことができる。例えば、レコード関連情報は、データベースシステムにおいて取引レコードが複数の取引先レコードに関連していることを示すことができる。いくつかの例において、レコード関連情報は、子レコードがさらなる子レコードに対する親レコードであることを示すことができる。
第1のレコードのレコード関連情報は、フィード項目と相互参照されている1以上のエンティティのうちの少なくとも1つを判別するのに役立ち得る。フィード項目は、第1のレコードの親レコードの情報フィードに含まれるように提示されるので、フィード項目は、親レコード又は第1のレコードに関連する他のエンティティと相互参照され得る。どのエンティティが親レコード及び/又は第1のレコードに関連しているかは、レコード関連情報により提供され得る。例えば、フィード項目は、第1のレコードの複数の親レコードと相互参照され得る。
ブロック1628aにおいて、アップデートに関連付けられたフィード項目が、フィード項目と相互参照されている1以上のエンティティの1以上の情報フィード内に提供される。フィード項目がどこに伝播されるかは、相互参照用データ又はレコード関連情報に基づき得る。親レコードの情報フィード内に表示されるものと同じフィード項目が、複数のユーザ、グループ、組織、及びレコードにわたって伝播され、複数のユーザ、グループ、組織、及びレコードに対して表示され得る。結果として、単一の会話スレッドが、様々なユーザ、グループ、組織、及びレコードの情報フィード内に複数回公開され得る。複数のユーザ、グループ、組織、及びレコードとフィード項目を相互参照することは、異なる場所にフィード項目をコピー又は再ポストすることよりも好ましいものであり得る。異なる場所にフィード項目をコピー又は再ポストすることにより、オリジナルのフィード項目に対して取られるアクションは、オリジナルのフィード項目のコピー又はオリジナルのフィード項目の再ポストにおいては通常公開されない。これは、オリジナルのフィード項目上での複数の異なる会話スレッドと、フィードのオリジナルのフィード項目のコピーと、をもたらし得る。相互参照することで同じフィード項目を複数のエンティティにわたって伝播することにより、他のユーザは、複数のユーザインタフェース間を移動する必要なく、フィード項目とインタラクトすることができる、あるいは、フィード項目に対してアクションを別の形で実行することができる。例えば、フィード項目が、エンティティと相互参照されている場合、特定のレコードの協働者は、自分のニュースフィード、親レコードのレコードフィード、又は第1のレコードのレコードフィードから、フィード項目とインタラクトすることができる。
例えば、ユーザは、新たなタスクを作成することができる。新たなタスクを作成する際、ユーザは、このタスクを、商談及び案件に関連付けることができる。加えて、ユーザは、このタスクを10個の連絡先に関連付けることができる。パブリッシャによりこのタスクが作成されると、このタスクに関する情報がフィード項目に公開される。このフィード項目は、商談、案件、及び10個の連絡先と相互参照されているので、このフィード項目は、これらのエンティティの各々の情報フィード内に伝播される。
本明細書で先に説明されたように、通常、フィード項目は、親レコードの情報フィード内に公開される。しかしながら、フィード項目は、相互参照されているエンティティ又は関連エンティティの他の情報フィード内に伝播され公開され得る。例えば、ユーザが、取引先(すなわち、親レコード)のページから連絡先(すなわち、子レコード)を作成している場合、フィード項目は、少なくとも取引先レコードのフィード内に伝播され得る。いくつかの実施例において、フィード項目はまた、新たに作成された連絡先のレコードフィード内に伝播され得る。いくつかの実施例において、フィード項目はまた、新たに作成された連絡先の複数の親レコードの他のレコードフィード内に伝播され得る。いくつかの実施例において、フィード項目はまた、親レコード又は子レコードにサブスクライブされているユーザのニュースフィード内に伝播され得る。
図32A〜図32Cは、レコードに関連する様々な情報を表示しているユーザインタフェースを伴うレコードの一例を示している。詳細には、ユーザインタフェースは、レコードの情報フィードに関連する情報、レコード詳細、及びレコード関連情報を表示することができる。
図32Aは、取引先ページ3216の情報フィード3204を表示しているユーザインタフェースを伴うレコードの一例を示している。ユーザインタフェースはまた、パブリッシャ3202を含む。情報フィード3204は、Feed(フィード)タブ3208aを選択することにより閲覧することができる。情報フィード3204は、メッセージ、フィード追跡アップデート等を示す複数のフィード項目を表示することができる。
図32Bは、図32Aの取引先ページ3216のレコード詳細3210を表示しているユーザインタフェースを伴うレコードの一例を示している。レコード詳細3210は、Details(詳細)タブ3208bを選択することにより閲覧することができる。レコード詳細3210は、この取引先自体と、その1以上の親レコードと、についての情報を提供することができる。そのような情報はまた、関連レコード、ファイル、及びウェブサイトへのリンクを含み得る。ここで、レコード詳細3210は、Account Owner(取引先所有者)、Account Name(取引先名)、Website(ウェブサイト)、Billing Address(請求先住所)、Shipping Address(発送先住所)等といったCirrus, Inc.についての一般情報を表示している。ユーザのアクセスパーミッションに応じて、ユーザは、レコード詳細3210にアクセスする際、及び/又は、レコード詳細3210を編集する際、制限されることがある。
図32Cは、図32Aの取引先ページ3216のレコード関連情報3220を表示しているユーザインタフェースを伴うレコードの一例を示している。レコード関連情報3220は、Related(関連)タブ3208cを選択することにより閲覧することができる。レコード関連情報3220は、Cirrus, Inc.用の取引先レコードに関連するレコードをリストした情報を提供することができる。例えば、レコード関連情報は、Cirrus, Inc.に関連付けられた連絡先、商談、案件、タスク、及びイベントを含む、Cirrus, Inc.用の取引先レコードに関連する複数の子レコードを表示する。いくつかの例において、フィード項目について相互参照されているエンティティの識別は、レコード関連情報3220に少なくとも部分的に基づき得る。
図33A〜図33Cは、複数のレコード及びユーザプロフィールと相互参照されている単一のフィード項目の例を示している。図33Aは、いくつかの実施例に従った、パブリッシャ3302aからのアップデートされたデータを提示しているフィード項目3322aを含むレコードフィード3304aを伴う連絡先レコードの一例を示している。任意のユーザインタフェースからのパブリッシャ又はAPIは、フィード項目3322aを作成するために必要なアップデートされたデータを提供することができる。この例において、公開されたフィード項目3322aが、連絡先レコードページ3316a内のレコードフィード3304aに含まれるように提示されている。フィード項目3322aは、連絡先レコードに対して実行されたアクションと、このアクションのソースと、についての情報を含む。フィード項目3322aはまた、この連絡先の作成に付随させたメッセージポストからの情報を含む。フィード項目3322aは、コメントをフィード項目3322aにポストすること、フィード項目3322aにいいね又は良くないねを付すこと、及びフィード項目3322aを共有することを含むアクションをフィード項目3322aに対して実行するよう構成されているアクション3326aをさらに含む。そのようなアクション3326aは、単一の会話スレッドを作成するために、他の関連フィード内に伝播される同じフィード項目に影響を及ぼすよう構成され得る。
フィード項目3322aの作成は、図24〜図27に示される一連のアクションから新たな連絡先を作成した結果であり得る。図27は、取引先レコードの情報フィード2104内に表示されているフィード項目2422を示しているのに対し、図33Aは、連絡先レコードの情報フィード3304a内に表示されているフィード項目3322aを示している。図27のフィード項目2422は、図33Aのフィード項目3322aを表示するために、子レコードと相互参照され得る。いくつかの例において、異なる情報フィード内に表示される相互参照されているフィード項目は、異なる情報を提供することができる。例えば、フィード項目2422は、図27において、子レコードへのリンク2424を含むのに対し、フィード項目3322aは、そのようなリンクを含まない。
相互参照されているフィード項目は、異なるフィードにわたって伝播される同じフィード項目である。しかしながら、相互参照されているフィード項目は、コンテキストファクタに応じて異なるようにレンダリングされ得る。1つのそのようなコンテキストファクタは、ユーザが、ワークフローを承認できる役割又は定義を有するかどうか、又は、このような場合に、承認ボタンが相互参照されているフィード項目内に現れ得るかどうか等、相互参照されているフィード項目を閲覧しているユーザのプロフィールを含み得る。別のコンテキストファクタは、ページレイアウトが、ユーザのホームページであるか、親レコードのページであるか、子レコードのページであるか等、相互参照されているフィード項目が表示されるページレイアウトを含み得る。別のコンテキストファクタは、デバイスが、スマートフォンであるか、タブレットであるか、ラップトップであるか、又はデスクトップであるか等、相互参照されているフィード項目が提供されるデバイスのタイプを含み得る。したがって、相互参照されているフィード項目は同じ(例えば、データベースシステムのテーブル内の同じ行の情報)でありながら、相互参照されているフィード項目は、コンテキストに応じて異なる情報を提供することができる。例えば、相互参照されているフィード項目の前段部(preamble)又は補助的ボディ部(auxiliary body)は、異なるフィード内に異なる情報を提示することができる。
図33Bは、いくつかの実施例に従った、図33Aのフィード項目から相互参照されているフィード項目3322bと連絡先レコードへのリンク3324bとを含むニュースフィード3304bを伴うユーザプロフィールの一例を示している。この例において、図33Aの公開されたフィード項目3322aが、連絡先レコードページ3316a内のレコードフィードに含まれるように提示されるだけでなく、同じフィード項目が、ユーザプロフィールページ3316bのニュースフィード3304bに含まれるように、図33Bのフィード項目3322bとして提示される。ユーザプロフィールページ3316bは、連絡先レコードを作成したユーザ、連絡先レコードをアップデートしたユーザ、又は連絡先レコードに対してアクションを別の形で実行したユーザに対応し得る。ここで、ユーザプロフィールページ3316bは、連絡先レコードを作成したDaniel Chengに対応するものである。図33Aのフィード項目3322aと同様に、ニュースフィード3304b内のフィード項目3322bは、この連絡先レコードに対して実行されたアクションと、このアクションのソースと、この連絡先の作成に付随させたメッセージポストからの情報と、フィード項目3322bに対してアクションを実行するよう構成されたアクション3326bと、を含む。加えて、フィード項目3322bは、ユーザプロフィールページ3316bから図33Aの連絡先レコードページ3316aに効率的に移動するためにユーザが選択できるリンク3324bを含む。
図33Cは、いくつかの実施例に従った、図33Aのフィード項目から相互参照されているフィード項目3322cと連絡先レコードへのリンク3324cとを含むニュースフィード3304cを伴う別のユーザプロフィールの一例を示している。図33Bと同様に、図33Aからの同じフィード項目が、ユーザプロフィールページ3316cのニュースフィード3304c内に公開され得る。ユーザプロフィールページ3316cは、Daniel Chengをフォローしているユーザ、又は、親レコード又は連絡先レコードにサブスクライブしているユーザに対応し得る。ここで、ユーザプロフィールページ3316cは、親レコードにサブスクライブしているScott Perketに対応するものである。図33Aのフィード項目3322aと同様に、ニュースフィード3304c内のフィード項目3322cは、この連絡先レコードに対して実行されたアクションと、このアクションのソースと、この連絡先の作成に付随させたメッセージポストからの情報と、フィード項目3322cに対してアクションを実行するよう構成されたアクション3326cと、を含む。加えて、フィード項目3322cは、ユーザプロフィールページ3316cから図33Aの連絡先レコードページ3316aに効率的に移動するためにユーザが選択できるリンク3324cを含む。
XIV.フォロワへの相互参照
図16Bは、いくつかの実施例に従って実行される、オンラインソーシャルネットワークにおいてエンティティの1以上のフォロワによりアクセスされる相互参照されているフィード項目を公開するための、コンピュータにより実施される方法1600bの一例のフローチャートを示している。
方法1600bのブロック1604bにおいて、フィード項目を親エンティティのフィードに公開するリクエストが、コンピューティングデバイスにおいて受信される。親エンティティは、オンラインソーシャルネットワークのデータベースにおいて識別される。例えば、グループ、ユーザ、レコード、又はCRMオブジェクト等といった親エンティティに専用のページ上に配置されるパブリッシャは、フィード項目をこの親エンティティの情報フィードに公開するよう構成され得る。したがって、フィード項目は、階層データモデルにおける親エンティティの子として特徴付けられ得る。フィード項目は、図9Aに示されるテーブルを参照して上述したように、親エンティティに関連付けられたフィードテーブル等のデータベーステーブルに記憶され、そのようなデータベーステーブルにおいて識別され得る。例えば、フィード項目が取引先に公開される場合、この取引先のレコードフィードは、このフィード項目の親であり得る。フィード項目がユーザに公開される場合、このユーザのプロフィールフィードは、このフィード項目の親であり得る。
親エンティティは、1以上のフォロワを有し得る。あるエンティティがあるフィード項目の親である場合、このフィード項目はまた、この親エンティティをフォローしているユーザのニュースフィード内に公開される。例えば、あるフィード項目がある商談に公開される場合、この商談はこのフィード項目の親であり、この商談のフォロワも、自分のニュースフィード内でこのフィード項目を閲覧するためのアクセスを有する。図9Aを参照して上述したような様々なテーブルは、フィード項目を識別して、このフィード項目を、様々なエンティティと所与のエンティティのフォロワのニュースフィードとに関連付けることができる。
フィード項目は、通常、親エンティティ及びこの親エンティティのフォロワのフィードに公開されるが、フィード項目は、相互参照され、他のエンティティのフィード内に現れ得る。相互参照することは、1以上のエンティティを識別してフィード項目に関連付け、そのフィード項目が識別されたエンティティのフィード内に現れようにすることを指し得る。したがって、相互参照されているフィード項目は、相互参照されているエンティティに専用のフィード、及び相互参照されているエンティティをフォローしているユーザのニュースフィードを含む複数のフィード内に現れ得る。
いくつかの実施例において、方法1600bは、コンピューティングデバイスにより、パブリッシャを含むユーザインタフェースを生成するためのデータを提供することをさらに含み得る。パブリッシャは、情報を情報フィードに公開するよう構成され、パブリッシャは、相互参照される1以上のエンティティを選択するためのAPIを含む。ユーザは、パブリッシャとインタラクトして、相互参照用データを提供することができる。代替的に、相互参照用データは、ハードコードされたものであってもよい。フィード項目が相互参照されている場合、相互参照されているフィード項目は、親エンティティとは異なるエンティティのフィードに伝播される。相互参照されているフィード項目は、異なるフィードにわたって伝播される子フィード項目と同じフィード項目である。相互参照されているフィード項目は、あたかも親エンティティがそのような相互参照されているフィード項目の親であるかのように振る舞う。
方法1600bのブロック1608bにおいて、エンティティが、フィード項目と相互参照されているものとして識別される。この相互参照されているエンティティは、1以上のフォロワを有する。フォロワは、相互参照されているエンティティをフォローしているユーザ等の任意のエンティティであり得る。フォロワは、例えば、相互参照されているエンティティのフィードへのサブスクライバであり得る。いくつかの実施例において、エンティティを、フィード項目と相互参照されているものとして識別することは、フィード項目がエンティティと相互参照されていると判定するために処理され得るデータを記憶しているデータベースにアクセスすることを含む。フィード項目が、親エンティティのフィードに加えて、他のフィードにも公開されるように、相互参照されているエンティティは、親エンティティとは異なる。2以上のエンティティが、フィード項目と相互参照されているものとして識別され得る。このようなエンティティは、オンラインソーシャルネットワークのデータベースにおいて相互参照されているものとして示され得る。
いくつかの実施例において、相互参照されているエンティティは、ユーザ、グループ、組織、レコード、又はカスタムオブジェクトを含み得る。したがって、フィード項目は、親エンティティのフィードに加えて、少なくともユーザ、グループ、組織、レコード、又はカスタムオブジェクトのフィードにも関連付けられ得る。いくつかの実施例において、相互参照されているエンティティは、CRMオブジェクトであり得る。CRMオブジェクトは、リード、案件、取引先、商談、タスク、及び連絡先を含み得る。フィード項目と相互参照されているものとして識別されるエンティティの数は、無制限であり得るが、相互参照されているエンティティの実際の識別は、所定の潜在的エンティティ(potential entity)に制限され得る。いくつかの例において、潜在的エンティティは、レコード関連情報に少なくとも部分的に基づき得る。親エンティティに関連するレコードに関するデータが、1以上のデータベーステーブルに記憶され得、そのようなデータが、相互参照されているエンティティの識別を容易にするために、コンピューティングデバイスによりアクセスされ得る。レコード関連情報は、例えば、オンラインソーシャルネットワークにおいて取引レコードが複数の取引先レコードに関連していることを示すことができる。レコード関連情報は、タスクが割り当て者(assignor)、取引先、及びプロジェクトに関連していることを示すことができる。いくつかの例において、潜在的エンティティは、ユーザ入力に少なくとも部分的に基づき得る。
フィード項目を生成、識別、操作、又は公開するコード、又はフィード項目を識別する他のデータは、親エンティティとは異なるエンティティへの相互参照を指定することができる。そのようなコード及び/又はデータは、フィード項目が相互参照されるエンティティのフィード内に現れるようにするために提供され得る。いくつかの実施例において、親エンティティに関連付けられたデータベーステーブルは、相互参照されるエンティティの識別に関するデータを反映するためにアップデートされ得る。次いで、データベーステーブルにアクセスして、親エンティティフィードに対する将来のアップデートにおける相互参照を決定することができる。
いくつかの実施例において、相互参照用データが、相互参照されているエンティティを識別するためにAPIにおいて指定され得る。いくつかの実施例において、相互参照用データは、例えば、次の関数の引数において等、相互参照されているエンティティを識別するためのコード内で指定され得る:public FeedCrossReferenceData(String recordId, String networkId, FeedCrossReferenceTypeEnum referenceType)。recordIDは、親エンティティを識別する。FeedCrossReferenceTypeは、識別されたエンティティへの相互参照、識別されたエンティティのフォロワへの相互参照、又はこれら両方等の相互参照のタイプを識別する。アプリケーション設計者等のユーザは、フィード項目が親エンティティとは異なるフィード内に伝播されるように、1以上の相互参照されているエンティティを識別することができる。したがって、いくつかの実施例において、相互参照されているエンティティの識別は、フィードAPIにおいてなされ得、フィード項目と相互参照されているエンティティの識別は、フィードAPIを介したユーザ入力に応答するものであり得る。
方法1600bのブロック1612bにおいて、フィード項目を相互参照されているエンティティの1以上のフォロワに公開するリクエストが、コンピューティングデバイスにおいて受信される。いくつかの実施例において、このリクエストは、相互参照がトランジティブ(transitive)であるか否かを指定し得る。トランジティブな相互参照は、フィード項目を相互参照されているエンティティのフィード内に公開し得るとともに、フィード項目を相互参照されているエンティティのフォロワのニュースフィードフィード内に公開し得る。非トランジティブな相互参照は、フィード項目を相互参照されているエンティティのフィード内に公開し得るが、フィード項目を相互参照されているエンティティのフォロワのニュースフィードには公開しない。いくつかの実施例において、方法1600bは、フィード項目が、相互参照されているエンティティの1以上のフォロワに対してトランジティブであるかどうかを判定することをさらに含み得る。相互参照がトランジティブであるか否かは、フィードAPI等のAPIにおいて指定され得る。
いくつかの実施例において、方法1600bは、コンピューティングデバイスにおいて、相互参照されているエンティティによりアクセスされるフィード項目を公開するリクエストを受信すること、及び、相互参照されているエンティティのフィード内にフィード項目を表示するよう動作可能なディスプレイデバイスにフィード項目を提供することをさらに含み得る。したがって、フィード項目は、相互参照されているエンティティの情報フィードに加えて、相互参照されているエンティティのフォロワのニュースフィード内に表示され得る。
ユーザインタフェース内のパブリッシャが、相互参照される1以上のエンティティを選択するためのAPIを含む場合、ユーザは、APIを介して相互参照されるエンティティを識別することができる。例えば、相互参照される1以上のエンティティを選択するためのフィードAPIのクライアントは、フィード項目の伝搬(propagation)を制御することができる。クライアントは、相互参照される1以上のエンティティを識別して、相互参照がトランジティブであるか否かを判定することができる。したがって、フィード項目を相互参照されているエンティティ及び相互参照されているエンティティの1以上のフォロワに公開するリクエストを受信することは、APIを介したユーザ入力に応答するものであり得る。そのようなAPIを使用することにより、クライアントは、フィード項目の相互参照を管理することに加えて、副次的影響として生じ得る「ノイズ」を低減することが可能になり得る。すなわち、クライアントは、フィード項目が、相互参照されているエンティティのフォロワのうちの1つ、一部、又は全てに関連しないと判定することができ、それにより、フィード項目の伝播を、フィード項目に関連すると判定され得るフォロワに制限することができる。このように、クライアントは、所定のエンティティには不必要であり得る、あるいは所定のエンティティに関連しないものであり得るフィード項目を含むフィードが過剰に存在するのを避けることができる。
例えば、タスクに関するフィード項目は、そのタスクの情報フィードに対する子にされる。ユーザは、そのタスクの割り当て者及びそのタスクに関連付けられた商談への相互参照を指定することができる。その商談をフォローしているユーザが、そのタスクについてヒアリングすることに関心がある場合、その相互参照は、トランジティブであるとして指定され得る。結果として、フィード項目が、その商談をフォローしているユーザのニュースフィード内に現れ得る。しかしながら、そのタスクの割り当て者をフォローしているユーザが、その割り当て者が他の人に割り当てているタスクについてヒアリングすることに関心がない場合、その相互参照は、非トランジティブであるとして指定され得る。結果として、フィード項目は、その割り当て者をフォローしているユーザのニュースフィード内に現れない。
別の例において、クライアント取引先に対するアップデートに関するフィード項目は、その取引先の情報フィードに対する子にされる。ここで、そのアップデートは、発注の履行に関連する。ユーザは、その発注に関する販売者及びその発注に関連する取引への相互参照を指定することができる。その取引のフォロワは、その発注の履行についてヒアリングすることに関心があることもあれば、その販売者のフォロワは、その販売者が関与している発注の全てに関心があるわけではないこともある。その発注の履行に関するフィード項目は、その販売者のニュースフィード及びその取引のレコードフィードに加えて、その取引をフォローしているユーザのニュースフィードに対して相互参照され得るが、その販売者をフォローしているユーザのニュースフィードに対しては相互参照されない。
相互参照がトランジティブであるか否かを判定することは、関連性評価に基づき得る。フィード項目が、相互参照されているエンティティのフォロワに関連する場合、相互参照は、フォロワに対してトランジティブである。いくつかの実施例において、方法1600bは、フィード項目と相互参照されているエンティティのフォロワとの関連性を分析すること、及び、フィード項目が相互参照されているエンティティのフォロワに関連すると判定することを含み得る。このように判定されると、フィード項目を、相互参照されているエンティティだけでなく、相互参照されているエンティティのフォロワにも公開するリクエストがなされ得る。いくつかの実施例において、関連性評価は、ハードコードされたものであり得、アプリケーション設計者により作成された一連のルールに基づき得る。このようなルールは、エンティティへの相互参照がいつこのエンティティ自体に制限されるか、及び、エンティティへの相互参照がいつこのエンティティのフォロワを含むのかを判定することができる。
方法1600bのブロック1616bにおいて、フィード項目が、親エンティティ及び相互参照されているエンティティに関連付けられて、1以上のデータベーステーブルに記憶される。フィード項目は、1以上のフォロワによりアクセス可能な複数の情報フィード内に表示され得る。1以上のフォロワによりアクセス可能な複数の情報フィードは、親エンティティのフィードと1以上のフォロワの1以上のフィードとを含み得る。いくつかの実施例において、方法1600bは、フォロワによりアクセス可能な複数の情報フィード(親エンティティのフィード、相互参照されているエンティティのフィード、及びフォロワのニュースフィード等)のうちの1つの情報フィード内にフィード項目を表示するよう動作可能なディスプレイデバイスに、フィード項目を提供することをさらに含み得る。
フォロワの情報フィード内のフィード項目は、親エンティティのフィード内に提示されるものと同じフィード項目である。相互参照されているフィード項目は、あたかも相互参照されているエンティティ自体から子にされたフィード項目であるかのように操作及び処理されるよう構成される。実際、同じフィード項目が、親エンティティのフィード、相互参照されているエンティティのフィード、及びフォロワのニュースフィード内に公開される。したがって、コメント、いいね、及び良くないね等を含む同じ会話スレッドが、親エンティティ、及び相互参照されているエンティティのフォロワにおいて公開される同じフィード項目の各々に伝播され得る。しかしながら、親エンティティ、及び相互参照されているエンティティのフォロワにおいて公開されるフィード項目が、単一の親から生じたかのように同じように振る舞うが、フィード項目が、親エンティティにおいてどのようにレンダリングされるかと、フィード項目が、相互参照されているエンティティ及び/又は相互参照されているエンティティのフォロワにおいてどのようにレンダリングされるかと、は、以下で説明されるように異なり得る。
相互参照されているエンティティの情報フィード又はフォロワの情報フィード内に提示されるフィード項目は、ディスプレイデバイスにおいて、情報をユーザインタフェースに公開することができる。しかしながら、公開される情報は、1以上のコンテキストファクタに依存し得る。いくつかの実施例において、公開される情報は、フィード項目が含まれる選択された情報フィードのソースに少なくとも部分的に応じて、異なるようにレンダリングされ得る。例えば、フィード項目の前段部又は補助的ボディ部は、ユーザのニュースフィード内に含まれる場合と、CRMレコードのレコードフィード内に含まれる場合とで、異なる情報を公開することができる。いくつかの実施例において、公開される情報は、ディスプレイデバイスのタイプに少なくとも部分的に応じて、異なるようにレンダリングされ得る。例えば、スマートフォンではなくラップトップのディスプレイ上に提示される場合には、フィード項目に関して、より多くの情報が公開され得る。
フィード項目は、相互参照されているエンティティのフォロワに伝播され得るが、相互参照されているエンティティのフォロワの全てが、フィード項目を閲覧することを許可されるわけではない。エンティティが親エンティティにアクセスするためのパーミッションを有さない場合にはそのエンティティが相互参照されているフィード項目を閲覧するのを防止するために、方法1600bにおいて、アクセスチェックが実施され得る。いくつかの実施例において、方法1600bは、親エンティティに対するフォロワのアクセスパーミッションを識別すること、及び、フォロワが、親エンティティの情報フィードを閲覧するためのパーミッションを有すると判定することをさらに含み得る。しかしながら、相互参照されているエンティティのフォロワが、親エンティティの情報フィードを閲覧するためのパーミッションを有していないと判定された場合、フォロワは、フィード項目を閲覧することができない。
XV.データオブジェクトのためのカスタムアクション
図17は、いくつかの実施例に従って実行される、情報をオンラインソーシャルネットワークの情報フィードに公開するよう構成されたパブリッシャから1以上のデータオブジェクトとインタラクトするための、コンピュータにより実施される方法1700の一例のフローチャートを示している。図17は、図34〜図51Cを参照して説明される。
ブロック1704において、1つのコンピューティングデバイス、又は、方法1700を実行するために協働する任意の数のコンピューティングデバイスは、カスタムアクションを伴うパブリッシャを含むユーザインタフェースを生成するためのデータを提供することができる。カスタムアクションは、アプリケーションプログラミングインタフェース(API)を介して第1のエンティティにより提供されるカスタムアクション命令に従ってデータオブジェクトとインタラクトするよう構成される。データオブジェクトは、データベースシステムに記憶されている、あるいは、データベースシステムに記憶されるよう構成されている。データオブジェクトは、データベースサービスにより定義されたデータ構造(標準オブジェクト)又はユーザにより定義されたデータ構造(カスタムオブジェクト)を有し得る。
パートナ又は顧客等のユーザ又は組織は、パブリッシャ内に含まれるようにカスタムアクションを定義したいと望むことがある。ユーザ又は組織は、ユーザ又は組織が独自のカスタムアクションを作成することを可能にするフレームワーク又は機能を提供することができるAPIを利用することができる。カスタムアクションは、パブリッシャを通じてデータオブジェクトに関連するデータの処理を可能にする。パブリッシャアクションと同様に、カスタムアクションは、レコードを作成すること、レコードを削除すること、レコードに関連付けられたデータを編集すること、レコードにアクションを記録すること、レコードを変換すること、レコードからデータをダウンロードすること、レコードにデータをアップロードすること、レコードにファイルを添付すること、及びレコードに関連付けられた情報を閲覧すること等のオペレーションを実行することができる。例えば、レコードにアクションを記録する際、カスタムアクションは、電子メールを送信し、次いで、その電子メールをレコードに記録するよう構成され得る、あるいは、カスタムアクションは、LinkedIn(登録商標)及びTwitter(登録商標)等の別のオンラインソーシャルネットワークにポストし、次いで、そのポストをレコードに記録するよう構成され得る。カスタムアクションは、レコードのネットワークドメインの外部での挙動を有するアクションを実行することができる。
いくつかの実施例において、カスタムアクションは、組織内の複数のユーザ又は組織に関連付けられた複数のユーザに利用可能にされ得る。代替的又は追加的に、組織等の第1のエンティティにより作成されるカスタムアクションは、他の組織及びユーザによる使用のために提供されてもよい。データベースサービスプロバイダは、カスタムアクション等のアプリケーションを作成するエンティティが、アプリケーションを他のエンティティに自由に配布し、販売し、あるいはアプリケーションを他のエンティティと自由に交換するマーケットプレース又は交換場所(exchange)を提供することができる。
データベースサービスのユーザインタフェースは、ユーザがカスタムアクションを作成することを可能にし得る。カスタムアクションを作成するためのデータベースサービスの例は、salesforce.com(登録商標)により提供されるForce.com(登録商標)及びWork.com(登録商標)を含み得る。ユーザ又は組織はまた、Chatter(登録商標)を含むオンラインソーシャルネットワーク内で新たなカスタムアクションを作成することもできる。ユーザは、宣言的又はプログラム的に、新たなカスタムアクションを作成することができる。
いくつかの実施例において、方法1700は、コンピューティングデバイスにおいて、ユーザからカスタムアクション命令を受け取ることをさらに含み得る。ここで、カスタムアクション命令は、データオブジェクトを定義するとともに、データオブジェクトに関連付けられる1以上のデータフィールドを定義するよう構成される。クライアントマシンから、ユーザは、データベースサービスにアクセスし、APIを利用して、カスタムオブジェクトのクライアントサイドスクリプト命令を作成することができる。いくつかの実施例において、APIは、ユーザが、カスタムアクションを伴うパブリッシャを作成するために、ソースコード及びコンピューティング環境への制限されたアクセスを有することを可能にし得る。
図34は、いくつかの実施例に従った、ユーザがカスタムアクションを作成するよう構成されたデータベースサービスのユーザインタフェースの一例を示している。ユーザは、ドロップダウンタブ「Customize(カスタマイズ)」3402を選択し、次いで、ドロップダウンタブ「Accounts(取引先)」3404を選択し、次いで、ドロップダウンタブ「Buttons, Links, and Actions(ボタン、リンク、及びアクション)」3406を選択することにより、APIを用いてカスタムアクションの作成を開始することができる。「Buttons, Links, and Actions(ボタン、リンク、及びアクション)」タブ3406を選択することは、ユーザインタフェースに、カスタムアクションの作成に関する情報に加えて、最近作成されたカスタムアクションのリスト3408を表示させる。ユーザインタフェースは、新たなカスタムアクションの作成を開始するためのボタン3410をさらに含む。
ユーザは、データベースサービスから、APIを用いてカスタムアクションの作成を開始することができるが、ユーザは、オンラインソーシャルネットワーク自体の中で、APIを用いてカスタムアクションの作成を開始することもできる。図35は、いくつかの実施例に従った、ユーザがパブリッシャ3502からカスタムアクションを作成するよう構成されたパブリッシャ3502を含むユーザインタフェースの一例を示している。オンラインソーシャルネットワークにおけるユーザインタフェースは、パブリッシャ3502及び情報フィード3504を表示することができる。ユーザは、ドロップダウンメニューを生成する、パブリッシャ3502内のアクションのレイアウトから「More(さらに)」3506を選択し、次いで、ドロップダウンメニューから「Customize(カスタマイズ)」3508を選択することにより、カスタムアクションの作成を開始することができる。
ユーザは、任意の数のユーザインタフェースにおいて任意の数の経路(pathway)を用いて、カスタムアクションの作成を開始することができることを理解されたい。例えば、ユーザインタフェース内のパブリッシャから分離されている制御領域(control region)が、ユーザが、タブ、チャンネル、又はボタンを選択して、カスタムアクションの作成を開始することを可能にしてもよい。データベースサービス又はオンラインソーシャルネットワークからの検索クエリツールが、ユーザが、リンクを選択して、カスタムアクションの作成を開始することを可能にする結果を表示してもよい。
カスタムアクションの作成を開始した後、ユーザは、カスタムアクションに関連付けられたカスタムアクション命令を提供することができる。カスタムアクション命令は、データオブジェクトとデータオブジェクトに関連付けられる1以上のデータフィールドとを定義することができる。図36は、いくつかの実施例に従った、カスタムアクションを作成するためのカスタムアクション定義領域3602を含むユーザインタフェースの一例を示している。ユーザインタフェースは、複数のカスタムフィールド3604〜3620を含むカスタムアクション定義領域3602と、ページレイアウト領域3622と、を含む。ユーザは、カスタムフィールド3604〜3620の各々に値を提供することにより、APIを利用するカスタムアクション命令を定義することができる。
いくつかの実施例において、APIは、データベースサービスプロバイダ等のエンティティにより提供され得、カスタムアクションのオペレーションのうち少なくともいくつかを実行する予め定義された命令のセットを含む。予め定義された命令は、例えば、Javascript(登録商標)、Java(登録商標)、Apex、又は、カスタムアクションのオペレーションのうち少なくともいくつかを実装するための任意の他のプログラミング言語において提供され得る。このようなオペレーションは、多くのカスタムアクション又は全てのカスタムアクションに共通する可能性が高いオペレーションを含み得る。例えば、そのような命令は、カスタムアクションを表示するためのユーザインタフェースの領域を作成することに関与するもの、クライアントマシンからのカスタムアクションがトリガしたメッセージの受信を処理することに関与するもの、アップデートされたカスタムアクションメッセージをクライアントマシンに送信することに関与するもの、及び他のそのようなオペレーションであり得る。
したがって、ユーザは、図36のカスタムフィールド3604〜3620に定義を提供して、APIとインタラクトするカスタムアクション命令を提供することができる。カスタムアクション命令は、APIに提供されている予め定義された命令と直接的に統合され得る。
カスタムアクション命令における定義のうちの1つは、Object Name(オブジェクト名)3604を含み得る。いくつかの実施例において、カスタムアクションの作成を開始したソースに基づいて、デフォルト値が提供され得る。カスタムアクション命令における別の定義は、Action Type(アクションタイプ)3606を含み得る。Action Type(アクションタイプ)3606は、データオブジェクトとインタラクトするために実行されるアクションのタイプを示す値を表示する。いくつかの実施例において、Action Type(アクションタイプ)3606は、データオブジェクトとインタラクトすることに限定されるものではなく、サードパーティアプリケーション又はコンテンツを公開すること等の他のアクションも含み得る。そのようなアクションはセクションXにおいてより詳細に説明されている。いくつかの実施例において、ユーザは、Action Type(アクションタイプ)3606において、とりわけ、Create a Record(レコードを作成する)、Create a Custom Page(カスタムページを作成する)(例えば、カスタムVisualforceページ)、及びUpdate a Record(レコードをアップデートする)等の可能な値のリストから選択することができる。他の可能なアクションは、Log a Call(要求のログを取る)、Send Email(電子メールを送信する)、Send SMS(SMSを送信する)、Change Status(ステータスを変更する)、Social Post(ソーシャルポスト)、Canvas、及びAuraを含み得る。
カスタムアクション命令におけるさらなる定義は、Target Object(ターゲットオブジェクト)3608を含み得る。Target Object(ターゲットオブジェクト)3608は、カスタムアクションがインタラクトするよう構成されるデータオブジェクトを表す。いくつかの実施例において、Target Object(ターゲットオブジェクト)3608内に提供される値は、親レコードの子レコードを含む。子レコード及び親レコードは、リード、案件、取引先、商談、タスク、連絡先、キャンペーン、契約、イベント、カスタムオブジェクト、及びVisualforceページ等のCRMオブジェクトであり得る。カスタムアクション命令における他の定義は、Record Type(レコードタイプ)3610、Relationship Field(関連フィールド)3612、Label(ラベル)3614、API Name(API名)3616、Description(説明)3618、及びIcon(アイコン)3620を含み得る。カスタムフィールドのうちのいくつかの表示は、Action Type(アクションタイプ)3606に依存し得る。図36において、Action Type(アクションタイプ)3606を「Create a Record(レコードを作成する)」に定義することは、ユーザインタフェースにカスタムフィールド3608〜3616を表示させる。
さらに、ユーザは、ページレイアウト領域3622内で、カスタムアクションが現れるページを定義することにより、さらなるカスタムアクション命令を提供することができる。したがって、カスタムアクションは、オンラインソーシャルネットワークにおける指定されたページ上でアクセス可能であり得る。
図17の方法1700に戻ると、ブロック1704におけるカスタムアクションを伴うパブリッシャを含むユーザインタフェースを生成するためのデータは、カスタムアクションがユーザインタフェース内に表示されるかどうかを判定し得る。このデータは、上述したように、カスタムアクションが提供されるページに関するカスタムアクション命令を含み得る。加えて、このデータは、カスタムアクションにアクセスするためのパーミッションを有するエンティティに関するカスタムアクション命令を含み得る。カスタムアクションは、組織内の全てのユーザに提供され得る。代替的に、カスタムアクションは、グループ等の複数人のユーザの特定のサブセットに限定されてもよい。
カスタムアクション命令はまた、データオブジェクトに関連付けられる1以上のデータフィールドを定義するよう構成され得る。図37Aは、いくつかの実施例に従った、カスタムアクションに関連付けられたデータフィールド3710を表示しているアクションレイアウトエディタ3702用のユーザインタフェースの一例を示している。データフィールド3710の各々は、データオブジェクトに提供される情報を表すことができる。いくつかの実施例において、この情報はユーザから生成され得る。いくつかの実施例において、この情報はマシン又はシステムから生成され得る。データフィールド3710のうちのいくつかはまた、入力の必須フィールドであるよう構成され得る。
「Fields(フィールド)」オプション3706を選択することにより、ユーザは、アクションレイアウトエディタ3702を用いて、カスタムアクションに関連付けられるようデータフィールド3710を構成することができる。アクションレイアウトエディタ3702は、カスタムアクションに関連付けられ得る複数の利用可能なフィールド3704を含む。利用可能なフィールド3704の例は、とりわけ、First Name(名)、Last Name(姓)、Phone(電話番号)、Email(電子メールアドレス)、Birthday(誕生日)、Last Modified(最終変更)、Created By(作成者)、Opportunity Name(商談名)、Account Name(取引先名)、Next Step(次のステップ)、Amount(数量)、Close Date(クローズ日)、Stage(段階)、及びDescription(説明)を含む。
利用可能なフィールド3704は、利用可能なフィールド3704のうちの1つをカスタマイズ可能なパブリッシャスペース3708にドラッグアンドドロップすることにより、カスタムアクションに関連付けられたデータフィールド3710になり得る。図37Bは、さらなるデータフィールド3712がカスタムアクションに関連付けられているアクションレイアウトエディタ3702用のユーザインタフェースの一例を示している。ユーザは、データフィールド3710のアクションレイアウトを決定するために、さらなるデータフィールド3712をカスタマイズ可能なパブリッシャスペース3708内に配置させることができる。いくつかの実施例において、パブリッシャスペース3708内に配置され得るデータフィールド3710の数又はタイプを制限するために、制限を管理することが課せられ得る。
アクションレイアウトは、パブリッシャ内でのデータフィールドの配置を表す。カスタムアクションのアクションレイアウトは、APIに応じて異なり得る。図38Aは、いくつかの実施例に従った、カスタムアクションに関連付けられたデータフィールド3810aの表示をプレビューしているウィンドウの一例を示している。ここで、カスタマイズ可能なパブリッシャスペース3808a内でのデータフィールド3810aの配置が、2列の配置で示されている。データフィールド3810aのこの配置は、デスクトップディスプレイデバイス、ラップトップディスプレイデバイス、又はタブレットディスプレイデバイス等の、ワイドスクリーンを有するディスプレイデバイスにおいて表示するのに有用であり得る。
図38Bは、他の実施例に従った、カスタムアクションに関連付けられたデータフィールド3810bの表示をプレビューしているウィンドウの一例を示している。ここで、カスタマイズ可能なパブリッシャスペース3808b内でのデータフィールド3810bの配置が、1列の配置で示されている。データフィールド3810bのこの配置は、スマートフォンディスプレイデバイス又は他のモバイルディスプレイデバイス等の、ナロースクリーンを有するディスプレイデバイスにおいて表示するのに有用であり得る。
カスタムアクション命令はまた、パブリッシャ内でのカスタムアクションのページレイアウトを定義するよう構成され得る。図39は、いくつかの実施例に従った、レコードに関連付けられたパブリッシャアクション3908を表示しているページレイアウトエディタ3902用のユーザインタフェースの一例を示している。パブリッシャアクション3908の各々は、データオブジェクトに対して実行され得る、あるいはデータオブジェクトを参照して実行され得るアクションを表す。
「Actions(アクション)」オプション3906を選択することにより、ユーザは、ページレイアウトエディタ3902を用いて、特定のページレイアウト用にパブリッシャアクション3908を構成することができる。ページレイアウトは、異なるレコード、グループ、ユーザ、及び組織用のページに対して異なり得る。例えば、連絡先を作成するためのパブリッシャアクション3908は、パートナ取引先ページ上には表示され得るが、顧客取引ページ上には表示されない。ページレイアウトエディタ3902は、ページレイアウトに含まれ得る複数の利用可能なアクション3904を含む。利用可能なアクション3904の例は、とりわけ、Contact(連絡先)、File(ファイル)、Link(リンク)、Log a Call(要求のログを取る)、Opportunity(商談)、Polls(投票)、Post(ポスト)、Task(タスク)、及びThanks(感謝)を含む。
利用可能なアクション3904は、利用可能なアクション3904のうちの1つをパブリッシャのページレイアウトにドラッグアンドドロップすることにより、パブリッシャアクション3908になり得る。利用可能なアクション3904のうちの1つは、カスタムアクション3910であり得る。ユーザは、パブリッシャ内でのカスタムアクション3910のページレイアウトを決定するために、1以上のパブリッシャアクション3908の間にカスタムアクション3910を配置させることができる。ページレイアウトは、パブリッシャ内でのパブリッシャアクション3908に対するカスタムアクション3910の配置を表し得る。パブリッシャアクション3908用の領域は、パブリッシャの特定の領域に制限され得る。パブリッシャアクション3908を制限された領域に制限することにより、パブリッシャアクション3908が、パブリッシャの残りの領域がどのように表示されるかを変更するのを防止することができる。
図40は、いくつかの実施例に従った、詳細4006、ページレイアウト4008、及び、カスタムアクションに関連付けられた予め定められたフィールド値4010を表示しているユーザインタフェースの一例を示している。カスタムアクションを作成した後、ユーザは、ページ4002にアクセスして、カスタムアクションに関する情報を閲覧することができる。ユーザは、複数のボタン4004のうちの1つを選択して、カスタムアクションのアクションレイアウトを編集することができる、あるいは、カスタムアクションを編集、複製、又は削除することができる。詳細4006は、カスタムアクションのカスタムフィールドに提供された定義を表示する。ページレイアウト4008は、カスタムアクションが現れる指定のページを表示する。予め定められたフィールド値4010は、予め定められた値又はデフォルト値を有するデータフィールドを表示する。ユーザは、New(新たに追加)ボタン4012を選択することにより、新たな予め定められた値又はデフォルト値を追加することができ、Edit(編集)リンク4014を選択することにより、指定されたデータフィールドにおける予め定められた値又はデフォルト値を編集することができ、あるいは、Del(削除)リンク4016を選択することにより、指定されたデータフィールドにおける以前の予め定められた値又はデフォルト値を削除することができる。
図41は、いくつかの実施例に従った、カスタムアクションに関連付けられた予め定められたフィールド値を編集又は追加するためのユーザインタフェースの一例を示している。ユーザは、複数のデータフィールドから1つのデータフィールド4102を選択して、予め定められた値又はデフォルト値を指定することができる。ユーザは、フィールドスペース4104内で値を定めることができる。ここで、この値は、単語、語句、文、質問、感情表現、及び/又は記号等の英数字の入力又は他の文字ベースの入力であり得る。しかしながら、フィールドスペース4104内で定められる値は、変数であってもよい。ユーザは、関数4106をフィールドスペース4104に追加して、値又は変数に対して関数を実行することができる。
データフィールド用の予め定められた値又はデフォルト値を設定することにより、パブリッシャからカスタムアクションを開始するいかなるユーザにも、データフィールドにおける予め定められた値又はデフォルト値がすでに提供されていることになる。いくつかの実施例において、データフィールドにおける予め定められた値又はデフォルト値は、変更することができない。
いくつかのカスタムアクションは、アクセスされているページ又はユーザアクセスパーミッションに応じてユーザインタフェース内での表示に制限され得るが、いくつかのアクションは、そのように制限されなくてもよい。そのようなアクションは、グローバルアクションと呼ばれ得る。図42〜図44は、グローバルアクションを作成する異なる態様のユーザインタフェースを示している。
図42は、いくつかの実施例に従った、ユーザがグローバルアクションを作成するよう構成されたデータベースサービスのユーザインタフェースの一例を示している。ユーザは、ドロップダウンタブ「Create(作成)」4202を選択し、次いで、ドロップダウンタブ「Global Actions(グローバルアクション)」4204を選択することにより、APIを用いてグローバルアクションの作成を開始することができる。「Global Actions(グローバルアクション)」タブ4204を選択することは、ユーザインタフェースに、グローバルアクションの作成に関する情報に加えて、最近作成されたグローバルアクションのリスト4208を表示させる。ユーザインタフェースは、新たなグローバルアクションの作成を開始するためのボタン4210をさらに含む。ユーザは、任意の数のユーザインタフェースにおいて任意の数の経路を用いて、グローバルアクションの作成を開始することができることを理解されたい。
グローバルアクションの作成を開始した後、ユーザは、グローバルアクションに関連付けられたグローバルアクション命令を提供することができる。図43は、いくつかの実施例に従った、グローバルアクションを作成するためのグローバルアクション定義領域4302を含むユーザインタフェースの一例を示している。グローバルアクション命令の提供は、本明細書で先に説明されているカスタムアクション命令の提供と同じやり方で又は同様のやり方で行うことができる。しかしながら、グローバルアクションは、オンラインソーシャルネットワークにおける所定のページに必ずしも限定されるものではなく、詳細ページ、ホームページ、及びChatter(登録商標)ページを含むより広範なページにわたって表示され得る。
ユーザインタフェースは、グローバルアクション定義領域4302を含み、グローバルアクション定義領域4302は、複数のグローバルフィールド4304〜4312を含む。グローバルアクション定義領域4302内のグローバルフィールド4304〜4312の数は、カスタムアクションを作成するためのカスタムフィールドの数よりも少なくてよい。なぜならば、ユーザは、関連性及び他の情報を指定する必要がないからである。
ユーザはまた、ページレイアウト領域4314内で、グローバルアクションが現れるページを定義することにより、さらなるグローバルアクション命令を提供することができる。ここで、選択することができるページは、操作されるデータオブジェクトと親子関係を有するページに限定されるものではなく、選択することができるページは、オンラインソーシャルネットワークにわたるページを含む。
グローバルアクション命令は、パブリッシャ内でのグローバルアクションのページレイアウトを定義するよう構成され得る。図44は、いくつかの実施例に従った、オンデマンドデータベースサービス環境に関連付けられたパブリッシャアクション4408を表示しているページレイアウトエディタ4402用のユーザインタフェースの一例を示している。パブリッシャアクション4408の各々は、オンラインソーシャルネットワークにわたる複数のページのいずれかから、データオブジェクトに対して実行され得る、あるいはデータオブジェクトを参照して実行され得るアクションを表す。
「Actions(アクション)」オプション4406を選択することにより、ユーザは、ページレイアウトエディタ4402を用いて、パブリッシャアクション4408を構成することができる。ページレイアウトエディタ4402は、パブリッシャ内に含まれ得る複数の利用可能なアクション4404を含む。利用可能なアクション4404は、利用可能なアクション4404のうちの1つをパブリッシャのページレイアウトにドラッグアンドドロップすることにより、パブリッシャアクション4408になり得る。ユーザは、パブリッシャのページレイアウトを決定するために、1以上のパブリッシャアクション4408の間に利用可能なアクション4404を配置させることができる。
図45は、いくつかの実施例に従った、パブリッシャ内に表示されるパブリッシャアクションを選択するためのウィンドウ4502の一例を示している。ユーザは、ホームページ、又は、ユーザがパブリッシャアクションの表示をカスタマイズするためのパーミッションを有するページからウィンドウ4502を開くことにより、パブリッシャ内に表示されるパブリッシャアクションをカスタマイズすることができる。ユーザは、利用可能なアクション4504のプールから選択済みアクション4506のプールにパブリッシャアクションを追加することができる。同様に、ユーザは、選択済みアクション4506から利用可能なアクション4504の領域にパブリッシャアクションを除去することができる。
図46A〜図46Bは、いくつかの実施例に従った、モバイルデバイスアプリケーション用の、カスタムアクション4606を伴うパブリッシャ4602と情報フィード4604とを含むユーザインタフェースの一例を示している。パブリッシャ4602内のカスタムアクション4606は、APIとインタフェースをとって、情報を情報フィード4604に公開することができる。モバイルアプリケーション及び様々な他のアプリケーションは、同じAPIと通信して、パブリッシャの同じ基本機能を実行することができる。
パブリッシャ4602は、複数のパブリッシャアクション4606を含む。いくつかの実施例において、パブリッシャアクション4606のうちの少なくとも1つは、カスタムアクションであり得る。いくつかの実施例において、パブリッシャ4602の上に指を乗せ、パブリッシャ4602を横方向にスライドさせることにより、さらなるパブリッシャアクション4606にアクセスすることができる。ユーザインタフェース内のボタン4608により、ユーザは、パブリッシャアクション4606を表示させること、又はパブリッシャアクション4606を隠すことが可能になり得る。実際、ボタン4608は、管理者によりインストール/構成されたアクションの予め定められたリストからのアクションを含むより多くのパブリッシャアクションを表示させるよう構成される。
いくつかの実施例において、カスタムアクションは、組織内の複数のユーザ又は組織に関連付けられた複数のユーザに利用可能にされ得る、あるいは、他の組織及びユーザによる使用のために提供され得る。Appexchange(アプリケーション交換)カスタムアクション4610は、カスタムアクション等のアプリケーションを作成するユーザが、アプリケーションを他のエンティティに自由に配布し、販売し、あるいはアプリケーションを他のエンティティと自由に交換することを可能にし得る。
図17に戻ると、ブロック1708において、データオブジェクトとインタラクトするリクエストが、第2のエンティティから、ユーザインタフェース内のカスタムアクションの選択を介して、受信される。いくつかの実施例において、第2のエンティティは、第1のエンティティとは異なるユーザ又は組織である。いくつかの実施例において、第2のエンティティは、第1のエンティティと同じユーザ又は組織である。
方法1700は、第2のエンティティがデータオブジェクトとインタラクトするためのパーミッションを有するかどうかを判定することをさらに含み得る。第2のエンティティのアクセスパーミッションに応じて、第2のエンティティがインタラクトできるデータオブジェクトに対して制限が課せられ得る。そのような制限は、例えば、とりわけ、システム管理者、データオブジェクトの所有者、又は組織のセキュリティ/パーミッションポリシにより設定され得る。
いくつかの実施例において、データオブジェクトとインタラクトするリクエストは、データオブジェクトを作成するリクエスト、データオブジェクトを削除するリクエスト、データオブジェクトをアップデートするリクエスト、データオブジェクトを変換するリクエスト、データオブジェクトからデータをダウンロードするリクエスト、データオブジェクトにデータをアップロードするリクエスト、データオブジェクトにファイルを添付するリクエスト、データオブジェクトに関連付けられた情報を閲覧するリクエスト、及びデータオブジェクトを参照するオペレーションを他の形で実行するリクエストを含み得る。
データオブジェクトとインタラクトするリクエストは、ユーザがユーザインタフェース内のカスタムアクションを選択したことに応じて生成され得る。いくつかの実施例において、カスタムアクションの選択は、パブリッシャ内に表示されているユーザインタフェースコンポーネントからのユーザ入力から生じてもよい。パブリッシャ内に表示されているそのようなユーザインタフェースコンポーネントの選択の例は、図21B、図24、及び図28〜図30に示されるパブリッシャアクション又はカスタムアクションを含む。さらに、ユーザインタフェースコンポーネントは、カスタマイゼーションツールから作成されたカスタマイズされたグラフィカルユーザインタフェースの一部であり得る。パートナ又は顧客は、Visualforce等のカスタマイゼーションツールを用いて、自分の好みに応じて、ユーザインタフェースコンポーネント及びパブリッシャのビジュアル表現をカスタマイズすることができる。そのようなカスタマイゼーションツールは、ユーザが、オンデマンドサービス環境によりネイティブにホストされ得るカスタムユーザインタフェースを構築することを可能にするフレームワークを提供することができる。Visualforceのようなカスタマイゼーションツールを利用するユーザは、カスタマイズされたユーザインタフェースコンポーネントをパブリッシャに追加することができる。したがって、パブリッシャは、レコードとの全てのユーザインタラクションのためのインタフェースとして機能することができ、異なるアクションを要する異なるアプリケーション、デバイス、又はウィンドウの必要性をなくすことができる。
いくつかの実施例において、カスタムアクションの選択は、パブリッシャの外部に表示されているユーザインタフェースコンポーネントからのユーザ入力から生じてもよい。パブリッシャの外部に表示されているそのようなユーザインタフェースコンポーネントの選択の例は、図47A〜図47B及び図48A〜図48Bの実行可能なセレクションを含む。
図47A〜図47Bは、いくつかの実施例に従った、オンデマンドデータベースサービス環境のためのデータベースシステム内を検索するためのルックアップツール4702の一例を示している。ユーザは、ルックアップクエリを実行するために、英数字の入力又は他の文字ベースの入力をボックス4704に提供することができる。いくつかの実施例において、ルックアップクエリが送信された後、結果のリストが表示され得る。例えば、ルックアップクエリは、ユーザのリスト、組織のリスト、グループのリスト、又はレコードのリストを返させることができる。ユーザは、ユーザインタフェースコンポーネント(図示せず)を選択して、ユーザ、組織、グループ、及びレコードのうちの1つに対してアクションを実行することができる、あるいは、ユーザ、組織、グループ、及びレコードのうちの1つを参照してアクションを実行することができる。いくつかの実施例において、ルックアップクエリは、結果を返させないこともあり、ユーザは、ユーザインタフェースコンポーネント(図示せず)を選択して、レコード等の新たなエンティティを作成することができる。例えば、図47Bにおいて、ルックアップクエリが結果を返させなかった結果として、ユーザは、新たな連絡先を作成することを選択し、複数のデータフィールド4706とともにパブリッシャをユーザインタフェース内に表示させることができる。
図48A〜図48Bは、いくつかの実施例に従った、オンデマンドデータベースサービス環境におけるデータベースシステム内を検索するための検索クエリツール4802の一例を示している。ユーザインタフェースから、ユーザは、英数字の入力又は他の文字ベースの入力をボックス4804に提供することができる。いくつかの実施例において、ユーザが検索クエリのための入力を提供しているときに、オートコンプリートオペレーションに従って、結果が同時に表示され得る。代替的又は追加的に、検索クエリが送信された後、結果が表示されてもよい。いくつかの実施例において、検索クエリは、アクション4806のリストを返させることができる。ユーザは、それらアクション4806のうちの1つを選択して、複数のデータフィールド4808とともにパブリッシャをユーザインタフェース内に表示させることができる。
図17に戻ると、ブロック1712において、データオブジェクトに関連付けられた1以上のデータフィールドのための第1の情報が、パブリッシャから、1以上のコンピューティングデバイスにおいて受信される。データオブジェクトは、データベースシステムに記憶されていてもよいし、データベースシステムに記憶されるよう構成されていてもよい。第1の情報は、ブロック1708においてデータオブジェクトとインタラクトすることをリクエストしたユーザにより提供され得る。第1の情報は、例えば、図1A及び図1Bにおける信号ネットワーク14を介して、方法1700を実行する1以上のコンピューティングデバイスに伝送され得る。
いくつかの例において、所定の入力の妥当性を検証するために、妥当性検証ルールが、1以上のデータフィールドに対して実施され得る。図49は、いくつかの実施例に従った、パブリッシャアクション4906用の複数のデータフィールド4904を表示しているパブリッシャ4902を含むユーザインタフェースと、1以上のデータフィールドに関連付けられた妥当性検証ルールと、の一例を示している。1以上のコンピューティングデバイスは、閾値に対する、データフィールド4904の各々に提供された値の妥当性検証チェックを実行することができる。閾値は、エンティティにより、1以上のデータフィールドを定義するカスタムアクション命令内に提供され得る。データフィールド4904のうちの1つに提供された値が、閾値のセットと比較され得、この値が閾値のセットを満たすと判定された場合、この値は有効である。例えば、図49において、Close Date(クローズ日)4908に対しては、カレンダ日付(calendar date)に関する妥当性検証ルールが設定され得、このカレンダ日付は将来でなければならない。さらに、Early Field Indicator(アーリーフィールドインジケータ)4910には、何らかの値が入力されなければならないという妥当性検証ルールが設定され得る。
図17に戻ると、ブロック1716において、データベースシステムが、データオブジェクトに関連付けられた1以上のデータフィールドのための第1の情報に基づいてアップデートされる。データオブジェクトに対するアップデートは、データオブジェクトの作成、データオブジェクトの削除、データオブジェクトに関連付けられたデータを編集すること、データオブジェクトに関連付けられたアクションのログを取ること、データオブジェクトの変換、データオブジェクトからデータをダウンロードすること、データオブジェクトにデータをアップロードすること、データオブジェクトへのファイルの添付、データオブジェクトに関連付けられた情報の閲覧、及びデータオブジェクトを参照するオペレーションを他の形で実行することを含み得る。すなわち、ブロック1716におけるデータオブジェクトに関連付けられた第1の情報を使用して、ブロック1708におけるリクエストされたインタラクションを実行する。例えば、第1の情報を受信すると、1以上のコンピューティングデバイスは、データベースシステムにおいて、データオブジェクトを表す行を、テーブル内で作成又はアップデートさせることができる。
ブロック1720において、アップデートに関連付けられたフィード項目が、ユーザインタフェース内の情報フィードに含まれるように提示される。フィード項目は、情報フィード内にアップデートされたデータの少なくとも一部を提示するためのビジュアルフィードバック要素を提供する。フィード項目内に提示されるデータは、1以上のコンテキストファクタに依存し得る。いくつかの例において、フィード項目は、データオブジェクトへの参照を提供する実行可能なセレクションを含み得る。本明細書で先に説明されたように、同じフィード項目が、相互参照により、他の関連フィード内に伝播され得る。
カスタムアクションは、サードパーティにより提供され、上述した一連のステップの一部を実行するよう構成されてもよい。サードパーティにより提供され得るカスタムアクションの一例は、Bug(バグ)カスタムアクションである。図50Aは、いくつかの実施例に従った、バグのログを取るためのパブリッシャ5002の一例を示している。図50Bは、いくつかの実施例に従った、図50Aにおいて提供されたパブリッシャデータ5004から作成された対応するフィード項目5014の一例を示している。Bug(バグ)カスタムアクション5006を用いて、ユーザは、パブリッシャ5002からレコードを作成し、情報をフィード項目5014として情報フィードに公開することができる。そのような情報は、Subject(題)、Frequency(頻度)、Impact(影響度)、Found In(見つけられた場所)、及びProduct Tag(製品タグ)等のパブリッシャデータ5004を含み得る。パブリッシャ5002はまた、フィード項目5014に付随させるメッセージをポストするためのテキストボックス5008、パブリッシャデータ5004をそれぞれのフィードに公開する特定のエンティティを選択するためのドロップダウンメニュー5012、及びパブリッシャデータ5004を公開するためのShare(共有)ボタン5010を含み得る。
サードパーティにより提供され得るカスタムアクションの別の例は、Expense Report(経費報告)カスタムアクションである。図51Aは、いくつかの実施例に従った、経費報告書をファイルするためのパブリッシャ5102の一例を示している。図51Bは、いくつかの実施例に従った、図51Aにおいて提供されたパブリッシャデータ5104からの対応するフィード項目5114を示している。図51Cは、いくつかの実施例に従った、図51Aにおいて提供されたパブリッシャデータ5104からの別の対応するフィード項目5116を示している。Expense Report(経費報告)カスタムアクション5106を用いて、ユーザは、パブリッシャ5102から、承認のために経費報告書を送信することができる。パブリッシャデータ5104は、Name(名前)、Policy(ポリシ)、Purpose(目的)、Amount(額)、Item(項目)、及びReceipt(領収書)を含み得る。いくつかの例において、パブリッシャは、Concur(登録商標)等のアプリケーションと通信して、パブリッシャデータ5104の値を取得することができる。領収書が添付され、パブリッシャデータ5104とともに送信され得る。パブリッシャはまた、フィード項目5114及び5116に付随させるメッセージをポストするためのテキストボックス5108、パブリッシャデータ5104をそれぞれのフィードに公開する特定のエンティティを選択するためのドロップダウンメニュー5112、及びパブリッシャデータ5104を公開するためのShare(共有)ボタン5110を含み得る。
XVI.アプリケーションプログラミングインタフェースを介したパブリッシャにおけるアプリケーションとのインタラクション
図18は、いくつかの実施例に従って実行される、オンラインソーシャルネットワークにおいてパブリッシャを用いてアプリケーションとインタラクトするための、コンピュータにより実施される方法1800の一例のフローチャートを示している。図18は、図52〜図56Cを参照して説明され得る。ブロック1804において、パブリッシャ及び情報フィードを含むユーザインタフェースを生成するためのデータが提供される。ここで、パブリッシャは、情報を情報フィードに公開するよう構成される。いくつかの実施例において、ユーザインタフェースはまた、カスタムアクションを含み得る。カスタムアクションは、カスタムアクション命令に従ってデータオブジェクト又はアプリケーションとインタラクトするよう構成され得る。カスタムアクション命令は、第1のエンティティにより、APIを介して提供され得る。いくつかの実施例において、第1のエンティティは、データベースサービスを複数の受領者(recipient)に提供するデータベースサービスプロバイダであり得る。いくつかの実施例において、第1のエンティティは、ユーザ又は組織であり得る。
図52は、Visualforceページとともにカスタムアクションを作成するためのカスタムアクション定義領域5202を含むユーザインタフェースの一例を示している。Visualforce等のカスタマイゼーションツールは、ユーザが、オンデマンドサービス環境においてネイティブにホストされ得るカスタムユーザインタフェースを構築することを可能にする。ユーザインタフェースを宣言的に定義するのではなく、カスタマイゼーションツールは、ユーザが、ユーザインタフェースをプログラム的にカスタマイズすることを可能にする。例えば、ユーザは、ページ上に含まれるべきユーザインタフェースコンポーネントと、そのようなユーザインタフェースコンポーネントがどのように現れるべきであるかと、をカスタマイズすることができる。ユーザは、Visualforceタグ、HTML、Javascript(登録商標)、又は他のウェブ対応コードを編集することができる。さらに、ユーザは、ユーザインタフェース内のカスタムアクションを選択すると開始されるカスタムアクション命令をカスタマイズすることができる。ユーザがユーザインタフェースに追加できるカスタムアクションの例は、例に過ぎないが、インスタントメッセンジャ、ナレッジアーティクル(knowledge article)、ライブチャット、twitter(登録商標)、バーチャル掲示板(virtual bulletin board)、電子メール、要求のログを取ること、ポータルアンサー(portal answer)、又は同様のものを含み得る。
図52において、ユーザインタフェースは、カスタムアクション定義領域5202を含み、カスタムアクション定義領域5202は、複数のカスタムフィールド5204〜5218を含む。ユーザは、カスタムフィールド5204〜5218の各々に値を提供することにより、カスタムアクション命令を定義することができる。Custom Action(カスタムアクション)5206を選択することにより、ユーザは、Custom Action(カスタムアクション)5206に関連付けるVisualforceページ5208を特定することができる。Visualforceページ5208は、Account(取引先)5204について案件を作成するためにエンティティにより以前に定義されたものであり得る。ユーザは、Height(高さ)5210、Label(ラベル)5212、Name(名前)5214、Description(説明)5216、及びIcon(アイコン)5218に値を提供することにより、Visualforceページ5208をさらに定義することができる。
Visualforceページ5208の選択は、カスタマイズされたユーザインタフェースを生成するためのプログラムされた命令のセットを参照する。この命令は、例えば、Javascript(登録商標)、Java(登録商標)、Apex、又は任意の他のプログラミング言語において提供され得る。Visualforce等のカスタマイゼーションツールを使用することにより、ユーザは、パブリッシャ、カスタムアクション、及び情報フィードを含むユーザインタフェースの全体的なレイアウト及び外観を決定し得るとともに、様々なユーザインタフェースコンポーネントにより実行されるオペレーションを決定し得る命令を提供することが可能になり得る。
図53Aは、カスタマイズされたVisualforceページレイアウト5300aを伴うレコードの一例を示している。Visualforceは、異なるタグが異なるユーザインタフェースコンポーネントを表し得るマークアップ言語から構成される。そのようなVisualforceページレイアウト5300aを作成するための命令の例が、以下に示される。

図53Aの例に示されるように、Visualforceページレイアウト5300a用のユーザインタフェースは、パブリッシャ5302及び情報フィード5304を含み得る。ユーザは、電子メールパブリッシャ、要求ログパブリッシャ、及びポータルアンサーパブリッシャであることが可能なパブリッシャ5302をカスタマイズすることができる。すなわち、パブリッシャ5302は、顧客に電子メールを送信し、要求のログを取り、ウェブポータルを介して問合せに回答するよう構成されたカスタムアクション5306を含み得る。情報フィード5304等のコンポーネントをホストする、ページレイアウト5300a内のパブリッシャ5302及び他のフレームのレイアウト及び寸法は、第1のエンティティの好みに従って、カスタムアクション命令内に定義され得る。
図53Bは、カスタマイズされたVisualforceアクションレイアウト5300bを伴うパブリッシャ5302の一例を示している。ユーザは、指定された受信者に電子メールを送信し、電子メールメッセージを情報フィードに公開するよう構成された電子メールパブリッシャとしてパブリッシャ5302を定義することができる。ユーザは、パブリッシャ5302内のデータフィールドをプログラム的に定義することができる。ユーザが、Email Customer(顧客に電子メールを送信する)のパブリッシャアクション5306を選択すると、パブリッシャ5302に、送信者フィールド5308、受信者フィールド5310、件名フィールド5312、及びメッセージフィールド5314を含むデータフィールドを表示させる。データフィールドの各々における可視性(visibility)及びデフォルト値は、プログラム的に設定され得る。したがって、ユーザ又は組織は、パブリッシャ5302を介して送信されるデータの標準性(standardization)を高めるようパブリッシャ5302をカスタマイズすることができる。パブリッシャ5302はまた、添付ボタン5316を介してファイルを添付するための機能、テンプレートボタン5318を介してテンプレートを選択するための機能、及び送信ボタン5320を介して電子メールを送信するための機能を含み得る。
いくつかの実施例において、表示されるユーザインタフェースは、エンティティのアクセスパーミッション、レコードのタイプ、ページのタイプ、ディスプレイデバイスのタイプ等を含むコンテキストファクタに依存し得る。例えば、どのデータフィールドが表示されるか、どのパブリッシャアクションが利用可能であるか、及びユーザインタフェースコンポーネントのレイアウトは、ユーザインタフェースを移動しているエンティティのタイプに依存し得る。
ユーザインタフェースは、salesforce.com(登録商標)により提供されるもの等のAPIを宣言的に利用するカスタムアクション命令、又は、独自のAPI及び予め定義された命令のセットを提供し得るVisualforce等のカスタマイゼーションツールをプログラム的に利用するカスタムアクション命令により定義され得る。技術的スキルをそれほど有していないユーザは、ユーザインタフェースを宣言的に開発することができるのに対し、より複雑なデータ管理の必要性があるユーザ又は組織は、ユーザインタフェースをカスタマイズするのにカスタマイゼーションツールを選択することができる。
図18に戻ると、ブロック1808において、パブリッシャを用いてアプリケーションを公開するリクエストが受信される。アプリケーションを公開するリクエストは、ユーザが、パブリッシャ内のボタン、リンク、タブ、又は他のメニューセレクションを選択したことに応じて、ユーザのスマートフォン、デスクトップコンピューティングデバイス、ラップトップコンピューティングデバイス、タブレットコンピューティングデバイス、又は他のモバイルコンピューティングデバイスを介して受信され得る。アプリケーションは、パブリッシャスペース内に公開され得、アプリケーションとのインタラクションが、パブリッシャを通じAPIを介して実行され得る。アプリケーションは、salesforce.com(登録商標)等のデータベースサービスプロバイダにより提供されるAPIと統合され得る。
いくつかの実施例において、アプリケーションは、オンデマンドサービス環境においてネイティブにホストされる。いくつかの実施例において、アプリケーションは、サードパーティプラットフォーム上でホストされる。サードパーティプラットフォームは、オンデマンドサービス環境の外部にある1以上のデータベースシステムを含み得る。アプリケーションは、site.com、Heroku(登録商標)、force.com(登録商標)、及びAppExchange(登録商標)を含むがこれらに限定されないプラットフォームサービス上でホストされ得る。
アプリケーションを実行させるための実際のコードは、サードパーティプラットフォーム上でホストされてもよいが、アプリケーションは、オンデマンドサービス環境において提供されるAPIと通信するよう構成される。このAPIは、サードパーティアプリケーション等のアプリケーションをオンデマンドサービス環境に統合することを可能にし得る。例えば、このようなAPIは、サードパーティアプリケーションをオンデマンドサービス環境に統合することを可能にする、ツール及びJavascript(登録商標) APIのセットから構成され得る。Javascript(登録商標) APIは、サードパーティアプリケーションがブラウザページと通信できるように、通信ブリッジを提供する。
ブロック1812において、アプリケーションからのコンテンツが、APIを介してパブリッシャ内に公開される。アプリケーションからのコンテンツは、標準インタフェース、又は、Visualforceページ等のカスタマイズされたユーザインタフェース内に公開され得る。いくつかの実施例において、パブリッシャ内にコンテンツを公開することは、データベースシステムからコンテンツを取得すること、及び、パブリッシャ内のパブリッシャスペースに表示されるように、コンテンツを提示することを含む。いくつかの例において、データベースシステムは、オンデマンドサービス環境の外部で記憶され得る。
パブリッシャスペース内に公開されるコンテンツは、任意の数のデータソースから生じ得る。いくつかの実施例において、そのようなデータソースは、とりわけ、アナリティクス(analytics)、外部データソース、フィード、及びダイレクトイベント(direct event)を含み得る。例えば、公開されるコンテンツは、ビデオ会議サービスから提供されるビデオストリームであり得る。別の例において、公開されるコンテンツは、ウェブマッピングサービスアプリケーションから提供されるマップであり得る。パブリッシャスペースは、ユーザインタフェース内でコンテンツを閲覧することができるフレーム又はウィンドウを提供し、データソースからのコンテンツは、ブラウザページと通信するためのAPIとインタフェースをとることができる。
図54は、いくつかの実施例に従った、オンデマンドサービス環境においてネイティブにホストされているカスタムアクション用のデータフィールドを公開しているパブリッシャを含むユーザインタフェースの一例を示している。パブリッシャ5402は、レコードとインタラクトするよう構成されているカスタムアクション5404を含み得る。カスタムアクション5404は、セクションIXにおいて先に説明された方法で第1のエンティティにより提供されるカスタムアクション命令に従ってレコードとインタラクトするよう構成され得る。カスタムアクション5404は、APIとインタフェースをとることができるAPI対応アクションであり得、APIに、レコードに関連付けられたデータフィールド5408を表示させ得る。カスタムアクション5404は、パブリッシャ5402に、コンテンツをパブリッシャスペース5406内に公開させる。コンテンツは、レコードに関連付けられたデータフィールド5408から構成され得る。ここで、ユーザは、New Oppty(新たな商談)のカスタムアクション5404を選択して、パブリッシャ5402に、新たな商談を作成するためのデータフィールド5408を公開させることができる。データフィールドは、Opportunity Name(商談名)、Account Name(取引先名)、Next Step(次のステップ)、Amount(数量)、Close Date(クローズ日)、及びStage(段階)を含み得る。APIは、オンデマンドサービス環境における1以上のデータベースシステムとインタフェースをとることができる。図54の例において、APIは、外部データベースシステム又はサードパーティデータベースシステムと通信しなくてもよい。
図55は、いくつかの実施例に従った、オンデマンドサービス環境の外部でホストされているウェブページ5508からのコンテンツを公開しているパブリッシャ5502を含むユーザインタフェースの一例を示している。パブリッシャ5502は、外部でホストされているコンテンツを公開するよう構成されているカスタムアクション5504を含み得る。そのようなコンテンツの例は、記事、ブログ、チャットルーム、ウェブページ、他のオンラインソーシャルネットワークからのフィード等を含み得る。カスタムアクション5504は、APIとインタフェースをとることができるAPI対応アクションであり、APIに、外部データソースからのコンテンツを表示させる。図55に示されるように、カスタムアクション5504は、パブリッシャ5502に、ウェブページ5508をパブリッシャスペース5506内に表示させ得る。ウェブページ5508は、ウェブベースのアプリケーションサービスを含み得る。ウェブページ5508が、オンデマンドサービス環境の外部でホストされている場合であっても、ユーザは、APIを介して、ウェブページ5508と直接インタラクトすることができる。図55の例において、ユーザが、Create Listening Campaign(リスニングキャンペーンを作成する)のカスタムアクション5504を選択すると、パブリッシャ5502は、リスニングキャンペーンを作成するためにユーザがインタラクトできるウェブページ5508を公開する。
図56Aは、いくつかの実施例に従った、サードパーティプラットフォーム上でホストされているアプリケーションからのコンテンツを公開しているパブリッシャを含むユーザインタフェースの一例を示している。パブリッシャ5602は、サードパーティプラットフォーム上でホストされているアプリケーションとインタラクトするよう構成されているカスタムアクション5604を含み得る。カスタムアクション5604は、APIとインタフェースをとることができるAPI対応アクションであり、APIに、サードパーティプラットフォーム上でホストされているアプリケーションからのコンテンツをパブリッシャスペース5606内に公開させる。いくつかの例において、パブリッシャスペース5606内でのアプリケーションの公開は、force.com(登録商標)のCanvasアプリケーションであるカスタムアクション5604を用いて実行され得る。Canvasアプリケーションは、アプリケーションからのコンテンツを表示するためのiFrame又はウィンドウとして機能する。アプリケーションは、Heroku(登録商標)等のサードパーティプラットフォーム上でホストされ得る。図56Aに示されるように、アプリケーションは、旅程5608のリストを表示するよう構成されているトラベルサービスであり得る。パブリッシャ5602内に公開され得る他のサービスは、とりわけ、CRMサービス、顧客サービス、タスク管理サービス、ウェブサービス、ソーシャルマーケティングサービス、実績管理サービス、及びデータリポジトリサービスを含み得るが、これらに限定されるものではない。
図18に戻ると、ブロック1816において、アプリケーションとインタラクトするための、公開されたコンテンツに関するユーザ入力が受信される。ユーザ入力は、例えば、図1A及び図1Bにおける信号ネットワーク14を介して、方法1800を実行する1以上のコンピューティングデバイスに伝送され得る。いくつかの例において、ユーザ入力は、1以上のコンピューティングデバイスに送信される情報の選択又は入力を含み得る。
ユーザインタフェースから、ユーザは、APIを介して、サードパーティアプリケーション等のアプリケーションとインタラクトすることができる。図56Aにおいて、ユーザは、パブリッシャスペース5606内の旅程5608のリストから選択して、複数のアクションを実行することができる。例えば、ユーザは、Share Itinerary(旅程共有)ボタン5610を選択することにより、パブリッシャスペース5606内にリストされた旅程を共有することができる。これは、旅程をフィード項目として1以上のフィードにポストさせ得る。別の例として、ユーザは、Request Approval(承認リクエスト)ボタン5612を選択することにより、別のエンティティに対して旅程の承認をリクエストすることができる。したがって、ユーザは、承認ワークフローを開始して、旅程を承認のためのフィード項目として指定されたエンティティのフィードにポストすることができる。ユーザのマネージャ等の指定されたエンティティは、このリクエストを承認又は拒否することにより、このフィード項目とインタラクトすることができる。別の例において、ユーザは、Cancel Trip(トリップ取消)ボタン5614を選択することにより、旅程のうちの1つを取り消すことができる。ユーザは、ドロップダウンメニュー5616においてエンティティを選択することにより、情報が公開されるエンティティのフィードを特定することができる。さらに、ユーザは、Share(共有)ボタン5618を選択することにより、情報を適切なフィードに公開することができる。したがって、ユーザは、カスタムアクション5604及びAPIを用いて、プラットフォームからコンテンツを取得して管理することができる。
図18に戻ると、ブロック1820において、APIを介したアプリケーションとのインタラクションが、ユーザ入力を用いて実行される。インタラクションがユーザ入力により開始されると、アプリケーションは、アプリケーションに対するアップデートを実施するAPIと直接インタフェースをとる。アプリケーションがサードパーティプラットフォーム上でホストされている場合であっても、アプリケーションは、ホスト中のページに対するアップデートを実施するAPIと直接インタフェースをとる。いくつかの実施例において、実行されるインタラクションは、ユーザインタフェースのブラウザページ内で生じる。例えば、アプリケーションは、パブリッシャ内に公開されているモーゲージカルキュレータ(mortgage calculator)であり得、インタラクションがパブリッシャスペースに直接出力される。いくつかの実施例において、実行されるインタラクションは、ユーザインタフェースのブラウザページで生じない。その代わりに、実行されるインタラクションは、ブラウザ内でページを開くこと又はブラウザ内でページをリフレッシュすることを回避するサードパーティアプリケーション及びAPIを用いて生じる。すなわち、ブラウザページは、サードパーティプラットフォーム上でホストされているアプリケーションに対してなされるアップデートを認識しない。いくつかの例において、1以上のデータベースシステムが、実行されたインタラクションに従ってアップデートされ得る。
ブロック1824において、情報フィードが、アプリケーションとの実行されたインタラクションに従って、ユーザインタフェースにおけるAPIを介してアップデートされる。情報フィードは、情報フィード内の情報をアップデートするAPIと直接インタフェースをとる。APIがアプリケーションと通信するので、APIは、アプリケーションから返される情報をブラウザページにリンクする。そのような情報は、APIを介して、ユーザインタフェースの情報フィード内に提供される。いくつかの実施例において、情報フィードは、ユーザインタフェースをリフレッシュすることなくアップデートされる。実際、方法1800において実行されるステップの各々は、ユーザインタフェースをリフレッシュすることなく生じ得る。例えば、情報フィードをアップデートすることは、1以上のデータフィールドに対する変更を「トグルする」ことにより、ユーザ入力に基づいて情報フィード内の1以上のデータフィールドをアップデートすることを含み得る。したがって、APIは、アップデートがユーザインタフェース内のパブリッシャと情報フィードとの間でシームレスに生じるように、サードパーティプラットフォーム上でホストされているアプリケーション等の公開されているアプリケーションとユーザとの間のインタラクションを可能にし得る。
図56Bは、いくつかの実施例に従った、図56Aにおけるサードパーティプラットフォーム上でホストされているアプリケーションからのコンテンツに関するユーザ入力に基づいて情報を表示しているフィード項目5624を含むユーザインタフェースの一例を示している。ユーザ入力に応じて、APIは、アプリケーションと通信し、サードパーティプラットフォームにおける1以上のデータベースシステムから情報を取得することができる。この情報は、APIを介して、情報フィード5622内のフィード項目5624に提供され得る。アプリケーションがAPIを呼び出し、次いで、APIが、情報フィード5622に含まれるようにフィード項目5624を提示するために、情報フィード5622をアップデートする。図56AのShare Itinerary(旅程共有)ボタン5610を選択した後、ユーザは、Share(共有)ボタン5620を選択して、選択された旅程を含むフィード項目5624をポストする。アプリケーションから取得される、フィード項目5624内の情報は、図56Aにおける公開されたコンテンツよりも多くのデータを含み得る。
いくつかの実施例において、フィード項目は、アプリケーションへの参照を提供する1以上の実行可能なセレクションを含み得る。1以上の実行可能なセレクションは、フィード項目から、アプリケーションに対するさらなるオペレーションを実行させ得る。図56Cは、いくつかの実施例に従った、図56Aにおけるサードパーティプラットフォーム上でホストされているアプリケーションからのコンテンツに関するユーザ入力に基づいて承認コントロール5630を表示しているフィード項目5628を含むユーザインタフェースの一例を示している。図56Aにおける選択された旅程の承認をリクエストするユーザ入力に応じて、選択された旅程に関する情報が、APIを介して、情報フィード5626内のフィード項目5628に提供され得る。この情報は、サードパーティプラットフォームにおける1以上のデータベースシステムから取得され得る。フィード項目5628は、承認コントロール5630をさらに含み得、適切なエンティティは、選択された旅程を承認又は拒否することができる。いくつかの実施例において、承認コントロール5630は、ユーザにより指定されたエンティティの情報フィード又はユーザのプロフィール及び/若しくはプリファレンスに基づくエンティティの情報フィード内に提供され得る。承認コントロール5630のうちの1つの選択は、情報フィード5626に加えて、サードパーティプラットフォーム上でホストされているアプリケーションをさらにアップデートさせ得る。
方法1800についての一連のステップの少なくとも一部が、図56A〜図56Cに例示され得るが、他の例もまた、方法1800についての一連のステップを例示し得る。例えば、ユーザインタフェースは、パブリッシャ及び情報フィードを含み得、パブリッシャは、顧客とビデオ会議を開始するためのカスタムアクションを含む。顧客は、ビデオ記録デバイスを使用することができ、パブリッシャのパブリッシャスペースを通じて、ユーザとリアルタイムに会話することができる。さらに、ユーザは、パブリッシャからビデオ会議を記録することにより、公開されたデータストリームに対してアクションを実行することができ、記録されたビデオを情報フィードに公開することができる。
別の例において、ユーザインタフェースは、パブリッシャ及び情報フィードを含み得、パブリッシャは、SAPシステムを用いて発注するためのカスタムアクションを含む。1以上の項目が、SAPシステムから、パブリッシャ内に公開され得、ユーザは、発注する項目を選択することができる。ユーザは、発注するためのボタンを選択し、次いで、APIを介して、SAPシステムとインタラクトすることができる。APIは、カスタムアクションが、情報フィードと通信して、その項目に関する発注がなされたことを示すフィード項目を公開させることを可能にする。
さらに別の例において、製薬会社は、遊離型薬物(free drug)サンプルを医師に販売する販売代理店用のカスタマイズされたユーザインタフェースを開発することができる。販売代理店が、ユーザインタフェース内で、特定の医師のアカウントを引き出すと、販売代理店は、その医師のアカウントを閲覧して、新たな注文をパブリッシャに入力することができる。販売代理店は、サードパーティアプリケーション等のアプリケーションとインタラクトして、注文請求を履行することができ、注文請求書が発行されたことを示すフィード項目が、情報フィード内にポストされ得る。
さらに別の例において、ゲーム会社は、大量の一斉電子メールを顧客に送信するためのカスタマイズされたユーザインタフェースを開発することができる。ビデオゲームにおけるバグに関する膨大な事例が速いペースで生じる場合、ゲーム会社は、パブリッシャを利用して、VerticalResponse Inc.又はConstant Contact, Inc.等の一斉電子メール送信ウェブサービス(mass email web service)とインタラクトすることができる。ゲーム会社は、全ての受信者をインポート又は選択し、電子メールを作成し、一斉電子メール送信ウェブサービスを通じて電子メールを送信することができる。完了後に、電子メールが送信されたことを示すフィード項目を提示することにより、情報フィードがアップデートされ得る。
IX.様々なオペレーティングシステムにおけるパブリッシャの実装
パブリッシャは、1以上の情報フィードに公開されている、インタラクションに関する情報を含む1以上のレコードとインタラクトするインタフェースであり得る。いくつかの実施例において、パブリッシャは、1以上のレコードの作成を処理するインタフェースであり得る。例えば、パブリッシャは、投票、連絡先、タスク等といったオブジェクトの作成を処理するコンポーザであり得る。パブリッシャは、投票コンポーザ、連絡先コンポーザ、タスクコンポーザ等といった様々なコンポーザを作成するためのフレームワークの一部であり得る。そのようなフレームワークは、「パブリッシャフレームワーク」と呼ばれ得る。
パブリッシャフレームワークは、Android(登録商標)、iOS(登録商標)、及びWindows(登録商標)を含むがこれらに限定されない任意の1以上のオペレーティングシステムのためのネイティブフレームワークであり得る。いくつかの実施例において、パブリッシャフレームワークは、iOS(登録商標)において実装され得る。
いくつかの実施例において、パブリッシャフレームワークは、任意のコンポーザクラス(composer class)を自動的に発見するよう構成され得る。したがって、パブリッシャがオペレーティングシステムにおいてロードされると、パブリッシャは、コンポーザのクラスの各々を登録する必要なく、コンポーザの1以上のクラスを自動的に発見することができる。
パブリッシャフレームワークにおけるパブリッシャのいくつかの実装には、1以上のプロトコル及び/又はベースクラス(base class)が伴い得る。1以上のプロトコル及び/又はベースクラスは、ユーザインタフェース内でのパブリッシャの実装を容易にし得る。
一例において、1以上のプロトコル及び/又はベースクラスは、@の記載(@ mention)、タグ、メタデータタグ、ハッシュタグ等を含む任意の番号参照(number reference)に対するサポートを提供することができる。いくつかの例において、既製の(ready-made)テキストビューは、デフォルトデータソース又はカスタムデータソースを用いる任意の数のそのような参照をサポートすることができる。
別の例において、1以上のプロトコル及び/又はベースクラスは、iPad(登録商標)及びiPhone(登録商標)を含む1以上のクライアントデバイスにおけるパブリッシャに対するサポートを提供することができる。それらクライアントデバイスの各々は、パブリッシャが適合し得るフォームファクタを有し得る。
別の例において、各パブリッシャは、パブリッシャがメインパブリッシャメニューにおいていつ可視にされるべきかを示すよう構成され得る。例えば、所定のレコードが選択されたとき、いくつかのパブリッシャは、メニューにおいて可視にされ得るが、他のパブリッシャは不可視にされ得る。
別の例において、1以上のプロトコル及び/又はベースクラスは、パブリッシャフレームワークにおいてユーザインタフェース内でアニメーション化されて表示され得るメッセージを提供することができる。そのような例は、エラーメッセージ、警告メッセージ、及び情報を含むが、これらに限定されるものではない。
別の例において、1以上のプロトコル及び/又はベースクラスは、パブリッシャ、カスタムボタン等の表示をカスタマイズする柔軟な方法を提供することができる。カスタマイズ可能な表示は、例えば、上方ビュー(upper view)、アクセサリビュー(accessory view)、右側ビュー(right-view)等を含み得る。
パブリッシャの実装に伴う前述の1以上のプロトコル及び/又はベースクラスは、任意のタイプのコンポーザの作成の容易化を可能にし得る。例えば、コンポーザは、ネイティブコンポーザ、ウェブベースのコンポーザ、又はサードパーティコンポーザであり得る。
いくつかの実施例において、オペレーティングシステムにおいてパブリッシャフレームワークを実装するためのいくつかのクラス及びメソッドのサブクラスを作ることにより、プラグインが、スクラッチから追加され得る。プラグインは、プラグイン自身のためのベースクラスを含み得る。プラグインは、パブリッシャの基本機能を得るための1以上のメソッドをオーバーライトし得る。プラグインは、プラグインビューコントローラ(plugin view controller)を含み得る。プラグインビューコントローラは、複数の様々なヘルパ機能を提供することができる別のベースクラスを含み得る。
本明細書で開示される実施例の特定の態様の具体的な詳細は、開示される実施例の主旨及び範囲から逸脱することなく、任意の適切な形で組み合わせることができる。しかしながら、他の実施例は、各個別の態様に関連する特定の実施例、又は、そのような個別の態様の特定の組合せを対象とし得る。
開示される例は、複数のテナントをサポートすることができるオンデマンドデータベースサービスのためのフロントエンドを提供するアプリケーションサーバを有するシステムにおいてオンデマンドデータベースサービス環境が実装される実施例を参照して本明細書でしばしば説明されるが、本実施例は、マルチテナントデータベースやアプリケーションサーバ上でのデプロイメント(deployment)に限定されるものではない。実施例は、特許請求される実施例の範囲から逸脱することなく、他のデータベースアーキテクチャ、すなわち、ORACLE(登録商標)、IBM(登録商標)のDB2(登録商標)、及び同様のものを用いて実施することができる。
開示される実施例のいくつかは、モジュラ型又は統合型のコンピュータソフトウェア及び/又はハードウェアを用いる制御ロジックの形態で具現化され得ることを理解すべきである。ハードウェア及びハードウェアとソフトウェアとの組合せを用いる他の形及び/又は方法も可能である。
本出願において説明されるソフトウェアコンポーネント又は機能のいずれも、例えば、従来技術又はオブジェクト指向型技術を用いる、例えば、Java(登録商標)、C++、又はPerl等の任意の適切なコンピュータ言語を用いる、プロセッサにより実行されるソフトウェアコードとして実装され得る。ソフトウェアコードは、一連の命令又はコマンドとして、記憶及び/又は伝送のためにコンピュータ読み取り可能媒体に記憶され得る。適切な媒体は、ランダムアクセスメモリ(RAM)、読み取り専用メモリ(ROM)、ハードドライブ又はフロッピディスク等の磁気媒体、コンパクトディスク(CD)又はDVD(デジタル多用途ディスク)等の光媒体、フラッシュメモリ、及び同様のものを含む。コンピュータ読み取り可能媒体は、そのような記憶デバイス又は伝送デバイスの任意の組合せであり得る。ソフトウェア/プログラムコードでエンコードされたコンピュータ読み取り可能媒体は、互換デバイスとともにパッケージ化されてもよいし、他のデバイスから(例えば、インターネットダウンロードを介して)別々に提供されてもよい。任意のそのようなコンピュータ読み取り可能媒体は、1つのコンピューティングデバイス又はコンピュータシステム全体上に存在しても、1つのコンピューティングデバイス又はコンピュータシステム全体内に存在してもよく、とりわけ、1つのシステム又はネットワーク内に存在してもよい。コンピュータシステム又は他のコンピューティングデバイスは、モニタ、プリンタ、又は本明細書に記載される結果のうちのいずれかをユーザに対して提供するための他の適切なディスプレイを含み得る。
様々な実施例が本明細書で説明されたが、これらは限定ではなく例として提示されているに過ぎないことを理解すべきである。したがって、本出願の広がり及び範囲は、本明細書で説明された実施例のいずれによっても限定されるべきではなく、以下の及び後で提出される請求項及びその均等の構成によってのみ定められるべきである。



  1. オンラインソーシャルネットワークにおいてユーザインタフェースから1以上のレコードとインタラクトする、コンピュータにより実施される方法であって、
    コンピューティングデバイスにより、パブリッシャを含むユーザインタフェースを生成するためのデータを提供するステップであって、前記パブリッシャは、情報を情報フィードに公開するよう構成される、ステップと、
    前記コンピューティングデバイスにおいて、前記パブリッシャから、第1のレコードとインタラクトするリクエストを受信するステップであって、前記第1のレコードは、データベースシステムに記憶された親レコードに関連する、ステップと、
    前記コンピューティングデバイスにおいて、前記パブリッシャから、前記第1のレコードに関連付けられた第1の情報を受信するステップと、
    前記第1のレコードに関連付けられた前記第1の情報に基づいて、前記データベースシステムをアップデートするステップと、
    前記ユーザインタフェース内の前記情報フィードに含まれるように、前記第1の情報に基づく前記アップデートに関連付けられたフィード項目を提示するステップであって、前記フィード項目は、前記第1のレコードへの参照を提供する1以上の実行可能なセレクションを含む、ステップと、
    前記1以上の実行可能なセレクションのうちの少なくとも1つを選択したというユーザ入力を受信するステップと、
    前記コンピューティングデバイスにおいて、前記パブリッシャから、前記第1のレコード又は第2のレコードに関連付けられた第2の情報を受信するステップと、
    前記第2の情報に基づいて、前記データベースシステムをアップデートするステップと、
    を含む、方法。

  2. 前記第1のレコード及び前記第2のレコードの各々は、顧客関係管理(CRM)オブジェクトであり、前記CRMオブジェクトは、リード、案件、取引先、商談、タスク、連絡先、キャンペーン、契約、イベント、カスタムオブジェクト、及びVisualforceページのうちの1つである、請求項1記載の方法。

  3. 前記第1のレコードとインタラクトする前記リクエストを受信した後、前記パブリッシャに、前記第1のレコードの1以上のデータフィールドを表示させるステップであって、前記1以上のデータフィールドは、前記第1のレコードに関連付けられる前記第1の情報を受け入れるよう構成される、ステップ
    をさらに含む、請求項1記載の方法。

  4. 前記1以上の実行可能なセレクションのうちの少なくとも1つを選択したという前記ユーザ入力を受信した後、前記パブリッシャに、前記第2のレコードの1以上のパブリッシャアクションを表示させるステップと、
    前記第2のレコードの前記1以上のパブリッシャアクションのうちの少なくとも1つの選択に応じた、前記第2のレコードとインタラクトするリクエストを受信するステップであって、前記第2のレコードは、前記データベースシステムに記憶された前記親レコード及び前記第1のレコードのうちの少なくとも1つに関連する、ステップと、
    をさらに含む、請求項1記載の方法。

  5. 前記1以上の実行可能なセレクションのうちの少なくとも1つを選択したという前記ユーザ入力を受信した後、前記第2の情報を用いて、前記第1のレコードを参照するオペレーションを実行するステップ
    をさらに含む、請求項1記載の方法。

  6. 前記オペレーションは、タスクを作成すること、タスクをアップデートすること、商談を作成すること、商談をアップデートすること、連絡先を作成すること、連絡先をアップデートすること、案件を作成すること、案件をアップデートすること、取引先を作成すること、取引先をアップデートすること、イベントを作成すること、イベントをアップデートすること、要求のログを取ること、タスクのログを取ること、バグのログを取ること、電子メールを作成すること、メモを書くこと、投票を作成すること、案件をクローズすること、タスクを完了すること、バグをクローズすること、電子メールを送信すること、承認のための電子メールを送信すること、ポータルにポストすること、ソーシャルネットワークにポストすること、リンクを追加すること、及び「感謝」を追加することのうちの少なくとも1つを含む、請求項5記載の方法。

  7. 前記第1の情報に基づいて前記データベースシステムをアップデートする前記ステップは、前記第1のレコードを作成すること、前記第1のレコードを削除すること、前記第1のレコードに関連付けられたデータを編集すること、前記第1のレコードにアクションを記録すること、前記第1のレコードを変換すること、前記第1のレコードにファイルを添付すること、及び前記第1のレコードに関連付けられた情報を閲覧することのうちの少なくとも1つを含む、請求項1乃至6いずれか一項記載の方法。

  8. 前記パブリッシャは、前記第1のレコードとインタラクトするよう構成されたカスタムアクションを含み、前記第1のレコードとインタラクトする前記リクエストを受信する前記ステップは、
    前記コンピューティングデバイスにおいて、前記カスタムアクションを選択したという第1のユーザ入力を受信するステップ
    を含む、請求項1乃至6いずれか一項記載の方法。

  9. ユーザが前記第1のレコードとインタラクトするためのパーミッションを有すると判定するステップ
    をさらに含む、請求項1乃至6いずれか一項記載の方法。

  10. ユーザがパーミッションを有すると判定する前記ステップは、
    前記ユーザのプロフィールの1以上のユーザ属性を識別するステップと、
    前記第1のレコードの1以上のレコード属性を識別するステップと、
    前記ユーザが前記第1のレコードとインタラクトするためのパーミッションを有すると判定するために、前記1以上のユーザ属性を前記1以上のレコード属性と比較するステップと、
    を含む、請求項9記載の方法。

  11. 前記情報フィードに含まれるように、前記第2の情報に基づく前記アップデートに関連付けられた別のフィード項目を提示するステップであって、前記別のフィード項目は、前記パブリッシャ及び前記第2のレコードへの別の参照を提供する別の1以上の実行可能なセレクションを含む、ステップ
    をさらに含む、請求項1乃至6いずれか一項記載の方法。

  12. 前記パブリッシャは、
    1以上のパブリッシャアクションと、
    前記フィード項目内にメッセージコンテンツを提供するよう構成されたメッセージボディと、
    1以上のパブリッシャエクステンションに関連付けられたパブリッシャスペースであって、前記第1の情報又は前記第2の情報を提供するよう構成されたパブリッシャスペースと、
    前記第1の情報又は前記第2の情報とともに前記メッセージコンテンツを前記データベースシステムに送信するよう構成されたパブリッシャコンポーネントと、
    を含む、請求項1乃至6いずれか一項記載の方法。

  13. 前記コンピューティングデバイスにより、前記ユーザインタフェース内の前記パブリッシャの寸法を定義するステップと、
    前記コンピューティングデバイスにより、前記ユーザインタフェース内の前記パブリッシャのレイアウトを定義するステップと、
    をさらに含む、請求項1乃至6いずれか一項記載の方法。

  14. 前記第1の情報に基づく前記アップデートに関連付けられた前記フィード項目は、前記第1のレコードと親子関係を有するレコードフィード、前記第1のレコードのレコードフィード、ユーザのニュースフィード、前記ユーザをフォローしているエンティティのニュースフィード、及び前記第1のレコードにサブスクライブしているエンティティのニュースフィードのうちの少なくとも1つに含まれる、請求項1乃至6いずれか一項記載の方法。

  15. 前記第2の情報に基づく前記アップデートに関連付けられた前記フィード項目は、前記第2のレコードと親子関係を有するレコードフィード、前記第2のレコードのレコードフィード、ユーザのニュースフィード、前記ユーザをフォローしているエンティティのニュースフィード、及び前記第2のレコードにサブスクライブしているエンティティのニュースフィードのうちの少なくとも1つに含まれる、請求項1乃至6いずれか一項記載の方法。

  16. 前記パブリッシャは、アプリケーションプログラミングインタフェース(API)を介して前記データベースシステムをアップデートするために、前記第1の情報又は前記第2の情報を送信するよう構成される、請求項1乃至6いずれか一項記載の方法。

  17. 前記APIは、モバイルディスプレイデバイス用に構成される、請求項16記載の方法。

  18. オンラインソーシャルネットワークにおいてユーザインタフェースから1以上のレコードとインタラクトするための1以上のコンピューティングデバイスであって、
    パブリッシャを含むユーザインタフェースを生成するためのデータを提供する手段であって、前記パブリッシャは、情報を情報フィードに公開するよう構成される、手段と、
    前記パブリッシャから、第1のレコードとインタラクトするリクエストを受信する手段であって、前記第1のレコードは、データベースシステムに記憶された親レコードに関連する、手段と、
    前記パブリッシャから、前記第1のレコードに関連付けられた第1の情報を受信する手段と、
    前記第1のレコードに関連付けられた前記第1の情報に基づいて、前記データベースシステムをアップデートする手段と、
    前記ユーザインタフェース内の情報フィードに含まれるように、前記第1の情報に基づく前記アップデートに関連付けられたフィード項目を提示する手段であって、前記フィード項目は、前記第1のレコードへの参照を提供する1以上の実行可能なセレクションを含む、手段と、
    前記1以上の実行可能なセレクションのうちの少なくとも1つを選択したというユーザ入力を受信する手段と、
    前記パブリッシャから、前記第1のレコード又は第2のレコードに関連付けられた第2の情報を受信する手段と、
    前記第2の情報に基づいて、前記データベースシステムをアップデートする手段と、
    を備えた、1以上のコンピューティングデバイス。

  19. 前記第1のレコード及び前記第2のレコードの各々は、顧客関係管理(CRM)オブジェクトであり、前記CRMオブジェクトは、リード、案件、取引先、商談、タスク、連絡先、キャンペーン、契約、イベント、カスタムオブジェクト、及びVisualforceページのうちの1つである、請求項18記載の1以上のコンピューティングデバイス。

  20. 前記パブリッシャに、前記第1のレコードの1以上のデータフィールドを表示させる手段であって、前記1以上のデータフィールドは、前記第1のレコードとインタラクトする前記リクエストが受信された後、前記第1のレコードに関連付けられた前記第1の情報を受け入れるよう構成される、手段
    をさらに備えた、請求項18記載の1以上のコンピューティングデバイス。

  21. 前記第1の情報に基づいて前記データベースシステムをアップデートする前記手段は、前記第1のレコードを作成すること、前記第1のレコードを削除すること、前記第1のレコードに関連付けられたデータを編集すること、前記第1のレコードにアクションを記録すること、前記第1のレコードを変換すること、前記第1のレコードにファイルを添付すること、及び前記第1のレコードに関連付けられた情報を閲覧することのうちの少なくとも1つを実行する手段を含む、請求項18乃至20いずれか一項記載の1以上のコンピューティングデバイス。

  22. 前記パブリッシャは、前記第1のレコードとインタラクトするよう構成されたカスタムアクションを含み、前記第1のレコードとインタラクトするリクエストを受信する前記手段は、前記カスタムアクションを選択したという第1のユーザ入力を受信する手段を含む、請求項18乃至20いずれか一項記載の1以上のコンピューティングデバイス。

  23. ユーザが前記第1のレコードとインタラクトするためのパーミッションを有すると判定する手段
    をさらに備えた、請求項18乃至20いずれか一項記載の1以上のコンピューティングデバイス。

  24. 前記第1の情報に基づく前記アップデートに関連付けられた前記フィード項目は、前記第1のレコードと親子関係を有するレコードフィード、前記第1のレコードのレコードフィード、ユーザのニュースフィード、前記ユーザをフォローしているエンティティのニュースフィード、及び前記第1のレコードにサブスクライブしているエンティティのニュースフィードのうちの少なくとも1つに含まれる、請求項18乃至20いずれか一項記載の1以上のコンピューティングデバイス。

  25. 前記パブリッシャは、アプリケーションプログラミングインタフェース(API)を介して前記データベースシステムをアップデートするために、前記第1の情報又は前記第2の情報を送信するよう構成される、請求項18乃至20いずれか一項記載の1以上のコンピューティングデバイス。

  26. オンラインソーシャルネットワークにおいてユーザインタフェースから1以上のレコードとインタラクトする、コンピュータにより実施される方法であって、
    コンピューティングデバイスにより、パブリッシャを含むユーザインタフェースを生成するためのデータを提供するステップであって、前記パブリッシャは、情報を情報フィードに公開するよう構成される、ステップと、
    前記コンピューティングデバイスにおいて、前記パブリッシャから、第1のレコードとインタラクトするリクエストを受信するステップであって、前記第1のレコードは、データベースシステムに記憶された親レコードに関連する、ステップと、
    前記コンピューティングデバイスにおいて、前記パブリッシャから、前記第1のレコードに関連付けられた第1の情報を受信するステップと、
    前記第1のレコードに関連付けられた前記第1の情報に基づいて、前記データベースシステムをアップデートするステップと、
    前記ユーザインタフェース内の前記親レコードの情報フィードに含まれるように、前記第1の情報に基づく前記アップデートに関連付けられたフィード項目を提示するステップと、
    前記フィード項目と相互参照されている1以上のエンティティを識別するステップと、
    前記フィード項目と相互参照されている前記1以上のエンティティの1以上の情報フィード内に、前記第1の情報に基づく前記アップデートに関連付けられた前記フィード項目を提供するステップと、
    を含む、方法。

  27. 前記1以上のエンティティのうちの少なくとも1つは、ユーザ、グループ、組織、又はレコードを含む、請求項26記載の方法。

  28. 前記1以上のエンティティは、前記第1のレコードの複数の親レコードを含む、請求項26記載の方法。

  29. 前記フィード項目と相互参照されている前記1以上のエンティティを識別する前記ステップは、
    前記データベースシステムにおける、前記第1のレコードのレコード関連情報を取得するステップと、
    前記レコード関連情報に少なくとも部分的に基づいて、前記1以上のエンティティのうちの少なくとも1つが前記フィード項目と相互参照されていると判定するステップと、
    を含む、請求項26記載の方法。

  30. 前記フィード項目と相互参照されている前記1以上のエンティティを識別する前記ステップは、
    前記コンピューティングデバイスにおいて、アプリケーションプログラミングインタフェース(API)から相互参照用データを受信するステップと、
    前記相互参照用データに少なくとも部分的に基づいて、前記1以上のエンティティのうちの少なくとも1つが前記フィード項目と相互参照されていると判定するステップと、
    を含む、請求項26記載の方法。

  31. 前記相互参照用データは、ユーザにより定められる、請求項30記載の方法。

  32. 1以上の実行可能なセレクションのうちの少なくとも1つを選択したというユーザ入力を受信するステップと、
    前記コンピューティングデバイスにおいて、前記パブリッシャから、第2のレコードに関連付けられた第2の情報を受信するステップであって、前記第2のレコードは、前記データベースシステムに記憶された前記第1のレコードの子レコードである、ステップと、
    前記第2のレコードに関連付けられた前記第2の情報に基づいて、前記データベースシステムをアップデートするステップと、
    をさらに含む、請求項26乃至31いずれか一項記載の方法。

  33. 前記第1のレコード、及び前記フィード項目と相互参照されている前記1以上のエンティティの各々は、顧客関係管理(CRM)オブジェクトであり、前記CRMオブジェクトは、リード、案件、取引先、商談、タスク、連絡先、キャンペーン、契約、イベント、カスタムオブジェクト、及びVisualforceページのうちの1つである、請求項26乃至31いずれか一項記載の方法。

  34. 前記第1のレコードとインタラクトする前記リクエストを受信した後、前記パブリッシャに、前記第1のレコードの1以上のデータフィールドを表示させるステップであって、前記1以上のデータフィールドは、前記第1のレコードに関連付けられる前記第1の情報を受け入れるよう構成される、ステップ
    をさらに含む、請求項26乃至31いずれか一項記載の方法。

  35. 前記1以上のデータフィールドのうちの少なくとも1つは、前記フィード項目と相互参照される前記1以上のエンティティを定める相互参照用データを受け入れるよう構成される、請求項34記載の方法。

  36. 前記フィード項目と相互参照されている前記1以上のエンティティのうちの少なくとも1つは、前記第1のレコード、前記第1のレコードの親レコード、前記第1のレコードの子レコード、前記第1のレコードにサブスクライブしているユーザ、前記第1のレコードとインタラクトしているユーザ、及び前記第1のレコードとインタラクトしている前記ユーザをフォローしているユーザを含む、請求項26乃至31いずれか一項記載の方法。

  37. ユーザが前記第1のレコードとインタラクトするためのパーミッションを有すると判定するステップ
    をさらに含む、請求項36記載の方法。

  38. オンラインソーシャルネットワークにおいて複数のレコードとインタラクトするための1以上のコンピューティングデバイスであって、
    パブリッシャを含むユーザインタフェースを生成するためのデータを提供する手段であって、前記パブリッシャは、情報を情報フィードに公開するよう構成される、手段と、
    前記パブリッシャから、第1のレコードとインタラクトするリクエストを受信する手段であって、前記第1のレコードは、データベースシステムに記憶された親レコードに関連する、手段と、
    前記パブリッシャから、前記第1のレコードに関連付けられた第1の情報を受信する手段と、
    前記第1のレコードに関連付けられた前記第1の情報に基づいて、前記データベースシステムをアップデートする手段と、
    前記ユーザインタフェース内の前記親レコードの情報フィードに含まれるように、前記第1の情報に基づく前記アップデートに関連付けられたフィード項目を提示する手段と、
    前記フィード項目と相互参照されている1以上のエンティティを識別する手段と、
    前記フィード項目と相互参照されている前記1以上のエンティティの1以上の情報フィードに含まれるように、前記第1の情報に基づく前記アップデートに関連付けられた前記フィード項目を提供する手段と、
    を備えた、1以上のコンピューティングデバイス。

  39. 前記1以上のエンティティは、前記第1のレコードの複数の親レコードを含む、請求項38記載の1以上のコンピューティングデバイス。

  40. 前記フィード項目と相互参照されている前記1以上のエンティティを識別する前記手段は、
    前記データベースシステムにおける、前記第1のレコードのレコード関連情報を取得する手段と、
    前記レコード関連情報に少なくとも部分的に基づいて、前記1以上のエンティティのうちの少なくとも1つが前記フィード項目と相互参照されていると判定する手段と、
    を含む、請求項38記載の1以上のコンピューティングデバイス。

  41. 前記フィード項目と相互参照されている前記1以上のエンティティを識別する前記手段は、
    アプリケーションプログラミングインタフェース(API)から相互参照用データを受信する手段と、
    前記相互参照用データに少なくとも部分的に基づいて、前記1以上のエンティティのうちの少なくとも1つが前記フィード項目と相互参照されていると判定する手段と、
    を含む、請求項38乃至40いずれか一項記載の1以上のコンピューティングデバイス。

  42. 前記第1のレコード、及び前記フィード項目と相互参照されている前記1以上のエンティティの各々は、顧客関係管理(CRM)オブジェクトであり、前記CRMオブジェクトは、リード、案件、取引先、商談、タスク、連絡先、キャンペーン、契約、イベント、カスタムオブジェクト、及びVisualforceページのうちの1つである、請求項38乃至40いずれか一項記載の1以上のコンピューティングデバイス。

  43. オンラインソーシャルネットワークにおいて1以上のフォロワによりアクセスされる相互参照されているフィード項目を公開する、コンピュータにより実施される方法であって、
    コンピューティングデバイスにおいて、フィード項目を親エンティティのフィードに公開するリクエストを受信するステップであって、前記親エンティティは、前記オンラインソーシャルネットワークのデータベースにおいて識別される、ステップと、
    エンティティを、前記フィード項目と相互参照されているものとして識別するステップであって、前記の相互参照されているエンティティは、1以上のフォロワを有する、ステップと、
    前記コンピューティングデバイスにおいて、前記の相互参照されているエンティティの前記1以上のフォロワによりアクセスされる前記フィード項目を公開するリクエストを受信するステップと、
    前記親エンティティ及び前記の相互参照されているエンティティに関連付けて、前記フィード項目を1以上のデータベーステーブルに記憶するステップであって、前記フィード項目は、前記1以上のフォロワによりアクセス可能な複数の情報フィード内に前記フィード項目を表示するよう動作可能なディスプレイデバイスに提供されることが可能であり、前記1以上のフォロワによりアクセス可能な前記複数の情報フィードは、前記親エンティティの前記フィードと前記1以上のフォロワの1以上のフィードとを含む、ステップと、
    を含む、方法。

  44. 前記1以上のフォロワによりアクセス可能な前記複数の情報フィードのうちの1つの情報フィード内に前記フィード項目を表示するよう動作可能な前記ディスプレイデバイスに、前記フィード項目を提供するステップ
    をさらに含む、請求項43記載の方法。

  45. 前記コンピューティングデバイスにおいて、前記の相互参照されているエンティティによりアクセスされる前記フィード項目を公開するリクエストを受信するステップと、
    前記の相互参照されているエンティティのフィード内に前記フィード項目を表示するよう動作可能な前記ディスプレイデバイスに、前記フィード項目を提供するステップと、
    をさらに含む、請求項43記載の方法。

  46. エンティティを、前記フィード項目と相互参照されているものとして識別する前記ステップは、
    前記オンラインソーシャルネットワークのデータベースにアクセスするステップであって、前記データベースは、前記フィード項目が前記エンティティと相互参照されていることを示すデータを記憶している、ステップ
    を含む、請求項43記載の方法。

  47. 前記コンピューティングデバイスにより、パブリッシャを含むユーザインタフェースを生成するためのデータを提供するステップであって、前記パブリッシャは、情報を情報フィードに公開するよう構成され、前記パブリッシャは、相互参照する1以上のエンティティを選択するためのアプリケーションプログラミングインタフェース(API)を含む、ステップ
    をさらに含む、請求項43記載の方法。

  48. エンティティを、前記フィード項目と相互参照されているものとして識別する前記ステップは、
    前記フィード項目が前記1以上のフォロワに対してトランジティブであると判定するステップ
    を含む、請求項43記載の方法。

  49. エンティティを、前記フィード項目と相互参照されているものとして識別する前記ステップは、
    前記フィード項目と、前記の相互参照されているエンティティの前記1以上のフォロワと、の関連性を分析するステップと、
    前記フィード項目が前記の相互参照されているエンティティの前記1以上のフォロワに関連すると判定するステップと、
    を含む、請求項43乃至48いずれか一項記載の方法。

  50. 前記フィード項目は、前記ディスプレイデバイスにおいて、情報をユーザインタフェースに公開し、前記の公開される情報は、前記フィード項目が含まれる選択された情報フィードのソースに少なくとも部分的に依存する、請求項43乃至48いずれか一項記載の方法。

  51. 前記フィード項目は、前記ディスプレイデバイスにおいて、情報をユーザインタフェースに公開し、前記の公開される情報は、前記ディスプレイデバイスのタイプに少なくとも部分的に依存する、請求項43乃至48いずれか一項記載の方法。

  52. 前記複数の情報フィードは、フォロワのニュースフィードを含む、請求項43乃至48いずれか一項記載の方法。

  53. 前記親エンティティの前記フィードへのアクセスをリクエストしているフォロワのアクセスパーミッションを識別するステップと、
    前記のリクエストしているフォロワが前記親エンティティの前記フィードを閲覧するためのパーミッションを有すると判定するステップと、
    をさらに含む、請求項43乃至48いずれか一項記載の方法。

  54. オンラインソーシャルネットワークにおいて1以上のフォロワによりアクセスされる相互参照されているフィード項目を公開するための1以上のコンピューティングデバイスであって、
    フィード項目を親エンティティのフィードに公開するリクエストを受信する手段であって、前記親エンティティは、前記オンラインソーシャルネットワークのデータベースにおいて識別される、手段と、
    エンティティを、前記フィード項目と相互参照されているものとして識別する手段であって、前記の相互参照されているエンティティは、1以上のフォロワを有する、手段と、
    前記の相互参照されているエンティティの前記1以上のフォロワによりアクセスされる前記フィード項目を公開するリクエストを受信する手段と、
    前記親エンティティ及び前記の相互参照されているエンティティに関連付けて、前記フィード項目を1以上のデータベーステーブルに記憶する手段であって、前記フィード項目は、前記1以上のフォロワによりアクセス可能な複数の情報フィード内に前記フィード項目を表示するよう動作可能なディスプレイデバイスに提供されることが可能であり、前記1以上のフォロワによりアクセス可能な前記複数の情報フィードは、前記親エンティティの前記フィードと前記1以上のフォロワの1以上のフィードとを含む、手段と、
    を備えた、1以上のコンピューティングデバイス。

  55. 前記の相互参照されているエンティティは、ユーザ、グループ、組織、レコード、又はカスタムオブジェクトである、請求項54記載の1以上のコンピューティングデバイス。

  56. 前記の相互参照されているエンティティによりアクセスされる前記フィード項目を公開するリクエストを受信する手段と、
    前記の相互参照されているエンティティのフィード内に前記フィード項目を表示するよう動作可能な前記ディスプレイデバイスに、前記フィード項目を提供する手段と、
    をさらに備えた、請求項54記載の1以上のコンピューティングデバイス。

  57. エンティティを、前記フィード項目と相互参照されているものとして識別する前記手段は、
    前記オンラインソーシャルネットワークのデータベースにアクセスする手段であって、前記データベースは、前記フィード項目が前記エンティティと相互参照されていることを示すデータを記憶している、手段
    を含む、請求項54乃至56いずれか一項記載の1以上のコンピューティングデバイス。

  58. 前記親エンティティの前記フィードへのアクセスをリクエストしているフォロワのアクセスパーミッションを識別する手段と、
    前記のリクエストしているフォロワが前記親エンティティの前記フィードを閲覧するためのパーミッションを有すると判定する手段と、
    をさらに備えた、請求項54乃至56いずれか一項記載の1以上のコンピューティングデバイス。

  59. 情報をオンラインソーシャルネットワークの情報フィードに公開するよう構成されたパブリッシャから1以上のデータオブジェクトとインタラクトする、コンピュータにより実施される方法であって、
    コンピューティングデバイスにより、カスタムアクションを伴うパブリッシャを含むユーザインタフェースを生成するためのデータを提供するステップであって、前記カスタムアクションは、アプリケーションプログラミングインタフェース(API)を介して第1のエンティティにより提供されるカスタムアクション命令に従ってデータオブジェクトとインタラクトするよう構成され、前記データオブジェクトは、データベースシステムに記憶されている、あるいは前記データベースシステムに記憶されるよう構成されている、ステップと、
    前記コンピューティングデバイスにおいて、第2のエンティティから、前記ユーザインタフェース内の前記カスタムアクションの選択を介した、前記データオブジェクトとインタラクトするリクエストを受信するステップと、
    前記コンピューティングデバイスにおいて、前記パブリッシャから、前記データオブジェクトに関連付けられた1以上のデータフィールドのための第1の情報を受信するステップと、
    前記データオブジェクトに関連付けられた前記1以上のデータフィールドのための前記第1の情報に基づいて、前記データベースシステムをアップデートするステップと、
    前記ユーザインタフェース内の情報フィードに含まれるように、前記第1の情報に基づく前記アップデートに関連付けられたフィード項目を提示するステップと、
    を含む、方法。

  60. 前記データオブジェクトは、顧客関係管理(CRM)オブジェクトであり、前記CRMオブジェクトは、リード、案件、取引先、商談、タスク、連絡先、キャンペーン、契約、イベント、カスタムオブジェクト、及びVisualforceページのうちの1つである、請求項59記載の方法。

  61. 前記第1のエンティティは、データベースサービスを複数の受領者に提供するデータベースサービスプロバイダである、請求項59記載の方法。

  62. 前記第2のエンティティは、前記複数の受領者のうちの1人である、請求項61記載の方法。

  63. 前記パブリッシャ内で選択されるように前記カスタムアクションを表示するよう構成された1以上のページタイプを定義するステップ
    をさらに含む、請求項59記載の方法。

  64. 前記カスタムアクションの選択は、前記パブリッシャの外部にあるユーザインタフェースコンポーネントからのユーザ入力により生じる、請求項59乃至63いずれか一項記載の方法。

  65. 前記コンピューティングデバイスにおいて、検索クエリを受信するステップと、
    前記検索クエリに応じて、前記ユーザインタフェースコンポーネントを前記ユーザインタフェース内に表示させるステップと、
    をさらに含む、請求項64記載の方法。

  66. 前記パブリッシャは、
    1以上のパブリッシャエクステンションと、
    前記カスタムアクションと、
    前記1以上のパブリッシャエクステンション又は前記カスタムアクションの選択に関連付けられたパブリッシャスペースであって、前記データオブジェクトに関連付けられた前記1以上のデータフィールドのための前記第1の情報を提供するよう構成されたパブリッシャスペースと、
    を含む、請求項59乃至63いずれか一項記載の方法。

  67. 前記パブリッシャは、
    前記フィード項目内にメッセージコンテンツを提供するよう構成されたメッセージボディと、
    前記データオブジェクトに関連付けられた前記1以上のデータフィールドからの前記第1の情報と、前記メッセージコンテンツと、を前記データベースシステムに送信するよう構成されたパブリッシャコンポーネントと、
    を含む、請求項66記載の方法。

  68. 前記コンピューティングデバイスにより、前記パブリッシャ内での前記カスタムアクションのページレイアウトを定義するステップであって、前記ページレイアウトは、前記パブリッシャ内での、前記1以上のパブリッシャエクステンションに対する前記カスタムアクションの配置を表す、ステップ
    をさらに含む、請求項66記載の方法。

  69. 前記コンピューティングデバイスにより、前記パブリッシャ内での前記1以上のデータフィールドのアクションレイアウトを定義するステップであって、前記アクションレイアウトは、前記パブリッシャスペース内での前記1以上のデータフィールドの配置を表す、ステップ
    をさらに含む、請求項66記載の方法。

  70. 前記データオブジェクトとインタラクトする前記リクエストは、レコードを作成すること、レコードを削除すること、レコードに関連付けられたデータを編集すること、レコードにアクションを記録すること、レコードを変換すること、レコードにファイルを添付すること、及びレコードに関連付けられた情報を閲覧することのうちの少なくとも1つを含む、請求項59乃至63いずれか一項記載の方法。

  71. 前記コンピューティングデバイスにおいて、ユーザから前記カスタムアクション命令を受け取るステップであって、前記カスタムアクション命令は、前記データオブジェクトを定義するとともに、前記データオブジェクトに関連付けられる前記1以上のデータフィールドを定義するよう構成される、ステップ
    をさらに含む、請求項59乃至63いずれか一項記載の方法。

  72. 前記カスタムアクション命令は、さらに、前記1以上のデータフィールドの各々に関連付けられる1以上の妥当性検証ルールを定義するよう構成され、前記1以上の妥当性検証ルールの各々は、前記1以上のデータフィールドの各々におけるユーザにより定められる値に対する制限を設定する、請求項71記載の方法。

  73. 前記カスタムアクション命令は、さらに、前記パブリッシャ内での前記カスタムアクションのページレイアウトを定義するよう構成され、前記ページレイアウトは、前記パブリッシャ内での、1以上のパブリッシャアクションに対する前記カスタムアクションの配置を表し、前記カスタムアクション命令は、さらに、前記パブリッシャ内での前記1以上のデータフィールドのアクションレイアウトを定義するよう構成され、前記アクションレイアウトは、前記パブリッシャ内での前記1以上のデータフィールドの配置を表す、請求項71記載の方法。

  74. 前記カスタムアクション命令は、前記カスタムアクションを伴う前記パブリッシャに含まれるように1以上のパブリッシャエクステンションを定義するよう構成される、請求項59乃至63いずれか一項記載の方法。

  75. 前記アップデートに関連付けられた前記フィード項目と相互参照されている1以上のエンティティを識別するステップと、
    前記フィード項目と相互参照されている前記1以上のエンティティの1以上の情報フィードに含まれるように、前記第1の情報に基づく前記フィード項目を提供するステップと、
    をさらに含む、請求項59乃至63いずれか一項記載の方法。

  76. パブリッシャから1以上のデータオブジェクトとインタラクトするための1以上のコンピューティングデバイスであって、
    カスタムアクションを伴うパブリッシャを含むユーザインタフェースを生成するためのデータを提供する手段であって、前記カスタムアクションは、アプリケーションプログラミングインタフェース(API)を介して第1のエンティティにより提供されるカスタムアクション命令に従ってデータオブジェクトとインタラクトするよう構成され、前記データオブジェクトは、データベースシステムに記憶されている、あるいは前記データベースシステムに記憶されるよう構成されている、手段と、
    第2のエンティティから、前記ユーザインタフェース内の前記カスタムアクションの選択を介した、前記データオブジェクトとインタラクトするリクエストを受信する手段と、
    前記カスタムアクションのイベントに応じて、前記パブリッシャに、前記データオブジェクトに関連付けられた1以上のデータフィールドを表示させる手段と、
    前記データオブジェクトに関連付けられた前記1以上のデータフィールドのための第1の情報を受信する手段と、
    前記データオブジェクトに関連付けられた前記1以上のデータフィールドのための前記第1の情報に基づいて、前記データベースシステムをアップデートする手段と、
    前記ユーザインタフェース内の情報フィードに含まれるように、前記第1の情報に基づく前記アップデートに関連付けられたフィード項目を提示する手段と、
    を備えた、1以上のコンピューティングデバイス。

  77. 前記データオブジェクトは、顧客関係管理(CRM)オブジェクトであり、前記CRMオブジェクトは、リード、案件、取引先、商談、タスク、連絡先、キャンペーン、契約、イベント、カスタムオブジェクト、及びVisualforceページのうちの1つである、請求項76記載の1以上のコンピューティングデバイス。

  78. 前記第1のエンティティは、データベースサービスを複数の受領者に提供するデータベースサービスプロバイダであり、前記第2のエンティティは、前記複数の受領者のうちの1人である、請求項76記載の1以上のコンピューティングデバイス。

  79. 選択されるように前記カスタムアクションを表示するよう構成された1以上のページタイプを定義する手段
    をさらに備えた、請求項76記載の1以上のコンピューティングデバイス。

  80. 前記カスタムアクションの選択は、前記パブリッシャの外部にあるユーザインタフェースコンポーネントからのユーザ入力により生じる、請求項76乃至79いずれか一項記載の1以上のコンピューティングデバイス。

  81. ユーザが前記カスタムアクションを選択するためのパーミッションを有すると判定する手段
    をさらに備えた、請求項76乃至79いずれか一項記載の1以上のコンピューティングデバイス。

  82. ユーザから前記カスタムアクション命令を受け取る手段であって、前記カスタムアクション命令は、前記データオブジェクトを定義するとともに、前記データオブジェクトに関連付けられる前記1以上のデータフィールドを定義するよう構成される、手段
    をさらに備えた、請求項76乃至79いずれか一項記載の1以上のコンピューティングデバイス。

  83. 前記カスタムアクション命令は、さらに、前記パブリッシャ内での前記カスタムアクションのページレイアウトを定義するよう構成され、前記ページレイアウトは、前記パブリッシャ内での、1以上のパブリッシャエクステンションに対する前記カスタムアクションの配置を表し、前記カスタムアクション命令は、さらに、前記パブリッシャ内での前記1以上のデータフィールドのアクションレイアウトを定義するよう構成され、前記アクションレイアウトは、前記パブリッシャ内での前記1以上のデータフィールドの配置を表す、請求項82記載の1以上のコンピューティングデバイス。

  84. オンラインソーシャルネットワークにおいてパブリッシャを用いてアプリケーションとインタラクトするための、コンピュータにより実施される方法であって、
    コンピューティングデバイスにより、パブリッシャ及び情報フィードを含むユーザインタフェースを生成するためのデータを提供するステップであって、前記パブリッシャは、情報を前記情報フィードに公開するよう構成される、ステップと、
    前記コンピューティングデバイスにおいて、前記パブリッシャを用いてアプリケーションを公開するリクエストを受信するステップと、
    アプリケーションプログラミングインタフェース(API)を介して、前記パブリッシャ内に前記アプリケーションからのコンテンツを公開するステップと、
    前記アプリケーションとインタラクトするための、前記の公開されたコンテンツに関するユーザ入力を受信するステップと、
    前記ユーザ入力を用いて、前記APIを介して前記アプリケーションとのインタラクションを実行するステップと、
    前記アプリケーションとの前記の実行されたインタラクションに従って、前記ユーザインタフェースにおける前記APIを介して前記情報フィードをアップデートするステップと、
    を含む、方法。

  85. 前記アプリケーションは、サードパーティプラットフォーム上でホストされている、請求項84記載の方法。

  86. 前記情報フィードに含まれるように、前記アップデートに関連付けられたフィード項目を提示するステップ
    をさらに含む、請求項84記載の方法。

  87. 前記フィード項目は、前記アプリケーションへの参照を提供する1以上の実行可能なセレクションを含む、請求項86記載の方法。

  88. 前記1以上の実行可能なセレクションのうちの少なくとも1つを選択したという、前記アプリケーションをアップデートするための別のユーザ入力を受信するステップと、
    前記別のユーザ入力を用いて、前記APIを介して前記アプリケーションに対するアップデートを実行するステップと、
    をさらに含む、請求項87記載の方法。

  89. 前記パブリッシャは、第1のエンティティにより提供されるカスタムアクション命令に従って前記アプリケーションとインタラクトするよう構成されたカスタムアクションを含む、請求項84記載の方法。

  90. ユーザから前記カスタムアクション命令を受け取るステップであって、前記カスタムアクション命令は、前記パブリッシャ及び前記カスタムアクションのレイアウト及び寸法を定義するよう構成される、ステップ
    をさらに含む、請求項89記載の方法。

  91. 前記第1のエンティティは、データベースサービスを複数の受領者に提供するデータベースサービスプロバイダである、請求項89記載の方法。

  92. 前記第1のエンティティは、ユーザ又は組織である、請求項89記載の方法。

  93. 前記アプリケーションとのインタラクションを実行する前記ステップは、
    前記アプリケーションとの実行されたインタラクションに従って、データベースシステムをアップデートするステップ
    を含む、請求項84乃至92いずれか一項記載の方法。

  94. 当該方法において実行される前記ステップの各々は、前記ユーザインタフェースをリフレッシュすることなく生じる、請求項84乃至92いずれか一項記載の方法。

  95. 前記アプリケーションからのコンテンツを公開する前記ステップは、
    データベースシステムから前記コンテンツを取得するステップと、
    前記パブリッシャ内のパブリッシャスペースに表示されるように、前記コンテンツを提示するステップと、
    を含む、請求項84乃至92いずれか一項記載の方法。

  96. 前記APIは、前記アプリケーションをオンデマンドサービス環境に統合することを可能にするよう構成される、請求項84乃至92いずれか一項記載の方法。

  97. 前記アプリケーションは、タスク管理サービス、顧客関係管理(CRM)サービス、顧客サービス、実績管理サービス、ソーシャルマーケティングサービス、ウェブサービス、及びデータリポジトリサービスのうちの少なくとも1つである、請求項84乃至92いずれか一項記載の方法。

  98. 前記情報フィードをアップデートする前記ステップは、前記ユーザ入力に基づいて、前記情報フィード内の1以上のデータフィールドをアップデートするステップを含む、請求項84乃至92いずれか一項記載の方法。

  99. オンラインソーシャルネットワークにおいてパブリッシャを用いてアプリケーションとインタラクトするための1以上のコンピューティングデバイスであって、
    パブリッシャ及び情報フィードを含むユーザインタフェースを生成するためのデータを提供する手段であって、前記パブリッシャは、情報を前記情報フィードに公開するよう構成される、手段と、
    前記パブリッシャを用いてアプリケーションを公開するリクエストを受信する手段と、
    アプリケーションプログラミングインタフェース(API)を介して、前記パブリッシャ内に前記アプリケーションからのコンテンツを公開する手段と、
    前記アプリケーションとインタラクトするための、前記の公開されたコンテンツに関するユーザ入力を受信する手段と、
    前記ユーザ入力を用いて、前記APIを介して前記アプリケーションとのインタラクションを実行する手段と、
    前記アプリケーションとの前記の実行されたインタラクションに従って、前記ユーザインタフェースにおける前記APIを介して前記情報フィードをアップデートする手段と、
    を備えた、1以上のコンピューティングデバイス。

  100. 前記情報フィードに含まれるように、前記アップデートに関連付けられたフィード項目を提示する手段であって、前記フィード項目は、前記アプリケーションへの参照を提供する1以上の実行可能なセレクションを含む、手段
    をさらに備えた、請求項99記載の1以上のコンピューティングデバイス。

  101. 前記パブリッシャは、第1のエンティティにより提供されるカスタムアクション命令に従って前記アプリケーションとインタラクトするよう構成されたカスタムアクションを含む、請求項99記載の1以上のコンピューティングデバイス。

  102. 前記インタラクションを実行する前記手段は、前記アプリケーションとの実行されたインタラクションに従って、データベースシステムをアップデートする手段を含む、請求項99乃至101いずれか一項記載の1以上のコンピューティングデバイス。

  103. 前記APIは、前記アプリケーションをオンデマンドサービス環境に統合することを可能にするよう構成される、請求項99乃至101いずれか一項記載の1以上のコンピューティングデバイス。

  104. 前記アプリケーションからのコンテンツを公開する前記手段は、
    データベースシステムから前記コンテンツを取得する手段と、
    前記パブリッシャ内のパブリッシャスペースに表示されるように、前記コンテンツを提示する手段と、
    を含む、請求項99乃至101いずれか一項記載の1以上のコンピューティングデバイス。

  105. 前記アプリケーションは、タスク管理サービス、顧客関係管理(CRM)サービス、顧客サービス、実績管理サービス、ソーシャルマーケティングサービス、ウェブサービス、及びデータリポジトリサービスのうちの少なくとも1つである、請求項99乃至101いずれか一項記載の1以上のコンピューティングデバイス。

  106. パブリッシャから1以上のレコードとインタラクトするための、コンピュータにより実施される方法であって、
    コンピューティングデバイスにより、パブリッシャを含むユーザインタフェースを生成するためのデータを提供するステップであって、前記パブリッシャは、情報を情報フィードに公開するよう構成され、前記データは、オペレーティングシステムにおいて前記パブリッシャを実装するための1以上のプロトコル及び/又はベースクラスを含む、ステップと、
    前記コンピューティングデバイスにおいて、前記パブリッシャから、第1のレコードとインタラクトするリクエストを受信するステップであって、前記第1のレコードは、データベースシステムに記憶された親レコードに関連する、ステップと、
    前記コンピューティングデバイスにおいて、前記パブリッシャから、前記第1のレコードに関連付けられた第1の情報を受信するステップと、
    前記第1のレコードに関連付けられた前記第1の情報に基づいて、前記データベースシステムをアップデートするステップと、
    前記ユーザインタフェース内の前記情報フィードに含まれるように、前記第1の情報に基づく前記アップデートに関連付けられたフィード項目を提示するステップであって、前記フィード項目は、前記第1のレコードへの参照を提供する1以上の実行可能なセレクションを含む、ステップと、
    前記1以上の実行可能なセレクションのうちの少なくとも1つを選択したというユーザ入力を受信するステップと、
    前記コンピューティングデバイスにおいて、前記パブリッシャから、前記第1のレコード又は第2のレコードに関連付けられた第2の情報を受信するステップと、
    前記第2の情報に基づいて、前記データベースシステムをアップデートするステップと、
    を含む、方法。

  107. 前記オペレーティングシステムは、iOS(登録商標)を含む、請求項106記載の方法。

  108. パブリッシャから1以上のレコードとインタラクトするための1以上のコンピューティングデバイスであって、
    パブリッシャを含むユーザインタフェースを生成するためのデータを提供する手段であって、前記パブリッシャは、情報を情報フィードに公開するよう構成され、前記データは、オペレーティングシステムにおいて前記パブリッシャを実装するための1以上のプロトコル及び/又はベースクラスを含む、手段と、
    前記パブリッシャから、第1のレコードとインタラクトするリクエストを受信する手段であって、前記第1のレコードは、データベースシステムに記憶された親レコードに関連する、手段と、
    前記パブリッシャから、前記第1のレコードに関連付けられた第1の情報を受信する手段と、
    前記第1のレコードに関連付けられた前記第1の情報に基づいて、前記データベースシステムをアップデートする手段と、
    前記ユーザインタフェース内の前記情報フィードに含まれるように、前記第1の情報に基づく前記アップデートに関連付けられたフィード項目を提示する手段であって、前記フィード項目は、前記第1のレコードへの参照を提供する1以上の実行可能なセレクションを含む、手段と、
    前記1以上の実行可能なセレクションのうちの少なくとも1つを選択したというユーザ入力を受信する手段と、
    前記パブリッシャから、前記第1のレコード又は第2のレコードに関連付けられた第2の情報を受信する手段と、
    前記第2の情報に基づいて、前記データベースシステムをアップデートする手段と、
    を備えた、1以上のコンピューティングデバイス。

 

 

Patent trol of patentswamp
類似の特許
システムは、属性に対してユーザをマッピングする表を記憶して、ソースドメインと関連付けられた製品に対してユーザをマッピングする第2の表を記憶する。システムは、属性のそれぞれについて1組の上位スコアの製品を決定して、上位スコアの製品を使用して、ソースドメインと区別されるターゲットドメインにおける活動を予測するモデルを生成する。システムは、ターゲットドメインにアクセスする特定のユーザからの行動を検出して、行動の検出に応答して、モデルに基づいて特定のユーザについての個別予測を生じる。
【選択図】図5
様々な実施形態は、関心地点の検索の際、データプロバイダに照会するためのシステム、方法、装置およびコンピュータ可読媒体に関する。1つの特定の実施形態では、各々がデータソースの優先度を有する複数のデータソースを識別するステップであって、複数のデータソースは、第1の参照先ソース、第1の構造化知識ベースおよび第1の個々のウェブサイトの少なくとも2つを含む、識別するステップを含む方法が提供される。次いで、複数のデータソースは、poi検索要求と関連するメタデータを求めて照会することができ、照会する順序が複数のデータソースの各々についてのデータソースの優先度と、複数のデータソースの少なくとも1つに関して測定された少なくとも1つのソース品質とに基づく。さらなる実施形態では、照会順序は、測定されたソース品質に基づきアップデートすることができる。
方法は、複数のモジュールを有するアプリケーションで受け取られたデータ記録のストリームからの、データ記録の群中のデータ記録の第1の量を決定するステップを含む。方法は、アプリケーションのモジュールのうちの1つ以上に関して、データ記録の群の処理時にモジュールによって出力されたデータ記録のそれぞれの第2の量を決定するステップを含む。方法は、データ記録の第1および第2の量が規則を満たすかどうかを判定するステップを含む。この規則は、アプリケーションで受け取られたデータ記録の量と、アプリケーションの1つまたは複数のモジュールによって出力されたデータ記録の量との間のターゲット関係を示す。
本発明の実施形態は、データ処理方法、コーディネータ、及びノードデバイスを提供する。コーディネータは、ノードデバイスから送信される、サービスデータを含むデータフレームを受信し、サービスデータが設定データ信頼区間内に収まっているか否かを判断し、データ信頼区間から外れていると判断する場合に、ノードデバイスがサービスデータの正当性を確認するよう、サービスデータを載せた問い合わせデータフレームをノードデバイスに送信する。本発明の実施形態によれば、コーディネータは、まず、受信したサービスデータがデータ信頼区間内に収まっているか否かを判断し、データ信頼区間から外れている場合に、サービスデータをノードデバイスに返して確認させる。コーディネータがサービスデータを直ちに受け入れる先行技術による方法と比較して、本発明の実施形態で提供されるデータ処理方法は、データの信頼性及び精度に対するシステムの要求を満たす。
データベースシステムは、データベースシステムによって格納された特定のデータ記録に対して行われる変更を指定する書き込み要求を受け取ることができる。特定のデータ記録に対して行われる変更を表すログ記録は、データベースシステムのストレージサービスに送ることができる。読み取り用レプリカのキャッシュ内に格納された特定のデータ記録のキャッシュされたバージョンが古くなっていることを示す指示(例えば、ログ記録または他の指示)は、読み取り用レプリカに送ることができる。読み取り用レプリカによって受け取られた特定のデータ記録の後続の読み取りでは、読み取り用レプリカは、ストレージサービスから特定のデータ記録を要求することができる。
【選択図】図5
本発明の実施例は、クラスタリング方法及び関連装置を公開し、前記クラスタリング方法によれば、対象間の距離が対応する、2つの対象間の類似性で決められた重み係数に基づいて、クラスタ間の重み付き距離を取得し、即ち、対象間の距離に重みを付け、そして、併合後のクラスタの数と併合前のクラスタの数と等しくなるまで、重み付き距離が併合条件を満たすクラスタを併合し、クラスタリング結果を取得する。前記重み付き距離と2つの対象の類似性とが関連付けられ、異なる対象間の距離の貢献が異なり、類似性が高いほど対応する貢献が大きくなるので、クラスタリング結果の正確率が向上した。
【選択図】図1
【解決手段】 ページスナップショットの作成が開示される。この作成は、ウェブページに関連付けられているデータを受信し、ウェブページに関連付けられているページリソースが遅延読み込みに関係付けられていると決定し、ページリソースは、遅延読み込みプロセスの間トリガイベントに応答して読み込まれるように設定され、少なくとも一部には、ウェブページに関連付けられている受信データの中のページリソースに関連付けられている1つ以上の属性を変更することに基づいて、トリガイベントを伴うことなくページリソースを読み込み、読み込まれたページリソースをレンダリングし、レンダリングされたページリソースを含むウェブページのページスナップショットを作成すること、を含む。
【選択図】図3
本発明の実施形態は、データベースにおいて再実行データを処理するための方法および装置を提供し、方法は、サーバ内に含まれる複数のアプリケーションスレッドの各アプリケーションスレッドによって、データベースの変更操作に従って、再実行データを生成し、各アプリケーションスレッドに割り当てられた対応するバッファ内に再実行データを保存し、時系列キューのロックが取得された後、時系列キュー内にアプリケーションスレッドの識別子を保存し、保存が終わった後、時系列キューのロックを解除するステップと、データ読み出しスレッドによって、データ読み出し条件が満たされていることを判定し、時系列キューからアプリケーションスレッドの識別子を読み出す順序に連続的に従って、時系列キューにおける各アプリケーションスレッドの識別子に対応する各アプリケーションスレッドのバッファから1つの再実行データを読み出し、1つの再実行データを再実行キューに書き込むステップとを含む。本発明の使用によって、時系列キューをデータキューから分離することによって再実行データの処理効率が改善されることができ、それによって、データベースシステムの同時スループットを向上させる。
被試験装置(DUT)の測定値と、同様な機器から得た測定値とを比較する方法及びシステムを提供する。この方法は、1つ以上の測定装置にモバイル計算装置を通信的に接続することと、1つ以上の測定装置から測定データを受信することとを含んでいる。モバイル計算装置は、DUTの機器識別子を決定し、その機器に関連する情報を回収する。この情報は、他の装置の以前の測定値又は規準文書を含んでもよい。モバイル計算装置は、比較のために回収した測定データと共に回収した情報を提示する。
【選択図】 図1
【課題】KIR及びHLA遺伝子型に基づいて同種造血細胞ドナーを選択する。
【解決手段】本開示は、AML又は骨髄異形成症候群を有する患者のために候補となるHLA適合の非血縁造血細胞ドナー(URD)をスコア化及び順位付けする方法を対象とする。候補ドナーは、KIR/HLA対立遺伝子及び遺伝子型の組合せをもとにスコア化される。明細書に開示される方法は、造血幹細胞移植の向上した臨床転帰を予測する好都合なドナーの順位付け及び選択を可能にする。
【選択図】図1
To top