Detailed Action
This is a Final Office action in response to communications received on 9/17/2025. Claims 1 and 8 were amended. Claims 1-20 are pending and are examined.
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 .
Response to Arguments
Applicant’s amendments, filed 9/17/2025, to claim(s) 1and 8 correcting the claim to recite “the bearer” are sufficient to overcome the rejection to the aforementioned claim(s). Accordingly, the rejection of claim(s) 1-12 under 112, second paragraph, as filed in (6) of the Non-Final Office action filed 5/21/2025 is withdrawn.
Applicant argues on page(s) 8-9 of the Remarks, filed 9/17/2025, the cited prior art fail to teach or suggest “receiving an input from a bearer at the receiving device associated with the token”, "authenticating ... using the receiver authentication data and the input from the bearer related to the token at the receiving device” nor “input from a bearer at the receiving device associated with the token” because “the "token" of Shanmugam is not combined at the issuer, does not include privilege information or the encrypted hash value. Instead, the "token" is created at the receiving device when the user makes an input”. However, Examiner respectfully disagrees. Falk establishes the baseline concept of issuer-created authorization material that is later received at a receiving device in an authentication context. Shanmugam teaches receiving user input at a receiving device and authenticating access to protected resources using token-based authorization mechanisms. The fact that Shanmugam’s token may differ in internal composition or point of creation does not negate its relevance. Shanmugam is relied upon not for the exact cryptographic construction of the token, but for the concept of receiving bearer/user input associated with a token to authenticate access, which is not expressly disclosed in Falk. Applicant has not identified any disclosure in Shanmugam that discourages the use of issuer-generated authorization tokens such as those of Falk. At most, the references disclose different implementations of token-based authorization. Such differences do not constitute teaching away and do not render the combination improper. Finally, Applicant’s arguments effectively read additional limitations into the claims, implying that the token must be generated exclusively at the issuer and must contain specific internal data in order for bearer input to be associated therewith. As this is not reflected in the claims, it is maintained that the combination of Falk and Shanmugam to teach these limitations remains proper.
Consequently, the rejection of the claims under 35 U.S.C. 103 is sustained.
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.
Claims 1-9 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Falk (US 20200302047 A1), in view of Shanmugam (US 20200322302 A1).
Regarding claim 1, Falk teaches the limitations of claim 1 substantially as follows:
A method, comprising:
obtaining, via an issuer, privilege information; (Falk; Paras. [0044]-[0045]: The certificate contains the explicit name of the certification entity, an explicit name of the device, a public key of the device, a time statement stipulating the validity of the certificate (i.e. privilege information) and the digital signature of the certification entity for the cited data, for example)
combining, via the issuer, the privilege information with receiver authentication data; (Falk; Paras. [0044]-[0045]: The certificate contains the explicit name of the certification entity, an explicit name of the device, a public key of the device (i.e. receiver authentication data), a time statement stipulating the validity of the certificate (i.e. privilege information) and the digital signature of the certification entity for the cited data, for example)
determining, via the issuer, an issuer hash value based on the combined privilege information and receiver authentication data; (Falk; Paras. [0044]-[0045]: The certificate contains the explicit name of the certification entity, an explicit name of the device, a public key of the device (i.e. receiver authentication data), a time statement stipulating the validity of the certificate (i.e. privilege information) and the digital signature of the certification entity for the cited data, for example. The signature was formed by applying the private key of the certification entity to the hash value of the details transmitted in the certificate (i.e. issuer hash value based on the combined privilege information and authentication information))
determining, via the issuer, an encrypted hash value based on the issuer hash value and a private key; (Falk; Paras. [0044]-[0045]: The signature was formed by applying the private key of the certification entity to the hash value of the details transmitted in the certificate (i.e. an encrypted hash value based on the issuer hash value and a private key))
combining, via the issuer, the privilege information with the encrypted hash value as a token; (Falk; Paras. [0044]-[0045]: The certificate (i.e. token) contains the explicit name of the certification entity, an explicit name of the device, a public key of the device, a time statement stipulating the validity of the certificate (i.e. privilege information) and the digital signature of the certification entity for the cited data, for example (i.e. encrypted hash value))
issuing, via the issuer, the token to a receiving device; (Falk; Para. [0044]: an existing certification infrastructure that equips the device with certificates signed by a certification entity (i.e. issuing, via the issuer, the token to a receiving device))
obtaining, by the receiving device, the token; (Falk; Para. [0044]: an existing certification infrastructure that equips the device with certificates signed by a certification entity (i.e. obtaining, by the receiving device, the token))
Falk does not teach the limitations of claim 1 as follows:
receiving an input from a bearer at the receiving device associated with the token;
authenticating the bearer as authorized to access data content, by the receiving device, using the receiver authentication data and the input from the bearer related to the token at the receiving device.
However, in the same field of endeavor, Shanmugam discloses the limitations of claim 1 as follows:
receiving an input from a bearer at the receiving device associated with the token; (Shanmugam; Para(s). [0103]: Responsive to the selection of the selectable input (and/or the content item), a request token may be generated and/or transmitted to the price protection system (i.e. input from a bearer at the receiving device associated with the token)
authenticating the bearer as authorized to access data content, by the receiving device, using the receiver authentication data and the input from the bearer related to the token at the receiving device. (Shanmugam; Para(s). [0103]: responsive to the selection of the selectable input (and/or the content item), an authentication process may be performed to verify an identify of the first user (i.e. authenticating the bearer as authorized to access data content, by the receiving device). In some examples, the authentication process may be performed using login information received via a login interface, a two-step verification process, an MFA process, a single-factor authentication process and/or a different type of authentication process (i.e. using the receiver authentication data and the input from a bearer related to the token at the receiving device))
Shanmugam is combinable with Falk because all are from the same field of endeavor of management of authenticating credentials. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified system of Falk to incorporate inclusion of user input as part of authentication as in Shanmugam in order to improve the security of the system by providing a means by which a user may be authenticated.
Regarding claim 2, Falk and Shanmugam teach the limitations of claim 1.
Falk and Shanmugam teach the limitations of claim 2 as follows:
The method of claim 1, comprising receiving, via a user interface of the issuer, a personal identification number (PIN) as the receiver authentication data to associate with a subject in the privilege information of the token. (Falk; Paras. [0044]-[0045]: The certificate contains the explicit name of the certification entity, an explicit name of the device (i.e. PIN), a public key of the device, a time statement stipulating the validity of the certificate and the digital signature of the certification entity for the cited data, for example)
Regarding claim 3, Falk and Shanmugam teach the limitations of claim 2.
Falk and Shanmugam teach the limitations of claim 3 as follows:
The method of claim 2, comprising obtaining a receiver key from a list of receivers to associate with the token. (Falk; Paras. [0044]-[0045]: The certificate contains the explicit name of the certification entity, an explicit name of the device, a public key of the device (i.e. a receiver key from a list of receivers to associate with the token), a time statement stipulating the validity of the certificate and the digital signature of the certification entity for the cited data, for example)
Regarding claim 4, Falk and Shanmugam teach the limitations of claim 3.
Falk and Shanmugam teach the limitations of claim 4 as follows:
The method of claim 3, wherein combining the privilege information with receiver authentication data comprises appending the PIN and the receiver key to the privilege information. (Falk; Paras. [0044]-[0045]: The certificate contains the explicit name of the certification entity, an explicit name of the device, a public key of the device, a time statement stipulating the validity of the certificate (i.e. combining the privilege information with receiver authentication data comprises appending the PIN and the receiver key to the privilege information) and the digital signature of the certification entity for the cited data, for example)
Regarding claim 5, Falk and Shanmugam teach the limitations of claim 1.
Falk and Shanmugam teach the limitations of claim 5 as follows:
The method of claim 1, wherein the issuer is a token issuance server. (Falk; Para. [0044]: an existing certification infrastructure that equips the device with certificates signed by a certification entity (i.e. the issuer is a token issuance server))
Regarding claim 6, Falk and Shanmugam teach the limitations of claim 1.
Falk and Shanmugam teach the limitations of claim 6 as follows:
The method of claim 1, comprising: obtaining, via a receiver, the token comprising the privilege information and the encrypted hash value; (Falk; Paras. [0044]-[0045]: the device transmits a certificate as proof of authorization to the authentication server (i.e. obtaining, via a receiver, the token comprising the privilege information and the encrypted hash value). The certificate contains the explicit name of the certification entity, an explicit name of the device, a public key of the device, a time statement stipulating the validity of the certificate and the digital signature of the certification entity for the cited data)
obtaining, via user inputs of the receiver, receiver authentication data; (Shanmugam; Para(s). [0103]: Responsive to the selection of the selectable input (and/or the content item), a request token may be generated and/or transmitted to the price protection system)
determining, via the receiver, a first receiver hash value based at least in part on a combination of the privilege information and the receiver authentication data; (Falk; Para. [0045]: The public key of the certification entity is able to be used to ascertain the hash value in the reverse step and to compare it with the result of a hash value formation for the details that the certificate contains (i.e. a first receiver hash value based at least in part on a combination of the privilege information and the receiver authentication data))
determining, via the receiver, a second receiver device hash value by decrypting the encrypted hash value using a public key of the issuer; and (Falk; Para. [0045]: The public key of the certification entity is able to be used to ascertain the hash value in the reverse step (i.e. determining, via the receiver, a second receiver device hash value by decrypting the encrypted hash value using a public key of the issuer) and to compare it with the result of a hash value formation for the details that the certificate contains)
authenticating, via the receiver, the token based on the first receiver hash value matching the second receiver hash value. (Falk; Para. [0045]: The public key of the certification entity is able to be used to ascertain the hash value in the reverse step and to compare it with the result of a hash value formation for the details that the certificate contains (i.e. authenticating, via the receiver, the token based on the first receiver hash value matching the second receiver hash value))
The same motivation to combine as in claim 1 is applicable to the instant claim.
Regarding claim 7, Falk and Shanmugam teach the limitations of claim 2.
Falk and Shanmugam teach the limitations of claim 7 as follows:
The method of claim 2, comprising an electronic document having the privilege information, wherein access to the electronic document is limited according to the privilege information, (Falk; Paras. [0044]-[0045]: The certificate contains the explicit name of the certification entity, an explicit name of the device, a public key of the device, a time statement stipulating the validity of the certificate (i.e. an electronic document having the privilege information, wherein access to the electronic document is limited according to the privilege information) and the digital signature of the certification entity for the cited data, for example)
wherein the electronic document is hashed along with the privilege information and the PIN. (Falk; Paras. [0044]-[0045]: The certificate contains the explicit name of the certification entity, an explicit name of the device, a public key of the device (i.e. authentication information), a time statement stipulating the validity of the certificate (i.e. privilege information) and the digital signature of the certification entity for the cited data, for example. The signature was formed by applying the private key of the certification entity to the hash value of the details transmitted in the certificate (i.e. the electronic document is hashed along with the privilege information and the PIN))
Regarding claim 8, Falk teaches the limitations of claim 1 substantially as follows:
An issuer, comprising: memory; and a processor operatively coupled to the memory, wherein the processor is configured to execute instructions to cause operations comprising:
obtaining privilege information; (Falk; Paras. [0044]-[0045]: The certificate contains the explicit name of the certification entity, an explicit name of the device, a public key of the device, a time statement stipulating the validity of the certificate (i.e. privilege information) and the digital signature of the certification entity for the cited data, for example)
combining the privilege information with receiver authentication data: (Falk; Paras. [0044]-[0045]: The certificate contains the explicit name of the certification entity, an explicit name of the device, a public key of the device (i.e. receiver authentication data), a time statement stipulating the validity of the certificate (i.e. privilege information) and the digital signature of the certification entity for the cited data, for example)
determining an issuer hash value based on the combined privilege information and receiver authentication data; (Falk; Paras. [0044]-[0045]: The certificate contains the explicit name of the certification entity, an explicit name of the device, a public key of the device (i.e. authentication information), a time statement stipulating the validity of the certificate (i.e. privilege information) and the digital signature of the certification entity for the cited data, for example. The signature was formed by applying the private key of the certification entity to the hash value of the details transmitted in the certificate (i.e. issuer hash value based on the combined privilege information and receiver authentication data))
determining an encrypted hash value based on the issuer hash value and a private key of the issuer; (Falk; Paras. [0044]-[0045]: The signature was formed by applying the private key of the certification entity to the hash value of the details transmitted in the certificate (i.e. an encrypted hash value based on the issuer hash value and a private key))
combining the privilege information with the encrypted hash value as a token; and (Falk; Paras. [0044]-[0045]: The certificate (i.e. token) contains the explicit name of the certification entity, an explicit name of the device, a public key of the device, a time statement stipulating the validity of the certificate (i.e. privilege information) and the digital signature of the certification entity for the cited data, for example (i.e. encrypted hash value))
issuing the token (Falk; Para. [0044]: an existing certification infrastructure that equips the device with certificates signed by a certification entity (i.e. issuing, via the issuer, the token))
Falk does not teach the limitations of claim 8 as follows:
wherein the receiver authentication data may be used by a receiving device upon receipt of an input from a bearer to authenticate the bearer as authorized to access data content using the receiver authentication data and the input from the bearer at the receiving device.
However, in the same field of endeavor, Shanmugam discloses the limitations of claim 8 as follows:
wherein the receiver authentication data may be used by a receiving device upon receipt of an input from a bearer to authenticate the bearer as authorized to access data content using the receiver authentication data and the input from the bearer at the receiving device.(Shanmugam; Para(s). [0103]: responsive to the selection of the selectable input (and/or the content item), an authentication process may be performed to verify an identify of the first user (i.e. authenticating the bearer as authorized to access data content, by the receiving device). In some examples, the authentication process may be performed using login information received via a login interface, a two-step verification process, an MFA process, a single-factor authentication process and/or a different type of authentication process (i.e. using the receiver authentication data and the input from a bearer related to the token at the receiving device))
Shanmugam is combinable with Falk because all are from the same field of endeavor of management of authenticating credentials. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified system of Falk to incorporate inclusion of user input as part of authentication as in Shanmugam in order to improve the security of the system by providing a means by which a user may be authenticated.
Regarding claim 9, Falk and Shanmugam teach the limitations of claim 1.
Falk and Shanmugam teach the limitations of claim 9 as follows:
The issuer of claim 8, wherein the private key is mathematically related to a public key such that the public key decrypts the encrypted hash value. (Falk; Para. [0045]: The public key of the certification entity is able to be used to ascertain the hash value in the reverse step (i.e. the private key is mathematically related to a public key such that the public key decrypts the encrypted hash value) and to compare it with the result of a hash value formation for the details that the certificate contains)
Regarding claim 13, Falk teaches the limitations of claim 1 substantially as follows:
A receiver, comprising: memory; and a processor operatively coupled to the memory, wherein the processor is configured to execute instructions to cause operations comprising:
obtaining a token comprising privilege information and an encrypted hash value; obtaining an input of data from a bearer at the receiver; (Falk; Paras. [0044]-[0045]: the device transmits a certificate as proof of authorization to the authentication server (i.e. obtaining a token comprising privilege information and an encrypted hash value). The certificate contains the explicit name of the certification entity, an explicit name of the device, a public key of the device (i.e. an input of data from a bearer at the receiver), a time statement stipulating the validity of the certificate and the digital signature of the certification entity for the cited data)
determining a first receiver hash value based at least in part on a combination of the privilege information and the input of data from the bearer; (Falk; Para. [0045]: The public key of the certification entity is able to be used to ascertain the hash value in the reverse step and to compare it with the result of a hash value formation for the details that the certificate contains (i.e. a first receiver hash value based at least in part on a combination of the privilege information and the input of data from the bearer))
determining a second receiver hash value by decrypting the encrypted hash value using a public key of an issuer of the token, (Falk; Para. [0045]: The public key of the certification entity is able to be used to ascertain the hash value in the reverse step (i.e. determining, via the receiver, a second receiver device hash value by decrypting the encrypted hash value using a public key of an issuer of the token) and to compare it with the result of a hash value formation for the details that the certificate contains)
wherein the token comprises receiver authentication data; and (Falk; Paras. [0044]-[0045]: the device transmits a certificate as proof of authorization to the authentication server (i.e. the token comprises receiver authentication data). The certificate contains the explicit name of the certification entity, an explicit name of the device, a public key of the device, a time statement stipulating the validity of the certificate and the digital signature of the certification entity for the cited data)
authenticating the token based on the first receiver hash value matching the second receiver hash value, (Falk; Para. [0045]: The public key of the certification entity is able to be used to ascertain the hash value in the reverse step and to compare it with the result of a hash value formation for the details that the certificate contains (i.e. authenticating, via the receiver, the token based on the first receiver hash value matching the second receiver hash value))
Falk does not teach the limitations of claim 13 as follows:
authenticating the bearer as authorized to access data content using the token
wherein the authentication requires that the input of data from the bearer matches the receiver authentication data of the token.
However, in the same field of endeavor, Shanmugam discloses the limitations of claim 13 as follows:
authenticating the bearer as authorized to access data content using the token (Shanmugam; Para(s). [0103]: Responsive to the selection of the selectable input (and/or the content item), a request token may be generated and/or transmitted to the price protection system (i.e. input from a bearer at the receiving device associated with the token)
wherein the authentication requires that the input of data from the bearer matches the receiver authentication data of the token. (Shanmugam; Para(s). [0103]: responsive to the selection of the selectable input (and/or the content item), an authentication process may be performed to verify an identify of the first user (i.e. authenticating the bearer as authorized to access data content, by the receiving device). In some examples, the authentication process may be performed using login information received via a login interface, a two-step verification process, an MFA process, a single-factor authentication process and/or a different type of authentication process (i.e. the authentication requires that the input of data from the bearer matches the receiver authentication data of the token))
Shanmugam is combinable with Falk because all are from the same field of endeavor of management of authenticating credentials. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified system of Falk to incorporate inclusion of user input as part of authentication as in Shanmugam in order to improve the security of the system by providing a means by which a user may be authenticated.
Regarding claim 14, Falk and Shanmugam teach the limitations of claim 1.
Falk and Shanmugam teach the limitations of claim 14 as follows:
The receiver of claim 13, wherein the one or more processors are configured to: acquire a public key associated with the issuer; and decrypt the encrypted hash value using the public key to obtain the second receiver hash value. (Falk; Para. [0045]: The public key of the certification entity is able to be used to ascertain the hash value in the reverse step (i.e. acquire a public key associated with the issuer; and decrypt the encrypted hash value using the public key to obtain the second receiver hash value) and to compare it with the result of a hash value formation for the details that the certificate contains)
Claims 10-12 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Falk (US 20200302047 A1), in view of Shanmugam (US 20200322302 A1), as applied to independent claims, in view of Hiltgen (US 20190138707 A1).
Regarding claim 10, Falk and Shanmugam teach the limitations of claim 8.
Falk and Shanmugam teach the limitations of claim 10 as follows:
The issuer of claim 8,
wherein each privilege indicates allowed uses of data content associated with the token. (Falk; Paras. [0044]-[0045]: The certificate contains the explicit name of the certification entity, an explicit name of the device, a public key of the device, a time statement stipulating the validity of the certificate (i.e. each privilege indicates allowed uses of data content associated with the token) and the digital signature of the certification entity for the cited data, for example)
Falk and Shanmugam do not teach the limitations of claim 10 as follows:
wherein the privilege information comprises a list of subjects and a privilege associated with each subject,
However, in the same field of endeavor, Hiltgen discloses the limitations of claim 10 as follows:
wherein the privilege information comprises a list of subjects and a privilege associated with each subject, (Hiltgen; Para. [0031]: Secure component may select the key(s) (associated with the first challenge type) from multiple keys stored in its secure memory (e.g., memory integrated as part of secure component). The multiple keys stored in the secure memory may include multiple private keys, multiple public keys (respectively corresponding to the private keys), or other keys (i.e. the privilege information comprises a list of subjects and a privilege associated with each subject))
Hiltgen is combinable with Falk and Shanmugam because all are from the same field of endeavor of management of credentials. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified system of Falk and Shanmugam to incorporate selection from a multitude of credentials as in Hiltgen in order to expand the functionality of the system by providing a means by which multiple credentials may be managed.
Regarding claim 11, Falk and Shanmugam teach the limitations of claim 8.
Falk and Shanmugam do not teach the limitations of claim 11 as follows:
The issuer of claim 8, wherein the processor is configured to execute instructions to cause operations comprising receiving a notification from the receiver indicating an attempted authentication when the receiver uses different receiver authentication data.
However, in the same field of endeavor, Hiltgen discloses the limitations of claim 11 as follows:
The issuer of claim 8, wherein the processor is configured to execute instructions to cause operations comprising receiving a notification from the receiver indicating an attempted authentication when the receiver uses different receiver authentication data. (Hiltgen; Para. [0030]: obtain notifications of authentication or failure to authenticate with his/her token(s) (i.e. receiving a notification from the receiver indicating an attempted authentication when the receiver uses different receiver authentication data))
Hiltgen is combinable with Falk and Shanmugam because all are from the same field of endeavor of management of credentials. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified system of Falk and Shanmugam to incorporate notification of authentication status as in Hiltgen in order to expand the functionality of the system by providing a means by an individual may be alerted when an authentication operation fails.
Regarding claim 12, Falk and Shanmugam teach the limitations of claim 8.
Falk and Shanmugam do not teach the limitations of claim 12 as follows:
The issuer of claim 8, wherein the processor is configured to execute instructions to cause operations comprising: receiving, via a user input, a selection of a receiver in which to send the token; and determining a device key of the selected receiver to include as the receiver authentication data.
However, in the same field of endeavor, Hiltgen discloses the limitations of claim 12 as follows:
The issuer of claim 8, wherein the processor is configured to execute instructions to cause operations comprising: receiving, via a user input, a selection of a receiver in which to send the token; and determining a device key of the selected receiver to include as the receiver authentication data. (Hiltgen; Para. [0031]: Secure component may select the key(s) (associated with the first challenge type) from multiple keys stored in its secure memory (e.g., memory integrated as part of secure component). The multiple keys stored in the secure memory may include multiple private keys, multiple public keys (respectively corresponding to the private keys), or other keys (i.e. a selection of a receiver in which to send the token; and determining a device key of the selected receiver to include as the receiver authentication data))
Hiltgen is combinable with Falk and Shanmugam because all are from the same field of endeavor of management of credentials. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified system of Falk and Shanmugam to incorporate selection from a multitude of credentials as in Hiltgen in order to expand the functionality of the system by providing a means by which multiple credentials may be managed.
Regarding claim 20, Falk and Shanmugam teach the limitations of claim 13.
Falk and Shanmugam do not teach the limitations of claim 20 as follows:
The receiver of claim 13, wherein the processor is configured to execute instructions to cause operations comprising sending a signal indicating a security event when the first receiver hash value does not match the second receiver hash value.
However, in the same field of endeavor, Hiltgen discloses the limitations of claim 20 as follows:
The receiver of claim 13, wherein the processor is configured to execute instructions to cause operations comprising sending a signal indicating a security event when the first receiver hash value does not match the second receiver hash value. (Hiltgen; Para. [0030]: obtain notifications of authentication or failure to authenticate with his/her token(s) (i.e. sending a signal indicating a security event when the first receiver hash value does not match the second receiver hash value))
Hiltgen is combinable with Falk and Shanmugam because all are from the same field of endeavor of management of credentials. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified system of Falk and Shanmugam to incorporate notification of authentication status as in Hiltgen in order to expand the functionality of the system by providing a means by an individual may be alerted when an authentication operation fails.
Claims 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Falk (US 20200302047 A1), in view of Shanmugam (US 20200322302 A1), further in view of Wright (US 20240202718 A1).
Regarding claim 15, Falk and Shanmugam teach the limitations of claim 13.
Falk and Shanmugam do not teach the limitations of claim 15 as follows:
The receiver of claim 13, wherein the receiver authentication data comprises a device key that is based on a media access control (MAC) address or a serial number that is unique to the receiver.
However, in the same field of endeavor, Wright discloses the limitations of claim 15 as follows:
The receiver of claim 13, wherein the receiver authentication data comprises a device key that is based on a media access control (MAC) address or a serial number that is unique to the receiver. (Wright; Para. [0392]: constituents to the identification data may include a passport number, national insurance number, names, birth date, or the answers to a security question (e.g. mother's maiden name), or serial numbers and manufacturing information in the case of device identification (i.e. the receiver authentication data comprises a device key that is based on a media access control (MAC) address or a serial number that is unique to the receiver))
Wright is combinable with Falk and Shanmugam because all are from the same field of endeavor of management of authenticating credentials. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified system of Falk and Shanmugam to incorporate inclusion of an input of a variety of identity credentials such as password, PIN or a biometric input as in Wright in order to expand the functionality of the system by providing a means by which different credentials may be used to identity an individual or device.
Regarding claim 16, Falk and Shanmugam teach the limitations of claim 15.
Falk and Shanmugam do not teach the limitations of claim 15 as follows:
The receiver of claim 15, wherein the receiver authentication data comprises a personal identification number (PIN), comprising one or more letters, numbers, or combination thereof, entered by a user at the receiver.
However, in the same field of endeavor, Wright discloses the limitations of claim 15 as follows:
The receiver of claim 15, wherein the receiver authentication data comprises a personal identification number (PIN), comprising one or more letters, numbers, or combination thereof, entered by a user at the receiver. (Wright; Para. [0125]: present recognized credentials such as a password, PIN or biometric information (i.e. the receiver authentication data comprises a personal identification number (PIN), comprising one or more letters, numbers, or combination thereof, entered by a user at the receiver))
Wright is combinable with Falk and Shanmugam because all are from the same field of endeavor of management of authenticating credentials. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified system of Falk and Shanmugam to incorporate inclusion of an input of a variety of identity credentials such as password, PIN or a biometric input as in Wright in order to expand the functionality of the system by providing a means by which different credentials may be used to identity an individual or device.
Regarding claim 17, Falk, Shanmugam and Wright teach the limitations of claim 16.
Falk, Shanmugam and Wright teach the limitations of claim 17 as follows:
The receiver of claim 16, wherein the processor is configured to execute instructions to cause operations comprising limiting use of data content associated with the token according to privilege information for a subject associated with the PIN. (Falk; Paras. [0044]-[0045]: The certificate contains the explicit name of the certification entity, an explicit name of the device, a public key of the device, a time statement stipulating the validity of the certificate (i.e. limiting use of data content associated with the token according to privilege information for a subject associated with the PIN) and the digital signature of the certification entity for the cited data, for example)
Regarding claim 18, Falk, Shanmugam and Wright teach the limitations of claim 16.
Falk, Shanmugam and Wright teach the limitations of claim 18 as follows:
The receiver of claim 16, wherein the PIN and the device key are appended to the privilege information in the same order as when the issuer hashed the privilege information, the PIN, and the device key. (Falk; Para. [0045]: The public key of the certification entity is able to be used to ascertain the hash value in the reverse step and to compare it with the result of a hash value formation for the details that the certificate contains (i.e. the PIN and the device key are appended to the privilege information in the same order as when the issuer hashed the privilege information, the PIN, and the device key))
Claims 19 are rejected under 35 U.S.C. 103 as being unpatentable over Falk (US 20200302047 A1), in view of Shanmugam (US 20200322302 A1), as applied to independent claims, in view of Hiltgen (US 20190138707 A1).
Regarding claim 19, Falk and Shanmugam teach the limitations of claim 13.
Falk and Shanmugam teach the limitations of claim 19 as follows:
The receiver of claim 13,
to obtain, via a user interface of the receiver, the receiver authentication data. (Shanmugam; Para(s). [0103]: Responsive to the selection of the selectable input (and/or the content item), a request token may be generated and/or transmitted to the price protection system)
Falk and Shanmugam do not teach the limitations of claim 19 as follows:
wherein the receiver is configured to obtain, via a universal serial bus (USB), the token from a portable device, and
However, in the same field of endeavor, Hiltgen discloses the limitations of claim 19 as follows:
wherein the receiver is configured to obtain, via a universal serial bus (USB), the token from a portable device, and (Hiltgen; Para. [0019]: non-wireless tokens which communicate via a Universal Serial Bus (USB) connection (i.e. obtain, via a universal serial bus (USB), the token from a portable device))
Hiltgen is combinable with Falk and Shanmugam because all are from the same field of endeavor of management of credentials. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified system of Falk and Shanmugam to incorporate use of a USB interface for providing a token as in Hiltgen in order to expand the functionality of the system by providing a means by which additional methods of receiving the authentication token.
Prior Art Considered But Not Relied Upon
DeRosa-Grund (US 20220270725 A1) which teaches an authentication verification request with the password to the key module, which retrieves the password salt, encryption parameters and authentication hash for the user.
Liu (US 20220231849 A1) which teaches obtaining an access token of a cloud storage server by a management device; sending a certificate request message to the management device by a user apparatus; performing a certificate verification on the user apparatus by the management device according to the certificate request message, and sending a certificate pass message with the access token to the user apparatus by the management device after passing the certificate verification
Conclusion
For the above-stated reasons, claims 1-20 are rejected.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BLAKE ISAAC NARRAMORE whose telephone number is (303)297-4357. The examiner can normally be reached on Monday - Friday 0700-1700 MT.
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, Taghi T Arani can be reached on (571) 272-3787. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BLAKE I NARRAMORE/Examiner, Art Unit 2438