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 .
Status of Claims:
Claims 1-20 are pending in Instant Application.
Priority
Examiner acknowledges Applicant’s claim to the priority benefit of U.S. Application No. 18/149,924, filed 01/04/2023, which claims the priority benefit of U.S. Provisional Application No. 63/328,619, filed 04/07/2022.
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.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-21 of U.S. Patent No. 12,309,070. Although the claims at issue are not identical, they are not patentably distinct from each other because they are drawn to obvious variations.
Claims of Instant Application
Claims of U.S. Patent No. 12,309,070
Reasons
1. A method, comprising: identifying messages that share a context created by a source application program; aggregating the identified messages for inclusion in a single packet; constructing the single packet including the aggregated identified messages and an identifier for the context, wherein the identifier references properties and the properties are stored, by the source application program, at each destination endpoint that participates in the context; and transmitting the single packet within a network, wherein the properties are irrelevant for routing the single packet through switches within the network.
1. A computer-implemented method, comprising: identifying messages that share a context created by a source application program; aggregating the identified messages for inclusion in a single packet; constructing the single packet including the aggregated identified messages and an identifier for the context, wherein the identifier references properties needed by a destination endpoint to interpret at least one of the identified messages in the single packet and the properties are stored, by the source application program, at each destination endpoint that participates in the context; extracting, at a switch within a network, a first message and a second message of the aggregated identified messages from the single packet, wherein the properties are irrelevant for routing the single packet through the switch; transmitting the first message and the identifier towards a first destination endpoint; and transmitting the second message and the identifier towards a second destination endpoint.
Patented claim 1 recites every limitation of Instant claim 1. Patented claim 1 recites additional limitations, which make the patented claim 1 narrower.
2. The method of claim 1, further comprising receiving at least one of the identified messages at a first destination endpoint within the network; and accessing, by the first destination endpoint, the properties using the identifier.
2. The computer-implemented method of claim 1, further comprising: receiving the first message at the first destination endpoint; and using the identifier, accessing the properties stored in a table within the first destination endpoint.
Patented claim 2 recites every limitation of instant claim 2 and is narrower.
3. The method of claim 2, wherein the properties are needed by the first destination endpoint to interpret at least one of the identified messages in the single packet.
1
Patented claim 1 recites the same limitation.
4. The method of claim 2, wherein the properties comprise at least one of a number of processes in a collective, a location where at least one of the identified messages will be stored, or attributes associated with reliability, ordering, atomicity, or data type.
4. The computer-implemented method of claim 1, wherein the properties comprise at least one of a number of processes in a collective, a location where at least one of the identified messages will be stored, or attributes associated with reliability, ordering, atomicity, or data type.
Same limitations.
5. The method of claim 1, further comprising: extracting, at a switch within the network, a first message and a second message of the aggregated identified messages from the single packet; transmitting the first message towards a first destination endpoint; and transmitting the second message towards a second destination endpoint.
1
Patented claim 1 recites the same limitation.
6. The method of claim 5, wherein the first message is aggregated with other messages identified as sharing the context and included in a second packet constructed at the switch.
5. The computer-implemented method of claim 1, wherein the first message is aggregated with other messages identified as sharing the context and included in a second packet constructed at the switch.
Same limitations.
7. The method of claim 1, wherein the single packet is constructed in response to determining that either a timer expired or a maximum number of the identified messages are aggregated.
6. The computer-implemented method of claim 1, wherein the single packet is constructed in response to determining that either a timer expired or a maximum number of the identified messages are aggregated.
Same limitations.
8. The method of claim 7, wherein at least one of the timer and the maximum number is adjusted as a processing workload changes.
7. The computer-implemented method of claim 6, wherein at least one of the timer and the maximum number is adjusted as a processing workload changes.
Same limitations.
9. The method of claim 7, wherein the maximum number corresponds to the context and a second maximum number corresponds to an additional context.
8. The computer-implemented method of claim 6, wherein the maximum number corresponds to the context and a second maximum number corresponds to an additional context.
Same limitations.
10. The method of claim 1, wherein the single packet is constructed in response to determining that an aggregation buffer is not available for an additional context.
9. The computer-implemented method of claim 1, wherein the single packet is constructed in response to determining that an aggregation buffer is not available for an additional context.
Same limitations.
11. The method of claim 1, wherein constructing the single packet comprises encoding a common portion of addresses of destination endpoints for the aggregated identified messages into the single packet.
10. The computer-implemented method of claim 1, wherein constructing the single packet comprises encoding a common portion of addresses of destination endpoints for the aggregated identified messages into the single packet.
Same limitations.
12. The method of claim 1, wherein constructing the single packet comprises encoding a next hop for the aggregated identified messages into the single packet.
12. The computer-implemented method of claim 1, wherein constructing the single packet comprises encoding a next hop for the aggregated identified messages into the single packet.
Same limitations.
13. The method of claim 1, wherein at least one of the steps of identifying, aggregating, constructing, or transmitting is performed on a server or in a data center to generate content that is streamed to a user device.
13. The computer-implemented method of claim 1, wherein at least one of the steps of identifying, aggregating, and constructing is performed on a server or in a data center to generate content that is streamed to a user device.
Similar limitations.
14. The method of claim 1, wherein at least one of the steps of identifying, aggregating, constructing, or transmitting is performed within a cloud computing environment.
14. The computer-implemented method of claim 1, wherein at least one of the steps of identifying, aggregating, and constructing is performed within a cloud computing environment.
Similar limitations.
15. The method of claim 1, wherein at least one of the steps of identifying, aggregating, constructing, or transmitting is performed for training, testing, or certifying a neural network employed in a machine, robot, or autonomous vehicle.
15. The computer-implemented method of claim 1, wherein at least one of the steps of identifying, aggregating, and constructing is performed for training, testing, or certifying a neural network employed in a machine, robot, or autonomous vehicle.
Similar limitations.
16. The method of claim 1, wherein at least one of the steps of identifying, aggregating, constructing, or transmitting is performed on a virtual machine comprising a portion of a graphics processing unit.
16. The computer-implemented method of claim 1, wherein at least one of the steps of identifying, aggregating, and constructing is performed on a virtual machine comprising a portion of a graphics processing unit.
Similar limitations.
17
17
Same reasoning as explained above in claim 1.
18
17
Same reasoning as explained above in claim 3.
19
20
Same reasoning as explained above in claim 1.
20. The method of claim 19, wherein the properties comprise at least one of a number of processes in a collective, a location where at least one of the identified messages will be stored, or attributes associated with reliability, ordering, atomicity, or data type.
4
Same reasoning as explained above in claim 4.
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 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 7-13, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Makineni et al. (U.S. Publication No. 2006/0104303), in view of Westberg (U.S. Publication No. 2003/0198226), and further in view of Craddock et al. (U.S. Publication No. 2003/0035433).
As per claim 1, Makineni discloses a method, comprising:
identifying messages that share a context created by a source application program (Makineni: paragraphs 0002-0003; TCP provides applications with simple mechanisms for creating a flow…The payload of a TCP segment carries a portion of a data stream sent across a network by an application...paragraphs 0009-0012; A packet's flow can be identified by the controller 100 by data within the header(s). For example, a TCP/IP flow can be identified by a tuple formed by a combination of the IP source and destination addresses and the source and destination port numbers in the TCP header. A tuple may not include all of these header fields and may include other information (e.g., a protocol identifier));
aggregating the identified messages for inclusion in a single packet (Makineni: paragraphs 0012-0013; In FIG. 1A, the controller 100 stores the received packet's 106 header 106a and payload 106b for potential coalescing with subsequently received packets…In FIG. 1B, the controller 100 receives a second packet 108 that belongs to the same flow ("1") as the packet received in FIG. 1A. Instead of simply writing the packet memory 102, the controller 100 combines the two payloads 106b, 108b of the packets 106, 108 together into a monolithic payload 110b);
constructing the single packet including the aggregated identified messages (Makineni: paragraph 0014; In addition to collecting the different payloads, the controller 100 also prepares a single IP header and a single TCP header 110a for the coalesced packet 110 that reflects the combined TCP payloads 110b. For example, the controller 100 may look-up TCP/IP headers 106a associated with the flow and modify the IP header's length field to reflect the length of the combined payloads).
However Makineni does not explicitly mention an identifier for the context; and
transmitting the single packet within a network.
However Westberg teaches:
an identifier for the context (Westberg: paragraphs 0011, 0016, 0018-0021, 0032-0033; the present invention uses a header compression technique in which the header overhead reduction comes from the observation that although several +fields change in every packet, the difference from packet to packet is often constant and therefore the second-order difference is zero…a session context is defined by the combination of the IP source and destination addresses, the UDP source and destination ports, and the RTP SSRC field. The compressed packet carries a small integer, called the session context identifier or CID, to indicate in which session context that packet should be interpreted. The decompressor can use the CID to index its table of stored session contexts directly. See also Makineni, paragraph 0011; flow identification by tuple including IP source and destination addresses); and
transmitting the single packet within a network (Westberg: paragraph 0042; the datagram segment is then forwarded to the outgoing port).
Therefore it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Westberg with the teachings as in Makineni. The motivation for doing so would have been for header overhead reduction (Westberg: paragraph 0011).
Westberg teaches that the compressed packet carries a small integer, called the session context identifier or CID, to indicate in which session context that packet should be interpreted. The decompressor can use the CID to index its table of stored session contexts directly, see at least paragraph 0033.
However Makineni and Westberg do not explicitly mention the properties are stored, by the source application program, at each destination endpoint that participates in the context, and wherein the properties are irrelevant for routing the single packet through switches within the network.
However Craddock teaches:
wherein the identifier references properties and the properties are stored, by the source application program, at each destination endpoint that participates in the context (Westberg: paragraph 0033; The compressed packet carries a small integer, called the session context identifier or CID, to indicate in which session context that packet should be interpreted. The decompressor can use the CID to index its table of stored session contexts directly. See also Craddock: paragraph 0083; End-to-end (EE) contexts maintain end-to-end specific state to keep track of sequence numbers, acknowledgments, and time-out values. The end-to-end state held in the EE contexts is shared by all the connectionless queue pairs communication between a pair of endnodes. Each endnode requires at least one EE context for every endnode it wishes to communicate with in the reliable datagram service (e.g., a given endnode requires at least N EE contexts to be able to have reliable datagram service with N other endnodes)); and
wherein the properties are irrelevant for routing the single packet through switches within the network (Craddock: paragraph 0083; End-to-end (EE) contexts maintain end-to-end specific state to keep track of sequence numbers, acknowledgments, and time-out values…paragraphs 0085-0086, and 0100; For packets destined to a channel adapter (either host or target), the data packets are neither generated nor consumed by the switches and routers in the SAN fabric. Instead for data packets that are destined to a channel adapter, switches and routers simply move request packets or acknowledgment packets closer to the ultimate destination, modifying the variant link header fields in the process. Routers, also modify the packet's network header when the packet crosses a subnet boundary. In traversing a subnet, a single packet stays on a single service level…Routing header 716 is used to identify source and destination ports for data packet 712. Transport header 718 in this example specifies the destination queue pair for data packet 712…A switch within a subnet examines the DLID that is unique within the subnet to permit the switch to quickly and efficiently route incoming message packets).
Therefore it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Craddock with the teachings as in Makineni and Westberg. The motivation for doing so would have been to maintain end-to-end specific state to keep track of sequence numbers, acknowledgments, and time-out values and to permit the switch to quickly and efficiently route incoming message packets (Craddock: paragraphs 0083 and 0100).
As per claim 2, the modified Makineni teaches the method of claim 1, further comprising receiving at least one of the identified messages at a first destination endpoint within the network; and accessing, by the first destination endpoint, the properties using the identifier (Westberg: paragraphs 0021, 0033, 0041-0042; CID value looked up on CID table to identify context).
The same motivation to combine as the independent claim applies here.
As per claim 3, the modified Makineni teaches the method of claim 2, wherein the properties are needed by the first destination endpoint to interpret at least one of the identified messages in the single packet (Westberg: paragraph 0033; The compressed packet carries a small integer, called the session context identifier or CID, to indicate in which session context that packet should be interpreted. The decompressor can use the CID to index its table of stored session contexts directly).
The same motivation to combine as the independent claim applies here.
As per claim 4, the modified Makineni teaches the method of claim 2, wherein the properties comprise at least one of a number of processes in a collective, a location where at least one of the identified messages will be stored, or attributes associated with reliability, ordering, atomicity, or data type (Makineni: paragraph 0020; flow id, which itself is at least one of a number of processes. Address of payload or header buffer, which is a location. Priority, which is an attribute associated with reliability. Sequence and checksum numbers, which are attributes associated with ordering and atomicity. See also Westberg: paragraph 0009; payload type identification).
As per claim 7, the modified Makineni teaches the method of claim 1, wherein the single packet is constructed in response to determining that either a timer expired or a maximum number of the identified messages are aggregated (Makineni: paragraphs 0015-0016; The number of packets coalesced and/or the period of time to coalesce packets may be configurable. For example, typically, network interface controllers use a technique known as interrupt moderation to batch signaling of packets received in some window of time. The controller 100 can use the interrupt moderation window to coalesce as many packets of a flow as possible. To allow for coalescing overhead (e.g., header preparation), the controller 100 may use a window of time (coalescing window) smaller than the interrupt moderation window to coalesce packets).
As per claim 8, the modified Makineni teaches the method of claim 7, wherein at least one of the timer and the maximum number is adjusted as a processing workload changes (Westberg: paragraph 0015; system may compress to allow real-time packets to interrupt non-real-time packets, which is an adjustment in the batching process based on type of workload).
The same motivation to combine as the independent claim applies here.
As per claim 9, the modified Makineni teaches the method of claim 7, wherein the maximum number corresponds to the context and a second maximum number corresponds to an additional context (Makineni: Fig. 1C, paragraph 0016, Claim 10; System may track multiple flows, which means that there are multiple maximum contexts. See also paragraph 0016; The number of packets coalesced and/or the period of time to coalesce packets may be configurable).
As per claim 10, the modified Makineni teaches the method of claim 1, wherein the single packet is constructed in response to determining that an aggregation buffer is not available for an additional context (Makineni: paragraph 0016; During the coalescing window, the controller 100 obtains a descriptor for flows that receive data during the coalescing window (e.g., by dequeuing a descriptor provided by a controller 100 device driver) and, generally, retains the descriptor until either the coalescing window expires or the controller 100 receives a flow packet that does not meet coalescing criteria (described below), or the size of the payload exceeds the available space in the packet buffer identified by the descriptor).
As per claim 11, the modified Makineni teaches the method of claim 1, wherein constructing the single packet comprises encoding a common portion of addresses of destination endpoints for the aggregated identified messages into the single packet (Westberg: paragraph 0033; In RFC 2508, a session context is defined by the combination of the IP source and destination addresses, the UDP source and destination ports, and the RTP SSRC field. The compressed packet carries a small integer, called the session context identifier or CID, to indicate in which session context that packet should be interpreted. The decompressor can use the CID to index its table of stored session contexts directly. Under this arrangement, the compression protocol maintains a collection of shared information in a consistent state between the compressor and decompressor. See also Makineni: paragraph 0011; a TCP/IP flow can be identified by a tuple formed by a combination of the IP source and destination addresses and the source and destination port numbers in the TCP header).
The same motivation to combine as the independent claim applies here.
As per claim 12, the modified Makineni teaches the method of claim 1, wherein constructing the single packet comprises encoding a next hop for the aggregated identified messages into the single packet (Westberg: paragraphs 0036-0037; CID is used to determine next hop. Therefore writing the CID in the compressed header is encoding a next hop).
The same motivation to combine as the independent claim applies here.
As per claim 13, the modified Makineni teaches the method of claim 1, wherein at least one of the steps of identifying, aggregating, constructing, or transmitting is performed on a server or in a data center to generate content that is streamed to a user device (Makineni: paragraph 0008; desktop applications including streaming media players. Server applications for web and file servers. See also Westberg, paragraphs 0009, 0016, 0034; voice or video streaming).
With respect to claim 17, it is substantially similar to claim 1 and is rejected in the same manner, the same art and reasoning applying. Further, Makineni also teaches a system, comprising: a processor that is connected to a network (Makineni: paragraph 0009; processor and NIC which connects device to network), wherein the processor executes a source application program (paragraph 0019; the circuitry 206 may feature a programmable engine that executes instructions to process the packets).
Regarding claim 18, it is substantially similar to claim 3, and is rejected in the same manner, the same arts and reasoning applying.
With respect to claim 19, it is substantially similar to claim 1 and is rejected in the same manner, the same art and reasoning applying. Further, Makineni also teaches a method for operation of a device connected to a network, wherein a plurality of source endpoints and a plurality of destination endpoints are coupled to the network, and wherein a message includes a payload that is associated with a context of one or more contexts created by a source application program (Makineni: paragraphs 0002-0003; Transmission Control Protocol (TCP) provides applications with simple mechanisms for establishing a flow and transferring data across a network…The payload of a TCP segment carries a portion of a stream of data sent across a network by an application…paragraphs 0009-0013; A packet's flow can be identified by the controller 100 by data within the header(s)… the controller 100 receives a second packet 108 that belongs to the same flow ("1") as the packet received in FIG. 1A. See also Craddock: paragraph 0083; The end-to-end state held in the EE contexts is shared by all the connectionless queue pairs communication between a pair of endnodes. Each endnode requires at least one EE context for every endnode it wishes to communicate with in the reliable datagram service).
The same motivation to combine as Claim 1 applies here.
Regarding claim 20, it is substantially similar to claim 4, and is rejected in the same manner, the same arts and reasoning applying.
Claims 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over Makineni et al. (U.S. Publication No. 2006/0104303), in view of Westberg (U.S. Publication No. 2003/0198226), in view of Craddock et al. (U.S. Publication No. 2003/0035433), and further in view of Boivie (U.S. Patent No. 7,079,501).
As per claim 5, the modified Makineni teaches the method of claim 1.
However the modified Makineni does not explicitly teach extracting, at a switch within the network, a first message and a second message of the aggregated identified messages from the single packet; transmitting the first message towards a first destination endpoint; and transmitting the second message towards a second destination endpoint.
However Boivie teaches:
teach extracting, at a switch within the network, a first message and a second message of the aggregated identified messages from the single packet; transmitting the first message towards a first destination endpoint; and transmitting the second message towards a second destination endpoint (Boivie: col. 8, line 36 to col. 9, line 7; router receives an aggregated packet with two destinations, extracts and formats messages for each of the endpoints, and transmits the packets).
Therefore it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Boivie with the teachings as in the modified Makineni. The motivation for doing so would have been in order to allow a server to handle more requests without increasing the actual bandwidth of a connection between the server and the Internet (Boivie: col. 1, lines 43-46).
As per claim 6, the modified Makineni teaches the method of claim 5, wherein the first message is aggregated with other messages identified as sharing the context and included in a second packet constructed at the switch (Makineni: paragraphs 0012-0013; In FIG. 1A, the controller 100 stores the received packet's 106 header 106a and payload 106b for potential coalescing with subsequently received packets…In FIG. 1B, the controller 100 receives a second packet 108 that belongs to the same flow ("1") as the packet received in FIG. 1A. Instead of simply writing the packet memory 102, the controller 100 combines the two payloads 106b, 108b of the packets 106, 108 together into a monolithic payload 110b).
Claims 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Makineni et al. (U.S. Publication No. 2006/0104303), in view of Westberg (U.S. Publication No. 2003/0198226), in view of Craddock et al. (U.S. Publication No. 2003/0035433), and further in view of Wei et al. (U.S. Publication No. 2021/0311774).
As per claim 14, the modified Makineni teaches the method of claim 1.
However the modified Makineni does not explicitly mention wherein at least one of the steps of identifying, aggregating, constructing, or transmitting is performed within a cloud computing environment.
However Wei teaches:
wherein at least one of the steps of identifying, aggregating, constructing, or transmitting is performed within a cloud computing environment (Wei: paragraph 0159; the mobile device 702 and/or the cloud computing platform 703 may generate and train machine learning models that may be used to identify, based on an initial application and the context of that initial application, a most likely application that a user will subsequently request and/or access).
Therefore it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Wei with the teachings as in the modified Makineni. The motivation for doing so would have been in order to offer seamless application switching across local and/or virtual applications and improve user productivity on mobile devices and for providing flexible deployment and scalability, and offer a balance between user privacy and convenience (Wei: paragraphs 0030-0031).
As per claim 15, the modified Makineni teaches the method of claim 1.
However the modified Makineni does not explicitly mention wherein at least one of the steps of identifying, aggregating, constructing, or transmitting is performed for training, testing, or certifying a neural network employed in a machine, robot, or autonomous vehicle.
However Wei teaches:
wherein at least one of the steps of identifying, aggregating, constructing, or transmitting is performed for training, testing, or certifying a neural network employed in a machine, robot, or autonomous vehicle (Wei: paragraph 0007; 4) applying one or more machine learning algorithms to the corresponding edge frame to identify a corresponding context tag of the corresponding edge frame of the application, 5) identifying an application name and a device identifier corresponding to the launch of the application, 6) generating, based on the corresponding context tag, application name, and device identifier, a training sample, and 7) inserting, into a central repository, the training sample, resulting in storage of the plurality of training samples at the central repository…paragraph 0134; the mobile device 702 may apply supervised learning (e.g., using convolutional neural networks) to the edge frame to identify a context corresponding to the edge frame…paragraph 0056; The client machine(s) 240 may in some embodiments be referred to as a single client machine 240 or a single group of client machines 240).
Therefore it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Wei with the teachings as in the modified Makineni. The motivation for doing so would have been in order to offer seamless application switching across local and/or virtual applications and improve user productivity on mobile devices and for providing flexible deployment and scalability, and offer a balance between user privacy and convenience (Wei: paragraphs 0030-0031).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Makineni et al. (U.S. Publication No. 2006/0104303), in view of Westberg (U.S. Publication No. 2003/0198226), in view of Craddock et al. (U.S. Publication No. 2003/0035433), in view of Wei et al. (U.S. Publication No. 2021/0311774), and further in view of Kurkure et al. (U.S. Publication No. 2021/0373972).
As per claim 16, , the modified Makineni teaches the method of claim 1.
However Makineni, Westberg, and Craddock does not explicitly mention wherein at least one of the steps of identifying, aggregating, constructing, or transmitting is performed on a virtual machine comprising a portion of a graphics processing unit.
However Wei teaches:
wherein at least one of the steps of identifying, aggregating, constructing, or transmitting is performed on a virtual machine (Wei: paragraph 0058; the client machine 240 may be a virtual machine. The virtual machine may be any virtual machine, while in some embodiments the virtual machine may be any virtual machine managed by a Type 1 or Type 2 hypervisor, for example, a hypervisor developed by Citrix Systems, IBM, VMware, or any other hypervisor. In some aspects, the virtual machine may be managed by a hypervisor, while in other aspects the virtual machine may be managed by a hypervisor executing on a server 206 or a hypervisor executing on a client 240…paragraph 0059; A desktop may include a graphical shell providing a user interface for an instance of an operating system in which local and/or remote applications can be integrated…paragraph 0086; the virtualization application 526 may record user interactions associated with a graphical user interface (GUI) and communicate them to a server application where the server application will use the user interaction data as an input to the application operating on the server).
Therefore it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Wei with the teachings as in Makineni, Westberg, and Craddock. The motivation for doing so would have been in order to offer seamless application switching across local and/or virtual applications and improve user productivity on mobile devices and for providing flexible deployment and scalability, and offer a balance between user privacy and convenience (Wei: paragraphs 0030-0031).
However Makineni, Westberg, Craddock, and Wei do not explicitly mention a virtual machine comprising a portion of a graphics processing unit.
However Kurkure teaches:
a virtual machine comprising a portion of a graphics processing unit (Kurkure: paragraph 0014; Each virtual machine 118 can be assigned to a vGPU 151 of the GPU 115).
Therefore it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Kurkure with the teachings as in Makineni, Westberg, Craddock, and Wei. The motivation for doing so would have been in order to select a host for placement of virtual machines and balance the resource utilization among the hosts in the cluster (Kurkure: paragraphs 0002).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KARINA J. GARCIA-CHING whose telephone number is (571)270-7159. The examiner can normally be reached Monday - Wednesday (9:00 AM - 5:00 PM).
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, Vivek Srivastava can be reached at (571) 272-7304. 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.
/KARINA J GARCIA-CHING/Examiner, Art Unit 2449
/VIVEK SRIVASTAVA/Supervisory Patent Examiner, Art Unit 2449
