DETAILED ACTION
Acknowledgements
This Final Office Action is in reply to Applicant’s response filed July 9, 2026.
Claims 1, 4, 13 are currently amended.
Claims 7-10 are currently cancelled.
Claims 1-6, 11-14 are currently pending.
Claims 1-6, 11-14 have been examined.
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 .
Claim Objections
Claim 11 is objected to. Part of claim 11 appears to have been mistakenly deleted and should be restored as shown:
(Original) The method as claimed in claim 1, wherein the first and/or second user-specific data key or the first and/or second user- and system-specific data key has a limited validity period.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3, 4, and 12-14 are rejected under 35 U.S.C. 103 as being unpatentable over Radich (US 20180012032 A1) in view of Yang (US 20200322793 A1) in view of Campagna (US 20060126842 A1).
Regarding claim 1
Radich teaches:
A method for transmitting encrypted data from a medical technology system, comprising: {Abstract “A method of sharing collaborative data between registered users in an online collaboration system.”}
generating the encrypted data by applying a data key specific to the medical technology system to data generated by the medical technology system; {[0004] “A cryptographic system protects data by encrypting it with a key.”}
generating the data key specific to the medical technology system based on […] and based on a secret code generated by the data transfer authorization entity; {[0298] “As an example, the keys generated may include an asymmetric encryption key pair generated by the user key module 3a in the browser based on entropy and random sequences [secret code].”}
transmitting a first user-specific data key for decrypting the encrypted data to a first data user authorized by the central data transfer authorization entity to receive the encrypted data by the central data transfer authorization entity, wherein the first user-specific data key comprises a first user- and system-specific data key for decrypting the data encrypted by applying the data key specific to the medical technology system; {[0296] “In this embodiment, the user key passport [user-specific key] delivered to the user application [first data user] 3 after successful log-in comprises the keys required by the user application 3 to perform the encryption and decryption tasks.”; [0134] “the user key passport [user-specific key] comprises the username, the double-hashed password, the encrypted user private key, the user public key and the server public key [data key specific to the medical technology system].”}
transmitting the encrypted data from the medical technology system to the first data user; {[0335] “In this embodiment, the user application 3 on the electronic user device 5 requests the encrypted data file 10d from the server 1. The server responds by retrieving the encrypted data file 10d from the file storage database 1g and sends it to the user application 3 on the electronic user device 5 over the data network”}
decrypting the encrypted data by the first data user by applying the first user-specific data key; {[0335] “the user application 3 invokes the decryption module 3c to decrypt the enveloped data key associated with the data file 10d using the user private key 14.”}
Radich does not explicitly teach:
transmitting a second user-specific data key, which is different from the first user-specific data key, for decrypting the encrypted data from the central data transfer authorization entity to a second data user authorized by the central data transfer authorization entity to receive the encrypted data, wherein the second user-specific data key comprises a second user- and system-specific data key for decrypting the data encrypted by applying a data key specific to the medical technology system;
transmitting the encrypted data by the medical technology system or by the first data user to the second data user; and
decrypting the encrypted data by the second data user by applying the second user-specific data key.
{Abstract “Each registered user is allocated a unique [different from the first user-specific data key] asymmetric key pair comprising a user public key and a user private key for encryption and decryption of shared data content. The server is able to modify uploaded encrypted data content to enable access by multiple authorised users”}
Radich teaches sending a user key passport (user-specific key) and an encrypted data file (encrypted data) to a user application, and further teaches the user application invoking a decryption module (decrypting the encrypted data). Radich does not explicitly teach performing these steps with respect to a second user. However, Radich teaches making the data reviewable by multiple users ([0006] “It is an object of the invention to provide an online collaboration system which allows multiple users to securely upload and review data content in a collaborative manner with end-to-end encryption”). Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to repeat these three steps for a second user in order to allow multiple users to review the data content in a collaborative manner with end-to-end encryption.
Radich does not teach, however Yang teaches:
generating the data key specific to the medical technology system based on a MAC address of a computer unit of the medical technology system and […]
generating the first user- and system-specific data key based on […], the MAC address of the computer unit of the medical technology system, and a MAC address of the computer unit of the first data user;
generating the second user- and system-specific data key based on […], the MAC address of the computer unit of the medical technology system, and the MAC address of the computer unit of the second data user; {Abstract “generate a dynamic encryption key using the identifier [MAC address] of the medical device and the identifier [MAC address] of the other device, and apply the dynamic encryption key to medical data transmitted between the medical device and the other device.” [0002-0003] “The present disclosure generally relates to medical devices with limited computational capability that securely exchange data with other medical devices or general-purpose computing devices and, more particularly, to efficiently encrypting data transmitted to and from such medical devices. Certain medical devices can wirelessly transmit data to, and receive data from, other computing devices. While some of these medical devices are equipped with powerful processors and operate using a permanent power supply, other medical devices are designed to operate using little power and/or have limited computational capabilities.”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to use the key generation process of Yang, which uses the device identifiers of the communicating devices, to generate each of the keys in the method of Radich because Yang teaches it can reduce computational requirements.
Radich in view of Yang does not teach, however Campagna teaches the following bolded language:
generating the first user- and system-specific data key based on a checksum for the secret code generated by the data transfer authorization entity, […]
generating the second user- and system-specific data key based on a checksum for the secret code generated by the data transfer authorization entity, […] {Campagna Abstract “deterministic random bit generator system operating in accordance with the method, for generating cryptographic keys […] A seed [secret code] is input from an entropy source; and an initial state is generated as a function of the seed. When a request to generate a cryptographic key is received a current state, where the current state is initially the initial state, is mixed to generate an output string [checksum] and a next state and the current state is set to the next state. The requested cryptographic key is generated from the string; and output. These steps can be repeated to generate successive output strings with assurance of forward and backward secrecy. An encryption system including such a generator is also disclosed.”}
Instead of using the entropy of Radich directly to generate a key, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to use the entropy of Radich as a seed input to a deterministic random bit generator to generate the key because it would reduce the amount of entropy needed to generate bits for use as keys.
Regarding claim 3
The method as claimed in claim 1, wherein the data generated by the medical technology system comprises a data type selected from the data types consisting of: machine data, measurement data from a region of interest, and medical image data.
This is non-functional descriptive material not given patentable weight. This claim merely describes the content of data which has no functional effect on the claimed method.
Regarding claim 4
Radich teaches:
The method as claimed in claim 1, wherein:
the first user-specific data key comprises a first data key pair with a first private data key and a first public data key, {[0134] “the user key passport [user-specific key] comprises the username, the double-hashed password, the encrypted user private key, the user public key and the server public key.”}
the second user-specific data key comprises a second data key pair with a second private data key and a second public data key, and {[0134] “the user key passport [user-specific key] comprises the username, the double-hashed password, the encrypted user private key, the user public key and the server public key.”}
the method further comprises:
transmitting the first public data key by the first data user to the medical technology system, {[0292] “Next, the user application program is configured to generate a user key passport which comprises the username, the double-hashed password, encrypted user private key 14, user public key 12, and a server public key 13. The user key passport is sent [transmitting] to the server [medical technology system]”}
encrypting the data from the medical technology system with the first public data key before being transmitted to the first data user, {[0072-0074] “request and receive [transmitted] an item of encrypted data from the sever over the data network in response to user interaction with the user device, the registered user being authorised to access the item of encrypted data, the encrypted data comprising: […] an associated enveloped data key comprising encrypted versions of the data key generated by asymmetric encryption of the data key with each of the user public keys of authorized registered users that have been granted access to the item of encrypted data content and a server public key respectively;” [0217] “The phrase ‘digital enveloping’ or term ‘enveloping’ as used in this specification and claims are intended to mean, unless the context suggests otherwise, an encryption method, algorithm or process in which a single data key, which is used to symmetrically encrypt a data file or data content, is itself asymmetrically encrypted using one or more public keys to generate an envelope comprising a number of encrypted versions of the data key. Any one of the private keys associated with the public key(s) in the encryption envelope can decrypt and reveal the single data key, which in turn can be used to decrypt the data file or data content.”}
Radich teaches part of the data received (transmitted to) by the user is an “enveloped data key”, which Radich further defines as a symmetric encryption key which has been encrypted using the user’s public key.
decrypting the encrypted data by the first data user after receipt with the first private data key, {[0217] “The phrase ‘digital enveloping’ or term ‘enveloping’ as used in this specification and claims are intended to mean, unless the context suggests otherwise, an encryption method, algorithm or process in which a single data key, which is used to symmetrically encrypt a data file or data content, is itself asymmetrically encrypted using one or more public keys to generate an envelope comprising a number of encrypted versions of the data key. Any one of the private keys associated with the public key(s) in the encryption envelope can decrypt and reveal the single data key, which in turn can be used to decrypt the data file or data content.”}
transmitting the second public data key by the second data user to the medical technology system or to the first data user,
encrypting the encrypted data with the second public data key before transmitting to the second data user, and
decrypting the encrypted data by the second data user after receipt with the second private data key.
The above three steps are merely repeating the previous three steps with respect to a second user. See claim 1 regarding why Radich implies the same steps for a second user.
Regarding claim 12
Radich teaches:
The method as claimed in claim 1, wherein the first and/or second user-specific data key or the first and/or second user- and system-specific data key are assigned to a specific authorization level. {[0014] “storing the re-encrypted converted data content with an associated new or modified enveloped data key or keys on the server to enable access to the data content by the first user and the one or more additional authorized users using their respective user private keys.”; [0278] “adding or removing of registered users to the list of authorized reviewers of a data file”}
This limitation does not claim a method step. Whether or not the keys are assigned to a specific authorization level does not affect the performance of any method step. This limitation is therefore not given patentable weight. However, Radich teaches users, and therefore their corresponding keys, being added to a list representing authorization to access particular data, which reads on assigning a specific authorization level.
Regarding claims 13-14
Claims 13-14 are similar in scope to claim 1 and are treated the same with respect to prior art rejections.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Radich in view of Yang in view of Campagna as applied to claim 1 above, and further in view of Lauter (US 20100246827 A1).
Regarding claim 2
Radich teaches:
The method as claimed in claim 1, wherein:
[…] and a different second user-specific data key, which is different from the first user-specific data key, and
This limitation is already listed in claim 1, and is addressed there.
the method further comprises:
transmitting the other second user-specific data keys to each of the different second data users by the central data transfer authorization entity, {[0006] “It is an object of the invention to provide an online collaboration system which allows multiple users to securely upload and review data content in a collaborative manner with end-to-end encryption, or to at least provide the public with a useful choice.”}
This is merely extending the method of claim 1 to additional users (different second data users). Since Radich teaches the online collaboration system involving “multiple users”, it would have been obvious to extend it to more than two users.
transmitting the encrypted data by the medical technology system or by the first data user to the respective second data user, and
This limitation is already listed in claim 1, and is addressed there.
decrypting the encrypted data by the respective second data user by applying the respective second user-specific data key.
The users decrypting the data using their user specific keys is addressed above with respect to claim 1.
Radich in view of Yang in view of Campagna does not teach, however Lauter teaches:
the second user-specific data key has a plurality of different data keys, and the second data user has a plurality of different data users {[0005-0006] “In accordance therewith and to other related ends, an architecture can obtain a root key or construct the root key based upon information (e.g., password or other data) provided by a user. The root key can be employed to derive a private set of decryption keys [plurality of different data keys], each of which conform to a hierarchy associated with encrypted data of the user. Moreover, each decryption key can be endowed with encryption capabilities that are based upon or defined or described by the hierarchy. For example, a particular decryption key's location or assignment within the hierarchy can determine the encrypted data associated with the user [different data users] that can be decrypted by that decryption key.”}
“The second data user has a plurality of different data users” is not a step, nor does it affect the performance of any claimed method step. It therefore is not given patentable weight.
Additionally, “the second user-specific data key has a plurality of different data keys” is also not a step. It merely claims the content of data (the second user-specific data key). The only functional use of the second user-specific data key in the claim is for decrypting the encrypted data. Therefore, this language is not given patentable weight.
However, Lauter teaches the above language. Lauter teaches a root key (second user-specific data key) which comprises a set of decryption keys (plurality of different data keys), and it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to use the hierarchical root key taught by Lauter as the unique user key in the method of Radich because it would have the advantage of allowing the user to provide granular access to the data to others ([0008] “Moreover, in addition to controlling access to data by key distribution, the user can further leverage the hierarchy (or a language feature or grammar related thereto) to provide a robust policy defining various patterns of access associated with the hierarchy or the decryption keys.”).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Radich in view of Yang in view of Campagna as applied to claim 1 above, and further in view of Mistry (US 20180367530 A1).
Regarding claim 5
Radich teaches:
The method as claimed in claim 1, wherein the method further comprises:
encrypting the data from the medical technology system by the medical technology system […] before transmitting to the first data user,
decrypting the encrypted data with the first private data key.
The above two limitations are addressed in claim 1.
after receiving the encrypted data, requesting by the first data user a first private data key from the central data transfer authorization entity, and {[0296] “In this embodiment, the user key passport delivered to the user application [first data user] 3 after successful log-in [request] comprises the keys required by the user application 3 to perform the encryption and decryption tasks.”; [0134] “the user key passport comprises the username, the double-hashed password, the encrypted user private key, the user public key and the server public key.”}
Radich in view of Yang in view of Campagna does not teach, however Mistry teaches the following bolded language:
transmitting a pool of public data keys by the central data transfer authorization entity to the medical technology system, {Abstract “Technology for providing secure communications between a user device and a secure server, in which a user device [medical technology system] performs a certificate pinning operation by requesting and receiving a set [pool] of public key certificates for the secure server from a dynamic host configuration protocol (DHCP) server [central data transfer authorization entity].”}
encrypting the data from the medical technology system by the medical technology system with one of the public data keys of the pool before transmitting to the first data user, {Abstract “In response to the current public key certificate of the secure server matching one of the public key certificates in the set of public key certificates for the secure server received from the DHCP server, the authenticity of the secure server is confirmed and communications are permitted between the user device and the secure server.”; [0034] “The public key of a public key certificate for Secure Server 104, and/or other information contained in the certificate, may be used [encrypting the data] by User Device 100 to establish a secure communication channel with Secure Server”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to add to the method of Radich the requesting of public key certificates from a DHCP server as well as from the other party to the communication so that the certificates can be compared and “the authenticity of the secure server is confirmed” and secure communications are ensured.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Radich in view of Yang in view of Campagna in view of Mistry as applied to claim 5 above, and further in view of Isles (US 20170372042 A1).
Regarding claim 6
Radich teaches:
The method as claimed in claim 5, wherein the method further comprises:
after receiving the encrypted data, requesting by the second data user a second private data key assigned to the public second data key used by the first data user from the central data transfer authorization entity, and {[0296] “In this embodiment, the user key passport delivered to the user application [second data user] 3 after successful log-in [request] comprises the keys required by the user application 3 to perform the encryption and decryption tasks.”; [0134] “the user key passport comprises the username, the double-hashed password, the encrypted user private key, the user public key and the server public key.”}
after receipt of the second private data key, decrypting the encrypted data with the second private data key. {[0335] “the user application 3 invokes the decryption module 3c to decrypt the enveloped data key associated with the data file 10d using the user private key 14.”}
Radich in view of Yang in view of Campagna does not teach, however Mistry teaches:
transmitting by the central data transfer authorization entity a pool of public second data keys to the first data user, {Abstract “Technology for providing secure communications between a user device [first data user] and a secure server [second data user], in which a user device performs a certificate pinning operation by requesting and receiving a set of public key certificates for the secure server from a dynamic host configuration protocol (DHCP) server [central data transfer authorization entity].”}
The reasons for combining are the same given above with respect to claim 5.
Radich in view of Yang in view of Campagna in view of Mistry does not teach, however Isles teaches:
encrypting by the first data user the encrypted data with one of the public second data keys and transmitting it to the second data user, {[0005] “In an aspect of the disclosure, a method includes receiving, by a processing device of a first user device, an encrypted media item and a wrapped encryption key from a second user device via a peer-to-peer connection”; [0020] “Traditional content sharing technology may include centralized sharing systems that require a network connection with a large bandwidth in order to stream online content. In many emerging markets, the capabilities of the computing networks are limited and they often have low bandwidth, are unreliable, or unavailable. Peer-to-peer networking may allow for exchange of content when networking infrastructure or internet access is limited.”}
Radich in view of Yang in view of Campagna in view of Mistry teaches user devices sharing data through a server, but does not teach a first data user transmitting to a second data user. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to add the peer-to-peer encrypted data sharing of Isles to the method of Radich in view of Mistry in order to reduce bandwidth demands on the server.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Radich in view of Yang in view of Campagna as applied to claim 1 above, and further in view of Wikipedia “Public key certificate”.
Regarding claim 11
Radich in view of Yang in view of Campagna does not teach, however Wikipedia teaches:
The method as claimed in claim 1, wherein the first and/or second user-specific data key or the first and/or second user- and system-specific data key has a limited validity period. {Page 1 “In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key.”; Page 3 Common fields, “These are some of the most common fields in certificates. […] Not Before: The earliest time and date on which the certificate is valid. Usually set to a few hours or days prior to the moment the certificate was issued, to avoid clock skew problems. Not After: The time and date past which the certificate is no longer valid.”}
This limitation does not specify a method step, nor does it affect the performance of any method step. It therefore is not given patentable weight. However, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have a limited validity period for the keys in Radich because Wikipedia teaches public key certificates, which are used to prove validity of a public key, commonly specify “Not Before” and “Not After” fields (validity period), and this would have the advantage of not allowing a key to be used indefinitely into the future if it is compromised at some point.
Response to Arguments
Claim Objections
The objection to claim 4 is withdrawn due to the amendment.
35 USC § 112
The 112(b) rejections of claims 11 and 12 are withdrawn due to the amendment to claim 1.
35 USC § 103
Applicant has amended claim 1 to incorporate the subject matter of previous claim 10. Current claim 1 is rejected in view of the same references as previous claim 10.
Applicant argues:
The Examiner's mapping of Campagna's "output string" to the claimed "checksum" is improper. Campagna's output string is merely the output of a random bit generator, not a checksum that verifies the integrity of specific device identifiers. A checksum, as recited in claim 1, as amended, is generated based on the secret code, the MAC address of the medical technology system, and the MAC address of the user device. This checksum ensures that the key functions only for data transmission between a specific medical technology system and a specific data user. Campagna does not teach or suggest such a checksum.
The checksum recited in claim 1, as amended, serves a specific verification function. As described in the specification, "[b]y ascertaining the checksum, it is checked whether the release key defined by the secret code is applied to the correct or intended constellation of a medical technology system and a data user." As-Filed Specification, paragraph [0067]. The checksum ensures that the key is being applied to the correct device pairing. Campagna's random bit generator output has no such verification function and cannot be properly mapped to the claimed checksum.
However, the term “checksum” is broader than this argument suggests. According to Wikipedia (page 1) “A checksum is a small-sized block of data derived from another block of digital data”. This is the interpretation which has been used in the rejection. The method of Radich in view of Yang in view of Campagna uses a device identifier (reads on MAC address) as a seed to a random bit generator (reads on checksum) to generate an encryption key. The specification does not provide any support for a narrower interpretation of the term.
With respect to Applicant’s argument regarding the “verification,” it is not clear what is being referred to. There is no such claimed functionality. If Applicant means that using a checksum of the MAC addresses to generate the encryption key inherently verifies that the MAC addresses are correct since incorrect MAC addresses would result in an incorrect encryption key, then the same result is achieved by the method of Radich in view of Yang in view of Campagna since an incorrect seed to the random bit generator would result in an incorrect encryption key.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT MICHAEL DIROMA whose telephone number is (571)272-6430. The examiner can normally be reached Monday - Friday 12:30 pm - 8:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575. 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.
/S.M.D./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights