Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Examiner’s Note (EN)
The prior art rejections below cite particular paragraphs, columns, and/or line numbers in the references for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-2, 5, 10-11, 14, and 19-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Naganuma et al. (US20210064351A1).
Regarding Claim 1, Naganuma teaches a method, comprising: receiving, in a build-time environment, a request to generate a runtime artifact([0041-0043] "The registered package source code 111 is used by the CI system 120 to build (or create) a package. Building the package (building processing) means processing for generating, for example, the installation image(s) 131 for executing the installation, the application image(s) 132 of an application instance(s) 141 executed at a virtual server, a container, and so on, and package management information 133 to be displayed and managed by the marketplace system 130 … The building processing is typically automatically started as triggered by, for example, registration of the package source code 111. In this embodiment, the CI system 120 executes the building processing. Regarding examples of the CI system 120, various resources (such as software and services) such as Jenkins (https://jenkins.io/) and GitLab-CI (https://docs.gitlab.com/ee/ci/) are provided whether with or without consideration. A method for designating the building processing varies depending on the selected resource; and if the CI system 120 has information internally, there may be a case where, for example, the information is included in part of the package source code 111" [0069] "The CI system 120 builds a package source code 111 by using CI management information 521. … Incidentally, in this embodiment, the CI system 120 is not indispensable and the package system 100 may be formed so that a human may perform manual operations to execute the building processing" EN: CI (Continuous Integration) is a build time environment. The request to generate the runtime artifact (installation image) is triggered automatically or manually as described.).
retrieving, from a version repository in a design-time environment, a plurality of design-time artifacts associated with the runtime artifact ([0038-0043] "A provider 101 who registers a package(s) in the marketplace system 130 registers a package source code 111, on which the package to be registered in the marketplace system 130 is based, in a designated repository 110. Examples of the repository 110 include GitHub (https://github.com/) as a cloud service and GitLab as OSS. An example of the package source code 111 will be explained later with reference to FIG. 2. Incidentally, FIG. 1 shows an example in which package source codes 111 for a plurality of packages included in the marketplace system 130 are managed by one repository 110; however, the configuration may be designed so that the repository 110 may be divided for each package source code 111 corresponding to a package" [0214] "A packaging support system (for example, the packaging support system 150) capable of communicating with a first management unit (for example, the repository 110) that manages one or more source codes (for example, the package source code 111), and a marketplace system (for example, the marketplace system 130) that manages one or more packages created based on one of the source codes and causes a package, regarding which an instruction is issued from a terminal operated by a user (for example, the user 102), to be available as an instance … and a packaging unit that, on the basis of reception of an instruction to package a specified instance from the terminal (for example, the terminal 501) operated by the user, acquires a specified source code associated with the specified instance based on the correspondence relationship information from the first management unit and outputs the specified source code" EN: based on the instruction to package an instance, the source code associated with that instance is retrieved from the version repository such as Github).
building, in the build-time environment, a plurality of run-time modules based on the plurality of design-time artifacts ([0041-0042] "The registered package source code 111 is used by the CI system 120 to build (or create) a package. Building the package (building processing) means processing for generating, for example, the installation image(s) 131 for executing the installation, the application image(s) 132 of an application instance(s) 141 executed at a virtual server, a container, and so on, and package management information 133 to be displayed and managed by the marketplace system 130. Examples of the installation images 131 include binary information for executing installation processing, container images for installation defined by CNAB (Cloud Native Application Bundles, https://cnab.io/), some or all of the package source codes 111, information obtained by archiving (compressing) some or all of the package source codes 111 by using, for example, tar, and binary data obtained by compiling the package source codes 111. Similarly, examples of the application images 132 include binary data for executing the application instances 141, virtual server images, and container images. Incidentally, the package management information 133 will be described later with reference to FIG. 7." [0051] "The package source code 111 includes, for example, a bin directory 201 which stores tools for executing actual deployment processing on the execution environment 140, a chart directory 202 which is a prototype file group for creating a Config 142, a Dockerfile 203 for creating the installation image 131, data for creating the package management information 133, a bundle.json 204 which describes metadata, etc., and an apps directory 205 which stores a file group for creating the application image 132." EN: The installation image is an example of a runtime artifact and it includes ‘some or all of the package source codes’ which are design time artifacts).
bundling, in the build-time environment, the plurality of design-time artifacts into a versioned design-time archive ([0042] "Examples of the installation images 131 include binary information for executing installation processing, container images for installation defined by CNAB (Cloud Native Application Bundles, https://cnab.io/), some or all of the package source codes 111, information obtained by archiving (compressing) some or all of the package source codes 111 by using, for example, tar, and binary data obtained by compiling the package source codes 111. Similarly, examples of the application images 132 include binary data for executing the application instances 141, virtual server images, and container images. Incidentally, the package management information 133 will be described later with reference to FIG. 7." [0086-0091] "The package management information 133 retains information of: a package ID 701 which has the same meaning as that of the package ID 602 included in the CI management information 521; and an installer ID 702 which has the same meaning as that of the installer ID 603. … Incidentally, there may be a plurality of installer ID's 702 for one package ID 701; and if there is the execution order of the corresponding installation images 131, information of the execution order may be included. Furthermore, if there is a parameter to be designated as a standard upon installation as the marketplace system 130 (for example, a URL or the like of the registry 134 in which an application image 132 to be used as a standard is stored), that value may be retained in the package management information 133. … Incidentally, there may be a plurality of installer ID's 702 for one package ID 701; and if there is the execution order of the corresponding installation images 131, information of the execution order may be included. Furthermore, if there is a parameter to be designated as a standard upon installation as the marketplace system 130 (for example, a URL or the like of the registry 134 in which an application image 132 to be used as a standard is stored), that value may be retained in the package management information 133." EN: The design artifacts are bundled/archived/compressed and included in the installation image).
generating, in the build-time environment, the runtime artifact from the plurality of run-time modules and the versioned design-time archive ([0041-0042] and [0052] "The CI system 120 executes the building processing by using the package source code 111. More specifically, upon creation of the installation image 131, a container image including a helm command 206, which is a tool for executing the actual deployment processing on the execution environment 140, a chart directory 202, and so on is created. In this case, the actual deployment processing is performed by executing the helm command 206 along with the chart directory 202 via the execution of the container image. The chart directory 202 includes, for example, a prototype file group (whose one example is a deploy.yaml 207) and a variable file (whose one example is a values.yaml 208) for designating a variable to be assigned to the prototype file group and a default value of the variable. The deploy.yaml 207 and the values.yaml 208 will be described later with reference to FIG. 4. Furthermore, the application image 132 is also created in the same manner by using, for example, information of the apps directory 205" Also see [0198-0204] and [0051-0052] "The package source code 111 includes, for example, a bin directory 201 which stores tools for executing actual deployment processing on the execution environment 140, a chart directory 202 which is a prototype file group for creating a Config 142, a Dockerfile 203 for creating the installation image 131, data for creating the package management information 133, a bundle.json 204 which describes metadata, etc., and an apps directory 205 which stores a file group for creating the application image 132 … The chart directory 202 includes, for example, a prototype file group (whose one example is a deploy.yaml 207) and a variable file (whose one example is a values.yaml 208) for designating a variable to be assigned to the prototype file group and a default value of the variable. The deploy.yaml 207 and the values.yaml 208 will be described later with reference to FIG. 4. Furthermore, the application image 132 is also created in the same manner by using, for example, information of the apps directory 205." [0074] "The registry 134 stores the installation images 131 and the application images 132. It is described that there is one registry 134 for the sake of convenience; however, if the registry 134 is connected to the package management information 133, there may be a plurality of registries 134. Examples of the registry 134 include: container registries represented by, for example, DockerRegistry if each one of the installation images 131 and the application images 132 is a container image; and various types of registries having a function that distribute binary data if each one of the installation images 131 and the application images 132 is the binary data. Furthermore, in a case where a plurality of different kinds of images (for example, the binary data and the containers) coexist, the registry 134 may be composed of a plurality of different kinds of registries 134. Moreover, the registry 134 may be, for example, a storage apparatus(es) such as an object storage apparatus(es) which can be used via a network" EN: The application image 132 is generated based on the runtime modules/artifacts generated in the build process).
storing the runtime artifact in an artifact storage of the build-time environment ([0044] "The installation images 131, the application images 132, and the package management information 133 which are created by the building processing are registered in a storage apparatus (such as a registry 134) of the marketplace system 130. The registry 134 is described as being included in the marketplace system 130 for the sake of convenience; however, the registry 134 may be provided outside the marketplace system 130. Furthermore, the marketplace system 130 displays a portal user interface 135 on a display device to the user 102 of the marketplace system 130 by using the package management information 133 and so on. An example of the portal user interface 135 will be described later with reference to FIG. 3" [0212] "Moreover, the information such as the programs, tables, and files for implementing each function in the above-descried explanation may be retained in storage apparatuses such as memories, hard disks, and SSDs (Solid State Drive) or storage media such as IC cards, SD cards, and DVDs" [0074] "The registry 134 stores the installation images 131 and the application images 132. It is described that there is one registry 134 for the sake of convenience; however, if the registry 134 is connected to the package management information 133, there may be a plurality of registries 134. Examples of the registry 134 include: container registries represented by, for example, DockerRegistry if each one of the installation images 131 and the application images 132 is a container image; and various types of registries having a function that distribute binary data if each one of the installation images 131 and the application images 132 is the binary data. Furthermore, in a case where a plurality of different kinds of images (for example, the binary data and the containers) coexist, the registry 134 may be composed of a plurality of different kinds of registries 134. Moreover, the registry 134 may be, for example, a storage apparatus(es) such as an object storage apparatus(es) which can be used via a network").
Regarding claim 2, Naganuma teaches wherein bundling includes compressing the plurality of design-time artifacts into the versioned design-time archive ([0042] "Examples of the installation images 131 include binary information for executing installation processing, container images for installation defined by CNAB (Cloud Native Application Bundles, https://cnab.io/), some or all of the package source codes 111, information obtained by archiving (compressing) some or all of the package source codes 111 by using, for example, tar, and binary data obtained by compiling the package source codes 111. Similarly, examples of the application images 132 include binary data for executing the application instances 141, virtual server images, and container images. Incidentally, the package management information 133 will be described later with reference to FIG. 7." [0083] " The package ID 602 is a common identifier with the package management information 133 and an identifier for uniquely identifying the relevant package. The package ID 602 may be designed in such a manner that the package ID 602 may be issued by the CI system 120, or it may be issued by the marketplace system 130, or the issuance of the package ID 602 may be designated by the provider 101." and [0086-0088]).
Regarding claim 5, Naganuma teaches receiving, in a runtime environment, a request to deploy the runtime artifact ([0113] "The deployment unit 533 waits in an instruction waiting state and receives the package ID and the input values (the values changed from the default values) selected by the user 102 on the portal user interface 135, and other information necessary for the deployment processing (the deployment destination, that is, the platform 805, and the credential 806), and so on from the portal information output unit 532 (step S1201). Incidentally, it may be designed in such a manner that the portal information output unit 532 updates (adds), for example, the input values to the instance management information 531 and the deployment unit 533 receives the instance ID of the current target and then refers to information necessary information for the deployment processing from the instance management information 531").
retrieving, in the runtime environment, the runtime artifact from the artifact storage in the build-time environment ( [0114] "Subsequently, the deployment unit 533 refers to the package management information 133, identifies the installer ID 702 corresponding to the selected package, and acquires the corresponding installation image 131 from the registry 134 by using the identified installer ID 702 (step S1202). For example, in a case of a container type, this processing corresponds to pull processing of the container image as an example of the acquisition of the installation image 131").
storing, in the runtime environment, the runtime artifact in runtime storage ([0072] "Incidentally, the functions of the marketplace system 130 (such as the portal information output unit 532 and the deployment unit 533) may be implemented by, for example, the CPU reading programs onto the memory and executing the programs (software), or may be implemented by hardware such as private circuits, or may be implemented by a combination of the software and the hardware" [0044] "The installation images 131, the application images 132, and the package management information 133 which are created by the building processing are registered in a storage apparatus (such as a registry 134) of the marketplace system 130" and [0045] "The user 102 selects a package which the user 102 wants to use this time, by using the portal user interface 135. When the user 102 selects the package, the marketplace system 130 executes deployment processing on the execution environment 140 by using the installation image 131 of the selected package. The execution environment 140 is an environment to operate packages. The execution environment 140 is, for example, a cluster of IT resources managed by public cloud services, private cloud services, and orchestration tools such as OpenStack and Kubernetes. Furthermore, the execution environment 140 to operate the package selected by the user 102 may be in a format designated by the user 102 or may be in a format automatically selected by the marketplace system 130").
deploying, in the run-time environment, the runtime artifact ([0115] "Subsequently, the deployment unit 533 executes the deployment processing on the installation image 131 acquired in step S1202 with the input values acquired in step S1201 (step S1203). For example, in the case of the installation image 131 of the container type, the deployment unit 533 sets the input values as environmental variables and then executes run processing. Moreover, if the processing varies depending on the execution environment 140 which is the deployment destination, branching processing associated with the deployment destination may be a method of selecting it within the installation image 131 or a method of selecting the installation image 131 according to the deployment destination when each of the installation images 131 is divided for each deployment destination" and [0046] "As a result of the deployment processing by the marketplace system 130, a system corresponding to the relevant package which is composed of the application instance 141 which is an execution state of the application image 132, a Config 142 which is a configuration file that defines the operation of the application instance 141, and so on (hereinafter referred to as an instance 143) is constructed in the execution environment 140. Under this circumstance, there may be one or more application instances 141 according to descriptions of the Config 142.").
Regarding claim 10, Naganuma teaches A system comprising: one or more processors; a non-transitory computer-readable medium storing a program executable by the one or more processors, the program comprising sets of instructions for ([0066] “The respective constituent elements operate (or function) on a computer equipped with a CPU (Central Processing Unit), a memory, hard disks, and so on. The respective constituent elements may operate on physically different computers or a physical computer called a virtual server may be operated in units of logically divided computers. Furthermore, each constituent element may operate in units of tasks (which may be also called processes or containers) executed on one computer or a cluster of a plurality of computers”).
Claims 11 and 14 are system claims reciting limitations similar to claims 2 and 5 respectively and are rejected under the same rationale.
Regarding claim 19, Naganuma teaches a non-transitory computer-readable medium storing a program executable by one or more processors, the program comprising sets of instructions for ([0066] “The respective constituent elements operate (or function) on a computer equipped with a CPU (Central Processing Unit), a memory, hard disks, and so on. The respective constituent elements may operate on physically different computers or a physical computer called a virtual server may be operated in units of logically divided computers. Furthermore, each constituent element may operate in units of tasks (which may be also called processes or containers) executed on one computer or a cluster of a plurality of computers”).
Claim 20 is a medium claim reciting limitations similar to claim 2 and is rejected under the same rationale.
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 3-4 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Naganuma et al. (US20210064351A1) in view of Tao et al. (CN113326481A)
Regarding claim 3, Naganuma teaches the method as in claim 1. Tao teaches wherein bundling includes obfuscating personal information from the plurality of design-time artifacts before storage in the versioned design-time archive ([n0025-n0026] "In the specific embodiment shown in Figure 1, the automatic project code building and packaging method disclosed in this application includes the following steps: Step S101, during the project code building process, selecting the content to be packaged, whether to perform Maven compilation and building, and whether to encrypt according to the packaging requirements; Step S102, if Maven compilation and building is selected, the currently configured Maven build tool is called to perform compilation and building on the content to be packaged to obtain the current content package; Step S103, if encryption is selected, the obfuscation and encryption component is called to obfuscate and encrypt all or part of the current content package to obtain the current encrypted content package; and Step S104, the aggregation plugin is called to aggregate the current encrypted content package or the current content package according to the current project's build directory structure to obtain the current packaged file; wherein, the currently configured Maven build tool is a Maven build tool with additional configuration items and settings added according to the current project's build directory structure and the obfuscation and encryption component's obfuscation and encryption requirements." Also see [n0035-n0040] and [n0061-n0063]).
Naganuma and Tao are analogous art because they are from the same field of endeavor in software code packaging and deployment. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Naganuma and Tao to incorporate Tao’s expanded encryption and obfuscation functionality to protect existing code. “It increases source code security and establishes standards for the company's operations, from development to maintenance.” (Tao, [n0003]).
Regarding claim 4, Naganuma teaches the method as in claim 1. Tao teaches wherein bundling includes encrypting the plurality of design-time artifacts before storage in the versioned design-time archive ([n0025-n0026] "In the specific embodiment shown in Figure 1, the automatic project code building and packaging method disclosed in this application includes the following steps: Step S101, during the project code building process, selecting the content to be packaged, whether to perform Maven compilation and building, and whether to encrypt according to the packaging requirements; Step S102, if Maven compilation and building is selected, the currently configured Maven build tool is called to perform compilation and building on the content to be packaged to obtain the current content package; Step S103, if encryption is selected, the obfuscation and encryption component is called to obfuscate and encrypt all or part of the current content package to obtain the current encrypted content package; and Step S104, the aggregation plugin is called to aggregate the current encrypted content package or the current content package according to the current project's build directory structure to obtain the current packaged file; wherein, the currently configured Maven build tool is a Maven build tool with additional configuration items and settings added according to the current project's build directory structure and the obfuscation and encryption component's obfuscation and encryption requirements." Also see [n0035-n0040], [n0046-n0047], [0005-0007] and [n0061-n0063]).
For motivation to combine please see claim 3.
Claims 12-13 are system claims reciting limitations similar to claims 3-4 respectively and are rejected under the same rationale.
Claims 6-9 and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Naganuma et al. (US20210064351A1) in view of Satheesh et al. (US20220300268A1)
Regarding claim 6, Naganuma teaches the method as in claim 5. Satheesh teaches further comprising: receiving, in the runtime environment, a request to access the design-time artifacts ([0004] "determining, by the data processing system, the performance of the compute is superior to the performance of the production compute based on the analyzing of the performances; and in response to determining the performance of the compute is superior to the performance of the production compute, replacing, by the data processing system, the production compute in the production environment with the compute, where the replacing comprises unpacking the deployable archive bundle and deploying the compute in the production environment with dependencies based on the record of the lineage of the logical building blocks in dependency" EN: unpacking the deployable archive makes its contents (design time artifacts) available. This is done in response to a request to ‘replace’ the deployment).
debundling, in the runtime environment, the versioned design-time archive into a plurality of design-time artifacts ([0042-0043] " The promotion and deployment of the new version of a compute 405 or 420 in the production environment 415 comprises unpacking the deployable archive bundle and deploying the compute 405 or 420 in the production environment with dependencies based on the record of the lineage of the logical building blocks in dependency. The deployable archive bundle contains the compute, dependencies that compute may have (e.g., external data file or file with macro variables and their values, data-movement routines that move data from certain columns to another column either as aggregate or split buckets, certain constants computed during the training process including the placeholders for the constants in the model, any transformations of source data that needs to be applied against production data, etc.,). These dependencies are carried as “metadata” or target agnostic definitions that can be converted in production environment to the execution semantics (e.g., SQL or Scala-code or Java or R or Python or anything for which an interpreter is available to convert the meta encoding format to target execution semantics). The meta-info with the deployable archive bundle carries the exact order in which the deployment image is laid out in the target environment and the series of actions to be applied. This meta-info or instruction set is understood by the application ecosystem irrespective of the target environment specifics like OS or middleware or topology" EN: Satheesh discloses unpacking the archive into its original components to create a new deployment).
Naganuma and Satheesh are analogous art because they are from the same field of endeavor in software code packaging and deployment. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Naganuma and Satheesh to incorporate Satheesh debundeling and unpacking of bundled software packages. “replacing, by the data processing system, the production compute in the production environment with the compute, where the replacing comprises unpacking the deployable archive bundle and deploying the compute in the production environment with dependencies based on the record of the lineage of the logical building blocks in dependency.” (Satheesh, [0004]).
Regarding claim 7, Naganuma in view of Satheesh teaches the method as in claim 6. Satheesh further teaches wherein debundling includes restoring the plurality of design-time artifacts from the versioned design-time archives by reversing the operations performed from the bundling ([0030-0031] "When a new version of the compound compute object is approved through quantitative and/or qualitative assessment in accordance with one or more governance processes, (i) a deployable archive bundle is generated of the compute with its dependencies, and (ii) the production environment automatically picks up the deployable archive bundle post any in-progress operation completion and deploys the compute with its dependencies. The deployable archive bundle is essentially a self-documenting object-model that implicitly carries a dependency footprint for the various objects. … Advantageously, these techniques cuts the process overload that riddles such compute systems, provides self-documenting compute objects … in response to determining the performance of the compute is superior to the performance of the production compute, replacing, by the data processing system, the production compute in the production environment with the compute, where the replacing comprises unpacking the deployable archive bundle and deploying the compute in the production environment with dependencies based on the record of the lineage of the logical building blocks in dependency. " and [0042-0043] "The promotion and deployment of the new version of a compute 405 or 420 in the production environment 415 comprises unpacking the deployable archive bundle and deploying the compute 405 or 420 in the production environment with dependencies based on the record of the lineage of the logical building blocks in dependency. The deployable archive bundle contains the compute, dependencies that compute may have (e.g., external data file or file with macro variables and their values, data-movement routines that move data from certain columns to another column either as aggregate or split buckets, certain constants computed during the training process including the placeholders for the constants in the model, any transformations of source data that needs to be applied against production data, etc.,). These dependencies are carried as “metadata” or target agnostic definitions that can be converted in production environment to the execution semantics (e.g., SQL or Scala-code or Java or R or Python or anything for which an interpreter is available to convert the meta encoding format to target execution semantics). The meta-info with the deployable archive bundle carries the exact order in which the deployment image is laid out in the target environment and the series of actions to be applied. This meta-info or instruction set is understood by the application ecosystem irrespective of the target environment specifics like OS or middleware or topology" EN: Satheesh in [0031] discloses unbundling the run time archive to its original components to construct a new deployment.).
Regarding claim 8, Naganuma in view of Satheesh teaches the method as in claim 6. Naganuma further teaches further comprising: launching, in the runtime environment, a browser application to view the plurality of design-time artifacts ([0044-0045] "Furthermore, the marketplace system 130 displays a portal user interface 135 on a display device to the user 102 of the marketplace system 130 by using the package management information 133 and so on. An example of the portal user interface 135 will be described later with reference to FIG. 3. The user 102 selects a package which the user 102 wants to use this time, by using the portal user interface 135. When the user 102 selects the package, the marketplace system 130 executes deployment processing on the execution environment 140 by using the installation image 131 of the selected package. The execution environment 140 is an environment to operate packages" [0055-0056] "The portal user interface 135 shows a screen used by the user 102 to select a package on which the deployment processing is to be executed. Besides this, the portal user interface 135 may include, for example, information of the instance 143 constructed by the deployment processing and a screen for managing the information. When selecting a package on the portal user interface 135, the portal user interface 135 includes, for example, a pane 310 which displays keywords for filtering packages, a pane 320 which displays a list of packages, and a pane 330 for displaying information 331 of the selected package and a deploy button 332 for executing the deployment processing. A package display 321 indicating one package displays an identifier of the package, a name of the package, a version of the package, and so on. Furthermore, the portal user interface 135 may be equipped with a function that displays detailed information on another screen, for example, information such as a further detailed explanation, how to use it, cautions to take when using it, and contact information, by pressing the package display 321" [0068] “The repository 110 stores one or more package source codes 111. If the repository 110 has enough information to add the installation images 131, the application images 132, and the package management information 133 to the marketplace system 130, it may be composed of a plurality of repositories 110. “ and [0038] “A provider 101 who registers a package(s) in the marketplace system 130 registers a package source code 111, on which the package to be registered in the marketplace system 130 is based, in a designated repository 110. Examples of the repository 110 include GitHub (https://github.com/) as a cloud service and GitLab as OSS. An example of the package source code 111 will be explained later with reference to FIG. 2.” EN: As per [0068] the repository 111 adds the design time artifacts and their information to the marketplace which is viewed in detail by the supplied UI. Additionally, GitHub is a web based repository for viewing the design time artifacts).
Regarding claim 9, Naganuma in view of Satheesh teaches the method as in claim 6. Naganuma further teaches the design-time environment has previously been deleted and the plurality of design-time artifacts are used in reconstructing the design-time environment (Please see [0151-0156] Specifically, "On the other hand, when the application image 132 cannot be acquired directly, the imaging unit 544 copies data in the application instance 141 (full backup) as alternative processing (step S1403). For example, in a case of kubernetes, the imaging unit 544 can draw out all the data in the application instance 141, on which the processing is being executed, by using a “kubectl cp {source_path}{target_path}” (elements inside { } are variables) command on the target application instance 141. Moreover, a tool or the like for performing such a backup may be made to operate in the application instance 141 in the execution environment 140 and be used. … The imaging unit 544 can reproduce the application image 132, which is changed by the user 102, by copying the data, then executing the application image 132 which served as the base (that is, the original) as the application instance 141 (at the location where the imaging unit 544 operates), overwriting the application instance 141 with the copied data, and performing imaging of that application instance 141" EN: Naganuma discloses ‘recreating’ the design time environment when it’s not available (deleted) or overwritten [0153]. Recreating the design time environment is accomplished by using the kubectl command as explained above or through a backup/the imaging unit 544 [0151 and 0153], which re-produces all the source code. As per the instant application’s spec [0020] re-constructing the design time environment is re-constructing the source code and its dependencies etc.).
Claims 15-18 are system claims reciting limitations similar to claims 6-9 respectively and are rejected under the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Github (Javascript Obfuscator): discloses a library for encrypting and obfuscating code for security purposes.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR DARWISH whose telephone number is (571)272-4779. The examiner can normally be reached 7:30-5:30 M-Thurs.
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, Emerson Puente can be reached on 571-272-3652. 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.
/A.E.D./Examiner, Art Unit 2187
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199