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 .
This communication is in response to RCE filed 11/26/2025 of application 18/213,740 filed 6/23/2023. Claims 2-3, 6-9, and 11-12 are canceled. Claims 1, 5, 13, and 21 are amended and hereby entered. Claims 22-28 are added and hereby entered. No claims are allowed.
Response to Arguments
Applicant's arguments filed 11/26/2025 have been fully considered but they are not persuasive.
Regarding USC 101: The applicant submits that the newly amended claims include claim limitations that cannot be practically be performed in the human mind and therefore do not recite an abstract idea. The limitations now an include artificial intelligence model and a user interface with elements chosen by the artificial intelligence model. The artificial intelligence model and user interface are additional elements for consideration in step 2A prong 2 and 2B analysis. However, this does not negate the presence of the abstract idea of a mental process in the application (i.e. receiving information, processing information and displaying the result of analysis). Further, the applicant submits that the operations cannot be performed in the human mind, and are directed to computer centric problems and solutions. However, the use of a computer to perform the abstract idea does not disqualify the claim from reciting a mental process, see MPEP 2106.04(a)(2)(III)(C). Therefore, the examiner respectfully disagrees and the rejection is maintained.
Further, the applicant submits the claims are integrated into practical application because the claims recite advancements to the additional elements of user interfaces and artificial intelligence models. However, the improvement is not directed to the technologies of user interfaces and artificial intelligence themselves; rather, the user interface is simply used to display an element chosen by an artificial intelligence model. There is no improvement to the user interface itself. Rather, the operations presented (payment, request, transfer, etc.) to the user are different. Additionally, the artificial intelligence is used to perform the abstract idea of mental process (i.e. estimating what to present to the user based on prior information). This falls under MPEP section 2106.05(f) “apply it” because the model is recited at a high level of generality (i.e. a trained model inputs data and outputs results). Therefore, the examiner respectfully disagrees and the rejection is maintained.
Further, the applicant submits the claims recite significantly more than the alleged abstract idea. Specifically, the applicant submits the office has not made a prima facie rejection because the office has not established the claim elements constitute “well-understood, routine, or conventional activities”. However, establishing claim elements to be “well-understood, routine, and conventional” relates to the Berkheimer analysis MPEP2106.05(d), which is only necessary when the eligibility determination relies upon the observation of extra solution activity among non-abstract claim elements. The present rejection does not rely upon a determination of extra solution activity; accordingly, the Berkheimer analysis is not relevant, informative or dispositive. The rejection observes an “apply it” level recitation of an abstract idea performed in a general-purpose computer environment, see MPEP 2106.05(f). The additional elements in the claims do not amount to significantly more than the abstract idea for the same reasons they do not amount to a practical application. Therefore, the examiner respectfully disagrees and the rejection is maintained.
Regarding 35 USC 102/103: The applicants amendments have necessitated new grounds for rejection relying on different prior art, rendering applicant’s arguments moot.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 26 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 26 recites, “determining, based on access controls, that a given message in the message thread is to be redacted and causing a given selectable user interface element corresponding to the given message to be redacted”. However, the specification does not contain redacting messages. In the applicant’s arguments filed 11/26/2025, the applicant highlights specification paragraphs [0049], [0050], [0052], [0053], [0067], [0080], and [0081] for support to the features of claims 22-28. Paragraph [0050] discusses “access controls” that route messages to appropriate users for security and efficiency. Access controls are further described in in paragraphs [0086] and [0087], [0111], [0147], [0149], and [0152], allowing selective presentation of communications to certain workers with the appropriate access.
For the purpose of compact prosecution, the claim limitation “determining, based on access controls, that a given message in the message thread is to be redacted and causing a given selectable user interface element corresponding to the given message to be redacted” is interpreted to mean: routing communications or presenting communications based on the appropriate access level of a user, and presenting user interface elements.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 4, 5, 10 and 13-28 are rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) with no practical application and without significantly more.
The claimed invention is directed to an abstract idea in that the instant application is directed to a mental process (See MPEP 2106.04(a)(2)(III)). The independent claims (1, 5, and 13) recite a method and systems to receive and present payment data. These claim elements are being interpreted as concepts performed in the human mind (including observation, evaluation, judgement, and opinion). Receiving payment data, organizing, and presenting the series of financial interactions on a user interface can equivalently be achieved by human observation and evaluation of payment information. The claims recite an abstract idea consistent with the “mental process” grouping set forth in the MPEP 2106.04(a)(2)(III).
The instant application fails to integrate the judicial exception into a practical application because the instant application merely recites an “apply it” (or an equivalent) with the judicial exception, or merely includes instructions to implement an abstract idea. The instant application is directed towards a method and systems to implement the identified abstract idea of receiving information, processing information, and displaying the result of the analysis (i.e. receiving payment data, organizing, and presenting results) on a generically claimed computer structure. The claims do not include additional elements that amount to significantly more than the judicial exception. The independent claims recite the additional elements “one or more processors”, “non-transitory computer-readable media”, “user interface”, and “artificial intelligence model”. These claim elements are recited at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a general computer environment. The machines merely act as a modality to implement the abstract idea and are not indicative of integration into a practical application (i.e., the additional elements are simply used as a tool to perform the abstract idea), see MPEP 2106.05(f).
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed in Step 2A Prong Two analysis, the additional elements in the claims amount to no more than mere instructions to apply the exception using generic computer components. The same analysis applies here in 2B and does not provide an inventive concept.
In regards to the dependent claims
Claims 4, 10, and 14-28 do not introduce any new additional abstract ideas or new additional elements and do not impact analysis under 35 USC 101.
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 4-5, 10, 13-16, 18-22, and 24-28 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Davis (US 20160117670 A1).
Regarding Claim 1, 5, and 13 (substantially similar in scope and language), Davis teaches:
A method comprising: receiving first data indicating a series of interactions between a user account associated with the user and an entity account associated with an entity of a payment service, wherein the series of interactions include at least payments made between the user account and the entity account [see at least Davis: (Para 0059) “For example, the user 102a can use the system 100 to provide a payment to a business for services or products”, (Para 0071) “As shown, the client application 202 can include a user interface manager 206, a user input detector 208, a messaging handler 210, a message analyzer 212, a location detector 214, a payment message generator 216, and a data manager 218. FIG. 2 illustrates that the network application 204 can include a communication manager 230, a status manager 232, a message database 234, a payment manager 236, a transaction database 238, a profile database”]
determining a selectable user interface element to include in a consolidated user interface utilizing a trained artificial intelligence model, [see at least Davis: (Para 0016) “In addition to the foregoing, one or more embodiments include providing selectable elements in an interface of a messaging user interface for setting a payment amount of a payment transaction”, (Para 0231) “In addition to the foregoing, the message analyzer 212 can compute the probability of a payment event using a machine learning model and historical data of other users of the social-networking system who have initiated payment events. In one or more embodiments, the message analyzer 212 trains a machine-learning model using historical data collected for the users, whether each user participated in a payment event, and the type of event…”, (Para 0235) “Based on this determination, the system 100 can provide the user an option to initiate a payment transaction as discussed above. In particular, the system 100 can convert a portion of a message into a payment initiation selectable element…”]
wherein the trained artificial intelligence model: is trained utilizing historical interaction data between multiple user accounts and at least the entity account; [see at least Davis: (Para 0231) “In one or more embodiments, the message analyzer 212 trains a machine-learning model using historical data collected for the users, whether each user participated in a payment event, and the type of event. The machine-learning model can use several data points within the collected data as variables to generate a predictive algorithm”]
is configured to intake the first data and output recommended user interface elements to associate with a consolidated user interface; [see at least Davis: (Para 0234) “The system 100 can compute a probability of a user participating in a payment event based on the user's communications and actions and also based on the training set”, (Para 0235) “Based on this determination, the system 100 can provide the user an option to initiate a payment transaction as discussed above. In particular, the system 100 can convert a portion of a message into a payment initiation selectable element 700. In another example, the user interface manager 206 can convert the entire message 416c into a payment initiation selectable element”]
and reduces communication with the entity account; [The claims recite intended use or result of using the artificial intelligence model that does not carry patentable weight in the claims.]
generating the consolidated user interface such that the consolidated user interface includes selectable user interface elements, that include the selectable user interface element determined utilizing the trained artificial intelligence model, [see at least Davis: (Para 0235) “Based on this determination, the system 100 can provide the user an option to initiate a payment transaction as discussed above. In particular, the system 100 can convert a portion of a message into a payment initiation selectable element 700. In another example, the user interface manager 206 can convert the entire message 416c into a payment initiation selectable element”]
wherein: the selectable user interface elements correspond to a coded representation of the series of interactions, at least one of the selectable user interface elements includes functionality that, when selected, causes the functionality to execute on a user device associated with the user; and [see at least Davis: (Para 0016) “In addition to the foregoing, one or more embodiments include providing selectable elements in an interface of a messaging user interface for setting a payment amount of a payment transaction. Specifically, one or more embodiments provide selectable elements with associated numerical (e.g., currency) values for requesting to initiate a payment transaction in a conversation with another user. In one or more embodiments, selecting one or more of the selectable elements can increment a payment amount of the payment transaction by the corresponding numerical value of each selected element. The selectable elements can allow users to incrementally increase a payment amount in real-time”]
the series of interactions span multiple services and individual ones of the multiple services differ from each other [see at least Davis: (Para 0014) “One or more additional or alternative embodiments include providing options to request payments from a group of users”, (Para 0015) “Additionally, the system and methods described herein can allow a user to initiate a payment transaction without having to first provide a payment credential”, (Figures 4A-4O), (Figures 5A-5D), (Figures 7A-7C)]
causing presentation of the consolidated user interface on the user device with the series of interactions as messages in a message thread, wherein the consolidated user interface is presented utilizing the payment application on a user device and the messages include indicators of the multiple services, and wherein the payment application is provided by the payment service [see at least Davis: (Figures 4A-4O), (Figures 5A-5D), (Figures 7A-7C)]
Regarding Claim 4 and 20, Davis teaches the limitations of claim 1, Davis further teaches:
determining, for a first message of the messages, a first service of the multiple services that is associated with the first message; identifying first functionality associated with the first service; [see at least Davis: (Figure 4C-4D, 4L-4M, and 5C-5D)]
determining, for a second message of the messages, a second service of the multiple services that is associated with the second message; identifying second functionality associated with the second service; [see at least Davis: (Figure 6A-6C and 7A-7B)]
and presenting an indicator of the first functionality with respect to the first message and an indicator of the second functionality with respect to the second message in a standardized format in the message thread. [The limitations recite standardized “functionality” or operations that can be completed, that are associated with messages; see at least Davis: (Para 0078) “The user interface manager 206 can update an available option based on whether a particular options is available at a particular point within the transaction process. The user interface manager 206 can add, remove, and/or update various other selectable actions within the sender and/or receiver status messages, as will be discussed below.
Regarding Claim 10, Davis teaches all the limitations of Claim 5, Davis further teaches:
the operations further comprising: storing the first data in a message index in association with an identifier of the user account and an identifier of the entity account; [see at least Davis: (Para 0091) “In one or more embodiments, the payment message generator 216 can create a data package that includes the payment amount, one or more sender identifiers, one or more recipient identifiers”]
receiving a request for the message thread be displayed via the payment application; [see at least Davis: (Para 0121) “With this information, the payment manager 236 can provide, upon request, a summary of one or more transactions to users as a history of payments requested, payments declined and payments completed”]
determining that the user input data is received in association with the identifier of the user account and the identifier of the entity account; [see at least Davis: (Para 0124) “For example, transaction information can include a transaction ID associated with one or more sender identifiers, recipient identifiers, payment amounts, payment methods (e.g., sender accounts), deposit methods (e.g., recipient accounts), transaction history, current transaction status, as well as other transaction information.”]
querying the message index for the first data; [see at least Davis: (Para 0121) “With this information, the payment manager 236 can provide, upon request, a summary of one or more transactions to users as a history of payments requested, payments declined and payments completed”]
and generating the message thread utilizing the first data, the generating including generating individual ones of the messages for individual ones of the series of interactions. [The limitation recites storing, querying, and retrieving, transaction data from a database to be generated on command; see at least Davis: (Para 0121) “The transaction database 238 of FIG. 2 can provide storage for each transaction (such as in the form of a graph object), attempted or completed, the transaction ID, a date, an amount of the transaction, the payment method used, associated messages interchanged between sender and recipient related to the transaction, and any other information gathered on the transaction. With this information, the payment manager 236 can provide, upon request, a summary of one or more transactions to users as a history of payments requested, payments declined and payments completed.”]
Regarding Claim 14, Davis teaches all the limitations of claim 13, Davis further teaches:
wherein the entity includes at least one of: another user involved in peer-to-peer payments with the user; a merchant involved in providing a product to the user; a group of users; the product; or the payment service [see at least Davis: (Para 0059) “While FIG. 1 illustrates the users as people, the users may include other entities, such as business, government, or other entities. For example, the user 102a can use the system 100 to provide a payment to a business for services or products. For instance, the user 102a can communicate with a business via the system 100, and ultimately decide to make a purchase of a product or service from the business. Using the same system 100, the user 102b can then send a payment for the product or service to the business. Similarly, a business may send a payment to other businesses or vendors, whether an individual or a business entity.”]
Regarding Claim 15, Davis teaches all the limitations of claim 13. Davis further teaches:
generating an overlay that includes one or more trust indicators; [see at least Davis: (Para 0156) “FIG. 4A illustrates a people or contacts user interface 404 provided by the user interface manager 206 on the touch screen 402. The contacts user interface 404 can provide a list of contacts of a user (“Donald”) of the client device 400. In particular, the contacts user interface 404 can list “friends” or contacts 406 with which the user is connected or associated within the system”]
and causing the overlay to be displayed in association with the message thread such that that overlay is configured to remain on a portion of a screen of the user device while scrolling functionality is utilized with respect to the messages; [(Figure 4B-4D)]
Regarding Claim 16, Davis teaches all the limitations of claim 13, Davis further teaches:
wherein the series of interactions is associated with one or more of: sending a gift card; receiving the gift card; sending stock; receiving stock; sending cryptocurrency; or receiving cryptocurrency. [(Para 0362) “As another example and not by way of limitation, content objects may include incentive content objects, such as coupons, discount tickets, gift certificates, or other suitable incentive objects”]
Regarding Claim 18, Davis teaches all the limitations of claim 13. Davis further teaches:
receiving a request for a summary of the series of interactions associated with the message thread; [see at least Davis: (Para 0121) “With this information, the payment manager 236 can provide, upon request, a summary of one or more transactions to users as a history of payments requested, payments declined and payments completed”]
determining first payments made to the user account from the entity account; determining second payments made to the entity account from the user account; [see at least Davis: (Para 0120) “ In any event, upon receipt of a payment message from a sender, the payment manager 236 can detect the user (or group) ID of the sender and retrieve the payment profile for that user (or entity). The payment manager 236 can then generate a transaction package that includes a transaction ID associated with a payment amount, the sender, and the recipient…”, (Para 0124) “As previously mentioned, the network application 204 can include a transaction database 238 that maintains transaction information for each payment message received via a client device 104a. For example, transaction information can include a transaction ID associated with one or more sender identifiers, recipient identifiers, payment amounts, payment methods (e.g., sender accounts), deposit methods (e.g., recipient accounts), transaction history, current transaction status, as well as other transaction information. In one or more embodiments, the transaction information is maintained in the form of one or more graph objects that are updated with any updates or actions with respect to a transaction.”]
generating a first user interface element displaying an amount of the first payments and an amount of the second payments; [see at least Davis: (Para 0075) “More particularly, the user interface manager 206 may direct the client device 104a, 104b to display a group of graphical components, objects and/or elements that enable a user to view a communication thread”, (Para 0077) “As discussed above, one example of content that can be included in a message is a payment from a sender user to a recipient user. In one or more embodiments, the user interface manager 206 can provide a user interface to allow a user to easily and efficiently define and send a payment to one or more other users”, (Para 0120) “The payment manager 236 can then generate a transaction package that includes a transaction ID associated with a payment amount, the sender, and the recipient”]
generating a second user interface element displaying a total number of transactions between the user account and the entity account; [see at least Davis: (Para 0121) “With this information, the payment manager 236 can provide, upon request, a summary of one or more transactions to users as a history of payments requested, payments declined and payments completed”]
and causing the consolidated user interface to display the first user interface element and the second user interface element on the user device via the payment application. [see at least Davis: (Para 0078) “In addition to the forgoing, the user interface manager 206 can receive instructions or communications from one or more components of the communication application 202 to display updated message information, updated status of the payment, and/or updated available actions”]
Regarding Claim 19, Davis teaches all the limitations of claim 13, Davis further teaches:
further comprising: identifying, for a message of the messages, a set of functionality associated with the message; [see at least Davis: (Figures 4A-4C), (Para 0167) “the user interface manager 206 may also provide a message input control palette or toolbar 422. As illustrated in FIG. 4B, the user interface manager 206 displays the message input control palette or toolbar 422 as part of the messaging graphical user interface 412. In one or more embodiments, the message input control palette or tool bar 422 includes a variety of selectable message input controls that provide a user with various message input options or other options. For example, in FIG. 4B, the message input control palette or toolbar 422 includes a text input control 424a, a payment control 424b, a camera viewfinder input control 424c, a multimedia input control 424d, a symbol input control 424e, and a like indicator control 424f. In one or more alternative embodiments, the message input control palette or toolbar 422 may provide the input controls 424a-424e in a different order, may provide other input controls not displayed in FIG. 4B, or may omit one or more of the input controls 424a-424e shown in FIG. 4B.”]
causing presentation, within the message thread, of the selectable user interface element corresponding to the functionality; receiving a selection of the selectable user interface element; and performing an action corresponding to the set of functionality based at least in part on receiving the selection, wherein performing the action includes updating the message thread to show that the action has been performed [see at least Davis: (Figures 4A-4C), (Para 0168) “As will be described below in greater detail, a user may interact with any of the input controls 424a-424e in order to compose and send different types of electronic communications. For example, if a user interacts with the text input control 424a, the user interface manager 206 may provide a touch screen display keyboard 418 in a portion of the messaging graphical user interface 412 that the user may utilize to compose a textual message 420. Similarly, if a user interacts with the multimedia input control 424d, the user interface manager 206 may provide a multimedia content item display area (e.g., for displaying digital photographs, digital videos, etc.) within a portion of the messaging graphical user interface 412. Likewise, if a user interacts with the camera viewfinder input control 424c, the user interface manager 206 may provide a digital camera interface within a portion of the messaging graphical user interface 412 that the user may utilize to capture, send, and add a digital photograph or digital video to the communication thread”, (Para 0169) “A user may interact with any of the message input controls 424a-e in order to compose and send a message or a payment to one or more co-users via the system 100. For example, in FIG. 4B, a user's finger is shown interacting with the payment control 424b. In one or more embodiments, the user input detector 208 can detect interactions (e.g., a tap touch gesture) of the user's finger or other input device with the payment control 424b. Upon the user input detector 208 detecting a tap touch gesture on the payment control 424b, the user interface manager 206 may display a payment user interface 415 within a portion of the messaging user interface 414 as shown by FIG. 4C.”]
Regarding Claim 21, Davis teaches all the limitations of claim 13, Davis further teaches:
further comprising: determining that user input data caused an update to a data object associated with the selectable user interface element; and generating an updated selectable user interface element indicating the update, the updated selectable user interface element replacing the selectable user interface element in the message thread. [see at least Davis: (Figures 4A-4O) (Para 0169) “A user may interact with any of the message input controls 424a-e in order to compose and send a message or a payment to one or more co-users via the system 100. For example, in FIG. 4B, a user's finger is shown interacting with the payment control 424b. In one or more embodiments, the user input detector 208 can detect interactions (e.g., a tap touch gesture) of the user's finger or other input device with the payment control 424b. Upon the user input detector 208 detecting a tap touch gesture on the payment control 424b, the user interface manager 206 may display a payment user interface 415 within a portion of the messaging user interface 414 as shown by FIG. 4C.”]
Regarding Claim 22, Davis teaches all the limitations of Claim 1, Davis further teaches:
further comprising: generating an artificial intelligence model configured to output the recommended user interface elements to associate with a consolidated user interface; [see at least Davis: (Para 0231) “In one or more embodiments, the message analyzer 212 trains a machine-learning model using historical data collected for the users, whether each user participated in a payment event, and the type of event. The machine-learning model can use several data points within the collected data as variables to generate a predictive algorithm. For example, the machine-learning model can analyze messages sent or received or other actions that a first user or users performed before initiating a payment. The message analyzer 212 can then provide a second user the option to participate in a payment event upon recognizing that the second user has performed the same or similar actions”]
generating a training dataset from the historical interaction data, wherein the training dataset is generated in a format that differs from the historical interaction data; and [see at least Davis: (Para 0232) “In one or more embodiments, the system 100 can generate the training set for training the machine-learning model based on content obtained via one or more users' social-networking profiles or other profiles associated with the system 100. For example, the system 100 can identify users of the social networking system that have performed a payment transaction. The system 100 can then collect information about such users, such as location, messages exchanged, check-ins, social network posts, etc. prior to conducting the payment transaction. Thus, the system can collect communications data, social-network data, and other information that identifies or is associated with the users”]
training the artificial intelligence model utilizing the training dataset such that the trained artificial intelligence model is generated [see at least Davis: (Para 0234) “The system 100 can compute a probability of a user participating in a payment event based on the user's communications and actions and also based on the training set”]
Regarding Claim 24, Davis teaches all the limitations of Claim 22, Davis further teaches:
wherein training the artificial intelligence model causes improvement to features associated with the artificial intelligence model [the limitations recite intended results of training that do not carry patentable weight in the claims;]
Regarding Claim 25, Davis teaches the all the limitations of claim 1, Davis further teaches:
further comprising: converting the first data representing the series of interactions into converted first data having a standardized format configured to enable threading of the messages; [see at least Davis: (Para 0122) “In one or more embodiments, for example, upon receiving a payment message the payment manager 236 can generate a transaction identifier (or simply “transaction ID”) and associate the transaction identifier with the payment message and/or the payment information within the payment message. For instance, upon generating a transaction ID, the payment manager 236 can send the transaction ID and the payment information to a transaction database 238. The transaction database 238 can include a data table or similar data matrix that stores transaction information according to transaction ID”]
storing converted first data in a data store; [see at least Davis: (0124) “As previously mentioned, the network application 204 can include a transaction database 238 that maintains transaction information for each payment message received via a client device”, (Para 0357) “Data stores may be used to store various types of information. In particular embodiments, the information stored in data stores may be organized according to specific data structures. In particular embodiments, each data store may be a relational, columnar, correlation, or other suitable database. Although this disclosure describes or illustrates particular types of databases, this disclosure contemplates any suitable types of databases”]
and parsing the data store for a portion of the converted first data based at least in part on determining the selectable user interface element, and wherein generating the consolidated user interface is performed utilizing the portion of the converted first data. [see at least Davis: (Para 0121) “With this information, the payment manager 236 can provide, upon request, a summary of one or more transactions to users as a history of payments requested, payments declined and payments completed”, (Para 0357) “Particular embodiments may provide interfaces that enable a client system 1906, a social-networking system 1902, or a third-party system 1908 to manage, retrieve, modify, add, or delete, the information stored in data store”]
Regarding Claim 26, Davis teaches all the limitations of claim 1, Davis further teaches:
further comprising: determining one or more access controls are associated with the consolidated user interface; [see at least Davis: (Para 0386) “A privacy setting of an object may specify how the object (or particular information associated with an object) can be accessed (e.g., viewed or shared) using the online social network”, (Para 0133) “Alternatively to validate the user, the client application 202 can obtain, identify, or otherwise discover a user identifier for the sender for the network application 204. For example, the client application 202 can access an obfuscated (e.g., hashed, encrypted, or otherwise algorithmically transformed) user identifier of the user existing on the computing device 104a of the sender”]
determining, based at least in part on the one or more access controls, that a given message in the message thread is to be redacted; [See rejection 112(a) for lack of written description and claim interpretation; see at least Davis: (Para 0351) “Also, the social-networking system may allow users to post photographs and other multimedia content items to a user's profile page (typically known as “wall posts” or “timeline posts”) or in a photo album, both of which may be accessible to other users of the social-networking system depending upon the user's configured privacy settings”, (Para 0386) “A privacy setting of an object may specify how the object (or particular information associated with an object) can be accessed (e.g., viewed or shared) using the online social network”]
and causing a given selectable user interface element corresponding to the given message to be redacted. [See rejection 112(a) for lack of written description and claim interpretation; see at least Davis: (Para 0386) “In particular embodiments, privacy settings may allow users to opt in or opt out of having their actions logged by social-networking system 1902 or shared with other systems (e.g., third-party system 1908). In particular embodiments, the privacy settings associated with an object may specify any suitable granularity of permitted access or denial of access. As an example and not by way of limitation, access or denial of access may be specified for particular users (e.g., only me, my roommates, and my boss)”, (Para 0127) “In particular, and as described above, the sender can access one or more user interfaces that allow the sender to define a payment to be made to a recipient user”]
Regarding Claim 27, Davis teaches all the limitations of claim 1, Davis further teaches:
further comprising: receiving user input data indicating selection of the selectable user interface element from the message thread; and [see at least Davis: (Figures 4A-4O), (Para 0169) “ A user may interact with any of the message input controls 424a-e in order to compose and send a message or a payment to one or more co-users via the system 100. For example, in FIG. 4B, a user's finger is shown interacting with the payment control 424b. In one or more embodiments, the user input detector 208 can detect interactions (e.g., a tap touch gesture) of the user's finger or other input device with the payment control 424b. Upon the user input detector 208 detecting a tap touch gesture on the payment control 424b, the user interface manager 206 may display a payment user interface 415 within a portion of the messaging user interface 414 as shown by FIG. 4C.”]
executing the functionality of a service of the multiple services based at least in part on receiving the user input data, wherein executing the functionality causes the payment application to perform the functionality without navigating the user device to another application associated with the functionality. [see at least Davis: (Figures 4A-4O)]
Regarding Claim 28, Davis teaches all the limitations of claim 1, Davis further teaches:
further comprising: determining that a number of the interactions exceeds a threshold number of interactions; and [see at least Davis: (Para 0245) “In one or more implementations, the system 100 can use any information related to an electronic message to identify a past, present or a future group event… In some instances, the system 100 can utilize user interaction information, such as information associated with comments or “likes” corresponding to the electronic message…]
identifying a subset of the interactions for inclusion in the consolidated user interface based at least in part on the number of the interactions exceeding the threshold number of interactions, and wherein generating the consolidated user interface comprises generating the consolidated user interface to include the subset of the interactions. [see at least Davis: (Para 0169) “In one or more embodiments, the user input detector 208 can detect interactions (e.g., a tap touch gesture) of the user's finger or other input device with the payment control 424b. Upon the user input detector 208 detecting a tap touch gesture on the payment control 424b, the user interface manager 206 may display a payment user interface 415 within a portion of the messaging user interface 414 as shown by FIG. 4C.”]
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 (i.e., changing from AIA to pre-AIA ) 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.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Davis (US 20160117670 A1) in view of Maeng (US 20240211931 A1).
Regarding claim 17, Davis teaches all the limitations of claim 13. While Davis teaches a consolidated messaging and payment method, it does not teach but Maeng does teach:
further comprising: receiving an indication of a first interaction of the series of interactions requesting a payment from the user account; [(0005) “The method includes receiving, by a processor of a payment processing system, a message, the message requesting payment from a mobile wallet account of a mobile wallet user.”]
determining that the first interaction is indicated as being fraudulent; [(Para 0045) “For example, provider system 150 may assess the likelihood that the transaction is fraudulent”]
generating a message of the messages associated with the first interaction, the message indicating details of the first interaction and indicating that the first interaction is indicated as being fraudulent; [(Para 0046) “In various embodiments, this communication may occur in real time within a chat feature of a mobile application which may be facilitated by the mobile wallet provider (e.g., a mobile wallet application implemented by the mobile wallet provider system 150), via text message, or via telephone call.”]
and associating first functionality with the message, the first functionality enabling review of the first interaction, the first functionality differing from second functionality enabling payment of an amount requested by the first interaction. [(Para 0048) “During the communication between the mobile wallet user and the approver, the approver may question the mobile wallet user regarding the details of the transaction. For example, a communication prompt transmitted by the mobile wallet provider system 150 to the approver system 130 may enable the approver to ask the mobile wallet user to provide justification for the purchase or to suggest an alternative purchase… Any responses from the mobile wallet user may be transmitted by an application (e.g., the mobile wallet circuit 120) on the mobile device 160 to the mobile wallet provider system 150, which may in turn transmit a request for approval to the approver system 130”]
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the payment method taught by Davis with fraud detection taught by Maeng. It is well within the capabilities of one of ordinary skill in the art and common in the art to utilize fraud detection methods within a payment method and system, yielding predictable results. The invention is merely a combination of old elements and in combination each element would have performed the same function as it did separately.
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over Davis (US 20160117670 A1) in view of Dimson (US 20180373794 A1).
Regarding Claim 23, Davis teaches all the limitations of claim 22. While Davis teaches a training a machine learning model, it does not explicitly teach but Dimson does teach:
further comprising: receiving feedback data indicating performance of the trained artificial intelligence model; and retraining the trained artificial intelligence model utilizing the feedback data, and wherein determining the selectable user interface element is performed utilizing the trained artificial intelligence model as retrained. [see at least Dimson: (Para 0051) “The ephemeral message training module 254 can retrain the machine learning model based on new or updated training data. For example, if information about new ephemeral message threads, new ephemeral messages, and/or new users becomes available, the ephemeral message training module 254 can train the machine learning model based on the information about new ephemeral message threads, new ephemeral messages, and interactions of new users therewith. Engagement of users with ephemeral message threads and/or ephemeral messages can be measured and used to train or retrain the machine learning model, for example, as a part of the training data. In some cases, users can provide feedback relating to ephemeral message threads and/or ephemeral messages, and feedback by users can be used to train or retrain the machine learning model, for example, as a part of the training data.”]
Further, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine machine model training (Davis) with retraining a model based on feedback (Dimson). One of ordinary skill would have recognized retraining the model based on feedback would have yielded predictable results of providing more accurate outputs.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Examiner Benjamin Truong, whose telephone number is 703-756-5883. The examiner can normally be reached on Monday-Friday from 9 am to 5 pm (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, Nathan Uber SPE can be reached on 571-270-3923. 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.
/B.L.T./
Examiner, Art Unit 3626
/NATHAN C UBER/Supervisory Patent Examiner, Art Unit 3626
Prosecution Insights