DETAILED ACTION
The action is in response to the original filing on October 10, 2024, and the Remarks and Amendments filed on July 14, 2026. Claims 1-17 are pending and have been considered below. Claims 1-2, 7, and 11-12 are amended accordingly.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claim 9 is objected to because of the following informalities: Claim 9 recites “the second processor,” “the target service module,” and “the target graphics processing unit,” which do not have antecedent basis in the claims, although the Examiner can understand the intended meaning and scope of these limitations. The Examiner suggests amending these limitations to read, for example, “the second processor of claim 7,” “the target service module of claim 7,” and “the target graphics processing unit of claim 7,” such that they clearly reference from where they are derived. Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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-2, 4, 11-12, &14 are rejected under 35 U.S.C. 103 as being unpatentable over Yu-kai Tian Et. Al. (Pat. Pub. CN-116860391-A, herein after “Tian”) in view of Hai-ling Song (Pat. Pub. CN-116578416-A) and an unnamed author (Pat. Pub. CN-116894275-A, herein after “Unnamed”).
In regard to claims 1 & 11, Tian teaches [a] method comprising:
generating, by a virtual machine at a first node “a GPU computing power resource scheduling method is provided” (Tian, page 2) where the request is made from a virtual machine, target information including an application request “GPU calculation force resource request from the target virtual machine” (Tian, page 2) where the resource request can be read as target information, including an application request, the target information satisfying a preset information transmission rule for transmission between a virtual graphics processing unit driver module of the virtual machine and a first processor at the first node “the through establishing unit is further configured to: obtaining the total port address of the target GPU device” (Tian, page 3) where the transmission information rule can be interpreted as a requirement to permit transmission, such as obtaining port address for access;
Tian does not explicitly teach determining, by the first processor, a target service module at a second node and a transmission path by querying a mapping table stored in the first processor based on the target information, the mapping table recording a correspondence between virtual graphics processing units and remote graphics processing units and including information identifying the target service module and a communication link type corresponding to the remote graphics processing units, the target service module being connected to a target graphics processing unit, and the transmission path connecting the virtual graphics processing unit driver, the first processor, a second processor at the second node, and the target service module;
sending, by the first processor, the application request to the target service module based on the transmission path; and
receiving, by the first processor, a processing result fed back by the second processor through the transmission path.
Song teaches determining, by the first processor based on the target information, a target service module at a second node and a transmission path “a GPU selecting module for selecting the target virtual GPU based on the simulation task” (Song, Page 3) where the target GPU must be selected by a module, which must receive information from a first system with a first processor to send the information, the target service module (“GPU selecting module”, Song, Page 3) being connected to a target graphics processing unit (“target virtual GPU”, Song, Page 3), and the transmission path connecting the virtual graphics processing unit driver, the first processor, a second processor at the second node, and the target service module “The method virtualizes the physical GPU into several virtual GPU through virtualization technology, then selects the most suitable target virtual GPU based on the simulation task, when executing the simulation task to the read-write GPU display memory, the request of the simulation task is redirected to the VCUDA library, re-updating the resource request configuration information of the application, based on the limited GPU resource use amount, operating the container application, reaching the purpose of using GPU resource by multiple container applications at the same time under the condition of non-sensing, finally based on the VCUDA library and the target virtual GPU, obtaining the response result of the simulation task, enabling the cloud computing platform to become a virtual GPU resource available multiplexing, capable of performing parallel computing task distribution” (Song, Page 3);
sending, by the first processor, the application request to the target service module based on the transmission path “the simulation task request is redirected to the VCUDA library, the VCUDA library comprises the rename function of several CUDA functions, the return value of the rename function is determined based on the information of the target virtual GPU” (Song, Page 3); and
receiving, by the first processor, a processing result fed back by the second processor through the transmission path “step 108, based on the VCUDA library and the target virtual GPU, obtaining the response result of the simulation task” (Song, Page 3) where the result of the simulation task is received based on the target GPU and VCUDA library.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of connecting a virtual machine with a GPU for information transfer taught by Tian with the method of a transmission path including a target service module taught by Song to send and receive the information. The motivation to do so would be to have a system which can confidently move the information through the modules and back to the user.
Tian in view of Song fail to explicitly teach querying a mapping table stored in the first processor based on the target information, the mapping table recording a correspondence between virtual graphics processing units and remote graphics processing units and including information identifying the target service module and a communication link type corresponding to the remote graphics processing units.
Unnamed teaches querying a mapping table stored in the first processor based on the target information, the mapping table recording a correspondence between virtual graphics processing units and remote graphics processing units and including information identifying the target service module and a communication link type corresponding to the remote graphics processing units “the second driver will perform full-link check according to the currently maintained information table, that is, all the page tables associated with the root of the page table to be updated are checked, and if the pointing problem of the page table entry of a page table is found, the page table entry will be modified as invalid” (Unnamed, Page 16) where a page table is used and updated for mapping addresses in memory. Additionally, “[i]n the embodiment of the present application, generally, the basic check is a first-stage check, the full-link check is a second-stage check, and the supplemental check is a third-stage check. It should be noted that the application does not limit the execution order of the three stages, and can be specifically selected according to the actual application scene” (Unnamed, Page 17) where a full-link check is taught according to the table, which is read as recording a communication link type.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of transmitting an application request to a target service module, receiving a processing result between two processors, and transmission path taught by Tian in view of Song with the use of a page table that records a communication link type taught by Unnamed to map addresses. The motivation to do so would be to include the information about connections between the virtual and remote processing units within the first processor.
In regard to claim 11, claim 1 is substantially similar to claim 11, hence the rejection analysis for claim 1 is also applied to claim 11. Tian in view of Song and Unnamed teach the additional limitations of [a] device applied at a first node, comprising:
one or more memories storing one or more programs “The memory 1315 may be used to store software programs and modules, and the processor 1380 executes various functional applications and data processing of the terminal by running the software programs and modules stored in the memory 1315” (Tian, Page 17); and
one or more processors including a first processor and configured to execute the one or more programs to “The server 130 may generate a relatively large difference due to configuration or performance differences, and may include one or more central processing units (CPU) 1422 (for example, one or more central processing units) (e.g., one or more central processing units) 1422 (CPU) 1422 (for example, one or more central processing units) 1422 (for example, one or more central processing units) 1422 (for example, one or more central processing units) 1422 (for example, One or more processors) and memory 1432, one or more storage applications 1442 or a storage medium 1430 of data 1444 (e.g., one or more mass storage devices)” (Tian, Page 18):
generate target information including an application request, the target information satisfying a preset information transmission rule for transmission between a virtual graphics processing unit driver module of a virtual machine at the first node and the first processor (Tian, Pages 2 & 3);
determine, a target service module at a second node and a transmission path by querying a mapping table stored in the first processor based on the target information, the mapping table recording a correspondence between virtual graphics processing units and remote graphics processing units and including information identifying the target service module and a communication link type corresponding to the remote graphics processing units (Unnamed, Pages 16 & 17), the target service module being connected to a target graphics processing unit, and the transmission path connecting the virtual graphics processing unit driver, the first processor, a second processor at the second node, and the target service module (Song, Page 3);
send the application request to the target service module based on the transmission path (Song, Page 3); and
receive a processing result fed back by the second processor through the transmission path (Song, Page 3).
In regard to claims 2 & 12, Tian in view of Song and Unnamed teach [t]he method according to claim 1, wherein generating the target information includes:
intercepting, by the virtual graphics processing unit driver module, the application request output by an application in the virtual machine based on one of at least two interception interfaces of the virtual graphics processing unit driver module that corresponds to the application “The server 130 may also include one or more power sources 1426, one or more wired or wireless network interfaces 1450, one or more input-output interfaces 1458, and/or one or more operating systems 1441” (Tian, Page 18) where the plurality of GPU devices are bound to the server, and multiple interfaces may be used in regard to the resource request transferring to and from the plurality of GPU devices, and it is known that a GPU will contain a driver module; and
processing, by the virtual graphics processing unit driver module, the application request according to the preset information transmission rule to obtain the target information “Optionally, the through establishing unit is further configured to: based on the first virtual address and the second virtual address, using the device transmission drive to create a virtual GPU device in the target virtual machine; establishing a direct connection between the virtual GPU device and the target GPU device.” (Tian, Page 3) where according to the request, a virtual GPU is assigned to perform the required action.
In regard to claim 12, claim 2 is substantially similar to claim 12, hence the rejection analysis for claim 2 is also applied to claim 12. Tian teaches the additional limitations of [t]he device according to claim 11, wherein one or more processors are further configured to execute the one or more programs to, when generating the target information:
intercept the application request output by an application in the virtual machine based on one of at least two interception interfaces of the virtual graphics processing unit driver module that corresponds to the application (Tian, Page 18); and
process the application request according to the preset information transmission rule to obtain the target information (Tian, Page 3).
In regard to claims 4 & 14, Tian in view of Song and Unnamed teach [t]he method according to claim 1, further comprising, after receiving the processing result:
parsing, by the first processor, the processing result to determine that the processing result corresponds to the target service module “a through establishing unit for loading the configuration file by using the device management drive and establishing the through connection between the target virtual machine and the target GPU device by using the device transmission drive” (Tian, Page 2) where the processing result configuration file is read to determine the connection between the target virtual machine and the target GPU;
feeding, by the first processor, back the processing result to the virtual machine to which the virtual graphics processing unit driver module belongs “using the device management drive to load the configuration file, using the device transmission drive to establish the direct connection between the target virtual machine and the target GPU device according to the node address” (Tian, Page 3).
Tian fails to explicitly teach determining, by the first processor according to the preset correspondence relationship, the virtual graphics processing unit driver module corresponding to the target service module from at least two candidate virtual graphics processing unit driver modules in the first node.
Song teaches determining, by the first processor according to the preset correspondence relationship, the virtual graphics processing unit driver module corresponding to the target service module from at least two candidate virtual graphics processing unit driver modules in the first node “step 104, based on the simulation task, selecting a target virtual GPU from the plurality of virtual GPUs” (Song, Page 4) where the selection is based on the task sent.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of connecting a virtual machine with a GPU for information transfer, and creation of virtual GPU for direct connection taught by Tian with the method of determining the virtual GPU taught by Song to have a preset list of virtual GPUs which can be used to quickly choose which corresponds to the target service. The motivation to do so would be to quickly allocate the correct virtual GPU for the task necessary.
In regard to claim 14, claim 4 is substantially similar to claim 14, hence the rejection analysis for claim 4 is also applied to claim 14. Tian in view of Song teach the additional limitations of [t]he device according to claim 11, wherein one or more processors are further configured to execute the one or more programs to, after receiving the processing result:
parse the processing result to determine that the processing result corresponds to the target service module (Tian, Page 2);
determine, according to the preset correspondence relationship, the virtual graphics processing unit driver module corresponding to the target service module from at least two candidate virtual graphics processing unit driver modules in the first node (Song, Page 4); and
feed back the processing result to the virtual machine to which the virtual graphics processing unit driver module belongs (Tian, Page 3).
Claims 3, 5-6, 13 & 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Tian in view of Song, Unnamed, and Kang-hua Fang (Pat. Pub. CN-116820764-A, herein after “Fang”).
In regard to claims 3, & 13, Tian in view of Song and Unnamed teach [t]he method according to claim 1, wherein determining the target service module and the transmission path includes:
parsing, by the first processor, the target information to determine the virtual graphics processing unit driver module corresponding to the application request “In the embodiment of the invention, after receiving the GPU calculation force resource request from the target virtual machine, the server selects one of multiple GPU devices as the target GPU device distributed to the target virtual machine; generating the configuration file of the target GPU, using the device management drive to load the configuration file, and using the direct connection between the target virtual machine and the target GPU device” (Tian, Page 4) where the resource request is read to determine a corresponding target GPU; and
determining, by the first processor, the target service module and the transmission path corresponding to the virtual graphics processing unit driver module based on a preset correspondence relationship “… after receiving the GPU calculation force resource request from the target virtual machine, the server selects one of multiple GPU devices as the target GPU device distributed to the target virtual machine; generating the configuration file of the target GPU, using the device management drive to load the configuration file, and using the direct connection between the target virtual machine and the target GPU device” (Tian, Page 4) where the target virtual machine which contains a first processor, sends a resource request, and is connected to a target GPU, the transmission path including a first transmission module of the first processor and a second transmission module of the second processor “The device management driver is used for managing the target virtual machine and detecting the use condition of the target GPU device ... The device transmission drive can improve the efficiency of establishing through connection, and also can transmit the resource data in the target GPU device to the target virtual machine, which improves the accuracy of data transmission” (Tian, Page 4) where the transmission path is from the virtual machine to the target GPU. Additionally, “step 240, using the device management drive to load the configuration file, using the device transmission drive to establish the through connection between the target virtual machine and the target GPU device; Step 250: transparently transmitting the resource data in the target GPU device to the target virtual machine by using the device transmission driver” (Tian, Page 7).
Tian teaches transmission methods but does not explicitly state where the first transmission module and the second transmission module being of a same type.
Fang teaches the transmission path including a first transmission module of the first processor and a second transmission module of the second processor, and the first transmission module and the second transmission module being of a same type “RDMA (Remote Direct Memory Access): It is generated for solving the delay of the data processing of the server terminal in the network transmission. It directly transmits the data from the memory of one computer to another computer without the intervention of the two operating systems. This allows high throughput, low delay network communications, and is particularly suitable for use in large scale parallel computer clusters” (Fang, Page 6) which better teaches the method of transmission.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of connecting a virtual machine with a GPU for information transfer, and creation of virtual GPU for direct connection taught by Tian with the use of the same transmission type taught by Fang to have matching transmissions. The motivation to do so would be to send and receive similar formats without a need for extra transmission steps.
In regard to claim 13, claim 3 is substantially similar to claim 13, hence the rejection analysis for claim 3 is also applied to claim 13. Tian in view of Song and Fang teach the additional limitations of [t]he device according to claim 11, wherein one or more processors are further configured to execute the one or more programs to, when determining the target service module and the transmission path:
parse the target information to determine the virtual graphics processing unit driver module corresponding to the application request (Tian, Page 4); and
determine the target service module and the transmission path corresponding to the virtual graphics processing unit driver module based on a preset correspondence relationship, the transmission path including a first transmission module of the first processor and a second transmission module of the second processor, and the first transmission module and the second transmission module being of a same type (Tian, Pages 4 & 7) & (Fang, Page 6).
In regard to claims 5 & 15, Tian in view of Song and Unnamed teach [t]he method according to claim 1, further comprising, after generating the target information:
determining, by the first processor, a function type of the target information “The appropriate GPU device 141 is selected according to the type of the transaction to be processed, the amount of calculation, and the like” (Tian, Page 8); in response to the function type being a first type “receiving the GPU calculation force resource request from the target virtual machine” (Tian, Page 2):
obtaining, by the first processor, transmission path information carried in the target information “selecting a target GPU device from multiple GPU devices according to the GPU calculation force resource request;” (Tian, Page 2), the transmission path information at least including an identifier of the virtual graphics processing unit driver module, an identifier of the second node, and an identifier of the target graphics processing unit “When generating the configuration file, the number of ports of the target GPU device needs to be determined, and the address of each port is added to the configuration file, so that the target virtual machine 110 can identify all functional ports on the target GPU device” (Tian, Page 9); and
establishing, by the first processor, the transmission path between the virtual graphics processing unit driver module and the target graphics processing unit based on the transmission path information “after receiving the GPU calculation force resource request from the target virtual machine, the server selects one of multiple GPU devices as the target GPU device distributed to the target virtual machine” (Tian, Page 4) where it can be interpreted that the resource request sent determines which target GPU is to be used, and therefore, determines the transmission path, the transmission path including the virtual graphics processing unit driver module, the first processor, the second processor, the target service module, and the target graphics processing unit “generating the configuration file of the target GPU, using the device management drive to load the configuration file, and using the direct connection between the target virtual machine and the target GPU device. The device management driver is used for managing the target virtual machine and detecting the use condition of the target GPU device so that the GPU arithmetic resource scheduling process can be monitored so as to process the burst condition. The connection between the target virtual machine and the target GPU device can be improved by the configuration file” (Tian, Page 4) where the connection between the virtual machine and the target GPU is the transmission path, and the devices that create the path include a driver that operates the GPU, a module to select the target GPU, the target GPU, as well as the virtual machine, which is run a processor.
Tian in view of Song and Unnamed fail to explicitly teach in response to the function type being a second type, triggering execution by the first processor of determining the target service module and the transmission path based on the target information.
Fang teaches in response to the function type being a second type, triggering execution by the first processor of determining the target service module and the transmission path based on the target information “the providing system of the computing resource realizes the receiving and transmission of the computing request in the virtual computing device through the semi-virtualization technology, Thus, the calculation request can be transmitted to the virtual backend unit 322 carrying the virtual calculation resource based on the shared memory by the virtual front end unit 321 running in the user state, so that the calculation request does not need to perform data copy between the user state and the kernel state” (Fang, Page 9) where the process of virtualization is done with a single system and processor.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of connecting a virtual machine with a GPU for information transfer, with a transmission path from a first processor to a second, then to a target service module, and finally to a target GPU and back taught by Tian with the method of a single processor used for virtualization taught by Fang to produce a transmission path utilizing a single processor. The motivation to do so would be to allow for GPU virtualization with a single processor.
In regard to claim 15, claim 5 is substantially similar to claim 15, hence the rejection analysis for claim 5 is also applied to claim 15. Tian in view of song, Unnamed, and Fang teach the additional limitations of [t]he device according to claim 11, wherein one or more processors are further configured to execute the one or more programs to, after generating the target information:
determine a function type of the target information (Tian, Page 8);
in response to the function type being a first type:
obtain transmission path information carried in the target information, the transmission path information at least including an identifier of the virtual graphics processing unit driver module, an identifier of the second node, and an identifier of the target graphics processing unit (Tian, Pages 2 & 9); and
establish the transmission path between the virtual graphics processing unit driver module and the target graphics processing unit based on the transmission path information, the transmission path including the virtual graphics processing unit driver module, the first processor, the second processor, the target service module, and the target graphics processing unit (Tian, Page 4); and
in response to the function type being a second type, trigger execution of determining the target service module and the transmission path based on the target information (Fang, Page 9).
In regard to claims 6 & 16, Tian in view of Song, Unnamed, and Fang teach [t]he method according to claim 5, further comprising: in response to the function type being a third type:
obtaining, by the first processor, information of a transmission path to be cancelled from the target information “step 1020, if the target GPU device stops calculating, detecting again after a predetermined time period, if the target GPU device stops calculating, modifying the configuration file” (Tian, Page 15), the information of the transmission path to be cancelled including an identifier of a virtual graphics processing unit driver module corresponding to the transmission path to be cancelled “removing the binding between the target GPU device and the server; using the device management drive to load the configuration file, using the device transmission drive to establish the through connection between the target virtual machine and the target GPU device according to the node address” (Tian, Page 16) where the connection path is removed;
generating, by the first processor, cancellation information based on the information of the transmission path to be cancelled “if the target GPU device stops calculating, detecting again after the preset time period, if the target GPU device stops calculating, modifying the configuration file” (Tian, Page 17) where the modified config. file can be read as cancellation information; and
sending, by the first processor, the cancellation information to a service module at the second node based on the transmission path to be cancelled, to enable the service module to release graphics processing unit resources corresponding to the transmission path to be cancelled “The direct-through unbinding unit 1260 is configured to modify the configuration file after the calculation by the target virtual machine using the calculation force resource in the target GPU device is completed, and load the configuration file by the device management and drive, and unchain the direct-through connection between the target virtual machine and the target GPU device” (Tian, Page 16) where the virtual machine may go idle or no longer require the virtual GPU, and the connection is removed.
In regard to claim 16, claim 6 is substantially similar to claim 16, hence the rejection analysis for claim 6 is also applied to claim 16. Tian teaches the additional limitations of [t]he device according to claim 15, wherein one or more processors are further configured to execute the one or more programs to, in response to the function type being a third type:
obtain information of a transmission path to be cancelled from the target information, the information of the transmission path to be cancelled including an identifier of a virtual graphics processing unit driver module corresponding to the transmission path to be cancelled (Tian, Pages 15 & 16);
generate cancellation information based on the information of the transmission path to be cancelled (Tian, Page 17); and
send the cancellation information to a service module at the second node based on the transmission path to be cancelled, to enable the service module to release graphics processing unit resources corresponding to the transmission path to be cancelled (Tian, Page 16).
Claims 7-10 are rejected under 35 U.S.C. 103 as being unpatentable over Tian in view of Unnamed.
In regard to claim 7, Tian teaches [a] method comprising:
receiving an application request transmitted by a first processor at a first node, by a second processor at a second node “a receiving unit for receiving the GPU calculation force resource request from the target virtual machine” (Tian, Page 2) where a first processor operating a virtual machine sends a resource request to a second processor operating the receiving unit and following units;
sending, by the second processor, the application request to a target service module at the second node “a receiving unit for receiving the GPU calculation force resource request from the target virtual machine” (Tian, Page 2) where the receiving unit communicates the request to a distributing unit, and contains a processor, the target service module being connected to a target graphics processing unit “a distribution unit for selecting a target GPU device from multiple GPU devices according to the GPU calculation force resource request” (Tian, Page 2);
calling, by the target service module, the target graphics processing unit based on the application request “a generating unit for generating a configuration file based on the target GPU device” (Tian, Page 2) where the target GPU has been selected and generates a config. file;
responding, by the target graphics processing unit, to the application request to obtain a processing result “loading the configuration file by using the device management drive and establishing the through connection between the target virtual machine and the target GPU” (Tian, Page 2);
feeding, by the target graphics processing unit, back the processing result to the second processor “a transparent transmission unit for transparently transmitting the resource data in the target GPU device to the target virtual machine by the device transmission drive” (Tian, Page 3) where the information is transmitted back the way it came; and
sending, by the second processor, the processing result to the first processor “the device management drive to load the configuration file, using the device transmission drive to establish the direct connection between the target virtual machine and the target GPU device according to the node address” (Tian, Page 3) where the information is transmitted back through the established connection;
wherein the target service module and a transmission path used for transmitting the application request are determined by the first processor based on a mapping table stored in the first processor, the mapping table recording a correspondence between virtual graphics processing units at the first node and remote graphics processing units at the second node and including information identifying the target service module “The device transmission driver maps the target GPU device on the target virtual machine 110, and establishes a through connection between the target GPU device and the target virtual machine 110” (Tian, Page 13) where the target GPU is mapped from the transmission driver through the target virtual machine by an established through connection.
Tian does not explicitly teach the mapping table recording a communication link type corresponding to the remote graphics processing units.
Unnamed teaches the mapping table recording a communication link type corresponding to the remote graphics processing units “the second driver will perform full-link check according to the currently maintained information table, that is, all the page tables associated with the root of the page table to be updated are checked, and if the pointing problem of the page table entry of a page table is found, the page table entry will be modified as invalid” (Unnamed, Page 16) where a page table is used and updated for mapping addresses in memory. Additionally, “[i]n the embodiment of the present application, generally, the basic check is a first-stage check, the full-link check is a second-stage check, and the supplemental check is a third-stage check. It should be noted that the application does not limit the execution order of the three stages, and can be specifically selected according to the actual application scene” (Unnamed, Page 17) where a full-link check is taught according to the table, which is read as recording a communication link type.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of transmitting an application request to a target service module, receiving a processing result between two processors, and an established connection taught by Tian with the use of a page table that records a communication link type taught by Unnamed to map addresses. The motivation to do so would be to include the information about connections between the virtual and remote processing units within the first processor.
In regard to claim 8, Tian in view of Unnamed teaches [t]he method according to claim 7, wherein feeding back the processing result to the second processor includes:
sending the processing result to the second processor by the target graphics processing unit based on a direct link between a graphics processing unit set including the target graphics processing unit and the second processor “The bus address is the memory address of the GPU device 141 that the server 130 can directly access” (Tian, Page 9) where the target GPU may be directly accessed from the server or the virtual machine.
In regard to claim 9, Tian in view of Unnamed teaches [a] device comprising:
the second processor “a receiving unit for receiving the GPU calculation force resource request from the target virtual machine” (Tian, Page 2) where a processor is required to operate the modules that process the resource request;
a service module set including the target service module “a distribution unit for selecting a target GPU device from multiple GPU devices according to the GPU calculation force resource request” (Tian, Page 2) where the distribution unit performs the actions of the service module; and
a graphics processing unit set including the target graphics processing unit “a distribution unit for selecting a target GPU device from multiple GPU devices according to the GPU calculation force resource request” (Tian, Page 2);
wherein the second processor, the target service module, and the target graphics processing unit are configured to perform the method of claim 7 (see the rejection of claim 7).
In regard to claim 10, Tian in view of Unnamed teaches [t]he device according to claim 9, wherein the target graphics processing unit is further configured to, when feeding back the processing result to the second processor:
send the processing result to the second processor based on a direct link between the graphics processing unit set and the second processor “the illustrated or discussed coupling or direct coupling or communication connection to each other may be an indirect coupling or communication connection via some interface, device or unit, and may be in electrical, mechanical or other form” (Tian, Page 19) where the method of data transfer may be direct or indirect, wired or wireless, or may contain a type of interface.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Tian in view of Song, Unnamed, and Todd Rimmer et al. (Pat. Pub. US-20220351326-A1, herein after “Rimmer”).
In regard to claim 17, Tian in view of Song and Unnamed teach [t]he method according to claim 1, wherein the first processor is a chip set at the first node and the second processor is a second chip set at the second node, and the first processor directly communicates with the second processor through an interface “the illustrated or discussed coupling or direct coupling or communication connection to each other may be an indirect coupling or communication connection via some interface, device or unit, and may be in electrical, mechanical or other form.” (Tian, Page 19) where the processors may communicate via an interface.
Tian in view of Song and Unnamed fail to explicitly teach a data processing unit (DPU).
Rimmer teaches a data processing unit (DPU) “network interface device 508-0 can include one or more of: a network interface controller (NIC), a remote direct memory access (RDMA)-enabled NIC, router, switch, forwarding element, infrastructure processing unit (IPU), or data processing unit (DPU)” (Rimmer, ¶ [0030]) where a data processing unit is utilized.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of transmitting an application request to a target service module, receiving a processing result between two processors, and transmission path that uses a page table with the communication link type taught by Tian in view of Song and Unnamed with the processors being data processing units taught by Rimmer to specifically process desired information. The motivation to do so would be to include the information about connections between the virtual and remote processing units within the first processor and allow the first processor to manage information according to a variety of DPU tasks.
Response to Arguments
Applicant' s arguments with respect to the prior art rejections have been fully considered, but are moot in view of the new grounds of rejection presented above. The Examiner agrees that the previously cited art does not teach the newly amended claim limitations; however, the Examiner respectfully submits that an unnamed author (Pat. Pub. CN-116894275-A, herein after “Unnamed”) teaches these limitations.
Applicant argues that the cited art fails to disclose any correspondence relationship table that associates virtual graphics processing units with remote graphics processing units nor any table containing information identifying a target service module and a communication link type used to determine a transmission path. Examiner appreciates the amendments and clarity provided, however, the arguments are moot in view of the cited reference unnamed inventor Pat. Pub. CN-116894275-A, herein after “Unnamed”. Unnamed discloses a “full-link check according to the currently maintained information table, that is, all the page tables associated with the root of the page table to be updated are checked, and if the pointing problem of the page table entry of a page table is found, the page table entry will be modified as invalid” (Unnamed, Page 16) where a page table is used and updated for mapping addresses in memory. Additionally, “[i]n the embodiment of the present application, generally, the basic check is a first-stage check, the full-link check is a second-stage check, and the supplemental check is a third-stage check. It should be noted that the application does not limit the execution order of the three stages, and can be specifically selected according to the actual application scene” (Unnamed, Page 17) where a full-link check is taught according to the table, which is read as a communication link type. Examiner applies the cited reference Unnamed in view of Tian and Song to teach the substantially similar amendments to claims 7 and 11.
Applicant’s newly added claim 17 specifies that the processors from claim 1 are data processing units. The newly cited art Todd Rimmer et al. (Pat. Pub. US-20220351326-A1) discloses “network interface device 508-0 can include one or more of: a network interface controller (NIC), a remote direct memory access (RDMA)-enabled NIC, router, switch, forwarding element, infrastructure processing unit (IPU), or data processing unit (DPU)” (Rimmer, ¶ [0030]) where the data processing unit would be obvious to combine with the processors used in Tian and Song.
Conclusion
Applicant's amendment necessitated the new grounds 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 CAIDEN ALEXANDER USSERY whose telephone number is (571)272-1192. The examiner can normally be reached Monday - Friday* 7:30AM - 5PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Tammy Goddard can be reached at (571) 272-7773. 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.
/CAIDEN ALEXANDER USSERY/Examiner, Art Unit 2611
/DAVID T WELCH/Primary Examiner, Art Unit 2613
Prosecution Insights