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. However, new 35 U.S.C. 112b rejections are applied to claims 1-5, 7-11, and 13-17 based on the amendments.
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 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 with data center systems and/or cloud systems to provision the selected pattern and the selected resource”.
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 a target electronic device, a user-specific system comprising the selected resource”.
The references fail to teach “authorizing, by the computer program, the user to access the user-specific system”.
The references fail to teach “monitoring, by the computer program, use of the user-specific system”.
Examiner has thoroughly considered Applicant' s arguments, but respectfully finds them unpersuasive for at least the following reasons:
As to point (a), the examiner respectfully disagrees. Gungabeesoon recites in [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 that enable resources and functionalities residing in one or more legacy systems to be accessible within a SOA environment 270. 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 (e.g. Google™ Cloud Services or Amazon™ Web Service)”, in [0044] “The SF 210 includes a service factory tools component (“SF tools”) 212 and a service factory engine component (“SF engine”) 220. The SF tools 212 provide the components and resources for a user to interact with the SF 210”, in [0045] “Within the SF tools 212, a service factory integrated development environment (“SF IDE”) 214 provides a suitable service factory user interface (“SFUI”) 213 for specifying and inputting the service requirements 202 to the SF 210”, 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, 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, data mapping information, and logging and data validations”. The Service Factory 210 can be hosted on a cloud-based environment at a data center. Within the Service Factory 210, there is a service factory tools component 212, and within the service factory tools component 212, there is a service factory user interface 213. Interactions are initiated with the service factory tools component 212, specifically the service factory user interface 213, which provisions the selected pattern and the selected resource. Using the service factory user interface 213, a pattern and resources can be selected to be assigned or provisioned for a service configuration.
As to point (b), the examiner respectfully disagrees. Gungabeesoon recites 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, 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”, in [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”, and in [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”. User selects an SOA environment and service integration pattern type for a configured service. The SOA environment can be considered a selected resource and configured service is deployed on the selected SOA environment, so the selected resource is onboarded. The configured service is instantiated based on the selected service integration pattern type so the selected pattern in onboarded.
As to point (c), the examiner respectfully disagrees. Gungabeesoon recites in [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” 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”. The user-specific system is provisioned or provided since the user configures a service and that service is deployed on a target SOA environment. The user configured service identifies a selected resource which can include a target SOA environment. Since the user configured service is deployed on a target SOA environment, the user-specific system comprising the selected resource is provisioned.
As to point (d), the examiner respectfully disagrees. Gungabeesoon recites in [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” 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, 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”. User creates a user configured service and when it is deployed in an SOA environment, a client is authorized access to it.
As to point (e), 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)”, and 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”. Applicant argues that instead of monitoring the user of the service, Gungabeesoon discloses that it monitors the operational status of the system, but this mischaracterizes the claims and mischaracterizes Gungabeesoon. The use of the user-specified system is monitored, not the user. 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.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-5, 7-11, and 13-17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As per claims 1, 7, and 13 (line numbers refer to claim 1):
Lines 15-17 recite "initiating, by the computer program, interactions with data center systems and/or cloud systems to provision the selected pattern and the selected resource" and lines 26-27 recite "provisioning, by the computer program and to a target electronic device, a user-specific system comprising the selected resource". It is unclear if the target electronic device is a part of the data center systems and/or cloud systems since the interactions with the data center systems and/or cloud systems are initiated to provision the selected resource and the user-specific system which comprises the selected resource is provisioned to the target electronic device.
Line 31 recites "the provisioned selected resource" and it is unclear if this refers to lines 26-27 which recites "provisioning, by the computer program and to a target electronic device, a user-specific system comprising the selected resource" or if this refers to lines 16-17 which recites "provision the selected pattern and the selected resource".
Claims 2-5, 8-11, and 14-17 are dependent claims of claims 1, 7, and 13, respectively, and fail to resolve the deficiencies of claims 1, 7, and 13, so they are rejected for the same reasons.
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).
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);
initiating, by the computer program, interactions with data center systems and/or cloud systems to provision the selected pattern and the selected resource ([0008] The method includes providing a configuration specification defining the software service; selecting at least one pattern template for the software service defined by the configuration specification; outputting source code corresponding to the software service using programming code provided in the selected at least one pattern template; [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 that enable resources and functionalities residing in one or more legacy systems to be accessible within a SOA environment 270. 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 (e.g. Google™ Cloud Services or Amazon™ Web Service); [0044] The SF 210 includes a service factory tools component (“SF tools”) 212 and a service factory engine component (“SF engine”) 220. The SF tools 212 provide the components and resources for a user to interact with the SF 210. [0045] Within the SF tools 212, a service factory integrated development environment (“SF IDE”) 214 provides a suitable service factory user interface (“SFUI”) 213 for specifying and inputting the service requirements 202 to the SF 210; [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, data mapping information, and logging and data validations.);
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 and to a target electronic device, 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 provisioned selected resource 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; [0046] 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, data mapping information, and logging and data validations; [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.); and
monitoring, by the computer program, use of the user-specific system (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.).
Gungabeesoon fails to teach associating, by the computer program, the project with a financial telemetry tool to monitor costs for the project.
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).
As per claim 2, Gungabeesoon and Franchitti 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 and Franchitti 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 and Franchitti 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 and Franchitti 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
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