DETAILED ACTION
The Office Action is in response to claims filed 06/27/2024
Claims 1-20 are pending.
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 .
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.
Claims 9-14 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 9-14 recites the limitation "The operations of" in line 1 respectively. There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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-3, 8-10, and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over US 20200159525 A1 hereinafter “Bhalla” in view of US 20240380712 A1 hereinafter “Levitt”.
With regards to claim 1, Bhalla teaches
A method comprising: receiving, at a generative platform, a project specification; (Bhalla [0135], “FIG. 7 illustrates a workflow for onboarding one or more projects. In particular, the presently described system is capable of automatically discovering software assets in an organization and onboarding one or more software assets into the system to track the software asset throughout its lifecycle [receiving, at a generative platform]. In the onboarding of one or more new or existing projects, project or projects to onboard are selected and identified 702. Project onboarding 702 can be based on number or content of tickets, for example, in an epic database, or by business priority of the organization, ease of resolution, software specification, or by risk evaluation [a project specification].”)
determining, by the generative platform, one or more contexts from the project specification; (Bhalla [0050], “All of the features and conditions that contribute to the structure and operation of each software asset are herein referred to as the software context, and the software context contributes to and determines the risks posed by the software asset after deployment. During the ideation phase of a project to create a software asset, the context of the software asset may be limited to the features desired by a business unit, and the context may be written entirely in natural language. Software context at the pre-development phase is often stored as one or more stories or epics (long stories) on a business organization platform, where stories are usually short, simple descriptions of a feature or set of features told from the perspective of the person who desires the new capability [from the project specification] … Software context can be gleaned from these stories by natural language processing to extract information such as desired features, jurisdiction of software use, use case of the software, population of software use, and other context relating to the software operation and security environment [determining, by the generative platform, one or more contexts]. Project lists can be stored, for example, in internal systems of record or databases or project management software comprising core planning, executional, project accounting, and analysis systems pertaining to the business software assets. In the early development of a software project, context repositories are called upon to provide precedents and libraries, all of which contribute to the context of the software.”)
determining, by the generative platform and based on the project specification, a set of tasks; (Bhalla [0115], “FIG. 5 illustrates a method of extracting context data for a project and selecting requirements based on the extracted context. A context database 502 is set up for a new or existing project software asset and the present method generates a set of work tasks [a set of tasks] by incorporating the project settings and software context of the software asset. From the context database 502 is created a link to the project 504, which includes a location where project settings can be updated 506, and a location where the software context can be updated 508. The project settings can include details of how a project is categorized amongst other projects in the system, and the project can be contributed to by both human and machine work participants, which provides additional attributes which describe the project [determining, by the generative platform and based on the project specification].”)
Bhalla does not teach: executing each task in the set of tasks with a corresponding agent, wherein the executing includes:
determining context information; receiving output from a language model;
enhancing the output from the language model with the context information; and
saving the output to an integrated development environment.
However, in an analogous art Levitt teaches executing each task in the set of tasks with a corresponding agent, (Levitt [0066], “The development environment may include a plurality of agent components (124). Each of the agent components may be an artificial intelligence-based agent component configured to perform a specific task within the development environment and to generate an output associated with that task for use by another agent component or other components of the development environment. One agent component may call another agent component. Agent components may input their outputs into other agent components.”) [Examiner’s Note: there are a plurality of agent components associated with a corresponding task. Each one is executed to generate an output associated with the task thereby achieving the execution of a plurality of tasks in the set of tasks] wherein the executing includes:
determining context information; (Levitt [0109], “Receiving the text from the chat between participants may include receiving summaries, keywords and/or key phrases of or obtained from the text from a chat text processing agent. Additionally, receiving the text from the chat between participants may include receiving contextual data relating to the chat text, for example information or insights relating to documentation and/or a codebase obtained from a document ingesting agent (124H), a codebase agent (1241), or the like. The text that the primitive element agent component receives may therefore be enriched text that includes chat text and context around the chat text.”)
receiving output from a language model; (Levitt [0110], “With reference to FIG. 4, using (222) the text to obtain the text-based output may include each of the one or more primitive element agent components: compiling (250) a prompt based on the text; inputting (252) the prompt into the language model; and receiving (254) the text-based output from the language model.”)
enhancing the output from the language model with the context information; (Levitt [0115], “The user input may have been input into the development environment via the chat engine or via the user interface (e.g., by way of clicking on one or more graphical elements, typing, etc.). The method may include each of the one or more primitive element agent components inputting (232) into the language model the user input as feedback on the text-based output generated for the prompt. This may for example include using the user input text to obtain an updated text-based output from the language model. The method may include each of the one or more primitive element agent components updating (234) or adjusting the text-based output and/or the visual representation of the text-based output based on the user input. This may for example be in the form of adding to or completing the text-based output and/or visual representation thereof, for example, by adding connections to other steps or flows, adding configuration and related data points or the like.”) [Examiner’s Note: Agents (LLMs or AI) can have inputs and outputs that are fed into one another with feedback and user input that allows a method of updating, completing, configuring and updating language model outputs.] and
saving the output to an integrated development environment. (Levitt [0049-50], “Aspects of the present disclosure provide a development platform for creating application software. The development platform may provide a development environment. The development environment may be a low-code development environment in which human users can write functional code for steps and/or in which the writing of those steps can be outsourced to agent components or modules. In some cases, the development environment may be a collaborative development environment. The development environment may be chat-based in that application software can be created based on voice- and/or text-based chat between various participants accessing the development platform. The development environment uses chat and visual tools and a series of language model agents to auto-generate code and visual representations of that code in a user interface for tweaking by participants in the chat. As will be explained below, auto-generating code may use agent components that generate text-based outputs from chat text.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Levitt into the teachings of Bhalla. This combination of teachings would have resulted in a method to determine a project requirement task list that is contextually relevant, as in Bhalla, with a development environment for collaboration and language model interaction, as in Levitt. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing an application development environment with agents to support software hyper-personalization, fault-tolerant, and distributed live updates to code (Levitt [0103-104]).
With regards to claim 2, the rejection of claim 1 is incorporated.
Bhalla further teaches the determining a set of tasks comprising:
determining a requirement of the project specification; (Bhalla [0081], “ Based on the software context, the selection module 110 is employed to select a plurality of task requirements for the software asset from the plurality of task requirements in the knowledge database 108, with the selected task requirements applicable to the context data stored in the context database 106 for the software asset under development or maintenance. The selection module 110 can also use computational methods that include machine learning or artificial intelligence to combine and/or match the information in the context database 106 with the tasks in the knowledge database 108 to generate a set of tasks pertinent to the software under consideration.”)
creating a database schema based on the project specification; (Bhalla [0110], “Source code 306 can also be processed and context extracted by performing a meta analysis 314 on the data to extract meaning from words and code and/or by scanning the code 312 of the software asset if development has begun and source code exists for scanning. The configuration 307 of a software asset includes its operation specification that describes its running and execution environment. Context data in a configuration 307 can be processed by scanning the configuration 313 and/or sent directly to the context database 318. A configuration scan 313 reveals the software asset configurations, which can be specified by a manufacturer, and optionally locally tailored to adapt to local policies. Context data from a software specification 308 can contain stories or epics in the form of natural language, and the natural language is processed by natural language processing 316, optionally using an artificial intelligence system. Context data in test plans 309 stored as natural language can be processed by natural language processing 316, and context data in test plans 309 stored as computer-readable format can be extracted performing a meta analysis 314. All extracted context data is then stored in one or more context database 318.”)
creating a project structure and a dependency; (Bhalla [0063-68], “Source code 306 can also be processed and context extracted by performing a meta analysis 314 on the data to extract meaning from words and code and/or by scanning the code 312 of the software asset if development has begun and source code exists for scanning. The configuration 307 of a software asset includes its operation specification that describes its running and execution environment. Context data in a configuration 307 can be processed by scanning the configuration 313 and/or sent directly to the context database 318. A configuration scan 313 reveals the software asset configurations, which can be specified by a manufacturer, and optionally locally tailored to adapt to local policies. Context data from a software specification 308 can contain stories or epics in the form of natural language, and the natural language is processed by natural language processing 316, optionally using an artificial intelligence system. Context data in test plans 309 stored as natural language can be processed by natural language processing 316, and context data in test plans 309 stored as computer-readable format can be extracted performing a meta analysis 314. All extracted context data is then stored in one or more context database 318 … Manifest/configuration files: details about an application or system's state or behavior that is encoded in one or more source files (For example, .ini, .xml, .sql, .json files) containing identifiers or details to initialize the application/system, or instructions for how an application should behave … Dependencies: The list of self-contained components an application or system relies in order to properly function. Knowing dependency X is part of an application or system implies information about its behavior and state. e.g. if a library is known to interact with European General Data Protection Regulation (GDPR) data, if looking at dependencies, then application context includes GDPR requirement standards”) [Examiner’s Note: A meta-analysis will determine the intended state/behavior of a software application (or its structure) as well as any dependencies.]
Bhalla does not teach: creating a system interface; and
deploying the system interface to a cloud platform.
However, in an analogous art Levitt teaches creating a system interface; (Levitt [0055], “The development environment includes a user interface (114). The user interface may be displayed to the participants via their respective user terminals, which may be in the form of a computing device. The user interface may define a bounded context in the form of a space in which roles and actions, and ultimately the application software, relating to a functional unit within an organization, for example, can be described. The bounded context may be represented graphically in the user interface as a circle or other shape to which and in which actions or roles may be added and configured. The user interface includes functionality for managing actions and roles. The user interface may include functionality for managing actions against a role, setting permissions for a role, assigning agents to one or more roles and the like. Managing actions against roles may allow for control as to which agents (being users or systems) can call which actions (based on the role to which they are assigned).”) and
deploying the system interface to a cloud platform. (Levitt [0053-54], “ FIG. 1A is a schematic diagram which illustrates an exemplary system (100) for software development. The system includes a development platform (102) providing a development environment (104) which is accessible to a plurality of participants including human users via their respective user terminals (106) and optionally various artificial intelligence agent participants (such as the one or more agent components described herein). … The development platform may be provided by a computing device or computing devices and may include or have access to a processor (110) for executing the functions of components described below, which may be provided by hardware or by software units executing on the development platform. The software units may be stored in a memory component (112) and instructions may be provided to the processor to carry out the functionality of the described components. In some cases, for example in a cloud computing implementation, software units arranged to manage and/or process data on behalf of the development platform may be provided remotely.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Levitt into the teachings of Bhalla. This combination of teachings would have resulted in a method to determine a project requirement task list that is contextually relevant, as in Bhalla, with a development environment for collaboration and language model interaction, as in Levitt. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing an application development environment with agents to support software hyper-personalization, fault-tolerant, and distributed live updates to code (Levitt [0103-104]).
With regards to claim 3, the rejection of claim 1 is incorporated.
Bhalla further teaches wherein the set of tasks includes one or more of a constraint, a command, a resource, a performance, an evaluation, and a response format. (Bhalla [0046], “The term “task” refers to any control or requirement for the purpose of compliance, obtaining a functionality, or addressing a risk. The requirement can be a non-functional requirement (NFR) for a system or software being designed or developed, and/or a requirement that specifies criteria that can be used to judge the operation and/or risk of a system. Non-limiting examples of non-functional requirements include accessibility, adaptability, auditability, availability, capacity, certification, compatibility, configuration management, data integrity, data retention, dependency, deployment, development environment, disaster recovery, documentation, durability, efficiency (resource consumption for given load), exploitability, extensibility, failure management, fault tolerance (e.g. operational system monitoring, measuring, and management), legal and licensing issues or patent-infringement-avoidability, interoperability, maintainability (e.g. mean time to repair—MTTR), management, modifiability, network topology, operability, performance and/or response time (performance engineering), platform compatibility, privacy (compliance to privacy laws), portability, quality (e.g. faults discovered, faults delivered, fault removal efficacy), readability, reliability (e.g. mean time between/to failures—MTBF/MTTF), resilience, resource constraints (processor speed, memory, disk space, network bandwidth, etc.), response time, reusability, robustness, scalability (horizontal, vertical), security (cyber and physical), stability, supportability, testability, throughput, transparency, and usability (Human Factors) by target user community.”)
Claims 8-10 are directed to a system corresponding to the method limitations as disclosed in claims 1-3 respectively. Thus, claims 8-10 are rejected for the same reasons set forth in claims 1-3.
Claims 15-17 are directed to a computer processing system corresponding to the method limitations as disclosed in claims 1-3 respectively. Thus, claims 8-10 are rejected for the same reasons set forth in claims 1-3.
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Bhalla in view of Levitt as applied to claims 1, 8, and 15 above, and further in view of US 20160188647 A1 hereinafter “Chang”.
With regards to claim 4, the rejection of claim 1 is incorporated.
The combination of Bhalla and Levitt does not teach: wherein the identified task is to create a persistent store and, in response, a persistent store agent creates the persistent store by generating one or more of a configuration, a software object, a service, and a deployment scheme.
However, Chang teaches wherein the identified task is to create a persistent store and, in response, a persistent store agent creates the persistent store by generating one or more of a configuration, a software object, a service, and a deployment scheme. (Chang [0089-90], “In step S304, the application 111 receives input from a user specifying a name for the database to be created at the location specified in step S203. In one embodiment, the GUI generated by the application 111 includes a free form data input field that allows the user to enter alphanumerical text therein to provide a name for the database to be stored at the location specified in step S302. In step S306, the GUI generated by application 111 receives user input representing a table name for the table in the database being created … In step S312, the application 111 uses the values of the data items received in the GUI to create a configuration data object that includes a structure and format data for use in creating a metadata database for storing metadata associated with the at least one image file. This configuration data object created in accordance with the algorithm in FIG. 3 is usable by other modules of application 111 when completing module specific tasks such as processing the at least one image file and any metadata associated therewith according to at least one processing rule specified by the user as will be discussed hereinafter.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Chang into the teachings of Bhalla in view of Levitt. This combination of teachings would have resulted in a method to determine a project requirement task list that is contextually relevant, as in Bhalla, with a development environment for collaboration and language model interaction, as in Levitt, and specifying a database via a configuration data object, as in Chang. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of specifying metadata to be stored with a database structure to define rules, bundles, names, and files which enables enhanced editing functionality of applications (Chang [0027-29]).
Claim 11 is directed to a system corresponding to the method limitations as disclosed in claim 4 respectively. Thus, claim 11 is rejected for the same reasons set forth in claim 4.
Claim 18 is directed to a computer processing system corresponding to the method limitations as disclosed in claim 4 respectively. Thus, claim 18 is rejected for the same reasons set forth in claim 4.
Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Bhalla in view of Levitt as applied to claims 1, 8, and 15 above, and further in view of US 20210117624 A1 hereinafter “Aghajanyan”.
With regards to claim 5, the rejection of claim 1 is incorporated.
The combination of Bhalla and Levitt does not teach: further comprising generating a domain classification scheme that isolates the execution of the set of tasks included in a domain class to a corresponding agent that only executes the domain class.
However, in an analogous art Aghajanyan teaches further comprising generating a domain classification scheme (Aghajanyan [0116], “ In particular embodiments, the assistant system 140 may construct NGO as follows. The construction may begin with the sub-graph. In particular embodiments, the structural ontology may further define a graph structure comprising one or more core sub-graphs and one or more generic sub-graphs. The one or more core sub-graphs may be not accessible by third-party agents, and the one or more generic sub-graphs may be accessible by the third-party agents. Actions and objects may be modeled as nodes on the graph whereas attributes may be expressed as edges between nodes … Defining core sub-graphs and generic sub-graphs may be an effective solution for addressing the technical challenge of providing third-party users flexibility for designing their own semantic units while keeping the structural ontology intact as the core sub-graphs and generic sub-graphs are functionally separated and the fundamental structure of the ontology are maintained by the core sub-graphs which are only viewable to the third-party users. Although this disclosure describes constructing particular ontology by particular systems in a particular manner, this disclosure contemplates constructing any suitable ontology by any suitable system in any suitable manner.”) that isolates the execution of the set of tasks included in a domain class to a corresponding agent that only executes the domain class. (Aghajanyan [0100], “In particular embodiments, the server-assistant service module 301 may call the remote reasoning model 214 to process the output from the ASR module 208 and the NLU module 210. In particular embodiments, the reasoning model 214 may perform entity resolution and dialog optimization. In particular embodiments, the output of the reasoning model 314 may be sent to the agent 350 for executing one or more relevant tasks. In particular embodiments, the agent 350 may access an ontology module 440 to accurately understand the result from entity resolution and dialog optimization so that it can execute relevant tasks accurately. The ontology module 440 may provide ontology data associated with a plurality of predefined domains, intents, and slots. The ontology data may also comprise the structural relationship between different slots and domains. The ontology data may further comprise information of how the slots may be grouped, related within a hierarchy where the higher level comprises the domain, and subdivided according to similarities and differences. The ontology data may also comprise information of how the slots may be grouped, related within a hierarchy where the higher level comprises the topic, and subdivided according to similarities and differences. Once the tasks are executed, the agent 350 may return the execution results together with a task completion indication to the reasoning module 214.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Aghajanyan into the teachings of Bhalla in view of Levitt. This combination of teachings would have resulted in a method to determine a project requirement task list that is contextually relevant, as in Bhalla, with a development environment for collaboration and language model interaction, as in Levitt, and a persistence database to structure groupings of agents that are executed according to their task/topic, as in Aghajanyan. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of an ontology with labeling systems that allow user requests that are mapped to an action in order to execute a corresponding task (Aghajanyan [0104]).
Claim 12 is directed to a system corresponding to the method limitations as disclosed in claim 5. Thus, claim 12 is rejected for the same reasons set forth in claim 5.
Claim 19 is directed to a computer processing system corresponding to the method limitations as disclosed in claim 5. Thus, claim 19 is rejected for the same reasons set forth in claim 5.
Claims 6, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bhalla in view of Levitt as applied to claims 1, 8, and 15 above, and further in view of US 8365138 B2 hereinafter “Iborra”.
With regards to claim 6, the rejection of claim 1 is incorporated.
The combination of Bhalla and Levitt does not teach: wherein a persistence agent is generated to create a persistence tier for the project.
However, in an analogous art Iborra teaches wherein a persistence agent is generated (Iborra Column 12 Lines 20-33, “The automatic software production system 202 is configured to accept requirements 200 as input, and produce a complete, robust application 204 (including both system logic and user-interface code), a database schema 206, and documentation 208. In one implementation, the automatic software production system 202 includes a Computer Aided Software Engineering (CASE) tool 210 front end to allow a user to input the requirements, a validator 220 for validating the input requirements 200, and several translators to convert the validated input requirements 200 into a complete, robust application 204. These translators may include a system logic translator 232, a user-interface translator 234, a database generator 236, and a documentation generator 238.”) to create a persistence tier for the project. (Iborra Columns 53-54 Lines 60-67 and 1-4) , “In the preferred species, the database generator 236 automatically defines a data model in a Relational Database Management System (RDBMS) according to the validated specification in the high level repository 215. In other species, any data structure that at least stores the values of all object attributes in a manner that allows at least the system logic code and, preferably, the user interface code to retrieve them at will may be coded. The output of the database generator 236 corresponds with the persistence tier (database or shared data structure) in a multi-tiered architecture [to create a persistence tier for the project]. In one embodiment this may be true, but it is not mandatory that the persistence tier in a multi-tiered architecture corresponds with a Relational Database Management System.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Iborra into the teachings of Bhalla in view of Levitt. This combination of teachings would have resulted in a method to determine a project requirement task list that is contextually relevant, as in Bhalla, with a development environment for collaboration and language model interaction, as in Levitt, with a defined persistence/database or data structure for automated software generation, as in Iborra. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of defining a database structure that defines objects (programming constructs) for retrieval at any point in time (Iborra Column 8 Lines 30-41).
Claim 13 is directed to a system corresponding to the method limitations as disclosed in claim 6. Thus, claim 13 is rejected for the same reasons set forth in claim 6.
Claim 20 is directed to a computer processing system corresponding to the method limitations as disclosed in claim 6. Thus, claim 20 is rejected for the same reasons set forth in claim 6.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Bhalla in view of Levitt as applied to claims 1 and 8 above, and further in view of US 20190187982 A1 hereinafter “Mathew”
With regards to claim 7, the rejection of claim 1 is incorporated.
The combination of Bhalla and Levitt does not teach: the corresponding agent is generated with a context of a domain environment in which the corresponding agent operates and a requirement of the domain environment.
However, in an analogous art Mathew teaches the corresponding agent is generated with a context of a domain environment in which the corresponding agent operates (Mathew [0024], “The software build task description 102 is, in an embodiment, a file specifying a set of software build specifications (i.e., a set of build parameters for software) for building software in multiple versions (i.e., one version for each environment). In an embodiment, a software build task description 102 can also describe a single version of software to build. The software build task description 102 may specify minimum resources required for instances where the software will be built such as, for example, memory, CPUs, network resource, or the like. The software build task description 102 may then be utilized to launch software containers (also referred to herein simply as “containers”) associated with the software build task. A software build task description 102 may contain and schedule many software build tasks and may target many different build environments. In some examples, a “task” or a “software build task” may refer to an instantiation of the resources specified by software build task description 102. Software build tasks may be modified by applying a new software build task description to the software build task.”) and a requirement of the domain environment. (Mathew [0066-67], “A software build management service such as the software build management service 104, described at least in connection with FIG. 1, may perform the example process 800 illustrated in FIG. 8. The software build management service may first receive 802 a software build task description and, based at least in part on that software build task description, may determine 804 one or more build environments that may be used to build a version of a software object. The software build management service may then assign 806 a build instance to a customer associated with the software build task description (i.e., the customer that requested the software build) and may instantiate 808 one or more containers for each build environment and one or more corresponding build agents. In an embodiment, the software build management service instantiates one container for each build environment. In another embodiment, the software build management service instantiates a plurality of containers for each build environment. In another embodiment, the software build management service instantiates one or more containers for a subset of the build environments. Next, the software build management service may start 810 a software build on each container as described above by sending build commands to the containers.”) [Examiner’s Note: a software build description describes requirements for environments that can instantiate the environment via a container. The container will have the required resources/requirements for generating an agent and their operations thereof.]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Mathew into the teachings of Bhalla in view of Levitt. This combination of teachings would have resulted in a method to determine a project requirement task list that is contextually relevant, as in Bhalla, with a development environment for collaboration and language model interaction, as in Levitt, and instantiating environments for software tasks in cohesion with their defined requirements, as in Mathew. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of launching containers with specified resources in order for the container instances to execute software build tasks (Mathew [0034]).
Claim 14 is directed to a system corresponding to the method limitations as disclosed in claim 7. Thus, claim 14 is rejected for the same reasons set forth in claim 7.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRAVIS VIET TRAN whose telephone number is (571)272-3720. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
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 Mui 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.
/T.V.T./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights