DETAILED ACTION
This action is in response to new application titled “DISTRIBUTED LEDGER APPLIANCE AND METHODS OF USE” filed 1/10/2025. Claims 1-20 were received for consideration.
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 .
Priority
Acknowledgment is made of applicant's claim for foreign priority under 35 U.S.C. 119(a)-(d). The certified copy has been received.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 1/31/2025, 2/13/2025 and 12/09/225 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant's arguments filed 8/13/2026 have been fully considered.
Applicant's arguments that Smith not teach “negotiate, with the peer device, one or more blockchain parameters” have been fully considered but they are not persuasive. Smith teaches “negotiate, with the peer device, one or more blockchain parameters” in paragraph paragraph 0056 i.e. the PoW algorithm for a given broker 108-116 is jointly approved by all the brokers 108-116, so the generation and application of the difficulty correction factor d to a particular broker 108-116 is a collective decision among the brokers 108-116).
This clearly teaches negotiate since the PoW algorithm is jointly approved by all the brokers 108-116 and the application of the difficulty correction factor d to a particular broker 108-116 is a collective decision among the brokers 108-116.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 5-9, 11-15 and 17-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Smith et al (US 2018/0287915).
With respect to claim 1 Smith teaches a user apparatus, comprising:
a processor apparatus (see Smith figure 8 element 812 Interface Processor and paragraph 0083);
a data interface in data communication with the processor apparatus, the data interface configured to communicate via a fog network (see Smith figure 8 element 820);
a blockchain processing module in data communication with the processor apparatus (see Smith figure 8 element 306), the blockchain processing module comprising at least one characterized memory (see Smith figure 8 element 813) configured to provide a first performance with a first operating parameter (see Smith figure 6 element 602 and paragraph 0069 i.e. performance metric(s) can be collected for a processor, storage, network, FPGA, power management, and/or other subsystem that can affect the broker's ability to process a PoW function); and
a non-transitory computer readable medium storing instructions which, when executed by the processor apparatus (see Smith paragraph 0061 i.e. As mentioned above, the example processes of FIGS. 5-7 may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a tangible computer readable storage medium such as a hard disk drive), cause the user apparatus to:
discover a peer device (see Smith figure 1 network brokers 108, 110, 112, 114 and 116);
negotiate, with the peer device, one or more blockchain parameters (see Smith paragraph 0056 i.e. the PoW algorithm for a given broker 108-116 is jointly approved by all the brokers 108-116, so the generation and application of the difficulty correction factor d to a particular broker 1-8-116 is a collective decision among the brokers 108-116);
create a blockchain data structure based on the one or more blockchain parameters (see Smith paragraph 0020 i.e. blockchain of message brokers); and
record one or more transactions with the peer device in the blockchain data structure (see Smith paragraph 0044 i.e. The contents of the ledger module 304 can be shared among all brokers 108-116 so that each broker 108-116 has a record of each message and/or other transaction facilitated by the broker 108-116 and stored in the ledger module 304, for example).
With respect to claim 5 Smith teaches the user apparatus of claim 1, wherein the processor apparatus is further configured via the instructions to identify a proof-of-work schema based on the one or more blockchain parameters (see Smith paragraph 0056 i.e. the PoW algorithm for a given broker 108-116 is jointly approved by all the brokers 108-116, so the generation and application of the difficulty correction factor d to a particular broker 1-8-116 is a collective decision among the brokers 108-116 and paragraph 0067-0068 i.t. the PoW for the broker 108-116 can be adjusted based on the feedback).
With respect to claim 6 Smith teaches the user apparatus of claim 5, wherein the processor apparatus is further configured via the instructions to mine proof-of-work based on the proof-of-work schema (see Smith paragraph 0056 i.e. the PoW algorithm for a given broker 108-116 is jointly approved by all the brokers 108-116, so the generation and application of the difficulty correction factor d to a particular broker 1-8-116 is a collective decision among the brokers 108-116).
With respect to claim 7 Smith teaches the user apparatus of claim 6, wherein the processor apparatus is further configured via the instructions to transmit the proof-of-work to the peer device (see Smith paragraph 0046-0047 i.e. In certain examples, brokers 108-116 can validate new messages and/or other message updates according to a validation protocol. For example, the validation protocol defines a process by which devices (e.g., brokers 108-122) of the computer network 100 agree on changes and/or additions to the distributed ledger 304. For example, the validation protocol may include the proof-of-work (PoW) protocol and/or other public consensus protocol, private validation protocol, custom validation protocol, etc. The distributed ledger 304 enables brokers 108-122 in the computer network 100 to agree, via the verification protocol, on the validity and timeliness of a message to subscriber(s) 118-122 and/or other additions to the distributed ledger (e.g., to include updates, to delete updates, to reject updates, etc.)).
With respect to claim 8 Smith teaches the user apparatus of claim 1, wherein the processor apparatus is further configured via the instructions to: receive a proposed proof-of-work from the peer device; and validate the proposed proof-of-work; wherein the proposed proof-of-work is added to a blockchain data structure based on that a community of peer devices achieve consensus on validity of the proposed proof-of work (see Smith paragraph 0046-0047 i.e. In certain examples, brokers 108-116 can validate new messages and/or other message updates according to a validation protocol. For example, the validation protocol defines a process by which devices (e.g., brokers 108-122) of the computer network 100 agree on changes and/or additions to the distributed ledger 304. For example, the validation protocol may include the proof-of-work (PoW) protocol and/or other public consensus protocol, private validation protocol, custom validation protocol, etc. The distributed ledger 304 enables brokers 108-122 in the computer network 100 to agree, via the verification protocol, on the validity and timeliness of a message to subscriber(s) 118-122 and/or other additions to the distributed ledger (e.g., to include updates, to delete updates, to reject updates, etc.)).
With respect to claim 9 Smith teaches a method, comprising:
discovering, by a user apparatus, a peer device over a network (see Smith figure 1 network brokers 108, 110, 112, 114 and 116);
negotiating, by the user apparatus and with the peer device, one or more blockchain parameters (see Smith paragraph 0056 i.e. the PoW algorithm for a given broker 108-116 is jointly approved by all the brokers 108-116, so the generation and application of the difficulty correction factor d to a particular broker 1-8-116 is a collective decision among the brokers 108-116);
creating, by the user apparatus, a blockchain data structure based on the one or more blockchain parameters (see Smith paragraph 0020 i.e. blockchain of message brokers); and
recording, by the user apparatus, one or more transactions with the peer device in the blockchain data structure (see Smith paragraph 0044 i.e. The contents of the ledger module 304 can be shared among all brokers 108-116 so that each broker 108-116 has a record of each message and/or other transaction facilitated by the broker 108-116 and stored in the ledger module 304, for example).
With respect to claim 11 Smith teaches the method of claim 9, further comprising: identifying, by the user apparatus, a proof-of-work schema based on the one or more blockchain parameters (see Smith paragraph 0056 i.e. the PoW algorithm for a given broker 108-116 is jointly approved by all the brokers 108-116, so the generation and application of the difficulty correction factor d to a particular broker 1-8-116 is a collective decision among the brokers 108-116 and paragraph 0067-0068 i.t. the PoW for the broker 108-116 can be adjusted based on the feedback).
With respect to claim 12 Smith teaches the method of claim 11, further comprising: mining, by the user apparatus, proof-of-work based on the proof-of-work schema (see Smith paragraph 0056 i.e. the PoW algorithm for a given broker 108-116 is jointly approved by all the brokers 108-116, so the generation and application of the difficulty correction factor d to a particular broker 1-8-116 is a collective decision among the brokers 108-116 and paragraph 0067-0068 i.t. the PoW for the broker 108-116 can be adjusted based on the feedback).
With respect to claim 13 Smith teaches the method of claim 12, further comprising: transmitting, by the user apparatus, the proof-of-work to the peer device (see Smith paragraph 0046-0047 i.e. In certain examples, brokers 108-116 can validate new messages and/or other message updates according to a validation protocol. For example, the validation protocol defines a process by which devices (e.g., brokers 108-122) of the computer network 100 agree on changes and/or additions to the distributed ledger 304. For example, the validation protocol may include the proof-of-work (PoW) protocol and/or other public consensus protocol, private validation protocol, custom validation protocol, etc. The distributed ledger 304 enables brokers 108-122 in the computer network 100 to agree, via the verification protocol, on the validity and timeliness of a message to subscriber(s) 118-122 and/or other additions to the distributed ledger (e.g., to include updates, to delete updates, to reject updates, etc.)).
With respect to claim 14 Smith teaches the method of claim 9, further comprising: receiving, in the user apparatus, a proposed proof-of-work from the peer device; and validating the proposed proof-of-work; wherein the proposed proof-of-work is added to the blockchain data structure based on that a community of peer devices achieve consensus on validity of the proposed proof-of work (see Smith paragraph 0046-0047 i.e. In certain examples, brokers 108-116 can validate new messages and/or other message updates according to a validation protocol. For example, the validation protocol defines a process by which devices (e.g., brokers 108-122) of the computer network 100 agree on changes and/or additions to the distributed ledger 304. For example, the validation protocol may include the proof-of-work (PoW) protocol and/or other public consensus protocol, private validation protocol, custom validation protocol, etc. The distributed ledger 304 enables brokers 108-122 in the computer network 100 to agree, via the verification protocol, on the validity and timeliness of a message to subscriber(s) 118-122 and/or other additions to the distributed ledger (e.g., to include updates, to delete updates, to reject updates, etc.)).
With respect to claim 15 Smith teaches a non-transitory computer storage medium storing instructions which, when executed on a user apparatus, cause the user apparatus to perform a method, comprising:
discovering, by a user apparatus, a peer device over a network (see Smith figure 1 network brokers 108, 110, 112, 114 and 116);
negotiating, by the user apparatus and with the peer device, one or more blockchain parameters (see Smith paragraph 0056 i.e. the PoW algorithm for a given broker 108-116 is jointly approved by all the brokers 108-116, so the generation and application of the difficulty correction factor d to a particular broker 1-8-116 is a collective decision among the brokers 108-116);
creating, by the user apparatus, a blockchain data structure based on the one or more blockchain parameters (see Smith paragraph 0020 i.e. blockchain of message brokers); and
recording, by the user apparatus, one or more transactions with the peer device in the blockchain data structure (see Smith paragraph 0044 i.e. The contents of the ledger module 304 can be shared among all brokers 108-116 so that each broker 108-116 has a record of each message and/or other transaction facilitated by the broker 108-116 and stored in the ledger module 304, for example).
With respect to claim 17 Smith teaches the non-transitory computer storage medium of claim 15, wherein the method further comprises: identifying, by the user apparatus, a proof-of-work schema based on the one or more blockchain parameters (see Smith paragraph 0056 i.e. the PoW algorithm for a given broker 108-116 is jointly approved by all the brokers 108-116, so the generation and application of the difficulty correction factor d to a particular broker 1-8-116 is a collective decision among the brokers 108-116 and paragraph 0067-0068 i.t. the PoW for the broker 108-116 can be adjusted based on the feedback).
With respect to claim 18 Smith teaches the non-transitory computer storage medium of claim 17, wherein the method further comprises: mining, by the user apparatus, proof-of-work based on the proof-of-work schema (see Smith paragraph 0056 i.e. the PoW algorithm for a given broker 108-116 is jointly approved by all the brokers 108-116, so the generation and application of the difficulty correction factor d to a particular broker 1-8-116 is a collective decision among the brokers 108-116 and paragraph 0067-0068 i.t. the PoW for the broker 108-116 can be adjusted based on the feedback).
With respect to claim 19 Smith teaches the non-transitory computer storage medium of claim 18, wherein the method further comprises: transmitting, by the user apparatus, the proof-of-work to the peer device (see Smith paragraph 0046-0047 i.e. In certain examples, brokers 108-116 can validate new messages and/or other message updates according to a validation protocol. For example, the validation protocol defines a process by which devices (e.g., brokers 108-122) of the computer network 100 agree on changes and/or additions to the distributed ledger 304. For example, the validation protocol may include the proof-of-work (PoW) protocol and/or other public consensus protocol, private validation protocol, custom validation protocol, etc. The distributed ledger 304 enables brokers 108-122 in the computer network 100 to agree, via the verification protocol, on the validity and timeliness of a message to subscriber(s) 118-122 and/or other additions to the distributed ledger (e.g., to include updates, to delete updates, to reject updates, etc.)).
With respect to claim 20 Smith teaches the non-transitory computer storage medium of claim 15, wherein the method further comprises: receiving, in the user apparatus, a proposed proof-of-work from the peer device; and validating the proposed proof-of-work; wherein the proposed proof-of-work is added to the blockchain data structure based on that a community of peer devices achieve consensus on validity of the proposed proof-of work (see Smith paragraph 0046-0047 i.e. In certain examples, brokers 108-116 can validate new messages and/or other message updates according to a validation protocol. For example, the validation protocol defines a process by which devices (e.g., brokers 108-122) of the computer network 100 agree on changes and/or additions to the distributed ledger 304. For example, the validation protocol may include the proof-of-work (PoW) protocol and/or other public consensus protocol, private validation protocol, custom validation protocol, etc. The distributed ledger 304 enables brokers 108-122 in the computer network 100 to agree, via the verification protocol, on the validity and timeliness of a message to subscriber(s) 118-122 and/or other additions to the distributed ledger (e.g., to include updates, to delete updates, to reject updates, etc.)).
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) 2-4, 10 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Smith et al (US 2018/0287915) in view of Madisetti et al (US 2019/0018888).
With respect to claim 2 Smith teaches the user apparatus of claim 1, but does not disclose wherein the one or more blockchain parameters ensure a minimum security of the blockchain data structure.
Madisetti teaches wherein the one or more blockchain parameters ensure a minimum security of the blockchain data structure (see Madisetti paragraph 0111-0113 i.e. The levels of Decentralization (L.sub.D), Scalability (L.sub.Sc) and Security (L.sub.Se) for blockchain networks are tunable subject to the following constraints: L.sub.Sc(1/L.sub.D).sup.ac(1/L.sub.Se).sup.b. where exponents a and b are dependent on the blockchain platform. The Decentralization, Scalability and Security (DSS) constraints according to an embodiment of the present invention are described as follows: Scalability and Security: The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases 214. For example, a scaling-up measure such as reducing block interval period (to decrease transaction latency) reduces the level of security due to larger number of stale blocks being produced which do not contribute to the network security. Inversely, as scalability decreases, security increases 212).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Madisetti to have tuned the blockchain network to prioritization scalability or security based of the needs of the blockchain. The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases. Inversely, as scalability decreases, security increases (see Madisetti paragraphs 0111-0113). Therefore one would have been motivated to have prioritized at least one of: scalability, security.
With respect to claim 3 Smith teaches the user apparatus of claim 1, but does not disclose wherein the one or more blockchain parameters ensure a minimum scalability of the blockchain data structure.
Madisetti teaches wherein the one or more blockchain parameters ensure a minimum scalability of the blockchain data structure (see Madisetti paragraph 0111-0113 i.e. The levels of Decentralization (L.sub.D), Scalability (L.sub.Sc) and Security (L.sub.Se) for blockchain networks are tunable subject to the following constraints: L.sub.Sc(1/L.sub.D).sup.ac(1/L.sub.Se).sup.b. where exponents a and b are dependent on the blockchain platform. The Decentralization, Scalability and Security (DSS) constraints according to an embodiment of the present invention are described as follows: Scalability and Security: The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases 214. For example, a scaling-up measure such as reducing block interval period (to decrease transaction latency) reduces the level of security due to larger number of stale blocks being produced which do not contribute to the network security. Inversely, as scalability decreases, security increases 212).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Madisetti to have tuned the blockchain network to prioritization scalability or security based of the needs of the blockchain. The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases. Inversely, as scalability decreases, security increases (see Madisetti paragraphs 0111-0113). Therefore one would have been motivated to have prioritized at least one of: scalability, security.
With respect to claim 4 Smith teaches the user apparatus of claim 1, but does not disclose wherein the one or more blockchain parameters ensure a minimum immutability of the blockchain data structure.
Madisetti teaches wherein the one or more blockchain parameters ensure a minimum immutability of the blockchain data structure (see Madisetti paragraph 0111-0113 i.e. The levels of Decentralization (L.sub.D), Scalability (L.sub.Sc) and Security (L.sub.Se) for blockchain networks are tunable subject to the following constraints: L.sub.Sc(1/L.sub.D).sup.ac(1/L.sub.Se).sup.b. where exponents a and b are dependent on the blockchain platform. The Decentralization, Scalability and Security (DSS) constraints according to an embodiment of the present invention are described as follows: Scalability and Security: The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases 214. For example, a scaling-up measure such as reducing block interval period (to decrease transaction latency) reduces the level of security due to larger number of stale blocks being produced which do not contribute to the network security. Inversely, as scalability decreases, security increases 212).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Madisetti to have tuned the blockchain network to prioritization scalability or security based of the needs of the blockchain. The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases. Inversely, as scalability decreases, security increases (see Madisetti paragraphs 0111-0113). Therefore one would have been motivated to have prioritized at least one of: scalability, security.
With respect to claim 10 Smith teaches the method of claim 9, but does not disclose wherein the one or more blockchain parameters are configured to ensure a minimum security of the blockchain data structure, a minimum scalability of the blockchain data structure, or a minimum immutability of the blockchain data structure.
Madisetti teaches wherein the one or more blockchain parameters are configured to ensure a minimum security of the blockchain data structure, a minimum scalability of the blockchain data structure, or a minimum immutability of the blockchain data structure (see Madisetti paragraph 0111-0113 i.e. The levels of Decentralization (L.sub.D), Scalability (L.sub.Sc) and Security (L.sub.Se) for blockchain networks are tunable subject to the following constraints: L.sub.Sc(1/L.sub.D).sup.ac(1/L.sub.Se).sup.b. where exponents a and b are dependent on the blockchain platform. The Decentralization, Scalability and Security (DSS) constraints according to an embodiment of the present invention are described as follows: Scalability and Security: The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases 214. For example, a scaling-up measure such as reducing block interval period (to decrease transaction latency) reduces the level of security due to larger number of stale blocks being produced which do not contribute to the network security. Inversely, as scalability decreases, security increases 212).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Madisetti to have tuned the blockchain network to prioritization scalability or security based of the needs of the blockchain. The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases. Inversely, as scalability decreases, security increases (see Madisetti paragraphs 0111-0113). Therefore one would have been motivated to have prioritized at least one of: scalability, security.
With respect to claim 16 Smith teaches the non-transitory computer storage medium of claim 15, but does not disclose wherein the one or more blockchain parameters are configured to ensure a minimum security of the blockchain data structure, a minimum scalability of the blockchain data structure, or a minimum immutability of the blockchain data structure, or any combination thereof.
Madisetti teaches wherein the one or more blockchain parameters are configured to ensure a minimum security of the blockchain data structure, a minimum scalability of the blockchain data structure, or a minimum immutability of the blockchain data structure, or any combination thereof (see Madisetti paragraph 0111-0113 i.e. The levels of Decentralization (L.sub.D), Scalability (L.sub.Sc) and Security (L.sub.Se) for blockchain networks are tunable subject to the following constraints: L.sub.Sc(1/L.sub.D).sup.ac(1/L.sub.Se).sup.b. where exponents a and b are dependent on the blockchain platform. The Decentralization, Scalability and Security (DSS) constraints according to an embodiment of the present invention are described as follows: Scalability and Security: The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases 214. For example, a scaling-up measure such as reducing block interval period (to decrease transaction latency) reduces the level of security due to larger number of stale blocks being produced which do not contribute to the network security. Inversely, as scalability decreases, security increases 212).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Madisetti to have tuned the blockchain network to prioritization scalability or security based of the needs of the blockchain. The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases. Inversely, as scalability decreases, security increases (see Madisetti paragraphs 0111-0113). Therefore one would have been motivated to have prioritized at least one of: scalability, security.
Conclusion
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 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 DEVIN E ALMEIDA whose telephone number is (571)270-1018. The examiner can normally be reached on Monday-Thursday from 7:30 A.M. to 5:00 P.M. The examiner can also be reached on alternate Fridays from 7:30 A.M. to 4:00 P.M.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Rupal Dharia, can be reached on 571-272-3880. 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).
/DEVIN E ALMEIDA/Examiner, Art Unit 2492
Prosecution Insights