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 .
Information Disclosure Statement
It is noted that the applicant has listed over 1500 documents on submitted IDSs, with no explanation of relevance for any particular document or piece of information. The examiner has considered the IDS documents to the extent able to within the time allotted for a patent application examination.
Response to Amendment / Arguments
Regarding claims rejected under 35 USC 112(b):
Applicant’s amendment is considered to have overcome the applied rejection. Therefore, the rejection has been withdrawn.
Regarding claims rejected under 35 USC 103:
Applicant’s arguments, in view of the amended claim language, have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Baum-Waidner (US 2002/0046335 A1), hereinafter “BaumWaidner.”
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.
Claim(s) 1-2 and 4-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Keselman (US 2020/0382323 A1) in view of Sjoquist (US 11,324,960 B2), Cho (US 2010/0088507 A1), and BaumWaidner (US 2002/0046335 A1).
Regarding claim 1, Keselman discloses: A system for managing communication certificates for [client] devices, the system comprising:
a [client] device comprising a secure memory; and
Refer to at least [0018] and FIG. 2 of Keselman with respect to a client device.
a verification system (Central Authority in Keselman) configured to serve as an intermediary between the [client] device (Client in Keselman) and a certificate authority (Certificate Authority in Keselman);
Refer to at least FIG. 1, the abstract, [0011], and [0013] of Keselman with respect to a certificate authority having a trust relationship with a central authority, where the central authority has a different trust relationship with the client.
wherein the [client] device is configured to:
obtain a signed token comprising identity data and expiration data;
Refer to at least [0051]-[0052], [0054], and [0063] of Keselman with respect to the client device obtaining a signed token as a temporary credential, the signed token having an associated expiration date.
send [a client certificate request] and the signed token to the verification system; and wherein the verification system is configured to: receive the [client certificate request] and the signed token from the [client] device;
Refer to at least [0053]-[0054] and [0064] of Keselman with respect to the client sending a request for a certificate to the central authority, where the request includes the signed token and request data.
verify a signature of the signed token; determine that the signed token is assigned to the [client] device; determine that the signed token has not expired;
Refer to at least [0013], [0054], and [0065] of Keselman with respect to the central authority validating the certificate request and signed token (i.e., correspondence to known values at the central authority, as well as with policy).
obtain a certificate from a certificate authority using the [client certificate request] and the signed token; and send the certificate to the [client] device.
Refer to at least [0013], [0054], and [0066]-[0068] of Keselman with respect to the central authority obtaining the requested certificate from the certificate authority as part of obtaining and validating the certificate request. The requested certificate is forwarded to the client.
Keselman discusses the certificate request having request data, but does not disclose: generate a secret cryptographic key and a corresponding public cryptographic key using the identity data; store the secret cryptographic key in the secure memory; generate a certificate signing request comprising the public cryptographic key; the client certificate request further comprising a certificate signing request. Keselman also does not specify: the client device further comprising a medical device; determine, based on the signed token not being present in a listing of tokens submitted to the verification system with certificate signing requests, that the signed token has not been previously received with any other certificate signing request. However, Keselman in view of Sjoquist discloses: the client device further comprising a medical device;
Refer to at least FIG. 1-2, and Col. 4, Ll. 27-37 of Sjoquist with respect to medical devices, medical device components, and components in communication with medical devices being operable to request certificates from a carestation server.
generate a certificate signing request comprising the public cryptographic key; the client certificate request further comprising a certificate signing request.
Refer to at least FIG. 6, Col. 5, Ll. 19-32, and Col. 10, Ll. 35-65 of Sjoquist with respect to generating a certificate signing request to send to the carestation server.
The teachings of Keselman and Sjoquist both concern obtaining certificates for requesting devices, and are considered to be with the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keselman to further implement a CSR as the client device certificate request because the particular known technique (CSR standard) was recognized as part of the ordinary capabilities of one skilled in the art. It further would have been obvious to one of ordinary skill in the art to implement the teachings for medical client devices because design incentives or market forces provided a reason to make an adaptation (security and privacy as in Col. 1, Ll. 31-48 of Sjoquist), and the invention resulted from application of the prior knowledge in a predictable manner.
Keselman-Sjoquist does not disclose: generate a secret cryptographic key and a corresponding public cryptographic key using the identity data; store the secret cryptographic key in the secure memory; determine, based on the signed token not being present in a listing of tokens submitted to the verification system with certificate signing requests, that the signed token has not been previously received with any other certificate signing request. However, Keselman-Sjoquist in view of Cho discloses: generate a secret cryptographic key and a corresponding public cryptographic key using the identity data; store the secret cryptographic key in the secure memory.
Refer to at least [0040] of Cho with respect to a proxy server transmitting a reference number/authentication code to a client for creating a public/private key pair. The key pair is used in transmitting certificate request data including the public key.
The teachings of Cho likewise concern obtaining certificates for requesting devices, and are considered to be with the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keselman-Sjoquist to further implement creating a public/private key pair at the client device from a reference number/authentication code sent by the central authority for at least the purpose of additionally binding identity information and providing auditing capability.
Although Keselman-Sjoquist-Cho discusses unique identifiers and one-time use (e.g., Col. 13, Ll. 9-14 of Sjoquist), it does not specify: determine, based on the signed token not being present in a listing of tokens submitted to the verification system with certificate signing requests, that the signed token has not been previously received with any other certificate signing request. However, Keselman-Sjoquist-Cho in view of BaumWaidner discloses: determine, based on the signed token not being present in a listing of tokens submitted to the verification system with certificate signing requests, that the signed token has not been previously received with any other certificate signing request.
Refer to at least [0030]-[0031] and [0043] of BaumWaidner with respect to unique context data comprising a hash signature, where the unique context data is part of a certificate request. As part of verification for the certificate request, the verifier evaluates a list of unique context data to certificate pairs. It is determined whether a certificate has already been generated for the given unique context data.
The teachings of BaumWaidner likewise concern e-commerce transactions and obtaining certificates for requesting devices, and are considered to be with the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keselman-Sjoquist-Cho to further implement storing and evaluating a list of token to certificate pairs for at least the purpose of preventing unintentional repeat transactions and replay attacks.
Regarding claim 2, Keselman-Sjoquist-Cho-BaumWaidner discloses: The system of claim 1, further comprising a setup device (access daemon as a separate intermediary device between the client and the central authority—e.g., see [0042]-[0043] of Keselman) configured to: obtain, from the verification system, a second public key and a second secret key associated with the setup device;
Refer to at least [0045]-[0047] of Keselman with respect to the access daemon receiving asymmetric keys as a shared secret from the central authority, and for provision to storage of the client device.
establish a near-field wireless communication connection to the medical device;
Refer to at least Col. 6, Ll. 54-63 of Sjoquist with respect to NFC communication between the medical device and remote components.
generate the identity data; generate the signed token using the identity data and the second secret key; and send the signed token to the medical device.
Refer to at least [0030] of BaumWaidner with respect to a unique context data generator for generating the unique context data.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keselman-Sjoquist-Cho-BaumWaidner to implement the access daemon as a configuration apparatus with NFC for at least the purpose of ensuring a trusted environment for generating cryptographic information; because the substitution of one known element for another would have yielded predictable results to one of ordinary skill in the art at the time (i.e., network interface type).
Regarding claim 4, it is rejected for substantially the same reasons as claim 1 above (i.e., the citations to Keselman concerning token expiration and validating the signed token).
Regarding claim 5, Keselman-Sjoquist-Cho-BaumWaidner discloses: The system of claim 1, wherein the verification system is further configured to: obtain a certificate revocation list from the certificate authority; and send the certificate revocation list to a plurality of medical devices.
Refer to at least FIG. 7, Col. 5, Ll. 5-13, and Col. 11, Ll. 64-Col. 12, Ll. 19 of Sjoquist with respect to medical devices obtaining a CRL from the carestation server.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keselman-Sjoquist-Cho-BaumWaidner to further implement providing CRLs for at least the purpose of improving security by preventing use of invalid certificates.
Regarding claim 6, Keselman-Sjoquist-Cho-BaumWaidner discloses: The system of claim 1, wherein the verification system receives the certificate signing request from the medical device via a local area network of a hospital, and wherein to obtain the certificate from the certificate authority, the verification system is further configured to send the certificate signing request and the signed token to the certificate authority hosted in a cloud provider network separate from the local area network.
Refer to at least FIG. 2 and Col. 13, Ll. 36-45 of Sjoquist with respect to connecting from a local medical device network to a cloud for performing the CSR and obtaining the certificate.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keselman-Sjoquist-Cho-BaumWaidner to further implement a cloud system for the certificate authority, CSR, and certificate retrieval because the substitution of one known element for another would have yielded predictable results to one of ordinary skill in the art at the time (i.e., addressing requests and responses to a different network).
Claim(s) 7-8 and 10-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Keselman (US 2020/0382323 A1) in view of Sjoquist (US 11,324,960 B2), Cho (US 2010/0088507 A1), Mihai (US 2004/0167465 A1), and BaumWaidner (US 2002/0046335 A1).
Regarding claim 7, Keselman discloses: [A client device] comprising: a secure data store; a processor configured to:
obtain, from a setup device (access daemon as a separate intermediary device between a client and the central authority—e.g., see [0042]-[0043] and [0047] of Keselman), a signed token comprising a device identifier uniquely assigned (e.g., UUID as in [0045] of Keselman concerning policy information) to the [client device];
Refer to at least [0051]-[0052] and [0063] of Keselman with respect to a client device receiving a signed token from a central authority, the signed token including access policy data for authorization of the client.
send the [client certificate request] and the signed token to a verification system, wherein the verification system is separate from the setup device (e.g., FIG. 1 of Keselman);
Refer to at least [0053]-[0054] and [0064] of Keselman with respect to the client sending a request for a certificate to the central authority, where the request includes the signed token and request data.
receive a certificate from the verification system;
Refer to at least [0013], [0054], and [0066]-[0068] of Keselman with respect to the central authority obtaining the requested certificate and forwarding it to the client.
establish, using the certificate, a secure network connection to a device; and
Refer to at least [0068] of Keselman with respect to an example use of the certificate for SSL.
Keselman does not specify: the client device further comprising an infusion pump; generate, using the device identifier, a secret key and a corresponding public key; store the secret key in the secure data store; generate a certificate signing request comprising the public key; the client certificate request further comprising a certificate signing request; receive, via the secure network connection, data regarding a medication; and a motor controller configured to cause the medication to be administered from a medication container; that the verification system maintains a listing of tokens submitted to the verification system with certificate signing requests. However, Keselman in view of Sjoquist discloses: the client device further comprising a medical device;
Refer to at least FIG. 1-2, and Col. 4, Ll. 27-37 of Sjoquist with respect to medical devices, medical device components, and components in communication with medical devices being operable to request certificates from a carestation server.
generate a certificate signing request comprising the public key; the client certificate request further comprising a certificate signing request.
Refer to at least FIG. 6, Col. 5, Ll. 19-32, and Col. 10, Ll. 35-65 of Sjoquist with respect to generating a certificate signing request to send to the carestation server.
The teachings of Keselman and Sjoquist both concern obtaining certificates for requesting devices, and are considered to be with the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keselman to further implement a CSR as the client device certificate request because the particular known technique (CSR standard) was recognized as part of the ordinary capabilities of one skilled in the art. It further would have been obvious to one of ordinary skill in the art to implement the teachings for medical client devices because design incentives or market forces provided a reason to make an adaptation (security and privacy as in Col. 1, Ll. 31-48 of Sjoquist), and the invention resulted from application of the prior knowledge in a predictable manner.
Keselman-Sjoquist does not specify: the client device further comprising an infusion pump; generate, using the device identifier, a secret key and a corresponding public key; store the secret key in the secure data store; receive, via the secure network connection, data regarding a medication; and a motor controller configured to cause the medication to be administered from a medication container; that the verification system maintains a listing of tokens submitted to the verification system with certificate signing requests. However, Keselman-Sjoquist in view of Cho discloses: generate, using the device identifier, a secret key and a corresponding public key; store the secret key in the secure data store.
Refer to at least [0040] of Cho with respect to a proxy server transmitting a reference number/authentication code to a client for creating a public/private key pair. The key pair is used in transmitting certificate request data including the public key.
The teachings of Cho likewise concern obtaining certificates for requesting devices, and are considered to be with the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keselman-Sjoquist to further implement creating a public/private key pair at the client device from a reference number/authentication code sent by the central authority for at least the purpose of additionally binding identity information and providing auditing capability.
Keselman-Sjoquist-Cho does not specify: the client device further comprising an infusion pump; receive, via the secure network connection, data regarding a medication; and a motor controller configured to cause the medication to be administered from a medication container; that the verification system maintains a listing of tokens submitted to the verification system with certificate signing requests. However, Keselman-Sjoquist-Cho in view of Mihai discloses: the client device further comprising an infusion pump;
Refer to at least the abstract of Mihai concerning infusion pumps as a form of medical device.
Refer to at least FIG. 66 of Mihai concerning certificates for the infusion pump.
receive, via the secure network connection, data regarding a medication; and a motor controller configured to cause the medication to be administered from a medication container.
Refer to at least [0200]-[0203], and [0236] of Mihai with respect to using a patient care system (having secure communication channels as in FIG. 66-68) for ordering and administering medication via the infusion pump.
The teachings of Mihai likewise concern securing medical devices and certificates, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keselman-Sjoquist-Cho to further apply to medical devices such as infusion pumps and their secure networked operations because the substitution of one known element for another (the type of medical device) would have yielded predictable results to one of ordinary skill in the art at the time (the information being sent over secure channels established using the certificates—e.g., medication administration information for an infusion pump).
Keselman-Sjoquist-Cho-Mihai does not disclose: that the verification system maintains a listing of tokens submitted to the verification system with certificate signing requests. However, Keselman-Sjoquist-Cho-Mihai in view of BaumWaidner discloses: that the verification system maintains a listing of tokens submitted to the verification system with certificate signing requests.
Refer to at least [0030]-[0031] and [0043] of BaumWaidner with respect to unique context data comprising a hash signature, where the unique context data is part of a certificate request. As part of verification for the certificate request, the verifier evaluates a list of unique context data to certificate pairs. It is determined whether a certificate has already been generated for the given unique context data.
The teachings of BaumWaidner likewise concern e-commerce transactions and obtaining certificates for requesting devices, and are considered to be with the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keselman-Sjoquist-Cho-Mihai to further implement storing and evaluating a list of token to certificate pairs for at least the purpose of preventing unintentional repeat transactions and replay attacks.
Regarding claim 8, it is rejected for substantially the same reasons as claim 7 above (i.e., citations to Sjoquist and Mihai concerning a medical facility network).
Regarding claim 10, Keselman-Sjoquist-Cho-Mihai-BaumWaidner discloses: The infusion pump of claim 7, wherein the processor is further configured to: prefetch a certificate revocation list from the verification system;
Refer to at least FIG. 7, Col. 5, Ll. 5-13, Col. 8, Ll. 15-21, and Col. 11, Ll. 64-Col. 12, Ll. 19 of Sjoquist with respect to medical devices obtaining a CRL and caching it.
receive a second certificate from the device during establishment of the secure network connection; and determine, using the certificate revocation list, that the second certificate has not been revoked.
Refer to at least Col. 12, Ll. 20-26 of Sjoquist with respect to determining that a certificate has not been revoked, and thereby allowing establishment of secure communication between devices associated with a medical device network.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keselman-Sjoquist-Cho-Mihai to further implement providing CRLs for at least the purpose of improving security by preventing use of invalid certificates.
Regarding claim 11, Keselman-Sjoquist-Cho-Mihai-BaumWaidner discloses: The infusion pump of claim 7, wherein the processor is further configured to: prefetch a certificate revocation list from the verification system;
Refer to at least FIG. 7, Col. 5, Ll. 5-13, Col. 8, Ll. 15-21, and Col. 11, Ll. 64-Col. 12, Ll. 19 of Sjoquist with respect to medical devices obtaining a CRL and caching it.
receive, from a hospital medication safety system, a drug library (e.g., [0110], [0120], and [0152] of Mihai concerning a pharmacy system and pharmacy information) and a second certificate; determine, using the certificate revocation list, that the second certificate has not been revoked; and verify a signature of the drug library using a second public key associated with the second certificate.
Refer to at least Col. 12, Ll. 20-26 of Sjoquist with respect to determining that a certificate has not been revoked; Col. 11, Ll. 28-63 of Sjoquist with respect to validating received certificates exchanged between devices associated with a medical device network.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keselman-Sjoquist-Cho-Mihai to further implement providing CRLs for at least the purpose of improving security by preventing use of invalid certificates, and to implement certificate verification for pharmacy information for at least the purpose of validating correctness of medication information to prevent malicious fraudulent information from hurting a patient due to administering an incorrect medication.
Regarding claim 12, Keselman-Sjoquist-Cho-Mihai-BaumWaidner discloses: The infusion pump of claim 7, wherein the processor is further configured to: determine to generate a new secret key and a corresponding new public key to replace the secret key and the public key; generate the new secret key and the new public key; store the new secret key in the secure data store; delete the secret key from the secure data store; generate a second certificate signing request comprising the new public key; establish, using the certificate, a second secure connection to the verification system; send the second certificate signing request to the verification system; and receive a second certificate from the verification system in response to the second certificate signing request.
Refer to at least [0068] of Keselman with respect to replacing the certificate any time it is expected to become invalid, and retrieving valid certificates on demand for the client. The retrieval is the same as that in [0062]-[0067] for the initial certificate.
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Keselman-Sjoquist-Cho-Mihai-BaumWaidner as applied to claims 7-8 and 10-12 above, and further in view of Brockhaus (US 2022/0191191 A1).
Regarding claim 9, Keselman-Sjoquist-Cho-Mihai-BaumWaidner does not specify: wherein the processor is further configured to obtain, from the setup device, network configuration information, wherein the secure network connection is established using the network configuration information. However, Keselman-Sjoquist-Cho-Mihai-BaumWaidner in view of Brockhaus discloses: wherein the processor is further configured to obtain, from the setup device, network configuration information, wherein the secure network connection is established using the network configuration information.
Refer to at least [0060]-[0061] of Brockhaus with respect to a configuration apparatus for generating network configuration information as well as a secret.
The teachings of Brockhaus likewise concern obtaining certificates for requesting devices, and are considered to be with the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keselman-Sjoquist-Cho-Mihai-BaumWaidner to further implement providing network configuration information by the access daemon for at least the purpose of automatic network enrolment.
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Keselman-Sjoquist-Cho-Mihai-BaumWaidner as applied to claims 1-2 and 4-6 above, and further in view of Brockhaus (US 2022/0191191 A1).
Regarding claim 3, it is substantially similar to claim 9, and is therefore likewise rejected in view of Brockhaus in the same manner as claim 9 above.
Claim(s) 13-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Keselman (US 2020/0382323 A1) in view of Sjoquist (US 11,324,960 B2), and BaumWaidner (US 2002/0046335 A1).
Regarding claim 13, Keselman discloses: A computer-implemented method comprising:
as performed by a verification system (Central Authority in Keselman) comprising one or more processors configured to execute specific instructions, providing a secret key to a setup device (access daemon as a separate intermediary device between a client and the central authority—e.g., see [0042]-[0043] of Keselman), wherein the secret key is associated with a public key;
Refer to at least [0045]-[0047] of Keselman with respect to an access daemon receiving asymmetric keys as a shared secret from the central authority, and for provision to storage of the client device.
receiving, from a [client] device (Client device in Keselman), a [client certificate request] and a signed token;
Refer to at least [0053]-[0054] and [0064] of Keselman with respect to the client sending a request for a certificate to the central authority, where the request includes a signed token and request data.
verifying a signature of the signed token using the public key;
Refer to at least [0054] and [0065] of Keselman with respect to the central authority validating the signature via public key.
determining that the signed token has not expired;
Refer to at least [0051]-[0052], [0054], and [0065] of Keselman with respect to expiration date information for the signed token, and validating the signed token.
obtaining a certificate from a certificate authority on behalf of the [client] device.
Refer to at least [0013], [0054], and [0066]-[0068] of Keselman with respect to the central authority obtaining the requested certificate from a certificate authority as part of obtaining and validating the certificate request. The requested certificate is forwarded to the client.
Keselman does not specify: the client device further comprising a medical device; the client certificate request further comprising a certificate signing request; determining that the signed token is uniquely assigned to the medical device and the certificate signing request is for the medical device; determining, based on a listing of tokens submitted to the verification system, that the signed token has not been used with any prior certificate signing request. However, Keselman in view of Sjoquist discloses: the client device further comprising a medical device;
Refer to at least FIG. 1-2, and Col. 4, Ll. 27-37 of Sjoquist with respect to medical devices, medical device components, and components in communication with medical devices being operable to request certificates from a carestation server.
the client certificate request further comprising a certificate signing request;
Refer to at least FIG. 6, Col. 5, Ll. 19-32, and Col. 10, Ll. 35-65 of Sjoquist with respect to generating a certificate signing request to send to the carestation server.
The teachings of Keselman and Sjoquist both concern obtaining certificates for requesting devices, and are considered to be with the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keselman to further implement a CSR as the client device certificate request because the particular known technique (CSR standard) was recognized as part of the ordinary capabilities of one skilled in the art. It further would have been obvious to one of ordinary skill in the art to implement the teachings for medical client devices because design incentives or market forces provided a reason to make an adaptation (security and privacy as in Col. 1, Ll. 31-48 of Sjoquist), and the invention resulted from application of the prior knowledge in a predictable manner.
Keselman-Sjoquist does not specify: determining that the signed token is uniquely assigned to the medical device and the certificate signing request is for the medical device; determining, based on a listing of tokens submitted to the verification system, that the signed token has not been used with any prior certificate signing request. However, Keselman-Sjoquist in view of BaumWaidner discloses: determining that the signed token is uniquely assigned to the medical device and the certificate signing request is for the medical device;
Refer to at least [0017] and [0030]-[0031] of BaumWaidner with respect to unique context data to be verified, which may include example data such as a serial number of a requesting computer and a hash signature.
determining, based on a listing of tokens submitted to the verification system, that the signed token has not been used with any prior certificate signing request.
Refer to at least [0030]-[0031] and [0043] of BaumWaidner with respect to use of the unique context data in a certificate request. As part of verification for the certificate request, the verifier evaluates a list of unique context data to certificate pairs. It is determined whether a certificate has already been generated for the given unique context data.
The teachings of BaumWaidner likewise concern e-commerce transactions and obtaining certificates for requesting devices, and are considered to be with the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keselman-Sjoquist to further implement unique context data, as well as storing and evaluating a list of token to certificate pairs, for at least the purpose of preventing unintentional repeat transactions and replay attacks.
Regarding claim 14, it is rejected for substantially the same reasons as claim 13 above (i.e., the citations concerning expiration information).
Regarding claim 15, it is rejected for substantially the same reasons as claim 13 above (i.e., the citations to BaumWaidner concerning device-specific information as part of the unique context data; the obviousness rationale).
Regarding claim 16, it is rejected for substantially the same reasons as claim 13 above (i.e., the citations to FIG. 6, Col. 5, Ll. 19-32, and Col. 10, Ll. 35-65 of Sjoquist; the obviousness rationale).
Regarding claim 17, Keselman-Sjoquist-BaumWaidner discloses: The computer-implemented method of claim 13, further comprising: pre-fetching a certificate revocation list from the certificate authority; caching the certificate revocation list; and sending the certificate revocation list to the medical device.
Refer to at least FIG. 7, Col. 5, Ll. 5-13, Col. 8, Ll. 15-21, and Col. 11, Ll. 64-Col. 12, Ll. 19 of Sjoquist with respect to medical devices obtaining a CRL from the carestation server.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keselman-Sjoquist-BaumWaidner to further implement providing CRLs for at least the purpose of improving security by preventing use of invalid certificates.
Regarding claim 18, Keselman-Sjoquist-BaumWaidner discloses: The computer-implemented method of claim 13, further comprising:
establishing a secure connection with the medical device based at least partly on the certificate;
Refer to at least [0068] of Keselman with respect to an example use of the certificate for SSL.
receiving, from the medical device via the secure connection, a second certificate signing request; determining, based at least partly on a device identifier in the second certificate signing request matching a device identifier in the certificate used to establish the secure connection, that the second certificate signing request is for the medical device; and obtaining a second certificate from the certificate authority on behalf of the medical device.
Refer to at least [0068] of Keselman with respect to replacing the certificate any time it is expected to become invalid, and retrieving valid certificates on demand for the client. The retrieval is the same as that in [0062]-[0067] for the initial certificate.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey L Nickerson can be reached at (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/V.S/Examiner, Art Unit 2432
/SYED A ZAIDI/Primary Examiner, Art Unit 2432