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 .
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 22 December 2025 has been entered.
Status of Claims
This Office action is issued in response to Applicant’s submission filed on 22 December 2025.
Claims 1, 6-9, 14, and 17 have been amended.
Claims 4-5 and 10 have been canceled previously.
Claims 1-3, 6-9, 11-20 are pending and have been examined herein.
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 (i.e., changing from AIA to pre-AIA ) 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 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.
Claim(s) 1-3, 6-9, and 11-20 are rejected under 35 U.S.C. 103 as being unpatentable over RULE (US 20200104891 A1 to RULE; J. et al.) in view of NEAFSEY (US 20190059122 A1 NEAFSEY; Jeffrey S. et al.) in view of MORSE (US 20240303640 A1 to MORSE; E. et al.) and in further view of KASHI (US 20200013011 A1 to KASHI; M. et al.).
Regarding claim(s) 1, 9, and 17,
RULE discloses:
A method comprising: receiving, by an access device, interaction data from a resource provider computer operated by a resource provider, the interaction data produced during a network-based interaction between a user device operated by a user and the resource provider computer (RULE: ¶[0239]: In operation, a user may order an item online and may receive an electronic notification when the item has been received and placed within a secure storage.; ¶[0212]: In some examples, a user may order an item on-line and the product may be delivered to a secure location to be picked up by the user; ¶[0010]: a receiving device comprising a processor, and a contactless communication interface configured to generate a near field communication field; a remote authentication server in data communication with the receiving device; and a secure locker in data communication with the receiving device; ¶[0039]: Based on receipt of the requested data from the one or more databases, server 120 may be configured to transmit the received data to client device 110, the received data being responsive to one or more requests.; ¶[0203]: the user may authenticate his or her identity using a contactless card in communication with an application executed on a mobile device. The application may interact directly with an access terminal or may communicate, using a server, with a backend hotel application or database to grant the user access to a room once the user's identity has been establishes as described herein; ¶[0218]: Database 1550 may contain information associated with a user's account including the account used to purchase an item that have been stored in the secure storage 1530.; ¶[0225]: System 1600 may include a contactless card 1610, a secure location 1620 with a secure location card reader 1640, a secure storage 1630, an authentication server 1650 and a database 1660.; ¶[0230] In some embodiments, system 1600 includes an authentication server 1650 in data communication with a database 1660. Database 1660 may contain information associated with a user's account including the account used to purchase an item that has been stored in a secure storage 1630 within the secure location 1620.)
and comprises a first plurality of user-specific data of first different categories, (RULE: ¶[0185]: The user may confirm his or her identi[ty] by providing, e.g., via the transmitting device, a user identification. […]. Examples of user identification information (alone or in a “combination”) include the user's date of birth, home address, work address, phone number, credit card number, bank account number, billing zip code, security number, password, biometric identification information (e.g., facial, retina, or fingerprint scan, voice recognition), personal identification number, identification information related to the transmitting device (e.g., a unique identification number, an algorithmically determined value, a counter value), or a combination thereof. The user identification may be transmitted by the transmitting device),
wherein the first different categories include at least two first categories from among a name, an age, an address, and a phone number and each of the first plurality of user-specific data corresponding to the at least two first categories respectively includes a user feature identifying the user involved in the network-based interaction (RULE: ¶[0212] a user may order an item on-line […] to be picked up by the user; RULE: ¶[0185]: The user may confirm his or her identi[ty] by providing, e.g., via the transmitting device, a user identification. […]. Examples of user identification information (alone or in a “combination”) include the user's date of birth, home address, work address, phone number, credit card number, bank account number, billing zip code, security number, password, biometric identification information (e.g., facial, retina, or fingerprint scan, voice recognition), personal identification number, identification information related to the transmitting device (e.g., a unique identification number, an algorithmically determined value, a counter value), or a combination thereof. The user identification may be transmitted by the transmitting device),
the network-based interaction having been initiated through the user device for obtaining an authorization for the user to gain an access to a resource from the resource provider (RULE: ¶ [0212] a user may order an item on-line and the product may be delivered to a secure location to be picked up by the user. The user may receive a notification informing the user that their package is ready for pick up. At that point the use may travel to the secure storage and tap, swipe, wave or perform any gesture or combination thereof with a contactless card or transmitting device with the communication and encryption capabilities described herein near a receiving device in order to authenticate the user's identity. Upon authenticating the user's identity, the secure storage, such as a locker, may open.; ¶[0218]: Database 1550 may contain information associated with a user's account including the account used to purchase an item that have been stored in the secure storage 1530; ¶[0239]: In operation, a user may order an item online and may receive an electronic notification when the item has been received and placed within a secure storage. […] This disclosed system allows a user to order an item online at a convenient time and also receive automated delivery of the item in a secure manner at a time and location the user chooses; ¶[0204] In some embodiments, when a reservation is made, the hotel may update an internal application, thereby allowing a user to access a room using a contactless card configured to authenticate the user's identity. In some embodiments, the user may use a contactless card to interface directly with a terminal and/or other hotel device to gain access to a room; ¶[0205]: the user may execute an application on a mobile device which is in communication, through a server, with a hotel's internal access and control system. In some embodiments, the user may tap, swipe, wave or perform any gesture or combination thereof a contactless card in response to a prompt from an application on a mobile device in order to open a hotel room door. The user's mobile device, upon confirming the user's identity using the contactless card, may inform the hotel's internal access and control system that the user has been authenticated, thereby causing the hotel's access and control system to unlock or open a particular door.);
subsequently, receiving, by the access device from the user device or another user device operated by a user via near field communication in a contactless interaction (RULE: ¶[0215]: In operation, a user may tap, swipe, wave or perform any gesture or combination thereof with contactless card 1510 near the card reader 1520 to authenticate the user's identity and gain access to the secure storage 1530; ¶[0215]: When the contactless card 1510 enters the contactless communication field created by contactless communication interface 1524 of card reader 1520, the card reader 1520 is configured to request an identification token from the applet 1518 via the contactless communication interface 1524 of the card reader 1520 ;. In response to this request, the applet 1518 may transmit an identification token contained in the memory 1516 of the contactless card 1510, may generate an identification token, and/or may encrypt an identification token using one or more cryptographic algorithms; ¶[0061]: communication [between the one or more transmitting devices 205 and the one or more receiving devices 210 may occur via at least one of NFC, Bluetooth, RFID, Wi-Fi, and/or the like;),
user device data comprising a user credential (RULE: ¶[0215]: When the contactless card 1510 enters the contactless communication field created by contactless communication interface 1524 of card reader 1520, the card reader 1520 is configured to request an identification token from the applet 1518 via the contactless communication interface 1524 of the card reader 1520; In response to this request, the applet 1518 may transmit an identification token contained in the memory 1516 of the contactless card 1510, may generate an identification token, and/or may encrypt an identification token using one or more cryptographic algorithms; ¶[0009]: the secondary device requests an identification certificate from the card via the contactless communication interface; transmitting an identification certificate from the card to the secondary device; ¶[0105]: The memory 535 may be configured to store a customer identifier 550. […]. The customer identifier 550 may comprise a unique alphanumeric identifier assigned to a user of the contactless card 500, and the identifier may distinguish the user of the contactless card from other contactless card users. In some examples, the customer identifier 550 may identify both a customer and an account assigned to that customer and may further identify the contactless card associated with the customer's account.),
a cryptogram encrypting the user credential (RULE: ¶[0215]: In response to this request, the applet 1518 may transmit an identification token contained in the memory 1516 of the contactless card 1510, may generate an identification token, and/or may encrypt an identification token using one or more cryptographic algorithms; ¶[0045]: 0045] At step 104, after communication has been established between client device 110 and contactless card 105, the contactless card 105 generates a message authentication code (MAC) cryptogram; ¶[0048]: In some examples, the transmission of the MAC cryptogram occurs via NFC); ¶[0139]: [0139] During an authentication session, one or more cryptograms may be generated by the one or more applications. For example, the one or more cryptograms may be generated as a 3DES MAC using ISO 9797-1 Algorithm 3 with Method 2 padding via one or more session keys, such as Aut-Session-Key 935. The input data 950 may take the following form: Version (2), pUID (8), pATC (4), Shared Secret (4); ¶[0145]: card's unique ID number (pUID); figure 9 and ¶[0141]: data 950 includes card ID used to produce cryptogram A 955 ),
and supplemental data comprising a second plurality of user-specific data of second different categories (RULE: ¶[0197]: the user's information may be recorded on the transmitting device and/or receiving device. Such information may include, but is not limited to, the user's name, date of birth, home address, work address, phone number, credit card number, bank account number, billing zip code, security number, password, and/or preferences; ¶[0105]:The memory 535 may be configured to store one or more counters 545 and a customer identifier 550; ¶[0178]: this data may include information such as an account number, card identifier, card verification value, or phone number, which may be transmitted from the card to the device. In some examples, one or more portions of the data may be encrypted via the systems and methods disclosed herein; ¶[0178]: this data may include information such as an account number, card identifier, card verification value, or phone number, which may be transmitted from the card to the device. In some examples, one or more portions of the data may be encrypted via the systems and methods disclosed herein.);
wherein the second different categories include at least two second categories that correspond to the at least two first categories and each of the second plurality of user-specific data corresponding to the at least two second categories respectively includes a user feature identifying the user involved in the contactless interaction (RULE ¶[0185]: The user may confirm his or her identi[ty] by providing, e.g., via the transmitting device, a user identification. […]. Examples of user identification information (alone or in a “combination”) include the user's date of birth, home address, work address, phone number, credit card number, bank account number, billing zip code, security number, password, biometric identification information (e.g., facial, retina, or fingerprint scan, voice recognition), personal identification number, identification information related to the transmitting device (e.g., a unique identification number, an algorithmically determined value, a counter value), or a combination thereof. The user identification may be transmitted by the transmitting device; ¶:[0197]:the user's information may be recorded on the transmitting device and/or receiving device; . ¶[0197]: Such information may include, but is not limited to, the user's name, date of birth, home address, work address, phone number, credit card number, bank account number, billing zip code, security number, password, and/or preferences; When prompted to provide such information, the user may tap, swipe, wave or perform any gesture or combination thereof with a contactless card, smartphone, or other transmitting device with the communication and encryption capabilities described herein in order to authenticate his or her identity to the receiving device. This may transfer information from the transmitting device to the receiving device and/or authorize the receiving device to communicate the user's information to the application, thereby reducing or eliminating the need for the user to enter his or her information manually and creating a more secure transmission of data; ¶[0198]: In some examples, an application may record information related to a user's identity authentication behavior. Such information may include, for example, time of authentication, location of authentication, type of transmitting device utilized, the individual transmitting device utilized, type of receiving device utilized, the individual receiving device utilized, and/or information related to the movement or timing of the tap, swipe, wave or perform any gesture or combination thereof utilized for identity authentications.)
[…]
in response to the determining that the cryptogram is valid (RULE: ¶[0002] The present disclosure relates to cryptography, and more particularly, to systems and methods for the cryptographic authentication of contactless cards.; ¶[0215]: may generate an identification token, and/or may encrypt an identification token using one or more cryptographic algorithms; ¶[0218]: the authentication server 1540 may be configured to, upon receipt of the identification message, determine if the contactless card 1510 is associated with an account used to purchase an item contained within the secure storage; ¶[0228]: reader 1640 may be configured to decrypt the encrypted identification token or may be configured to utilize and/or transmit information form the encrypted identification token),
comparing, by the access device, the first plurality of user-specific data included in the interaction data received from the resource provider computer and the second plurality of user-specific data included in the supplemental data (RULE: ¶[0216]: the card reader 1520 may be configured to authenticate the token by generating an identification message based on the identification token and transmitting the identification message to the authentication server; ¶[0218]: the authentication server 1540 may be configured to, upon receipt of the identification message, determine if the contactless card 1510 is associated with an account used to purchase an item contained within the secure storage 153; ¶[0219]: In some embodiments, the determination that contactless card 1510 is associated with the account used to purchase an item contained within the secure storage may also serve as an additional fraud prevention feature),
[…]
determining, by the access device, that the second plurality of user- specific data included in the supplemental data that are received via the contactless interaction with the access device matches the first plurality of user-specific data included in the interaction data that is received is from the resource provider computer for the network-based interaction (RULE discloses at ¶[0218]: Database 1550 may contain information associated with a user's account including the account used to purchase an item that have been stored in the secure storage 1530; ¶[0219]: verifying that the contactless card 1510 used to authenticate the user's identity is associated with the account that was used to purchase an item contained within the secure storage; ¶[0218]: determine if the contactless card 1510 is associated with an account used to purchase an item contained within the secure storage; ¶[0231]: upon receipt of an identification token from contactless card 1610, the secure location card reader 1640 is configured to determine if an item contained in the secure storage 1630 was purchased using the account associated with the contactless card 1610.)
[…]
and providing, by the access device on a display, a message comprising an indication of the authorization for the user involved in the contactless interaction to gain the access to the resource (RULE: ¶[0221]: transmit a pick up message to a user interface 1560 associated with the account used to purchase an item when the item is placed within the secure storage; ¶[0222]: The user interface 1560 may be displayed on a client device, mobile device, or any suitable device capable of receiving an electronic message and displaying information to a user; ¶[0229]: the secure location card reader is configured to transmit an access message to the secure location lock 1624. Upon receipt of the access message, the secure location lock 1624 may allow access to the secure location. ¶[0229]: . In some embodiments, a visual indicator, such as a colored or blinking light, may identity a secure storage 1630 that has received an access message from the secure location card reader 1640 and allowed access to a user.; ¶[0175]: The application then outputs for display the status indicator of the transaction.) .
RULE does not expressly disclose the following limitations, which NEAFSEY however, teaches:
validating, by the access device, the cryptogram by comparing the user credential decrypted from the cryptogram and the user credential separately included in the user device data, and determining that the cryptogram is valid when the user credential decrypted from the cryptogram matches the user credential separately included in the user device data (NEAFSEY: ¶[0036]: at operation 314, the application 106 on the mobile device 102 transmits, beams, and/or pushes, via the transceiver 104, the encrypted payload (session identifier, secure data 103, unique device identifier) along with the unique device identifier (unencrypted) to the reader device 108; ¶[0037]: At operation 316, the reader device 108 receives the data (e.g., the encrypted payload), via transceiver 110, from the mobile device 102. The application 112 may validate that the received data is a well-formed NDEF message. The application 112 may unpack the unique device identifier from the NDEF message. The application 112 on the reader device 108 may decrypt the payload using a symmetric key or a device diversified symmetric key, and/or the unique device identifier; ¶[0038]: The process 300 then proceeds from operation 316 to operation 318. At operation 318, the application 112 on the reader device 108 verifies that the session identifier received from the mobile device 102 matches or corresponds to the session identifier that was sent to the mobile device 102. The application 112 also verifies that copies of the unique device identifier received from the mobile device 102 match or correspond to one another. In some embodiments, the session identifiers correspond to one another if they are identical. In other embodiments, the session identifiers may not be identical, but still correspond to one another such as being sequential numbers or otherwise relate to one another.)
It would have been obvious to one of ordinary skill in the art before the time of filing to modify the system/method of RULE, which discloses systems and methods of authenticating identity to provide access to secure storage in the context of order pick up (RULE [0009]) with the technique of NEAFSEY in order to more securely transfer data during authentication (NEAFSEY ¶[0003]) for many applications including “access control, payment, transit,” and “vending” (NEAFSEY ¶[0050]). .
RULE does not expressly disclose the following limitations, which MORSE however, teaches:
determining, by the access device, a similarity score between the first plurality of user-specific data and the second plurality of user-specific data using the multi-feature comparison result for each category, wherein the similarity score is based on a number of similar user features between the first plurality of user-specific data received in the network-based interaction and the second plurality of user-specific data received in the contactless interaction (MORSE: ¶[0070]: processing the account data of block S140 can include comparing the user information and the request-associated user information. The digital interaction details in this variation can be specified request-associated user information. For example, the details on a financial account to be assessed may specify the legal name and phone number of the recipient or originator bank account. This can be compared with what is stored at the bank account. The resulting comparison, which may be formed as a metric measuring the degree or probability of a match, may be used as a signal into the analysis. This comparison of information may further be extended to comparing interaction details to other account information. This comparison can be used in comparing names, contact information, biographical information, and/or other data of the user to see if there is a strong correspondence; ¶[0079]: comparing user information of the account data to user information of the request can be used in generating a user information confirmation score);
It would have been obvious to one of ordinary skill in the art before the time of filing to modify the system/method of RULE, which discloses systems and methods of authenticating identity to provide access to secure storage in the context of order pick up (RULE [0009]) with the technique of MORSE, teaches controlling access to user account data (MORSE [0020]) and managing authentication and assessing fraud or confidence in a transaction (see MORSE [0028]) in order to simplify integration of functionalities (see MORSE ¶[0023]) and to enable more efficient inspection and analysis of data (MORSE ¶[0030]).
RULE does not expressly disclose the following limitations, which KASHI however, teaches:
and based on the similarity score exceeding a threshold: (KASHI: ¶[0035]: In order to match John Doe with John D., the Levenstein metrics can determine a distance between the number of characters representing each name presents a sufficient similarity to determine the user name is a match.)
It would have been obvious to one of ordinary skill in the art before the time of filing to modify the system/method of RULE, which discloses systems and methods of authenticating identity to provide access to secure storage in the context of order pick up (RULE [0009]) with the technique of KASHI, which also teaches verifying and authenticating a user to enable access to a secure storage space (see KASHI [0045]) in order to increase accuracy and reliability of authentication by reducing false negatives where minor formatting differences or discrepancies exist (“match John Doe with John D”) (KASHI ¶[0035]).
Regarding claim(s) 2,
The combination of RULE, NEAFSEY, MORSE, and KASHI teaches the method of claim 1.
RULE further discloses:
wherein the receiving, by the access device, the user device data comprises receiving, by the access device, the user device data comprising the cryptogram and the supplemental data from the another user device operated by the user (RULE: ¶[0033]: By employing a contactless interface, contactless cards may be provided with a method to interact and communicate between a user's device (such as a mobile phone) and the card itself.; ¶[0053]: FIG. 2 illustrates a data transmission system according to an example embodiment. System 200 may include a transmitting or sending device 205, a receiving or recipient device 210 in communication, for example via network 215, with one or more servers 220. Transmitting or sending device 205 may be the same as, or similar to, client device 110 discussed above with reference to FIG. 1A; ¶[0036]: Client device 110 also may be a mobile device; for example, a mobile device may include an iPhone, iPod, iPad from Apple® or any other mobile device running Apple's iOS® operating system, any device running Microsoft's Windows® Mobile operating system, any device running Google' s Android® operating system, and/or any other smartphone, tablet, or like wearable mobile device.; ¶[0061]: In some examples, one or more transmitting devices 205 and one or more receiving devices 210 may be configured to communicate and transmit and receive data between each other without passing through network 215. For example, communication between the one or more transmitting devices 205 and the one or more receiving devices 210 may occur via at least one of NFC, Bluetooth, RFID, Wi-Fi, and/or the like; ¶[0065]: The transmitting device 205 may then transmit the protected encrypted data, along with the counter value, to the receiving device 210 for processing.).
Regarding claim(s) 3,
The combination of RULE, NEAFSEY, MORSE, and KASHI teaches the method of claim 1.
RULE does not expressly disclose the following limitations, which MORSE however, teaches:
wherein the access device comprises a software development kit (SDK), that performs at least the comparing step (MORSE: [0039]: Collection of the user account credentials can be performed in connection with a particular application or service. An application instance of an application service is described herein as the application context. For example, a software development kit (SDK) or library of the operating platform may be implemented within an application context, and the SDK can be used in rendering a user interface for collection and verification of user account credentials to an external account service; [0041] the authentication module may be a native user interface rendered through an SDK of the operating platform. […] As part of the authentication module, there is preferably a user interface form facilitating collecting account credentials from the authentication module. This may include collecting username and password for a user account on a particular external account service.; [0070]: The digital interaction details in this variation can be specified request-associated user information. For example, the details on a financial account to be assessed may specify the legal name and phone number of the recipient or originator bank account. This can be compared with what is stored at the bank account. The resulting comparison, which may be formed as a metric measuring the degree or probability of a match, may be used as a signal into the analysis. This comparison of information may further be extended to comparing interaction details to other account information. This comparison can be used in comparing names, contact information, biographical information, and/or other data of the user to see if there is a strong correspondence. A low degree of match (e.g., high degree of mismatch) can signal possible issues in the interaction. In some variations, the comparison result may be used in conditionally setting an assessment (e.g., setting classification as an error or an invalid transaction because of mismatch of information). In other variations, the comparison may be used as a feature input into a machine learning model.; [0090] additional authentication/authorization may include supplemental authentication verification as a conditional process for executing the financial transaction.).
It would have been obvious to one of ordinary skill in the art before the time of filing to modify the system/method of RULE, which discloses systems and methods of authenticating identity to provide access to secure storage in the context of order pick up (RULE [0009]) with the technique of MORSE, teaches controlling access to user account data (MORSE [0020]) and managing authentication and assessing fraud or confidence in a transaction (see MORSE [0028]) in order to simplify implementation of verification and comparison functionalities without having to resort to writing custom code for implementation (see MORSE ¶[0041]).
Regarding claim(s) 6,
The combination of RULE, NEAFSEY, MORSE, and KASHI teaches the method of claim 1.
RULE discloses:
determining, by the access device, that the user in the contactless interaction is the same user as the user that interacted with the resource provider computer in the network-based interaction (RULE: ¶[0239]: a user may order an item online and may receive an electronic notification when the item has been received and placed within a secure storage.; ¶[0218]: the authentication server 1540 may be configured to, upon receipt of the identification message, determine if the contactless card 1510 is associated with an account used to purchase an item contained within the secure storage 1530; ¶[0219]: verifying that the contactless card 1510 used to authenticate the user's identity is associated with the account that was used to purchase an item contained within the secure storage),
RULE does not expressly disclose the following limitations, which KASHI however, teaches:
based on the similarity score exceeding the threshold. (KASHI: ¶[0034]: an analysis employing Levenstein distance metrics can determine the similarity of words representing user names; [0035] In an aspect, the Levenstein distance metrics can employ an adaptive threshold to indicate the similarity between characters representing a user name and a user name in a recipient or deliverer data store. For instance, a package label can list “John Doe” as a user name, however, a user name in the recipient data store can present “John D.”. In order to match John Doe with John D., the Levenstein metrics can determine a distance between the number of characters representing each name presents a sufficient similarity to determine the user name is a match.; Furthermore, in an instance Levenstein metrics and adaptive thresholds can be employed to match a business with a user name. For instance, secondary information can be utilized to identify the user name with the proper user.).
It would have been obvious to one of ordinary skill in the art before the time of filing to modify the system/method of RULE, which discloses systems and methods of authenticating identity to provide access to secure storage in the context of order pick up (RULE [0009]) with the technique of KASHI, which also teaches verifying and authenticating a user to enable access to a secure storage space (see KASHI [0045]) in order to increase accuracy and reliability of authentication by reducing false negatives where minor formatting differences or discrepancies exist (“match John Doe with John D”) (KASHI ¶[0035]).
Regarding claim(s) 7,
The combination of RULE, NEAFSEY, MORSE, and KASHI teaches the method of claim 1.
RULE further discloses:
wherein the interaction data comprises a name of the user involved in the network-based interaction, and the supplemental data comprises the name of the user involved in the contactless interaction (RULE: ¶[0197]: user may provide information to an application using a transmitting device and a receiving device in communication with the application. “In such examples, the user's information may be recorded on the transmitting device and[…] receiving device”; “Such information may include […] the user's name”; When prompted to provide such information, the user may tap, swipe, wave or perform any gesture or combination thereof with a contactless card, smartphone, or other transmitting device with the communication and encryption capabilities described herein in order to authenticate his or her identity to the receiving device. This may transfer information from the transmitting device to the receiving device and/or authorize the receiving device to communicate the user's information to the application, thereby reducing or eliminating the need for the user to enter his or her information manually and creating a more secure transmission of data.; ¶[0239]: order an item online; ¶[0219]: verifying that the contactless card is associated with the account that was used to purchase an item) .
Regarding claim(s) 8,
The combination of RULE, NEAFSEY, MORSE, and KASHI teaches the method of claim 1.
RULE further discloses:
wherein the resource provider computer operates a Web site and the interaction data was obtained by the resource provider computer from the user involved in the network-based interaction via the Web site (RULE: ¶[0239]: In operation, a user may order an item online and may receive an electronic notification when the item has been received and placed within a secure storage. […]This disclosed system allows a user to order an item online at a convenient time and also receive automated delivery of the item in a secure manner at a time and location the user chooses.; ¶[0036]: Internet browser; ¶[0163]: a webportal, a web-based app; data may comprise information associated with a merchant, such as merchant type, merchant ID; ¶[0222]: item ordered online; ¶[0239]: user may order an item online; system allows a user to order an item online at a convenient time and also receive automated delivery of the item in a secure manner at a time and location the user chooses.; ¶[0219]: verifying that the contactless card is associated with the account that was used to purchase an item; ¶[0176]: card activation by visiting a website).
Regarding claim(s) 11,
The combination of RULE, NEAFSEY, MORSE, and KASHI teaches the access device of claim 9.
RULE further discloses:
wherein the access device is in the form of a mobile phone (RULE: ¶[0053]: Receiving or recipient device 210 may be the same as, or similar to, client device 110 discussed above with reference to FIG. 1A; ¶[0036]: client device 110, which may be a network-enabled computer. a network-enabled computer may include, but is not limited to a computer device, or communications device including a phone, a handheld PC, a personal digital assistant, or other device. Client device 110 also may be a mobile device; for example, a mobile device may include an iPhone, iPod, iPad from Apple® or any other mobile device running Apple's iOS® operating system, any device running Microsoft's Windows® Mobile operating system, any device running Google' s Android® operating system, and/or any other smartphone, tablet, or like wearable mobile device.).
Regarding claim(s) 12,
The combination of RULE, NEAFSEY, MORSE, and KASHI teaches the limitations of claim 9.
RULE does not expressly disclose the following limitations, which MORSE however, teaches:
wherein the access device further comprises: an application programming interface (API) connecting the access device to the resource provider computer, wherein the interaction data is received from the resource provider computer via the API (MORSE: ¶[0053]: different approaches may be used such as API-based authentication or virtualized application authentication.; ¶[0054]: This may include: for an API authentication process, authenticating through the application programming interface and for a virtualized application authentication process, authenticating through a virtualized application instance using the user account credentials.; ¶[0055]: As one variation, programmatically authenticating as the user account with the external computing system and retrieving account data is performed through an API of the external service. Accordingly in such variations, programmatically authenticating can include authenticating, using the user account credentials, a user account with the external account service and then retrieving the user account data through one or more API requests to the external account service; the operating platform may make a sequence of API requests to collect data such as user information, account balance, transaction history, and the like.; ¶[0036] providing a digital tool for inspecting the predicted assessment of one or more interactions (e.g., wherein an API is provided for delivering interaction assessments).; ¶[0047]: The implementation of virtualized authentication can include generation of instances of software applications that are configured to interface with external systems via public or non-public (e.g., proprietary) application programming interfaces (APIs).; ¶[0023]: The fraud scores may be requested and return through a programmatic interface, preferably in the form of an application programming interface (API). The system and method can be implemented so as to provide a transaction assessment as part of a digital tool. More specifically, the transaction assessment can be a fraud risk check, but may alternatively frame the transaction assessment in alternative forms such as a transaction confidence check or a transaction classification; ¶[0030]: Via the public/non-public APIs user account information may be obtained and processed, such that the data may be normalized and provided to other software systems via a normalized API of the system. Accordingly, the systems of the present disclosure may be significantly more efficient at obtaining user account data and thereby financial data from external systems than previous techniques. Further, the user account data may be normalized and requested and/or provided via a normalized API, enabling more efficient inspection and analysis of such data (originally obtained from multiple external systems) from a single standardized interface in a highly efficient manner.; ¶[0099]-¶[0104]: API Call/request containing access token, account ID, transaction amount, Consumer provided information (e.g.) name ).
It would have been obvious to one of ordinary skill in the art before the time of filing to modify the system/method of RULE, which discloses systems and methods of authenticating identity to provide access to secure storage in the context of order pick up (RULE [0009]) with the technique of MORSE, teaches controlling access to user account data (MORSE [0020]) and managing authentication and assessing fraud or confidence in a transaction (see MORSE [0028]) in order to simplify integration of functionalities (see MORSE ¶[0023]) and to enable more efficient inspection and analysis of data (MORSE ¶[0030]).
Regarding claim(s) 13,
The combination of RULE, NEAFSEY, MORSE, and KASHI teaches the limitations of claim 11.
RULE further teaches
wherein the access device is a mobile phone (RULE: ¶[0053]: Receiving or recipient device 210 may be the same as, or similar to, client device 110 discussed above with reference to FIG. 1A; ¶[0036]: client device 110, which may be a network-enabled computer. a network-enabled computer may include, but is not limited to a computer device, or communications device including a phone, a handheld PC, a personal digital assistant, or other device. Client device 110 also may be a mobile device; for example, a mobile device may include an iPhone, iPod, iPad from Apple® or any other mobile device running Apple's iOS® operating system, any device running Microsoft's Windows® Mobile operating system, any device running Google' s Android® operating system, and/or any other smartphone, tablet, or like wearable mobile device.),
the access device further comprising: a wireless network interface configured to obtain the user device data from the user device by obtaining short-range wireless communication message data (RULE: [0035] System 100 may include one or more contactless cards 105, which are further explained below with reference to FIGS. 5A-5B. In some embodiments, contactless card 105 may be in wireless communication, utilizing NFC in an example, with client device 110.; ¶[0048]: In other examples, this communication may occur via Bluetooth, Wi-Fi, or other means of wireless data communication; ¶[0059]: System 200 may include one or more networks 215. In some examples, network 215 may be one or more of a wireless network, a wired network or any combination of wireless network and wired network, and may be configured to connect one or more transmitting devices 205 and one or more receiving devices 210 to server 220. For example, network 215 may include one or more of a wireless LAN, a Global System for Mobile Communication, a Personal Communication Service, a Personal Area Network, Wireless Application Protocol, D-AMPS, Wi-Fi, Fixed Wireless Data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth, NFC, RFID, Wi-Fi, and/or the like. ¶[0061]: In some examples, one or more transmitting devices 205 and one or more receiving devices 210 may be configured to communicate and transmit and receive data between each other without passing through network 215. For example, communication between the one or more transmitting devices 205 and the one or more receiving devices 210 may occur via at least one of NFC, Bluetooth, RFID, Wi-Fi, and/or the like.).
Regarding claim(s) 14,
The combination of RULE, NEAFSEY, MORSE, and KASHI teaches the limitations of claim 9.
RULE further discloses:
wherein the supplemental data comprises a name of the user involved in the contactless interaction and the interaction data comprises the name of the user involved in the network-based interaction (RULE: ¶[0197]: user may provide information to an application using a transmitting device and a receiving device in communication with the application. “In such examples, the user's information may be recorded on the transmitting device and[…] receiving device”; “Such information may include […] the user's name”; When prompted to provide such information, the user may tap, swipe, wave or perform any gesture or combination thereof with a contactless card, smartphone, or other transmitting device with the communication and encryption capabilities described herein in order to authenticate his or her identity to the receiving device. This may transfer information from the transmitting device to the receiving device and/or authorize the receiving device to communicate the user's information to the application, thereby reducing or eliminating the need for the user to enter his or her information manually and creating a more secure transmission of data.; ¶[0239]: order an item online; ¶[0219]: verifying that the contactless card is associated with the account that was used to purchase an item).
Regarding claim(s) 15,
The combination of RULE, NEAFSEY, MORSE, and KASHI teaches the limitations of claims 9 and 14.
RULE does not expressly disclose the following limitations, which KASHI however, teaches: wherein the name of the user in the supplemental data is different than but is substantially similar to the name in the interaction data and wherein a string of characters corresponding to the name of the user in the supplemental data is different from a string of characters corresponding to the name in the interaction data (KASHI: ¶[0034]: character extraction component 114 can compare one or more user name extracted from the label data to a list of user names using Levenstein metrics. For instance, recipient data associated with packages can be stored in a data store. Furthermore, an analysis employing Levenstein distance metrics can determine the similarity of words representing user names; ¶[0035]: In an aspect, the Levenstein distance metrics can employ an adaptive threshold to indicate the similarity between characters representing a user name and a user name in a recipient or deliverer data store. For instance, a package label can list “John Doe” as a user name, however, a user name in the recipient data store can present “John D.”. In order to match John Doe with John D., the Levenstein metrics can determine a distance between the number of characters representing each name presents a sufficient similarity to determine the user name is a match; KASHI: ¶[0035]: Furthermore, in an instance Levenstein metrics and adaptive thresholds can be employed to match a business with a user name. For instance, secondary information can be utilized to identify the user name with the proper user. If there are three John Doe's in a database, a business name data, for instance, can be utilized (from the label data) to determine (e.g., using character extraction component 114) the respective user is identified in association with the package; ¶[0036]: As such, package analysis device 120 can transmit package image data, recipient name data, tracking number information, optical character recognized data, textual data, user identification data (UUID) and other such package data to support server device 140.)
It would have been obvious to one of ordinary skill in the art before the time of filing to modify the system/method of RULE, which discloses systems and methods of authenticating identity to provide access to secure storage in the context of order pick up (RULE [0009]) with the technique of KASHI, which also teaches verifying and authenticating a user to enable access to a secure storage space (see KASHI [0045]) in order to increase accuracy and reliability of authentication by reducing false negatives where minor formatting differences or discrepancies exist (“match John Doe with John D”) (see KASHI ¶[0035])).
Regarding claim(s) 16,
The combination of RULE, NEAFSEY, MORSE, and KASHI teaches the limitations of claim 9.
RULE further discloses:
a contactless reader that is coupled to the processor, and configured to read data from the user device. (RULE: ¶[0009]: providing a card comprising a contactless communication interface; moving the card within a communication field of a secondary device in data communication with a secure storage, wherein the secondary device requests an identification certificate from the card via the contactless communication interface; transmitting an identification certificate from the card to the secondary device; ¶[0010]: a transmitting device comprising a processor, a memory containing an applet, and a contactless communication interface; a receiving device comprising a processor, and a contactless communication interface configured to generate a near field communication field; a remote authentication server in data communication with the receiving device; and a secure locker in data communication with the receiving device, the receiving device configured to, upon entry of the transmitting device into the near field communication field: request a user identification via the contactless communication interface of the receiving device).
Regarding claim(s) 18,
The combination of RULE, NEAFSEY, MORSE, and KASHI teaches the limitations of claim 17.
RULE further discloses:
wherein the communication device is a laptop computer (RULE: ¶[0102]: The contactless card 500 may also include identification information 515 displayed on the front and/or back of the card, and a contact pad 520. The contact pad 520 may be configured to establish contact with another communication device, such as a user device, smart phone, laptop, desktop, or tablet computer.).
Regarding claim(s) 19,
The combination of RULE, NEAFSEY, MORSE, and KASHI teaches the limitations of claim 17.
RULE further discloses:
wherein the user device is a card (RULE: ¶[0101]: FIG. 5A illustrates one or more contactless cards 500, which may comprise a payment card, such as a credit card, debit card, or gift card, issued by a service provider 505 displayed on the front or back of the card 500. In some examples, the contactless card 500 is not related to a payment card, and may comprise, without limitation, an identification card. In some examples, the payment card may comprise a dual interface contactless payment card. The contactless card 500 may comprise a substrate 510, which may include a single layer or one or more laminated layers composed of plastics, metals, and other materials).
Regarding claim(s) 20,
The combination of RULE, NEAFSEY, MORSE, and KASHI teaches the limitations of claim 17.
RULE further discloses:
wherein the resource is a secure location in the form of a building (RULE: ¶[0226]: The secure location 1620 may be a room, building, compartment, area, or any portion or combination thereof that is able be locked or otherwise secured to prevent unwanted entry; ¶[0201]: the receiving device may be in communication with an automated kiosk which may issue room keys upon receiving the user's authenticated identification without the involvement of a human desk clerk; ¶[0204]: In some embodiments, when a reservation is made, the hotel may update an internal application, thereby allowing a user to access a room using a contactless card configured to authenticate the user's identity. In some embodiments, the user may use a contactless card to interface directly with a terminal and/or other hotel device to gain access to a room; ¶[0208]: In some examples, a user may wish to access a secure physical location, including but not limited to unlocking a locker, opening a locked door, or unlocking a safe; ¶[0227]: In operation, a user may tap, swipe, wave or perform any gesture or combination thereof with contactless card 1610 near the secure location card reader 1640 to authenticate the user's identity and gain access to the secure location 1620.).
Response to Arguments
Applicant’s arguments with respect to the claims 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:
US 20190319808 to FALLAH teaches match scores for names, cryptographic algorithms, and integrated circuit cards in the context of identity attestation.
US 20210289001 A1 to WILSON teaches comparing names before cryptographic authentication of a message - see ¶[0266]
US 10366378 B1 to HAN teaches establishing a communication channel between the POS terminal an RF communication device in proximity to the POS terminal to obtain at least one device characteristic of the communication device, related to the operational or physical features of the communication device; generating a digital fingerprint based in part on the obtained device characteristic and the information related to received payment object; determining whether the digital fingerprint substantially compares to an existing fingerprint in a database and if the existing fingerprint is substantially similar to the digital fingerprint, rejecting the payment transaction through presence of the communication device.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BOLKO HAMERSKI whose telephone number is (571)270-7621. The examiner can normally be reached Monday-Friday 10:00 AM to 6:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, BENNETT SIGMOND can be reached at (303) 297-4411. 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.
BOLKO HAMERSKI
Examiner
Art Unit 3694
/BOLKO M HAMERSKI/Examiner, Art Unit 3694
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694
Prosecution Insights