DETAILED ACTION The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Claims 1-20 are pending in this application. Specification The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed. 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 ” 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. 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 “the preset execution file being pre-deployed in the serverless platform” 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 “the preset execution file being pre-deployed in the serverless platform” 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 SCHULTZ et al. (US Pub. 2022/0035714 A1). 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 an upgrading type corresponding to the upgrading instruction and a preset execution file matched with the upgrading type, the preset execution file being pre-deployed in the platform (Mesika, Fig. 4 upgrade features; 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; [0045] lines 1-13, method 500 identifies database upgrade scripts corresponding to the new feature (as determining an upgrading type corresponding to the upgrading instruction and a preset execution file matched with the upgrading type, see [0044] receives the request, which may specify the new feature to install). 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 (as upgrade type, version updating) and/or script identification number) ; 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 the virtual system is a virtual storage system, and upgrading is applied to a serverless platform. However, SCHULTZ teaches the virtual system is a virtual storage system, and upgrading is applied to a serverless platform ( 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 with SCHULTZ because SCHULTZ’s teaching of upgrading the virtual storage system at serverless platform would have provided Mesika’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). A s 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 and SCHULTZ, as applied to claims 1 and 11 respectively above, and further in view of TURLIK et al. (US Pub. 2023/0297527 A1). As per claim 2, Mesika 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 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 , m emory 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 and SCHULTZ with TURLIK because TURLIK’s teaching of using the execution file for performing the memory allocation would have provided Mesika 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 , 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, 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, 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, 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, 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 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 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 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 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 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 , 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, 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, 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, SCHULTZ and Ma with Khosrowpour because Khosrowpour’s teaching of different types of storage system for upgrading for improving performance would have provided Mesika, 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, 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, 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, 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 , 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, 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, 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, SCHULTZ and Ma with Khosrowpour because Khosrowpour’s teaching of different types of storage system for upgrading for improving performance would have provided Mesika, 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, 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, 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, SCHULTZ and Ma with Khosrowpour because Khosrowpour’s teaching of different types of storage system for upgrading for improving performance would have provided Mesika, 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 , 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, 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, 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 a