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 .
This Office Action is in response to Applicant’s Amendment and Remarks filed on 10 June 2026.
Claims 1-20 are pending in this application.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-3, 11-13 and 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1, Statutory Category: Yes, the claim 1 is a method for upgrading a virtual storage system, applied to a serverless platform that recites a series of steps and therefore falls in the statutory category of a process.
Step 2A- Prong 1: Judicial Exception Recited: Yes, the claim recites: “determining an upgrading type corresponding to the upgrading instruction and a preset execution file matched with the upgrading type based on a mapping relationship between a plurality of upgrading types and a plurality of preset execution files pre-deployed in the serverless platform as functions as a service,” As drafted, the claim as a whole recites a method including steps that could be performed in the human mind, but for the recitation of generic computing components. The human mind can easily judging/evaluating/determining an upgrading type corresponding to the upgrading instruction and a preset execution file matched with the upgrading type based on the mapping relationship between a plurality of upgrading types and a plurality of preset execution files pre-deployed. Therefore, but for the recitation of generic computing components, these steps may be a Mental Processes that can be performed in the human mind (including an observation, evaluation, judgment, opinion).
Therefore, yes, the claims do recite judicial exceptions.
Step 2A- Prong 2: Integrated into a practical Application: No, this judicial exception is not integrated into a practical application. In particular, the claim recites an additional limitations that “receiving an upgrading instruction for the virtual storage system” which is insignificant pre-solution data gathering (see MPEP § 2106.05(g)). In addition, “a method for upgrading a virtual storage system, applied to a serverless platform” is an attempt to generally link the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))). Moreover, the limitation of “wherein different upgrading types correspond to different working processes for upgrading the virtual storage system” and “wherein, in response to the preset execution file being invoked, the serverless platform allocates system resources and starts a host environment to run the preset execution file” which is directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a generic computer as a tool to perform an abstract idea (see MPEP 2106.05(f)). Further, the limitation of “upgrading the virtual storage system by running the preset execution file in the serverless platform” which is merely applying the judicial exception or abstract idea (See MPEP 2106.05(f)). The claim does not define any particular machine to “upgrading”, and no details what so ever on how the claimed function will occur. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because they not impose any meaningful limits on practicing the abstract idea. Therefore, the claim is directed to the abstract idea.
Step 2B: Claim provides an Inventive Concept: No. The additional element “a method for upgrading a virtual storage system, applied to a serverless platform” is an attempt to generally link the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))). In addition, the limitation of “wherein different upgrading types correspond to different working processes for upgrading the virtual storage system” and “wherein, in response to the preset execution file being invoked, the serverless platform allocates system resources and starts a host environment to run the preset execution file” which is directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a generic computer as a tool to perform an abstract idea (see MPEP 2106.05(f)). Moreover, the limitation of “upgrading the virtual storage system by running the preset execution file in the serverless platform” which is merely applying the judicial exception or abstract idea (See MPEP 2106.05(f)). The claim does not define any particular machine to “upgrading”, and no details what so ever on how the claimed function will occur. Further, “receiving an upgrading instruction for the virtual storage system” which is insignificant pre-solution data gathering (see MPEP § 2106.05(g)) which are well understood, routine, conventional activity (see MPEP § 2106.05(d)). Courts have identified “receiving and transmitting data, storing and retrieving information”, et cetera as well understood, routine, conventional and mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f))). These additional elements and combination of the elements does not amount to significant more than the exception itself or provide an inventive concept in Step 2B.
Under the 2019 PEG, a conclusion that an additional element is insignificant extra-solution activity in Step 2A should be re-evaluated in Step 2B. Here, the “receiving” step was considered to be extra-solution activity in Step 2A as insignificant data gathering and communication and are well understood, routine, conventional activity in the field. The “receiving” step was for the purpose of “communication” and “transmitting the data” and these can be reached on one of court case (Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) see MPEP § 2106.05(d) II). Accordingly, a conclusion that “receiving” is well understood, routine, conventional activity is supported under Berkheimer options 2.
For these reasons, there is no inventive concept in the claim, and thus the claim is ineligible.
Independent claims 11 and 20 are rejected for the same reason as claim 1 above. Claim 11 further recites “An electronic device, comprising: at least one processor; and a memory coupled to the at least one processor and having an instruction stored thereon, wherein the instruction, when executed by the at least one processor, causes the electronic device to perform actions,”. Claim 20 further recites “A computer program product, the computer program product being tangibly stored on a non-transitory computer-readable medium and comprising a machine-executable instruction, wherein the machine-executable instruction, when executed, causes a machine to perform actions”. These additional elements are directed to generic computing components/functions merely applying the abstract idea (MPEP § 2106.05(f)).
With respect to the dependent claim 2, the claim elaborates that wherein the upgrading type comprises a first upgrading type, the first upgrading type is to add a memory, the preset execution file is a first preset execution file, and upgrading the virtual storage system comprises: sending a storage resource request to a cloud computing platform by using the first preset execution file; receiving storage resources allocated by the cloud computing platform for the storage resource request by using the first preset execution file; configuring a new memory based on the storage resources by using the first preset execution file; and adding the new memory to the virtual storage system by using the first preset execution file. (“sending” , ”receiving” which is insignificant pre-solution data gathering (see MPEP § 2106.05(g)) which are well understood, routine, conventional activity (see MPEP § 2106.05(d)). Courts have identified “receiving and transmitting data, storing and retrieving information”, et cetera as well understood, routine, conventional and mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f))). In addition, “configuring a new memory” are directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)). Further, “adding the new memory” are being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind (i.e., scheduling/assigning/adding the new memory)).
With respect to the dependent claim 3, the claim elaborates that wherein the storage resource request comprises a size of the storage resources, and the size of the storage resources is determined according to a use state and configuration information of the virtual storage system (these limitations are directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)).
Dependent claims 12-13 recite the same features as applied to claims 2-3 respectively above, therefore they are also 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 1, 11 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mesika et al. (US Pub. 2014/0337282 A1) in view of Khangaonkar et al. (US Pub. 2009/0063563 A1) and further in view of Murthy et al. (US Pub. 2013/0173804 A1) and SCHULTZ et al. (US Pub. 2022/0035714 A1).
Mesika and SCHULTZ were cited in the previous Office Action.
As per claim 1, Mesika teaches the invention substantially as claimed including A method for upgrading a virtual system, applied to a platform and comprising (Mesika, Fig. 1, 100 platform; Abstract, lines 1-4, A virtualization manager receives a request to install a new feature in a first virtualization environment):
receiving an upgrading instruction for the virtual system (Mesika, [0028] lines 1-4, request interface module 202 receives a request to install a new feature in the virtualization environment; Fig. 5, 510; [0044] lines 1-6, at block 510, method 500 receives a request to install or upgrade to a new feature for an application. In one embodiment, request interface module 202 receives the request, which may specify the new feature to install or a currently installed application to upgrade to a new version);
determining a preset execution file matched with the upgrading type based on a mapping relationship between a plurality of upgrading types and a plurality of preset execution files pre-deployed in the platform, wherein different upgrading types correspond to different working processes for upgrading the virtual system (Mesika, Fig. 5, 520 identifying database upgrade scripts corresponding to new feature; [0030] lines 1-7, virtualization manager 114 is designed to run the database upgrades scripts 108 on management database 109 based on the order of the identification numbers. For example, when request interface module 202 receives a request to install a feature, request interface module 202 may instruct script management module 204 to locate and run the associated database upgrade scripts 108; [0032] if there are two features to be installed, F1 and F2 where F1 has a script numbered 0010 and F2 has scripts numbered 0020 and 0030; [0040] The upgrade scripts may be run on management database 109 in order to update the database to reflect the changes that accompany the new feature; [0042] Feature 1 may be installed first, followed by Feature 3 and then Feature 2. In this embodiment, the upgrade scripts are run in an order that differs from the numerical order of the script identification numbers; [0044] receives the request, which may specify the new feature to install; [0045] lines 1-13, method 500 identifies database upgrade scripts corresponding to the new feature; In one embodiment, the request to install the feature may include the corresponding upgrade scripts. In another embodiment, script management module 204 may read database scripts 108 on data store 105 and determine which scripts are associated with the feature (as preset execution file being pre-deployed in the platform). The upgrade scripts may be identified by a name including a version and/or script identification number; [0049] Running the script may upgrade the entries 111 in the database 109, such as by adding, removing or changing data, etc., or may upgrade the schema of the database 10 (as different upgrading types correspond to different working processes for upgrading the virtual system)); and
upgrading the virtual system by running the preset execution file in the platform (Mesika, Fig. 5, 560 Run upgrade script; [0049] lines 1-8, If at block 550, method 500 determines that the script has not yet been run, at block 560, method 500 runs the script on the management database. Running the script may upgrade the entries 111 in the database 109, such as by adding, removing or changing data, etc., or may upgrade the schema of the database 109).
Mesika fails to specifically teach determining an upgrading type corresponding to the upgrading instruction and a preset execution file matched with the upgrading type based on a mapping relationship between a plurality of upgrading types and a plurality of preset execution files, and wherein, in response to the preset execution file being invoked, the serverless platform allocates system resources and starts a host environment to run the preset execution file.
However, Khangaonkar teaches determining an upgrading type corresponding to the upgrading instruction and a preset execution file matched with the upgrading type based on a mapping relationship between a plurality of upgrading types and a plurality of preset execution files and wherein, in response to the preset execution file being invoked, the platform run the preset execution file (Khangaonkar, Abstract, Configuration interfaces are maintained for a plurality of different database types, wherein each configuration interface implements a database configuration operation with respect to a database of one database type. A configuration request is received from an application indicating a database type, database name, and a database configuration operation. A determination is made of one of the configuration interfaces for the requested database type to implement the requested configuration operation with respect to the database having the database name. The determined configuration interface is invoked with the requested database name to perform the requested configuration operation with respect to the database name; [0007] Configuration interfaces are maintained for a plurality of different database types, wherein each configuration interface implements a database configuration operation with respect to a database of one database type; Fig. 2; Fig. 3. 70 configuration mapping; Fig. 8, 160 receive version upgrade configuration request, 162 determine the version upgrade configuration; 164 invoke the determined version upgrade confirmation interface to update the database element; also see [0018] The database configuration server 6 maintains a configuration request mapping 12 that is used to map a generic configuration request from an application component 4 to perform a specific database configuration. The database configuration server 6 further includes a configuration program 14 that processes the configuration request mapping 12 to determine a configuration interface 8 to use to perform an application component 4 requested configuration operation. A database configuration operation may comprise an operation to create a database 10, create or delete a table in a database 10 of a specified database type, validate the presence and operability of a database element, such as a password used to access a database 10, database table or object, a driver used to access the database, etc., and an upgrade of a version of a database element, such as a table, in the database 10 to a higher version of the database 10. In this way, the common database configuration framework implemented by the database configuration server 6 abstracts the database configuration operations for the applications 2 so that applications need only provide a generic database configuration request not specific to a particular database type, and the common database configuration framework will implement that generic database configuration request for the specified database and database type. Thus, each configuration interface 8 provides an implementation of a generic configuration request specific to a particular database type, including commands and application program interfaces (API), scripts, etc., specific to that database type (the different database specific version-upgrade operations/processes as different upgrading types which is determined based on the mapping)).
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 the teaching of Mesika with Khangaonkar because Khangaonkar’s teaching of determining the database specific upgrading interface for that database type (as upgrading type) based on the mapping between the request and configuration interface would have provided Mesika’s system with the advantage and capability to allow the system to easily determining and identifying the correct upgrading types based on the mapping in order to improving the system performance and efficiency.
Mesika and Khangaonkar fail to specifically teach the serverless platform allocates system resources and starts a host environment to run the preset execution file.
However, Murthy teaches the platform allocates system resources and starts a host environment to run the preset execution file (Murthy, [0031] FIGS. 6 and 7 illustrate a method of providing effective resource reusability management in a virtualized environment similar to virtualized environment 100, starting at block 502. A first workload is defined in block 504. For example, a user of virtualized environment 100 can submit a demand for resources to perform a processing task to virtual system manager 152 that can be managed by system viewer/director 154, VM/workload creator 156, and infrastructure manager 158 to allocate resources of the virtualized environment, to launch a virtual machine on one of host processing systems 110 or 120, and to initiate one of workloads 112, 114, 122, or 124 on the associated virtual machine).
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 the teaching of Mesika and Khangaonkar with Murthy because Murthy’s teaching of before initiating process, the system allocate the resource and starting the environment for initiating the process would have provided Mesika and Khangaonkar’s system with the advantage and capability to allow the system to establishing the execution environment in order to execute subsequent instructions for improving the system resource utilization and performance.
Mesika, Khangaonkar and Murthy fail to specifically teach the virtual system is a virtual storage system, and upgrading is applied to a serverless platform as functions as a service.
However, SCHULTZ teaches the virtual system is a virtual storage system, and upgrading is applied to a serverless platform a serverless platform as functions as a service (SCHULTZ, [0402] lines 1-6, modifications to the virtual storage system 1902 may include, responsive to an increase in demand for compute and/or storage performance, upgrading storage classes for existing storage or commissioning new higher storage classes; [0235] initiating updates or upgrades on one or more storage systems; [0197] lines 1-8, The storage systems described above may also, either alone or in combination with other computing environments, be used to support a wide variety of digital platforms. Such digital platforms can include, for example, 5G wireless systems and platforms, digital twin platforms, edge computing platforms, IoT platforms, quantum computing platforms, serverless PaaS (as serverless platform)).
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 the teaching of Mesika, Khangaonkar and Murthy with SCHULTZ because SCHULTZ’s teaching of upgrading the virtual storage system at serverless platform would have provided Mesika, Khangaonkar and Murthy’s system with the advantage and capability to allow the system to upgrading the virtual storage system based on the demand for compute and storage performance in order to improving the resource utilization and system performance (see SCHULTZ, [0402] “responsive to a decrease in demand for compute and/or storage performance”).
As per claim 11, it is an electronic device claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above. In addition, Mesika further teaches at least one processor; and a memory coupled to the at least one processor and having an instruction stored thereon, wherein the instruction, when executed by the at least one processor (Mesika, Claim 8, A system comprising: a processing device; a memory coupled to the processing device; and a virtualization manager, executable by the processing device from the memory).
As per claim 20, it is a computer program product claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above.
Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Mesika, Khangaonkar, Murthy and SCHULTZ, as applied to claims 1 and 11 respectively above, and further in view of TURLIK et al. (US Pub. 2023/0297527 A1).
TURLIK was cited in the previous Office Action.
As per claim 2, Mesika, Khangaonkar, Murthy and SCHULTZ teach the invention according to claim 1 above. Mesika teaches wherein the upgrading type comprises a first upgrading type, the preset execution file is a first preset execution file, and upgrading the virtual system (Mesika, Fig. 4, different features corresponding to different scripts (as including first preset execution file); [0014] when a new feature is to be added to a virtualization manager development environment, a script management module can identify any database upgrade scripts that are associated with the new feature. In one embodiment, a single feature may have more than one database upgrade script 108 associated with it. In this case, each database upgrade script may be run on a management database in order to fully complete the upgrade. In one embodiment, each database upgrade script may have a naming convention that includes an identification number to uniquely identify the script. For example, the name of each database upgrade script may include an eight digit number where the first four digits represent a version number of the feature (e.g., 0301 for version 3.1); [0030] lines 2-6, designed to run the database upgrades scripts 108 on management database 109 based on the order of the identification numbers. For example, when request interface module 202 receives a request to install a feature, request interface module 202 may instruct script management module 204 to locate and run the associated database upgrade scripts 108). In addition, SCHULTZ teaches the virtual system is a virtual storage system, (SCHULTZ, [0402] lines 1-6, modifications to the virtual storage system 1902 may include, responsive to an increase in demand for compute and/or storage performance, upgrading storage classes for existing storage or commissioning new higher storage classes; [0235] initiating updates or upgrades on one or more storage systems).
Mesika, Khangaonkar, Murthy and SCHULTZ fail to specifically teach the first upgrading type is to add a memory; sending a storage resource request to a cloud computing platform by using the first preset execution file; receiving storage resources allocated by the cloud computing platform for the storage resource request by using the first preset execution file; configuring a new memory based on the storage resources by using the first preset execution file; and adding the new memory to the virtual storage system by using the first preset execution file.
However, TURLIK teaches the first upgrading type is to add a memory (TURLIK, [0153] lines 1-9, memory allocations represent the creation of logical memory spaces in on-chip and/or off-chip memories for data used to implement the computation graphs 636, and these memory allocations are specified in the execution file 656. Memory allocations define the type and the number of hardware resources (functional units, storage, or connectivity components). Main memory (e.g., DRAM) is memory outside the reconfigurable processors for which the memory allocations can be made);
sending a storage resource request to a cloud computing platform by using the first preset execution file (TURLIK, Fig. 8, see arrow between runtime processor to the resource pool 678 (as storage resource request); Fig. 9 cloud computing platform; [0153] lines 1-14, Memory allocations represent the creation of logical memory spaces in on-chip and/or off-chip memories for data used to implement the computation graphs 636, and these memory allocations are specified in the execution file 656. Memory allocations define the type and the number of hardware resources (functional units, storage, or connectivity components). Main memory (e.g., DRAM) is memory outside the reconfigurable processors for which the memory allocations can be made; [0164] allocating CGR units to the virtual data flow resources requested in the execution file 656; [0174] lines 1-4, The execution file 656 (as first preset execution file) may specify virtual memory segments 714 for the requested virtual flow resources, including virtual address spaces of the virtual memory segments and sizes of the virtual address spaces; [0178] lines 1-12, The runtime processor 666 partitions the physical hardware resources in the hardware space 870, i.e. the components in the pool of reconfigurable data flow resources, into multiple virtual resources, and provides uniform and coherent access to these virtual resources as being physical in a balanced and unified view. It also manages all interactions among the applications and their respective resources by handling the traffic of application requests for reconfigurable resources, memory, and I/O channels);
receiving storage resources allocated by the cloud computing platform for the storage resource request by using the first preset execution file (TURLIK, [0156] lines 1-15, The compiler 648 allocates the virtual memory units to physical memory units of a reconfigurable processor (e.g., pattern memory units (PMUs) of the reconfigurable processor) and allocates the virtual compute units to physical compute units of the reconfigurable processor (e.g., pattern compute units (PCUs) of the reconfigurable processor), and these allocations are specified in the execution file 656. The compiler 648 places the physical memory units and the physical compute units onto positions in the arrays of CGR units of the pool of reconfigurable data flow resources and routes data and control networks between the placed positions, and these placements and routes are specified in the execution file 656.)
configuring a new memory based on the storage resources by using the first preset execution file (TURLIK, [0158] lines 1-10, A runtime processor 666 (e.g., host processor 180 of FIG. 1 executing runtime processes) receives the execution file 656 from the SDK 642 and uses the execution file 656 for resource allocation, memory mapping, and execution of the configuration files for the applications 602 on the pool of reconfigurable data flow resources 678. The runtime processor 666 may communicate with the SDK 642 over APIs 654 (e.g., Python APIs)); and
adding the new memory to the virtual storage system by using the first preset execution file (TURLIK, [0153] lines 1-14, Memory allocations represent the creation of logical memory spaces in on-chip and/or off-chip memories for data used to implement the computation graphs 636, and these memory allocations are specified in the execution file 656. Memory allocations define the type and the number of hardware resources (functional units, storage, or connectivity components). Main memory (e.g., DRAM) is memory outside the reconfigurable processors for which the memory allocations can be made).
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 the teaching of Mesika, Khangaonkar, Murthy and SCHULTZ with TURLIK because TURLIK’s teaching of using the execution file for performing the memory allocation would have provided Mesika, Khangaonkar, Murthy and SCHULTZ’s system with the advantage and capability to allow the system to easily allocating the amount of memory based on the execution file in order to improving the system allocation speed and resource utilization.
As per claim 12, it is an electronic device claim of claim 2 above. Therefore, it is rejected for the same reason as claim 2 above.
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Mesika, Khangaonkar, Murthy, SCHULTZ and TURLIK, as applied to claims 2 and 12 respectively above, and further in view of Sharma et al. (US Patent. 11,956,144 B1).
As per claim 3, Mesika, Khangaonkar, Murthy, SCHULTZ and TURLIK teach the invention according to claim 2 above. TURLIK further teaches wherein the storage resource request comprises a size of the storage resources (TURLIK, Fig. 8, runtime processor send the storage resource request to pool of reconfigurable data flow resources; [0153] lines 1-15, Memory allocations represent the creation of logical memory spaces in on-chip and/or off-chip memories for data used to implement the computation graphs 636, and these memory allocations are specified in the execution file 656. Memory allocations define the type and the number of hardware resources (functional units, storage, or connectivity components). Main memory (e.g., DRAM) is memory outside the reconfigurable processors for which the memory allocations can be made. Scratchpad memory (e.g., SRAM) is memory inside the reconfigurable processors for which the memory allocations can be made. Other memory types for which the memory allocations can be made for various access patterns and layouts include read-only lookup-tables (LUTs), fixed size queues (e.g., FIFOs), and register files).
Mesika, Khangaonkar, Murthy, SCHULTZ and TURLIK fail to specifically teach the size of the storage resources is determined according to a use state and configuration information of the virtual storage system.
However, Sharma teaches the size of the storage resources is determined according to a use state and configuration information of the virtual storage system (Sharma, Col 6, lines 1-22, improvement over existing solutions to the website traffic routing and load balancing (i) with fewer steps to achieve the solution, thus reducing the amount of computing resources, such as processing resources, storage resources, network resources, and/or the like, that are being used, (ii) providing a more accurate solution to problem (e.g., through the use of multiple layers which may provide more resilient and redundant solutions, which in turn allow for lower likelihoods in error in determining which servers to transmit the website access requests), thus reducing the number of resources required to remedy any errors made due to a less accurate solution, (iii) removing manual input and waste from the implementation of the solution (e.g., by sending and receiving real time performance metrics from the web sites and servers themselves), thus improving speed and efficiency of the process and conserving computing resources, (iv) determining an optimal amount of resources that need to be used to implement the solution (by optimizing the number of layers implemented and each of their functions/configurations), thus reducing network traffic and load on existing computing resources).
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 the teaching of Mesika, Khangaonkar, Murthy, SCHULTZ and TURLIK with Sharma because Sharma’s teaching of determining the optimal size of the resource based on the use state and configuration information would have provided Mesika, Khangaonkar, Murthy, SCHULTZ and TURLIK’s system with the advantage and capability to allow the system to dynamically determining and allocating the optimal amount of resources in order to improving the load balancing and resource utilization.
As per claim 13, it is an electronic device claim of claim 3 above. Therefore, it is rejected for the same reason as claim 3 above.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Mesika, Khangaonkar, Murthy and SCHULTZ, as applied to claims 1 and 11 respectively above, and further in view of Ma et al. (US Pub. 2012/0210312 A1).
As per claim 4, Mesika, Khangaonkar, Murthy and SCHULTZ teach the invention according to claim 1 above. Mesika further teaches wherein the upgrading type comprises a second upgrading type, the preset execution file is a second preset execution file, and upgrading the virtual system comprises (Mesika, Fig. 4, different features corresponding to different scripts (as including second preset execution file); [0014] when a new feature is to be added to a virtualization manager development environment, a script management module can identify any database upgrade scripts that are associated with the new feature. In one embodiment, a single feature may have more than one database upgrade script 108 associated with it. In this case, each database upgrade script may be run on a management database in order to fully complete the upgrade. In one embodiment, each database upgrade script may have a naming convention that includes an identification number to uniquely identify the script. For example, the name of each database upgrade script may include an eight digit number where the first four digits represent a version number of the feature (e.g., 0301 for version 3.1); [0030] lines 2-6, designed to run the database upgrades scripts 108 on management database 109 based on the order of the identification numbers. For example, when request interface module 202 receives a request to install a feature, request interface module 202 may instruct script management module 204 to locate and run the associated database upgrade scripts 108). In addition, SCHULTZ teaches the virtual system is a virtual storage system, (SCHULTZ, [0402] lines 1-6, modifications to the virtual storage system 1902 may include, responsive to an increase in demand for compute and/or storage performance, upgrading storage classes for existing storage or commissioning new higher storage classes; [0235] initiating updates or upgrades on one or more storage systems).
Mesika, Khangaonkar, Murthy and SCHULTZ fail to specifically teach shutting down the virtual storage system by using the second preset execution file; acquiring system resources required for upgrading the virtual storage system by using the second preset execution file; upgrading the virtual storage system based on the system resources by using the second preset execution file; and starting up the virtual storage system by using the second preset execution file.
However, Ma teaches shutting down the virtual storage system by using the second preset execution file (Ma, [0143] lines 1-5, Step 503. the installation engine runs the pre-upgrade executed script preflight under the software upgrade package directory and closes upgrade related process. The upgrade process may relate to updating drive and system configuration file, therefore, these system add-ins have to be terminated, otherwise, even the files are updated in the Mac system, what are running in the system are still old files);
acquiring system resources required for upgrading the virtual storage system by using the second preset execution file (Ma, [0144] lines 1-8, step 504. the installation engine reads the undateInfo.plis file in the software upgrade package, acquires the upgrade resource file list, and creates an update operation list according to the source storage address, destination installation address and operation code of each upgrade resource file recorded in the upgrade resource file list);
upgrading the virtual storage system based on the system resources by using the second preset execution file (Ma [0169] the installation engine first acquires the upgrade resource file list in the software upgrade package, and update the client with the upgrade resource files one by one according to the source storage path, destination installation path and corresponding operators of each upgrade resource file recorded in the upgrade resource file list); and
starting up the virtual storage system by using the second preset execution file (Ma, Fig. 5, [0155] lines 1-3, the installation engine starts the upgrade relevant process and service; [0122] lines 1-4, after the upgrade of the wireless network card client is completed, the installation engine calls the post-upgrade executed script to restart relevant process, load drive, and load PPPMonitor program closed before upgrade; (please notes: virtual storage system was taught by SCHULTZ)).
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 the teaching of Mesika, Khangaonkar, Murthy and SCHULTZ with Ma because Ma’s teaching of shutting down the system before upgrading, and restarting the system after complete the upgrade and reload the process before upgrading would have provided Mesika, Khangaonkar, Murthy and SCHULTZ’s system with the advantage and capability to allow the system to continually processing the workloads after upgrading completing in order to improving the user experience and system performance.
As per claim 14, it is an electronic device claim of claim 4 above. Therefore, it is rejected for the same reason as claim 4 above.
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Mesika, Khangaonkar, Murthy, SCHULTZ and Ma, as applied to claims 4 and 14 respectively above, and further in view of Khosrowpour et al. (US Patent. 10,771,580 B1) and Zhang et al. (US Pub. 2019/0164242 A1).
As per claim 5, Mesika, Khangaonkar, Murthy, SCHULTZ and Ma teach the invention according to claim 4 above. Ma further teaches acquiring the system resources required for upgrading the virtual storage system by using the second preset execution file (Ma, [0144] lines 1-8, step 504. the installation engine reads the undateInfo.plis file in the software upgrade package, acquires the upgrade resource file list, and creates an update operation list according to the source storage address, destination installation address and operation code of each upgrade resource file recorded in the upgrade resource file list).
Mesika, Khangaonkar, Murthy, SCHULTZ and Ma fail to specifically teach wherein the second upgrading type comprises switching a type of the virtual storage system, different types of virtual storage systems have different configuration information and supported system resources, determining a target switching type of the virtual storage system by using the second preset execution file; receiving a license corresponding to the target switching type by using the second preset execution file; and acquiring the system resources required for upgrading the virtual storage system based on the license by using the second preset execution file.
However, Khosrowpour teaches wherein the second upgrading type comprises switching a type of the virtual storage system, different types of virtual storage systems have different configuration information and supported system resources (Khosrowpour, Col 14, lines 39-54, The performance improvement tool 106 may provide recommendations 172 to improve performance of one or more of the apps 110. For example, the recommendations 172 may include “Increasing RAM from 8 GB to 16 GB will provide up to X % improvement in execution times for app 110(N)”, “For app 110(N), switching from a first type of storage device (e.g., mechanical disk drive) to a second type of storage device (e.g., SSD) may provide up to Y % improvement in execution times, and switching to a third type of storage device (e.g., NVME) may provide up to Z % improvement in execution times.” (X, Y, and Z>0). The recommendations 172 may include “Upgrading to the latest Precision workstation with 4.2 GHz 17 processor, 16 GB RAM, and 256 GB NVME memory will yield an improvement of X % for app 110(N)).
determining a target switching type of the virtual storage system by using the second preset execution file (Khosrowpour, Col 6, lines 55-67, The training data for the classifier may be gathered using different types of storage devices with different types of interfaces. For example, different amounts of RAM, different types of storage, and the like may be used to generate the training data. The different types of storage may include mechanical-based disk drivers and solid-state drives (SSD) that use different types of interfaces, such as serial ATA (SATA), Non-Volatile Memory Express (NVMe), or the like. When the classifier is deployed (e.g., after being trained), the classifier may provide recommendations to improve performance, such as, for example, “Increasing RAM from 8 GB to 16 GB will provide up to X % improvement in execution times”, “Switching from a first type of storage device (e.g., mechanical disk drive) to a second type of storage device (e.g., SSD) may provide up to Y % improvement in execution times, and switching to a third type of storage device (e.g., NVME) may provide up to Z % improvement in execution times.” (X, Y, and Z>0) (As determining a target switching type of the virtual storage system by using the second preset execution file (i.e., recommendation, please note: second preset execution file was taught by Mesika, SCHULTZ and Ma)).
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 the teaching of Mesika, Khangaonkar, Murthy, SCHULTZ and Ma with Khosrowpour because Khosrowpour’s teaching of different types of storage system for upgrading for improving performance would have provided Mesika, Khangaonkar, Murthy, SCHULTZ and Ma’s system with the advantage and capability to allow the system to determining the optimized upgrade based on the recommendation/training data in order to improving the resource utilization and system efficiency.
Mesika, Khangaonkar, Murthy, SCHULTZ, Ma and Khosrowpour fail to specifically teach receiving a license corresponding to the target switching type by using the second preset execution file; and acquiring the system resources required for upgrading the virtual storage system based on the license by using the second preset execution file.
However, Zhang teaches receiving a license corresponding to the target switching type by using the second preset execution file; and acquiring the system resources required for upgrading the virtual storage system based on the license by using the second preset execution file (Zhang, Fig. 7a, 701 user submit a resource request, 703 existing license (as receiving license); [0078] lines 1-8, the license controller 113 may make a system call to the license initialization 115 service to load the license file 133 generated in step 803 into the memory device 114 of the licensing management system 101. Once loaded, the license validation 117 of the license controller 113 may, in step 807 evaluate the validity of the license file 807 to ensure that the license was properly obtained and has not expired; [0023] the customer upgrades and downgrades services through point transfers which convert available points into resources that are subsequently delivered to the users by the resource administrators. Using the point-based conversions, customers may not exceed their license without actively upgrading the license to obtain more points to spend on additional resources, thus controlling providing a mechanism for licensees to control resource acquisition expenses (as acquiring the system resources required for upgrading the virtual storage system based on the license by using the second preset execution file; please note upgrading the virtual storage system by using the second preset execution file was taught by Mesika, SCHULTZ, Ma and Khosrowpour); also see Fig. 3, license file (including points for acquiring the resources)).
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 the teaching of Mesika, Khangaonkar, Murthy, SCHULTZ, Ma and Khosrowpour with Zhang because Zhang’s teaching of obtaining license and acquiring the system resources based on the license would have provided Mesika, Khangaonkar, Murthy, SCHULTZ, Ma and Khosrowpour’s system with the advantage and capability to allow the system to ensuring the sufficient resource amount to be acquired for the processing which improving the system performance and efficiency (see Zhang, [0004] “resource request follows a basic policy of the license file and the amount of available point-based currency of the license file is greater than or equal to an amount of point-based currency sufficient for exchanging the computing resources requested by the resource request”).
As per claim 15, it is an electronic device claim of claim 5 above. Therefore, it is rejected for the same reason as claim 5 above.
Claims 6, 9, 16 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Mesika, Khangaonkar, Murthy, SCHULTZ and Ma, as applied to claims 4 and 14 above, and further in view of Khosrowpour et al. (US Patent. 10,771,580 B1).
As per claim 6, Mesika, Khangaonkar, Murthy, SCHULTZ and Ma teach the invention according to claim 4 above. Mesika teaches upgrading the virtual system by using the second preset execution file (Mesika, Fig. 4, different features corresponding to different scripts (as including second preset execution file); [0014] when a new feature is to be added to a virtualization manager development environment, a script management module can identify any database upgrade scripts that are associated with the new feature. In one embodiment, a single feature may have more than one database upgrade script 108 associated with it. In this case, each database upgrade script may be run on a management database in order to fully complete the upgrade. In one embodiment, each database upgrade script may have a naming convention that includes an identification number to uniquely identify the script. For example, the name of each database upgrade script may include an eight digit number where the first four digits represent a version number of the feature (e.g., 0301 for version 3.1); [0030] lines 2-6, designed to run the database upgrades scripts 108 on management database 109 based on the order of the identification numbers. For example, when request interface module 202 receives a request to install a feature, request interface module 202 may instruct script management module 204 to locate and run the associated database upgrade scripts 108). In addition, SCHULTZ teaches the virtual system is a virtual storage system, (SCHULTZ, [0402] lines 1-6, modifications to the virtual storage system 1902 may include, responsive to an increase in demand for compute and/or storage performance, upgrading storage classes for existing storage or commissioning new higher storage classes; [0235] initiating updates or upgrades on one or more storage systems).
In addition, Ma further teaches reconfiguring the virtual storage system by using the second preset execution file (Ma, [0141] the installation engine sends a message to the upgrade engine to indicate that the current upgrade state is a version update state; [0142] step 502. the installation engine resets the total update progress on the basis of the backup progress; [0143] step 503. the installation engine runs the pre-upgrade executed script preflight under the software upgrade package directory and closes upgrade related process. The upgrade process may relate to updating drive and system configuration file, therefore, these system add-ins have to be terminated, otherwise, even the files are updated in the Mac system, what are running in the system are still old files; [0144] step 504. the installation engine reads the undateInfo.plis file in the software upgrade package, acquires the upgrade resource file list, and creates an update operation list according to the source storage address, destination installation address and operation code of each upgrade resource file recorded in the upgrade resource file list).
Mesika, Khangaonkar, Murthy, SCHULTZ and Ma fail to specifically teach wherein the second upgrading type comprises switching a type of the virtual storage system, different types of virtual storage systems have different configuration information and supported system resources, and to switch the type of the virtual storage system.
However, Khosrowpour teaches wherein the second upgrading type comprises switching a type of the virtual storage system, different types of virtual storage systems have different configuration information and supported system resources, and to switch the type of the virtual storage system (Khosrowpour, Col 14, lines 39-54, The performance improvement tool 106 may provide recommendations 172 to improve performance of one or more of the apps 110. For example, the recommendations 172 may include “Increasing RAM from 8 GB to 16 GB will provide up to X % improvement in execution times for app 110(N)”, “For app 110(N), switching from a first type of storage device (e.g., mechanical disk drive) to a second type of storage device (e.g., SSD) may provide up to Y % improvement in execution times, and switching to a third type of storage device (e.g., NVME) may provide up to Z % improvement in execution times.” (X, Y, and Z>0). The recommendations 172 may include “Upgrading to the latest Precision workstation with 4.2 GHz 17 processor, 16 GB RAM, and 256 GB NVME memory will yield an improvement of X % for app 110(N)).
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 the teaching of Mesika, Khangaonkar, Murthy, SCHULTZ and Ma with Khosrowpour because Khosrowpour’s teaching of different types of storage system for upgrading for improving performance would have provided Mesika, Khangaonkar, Murthy, SCHULTZ and Ma’s system with the advantage and capability to allow the system to determining the optimized upgrade based on the recommendation/training data in order to improving the resource utilization and system efficiency.
As per claim 9, Mesika, Khangaonkar, Murthy, SCHULTZ and Ma teach the invention according to claim 4 above. Ma teaches upgrading the virtual storage system by using the second preset execution file comprises: using the second preset execution file (Ma, [0143] lines 1-5, Step 503. the installation engine runs the pre-upgrade executed script preflight under the software upgrade package directory and closes upgrade related process. The upgrade process may relate to updating drive and system configuration file, therefore, these system add-ins have to be terminated, otherwise, even the files are updated in the Mac system, what are running in the system are still old files; [0144] lines 1-8, step 504. the installation engine reads the undateInfo.plis file in the software upgrade package, acquires the upgrade resource file list, and creates an update operation list according to the source storage address, destination installation address and operation code of each upgrade resource file recorded in the upgrade resource file list).
Mesika, Khangaonkar, Murthy, SCHULTZ and Ma fail to specifically teach wherein the second upgrading type comprises expanding a memory of the virtual storage system and expanding the memory of the virtual storage system by using the second preset execution file.
However, Khosrowpour teaches wherein the second upgrading type comprises expanding a memory of the virtual storage system and expanding the memory of the virtual storage system by using the second preset execution file. (Khosrowpour, Col 14, lines 39-54, The performance improvement tool 106 may provide recommendations 172 to improve performance of one or more of the apps 110. For example, the recommendations 172 may include “Increasing RAM from 8 GB to 16 GB will provide up to X % improvement in execution times for app 110(N)”, “For app 110(N), switching from a first type of storage device (e.g., mechanical disk drive) to a second type of storage device (e.g., SSD) may provide up to Y % improvement in execution times, and switching to a third type of storage device (e.g., NVME) may provide up to Z % improvement in execution times.” (X, Y, and Z>0). The recommendations 172 may include “Upgrading to the latest Precision workstation with 4.2 GHz 17 processor, 16 GB RAM, and 256 GB NVME memory will yield an improvement of X % for app 110(N)).
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 the teaching of Mesika, Khangaonkar, Murthy, SCHULTZ and Ma with Khosrowpour because Khosrowpour’s teaching of different types of storage system for upgrading for improving performance would have provided Mesika, Khangaonkar, Murthy, SCHULTZ and Ma’s system with the advantage and capability to allow the system to determining the optimized upgrade based on the recommendation/training data in order to improving the resource utilization and system efficiency.
As per claim 16, it is an electronic device claim of claim 6 above. Therefore, it is rejected for the same reason as claim 6 above.
As per claim 19, it is an electronic device claim of claim 9 above. Therefore, it is rejected for the same reason as claim 9 above.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Mesika, Khangaonkar, Murthy, SCHULTZ, Ma, Khosrowpour and Zhang, as applied to claims 5 and 15 respectively above, and further in view of GU et al. (US Pub. 2014/0189282 A1).
As per claim 7, Mesika, Khangaonkar, Murthy, SCHULTZ, Ma, Khosrowpour and Zhang teach the invention according to claim 5 above. Khosrowpour further teaches wherein determining the target switching type of the virtual storage system comprises: determining the target switching type of the virtual storage system according a data reading speed of the virtual storage system (Khosrowpour, Col 6, lines 55-67, The training data for the classifier may be gathered using different types of storage devices with different types of interfaces. For example, different amounts of RAM, different types of storage, and the like may be used to generate the training data. The different types of storage may include mechanical-based disk drivers and solid-state drives (SSD) that use different types of interfaces, such as serial ATA (SATA), Non-Volatile Memory Express (NVMe), or the like. When the classifier is deployed (e.g., after being trained), the classifier may provide recommendations to improve performance, such as, for example, “Increasing RAM from 8 GB to 16 GB will provide up to X % improvement in execution times”, “Switching from a first type of storage device (e.g., mechanical disk drive) to a second type of storage device (e.g., SSD) may provide up to Y % improvement in execution times, and switching to a third type of storage device (e.g., NVME) may provide up to Z % improvement in execution times.” (X, Y, and Z>0) (As determining a target switching type of the virtual storage system (i.e., recommendation, please note: second preset execution file was taught by Mesika, SCHULTZ and Ma); Col 4, lines 14-15, to increase throughput when apps access the physical storage device).
Mesika, Khangaonkar, Murthy, SCHULTZ, Ma, Khosrowpour and Zhang fail to specifically teach determining the target switching type according to a size of remaining storage data.
However, GU teaches determining the target switching type according to a size of remaining storage data (GU, [0016] The allocating of the spare memory space may include, with respect to a storage node among the storage nodes allocating a space in which data is not stored in an available memory space as the spare memory space in response to a sum of the size of the current spare memory space and a size of the space in which data is not stored in the available memory space being less than the size of the recommended spare memory space, and allocating another space from which data was deleted in the available memory space as the spare memory space in response to the stored data being deleted from the other space).
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 the teaching of Mesika, Khangaonkar, Murthy, SCHULTZ, Ma, Khosrowpour and Zhang with GU because GU’s teaching of determining the allocation/upgrading based on a sum of the size of the current spare memory space would have provided Mesika, Khangaonkar, Murthy, SCHULTZ, Ma, Khosrowpour and Zhang’s system with the advantage and capability to allow the system to easily identifying the amount the resource needed for upgrading in order to improving the resource utilization and system performance.
As per claim 17, it is an electronic device claim of claim 7 above. Therefore, it is rejected for the same reason as claim 7 above.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Mesika, Khangaonkar, Murthy, SCHULTZ and Ma, as applied to claims 4 and 14 respectively above, and further in view of Khosrowpour et al. (US Patent. 10,771,580 B1) and BALANI et al. (US Pub. 2011/0231525 A1).
As per claim 8, Mesika, Khangaonkar, Murthy, SCHULTZ and Ma teach the invention according to claim 4 above. Mesika upgrading the virtual system (Mesika, Fig. 4, different features corresponding to different scripts; [0014] when a new feature is to be added to a virtualization manager development environment, a script management module can identify any database upgrade scripts that are associated with the new feature. In one embodiment, a single feature may have more than one database upgrade script 108 associated with it. In this case, each database upgrade script may be run on a management database in order to fully complete the upgrade. In one embodiment, each database upgrade script may have a naming convention that includes an identification number to uniquely identify the script. For example, the name of each database upgrade script may include an eight digit number where the first four digits represent a version number of the feature (e.g., 0301 for version 3.1); [0030] lines 2-6, designed to run the database upgrades scripts 108 on management database 109 based on the order of the identification numbers. For example, when request interface module 202 receives a request to install a feature, request interface module 202 may instruct script management module 204 to locate and run the associated database upgrade scripts 108). In addition, SCHULTZ teaches the virtual system is a virtual storage system, (SCHULTZ, [0402] lines 1-6, modifications to the virtual storage system 1902 may include, responsive to an increase in demand for compute and/or storage performance, upgrading storage classes for existing storage or commissioning new higher storage classes; [0235] initiating updates or upgrades on one or more storage systems).
Further, Ma teaches acquiring the system resources required for upgrading by using the second preset execution file comprises: acquiring, the system resources acquired for upgrading the virtual storage system by using the second preset execution file (Ma, [0143] lines 1-5, Step 503. the installation engine runs the pre-upgrade executed script preflight under the software upgrade package directory and closes upgrade related process. The upgrade process may relate to updating drive and system configuration file, therefore, these system add-ins have to be terminated, otherwise, even the files are updated in the Mac system, what are running in the system are still old files; [0144] lines 1-8, step 504. the installation engine reads the undateInfo.plis file in the software upgrade package, acquires the upgrade resource file list, and creates an update operation list according to the source storage address, destination installation address and operation code of each upgrade resource file recorded in the upgrade resource file list).
Mesika, Khangaonkar, Murthy, SCHULTZ and Ma fail to specifically teach wherein the second upgrading type comprises expanding a memory of the virtual storage system, acquiring an expansion capacity of the memory indicated in the upgrading instruction and determining whether the expansion capacity meets the supported system resources of the virtual storage system by using the second preset execution file; and acquiring, in response to determining that the expansion capacity meets the supported system resources, the system resources acquired.
However, Khosrowpour teaches wherein the second upgrading type comprises expanding a memory of the virtual storage system, acquiring an expansion capacity of the memory indicated in the upgrading instruction (Khosrowpour, Col 14, lines 39-54, The performance improvement tool 106 may provide recommendations 172 to improve performance of one or more of the apps 110. For example, the recommendations 172 may include “Increasing RAM from 8 GB to 16 GB will provide up to X % improvement in execution times for app 110(N)”, “For app 110(N), switching from a first type of storage device (e.g., mechanical disk drive) to a second type of storage device (e.g., SSD) may provide up to Y % improvement in execution times, and switching to a third type of storage device (e.g., NVME) may provide up to Z % improvement in execution times.” (X, Y, and Z>0). The recommendations 172 may include “Upgrading to the latest Precision workstation with 4.2 GHz 17 processor, 16 GB RAM, and 256 GB NVME memory will yield an improvement of X % for app 110(N)).
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 the teaching of Mesika, Khangaonkar, Murthy, SCHULTZ and Ma with Khosrowpour because Khosrowpour’s teaching of different types of storage system for upgrading for improving performance would have provided Mesika, Khangaonkar, Murthy, SCHULTZ and Ma’s system with the advantage and capability to allow the system to determining the optimized upgrade based on the recommendation/training data in order to improving the resource utilization and system efficiency.
Mesika, Khangaonkar, Murthy, SCHULTZ, Ma and Khosrowpour fail to specifically teach determining whether the expansion capacity meets the supported system resources of the virtual storage system by using the second preset execution file; and acquiring, in response to determining that the expansion capacity meets the supported system resources, the system resources acquired.
However, BALANI teaches determining whether the expansion capacity meets the supported system resources of the virtual storage system by using the second preset execution file; and acquiring, in response to determining that the expansion capacity meets the supported system resources, the system resources acquired (BALANI, [0077] lines 1-12, Based on the information provided by the ontological database, if a cloud resource provider receives a request for a specific set of cloud resources (e.g., an application server capable of handling 100 users for less than $1000 per year, while meeting the SLA of being "up" at least 95% of the time), then an optimal set of cloud resources that meet these requirements can be configured by utilizing the ontological database for each of the resources in a cloud (block 614). Resources meeting these requirements that are supported by the cloud environment can be dynamically pulled off by scanning the OWL meta-data. [0080] Note that the "set of cloud resources" may be a set of multiple cloud resources, or it may be a single cloud resource, such as a virtual application server, a database (virtual or real), a messaging service, an extension to a set of software instructions (please note: expansion capacity was taught by Khosrowpour)).
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 the teaching of Mesika, Khangaonkar, Murthy, SCHULTZ, Ma and Khosrowpour with BALANI because BALANI’s teaching of determining if the set of cloud of resources (as including expansion capacity) will meet the requirement and acquiring the resources would have provided Mesika, Khangaonkar, Murthy, SCHULTZ, Ma and Khosrowpour’s system with the advantage and capability to allow the system to ensuring the resources that later acquired to meet the requirements which preventing potential system failure due to lacks of resources in order to improving the system reliability.
As per claim 18, it is an electronic device claim of claim 8 above. Therefore, it is rejected for the same reason as claim 8 above.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Mesika, Khangaonkar, Murthy, SCHULTZ and Ma, as applied to claim 4 above, and further in view of DAIN (US Pub. 2013/0179878 A1).
As per claim 10, Mesika, Khangaonkar, Murthy, SCHULTZ and Ma teach the invention according to claim 4 above. Ma further teaches before shutting down the virtual storage system by using the second preset execution file (Ma, [0143] lines 1-5, Step 503. the installation engine runs the pre-upgrade executed script preflight under the software upgrade package directory and closes upgrade related process. The upgrade process may relate to updating drive and system configuration file, therefore, these system add-ins have to be terminated, otherwise, even the files are updated in the Mac system, what are running in the system are still old files) further comprising triggering the second preset execution file (Ma, [0024] The installation engine calling a pre-upgrade executed script in the software upgrade package, and before update the client with the upgrade resource file, the installation engine closing a relevant process of the client currently running by way of the pre-upgrade executed script).
Mesika, Khangaonkar, Murthy, SCHULTZ and Ma fail to specifically teach determining a target time instant according to a work load and a use state of the virtual storage system; and when triggering the second preset execution file, it is triggering at the target time instant.
However, DAIN teaches determining a target time instant according to a work load and a use state of the virtual storage system; and when triggering the second preset execution file, it is triggering at the target time instant. (DAIN, [0064] Alternatively, the scheduling module may determine the optimal time to perform an upgrade based on system resource utilization. For example, CPU, network, and disk utilization might be lowest at time T=3-5 (as work load and use state) and the scheduling module may identify time T=3 to initiate an upgrade. This may also be employed as a second level trend identification approach only if there are no clear idle times identified; please note virtual storage system was taught by SCHULTZ).
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 the teaching of Mesika, Khangaonkar, Murthy, SCHULTZ and Ma with DAIN because DAIN’s teaching of determining the target time for initiating the upgrade would have provided Mesika, Khangaonkar, Murthy, SCHULTZ and Ma’s system with the advantage and capability to allow the system to ensuring when performing the upgrade, it is based on the usage at lowest time in order to minimizing the impact regarding to the upgrade which improving the user experience and system performance.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
In the remark applicant’s argue in substance:
(a), the claim requires that a plurality of preset execution files be pre-deployed as functions as a service on a serverless platform and organized by a mapping relationship to different upgrading types that correspond to different working processes. This claimed architecture directly improves upgrading efficiency and reliability by ensuring that each upgrading type is handled by an independent.
(b), the claim requires that, in response to the preset execution file being invoked, the serverless platform allocates system resources and starts a host environment to run the preset execution file. This claimed on-demand provisioning step is itself a technical improvement: it ensures that computing resources are allocated only when the upgrade is actually triggered, and no resources are consumed when the function is not invoked-directly addressing the prior art problem identified in the specification at paragraphs [0021]-[0023], where continuously running virtual machines consumed resources regardless of whether an upgrade was occurring.
Examiner respectfully disagreed with Applicant’s argument for the following reasons:
As to point (a), in response to applicant’s argument that “a plurality of preset execution files be pre-deployed as functions as a service on a serverless platform and organized by a mapping relationship to different upgrading types that correspond to different working processes. This claimed architecture directly improves upgrading efficiency and reliability by ensuring that each upgrading type is handled by an independent”. Examiner would like to point out that the concept can be performed by mentally. That is, the human mind can easily judging/evaluating/determining an upgrading type corresponding to the upgrading instruction and a preset execution file matched with the upgrading type based on the mapping relationship between a plurality of upgrading types and a plurality of preset execution files pre-deployed (i.e., by observing and comparing with mapping).
In addition, MPEP 2106.05(a) discloses that “It is important to note, the judicial exception alone cannot provide the improvement. The improvement can be provided by one or more additional elements. See the discussion of Diamond v. Diehr, 450 U.S. 175, 187 and 191-92, 209 USPQ 1, 10 (1981)) in subsection II, below. In addition, the improvement can be provided by the additional element(s) in combination with the recited judicial exception”. Here, the claim does NOT provide any additional limitations other than the generic computing components/Functions (i.e., system resource allocated, start host environment, which is directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a generic computer as a tool to perform an abstract idea (see MPEP 2106.05(f)).) that perform the abstract idea. Therefore, the claim cannot provide the improvement. Therefore, the claim cannot provide the improvement.
As to point (b), please refers to point (a) above. Again, the claimed limitation “in response to the preset execution file being invoked, the serverless platform allocates system resources and starts a host environment to run the preset execution file” which is which is directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a generic computer as a tool to perform an abstract idea (see MPEP 2106.05(f)). (i.e., this is no more than using the system resource (generic computer) as tool to perform the preset execution file). It does not provide any details on how the claimed function (i.e., upgrading) will occur. In other words, how that virtual storage system is upgraded (see claim 4 for more details).
For the reasons above, Applicant’s argument has not been found to be persuasive, and therefore the rejections are maintained.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZUJIA XU whose telephone number is (571)272-0954. The examiner can normally be reached M-F 9:30-5:30 EST.
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 J 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.
/ZUJIA XU/Primary Examiner, Art Unit 2195
Prosecution Insights