DETAILED ACTION
This office action is in response to the claim listing filed on March 17th, 2026. Claims 1-53 are currently pending.
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.
Claims 1, 11, 21, 34, and 44 are rejected 35 U.S.C. 103 as being unpatentable over Jen (USPGPUB No. 2019/00303342 A1, hereinafter referred to as Jen) and further in view of Stremlau et al. (USPGPUB No. 2022/0188419 A1, hereinafter referred to as Stremlau) in view of Smith et al. (USPGPUB No. 2022/0141026 A1, hereinafter referred to as Smith).
Referring to claim 1, Jen discloses a docking station, comprising {“network hubs”, see Fig. 1, including USB [0018], [0023], and [0025]}:
a microcontroller unit (MCU) {“executed by the microcontroller”, see Fig. 1 [0139]} comprising a validation engine {“from the docket controller to [validation engine] software running on the electronic device” [0152]};
a universal serial bus (USB) {“I/O modules 131 and 118” with appropriate port(s), see Fig. 1 [0026] such as “PIPE USB Type-C” ([0053])};
and a network interface system on a chip (SOC) {“integrated on a single die, such as SOC,”, see Fig. 11, [0104]} communicatively coupled to the docking station {docking station “network hubs”, see Fig. 1, including USB [0018], [0023], and [0025]};
and a chipset configured to operate chipset services {“controller hub 115 include a chipset”, see Figs. 1 and 11, [0023], 2nd sentence} with a host device communicatively coupled to the docking station {“[host] System 100 includes processor 105 and system memory 110”, see Fig. 1, [0021], 2nd sentence}, according to chipset firmware {“hardware, software, firmware, or a combination thereof adapted in a computer system” ([0115], 2nd sentence) for the chipset “chipset 1290” (see Fig. 12, [0108])};
wherein the docking station is configured to:
Jen does not appear to explicitly disclose receive, from the network interface SOC, chipset update binary for updating the chipset firmware for the chipset of the docking station, the chipset update binary including a signature;
determine, by the MCU, that the chipset update binary is signed;
validate, using the validation engine of the MCU, the chipset update binary based on validating the received signature without input from the host device;
based on the validation, operate the MCU to update the chipset firmware using the chipset update binary data without input from the host device;
Stremlau discloses receive, from the network interface SOC, chipset update binary {“firmware hub 174” see Fig. 1 [0041]} for updating the chipset firmware for the chipset of the docking station {“have its firmware code and/or settings updated” see Fig. 1 [0043]}, the chipset update binary including a signature {“usable to validate the first and second digital signatures [of the firmware update data]” [0014]};
determine, by the MCU, that the chipset update binary is signed {“executable to hash the firmware update data to render a first hash” [0003]};
validate, using the validation engine of the MCU, the chipset update binary {“firmware update data has not been previously applied at the device based on the first hash not matching” [0012]} based on validating the received signature without input from the host device {“generating, at the EC, a key pair” without host device input [0014], see Fig. 1};
based on the validation {“step 318”, see Fig. 3, [0065]}, operate the MCU to update the chipset firmware {“step 320”, see Fig. 3, [0066]} using the chipset update binary data without input from the host device {“block 320 where the [automatic] component itself may receive the first firmware update data along with the public key(s), first digital certificate, and second digital certificate”, see Fig. 3 [0066]};
Jen and Stremlau are analogous because they are from the same field of endeavor, communicating between peripheral devices.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Jen and Stremlau before him or her, to modify Jen’s “network hubs” (see Fig. 1) incorporating Stremlau’s “embedded controller 191” (see Fig. 1 [0043]).
The suggestion/motivation for doing so would have been to implement improved computer-based user interface that increases the functionality and ease of use of the devices disclosed herein (Stremlau [0079]) with regards to hacker response solutions (Stremlau [0002]) .
Therefore, it would have been obvious to combine Stremlau with Jen to obtain the invention as specified in the instant claim(s).
Jen and Stremlau does not appear to explicitly disclose a universal serial bus (USB) interface configured to facilitate communication between the MCU and a network interface system on a chip (SOC) communicatively coupled to the docking station;
However, Smith discloses a universal serial bus (USB) interface configured to facilitate communication {“USB controllers 1442”, see Figs. 10 and 11A, [0299] last sentence} between the MCU and a network interface system on a chip (SOC) {“[MCU] processing platform incorporated within a system-on-a-chip SOC” (see Fig. 10, [0292], 3rd sentence) that processing platform includes microcontroller } communicatively coupled to the docking station {“[docking station] platform controller hub 130 enables peripherals to connect to memory device 1420”, see Fig. 10, [0299], 1st sentence}.
Jen/Stremlau and Smith are analogous because they are from the same field of endeavor, routing packet stream(s).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Jen/Stremlau and Smith before him or her, to modify Jen/Stremlau’s system incorporating Smith’ “weightage-based scheduling schemes” (see Fig. 3, [0033]).
The suggestion/motivation for doing so would have been to implement a count indicating a number of input ports of the input group arbiter having queued data packets targeting the set of output ports (Smith [0002]).
Therefore, it would have been obvious to combine Smith with Gray to obtain the invention as specified in the instant claim(s).
Referring to claims 11 are method claims reciting claim functionality corresponding to the system claim of claim 1, thereby rejected under the same rationale as claim 1 recited above.
Referring to claim 21 is a system claims reciting claim functionality corresponding to the system claim of claim 1, thereby rejected under the same rationale as claim 1 recited above.
Referring to claims 34 is a system claims reciting claim functionality corresponding to the system claim of claim 1, thereby rejected under the same rationale as claim 1 recited above.
Referring to claims 44 is a method claim reciting claim functionality corresponding to the system claim of claim 1, thereby rejected under the same rationale as claim 1 recited above.
Claims 2, 3, 4, 5, 6, 12, 13, 14, 15, 16, 22-29, 34-39, and 45, 46, 47, 48, and 49 are rejected 35 U.S.C. 103 as being unpatentable over Jen (USPGPUB No. 2019/00303342 A1, hereinafter referred to as Jen) and further in view of Stremlau et al. (USPGPUB No. 2022/0188419 A1, hereinafter referred to as Stremlau) in view of Smith et al. (USPGPUB No. 2022/0141026 A1, hereinafter referred to as Smith) in view of Nix (US Pat No. 10169587 B1).
As per claim 2, the rejection of claim 1 is incorporated and Nix discloses wherein the chipset update binary from the network interface SOC {“potentially as a “system on a chip”, Col 20, lines 57-58} is received without input from the host device {“Configuration package for device 101 could include updated software or firmware for device 101” automatically and without host device input, see Fig. 6a, Col 89, lines 60-62]}.
Jen/Stremlau/Smith and Nix are analogous because they are from the same field of endeavor, communicating between USB devices.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Jen/Stremlau/Smith and Nix before him or her, to modify Jen/Stremlau/Smith’s system incorporating Nix’s “device database” and corresponding “configuration data” (see Fig. 6a, Col 88, lines 18 and 37).
The suggestion/motivation for doing so would have been to implement ways to securely provision a device, such as conduct mutual authentication via PKI keys (Nix Col 2, lines 35-37) addressing needs in the art pertain to securely and efficiently configuring the transducer devices, including allowing a user or a network to securely and easily upload to the device a set of network access credentials for a wireless network (paraphrased Nix Col 1, lines 58-62).
Therefore, it would have been obvious to combine Nix with Jen/Stremlau/Smith to obtain the invention as specified in the instant claim(s).
As per claim 3, the rejection of claim 1 is incorporated and Nix discloses wherein the MCU further comprises a decryption engine {“conduct a decryption step 320”, see FIG. 4a , Col 52, lines 40-41} configured to decrypt the chipset update binary {“into an ECDH key exchange in order to mutually derive a shared secret key M 410 fabric”, see Fig. 4a, Col 52, lines 36-37}, and wherein the chipset update binary is received from the network interface SOC and at the MCU in encrypted form {“[network interface] for WiFi can be preferred, since unicast messages are acknowledged at the data link layer.”, Col 51, lines 42-44}.
As per claim 4, the rejection of claim 3 is incorporated and Nix discloses wherein the MCU is further configured to decrypt the chipset update binary {“conduct a decryption step 320”, see FIG. 4a , Col 52, lines 40-41} without input from the host device {“Configuration package for device 101 could include updated software or firmware for device 101” automatically and without host device input, see Fig. 6a, Col 89, lines 60-62]}.
As per claim 5, the rejection of claim 3 is incorporated and Nix discloses wherein the validation engine of the MCU is further configured to validate the signature of the chipset update binary {signature validation “conduct public key validation step to ensure”, see Fig. 3a, Col 54, lines 13-14} without input from the host device {“Configuration package for device 101 could include updated software or firmware for device 101” automatically and without host device input, see Fig. 6a, Col 89, lines 60-62]}.
As per claim 6, the rejection of claim 1 is incorporated and Smith discloses wherein the network interface SOC is configured to receive the chipset update binary {“FW updates comply with National Institute of Standards and Technology (NIST) requirements”(see Figs. 8a-8c, [0227] 1st sentence)} via a Wi-Fi access point using a Wi-Fi interface {“wireless transceiver 1426 can be a Wi-Fi transceiver,”, see Fig. 10, [0299]}.
Referring to claims 12-16 are method claims reciting claim functionality corresponding to the system claim of claims 2, 3, 4, 5, and 6, respectively, thereby rejected under the same rationale as claims 2, 3, 4, 5, and 6 recited above.
Referring to claims 22-26 are system claims reciting claim functionality corresponding to the system claim of claims 2, 3, 4, 5, and 6, respectively, thereby rejected under the same rationale as claims 2, 3, 4, 5, and 6 recited above.
As per claim 27, the rejection of claim 26 is incorporated and Stremlau discloses wherein the cloud server comprises the chipset update binary {“firmware hub 174” see Fig. 1 [0041]}.
As per claim 28, the rejection of claim 21 is incorporated and Stremlau discloses wherein the validation engine of the MCU is further configured to validate the signature {“generating, at the EC, a key pair” without host device input [0014], see Fig. 1} of the chipset update binary without input from the host device {“block 320 where the [automatic] component itself may receive the first firmware update data along with the public key(s), first digital certificate, and second digital certificate”, see Fig. 3 [0066]}.
As per claim 29, the rejection of claim 21 is incorporated and Stremlau discloses wherein the network interface SOC is configured to receive the chipset update binary via the network access point using the network interface {“firmware hub 174” see Fig. 1 [0041]}.
Referring to claims 34, 35, and 36 are system claims reciting claim functionality corresponding to the system claim of claims 1, 2, and 3, respectively, thereby rejected under the same rationale as claims 1, 2, and 3 recited above.
As per claim 37, the rejection of claim 36 is incorporated and Nix discloses wherein the MCU is further configured to decrypt the chipset update binary without input from the host device {“visible to the networking devices in the switch fabric”, [0218]}.
As per claim 38, the rejection of claim 34 is incorporated and Nix discloses wherein the validation engine of the MCU is further configured to validate the signature of the chipset update binary {signature validation “conduct public key validation step to ensure”, see Fig. 3a, Col 54, lines 13-14} without input from the host device {“Configuration package for device 101 could include updated software or firmware for device 101” automatically and without host device input, see Fig. 6a, Col 89, lines 60-62}.
As per claim 39, the rejection of claim 34 is incorporated and Nix wherein the network interface SOC is configured to receive the chipset update binary {“into an ECDH key exchange in order to mutually derive a shared secret key M 410 fabric”, see Fig. 4a, Col 52, lines 36-37}, from the cloud server, via a Wi-Fi access point using a Wi-Fi interface {“for WiFi [interface] can be preferred, since unicast messages are acknowledged at the data link layer.”, Col 51, lines 42-44}}.
Referring to claims 45, 46, 47, 48, and 49 are method claims reciting claim functionality corresponding to the system claim of claims 2, 3, 4, 5, and 6, respectively, thereby rejected under the same rationale as claims 2, 3, 4, 5, and 6 recited above.
Claims 7, 8, 9, 10, 17, 18, 19, 20, 30, 31, 32, 33, 40, 41, 42, 43, 50, 51, 52, and 53 are rejected 35 U.S.C. 103 as being unpatentable over Jen in view of Stremlau and further in view of Nix and further in view of Smith and further in view of Litichever et al. (USPGPUB No. 2018/0225230 A1, hereinafter referred to as Litichever).
As per claim 7, the rejection of claim 3 is incorporated and Litichever discloses wherein the docking station is further configured to:
using the decryption engine of the MCU {“by forcing them to purchase either a [MCU/CPU] program to decrypt the files it had encrypted, or an unlock code which will remove the locks it had applied”, [0198], last sentence}, determine the chipset update binary cannot be decrypted {“the [chipset update binary] rootkit is designed to hide the existence of certain processes or programs from the normal [decryption] methods of detection”, see Fig. 1, [0201]};
and based on said determination {“Once [determined and ] installed, it becomes possible to hide…”, see Fig. 1, [0201]}, discard the chipset update binary {“When dealing with [chipset update binary] firmware rootkits, removal [/discarding] may require hardware replacement, or specialized equipment”, see Fig. 1, [0201], last sentence}.
Jen/Stremlau/Smith/Nix and Litichever are analogous because they are from the same field of endeavor, communicating between USB devices.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Jen/Stremlau/Smith/Nix and Litichever before him or her, to modify Jen/Stremlau/Smith/Nix’s system incorporating Litichever’s MCU Decryption engine (see Fig. 1 [0201]).
The suggestion/motivation for doing so would have been to implement firmware through certain browser functionality contributes to security by verifying each step in the boot process and incorporating system recovery. The system-level software includes the Linux kernel that has been patched to improve boot performance. The userland software has been trimmed to essentials, with management by Upstart, which can launch services in parallel, re-spawn crashed jobs, and defer services in the interest of faster booting (Litichever [0073], 3rd and 4th sentences).
Therefore, it would have been obvious to combine Litichever with Jen/Stremlau/Smith/Nix to obtain the invention as specified in the instant claim(s).
As per claim 8, the rejection of claim 1 is incorporated and Litichever discloses wherein updating the chipset firmware improves operation and performance of the chipset firmware {these two terms “improves operation and performance” is intended use and relative term; someone of ordinary skill in the art that changing/updating firmware intends to make a function normal or expected to the end user or person utilizing said product/device}, enables the chipset firmware to perform new services for the host device {new services “[first] Denial of Service… by stopping a [new service] malware related message from passing through the system”, see Fig. 1, [0408]}, enables the chipset firmware to operate a new host device, enables the chipset firmware to operate a new type of host device, or combinations thereof {Examiner’s note: recitation “or” term treats this dependent claim as a Markush claim, thus the reference needs only disclose one element in the Markush group to address the claim}.
The 103 motivation recited for this dependent claim relied upon as recited in claim 7 above.
As per claim 9, the rejection of claim 1 is incorporated and Litichever discloses wherein the docking station is configured to operate the MCU {“Tiva TM4C Microcontroller… available from Texas Instruments”, see Fig. 1, [0008]} to update the chipset firmware independent of the host device {“ Rootkit installation can be automated,” independent of host device “Administrator Access” or “continued privileged access to a [hots] computer” (see Fig. 1, [0201], 2nd and 3rd sentences}, such that the host device does not occupy the docking station during the update {“detection and reporting mechanism, and native hot plug functionality” hpd functionality whether or not the “PCIe” device/chipset remains with the docking station during the update as claimed (see Fig. 1, [0148], 2nd sentence)}.
The 103 motivation recited for this dependent claim relied upon as recited in claim 7 above.
As per claim 10, the rejection of claim 1 is incorporated and Litichever discloses wherein the docking station is configured to operate the MCU to update the chipset firmware independent of the host device, minimizing logistics concerns of the host device {“prefix of the URL, the Uniform Resource Identifier (URI), determines how the URL will be interpreted” (see Fig. 1, [0031]) utilizing servers as to way minimize logistics as a physical person/transportation not needed to deliver/update the chipset firmware.}, scheduling concerns of the host device, location concerns of the host device {“connect to servers on the World Wide Web, to deliver email and transfer files from one location to another” concern addressed by TCP/IP protocol [0022], 2nd sentence}, worktime interruption concerns of the host device, or combinations thereof {Examiner’s note: recitation “or” term treats this dependent claim as a Markush claim, thus the reference needs only disclose one element in the Markush group to address the claim}.
The 103 motivation recited for this dependent claim relied upon as recited in claim 7 above.
As per claims 17-20 are method claims reciting claim functionality corresponding to the system claim of claims 7-10, respectively, thereby rejected under the same rationale as claims 7-10 recited above.
As per claims 30, 31, 32, and 33 are system claims reciting claim functionality corresponding to the method claim of claims 17, 18, 19, and 20, respectively, thereby rejected under the same rationale as claims 17, 18, 19, and 20 recited above.
As per claim 40, the rejection of claim 36 is incorporated however neither one of the group consisting of recites any limitation in this dependent claim.
Furthermore, Litichever discloses wherein the docking station is further configured to:
using the decryption engine of the MCU {“by forcing them to purchase either a [MCU/CPU] program to decrypt the files it had encrypted, or an unlock code which will remove the locks it had applied”, [0198], last sentence}, determine the chipset update binary cannot be decrypted {“the [chipset update binary] rootkit is designed to hide the existence of certain processes or programs from the normal [decryption] methods of detection”, see Fig. 1, [0201]};
and based on said determination {“Once [determined and ] installed, it becomes possible to hide…”, see Fig. 1, [0201]}, discard the chipset update binary {“When dealing with [chipset update binary] firmware rootkits, removal [/discarding] may require hardware replacement, or specialized equipment”, see Fig. 1, [0201], last sentence}.
The 103 motivation for this dependent claim relied upon as recited in claim 7 above.
As per claim 41, the rejection of claim 34 is incorporated however neither one of the group consisting of recites any limitation in this dependent claim.
Furthermore, Litichever discloses wherein updating the chipset firmware improves operation and performance of the chipset firmware {these two terms “improves operation and performance” is intended use and relative term; someone of ordinary skill in the art that changing/updating firmware intends to make a function normal or expected to the end user or person utilizing said product/device}, enables the chipset firmware to perform new services for the host device {new services “[first] Denial of Service… by stopping a [new service] malware related message from passing through the system”, see Fig. 1, [0408]}, enables the chipset firmware to operate a new host device, enables the chipset firmware to operate a new type of host device, or combinations thereof {Examiner’s note: recitation “or” term treats this dependent claim as a Markush claim, thus the reference needs only disclose one element in the Markush group to address the claim}.
The 103 motivation for this dependent claim relied upon as recited in claim 7 above.
As per claim 42, the rejection of claim 34 is incorporated however neither one of the group consisting of recites any limitation in this dependent claim.
Furthermore, Litichever discloses wherein the docking station is configured to operate the MCU {“Tiva TM4C Microcontroller… available from Texas Instruments”, see Fig. 1, [0008]} to update the chipset firmware independent of the host device {“ Rootkit installation can be automated,” independent of host device “Administrator Access” or “continued privileged access to a [hots] computer” (see Fig. 1, [0201], 2nd and 3rd sentences}, such that the host device does not occupy the docking station during the update {“detection and reporting mechanism, and native hot plug functionality” hpd functionality whether or not the “PCIe” device/chipset remains with the docking station during the update as claimed (see Fig. 1, [0148], 2nd sentence)}.
The 103 motivation for this dependent claim relied upon as recited in claim 7 above.
As per claim 43, the rejection of claim 34 is incorporated however neither one of the group consisting of recites any limitation in this dependent claim.
Furthermore, Litichever discloses wherein the docking station is configured to operate the MCU to update the chipset firmware independent of the host device, minimizing logistics concerns of the host device {“prefix of the URL, the Uniform Resource Identifier (URI), determines how the URL will be interpreted” (see Fig. 1, [0031]) utilizing servers as to way minimize logistics as a physical person/transportation not needed to deliver/update the chipset firmware.}, scheduling concerns of the host device, location concerns of the host device {“connect to servers on the World Wide Web, to deliver email and transfer files from one location to another” concern addressed by TCP/IP protocol [0022], 2nd sentence}, worktime interruption concerns of the host device, or combinations thereof {Examiner’s note: recitation “or” term treats this dependent claim as a Markush claim, thus the reference needs only disclose one element in the Markush group to address the claim}.
The 103 motivation for this dependent claim relied upon as recited in claim 7 above.
Referring to claims 50, 51, 52, and 53 are method claims reciting claim functionality corresponding to the method claim of claims 30, 31, 32, and 33, respectively, thereby rejected under the same rationale as claims 30, 31, 32, and 33 recited above.
Response to Arguments
Applicant’s arguments filed on 03/17/2026 have been considered but deemed moot in view of the following explanation:
Applicant alleges the Jen and Smith reference fails to cure the deficiencies of the Stremlau reference teachings of claim 1’s “disclose receive, from the network interface SOC, chipset update binary for updating the chipset firmware for the chipset of the docking station, the chipset update binary including a signature;
determine, by the MCU, that the chipset update binary is signed;
validate, using the validation engine of the MCU, the chipset update binary based on validating the received signature without input from the host device;” (Remarks page 14, last two full paragraphs preceding “Independent Claim 11” subsection) on the basis of other contrasts between Stremlau’s EC and the claim language (Remarks page 13 last sentence through page 14, 1st two paragraphs).
The Examiner will elaborate on the claim language, and then draw parallels to the references, in particular Stremlau. The “comprising” preamble renders the claim open-ended, meaning elements/structure/steps undisclosed can be included as long as they support or don’t materially affect the claimed steps/elements/structure. Claim 1 recites receiving the contested chipset update binary which the chipset update binary including a signature; which element generating said “signature” is not disclosed/defined in any claim, as long as the signature is included when the binary is sent from point A to B (chipset of the docking station). The Stremlau citation already indicated/illustrated in Figure 3 this functionality/claim interpretation [0066] “step 320”: “the component itself may receive the first firmware update data along with the public key(s), [signatures] first digital certificate, and second digital certificate”.
The rest of the arguments are contingent on this functionality and thus rendered unpersuasive in lieu of the rebuttal above.
For these reasons the current ground of rejection(s) is respectfully maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The following references indicative the current state of the art regarding claim 1’s “USB”/universal serial bus, “MCU”/microcontroller, or “docking station”: US 11106796 B2, US 11194562 B2, US 20210056208 A1, US 20230418590 A1.
THIS ACTION IS MADE FINAL. 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 extension fee 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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER A. BARTELS whose telephone number is (571)270-3182. The examiner can normally be reached on Monday-Friday 9:00a-5:30pm EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Dr. Henry Tsai can be reached on 571-272-4176. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C. B./
Examiner, Art Unit 2184
/HENRY TSAI/Supervisory Patent Examiner, Art Unit 2184
Prosecution Insights