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

Abstract

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

Description

本特許文書は、一般に、データベースシステムを用いて、オンラインソーシャルネットワークにおいてオンデマンドサービスを提供することに関し、より詳細には、オンラインソーシャルネットワークにおいて、パブリッシャからレコード及びアプリケーションとインタラクトするための技術に関する。

（優先権及び関連出願データ）
本出願は、Beechukらによる「MULTI-DIMENSIONAL PUBLISHER」と題された２０１３年３月１５日出願の同時係属中の同一出願人による米国特許仮出願第６１／８５２０８９号と、Beechukらによる「SYSTEMS AND METHODS FOR INTERACTING WITH RECORDS VIA A PUBLISHER AND AN INFORMATION FEED」と題された２０１３年７月１６日出願の同時係属中の同一出願人による米国特許出願第１３／９４３６５７号と、Beechukらによる「SYSTEMS AND METHODS FOR CROSS-REFERENCING FEED ITEMS」と題された２０１３年７月１６日出願の同時係属中の同一出願人による米国特許出願第１３／９４３６２９号と、Beechukらによる「SYSTEMS AND METHODS FOR CREATING CUSTOM ACTIONS」と題された２０１３年７月１６日出願の同時係属中の同一出願人による米国特許出願第１３／９４３６３６号と、Beechukらによる「SYSTEMS AND METHODS FOR INTERACTING WITH AN APPLICATION IN A PUBLISHER」と題された２０１３年７月１６日出願の同時係属中の同一出願人による米国特許出願第１３／９４３６４０号と、Horenらによる「SYSTEMS AND METHODS FOR CROSS-REFERENCING FEED ITEMS」と題された２０１３年１２月２０日出願の同時係属中の同一出願人による米国特許出願第１４／１３７２０２号と、Beechukらによる「SYSTEMS AND METHODS FOR INTERACTING WITH RECORDS VIA A PUBLISHER AND AN INFORMATION FEED」と題された２０１３年１２月１３日出願の同時係属中の同一出願人による米国特許仮出願第６１／９１５６４９号と、の優先権を主張し、それらの全てが、それらの全体を参照することにより、全ての目的のために、本明細書に組み込まれる。

（著作権表示）
本特許文書の開示の一部は、著作権保護の対象となる内容を含む。著作権者は、特許文書又は特許開示が特許商標庁の特許ファイル又は記録に現れるものについては、何人によるこれらの複製に対して異議を持たないが、それ以外はどのようなものであっても全ての著作権を保有する。

「クラウドコンピューティング」サービスは、リクエストされると、共有リソース、ソフトウェア、及び情報を、コンピュータ及び他のデバイスに提供する。クラウドコンピューティング環境において、ソフトウェアは、インハウスコンピュータシステム上にローカルにインストールされる代わりに、インターネットを介してアクセス可能であり得る。クラウドコンピューティングは、通常、動的に拡張可能でしばしば仮想化されているリソースのインターネットを介した提供を伴う。ユーザから技術的な詳細を取り除くことができ、ユーザは、ユーザをサポートする「クラウド内の」技術インフラストラクチャの専門知識をもはや有する必要性がない、あるいは、そのような技術インフラストラクチャをもはや制御する必要性がない。

データベースリソースが、クラウドコンピューティングコンテキストにおいて提供され得る。しかしながら、従来のデータベース管理技術を用いると、クラウド又は他のネットワークにおけるデータベースシステムの他のユーザの行動について知ることは難しい。例えば、データベースリソース上の販売員等の特定のユーザのアクションは、そのユーザの上司にとって重要であり得る。ユーザは、ユーザが行ったことについてレポートを作成し、そのレポートを上司に送ることができるが、そのようなレポートは、役に立たないものであり、タイムリーでなく、不完全であり得る。また、レポート内の情報から恩恵を受ける可能性がある他のユーザを識別するのは難しいことであり得る。

添付の図面は、例示の目的のためにあり、オンラインソーシャルネットワークにおいて単一のユーザインタフェース内で１以上のレコードとインタラクトするための、開示される独創的なシステム、装置、及び方法のための可能な構造及びオペレーションの例を提供するに過ぎない。これらの図面は、開示される実施例の主旨及び範囲から逸脱することなく当業者によりなされ得る、形態及び詳細のいかなる変更も制限しない。
いくつかの実施例に従ってオンデマンドデータベースサービスが使用され得る環境１０の一例のブロック図。 図１Ａの要素とそれら要素間の種々の可能な相互接続とのいくつかの実装の例のブロック図。 いくつかの実施例に従ったオンデマンドデータベースサービス環境２００のアーキテクチャコンポーネントの例を示すシステム図。 いくつかの実施例に従ったオンデマンドデータベースサービス環境のアーキテクチャコンポーネントの例をさらに示すシステム図。 いくつかの実施例に従って実行される、データベースシステムに記憶されたレコードに対するアップデートを追跡するための方法３００の一例のフローチャート。 いくつかの実施例に従ってレコードに対するアップデートを追跡するための方法を実行するデータベースシステム構成４００のコンポーネントの例のブロック図。 いくつかの実施例に従って実行される、データベースシステムのユーザのアクションを追跡するための方法５００の一例のフローチャート。 いくつかの実施例に従って実行される、レコード又は別のユーザについてユーザにより作成されたメッセージからニュースフィードを作成するための方法６００の一例のフローチャート。 いくつかの実施例に従ったグループページ上のグループフィードの一例を示す図。 いくつかの実施例に従った、フィード追跡アップデート、ポスト、及びコメントを含むレコードフィードの一例を示す図。 いくつかの実施例に従ってイベントを追跡しフィードを作成する際に使用され得る複数のテーブルの例を示す図。 いくつかの実施例に従って実行される、ユーザをデータベースシステムにおけるオブジェクトに自動的にサブスクライブさせるための方法９００の一例のフローチャート。 いくつかの実施例に従って実行される、情報をフィード追跡テーブルに記録するための方法１０００の一例のフローチャート。 いくつかの実施例に従って実行される、表示されるフィードを生成することの一部としてフィード項目を読み出すための方法１１００の一例のフローチャート。 いくつかの実施例に従って実行される、表示されるプロフィールフィードのフィード項目を読み出すための方法１２００の一例のフローチャート。 いくつかの実施例に従って実行される、フィード内に表示するためのフィード項目を効率的に生成するためにイベント情報を記憶する方法１３００の一例のフローチャート。 いくつかの実施例に従って実行される、フィルタリング基準を用いて、データベースシステムのユーザのためのカスタムフィードを作成するための方法１４００の一例のフローチャート。 いくつかの実施例に従って実行される、オンラインソーシャルネットワークにおいて単一のユーザインタフェースから１以上のレコードとインタラクトするための、コンピュータにより実施される方法１５００の一例のフローチャート。 いくつかの実施例に従って実行される、オンラインソーシャルネットワークにおいて単一のユーザインタフェースから１以上のレコードとインタラクトするための、コンピュータにより実施される方法１６００ａの一例のフローチャート。 いくつかの実施例に従って実行される、オンラインソーシャルネットワークにおいて１以上のフォロワによりアクセスされる相互参照されているフィード項目を公開するための、コンピュータにより実施される方法１６００ｂの一例のフローチャート。 いくつかの実施例に従って実行される、情報をオンラインソーシャルネットワークの情報フィードに公開するよう構成されたパブリッシャから１以上のデータオブジェクトとインタラクトするための、コンピュータにより実施される方法１７００の一例のフローチャート。 いくつかの実施例に従って実行される、オンラインソーシャルネットワークにおいてパブリッシャを用いてアプリケーションとインタラクトするための、コンピュータにより実施される方法１８００の一例のフローチャート。 いくつかの実施例に従った、パブリッシャ及び情報フィードを含むユーザインタフェースを伴うレコードの一例を示す図。 いくつかの実施例に従ったパブリッシャの一例を示す図。 いくつかの実施例に従った、モバイルデバイスアプリケーション用のパブリッシャ及び情報フィードを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、モバイルデバイスアプリケーション用のパブリッシャ及び情報フィードを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、モバイルデバイスアプリケーション用のパブリッシャ及び情報フィードを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、モバイルデバイスアプリケーション用のパブリッシャ及び情報フィードを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従ったフィード項目の一例を示す図。 いくつかの実施例に従った、モバイルデバイスアプリケーション用の、パブリッシャと、情報フィード内のフィード項目と、を含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、モバイルデバイスアプリケーション用の、パブリッシャと、情報フィード内のフィード項目と、を含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、パブリッシャ及び情報フィードを含むユーザインタフェースを伴うレコードの一例を示す図。 いくつかの実施例に従った、パブリッシャアクションが選択されたときの、複数の空データフィールドを表示しているユーザインタフェースを伴う、図２４におけるレコードの一例を示す図。 いくつかの実施例に従った、ユーザ入力を受け入れたときの、複数の入力済みデータフィールドを表示しているユーザインタフェースを伴う、図２５におけるレコードの一例を示す図。 いくつかの実施例に従った、パブリッシャからのアップデートされたデータを提示しているフィード項目と、子レコードへのリンクと、を含む情報フィードを含むユーザインタフェースを伴う、図２６におけるレコードの一例を示す図。 いくつかの実施例に従った、パブリッシャ、カスタムアクション、及び情報フィードを含むユーザインタフェースを伴うレコードの一例を示す図。 いくつかの実施例に従った、パブリッシャ、カスタムアクション、及び情報フィードを含むユーザインタフェースを伴う、図２８におけるレコードから変換されたレコードの一例を示す図。 いくつかの実施例に従った、パブリッシャ、カスタムアクション、及び情報フィードを含むユーザインタフェースを伴う、図２９における変換されたレコードの子レコードの一例を示す図。 いくつかの実施例に従った、親レコードの情報フィード内にフィード項目を表示しているユーザインタフェースを伴うレコードの一例を示す図。 いくつかの実施例に従った、取引先ページの情報フィードを表示しているユーザインタフェースを伴うレコードの一例を示す図。 いくつかの実施例に従った、図３２Ａの取引先ページのレコード詳細を表示しているユーザインタフェースを伴うレコードの一例を示す図。 いくつかの実施例に従った、図３２Ａの取引先ページのレコード関連情報を表示しているユーザインタフェースを伴うレコードの一例を示す図。 いくつかの実施例に従った、パブリッシャからのアップデートされたデータを提示しているフィード項目を含むレコードフィードを伴う連絡先レコードの一例を示す図。 いくつかの実施例に従った、図３３Ａのフィード項目から相互参照されているフィード項目と連絡先レコードへのリンクとを含むニュースフィードを伴うユーザプロフィールの一例を示す図。 いくつかの実施例に従った、図３３Ａのフィード項目から相互参照されているフィード項目と連絡先レコードへのリンクとを含むニュースフィードを伴う別のユーザプロフィールの一例を示す図。 いくつかの実施例に従った、ユーザがカスタムアクションを作成するよう構成されたデータベースサービスのユーザインタフェースの一例を示す図。 いくつかの実施例に従った、ユーザがパブリッシャからカスタムアクションを作成するよう構成されたパブリッシャを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、カスタムアクションを作成するためのカスタムアクション定義領域を含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、カスタムアクションに関連付けられたデータフィールドを表示しているアクションレイアウトエディタ用のユーザインタフェースの一例を示す図。 いくつかの実施例に従った、カスタムアクションに関連付けられたさらなるデータフィールドを表示している、図３７Ａのアクションレイアウトエディタ用のユーザインタフェースの一例を示す図。 いくつかの実施例に従った、カスタムアクションに関連付けられたデータフィールドの表示をプレビューしているウィンドウの一例を示す図。 他の実施例に従った、カスタムアクションに関連付けられたデータフィールドの表示をプレビューしているウィンドウの一例を示す図。 いくつかの実施例に従った、レコードに関連付けられたパブリッシャアクションを表示しているページレイアウトエディタ用のユーザインタフェースの一例を示す図。 いくつかの実施例に従った、詳細、ページレイアウト、及び、カスタムアクションに関連付けられた予め定められたフィールド値を表示しているユーザインタフェースの一例を示す図。 いくつかの実施例に従った、カスタムアクションに関連付けられた予め定められたフィールド値を編集又は追加するためのユーザインタフェースの一例を示す図。 いくつかの実施例に従った、ユーザがグローバルアクションを作成するよう構成されたデータベースサービスのユーザインタフェースの一例を示す図。 いくつかの実施例に従った、グローバルアクションを作成するための複数のパラメータを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、オンデマンドデータベースサービス環境に関連付けられたパブリッシャアクションを表示しているページレイアウトエディタ用のユーザインタフェースの一例を示す図。 いくつかの実施例に従った、パブリッシャ内に表示されるパブリッシャアクションを選択するためのウィンドウの一例を示す図。 いくつかの実施例に従った、モバイルデバイスアプリケーション用の、カスタムアクションを伴うパブリッシャと情報フィードとを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、モバイルデバイスアプリケーション用の、カスタムアクションを伴うパブリッシャと情報フィードとを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、オンデマンドデータベースサービス環境のためのデータベースシステム内を検索するためのルックアップツールの一例を示す図。 いくつかの実施例に従った、オンデマンドデータベースサービス環境のためのデータベースシステム内を検索するためのルックアップツールの一例を示す図。 いくつかの実施例に従った、オンデマンドデータベースサービス環境のためのデータベースシステム内を検索するための検索クエリツールの一例を示す図。 いくつかの実施例に従った、オンデマンドデータベースサービス環境のためのデータベースシステム内を検索するための検索クエリツールの一例を示す図。 いくつかの実施例に従った、パブリッシャアクション用の複数のデータフィールドを表示しているパブリッシャを含むユーザインタフェースと、１以上のデータフィールドに関連付けられた妥当性検証ルールと、の一例を示す図。 いくつかの実施例に従った、バグのログを取るためのパブリッシャの一例を示す図。 いくつかの実施例に従った、図５０Ａにおいて提供されたパブリッシャデータから作成された対応するフィード項目の一例を示す図。 いくつかの実施例に従った、経費報告書をファイルするためのパブリッシャの一例を示す図。 いくつかの実施例に従った、図５１Ａにおいて提供されたパブリッシャデータからのフィード項目の一例を示す図。 いくつかの実施例に従った、図５１Ａにおける経費報告書のステータスをアップデートするための承認コントロールを含む別のフィード項目の一例を示す図。 Ｖｉｓｕａｌｆｏｒｃｅページとともにカスタムアクションを作成するためのカスタムアクション定義領域を含むユーザインタフェースの一例を示す図。 カスタマイズされたＶｉｓｕａｌｆｏｒｃｅページレイアウトを伴うレコードの一例を示す図。 カスタマイズされたＶｉｓｕａｌｆｏｒｃｅアクションレイアウトを伴うパブリッシャの一例を示す図。 いくつかの実施例に従った、オンデマンドサービス環境においてネイティブにホストされているカスタムアクション用のデータフィールドを公開しているパブリッシャを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、オンデマンドサービス環境の外部でホストされているウェブページからのコンテンツを公開しているパブリッシャを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、サードパーティプラットフォーム上でホストされているアプリケーションからのコンテンツを公開しているパブリッシャを含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、図５６Ａにおけるサードパーティプラットフォーム上でホストされているアプリケーションからのコンテンツに関するユーザ入力に基づいてデータを表示しているフィード項目を含むユーザインタフェースの一例を示す図。 いくつかの実施例に従った、図５６Ａにおけるサードパーティプラットフォーム上でホストされているアプリケーションからのコンテンツに関するユーザ入力に基づいて承認コントロールを表示しているフィード項目を含むユーザインタフェースの一例を示す図。

開示される実施例に従ったシステム、装置、及び方法の例が、このセクションで説明される。これらの例は、開示される実施例の理解におけるコンテキスト及び助けを加えるためだけに提供されている。したがって、実施例は、そのような具体的な詳細の一部又は全てがなくても実施できることが当業者には明白であろう。他の例において、所定のプロセス／方法オペレーション（本明細書において「ブロック」とも呼ばれる）は、実施例を不必要に曖昧にするのを避けるために詳細に説明されていない。他の応用も可能であるので、以下の例は、範囲又は環境において限定的又は制限的であると解釈されるべきでない。

以下の詳細な説明において、説明の一部を形成し、例として特定の実施例が示されている添付の図面が参照される。これらの実施例は、当業者が開示される実施例を実施できるよう十分詳細に説明されるが、これらの例は限定的なものでなく、したがって、主旨及び範囲から逸脱することがなければ、他の実施例が使用されてもよいし、変更がなされてもよいことを理解されたい。例えば、図示され本明細書で説明される方法のブロックは、必ずしも示される順番で実行される必要はない。方法は、示されるブロックよりも多くのブロック又は少ないブロックを含んでもよいことも理解すべきである。いくつかの実施例において、別々のブロックとして本明細書で説明されるブロックは、組み合わされてもよい。反対に、単一のブロックとして本明細書で説明され得るブロックは、複数のブロックで実施されてもよい。

本明細書で説明又は参照される様々な実施例は、本明細書においてソーシャルネットワーキングシステムとも呼ばれるオンラインソーシャルネットワークにおいて単一のユーザインタフェース内で１以上のレコードとインタラクトするための様々な方法、装置、システム、及びコンピュータ読み取り可能記憶媒体を対象とする。オンラインソーシャルネットワークの一例は、カリフォルニア州サンフランシスコのｓａｌｅｓｆｏｒｃｅ．ｃｏｍ， ｉｎｃ．により提供されるＣｈａｔｔｅｒ（登録商標）である。オンラインソーシャルネットワークは、人々及び人々のグループの間のコミュニケーションを円滑にする一般的な方法にますますなりつつあり、それらの人々の何人も、ソーシャルネットワーキングシステムのユーザとして認識され得る。いくつかのオンラインソーシャルネットワークは、例えば、会社又はビジネスパートナ等の企業といった組織、学術機関、又はそのような組織内のグループを含む様々な環境において実施され得る。例えば、Ｃｈａｔｔｅｒ（登録商標）は、様々な目的で、データを共有し、互いとコミュニケーションし、互いと協働するために、ビジネス組織の部門内の従業員ユーザにより使用され得る。

いくつかのオンラインソーシャルネットワークにおいて、ユーザは、１以上の情報フィードにアクセスすることができ、情報フィードは、その情報フィード内の項目又はエントリとして提示される情報アップデートを含む。そのようなフィード項目は、単一の情報アップデート又は個々の情報アップデートの集合を含み得る。フィード項目は、文字ベースのデータ、オーディオデータ、画像データ、及び／又はビデオデータを含む様々なタイプのデータを含み得る。情報フィードは、以下で説明されるように、コンピューティングデバイスのディスプレイ等のディスプレイデバイス上のグラフィカルユーザインタフェース（ＧＵＩ）内に表示され得る。情報アップデートは、様々なソースからの様々なソーシャルネットワークデータを含み得、オンデマンドデータベースサービス環境に記憶され得る。いくつかの実施例において、開示される方法、装置、システム、及びコンピュータ読み取り可能記憶媒体は、マルチテナントデータベース環境における使用のために構成又は設計され得る。

いくつかの実施例において、オンラインソーシャルネットワークは、ユーザが、個々のユーザ及びユーザのグループをフォローすることに加えて、案件（case）、取引先（account）、又は商談（opportunity）等のレコードの形態のデータオブジェクトをフォローすることを可能にし得る。以下でより詳細に説明されるように、データベースに記憶されたレコードを「フォローする」ことにより、ユーザは、そのレコードの進捗を追跡することが可能になる。本明細書においてレコードに対する変更とも呼ばれるレコードに対するアップデートは、そのレコードにサブスクライブされているユーザのニュースフィード又はレコードフィード等の情報フィードに対して生じ得るものであり、且つそのような情報フィード上に記され得る１つのタイプの情報アップデートである。レコードアップデートの例は、レコードにおけるフィールド変更、レコードのステータスに対するアップデートに加えて、レコード自体の作成も含む。一部のレコードは、パブリックに（publicly）アクセス可能であるので、いかなるユーザもそのレコードをフォローできるのに対し、他のレコードは、プライベートであり（private）、適切なセキュリティクリアランス／パーミッションが、そのレコードをフォローするユーザへの必須条件である。

情報アップデートは、特定のレコードにリンクされていてもリンクされていなくてもよい様々なタイプのアップデートを含み得る。例えば、情報アップデートは、ユーザ送信メッセージであってもよいし、ユーザアクション又はイベントに応じて、別の形で生成されてもよい。メッセージの例は、ポスト、コメント、「いいね（like）」及び「良くないね（dislike）」等のユーザの個人的好みのインジケーション、ユーザのステータスに対するアップデート、アップロードファイル、及び、インターネット上の様々なウェブページ及び／又は文書等のソーシャルネットワークデータ又は他のネットワークデータへのハイパーリンクを含む。ポストは、単語、語句、文、質問、感情表現、及び／又は記号等の英数字のユーザ入力又は他の文字ベースのユーザ入力を含み得る。コメントは、一般に、単語、語句、文、回答、質問、及び応答的な感情表現、並びに／又は記号等の、ポストに対する応答を指す。マルチメディアデータは、ポスト又はコメントに含まれ得る、ポスト又はコメントにリンクされ得る、あるいは、ポスト又はコメントに添付され得る。例えば、ポストは、ＪＰＥＧ画像又はアニメーション画像と組み合わせたテキスト文を含み得る。いいね又は良くないねは、特定のポスト又はコメントに応じて送信され得る。アップロードファイルの例は、プレゼンテーション、文書、マルチメディアファイル、及び同様のものを含む。

ユーザは、上述したように、レコードにサブスクライブすることにより、そのレコードをフォローすることができる。ユーザはまた、他のタイプのデータオブジェクト、他のユーザ、及びユーザのグループ等の他のエンティティをフォローすることもできる。そのようなエンティティに関するフィード追跡アップデート（feed tracked update）は、受信されユーザのニュースフィードに含まれ得る１つのタイプの情報アップデートである。任意の数のユーザが、特定のエンティティをフォローでき、したがって、ユーザのそれぞれのニュースフィード上で、そのエンティティに関連する情報アップデートを閲覧することができる。いくつかのソーシャルネットワークにおいて、ユーザは、互いとのコネクションを確立することにより、互いをフォローすることができ、これは、時として「友達になる（friending）」と呼ばれる。そのようなコネクションを確立することにより、ユーザは、別のユーザにより生成された情報、別のユーザについて生成された情報、又は別のユーザに他の形で関連付けられた情報を見ることができ得る。例えば、第１のユーザは、第２のユーザにより第２のユーザのパーソナルソーシャルネットワークページにポストされた情報を見ることができ得る。そのようなパーソナルソーシャルネットワークページの一実装は、例えば、ユーザのプロフィールを表すウェブページの形態のユーザのプロフィールページである。一例において、第１のユーザが第２のユーザをフォローしている場合、第１のユーザのニュースフィードは、第２のユーザのプロフィールフィードに送信された、第２のユーザからのポストを受け取ることができ、これは、本明細書において、ユーザの「ウォール」とも呼ばれ、ユーザのプロフィールページ上に表示される情報フィードの一例である。

いくつかの実施例において、情報フィードは、オンラインソーシャルネットワークのユーザのグループに固有であり得る。例えば、ユーザのグループは、ニュースフィードを公開することができる。グループのメンバは、フィード及びグループのためのパーミッション構成に従って、このグループフィードを閲覧することができるとともに、このグループフィードにポストすることができる。グループコンテキストにおける情報アップデートはまた、グループステータス情報に対する変更も含み得る。

いくつかの実施例において、１人以上のユーザから入力されたポスト又はコメント等のデータが、オンラインソーシャルネットワーク内の特定のユーザ、グループ、オブジェクト、又は他の構成（construct）のための情報フィードに送信されたとき、ユーザのプロフィールフィード、ニュースフィード、又はレコードフィード等の１以上のフィード内のフィード項目としてのそのデータに含まれるもの（inclusion）に加えて、電子メール通知又は他のタイプのネットワーク通知が、ユーザ、グループ、又はオブジェクトをフォローしている全てのユーザに送信され得る。いくつかのオンラインソーシャルネットワークにおいて、そのような通知の発生は、より大きな会話（larger conversation）の一部を形成し得る、公開された入力の最初のインスタンス（instance）に限定される。例えば、通知は、最初のポストに関しては送信され得るが、そのポストに対するコメントに関しては送信されない。いくつかの他の実施例においては、そのような情報アップデートごとに、別々の通知が送信される。

開示されるシステム、装置、方法、及びコンピュータ読み取り可能記憶媒体のいくつかの実施例は、オンラインソーシャルネットワークにおいて単一のユーザインタフェースを介してレコード又はアプリケーションとインタラクトするよう構成される。単一のユーザインタフェースは、パブリッシャ及び情報フィードを含む統合ユーザインタフェースを提供する。パブリッシャは、レコード又はアプリケーションとインタラクトするよう構成された１以上のパブリッシャアクションを含み得る。いくつかの実施例において、レコードは、リード（lead）、案件、取引先、商談、タスク、連絡先（contact）、キャンペーン（campaign）、契約、イベント、カスタムオブジェクト、及びＶｉｓｕａｌｆｏｒｃｅページ等の顧客関係管理（ＣＲＭ）オブジェクトであり得る。いくつかの実施例において、アプリケーションは、サードパーティプラットフォーム上でホストされるアプリケーションであり得る。

パブリッシャアクションのいくつかは、データオブジェクト又はアプリケーションとインタラクトするよう構成されたカスタムアクションであり得る。カスタムアクションは、カスタムアクション命令に従って、宣言的に（declaratively）、あるいはプログラム的に（programmatically）、定義され得る。カスタムアクション命令は、データオブジェクトと、データオブジェクトに対して実行されるインタラクションと、を定義し得る。カスタムアクション命令はまた、データオブジェクトに関連付けられたデータフィールド、１以上のデータフィールドに関連付けられた妥当性検証ルール、パブリッシャ内のカスタムアクションのページレイアウト、及びパブリッシャ内の１以上のデータフィールドのアクションレイアウトを含む、カスタムアクションの属性（attribute）も定義し得る。いくつかの例において、カスタムアクション命令は、Ｖｉｓｕａｌｆｏｒｃｅ等のカスタマイゼーションツールを用いて定義され得る。これにより、ユーザ又は組織は、ビジネスニーズを満たすようにカスタマイズされたユーザインタフェースを作成することが可能になる。

パブリッシャは、情報を情報フィードに公開するよう構成される。いくつかの例において、レコード又はアプリケーションとのインタラクションが実行されると、フィード項目が作成される。そのようなフィード項目は、１以上の実行可能なセレクション（選択手段）（actionable selection）を含み得る。１以上の実行可能なセレクションは、レコード又はアプリケーションへの参照を提供し得る。そのような実行可能なセレクションのうちの１つが選択されると、パブリッシャに、さらなる情報を受け取るよう、且つ／あるいは、さらなるオペレーションをレコード又はアプリケーションに対して実行するよう動作させ得る。フィード項目内にそのような実行可能なセレクションを有することにより、ユーザは、異なるユーザインタフェース間を移動して切り替える必要なく、レコード又はアプリケーションに対してアクションを効率的に実行することが可能になる。例えば、ユーザは、共通ユーザインタフェースを離れることなく、複数のレコードとインタラクトすることができる。これは、パブリッシャ及び情報フィードを通じてＣＲＭライフサイクル及び非ＣＲＭライフサイクルを効率的に進めるのに有用であり得る。

フィード項目は、操作されている子レコードの親レコード等の情報フィードに含まれるように提示され得る。しかしながら、フィード項目は、親レコードのレコードフィード内での表示のためだけでなく、他の関連フィード内での表示のために、伝播され（propagated）相互参照され得る。そのような関連フィードの識別は、例えば、ユーザがペイロード内に値を定義することにより、あるいはシステム管理者がそのような値をハードコードすることにより生じ得る。相互参照されているフィード項目に対して実行される任意のインタラクションもまた、単一の会話スレッドが保たれるように、全ての他の相互参照されているフィード項目上に提示される。これにより、ユーザ又は組織は、複数のページレイアウトから同じフィード項目を閲覧するとともに、複数のページレイアウトから同じフィード項目とインタラクトすることが可能になり得る。

パブリッシャは、データオブジェクトとインタラクトできるだけでなく、アプリケーションともインタラクトするよう構成され得る。そのようなアプリケーションは、オンデマンドサービス環境においてネイティブにホストされていてもよいし、サードパーティプラットフォーム上でホストされていてもよい。カスタムアクションは、ＡＰＩを介してアプリケーションとインタラクトするよう定義され得る。アプリケーションがネイティブにホストされているかサードパーティプラットフォーム上でホストされているかにかかわらず、ＡＰＩは、アプリケーションをオンデマンドサービス環境に統合することを可能にし得る。アプリケーションとのインタラクションは、情報フィードに対してアップデートされ得る。そのようなアップデートは、ユーザインタフェースをリフレッシュすることなく生じ得る。

より多くのユーザ及び組織が、コミュニケーションを取りながらビジネスを行うために、より協働的な共有モデルに向かっているので、より良く情報を公開、強化、及び利用する要望が存在する。従来、オンラインソーシャルネットワークにおいて、情報にアクセスし情報とインタラクトすることは、複数の異なるアプリケーション及びインタフェース間を移動して切り替えることを伴い得る。これは、面倒であり、時間を消費するものであり、非生産的であり得る。

上述したように、本明細書で説明される実施例のいくつかは、オンラインソーシャルネットワークにおいて、ユーザがデータオブジェクト又はアプリケーションとインタラクトすることを可能にする統合ユーザインタフェースを提供する機構を対象とする。そのようなインタラクションは、例えば、データオブジェクトを作成するリクエスト、データオブジェクトを削除するリクエスト、データオブジェクトをアップデートするリクエスト、データオブジェクトを変換するリクエスト、データオブジェクトからデータをダウンロードするリクエスト、データオブジェクトにデータをアップロードするリクエスト、データオブジェクトにファイルを添付するリクエスト、データオブジェクトに関連付けられた情報を閲覧するリクエスト、及びデータオブジェクトを参照するオペレーションを他の形で実行するリクエストを含み得る。統合ユーザインタフェースは、カスタムアクションを伴うパブリッシャ及び情報フィードを含み得る。ここで、カスタムアクションは、データオブジェクト又はアプリケーションに対して上述のインタラクションのうちの１つを実行するよう構成される。そのようなインタラクションは、ＡＰＩを介して生じ、フィード項目の形で情報フィードに公開され得る。フィード項目は、単一の会話スレッドを提供するために、他の関連フィードにおいて相互参照され得、フィード項目は、データオブジェクトに対してさらなるオペレーションを実行するための実行可能なセレクションを有し得る。したがって、パブリッシャ及びフィード項目は、異なるアプリケーション及びインタフェース間を切り替える必要なく関連情報とインタラクトし関連情報を閲覧するためのメインインタフェースになる。

これらの実施例及び他の実施例は、様々なタイプのハードウェア、ソフトウェア、ファームウェア、及びこれらの組合せにより具現化され得る。例えば、本明細書で開示されるいくつかの技術は、本明細書で説明される様々なサービス及びオペレーションを実行するためのプログラム命令、状態情報等を含むコンピュータ読み取り可能媒体により、少なくとも部分的に実施され得る。プログラム命令の例は、コンパイラにより生成されるもの等のマシンコードと、インタプリタを用いるサーバ又は他のデータ処理装置等のコンピューティングデバイスにより実行され得る、より高水準のコードを含むファイルと、の両方を含む。コンピュータ読み取り可能媒体の例は、ハードディスク、フロッピディスク、及び磁気テープ等の磁気媒体、ＣＤ−ＲＯＭディスク等の光媒体、光磁気媒体、及び、読み取り専用メモリ（「ＲＯＭ」）デバイス及びランダムアクセスメモリ（「ＲＡＭ」）デバイス等の、プログラム命令を記憶するよう特別に構成されているハードウェアデバイスを含むが、これらに限定されるものではない。開示される実施例のこれらの特徴及び他の特徴が、関連する図面を参照して以下でより詳細に説明される。

用語「マルチテナントデータベースシステム」は、データベースシステムのハードウェア及びソフトウェアの様々な要素が１人以上の顧客により共用され得るシステムを指し得る。例えば、所与のアプリケーションサーバは、非常に多くの顧客のリクエストを同時に処理することができ、所与のデータベーステーブルは、潜在的に非常に多くの顧客のためのフィード項目等のデータの行を記憶することができる。用語「クエリプラン」は、一般に、データベースシステム内の情報にアクセスするために用いられる１以上のオペレーションを指す。

「ユーザプロフィール」又は「ユーザのプロフィール」は、一般に、データベースシステムの所与のユーザについてのデータを記憶及び保持するよう構成される。そのデータは、名前、肩書、電話番号等の一般情報、写真、略歴（biographical summary）、及びステータス、例えば、ユーザが現在行っていることを説明するテキストを含み得る。以下で述べられるように、そのデータは、他のユーザにより作成されたメッセージを含んでもよい。複数のテナントが存在する場合、ユーザは、通常、特定のテナントに関連付けられる。例えば、ユーザは、データベースサービスを提供するデータベースシステムのテナントである会社の販売員であり得る。

用語「レコード」は、一般に、例えば、特定の（実際の又は潜在的な）ビジネス関係又はプロジェクトについてデータベースサービスのユーザにより作成されたデータオブジェクトのインスタンス等のデータエンティティを指す。データオブジェクトは、データベースサービスにより定義されたデータ構造（標準オブジェクト）又はユーザにより定義されたデータ構造（カスタムオブジェクト）を有し得る。例えば、レコードは、ユーザのビジネスパートナ又は潜在的ビジネスパートナ（例えば、クライアント、ベンダ、ディストリビュータ等）に関するものであり得、会社全体、子会社（subsidiary）、又は会社の連絡先を説明する情報を含み得る。別の例として、レコードは、既存パートナとの商談（例えば、可能な販売）等のユーザが取り組んでいるプロジェクトであってもよいし、ユーザが得ようと試みているプロジェクトであってもよい。マルチテナントデータベースシステムの一実装において、テナントのための各レコードは、共通テーブルに記憶された一意な識別子を有する。レコードは、オブジェクトの構造により定義されるデータフィールドを有する（例えば、所定のデータ型及び目的のフィールド）。レコードはまた、ユーザにより定義されたカスタムフィールドを有してもよい。フィールドは、別のレコードであってもよいし、別のレコードへのリンクを含んでもよい。これにより、レコード間の親子関係を提供することができる。

用語「情報フィード」及び用語「フィード」は、本明細書において同じ意味で用いられ、一般に、フィード項目又はエントリと様々なタイプの情報及びデータとの組合せ（例えば、リスト）を指す。そのようなフィード項目は、表示されるフィードの一部として提示される関連情報を取得するためにアクセスされ得る１以上のデータベーステーブルに、例えば、行として、記憶及び保持され得る。用語「フィード項目」（又は、フィード要素）は、情報の項目を指し、ユーザにより送信されたポスト等、フィード内に提示され得る。例えば、ユーザについての情報のフィード項目は、データベースのユーザのプロフィールフィード内に提示され得るのに対し、レコードについての情報のフィード項目は、データベースにおけるレコードフィード内に提示され得る。プロフィールフィード及びレコードフィードは、様々な情報フィードの例である。第１のユーザ及びレコードをフォローしている第２のユーザは、別のタイプの情報フィードである第２のユーザのニュースフィード内に表示される、第１のユーザ及びレコードに関連付けられたフィード項目を受け取ることができる。いくつかの実施例において、任意の数のフォローされているユーザ及びレコードからのフィード項目は、特定のユーザの単一の情報フィードに結合され得る。

例として、フィード項目は、テキストデータのユーザにより作成されたポスト等のメッセージ、及び、レコードのフィールドに対する変更等のレコード又はプロフィールに対するフィード追跡アップデートであり得る。フィード追跡アップデートは、以下でより詳細に説明される。フィードは、メッセージとフィード追跡アップデートとの組合せであり得る。メッセージは、ユーザにより作成されたテキストを含み、他のデータを含んでもよい。メッセージの例は、ポスト、ユーザステータスアップデート、及びコメントを含む。メッセージは、ユーザのプロフィール又はレコードに対して作成され得る。ポストは、様々なユーザ、潜在的に全てのユーザにより作成され得るが、いくつかの制限が適用され得る。一例として、ポストは、ユーザのプロフィールページのウォールセクション（複数の最近のポストを含み得る）又は複数のポストを含むレコードのセクションに対してなされ得る。ポストは、ユーザのプロフィールフィードの一部として、例えば、ユーザのプロフィールページ上のグラフィカルユーザインタフェース（ＧＵＩ）内に表示されるとき、時系列で編成され得る。ポストとは対照的に、ユーザステータスアップデートは、ユーザのステータスを変更するものであり、そのユーザ又は管理者によりなされ得る。レコードは、ステータスを有してもよく、そのアップデートは、そのレコードの所有者又はそのレコードに対する適切なライトアクセスパーミッション（write access permission）を有する他のユーザにより提供され得る。所有者は、１人のユーザであってもよいし、複数人のユーザであってもよいし、グループであってもよい。一実施例において、１レコードにつき１つのステータスのみ存在する。

いくつかの実施例において、コメントは、任意のフィード項目について作成され得る。いくつかの実施例において、コメントは、特定のフィード追跡アップデート、ポスト、又はステータスアップデートに明示的に関連付けられたリストとして編成される。いくつかの実施例において、コメントは、フィード項目の（階層上の）最初のレイヤにリストされなくてもよいが、特定の第１のレイヤのフィード項目から分岐した第２のレイヤとしてリストされ得る。

本明細書において「フィードアップデート」とも呼ばれる「フィード追跡アップデート」は、１つのタイプの情報アップデートであり、一般に、イベントを表すデータを指す。フィード追跡アップデートは、１以上のフィードに含まれ得る１以上のフィード項目として提供される、イベントに応じてデータベースシステムにより生成されるテキストを含み得る。一実施例において、このデータはまず記憶され得、次いで、データベースシステムは、その後にこのデータを使用して、イベントを説明するためのテキストを作成することができる。このデータ及び／又はこのテキストの両方が、本明細書で用いられるフィード追跡アップデートであり得る。様々な実施例において、イベントは、レコードのアップデートであってもよいし、且つ／あるいは、ユーザによる特定のアクションによってトリガされてもよい。どのアクションがイベントをトリガするのかは設定可能である。どのイベントがフィード追跡アップデートを作成させるか、及び、どのフィードアップデートがどのユーザに送信されるかも設定可能である。メッセージ及びフィードアップデートは、レコードの子オブジェクト又はフィールドとして記憶され得る。例えば、フィードは、レコードの子オブジェクトとして記憶され得る。

「グループ」は、一般に、ユーザの集合である。いくつかの実施例において、グループは、同じ属性又は類似する属性を有するユーザ群として定義され得る、あるいはメンバシップ（membership）により定義され得る。いくつかの実施例において、本明細書において「グループニュースフィード」とも呼ばれる「グループフィード」は、グループ内の任意のユーザについての１以上のフィード項目を含む。いくつかの実施例において、グループフィードはまた、グループ全体、グループの目的、グループの説明についての情報アップデート及び他のフィード項目、グループレコード、並びに、グループに関連付けられて記憶された他のオブジェクトも含む。ポスト、コメント、いいね等といったグループレコードアップデート及びメッセージを含む情報アップデートのスレッドは、グループ会話を定め得るものであり、時間とともに変化し得る。

「エンティティフィード」又は「レコードフィード」は、一般に、レコードに対する変更についてのフィード追跡アップデートやレコードについてユーザにより作成されたポスト等の、データベース内の特定のレコードについてのフィード項目のフィードを指す。エンティティフィードは、任意のタイプのフィード項目から構成され得る。そのようなフィードは、例えば、レコードのホームページといった、レコードに関連付けられたウェブページ等のページ上に表示され得る。本明細書で使用されるとき、「プロフィールフィード」又は「ユーザのプロフィールフィード」は、特定のユーザについてのフィード項目のフィードである。一例において、プロフィールフィード用のフィード項目は、他のユーザが特定のユーザについて作成した、あるいは他のユーザが特定のユーザに送信した、ポスト及びコメント、並びに、特定のユーザによりなされたステータスアップデートを含む。そのようなプロフィールフィードは、特定のユーザに関連付けられたページ上に表示され得る。別の例において、プロフィールフィード内のフィード項目は、特定のユーザにより作成されたポスト、及び、特定のユーザのアクションに基づいて生じたフィード追跡アップデートを含み得る。

Ｉ．一般的概要
企業レベルのソーシャル及びビジネス情報ネットワーキングを実装するためのシステム、装置、及び方法が提供される。そのような実装は、データベースシステムのより効率的な使用を提供し得る。例えば、データベースシステムのユーザは、例えば、プロジェクト又はクライアントについてのデータベース内の重要な情報がいつ変更されたかを容易に知ることはできない。実施例は、そのような変更及び他のイベントについてのフィード追跡アップデートを提供することができ、それにより、ユーザに知らせ続けることができる。

例えば、ユーザは、例えば、１０００個のコンピュータの可能な販売等の商談といったレコードをアップデートすることができる。レコードのアップデートがなされると、次いで、レコードのアップデートについてのフィード追跡アップデートが、その商談又はそのユーザにサブスクライブしている全てのユーザに対して、例えばフィード内に、自動的に提供され得る。したがって、そのユーザは、その商談の変更に関してマネージャとコンタクトする必要がない。なぜならば、そのアップデートについてのフィード追跡アップデートが、フィードを介して、マネージャのフィードページ又は他のページに直ちに送信されるからである。

次いで、いくつかの実施例を参照して、企業レベルのソーシャル及びビジネス情報ネットワーキングを実装するシステムを提供するための機構及び方法が説明される。まず、データベースシステムの一例の概要が説明され、次いで、レコードに関するイベントの追跡、ユーザのアクションの追跡、及び、ユーザ又はレコードについてのメッセージの追跡の例が説明される。フィードのデータ構造、フィードのカスタマイズ、フォローするレコード及びユーザのユーザ選択、フィードの生成、及びフィードの表示についての様々な実施例も説明される。

ＩＩ．システム概要
図１Ａは、いくつかの実施例に従ってオンデマンドデータベースサービスが使用され得る環境１０の一例のブロック図を示している。環境１０は、ユーザシステム１２、ネットワーク１４、データベースシステム１６、プロセッサシステム１７、アプリケーションプラットフォーム１８、ネットワークインタフェース２０、テナントデータストレージ２２、システムデータストレージ２４、プログラムコード２６、及びプロセススペース２８を含み得る。他の実施例において、環境１０は、これらのコンポーネントの全てを含まなくてもよいし、且つ／あるいは、上記で挙げたコンポーネントの代わりに、又は上記で挙げたコンポーネントに加えて、他のコンポーネントを含んでもよい。

環境１０は、オンデマンドデータベースサービスが存在する環境である。ユーザシステム１２は、データベースシステム１６にアクセスするためにユーザにより使用されるマシン又はシステム等の任意の１以上のコンピューティングデバイス又は他のデータ処理装置として実装され得る。例えば、ユーザシステム１２のいずれも、ハンドヘルドコンピューティングデバイス、携帯電話機、ラップトップコンピュータ、ワークステーション、及び／又はそのようなコンピューティングデバイスのネットワークであり得る。図１Ａに示されるように（且つ図１Ｂにより詳細に示されるように）、ユーザシステム１２は、ネットワーク１４を介して、図１Ａの例においてデータベースシステム１６として実装されているオンデマンドデータベースサービスとインタラクトすることができる。

例えばシステム１６を用いて実装されているオンデマンドデータベースサービスは、データベースシステムを構築及び／又は保守することに必ずしも関与している必要はない外部ユーザに利用可能になっているサービスである。代わりに、データベースシステムは、ユーザがデータベースシステムを必要とするときに、すなわち、ユーザの要求時に、ユーザによる使用のために利用可能であってもよい。いくつかのオンデマンドデータベースサービスは、１以上のテナントからの情報を、マルチテナントデータベースシステム（ＭＴＳ）を形成するための共通データベースイメージのテーブルに記憶することができる。データベースイメージは、１以上のデータベースオブジェクトを含み得る。リレーショナルデータベース管理システム（ＲＤＢＭＳ）又はその均等物は、１以上のデータベースオブジェクトに対して、情報の記憶及び取得を実行することができる。アプリケーションプラットフォーム１８は、例えばオペレーティングシステムといったソフトウェア及び／又はハードウェア等、システム１６のアプリケーションが動作することを可能にするフレームワークであり得る。いくつかの実施例において、アプリケーションプラットフォーム１８は、オンデマンドデータベースサービスのプロバイダ、ユーザシステム１２を介してオンデマンドデータベースサービスにアクセスするユーザ、又はユーザシステム１２を介してオンデマンドデータベースサービスにアクセスするサードパーティアプリケーション開発者により開発される１以上のアプリケーションの作成、管理、及び実行を可能にする。

ユーザシステム１２のユーザは、それぞれの能力の点で異なり得るものであり、特定のユーザシステム１２の能力は、現在のユーザに対するパーミッション（パーミッションレベル）により完全に決定され得る。例えば、販売員が、システム１６とインタラクトするために特定のユーザシステム１２を使用している場合、そのユーザシステムは、その販売員に割り当てられた能力を有する。しかしながら、管理者が、システム１６とインタラクトするためにそのユーザシステムを使用している間、そのユーザシステムは、その管理者に割り当てられた能力を有する。階層ロールモデルを有するシステムにおいて、あるパーミッションレベルのユーザは、より低いパーミッションレベルのユーザによりアクセス可能なアプリケーション、データ、及びデータベース情報にアクセスすることはできるが、より高いパーミッションレベルのユーザによりアクセス可能な所定のアプリケーション、データ、及びデータベース情報にはアクセスすることができない。したがって、アプリケーション及びデータベース情報にアクセスし、それらを変更することに関して、異なるユーザは、権限とも呼ばれるユーザのパーミッションレベル又はセキュリティレベルに応じて、異なる能力を有する。

ネットワーク１４は、他のデバイスと通信するデバイスの任意のネットワーク又はネットワークの組合せである。例えば、ネットワーク１４は、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、電話網、無線ネットワーク、ポイントツーポイントネットワーク、スター型ネットワーク、トークンリングネットワーク、ハブネットワーク、又は他の適切な構成のうちの任意の１つ又はこれらの任意の組合せであり得る。ネットワーク１４は、「インターネット（Internet）」（「I」は大文字）と呼ばれることが多い、ネットワークの全世界的相互ネットワーク等のＴＣＰ／ＩＰ（伝送制御プロトコル及びインターネットプロトコル）ネットワークを含み得る。インターネットは、本明細書における例の多くで使用される。しかしながら、ＴＣＰ／ＩＰは、頻繁に実装されるプロトコルであるが、本実施例が使用できるネットワークは、これに限定されるものではないことを理解すべきである。

ユーザシステム１２は、ＴＣＰ／ＩＰを使用してシステム１６と通信することもできるし、より高いネットワークレベルでは、ＨＴＴＰ、ＦＴＰ、ＡＦＳ、ＷＡＰ等の他の一般的なインターネットプロトコルを使用して通信することもできる。ＨＴＴＰが使用される例において、ユーザシステム１２は、システム１６におけるＨＴＴＰサーバとの間でＨＴＴＰ信号を送受信するための、一般に「ブラウザ」と呼ばれるＨＴＴＰクライアントを含み得る。このようなＨＴＴＰサーバは、システム１６とネットワーク１４との間の唯一のネットワークインタフェース２０として実装され得るが、他の技術が併用又は代用されてもよい。いくつかの実施例において、システム１６とネットワーク１４との間のネットワークインタフェース２０は、負荷を平衡させ、到来するＨＴＴＰリクエストを複数のサーバにわたって均等に分配するためのラウンドロビン式ＨＴＴＰリクエストディストリビュータ等の負荷分散機能を含む。複数のサーバの各々は、少なくともシステム１６にアクセスしているユーザに関しては、ＭＴＳのデータへのアクセスを有する。しかしながら、代わりに、他の代替構成が使用されてもよい。

一実施例において、図１Ａに示されるシステム１６は、ウェブベースの顧客関係管理（ＣＲＭ）システムを実装する。例えば、一実施例において、システム１６は、ＣＲＭソフトウェアアプリケーションを実装及び実行するとともに、関連データ、コード、フォーム、ウェブページ、及び他の情報をユーザシステム１２との間で提供し、関連データ、オブジェクト、及びウェブページコンテンツをデータベースシステムに記憶してデータベースシステムから取得するよう構成されたアプリケーションサーバを含む。マルチテナントシステムにおいて、複数のテナントのためのデータは、テナントデータストレージ２２内の同じ物理データベースオブジェクトに記憶され得るが、テナントデータは、明示的に共用される場合を除き、あるテナントが別のテナントのデータにアクセスすることのないように、あるテナントのデータが他のテナントのデータから論理的に別々に保持されるようテナントデータストレージ２２の１以上の記憶媒体に通常は配置される。所定の実施例において、システム１６は、ＣＲＭアプリケーションとは異なるアプリケーション又はＣＲＭアプリケーションに追加されるアプリケーションを実装する。例えば、システム１６は、ＣＲＭアプリケーションを含む複数のホストされた（標準及びカスタム）アプリケーションへのテナントアクセスを提供することができる。ＣＲＭアプリケーションを含んでも含まなくてもよいユーザアプリケーション（又は、サードパーティ開発者アプリケーション）は、アプリケーションプラットフォーム１８によりサポートされ得る。アプリケーションプラットフォーム１８は、アプリケーションの作成、１以上のデータベースオブジェクトへのアプリケーションの記憶、及びシステム１６のプロセススペース内での仮想マシンにおけるアプリケーションの実行を管理する。

ネットワークインタフェース２０、アプリケーションプラットフォーム１８、テナントデータ２３のためのテナントデータストレージ２２、システム１６及びおそらくは複数のテナントがアクセス可能なシステムデータ２５のためのシステムデータストレージ２４、システム１６の様々な機能を実装するためのプログラムコード２６、並びにＭＴＳシステムプロセス及びテナント固有プロセスを実行するための、例えば、アプリケーションホスティングサービスの一部としてアプリケーションを実行するためのプロセススペース２８を含む、システム１６の要素の一構成が、図１Ａ及び図１Ｂに示されている。システム１６上で実行することができるさらなるプロセスは、データベースインデクシングプロセスを含む。

図１Ａに示されるシステム内のいくつかの要素は、本明細書で簡略的に説明されるに過ぎない従来の周知要素を含む。例えば、各ユーザシステム１２は、デスクトップパーソナルコンピュータ、ワークステーション、ラップトップ、ＰＤＡ、携帯電話機、若しくは任意の無線アクセスプロトコル（ＷＡＰ）対応デバイス、又はインターネット若しくは他のネットワーク接続と直接的又は間接的にインタフェースをとることができる任意の他のコンピューティングデバイスを含み得る。用語「コンピューティングデバイス」は、本明細書において単に「コンピュータ」とも呼ばれる。ユーザシステム１２は、通常は、例えばブラウジングプログラムといった、Ｍｉｃｒｏｓｏｆｔ（登録商標）のＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）ブラウザ、Ｎｅｔｓｃａｐｅ（登録商標）のＮａｖｉｇａｔｏｒブラウザ、Ｏｐｅｒａ（登録商標）のブラウザ、又は、携帯電話機、ＰＤＡ、若しくは他の無線デバイスの場合にはＷＡＰ対応ブラウザ等といったＨＴＴＰクライアントを実行して、ユーザシステム１２のユーザ（例えば、マルチテナントデータベースシステムのサブスクライバ）が、システム１６からネットワーク１４を介してそのユーザが利用可能な情報、ページ、及びアプリケーションにアクセスし、それらを処理し、それらを閲覧することを可能にする。各ユーザシステム１２はまた、通常は、システム１６又は他のシステム若しくはサーバにより提供されるページ、フォーム、アプリケーション、及び他の情報とともにブラウザによりコンピューティングデバイスのディスプレイ（例えば、モニタスクリーン、ＬＣＤディスプレイ等）上に提供されるグラフィカルユーザインタフェース（ＧＵＩ）とインタラクトするための、キーボード、マウス、トラックボール、タッチパッド、タッチスクリーン、ペン、又は同様のもの等の１以上のユーザ入力デバイスを含む。例えば、ユーザインタフェースデバイスは、システム１６によりホストされているアプリケーション及びデータにアクセスし、記憶されているデータに対して探索を実行し、ユーザがユーザに提示され得る様々なＧＵＩページとインタラクトすることを他の形で可能にするために使用され得る。上述したように、実施例は、インターネットとともに使用するのに適したものであるが、イントラネット、エクストラネット、仮想プライベートネットワーク（ＶＰＮ）、非ＴＣＰ／ＩＰベースのネットワーク、任意のＬＡＮ若しくはＷＡＮ、又は同様のネットワーク等の他のネットワークが、インターネットの代わりに、あるいはインターネットに加えて、使用されてもよい。

一実施例に従うと、各ユーザシステム１２及びそのコンポーネントの全ては、Ｉｎｔｅｌ（登録商標） Ｐｅｎｔｉｕｍ（登録商標）プロセッサ又は同様のもの等の中央処理装置を用いて実行されるコンピュータコードを含む、ブラウザ等のアプリケーションを用いてオペレータ構成可能である。同様に、システム１６（及び、複数存在する場合にはＭＴＳのさらなるインスタンス）並びにそのコンポーネントの全ては、Ｉｎｔｅｌ（登録商標） Ｐｅｎｔｉｕｍ（登録商標）プロセッサ若しくは同様のものを含み得る中央処理装置及び／又は複数のプロセッサ装置を含むよう実装され得るプロセッサシステム１７を用いて実行されるコンピュータコードを含む１以上のアプリケーションを用いてオペレータ構成可能であり得る。非一時的なコンピュータ読み取り可能媒体は、命令を記憶することができ、そのような命令は、本明細書で説明される実施例の方法のいずれかを実行するコンピューティングデバイスにより実行され得る、あるいは本明細書で説明される実施例の方法のいずれかを実行するようコンピューティングデバイスをプログラムするために使用され得る。本明細書で説明されるように、ウェブページ、アプリケーション、並びに他のデータ及びメディアコンテンツを相互通信して、処理するようにシステム１６を動作させ構成するための命令を実装するコンピュータプログラムコード２６は、好ましくは、ダウンロード可能であり、ハードディスクに記憶されるが、プログラムコード全体又はその部分は、ＲＯＭ又はＲＡＭ等の、周知である任意の他の揮発性又は不揮発性メモリ媒体又はデバイスに記憶されてもよいし、フロッピディスク、光ディスク、デジタル多用途ディスク（ＤＶＤ）、コンパクトディスク（ＣＤ）、マイクロドライブ、及び光磁気ディスクを含む任意のタイプの回転媒体、磁気カード若しくは光カード、ナノシステム（分子メモリＩＣを含む）、又は、命令及び／又はデータを記憶するのに適した任意の他のタイプのコンピュータ読み取り可能媒体又はデバイス等の、プログラムコードを記憶することができる任意の媒体に提供されてもよい。さらに、プログラムコード全体又はその部分は、例えば、インターネット等の伝送媒体を介してソフトウェアソースから、あるいは周知である別のサーバから送信されダウンロードされてもよいし、周知である任意の他の従来のネットワーク接続（例えば、エクストラネット、ＶＰＮ、ＬＡＮ等）を介して、周知である任意の通信媒体及びプロトコル（例えば、ＴＣＰ／ＩＰ、ＨＴＴＰ、ＨＴＴＰＳ、イーサネット（登録商標）等）を用いて送信されてもよい。また、クライアントシステム及び／又はサーバ若しくはサーバシステム上で実行され得る、開示される実施例のためのコンピュータコードは、例えば、Ｃ、Ｃ＋＋、ＨＴＭＬ、任意の他のマークアップ言語、Ｊａｖａ（登録商標）、ＪａｖａＳｃｒｉｐｔ（登録商標）、ＡｃｔｉｖｅＸ（登録商標）、ＶＢＳｃｒｉｐｔ等の任意の他のスクリプト言語、及び、使用することができる周知である多くの他のプログラミング言語等の任意のプログラミング言語により実現され得ることも理解されよう（Ｊａｖａ（登録商標）は、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ， Ｉｎｃ．の商標である）。

いくつかの実施例に従うと、各システム１６は、ウェブページ、フォーム、アプリケーション、データ、及びメディアコンテンツをユーザシステム（クライアントシステム）１２に提供して、システム１６のテナントとしてのユーザシステム１２によるアクセスをサポートするよう構成される。そのようなものとして、システム１６は、データが共用される場合を除いて、各テナントのデータを別々に保持するためのセキュリティ機構を提供する。複数のＭＴＳが使用される場合、それらは、互いに近接して（例えば、１つのビル又はキャンパス内に配置されたサーバファーム内に）配置されてもよいし、互いから離れた場所に分散されてもよい（例えば、１以上のサーバをＡ市に配置させ、１以上のサーバをＢ市に配置させる）。本明細書で使用されるように、各ＭＴＳは、局所的に、あるいは１以上の地理的場所にわたって分散された１以上の論理的及び／又は物理的に接続されたサーバを含み得る。さらに、用語「サーバ」は、当分野で周知である、処理ハードウェア及び１以上のプロセススペース、メモリデバイス又はデータベース等の関連する記憶媒体、並びに、いくつかの例ではデータベースアプリケーション（例えば、ＯＯＤＢＭＳ又はＲＤＢＭＳ）を含むコンピューティングデバイス又はコンピューティングシステムを指すことが意図される。また、「サーバシステム」及び「サーバ」は、本明細書においてしばしば同じ意味で使用されることを理解すべきである。同様に、本明細書に記載されるデータベースオブジェクトは、単一のデータベース、分散データベース、分散データベースの集合、冗長オンラインバックアップ若しくは冗長オフラインバックアップ又は他の冗長性を有するデータベース等として実装され得、分散データベース又はストレージネットワーク、及び関連する処理インテリジェンス（processing intelligence）を含み得る。

図１Ｂは、図１Ａの要素とそれら要素間の種々の可能な相互接続とのいくつかの実装の例のブロック図を示している。すなわち、図１Ｂも環境１０を示している。しかしながら、図１Ｂでは、いくつかの実施例におけるシステム１６の要素と種々の相互接続とが、さらに例示されている。図１Ｂは、ユーザシステム１２が、プロセッサシステム１２Ａ、メモリシステム１２Ｂ、入力システム１２Ｃ、及び出力システム１２Ｄを含み得ることを示している。図１Ｂは、ネットワーク１４及びシステム１６を示している。図１Ｂはまた、システム１６が、テナントデータストレージ２２、テナントデータ２３、システムデータストレージ２４、システムデータ２５、ユーザインタフェース（ＵＩ）３０、アプリケーションプログラムインタフェース（ＡＰＩ）３２、ＰＬ／ＳＯＱＬ３４、記録ルーチン３６、アプリケーションセットアップ機構３８、アプリケーションサーバ１００_１〜１００_Ｎ、システムプロセススペース１０２、テナントプロセススペース１０４、テナント管理プロセススペース１１０、テナントストレージスペース１１２、ユーザストレージ１１４、及びアプリケーションメタデータ１１６を含み得ることを示している。他の実施例において、環境１０は、上記で挙げた要素と同じ要素を有さなくてもよいし、且つ／あるいは、上記で挙げた要素の代わりに、又は上記で挙げた要素に加えて、他の要素を有してもよい。

ユーザシステム１２、ネットワーク１４、システム１６、テナントデータストレージ２２、及びシステムデータストレージ２４は、図１Ａにおいて上述されている。ユーザシステム１２に関して、プロセッサシステム１２Ａは、１以上のプロセッサの任意の組合せであり得る。メモリシステム１２Ｂは、１以上のメモリデバイス、短期メモリ、及び／又は長期メモリの任意の組合せであり得る。入力システム１２Ｃは、１以上のキーボード、マウス、トラックボール、スキャナ、カメラ、及び／又はネットワークへのインタフェース等の入力デバイスの任意の組合せであり得る。出力システム１２Ｄは、１以上のモニタ、プリンタ、及び／又はネットワークへのインタフェース等の出力デバイスの任意の組合せであり得る。図１Ｂに示されるように、システム１６は、ＨＴＴＰアプリケーションサーバ１００のセットとして実装された（図１Ａの）ネットワークインタフェース２０、アプリケーションプラットフォーム１８、テナントデータストレージ２２、及びシステムデータストレージ２４を含み得る。個々のテナントプロセススペース１０４及びテナント管理プロセススペース１１０を含むシステムプロセススペース１０２も示されている。各アプリケーションサーバ１００は、ユーザシステム１２のリクエストを処理するために、テナントデータストレージ２２及びテナントデータストレージ２２内のテナントデータ２３、並びに、システムデータストレージ２４及びシステムデータストレージ２４内のシステムデータ２５と通信するよう構成され得る。テナントデータ２３は、データの物理構成及び／又は論理構成であり得る個々のテナントストレージスペース１１２に分割され得る。各テナントストレージスペース１１２内では、ユーザストレージ１１４及びアプリケーションメタデータ１１６が、ユーザごとに同様に割り当てられ得る。例えば、ユーザの直近に使用された（ＭＲＵ：most recently used）項目のコピーは、ユーザストレージ１１４に記憶され得る。同様に、テナントである組織全体についてのＭＲＵ項目のコピーは、テナントストレージスペース１１２に記憶され得る。ＵＩ３０は、システム１６に存在するプロセスへのユーザインタフェースを、ＡＰＩ３２は、そのようなプロセスへのアプリケーションプログラマインタフェースを、ユーザシステム１２におけるユーザ及び／又は開発者に提供する。テナントデータ及びシステムデータは、１以上のＯｒａｃｌｅ（登録商標）データベース等の様々なデータベースに記憶され得る。

アプリケーションプラットフォーム１８は、アプリケーション開発者のアプリケーションの作成及び管理をサポートするアプリケーションセットアップ機構３８を含み、アプリケーションは、例えば、テナント管理プロセス１１０により管理される１以上のテナントプロセススペース１０４としてのサブスクライバによる実行のために、記録ルーチン３６によりテナントデータストレージ２２にメタデータとして記録され得る。そのようなアプリケーションへの呼び出しは、プログラミング言語形式のインタフェース拡張をＡＰＩ３２に提供するＰＬ／ＳＯＱＬ３４を用いてコード化され得る。いくつかのＰＬ／ＳＯＱＬ言語実装の詳細な説明は、Craig Weissmanによる「METHOD AND SYSTEM FOR ALLOWING ACCESS TO DEVELOPED APPLICATIONS VIA A MULTI-TENANT ON-DEMAND DATABASE SERVICE」と題された２０１０年６月１日に発行された同一出願人による米国特許第７７３０４７８号に記載されており、これは、その全体を参照することにより、全ての目的のために、本明細書に組み込まれる。アプリケーションへの呼び出しは、１以上のシステムプロセスにより検出され得、１以上のシステムプロセスは、サブスクライバが、アプリケーションを呼び出して、アプリケーションメタデータ１１６をアプリケーションとして仮想マシンにおいて実行するために、アプリケーションメタデータ１１６の取得を管理する。

各アプリケーションサーバ１００は、データベースシステムに通信可能に接続され得、データベースシステムは、例えば、異なるネットワーク接続を介してシステムデータ２５及びテナントデータ２３にアクセスする。例えば、あるアプリケーションサーバ１００_１は、ネットワーク１４（例えば、インターネット）を介して接続され得、別のアプリケーションサーバ１００_Ｎ−１は、直接ネットワークリンクを介して接続され得、別のアプリケーションサーバ１００_Ｎは、さらに異なるネットワーク接続を介して接続され得る。伝送制御プロトコル及びインターネットプロトコル（ＴＣＰ／ＩＰ）は、アプリケーションサーバ１００とデータベースシステムとの間で通信するための典型的なプロトコルである。しかしながら、使用されるネットワーク相互接続に応じてシステムを最適化するために、他の転送プロトコルが使用されてもよいことが当業者には明らかであろう。

所定の実施例において、各アプリケーションサーバ１００は、テナントである任意の組織に関連付けられた任意のユーザのリクエストを処理するよう構成される。任意の時点において任意の理由でアプリケーションサーバをサーバプールに追加でき、アプリケーションサーバをサーバプールから除去できることが望ましいので、好ましくは、特定のアプリケーションサーバ１００に対するユーザ及び／又は組織のサーバアフィニティは存在しない。したがって、一実施形態において、リクエストをアプリケーションサーバ１００に分配するために、アプリケーションサーバ１００とユーザシステム１２との間に、負荷平衡機能（例えば、Ｆ５ Ｂｉｇ−ＩＰ負荷バランサ）を実装するインタフェースシステムが通信可能に接続される。一実施例において、負荷バランサは、ユーザリクエストをアプリケーションサーバ１００にルーティングするために、最小接続アルゴリズムを使用する。ラウンドロビンの観測された応答時間等、負荷平衡アルゴリズムの他の例が使用されてもよい。例えば、所定の実施例において、同じユーザからの３つの連続したリクエストが、３つの異なるアプリケーションサーバ１００に到達することがあり得、異なるユーザからの３つのリクエストが、同じアプリケーションサーバ１００に到達することもあり得る。このように、例えば、システム１６は、マルチテナント型であり、システム１６は、異なるユーザ及び組織にわたる異なるオブジェクト、データ、及びアプリケーションの記憶、並びに異なるオブジェクト、データ、及びアプリケーションへのアクセスを処理する。

ストレージの一例として、あるテナントは、販売員を雇用する会社であり得、各販売員は、各自の販売プロセスを管理するためにシステム１６を使用する。したがって、ユーザは、連絡先データ、リードデータ、顧客フォローアップデータ、実績データ、目標及び進捗データ等、そのユーザの個人販売プロセスに利用可能な全てを、（例えば、テナントデータストレージ２２に）保持することができる。ＭＴＳ構成の一例において、アクセス、閲覧、変更、報告、送信、計算等を行うためのデータ及びアプリケーションの全てが、ネットワークアクセスを有するに過ぎないユーザシステムにより保持されアクセスされ得るので、ユーザは、多くの異なるユーザシステムのいずれからも、自身の販売活動及び販売サイクルを管理することができる。例えば、販売員が顧客を訪問しており、顧客がロビーにおいてインターネットアクセスを有する場合、販売員は、顧客がロビーに到着するのを待ちながら、顧客に関する重大なアップデートを得ることができる。

各ユーザのデータは、各ユーザの雇用者にかかわらず、他のユーザのデータから分離され得るが、いくつかのデータは、テナントである所与の組織の複数のユーザ又は全てのユーザにより共用又はアクセスされる全組織的なデータであり得る。したがって、他のデータ構造がユーザレベルで管理され得る一方で、テナントレベルで割り当てられる、システム１６により管理されるいくつかのデータ構造が存在し得る。ＭＴＳは、見込みコンペティタを含む複数のテナントをサポートできるので、ＭＴＳは、データ、アプリケーション、及びアプリケーション使用を独立して維持するセキュリティプロトコルを有するべきである。また、多くのテナントは、各自のシステムを維持するよりも、ＭＴＳにアクセスする方を選択することがあるので、冗長性、使用可能時間（up-time）、及びバックアップは、ＭＴＳにおいて実装され得る付加機能である。ユーザ固有データ及びテナント固有データに加えて、システム１６は、複数のテナントにより使用可能なシステムレベルデータ、又は他のデータも保持することができる。そのようなシステムレベルデータは、テナント間で共有可能な業界レポート、ニュース、及びポスティング等を含み得る。

所定の実施例において、（クライアントシステムであり得る）ユーザシステム１２は、システムレベルデータ及びテナントレベルデータをシステム１６にリクエストして、アップデートするために、アプリケーションサーバ１００と通信する。このリクエスト及びアップデートは、１以上のクエリをテナントデータストレージ２２及び／又はシステムデータストレージ２４に送信することを含み得る。システム１６（例えば、システム１６内のアプリケーションサーバ１００）は、所望の情報にアクセスするために設計される１以上のＳＱＬ文（例えば、１以上のＳＱＬクエリ）を自動的に生成する。システムデータストレージ２４は、リクエストされたデータをデータベースから取得するためのクエリプランを生成することができる。

各データベースは、一般に、予め定義されたカテゴリに一致するデータを含む、論理テーブルのセット等のオブジェクトの集合とみなすことができる。「テーブル」は、データオブジェクトの１つの表現であり、いくつかの実施例に従ったオブジェクト及びカスタムオブジェクトの概念的説明を簡略化するために本明細書では使用され得る。「テーブル」及び「オブジェクト」は、本明細書において同じ意味で使用され得ることを理解すべきである。各テーブルは、一般に、閲覧可能なスキーマにおいて列すなわちフィールドとして論理的に配列される１以上のデータカテゴリを含む。テーブルの各行すなわちレコードは、フィールドにより定義される各カテゴリについてのデータのインスタンスを含む。例えば、ＣＲＭデータベースは、名前、住所、電話番号、ファックス番号等の基本連絡先情報用のフィールドを用いて顧客を記述するテーブルを含み得る。別のテーブルは、顧客、製品、販売価格、日付等の情報用のフィールドを含む発注を記述することができる。いくつかのマルチテナントデータベースシステムにおいて、全てのテナントにより使用するための標準エンティティテーブルが提供され得る。ＣＲＭデータベースアプリケーションの場合、そのような標準エンティティテーブルは、各々が予め定義されたフィールドを含む、案件、取引先、連絡先、リード、及び商談データオブジェクト用のテーブルを含み得る。用語「エンティティ」は、本明細書において「オブジェクト」及び「テーブル」と同じ意味で使用され得ることも理解すべきである。

いくつかのマルチテナントデータベースシステムにおいて、テナントは、カスタムオブジェクトを作成して記憶させることを許可され得る、あるいは、例えば、カスタムインデクスフィールドを含む、標準オブジェクト用のカスタムフィールドを作成することにより、標準エンティティ又はオブジェクトをカスタマイズすることを許可され得る。Weissmanらによる「CUSTOM ENTITIES AND FIELDS IN A MULTI-TENANT DATABASE SYSTEM」と題された２０１０年８月１７日に発行された同一出願人による米国特許第７７７９０３９号（これは、その全体を参照することにより、全ての目的のために、本明細書に組み込まれる）は、マルチテナントデータベースシステムにおいてカスタムオブジェクトを作成するとともに標準オブジェクトをカスタマイズするためのシステム及び方法を教示している。例えば、所定の実施例において、全てのカスタムエンティティデータ行は、組織当たり複数の論理テーブルを含み得る単一のマルチテナント物理テーブルに記憶される。顧客の複数の「テーブル」が、実際には１つの大きなテーブルに記憶されること、又は、顧客のデータが、他の顧客のデータと同じテーブルに記憶されることがあることが、顧客に透過的である。

図２Ａは、いくつかの実施例に従ったオンデマンドデータベースサービス環境２００のアーキテクチャコンポーネントの例を示すシステム図を示している。本明細書で説明されるように、組み合わされた１以上のネットワークを一般に指すクラウド２０４内に配置されたクライアントマシンは、１以上のエッジルータ２０８及び２１２を介して、オンデマンドデータベースサービス環境と通信することができる。クライアントマシンは、上述したユーザシステム１２の例のいずれかであり得る。エッジルータは、ファイアウォール２１６を介して、１以上のコアスイッチ２２０及び２２４と通信することができる。コアスイッチは、負荷バランサ２２８と通信することができ、負荷バランサ２２８は、ポッド２４０及び２４４等の異なるポッドに対してサーバ負荷を分散させることができる。各々が１以上のサーバ及び／又は他のコンピューティングリソースを含み得るポッド２４０及び２４４は、オンデマンドサービスを提供するために用いられるデータ処理及び他のオペレーションを実行することができる。ポッドとの通信は、ポッドスイッチ２３２及び２３６を介してなされ得る。オンデマンドデータベースサービス環境のコンポーネントは、データベースファイアウォール２４８及びデータベーススイッチ２５２を介して、データベースストレージ２５６と通信することができる。

図２Ａ及び図２Ｂに示されるように、オンデマンドデータベースサービス環境にアクセスすることは、種々の異なるハードウェアコンポーネント及び／又はソフトウェアコンポーネント間で伝送される通信を含み得る。さらに、オンデマンドデータベースサービス環境２００は、実際のオンデマンドデータベースサービス環境の単純化された表現である。例えば、図２Ａ及び図２Ｂにおいて、各タイプの１つのデバイス又は２つのデバイスのみが示されているが、オンデマンドデータベースサービス環境のいくつかの実装は、各タイプの１つのデバイスから多数のデバイスの範囲を含んでもよい。また、オンデマンドデータベースサービス環境は、図２Ａ及び図２Ｂに示される各デバイスを含む必要はないし、図２Ａ及び図２Ｂに示されないさらなるデバイスを含んでもよい。

さらに、オンデマンドデータベースサービス環境２００内のデバイスのうちの１以上は、同じ物理デバイス又は異なるハードウェア上に実装されてもよい。いくつかのデバイスは、ハードウェア又はハードウェアとソフトウェアとの組合せを用いて実装され得る。したがって、本明細書で使用される「データ処理装置」、「マシン」、「サーバ」、及び「デバイス」等の用語は、単一のハードウェアデバイスに限定されるものではなく、説明される機能を提供するよう構成された任意のハードウェア及びソフトウェアを含む。

クラウド２０４は、インターネットをしばしば含む、１つのデータネットワーク又は複数のデータネットワークを指すよう意図されている。クラウド２０４内に配置されたクライアントマシンは、オンデマンドデータベースサービス環境と通信して、オンデマンドデータベースサービス環境により提供されるサービスにアクセスすることができる。例えば、クライアントマシンは、オンデマンドデータベースサービス環境にアクセスして、情報を取得、記憶、編集、及び／又は処理することができる。

いくつかの実施例において、エッジルータ２０８及び２１２は、クラウド２０４とオンデマンドデータベースサービス環境２００の他のコンポーネントとの間でパケットをルーティングする。エッジルータ２０８及び２１２は、ボーダゲートウェイプロトコル（ＢＧＰ）を使用することができる。ＢＧＰは、インターネットのコアルーティングプロトコルである。エッジルータ２０８及び２１２は、インターネット上の自律システム間におけるネットワーク到達可能性を示す、ＩＰネットワークのテーブル、すなわち、「プレフィックス」を保持することができる。

１以上の実施例において、ファイアウォール２１６は、インターネットトラフィックから、オンデマンドデータベースサービス環境２００の内部コンポーネントを保護することができる。ファイアウォール２１６は、ルールのセット及び他の基準に基づいて、オンデマンドデータベースサービス環境２００の内部コンポーネントへのアクセスをブロック、許可、又は拒否することができる。ファイアウォール２１６は、パケットフィルタ、アプリケーションゲートウェイ、ステートフルフィルタ、プロキシサーバ、又は任意の他のタイプのファイアウォールのうちの１以上として動作することができる。

いくつかの実施例において、コアスイッチ２２０及び２２４は、オンデマンドデータベースサービス環境２００内でパケットを転送する高能力スイッチである。コアスイッチ２２０及び２２４は、オンデマンドデータベースサービス環境内の異なるコンポーネント間でデータを迅速にルーティングするネットワークブリッジとして構成され得る。いくつかの実施例において、２以上のコアスイッチ２２０及び２２４の使用は、冗長性及び／又は低減された待ち時間を提供することができる。

いくつかの実施例において、ポッド２４０及び２４４は、オンデマンドデータベースサービス環境により提供されるコアデータ処理及びサービス機能を実行することができる。各ポッドは、様々なタイプのハードウェアコンピューティングリソース及び／又はソフトウェアコンピューティングリソースを含み得る。ポッドアーキテクチャの一例は、図２Ｂを参照してより詳細に説明される。

いくつかの実施例において、ポッド２４０とポッド２４４との間の通信は、ポッドスイッチ２３２及び２３６を介してなされ得る。ポッドスイッチ２３２及び２３６は、例えば、コアスイッチ２２０及び２２４を介した、ポッド２４０及び２４４とクラウド２０４内に配置されたクライアントマシンとの間の通信を円滑にすることができる。また、ポッドスイッチ２３２及び２３６は、ポッド２４０及び２４４とデータベースストレージ２５６との間の通信を円滑にすることができる。

いくつかの実施例において、負荷バランサ２２８は、ポッド２４０及び２４４間で作業負荷を分散させることができる。ポッド間でオンデマンドサービスリクエストを平衡させることは、リソースの使用を向上させること、スループットを増大させること、応答時間を低減させること、及び／又はオーバーヘッドを低減させることに役立ち得る。負荷バランサ２２８は、トラフィックを解析して転送するためのマルチレイヤスイッチを含み得る。

いくつかの実施例において、データベースストレージ２５６へのアクセスは、データベースファイアウォール２４８により保護され得る。データベースファイアウォール２４８は、プロトコルスタックのデータベースアプリケーションレイヤで動作するコンピュータアプリケーションファイアウォールとして動作することができる。データベースファイアウォール２４８は、構造化クエリ言語（ＳＱＬ）インジェクション、データベースルートキット、及び権限のない情報開示（unauthorized information disclosure）等のアプリケーション攻撃からデータベースストレージ２５６を保護することができる。

いくつかの実施例において、データベースファイアウォール２４８は、トラフィックをゲートウェイルータに渡す前にトラフィックをプロキシするリバースプロキシサービスの１以上の形態を使用するホストを含み得る。データベースファイアウォール２４８は、データベーストラフィックのコンテンツを調べて、所定のコンテンツ又はデータベースリクエストをブロックすることができる。データベースファイアウォール２４８は、データベース又はＳＱＬ管理インタフェースへのアプリケーションの接続を管理するとともにパケットをインターセプトしてパケットがデータベースネットワーク又はアプリケーションインタフェースとの間で伝送されるよう強いる、ＴＣＰ／ＩＰスタックの最上位の（atop）ＳＱＬアプリケーションレベルで動作することができる。

いくつかの実施例において、データベースストレージ２５６との通信は、データベーススイッチ２５２を介してなされ得る。マルチテナントデータベースストレージ２５６は、データベースクエリを処理するための複数のハードウェアコンポーネント及び／又はソフトウェアコンポーネントを含み得る。したがって、データベーススイッチ２５２は、オンデマンドデータベースサービス環境の他のコンポーネント（例えば、ポッド２４０及び２４４）により送信されたデータベースクエリを、データベースストレージ２５６内の適切なコンポーネントに向かわせることができる。

いくつかの実施例において、データベースストレージ２５６は、多くの異なる組織により共用されるオンデマンドデータベースシステムである。オンデマンドデータベースシステムは、マルチテナントアプローチ、仮想化アプローチ、又は任意の他のタイプのデータベースアプローチを使用することができる。オンデマンドデータベースシステムは、図１Ａ及び図１Ｂを参照してより詳細に説明されている。

図２Ｂは、いくつかの実施例に従ったオンデマンドデータベースサービス環境のアーキテクチャコンポーネントの例をさらに示すシステム図を示している。ポッド２４４を使用して、オンデマンドデータベースサービス環境２００のユーザにサービスを提供することができる。いくつかの実施例において、各ポッドは、様々なサーバ及び／又は他のシステムを含み得る。ポッド２４４は、１以上のコンテンツバッチサーバ２６４、コンテンツ検索サーバ２６８、クエリサーバ２８２、ファイルフォースサーバ（file force server）２８６、アクセス制御システム（ＡＣＳ）サーバ２８０、バッチサーバ２８４、及びアプリケーションサーバ（app server）２８８を含む。また、ポッド２４４は、データベースインスタンス２９０、クイックファイルシステム（ＱＦＳ）２９２、及びインデクサ２９４を含む。１以上の実施例において、ポッド２４４内のサーバ間の通信の一部又は全ては、スイッチ２３６を介して伝送され得る。

いくつかの実施例において、アプリケーションサーバ２８８は、ポッド２４４を介してオンデマンドデータベースサービス環境２００により提供されるアプリケーションの構築をサポートするためのプロシージャ（例えば、プログラム、ルーチン、スクリプト）の実行に専用のハードウェアフレームワーク及び／又はソフトウェアフレームワークを含み得る。いくつかの実施例において、アプリケーションサーバ２８８のハードウェアフレームワーク及び／又はソフトウェアフレームワークは、図１５〜図５６Ｃを参照して説明される方法のブロックの実行を含め、本明細書で説明されるサービスのオペレーションを実行するよう構成される。代替実施例において、２以上のアプリケーションサーバ２８８が、含まれて、協働してそのような方法を実行してもよいし、本明細書で説明される１以上の他のサーバが、開示される方法を実行するよう構成されてもよい。

コンテンツバッチサーバ２６４は、ポッドの内部に存在するリクエストを処理することができる。このようなリクエストは、長期に及ぶものであってもよいし、且つ／あるいは、特定の顧客に関連付けられていなくてもよい。例えば、コンテンツバッチサーバ２６４は、ログマイニング、クリーンアップ作業、及び保守タスクに関連するリクエストを処理することができる。

コンテンツ検索サーバ２６８は、クエリ機能及びインデクサ機能を提供することができる。例えば、コンテンツ検索サーバ２６８により提供される機能は、ユーザが、オンデマンドデータベースサービス環境に記憶されたコンテンツを検索することを可能にし得る。

ファイルフォースサーバ２８６は、Ｆｉｌｅｆｏｒｃｅストレージ２９８に記憶された情報を求めるリクエストを管理することができる。Ｆｉｌｅｆｏｒｃｅストレージ２９８は、文書、画像、及びベーシックラージオブジェクト（ＢＬＯＢ）等の情報を記憶することができる。ファイルフォースサーバ２８６を用いて、情報を求めるリクエストを管理することにより、データベース上のイメージフットプリント（image footprint）を低減させることができる。

クエリサーバ２８２を使用して、１以上のファイルシステムから情報を取得することができる。例えば、クエリシステム２８２は、アプリケーションサーバ２８８から、情報を求めるリクエストを受信し、次いで、情報クエリを、ポッド外部に配置されたＮＦＳ２９６に送信することができる。

ポッド２４４は、異なる組織が同じデータベースへのアクセスを共有するマルチテナント環境として構成されたデータベースインスタンス２９０を共有することができる。さらに、ポッド２４４により提供されるサービスは、様々なハードウェアリソース及び／又はソフトウェアリソースを要求することができる。いくつかの実施例において、ＡＣＳサーバ２８０は、データ、ハードウェアリソース、又はソフトウェアリソースへのアクセスを制御することができる。

いくつかの実施例において、バッチサーバ２８４は、指定された時間にタスクを実行するために用いられるバッチジョブを処理することができる。したがって、バッチサーバ２８４は、バッチジョブをトリガするために、アプリケーションサーバ２８８等の他のサーバに命令を送信することができる。

いくつかの実施例において、ＱＦＳ２９２は、カリフォルニア州サンタクララのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）から入手可能なオープンソースファイルシステムであり得る。ＱＦＳは、ポッド２４４内の利用可能な情報を記憶しそのような情報にアクセスするためのラピッドアクセスファイルシステムとして機能することができる。ＱＦＳ２９２は、多くのディスクがファイルシステムに一緒にグループ化されることを可能にする、いくつかのボリューム管理機能をサポートすることができる。ファイルシステムメタデータは、ディスクの別々のセット上で保持することができ、これは、長いディスクシークを許容できないアプリケーションをストリーミングするのに有用であり得る。したがって、ＱＦＳシステムは、１以上のコンテンツ検索サーバ２６８及び／又はインデクサ２９４と通信して、ネットワークファイルシステム２９６及び／又は他のストレージシステムに記憶されたデータを識別し、取得し、移動させ、且つ／あるいはアップデートすることができる。

いくつかの実施例において、１以上のクエリサーバ２８２は、ＮＦＳ２９６と通信して、ポッド２４４の外部で記憶された情報を取得及び／又はアップデートすることができる。ＮＦＳ２９６は、ポッド２４４内に配置されたサーバが、ローカルストレージにアクセスするのと同様の方法でネットワークを介してファイルにアクセスするために情報にアクセスすることを可能にし得る。

いくつかの実施例において、クエリサーバ２８２からのクエリは、負荷バランサ２２８を介してＮＦＳ２９６に伝送され得る。負荷バランサ２２８は、オンデマンドデータベースサービス環境内で利用可能な様々なリソースに対するリソースリクエストを分散させることができる。ＮＦＳ２９６はまた、ＱＦＳ２９２と通信して、ＮＦＳ２９６に記憶された情報をアップデートすることができる、且つ／あるいは、ポッド２４４内に配置されたサーバによる使用のために情報をＱＦＳ２９２に提供することができる。

いくつかの実施例において、ポッドは、１以上のデータベースインスタンス２９０を含み得る。データベースインスタンス２９０は、情報をＱＦＳ２９２に送信することができる。情報がＱＦＳに送信されると、さらなるデータベース呼び出しを用いることなく、ポッド２４４内のサーバによる使用のために、その情報が利用可能であり得る。

いくつかの実施例において、データベース情報は、インデクサ２９４に伝送され得る。インデクサ２９４は、データベース２９０及び／又はＱＦＳ２９２内の利用可能な情報のインデクスを提供することができる。インデクス情報は、ファイルフォースサーバ２８６及び／又はＱＦＳ２９２に提供され得る。

ＩＩＩ．データベースに記憶されたレコードに対するアップデートの追跡
複数のユーザが、レコードのデータを変更でき得るので、レコードがアップデートされたときを所定のユーザに通知することが有用であり得る。また、ユーザが、レコードを変更する権限を有していないとしても、そのユーザは、それでも、レコードがアップデートされたときを知りたいかもしれない。例えば、ベンダは、テナントＹに関連付けられたユーザである、会社Ｘの販売員と新価格について交渉することがある。新たな請求書を作成することの一部として、あるいは会計目的のために、その販売員は、データベースに記録された価格を変更することができる。価格が変更されたことを同僚が知ることは重要であり得る。その販売員は、電子メールを所定の人に送り得るが、これは面倒であり、その販売員は、知る必要がある、あるいは知りたいと望んでいる人の全てに電子メールを送らない可能性もある。したがって、開示される技術のいくつかの実施例は、レコードに対するアップデートについて知りたいと望んでいる他の人（例えば、同僚）に、自動的に通知することができる。

図３は、いくつかの実施例に従って実行される、データベースシステムに記憶されたレコードに対するアップデートを追跡するための方法３００の一例のフローチャートを示している。方法３００（及び、本明細書で説明される他の方法）は、例えば、情報を受信又は取得し、その情報を処理し、結果を記憶し、その結果を送信するよう構成された１以上のプロセッサにより、マルチテナントデータベースシステム１６を用いて少なくとも部分的に実施され得る。他の実施例において、方法３００は、シングルテナントデータベースシステムを用いて少なくとも部分的に実施され得る。様々な実施例において、ブロックは、除去されてもよいし、組み合わされてもよいし、方法３００用のさらなるブロックに分割されてもよい。本明細書で説明される他の方法についても同様である。

ブロック３１０において、データベースシステムは、第１のレコードをアップデートするリクエストを受信する。一実施例において、このリクエストは、第１のユーザから受信される。例えば、ユーザは、第１のレコードに関連付けられたページにアクセス中であり得、表示されたフィールドを変更して記録することがある。別の実施例において、データベースシステムは、このリクエストを自動的に生成することができる。例えば、データベースシステムは、例えば、特定の日及び／又は時間に定期的に送信され得る、フィールドを変更するリクエスト、又は、別のフィールド若しくはオブジェクトに対する変更といった別のイベントに応じて、このリクエストを生成することができる。データベースシステムは、レコードの他のフィールドに基づいて、且つ／あるいはシステムにおけるパラメータに基づいて、新たな値を取得することができる。

レコードのフィールドのアップデートを求めるこのリクエストは、フィード追跡アップデートが作成され得る、第１のレコードに関連付けられたイベントの一例である。他の実施例において、データベースシステムは、レコードのフィールドに対するアップデートに加えて、他のイベントも識別することができる。例えば、イベントは、フィールドを変更する承認の送信であり得る。そのようなイベントはまた、関連するフィールド（例えば、変更が送信されたかどうかのステータスを示すフィールド）を有することもできる。イベントの他の例は、レコードの作成、レコードの削除、あるタイプから別のタイプへのレコードの変換（例えば、リードから商談への変換）、レコード（例えば、案件タイプのレコード）のクローズ、及びレコードの可能な任意の他の状態変更（state change）を含み得、これらのいずれもが、状態変更に関連付けられたフィールド変更を含み得る。これらのイベントのいずれもが、レコードのフィールド、レコードの状態、又はレコードの何らかの他の特性若しくは属性を変更することにより、レコードをアップデートさせる。一実施例において、フィード追跡アップデートを作成するためにサポートされるイベントのリストが、例えば、サーバ又はデータベースにおいて、データベースシステム内に保持され得る。

ブロック３２０において、データベースシステムは、新たなデータを第１のレコードに書き込む。一実施例において、新たなデータは、古いデータに取って代わる新たな値を含み得る。例えば、フィールドが、新たな値を用いてアップデートされる。別の実施例において、新たなデータは、以前にはデータを含んでいなかったフィールドの値であり得る。さらに別の実施例において、新たなデータは、レコードのフィールドとして記憶され得る、例えばレコードのステータスのためのフラグであり得る。

いくつかの実施例において、「フィールド」はまた、親子階層における第１のレコードの子オブジェクトであるレコードを含み得る。代替的に、フィールドは、子レコードに対するポインタを含んでもよい。子オブジェクト自体もさらなるフィールドを含み得る。したがって、子オブジェクトのフィールドが、新たな値を用いてアップデートされる場合、親レコードも、変更されるフィールドを有するとみなされ得る。一例において、フィールドは、関連リスト（related list）とも呼ばれる関連子オブジェクト（related child object）のリストであり得る。

ブロック３３０において、レコードに対するアップデートについてのフィード追跡アップデートが生成される。一実施例において、フィード追跡アップデートは、後に表示バージョンにアセンブルするために部分的に作成される。例えば、イベントエントリが、第１のテーブル内で作成されて追跡され得、変更されたフィールドエントリが、第１のテーブルと相互参照されている別のテーブル内で追跡され得る。そのような実施例のさらなる詳細は、例えば図９Ａを参照して後で提供される。別の実施例において、フィード追跡アップデートは、データベースシステムにより自動的に生成される。フィード追跡アップデートは、第１のレコードがアップデートされたことを文字で伝え、レコードにおいて何がアップデートされたかと誰がアップデートを実行したかとについての詳細を提供することができる。いくつかの実施例において、フィード追跡アップデートは、所定のタイプのイベント及び／又は第１のレコードに関連付けられたアップデートに対してのみ生成される。

一実施例において、テナントは、（例えば、管理者を通じて、）所定のタイプのレコードのみに対するフィード追跡アップデートを作成する（有効にする）ようにデータベースシステムを構成することができる。例えば、管理者は、例えば、取引先及び商談等の指定されたタイプのレコードが有効にされることを指定することができる。有効にされたレコードタイプについてのアップデート（又は、他のイベント）が受信されると、フィード追跡アップデートが生成される。別の実施例において、テナントはまた、変更が追跡されるべきであり、フィード追跡アップデートが作成される、レコードのフィールドを指定することができる。一態様において、追跡するフィールドの最大数が指定され得、これにはカスタムフィールドが含まれ得る。一実施例において、例えば、フィールドの値変化が、閾値（例えば、絶対量又はパーセンテージ変化）よりも大きいといった変更のタイプも指定され得る。さらに別の実施例において、テナントは、どのイベントがフィード追跡アップデートを生成させるべきであるかを指定することができる。また、一実施例において、個々のユーザは、以下でより詳細に説明されるカスタムフィードを作成することができる、ユーザに固有の構成を指定することができる。

一実施例において、子オブジェクトのフィールドに対する変更は、親レコードに対するフィード追跡アップデートを作成するためには追跡されない。別の実施例において、子オブジェクトのフィールドに対する変更は、親レコードに対するフィード追跡アップデートを作成するために追跡され得る。例えば、親タイプの子オブジェクトが、追跡のために指定され得、子オブジェクトの所定のフィールドが、追跡のために指定され得る。別の例として、子オブジェクトが、追跡のために指定されたタイプである場合、子オブジェクトに対する追跡された変更が、子オブジェクトの親レコードに伝播される。

ブロック３４０において、フィード追跡アップデートが、第１のレコード用のフィードに追加される。一実施例において、フィード追跡アップデートをフィードに追加することは、イベントを、（レコードに固有であり得る、あるいはオブジェクトの全て又はオブジェクトのグループ用であり得る）テーブルに追加することを含み得、ユーザが、第１のレコード用のフィードをリクエストしたときに、フィード追跡アップデートの表示バージョンが、動的に生成されて、フィード項目としてＧＵＩ内に提示され得る。別の実施例において、レコードに関するレコードフィードが記憶され保持されるときに、フィード追跡アップデートの表示バージョンが追加されてもよい。上述したように、フィードは、所定のレコードに関してのみ保持され得る。一実施例において、レコードのフィードは、そのレコードに関連付けられたデータベースに記憶され得る。例えば、フィードは、そのレコードのフィールドとして（例えば、子オブジェクトとして）記憶され得る。そのようなフィールドは、フィード追跡アップデートに関して表示されるテキストに対するポインタを記憶することができる。

いくつかの実施例において、現在のフィード追跡アップデート（又は、他の現在のフィード項目）のみが、例えば、何らかの一時メモリ構造に、保持され得る、あるいは一時的に記憶され得る。例えば、任意の特定のフィールドに対する直近の変更のみについてのフィード追跡アップデートが保持される。他の実施例において、多くの以前のフィード追跡アップデートが、フィード内に保持されてもよい。各フィード追跡アップデートについての時間及び／又は日付が追跡され得る。本明細書において、レコードのフィードは、エンティティフィードとも呼ばれる。というのは、レコードは、データベースの特定のエンティティオブジェクトのインスタンスであるからである。

ブロック３５０において、第１のレコードのフォロワ（follower）が識別され得る。フォロワは、第１のレコードのフィードに対するサブスクライバ等、第１のレコードをフォローしているユーザである。一実施例において、ユーザが、特定のレコードのフィードをリクエストする場合、ブロック３５０のそのような識別は省略されてもよい。別の実施例において、レコードフィードが、（例えば、ニュースフィードの一部として、）ユーザにプッシュされる場合、そのユーザが、第１のレコードのフォロワとして識別され得る。したがって、このブロックは、特定のユーザによりフォローされているレコード及び他のオブジェクトの識別を含み得る。

一実施例において、データベースシステムは、特定のレコードについてのフォロワのリストを記憶することができる。様々な実施例において、このリストは、第１のレコードとともに、あるいはこのリストを取得するために識別子（例えば、ポインタ）を使用するレコードに関連付けられて、記憶され得る。例えば、このリストは、第１のレコードのフィールドに記憶され得る。別の実施例において、ユーザがフォローしているレコードのリストが使用される。一実施例において、データベースシステムは、各ユーザ用の、実行されるルーチンを有することができ、このルーチンは、リスト内のレコードをポーリングして、新たなフィード追跡アップデートがレコードのフィードに追加されたかどうかを判定する。別の実施例において、ユーザ用のこのルーチンは、ポーリングを実行するデータベースと通信するユーザデバイス上で少なくとも部分的に実行され得る。

ブロック３６０において、一実施例では、以下でより詳細に説明されるように、フィード追跡アップデートがテーブルに記憶され得る。ユーザがフィードを開いたときに、レコードに対するアップデートを取得するために、適切なクエリが、１以上のテーブルに送信される。このことも、以下でより詳細に説明される。いくつかの実施例において、フィードは、新しい順に（reverse chronological order）、フィード追跡アップデートを表示する。一実施例において、フィード追跡アップデートは、例えば、レコードに関連付けられたリストからレコードのフォロワを判別するルーチンにより、ユーザのフィードにプッシュされる。別の実施例において、フィード追跡アップデートは、例えばユーザデバイスにより、フィードにプルされる。このプルは、ブロック３７０で生じるように、ユーザがフィードをリクエストしたときに生じ得る。したがって、これらのアクションは、異なる順番で生じてもよい。プルされるフィードの作成は、リクエストしているユーザによりフォローされているレコードを識別する動的な作成であり得、記憶された情報（例えば、イベント及びフィールド変更）から、関連するフィード追跡アップデートの表示バージョンを生成し、フィード追跡アップデートをフィードに追加する。ユーザがフォローしているレコード及び他のオブジェクトのフィード追跡アップデートのフィードは、本明細書において、一般にニュースフィードとも呼ばれ、これは、ポスト等の他のタイプの情報アップデートが現れるより大きな情報フィードのサブセットであり得る。

さらに別の実施例において、フィード追跡アップデートは、フィード内に表示される代わりに、フォロワへの電子メールとして送信されてもよい。一実施例において、イベントについての電子メールアラートは、所定のイベントが発生したときに、人々に電子メールを送信することを可能にし得る。別の実施例において、ユーザプロフィールに対するポストが存在したときに、及びユーザがサブスクライブしているエンティティに対するポストが存在したときに、電子メールが送信されてもよい。一実施例において、ユーザは、全てのイベント又は一部のイベントについて、電子メールアラートをオン／オフにすることができる。一実施例において、ユーザは、このユーザがフォローしているレコードについて受信すべきフィード追跡アップデートの種類を指定することができる。例えば、ユーザは、このユーザがフォローしているレコードの所定のフィールドと、おそらくはどのような種類のアップデートが実行されたか（例えば、指定されたフィールドへの新たな値の入力、又は新たなフィールドの作成）と、についてのフィード追跡アップデートのみを受け取ることを選択することができる。

ブロック３７０において、フォロワは、自分のニュースフィードにアクセスして、フィード追跡アップデードを閲覧することができる。一実施例において、ユーザは、このユーザがフォローしているレコードの全てに対する１つのニュースフィードのみを有する。一態様において、ユーザは、データベースシステムへのインタフェースのページ上で特定のタブ又は他のオブジェクトを選択することにより、自分のフィードにアクセスすることができる。選択されると、フィードが、例えば、識別子（例えば、時間）を有するリスト又はフィード追跡アップデートのテキストの一部又は全てを含むリストとして、提供され得る。別の実施例において、ユーザは、フィード追跡アップデートがどのように表示されるべきか、及び／又は、フィード追跡アップデートがユーザにどのように送られるべきかを指定することができる。例えば、ユーザは、テキストのフォント、フィードを選択及び表示できる場所の位置、表示されるテキストの量、並びに表示される他のテキスト又は記号（例えば、重要度フラグ）を指定することができる。

図４は、いくつかの実施例に従ってレコードに対するアップデートを追跡するための方法を実行するデータベースシステム構成４００のコンポーネントの例のブロック図を示している。データベースシステム構成４００は、方法３００の実施例及び本明細書で説明される他の方法の実施例を実行し得る。

第１のユーザ４０５は、データベースシステム４１６内のレコード４２５をアップデートするリクエスト１を送る。アップデートリクエストについて説明されるが、追跡されている他のイベントにも等しく適用可能である。様々な実施例において、リクエスト１は、ユーザインタフェース（例えば、図１Ｂの３０）又はアプリケーションプログラムインタフェース（例えば、ＡＰＩ３２）を介して送信され得る。Ｉ／Ｏポート４２０は、任意の入力インタフェースを介したリクエスト１の信号を受け入れ、その信号を１以上のプロセッサ４１７に送信することができる。プロセッサ４１７は、リクエストを解析して、実行すべきオペレーションを判別することができる。本明細書において、プロセッサ４１７へのいかなる言及も、集合的にプロセッサ４１７と呼ばれ得る、データベースシステム４１６内の特定のプロセッサ又はプロセッサの任意のセットに対するものであり得る。

プロセッサ４１７は、レコード４２５の識別子を判別して、リクエストの新たなデータ２を含むコマンドを、レコード４２５をアップデートするレコードデータベース４１２に送信することができる。一実施例において、レコードデータベース４１２は、図１Ｂのテナントストレージスペース１１２が配置されている場所にある。リクエスト１及び新たなデータコマンド２が、単一のライトトランザクションにカプセル化され、レコードデータベース４１２に送信され得る。一実施例において、データベース内のレコードに対する複数の変更が、単一のライトトランザクションでなされ得る。

プロセッサ４１７はまた、リクエスト１を解析して、フィード追跡アップデートが作成されるべきであるかどうかを判定することができる。この判定は、この時点において、イベント（例えば、特定のフィールドに対する変更）が追跡されるべきであるかどうかを判定することを含み得る。この判定は、レコードデータベース４１２及び／又は他のデータベースとのインタラクション（すなわち、データの交換）に基づいてもよいし、プロセッサ４１７においてローカルに記憶された（例えば、キャッシュ又はＲＡＭに記憶された）情報に基づいてもよい。一実施例において、追跡されているレコードタイプのリストが記憶され得る。このリストは、テナントごとに異なり得る。というのは、例えば、各テナントは、自身の仕様に合わせてデータベースシステムを構成し得るからである。したがって、レコード４２５が、追跡されているタイプのものではない場合、フィード追跡アップデートを作成すべきかどうかの判定は、ここで終了し得る。

同じリスト又は第２のリスト（同じ位置又は異なる位置に記憶され得る）はまた、第１のリスト内のレコードタイプのために追跡されるフィールド及び／又はイベントを含み得る。このリストは、イベントが追跡されているかどうかを判定するために検索される。リストはまた、追跡されるべき特定のレコードをリストする粒度（granularity）を有する情報を含み得る（例えば、テナントが、タイプそのものではない、追跡されるべき特定のレコードを指定できるかどうか）。

一例として、プロセッサ４１７は、おそらくはテナント識別子とともに、（例えば、リクエスト１又はデータベース４１２から、）レコード４２５に関連付けられた識別子を取得し、その識別子とフィード追跡アップデートが作成されるべきレコードのリストとを相互参照することができる。詳細には、このレコード識別子は、レコードタイプを判別するために使用され得、追跡されるタイプのリストが、照合のために検索され得る。特定のレコードはまた、そのような個別のレコード追跡が有効にされたかどうかチェックされ得る。変更されるフィールドの名前が、追跡が有効にされたフィールドのリストを検索するために使用され得る。フィールド及びイベントに加えて、例えばフィールドにおける変更のタイプといった他の基準が、フィード追跡アップデートが作成されるかどうかを判定するために使用され得る。フィード追跡アップデートが生成されるべきである場合、プロセッサ４１７は、フィード追跡アップデートを生成することができる。

いくつかの実施例において、フィード追跡アップデートは、フィード（例えば、レコード４２５のエンティティフィード）がリクエストされたときに動的に作成される。したがって、一実施例において、フィード追跡アップデートは、ユーザがレコード４２５のエンティティフィードをリクエストしたときに作成され得る。この実施例において、フィード追跡アップデートは、再作成を含め、エンティティフィードが任意のユーザに対して表示されるときに作成され得る（例えば、アセンブルされ得る）。一実施例において、１以上のイベント履歴テーブルは、フィード追跡アップデートが再作成され得るように、以前のイベントを追跡することができる。

別の実施例において、フィード追跡アップデートは、イベントが発生したときに作成され得、そのフィード追跡アップデートは、フィード項目のリストに追加され得る。フィード項目のリストは、レコード４２５に固有であってもよいし、多くのレコード用のフィード項目を含む、フィード項目の集約であってもよい。そのような集約リストは、レコード４２５のエンティティフィード用のフィード項目が容易に取得され得るように、レコード識別子を含み得る。例えば、フィード追跡アップデートが生成された後、プロセッサ４１７は、新たなフィード追跡アップデート３を、レコード４２５のフィードに追加することができる。上述したように、一実施例において、フィードは、レコード４２５のフィールドに（例えば子オブジェクトとして）記憶され得る。別の実施例において、フィードは、別の位置又は別のデータベースに記憶されてもよいが、その場合、レコード４２５へのリンク（例えば、コネクション識別子）を伴って記憶される。フィードは、例えば、リンク付きリスト（linked list）、配列、又は他のデータ構造として、様々な形で編成され得る。

第２のユーザ４３０は、様々な方法により、新たなフィード追跡アップデート３にアクセスすることができる。一実施例において、第２のユーザ４３０は、レコードフィードを求めるリクエスト４を送ることができる。例えば、第２のユーザ４３０は、（例えば、クエリを用いて、あるいはブラウジングにより）レコード４２５のホームページ（詳細ページ）にアクセスし、そのページ上のタブ、ボタン、又は他のアクティベーションオブジェクト（activation object）を介してフィードを取得することができる。

別の実施例において、プロセッサ４１７は、新たなフィード追跡アップデート５を、レコード４２５をフォローしているユーザのフィード（例えば、ニュースフィード）に追加することができる。一実施例において、プロセッサ４１７は、フォロワとして登録されているユーザのリストにアクセスすることにより、レコード４２５のフォロワの各々を判別することができる。この判別は、新たなイベント（例えば、アップデート１）ごとになされ得る。別の実施例において、プロセッサ４１７は、新たなフィード追跡アップデート（又は、他のフィード項目）が利用可能であるときを判定するために、（例えば、クエリを用いて）第２のユーザ４３０がフォローしているレコードをポーリングすることができる。プロセッサ４１７は、第２のユーザ４３０がフォローしているレコードのリストを含み得る、第２のユーザ４３０のフォロワプロフィール４３５を使用することができる。そのようなリストは、データベースの他の部分に含まれてもよい。その後、第２のユーザ４３０は、新たなフィード追跡アップデートを含むフィードを取得するために、リクエスト６を自分のプロフィール４３５に送ることができる。ユーザのプロフィール４３５は、データベース４１２と同じであっても異なってもよいプロフィールデータベース４１４に記憶され得る。

いくつかの実施例において、ユーザは、最大数に制限され得る、様々なレコードからの新たなフィード追跡アップデートを含むようにニュースフィードを定義することができる。一実施例において、各ユーザは１つのニュースフィードを有する。別の実施例において、フォロワプロフィール４３５は、フィードに加えて、（どのフィード追跡アップデートが提供されるべきであるかと、そのようなフィード追跡アップデートがどのように表示されるかと、に関する基準を含む、）フォローされるレコードの各々の仕様を含み得る。

いくつかの実施例は、様々なタイプのレコード（エンティティ）フィードを提供することができる。エンティティフィードは、取引先、商談、案件、及び連絡先のようなレコードタイプについて存在し得る。エンティティフィードは、特定のレコード又はその関連レコードに対して人々が取ったアクションについてユーザに知らせることができる。エンティティフィードは、誰がアクションを行ったか、どのフィールドが変更されたか、並びに、古い値及び新たな値を含み得る。一実施例において、エンティティフィードは、特定のレコードにリンクされているリストとして、全てのサポートされるレコードについて存在し得る。例えば、フィードは、リスト（例えば、リンク付きリスト）を許容するフィールドに、あるいは子オブジェクトとして記憶され得る。

ＩＶ．ユーザのアクションの追跡
特定のレコードに関連付けられたイベントについて知ることに加えて、ユーザが、特定のユーザが行っていることを知ることは有用であり得る。特に、ユーザがフィード追跡アップデートを生成する必要なく（例えば、ユーザが行ったことの概要を送ることなく）ユーザが行っていることを知ることは有用であり得る。したがって、実施例は、イベントをトリガするユーザのアクションを自動的に追跡することができ、フィード追跡アップデートが、所定のイベントに関して生成され得る。

図５は、いくつかの実施例に従って実行される、データベースシステムのユーザのアクションを追跡するための方法５００の一例のフローチャートを示している。方法５００は、方法３００に加えて実行され得る。ブロックの順番を含め、方法３００のオペレーションは、方法５００及び本明細書で説明される他の方法と組み合わせて実行され得る。したがって、フィードは、レコードに対する変更とユーザのアクションとから構成され得る。

ブロック５１０において、データベースシステム（例えば、図１Ａ及び図１Ｂの１６）は、第１のユーザのアクションを識別する。一実施例において、このアクションはイベントをトリガし、このイベントが識別される。例えば、レコードに対するアップデートをリクエストするユーザのアクションが識別され得る。ここで、イベントは、リクエストを受信すること、又は、レコードの結果として生じるアップデートである。したがって、アクションは、結果として生じるイベントにより定義され得る。別の実施例において、所定のタイプのアクション（イベント）のみが識別される。どのアクションが識別されるかは、デフォルトとして設定されてもよいし、テナントにより設定可能であってもよいし、さらにはユーザレベルで設定可能であってもよい。このように、いくつかのアクションしか識別されないので、処理労力を低減させることができる。

ブロック５２０において、イベントがフィード追跡アップデートの対象であるかどうかが判定される。一実施例において、所定のアクションのみが識別されるように、（例えば、本明細書で説明される）イベントの予め定められたリストが作成され得る。一実施例において、テナントの管理者（又は、他のユーザ）は、フィード追跡アップデートが生成されるべきアクション（イベント）のタイプを指定することができる。このブロックは、方法３００のためにも実行され得る。

ブロック５３０において、アクションについてのフィード追跡アップデートが生成される。一例において、アクションがレコードのアップデートである場合、フィード追跡アップデートは、そのレコードに関して作成されるフィード追跡アップデートと同様又は同一であり得る。記載は、レコードではなくユーザにフォーカスするよう変更され得る。例えば、「an opportunity has been closed for account XYX（商談は、取引先ＸＹＺに関してクローズされた）」ではなく、「John D. has closed a new opportunity for account XYX（Ｊｏｈｎ Ｄ．は、取引先ＸＹＺに関して新たな商談をクローズした）」といったようにである。

ブロック５４０において、例えば、第１のユーザが、ブラウザプログラムにおいてプロフィールフィードを表示するページを開くためのタブをクリックしたときに、フィード追跡アップデートが、第１のユーザのプロフィールフィードに追加される。一実施例において、特定のユーザ用のフィードは、レコードフィードがレコードの詳細ページ上でアクセスされ得るのと同様、ユーザのプロフィールのページ上でアクセスされ得る。別の実施例において、第１のユーザは、プロフィールフィードを有していないことがあり、フィード追跡アップデートは、進む前に一時的に記憶されるだけでよい。ユーザのプロフィールフィードは、ユーザのプロフィールに関連付けられて記憶され得る。このプロフィールフィードは、別のユーザのニュースフィードに追加され得る。

ブロック５５０において、第１のユーザのフォロワが識別される。一実施例において、ユーザは、他のユーザがフォローできるアクションのタイプを指定することができる。同様に、一実施例において、フォロワは、このフォロワがフォローしたいと望むユーザによるアクションを選択することができる。一実施例において、異なるフォロワが、異なるタイプのアクションをフォローする場合、どのユーザが、そのユーザ及び特定のアクションのフォロワであるかが、例えば、どのアクション及び基準が特定のユーザによりフォローされているかを追跡する様々なリストを用いて識別され得る。様々な実施例において、第１のユーザのフォロワは、ブロック３５０に関して上述したレコードのフォロワと同様に識別され得る。

ブロック５６０において、例えば、第１のユーザの各フォロワが、ニュースフィードを表示するページを開くためのタブをクリックしたときに、フィード追跡アップデートが、第１のユーザの各フォロワのニュースフィードに追加される。フィード追跡アップデートは、レコードフィードのフィード項目と同様に追加され得る。ニュースフィードは、ユーザ及びレコード両方についてのフィード追跡アップデートを含み得る。別の実施例において、ユーザは、このユーザがフォローしているユーザについて受信すべきフィード追跡アップデートの種類を指定することができる。例えば、ユーザは、特定のキーワードを含むフィード追跡アップデート、所定のタイプのレコードのフィード追跡アップデート、所定のユーザにより所有又は作成されたレコードのフィード追跡アップデート、特定のフィールド、及び、本明細書に記載される他の基準を指定することができる。

ブロック５７０において、フォロワは、ニュースフィードにアクセスして、フィード追跡アップデートを閲覧する。一実施例において、ユーザは、このユーザがフォローしているレコードの全てに対する１つのニュースフィードのみを有する。別の実施例において、ユーザは、データベースシステムへのインタフェースのページ上で特定のタブ又は他のオブジェクトを選択することにより、自分のフィード（すなわち、自分のアクションについてのフィード）にアクセスすることができる。したがって、フィードは、他のユーザがデータベースシステムにおいて行っていることについてのフィード追跡アップデートを含み得る。ユーザが、別のユーザの関連するアクションを認識すると、そのユーザは、同僚に連絡を取ることができ、それにより、チームワークを高めることができる。

Ｖ．フィード追跡アップデートの生成
上述したように、いくつかの実施例は、レコードに関して発生したイベント（例えば、アップデート）、及び、ユーザによる、イベントをトリガするアクションを説明するテキストを生成することができる。データベースシステムは、様々な方法により、様々なイベントのためのフィード追跡アップデートを生成するよう構成され得る。

一実施例において、フィード追跡アップデートは文章（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（Ｍａｒｋ Ａｂｒａｍｏｗｉｔｚは、＄３．５Ｍである総額と、意思決定者であるＳａｍ Ｐａｌｍｉｓａｎｏと、を含む、ＩＢＭの２００００個のラップトップに関する新たな商談を作成した）」を考える。このイベントは、Ｍａｒｋ Ａｂｒａｍｏｗｉｔｚ用のプロフィールフィードと、ＩＢＭの２００００個のラップトップに関する商談のレコード用のエンティティフィールドと、にポストされ得る。パターンは、新たな(ObjectName)(RecordName) with [ (FieldName) as (FieldValue) [, / and] ]* [ [added / changed / removed] (RelatedListRecordName) [as / to / as] (RelatedListRecordValue) [, / and] ]*を作成した(AgentFullName)により与えられ得る。同様のパターンが、変更されたフィールド（標準又はカスタム）と、関連リストに追加された子レコードと、に関して形成され得る。

ＶＩ．ユーザからのコメント又はユーザについてのコメントの追跡
いくつかの実施例はまた、データベースシステムがフィード追跡アップデートを生成する代わりに、ユーザ送信テキストを有することができる。このテキストは、メッセージの一部又は全てとしてユーザにより送られるので、このテキストは任意のトピックに関するものであり得る。したがって、ユーザのアクション及びレコードのイベントのみよりも詳細な情報が伝えられ得る。一実施例において、メッセージを使用して、特定のレコードについて質問することができ、そのレコードをフォローしているユーザは、コメント及び応答を提供することができる。

図６は、いくつかの実施例に従って実行される、レコード又は別のユーザについてユーザにより作成されたメッセージからニュースフィードを作成するための方法６００の一例のフローチャートを示している。一実施例において、方法６００は、方法３００及び方法５００と組み合わせることができる。一態様において、第１のユーザがメッセージ（例えば、レコード又は別のユーザについてのポスト又はコメント）を作成した場合、このメッセージが、第１のユーザに関連付けられ得る。別の態様において、メッセージが第１のユーザについてのものである場合（例えば、別のユーザにより第１のユーザのプロフィールフィード上にポストされた場合）、このメッセージが、第１のユーザに関連付けられ得る。

ブロック６１０において、データベースシステムは、第１のユーザに関連付けられたメッセージ（例えば、ポスト又はステータスアップデート）を受信する。このメッセージ（例えば、ポスト又はステータスアップデート）は、別のユーザ又は第１のユーザにより送られたテキスト及び／又はマルチメディアコンテンツを含み得る。一実施例において、ポストは、任意のユーザがポストを追加でき複数のポストが存在し得る、第１のユーザのプロフィールページのセクションに対するものである。したがって、ポストは、第１のユーザのプロフィールページ上に現れ得、第１のユーザのプロフィールに訪れたときに閲覧され得る。レコードについてのメッセージの場合、ポストは、レコードの詳細ページ上に現れ得る。メッセージは、他のフィード内に現れてもよいことに留意されたい。別の実施例において、第１のユーザについてのステータスアップデートは、第１のユーザのみにより追加され得る。一実施例において、ユーザは、１つのステータスメッセージのみ有することができる。

ブロック６２０において、以下でより詳細に説明されるように、メッセージがテーブルに追加される。フィードが開かれるとき、クエリは、１以上のテーブルをフィルタリングして、第１のユーザを識別し、ユーザがフォローしている他の人を識別し、メッセージを取得する。メッセージ及びレコードアップデートは、フィードとして結合されたリスト内に提供される。このように、一実施例において、メッセージは、第１のユーザのプロフィールに（例えば関連リストとして）関連付けられている、第１のユーザのプロフィールフィードに追加され得る。一実施例において、ポストは無制限にリストされる。別の実施例において、直近のポスト（例えば、直近の５０個）のみが、プロフィールフィード内に保持される。このような実施例はまた、フィード追跡アップデートとともに使用されてもよい。さらに別の実施例において、メッセージは、このメッセージを追加したユーザのプロフィールに追加され得る。

ブロック６３０において、データベースシステムは、第１のユーザのフォロワを識別する。一実施例において、データベースシステムは、方法５００に関して上述したようにフォロワを識別することができる。様々な実施例において、フォロワは、第１のユーザのアクションに関するフィード、第１のユーザについてのメッセージに関するフィード、又はこれら両方に関するフィード（同一のフィードであることが可能）をフォローすることを選択することができる。

ブロック６４０において、メッセージが、各フォロワのニュースフィードに追加される。一実施例において、メッセージが何らかの基準に合致する場合、例えば、メッセージが特定のキーワード又は他の基準を含む場合、メッセージは、特定のフォロワのニュースフィードにのみ追加される。別の実施例において、メッセージは、このメッセージを作成したユーザにより削除され得る。一実施例において、メッセージが作成者により削除されると、このメッセージは、このメッセージが追加された全てのフィードから削除される。

ブロック６５０において、フォロワは、ニュースフィードにアクセスして、メッセージを閲覧する。例えば、フォロワは、フォロワ自身のプロフィールページ上でニュースフィードにアクセスすることができる。別の例として、フォロワは、最初にホームページに行く必要のない、フォロワ自身のデスクトップに送られたニュースフィードを有することができる。

ブロック６６０において、データベースシステムは、メッセージについてのコメントを受信する。データベースシステムは、元のメッセージが追加されたのと同様に、このコメントを同じ第１のユーザのフィードに追加することができる。一実施例において、コメントはまた、このコメントを追加した第２のユーザのフィードにも追加され得る。一実施例において、ユーザはまた、コメントに返信することもできる。別の実施例において、ユーザは、コメントをフィード追跡アップデートに追加することができ、さらなるコメントが、フィード追跡アップデートに関連付けられ得る。さらに別の実施例において、コメント又はメッセージを作成することは、フィード追跡アップデートが作成されるアクションではない。したがって、このメッセージは、そのようなアクションから作成される唯一のフィード項目であり得る。

一実施例において、フィード追跡アップデート又はポストが削除される場合、その対応するコメントも削除される。別の実施例において、フィード追跡アップデート又はポストに対する新たなコメントは、フィード追跡アップデートのタイムスタンプをアップデートしない。また、指定された時間枠内に（例えば、前週内に）コメントがあった場合、フィード追跡アップデート又はポストは、フィード（プロフィールフィード、レコードフィード、又はニュースフィード）内に表示され続けられ得る。そうでなければ、一実施例において、フィード追跡アップデート又はポストは削除され得る。

いくつかの実施例において、全ての又はほとんどのフィード追跡アップデートに対して、コメントすることができる。他の実施例において、所定のレコード（例えば、案件又はアイディア）のフィード追跡アップデートに対しては、コメントすることができない。様々な実施例において、商談、取引先、連絡先、リード、及びカスタムオブジェクトの任意の１以上のレコードに対して、コメントを作成することができる。

ブロック６７０において、コメントが、各フォロワのニュースフィードに追加される。一実施例において、ユーザは、このユーザのニュースフィード内でコメントを作成することができる。そのようなコメントは、適切なプロフィールフィード又はレコードフィードに伝播し得、次いで、フォローしているユーザのニュースフィードに伝播し得る。したがって、フィードは、人が行っていることに加えて、人が話していることも含み得る。一態様において、フィードは、（例えば、ユーザ、商談等について）最新であり続けるための手段であるとともに、同僚／パートナと連絡を取り合って、共通の目標に向かって同僚／パートナを引き込むための好機である。

いくつかの実施例において、ユーザは、フィード追跡アップデート及び／又はメッセージ（コメントを含む）をランク付けすることができる。ユーザは、より高くランク付けされたフィード項目がディスプレイのより上の方に現れるように、フィードの表示の優先順位を付けることを選択することができる。例えば、一実施例において、コメントが特定の質問に対する回答である場合、ユーザは、最良の回答が識別され得るように、様々なステータスポストをランク付けすることができる。別の例として、最も重要なフィード項目がリストの一番上に表示され得るので、ユーザは、最も重要なフィード項目を迅速に識別することができる。フィード項目の順番は、（いくつかは本明細書において説明される様々なファクタを用いてデータベースシステムにより決定され得る）重要度レベルと、ユーザからのレーティングと、に基づき得る。一実施例において、このレーティングは、少なくとも３つの値を含む。別の実施例において、このレーティングは、２値に基づく。

ユーザのプロフィールに加えて、グループも作成され得る。様々な実施例において、グループは、ユーザらに共通する所定の属性に基づいて作成されてもよいし、ユーザを招待することにより作成されてもよいし、且つ／あるいは、ユーザから参加のリクエストを受信することにより作成されてもよい。一実施例において、グループフィードが作成され得、誰かが適切なユーザインタフェースを介してグループ全体にメッセージを送ったときに、メッセージがグループフィードに追加される。例えば、グループページは、グループフィード、又はグループフィード内のポスト用のセクションを有することができ、ユーザは、「共有（Share）」ボタン又は同様のボタンをクリックすることにより、ユーザインタフェース内のパブリッシャコンポーネントを介してポストを送ることができる。別の実施例において、メンバのうちのいずれか１人についてのメッセージが送信されたとき、そのメッセージがグループフィードに追加され得る。また、グループフィードは、グループ全体のアクション（例えば、管理者が、グループプロフィール内のデータ又はグループにより所有されているレコードを変更すること）についてのフィード追跡アップデート、又は、個々のメンバのアクションについてのフィード追跡アップデートを含み得る。

図７は、いくつかの実施例に従った、グループページ上のグループフィードの一例を示している。図示されるように、フィード項目７１０は、ユーザが文書をグループオブジェクトにポストしたことを示している。テキスト「Bill Bauer has posted the document Competitive Insights（Ｂｉｌｌ Ｂａｕｅｒは、文書Ｃｏｍｐｅｔｉｔｉｖｅ Ｉｎｓｉｇｈｔｓをポストした）」は、変更されたレコードについてのフィード追跡アップデートと同様に、データベースシステムにより生成され得る。フィード項目７２０は、グループへのポストとともに、Ｅｌｌａ Ｊｏｈｎｓｏｎ、Ｊａｍｅｓ Ｓａｘｏｎ、Ｍａｒｙ Ｍｏｏｒｅ、及びＢｉｌｌ Ｂａｕｅｒからのコメント７３０を示している。

図８は、いくつかの実施例に従った、フィード追跡アップデート、ポスト、及びコメントを含むレコードフィードの一例を示している。フィード項目８１０は、承認のためにディスカウントを送ったというイベントに基づくフィード追跡アップデートを示している。他のフィード項目は、例えば、Ｂｉｌｌ Ｂａｕｅｒからの、レコードに対してなされたポストと、例えば、Ｅｒｉｃａ Ｌａｗ及びＪａｋｅ Ｒａｐｐからの、ポストに対してなされたコメントと、を示している。

ＶＩＩ．フィードのためのインフラストラクチャ
Ａ．フィードを作成するために使用されるテーブル
図９Ａは、いくつかの実施例に従ってイベントを追跡しフィードを作成する際に使用され得る複数のフィード追跡アップデートテーブルの例を示している。図９Ａのテーブルにおいて、フィード項目が作成される、あるいはフィード項目に対応する、データベースにおけるイベントを追跡することの一部として、エントリが追加され得る、あるいはエントリが潜在的に削除され得る。一実施例において、各テナントは、各テナントにより提供される基準に基づいて作成されるテーブルの独自のセットを有する。

イベント履歴テーブル９１０は、フィード項目が作成されるイベントのフィード追跡アップデートを提供することができる。一態様において、イベントは、追跡されているオブジェクトに対するものである。したがって、テーブル９１０は、フィードのためのフィード追跡アップデートを記憶及び変更することができ、この変更が維持され得る。様々な実施例において、イベント履歴テーブル９１０は、イベントＩＤ９１１の列、オブジェクトＩＤ９１２（親ＩＤとも呼ばれる）の列、及びクリエイテッドバイＩＤ（created by ID）９１３の列を有することができる。イベントＩＤ９１１は、特定のイベントを一意に識別することができ、１（又は、他の数字若しくは値）で始まり得る。

新たなイベントの各々は、順番にインクリメントされ得る新たなイベントＩＤを用いて時系列に追加され得る。オブジェクトＩＤ９１２は、どのレコード又はユーザのプロフィールが変更されているかを追跡するために使用され得る。例えば、オブジェクトＩＤは、フィールドが変更されたレコード又はフィードがポストを受け入れたユーザに対応し得る。クリエイテッドバイＩＤ９１３は、イベントをもたらすアクションを実行しているユーザ、例えば、フィールドを変更している、あるいは別のユーザのプロフィールにメッセージをポストしているユーザを追跡することができる。

一実施例において、イベントの名前もテーブル９１０に記憶され得る。一実施例において、テナントは、追跡されることが望まれるイベントを指定することができる。一実施例において、イベント履歴テーブル９１０は、変更されたフィールド（例えば、古い値及び新たな値）の名前を含み得る。別の実施例において、フィールドの名前、及び値は、別のテーブルに記憶される。イベントについての他の情報（例えば、フィード追跡アップデート、ポスト、ステータスアップデート、又はコメントのテキスト）は、イベント履歴テーブル９１０に記憶されてもよいし、これより説明される他のテーブルに記憶されてもよい。

フィールド変更テーブル９２０は、フィールドに対する変更のフィード追跡アップデートを提供することができる。テーブル９２０の列は、イベントＩＤ９２１（イベントＩＤ９１１に関連付けられる）、フィールドの古い値９２２、及びフィールドの新たな値９２３を含み得る。一実施例において、イベントが、２以上のフィールド値を変更する場合、変更されるフィールドごとにエントリが存在し得る。図示されるように、イベントＩＤ９２１は、イベントＥ３７について２つのエントリを有する。

コメントテーブル９３０は、例えば、ポストに対するコメント又はフィールド値の変更に対するコメントといった、イベントに関して作成されたコメントのフィード追跡アップデートを提供することができる。テーブル９３０の列は、イベントＩＤ９３１（イベントＩＤ９１１に関連付けられる）、コメントのテキストを記憶するコメント列９３２、及びコメントの時間／日付９３３を含み得る。一実施例において、各イベントに対して複数のコメントが存在し得る。図示されるように、イベントＩＤ９３１は、イベントＥ３７について２つのエントリを有する。

ユーザサブスクリプションテーブル９４０は、ユーザによりフォローされている（ユーザにサブスクライブされている）オブジェクトのリストを提供することができる。一実施例において、各エントリは、フォローしているユーザのユーザＩＤ９４１と、フォローされているオブジェクトに対応する１つのオブジェクトＩＤ９４２と、を有する。一実施例において、フォローされているオブジェクトは、レコード又はユーザであり得る。図示されるように、ＩＤ Ｕ８１９を有するユーザは、オブジェクトＩＤ Ｏ６１５及びオブジェクトＩＤ Ｏ４８９をフォローしている。ユーザＵ８１９が、他のオブジェクトをフォローしている場合、ユーザＵ８１９に関してさらなるエントリが存在し得る。さらに図示されるように、ユーザＵ７１９もオブジェクトＯ６１５をフォローしている。ユーザサブスクリプションテーブル９４０は、ユーザが、フォローされるオブジェクトを追加したとき、又は、ユーザが、フォローされているオブジェクトを削除したときに、アップデートされ得る。

一実施例において、プロフィールフィード及びニュースフィードに関して、これらは、これらのフィードタイプに合わせて特殊化された、イベント履歴テーブル９１０上の読み取り専用ビュー（real-only view）である。概念的には、ニュースフィードは、ユーザのための、ユーザサブスクリプションテーブル９４０のオブジェクトＩＤ９４２と、イベント履歴テーブル９１０のオブジェクトＩＤ９１２と、の間の半結合（semi-join）であり得る。一態様において、これらのエンティティは、多態的な親（polymorphic parent）を有し得、例えば、共用チェック（sharing check）のコストを制限するため等といった、本明細書で詳述される複数の制限を受け得る。

一実施例において、エンティティフィードは、エンティティ関連フィード（feed associate entity）（例えば、取引先フィード（AccountFeed）、案件フィード（CaseFeed）等）として、ＡＰＩにおいてモデル化される。エンティティ関連フィードは、１つの特定のレコードタイプのみのためのイベント（例えば、イベントＩＤ）から構成される情報を含む。このようなリストは、クエリ（及び、共用チェック）を特定のレコードタイプに制限し得る。一態様において、エンティティフィードをこのように構造化することにより、クエリをより速く実行させることができる。例えば、特定の取引先のフィードを求めるリクエストは、取引先のレコードタイプを含み得る。一実施例において、取引先レコードＩＤと、対応するイベントＩＤ、又は、イベント履歴テーブル９１０内の特定のイベントエントリに対するポインタと、を有する取引先フィードテーブルが、次いで検索され得る。取引先フィードテーブルは、レコードのうちの一部（全てではない）しか含まないので、クエリがより速く実行され得る。

一実施例において、レコードが追跡されているとしても、イベント履歴テーブル９１０内にリストされたイベントを有さないオブジェクトが存在することがある。この場合、データベースサービスは、フィード項目が存在しないことを示す結果を返すことができる。

フィード項目は、レコードの個々のフィールド変更、レコードの作成及び削除、又は、レコード若しくはユーザに関して追跡されている他のイベントを表すことができる。一実施例において、単一のトランザクション（イベント）におけるフィード項目の全てが、一緒にグループ化され得、同じイベントＩＤを有し得る。単一のトランザクションは、データベースとの１回の通信において実行され得るオペレーションに関連する。別の実施例において、フィードがデータベースのオブジェクトである場合、フィード項目は、プロフィールフィード、ニュースフィード、又はエンティティフィードの子であり得る。フィード項目が複数のフィードに追加される場合、そのフィード項目は、そのフィード項目が追加される各フィードの子として複製され得る。

いくつかの実施例において、コメントは、フィード追跡アップデート、ポスト、ステータスアップデート、及び他の項目に従属する項目として存在する。これらフィード追跡アップデート、ポスト、ステータスアップデート、及び他の項目は、互いから独立している。したがって、フィードコメントオブジェクトは、フィード項目オブジェクトの子オブジェクトとして存在し得る。例えば、コメントテーブル９３０は、イベント履歴テーブル９１０の子テーブルとみなすことができる。一実施例において、フィードコメントは、他のフィード項目から分離される、プロフィールフィード、ニュースフィード、又はエンティティフィードの子であり得る。

一実施例において、フィードを閲覧することは、直近のメッセージ又はフィード追跡アップデート（例えば、２５個）を引き出して（pull up）、各フィード項目についての直近の（例えば、４個の）コメントを検索する。コメントは、コメントテーブル９３０を介して識別され得る。一実施例において、ユーザは、例えば、「see more link（より多くのリンクを見る）」を選択することにより、より多くのコメントを見ることをリクエストすることができる。

フィード項目が生成された後、特定のテナント及び／又はユーザに合わせて調整され得る所定のフィード項目のみが表示されるように、フィード項目はフィルタリングされ得る。一実施例において、ユーザは、例えば、このユーザに対して直接的に表示されるニュースフィード、又は、さらにはエンティティフィードといった、このユーザに対して表示されるフィード内にフィード項目が現れるための所定の基準を満たす、フィールドに対する変更を指定することができる。一実施例において、この基準は、どのフィード項目を表示するかを決定するための他のファクタ（例えば、フィード内のフィード項目の数）と組み合わせられ得る。例えば、（例えば、閾値未満の）少数のフィード項目が存在する場合、これらフィード項目の全てが表示され得る。

一実施例において、ユーザは、自分のニュースフィード内のフィード項目に対するクエリを介して、この基準を指定することができる。したがって、フィードは、所定のタイプのオブジェクト、所定のタイプのイベント、所定のフィールドについてのフィード追跡アップデート、及び本明細書に記載される他の基準のみを返し得る。メッセージもまた、クエリにおいて指定され得る何らかの基準に従ってフィルタリングされ得る。そのような追加クエリが、ユーザのためのニュースフィードを作成するために使用される標準クエリに追加され得る。第１のユーザは、このように第１のユーザがフォローしているユーザ及びレコードを指定することができるのに加えて、第１のユーザがフォローしたいと望む特定のフィード項目を識別することができる。クエリは、グラフィカルインタフェースを介して作成され得る、あるいは、ユーザにより直接的にクエリ言語で追加され得る。他の基準は、他のフィード項目ではなく、特定のユーザ又はレコードを対象とするポストのみを受け取ることを含み得る。

一実施例において、ユーザは、このユーザがレコードにアクセスすることができる場合、このレコードのフィードにアクセスすることができる。ユーザがレコードにアクセスできるかどうかを判定するためのセキュリティルールが、様々な方法により実行され得る。それらの方法のうちのいくつかは、Weissmanらによる「METHODS AND SYSTEMS FOR CONTROLLING ACCESS TO CUSTOM OBJECTS IN A DATABASE」と題された２０１２年１月１０日に発行された同一出願人による米国特許第８０９５５３１号に記載されており、これは、その全体を参照することにより、全ての目的のために、本明細書に組み込まれる。

一実施例において、ユーザは、このユーザがレコードにアクセスすることができる場合、例えば、フィード項目を削除又は編集する等、このレコードのフィードを編集することができる。別の実施例において、（管理者に加えて）ユーザは、フィード項目が作成され得るアクションを実行することを除いて、フィード項目を編集することができない。一例において、ユーザは、まず、このユーザのアクションに基づいて作成されるべきフィード項目の特定のレコード及びフィールドにアクセスしなければならない。この場合、管理者は、MODIFY-ALL-DATAセキュリティレベル（全てのデータを変更するセキュリティレベル）を有するユーザであるとみなすことができる。さらに別の実施例において、レコードを作成したユーザは、フィードを編集することができる。

一実施例において、ポストのテキストは、イベント履歴テーブル９１０と相互参照され得る子テーブル（ポストテーブル９５０）に記憶される。ポストテーブル９５０は、（イベントＩＤ９１１と相互参照するための）イベントＩＤ９５１、ポストのテキストを記憶するためのポストテキスト９５２、及び時間／日付９５３を含み得る。ポストテーブル９５０内のエントリは、フィードポストオブジェクトとみなすことができる。

ＶＩＩＩ．フォローするユーザ及びレコードに対するサブスクライブ
上述したように、ユーザは、ユーザ、グループ、及びレコードをフォローすることができる。実施例は、ユーザが、このユーザが現在フォローしているどのユーザ、グループ、及びレコードを管理するための機構を提供することができる。一実施例において、ユーザは、このユーザがフォローできるユーザ及びレコードの数（集合的又は個別的）に制限され得る。例えば、ユーザは、１０人のユーザ及び１５個のレコードのみをフォローするよう制限され得る、あるいは、別の例として、計２５のみをフォローするよう制限され得る。代替的に、ユーザは、より多くのユーザ又はより少ないユーザをフォローすることが許可されてもよい。

一実施例において、ユーザは、レコードのページに行き、次いで、（例えば、「フォロー（follow）」又は「参加（join）」と記されたボタンにより、）オブジェクトをフォローすることを選択することができる。別の実施例において、ユーザは、レコードを検索して、合致するレコードをリスト内に表示させることができる。この検索は、ユーザがフォローしたいと望み得るレコードの基準を含み得る。このような基準は、所有者、作成日、最終コメント日、及び特定のフィールドの数値（例えば、１００００ドル以上の値を有する商談）を含み得る。

次いで、フォローボタン（又は、他のアクティベーションオブジェクト）が、結果として生じるリスト内の各レコードの横に提供され得、レコードをフォローすることを開始するために、フォローボタンが選択され得る。同様に、ユーザは、ユーザのプロフィールページに行き、ユーザをフォローすることを選択することができる、あるいは、ユーザの検索が、リストを提供し得、１人以上のユーザが、フォローするために、このリストから選択され得る。サブスクライブ及びサブスクライブ解除（unsubscribing）の選択は、テーブル９２０に行を追加しテーブル９２０から行を削除し得る。

いくつかの実施例において、サブスクリプションセンタ（subscription center）は、ユーザがサブスクライブしているどのレコードを管理し、フィード追跡アップデートにおいてユーザが閲覧したいと望むどのフィールドアップデートを管理するために、データベースアプリケーション（例えば、アプリケーションプラットフォーム１８）における中央環境（centralized place）として動作する。サブスクリプションセンタは、サブスクリプションテーブルを使用して、様々なユーザのサブスクリプションを追跡することができる。一実施例において、サブスクリプションセンタは、ユーザがサブスクライブされている全ての項目（ユーザ及びレコード）のリストを示す。別の実施例において、ユーザは、サブスクリプションセンタから、サブスクライブされているオブジェクトをサブスクライブ解除することができる。

Ａ．自動サブスクリプション
図９Ｂは、いくつかの実施例に従って実行される、ユーザをデータベースシステムにおけるオブジェクトに自動的にサブスクライブさせるための方法９００の一例のフローチャートを示している。以下のブロックのいずれも、データベースシステムを用いて全体的又は部分的に実行され、詳細には、データベースシステムの１以上のプロセッサにより実行され得る。

ブロック９０１において、データベースシステムに記憶されたオブジェクトの１以上の属性（property）が受信される。この属性は、データベースシステムの管理者から受信されてもよいし、データベースシステムのユーザ（顧客組織の管理者であり得る）から受信されてもよい。この属性は、レコード又はユーザであり得、データベースシステムに記憶されているオブジェクトのフィールドのうち任意のフィールドを含み得る。レコードの属性の例は、このレコードの所有者、このレコードを、あるレコードタイプから別のレコードタイプに変換したユーザ、第１のユーザがこのレコードを閲覧したかどうか、及び第１のユーザがこのレコードを閲覧した時間を含む。ユーザの属性の例は、このユーザがどの組織（テナント）に関連付けられているか、同じ組織における第２のユーザの地位、及びこのユーザがどの他のユーザに電子メールを送ったか、あるいはこのユーザがプロジェクトにおいてどの他のユーザと一緒に取り組んでいるかを含む。

ブロック９０２において、データベースシステムは、どのユーザがオブジェクトを自動的にフォローすべきかについての１以上の基準を受信する。この基準の例は、レコードの所有者又は作成者が、このレコードをフォローすること、レコードの所有者又は作成者の部下が、このレコードをフォローすること、及び、ユーザが、自分のマネージャ、このユーザの同僚、このユーザと同じビジネスグループにおける他のユーザ、及び、このユーザが電子メールを送った、あるいはこのユーザがプロジェクトにおいて一緒に取り組んでいる他のユーザをフォローすることを含み得る。この基準は、ユーザ又はユーザのグループ（例えば、テナントのユーザ）に固有であり得る。

ブロック９０３において、データベースシステムは、オブジェクトの１以上の属性が、第１のユーザに関して１以上の基準を満たすかどうかを判定する。一実施例において、この判定は、まず基準を取得し、次いでこの基準を満たすオブジェクトを判別することにより行われ得る。この判定は、定期的に行われてもよいし、オブジェクトの作成時に行われてもよいし、他の時間に行われてもよい。

ブロック９０４において、基準が満たされた場合、オブジェクトが第１のユーザに関連付けられる。この関連付けは、第１のユーザによりどのオブジェクトがフォローされているかに関する情報を記憶するリスト内に存在し得る。ユーザサブスクリプションテーブル９４０が、このようなリストの一例である。一実施例において、１以上の基準は、１つの属性が少なくとも１つの基準を満たす場合に満たされる。したがって、基準が、ユーザが自分のマネージャをフォローすることであり、オブジェクトが、ユーザのマネージャである場合、第１のユーザは、このオブジェクトをフォローするようになる。

一実施例において、ユーザはまた、例えば、所定のアクションが生じた場合に、自動的にサブスクライブ解除され得る。このアクションは、例えば、降格又は契約者（contractor）になることといった、組織内でのユーザの地位の変化であり得る。別の例として、案件がクローズした場合、この案件をフォローしているユーザは、自動的にサブスクライブ解除され得る。

ＩＸ．フィードへの項目の追加
上述したように、フィードは、フィード項目を含み、フィード項目は、本明細書で定義されるようなフィード追跡アップデート及びメッセージを含む。様々なフィードが生成され得る。例えば、フィードは、レコード又はユーザについて生成され得る。次いで、ユーザは、このようなフィードを閲覧することができる。ユーザは、例えば、レコード又はユーザ用のホームページに行くことにより、レコード又はユーザのフィードを別々に閲覧することができる。上述したように、ユーザはまた、別のレコード又はユーザをフォローして、別々のフィードアプリケーションを通じて、このようなフィードのフィード項目を受け取ることもできる。フィードアプリケーションは、ユーザがフォローしているフィードの各々を提供することができ、いくつかの例においては、単一の情報フィード内に様々なフィードを結合することができる。

フィードジェネレータは、フィード項目（例えば、フィード追跡アップデート又はメッセージ）を生成してこのようなフィード項目をフィードに結合することができる、プロセッサ若しくは専用プロセッサ（又は、これらの組合せ）上で実行される任意のソフトウェアプログラムを指し得る。一実施例において、フィードジェネレータは、フィード追跡アップデート又はメッセージを受信し、フィード項目がどのフィードに追加されるべきであるかを識別し、フィードを追加することにより、フィード項目を生成することができる。フィードを追加することは、さらなる情報（メタデータ）をフィード追跡アップデート又はメッセージに追加すること（例えば、文書、メッセージの送信者、決定された重要度等を追加すること）を含み得る。フィードジェネレータはまた、人が（例えば、共用ルールに従って）閲覧するためにアクセスしないデータについてフィード追跡アップデートを誰も閲覧しないことを確認することをチェックすることができる。フィードジェネレータは、フィードを事前算出するために、フィードを動的に算出するために、あるいはこれらの組合せのために、様々な時間において実行され得る。

一実施例において、図４におけるプロセッサ４１７は、フィード追跡アップデートのための基準を満たすイベントを識別し、次いで、フィード追跡アップデートを生成することができる。プロセッサ４１７はまた、メッセージを識別することもできる。例えば、アプリケーションインタフェースは、メッセージを送信するための所定の機構（例えば、プロフィールページ上の「送信」ボタン、レコードの詳細ページ上の「送信」ボタン、ポスト上の「コメント」ボタン）を有することができ、これらの機構は、フィードを作成するために使用されるテーブルに追加されるべきメッセージ又は表示の準備ができているフィード項目のリストに直接追加されるべきメッセージを識別するために使用され得る。

Ａ．事前算出されているフィードへの項目の追加
いくつかの実施例において、フィード項目のフィードは、ユーザがこのフィードをリクエストする前に作成される。そのような実施例は、高速で動作し得るが、記憶のために高い全般的コストを有する。一実施例において、プロフィールフィード又はレコードフィードが作成されると、フィード項目（メッセージ及びフィード追跡アップデート）が、このようなフィードに追加され得る。このようなフィードは、データベースシステムにおいて、関連リスト等、様々な形で存在し得る。このようなフィードは、項目を追加することに加えて項目を除去するための機構を含み得る。

上述したように、ニュースフィードは、ユーザがサブスクライブしている全てのレコードフィード及びプロフィールフィードの集約フィードであり得る。ニュースフィードは、サブスクライブしているユーザのホームページ上に提供され得る。したがって、ニュースフィードは、特定のユーザにより作成され、特定のユーザのために存在し得る。例えば、ユーザは、このユーザが関心のある所定のレコードのエンティティフィードを受け取り、関心のある人（例えば、このユーザのために働く同じチームの人はこのユーザの上司である、等）のプロフィールフィードを受け取るようサブスクライブすることができる。ニュースフィードは、（上述した）サブスクリプションセンタを介して明示的（又は暗黙的）にサブスクライブされているユーザに、全てのレコード（及び人）にわたる全てのアクションについて通知することができる。

一実施例において、フィード追跡アップデートが、ユーザがサブスクライブされている複数のエンティティにおいて公開される場合であっても、各フィード追跡アップデートの１つのインスタンスのみが、ユーザのニュースフィード上に表示される。一態様において、ニュース記事を公開する際に遅延が存在し得る。例えば、遅延は、非同期のエンティティフィード追跡アップデートの持続のためにキューされた（queued up）メッセージに起因するものであり得る。異なるフィードは、異なる遅延を有し得る（例えば、ニュースフィードの遅延はあるが、プロフィールフィード及びエンティティフィードには遅延がない）。別の実施例において、サブスクライブされているプロフィールフィード又はエンティティフィードに関する所定のフィード追跡アップデートは、ユーザが、例えば、（どのユーザがどのデータを閲覧できるかを制限する）共用ルールのために、アクセスを許可されていなので、表示されない。また、一実施例において、アップデートされたレコード（作成を含む）のデータが、フィード内に提供され得る（例えば、フィードのアップデータされた値又はファイルが、フラッシュ表現として追加され得る）。

Ｂ．フィードの動的な生成
いくつかの実施例において、フィードジェネレータは、ユーザが、例えば、プロフィールフィード、エンティティフィード、又はユーザのニュースフィードといった特定のフィードを閲覧することをリクエストしたときにフィード項目を動的に生成することができる。一実施例において、直近のフィード項目（例えば、トップ５０）が最初に生成される。一態様において、他のフィード項目が、例えば、フィードを閲覧するリクエストとは同調しないバックグラウンドプロセスとして生成され得る。しかしながら、バックグラウンドプロセスは、ユーザが次の５０個のフィード項目に到達する前に完了する可能性が高いので、このフィード生成は同調的と思われるかもしれない。別の態様において、直近のフィード項目は、例えば、フィード追跡アップデート又はポストに関連付けられているコメントを含む場合もあるし含まない場合もある。

一実施例において、フィードジェネレータは、表示されるフィード項目を生成するために、図９Ａに示されるテーブル及び／又は必要に応じて他のテーブルの適切なサブセットをクエリすることができる。例えば、フィードジェネレータは、特定のレコードについて生じたアップデートのために、イベント履歴テーブル９１０をクエリすることができる。特定のレコードのＩＤが、レコードのＩＤに対して照合され得る。一実施例において、レコードの全セットに対する変更は、１つのテーブルに記憶され得る。フィードジェネレータはまた、ステータスアップデート、ポスト、及びコメントのためにもクエリすることができ、これらステータスアップデート、ポスト、及びコメントの各々は、図９Ａに示されるように、レコードの異なる部分又は別個のテーブルに記憶され得る。エンティティイベント履歴テーブルに何を記録させるか（及び、何が表示されるか）は、セットアップにおけるフィード設定ページにより制御され得、これは、管理者により設定可能であり得、カスタムフィードに関して上述されている組織全体についても同じであり得る。

一実施例において、２つのフィードジェネレータが存在し得る。例えば、１つのフィードジェネレータは、レコードフィード及びプロフィールフィードを生成することができ、別のフィードジェネレータは、ニュースフィードを生成することができる。前者に関して、フィードジェネレータは、レコード又はユーザプロフィールの識別子をクエリすることができる。後者に関して、ニュースフィードジェネレータは、例えば、ユーザサブスクリプションテーブル９４０等、サブスクライブされているプロフィールフィード及びレコードフィードをクエリすることができる。一実施例において、フィードジェネレータは、人のサブスクリプションセンタを調べて、クエリするフィードを判別し、フィード項目のリストをユーザに返す。例えば、フィールド名若しくはＩＤ、コメントＩＤ、又は他の情報等、それぞれのテーブルのイベント番号及び値を調べることにより、このリストから重複が除去され得る。

Ｃ．フィード追跡アップデートテーブルへの情報の追加
図１０は、いくつかの実施例に従って実行される、情報をフィード追跡テーブルに記録するための方法１０００の一例のフローチャートを示している。一実施例において、ブロックのいくつかは、特定のイベント又はイベントの一部（例えば、アップデートの１つのフィールドのみが追跡されている）が追跡されているかどうかにかかわらず実行され得る。様々な実施例において、（ハードワイヤードの、又はプログラムされた）プロセッサ又はプロセッサのセットは、方法１０００と、本明細書で説明される任意の他の方法と、を実行することができる。

ブロック１０１０において、イベントを示すデータが受信される。このデータは、このイベントを識別する特定の識別子を有し得る。例えば、フィールドアップデートのための特定の識別子が存在し得る。別の実施例において、トランザクションが、このイベントを識別するキーワード（例えば、クローズ、フィールド変更、又は作成オペレーションを示すクエリ内の語）を探すために調べられ得る。

ブロック１０２０において、フィード追跡アップデートテーブルに含めるためにこのイベントが追跡されているかどうかが判定される。何が追跡されているかのこの判定は、上述したように、テナントの設定に基づき得る。一態様において、このイベントは、このイベントの行為者（イベントを実行する人）と、このイベントのオブジェクト（例えば、変更されているレコード又はユーザプロフィール）と、を有する。

ブロック１０３０において、このイベントが、イベント履歴テーブル（例えば、テーブル９１０）に書き込まれる。一実施例において、このフィード追跡オペレーションは、レコードをアップデートするための記録オペレーションを実行する同じトランザクションにおいて実行され得る。別の実施例において、トランザクションは、少なくとも２つのラウンドトリップデータベースオペレーションを含み、１つのラウンドトリップは、データベース記録（書き込み）であり、第２のデータベースオペレーションは、フィード追跡アップデートテーブルへのアップデートの記録である。一実施例において、イベント履歴テーブルは時系列である。別の実施例において、ユーザＡが、ユーザＢのプロフィール上にポストする場合、ユーザＡは「クリエイテッドバイ」９１３下にあり、ユーザＢはオブジェクトＩＤ９１２下にある。

ブロック１０４０において、フィールド変更テーブル（例えば、フィールド変更テーブル９２０）が、イベント識別子と、アップデートにおいて変更されたフィールドと、を有するエントリを用いてアップデートされ得る。一実施例において、フィールド変更テーブルは、イベント履歴テーブルの子テーブルである。このテーブルは、変更されるフィールドの各々についての情報を含み得る。例えば、口座レコードの名前及び残高を変更するイベントに関して、エントリは、イベント識別子と、古い名前及び新たな名前と、古い残高及び新たな残高と、を有することができる。代替的に、各フィールド変更は、同じイベント識別子を有する異なる行に存在してもよい。フィールド名又はＩＤはまた、値がどのフィールドに関連するかを判定するために含まれ得る。

ブロック１０５０において、このイベントがポストである場合、ポストテーブル（例えば、ポストテーブル９５０）が、イベント識別子とポストのテキストとを有するエントリを用いてアップデートされ得る。一実施例において、フィールド変更テーブルは、イベント履歴テーブルの子テーブルである。別の実施例において、このテキストは、トランザクション（例えば、クエリコマンド）において識別され、分離され、適切な列においてエントリに入れられ得る。本明細書で説明される様々なテーブルは、様々な形で組み合わされてもよいし、分離されてもよい。例えば、ポストテーブル及びフィールド変更テーブルは、同じテーブルの一部であってもよいし、別のテーブルであってもよいし、データのオーバーラップする部分を含んでもよい。

ブロック１０６０において、イベントについてのコメントが受信され、コメントが、コメントテーブル（例えば、コメントテーブル９３０）に追加される。コメントは、ポストに対するもの、又は、表示されるフィード追跡アップデートが生成され得るレコードのアップデートに対するものであり得る。一実施例において、テキストが、トランザクション（例えば、クエリコマンド）において識別され、分離され、適切な列においてエントリに入れられ得る。

Ｄ．フィード追跡アップデートテーブルからの情報の読み出し
図１１は、いくつかの実施例に従って実行される、表示されるフィードを生成することの一部としてフィード項目を読み出すための方法１１００の一例のフローチャートを示している。一実施例において、フィード項目は、レコードのためのフィードを作成することの一部として読み出され得る。

ブロック１１１０において、特定のレコードに関連するイベントのための、イベント履歴テーブル（例えば、イベント履歴テーブル９１０）に対するクエリが受信される。一実施例において、このクエリは、フィードがリクエストされているレコードの識別子を含む。様々な実施例において、クエリは、レコードの詳細ページ、レコードフィードをリクエストしているユーザのホームページ、又は（例えば、検索又はブラウジングから取得された）様々なレコードのリストから開始され得る。

ブロック１１２０において、ユーザがレコードフィードを閲覧できるかどうかを判定するために、ユーザのセキュリティレベルがチェックされ得る。通常、ユーザがレコードにアクセスできる場合、このユーザはレコードフィードを閲覧することができる。このセキュリティチェックは、様々な方法により実行され得る。一実施例において、ユーザがクラシフィケーション（classification）（例えば、ユーザが所与のタイプのレコードを閲覧することを許可するセキュリティレベル）を有するかどうかを確認するために、第１のテーブルがチェックされる。別の実施例において、ユーザが特定のレコードを閲覧することを許可されているかどうかを確認するために、第２のテーブルがチェックされる。第１のテーブルは第２のテーブルの前にチェックされ得、両テーブルは同じテーブルの異なるセクションであり得る。ユーザが、レコードの詳細ページからフィードをリクエストした場合、一実施例は、レコードのためのセキュリティレベルチェックをスキップすることができる。なぜならば、このチェックは、ユーザが詳細ページを閲覧することをリクエストしたときにすでに行われているからである。

一実施例において、セキュリティチェックは、レコードフィードを閲覧する各リクエストに対して判定される。したがって、フィード項目がユーザに対して表示されるか否かは、例えば、ユーザが、レコードのフィード又はこのユーザがフォローしている全てのオブジェクトのニュースフィードを閲覧することをリクエストしたときのアクセス権に基づいて判定される。このように、ユーザのセキュリティが変化する場合、フィードは、変化されたときのユーザのセキュリティレベルに自動的に適応する。別の実施例において、フィードは、リクエストされる前に算出され得、ユーザがフィード項目を閲覧するためのアクセス権をなお有しているかどうかを判定するために、次いでセキュリティチェックがなされ得る。このセキュリティ（アクセス）チェックは、レコードレベルであるとともにフィールドレベルであり得る。

ブロック１１３０において、ユーザがレコードにアクセスできる場合、ユーザが特定のフィールドを閲覧できるかどうかを判定するために、フィールドレベルセキュリティテーブルがチェックされ得る。一実施例において、このようなフィールドだけがユーザに対して表示される。あるいは、ユーザがアクセスできるこのようなフィールドのサブセットが表示される。フィールドレベルセキュリティチェックは、レコードレベルチェックと同時に、且つさらにはレコードレベルチェックと同じオペレーションを用いて、オプションで実行され得るものである。加えて、レコードタイプチェックも、このときに実行されてもよい。ユーザが所定のフィールドのみ閲覧できる場合、（例えば、フィールド変更テーブル９２０から決定された、）このようなフィールドに関連する任意のフィード項目が、表示されるフィードから除去され得る。

ブロック１１４０において、ユーザがアクセスできるフィード項目が表示される。一実施例において、予め定められた数（例えば、２０個）のフィード項目が一度に表示される。この方法は、読むことが可能であると分かっている最初の２０個のフィード項目を表示して、次いで、ユーザがこの最初の２０個を閲覧している間に他のフィード項目を決定することができる。別の実施例において、ユーザが、例えば、「see more link（より多くのリンクを見る）」を作動させることにより、他のフィード項目を閲覧することをリクエストするまで、他のフィード項目は決定されない。

図１２は、いくつかの実施例に従って実行される、表示されるプロフィールフィードのフィード項目を読み出すための方法１２００の一例のフローチャートを示している。一実施例において、クエリは、リクエストされているユーザプロフィールフィードの識別子を含む。所定のブロックはオプションであり得、これは、本明細書で説明される他の方法についても同様である。例えば、セキュリティチェックは実行されてなくてもよい。

ブロック１２１０において、イベント（例えば、取引先の作成）の行為者として第１のユーザを有するイベント又はイベント（例えば、ユーザのプロフィールへのポスト）が生じたイベントのためのクエリが、イベント履歴テーブル（例えば、イベント履歴テーブル９１０）に向けられる。様々な実施例において、クエリは、ユーザのプロフィールページから、プロフィールフィードをリクエストしているユーザのホームページから（例えば、フォローされているユーザのリストから）、又は（例えば、検索又はブラウジングから取得された）様々なユーザのリストから、第２のユーザにより開始され得る。イベントの態様を判別してテーブルから情報を取得するための様々な機構は、本明細書で説明される方法のいずれに対しても同じものであり得る。

ブロック１２２０において、第２のユーザが第１のユーザのプロフィールを閲覧できるかどうかについて、セキュリティチェックが実行され得る。一実施例において、いかなるユーザも、同じテナントの別のユーザのプロフィールを閲覧することができ、ブロック１２２０はオプションである。

ブロック１２３０において、フィード追跡アップデートのためのセキュリティ（アクセス）チェックが、レコードタイプ、レコード、及び／又はフィールドに基づいて実行され得、メッセージのためのセキュリティチェックも同様に実行され得る。一実施例において、人がアップデートしたレコードに関連するフィード追跡アップデートだけが、セキュリティチェックを要するものである。というのは、ユーザについてのフィード項目は、同じテナントの任意のユーザにより読むことが可能だからである。他のテナントのユーザは、ナビゲート可能（navigable）でなく、したがって、セキュリティが、テナントレベルで実施され得る。別の実施例において、第２のユーザがアクセスできないレコード又はフィールドへのリンク又はキーワードを探すために、メッセージがチェックされ得る。

ユーザは、異なるセキュリティクラシフィケーションを有し得るので、低レベルのセキュリティを有するユーザが、高レベルのセキュリティを有するユーザにより行われたレコードに対する変更を閲覧できないことは重要である。一実施例において、各フィード項目がチェックされ、次いで閲覧可能な結果が表示され得るが、これは非効率的であり得る。例えば、このようなセキュリティチェックは、長い時間を要し得るものであり、第２のユーザは、いくつかの結果をより早く得たいと望み得る。以下のブロックは、多数のフィード項目を有する第１のユーザに関してセキュリティがどのようにチェックされ得るかの一実施例を示すが、第２のユーザは、そのようなフィード項目のほとんどを閲覧できない。この実施例は、全ての状況に対して使用され得るが、上記の状況において有効であり得る。

ブロック１２３１において、（例えば、イベント識別子から判別できる、直近から始まる）予め定められた数のエントリが、イベント履歴テーブルから取得される。取得されたエントリは、まさにクエリのユーザＩＤと合致するエントリであり得る。一実施例において、ユーザ及びレコードに関連付けられているエントリ（すなわち、ユーザアカウントに対するポストではない）を見つけるために、エントリがチェックされる。別の実施例において、ユーザに関連付けられたこのようなエントリが、閲覧されることを許可される。なぜならば、例えば、第２のユーザは、ブロック１２２０において判定されたように、第１のユーザのプロフィールを閲覧することができるからである。

ブロック１２３２において、レコード識別子が、タイプ別に編成され、第２のユーザがレコードタイプを閲覧できるかどうかについて、このタイプがチェックされる。レコードが（例えば、所有者により）手動で共有されたかどうか等の他のチェックが実行されてもよい。一実施例において、様々なタイプのためのクエリが、並行して行われ得る。

ブロック１２３３において、ユーザがレコードタイプを閲覧できる場合、チェックが、特定のレコードについて実行され得る。一実施例において、ユーザがあるレコードタイプを閲覧できる場合、このユーザは、このタイプのレコードの全てを閲覧することができるので、このブロックはスキップされ得る。別の実施例において、共用モデルは、第２のユーザより下のユーザ（例えば、第２のユーザはマネージャである）がレコードを閲覧できるかどうかを考慮に入れることができる。そのような実施例において、第２のユーザは、そのようなレコードを閲覧することができる。一実施例において、ユーザが特定のレコードを閲覧できない場合、そのレコードに対するコメントも閲覧できない。

ブロック１２３４において、フィールドレベル共用ルールを使用して、第２のユーザが、アップデートについての情報、すなわち、所定のフィールドの値を閲覧できるかどうかを判定することができる。一実施例において、特定のフィールド名への参照がなされるかどうかを判定するために、メッセージが解析され得る。特定のフィールド名への参照がなされる場合には、フィールドレベルセキュリティがメッセージに適用され得る。

ブロック１２３５において、終了基準（stopping criterion）が満たされるまで、ブロック１２３１〜ブロック１２３４が繰り返される。一実施例において、終了基準は、閲覧可能な最大数（例えば、１００個）のエントリが識別されたときであり得る。別の実施例において、終了基準は、エントリが閲覧可能であるか否かにかかわらず、エンティティフィード追跡アップデートテーブルからの最大数（例えば、５００個）のエントリが解析されたことであり得る。

一実施例において、ニュースフィードが、例えば上述したように、プロフィールフィードとエンティティフィードとの組合せとして生成され得る。一実施例において、ブロック１１１０及びブロック１２１０におけるクエリに関するレコード及びユーザプロフィールのリストが、ユーザサブスクリプションテーブル９４０から取得され得る。一実施例において、フォローされ得るオブジェクトの最大数が存在する。

Ｅ．フィードのための項目の部分的事前算出
図１３は、いくつかの実施例に従って実行される、フィード内に表示するためのフィード項目を効率的に生成するためにイベント情報を記憶する方法１３００の一例のフローチャートを示している。様々な実施例において、方法１３００は、イベントがイベント履歴テーブルに書き込まれるたびに、あるいは何らかの他の基準に基づいて定期的に（例えば、１分おきに、５つのアップデートがなされた後に、等）、実行され得る。

ブロック１３１０において、イベントを示すデータが受信される。このデータは、ブロック１０１０に関して上述したものと同じであり得、ブロック１０１０に関して上述したのと同じ方法で識別され得る。このイベントは、イベント履歴テーブル（例えば、テーブル９１０）に書き込まれ得る。

ブロック１３２０において、このイベントに関連付けられた１以上のオブジェクトが識別される。様々な実施例において、オブジェクトは、レコードが変更されている、ユーザがレコードを変更している、ユーザがメッセージをポストしている、メッセージがユーザのプロフィールにポストされている等の様々な基準に従うことにより識別され得る。

ブロック１３３０において、このイベントをフォローしているユーザが判別される。一実施例において、このイベントに関連付けられている１以上のオブジェクトを使用して、このイベントをフォローしているユーザを判別する。一実施例において、サブスクリプションテーブル（例えば、テーブル９４０）を使用して、識別されるオブジェクトを見つけることができる。識別されたオブジェクトのエントリは、このオブジェクトをフォローしているユーザの各々の識別子（例えば、ユーザＩＤ９４１）を含み得る。

ブロック１３４０において、このイベントと、例えば（レコードアップデートの）レコード又は（ユーザにより生成されたポストの）ポストしたユーザといったこのイベントのソースと、が、イベント識別子とともに、ニュースフィードテーブルに書き込まれる。一実施例において、このような情報は、別個のエントリとして、イベントＩＤとともにニュースフィードテーブルに追加される。別の実施例において、ユーザのためのイベントの各々は、このユーザの行に関して、新たな列として追加される。さらに別の実施例において、より多くの列（例えば、他のテーブルからの列）が追加されてもよい。

ニュースフィードテーブル９６０は、ユーザＩＤ９６１と、イベントＩＤ又はポインタ９６２と、を有するそのようなテーブルの一例を示している。このテーブルは、任意の形で編成され得る。イベント履歴テーブル９１０との１つの差異は、ニュースフィードテーブル９６０においては、１つのイベントが複数のエントリ（サブスクライバごとに１つ）を有し得ることである。一実施例において、同じユーザのためのエントリの全ては、例えば示されるように、一緒にグループ化される。ユーザＵ８１９は、イベントＥ３７及びイベントＥ９０をフォローしているものとして示されており、したがって、これらのイベントから生じる個々のフィード項目のいずれもフォローしている。別の実施例において、任意の新たなエントリは、このテーブルの最後に追加される。したがって、新たなイベントのフォロワの全てが、グループとして追加され得る。そのような実施例において、イベントＩＤは、一般に、このテーブル内で一緒にグループ化される。もちろん、このテーブルは、任意の適切な方法でソートされてもよい。

一実施例において、ユーザの数が少ない場合、このようなテーブルのうちの１以上におけるフィード項目は、同じライトトランザクションの一部として書き込まれ得る。一実施例において、少ないことの判定は、イベントに関して実行されたアップデートの数（例えば、最大数のアップデートオペレーションが許容され得る）に依存し、より多くのオペレーションが実行される場合、フィード項目の追加が行われる。一態様において、オペレーションの数は、（アップデートイベントに依存する）レコードの行と、フォロワの数に依存し得るフィード追跡アップデートテーブルの行と、を含む、アップデートされる行の数によりカウントされ得る。別の実施例において、ユーザの数が多い場合、フィード項目の残りは、バッチにより作成され得る。一実施例において、フィード項目は、異なるトランザクションの一部として、すなわち、バッチジョブにより、書き込まれる。

一実施例において、エントリがニュースフィードテーブル９６０に追加される前に、セキュリティチェックが実行され得る。このように、セキュリティチェックは、バッチジョブ中に実行され得るものであり、ニュースフィードをリクエストしたときに実行される必要はない。一実施例において、イベントが解析され得、このイベントのフィード項目へのアクセスが許可されない場合、エントリは追加されない。一態様において、同じユーザのための複数のフィード項目は、同じイベントから生じなくてもよく（例えば、イベントがテーブル９１０内でどのように定義されているかにより）、したがって、ユーザが閲覧できるべきであるフィード項目をユーザが見逃す心配はない。

ブロック１３５０において、ニュースフィードを求めるリクエストが、ユーザから受信される。一実施例において、このリクエストは、ユーザがこのユーザのホームページに移動したときに得られる。別の実施例において、ユーザは、このリクエストを送信させるテーブル、リンク、又は他のページ項目を選択する。

ブロック１３６０において、ニュースフィードの表示可能なフィード項目を提供するために、ニュースフィードテーブル及び他のテーブルがアクセスされる。次いで、ニュースフィードが表示され得る。一実施例において、フィード項目を決定するために、ニュースフィードテーブルが、イベント履歴テーブルと結合され得る。例えば、特定のユーザＩＤを有するエントリを探すために、ニュースフィードテーブル９６０が検索され得る。このようなエントリを使用して、イベント履歴テーブル９１０内のイベントエントリを識別することができ、任意の子テーブルからの適切な情報を取得することができる。次いで、フィード項目（例えば、フィード追跡アップデート及びメッセージ）が、表示のために生成され得る。

一実施例において、直近のフィード項目（例えば、直近１００個）がまず決定される。次いで、他のフィード項目が、バッチプロセスにおいて決定され得る。したがって、ユーザが閲覧する最も可能性が高いフィード項目が最初に現れ得、ユーザは、他のフィード項目がバッチで処理されていることを認識しなくてよい。一実施例において、直近のフィード項目は、イベント識別子により判別され得る。別の実施例において、最高重要度レベルを有するフィード項目が最初に表示されてもよい。最高重要度は、誰がフィード項目をポストしたか、フィード項目がどれくらい新しいか、フィード項目が他のフィード項目にどれくらい関連するか等の１以上の基準により決定される。

一実施例において、ユーザサブスクリプションテーブル９４０を使用してニュースフィードを動的に作成する場合、クエリは、サブスクリプションテーブルを検索し、次いで、オブジェクトＩＤを使用してイベント履歴テーブルを検索する（ユーザがフォローしているオブジェクトごとに１回の検索）。したがって、ニュースフィードのためのクエリは、ユーザがサブスクライブしていたオブジェクトの数に比例し得る。ニュースフィードテーブルは、関連するイベントが既知であるように、オブジェクトＩＤを判別する中間ブロックがより早い段階で実行されることを可能にする。したがって、フィードの決定は、フォローされているオブジェクトの数にもはや比例しない。

いくつかの実施例において、ニュースフィードテーブルは、ユーザによりフォローされているイベントごとに、イベント履歴テーブルに対するポインタ（イベント識別子ではない）を含み得る。このように、イベントエントリは、イベント履歴テーブルに対して検索を実行する必要なく、即座に取得され得る。このときにセキュリティチェックが実行され得、フィード追跡アップデートのテキストが生成され得る。

Ｘ．フィードの表示
フィードは、メッセージ及びフィード追跡アップデートを含み、データベースシステムとのアプリケーションインタフェース内の多くの場所に現れ得る。一実施例において、フィードは、フィードが表示されているページのコンテキストにスコープされ得る。例えば、フィード追跡アップデートがどのように提示されるかは、どのページでフィード追跡アップデートが表示されるか（例えば、レコードの詳細ページ上のニュースフィード内、及び、さらにはユーザが特定のページにおいてどのように終了したか）に応じて変わり得る。別の実施例において、限定された数（例えば５０個）のフィード項目のみが表示される。一実施例において、特に表示されるフィード追跡アップデート又はメッセージの数に対する制限が存在し得る。代替的に、この制限は、特定のタイプのフィード追跡アップデート又はメッセージに適用されてもよい。例えば、フィールドの直近の変更（例えば、直近５個）のみが表示されてもよい。また、変更が表示されるフィールドの数が制限されてもよい。このような制限は、プロフィールフィード及びニュースフィードについても適用され得る。一実施例において、フィード項目は、例えば、以下で説明されるように、表示される前に、所定のフィルタリング基準の対象となり得る。

ＸＩ．フィードのフィルタリング及び検索
ユーザは、多くのユーザ及びレコードにサブスクライブすることが可能であり得るが、これは、ユーザのニュースフィードを非常に長くさせ、多くのフィード項目を含ませる。そのような例において、ユーザが全てのフィード項目を読むことは困難であり得、したがって、いくつかの重要なフィード項目又は関心のあるフィード項目は、読まれないことがある。いくつかの実施例において、フィルタを使用して、どのフィード項目がフィードに追加されるか、あるいはどのフィード項目がフィード内に表示されるかを決定することができる。

図１４は、いくつかの実施例に従って実行される、フィルタリング基準を用いて、データベースシステムのユーザのためのカスタムフィードを作成するための方法１４００の一例のフローチャートを示している。以下のブロックのいずれも、データベースシステムを用いて全体的又は部分的に実行され、詳細には、データベースシステムの１以上のプロセッサにより実行され得る。

ブロック１４１０において、どのフィード項目が第１のユーザに対して表示されるべきであるかを指定する１以上の基準が、テナントから受信される。一実施例において、基準は、どの項目をカスタムフィードに追加するかを指定する。例えば、基準は、レコードの所定のフィールドのためのフィード項目、所定のキーワードを含むメッセージ、及び本明細書に記載される他の基準のみを含むよう指定し得る。別の実施例において、基準は、どの項目をカスタムフィードから除去するかを指定する。例えば、基準は、所定のフィールドについてのフィード項目又は所定のキーワードを含むものを含まないよう指定し得る。

ブロック１４２０において、データベースシステムは、基準に合致する、１以上の選択されたオブジェクトのフィード項目を識別する。このフィード項目は、例えば、図９Ａのテーブルのうちの１以上といったデータベースに記憶され得る。一実施例において、１以上の選択されたオブジェクトは、第１のユーザがフォローしているオブジェクトである。別の実施例において、１以上の選択されたオブジェクトは、第１のユーザがリクエストしているレコードフィードの１つのレコードである。

ブロック１４３０において、基準に合致するフィード項目が、カスタムフィード内で、第１のユーザに対して表示される。フィード追跡アップデートのテキストは、フィード項目（例えば、フィールド変更のデータ）の識別後であって、フィード項目の最終バージョンの表示前に、生成され得る。

一実施例において、基準は、フィード項目が作成される前に受信される。別の実施例において、基準は、第１のユーザから受信される。一態様において、基準は、第１のユーザに対して表示するフィードを決定するために使用されるだけである。さらに別の実施例において、基準は、第１のテナントから受信され、第１のテナントの全てのユーザに適用される。また、一実施例において、複数の基準が指定される場合、１つの基準が満たされるならば、これらの基準は、フィード項目に関して満たされ得る。

いくつかの実施例は、関心のあるフィード項目を検索するための機構を提供することができる。例えば、フィード項目は、例えば、ユーザにより入力されるキーワードにより検索され得る。別の例として、タブ（又は、他の選択デバイス）は、特定のユーザについてのフィード項目又は特定のユーザからのフィード項目を表示することができる。一実施例において、特定のユーザからのメッセージ（又は、さらにはコメント）のみが選択され得る。基準に合致するフィード項目を検索することに加えて、ユーザは、特定のフィード項目を検索することもできる。

ＸＩＩ．パブリッシャ及び情報フィードを介した複数のレコードとのインタラクション
図１５は、いくつかの実施例に従って実行される、オンラインソーシャルネットワークにおいて単一のユーザインタフェースから１以上のレコードとインタラクトするための、コンピュータにより実施される方法１５００の一例のフローチャートを示している。図１５は、図１９〜図３０を参照して説明され得る。ブロック１５０４において、１つのコンピューティングデバイス、又は、方法１５００を実行するために協働する任意の数のコンピューティングデバイスは、パブリッシャを含むユーザインタフェースを生成するためのデータを提供することができる。パブリッシャは、情報を情報フィードに公開するよう構成され得る。いくつかの実施例において、ユーザインタフェースは、パブリッシャ及び情報フィードを同時に表示することができる。ユーザインタフェースは、オンラインソーシャルネットワークにおけるユーザ、レコード、又は他のエンティティのためのページレイアウトの一部であり得る。

図１９は、いくつかの実施例に従った、パブリッシャ１９０２及び情報フィード１９０４を含むユーザインタフェースを伴うレコードの一例を示している。図１９において、Ｄｅｌｌ用の取引先ページ１９０６は、ディスプレイデバイス上に表示されるグラフィカルユーザインタフェース（ＧＵＩ）の形態である。ユーザは、ユーザインタフェース内の複数のタブの中からタブ１９０８を選択することにより、取引先ページ１９０６に移動することができる。レコードとインタラクトするリクエストは、ユーザがパブリッシャ１９０２内のボタン、リンク、タブ、又はメニューセレクションを選択したことに応じて生成され得る。いくつかの実施例において、レコードは、取引先ページ１９０６に関連付けられている親レコードと関連し得る。パブリッシャは、ユーザがレコードとインタラクトするリクエストを行うことを可能にする１以上のパブリッシャアクション１９１０を含み得る。パブリッシャ１９０２内に表示されているそのようなパブリッシャアクション１９１０の例は、「Post（ポスト）」、「Log a Task（タスクのログを取る）」、及び「New Contact（新たな連絡先）」を含む。図１９の例に示されるように、「More（さらに）」を選択することは、ユーザがレコードとインタラクトするためにさらなるパブリッシャアクション１９１０から選択することを可能にするドロップダウンメニュー１９１２を生じさせる。そのようなさらなるパブリッシャアクション１９１０は、「Link（リンク）」、「Create Case（案件を作成する）」、「File（ファイル）」、「Create Listening Campaign（リスニングキャンペーンを作成する）」、「DSR」、「New Oppty（新たな商談）」、及び「Poll（投票）」を含む。加えて、取引先ページ１９０６内のパブリッシャ１９０２は、メッセージの入力のためのテキストボックス１９１４を含む。パブリッシャ１９０２はまた、テキストボックス１９１２内のメッセージを含むデータを、パブリッシャ１９０２から１以上のコンピューティングデバイスに送信するためのShare（共有）ボタン１９１６を含み、このデータが１以上のデータベースシステムに記憶される。このデータの一部は、パブリッシャ１９０２からのデータの送信に応じて、情報フィード１９０４内のフィード項目内に提示され得る。

図２０は、いくつかの実施例に従ったパブリッシャ２０００の一例を示している。パブリッシャ２０００は、ユーザが、公開されることになる情報をフィードに公開することを可能にするインタフェースである。パブリッシャ２０００は、異なるプリファレンス又は要件に従ってプログラムされ得る多様なデザイン又はレイアウトのうちの任意の１つを表示するインタフェースを提供することができる。例えば、パブリッシャ２０００のインタフェースは、パブリッシャ２０００がウェブページ上で表示されるか、モバイルデバイス上で表示されるか、自動車用ディスプレイ上で表示されるか等に応じて変わり得る。インタフェースのデザイン又はレイアウトにかかわらず、パブリッシャ２０００は、同じアプリケーションプログラミングインタフェース（ＡＰＩ）と通信して、情報をフィードに公開するパブリッシャ２０００の基本機能を実行することができる。

パブリッシャ２０００のインタフェースの一例が図２０に示されている。パブリッシャ２０００は、複数のパブリッシャアクション２００２、パブリッシャスペース２００４、メッセージボディ２００６、公開ボタン（publishing button）２００８、及び共有ドロップダウンメニュー２０１０を含み得る。パブリッシャアクション２００２の各々は、ＧＵＩボタン、リンク、タブ、チャンネル（channel）、又はメニュー項目の形態であり得る。パブリッシャアクション２００２は、パブリッシャ２０００のためのＡＰＩにより有効にされ得る。さらに、パブリッシャアクション２００２は、レコードのための作成オペレーション若しくはアップデートオペレーション、又はレコードを参照する作成オペレーション若しくはアップデートオペレーションを実行するよう構成され得る。

パブリッシャアクション２００２のうちの１つの選択は、パブリッシャスペース２００４に、選択されたパブリッシャアクション２００２に関連付けられたデータを表示させ得る。例えば、パブリッシャスペース２００４は、図２０に示される新たな連絡先を作成するための複数のデータフィールド２０１２を有するフォームを含み得る。別の例において、パブリッシャスペース２００４は、ウェブページ等の、１以上のデータソースからのコンテンツを含み得る。さらに別の例において、パブリッシャスペース２００４は、Ｈｅｒｏｋｕ（登録商標）等のサードパーティプラットフォーム上でホストされているアプリケーションからのデータを公開することができる。

パブリッシャスペース２００４内に提供されたデータは、情報フィードに公開され得る。図２０において、複数のデータフィールド２０１２は、ユーザが、新たな連絡先の作成に関連する情報を入力することを可能にする。データフィールド２０１２の一部は、デフォルト値が提供されてグレーアウトされ得る。データフィールド２０１２の一部は、それらが必須フィールドであることを示すために星印が付けられ得る。データフィールド２０１２内のそのような情報は、メッセージボディ２００６内に提供されたメッセージとともに公開され得る。メッセージは、単語、語句、文、質問、感情表現、及び／又は記号等の任意の英数字のユーザ入力又は他の文字ベースのユーザ入力を含み得る。公開ボタン２００８の選択により、データフィールド２０１２及びメッセージボディ２００６内に提供された情報が適切な情報フィードに公開される。ユーザがそのような情報を共有したいと望むエンティティは、共有ドロップダウンメニュー２０１０からエンティティを選択することにより提供され得る。

図２１Ａ〜図２１Ｄは、いくつかの実施例に従った、モバイルデバイスアプリケーション用のパブリッシャ２１０８及び情報フィード２１０４を含むユーザインタフェースの一例を示している。ＡＰＩは、パブリッシャ２１０８が、モバイルデバイスアプリケーションを含む任意の数のアプリケーションのために、データベースシステムとインタフェースをとることを可能にする。いくつかの実施例において、エンティティは、任意の顧客、パートナ、組織、又は他のユーザがＡＰＩを利用するアプリケーションを書くことができるように、パブリッシャ２１０８のためのＡＰＩを開発することができる。

図２１Ａにおいて、モバイルデバイス用のユーザインタフェースは、パブリッシャボタン２１０２及び情報フィード２１０４を含み得る。パブリッシャボタン２１０２は、ユーザが図２１Ｂに示されるパブリッシャ２１０８にアクセスすることを可能にする。パブリッシャ２１０８は、モバイルデバイスのユーザインタフェース内の情報フィード２１０４の一部の上に広がり得る。ユーザは、パブリッシャ２１０８内の複数のパブリッシャアクション２１０６の中から選択することができる。パブリッシャアクション２１０６は、「Post（ポスト）」、「Photo（写真）」、「Files（ファイル）」、「Task（タスク）」、「Contact（連絡先）」、及び「Check-In（チェックイン）」を含む。パブリッシャアクション２１０６の選択は、パブリッシャに、選択されたパブリッシャアクション２１０６に関連付けられたコンテンツ及び／又はデータフィールドを表示させ得る。図２１Ｃに示されるように、Contact（連絡先）パブリッシャアクション２１０６の選択は、パブリッシャ２１０８に、メッセージをポストするためのテキストボックス２１１０と、新たな連絡先を作成するための複数のデータフィールド２１１２と、を表示させる。モバイルデバイスアプリケーションのいくつかの実装において、パブリッシャアクション２１０６の選択は、ユーザインタフェースにキーボード２１１４を表示させる。データフィールド２１１２及びテキストボックス２１１０に情報を入力した後、ユーザは、Share（共有）ボタン２１１６を選択して、この情報を１以上の適切なフィードに公開することができる。

パブリッシャは、フィード項目等のビジュアルフィードバック要素（visual feedback element）を作成することにより、情報を１以上の情報フィードに公開するよう構成され得る。図２２は、いくつかの実施例に従ったフィード項目２２００の一例を示している。フィード項目２２００は、パブリッシャから送信されたデータを含み得る。フィード項目２２００は、ユーザインタフェース内の情報フィードの一部として現れ得る。ここで、フィード項目２２００は、レコードをアップデート又は作成したエンティティ２２０２のアイデンティティ（識別情報）（identity）と、パブリッシャからのデータに付随するメッセージ２２０４と、アップデート又は作成されたレコード２２０６の名前と、添付物（attachment）２２０８と、トピック２２１０と、を含む。パブリッシャからの他のデータも、フィード項目２２００内に提示され得る。いくつかの実施例において、レコード２２０６の名前は、ユーザインタフェースにこのレコードのためのページレイアウトを表示させる実行可能なセレクション又はリンクであり得る。フィード項目２２００内にどの情報が表示されるかは、フィード項目２２００を閲覧するエンティティのプロフィール及びフィード項目２２００が表示されるページレイアウト等のコンテキストファクタ（contextual factor）に依存し得る。

図２３Ａ〜図２３Ｂは、いくつかの実施例に従った、モバイルデバイスアプリケーション用の、パブリッシャ２３０８と、情報フィード２３０４内のフィード項目２３２０と、を含むユーザインタフェースの一例を示している。図２１Ａ〜図２１Ｄにおいて説明されたパブリッシャ２１０８と同様に、パブリッシャ２３０８は、ユーザが、情報をデータフィールド２３１２に入力して、Share（共有）ボタン２３１６を用いてそのような情報を情報フィード２３０４に公開することを可能にする。パブリッシャ２３０８は、公開される情報に付随させるための添付ボタン及びメッセージポストボタン等のさらなるパブリッシャボタン２３１８を含み得る。図２３Ｂにおいて、パブリッシャ２３０８からの情報のうちの少なくとも一部を含むフィード項目２３２０が、情報フィード２３０４内に提示され得る。ここで、フィールドデータ２３２２は、パブリッシャ２３０８内のデータフィールド２３１２から提供されるタスクのためのフィード項目２３２０内に提供される。

図１５に戻ると、ブロック１５０８において、第１のレコードとインタラクトするリクエストが、パブリッシャから、方法１５００を実行するために協働する１以上のコンピューティングデバイスにおいて受信される。第１のレコードは、データベースシステムに記憶された親レコードに関連する。ブロック１５０８におけるリクエストは、オンラインソーシャルネットワークにおいてユーザプロフィールを有するユーザ等のエンティティから、このユーザのスマートフォン、デスクトップコンピューティングデバイス、ラップトップコンピューティングデバイス、タブレットコンピューティングデバイス、又は他のモバイルコンピューティングデバイスを経由して、パブリッシャを介して受信され得る。他の例において、このリクエストは、オンラインソーシャルネットワークにおけるグループ、組織、又はレコードから受信され得る。

いくつかの実施例において、方法１５００は、エンティティが第１のレコードとインタラクトするためのパーミッションを有するかどうかを判定することをさらに含み得る。従来のように、ＣＲＭシステムは、レコードとのインタラクションを、システム管理者及びレコードの所有者に制限する。したがって、他のユーザ又はグループは、所有者又はシステム管理者の支援又は許可がないと、レコードと直接インタラクトすることができない。エンティティのアクセスパーミッションに応じて、エンティティがインタラクトできるレコードのタイプと、エンティティが特定のタイプのレコードに関して閲覧できるページレイアウトと、に対して制限が課され得る。

エンティティが第１のレコードとインタラクトするためのパーミッションを有するかどうかを判定することは、このエンティティのプロフィールの１以上のエンティティ属性を識別することを少なくとも含み得る。エンティティのプロフィールの属性は、例えば、エンティティの役割又は定義（definition）、エンティティの関連情報（relationship information）、エンティティのプリファレンス、エンティティの使用パターン（usage pattern）、及びエンティティのプロフィールに関連付けられる他のメタデータを含み得る。例えば、エンティティの役割は、所定の取引先レコードに対して協働するチームに対するメンバシップを示すことができ、レコードとインタラクトするためのパーミッションは、エンティティがその取引先レコードに対する協働者である場合に判別され得る。別の例において、エンティティの役割は、組織階層における職位を示すことができる。エンティティが組織階層において位置するポジションに応じて、このエンティティは、所定のレコードとインタラクトするためのパーミッションを有することもあるし、有さないこともない。

さらに、エンティティが第１のレコードとインタラクトするためのパーミッションを有するかどうかを判定することは、第１のレコードの１以上のレコード属性を識別することを少なくとも含み得る。第１のレコードの属性は、レコードがリードであるか、案件であるか、取引先であるか、商談であるか、タスクであるか、イベントであるか、連絡先であるか、又はカスタムオブジェクトであるか等のレコードのタイプを示すことができる。第１のレコードの属性はまた、レコードのついての他のメタデータを提供することもできる。例えば、レコードのタイプは案件であり得、この案件は、技術的問題案件（例えば、バグ）又は取引先のための注文処理案件（例えば、取引）であり得る。あるエンティティは、技術的問題案件とインタラクトすることを許可されるが、注文処理案件とインタラクトすることは許可されないこともあるし、この逆もある。

さらに、エンティティが第１のレコードとインタラクトするためのパーミッションを有するかどうかを判定することは、１以上のエンティティ属性を１以上のレコード属性と比較することを少なくとも含み得る。例えば、エンティティが、営業部の部長（Vice President）として識別された場合、このエンティティは、取引先の全ての案件にアクセスして、そのような全ての案件とインタラクトすることができる。エンティティが、一営業員（Sales Associate）として識別された場合、このエンティティは、例えば、特定の製品に関わる案件等、取引先の限定されたタイプの案件にアクセスして、そのような案件とインタラクトすることしかできない。

いくつかの実施例において、エンティティが第１のレコードとインタラクトするためのパーミッションを有する場合であっても、インタラクションのタイプが制限され得る。そのような制限は、例えば、とりわけ、システム管理者、第１のレコードの所有者、又は組織のセキュリティ／パーミッションポリシにより設定され得る。いくつかの実施例において、エンティティは、第１のレコードとインタラクトするために、所定のアクションしか実行できないよう制限され得る。したがって、ユーザインタフェース内のパブリッシャは、このエンティティに対して少なくとも一部のパブリッシャアクションを無効にすることができる、このエンティティから少なくとも一部のパブリッシャアクションを隠すことができる、あるいは別の形でこのエンティティに対して少なくとも一部のパブリッシャアクションを表示しないようにすることができる。例えば、あるエンティティは、取引先に関連する商談を閲覧、アップデート、及び作成することが可能であるが、別のエンティティは、同じ取引先に関連する商談を閲覧及びアップデートすることしか可能でないことがある。いくつかの実施例において、エンティティは、レコードとインタラクトするために、所定のタイプの情報又はオプションしか閲覧できないよう制限され得る。例えば、あるエンティティは、契約の全ての条項をアップデートできるが、別のエンティティは、同じ契約の所定の条項しかアップデートできないことがある。別の例において、あるエンティティは、取引先に関連する公的情報及び私的情報を閲覧することができるが、別のエンティティは、同じ取引先に関連する公的に利用可能な情報しか閲覧することができないことがある。

いくつかの実施例において、第１のレコードとインタラクトするリクエストは、レコードを作成するリクエスト、レコードを削除するリクエスト、レコードをアップデートするリクエスト、レコードを変換するリクエスト、レコードにファイルを添付するリクエスト、レコードからデータをダウンロードするリクエスト、レコードにデータをアップロードするリクエスト、レコードに関連付けられた情報を閲覧するリクエスト、及びレコードを参照するオペレーションを他の形で実行するリクエストを含み得る。例えば、そのようなオペレーションは、電子メールを下書きすること、ワークフロー承認を承認又は拒否すること、メモを書くこと、投票（poll）を作成すること、要求（call）のログを取ること、タスクのログを取ること、バグのログを取ること、イベントを作成すること、電子メールを送信すること、承認のための電子メールを送信すること、ポータルにポストすること、ソーシャルネットワークにポストすること、リンクを追加すること、「感謝（Thanks）」を追加すること等を含み得るが、これらに限定されるものではない。いくつかの実施例において、第１のレコードは、顧客関係管理（ＣＲＭ）オブジェクトであり得る。ＣＲＭオブジェクトは、リード、案件、取引先、商談、タスク、連絡先、キャンペーン、契約、イベント、カスタムオブジェクト、及びＶｉｓｕａｌｆｏｒｃｅページを含み得るが、これらに限定されるものではない。第１のレコードとインタラクトするリクエストは、ユーザがユーザインタフェース内でパブリッシャアクション又はカスタムアクションを選択したことに応じて生成され得る。

第１のレコードとインタラクトするリクエストは、データベースシステムに記憶された親レコードに関連する子レコードとインタラクトするリクエストであり得る。ここで、この親子関係は、データベースシステムにおけるレコード間の階層関係を指す。例えば、商談は、取引先に関連付けられた子であり得るのに対し、この取引先は親である。別の例において、タスクは、リードに関連付けられた子であり得るのに対し、このリードは親である。

図２４は、いくつかの実施例に従った、パブリッシャ２４０２及び情報フィード２４０４を含むユーザインタフェースを伴うレコードの一例を示している。パブリッシャ２４０２は、複数のパブリッシャアクション２４０６、メッセージのためのテキストボックス２４０８、さらなるパブリッシャアクション２４０６を表示するためのドロップダウンメニュー２４１０、及びShare（共有）ボタン２４１２を含む。パブリッシャ２４０２は、複数のパブリッシャアクション２４０６の中からの少なくとも１つのカスタムアクションを含み得る。カスタムアクションは、パブリッシャ２４０２のためのＡＰＩにより有効にされるアクションであり得る。いくつかの実施例において、カスタムアクションは、ＡＰＩを利用してエンティティによりカスタマイズされ得る。カスタムアクションのカスタマイゼーションに関するさらなる詳細は、以下のセクションＩＸにおいて提供される。

図２４において、Ｃｉｒｒｕｓ， Ｉｎｃ．用の取引先ページ２４１６は、複数のパブリッシャアクション２４０６を伴うパブリッシャ２４０２を含む。いくつかの実施例において、同じパブリッシャ２４０２が、異なるレコード及びエンティティ用の他のページ内に現れ得る。いくつかの例において、パブリッシャアクション２４０６は、全く同じであってよい。ユーザは、単一のユーザインタフェース又は類似するユーザインタフェースを表示する、異なるレコード及びエンティティ用の複数のページ間を移動することができる。

ここで、ユーザは、新たな連絡先の作成を開始するためのパブリッシャアクション２４０６である「Contact（連絡先）」を選択することにより、レコードとインタラクトするリクエストを開始することができる。新たな連絡先は、取引先に関連付けられた子レコードであり、取引先は親レコードである。パブリッシャアクション２４０６のうちのいずれかを選択して、ＡＰＩと通信し、レコードとインタラクトするリクエストを開始することができることを理解されたい。

図１５に戻ると、ブロック１５１２において、第１のレコードに関連付けられた第１の情報が、パブリッシャから、１以上のコンピューティングデバイスにおいて受信される。第１のレコードは、データベースシステムに記憶されていてもよいし、データベースシステムに記憶されるよう構成されていてもよい。第１の情報は、ブロック１５０８において第１のレコードとインタラクトすることをリクエストしたエンティティ（例えば、ユーザ）により提供され得る。第１の情報は、例えば、図１Ａ及び図１Ｂにおける信号ネットワーク１４を介して、方法１５００を実行する１以上のコンピューティングデバイスに伝送され得る。いくつかの実施例において、エンティティは、選択されたパブリッシャアクションに関連付けられた１以上のデータフィールド内にフィールドデータを提供することができる。例えば、イベントレコードは、イベントの日付及び時間、招待された人（invitee）の名前、並びに開催地（venue）等のフィールドデータを含み得る。別の例において、タスクは、タスクの名前、タスクに割り当てられた人（assignee）の１以上の名前、及び期限日等のフィールドデータを含み得る。

図２５は、いくつかの実施例に従った、パブリッシャアクション２４０６が選択されたときの、複数の空データフィールド２４１８を表示しているユーザインタフェースを伴う、図２４におけるレコードの一例を示している。図２５に示されるように、新たな連絡先を作成するためのパブリッシャアクション２４０６の選択は、パブリッシャ２４０２に、First Name（名）、Last Name（姓）、Title（職位）、Account（取引先）、Phone（電話番号）、Email（電子メールアドレス）、LinkedIn（リンクトイン）、及びTwitter（ツイッター）を含むデータフィールド２４１８を表示させる。新たな連絡先を作成するための一部のデータフィールド２４１８には、デフォルト値が入力されていることもあるし、新たな連絡先を作成するための一部のデータフィールド２４１８は、セキュリティクリアランス／パーミッションモデルに従ってシステム管理者により指定された予め定められた値を有するよう制限されることさえある。例えば、Account（取引先）データフィールドは、新たな連絡先と、親レコード、すなわち、Ｃｉｒｒｕｓ， Ｉｎｃ．取引先と、のレコード関係を確立するように制限される。パブリッシャ２４０２は、パブリッシャ情報を１以上の選択されたエンティティと共有するための共有ドロップダウンメニュー２４２０とともに、パブリッシャ情報を少なくとも選択されたエンティティの１以上の情報フィードに公開するためのShare（共有）ボタン２４１２をさらに表示している。

図２６は、いくつかの実施例に従った、ユーザ入力を受け入れたときの、複数の入力済みデータフィールド２４１８を表示しているユーザインタフェースを伴う、図２５におけるレコードの一例を示している。ユーザは、データフィールド２４１８の各々に値を入力することができる。いくつかの実施例において、データフィールド２４１８の各々における値は、マシン又はシステムにより生成され得る。データフィールド２４１８の各々における値は、ｄａｔａ．ｃｏｍ又はｄａｔａｂａｓｅ．ｃｏｍ等のデータベースサービスから取得されてもよい。データフィールド２４１８の各々における値を使用して、レコードとのリクエストされたインタラクションを実行する、すなわち、子レコードを作成する。さらに、データフィールド２４１８の各々における値は、データベースシステムに記憶される情報を提供する。ユーザはまた、新たな連絡先についてのさらなるコンテキスト情報を表し得る、コメント等のメッセージをテキストボックス２４０８内に入力することができる。これは、この連絡先が有用又は重要である理由を含み得る。このように、ユーザは、パブリッシャ２４０２を使用して、連絡先レコードを作成すると同時に、連絡先レコードの作成に付随するコメントを作成することができる。テキストボックス２４０８内のメッセージ及びデータフィールド２４２８内の情報は、Share（共有）ボタン２４１２を選択することにより、パブリッシャ２４０２を介して送信され得る。

図１５に戻ると、ブロック１５１６において、データベースシステムが、第１のレコードに関連付けられた第１の情報に基づいてアップデートされる。第１のレコードに対するアップデートは、レコードの作成、レコードの削除、レコードに関連付けられたデータを編集すること、レコードにアクションを記録すること、レコードの変換、レコードへのファイルの添付、レコードからデータをダウンロードすること、レコードにデータをアップロードすること、レコードに関連付けられた情報を閲覧すること、及びレコードを参照するオペレーションを他の形で実行することを含み得る。すなわち、ブロック１５１６における第１のレコードに関連付けられた第１の情報を使用して、ブロック１５０８におけるリクエストされたインタラクションを実行する。第１の情報を受信すると、１以上のコンピューティングデバイスは、データベースシステムにおいて、第１のレコードを表す行を作成又はアップデートさせることができる。例えば、レコードにアクションを記録する際、電子メールが送信された後にアップデートが実行され、次いで、レコードに記録され得る、あるいは、ポストがＴｗｉｔｔｅｒ（登録商標）又はＦａｃｅｂｏｏｋ（登録商標）のようなオンラインソーシャルネットワークに送信された後にアップデートが実行され、次いで、レコードに記録され得る。実際、パブリッシャは、レコードのネットワークドメインの外部での挙動を有するアクションを実行することができる。それでも、そのようなアクションは、レコードに記録される。

ブロック１５２０において、アップデートに関連付けられたフィード項目が、ユーザインタフェース内の情報フィードに含まれるように提示される。フィード項目は、第１のレコードへの参照を提供する１以上の実行可能なセレクションを含む。実行可能なセレクションは、メニュー、リンク、又はグラフィカルボタン等の表示コンポーネントを指し得る。いくつかの実施例において、第１のレコードへの参照は、ユーザインタフェース内で、第１のレコードのためのページを開かせ得る。このように、ユーザは、フィード項目から、直接第１のレコードに移動することができる。ユーザは、異なるユーザインタフェース間を移動することによりレコード間を移動する必要がない。

いくつかの実施例において、第１のレコードへの参照は、第１のレコードに対するさらなるアクションを実行させ得る。第１のレコードを開くことに加えて、そのようなアクションは、第２のレコードを作成すること、第１のレコードを削除すること、第１のレコードをアップデートすること、第１のレコードを変換すること、第１のレコードにファイルを添付すること、第１のレコードからデータをダウンロードすること、第１のレコードにデータをアップロードすること、第１のレコードに関連付けられた情報を閲覧すること、及び第１のレコードを参照するオペレーションを他の形で実行することを含み得るが、これらに限定されるものではない。より詳細には、そのようなアクションの例は、タスクを作成すること、タスクをアップデートすること、商談を作成すること、商談をアップデートすること、連絡先を作成すること、連絡先をアップデートすること、案件を作成すること、案件をアップデートすること、取引先を作成すること、取引先をアップデートすること、イベントを作成すること、イベントをアップデートすること、要求のログを取ること、タスクのログを取ること、バグのログを取ること、ワークフロー承認を承認すること、ワークフロー承認を拒否すること、電子メールを作成すること、メモを書くこと、投票を作成すること、案件をクローズすること、タスクを完了すること、バグをクローズすること、電子メールを送信すること、承認のための電子メールを送信すること、ポータルにポストすること、ソーシャルネットワークにポストすること、リンクを追加すること、「感謝」を追加することを含み得る。したがって、アクションは、別のページに移動することなく、第１のレコード上のフィード項目から直接実行され得る。

１以上の実行可能なセレクションは、パブリッシャに、ユーザが第１のレコードとさらにインタラクトすることを可能にするさらなるデータフィールドを提供させ得る。いくつかの実施例において、１以上の実行可能なセレクションを選択することは、パブリッシャに、第２の情報を受信するよう動作させ得る。第２の情報を使用して、第１のレコードに対して、オペレーションのうちの１つを実行することができる。あるいは、第２の情報を使用して、第２のレコードとインタラクトすることができる。第２のレコードは、第１のレコードと親子関係を有し得る。いくつかの実施例において、第２のレコードは、第１のレコードの子である。このように、フィード項目からさらなるアクションを実行するための参照を提供することにより、ユーザは、情報フィード自体の中で直接アクションを実行することが可能になる。

図２７は、いくつかの実施例に従った、パブリッシャ２４０２からのアップデートされたデータを提示しているフィード項目２４２２と、子レコードへのリンク２４２４と、を含む情報フィード２４０４を含むユーザインタフェースを伴う、図２６におけるレコードの一例を示している。フィード項目２４２２は、親レコードのための情報フィード２４０４の上部に提示されている。フィード項目２４２２は、レコードとの実行されたインタラクションに関する情報を含み得る。取引先ページ２４１６の情報フィード２４０４内に表示されている、図２７のフィード項目２４２２は、「Daniel Cheng created a contact（Ｄａｎｉｅｌ Ｃｈｅｎｇは連絡先を作成した）」を示している。いくつかの例において、フィード項目２４２２は、パブリッシャ２４０２内のデータフィールド２４１８内に提供されたさらなるデータを含み得る。しかしながら、データフィールド２４１８内に提供された全てのデータが、必ずしもフィード項目２４２２に含まれるわけではない。そのようなデータがフィード項目２４２２内にどのようにレンダリングされるかは、フィード項目２４２２を閲覧するユーザのプロフィール及びフィード項目２４２２が表示されるページレイアウト等のコンテキストファクタに依存し得る。フィード項目２４２２はまた、実行可能なセレクション、すなわち、作成又はアップデートされたレコードへのリンク２４２４を含む。図２７において、新たに作成された連絡先レコードが、リンク２４２４「Chuy Santiago」として表示されている。ユーザはまた、コメントをフィード項目２４２２にポストすること、フィード項目２４２２にいいね又は良くないねを付すこと、又はフィード項目２４２２を共有することを含む様々なアクションをフィード項目２４２２に対して実行することができる。そのようなアクションは、他の関連フィード内に提示される同じフィード項目２４２２に影響を及ぼし得る。

ユーザは、リンク２４２４を選択して、Ｃｉｒｒｕｓ， Ｉｎｃ．用の取引先レコードから、Ｃｈｕｙ Ｓａｎｔｉａｇｏ用の連絡先レコードに移動することができる。これにより、ユーザは、情報フィード２４０４から直接別のレコードに効率的に移動することが可能になる。

図１５に戻ると、ブロック１５２４において、１以上の実行可能なセレクションを選択したというユーザ入力が受信される。１以上の実行可能なセレクションは、第１のレコードへの参照を提供するよう構成されたメニュー、グラフィカルボタン、又はリンクであり得る。第１のレコードへの参照は、ユーザインタフェース内で第１のレコードを開くこと、第１のレコードから第２のレコードを作成すること、第１のレコードをアップデートすること、第１のレコードを削除すること、第１のレコードを変換すること、第１のレコードにファイルを添付すること、第１のレコードからデータをダウンロードすること、第１のレコードにデータをアップロードすること、第１のレコードに関連付けられた情報を閲覧すること、又は第１のレコードを参照するオペレーションを他の形で実行すること等、第１のレコードに対してアクションを実行させ得る。例えば、実行可能なセレクションは、電子メールに応答するための返信ボタンであり得る。別の例において、実行可能なセレクションは、ワークフロー承認リクエストに応答するための承認ボタンであり得る。いくつかの実施例において、第１のレコードへの参照は、パブリッシャに、第２のレコードに関連付けられた第２の情報を受信するよう動作させ得る。

ブロック１５２８において、第１のレコード又は第２のレコードに関連付けられた第２の情報が、パブリッシャから、１以上のコンピューティングデバイスにおいて受信される。第２のレコードは、第１のレコード又は親レコードの子レコードであり得る。第２のレコードは、データベースシステムに記憶されていてもよいし、データベースシステムに記憶されるよう構成されていてもよい。いくつかの実施例において、第２のレコードは、リード、案件、取引先、商談、タスク、連絡先、キャンペーン、契約、イベント、カスタムオブジェクト、及びＶｉｓｕａｌｆｏｒｃｅページ等のＣＲＭオブジェクトであり得る。いくつかの実施例において、第２の情報は、第１のレコード又は第２のレコードに関連付けられた１以上のデータフィールド内に提供され得る。１以上のデータフィールドにおける値は、ユーザにより定められてもよいし、システムにより生成されてもよい。いくつかの実施例において、値は、ｄａｔａ．ｃｏｍ又はｄａｔａｂａｓｅ．ｃｏｍ等のデータベースサービスから取得され得る。

ブロック１５３２において、データベースシステムが、第２の情報に基づいてアップデートされる。第１のレコード又は第２のレコードに対するアップデートは、パブリッシャ及び情報フィードを含み得るユーザインタフェースから離れることなく、パブリッシャを介してなされ得る。したがって、１以上のレコードとの複数回のインタラクションが、単一のユーザインタフェースから実行され得る。

図１５において、一例では、図２Ａ及び図２Ｂのオンデマンドサービス環境２００におけるアプリケーションサーバ２８８は、ブロック１５０４〜ブロック１５３２の一部又は全てを実行するよう構成された１以上のプロセッサを含む。他の例では、さらなるサーバが、アプリケーションサーバ２８８と協働して、これらのブロックを実行する。例えば、ブロック１５１２において、第１の情報が受信される場合、このような情報は、図１Ａ及び図１Ｂに示されるユーザシステム１２を操作しているユーザから、データネットワークを介して、サーバにより受信され得る。他の例では、そのようなデータは、ユーザの代理であるプロキシサーバ又は他のデータソースから受信される。方法１５００の様々な実装が可能であるので、図２Ｂを参照して上述したサーバ又は本明細書で開示される他のコンピューティングデバイスのいずれも、方法１５００に従ってユーザ入力及び情報アップデートを受信して処理するよう構成され得る。

いくつかの実施例において、共通ユーザインタフェースを介した複数のレコードとのインタラクションは、図１５の方法１５００において実行され得る。そのようなインタラクションは、パブリッシャ及び情報フィードのコンテキストにおいて動作しながらＣＲＭライフサイクル又は非ＣＲＭライフサイクルを進めることができる。ＣＲＭライフサイクルの一例は、本明細書で先に説明されたように、図２４〜図２７に示され得る。ＣＲＭライフサイクルの別の例は、図２８〜図３０に示され得る。

図２８〜図３０は、パブリッシャ及び情報フィードを含む単一のユーザインタフェースからＣＲＭライフサイクルを進める段階の例を示している。図２８は、いくつかの実施例に従った、パブリッシャ２８０２及び情報フィード２８０４を含むユーザインタフェースを伴うリードレコードの一例を示している。例えば、見込み客であるＭｒ． ＪｉｍＢｏｂと会った、あるいはＭｒ． ＪｉｍＢｏｂを知っているサービスエージェントは、図２８に示されるようなＭｒ．ＪｉｍＢｏｂ用のリードページ２８１６にアクセスすることができる。サービスエージェントがＭｒ． ＪｉｍＢｏｂ用のリードにアクセスするためのパーミッションの判定は、サービスエージェントのプロフィールに基づき得る。適切なパブリッシャアクション及び情報が、サービスエージェントのプロフィールに従って、データベースシステムから取得され、Ｍｒ． ＪｉｍＢｏｂ用のリードページ２８１６上に表示され得る。本明細書で先に説明されたように、一部の情報及び／又はアクションは、所定のユーザに利用可能でないことがある。図２８に示されるように、パブリッシャ２８０２内の複数のパブリッシャアクション２８０６が、Ｍｒ． ＪｉｍＢｏｂ用のリードに対してアクションを実行するためのチャンネルとして、左側のバー上に表示されている。パブリッシャアクション２８０６は、「Create a Task（タスクを作成する）」、「Create a Case（案件を作成する）」、「Convert Lead（リードを変換する）」、「Write Lead Note（リードメモを書く）」、及び「View Lead Details（リード詳細を閲覧する）」を含む。

サービスエージェントは、パブリッシャアクション２８０６のうちの任意の１つを選択して、パブリッシャ２８０２に、選択されたパブリッシャアクション２８０６に関連付けられたデータフィールド２８１８を表示させることができる。いくつかの実施例において、パブリッシャアクション２８０６の選択は、パブリッシャ２８０２に、データソースからのコンテンツ又はアプリケーションを表示させ得る。図２８において、データフィールド２８１８のうちのいくつかは、文字ベースの値を受け入れるよう構成されたテキストボックスであり、データフィールド２８１８のうちの１つは、チェックボックスであり、データフィールド２８１８のうちのいくつかは、ドロップダウンメニューである。サービスエージェントは、パブリッシャ２８０２内のデータフィールド２８１８のうちのいくつかに値を入力することができる。データフィールド２８１８のうちのいくつかにおいて、サービスエージェントは、検索クエリを実行することができる、且つ／あるいは、値を入力するためにオートコンプリート機能（auto-complete function）を利用することができる。いくつかの実施例において、データフィールド２８１８のうちのいくつかにはデフォルト値が提供され得る。

サービスエージェントは、Convert Lead（リード変換）ボタン２８１０を選択することにより、データフィールド２８１８に入力された情報を公開することができる。パブリッシャ２８０２からの情報は、データベースシステムに送信され得る。Ｍｒ． ＪｉｍＢｏｂ用のリードが削除され、Ｍｒ． ＪｉｍＢｏｂ用の商談が作成され、Ｍｒ． ＪｉｍＢｏｂ用の商談がデータベースシステムに記憶される。いくつかの実施例において、別のレコードが、Ｍｒ． ＪｉｍＢｏｂ用の商談の作成に伴って同時にインタラクトされ得る。この例において、Ｍｒ． ＪｉｍＢｏｂ用のリードからＭｒ． ＪｉｍＢｏｂ用の商談への変換に伴って、タスクが同時に作成されている。フィード項目（図示せず）が、情報フィード２８０４内での提示のために作成される。フィード項目は、Ｍｒ． ＪｉｍＢｏｂ用の商談ページに移動する機能、又は、情報フィード２８０４からＭｒ． ＪｉｍＢｏｂ用の商談を参照する他のアクションを実行する機能を、ユーザインタフェース内に提供することができる。この移動及び／又はアクションは、ユーザインタフェースを離れることなく実行することができる。すなわち、サービスエージェント又は別のエンティティは、１以上のレコードに対してアクションを実行するために、異なるユーザインタフェース間を移動する必要がない。フィード項目は、相互参照を通じて、複数の関連フィード内に公開され得る。相互参照については、以下のセクションＸＩＩＩにおいてより詳細に説明される。

図２９は、いくつかの実施例に従った、パブリッシャ２９０２及び情報フィード２９０４を含むユーザインタフェースを伴う、図２８におけるリードレコードから変換された商談レコードの一例を示している。リードレコードは、データベースシステムから削除され、商談レコードに置換される。Ｍｒ． ＪｉｍＢｏｂ用の商談ページ２９１６に移動するために、サービスエージェントは、フィード項目内の実行可能なセレクションを選択することができる。これにより、適切なパブリッシャアクション及び情報が、サービスエージェントのプロフィールに従って、データベースシステムから取得され、Ｍｒ． ＪｉｍＢｏｂ用の商談ページ２９１６内に表示され得る。図２９に示されるように、パブリッシャ２９０２内の複数のパブリッシャアクション２９０６が、Ｍｒ． ＪｉｍＢｏｂ用の商談に対してアクションを実行するためのチャンネルとして、左側のバー上に表示されている。パブリッシャアクション２９０６は、「Create a Task（タスクを作成する）」、「Log a Call（要求のログを取る）」、「Create a Case（案件を作成する）」、「Create a Service Contract（サービス契約を作成する）」、「Write Opportunity Note（商談メモを書く）」、及び「View Opportunity Details（商談詳細を閲覧する）」を含む。サービスエージェントは、パブリッシャアクション２９０６のうちの任意の１つを選択して、パブリッシャ２９０２に、選択されたパブリッシャアクション２９０６に関連付けられたデータフィールド２９１８を表示させることができる。

図２９において、サービスエージェントは、サービス契約を作成するためのパブリッシャアクション２９０６を選択しており、Contract Name（契約名）、Start Date（開始日）、及びEnd Date（終了日）用のデータフィールド２９１８が表示されている。サービスエージェントは、パブリッシャ２９０２内のデータフィールド２９１８の各々に値を入力することができる。

サービスエージェントは、Create Contract（契約作成）ボタン２９１０を選択することにより、データフィールド２９１８に入力された情報を公開することができる。パブリッシャ２９０２からの情報は、データベースシステムに送信され得る。サービス契約レコードが作成され、データベースシステムに記憶される。これは、データベースシステム内のテーブル内の行により表され得る。サービス契約レコードは、親レコードに対する子レコードとして、Ｍｒ． ＪｉｍＢｏｂ用の商談に関連する。フィード項目（図示せず）が、情報フィード２９０４に含まれるように作成される。フィード項目は、サービス契約レコードに移動する機能、又は、情報フィード２９０４からサービス契約レコードを参照する他のアクションを実行する機能を、ユーザインタフェース内に含み得る。この移動及び／又はアクションは、ユーザインタフェースを離れることなく実行することができる。

図３０は、いくつかの実施例に従った、パブリッシャ３００２及び情報フィード３００４を含むユーザインタフェースを伴う、図２９における親レコードのサービス契約レコードの一例を示している。サービス契約ページ３０１６に移動するために、サービスエージェントは、フィード項目内の実行可能なセレクションを選択することができる。これにより、適切なパブリッシャアクション及び情報が、サービスエージェントのプロフィールに従って、データベースシステムから取得され、サービス契約ページ３０１６内に表示され得る。図３０に示されるように、パブリッシャ３００２内の複数のパブリッシャアクション３００６が、サービス契約レコードに対してアクションを実行するためのチャンネルとして、左側のバー上に表示されている。パブリッシャアクション３００６は、「Add a Product（製品を追加する）」、「Write Service Contract Note（サービス契約メモを書く）」、及び「View Service Contract Details（サービス契約詳細を閲覧する）」を含む。サービスエージェントは、パブリッシャアクション３００６のうちの任意の１つを選択して、パブリッシャ３００２に、選択されたパブリッシャアクション３００６に関連付けられたデータフィールド３０１８を表示させることができる。

図３０において、サービスエージェントは、製品を追加するためのパブリッシャアクション３００６を選択しており、Product（製品）、Quantity（数量）、及びSales Price（販売価格）用のデータフィールド３０１８が表示されている。サービスエージェントは、パブリッシャ３００２内のデータフィールド３０１８の各々に値を入力することができる。

サービスエージェントは、Add（追加）ボタン３０１０を選択することにより、データフィールド３０１８に入力された情報を公開することができる。パブリッシャ３００２からの情報は、データベースシステムに送信され得る。製品の契約品目項目（contract line item）が作成され、データベースシステムに記憶される。これは、データベースシステム内のテーブル内の行により表され得る。製品の契約品目項目は、親レコードに対する子レコードとして、サービス契約レコードに関連する。フィード項目（図示せず）が、情報フィード３００４内での提示のために作成される。フィード項目は、契約品目項目に移動する機能、又は、情報フィード３００４から契約品目項目を参照する他のアクションを実行する機能を、ユーザインタフェース内に含み得る。この移動及び／又はアクションは、ユーザインタフェースを離れることなく実行することができる。

ユーザは、図２８〜図３０に示されるような単一の標準化されたユーザインタフェース（standardized user interface）内で、ＣＲＭライフサイクル間を移動し、ＣＲＭライフサイクルを進めることができる。したがって、ユーザは、ＣＲＭライフサイクルを通じてレコードの各々とインタラクトするために、複数のユーザインタフェースを移動し学習する必要がない。レコードが作成及び／又はアップデートされたときに、ユーザは、即座に移動して、情報フィード及びパブリッシャを介して、新たに作成又はアップデートされたレコードに対してアクションを実行することができる。すなわち、情報フィード及びパブリッシャを介して、ＣＲＭライフサイクルにおける全てを行うことができる。

いくつかの実施例において、パブリッシャ及び情報フィードはまた、非ＣＲＭライフサイクルを進めるための共通ユーザインタフェースとして利用され得る。例えば、金融サービスエージェントは、顧客から、投資に関する要求を受け取ることがある。金融サービスエージェントは、顧客情報を入力して、顧客の投資レコードにアクセスすることができる。顧客の投資レコードページにおいて、ユーザインタフェースは、パブリッシャ及び情報フィードを含み得る。金融サービスエージェントは、パブリッシャを介して、顧客の投資レコードに投資を追加することができ、顧客の投資レコードから投資を削除することができ、あるいは、顧客の投資レコード内の投資をアップデートすることができる。フィード項目が、投資に対する１以上の実行可能なセレクションとともに、顧客の投資レコードの情報フィード内に提示される。投資は、例えば、とりわけ、ＩＲＡ、Ｒｏｔｈ ＩＲＡ、又はモーゲージ（mortgage）を含み得る。金融サービスエージェントは、フィード項目を通じて投資にアクセスし、非ＣＲＭライフサイクルを進めるのを続けることができる。

別の例において、健康保険エージェントは、顧客から、顧客の保険の補償に関する要求を受け取ることがある。健康保険エージェントは、顧客情報を入力して、顧客の健康保険プランにアクセスすることができる。顧客の健康保険プランページにおいて、ユーザインタフェースは、パブリッシャ及び情報フィードを含み得る。いくつかの実施例において、健康保険プラン、補償、商品、制限、及び補償額を表すためのカスタムオブジェクトが、ユーザインタフェースに提供され得る。顧客が関心をもっている補償に応じて、健康保険エージェントは、パブリッシャを介して、顧客の健康保険プランを追加、削除、又はアップデートすることができる。これは、健康保険プランに商品を追加すること又は健康保険プランから商品を削除することを含み得る。これはまた、制限及び補償額をアップデートすることを含み得る。フィード項目が、商品又は補償に対する１以上の実行可能なセレクションとともに、顧客の健康保険プランの情報フィード内に提示される。健康保険エージェントは、フィード項目を通じて商品又は補償にアクセスし、非ＣＲＭライフサイクルを進めるのを続けることができる。

別の例において、ユーザは、取引先下の経費報告書をファイルしたいと望むことがある。ユーザは、取引先レコードにアクセスすることができる。取引先レコードのユーザインタフェースは、パブリッシャ及び情報フィードを含む。いくつかの実施例において、パブリッシャは、Ｃｏｎｃｕｒ（登録商標）等の、経費報告のためのサードパーティアプリケーションを公開することができる。いくつかの実施例において、パブリッシャは、「File New Expense Report（新たな経費報告書をファイルする）」等のカスタムアクションを含み得る。ユーザは、パブリッシャを介して、経費報告書をファイルし、情報をフィード項目として情報フィードに公開することができる。フィード項目は、新たに作成された経費報告書にリンクしている１以上の実行可能なセレクションを含み得る。ユーザは、フィード項目を通じて経費報告書にアクセスし、非ＣＲＭライフサイクルを進めることができる。

ＸＩＩＩ．フィード項目の相互参照
図１６Ａは、いくつかの実施例に従って実行される、オンラインソーシャルネットワークにおいて単一のユーザインタフェースから１以上のレコードとインタラクトするための、コンピュータにより実施される方法１６００ａの一例のフローチャートを示している。図１６Ａは、図３１、図３２Ａ〜図３２Ｃ、及び図３３Ａ〜図３３Ｃを参照して説明され得る。ブロック１６０４ａにおいて、概して方法１５００のブロック１５０４において上述したように、パブリッシャを含むユーザインタフェースを生成するためのデータが提供される。ブロック１６０８ａにおいて、概して方法１５００のブロック１５０８において上述したように、第１のレコードとインタラクトするリクエストが、パブリッシャから受信される。第１のレコードは、データベースシステムに記憶された親レコードに関連し得る。ブロック１６１２ａにおいて、概して方法１５００のブロック１５１２において上述したように、第１のレコードに関連付けられた第１の情報が、パブリッシャから受信される。ブロック１６１６ａにおいて、概して方法１５００のブロック１５１６において上述したように、データベースシステムが、第１のレコードに関連付けられた第１の情報に基づいてアップデートされる。

ブロック１６２０ａにおいて、第１の情報に基づくアップデートに関連付けられたフィード項目が、ユーザインタフェース内の親レコードの情報フィードに含まれるように提示される。フィード項目は、親レコードの情報フィード内に、パブリッシャからの第１の情報を表すビジュアルフィードバック要素を提供することができる。以下でより詳細に説明されるように、フィード項目は、複数の異なるフィードに含まれるように提示され得るが、フィード項目は、少なくとも親レコードの情報フィードに含まれるように提示され得る。いくつかの実施例において、フィード項目は、第１のレコードへの参照を提供する１以上の実行可能なセレクションを含み得る。結果として、ユーザは、フィード項目から直接第１のレコードに移動することができる。いくつかの実施例において、第１のレコードへの参照は、第１のレコードに対するさらなるアクションを実行させ得る。そのようなアクションは、第２のレコードを作成すること、第１のレコードを削除すること、第１のレコードをアップデートすること、第１のレコードを変換すること、第１のレコードにファイルを添付すること、第１のレコードからデータをダウンロードすること、第１のレコードにデータをアップロードすること、第１のレコードに関連付けられた情報を閲覧すること、及び第１のレコードを参照するオペレーションを他の形で実行すること（例えば、要求のログを取ること、電子メールを作成すること、ワークフロー承認を承認又は拒否すること等）を含み得る。いくつかの例において、１以上の実行可能なセレクションを選択することは、パブリッシャに、第２の情報を受信するよう動作させ得る。

図３１において、フィード項目３１２２が、取引先ページ３１１６内に示される親レコードの情報フィード３１０４に含まれるように提示されている。ユーザＤａｎｉｅｌ Ｃｈｅｎｇが新たな連絡先（子レコード）を作成した後、フィード項目３１２２が、取引先（親レコード）の情報フィード３１０４の上部に公開される。フィード項目３１２２は、実行可能なセレクション、すなわち、新たに作成された連絡先「Ｃｈｕｙ Ｓａｎｔｉａｇｏ」へのリンク３１２４を含む。ユーザはまた、コメントをフィード項目３１２２に対してポストすること、フィード項目３１２２にいいね又は良くないねを付すこと、又はフィード項目３１２２を共有することを含む様々なアクションをフィード項目３１２２に対して実行することができる。そのようなアクションは、他の関連フィード内に提示される同じフィード項目３１２２に影響を及ぼし得る。ユーザは、リンク３１２４を選択して、Ｃｉｒｒｕｓ， Ｉｎｃ．用の取引先レコードから、Ｃｈｕｙ Ｓａｎｔｉａｇｏ用の連絡先レコードに移動することができる。

図１６Ａに戻ると、ブロック１６２４ａにおいて、フィード項目と相互参照されている１以上のエンティティが識別される。フィード項目の相互参照は、複数の方法により実現され得る。相互参照されているエンティティのアイデンティフィケーション（識別情報）（identification）は、相互参照用データ（cross-referencing data）から取得され得る。いくつかの実施例において、そのような相互参照用データは、ＡＰＩから受信され得る。相互参照されるエンティティの数は無制限であり得、相互参照されるエンティティの各々は、ＡＰＩにおけるペイロードにより定められ得る。例えば、ユーザは、ＡＰＩのペイロード内に相互参照用データを定めることができる。いくつかの実施例において、ペイロード及び相互参照用データを提供するために、ＡＰＩがパブリッシャにより利用される。

いくつかの実施例において、第１のレコードとインタラクトするリクエストを受信した後、パブリッシャに、第１のレコードの１以上のデータフィールドを表示させることができる。１以上のデータフィールドは、第１のレコードに関連付けられた第１の情報を受け入れるよう構成される。１以上のデータフィールドのうちの少なくとも１つは、フィード項目と相互参照される１以上のエンティティを定める相互参照用データを受け入れるよう構成される。相互参照されるエンティティは、ユーザ、グループ、組織、及びレコードを含み得る。いくつかの実施例において、相互参照用データは、ペイロード内のユーザ入力値により定められる等、ユーザにより定められ得る。

いくつかの他の実施例において、相互参照用データは、マシン又はシステムにより定められてもよい。すなわち、相互参照されているエンティティのアイデンティフィケーション（識別情報）は、ハードコードされたものであり得る。例えば、システム管理者又は親レコードの所有者は、相互参照用データのデフォルト値を設定することができる。いくつかの例において、相互参照されているエンティティは、第１のレコード及び第１のレコードの親レコードを含み得る。いくつかの例において、相互参照されているエンティティは、第１のレコード、第１のレコードの親レコード、第１のレコードの子レコード、第１のレコードにサブスクライブしているユーザ、第１のレコードとインタラクトしているユーザ、及び第１のレコードとインタラクトしているユーザをフォローしているユーザを含み得る。前述のエンティティの任意の数の組合せが、フィード項目と相互参照され得ることを理解されたい。

相互参照されているエンティティの識別は、レコード関連情報に少なくとも部分的に基づき得る。レコード関連情報は、データベースシステムから取得され得る。レコード関連情報は、子レコードが１つの親レコード又は複数の親レコードに関連していることを示すことができる。例えば、レコード関連情報は、データベースシステムにおいて取引レコードが複数の取引先レコードに関連していることを示すことができる。いくつかの例において、レコード関連情報は、子レコードがさらなる子レコードに対する親レコードであることを示すことができる。

第１のレコードのレコード関連情報は、フィード項目と相互参照されている１以上のエンティティのうちの少なくとも１つを判別するのに役立ち得る。フィード項目は、第１のレコードの親レコードの情報フィードに含まれるように提示されるので、フィード項目は、親レコード又は第１のレコードに関連する他のエンティティと相互参照され得る。どのエンティティが親レコード及び／又は第１のレコードに関連しているかは、レコード関連情報により提供され得る。例えば、フィード項目は、第１のレコードの複数の親レコードと相互参照され得る。

ブロック１６２８ａにおいて、アップデートに関連付けられたフィード項目が、フィード項目と相互参照されている１以上のエンティティの１以上の情報フィード内に提供される。フィード項目がどこに伝播されるかは、相互参照用データ又はレコード関連情報に基づき得る。親レコードの情報フィード内に表示されるものと同じフィード項目が、複数のユーザ、グループ、組織、及びレコードにわたって伝播され、複数のユーザ、グループ、組織、及びレコードに対して表示され得る。結果として、単一の会話スレッドが、様々なユーザ、グループ、組織、及びレコードの情報フィード内に複数回公開され得る。複数のユーザ、グループ、組織、及びレコードとフィード項目を相互参照することは、異なる場所にフィード項目をコピー又は再ポストすることよりも好ましいものであり得る。異なる場所にフィード項目をコピー又は再ポストすることにより、オリジナルのフィード項目に対して取られるアクションは、オリジナルのフィード項目のコピー又はオリジナルのフィード項目の再ポストにおいては通常公開されない。これは、オリジナルのフィード項目上での複数の異なる会話スレッドと、フィードのオリジナルのフィード項目のコピーと、をもたらし得る。相互参照することで同じフィード項目を複数のエンティティにわたって伝播することにより、他のユーザは、複数のユーザインタフェース間を移動する必要なく、フィード項目とインタラクトすることができる、あるいは、フィード項目に対してアクションを別の形で実行することができる。例えば、フィード項目が、エンティティと相互参照されている場合、特定のレコードの協働者は、自分のニュースフィード、親レコードのレコードフィード、又は第１のレコードのレコードフィードから、フィード項目とインタラクトすることができる。

例えば、ユーザは、新たなタスクを作成することができる。新たなタスクを作成する際、ユーザは、このタスクを、商談及び案件に関連付けることができる。加えて、ユーザは、このタスクを１０個の連絡先に関連付けることができる。パブリッシャによりこのタスクが作成されると、このタスクに関する情報がフィード項目に公開される。このフィード項目は、商談、案件、及び１０個の連絡先と相互参照されているので、このフィード項目は、これらのエンティティの各々の情報フィード内に伝播される。

本明細書で先に説明されたように、通常、フィード項目は、親レコードの情報フィード内に公開される。しかしながら、フィード項目は、相互参照されているエンティティ又は関連エンティティの他の情報フィード内に伝播され公開され得る。例えば、ユーザが、取引先（すなわち、親レコード）のページから連絡先（すなわち、子レコード）を作成している場合、フィード項目は、少なくとも取引先レコードのフィード内に伝播され得る。いくつかの実施例において、フィード項目はまた、新たに作成された連絡先のレコードフィード内に伝播され得る。いくつかの実施例において、フィード項目はまた、新たに作成された連絡先の複数の親レコードの他のレコードフィード内に伝播され得る。いくつかの実施例において、フィード項目はまた、親レコード又は子レコードにサブスクライブされているユーザのニュースフィード内に伝播され得る。

図３２Ａ〜図３２Ｃは、レコードに関連する様々な情報を表示しているユーザインタフェースを伴うレコードの一例を示している。詳細には、ユーザインタフェースは、レコードの情報フィードに関連する情報、レコード詳細、及びレコード関連情報を表示することができる。

図３２Ａは、取引先ページ３２１６の情報フィード３２０４を表示しているユーザインタフェースを伴うレコードの一例を示している。ユーザインタフェースはまた、パブリッシャ３２０２を含む。情報フィード３２０４は、Feed（フィード）タブ３２０８ａを選択することにより閲覧することができる。情報フィード３２０４は、メッセージ、フィード追跡アップデート等を示す複数のフィード項目を表示することができる。

図３２Ｂは、図３２Ａの取引先ページ３２１６のレコード詳細３２１０を表示しているユーザインタフェースを伴うレコードの一例を示している。レコード詳細３２１０は、Details（詳細）タブ３２０８ｂを選択することにより閲覧することができる。レコード詳細３２１０は、この取引先自体と、その１以上の親レコードと、についての情報を提供することができる。そのような情報はまた、関連レコード、ファイル、及びウェブサイトへのリンクを含み得る。ここで、レコード詳細３２１０は、Account Owner（取引先所有者）、Account Name（取引先名）、Website（ウェブサイト）、Billing Address（請求先住所）、Shipping Address（発送先住所）等といったＣｉｒｒｕｓ， Ｉｎｃ．についての一般情報を表示している。ユーザのアクセスパーミッションに応じて、ユーザは、レコード詳細３２１０にアクセスする際、及び／又は、レコード詳細３２１０を編集する際、制限されることがある。

図３２Ｃは、図３２Ａの取引先ページ３２１６のレコード関連情報３２２０を表示しているユーザインタフェースを伴うレコードの一例を示している。レコード関連情報３２２０は、Related（関連）タブ３２０８ｃを選択することにより閲覧することができる。レコード関連情報３２２０は、Ｃｉｒｒｕｓ， Ｉｎｃ．用の取引先レコードに関連するレコードをリストした情報を提供することができる。例えば、レコード関連情報は、Ｃｉｒｒｕｓ， Ｉｎｃ．に関連付けられた連絡先、商談、案件、タスク、及びイベントを含む、Ｃｉｒｒｕｓ， Ｉｎｃ．用の取引先レコードに関連する複数の子レコードを表示する。いくつかの例において、フィード項目について相互参照されているエンティティの識別は、レコード関連情報３２２０に少なくとも部分的に基づき得る。

図３３Ａ〜図３３Ｃは、複数のレコード及びユーザプロフィールと相互参照されている単一のフィード項目の例を示している。図３３Ａは、いくつかの実施例に従った、パブリッシャ３３０２ａからのアップデートされたデータを提示しているフィード項目３３２２ａを含むレコードフィード３３０４ａを伴う連絡先レコードの一例を示している。任意のユーザインタフェースからのパブリッシャ又はＡＰＩは、フィード項目３３２２ａを作成するために必要なアップデートされたデータを提供することができる。この例において、公開されたフィード項目３３２２ａが、連絡先レコードページ３３１６ａ内のレコードフィード３３０４ａに含まれるように提示されている。フィード項目３３２２ａは、連絡先レコードに対して実行されたアクションと、このアクションのソースと、についての情報を含む。フィード項目３３２２ａはまた、この連絡先の作成に付随させたメッセージポストからの情報を含む。フィード項目３３２２ａは、コメントをフィード項目３３２２ａにポストすること、フィード項目３３２２ａにいいね又は良くないねを付すこと、及びフィード項目３３２２ａを共有することを含むアクションをフィード項目３３２２ａに対して実行するよう構成されているアクション３３２６ａをさらに含む。そのようなアクション３３２６ａは、単一の会話スレッドを作成するために、他の関連フィード内に伝播される同じフィード項目に影響を及ぼすよう構成され得る。

フィード項目３３２２ａの作成は、図２４〜図２７に示される一連のアクションから新たな連絡先を作成した結果であり得る。図２７は、取引先レコードの情報フィード２１０４内に表示されているフィード項目２４２２を示しているのに対し、図３３Ａは、連絡先レコードの情報フィード３３０４ａ内に表示されているフィード項目３３２２ａを示している。図２７のフィード項目２４２２は、図３３Ａのフィード項目３３２２ａを表示するために、子レコードと相互参照され得る。いくつかの例において、異なる情報フィード内に表示される相互参照されているフィード項目は、異なる情報を提供することができる。例えば、フィード項目２４２２は、図２７において、子レコードへのリンク２４２４を含むのに対し、フィード項目３３２２ａは、そのようなリンクを含まない。

相互参照されているフィード項目は、異なるフィードにわたって伝播される同じフィード項目である。しかしながら、相互参照されているフィード項目は、コンテキストファクタに応じて異なるようにレンダリングされ得る。１つのそのようなコンテキストファクタは、ユーザが、ワークフローを承認できる役割又は定義を有するかどうか、又は、このような場合に、承認ボタンが相互参照されているフィード項目内に現れ得るかどうか等、相互参照されているフィード項目を閲覧しているユーザのプロフィールを含み得る。別のコンテキストファクタは、ページレイアウトが、ユーザのホームページであるか、親レコードのページであるか、子レコードのページであるか等、相互参照されているフィード項目が表示されるページレイアウトを含み得る。別のコンテキストファクタは、デバイスが、スマートフォンであるか、タブレットであるか、ラップトップであるか、又はデスクトップであるか等、相互参照されているフィード項目が提供されるデバイスのタイプを含み得る。したがって、相互参照されているフィード項目は同じ（例えば、データベースシステムのテーブル内の同じ行の情報）でありながら、相互参照されているフィード項目は、コンテキストに応じて異なる情報を提供することができる。例えば、相互参照されているフィード項目の前段部（preamble）又は補助的ボディ部（auxiliary body）は、異なるフィード内に異なる情報を提示することができる。

図３３Ｂは、いくつかの実施例に従った、図３３Ａのフィード項目から相互参照されているフィード項目３３２２ｂと連絡先レコードへのリンク３３２４ｂとを含むニュースフィード３３０４ｂを伴うユーザプロフィールの一例を示している。この例において、図３３Ａの公開されたフィード項目３３２２ａが、連絡先レコードページ３３１６ａ内のレコードフィードに含まれるように提示されるだけでなく、同じフィード項目が、ユーザプロフィールページ３３１６ｂのニュースフィード３３０４ｂに含まれるように、図３３Ｂのフィード項目３３２２ｂとして提示される。ユーザプロフィールページ３３１６ｂは、連絡先レコードを作成したユーザ、連絡先レコードをアップデートしたユーザ、又は連絡先レコードに対してアクションを別の形で実行したユーザに対応し得る。ここで、ユーザプロフィールページ３３１６ｂは、連絡先レコードを作成したＤａｎｉｅｌ Ｃｈｅｎｇに対応するものである。図３３Ａのフィード項目３３２２ａと同様に、ニュースフィード３３０４ｂ内のフィード項目３３２２ｂは、この連絡先レコードに対して実行されたアクションと、このアクションのソースと、この連絡先の作成に付随させたメッセージポストからの情報と、フィード項目３３２２ｂに対してアクションを実行するよう構成されたアクション３３２６ｂと、を含む。加えて、フィード項目３３２２ｂは、ユーザプロフィールページ３３１６ｂから図３３Ａの連絡先レコードページ３３１６ａに効率的に移動するためにユーザが選択できるリンク３３２４ｂを含む。

図３３Ｃは、いくつかの実施例に従った、図３３Ａのフィード項目から相互参照されているフィード項目３３２２ｃと連絡先レコードへのリンク３３２４ｃとを含むニュースフィード３３０４ｃを伴う別のユーザプロフィールの一例を示している。図３３Ｂと同様に、図３３Ａからの同じフィード項目が、ユーザプロフィールページ３３１６ｃのニュースフィード３３０４ｃ内に公開され得る。ユーザプロフィールページ３３１６ｃは、Ｄａｎｉｅｌ Ｃｈｅｎｇをフォローしているユーザ、又は、親レコード又は連絡先レコードにサブスクライブしているユーザに対応し得る。ここで、ユーザプロフィールページ３３１６ｃは、親レコードにサブスクライブしているＳｃｏｔｔ Ｐｅｒｋｅｔに対応するものである。図３３Ａのフィード項目３３２２ａと同様に、ニュースフィード３３０４ｃ内のフィード項目３３２２ｃは、この連絡先レコードに対して実行されたアクションと、このアクションのソースと、この連絡先の作成に付随させたメッセージポストからの情報と、フィード項目３３２２ｃに対してアクションを実行するよう構成されたアクション３３２６ｃと、を含む。加えて、フィード項目３３２２ｃは、ユーザプロフィールページ３３１６ｃから図３３Ａの連絡先レコードページ３３１６ａに効率的に移動するためにユーザが選択できるリンク３３２４ｃを含む。

ＸＩＶ．フォロワへの相互参照
図１６Ｂは、いくつかの実施例に従って実行される、オンラインソーシャルネットワークにおいてエンティティの１以上のフォロワによりアクセスされる相互参照されているフィード項目を公開するための、コンピュータにより実施される方法１６００ｂの一例のフローチャートを示している。

方法１６００ｂのブロック１６０４ｂにおいて、フィード項目を親エンティティのフィードに公開するリクエストが、コンピューティングデバイスにおいて受信される。親エンティティは、オンラインソーシャルネットワークのデータベースにおいて識別される。例えば、グループ、ユーザ、レコード、又はＣＲＭオブジェクト等といった親エンティティに専用のページ上に配置されるパブリッシャは、フィード項目をこの親エンティティの情報フィードに公開するよう構成され得る。したがって、フィード項目は、階層データモデルにおける親エンティティの子として特徴付けられ得る。フィード項目は、図９Ａに示されるテーブルを参照して上述したように、親エンティティに関連付けられたフィードテーブル等のデータベーステーブルに記憶され、そのようなデータベーステーブルにおいて識別され得る。例えば、フィード項目が取引先に公開される場合、この取引先のレコードフィードは、このフィード項目の親であり得る。フィード項目がユーザに公開される場合、このユーザのプロフィールフィードは、このフィード項目の親であり得る。

親エンティティは、１以上のフォロワを有し得る。あるエンティティがあるフィード項目の親である場合、このフィード項目はまた、この親エンティティをフォローしているユーザのニュースフィード内に公開される。例えば、あるフィード項目がある商談に公開される場合、この商談はこのフィード項目の親であり、この商談のフォロワも、自分のニュースフィード内でこのフィード項目を閲覧するためのアクセスを有する。図９Ａを参照して上述したような様々なテーブルは、フィード項目を識別して、このフィード項目を、様々なエンティティと所与のエンティティのフォロワのニュースフィードとに関連付けることができる。

フィード項目は、通常、親エンティティ及びこの親エンティティのフォロワのフィードに公開されるが、フィード項目は、相互参照され、他のエンティティのフィード内に現れ得る。相互参照することは、１以上のエンティティを識別してフィード項目に関連付け、そのフィード項目が識別されたエンティティのフィード内に現れようにすることを指し得る。したがって、相互参照されているフィード項目は、相互参照されているエンティティに専用のフィード、及び相互参照されているエンティティをフォローしているユーザのニュースフィードを含む複数のフィード内に現れ得る。

いくつかの実施例において、方法１６００ｂは、コンピューティングデバイスにより、パブリッシャを含むユーザインタフェースを生成するためのデータを提供することをさらに含み得る。パブリッシャは、情報を情報フィードに公開するよう構成され、パブリッシャは、相互参照される１以上のエンティティを選択するためのＡＰＩを含む。ユーザは、パブリッシャとインタラクトして、相互参照用データを提供することができる。代替的に、相互参照用データは、ハードコードされたものであってもよい。フィード項目が相互参照されている場合、相互参照されているフィード項目は、親エンティティとは異なるエンティティのフィードに伝播される。相互参照されているフィード項目は、異なるフィードにわたって伝播される子フィード項目と同じフィード項目である。相互参照されているフィード項目は、あたかも親エンティティがそのような相互参照されているフィード項目の親であるかのように振る舞う。

方法１６００ｂのブロック１６０８ｂにおいて、エンティティが、フィード項目と相互参照されているものとして識別される。この相互参照されているエンティティは、１以上のフォロワを有する。フォロワは、相互参照されているエンティティをフォローしているユーザ等の任意のエンティティであり得る。フォロワは、例えば、相互参照されているエンティティのフィードへのサブスクライバであり得る。いくつかの実施例において、エンティティを、フィード項目と相互参照されているものとして識別することは、フィード項目がエンティティと相互参照されていると判定するために処理され得るデータを記憶しているデータベースにアクセスすることを含む。フィード項目が、親エンティティのフィードに加えて、他のフィードにも公開されるように、相互参照されているエンティティは、親エンティティとは異なる。２以上のエンティティが、フィード項目と相互参照されているものとして識別され得る。このようなエンティティは、オンラインソーシャルネットワークのデータベースにおいて相互参照されているものとして示され得る。

いくつかの実施例において、相互参照されているエンティティは、ユーザ、グループ、組織、レコード、又はカスタムオブジェクトを含み得る。したがって、フィード項目は、親エンティティのフィードに加えて、少なくともユーザ、グループ、組織、レコード、又はカスタムオブジェクトのフィードにも関連付けられ得る。いくつかの実施例において、相互参照されているエンティティは、ＣＲＭオブジェクトであり得る。ＣＲＭオブジェクトは、リード、案件、取引先、商談、タスク、及び連絡先を含み得る。フィード項目と相互参照されているものとして識別されるエンティティの数は、無制限であり得るが、相互参照されているエンティティの実際の識別は、所定の潜在的エンティティ（potential entity）に制限され得る。いくつかの例において、潜在的エンティティは、レコード関連情報に少なくとも部分的に基づき得る。親エンティティに関連するレコードに関するデータが、１以上のデータベーステーブルに記憶され得、そのようなデータが、相互参照されているエンティティの識別を容易にするために、コンピューティングデバイスによりアクセスされ得る。レコード関連情報は、例えば、オンラインソーシャルネットワークにおいて取引レコードが複数の取引先レコードに関連していることを示すことができる。レコード関連情報は、タスクが割り当て者（assignor）、取引先、及びプロジェクトに関連していることを示すことができる。いくつかの例において、潜在的エンティティは、ユーザ入力に少なくとも部分的に基づき得る。

フィード項目を生成、識別、操作、又は公開するコード、又はフィード項目を識別する他のデータは、親エンティティとは異なるエンティティへの相互参照を指定することができる。そのようなコード及び／又はデータは、フィード項目が相互参照されるエンティティのフィード内に現れるようにするために提供され得る。いくつかの実施例において、親エンティティに関連付けられたデータベーステーブルは、相互参照されるエンティティの識別に関するデータを反映するためにアップデートされ得る。次いで、データベーステーブルにアクセスして、親エンティティフィードに対する将来のアップデートにおける相互参照を決定することができる。

いくつかの実施例において、相互参照用データが、相互参照されているエンティティを識別するためにＡＰＩにおいて指定され得る。いくつかの実施例において、相互参照用データは、例えば、次の関数の引数において等、相互参照されているエンティティを識別するためのコード内で指定され得る：public FeedCrossReferenceData(String recordId, String networkId, FeedCrossReferenceTypeEnum referenceType)。recordIDは、親エンティティを識別する。FeedCrossReferenceTypeは、識別されたエンティティへの相互参照、識別されたエンティティのフォロワへの相互参照、又はこれら両方等の相互参照のタイプを識別する。アプリケーション設計者等のユーザは、フィード項目が親エンティティとは異なるフィード内に伝播されるように、１以上の相互参照されているエンティティを識別することができる。したがって、いくつかの実施例において、相互参照されているエンティティの識別は、フィードＡＰＩにおいてなされ得、フィード項目と相互参照されているエンティティの識別は、フィードＡＰＩを介したユーザ入力に応答するものであり得る。

方法１６００ｂのブロック１６１２ｂにおいて、フィード項目を相互参照されているエンティティの１以上のフォロワに公開するリクエストが、コンピューティングデバイスにおいて受信される。いくつかの実施例において、このリクエストは、相互参照がトランジティブ（transitive）であるか否かを指定し得る。トランジティブな相互参照は、フィード項目を相互参照されているエンティティのフィード内に公開し得るとともに、フィード項目を相互参照されているエンティティのフォロワのニュースフィードフィード内に公開し得る。非トランジティブな相互参照は、フィード項目を相互参照されているエンティティのフィード内に公開し得るが、フィード項目を相互参照されているエンティティのフォロワのニュースフィードには公開しない。いくつかの実施例において、方法１６００ｂは、フィード項目が、相互参照されているエンティティの１以上のフォロワに対してトランジティブであるかどうかを判定することをさらに含み得る。相互参照がトランジティブであるか否かは、フィードＡＰＩ等のＡＰＩにおいて指定され得る。

いくつかの実施例において、方法１６００ｂは、コンピューティングデバイスにおいて、相互参照されているエンティティによりアクセスされるフィード項目を公開するリクエストを受信すること、及び、相互参照されているエンティティのフィード内にフィード項目を表示するよう動作可能なディスプレイデバイスにフィード項目を提供することをさらに含み得る。したがって、フィード項目は、相互参照されているエンティティの情報フィードに加えて、相互参照されているエンティティのフォロワのニュースフィード内に表示され得る。

ユーザインタフェース内のパブリッシャが、相互参照される１以上のエンティティを選択するためのＡＰＩを含む場合、ユーザは、ＡＰＩを介して相互参照されるエンティティを識別することができる。例えば、相互参照される１以上のエンティティを選択するためのフィードＡＰＩのクライアントは、フィード項目の伝搬（propagation）を制御することができる。クライアントは、相互参照される１以上のエンティティを識別して、相互参照がトランジティブであるか否かを判定することができる。したがって、フィード項目を相互参照されているエンティティ及び相互参照されているエンティティの１以上のフォロワに公開するリクエストを受信することは、ＡＰＩを介したユーザ入力に応答するものであり得る。そのようなＡＰＩを使用することにより、クライアントは、フィード項目の相互参照を管理することに加えて、副次的影響として生じ得る「ノイズ」を低減することが可能になり得る。すなわち、クライアントは、フィード項目が、相互参照されているエンティティのフォロワのうちの１つ、一部、又は全てに関連しないと判定することができ、それにより、フィード項目の伝播を、フィード項目に関連すると判定され得るフォロワに制限することができる。このように、クライアントは、所定のエンティティには不必要であり得る、あるいは所定のエンティティに関連しないものであり得るフィード項目を含むフィードが過剰に存在するのを避けることができる。

例えば、タスクに関するフィード項目は、そのタスクの情報フィードに対する子にされる。ユーザは、そのタスクの割り当て者及びそのタスクに関連付けられた商談への相互参照を指定することができる。その商談をフォローしているユーザが、そのタスクについてヒアリングすることに関心がある場合、その相互参照は、トランジティブであるとして指定され得る。結果として、フィード項目が、その商談をフォローしているユーザのニュースフィード内に現れ得る。しかしながら、そのタスクの割り当て者をフォローしているユーザが、その割り当て者が他の人に割り当てているタスクについてヒアリングすることに関心がない場合、その相互参照は、非トランジティブであるとして指定され得る。結果として、フィード項目は、その割り当て者をフォローしているユーザのニュースフィード内に現れない。

別の例において、クライアント取引先に対するアップデートに関するフィード項目は、その取引先の情報フィードに対する子にされる。ここで、そのアップデートは、発注の履行に関連する。ユーザは、その発注に関する販売者及びその発注に関連する取引への相互参照を指定することができる。その取引のフォロワは、その発注の履行についてヒアリングすることに関心があることもあれば、その販売者のフォロワは、その販売者が関与している発注の全てに関心があるわけではないこともある。その発注の履行に関するフィード項目は、その販売者のニュースフィード及びその取引のレコードフィードに加えて、その取引をフォローしているユーザのニュースフィードに対して相互参照され得るが、その販売者をフォローしているユーザのニュースフィードに対しては相互参照されない。

相互参照がトランジティブであるか否かを判定することは、関連性評価に基づき得る。フィード項目が、相互参照されているエンティティのフォロワに関連する場合、相互参照は、フォロワに対してトランジティブである。いくつかの実施例において、方法１６００ｂは、フィード項目と相互参照されているエンティティのフォロワとの関連性を分析すること、及び、フィード項目が相互参照されているエンティティのフォロワに関連すると判定することを含み得る。このように判定されると、フィード項目を、相互参照されているエンティティだけでなく、相互参照されているエンティティのフォロワにも公開するリクエストがなされ得る。いくつかの実施例において、関連性評価は、ハードコードされたものであり得、アプリケーション設計者により作成された一連のルールに基づき得る。このようなルールは、エンティティへの相互参照がいつこのエンティティ自体に制限されるか、及び、エンティティへの相互参照がいつこのエンティティのフォロワを含むのかを判定することができる。

方法１６００ｂのブロック１６１６ｂにおいて、フィード項目が、親エンティティ及び相互参照されているエンティティに関連付けられて、１以上のデータベーステーブルに記憶される。フィード項目は、１以上のフォロワによりアクセス可能な複数の情報フィード内に表示され得る。１以上のフォロワによりアクセス可能な複数の情報フィードは、親エンティティのフィードと１以上のフォロワの１以上のフィードとを含み得る。いくつかの実施例において、方法１６００ｂは、フォロワによりアクセス可能な複数の情報フィード（親エンティティのフィード、相互参照されているエンティティのフィード、及びフォロワのニュースフィード等）のうちの１つの情報フィード内にフィード項目を表示するよう動作可能なディスプレイデバイスに、フィード項目を提供することをさらに含み得る。

フォロワの情報フィード内のフィード項目は、親エンティティのフィード内に提示されるものと同じフィード項目である。相互参照されているフィード項目は、あたかも相互参照されているエンティティ自体から子にされたフィード項目であるかのように操作及び処理されるよう構成される。実際、同じフィード項目が、親エンティティのフィード、相互参照されているエンティティのフィード、及びフォロワのニュースフィード内に公開される。したがって、コメント、いいね、及び良くないね等を含む同じ会話スレッドが、親エンティティ、及び相互参照されているエンティティのフォロワにおいて公開される同じフィード項目の各々に伝播され得る。しかしながら、親エンティティ、及び相互参照されているエンティティのフォロワにおいて公開されるフィード項目が、単一の親から生じたかのように同じように振る舞うが、フィード項目が、親エンティティにおいてどのようにレンダリングされるかと、フィード項目が、相互参照されているエンティティ及び／又は相互参照されているエンティティのフォロワにおいてどのようにレンダリングされるかと、は、以下で説明されるように異なり得る。

相互参照されているエンティティの情報フィード又はフォロワの情報フィード内に提示されるフィード項目は、ディスプレイデバイスにおいて、情報をユーザインタフェースに公開することができる。しかしながら、公開される情報は、１以上のコンテキストファクタに依存し得る。いくつかの実施例において、公開される情報は、フィード項目が含まれる選択された情報フィードのソースに少なくとも部分的に応じて、異なるようにレンダリングされ得る。例えば、フィード項目の前段部又は補助的ボディ部は、ユーザのニュースフィード内に含まれる場合と、ＣＲＭレコードのレコードフィード内に含まれる場合とで、異なる情報を公開することができる。いくつかの実施例において、公開される情報は、ディスプレイデバイスのタイプに少なくとも部分的に応じて、異なるようにレンダリングされ得る。例えば、スマートフォンではなくラップトップのディスプレイ上に提示される場合には、フィード項目に関して、より多くの情報が公開され得る。

フィード項目は、相互参照されているエンティティのフォロワに伝播され得るが、相互参照されているエンティティのフォロワの全てが、フィード項目を閲覧することを許可されるわけではない。エンティティが親エンティティにアクセスするためのパーミッションを有さない場合にはそのエンティティが相互参照されているフィード項目を閲覧するのを防止するために、方法１６００ｂにおいて、アクセスチェックが実施され得る。いくつかの実施例において、方法１６００ｂは、親エンティティに対するフォロワのアクセスパーミッションを識別すること、及び、フォロワが、親エンティティの情報フィードを閲覧するためのパーミッションを有すると判定することをさらに含み得る。しかしながら、相互参照されているエンティティのフォロワが、親エンティティの情報フィードを閲覧するためのパーミッションを有していないと判定された場合、フォロワは、フィード項目を閲覧することができない。

ＸＶ．データオブジェクトのためのカスタムアクション
図１７は、いくつかの実施例に従って実行される、情報をオンラインソーシャルネットワークの情報フィードに公開するよう構成されたパブリッシャから１以上のデータオブジェクトとインタラクトするための、コンピュータにより実施される方法１７００の一例のフローチャートを示している。図１７は、図３４〜図５１Ｃを参照して説明される。

ブロック１７０４において、１つのコンピューティングデバイス、又は、方法１７００を実行するために協働する任意の数のコンピューティングデバイスは、カスタムアクションを伴うパブリッシャを含むユーザインタフェースを生成するためのデータを提供することができる。カスタムアクションは、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して第１のエンティティにより提供されるカスタムアクション命令に従ってデータオブジェクトとインタラクトするよう構成される。データオブジェクトは、データベースシステムに記憶されている、あるいは、データベースシステムに記憶されるよう構成されている。データオブジェクトは、データベースサービスにより定義されたデータ構造（標準オブジェクト）又はユーザにより定義されたデータ構造（カスタムオブジェクト）を有し得る。

パートナ又は顧客等のユーザ又は組織は、パブリッシャ内に含まれるようにカスタムアクションを定義したいと望むことがある。ユーザ又は組織は、ユーザ又は組織が独自のカスタムアクションを作成することを可能にするフレームワーク又は機能を提供することができるＡＰＩを利用することができる。カスタムアクションは、パブリッシャを通じてデータオブジェクトに関連するデータの処理を可能にする。パブリッシャアクションと同様に、カスタムアクションは、レコードを作成すること、レコードを削除すること、レコードに関連付けられたデータを編集すること、レコードにアクションを記録すること、レコードを変換すること、レコードからデータをダウンロードすること、レコードにデータをアップロードすること、レコードにファイルを添付すること、及びレコードに関連付けられた情報を閲覧すること等のオペレーションを実行することができる。例えば、レコードにアクションを記録する際、カスタムアクションは、電子メールを送信し、次いで、その電子メールをレコードに記録するよう構成され得る、あるいは、カスタムアクションは、ＬｉｎｋｅｄＩｎ（登録商標）及びＴｗｉｔｔｅｒ（登録商標）等の別のオンラインソーシャルネットワークにポストし、次いで、そのポストをレコードに記録するよう構成され得る。カスタムアクションは、レコードのネットワークドメインの外部での挙動を有するアクションを実行することができる。

いくつかの実施例において、カスタムアクションは、組織内の複数のユーザ又は組織に関連付けられた複数のユーザに利用可能にされ得る。代替的又は追加的に、組織等の第１のエンティティにより作成されるカスタムアクションは、他の組織及びユーザによる使用のために提供されてもよい。データベースサービスプロバイダは、カスタムアクション等のアプリケーションを作成するエンティティが、アプリケーションを他のエンティティに自由に配布し、販売し、あるいはアプリケーションを他のエンティティと自由に交換するマーケットプレース又は交換場所（exchange）を提供することができる。

データベースサービスのユーザインタフェースは、ユーザがカスタムアクションを作成することを可能にし得る。カスタムアクションを作成するためのデータベースサービスの例は、ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ（登録商標）により提供されるＦｏｒｃｅ．ｃｏｍ（登録商標）及びＷｏｒｋ．ｃｏｍ（登録商標）を含み得る。ユーザ又は組織はまた、Ｃｈａｔｔｅｒ（登録商標）を含むオンラインソーシャルネットワーク内で新たなカスタムアクションを作成することもできる。ユーザは、宣言的又はプログラム的に、新たなカスタムアクションを作成することができる。

いくつかの実施例において、方法１７００は、コンピューティングデバイスにおいて、ユーザからカスタムアクション命令を受け取ることをさらに含み得る。ここで、カスタムアクション命令は、データオブジェクトを定義するとともに、データオブジェクトに関連付けられる１以上のデータフィールドを定義するよう構成される。クライアントマシンから、ユーザは、データベースサービスにアクセスし、ＡＰＩを利用して、カスタムオブジェクトのクライアントサイドスクリプト命令を作成することができる。いくつかの実施例において、ＡＰＩは、ユーザが、カスタムアクションを伴うパブリッシャを作成するために、ソースコード及びコンピューティング環境への制限されたアクセスを有することを可能にし得る。

図３４は、いくつかの実施例に従った、ユーザがカスタムアクションを作成するよう構成されたデータベースサービスのユーザインタフェースの一例を示している。ユーザは、ドロップダウンタブ「Customize（カスタマイズ）」３４０２を選択し、次いで、ドロップダウンタブ「Accounts（取引先）」３４０４を選択し、次いで、ドロップダウンタブ「Buttons, Links, and Actions（ボタン、リンク、及びアクション）」３４０６を選択することにより、ＡＰＩを用いてカスタムアクションの作成を開始することができる。「Buttons, Links, and Actions（ボタン、リンク、及びアクション）」タブ３４０６を選択することは、ユーザインタフェースに、カスタムアクションの作成に関する情報に加えて、最近作成されたカスタムアクションのリスト３４０８を表示させる。ユーザインタフェースは、新たなカスタムアクションの作成を開始するためのボタン３４１０をさらに含む。

ユーザは、データベースサービスから、ＡＰＩを用いてカスタムアクションの作成を開始することができるが、ユーザは、オンラインソーシャルネットワーク自体の中で、ＡＰＩを用いてカスタムアクションの作成を開始することもできる。図３５は、いくつかの実施例に従った、ユーザがパブリッシャ３５０２からカスタムアクションを作成するよう構成されたパブリッシャ３５０２を含むユーザインタフェースの一例を示している。オンラインソーシャルネットワークにおけるユーザインタフェースは、パブリッシャ３５０２及び情報フィード３５０４を表示することができる。ユーザは、ドロップダウンメニューを生成する、パブリッシャ３５０２内のアクションのレイアウトから「More（さらに）」３５０６を選択し、次いで、ドロップダウンメニューから「Customize（カスタマイズ）」３５０８を選択することにより、カスタムアクションの作成を開始することができる。

ユーザは、任意の数のユーザインタフェースにおいて任意の数の経路（pathway）を用いて、カスタムアクションの作成を開始することができることを理解されたい。例えば、ユーザインタフェース内のパブリッシャから分離されている制御領域（control region）が、ユーザが、タブ、チャンネル、又はボタンを選択して、カスタムアクションの作成を開始することを可能にしてもよい。データベースサービス又はオンラインソーシャルネットワークからの検索クエリツールが、ユーザが、リンクを選択して、カスタムアクションの作成を開始することを可能にする結果を表示してもよい。

カスタムアクションの作成を開始した後、ユーザは、カスタムアクションに関連付けられたカスタムアクション命令を提供することができる。カスタムアクション命令は、データオブジェクトとデータオブジェクトに関連付けられる１以上のデータフィールドとを定義することができる。図３６は、いくつかの実施例に従った、カスタムアクションを作成するためのカスタムアクション定義領域３６０２を含むユーザインタフェースの一例を示している。ユーザインタフェースは、複数のカスタムフィールド３６０４〜３６２０を含むカスタムアクション定義領域３６０２と、ページレイアウト領域３６２２と、を含む。ユーザは、カスタムフィールド３６０４〜３６２０の各々に値を提供することにより、ＡＰＩを利用するカスタムアクション命令を定義することができる。

いくつかの実施例において、ＡＰＩは、データベースサービスプロバイダ等のエンティティにより提供され得、カスタムアクションのオペレーションのうち少なくともいくつかを実行する予め定義された命令のセットを含む。予め定義された命令は、例えば、Ｊａｖａｓｃｒｉｐｔ（登録商標）、Ｊａｖａ（登録商標）、Ａｐｅｘ、又は、カスタムアクションのオペレーションのうち少なくともいくつかを実装するための任意の他のプログラミング言語において提供され得る。このようなオペレーションは、多くのカスタムアクション又は全てのカスタムアクションに共通する可能性が高いオペレーションを含み得る。例えば、そのような命令は、カスタムアクションを表示するためのユーザインタフェースの領域を作成することに関与するもの、クライアントマシンからのカスタムアクションがトリガしたメッセージの受信を処理することに関与するもの、アップデートされたカスタムアクションメッセージをクライアントマシンに送信することに関与するもの、及び他のそのようなオペレーションであり得る。

したがって、ユーザは、図３６のカスタムフィールド３６０４〜３６２０に定義を提供して、ＡＰＩとインタラクトするカスタムアクション命令を提供することができる。カスタムアクション命令は、ＡＰＩに提供されている予め定義された命令と直接的に統合され得る。

カスタムアクション命令における定義のうちの１つは、Object Name（オブジェクト名）３６０４を含み得る。いくつかの実施例において、カスタムアクションの作成を開始したソースに基づいて、デフォルト値が提供され得る。カスタムアクション命令における別の定義は、Action Type（アクションタイプ）３６０６を含み得る。Action Type（アクションタイプ）３６０６は、データオブジェクトとインタラクトするために実行されるアクションのタイプを示す値を表示する。いくつかの実施例において、Action Type（アクションタイプ）３６０６は、データオブジェクトとインタラクトすることに限定されるものではなく、サードパーティアプリケーション又はコンテンツを公開すること等の他のアクションも含み得る。そのようなアクションはセクションＸにおいてより詳細に説明されている。いくつかの実施例において、ユーザは、Action Type（アクションタイプ）３６０６において、とりわけ、Create a Record（レコードを作成する）、Create a Custom Page（カスタムページを作成する）（例えば、カスタムＶｉｓｕａｌｆｏｒｃｅページ）、及びUpdate a Record（レコードをアップデートする）等の可能な値のリストから選択することができる。他の可能なアクションは、Log a Call（要求のログを取る）、Send Email（電子メールを送信する）、Send SMS（ＳＭＳを送信する）、Change Status（ステータスを変更する）、Social Post（ソーシャルポスト）、Canvas、及びAuraを含み得る。

カスタムアクション命令におけるさらなる定義は、Target Object（ターゲットオブジェクト）３６０８を含み得る。Target Object（ターゲットオブジェクト）３６０８は、カスタムアクションがインタラクトするよう構成されるデータオブジェクトを表す。いくつかの実施例において、Target Object（ターゲットオブジェクト）３６０８内に提供される値は、親レコードの子レコードを含む。子レコード及び親レコードは、リード、案件、取引先、商談、タスク、連絡先、キャンペーン、契約、イベント、カスタムオブジェクト、及びＶｉｓｕａｌｆｏｒｃｅページ等のＣＲＭオブジェクトであり得る。カスタムアクション命令における他の定義は、Record Type（レコードタイプ）３６１０、Relationship Field（関連フィールド）３６１２、Label（ラベル）３６１４、API Name（ＡＰＩ名）３６１６、Description（説明）３６１８、及びIcon（アイコン）３６２０を含み得る。カスタムフィールドのうちのいくつかの表示は、Action Type（アクションタイプ）３６０６に依存し得る。図３６において、Action Type（アクションタイプ）３６０６を「Create a Record（レコードを作成する）」に定義することは、ユーザインタフェースにカスタムフィールド３６０８〜３６１６を表示させる。

さらに、ユーザは、ページレイアウト領域３６２２内で、カスタムアクションが現れるページを定義することにより、さらなるカスタムアクション命令を提供することができる。したがって、カスタムアクションは、オンラインソーシャルネットワークにおける指定されたページ上でアクセス可能であり得る。

図１７の方法１７００に戻ると、ブロック１７０４におけるカスタムアクションを伴うパブリッシャを含むユーザインタフェースを生成するためのデータは、カスタムアクションがユーザインタフェース内に表示されるかどうかを判定し得る。このデータは、上述したように、カスタムアクションが提供されるページに関するカスタムアクション命令を含み得る。加えて、このデータは、カスタムアクションにアクセスするためのパーミッションを有するエンティティに関するカスタムアクション命令を含み得る。カスタムアクションは、組織内の全てのユーザに提供され得る。代替的に、カスタムアクションは、グループ等の複数人のユーザの特定のサブセットに限定されてもよい。

カスタムアクション命令はまた、データオブジェクトに関連付けられる１以上のデータフィールドを定義するよう構成され得る。図３７Ａは、いくつかの実施例に従った、カスタムアクションに関連付けられたデータフィールド３７１０を表示しているアクションレイアウトエディタ３７０２用のユーザインタフェースの一例を示している。データフィールド３７１０の各々は、データオブジェクトに提供される情報を表すことができる。いくつかの実施例において、この情報はユーザから生成され得る。いくつかの実施例において、この情報はマシン又はシステムから生成され得る。データフィールド３７１０のうちのいくつかはまた、入力の必須フィールドであるよう構成され得る。

「Fields（フィールド）」オプション３７０６を選択することにより、ユーザは、アクションレイアウトエディタ３７０２を用いて、カスタムアクションに関連付けられるようデータフィールド３７１０を構成することができる。アクションレイアウトエディタ３７０２は、カスタムアクションに関連付けられ得る複数の利用可能なフィールド３７０４を含む。利用可能なフィールド３７０４の例は、とりわけ、First Name（名）、Last Name（姓）、Phone（電話番号）、Email（電子メールアドレス）、Birthday（誕生日）、Last Modified（最終変更）、Created By（作成者）、Opportunity Name（商談名）、Account Name（取引先名）、Next Step（次のステップ）、Amount（数量）、Close Date（クローズ日）、Stage（段階）、及びDescription（説明）を含む。

利用可能なフィールド３７０４は、利用可能なフィールド３７０４のうちの１つをカスタマイズ可能なパブリッシャスペース３７０８にドラッグアンドドロップすることにより、カスタムアクションに関連付けられたデータフィールド３７１０になり得る。図３７Ｂは、さらなるデータフィールド３７１２がカスタムアクションに関連付けられているアクションレイアウトエディタ３７０２用のユーザインタフェースの一例を示している。ユーザは、データフィールド３７１０のアクションレイアウトを決定するために、さらなるデータフィールド３７１２をカスタマイズ可能なパブリッシャスペース３７０８内に配置させることができる。いくつかの実施例において、パブリッシャスペース３７０８内に配置され得るデータフィールド３７１０の数又はタイプを制限するために、制限を管理することが課せられ得る。

アクションレイアウトは、パブリッシャ内でのデータフィールドの配置を表す。カスタムアクションのアクションレイアウトは、ＡＰＩに応じて異なり得る。図３８Ａは、いくつかの実施例に従った、カスタムアクションに関連付けられたデータフィールド３８１０ａの表示をプレビューしているウィンドウの一例を示している。ここで、カスタマイズ可能なパブリッシャスペース３８０８ａ内でのデータフィールド３８１０ａの配置が、２列の配置で示されている。データフィールド３８１０ａのこの配置は、デスクトップディスプレイデバイス、ラップトップディスプレイデバイス、又はタブレットディスプレイデバイス等の、ワイドスクリーンを有するディスプレイデバイスにおいて表示するのに有用であり得る。

図３８Ｂは、他の実施例に従った、カスタムアクションに関連付けられたデータフィールド３８１０ｂの表示をプレビューしているウィンドウの一例を示している。ここで、カスタマイズ可能なパブリッシャスペース３８０８ｂ内でのデータフィールド３８１０ｂの配置が、１列の配置で示されている。データフィールド３８１０ｂのこの配置は、スマートフォンディスプレイデバイス又は他のモバイルディスプレイデバイス等の、ナロースクリーンを有するディスプレイデバイスにおいて表示するのに有用であり得る。

カスタムアクション命令はまた、パブリッシャ内でのカスタムアクションのページレイアウトを定義するよう構成され得る。図３９は、いくつかの実施例に従った、レコードに関連付けられたパブリッシャアクション３９０８を表示しているページレイアウトエディタ３９０２用のユーザインタフェースの一例を示している。パブリッシャアクション３９０８の各々は、データオブジェクトに対して実行され得る、あるいはデータオブジェクトを参照して実行され得るアクションを表す。

「Actions（アクション）」オプション３９０６を選択することにより、ユーザは、ページレイアウトエディタ３９０２を用いて、特定のページレイアウト用にパブリッシャアクション３９０８を構成することができる。ページレイアウトは、異なるレコード、グループ、ユーザ、及び組織用のページに対して異なり得る。例えば、連絡先を作成するためのパブリッシャアクション３９０８は、パートナ取引先ページ上には表示され得るが、顧客取引ページ上には表示されない。ページレイアウトエディタ３９０２は、ページレイアウトに含まれ得る複数の利用可能なアクション３９０４を含む。利用可能なアクション３９０４の例は、とりわけ、Contact（連絡先）、File（ファイル）、Link（リンク）、Log a Call（要求のログを取る）、Opportunity（商談）、Polls（投票）、Post（ポスト）、Task（タスク）、及びThanks（感謝）を含む。

利用可能なアクション３９０４は、利用可能なアクション３９０４のうちの１つをパブリッシャのページレイアウトにドラッグアンドドロップすることにより、パブリッシャアクション３９０８になり得る。利用可能なアクション３９０４のうちの１つは、カスタムアクション３９１０であり得る。ユーザは、パブリッシャ内でのカスタムアクション３９１０のページレイアウトを決定するために、１以上のパブリッシャアクション３９０８の間にカスタムアクション３９１０を配置させることができる。ページレイアウトは、パブリッシャ内でのパブリッシャアクション３９０８に対するカスタムアクション３９１０の配置を表し得る。パブリッシャアクション３９０８用の領域は、パブリッシャの特定の領域に制限され得る。パブリッシャアクション３９０８を制限された領域に制限することにより、パブリッシャアクション３９０８が、パブリッシャの残りの領域がどのように表示されるかを変更するのを防止することができる。

図４０は、いくつかの実施例に従った、詳細４００６、ページレイアウト４００８、及び、カスタムアクションに関連付けられた予め定められたフィールド値４０１０を表示しているユーザインタフェースの一例を示している。カスタムアクションを作成した後、ユーザは、ページ４００２にアクセスして、カスタムアクションに関する情報を閲覧することができる。ユーザは、複数のボタン４００４のうちの１つを選択して、カスタムアクションのアクションレイアウトを編集することができる、あるいは、カスタムアクションを編集、複製、又は削除することができる。詳細４００６は、カスタムアクションのカスタムフィールドに提供された定義を表示する。ページレイアウト４００８は、カスタムアクションが現れる指定のページを表示する。予め定められたフィールド値４０１０は、予め定められた値又はデフォルト値を有するデータフィールドを表示する。ユーザは、New（新たに追加）ボタン４０１２を選択することにより、新たな予め定められた値又はデフォルト値を追加することができ、Edit（編集）リンク４０１４を選択することにより、指定されたデータフィールドにおける予め定められた値又はデフォルト値を編集することができ、あるいは、Del（削除）リンク４０１６を選択することにより、指定されたデータフィールドにおける以前の予め定められた値又はデフォルト値を削除することができる。

図４１は、いくつかの実施例に従った、カスタムアクションに関連付けられた予め定められたフィールド値を編集又は追加するためのユーザインタフェースの一例を示している。ユーザは、複数のデータフィールドから１つのデータフィールド４１０２を選択して、予め定められた値又はデフォルト値を指定することができる。ユーザは、フィールドスペース４１０４内で値を定めることができる。ここで、この値は、単語、語句、文、質問、感情表現、及び／又は記号等の英数字の入力又は他の文字ベースの入力であり得る。しかしながら、フィールドスペース４１０４内で定められる値は、変数であってもよい。ユーザは、関数４１０６をフィールドスペース４１０４に追加して、値又は変数に対して関数を実行することができる。

データフィールド用の予め定められた値又はデフォルト値を設定することにより、パブリッシャからカスタムアクションを開始するいかなるユーザにも、データフィールドにおける予め定められた値又はデフォルト値がすでに提供されていることになる。いくつかの実施例において、データフィールドにおける予め定められた値又はデフォルト値は、変更することができない。

いくつかのカスタムアクションは、アクセスされているページ又はユーザアクセスパーミッションに応じてユーザインタフェース内での表示に制限され得るが、いくつかのアクションは、そのように制限されなくてもよい。そのようなアクションは、グローバルアクションと呼ばれ得る。図４２〜図４４は、グローバルアクションを作成する異なる態様のユーザインタフェースを示している。

図４２は、いくつかの実施例に従った、ユーザがグローバルアクションを作成するよう構成されたデータベースサービスのユーザインタフェースの一例を示している。ユーザは、ドロップダウンタブ「Create（作成）」４２０２を選択し、次いで、ドロップダウンタブ「Global Actions（グローバルアクション）」４２０４を選択することにより、ＡＰＩを用いてグローバルアクションの作成を開始することができる。「Global Actions（グローバルアクション）」タブ４２０４を選択することは、ユーザインタフェースに、グローバルアクションの作成に関する情報に加えて、最近作成されたグローバルアクションのリスト４２０８を表示させる。ユーザインタフェースは、新たなグローバルアクションの作成を開始するためのボタン４２１０をさらに含む。ユーザは、任意の数のユーザインタフェースにおいて任意の数の経路を用いて、グローバルアクションの作成を開始することができることを理解されたい。

グローバルアクションの作成を開始した後、ユーザは、グローバルアクションに関連付けられたグローバルアクション命令を提供することができる。図４３は、いくつかの実施例に従った、グローバルアクションを作成するためのグローバルアクション定義領域４３０２を含むユーザインタフェースの一例を示している。グローバルアクション命令の提供は、本明細書で先に説明されているカスタムアクション命令の提供と同じやり方で又は同様のやり方で行うことができる。しかしながら、グローバルアクションは、オンラインソーシャルネットワークにおける所定のページに必ずしも限定されるものではなく、詳細ページ、ホームページ、及びＣｈａｔｔｅｒ（登録商標）ページを含むより広範なページにわたって表示され得る。

ユーザインタフェースは、グローバルアクション定義領域４３０２を含み、グローバルアクション定義領域４３０２は、複数のグローバルフィールド４３０４〜４３１２を含む。グローバルアクション定義領域４３０２内のグローバルフィールド４３０４〜４３１２の数は、カスタムアクションを作成するためのカスタムフィールドの数よりも少なくてよい。なぜならば、ユーザは、関連性及び他の情報を指定する必要がないからである。

ユーザはまた、ページレイアウト領域４３１４内で、グローバルアクションが現れるページを定義することにより、さらなるグローバルアクション命令を提供することができる。ここで、選択することができるページは、操作されるデータオブジェクトと親子関係を有するページに限定されるものではなく、選択することができるページは、オンラインソーシャルネットワークにわたるページを含む。

グローバルアクション命令は、パブリッシャ内でのグローバルアクションのページレイアウトを定義するよう構成され得る。図４４は、いくつかの実施例に従った、オンデマンドデータベースサービス環境に関連付けられたパブリッシャアクション４４０８を表示しているページレイアウトエディタ４４０２用のユーザインタフェースの一例を示している。パブリッシャアクション４４０８の各々は、オンラインソーシャルネットワークにわたる複数のページのいずれかから、データオブジェクトに対して実行され得る、あるいはデータオブジェクトを参照して実行され得るアクションを表す。

「Actions（アクション）」オプション４４０６を選択することにより、ユーザは、ページレイアウトエディタ４４０２を用いて、パブリッシャアクション４４０８を構成することができる。ページレイアウトエディタ４４０２は、パブリッシャ内に含まれ得る複数の利用可能なアクション４４０４を含む。利用可能なアクション４４０４は、利用可能なアクション４４０４のうちの１つをパブリッシャのページレイアウトにドラッグアンドドロップすることにより、パブリッシャアクション４４０８になり得る。ユーザは、パブリッシャのページレイアウトを決定するために、１以上のパブリッシャアクション４４０８の間に利用可能なアクション４４０４を配置させることができる。

図４５は、いくつかの実施例に従った、パブリッシャ内に表示されるパブリッシャアクションを選択するためのウィンドウ４５０２の一例を示している。ユーザは、ホームページ、又は、ユーザがパブリッシャアクションの表示をカスタマイズするためのパーミッションを有するページからウィンドウ４５０２を開くことにより、パブリッシャ内に表示されるパブリッシャアクションをカスタマイズすることができる。ユーザは、利用可能なアクション４５０４のプールから選択済みアクション４５０６のプールにパブリッシャアクションを追加することができる。同様に、ユーザは、選択済みアクション４５０６から利用可能なアクション４５０４の領域にパブリッシャアクションを除去することができる。

図４６Ａ〜図４６Ｂは、いくつかの実施例に従った、モバイルデバイスアプリケーション用の、カスタムアクション４６０６を伴うパブリッシャ４６０２と情報フィード４６０４とを含むユーザインタフェースの一例を示している。パブリッシャ４６０２内のカスタムアクション４６０６は、ＡＰＩとインタフェースをとって、情報を情報フィード４６０４に公開することができる。モバイルアプリケーション及び様々な他のアプリケーションは、同じＡＰＩと通信して、パブリッシャの同じ基本機能を実行することができる。

パブリッシャ４６０２は、複数のパブリッシャアクション４６０６を含む。いくつかの実施例において、パブリッシャアクション４６０６のうちの少なくとも１つは、カスタムアクションであり得る。いくつかの実施例において、パブリッシャ４６０２の上に指を乗せ、パブリッシャ４６０２を横方向にスライドさせることにより、さらなるパブリッシャアクション４６０６にアクセスすることができる。ユーザインタフェース内のボタン４６０８により、ユーザは、パブリッシャアクション４６０６を表示させること、又はパブリッシャアクション４６０６を隠すことが可能になり得る。実際、ボタン４６０８は、管理者によりインストール／構成されたアクションの予め定められたリストからのアクションを含むより多くのパブリッシャアクションを表示させるよう構成される。

いくつかの実施例において、カスタムアクションは、組織内の複数のユーザ又は組織に関連付けられた複数のユーザに利用可能にされ得る、あるいは、他の組織及びユーザによる使用のために提供され得る。Appexchange（アプリケーション交換）カスタムアクション４６１０は、カスタムアクション等のアプリケーションを作成するユーザが、アプリケーションを他のエンティティに自由に配布し、販売し、あるいはアプリケーションを他のエンティティと自由に交換することを可能にし得る。

図１７に戻ると、ブロック１７０８において、データオブジェクトとインタラクトするリクエストが、第２のエンティティから、ユーザインタフェース内のカスタムアクションの選択を介して、受信される。いくつかの実施例において、第２のエンティティは、第１のエンティティとは異なるユーザ又は組織である。いくつかの実施例において、第２のエンティティは、第１のエンティティと同じユーザ又は組織である。

方法１７００は、第２のエンティティがデータオブジェクトとインタラクトするためのパーミッションを有するかどうかを判定することをさらに含み得る。第２のエンティティのアクセスパーミッションに応じて、第２のエンティティがインタラクトできるデータオブジェクトに対して制限が課せられ得る。そのような制限は、例えば、とりわけ、システム管理者、データオブジェクトの所有者、又は組織のセキュリティ／パーミッションポリシにより設定され得る。

いくつかの実施例において、データオブジェクトとインタラクトするリクエストは、データオブジェクトを作成するリクエスト、データオブジェクトを削除するリクエスト、データオブジェクトをアップデートするリクエスト、データオブジェクトを変換するリクエスト、データオブジェクトからデータをダウンロードするリクエスト、データオブジェクトにデータをアップロードするリクエスト、データオブジェクトにファイルを添付するリクエスト、データオブジェクトに関連付けられた情報を閲覧するリクエスト、及びデータオブジェクトを参照するオペレーションを他の形で実行するリクエストを含み得る。

データオブジェクトとインタラクトするリクエストは、ユーザがユーザインタフェース内のカスタムアクションを選択したことに応じて生成され得る。いくつかの実施例において、カスタムアクションの選択は、パブリッシャ内に表示されているユーザインタフェースコンポーネントからのユーザ入力から生じてもよい。パブリッシャ内に表示されているそのようなユーザインタフェースコンポーネントの選択の例は、図２１Ｂ、図２４、及び図２８〜図３０に示されるパブリッシャアクション又はカスタムアクションを含む。さらに、ユーザインタフェースコンポーネントは、カスタマイゼーションツールから作成されたカスタマイズされたグラフィカルユーザインタフェースの一部であり得る。パートナ又は顧客は、Ｖｉｓｕａｌｆｏｒｃｅ等のカスタマイゼーションツールを用いて、自分の好みに応じて、ユーザインタフェースコンポーネント及びパブリッシャのビジュアル表現をカスタマイズすることができる。そのようなカスタマイゼーションツールは、ユーザが、オンデマンドサービス環境によりネイティブにホストされ得るカスタムユーザインタフェースを構築することを可能にするフレームワークを提供することができる。Ｖｉｓｕａｌｆｏｒｃｅのようなカスタマイゼーションツールを利用するユーザは、カスタマイズされたユーザインタフェースコンポーネントをパブリッシャに追加することができる。したがって、パブリッシャは、レコードとの全てのユーザインタラクションのためのインタフェースとして機能することができ、異なるアクションを要する異なるアプリケーション、デバイス、又はウィンドウの必要性をなくすことができる。

いくつかの実施例において、カスタムアクションの選択は、パブリッシャの外部に表示されているユーザインタフェースコンポーネントからのユーザ入力から生じてもよい。パブリッシャの外部に表示されているそのようなユーザインタフェースコンポーネントの選択の例は、図４７Ａ〜図４７Ｂ及び図４８Ａ〜図４８Ｂの実行可能なセレクションを含む。

図４７Ａ〜図４７Ｂは、いくつかの実施例に従った、オンデマンドデータベースサービス環境のためのデータベースシステム内を検索するためのルックアップツール４７０２の一例を示している。ユーザは、ルックアップクエリを実行するために、英数字の入力又は他の文字ベースの入力をボックス４７０４に提供することができる。いくつかの実施例において、ルックアップクエリが送信された後、結果のリストが表示され得る。例えば、ルックアップクエリは、ユーザのリスト、組織のリスト、グループのリスト、又はレコードのリストを返させることができる。ユーザは、ユーザインタフェースコンポーネント（図示せず）を選択して、ユーザ、組織、グループ、及びレコードのうちの１つに対してアクションを実行することができる、あるいは、ユーザ、組織、グループ、及びレコードのうちの１つを参照してアクションを実行することができる。いくつかの実施例において、ルックアップクエリは、結果を返させないこともあり、ユーザは、ユーザインタフェースコンポーネント（図示せず）を選択して、レコード等の新たなエンティティを作成することができる。例えば、図４７Ｂにおいて、ルックアップクエリが結果を返させなかった結果として、ユーザは、新たな連絡先を作成することを選択し、複数のデータフィールド４７０６とともにパブリッシャをユーザインタフェース内に表示させることができる。

図４８Ａ〜図４８Ｂは、いくつかの実施例に従った、オンデマンドデータベースサービス環境におけるデータベースシステム内を検索するための検索クエリツール４８０２の一例を示している。ユーザインタフェースから、ユーザは、英数字の入力又は他の文字ベースの入力をボックス４８０４に提供することができる。いくつかの実施例において、ユーザが検索クエリのための入力を提供しているときに、オートコンプリートオペレーションに従って、結果が同時に表示され得る。代替的又は追加的に、検索クエリが送信された後、結果が表示されてもよい。いくつかの実施例において、検索クエリは、アクション４８０６のリストを返させることができる。ユーザは、それらアクション４８０６のうちの１つを選択して、複数のデータフィールド４８０８とともにパブリッシャをユーザインタフェース内に表示させることができる。

図１７に戻ると、ブロック１７１２において、データオブジェクトに関連付けられた１以上のデータフィールドのための第１の情報が、パブリッシャから、１以上のコンピューティングデバイスにおいて受信される。データオブジェクトは、データベースシステムに記憶されていてもよいし、データベースシステムに記憶されるよう構成されていてもよい。第１の情報は、ブロック１７０８においてデータオブジェクトとインタラクトすることをリクエストしたユーザにより提供され得る。第１の情報は、例えば、図１Ａ及び図１Ｂにおける信号ネットワーク１４を介して、方法１７００を実行する１以上のコンピューティングデバイスに伝送され得る。

いくつかの例において、所定の入力の妥当性を検証するために、妥当性検証ルールが、１以上のデータフィールドに対して実施され得る。図４９は、いくつかの実施例に従った、パブリッシャアクション４９０６用の複数のデータフィールド４９０４を表示しているパブリッシャ４９０２を含むユーザインタフェースと、１以上のデータフィールドに関連付けられた妥当性検証ルールと、の一例を示している。１以上のコンピューティングデバイスは、閾値に対する、データフィールド４９０４の各々に提供された値の妥当性検証チェックを実行することができる。閾値は、エンティティにより、１以上のデータフィールドを定義するカスタムアクション命令内に提供され得る。データフィールド４９０４のうちの１つに提供された値が、閾値のセットと比較され得、この値が閾値のセットを満たすと判定された場合、この値は有効である。例えば、図４９において、Close Date（クローズ日）４９０８に対しては、カレンダ日付（calendar date）に関する妥当性検証ルールが設定され得、このカレンダ日付は将来でなければならない。さらに、Early Field Indicator（アーリーフィールドインジケータ）４９１０には、何らかの値が入力されなければならないという妥当性検証ルールが設定され得る。

図１７に戻ると、ブロック１７１６において、データベースシステムが、データオブジェクトに関連付けられた１以上のデータフィールドのための第１の情報に基づいてアップデートされる。データオブジェクトに対するアップデートは、データオブジェクトの作成、データオブジェクトの削除、データオブジェクトに関連付けられたデータを編集すること、データオブジェクトに関連付けられたアクションのログを取ること、データオブジェクトの変換、データオブジェクトからデータをダウンロードすること、データオブジェクトにデータをアップロードすること、データオブジェクトへのファイルの添付、データオブジェクトに関連付けられた情報の閲覧、及びデータオブジェクトを参照するオペレーションを他の形で実行することを含み得る。すなわち、ブロック１７１６におけるデータオブジェクトに関連付けられた第１の情報を使用して、ブロック１７０８におけるリクエストされたインタラクションを実行する。例えば、第１の情報を受信すると、１以上のコンピューティングデバイスは、データベースシステムにおいて、データオブジェクトを表す行を、テーブル内で作成又はアップデートさせることができる。

ブロック１７２０において、アップデートに関連付けられたフィード項目が、ユーザインタフェース内の情報フィードに含まれるように提示される。フィード項目は、情報フィード内にアップデートされたデータの少なくとも一部を提示するためのビジュアルフィードバック要素を提供する。フィード項目内に提示されるデータは、１以上のコンテキストファクタに依存し得る。いくつかの例において、フィード項目は、データオブジェクトへの参照を提供する実行可能なセレクションを含み得る。本明細書で先に説明されたように、同じフィード項目が、相互参照により、他の関連フィード内に伝播され得る。

カスタムアクションは、サードパーティにより提供され、上述した一連のステップの一部を実行するよう構成されてもよい。サードパーティにより提供され得るカスタムアクションの一例は、Bug（バグ）カスタムアクションである。図５０Ａは、いくつかの実施例に従った、バグのログを取るためのパブリッシャ５００２の一例を示している。図５０Ｂは、いくつかの実施例に従った、図５０Ａにおいて提供されたパブリッシャデータ５００４から作成された対応するフィード項目５０１４の一例を示している。Bug（バグ）カスタムアクション５００６を用いて、ユーザは、パブリッシャ５００２からレコードを作成し、情報をフィード項目５０１４として情報フィードに公開することができる。そのような情報は、Subject（題）、Frequency（頻度）、Impact（影響度）、Found In（見つけられた場所）、及びProduct Tag（製品タグ）等のパブリッシャデータ５００４を含み得る。パブリッシャ５００２はまた、フィード項目５０１４に付随させるメッセージをポストするためのテキストボックス５００８、パブリッシャデータ５００４をそれぞれのフィードに公開する特定のエンティティを選択するためのドロップダウンメニュー５０１２、及びパブリッシャデータ５００４を公開するためのShare（共有）ボタン５０１０を含み得る。

サードパーティにより提供され得るカスタムアクションの別の例は、Expense Report（経費報告）カスタムアクションである。図５１Ａは、いくつかの実施例に従った、経費報告書をファイルするためのパブリッシャ５１０２の一例を示している。図５１Ｂは、いくつかの実施例に従った、図５１Ａにおいて提供されたパブリッシャデータ５１０４からの対応するフィード項目５１１４を示している。図５１Ｃは、いくつかの実施例に従った、図５１Ａにおいて提供されたパブリッシャデータ５１０４からの別の対応するフィード項目５１１６を示している。Expense Report（経費報告）カスタムアクション５１０６を用いて、ユーザは、パブリッシャ５１０２から、承認のために経費報告書を送信することができる。パブリッシャデータ５１０４は、Name（名前）、Policy（ポリシ）、Purpose（目的）、Amount（額）、Item（項目）、及びReceipt（領収書）を含み得る。いくつかの例において、パブリッシャは、Ｃｏｎｃｕｒ（登録商標）等のアプリケーションと通信して、パブリッシャデータ５１０４の値を取得することができる。領収書が添付され、パブリッシャデータ５１０４とともに送信され得る。パブリッシャはまた、フィード項目５１１４及び５１１６に付随させるメッセージをポストするためのテキストボックス５１０８、パブリッシャデータ５１０４をそれぞれのフィードに公開する特定のエンティティを選択するためのドロップダウンメニュー５１１２、及びパブリッシャデータ５１０４を公開するためのShare（共有）ボタン５１１０を含み得る。

ＸＶＩ．アプリケーションプログラミングインタフェースを介したパブリッシャにおけるアプリケーションとのインタラクション
図１８は、いくつかの実施例に従って実行される、オンラインソーシャルネットワークにおいてパブリッシャを用いてアプリケーションとインタラクトするための、コンピュータにより実施される方法１８００の一例のフローチャートを示している。図１８は、図５２〜図５６Ｃを参照して説明され得る。ブロック１８０４において、パブリッシャ及び情報フィードを含むユーザインタフェースを生成するためのデータが提供される。ここで、パブリッシャは、情報を情報フィードに公開するよう構成される。いくつかの実施例において、ユーザインタフェースはまた、カスタムアクションを含み得る。カスタムアクションは、カスタムアクション命令に従ってデータオブジェクト又はアプリケーションとインタラクトするよう構成され得る。カスタムアクション命令は、第１のエンティティにより、ＡＰＩを介して提供され得る。いくつかの実施例において、第１のエンティティは、データベースサービスを複数の受領者（recipient）に提供するデータベースサービスプロバイダであり得る。いくつかの実施例において、第１のエンティティは、ユーザ又は組織であり得る。

図５２は、Ｖｉｓｕａｌｆｏｒｃｅページとともにカスタムアクションを作成するためのカスタムアクション定義領域５２０２を含むユーザインタフェースの一例を示している。Ｖｉｓｕａｌｆｏｒｃｅ等のカスタマイゼーションツールは、ユーザが、オンデマンドサービス環境においてネイティブにホストされ得るカスタムユーザインタフェースを構築することを可能にする。ユーザインタフェースを宣言的に定義するのではなく、カスタマイゼーションツールは、ユーザが、ユーザインタフェースをプログラム的にカスタマイズすることを可能にする。例えば、ユーザは、ページ上に含まれるべきユーザインタフェースコンポーネントと、そのようなユーザインタフェースコンポーネントがどのように現れるべきであるかと、をカスタマイズすることができる。ユーザは、Ｖｉｓｕａｌｆｏｒｃｅタグ、ＨＴＭＬ、Ｊａｖａｓｃｒｉｐｔ（登録商標）、又は他のウェブ対応コードを編集することができる。さらに、ユーザは、ユーザインタフェース内のカスタムアクションを選択すると開始されるカスタムアクション命令をカスタマイズすることができる。ユーザがユーザインタフェースに追加できるカスタムアクションの例は、例に過ぎないが、インスタントメッセンジャ、ナレッジアーティクル（knowledge article）、ライブチャット、ｔｗｉｔｔｅｒ（登録商標）、バーチャル掲示板（virtual bulletin board）、電子メール、要求のログを取ること、ポータルアンサー（portal answer）、又は同様のものを含み得る。

図５２において、ユーザインタフェースは、カスタムアクション定義領域５２０２を含み、カスタムアクション定義領域５２０２は、複数のカスタムフィールド５２０４〜５２１８を含む。ユーザは、カスタムフィールド５２０４〜５２１８の各々に値を提供することにより、カスタムアクション命令を定義することができる。Custom Action（カスタムアクション）５２０６を選択することにより、ユーザは、Custom Action（カスタムアクション）５２０６に関連付けるＶｉｓｕａｌｆｏｒｃｅページ５２０８を特定することができる。Ｖｉｓｕａｌｆｏｒｃｅページ５２０８は、Account（取引先）５２０４について案件を作成するためにエンティティにより以前に定義されたものであり得る。ユーザは、Height（高さ）５２１０、Label（ラベル）５２１２、Name（名前）５２１４、Description（説明）５２１６、及びIcon（アイコン）５２１８に値を提供することにより、Ｖｉｓｕａｌｆｏｒｃｅページ５２０８をさらに定義することができる。

Ｖｉｓｕａｌｆｏｒｃｅページ５２０８の選択は、カスタマイズされたユーザインタフェースを生成するためのプログラムされた命令のセットを参照する。この命令は、例えば、Ｊａｖａｓｃｒｉｐｔ（登録商標）、Ｊａｖａ（登録商標）、Ａｐｅｘ、又は任意の他のプログラミング言語において提供され得る。Ｖｉｓｕａｌｆｏｒｃｅ等のカスタマイゼーションツールを使用することにより、ユーザは、パブリッシャ、カスタムアクション、及び情報フィードを含むユーザインタフェースの全体的なレイアウト及び外観を決定し得るとともに、様々なユーザインタフェースコンポーネントにより実行されるオペレーションを決定し得る命令を提供することが可能になり得る。

図５３Ａは、カスタマイズされたＶｉｓｕａｌｆｏｒｃｅページレイアウト５３００ａを伴うレコードの一例を示している。Ｖｉｓｕａｌｆｏｒｃｅは、異なるタグが異なるユーザインタフェースコンポーネントを表し得るマークアップ言語から構成される。そのようなＶｉｓｕａｌｆｏｒｃｅページレイアウト５３００ａを作成するための命令の例が、以下に示される。

図５３Ａの例に示されるように、Ｖｉｓｕａｌｆｏｒｃｅページレイアウト５３００ａ用のユーザインタフェースは、パブリッシャ５３０２及び情報フィード５３０４を含み得る。ユーザは、電子メールパブリッシャ、要求ログパブリッシャ、及びポータルアンサーパブリッシャであることが可能なパブリッシャ５３０２をカスタマイズすることができる。すなわち、パブリッシャ５３０２は、顧客に電子メールを送信し、要求のログを取り、ウェブポータルを介して問合せに回答するよう構成されたカスタムアクション５３０６を含み得る。情報フィード５３０４等のコンポーネントをホストする、ページレイアウト５３００ａ内のパブリッシャ５３０２及び他のフレームのレイアウト及び寸法は、第１のエンティティの好みに従って、カスタムアクション命令内に定義され得る。

図５３Ｂは、カスタマイズされたＶｉｓｕａｌｆｏｒｃｅアクションレイアウト５３００ｂを伴うパブリッシャ５３０２の一例を示している。ユーザは、指定された受信者に電子メールを送信し、電子メールメッセージを情報フィードに公開するよう構成された電子メールパブリッシャとしてパブリッシャ５３０２を定義することができる。ユーザは、パブリッシャ５３０２内のデータフィールドをプログラム的に定義することができる。ユーザが、Email Customer（顧客に電子メールを送信する）のパブリッシャアクション５３０６を選択すると、パブリッシャ５３０２に、送信者フィールド５３０８、受信者フィールド５３１０、件名フィールド５３１２、及びメッセージフィールド５３１４を含むデータフィールドを表示させる。データフィールドの各々における可視性（visibility）及びデフォルト値は、プログラム的に設定され得る。したがって、ユーザ又は組織は、パブリッシャ５３０２を介して送信されるデータの標準性（standardization）を高めるようパブリッシャ５３０２をカスタマイズすることができる。パブリッシャ５３０２はまた、添付ボタン５３１６を介してファイルを添付するための機能、テンプレートボタン５３１８を介してテンプレートを選択するための機能、及び送信ボタン５３２０を介して電子メールを送信するための機能を含み得る。

いくつかの実施例において、表示されるユーザインタフェースは、エンティティのアクセスパーミッション、レコードのタイプ、ページのタイプ、ディスプレイデバイスのタイプ等を含むコンテキストファクタに依存し得る。例えば、どのデータフィールドが表示されるか、どのパブリッシャアクションが利用可能であるか、及びユーザインタフェースコンポーネントのレイアウトは、ユーザインタフェースを移動しているエンティティのタイプに依存し得る。

ユーザインタフェースは、ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ（登録商標）により提供されるもの等のＡＰＩを宣言的に利用するカスタムアクション命令、又は、独自のＡＰＩ及び予め定義された命令のセットを提供し得るＶｉｓｕａｌｆｏｒｃｅ等のカスタマイゼーションツールをプログラム的に利用するカスタムアクション命令により定義され得る。技術的スキルをそれほど有していないユーザは、ユーザインタフェースを宣言的に開発することができるのに対し、より複雑なデータ管理の必要性があるユーザ又は組織は、ユーザインタフェースをカスタマイズするのにカスタマイゼーションツールを選択することができる。

図１８に戻ると、ブロック１８０８において、パブリッシャを用いてアプリケーションを公開するリクエストが受信される。アプリケーションを公開するリクエストは、ユーザが、パブリッシャ内のボタン、リンク、タブ、又は他のメニューセレクションを選択したことに応じて、ユーザのスマートフォン、デスクトップコンピューティングデバイス、ラップトップコンピューティングデバイス、タブレットコンピューティングデバイス、又は他のモバイルコンピューティングデバイスを介して受信され得る。アプリケーションは、パブリッシャスペース内に公開され得、アプリケーションとのインタラクションが、パブリッシャを通じＡＰＩを介して実行され得る。アプリケーションは、ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ（登録商標）等のデータベースサービスプロバイダにより提供されるＡＰＩと統合され得る。

いくつかの実施例において、アプリケーションは、オンデマンドサービス環境においてネイティブにホストされる。いくつかの実施例において、アプリケーションは、サードパーティプラットフォーム上でホストされる。サードパーティプラットフォームは、オンデマンドサービス環境の外部にある１以上のデータベースシステムを含み得る。アプリケーションは、ｓｉｔｅ．ｃｏｍ、Ｈｅｒｏｋｕ（登録商標）、ｆｏｒｃｅ．ｃｏｍ（登録商標）、及びＡｐｐＥｘｃｈａｎｇｅ（登録商標）を含むがこれらに限定されないプラットフォームサービス上でホストされ得る。

アプリケーションを実行させるための実際のコードは、サードパーティプラットフォーム上でホストされてもよいが、アプリケーションは、オンデマンドサービス環境において提供されるＡＰＩと通信するよう構成される。このＡＰＩは、サードパーティアプリケーション等のアプリケーションをオンデマンドサービス環境に統合することを可能にし得る。例えば、このようなＡＰＩは、サードパーティアプリケーションをオンデマンドサービス環境に統合することを可能にする、ツール及びＪａｖａｓｃｒｉｐｔ（登録商標） ＡＰＩのセットから構成され得る。Ｊａｖａｓｃｒｉｐｔ（登録商標） ＡＰＩは、サードパーティアプリケーションがブラウザページと通信できるように、通信ブリッジを提供する。

ブロック１８１２において、アプリケーションからのコンテンツが、ＡＰＩを介してパブリッシャ内に公開される。アプリケーションからのコンテンツは、標準インタフェース、又は、Ｖｉｓｕａｌｆｏｒｃｅページ等のカスタマイズされたユーザインタフェース内に公開され得る。いくつかの実施例において、パブリッシャ内にコンテンツを公開することは、データベースシステムからコンテンツを取得すること、及び、パブリッシャ内のパブリッシャスペースに表示されるように、コンテンツを提示することを含む。いくつかの例において、データベースシステムは、オンデマンドサービス環境の外部で記憶され得る。

パブリッシャスペース内に公開されるコンテンツは、任意の数のデータソースから生じ得る。いくつかの実施例において、そのようなデータソースは、とりわけ、アナリティクス（analytics）、外部データソース、フィード、及びダイレクトイベント（direct event）を含み得る。例えば、公開されるコンテンツは、ビデオ会議サービスから提供されるビデオストリームであり得る。別の例において、公開されるコンテンツは、ウェブマッピングサービスアプリケーションから提供されるマップであり得る。パブリッシャスペースは、ユーザインタフェース内でコンテンツを閲覧することができるフレーム又はウィンドウを提供し、データソースからのコンテンツは、ブラウザページと通信するためのＡＰＩとインタフェースをとることができる。

図５４は、いくつかの実施例に従った、オンデマンドサービス環境においてネイティブにホストされているカスタムアクション用のデータフィールドを公開しているパブリッシャを含むユーザインタフェースの一例を示している。パブリッシャ５４０２は、レコードとインタラクトするよう構成されているカスタムアクション５４０４を含み得る。カスタムアクション５４０４は、セクションＩＸにおいて先に説明された方法で第１のエンティティにより提供されるカスタムアクション命令に従ってレコードとインタラクトするよう構成され得る。カスタムアクション５４０４は、ＡＰＩとインタフェースをとることができるＡＰＩ対応アクションであり得、ＡＰＩに、レコードに関連付けられたデータフィールド５４０８を表示させ得る。カスタムアクション５４０４は、パブリッシャ５４０２に、コンテンツをパブリッシャスペース５４０６内に公開させる。コンテンツは、レコードに関連付けられたデータフィールド５４０８から構成され得る。ここで、ユーザは、New Oppty（新たな商談）のカスタムアクション５４０４を選択して、パブリッシャ５４０２に、新たな商談を作成するためのデータフィールド５４０８を公開させることができる。データフィールドは、Opportunity Name（商談名）、Account Name（取引先名）、Next Step（次のステップ）、Amount（数量）、Close Date（クローズ日）、及びStage（段階）を含み得る。ＡＰＩは、オンデマンドサービス環境における１以上のデータベースシステムとインタフェースをとることができる。図５４の例において、ＡＰＩは、外部データベースシステム又はサードパーティデータベースシステムと通信しなくてもよい。

図５５は、いくつかの実施例に従った、オンデマンドサービス環境の外部でホストされているウェブページ５５０８からのコンテンツを公開しているパブリッシャ５５０２を含むユーザインタフェースの一例を示している。パブリッシャ５５０２は、外部でホストされているコンテンツを公開するよう構成されているカスタムアクション５５０４を含み得る。そのようなコンテンツの例は、記事、ブログ、チャットルーム、ウェブページ、他のオンラインソーシャルネットワークからのフィード等を含み得る。カスタムアクション５５０４は、ＡＰＩとインタフェースをとることができるＡＰＩ対応アクションであり、ＡＰＩに、外部データソースからのコンテンツを表示させる。図５５に示されるように、カスタムアクション５５０４は、パブリッシャ５５０２に、ウェブページ５５０８をパブリッシャスペース５５０６内に表示させ得る。ウェブページ５５０８は、ウェブベースのアプリケーションサービスを含み得る。ウェブページ５５０８が、オンデマンドサービス環境の外部でホストされている場合であっても、ユーザは、ＡＰＩを介して、ウェブページ５５０８と直接インタラクトすることができる。図５５の例において、ユーザが、Create Listening Campaign（リスニングキャンペーンを作成する）のカスタムアクション５５０４を選択すると、パブリッシャ５５０２は、リスニングキャンペーンを作成するためにユーザがインタラクトできるウェブページ５５０８を公開する。

図５６Ａは、いくつかの実施例に従った、サードパーティプラットフォーム上でホストされているアプリケーションからのコンテンツを公開しているパブリッシャを含むユーザインタフェースの一例を示している。パブリッシャ５６０２は、サードパーティプラットフォーム上でホストされているアプリケーションとインタラクトするよう構成されているカスタムアクション５６０４を含み得る。カスタムアクション５６０４は、ＡＰＩとインタフェースをとることができるＡＰＩ対応アクションであり、ＡＰＩに、サードパーティプラットフォーム上でホストされているアプリケーションからのコンテンツをパブリッシャスペース５６０６内に公開させる。いくつかの例において、パブリッシャスペース５６０６内でのアプリケーションの公開は、ｆｏｒｃｅ．ｃｏｍ（登録商標）のＣａｎｖａｓアプリケーションであるカスタムアクション５６０４を用いて実行され得る。Ｃａｎｖａｓアプリケーションは、アプリケーションからのコンテンツを表示するためのｉＦｒａｍｅ又はウィンドウとして機能する。アプリケーションは、Ｈｅｒｏｋｕ（登録商標）等のサードパーティプラットフォーム上でホストされ得る。図５６Ａに示されるように、アプリケーションは、旅程５６０８のリストを表示するよう構成されているトラベルサービスであり得る。パブリッシャ５６０２内に公開され得る他のサービスは、とりわけ、ＣＲＭサービス、顧客サービス、タスク管理サービス、ウェブサービス、ソーシャルマーケティングサービス、実績管理サービス、及びデータリポジトリサービスを含み得るが、これらに限定されるものではない。

図１８に戻ると、ブロック１８１６において、アプリケーションとインタラクトするための、公開されたコンテンツに関するユーザ入力が受信される。ユーザ入力は、例えば、図１Ａ及び図１Ｂにおける信号ネットワーク１４を介して、方法１８００を実行する１以上のコンピューティングデバイスに伝送され得る。いくつかの例において、ユーザ入力は、１以上のコンピューティングデバイスに送信される情報の選択又は入力を含み得る。

ユーザインタフェースから、ユーザは、ＡＰＩを介して、サードパーティアプリケーション等のアプリケーションとインタラクトすることができる。図５６Ａにおいて、ユーザは、パブリッシャスペース５６０６内の旅程５６０８のリストから選択して、複数のアクションを実行することができる。例えば、ユーザは、Share Itinerary（旅程共有）ボタン５６１０を選択することにより、パブリッシャスペース５６０６内にリストされた旅程を共有することができる。これは、旅程をフィード項目として１以上のフィードにポストさせ得る。別の例として、ユーザは、Request Approval（承認リクエスト）ボタン５６１２を選択することにより、別のエンティティに対して旅程の承認をリクエストすることができる。したがって、ユーザは、承認ワークフローを開始して、旅程を承認のためのフィード項目として指定されたエンティティのフィードにポストすることができる。ユーザのマネージャ等の指定されたエンティティは、このリクエストを承認又は拒否することにより、このフィード項目とインタラクトすることができる。別の例において、ユーザは、Cancel Trip（トリップ取消）ボタン５６１４を選択することにより、旅程のうちの１つを取り消すことができる。ユーザは、ドロップダウンメニュー５６１６においてエンティティを選択することにより、情報が公開されるエンティティのフィードを特定することができる。さらに、ユーザは、Share（共有）ボタン５６１８を選択することにより、情報を適切なフィードに公開することができる。したがって、ユーザは、カスタムアクション５６０４及びＡＰＩを用いて、プラットフォームからコンテンツを取得して管理することができる。

図１８に戻ると、ブロック１８２０において、ＡＰＩを介したアプリケーションとのインタラクションが、ユーザ入力を用いて実行される。インタラクションがユーザ入力により開始されると、アプリケーションは、アプリケーションに対するアップデートを実施するＡＰＩと直接インタフェースをとる。アプリケーションがサードパーティプラットフォーム上でホストされている場合であっても、アプリケーションは、ホスト中のページに対するアップデートを実施するＡＰＩと直接インタフェースをとる。いくつかの実施例において、実行されるインタラクションは、ユーザインタフェースのブラウザページ内で生じる。例えば、アプリケーションは、パブリッシャ内に公開されているモーゲージカルキュレータ（mortgage calculator）であり得、インタラクションがパブリッシャスペースに直接出力される。いくつかの実施例において、実行されるインタラクションは、ユーザインタフェースのブラウザページで生じない。その代わりに、実行されるインタラクションは、ブラウザ内でページを開くこと又はブラウザ内でページをリフレッシュすることを回避するサードパーティアプリケーション及びＡＰＩを用いて生じる。すなわち、ブラウザページは、サードパーティプラットフォーム上でホストされているアプリケーションに対してなされるアップデートを認識しない。いくつかの例において、１以上のデータベースシステムが、実行されたインタラクションに従ってアップデートされ得る。

ブロック１８２４において、情報フィードが、アプリケーションとの実行されたインタラクションに従って、ユーザインタフェースにおけるＡＰＩを介してアップデートされる。情報フィードは、情報フィード内の情報をアップデートするＡＰＩと直接インタフェースをとる。ＡＰＩがアプリケーションと通信するので、ＡＰＩは、アプリケーションから返される情報をブラウザページにリンクする。そのような情報は、ＡＰＩを介して、ユーザインタフェースの情報フィード内に提供される。いくつかの実施例において、情報フィードは、ユーザインタフェースをリフレッシュすることなくアップデートされる。実際、方法１８００において実行されるステップの各々は、ユーザインタフェースをリフレッシュすることなく生じ得る。例えば、情報フィードをアップデートすることは、１以上のデータフィールドに対する変更を「トグルする」ことにより、ユーザ入力に基づいて情報フィード内の１以上のデータフィールドをアップデートすることを含み得る。したがって、ＡＰＩは、アップデートがユーザインタフェース内のパブリッシャと情報フィードとの間でシームレスに生じるように、サードパーティプラットフォーム上でホストされているアプリケーション等の公開されているアプリケーションとユーザとの間のインタラクションを可能にし得る。

図５６Ｂは、いくつかの実施例に従った、図５６Ａにおけるサードパーティプラットフォーム上でホストされているアプリケーションからのコンテンツに関するユーザ入力に基づいて情報を表示しているフィード項目５６２４を含むユーザインタフェースの一例を示している。ユーザ入力に応じて、ＡＰＩは、アプリケーションと通信し、サードパーティプラットフォームにおける１以上のデータベースシステムから情報を取得することができる。この情報は、ＡＰＩを介して、情報フィード５６２２内のフィード項目５６２４に提供され得る。アプリケーションがＡＰＩを呼び出し、次いで、ＡＰＩが、情報フィード５６２２に含まれるようにフィード項目５６２４を提示するために、情報フィード５６２２をアップデートする。図５６ＡのShare Itinerary（旅程共有）ボタン５６１０を選択した後、ユーザは、Share（共有）ボタン５６２０を選択して、選択された旅程を含むフィード項目５６２４をポストする。アプリケーションから取得される、フィード項目５６２４内の情報は、図５６Ａにおける公開されたコンテンツよりも多くのデータを含み得る。

いくつかの実施例において、フィード項目は、アプリケーションへの参照を提供する１以上の実行可能なセレクションを含み得る。１以上の実行可能なセレクションは、フィード項目から、アプリケーションに対するさらなるオペレーションを実行させ得る。図５６Ｃは、いくつかの実施例に従った、図５６Ａにおけるサードパーティプラットフォーム上でホストされているアプリケーションからのコンテンツに関するユーザ入力に基づいて承認コントロール５６３０を表示しているフィード項目５６２８を含むユーザインタフェースの一例を示している。図５６Ａにおける選択された旅程の承認をリクエストするユーザ入力に応じて、選択された旅程に関する情報が、ＡＰＩを介して、情報フィード５６２６内のフィード項目５６２８に提供され得る。この情報は、サードパーティプラットフォームにおける１以上のデータベースシステムから取得され得る。フィード項目５６２８は、承認コントロール５６３０をさらに含み得、適切なエンティティは、選択された旅程を承認又は拒否することができる。いくつかの実施例において、承認コントロール５６３０は、ユーザにより指定されたエンティティの情報フィード又はユーザのプロフィール及び／若しくはプリファレンスに基づくエンティティの情報フィード内に提供され得る。承認コントロール５６３０のうちの１つの選択は、情報フィード５６２６に加えて、サードパーティプラットフォーム上でホストされているアプリケーションをさらにアップデートさせ得る。

方法１８００についての一連のステップの少なくとも一部が、図５６Ａ〜図５６Ｃに例示され得るが、他の例もまた、方法１８００についての一連のステップを例示し得る。例えば、ユーザインタフェースは、パブリッシャ及び情報フィードを含み得、パブリッシャは、顧客とビデオ会議を開始するためのカスタムアクションを含む。顧客は、ビデオ記録デバイスを使用することができ、パブリッシャのパブリッシャスペースを通じて、ユーザとリアルタイムに会話することができる。さらに、ユーザは、パブリッシャからビデオ会議を記録することにより、公開されたデータストリームに対してアクションを実行することができ、記録されたビデオを情報フィードに公開することができる。

別の例において、ユーザインタフェースは、パブリッシャ及び情報フィードを含み得、パブリッシャは、ＳＡＰシステムを用いて発注するためのカスタムアクションを含む。１以上の項目が、ＳＡＰシステムから、パブリッシャ内に公開され得、ユーザは、発注する項目を選択することができる。ユーザは、発注するためのボタンを選択し、次いで、ＡＰＩを介して、ＳＡＰシステムとインタラクトすることができる。ＡＰＩは、カスタムアクションが、情報フィードと通信して、その項目に関する発注がなされたことを示すフィード項目を公開させることを可能にする。

さらに別の例において、製薬会社は、遊離型薬物（free drug）サンプルを医師に販売する販売代理店用のカスタマイズされたユーザインタフェースを開発することができる。販売代理店が、ユーザインタフェース内で、特定の医師のアカウントを引き出すと、販売代理店は、その医師のアカウントを閲覧して、新たな注文をパブリッシャに入力することができる。販売代理店は、サードパーティアプリケーション等のアプリケーションとインタラクトして、注文請求を履行することができ、注文請求書が発行されたことを示すフィード項目が、情報フィード内にポストされ得る。

さらに別の例において、ゲーム会社は、大量の一斉電子メールを顧客に送信するためのカスタマイズされたユーザインタフェースを開発することができる。ビデオゲームにおけるバグに関する膨大な事例が速いペースで生じる場合、ゲーム会社は、パブリッシャを利用して、ＶｅｒｔｉｃａｌＲｅｓｐｏｎｓｅ Ｉｎｃ．又はＣｏｎｓｔａｎｔ Ｃｏｎｔａｃｔ， Ｉｎｃ．等の一斉電子メール送信ウェブサービス（mass email web service）とインタラクトすることができる。ゲーム会社は、全ての受信者をインポート又は選択し、電子メールを作成し、一斉電子メール送信ウェブサービスを通じて電子メールを送信することができる。完了後に、電子メールが送信されたことを示すフィード項目を提示することにより、情報フィードがアップデートされ得る。

ＩＸ．様々なオペレーティングシステムにおけるパブリッシャの実装
パブリッシャは、１以上の情報フィードに公開されている、インタラクションに関する情報を含む１以上のレコードとインタラクトするインタフェースであり得る。いくつかの実施例において、パブリッシャは、１以上のレコードの作成を処理するインタフェースであり得る。例えば、パブリッシャは、投票、連絡先、タスク等といったオブジェクトの作成を処理するコンポーザであり得る。パブリッシャは、投票コンポーザ、連絡先コンポーザ、タスクコンポーザ等といった様々なコンポーザを作成するためのフレームワークの一部であり得る。そのようなフレームワークは、「パブリッシャフレームワーク」と呼ばれ得る。

パブリッシャフレームワークは、Ａｎｄｒｏｉｄ（登録商標）、ｉＯＳ（登録商標）、及びＷｉｎｄｏｗｓ（登録商標）を含むがこれらに限定されない任意の１以上のオペレーティングシステムのためのネイティブフレームワークであり得る。いくつかの実施例において、パブリッシャフレームワークは、ｉＯＳ（登録商標）において実装され得る。

いくつかの実施例において、パブリッシャフレームワークは、任意のコンポーザクラス（composer class）を自動的に発見するよう構成され得る。したがって、パブリッシャがオペレーティングシステムにおいてロードされると、パブリッシャは、コンポーザのクラスの各々を登録する必要なく、コンポーザの１以上のクラスを自動的に発見することができる。

パブリッシャフレームワークにおけるパブリッシャのいくつかの実装には、１以上のプロトコル及び／又はベースクラス（base class）が伴い得る。１以上のプロトコル及び／又はベースクラスは、ユーザインタフェース内でのパブリッシャの実装を容易にし得る。

一例において、１以上のプロトコル及び／又はベースクラスは、＠の記載（@ mention）、タグ、メタデータタグ、ハッシュタグ等を含む任意の番号参照（number reference）に対するサポートを提供することができる。いくつかの例において、既製の（ready-made）テキストビューは、デフォルトデータソース又はカスタムデータソースを用いる任意の数のそのような参照をサポートすることができる。

別の例において、１以上のプロトコル及び／又はベースクラスは、ｉＰａｄ（登録商標）及びｉＰｈｏｎｅ（登録商標）を含む１以上のクライアントデバイスにおけるパブリッシャに対するサポートを提供することができる。それらクライアントデバイスの各々は、パブリッシャが適合し得るフォームファクタを有し得る。

別の例において、各パブリッシャは、パブリッシャがメインパブリッシャメニューにおいていつ可視にされるべきかを示すよう構成され得る。例えば、所定のレコードが選択されたとき、いくつかのパブリッシャは、メニューにおいて可視にされ得るが、他のパブリッシャは不可視にされ得る。

別の例において、１以上のプロトコル及び／又はベースクラスは、パブリッシャフレームワークにおいてユーザインタフェース内でアニメーション化されて表示され得るメッセージを提供することができる。そのような例は、エラーメッセージ、警告メッセージ、及び情報を含むが、これらに限定されるものではない。

別の例において、１以上のプロトコル及び／又はベースクラスは、パブリッシャ、カスタムボタン等の表示をカスタマイズする柔軟な方法を提供することができる。カスタマイズ可能な表示は、例えば、上方ビュー（upper view）、アクセサリビュー（accessory view）、右側ビュー（right-view）等を含み得る。

パブリッシャの実装に伴う前述の１以上のプロトコル及び／又はベースクラスは、任意のタイプのコンポーザの作成の容易化を可能にし得る。例えば、コンポーザは、ネイティブコンポーザ、ウェブベースのコンポーザ、又はサードパーティコンポーザであり得る。

いくつかの実施例において、オペレーティングシステムにおいてパブリッシャフレームワークを実装するためのいくつかのクラス及びメソッドのサブクラスを作ることにより、プラグインが、スクラッチから追加され得る。プラグインは、プラグイン自身のためのベースクラスを含み得る。プラグインは、パブリッシャの基本機能を得るための１以上のメソッドをオーバーライトし得る。プラグインは、プラグインビューコントローラ（plugin view controller）を含み得る。プラグインビューコントローラは、複数の様々なヘルパ機能を提供することができる別のベースクラスを含み得る。

本明細書で開示される実施例の特定の態様の具体的な詳細は、開示される実施例の主旨及び範囲から逸脱することなく、任意の適切な形で組み合わせることができる。しかしながら、他の実施例は、各個別の態様に関連する特定の実施例、又は、そのような個別の態様の特定の組合せを対象とし得る。

開示される例は、複数のテナントをサポートすることができるオンデマンドデータベースサービスのためのフロントエンドを提供するアプリケーションサーバを有するシステムにおいてオンデマンドデータベースサービス環境が実装される実施例を参照して本明細書でしばしば説明されるが、本実施例は、マルチテナントデータベースやアプリケーションサーバ上でのデプロイメント（deployment）に限定されるものではない。実施例は、特許請求される実施例の範囲から逸脱することなく、他のデータベースアーキテクチャ、すなわち、ＯＲＡＣＬＥ（登録商標）、ＩＢＭ（登録商標）のＤＢ２（登録商標）、及び同様のものを用いて実施することができる。

開示される実施例のいくつかは、モジュラ型又は統合型のコンピュータソフトウェア及び／又はハードウェアを用いる制御ロジックの形態で具現化され得ることを理解すべきである。ハードウェア及びハードウェアとソフトウェアとの組合せを用いる他の形及び／又は方法も可能である。

本出願において説明されるソフトウェアコンポーネント又は機能のいずれも、例えば、従来技術又はオブジェクト指向型技術を用いる、例えば、Ｊａｖａ（登録商標）、Ｃ＋＋、又はＰｅｒｌ等の任意の適切なコンピュータ言語を用いる、プロセッサにより実行されるソフトウェアコードとして実装され得る。ソフトウェアコードは、一連の命令又はコマンドとして、記憶及び／又は伝送のためにコンピュータ読み取り可能媒体に記憶され得る。適切な媒体は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードドライブ又はフロッピディスク等の磁気媒体、コンパクトディスク（ＣＤ）又はＤＶＤ（デジタル多用途ディスク）等の光媒体、フラッシュメモリ、及び同様のものを含む。コンピュータ読み取り可能媒体は、そのような記憶デバイス又は伝送デバイスの任意の組合せであり得る。ソフトウェア／プログラムコードでエンコードされたコンピュータ読み取り可能媒体は、互換デバイスとともにパッケージ化されてもよいし、他のデバイスから（例えば、インターネットダウンロードを介して）別々に提供されてもよい。任意のそのようなコンピュータ読み取り可能媒体は、１つのコンピューティングデバイス又はコンピュータシステム全体上に存在しても、１つのコンピューティングデバイス又はコンピュータシステム全体内に存在してもよく、とりわけ、１つのシステム又はネットワーク内に存在してもよい。コンピュータシステム又は他のコンピューティングデバイスは、モニタ、プリンタ、又は本明細書に記載される結果のうちのいずれかをユーザに対して提供するための他の適切なディスプレイを含み得る。

様々な実施例が本明細書で説明されたが、これらは限定ではなく例として提示されているに過ぎないことを理解すべきである。したがって、本出願の広がり及び範囲は、本明細書で説明された実施例のいずれによっても限定されるべきではなく、以下の及び後で提出される請求項及びその均等の構成によってのみ定められるべきである。

Claims (108)

1. オンラインソーシャルネットワークにおいてユーザインタフェースから１以上のレコードとインタラクトする、コンピュータにより実施される方法であって、
   コンピューティングデバイスにより、パブリッシャを含むユーザインタフェースを生成するためのデータを提供するステップであって、前記パブリッシャは、情報を情報フィードに公開するよう構成される、ステップと、
   前記コンピューティングデバイスにおいて、前記パブリッシャから、第１のレコードとインタラクトするリクエストを受信するステップであって、前記第１のレコードは、データベースシステムに記憶された親レコードに関連する、ステップと、
   前記コンピューティングデバイスにおいて、前記パブリッシャから、前記第１のレコードに関連付けられた第１の情報を受信するステップと、
   前記第１のレコードに関連付けられた前記第１の情報に基づいて、前記データベースシステムをアップデートするステップと、
   前記ユーザインタフェース内の前記情報フィードに含まれるように、前記第１の情報に基づく前記アップデートに関連付けられたフィード項目を提示するステップであって、前記フィード項目は、前記第１のレコードへの参照を提供する１以上の実行可能なセレクションを含む、ステップと、
   前記１以上の実行可能なセレクションのうちの少なくとも１つを選択したというユーザ入力を受信するステップと、
   前記コンピューティングデバイスにおいて、前記パブリッシャから、前記第１のレコード又は第２のレコードに関連付けられた第２の情報を受信するステップと、
   前記第２の情報に基づいて、前記データベースシステムをアップデートするステップと、
   を含む、方法。
2. 前記第１のレコード及び前記第２のレコードの各々は、顧客関係管理（ＣＲＭ）オブジェクトであり、前記ＣＲＭオブジェクトは、リード、案件、取引先、商談、タスク、連絡先、キャンペーン、契約、イベント、カスタムオブジェクト、及びＶｉｓｕａｌｆｏｒｃｅページのうちの１つである、請求項１記載の方法。
3. 前記第１のレコードとインタラクトする前記リクエストを受信した後、前記パブリッシャに、前記第１のレコードの１以上のデータフィールドを表示させるステップであって、前記１以上のデータフィールドは、前記第１のレコードに関連付けられる前記第１の情報を受け入れるよう構成される、ステップ
   をさらに含む、請求項１記載の方法。
4. 前記１以上の実行可能なセレクションのうちの少なくとも１つを選択したという前記ユーザ入力を受信した後、前記パブリッシャに、前記第２のレコードの１以上のパブリッシャアクションを表示させるステップと、
   前記第２のレコードの前記１以上のパブリッシャアクションのうちの少なくとも１つの選択に応じた、前記第２のレコードとインタラクトするリクエストを受信するステップであって、前記第２のレコードは、前記データベースシステムに記憶された前記親レコード及び前記第１のレコードのうちの少なくとも１つに関連する、ステップと、
   をさらに含む、請求項１記載の方法。
5. 前記１以上の実行可能なセレクションのうちの少なくとも１つを選択したという前記ユーザ入力を受信した後、前記第２の情報を用いて、前記第１のレコードを参照するオペレーションを実行するステップ
   をさらに含む、請求項１記載の方法。
6. 前記オペレーションは、タスクを作成すること、タスクをアップデートすること、商談を作成すること、商談をアップデートすること、連絡先を作成すること、連絡先をアップデートすること、案件を作成すること、案件をアップデートすること、取引先を作成すること、取引先をアップデートすること、イベントを作成すること、イベントをアップデートすること、要求のログを取ること、タスクのログを取ること、バグのログを取ること、電子メールを作成すること、メモを書くこと、投票を作成すること、案件をクローズすること、タスクを完了すること、バグをクローズすること、電子メールを送信すること、承認のための電子メールを送信すること、ポータルにポストすること、ソーシャルネットワークにポストすること、リンクを追加すること、及び「感謝」を追加することのうちの少なくとも１つを含む、請求項５記載の方法。
7. 前記第１の情報に基づいて前記データベースシステムをアップデートする前記ステップは、前記第１のレコードを作成すること、前記第１のレコードを削除すること、前記第１のレコードに関連付けられたデータを編集すること、前記第１のレコードにアクションを記録すること、前記第１のレコードを変換すること、前記第１のレコードにファイルを添付すること、及び前記第１のレコードに関連付けられた情報を閲覧することのうちの少なくとも１つを含む、請求項１乃至６いずれか一項記載の方法。
8. 前記パブリッシャは、前記第１のレコードとインタラクトするよう構成されたカスタムアクションを含み、前記第１のレコードとインタラクトする前記リクエストを受信する前記ステップは、
   前記コンピューティングデバイスにおいて、前記カスタムアクションを選択したという第１のユーザ入力を受信するステップ
   を含む、請求項１乃至６いずれか一項記載の方法。
9. ユーザが前記第１のレコードとインタラクトするためのパーミッションを有すると判定するステップ
   をさらに含む、請求項１乃至６いずれか一項記載の方法。
10. ユーザがパーミッションを有すると判定する前記ステップは、
    前記ユーザのプロフィールの１以上のユーザ属性を識別するステップと、
    前記第１のレコードの１以上のレコード属性を識別するステップと、
    前記ユーザが前記第１のレコードとインタラクトするためのパーミッションを有すると判定するために、前記１以上のユーザ属性を前記１以上のレコード属性と比較するステップと、
    を含む、請求項９記載の方法。
11. 前記情報フィードに含まれるように、前記第２の情報に基づく前記アップデートに関連付けられた別のフィード項目を提示するステップであって、前記別のフィード項目は、前記パブリッシャ及び前記第２のレコードへの別の参照を提供する別の１以上の実行可能なセレクションを含む、ステップ
    をさらに含む、請求項１乃至６いずれか一項記載の方法。
12. 前記パブリッシャは、
    １以上のパブリッシャアクションと、
    前記フィード項目内にメッセージコンテンツを提供するよう構成されたメッセージボディと、
    １以上のパブリッシャエクステンションに関連付けられたパブリッシャスペースであって、前記第１の情報又は前記第２の情報を提供するよう構成されたパブリッシャスペースと、
    前記第１の情報又は前記第２の情報とともに前記メッセージコンテンツを前記データベースシステムに送信するよう構成されたパブリッシャコンポーネントと、
    を含む、請求項１乃至６いずれか一項記載の方法。
13. 前記コンピューティングデバイスにより、前記ユーザインタフェース内の前記パブリッシャの寸法を定義するステップと、
    前記コンピューティングデバイスにより、前記ユーザインタフェース内の前記パブリッシャのレイアウトを定義するステップと、
    をさらに含む、請求項１乃至６いずれか一項記載の方法。
14. 前記第１の情報に基づく前記アップデートに関連付けられた前記フィード項目は、前記第１のレコードと親子関係を有するレコードフィード、前記第１のレコードのレコードフィード、ユーザのニュースフィード、前記ユーザをフォローしているエンティティのニュースフィード、及び前記第１のレコードにサブスクライブしているエンティティのニュースフィードのうちの少なくとも１つに含まれる、請求項１乃至６いずれか一項記載の方法。
15. 前記第２の情報に基づく前記アップデートに関連付けられた前記フィード項目は、前記第２のレコードと親子関係を有するレコードフィード、前記第２のレコードのレコードフィード、ユーザのニュースフィード、前記ユーザをフォローしているエンティティのニュースフィード、及び前記第２のレコードにサブスクライブしているエンティティのニュースフィードのうちの少なくとも１つに含まれる、請求項１乃至６いずれか一項記載の方法。
16. 前記パブリッシャは、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して前記データベースシステムをアップデートするために、前記第１の情報又は前記第２の情報を送信するよう構成される、請求項１乃至６いずれか一項記載の方法。
17. 前記ＡＰＩは、モバイルディスプレイデバイス用に構成される、請求項１６記載の方法。
18. オンラインソーシャルネットワークにおいてユーザインタフェースから１以上のレコードとインタラクトするための１以上のコンピューティングデバイスであって、
    パブリッシャを含むユーザインタフェースを生成するためのデータを提供する手段であって、前記パブリッシャは、情報を情報フィードに公開するよう構成される、手段と、
    前記パブリッシャから、第１のレコードとインタラクトするリクエストを受信する手段であって、前記第１のレコードは、データベースシステムに記憶された親レコードに関連する、手段と、
    前記パブリッシャから、前記第１のレコードに関連付けられた第１の情報を受信する手段と、
    前記第１のレコードに関連付けられた前記第１の情報に基づいて、前記データベースシステムをアップデートする手段と、
    前記ユーザインタフェース内の情報フィードに含まれるように、前記第１の情報に基づく前記アップデートに関連付けられたフィード項目を提示する手段であって、前記フィード項目は、前記第１のレコードへの参照を提供する１以上の実行可能なセレクションを含む、手段と、
    前記１以上の実行可能なセレクションのうちの少なくとも１つを選択したというユーザ入力を受信する手段と、
    前記パブリッシャから、前記第１のレコード又は第２のレコードに関連付けられた第２の情報を受信する手段と、
    前記第２の情報に基づいて、前記データベースシステムをアップデートする手段と、
    を備えた、１以上のコンピューティングデバイス。
19. 前記第１のレコード及び前記第２のレコードの各々は、顧客関係管理（ＣＲＭ）オブジェクトであり、前記ＣＲＭオブジェクトは、リード、案件、取引先、商談、タスク、連絡先、キャンペーン、契約、イベント、カスタムオブジェクト、及びＶｉｓｕａｌｆｏｒｃｅページのうちの１つである、請求項１８記載の１以上のコンピューティングデバイス。
20. 前記パブリッシャに、前記第１のレコードの１以上のデータフィールドを表示させる手段であって、前記１以上のデータフィールドは、前記第１のレコードとインタラクトする前記リクエストが受信された後、前記第１のレコードに関連付けられた前記第１の情報を受け入れるよう構成される、手段
    をさらに備えた、請求項１８記載の１以上のコンピューティングデバイス。
21. 前記第１の情報に基づいて前記データベースシステムをアップデートする前記手段は、前記第１のレコードを作成すること、前記第１のレコードを削除すること、前記第１のレコードに関連付けられたデータを編集すること、前記第１のレコードにアクションを記録すること、前記第１のレコードを変換すること、前記第１のレコードにファイルを添付すること、及び前記第１のレコードに関連付けられた情報を閲覧することのうちの少なくとも１つを実行する手段を含む、請求項１８乃至２０いずれか一項記載の１以上のコンピューティングデバイス。
22. 前記パブリッシャは、前記第１のレコードとインタラクトするよう構成されたカスタムアクションを含み、前記第１のレコードとインタラクトするリクエストを受信する前記手段は、前記カスタムアクションを選択したという第１のユーザ入力を受信する手段を含む、請求項１８乃至２０いずれか一項記載の１以上のコンピューティングデバイス。
23. ユーザが前記第１のレコードとインタラクトするためのパーミッションを有すると判定する手段
    をさらに備えた、請求項１８乃至２０いずれか一項記載の１以上のコンピューティングデバイス。
24. 前記第１の情報に基づく前記アップデートに関連付けられた前記フィード項目は、前記第１のレコードと親子関係を有するレコードフィード、前記第１のレコードのレコードフィード、ユーザのニュースフィード、前記ユーザをフォローしているエンティティのニュースフィード、及び前記第１のレコードにサブスクライブしているエンティティのニュースフィードのうちの少なくとも１つに含まれる、請求項１８乃至２０いずれか一項記載の１以上のコンピューティングデバイス。
25. 前記パブリッシャは、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して前記データベースシステムをアップデートするために、前記第１の情報又は前記第２の情報を送信するよう構成される、請求項１８乃至２０いずれか一項記載の１以上のコンピューティングデバイス。
26. オンラインソーシャルネットワークにおいてユーザインタフェースから１以上のレコードとインタラクトする、コンピュータにより実施される方法であって、
    コンピューティングデバイスにより、パブリッシャを含むユーザインタフェースを生成するためのデータを提供するステップであって、前記パブリッシャは、情報を情報フィードに公開するよう構成される、ステップと、
    前記コンピューティングデバイスにおいて、前記パブリッシャから、第１のレコードとインタラクトするリクエストを受信するステップであって、前記第１のレコードは、データベースシステムに記憶された親レコードに関連する、ステップと、
    前記コンピューティングデバイスにおいて、前記パブリッシャから、前記第１のレコードに関連付けられた第１の情報を受信するステップと、
    前記第１のレコードに関連付けられた前記第１の情報に基づいて、前記データベースシステムをアップデートするステップと、
    前記ユーザインタフェース内の前記親レコードの情報フィードに含まれるように、前記第１の情報に基づく前記アップデートに関連付けられたフィード項目を提示するステップと、
    前記フィード項目と相互参照されている１以上のエンティティを識別するステップと、
    前記フィード項目と相互参照されている前記１以上のエンティティの１以上の情報フィード内に、前記第１の情報に基づく前記アップデートに関連付けられた前記フィード項目を提供するステップと、
    を含む、方法。
27. 前記１以上のエンティティのうちの少なくとも１つは、ユーザ、グループ、組織、又はレコードを含む、請求項２６記載の方法。
28. 前記１以上のエンティティは、前記第１のレコードの複数の親レコードを含む、請求項２６記載の方法。
29. 前記フィード項目と相互参照されている前記１以上のエンティティを識別する前記ステップは、
    前記データベースシステムにおける、前記第１のレコードのレコード関連情報を取得するステップと、
    前記レコード関連情報に少なくとも部分的に基づいて、前記１以上のエンティティのうちの少なくとも１つが前記フィード項目と相互参照されていると判定するステップと、
    を含む、請求項２６記載の方法。
30. 前記フィード項目と相互参照されている前記１以上のエンティティを識別する前記ステップは、
    前記コンピューティングデバイスにおいて、アプリケーションプログラミングインタフェース（ＡＰＩ）から相互参照用データを受信するステップと、
    前記相互参照用データに少なくとも部分的に基づいて、前記１以上のエンティティのうちの少なくとも１つが前記フィード項目と相互参照されていると判定するステップと、
    を含む、請求項２６記載の方法。
31. 前記相互参照用データは、ユーザにより定められる、請求項３０記載の方法。
32. １以上の実行可能なセレクションのうちの少なくとも１つを選択したというユーザ入力を受信するステップと、
    前記コンピューティングデバイスにおいて、前記パブリッシャから、第２のレコードに関連付けられた第２の情報を受信するステップであって、前記第２のレコードは、前記データベースシステムに記憶された前記第１のレコードの子レコードである、ステップと、
    前記第２のレコードに関連付けられた前記第２の情報に基づいて、前記データベースシステムをアップデートするステップと、
    をさらに含む、請求項２６乃至３１いずれか一項記載の方法。
33. 前記第１のレコード、及び前記フィード項目と相互参照されている前記１以上のエンティティの各々は、顧客関係管理（ＣＲＭ）オブジェクトであり、前記ＣＲＭオブジェクトは、リード、案件、取引先、商談、タスク、連絡先、キャンペーン、契約、イベント、カスタムオブジェクト、及びＶｉｓｕａｌｆｏｒｃｅページのうちの１つである、請求項２６乃至３１いずれか一項記載の方法。
34. 前記第１のレコードとインタラクトする前記リクエストを受信した後、前記パブリッシャに、前記第１のレコードの１以上のデータフィールドを表示させるステップであって、前記１以上のデータフィールドは、前記第１のレコードに関連付けられる前記第１の情報を受け入れるよう構成される、ステップ
    をさらに含む、請求項２６乃至３１いずれか一項記載の方法。
35. 前記１以上のデータフィールドのうちの少なくとも１つは、前記フィード項目と相互参照される前記１以上のエンティティを定める相互参照用データを受け入れるよう構成される、請求項３４記載の方法。
36. 前記フィード項目と相互参照されている前記１以上のエンティティのうちの少なくとも１つは、前記第１のレコード、前記第１のレコードの親レコード、前記第１のレコードの子レコード、前記第１のレコードにサブスクライブしているユーザ、前記第１のレコードとインタラクトしているユーザ、及び前記第１のレコードとインタラクトしている前記ユーザをフォローしているユーザを含む、請求項２６乃至３１いずれか一項記載の方法。
37. ユーザが前記第１のレコードとインタラクトするためのパーミッションを有すると判定するステップ
    をさらに含む、請求項３６記載の方法。
38. オンラインソーシャルネットワークにおいて複数のレコードとインタラクトするための１以上のコンピューティングデバイスであって、
    パブリッシャを含むユーザインタフェースを生成するためのデータを提供する手段であって、前記パブリッシャは、情報を情報フィードに公開するよう構成される、手段と、
    前記パブリッシャから、第１のレコードとインタラクトするリクエストを受信する手段であって、前記第１のレコードは、データベースシステムに記憶された親レコードに関連する、手段と、
    前記パブリッシャから、前記第１のレコードに関連付けられた第１の情報を受信する手段と、
    前記第１のレコードに関連付けられた前記第１の情報に基づいて、前記データベースシステムをアップデートする手段と、
    前記ユーザインタフェース内の前記親レコードの情報フィードに含まれるように、前記第１の情報に基づく前記アップデートに関連付けられたフィード項目を提示する手段と、
    前記フィード項目と相互参照されている１以上のエンティティを識別する手段と、
    前記フィード項目と相互参照されている前記１以上のエンティティの１以上の情報フィードに含まれるように、前記第１の情報に基づく前記アップデートに関連付けられた前記フィード項目を提供する手段と、
    を備えた、１以上のコンピューティングデバイス。
39. 前記１以上のエンティティは、前記第１のレコードの複数の親レコードを含む、請求項３８記載の１以上のコンピューティングデバイス。
40. 前記フィード項目と相互参照されている前記１以上のエンティティを識別する前記手段は、
    前記データベースシステムにおける、前記第１のレコードのレコード関連情報を取得する手段と、
    前記レコード関連情報に少なくとも部分的に基づいて、前記１以上のエンティティのうちの少なくとも１つが前記フィード項目と相互参照されていると判定する手段と、
    を含む、請求項３８記載の１以上のコンピューティングデバイス。
41. 前記フィード項目と相互参照されている前記１以上のエンティティを識別する前記手段は、
    アプリケーションプログラミングインタフェース（ＡＰＩ）から相互参照用データを受信する手段と、
    前記相互参照用データに少なくとも部分的に基づいて、前記１以上のエンティティのうちの少なくとも１つが前記フィード項目と相互参照されていると判定する手段と、
    を含む、請求項３８乃至４０いずれか一項記載の１以上のコンピューティングデバイス。
42. 前記第１のレコード、及び前記フィード項目と相互参照されている前記１以上のエンティティの各々は、顧客関係管理（ＣＲＭ）オブジェクトであり、前記ＣＲＭオブジェクトは、リード、案件、取引先、商談、タスク、連絡先、キャンペーン、契約、イベント、カスタムオブジェクト、及びＶｉｓｕａｌｆｏｒｃｅページのうちの１つである、請求項３８乃至４０いずれか一項記載の１以上のコンピューティングデバイス。
43. オンラインソーシャルネットワークにおいて１以上のフォロワによりアクセスされる相互参照されているフィード項目を公開する、コンピュータにより実施される方法であって、
    コンピューティングデバイスにおいて、フィード項目を親エンティティのフィードに公開するリクエストを受信するステップであって、前記親エンティティは、前記オンラインソーシャルネットワークのデータベースにおいて識別される、ステップと、
    エンティティを、前記フィード項目と相互参照されているものとして識別するステップであって、前記の相互参照されているエンティティは、１以上のフォロワを有する、ステップと、
    前記コンピューティングデバイスにおいて、前記の相互参照されているエンティティの前記１以上のフォロワによりアクセスされる前記フィード項目を公開するリクエストを受信するステップと、
    前記親エンティティ及び前記の相互参照されているエンティティに関連付けて、前記フィード項目を１以上のデータベーステーブルに記憶するステップであって、前記フィード項目は、前記１以上のフォロワによりアクセス可能な複数の情報フィード内に前記フィード項目を表示するよう動作可能なディスプレイデバイスに提供されることが可能であり、前記１以上のフォロワによりアクセス可能な前記複数の情報フィードは、前記親エンティティの前記フィードと前記１以上のフォロワの１以上のフィードとを含む、ステップと、
    を含む、方法。
44. 前記１以上のフォロワによりアクセス可能な前記複数の情報フィードのうちの１つの情報フィード内に前記フィード項目を表示するよう動作可能な前記ディスプレイデバイスに、前記フィード項目を提供するステップ
    をさらに含む、請求項４３記載の方法。
45. 前記コンピューティングデバイスにおいて、前記の相互参照されているエンティティによりアクセスされる前記フィード項目を公開するリクエストを受信するステップと、
    前記の相互参照されているエンティティのフィード内に前記フィード項目を表示するよう動作可能な前記ディスプレイデバイスに、前記フィード項目を提供するステップと、
    をさらに含む、請求項４３記載の方法。
46. エンティティを、前記フィード項目と相互参照されているものとして識別する前記ステップは、
    前記オンラインソーシャルネットワークのデータベースにアクセスするステップであって、前記データベースは、前記フィード項目が前記エンティティと相互参照されていることを示すデータを記憶している、ステップ
    を含む、請求項４３記載の方法。
47. 前記コンピューティングデバイスにより、パブリッシャを含むユーザインタフェースを生成するためのデータを提供するステップであって、前記パブリッシャは、情報を情報フィードに公開するよう構成され、前記パブリッシャは、相互参照する１以上のエンティティを選択するためのアプリケーションプログラミングインタフェース（ＡＰＩ）を含む、ステップ
    をさらに含む、請求項４３記載の方法。
48. エンティティを、前記フィード項目と相互参照されているものとして識別する前記ステップは、
    前記フィード項目が前記１以上のフォロワに対してトランジティブであると判定するステップ
    を含む、請求項４３記載の方法。
49. エンティティを、前記フィード項目と相互参照されているものとして識別する前記ステップは、
    前記フィード項目と、前記の相互参照されているエンティティの前記１以上のフォロワと、の関連性を分析するステップと、
    前記フィード項目が前記の相互参照されているエンティティの前記１以上のフォロワに関連すると判定するステップと、
    を含む、請求項４３乃至４８いずれか一項記載の方法。
50. 前記フィード項目は、前記ディスプレイデバイスにおいて、情報をユーザインタフェースに公開し、前記の公開される情報は、前記フィード項目が含まれる選択された情報フィードのソースに少なくとも部分的に依存する、請求項４３乃至４８いずれか一項記載の方法。
51. 前記フィード項目は、前記ディスプレイデバイスにおいて、情報をユーザインタフェースに公開し、前記の公開される情報は、前記ディスプレイデバイスのタイプに少なくとも部分的に依存する、請求項４３乃至４８いずれか一項記載の方法。
52. 前記複数の情報フィードは、フォロワのニュースフィードを含む、請求項４３乃至４８いずれか一項記載の方法。
53. 前記親エンティティの前記フィードへのアクセスをリクエストしているフォロワのアクセスパーミッションを識別するステップと、
    前記のリクエストしているフォロワが前記親エンティティの前記フィードを閲覧するためのパーミッションを有すると判定するステップと、
    をさらに含む、請求項４３乃至４８いずれか一項記載の方法。
54. オンラインソーシャルネットワークにおいて１以上のフォロワによりアクセスされる相互参照されているフィード項目を公開するための１以上のコンピューティングデバイスであって、
    フィード項目を親エンティティのフィードに公開するリクエストを受信する手段であって、前記親エンティティは、前記オンラインソーシャルネットワークのデータベースにおいて識別される、手段と、
    エンティティを、前記フィード項目と相互参照されているものとして識別する手段であって、前記の相互参照されているエンティティは、１以上のフォロワを有する、手段と、
    前記の相互参照されているエンティティの前記１以上のフォロワによりアクセスされる前記フィード項目を公開するリクエストを受信する手段と、
    前記親エンティティ及び前記の相互参照されているエンティティに関連付けて、前記フィード項目を１以上のデータベーステーブルに記憶する手段であって、前記フィード項目は、前記１以上のフォロワによりアクセス可能な複数の情報フィード内に前記フィード項目を表示するよう動作可能なディスプレイデバイスに提供されることが可能であり、前記１以上のフォロワによりアクセス可能な前記複数の情報フィードは、前記親エンティティの前記フィードと前記１以上のフォロワの１以上のフィードとを含む、手段と、
    を備えた、１以上のコンピューティングデバイス。
55. 前記の相互参照されているエンティティは、ユーザ、グループ、組織、レコード、又はカスタムオブジェクトである、請求項５４記載の１以上のコンピューティングデバイス。
56. 前記の相互参照されているエンティティによりアクセスされる前記フィード項目を公開するリクエストを受信する手段と、
    前記の相互参照されているエンティティのフィード内に前記フィード項目を表示するよう動作可能な前記ディスプレイデバイスに、前記フィード項目を提供する手段と、
    をさらに備えた、請求項５４記載の１以上のコンピューティングデバイス。
57. エンティティを、前記フィード項目と相互参照されているものとして識別する前記手段は、
    前記オンラインソーシャルネットワークのデータベースにアクセスする手段であって、前記データベースは、前記フィード項目が前記エンティティと相互参照されていることを示すデータを記憶している、手段
    を含む、請求項５４乃至５６いずれか一項記載の１以上のコンピューティングデバイス。
58. 前記親エンティティの前記フィードへのアクセスをリクエストしているフォロワのアクセスパーミッションを識別する手段と、
    前記のリクエストしているフォロワが前記親エンティティの前記フィードを閲覧するためのパーミッションを有すると判定する手段と、
    をさらに備えた、請求項５４乃至５６いずれか一項記載の１以上のコンピューティングデバイス。
59. 情報をオンラインソーシャルネットワークの情報フィードに公開するよう構成されたパブリッシャから１以上のデータオブジェクトとインタラクトする、コンピュータにより実施される方法であって、
    コンピューティングデバイスにより、カスタムアクションを伴うパブリッシャを含むユーザインタフェースを生成するためのデータを提供するステップであって、前記カスタムアクションは、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して第１のエンティティにより提供されるカスタムアクション命令に従ってデータオブジェクトとインタラクトするよう構成され、前記データオブジェクトは、データベースシステムに記憶されている、あるいは前記データベースシステムに記憶されるよう構成されている、ステップと、
    前記コンピューティングデバイスにおいて、第２のエンティティから、前記ユーザインタフェース内の前記カスタムアクションの選択を介した、前記データオブジェクトとインタラクトするリクエストを受信するステップと、
    前記コンピューティングデバイスにおいて、前記パブリッシャから、前記データオブジェクトに関連付けられた１以上のデータフィールドのための第１の情報を受信するステップと、
    前記データオブジェクトに関連付けられた前記１以上のデータフィールドのための前記第１の情報に基づいて、前記データベースシステムをアップデートするステップと、
    前記ユーザインタフェース内の情報フィードに含まれるように、前記第１の情報に基づく前記アップデートに関連付けられたフィード項目を提示するステップと、
    を含む、方法。
60. 前記データオブジェクトは、顧客関係管理（ＣＲＭ）オブジェクトであり、前記ＣＲＭオブジェクトは、リード、案件、取引先、商談、タスク、連絡先、キャンペーン、契約、イベント、カスタムオブジェクト、及びＶｉｓｕａｌｆｏｒｃｅページのうちの１つである、請求項５９記載の方法。
61. 前記第１のエンティティは、データベースサービスを複数の受領者に提供するデータベースサービスプロバイダである、請求項５９記載の方法。
62. 前記第２のエンティティは、前記複数の受領者のうちの１人である、請求項６１記載の方法。
63. 前記パブリッシャ内で選択されるように前記カスタムアクションを表示するよう構成された１以上のページタイプを定義するステップ
    をさらに含む、請求項５９記載の方法。
64. 前記カスタムアクションの選択は、前記パブリッシャの外部にあるユーザインタフェースコンポーネントからのユーザ入力により生じる、請求項５９乃至６３いずれか一項記載の方法。
65. 前記コンピューティングデバイスにおいて、検索クエリを受信するステップと、
    前記検索クエリに応じて、前記ユーザインタフェースコンポーネントを前記ユーザインタフェース内に表示させるステップと、
    をさらに含む、請求項６４記載の方法。
66. 前記パブリッシャは、
    １以上のパブリッシャエクステンションと、
    前記カスタムアクションと、
    前記１以上のパブリッシャエクステンション又は前記カスタムアクションの選択に関連付けられたパブリッシャスペースであって、前記データオブジェクトに関連付けられた前記１以上のデータフィールドのための前記第１の情報を提供するよう構成されたパブリッシャスペースと、
    を含む、請求項５９乃至６３いずれか一項記載の方法。
67. 前記パブリッシャは、
    前記フィード項目内にメッセージコンテンツを提供するよう構成されたメッセージボディと、
    前記データオブジェクトに関連付けられた前記１以上のデータフィールドからの前記第１の情報と、前記メッセージコンテンツと、を前記データベースシステムに送信するよう構成されたパブリッシャコンポーネントと、
    を含む、請求項６６記載の方法。
68. 前記コンピューティングデバイスにより、前記パブリッシャ内での前記カスタムアクションのページレイアウトを定義するステップであって、前記ページレイアウトは、前記パブリッシャ内での、前記１以上のパブリッシャエクステンションに対する前記カスタムアクションの配置を表す、ステップ
    をさらに含む、請求項６６記載の方法。
69. 前記コンピューティングデバイスにより、前記パブリッシャ内での前記１以上のデータフィールドのアクションレイアウトを定義するステップであって、前記アクションレイアウトは、前記パブリッシャスペース内での前記１以上のデータフィールドの配置を表す、ステップ
    をさらに含む、請求項６６記載の方法。
70. 前記データオブジェクトとインタラクトする前記リクエストは、レコードを作成すること、レコードを削除すること、レコードに関連付けられたデータを編集すること、レコードにアクションを記録すること、レコードを変換すること、レコードにファイルを添付すること、及びレコードに関連付けられた情報を閲覧することのうちの少なくとも１つを含む、請求項５９乃至６３いずれか一項記載の方法。
71. 前記コンピューティングデバイスにおいて、ユーザから前記カスタムアクション命令を受け取るステップであって、前記カスタムアクション命令は、前記データオブジェクトを定義するとともに、前記データオブジェクトに関連付けられる前記１以上のデータフィールドを定義するよう構成される、ステップ
    をさらに含む、請求項５９乃至６３いずれか一項記載の方法。
72. 前記カスタムアクション命令は、さらに、前記１以上のデータフィールドの各々に関連付けられる１以上の妥当性検証ルールを定義するよう構成され、前記１以上の妥当性検証ルールの各々は、前記１以上のデータフィールドの各々におけるユーザにより定められる値に対する制限を設定する、請求項７１記載の方法。
73. 前記カスタムアクション命令は、さらに、前記パブリッシャ内での前記カスタムアクションのページレイアウトを定義するよう構成され、前記ページレイアウトは、前記パブリッシャ内での、１以上のパブリッシャアクションに対する前記カスタムアクションの配置を表し、前記カスタムアクション命令は、さらに、前記パブリッシャ内での前記１以上のデータフィールドのアクションレイアウトを定義するよう構成され、前記アクションレイアウトは、前記パブリッシャ内での前記１以上のデータフィールドの配置を表す、請求項７１記載の方法。
74. 前記カスタムアクション命令は、前記カスタムアクションを伴う前記パブリッシャに含まれるように１以上のパブリッシャエクステンションを定義するよう構成される、請求項５９乃至６３いずれか一項記載の方法。
75. 前記アップデートに関連付けられた前記フィード項目と相互参照されている１以上のエンティティを識別するステップと、
    前記フィード項目と相互参照されている前記１以上のエンティティの１以上の情報フィードに含まれるように、前記第１の情報に基づく前記フィード項目を提供するステップと、
    をさらに含む、請求項５９乃至６３いずれか一項記載の方法。
76. パブリッシャから１以上のデータオブジェクトとインタラクトするための１以上のコンピューティングデバイスであって、
    カスタムアクションを伴うパブリッシャを含むユーザインタフェースを生成するためのデータを提供する手段であって、前記カスタムアクションは、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して第１のエンティティにより提供されるカスタムアクション命令に従ってデータオブジェクトとインタラクトするよう構成され、前記データオブジェクトは、データベースシステムに記憶されている、あるいは前記データベースシステムに記憶されるよう構成されている、手段と、
    第２のエンティティから、前記ユーザインタフェース内の前記カスタムアクションの選択を介した、前記データオブジェクトとインタラクトするリクエストを受信する手段と、
    前記カスタムアクションのイベントに応じて、前記パブリッシャに、前記データオブジェクトに関連付けられた１以上のデータフィールドを表示させる手段と、
    前記データオブジェクトに関連付けられた前記１以上のデータフィールドのための第１の情報を受信する手段と、
    前記データオブジェクトに関連付けられた前記１以上のデータフィールドのための前記第１の情報に基づいて、前記データベースシステムをアップデートする手段と、
    前記ユーザインタフェース内の情報フィードに含まれるように、前記第１の情報に基づく前記アップデートに関連付けられたフィード項目を提示する手段と、
    を備えた、１以上のコンピューティングデバイス。
77. 前記データオブジェクトは、顧客関係管理（ＣＲＭ）オブジェクトであり、前記ＣＲＭオブジェクトは、リード、案件、取引先、商談、タスク、連絡先、キャンペーン、契約、イベント、カスタムオブジェクト、及びＶｉｓｕａｌｆｏｒｃｅページのうちの１つである、請求項７６記載の１以上のコンピューティングデバイス。
78. 前記第１のエンティティは、データベースサービスを複数の受領者に提供するデータベースサービスプロバイダであり、前記第２のエンティティは、前記複数の受領者のうちの１人である、請求項７６記載の１以上のコンピューティングデバイス。
79. 選択されるように前記カスタムアクションを表示するよう構成された１以上のページタイプを定義する手段
    をさらに備えた、請求項７６記載の１以上のコンピューティングデバイス。
80. 前記カスタムアクションの選択は、前記パブリッシャの外部にあるユーザインタフェースコンポーネントからのユーザ入力により生じる、請求項７６乃至７９いずれか一項記載の１以上のコンピューティングデバイス。
81. ユーザが前記カスタムアクションを選択するためのパーミッションを有すると判定する手段
    をさらに備えた、請求項７６乃至７９いずれか一項記載の１以上のコンピューティングデバイス。
82. ユーザから前記カスタムアクション命令を受け取る手段であって、前記カスタムアクション命令は、前記データオブジェクトを定義するとともに、前記データオブジェクトに関連付けられる前記１以上のデータフィールドを定義するよう構成される、手段
    をさらに備えた、請求項７６乃至７９いずれか一項記載の１以上のコンピューティングデバイス。
83. 前記カスタムアクション命令は、さらに、前記パブリッシャ内での前記カスタムアクションのページレイアウトを定義するよう構成され、前記ページレイアウトは、前記パブリッシャ内での、１以上のパブリッシャエクステンションに対する前記カスタムアクションの配置を表し、前記カスタムアクション命令は、さらに、前記パブリッシャ内での前記１以上のデータフィールドのアクションレイアウトを定義するよう構成され、前記アクションレイアウトは、前記パブリッシャ内での前記１以上のデータフィールドの配置を表す、請求項８２記載の１以上のコンピューティングデバイス。
84. オンラインソーシャルネットワークにおいてパブリッシャを用いてアプリケーションとインタラクトするための、コンピュータにより実施される方法であって、
    コンピューティングデバイスにより、パブリッシャ及び情報フィードを含むユーザインタフェースを生成するためのデータを提供するステップであって、前記パブリッシャは、情報を前記情報フィードに公開するよう構成される、ステップと、
    前記コンピューティングデバイスにおいて、前記パブリッシャを用いてアプリケーションを公開するリクエストを受信するステップと、
    アプリケーションプログラミングインタフェース（ＡＰＩ）を介して、前記パブリッシャ内に前記アプリケーションからのコンテンツを公開するステップと、
    前記アプリケーションとインタラクトするための、前記の公開されたコンテンツに関するユーザ入力を受信するステップと、
    前記ユーザ入力を用いて、前記ＡＰＩを介して前記アプリケーションとのインタラクションを実行するステップと、
    前記アプリケーションとの前記の実行されたインタラクションに従って、前記ユーザインタフェースにおける前記ＡＰＩを介して前記情報フィードをアップデートするステップと、
    を含む、方法。
85. 前記アプリケーションは、サードパーティプラットフォーム上でホストされている、請求項８４記載の方法。
86. 前記情報フィードに含まれるように、前記アップデートに関連付けられたフィード項目を提示するステップ
    をさらに含む、請求項８４記載の方法。
87. 前記フィード項目は、前記アプリケーションへの参照を提供する１以上の実行可能なセレクションを含む、請求項８６記載の方法。
88. 前記１以上の実行可能なセレクションのうちの少なくとも１つを選択したという、前記アプリケーションをアップデートするための別のユーザ入力を受信するステップと、
    前記別のユーザ入力を用いて、前記ＡＰＩを介して前記アプリケーションに対するアップデートを実行するステップと、
    をさらに含む、請求項８７記載の方法。
89. 前記パブリッシャは、第１のエンティティにより提供されるカスタムアクション命令に従って前記アプリケーションとインタラクトするよう構成されたカスタムアクションを含む、請求項８４記載の方法。
90. ユーザから前記カスタムアクション命令を受け取るステップであって、前記カスタムアクション命令は、前記パブリッシャ及び前記カスタムアクションのレイアウト及び寸法を定義するよう構成される、ステップ
    をさらに含む、請求項８９記載の方法。
91. 前記第１のエンティティは、データベースサービスを複数の受領者に提供するデータベースサービスプロバイダである、請求項８９記載の方法。
92. 前記第１のエンティティは、ユーザ又は組織である、請求項８９記載の方法。
93. 前記アプリケーションとのインタラクションを実行する前記ステップは、
    前記アプリケーションとの実行されたインタラクションに従って、データベースシステムをアップデートするステップ
    を含む、請求項８４乃至９２いずれか一項記載の方法。
94. 当該方法において実行される前記ステップの各々は、前記ユーザインタフェースをリフレッシュすることなく生じる、請求項８４乃至９２いずれか一項記載の方法。
95. 前記アプリケーションからのコンテンツを公開する前記ステップは、
    データベースシステムから前記コンテンツを取得するステップと、
    前記パブリッシャ内のパブリッシャスペースに表示されるように、前記コンテンツを提示するステップと、
    を含む、請求項８４乃至９２いずれか一項記載の方法。
96. 前記ＡＰＩは、前記アプリケーションをオンデマンドサービス環境に統合することを可能にするよう構成される、請求項８４乃至９２いずれか一項記載の方法。
97. 前記アプリケーションは、タスク管理サービス、顧客関係管理（ＣＲＭ）サービス、顧客サービス、実績管理サービス、ソーシャルマーケティングサービス、ウェブサービス、及びデータリポジトリサービスのうちの少なくとも１つである、請求項８４乃至９２いずれか一項記載の方法。
98. 前記情報フィードをアップデートする前記ステップは、前記ユーザ入力に基づいて、前記情報フィード内の１以上のデータフィールドをアップデートするステップを含む、請求項８４乃至９２いずれか一項記載の方法。
99. オンラインソーシャルネットワークにおいてパブリッシャを用いてアプリケーションとインタラクトするための１以上のコンピューティングデバイスであって、
    パブリッシャ及び情報フィードを含むユーザインタフェースを生成するためのデータを提供する手段であって、前記パブリッシャは、情報を前記情報フィードに公開するよう構成される、手段と、
    前記パブリッシャを用いてアプリケーションを公開するリクエストを受信する手段と、
    アプリケーションプログラミングインタフェース（ＡＰＩ）を介して、前記パブリッシャ内に前記アプリケーションからのコンテンツを公開する手段と、
    前記アプリケーションとインタラクトするための、前記の公開されたコンテンツに関するユーザ入力を受信する手段と、
    前記ユーザ入力を用いて、前記ＡＰＩを介して前記アプリケーションとのインタラクションを実行する手段と、
    前記アプリケーションとの前記の実行されたインタラクションに従って、前記ユーザインタフェースにおける前記ＡＰＩを介して前記情報フィードをアップデートする手段と、
    を備えた、１以上のコンピューティングデバイス。
100. 前記情報フィードに含まれるように、前記アップデートに関連付けられたフィード項目を提示する手段であって、前記フィード項目は、前記アプリケーションへの参照を提供する１以上の実行可能なセレクションを含む、手段
     をさらに備えた、請求項９９記載の１以上のコンピューティングデバイス。
101. 前記パブリッシャは、第１のエンティティにより提供されるカスタムアクション命令に従って前記アプリケーションとインタラクトするよう構成されたカスタムアクションを含む、請求項９９記載の１以上のコンピューティングデバイス。
102. 前記インタラクションを実行する前記手段は、前記アプリケーションとの実行されたインタラクションに従って、データベースシステムをアップデートする手段を含む、請求項９９乃至１０１いずれか一項記載の１以上のコンピューティングデバイス。
103. 前記ＡＰＩは、前記アプリケーションをオンデマンドサービス環境に統合することを可能にするよう構成される、請求項９９乃至１０１いずれか一項記載の１以上のコンピューティングデバイス。
104. 前記アプリケーションからのコンテンツを公開する前記手段は、
     データベースシステムから前記コンテンツを取得する手段と、
     前記パブリッシャ内のパブリッシャスペースに表示されるように、前記コンテンツを提示する手段と、
     を含む、請求項９９乃至１０１いずれか一項記載の１以上のコンピューティングデバイス。
105. 前記アプリケーションは、タスク管理サービス、顧客関係管理（ＣＲＭ）サービス、顧客サービス、実績管理サービス、ソーシャルマーケティングサービス、ウェブサービス、及びデータリポジトリサービスのうちの少なくとも１つである、請求項９９乃至１０１いずれか一項記載の１以上のコンピューティングデバイス。
106. パブリッシャから１以上のレコードとインタラクトするための、コンピュータにより実施される方法であって、
     コンピューティングデバイスにより、パブリッシャを含むユーザインタフェースを生成するためのデータを提供するステップであって、前記パブリッシャは、情報を情報フィードに公開するよう構成され、前記データは、オペレーティングシステムにおいて前記パブリッシャを実装するための１以上のプロトコル及び／又はベースクラスを含む、ステップと、
     前記コンピューティングデバイスにおいて、前記パブリッシャから、第１のレコードとインタラクトするリクエストを受信するステップであって、前記第１のレコードは、データベースシステムに記憶された親レコードに関連する、ステップと、
     前記コンピューティングデバイスにおいて、前記パブリッシャから、前記第１のレコードに関連付けられた第１の情報を受信するステップと、
     前記第１のレコードに関連付けられた前記第１の情報に基づいて、前記データベースシステムをアップデートするステップと、
     前記ユーザインタフェース内の前記情報フィードに含まれるように、前記第１の情報に基づく前記アップデートに関連付けられたフィード項目を提示するステップであって、前記フィード項目は、前記第１のレコードへの参照を提供する１以上の実行可能なセレクションを含む、ステップと、
     前記１以上の実行可能なセレクションのうちの少なくとも１つを選択したというユーザ入力を受信するステップと、
     前記コンピューティングデバイスにおいて、前記パブリッシャから、前記第１のレコード又は第２のレコードに関連付けられた第２の情報を受信するステップと、
     前記第２の情報に基づいて、前記データベースシステムをアップデートするステップと、
     を含む、方法。
107. 前記オペレーティングシステムは、ｉＯＳ（登録商標）を含む、請求項１０６記載の方法。
108. パブリッシャから１以上のレコードとインタラクトするための１以上のコンピューティングデバイスであって、
     パブリッシャを含むユーザインタフェースを生成するためのデータを提供する手段であって、前記パブリッシャは、情報を情報フィードに公開するよう構成され、前記データは、オペレーティングシステムにおいて前記パブリッシャを実装するための１以上のプロトコル及び／又はベースクラスを含む、手段と、
     前記パブリッシャから、第１のレコードとインタラクトするリクエストを受信する手段であって、前記第１のレコードは、データベースシステムに記憶された親レコードに関連する、手段と、
     前記パブリッシャから、前記第１のレコードに関連付けられた第１の情報を受信する手段と、
     前記第１のレコードに関連付けられた前記第１の情報に基づいて、前記データベースシステムをアップデートする手段と、
     前記ユーザインタフェース内の前記情報フィードに含まれるように、前記第１の情報に基づく前記アップデートに関連付けられたフィード項目を提示する手段であって、前記フィード項目は、前記第１のレコードへの参照を提供する１以上の実行可能なセレクションを含む、手段と、
     前記１以上の実行可能なセレクションのうちの少なくとも１つを選択したというユーザ入力を受信する手段と、
     前記パブリッシャから、前記第１のレコード又は第２のレコードに関連付けられた第２の情報を受信する手段と、
     前記第２の情報に基づいて、前記データベースシステムをアップデートする手段と、
     を備えた、１以上のコンピューティングデバイス。

Images