DETAILED ACTION
Notice of AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Application
Claims 1-20 were pending and were rejected in the previous office action. Claims 1, 8, and 15 were amended. Claims 1-20 remain pending and are examined in this office action.
Priority
This application claims the benefit of priority to U.S. Provisional Application No. 63/708,113, filed October 16, 2024.
Response to Arguments
Claim Objections:
Claims 1, 8 and 15 were previously objected as reciting “the each block.” The claims are amended to correct the previous issues, and the previous objections are withdrawn.
Note: See the new objections to claims 6, 13, and 20 above suggesting clarifications to the claims.
35 USC § 103:
Applicant’s arguments with respect to the § 103 rejections of claims 1-20 (pgs. 10-12, remarks filed 7/23/2026) have been considered but are moot, as they do not apply to the current grounds of rejection in the current § 103 rejections of claims 1-20 below, in response to applicant’s amendments.
Please see the current § 103 rejections over claims 1-20 below.
Claim Objections
Claims 6, 13, and 20 objected to because of the following informalities:
Claims 6, 13, and 20 recite limitations (using claim 6 as representative), for: “wherein the activity feed is stored within multiple blocks, wherein each block represents an activity, and wherein the method comprises enabling commenting and tagging on the blocks…” – while it is clear that applicant intends to refer to the multiple blocks recited in the directly preceding limitation, the examiner suggests amending the term “the blocks” to clearly distinguish which blocks are being referred to, in order to avoid potential confusion as to whether or not “the blocks” may be referring to blocks described in independent claims 1/8/15.
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“identifying patterns…using an artificial intelligence (AI) system” of claim 1,
“identify patterns…using an artificial intelligence (AI) system” of claims 8 and 15
“at least one suggestion generated by the AI system” of claim 1,
“generate, using the AI system, at least one follow-up suggestion…” of claims 8 and 15
The following portions of the specification appear to provide the corresponding structure for the AI system to perform the claimed functions:
See published application US20260105459A1 at ¶ 0209-0214 and Fig. 12 showing corresponding structure of AI system implemented on a computer system including processor/memory. Also see ¶ 0140-0142.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 5, 7-10, 12, 14-17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US 20160019661 A1 to Bouganim et al. (Bouganim) in view of NPL Reference U to “Teton-Landis” (see 7/1/2026 PTO-892), and further in view of US 20120078917 A1 to Gradin et al. (Gradin).
Note: NPL Reference U (cited and attached with the 7/1/2026 non-final rejection) was retrieved from https://www.notion.com/blog/data-model-behind-notion and was Published on May 18, 2021, more than 1 year prior to the effective filing date of the instant application. Therefore, even though the reference appears to be published by the same entity as the applicant (Notion Labs, Inc.), it still qualifies as prior art over the instant application.
Claim 1: Bouganim teaches:
A computer-implemented method (Bouganim ¶ 0005-0026 showing computer implemented process steps; and ¶ 0049 “relationship management systems and methods for managing a social network in accordance with embodiments of the invention are disclosed”) comprising:
accessing a database storing a profile of at least one contact (Bouganim: ¶ 0056 showing accessing information for relevant contacts in a CRM database; also see ¶ 0005-0006, ¶ 0074, ¶ 0050-0051 and ¶ 0070),
wherein the database is integrated with electronic communication services (Bouganim: Figs. 1 and 2, ¶ 0069 showing data sources in communication with the relationship management server system, for collecting contacts information by the relationship management system, and storing the information on the contacts in database 34);
tracking interactions that include the at least one contact by logging electronic communications and events sent and received by the electronic communication services (Bouganim: ¶ 0005, ¶ 0026, ¶ 0068, ¶ 0073-0074 showing aggregating/obtaining even information, i.e. interactions, between the user and one or more contacts by monitoring sources of event information such as email, call records, meeting and calendar data, social networking communications, etc.);
determining a frequency of the interactions (Bouganim: ¶ 0060-0065, ¶ 0070, ¶ 0134 showing “The relationship management system may determine engagement scores with respect to achieving the objective (e.g., landing company B as a customer) based on the level of events between the set of users and the set of contacts. As described above, this scoring may take into account various factors, including the type of contact (e.g., title, position), the type of event (phone call, lunch meeting), the frequency of the event (e.g., how often people communicate), and the duration since the last event”);
generating a timeline of the interactions using the determined frequency of the interactions (Bouganim: Fig. 12, ¶ 0115 showing a timeline of interactions with a contact according to the collected events/interactions data, which displays frequency and shows how a relationship score decreases without contract over time, and showing the impact/effect of different events on a relationship score);
displaying an activity feed associated with the at least one contact, wherein the activity feed is generated using the timeline of the interactions (Bouganim: Fig. 17 and ¶ 0141 showing activity feed displayed on a contact page corresponding to a contact and showing a sequence of recent activity between the user and the contact “John Doe”, wherein “the UI displays a set of activities 1710. As described above, in some embodiments, these activities may be generated based on event information automatically captured and provided by a relationship management system,” i.e. based on a timeline of events over time captured as event information);
identifying patterns in the interactions using an artificial intelligence (AI) system (Bouganim: ¶ 0054 “relationship management systems use machine learning and statistical techniques to infer information from user networks and observed behaviors that can be used to enhance the ability of other users to achieve their objectives”; ¶ 0146 “In certain embodiments, machine learning techniques may be utilized to analyze data of contacts with which objectives have been successfully achieved, and based on this analysis, this relationship management system may provide recommendations and/or tasks for other contacts in order to achieve similar objectives. For example, if a certain level of event activity between a user and a contact has been achieved prior to a deal being reached in a majority of prior deals, then the relationship management system may use this historic information to determine when a current deal in progress and/or a future deal obtains the same requisite level of event activity to increase the likelihood of success of the deal”; note that one of ordinary skill in the art would know that machine learning to be a subset of artificial intelligence);
generating an activity report summarizing the patterns in the interactions (Bouganim: ¶ 0096-0098 and Fig. 9A, showing a generated user interface showing an overview summarizing the status of groups of contacts or with respect to specific tasks; also see groups such as recent contacts, frequently contacted, and 6+ months without contact),
wherein the activity report includes at least a date of a latest interaction involving the at least one contact (Bouganim Fig. 9A showing “Most recent contact: Today” for one group, with the other groups of contacts showing other dates of most recent contact);
enabling sharing of at least one of the activity feed or the activity report across accounts associated with the database (Bouganim: ¶ 0066 showing “the relationship management system may be used across many users (e.g., by management), and provide managers with administrative level access to tune the scored relationships held by different users with respect to contacts. For example, a user may engage another colleague to assist during a particular stage of a deal, and the colleague may fine tune the relationship scores based on their own subjective perceptions of the strengths of various relationships with contacts. In this way, the relationship management system can employ user feedback, from a user, other users, and or managers with administrative level access in order to increase the likelihood that the user's scored social graph closely corresponds to the relationships the user enjoys in the real world”; and see ¶ 0133 “a relationship management system in accordance with embodiments of the invention can be deployed across a workgroup or an enterprise to provide team benchmarking, and a tool to support collaborative networking or optimization of shard social networks for a group of users. For example, a team member can ascertain whether another team member has a sufficiently strong relationship with an individual to perform a desired action with respect to the individual (e.g. request a benefit or arrange a meeting that will strengthen both users' relationship with the contact). In addition, the relationship management system can provide an opportunity for an organization to monitor the progress of business development efforts”; also see for example Fig. 17 element 1720 and Fig. 18 element 1810, which displays John Doe’s and Jane Doe’s relationship scores with other users);
With respect to the following limitations, while Bouganim teaches providing permissions and access to contacts through a database (Bouganim: ¶ 0066, ¶ 0133, Figs. 17-18, and ¶ 0056 as above), Bouganim does not explicitly teach the following data structure implementation of the database to determine permissions. However, Teton-Landis teaches:
wherein the database is implemented using a block data model comprising multiple nested blocks (Teton-Landis: Pg. 2-3 showing block data model, with Pg. 4 showing “the block model also allows blocks to be nested inside of other blocks”; see Pg. 8 showing the data records may include users),
wherein each block of the multiple nested blocks includes an upward pointer that identifies a single parent block of each block to provide a direct path from each block to a root of the multiple nested blocks (Teton-Landis: Pgs. 3 and 6-7 showing the plurality of nested blocks use an upward pointer to identify a single parent block to provide a direct path from each block to the root of the multiple nested blocks),
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the block data model implementation of Teton-Landis in the CRM system of Bouganim with a reasonable expectation of success of arriving at the claimed invention, with the motivation “to provide […] users with the ability to customize how their information is moved, organized, and shared” (Teton-Landis: Pg. 1) and “so only the right people can read it or change it” (Teton-Landis: Pg. 6).
Bouganim, as modified above (to incorporate the nested blocks structure as per Teton-Landis above), further teaches:
wherein the profile of the at least one contact is stored within a block of the multiple nested blocks (Bouganim: ¶ 0005-0006, ¶ 0059-0060, ¶ 0069-0070, ¶ 0095-0098, Fig. 9A, showing contacts stored in database as data records, i.e. data blocks, and also arranged in groups),
With respect to the limitations, while Bouganim teaches tracking interactions between users (Bouganim: ¶ 0054, ¶ 0060-0065, ¶ 0070, ¶ 0134, ¶ 0146 all cited above), and Teton-Landis teaches the nested block data structure as describe above – Bouganim/Teton-Landis do not explicitly teach the following limitations as a whole for tracking interactions and updating properties of blocks based on events/interactions as per below. However, Gradin teaches:
wherein each of the interactions is stored within a respective block of the multiple nested blocks (Gradin: ¶ 0111-0114 showing events, i.e. interactions, are stored in fields of child records which are a child of a parent record and ¶ 0117 showing “the feed can be stored as a field (e.g. as a child object) of the record” and ¶ 0199 “A feed item can represent an individual field change of a record, creation and deletion of a record, or other events being tracked for a record or a user…a feed item can be a child of a profile feed” – therefore, interactions are stored within respective child records/data objects in a nested data structure; also generally see ¶ 0047-0054),
wherein the block storing the profile references, via a content array, the respective block (Gradin: ¶ 0131 further specifying that “in one embodiment, the feed can be stored in a field (e.g. as a child object) of record 425…The feed can be organized in various ways, e.g., as a linked list, an array, or other data structure” and ¶ 0133-0135 showing “a follower profile 435 of second user 430, which can contain a list of the records that the second user 430 is following,” which describes a profile block referencing the list of the feed items, i.e. the blocks storing the tracked interactions organized as an array; also see ¶ 0192/Fig. 9A showing data array referencing list of objects followed by a user),
wherein tracking the interactions comprises automatically updated at least one property of the block storing the profile based on at least one property of the respective block (Gradin: ¶ 0116 showing “the changes to fields of a child object can be tracked to create feed tracked updates for the parent record. For example, a child object of the parent type can be specified for tracking, and certain fields of the child object can be specified for tracking. As another example, if the child object is of a type specified for tracking, then a tracked change for the child object is propagated to parent records of the child object”; also see ¶ 0117, ¶ 0131 showing the feed tracked update to a field of a child object is automatically updated in the parent record, with ¶ 0142 further showing “the feed tracked update is added to a profile feed of the first user”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the use of a nested data structure for adding feed tracked updates to fields in child records to parent records referenced in a follower profile as taught by Gradin in the CRM system of Bouganim/Teton-Landis with a reasonable expectation of success of arriving at the claimed invention, with the motivation to address the problems with conventional database management, that “using conventional database management techniques, it is difficult to know about the activity of other users of a database system in the cloud or other network. For example, the actions of a particular user, such as a salesperson, on a database resource may be important to the user's boss. The user can create a report about what the user has done and send it to the boss, but such reports may be inefficient, not timely, and incomplete. Also, it may be difficult to identify other users who might benefit from the information in the report” (Gradin: ¶ 0005), and therefore “provide more efficient use of a database system. For instance, a user of a database system may not easily know when important information in the database has changed, e.g., about a project or client. Embodiments can provide feed tracked updates about such changes and other events, thereby keeping users informed” (Gradin: ¶ 0053). Further, “As multiple users might be able to change the data of a record, it can be useful for certain users to be notified when a record is updated. Also, even if a user does not have authority to change a record, the user still might want to know when there is an update” (Gradin: ¶ 0108).
With respect to the following limitation, while Bouganim discusses permissions associated with user account as per above, Bouganim does not explicitly teach the use of an upward pointer traversed to the root of blocks for determining permissions. However, Teton-Landis teaches:
and wherein the enabling sharing comprises traversing the upward pointer from the block storing the profile to the root of the multiple nested blocks to determine permissions for the accounts (Teton-Landis: Pg. 6 showing “It’s also important to understand how this structure protects your information so only the right people can read it or change it” and Pg. 7 showing traversing the upward pointer from the nested blocks to determine permissions – “To implement permission checks for a block, we need to look up the tree, getting that block’s ancestors all the way up to the root of the tree (which is the workspace)… we use an “upward pointer”—the parent attribute—for the permission system”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the use of an upward pointer to determine permissions from a root of the nested blocks in the block data model implementation of Teton-Landis in the CRM system of Bouganim/Teton-Landis/Gradin with a reasonable expectation of success of arriving at the claimed invention, for the same reasons described in the limitations above.
Bouganim, as modified above, further teaches:
and providing, to at least one of the accounts, at least one suggestion generated by the Al system based on at least one of the activity feed or the activity report (Bouganim: ¶ 0146 showing “machine learning techniques may be utilized to analyze data of contacts with which objectives have been successfully achieved, and based on this analysis, this relationship management system may provide recommendations and/or tasks for other contacts in order to achieve similar objectives. For example, if a certain level of event activity between a user and a contact has been achieved prior to a deal being reached in a majority of prior deals, then the relationship management system may use this historic information to determine when a current deal in progress and/or a future deal obtains the same requisite level of event activity to increase the likelihood of success of the deal. In many embodiments, the relationship management system may generate task entities to provide to a CRM system that may be displayed within a task list by the CRM system”; also see ¶ 0095 “the relationship management system can provide relationship target recommendations based upon the user's priorities and/or a list of recommended activities with respect to specific contacts and/or groups of contacts related to achieving one or more specific objectives” and ¶ 0098 “Once groups are defined, the relationship management system can generate recommendations specific to the objectives of the group (whether relationship targets or project objectives) in addition to recommendations related to achieving target relationship scores”)
Claim 2: Bouganim/Teton-Landis/Gradin teach claim 1. Bouganim, as modified above, further teaches:
comprising at least one of: tracking progress of transactions associated with the at least one contact (Bouganim: ¶ 0117 showing tracking progress towards a desired relationship objective, a group objective, and/or a goal; also see ¶ 0053-0054, Fig. 13B, ¶ 0127 showing tracking progress toward deal stages and/or progress of relationship with contact with respect to an objective); or linking the interactions to a visual pipeline interface displaying stages of the transactions (Bouganim: Figs. 9A-9C, ¶ 0096-0098 showing groups of contacts in various stages, such as "suspects," "prospects," "referral sources," and "current customers" along with current relationships status/stage such as "knows my name," "exchange info," "promotes me," and "recommends me," and showing a target status for building relationships with the contacts in the group; in addition, also see ¶ 0051-0055 progress towards an objective in each of multiple stages/sub-stages is tracked, in an example pertaining to sales deal stages; see ¶ 0055 specifically describing the stages)
Claim 3: Bouganim/Teton-Landis/Gradin teach claim 1. Bouganim, as modified above, further teaches:
determining importance values for the at least one contact based on the patterns in the interactions (Bouganim: ¶ 0062, ¶ 0064, ¶ 0114-0116, ¶ 0135 showing determining importance of a relationship/contact based upon the received events information; also see ¶ 0077, ¶ 0080, ¶ 0082, ¶ 0097 user designated importance)
Claim 5: Bouganim/Teton-Landis/Gradin teach claim 1. Bouganim, as modified above, further teaches:
comprising at least one of: integrating the activity feed with calendar services to track meeting attendance (Bouganim: ¶ 0049, ¶ 0052, ¶ 0059, ¶ 0061-0062, ¶ 0068, ¶ 0084, ¶ 0134 showing tracking occurrence of in-person meetings between user and one or more contacts and retrieving event/meeting information from calendar services);
monitoring electronic communication response times;
or determining engagement metrics based on the frequency of the interactions (Bouganim: ¶ 0134 “The relationship management system may determine engagement scores with respect to achieving the objective (e.g., landing company B as a customer) based on the level of events between the set of users and the set of contacts. As described above, this scoring may take into account various factors, including the type of contact (e.g., title, position), the type of event (phone call, lunch meeting), the frequency of the event (e.g., how often people communicate), and the duration since the last event”)
Claim 7: Bouganim/Teton-Landis/Gradin teach claim 1. Bouganim, as modified above, further teaches:
wherein the suggestion includes at least one of a recommended follow-up timing or recommended actions (Bouganim: ¶ 0004 “analyze a user's social network and provide recommendations concerning actions the user can take to strengthen relevant relationships and achieve defined objectives…”; also see ¶ 0019, ¶ 0024, ¶ 0053-0054, ¶ 0059, ¶ 0098-0100, ¶ 0114-0117 showing recommendations, including recommended actions to strengthen or improve relationship)
Claim 8: See the rejection of claim 1 above teaching analogous limitations (note that while some of the “wherein” limitations describing the blocks are recited in a slightly different order than claim 1, they do not require any particular order and thus the order does not change the scope of the claim). Bouganim further teaches: A non-transitory, computer-readable storage medium comprising instructions recorded thereon, wherein the instructions, when executed by at least one data processor of a computer system, cause the computer system to… (Bouganim: ¶ 0005 “a relationship management server system that includes a processor and memory containing software and a database that includes several contacts obtained from at least one source of contact information. In many embodiments, the software directs the processor in the relationship management server system to…”).
Claims 9/16: See the rejection of claim 2 above.
Claims 10/17: See the rejection of claim 3 above.
Claims 12/19: See the rejection of claim 5 above.
Claim 14: See the rejection of claim 7 above.
Claim 15: See the rejection of claim 1 above teaching analogous limitations. Bouganim further teaches: A computer system (Bouganim: ¶ 0005 relationship management server system) comprising: at least one hardware processor (Bouganim: ¶ 0005 a processor); and at least one non-transitory memory storing instructions, which, when executed by the at least one hardware processor, cause the computer system to… (Bouganim: ¶ 0005 “a relationship management server system that includes a processor and memory containing software and a database that includes several contacts obtained from at least one source of contact information. In many embodiments, the software directs the processor in the relationship management server system to…”).
Claims 4, 6, 11, 13, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20160019661 A1 to Bouganim et al. (Bouganim) in view of NPL Reference U to “Teton-Landis” (see 7/1/2026 PTO-892), further in view of US 20120078917 A1 to Gradin et al. (Gradin), and further in view of US 20210224858 A1 to Khoury et al. (Khoury).
Claim 4: Bouganim/Teton-Landis/Gradin teach claim 1. Bouganim further teaches:
comprising: chronologically organizing the interactions (Bouganim: ¶ 0041, ¶ 0115, Fig. 12 showing interactions organized chronologically; ¶ 0056, ¶ 0059-0060, ¶ 0068, ¶ 0074, ¶ 0078-0079, ¶ 0136-0141 showing the aggregation of event information, i.e. interactions for updating relationship with contact);
With respect to the following limitations, to the extent that Bouganim/Teton-Landis/Gradin do not explicitly teach the following, Khoury teaches:
filtering the interactions by type including electronic communications and events (Khoury: ¶ 0113, ¶ 0235, ¶ 0266 showing filtering communications/content by various types of filters); and
enabling comments and tags on the interactions to provide the activity feed (Khoury: ¶ 0094, ¶ 0114-0115, ¶ 0183, ¶ 0249, ¶ 0344-0345 showing each piece of content may be commented on, liked, or otherwise interacted with; and ¶ 0330 specifying “a tag may be generated for each content element of each post whereby a unique identifier may be associated with each piece of specific content. The tags may then be tracked and traced so that the system can identify the exact history of every post containing that content, from which locations and in which contexts it has been employed, where and when it has been published, and the amount of engagement it has generated”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included filtering interactions by communication type and providing communications content that allows for commenting and tagging on social media platforms of Khoury in the relationship management system of Bouganim/Teton-Landis/Gradin with a reasonable expectation of success of arriving at the claimed invention, with the motivation to provide “an intuitive, easy to use platform for advertisement generation and deployment across social media modalities and throughout the various divisions of global brands” and “to ensure message consistency, vastly increasing reach across social media modalities, while reducing production cost, thereby allowing a greater portion of advertising spend to be allocated to increasing reach and lift while reducing production costs” (Khoury: ¶ 0016).. Furthermore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to do so, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 6: Bouganim/Teton-Landis/Gradin teach claim 1. With respect to the following limitations, Bouganim teaches events information stored in a database, i.e. “activity feed is stored within multiple blocks, wherein each block represents an activity” (Bouganim: ¶ 0069-0070, ¶ 0074 showing collecting events/activity information and storing in database of the CRM/server system), and Teton-Landis/Gradin both teach a nested/hierarchical data block structure (see claim 1 above). However, to the extent that Bouganim/Teton-Landis/Gradin do not explicitly teach the following limitations as a whole, Khoury teaches:
wherein the activity feed is stored within multiple blocks, wherein each block represents an activity (Khoury: ¶ 0127 showing structured database wherein each communication or instance of generated content and communications is stored in the database wherein “a unique identification may be generated for the communication and/or its components and used for cataloging the content and communication for storage”), and
wherein the method comprises enabling commenting and tagging on the blocks (Khoury: ¶ 0094, ¶ 0114-0115, ¶ 0183, ¶ 0249, ¶ 0344-0345 showing each piece of content, i.e. each data “block,” as a post/content that may be commented on, liked, or otherwise interacted with; and ¶ 0330 specifying “a tag may be generated for each content element of each post whereby a unique identifier may be associated with each piece of specific content. The tags may then be tracked and traced so that the system can identify the exact history of every post containing that content, from which locations and in which contexts it has been employed, where and when it has been published, and the amount of engagement it has generated”) while maintaining security boundaries between blocks using a hierarchical permission structure (Khoury: ¶ 0298 “the present communications platform allows various users within an organization, with the appropriate permissions and authorizations, to access all of the official social media interfaces of all of the retail outlets from the corporate to the local levels, and to manage the messaging taking place there on at a single or multiple client computing devices. For instance, at the corporate level, the maximum authorization may be permitted such that global access is allowed, whereas at the group or regional level only a subset of accesses are permitted, and then at the local level, access may only be given to the local franchisee's social media pages at one or more specific locations servicing a local community”; also see ¶ 0310, ¶ 0145 hierarchical permissions)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the database storing each piece of content, which is enabled for commenting and tagging on social media platforms of Khoury in the relationship management system of Bouganim/Teton-Landis/Gradin with a reasonable expectation of success of arriving at the claimed invention, with the motivation to provide “an intuitive, easy to use platform for advertisement generation and deployment across social media modalities and throughout the various divisions of global brands” and “to ensure message consistency, vastly increasing reach across social media modalities, while reducing production cost, thereby allowing a greater portion of advertising spend to be allocated to increasing reach and lift while reducing production costs” (Khoury: ¶ 0016). Furthermore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to do so, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim Interpretation Note: The filed specification at ¶ 0027 describes data blocks as follows: “The blocks are dynamic units of information that can be transformed into other block types and move across workspaces. The block model allows users to customize how their information is moved, organized, and shared. Hence, blocks contain information but are not siloed. [0028] Blocks are singular pieces that represent all units of information inside an editor. In one example, text, images, lists, a row in a database, etc., are all blocks in a workspace.” Therefore, the blocks describe units of information/data records.
Claims 11/18: See the rejection of claim 4 above.
Claims 13/20: See the rejection of claim 6 above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Hunter Molnar whose telephone number is (571)272-8271. The examiner can normally be reached Monday - Friday, 7:30 - 4:00 EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Zimmerman can be reached at (571) 272-4602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HUNTER MOLNAR/Examiner, Art Unit 3628
