DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the communication filed on 06/30/2023.
Claims 1-20 are pending.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 16-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Claim 16 recites “A machine-readable storage medium” and the specification does not limit the medium to be non-transitory only. The specification paragraph 126 only indicate that the terms “machine-readable medium” and “computer- readable medium” are interchangeable, and the term “non-transitory computer-readable medium” is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media, but the claim does not recite “a non-transitory machine-readable storage medium”. As such, applying the broadest reasonable interpretation in light of the specification, the claim as a whole cover both transitory and non-transitory machine-readable medium. A transitory medium does not fall into any of the 4 categories of invention (process, machine, manufacture, or composition of matter). However, re-phrasing the claim such as “A non-transitory machine-readable storage medium” would render the claimed subject matter statutory, and therefore overcome the 101 rejection. Claims 17-20 are dependent to claim 16 and are rejected under similar rationale.
Claims 1, 9, and 16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 1 recites the steps of identify a set of security requirements associated with the computing workload request, identify a security feature present in the set of security requirements but not provided by the edge computing node, identify an application execution environment and the application execution environment providing the security feature. The limitation, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, other than reciting an edge computing node, and a trust brokering service edge computing device that performs the steps, nothing in the claim element precludes the steps from practically being performed in the mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the Mental Processes grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the additional elements of receiving a computing workload request from an application and the application configured to process secure data, and executing the computing workload request at the application execution environment are merely insignificant extra-solution activities, e.g., data gathering and pre and/or post solution activities. In addition, the claim recites the additional element of the trust brokering service edge computing device performing these steps. This additional element is recited at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component. Accordingly, the combination of the above additional elements does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using the trust brokering service edge computing device to perform the steps recited in the claim amounts to no more than mere instructions to apply the exception using a generic computer component; mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. In addition, the addition elements of the receiving and executing steps are insignificant extra-solution activities that cannot provide an inventive concept. The claim is not patent eligible.
Claims 9 and 16, although not using the exact claim languages, contain similar elements as recited in claim 1 and are rejected for similar reasons.
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 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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Suneja et al. (US 11,281,767) in view of Rosenhouse (US 10,623,390).
Claim 1, Suneja teaches:
A system for trust brokering as a service, the system comprising:
an edge computing node; and (e.g., figs. 2, 3)
a trust brokering service edge computing device to: (e.g., fig. 1)
identify a security feature present in a set of security requirements but not provided by the edge computing node; (e.g., col. 8 ll. 43-52, “FIG. 2 illustrates 4 different Plugin environments that are reviewed for security capability. Environment 212 depicts the plugin 202 running on the host 208 with the collector software (system state extraction software) 204 but no sidecar sandboxing feature is implemented. This allows the risk of the plugin infecting the guest and host without adequate protection. Environment 214 depicts the plugin 202 running on the guest container 206 with no sidecar sandbox. Since the plugin is in the guest, the guest is not protected”)
identify an application execution environment, the application execution environment providing the security feature; and (e.g., col. 8 ll. 54-59, “The final environment 218 depicts the plugin 202 running on the sidecar container 220 with the access and the constraints in place to communicate with the guest through the kernel constructs that creates the sandbox for the invention. This allows security for the guest (client), the host and guest visibility”)
executing the computing workload request at the application execution environment. (e.g., col. 1 ll. 30-35, “The innovation enables a secure environment where plugins will run inside a sidecar container that is separate from a guest container. A container consists of an entire runtime environment: an application, plus its dependencies, libraries and other binaries, and configuration files needed to run it, bundled into one package” Claim 1, “granting the sidecar container capabilities that are required by the plugin for full functionality of the plugin”)
Suneja does not appear to explicitly teach but Rosenhouse teaches:
receive a computing workload request from an application, the application configured to process secure data; identify a set of security requirements associated with the computing workload request. (e.g., col. 7 ll. 19-40, “A cloud controller 307 directs deployment of applications, including the application 110. The cloud controller 307 maintains records of organizations, spaces, user roles, and services, including the service 114. A service broker 308 provisions resources as the services. The cloud controller 307 submits a request to the service broker 308 indicating that the application 110 is to bind with the service 114. In response, the service broker 308 returns credentials information, e.g., a credentials block, describing how a client such as the application 110 can connect to the service 114. An example credentials block, as returned by the service broker 308, is shown below in Listing 4. {“credentials”: {“hostname”: “example-host-guid.link.bosh”, “port”: “5432”, “username”: “a_user_name”, “password”: “a-password”, “name”: “a-database-name” }, “sidecar-enabled”: true }”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings described by Rosenhouse into the invention of Suneja, and the motivation for such an implementation would be for the purpose of reducing or eliminating potential security holes caused by human error and reducing security requests to and workload of a security administrator (Rosenhouse col. 1 ll. 65 - col. 2 ll. 15).
Claim 2, Suneja-Rosenhouse teaches:
wherein the application execution environment includes a trust brokering service, the trust brokering service configured to provide two-sided trust-brokered mediation between the application and the application execution environment. (e.g., Suneja abstract, figs. 2-3, col. 3 ll. 32-46; Rosenhouse fig. 3, col. 7 ll. 19-col. 8 ll. 26) Same motivation as presented in claim 1 would apply.
Claim 3, Suneja-Rosenhouse teaches:
the application execution environment is executed on a target edge device; and the trust brokering service provides a virtualized view of the application execution environment to the application. (e.g., Suneja figs. 2-3, col. 3 ll. 32-46, col. 6 ll. 24-45; Rosenhouse fig. 3, col. 7 ll. 19-col. 8 ll. 26, col. 12 ll. 21-36) Same motivation as presented in claim 1 would apply.
Claim 4, Suneja-Rosenhouse teaches:
the trust brokering service edge computing device further to: generate a set of workload microservices based on the computing workload request; generate a secure information container based on the set of workload microservices; and migrate the secure information container to the application execution environment. (e.g., Suneja figs. 3, 6-8, col. 3 ll. 32-46, col. 6 ll. 24-45; Rosenhouse fig. 3, col. 7 ll. 19-col. 8 ll. 26) Same motivation as presented in claim 1 would apply.
Claim 5, Suneja-Rosenhouse teaches:
the trust brokering service edge computing device further to generate an application execution environment, wherein the application execution environment includes a secure plugin to provide the security feature and a virtual device corresponding to the edge computing node. (e.g., Suneja figs. 2-3, col. 6 ll. 24-45, col. 8 ll. 54-59; Rosenhouse fig. 3, col. 7 ll. 19-col. 8 ll. 26) Same motivation as presented in claim 1 would apply.
Claim 6, Suneja-Rosenhouse teaches:
wherein the application execution environment includes at least one of an application sidecar, a logical network slice, or a scalable input/output virtualization (IOV). (e.g., Suneja abstract, figs. 1-3, col. 3 ll. 32-46)
Claim 7, Suneja-Rosenhouse teaches:
wherein the logical network slice includes a dynamically created logical network subset, the logical network slice associated with a set of logical network function instances and a set of logical network resources. (e.g., Suneja figs. 3, 8, col. 3 ll. 32-46; Rosenhouse col. 11 ll. 9-16) Same motivation as presented in claim 1 would apply.
Claim 8, Suneja-Rosenhouse teaches:
wherein the application execution environment is implemented within a virtual execution environment. (e.g., Suneja figs. 1-3, col. 3 ll. 32-46, col. 6 ll. 24-45)
Claim 9, Suneja teaches:
A method for trust brokering as a service, the method comprising:
identifying a security feature present in a set of security requirements but not provided by an edge computing node; (e.g., col. 8 ll. 43-52, “FIG. 2 illustrates 4 different Plugin environments that are reviewed for security capability. Environment 212 depicts the plugin 202 running on the host 208 with the collector software (system state extraction software) 204 but no sidecar sandboxing feature is implemented. This allows the risk of the plugin infecting the guest and host without adequate protection. Environment 214 depicts the plugin 202 running on the guest container 206 with no sidecar sandbox. Since the plugin is in the guest, the guest is not protected”)
identifying an application execution environment, the application execution environment including a secure plugin providing the security feature and a virtual device corresponding to the edge computing node; and (e.g., figs. 2-3, col. 8 ll. 54-59, “The final environment 218 depicts the plugin 202 running on the sidecar container 220 with the access and the constraints in place to communicate with the guest through the kernel constructs that creates the sandbox for the invention. This allows security for the guest (client), the host and guest visibility”)
causing the computing workload request to be executed at the application execution environment. (e.g., col. 1 ll. 30-35, “The innovation enables a secure environment where plugins will run inside a sidecar container that is separate from a guest container. A container consists of an entire runtime environment: an application, plus its dependencies, libraries and other binaries, and configuration files needed to run it, bundled into one package” Claim 1, “granting the sidecar container capabilities that are required by the plugin for full functionality of the plugin”)
Suneja does not appear to explicitly teach but Rosenhouse teaches:
receiving, at a trust brokering service edge computing device, a computing workload request from an application, the application configured to process secure data; identifying a set of security requirements associated with the computing workload request. (e.g., col. 7 ll. 19-40, “A cloud controller 307 directs deployment of applications, including the application 110. The cloud controller 307 maintains records of organizations, spaces, user roles, and services, including the service 114. A service broker 308 provisions resources as the services. The cloud controller 307 submits a request to the service broker 308 indicating that the application 110 is to bind with the service 114. In response, the service broker 308 returns credentials information, e.g., a credentials block, describing how a client such as the application 110 can connect to the service 114. An example credentials block, as returned by the service broker 308, is shown below in Listing 4. {“credentials”: {“hostname”: “example-host-guid.link.bosh”, “port”: “5432”, “username”: “a_user_name”, “password”: “a-password”, “name”: “a-database-name” }, “sidecar-enabled”: true }”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings described by Rosenhouse into the invention of Suneja, and the motivation for such an implementation would be for the purpose of reducing or eliminating potential security holes caused by human error and reducing security requests to and workload of a security administrator (Rosenhouse col. 1 ll. 65 - col. 2 ll. 15).
Claim 10, this claim is directed to a method containing similar limitations as recited in claim 2 and is rejected using the same rationale to combine the references.
Claim 11, this claim is directed to a method containing similar limitations as recited in claim 3 and is rejected using the same rationale to combine the references.
Claim 12, this claim is directed to a method containing similar limitations as recited in claim 4 and is rejected using the same rationale to combine the references.
Claim 13, this claim is directed to a method containing similar limitations as recited in claim 5 and is rejected using the same rationale to combine the references.
Claim 14, this claim is directed to a method containing similar limitations as recited in claim 6 and is rejected using the same rationale to combine the references.
Claim 15, this claim is directed to a method containing similar limitations as recited in claim 7 and is rejected using the same rationale to combine the references.
Claim 16, Suneja teaches:
A machine-readable storage medium comprising instructions that, when executed by a processor of a trust brokering service edge computing device, cause the trust brokering service edge computing device to:
identify a security feature present in a set of security requirements but not provided by an edge computing node; (e.g., col. 8 ll. 43-52, “FIG. 2 illustrates 4 different Plugin environments that are reviewed for security capability. Environment 212 depicts the plugin 202 running on the host 208 with the collector software (system state extraction software) 204 but no sidecar sandboxing feature is implemented. This allows the risk of the plugin infecting the guest and host without adequate protection. Environment 214 depicts the plugin 202 running on the guest container 206 with no sidecar sandbox. Since the plugin is in the guest, the guest is not protected”)
identify an application execution environment, the application execution environment including a secure plugin providing the security feature and a virtual device corresponding to the edge computing node; and (e.g., figs. 2-3, col. 8 ll. 54-59, “The final environment 218 depicts the plugin 202 running on the sidecar container 220 with the access and the constraints in place to communicate with the guest through the kernel constructs that creates the sandbox for the invention. This allows security for the guest (client), the host and guest visibility”)
execute the computing workload request at the application execution environment. (e.g., col. 1 ll. 30-35, “The innovation enables a secure environment where plugins will run inside a sidecar container that is separate from a guest container. A container consists of an entire runtime environment: an application, plus its dependencies, libraries and other binaries, and configuration files needed to run it, bundled into one package” Claim 1, “granting the sidecar container capabilities that are required by the plugin for full functionality of the plugin”)
Suneja does not appear to explicitly teach but Rosenhouse teaches:
receive, at a trust brokering service edge computing device, a computing workload request from an application, the application configured to process secure data; identify a set of security requirements associated with the computing workload request. (e.g., col. 7 ll. 19-40, “A cloud controller 307 directs deployment of applications, including the application 110. The cloud controller 307 maintains records of organizations, spaces, user roles, and services, including the service 114. A service broker 308 provisions resources as the services. The cloud controller 307 submits a request to the service broker 308 indicating that the application 110 is to bind with the service 114. In response, the service broker 308 returns credentials information, e.g., a credentials block, describing how a client such as the application 110 can connect to the service 114. An example credentials block, as returned by the service broker 308, is shown below in Listing 4. {“credentials”: {“hostname”: “example-host-guid.link.bosh”, “port”: “5432”, “username”: “a_user_name”, “password”: “a-password”, “name”: “a-database-name” }, “sidecar-enabled”: true }”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings described by Rosenhouse into the invention of Suneja, and the motivation for such an implementation would be for the purpose of reducing or eliminating potential security holes caused by human error and reducing security requests to and workload of a security administrator (Rosenhouse col. 1 ll. 65 - col. 2 ll. 15).
Claim 17, this claim is directed to a machine-readable storage medium containing similar limitations as recited in claim 2 and is rejected using the same rationale to combine the references.
Claim 18, this claim is directed to a machine-readable storage medium containing similar limitations as recited in claim 3 and is rejected using the same rationale to combine the references.
Claim 19, this claim is directed to a machine-readable storage medium containing similar limitations as recited in claim 4 and is rejected using the same rationale to combine the references.
Claim 20, this claim is directed to a machine-readable storage medium containing similar limitations as recited in claim 5 and is rejected using the same rationale to combine the references.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: US 2023/0334140 teaches techniques for managing applications’ access to data resources.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIE C LIN whose telephone number is (571)272-7752. The examiner can normally be reached M-F 9:00AM -5:00PM.
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, GELAGAY SHEWAYE can be reached at (571)272-4219. 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.
/AMIE C. LIN/Primary Examiner, Art Unit 2436
