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 . 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.
Claims 5, 13 and 14 are cancelled.
Response to Arguments
Applicant’s arguments, see page 8, filed 11/03/2025, with respect to Claim 1 and 9 have been fully considered and are persuasive. The claim objection of 05/06/2025 has been withdrawn.
Applicant’s arguments, see page 11 , filed 11/03/2025, with respect to Figs. 1-3 have been fully considered and are persuasive. The drawing objection of 05/06/2025 has been withdrawn.
Applicant’s arguments, see page 10, filed 11/03/2025, with respect to Claims 9 and 12 have been fully considered and are persuasive. The rejection under 35 U.S.C. 112(b) of claims 9 and 12 has been withdrawn.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 1-8, 16-18 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites “querying a pin or password…”. The specification fails to description of what is “querying a pin or password…” exactly means. How “querying a pin or password…”step is being performed. There is not written description and support in the specification to understand the process of “querying a pin or password…”.
Dependent claims 2-8, 16-18 fails to cure the deficiencies of their parent claim(s) and, therefore, inherit the rejection. For the examination purpose examiner interpreting as that the user may cut and paste the code(=pin) into a website or application to activate (=download) the digital pass. Please see prior art rejection below.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-4, 6-8, 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Miller et al. (U. S. PGPub. No 2021/0064725 A1 ) (hereinafter “Miller”) in view of CHILAKA et al. (U. S. PGPub. No. 2021/0117969 A1) (hereinafter “Chilaka”); and in further view of Chen et al. (U. S. PGPub. No. 2022/0114655 A1) (hereinafter “Chen”) and Oberhauser et al. (U. S. PGPub. No. 2019/0222575 A1) (hereinafter “Oberhauser”)
Regarding Claim 1, Miller teaches:
a) selecting a first dataset from a user database (Miller: [0029] Database 227 could be a local database, a virtual database, a cloud database, a plurality of databases, or a combination thereof. [0030] In one embodiment, database 227 can also stores a plurality of customer data files (such as credit accounts, reward accounts, and the like) and request receiver 225 could search database 227 for one or more existing data files that are held by the user as identified by the ID information included with the request. If any pre-existing data files are found, the received information would be compared/added/or otherwise tied to the existing customer data file).
b) reading a user's address from the first dataset of the user database (Miller: [0028] upon receiving request 205, request receiver 225 will access (=reading) database 227 to build a user profile and store any received ID information (=the ID information includes a telephone number = User’s address ) in the user profile)
c) generating an ID (Miller: [0031], In one embodiment the image is a computer scannable image that is generated as an identifier (=generating ID) for the customer data file (or to include at least some of the ID information). Although in one embodiment, an image is generated, it should be appreciated that there may be an identification scheme other than an image that is used)
d) creating a wallet pass with the ID in the wallet pass (Miller: [0054] Referring now to 410 of FIG. 4, one embodiment generates the digital pass 13 (=wallet pass), the digital pass 13 including the image 330 and a non-image portion (e.g., preference information 310) that is editable by the user. In one embodiment, the user editable non-image portion is user defined preference information 310 such as sizing, style, brand, manufacturer, etc.), wherein the wallet pass comprises the ID (Miller: [0046] In one embodiment, the ID information includes at least a portion of each mobile device identifier from the group including, but not limited to, a telephone number, a serial number, an IMEI, an ICCID, an MEID, an SEID, a MAC address, an IP address, a UUID, a model number, a product number, a serial number, and the like)
f) writing the ID to an authentication database (Miller: [0047] With reference now to 404 of FIG. 4, one embodiment adds the ID information to a database 227….once any related ID information is found, identified, etc. that information is added to the ID information stored (=writing) in the database 227).
Miller does not explicitly teach:
e) sending a message to the user's address the message including a one- time link to the wallet pass.
However, in an analogous art, Chilaka teaches:
e) sending a message to the user's address the message including a one- time link to the wallet pass (Chilaka: [0113] With reference now to 422 of FIG. 4, one embodiment receives, at a customer's mobile device, a message that includes a link to receive the digital pass at the customer's mobile wallet. The link could be a web URL link or the like. In general, the message could be a text message, an email message, or the like. [0114] At 423 of FIG. 4, one embodiment utilizes the link to receive the digital pass, the link causing the digital pass to be provided to the mobile wallet of the customer's mobile device 110. [0062] In one embodiment, if the digital pass in device 183 expires (=one-time link which include wallet pass), and the device token has expired, a session expiration message displayed with “Retrieve Pass” button is displayed on the approval page (e.g., FIG. 2D) of device 183. In one embodiment, the customer can click the ‘Add to Wallet’ button on the digital pass and the digital pass is displayed on the customer's mobile device 110, the customer can then select an ‘Add’ button and the digital pass will be saved in mobile wallet app).
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Miller’s method of generating image with image identifier based on user’s information by applying Chilaka’s method of sending a message with a link to access digital pass on to customer’s mobile device, in order to install/download or save generated digital pass into customer’s mobile wallet app. The motivation is to detect and deter fraud in the electronic realm (Chilaka: [0003]).
Miller in view of Chilaka does not explicitly disclose:
el) sending a pin or password to the user in a fashion that is different from how the one-time link is sent.
e2) querying a pin or password before enabling a download of the wallet pass via the link, wherein the one-time link is hashed
However, in an analogous art Chen teaches:
el) sending a pin or password to the user in a fashion that is different from how the one-time link is sent (Chen et al. (2022/0114655 A1): [0021], The enrollment codes (=Pin) may be transmitted and received by phone number, by email (e.g., all company-associated email accounts may be permitted to redeem and use the company's pass), by text message, [0037] That email may include an enrollment code (=Pin) that may be used within a transportation requesting application or at a website to access the digital pass),
e2) querying a pin or password before enabling a download of the wallet pass via the link, (Chen: [0038], the user may cut and paste the code(=pin) into a website or application to activate (=download) the digital pass),
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Miller in view of Chilaka by applying the well-known technique as disclosed by Chen of transmitting enrollment code to phone number via text messages in order to activate/access digital transportation pass. The motivation is allowing transportation requestor devices to request transportation via the digital transportation pass within a multi-modal transportation ecosystem (Chen: [abstract]).
Miller in view of Chilaka and Chen does not explicitly disclose:
wherein the one-time link is hashed.
However, in an analogous art Oberhauser teaches:
wherein the one-time link is hashed (Oberhauser: [0083], the PDS may generate an attestation for each attribute (e.g., “belongsTo”) by applying a cryptographic hash function to a value of the attribute (e.g., “https://example.org/entities/corporation-A”) to obtain a cryptographic proof of the attribute value. Any suitable cryptographic hash function may be used, as aspects of the present disclosure are not so limited. Moreover, a cryptographic hash function may be applied in any suitable manner (e.g., with or without a randomly generated salt).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Miller in view of Chilaka and Chen by applying the well-known technique as disclosed by Oberhauser of applying hash values to a value of attribute in order to prevent confidential information leakage and prove authenticity. The motivation is to limit the access to sensitive data and ensure data integrity to a needs to handle the sensitive data (Oberhauser: [0002])
Regarding Claim 2, Miller in view of Chilaka, Chen and Oberhauser teaches:
i) with the secured device, forwarding the ID to the authentication database, and
(Chilaka: [0107] With reference now to FIG. 4, a flowchart 400 of a method for performing a mobile device verification for an electronic application before providing a digital pass to an approved customer, in accordance with an embodiment)
j) retrieving authentication information from the authentication database with the secured device (Chilaka: [0112], the customer contact information will be validated before the customer receives the access to the digital pass).
g) downloading the wallet pass into a mobile device (Chilaka: . [0107] With reference now to FIG. 4, a flowchart 400 of a method for performing a mobile device verification for an electronic application before providing a digital pass (=wallet pass) to an approved customer, in accordance with an embodiment)
h) transmitting, with the mobile device, the ID of the wallet pass to a secured device (Chilaka: [0188] At a POS (=secured device), in one embodiment, the customer would present temporary credit account 600 to the POS (or another checkout system such as an associate's mobile device, etc.) When temporary credit account 600 is presented at checkout it could include the transmission of the token (=transmitting ID) via a near field communication (NFC), a scan of image 630….The token, metadata, barcode, and/or the like (=ID) would be provided (=transmitting) from the POS to the credit account provider which would validate the token and link the purchase to the appropriate customer credit account. The credit account provider would then provide the authorization for the purchase to the POS and the transaction would be completed)
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Miller’s method of generating image with image identifier based on user’s information by applying Chilaka’s method of verification of customer’s mobile device, in order to determine customer’s mobile device and associated customer is valid. The motivation is to detect and deter fraud in the electronic realm (Chilaka: [0003]).
Regarding Claim 3, Miller in view of Chilaka, Chen and Oberhauser teaches:
The method of claim 1 (see rejection of claim 1 above),
wherein step f) includes writing the ID to the first dataset (Miller: [0047] With reference now to 404 of FIG. 4, one embodiment adds the ID information to a database 227….once any related ID information is found, identified, etc. that information is added to the ID information stored (=writing) in the database 227).
Regarding Claim 4, Miller in view of Chilaka, Chen and Oberhauser teaches:
The method of claim 1 (see rejection of claim 1 above),
and wherein the one-time link is configured to stop working once the wallet pass is downloaded one time, or the link is configured to work until the wallet pass reports to a host system PDC of the wallet pass via a phone that the wallet pass is successfully installed (Chilaka: [0061] In one embodiment, if the digital pass in device 183 expires, as long as the device token has not expired, a session expiration message displayed with “Retrieve Pass” button is displayed on the approval page (e.g., FIG. 2D) of device 183. In one embodiment, the customer can click the ‘Retrieve Pass’ button displayed on the approval page (e.g., FIG. 2D) of device 183. The customer will then need to enter correct authentication data and will be able to retrieve a new digital pass as shown in FIG. 6).
wherein step f) includes writing the ID to the authentication database (Miller: [0047] With reference now to 404 of FIG. 4, one embodiment adds the ID information to a database 227….once any related ID information is found, identified, etc. that information is added to the ID information stored (=writing) in the database 227) only after the wallet pass has been downloaded by with the use of the one-time link (Chilaka: [0059] However, if the customers mobile device is authenticated, a verification text 261 (e.g., SMS, email, app message, or the like) is sent to the customer's mobile device 110 as shown in FIG. 2G. In one embodiment, the verification text 261 will include instructions and a link 262 which for adding the digital pass 130 for the new credit account to the mobile wallet 129 of the customer's mobile device 110. In another embodiment, the digital pass 130 can be added to an application or other location on the customer's mobile device 110),
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Miller’s method of generating image with image identifier based on user’s information by applying Chilaka’s method of retrieving new pass upon expiration, in order to ensure ongoing validity and functionality, most current data. The motivation is to detect and deter fraud in the electronic realm (Chilaka: [0003]).
Regarding Claim 6, Miller in view of Chilaka, Chen and Oberhauser teaches:
The method of claim 1 (see rejection of claim 1 above)
wherein the step c) (Miller: [0031], In one embodiment the image is a computer scannable image that is generated as an identifier (=generating ID) for the customer data file (or to include at least some of the ID information). Although in one embodiment, an image is generated, it should be appreciated that there may be an identification scheme other than an image that is used), and/or precedes the step a) (Miller: [0029] Database 227 could be a local database, a virtual database, a cloud database, a plurality of databases, or a combination thereof. [0030] In one embodiment, database 227 can also stores a plurality of customer data files (such as credit accounts, reward accounts, and the like) and request receiver 225 could search database 227 for one or more existing data files that are held by the user as identified by the ID information included with the request. If any pre-existing data files are found, the received information would be compared/added/or otherwise tied to the existing customer data file),
Regarding Claim 7, Miller in view of Chilaka, Chen and Oberhauser teaches:
The method of claim 1 (see rejection of claim 1 above),
(Miller: [0029] Database 227 could be a local database, a virtual database, a cloud database, a plurality of databases, or a combination thereof. [0030] In one embodiment, database 227 can also stores a plurality of customer data files (such as credit accounts, reward accounts, and the like) and request receiver 225 could search (=selecting/lookup) database 227 for one or more existing data files that are held by the user as identified by the ID information included with the request. If any pre-existing data files are found, the received information would be compared/added/or otherwise tied to the existing customer data file), and said generating an ID are caried out (Miller: [0031], In one embodiment the image is a computer scannable image that is generated as an identifier (=generating ID) for the customer data file (or to include at least some of the ID information). Although in one embodiment, an image is generated, it should be appreciated that there may be an identification scheme other than an image that is used) Wherein the step f) is carried out at any time (Miller: [0047] With reference now to 404 of FIG. 4, one embodiment adds the ID information to a database 227….once any related ID information is found, identified, etc. that information is added to the ID information stored (=writing) in the database 227)
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Miller’s method of generating image with image identifier based on user’s information by applying Chilaka’s method of sending a message with a link to access digital pass on to customer’s mobile device, in order to install/download or save generated digital pass into customer’s mobile wallet app. The motivation is to detect and deter fraud in the electronic realm (Chilaka: [0003]).
Regarding Claim 8, Miller in view of Chilaka, Chen and Oberhauser teaches:
The method of claim 1 (see rejection of claim 1 above),
wherein the user's address includes at least one of an E-mail address and a mobile phone number and/or the message includes at least one of an E-Mail, a messenger message, and an SMS (Miller: [0028] upon receiving request 205, request receiver 225 will access (=reading) database 227 to build a user profile and store any received ID information (=the ID information includes a telephone number = User’s address ) in the user profile. [0034], , the digital pass 13 is provided to mobile device 11 from pass generator 245 via a delivery method such as, but not limited to: a text (examiner interpreting that the text will be sent on received ID information (=a telephone number = User’s address), an email)
Regarding Claim 16, Miller in view of Chilaka, Chen and Oberhauser teaches:
The method of claim 1 (see rejection of claim 1 above),
wherein the ID is a UUID or any predefined string or number combination (Miller: [0046] In one embodiment, the ID information includes at least…a UUID, a model number, a product number, a serial number, and the like).
Regarding Claim 17, Miller in view of Chilaka, Chen and Oberhauser teaches:
The method of claim 1 (see rejection of claim 1 above),
wherein the authentication database is part of the user database (Miller: [0029] Database 227 could be a local database, a virtual database, a cloud database, a plurality of databases, or a combination thereof. [0030] In one embodiment, database (=authentication database) can also store a plurality of customer data files (=user database) (such as credit accounts, reward accounts, and the like. [0047], the database is part of a distributed system that includes a plurality of databases in a plurality of different locations).
Regarding Claim 18, Miller in view of Chilaka, Chen and Oberhauser teaches:
The method of claim 1 (see rejection of claim 1 above),
and a website providing a user fillable form configured to generate the wallet pass based on data filled in by a user (Miller: [0079] In one embodiment, upon the completion of any application (or at any point during the filling out of the application) the user would be prompted to securely store the provided information which would then generate the autofill formatted ID information as shown at 502, where it is then stored in their digital wallet as a secure pass to make prefilling this information faster in the future. This secure pass is either the digital pass 13 or a separate pass).
wherein the one-time link is a QR code (Chilaka: [0113] With reference now to 422 of FIG. 4, one embodiment receives, at a customer's mobile device, a message that includes a link to receive the digital pass at the customer's mobile wallet. The link could be a web URL link or the like. In general, the message could be a text message, an email message, or the like. [0114] At 423 of FIG. 4, one embodiment utilizes the link to receive the digital pass, the link causing the digital pass to be provided to the mobile wallet of the customer's mobile device 110. [0062] In one embodiment, if the digital pass in device 183 expires (=one-time link which include wallet pass), and the device token has expired, a session expiration message displayed with “Retrieve Pass” button is displayed on the approval page (e.g., FIG. 2D) of device 183. In one embodiment, the customer can click the ‘Add to Wallet’ button on the digital pass and the digital pass is displayed on the customer's mobile device 110, the customer can then select an ‘Add’ button and the digital pass will be saved in mobile wallet app) which directly points to at least one of: the wallet pass, a website providing the wallet pass (Chilaka: [0059] However, if the customers mobile device is authenticated, a verification text 261 (e.g., SMS, email, app message, or the like) is sent to the customer's mobile device 110 as shown in FIG. 2G. In one embodiment, the verification text 261 will include instructions and a link 262 which for adding the digital pass 130 for the new credit account to the mobile wallet 129 of the customer's mobile device 110. In another embodiment, the digital pass 130 can be added to an application or other location on the customer's mobile device 110. )
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Miller’s method of generating image with image identifier based on user’s information by applying Chilaka’s method of retrieving new pass upon expiration, in order to ensure ongoing validity and functionality, most current data. The motivation is to detect and deter fraud in the electronic realm (Chilaka: [0003]).
Claim(s) 9-12 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Miller et al. (U. S. PGPub. No 2021/0064725 A1 ) (hereinafter “Miller”), and further in view of CHILAKA et al. (U. S. PGPub. No. 2021/0117969 A1) (hereinafter “Chilaka”)
Regarding Claim 9, Miller teaches:
select a first dataset from a user database (Miller: [0029] Database 227 could be a local database, a virtual database, a cloud database, a plurality of databases, or a combination thereof. [0030] In one embodiment, database 227 can also stores a plurality of customer data files (such as credit accounts, reward accounts, and the like) and request receiver 225 could search database 227 for one or more existing data files that are held by the user as identified by the ID information included with the request. If any pre-existing data files are found, the received information would be compared/added/or otherwise tied to the existing customer data file).
read a user's address from the first dataset of the user database (Miller: [0028] upon receiving request 205, request receiver 225 will access (=reading) database 227 to build a user profile and store any received ID information (=the ID information includes a telephone number = User’s address ) in the user profile)
create a wallet pass wherein the wallet pass comprises an ID ([0031], In one embodiment the image is a computer scannable image that is generated as an identifier (=generating ID) for the customer data file (or to include at least some of the ID information). Although in one embodiment, an image is generated, it should be appreciated that there may be an identification scheme other than an image that is used; [0054] Referring now to 410 of FIG. 4, one embodiment generates the digital pass 13 (=wallet pass), the digital pass 13 including the image 330 and a non-image portion (e.g., preference information 310) that is editable by the user. In one embodiment, the user editable non-image portion is user defined preference information 310 such as sizing, style, brand, manufacturer, etc.)
write the ID to an authentication database (Miller: [0047] With reference now to 404 of FIG. 4, one embodiment adds the ID information to a database 227….once any related ID information is found, identified, etc. that information is added to the ID information stored (=writing) in the database 227).
Miller does not explicitly teach:
send an E-mail or an SMS to the user's address, the user's address including at least one of an Email address and a mobile phone number, the E-mail or the SMS including a one-time link to the wallet pass.
However, in an analogous art, Chilaka teaches:
send an E-mail or an SMS to the user's address, the user's address including at least one of an Email address and a mobile phone number, the E-mail or the SMS including a one-time link to the wallet pass (Chilaka: [0113] With reference now to 422 of FIG. 4, one embodiment receives, at a customer's mobile device, a message that includes a link to receive the digital pass at the customer's mobile wallet. The link could be a web URL link or the like. In general, the message could be a text message, an email message, or the like. [0114] At 423 of FIG. 4, one embodiment utilizes the link to receive the digital pass, the link causing the digital pass to be provided to the mobile wallet of the customer's mobile device 110. [0062] In one embodiment, if the digital pass in device 183 expires (=one-time link which include wallet pass), and the device token has expired, a session expiration message displayed with “Retrieve Pass” button is displayed on the approval page (e.g., FIG. 2D) of device 183. In one embodiment, the customer can click the ‘Add to Wallet’ button on the digital pass and the digital pass is displayed on the customer's mobile device 110, the customer can then select an ‘Add’ button and the digital pass will be saved in mobile wallet app).
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Miller’s method of generating image with image identifier based on user’s information by applying Chilaka’s method of sending a message with a link to access digital pass on to customer’s mobile device, in order to install/download or save generated digital pass into customer’s mobile wallet app. The motivation is to detect and deter fraud in the electronic realm (Chilaka: [0003]).
Regarding Claim 10, Miller in view of Chilaka teaches:
The method of claim 9 (see rejection of claim 9 above),
wherein the ID is a UUID or any predefined string or number combination (Miller: [0046] In one embodiment, the ID information includes at least…a UUID, a model number, a product number, a serial number, and the like).
Regarding Claim 11, Miller in view of Chilaka teaches:
The method of claim 9 (see rejection of claim 9 above),
wherein the authentication database is part of the user database (Miller: [0029] Database 227 could be a local database, a virtual database, a cloud database, a plurality of databases, or a combination thereof. [0030] In one embodiment, database (=authentication database) can also store a plurality of customer data files (=user database) (such as credit accounts, reward accounts, and the like. [0047], the database is part of a distributed system that includes a plurality of databases in a plurality of different locations).
Regarding Claim 12, Miller in view of Chilaka teaches:
The method of claim 9 (see rejection of claim 9 above),
and a website providing a user fillable form configured to generate the wallet pass based on data filled in by a user (Miller: [0079] In one embodiment, upon the completion of any application (or at any point during the filling out of the application) the user would be prompted to securely store the provided information which would then generate the autofill formatted ID information as shown at 502, where it is then stored in their digital wallet as a secure pass to make prefilling this information faster in the future. This secure pass is either the digital pass 13 or a separate pass) wherein the one-time link is a QR code (Chilaka: [0113] With reference now to 422 of FIG. 4, one embodiment receives, at a customer's mobile device, a message that includes a link to receive the digital pass at the customer's mobile wallet. The link could be a web URL link or the like. In general, the message could be a text message, an email message, or the like. [0114] At 423 of FIG. 4, one embodiment utilizes the link to receive the digital pass, the link causing the digital pass to be provided to the mobile wallet of the customer's mobile device 110. [0062] In one embodiment, if the digital pass in device 183 expires (=one-time link which include wallet pass), and the device token has expired, a session expiration message displayed with “Retrieve Pass” button is displayed on the approval page (e.g., FIG. 2D) of device 183. In one embodiment, the customer can click the ‘Add to Wallet’ button on the digital pass and the digital pass is displayed on the customer's mobile device 110, the customer can then select an ‘Add’ button and the digital pass will be saved in mobile wallet app).
which directly points to at least one of: the wallet pass, a website providing the wallet pass (Chilaka: [0059] However, if the customers mobile device is authenticated, a verification text 261 (e.g., SMS, email, app message, or the like) is sent to the customer's mobile device 110 as shown in FIG. 2G. In one embodiment, the verification text 261 will include instructions and a link 262 which for adding the digital pass (=wallet pass) 130 for the new credit account to the mobile wallet 129 of the customer's mobile device 110. In another embodiment, the digital pass 130 can be added to an application or other location on the customer's mobile device 110),
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Miller’s method of generating image with image identifier based on user’s information by applying Chilaka’s method of retrieving new pass upon expiration, in order to ensure ongoing validity and functionality, most current data. The motivation is to detect and deter fraud in the electronic realm (Chilaka: [0003]).
Regarding Claim 15, Miller in view of Chilaka teaches:
The computer device of claim 9 (see rejection of claim 9 above),
the mobile device configured to download the wallet pass created by said computer device by using the one-time link (Chilaka: . [0107] With reference now to FIG. 4, a flowchart 400 of a method for performing a mobile device verification for an electronic application before providing a digital pass (=wallet pass) to an approved customer, in accordance with an embodiment) and to transmit the ID of the wallet pass to a secured device (Chilaka: [0188] At a POS (=secured device), in one embodiment, the customer would present temporary credit account 600 to the POS (or another checkout system such as an associate's mobile device, etc.) When temporary credit account 600 is presented at checkout it could include the transmission of the token (=transmitting ID) via a near field communication (NFC), a scan of image 630….The token, metadata, barcode, and/or the like (=ID) would be provided (=transmitting) from the POS to the credit account provider which would validate the token and link the purchase to the appropriate customer credit account. The credit account provider would then provide the authorization for the purchase to the POS and the transaction would be completed)
and the secured device configured to: i. receive the ID of the wallet pass from the mobile device (Chilaka: [0188] At a POS (=secured device), in one embodiment, the customer would present temporary credit account 600 to the POS (or another checkout system such as an associate's mobile device, etc.) When temporary credit account 600 is presented at checkout it could include the transmission of the token (=transmitting ID) via a near field communication (NFC), a scan of image 630….The token, metadata, barcode, and/or the like (=ID) would be provided (=transmitting) from the POS to the credit account provider which would validate the token and link the purchase to the appropriate customer credit account. The credit account provider would then provide the authorization for the purchase to the POS and the transaction would be completed)
ii. forward the ID to the authentication database, and (Chilaka: [0107] With reference now to FIG. 4, a flowchart 400 of a method for performing a mobile device verification for an electronic application before providing a digital pass to an approved customer, in accordance with an embodiment)
iii. retrieve authentication information from the authentication database (Chilaka: [0112], the customer contact information will be validated before the customer receives the access to the digital pass).
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Miller’s method of generating image with image identifier based on user’s information by applying Chilaka’s method of verification of customer’s mobile device, in order to determine customer’s mobile device and associated customer is valid. The motivation is to detect and deter fraud in the electronic realm (Chilaka: [0003]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
Belleville et al. (U. S. Pat. No. 10,628,822 B1): Installing digital wallet assets is disclosed. A distribution channel is received. A notification message indicating that a digital wallet asset is available for installation is generated. The notification message is distributed based at least in part on the distribution channel. A callback is received. The digital wallet asset is provided. The digital wallet asset is constructed based at least in part on an associated digital wallet asset logical instance.
Kurani et al. (U. S. Pat. No. 9,652,770 B1): One embodiment of the present disclosure relates to a computer-implemented method that includes sending, by a mobile wallet server, an identification number that is part of a substitute card number to be used by a mobile device as a mobile wallet, determining an actual card number based on the substitute card number and sending the actual card number and the identification number for processing a payment.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 RUPALI DHAKAD whose telephone number is (571)270-3743. The examiner can normally be reached M-F 8: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, Alexander Lagor can be reached at 5712705143. 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.
/R.D./Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437