DETAILED ACTION
Claims 17-19 are new.
Claims 1-19 are pending.
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 .
Terminal Disclaimer
The Applicant’s name cited on the Terminal Disclaimer must be cited exactly as it is cited on the ADS and/or filing receipt, and in its entirety. If more space for Applicant’s section is required, please use smaller fonts or submit an attachment page to the Terminal Disclaimer.
Please correct and resubmit the Terminal Disclaimer. (No new fee required).
Response to Arguments
Applicant's arguments filed 07/20/2026 have been fully considered.
Regarding Applicant’s argument that Cronin does not teach “decrypt… the encrypted blood oxygen saturation data upon a match of the first and second hash”, Examiner respectfully disagrees. Cronin teaches at least in paragraph [0025] that the comparison of authentication tokens (hashes of passwords) grants authorization into the cloud-based medical service. Cronin further clarifies in paragraph [0019] that medical data is protected from being viewed by unintended recipients via the authentication system. Therefore, Cronin does teach to ““decrypt… the encrypted blood oxygen saturation data upon a match of the first and second hash” because a user/client must be authenticated before accessing cloud-based medical service. The authentication is done by comparing a first and second hash (hashes of password), allowing the user/client into the cloud-based medical service to decrypt and view the encrypted blood oxygen saturation data. The same response applies to claim 10.
Regarding Applicant’s argument that the values used for authentication are not hashes of blood saturation data, it is noted that the features upon which applicant relies are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The same response applies to claim 10.
Regarding Applicant’s argument that the prior art of record does not teach “wherein one of the one or more computer processors is an external data processing unit comprising a cellular modem” and “generate and send an acknowledgement to the pulse oximeter upon acceptance of the encrypted blood oxygen saturation data”, this argument is moot in view of new grounds of rejection, necessitated by amendments.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-6, 8-14, 16, 17, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over to Cronin et al. (US Pat. Pub. No. 20180263495) in view of Poltorak et al. (US Pat. No. 9,942,051), in further view of Gaines et al. (US Pat. Pub. No. 20120182924), and in further view of Bedingham (US Pat. Pub. No. 20200113498).
Regarding claim 1, Cronin teaches a system for improving security of cellular-enabled blood oxygen saturation data transmission by layering security, the system comprising: a pulse oximeter (Cronin [0012], e.g., A pulse oximeter sensor 100 is connected to a pulse oximeter monitor 102); a wireless network connected to the pulse oximeter (Cronin [0012], e.g., The pulse oximeter monitor 102 is connected to a cloud-based medical service 108 via the cloud or internet 106); [a private network connected to the wireless network via a persistent and fully redundant Internet Protocol Security (IPsec) Virtual Private Network (VPN) tunnel]; one or more computer processors (Cronin [Claim 15], e.g., a pulse oximetry processor that executes instructions stored in memory), [wherein one of the one or more processors is an external data processing unit comprising a cellular modem]; and a memory having stored therein machine executable instructions (Cronin [Claim 15], e.g., instructions stored in memory), that when executed by the one or more processors, cause the system to: collect, via the pulse oximeter, blood oxygen saturation data from a patient (Cronin [0013], e.g., The pulse oximeter sensor collects pulse and SpO2 data and sends the data to a pulse oximetry monitor (step 200)); encrypt, via the pulse oximeter, the blood oxygen saturation data with a shared secret (Cronin [0013], e.g., A sending security software is then executed (step 204) and the resulting encrypted data, a first unique key, and Device ID are transmitted to a cloud medical server (step 206); [0014], e.g., the sensor database is accessed and the most recent entry of the pulse data and the SpO.sub.2 data is retrieved (step 300). The retrieved data is then encrypted (step 302) and a random number generator then accesses a pulse oximeter hardware key (step 304). Then, the random number generator creates a first unique key using the pulse oximeter hardware key (step 306)), wherein encrypting the blood oxygen saturation data creates encrypted blood oxygen saturation data (Cronin [0014], e.g., The retrieved data is then encrypted); generate, via the pulse oximeter, a first hash using a signing algorithm (Cronin [0024], e.g., In an embodiment of the present invention, a server or network such as a cloud-based medical service generates a request to authenticate access…… After receiving the request to authenticate access, the user generates an authentication token; [0025], e.g., Once generated, for security purposes the authorization token may be secured by encrypting the token, digesting and encrypting the digest of the token, or cryptographically hashing the token before transmission to the requesting entity such as the medical data system or server); transmit, [via the persistent and fully redundant IPsec VPN tunnel,] the encrypted blood oxygen saturation data from the pulse oximeter to the private network (Cronin [0013], e.g., A sending security software is then executed (step 204) and the resulting encrypted data, a first unique key, and Device ID are transmitted to a cloud medical server (step 206). The cloud-based medical service then receives the encrypted data); [generate and send an acknowledgement to the pulse oximeter upon acceptance of the encrypted blood oxygen saturation data]; generate, via the private network, a second hash (Cronin [0025], e.g., Then, the secured authentication token is sent and when the recipient receives the token along with any encrypted or cleartext certification data, the component may determine the access is valid by attempting to: decrypt an encrypted token with the alleged originator's public key; decrypt an encrypted token with the alleged originator's public key; decrypt an encrypted digest with the alleged originator's public key, and comparing the result to a hashed value of the PIN, token, pin, password, code or comparing a cryptographically hashed password for the alleged originator to known pre-stored values, and if a match is found, authorization is granted); compare, via the one or more computer processors, the first hash to the second hash (Cronin [0026], e.g., The token recipient or verifier then receives and analyzes the validity of the authentication token. If the authentication token is confirmed to be authentic, such as by comparing the analyzed token data to known, pre-stored values such as the patient or the patient's health care provider's pre-stored hashed password or other patient personal information, then access is successful and the process terminates); decrypt, via the one or more computer processors, the encrypted blood oxygen saturation data upon a match of the first and second hash (Cronin [0015], e.g., In the first step, the device database is accessed and the matching entry of the pulse data and the SpO.sub.2 data for the received device ID is located (step 400). The corresponding pulse oximetry hardware key is then retrieved from the determined matching entry (step 402). Next, the received encrypted data is decrypted using the retrieved pulse oximetry hardware key step 404)), wherein decrypting the encrypted blood oxygen saturation data creates verified blood oxygen saturation data (Cronin [0015], e.g., the received encrypted data is decrypted using the retrieved pulse oximetry hardware key step 404). Then, the decrypted data is saved in the network sensor database (step 406)); and transmit, via the one or more computer processors, the verified blood oxygen saturation data to a target recipient (Cronin [0018], e.g., Confidential medical data can be transmitted and received by any number of types of devices. Examples of these devices are the medical devices that are used to measure data and conduct tests on the patient, as well as devices connected to these medical devices such as computers and storage devices).
Cronin does not explicitly teach, but Poltorak teaches a private network connected to the wireless network via a persistent and fully redundant Internet Protocol Security (IPsec) Virtual Private Network (VPN) tunnel (Poltorak Col. 31, lines 48-67, e.g., The at least one programmable automated electronic processor 3 may initiate a request to a respective one of the plurality of different endpoints 11, 12, to open a cryptographically secure tunneling protocol communication session 8, 8′ according to the public key infrastructure…… The cryptographically secure tunneling protocol communication 8, 8′ may be a virtual private network (VPN); Col. 13, lines 13-35, e.g., There are several secure VPN protocols, like IPsec, SSL and PPTP; Fig. 3.) and transmitting, via the persistent and fully redundant IPsec VPN tunnel, data to a private network (Poltorak Col. 31, lines 48-67, e.g., The cryptographically secure tunneling protocol communication 8, 8′ may be a virtual private network (VPN); Col. 13, lines 13-35, e.g., There are several secure VPN protocols, like IPsec, SSL and PPTP).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Cronin with the teachings of Poltorak with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit of securing communications over unsecured networks (Poltorak Col. 13, lines 13-35, e.g., A properly chosen, implemented, and used secure VPN protocol can provide secure communications over unsecured networks, and provide protection of confidentiality and integrity, and sender authentication to ensure privacy).
Cronin and Poltorak do not explicitly teach, but Gaines teaches wherein one of the one or more processors is an external data processing unit comprising a cellular modem (Gaines [0008], e.g., one or more medical devices including, for example, enteral feeding, thermometers, pulse oximeters…… An interface circuit is coupled to each medical device, and is configured for communicating with one of a plurality of wireless relay modules via a wireless relay network. The wireless relay modules are further configured to communicate with a remote monitoring device over an internet-accessible wireless communication network, and preferably, a wireless wide-area network (WWAN) such as a mobile telephone data network, e.g. 3G or 4G network; [0022], e.g., Relay modules 30a as depicted in FIG. 3 correspond to relay modules 30, and further include a second transceiver for wirelessly transmitting signals to and receiving signals from an access point 40 as shown in FIG. 2 via a wireless wide-area network or “WWAN”. Suitable WWANs for use with the present invention include, for example, networks based on a Global System for Mobile Communications (GSM) or Code Division Multiple Access (CDMA) cellular network or associated with the 2G, 3G, 3G Long Term Evolution, 4G, WiMAX cellular wireless standards of the International Telecommunication Union-Radiocommunication Sector (ITU-R)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the combined teachings of Cronin and Poltorak with the teachings of Gaines with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit of improving reliability and enables the use of conventional, low-cost cellular transceivers for accessing the WWAN (Gaines, e.g., [0040] By introducing relay modules 30a that are part of the ZIGBEE networks and are directly able to access off-site monitoring devices via a WWAN, access to and reliance on existing and potentially unreliable LAN facilities at a facility can be avoided. By incorporating relay features into the relay modules 30a that relay communications from a first relay module 30a to a second relay module 30a in the event that WWAN access to the first relay module 30a has been compromised, the present invention improves reliability and enables the use of conventional, low-cost cellular transceivers in the relay modules 30a for accessing the WWAN).
Cronin, Poltorak, and Gaines do not explicitly teach, but Bedingham teaches generate and send an acknowledgement [to the pulse oximeter] upon acceptance of the [encrypted blood oxygen saturation] data (Bedingham [0057], [0064], e.g., FIG. 4 illustrates a flowchart of a method 420 of receiving a wireless transmission. The method 420 can correspond to block 320 in FIG. 3. In at least one embodiment, the method 420 can occur for a packet-based wireless signal and different schemes may be used In block 428, the translation circuit 214 can instruct the wireless communication module 224 to send an acknowledgement to a sender that wireless packet was received).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the combined teachings of Cronin, Poltorak, and Gaines with the teachings of Bedingham with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit of ensuring that the data was received and in the case that the data was not received, allows the sender to retransmit the data, enhancing the overall reliability of the system.
Bedingham teaches sending and receiving an acknowledgement to a sender device upon receipt of data, but, does not specify that the sender device is a pulse oximeter nor that the data is encrypted blood oxygen saturation data , however, Cronin teaches the pulse oximeter being a sender device (Cronin [0013], e.g., The pulse oximeter sensor collects pulse and SpO2 data and sends the data to a pulse oximetry monitor (step 200). The pulse oximetry monitor then receives pulse and SpO2 data and saves the data to a sensor database (step 202). A sending security software is then executed (step 204) and the resulting encrypted data, a first unique key, and Device ID are transmitted to a cloud medical server (step 206)) and the data being encrypted blood oxygen saturation data (Cronin [0014], e.g., FIG. 3A shows a flowchart of the sending security software according to a preferred embodiment of the invention. In accordance with this embodiment, the sensor database is accessed and the most recent entry of the pulse data and the SpO.sub.2 data is retrieved (step 300). The retrieved data is then encrypted (step 302)).
Regarding claim 2, most of the limitations of this claim have been noted in the rejection of claim 1. Cronin does not explicitly teach, but Poltorak teaches wherein the shared secret is a symmetric-key algorithm comprising: a key; and a symmetric block cipher (Poltorak Col. 10, 11, lines 53-67, 1-31, e.g., AES is a block cipher with a fixed block size of 128 bits and a variable key size of 128, 192 or 256 bits).
The motivation to combine is the same as that of claim 1.
Regarding claim 3, most of the limitations of this claim have been noted in the rejection of claim 2. Cronin does not explicitly teach, but Poltorak teaches wherein the key is comprised of at least one of a 128-bit key, a 256- bit key, a 576-bit key, and a 2040-bit key (Poltorak Col. 10, 11, lines 53-67, 1-31, e.g., AES is a block cipher with a fixed block size of 128 bits and a variable key size of 128, 192 or 256 bits).
The motivation to combine is the same as that of claim 1.
Regarding claim 4, most of the limitations of this claim have been noted in the rejection of claim 2. Cronin does not explicitly teach, but Poltorak teaches wherein the symmetric block cipher is comprised of at least one of an Advanced Encryption Standard (AES) block cipher, a Blowfish block cipher, a CAST-256 block cipher, a GOST block cipher, an International Data Encryption Algorithm (IDEA) block cipher, a Rivest Cipher 6 (RC-6) block cipher, a Serpent block cipher, and a Twofish block cipher (Poltorak Col. 10, 11, lines 53-67, 1-31, e.g., AES is a block cipher with a fixed block size of 128 bits and a variable key size of 128, 192 or 256 bits).
The motivation to combine is the same as that of claim 1.
Regarding claim 5, most of the limitations of this claim have been noted in the rejection of claim 2. Cronin does not explicitly teach, but Poltorak teaches wherein the persistent and fully redundant IPsec VPN tunnel leverages the [symmetric-]key algorithm to encrypt the encrypted [blood oxygen saturation] data while travelling through the persistent and fully redundant IPsec VPN tunnel (Poltorak Col. 31, lines 48-67, e.g., The at least one programmable automated electronic processor 3 may initiate a request to a respective one of the plurality of different endpoints 11, 12, to open a cryptographically secure tunneling protocol communication session 8, 8′ according to the public key infrastructure…… The cryptographically secure tunneling protocol communication 8, 8′ may be a virtual private network (VPN); Col. 13, lines 13-35, e.g., There are several secure VPN protocols, like IPsec, SSL and PPTP; Fig. 3).
The motivation to combine is the same as that of claim 1.
Poltorak does not explicitly teach, but Cronin teaches encrypting blood oxygen saturation data using a symmetric key (Cronin [0013], e.g., A sending security software is then executed (step 204) and the resulting encrypted data, a first unique key, and Device ID are transmitted to a cloud medical server (step 206); [0014], e.g., the sensor database is accessed and the most recent entry of the pulse data and the SpO.sub.2 data is retrieved (step 300). The retrieved data is then encrypted (step 302) and a random number generator then accesses a pulse oximeter hardware key (step 304). Then, the random number generator creates a first unique key using the pulse oximeter hardware key (step 306)).
Regarding claim 6, most of the limitations of this claim have been noted in the rejection of claim 1. Cronin and Poltorak do not explicitly teach, but Gaines teaches wherein the pulse oximeter connects to the wireless network via an Access Point Name (APN) (Gaines [0008], e.g., one or more medical devices including, for example, enteral feeding, thermometers, pulse oximeters…… An interface circuit is coupled to each medical device, and is configured for communicating with one of a plurality of wireless relay modules via a wireless relay network. The wireless relay modules are further configured to communicate with a remote monitoring device over an internet-accessible wireless communication network, and preferably, a wireless wide-area network (WWAN) such as a mobile telephone data network, e.g. 3G or 4G network; [0022], e.g., Relay modules 30a as depicted in FIG. 3 correspond to relay modules 30, and further include a second transceiver for wirelessly transmitting signals to and receiving signals from an access point 40 as shown in FIG. 2 via a wireless wide-area network or “WWAN”. Suitable WWANs for use with the present invention include, for example, networks based on a Global System for Mobile Communications (GSM) or Code Division Multiple Access (CDMA) cellular network or associated with the 2G, 3G, 3G Long Term Evolution, 4G, WiMAX cellular wireless standards of the International Telecommunication Union-Radiocommunication Sector (ITU-R); Note a cellular network connects to the internet via an APN).
Regarding claim 8, most of the limitations of this claim have been noted in the rejection of claim 1. Cronin further teaches wherein the verified blood oxygen saturation data is transmitted to one or more client devices of the target recipient (Cronin [0018], e.g., Confidential medical data can be transmitted and received by any number of types of devices. Examples of these devices are the medical devices that are used to measure data and conduct tests on the patient, as well as devices connected to these medical devices such as computers and storage devices).
Regarding claim 9, most of the limitations of this claim have been noted in the rejection of claim 1. Cronin does not explicitly teach, but Poltorak teaches wherein the signing algorithm is comprised of at least one of Rivest- Shamir-Adleman (RSA) algorithms, ElGamal signature scheme, Digital Signing Algorithm (DSA), and Elliptical Curve Digital Signature Algorithm (ECDSA) (Poltorak Col. 12, lines 16-40, e.g., Public Key Infrastructure (PKI) is a policy to establish a secure method for information exchange…… Some examples of public key techniques are: Diffie-Hellmann, DSS, ElGamal, RSA, and various Elliptic Curve techniques).
The motivation to combine is the same as that of claim 1.
Regarding claim 10, Cronin teaches a method for improving security of cellular-enabled blood oxygen saturation data transmission by layering security, the method comprising: collecting, via a pulse oximeter, blood oxygen saturation data from a patient (Cronin [0013], e.g., The pulse oximeter sensor collects pulse and SpO2 data and sends the data to a pulse oximetry monitor (step 200)); encrypting, via a shared secret generated by the pulse oximeter, the blood oxygen saturation data (Cronin [0013], e.g., A sending security software is then executed (step 204) and the resulting encrypted data, a first unique key, and Device ID are transmitted to a cloud medical server (step 206); [0014], e.g., the sensor database is accessed and the most recent entry of the pulse data and the SpO.sub.2 data is retrieved (step 300). The retrieved data is then encrypted (step 302) and a random number generator then accesses a pulse oximeter hardware key (step 304). Then, the random number generator creates a first unique key using the pulse oximeter hardware key (step 306)), wherein encrypting the blood oxygen saturation data creates encrypted blood oxygen saturation data (Cronin [0014], e.g., The retrieved data is then encrypted); signing, via a signing algorithm, the encrypted blood oxygen saturation data creating a first hash (Cronin [0024], e.g., In an embodiment of the present invention, a server or network such as a cloud-based medical service generates a request to authenticate access…… After receiving the request to authenticate access, the user generates an authentication token; [0025], e.g., Once generated, for security purposes the authorization token may be secured by encrypting the token, digesting and encrypting the digest of the token, or cryptographically hashing the token before transmission to the requesting entity such as the medical data system or server); connecting, [via an Access Point Name (APN),] the pulse oximeter to a wireless network (Cronin [0012], e.g., The pulse oximeter monitor 102 is connected to a cloud-based medical service 108 via the cloud or internet 106), transmitting, [via a persistent and fully redundant Internet Protocol Security (IPsec) Virtual Private Network (VPN) tunnel,] the encrypted blood oxygen saturation data from the pulse oximeter to a private network (Cronin [0013], e.g., A sending security software is then executed (step 204) and the resulting encrypted data, a first unique key, and Device ID are transmitted to a cloud medical server (step 206). The cloud-based medical service then receives the encrypted data); receiving, via the private network, the encrypted blood oxygen saturation data (Cronin [0013], e.g., The cloud-based medical service then receives the encrypted data), wherein upon receipt of the encrypted blood oxygen saturation data, the private network generates a second hash (Cronin [0025], e.g., Then, the secured authentication token is sent and when the recipient receives the token along with any encrypted or cleartext certification data, the component may determine the access is valid by attempting to: decrypt an encrypted token with the alleged originator's public key; decrypt an encrypted token with the alleged originator's public key; decrypt an encrypted digest with the alleged originator's public key, and comparing the result to a hashed value of the PIN, token, pin, password, code or comparing a cryptographically hashed password for the alleged originator to known pre-stored values, and if a match is found, authorization is granted); [generating and sending an acknowledgement to the pulse oximeter upon acceptance of the encrypted blood oxygen saturation data]; verifying, via a comparison of the first hash and second hash, the encrypted blood oxygen saturation data (Cronin [0026], e.g., The token recipient or verifier then receives and analyzes the validity of the authentication token. If the authentication token is confirmed to be authentic, such as by comparing the analyzed token data to known, pre-stored values such as the patient or the patient's health care provider's pre-stored hashed password or other patient personal information, then access is successful and the process terminates), wherein upon a match of the first hash and the second hash, the private network decrypts the encrypted blood oxygen saturation data, creating verified blood oxygen saturation data (Cronin [0015], e.g., In the first step, the device database is accessed and the matching entry of the pulse data and the SpO.sub.2 data for the received device ID is located (step 400). The corresponding pulse oximetry hardware key is then retrieved from the determined matching entry (step 402). Next, the received encrypted data is decrypted using the retrieved pulse oximetry hardware key step 404); [0015], e.g., the received encrypted data is decrypted using the retrieved pulse oximetry hardware key step 404). Then, the decrypted data is saved in the network sensor database (step 406)); and transmitting the verified blood oxygen saturation data to a target recipient (Cronin [0018], e.g., Confidential medical data can be transmitted and received by any number of types of devices. Examples of these devices are the medical devices that are used to measure data and conduct tests on the patient, as well as devices connected to these medical devices such as computers and storage devices).
Cronin does not explicitly teach, but Poltorak teaches transmitting, via the persistent and fully redundant IPsec VPN tunnel, data to a private network (Poltorak Col. 31, lines 48-67, e.g., The cryptographically secure tunneling protocol communication 8, 8′ may be a virtual private network (VPN); Col. 13, lines 13-35, e.g., There are several secure VPN protocols, like IPsec, SSL and PPTP).
The motivation to combine Poltorak is the same as that of claim 1.
Cronin and Poltorak do not explicitly teach, but Gaines teaches connecting, via an Access Point Name (APN), the pulse oximeter to a wireless network (Gaines [0008], e.g., one or more medical devices including, for example, enteral feeding, thermometers, pulse oximeters…… An interface circuit is coupled to each medical device, and is configured for communicating with one of a plurality of wireless relay modules via a wireless relay network. The wireless relay modules are further configured to communicate with a remote monitoring device over an internet-accessible wireless communication network, and preferably, a wireless wide-area network (WWAN) such as a mobile telephone data network, e.g. 3G or 4G network; [0022], e.g., Relay modules 30a as depicted in FIG. 3 correspond to relay modules 30, and further include a second transceiver for wirelessly transmitting signals to and receiving signals from an access point 40 as shown in FIG. 2 via a wireless wide-area network or “WWAN”. Suitable WWANs for use with the present invention include, for example, networks based on a Global System for Mobile Communications (GSM) or Code Division Multiple Access (CDMA) cellular network or associated with the 2G, 3G, 3G Long Term Evolution, 4G, WiMAX cellular wireless standards of the International Telecommunication Union-Radiocommunication Sector (ITU-R); Note a cellular network connects to the internet via an APN).
The motivation to combine Gaines is the same as that of claim 1.
Cronin, Poltorak, and Gaines do not explicitly teach, but Bedingham teaches generating and sending an acknowledgement to the pulse oximeter upon acceptance of the encrypted blood oxygen saturation data (Bedingham [0057], [0064], e.g., FIG. 4 illustrates a flowchart of a method 420 of receiving a wireless transmission. The method 420 can correspond to block 320 in FIG. 3. In at least one embodiment, the method 420 can occur for a packet-based wireless signal and different schemes may be used In block 428, the translation circuit 214 can instruct the wireless communication module 224 to send an acknowledgement to a sender that wireless packet was received).
The motivation to combine Bedingham is the same as that of claim 1.
Bedingham teaches sending and receiving an acknowledgement to a sender device upon receipt of data, but, does not specify that the sender device is a pulse oximeter nor that the data is encrypted blood oxygen saturation data, however, Cronin teaches the pulse oximeter being a sender device (Cronin [0013], e.g., The pulse oximeter sensor collects pulse and SpO2 data and sends the data to a pulse oximetry monitor (step 200). The pulse oximetry monitor then receives pulse and SpO2 data and saves the data to a sensor database (step 202). A sending security software is then executed (step 204) and the resulting encrypted data, a first unique key, and Device ID are transmitted to a cloud medical server (step 206)) and the data being encrypted blood oxygen saturation data (Cronin [0014], e.g., FIG. 3A shows a flowchart of the sending security software according to a preferred embodiment of the invention. In accordance with this embodiment, the sensor database is accessed and the most recent entry of the pulse data and the SpO.sub.2 data is retrieved (step 300). The retrieved data is then encrypted (step 302)).
Regarding claim 11, the claim recites a method of the system of claim 2, and is similarly analyzed.
Regarding claim 12, the claim recites a method of the system of claim 3, and is similarly analyzed.
Regarding claim 13, the claim recites a method of the system of claim 4, and is similarly analyzed.
Regarding claim 14, the claim recites a method of the system of claim 5, and is similarly analyzed.
Regarding claim 16, the claim recites a method of the system of claim 9, and is similarly analyzed.
Regarding claim 17, Cronin and Poltorak do not explicitly teach, but Gaines teaches wherein the pulse oximeter comprises the external data processing unit comprising the cellular modem (Gaines [0008], e.g., one or more medical devices including, for example, enteral feeding, thermometers, pulse oximeters…… An interface circuit is coupled to each medical device, and is configured for communicating with one of a plurality of wireless relay modules via a wireless relay network. The wireless relay modules are further configured to communicate with a remote monitoring device over an internet-accessible wireless communication network, and preferably, a wireless wide-area network (WWAN) such as a mobile telephone data network, e.g. 3G or 4G network; [0022], e.g., Relay modules 30a as depicted in FIG. 3 correspond to relay modules 30, and further include a second transceiver for wirelessly transmitting signals to and receiving signals from an access point 40 as shown in FIG. 2 via a wireless wide-area network or “WWAN”. Suitable WWANs for use with the present invention include, for example, networks based on a Global System for Mobile Communications (GSM) or Code Division Multiple Access (CDMA) cellular network or associated with the 2G, 3G, 3G Long Term Evolution, 4G, WiMAX cellular wireless standards of the International Telecommunication Union-Radiocommunication Sector (ITU-R)).
The motivation to combine Gaines is the same as that of claim 1.
Regarding claim 19, Cronin and Poltorak do not explicitly teach, but Gaines teaches wherein the external data processing unit comprising the cellular modem transmits [the verified blood oxygen saturation] data [to a target recipient] (Gaines [0008], e.g., one or more medical devices including, for example, enteral feeding, thermometers, pulse oximeters…… An interface circuit is coupled to each medical device, and is configured for communicating with one of a plurality of wireless relay modules via a wireless relay network. The wireless relay modules are further configured to communicate with a remote monitoring device over an internet-accessible wireless communication network, and preferably, a wireless wide-area network (WWAN) such as a mobile telephone data network, e.g. 3G or 4G network).
The motivation to combine Gaines is the same as that of claim 1.
Gaines does not explicitly teach sending the verified blood oxygen saturation data to a target recipient, however, Gaines provides a system for communicating with a remote monitoring device communicate with a remote monitoring device (target recipient) over an internet-accessible wireless communication network. Cronin teaches sending verified blood oxygen saturation data (Cronin [0013], e.g., The cloud medical server then executes a network encrypting software (step 214) and generates an encrypted new data and a second unique key. The cloud-based medical service then sends back to the pulse oximeter monitor the encrypted new data and the second unique key (step 216)).
Claim(s) 7 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cronin in view of Poltorak, Gaines, and Bedingham, and in further view of Kondapavuluru et al. (US Pat. Pub. No. 20210385195), which claims foreign priority to (IN 202041023290) filed on 06/03/2020.
Regarding claim 7, most of the limitations of this claim have been noted in the rejection of claim 1. Cronin, Poltorak, Gaines, and Bedingham do not explicitly teach, but Kondapavuluru teaches wherein the persistent and fully redundant IPsec VPN tunnel is further comprised of Transport Layer Security (TLS) (Kondapavuluru [0017], e.g., a device (e.g., a client device) may selectively encrypt a packet transmitted to establish and/or communicate via a VPN. For example, the device may seek to communicate securely, via a public network, with a remote device using a tunnel by establishing a VPN tunnel (e.g., an Internet Protocol Security (IPsec) tunnel) to the remote device; [0018], e.g., In order to establish and/or communicate on the VPN tunnel, the device may transmit a packet (associated with a protocol) toward the remote device…… the device may selectively encrypt the packet using a null encryption for TLS (e.g., null cipher or no cipher, and therefore no encryption) or a combination of an encryption associated with the protocol and TLS encryption to generate an encrypted packet. The device may transmit the encrypted packet to establish or communicate via the VPN).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the combined teachings of Cronin and Poltorak with the teachings of Kondapavuluru with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit of preventing packets from being automatically dropped by the firewall (Kondapavuluru [0015], e.g., the client device may use multiple encryption techniques to prevent the packet from being dropped by the firewall). Additionally, using TLS provides an extra layer of security, which increases the overall security of the system.
Regarding claim 15, the claim recites a method of the system of claim 7, and is similarly analyzed.
Claim(s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cronin in view of Poltorak, Gaines, and Bedingham, and in further view of McKeeman et al. (US Pat. No. 9,282,495).
Regarding claim 18. Cronin, Poltorak, Gaines, and Bedingham do not explicitly teach, but McKeeman teaches wherein the cellular modem is configured to automatically connect to a slower network when a faster network is not available (McKeeman Col. 11, lines 11-19, e.g., if the network switching application 106 determines the cellular modem 102 is connected to a 4G cellular network 40, the cellular modem 102 will determine whether or not the 4G cellular network 40 is reliable (step 1020). If the cellular modem 102 finds the 4G cellular network 40 unreliable, as described in step 1010, the cellular modem 102 will disconnect from the 4G cellular network 40 and connect to the available 3G cellular network 30 (step 1012)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the combined teachings of Cronin, Poltorak, Gaines, and Bedingham with the teachings of McKeeman with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit of ensuring the availability of wireless communication by providing an alternative wireless connection.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-16 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-16 of copending Application No. 18/963,296 in view of US 20180263495 A1 to Cronin et al. (Cronin).
This is a provisional nonstatutory double patenting rejection.
18/985,958 (Instant Application)
18/963,296 (Co-pending application)
1. A system for improving security of cellular-enabled blood [oxygen saturation] data transmission by layering security, the system comprising: a pulse oximeter; a wireless network connected to the pulse oximeter; a private network connected to the wireless network via a persistent and fully redundant Internet Protocol Security (IPsec) Virtual Private Network (VPN) tunnel; one or more computer processors , wherein one of the one or more computer processors is an external data processing unit comprising a cellular modem; and a memory having stored therein machine executable instructions, that when executed by the one or more processors, cause the system to: collect, via the pulse oximeter, blood [oxygen saturation] data from a patient; encrypt, via the pulse oximeter, the blood [oxygen saturation] data with a shared secret, wherein encrypting the blood [oxygen saturation] data creates encrypted blood [oxygen saturation] data; generate, via the pulse oximeter, a first hash using a signing algorithm; transmit, via the persistent and fully redundant IPsec VPN tunnel, the encrypted blood [oxygen saturation] data from the pulse oximeter to the private network; generate and send an acknowledgement to the pulse oximeter upon acceptance of the encrypted blood oxygen saturation data; generate, via the private network, a second hash; compare, via the one or more computer processors, the first hash to the second hash; decrypt, via the one or more computer processors, the encrypted blood [oxygen saturation] data upon a match of the first and second hash, wherein decrypting the encrypted blood [oxygen saturation] data creates verified blood [oxygen saturation] data; and transmit, via the one or more computer processors, the verified blood [oxygen saturation] data to a target recipient.
1. A system for improving security of cellular-enabled blood pressure data transmission by layering security, the system comprising: an electronic blood pressure monitor; a wireless network connected to the electronic blood pressure monitor; a private network connected to the wireless network via a persistent and fully redundant Internet Protocol Security (IPsec) Virtual Private Network (VPN) tunnel; one or more computer processors; and a memory having stored therein machine executable instructions, that when executed by the one or more processors, cause the system to: collect, via the electronic blood pressure monitor, initial blood pressure measurements from a patient; encrypt, via the electronic blood pressure monitor, the initial blood pressure measurements with a shared secret, wherein encrypting the initial blood pressure measurements creates encrypted blood pressure measurements; generate, via the electronic blood pressure monitor, a first hash using a signing algorithm; transmit, via the persistent and fully redundant IPsec VPN tunnel, the encrypted blood pressure measurements from the electronic blood pressure monitor to the private network; generate, via the private network, a second hash; compare, via the one or more computer processors, the first hash to the second hash; decrypt, via the one or more computer processors, the encrypted blood pressure measurements upon a match of the first and second hash, wherein decrypting the encrypted blood pressure measurements creates verified blood pressure measurements; and transmit, via the one or more computer processors, the verified blood pressure measurements to a target recipient.
10. connecting, via an Access Point Name (APN)
2. The system of Claim 1, wherein the shared secret is a symmetric-key algorithm comprising: a key; and a symmetric block cipher.
2. The system of claim 1, wherein the shared secret is a symmetric-key algorithm comprising: a key; and a symmetric block cipher.
3. The system of Claim 2, wherein the key is comprised of at least one of a 128-bit key, a 256- bit key, a 576-bit key, and a 2040-bit key.
3. The system of claim 2, wherein the key is comprised of at least one of a 128-bit key, a 256-bit key, a 576-bit key, and a 2040-bit key.
4. The system of Claim 2, wherein the symmetric block cipher is comprised of at least one of an Advanced Encryption Standard (AES) block cipher, a Blowfish block cipher, a CAST-256 block cipher, a GOST block cipher, an International Data Encryption Algorithm (IDEA) block cipher, a Rivest Cipher 6 (RC-6) block cipher, a Serpent block cipher, and a Twofish block cipher.
4. The system of claim 2, wherein the symmetric block cipher is comprised of at least one of an Advanced Encryption Standard (AES) block cipher, a Blowfish block cipher, a CAST-256 block cipher, a GOST block cipher, an International Data Encryption Algorithm (IDEA) block cipher, a Rivest Cipher 6 (RC-6) block cipher, a Serpent block cipher, and a Twofish block cipher.
5. The system of Claim 2, wherein the persistent and fully redundant IPsec VPN tunnel leverages the symmetric-key algorithm to encrypt the encrypted blood [oxygen saturation] data while travelling through the persistent and fully redundant IPsec VPN tunnel.
5. The system of claim 2, wherein the persistent and fully redundant IPsec VPN tunnel leverages the symmetric-key algorithm to encrypt the encrypted blood pressure measurements while travelling through the persistent and fully redundant IPsec VPN tunnel.
6. The system of Claim 1, wherein the pulse oximeter connects to the wireless network via an Access Point Name (APN).
6. The system of claim 1, wherein the electronic blood pressure monitor connects to the wireless network via an Access Point Name (APN).
7. The system of Claim 1, wherein the persistent and fully redundant IPsec VPN tunnel is further comprised of Transport Layer Security (TLS).
7. The system of claim 1, wherein the persistent and fully redundant IPsec VPN tunnel is further comprised of Transport Layer Security (TLS).
8. The system of Claim 1, wherein the verified blood oxygen saturation data is transmitted to one or more client devices of the target recipient.
8. The system of claim 1, wherein the verified blood pressure measurements are transmitted to one or more client devices of the target recipient.
9. The system of Claim 1, wherein the signing algorithm is comprised of at least one of Rivest- Shamir-Adleman (RSA) algorithms, ElGamal signature scheme, Digital Signing Algorithm (DSA), and Elliptical Curve Digital Signature Algorithm (ECDSA).
9. The system of claim 1, wherein the signing algorithm is comprised of at least one of Rivest-Shamir-Adleman (RSA) algorithms, ElGamal signature scheme, Digital Signing Algorithm (DSA), and Elliptical Curve Digital Signature Algorithm (ECDSA).
10. A method for improving security of cellular-enabled blood [oxygen saturation] data transmission by layering security, the method comprising: collecting, via a pulse oximeter, blood [oxygen saturation] data from a patient; encrypting, via a shared secret generated by the pulse oximeter, the blood [oxygen saturation] data, wherein encrypting the blood [oxygen saturation] data creates encrypted blood [oxygen saturation] data; signing, via a signing algorithm, the encrypted blood [oxygen saturation] data creating a first hash; connecting, via an Access Point Name (APN), the pulse oximeter to a wireless network, transmitting, via a persistent and fully redundant Internet Protocol Security (IPsec) Virtual Private Network (VPN) tunnel, the encrypted blood [oxygen saturation] data from the pulse oximeter to a private network; receiving, via the private network, the encrypted blood [oxygen saturation] data, wherein upon receipt of the encrypted blood [oxygen saturation] data, the private network generates a second hash; generating and sending an acknowledgement to the pulse oximeter upon acceptance of the encrypted blood oxygen saturation data; verifying, via a comparison of the first hash and second hash, the encrypted blood [oxygen saturation] data, wherein upon a match of the first hash and the second hash, the private network decrypts the encrypted blood [oxygen saturation] data, creating verified blood [oxygen saturation] data; and transmitting the verified blood [oxygen saturation] data to a target recipient.
10. A method for improving security of cellular-enabled blood pressure data transmission by layering security, the method comprising: collecting, via an electronic blood pressure monitor, initial blood pressure measurements from a patient; encrypting, via a shared secret generated by the electronic blood pressure monitor, the initial blood pressure measurements, wherein encrypting the initial blood pressure measurements creates encrypted blood pressure measurements; signing, via a signing algorithm, the encrypted blood pressure measurements, creating a first hash; connecting, via an Access Point Name (APN), the electronic blood pressure monitor to a wireless network, transmitting, via a persistent and fully redundant Internet Protocol Security (IPsec) Virtual Private Network (VPN) tunnel, the encrypted blood pressure measurements from the electronic blood pressure monitor to a private network; receiving, via the private network, the encrypted blood pressure measurements, wherein upon receipt of the encrypted blood pressure measurements, the private network generates a second hash; verifying, via a comparison of the first hash to the second hash, the encrypted blood pressure measurements, wherein upon a match of the first hash and the second hash, the private network decrypts the encrypted blood pressure measurements, creating verified blood pressure measurements; and transmitting the verified blood pressure measurements to a target recipient.
11. The method of Claim 10, wherein the shared secret is a symmetric-key algorithm comprising: a key; and a symmetric block cipher.
11. The method of claim 10, wherein the shared secret is a symmetric-key algorithm comprising: a key; and a symmetric block cipher.
12. The method of Claim 11, wherein the key is comprised of at least one of a 128-bit key, a 256-bit key, a 576-bit key, and a 2040-bit key.
12. The method of claim 11, wherein the key is comprised of at least one of a 128-bit key, a 256-bit key, a 576-bit key, and a 2040-bit key.
13. The method of Claim 11, wherein the symmetric block cipher is comprised of at least one of an Advanced Encryption Standard (AES) block cipher, a Blowfish block cipher, a CAST-256 block cipher, a GOST block cipher, an International Data Encryption Algorithm (IDEA) block cipher, a Rivest Cipher 6 (RC-6) block cipher, a Serpent block cipher, and a Twofish block cipher.
13. The method of claim 11, wherein the symmetric block cipher is comprised of at least one of an Advanced Encryption Standard (AES) block cipher, a Blowfish block cipher, a CAST-256 block cipher, a GOST block cipher, an International Data Encryption Algorithm (IDEA) block cipher, a Rivest Cipher 6 (RC-6) block cipher, a Serpent block cipher, and a Twofish block cipher.
14. The method of Claim 11, wherein the persistent and fully redundant IPsec VPN tunnel leverages the symmetric-key algorithm to encrypt the encrypted blood [oxygen saturation] data while travelling through the persistent and fully redundant IPsec VPN tunnel.
14. The method of claim 11, wherein the persistent and fully redundant IPsec VPN tunnel leverages the symmetric-key algorithm to encrypt the encrypted blood pressure measurements while travelling through the persistent and fully redundant IPsec VPN tunnel.
15. The method of Claim 10, wherein the persistent and fully redundant IPsec VPN tunnel is further comprised of Transport Layer Security (TLS).
15. The method of claim 10, wherein the persistent and fully redundant IPsec VPN tunnel is further comprised of Transport Layer Security (TLS).
16. The method of Claim 10, wherein the signing algorithm is comprised of at least one of Rivest- Shamir-Adleman (RSA) algorithms, EIGamal signature scheme, Digital Signing Algorithm (DSA), and Elliptical Curve Digital Signature Algorithm (ECDSA).
16. The method of claim 10, wherein the signing algorithm is comprised of at least one of Rivest-Shamir-Adleman (RSA) algorithms, ElGamal signature scheme, Digital Signing Algorithm (DSA), and Elliptical Curve Digital Signature Algorithm (ECDSA).
Regarding claims 1, 5, 10, and 14, co-pending application (18/963,296) does not explicitly teach, but Cronin teaches the blood data being blood oxygen data (Cronin [0013], e.g., The pulse oximeter sensor collects pulse and SpO2 data and sends the data to a pulse oximetry monitor (step 200)). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the co-pending application with the teachings of Cronin with reasonable expectation of success. One of ordinary skill in the art would have been motivated to simply substitute the blood pressure data of the co-pending application with the blood oxygen saturation data of Cronin because the processing of the data itself is the same, with the only difference being the type of data.
Conclusion
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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAWRENCE TRUONG whose telephone number is (571)272-6973. The examiner can normally be reached Monday - Friday, 8:00 am - 4 pm 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, Ali Shayanfar can be reached at (571) 270-1050. 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.
/LAWRENCE TRUONG/Examiner, Art Unit 2434 /NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
Prosecution Insights