DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The 4/28/2025 IDS document comprises over 1500 references with no explanation of relevance for any particular document or piece of information, and has been considered by the examiner to the extent possible within the time allotted for examination.
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) 12-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Halageri (US 2014/0013409 A1) in view of SAML (“Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0”), Wallrabenstein (US 2017/0063559 A1), and Lee (US 2020/0356694 A1).
Regarding claim 12, Halageri discloses: A system comprising:
a plurality of [entities] (e.g., users 1-N in FIG. 1-3 of Halageri);
an authorization manager (e.g., “Authentication” 130/230/330 of the tenants in FIG. 1-3 of Halageri); and
an application server comprising one or more computing devices (e.g., service provider 102/202/302 in FIG. 1-3 of Halageri), wherein the application server is configured to at least:
receive, from a first [entity] of the plurality of [entities], a communication regarding operation of the first [entity];
Refer to at least [0043] of Halageri, wherein “user 325 needing to use the cloud service engine 315 contacts the consumer unit 345 with an access request 360.”
determine to initiate an authorization process to authorize the first [entity] prior to responding to the communication;
Refer to at least [0043] of Halageri, wherein “consumer unit 345 contacts the authentication system 330 for access to the cloud service requested by the user 325;” it is determined whether “a security token is required for the user 325 to access the cloud service engine 315.”
[send a token request] to the authorization manager;
Refer to at least [0043]-[0044] of Halageri, wherein “the authentication system 330 sends a token request 349 to the consumer unit 345. The consumer unit 345 contacts the authentication system 355 for access to the cloud services provided by cloud service engine 315. The authentication system 355 in-turn contacts the appropriate authentication system 330 of the tenants… authentication system 335, responds by requesting a specific form of token for the user 325. The consumer unit 345, contacts the authentication system 355 of the cloud provider. The consumer unit 345 requests the specific form of token from the authentication system 355. The authentication system 355 identifies the tenant 320 for the user 325 and contacts the respective authentication system 330 to request a token 350 for the user 325, based on the token 350 requested by the consumer unit 345.”
receive a digital signature from the authorization manager;
Refer to at least [0044] of Halageri, wherein “the authentication system 330 completes and signs the token and sends the token 350 back to the authentication system 355. The authentication system 355 completes the token requested by the consumer unit 345 based on the token issued by the authentication system 330 and issues the token 350 to the consumer unit 345. The consumer unit 345 forwards the completed and signed token 350 to the authentication system 335.”
verify the digital signature using a verification key and the token;
Refer to at least [0045] of Halageri, wherein “decryption keys may be required to validate signatures on the issued tokens. The authentication system 330 may store the keys in a key store. The authentication system 330 may also encrypt the token requests, and provide a public key so that only the authentication system 355 and/or the authentication system 335 is capable of signing the requested token.” Further see at least [0026] of Halageri with respect to the service provider validating the signed token.
determine, based on verifying the digital signature, that the first [entity] is authorized to operate; and respond to the communication;
Refer to at least [0044] of Halageri, wherein “authentication system 335 provides access to the portlets 310 for the user 325 to access the cloud service engine 315;” refer to at least [0002] of Halageri with respect to example services to provide the user.
and wherein the authorization manager comprises one or more computing devices and is configured to at least:
[receive the token request] from the application server;
Refer to at least [0044] of Halageri with respect to the service provider requesting the token “contact[ing] the respective authentication system 330 to request a token 350 for the user 325, based on the token 350 requested by the consumer unit 345.”
identify at least a subset of the plurality of [entities] based at least partly the subset of the plurality of [entities] being in communication with the authorization manager;
Refer to at least [0044] of Halageri, wherein “authentication system 330 checks to see that the user [i.e., of users 1-N in communication with 330 as in FIG. 3] is authenticated for the services of the corresponding tenant 320.”
generate the digital signature using the token; and send the digital signature to the application server.
Refer to at least [0044] of Halageri, wherein “[i]f the user 325 is authenticated, the authentication system 330 completes and signs the token and sends the token 350 back to the authentication system 355.”
Halageri does not specify: the entity/entities further comprising medical devices; sending the token request further comprising to send a token to the authorization manager; receiving the token request further comprising to receive the token from the application server; generating the signed token further comprising access secret share data associated with at least the subset of the plurality of medical devices, wherein secret share data associated with a first medical device of the subset represents a secret share for generating a digital signature, and wherein a threshold number of secret shares are required in order to generate the digital signature; generating the digital signature further comprising generating the digital signature using the secret share data. However, Halageri in view of SAML discloses: sending the token request further comprising to send a token to the authorization manager;
Refer to at least FIG. 1, 4.1.3.3, and 4.1.4.1 of SAML with respect to <AuthnRequest> sent from a service provider to an identity provider.
receiving the token request further comprising to receive the token from the application server;
Refer to at least FIG. 1, 4.1.3.5, and 4.1.4.2 of SAML with respect to <Response> sent from the identity provider to the service provider responsive to the <AuthnRequest>; as per at least 4.1.4.2, the response should have an InResponseTo attribute matching the request’s ID. For instance, ID "_1234567890" as in 3.3 of SAML.
The teachings of both Halageri and SAML concern SSO, 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 Halageri to further implement SAML sending a unique ID to be signed (e.g., as per the definition in [0038] of the instant specification stating that the token “may be a randomly-generated value, a token provided to the authorization process, or some other input that is to serve as the unencrypted message to be digitally signed”) because the particular known protocol was recognized as part of the ordinary capabilities of one skilled in the art.
Halageri-SAML does not specify: the entity/entities further comprising medical devices; generating the signed token further comprising access secret share data associated with at least the subset of the plurality of medical devices, wherein secret share data associated with a first medical device of the subset represents a secret share for generating a digital signature, and wherein a threshold number of secret shares are required in order to generate the digital signature; generating the digital signature further comprising generating the digital signature using the secret share data. However, Halageri-SAMl in view of Wallrabenstein discloses: generating the signed token further comprising access secret share data associated with at least the subset of the plurality of [entities], wherein secret share data associated with a first [entity] of the subset represents a secret share for generating a digital signature, and wherein a threshold number of secret shares are required in order to generate the digital signature; generating the digital signature further comprising generating the digital signature using the secret share data.
Refer to at least FIG. 13-14 and [0153]-[0154] of Wallrabenstein with respect to PUF protocols linked to a specific hardware device and an associated processing center, where the PUFs comprise a master identity being generated from a set of component identities using a threshold system of cryptographic operations (e.g., [0062] and [0090] of Wallrabenstein concerning secret sharing schemes).
The teachings of Wallrabenstein likewise concern signature generation and device authentication, 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 Halageri-SAML to further implement a threshold signature scheme based on device components for at least the purpose of cryptographically binding the signature to a given device, and for at least the reasons discussed in [0011] of Wallrabenstein (e.g., key storage considerations, reducing the need to issue challenges and store helper data for a device). Additionally, threshold signature schemes are particular known techniques that were recognized as part of the ordinary capabilities of one skilled in the art.
Halageri-SAML-Wallrabenstein does not specify: the entity/entities further comprising medical devices. However, Halageri-SAML-Wallrabenstein in view of Lee discloses: the entity/entities further comprising medical devices.
Refer to at least FIG. 1-2, [0060], and [0070] of Lee with respect to access control for medical device requests using an identity management system and transaction management system.
The teachings of Wallrabenstein likewise concern device access control, 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 Halageri-SAML-Wallrabenstein to further implement support for the entities being medical devices 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.
Regarding claim 13, Halageri-SAML-Wallrabenstein-Lee discloses: The system of claim 12, wherein the application server being configured to verify the digital signature comprises the application server being configured to at least: generate a decrypted message using the digital signature and the verification key, wherein the verification key comprises a decryption key for a decryption function; and determine that the decrypted message comprises data representing the token.
Refer to at least [0034] and [0045] of Halageri with respect to decryption keys to validate signatures on the signed tokens.
Regarding claim 14, Halageri-SAML-Wallrabenstein-Lee discloses: The system of claim 12, wherein the authorization manager being configured to generate the digital signature comprises the authorization manager being configured to encrypt the token using a secret share as an encryption key for an encryption function.
Refer to at least [0034] and [0045] of Halageri with respect to keys for generating and validating the signature.
Refer to at least FIG. 13-14 and [0153]-[0154] of Wallrabenstein with respect to signatures and secret share-based encryption (e.g., [0062]-[0067] and [0090] of Wallrabenstein concerning secret sharing schemes).
This claim would have been obvious for substantially the same reasons as claim 12 above.
Regarding claim 15, it is rejected for substantially the same reasons as claim 1 above (i.e., the citations to Wallrabenstein and the obviousness rationale).
Regarding independent claim 16, it is substantially similar to independent claim 12 above, and is therefore likewise rejected (i.e., the citations and obviousness rationale).
Regarding claims 17-19, they are substantially similar to claims 13-15 above, and are therefore likewise rejected.
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