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 . In communications filed on 07/25/2025. Claims 1-8cancelled. Claims 9-15 newly added. Claims 9-15 are pending in this examination.
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. This examination is in response to US Patent Application No. 19/151,165.
Drawings
New corrected drawings in compliance with 37 CFR 1.121(d) are required in this application because [the drawing filed on 07/25/2026 does not describe what the item numbers are in the FIG 1]. Applicant is advised to employ the services of a competent patent draftsperson outside the Office, as the U.S. Patent and Trademark Office no longer prepares new drawings. The corrected drawings are required in reply to the Office action to avoid abandonment of the application. The requirement for corrected drawings will not be held in abeyance.
Claim Objections
Claim 1 is objected to because of the following informalities: the word “wherein” repeated at third paragraph in claim 1. Appropriate correction is required.
Information Disclosure Statement
The listing of references in the specification paragraphs [ 008-0010, 0037] are not a proper information disclosure statement. 37 CFR 1.98(b) requires a list of all patents, publications, or other information submitted for consideration by the Office, and MPEP § 609.04(a) states, "the list may not be incorporated into the specification but must be submitted in a separate paper." Therefore, unless the references have been cited by the examiner on form PTO-892, they have not been considered.
Examiner Note
The independent claim 15 needs to be written in independent claim format which includes all the limitations of claim 9.
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.
Claim 13 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. As recited in the body of the claim 13 :“container instances”, and “monitoring unit”, and “provisioning unit” can be implemented as software only, hence the claimed system lacks a structural component. Therefore, claim 13 is directed to non-statutory subject matter for lack of a hardware component. The Examiner respectfully suggests that the claim be further amended to positively recite at least one hardware element within the body of the claim to make the claim statutory subject matter under 35 U.S.C. 101. Dependent claim 14 are also rejected for being directed to a non- statutory subject matter.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Regarding claim 13, the phrase "such that" renders the claim indefinite because it is unclear whether the limitations following the phrase are part of the claimed invention. See MPEP § 2173.05(d).
First t Set of Rejections:
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 9-15 are rejected under 35 U.S.C. 102(a) (1) as being anticipated by Lai (US2020/0344233).
Regarding claim 9, Lai discloses a computer-implemented method for handling at least one unauthorized access operation to at least one common resource by at least one first container instance, wherein the at least one first container instance and at least one second container instance are executed on a common runtime environment of a host system, wherein the at least one second container instance uses the at least one common resource, the method comprising:
[0087] As depicted here, there is again a host organization 110 having a hosted computing environment 111 operating therein with a web-server 175, request interface 176, authenticator 140, query interface 180, and database system 130. As before, there is also a blockchain services interface 190 via which the host organization 110 provides a variety of blockchain related services to customers, subscribers, and other organizations and tenants which utilize the cloud computing services provided by the host organization 110]
[see FIG. 6F, and corresponding text for more detail, [0153] FIG. 6F depicts another exemplary architecture 650, specifically depicting an exemplary Access Chain Authorization Model 651, in accordance with described embodiments.
[0154] As shown here, the Client Service cloud 652 communicates with the Access Chain configured blockchain 653 via its sidecar container 654(equate second container) exposed via the application container 655 (equate first container) by the host organization's client service cloud, with the sidecar container being accessible from the WWW 656, and thus able to receive and process incoming API access authorization requests and RBAC policy enforcement.
defining and providing at least one access authorization criterion for one of the second container instances that rules which operations involving accessing of the at least one common resource by the at least one first container instance are authorized or unauthorized
[0154] As shown here, the Client Service cloud 652 communicates with the Access Chain configured blockchain 653 via its sidecar container 654(equate second container) exposed via the application container 655 (equate first container) by the host organization's client service cloud, with the sidecar container being accessible from the WWW 656, and thus able to receive and process incoming API access authorization requests and RBAC policy enforcement( equated to second container with access authorization criterion].
checking, when a new first container instance is launched, whether at least one access authorization criterion has been provided for the at least one second container instance
[0154] As shown here, the Client Service cloud 652 communicates with the Access Chain configured blockchain 653 via its sidecar container 654(equate second container) exposed via the application container 655 (equate first container) by the host organization's client service cloud, with the sidecar container being accessible from the WWW 656, and thus able to receive and process incoming API access authorization requests and RBAC policy enforcement( equated to second container with access authorization criterion].
[0155] In the sidecar, tasks such as authentication, validation, monitoring, logging, networking services, and configuration may be executed within the process as the parent application, making use of shared resources. Sidecar usage provides isolation of the parent and sidecar processes from other operations which may be running concurrently such that network fault will not jeopardize an entire application or other components. By separating the various application components (e.g., such as the access manager, the API manager, the Exchange service, the cloud hub, and the authorization control) into separate services, each of which are preferably built individually, it is possible to isolate any faults with one sub-part form the application as a whole. According to one embodiment, when an API call is intercepted, a sidecar is instantiated to perform the authentication of the API caller, with the sidecar process being tied to the API process having received the API call.
in an event of a positive check, monitoring the operations of the at least one first container instance during execution thereof as to whether the operations are unauthorized in accordance with the at least one access authorization criterion
[0156] According to specific embodiments, the sidecar container 654 intercepts incoming requests and then the sidecar container utilizes the Access Chain 653 to perform the authorization check on the incoming user API request. If the user is authorized, then the sidecar container 654 forwards the request to the application container 655 for processing via the application logic. If the user is not authorized, then the sidecar simply returns an access denied message or ignores the request.
[0233] According to another embodiment of method 900, the API call intercepted at the API gateway is intercepted via a sidecar process tied to an API process executing the defined API; in which the sidecar is to perform an authorization check for a user having originated the incoming API call; in which the sidecar returns an access denied message or ignores the request in the event of a failed authentication attempt; and in which the sidecar forwards the API call intercepted at the API gateway to an application container for processing via application logic for handling an authenticated and successfully received API call.
wherein, , if, during monitoring, at least one operation is recognized as unauthorized, then initiating an action that counteracts the accessing of the at least one common resource, by way of an alert message for the at least one second container instance or by stopping the execution of the at least one second container instance
[0156] According to specific embodiments, the sidecar container 654 intercepts incoming requests and then the sidecar container utilizes the Access Chain 653 to perform the authorization check on the incoming user API request. If the user is authorized, then the sidecar container 654 forwards the request to the application container 655 for processing via the application logic. If the user is not authorized, then the sidecar simply returns an access denied message or ignores the request.
[0233] According to another embodiment of method 900, the API call intercepted at the API gateway is intercepted via a sidecar process tied to an API process executing the defined API; in which the sidecar is to perform an authorization check for a user having originated the incoming API call; in which the sidecar returns an access denied message or ignores the request in the event of a failed authentication attempt; and in which the sidecar forwards the API call intercepted at the API gateway to an application container for processing via application logic for handling an authenticated and successfully received API call
wherein the at least one access authorization criterion is present in a container image belonging to the at least one second container instance.
[0154] As shown here, the Client Service cloud 652 communicates with the Access Chain configured blockchain 653 via its sidecar container 654(equate second container) exposed via the application container 655 (equate first container) by the host organization's client service cloud, with the sidecar container being accessible from the WWW 656, and thus able to receive and process incoming API access authorization requests and RBAC policy enforcement( equated to second container with access authorization criterion].
Regarding claim 10, Lai discloses wherein, in an event of a negative check, the operations of the at least one first container instance are monitored and, if, from a point of view of the runtime environment, all operations accessing the common resources are considered to be unauthorized, when such an operation considered to be unauthorized is executed, an action that counteracts the accessing of the at least one common resource is initiated by way of an alert message for the at least one second container instance or by stopping the execution of the at least one second container instance.
[0156] According to specific embodiments, the sidecar container 654 intercepts incoming requests and then the sidecar container utilizes the Access Chain 653 to perform the authorization check on the incoming user API request. If the user is authorized, then the sidecar container 654 forwards the request to the application container 655 for processing via the application logic. If the user is not authorized, then the sidecar simply returns an access denied message or ignores the request.
[0233] According to another embodiment of method 900, the API call intercepted at the API gateway is intercepted via a sidecar process tied to an API process executing the defined API; in which the sidecar is to perform an authorization check for a user having originated the incoming API call; in which the sidecar returns an access denied message or ignores the request in the event of a failed authentication attempt; and in which the sidecar forwards the API call intercepted at the API gateway to an application container for processing via application logic for handling an authenticated and successfully received API call
Regarding claim 11, Lai discloses, wherein the at least one common resource comprises namespaces respectively used by container instances and/or a namespace used by the host system and/or file system objects and/or device files.
[0053, A distributed ledger (also called a shared or common ledger or referred to as distributed ledger technology (DLT)) is a consensus of replicated, shared, and synchronized digital data geographically spread across multiple nodes. The nodes may be located in different sites, countries, institutions, user communities, customer organizations, host organizations, hosted computing environments, or application servers. There is no central administrator or centralized data storage.
Regarding claim 12, Lai discloses, wherein it is possible to derive, from the at least one access authorization criterion, whether an alert message or stoppage of the execution of the at least one second container instance should be initiated.
[0156] According to specific embodiments, the sidecar container 654 intercepts incoming requests and then the sidecar container utilizes the Access Chain 653 to perform the authorization check on the incoming user API request. If the user is authorized, then the sidecar container 654 forwards the request to the application container 655 for processing via the application logic. If the user is not authorized, then the sidecar simply returns an access denied message or ignores the request.
[0233] According to another embodiment of method 900, the API call intercepted at the API gateway is intercepted via a sidecar process tied to an API process executing the defined API; in which the sidecar is to perform an authorization check for a user having originated the incoming API call; in which the sidecar returns an access denied message or ignores the request in the event of a failed authentication attempt; and in which the sidecar forwards the API call intercepted at the API gateway to an application container for processing via application logic for handling an authenticated and successfully received API call.
Regarding claims 13, and 15, this claim is interpreted and rejected for the same rational set forth in claim 9.
Regarding claim 14, this claim is interpreted and rejected for the same rational set forth in claim 10.
Second Set of Rejections:
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 9-15 are rejected under 35 U.S.C. 102(a) (1) as being anticipated Christian Peter [Mechanism for Protection from Shared Volumes on Edge Devices SIEMENS AG [ filed in IDS07/24/2025] , hereinafter “Peter”.
Regarding claim 9, Peter discloses a computer-implemented method for handling at least one unauthorized access operation to at least one common resource by at least one first container instance, wherein the at least one first container instance and at least one second container instance are executed on a common runtime environment of a host system, wherein the at least one second container instance uses the at least one common resource, the method comprising:
[see p. 4, column 1, 4th paragraph: "checking accesses, such as reading and writing, by apps or their container instances and processes at runtime"; p. 3, column 1, 1st paragraph: "improved protection of shared volumes"; p. 1, column 1, 1st paragraph: "containers are a method that makes it possible to operate multiple instances of an operating system on the same system independently and in isolation from one another. In this context, an app can consist of multiple containers")], and
defining and providing at least one access authorization criterion for one of the second container instances that rules which operations involving accessing of the at least one common resource by the at least one first container instance are authorized or unauthorized
[ see p. 3, column 2, 3rd paragraph: "3. When loading or installing an app that is to gain access to the shared volume, the access policy is extended to include the accesses to the shared volume required for the app. This is achieved by assigning the corresponding volume identifier to the app and, where applicable, creating additional rules."]; and
checking, when a new first container instance is launched, whether at least one access authorization criterion has been provided for the at least one second container instance
[p. 4, column 1, 4th paragraph: "5. The checking of accesses—such as reading and writing—by apps (or their container instances and processes) at runtime is implemented by a dedicated component. This component uses the assigned identifiers, together with an automatically extended access policy, to decide whether an access is actually permitted. Unwanted access can be blocked and reported. Consequently, an unauthorized and—additionally—malicious or compromised app cannot access the shared volumes of other apps." .Note: the checking of accesses based on access authorization criteria—including identifiers and policy—takes place continuously, which also encompasses the launching of new instances]; and
in an event of a positive check, monitoring the operations of the at least one first container instance during execution thereof as to whether the operations are unauthorized in accordance with the at least one access authorization criterion
[p. 4, column 1, 4th paragraph: "5. The checking of accesses—such as reading and writing—by apps (or their container instances and processes) at runtime is implemented by a dedicated component. This component uses the assigned identifiers, together with an automatically extended access policy, to decide whether an access is actually permitted. Unwanted access can be blocked and reported. Consequently, an unauthorized and—additionally—malicious or compromised app cannot access the shared volumes of other apps." .Note: the checking of accesses based on access authorization criteria—including identifiers and policy—takes place continuously, which also encompasses the launching of new instances]; and
wherein, if, during monitoring, at least one operation is recognized as unauthorized, then initiating an action that counteracts the accessing of the at least one common resource, by way of an alert message for the at least one second container instance or by stopping the execution of the at least one second container instance
[p. 4, column 2, 2nd paragraph: "An app that should not have access to the shared volume is not assigned this identifier. A malicious or compromised app that should not have access to the shared volume can now be prevented by the operating system from accessing the shared volume. A dedicated component of the operating system checks whether the accessing process has been assigned the identifier of the shared volume. If this is not the case, the access is blocked, reported, and/or logged. When using SELinux, as shown in the example above, this is done by the SELinux subsystem implemented in the Linux kernel."),
wherein the at least one access authorization criterion is present in a container image belonging to the at least one second container instance.
[p. 4, column 1, 4th paragraph: "5. The checking of accesses—such as reading and writing—by apps (or their container instances and processes) at runtime is implemented by a dedicated component. This component uses the assigned identifiers, together with an automatically extended access policy, to decide whether an access is actually permitted. Unwanted access can be blocked and reported. Consequently, an unauthorized and—additionally—malicious or compromised app cannot access the shared volumes of other apps." //Note: the checking of accesses based on access authorization criteria—including identifiers and policy—takes place continuously, which also encompasses the launching of new instances]
Regarding claim 10, Peter discloses, wherein, in an event of a negative check, the operations of the at least one first container instance are monitored and, if, from a point of view of the runtime environment, all operations accessing the common resources are considered to be unauthorized, when such an operation considered to be unauthorized is executed, an action that counteracts the accessing of the at least one common resource is initiated by way of an alert message for the at least one second container instance or by stopping the execution of the at least one second container instance.
[p. 4, column 1, 4th paragraph: "5. The checking of accesses—such as reading and writing—by apps (or their container instances and processes) at runtime is implemented by a dedicated component. This component uses the assigned identifiers, together with an automatically extended access policy, to decide whether an access is actually permitted. Unwanted access can be blocked and reported. Consequently, an unauthorized and—additionally—malicious or compromised app cannot access the shared volumes of other apps." //Note: the checking of accesses based on access authorization criteria—including identifiers and policy—takes place continuously, which also encompasses the launching of new instances]
[p. 4, column 2, 2nd paragraph: "An app that should not have access to the shared volume is not assigned this identifier. A malicious or compromised app that should not have access to the shared volume can now be prevented by the operating system from accessing the shared volume. A dedicated component of the operating system checks whether the accessing process has been assigned the identifier of the shared volume. If this is not the case, the access is blocked, reported, and/or logged. When using SELinux, as shown in the example above, this is done by the SELinux subsystem implemented in the Linux kernel."),
Regarding claim 11, Peter discloses, wherein the at least one common resource comprises namespaces respectively used by container instances and/or a namespace used by the host system and/or file system objects and/or device files.
[, p. 1, column 1, 2nd paragraph , the customers should be able to be offered the widest possible range of applications. This also places stronger attachments to the security mechanisms of such a device, as the applications have different levels of privileges on the device, such as access to certain files or interfaces. Asa rule , apps are from different manufacturers or third-party providers. It is increasing that individual apps are inter-connected to each other have to exchange data using shared volumes].
Regarding claim 12, Peter discloses, wherein it is possible to derive, from the at least one access authorization criterion, whether an alert message or stoppage of the execution of the at least one second container instance should be initiated
[p. 4, column 1, 4th paragraph: "5. The checking of accesses—such as reading and writing—by apps (or their container instances and processes) at runtime is implemented by a dedicated component. This component uses the assigned identifiers, together with an automatically extended access policy, to decide whether an access is actually permitted. Unwanted access can be blocked and reported. Consequently, an unauthorized and—additionally—malicious or compromised app cannot access the shared volumes of other apps." .Note: the checking of accesses based on access authorization criteria—including identifiers and policy—takes place continuously, which also encompasses the launching of new instances], and [p. 4, column 2, 2nd paragraph: "An app that should not have access to the shared volume is not assigned this identifier. A malicious or compromised app that should not have access to the shared volume can now be prevented by the operating system from accessing the shared volume. A dedicated component of the operating system checks whether the accessing process has been assigned the identifier of the shared volume. If this is not the case, the access is blocked, reported, and/or logged. When using SELinux, as shown in the example above, this is done by the SELinux subsystem implemented in the Linux kernel.")].
Regarding claims 13, and 15, this claim is interpreted and rejected for the same rational set forth in claim 9.
Regarding claim 14, this claim is interpreted and rejected for the same rational set forth in claim 10.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's
disclosure.
See submitted 892 for more relevant references.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Prosecution Insights