Detailed Action
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 .
Acknowledgments
The application filed on 12/02/25 is acknowledged.
Status of Claims
Claims 1-20 are pending.
In the Amendment filed on 12/02/25, claims 1, 10, 11 and 19 were amended, and no claims were cancelled or added.
Claims 1-20 are rejected.
Response to Arguments
Regarding the rejection under 35 U.S.C. 101
Applicant's arguments have been fully considered but are not persuasive.
The Office responds to Applicant arguments below, under the headings used by Applicant in the Response. Page numbers below refer to Applicant's instant Response (filed on 12/02/25) unless otherwise indicated.
Initially, the Office notes that Applicant's arguments are virtually identical to the arguments presented in the last Response (Amendment filed on 03/17/25). The differences between the instant arguments and the previous arguments are as follows:
1. At pp. 10-11, claim 1 is set forth as currently amended. In the previous response claim 1 was set forth prior to the instant amendments. Note, however, that following this setting forth of claim 1, Applicant's arguments do not mention the currently amended claim language. Rather, Applicant's arguments incorrectly mention the claim language prior to the instant amendments. See, e.g., p. 14 ("transmit[s], to the server, a request for data associated with a completed transaction").
2. In the paragraph bridging pp. 11-12 (re: Step 2A), the following sentence has been changed from the prior version as indicated (strike-through indicates deletions):
The
3. At p. 13 (re: Step 2A), first full paragraph, the following sentence has been changed from the prior version as indicated (underlining indicates additions):
Applicant respectfully submits that the above-noted limitations are not directed to fundamental economic practices or principles and/or commercial or legal interactions or a process for mitigation of risk of financial loss.
4. In the paragraph bridging pp. 13-14 (re: Step 2A), at the end of the paragraph the following sentence has been added, relative to the prior version (underlining indicates additions):
These features are to ensure data security and are not a process for mitigation of risk of financial loss.
As seen from the above comparison of the instant arguments to the previous arguments, the differences therebetween are minor, and the substance of the arguments is the same. Accordingly, the Response to Arguments in the previous Office Action (Final Office Action issued 07/02/25) addresses Applicant's instant arguments. Below, the Office provides a revised version of the previous Response to Arguments, including further clarification.
First, the Office notes that the instant claim amendments merely constitute a limited change to the abstract idea. That is, the claim language added in the instant amendments constitutes a part of the abstract idea, and amounts to a limited revision of the abstract idea, relative to the previous version of the claims. As such, the instant claim amendments do not alter the results of the 101 analysis.
Revised Step 2A – Judicial Exception
Applicant argues that the claims are not directed to fundamental economic practices or principles and/or commercial or legal interactions. Further, Applicant argues that the claims represent an improvement in functioning of a computer or other technology, specifically, in secure transaction data processing, by virtue of the fact that the authentication exchange ensures that the user is present with the both the user device and the contactless card, thus ensuring that the user is not a fraudulent party.
The Examiner respectfully disagrees.
The specification and claims are directed to financial recordkeeping (editing/ correcting financial transaction data) including a preliminary authentication process. For example, the claim language recites “transmitting, by the user device, the authentication credential to the server; upon receiving the authentication credential, matching, by the server, the authentication credential with a user profile of a user of authenticate the user” (authentication process) and "receiving, from the server, one or more data associated with the completed transaction; opening, in response to receiving the one or more data associated with the completed transaction, an application configured to display one or more data fields associated with the completed transaction wherein some of the one or more data fields have been populated with the one or more data received from the server; transmitting, by the user device to the application, one or more additional entries to the one or more data fields to obtain completed data fields associated with the one or more additional entries; storing, by the user device to a data storage unit, the completed data fields; and transmitting, by the user device to the server, the completed data fields" (financial recordkeeping process (editing/correcting financial transaction data)). Notably, both the authentication and the financial recordkeeping (editing/correcting) serve to mitigate risk of financial loss. Thus, the claims recite fundamental economic practices or principles and/or commercial or legal interactions.
Further, as for the alleged improvement (e.g., authenticating with both card and device), as described in Applicant’s own words (“computing devices that engage securely processing transaction data by authenticating a user through both a contactless card of the user and a user device of the user”; p. 16), the instant claims use off-the-shelf computer devices recited at a high level of generality and used in their ordinary capacity (i.e., generic computer elements) to process data in an authentication process and a financial recordkeeping process. The claimed additional elements (as indicated in the body of the rejection hereinbelow) amount merely to generic computer elements and generally linking the abstract idea to a particular technological environment. As such, the claims do not encompass an improvement in the functioning of a computer or in another technology, and accordingly do not integrate the abstract idea into a practical application.
As for the argument that the claims do not monopolize the judicial exception, the Office notes that this is not a standalone criterion for eligibility. Even assuming arguendo that this argument were correct, it would be outweighed by the other considerations (counterarguments) set forth here by the Office.
Insofar as Applicant is arguing that the claims "apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment," the Office finds in Applicant's remarks no supporting substance behind such argument other than the alleged improvement discussed above.
Step 2B - The Claims Include "Significantly More"
Applicant argues that “the elements recited in the independent claims include specific processes performed by a computing system to provide secure transaction data processing” and that the “features operate in a non-conventional and non-generic way for processing transaction data securely.”
The Examiner respectfully disagrees.
The specificity of the claims does not indicate 'significantly more'. Rather, any specificity present amounts merely to specificity (narrowing) of the abstract idea or specificity of generic computer elements or of a linked particular field of use.
Further, Applicant has not demonstrated but rather has merely provided a conclusory assertion that the “features operate in a non-conventional and non-generic way for processing transaction data securely.”
Insofar as Applicant is alleging that the claimed subject matter is not well-understood, routine and conventional, the Office notes that the claims were not rejected as being well-understood, routine and conventional. Rather, the claims were rejected under Step 2B because, when the additional elements are included in the consideration of the claims as a combination, they are merely generic computer elements recited at a high level of generality, that are used to apply the abstract idea, or they merely generally link the abstract idea to a particular field of use. However, "adding the words 'apply it' (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer" and "generally linking the use of the judicial exception to a particular technological environment or field of use" are "[l]imitations that the courts have found not to be enough to qualify as 'significantly more' when recited in a claim with a judicial exception." MPEP 2106.05. (Eligibility Step 2B: Whether a Claim Amounts to Significantly More), I. (THE SEARCH FOR AN INVENTIVE CONCEPT), A. (Relevant Considerations For Evaluating Whether Additional Elements Amount To An Inventive Concept).
Under Step 2B Applicant also argues again that the claims represent an improvement in technology (p. 18). This argument has been addressed above under Step 2A. In this argument, Applicant also cites the decision, Affinity Labs of Tex. v. DirecTV, LLC. However, Applicant's own description of that case ("an advance in the process of downloading content for streaming") indicates that the claims therein are directed to subject matter distinct from the instant claims. Applicant does not provide any explanation of how the instant claims are alleged to be analogous to those of Affinity Labs of Tex. v. DirecTV, LLC. Accordingly, the implied analogy with Affinity Labs of Tex. v. DirecTV, LLC is not persuasive.
Regarding the rejection under 35 U.S.C. 103
Applicant’s arguments have been fully considered but are moot in view of the new combination of references used in the current rejections. The new combination of references includes both a new reference (Mossler) and new portions of a previously applied reference (Krakowiecki).
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1-20 are directed to a method, system, or computer readable non-transitory medium, which are/is one of the statutory categories of invention. (Step 1: YES)
Claims 1, 11 and 19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite a method, system, and computer readable non-transitory medium for editing/correcting financial transaction data, including authenticating the user for access to the data to perform the editing/correcting. (See specification as filed at 0002-0003 and 0023-0025.)
For claims 1, 11 and 19 (claim 1 being deemed representative), the limitations (indicated below in bold) of:
transmitting, from a user device to a server, a request for transaction data, the request including viewing a completed transaction and supplying categorial information regarding the completed transaction;
receiving, by the user device from the server, an authentication request;
opening, by the user device in response to receiving the authentication request, a communication field;
transmitting, from the user device to a contactless card via the communication field, the authentication request;
receiving, by the user device from the contactless card, an authentication credential, wherein the authentication credential includes a message authentication code (MAC) generated via a diversified key exchange between the user device and the contactless card;
transmitting, by the user device, the authentication credential to the server;
upon receiving the authentication credential, matching, by the server, the authentication credential with a user profile of a user to authenticate the user, wherein the user is a user associated with the user device transmitting the request for transaction data;
receiving, from the server, one or more data associated with the completed transaction;
opening, in response to receiving the one or more data associated with the completed transaction, an application configured to display one or more data fields associated with the completed transaction wherein some of the one or more data fields have been populated with the one or more data received from the server;
transmitting, by the user device to the application, one or more additional entries to the one or more data fields to obtain completed data fields associated with the one or more additional entries;
storing, by the user device to a data storage unit, the completed data fields; and
transmitting, by the user device to the server, the completed data fields.
as drafted, constitute a process that, under the broadest reasonable interpretation, covers "certain methods of organizing human activity," specifically, "fundamental economic practices or principles" and/or "commercial or legal interactions,” but for recitation of generic computer components and generally linking the use of a judicial exception to a particular technological environment or field of use. The Examiner notes that "fundamental economic practices" or "fundamental economic principles" describe concepts relating to the economy and commerce, including hedging, insurance, and mitigating risks, and "commercial interactions" or "legal interactions" include agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. MPEP 2106.04(a)(2)II.A.,B. If a claim limitation, under its broadest reasonable interpretation, covers “mathematical relationships, mathematical formulas or equations, mathematical calculations” or "fundamental economic practices or principles" and/or "commercial or legal interactions," but for recitation of generic computer components and generally linking the use of a judicial exception to a particular technological environment or field of use, then it falls within the "certain methods of organizing human activity" grouping of abstract ideas. Accordingly, claims 1, 11 and 19 recite an abstract idea. (Step 2A - Prong 1: YES. Claims 1, 11 and 19 recite an abstract idea.)
This judicial exception is not integrated into a practical application. Claims 1, 11 and 19 recite the additional elements of a user device, a server, opening (and transmitting data via) a communication field, a contactless card, opening an application configured to display, a data storage unit (all the foregoing recited by claims 1, 11 and 19), the user device comprising a memory and a processor (claim 11), and a computer readable non-transitory medium (claim 19), that implement the abstract idea. These additional elements are not described by the applicant and they are recited at a high level of generality (i.e., one or more generic computer elements performing generic computer functions, or a field of use limitation), such that they amount to no more than mere instructions to apply the exception using generic computer elements or -- in the case of “opening [and transmitting data via] a communication field” and “a contactless card” -- generally linking the use of a judicial exception to a particular technological environment or field of use. Accordingly, even in combination these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (Step 2A - prong 2: NO. The additional elements do not integrate the abstract idea into a practical application.)
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of a user device, a server, opening a communication field, a contactless card, opening an application configured to display, a data storage unit (all the foregoing recited by claims 1, 11 and 19), the user device comprising a memory and a processor (claim 11), and a computer readable non-transitory medium (claim 19), to perform the noted steps amount to no more than mere instructions to apply the exception using generic computer elements, or generally link the use of the judicial exception to a particular technological environment or field of use. Mere instructions to apply an exception using generic computer elements or generally linking the use of a judicial exception to a particular technological environment or field of use cannot provide an inventive concept ("significantly more"). Accordingly, even in combination, these additional elements do not provide significantly more. As such, claims 1, 8 and 15 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more.)
Dependent claims 2-10, 12-18 and 20 are similarly rejected because they further define/narrow the abstract idea of independent claims 1, 11 and 19 as discussed above, and/or do not integrate the abstract idea into a practical application or provide an inventive concept such as would render the claims eligible, whether each is considered individually or as an ordered combination.
As for further defining/narrowing the abstract idea:
Claims 2 and 20 merely describe receiving, …, a first uniform resource locator (URL); transmitting, …, the first URL …; receiving, …, a second URL associated with … the one or more data fields, …, wherein … has matched the first URL with a user on file; and … associated with the second URL.
Claim 4 merely describes wherein the completed transaction is a consumer transaction between the user and a merchant.
Claim 5 merely describes wherein the authentication credential is a customer identification number ….
Claim 6 merely describes wherein … is further configured to perform a public-private key exchange ….
Claim 7 merely describes wherein … is further configured to edit the one or more data received … before storing the completed data fields …
Claim 8 merely describes wherein ,,, is further configured to receive an item code associated with the completed transaction and populate a data field of the one or more data fields with the item code.
Claim 9 merely describes wherein the item code is a barcode, a quick response (QR) code, a universal product code, or a stock keeping unit.
Claims 10 and 14 merely describe further comprising accessing (claim 10) / wherein … is further configured to access (claim 14) a spending habit report, and wherein the spending habit report has been generated … based on historical data fields from past transactions.
Claim 12 merely describes wherein the one or more data fields comprise purchase dates, merchant names, and item names.
Claim 13 merely describes wherein the one or more data fields comprise a merchant categorization code (MCC) and location of the completed transaction.
Claim 15 merely describes wherein … is further configured to populate at least one data field of the one or more data fields with card information upon ….
Claim 16 merely describes … an item code associated with the completed transaction.
Claim 17 merely describes wherein … is configured to store historical transaction data associated with purchases made by a user ….
Claim 18 merely describes wherein … is further configured to edit, upon receiving information given by a user, data fields that have already been populated ….
As for additional elements:
Claims 2 and 20 recite “the user device,” “the contactless card,” “the server,” “the application configured to display,” “wherein the application comprises a website application or a mobile application,” and “opening the application.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element (“the user device,” “the server,” “the application configured to display,” “wherein the application comprises a website application or a mobile application,” and “opening the application”) or generally linking the use of a judicial exception to a particular technological environment or field of use (“the contactless card”). Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 3 recites “wherein the communication field is a near field communication (NFC) field, Bluetooth, or a radio frequency identification (RFID) enabled field.” This recitation is at a high level of generality such that it amounts to no more than generally linking the use of a judicial exception to a particular technological environment or field of use. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 5 recites “the contactless card.” This recitation is at a high level of generality such that it amounts to no more than generally linking the use of a judicial exception to a particular technological environment or field of use. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 6 recites "the user device” and "the contactless card.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element (“the user device”) or generally linking the use of a judicial exception to a particular technological environment or field of use (“the contactless card”). Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 7 recites “the user device,” the server” and “the data storage unit.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 8 recites “the user device.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 10 recites “the user device.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 14 recites “the processor” and “the user device.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 15 recites “the processor” and “the contactless card entering the communication field.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element (“the processor”) or generally linking the use of a judicial exception to a particular technological environment or field of use (“the contactless card entering the communication field”). Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 16 recites “the user device further comprises a camera configured to scan.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element (“the user device”) or generally linking the use of a judicial exception to a particular technological environment or field of use (“a camera configured to scan”). Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 17 recites “the data storage unit” and “the contactless card.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element (“the data storage unit”) or generally linking the use of a judicial exception to a particular technological environment or field of use (“the contactless card”). Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 18 recites “the processor” and “the server.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claims 4, 9, 12, and 13 do not recite any additional elements, and accordingly, for the reasons provided above with respect to the independent claims, are not patent eligible.
Therefore, dependent claims 2-10, 12-18 and 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, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-8, 10-14 and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Krakowiecki et al. (U.S. Patent No. 8,170,932), hereafter Krakowiecki, in view of Mossler et al. (U.S. Patent Application Publication No. 2021/0029111 A1), hereafter Mossler.
Regarding Claims 1, 11 and 19
Krakowiecki teaches
(claim 11) a … card (Figs. 15-17, Visa credit card); a server; and a user device comprising a memory and a processor, the processor configured to: (Figs. 1, 10, 11, 15:18-31)
transmitting, from a user device to a server, a request for transaction data, the request including viewing a completed transaction and supplying categorial information regarding the completed transaction; (Fig. 6, 604, 7:32-39; note as per 8:27-34, "The aggregate transaction data are organized according to categories 640 stored in the category tables 46 within the management database 28. Each category 640 is an interactive link configured to facilitate further user interaction." -- Therefore, inasmuch as the aggregate data includes categorial information, the request for aggregate data includes "supplying categorial information." (Note regarding claim interpretation: as per Applicant's remarks, support for the instant amended claim language is found in 0071 of the specification as filed. 0071 reads in pertinent part:
In action 605, a user device can request transaction data from a server. … For example, the user can request the transaction data from their most recent purchase of sneakers. …. Additionally, the notification [sic, request] can include a request to view the completed transaction and supply more categorial information regarding the transaction.
The instant amended claim language is interpreted in view of the specification without importing limitations from the specification into the claims. Accordingly, the language "the request including viewing a completed transaction and supplying categorial information regarding the completed transaction" is interpreted as "the request including a request to view a completed transaction and supply categorial information regarding the completed transaction." The reason for this note regarding claim interpretation is that, as drafted, the instant amended claim language may be misunderstood as stating that the request itself includes viewing a completed transaction and supplying categorial information regarding the completed transaction (which does not appear to make sense), rather than stating that the request includes a request to view a completed transaction and to supply categorial information regarding the completed transaction.))
…
receiving, from the server (claims 11 and 19: in response to the request for data), one or more data associated with the completed transaction; (Fig. 6, 608, 7:57-67)
opening, in response to receiving the one or more data associated with the completed transaction, an application configured to display one or more data fields associated with the completed transaction wherein some of the one or more data fields have been populated with the one or more data received from the server; (The application is taught by Fig. 1, 32, 3:30-67 client program, 15:18-22 software programs, which are used to provide the UI/display transaction data, etc. as per Figs. 7A-7D, 8, 9, 13-18, where data fields for transactions are pre-populated with data from server but, as per Figs. 16-18 ("edit," "edit transaction details," 1228, 1264, 1314) and 12:61-13:60, are editable by user; note: under broadest reasonable interpretation, execution of the application, e.g., 32 (Fig. 1), to provide the UI / display the data teaches “opening” the application)
transmitting, by the user device to the application, one or more additional entries to the one or more data fields to obtain completed data fields associated with the one or more additional entries; (Figs. 16-18, 1228, 1264, 1314, 12:61-13:60, "edit," "edit transaction details" – i.e., user inputs data on device to edit displayed data; note: under broadest reasonable interpretation, this input by the user to effect editing of the data displayed in the UI/browser by the application, e.g., 32 (Fig. 1), so as to replace the initial data with the edited data, teaches “transmitting” the entries “by the user device to the application”)
storing, by the user device to a data storage unit, the completed data fields; and (As per Figs. 16-18, 1228, 1264, 1314, 12:61-13:60 and Figs. 17-18, 1268, 1318, 12:61-13:60, "submit," and claim 14: the user inputs data to edit the fields, and the inputted data is displayed and sent to server, therefore the inputted data has been stored on the user device in order to permit the displaying on the user device and the sending to the server, and the data, having been received by server, is stored on server; client machine 33 has storage (data storage unit), as per, e.g., Fig. 1 showing stored programs, 15:18-31; Figs. 1, 3, 11 and associated description indicate that user inputted data including, e.g., categories, is received and stored by the server)
transmitting, by the user device to the server, the completed data fields. (Figs. 17-18, 1268, 1318, 12:61-13:60, "submit"; see also claim 14, Figs. 1, 3, 11 and associated description, indicating that user inputted data, including e.g., categories, is received and stored by the server)
Krakowiecki, 6:61-7:2, teaches requiring a user to authenticate in order to access the user's financial data, but does not spell out the details of this authentication process. Thus, Krakowiecki does not explicitly disclose the following limitations. However, Mossler remedies Krakowiecki's deficiencies in this regard.
Specifically, Krakowiecki does not explicitly disclose but Mossler teaches:
a contactless card; (Fig. 2, 105 contactless card, Fig. 8, 840 contactless card)
receiving, by the user device (Fig. 8, 830 client NFC enabled device) from the server (Fig. 8, 820 application server), an authentication request; (Fig. 8, 802, 0093 "At step 802, in response to the access request, the application server 820 … forwards a notice to the client NFC enabled device [830] [receiving, by the user device from the server] …. The notice may provide a visible or audible indication that an access request is being received for an application registered to the client. The notice may additionally include a prompt for an action by the client. The prompt may take many forms and may include one or more mechanisms enabling a client to authorize the access [authentication request]."; 0094 note Fig. 9 presents an example of 802 ("By way of example, Fig. 9 …."); specifically, as per 0097, '[t]he notice [802] may also include a prompt 950, requesting further action by the client. For example, the prompt 950 instructs the client to ‘tap the contactless card to approve’.")
opening, by the user device in response to receiving the authentication request, a communication field; (Fig. 8, "Request Cryptogram"; 0098 "Referring to FIG. 8, if the service provider prompts for contactless card authentication at step 802, then the client engages the contactless card 840 with the NFC enabled device 830, for example by bringing the contactless card 840 into NFC proximity with the device 830."; note 0048: "As described in the '119 application [incorporated by reference in Mossler, per 0026], contactless card 105 may be configured to communicate with one of a card reader terminal 146, a cellular phone 142, a laptop 144 and/or a tablet 148 [user device] through NFC when the contactless card 105 is within range of the respective client device [user device].")
transmitting, from the user device to a contactless card (Fig. 8, 840) via the communication field, the authentication request; (Fig. 8, "Request Cryptogram" (the authentication request); 0098 "Referring to FIG. 8, if the service provider prompts for contactless card authentication at step 802, then the client engages the contactless card 840 with the NFC enabled device 830, for example by bringing the contactless card 840 into NFC proximity with the device 830. As described with regard to FIG. 2, the contactless card 840 and device 830 may then exchange a cryptogram wherein a stored, encrypted username and dynamic password are forwarded to the NFC enabled device."; see also 0095 "device having NFC capability to enable authentication using cryptogram exchanges comprising encrypted usernames and dynamic passwords")
receiving, by the user device from the contactless card, an authentication credential (cryptogram including username and dynamic password); (Fig. 8, 803 cryptogram is received by client device 830 from card 840; 0098 "As described with regard to FIG. 2, the contactless card 840 and device 830 may then exchange a cryptogram wherein a stored, encrypted username and dynamic password are forwarded to the NFC enabled device."; see also 0095 "device having NFC capability to enable authentication using cryptogram exchanges comprising encrypted usernames and dynamic passwords")
wherein the authentication credential includes a message authentication code (MAC) generated via a diversified key exchange between the user device and the contactless card; (Regarding wherein the authentication credential includes a message authentication code (MAC): 0052 "At step 104, after communication has been established between client device 110 and contactless card 105, the contactless card 105 generates a message authentication code (MAC) cryptogram in accordance with the NFC Data Exchange Format. … The MAC cryptogram may be created from the message, which may include the header, payload, and the shared secret. The MAC cryptogram may then be concatenated with one or more blocks of random data, and the MAC cryptogram and a random number (RND) may be encrypted with a session key." (Note 0052 (Fig. 2, 0050-0058) describes a general authentication process, among card, client device, and authentication server (authentication server not illustrated in Fig. 2; see 0058), similar to that of Fig. 8. Aspects of the authentication process of Fig. 2 may be employed in the authentication process of Fig. 8, as taught by 0108 ("Some embodiments may be described using the expression “one embodiment” or “an embodiment” along with their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. … unless otherwise noted the features described above are recognized to be usable together in any combination. Thus, any features discussed separately may be employed in combination with each other unless it is noted that the features are incompatible with each other."). In any event, it would be obvious to combine embodiments so as to use the MAC cryptogram of 0052 in the authentication process of Fig. 8 because using a MAC cryptogram as authentication credential is a known authentication technique that provides for security of sensitive data and of the authentication process and as such the combination is merely a matter of combining prior art elements according to known methods to yield predictable results; and/or simple substitution of one known element (MAC cryptogram used in Fig. 2, see 0052) for another (encrypted authentication credentials used in Fig. 8, see 0099) to obtain predictable results. MPEP 2143.I. (A), (B).; regarding generated via a diversified key exchange between the user device and the contactless card: As per 0026-0027, Mossler incorporates by reference Osborn (U.S. patent application Ser. No. 16/205,119, which issued in U.S. Patent No. 10,581,611), with specific reference to Osborn's "cryptogram exchange protocol." Osborn teaches "key diversification" (7:18-19 (Fig. 2), 12:45 (Fig. 4), 19:10, 19:22-23, 19:56 (Fig. 8), 14:52-53 (Fig. 11)). Specifically, e.g., "part of the data exchanged between the transmitting device 205 and receiving device 210 comprises at least a portion of data which may be referred to as the counter value. The counter value may comprise a number that changes each time data is exchanged between the transmitting device 205 and the receiving device 210." (7:39-45). Further, "At block 225, when the transmitting device 205 is preparing to process the sensitive data with symmetric cryptographic operation, the sender may update a counter. In addition, the transmitting device 205 may select an appropriate symmetric cryptographic algorithm, which may include at least one of a symmetric encryption algorithm, HMAC algorithm, and a CMAC algorithm. In some examples, the symmetric algorithm used to process the diversification value may comprise any symmetric cryptographic algorithm used as needed to generate the desired length diversified symmetric key." (8:24-34), then "At block 230, the transmitting device 205 may take the selected cryptographic algorithm, and using the master symmetric key, process the counter value. For example, the sender may select a symmetric encryption algorithm, and use a counter which updates with every conversation between the transmitting device 205 and the receiving device 210. The transmitting device 205 may then encrypt the counter value with the selected symmetric encryption algorithm using the master symmetric key, creating a diversified symmetric key." (8:45-54), and finally "At block 235, the diversified symmetric key may be used to process the sensitive data before transmitting the result to the receiving device 210. For example, the transmitting device 205 may encrypt the sensitive data using a symmetric encryption algorithm using the diversified symmetric key, with the output comprising the protected encrypted data. The transmitting device 205 may then transmit the protected encrypted data, along with the counter value, to the receiving device 210 for processing." (8:59-67). In the foregoing process, the counter, counter value, or the like, may be the diversification value/diversification data. (9:43-10:5, 19:22-24).
Note also per 19:22-24 the counter is used to create a session key (a different session key is created/used for each transmission between transmitting and receiving devices (each authentication session)). And as per 19:36-41 (Fig. 8, 830), "the … session key may be used to prepare the MAC cryptogram, … before it is transmitted …." Similar processes are taught with reference to Figs. 4 and 11: "At block 430, sensitive data may be protected using one or more cryptographic algorithms and the diversified keys. The diversified session keys, which may be created by the key diversification which uses the counter, may be used with one or more cryptographic algorithms to protect the sensitive data. For example, data may be processed by a MAC using a first diversified session key, and the resulting output may be encrypted using the second diversified session key producing the protected data." (13:57-65, Fig. 4, 430); "At block 1120, the counter value may be encrypted by the sender using the data encryption master key to produce the data encryption derived session key, and the counter value may also be encrypted by the sender using the data integrity master key to produce the data integrity derived session key. … At block 1130, the data to be protected is processed with a cryptographic MAC operation by the sender using the data integrity session key and a cryptographic MAC algorithm. The protected data, including plaintext and shared secret, may be used to produce a MAC using one of the session keys (AUT-Session-Key)." (24:61-25:10, Fig. 11, 1120, 1130).
(Note although the above descriptions from Osborn generally speak in terms of a transmitting device and a receiving device, these devices may refer to a user device and a contactless card (both of which may function as both transmitting device and receiving device), see, e.g., 26:3-12, 31:1-2. In addition, Osborn, like Mossler, envisions authentication in the context of requesting access to transaction data, see, e.g., 30:51-67.)
Thus, as taught by the foregoing, the counter/counter value, or session key(s) created based on the counter/counter value, is used to generate the MAC cryptogram (containing the sensitive data). Therefore, the MAC cryptogram is generated based on the counter/counter value. Further, the counter/counter value in turn constitutes diversification data, which is produced via a diversified key exchange between transmitting device and receiving device (user device and contactless card), inasmuch as the counter value is updated -- i.e., generated anew -- with each transmission (exchange) between transmitting device and receiving device (-- any counter value currently being used has been generated in the previous exchange between card and user device). Therefore, the MAC cryptogram is generated via a diversified key exchange between the user device and the contactless card.
In short, the MAC is generated using counter values or session keys (created based on counter values), which constitute diversification data, generated during key exchange between card and user device, thus teaching that the MAC is generated via a diversified key exchange between the user device and the contactless card.
Note abbreviated versions of Osborn's teachings are found in Mossler 0052 ("the MAC cryptogram and a random number (RND) may be encrypted with a session key") and 0079 ("encrypt the counter value using one or more cryptographic algorithms and the diversified key to yield an encrypted counter value" and "transmit the encrypted counter value and encrypted transmission data to the receiving device as a [the MAC] cryptogram.") but Osborn provides clarifying elaboration / implementation detail.)
transmitting, by the user device, the authentication credential to the server; (Fig. 8, 804 cryptogram is transmitted by client device 830 to authentication server 850; note step 804 occurs between 0098 and 0099 but description of step 804 in Mossler's specification is omitted, apparently inadvertently. Note Fig. 2 teaches an authentication process among client device, card and authentication server, similar to Fig. 8, in which client device 110 sends the cryptogram to the authentication server 160, which performs verification on the cryptogram, see Fig. 2, 108, 112, 0056-0058 ("processor 124 [client device 110] may output the MAC cryptogram for transmission to the authentication server 160 of the service provider 120, which may verify the MAC cryptogram.").)
upon receiving the authentication credential, matching, by the server, the authentication credential with a user profile of a user to authenticate the user, (0099 "… the authentication server 850 may be configured to store at least username, master key information and counter information for each client [a user profile of a user]. The authentication server 850 may decrypt the encrypted username, comparing the decrypted username against a stored username [a user profile of a user] known to correspond to the client for verifying client identity. The authentication server 850 may further decrypt the cryptogram, …. The authentication server 850 compares a password extracted from the cryptogram against a stored, expected password for the client [a user profile of a user] to approve [indicating a match] or deny the application request." -- the comparing is for the purpose of matching, if a match is found the request is approved, if a match is not found the request is denied.)
wherein the user is a user associated with the user device transmitting the request for transaction data; (0086 "At step 730, once the card is registered to the client [user], the client and card combination may be bound to [associated with] one or more client device(s) [user device]." Note 730 is part of a registration process (Fig. 7) in which client registers with application service in order to access application services. Fig. 8 (parts of which are cited and described above) is a process of authenticating the client for this access to application services.; 0089 "In the embodiment of FIG. 8, the client [user], contactless card and client device(s) [user device] have been previously registered with the application [associated with each other] using a method similar to that described with regard to FIG. 7, and the user of the web device 810 seeking access to the application takes advantage of this association [associated with each other] …."; regarding transmitting the request for transaction data: Note the authentication request received by client device 830 from server 820 (0093, 0097 "notification"/"prompt") is in response to the client's request for access to application services (0083 "application services," 0087 "client application access," 0088 "application launch request," 0089 "the user … seeking access to the application," 0090 "the access request," 0091 "the launch request," 0093 "an access request … for an application," 0095 "to initiate application launch," 0097 "an attempt has been made to access a service provider application … accessing the service provider application," 0025 "application access service"). Accordingly, the client being authenticated here (Fig. 8) is a client who has (via the client device) previously requested access to application services. Further, as per 0003, by "application services" Mossler means to include accessing sensitive financial information, such as purchase history. Accordingly, the client being authenticated here (Fig. 8) is a client who has (via the client device) previously requested access to transaction data (transmitting the request for transaction data))
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified Krakowiecki's systems and methods for retrieval, organization and management of financial data, by incorporating therein these teachings of Mossler regarding authentication by a server using an authentication credential received by a user mobile device from a contactless card, for access to account information/services, because doing so would provide for security of Krakowiecki's financial data, with added convenience and heightened security by not requiring the user to manually enter credentials, and Krakowiecki endorses such security but does not flesh out the details thereof as Krakowiecki is not primarily directed to this aspect, see Mossler, 0002-0005, 0012, 0030, see Osborn, 1:21-49, 3:29-44 (Osborn is incorporated by reference in Mossler, as per Mossler 0026), see Krakowiecki, 6:61-7:2 (requiring authentication/login procedure, without providing elaboration / implementation detail thereof).
Regarding Claim 3
Krakowiecki in view of Mossler teaches the limitations of base claim 1 as set forth above. Mossler further teaches:
wherein the communication field is a near field communication (NFC) field, Bluetooth, or a radio frequency identification (RFID) enabled field. (0048, 0041, 0055, 0095, 0098)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Krakowiecki's systems and methods for retrieval, organization and management of financial data, as modified by Mossler's teachings regarding authentication by a server using an authentication credential received by a user mobile device from a contactless card, for access to account information/services, by incorporating therein these further teachings of Mossler regarding a communication field between card and device, because Mossler's communication fields (NFC, etc.) are known standard communication methods that would perform the same way if used in the context of Krakowiecki, and as such the combination is merely a matter of combining prior art elements according to known methods to yield predictable results. MPEP 2143.I. (A)
Regarding Claim 4
Krakowiecki in view of Mossler teaches the limitations of base claim 1 as set forth above. Krakowiecki further teaches:
wherein the completed transaction is a consumer transaction between the user and a merchant. (Abstract, 11:14-62, 12:48-50, 12:61-13:60 user's transactions have merchant categories, indicating the transaction is a consumer transaction between user and merchant)
Regarding Claim 5
Krakowiecki in view of Mossler teaches the limitations of base claim 1 as set forth above. Mossler further teaches:
wherein the authentication credential is a customer identification number associated with the contactless card. (0017 "FIG. 5 is a diagram of exemplary fields of messages exchanged between a contactless card and a client device of FIG. 1;"; 0070-0073: "[0070] FIG. 5 illustrates an exemplary NDEF short-record layout (SR=1) 500 according to an example embodiment. An NDEF message provides a standardized method for a client device 110 to communicate with a contactless card 105. In some examples, NDEF messages may comprise one or more records. The NDEF record 500 includes … a Type Name Format (TNF) field 503 f. [0071] The TNF field 503 f identifies the type of content that the field contains, as defined by the NFC protocol. These types include …. [0072] Other fields of an NFC record include type length 504, payload length 506, ID length 508, Type 510, ID 512 and Payload 514. … Type 510 identifies the type of data that the payload contains. For example, for authentication purposes, the Type 510 may indicate that the payload includes a username/password pair. … Payload 514 comprises the message. [0073] In some examples, data may initially be stored in the contactless card …. This data may include a personal User ID (pUID) or other username that is unique to the card, …."; Note as per Osborn, e.g., 20:3-8, a pUID is a number: "… the card's unique ID number (pUID) …. The pUID may comprise a 16-digit numerical value. As explained above, pUID may comprise a 16 digit BCD encoded number. In some examples, pUID may comprise a 14-digit numerical value." (Osborn, U.S. patent application Ser. No. 16/205,119, which issued in U.S. Patent No. 10,581,611, is incorporated by reference in Mossler, see 0026.))
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Krakowiecki's systems and methods for retrieval, organization and management of financial data, as modified by Mossler's teachings regarding authentication by a server using an authentication credential received by a user mobile device from a contactless card, for access to account information/services, by incorporating therein these further teachings of Mossler regarding using a card ID number (pUID) as an authentication credential, because doing so would provide for security of Krakowiecki's financial data, with added convenience and heightened security by not requiring the user to manually enter credentials, and Krakowiecki endorses such security but does not flesh out the details thereof as Krakowiecki is not primarily directed to this aspect, see Mossler, 0002-0005, 0012, 0030, see Osborn, 1:21-49, 3:29-44 (Osborn is incorporated by reference in Mossler, as per Mossler 0026), see Krakowiecki, 6:61-7:2 (requiring authentication/login procedure, without providing elaboration / implementation detail thereof).
Regarding Claim 6
Krakowiecki in view of Mossler teaches the limitations of base claim 1 as set forth above. Mossler further teaches:
wherein the user device is further configured to perform a public-private key exchange with the contactless card. (Osborn 6:23-28 a public key asymmetric algorithm, i.e., public-private key exchange, may be used in the MAC cryptogram verification process between card and user device, i.e., Fig. 1B, step 112, described at 6:13-16. (Osborn, U.S. patent application Ser. No. 16/205,119, which issued in U.S. Patent No. 10,581,611, is incorporated by reference in Mossler, see 0026.))
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Krakowiecki's systems and methods for retrieval, organization and management of financial data, as modified by Mossler's teachings regarding authentication by a server using an authentication credential received by a user mobile device from a contactless card, for access to account information/services, by incorporating therein these further teachings of Mossler regarding using a public key asymmetric algorithm in an exchange between card and user device, because doing so would provide for security of Krakowiecki's financial data, with added convenience and heightened security by not requiring the user to manually enter credentials, and Krakowiecki endorses such security but does not flesh out the details thereof as Krakowiecki is not primarily directed to this aspect, see Mossler, 0002-0005, 0012, 0030, see Osborn, 1:21-49, 3:29-44 (Osborn is incorporated by reference in Mossler, as per Mossler 0026), see Krakowiecki, 6:61-7:2 (requiring authentication/login procedure, without providing elaboration / implementation detail thereof).
Regarding Claim 7
Krakowiecki in view of Mossler teaches the limitations of base claim 1 as set forth above. Krakowiecki further teaches:
wherein the user device is further configured to edit the one or more data received from the server before storing the completed data fields in the data storage unit. (Figs. 16-18, 12:61-13:60, "edit," "edit transaction details")
Regarding Claim 8
Krakowiecki in view of Mossler teaches the limitations of base claim 1 as set forth above. Krakowiecki further teaches:
wherein the user device is further configured to receive an item code associated with the completed transaction and populate a data field of the one or more data fields with the item code. (Fig. 16, 1212, 1228, Fig. 17, 1262, 1264, Fig. 18, 1312, 1314; 12:61-13:60, "edit," "edit transaction details" -- user device receives input, e.g., category (code), from user and populates corresponding data field; as per 4:30-43 and Fig. 16, 1212, Fig. 17, 1262, Fig. 18, 1312, category codes may indicate item purchased (e.g., auto rental), therefore under broadest reasonable interpretation category code is "item code")
Regarding Claims 10 and 14
Krakowiecki in view of Mossler teaches the limitations of base claims 1 and 11 as set forth above. Krakowiecki further teaches:
further comprising accessing (claim 10) / wherein the processor is further configured to access (claim 14) a spending habit report, and wherein the spending habit report has been generated by the user device based on historical data fields from past transactions. (Figs. 7A (611), 7B, 13, 16 “My Spending Report”)
Regarding Claim 12
Krakowiecki in view of Mossler teaches the limitations of base claim 11 as set forth above. Krakowiecki further teaches:
wherein the one or more data fields comprise purchase dates, merchant names, and item names. (Figs. 16, 17 posting date 1208, 1254 (purchase date), description 1210, 1256: Chevron (merchant name), category 1212, 1262: auto/gas (item name), 4:30-43, 5:16-29 categories, e.g., auto rental (item name))
Regarding Claim 13
Krakowiecki in view of Mossler teaches the limitations of base claim 11 as set forth above. Krakowiecki further teaches:
wherein the one or more data fields comprise a merchant categorization code (MCC) and location of the completed transaction. (Figs. 16, 17, category 1212, 1262, 4:30-43, 5:16-29 merchant categories codes; description 1210, 1256: Redwood City CA (location))
Regarding Claim 17
Krakowiecki in view of Mossler teaches the limitations of base claim 11 as set forth above. Krakowiecki further teaches:
wherein the data storage unit is configured to store historical transaction data associated with purchases made by a user in connection with the … card. (Fig. 1, 23, 25, e.g., 5:34-35 “banking transactions being stored in the database 25,” Fig. 2, 28, Fig. 3, 40, 42, 44, 46, Fig. 11, 954, e.g., 1067-11:4 “Storage device 954 is configured to store financial data for a number of different user accounts, such as a checking account, a credit card account, etc., and facilitate retrieval and usage of such data by server system 952.”)
Mossler further teaches:
… the contactless card; (Fig. 2, 105 contactless card, Fig. 8, 840 contactless card)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Krakowiecki's systems and methods for retrieval, organization and management of financial data, as modified by Mossler's teachings regarding authentication by a server using an authentication credential received by a user mobile device from a contactless card, for access to account information/services, by incorporating therein these further teachings of Mossler regarding a contactless card for use in Mossler's authentication process, because doing so enables Mossler's authentication process and hence serves to provide security for Krakowiecki's financial data, with added convenience and heightened security by not requiring the user to manually enter credentials, and Krakowiecki endorses such security but does not flesh out the details thereof as Krakowiecki is not primarily directed to this aspect, see Mossler, 0002-0005, 0012, 0030, see Osborn, 1:21-49, 3:29-44 (Osborn is incorporated by reference in Mossler, as per Mossler 0026), see Krakowiecki, 6:61-7:2 (requiring authentication/login procedure, without providing elaboration / implementation detail thereof). In addition, the combination is merely a matter of combining prior art elements according to known methods to yield predictable results. MPEP 2143.I. (A)
Regarding Claim 18
Krakowiecki in view of Mossler teaches the limitations of base claim 11 as set forth above. Krakowiecki further teaches:
wherein the processor is further configured to edit, upon receiving information given by a user, data fields that have already been populated by the server. (Fig. 16, 1212, 1228, Fig. 17, 1262, 1264, Fig. 18, 1312, 1314; 12:61-13:60, "edit," "edit transaction details")
Claims 2 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Krakowiecki et al. (U.S. Patent No. 8,170,932), hereafter Krakowiecki, in view of Mossler et al. (U.S. Patent Application Publication No. 2021/0029111 A1), hereafter Mossler, and further in view of Rule et al. (U.S. Patent Application Publication No. 2020/0250659 A1), hereafter Rule.
Regarding Claims 2 and 20
Krakowiecki in view of Mossler teaches the limitations of base claims 1 and 19 as set forth above.
Mossler further teaches:
receiving, by the user device from the contactless card, a first uniform resource … (UR…); (0053 "the MAC cryptogram [sent at 106 from card 105 to client device 110, see Fig. 2] may be included with a uniform resource indicator (e.g., as a formatted string).")
transmitting, by the user device, the first UR… to the server; (Fig. 2, 108, 112, 0056-0058 client device 110 sends the cryptogram to the authentication server 160 ("processor 124 [client device 110] may output the MAC cryptogram for transmission to the authentication server 160 of the service provider 120, which may verify the MAC cryptogram."); Fig. 8, 804 cryptogram is transmitted by client device 830 to authentication server 850; note cryptogram of Fig. 8 may be the MAC cryptogram included with URI of Fig. 2)
… wherein the server has matched the first UR… with a user on file; and (Fig. 2, 108, 112, 0056-0058 ("processor 124 [client device 110] may output the MAC cryptogram for transmission to the authentication server 160 of the service provider 120, which may verify the MAC cryptogram."); note the description of Fig. 8 elaborates on this verification of Fig. 2, clarifying that it involves the recited matching: 0099 "… the authentication server 850 may be configured to store at least username, master key information and counter information for each client [a user on file]. The authentication server 850 may decrypt the encrypted username, comparing the decrypted username against a stored username [a user on file] known to correspond to the client for verifying client identity. The authentication server 850 may further decrypt the cryptogram, …. The authentication server 850 compares a password extracted from the cryptogram against a stored, expected password for the client [a user on file] to approve [indicating a match] or deny the application request." -- the comparing is for the purpose of matching, if a match is found the request is approved, if a match is not found the request is denied. Note verifying the MAC cryptogram involves verifying the uniform resource indicator with which the MAC cryptogram may be included (e.g., as a formatted string).)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Krakowiecki's systems and methods for retrieval, organization and management of financial data, as modified by Mossler's teachings regarding authentication by a server using an authentication credential received by a user mobile device from a contactless card, for access to account information/services, by incorporating therein these further teachings of Mossler regarding the authentication including a URI as part of the cryptogram/payload received by the user mobile device from the contactless card, because the combination is merely a matter of combining prior art elements according to known methods to yield predictable results. MPEP 2143.I. (A)
In the context of the foregoing limitations, Mossler teaches a uniform resource indicator (URI), not a uniform resource locator (URL). A URI is either a URL or a URN (uniform resource name), so a URL is merely a very common kind of URI. While Mossler thus does not explicitly disclose a URL, Rule remedies this deficiency.
Krakowiecki in view of Mossler does not explicitly disclose the following limitations in their entirety but Rule teaches:
… uniform resource locator (URL); 0012-0013 bringing contactless card in communication range of computing device by tapping "[0012] … causes the contactless card to generate a uniform resource locator (URL) which is transmitted to the computing device … [0013] The URL generated by the contactless card may further include data used by an authentication server as part of a validation process."; note this teaching teaches the URL recited in all the above limitations of claims 2 and 20)
receiving, by the user device from the server, a second URL associated with the application configured to display the one or more data fields, wherein the application comprises a website application or a mobile application, … (Fig. 4, 420, 425, 0056 "At block 425, the application server 150 transmits the selected account application 151 and the URL to the mobile device 110.", 0051 "Regardless of the type of the account application 151, the OS 112 receives the URL with encrypted data from the application server 150 and provides the URL with encrypted data to the application as input."; as per 0056, the functionality of the application includes display of data fields ("(e.g., extracting encrypted data, transmitting encrypted data to the authentication server, receiving virtual card data from the VAN generator 142, and providing the received virtual card data to the autofill service 114)"), see Figs. 2B-2D, 0042-0045; note regarding second: the second URL taught here (which is sent from server to user device) is distinguished from the first URL, which is sent from card to user device, as per 0012-0013 as cited above in the immediately preceding bullet point, or again as per Fig. 3, 320)
opening the application associated with the second URL. (0056, 0058 "Doing so causes the selected application to be dynamically downloaded and installed on the mobile device 110."; then, the application is opened upon installation or downloading as per: 0027 “the URL 106 may include an indication of which page of the application 151 to open upon installation”; 0050 “an instant application 152 version of the account application 151 is downloaded and installed on the mobile device 110. As shown, the account application 151 opens a page …”; 0060; 0033 “once downloaded to the mobile device 110, the account application 151-1 may open one or more pages,”; 0043 “an instant application 152 version of the account application 151 is downloaded and installed on the mobile device 110. As shown, the account application 151 opens a page …”; again, 0059 teaches application is executed, while 0022 teaches application is opened upon execution)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Krakowiecki's systems and methods for retrieval, organization and management of financial data, as modified by Mossler's teachings regarding authentication by a server using an authentication credential received by a user mobile device from a contactless card, for access to account information/services, by incorporating therein these teachings of Rule regarding (1) a first URL (sent from a card to a user mobile device as part of an authentication process) and (2) a server providing to a user mobile device a second URL associated with an application, because (1) Krakowiecki teaches a URI and the substitution of Rule's URL for Krakowiecki's URI amounts to merely simple substitution of one known element for another to obtain predictable results, MPEP 2143.I. (B), and (2) Rule's teachings of a server providing to a user mobile device a second URL associated with an application constitute a known way for a server to provide data/functionality to a client, and as such would operate in the same way in Krakowiecki as in Rule, if employed by Krakowiecki in addition to or instead of the ways in which Krakowiecki carries out such provision, and as such, this combination amounts to merely combining prior art elements according to known methods to yield predictable results and/or simple substitution of one known element for another to obtain predictable results, MPEP 2143.I. (A) and/or (B).
Claims 8, 9 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Krakowiecki et al. (U.S. Patent No. 8,170,932), hereafter Krakowiecki, in view of Mossler et al. (U.S. Patent Application Publication No. 2021/0029111 A1), hereafter Mossler, and further in view of Gancarz (U.S. Patent Application Publication No. 2020-0028675 A1).
Regarding Claim 8
Krakowiecki in view of Mossler teaches the limitations of base claim 1 as set forth above. Alternatively to the above rejection of claim 8, which cites Krakowiecki as teaching the limitations unique to claim 8, Gancarz teaches:
wherein the user device is further configured to receive an item code associated with the completed transaction and populate a data field of the one or more data fields with the item code. (0041)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Krakowiecki's systems and methods for retrieval, organization and management of financial data, as modified by Mossler's teachings regarding authentication by a server using an authentication credential received by a user mobile device from a contactless card, for access to account information/services, by incorporating therein these teachings of Gancarz regarding using an item code to insert transaction data, because doing so would provide convenience by not requiring the user to manually enter data, and would increase security by maintaining integrity of financial data and eliminating/ reducing data entry errors, see Gancarz 0004, see Mossler, 0002-0005, 0012, 0030, see Osborn, 1:21-49, 3:29-44 (Osborn is incorporated by reference in Mossler, as per Mossler 0026), see Krakowiecki, 6:61-7:2 (requiring authentication/login procedure, without providing elaboration / implementation detail thereof).
Regarding Claim 9
Krakowiecki in view of Mossler and (optionally) Gancarz teaches the limitations of base claim 1 and intervening claim 8 as set forth above. Gancarz further teaches:
wherein the item code is a barcode, a quick response (QR) code, a universal product code, or a stock keeping unit. (0041)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Krakowiecki's systems and methods for retrieval, organization and management of financial data, as modified by Mossler's teachings regarding authentication by a server using an authentication credential received by a user mobile device from a contactless card, for access to account information/services, (and as further modified by Gancarz's teachings regarding using an item code to insert transaction data,) by incorporating therein these (further) teachings of Gancarz regarding using a QR code to insert transaction data, because doing so would provide convenience by not requiring the user to manually enter data, and would increase security by maintaining integrity of financial data and eliminating/reducing data entry errors, see Gancarz 0004, see Mossler, 0002-0005, 0012, 0030, see Osborn, 1:21-49, 3:29-44 (Osborn is incorporated by reference in Mossler, as per Mossler 0026), see Krakowiecki, 6:61-7:2 (requiring authentication/ login procedure, without providing elaboration / implementation detail thereof), and because a QR code is a known, standard, efficient means for holding, capturing, and transmitting information such that the use of a QR code in particular in this context amounts to merely combining prior art elements (incorporating Gancarz's teachings regarding using a QR code into Krakowiecki's systems and methods) according to known methods to yield predictable results, MPEP 2143.I. (A).
Regarding Claim 16
Krakowiecki in view of Mossler teaches the limitations of base claim 11 as set forth above. Krakowiecki in view of Mossler does not explicitly disclose but Gancarz teaches:
wherein the user device further comprises a camera configured to scan an item code associated with the completed transaction. (0041)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Krakowiecki's systems and methods for retrieval, organization and management of financial data, as modified by Mossler's teachings regarding authentication by a server using an authentication credential received by a user mobile device from a contactless card, for access to account information/services, by incorporating therein these teachings of Gancarz, because doing so would provide convenience by not requiring the user to manually enter data, and would increase security by maintaining integrity of financial data and eliminating/reducing data entry errors, see Gancarz 0004, see Mossler, 0002-0005, 0012, 0030, see Osborn, 1:21-49, 3:29-44 (Osborn is incorporated by reference in Mossler, as per Mossler 0026), see Krakowiecki, 6:61-7:2 (requiring authentication/login procedure, without providing elaboration / implementation detail thereof).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Krakowiecki et al. (U.S. Patent No. 8,170,932), hereafter Krakowiecki, in view of Mossler et al. (U.S. Patent Application Publication No. 2021/0029111 A1), hereafter Mossler, and further in view of Moreton et al. (U.S. Patent Application Publication No. 2022/0247741 A1), hereafter Moreton.
Regarding Claim 15
Krakowiecki in view of Mossler teaches the limitations of base claim 11 as set forth above. Krakowiecki in view of Mossler does not explicitly disclose the following limitations in their entirety but Moreton teaches:
wherein the processor further configured to populate at least one data field of the one or more data fields with card information upon the contactless card entering the communication field. (0037 and 0051 "the received VAN, expiration date, and/or CVV may be autofilled to one or more forms.")
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Krakowiecki's systems and methods for retrieval, organization and management of financial data, as modified by Mossler's teachings regarding authentication by a server using an authentication credential received by a user mobile device from a contactless card, for access to account information/services, by incorporating therein these teachings of Moreton regarding autofilling card data, because doing so would provide convenience by not requiring the user to manually enter data, and would eliminate/reduce data entry errors and maintain integrity of financial data, thereby increasing security, see Moreton, 0002, 0012, 0015, see Mossler, 0002-0005, 0012, 0030, see Osborn, 1:21-49, 3:29-44 (Osborn is incorporated by reference in Mossler, as per Mossler 0026), see Krakowiecki, 6:61-7:2 (requiring authentication/login procedure, without providing elaboration / implementation detail thereof).
Conclusion
The prior art made of record and not relied upon, as set forth in the accompanying Notice of References Cited (PTO-892), is considered pertinent to applicant's disclosure. Among the cited references:
Kandasamy (US-20220337694-A1), Patel (US-20230245124-A1), Dyor (US-20100332353-A1) and Chandrasekar (US-20220114659-A1) teach editing/correcting data fields in transaction data;
Rule (US-20200250672-A1), Rule (US-20210342809-A1), and Ji (US-11216799-B1) teach authentication involving a user/mobile device receiving a credential/URL from a contactless card; and
Rule (US-20200019725-A1) teaches a URL for authentication and for receiving/ displaying financial information from a server.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DOUGLAS W PINSKY whose telephone number is (571)272-4131. The examiner can normally be reached on 8:30 am - 5:30 pm ET.
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, Jessica Lemieux can be reached on 571-270-3445. 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.
/DOUGLAS W PINSKY/Examiner, Art Unit 3626