DETAILED ACTION
In response to the communication filed on 12/17/2025, responded in following:
On this Office Action, claims 1-20, consisting of independent claims 1, 18, 19 and 20.
Claims 1-20 are pending.
Claims 1, 8-9, 15-20 are rejected under the 35 USC § 102.
Claims 2-3 and 5-7 are rejected under the 35 USC § 103.
Claims 4 and 10-14 are objected to as being dependent upon a rejected base claim.
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 filed in parent Application No. PCT/EP2021/056538, filed on 03/15/2021.
Examiner’s Note
Claim 20 recites “a computer readable storage medium.” Upon review of the specification, as reproduced blew, the storage medium is construed as “non-transitory computer readable storage medium.”
“[0147] A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.”
Response to Amendment
The amendment filed 12/17/2025 has been entered.
Claims 1-18 have been amended.
Response to Arguments
As per Claims Objections
Applicant’s arguments with respect to Claim Objection have been fully considered and are persuasive. The objections has been withdrawn.
As per Claim Rejections - 35 USC § 112
Applicant’s arguments with respect to claim Rejections under 35 USC § 112 have been fully considered and are persuasive. The rejections has been withdrawn.
As per Claim Rejections - 35 USC § 101
Applicant’s arguments with respect to claim Rejections under 35 USC § 101 have been fully considered and are persuasive. The rejections has been withdrawn.
As per Claim Rejections - 35 USC § 103
With respect to the arguments on page13-14, in respect to the argument below:
“In the rejection of claim 1, the examiner refers, with respect to this feature, to paragraph 137 of Williams where it is mentioned that "each input block 720 produced by consensus contains a set of ingress messages", but this does not disclose the feature that the computation of the random seed is performed only after a consensus on the respective payload has been reached.
On the contrary, in paragraph 137 of Williams it is clearly specified that the input block produced by the consensus component 63 contains the set of execution parameters which may include a random seed. And this clearly teaches that the random seed is produced by the consensus component, is part of the input blocks (the payload) produced by the consensus component and hence produced before or as part of the consensus on the payload, but not after a consensus on the payload has been reached.”
The argued limitations are reproduced below:
“perform consecutive computations of a random seed for each of the payloads of the sequence of payloads; and
the respective computation of the random seed for a respective payload is performed only after a consensus on the respective payload has been reached”
Applicant's arguments filed on have been fully considered but they are not persuasive. The examiner disagrees with the applicant’s argument. Williams explicitly discloses that pseudo-randomness in execution is computed based on a random seed that included in blocks produced by the consensus process.
As the reproduced in Figure 7 of Williams provided below, Williams discloses a consensus component 63, which is a subnet consensus component that runs a consensus protocol.
PNG
media_image1.png
607
596
media_image1.png
Greyscale
As acknowledged by the applicant, Williams discloses that the consensus component 63 produces blocks 720 containing a set of ingress messages 713, a set of inter-subnet messages 711, 712 and execution parameters 714 (EP), including a random seed.
A queue of input blocks 720 is produced, and the random seed included in each block may be computed, for example, to achieve pseudo-randomness during execution, as described in paragraph [0053].
For example, when the messaging component 61 invokes the execution component 62 (see FIG. 6 provided below or paragraphs [0126]-[0127], which describe interactions among the messaging component 61, the execution component 62 and the consensus component 63), the execution component computes pseudo-randomness using the random seed included in the input block in order to execute the induction pool during an execution cycle, as described in paragraph [0147].
PNG
media_image2.png
347
455
media_image2.png
Greyscale
Accordingly, Williams teaches that pseudo-randomness is computed after consensus and is explicitly based on the random seed contained in the consensus-produced block. For this reason, the examiner determines that the consecutive computations of a random seed is after the consensus, as claimed, the argument is unpersuasive and the rejection is maintained.
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.
Claims 1, 8-9, 15-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Williams et al. (US 20220377133 A1, hereinafter “Williams”).
Regarding claim 1, (Currently amended) Williams discloses a distributed network, the distributed network comprising
a replicated computing cluster, the replicated computing cluster comprising a plurality of nodes (Williams: [0194] According to embodiments, each of the plurality of subnets 11 is configured to run a separate subnet protocol client 42 on its corresponding nodes 10), wherein each of the plurality of nodes of the replicated computing cluster comprises one or more hardware processors and memory, and is configured to run a replica and each of the replicas is configured to run one or more computational units (Williams: [0093] The distributed network 100 comprises a plurality of nodes 10, which may also be denoted as network nodes 10 or computing nodes 10. Each of the plurality of nodes 10 is configured to run one or more computational units);
the replicated computing cluster being configured (Williams: Refer to the workflow of the consensus component 63, messaging component 61 and execution component 62 of the subnet protocol client 42 in Figs.6 and 7) to
perform consecutive consensus rounds to reach a consensus on a sequence of payloads (Williams: [0120] FIG. 6 shows a schematic block diagram of protocol components 600 of a subnet protocol client, e.g. of the subnet protocol client 42; [0122] The protocol components 600 comprise a messaging component 61 … and an execution component 62 … a consensus component 63 configured to run a consensus protocol; [0134] FIG. 7 shows an exemplary visualization of a workflow 700 of the messaging protocol and the consensus protocol and the associated components, e.g. of the messaging component 61 and the consensus component 63 of FIG. 6 (“perform consensus”, See below); [0150] In each round, the execution component 61 will execute certain messages from the induction pool by reading and updating the state of the respective computational unit and return any outgoing messages the executed computational unit wants to send; [0159] the messaging component is clocked by input blocks IB produced by the consensus component. The input blocks are numbered by the consensus component in a consecutive order (“perform consecutive consensus”), denoted as execution height or height index and are processed by the messaging component in that order; [0222] The message payload comes directly from the message M, i.e., it is not interpreted by the system);
perform consecutive processing rounds comprising a consecutive processing of the sequence of payloads in a deterministic and replicated manner (Williams: [0127] Such an identical replication is achieved according to embodiments on the one hand by virtue of the consensus component 63 that ensures that the stream of inputs to the messaging component 61 is agreed upon by the respective subnet and thus identical for all nodes, more particularly by all honest nodes (“consecutive processing”). On the other hand, this is achieved by the fact that the messaging component 61 and the execution component 62 are configured to perform a deterministic and replicated computation (“in a deterministic and replicated manner”));
perform consecutive computations of a random seed for each of the payloads of the sequence of payloads (Williams: [0053] The random seed may be used e.g. to achieve pseudo-randomness in execution if needed; [0137] The consensus component 63 is configured to receive and process the inter-subnet messages 711, 712 of the subnets SNA, SNC and the ingress messages 713 of the users U and to generate a queue of input blocks 720 from the inter-subnet messages 711, 712 and the ingress messages 713 according to a predefined consensus mechanism that is executed by the corresponding consensus protocol. Each input block 720 produced by consensus contains a set of ingress messages 713, a set of inter-subnet messages 711, 712 and execution parameters 714, EP. The execution parameters 714, EP may include in particular a random seed (“a random seed”), a designated execution time and/or a height index; [0147] the messaging component 61 invokes the execution component 62 (see FIG. 6) to execute as much of the induction pool as is feasible during a single execution cycle, providing the designated execution time and the random seed (“perform consecutive computations of a random seed”) as additional inputs); and
use the random seed of a respective payload of the sequence of payloads to provide randomness to the payload (Williams: [0053] The random seed may be used e.g. to achieve pseudo-randomness in execution if needed. The height index may e.g. be an ascending index of the input blocks to facilitate an in-order processing of the input blocks);
wherein the respective computation of the random seed for a respective payload is performed only after a consensus on the respective payload has been reached (Williams: [0137] The consensus component 63 is configured to receive and process the inter-subnet messages 711, 712 of the subnets SNA. … Each input block 720 produced by consensus contains a set of ingress messages 713 (“only after a consensus on the respective payload has been reached”), a set of inter-subnet messages 711, 712 and execution parameters 714, EP. The execution parameters 714, EP may include in particular a random seed (“use the random seed”); [0147] the messaging component 61 invokes the execution component 62 (see FIG. 6) to execute as much of the induction pool as is feasible during a single execution cycle, providing the designated execution time and the random seed as additional inputs; [0049] the network is configured to perform a plurality of processing loops in a sequential order with an increasing height index N, wherein N is an increasing integer).
Regarding claim 8, (Currently amended) Williams discloses the distributed network according to claim 1, wherein the distributed network is configured to perform a consecutive processing of input blocks of a blockchain, wherein each of the input blocks comprises a payload of the sequence of payloads (Williams: [0107] The network 100 may be in particular a proof-of-stake blockchain network; [0222] The message payload comes directly from the message M, i.e., it is not interpreted by the system).
Regarding claim 9, (Currently amended) Williams discloses the distributed network according to claim 1, wherein each of the replicas is configured to process during each of the consecutive processing rounds a batch comprising the payload of the respective processing round and a random seed (Williams: [0150] In each round, the execution component 61 will execute certain messages from the induction pool by reading and updating the state of the respective computational unit and return any outgoing messages the executed computational unit wants to send; [0147] the messaging component 61 invokes the execution component 62 (see FIG. 6) to execute as much of the induction pool as is feasible during a single execution cycle, providing the designated execution time and the random seed as additional inputs).
Regarding claim 15, (Currently amended) Williams discloses the distributed network according to claim 1, wherein the distributed network is configured to derive during a respective processing round a plurality of random values from the random seed of the respective processing round (Williams: [0049] the network is configured to perform a plurality of processing loops in a sequential order with an increasing height index N, wherein N is an increasing integer; [0053] The random seed may be used e.g. to achieve pseudo-randomness in execution if needed; [0137] The execution parameters 714, EP may include in particular a random seed, a designated execution time and/or a height index).
Regarding claim 16, (Currently amended) Williams discloses the distributed network according to claim 15, wherein the distributed network is configured to run a pseudorandom number generator, the pseudorandom number generator being configured to use the random seed of a respective processing round as input seed value (Williams: [0049] the network is configured to perform a plurality of processing loops in a sequential order with an increasing height index N, wherein N is an increasing integer; [0053] The random seed may be used e.g. to achieve pseudo-randomness in execution if needed; [0137] The execution parameters 714, EP may include in particular a random seed, a designated execution time and/or a height index).
Regarding claim 17, (Currently amended) Williams discloses the distributed network according to claim 1, wherein the distributed network comprises a plurality of subnetworks, wherein each of the plurality of subnetworks comprises a set of assigned nodes, wherein replicas of the assigned nodes of the plurality of subnetworks are configured to perform a deterministic and replicated computation across their respective subnetworks, thereby forming a plurality of replicated computing clusters (Williams: [0011] The network is further configured to individually execute, by an execution subset of the plurality of nodes, a set of execution messages in a deterministic manner, thereby mutating the unit states of one or more of the computational units of the execution subset; [0014] the unit states of the computational units of the execution subset are replicated across the execution subset. This may be in particular facilitated by performing an active replication in space of the unit state of the computational units on each node of the execution subset).
Regarding independent claims 18, Williams discloses a node for a distributed network, the node comprising one or more hardware processors and memory (Williams: [0194] According to embodiments, each of the plurality of subnets 11 is configured to run a separate subnet protocol client 42 on its corresponding nodes 10; [0214] The components of network node 10 may include, but are not limited to, one or more processors or processing units 1815, a system memory 1820), wherein the node is configured to run a replica, wherein the replica is configured to
participate in consecutive consensus rounds to reach a consensus on a sequence of payloads (Williams: [0120] FIG. 6 shows a schematic block diagram of protocol components 600 of a subnet protocol client, e.g. of the subnet protocol client 42; [0122] The protocol components 600 comprise a messaging component 61 … and an execution component 62 … a consensus component 63 configured to run a consensus protocol; [0134] FIG. 7 shows an exemplary visualization of a workflow 700 of the messaging protocol and the consensus protocol and the associated components, e.g. of the messaging component 61 and the consensus component 63 of FIG. 6 (“perform consensus”, See below); [0150] In each round, the execution component 61 will execute certain messages from the induction pool by reading and updating the state of the respective computational unit and return any outgoing messages the executed computational unit wants to send; [0159] the messaging component is clocked by input blocks IB produced by the consensus component. The input blocks are numbered by the consensus component in a consecutive order (“perform consecutive consensus”), denoted as execution height or height index and are processed by the messaging component in that order; [0222] The message payload comes directly from the message M, i.e., it is not interpreted by the system);
perform consecutive processing rounds comprising a consecutive processing of the sequence of payloads in a deterministic and replicated manner (Williams: [0127] Such an identical replication is achieved according to embodiments on the one hand by virtue of the consensus component 63 that ensures that the stream of inputs to the messaging component 61 is agreed upon by the respective subnet and thus identical for all nodes, more particularly by all honest nodes (“consecutive processing”). On the other hand, this is achieved by the fact that the messaging component 61 and the execution component 62 are configured to perform a deterministic and replicated computation (“in a deterministic and replicated manner”));
participate in consecutive computations of a random seed for each of the payloads of the sequence of payloads (Williams: [0053] The random seed may be used e.g. to achieve pseudo-randomness in execution if needed; [0137] The consensus component 63 is configured to receive and process the inter-subnet messages 711, 712 of the subnets SNA, SNC and the ingress messages 713 of the users U and to generate a queue of input blocks 720 from the inter-subnet messages 711, 712 and the ingress messages 713 according to a predefined consensus mechanism that is executed by the corresponding consensus protocol. Each input block 720 produced by consensus contains a set of ingress messages 713, a set of inter-subnet messages 711, 712 and execution parameters 714, EP. The execution parameters 714, EP may include in particular a random seed (“a random seed”), a designated execution time and/or a height index; [0147] the messaging component 61 invokes the execution component 62 (see FIG. 6) to execute as much of the induction pool as is feasible during a single execution cycle, providing the designated execution time and the random seed (“perform consecutive computations of a random seed”) as additional inputs); and
use the random seed of a respective payload of the sequence of payloads to provide randomness to the payload (Williams: [0053] The random seed may be used e.g. to achieve pseudo-randomness in execution if needed. The height index may e.g. be an ascending index of the input blocks to facilitate an in-order processing of the input blocks); wherein the respective computation of the random seed for a respective payload is performed only after a consensus on the respective payload has been reached (Williams: [0137] The consensus component 63 is configured to receive and process the inter-subnet messages 711, 712 of the subnets SNA. … Each input block 720 produced by consensus contains a set of ingress messages 713 (“only after a consensus on the respective payload has been reached”), a set of inter-subnet messages 711, 712 and execution parameters 714, EP. The execution parameters 714, EP may include in particular a random seed (“use the random seed”); [0147] the messaging component 61 invokes the execution component 62 (see FIG. 6) to execute as much of the induction pool as is feasible during a single execution cycle, providing the designated execution time and the random seed as additional inputs; [0049] the network is configured to perform a plurality of processing loops in a sequential order with an increasing height index N, wherein N is an increasing integer).
Regarding independent claims 19 and 20, they are a method and a computer program product comprising a computer readable storage medium having program instructions that respectively corresponds to claim 1. Therefore, the claims are rejected for at least the same reasons as claim 1.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 2-3 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Williams et al. (US 20220377133 A1, hereinafter “Williams”) in view of Yakira et al. (US 20220038264 A1, hereinafter “Yakira”).
Regarding claim 2, (Currently amended) Williams discloses all elements of the current invention as stated above. Williams discloses the distributed network according to claim 1, wherein the distributed network is configured to perform the computation of the random seed by
performing a threshold-signature protocol on a predefined input value of a respective processing round, thereby creating a threshold-signature on the predefined input value (Williams: [0031] the execution subset of nodes is configured to run a threshold-signature algorithm to certify the one or more certified parts. Hence the signature may be embodied as a threshold-signature; [0154 and 156] The certification component 820 may correspond to the certification component 65 a of FIG. 6. the certification component 820 is configured to run a threshold-signature algorithm to certify the one or more certified parts).
However, Williams does not disclose “using the threshold-signature as random seed.”
In a same field of endeavor, Yakira teaches the random seed by using the threshold-signature as random seed (Yakira: [0027] This requires using unique threshold signatures (a subset of threshold signatures such as the BLS signatures discussed below), and allows the system to generate a common unpredictable, verifiable, random seed even in the presence of untrusted entities, with no an ability to predict or generate it without t+1 valid signatures).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the subnet protocol client disclosed by Williams with the teachings of Yakira to use the threshold-signature as random seed. One of ordinary skill in the art would have been motivated to make this modification because threshold signatures, especially when using the BLS signature scheme, offer significant benefits in secure multi-party signing, including enhanced security, reduced risk of single point of failure, and efficient signature aggregation.
Regarding claim 3, (Currently amended) the combination of Williams and Yakira teaches all elements of the current invention as stated above. Williams discloses the distributed network according to claim 2, wherein
the consecutive processing rounds are numbered with a consecutive processing round number; and the predefined input value of a respective processing round is the processing round number (Williams: [0049] the network is configured to perform a plurality of processing loops in a sequential order with an increasing height index N, wherein N is an increasing integer. The plurality of processing loops are configured to perform, at a first loop step, the consensus protocol, to individually execute, at a second loop step, the selection of execution messages and to make, at a third loop step, the read snapshot).
Regarding claim 5, (Currently amended) the combination of Williams and Yakira teaches all elements of the current invention as stated above. Yakira teaches the distributed network according to claim 2, wherein the threshold-signature protocol is the Boneh-Lynn-Shacham (BLS)-signature protocol (Yakira: [0027] This requires using unique threshold signatures (a subset of threshold signatures such as the BLS signatures discussed below); [0164-0165] Signature Scheme (client program) (Threshold BLS): This client can have functionalities such as: Sign a message (or, produce a signature share for a message)).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the subnet protocol client disclosed by Williams with the teachings of Yakira to include the threshold-signature protocol that is the Boneh-Lynn-Shacham (BLS)-signature protocol. One of ordinary skill in the art would have been motivated to make this modification because threshold signatures, especially when using the BLS signature scheme, offer significant benefits in secure multi-party signing, including enhanced security, reduced risk of single point of failure, and efficient signature aggregation.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Williams et al. (US 20220377133 A1, hereinafter “Williams”) in view of Yakira et al. (US 20220038264 A1, hereinafter “Yakira”) as applied to claims above, and further in view of Camenisch et al. (US 20230269092 A1, hereinafter “Camenisch”).
Regarding claim 6, (Currently amended) the combination of Williams and Yakira teaches all elements of the current invention as stated above. However, the combination does not disclose, Camenisch in a same filed of endeavor discloses the distributed network according to claim 2, wherein the distributed network is configured to
perform a distributed key generation protocol for or by the plurality of nodes of the replicated computing cluster (Camenisch: [0049] The method comprises generating for each of the plurality of subnets, by a distributed key generation protocol, an individual static verification key of a public-key signature scheme and a first set of corresponding secret key shares for a first set of nodes of the respective subnet),
thereby generating a verification key of a public-key threshold signature scheme and a set of corresponding secret key shares for the nodes of the replicated computing cluster; and perform the threshold-signature protocol with the set of secret key shares (Camenisch: [0103] The static verification keys pk.sub.X are generated by a distributed key generation protocol. The distributed key generation protocol generates a first set of corresponding secret key shares sks.sub.1, sks.sub.2, sks.sub.n, i.e. a first set of secret key shares that correspond to the respective static verification key pk.sub.x. The first set of secret key shares are assigned to a first set of nodes of the respective subnet. The first set of nodes may be in particular the nodes of the respective subnet at a time t.sub.0, wherein the time t.sub.0 may be e.g. the time of the creation of the respective subnet. The verification keys pk.sub.X are verification keys of a public-key signature scheme. Accordingly, the verification keys pk.sub.X may be used to verify a joint signature that has been created by the nodes which hold the secret key shares sks.sub.1, sks.sub.2, sks.sub.n. The distributed key generation protocol may be in particular a threshold key generation protocol).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the subnet protocol client disclosed by Williams with the teachings of Camenisch to perform a distributed key generation protocol for or by the plurality of nodes of the replicated computing cluster, thereby generating a verification key of a public-key threshold signature scheme and a set of corresponding secret key shares for the nodes of the replicated computing cluster; and perform the threshold-signature protocol with the set of secret key shares. One of ordinary skill in the art would have been motivated to make this modification because the system may use the same static verification key to verify information provided by a respective subnet of the network (para.[0020]).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Williams et al. (US 20220377133 A1, hereinafter “Williams”) in view of Pimienta et al. (US 20200020065 A1, hereinafter “Pimienta”).
Regarding claim 7, (Currently amended) Williams teaches all elements of the current invention as stated above. However, Williams does not disclose, Pimienta in a same field of endeavor discloses the distributed network according to claim 1, wherein the distributed network is configured to perform the computation of the random seed by performing a coin-flipping protocol (Pimienta: [0093] our system relies on a random seed to determine a random outcome, where the random seed is provided by your computer when you request a coin flip).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the subnet protocol client disclosed by Williams with the teachings of Pimienta to perform the computation of the random seed by performing a coin-flipping protocol. One of ordinary skill in the art would have been motivated to make this modification because the coin flipping is easy to understand, simply to perform, and a true 50% chance of predicting the correct outcome (i.e., the odd of heads or tails is 50/50). This is important because it provides the user with a gaming activity that (i) everyone knows and (ii) neither the host (e.g., house) nor the user (e.g., player) has the advantage (para.[0043]).
Allowable Subject Matter
Claims 4 and 10-14 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Camenisch et al. (US 20220383304 A1): [0138] The computational units that run on the nodes 100 can be used by a user of the network 100 to perform or request computational tasks or services, in particular application services. The computational units of the network 100 may execute in particular execution messages from a current set of execution messages. The execution messages may comprise in particular unit-to-unit messages which are exchanged between the computational units of the network and/or ingress messages, i.e. messages which are received from external sources, in particular from users of the network. The network 100 is configured such that at first a consensus protocol is performed to reach a consensus on a selection and processing order of execution messages from a respective current set of execution messages. Depending on the number of nodes 10 in the network 100, the consensus protocol is advantageously not performed by all nodes of the network, but by only a subset of the nodes 10 of the network 100, which is in the following denoted as consensus subset SS1. The consensus subset SS1 may also be denoted as consensus subset. The nodes of the consensus subset SS1 are accordingly configured to run the consensus protocol to reach a consensus on a selection and processing order of execution messages from the current set of execution message.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW SUH whose telephone number is (571)270-5524. The examiner can normally be reached 9:00 AM- 5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Carl Colin can be reached at (571) 272-3862. 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.
/ANDREW SUH/ Examiner, Art Unit 2493