DETAILED ACTION
This office action is in response to the application filed on 1/26/2024 in which claims 1-15 are pending.
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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
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.
Claim(s) 1, 4-8, and 11-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over MA (US20170346680A1) in view of Kutch et al. (US20230319133A1).
As to claims 1, and 8, MA teaches a method for cross-card link aggregation of virtual function ports of data processing units, wherein each of the data processing units is communicatively connected to a virtual machine and a switch respectively, the method comprising: (Fig. 1-3 [0045] For link aggregation control management of VFs in the VM environment, a method for implementing negotiation management among guest OSs, the VFs, a host OS and PFs is required. [0061] In the schematic diagram shown in FIG. 3, the host of the server is connected with two switch ports PA and PB of an external switch by virtue of two NICs in an LACP manner. The ports are managed through the LACP, and the two NICs run in an aggregation group manner.)
performing link negotiation for the virtual machine and the switch respectively; ([0045] For link aggregation control management of VFs in the VM environment, a method for implementing negotiation management among guest OSs, the VFs, a host OS and PFs is required [0061] The PF1 and the PF2 form an LACP aggregation group, and this aggregation group completes LACP negotiation with the external switch through the physical machine.[0065] In the schematic diagram shown in FIG. 5, the host OS and the guest OSs establish heartbeat handshake links through shared communication queues, and synchronize PF and VF aggregation states through the links.)
determining a communication link for the to-be-communicated data message, wherein the communication link is a message channel between a virtual function port in the virtual machine, a virtual function port representor corresponding to the virtual function port in the virtual machine, an uplink corresponding to a physical port in the data processing unit, the physical port in the data processing unit, and the switch; and performing communication for the to-be-communicated data message based on the communication link. ([0063] FIG. 4 is a schematic diagram of an LACP control flow and a VM service flow in a connection relationship shown in FIG. 3 according to an exemplary embodiment of the invention. [0064] From the schematic diagram shown in FIG. 4, it can be seen that the host still runs the LACP. The VMs perform data transmission without hardware improvement by virtue of the VFs provided by the NICs, and an existing hardware structure is maintained. [0065] FIG. 5 is a schematic diagram of implementation of information interaction between a host and VMs in a connection relationship through a shared communication queue of an NIC shown in FIG. 3 according to an exemplary embodiment of the invention.)
But MA does not specifically teach:
acquiring a to-be-communicated data message which comprises a destination identifier, a source identifier, and a message type;
However Kutch teaches acquiring a to-be-communicated data message which comprises a destination identifier, a source identifier, and a message type; ([0022] A packet flow to be controlled can be identified by a combination of tuples (e.g., Ethernet type field, source and/or destination IP address, source and/or destination User Datagram Protocol (UDP) ports, source/destination TCP ports, or any other header field) and a unique source and destination queue pair (QP) number or identifier. [0035] FIG. 1B depicts an example network interface device system. Various examples of packet processing device or data plane circuitry 110 can utilize components of the system of examples described herein. In some examples, packet processing device or network interface device can refer to one or more of: a network interface controller (NIC), a remote direct memory access (RDMA)-enabled NIC, SmartNIC, router, switch, forwarding element, infrastructure processing unit (IPU), or data processing unit (DPU).)
It would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the system of MA with the system of Kutch in order to provide services to a specific destination.
As to claims 4 and 11, MA in view of Kutch teaches the method according to claim 1, wherein the to-be-communicated data message comprises at least one of: a first data message transmitted from the virtual machine or a second data message transmitted from the switch. (MA fig. 4 shows the service data flow from the switch or VM going to the VM or the switch in either direction)
As to claims 5, 12, and 15, Ma in view of Kutch teaches the method according to claim 1, wherein the acquiring the to-be-communicated data message comprises: transmitting the to-be-communicated data message to the virtual switch through the virtual function port representor corresponding to the virtual function port in the virtual machine; or transmitting the to-be-communicated data message to the virtual switch through the uplink corresponding to the physical port in the data processing unit; and obtaining the to-be-communicated data message based on the virtual switch. (MA fig. 4 shows the service data flow from the switch or VM going to the VM or the switch in either direction)
As to claims 6 and 13, Ma in view of Kutch teaches the method according to claim 1, wherein the determining the communication link for the to-be-communicated data message comprises: acquiring a correspondence between a preset destination identifier and a preset communication link; and determining a communication link corresponding to the destination identifier in the to-be-communicated data message from the correspondence. (Kutch [0022] A flow can be a sequence of packets being transferred between two endpoints, generally representing a single session using a protocol. Accordingly, a flow can be identified, using a match, by a set of defined tuples and, for routing purpose, a flow is identified by the two tuples that identify the endpoints, e.g., the source and destination addresses. [0023] For example, ACC 120 can execute a virtual switch such as vSwitch or Open vSwitch (OVS), Stratum, or Vector Packet Processing (VPP) that provides communications between virtual machines executed by host 200 or with other devices connected to a network. For example, ACC 120 can configure packet processing pipeline circuitry 140 as to which VM is to receive traffic and what kind of traffic a VM can transmit. For example, packet processing pipeline circuitry 140 can execute a virtual switch such as vSwitch or Open vSwitch that provides communications between virtual machines executed by host 100 and packet processing device 110. [0025] One or both control planes of ACC 120 and MCC 130 can define traffic routing table content and network topology applied by packet processing circuitry 140 to select a path of a packet in a network to a next hop or to a destination network-connected device. For example, a VM executing on host 100 can utilize packet processing device 110 to receive or transmit packet traffic.)
It would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the system of MA with the system of Kutch in order to provide services to a specific destination.
As to claims 7 and 14, MA in view of Kutch teaches the method according to claim 1, wherein the performing communication for the to-be-communicated data message based on the communication link comprises: acquiring the destination identifier from the to-be-communicated data message based on the virtual switch; and forwarding the to-be-communicated data message through the communication link to a destination corresponding to the destination identifier based on the virtual switch. (Kutch [0022] A flow can be a sequence of packets being transferred between two endpoints, generally representing a single session using a protocol. Accordingly, a flow can be identified, using a match, by a set of defined tuples and, for routing purpose, a flow is identified by the two tuples that identify the endpoints, e.g., the source and destination addresses. [0023] For example, ACC 120 can execute a virtual switch such as vSwitch or Open vSwitch (OVS), Stratum, or Vector Packet Processing (VPP) that provides communications between virtual machines executed by host 200 or with other devices connected to a network. For example, ACC 120 can configure packet processing pipeline circuitry 140 as to which VM is to receive traffic and what kind of traffic a VM can transmit. For example, packet processing pipeline circuitry 140 can execute a virtual switch such as vSwitch or Open vSwitch that provides communications between virtual machines executed by host 100 and packet processing device 110. [0025] One or both control planes of ACC 120 and MCC 130 can define traffic routing table content and network topology applied by packet processing circuitry 140 to select a path of a packet in a network to a next hop or to a destination network-connected device. For example, a VM executing on host 100 can utilize packet processing device 110 to receive or transmit packet traffic.)
It would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the system of MA with the system of Kutch in order to provide services to a specific destination.
Allowable Subject Matter
Claims 2-3 and 9-10 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ELTON S WILLIAMS whose telephone number is (571)272-9933. The examiner can normally be reached 8-4 Mon-Fri.
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, Gary Mui can be reached at (571) 270-1420. 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.
/Elton Williams/Examiner, Art Unit 2465
Prosecution Insights