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.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/04/2026 has been entered.
Claims 2, 5, 13 and 14 are cancelled.
Response to Arguments
Applicant’s arguments, see page 6, filed 05/04/2026, with respect to claims 1-4, 6-12, 15-18 have been fully considered and are persuasive. The claims rejection under 35 USC § 112(a) of 12/05/2025 has been withdrawn.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-4, 6-12, and 15-18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The term “in a fashion” in claim 1 is a relative term which renders the claim indefinite. The term “in an fashion” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. In the specification, it is not clear that what exactly “fashion” means? The claim is referring to what fashion, what the other fashion is and how claimed fashion of sending a pin or password is different than others?
Claims 3-4, 6-8, 16-18 are rejected, in addition to the rejections mentioned above for the individual claims, also in light of their dependency on claim 1 respectively and for not overcoming the grounds of rejection applied to claim 1.
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 Jenkin et al. (U. S. PGPub. No. 2020/0296061 A1) (hereinafter “Jenkin”), Rackley III et al. (U. S. PGPub. No. 2008/0126145 A1) (hereinafter “Rackley”) and Oberhauser et al. (U. S. PGPub. No. 2019/0222575 A1) (hereinafter “Oberhauser”); and further view of CHILAKA et al. (U. S. PGPub. No. 2021/0117969 A1) (hereinafter “Chilaka”)
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 email address from the first dataset of the user database (Miller: [0126], providing e-mail addresses to initiate and/or facilitate communications by telephone 138, video conference module 139, e-mail 140, or IM 141; and so forth)
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)
Miller does not explicitly teach:
e) sending a message to the user's email address the message including a one- time link to the wallet pass, Wherein the one-time link is configured to be voided after used once to at least not allows access to the wallet pass multiple times,
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 the user to enter the pin or password as a login entry via a software program running on a user’s platform to enable a download of the wallet pass via the one-time link,
wherein the one-time link is hashed,
f) writing the ID to an authentication database
g) downloading the wallet pass into a mobile device
h) transmitting, with the mobile device, the ID of the wallet pass to a secured device
i) With the secured device, forwarding the ID to the authentication database,
j) retrieving authentication information from the authentication database with secured device.
However, in an analogous art, Jenkin teaches:
e) sending a message to the user's email address, the message including a one-time link to the wallet pass (Jenkin: [0031], the visitor invitation management program send an electronic message (e.g., an email) that includes a barcode and/or QR code containing details of a visitor's visit to a secured location. [0064] At 208, the visitor invitation management program 110a, 110b sends the generated visitor badge (=wallet pass) via an electronic message (i.e., a second electronic message). An electronic message (e.g., an email) may be sent to the visitor which may include the badge generated by the visitor invitation management program 110a, 110b. A visitor badge printed by the user and/or an electronic badge accessed by the user's smartphone and/or tablet), Wherein the one-time link is configured to be voided after used once to at least not allows access to the wallet pass multiple times (Jenkin: [0058] A visitor badge contain a barcode and/or a quick response (QR) code which automatically expire when a predefined event date and/or event time expires.)
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 Jenkin’s method of creating visitor badge which contains bar code/QR code which automatically expires when a predetermined event date and/or time expires. The motivation is to improve the technical field of visitor-related systems by automatically extracting information from an electronic message about a visitor's trip to a facility that requires formal access approval (e.g., a secured location), and further, by automatically generating a time-sensitive visitor badge by considering a date, a time, and a location of the visitor's visit (Jenkin: [0020])
However, Miller in view of Jenkin 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 the user to enter the pin or password as a login entry via a software program running on a user’s platform to enable a download of the wallet pass via the one-time link,
wherein the one-time link is hashed,
f) writing the ID to an authentication database
g) downloading the wallet pass into a mobile device
h) transmitting, with the mobile device, the ID of the wallet pass to a secured device
i) With the secured device, forwarding the ID to the authentication database,
j) retrieving authentication information from the authentication database with secured device.
However, in an analogous art, Rackley disclose:
el) sending a pin or password to the user in a fashion that is different from how the one-time link is sent (Rackley: [0278], the MFTS 18 sends an SMS to the phone number specified; this SMS contains a verification code)
e2) querying the user to enter the pin or password as a login entry via a software program running on a user’s platform to enable a download of the wallet pass via the one-time link, (Rackley: [0278],The user is then prompted by the mobile application to enter the verification code to activate the mobile client to conduct transactions. [0279] (b) In accordance with another aspect, the user views the verification code in the SMS and enters the verification code into a browser verification screen at the user site web application 153)
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 Jenkin by applying the well-known technique as disclosed by Rackley of sending SMS which includes a verification code and user enter this verification code into verification screen in order to perform transaction using mobile wallet application . The motivation is conducting financial transactions in a mobile environment using a mobile device such as a mobile telephone (cellphone) (Rackley: [0013])
Miller in view of Jenkin and Rackley does not explicitly disclose:
wherein the one-time link is hashed.
f) writing the ID to an authentication database
g) downloading the wallet pass into a mobile device.
h) transmitting, with the mobile device, the ID of the wallet pass to a secured device.
i) With the secured device, forwarding the ID to the authentication database.
j) retrieving authentication information from the authentication database with secured device.
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 Jenkin and Rackley 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]).
The Miller in view of Jenkin, Rackley and Oberhauser does not explicitly disclose:
f) writing the ID to an authentication database
g) downloading the wallet pass into a mobile device.
h) transmitting, with the mobile device, the ID of the wallet pass to a secured device.
i) With the secured device, forwarding the ID to the authentication database.
j) retrieving authentication information from the authentication database with secured device.
However, in an analogous art, Chilaka teaches:
f) writing the ID to an authentication database (Chilaka: [0102] Customer account identifier 361 accesses database 327 which stores (=write) a plurality of customer credit accounts and utilizes the customer specific information 323 in order to identify any other accounts related to the customer. Database 327 may include store specific data, brand specific data, retailer specific data, a shared database, a conglomerate database, a portion of a larger storage database, and the like. Moreover, database 327 could be a local database, a virtual database, a cloud database, a plurality of databases, or a combination thereof. [0103] In one embodiment, database 327 stores a plurality of customer credit accounts, a plurality of customer reward accounts and/or offers, coupons, and the like),.
g) downloading the wallet pass into a mobile device (Chilaka: [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. [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)
i) With the secured device, forwarding the ID to the authentication database (Chilaka: [0109] Referring now to 415 of FIG. 4, in one embodiment, the store's computing system (e.g., device 185) will provide (=forward)the customer's mobile device ID (=ID) to a verification system such as system 306 to authenticate the customer's mobile device),
j) retrieving authentication information from the authentication database with secured device (Chilaka: [0112] In other words, since the store associate or customer enters the customer contact information into device 185 that will be used by the credit account provider to send a message to the customer's mobile device, and since the customer opens the message and selects the link, which initiates the second verification process; the customer contact information will be validated before the customer receives the access to 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 Jenkin, Chen and Oberhauser by applying the well-known technique as disclosed by Chilaka 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 Jenkin, Rackley 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 Jenkin, Rackley 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 (Jenkin: [0058] A visitor badge contain a barcode and/or a quick response (QR) code which automatically expire when a predefined event date and/or event time expires), 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
wherein step f) includes writing the ID to the authentication database (Chilaka: [0102] Customer account identifier 361 accesses database 327 which stores (=write) a plurality of customer credit accounts and utilizes the customer specific information 323 in order to identify any other accounts related to the customer. Database 327 may include store specific data, brand specific data, retailer specific data, a shared database, a conglomerate database, a portion of a larger storage database, and the like. Moreover, database 327 could be a local database, a virtual database, a cloud database, a plurality of databases, or a combination thereof. [0103] In one embodiment, database 327 stores a plurality of customer credit accounts, a plurality of customer reward accounts and/or offers, coupons, and the like),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),
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 Jenkin, Rackley and Oberhauser by applying the well-known technique as disclosed by Chilaka of retrieving new pass upon added to on the customer’s mobile device, 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 Jenkin, Rackley 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 Jenkin, Rackley 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)
Regarding Claim 8, Miller in view of Jenkin, Rackley 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 Jenkin, Rackley 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 Jenkin, Rackley 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 Jenkin, Rackley 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 (Jenkin: [0031], the visitor invitation management program send an electronic message (e.g., an email) that includes a barcode and/or QR code containing details of a visitor's visit to a secured location) which directly points to at least one of: the wallet pass, a website providing the wallet pass (Jenkin: [0064] At 208, the visitor invitation management program 110a, 110b sends the generated visitor badge (=wallet pass) via an electronic message (i.e., a second electronic message). An electronic message (e.g., an email) may be sent to the visitor which may include the badge generated by the visitor invitation management program 110a, 110b. A visitor badge printed by the user and/or an electronic badge accessed by the user's smartphone and/or tablet),
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 Jenkin’s method of creating visitor badge which contains bar code/QR code which automatically expires when a predetermined event date and/or time expires. The motivation is to improve the technical field of visitor-related systems by automatically extracting information from an electronic message about a visitor's trip to a facility that requires formal access approval (e.g., a secured location), and further, by automatically generating a time-sensitive visitor badge by considering a date, a time, and a location of the visitor's visit (Jenkin: [0020])
Claim(s) 9-12 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 Jenkin et al. (U. S. PGPub. No. 2020/0296061 A1) (hereinafter “Jenkin”).
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 (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; [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.)
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, Wherein the one-time link is configured to be voided after used once to at least not allows access to the wallet pass multiple times.
However, in an analogous art, Jenkin 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 (Jenkin: [0031], the visitor invitation management program send an electronic message (e.g., an email) that includes a barcode and/or QR code containing details of a visitor's visit to a secured location. [0064] At 208, the visitor invitation management program 110a, 110b sends the generated visitor badge (=wallet pass) via an electronic message (i.e., a second electronic message). An electronic message (e.g., an email) may be sent to the visitor which may include the badge generated by the visitor invitation management program 110a, 110b. A visitor badge printed by the user and/or an electronic badge accessed by the user's smartphone and/or tablet), Wherein the one-time link is configured to be voided after used once to at least not allows access to the wallet pass multiple times (Jenkin: [0058] A visitor badge contain a barcode and/or a quick response (QR) code which automatically expire when a predefined event date and/or event time expires.)
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 Jenkin’s method of creating visitor badge which contains bar code/QR code which automatically expires when a predetermined event date and/or time expires. The motivation is to improve the technical field of visitor-related systems by automatically extracting information from an electronic message about a visitor's trip to a facility that requires formal access approval (e.g., a secured location), and further, by automatically generating a time-sensitive visitor badge by considering a date, a time, and a location of the visitor's visit (Jenkin: [0020])
Regarding Claim 10, Miller in view of Jenkin 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 Jenkin 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 Jenkin 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 (Jenkin: [0031], the visitor invitation management program send an electronic message (e.g., an email) that includes a barcode and/or QR code containing details of a visitor's visit to a secured location)
which directly points to at least one of: the wallet pass, a website providing the wallet pass (Jenkin: [0064] At 208, the visitor invitation management program 110a, 110b sends the generated visitor badge (=wallet pass) via an electronic message (i.e., a second electronic message). An electronic message (e.g., an email) may be sent to the visitor which may include the badge generated by the visitor invitation management program 110a, 110b. A visitor badge printed by the user and/or an electronic badge accessed by the user's smartphone and/or tablet),
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 Jenkin’s method of creating visitor badge which contains bar code/QR code which automatically expires when a predetermined event date and/or time expires. The motivation is to improve the technical field of visitor-related systems by automatically extracting information from an electronic message about a visitor's trip to a facility that requires formal access approval (e.g., a secured location), and further, by automatically generating a time-sensitive visitor badge by considering a date, a time, and a location of the visitor's visit (Jenkin: [0020]).
Claim(s) 15 is 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 Jenkin et al. (U. S. PGPub. No. 2020/0296061 A1) (hereinafter “Jenkin”) and CHILAKA et al. (U. S. PGPub. No. 2021/0117969 A1) (hereinafter “Chilaka”)
Regarding Claim 15, Miller in view of Jenkin teaches:
The computer device of claim 9 (see rejection of claim 9 above),
Miller in view of Jenkin does not explicitly disclose:
the mobile device configured to download the wallet pass created by said computer device by using the one-time link and to transmit the ID of the wallet pass to a secured device and the secured device configured to:
(i). receive the ID of the wallet pass from the mobile device
ii. forward the ID to the authentication database, and;
iii. retrieve authentication information from the authentication database.
However, in an analogous art, Chilaka teaches:
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: [0109] Referring now to 415 of FIG. 4, in one embodiment, the store's computing system (e.g., device 185) will provide (=forward) the customer's mobile device ID (=ID) to a verification system such as system 306 to authenticate the customer's mobile device)
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).
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 Jenkin by applying the well-known technique as disclosed by Chilaka 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.
Spodak et al. (U. S. Pat. No. 9,317,018 B2): Universal cards are used in place of all the other traditional cards which a person may want to carry. The universal card can include a short range communications transceiver to communicate with a mobile device. The mobile device can include a user interface and an e-wallet application so that the user can interface with the e-wallet application for programming the universal card via the short range communication link. Once programmed, the universal card emulates a function of a traditional card.
Ellis et al. (U. S. Pat. No. 10, 380,583 B1): A computer-implemented system and method that includes receiving via a messaging hub a code and an identifier for a merchant from a first financial institution, determining, by the messaging hub, a second financial institution based at least partially on the code, sending the code and the merchant identifier to the second financial institution, and receiving from the second financial institution account information to be sent to the first financial institution. The system and method includes sending the account information to the first financial institution to allow the first financial institution to process the payment from an account held by a payor to an account held by the merchant.
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
/ALI S ABYANEH/Primary Examiner, Art Unit 2437
Prosecution Insights