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 5/8/2026 has been entered.
Response to Amendment / Arguments
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 Barnes (“RFC 8555: Automatic Certificate Management Environment (ACME)”).
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 Barnes (“RFC 8555: Automatic Certificate Management Environment (ACME)”).
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; the token further comprising a key fingerprint; 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; verify that a fingerprint of the public cryptographic key in the certificate signing request matches the key fingerprint in the signed token. 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: the token further comprising a key fingerprint; 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; verify that a fingerprint of the public cryptographic key in the certificate signing request matches the key fingerprint in the signed token. 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: the token further comprising a key fingerprint; 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; verify that a fingerprint of the public cryptographic key in the certificate signing request matches the key fingerprint in the signed token; verify that a fingerprint of the public cryptographic key in the certificate signing request matches the key fingerprint in the signed token. However, Keselman-Sjoquist-Cho in view of Barnes discloses: the token further comprising a key fingerprint; verify that a fingerprint of the public cryptographic key in the certificate signing request matches the key fingerprint in the signed token;
Refer to at least 8.1 of Barnes stating that “[a]ll challenges defined in this document make use of a key authorization string. A key authorization is a string that concatenates the token for the challenge with a key fingerprint, separated by a "." character: keyAuthorization = token || '.' || base64url(Thumbprint(accountKey)),” where the fingerprint relies on a SHA-256 digest. As per at least 7.3.5 of Barnes, the accountKey is a public key of the client. Refer to at least pages 8, 10, and 51 with respect to challenges for CSRs.
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 11.1 and 11.3 of Barnes with respect to verifying key and token uniqueness for CSRs and challenges.
The teachings of Barnes 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 to further implement a key fingerprint as part of all challenges for at least the purpose of simplifying key management tasks since the key fingerprint is shorter than a key. It further would have been obvious to implement verifying uniqueness for at least the purpose of preventing spoofing and replication attacks.
Regarding claim 2, Keselman-Sjoquist-Cho-Barnes 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 4 and page 87 of Barnes with respect to generating cryptographic information.
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- Barnes 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-Barnes 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-Barnes 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-Barnes 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-Barnes 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 ,10-12, and 19 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), Barnes (“RFC 8555: Automatic Certificate Management Environment (ACME)”), and Mihai (US 2004/0167465 A1).
Regarding claim 7, it is substantially similar to elements of claim 1 above, but further recites: 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, which Keselman-Sjoquist-Cho-Barnes does not disclose. However, Keselman-Sjoquist-Cho-Barnes 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-Barnes 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).
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-Barnes-Mihai 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-Barnes-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-Barnes-Mihai 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-Barnes-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-Barnes-Mihai 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.
Regarding claim 19, it is rejected for substantially the same reasons as claim 7 above (i.e., the citations to Barnes concerning its key fingerprint and SHA-256).
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Keselman-Sjoquist-Cho-Barnes-Mihai as applied to claims 7-8 ,10-12, and 19 above, and further in view of Brockhaus (US 2022/0191191 A1).
Regarding claim 9, Keselman-Sjoquist-Cho-Barnes-Mihai 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-Barnes-Mihai 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-Barnes-Mihai 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-Barnes-Mihai 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 and 20 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 Barnes (“RFC 8555: Automatic Certificate Management Environment (ACME)”).
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 token further comprising a key fingerprint; 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; verifying that a fingerprint of a public cryptographic key in the certificate signing request matches the key fingerprint in the signed token. 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: the token further comprising a key fingerprint; 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; verifying that a fingerprint of a public cryptographic key in the certificate signing request matches the key fingerprint in the signed token. However, Keselman-Sjoquist in view of Barnes discloses: the token further comprising a key fingerprint; verifying that a fingerprint of a public cryptographic key in the certificate signing request matches the key fingerprint in the signed token;
Refer to at least 8.1 of Barnes stating that “[a]ll challenges defined in this document make use of a key authorization string. A key authorization is a string that concatenates the token for the challenge with a key fingerprint, separated by a "." character: keyAuthorization = token || '.' || base64url(Thumbprint(accountKey)),” where the fingerprint relies on a SHA-256 digest. As per at least 7.3.5 of Barnes, the accountKey is a public key of the client. Refer to at least pages 8, 10, and 51 with respect to challenges for CSRs.
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.
Refer to at least 11.1 and 11.3 of Barnes with respect to verifying key and token uniqueness for CSRs and challenges.
The teachings of Barnes 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 a key fingerprint as part of all challenges for at least the purpose of simplifying key management tasks since the key fingerprint is shorter than a key. It further would have been obvious to implement verifying uniqueness for at least the purpose of preventing spoofing and replication 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 Barnes 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-Barnes 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-Barnes to further implement providing CRLs for at least the purpose of improving security by preventing use of invalid certificates.
Regarding claim 18, Keselman-Sjoquist-Barnes 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.
Regarding claim 20, it is rejected for substantially the same reasons as claim 7 above (i.e., the citations to Barnes concerning its key fingerprint for all challenges, and SHA-256 digests—e.g., 8.1 of Barnes).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
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.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/V.S/Examiner, Art Unit 2432
Prosecution Insights