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 .
DETAILED ACTION
This office action is in response to the communication filed on 6/25/2026.
Claims 1-33 have been examined.
Response to Arguments
Applicant's arguments filed 6/25/2026 have been fully considered but they are not persuasive.
The applicants argue that Drechsler describes the use of a soft token and fails to describe a physical token. The examiner notes the following statement from the instant application paragraph 00108:
“the physical security token 230a, 230 may be implemented via another device: for instance, a smartphone or another electronic device may have the capability to store encoded access information and communicate with security token readers, thereby acting as a physical security token.”
This is equivalent to the “soft token” the applicants are arguing against, and as such examiner notes that by applicants own admission, the soft token embodiment still reads on “a physical security token”. Therefore the examiner does not find the argument persuasive.
The applicants further argue that Drechsler is silent to “provisioning the physical security token”. The examiner respectfully disagrees. Fig. 15 and paragraphs 0271-0274 of Drechsler makes clear that the Secure Server Computer provisions the Auxiliary Device with the cryptogram. This meets the contested limitation. As such, the examiner does not find the argument persuasive.
The applicants argue that in Drechsler the secure server 108 does not receive any command from another remote server to encode a token. The examiner respectfully disagrees. The Token Provider Computer 110 sends a message to the Secure Server Computer 108 at step 5 of Fig. 15. While Drechsler does not explicitly call that message a “command”, the Server Computer, in response to the message received in step 5, performs the claimed operation. The operation is not performed until that message is received, and cannot be performed without receiving or before receiving that message. As such the received message falls within the scope of a command. Furthermore, the claimed “command” is nominal, as the “command” is never claimed as being followed, and nothing is claimed as being in performed in response to the command. As such, the examiner does not find the argument persuasive.
The applicants argue that in Drechsler the secure server 108 does not interact with a secure cryptoprocessor. The examiner disagrees. The applicants argue that it is the Token Provider Computer 110 that generates the cryptogram. This may be true in some embodiments but is not true in the relied upon embodiment. Paragraph 0064 makes clear that the cryptograms are generated by encrypting data. Paragraph 0274 states that secure server computer may generate the cryptogram. As such, whatever processor in the secure server computer that performs the generation of the cryptogram falls within the scope of a secure cryptoprocessor. As such, the examiner does not find the argument persuasive.
The applicants argue “in fact, Drechsler is completely silent with regards to a ‘secure cryptoprocessor”. This has been addressed in the above paragraph and as such is not persuasive.
The applicants argue that Drechsler does not disclose the obtaining step because the applicants believe that the auxiliary device of Drechsler cannot be equated with the security token reader because the auxiliary device does not detect the presence of a physical security token. The examiner disagrees. Drechsler discloses that the auxiliary device can emulate a payment card. The emulated payment card in the auxiliary device is equivalent to the claimed “physical security token”. The claims do not require “detecting the presence of a physical security token”. Rather the claim recites “obtaining, from a security token reader (e.g. 104), an indication of a presence of the physical security token being inserted into or presented to the security token reader”. The claims do not preclude the security token reader from possessing the physical security token, as is the case when the security token reader emulates the payment card. The auxiliary device emulating the payment card (again the emulation of the payment card forms the claimed physical security token) communicates with the access device. This alone shows the claimed “presence of the physical security token being inserted into or presented to the security token reader”. The response to this communication with the access device is to contact the secure server computer in step 8 of Fig. 15. This communication, because it is a result of the communication between the emulated card and the access device, is an indication of the presence. As such, the examiner does not find the argument persuasive.
The applicants argue that Drechsler does not describe provisioning the physical access token because Drechser fails to teach provisioning a physical token or encoding the physical token with the encrypted access information. The examiner disagrees. Step 9 of Drechsler clearly teaches provisioning the auxiliary device with the ARQC, which meets the contested limitation. As such, the examiner does not find the argument persuasive.
The applicants argue that the provisioning communication between the secure server and the auxiliar device is not via a secured channel. The examiner disagrees. “a secured channel” is rather broad. The term “secured” is not the same as “secure”, and can include “acquired”. The act of communicating between the devices means that a communication channel of some sort has been acquired. As such, the examiner does not find the argument persuasive.
The new claims have also been addressed below. With respect to the new claims, the examiner notes that this limitation reads “stores a location” and not “stores an indication of a location” or “stores an address” or “stores a location identifier”, etc. The examiner also notes that the claims do not preclude the secure appliance and the secure cryptoprocessor from being the same device. In this case, the secure server stores the key, and therefore the location of the key (e.g. the memory storing the key) that is used to encrypt. The secure appliance also contains its processor that performs the encryption using the key, and as such is coupled to the processor. As such, the examiner believes that the teachings of Drechsler meets the newly added claim limitations.
Because the examiner does not find the arguments persuasive, the examiner has maintained the rejections presented below.
All objections and rejections not set forth below have been withdrawn.
The examiner notes that the currently relied upon prior art rejections can be overcome by actually claiming the above argued detecting the presence, or by claiming that the access device and the physical security token are somehow distinct.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-5, 8-13, 15, 16, 18-24, and 27-33 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Drechsler et al. (US Patent Application Publication Number 2021/0344672) hereinafter referred to as Drechsler.
Regarding claim 1, Drechsler disclosed a computer-implemented method of securely provisioning a physical security token, comprising:
receiving, at a secure appliance (108) and from a remote server (e.g. 110), a command to encode a set of access information into the physical security token (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example);
generating, at the secure appliance, encrypted access information, comprising: providing the set of access information to a secure cryptoprocessor (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example); and instructing the secure cryptoprocessor to use a cryptographic key stored in the secure cryptoprocessor to encrypt the set of access information (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example);
obtaining, from a security token reader (e.g. 104), an indication of a presence of the physical security token being inserted into or presented to the security token reader (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example); and
provisioning the physical security token (e.g. 104 and emulated card) by transmitting, via a secured channel, the encrypted access information from the secure appliance to the security token reader for encoding the physical security token with the encrypted access information (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example).
Regarding claim 2, Drechsler disclosed that receiving the command to encode the set of access information comprises receiving the set of access information from the remote server, and the set of access information comprises a set of credential information and an access policy (Drechsler Fig 15 and Paragraphs 0064, 0109, 0163-0172 and 250-276 for example).
Regarding claim 3, Drechsler disclosed that the command to encode the set of access information comprises the set of access information arranged in a predetermined structure for encoding (Drechsler Fig 15 and Paragraphs 0064, 0109, 0163-0172 and 250-276 for example).
Regarding claim 4, Drechsler disclosed that providing the set of access information to the secure cryptoprocessor comprises placing the set of access information on a bus of the secure appliance via which the secure cryptoprocessor is coupled to secure appliance (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 and 0305 for example).
Regarding claim 5, Drechsler disclosed that providing the set of access information to the secure cryptoprocessor comprises transmitting the set of access information to the secure cryptoprocessor over a network (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 and 0305 for example).
Regarding claim 8, Drechsler disclosed that generating the encrypted access information comprises selecting the secure cryptoprocessor from a plurality of secure cryptoprocessors available to the secure appliance based on the command received from the remote server (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example – and Paragraph 0088).
Regarding claim 9, Drechsler disclosed that selecting the secure cryptoprocessor from the plurality of secure cryptoprocessors is further based on at least one of: a credential information received from the remote server, an access policy received from the remote server, a privilege level associated with one or more cryptographic keys stored in the secure cryptoprocessor, a load balancing factor, and a predetermined schedule (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example – and Paragraph 0088).
Regarding claim 10, Drechsler disclosed generating the encrypted access information comprises selecting the cryptographic key from a plurality of cryptographic keys stored in the secure cryptoprocessor based on the command received from the remote server (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example).
Regarding claim 11, Drechsler disclosed that selecting the cryptographic key from the plurality of cryptographic keys is further based on at least one of: a credential information received from the remote server, an access policy received from the remote server, a privilege level associated the cryptographic key, and a predetermined schedule (Drechsler Fig 15 and Paragraphs 0064, 0109, 0163-0172 and 250-276 for example).
Regarding claim 12, Drechsler disclosed that prior to transmitting the encrypted access information to the security token reader for provisioning the physical security token: determining a requested token identifier from the set of access information; obtaining a presented token identifier of the physical security token inserted into or presented to the security token reader; and transmitting the encrypted access information to the security token reader for provisioning the physical security token only when the requested token identifier matches the presented token identifier (Drechsler Fig 15 and Paragraphs 0064, 0109, 0163-0172 and 250-276 for example).
Regarding claim 13, Drechsler disclosed a computer-implemented method for securely provisioning a physical security token, comprising:
providing a remote server executing security software (Drechsler Fig 15 and Paragraphs 0064, 0109, 0163-0172 and 250-276 for example);
providing a secure appliance coupled to a security token reader and to the remote server, the secure appliance having access to a secure cryptoprocessor for encrypting information (Drechsler Fig 15 and Paragraphs 0064, 0109, 0163-0172 and 250-276 for example);
obtaining, at the remote server, a request to encode a physical security token to be assigned to a user (Drechsler Fig 15 and Paragraphs 0064, 0109, 0163-0172 and 250-276 for example);
sending, from the remote server to the secure appliance, a command to encode a set of access information into the physical security token (Drechsler Fig 15 and Paragraphs 0064, 0109, 0163-0172 and 250-276 for example);
generating, at the secure appliance, encrypted access information based on the set of access information using a cryptographic key stored in the secure cryptoprocessor (Drechsler Fig 15 and Paragraphs 0064, 0109, 0163-0172 and 250-276 for example);
obtaining, at the secure appliance, an indication from the security token reader of a presence of the physical security token being inserted into or presented to the security token reader (Drechsler Fig 15 and Paragraphs 0064, 0109, 0163-0172 and 250-276 for example); and
transmitting, via a secured channel, the encrypted access information from the secure appliance to the security token reader for encoding the physical security token with the encrypted access information (Drechsler Fig 15 and Paragraphs 0064, 0109, 0163-0172 and 250-276 for example).
Regarding claim 15, Drechsler disclosed that the set of access information is arranged in a predetermined structure for encoding, and comprises a set of credential information and an access policy (Drechsler Fig 15 and Paragraphs 0064, 0109, 0163-0172 and 250-276 for example).
Regarding claim 16, Drechsler disclosed that generating the encrypted access information comprises: providing the set of access information to the secure cryptoprocessor; and instructing the secure cryptoprocessor to use the cryptographic key stored in the secure cryptoprocessor to encrypt the set of access information (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example).
Regarding claim 18, Drechsler disclosed that generating the encrypted access information comprises selecting the secure cryptoprocessor from a plurality of secure cryptoprocessors available to the secure appliance based on the command received from the remote server (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example – and Paragraph 0088).
Regarding claim 19, Drechsler disclosed that generating the encrypted access information comprises selecting the cryptographic key from a plurality of cryptographic keys stored in the secure cryptoprocessor based on the command received from the remote server (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example).
Regarding claim 20, Drechsler disclosed that selecting the cryptographic key from the plurality of cryptographic keys is further based on at least one of: a credential information received from the remote server, an access policy received from the remote server, a privilege level associated the cryptographic key, and a predetermined schedule (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example).
Regarding claim 21, Drechsler disclosed a computer-implemented system for provisioning a physical security token, comprising: a communication interface; at least one processor; memory in communication with said at least one processor; and instructions stored in said memory, which when executed at said at least one processor causes said system to:
receive, at a secure appliance and from a remote server, a command to encode a set of access information into the physical security token (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example);
generate, at the secure appliance, encrypted access information, comprising: providing the set of access information to a secure cryptoprocessor; and instructing the secure cryptoprocessor to use a cryptographic key stored in the secure cryptoprocessor to encrypt the set of access information (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example);
obtain, from a security token reader, an indication of a presence of the physical security token being inserted into or presented to the security token reader (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example); and
provision the physical security token by transmitting, via a secured channel, the encrypted access information from the secure appliance to the security token reader for encoding the physical security token with the encrypted access information (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example).
Regarding claim 22, Drechsler disclosed that [the] command to encode the set of access information comprises the set of access information arranged in a predetermined structure for encoding (Drechsler Fig 15 and Paragraphs 0064, 0109, 0163-0172 and 250-276 for example).
Regarding claim 23, Drechsler disclosed that providing the set of access information to the secure cryptoprocessor comprises placing the set of access information on a bus of the secure appliance via which the secure cryptoprocessor is coupled to secure appliance (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 and 0305 for example).
Regarding claim 24, Drechsler disclosed that providing the set of access information to the secure cryptoprocessor comprises transmitting the set of access information to the secure cryptoprocessor over a network (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 and 0305 for example).
Regarding claim 27, Drechsler disclosed that generating the encrypted access information comprises selecting the secure cryptoprocessor from a plurality of secure cryptoprocessors available to the secure appliance based on the command received from the remote server (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example – and Paragraph 0088).
Regarding claim 28, Drechsler disclosed that selecting the secure cryptoprocessor from the plurality of secure cryptoprocessors is further based on at least one of: a credential information received from the remote server, an access policy received from the remote server, a privilege level associated with one or more cryptographic keys stored in the secure cryptoprocessor, a load balancing factor, and a predetermined schedule (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example – and Paragraph 0088).
Regarding claim 29, Drechsler disclosed that generating the encrypted access information comprises selecting the cryptographic key from a plurality of cryptographic keys stored in the secure cryptoprocessor based on the command received from the remote server (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example).
Regarding claim 30, Drechsler disclosed that selecting the cryptographic key from the plurality of cryptographic keys is further based on at least one of: a credential information received from the remote server, an access policy received from the remote server, a privilege level associated the cryptographic key, and a predetermined schedule (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example).
Regarding claims 31-33, Drechsler disclosed that the secure appliance is coupled to the secure cryptoprocessor and stores a location of the cryptographic key stored in the secure cryptoprocessor (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276) (the examiner notes that this limitation reads “stores a location” and not “stores an indication of a location”).
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 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 of this title, 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 7, 14, and 26 rejected under 35 U.S.C. 103 as being unpatentable over Drechsler.
Regarding claims 7 and 26, Drechsler did not explicitly disclose that provisioning the physical security token comprises instructing the security token reader to transmit the encrypted access information to the physical security token without storing any of the encrypted access information.
Official Notice: It was well known before the effective filing date of the invention for devices to communicate over a network, and that this involved sending data through access points and routers. As such, it would have been obvious to the person having ordinary skill in the art for device 104 and 108 to communicate over a network involving transmission through access points and routers. This would have been obvious because the person having ordinary skill in the art would have been motivated to employ common communication network practices to enable the generically taught communications in Drechsler.
In this case, the combination meets that provisioning the physical security token comprises instructing the security token reader to transmit the encrypted access information to the physical security token without storing any of the encrypted access information (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example – in this case, the access point or router through which device 104 receives the access information reads on the “security token reader”).
Regarding claims 14, Drechsler did not explicitly disclosed transmitting the encrypted access information from the secure appliance to the security token reader to cause the security token reader to transparently transmit the encrypted access information to the physical security token for encoding the physical security token.
Official Notice: It was well known before the effective filing date of the invention for devices to communicate over a network, and that this involved sending data through access points and routers. As such, it would have been obvious to the person having ordinary skill in the art for device 104 and 108 to communicate over a network involving transmission through access points and routers. This would have been obvious because the person having ordinary skill in the art would have been motivated to employ common communication network practices to enable the generically taught communications in Drechsler.
In this case, the combination meets transmitting the encrypted access information from the secure appliance to the security token reader to cause the security token reader to transparently transmit the encrypted access information to the physical security token for encoding the physical security token. (Drechsler Fig 15 and Paragraphs 0064, 0109 and 250-276 for example – in this case, the access point or router through which device 104 receives the access information reads on the “security token reader”).
Allowable Subject Matter
Claims 6, 17, and 25 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Claims 1-5, 7-16, 18-24, and 26-33 have been rejected.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 11,922,384 disclosed a system for obtaining a security token by a mobile terminal.
US 2009/0198618 disclosed a method for loading and managing and using smartcard authentication tokens and digital certificates.
US 7,121,456 disclosed a system for managing and updating card images of a smartcard in a smartcard access system.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 MATTHEW T HENNING whose telephone number is (571)272-3790. The examiner can normally be reached Monday-Friday 7AM-2PM ET.
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, William Korzuch can be reached at (571)272-7589. 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.
/MATTHEW T HENNING/ Primary Examiner, Art Unit 2491
Prosecution Insights