DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/04/2026 has been entered. Claims 1- 12,21-22,24-29 have been examined. Claims 13-20,23 are cancelled.
Response to Arguments
Applicant’s arguments, see Remarks – Pages 8-11 filed on 01/20/2026, with respect to the rejections of claims 1,9,21 under 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of Holt.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1,2,5,7,9,10,21,22,25,27 are rejected under 35 U.S.C. 103 as being unpatentable over Hawkes et al. Publication No. US 2004/0003260 A1 ( Hawkes hereinafter) in view of Holt et al. “Selective Disclosure Credential Sets” (Holt hereinafter).
Regarding claim 1
Hawkes teaches a method comprising:
receiving a digital pass from a first server, wherein the digital pass comprises a plurality of attributes (¶ 0005 - issuer generating a digital ticket associated with a verifier. The issuer is authorized by the verifier to generate such digital tickets. The method also includes providing the ticket to a portable mobile device – ¶0033 - The digital tickets may be provided to the user of the mobile device 12 by voice, printed paper, or email – ¶0035 - each preferred, nonlimiting digital ticket 21 includes ticket data, i.e., information regarding what the ticket is for ( e.g., entry into a particular entity or group of entities), along with a ticket index, also referred to as a booking number or ticket number );
transmitting, to a second server, a request to access a service associated with an attribute of the plurality of attributes of the digital pass (¶ 0044 - FIG. 6, which discloses further components of the preferred TMF 14 and mobile device 12 that are used when a ticket is to be presented for access, and which assumes, for completeness, that encryption has been employed. When a user desires access to an entity associated with the TMF 14, the user selects the appropriate ticket (with ticket index) using any convenient mobile device 12 input apparatus ( e.g., keypad) and then manipulates the mobile device 12 as appropriate to transmit the ticket index - ¶0048 - Once decrypted, the ticket index 20 is used by the TMF 14 to selectively grant access to the entity to which the ticket index corresponds. To do this, the TMF 14 can first determine whether the ticket index 20 is valid by determining whether it exists in the ticket database 16) ;
receiving, from the second server, a request for verification of the attribute( ¶0048 - if the ticket index is not initially found, the TMF 14 can request the mobile device 12 to retransmit, in which case one of the alternate ticket indices associated with the ticket ( as mentioned above) can be transmitted In addition to the above, if desired, to foil a "false attack" that might arise by an eavesdropper controlling the receiving microphone and intercepting a ticket for later reuse, authentication information ( e.g., time and/or location) can also be transmitted by the mobile device 12 and checked by the TMF 14 before granting access);
transmitting, responsive to the request, a portion of the digital pass that includes the attribute to the second server for verification of the attribute [..]; and accessing the service via the second server based at least in part on transmitting the portion of the digital pass to the second server (¶0048 - the ticket index 20 is used by the TMF 14 to selectively grant access to the entity to which the ticket index corresponds. To do this, the TMF 14 can first determine whether the ticket index 20 is valid by determining whether it exists in the ticket database 16. If the ticket index is valid, the TMF 14 can determine whether the ticket index 20 has been used already ( as might be indicated by, e.g., a "used" flag), granting access – Claim 1- using at least the portion, selectively granting, to a user of the mobile device, access to an entity associated with the verifier – Claim 12 - determining whether at least the portion of the digital ticket matches at least one entry in a database accessible to the verifier; determining whether the digital ticket has been used; and only if the portion matches at least one entry in the database and the ticket has not yet been used or voided, granting access to the entity – ¶0005 - selectively grants access, wherein access denotes access to goods, services, data or whatever is associated with the digital ticket – ¶0031 - The particular entity, access to which is controlled by the TMF, can take any suitable form, e.g., the entity might be a movie theater, with successful presentation of a digital ticket resulting in the automatic or manual unlocking of an entrance door – See ¶0044).
However, Hawkes does not explicitly teach
wherein the at least a portion of the digital pass includes a digital signature associated with the digital pass and the portion of the digital pass excludes other attributes of the plurality of attributes that are unassociated with the service, and the attribute is verifiable by the second server based at least in part on the digital signature and without obtaining any of the excluded other attributes of the digital pass.
Holt teaches
wherein the at least a portion of the digital pass includes a digital signature associated with the digital pass and the portion of the digital pass excludes other attributes of the plurality of attributes that are unassociated with the service, and the attribute is verifiable by the second server based at least in part on the digital signature and without obtaining any of the excluded other attributes of the digital pass (Section 1 - Alice wishes to obtain a service from Steve, a server. Steve will only provide the service if Alice can demonstrate certain attributes about herself as attested by credential issuing authorities. Alice is willing to prove these attributes, but doesn't want Steve to get any additional information about her, even if Steve works together with the credential issuers - If Alice doesn't choose to reveal the value of a selective disclosure field, Steve doesn't learn anything about that value - Section 3.1.1 - A selective disclosure credential has several attributes. When the user shows the credential to a verifier, she can choose to reveal only some of the attributes to the verifier – Section 4 - Alice may have several credentials issued by different issuers. For example, the state might issue her driver's license, while her school issues her student identification .Alice can then unblind the credentials and show them to obtain services – Notes - She sends Steve the unblinded signature, the certificates which were signed, and the values for the selective disclosure fields she wishes to reveal (along with the random strings used in commit()) – Section 4.2 - Alice can then unblind the signature and use it along with the corresponding certificates as a valid, signed credential – Section 4.4 - Steve verifies the credential signature just as for any other RSA signature, by raising the signature to the issuer's public exponent (modulo its public modulus) and checking that the value equals the product of certificate hashes - Steve forwards the product of hashes and the signature to the issuer for verification. Note that this product of hashes does not reveal the credentials themselves to the issuer, and thus preserves the privacy of both Alice and Steve).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Holt. The motivation for doing so is to allow the system to use bit commitments to create selective disclosure credentials which limit what portions of a credential the holder must reveal (Abstract – Holt) .
Regarding claim 2
Hawkes further teaches
transmitting, to a third server, a request to access another service associated with another attribute of the plurality of attributes; receiving, from the third server, a request for verification of the other attribute (¶0044 - FIG. 6, which discloses further components of the preferred TMF 14 and mobile device 12 that are used when a ticket is to be presented for access, and which assumes, for completeness, that encryption has been employed. When a user desires access to an entity associated with the TMF 14, the user selects the appropriate ticket (with ticket index) using any convenient mobile device 12 input apparatus ( e.g., keypad) and then manipulates the mobile device 12 as appropriate to transmit the ticket index - ¶0048 - Once decrypted, the ticket index 20 is used by the TMF 14 to selectively grant access to the entity to which the ticket index corresponds. To do this, the TMF 14 can first determine whether the ticket index 20 is valid by determining whether it exists in the ticket database 16 – ¶0035 Turning to the details of FIG. 4, as shown the TMF 14 can include a ticket database 16 that stores ticket data 18 indexed by ticket indices 20. Thus, each preferred, nonlimiting digital ticket 21 includes ticket data, i.e., information regarding what the ticket is for ( e.g., entry into a particular entity or group of entities), along with a ticket index, also referred to as a booking number or ticket number. However, "digital ticket" can refer simply to the ticket index. If desired, a single ticket might be assigned more than one ticket index, so that if need be the same ticket, in the form of its indices, may be transmitted more than once ( e.g., a second time for confirmation) without having to use the same index and, hence, give an eavesdropper the opportunity to re-use a ticket );
transmitting, responsive to the request, another portion of the digital pass that include the other attribute to the third server for verification of the other attribute [..]; and accessing the other service via the third server based at least in part on transmitting the at least the other portion of the digital pass to the third server(¶ 0048 - the ticket index 20 is used by the TMF 14 to selectively grant access to the entity to which the ticket index corresponds. To do this, the TMF 14 can first determine whether the ticket index 20 is valid by determining whether it exists in the ticket database 16. If the ticket index is valid, the TMF 14 can determine whether the ticket index 20 has been used already ( as might be indicated by, e.g., a "used" flag), granting access – Claim 1- using at least the portion, selectively granting, to a user of the mobile device, access to an entity associated with the verifier – Claim 12 - determining whether at least the portion of the digital ticket matches at least one entry in a database accessible to the verifier; determining whether the digital ticket has been used; and only if the portion matches at least one entry in the database and the ticket has not yet been used or voided, granting access to the entity – ¶ 0005 - selectively grants access, wherein access denotes access to goods, services, data or whatever is associated with the digital ticket – ¶ 0031 - The particular entity, access to which is controlled by the TMF, can take any suitable form, e.g., the entity might be a movie theater, with successful presentation of a digital ticket resulting in the automatic or manual unlocking of an entrance door – See ¶ 0030-0031, ¶ 0044, ¶ 0050).
However, Hawkes does not explicitly teach wherein the other portion of the digital pass includes the digital signature associated with the digital pass
Holt teaches
wherein the other portion of the digital pass includes the digital signature associated with the digital pass (Section -1 - When Alice shows some subset of the credentials to Steve, Steve checks that all the IDs match, ensuring that all the credentials were in fact issued to the same person. Alice also reveals the preimages of the selective disclosure attributes in each credential which she wishes to show to Steve. If Alice later shows credentials from the same set to someone else, that person could collude with Steve and determine that they both were dealing with the same person – Section 4.2 - . Alice can then unblind the signature and use it along with the corresponding certificate as a valid, signed credential – Section 4.4 - Steve verifies the credential signature just as for any other RSA signature, by raising the signature to the issuer's public exponent (modulo its public modulus) and checking that the value equals the product of certificate hashes).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Holt. The motivation for doing so is to allow the system to use bit commitments to create selective disclosure credentials which limit what portions of a credential the holder must reveal (Abstract – Holt) .
Regarding claim 5
Hawkes does not explicitly teach
wherein the digital signature is generated with a private key associated with the digital pass and the digital signature is verified by a public key associated with the digital pass
However, Holt teaches
wherein the digital signature is generated with a private key associated with the digital pass and the digital signature is verified by a public key associated with the digital pass ( Section 3.1 The issuer signs the request by hashing the document with a collision-resistant one-way function and signing the hash with his private key. Later the user can show the signed certificate to a verifier, who verifies that the certificate is valid. - Section 4.3 - certificate contain a public key whose corresponding private key is known to the rightful certificate owner. This allows Alice to show a certificate to Steve and prove her ownership of it. She can do this by creating a new key pair whose public key will be included in each credential in her set. She stores it as a selective disclosure value in her credentials so that Izzy doesn't see it when signing them. Later she'll reveal it to Steve when he demands that she prove ownership of her credentials).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Holt. The motivation for doing so is to allow the system to use bit commitments to create selective disclosure credentials which limit what portions of a credential the holder must reveal (Abstract – Holt) .
Regarding claim 7
Hawkes further teaches wherein transmitting the portion of the digital pass (¶ 0048, Claim 12).
However, Hawkes does not explicitly teach
receiving a selection of the attribute from the plurality of attributes from a user.
Holt teaches
receiving a selection of the attribute from the plurality of attributes from a user (Abstract - Our system uses bit commitments to create selective disclosure credentials which limit what portions of a credential the holder must reveal – Section 1 - If Alice doesn't choose to reveal the value of a selective disclosure
field, Steve doesn't learn anything about that value. But if she does choose to reveal such a field, Steve can verify that she isn't lying about its value. Section 3.1.1 - selective disclosure credential has several attributes. When the user shows the credential to a verifier, she can choose to reveal only some of the attributes to the verifier).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Holt. The motivation for doing so is to allow the system to use bit commitments to create selective disclosure credentials which limit what portions of a credential the holder must reveal (Abstract – Holt) .
Regarding claim 9
Hawkes teaches a system comprising:
a memory and a processor circuit configured to receive a digital pass from receive a digital pass from a first server, wherein the digital pass comprises a plurality of attributes (¶ 0005 - issuer generating a digital ticket associated with a verifier. The issuer is authorized by the verifier to generate such digital tickets. The method also includes providing the ticket to a portable mobile device – ¶ 0033 - The digital tickets may be provided to the user of the mobile device 12 by voice, printed paper, or email – ¶0035 - each preferred, nonlimiting digital ticket 21 includes ticket data, i.e., information regarding what the ticket is for ( e.g., entry into a particular entity or group of entities), along with a ticket index, also referred to as a booking number or ticket number );
transmit, to a second server, a request to access a service associated with an attribute of the plurality of attributes of the digital pass (¶ 0044 - FIG. 6, which discloses further components of the preferred TMF 14 and mobile device 12 that are used when a ticket is to be presented for access, and which assumes, for completeness, that encryption has been employed. When a user desires access to an entity associated with the TMF 14, the user selects the appropriate ticket (with ticket index) using any convenient mobile device 12 input apparatus ( e.g., keypad) and then manipulates the mobile device 12 as appropriate to transmit the ticket index - ¶ 0048 - Once decrypted, the ticket index 20 is used by the TMF 14 to selectively grant access to the entity to which the ticket index corresponds. To do this, the TMF 14 can first determine whether the ticket index 20 is valid by determining whether it exists in the ticket database 16) ;
receive, from the second server, a request for verification of the attribute( ¶ 0048 - if the ticket index is not initially found, the TMF 14 can request the mobile device 12 to retransmit, in which case one of the alternate ticket indices associated with the ticket ( as mentioned above) can be transmitted In addition to the above, if desired, to foil a "false attack" that might arise by an eavesdropper controlling the receiving microphone and intercepting a ticket for later reuse, authentication information ( e.g., time and/or location) can also be transmitted by the mobile device 12 and checked by the TMF 14 before granting access);
transmit, responsive to the request, a portion of the digital pass that includes the attribute to the second server for verification of the attribute [..]; and access the service via the second server based at least in part on transmitting the portion of the digital pass to the second server (¶ 0048 - the ticket index 20 is used by the TMF 14 to selectively grant access to the entity to which the ticket index corresponds. To do this, the TMF 14 can first determine whether the ticket index 20 is valid by determining whether it exists in the ticket database 16. If the ticket index is valid, the TMF 14 can determine whether the ticket index 20 has been used already ( as might be indicated by, e.g., a "used" flag), granting access – Claim 1- using at least the portion, selectively granting, to a user of the mobile device, access to an entity associated with the verifier – Claim 12 - determining whether at least the portion of the digital ticket matches at least one entry in a database accessible to the verifier; determining whether the digital ticket has been used; and only if the portion matches at least one entry in the database and the ticket has not yet been used or voided, granting access to the entity – ¶0005 - selectively grants access, wherein access denotes access to goods, services, data or whatever is associated with the digital ticket – ¶ 0031 - The particular entity, access to which is controlled by the TMF, can take any suitable form, e.g., the entity might be a movie theater, with successful presentation of a digital ticket resulting in the automatic or manual unlocking of an entrance door – See ¶ 0044).
However, Hawkes does not explicitly teach
wherein the at least a portion of the digital pass includes a digital signature associated with the digital pass and the portion of the digital pass excludes other attributes of the plurality of attributes that are unassociated with the service, and the attribute is verifiable by the second server based at least in part on the digital signature and without obtaining any of the excluded other attributes of the digital pass;
Holt teaches
wherein the at least a portion of the digital pass includes a digital signature associated with the digital pass and the portion of the digital pass excludes other attributes of the plurality of attributes that are unassociated with the service, and the attribute is verifiable by the second server based at least in part on the digital signature and without obtaining any of the excluded other attributes of the digital pass (Section 1 - Alice wishes to obtain a service from Steve, a server. Steve will only provide the service if Alice can demonstrate certain attributes about herself as attested by credential issuing authorities. Alice is willing to prove these attributes, but doesn't want Steve to get any additional information about her, even if Steve works together with the credential issuers - If Alice doesn't choose to reveal the value of a selective disclosure field, Steve doesn't learn anything about that value - Section 3.1.1 - A selective disclosure credential has several attributes. When the user shows the credential to a verifier, she can choose to reveal only some of the attributes to the verifier – Section 4 - Alice may have several credentials issued by different issuers. For example, the state might issue her driver's license, while her school issues her student identification .Alice can then unblind the credentials and show them to obtain services – Notes - She sends Steve the unblinded signature, the certificates which were signed, and the values for the selective disclosure fields she wishes to reveal (along with the random strings used in commit()) – Section 4.2 - Alice can then unblind the signature and use it along with the corresponding certificates as a valid, signed credential – Section 4.4 - Steve verifies the credential signature just as for any other RSA signature, by raising the signature to the issuer's public exponent (modulo its public modulus) and checking that the value equals the product of certificate hashes - Steve forwards the product of hashes and the signature to the issuer for verification. Note that this product of hashes does not reveal the credentials themselves to the issuer, and thus preserves the privacy of both Alice and Steve).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Holt. The motivation for doing so is to allow the system to use bit commitments to create selective disclosure credentials which limit what portions of a credential the holder must reveal (Abstract – Holt).
Regarding claim 10
Hawkes further teaches
transmit, to a third server, a request to access another service associated with another attribute of the plurality of attributes; receive, from the third server, a request for verification of the other attribute (¶ 0044 - FIG. 6, which discloses further components of the preferred TMF 14 and mobile device 12 that are used when a ticket is to be presented for access, and which assumes, for completeness, that encryption has been employed. When a user desires access to an entity associated with the TMF 14, the user selects the appropriate ticket (with ticket index) using any convenient mobile device 12 input apparatus ( e.g., keypad) and then manipulates the mobile device 12 as appropriate to transmit the ticket index - ¶0048 - Once decrypted, the ticket index 20 is used by the TMF 14 to selectively grant access to the entity to which the ticket index corresponds. To do this, the TMF 14 can first determine whether the ticket index 20 is valid by determining whether it exists in the ticket database 16 – ¶ 0035 Turning to the details of FIG. 4, as shown the TMF 14 can include a ticket database 16 that stores ticket data 18 indexed by ticket indices 20. Thus, each preferred, nonlimiting digital ticket 21 includes ticket data, i.e., information regarding what the ticket is for ( e.g., entry into a particular entity or group of entities), along with a ticket index, also referred to as a booking number or ticket number. However, "digital ticket" can refer simply to the ticket index. If desired, a single ticket might be assigned more than one ticket index, so that if need be the same ticket, in the form of its indices, may be transmitted more than once ( e.g., a second time for confirmation) without having to use the same index and, hence, give an eavesdropper the opportunity to re-use a ticket. )
transmit, responsive to the request, another portion of the digital pass that include the other attribute to the third server for verification of the other attribute [..]; and access the other service via the third server based at least in part on transmitting the at least the other portion of the digital pass to the third server(¶ 0048 - the ticket index 20 is used by the TMF 14 to selectively grant access to the entity to which the ticket index corresponds. To do this, the TMF 14 can first determine whether the ticket index 20 is valid by determining whether it exists in the ticket database 16. If the ticket index is valid, the TMF 14 can determine whether the ticket index 20 has been used already ( as might be indicated by, e.g., a "used" flag), granting access – Claim 1- using at least the portion, selectively granting, to a user of the mobile device, access to an entity associated with the verifier – Claim 12 - determining whether at least the portion of the digital ticket matches at least one entry in a database accessible to the verifier; determining whether the digital ticket has been used; and only if the portion matches at least one entry in the database and the ticket has not yet been used or voided, granting access to the entity – ¶ 0005 - selectively grants access, wherein access denotes access to goods, services, data or whatever is associated with the digital ticket – ¶ 0031 - The particular entity, access to which is controlled by the TMF, can take any suitable form, e.g., the entity might be a movie theater, with successful presentation of a digital ticket resulting in the automatic or manual unlocking of an entrance door – See ¶ 0030-0031, ¶ 0044, ¶ 0050).
However, Hawkes does not explicitly teach wherein the other portion of the digital pass includes the digital signature associated with the digital pass
Holt teaches
wherein the other portion of the digital pass includes the digital signature associated with the digital pass (Section -1 - When Alice shows some subset of the credentials to Steve, Steve checks that all the IDs match, ensuring that all the credentials were in fact issued to the same person. Alice also reveals the preimages of the selective disclosure attributes in each credential which she wishes to show to Steve. If Alice later shows credentials from the same set to someone else, that person could collude with Steve and determine that they both were dealing with the same person – Section 4.2 - . Alice can then unblind the signature and use it along with the corresponding certificate as a valid, signed credential – Section 4.3 - Steve verifies the credential signature just as for any other RSA signature, by raising the signature to the issuer's public exponent (modulo its public modulus) and checking that the value equals the product of certificate hashes).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Holt. The motivation for doing so is to allow the system to use bit commitments to create selective disclosure credentials which limit what portions of a credential the holder must reveal (Abstract – Holt) .
Regarding claim 21
Hawkes teaches a non-transitory computer-readable medium storing instructions that, when executed by a processor, causes the processor to perform operations comprising:
receiving a digital pass from a first server, wherein the digital pass comprises a plurality of attributes (¶ 0005 - issuer generating a digital ticket associated with a verifier. The issuer is authorized by the verifier to generate such digital tickets. The method also includes providing the ticket to a portable mobile device – ¶0033 - The digital tickets may be provided to the user of the mobile device 12 by voice, printed paper, or email – ¶ 0035 - each preferred, nonlimiting digital ticket 21 includes ticket data, i.e., information regarding what the ticket is for ( e.g., entry into a particular entity or group of entities), along with a ticket index, also referred to as a booking number or ticket number );
transmitting, to a second server, a request to access a service associated with an attribute of the plurality of attributes of the digital pass (¶ 0044 - FIG. 6, which discloses further components of the preferred TMF 14 and mobile device 12 that are used when a ticket is to be presented for access, and which assumes, for completeness, that encryption has been employed. When a user desires access to an entity associated with the TMF 14, the user selects the appropriate ticket (with ticket index) using any convenient mobile device 12 input apparatus ( e.g., keypad) and then manipulates the mobile device 12 as appropriate to transmit the ticket index - ¶0048 - Once decrypted, the ticket index 20 is used by the TMF 14 to selectively grant access to the entity to which the ticket index corresponds. To do this, the TMF 14 can first determine whether the ticket index 20 is valid by determining whether it exists in the ticket database 16) ;
receiving, from the second server, a request for verification of the attribute( ¶ 0048 - if the ticket index is not initially found, the TMF 14 can request the mobile device 12 to retransmit, in which case one of the alternate ticket indices associated with the ticket ( as mentioned above) can be transmitted In addition to the above, if desired, to foil a "false attack" that might arise by an eavesdropper controlling the receiving microphone and intercepting a ticket for later reuse, authentication information ( e.g., time and/or location) can also be transmitted by the mobile device 12 and checked by the TMF 14 before granting access);
transmitting, responsive to the request, a portion of the digital pass that includes the attribute to the second server for verification of the attribute [..]; and accessing the service via the second server based at least in part on transmitting the portion of the digital pass to the second server (¶ 0048 - the ticket index 20 is used by the TMF 14 to selectively grant access to the entity to which the ticket index corresponds. To do this, the TMF 14 can first determine whether the ticket index 20 is valid by determining whether it exists in the ticket database 16. If the ticket index is valid, the TMF 14 can determine whether the ticket index 20 has been used already ( as might be indicated by, e.g., a "used" flag), granting access – Claim 1- using at least the portion, selectively granting, to a user of the mobile device, access to an entity associated with the verifier – Claim 12 - determining whether at least the portion of the digital ticket matches at least one entry in a database accessible to the verifier; determining whether the digital ticket has been used; and only if the portion matches at least one entry in the database and the ticket has not yet been used or voided, granting access to the entity – ¶ 0005 - selectively grants access, wherein access denotes access to goods, services, data or whatever is associated with the digital ticket – ¶ 0031 - The particular entity, access to which is controlled by the TMF, can take any suitable form, e.g., the entity might be a movie theater, with successful presentation of a digital ticket resulting in the automatic or manual unlocking of an entrance door – See ¶ 0044).
However, Hawkes does not explicitly teach
wherein the at least a portion of the digital pass includes a digital signature associated with the digital pass and the portion of the digital pass excludes other attributes of the plurality of attributes that are unassociated with the service, and the attribute is verifiable by the second server based at least in part on the digital signature and without obtaining any of the excluded other attributes of the digital pass;
Holt teaches
wherein the at least a portion of the digital pass includes a digital signature associated with the digital pass and the portion of the digital pass excludes other attributes of the plurality of attributes that are unassociated with the service, and the attribute is verifiable by the second server based at least in part on the digital signature and without obtaining any of the excluded other attributes of the digital pass (Section 1 - Alice wishes to obtain a service from Steve, a server. Steve will only provide the service if Alice can demonstrate certain attributes about herself as attested by credential issuing authorities. Alice is willing to prove these attributes, but doesn't want Steve to get any additional information about her, even if Steve works together with the credential issuers - If Alice doesn't choose to reveal the value of a selective disclosure field, Steve doesn't learn anything about that value - Section 3.1.1 - A selective disclosure credential has several attributes. When the user shows the credential to a verifier, she can choose to reveal only some of the attributes to the verifier – Section 4 - Alice may have several credentials issued by different issuers. For example, the state might issue her driver's license, while her school issues her student identification .Alice can then unblind the credentials and show them to obtain services – Notes - She sends Steve the unblinded signature, the certificates which were signed, and the values for the selective disclosure fields she wishes to reveal (along with the random strings used in commit()) – Section 4.2 - Alice can then unblind the signature and use it along with the corresponding certificates as a valid, signed credential – Section 4.6 - Steve verifies the credential signature just as for any other RSA signature, by raising the signature to the issuer's public exponent (modulo its public modulus) and checking that the value equals the product of certificate hashes - Steve forwards the product of hashes and the signature to the issuer for verification. Note that this product of hashes does not reveal the credentials themselves to the issuer, and thus preserves the privacy of both Alice and Steve).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Holt. The motivation for doing so is to allow the system to use bit commitments to create selective disclosure credentials which limit what portions of a credential the holder must reveal (Abstract – Holt) .
Regarding claim 22
Hawkes further teaches
transmitting, to a third server, a request to access another service associated with another attribute of the plurality of attributes; receiving, from the third server, a request for verification of the other attribute (¶ 0044 - FIG. 6, which discloses further components of the preferred TMF 14 and mobile device 12 that are used when a ticket is to be presented for access, and which assumes, for completeness, that encryption has been employed. When a user desires access to an entity associated with the TMF 14, the user selects the appropriate ticket (with ticket index) using any convenient mobile device 12 input apparatus ( e.g., keypad) and then manipulates the mobile device 12 as appropriate to transmit the ticket index - ¶0048 - Once decrypted, the ticket index 20 is used by the TMF 14 to selectively grant access to the entity to which the ticket index corresponds. To do this, the TMF 14 can first determine whether the ticket index 20 is valid by determining whether it exists in the ticket database 16 – ¶ 0035 Turning to the details of FIG. 4, as shown the TMF 14 can include a ticket database 16 that stores ticket data 18 indexed by ticket indices 20. Thus, each preferred, nonlimiting digital ticket 21 includes ticket data, i.e., information regarding what the ticket is for ( e.g., entry into a particular entity or group of entities), along with a ticket index, also referred to as a booking number or ticket number. However, "digital ticket" can refer simply to the ticket index. If desired, a single ticket might be assigned more than one ticket index, so that if need be the same ticket, in the form of its indices, may be transmitted more than once ( e.g., a second time for confirmation) without having to use the same index and, hence, give an eavesdropper the opportunity to re-use a ticket. )
transmitting, responsive to the request, another portion of the digital pass that include the other attribute to the third server for verification of the other attribute [..]; and accessing the other service via the third server based at least in part on transmitting the at least the other portion of the digital pass to the third server(¶ 0048 - the ticket index 20 is used by the TMF 14 to selectively grant access to the entity to which the ticket index corresponds. To do this, the TMF 14 can first determine whether the ticket index 20 is valid by determining whether it exists in the ticket database 16. If the ticket index is valid, the TMF 14 can determine whether the ticket index 20 has been used already ( as might be indicated by, e.g., a "used" flag), granting access – Claim 1- using at least the portion, selectively granting, to a user of the mobile device, access to an entity associated with the verifier – Claim 12 - determining whether at least the portion of the digital ticket matches at least one entry in a database accessible to the verifier; determining whether the digital ticket has been used; and only if the portion matches at least one entry in the database and the ticket has not yet been used or voided, granting access to the entity – ¶ 0005 - selectively grants access, wherein access denotes access to goods, services, data or whatever is associated with the digital ticket – ¶ 0031 - The particular entity, access to which is controlled by the TMF, can take any suitable form, e.g., the entity might be a movie theater, with successful presentation of a digital ticket resulting in the automatic or manual unlocking of an entrance door – See ¶ 0030-0031, ¶ 0044, ¶ 0050).
However, Hawkes does not explicitly teach wherein the other portion of the digital pass includes the digital signature associated with the digital pass
Holt teaches
wherein the other portion of the digital pass includes the digital signature associated with the digital pass (Section -1 - When Alice shows some subset of the credentials to Steve, Steve checks that all the IDs match, ensuring that all the credentials were in fact issued to the same person. Alice also reveals the preimages of the selective disclosure attributes in each credential which she wishes to show to Steve. If Alice later shows credentials from the same set to someone else, that person could collude with Steve and determine that they both were dealing with the same person – Section 4.2 - . Alice can then unblind the signature and use it along with the corresponding certificate as a valid, signed credential – Section 4.4 - Steve verifies the credential signature just as for any other RSA signature, by raising the signature to the issuer's public exponent (modulo its public modulus) and checking that the value equals the product of certificate hashes).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Holt. The motivation for doing so is to allow the system to use bit commitments to create selective disclosure credentials which limit what portions of a credential the holder must reveal (Abstract – Holt) .
Regarding claim 25
Hawkes does not explicitly teach
wherein the digital signature is generated with a private key associated with the digital pass and the digital signature is verified by a public key associated with the digital pass
However, Holt further teaches
wherein the digital signature is generated with a private key associated with the digital pass and the digital signature is verified by a public key associated with the digital pass ( Section 3.1 The issuer signs the request by hashing the document with a collision-resistant one-way function and signing the hash with his private key. Later the user can show the signed certificate to a verifier, who verifies that the certificate is valid. - Section 4.3 - certificate contain a public key whose corresponding private key is known to the rightful certificate owner. This allows Alice to show a certificate to Steve and prove her ownership of it. She can do this by creating a new key pair whose public key will be included in each credential in her set. She stores it as a selective disclosure value in her credentials so that Izzy doesn't see it when signing them. Later she'll reveal it to Steve when he demands that she prove ownership of her credentials).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Holt. The motivation for doing so is to allow the system to use bit commitments to create selective disclosure credentials which limit what portions of a credential the holder must reveal (Abstract – Holt) .
Regarding claim 27
Hawkes further teaches wherein transmitting the portion of the digital pass (¶ 0048, Claim 12).
However, Hawkes does not explicitly teach
receiving a selection of the attribute from the plurality of attributes from a user.
Holt teaches
receiving a selection of the attribute from the plurality of attributes from a user (Abstract - Our system uses bit commitments to create selective disclosure credentials which limit what portions of a credential the holder must reveal – Section 1 - If Alice doesn't choose to reveal the value of a selective disclosure
field, Steve doesn't learn anything about that value. But if she does choose to reveal such a field, Steve can verify that she isn't lying about its value. Section 3.1.1 - selective disclosure credential has several attributes. When the user shows the credential to a verifier, she can choose to reveal only some of the
attributes to the verifier.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Holt. The motivation for doing so is to allow the system to use bit commitments to create selective disclosure credentials which limit what portions of a credential the holder must reveal (Abstract – Holt) .
Claims 3,11 are rejected under 35 U.S.C. 103 as being unpatentable over Hawkes in view of Holt further in view of Xin et al. Publication No.US 2023/0328147 A1 ( Xin hereinafter).
Regarding claim 3
Hawkes further teaches providing the digital pass to one or more electronic devices (Fig.2). However, Hawkes does not explicitly teach the one or more electronic devices are associated with a same user account.
Xin teaches
one or more electronic devices associated with a same user account (¶ 0004 - a user has multiple personal devices (e.g., a laptop, a mobile phone, and a tablet) that are associated with the same user account, repeated notifications from the plurality of the personal devices may be received. For example, each of the laptop, the mobile phone, and the tablet may have an email application installed. The email application on each of the personal devices may be linked to the same email account – ¶ 0080 - Upon receiving the launch ticket, the resource access application 522 may initiate a secure session to the gateway service 506 and present the launch ticket. When the gateway service 506 is presented with the launch ticket, it may initiate a secure session to the appropriate resource feed and present the identity token to that feed to seamlessly authenticate the user 524. Once the session initializes, the client 501 may proceed to access the selected resource. ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Xin. The motivation for doing so is to allow seamless access to purchases and services across different devices and enhancing convenience with single login for all devices.
Regarding claim 11
Hawkes further teaches providing the digital pass to one or more electronic devices (Fig.2). However, Hawkes does not explicitly teach the one or more electronic devices are associated with a same user account.
Xin teaches
one or more electronic devices associated with a same user account (¶ 0004 - a user has multiple personal devices (e.g., a laptop, a mobile phone, and a tablet) that are associated with the same user account, repeated notifications from the plurality of the personal devices may be received. For example, each of the laptop, the mobile phone, and the tablet may have an email application installed. The email application on each of the personal devices may be linked to the same email account – ¶ 0080 - Upon receiving the launch ticket, the resource access application 522 may initiate a secure session to the gateway service 506 and present the launch ticket. When the gateway service 506 is presented with the launch ticket, it may initiate a secure session to the appropriate resource feed and present the identity token to that feed to seamlessly authenticate the user 524. Once the session initializes, the client 501 may proceed to access the selected resource).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Xin. The motivation for doing so is to allow seamless access to purchases and services across different devices and enhancing convenience with single login for all devices.
Claims 4,12,24 are rejected under 35 U.S.C. 103 as being unpatentable over Hawkes in view of Holts further in view of Gadwale et al. Publication No. US 2023/0388375 A1 ( Gadwale hereinafter)
Regarding claim 4
Hawkes further teaches transmitting the request to access the service (¶ 0048). However, Hawkes does not explicitly teach
presenting an authentication prompt; receiving an authentication input in response to the authentication prompt; determining whether the authentication input is valid based on a local authentication data; and transmitting the request to access the service in response to a determination that the authentication input is valid.
Gadwale teaches
presenting an authentication prompt; receiving an authentication input in response to the authentication prompt; determining whether the authentication input is valid based on a local authentication data; and transmitting the request to access the service in response to a determination that the authentication input is valid (¶ 0005 - authorizing the network registration request further comprises: transmitting an authorization code to the first user input device; displaying an authentication prompt on the first user input device for an authorization code input; receiving, from the first user input device, the authorization code input; determining that the authorization code matches the authorization code input; and authorizing the first network registration request for the first user – See Also ¶ 0022)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Gadwale. The motivation for doing so is to allow the system to reduce the likelihood that the user identifiers used to access the resources have not been misappropriated (Gadwale – ¶ 0002).
Regarding claim 12
Hawkes further teaches transmitting the request to access the service (¶ 0048). However, Hawkes does not explicitly teach
presenting an authentication prompt; receiving an authentication input in response to the authentication prompt; determining whether the authentication input is valid based on a local authentication data; and transmitting the request to access the service in response to a determination that the authentication input is valid.
Gadwale teaches
presenting an authentication prompt; receiving an authentication input in response to the authentication prompt; determining whether the authentication input is valid based on a local authentication data; and transmitting the request to access the service in response to a determination that the authentication input is valid (¶ 0005 - authorizing the network registration request further comprises: transmitting an authorization code to the first user input device; displaying an authentication prompt on the first user input device for an authorization code input; receiving, from the first user input device, the authorization code input; determining that the authorization code matches the authorization code input; and authorizing the first network registration request for the first user – See Also ¶ 0022)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Gadwale. The motivation for doing so is to allow the system to reduce the likelihood that the user identifiers used to access the resources have not been misappropriated (Gadwale – ¶ 0002).
Regarding claim 24
Hawkes further teaches transmitting the request to access the service (¶ 0048). However, Hawkes does not explicitly teach
presenting an authentication prompt; receiving an authentication input in response to the authentication prompt; determining whether the authentication input is valid based on a local authentication data; and transmitting the request to access the service in response to a determination that the authentication input is valid.
Gadwale teaches
presenting an authentication prompt; receiving an authentication input in response to the authentication prompt; determining whether the authentication input is valid based on a local authentication data; and transmitting the request to access the service in response to a determination that the authentication input is valid (¶ 0005 - authorizing the network registration request further comprises: transmitting an authorization code to the first user input device; displaying an authentication prompt on the first user input device for an authorization code input; receiving, from the first user input device, the authorization code input; determining that the authorization code matches the authorization code input; and authorizing the first network registration request for the first user – See Also ¶ 0022)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Gadwale. The motivation for doing so is to allow the system to reduce the likelihood that the user identifiers used to access the resources have not been misappropriated (Gadwale – ¶ 0002).
Claims 6,26 are rejected under 35 U.S.C. 103 as being unpatentable over Hawkes in view of Holt further in view of Grimault et al. Publication No. US 2017/0286873 A1 (Grimault hereinafter)
Regarding claim 6
Hawkes further teaches wherein receiving the digital pass from the first server (¶ 0005). However, Hawkes does not explicitly teach
provisioning, on a secure element of a user device, the digital pass
Grimault teaches
provisioning, on a secure element of a user device, the digital pass (Abstract - A method for providing an electronic ticket by a security element associated with a mobile terminal . The ticket is stored in the mobile terminal and designed to access a service via an access control device. ¶ 0007 - “ Security element ” means , in this case , an element for storing and handling data for guaranteeing a user of the handheld device a high level of security since the data recorded in the security element is not accessible to a non - authorized user . “ User ” means the user of the handheld device , who is also the client of the ticket provider . This security element can also be a “ Secure SD Card ” removable medium or a security element integrated in the device ( “ Embedded Secure Element ” ) or else a secured area of the application processor by virtue of the use of a security technology integrated in the processor – See ¶ 0011 - . The users of such a system previously load a ticket by means of a mobile application of their handheld device which is provided with the contactless technology . The data loaded in this manner , relating to the ticket , are saved and managed in a security element associated with the handheld device)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Grimault. The motivation for doing so is to allow the system to prevent non authorized user from accessing the ticket data by guarantying a user of the handheld device a high level of security (Grimault – ¶ 0007).
Regarding claim 26
Hawkes further teaches wherein receiving the digital pass from the first server (¶ 0005). However, Hawkes does not explicitly teach
provisioning, on a secure element of a user device, the digital pass
Grimault teaches
provisioning, on a secure element of a user device, the digital pass (Abstract - A method for providing an electronic ticket by a security element associated with a mobile terminal . The ticket is stored in the mobile terminal and designed to access a service via an access control device. ¶ 0007 - “ Security element ” means , in this case , an element for storing and handling data for guaranteeing a user of the handheld device a high level of security since the data recorded in the security element is not accessible to a non - authorized user . “ User ” means the user of the handheld device , who is also the client of the ticket provider . This security element can also be a “ Secure SD Card ” removable medium or a security element integrated in the device ( “ Embedded Secure Element ” ) or else a secured area of the application processor by virtue of the use of a security technology integrated in the processor – See ¶ 0011 - . The users of such a system previously load a ticket by means of a mobile application of their handheld device which is provided with the contactless technology . The data loaded in this manner , relating to the ticket , are saved and managed in a security element associated with the handheld device)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Grimault. The motivation for doing so is to allow the system to prevent non authorized user from accessing the ticket data by guarantying a user of the handheld device a high level of security (Grimault – ¶ 0007).
Claims 8,28 are rejected under 35 U.S.C. 103 as being unpatentable over Hawkes in view of Holt further in view of Danielson et al. Publication No. US 2020/0357236 A1 (Danielson hereinafter)
Regarding claim 8
Hawkes does not explicitly teach
receiving, from the first server, an indication of a modification of the plurality of attributes; and modifying the plurality of attributes based on the indication of the modification.
However, Danielson teaches
receiving, from the first server, an indication of a modification of the plurality of attributes; and modifying the plurality of attributes based on the indication of the modification (¶ 0066 - the game/event management instruction set 152 may notify the payout reconciliation instruction set 156, thereby enabling the payout reconciliation instruction set 156 to update the wager management database 176 and send event notification messages to the gaming machine 108, wager terminal 112, digital ticket management server 116, and/or mobile device 160 to notify such devices of the event outcome and the related outcome of the wager( s) placed on the event – ¶ 0107 - the method may then continue with the mobile device 160 causing appropriate electronic records associated with affected ticket to be updated based on the event outcome (step 536)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Danielson The motivation for doing so is to allow the system to update the ticket based on the event outcome (Danielson - ¶ 0107).
Regarding claim 28
Hawkes does not explicitly teach
receiving, from the first server, an indication of a modification of the plurality of attributes; and modifying the plurality of attributes based on the indication of the modification.
However, Danielson teaches
receiving, from the first server, an indication of a modification of the plurality of attributes; and modifying the plurality of attributes based on the indication of the modification (¶ 0066 - the game/event management instruction set 152 may notify the payout reconciliation instruction set 156, thereby enabling the payout reconciliation instruction set 156 to update the wager management database 176 and send event notification messages to the gaming machine 108, wager terminal 112, digital ticket management server 116, and/or mobile device 160 to notify such devices of the event outcome and the related outcome of the wager( s) placed on the event – ¶ 0107 - the method may then continue with the mobile device 160 causing appropriate electronic records associated with affected ticket to be updated based on the event outcome (step 536)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes to include the teachings of Danielson The motivation for doing so is to allow the system to update the ticket based on the event outcome (Danielson - ¶ 0107) .
Claim 29 is rejected under 35 U.S.C. 103 as being unpatentable over Hawkes in view of Holt further in view of Grimault further in view Radu et al. Publication No. US 2023/0298038 A1 ( Radu hereinafter).
Regarding claim 29,
Hawkes in view of Holt teaches wherein the digital signature is generated by a user device using a private key (Holt – Section 3.1 & Section 4.3)
However, Hawkes in view of Holt does not explicitly teach
a private key stored in the secure element of the user device
Radu teaches
a digital signature is generated by a user device using a private key stored in the secure element of the user device ( ¶0083 - The digital signature may be generated using a private key or a symmetric key. The private or symmetric key may be held by the digital wallet 43, the payment system 41, for example by a secure element of the payment device 411 – ¶0077 - The payment device 411 comprises a portable communications device comprising a digital device wallet 412).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hawkes in view of Holt to include the teachings of Radu. The motivation for doing so is to allow the system to improve security by preventing exposure to malware or unauthorize software.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's amendment.
Han et al. "Privacy Preserving Electronic Ticket Scheme with Attribute-Based Credentials (Year: 2021)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached Monday - Friday 8:30 AM -5:30 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, Oscar A Louie can be reached at (571) 270-1684. 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.
/YOUNES NAJI/Primary Examiner, Art Unit 2445