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 .
Status of the Application
Claims 1-2, 4-7, 14-17, and 20 have been examined in this application.
The filling date of this application number recited above is 02 October 2019. Domestic Benefit/National Stage priority has been claimed for provisional application 62/740,255 in the Application Data Sheet, thus the examination will be undertaken in consideration of 02 October 2018, as the priority date, for applicable claims.
No additional information disclosure statement (IDS) has been filed to date.
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-2, 4-7, 14-17, and 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. The Claims are directed to an abstract idea, Certain Methods of Organizing Human Activity. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional computer elements, which are recited at a high level of generality, provide conventional computer functions that do not add meaningful limits to practicing the abstract idea.
As per Claim 1, the claim recites “[an entity] comprising:
a validation [worker] to:
receive an image of a customer’s identification (ID) …;
determine an ID type for said customer's ID;
obtain a valid ID layout for said determined ID type; and
compare said image of said customer's ID with said valid ID layout for said determined ID type to validate said image of said customer's ID; and
… validate a geographic location of said customer …;
a customer account identifier to:
identify the customer via the validated image of the customer's ID; and
link the validated image of the customer's ID with one or more customer accounts held by the identified customer to build a customer data file, said customer accounts comprising: at least one credit account, at least one reward account, and at least one savings vehicle selected from a group consisting of: a coupon, an offer, and a promotion;
a token generator to generate token identifying customer data file, said token comprising anti-tamper … protection;
a metadata file generator to build a metadata file in compliance with a … wallet format, the metadata file comprising:
said token embedded within the validated image of the customer’s ID to form a tokenized image of said customer’s ID, said tokenized image of said customer’s ID useable as a stand-alone tender vehicle at a point-of-purchase, wherein said use of said tokenized image of said customer’s ID at said point-of-purchase includes … selection of an appropriate one or more of said customer accounts of said customer data file to use for a purchase; and
an instruction to cause said tokenized image of said customer’s ID to be presented first in a … wallet stack on a … wallet of said customer … when said … wallet is accessed; and
a transmitter to transmit said metadata file to said .. wallet of said customer … .
As per claim 14, the claim recites “[an entity] comprising:
a credit provider [team], the credit provider [team] comprising:
a database that stores a plurality of customer accounts, said customer accounts comprising: credit accounts and reward accounts, and savings vehicles comprising: coupons, offers, and promotions; and
a [worker] to:
receive an image of a customer’s identification (ID) …;
determine an ID type for the customer’s ID;
obtain a valid ID layout for the determined ID type;
compare the image of the customer’s ID with the valid ID layout for the determined ID type to validate the image of the customer’s ID;
identify a customer based on the validated image of the customer's ID;
search the database for one or more customer accounts of the plurality of customer accounts that are held by the identified customer;
link the validated image of the customer's ID with the one or more customer accounts held by the identified customer to build a customer data file, said customer data file comprising: at least one credit account, at least one reward account, and at least one savings vehicle selected from a group consisting of: a coupon, an offer, and a promotion;
… validate a geographic location of said customer …;
generate a token to identify the customer data file; and
generate a metadata file formatted for a … wallet, the metadata file comprising:
said token embedded within the validated image of the customer's ID to form a tokenized image of said customer's ID, said tokenized image of said customer's ID useable as a stand-alone tender vehicle at a point-of-purchase, wherein said use of said tokenized image of said customer's ID at said point-of-purchase includes … selection of an appropriate one or more of said customer accounts of said customer data file to use for a purchase; and
an instruction to cause said tokenized image of said customer’s ID to be presented on a top of a … wallet stack in a … wallet of said customer … when said … wallet is opened; and
transmit said metadata file to said … wallet of said customer …, and
said customer … comprising:
said … wallet;
…
… executing the instructions, to:
receive said metadata file;
add said tokenized image of said customer’s ID to said … wallet;
open said … wallet, wherein said tokenized image of said customer’s ID is presented on said top of said … wallet stack when … wallet is opened; and
use said presented tokenized image of said customer’s ID as a stand-alone tender vehicle at a point-of-purchase.”
The limitation of the claims recited above, considering the claims without the additional elements (e.g. system, processor, device, etc.), under its broadest reasonable interpretation (BRI), recites Certain Methods of Organizing Human Activity, specifically under fundamental economic principles or practices and/or commercial or legal interactions. The method recited above is a process to build a file or data comprising an image of the customer’s ID and generating a token representing the customer’s credit account, which involves various interaction for the validation process (e.g. receive data, determine data, compare data, identify data, link data, etc.), wherein the token is merely a representation or saved data/information used in place of the customer’s financial account, which is used as a payment method for transactions, for the purpose of improving the conventional mobile payment process as disclosed by Specification [0013], [0014], [0017], and [0046]. The process of linking tokens and using tokens in place of a credit account is a fundamental economic principles or practices, and the various interactions performed for the validating and linking process to generate the token is commercial or legal interactions, wherein both categories are under certain methods of organizing human activity. Therefore, the claims recite an abstract idea.
This judicial exception is not integrated into practical application. In particular, the claims recite additional elements “system”, “validation engine”, “network connection”, “customer account identifier”, “token generator”, “metadata file generator”, “mobile wallet”, “mobile device”, “credit provider computer system”, “memory”, “processor”, “internet connection”, “ID type determiner”, “valid ID layout comparator”, and “database” to perform the method recited above by instructing the abstract idea to be performed “by” these generic computer components. As shown in Figures 1 and 5, and Specification:
[0020] “In general, mobile device 110 is an example of a customer’s mobile device, a store’s mobile device, an associate’s mobile device, or the like. Mobile device 110 could be a mobile phone, a smart phone, a tablet, a smart watch, a piece of smart jewelry, smart glasses, or other user portable devices having wireless connectivity. For example, mobile device 110 would be capable of broadcasting and receiving via at least one network, such as, but not limited to, WiFi, Cellular, Bluetooth, NFC, and the like. In one embodiment, mobile device 110 includes a display 112, a processor 114, a memory 116, a GPS 118, a camera 119, and the like”;
[0021] “Mobile device 110 also includes a mobile wallet 129 which is an electronic application that operates on mobile device 110. Mobile wallet 129 includes mobile wallet ID 130. In general, mobile wallet ID 130 allows a customer to utilize a single mobile payment method that is linked to one or more credit account information, reward account information, offers, coupons, and the like, and is carried in a secure digital form on a mobile device 110. Instead of using a physical plastic card to make purchases, a mobile wallet allows a customer to pay via mobile device 110 in stores, in apps, or on the web”; and
[0066] “Figure 5 illustrates an example computer system 500 used in accordance with embodiments of the present technology. It is appreciated that computer system 500 of Figure 5 is an example only and that the present technology can operate on or within a number of different computer systems including general purpose networked computer systems, embedded computer systems, routers, switches, server devices, user devices, various intermediate devices/artifacts, stand-alone computer systems, mobile phones, personal data assistants, televisions and the like. As shown in Figure 5, computer system 500 of Figure 5 is well adapted to having peripheral computer readable media 502 such as, for example, a disk, a compact disc, a flash drive, and the like coupled thereto”,
the additional elements are generic, off-the-shelf computer components that are available to the public, and does not require any specialized hardware components or equipment to perform the claimed method. These generic computer components are merely instructed to perform its basic functionalities, such as: receive data, link data, store data, compare data, open data, and transmit data. For example, mere instructions to display information on a GUI does not improve computer functionality, see MPEP 2106.05(a)(I) example that the courts have indicated may not be sufficient to show an improvement in computer-functionality: “Arranging transactional information on a graphical user interface in a manner that assists traders in processing information more quickly, Trading Technologies v. IBG LLC, 921 F.3d 1084, 1093-94, 2019 USPQ2d 138290 (Fed. Cir. 2019)”. These general computer components are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer system. Mere instructions to implement the abstract idea on a generic computer system, or merely using the generic computer system as a tool to perform the abstract idea (e.g. mere “apply it”) is not indicative of integration into a practical application; see MPEP 2106.05(f). Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, transmit, compare, or display data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activities) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). Accordingly, 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. The claims are directed to an abstract idea.
The claims also recite additional elements “token generator to generate a token”, “metadata file generator to build a metadata file”, and “token”. As similarly discussed above, the “generators” are parts of the generic computer system merely applied to implement the abstract idea. With respect to the “token”, “metadata file”, and “customer data file”, these additional elements are mere data being gathered and/or manipulated, as disclosed by Specification:
[0039] “Once the customer data file was built, a token (e.g., an identification number, hash, or other type of anti-tamper encrypted protection) would be generated for the customer data file. The token would then be added to a metadata file 250 that would be built to meet any format, database, size, and storage requirements that were necessary for proper display and utilization in a customer’s mobile wallet on the mobile device 110”.
Mere data gathering (e.g. receive customer’s ID, build metadata, store credit accounts, etc.) and mere data manipulations (e.g. generate token to identify customer data file, generate metadata file to meet mobile wallet format, etc.) is adding insignificant extra-solution activity to the judicial exception, which is not indicative of integration into a practical application; see MPEP 2106.05(g). Therefore, the claims are directed to an abstract idea.
The claims also recite the additional element: “an instruction to cause said tokenized image of said customer’s ID to be presented first in a mobile wallet stack on a mobile wallet of a customer’s mobile device when said mobile wallet is accessed”. The use of the tokenized image is outside the scope of the system and is merely an “intended use” of the tokenized image, as it does not functionally distinguish the claimed invention. The “instruction” in the file is for merely presenting the data, which is not changing any functionality of the mobile wallet and/or modifying the mobile device and/or controlling the display itself, but are merely instructing which data to be displayed first. As similarly discussed above, mere “apply it” is not indicative of integration into a practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, when analyzed as a whole, considering the additional elements individually and/or as an ordered combination, the additional element of using a computer based system is recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer system. The claims lack sufficient technical details to provide how these limitations may provide technological steps or technical details on how it is particularly implemented on a computer to improve its system or any of its underlying hardware or components (e.g. how it is performed on the mobile device, how it could improve the mobile device itself, how it could manipulate the mobile device to function in a specific way other than its generic functionality, and/or how it could improve any of the underlying technology), but merely applies the generic computer system to perform its generic functionalities. Mere instructions to implement the abstract idea on the generic computer system, or merely using the generic computer system as a tool to perform the abstract idea (e.g. mere “apply it”) is not indicative of an inventive concept (aka “significantly more”). In view of the Specification, the judicial exception is not applied with or used by a particular machine. As held in Parker v. Flook, 437 U.S. 584, 590, 198 USPQ 193, 199 (1978) and Bancorp Services v. Sun Life, 687 F.3d 1266, 1276, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012), “the routine use of a computer to perform calculations cannot turn an otherwise ineligible mathematical formula or law of nature into patentable subject matter.” The claims are not patent eligible.
Regarding dependent claims, they are still directed to an abstract idea without significantly more.
Claim 2 recites “wherein the image of the customer's ID is received from said customer's mobile device.” The claim provides further details regarding the data (e.g. the image is received from a mobile device), wherein as similarly disclosed by its parent claim above, the additional elements are merely using the generic computer components as a tool to perform the abstract idea, which is not indicative of integration into a practical application. Additionally, mere data gathering and/or data manipulation is adding insignificant extra-solution activity to the judicial exception, which is not indicative of integration into a practical application.
Claim 4 recites “wherein the ID type is determined by an identifier from the group consisting of: an image matching software, and an optical character recognition.” The claim provides further details regarding the data (e.g. determining the ID type by using a software or OCR), wherein as similarly disclosed by its parent claim above, the additional elements are merely using the generic computer components as a tool to perform the abstract idea, which is not indicative of integration into a practical application. Additionally, mere data gathering and/or data manipulation is adding insignificant extra-solution activity to the judicial exception, which is not indicative of integration into a practical application.
Claim 5 recites “wherein the validation engine further comprises: an ID layout database that includes a plurality of valid ID layouts for a plurality of different ID types.” The claim provides further details regarding the validation engine (e.g. comprising a database), wherein as similarly disclosed by its parent claim above, the additional elements are merely using the generic computer components as a tool to perform the abstract idea (e.g. database storing data), which is not indicative of integration into a practical application. Additionally, mere data gathering and/or data manipulation is adding insignificant extra-solution activity to the judicial exception, which is not indicative of integration into a practical application.
Claim 6 recites “wherein the validation engine compares one or more ID characteristics from the group consisting of: an image requirement, a layout, a data, an identifying characteristic, a hologram, a color, a valid date, a spacing, an orientation, a decal, a blacklight word, a state specific layout, a front-side and back-side evaluation, a front-side evaluation, and a back-side evaluation.” The claim provides further details regarding the data (e.g. group of data for comparison), wherein as similarly disclosed by its parent claim above, the additional elements are merely using the generic computer components as a tool to perform the abstract idea, which is not indicative of integration into a practical application. Additionally, mere data gathering and/or data manipulation is adding insignificant extra-solution activity to the judicial exception, which is not indicative of integration into a practical application.
Claim 7 recites “further comprising: a database that stores a plurality of customer accounts; and said customer account identifier to: search the database for one or more customer accounts of the plurality of customer accounts that are held by the identified customer.” The claim provides further details regarding additional elements (e.g. database and processor), wherein as similarly disclosed by its parent claim above, the additional elements are merely using the generic computer components as a tool to perform the abstract idea (e.g. database to store data and processor to identify and search data), which is not indicative of integration into a practical application. Additionally, mere data gathering and/or data manipulation is adding insignificant extra-solution activity to the judicial exception, which is not indicative of integration into a practical application.
Claim 15 recites “wherein the ID type is determined by an ID determiner from the group consisting of: an image matching software, and an optical character recognition.” The claim provides further details regarding the ID type determination, wherein as similarly disclosed by its parent claim above, the additional elements are merely using the generic computer components as a tool to perform the abstract idea (e.g. compare data), which is not indicative of integration into a practical application. Additionally, mere data gathering and/or data manipulation is adding insignificant extra-solution activity to the judicial exception, which is not indicative of integration into a practical application.
Claim 16 recites “wherein said valid ID layout is obtained from an ID layout database that includes a plurality of valid ID layouts for a plurality of different ID types.” The claim provides further details regarding the validation engine (e.g. comprising a database), wherein as similarly disclosed by its parent claim above, the additional elements are merely using the generic computer components as a tool to perform the abstract idea (e.g. database storing data), which is not indicative of integration into a practical application. Additionally, mere data gathering and/or data manipulation is adding insignificant extra-solution activity to the judicial exception, which is not indicative of integration into a practical application.
Claim 17 recites “wherein the comparison of the image of the customer’s ID with the valid ID layout compares one or more ID characteristics from the group consisting of: an image requirement, a layout, a data, an identifying characteristic, a hologram, a color, a valid date, a spacing, an orientation, a decal, a blacklight word, a state specific layout, a front-side and back- side evaluation, a front-side evaluation, and a back-side evaluation.” The claim provides further details regarding the data (e.g. group of data for comparison), wherein as similarly disclosed by its parent claim above, the additional elements are merely using the generic computer components as a tool to perform the abstract idea, which is not indicative of integration into a practical application. Additionally, mere data gathering and/or data manipulation is adding insignificant extra-solution activity to the judicial exception, which is not indicative of integration into a practical application.
Claim 20 recites “wherein the customer's mobile device further comprises: an image capturing device, the image capturing device to capture the image of the customer's ID; and a mobile network connection to provide the image of the customer's ID to said credit provider computer system.” The claim provides further details regarding additional elements (e.g. image capturing device), wherein as similarly disclosed by its parent claim above, the additional elements are merely using the generic computer components as a tool to perform the abstract idea (e.g. capture image data, transmit image data), which is not indicative of integration into a practical application. Additionally, mere data gathering and/or data manipulation is adding insignificant extra-solution activity to the judicial exception, which is not indicative of integration into a practical application.
These additional steps of each claims fail to remedy the deficiencies of their parent claim above because they are merely further limiting the rules used to conduct the previously recited abstract idea, and are therefore rejected for at least the same rationale as applied to their parent claim above.
Claims 2, 4-7, 15-17, and 20, when analyzed as a whole, considering the additional elements individually and/or as an ordered combination, are held to be patent ineligible under 35 U.S.C. 101 because the additional recited limitations fail to establish that the claims are sufficient to integrate into a practical application and do not amount to significantly more than the judicial exception. Similarly to the independent claims, each claim recites using a generic computer system to perform the abstract idea (e.g. “apply it”) as mentioned above. Mere instructions to implement the abstract idea on a generic computer system and/or adding insignificant extra-solution activity to the judicial exception is not indicative of an inventive concept (aka “significantly more”). Therefore, prong 2 and step 2B analysis are similar to above and these claims are not eligible.
Therefore, Claims 1-2, 4-7, 14-17, and 20 are not drawn to eligible subject matter as they are directed to an abstract idea without significantly more.
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-2 and 4-6 are rejected under 35 U.S.C. 103 as being unpatentable over Amtrup et al. (US 20150269433 A1), in view of Kohli (US 20170345000 A1), in view of JANG (KR 20180042788 A), in view of Purves et al. (US 20150220914 A1) in further view of Gower (US 20210374722 A1).
As per Claim 1, Amtrup discloses a system comprising:
a validation engine to:
receive an image of a customer’s identification (ID) via a network connection (See Figure 1, as disclosed [0055] “Turning now to the figures, FIG. 1 illustrates a network architecture 100, in accordance with one embodiment … In the context of the present network architecture 100, the networks 104, 106 may each take any form including, but not limited to a LAN, a WAN such as the Internet, public switched telephone network (PSTN), internal telephone network, etc.” and see Figure 4 – step 404, as disclosed [0122] “The method 400 also includes operation 404, in which an image comprising an ID is received. Again, the image is preferably received at a mobile device, or alternatively is captured using the mobile device, but the image may be received at any number of locations or resources involved in conducting the workflow” or see also Figure 6 – step 602 which teaches [0209] “Referring still to the Figures, FIG. 6 depicts a method 600 generally illustrating the overall inventive process of integrating ID classification techniques and/or mobile implementations thereof into business workflows, according to one embodiment. The method 600 may be practiced in any environment, using any number of suitable resources, such as depicted in FIGS. 1-3, among others”);
determine an ID type for said customer's ID (See Figure 6 – step 604 for classifying the ID, as disclosed [0192] “For example, in one approach a multi-level ID classification includes first classifying a document depicted in an image as an ID (e.g. as opposed to other types of document such as a financial document like a check or remittance slip), then classifying the ID as a particular type of ID (e.g. driver's license, credit card, social security card, tax form, passport, military ID, employee ID, insurance card, etc.)”, and see also [0194] “In one generic example, a first iteration may classify a document as an ID. A second iteration may classify the ID as a particular type of ID, e.g. a license. A third iteration may classify the license as a particular type of license, e.g. a driver's license or hunting license”);
obtain a valid ID layout for said determined ID type (See Figure 6 – step 606, as disclosed [0166] “Authentication data may still further include identifying information, in some approaches. Authentication data may additionally and/or alternatively include one or more unique identifiers. The unique identifier(s) may optionally be depicted on the ID or a portion of the ID, preferably a portion of the ID depicting unique image data, such as a facial photograph, a hologram, a logo, a watermark, a barcode, etc. or any combination thereof”); and
compare said image of said customer's ID with said valid ID layout for said determined ID type to validate said image of said customer's ID ([0165] “In various approaches, authentication data may include any data and/or metadata suitable for comparison to the processed image of the ID and/or associated metadata to determine a partial or complete match therebetween. Authentication data may include image(s), such as another image of the ID; another instance of the processed ID image; a portion of the ID image; etc. Authentication data may additionally and/or alternatively include image data descriptive of part or all of the processed ID image, such as the various types of image data utilized in the processing image operation(s) described herein” or see also [0211] “The method 600 also includes operation 604, in which the ID is classified. The classification may take any form such as described herein, but preferably the classifying is based at least in part on comparing feature vector data. The comparison may include comparing feature vector(s) to reference feature vector(s), a reference feature matrix or matrices, and/or by performing any number of pre-comparison analyses, computations, operations, or transformations of the feature vector (e.g. in one approach feature vectors may be subjected to a weighting process, and the resulting products compared rather than comparing the feature vectors per se)”);
…;
a customer account identifier to:
identify the customer via the validated image of the customer's ID (See Figure 5 – steps 502 and 504, as disclosed [0129] “The method 500 includes operation 502, where at least one image of one or more IDs are captured or received using a mobile device” and [0130] “The method 500 also includes operation 504, in which identifying information is determined from one or more of the IDs”); and
link the validated image of the customer's ID with one or more customer accounts held by the identified customer to build a customer data file, … (See Figure 5 – step 506, as disclosed [0131] “In operation 506, method 500 includes building an ID profile based in whole or in part on the generated data. The ID profile, as described in further detail with respect to various exemplary embodiments throughout these descriptions, may be built in any suitable form or using any suitable technique, and includes preferably identifying information from one or more IDs, even more preferably at least two of a plurality of IDs from which the data were generated. Even more preferably, the built ID profile comprises identifying information and/or image data from the plural IDs”);
Although Amtrup teaches of receiving and validating the customer’s ID wherein a customer profile is built with the customer identity and the ID image data as disclosed above, the prior art does not seem to explicitly disclose of validating the geographic location of the device. However, Kohli teaches:
automatically validate a geographic location of said customer’s mobile device ([0019] “In some embodiments, authentication data includes one or more of: (1) consumer device attributes such as, for example, … geo-location data (i.e., data from the device of the cardholder, indicating the assessed location of the device, such as GPS location, country, city, etc.)”);
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize validating the GPS location data of the customer’s device for the transaction as in Kohli, wherein the authentication information also includes ID as disclosed [0019] “(2) data from the merchant such as, for example, consumer contact information (personally identifiable information (PII) about the cardholder associated with the payment account that the candidate online payment transaction is for, which will be used to determine the likelihood that the merchant has the correct cardholder, and which may include … authentic issued official ID (e.g., passport, driver's license))”, in the system executing the method of Amtrup, with the motivation of offering to [0001-0003] mitigate risk of fraudulent transactions by improving transaction authentication process to enhance fraud detection as taught by Kohli over that of Amtrup.
Although Amtrup teaches of receiving and validating the customer’s ID wherein a customer profile is built with the customer identity and the ID image data as disclosed above, the prior art does not seem to explicitly disclose of linking the validated image of the customer’s ID with the customer account which may be a credit account, reward account, or a savings vehicle (e.g. coupon, offer, or promotion), to build and provide a token. However, JANG teaches:
link the validated image of the customer's ID with one or more customer accounts held by the identified customer to build a customer data file, said customer accounts comprising: at least one credit account, at least one reward account, and at least one savings vehicle selected from a group consisting of: a coupon, an offer, and a promotion ([Page 3 Lines 31-34] “In addition, when generating the mobile passport 1, corresponding coupon numbers are issued together and stored in the information. It is a matter of course that the issued coupon number can be used when the passport holder purchases the goods” which is obvious that the coupon number corresponds to a customer’s financial account in order to conduct transactions to purchase goods);
a token generator to generate a token identifying the customer data file, said token comprising anti-tamper encrypted protection (The QR code is generated as a token for the customer data file, as disclosed [Page 4 Lines 4-9] “The encryption unit 120 includes a character encryption module 121 for encrypting character information, a simple authentication number, and a coupon number in the passport information extracted through the mobile passport information generation unit 110, And an image encryption module (122) for encrypting image information including a photograph of the passport information extracted through the generation unit. The information selected by the combination of the character encryption module and the image encryption module is QR encoded”);
… the metadata file comprising:
said token embedded within the validated image of the customer's ID to form a tokenized image of said customer's ID, said tokenized image of said customer's ID useable as a stand-alone tender vehicle at a point-of-purchase, wherein said use of said tokenized image of said customer's ID at said point-of-purchase includes an automatic selection of an appropriate one or more of said customer accounts of said customer data file to use for a purchase (See Figure 9, as disclosed [Page 6 Lines 8-22] “An F1 step in which the merchant who wants to authenticate the mobile passport scans the coupon number associated with the mobile passport of the mobile passport holder; A step F2 of comparing the coupon number scanned in step F1 with the coupon number DB of the mobile coupon management issuing unit 112 via network communication; F3 step of confirming that the coupon number is a valid coupon number in step F2 and requesting the mobile passport management server 130 to authenticate the authentication key of the mobile passport linked to the coupon number; … and if it is a valid passport number F5 step of transmitting passport information corresponding to the passport number from the character information DB and the image information DB so as to be exposed on the display screen of the merchant; And a step F6 of confirming the passport information transmitted through the step F5 and comparing the passport photograph on the image information and the real product of the mobile passport holder with the merchant”); and
…
a transmitter to transmit said metadata file to … said customer’s mobile device via said network connection (See Figure 1 of the generated QR code (e.g. token) used by the mobile device, as disclosed [Page 3 Lines 26-27] “At this time, the mobile passport 1 can be converted and displayed on a display window of a terminal such as a smart phone, or outputted as a QR code”, which is transmitted to the mobile device after creation, as disclosed [Page 4 Lines 15-16] “Meanwhile, the terminal 140 transmits the encrypted QR code and the image information through the encryption generating unit 120 and is stored through the network”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize linking the validated passport to the customer’s account, and creating a QR code to be presented by the mobile device as in JANG in the system executing the method of Amtrup, with the motivation of offering to improve the system of electronically presenting passports linked to the customer’s accounts to reduce burden for the tourists and the risk of losing actual passports as taught by JANG over that of Amtrup.
Although Amtrup teaches of receiving and validating the customer’s ID wherein a customer profile is built with the customer identity and the ID image data as disclosed above, the prior art does not seem to explicitly disclose of building a mobile wallet metadata file to utilize the tokenized ID for the mobile wallet of the user’s mobile device. However, Purves teaches:
a metadata file generator to build a metadata file in compliance with a mobile wallet format, the metadata file comprising ([0322] “FIG. 25 shows a block diagram illustrating embodiments of a EWM controller. In this embodiment, the EWM controller 3301 may serve to aggregate, process, store, search, serve, identify, instruct, generate, match, and/or facilitate interactions with a computer through various bi-directional linking technologies, and/or other related data” and also [0324] “In one embodiment, the EWM controller 3301 may be connected to and/or communicate with entities such as, but not limited to: one or more users from user input devices 3311; peripheral devices 3312; an optional cryptographic processor device 3328; and/or a communications network 3313”):
said token embedded within the validated image of the customer's ID to form a tokenized image of said customer's ID (See Figure 1j which shows a list of payment cards (e.g. tokens) associated in the mobile wallet, and Figure 1k which shows an option to add image to be associated with a card, as disclosed [0104] “Referring to FIG. 1k, for example, EWM may allow a user to upload an image 180 to associate with the payment device, and/or may allow the user to obtain an image through like means in order to associate an image with the payment device” wherein the image may be a photo of the user, as disclosed [0184] “In one embodiment of the invention, the card template image retrieved from 2419i may be overlayed with a … photo of the user” and [0185] “By using a cached version of the image, the card image server may advantageously be able to provide individually customized versions of the card images for card image requesters without having to frequently re-generate customized card images (e.g. images containing a logo, or the user's name and/or photo)” and also [0196] “In some embodiments, the card image server may create an "on the fly" image to represent the card and overlay that image with appropriate consumer specific data such as name, photo, and/or the like 2323a”), said tokenized image of said customer's ID useable as a stand-alone tender vehicle at a point-of-purchase, wherein said use of said tokenized image of said customer's ID at said point-of-purchase includes an automatic selection of an appropriate one or more of said customer accounts of said customer data file to use for a purchase ([0104] “Regarding FIG. 1j, in some implementations, the user may also view a list 173 of all the payment devices registered with his electronic wallet account, and may select any of the registered devices in order to view more information 179 about the device (e.g. the payment device number, cardholder name, expiration date, security code, balance, value of all charges to the payment device to date, and/or the like), and/or to edit and/or view other settings associated with the payment device. For example, the user may be able to edit 175 the image representing the payment device 174, may be able to access payment-device-specific settings 176 for the device, may be able to delete 177 the payment device from the wallet, and/or may be able to view and/or edit bonds associated with the payment device 178 (for more detail, see e.g, FIGS. 2b-i)”);
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize linking the customer profile metadata with the image of the customer’s ID in mobile wallet as in Purves in the system executing the method of Amtrup, with the motivation of offering to [0092] “provide a secure and trusted bidirectional federation with a digital wallet by instituting a permissions system that allows services certain access privileges (e.g., read, write, transact, etc.) to the wallet only when appropriate and subject to both systematic and customer-managed controls” as taught by Purves over that of Amtrup.
Although Purves teaches of using mobile wallet for tokens (e.g. payment cards with images) to use for transactions, which includes setting a “default payment card” in the wallet as disclosed [0199] “The user may also be able to specify which card to set as a default card for the wallet”, the prior art does not seem to explicitly disclose of presenting one tokenized image first in a mobile wallet stack. Although it would be obvious to one of ordinary skilled in the art that the “default card” of the mobile wallet would be presented as a first image when a mobile wallet is accessed, Gower teaches:
an instruction to cause said tokenized image of said customer’s ID to be presented first in a mobile wallet stack on a mobile wallet of said customer’s mobile device when said mobile wallet is accessed ([0047] “If multiple payment cards and/or other user tokens, such as event tickets or loyalty cards, are registered with the digital wallet application 130, they are represented in list form, such as that shown in the ‘wallet’ 50 of FIG. 1, with each card being represented by part of an image of that card within a wallet style GUI. One of the registered payment cards or tokens, which has been selected by the user to be the default payment card, is displayed at the top of the list (GUI)”);
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize displaying the default payment card at the top of the mobile wallet list as in Gower in the system executing the method of Purves, wherein Purves already teaches of setting a default payment card in the mobile wallet, with the motivation of offering to provide [0036] “improved graphics for payment card representations in the digital wallet” as taught by Gower over that of Purves.
As per claim 2, Amtrup teaches the system of Claim 1, wherein the image of the customer's ID is received from said customer's mobile device (See Figure 4 – step 404, as disclosed [0122] “The method 400 also includes operation 404, in which an image comprising an ID is received. Again, the image is preferably received at a mobile device, or alternatively is captured using the mobile device”).
As per claim 4, Amtrup teaches the system of Claim 1, wherein the ID type is determined by an identifier from the group consisting of: an image matching software, and an optical character recognition ([0130] “The method 500 also includes operation 504, in which identifying information is determined from one or more of the IDs. The identifying information may be determined using any suitable technique, such as utilizing optical character recognition to recognize textual characters on an ID, facial recognition to recognize a photograph of a human face or portrait, etc. as would be understood by those having ordinary skill in the art upon reading the present descriptions” and see also Figure 6 – step 604 for classifying the ID, as disclosed [0211] “The method 600 also includes operation 604, in which the ID is classified. The classification may take any form such as described herein, but preferably the classifying is based at least in part on comparing feature vector data. The comparison may include comparing feature vector(s) to reference feature vector(s), a reference feature matrix or matrices, and/or by performing any number of pre-comparison analyses, computations, operations, or transformations of the feature vector (e.g. in one approach feature vectors may be subjected to a weighting process, and the resulting products compared rather than comparing the feature vectors per se)”).
As per claim 5, Amtrup teaches the system of Claim 1, wherein the validation engine further comprises: an ID layout database that includes a plurality of valid ID layouts for a plurality of different ID types ([0220] “The identifying information may be determined from the ID(s) directly, e.g. using an OCR operation or the like, using a lookup operation, e.g. as described herein with respect to ID identifiers and the capacity thereof to serve as a "key" to which identifying information may be a value or values in a relational database or other similar data structure, in some approaches” or see also [0248] “In one embodiment, a workflow classifies an ID such as a driver's license. Based on classifying the ID as a driver's license issued by a particular state, downstream operations, e.g. retrieving associated driving records, financial records, criminal records, etc. may be facilitated by reducing the search space within which the workflow must search for the associated records. For example, by determining an ID is a Maryland driver's license, subsequent retrieval records may search a database storing records for only Maryland residents rather than a database storing records for all U.S. residents”).
As per claim 6, Amtrup teaches the system of Claim 1, wherein the validation engine compares one or more ID characteristics from the group consisting of: an image requirement, a layout, a data, an identifying characteristic, a hologram, a color, a valid date, a spacing, an orientation, a decal, a blacklight word, a state specific layout, a front-side and back-side evaluation, a front-side evaluation, and a back-side evaluation (See Figure 6 – step 606, as disclosed [0166] “Authentication data may still further include identifying information, in some approaches. Authentication data may additionally and/or alternatively include one or more unique identifiers. The unique identifier(s) may optionally be depicted on the ID or a portion of the ID, preferably a portion of the ID depicting unique image data, such as a facial photograph, a hologram, a logo, a watermark, a barcode, etc. or any combination thereof”).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Amtrup, in view of Kohli, in view of JANG, in view of Purves in further view of Gower, and in view of Labaton (US 20160241549 A1).
As per claim 7, Amtrup may not explicitly disclose, but Labaton teaches the system of Claim 1, further comprising:
a database that stores a plurality of customer accounts ([0114] “a database where the credit card account numbers associated with the portable device and/or customers are stored”); and
said customer account identifier to:
search the database for one or more customer accounts of the plurality of customer accounts that are held by the identified customer ([0114] “Once the device owner is identified and the transaction data decrypted, the certification service queries a database where the credit card account numbers associated with the portable device and/or customers are stored”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize searching database for credit accounts held by the identified customer as in Labaton in the system executing the method of Amtrup, with the motivation of offering to [0003-0021] improve security over the conventional system and [0026] allow users to perform secure and certified transactions as taught by Labaton over that of Amtrup.
Claims 14-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Amtrup, in view of Kohli, in view of Labaton, in view of JANG, and in view of Purves in further view of Gower.
As per claim 14, Amtrup teaches a system comprising:
a credit provider computer system (See Figure 1), the credit provider computer system comprising:
a database that stores a plurality of customer accounts … ([0130] “In one illustrative scenario, the lookup may utilize the unique ID identifier as a query to a database comprising identifying information values for which the unique string is a key”); and
a processor to:
receive an image of a customer’s identification (ID) via a network connection (See Figure 1, as disclosed [0055] “Turning now to the figures, FIG. 1 illustrates a network architecture 100, in accordance with one embodiment … In the context of the present network architecture 100, the networks 104, 106 may each take any form including, but not limited to a LAN, a WAN such as the Internet, public switched telephone network (PSTN), internal telephone network, etc.” and see Figure 4 – step 404, as disclosed [0122] “The method 400 also includes operation 404, in which an image comprising an ID is received. Again, the image is preferably received at a mobile device, or alternatively is captured using the mobile device, but the image may be received at any number of locations or resources involved in conducting the workflow” or see also Figure 6 – step 602 which teaches [0209] “Referring still to the Figures, FIG. 6 depicts a method 600 generally illustrating the overall inventive process of integrating ID classification techniques and/or mobile implementations thereof into business workflows, according to one embodiment. The method 600 may be practiced in any environment, using any number of suitable resources, such as depicted in FIGS. 1-3, among others”);
determine an ID type for the customer’s ID (See Figure 6 – step 604, as disclosed [0192] “For example, in one approach a multi-level ID classification includes first classifying a document depicted in an image as an ID (e.g. as opposed to other types of document such as a financial document like a check or remittance slip), then classifying the ID as a particular type of ID (e.g. driver's license, credit card, social security card, tax form, passport, military ID, employee ID, insurance card, etc.)” and see also [0194] “In one generic example, a first iteration may classify a document as an ID. A second iteration may classify the ID as a particular type of ID, e.g. a license. A third iteration may classify the license as a particular type of license, e.g. a driver's license or hunting license”);
obtain a valid ID layout for the determined ID type (See Figure 6, as disclosed [0209] “Referring still to the Figures, FIG. 6 depicts a method 600 generally illustrating the overall inventive process of integrating ID classification techniques and/or mobile implementations thereof into business workflows, according to one embodiment. The method 600 may be practiced in any environment, using any number of suitable resources, such as depicted in FIGS. 1-3, among others”);
compare the image of the customer’s ID with the valid ID layout for the determined ID type to validate the image of the customer’s ID (See Figure 6 – step 606, as disclosed [0165] “In various approaches, authentication data may include any data and/or metadata suitable for comparison to the processed image of the ID and/or associated metadata to determine a partial or complete match therebetween. Authentication data may include image(s), such as another image of the ID; another instance of the processed ID image; a portion of the ID image; etc. Authentication data may additionally and/or alternatively include image data descriptive of part or all of the processed ID image, such as the various types of image data utilized in the processing image operation(s) described herein” and see also [0211] “The method 600 also includes operation 604, in which the ID is classified. The classification may take any form such as described herein, but preferably the classifying is based at least in part on comparing feature vector data. The comparison may include comparing feature vector(s) to reference feature vector(s), a reference feature matrix or matrices, and/or by performing any number of pre-comparison analyses, computations, operations, or transformations of the feature vector (e.g. in one approach feature vectors may be subjected to a weighting process, and the resulting products compared rather than comparing the feature vectors per se)”);
identify a customer based on the validated image of the customer's ID (See Figure 5 – steps 502 and 504, as disclosed [0129] “The method 500 includes operation 502, where at least one image of one or more IDs are captured or received using a mobile device” and [0130] “The method 500 also includes operation 504, in which identifying information is determined from one or more of the IDs”);
search the database for one or more customer accounts of the plurality of customer accounts that are held by the identified customer ([0130] “In other embodiments, identifying information may be determined from an ID or IDs using a lookup operation, for example where a unique string suitable for use as an ID identifier (e.g. a driver's license number, social security number, tax ID number, etc.) is determined from the ID (e.g. using OCR, barcode scanning, etc.) and utilized to retrieve additional identifying information that may or may not be depicted on the ID itself. In one illustrative scenario, the lookup may utilize the unique ID identifier as a query to a database comprising identifying information values for which the unique string is a key”);
link the validated image of the customer's ID with the one or more customer accounts held by the identified customer to build a customer data file … (See Figure 5 – step 506, as disclosed [0131] “In operation 506, method 500 includes building an ID profile based in whole or in part on the generated data. The ID profile, as described in further detail with respect to various exemplary embodiments throughout these descriptions, may be built in any suitable form or using any suitable technique, and includes preferably identifying information from one or more IDs, even more preferably at least two of a plurality of IDs from which the data were generated. Even more preferably, the built ID profile comprises identifying information and/or image data from the plural IDs”);
Although Amtrup teaches of receiving and validating the customer’s ID wherein a customer profile is built with the customer identity and the ID image data as disclosed above, the prior art does not seem to explicitly disclose of validating the geographic location of the device. However, Kohli teaches:
automatically validate a geographic location of said customer’s mobile device ([0019] “In some embodiments, authentication data includes one or more of: (1) consumer device attributes such as, for example, … geo-location data (i.e., data from the device of the cardholder, indicating the assessed location of the device, such as GPS location, country, city, etc.)”);
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize validating the GPS location data of the customer’s device for the transaction as in Kohli, wherein the authentication information also includes ID as disclosed [0019] “(2) data from the merchant such as, for example, consumer contact information (personally identifiable information (PII) about the cardholder associated with the payment account that the candidate online payment transaction is for, which will be used to determine the likelihood that the merchant has the correct cardholder, and which may include … authentic issued official ID (e.g., passport, driver's license))”, in the system executing the method of Amtrup, with the motivation of offering to [0001-0003] mitigate risk of fraudulent transactions by improving transaction authentication process to enhance fraud detection as taught by Kohli over that of Amtrup.
Although Amtrup teaches of querying the database which comprises a plurality customer identifying information, the prior art does not seem to explicitly disclose of a database storing a plurality of customer accounts. However, Labaton teaches:
a database that stores a plurality of customer accounts, said customer accounts comprising: credit accounts and reward accounts, and savings vehicles comprising: coupons, offers, and promotions ([0114] “a database where the credit card account numbers associated with the portable device and/or customers are stored”); and
a processor to:
…
search the database for one or more customer accounts of the plurality of customer accounts that are held by the identified customer ([0114] “Once the device owner is identified and the transaction data decrypted, the certification service queries a database where the credit card account numbers associated with the portable device and/or customers are stored”);
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize searching database for credit accounts held by the identified customer as in Labaton in the system executing the method of Amtrup, with the motivation of offering to [0003-0021] improve security over the conventional system and [0026] allow users to perform secure and certified transactions as taught by Labaton over that of Amtrup.
Although Amtrup teaches of receiving and validating the customer’s ID wherein a customer profile is built with the customer identity and the ID image data as disclosed above, the prior art does not seem to explicitly disclose of linking the validated image of the customer’s ID with the customer account which may be a credit account, reward account, or a savings vehicle (e.g. coupon, offer, or promotion), to build and provide a token. However, JANG teaches:
link the validated image of the customer's ID with the one or more customer accounts held by the identified customer to build a customer data file, said customer data file comprising: at least one credit account, at least one reward account, and at least one savings vehicle selected from a group consisting of: a coupon, an offer, and a promotion ([Page 3 Lines 31-34] “In addition, when generating the mobile passport 1, corresponding coupon numbers are issued together and stored in the information. It is a matter of course that the issued coupon number can be used when the passport holder purchases the goods” which is obvious that the coupon number corresponds to a customer’s financial account in order to conduct transactions to purchase goods);
generate a token to identify the customer data file (The QR code is generated as a token for the customer data file, as disclosed [Page 4 Lines 4-9] “The encryption unit 120 includes a character encryption module 121 for encrypting character information, a simple authentication number, and a coupon number in the passport information extracted through the mobile passport information generation unit 110, And an image encryption module (122) for encrypting image information including a photograph of the passport information extracted through the generation unit. The information selected by the combination of the character encryption module and the image encryption module is QR encoded”); and
… the metadata file comprising:
said token embedded within the validated image of the customer's ID and the token to form a tokenized image of said customer's ID, said tokenized image of said customer's ID useable as a stand-alone tender vehicle at a point-of-purchase, wherein said use of said tokenized image of said customer's ID at said point-of-purchase includes an automatic selection of an appropriate one or more of said customer accounts of said customer data file to use for a purchase (See Figure 9, as disclosed [Page 6 Lines 8-22] “An F1 step in which the merchant who wants to authenticate the mobile passport scans the coupon number associated with the mobile passport of the mobile passport holder; A step F2 of comparing the coupon number scanned in step F1 with the coupon number DB of the mobile coupon management issuing unit 112 via network communication; F3 step of confirming that the coupon number is a valid coupon number in step F2 and requesting the mobile passport management server 130 to authenticate the authentication key of the mobile passport linked to the coupon number; … and if it is a valid passport number F5 step of transmitting passport information corresponding to the passport number from the character information DB and the image information DB so as to be exposed on the display screen of the merchant; And a step F6 of confirming the passport information transmitted through the step F5 and comparing the passport photograph on the image information and the real product of the mobile passport holder with the merchant”); and
…
transmit said metadata file to … said customer's mobile device via said network connection (See Figure 1 of the generated QR code (e.g. token) used by the mobile device, as disclosed [Page 3 Lines 26-27] “At this time, the mobile passport 1 can be converted and displayed on a display window of a terminal such as a smart phone, or outputted as a QR code”, which is transmitted to the mobile device after creation, as disclosed [Page 4 Lines 15-16] “Meanwhile, the terminal 140 transmits the encrypted QR code and the image information through the encryption generating unit 120 and is stored through the network”), and
said customer's mobile device comprising:
…
a memory storing instructions; and one or more processors, executing the instructions, to:
receive said metadata file; add said tokenized image of said customer's ID …; open …, wherein said tokenized image of said customer's ID is presented … (See Figure 1 of the generated QR code (e.g. token) used by the mobile device, as disclosed [Page 3 Lines 26-27] “At this time, the mobile passport 1 can be converted and displayed on a display window of a terminal such as a smart phone, or outputted as a QR code”, which is transmitted to the mobile device after creation, as disclosed [Page 4 Lines 15-16] “Meanwhile, the terminal 140 transmits the encrypted QR code and the image information through the encryption generating unit 120 and is stored through the network”); and
use said presented tokenized image of said customer's ID as a stand-alone tender vehicle at a point-of-purchase ([Page 3 Lines 31-34] “In addition, when generating the mobile passport 1, corresponding coupon numbers are issued together and stored in the information. It is a matter of course that the issued coupon number can be used when the passport holder purchases the goods”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize linking the validated passport to the customer’s account, and creating a QR code to be presented by the mobile device as in JANG in the system executing the method of Amtrup, with the motivation of offering to improve the system of electronically presenting passports linked to the customer’s accounts to reduce burden for the tourists and the risk of losing actual passports as taught by JANG over that of Amtrup.
Although Amtrup teaches of receiving and validating the customer’s ID wherein a customer profile is built with the customer identity and the ID image data as disclosed above, the prior art does not seem to explicitly disclose of building a mobile wallet metadata file to utilize the tokenized ID for the mobile wallet of the user’s mobile device. However, Purves teaches:
generate a metadata file formatted for a mobile wallet, the metadata file comprising:
said token embedded within the validated image of the customer's ID to form a tokenized image of said customer's ID (See Figure 1j which shows a list of payment cards (e.g. tokens) associated in the mobile wallet, and Figure 1k which shows an option to add image to be associated with a card, as disclosed [0104] “Referring to FIG. 1k, for example, EWM may allow a user to upload an image 180 to associate with the payment device, and/or may allow the user to obtain an image through like means in order to associate an image with the payment device” wherein the image may be a photo of the user, as disclosed [0184] “In one embodiment of the invention, the card template image retrieved from 2419i may be overlayed with a … photo of the user” and [0185] “By using a cached version of the image, the card image server may advantageously be able to provide individually customized versions of the card images for card image requesters without having to frequently re-generate customized card images (e.g. images containing a logo, or the user's name and/or photo)” and also [0196] “In some embodiments, the card image server may create an "on the fly" image to represent the card and overlay that image with appropriate consumer specific data such as name, photo, and/or the like 2323a”), said tokenized image of said customer's ID useable as a stand-alone tender vehicle at a point-of-purchase, wherein said use of said tokenized image of said customer's ID at said point-of-purchase includes an automatic selection of an appropriate one or more of said customer accounts of said customer data file to use for a purchase ([0104] “Regarding FIG. 1j, in some implementations, the user may also view a list 173 of all the payment devices registered with his electronic wallet account, and may select any of the registered devices in order to view more information 179 about the device (e.g. the payment device number, cardholder name, expiration date, security code, balance, value of all charges to the payment device to date, and/or the like), and/or to edit and/or view other settings associated with the payment device. For example, the user may be able to edit 175 the image representing the payment device 174, may be able to access payment-device-specific settings 176 for the device, may be able to delete 177 the payment device from the wallet, and/or may be able to view and/or edit bonds associated with the payment device 178 (for more detail, see e.g, FIGS. 2b-i)”); and
…
said customer's mobile device comprising:
said mobile wallet; a memory storing instructions; and one or more processors, executing the instructions ([0078] “For example, in some embodiments the virtual wallet may be accessed through a mobile application. In this embodiment, the wallet application on the user's mobile phone …” or see also [0195] “FIG. 23a is an exemplary virtual wallet and card enrollment logic and data flow. In some embodiments, the user accesses a wallet URL using a mobile device 2303” and [0227] “FIGS. 31A-31I show example user interfaces and a logic flow diagram illustrating wallet overlay on mobile devices (e.g., mobile phones, tablets, etc.) in some embodiments of the EWM”), to:
receive said metadata file ([0105] “In some implementations EWM may analyze the image to obtain the necessary information to create a record for the payment device in the user's electronic wallet. In other implementations, the user may also be able to add a payment device and/or other information associated with a payment device via options on a prepaid consumer website which may connect with EWM to provide the user's payment device and/or like user data (e.g. user name, address, and/or the like) to the user's electronic wallet”);
add said tokenized image of said customer's ID to said mobile wallet ([0102] “In some implementations, a user may wish to either add payment devices (e.g. credit cards, debit cards, gift cards, prepaid cards, and/or the like) and/or wallet-enabled devices to the user's electronic wallet for future transactions and/or the like” and also [0105] “In some implementations EWM may analyze the image to obtain the necessary information to create a record for the payment device in the user's electronic wallet. In other implementations, the user may also be able to add a payment device and/or other information associated with a payment device via options on a prepaid consumer website which may connect with EWM to provide the user's payment device and/or like user data (e.g. user name, address, and/or the like) to the user's electronic wallet”);
open said mobile wallet, wherein said tokenized image of said customer’s ID is presented on said … mobile wallet … when said mobile wallet is opened ([0104] “Regarding FIG. 1j, in some implementations, the user may also view a list 173 of all the payment devices registered with his electronic wallet account, and may select any of the registered devices in order to view more information 179 about the device (e.g. the payment device number, cardholder name, expiration date, security code, balance, value of all charges to the payment device to date, and/or the like), and/or to edit and/or view other settings associated with the payment device. For example, the user may be able to edit 175 the image representing the payment device 174, may be able to access payment-device-specific settings 176 for the device, may be able to delete 177 the payment device from the wallet, and/or may be able to view and/or edit bonds associated with the payment device 178 (for more detail, see e.g, FIGS. 2b-i)”);
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize linking the customer profile metadata with the image of the customer’s ID in mobile wallet as in Purves in the system executing the method of Amtrup, with the motivation of offering to [0092] “provide a secure and trusted bidirectional federation with a digital wallet by instituting a permissions system that allows services certain access privileges (e.g., read, write, transact, etc.) to the wallet only when appropriate and subject to both systematic and customer-managed controls” as taught by Purves over that of Amtrup.
Although Purves teaches of using mobile wallet for tokens (e.g. payment cards with images) to use for transactions, which includes setting a “default payment card” in the wallet as disclosed [0199] “The user may also be able to specify which card to set as a default card for the wallet”, the prior art does not seem to explicitly disclose of presenting one tokenized image first in a mobile wallet stack. Although it would be obvious to one of ordinary skilled in the art that the “default card” of the mobile wallet would be presented as a first image when a mobile wallet is accessed, Gower teaches:
an instruction to cause said tokenized image of said customer’s ID to be presented on a tope of a mobile wallet stack in a mobile wallet of said customer’s mobile device when said mobile wallet is opened ([0047] “If multiple payment cards and/or other user tokens, such as event tickets or loyalty cards, are registered with the digital wallet application 130, they are represented in list form, such as that shown in the ‘wallet’ 50 of FIG. 1, with each card being represented by part of an image of that card within a wallet style GUI. One of the registered payment cards or tokens, which has been selected by the user to be the default payment card, is displayed at the top of the list (GUI)”);
…
open said mobile wallet, wherein said tokenized image of said customer’s ID is presented on said top of said mobile wallet stack when said mobile wallet is opened ([0047] “One of the registered payment cards or tokens, which has been selected by the user to be the default payment card, is displayed at the top of the list (GUI)”);
It would have been obvious to one of ordinary skill in the art at the time of the invention to utilize displaying the default payment card at the top of the mobile wallet list as in Gower in the system executing the method of Purves, wherein Purves already teaches of setting a default payment card in the mobile wallet, with the motivation of offering to provide [0036] “improved graphics for payment card representations in the digital wallet” as taught by Gower over that of Purves.
As per claim 15, Amtrup teaches the system of Claim 14, wherein the ID type is determined by an ID determiner from the group consisting of: an image matching software, and an optical character recognition ([0130] “The method 500 also includes operation 504, in which identifying information is determined from one or more of the IDs. The identifying information may be determined using any suitable technique, such as utilizing optical character recognition to recognize textual characters on an ID, facial recognition to recognize a photograph of a human face or portrait, etc. as would be understood by those having ordinary skill in the art upon reading the present descriptions” and see also Figure 6 – step 604 for classifying the ID, as disclosed [0211] “The method 600 also includes operation 604, in which the ID is classified. The classification may take any form such as described herein, but preferably the classifying is based at least in part on comparing feature vector data. The comparison may include comparing feature vector(s) to reference feature vector(s), a reference feature matrix or matrices, and/or by performing any number of pre-comparison analyses, computations, operations, or transformations of the feature vector (e.g. in one approach feature vectors may be subjected to a weighting process, and the resulting products compared rather than comparing the feature vectors per se)”).
As per claim 16, Amtrup teaches the system of Claim 14, wherein said valid ID layout is obtained from an ID layout database that includes a plurality of valid ID layouts for a plurality of different ID types ([0220] “The identifying information may be determined from the ID(s) directly, e.g. using an OCR operation or the like, using a lookup operation, e.g. as described herein with respect to ID identifiers and the capacity thereof to serve as a "key" to which identifying information may be a value or values in a relational database or other similar data structure, in some approaches” or see also [0248] “In one embodiment, a workflow classifies an ID such as a driver's license. Based on classifying the ID as a driver's license issued by a particular state, downstream operations, e.g. retrieving associated driving records, financial records, criminal records, etc. may be facilitated by reducing the search space within which the workflow must search for the associated records. For example, by determining an ID is a Maryland driver's license, subsequent retrieval records may search a database storing records for only Maryland residents rather than a database storing records for all U.S. residents”).
As per claim 17, Amtrup teaches the system of Claim 14, wherein the comparison of the image of the customer’s ID with the valid ID layout compares one or more ID characteristics from the group consisting of: an image requirement, a layout, a data, an identifying characteristic, a hologram, a color, a valid date, a spacing, an orientation, a decal, a blacklight word, a state specific layout, a front-side and back- side evaluation, a front-side evaluation, and a back-side evaluation (See Figure 6 – step 606, as disclosed [0166] “Authentication data may still further include identifying information, in some approaches. Authentication data may additionally and/or alternatively include one or more unique identifiers. The unique identifier(s) may optionally be depicted on the ID or a portion of the ID, preferably a portion of the ID depicting unique image data, such as a facial photograph, a hologram, a logo, a watermark, a barcode, etc. or any combination thereof”).
As per claim 20, Amtrup teaches the system of Claim 14, wherein the customer's mobile device further comprises:
an image capturing device, the image capturing device to capture the image of the customer's ID (See Figure 6 – step 602, as disclosed [0210] “The method 600 includes operation 602, where an image comprising an ID is received or captured, preferably using a mobile device”); and
a mobile network connection to provide the image of the customer's ID to said credit provider computer system (See Figure 6 – step 606, as disclosed [0212] “In operation 606, method 600 includes providing the ID and the ID classification to a workflow, preferably a workflow also instantiated on the mobile device and/or executable at least in part using the mobile device. The ID and ID classification may be provided to the workflow in any suitable manner, e.g. … by communicating with a remote data storage system storing the ID and/or ID classification, via another workflow or another operation within a same workflow, etc. as would be understood by skilled artisans reading these descriptions”).
Response to Arguments
Applicant's arguments, see pages 9 to 18, filed 28-October-2025, with respect to 35 U.S.C. 101 rejection have been fully considered but they are not persuasive.
Applicant contends, see page 15, under Group A Discussion, that the claims in view of the limitation “automatically validate a geographic location of said customer’s mobile device” provide a technological benefit to the electronic payment system that includes reducing fraud/hacking/misuse by implementing a previously nonexistent ID verification procedure into the token building process. Examiner respectfully disagrees. As discussed above under 35 U.S.C. 101 rejection, this step of “validation” is still part of the abstract idea to verify information (i.e. validate location data) in addition to obtaining other information (i.e. receiving customer ID, comparing information, etc.). The claims lack sufficient technical details to provide how these limitations may provide technological steps or technical details on how it is particularly implemented on a computer to improve its system or any of its underlying hardware or components (e.g. how it is performed on the mobile device, how it could improve the mobile device itself, how it could manipulate the mobile device to function in a specific way other than its generic functionality, and/or how it could improve any of the underlying technology), but merely applies the generic computer system to perform its generic functionalities.
Applicant contends, see pages 16 to 18, under Group B Discussion, that the claims include additional elements that amount to significantly more as they modify conventional mobile wallet behavior with respect to the addition of new electronic tender vehicles thereto. Examiner respectfully disagrees. As discussed above under 35 U.S.C. 101 rejection, the additional elements regarding the “mobile wallet”, “metadata file generator”, and “token”, these are mere data being gathered and/or manipulated in view of Specification [0039], and the additional elements of a generic computer system is merely applied to implement the abstract idea. Mere data gathering (e.g. receive customer’s ID, build metadata, store credit accounts, etc.) and mere data manipulations (e.g. generate token to identify customer data file, generate metadata file to meet mobile wallet format, etc.) is adding insignificant extra-solution activity to the judicial exception, which is not indicative of integration into a practical application. Mere “apply it” and/or mere data gathering or data manipulation is not “significantly more”. Therefore, the 35 U.S.C. 101 rejection is maintained.
Applicant’s arguments, see pages 19 to 28, with respect to 35 U.S.C. 103 rejection have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
VAN OS et al. (US 20160358180 A1) discloses [0297] “The visual indication 802 of the default payment account includes: the name of a first financial institution “AA BANK” associated with the default payment account” and [0298] “As illustrated in FIG. 8B, in accordance with a determination that the current location is associated with the first account, the electronic device concurrently displays, on the display, the visual indication 802 of the default payment account (e.g., a visual depiction of a credit card associated with the default payment account) and a visual indication 806 of the first account (e.g., a visual depiction of the private label card or the particular loyalty account associated with the particular payment account). The default payment account and the first account are linked to the electronic device (e.g., stored in an electronic wallet of the device; the electronic device has been provisioned for both accounts) and the default payment account and the first account are different accounts”.
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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HENRY H JUNG whose telephone number is (571)270-5018. The examiner can normally be reached Mon - Fri 9:30 - 5:30.
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, Christine M Tran (Behncke) can be reached at (571) 272-8103. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HENRY H JUNG/ Examiner, Art Unit 3695
/CHRISTINE M Tran/ Supervisory Patent Examiner, Art Unit 3695