CTFR 18/075,262 CTFR 100769 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. This application claims priority to U.S. Provisional Application 63/416,831, filed 10/17/2022. The benefit claim is acknowledged and entered by the Examiner. The Supplemental Amendment to the specification, filed 02/25/2026, directed to correction of minor informalities, is acknowledged and entered by the Examiner. This action is responsive to the Applicant’s amendments filed on 02/25/2026. Claims 1-2 and 4-20 remain pending in the application. Claims 1-2, 6, 8-12, 15, and 17-19 have been amended. Claim 3 has been canceled. Any examiner’s note, objection, and rejection not repeated is withdrawn due to Applicant’s amendment. Information Disclosure Statement The information disclosure statements (IDS) submitted on 10/11/2023 and 12/27/2023 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner. Examiner’s Note The 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 also apply. It is respectfully requested that, in preparing responses, the Applicant fully consider the references in its entirety 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. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim s 1-2, and 5-9 are rejected under 35 U.S.C. 103 as being unpatentable over Goel et al. (US 20120033673 A1) hereafter Goel in view of Pope et al. (US 20190303209 A1) hereafter Pope, further in view of Shen et al. (US 20210359940 A1) hereafter Shen, further in view of Youseff et al. (US 9280375 B1) hereafter Youseff . Regarding claim 1, Goel teaches: at least one memory; at least one processor (Paragraph 86; “The central processing unit 101 is any logic circuitry that responds to and processes instructions fetched from the main memory unit 122.”), wherein the at least one processor is to execute instructions stored in the at least one memory that cause the at least one processor to: performing load balancing of packet data among processor cores and allocation of the load balanced packet data for processing by the processor cores (Paragraph 199; “packet engine(s) 548A-N can distribute functions or data among the processing cores 505A-N so that the distribution is according to the parallelism or distribution scheme. In some embodiments, a single packet engine(s) 548A-N carries out a load balancing scheme, while in other embodiments one or more packet engine(s) 548A-N carry out a load balancing scheme. Each core 505A-N, in one embodiment, can be associated with a particular packet engine 505 such that load balancing can be carried out by the packet engine 505. Load balancing may in this embodiment, require that each packet engine 505 associated with a core 505 communicate with the other packet engines 505 associated with cores 505 so that the packet engines 505 can collectively determine where to distribute load.”, where packet engines actively distribute work among multiple processing cores, corresponding to performing load balancing of packet data across cores.); allocate received packets to a first queue (Paragraph 270; “When a data packet is received by the NIC 552, the data packet can be stored into the NIC receive queue 622.”, where incoming network communications are received and stored in a receive-side queue in the NIC.); allocate packets, that are to be transmitted, to a second queue (Paragraph 270; “interface module 612 that interfaces with the logical receive queues 604 and the logical transmit queues 602 within each packet engine 548. The interface module 612 can also interface with the transmit queue 620 and the receive queue 622 on the NIC 552. When a data packet is received by the NIC 552, the data packet can be stored into the NIC receive queue 622. The interface module 612 in turn can drain the NIC receive queue 622 and distribute the received data packets to the logical receive queues 604 within each core's packet engine 548.”, where there exists a transmit-side queue within the NIC used for outbound communications, where packets intended for transmission are placed into the NIC transmit queue.); wherein: the first queue is to solely store the received remote procedure calls (Paragraph 270; “When a data packet is received by the NIC 552, the data packet can be stored into the NIC receive queue 622.”, where inbound network communications are placed in a dedicated receive queue, NIC receive queue 622, which is designed for incoming data packets and defined as the receive-side buffer in the NIC, which is functionally different from the transmit queue, supporting its use solely for received communications, where the explicit architectural separation of receive and transmit queues restricts each queue to its respective traffic direction.); the second queue is to solely store the remote procedure calls that are to be transmitted (Paragraph 270; “The interface module 612 in turn can drain the NIC receive queue 622 and distribute the received data packets to the logical receive queues 604 within each core's packet engine 548. Thus, the interface module 612, in some embodiments, operates in conjunction with the flow distributor 550 to obtain, drain or otherwise pull information from the NIC receive queue 622 and the logical transmit queues 602, and write or otherwise store information into the logical receive queues 604 and the NIC transmit queue 620.”, which teaches a distinct transmit-side queue 620 as part of the NIC transmission pipeline which is distinct from the receive queue, indicating a dedicated role for outbound data, where the explicit architectural separation of receive and transmit queues restricts each queue to its respective traffic direction.); a receiver of packets (Paragraph 7; “A first core operating a first domain of a virtualized environment receives a packet from the NIC of a multi-core device” indicates a first core may receive packets from a network interface device, the NIC.). Goel does not teach execute a communication proxy; the received remote procedure calls are received by a network interface device; the network interface device is to transmit the remote procedure calls. However, Pope teaches: the received packets are received by a network interface device (Paragraph 62; “A data packet 810 is received at the network interface device and is written to a receive buffer 840 in the network interface device.”); the network interface device is to transmit the packets (Paragraph 73; “network interface device comprises a transmit function 370, which is invoked by the application 310 to transmit data packets over the network”, which explicitly discloses the transmission of packets occurring through a network interface device.). Goel and Pope are considered to be analogous to the claimed invention because they are in the same field of load balancing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Goel to incorporate the teachings of Pope and have the received packets received by a network interface device, and to later have the network interface device transmit the packets. A person of ordinary skill in the art would have been motivated to provide a unified network interface device architecture supporting coordinated receive and transmit-side packet handling, enabling efficient bidirectional communication through queue processing in a networking system. Goel in view of Pope does not teach execute a communication proxy; or RPC. However, Shen teaches: execute a communication proxy (Paragraph 40; “It is often the case that a proxy (may also be referred to as a proxy device or a proxy server) is installed between user terminals and a SaaS server to execute communication via the proxy.”). Goel, Pope, and Shen are considered to be analogous to the claimed invention because they are in the same field of load balancing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Goel in view of Pope to incorporate the teachings of Shen and incorporate execution of a communication proxy into the system of Goel in view of Pope in order to facilitate management and routing of network communications between communicating components, yielding the predictable result of improving coordination of packet handling. Goel in view of Pope, further in view of Shen does not teach RPC. However, Youseff teaches: RPC (Col. 13, lines 33-35; “The clients 120 may communicate with the data processing devices 110 through a network 130 (e.g., via RPC).”). Goel, Pope, Shen, and Youseff are considered to be analogous to the claimed invention because they are in the same field of load balancing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Goel in view of Pope, further in view of Shen to incorporate the teachings of Youseff and have the packets be RPCs. A person of ordinary skill in the art would have been motivated to use the known method of RPCs to support structured request/response communication between distributed components, yielding the predictable result of enabling efficient remote invocation of services over the existing packet-based networking and communication proxy architecture. Regarding claim 2, Goel in view of Pope, further in view of Shen, further in view of Youseff teaches the apparatus of claim 1. Goel teaches: circuitry to load balance packet traffic for processing among the processor cores (Paragraph 195; “In some cases, the multi-core system may use any type and form of load balancing schemes to distribute load among the one or more cores 505.”, where the multi-core system is implemented using physical hardware components which include processor circuitry. Load corresponds to packet traffic as evidenced by Paragraph 191; “load 536A on Core 1 505A may be comprised of the network traffic associated with the transactions between the particular client and server. Allocating the network traffic to Core 1 505A can be accomplished by routing all data packets originating from either the particular client or server to Core 1 505A.”). Shen teaches: the communication proxy (Paragraph 40; “It is often the case that a proxy (may also be referred to as a proxy device or a proxy server) is installed between user terminals and a SaaS server to execute communication via the proxy.”). Regarding claim 5, Goel in view of Pope, further in view of Shen, further in view of Youseff teach the apparatus of claim 1. Youseff teaches: wherein the remote procedure calls are made as part of communications to access a key-value store (Col. 13, lines 30-35; “A storage abstraction (e.g., key/value store or file system) overlain on the storage resources 114 allows scalable use of the storage resources 114 by one or more clients 120, 120a-n. The clients 120 may communicate with the data processing devices 110 through a network 130 (e.g., via RPC)”). Regarding claim 6, Goel in view of Pope, further in view of Shen, further in view of Youseff teach the apparatus of claim 1. Goel teaches: comprising circuitry that comprises the first and second queue s, wherein the circuitry is part of the network interface device (Paragraph 270; “NIC receive queue 622”, “NIC transmit queue 620” explicitly discloses receive/transmit queues within the NIC architecture. “interface module 612... write or otherwise store information into the NIC transmit queue” teaches that logic within the NIC system operates on and manages the receive and transmit queues, thereby showing that the queues are integrated into the processing circuitry of the NIC.). Regarding claim 7, Goel in view of Pope, further in view of Shen, further in view of Youseff teach the apparatus of claim 6. Goel teaches: wherein the network interface device comprises 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) (Paragraph 270, element 552; explicitly is a NIC, covering the NIC element of the “one or more of” list of elements.). Regarding claim 8, Goel in view of Pope, further in view of Shen, further in view of Youseff teach the apparatus of claim 1. Goel teaches: wherein at least one of the at least one processor comprises circuitry to perform the load balancing (Paragraph 195; “the multi-core system may use any type and form of load balancing schemes to distribute load among the one or more cores 505”, where the multi-core system comprises the processing circuitry for performing the load balancing techniques.). Regarding claim 9, Goel in view of Pope, further in view of Shen, further in view of Youseff teach the apparatus of claim 1. Goel teaches: comprising circuitry to perform load balancing (Paragraph 195; “the multi-core system may use any type and form of load balancing schemes to distribute load among the one or more cores 505”, where the multi-core system comprises the processing circuitry for performing the load balancing techniques.). Youseff teaches: a server comprising the at least one memory, and the at least one processor (Col. 13, lines 22-28; “Referring to FIG. 5, in some implementations, a distributed system 10′ includes loosely coupled data processing devices 110 (e.g., computers or servers), each having a physical processor 112 (e.g., one or more central processing units (CPUs) or other computing resource) in communication with storage resources 114 (e.g., memory, flash memory, dynamic random access memory (DRAM), phase change memory (PCM), and/or disks having spindles)”). It would have been obvious to a person of ordinary skill in the art to implement the load balancing functionality of Goel within the server-based system of Youseff to distribute processing workload among processors within the server, yielding the predictable result of improving processing efficiency . 07-21-aia AIA Claim s 10-11 and 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over Goel in view of Pope, further in view of Shen, further in view of Youseff, further in view of Kulkarni et al. (US 20230409396 A1) hereafter Kulkarni . Claim 10 recites similar limitations as those of claim 1, additionally reciting a non-transitory computer-readable medium, execution by a processor, a microservice communication proxy, allocating packet data to allocate workloads, and a queue system. Goel further teaches: execution by a processor (Paragraph 86; “In many embodiments, the central processing unit is provided by a microprocessor unit”); allocating packet data to allocate workloads (Paragraph 195; ”distribute load among the one or more cores”, in the context of Goel’s packet-processing architecture, a person of ordinary skill in the art would understand the load being distributed to correspond to packet data. “use any type and form of load balancing schemes” expressly teaches workload distribution mechanisms. “among the one or more cores 505” explicitly discloses that workloads, corresponding to load, are distributed across multiple processor cores.); a queue system (Paragraph 270; “NIC receive queue 622”, “NIC transmit queue 620” explicitly discloses receive/transmit queues within the NIC architecture, corresponding to the queue system.). Pope further teaches: a non-transitory computer-readable medium (Paragraph 20; “a non-transitory computer readable medium encoded with instructions”); a communication proxy (Paragraph 40; “It is often the case that a proxy (may also be referred to as a proxy device or a proxy server) is installed between user terminals and a SaaS server to execute communication via the proxy.”); Goel in view of Pope, further in view of Shen, further in view of Youseff does not teach microservices. However, Kulkarni teaches: microservices (Paragraph 174; “The functions, as microservices, may split into control planes, user and data planes, or even state machines, allowing for independent optimization and scaling techniques to be applied. Such user and data planes may be enabled through increased accelerators, both those residing in server platforms, such as FPGAs and Smart NICs”). Goel, Pope, Shen, Youseff, and Kulkarni are considered to be analogous to the claimed invention because they are in the same field of load balancing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Goel in view of Pope, further in view of Shen, further in view of Youseff to incorporate the teachings of Kulkarni and apply the communication proxy to microservices. A person of ordinary skill in the art would have recognized the use of a communication proxy and microservices to be known methods in the art whose implementation would yield the predictable result of proper transmission of network communications between distributed service components using queue-based packet handling. Claim 10 is rejected for similar reasons as those of claim 1. Claim 17 recites similar limitations as those of claim 10. Claim 17 is rejected for similar reasons as those of claim 10. Regarding claim 11, Goel in view of Pope, further in view of Shen, further in view of Youseff, further in view of Kulkarni teaches the computer-readable medium of claim 10. Goel teaches: wherein the load balancer is to allocate packet traffic to one or more cores of the cores (Paragraph 195; “In some cases, the multi-core system may use any type and form of load balancing schemes to distribute load among the one or more cores 505.”, where the multi-core system is implemented using physical hardware components which include processor circuitry. Load corresponds to packet traffic as evidenced by Paragraph 191; “load 536A on Core 1 505A may be comprised of the network traffic associated with the transactions between the particular client and server. Allocating the network traffic to Core 1 505A can be accomplished by routing all data packets originating from either the particular client or server to Core 1 505A.”). Regarding claim 14, Goel in view of Pope, further in view of Shen, further in view of Youseff, further in view of Kulkarni teach the computer-readable medium of claim 10. Youseff teaches: wherein the remote procedure calls are made as part of communications to access a key-value store (Col. 13, lines 30-35; “A storage abstraction (e.g., key/value store or file system) overlain on the storage resources 114 allows scalable use of the storage resources 114 by one or more clients 120, 120a-n. The clients 120 may communicate with the data processing devices 110 through a network 130 (e.g., via RPC)”). Regarding claim 15, Goel in view of Pope, further in view of Shen, further in view of Youseff, further in view of Kulkarni teach the computer-readable medium of claim 10. Goel teaches: wherein the queue system is part of the network interface device (Paragraph 270; “NIC receive queue 622”, “NIC transmit queue 620” explicitly discloses receive/transmit queues within the NIC architecture. “interface module 612... write or otherwise store information into the NIC transmit queue” teaches that logic within the NIC system operates on and manages the receive and transmit queues, thereby showing that the queues are integrated into the processing circuitry of the NIC.). Claim 19 recites similar limitations as those of claim 15. Claim 19 is rejected for similar reasons as those of claim 15. Regarding claim 16, Goel in view of Pope, further in view of Shen, further in view of Youseff, further in view of Kulkarni teach the computer-readable medium of claim 10. Goel teaches: wherein at least one of the at least one processor comprises the load balancer (Paragraph 195; “the multi-core system may use any type and form of load balancing schemes to distribute load among the one or more cores 505”, disclosing a multi-core processing system in which load balancing functionality is implemented within the multi core architecture.). Claim 20 recites similar limitations as those of claim 16. Claim 20 is rejected for similar reasons as those of claim 16. Regarding claim 18, Goel in view of Pope, further in view of Shen, further in view of Youseff, further in view of Kulkarni teach the method of claim 17. Goel teaches: allocating, by the queue system, packet data exclusively to the first and second queues (Paragraph 270; “When a data packet is received by the NIC 552, the data packet can be stored into the NIC receive queue 622. The interface module 612 in turn can drain the NIC receive queue 622 and distribute the received data packets to the logical receive queues 604 within each core's packet engine 548. Thus, the interface module 612, in some embodiments, operates in conjunction with the flow distributor 550 to obtain, drain or otherwise pull information from the NIC receive queue 622 and the logical transmit queues 602, and write or otherwise store information into the logical receive queues 604 and the NIC transmit queue 620.”, which discloses queue-based system in which an interface model controls distribution of received data packets into designated queues. There exist dedicated receive and transmit queues that separately store packet data based on direction and processing stage, in which the separation teaches allocation of packet data into distinct queues based on function. NIC receive queue 622 and NIC transmit queue 620 correspond to the claimed first and second queues respectively. Exclusivity is functionally supported by directional queue separation.). Claims 12 and 18 is rejected under 35 U.S.C. 103 as unpatentable over Goel in view of Pope, further in view of Shen, further in view of Youseff, further in view of Kulkarni, further in view of Buick et al. (US 20100306483 A1) hereafter Buick. Regarding claim 12, Goel in view of Pope, further in view of Shen, further in view of Youseff, further in view of Kulkarni teaches the computer-readable medium of claim 10. Goel teaches: packet data (Paragraph 128; “The network stack 310 via the interface may receive or provide any type and form of data structure, such as an object, related to functionality or operation of the network stack 310. For example, the data structure may comprise information and data related to a network packet or one or more network packets.”) Goel in view of Pope, further in view of Shen, further in view of Youseff, further in view of Kulkarni does not teach wherein the circuitry to queue one or more packets comprises circuitry to allocate packet data exclusively to one or more queues. However, Buick teaches: wherein the circuitry to queue one or more packets comprises circuitry to allocate tokens exclusively to one or more queues (Paragraph 16; “a token associated with the received data packet, and sends a token enqueue request to the sequencer circuits 143, 144, and 145 via the memory controller 124. As the token enqueue request is acted upon by one of the sequencer circuits 143, 144, or 145, a token associated with the received data packet is added to the tail-end of a queue in the queuing mechanism 140. The token is placed in the tail-end of the queue” shows queueing functionality performed by circuits for tokens). Goel, Pope, Shen, Youseff, Kulkarni, and Buick are considered to be analogous to the claimed invention because they are in the same field of load balancing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Goel in view of Pope, further in view of Shen, further in view of Youseff, further in view of Kulkarni to incorporate the teachings of Buick and utilize packet data to queues using dedicated circuitry. A person of ordinary skill in the art would have recognized the use of known queueing allocation circuitry on the packet data to yield a predictable improvement in ordering, prioritizing, and managing packet flow. Claim 4 is rejected under 35 U.S.C. 103 as unpatentable over Goel in view of Pope, further in view of Shen, further in view of Youseff, further in view of Alamouti et al. (US 20210042160 A1) hereafter Alamouti. Regarding claim 4, Goel in view of Pope, further in view of Shen, further in view of Youseff teach the apparatus of claim 1. Goel in view of Pope, further in view of Shen, further in view of Youseff does not teach wherein the proxy comprises a microservice sidecar, wherein the microservice sidecar is to provide communications between microservices. However, Alamouti teaches: wherein the proxy comprises a microservice sidecar, wherein the microservice sidecar is to provide communications between microservices (Paragraph 127; “It further expands on the notion of service mesh by providing a sidecar pattern at the edge to handle the API gateway, security, and routing for communication with other microservices”). Goel, Pope, Shen, Youseff, and Alamouti are considered to be analogous to the claimed invention because they are in the same field of load balancing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Goel in view of Pope, further in view of Shen, further in view of Youseff to incorporate the teachings of Alamouti and utilize a microservice sidecar to provide communications between microservices. A person of ordinary skill in the art would recognize that using a microservice sidecar would enable standardized handling of inter-service communication (i.e. through RPC). Incorporating the microservice sidecar would have been a logical application of known techniques to predictably yield uniform communication across microservices. Claim 13 is rejected over Goel in view of Pope, further in view of Shen, further in view of Youseff, further in view of Alamouti. Regarding claim 13, Goel in view of Pope, further in view of Shen, further in view of Youseff teach the non-transitory computer-readable medium of claim 10. Goel in view of Pope, further in view of Shen, further in view of Youseff does not teach wherein the microservice communication proxy comprises a microservice sidecar, wherein the microservice sidecar is to provide communications between microservices. However, Alamouti teaches: wherein the microservice communication proxy comprises a microservice sidecar, wherein the microservice sidecar is to provide communications between microservices (Paragraph 127; “It further expands on the notion of service mesh by providing a sidecar pattern at the edge to handle the API gateway, security, and routing for communication with other microservices”). Goel, Pope, Shen, and Youseff are considered to be analogous to the claimed invention because they are in the same field of load balancing. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Goel in view of Pope, further in view of Shen, further in view of Youseff to incorporate the teachings of Alamouti and utilize a microservice sidecar to provide communications between microservices. A person of ordinary skill in the art would recognize that using a microservice sidecar would enable standardized handling of inter-service communication (i.e. through RPC). Incorporating the microservice sidecar would have been a logical application of a known technique to achieve predictable, uniform communication across microservices . Response to Arguments Applicant's arguments filed 02/25/2026 have been fully considered. Applicant’s arguments are summarized below: The amendments to claim 10 overcome the rejections of claims 10-16 under 35 U.S.C. 101. The prior art of record does not teach the amended limitations of claim 1, 10, and 17. Dependent claims are submitted as allowable for at least the above reasons. Examiner’s response: The Examiner agrees that the amendments to claim 10 limiting the computer-readable medium to non-transitory form overcomes the rejection under 35 U.S.C. 101. Accordingly, the rejection under 35 U.S.C. 101 is withdrawn. The Examiner agrees that the prior art of record does not teach the amended limitations of claims 1, 10, and 17. Accordingly, the previous rejections of claims 1, 10, and 17, under 35 U.S.C. 103 are withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Goel, Pope, Shen, and Youseff as applied to claim 1, under 35 U.S.C. 103. Further, a new ground(s) of rejection is made in view of Goel, Pope, Shen, Youseff, and Kulkarni, as applied to claims 10 and 17, under 35 U.S.C. 103. Independent claims 1, 10, and 17 remain rejected for the reasons stated above. Therefore, contrary to Applicant's arguments, because the dependent claims depend from an unpatentable claim and does not add limitations that overcome the rejection, it likewise remains rejected. Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. McDonnell et al. (US 20230401109 A1) discusses a load balancer to perform ordering of requests from a plurality of processor cores that are allocated into queue elements before allocation for processing . Applicant's amendment necessitated the new ground(s) 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 KENNETH P TRAN whose telephone number is (571)272-6926. The examiner can normally be reached M-TH 4:30 a.m. - 12:30 p.m. PT, F 4:30 a.m. - 8:30 a.m. PT, or at Kenneth.Tran@uspto.gov. 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, April Blair can be reached at (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 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. /KENNETH P TRAN/ Examiner, Art Unit 2196 /APRIL Y BLAIR/ Supervisory Patent Examiner, Art Unit 2196 Application/Control Number: 18/075,262 Page 2 Art Unit: 2196 Application/Control Number: 18/075,262 Page 3 Art Unit: 2196 Application/Control Number: 18/075,262 Page 4 Art Unit: 2196 Application/Control Number: 18/075,262 Page 5 Art Unit: 2196 Application/Control Number: 18/075,262 Page 6 Art Unit: 2196 Application/Control Number: 18/075,262 Page 7 Art Unit: 2196 Application/Control Number: 18/075,262 Page 8 Art Unit: 2196 Application/Control Number: 18/075,262 Page 9 Art Unit: 2196 Application/Control Number: 18/075,262 Page 10 Art Unit: 2196 Application/Control Number: 18/075,262 Page 11 Art Unit: 2196 Application/Control Number: 18/075,262 Page 12 Art Unit: 2196 Application/Control Number: 18/075,262 Page 13 Art Unit: 2196 Application/Control Number: 18/075,262 Page 14 Art Unit: 2196 Application/Control Number: 18/075,262 Page 15 Art Unit: 2196 Application/Control Number: 18/075,262 Page 16 Art Unit: 2196 Application/Control Number: 18/075,262 Page 17 Art Unit: 2196 Application/Control Number: 18/075,262 Page 18 Art Unit: 2196
Prosecution Insights