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 .
Status of Claims
The following is a Final Office Action in response to applicant’s filing on March 10, 2026. Claims 1-15 are pending, of which claims 1and 14 are in independent form.
Response to Amendment
In view of the remarks, submitted on March 10, 2026, Applicant’s amendments and arguments regarding claim 8 does not obviate the 35 U.S.C. 112(a) rejection, therefore the rejection under 35 U.S.C. 112(a) is maintained.
In view of the remarks, submitted on March 10, 2026, Applicant’s amendments and arguments regarding the Abstract obviate the objection, therefore the abstract objection is withdrawn.
In view of the remarks, submitted on March 10, 2026, Applicant’s amendments and arguments regarding the drawings obviate the objection, therefore the drawing objection is withdrawn .
Response to Arguments
In view of the remarks, submitted on March 10, 2026, applicant’s arguments have been carefully and respectfully considered but are not persuasive.
35 USC § 112(a) Rejection
On page 9 of remarks, Applicant argues that “The specification describes what a skip-mark is (e.g. a label or tag assigned to container images or deployment information), and the purpose it serves (e.g. enabling selective checking of tagged container images)”. Applicant’s arguments are not persuasive. While paragraphs [0063] and [0029] describe assigning information (e.g., tags or labels) to container images or deployment information, the specification does not define a skip-mark nor how such skip-mark establishes a range of validity of an integrity guideline as recited in claim 8. The cited disclosure merely describes a result without providing sufficient retail regarding the structure as to how the skip-mark performs this function. Accordingly, the specification does not reasonably convey possession of the claimed subject matter. Thus, the rejection under 35 USC § 112(a) is maintained.
35 USC § 103 Rejection
On page 10 of remarks, Applicant argues that “claim 1 is not obvious and unpatentable over Fleck in view of Jain because the combination of cited references does not teach or render obvious each and every element of claim 1”. Further, Applicant argues that “Jain is an unrelated technical field…”. Applicant’s arguments have been fully considered but are not persuasive. Applicant contends that Jain is directed to VPN packet encryption and therefore is unrelated to the claimed invention. The examiner disagrees. Jain is teaching managing runtime execution of applications in a cloud computing environment and monitoring application behavior using specifications that define properties, and rules. Accordingly, Jain is in the same field of endeavor (runtime control and enforcement of application behavior or enforcing constraints across applications in a shared environment). Thus, Jain is a related technical field.
Further, on page 10-11, Applicant argues that “Jain does not teach deployment information”. The examiner disagrees. It is noted that, references need not use identical terminology as long as the teachings are equivalent. While Jain may not use the exact term “deployment information”, it discloses an application specification that defines properties of applications and is used to control runtime behavior of application instances, this corresponds to the claimed “the first item of deployment information including at least one property of the first application”. Jain discloses in paragraph [0024] various properties for application, and in paragraph [0027], Jain discloses , runtime observer or monitor by translating the specification into executable code and integrating the monitor with user-defined actions for deployment along with application instances. When on any given host or VM the monitor code is executed at runtime, it continually checks the conditions described in the specification against observed proper ties and characteristics of the application and the cloud computing infrastructure 100. Therefore, Jain’s application specification serves as the same function as the claimed “deployment information”.
Furthermore, Applicant argues that “Jain does not teach “integrity guidelines assigned to deployment information”. Applicant’s arguments have been fully considered but are not persuasive. Jain in paragraph [0024] discloses rules governing behavior of the application 110 (e.g., CPU usage<20%) and cloud computing infrastructure 100 (e.g., inter-node delay<1 ms), and recovery and enforcement actions to be invoked when a monitor 112 (discussed next) detects a condition to be satisfied or violated as specified by a rule, which defines rules within the specification that define conditions and constraints on application behavior. Further, Jain in paragraph [0027] discloses the monitor application instance triggers the specified user-defined action such as reporting an error to the developer and cloud operator, logging a message to storage, and executing a recovery code to enforce desired application and system behavior. Further, Jain’s abstract discloses monitor instance may evaluate the local host information or aggregate information collected from hosts running other instances of the monitor application, to repeatedly determine whether a rule condition has been violated. On violation, a user-specified handler is triggered. Therefore, Jain teaches rule-based constraints governing interactions and behavior of applications in a shared environment. Moreover, Jain discloses the monitor application instance triggers the specified user-defined action such as reporting an error to the developer and cloud operator, logging a message to storage, and executing a recovery code to enforce desired application and system behavior, etc. (see paragraph [0027]), therefore, the relevant information (rules and properties) is provided by a user and used in the runtime environment.
In addition, on page 12, Applicant argues that Jain does not teach “standard and fallback configurations”. The examiner disagrees. Jain in paragraph [0051] discloses Such a library may include different types of recovery actions and enforcement modules providing different functionality, including, logging to a database, sending notification alerts, modifying application execution at runtime, analyzing runtime data and stack of application execution, terminating application, invocation of an alternate service, debugging the application execution state, task scheduling, and triggering actions for rollback and compensation. It is noted that these actions represent different runtime behaviors or configurations, including normal operation , which correspond to normal operation and alternative behavior upon violation, which corresponds to fallback configuration. Thus, Jain teaches “standard and fallback configurations”.
Further, on page 12 of remarks, Applicant argues that “Even if Fleck and Jain were combined, the combination fails to teach the bidirectional checking required by claim 1.”. Applicant’s arguments have been fully considered but are not persuasive. The examiner reminds Applicant that every limitation in the argument in order to be considered and analyzed must be recited in the claim. Fleck discloses the policy 1145 may specify which destination applications 1115B-N are permitted to replicate the data 1125. In some embodiments, the policy 1145 may specify which device types of the client accessing the second application 1115B are permitted to replicate the data 1125 (see paragraphs [0163]-[0165]). It is noted that Fleck’s policy evaluation inherently considers both sides of the interaction, not a one-way data transfer. On the other hand, Jain explicitly discloses evaluation based on local and aggregated information across multiple application instances and hosts (paragraphs [0024] and [0027]). Moreover, Jain discloses Each monitor instance may evaluate the local host information or aggregate information collected from hosts running other instances of the monitor application, to repeatedly determine whether a rule condition has been violated (Jain, Abstract). Therefore, the combination of Fleck and Jain teaches bidirectional checking. Fleck provides the framework for enforcing constraints on interactions between applications in paragraphs [0163] and [0165]. Further, Jain provides a rule-based system in paragraphs [0024] and [0027]. Lastly, Applicant’s argument that there is no motivation to combine Fleck and Jain is not persuasive because both references address enforcement of constraints on application behavior in runtime environments, with Jain’s rule-based system and Fleck’s policy system, the combination of references would have been rendered the claimed functionality obvious to one of ordinary skill in the art.
Regarding the combination of Fleck and Jain with respect to claims 1-15 it is applicant’s opinion that adding the Jain reference provides no reasonable combination. However, a person of ordinary skill is also a person of ordinary creativity, not an automaton, and in many cases will be able to fit teaching of multiple patents together like pieces of a puzzle. Furthermore, “The test for obviousness is not whether the feature of secondary reference may be bodily incorporated into the structure of the primary reference…Rather, the test is what the combined teachings of those references would have suggested to those of ordinary skill in the art”. In the instant case Jain provides additional information that would suggest a modification of Fleck.
The independent claim 14 is similarly rejected. As to the dependent claims 1-13 and 15, these claims remain rejected by virtue of dependency to their independent claims. Accordingly, the rejection under 103 is maintained.
Examiner Note
The term “a computer program product” recited in claim 15 has been interpreted to cover only a set of computer-executable instructions stored in a non-transitory and physical computer readable storage media in view of paragraph [0060] of the specification which states “A further aspect of embodiments of the invention relates to a computer program product (non-transitory computer readable storage medium having instructions, which when executed by a processor, perform actions) which is capable of being loaded directly into a memory of a digital computer, comprising program-code parts that upon execution of the program-code parts by the digital computer cause the latter to carry out the steps of the method”.
Specification
The disclosure is objected to because paragraph [0073] states “the first item of deployment information BI1 ”. However, paragraph [0074] states “the first deployment guideline BI1”. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 8 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 8 recites “ wherein a range of validity of the first integrity guideline is established by a skip-mark which has been assigned to at least one container image or to at least one second item of deployment information”.
Claim 8 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 8 recites “a range of validity of the first integrity guideline is established by a skip-mark;”. (i.e., A range of validity of the first integrity guideline IR1 is established by a skip-mark that has been assigned to at least one container image CI11, . . . , CIn3 or to at least one second item of deployment information BI2, . . . , Bn, see paragraph [0083]). The full scope of the claim covers a range of validity of the first integrity guideline established by “a skip-mark” . However, there is no definition of what a skip-mark is, moreover, there is no embodiment explaining as to how a range of validity of the first integrity guideline is established by a skip-mark. The cited disclosure merely describes a result without providing sufficient retail regarding the structure as to how the skip-mark performs this function.
The level of detail required to satisfy the written description requirement varies depending on the nature and scope of the claims and on the complexity and predictability of the relevant technology. Ariad, 598 F.3d at 1351, 94 USPQ2d at 1172; Capon v. Eshhar, 418 F.3d 1349, 1357-58, 76 USPQ2d 1078, 1083-84 (Fed. Cir. 2005). Computer-implemented inventions are often disclosed and claimed in terms of their functionality. For computer-implemented inventions, the determination of the sufficiency of disclosure will require an inquiry into the sufficiency of both the disclosed hardware and the disclosed software due to the interrelationship and interdependence of computer hardware and software. The critical inquiry is whether the disclosure of the application relied upon reasonably conveys to those skilled in the art that the inventor had possession of the claimed subject matter as of the filing date. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 682. 114 USPQ2d 1349, 1356 (citing Ariad Pharm., Inc. V. Eli Lilly & Co, 598 F.3d 1336, 1351, 94 USPQ2d 1161, 1172 (Fed. Cir. 2010) in the context of determining possession of a claimed means of accessing disparate databases).
Claim Rejections - 35 USC § 103
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 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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-15 are rejected under 35 U.S.C. 103 as being unpatentable over Fleck et al. (US 2019/0340376 A1), hereinafter Fleck in view of Jain (US 2011/0276951 A1), hereinafter Jain.
Regarding claim 1, Fleck discloses A method for enforcing integrity conditions of a first container-based application in relation to all second container-based applications that are being executed in a common runtime environment of a host system (Fleck, Fig. 11, Para. 0155, the IPC manager 1110 may include a data transfer engine 1130, a policy enforcer engine 1135, a data analysis engine 140, and/or a policy 1145. In some embodiments, the IPC manager 1110 may reside on one or more servers or a cloud-based resource with the network application 1105. In some embodiments, the IPC manager 1110 may reside on each client application 404A-N (e.g., as part of the embedded browser 410A-N), comprising:
prior to the starting of a first container instance of the first application, for each second application, checking the first item of deployment information against a second integrity guideline which has been assigned to a second item of deployment information pertaining to the second application (Fleck, Para. 0163, the policy 1145 may specify which device types of the client accessing the second application 1115B are permitted to replicate the data 1125. In some embodiments, the policy 1145 may specify which data types of the data 1125 permitted to be replicated to the second application 1115B. The policy 1145 may also be context-specific in specifying whether the replication of the data 1125 is to be permitted),
checking the second item of deployment information for each of the second applications against the first integrity guideline (Fleck, Para. 0165, using the identifier for the second application 1115B, the policy enforcer engine 1135 may determine whether the second application 1115B is permitted to replicate the data 1125 under the policy 1145), reporting at least one violation, including the properties in the first item of deployment information that violate at least one of the second integrity guidelines (Fleck, Para. 0165, the client application 404A or 404B may in turn cause the embedded browser 410A or 410B accessing the second application 1115B to display a prompt notifying that the data 1125 is not permitted to be replicated onto the second application 1115B), and
including the properties in the second item of deployment information that violate the first integrity guideline, to the user (Fleck, Para. 0190), carrying out an operation for eliminating the at least one violation, and upon successful elimination of the at least one violation (Fleck, Para. 0190), executing the first container instance in the runtime environment (Fleck, Para. 0190, the IPC manager may identify the one or more portions to be altered or removed in accordance with the policy. As discussed above, the policy may specify one or more portions to be modified or deleted in accessing the data maintained on the secure container. With the identification, the IPC manager may alter the portion or may delete the portion in accordance with the policy. In some embodiments, the IPC manager may decrypt the data accessed from the secure container using the cryptographic algorithm and key used to encrypt the data, prior to the alteration or the removal. Once altered or removed, the IPC manager may permit access to a remaining portion of the data by the second network application), and
(Fleck, Para. 0163, the policy 1145 may specify whether one or more portions of the data 1125 are to be altered or removed (e.g., redacted, obscured, blacked-out, deleted) prior to replication onto the second application 1115B).
Fleck does not explicitly disclose assigning a first integrity guideline to a first item of deployment information pertaining to the first application, the first integrity guideline including at least one requirement with respect to the at least one second application, and
the first item of deployment information including at least one property of the first application, receiving the first item of deployment information and the first integrity guideline from a user of the first application in the runtime environment, wherein the first item of deployment information comprises a standard configuration and at least one fallback configuration of the runtime environment for the first application.
However, Jain teaches assigning a first integrity guideline to a first item of deployment information pertaining to the first application (Jain, Fig.1, Para. 0027, runtime observer or monitor by translating the specification into executable code and integrating the monitor with user-defined actions for deployment along with application instances. When on any given host or VM the monitor code is executed at runtime, it continually checks the conditions described in the specification against observed proper ties and characteristics of the application and the cloud computing infrastructure 100), the first integrity guideline including at least one requirement with respect to the at least one second application (Jain, Fig.1, Para. 0024, the specification 108 is compiled/synthesized to build an executable monitor 112. Instances (copies) of the monitor 112 and application 110 may be distributed in pairs to run concurrently on various hosts 102), and
the first item of deployment information including at least one property of the first application (Jain, Fig.1, Para. 0024, the specification 108 describes various properties for application),
receiving the first item of deployment information and the first integrity guideline from a user of the first application in the runtime environment (Jain, Fig.1, Para. 0027, regarding compilation of a monitor, the predicates in a specification are compiled to synthesize/build a corresponding runtime observer or monitor by translating the specification into executable code and integrating the monitor with user-defined actions for deployment along with application instances. When on any given host or VM the monitor code is executed at runtime, it continually checks the conditions described in the specification against observed properties and characteristics of the application and the cloud computing infrastructure 100),
wherein the first item of deployment information comprises a standard configuration and at least one fallback configuration of the runtime environment for the first application (Jain, Para. 0051, Regarding violation handlers, a standard library of pre-defined actions may be built. Such a library may include different types of recovery actions and enforcement modules providing different functionality, including, logging to a database, sending notification alerts, modifying application execution at runtime, analyzing runtime data and stack of application execution, terminating application, invocation of an alternate service, debugging the application execution state, task scheduling, and triggering actions for rollback and compensation). Fleck are Jain are both considered to be analogous to the claim invention because they are in the same field of providing for enforcing policy of multiple applications in a secure container running in a runtime environment . Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Fleck to incorporate the teachings of Jain to include assigning a first integrity guideline to a first item of deployment information pertaining to the first application (Jain, Fig.1, Para. 0027), the first integrity guideline including at least one requirement with respect to the at least one second application (Jain, Fig.1, Para. 0024), and the first item of deployment information including at least one property of the first application (Jain, Fig.1, Para. 0024), receiving the first item of deployment information and the first integrity guideline from a user of the first application in the runtime environment (Jain, Fig.1, Para. 0027), wherein the first item of deployment information comprises a standard configuration and at least one fallback configuration of the runtime environment for the first application (Jain, Para. 0051). Doing so would aid to help recovery actions and enforcement techniques be used to control dynamic application behavior and system behavior in user-defined ways. That is; to enforce desired application behavior and system behavior at runtime, the mechanism of enforcement is separated from application-specific policy for controlling the application behavior (Jain, Fig.1, Para. 0022).
Regarding claim 2, the combination of Fleck in view of Jain teaches the method as claimed in claim 1, wherein the first integrity guideline and the first item of deployment information are made available by a creator of the first item of deployment information (Jain, Para. 0027, regarding compilation of a monitor, the predicates in a specification are compiled to synthesize/build a corresponding runtime observer or monitor by translating the specification into executable code and integrating the monitor with user-defined actions for deployment along with application instances. When on any given host or VM the monitor code is executed at runtime, it continually checks the conditions described in the specification against observed properties and characteristics of the application and the cloud computing infrastructure 100). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Fleck to incorporate the teachings of Jain to include the method as claimed in claim 1, wherein the first integrity guideline and the first item of deployment information are made available by a creator of the first item of deployment information (Jain, Para. 0027). Doing so would aid to help recovery actions and enforcement techniques be used to control dynamic application behavior and system behavior in user-defined ways. That is; to enforce desired application behavior and system behavior at runtime, the mechanism of enforcement is separated from application-specific policy for controlling the application behavior (Jain, Fig.1, Para. 0022).
Regarding claim 3, the combination of Fleck in view of Jain teaches the method as claimed in claim 1, the first item of deployment information is checked against a runtime-integrity guideline of the runtime environment and a violation, including the properties of the first item of deployment information that violate the runtime-integrity guideline, is reported to the user (Jain, Para. 0027, when on any given host or VM the monitor code is executed at runtime, it continually checks the conditions described in the specification against observed properties and characteristics of the application and the cloud computing infrastructure 100. On detecting a condition to be satisfied or violated, the monitor application instance triggers the specified user-defined action such as reporting an error to the developer and cloud operator, logging a message to storage, and executing a recovery code to enforce desired application and system behavior, etc.). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Fleck to incorporate the teachings of Jain to include the first item of deployment information is checked against a runtime-integrity guideline of the runtime environment and a violation, including the properties of the first item of deployment information that violate the runtime-integrity guideline, is reported to the user (Jain, Para. 0027). Doing so would aid to help recovery actions and enforcement techniques be used to control dynamic application behavior and system behavior in user-defined ways. That is; to enforce desired application behavior and system behavior at runtime, the mechanism of enforcement is separated from application-specific policy for controlling the application behavior (Jain, Fig.1, Para. 0022).
Regarding claim 4, the combination of Fleck in view of Jain teaches the method as claimed in claim 1, wherein the second item of deployment information and the second integrity guideline have been stored persistently on the host system for each second application, and the first item of deployment information and the assigned first integrity guideline are stored on the host system after the elimination of the violation (Fleck, Para. 0048, The managed partition 210 may have policies applied to it to secure the applications running on and data stored in the managed partition) and (Fleck, Para. 0176, the IPC manager may identify shared data from a first application (1205). The first application may be accessed via an embedded browser of a client application. The IPC manager may detect a command to copy the shared data on the first application accessed via the embedded browser. Upon detecting the command to copy, the IPC manager may identify the selected data and may store the selected data onto a secure container. The secure container may be storage (e.g., memory and/or hard disk) dedicated, assigned or allocated to the embedded browser. The IPC manager may then subsequently detect a command to replicate (e.g., paste, enter, input, load) the shared data onto a second application. The second application may be accessed via the same embedded browser as the first application or another embedded browser across different user accounts and various client applications).
Regarding claim 5, the combination of Fleck in view of Jain teaches the method as claimed in claim 1, wherein the first integrity guideline is assigned to the first item of deployment information, in that the first integrity guideline is arranged as an integral part of the first item of deployment information, and/or in that a common digital signature is created with the aid of the first integrity guideline and the first item of deployment information, or in that a unique identifier is allocated to the first integrity guideline and to the first item of deployment information (Fleck, Para. 0106, access to the file system can be governed based on document access policies (e.g., encoded rules) maintained by the client application, in the documents and/or in the file system. A document access policy can limit access to the file system based on (1) which application or other component of the client device is requesting access, (2) which documents are being requested, (3) time or date, (4) geographical position of the client device, (5) whether the requesting application or other component provides a correct certificate or credentials, (6) whether the user of the client device provides correct credentials, (7) other conditions, or any combination thereof. A user's credentials can comprise, for example, a password, one or more answers to security questions (e.g., What is the mascot of your high school?), biometric information (e.g., fingerprint scan, eye-scan), and the like).
Regarding claim 6, the combination of Fleck in view of Jain teaches the method as claimed in claim 1, wherein the first integrity guideline contains at least one requirement imposed on at least one of the second applications with respect to: privileges for performing operations, access authorizations to predetermined file-system paths, a predetermined signature, a predetermined creator of the second application (Fleck, Para. 0105, the secure container can include an application that implements a file system that stores documents and/or other types of files. The file system can comprise a portion of a computer-readable memory of the client device. The file system can be logically separated from other portions of the computer-readable memory of the client device. In this way, enterprise data can be stored in a secure container and private data can be stored in a separate portion of the computer-readable memory of the client device for instance. The secure container can allow the CEB, network applications accessed via the CEB, locally installed applications and/or other components of the client device to read from, write to, and/or delete information from the file system (if authorized to do so)).
Regarding claim 7, the combination of Fleck in view of Jain teaches the method as claimed in claim 6, wherein each of the requirements in the first integrity guideline is valid for the at least one second application as a whole, or valid for at least one of the second container instances of the at least one second application, or valid for both the first container instances and the second container instances (Fleck, Para. 0008, the IPC manager may subsequently detect a second command to retrieve data from the secure container and to replicate the data onto the second application via the embedded browser. Responsive to detection of the second command, the IPC manager may determine a policy to apply to the data maintained on the secure container).
Regarding claim 8, the combination of Fleck in view of Jain teaches the method as claimed in claim1, wherein a range of validity of the first integrity guideline is established by a skip-mark which has been assigned to at least one container image or to at least one second item of deployment information (Fleck, Para. 0163, in some embodiments, the policy 1145 may specify which destination applications 1115B-N are permitted to replicate the data 1125. In some embodiments, the policy 1145 may specify which device types of the client accessing the second application 1115B are permitted to replicate the data 1125. In some embodiments, the policy 1145 may specify which data types of the data 1125 permitted to be replicated to the second application 1115B. The policy 1145 may also be context-specific in specifying whether the replication of the data 1125 is to be permitted. In some embodiments, the policy 1145 may specify locations from which the client accessing the second application 1115B are permitted to replicate the data 1125. In some embodiments, the policy 1145 may specify which account identifiers with which the second application 1115B is accessed are permitted to replicate the data 1125. In some embodiments, the policy 1145 may specify whether one or more portions of the data 1125 are to be altered or removed (e.g., redacted, obscured, blacked-out, deleted) prior to replication onto the second application 1115B).
Regarding claim 9, the combination of Fleck in view of Jain teaches the method as claimed in claim 1, wherein the violation is indicated to the user via a user interface (Fleck, Para. 0174, in some embodiments, the data transfer engine 1130 may insert the data 1125 onto a location within a graphical user interface of the second application 1115B accessed via the embedded browser 418A or 418B. In some embodiments, the data transfer engine 1130 may replicate the data 1125 with the one or more portions removed by the policy enforcer engine 1135 in accordance with the policy 1145).
Regarding claim 10, the combination of Fleck in view of Jain teaches the method as claimed in claim 1, wherein at least one predefined rule, for eliminating the violation, and instructions resulting therefrom are contained in the runtime environment (Fleck, Para. 0107, the document access policy can instruct the secure container or client application to delete the documents from the secure container or otherwise make them unavailable when the specified time period expires or if the client device is taken outside of the defined geographic zone).
Regarding claim 11, the combination of Fleck in view of Jain teaches the method as claimed in claim 9, wherein the elimination of the violation is made available via the user interface or via the predefined rule and further modalities for eliminating the violation in an application-specific deployment guideline in the runtime environment (Fleck, Para. 0163, the policy 1145 may specify whether one or more portions of the data 1125 are to be altered or removed (e.g., redacted, obscured, blacked-out, deleted) prior to replication onto the second application 1115B).
Regarding claim 12, the combination of Fleck in view of Jain teaches the method as claimed in claim 1, wherein the fallback configuration includes fewer properties with respect to privileges for performing operations, access authorizations to predetermined file-system paths, the predetermined signature or the predetermined creator in comparison with the standard configuration (Jain, Para. 0028, by using recovery actions and enforcement modules on the hosts. A host may have one recovery action or enforcement module to handle all application-monitor pairs, or a host may have application-specific recovery actions and enforcement modules. Monitors, recovery actions, and enforcement modules may operate in the user-space where possible, or in the host kernel-space (e.g., in a hypervisor in the cloud service layer 104 or OS) where permissible). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Fleck to incorporate the teachings of Jain to include the method as claimed in claim 1, wherein the fallback configuration includes fewer properties with respect to privileges for performing operations, access authorizations to predetermined file-system paths, the predetermined signature or the predetermined creator in comparison with the standard configuration (Jain, Para. 0028). Doing so would aid to help recovery actions and enforcement techniques be used to control dynamic application behavior and system behavior in user-defined ways. That is; to enforce desired application behavior and system behavior at runtime, the mechanism of enforcement is separated from application-specific policy for controlling the application behavior (Jain, Fig.1, Para. 0022).
Regarding claim 13, the combination of Fleck in view of Jain teaches the method as claimed in claim 1, wherein an orchestration unit carries out the checking, reporting and eliminating in an orchestrated environment (Fleck, Para. 0066, the application management framework 314 is responsible for orchestrating the network access on behalf of each application 310).
In regards to claim 14, the system claim 14 is similarly analyzed and rejected as the method claim 1.
In regards to claim 15, the computer-program product claim 15 is similarly analyzed and rejected as the method claim 1 and system claim 14.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
THIS ACTION IS MADE FINAL. 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 GITA FARAMARZI whose telephone number is (571)272-0248. The examiner can normally be reached Monday- Friday 9:00 am- 6:00 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, Jorge L. 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.
/GITA FARAMARZI/Examiner, Art Unit 2496
/JORGE L ORTIZ CRIADO/Supervisory Patent Examiner, Art Unit 2496
Prosecution Insights