DETAILED ACTION
Examiner acknowledges receipt of Applicant’s amendment filed 6/29/2026.
In the amendment, Applicant amended claims 1, 5, and 9-13 and cancelled claims 6-8.
Claims 1-5 and 9-13 are currently pending.
Response to Arguments
Examiner has fully considered Applicant’s arguments, see page 7, filed 6/29/2026, with respect to the objection to the specification and they are persuasive. Examiner has withdrawn the objection to the specification.
Examiner has fully considered Applicant’s arguments, see page 7, filed 6/29/2026, with respect to the rejection of claims 1-9 under 35 U.S.C. 112(b) and they are persuasive. Examiner has withdrawn the rejection of claims 1-9 under 35 U.S.C. 112(b).
Examiner has fully considered Applicant's arguments, see pages 7-8, filed 6/29/2026, with respect to the rejections of claims 1-9 under 35 U.S.C. 112(b/f) and 35 U.S.C. 112(a/f) but they are not persuasive. Applicant generally asserts that the rejection is moot in view of the claim amendments. However, the claim amendments do not appear to change the scope such that 35 U.S.C. 112(f) is not invoked. The limitation that the “setting unit” is “included in” the SMO does not provide any structural limitations for the unit itself. Therefore, the previous rejections of claims 1-9 under 35 U.S.C. 112(b/f) and 35 U.S.C. 112(a/f) are maintained herein.
Examiner has fully considered Applicant's arguments, see pages 8-11, filed 6/29/2026, with respect to the rejection of the claims under 35 U.S.C. 102 but they are not persuasive.
On pages 8-9, Applicant recites amended claim 1 and asserts that Grayson does no disclose the last limitation. Applicant then argues that Grayson does not disclose the “setting” limitation because including an IPv6 in a list of known NETCONF clients does not constitute setting the O-RU to use IPv6 as its IP protocol version. Examiner respectfully disagrees. The claim language is broad and “setting an IP Protocol version required for the O-RU to IPv6” is disclosed in Grayson. Using an IP address in IPv6 format to communicate with an O-RU that uses an IPv6 address discloses the above limitation because this sets the version (via the use of the IPv6 address) that is required “for” the O-RU.
On page 10, Applicant asserts that Grayson also does not disclose that the setting is based on information suggesting the IP version acquired from the O-RU. However, as indicated in the rejection below, the SMO acquires information suggesting the IP version (the IP address) from the O-RU via a pnfRegistration message.
On pages 10-11, Applicant discusses claim 5, asserting that Grayson does not disclose the last limitation. Applicant argues that Grayson does not disclose the limitations for reasons similar to those discussed above regarding claim 1. For reasons similar to those discussed above, Examiner respectfully disagrees.
Claim Objections
Claim 13 is objected to because of the following informalities:
Claim 5 includes the acronym NETCONF. This acronym is later spelled out in dependent claim 9. This acronym should be spelled out in its first use in claim 5.
Claim 13 includes the limitation “[a] computer readable medium”. This appears to be a typographical error as claim 12 includes “[a] non-transitory computer readable medium”. Claim 13 should be amended to include “non-transitory” for consistency.
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-5 and 9-13 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 intended scope of the term “suggesting” in line 8 is unclear and should be amended to clarify what the information acquired from the O-RU is required to include.
Claims 5 and 10-13 also include the term “suggesting” and are similarly rejected.
Regarding claim 5: the intended scope of the phrase “already implemented” in line 9 is unclear. When and where has NETCONF been implemented?
Claims 11 and 13 also include the phrase “already implemented” and are similarly rejected.
Regarding claim 9: the phrase “functions as a Network Configuration Protocol (NETCONF) client in a NETCONF implemented via an O1 interface” in combination with the phrase “functions as a NETCONF client in a NETCONF already implemented via Open Fronthaul M-Plane” is unclear. Are there two distinct NETCONFs? That is, “a NETCONF already implemented via Open Fronthaul M-Plane” and “a NETCONF implemented via an O1 interface”? Do they both acquire the information suggesting the IP version? The claims should be amended to clarify the intended scope.
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: “IP version setting unit” in claim 1 and “IP version detecting unit” in claim 5. Both of these claims use the nonce word “unit”, are modified by functional language (“setting…” and “detecting…”) and are not modified by sufficient structure, material, or acts for performing the claimed function.
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.
Claims 1-9 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 claims 1 and 5: claim limitations “an IP version setting unit” and “an IP version detecting unit” 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 11 and 12 of Figure 3 and the corresponding descriptions in [0027]-[0028], for example. These paragraphs describe the function performed by these modules, but do not describe the structure required by 35 U.S.C. 112(f). That is, because the limitations “an IP version setting unit” and “an IP version detecting unit” 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.
Claims 2-4 and 6-9 depend from claims 1 and 5 and thus include the above limitations and are also rejected under 35 U.S.C. 112(b) for reasons similar to those stated above.
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.
Claims 1-9 are 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 “an IP version setting unit” and “an IP version detecting unit” 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 “an IP version setting unit” and “an IP version detecting unit”. Therefore, claim 1 and 5 are rejected under 35 U.S.C. 112(a).
Claims 2-4 and 6-9 depend from claims 1 and 5 and thus include the above limitations and are also rejected under 35 U.S.C. 112(a) for reasons similar to those stated above.
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.
(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-13 are rejected under 35 U.S.C. 102(a)(1) and 35 U.S.C. 102(a)(2) as being anticipated by Grayson (US 2021/0314211).
Regarding claim 1: Grayson discloses a radio access network control apparatus (see the SMO 104 of Figure 1 and/or the SMO 406 of Figure 4, for example) for controlling an Open Radio Access Network (O-RAN) including an O-RAN Radio Unit (O-RU) as a radio unit (see O-RU 102 of Figure 1 and/or O-RU 402 of Figure 4, for example), the radio access network control apparatus comprising:
at least one memory storing instructions (see memory 616 of Figure 6, for example); and
at least one processor configured to execute the instructions to (see processor(s) 614 of Figure 6, for example):
by an IP version setting unit included in Service Management and Orchestration (SMO), setting an Internet Protocol version required for the O-RU to IPv6, based on information suggesting the Internet Protocol version supported by the O-RU, acquired from the O-RU (disclosed throughout; see Figure 1 and [0020], for example; the event collector sends the IP address of the NETCONF server 114 of the O-RU 102 to the NETCONF client 120; this address is either IPv6 of IPv4 as indicated in [0020] and sending the IP address sets the IP version required for the O-RU (the address and its corresponding version that the NETCONF client uses for the O-RU); the address is acquired via the pnfRegistration message, which suggests the IP version supported by the O-RU (based on the type of address sent)).
Regarding claim 5: Grayson discloses a radio access network control apparatus (see the SMO 104 of Figure 1 and/or the SMO 406 of Figure 4, for example) for controlling an Open Radio Access Network (O-RAN) including an O-RAN Radio Unit (O-RU) as a radio unit (see O-RU 102 of Figure 1 and/or O-RU 402 of Figure 4, for example), the radio access network control apparatus comprising:
at least one memory storing instructions (see memory 616 of Figure 6, for example); and
at least one processor configured to execute the instructions to (see processor(s) 614 of Figure 6, for example):
by an IP version detecting unit capable of communicating with the O-RU, detecting that IPv6 is included in the Internet Protocol version supported by the O-RU (disclosed throughout; see Figure 1 and [0020], for example; the NETCONF client 120 receives the IP address of the NETCONF server 114 in the O-RU 102; as further indicated in [0020], the IP address may be either an IPv4 or an IPv6 IP address; the NETCONF client 120 initiates a session with the NETCONF server 114 in response to detecting the address and thus determines (in the case that the IP address is IPv6) that the O-RU supports IPv6 as this is used in the establishment of the NETCONF session),
wherein the IP version detecting unit functions as a NETCONF client in NETCONF already implemented via Open Fronthaul M-Plane (disclosed throughout; see [0024], for example, which indicates that NETCONF may use a M-plane interface via the fronthaul (between O-DU and O-RU) and that this interface is defined via the O-RAN Alliance (i.e. it is already implemented)), and acquires from the O- RU that functions as a NETCONF server the information suggesting the Internet Protocol version supported by the O-RU (disclosed throughout; see Figure 1 and [0020], which indicates that the information regarding the IP address from the event collector is received from the O-RU in a pnfRegistration event/message, which suggests the IP version supported by the O-RU (based on the type of address sent)).
Regarding claim 10: Grayson discloses a radio access network control method for controlling the an Open Radio Access Network (O-RAN) including an O-RAN Radio Unit (O-RU) as a radio unit, the method comprising:
by an IP version setting unit included in Service Management and Orchestration (SMO), setting an Internet Protocol version required for the O-RU to IPv6, based on information suggesting the Internet Protocol version supported by the O-RU, acquired from the O-RU (disclosed throughout; see Figure 1 and [0020], for example; the event collector sends the IP address of the NETCONF server 114 of the O-RU 102 to the NETCONF client 120; this address is either IPv6 of IPv4 as indicated in [0020] and sending the IP address sets the IP version required for the O-RU (the address and its corresponding version that the NETCONF client uses for the O-RU); the address is acquired via the pnfRegistration message, which suggests the IP version supported by the O-RU (based on the type of address sent)).
Regarding claim 11: Grayson discloses a radio access network control method for controlling an Open Radio Access Network (O-RAN) including an O-RAN Radio Unit (O-RU) as a radio unit, the method comprising:
by an IP version detecting unit communicating with the O-RU, detecting that IPv6 is included in the Internet Protocol version supported by the O-RU (disclosed throughout; see Figure 1 and [0020], for example; the NETCONF client 120 receives the IP address of the NETCONF server 114 in the O-RU 102; as further indicated in [0020], the IP address may be either an IPv4 or an IPv6 IP address; the NETCONF client 120 initiates a session with the NETCONF server 114 in response to detecting the address and thus determines (in the case that the IP address is IPv6) that the O-RU supports IPv6 as this is used in the establishment of the NETCONF session),
wherein the IP version detecting unit functions as a NETCONF client in NETCONF already implemented via Open Fronthaul M-Plane (disclosed throughout; see [0024], for example, which indicates that NETCONF may use a M-plane interface via the fronthaul (between O-DU and O-RU) and that this interface is defined via the O-RAN Alliance (i.e. it is already implemented)), and acquires from the O-RU that functions as a NETCONF server the information suggesting the Internet Protocol version supported by the O- RU (disclosed throughout; see Figure 1 and [0020], which indicates that the information regarding the IP address from the event collector is received from the O-RU in a pnfRegistration event/message, which suggests the IP version supported by the O-RU (based on the type of address sent)).
Regarding claim 12: Grayson discloses a non-transitory computer-readable medium storing a radio access network control program for controlling an Open Radio Access Network (O-RAN) including an O-RAN Radio Unit (O-RU) as a radio unit (see O-RU 102 of Figure 1 and/or O-RU 402 of Figure 4, for example), the program causing a computer to perform (see memory 616 of Figure 6, for example):
by an IP version setting unit included in Service Management and Orchestration (SMO), setting the Internet Protocol version required for the O-RU to IPv6, based on information suggesting the Internet Protocol version supported by the O-RU, acquired from the O-RU (disclosed throughout; see Figure 1 and [0020], for example; the event collector sends the IP address of the NETCONF server 114 of the O-RU 102 to the NETCONF client 120; this address is either IPv6 of IPv4 as indicated in [0020] and sending the IP address sets the IP version required for the O-RU (the address and its corresponding version that the NETCONF client uses for the O-RU); the address is acquired via the pnfRegistration message, which suggests the IP version supported by the O-RU (based on the type of address sent)).
Regarding claim 13: Grayson discloses a computer-readable medium storing a radio access network control program for controlling an Open Radio Access Network (O-RAN} including an O-RAN Radio Unit (O-RU) as a radio unit (see O-RU 102 of Figure 1 and/or O-RU 402 of Figure 4, for example), the program causing a computer to perform (see memory 616 of Figure 6, for example):
by an IP version detecting unit, communicating with the O-RU, detecting that IPv6 is included in the Internet Protocol version supported by the O-RU (disclosed throughout; see Figure 1 and [0020], for example; the NETCONF client 120 receives the IP address of the NETCONF server 114 in the O-RU 102; as further indicated in [0020], the IP address may be either an IPv4 or an IPv6 IP address; the NETCONF client 120 initiates a session with the NETCONF server 114 in response to detecting the address and thus determines (in the case that the IP address is IPv6) that the O-RU supports IPv6 as this is used in the establishment of the NETCONF session),
wherein the IP version detecting unit functions as a NETCONF client in NETCONF already implemented via Open Fronthaul M-Plane (disclosed throughout; see [0024], for example, which indicates that NETCONF may use a M-plane interface via the fronthaul (between O-DU and O-RU) and that this interface is defined via the O-RAN Alliance (i.e. it is already implemented)), and acquires from the O-RU that functions as a NETCONF server the information suggesting the Internet Protocol version supported by the O- RU (disclosed throughout; see Figure 1 and [0020], which indicates that the information regarding the IP address from the event collector is received from the O-RU in a pnfRegistration event/message, which suggests the IP version supported by the O-RU (based on the type of address sent)).
Regarding claim 2: Grayson discloses the limitation that the IP version setting unit is capable of setting the Internet Protocol version required for the O-RU to IPv4 (disclosed throughout; as indicated in [0040], the known client list configured by the NETCONF client in the SMO or O-DU may include “an IP version 4 (IPv4) address and/or IP version 6 (IPv6) address”; see also [0020], which discloses that the address can be an IPv4 IP address).
Regarding claim 3: Grayson discloses the limitation that the IP version setting unit is capable of setting the Internet Protocol version required for the O-RU to both IPv4 and IPv6 (disclosed throughout; as indicated in [0040], the known client list configured by the NETCONF client in the SMO or O-DU may include “an IP version 4 (IPv4) address and/or IP version 6 (IPv6) address”, which clearly discloses that both IPv4 address(es) and IPv6 address(es) can be configured for the O-RU and thus the setting unit is capable of requiring the O-RU to support both IPv4 and IPv6; see also [0020], which discloses that the addresses can be IPv4 IP addresses and IPv6 IP addresses).
Regarding claim 4: Grayson discloses the limitation that the IP version setting unit is capable of setting the Internet Protocol version required for the O-RU to either IPv4, IPv6, or both IPv4 and IPv6 (disclosed throughout; as indicated in [0040], the known client list configured by the NETCONF client in the SMO or O-DU may include “an IP version 4 (IPv4) address and/or IP version 6 (IPv6) address”; see also [0020], which discloses that the addresses can be IPv4 IP addresses and IPv6 IP addresses).
Regarding claim 9: Grayson discloses the limitation that the IP version detecting unit functions as a Network Configuration Protocol (NETCONF) client in a NETCONF implemented via an O1 interface, and acquires from the O-RU that functions as a NETCONF server the information suggesting the Internet Protocol version supported by the O-RU (disclosed throughout; see Figure 1, which indicates that the SMO’s detecting unit (the NETCONF client) implements the O1 interface (122); further, the information suggesting the IP version supported by the O-RU is received from the O-RU 102, which functions as a NETCONF server (see 114)).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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 July 29, 2026
Prosecution Insights