DETAILED ACTION
Claim Objections
Claim 2 is objected to because of the following informalities:
Step 2.2 of claim 2 should be amended to clarify that the Select_Field primitive sets the value of the selected field to a random value as indicated in [0083] of the specification, for example. As currently worded, the function of the Select_Field primitive is not completely clear.
Appropriate correction is required.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1 and 4-6 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 1: the scope of the phrase “sending and controlling, by a programmable switch, the initial traffic set sent from the server group by using a pipeline processor according to traffic control requirements of hardware compatible primitives,” is indefinite. Specifically, it is unclear how the initial traffic set is both sent and controlled. The claim should be amended to clarify how each of these actions (sending and controlling) is performed on the initial traffic set.
Regarding claim 4: first, the phrase “the class of attack traffic generation primitive” does not have antecedent basis in the claims.
Further, the phrases “wherein the task T needs to change header structures of the data packets or payloads, and these header structures or payloads are disabled on the switch due to switch resource limitations”, “determines whether P belongs to the class of attack traffic generation primitive,” and “wherein when P belongs to the attack traffic generation primitive, P is incompatible with the switch resources, and is added to the hardware incompatible primitive set Ωserver ; otherwise, P is classified into the hardware compatible primitive set”.
In particular, it is unclear how to determine whether a specific primitive is an “attack traffic generation primitive” as the distinction between “attack traffic” and other traffic is not clear.
Further, the first limitation above states that the “header structures and payloads are disabled”. The scope of this limitation is unclear. It appears to mean that the headers and payloads cannot be processed by the switch. If Applicant intends this to mean changing or setting of the header structures or payloads is disabled, the claim should be amended to clarify this scope.
In addition, first and third limitations above appear to contract one another. As noted above, the first limitation can be read as meaning the changing or setting of the header structures or payloads is disabled by the switch and thus not compatible with the switch. The third limitation then clearly states that the distinction between compatible and incompatible primitives is based on whether the primitives are “attack traffic generation primitives”. That is, if a primitive is an attack traffic generation primitive, it is incompatible with the switch resources. However, primitives which are not attack traffic generation primitives, but need to change header structures or payloads appear to be incompatible based on the first limitation and compatible based on the third limitation. The claim should be reworded to clarify exactly how the determination of primitive classification is performed.
Regarding claim 5: first, the phrase “the primitive Set_Packet_Structure(Lheader)” does not have antecedent basis in the claims.
Regarding claim 6: first, the phrase “the traffic control configuration extracted in the step (4)” does not have antecedent basis in the claims. Specifically, step (4) in claim 1 does not disclose extracting traffic control configuration.
Regarding claim 6: first, the phrase “the total number of times N” does not have antecedent basis in the claims.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitations uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are: “a task intention primitive module”, “a task intention primitive classification module”, “an initial traffic generation module”, “a server-switch interaction module”, and “a traffic control module” in claim 8.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have these limitations interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitations recite sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112(b/f)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 8 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 8: claim limitations “a task intention primitive module”, “a task intention primitive classification module”, “an initial traffic generation module”, “a server-switch interaction module”, and “a traffic control module” invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, as indicated above. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the functions.
In particular, the specification describes these modules in elements 123 and 124 of Figure 3 and the corresponding descriptions in [0097]-[00102], for example. These paragraphs describe the function performed by these modules (Figure 3 is described as a “flow chart”), but do not describe the structure required by 35 U.S.C. 112(f). That is, because the “a task intention primitive module”, “a task intention primitive classification module”, “an initial traffic generation module”, “a server-switch interaction module”, and “a traffic control module” invoke 35 U.S.C. 112(f), the structure is limited to that described in the specification. However, because the specification does not provide sufficient structure for these modules, the scope of these claim limitations is indefinite.
Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claim Rejections - 35 USC § 112(a/f)
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 8 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement.
The claims contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor, at the time the application was filed, had possession of the claimed invention.
In particular, as noted above, claim limitations “a task intention primitive module”, “a task intention primitive classification module”, “an initial traffic generation module”, “a server-switch interaction module”, and “a traffic control module” invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Further, as noted in the rejection under 35 U.S.C. 112(b), the specification describes the function of these modules, but does not provide the required structural support. Thus, in addition to being indefinite (because the scope of the claim is not clear as articulated in the 35 U.S.C. 112(b) rejection), the claim is similarly rejected for failing to comply with the written description requirement. That is, the original disclosure does not provide a written description of the structure of the limitations “a task intention primitive module”, “a task intention primitive classification module”, “an initial traffic generation module”, “a server-switch interaction module”, and “a traffic control module”. Therefore, claim 8 is rejected under 35 U.S.C. 112(a).
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1 and 8 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Zhang et al (“HyperTester: High-Performance Network Testing Driven by Programmable Switches”; IEEE/ACM Transactions on Networking).
Regarding claim 1: Zhang discloses a large-scale traffic generation method based on programmable network technology, comprising:
step (1) generating task intention primitives, wherein the task intention primitives comprise traffic generation primitives and traffic control primitives for clearly expressing an intent of a large-scale traffic generation task (see the network testing API (NTAPI) described throughout; in particular, see the HTStream APIs in section IV and Table I; as indicated in the first full paragraph in column 1 on page 2008, these APIs are provided to “facilitate the specification of network testing intents”; see also the second bullet in column 1 of page 2006 (“We provide a NTAPI to help operators express their intents on network testing”); further, these APIs include both traffic generation APIs/primitives (such as “template” and “ports”) that specify traffic to generate and traffic control APIs/primitives (such as “rate” and “burst”), which as indicated in section B on page 2010 are for “traffic control”);
step (2) classifying the task intention primitives, comprising: classifying the large-scale traffic generation task expressed by the task intention primitives into a hardware compatible primitive set and a hardware incompatible primitive set according to whether the task intention primitives are compatible with a resource limitation of a switch (disclosed throughout; as indicated in the third paragraph of section A in column 2 on page 2007, the operations are split between the switch CPU and the switch ASIC (“Template-based packet generation properly divides the packet generation labor between the switch CPU and the switch ASIC” and indicates that the switch CPU performs “operations that are hard for the switch ASIC” such as generating origin packets; these operations that are hard for the switch ASIC are interpreted as hardware incompatible APIs/primitives);
step (3) generating an initial traffic, comprising: configuring a server group based on the task intention primitives in the hardware incompatible primitive set to generate data packets that meet task requirements, and creating an initial traffic set (disclosed throughout; the switch CPU (interpreted as a server) performs the task intention primitives/APIs that are “hard for the switch ASIC” (incompatible), including generating template packets (initial traffic set) based on information specified in the APIs; see Figure 2 and the third paragraph of section A in column 2 on page 2007, which indicate that “the switch CPU prepares template packets with customized payloads and initialized headers”);
step (4) interacting a server with the switch, comprising: when creating the initial traffic, sending the data packets in the initial traffic set and a traffic control configuration in the hardware compatible primitive set to the switch through a link connecting the server group and the switch for controlling a subsequent traffic by a pipeline processing program of the switch (disclosed throughout; see Figures 2-4 and pages 2007-2011, for example; the server (switch CPU) interacts with the switch (switch ASIC) to send data packets in the initial traffic set (template packets in Figure 2, for example) and traffic control configuration in the hardware compatible primitive set (P4 program in Figure 2, for example) to the switch; the switch controls subsequent traffic by a pipeline processing program as described in section V “HyperTester Packet Sender”; as described in this section, the pipelines in Figure 4 use the template packets and accelerate, replicate, and edit them to create full speed packets for testing); and
step (5) controlling a traffic, comprising: sending and controlling, by a programmable switch, the initial traffic set sent from the server group by using a pipeline processor according to traffic control requirements of hardware compatible primitives, allowing the generated large-scale traffic to meet a task configuration requirement (disclosed throughout; see section V “HyperTester Packet Sender” and Figures 3 and 4, which indicate how the programmable switch (the sender in the switch ASIC) sends and controls the traffic using the initial traffic set (template packets) and the accelerator, replicator, and editor along with the rate control and burst control traffic control mechanisms to meet the requirements for different throughput and burst tests and to emulate real-world traffic as specified by the user’s intent via the APIs/primitives).
Regarding claim 8: Zhang discloses a large-scale traffic generation system based on programmable network technology, comprising:
a task intention primitive module configured to generate task intention primitives, wherein the task intention primitives comprise traffic generation primitives and traffic control primitives for clearly expressing an intent of a large-scale traffic generation task (see the network testing API (NTAPI) described throughout; in particular, see the HTStream APIs in section IV and Table I; as indicated in the first full paragraph in column 1 on page 2008, these APIs are provided to “facilitate the specification of network testing intents”; see also the second bullet in column 1 of page 2006 (“We provide a NTAPI to help operators express their intents on network testing”); further, these APIs include both traffic generation APIs/primitives (such as “template” and “ports”) that specify traffic to generate and traffic control APIs/primitives (such as “rate” and “burst”), which as indicated in section B on page 2010 are for “traffic control”);
a task intention primitive classification module configured to classify the large-scale traffic generation task expressed by the task intention primitives into a hardware compatible primitive set and a hardware incompatible primitive set according to whether the task intention primitives are compatible with a resource limitation of a switch (disclosed throughout; as indicated in the third paragraph of section A in column 2 on page 2007, the operations are split between the switch CPU and the switch ASIC (“Template-based packet generation properly divides the packet generation labor between the switch CPU and the switch ASIC” and indicates that the switch CPU performs “operations that are hard for the switch ASIC” such as generating origin packets; these operations that are hard for the switch ASIC are interpreted as hardware incompatible APIs/primitives);
an initial traffic generation module configured to configure a server group based on the task intention primitives in the hardware incompatible primitive set to generate a data packet that meet task requirements, and create an initial traffic set (disclosed throughout; the switch CPU (interpreted as a server) performs the task intention primitives/APIs that are “hard for the switch ASIC” (incompatible), including generating template packets (initial traffic set) based on information specified in the APIs; see Figure 2 and the third paragraph of section A in column 2 on page 2007, which indicate that “the switch CPU prepares template packets with customized payloads and initialized headers”);
a server-switch interaction module configured to send the data packets in the initial traffic set and a traffic control configuration in the hardware compatible primitive set to the switch through a link connecting the server group and the switch for controlling a subsequent traffic by a pipeline processing program of the switch when creating an initial traffic (disclosed throughout; see Figures 2-4 and pages 2007-2011, for example; the server (switch CPU) interacts with the switch (switch ASIC) to send data packets in the initial traffic set (template packets in Figure 2, for example) and traffic control configuration in the hardware compatible primitive set (P4 program in Figure 2, for example) to the switch; the switch controls subsequent traffic by a pipeline processing program as described in section V “HyperTester Packet Sender”; as described in this section, the pipelines in Figure 4 use the template packets and accelerate, replicate, and edit them to create full speed packets for testing); and
a traffic control module configured to send and control the initial traffic set sent from the server group by the programmable switch by using a pipeline processor according to traffic control requirements of hardware compatible primitives, allowing the generated large-scale traffic to meet a task configuration requirement (disclosed throughout; see section V “HyperTester Packet Sender” and Figures 3 and 4, which indicate how the programmable switch (the sender in the switch ASIC) sends and controls the traffic using the initial traffic set (template packets) and the accelerator, replicator, and editor along with the rate control and burst control traffic control mechanisms to meet the requirements for different throughput and burst tests and to emulate real-world traffic as specified by the user’s intent via the APIs/primitives).
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 3 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang et al (“HyperTester: High-Performance Network Testing Driven by Programmable Switches”; IEEE/ACM Transactions on Networking) in view of Cidon et al (US 2007/0195707).
Regarding claim 3: Zhang discloses the limitations of parent claim 1 as indicated above. Zhang further discloses the limitations of claim 3 that the traffic control primitives in the step (1) are configured to express a task intention of controlling the initial traffic set, and comprise following primitives:
(3.1) setting the switch port list Lport to emit the large-scale traffic: Set_Port(Lport) (disclosed throughout; see the ports API in table 1, which as indicated at the bottom of column 1 on page 2008, is used to “configure the output ports of the test traffic”);
(3.2) setting a rate γ for sending the large-scale traffic: Set_Rate(γ) (disclosed throughout; see the rate API in table 1);
(3.4) setting a duration D in seconds for sending the large-scale traffic each time: Set_Duration(D) (see section 2 Burst Control on page 2010, which discloses that the burst API indicates that length of each burst (the burst time window when the tester is to send traffic for each burst)).
Zhang does not explicitly disclose the limitations of:
(3.3) setting a total number of times Ntest for sending the large-scale traffic: Set_Number(Ntest);
(3.5) setting a time interval I in seconds for sending the large-scale traffic consecutively for two times: Set_Interval(I).
However, Cidon discloses a system which generates test traffic in bursts. Further, Cidon discloses that the bursts are configured by setting the number N of bursts as well as an interval T between the bursts (see [0052] and step 84 of Figure 4, for example). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Zhang explicitly include configuration for the number of bursts as well as the interval between bursts as suggested by Cidon. The rationale for doing so would have been to more specifically specify the test parameters for traffic bursts as suggested by Cidon.
Regarding claim 6: Zhang discloses the limitations of parent claim 1 as indicated above. Zhang further discloses the limitations of claim 6 that . Zhang does not explicitly disclose the limitations the traffic control configuration extracted in the step (4) comprises an expected sending rate γ (disclosed throughout; see the rate API in table 1), a switch port list Lport for sending the data packets (disclosed throughout; see the ports API in table 1, which as indicated at the bottom of column 1 on page 2008, is used to “configure the output ports of the test traffic”), a duration D for sending the large-scale traffic each time (see section 2 Burst Control on page 2010, which discloses that the burst API indicates that length of each burst (the burst time window when the tester is to send traffic for each burst)).
Zhang does not explicitly disclose the limitations of: the total number of times N for sending the large-scale traffic, and a time interval I for sending the large-scale traffic consecutively for two times.
However, Cidon discloses a system which generates test traffic in bursts. Further, Cidon discloses that the bursts are configured by setting the number N of bursts as well as an interval T between the bursts (see [0052] and step 84 of Figure 4, for example). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Zhang explicitly include configuration for the number of bursts as well as the interval between bursts as suggested by Cidon. The rationale for doing so would have been to more specifically specify the test parameters for traffic bursts as suggested by Cidon.
Allowable Subject Matter
Claims 2 and 7 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.
Claim 5 would be allowable if rewritten to overcome the rejections under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include 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.
Manolescu et al (US 2024/0356832) discloses a method for link multiplexing and forwarding packets in a test environment.
Bortok et al (US 2024/0171495) discloses a method for scaling network traffic and emulating a stateful transport layer protocol.
Sommers et al (US 2024/0069099) discloses a method for using a testbed transpiler to translate a portion of the test configuration information to generate configuration instructions.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Robert C Scheibel whose telephone number is (571)272-3169. The examiner can normally be reached Monday-Friday 8: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, Hassan A Phillips can be reached at 571-272-3940. 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.
Robert C. Scheibel
Primary Examiner
Art Unit 2467
/Robert C Scheibel/Primary Examiner, Art Unit 2467 June 4, 2026
Prosecution Insights