DETAILED ACTION
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 .
This action is responsive to the communication filed 9/13/2023.
Claims 1-20 are presented for examination.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirely as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 9/13/2023. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 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 of this title, 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, 3, 5, 11, 14-15, 17-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bugenhagen (US 20190026144 A1) in view of Steben et al. (US 11606329 B1, hereafter Steben).
Regarding to claim 1, Bugenhagen discloses: An apparatus comprising:
at least one processing device comprising a processor coupled to a memory; the at least one processing device being configured (see Fig. 7 and [0086]-[0091]; “FIG. 7 provides a schematic illustration of one embodiment of a computer system 700 of the service provider system hardware that can perform the methods provided by various other embodiments, as described herein, and/or can perform the functions of computer or hardware system (i.e., host computing system 110), or of any other device (e.g., client device 145, etc.)”):
to maintain a register of interface endpoints for one or more external devices coupled to one or more physical hardware ports of one or more host devices and one or more virtual ports associated with one or more virtual devices running on one or more virtual computing instances (see [0022]-[0023]; “map, using the VM-to-port peripheral device driver, each of two or more VMs running on the host computing system with corresponding each of the two or more virtual ports associated with the physical port” and “when a client device is communicatively coupled to the physical port (or is determined to be communicatively coupled to the physical port) … map, using the VM-to-port peripheral device driver, each of the two or more VMs with one or more functions of the client device via corresponding each of the two or more virtual ports associated with the physical port to which the client device is communicatively coupled”. Note1: in order to perform the two mappings described at [0022]-[0023], the orchestration agent is required to maintain certain registers of the virtual and physical port endpoints. Note2: according to current claim language, the claimed virtual device is a broad term that does not have specific definition or further description, and thus such claimed virtual device under BRI is similar as host device, i.e., a combination of resources allocated to virtual machine);
to generate, in response to establishment of a given communication network enabling a given application running on a given one of the one or more virtual computing instances to consume data from a given one of the one or more external devices coupled to a given one of the one or more physical hardware ports of a given one of the one or more host devices, a given logical-to-physical mapping between (i) a given virtual identifier of a first interface endpoint in the register of interface endpoints associated with a given one of the one or more virtual ports associated with a given one of one or more virtual devices running on the given virtual computing instance and (ii) a given physical identifier of a second interface endpoint in the register of interface endpoints associated with the given external device coupled to the given physical hardware port of the given host device (see Figs. 2A, 4A, [0072]; “a client device 145 is communicatively coupled to a physical port 130 … map each of the two or more VMs 120 with one or more functions of the client device 145 via corresponding each of the two or more virtual ports 140 associated with the particular physical port 130 to which the client device 145 is communicatively coupled … allocate, to each of the two or more VMs 120, resource usage times for the client device 145 that is communicatively coupled to the particular physical port 130”. Mapping between a particular virtual port associated with a virtual machine and a particular physical port associated with a particular client/external device to allow the particular virtual machine to use the function of the particular client/external device, i.e., to allow the application of particular virtual machine to consume data of the particular external device. Note: although [0072] does not exactly describe the mapping is mapping identifier of the virtual port associated with virtual machine and identifier of the physical port associated with the particular client/external device; there are multiple virtual ports, multiple VMs, multiple physical ports and multiple client/external devices according to Fig. 4A, and thus the mapping discussed at [0072] is required to utilize the respective identifiers of the virtual ports and the respective identifiers of the physical ports in order to distinguish which virtual port is mapped to which physical port); and
to control exchange of data for the given communication network based at least in part on the given logical-to-physical mapping and one or more policies (see [0072]; “scheduling, using the VM-to-port peripheral device driver 135, time slices to each of the two or more VMs during which each VM can use resources associated with the client device that is communicatively coupled to the particular physical port”. Also see “In the non-limiting embodiment of FIG. 5A, each VM 120 a-120 n is provided with equal time slices of resource usage for the resources of the client device 145 (or resource usage for the resources of devices controlled by the shared client device 145) that repeat” and “each VM 120 a-120 n may be allocated a particular time slice of resource usage for the shared client device 145 (or resource usage for devices controlled by the shared client device 145), based on factors” from [0075]-[0076] for claimed “one or more policies” to control the usage of function of client/external device for particular virtual machine, i.e., control exchange of data).
Bugenhagen does not disclose: the given communication network is a service mesh.
However, Steben discloses: to generate, in response to establishment of a given service mesh enabling a given application running on a given one of the one or more virtual computing instances to consume data from a given one of the one or more external devices connected to a given one of the one or more host devices, a given [logical-to-physical] mapping between port associated with the given virtual computing instance and port associated with the given external device; (see lines 63-10 of cols 1-2, lines 46-9 of cols. 2-3; “a set of virtualized instances, containers, etc. may be deployed in a containerized environment, and may communicate with each other and/or devices or systems that are external to the containerized environment via a service mesh”, “Service mesh 105 may, for example, maintain a mapping of such identifiers, names, labels, etc. to Internet Protocol (“IP”) addresses, ports, or other types of identifiers that may be used to provide communication capability to namespaces 101 that implement respective service mesh proxies 107”, “Network 109 may be “external” to service mesh 105 and/or namespaces 101 inasmuch as communications via network 109 may utilize a different set of IP addresses (e.g., referred to as “public” IP addresses), ports, and/or other types of communication identifiers”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the generic communication network between virtual machines and external devices from Bugenhagen by including a service mesh between virtualized instances and external devices from Steben, and thus the combination of Bugenhagen and Steben would disclose the missing limitations from Steben, since “[A] service mesh in a virtualized and/or containerized environment may serve as an abstraction layer for one or more communication interfaces and/or pathways, such that an entity deploying, designing, implementing, etc. such virtualized instances or containers need not design or specifically implement such communication interfaces and/or pathways” (see lines 63-10 of cols 1-2 from Steben).
Regarding to Claim 3, the rejection of Claim 1 is incorporated and further the combination of Bugenhagen and Steben discloses: wherein the given virtual computing instance runs on the given host device (see Fig. 4A and [0070]-[0071] from Bugenhagen; “the multiple VMs running on the host computing system of the host device”).
Regarding to Claim 5, the rejection of Claim 1 is incorporated and further the combination of Bugenhagen and Steben discloses: wherein the given virtual computing instance comprises at least one of a virtual machine, a software container, and a microservice (see Fig. 4A and [0070]-[0071] from Bugenhagen and lines 63-10 of cols. 1-2 from Steben; “the multiple VMs running on the host computing system of the host device” and “a set of virtualized instances, containers, etc. may be deployed in a containerized environment, and may communicate with each other and/or devices or systems that are external to the containerized environment via a service mesh”).
Regarding to Claim 11, the rejection of Claim 1 is incorporated and further the combination of Bugenhagen and Steben discloses: wherein controlling the exchange of data on the given service mesh comprises controlling at least one of timing and multiplexing of data exchanged between the given application and the given external device (see [0072] and [0075]-[0076] from Bugenhagen; “scheduling, using the VM-to-port peripheral device driver 135, time slices to each of the two or more VMs during which each VM can use resources associated with the client device that is communicatively coupled to the particular physical port”, “each VM 120 a-120 n is provided with equal time slices of resource usage for the resources of the client device 145 (or resource usage for the resources of devices controlled by the shared client device 145) that repeat” and “each VM 120 a-120 n may be allocated a particular time slice of resource usage for the shared client device 145 (or resource usage for devices controlled by the shared client device 145), based on factors”).
Regarding to Claim 14, the rejection of Claim 1 is incorporated and further the combination of Bugenhagen and Steben discloses: wherein controlling the exchange of data on the given service mesh comprises performing device configuration for at least one of the given external device and the given virtual device running on the given virtual computing instance (see [0072] and [0075]-[0076] from Bugenhagen; “scheduling, using the VM-to-port peripheral device driver 135, time slices to each of the two or more VMs during which each VM can use resources associated with the client device that is communicatively coupled to the particular physical port”, “each VM 120 a-120 n is provided with equal time slices of resource usage for the resources of the client device 145 (or resource usage for the resources of devices controlled by the shared client device 145) that repeat” and “each VM 120 a-120 n may be allocated a particular time slice of resource usage for the shared client device 145 (or resource usage for devices controlled by the shared client device 145), based on factors”).
Note: current claimed “device configuration” is very broad, the resource usage and/or time slices allocation discussed at [0072] and [0075]-[0076] are reasonable to be considered as claimed device configuration under BRI.
Regarding to Claim 15, Claim 15 is a product claim corresponds to system Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above.
Regarding to Claim 17, the rejection of Claim 15 is incorporated and further Claim 17 is a product claim corresponds to system Claim 11 and is rejected for the same reason set forth in the rejection of Claim 11 above.
Regarding to Claim 18, Claim 18 is a method claim corresponds to system Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above.
Regarding to Claim 20, the rejection of Claim 18 is incorporated and further Claim 20 is a method claim corresponds to system Claim 11 and is rejected for the same reason set forth in the rejection of Claim 11 above.
Claims 2 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Bugenhagen (US 20190026144 A1) in view of Steben et al. (US 11606329 B1, hereafter Steben) and further in view of Smith et al. (US 20240205163 A1, hereafter Smith).
Regarding to Claim 2, the rejection of Claim 1 is incorporated, the combination of Bugenhagen and Steben does not discloses: wherein the given host device comprises an edge gateway device, and wherein the given external device comprises an Internet of Things (IoT) device.
However, Smith discloses: wherein the given host device comprises an edge gateway device, and wherein the given external device comprises an Internet of Things (IoT) device (see [0054] and [0136]; “The term “edge device” may be used herein to refer to a computing device that includes a programmable processor and communications circuitry for establishing communication links to consumer devices (e.g., smartphones, IoT devices, etc.) … an edge device may include or implement functionality associated with any one or all of an access point, gateway, modem, router, network switch, residential gateway”, “A single ECN (SE) may be the primary device in which applications and containers are deployed and executed. Each ECN may be a discrete unit in the orchestration process that is responsible for running specific applications or container”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the connection between virtual machine hosted within a host device and an external device connected to the host device from the combination of Bugenhagen and Steben by including the implementation of hosting container instances within an edge gateway device that connected to an external IoT device from Smith, and thus the combination of Bugenhagen, Steben and Smith would disclose the missing limitations from the combination of Bugenhagen and Steben, since “[A]n edge computing system may operate to combine the advantages of remote cloud servers and close-by edge devices to provide a powerful collaborative cloud and edge computing system that improves the performance, end-to-end latency, and/or energy consumption characteristics of user computing devices” (see [0055] from Smith. Also see [0005] [0053]-[0054] from Smith).
Regarding to Claim 13, the rejection of Claim 1 is incorporated, the combination of Bugenhagen and Steben does not disclose: wherein controlling the exchange of data on the given service mesh comprises: monitoring bandwidth usage by the given service mesh; generating at least one metric based at least in part on the monitored bandwidth usage; and modifying one or more bandwidth constraints for the given service mesh based at least in part on the generated at least one metric.
However, Smith discloses: wherein controlling the exchange of data on the given communication network comprises:
monitoring bandwidth usage by the given service communication network (see [0244]; “monitor the health and bandwidth of network connections to identify any data transmission bottlenecks or failures”);
generating at least one metric based at least in part on the monitored bandwidth usage (see [0245]; “the processor may evaluate a video streaming application's need for high bandwidth and low latency to ensure uninterrupted service. This may include analyzing data traffic patterns, video resolution demands, and expected user count to determine the necessary network bandwidth”); and
modifying one or more bandwidth constraints for the given communication network based at least in part on the generated at least one metric (see [0246]; “dynamically scale network resources based on the determined requirements, which may include adjusting capacity, bandwidth, and/or latency thresholds (or otherwise setting or modifying specific limits or parameters for capacity, bandwidth, and latency) that act as reference points or benchmarks that dictate how resources are allocated and managed within the network. For example, the processor may increase the bandwidth allocation for an ECN that is managing a sudden surge in video conferencing traffic during peak business hours”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the resource allocation mechanism from the combination of Bugenhagen and Steben by including the process of dynamic bandwidth allocation from Smith, and thus the combination of Bugenhagen, Steben and Smith would disclose the missing limitations from the combination of Bugenhagen and Steben, since it is understood that bandwidth is an important type of resource for data transmission process and network communication (see [0244] from Smith; “monitor the health and bandwidth of network connections to identify any data transmission bottlenecks or failures”).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Bugenhagen (US 20190026144 A1) in view of Steben et al. (US 11606329 B1, hereafter Steben) and further in view of Antony et al. (US 20160132358 A1, hereafter Antony).
Regarding to Claim 4, the rejection of Claim 1 is incorporated, the combination of Bugenhagen and Steben does not disclose: wherein the given virtual computing instance runs on another host device different than the given host device.
However, Antony discloses: wherein the given virtual computing instance runs on another host device different than the given host device (see Fig. 2, [0028]; “a request to access the peripheral device connected to the first host computing system is received from a VM running on a second host computing system”. Also see [0030]; “the VM is enabled to remotely access the peripheral device over the network”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the system of accessing or utilizing an external or peripheral device connected to a host device from a local virtual machine of the host device from the combination of Bugenhagen and Steben by including the system of accessing or utilizing an external or peripheral device connected to a host device from a remote virtual machine of another host device from Antony, and thus the combination of Bugenhagen, Steben and Antony would disclose the missing limitations from the combination of Bugenhagen and Steben, since it would provide a system to allow an enhanced usage of peripheral device from a remote virtual machine (see [0005] and [0016] from Antony; “Typically, when a peripheral device is attached to a first host computing system, the peripheral device is available only to VMs that run on the first host computing system and may not connect to VMs that run on other host computing systems in the datacenter”, “enables the VM to remotely access the peripheral device over a network”).
Claims 6-8, 16 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Bugenhagen (US 20190026144 A1) in view of Steben et al. (US 11606329 B1, hereafter Steben) and further in view of Purtell et al. (US 20080168479 A1, hereafter Purtell).
Regarding to Claim 6, the rejection of Claim 1 is incorporated, the combination of Bugenhagen and Steben does not discloses: wherein the given service mesh comprises a socket plane interface instantiated on the given host device enabling Transport Control Protocol (TCP)/Internet Protocol (IP) communications between a given virtual driver running on the given virtual computing instance and a given physical driver running on a host operating system of the given host device.
However, Purtell discloses: wherein the given communication network comprises a socket plane interface instantiated on the given host device enabling Transport Control Protocol (TCP)/Internet Protocol (IP) communications between a given virtual driver running on the given virtual computing instance and a given physical driver running on a host operating system of the given host device (see [0040]; “the VMM-emulated network between the guest OS and the host OS. A TCP/IP socket can connect the guest OS with the host OS”. Also see [0081]; “VM block I/O driver 310 c communicates directly with VMM 320 running on host OS 300, which translates the guest physical address into a host virtual address in the memory space of VMM 320. Finally, VMM 320 performs a real DMA transaction (through kernel interface 330 and block I/O driver 340 on the host OS) on behalf of application 310 a on the guest OS”. At one of the reasonable embodiments, the VM block I/O drivers 310 C uses TCP/IP socket discussed at [0040] to connect with the block I/O driver 340).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the communication between virtual machine and host operating system from the combination of Bugenhagen and Steben by including communication between virtual machine and host operating system via a TCP/IP socket from Purtell, and thus the combination of Bugenhagen, Steben and Purtell would disclose the missing limitations from the combination of Bugenhagen and Steben, since it socket is one of the well-known message passing components implemented by VMM to achieve communication between guest and host (see [0040] from Purtell).
Regarding to Claim 7, the rejection of Claim 6 is incorporated and further the combination of Bugenhagen, Steben and Purtell discloses: wherein the socket plane interface is distinct from a physical device interface utilized for communication between the given external device and the given physical driver (see [0023] from Bugenhagen and [0040] from Purtell; “when a client device is communicatively coupled to the physical port (or is determined to be communicatively coupled to the physical port)” and “the VMM-emulated network between the guest OS and the host OS. A TCP/IP socket can connect the guest OS with the host OS”. Note: the interface used TCP/IP socket is used to connect the guest/virtual machine with the host while the physical port or physical interface is used to connect the host with an external device, based on such difference or point of view, these two interfaces are already distinct from each other (even if both of they use same communication protocol/technology)).
Regarding to Claim 8, the rejection of Claim 7 is incorporated and further the combination of Bugenhagen, Steben and Purtell discloses: wherein the physical device interface comprises at least one of a serial interface, a General Purpose Input/Output (GPIO) interface, a sensor interface, a lab card interface, a video interface, and an audio interface (see [0071] from Bugenhagen; “The one or more client devices 145 … might include, without limitation … a universal serial bus (“USB”) pluggable device, and/or the like. The client device, according to some embodiments, can be any physical device that can be plugged into a specific port”. At certain reasonable embodiment, the client/external device is a USB pluggable device to be plugged into a USB port of the host device, and thus the physical device interface is a serial interface).
Regarding to Claim 16, the rejection of Claim 15 is incorporated and further Claim 16 is a product claim corresponds to system Claim 6 and is rejected for the same reason set forth in the rejection of Claim 6 above.
Regarding to Claim 19, the rejection of Claim 18 is incorporated and further Claim 19 is a method claim corresponds to system Claim 6 and is rejected for the same reason set forth in the rejection of Claim 6 above.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Bugenhagen (US 20190026144 A1) in view of Steben et al. (US 11606329 B1, hereafter Steben) and further in view of Koskinen et al. (US 20210221642 A1, hereafter Koskinen).
Regarding to Claim 9, the rejection of Claim 1 is incorporated, the combination of Bugenhagen and Steben does not disclose: wherein maintaining the register of interface endpoints comprises automating onboarding and removal of interface endpoints in response to detection of coupling and decoupling of the one or more external devices to and from the one or more physical hardware ports of the one or more host devices.
However, Koskinen discloses: wherein maintaining the register of interface endpoints comprises automating onboarding and removal of interface endpoints in response to detection of coupling and decoupling of the one or more external devices to and from the one or more physical hardware ports (see [0046]; “each time the switch detects in step 301 that a peripheral device is connected to a port of the switch or disconnected from a port of the switch, the switch creates in step 302 an update message, or any corresponding message, that lists, port by port, identifiers of those devices that are connected to the switch”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the management of external device connections from the combination of Bugenhagen and Steben by including updating information indicating connected external devices from Koskinen, and thus the combination of Bugenhagen, Steben and Koskinen would disclose the missing limitations from the combination of Bugenhagen and Steben, since it would provide a mechanism of providing updated information indicating all of connected external devices (see [0046] from Koskinen).
Claims 10 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Bugenhagen (US 20190026144 A1) in view of Steben et al. (US 11606329 B1, hereafter Steben) and further in view of Lakshmanan et al. (US 20170149694 A1, hereafter Lakshmanan).
Regarding to Claim 10, the rejection of Claim 1 is incorporated, the combination of Bugenhagen and Steben does not disclose: wherein controlling the exchange of data on the given service mesh comprises performing event-based queuing of commands exchanged between the given application and the given external device.
However, Lakshmanan discloses: wherein controlling the exchange of data on the given communication network comprises performing event-based queuing of commands exchanged between the given application and the given external device (see [0020], [0023]-[0024]; “To support the transfer of transmit packets from vNIC 122(1) to pNIC 112 via transmit buffer TB, vNIC 221(1) includes a configurable transmit descriptor 320T (also referred to as a “Virtio transmit ring”) … the transmit packet has been loaded into the corresponding packet slot. Transmit descriptor 320T may be implemented as a Virtio virtual queue”, “In a receive direction, pNIC 112 (e.g., VF 204(1)) transfers receive packets (i.e., packets received at the pNIC form some external device) to virtual machine VM1 through vNIC 122(1)” and “Similarly, vNIC 122(1) includes a configurable receive descriptor 320R (referred to as a “Virtio receive ring”) having sequential descriptor entries 322R(1)-322R(f) for respective receive pointers to the receive packets loaded into receive buffer RB by pNIC 112”. Using the ring queue for transmitting and receiving packets exchanged between the virtual machine and the external device).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the system of data communication between an external device and a virtual machine from the combination of Bugenhagen and Steben by including the packet transition and receiving between vNIC associated with virtual machine and pNIC at host level from Lakshmanan, and thus the combination of Bugenhagen, Steben and Lakshmanan would disclose the missing limitations from the combination of Bugenhagen and Steben, since it would provide specific data flows between vNIC or virtual port and pNIC or physical port to achieve data exchange between virtual machine and external device (see [0019]-[0024] from Lakshmanan).
Regarding to Claim 12, the rejection of Claim 11 is incorporated, the combination of Bugenhagen and Steben does not disclose: wherein controlling said at least one of the timing and the multiplexing of the data that is exchanged between the given application and the given external device comprises at least one of managing handshaking between the given application and the given external device, performing flow control for one or more data flows established between the given application and the given external device, management of start and stop bits for the one or more data flows, and interrupt handling for the one or more data flows.
However, Lakshmanan discloses: wherein controlling said at least one of the timing and the multiplexing of the data that is exchanged between the given application and the given external device comprises at least one of managing handshaking between the given application and the given external device, performing flow control for one or more data flows established between the given application and the given external device, management of start and stop bits for the one or more data flows, and interrupt handling for the one or more data flows (see [0019]-[0024]; “In a transmit direction, virtual machine VM1 transfers packets to pNIC 112 using vNIC 122(1)” and “In a receive direction, pNIC 112 (e.g., VF 204(1)) transfers receive packets (i.e., packets received at the pNIC form some external device) to virtual machine VM1 through vNIC 122(1)”. The details of transmit direction and receive direction discussed at [0019]-[0024] can be considered as claimed limitation of “performing flow control for one or more data flows established between the given application and the given external device”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the system of data communication between an external device and a virtual machine from the combination of Bugenhagen and Steben by including the packet transition and receiving between vNIC associated with virtual machine and pNIC at host level from Lakshmanan, and thus the combination of Bugenhagen, Steben and Lakshmanan would disclose the missing limitations from the combination of Bugenhagen and Steben, since it would provide specific data flows between vNIC or virtual port and pNIC or physical port to achieve data exchange between virtual machine and external device (see [0019]-[0024] from Lakshmanan).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Qin et al. (US 20180302325 A1) discloses: acquiring, by a switch in a physical host, data to be sent to a destination node external to the physical host; acquiring, by the switch in the physical host, a sending virtual network interface card (NIC) port used to receive the data; determining, by the switch in a physical host, a physical NIC port based on a second mapping table, wherein the second mapping table comprises a correspondence between virtual NIC ports and physical NIC ports; and sending the data outside the physical host using a physical NIC corresponding to the physical NIC port (see claim 1).
Jung et al. (US 20230007080 A1) discloses: When a user requests a service through docker-cli 910, a request may be transferred to the Ethernet driver 940 through the socket layer 920 and the TCP/IP layer 930. A request may be transferred from the Ethernet driver 940 to the docker-cli 910 through the TCP/IP layer 930 and the socket layer 920 (see Fig. 9 and [0091]).
Lee et al. (US 20170031697 A1) discloses: the host operating system 110 and the guest operating system 120 may communicate with each other through a TCP/IP network socket (see [0066]).
Brandwine (US 9825911 B1) discloses: Attempts to establish a communication session between an external computing system (e.g., computing system 145a) and an internal virtual machine or computing system (e.g., virtual machines 107a-d, computing system 155a-n) may include at least one packet of a multi-packet handshake protocol to pass through the NAT 16 (see lines 59-4 of cols 7-8).
Sakata et al. (US 20140064056 A1) discloses: when receiving a path change request and a via link request to request a via link with respect to the specified flow from an external terminal, the control part selects either one of addresses of an address pair of the specified flow as a change target address; and when changing the selected change target address, the control part changes the change target address to a candidate address to be assigned by selecting an address, which is routed through a link included in the via link request and has not been assigned, as the candidate address to be assigned (see [0012]).
Kumar et al. (US 20230134657 A1) discloses: Circuitry coupled to an external device is to receive an interrupt request from the external device for the guest user application, locate a first interrupt data structure associated with the guest user application, generate a first interrupt with the first interrupt data structure based on a first interrupt vector for the interrupt request, locate a second interrupt data structure associated with the virtual CPU, and generate a first notification interrupt for the virtual CPU with the second interrupt data structure based on a first notification vector in the first interrupt data structure (see abstract).
Fatzer et al. (US 20150293878 A1) discloses: The aligned byte data 807 includes payload data (the command coming from the motherboard 110, which contains the command that will control the endpoint device 710) as well as control characters (which are the protocol level parts of the data packet that includes, for example start and stop bits, etc.) for flow control (to control the transfer of data) and packet alignment 805 (see [0034]).
Rupp et al. (US 20100023795 A1) discloses: A stop bit 100 and a start bit 102 of second synchronization block 94 are additionally shown in the enlarged illustration of data flow 82 in the lower region of FIG. 6 (see [0053]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHI CHEN whose telephone number is (571)272-0805. The examiner can normally be reached on M-F from 9:30AM to 5:30PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on 571-270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Zhi Chen/
Patent Examiner, AU2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196