DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-5, 7-11, and 13-17 are pending in this application.
Response to Arguments
Applicant' s arguments regarding the rejections of claims 1-5, 7-11, and 13-17 under 35 U.S.C. 112b have been fully considered and are persuasive. The rejections have been withdrawn.
Applicant's arguments regarding the 35 U.S.C. 103 rejections of claims 1-5, 7-11, and 13-17 have been fully considered but they are either moot in light of the references applied in the current rejection or not persuasive.
Regarding the 35 U.S.C. 103 rejection, the applicant argues the following in the remarks:
The references fail to teach “initiating, by the computer program, interactions between the computer program and a cloud system to provision the selected pattern and the selected resource to the cloud system”.
The references fail to teach “onboarding, by the computer program, the selected pattern and the selected resource”.
The references fail to teach “provisioning, by the computer program and to the cloud system, a user-specific system comprising the selected resource”.
The references fail to teach “monitoring, by the computer program, use of the user-specific system by the at least one account”.
Examiner has thoroughly considered Applicant' s arguments, but respectfully finds them unpersuasive for at least the following reasons:
As to point (a), this point is moot in light of the references being applied in the current rejection.
As to point (b), the examiner respectfully disagrees. Applicant argues that the SOA environment is a user-specific system rather than a selected resource but provides no support for this argument.
As to point (c), this point is moot in light of the references being applied in the current rejection.
As to point (d), the examiner respectfully disagrees. Gungabeesoon recites in [0057] “Where the service interface specification is validated, the project owner or solution architect is notified for further review and approval, for example, of the metadata of the service, for example, the service name, domain name, target namespace, etc. This review and approval stage is considered a mandatory governance and approval checkpoint, which can be controlled by the project owner or solution architect for enforcing the service specification and for ensuring that the service design meets particular design standards”, in [0066] “The service promotion module 252 noted previously is a stage and component within the service delivery pipeline 240 operable to promote the service for deployment. For example, the service promotion module 252 can promote the service during its development cycle from the DEV (development) areas to the PROD (production) areas of the SOA environment 270 mentioned previously. In some embodiments, the service promotion module 252 includes a built-in governance approval checkpoint controlled by the project owner. Upon the owner's approval based on the satisfactory status of the testing results (e.g. by reviewing the outcome of the automated tester module 248 or reviewing the results from the end-to-end tests performed by a quality assurance team)”, in [0045] “Once a user is authenticated, SFUI 213 allows users, such as project owners, to manage service delivery, project-level configuration and promote services to upper level environments (e.g. from a pre-staging area to a staging/controlled area of the SOA environment 270). SFUI 213 can further be used by users, such as developers of the services, to configure, generate, deploy, and test the services (e.g. DataPower™ services) generated by a SF Service Generator 242”, and in [0046] “In some embodiments, SFUI 213 is configurable to provide a development portal intended for project owners or service developers to manage projects or service configurations…The configuration parameters for a service delivery project include defining the name of the project, owner, default service version, names of a set of environments, service shared objects' configurations such as front side handlers, port numbers, backend connectivity information for the database and other proprietary systems such as IBM MQ™, URLs of backend services, and the network addresses of the target SOA environment 270. The configuration parameters of a service include, but are not limited to, defining the configuration information for each operation of a service such as the service integration pattern type”. In Gungabeesoon, a project owner configures a service and the configured service is tested and results of the tests are determined. Testing the configured service means that the configured service is used. The authenticated user can be considered an account and it monitors the service configured by the project owner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5, 7-11, and 13-17 are rejected under 35 U.S.C. 103 as being unpatentable over Gungabeesoon et al. (US 20210004226 A1 hereinafter Gungabeesoon), in view of Franchitti (US 20190171438 A1), and further in view of Pathak et al. (US 20190207866 A1 hereinafter Pathak).
Gungabeesoon and Franchitti were cited in a previous office action.
As per claim 1, Gungabeesoon teaches the invention substantially as claimed including a computer-implemented method, comprising: receiving, by a computer program and from a user portal, a user identifier for a user ([0045] User access to the SFUI 213 is controlled by a SF Source Control Management (“SCM”) server 262 using various suitable system login methods including single sign-on (SSO), i.e. only valid SCM users can access SFUI 213. The user authorization to the functions of the SFUI 213 and SFS 215 is controlled by the SCM's role-based user authorization. Once a user is authenticated, SFUI 213 allows users, such as project owners, to manage service delivery, project-level configuration);
retrieving, by the computer program executed by a computer processor, and based on the user identifier, an identification of a plurality of patterns and an identification of a plurality of resources available to the user based on a set of entitlements associated with the user identifier ([0048] The SFS 215 can be deployed as an application to handle requests from the SFUI and trigger pipelines (i.e. processes) residing within the SF engine (“SFE”) 220 or manipulate SCM repositories within the SCM server 262 on behalf of users. User access to the SFUI within the SF IDE 214 can be controlled by the SCM server 262 using single sign on (“SSO”). The user authorization to resources is controlled by SCM's role-based user authorization; [0045] the SFUI 213 is designed and implemented as a web-based graphical user interface (“GUI”) application to manage a SOA service delivery project and can be deployed as an independent application to submit users' requests to a service factory server (“SFS”) 215 which is further described below. User access to the SFUI 213 is controlled by a SF Source Control Management (“SCM”) server 262 using various suitable system login methods including single sign-on (SSO), i.e. only valid SCM users can access SFUI 213. The user authorization to the functions of the SFUI 213 and SFS 215 is controlled by the SCM's role-based user authorization. Once a user is authenticated, SFUI 213 allows users, such as project owners, to manage service delivery, project-level configuration and promote services to upper level environments (e.g. from a pre-staging area to a staging/controlled area of the SOA environment 270). SFUI 213 can further be used by users, such as developers of the services, to configure, generate, deploy, and test the services (e.g. DataPower™ services) generated by a SF Service Generator 242; Abstract Based on the specification, at least one pattern template for the software service is selected from a library of templates; [0012] The system may also include a graphical user interface for inputting the configuration specification by a user of the system; [0069] An infrastructure modules component 320 is operable to provide supporting modules that are used by the service generator 242 to generate components for the service when the service delivery pipeline 240 is activated. The infrastructure modules component 320 includes a library of service source code pattern templates for the service generator 242 to instantiate the service);
presenting, by the computer program, the identification of the plurality of patterns and the identification of the plurality of resources to the user for selection (Abstract Based on the specification, at least one pattern template for the software service is selected from a library of templates; [0012] The system may also include a graphical user interface for inputting the configuration specification by a user of the system; [0046] In some embodiments, SFUI 213 is configurable to provide a development portal intended for project owners or service developers to manage projects or service configurations, respectively. For example, the development portal allows project owners to initialize a service delivery project (e.g. create a new project) and manage the configuration or settings of an existing project, also allows developers to manage the configuration of a SOA service. The configuration parameters for a service delivery project include defining the name of the project, owner, default service version, names of a set of environments, service shared objects' configurations such as front side handlers, port numbers, backend connectivity information for the database and other proprietary systems such as IBM MQ™, URLs of backend services, and the network addresses of the target SOA environment 270. The configuration parameters of a service include, but are not limited to, defining the configuration information for each operation of a service such as the service integration pattern type, backend service connectivity information; [0072] to select suitable code pattern or design templates from the pattern templates library within the infrastructure modules component 320 based on the interface configuration of the service; Claim 12 a graphical user interface for inputting the configuration specification by a user; [0039] Referring first to FIG. 1, shown therein is a block diagram of an architecture 100 to enable the resources and/or functionalities available on one or more legacy computing systems 102-1 to 102-N (collectively, 102) to be available and accessible within SOA Service Consumers Layer 110; [0007] expose computing and/or software functionalities available on legacy computing systems to a service-oriented computing environment; [0042] the particulars of the legacy system that the service is intended to operate with, can be defined using service requirements 202);
receiving, by the computer program and from the user portal, a selection of a selected pattern of the identified plurality of patterns and a selected resource of the identified plurality of resources from the user (Abstract Based on the specification, at least one pattern template for the software service is selected from a library of templates; [0012] The system may also include a graphical user interface for inputting the configuration specification by a user of the system; [0046] In some embodiments, SFUI 213 is configurable to provide a development portal intended for project owners or service developers to manage projects or service configurations, respectively. For example, the development portal allows project owners to initialize a service delivery project (e.g. create a new project) and manage the configuration or settings of an existing project, also allows developers to manage the configuration of a SOA service. The configuration parameters for a service delivery project include defining the name of the project, owner, default service version, names of a set of environments, service shared objects' configurations such as front side handlers, port numbers, backend connectivity information for the database and other proprietary systems such as IBM MQ™, URLs of backend services, and the network addresses of the target SOA environment 270. The configuration parameters of a service include, but are not limited to, defining the configuration information for each operation of a service such as the service integration pattern type, backend service connectivity information; [0045] a suitable service factory user interface (“SFUI”) 213 for specifying and inputting the service requirements 202…SFUI 213 can further be used by users, such as developers of the services, to configure, generate, deploy, and test the services (e.g. DataPower™ services) generated by a SF Service Generator 242; [0043] The service requirements 202 are captured by service designers using standard templates offered by the SF 210 to help design a service interface specification. The service interface specification along with other information about the service help define the configuration specifications of the service; [0041] FIG. 2 is a block diagram depicting the architecture of a SOA Service Factory, an automated SOA service delivery platform 200 according to an embodiment of the invention for specifying, generating, verifying and deploying services);
creating, by the computer program, a project for the selected pattern ([0046] In some embodiments, SFUI 213 is configurable to provide a development portal intended for project owners or service developers to manage projects or service configurations, respectively. For example, the development portal allows project owners to initialize a service delivery project (e.g. create a new project) … The configuration parameters of a service include, but are not limited to, defining the configuration information for each operation of a service such as the service integration pattern type; Abstract Based on the specification, at least one pattern template for the software service is selected from a library of templates);
creating, by the computer program, a development pipeline that is linked to the project ([0059] The service delivery pipeline generator module 228 noted previously corresponds to a stage and component in the service interface specification review pipeline 222 that generates the service delivery pipeline 240 for a specific service to be generated, built, tested, and deployed, promoted, and published; [0046] For example, the development portal allows project owners to initialize a service delivery project);
onboarding, by the computer program, the selected pattern and the selected resource ([0067] The service code templates are created based on service integration patterns as code fragments for instantiating and composing a complete service based on the service configuration; [0041] deploying services that enable resources and functionalities residing in one or more legacy systems to be accessible within a SOA environment 270; [0046] In some embodiments, SFUI 213 is configurable to provide a development portal intended for project owners or service developers to manage projects or service configurations, respectively. For example, the development portal allows project owners to initialize a service delivery project (e.g. create a new project) and manage the configuration or settings of an existing project, also allows developers to manage the configuration of a SOA service. The configuration parameters for a service delivery project include defining the name of the project, owner, default service version, names of a set of environments, service shared objects' configurations such as front side handlers, port numbers, backend connectivity information for the database and other proprietary systems such as IBM MQ™, URLs of backend services, and the network addresses of the target SOA environment 270. The configuration parameters of a service include, but are not limited to, defining the configuration information for each operation of a service such as the service integration pattern type, backend service connectivity information; [0047] In some embodiments, the SFUI 213 is further configurable to provide a service lifecycle portal intended for service developers to generate and deploy services to various SDLC areas of the SOA environment 270. Activities carried out within this portal include reviewing and approving the specifications for the service, managing the build of shared objects (e.g. converting service source code into binary objects), and publication and promotion of the generated service. Shared objects are stored in the BRM server 264 noted above prior to deployment into the SOA environment 270. The lifecycle portal also operates in conjunction with a service gateway 272, such as DataPower™, to deploy the shared objects (i.e. services) to target areas within the SOA environment 270. More specifically, the service gateway 272 provides pre-staging areas such as the Development (DEV) and Shakedown (SHK) environments, and staging areas (i.e. pre-production or controlled areas) such as User Acceptance Test (UAT), Non-Functional Test (NFT), as well as Production (PROD) environments. The lifecycle portal allows project owners to deploy binary objects services such as DataPower™ shared objects, and to promote and approve service deployment to those above-mentioned target environments; [0070] The template instantiation component is called for instantiating service code based on the configured service integration pattern. The dynamic task generation component is called for generating a build task to transform service configuration template files based on service specific dynamic configuration values during the service generation process.);
provisioning, by the computer program, a user-specific system comprising the selected resource ([0047] In some embodiments, the SFUI 213 is further configurable to provide a service lifecycle portal intended for service developers to generate and deploy services to various SDLC areas of the SOA environment 270. Activities carried out within this portal include reviewing and approving the specifications for the service, managing the build of shared objects (e.g. converting service source code into binary objects), and publication and promotion of the generated service. Shared objects are stored in the BRM server 264 noted above prior to deployment into the SOA environment 270. The lifecycle portal also operates in conjunction with a service gateway 272, such as DataPower™, to deploy the shared objects (i.e. services) to target areas within the SOA environment 270; [0038] Described in more details below are the various modules of the SOA Service Factory to provide DevOps CI pipelines, which improve the agility of developing and delivering service runnable artifacts to the target platforms; [0046] In some embodiments, SFUI 213 is configurable to provide a development portal intended for project owners or service developers to manage projects or service configurations…The configuration parameters for a service delivery project include defining the name of the project, owner, default service version, names of a set of environments, service shared objects' configurations such as front side handlers, port numbers, backend connectivity information for the database and other proprietary systems such as IBM MQ™, URLs of backend services, and the network addresses of the target SOA environment 270. The configuration parameters of a service include, but are not limited to, defining the configuration information for each operation of a service such as the service integration pattern type; [0042] the particulars of the legacy system that the service is intended to operate with, can be defined using service requirements 202);
authorizing, by the computer program, the user to access the user-specific system ([0052] Within the SOA environment 270, the service gateway 272 is a service gateway for housing the generated services including web services, accessible via a suitable protocol such as the SOAP (Simple Object Access Protocol) protocol. For example, services created by the SF 210 that have been deployed within the SOA environment 270 may reside within the service gateway 272 to allow clients of the SOA environment 270 to access the generated services. In some embodiments, the SOA environment 270 may be implemented using IBM™ DataPower™ Gateway. A service registry 274 is for publishing and managing metadata (e.g. configuration parameters, non-technical information, description of service, etc.) of services available in the SOA environment 270 for the future discovery and reuse purposes; [0045] Once a user is authenticated, SFUI 213 allows users, such as project owners, to manage service delivery, project-level configuration and promote services to upper level environments (e.g. from a pre-staging area to a staging/controlled area of the SOA environment 270). SFUI 213 can further be used by users, such as developers of the services, to configure, generate, deploy, and test the services (e.g. DataPower™ services) generated by a SF Service Generator 242; [0046] In some embodiments, SFUI 213 is configurable to provide a development portal intended for project owners or service developers to manage projects or service configurations, respectively. For example, the development portal allows project owners to initialize a service delivery project (e.g. create a new project) and manage the configuration or settings of an existing project, also allows developers to manage the configuration of a SOA service);
making, by the computer program, the selected resource in the provisioned user-specific system and at least one account available for discovery ([0052] A service registry 274 is for publishing and managing metadata (e.g. configuration parameters, non-technical information, description of service, etc.) of services available in the SOA environment 270 for the future discovery; [0063] A service deployer module 246 is a stage and component within the service delivery pipeline 240 operable for deploying the specific files versions of a service distribution package with the required access privileges to a target area within the SOA environment 270. As noted earlier, the SOA environment 270 may be divided into different areas for deploying services for the purposes of testing/staging and actual use (i.e. production); [0039] Referring first to FIG. 1, shown therein is a block diagram of an architecture 100 to enable the resources and/or functionalities available on one or more legacy computing systems 102-1 to 102-N (collectively, 102) to be available and accessible within SOA Service Consumers Layer 110; [0007] expose computing and/or software functionalities available on legacy computing systems to a service-oriented computing environment; [0045] User access to the SFUI 213 is controlled by a SF Source Control Management (“SCM”) server 262 using various suitable system login methods including single sign-on (SSO), i.e. only valid SCM users can access SFUI 213; [0046] In some embodiments, SFUI 213 is configurable to provide a development portal intended for project owners or service developers to manage projects or service configurations…The configuration parameters for a service delivery project include defining the name of the project, owner, default service version, names of a set of environments, service shared objects' configurations such as front side handlers, port numbers, backend connectivity information for the database and other proprietary systems such as IBM MQ™, URLs of backend services, and the network addresses of the target SOA environment 270. The configuration parameters of a service include, but are not limited to, defining the configuration information for each operation of a service such as the service integration pattern type); and
monitoring, by the computer program, use of the user-specific system by the at least one account (Fig. 2; [0057] Where the service interface specification is validated, the project owner or solution architect is notified for further review and approval, for example, of the metadata of the service, for example, the service name, domain name, target namespace, etc. This review and approval stage is considered a mandatory governance and approval checkpoint, which can be controlled by the project owner or solution architect for enforcing the service specification and for ensuring that the service design meets particular design standards; [0066] The service promotion module 252 noted previously is a stage and component within the service delivery pipeline 240 operable to promote the service for deployment. For example, the service promotion module 252 can promote the service during its development cycle from the DEV (development) areas to the PROD (production) areas of the SOA environment 270 mentioned previously. In some embodiments, the service promotion module 252 includes a built-in governance approval checkpoint controlled by the project owner. Upon the owner's approval based on the satisfactory status of the testing results (e.g. by reviewing the outcome of the automated tester module 248 or reviewing the results from the end-to-end tests performed by a quality assurance team); [0045] Once a user is authenticated, SFUI 213 allows users, such as project owners, to manage service delivery, project-level configuration and promote services to upper level environments (e.g. from a pre-staging area to a staging/controlled area of the SOA environment 270). SFUI 213 can further be used by users, such as developers of the services, to configure, generate, deploy, and test the services (e.g. DataPower™ services) generated by a SF Service Generator 242; [0046] In some embodiments, SFUI 213 is configurable to provide a development portal intended for project owners or service developers to manage projects or service configurations…The configuration parameters for a service delivery project include defining the name of the project, owner, default service version, names of a set of environments, service shared objects' configurations such as front side handlers, port numbers, backend connectivity information for the database and other proprietary systems such as IBM MQ™, URLs of backend services, and the network addresses of the target SOA environment 270. The configuration parameters of a service include, but are not limited to, defining the configuration information for each operation of a service such as the service integration pattern type;).
Gungabeesoon fails to teach initiating, by the computer program, interactions between the computer program and a cloud system to provision the selected pattern and the selected resource to the cloud system; associating, by the computer program, the project with a financial telemetry tool to monitor costs for the project; provisioning, by the computer program and to the cloud system, a user-specific system comprising the selected resource.
However, Franchitti teaches associating, by the computer program, the project with a financial telemetry tool to monitor costs for the project ([0464] there must be a cost/benefit model in place to solicit active bilateral participation from all projects; [0546] The business output from such projects will be optimized outcomes (e.g., maximized revenues, minimized costs; [0278] Archemy™ uses the Blockchain 2.0 Ethereum platform to implement a global cost management application to bill (i.e., debit or credit) the various DKME participants for BSRs, SURs, and all other support requests; [0164] purposes of financial recordkeeping, billing; [0220] To streamline the complexity of rating and billing service requests and associated costs within its global DKME, Archemy™ uses blockchain along with a D3 Ethereum application (DApp) that customers can use to review their bills.)
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Gungabeesoon with the teachings of Franchitti to minimize costs (see Franchitti [0546] The business output from such projects will be optimized outcomes (e.g., maximized revenues, minimized costs).
Gungabeesoon and Franchitti fail to teach initiating, by the computer program, interactions between the computer program and a cloud system to provision the selected pattern and the selected resource to the cloud system; provisioning, by the computer program and to the cloud system, a user-specific system comprising the selected resource.
However, Pathak teaches initiating, by the computer program, interactions between the computer program and a cloud system to provision the selected pattern and the selected resource to the cloud system; provisioning, by the computer program and to the cloud system, a user-specific system comprising the selected resource ([0042] when a one-to-one composition pattern is selected for an application and this software service then initially the dependent software service(s) are instantiated and deployed at a cloud resource and/or device; abstract the platform broker determines whether the software service is to be deployed at a cloud resource or devices. Based on the determination and a composition pattern, the platform broker sends a software service deployment request to a cloud broker and a device broker. Based on the software service deployment request, an instance of the software service generates and deploys the generated instance of the software service to one of the cloud resource and the one or more devices; [0045] In one embodiment, the cloud device platform also allows a user to define a singleton composition pattern when the software service has to be instantiated only for the first deployment request; [0074] In case the customized cloud device application has a one-to-one composition pattern (condition in 918 is true) then the platform broker sends a cloud deployment request to a cloud broker at the cloud device platform (920), as shown in FIG. 9B. The cloud deployment request includes the deployment request received at the platform broker and a destination address of the cloud resource where the software service included in the customized cloud device application is to be deployed; [0043] Similarly, the user may select a one-to-many composition pattern; [0037] A user provides name 204, version 206, and description 208 of the application and/or software service at the form 202. The user also defines the runtime 210 of the application or software service. The runtime of the application or software service defines whether the application or software service is to be executed at the cloud resource and/or the device; [0039] In one embodiment, the form 202 also allows a user to select a composition pattern (not shown) for composing an application with the selected software service. Composing an application is a process to select a pattern in which the application and application service work together to perform one or more useful actions; [0066] The cloud device platform 800 includes a user interface 804 that allows selection of the different services from the software and device service store 802 and one or more devices and/or cloud resources at which the application and/or selected software services is to be deployed).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Gungabeesoon and Franchitti with the teachings of Pathak to produce a desired behavior (see Pathak [0043] This composition pattern is selected when the developer needs to compose the desired service behaviour).
As per claim 2, Gungabeesoon, Franchitti, and Pathak teach the method of claim 1. Franchitti teaches wherein the user identifier is further associated with a geography or region ([0702] Individuals can share information about events and locations using their mobile phones).
As per claim 3, Gungabeesoon, Franchitti, and Pathak teach the method of claim 1. Gungabeesoon teaches further comprising: receiving, by the computer program, a selection of resource attributes for the selected resource ([0046] In some embodiments, SFUI 213 is configurable to provide a development portal intended for project owners or service developers to manage projects or service configurations, respectively. For example, the development portal allows project owners to initialize a service delivery project (e.g. create a new project) and manage the configuration or settings of an existing project, also allows developers to manage the configuration of a SOA service. The configuration parameters for a service delivery project include defining the name of the project, owner, default service version, names of a set of environments, service shared objects' configurations such as front side handlers, port numbers, backend connectivity information for the database and other proprietary systems such as IBM MQ™, URLs of backend services, and the network addresses of the target SOA environment 270.).
As per claim 4, Gungabeesoon, Franchitti, and Pathak teach the method of claim 1. Gungabeesoon teaches further comprising: receiving, by the computer program, a selection of authorized users or groups for onboarding; wherein the authorized users or groups are granted access to the user-specific system ([0045] User access to the SFUI 213 is controlled by a SF Source Control Management (“SCM”) server 262 using various suitable system login methods including single sign-on (SSO), i.e. only valid SCM users can access SFUI 213; [0052] allow clients of the SOA environment 270 to access the generated services. In some embodiments, the SOA environment 270 may be implemented using IBM™ DataPower™ Gateway. A service registry 274 is for publishing and managing metadata (e.g. configuration parameters, non-technical information, description of service, etc.) of services available in the SOA environment 270 for the future discovery and reuse purposes; [0046] In some embodiments, SFUI 213 is configurable to provide a development portal intended for project owners or service developers to manage projects or service configurations).
As per claim 5, Gungabeesoon, Franchitti, and Pathak teach the method of claim 1. Franchitti teaches further comprising: generating, by the computer program, a cost estimate for the selected resource; and receiving, by the computer program, approval for the cost estimate; wherein the approval is received before the user-specific system is provisioned ([0469] the DKMF requires authorized human approval to perform a behavior upgrade on a business solution node. There are two reasons for this. On one hand, a behavior upgrade may result in increasing the node DKME subscription cost, as well as services or transactions costs; [0528] An important aspect of the DKME is the fact that any update requested by intelligent active and/or autonomous business solutions is subject to review and approval (e.g., service charges authorization) by the end users of the solutions; [0471] 1. The DKMF provides real-time access to a knowledge base that supports a novel way to select best practice business components that can be reused to help intelligent active and/or autonomous business solutions address end users' requests.).
As per claim 7, it is an electronic device claim of claim 1, so it is rejected for similar reasons. Additionally, Gungabeesoon teaches an electronic device, comprising: a memory storing a computer program; and a computer processor; wherein, when executed by the computer processor, the computer program causes the computer processor to ([0041] The Service Factory 210 can be hosted on a local or on-premises computing system or by way of a distributed or cloud-based environment located remotely at a data center; Data centers include memory with computer programs and computer processors.)
As per claims 8-11, they are electronic device claims of claims 2-5, so they are rejected for similar reasons.
As per claim 13, it is an system claim of claim 1, so it is rejected for similar reasons. Additionally, Gungabeesoon teaches a system, comprising: an entitlements library comprising a plurality of user identifiers, each user identifier associated with a set of entitlements for a plurality of patterns and a plurality of resources that the user identifier is authorized to access for a project (Abstract Based on the specification, at least one pattern template for the software service is selected from a library of templates; [0012] The system may also include a graphical user interface for inputting the configuration specification by a user of the system; [0045] provides a suitable service factory user interface (“SFUI”) 213 for specifying and inputting the service requirements 202 to the SF 210. In some embodiments, the SFUI 213 is designed and implemented as a web-based graphical user interface (“GUI”) application to manage a SOA service delivery project and can be deployed as an independent application to submit users' requests to a service factory server (“SFS”) 215 which is further described below. User access to the SFUI 213 is controlled by a SF Source Control Management (“SCM”) server 262 using various suitable system login methods including single sign-on (SSO), i.e. only valid SCM users can access SFUI 213. The user authorization to the functions of the SFUI 213 and SFS 215 is controlled by the SCM's role-based user authorization. Once a user is authenticated, SFUI 213 allows users, such as project owners, to manage service delivery, project-level configuration and promote services to upper level environments (e.g. from a pre-staging area to a staging/controlled area of the SOA environment 270). SFUI 213 can further be used by users, such as developers of the services, to configure, generate, deploy, and test the services (e.g. DataPower™ services) generated by a SF Service Generator 242; [0046] In some embodiments, SFUI 213 is configurable to provide a development portal intended for project owners or service developers to manage projects or service configurations, respectively. For example, the development portal allows project owners to initialize a service delivery project (e.g. create a new project) and manage the configuration or settings of an existing project, also allows developers to manage the configuration of a SOA service. The configuration parameters for a service delivery project include defining the name of the project, owner, default service version, names of a set of environments, service shared objects' configurations such as front side handlers, port numbers, backend connectivity information for the database and other proprietary systems such as IBM MQ™, URLs of backend services, and the network addresses of the target SOA environment 270; [0069] An infrastructure modules component 320 is operable to provide supporting modules that are used by the service generator 242 to generate components for the service when the service delivery pipeline 240 is activated. The infrastructure modules component 320 includes a library of service source code pattern templates for the service generator 242 to instantiate the service; [0048] The SFS 215 can be deployed as an application to handle requests from the SFUI and trigger pipelines (i.e. processes) residing within the SF engine (“SFE”) 220; [0048] The user authorization to resources is controlled by SCM's role-based user authorization; Table 1 A spreadsheet capturing the business properties Spreadsheet (metadata) of a SOA service including service name, business domain, service owner);
a pattern library comprising a plurality of patterns (abstract at least one pattern template for the software service is selected from a library of templates);
a resource library comprising a plurality of resources ([0046] In some embodiments, SFUI 213 is configurable to provide a development portal intended for project owners or service developers to manage projects or service configurations, respectively. For example, the development portal allows project owners to initialize a service delivery project (e.g. create a new project) and manage the configuration or settings of an existing project, also allows developers to manage the configuration of a SOA service. The configuration parameters for a service delivery project include defining the name of the project, owner, default service version, names of a set of environments, service shared objects' configurations such as front side handlers, port numbers, backend connectivity information for the database and other proprietary systems such as IBM MQ™, URLs of backend services, and the network addresses of the target SOA environment 270; [0007] expose computing and/or software functionalities available on legacy computing systems to a service-oriented computing environment; [0039] Referring first to FIG. 1, shown therein is a block diagram of an architecture 100 to enable the resources and/or functionalities available on one or more legacy computing systems 102-1 to 102-N (collectively, 102) to be available and accessible within SOA Service Consumers Layer 110).
As per claims 14-17, they are system claims of claims 2-5, so they are rejected for similar reasons.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 HSING CHUN LIN whose telephone number is (571)272-8522. The examiner can normally be reached Mon - Fri 9AM-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, Aimee Li can be reached at (571) 272-4169. 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.
/H.L./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights