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 .
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
The following title is suggested: “Distributed Intelligent System and Analyzing Manifestation of an Application”.
The abstract of the disclosure is objected to because it recites verbatim as claim language. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
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 1-20 are rejected under 35 U.S.C. 101 because
As per claims 1, 8 and 15,
under Step 2A, Prong 1,
Claims 1, 8 and 15 recite
A method for analyzing a manifest of an application the method comprising,
accessing an application that is tasked with performing a set of functions, wherein the set of functions are outlined in a manifest for the application and accessing the manifest merely recite insignificant extra solution activity such as data gathering which does not integrate the judicial exception into a practical application. See MPEP 2106.05(g).
Under Step 2 A prong 2
A method for analyzing a manifest of an application the method comprising,
parsing the manifest to identify each function in the set of functions and selecting one or more artificial intelligence (AI) models to perform each function in the set of functions can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process. MPEP 2106.05(d).
Under Step 2 B
analyzing a manifest… parsing the manifest to identify each function in the set of functions and selecting one or more artificial intelligence (AI) models to perform each function in the set of functions can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process cause operations does nothing more than additional insignificant extra solution activity to the judicial expectation, such as data gathering see MPEP 2106(g). Accordingly, the additional elements don’t integrate the abstract idea into practical application because it does not impose any meaningful limits on practicing the abstract idea thus fail to integrate the abstract idea into practical application. See MPEP 2106.05(f).
Regarding claim 2
selecting the one or more AI models includes interchangeably swapping static logic code and semantic code based on an identified function can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process. MPEP 2106.05(d).
Regarding claim 3
the semantic code is run by the one or more AI models can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process. MPEP 2106.05(d).
Regarding claim 4
the static logic code is compiled code based on a set of rules and procedures can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process. MPEP 2106.05(d).
Regarding claim 5
interchangeably swapping static logic code and semantic code is performed by a semantic kernel can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process. MPEP 2106.05(d).
Regarding claim 6
the manifest of the application includes a name, a version, trust information, and privileges that the application requires to execute can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process. MPEP 2106.05(d).
Regarding claim 7
wherein the manifest of the application is described in an extensible markup language can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process. MPEP 2106.05(d).
With respect to claims 15-20, the claim is directed to a memory including computer executable instructions... However, applicant describes the term readable medium as including carrier wave signals (see, applicant's specification, paragraph [0073]). Such transitory, propagating signals do not fall within any category of statutory subject matter. Thus, the claims are directed to non-statutory subject matter. See MPEP § 2106.
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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Beck et al US 2005/0114494 in view of Biggerstaff USPN 8,060,857.
Regarding claims 1 and 15
Beck et al teaches
accessing an application that is tasked with performing a set of functions, wherein the set of functions are outlined in a manifest for the application [0081] a cooperative multitasking system requires that the scheduled tasks relinquish control of a thread so that other tasks may be run. Since the translation of RDL code is controlled, a determination is made as to where each task will relinquish control. A task relinquishes control simply by returning in the normal fashion from the currently executing function. However, prior to returning, each task will update a stack frame that contains information about parameters, local variables, and where in the function to jump upon reentry (details on the stack frames appear hereinbelow). Since a task switch involves a function return, the system stack is unwound and lost. Consequently, the system stack can be restricted to a depth of one such that function calls between rules involve a return to the runtime prior to a callee function entry. When a function returns to the runtime, one of two execution pathways can occur. Either the runtime immediately enters the callee function and begins execution on the same thread, or the task stack frame is pushed onto the work item queue and thus, cause a task switch];
accessing the manifest [0122] referring now to FIG. 7B, there are illustrated blocks associated with the manifest component 508 of the model-based management architecture. The manifest that ships with the application contains information from the models and source code attribution in a machine-readable form for use by management system services. Administrative tasks for an application are defined within the manifest. There can be a number of manifests generated that correspond to the models, including the following; a first manifest subcomponent 707 associated with component dependencies, relationships between the components, and service roles; a second manifest subcomponent 708 associated with events, probes, rules, and actions; a third manifest subcomponent 709 associated with settings and assertions; a fourth manifest subcomponent 710 associated with commands (i.e., cmdlets) and administrative roles; a fifth manifest subcomponent 711 associated with distributed environments; and a sixth manifest subcomponent 712 associated with deployment];
selecting one or more artificial intelligence (AI) models to perform each function in the set of functions [0116] the subject model-based system can employ various artificial intelligence based schemes for carrying out various aspects thereof. For example, with respect to models, a process for determining what models can be utilized for a given instance or implementation can be facilitated via an automatic classification system and process. Moreover, such classifiers can be used to build operational profiles of the system that start to detect system patterns, and learn what is a good state, a bad state and, successful and unsuccessful transactions. This information can then be fed back into the corresponding model and used as an updated model for a follow-on system] and [0104] referring now to FIG. 5, there is illustrated a model-based management architecture 500 utilizing a rules engine in accordance with the present invention. The model-based management approach allows a developer to describe an application or service 502 in terms of its constituent components and desired states in terms of functionality, configuration, security, and performance. Thus, an application or service description 504 facilitates describing the application or service 502 in terms of one or more manageable components, including at least a models component 506, manifest component 508, system component 510, and tasks component 512. The model-based management system 500 utilizes an attribution component 514 to facilitate attribution of the source code from the model component 506 to the manifest component 508]. Beck et al teaches manifest application but doesn’t teach explicitly parsing the manifest to identify each function in the set of functions, however, Biggerstaff teaches (column 82, line 2, the suchthat field allows the generator to keep the description of a loop in a propositional-based semantic form, which allows the structural nature of loops to be inferred and realized very late in the development of the target program based on a few, relatively simple logic rules. Importantly, it avoids much program analysis and syntactic parsing that might be required if loop were specified early-on in a true GPL form. For example, a loop may be destined to be eliminated because its index has become a constant value through partitioning. The generator does not have to parse and analyze AST structures to determine this situation. A simple semantic rule allows it to infer this fact from a few propositions that logically describe the loop. Further, simple addition of new propositions can significantly alter the resulting GPL structure. This is a case where one representation of the loop (i.e., semantic-based propositions) makes early processing easy (e.g., partitioning) and a different representation (i.e., a GPL form) makes specification of executable code easy. This section provides a snapshot of the process that gets from the first representation to the second). Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate parsing the manifest. The modification would have been obvious because one of ordinary skill in the art would have been motivated to combine teaching into application manifest parsing reduces manual intervention in repetitive tasks such as reading logs, processing XML feeds, or extracting information.
Regarding claims 2, 9 and 16
Beck et al teaches
selecting the one or more AI models includes interchangeably swapping static logic code and semantic code based on an identified function [0035] In order to facilitate scheduling, rules are written in RDL and can then translated into any suitable language, for example, C#. The translated code is designed to support scheduling among large numbers of rules by introducing "yielding" semantics into the code. In this case a "yield" results in a context switch from rule code to engine code and into other rule code. This allows the rules engine 108 to multitask rules with a limited number of threads]. The feature of providing swapping or switching… would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claims 3, 10 and 17
Biggerstaff teaches
the semantic code is run by the one or more AI models [column 82, line 2, the suchthat field allows the generator to keep the description of a loop in a propositional-based semantic form, which allows the structural nature of loops to be inferred and realized very late in the development of the target program based on a few, relatively simple logic rules. Importantly, it avoids much program analysis and syntactic parsing that might be required if loop were specified early-on in a true GPL form. For example, a loop may be destined to be eliminated because its index has become a constant value through partitioning. The generator does not have to parse and analyze AST structures to determine this situation. A simple semantic rule allows it to infer this fact from a few propositions that logically describe the loop. Further, simple addition of new propositions can significantly alter the resulting GPL structure. This is a case where one representation of the loop (i.e., semantic-based propositions) makes early processing easy (e.g., partitioning) and a different representation (i.e., a GPL form) makes specification of executable code easy. This section provides a snapshot of the process that gets from the first representation to the second]. The feature of providing semantic…would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claims 4, 11 and 18
Beck et al teaches
the static logic code is compiled code based on a set of rules and procedures [0078] prior to describing the basics of a scheduling solution, a clear description of the problem is warranted. Consider a rules document that contains a large number of rules, and within the document are the following three rules, as shown below, called CheckCDiskSpace, CheckCounter, and CreateEvent. Also consider for the sake of simplicity, that the rules engine is configured to utilize only a single thread for multitasking among a set of tasks. (Note that CheckCDiskSpace contains an attribute that marks it as a startup rule and that it should be run in parallel with other rules similarly marked.) Conceptually, the rules engine processes the compiled assembly and constructs a list of all the rules that must be run in parallel, e.g., CheckCDiskSpace shown below. Each rule is then placed in a task execution queue for consumption by a rules engine thread. In the case of the rules shown below, CheckCDiskSpace is placed in the initial execution queue. At some point in time, a thread sequences the rule and begins to execute CheckCDiskSpace. At some later point in time, the thread encounters CheckCounter. The thread invokes this internal function by invoking the function synchronously just as it appears, implying that the translated program language code (e.g., C#) will appear almost exactly as shown in the RDL sample below]. The feature of providing compiling… would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claims 5, 12 and 19
Beck et al teaches
interchangeably swapping static logic code and semantic code is performed by a semantic kernel [0035] In order to facilitate scheduling, rules are written in RDL and can then translated into any suitable language, for example, C#. The translated code is designed to support scheduling among large numbers of rules by introducing "yielding" semantics into the code. In this case a "yield" results in a context switch from rule code to engine code and into other rule code. This allows the rules engine 108 to multitask rules with a limited number of threads]. The feature of providing swapping or switching… would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claims 6, 13 and 20
Beck et al teaches
the manifest of the application includes a name, a version, trust information, and privileges that the application requires to execute [0132] If a manifest describes the default installation or recommended best practices from the manufacturer, an administrator may want to change things. For example, with respect to health rules the administrator may want to change a threshold from thirty to forty, or install components, or override a security policy. This can be done by creating a customized version of the manifest to override the manifest bundled by the manufacturer. A different version can be detected during installation, allowing a user the option to select the default manifest or the custom manifest. Alternatively, there can be a separate file the system reads that lists the overrides, which are then displayed for selection by the user to be applied to the default manifest or during installation such that the default settings are overridden.] and [0153] there is also provided a manifest storing and editing service 788 for use by the administrator. The manifest service 788 has associated therewith a protocol 789 and a viewer 790 to expose these manifest functions to the administrator. The manifest service 788 feeds the manifests to the administrator via the protocol 789 and viewer 790, allowing the administrator to view and change the manifests before installation. The manifest service 788 also facilitates versioning of the manifests according to updates and customizations]. The feature of providing version…would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claims 7 and 14
Beck et al teaches
the manifest of the application is described in an extensible markup language [0159] the model-based management framework employs the RDL to enable defining of rules for the purpose of monitoring the availability of software and hardware. Rules written in RDL are executed by the runtime engine as part of the monitoring service. The purpose of the RDL is to test assertions, enforce constraints using runtime information, make inferences, perform correlation, and communicate results of dynamic tests to other components. The RDL defines the rule type (i.e., class) while a separate XML (eXtensible Markup Language) document is used to create instances of the rule type by specifying the parameter values necessary for its instantiation. There is a schema for describing the sequence of steps the system should take for problem detection, diagnosis, resolution, verification, and alerting. This is what is described in the model, expressed in the manifest, and executed/managed by the monitoring system]. The feature of providing XML…would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claim 8
Beck et al teaches
selecting a set of AI models to perform a set of functions of an application based on a manifest of the application [0122] referring now to FIG. 7B, there are illustrated blocks associated with the manifest component 508 of the model-based management architecture. The manifest that ships with the application contains information from the models and source code attribution in a machine-readable form for use by management system services. Administrative tasks for an application are defined within the manifest. There can be a number of manifests generated that correspond to the models, including the following; a first manifest subcomponent 707 associated with component dependencies, relationships between the components, and service roles; a second manifest subcomponent 708 associated with events, probes, rules, and actions; a third manifest subcomponent 709 associated with settings and assertions; a fourth manifest subcomponent 710 associated with commands (i.e., cmdlets) and administrative roles; a fifth manifest subcomponent 711 associated with distributed environments; and a sixth manifest subcomponent 712 associated with deployment];
causing a first AI model in the set of AI models to perform a first operation for a first function in the set of functions, a first AI model generating output [0116] the subject model-based system can employ various artificial intelligence based schemes for carrying out various aspects thereof. For example, with respect to models, a process for determining what models can be utilized for a given instance or implementation can be facilitated via an automatic classification system and process. Moreover, such classifiers can be used to build operational profiles of the system that start to detect system patterns, and learn what is a good state, a bad state and, successful and unsuccessful transactions. This information can then be fed back into the corresponding model and used as an updated model for a follow-on system. Such classification can employ a probabilistic and/or statistical-based analysis (e.g., factoring into the analysis utilities and costs) to prognose or infer an action that a user desires to be automatically performed. For example, a support vector machine (SVM) classifier can be employed. Other classification approaches include Bayesian networks, decision trees, and probabilistic classification models providing different patterns of independence can be employed. Classification as used herein also is inclusive of statistical regression that is utilized to develop models of priority];
determining that a second AI model is to perform a second operation for the first function [0116] the subject model-based system can employ various artificial intelligence based schemes for carrying out various aspects thereof. For example, with respect to models, a process for determining what models can be utilized for a given instance or implementation can be facilitated via an automatic classification system and process. Moreover, such classifiers can be used to build operational profiles of the system that start to detect system patterns, and learn what is a good state, a bad state and, successful and unsuccessful transactions. This information can then be fed back into the corresponding model and used as an updated model for a follow-on system. Such classification can employ a probabilistic and/or statistical-based analysis (e.g., factoring into the analysis utilities and costs) to prognose or infer an action that a user desires to be automatically performed. For example, a support vector machine (SVM) classifier can be employed. Other classification approaches include Bayesian networks, decision trees, and probabilistic classification models providing different patterns of independence can be employed. Classification as used herein also is inclusive of statistical regression that is utilized to develop models of priority];
causing the first AI model to format the output to a scheme that is usable by the second AI model [0141] there is provided an instrumentation API 740 in communication with the application 714 to facilitate configuring instrumentation and the passing of instrumentation data with the application 714. The instrumentation API 740 has associated therewith a protocol 742 and a viewer 744 through which the instrumentation is exposed. The protocol 742 facilitates communicating API-related data with other components of the system 510. The viewer 744 displays data related to the instrumentation API 740. The instrumentation API 740 communicates with the managed application 714 via IPC (InterProcess Communication) 746. IPC is the automatic exchange of data between one program and another, either within the same computer or over a network. One example of an IPC function is performed when a user manually cuts and pastes data from one file to another using a clipboard. The counters are always published via shared memory, while the instrumentation is delivered on demand. The instrumentation API 740 also includes a schema 748 that describes the surface of the instrumentation classes in manner similar to an events schema. There may also be included an instrumentation log (not shown); however, many administrators prefer to utilize an event log
causing the first AI model to transmit the output, which is formatted in the scheme, to the second AI model [0033] the runtime engine 108 takes as its input rules code expressed in RDL, as well as configuration data 110 that is used to instantiate the rule code. The rules code is organized into a series of rule types. Each type expresses the logic required to determine if a hardware and/or software target is in a desired state for the system being monitored. If the type determines that the target is not in the desired state, it typically performs some action. For example, the code below utilizes a rule type that suppresses sending a flood of error events when the system goes into an undesirable state. Note that the rule logic is demarcated and bounded by RuleType . . . End RuleType keywords. The code is translated by the translator component 106 and loaded into the rules engine 108 thus putting it into a state from which it can be instantiated. Rule code is instantiated by loading the configuration data 1 10 into the runtime engine 108, which configuration data specifies which rules to run, as well as the parameters required to run the rule];
causing the second Al model to perform the second operation for the first function using the output from the first AI model [[0104] referring now to FIG. 5, there is illustrated a model-based management architecture 500 utilizing a rules engine in accordance with the present invention. The model-based management approach allows a developer to describe an application or service 502 in terms of its constituent components and desired states in terms of functionality, configuration, security, and performance. Thus, an application or service description 504 facilitates describing the application or service 502 in terms of one or more manageable components, including at least a models component 506, manifest component 508, system component 510, and tasks component 512. The model-based management system 500 utilizes an attribution component 514 to facilitate attribution of the source code from the model component 506 to the manifest component 508]. The feature of providing AI models…be obvious for the reasons set forth in the rejection of claim 1.
Relevant Prior Art
US 7558778 B2 Carus et al teaches Semantic Exploration And Discovery
US 11042369 B1 Kimball; et al teaches Systems And Methods For Modernizing And Optimizing Legacy Source Code
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Anil Khatri whose telephone number is (571)272-3725. The examiner can normally be reached M-F 8:30-5:00.
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.
/ANIL KHATRI/Primary Examiner, Art Unit 2191
Prosecution Insights