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 .
DETAILED ACTION
This Office Action is in response to an AMENDMENT entered March 12, 2026 for the patent application 18/776,932. Claims 1 – 20 are pending in the application.
Response to Arguments
Examiner would like to point out that the Supreme Court in KSR International Co. v. Teleflex Inc. described seven rationales to support rejections under 35 U.S.C. 103:
Combining prior art elements according to known methods to yield predictable results;
Simple substitution of one known element for another to obtain predictable results;
Use of known technique to improve similar devices (methods, or products) in the same way;
Applying a known technique to a known device (method, or product) ready for improvement to yield predictable results;
“Obvious to try” –choosing from a finite number of identified, predictable solutions, with a reasonable expectation of success;
Known work in one field of endeavor may prompt variations of it for use in either the same field or a different one based on design incentives or other market forces if the variations would have been predictable to one of ordinary skill in the art; and
Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference or to combine prior art reference teachings to arrive at the claimed invention.
Prior art is not limited just to the references being applied, but includes the understanding of one of ordinary skill in the art. The prior art reference (or references when combined) need not teach or suggest all the claim limitations; however, Office personnel must explain why the difference(s) between the prior art and the claimed invention would have been obvious to one of ordinary skill in the art. The “mere existence of differences between the prior art and an invention does not establish the invention’s nonobviousness.” see Dann v. Johnson, 425 U.S. 219, 230 (1976).
Applicant's arguments filed with an Amendment on March 12, 2026 have been fully considered but they are not persuasive.
Applicant Argument:
“Applicant respectfully submits that claims 1-20 are patent eligible under Step 2A, Prong One, because the claims do not recite an abstract idea. On page 3, the Office Action alleges that the recited limitations fall within the "Certain Methods of Organizing
Human Activity" grouping of abstract ideas. Applicant respectfully disagrees.“, (see page 10 of the Remarks).
Examiner’s Response:
Examiner respectfully disagrees. The 2019 Revised Patent Subject Matter Eligibility Guidance ("2019 PEG") states that a category of abstract ideas is a "Certain Methods Of Organizing Human Activity", which are concepts relating to the economy and commerce, such as agreements between people in the form of contracts, legal obligations, and business relations. The method for identifying, by at least one computing device, a payment request derived from a text message, the text message being generated by a client device; determining, by the at least one computing device, a user identifier, a first entity identifier, and a second entity identifier associated with the payment request, falls under the category of concepts relating to business relations and commerce. Abstract ideas are not limited to ideas that may be characterized as economic principles; nor are abstract ideas limited to the examples set forth in Alice, i.e., fundamental economic practices, certain methods of organizing human activities, an idea of itself, and mathematical relationships or formulae.
Applicant Argument:
“Applicant respectfully submits that even if the claims did recite a judicial exception or an abstract idea, an assertion with which Applicant strongly disagrees, claims 1-20 would still be patent eligible under Step 2A, Prong Two, because claims 1-20 recite a
technical solution to a technical problem.“, (see page 13 of the Remarks).
Examiner’s Response:
Examiner respectfully disagrees. The claims does not include an inventive concept sufficient to transform the claimed abstract idea into a patent-eligible invention. This judicial exception is not integrated into a practical application. In particular, the claim only recites one additional element – computing device to perform both the determining and identifying steps. The computing device in both steps is recited at a high-level of generality (i.e., as a generic computing device performing a generic computer function of facilitating the request for the client device) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Applicant Argument:
“Even if the pending claims were directed to an abstract idea - an assertion or contention with which Applicant strongly disagrees -they still amount to significantly more than an abstract idea because the claims contain an inventive concept..“, (see page 16 of the Remarks).
Examiner’s Response:
Examiner respectfully disagrees. In the claims included individually or as an ordered combination limitations that are “significantly more” than the abstract idea itself. This includes analysis as to whether there is an improvement to either the “computer itself,” "another technology,” the "technical field,” or significantly more than what is “well-understood, routine, or conventional” in the related arts. The USPTO 2019 Revised Patent Subject Matter Eligibility Guidance lists included tables and appendices examples of what has been considered by the Courts to be generic computer functioning and not “significantly more” than what is well-understood, routine, and conventional in the field of endeavor. These examples, a non-exhaustive illustrative list, constitute the basis for the findings below. In step two as per Alice, consideration of the elements of each claim both individually and “as an ordered combination” is set forth to determine whether the additional elements “transform the nature of the claim” into a patent-eligible application. Alice, 134 S. Ct. at 2355.
Re: Claim 8, the applicant asserts that cited prior art do not teach – “querying, by the at least one computing device, a first entity computing device for a first list of billing accounts based at least in part on the user identifier and the first entity identifier.“, (see page 19 of the Remarks).
The Examiner respectfully disagrees, JE does discloses “querying, by the at least one computing device, a first entity computing device for a first list of billing accounts based at least in part on the user identifier and the first entity identifier.“ at (JE, [0165] – In operation 813, if a payment electronic device is selected by the user, the first electronic device 810 may deliver order information to the payment server 820 (or a billing server). According to an embodiment, order information may include information related to a product that the user desires to purchase in a content being displayed (or reproduced) by the first electronic device 810. According to an embodiment, order information may include at least one of a product dealer, a product type, a product name, a product quantity, or a payment amount. According to an embodiment, the first electronic device 810 may deliver information (e.g., a user key, or a GUID) related to a user account which is currently logging in to the first electronic device 810 (or a user account pre-registered in the first electronic device 810). For example, the first electronic device 810 may provide the payment server 820 with information on which electronic device is to be used to perform payment, based on the GUID delivered to the server 840 in operation 803.), with further emphasis at (JE, [0091], [0154], - In an embodiment, Table 1 may refer to an example of information managed by the server 840. As illustrated in Table 1, Table 1 shows an example of registering three accounts in the server 840. For example, the server 840 may store account information related to a first user account (e.g., testl@samsung.com), a second user account (e.g., sonl@sam.com), and a third user account (e.g., wife@sung.com).).
Re: Claim 8, the applicant asserts that cited prior art do not teach – “querying, by the at least one computing device, a second entity computing device for a second list of funding accounts based at least in part on the user identifier and the second entity identifier.“, (see page 20 of the Remarks).
The Examiner respectfully disagrees, JE does discloses “querying, by the at least one computing device, a second entity computing device for a second list of funding accounts based at least in part on the user identifier and the second entity identifier.“ at (JE, [0011] – In accordance with another example aspect of the disclosure, an electronic device may include: a communication interface comprising communication circuitry; a dis-play; at least one processor operatively connected to the display and the communication interface; and at least one memory electrically connected to the processor, wherein the memory is configured to store instructions that, when executed by the processor, control the electronic device to: display, on the display, a content and a user interface configured to receive a payment request related to the content; receive a first input related to the payment request through the user interface; transmit information related to the first input to an external server through the connumeration interface; receive, from the external server, a list of at least one external electronic device having a payment function and related to an account of a user; display the list on the display; receive a second input for selection of one external electronic device among the at least one external electronic device of the list; and transmit information on the second input to the external server through the communication interface.), with further emphasis at (JE, [0090], According to an embodiment, the server 350 may
determine a payment-capable device capable of performing payment among multiple electronic devices, and may pro-vide the first electronic device 310, which has made a payment request, with information on the determined payment-capable device, or a list including the information on the determined payment-capable device. According to an embodiment, if one electronic device (e.g., a payment electronic device selected from among the payment-capable devices) is selected by the first electronic device 310, the server 350 may determine the selected payment-capable device as a payment electronic device (e.g., the second electronic device 320), and may control the relevant payment electronic device (e.g., the second electronic device 320) to proceed with a process related to payment. In various embodiments, the server 350 may refer, for example, to a device, such as, for example, and without limitation, central control equipment, a hub, an artificial intelligent device, a cloud server, or the like, which can be connected to neigh-boring electronic devices and can communicate with and control the connected neighboring electronic devices.).
Re: Claim 8, the applicant asserts that cited prior art do not teach – “identifying, by the at least one computing device, a billing account and a funding account that matches a set of identity matching criteria based at least in part on the first list of billing accounts and the second list of funding accounts.“, (see page 21 of the Remarks).
The Examiner respectfully disagrees, Garrison does discloses “identifying, by the at least one computing device, a billing account and a funding account that matches a set of identity matching criteria based at least in part on the first list of billing accounts and the second list of funding accounts.“ at (Garrison, col. 7, lines 32 – 53 – RPP 3 initiates merchant identification by step 60 which retrieves a payment record from one of the payment records previously submitted by the source 7. At step 62, the RPP first attempts to retrieve a merchant record from the merchant database 18 by matching the merchant id included in the payment record against the records of the merchant database 18. If there is a match, then at step 63 processing of the payment record continues to the payment directions stage 64. The payment directions stage is where the RPP determines where to send payments. This stage includes account ranging discussed below which determines the remittance center to which payment gets sent. If there is no match at step 63, the RPP continues to step 65. At step 65, the RPP maps the merchant's merchant name and address, excluding the pro-vided street address and zip code, into an eleven digit zip code. That is, the RPP produces an eleven digit zip code based on merchant name, city, and state in the payment information. In order to avail the merchant information which the inventors have determined to be mostly likely to contain errors, the received merchant street address and zip code are not considered. Hence, in step 65 the RPP 3 identifies an eleven digit zip code based only on the merchant's name, city, and state.), with further emphasis at (Garrison, cols. 6 - 7, lines 54 – ? – After receiving payment requests from sources 7, the RPP 3 periodically initiates a payment cycle 20 which process the records to generate information which will be used by the payment processing system 25 to credit merchant accounts and advise the merchant systems of the payments. The processing flow of the billing cycle contains, in addition to other processes, three particularly important processes necessary for successful processing of each payment request. These processes are merchant identification 19a, account ranging 19b, and account scheming 19c, typically performed in this order. In the first step of processing a payment request, the processor 17 attempts to identify a merchant in the merchant database 18 based on information in the payment request. In the second step, the processor 17 will attempt to determine a remittance center of the merchant to which the payment and/ or payment information is to be sent. If a candidate remittance center is identified, the system enters the third stage of processing, account scheming. In account scheming, the processor 17 attempts to normalize a user account with a merchant according to the merchant's rules. If account scheming fails, the system will return to the account ranging process to attempt to identify another candidate remittance center, and from there, again into account scheming.).
Re: Claim 15, the applicant asserts that cited prior art do not teach – “determine a first entity identifier associated with the command based at least in part on a first character input and the chat template.", (see page 23 of the Remarks).
The Examiner respectfully disagrees, Finneran does discloses “determine a first entity identifier associated with the command based at least in part on a first character input and the chat template." at (Finneran, [0241] – User interface 1910 request information from the user regarding a few potential accounts that could be added to the credit data of the consumer. The user interface request that the user confirm that payments to the identified payees are actually made by the user and, accordingly, could properly be used in calculating credit worthiness of the user. In this embodiment, if the user does not recognize payees listed, those payees can be removed by clicking the acts the right of the payee data identifiers.), with further emphasis at (Finneran, [0040] – In some embodiments, the system may interact with the user via a chat window (for example, a pop-up window) that may be operated by a chatbot to request the information needed from the user and/or provide the user with educational information regarding the process. In some embodiments, such chatbots may be entirely automated (for example, using artificial intelligence that learns how to best interact with users over time) or may be partially operated by a human operator (for example, when the chatbot is unsure of how to respond to a query from the user). Similarly, any other user interactions discussed herein may be partially or fully performed via a conversational format, with a chatbot (for example, fully or partially automated) interacting with the user via primarily textual communications. FIGS. 14-18 illustrates example embodiments of such chat-like communications.).
Re: Claim 15, the applicant asserts that cited prior art do not teach – “determine a second entity identifier associated with the command based at least in part on a second character input and the chat template.“, (see page 24 of the Remarks).
The Examiner respectfully disagrees, Finneran does discloses “determine a second entity identifier associated with the command based at least in part on a second character input and the chat template.“ at (Finneran, [0247] – Since there are a few missing payments, the user may want to review the payment transaction items that were identified by the account identification component 114 to determine if some of those missing payments can be located (for example, in another DDA account of the user). Similarly, the user may want to provide the account identification component 114 with additional information regarding payments made to the payee, such as an alternate payee identifier that may have been used in certain transaction data items. As another example, the user may want to authorize access to another DDA account where payments to the payee may also be located. Through these processes, the user may improve the payment history associated with the account and, accordingly, may further increase a score impact by addition of the account to credit data of the user. In some implementations, a user interface such as FIG. 24B, which displays missing payments associated with a particular account, may not be displayed to the user until after the account is added as a trade line to the credit data of the user.), with further emphasis at (Finneran, [0214] – In some embodiments, the account identification
component 114 performs a normalization and/or standardization process on data values of the transaction data items. For example, standardization may include removal of certain special characters (for example, symbols), correction of typographical errors (for example, which could catch the typo "Retails" and correct to "Rentals") and/or perform other standardization processes. A normalization process may involve accessing a payee data structure associating a normalized payee identifier with one or multiple possible payee identifiers that could be located in transaction data items. Example, the payee data structure could include a standard payee identifier of "ABC Rentals" that is associated with multiple variations of that payee identifier, such as "ABC Rental", "ABC-Rentals", "ABC Rentals Inc.", and so forth. In this way, the account identification component 114 can more accurately associate transaction data items that are
each involve a common payee.).
Re: Claim 15, the applicant asserts that cited prior art do not teach – “generate a biometric identify scan for verifying a biometric identify of a user.“, (see page 25 of the Remarks).
The Examiner respectfully disagrees, JE does discloses “generate a biometric identify scan for verifying a biometric identify of a user.“ at (JE, [0095] – According to an embodiment, the authentication server 390 may, for example, be a server related to authentication for user verification. According to an embodiment, if the authentication server 390 proceeds with payment in relation to the second electronic device 320, the authentication server 390 may process user authentication based on biometric information (e.g., registered fingerprint information, registered iris information, etc.) (or based on biometric authentication). According to an embodiment, the authentication server 390 may perform user verification based at least on at least one authentication scheme among, for example, and without limitation, a pin-based authentication scheme, an online authentication-based (e.g., a scheme, such as communication company authentication) scheme, an online biometric authentication (e.g., fast identity online (FIDO))-based scheme, or the like. According to an embodiment, the authentication server 390 may transmit a result of the authentication related to the payment by the user (or the second electronic device 320), to the card company server 380 and/or the payment agency server 360., with further emphasis at (JE, [0170] – In operation 823, a user verification process may be performed. According to an embodiment, the user verification process may be performed based on at least one authentication scheme among, for example, a pin-based authentication scheme, a biometric authentication-based scheme, an online authentication-based scheme (e.g., a scheme such as communication company authentication), and an online biometric authentication (e.g., FIDO)-based scheme. According to an embodiment, the second electronic device 850 may perform biometric authentication using a biometric signal detected from the user. For example, the second electronic device 850 may scan the user's biometric information (e.g., a fingerprint, an iris, or a face) based on a biometric sensor (e.g., a fingerprint recognition sensor, an iris recognition sensor, or a face recognition sensor) of the second electronic device 850, and may perform user authentication based on the scanned biometric information (e.g., an image). According to an embodiment, the second electronic device 850, together with the card company server 860 (or an authentication server, e.g., a FIDO server, (not illustrated)), may perform online biometric authentication (e.g., FIDO). According to an embodiment, as a result of the biometric authentication, an authentication server (e.g., a FIDO server) may transmit random data to the second electronic device 850.).
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.
Claim(s) 1 – 20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1 - 20 are either directed to a method or system or computer readable medium, which are statutory categories of invention. (Step 1: YES).
The Examiner has identified method claim 8 as the claim that represents the claimed invention for analysis and is similar to system claims 1 and 15. Claim 8 recites the limitations of:
( A ) identifying, by at least one computing device, a payment request derived from a text message, the text message being generated by a client device;
( B ) determining, by the at least one computing device, a user identifier, a first entity identifier, and a second entity identifier associated with the payment request;
( C ) querying, by the at least one computing device, a first entity computing device for a first list of billing accounts based at least in part on the user identifier and the first entity identifier;
( D ) querying, by the at least one computing device, a second entity computing device for a second list of funding accounts based at least in part on the user identifier and the second entity identifier;
( E ) identifying, by the at least one computing device, a billing account and a funding account that matches a set of identity matching criteria based at least in part on the first list of billing accounts and the second list of funding accounts; and
( F ) executing, by the at least one computing device, the payment request based at least in part on the identification of the billing account and the funding account.
These limitations without the bolded limitations above, cover performance of the limitations as certain methods of organizing human activity under their broadest reasonable interpretation.
More specifically, these limitations cover performance of the limitations as a fundamental economic practice.
In summary, if claim 8 limitations, under its broadest reasonable interpretation, covers performance of the limitation as a fundamental economic practice, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Claims 1 and 15 are also abstract for similar reasons. (Step 2A-Prong 1: YES. The claims are abstract).
The use of the computing device or any of the bolded limitations in claim 1 are just applying generic computer components to the recited abstract limitations. Similar arguments apply to claims 1 and 15.
Therefore, the above mentioned judicial exception is not integrated into a practical application by merely applying generic computer components (bolded elements).
Furthermore, the “identifying” and “querying” steps are recited at a high level of generality and amounts to mere data gathering/transmitting, which are forms of insignificant extra-solution activity (See MPEP 2106.05(g): CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375 (Fed. Cir. 2011); and OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)).
In addition, supported by specification, the computer hardware are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer component., see MPEP 2106.05(f), where applying a computer or using a computer is not indicative of a practical application).
Claim 8, limitation ( A ) – ( F ) above in Applicant’s specification para [0021], which discloses “The computing environment 203 can include one or more computing devices that include a processor, a memory, and/or a network interface. For example, the computing devices can be configured to perform computations on behalf of other computing devices or applications. As another example, such computing devices can host and/or provide content to other computing devices in response to requests for content.“.
Also, claim 8, limitation ( A ) above in Applicant’s specification para [0024], which discloses “The payment service 218 can be executed to facilitate the execution of a payment request received from the client device 212 during a chat session. The payment request can be received from the client device 212 and can be interpreted in order to execute the payment request. The payment service 218 can involve interpreting the payment request by identifying entity identifiers, payment parameters, and other suitable payment data from the payment request. The payment service 218 can retrieve additional information (e.g., funding client account numbers, billing client numbers, etc.) needed in order to execute the payment information.“.
Also, claim 8, limitation ( C ) and ( D ) above in Applicant’s specification para [0027], which discloses “The client account data 242 can represent accounts associated with the user that have been retrieved from the first entity computing device 206, the second entity computing device 209, and from other suitable data sources. For example, the client accounts can include billing client accounts, funding client accounts, and other types of user accounts. The device data 245 can represent data associated with the client device 212 of the user. For example, the device data 245 can include a phone number, an Internet protocol (IP) address, an International Mobile Equipment Identity (IMEI), and other suitable identifiers for a client device 212.“. Similar arguments apply to claims 1 and 15.
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Therefore, claims 1, 8 and 15 are directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application).
The claims 1 , 8 and 15 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements (bolded elements above) amount to no more than mere instructions to apply the abstract idea using generic computer components. In conclusion, merely "applying" the exception using generic computer components cannot provide an inventive concept. Therefore, the claims 1, 8, and 15 are not patent eligible under 35 USC 101. (Step 2B: NO. The claims do not provide significantly more).
Dependent Claims
Dependent claims 2 - 7, 9 - 14 and 16 - 20 are also rejected under 35 U.S.C. 101. Dependent claims 2 - 7, 9 - 14 and 16 - 20 are further define the abstract idea or further define the extra-solution activities that are present in independent claim 1 thus abstract idea correspond to certain methods of organizing human activity as presented above. Claims 2 - 7, 9 - 14 and 16 - 20 clearly further define the abstract idea as stated above and further define extra-solution activities such as presenting data and transmitting/receiving data.
Furthermore, dependent claims 2 - 7, 9 - 14 and 16 - 20 do not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
Regarding claims 2 and 9, these claims merely recite additional steps that amount to no more than insignificant extra-solution activity. Specifically, claim 2 states “wherein identifying the funding account further comprises causing the computing device to at least: verifying the funding account matches an account type indicated in the payment request.”. These steps amount to no more than mere data gathering/analysis, which is a form of insignificant extra- solution activity (See M PEP 2016.05(g): CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375 (Fed. Cir. 2011); and GIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)). Such limitations do not integrate the abstract idea into a practical application, or amount to significantly than the abstract idea, because the courts have found the concept of data gathering to be well-understood, routine, and conventional activity (See MPEP 2106.05(d): GIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015); and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, (Fed. Cir. 2014)). Similar arguments can be made for claim 9.
Regarding claims 3 and 10, these claims merely recite, "wherein identifying the funding account further comprises causing the computing device to at least: verifying the funding account matches a partial account identifier indicated in the payment request.“. These steps amount to no more than mere data gathering/analysis, which is a form of insignificant extra- solution activity (See M PEP 2016.05(g): CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375 (Fed. Cir. 2011); and GIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)). Such limitations do not integrate the abstract idea into a practical application, or amount to significantly than the abstract idea, because the courts have found the concept of data gathering to be well-understood, routine, and conventional activity (See MPEP 2106.05(d): GIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015); and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, (Fed. Cir. 2014)). Similar arguments can be made for claim 10.
Regarding claims 4 and 11, these claims merely recite, “wherein identifying the funding account further comprises causing the computing device to at least: verifying the funding account has sufficient funds for the payment request.”. These steps amount to no more than mere data gathering/analysis, which is a form of insignificant extra- solution activity (See M PEP 2016.05(g): CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375 (Fed. Cir. 2011); and GIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)). Such limitations do not integrate the abstract idea into a practical application, or amount to significantly than the abstract idea, because the courts have found the concept of data gathering to be well-understood, routine, and conventional activity (See MPEP 2106.05(d): GIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015); and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, (Fed. Cir. 2014)). Similar arguments can be made for claim 11.
Regarding claims 5 and 12, these claims merely recite, "wherein the user identifier comprises an email address or a phone number associated with a user.“. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)). Similar arguments can be made for claim 12.
Regarding claims 6 and 13, these claims merely recite additional steps that amount to no more than insignificant extra-solution activity. Specifically, claim 6 states “wherein the identifying the billing account and the funding account that further comprises causing the computing device to at least: determine a payment amount for the payment request exceeds an amount threshold; and determine the billing account and the funding account matches an additional set of identity matching criteria based at least in part on the payment amount exceeding the amount threshold, wherein the additional set of identity matching criteria represents a greater quantity of data elements that match than the set of identity matching criteria.". These steps amount to no more than mere data gathering/analysis, which is a form of insignificant extra- solution activity (See M PEP 2016.05(g): CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375 (Fed. Cir. 2011); and GIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)). Such limitations do not integrate the abstract idea into a practical application, or amount to significantly than the abstract idea, because the courts have found the concept of data gathering to be well-understood, routine, and conventional activity (See MPEP 2106.05(d): GIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015); and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, (Fed. Cir. 2014)). Similar arguments can be made for claim 13.
Regarding claims 7 and 14, these claims merely add further description to the process of “wherein the set of identity matching criteria comprises at least three of a name, a phone number, an email address, a mailing address, or a social security number.”. This amount to no more than mere data gathering/outputting as described in reference to claims 1 and 8 (see analysis above). Merely describing the comparing the new claim information does not integrate the abstract idea into a practical application, or amount to significantly more than the judicial exception, because it does not impose any meaningful limitations on practicing the abstract idea. Similar arguments can be made for claim 14.
Regarding claim 16, this claim merely add further description to the process of “wherein the biometric identify is verified based at least in part on a comparison between a stored biometric identifier and the biometric identify scan.”, which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
Regarding claim 17, this claim merely recite, "display a user interface that includes a user interface component associated with the payment request; identify a payment condition for the payment request based at least in part on a user manipulation associated with the user interface component.“. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
Regarding claim 18, this claim merely provide further detail regarding the processing the new claim, recited in claims 1 and 8. Merely stating “wherein the payment condition is a scheduled time for executing the payment request.." This does not integrate the abstract idea into a practical application because it does not impose any meaningful limitation on practicing the abstract idea.
Regarding claim 19, this claim merely add further description to the process of “wherein the payment condition is an instruction storing the payment request as a favorite command or repeating an execution of the payment request.”. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)). .
Regarding claim 20, this claim merely add further description to the process of “display a chat feed in a user interface that includes the payment request.”, which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
As a result, such limitations do not overcome the requirements as described above. Therefore, claims 2 - 7, 9 - 14 and 16 - 20 are directed to an abstract idea. Thus, claims 1 - 20 are not patent eligible.
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 of this title, 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.
Claims 8 – 14 and 1 - 7 are rejected under 35 U.S.C. 103 as being obvious over Seongmin JE et al. (Pub. # US 2020/0134602 A1 – herein referred to as JE) in view of David L. Garrison et al. (Pat. # US 7,711, 690 B1 – herein referred to as Garrison).
Re: Claim 8, JE discloses a method, comprising:
identifying, by at least one computing device, a payment request derived from a text message, the text message being generated by a client device; determining, by the at least one computing device, a user identifier, a first entity identifier, and a second entity identifier associated with the payment request (JE, [0075] – According to various embodiments, if the first electronic device 310 receives (or detects) an input for payment request from the user, the first electronic device 310 makes it possible to proceed with payment in place of the first electronic device 310 itself through one electronic device among the multiple neighboring electronic devices 320, 330, and 340 having a payment function (or capable of performing payment). According to an embodiment, in response to a payment request of the user, the first electronic device 310 may transmit, to a server (not illustrated), a signal (or a message) for requesting verification of at least one electronic device capable of performing payment (or having a payment function) (hereinafter, referred to as a "payment-capable device"). According to an embodiment, a signal (or a message) for requesting verification of a payment-capable device may include, for example, and without limitation: input information for a payment request of the user; and context information related to the first electronic device 310. According to an embodiment, context information may include, for example, and without limitation, at least one piece of information among: information on a product for which a payment is to be made (e.g., a product code, a product type, a product quantity, and a product dealer); information on a payment amount; information on a user account registered in the first electronic device 310; information on a place (or a position) at which the first electronic device 310 is located in a space; and the like.);
querying, by the at least one computing device, a first entity computing device for a first list of billing accounts based at least in part on the user identifier and the first entity identifier (JE, [0165] – In operation 813, if a payment electronic device is selected by the user, the first electronic device 810 may deliver order information to the payment server 820 (or a billing server). According to an embodiment, order information may include information related to a product that the user desires to purchase in a content being displayed (or reproduced) by the first electronic device 810. According to an embodiment, order information may include at least one of a product dealer, a product type, a product name, a product quantity, or a payment amount. According to an embodiment, the first electronic device 810 may deliver information (e.g., a user key, or a GUID) related to a user account which is currently logging in to the first electronic device 810 (or a user account pre-registered in the first electronic device 810). For example, the first electronic device 810 may provide the payment server 820 with information on which electronic device is to be used to perform payment, based on the GUID delivered to the server 840 in operation 803.);
querying, by the at least one computing device, a second entity computing device for a second list of funding accounts based at least in part on the user identifier and the second entity identifier (JE, [0011] – In accordance with another example aspect of the disclosure, an electronic device may include: a communication interface comprising communication circuitry; a dis-play; at least one processor operatively connected to the display and the communication interface; and at least one memory electrically connected to the processor, wherein the memory is configured to store instructions that, when executed by the processor, control the electronic device to: display, on the display, a content and a user interface configured to receive a payment request related to the content; receive a first input related to the payment request through the user interface; transmit information related to the first input to an external server through the connumeration interface; receive, from the external server, a list of at least one external electronic device having a payment function and related to an account of a user; display the list on the display; receive a second input for selection of one external electronic device among the at least one external electronic device of the list; and transmit information on the second input to the external server through the communication interface.).
However, JE does not expressly disclose:
identifying, by the at least one computing device, a billing account and a funding account that matches a set of identity matching criteria based at least in part on the first list of billing accounts and the second list of funding accounts; and
executing, by the at least one computing device, the payment request based at least in part on the identification of the billing account and the funding account.
In a similar field of endeavor, Garrison discloses:
identifying, by the at least one computing device, a billing account and a funding account that matches a set of identity matching criteria based at least in part on the first list of billing accounts and the second list of funding accounts (Garrison, col. 7, lines 32 – 53 – RPP 3 initiates merchant identification by step 60 which retrieves a payment record from one of the payment records previously submitted by the source 7. At step 62, the RPP first attempts to retrieve a merchant record from the merchant database 18 by matching the merchant id included in the payment record against the records of the merchant database 18. If there is a match, then at step 63 processing of the payment record continues to the payment directions stage 64. The payment directions stage is where the RPP determines where to send payments. This stage includes account ranging discussed below which determines the remittance center to which payment gets sent. If there is no match at step 63, the RPP continues to step 65. At step 65, the RPP maps the merchant's merchant name and address, excluding the pro-vided street address and zip code, into an eleven digit zip code. That is, the RPP produces an eleven digit zip code based on merchant name, city, and state in the payment information. In order to avail the merchant information which the inventors have determined to be mostly likely to contain errors, the received merchant street address and zip code are not considered. Hence, in step 65 the RPP 3 identifies an eleven digit zip code based only on the merchant's name, city, and state.); and
executing, by the at least one computing device, the payment request based at least in part on the identification of the billing account and the funding account (Garrison, cols. 6 - 7, lines 57 – 9 – After receiving payment requests from sources 7, the RPP 3 periodically initiates a payment cycle 20 which process the records to generate information which will be used by the payment processing system 25 to credit merchant accounts and advise the merchant systems of the payments. The processing flow of the billing cycle contains, in addition to other processes, three particularly important processes necessary for successful processing of each payment request. These processes are merchant identification 19a, account ranging 19b, and account scheming 19c, typically performed in this order. In the first step of processing a payment request, the processor 17 attempts to identify a merchant in the merchant database 18 based on information in the payment request. In the second step, the processor 17 will attempt to determine a remittance center of the merchant to which the payment and/ or payment information is to be sent. If a candidate remittance center is identified, the system enters the third stage of processing, account scheming. In account scheming, the processor 17 attempts to normalize a user account with a merchant according to the merchant's rules. If account scheming fails, the system will return to the account ranging process to attempt to identify another candidate remittance center, and from there, again into account scheming.).
Therefore, in light of the teachings of Garrison, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the method of JE, motivation according to one KSR Exemplary Rationale where a known technique is used to improve similar methods and systems in the same way by provide a way to reduce the time and expense which must now be spent by every bill payment entity to implement a consolidated bill payment system.
Re: Claim 9, JE in view of Garrison discloses the method of claim 8, wherein identifying the funding account further comprises:
verifying the funding account matches an account type indicated in the payment request (Garrison, col. 8, lines 6 – 19 – If step 65 identifies a unique merchant record then there is an exact match and at step 66 processing continues to step 64. However, if step 65 retrieves more than one merchant forming a group of records 86, (see FIG. 4) then at step 66 processing continues to step 67. At step 67, the RPP 3 will attempt to match one or more characters of the merchant's name 83 against the records 86 to identify a merchant record. If a match is found, processing continues at step 68 to the payment directions stage 64. If there is no match, then at step 68 the program will continue to step 69 where the RPP will handle the unmanaged merchant. If there is no merchant, the system may have provisions at step 69 for adding the merchant to the merchant database 18.). The rationale for support of motivation, obviousness and reason to combine see claim 8 above.
Re: Claim 10, JE in view of Garrison discloses the method of claim 8, wherein identifying the funding account further comprises:
verifying the funding account matches a partial account identifier indicated in the payment request (Garrison, col. 7, lines 32 – 53 – RPP 3 initiates merchant identification by step 60 which retrieves a payment record from one of the payment records previously submitted by the source 7. At step 62, the RPP first attempts to retrieve a merchant record from the merchant database 18 by matching the merchant id included in the payment record against the records of the merchant database 18. If there is a match, then at step 63 processing of the payment record continues to the payment directions stage 64. The payment directions stage is where the RPP determines where to send payments. This stage includes account ranging discussed below which determines the remittance center to which payment gets sent. If there is no match at step 63, the RPP continues to step 65. At step 65, the RPP maps the merchant's merchant name and address, excluding the provided street address and zip code, into an eleven digit zip code. That is, the RPP produces an eleven digit zip code based on merchant name, city, and state in the payment information. In order to avail the merchant information which the inventors have determined to be mostly likely to contain errors, the received merchant street address and zip code are not considered. Hence, in step 65 the RPP 3 identifies an eleven digit zip code based only on the merchant's name, city, and state.). The rationale for support of motivation, obviousness and reason to combine see claim 8 above.
Re: Claim 11, JE discloses the method of claim 8, wherein identifying the funding account further comprises:
verifying the funding account has sufficient funds for the payment request (JE, [0153] – In operation 803, if the first electronic device 810 detects an input made by the user in order to request payment related to a product in a content currently being displayed (or reproduced), the first electronic device 810 may transmit, to the server 840, a request for verification of an electronic device capable of performing payment (hereinafter, referred to as a "payment-capable device"). According to an embodiment, the first electronic device 810 may deliver information (e.g., a user key, or a global unique identifier (GUID)) related to a user account via which the user is currently logged in to the first electronic device 810 (or a user account pre-stored in the first electronic device 810). Through this configuration, the server 840 may verify a payment-capable device and/or card information related to the user account. According to an embodiment, a GUID may be an identifier which can be solely used to identify a particular object (e.g., an electronic device). According to an embodiment, the server 840 may search for a payment-capable device which has a payment function and is related to a user account, based on the GUID. According to an embodiment, the server 840 may manage electronic devices for each user account.).
Re: Claim 12, JE discloses the method of claim 8,
wherein the user identifier comprises an email address or a phone number associated with a user (JE, [0004] – An electronic device may be implemented in the form of a multifunctional multimedia device (multimedia player). For example, an electronic device may provide a call function such as a voice call or a video call, a message transmission/reception function such as a short message service (SMS)/multimedia message service (MMS) or an email, an electronic organizer function, an image-capturing function, a broadcast reproduction function, a moving-im-age reproduction function, a music reproduction function, an Internet function, a messenger function, a game function, a social network service (SNS) function, or the like. Recently, an electronic device provided an electronic payment function including mobile payment. According to an embodiment, if a user purchases a product (or an article) through web shopping (or Internet shopping) or home shopping, the user may pay for the product through an electronic card (or an application card) registered in an electronic payment service (or a payment application) using an electronic device.).
Re: Claim 13, JE in view of Garrison discloses the method of claim 8,
wherein identifying the billing account and the funding account that further comprises causing the computing device to at least:
determining a payment amount for the payment request exceeds an amount threshold (JE, [0080] – According to various embodiments, in response to reception of the signal for requesting payment from the first electronic device 310, the server allows the corresponding payment electronic device to proceed with (execute) the payment. For example, the server may transmit, to the payment electronic device, various pieces of information (e.g., product information, a payment amount, and mutual information) related to payment for a product, and a signal including a command for controlling execution of payment.); and
determining the billing account and the funding account matches an additional set of identity matching criteria based at least in part on the payment amount exceeding the amount threshold, wherein the additional set of identity matching criteria represents a great quantity of data element that match than the set of identity matching criteria (Garrison, col. 7, lines 32 – 53 – RPP 3 initiates merchant identification by step 60 which retrieves a payment record from one of the payment records previously submitted by the source 7. At step 62, the RPP first attempts to retrieve a merchant record from the merchant database 18 by matching the merchant id included in the payment record against the records of the merchant database 18. If there is a match, then at step 63 processing of the payment record continues to the payment directions stage 64. The payment directions stage is where the RPP determines where to send payments. This stage includes account ranging discussed below which determines the remittance center to which payment gets sent. If there is no match at step 63, the RPP continues to step 65. At step 65, the RPP maps the merchant's merchant name and address, excluding the pro-vided street address and zip code, into an eleven digit zip code. That is, the RPP produces an eleven digit zip code based on merchant name, city, and state in the payment information. In order to avail the merchant information which the inventors have determined to be mostly likely to contain errors, the received merchant street address and zip code are not considered. Hence, in step 65 the RPP 3 identifies an eleven digit zip code based only on the merchant's name, city, and state.). The rationale for support of motivation, obviousness and reason to combine see claim 8 above.
Re: Claim 14, JE in view of Garrison discloses the method of claim 8,
wherein the set of identity matching criteria comprises at least three of a name, a phone number, an email address, a mailing address, or a social security number (Garrison, col. 8, lines 6 – 19 – If step 65 identifies a unique merchant record then there is an exact match and at step 66 processing continues to step 64. However, if step 65 retrieves more than one merchant forming a group of records 86, (see FIG. 4) then at step 66 processing continues to step 67. At step 67, the RPP 3 will attempt to match one or more characters of the merchant's name 83 against the records 86 to identify a merchant record. If a match is found, processing continues at step 68 to the payment directions stage 64. If there is no match, then at step 68 the program will continue to step 69 where the RPP will handle the unmanaged merchant. If there is no merchant, the system may have provisions at step 69 for adding the merchant to the merchant database 18..). The rationale for support of motivation, obviousness and reason to combine see claim 8 above.
Re: Claim 1, claim 1 is a system claim corresponding to method claim 8. Therefore, claim 1 is analyzed and rejected as previously discussed with respect to claim 8.
Re: Claim 2, claim 2 is a system claim corresponding to method claim 9. Therefore, claim 2 is analyzed and rejected as previously discussed with respect to claim 9.
Re: Claim 3, claim 3 is a system claim corresponding to method claim 10. Therefore, claim 3 is analyzed and rejected as previously discussed with respect to claim 10.
Re: Claim 4, claim 4 is a system claim corresponding to method claim 11. Therefore, claim 4 is analyzed and rejected as previously discussed with respect to claim 11.
Re: Claim 5, claim 5 is a system claim corresponding to method claim 12. Therefore, claim 5 is analyzed and rejected as previously discussed with respect to claim 12.
Re: Claim 6, claim 6 is a system claim corresponding to method claim 13. Therefore, claim 6 is analyzed and rejected as previously discussed with respect to claim 13.
Re: Claim 7, claim 7 is a system claim corresponding to method claim 14. Therefore, claim 7 is analyzed and rejected as previously discussed with respect to claim 14.
Claims 15 – 20 are rejected under 35 U.S.C. 103 as being obvious over Seongmin JE et al. (Pub. # US 2020/0134602 A1 – herein referred to as JE) in view of Pat Finneran et al. (Pub. # US 2020/0074541 A1 – herein referred to as Finneran).
Re: Claim 15, JE discloses a system, comprising:
a computing device comprising a processor and a memory (JE, [0032] – Referring to FIG. 1, the electronic device 101 in the network environment 100 may communicate with an electronic device 102 via a first network 198 (e.g., a short-range wireless communication network), or an electronic device 104 or a server 108 via a second network 199 (e.g., a long-range wireless communication network). According to an embodiment, the electronic device 101 may communicate with the electronic device 104 via the server 108. According to an embodiment, the electronic device 101 may include a processor 120, a memory 130, an input device 150, a sound output device 155, a display device 160, an audio module 170, a sensor module 176, an interface 177, a haptic module 179, a camera module 180, a power management module 188, a battery 189, a communication module 190, a sub-scriber identification module (SIM) 196, or an antenna module 197.); and
machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to at least:
generate a biometric identify scan for verifying a biometric identify of a user (JE, [0095] – According to an embodiment, the authentication server 390 may, for example, be a server related to authentication for user verification. According to an embodiment, if the authentication server 390 proceeds with payment in relation to the second electronic device 320, the authentication server 390 may process user authentication based on biometric information (e.g., registered fingerprint information, registered iris information, etc.) (or based on biometric authentication). According to an embodiment, the authentication server 390 may perform user verification based at least on at least one authentication scheme among, for example, and without limitation, a pin-based authentication scheme, an online authentication-based (e.g., a scheme, such as communication company authentication) scheme, an online biometric authentication (e.g., fast identity online (FIDO))-based scheme, or the like. According to an embodiment, the authentication server 390 may transmit a result of the authentication related to the payment by the user (or the second electronic device 320), to the card company server 380 and/or the payment agency server 360. ); and
transmit a payment request to a remote computing device based at least in part on a verification of the biometric identify, the payment request comprising the first entity identifier and the second entity identifier (JE, [0171] – According to an embodiment, in operation 825, the second electronic device 850 may deliver, to the server 840, a payment authentication request in response to the call by the server 840. According to an embodiment, the second electronic device 850 may receive random data as of a result of the online biometric authentication between itself and the authentication server, and may provide the received random data to the server 840. According to an embodiment, if the user authentication has been completed (e.g., if user authentication is valid), the second electronic device 850 may transmit, to the server 840, a payment authentication request including an authentication result (e.g., signature data and random data).).
However, JE does not expressly disclose:
machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to at least:
identify a command in a chat session, the command being associated with a chat template;
determine a first entity identifier associated with the command based at least in part on a first character input and the chat template;
determine a second entity identifier associated with the command based at least in part on a second character input and the chat template.
In a similar field of endeavor, Finneran discloses:
machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to at least:
identify a command in a chat session, the command being associated with a chat template (Finneran, [0240] – In some embodiments, the system may interact with the user via a chat window (for example, a pop-up window) that may be operated by a chatbot to request the information needed from the user and/or provide the user with educational information regarding the process. In some embodiments, such chatbots may be entirely automated (for example, using artificial intelligence that learns how to best interact with users over time) or may be partially operated by a human operator (for example, when the chatbot is unsure of how to respond to a query from the user). Similarly, any other user interactions discussed herein may be partially or fully performed via a conversational format, with a chatbot (for example, fully or partially automated) interacting with the user via primarily textual communications. FIGS. 14-18 illustrates example embodiments of such chat-like communications.);
determine a first entity identifier associated with the command based at least in part on a first character input and the chat template (Finneran, [0241] – User interface 1910 request information from the user regarding a few potential accounts that could be added to the credit data of the consumer. The user interface request that the user confirm that payments to the identified payees are actually made by the user and, accordingly, could properly be used in calculating credit worthiness of the user. In this embodiment, if the user does not recognize payees listed, those payees can be removed by clicking the acts the right of the payee data identifiers.);
determine a second entity identifier associated with the command based at least in part on a second character input and the chat template (Finneran, [0247] – Since there are a few missing payments, the user may want to review the payment transaction items that were identified by the account identification component 114 to determine if some of those missing payments can be located (for example, in another DDA account of the user). Similarly, the user may want to provide the account identification component 114 with additional information regarding payments made to the payee, such as an alternate payee identifier that may have been used in certain transaction data items. As another example, the user may want to authorize access to another DDA account where payments to the payee may also be located. Through these processes, the user may improve the payment history associated with the account and, accordingly, may further increase a score impact by addition of the account to credit data of the user. In some implementations, a user interface such as FIG. 24B, which displays missing payments associated with a particular account, may not be displayed to the user until after the account is added as a trade line to the credit data of the user.).
Therefore, in light of the teachings of Finneran, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the method of JE, motivation according to one KSR Exemplary Rationale where a known technique is used to improve similar methods and systems in the same way by providing the user interface data configured to depict a permissions interface element that is selectable to indicate authorization to access account information associated with the user, and receiving, from the user computing device, authorization to access account information associated with the user.
Re: Claim 16, JE discloses the system of claim 15,
wherein the biometric identify is verified based at least in part on a comparison between a stored biometric identifier and the biometric identify scan (JE, [0041] – The sensor module 176 may detect an operational state (e.g., power or temperature) of the electronic device 101 or an environmental state (e.g., a state of a user) external to the electronic device 101, and then generate an electrical signal or data value corresponding to the detected state. According to an embodiment, the sensor module 176 may include, for example, a gesture sensor, a gyro sensor, an atmospheric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an infrared (IR) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illuminance sensor.).
Re: Claim 17, JE discloses the system of claim 15, wherein the machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to at least:
display a user interface that includes a user interface component associated with the payment request (JE, [0011] – In accordance with another example aspect of the disclosure, an electronic device may include: a commune-cation interface comprising communication circuitry; a display; at least one processor operatively connected to the display and the communication interface; and at least one memory electrically connected to the processor, wherein the memory is configured to store instructions that, when executed by the processor, control the electronic device to: display, on the display, a content and a user interface configured to receive a payment request related to the content; receive a first input related to the payment request through the user interface; transmit information related to the first input to an external server through the communication interface; receive, from the external server, a list of at least one external electronic device having a payment function and related to an account of a user; display the list on the display; receive a second input for selection of one external electronic device among the at least one external electronic device of the list; and transmit information on the second input to the external server through the communication interface.);
identify a payment condition for the payment request based at least in part on a user manipulation associated with the user interface component (JE, [0078] – According to various embodiments, among multiple electronic devices capable of performing payment, the server may determine a priority of a payment electronic device based on various conditions (e.g., positions of the electronic devices, states thereof, a discount rate of a registered card, or the like), may generate a list including at least one payment electronic device, based on the priority, and may provide the generated list to the first electronic device 310.).
Re: Claim 18, JE discloses the system of claim 15,
wherein the payment condition is a scheduled time for executing the payment request (JE, [0094] – According to an embodiment, the card company server 380 may, for example, be a server which is actually operated by a card company, and may store and manage individual card information of each user. According to an embodiment, the card company server 380 may issue a card to a user (or the second electronic device 320), and may manage the issued card. According to an embodiment, the card company server 380 may be connected to another server (e.g., a financial server (not illustrated), a purchase server (not illustrated), or a token server) in a wired or wireless manner. According to an embodiment, the card company server 380 may issue (e.g., one-time issuance or issuance at the time of registering a card) and manage a token used for an electronic payment service. In an embodiment, a token may replace unique card information (a primary account number (PAN)). In an embodiment, a token may be generated using bank identification information (a bank identification number (BIN)). According to an embodiment, a token server (not illustrated) may transmit a token for authentication related to payment by the user (or the second electronic device 320), to the card company server 380 and/or the payment agency server 360.).
Re: Claim 19, JE discloses the system of claim 15,
wherein the payment condition is an instruction storing the payment request as a favorite command or repeating an execution of the payment request (JE, [0065] – According to an embodiment, the memory 220 may store various data used by at least one element (e.g., the processor 210) of the electronic device 201. Data may include, for example, software (e.g., the program 140 of FIG. 1) and input data for commands related to the software or output data for the commands. The memory 220 may include a volatile memory and/or a non-volatile memory. According to an embodiment, the memory 220 may store a module (e.g., a process or a function) configured to perform a function according to various embodiments, and a module stored in the memory 220 may be executed by the processor 220.).
Re: Claim 20, JE in view of Finneran discloses the system of claim 15, wherein the machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to at least:
display a chat feed in a user interface that includes the payment request (Finneran, [0246] – FIG. 24A is another embodiment of an example user interface that provides information regarding an identified account in transaction data items of user, with an option that is selectable by the user to add the account to credit data of the user (as a self-reported account). In the example of FIG. 24A, the user interface may be displayed via a browser, such as on a desktop or laptop computer. However, the same or similar user interface may be displayed on any other display device or type. In this example, a payment account associated with So Cal Edison has been identified, and payments identified in transaction data items are indicated in the payment history graphic 2412. In this example, payments for two months in 2017 were not identified and a payment for one month in 2018 was not identified (indicated as gray circles in the payment history graphic 2412, rather than green circles). Thus, 21 of 24 payments were identified in the prior two year history for the account. Missing payments in one or more calendar months may not necessarily indicate negative activity associated with the account. For example, a user may have made two payments within a given month (for example, paid bill on 1st and 31st of the same month), causing the following calendar month to not be associated with a payment. However, the payment for that following month was actually paid early, so the account identification component 114 may be programmed to identify special circumstances such as this example (either through manually provided rules and/or rules determined by machine learning) so missed payments can be more accurately identified.). The rationale for support of motivation, obviousness and reason to combine see claim 15 above.
Conclusion
THIS ACTION IS MADE FINAL. 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 extension fee 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 JOHN H. HOLLY whose telephone number is (571)270-3461. The examiner can normally be reached on MON. - FRI 10 AM - 8 PM.
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, MATTHEW S. GART can be reached on 571-272-3955. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/John H. Holly/Primary Examiner, Art Unit 3696
Prosecution Insights