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 .
This Office Action is in response to the filing date of 03/05/2024.
Claims 1-20 are pending and have been considered below.
Note
Applicant is respectfully reminded that although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See MPEP 2145 [R-6]
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 1-6, 9-13, and 16-19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Patent No. 9602344 to Iyengar.
Per claims 1, 9, and 16, Iyengar teaches a method comprising:
monitoring a file system of a workspace (see col.13, lines 49-50 “…monitor the file systems 114 of the source systems 110 (i.e. workspace)…”), the workspace including a playbook (see also at least col.4, lines 30-36 “The source systems 110 (i.e. workspaces) of an enterprise may include systems providing services (i.e. playbooks), such as a database server that provides access to data of a database (e.g., in response to queries in the Structured Query Language (SQL)), a directory information server providing directory information about the enterprise (e.g., a Lightweight Directory Access Protocol (LDAP) server), or the like”);
detecting a modification to the file system of the workspace (see at least col.5, lines 52-58 “…The file system reader module 117 can also determine a difference between the current state and a previous state of the file systems 114. For example, the file system reader module 117 can identify files that have changed since a given previous file system state (along with the data of the changed files), the files that have been added (along with the data of the added files), and the files that have been deleted.…”);
injecting, by a processing device, a path into a current configuration associated with the playbook to produce an updated configuration associated with the playbook, wherein the path corresponds to the modification to the file system of the workspace (see at least col.9, lines 5-27 “…The customization module 126 could then write the hexadecimal string into the metadata for the file system 124 and also modify the entry of the file/etc/fstab from /dev/sda1/ext3 to UUID=f6f514a9-2954-473c-9a47-664a4d4eb0d4/ext3 which has the effect of mounting a file system, whose unique ID is “f6f514a9-,2954-473c-9a47-664a4d4eb0d4”, at the root directory of a Linux system…”); and
triggering a language server to reinitialize based on the updated configuration associated with the playbook (see at least col.12, lines 61-67 “Initial Data Gathering. As discussed above, the site manager 100 obtains information from the source systems 110, including configuration information and data from the file systems 114. The site manager 100 further customizes (i.e. reinitializes) the enterprise-based application (as embodied in the source systems 110) so that it will function properly on the cloud provider 130. Additionally, the site manager 100 may further monitor any changes to the source system 110, updating the file systems 124 to reflect the changes (i.e. reinitializing)...”).
Per claims 2, 10, and 17, Iyengar further teaches:
wherein the modification comprises addition of a playbook adjacent file to the workspace (see at least col.5, lines 52-58 “The file system reader module 117 can also determine a difference between the current state and a previous state of the file systems 114. For example, the file system reader module 117 can identify files that have changed since a given previous file system state (along with the data of the changed files), the files that have been added (along with the data of the added files), and the files that have been deleted”), and reinitialization of the language server enables support for one or more language features based on contents of the playbook adjacent file (see at least col.12, lines 61-67 “Initial Data Gathering. As discussed above, the site manager 100 obtains information from the source systems 110, including configuration information and data from the file systems 114. The site manager 100 further customizes (i.e. reinitializes) the enterprise-based application (as embodied in the source systems 110) so that it will function properly on the cloud provider 130”).
Per claim 3, Iyengar further teaches:
wherein the one or more language features comprise at least one of a go to definition feature, a hover feature, an autocompletion feature, or a validation feature (see at least col.4, lines 30-45 “ see also at least col.4, lines 30-67 “The source systems 110 (i.e. workspace) of an enterprise may include systems providing services (i.e. playbooks), such as a database server that provides access to data of a database (e.g., in response to queries in the Structured Query Language (SQL)), a directory information server providing directory information about the enterprise (e.g., a Lightweight Directory Access Protocol (LDAP) server), or the like” [Note, SQL provides a validation feature for validating queries to ensure correct format before processing the queries]).
Per claims 4, 11, 18
wherein the one or more language features comprise the autocompletion feature and the method further comprises: identifying a name of a function defined in the playbook adjacent file utilizing the autocompletion feature, the name of the function identified based on user input provided during editing the playbook via a code editor; and presenting the name of the function as an autocompletion suggestion in the code editor.
Per claims 5 and 12, Iyengar further teaches:
wherein the modification comprises addition of a playbook adjacent collection to the workspace (see at least col.5, lines 52-58 “The file system reader module 117 can also determine a difference between the current state and a previous state of the file systems 114. For example, the file system reader module 117 can identify files that have changed since a given previous file system state (along with the data of the changed files), the files that have been added (along with the data of the added files), and the files that have been deleted”) and the path that corresponds to the modification to the file system comprises a path of the playbook adjacent collection (see at least col.9, lines 5-27 “…The customization module 126 could then write the hexadecimal string into the metadata for the file system 124 and also modify the entry of the file/etc/fstab from /dev/sda1/ext3 to UUID=f6f514a9-2954-473c-9a47-664a4d4eb0d4/ext3 which has the effect of mounting a file system, whose unique ID is “f6f514a9-,2954-473c-9a47-664a4d4eb0d4”, at the root directory of a Linux system…”).
Per claims 6, 13 and 19, Iyengar further teaches:
creating the playbook adjacent collection based on a namespace name, a collection name, and an initialization path, wherein creation of the playbook adjacent collection includes scaffolding the playbook adjacent collection with one or more files in a predefined layout; and adding the playbook adjacent collection to the workspace (see at least col.2, lines 44-55 “A mount table file is modified to use a unique identifier for a file system of the source system, the unique identifier may be generated and stored within metadata of the file system. When the corresponding operating system begins execution and the mount table file is analyzed to establish the file system mount points, the unique identifier is located within the file system metadata, thereby correlating the file system with the proper device name of the underlying storage, regardless of whether the device names differ between the source system and the cloud provider”).
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, 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 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. 9602344 to Iyengar in view of U.S. Pub. No. 20230229788 to Pieno.
Per claims 7 and 14, Iyengar does not explicitly teach
wherein the one or more files comprise at least one template plugin file.
Pieno teaches an analogous art relates to monitoring file system, comprising:
one or more files comprise at least one template plugin file (see at least paragraph [0071] “A plugin configurer 280 can be used to configure agent plugins according to a received configuration template. The configuration template describes data to be gathered by the agent, frequency with which to gather the data, and formats to be used for generating augmentation and tag data generated by the plugin for sending to a vulnerability scanner”).
It would have been obvious for a person of an ordinary skilled in the art as of the effective filing date of the claimed invention to modify the teaching of Iyengar to incorporate the teaching of Pieno to include at least one template plugin. One would have been motivated to do so because it provides predesigned structures to allow users to quickly create consistent contents without building from scratch.
Claims 8, 15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. 9602344 to Iyengar in view of U.S. Pub. No. 20210201236 to Makhija.
Per claims 8, 15 and 20, Iyengar further teaches:
presenting the playbook via a code editor (see at least col.14, lines 32-36 “FIGS. 4A-4B respectively illustrate example graphical user interfaces used in the process of replicating an enterprise-based application on a cloud provider and creating instances of that application, according to one embodiment…”).
Iyengar does not explicitly teach
determining one or more playbook task suggestions based on analysis of contents of the playbook via an artificial intelligence (AI) feature; and
presenting at least one of the one or more playbook task suggestions via the code editor.
Makhija teaches an analogous art relates to artificial intelligence (AI), comprising:
determining one or more playbook task suggestions based on analysis of contents of the playbook via an artificial intelligence (AI) feature; and presenting at least one of the one or more playbook task suggestions via the code editor (see at least paragraph [0013] “…data models working with identified block of data objects, the impact data and AI based processing logic for recommending an action/task to a user. The system includes reconfiguration of a plurality of functions of the one or more applications in real-time based on the recommended action/task for accurate results”).
It would have been obvious for a person of an ordinary skilled in the art as of the effective filing date of the claimed invention to modify the teaching of Iyengar to incorporate the teaching of Makhija to use an artificial intelligence (AI) to suggest actions to be performed to the user. One would have been motivated to use AI for suggesting actions/tasks to the user for accurate results.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US20110145216 relates to monitoring changes to file systems.
US11966592 relates to data loss for modified file system
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PHILLIP H NGUYEN whose telephone number is (571)270-1070. The examiner can normally be reached Monday-Friday 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, Wei Zhen can be reached at (571) 272-3708. 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.
/PHILLIP H NGUYEN/Primary Examiner, Art Unit 2191