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 .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-6, 8-15, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Marelli et al. (US 2017/0366442 A1), hereinafter referred to as D1, in view of Volpe (US 11848849 B1), hereinafter referred to as D2.
Regarding claims 1, 10, and 17, D1 discloses generating high-speed test traffic in a network switch, which comprises:
an interface and a network interface device coupled to the interface and comprising pipeline circuitry that is to: receive a packet (Referring to Figures 1-4, A memory coupled to the interfaces serves as a buffer, containing packets received through the ingress interfaces while the packets await transmission to the network via respective egress interfaces. Interpreted as pipeline circuitry as circuitry for transmission from ingress to an egress interface. See paragraphs 0020-0024.);
replicate the packet based on a multicast configuration (Referring to Figures 1-4, Test generation is initiated when the switching element receives a test packet through a given ingress interface. Packet processing logic in the switching element allocates a space in the buffer for storage of a single copy of the test packet, and then replicates and transmits sequentially multiple copies of this stored copy through a designated egress interface. In the meanwhile, the switching element is able to continue receiving and forwarding data packets from the network via the egress interfaces other than the designated egress interface. The packet replication mechanism can also be used in replicating and transmitting multiple copies of multicast packets. Furthermore, when the test packet itself has a multicast header (or some other header calling for transmission of the packet through multiple egress interfaces), the packet processing logic can replicate and transmit respective sequences of copies of the test packet through multiple different egress interfaces concurrently. See paragraphs 0020-0024.)
D1 does not disclose determine, based upon a number of replicate packets that differ from the received packet, a multicast operative error count value and the pipeline circuitry comprises match-action circuity that is to determine, based upon programmable checksum table data, whether the replicate packets differ from the received packet.
D2 teaches, referring to Figures 10-13, data packets can be received at a port of a network device. The port can be an ingress port or an egress port (e.g., the packets can be generated by an external device or internally by the network device). At 1304, a determination can be made as to whether some of the received data packets are test types of data packets by, for example, a packet checker coupled to an ingress port (determine a number of replicate packets, test packets, that differ from the received packet, original test packet). At optional step 1306, one or more fields of test information of the test type of data packets can further be used for matching purposes so that only certain ones of the test type of data packets are used for signature generation. The remaining may be dropped or passed. At 1308, a value can be generated corresponding to data of a field of each of the test type of data packets (such as a field within test information). For example, hashing can be performed on the data of the field to generate a respective value for each field and/or packet. Hashing can project a value from a set with many members to a value from a set with a fixed number of (relatively fewer) members. The results of the hashing may be used to generate or augment an already generated value that represents the data in the field of all of the data packets. For example, a hash may result in a sequence of 1 or 0 values that may be logically ORed together to obtain an updated value that represents all of the data packets. At 1310, a signature can be generated that represents the values of the field for each of the data packets. See column 24, lines 18-43. The signature can be used in a variety of manners. For example, the signature can be analyzed to determine if certain data packet(s) were or were not received. For example, specific sequence(s) of test type of data packets can be generated to be routed through certain port(s) of a network device. The packet checker(s) of the network device can generate signature(s). The signature(s) can then be analyzed to verify if the anticipated test type of data packets were (or were not) received at he expected ports. Use of the signature can optimize memory storage space, bandwidth utilization, and/or processor utilization to analyze the test type of data packet(s). See column 24, lines 44-56. The test logic can include packet generators, packet checkers, and packet parsers to perform internal testing of a network device. See column 6, line 59 to column 7, line 14. In a mode, for example, memory 702 can be used by packet checker 704 to store packet and/or byte count information corresponding to test types of data packets received by packet checker 704 (and/or matched by packet checker or a number of packets used to generate a bloom filter signature). In certain embodiments, fields from a header of a test type of data packet can be used as an index into memory 702 (such as a header identifier and sequence number, for example). In certain embodiments, the fields can be used as an index to a counter stored within memory 702 for updating or otherwise accessing a counter stored therein. For example, a counter can be updated when a specific test type of data packet is matched and/or received or generated at a certain port (interpreted as multicast operative error count value as the claim does not set forth a definition of the claim limitation which would differentiate the claim term from the prior art’s counter). See column 17, lines 53-64. The test information is included in a packet payload of a test type of data packet. The test information can include one or more of the following fields, as illustrated: Debugging Identifier—a value used to identify a specific test type of data packet and/or to determine if a data packet is a test type of data packet. Checksum—a checksum of field(s) in test information. In certain embodiments, once a preliminary check is performed for identifying that the data packet is a test type of packet using the Debugging Identifier, a secondary check may be performed for confirming that the data packet is in fact a test type of packet by checking the checksum value, since the checksum is also unique to the test type of packet (match-action circuity that is to determine, based upon programmable checksum table data, whether the replicate packets differ from the received packet). See column 13, lines 26-40.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the packet checker and parser of D2 in the system of D1. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to perform internal testing of a network device without external test equipment for complex testing environments a taught as D2, See column 3, lines 51-65. Essentially, teaches receiving a packet and replicating test packets for transmission to another device. D1 does not disclose determining whether the transmitted replicated test packets match the received test packet. D2 teaches internal testing of a received packet on the same system in which a test packet parser verifies a signature of a test packet. The combination of D1 and D2 teach the claimed invention.
Regarding claims 2 and 12, D1 does not disclose wherein the pipeline circuitry is to receive hash value that comprises a hash of a portion of the packet and the pipeline circuitry is to determine a hash value of a portion of the replicated packet.
D2 teaches, referring to Figures 10-13, for example, hashing can be performed on the data of the field to generate a respective value for each field and/or packet. Hashing can project a value from a set with many members to a value from a set with a fixed number of (relatively fewer) members. The results of the hashing may be used to generate or augment an already generated value that represents the data in the field of all of the data packets. For example, a hash may result in a sequence of 1 or 0 values that may be logically ORed together to obtain an updated value that represents all of the data packets. At 1310, a signature can be generated that represents the values of the field for each of the data packets. See column 24, lines 18-43. The signature can be used in a variety of manners. For example, the signature can be analyzed to determine if certain data packet(s) were or were not received. For example, specific sequence(s) of test type of data packets can be generated to be routed through certain port(s) of a network device. The packet checker(s) of the network device can generate signature(s). The signature(s) can then be analyzed to verify if the anticipated test type of data packets were (or were not) received at he expected ports. Use of the signature can optimize memory storage space, bandwidth utilization, and/or processor utilization to analyze the test type of data packet(s). See column 24, lines 44-56. The test logic can include packet generators, packet checkers, and packet parsers to perform internal testing of a network device. See column 6, line 59 to column 7, line 14.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the packet checker and parser of D2 in the system of D1. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to perform internal testing of a network device without external test equipment for complex testing environments a taught as D2, See column 3, lines 51-65. Essentially, teaches receiving a packet and replicating test packets for transmission to another device. D1 does not disclose determining whether the transmitted replicated test packets match the received test packet. D2 teaches internal testing of a received packet on the same system in which a test packet parser verifies a signature of a test packet. The combination of D1 and D2 teach the claimed invention.
Regarding claims 3, 13, and 19, D1 does not disclose wherein the determine a number of replicate packets that differ from the received packet is based on the received hash value and the determined hash value.
D2 teaches, referring to Figures 10-13, for example, hashing can be performed on the data of the field to generate a respective value for each field and/or packet. Hashing can project a value from a set with many members to a value from a set with a fixed number of (relatively fewer) members. The results of the hashing may be used to generate or augment an already generated value that represents the data in the field of all of the data packets. For example, a hash may result in a sequence of 1 or 0 values that may be logically ORed together to obtain an updated value that represents all of the data packets. At 1310, a signature (determined hash value) can be generated that represents the values of the field for each of the data packets. See column 24, lines 18-43. The signature can be used in a variety of manners. For example, the signature can be analyzed to determine if certain data packet(s) were or were not received. For example, specific sequence(s) of test type of data packets can be generated to be routed through certain port(s) of a network device. The packet checker(s) of the network device can generate signature(s). The signature(s) can then be analyzed to verify if the anticipated test type of data packets were (or were not) received at he expected ports (received hash value). Use of the signature can optimize memory storage space, bandwidth utilization, and/or processor utilization to analyze the test type of data packet(s). See column 24, lines 44-56. The test logic can include packet generators, packet checkers, and packet parsers to perform internal testing of a network device. See column 6, line 59 to column 7, line 14.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the packet checker and parser of D2 in the system of D1. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to perform internal testing of a network device without external test equipment for complex testing environments a taught as D2, See column 3, lines 51-65. Essentially, teaches receiving a packet and replicating test packets for transmission to another device. D1 does not disclose determining whether the transmitted replicated test packets match the received test packet. D2 teaches internal testing of a received packet on the same system in which a test packet parser verifies a signature of a test packet. The combination of D1 and D2 teach the claimed invention.
Regarding claims 4 and 14, D1 does not disclose wherein the hash value of the packet is based on at least one header of the packet.
D2 teaches, referring to Figures 10-13, a determination that a data packet is a test type of data packet, match logic 706 can perform additional matching techniques to identify certain test types of data packets. For example, match logic 706 may be configured to examine certain field(s) of a test type of data packet. The fields may be contained in packet and/or test information portions of a data packet. Example fields can include a port at which a test type of data packet was generated, a header number (header of the packet), an ID of a specific packet checker, a sequence number, or a timestamp. This information can be included as test information in a test type of data packet by a packet generator. In certain embodiments, wild-carded matching can be performed. Upon a successful match, several action(s) can be performed. For example, an interrupt can be generated for a CPU, packet checker(s) or generator(s) can be triggered to start or stop, the data packet can be trapped in memory (partially or wholly), a signature can be generated, or a latency measurement obtained. See column 17, lines 8-25. The test logic can include packet generators, packet checkers, and packet parsers to perform internal testing of a network device. See column 6, line 59 to column 7, line 14.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the packet checker and parser of D2 in the system of D1. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to perform internal testing of a network device without external test equipment for complex testing environments a taught as D2, See column 3, lines 51-65. Essentially, teaches receiving a packet and replicating test packets for transmission to another device. D1 does not disclose determining whether the transmitted replicated test packets match the received test packet. D2 teaches internal testing of a received packet on the same system in which a test packet parser verifies a signature of a test packet. The combination of D1 and D2 teach the claimed invention.
Regarding claims 5, 15, and 20, D1 does not disclose wherein the hash value of the packet is based on at least one header and a portion of a payload of the packet.
D2 teaches a signature (hash value) based upon a header. See above. D2 also teaches the payload generator 908 can similarly generate a packet payload for a generated data packet in several manners. For example, the packet payload can include random or pseudo-random values. Data to populate packet a payload data can be retrieved from memory 902. Packet payload(s) or packet payload template(s) may be stored within memory 902. Packet payload template(s) may be modified by payload generator 908 similar to the header information generator 906 modification of template(s). Payload generator 908 can vary lengths of packet payloads depending on one or more rules and/or an amount of data packet traffic received or processed at network device 900. The packet payload can optionally be populated with test information, as further described for FIG. 4 to generate a test type of data packet. See column 19, lines 14-27.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the packet checker and parser of D2 in the system of D1. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to perform internal testing of a network device without external test equipment for complex testing environments a taught as D2, See column 3, lines 51-65. Essentially, teaches receiving a packet and replicating test packets for transmission to another device. D1 does not disclose determining whether the transmitted replicated test packets match the received test packet. D2 teaches internal testing of a received packet on the same system in which a test packet parser verifies a signature of a test packet. The combination of D1 and D2 teach the claimed invention.
Regarding claim 6, D1 does not disclose wherein the determine a number of replicate packets that differ from the received packet is performed at line-rate of the network interface device.
D2 teaches he ability to generate test types of data packets at a same rate as can be processed by a network device across multiple ports/packet processors can be used to saturate a network device, for example (determination performed at line-rate of the network interface device). Saturating the device can aid in corner case testing, stress testing, verification of crossbar design, and/or power usage testing, for example. Furthermore, multiple test engineers can work in parallel by developing test suites on isolated portion(s) of an FPGA or integrated circuit. Furthermore, one integrated circuit can be used in external mode to generate stimuli for a second integrated circuit (under test). Furthermore, use of dedicated and/or external test equipment can be minimized.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the packet checker and parser of D2 in the system of D1. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to perform internal testing of a network device without external test equipment for complex testing environments a taught as D2, See column 3, lines 51-65. Essentially, teaches receiving a packet and replicating test packets for transmission to another device. D1 does not disclose determining whether the transmitted replicated test packets match the received test packet. D2 teaches internal testing of a received packet on the same system in which a test packet parser verifies a signature of a test packet. The combination of D1 and D2 teach the claimed invention.
Regarding claim 8, the primary reference further 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) (Referring to Figures 1-4, a switching element, which has multiple interfaces connected to a packet data network and configured to serve as both ingress and egress interfaces to receive and forward data packets. A memory coupled to the interfaces serves as a buffer, containing packets received through the ingress interfaces while the packets await transmission to the network via respective egress interfaces. Test generation is initiated when the switching element receives a test packet through a given ingress interface. Packet processing logic in the switching element allocates a space in the buffer for storage of a single copy of the test packet, and then replicates and transmits sequentially multiple copies of this stored copy through a designated egress interface. In the meanwhile, the switching element is able to continue receiving and forwarding data packets from the network via the egress interfaces other than the designated egress interface. See paragraphs 0019-0021.)
Regarding claim 9, the primary reference further teaches a server communicatively coupled to the network interface device to configure the circuitry to replicate the packet based on a multicast configuration (Referring to Figures 1-4, a switching element (server), which has multiple interfaces connected to a packet data network and configured to serve as both ingress and egress interfaces to receive and forward data packets. A memory coupled to the interfaces serves as a buffer, containing packets received through the ingress interfaces while the packets await transmission to the network via respective egress interfaces. Test generation is initiated when the switching element receives a test packet through a given ingress interface. Packet processing logic in the switching element allocates a space in the buffer for storage of a single copy of the test packet, and then replicates and transmits sequentially multiple copies of this stored copy through a designated egress interface. In the meanwhile, the switching element is able to continue receiving and forwarding data packets from the network via the egress interfaces other than the designated egress interface. See paragraphs 0019-0021.)
D1 does not disclose determine a number of replicate packets that differ from the received packet.
D2 teaches, referring to Figures 10-13, a determination that a data packet is a test type of data packet, match logic 706 can perform additional matching techniques to identify certain test types of data packets. For example, match logic 706 may be configured to examine certain field(s) of a test type of data packet. The fields may be contained in packet and/or test information portions of a data packet. Example fields can include a port at which a test type of data packet was generated, a header number (header of the packet), an ID of a specific packet checker, a sequence number, or a timestamp. This information can be included as test information in a test type of data packet by a packet generator. In certain embodiments, wild-carded matching can be performed. Upon a successful match, several action(s) can be performed. For example, an interrupt can be generated for a CPU, packet checker(s) or generator(s) can be triggered to start or stop, the data packet can be trapped in memory (partially or wholly), a signature can be generated, or a latency measurement obtained. See column 17, lines 8-25. The test logic can include packet generators, packet checkers, and packet parsers to perform internal testing of a network device. See column 6, line 59 to column 7, line 14.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the packet checker and parser of D2 in the system of D1. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to perform internal testing of a network device without external test equipment for complex testing environments a taught as D2, See column 3, lines 51-65. Essentially, teaches receiving a packet and replicating test packets for transmission to another device. D1 does not disclose determining whether the transmitted replicated test packets match the received test packet. D2 teaches internal testing of a received packet on the same system in which a test packet parser verifies a signature of a test packet. The combination of D1 and D2 teach the claimed invention.
Regarding claim 11, the primary reference further teaches wherein the multicast configuration is based on one or more of: a link aggregation group (LAG), an equal-cost multi-path routing (ECMP) group, packet size, single packet copy or multiple packet copy per port, single tree node or multiple tree nodes per multicast group, or cross pipeline packet traversal (Referring to Figures 1-4, a switching element, which has multiple interfaces connected to a packet data network and configured to serve as both ingress and egress interfaces to receive and forward data packets. A memory coupled to the interfaces serves as a buffer, containing packets received through the ingress interfaces while the packets await transmission to the network via respective egress interfaces. Test generation is initiated when the switching element receives a test packet through a given ingress interface. Packet processing logic in the switching element allocates a space in the buffer for storage of a single copy of the test packet, and then replicates and transmits sequentially multiple copies of this stored copy through a designated egress interface. In the meanwhile, the switching element is able to continue receiving and forwarding data packets from the network via the egress interfaces other than the designated egress interface. See paragraphs 0019-0021. The packet replication mechanism can also be used in replicating and transmitting multiple copies of multicast packets. Furthermore, when the test packet itself has a multicast header (or some other header calling for transmission of the packet through multiple egress interfaces), the packet processing logic can replicate and transmit respective sequences of copies of the test packet through multiple different egress interfaces concurrently. See paragraphs 0020-0024.)
Regarding claim 18, and further regarding claim 17, D1 does not disclose wherein the determining whether a network interface device is defective is based on a non-zero number of replicate packets that differ from the received packet.
D2 teaches stress testing can be used to, for example, characterize or identify a fault on a certain path of a network. For example, a relatively large number of test type of data packets can be injected over path(s) of a network and error statistics recorded. The statistics can aid in identifying, at a level of granularity, a location of a possible fault. Additional stress tests can be run at increasingly targeted location(s) of a network to further characterize/locate the fault. Such testing may be difficult using simple single packet (e.g., pinging) techniques as certain errors may be intermittent and difficult to identify without stress testing. See column 23, lines 10-20. Test information of the test type of data packet received at an ingress port can be examined to aid in characterization of an error and/or validation of network device/infrastructure operations. At optional step 1206, one or more test types of packets can be generated by a packet generator of the network device operating in internal mode. At 1208, the sequence(s) of data packets can be routed by the network device that received the sequence(s) of network packets to an egress port of the network device. Routing can be performed by a packet processor, for example. In certain embodiments, the sequence(s) can be live sequences received at an ingress port while a network device is deployed. While the live sequence(s) are received and routed, test type of data packet(s) can be contemporaneously received and/or generated. Thus, life traffic sequence(s) may be routed and/or test type of data packet(s) contemporaneously received and/or processed. At 1210, test types of data packets generated at 1206 can be identified to aid in troubleshooting and/or verifying operations of the network device that routed the test type of data packet. The test type of data packets can be generated, for example, at egress port(s) of a network device by one or more packet checkers using techniques disclosed herein. See column 23, line 51 to column 24, line 7.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the packet checker and parser of D2 in the system of D1. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to perform internal testing of a network device without external test equipment for complex testing environments a taught as D2, See column 3, lines 51-65. Essentially, teaches receiving a packet and replicating test packets for transmission to another device. D1 does not disclose determining whether the transmitted replicated test packets match the received test packet. D2 teaches internal testing of a received packet on the same system in which a test packet parser verifies a signature of a test packet. The combination of D1 and D2 teach the claimed invention.
Claim(s) 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Marelli et al. (US 2017/0366442 A1), hereinafter referred to as D1, in view of Volpe (US 11848849 B1), hereinafter referred to as D2, in further view of Sommers et al. (US 2020/0401504 A1), hereinafter referred to as D3.
Regarding claims 7 and 16, D1 does not disclose wherein the circuitry is configured to replicate the packet based on a multicast configuration and determine a number of replicate packets that differ from the received packet based on a configuration consistent with one or more of: Protocol-independent Packet Processors (P4), Software for Open Networking in the Cloud (SONiC), Broadcom® Network Programming Language (NPL), NVIDIAO CUDAO, NVIDIAO DOCATM,orInfrastructure Programmer Development Kit (IPDK).
D3 teaches a network equipment test device or a related entity may generate one or more configuration files (e.g., P4 source files, test plans, test variables and related test values, test conditions, test actions, etc.) for configuring the network equipment test device or resource(s) therein. For example, a network equipment test device may test an ASIC-based switch programmed or configured using one or more P4 source files. In this example, the network equipment test device or a related entity may receive and analyze the P4 source files to generate source code for a test system resource and test metadata for testing the ASIC-based switch. Continuing with this example, the test system resource may use this information to may generate test traffic for testing the ASIC-based switch, e.g., based on the identified test metadata and/or related test plans (e.g., protocol templates, packet templates, flow templates, test templates, etc.). See paragraphs 0020-0025.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the P4 standard of D3 in the system of D1 and D2. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to comply with well-known standards. In so doing, unexpected results are not achieved.
Response to Arguments
Applicant's arguments filed 15 October 2025 have been fully considered but they are not persuasive.
On page 2 of the remarks, regarding claim 1, the Applicant argues the prior art does not teach the amended claim limitations. The Examiner respectfully disagrees. Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
SUBRAHMANYA et al. (US 2022/0417142 A1) - The extended packet processing pipeline can be implemented via a pipeline circuit. The extended packet processing pipeline can determine that a network traffic flow associated with the flow table entry is expired or terminated. The network appliance can delete the flow table entry from the flow table by processing a traffic flow deletion operation after determining that the network traffic flow is expired or terminated.
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 DONALD L MILLS whose telephone number is (571)272-3094. The examiner can normally be reached Monday through Friday from 9-5 PM EST.
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, Yemane Mesfin can be reached at 571-272-3927. 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.
DONALD L. MILLS
Primary Examiner
Art Unit 2462
/Donald L Mills/ Primary Examiner, Art Unit 2462