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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 19 November 2024 has been considered by the examiner.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 14-16, 19-22 and 27-28 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Patent Application Publication No. 2019/0253414 by Giobbi.
As to claim 14, Giobbi discloses a method of accessing secure data on a user device, wherein authentication access of the user device is not available, comprising:
receiving a request from a requester to access secure data in the user device (Giobbi: Fig 9; Page 11, Sec 130; “The Reader 108 transmits 904 profile authentication requests to the PDK 102 requesting transmission of one or more stored profiles over the secure channel.”);
receiving an authentication input from a user (Giobbi: Fig 10A; Page 12, Sec 140; “FIG. 10A illustrates a method 1000A for biometric authentication. In biometric authentication, a Reader 108 compares a biometric profile stored in the PDK 102 to the biometric input 122 acquired by the biometric reader 502. Advantageously, the biometric input 122 is not persistently stored by the Reader 108, reducing the risk of theft or fraudulent use. If the Reader 108 determine 1002 that biometric authentication is requested, the Reader 108 scans 1104 the biometric input 122 supplied by the user. In one embodiment, scanning 1004 includes computing a mathematical representation or hash of the biometric input 122 that can be directly compared to the biometric profile”);
authenticating the authentication input from the user using a control token (Giobbi: Fig 10A; Page 12, Sec 140 -141; “[0140] FIG. 10A illustrates a method 1000A for biometric authentication. In biometric authentication, a Reader 108 compares a biometric profile stored in the PDK 102 to the biometric input 122 acquired by the biometric reader 502. Advantageously, the biometric input 122 is not persistently stored by the Reader 108, reducing the risk of theft or fraudulent use. If the Reader 108 determine 1002 that biometric authentication is requested, the Reader 108 scans 1104 the biometric input 122 supplied by the user. In one embodiment, scanning 1004 includes computing a mathematical representation or hash of the biometric input 122 that can be directly compared to the biometric profile.
[0141] In one embodiment, scanning 1004 also includes obtaining a biometric input sample from the biometric input according to the same function used to compute the biometric profile sample stored in the PDK 102. Optionally, the Reader 108 receives 1008 a biometric profile sample from the PDK 102 and determines 1010 if the biometric profile sample matches the biometric input sample. If the biometric profile sample does not match the input sample computed from the scan, the profile is determined to be invalid 1018. If the biometric profile sample matches, the full biometric profile 1012 is received from the PDK 102 to determine 1014 if the full biometric profile 1012 matches the complete biometric input 122. If the profile 1012 matches the scan, the profile 1012 is determined to be valid 1120, otherwise the profile 1012 is invalid 1018. It is noted that in one embodiment, steps 1008 and 1010 are skipped and only a full comparison is performed. In one embodiment, the biometric profile and/or biometric profile sample is encoded and transmitted to the Reader 108 along with an encoding key and/or algorithm. Then, the Reader 108 uses the encoding key and/or algorithm to recover the biometric profile and/or biometric profile sample. In another alternative embodiment, only the encoding key and/or algorithm is transmitted by the PDK 102 and the biometric profile data is recovered from a remote database in an encoded form that can then be decoded using the key and/or algorithm”); and
providing access to the secure data to the requester (Giobbi: Fig 7; Page 11, Sec 129; “The method next determines 710 whether profile authentication is required based on the configuration of the Reader 108, the type of transaction desired or by request of a merchant or other administrator. If the Reader 108 configuration does not require a profile authentication in addition to the PDK authentication, then the Reader 108 proceeds to complete the transaction for the PDK 102. If the Reader 108 does require profile authentication, the profile authentication is performed 712 as will be described below with references to FIGS. 9-10D. If a required profile is determined 714 to be valid, the Reader 108 allows 716 the connection. Otherwise, the Reader 108 indicates that the connection is not authorized 718. In one embodiment, allowing 716 the connection includes enabling access to secure patient records. In another embodiment, allowing 716 the connection includes enabling the automatic logging in and out of software and system applications. Patient or provider name or medical record number (typically stored in a profile memory field 332) can be transmitted by the PDK 102 for identification purposes. In one embodiment, the PDK 102 is configured with multiple purchasing means and a default is configured for different types of transactions. In another embodiment, each insurance card or medical billing information is displayed to the customer by the Reader 108 and the customer is allowed to select which to apply to the office visit”); and
wherein the control token comprises:
a second factor for authenticating the authentication input when the user device is fully operational (Giobbi: Fig 10A; Page 12, Sec 140 -141; “[0140] FIG. 10A illustrates a method 1000A for biometric authentication. In biometric authentication, a Reader 108 compares a biometric profile stored in the PDK 102 to the biometric input 122 acquired by the biometric reader 502. Advantageously, the biometric input 122 is not persistently stored by the Reader 108, reducing the risk of theft or fraudulent use. If the Reader 108 determine 1002 that biometric authentication is requested, the Reader 108 scans 1104 the biometric input 122 supplied by the user. In one embodiment, scanning 1004 includes computing a mathematical representation or hash of the biometric input 122 that can be directly compared to the biometric profile.
[0141] In one embodiment, scanning 1004 also includes obtaining a biometric input sample from the biometric input according to the same function used to compute the biometric profile sample stored in the PDK 102. Optionally, the Reader 108 receives 1008 a biometric profile sample from the PDK 102 and determines 1010 if the biometric profile sample matches the biometric input sample. If the biometric profile sample does not match the input sample computed from the scan, the profile is determined to be invalid 1018. If the biometric profile sample matches, the full biometric profile 1012 is received from the PDK 102 to determine 1014 if the full biometric profile 1012 matches the complete biometric input 122. If the profile 1012 matches the scan, the profile 1012 is determined to be valid 1120, otherwise the profile 1012 is invalid 1018. It is noted that in one embodiment, steps 1008 and 1010 are skipped and only a full comparison is performed. In one embodiment, the biometric profile and/or biometric profile sample is encoded and transmitted to the Reader 108 along with an encoding key and/or algorithm. Then, the Reader 108 uses the encoding key and/or algorithm to recover the biometric profile and/or biometric profile sample. In another alternative embodiment, only the encoding key and/or algorithm is transmitted by the PDK 102 and the biometric profile data is recovered from a remote database in an encoded form that can then be decoded using the key and/or algorithm”);; and
a single factor for authenticating the request when the user device is not fully operational (Giobbi: Fig 10A; Page 12, Sec 140 -141; “[0140] FIG. 10A illustrates a method 1000A for biometric authentication. In biometric authentication, a Reader 108 compares a biometric profile stored in the PDK 102 to the biometric input 122 acquired by the biometric reader 502. Advantageously, the biometric input 122 is not persistently stored by the Reader 108, reducing the risk of theft or fraudulent use. If the Reader 108 determine 1002 that biometric authentication is requested, the Reader 108 scans 1104 the biometric input 122 supplied by the user. In one embodiment, scanning 1004 includes computing a mathematical representation or hash of the biometric input 122 that can be directly compared to the biometric profile.
[0141] In one embodiment, scanning 1004 also includes obtaining a biometric input sample from the biometric input according to the same function used to compute the biometric profile sample stored in the PDK 102. Optionally, the Reader 108 receives 1008 a biometric profile sample from the PDK 102 and determines 1010 if the biometric profile sample matches the biometric input sample. If the biometric profile sample does not match the input sample computed from the scan, the profile is determined to be invalid 1018. If the biometric profile sample matches, the full biometric profile 1012 is received from the PDK 102 to determine 1014 if the full biometric profile 1012 matches the complete biometric input 122. If the profile 1012 matches the scan, the profile 1012 is determined to be valid 1120, otherwise the profile 1012 is invalid 1018. It is noted that in one embodiment, steps 1008 and 1010 are skipped and only a full comparison is performed. In one embodiment, the biometric profile and/or biometric profile sample is encoded and transmitted to the Reader 108 along with an encoding key and/or algorithm. Then, the Reader 108 uses the encoding key and/or algorithm to recover the biometric profile and/or biometric profile sample. In another alternative embodiment, only the encoding key and/or algorithm is transmitted by the PDK 102 and the biometric profile data is recovered from a remote database in an encoded form that can then be decoded using the key and/or algorithm”).
As to claim 21, Giobbi discloses a method of accessing secure data on a user device by a requester device, wherein the user device is in a low power mode, comprising:
sending a request to the user device to access secure data in the user device (Giobbi: Fig 9; Page 11, Sec 130; “The Reader 108 transmits 904 profile authentication requests to the PDK 102 requesting transmission of one or more stored profiles over the secure channel.”);
receiving data from the user device including biometric verification data (Giobbi: Fig 10A; Page 12, Sec 140 -141; “[0140] FIG. 10A illustrates a method 1000A for biometric authentication. In biometric authentication, a Reader 108 compares a biometric profile stored in the PDK 102 to the biometric input 122 acquired by the biometric reader 502. Advantageously, the biometric input 122 is not persistently stored by the Reader 108, reducing the risk of theft or fraudulent use. If the Reader 108 determine 1002 that biometric authentication is requested, the Reader 108 scans 1104 the biometric input 122 supplied by the user. In one embodiment, scanning 1004 includes computing a mathematical representation or hash of the biometric input 122 that can be directly compared to the biometric profile.
[0141] In one embodiment, scanning 1004 also includes obtaining a biometric input sample from the biometric input according to the same function used to compute the biometric profile sample stored in the PDK 102. Optionally, the Reader 108 receives 1008 a biometric profile sample from the PDK 102 and determines 1010 if the biometric profile sample matches the biometric input sample. If the biometric profile sample does not match the input sample computed from the scan, the profile is determined to be invalid 1018. If the biometric profile sample matches, the full biometric profile 1012 is received from the PDK 102 to determine 1014 if the full biometric profile 1012 matches the complete biometric input 122. If the profile 1012 matches the scan, the profile 1012 is determined to be valid 1120, otherwise the profile 1012 is invalid 1018. It is noted that in one embodiment, steps 1008 and 1010 are skipped and only a full comparison is performed. In one embodiment, the biometric profile and/or biometric profile sample is encoded and transmitted to the Reader 108 along with an encoding key and/or algorithm. Then, the Reader 108 uses the encoding key and/or algorithm to recover the biometric profile and/or biometric profile sample. In another alternative embodiment, only the encoding key and/or algorithm is transmitted by the PDK 102 and the biometric profile data is recovered from a remote database in an encoded form that can then be decoded using the key and/or algorithm”);
receiving a biometric input from a verifier device, where a user provides a biometric input to the verifier device (Giobbi: Fig 10A; Page 12, Sec 140 -141; “[0140] FIG. 10A illustrates a method 1000A for biometric authentication. In biometric authentication, a Reader 108 compares a biometric profile stored in the PDK 102 to the biometric input 122 acquired by the biometric reader 502. Advantageously, the biometric input 122 is not persistently stored by the Reader 108, reducing the risk of theft or fraudulent use. If the Reader 108 determine 1002 that biometric authentication is requested, the Reader 108 scans 1104 the biometric input 122 supplied by the user. In one embodiment, scanning 1004 includes computing a mathematical representation or hash of the biometric input 122 that can be directly compared to the biometric profile.
[0141] In one embodiment, scanning 1004 also includes obtaining a biometric input sample from the biometric input according to the same function used to compute the biometric profile sample stored in the PDK 102. Optionally, the Reader 108 receives 1008 a biometric profile sample from the PDK 102 and determines 1010 if the biometric profile sample matches the biometric input sample. If the biometric profile sample does not match the input sample computed from the scan, the profile is determined to be invalid 1018. If the biometric profile sample matches, the full biometric profile 1012 is received from the PDK 102 to determine 1014 if the full biometric profile 1012 matches the complete biometric input 122. If the profile 1012 matches the scan, the profile 1012 is determined to be valid 1120, otherwise the profile 1012 is invalid 1018. It is noted that in one embodiment, steps 1008 and 1010 are skipped and only a full comparison is performed. In one embodiment, the biometric profile and/or biometric profile sample is encoded and transmitted to the Reader 108 along with an encoding key and/or algorithm. Then, the Reader 108 uses the encoding key and/or algorithm to recover the biometric profile and/or biometric profile sample. In another alternative embodiment, only the encoding key and/or algorithm is transmitted by the PDK 102 and the biometric profile data is recovered from a remote database in an encoded form that can then be decoded using the key and/or algorithm”);
comparing the biometric input from the verifier device with the biometric verification data (Giobbi: Fig 10A; Page 12, Sec 140 -141; “[0140] FIG. 10A illustrates a method 1000A for biometric authentication. In biometric authentication, a Reader 108 compares a biometric profile stored in the PDK 102 to the biometric input 122 acquired by the biometric reader 502. Advantageously, the biometric input 122 is not persistently stored by the Reader 108, reducing the risk of theft or fraudulent use. If the Reader 108 determine 1002 that biometric authentication is requested, the Reader 108 scans 1104 the biometric input 122 supplied by the user. In one embodiment, scanning 1004 includes computing a mathematical representation or hash of the biometric input 122 that can be directly compared to the biometric profile.
[0141] In one embodiment, scanning 1004 also includes obtaining a biometric input sample from the biometric input according to the same function used to compute the biometric profile sample stored in the PDK 102. Optionally, the Reader 108 receives 1008 a biometric profile sample from the PDK 102 and determines 1010 if the biometric profile sample matches the biometric input sample. If the biometric profile sample does not match the input sample computed from the scan, the profile is determined to be invalid 1018. If the biometric profile sample matches, the full biometric profile 1012 is received from the PDK 102 to determine 1014 if the full biometric profile 1012 matches the complete biometric input 122. If the profile 1012 matches the scan, the profile 1012 is determined to be valid 1120, otherwise the profile 1012 is invalid 1018. It is noted that in one embodiment, steps 1008 and 1010 are skipped and only a full comparison is performed. In one embodiment, the biometric profile and/or biometric profile sample is encoded and transmitted to the Reader 108 along with an encoding key and/or algorithm. Then, the Reader 108 uses the encoding key and/or algorithm to recover the biometric profile and/or biometric profile sample. In another alternative embodiment, only the encoding key and/or algorithm is transmitted by the PDK 102 and the biometric profile data is recovered from a remote database in an encoded form that can then be decoded using the key and/or algorithm”); and
accessing the secure data of the user when an input from the verifier device matches the biometric verification data (Giobbi: Fig 7; Page 11, Sec 129; “The method next determines 710 whether profile authentication is required based on the configuration of the Reader 108, the type of transaction desired or by request of a merchant or other administrator. If the Reader 108 configuration does not require a profile authentication in addition to the PDK authentication, then the Reader 108 proceeds to complete the transaction for the PDK 102. If the Reader 108 does require profile authentication, the profile authentication is performed 712 as will be described below with references to FIGS. 9-10D. If a required profile is determined 714 to be valid, the Reader 108 allows 716 the connection. Otherwise, the Reader 108 indicates that the connection is not authorized 718. In one embodiment, allowing 716 the connection includes enabling access to secure patient records. In another embodiment, allowing 716 the connection includes enabling the automatic logging in and out of software and system applications. Patient or provider name or medical record number (typically stored in a profile memory field 332) can be transmitted by the PDK 102 for identification purposes. In one embodiment, the PDK 102 is configured with multiple purchasing means and a default is configured for different types of transactions. In another embodiment, each insurance card or medical billing information is displayed to the customer by the Reader 108 and the customer is allowed to select which to apply to the office visit”).
As to claim 27, Giobbi discloses a method of accessing secure data on a user device by a requester device, wherein the user device is in a low power mode, comprising:
receiving a request from the requester device to access secure data in the user device (Giobbi: Fig 9; Page 11, Sec 130; “The Reader 108 transmits 904 profile authentication requests to the PDK 102 requesting transmission of one or more stored profiles over the secure channel.”);
sending data to the requester device including biometric verification data (Giobbi: Fig 10A; Page 12, Sec 140 -141; “[0140] FIG. 10A illustrates a method 1000A for biometric authentication. In biometric authentication, a Reader 108 compares a biometric profile stored in the PDK 102 to the biometric input 122 acquired by the biometric reader 502. Advantageously, the biometric input 122 is not persistently stored by the Reader 108, reducing the risk of theft or fraudulent use. If the Reader 108 determine 1002 that biometric authentication is requested, the Reader 108 scans 1104 the biometric input 122 supplied by the user. In one embodiment, scanning 1004 includes computing a mathematical representation or hash of the biometric input 122 that can be directly compared to the biometric profile.
[0141] In one embodiment, scanning 1004 also includes obtaining a biometric input sample from the biometric input according to the same function used to compute the biometric profile sample stored in the PDK 102. Optionally, the Reader 108 receives 1008 a biometric profile sample from the PDK 102 and determines 1010 if the biometric profile sample matches the biometric input sample. If the biometric profile sample does not match the input sample computed from the scan, the profile is determined to be invalid 1018. If the biometric profile sample matches, the full biometric profile 1012 is received from the PDK 102 to determine 1014 if the full biometric profile 1012 matches the complete biometric input 122. If the profile 1012 matches the scan, the profile 1012 is determined to be valid 1120, otherwise the profile 1012 is invalid 1018. It is noted that in one embodiment, steps 1008 and 1010 are skipped and only a full comparison is performed. In one embodiment, the biometric profile and/or biometric profile sample is encoded and transmitted to the Reader 108 along with an encoding key and/or algorithm. Then, the Reader 108 uses the encoding key and/or algorithm to recover the biometric profile and/or biometric profile sample. In another alternative embodiment, only the encoding key and/or algorithm is transmitted by the PDK 102 and the biometric profile data is recovered from a remote database in an encoded form that can then be decoded using the key and/or algorithm”);
receiving proof of a biometric input from into a verifier device from the requester device, where the user provides a biometric input to the verifier device(Giobbi: Fig 10A; Page 12, Sec 140 -141; “[0140] FIG. 10A illustrates a method 1000A for biometric authentication. In biometric authentication, a Reader 108 compares a biometric profile stored in the PDK 102 to the biometric input 122 acquired by the biometric reader 502. Advantageously, the biometric input 122 is not persistently stored by the Reader 108, reducing the risk of theft or fraudulent use. If the Reader 108 determine 1002 that biometric authentication is requested, the Reader 108 scans 1104 the biometric input 122 supplied by the user. In one embodiment, scanning 1004 includes computing a mathematical representation or hash of the biometric input 122 that can be directly compared to the biometric profile.
[0141] In one embodiment, scanning 1004 also includes obtaining a biometric input sample from the biometric input according to the same function used to compute the biometric profile sample stored in the PDK 102. Optionally, the Reader 108 receives 1008 a biometric profile sample from the PDK 102 and determines 1010 if the biometric profile sample matches the biometric input sample. If the biometric profile sample does not match the input sample computed from the scan, the profile is determined to be invalid 1018. If the biometric profile sample matches, the full biometric profile 1012 is received from the PDK 102 to determine 1014 if the full biometric profile 1012 matches the complete biometric input 122. If the profile 1012 matches the scan, the profile 1012 is determined to be valid 1120, otherwise the profile 1012 is invalid 1018. It is noted that in one embodiment, steps 1008 and 1010 are skipped and only a full comparison is performed. In one embodiment, the biometric profile and/or biometric profile sample is encoded and transmitted to the Reader 108 along with an encoding key and/or algorithm. Then, the Reader 108 uses the encoding key and/or algorithm to recover the biometric profile and/or biometric profile sample. In another alternative embodiment, only the encoding key and/or algorithm is transmitted by the PDK 102 and the biometric profile data is recovered from a remote database in an encoded form that can then be decoded using the key and/or algorithm”);
verifying the proof of a biometric input(Giobbi: Fig 10A; Page 12, Sec 140 -141; “[0140] FIG. 10A illustrates a method 1000A for biometric authentication. In biometric authentication, a Reader 108 compares a biometric profile stored in the PDK 102 to the biometric input 122 acquired by the biometric reader 502. Advantageously, the biometric input 122 is not persistently stored by the Reader 108, reducing the risk of theft or fraudulent use. If the Reader 108 determine 1002 that biometric authentication is requested, the Reader 108 scans 1104 the biometric input 122 supplied by the user. In one embodiment, scanning 1004 includes computing a mathematical representation or hash of the biometric input 122 that can be directly compared to the biometric profile.
[0141] In one embodiment, scanning 1004 also includes obtaining a biometric input sample from the biometric input according to the same function used to compute the biometric profile sample stored in the PDK 102. Optionally, the Reader 108 receives 1008 a biometric profile sample from the PDK 102 and determines 1010 if the biometric profile sample matches the biometric input sample. If the biometric profile sample does not match the input sample computed from the scan, the profile is determined to be invalid 1018. If the biometric profile sample matches, the full biometric profile 1012 is received from the PDK 102 to determine 1014 if the full biometric profile 1012 matches the complete biometric input 122. If the profile 1012 matches the scan, the profile 1012 is determined to be valid 1120, otherwise the profile 1012 is invalid 1018. It is noted that in one embodiment, steps 1008 and 1010 are skipped and only a full comparison is performed. In one embodiment, the biometric profile and/or biometric profile sample is encoded and transmitted to the Reader 108 along with an encoding key and/or algorithm. Then, the Reader 108 uses the encoding key and/or algorithm to recover the biometric profile and/or biometric profile sample. In another alternative embodiment, only the encoding key and/or algorithm is transmitted by the PDK 102 and the biometric profile data is recovered from a remote database in an encoded form that can then be decoded using the key and/or algorithm”); and
sending the secure data of the user to the requester device when the proof of a biometric input is verified (Giobbi: Fig 7; Page 11, Sec 129; “The method next determines 710 whether profile authentication is required based on the configuration of the Reader 108, the type of transaction desired or by request of a merchant or other administrator. If the Reader 108 configuration does not require a profile authentication in addition to the PDK authentication, then the Reader 108 proceeds to complete the transaction for the PDK 102. If the Reader 108 does require profile authentication, the profile authentication is performed 712 as will be described below with references to FIGS. 9-10D. If a required profile is determined 714 to be valid, the Reader 108 allows 716 the connection. Otherwise, the Reader 108 indicates that the connection is not authorized 718. In one embodiment, allowing 716 the connection includes enabling access to secure patient records. In another embodiment, allowing 716 the connection includes enabling the automatic logging in and out of software and system applications. Patient or provider name or medical record number (typically stored in a profile memory field 332) can be transmitted by the PDK 102 for identification purposes. In one embodiment, the PDK 102 is configured with multiple purchasing means and a default is configured for different types of transactions. In another embodiment, each insurance card or medical billing information is displayed to the customer by the Reader 108 and the customer is allowed to select which to apply to the office visit”).
As to claim 15, Giobbi further discloses wherein the authentication input from the user includes a biometric input (Giobbi: Fig 10A; Page 12, Sec 140 -141; “[0140] FIG. 10A illustrates a method 1000A for biometric authentication. In biometric authentication, a Reader 108 compares a biometric profile stored in the PDK 102 to the biometric input 122 acquired by the biometric reader 502. Advantageously, the biometric input 122 is not persistently stored by the Reader 108, reducing the risk of theft or fraudulent use. If the Reader 108 determine 1002 that biometric authentication is requested, the Reader 108 scans 1104 the biometric input 122 supplied by the user. In one embodiment, scanning 1004 includes computing a mathematical representation or hash of the biometric input 122 that can be directly compared to the biometric profile.
[0141] In one embodiment, scanning 1004 also includes obtaining a biometric input sample from the biometric input according to the same function used to compute the biometric profile sample stored in the PDK 102. Optionally, the Reader 108 receives 1008 a biometric profile sample from the PDK 102 and determines 1010 if the biometric profile sample matches the biometric input sample. If the biometric profile sample does not match the input sample computed from the scan, the profile is determined to be invalid 1018. If the biometric profile sample matches, the full biometric profile 1012 is received from the PDK 102 to determine 1014 if the full biometric profile 1012 matches the complete biometric input 122. If the profile 1012 matches the scan, the profile 1012 is determined to be valid 1120, otherwise the profile 1012 is invalid 1018. It is noted that in one embodiment, steps 1008 and 1010 are skipped and only a full comparison is performed. In one embodiment, the biometric profile and/or biometric profile sample is encoded and transmitted to the Reader 108 along with an encoding key and/or algorithm. Then, the Reader 108 uses the encoding key and/or algorithm to recover the biometric profile and/or biometric profile sample. In another alternative embodiment, only the encoding key and/or algorithm is transmitted by the PDK 102 and the biometric profile data is recovered from a remote database in an encoded form that can then be decoded using the key and/or algorithm”).
As to claims 16, 22 and 28, Giobbi further discloses wherein the authentication input from the user also includes a secret user input code (Giobbi: Page 17, Sec 180; “In one embodiment, the accessed application 630 of the computing device 120 communicates the data retrieved from the PDK 102 to the application server 240, which communicates login credentials associated with the application 630 to the computing device 120. The computing device 120 uses the login credential information access the application 630. For example, the application 630 communicates a PDK ID, a record identifier and a key retrieved form the PDK 102 to the application server 240, which identifies a login and password from the PDK ID, the record identifier and the key. The login and password are communicated from the application server 240 to the computing device 120, which uses the login and password to launch the application 630. In another embodiment, the application 630 of the computing device 120 retrieves the login credential information associated with the data retrieved form the PDK 102 from the credentials database 320 to allow 1814 access to one or more applications. Allowing 1814 access to one or more applications is further described below in conjunction with FIG. 19.”).
As to claim 19, Giobbi further discloses wherein providing access to secure data to the requester includes securely sending the requested secure data to the requester Giobbi: Fig 7; Page 11, Sec 129; “The method next determines 710 whether profile authentication is required based on the configuration of the Reader 108, the type of transaction desired or by request of a merchant or other administrator. If the Reader 108 configuration does not require a profile authentication in addition to the PDK authentication, then the Reader 108 proceeds to complete the transaction for the PDK 102. If the Reader 108 does require profile authentication, the profile authentication is performed 712 as will be described below with references to FIGS. 9-10D. If a required profile is determined 714 to be valid, the Reader 108 allows 716 the connection. Otherwise, the Reader 108 indicates that the connection is not authorized 718. In one embodiment, allowing 716 the connection includes enabling access to secure patient records. In another embodiment, allowing 716 the connection includes enabling the automatic logging in and out of software and system applications. Patient or provider name or medical record number (typically stored in a profile memory field 332) can be transmitted by the PDK 102 for identification purposes. In one embodiment, the PDK 102 is configured with multiple purchasing means and a default is configured for different types of transactions. In another embodiment, each insurance card or medical billing information is displayed to the customer by the Reader 108 and the customer is allowed to select which to apply to the office visit”).
As to claim 20, Giobbi further discloses further comprising: receiving a request from the user to add the control token for each authentication; personalizing the control token; and binding the control token to the user device (Giobbi: Fig 10A; Page 12, Sec 140 -141; “[0140] FIG. 10A illustrates a method 1000A for biometric authentication. In biometric authentication, a Reader 108 compares a biometric profile stored in the PDK 102 to the biometric input 122 acquired by the biometric reader 502. Advantageously, the biometric input 122 is not persistently stored by the Reader 108, reducing the risk of theft or fraudulent use. If the Reader 108 determine 1002 that biometric authentication is requested, the Reader 108 scans 1104 the biometric input 122 supplied by the user. In one embodiment, scanning 1004 includes computing a mathematical representation or hash of the biometric input 122 that can be directly compared to the biometric profile.
[0141] In one embodiment, scanning 1004 also includes obtaining a biometric input sample from the biometric input according to the same function used to compute the biometric profile sample stored in the PDK 102. Optionally, the Reader 108 receives 1008 a biometric profile sample from the PDK 102 and determines 1010 if the biometric profile sample matches the biometric input sample. If the biometric profile sample does not match the input sample computed from the scan, the profile is determined to be invalid 1018. If the biometric profile sample matches, the full biometric profile 1012 is received from the PDK 102 to determine 1014 if the full biometric profile 1012 matches the complete biometric input 122. If the profile 1012 matches the scan, the profile 1012 is determined to be valid 1120, otherwise the profile 1012 is invalid 1018. It is noted that in one embodiment, steps 1008 and 1010 are skipped and only a full comparison is performed. In one embodiment, the biometric profile and/or biometric profile sample is encoded and transmitted to the Reader 108 along with an encoding key and/or algorithm. Then, the Reader 108 uses the encoding key and/or algorithm to recover the biometric profile and/or biometric profile sample. In another alternative embodiment, only the encoding key and/or algorithm is transmitted by the PDK 102 and the biometric profile data is recovered from a remote database in an encoded form that can then be decoded using the key and/or algorithm”); and
accessing the secure data of the user when an input from the verifier device matches the biometric verification data (Giobbi: Fig 7; Page 11, Sec 129; “The method next determines 710 whether profile authentication is required based on the configuration of the Reader 108, the type of transaction desired or by request of a merchant or other administrator. If the Reader 108 configuration does not require a profile authentication in addition to the PDK authentication, then the Reader 108 proceeds to complete the transaction for the PDK 102. If the Reader 108 does require profile authentication, the profile authentication is performed 712 as will be described below with references to FIGS. 9-10D. If a required profile is determined 714 to be valid, the Reader 108 allows 716 the connection. Otherwise, the Reader 108 indicates that the connection is not authorized 718. In one embodiment, allowing 716 the connection includes enabling access to secure patient records. In another embodiment, allowing 716 the connection includes enabling the automatic logging in and out of software and system applications. Patient or provider name or medical record number (typically stored in a profile memory field 332) can be transmitted by the PDK 102 for identification purposes. In one embodiment, the PDK 102 is configured with multiple purchasing means and a default is configured for different types of transactions. In another embodiment, each insurance card or medical billing information is displayed to the customer by the Reader 108 and the customer is allowed to select which to apply to the office visit”).
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.
Claims 17-18, 23-24 and 29-30 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 2019/0253414 by Giobbi in view of U.S. Patent Application Publication No. 2020/0000345 by Connor.
As to claims 17, 23 and 29, Giobbi discloses all recited elements of claims 14, 21 and 27 from which claims 17, 23 and 29 depend.
Giobbi does not expressly disclose wherein authenticating the authentication input from the user using the control token uses near field communication.
Connor discloses wherein authenticating the authentication input from the user using the control token uses near field communication (Connor: Pages 10-11, Sec 79; “ In an example, a device comprising a wearable ring of biometric sensors can further comprise one or more additional components selected from the group consisting of: accelerometer, ambient light sensor, camera, display LED array, display screen, electromagnetic energy sensor, gyroscope, humidity sensor, impedance sensor, microphone, motion sensor, power source, power transducer, pressure sensor, proximity sensor, touch screen, and wireless data transmitter (e.g. via Bluetooth, Bluetooth low energy (BLE), near-field communication (NFC), wireless local area network (WLAN), ZigBee, SkuBeeDu, VELMA, infrared data association (IrDA), Wi-Fi Direct (WFD), ultra wideband (UWB), Ant+, or Wi-Fi). In an example, the locations of light emitters and light receivers in the ring can be automatically adjusted based on data from one or more of these additional components. In an example, the orientations of light emitters and light receivers in the ring can be automatically adjusted based on data from one or more of these additional components. In an example, the time of activation of light emitters and light receivers in the ring can be automatically adjusted based on data from one or more of these additional components.”).
Giobbi and Conner are analogous art because they are from the common area of biometric authencation.
It would have been obvious to one of ordinary skill in the art, at or before t eh effective filing date of the instant application, to use the wireless communicati8on of Connor in the system of Giobbi. The rationale would have been to communicate t he biometric data (Connor: Pages 10-11, Sec 79).
As to claims 18, 24 and 30, the modified Giobbi/Connor reference further discloses wherein authenticating the authentication input from the user using the control token uses one of ultra-wideband communication, Bluetooth communication, and near field magnetic induction communication (Connor: Pages 10-11, Sec 79; “ In an example, a device comprising a wearable ring of biometric sensors can further comprise one or more additional components selected from the group consisting of: accelerometer, ambient light sensor, camera, display LED array, display screen, electromagnetic energy sensor, gyroscope, humidity sensor, impedance sensor, microphone, motion sensor, power source, power transducer, pressure sensor, proximity sensor, touch screen, and wireless data transmitter (e.g. via Bluetooth, Bluetooth low energy (BLE), near-field communication (NFC), wireless local area network (WLAN), ZigBee, SkuBeeDu, VELMA, infrared data association (IrDA), Wi-Fi Direct (WFD), ultra wideband (UWB), Ant+, or Wi-Fi). In an example, the locations of light emitters and light receivers in the ring can be automatically adjusted based on data from one or more of these additional components. In an example, the orientations of light emitters and light receivers in the ring can be automatically adjusted based on data from one or more of these additional components. In an example, the time of activation of light emitters and light receivers in the ring can be automatically adjusted based on data from one or more of these additional components.”).
Claims 25-26 and 31 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 2019/0253414 by Giobbi in view of U.S. Patent Application Publication No. 2020/0027091 by Hassani et al.
As to claim 25, Giobbi discloses all recited elements of claim 21 from which claim 25 depends.
Giobbi does not expressly disclose wherein receiving data from the user device accessing the secure data includes: receiving data from the user device includes receiving encrypted secure data from the user device; and accessing the secure data includes decrypting the encrypted secure data when an input from the verifier device matches the biometric verification data.
Hassani discloses wherein receiving data from the user device accessing the secure data includes: receiving data from the user device includes receiving encrypted secure data from the user device; and accessing the secure data includes decrypting the encrypted secure data when an input from the verifier device matches the biometric verification data (Hassani: Page 6, Sec 50-51; “[0050] The autonomous vehicle and/or biometric reader may analyze the scanned data into the model feature inputs needed. Standard facial features may include detecting edges to associate the shape of a face, tracking facial proportions (e.g., relative distance between eyes and length of nose, etc.), blood vessel patterns detected by infrared, and/or changes in 3D depth detected by bi-focal lenses or ultrasonic sensors (e.g., how relative ratio of how far cheeks protrude vs eye recession, etc.). These extracted features may be encrypted and sent as an authentication challenge to the first cloud-based server (e.g., biometric server). [0051] The first cloud-based server may compare the received encrypted features against one or more template repositories. If no match is found, the first cloud-based server may communicate to the vehicle to request a new biometric scan. In some instances, the autonomous vehicle 120 and/or user device may include an indicator to provide feedback, such as flashing a red LED. This process could be repeated iteratively until (i) the rider is authenticated, (ii) a finite waiting period (to accommodate current riders in the vehicle), and/or (iii) a finite number of rejections. Decision making logic at the autonomous vehicle 120 may be implemented in instances where no valid rider be found. In instances where the first cloud-based server finds a match, the first cloud-based server may transmit the associated authentication token to the second cloud-based server. The second cloud-based server may retrieve the rider personal information associated with the authentication token. If the authentication token matches the expected rider and/or expected user account, the second cloud-based server may send a rider verification token to the autonomous vehicle to grant access and continue with/initiate a trip. If the authentication token does not match the expected rider and/or user account, the second cloud-based server sends a wrong rider token to the vehicle, informing it is someone else. If desired, the vehicle may send a greeting and/or other information informing the user that they have a different vehicle and where it is, via visual or audio systems of the autonomous vehicle and/or user device”).
As to claim 26, the modified Giobbi/Hassani further discloses further comprising: sending proof to the user device that the user performed a biometric verification; and receiving encrypted secure data from the user device when the user device verifies the proof that the user performed a biometric verification (Hassani: Page 6, Sec 50-51; “[0050] The autonomous vehicle and/or biometric reader may analyze the scanned data into the model feature inputs needed. Standard facial features may include detecting edges to associate the shape of a face, tracking facial proportions (e.g., relative distance between eyes and length of nose, etc.), blood vessel patterns detected by infrared, and/or changes in 3D depth detected by bi-focal lenses or ultrasonic sensors (e.g., how relative ratio of how far cheeks protrude vs eye recession, etc.). These extracted features may be encrypted and sent as an authentication challenge to the first cloud-based server (e.g., biometric server). [0051] The first cloud-based server may compare the received encrypted features against one or more template repositories. If no match is found, the first cloud-based server may communicate to the vehicle to request a new biometric scan. In some instances, the autonomous vehicle 120 and/or user device may include an indicator to provide feedback, such as flashing a red LED. This process could be repeated iteratively until (i) the rider is authenticated, (ii) a finite waiting period (to accommodate current riders in the vehicle), and/or (iii) a finite number of rejections. Decision making logic at the autonomous vehicle 120 may be implemented in instances where no valid rider be found. In instances where the first cloud-based server finds a match, the first cloud-based server may transmit the associated authentication token to the second cloud-based server. The second cloud-based server may retrieve the rider personal information associated with the authentication token. If the authentication token matches the expected rider and/or expected user account, the second cloud-based server may send a rider verification token to the autonomous vehicle to grant access and continue with/initiate a trip. If the authentication token does not match the expected rider and/or user account, the second cloud-based server sends a wrong rider token to the vehicle, informing it is someone else. If desired, the vehicle may send a greeting and/or other information informing the user that they have a different vehicle and where it is, via visual or audio systems of the autonomous vehicle and/or user device”).
As to claim 31, the modified Giobbi/Hassani further discloses further comprising encrypting the secure data before sending the secure data to the requester device (Hassani: Page 6, Sec 50-51; “[0050] The autonomous vehicle and/or biometric reader may analyze the scanned data into the model feature inputs needed. Standard facial features may include detecting edges to associate the shape of a face, tracking facial proportions (e.g., relative distance between eyes and length of nose, etc.), blood vessel patterns detected by infrared, and/or changes in 3D depth detected by bi-focal lenses or ultrasonic sensors (e.g., how relative ratio of how far cheeks protrude vs eye recession, etc.). These extracted features may be encrypted and sent as an authentication challenge to the first cloud-based server (e.g., biometric server). [0051] The first cloud-based server may compare the received encrypted features against one or more template repositories. If no match is found, the first cloud-based server may communicate to the vehicle to request a new biometric scan. In some instances, the autonomous vehicle 120 and/or user device may include an indicator to provide feedback, such as flashing a red LED. This process could be repeated iteratively until (i) the rider is authenticated, (ii) a finite waiting period (to accommodate current riders in the vehicle), and/or (iii) a finite number of rejections. Decision making logic at the autonomous vehicle 120 may be implemented in instances where no valid rider be found. In instances where the first cloud-based server finds a match, the first cloud-based server may transmit the associated authentication token to the second cloud-based server. The second cloud-based server may retrieve the rider personal information associated with the authentication token. If the authentication token matches the expected rider and/or expected user account, the second cloud-based server may send a rider verification token to the autonomous vehicle to grant access and continue with/initiate a trip. If the authentication token does not match the expected rider and/or user account, the second cloud-based server sends a wrong rider token to the vehicle, informing it is someone else. If desired, the vehicle may send a greeting and/or other information informing the user that they have a different vehicle and where it is, via visual or audio systems of the autonomous vehicle and/or user device”).
Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Patent Application Publication No. 2024/0223555 by Fukishima et al. discloses the use of alternative authentication when primary authentication is unavailable
U.S. Patent Application Publication No. 2025/0170988 by Fukishima et al. discloses he use of alternative authentication when primary authentication is unavailable
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL S MCNALLY whose telephone number is (571)270-1599. The examiner can normally be reached Monday-Friday, 8:30 AM - 5: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, Jeffrey L Nickerson can be reached at (469)295-9235. 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.
MICHAEL S. MCNALLY
Primary Examiner
Art Unit 2432
/Michael S McNally/Primary Examiner, Art Unit 2432