DETAILED ACTION
The Office Action is in response to claims filed 07/09/2026.
Claims 1, 3, 10, and 12 are currently amended.
Claims 2, 7, 11, 16, and 19 are currently cancelled.
The objection to claims 3, 7, 12, and 16 are withdrawn in view of the applicant’s amendments/cancellation of claims 3, 7, 12, and 16.
The rejection of claims 1-19 under 35 U.S.C. 101 and 112(b) is withdrawn in view of the applicant’s amendments/cancellation/arguments of claims 1, 2, 7, 10, 11, 16, and 19.
Claims 1, 3-6, 8-10, 12-15, and 17-18 are currently 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 § 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-6, 9, 10, 12-15, and 18 are rejected under 35 U.S.C. 103 as being
unpatentable over US 20240070435 A1 hereinafter "Shinde" in view of US 20220327124 A1
hereinafter "Sweeney" in view of US 20210360083 A1 hereinafter "Duggal" in view of US 20240152343 A1 hereinafter "Prasad" and further in view of US 20240345832 A1 hereinafter "Iruvanti".
With regards to claim 1, Shinde teaches
A neural network for use with implementing a cloud migration in response to a
receiving a request to provide the cloud migration for a predetermined application, the
neural network comprising: (Shinde [0020-22], "Cloud migration can move databases,
applications, services, workloads, or other digital content of an on-premises system from a local
data center to a cloud computing environment [for use with implementing a cloud migration].
The on-premises system can include a set of databases, applications, services, workloads, or
other digital content that executes on hardware located at a location that is physically accessible
to a corresponding entity, such as an organization or enterprise. However, due to the large
number of parameters of the on-premises system and different cloud providers, it can be
challenging and burdensome to identify a target cloud architecture/system that is optimally suited
for a given on-premises system. The systems and methods described in this specification can
assess interdependencies of various technical components, underlying infrastructure fabric,
application specific non-functional requirements (NFRs) of the on-premises system; map them
against each cloud providers' service releases, specifications, features currently being offered,
and features being updated over future; and provide guidance on selection cloud vendors and
cloud infrastructure options. Furthermore, the systems and methods described in this
specification can train a neural network model for the recommendation of target cloud
architectures [A neural network]. The systems and the methods described in this specification
can train the neural network model in an efficient way. Specifically, the neural network model
can be trained by applying various tools such as convolutional filters, ReLu activation functions,
and max pooling The on-premises system can include a set of databases, applications,
services, workloads, or other digital content that executes on hardware located at a location that
is physically accessible to the corresponding entity. The entity can request to migrate at least part
of the on-premises system to a cloud architecture for various reasons, such as increased
flexibility, increasing resource demands, reduction in costs, etc. [receiving a request to provide
the cloud migration for a predetermined application].")
a plurality of cloud configuration nodes, each of the plurality of cloud configuration
nodes couples [to each of the CICD nodes;] (Shinde [0042], "An initial weight can be assigned
to each node of the neural network. The values of the set of input parameters corresponding to
the metadata or the features of the on-premises system are provided into the input layer. The one
or more hidden layers can process the outputs from the previous layer [each of the plurality of
nodes couples]. The output layer can provide one or more classification or prediction results. In
other words, the input layer collects input patterns. The output layer has classification or out
signals to which input patterns may map. The hidden layers can extrapolate salient features in the
input data that have predictive power regarding the outputs.") and (Shinde [0061-63]" Extracting
the set of input parameters can include executing extraction script at the on-premises system to
extract metadata of the on-premises system, and generating the set of input parameters based on
analyzing the metadata of the on-premises system. By executing the script, the server can extract
the metadata of the on-premises system and better understand the features and execution
environment of the on-premises system. Based on analyzing the metadata, the server can
generate a set of input parameters that can be used to determine the features of the cloud
architecture At step 306, the server can execute the trained neural network model using the set
of input parameters to obtain a set of output parameters associated with a target cloud
architecture [cloud configuration].") [Examiner's Note: input parameters define the target cloud
migration which in turn defines the metadata into the neural network. The metadata will map to
individual classified layers comprising cloud nodes which can then couple to other layers.]
[a plurality of single sign on nodes (SSO), each of the SSO nodes] coupled to the
cloud configuration nodes; (Shinde [0041-42], "Afterwards, the output is passed through an
activation function, which determines the output. If that output exceeds a given threshold, it
activates the node, passing data to the next layer in the network. This result in the output of the
node becomes the input of the next node in the next layer [coupled to the nodes]. This process
of passing data from one layer to the next layer defines the neural network as a feedforward
network. An initial weight can be assigned to each node of the neural network. The values of the
set of input parameters corresponding to the metadata or the features of the on-premises system
are provided into the input layer. The one or more hidden layers can process the outputs from the
previous layer. The output layer can provide one or more classification or prediction results. In
other words, the input layer collects input patterns. The output layer has classification or out
signals to which input patterns may map. The hidden layers can extrapolate salient features in the
input data that have predictive power regarding the outputs.") and (Shinde [0061-63]" Extracting
the set of input parameters can include executing extraction script at the on-premises system to
extract metadata of the on-premises system, and generating the set of input parameters based on
analyzing the metadata of the on-premises system. By executing the script, the server can extract
the metadata of the on-premises system and better understand the features and execution
environment of the on-premises system. Based on analyzing the metadata, the server can
generate a set of input parameters that can be used to determine the features of the cloud
architecture At step 306, the server can execute the trained neural network model using the set
of input parameters to obtain a set of output parameters associated with a target cloud
architecture. [cloud configuration]") [Examiner's Note: By activating the node and traversing
the layers of the network, the neural network is capable of making associations or coupling
between layers of classified nodes (one layer being classifying said cloud configurations)]
wherein a single cloud configuration is formed (Shinde [0071], "In the solution design
phase 420, the server can determine cloud strategy. In step 4 422, the server can process source
system details and target system details, along with external parameters impacting the cloud
migration journey. The server can produce solution blueprint for the cloud migration, such as the
recommended features of the target cloud architecture. The recommendation features of the
target cloud architecture can include identifier of the target cloud architecture, versions of the
components of the target cloud architecture, methods for cloud migration, cloud target
shapes/sizes, licensing impact, estimated time, etc. For example, the server can execute a trained
neural network using the set of input parameters corresponding to the source system details. The
server can obtain a set of output parameters from the neural network model.") [from a single
CICD node selected from the plurality of CICD nodes] a single cloud configuration node selected from the plurality of cloud configuration nodes, [a single SSO node selected from the plurality of SSO nodes, and a single application node selected from the plurality of application nodes.] (Shinde [0039-40], "At step 208, the server can extract a set of output parameters of the target cloud architecture. The set of output parameters can include the metadata or the features of the target cloud architecture. For example, the set of output parameters can include target cloud versions, migration methods, target cloud shapes and sizes, licensing impact, etc. [cloud configuration]. The neural network can include layers of interconnected nodes [from the plurality of nodes]. The neural network can include an input layer, one or more hidden layers, and an output layer. Each layer can include a set of nodes or neurons. Each node connects to another and has an associated weight and threshold. If the output of any individual node is above the specified threshold value, that node is activated [a single node selected], sending data to the next layer of the neural network. Otherwise, no data is passed along to the next layer of the neural network.") [Examiner's Note: A layer consists of multiple neural network nodes of a particular type. Using weights and biases the neural network will traverse the layer by picking the node using its activation.]
Shinde teaches a single cloud configuration is formed from a single cloud configuration node selected from the plurality of cloud configuration nodes but does not teach: a plurality of continuous integration continuation deployment (CICD) nodes;
[wherein a single cloud configuration is formed from] a single CICD node selected from the plurality of CICD nodes [a cloud configuration single node selected from the plurality of cloud configuration nodes,] a single SSO node selected from the plurality of SSO nodes, and a single application node selected from the plurality of application nodes.
However, in an analogous art Sweeney teaches a plurality of continuous integration
continuation deployment (CICD) nodes; (Sweeney [0028], "However, the new project may be
inferred based on interactions between people (e.g., determined from schedule/calendar
information in the knowledge graph), reporting structures (e.g., nodes/edges that represent who
has applied to work at what positions at the organization, who receives what benefits (e.g.,
insurance, salary, etc.) at the organization, or any other relationship indicated by human resource
information), software development patterns (e.g., nodes/edges that indicate changes to version
control systems or other software management information), and/or information technology (IT)
relationships (e.g., indicated by nodes/edges that represent incidents/errors with computer
systems) indicated by the knowledge graph. For example, the new project may be inferred via a
machine learning model as discussed in more detail below.") [Examiner's Note: A knowledge
graph will contain a plurality of nodes associated with different entities. Sweeney describes
nodes that are associated with software development patterns thereby teaching a CICD node.]
[...] a single CICD node selected from the plurality of CICD nodes [...] (Sweeney [0028-29], "software development patterns (e.g., nodes/edges that indicate changes to version control systems or other software management information), The graph subsystem 114 may
determine a set of the nodes stored in the database 106 (e.g., a subset of the nodes shown in FIG.
2, or the set may include all the nodes shown in FIG. 2) that should be used in a machine
learning model to determine an answer to a query. The graph subsystem 114 may identify a first
node in the knowledge graph corresponding to the query. The graph subsystem 114 may
determine nodes connected to the first node that may be helpful in answering the query. For
example, if the query indicates a request for information on how to use a product associated with
node 220, the graph subsystem 114 may identify node 220 as a starting point in the knowledge
graph (e.g., the product itself). The graph subsystem 114 may determine a plurality of edges
connecting the first node (in this example, the first node may be node 220) with other nodes in
the knowledge graph.")
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 Sweeney into
the teachings of Shinde This combination of teachings would have resulted in a method
configured to determine the target cloud migration infrastructure through neural networks, as in
Shinde, using continuous integration and deployment node traversal, as in Sweeney. One of
ordinary skill in the art would have been motivated to combine these teachings for the purpose of
connecting edge nodes to indicate a project and/or project in a knowledge graph for software
development data (Sweeney [0026-27]).
The combination of Shinde and Sweeney teaches coupled to the cloud configuration
nodes wherein a single cloud configuration is formed from a single CICD node selected from the plurality of CICD nodes, a single cloud configuration node selected from the plurality of cloud configuration nodes, but does not teach: a plurality of single sign on nodes (SSO), each of the SSO nodes [coupled to the cloud configuration nodes;]
and a plurality of application nodes coupled to each of the plurality of SSO nodes;
[wherein a single cloud configuration is formed from a single CICD node selected from the plurality of CICD nodes, a single cloud configuration node selected from the plurality of cloud configuration nodes,] a single SSO node selected from the plurality of SSO nodes, and a single application node selected from the plurality of application nodes.
However, in an analogous art Duggal teaches a plurality of single sign on nodes (SSO),
each of the SSO nodes [...] (Duggal [0124-125], "The object 302 includes types 304, concepts
306, and policies 308. The types 304, concepts 306, and/or policies 308 may comprise references
to corresponding types, concepts, and/or policies of an ontology and/or domain model (e.g., of
one or more domain models such as a domain model 212) The design environment may
enable technical staff to map properties, behaviors, constraints and dependencies to domain
concepts and types. The graph topology represents mappings as a set of conditional, policy-based
relationships, which allow one-or-more implementations of an object based on prototypal, nonhierarchical, inheritance.") (Duggal [0148], "The platform services 416 may include middleware capabilities inherited through the type system and automatically linked to the object graph. The middleware capabilities may include portal services (e.g., browser-based JSON portal (cross platform)), dynamic applications, work-lists, forms, enterprise search, UI-Integration (e.g.,
templates, content, mashups), security services (e.g., identity, role-based access control, single
sign-on authentication/authorization protocols (such as Kerberos, OAuth, SAML, XACML, or
the like), certification and credential management, encryption in-flight/at-rest)") [Examiner's
Note: The neural network is a graph of nodes/objects. The object types are linked to middleware
capabilities including security services such as Single Sign On.]
and a plurality of application nodes (Duggal [0148], "The platform services 416 may
include middleware capabilities inherited through the type system and automatically linked to the
object graph.. Modeling/onboarding endpoints (service, API, system, database, device)),
protocol translation, data type transformations, entity mapping, proxy services, fault
management, controller services (e.g., automate configuration and control), network services
(e.g., network integration (virtual functions, orchestrators, target hosts, network resources)),
M2M/IoT services (e.g., Machine/Device Integration (sensors, actuators, gateways)), entity
management services (e.g., Lifecycle management of all system objects (models and instances,
apps and data, nodes and machines/devices)), application services (e.g., application integration,
data services (e.g., data integration (structured, semi-structured and un-structured)), process
services (e.g., service choreography and orchestration, system and human workflows,
collaboration), policy services (e.g., enforcement and execution of declarative policies), decision
services (e.g., decision tables, decision trees)).") coupled to each of the plurality of SSO
nodes; (Duggal [0126-127], "With GOAL, objects 302 may have a logical model that references
a conceptual model of a domain (e.g., an ontology), which also describes its physical model (e.g.,
implementations); eliminating or reducing system overhead and supporting greater expressivity
and adaptability of the system. Objects are loosely-coupled to their underlying elements, to each
other and to the domain model for a complete separation of concerns and a completely metadata
configurable environment. By mapping all connected elements to a common domain model, the
platform may accommodate heterogeneous interfaces with diverse formats, data protocols and
support interoperability with third party components (middleware, tools, runtimes, etc.),
databases, network resources and devices/machines where specified which may relax constraints
to promote interoperability and allow the system boundaries to be extended in a natural
manner.") [Examiner's Note: Duggal teaches objects that are linked or classified with
application/middleware capabilities. These objects can be linked/coupled to each other and
reconfigurable through metadata meaning an application object can be linked to an SSO object
according to user intentions.]
[...] a single SSO node selected from the plurality of SSO nodes, and a single application node selected from the plurality of application nodes. (Duggal [0171], "As distinct from Map-Reduce algorithms, which divide a workload across multiple workers and then aggregate results, in this example, diverse workloads may be distributed to agents and coordinated such that overall processing of a complex event may be modeled in a single language with a unified execution engine with all agents leveraging shared domain semantics and object data store so metadata and state is exchanged efficiently. Agents may run in the same compute node or distributed nodes, which may represent different deployment technologies (e.g., servers, virtual machines, containers) and the placement of agent workloads may itself be an automated, domain-driven, policy-controlled decision based on real-time metadata and state.") [Examiner's Note: Policies can define the selection of nodes or objects of the knowledge graph. These nodes are linked to applications and SSO as described in paragraph [0148]]
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 Duggal into
the teachings of Shinde in view of Sweeney. This combination of teachings would have resulted
in a method configured to determine the target cloud migration infrastructure through neural
networks, as in Shinde, using continuous integration and deployment node traversal, as in
Sweeney, while determining the associated single sign on as well as application nodes associated
with neural network requirements, as in Duggal. One of ordinary skill in the art would have been
motivated to combine these teachings for the purpose of composing an application that can
coordinate from many sources with associations with many events and policies that are secure
and scalable (Duggal [0067]).
The combination of Shinde, Sweeney, and Duggal does not teach: further comprising a
CICD pipeline integrator, said CICD pipeline integrator that tests the migration in the
pipeline and returns a cloud migration compliance score based on the testing.
However, in an analogous art Prasad teaches further comprising a CICD pipeline
integrator, said CICD pipeline integrator that tests the migration in the pipeline (Prasad
[0059-60], "In some embodiments, the one or more enterprise change management systems,
integrated change control gateway systems, change control modules, cognitive change evaluation
and assistance systems, secure tokenization modules, deployment authentication modules,
implementation modules, and/or production modules and/or systems may perform one or more
of the steps described herein with respect to the process flows described herein with respect to
FIGS. 2-4 [further comprising a CICD pipeline integrator]. FIG. 2 illustrates a process
flow 200 for evaluating, validating, and implementing system environment production
deployment tools using cognitive learning input, in accordance with an embodiment of the
invention. In some embodiments, a release management module is configured to interface with
one or more enterprise change management systems, integrated change control gateway systems,
change control modules, cognitive change evaluation and assistance systems, secure tokenization
modules, deployment authentication modules, implementation modules, production modules
and/or systems, and/or the like (e.g., similar to one or more of the systems described herein with
respect to FIG. 1) may perform one or more of the steps of process flow 200. It is understood
that the present invention is primarily focused on effective assessment of software releases [said
CICD pipeline integrator that tests the migration in the pipeline].") and returns a cloud
migration compliance score based on the testing. (Prasad [0083-84], "In some embodiments,
this may include extracting and assigned a CI level confidence score. As shown in FIG. 3, the
process flow 300 may include assigning the quantitative failure chance score to the each
operation or configuration item based on the cognitive intelligence built from previous modules
to produce a package level assessment, which is then compared to a project threshold to
determine if the production package passes or not. In further embodiments, the smart decision
system module calculates the confidence score of the proposed change based in the failure
chance and criticality of a particular configuration item.")
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 Prasad into the teachings of Shinde in view of Sweeney in view of Duggal. This combination of teachings would have resulted in a method configured to determine the target cloud migration infrastructure through neural networks, as in Shinde, using continuous integration and deployment node traversal, as in Sweeney, while determining the associated single sign on as well as application nodes associated with neural network requirements, as in Duggal, with a pipeline integrator to test the migration, as in Prasad. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a system for evaluating, validating, and implementing software release change requests into a system environment while obtaining meaningful conclusions regarding potential negative impacts (Prasad [0023]).
The combination of Shinde, Sweeney, Duggal, and Prasad does not teach: comprising a code repository, said code repository coupled to the neural network, said code repository for rewriting the code in which the application is written and integrating the code for use with the cloud migration.
However, in an analogous art Iruvanti teaches comprising a code repository, said code
repository coupled to the neural network, (Iruvanti [0017], "The build agent server may collect possible information on every build from a Mainframe Environment for every object, and may prepare a knowledge graph using support vector machine classification and bi-directional long short term memory (BI-LSTM) deep learning algorithms to identify errors, object dependencies, and source code patterns, and simulate the build on non-mainframe servers. The build agent may be introduced in a continuous integration chain. Whenever any module or object is changed in source repository, it may trigger a build on a non-mainframe environment to identify risks or errors prior to executing the build for mainframe source code components.") said code repository for rewriting the code in which the application is written and integrating the code for use with the cloud migration. (Iruvanti [0024-27], "Source repository device 104 may be or include one or more devices (e.g., servers, server blades, or the like), which may, e.g., be configured to store source code (e.g., which has not yet been built, compiled, run, or the like). For example, the source repository device 104 may communicate with the enterprise user device 103 and/or other devices to initially obtain the mainframe source code [said code repository for rewriting the code in which the application is written] The mainframe build and deployment engine 106 may be or include one or more devices (e.g., servers, server blades, or the like) configured to execute builds of mainframe source code [integrating the code for use with the cloud migration]. For example, once the mainframe source code has been analyzed by the build agent server 102, it may be passed to the mainframe build and deployment engine 106 for execution of the build process. The mainframe build and deployment engine 106 may be configured to send information of the build (e.g., build confirmation, error notifications, or the like) to the build agent server 102 and/or the enterprise user device 103. Computing environment 100 also may include one or more networks, which may interconnect build agent server 102, enterprise user device 103, source repository device 104, dependency data storage system 105, and mainframe build and deployment engine 106.") [Examiner’s Note: the analyzed code is executed and built and thereby integrated to implement a deployment engine for operations including cloud migration.]
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 Iruvanti into
the teachings of Shinde in view of Sweeney in view of Duggal and further in view of Prasad. This combination of teachings would have resulted in a method configured to determine the target cloud migration infrastructure through neural networks, as in Shinde, using continuous integration and deployment node traversal, as in Sweeney, while determining the associated single sign on as well as application nodes associated with neural network requirements, as in Duggal, with a pipeline integrator to test the migration, as in Prasad, and integrating a code repository coupled to the neural network in order to manage migration accordingly, as in Iruvanti. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of enabling user commits to a source repository with automated processes to check for errors and suggest remediation accordingly with knowledge graphs (Iruvanti [0020]).
With regards to claim 3, the rejection of claim 1 is incorporated.
The combination of Shinde, Sweeney, Duggal, and Iruvanti does not teach: wherein, the cloud migration is determined to have more than a threshold cloud migration compliance score, rerun the implementation of the cloud migration.
However, in an analogous art Prasad teaches wherein, the cloud migration is
determined to have more than a threshold cloud migration compliance score, (Prasad
[0071], "The process flow 200 may include determining whether the confidence score is greater
than the threshold limit, where higher confidence scores are associated with higher likelihoods of
software release change request not negatively impacting the system environment. Some
embodiments are described herein in connection with thresholds. As used herein, satisfying a
threshold may, depending on the context, refer to a value being greater than the threshold, more
than the threshold, higher than the threshold") rerun the implementation of the cloud
migration. (Prasad [0087-88], "In this way, the post implementation data is analyzed to identify
any post-implementation issues. As shown in FIG. 3, the process flow 300 may include applying
a cognitive learning AI/ML model, as indicated in module 4 of FIG. 2. In this way the postimplementation analysis module may access threshold limits either predefined or defined by
other modules such as the production certificate module or smart decision system module. The
post implementation analysis module may update inferences and adjust thresholds as
necessitated by insights from post implementation data. The post implementation analysis
module analyzes the implementation defects, incident, problem, and change data, and applies
cognitive learning to refine the inferences and thresholds. These inferences drawn on this module
can be used as a "lessons learned document" for future releases. As indicated in FIG. 3, all of the
modules shown collectively are used to build the cognitive input using AI/ML, artificial network,
and cognitive learning models, in order to proceed to the steps shown in FIG. 4, as indicated in
the process flow continuation marker "A". FIG. 4 illustrates a process flow 400 for evaluating,
validating, and implementing system environment production deployment tools using cognitive
learning input, in accordance with an embodiment of the invention. In some embodiments, a
release management module is configured to interface with one or more enterprise change
management systems, integrated change control gateway systems, change control modules,
cognitive change evaluation and assistance systems, secure tokenization modules, deployment
authentication modules, implementation modules, production modules and/or systems, and/or the
like") [Examiner's Note: FIG 3. Describes a post assessment flow that triggers the steps of FIG.
4 which is to run the cloud migration once more]
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 Prasad into
the teachings of Shinde in view of Sweeney in view of Duggal and further in view of Iruvanti. This combination of teachings would have resulted in a method configured to determine the target cloud migration infrastructure through neural networks, as in Shinde, using continuous integration and deployment node traversal, as in Sweeney, while determining the associated single sign on as well as application nodes associated with neural network requirements, as in Duggal, with a pipeline integrator to test the migration, as in Prasad, and integrating a code repository coupled to the neural network in order to manage migration accordingly, as in Iruvanti. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a system for evaluating, validating, and implementing software release change requests into a system environment while obtaining meaningful conclusions regarding potential negative impacts (Prasad [0023]).
With regards to claim 4, the rejection of claim 1 is incorporated.
Shinde further teaches comprising a neural network interface for interfacing between
the request and the neural network. (Shinde [0023-24], "The server 102 can receive the
request from a user device (not shown) associated with the entity over the network 104, such as
Internet. The request can include a plurality of parameters associated with the on-premises
system. For example, the plurality of parameters can include an identifier of the on-premises
system, identifiers of components of the on-premises system, migration requirements, and the
like. The server 102 can use a neural network model to predict the features of a target cloud
architecture. Specifically, the server 102 can extract, from the plurality of parameters, a set of
input parameters substantially affecting the migration of the on-premises system. The server 102
can use the set of input parameters to execute a trained neural network model to obtain a set of
output parameters.") [Examiner's Note: A user device is an interface that allows for a user to
send requests and interact/interface with the neural network.]
With regards to claim 5, the rejection of claim 4 is incorporated.
Shinde further teaches comprising a cloud plugin integrator for providing an
integration point (Shinde [0036-37], "For example, the server can identify one or more target
cloud architectures that satisfy the requirements of the on-premises system, the server can further
determine the migration methods or the migration paths to migrate the on-premises system to the
target cloud architectures. For instance, the migration paths can include infrastructure as a
service (IaaS), platform as a service (PaaS), and software as a service (SaaS). The server can
choose one of the migration paths based on the database version, data editions, workload type,
dedicated/shared infrastructure, features, RAC option, and other features available in the on premises system and the respective mapped features in the cloud architecture. In some
implementations, the server can consider the cost and performance requirements for migrating
the on-premises system to the cloud architecture. The target cloud architecture can be selected
such that the selected cloud architecture satisfies one or more threshold conditions associated
with the on-premises system. For example, the target cloud architecture can provide services that
satisfy the performance thresholds required by the entity.") between a plurality of application
requirements of the application and the cloud migration as defined in the neural network
interface. (Shinde [0064], "The trained neural network model can use a set of input parameters
associated with the on-premises system to generate a set of output parameters associated with the
target cloud architecture that is compliant with the set of input parameters and satisfies the
threshold conditions associated with the migration, such as the performance thresholds and/or
cost thresholds. The server can execute the trained neural network model to obtain the set of
output parameters. The set of output parameters can indicate the metadata or features required
for the target cloud architecture and can be used to identify the target cloud architecture.")
With regards to claim 6, the rejection of claim 1 is incorporated.
Shinde further teaches comprising a platform interpreter for determining an identity
of the application being migrated. (Shinde [0033], "Extracting the set of input parameters can
include executing an extraction script at the on-premises system to extract metadata of the on Application/premises system, and generating the set of input parameters based on analyzing the metadata of the on-premises system. In some implementations, by executing the script, the server can extract the metadata of the on-premises system and identify the features and execution environment of the on-premises system. Based on analyzing the metadata, the server can generate a set of input parameters that can be used to determine the features of the cloud architecture.")
With regards to claim 9, the rejection of claim 1 is incorporated.
The combination of Shinde, Sweeney, Prasad, and Iruvanti does not teach: further comprising an SSI single sign on (SSO) platform interface, said SSO platform interface for providing an SSO library for use with the cloud migration.
However, in an analogous art Duggal teaches further comprising an SSI single sign on
(SSO) platform interface, said SSO platform interface (Duggal [0148], "The platform
services 416 may include middleware capabilities inherited through the type system and
automatically linked to the object graph. The middleware capabilities may include portal services
(e.g., browser-based JSON portal (cross-platform)), dynamic applications, work-lists, forms,
enterprise search, UI-Integration (e.g., templates, content, mashups), security services (e.g.,
identity, role-based access control, single sign-on authentication/authorization protocols (such as
Kerberos, OAuth, SAML, XACML, or the like), certification and credential management,
encryption in-flight/at-rest), gateway services (e.g., Modeling/onboarding endpoints (service,
API, system, database, device))") for providing an SSO library for use with the cloud
migration. (Duggal [0571], "In some embodiments, at run-time, the platform's execution
environment references the library to dynamically construct the tool-chain it may need in order
to realize the network service. It may assemble just the right tools for the job just-in-time, in a
single middleware backplane allowing extremely efficient, compute and Input/Output intensive,
graph transaction processing.")
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 Duggal into
the teachings of Shinde in view of Sweeney in view of Prasad and further in view of Iruvanti. This combination of teachings would have resulted in a method configured to determine the target cloud migration infrastructure through neural networks, as in Shinde, using continuous integration and deployment node traversal, as in Sweeney, while determining the associated single sign on as well as application nodes associated with neural network requirements, as in Duggal, with a pipeline integrator to test the migration, as in Prasad, and integrating a code repository coupled to the neural network in order to manage migration accordingly, as in Iruvanti. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of composing an application that can coordinate from many sources with associations with many events and policies that are secure and scalable (Duggal [0067]).
With regards to claim 10, Shinde teaches
A method for using a neural network to implement a cloud migration in response
to receiving a request to provide the cloud migration for a predetermined application, the
method comprising: (Shinde [0020-22], "Cloud migration can move databases, applications,
services, workloads, or other digital content of an on-premises system from a local data center to
a cloud computing environment [for use with implementing a cloud migration]. The on-premises
system can include a set of databases, applications, services, workloads, or other digital content
that executes on hardware located at a location that is physically accessible to a corresponding
entity, such as an organization or enterprise. However, due to the large number of parameters of
the on-premises system and different cloud providers, it can be challenging and burdensome to
identify a target cloud architecture/system that is optimally suited for a given on-premises
system. The systems and methods described in this specification can assess interdependencies of
various technical components, underlying infrastructure fabric, application specific nonfunctional requirements (NFRs) of the on-premises system; map them against each cloud
providers' service releases, specifications, features currently being offered, and features being
updated over future; and provide guidance on selection cloud vendors and cloud infrastructure
options. Furthermore, the systems and methods described in this specification can train a neural
network model for the recommendation of target cloud architectures [A neural network]. The
systems and the methods described in this specification can train the neural network model in an
efficient way. Specifically, the neural network model can be trained by applying various tools
such as convolutional filters, ReLu activation functions, and max pooling The on-premises
system can include a set of databases, applications, services, workloads, or other digital content
that executes on hardware located at a location that is physically accessible to the corresponding
entity. The entity can request to migrate at least part of the on-premises system to a cloud
architecture for various reasons, such as increased flexibility, increasing resource demands,
reduction in costs, etc. [receiving a request to provide the cloud migration for a predetermined
application].")
selecting a single cloud configuration node from a plurality of cloud configuration
nodes; (Shinde [0039-40], "At step 208, the server can extract a set of output parameters of the
target cloud architecture. The set of output parameters can include the metadata or the features of
the target cloud architecture. For example, the set of output parameters can include target cloud
versions, migration methods, target cloud shapes and sizes, licensing impact, etc. [cloud
configuration]. The neural network can include layers of interconnected nodes [from the
plurality of nodes]. The neural network can include an input layer, one or more hidden layers,
and an output layer. Each layer can include a set of nodes or neurons. Each node connects to
another and has an associated weight and threshold. If the output of any individual node is above
the specified threshold value, that node is activated [a single cloud configuration node selected], sending data to the next layer of the neural network. Otherwise, no data is passed along to the next layer of the neural network.")
Shinde does not teach: selecting a single cloud continuous integration continuation
deployment (CICD) node from a plurality of continuous integration continuation
deployment (CICD) nodes;
However in an analogous art Sweeney teaches selecting a single cloud continuous
integration continuation deployment (CICD) node from a plurality of continuous
integration continuation deployment (CICD) nodes; (Sweeney [0028-29], "software
development patterns (e.g., nodes/edges that indicate changes to version control systems or other
software management information), [cloud continuous integration continuation deployment
(CICD)] The graph subsystem 114 may determine a set of the nodes stored in the database
106 (e.g., a subset of the nodes shown in FIG. 2, or the set may include all the nodes shown in
FIG. 2) that should be used in a machine learning model to determine an answer to a query
[selecting a single cloud continuous integration continuation deployment node]. The graph subsystem 114 may identify a first node in the knowledge graph corresponding to the query. The graph subsystem 114 may determine nodes connected to the first node that may be helpful in answering the query. For example, if the query indicates a request for information on how to use a product associated with node 220, the graph subsystem 114 may identify node 220 as a starting point in the knowledge graph (e.g., the product itself). The graph subsystem 114 may determine a plurality of edges connecting the first node (in this example, the first node may be node 220) with other nodes in the knowledge graph [from a plurality of continuous integration continuation deployment (CICD) nodes;].")
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 Sweeney into
the teachings of Shinde This combination of teachings would have resulted in a method
configured to determine the target cloud migration infrastructure through neural networks, as in
Shinde, using continuous integration and deployment node traversal, as in Sweeney. One of
ordinary skill in the art would have been motivated to combine these teachings for the purpose of
connecting edge nodes to indicate a project and/or project in a knowledge graph for software
development data (Sweeney [0026-27]).
The combination of Shinde and Sweeney does not teach: selecting a single sign on SSO node selected from a plurality of SSO nodes; and
selecting a single application node from a plurality of application nodes.
However, in an analogous art Duggal teaches selecting a single sign on SSO node selected from a plurality of SSO nodes; and
selecting a single application node from a plurality of application nodes. (Duggal
[0148], "The platform services 416 may include middleware capabilities inherited through the
type system and automatically linked to the object graph. The middleware capabilities may
include portal services (e.g., browser-based JSON portal (cross-platform)), dynamic applications,
work-lists, forms, enterprise search, UI-Integration (e.g., templates, content, mashups), security
services (e.g., identity, role-based access control, single sign-on authentication/authorization
protocols (such as Kerberos, OAuth, SAML, XACML, or the like) [from a plurality of single
sign on nodes (SSO)], certification and credential management, encryption in-flight/at-rest),
gateway services (e.g., Modeling/onboarding endpoints (service, API, system, database, device)),
protocol translation, data type transformations, entity mapping, proxy services, fault
management, controller services (e.g., automate configuration and control), network services
(e.g., network integration (virtual functions, orchestrators, target hosts, network resources)),
M2M/IoT services (e.g., Machine/Device Integration (sensors, actuators, gateways)), entity
management services (e.g., Lifecycle management of all system objects (models and instances,
apps and data, nodes and machines/devices)), application services (e.g., application integration
[from a plurality of application nodes], data services (e.g., data integration (structured, semi structured and un-structured)), process services (e.g., service choreography and orchestration,
system and human workflows, collaboration), policy services (e.g., enforcement and execution of
declarative policies), decision services (e.g., decision tables, decision trees)).") and (Duggal
[0171], "As distinct from Map-Reduce algorithms, which divide a workload across multiple
workers and then aggregate results, in this example, diverse workloads may be distributed to
agents and coordinated such that overall processing of a complex event may be modeled in a
single language with a unified execution engine with all agents leveraging shared domain
semantics and object data store so metadata and state is exchanged efficiently. Agents may run in
the same compute node or distributed nodes, which may represent different deployment
technologies (e.g., servers, virtual machines, containers) and the placement of agent workloads
may itself be an automated, domain-driven, policy-controlled decision based on real-time
metadata and state [selecting a single node].") [Examiner's Note: Policies/decision
tables/decision trees can define the selection of nodes or objects of the knowledge graph. These
nodes are linked to applications and SSO as described in paragraph [0148]]
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 Duggal into
the teachings of Shinde in view of Sweeney. This combination of teachings would have resulted
in a method configured to determine the target cloud migration infrastructure through neural
networks, as in Shinde, using continuous integration and deployment node traversal, as in
Sweeney, while determining the associated single sign on as well as application nodes associated
with neural network requirements, as in Duggal. One of ordinary skill in the art would have been
motivated to combine these teachings for the purpose of composing an application that can
coordinate from many sources with associations with many events and policies that are secure
and scalable (Duggal [0067]).
The combination of Shinde, Sweeney, and Duggal does not teach: using a CICD pipeline integrator to test the cloud migration in a CICD pipeline and return a cloud migration compliance score based on the testing;
However, in an analogous art Prasad teaches using a CICD pipeline integrator to test the cloud migration in a CICD pipeline and return a cloud migration compliance score based on the testing; (Prasad [0059-60], "In some embodiments, the one or more enterprise change management systems, integrated change control gateway systems, change control modules, cognitive change evaluation and assistance systems, secure tokenization modules, deployment authentication modules, implementation modules, and/or production modules and/or systems may perform one or more of the steps described herein with respect to the process flows described herein with respect to FIGS. 2-4 [using a CICD pipeline integrator]. FIG. 2 illustrates a process flow 200 for evaluating, validating, and implementing system environment production deployment tools using cognitive learning input, in accordance with an embodiment of the invention. In some embodiments, a release management module is configured to interface with one or more enterprise change management systems, integrated change control gateway systems, change control modules, cognitive change evaluation and assistance systems, secure tokenization modules, deployment authentication modules, implementation modules, production modules and/or systems, and/or the like (e.g., similar to one or more of the systems described herein with respect to FIG. 1) may perform one or more of the steps of process flow 200. It is understood that the present invention is primarily focused on effective assessment of software releases [to the cloud migration in a CICD pipeline].") and returns a cloud migration compliance score based on the testing. (Prasad [0083-84], "In some embodiments, this may include extracting and assigned a CI level confidence score. As shown in FIG. 3, the process flow 300 may include assigning the quantitative failure chance score to the each operation or configuration item based on the cognitive intelligence built from previous modules to produce a package level assessment, which is then compared to a project threshold to determine if the production package passes or not. In further embodiments, the smart decision system module calculates the confidence score of the proposed change based in the failure chance and criticality of a particular configuration item.")
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 Prasad into the teachings of Shinde in view of Sweeney in view of Duggal. This combination of teachings would have resulted in a method configured to determine the target cloud migration infrastructure through neural networks, as in Shinde, using continuous integration and deployment node traversal, as in Sweeney, while determining the associated single sign on as well as application nodes associated with neural network requirements, as in Duggal, with a pipeline integrator to test the migration, as in Prasad. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a system for evaluating, validating, and implementing software release change requests into a system environment while obtaining meaningful conclusions regarding potential negative impacts (Prasad [0023]).
The combination of Shinde, Sweeney, Duggal, and Prasad does not teach: and coupling a code repository to the neural network, and using said code repository to rewrite a computer code in which the predetermined application is written and to integrate the computer code for use with the cloud migration.
However, in an analogous art Iruvanti teaches and coupling a code repository to the neural network, (Iruvanti [0017], "The build agent server may collect possible information on every build from a Mainframe Environment for every object, and may prepare a knowledge graph using support vector machine classification and bi-directional long short term memory (BI-LSTM) deep learning algorithms to identify errors, object dependencies, and source code patterns, and simulate the build on non-mainframe servers. The build agent may be introduced in a continuous integration chain. Whenever any module or object is changed in source repository, it may trigger a build on a non-mainframe environment to identify risks or errors prior to executing the build for mainframe source code components.") and using said code repository to rewrite a computer code in which the predetermined application is written and to integrate the computer code for use with the cloud migration. (Iruvanti [0024-27], "Source repository device 104 may be or include one or more devices (e.g., servers, server blades, or the like), which may, e.g., be configured to store source code (e.g., which has not yet been built, compiled, run, or the like). For example, the source repository device 104 may communicate with the enterprise user device 103 and/or other devices to initially obtain the mainframe source code [said code repository for rewriting the code in which the application is written] The mainframe build and deployment engine 106 may be or include one or more devices (e.g., servers, server blades, or the like) configured to execute builds of mainframe source code [integrating the code for use with the cloud migration]. For example, once the mainframe source code has been analyzed by the build agent server 102, it may be passed to the mainframe build and deployment engine 106 for execution of the build process. The mainframe build and deployment engine 106 may be configured to send information of the build (e.g., build confirmation, error notifications, or the like) to the build agent server 102 and/or the enterprise user device 103. Computing environment 100 also may include one or more networks, which may interconnect build agent server 102, enterprise user device 103, source repository device 104, dependency data storage system 105, and mainframe build and deployment engine 106.") [Examiner’s Note: the analyzed code is executed and built and thereby integrated to implement a deployment engine for operations including cloud migration.]
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 Iruvanti into the teachings of Shinde in view of Sweeney in view of Duggal and further in view of Prasad. This combination of teachings would have resulted in a method configured to determine the target cloud migration infrastructure through neural networks, as in Shinde, using continuous integration and deployment node traversal, as in Sweeney, while determining the associated single sign on as well as application nodes associated with neural network requirements, as in Duggal, with a pipeline integrator to test the migration, as in Prasad, and integrating a code repository coupled to the neural network in order to manage migration accordingly, as in Iruvanti. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of enabling user commits to a source repository with automated processes to check for errors and suggest remediation accordingly with knowledge graphs (Iruvanti [0020]).
Claims 12-15 and 18 are directed to a method corresponding to the neural network as
disclosed in claims 3-6 and 9 respectively. Thus, claims 12-15 and 18 are rejected for the same
reasons set forth in claims 3-6 and 9.
Claims 8 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Shinde in
view of Sweeney in view of Duggal in view of Prasad in view of Iruvanti as applied to claims 1 and 10 above, and further in view of US 20210117425 A1 hereinafter "Rao".
With regards to claim 8, the rejection of claim 1 is incorporated.
The combination of Shinde, Sweeney, Duggal, Prasad, and Iruvanti does not teach: comprising an application dynamics interface, the application dynamics interface that posts a plurality of user app specific metrics post cloud migration.
However, in an analogous art Rao teaches comprising an application dynamics
interface, the application dynamics interface that posts a plurality of user app specific
metrics post cloud migration. (Rao [0383-385], "he data intake and query platform provides
various features that simplify the developers' task to create various applications. One such
application is a virtual machine monitoring application, such as SPLUNK® APP FOR
VMWARE® that provides operational visibility into granular performance metrics, logs, tasks
and events, and topology from hosts, virtual machines and virtual centers [comprising an application dynamics interface, the application dynamics interface]. It empowers administrators
with an accurate real-time picture of the health of the environment, proactively identifying
performance and capacity bottlenecks In contrast, the virtual machine monitoring application
stores large volumes of minimally processed machine data, such as performance information and
log data, at ingestion time for later retrieval and analysis at search time when a live performance
issue is being investigated [post cloud migration]. In addition to data obtained from various log
files, this performance-related information can include values for performance metrics obtained
through an application programming interface (API) provided as part of the vSphere
Hypervisor™ system [that posts a plurality of user app specific metrics]")
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 Rao into the
teachings of Shinde in view of Sweeney in view of Duggal in view of Prasad and further in view of Iruvanti. This combination of teachings would have resulted in a method configured to determine the target cloud migration infrastructure through neural networks, as in Shinde, using continuous integration and deployment node traversal, as in Sweeney, while determining the associated single sign on as well as application nodes associated with neural network requirements, as in Duggal, with a pipeline integrator to test the migration, as in Prasad, and integrating a code repository coupled to the neural network in order to manage migration accordingly, as in Iruvanti, with an interface to monitor and display post migration performance, as in Rao. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using computing environments to generate machine data that can be monitored and analyzed to derive insights (Rao [0128]).
Claim 17 is directed to a method corresponding to the neural network as disclosed in
claim 8. Thus, claim 17 is rejected for the same reasons set forth in claim 8
Response to Arguments
In the Remarks, Applicant Argues:
Applicant respectfully traverses the rejection of Claims 1-18 under 35 U.S.C. § 101. The Claims Integrate Allegedly Abstract Ideas into Practical Applications. The claims recite more than a generic “apply it” instructions. The claims recite significantly more under step 2B.
Examiner’s Response:
Applicant’s amendments/arguments are persuasive and the rejections are hereby withdrawn.
In the Remarks, Applicant Argues:
The Examiner relies upon Shinde's generic neural network architecture and equates conventional neural-network neurons with Applicant's claimed migration nodes.
Applicant respectfully submits that these are not the same.
The claimed CICD nodes, cloud configuration nodes, SSO nodes, and application nodes are functional cloud-migration components described throughout the Specification as representing deployment infrastructure, authentication infrastructure, application infrastructure, and cloud configuration infrastructure.
Examiner’s Response:
With respect to the applicant’s argument “The Examiner relies upon Shinde's generic neural network architecture and equates conventional neural-network neurons with Applicant's claimed migration nodes. Applicant respectfully submits that these are not the same” Examiner respectfully disagrees. One of ordinary skill in the art would interpret a node and a neuron as interchangeable terminology describing computational units, that are traversed in a neural network, in order to generate outputs.
In the Remarks, Applicant Argues:
Shinde merely discloses neurons within a machine-learning model.
Nothing in Shinde teaches or suggests that individual neurons correspond to CICD components, cloud configuration components, SSO components, or application migration components.
Nor does Shinde disclose forming a cloud migration configuration from one selected node of each claimed category.
Rather, Shinde utilizes a neural network to generate cloud recommendations.
Applicant's claims, on the other hand, require a cloud migration configuration
formed from selected CICD nodes, cloud configuration nodes, SSO nodes, and application nodes, together with cloud-migration testing and code rewriting functionality.
Examiner’s Response:
With respect to the applicant’s argument, “Shinde merely discloses neurons within a machine-learning model. Nothing in Shinde teaches or suggests that individual neurons correspond to CICD components, cloud configuration components, SSO components, or application migration components. Nor does Shinde disclose forming a cloud migration configuration from one selected node of each claimed category.” Examiner respectfully disagrees. Examiner asserts that Shinde is used to teach a neural network that corresponds to a cloud configuration. Sweeney teaches a neural network with CI/CD nodes, and Duggal teaches a neural network with SSO nodes. Furthermore, with respect to the applicant’s argument “Nor does Shinde disclose forming a cloud migration configuration from one selected node of each claimed category. Rather, Shinde utilizes a neural network to generate cloud recommendations.” Examiner asserts that the claims describe a neural network in use with implementation which could mean providing recommendations for configuration but does not require the generation of a cloud configuration itself. Therefore, the rejection of claims 1, 3-6, 8-10, 12-15, and 17-18 under 35 U.S.C. 103 are proper and are maintained.
In the Remarks, Applicant Argues:
Applicant respectfully submits that Prasad is directed to software release evaluation, change-management review, and production deployment analysis. Prasad does not seem to show or suggest a cloud migration architecture, does not seem to show or suggest selecting cloud migration nodes, and does not seem to show or suggest a CICD pipeline integrator that tests a cloud migration generated from selected CICD, cloud configuration, SSO, and application nodes.
The claim recites a CICD pipeline integrator operating within applicant's cloud
migration framework for testing an implemented cloud migration. Prasad merely evaluates software release requests and deployment changes. Evaluating a software release is fundamentally different from testing a cloud migration architecture assembled from selected migration nodes.
However, Prasad's "confidence score" is merely a release-management risk
assessment associated with a proposed software change. The cited passage does not disclose a cloud migration compliance score, does not assess success or compliance of a cloud migration, and does not evaluate operation of a migrated application within a cloud environment.
Fundamentally, evaluating a software release is different from testing a cloud migration architecture assembled from selected migration nodes.
Examiner’s Response:
With respect to the applicant’s argument that “Prasad merely evaluates software release requests and deployment changes. Evaluating a software release is fundamentally different from testing a cloud migration architecture assembled from selected migration nodes” Examiner asserts that Prasad teaches a release management module that interfaces and can configure the cloud migration aspects such as change management, deployment authentication, implementation, and production systems which is analogous to the described cloud migration. Furthermore, both a migration compliance score and a confidence score remain arbitrary numbers to describe an assessment of a configuration of a system environment/cloud environment which does further evaluate the degree to which the environment/migration is able to comply with continuous integration/development requirements. Therefore, the rejection of claims 1, 3-6, 8-10, 12-15, and 17-18 under 35 U.S.C. 103 remains proper and maintained.
In the Remarks, Applicant Argues:
In short, the subject matter of cancelled claim 7 (and 16) as filed recites "rewriting the code in which the application is written and integrating the code for use with the cloud migration." The cited portions of Iruvanti do not show or suggest rewriting code. They merely disclose storing source code, analyzing build dependencies, and executing build processes. Storage and analysis of source code are not equivalent to rewriting source code.
Moreover, the claims further recite integrating the rewritten code for use with a
cloud migration. The cited passages do not disclose cloud migration whatsoever. Iruvanti is directed to mainframe build validation and build-risk analysis. The reference does not describe converting applications for cloud deployment, generating cloud-compatible code, integrating rewritten code into a cloud architecture, or implementing a cloud migration.
The Examiner therefore appears to rely upon applicant's disclosure as a template for reconstructing the claimed functionality from isolated teachings relating to source repositories and build systems.
Accordingly, Iruvanti does not teach or suggest a code repository configured to
rewrite application code and integrate the rewritten code for use with a cloud migration as recited by former claim 7.
Examiner’s Response:
With regards to the applicant’s argument “The reference does not describe converting applications for cloud deployment, generating cloud-compatible code, integrating rewritten code into a cloud architecture, or implementing a cloud migration” Examiner asserts that Iruvanti discloses a method of utilizing a knowledge graph (AI/machine learning/neural network) that can generate and thereby update/rewrite code. The recited limitation describes updated mainframe code that is stored to a repository thereby implementing a system for continuous integration. Therefore, in combination with Shinde, Sweeney, and Duggal, Iruvanti uses the described neural network to generate and update software for continuous integration, development, and eventual deployment or use in alternate environments. Examiner has provided a clear articulation of the reasons why the claimed invention would have been obvious. When a rejection depends on a combination of prior art references, there must be some teaching, suggestion, or motivation to combine the references. See In re Geiger, 815 F.2d 686, 688, 2 USPQ2d 1276, 1278 (Fed. Cir. 1987). Therefore, the Examiner’s rejections of the claims on obviousness grounds are not based on mere conclusory statements because the teaching-suggestion-motivation (TSM) test asks not merely what the references disclose, but whether a person of ordinary skill in the art, possessed with the understandings and knowledge reflected in the prior art, and motivated by the general problem facing the inventor, would have been led to make the combination recited in the claims. See Cross Med. Prods., 424 F.3d at 1321-24. From this it may be determined whether the overall disclosures, teachings, and suggestions of the prior art, and the level of skill in the art—i.e., the understandings and knowledge of persons having ordinary skill in the art at the time of the invention—support the legal conclusion of obviousness. See Princeton Biochemicals, 411 F.3d at 1338 (pointing to evidence supplying detailed analysis of the prior art and the reasons one of ordinary skill would have possessed the knowledge and motivation to combine). Therefore, the rejection of claims 1, 3-6, 8-10, 12-15, and 17-18 under 35 U.S.C. 103 remains proper and maintained.
In the Remarks, Applicant Argues:
Sweeney Does Not Teach The Claimed CICD Nodes
The Examiner relies on Sweeney's knowledge-graph nodes as allegedly corresponding to Applicant's CICD nodes.
However, Sweeney merely discusses information nodes associated with software- development activities.
A knowledge-graph node storing information concerning software development is not a CICD node as claimed.
Examiner’s Response:
With respect to the applicant’s argument that “Sweeney merely discusses information nodes associated with software- development activities. A knowledge-graph node storing information concerning software development is not a CICD node as claimed” Examiner asserts that under its broadest reasonable interpretation a CICD node are incorporated in a neural network or knowledge graph as computing elements that can represent software development patterns management and control information. Therefore, the rejection of claims 1, 3-6, 8-10, 12-15, and 17-18 under 35 U.S.C. 103 remains proper and maintained.
In the Remarks, Applicant Argues:
Duggal Does Not Teach The Claimed SSO Nodes Or Application Nodes
The Examiner relies on Duggal's security services and application services.
However, Duggal merely lists available services within a platform architecture.
Duggal does not disclose a plurality of SSO nodes and a plurality of application
nodes arranged within a cloud-migration neural-network architecture and selected to form a cloud migration configuration.
Examiner’s Response:
With respect to the applicant’s argument that “Duggal merely lists available services within a platform architecture. Duggal does not disclose a plurality of SSO nodes and a plurality of application nodes arranged within a cloud-migration neural-network architecture and selected to form a cloud migration configuration” Examiner respectfully disagrees. Duggal teaches a model driven design using decision gateways/algorithms in order to configure domain models that automate cloud computing. Duggal further teaches model objects that describe application services and in correspondence to Single Sign on Objects as described in paragraph [0148]. Therefore, the rejection of claims 1, 3-6, 8-10, 12-15, and 17-18 under 35 U.S.C. 103 remains proper and maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Tiwari (US 20240370287 A1): Computer implemented methods, systems, and computer program products include program code executing on a processor(s) that ingests data from one or more computing environments, where the data is related to applications. The processor(s) identifies, based on utilizing topic modeling and latent semantic analysis of the data, homogenous applications among the applications, which include analyzing subdata handled by each application and functionalities of each application; the homogenous applications comprise similarities in the data and in the functionalities. The processor(s) determines overlapping data among the homogenous applications based on the topic modeling, the latent semantic analysis, and term frequency-inverse document frequency of terms in the overlapping data. The processor(s) selects, from the overlapping data, training data. The processor(s) utilizes the training data to calculate weights for disposition metrics and the metrics to predict the resource dispositions for the applications.
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 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