Notice of Pre-AIA or 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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for convince of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references cited in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Response to Amendment
The amendment filed 7/20/2026 has been entered. The specification comments have been omitted and Claims 1-7, 9-15, and 17-20 are pending in the present Office Action.
Claim Rejections – 35 USC § 103
Claims 1-6, 9, and 17 are rejected 35 U.S.C. 103 as being anticipated by Stepanova (US 2021/0157564 A1) .
Regarding claim 1, Stepanova teaches
receiving an application programming interface (API) request to generate a first update to a content item for display at a client application ([0074] – “Additionally, product feature access module 304 may receive output data from content management system 100 indicating a result of the API request.” [0092]- “ The support application may send the request, for example, when the application is first launched, prior to generating and displaying its graphical user interface. That is, the support application may query the content management system to obtain service definitions for available product features, and generate or modify its graphical user interface based on the available product features.”);
causing, based at least in part on receiving the API request, the first update to the content item to be displayed at the client application ([0074] –“Additionally, product feature access module 304 may receive output data from content management system 100 indicating a result of the API request.” [0092]- “ The support application may send the request, for example, when the application is first launched, prior to generating and displaying its graphical user interface. That is, the support application may query the content management system to obtain service definitions for available product features, and generate or modify its graphical user interface based on the available product features.”); It is understood by the examiner, that these two passages, when read together, disclose that (i), the API request causes the content management system to return output data reflecting the requested update, and (ii), that output data is affirmatively displayed to the user via the graphical user interface.
transmitting to the content management system, a second update to the content item that is synchronized to the content management system ([0026] - “Content management system 100 provides functionality for sharing content items with one or more client devices 120 and synchronizing content items between content management system 100 and the one or more client devices 120”. Here it is understood by the examiner that Stepanova’s system possesses a general snychornixation channel between the client application and the content management system. [0093]- “Additionally or alternately, the support application may periodically send a request to the content management system to obtain updated and/or new service definitions for product features. In some embodiments, the content management system may automatically provide new and/or updated service definitions to the support application when the service definitions are added or modified.” Here, it is understood by the examiner, that a second, distinct update is transmitted after the first, is taught. This is shown in the term “periodically expressly disclosing that the update exchange is not just a single, one-time event, but performed repeatedly over rime, and that the content management system “automatically” provides updates as they arise.
causing, based at least in part on transmitting the second update, the second update to the content item to be displayed at the client application. ([0074] –“Additionally, product feature access module 304 may receive output data from content management system 100 indicating a result of the API request.” [0092]- “ The support application may send the request, for example, when the application is first launched, prior to generating and displaying its graphical user interface. That is, the support application may query the content management system to obtain service definitions for available product features, and generate or modify its graphical user interface based on the available product features.”);
Claims 2-6 are rejected 35 U.S.C. 103 as being anticipated by Stepanova (US 2021/0157564 A1) in view of Falivene (US 2025/0028829 A1)
Regarding claim 2, Falivene teaches,
causing the first update or the second update to be stored in a storage location from which the client application pulls information by stating “Client application 200 manages access to content management system 100 and collaborative content management system 130… Client application 200 may store content accessed from a content storage at content management system 100 in local content 204… the content is available to the user and other applications or modules, such as collaborative content item editor 270, when client application 200 is not in communication with content management system 100” [(0025)].
It would have been obvious to a person of ordinary skill in the art to incorporate Falivene’s local storage/pull technique into Stepanova’s update and display architecture because both references address the same technical problem: making updated content available to a client application, and combining a known local storage technique with a known update request architecture according to their established functions would’ve yielded the predictable result of a client application that remains responsive when connectivity to the content management system is interrupted.
Regarding claim 3, Falivene teaches,
receiving the API request that defines a container user interface for displaying the content item by teaching “ Client application 200 includes user interface module 202 that generates an interface to the content accessed by client application 200 and is one means for performing this function. The generated interface is provided to the user by display” [(0062)]. Falivene further teaches, “From the API calls made by the application, the collaborative content management system extracts API call features. Example API call features may be timestamps of API requests (e.g., timestamp of an API request to download a file), frequency of requests, or pattern of requests (e.g., an API request to create a file followed by an API request to modify a file), among other features.” [(0003)].
It would’ve been obvious to a person of ordinary skill in the art to incorporate Falivene’s container-interface generation technique to Stepanova’s API driven update request as both are directed to defining, via an API request, a user interface for displaying content, and combining them is a straightforward application of a known display technique to a known update request architecture.
Regarding claim 4, Falivene teaches,
transmitting the second update to the content item that is to be displayed within the container user interface by teaching “Changes or updates to content… made through the web interface, such as uploading a new version of a file, are synchronized back to other client devices 120 associated with the user's account” ([0036]).
It would’ve been obvious to a person of ordinary skill in the art to apply Falivene’s cross-device synchronization behavior to Stepanova’s second-update transmission step to combine a known synchronization technique with a known update transmission architecture to achieve the predictable result of consistent content display within the container interface across client devices.
Regarding claim 5, Falivene teaches selecting the content item from a plurality of content items based at least in part on one or more selection criteria ([0045] – “Collaborative content items database 408 contains a plurality of database objects representing collaborative content items, comment threads, and comments. Each of the database objects can be associated with a content pointer indicating the location of each object within the CCI database 408”. For clarity of the record, the Examiner would like to point to paragraph [0039] of the Specification which recites: “For example, the presentation service 215 may store a plurality of content items via the content storage system 225 such that the plurality of content items are retrievable by the presentation service 215 to display at the client application 205”. Thus, it is understood the content within the plurality of content items are organized and selected based on the requirements established by the database or means of displaying the content.
It would’ve been obvious to a person with ordinary skill in the art to combine Falivene’s database driven selection technique with Stepanova’s update and display architecture because Stepanova’s system necessarily operates on content items that must be first identified before an update to them can be generated or displayed, and Falivene teaches a known technique, a collaborative content items database in which each object is associated with a counter pointer, for locating and selecting a particular content item from among a plurality of such items.
Regarding claim 6, Falivene teaches wherein the one or more selection criteria are based on a content type or user attributes. ([0045] – “Collaborative content items database 408 contains a plurality of database objects representing collaborative content items, comment threads, and comments. Each of the database objects can be associated with a content pointer indicating the location of each object within the CCI database 408”. For clarity of the record, the Examiner would like to point to paragraph [0028] of the Specification which recites: “For example, the presentation service may rank the content items (e.g., based on machine learning techniques), select the content items based on one or more user attributes or content types, or both. The presentation service may store the content (e.g., received via API and the content management system) and pull content to be displayed at the user interface based on the selecting”. Thus, it is understood that based on the established content within the plurality of content items are organized and selected based on the requirements established by the database or means of displaying the content.
It would’ve been obvious to a person with ordinary skill in the art to combine Falivene’s database driven selection technique with Stepanova’s update and display architecture because Stepanova’s system necessarily operates on content items that must be first identified before an update to them can be generated or displayed, and Falivene teaches a known technique, a collaborative content items database in which each object is associated with a counter pointer, for locating and selecting a particular content item from among a plurality of such items.
Claim 10-14 and 18-20 recites substantially the same limitations as those recited in claim 2-6, applied to the method of claim 1, respectively. Thus, for the same reasons presented with respect to claims 2-6, claims 10-14 and 18-20 are rejected as being unpatentable in view of Stepanova in view of Falivene for the same reasons presented with respect to claims 2-6.
Claims 7 and 15 are rejected 35 U.S.C. 103 as being anticipated by Stepanova . (US 2021/0157564 A1) in view of Bern (US 2021/0028829 A1)
Regarding claim 7, Bern teaches,
determining a ranking for the content item using one or more machine learning algorithms, wherein the content item is selected based at least in part on the determined ranking for the content item by teaching ([0003]- “A computing system generates a default view of content items associated with a user account. The default view is representative of an underlying hierarchical structure of the content items associated with the user account. […] The computing system ranks the content items based on a predicted likelihood of the user interacting with the particular content item. The ranking is performed based at least on the user's past activity. The computing system identifies the subset of content items for the modified view based on the ranking. The computing system generates the modified view based on the identified subset of the content items.”
For clarity of the record, the Examiner would like to point to paragraph [0011] of the
Specification which recites: “The presentation service may include or access a database of stored content (or content updates) that the client application may pull from based on an attribute of a user of the client application. For example, the presentation service may include a machine learning (ML) or AI algorithm to rank, select, or both content items to display on the client application on a user device. The presentation service may rank and select the content items based on flagged content of the user, a geolocation of the user, etc. The described techniques provide a unified method to generate and post content items, updates to content items, or both on a client application.”. Thus, it is understood that the ranking process relies on user content and the user’s interaction with said content, to then use a means of generating rank among the content.
It would have been obvious to a person of ordinary skill in the art to incorporate Bern’s known ranking technique into Stepanova’s known update and display system as a prior step for selecting which content items are to receive an update, since doing so is no more than using a known technique to improve a known system. This is done by prioritizing the content items most likely to be relevant to the user, yielding the result of a core relevantly targeted update and display process.
Claim 15 recites substantially the same limitations as those recited in claim 7, applied to the method of claim 1, respectively. Thus, for the same reasons presented with respect to claim 7, claim 15 is rejected as being unpatentable in view of Bern for the same reasons presented with respect to claim 7.
Claims 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Couillard et. al. in view of Falivene (U.S. Patent No. US 2025/0028829 A1).
Regarding claim 8, Couillard et al. teaches the content item is configured to obtain a current characteristic associated with a crypto token ([0077] – “one entity-specific data record that is configured to link at least one entity-specific network data store to at least one entity-specific entity profile. In some embodiments, the at least one entity-specific data record includes a plurality of parameters representing at least one characteristic of the entity, where the plurality of parameters may include, but are not limited to, an entity identifier, an entity name, entity contact data, an entity access status, an entity authentication status, an entity token API, and an entity wire API, and the like.”).
Couillard et al. fails to expressly teach when pulled by the client application for display via the client application, and wherein the content item is configured to display, at the client application, an indication of the current characteristic.
However, Stepanova teaches when pulled by the client application for display via the client application, and wherein the content item is configured to display, at the client application, an indication of the current characteristic ([0087]- “The methods for different product features may be programmed or configured such that the method names, types, parameters, and expected output conform to a standardized format. The support application may be configured to invoke methods and process output data returned by the invoked methods that follow the standardized format. Thus, the support application is able to utilize auxiliary API support methods for any product feature that includes a set of corresponding support methods.”)
Couillard et al and Stepanova are considered to be analogous art to the claimed invention as they are reasonably pertinent to the problem faced by the inventor of obtaining a characteristic via an application and having the content item configured, as a result of that characteristic. Therefore, it would have been obvious to one of ordinary skill in the art that the obtaining of chrematistics of a token taught by Couillard et al could include the displaying of a content idea via that characteristic as taught by Stepanova.
Claim 16 recites substantially the same limitations as those recited in claim 8, applied to the method of claim 1, respectively. Thus, for the same reasons presented with respect to claim 8, claim 16 is rejected as being unpatentable in view of Couillard et al for the same reasons presented with respect to claim 8.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMUEL NWUHA whose telephone number is (571)272-9367. The examiner can normally be reached Monday-Friday; 7:30 am - 5:00pm.
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, Kevin Young can be reached at (571) 270-3180. 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.
/SAMUEL OBINNA NNAJI NWUHA/Examiner, Art Unit 2194
/KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights