DETAILED ACTION
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on November 18, 2025 was filed in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Amendment
The Amendment filed December 12, 2025 has been entered. Claims 1-20 are pending in the application. Applicant has submitted amendments to the claims along with other remarks. Claims 1-20 are still rejected by prior art references, refer to the following rejection for details.
Response to Arguments
Applicant’s arguments and amendments, see pp. 9-13 of the response, filed December 12, 2025, with respect to the rejection(s) of claim(s) 1-20 under § 102 have been fully considered but are not persuasive, please see the rejection for details.
Regarding claim 1, Applicant states that the cited “portions of E2AP fail to disclose whether the E2 setup request message comprises the claimed interface type information for indicating a type of an E2 interface between the E2 node and the near-RT RIC among a plurality of interface types.” Importantly, Applicant recites the pre-amendment claim language of “among a plurality” instead of the post-amendment claim language of “as one of the plurality.” It is unclear whether this argument to the pre-amendment claim language is intentional or whether there is a change in scope from the previous claim language.
Further, the claim language is unclear because it recites “indicating a type of an E2 interface” from a list that includes “the E2 interface.” (“interface type information for indicating an E2 interface between the E2 node and the near-RT RIC as one of a plurality of interface types including . . . the E2 interface”). Applicant has not provided a basis for why E2AP does not teach “interface type information for indicating [itself].”
See also,
PNG
media_image1.png
500
1130
media_image1.png
Greyscale
E2AP p. 80/94
, and
PNG
media_image2.png
257
516
media_image2.png
Greyscale
3GPP TS 38.413 v.15.4.0 p. 185/324
3GPP TS 38.43 further provides “The ASN.1 definition specifies the structure and content of NGAP messages. NGAP messages can contain any IEs specified in the object set definitions for that message without the order or number of occurrence being restricted by ASN.1. However, for this version of the standard, a sending entity shall construct an NGAP message according to the PDU definitions module . . .”
For these reasons, the rejection is maintained.
Claim Rejections - 35 USC § 112
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.
Claims 1-20 are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claim(s) contains 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(s), at the time the application was filed, had possession of the claimed invention.
Applicant has introduced amendments to the claims without indicating where the original specification supported the subject matter. After reviewing the specification, it is unclear where support for these amendments is provided in the original specification.
The MPEP provides that “[w]ith respect to newly added or amended claims, applicant should show support in the original disclosure for the new or amended claims.” MPEP § 2163(II). As such, “Applicant has not pointed out where the new (or amended) claim is supported, nor does there appear to be a written description of the claim limitation ‘version information . . . based on the interface type information’ in the application as filed.” See, e.g., Hyatt v. Dudas, 492 F.3d 1365, 1370, n.4, 83 USPQ2d 1373, 1376, n.4 (Fed. Cir. 2007).
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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, 5-6, 10-11, 15-16, and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Non-patent Literature entitled, “O-RAN Working Group 3, Near-Real-time RAN Intelligent Controller, E2 Application Protocol (E2AP) (O-RAN.WG3.E2AP-v02.02)” (hereinafter “E2AP”)
Regarding claim 1, E2AP teaches: A method performed by an E2 node, the method comprising: transmitting, to a near-real time (RT) radio access network (RAN) intelligent controller (RIC), an E2 setup request message (p. 22/94 An E2 Node initiates the procedure by sending the E2 SETUP REQUEST message including the appropriate data to a Near-RT RIC. The Near-RT RIC replies with the E2 SETUP RESPONSE message including the appropriate data.); and receiving, from the near-RT RIC, an E2 setup response message (p. 22/94 The Near-RT RIC replies with the E2 SETUP RESPONSE message including the appropriate data.), wherein the E2 setup request message comprises: interface type information for indicating an E2 interface between the E2 node and the near-RT RIC as one of a plurality of interface types including, an NG interface, an XN interface, an E1 interface, a F1 interface, a W1 interface, a S1 interface, a X2 interface, and the E2 interface (p. 7/94 The E2 interface provides means for interconnecting a Near-RT RIC and an E2 Node. The E2 Application Protocol (E2AP) supports the functions of E2 interface by signalling procedures defined in the present document. E2AP is developed in accordance to the general principles stated in O-RAN E2 General Aspects & Principles [2]. 27 [10] 3GPP TS 38.410: “NG general aspects and principles”. 28 [11] 3GPP TS 38.420: “Xn general aspects and principles”. 29 [12] 3GPP TS 38.470: “F1 general aspects and principles”. 30 [13] 3GPP TS 36.410: “S1 general aspects and principles”.), and version information for indicating a version of E2 application protocol (E2AP) of a radio network layer in the E2 interface indicated based on the interface type information (p. 60/94 9.3.3 E2AP-PDU-Descriptions { 18 iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 53148 e2(1) version2 19 (2) e2ap(1) e2ap-PDU-Descriptions (0) }).
See also the inherent O-RAN Logical Architecture in Figure 1 below from Non-patent Literature entitled, “O-RAN ALLIANCE Introduces 53 New Specifications Released Since July 2022” (hereinafter “O-RAN Alliance”), which depicts the “NG interface, an XN interface, an E1 interface, a F1 interface, a W1 interface, a S1 interface, a X2 interface, and the E2 interface.”
PNG
media_image3.png
724
1037
media_image3.png
Greyscale
Figure 1
Regarding claim 5, E2AP teaches: wherein the version information indicating the version of the E2AP is used for a backward compatibility of the E2AP (p. 10/94 4.2 Forwards and Backwards Compatibility 2 The forwards and backwards compatibility of the protocol is assured by mechanism where all current and future 3 messages, and IEs or groups of related IEs, include ID and criticality fields that are coded in a standard format that will 4 not be changed in the future. These parts can always be decoded regardless of the standard version.).
Regarding claim 6, E2AP teaches: A method performed by a near-real time (RT) radio access network (RAN) intelligent controller (RIC), the method comprising: receiving, from an E2 node, an E2 setup request message (p. 22/94 An E2 Node initiates the procedure by sending the E2 SETUP REQUEST message including the appropriate data to a Near-RT RIC. The Near-RT RIC replies with the E2 SETUP RESPONSE message including the appropriate data.); and receiving, from the near-RT RIC, an E2 setup response message (p. 22/94 The Near-RT RIC replies with the E2 SETUP RESPONSE message including the appropriate data.), wherein the E2 setup request message comprises: interface type information for indicating an E2 interface between the E2 node and the near-RT RIC as one of a plurality of interface types including, an NG interface, an XN interface, an E1 interface, a F1 interface, a W1 interface, a S1 interface, a X2 interface, and the E2 interface (p. 7/94 The E2 interface provides means for interconnecting a Near-RT RIC and an E2 Node. The E2 Application Protocol (E2AP) supports the functions of E2 interface by signalling procedures defined in the present document. E2AP is developed in accordance to the general principles stated in O-RAN E2 General Aspects & Principles [2]. 27 [10] 3GPP TS 38.410: “NG general aspects and principles”. 28 [11] 3GPP TS 38.420: “Xn general aspects and principles”. 29 [12] 3GPP TS 38.470: “F1 general aspects and principles”. 30 [13] 3GPP TS 36.410: “S1 general aspects and principles”.), and version information for indicating a version of E2 application protocol (E2AP) of a radio network layer in the E2 interface indicated based on the interface type information (p. 60/94 9.3.3 E2AP-PDU-Descriptions { 18 iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 53148 e2(1) version2 19 (2) e2ap(1) e2ap-PDU-Descriptions (0) }).
See also the inherent O-RAN Logical Architecture in Figure 1 below from Non-patent Literature entitled, “O-RAN ALLIANCE Introduces 53 New Specifications Released Since July 2022” (hereinafter “O-RAN Alliance”), which depicts the “NG interface, an XN interface, an E1 interface, a F1 interface, a W1 interface, a S1 interface, a X2 interface, and the E2 interface.”
PNG
media_image3.png
724
1037
media_image3.png
Greyscale
Figure 2
Regarding claim 10, E2AP teaches: wherein the version information indicating the version of the E2AP is used for a backward compatibility of the E2AP (p. 10/94 4.2 Forwards and Backwards Compatibility 2 The forwards and backwards compatibility of the protocol is assured by mechanism where all current and future 3 messages, and IEs or groups of related IEs, include ID and criticality fields that are coded in a standard format that will 4 not be changed in the future. These parts can always be decoded regardless of the standard version.).
Regarding claim 11, E2AP teaches: A device of an E2 node, the device comprising: at least one transceiver; and at least one processor electrically connected to the at least one transceiver, wherein the at least one processor is configured to: transmit, to a near-real time (RT) radio access network (RAN) intelligent controller (RIC), an E2 setup request message, and receive, from the near-RT RIC, an E2 setup response message (p. 22/94 An E2 Node initiates the procedure by sending the E2 SETUP REQUEST message including the appropriate data to a Near-RT RIC. The Near-RT RIC replies with the E2 SETUP RESPONSE message including the appropriate data.), wherein the E2 setup request message comprises: interface type information for indicating an E2 interface between the E2 node and the near-RT RIC as one of a plurality of interface types including, an NG interface, an XN interface, an E1 interface, a F1 interface, a W1 interface, a S1 interface, a X2 interface, and the E2 interface (p. 7/94 The E2 interface provides means for interconnecting a Near-RT RIC and an E2 Node. The E2 Application Protocol (E2AP) supports the functions of E2 interface by signalling procedures defined in the present document. E2AP is developed in accordance to the general principles stated in O-RAN E2 General Aspects & Principles [2]. 27 [10] 3GPP TS 38.410: “NG general aspects and principles”. 28 [11] 3GPP TS 38.420: “Xn general aspects and principles”. 29 [12] 3GPP TS 38.470: “F1 general aspects and principles”. 30 [13] 3GPP TS 36.410: “S1 general aspects and principles”. ), and version information for indicating a version of E2 application protocol (E2AP) of a radio network layer in the E2 interface indicated based on the interface type information (p. 60/94 9.3.3 E2AP-PDU-Descriptions { 18 iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 53148 e2(1) version2 19 (2) e2ap(1) e2ap-PDU-Descriptions (0) }).
See also the inherent O-RAN Logical Architecture in Figure 1 below from Non-patent Literature entitled, “O-RAN ALLIANCE Introduces 53 New Specifications Released Since July 2022” (hereinafter “O-RAN Alliance”), which depicts the “NG interface, an XN interface, an E1 interface, a F1 interface, a W1 interface, a S1 interface, a X2 interface, and the E2 interface.”
PNG
media_image3.png
724
1037
media_image3.png
Greyscale
Figure 3
Regarding claim 15, E2AP teaches: wherein the version information indicating the version of the E2AP is used for a backward compatibility of the E2AP (p. 10/94 4.2 Forwards and Backwards Compatibility 2 The forwards and backwards compatibility of the protocol is assured by mechanism where all current and future 3 messages, and IEs or groups of related IEs, include ID and criticality fields that are coded in a standard format that will 4 not be changed in the future. These parts can always be decoded regardless of the standard version.).
Regarding claim 16, E2AP teaches: 16. A device of a near-real time (RT) radio access network (RAN) intelligent controller (RIC), the device comprising: at least one transceiver; and at least one processor electrically connected to the at least one transceiver, wherein the at least one processor is configured to: receive, from an E2 node, an E2 setup request message, and transmit, to the E2 node, an E2 setup response message (p. 22/94 An E2 Node initiates the procedure by sending the E2 SETUP REQUEST message including the appropriate data to a Near-RT RIC. The Near-RT RIC replies with the E2 SETUP RESPONSE message including the appropriate data.), wherein the E2 setup request message comprises: interface type information for indicating an E2 interface between the E2 node and the near-RT RIC as one of a plurality of interface types including, an NG interface, an XN interface, an E1 interface, a F1 interface, a W1 interface, a S1 interface, a X2 interface, and the E2 interface (p. 7/94 The E2 interface provides means for interconnecting a Near-RT RIC and an E2 Node. The E2 Application Protocol (E2AP) supports the functions of E2 interface by signalling procedures defined in the present document. E2AP is developed in accordance to the general principles stated in O-RAN E2 General Aspects & Principles [2]. 27 [10] 3GPP TS 38.410: “NG general aspects and principles”. 28 [11] 3GPP TS 38.420: “Xn general aspects and principles”. 29 [12] 3GPP TS 38.470: “F1 general aspects and principles”. 30 [13] 3GPP TS 36.410: “S1 general aspects and principles”. ), and version information for indicating a version of E2 application protocol (E2AP) of a radio network layer in the E2 interface indicated based on the interface type information (p. 60/94 9.3.3 E2AP-PDU-Descriptions { 18 iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 53148 e2(1) version2 19 (2) e2ap(1) e2ap-PDU-Descriptions (0) }).
See also the inherent O-RAN Logical Architecture in Figure 1 below from Non-patent Literature entitled, “O-RAN ALLIANCE Introduces 53 New Specifications Released Since July 2022” (hereinafter “O-RAN Alliance”), which depicts the “NG interface, an XN interface, an E1 interface, a F1 interface, a W1 interface, a S1 interface, a X2 interface, and the E2 interface.”
PNG
media_image3.png
724
1037
media_image3.png
Greyscale
Figure 4
Regarding claim 20, E2AP teaches: wherein the version information indicating the version of the E2AP is used for a backward compatibility of the E2AP(p. 10/94 4.2 Forwards and Backwards Compatibility 2 The forwards and backwards compatibility of the protocol is assured by mechanism where all current and future 3 messages, and IEs or groups of related IEs, include ID and criticality fields that are coded in a standard format that will 4 not be changed in the future. These parts can always be decoded regardless of the standard version.).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-4, 7-9, 12-14, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over E2AP in view of Non-patent Literature entitled, “ASN.1 - Communication between Heterogeneous Systems” (hereinafter “Dubuisson”).
Regarding claim 2, E2AP teaches: wherein the version information indicating the version of the E2AP and the interface type information for indicating the E2 interface are included in an E2 node component configuration addition list information element (IE) of the E2 setup request message (p. 78/94 ln. 40-42, E2AP-IEs {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 53148 e2(1) version2 (2) e2ap(1) e2ap-IEs (2)}).
E2AP does not explicitly teach: wherein the version information indicating the version of the E2AP is encoded subsequent to the information for indicating the E2 interface.
However, in the same field of endeavor, Dubuisson teaches: wherein the version information indicating the version of the E2AP is encoded subsequent to the information for indicating the E2 interface (p. 254/590 In this case, the application can provide the components to the encoder in the best order for it. Moreover, the encoder may also send these components in a different order as we shall see in Part III on the encoding rules. Dubuisson also provides for version indications and backward compatibility (p. 76/590)).
That is, Dubuisson indicates that encoding the version of the E2AP subsequent to the information indicating the E2 interface—to the extent not disclosed in NPL E2AP—is obvious to try. Whether the “information indicating the version of the E2AP is encoded subsequent to the information for indicating the E2 interface” or vice versa. That is, according to MPEP § 2143(I)(E) the claim is obvious to try because:
(1) it was known before the earliest priority date, that there is a best order for the encoder and the components may be encoded in a different order to alleviate any issues with the components not being in the optimal or desired order;
(2) there were a finite number of identified, predictable potential solutions to the recognized need or problem, which would include rearranging components in the encoding order; and
(3) Dubuisson indicates that encoding in different orders was within the abilities of one of ordinary skill in the art before the earliest priority date to find the optimal or desired order.
Therefore, claim 2 is prima facie obvious.
Regarding claim 3, E2AP teaches: wherein the information for indicating the E2 interface is included in an E2 node component configuration addition list information element (IE) of the E2 setup request message (p. 78/94 ln. 40-42, E2AP-IEs {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 53148 e2(1) version2 (2) e2ap(1) e2ap-IEs (2)}).
E2AP does not explicitly teach: wherein the version information indicating the version of the E2AP is encoded at the end of the E2 setup request message.
However, in the same field of endeavor, Dubuisson teaches: wherein the version information indicating the version of the E2AP is encoded at the end of the E2 setup request message (p. 254/590 In this case, the application can provide the components to the encoder in the best order for it. Moreover, the encoder may also send these components in a different order as we shall see in Part III on the encoding rules. Dubuisson also provides for version indications and backward compatibility (p. 76/590)).
That is, Dubuisson indicates that encoding the version of the E2AP at the end of the E2 setup request message—to the extent not disclosed in NPL E2AP—is obvious to try. Whether the “information indicating the version of the E2AP is encoded at the end of the E2 setup request message” or otherwise. That is, according to MPEP § 2143(I)(E) the claim is obvious to try because:
(1) it was known before the earliest priority date, that there is a best order for the encoder and the components may be encoded in a different order to alleviate any issues with the components not being in the optimal or desired order;
(2) there were a finite number of identified, predictable potential solutions to the recognized need or problem, which would include rearranging components in the encoding order; and
(3) Dubuisson indicates that encoding in different orders was within the abilities of one of ordinary skill in the art before the earliest priority date to find the optimal or desired order.
Therefore, claim 3 is prima facie obvious.
Regarding claim 4, E2AP teaches: wherein the E2 setup request message further comprises a message type of the E2 setup request message, a transaction identifier (ID) of the E2 setup request message (p. 59/94 9.2.33 Transaction ID 5 The Transaction ID IE uniquely identifies a procedure among all ongoing parallel procedures of the same type initiated 6 by the same protocol peer. Messages belonging to the same procedure shall use the same Transaction ID. The 7 Transaction ID is determined by the initiating peer of a procedure. 8 IE/Group Name Presence Range IE type and reference Semantics description Transaction ID M INTEGER (0..255, …)), and a global ID of the E2 node (p. 10/94Global E2 Node ID: Global identifier of an E2 Node. Defined as the global eNB or gNB identifier and an optional 20 local identifier of an CU-UP or DU which is required when and if an individual DU or CU-UP supports a direct E2 21 interface.)
E2AP does not explicitly teach: wherein the version information indicating the version of the E2AP is encoded subsequent to the global ID of the E2 node.
However, in the same field of endeavor, Dubuisson teaches: wherein the version information indicating the version of the E2AP is encoded subsequent to the global ID of the E2 node (p. 254/590 In this case, the application can provide the components to the encoder in the best order for it. Moreover, the encoder may also send these components in a different order as we shall see in Part III on the encoding rules. Dubuisson also provides for version indications and backward compatibility (p. 76/590)).
That is, Dubuisson indicates that encoding the version information indicating the version of the E2AP subsequent to the global ID of the E2 node —to the extent not disclosed in NPL E2AP—is obvious to try. Whether the “information indicating the version of the E2AP is encoded at the end of the E2 setup request message” or otherwise. That is, according to MPEP § 2143(I)(E) the claim is obvious to try because:
(1) it was known before the earliest priority date, that there is a best order for the encoder and the components may be encoded in a different order to alleviate any issues with the components not being in the optimal or desired order;
(2) there were a finite number of identified, predictable potential solutions to the recognized need or problem, which would include rearranging components in the encoding order; and
(3) Dubuisson indicates that encoding in different orders was within the abilities of one of ordinary skill in the art before the earliest priority date to find the optimal or desired order.
Therefore, claim 4 is prima facie obvious.
Regarding claim 7, E2AP teaches: wherein the version information indicating the version of the E2AP and the interface type information for indicating the E2 interface are included in an E2 node component configuration addition list information element (IE) of the E2 setup request message (p. 78/94 ln. 40-42, E2AP-IEs {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 53148 e2(1) version2 (2) e2ap(1) e2ap-IEs (2)}).
E2AP does not explicitly teach: wherein the version information indicating the version of the E2AP is encoded subsequent to the information for indicating the E2 interface.
However, in the same field of endeavor, Dubuisson teaches: wherein the version information indicating the version of the E2AP is encoded subsequent to the information for indicating the E2 interface (p. 254/590 In this case, the application can provide the components to the encoder in the best order for it. Moreover, the encoder may also send these components in a different order as we shall see in Part III on the encoding rules. Dubuisson also provides for version indications and backward compatibility (p. 76/590)).
That is, Dubuisson indicates that encoding the version of the E2AP subsequent to the information indicating the E2 interface—to the extent not disclosed in NPL E2AP—is obvious to try. Whether the “information indicating the version of the E2AP is encoded subsequent to the information for indicating the E2 interface” or vice versa. That is, according to MPEP § 2143(I)(E) the claim is obvious to try because:
(1) it was known before the earliest priority date, that there is a best order for the encoder and the components may be encoded in a different order to alleviate any issues with the components not being in the optimal or desired order;
(2) there were a finite number of identified, predictable potential solutions to the recognized need or problem, which would include rearranging components in the encoding order; and
(3) Dubuisson indicates that encoding in different orders was within the abilities of one of ordinary skill in the art before the earliest priority date to find the optimal or desired order.
Therefore, claim 7 is prima facie obvious.
Regarding claim 8, E2AP teaches: wherein the information for indicating the E2 interface is included in an E2 node component configuration addition list information element (IE) of the E2 setup request message (p. 78/94 ln. 40-42, E2AP-IEs {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 53148 e2(1) version2 (2) e2ap(1) e2ap-IEs (2)}).
E2AP does not explicitly teach: wherein the version information indicating the version of the E2AP is encoded at the end of the E2 setup request message.
However, in the same field of endeavor, Dubuisson teaches: wherein the version information indicating the version of the E2AP is encoded at the end of the E2 setup request message (p. 254/590 In this case, the application can provide the components to the encoder in the best order for it. Moreover, the encoder may also send these components in a different order as we shall see in Part III on the encoding rules. Dubuisson also provides for version indications and backward compatibility (p. 76/590)).
That is, Dubuisson indicates that encoding the version of the E2AP at the end of the E2 setup request message—to the extent not disclosed in NPL E2AP—is obvious to try. Whether the “information indicating the version of the E2AP is encoded at the end of the E2 setup request message” or otherwise. That is, according to MPEP § 2143(I)(E) the claim is obvious to try because:
(1) it was known before the earliest priority date, that there is a best order for the encoder and the components may be encoded in a different order to alleviate any issues with the components not being in the optimal or desired order;
(2) there were a finite number of identified, predictable potential solutions to the recognized need or problem, which would include rearranging components in the encoding order; and
(3) Dubuisson indicates that encoding in different orders was within the abilities of one of ordinary skill in the art before the earliest priority date to find the optimal or desired order.
Therefore, claim 8 is prima facie obvious.
Regarding claim 9, E2AP teaches: wherein the E2 setup request message further comprises a message type of the E2 setup request message, a transaction identifier (ID) of the E2 setup request message (p. 59/94 9.2.33 Transaction ID 5 The Transaction ID IE uniquely identifies a procedure among all ongoing parallel procedures of the same type initiated 6 by the same protocol peer. Messages belonging to the same procedure shall use the same Transaction ID. The 7 Transaction ID is determined by the initiating peer of a procedure. 8 IE/Group Name Presence Range IE type and reference Semantics description Transaction ID M INTEGER (0..255, …)), and a global ID of the E2 node (p. 10/94Global E2 Node ID: Global identifier of an E2 Node. Defined as the global eNB or gNB identifier and an optional 20 local identifier of an CU-UP or DU which is required when and if an individual DU or CU-UP supports a direct E2 21 interface.)
E2AP does not explicitly teach: wherein the version information indicating the version of the E2AP is encoded subsequent to the global ID of the E2 node.
However, in the same field of endeavor, Dubuisson teaches: wherein the version information indicating the version of the E2AP is encoded subsequent to the global ID of the E2 node (p. 254/590 In this case, the application can provide the components to the encoder in the best order for it. Moreover, the encoder may also send these components in a different order as we shall see in Part III on the encoding rules. Dubuisson also provides for version indications and backward compatibility (p. 76/590)).
That is, Dubuisson indicates that encoding the version information indicating the version of the E2AP subsequent to the global ID of the E2 node —to the extent not disclosed in NPL E2AP—is obvious to try. Whether the “information indicating the version of the E2AP is encoded at the end of the E2 setup request message” or otherwise. That is, according to MPEP § 2143(I)(E) the claim is obvious to try because:
(1) it was known before the earliest priority date, that there is a best order for the encoder and the components may be encoded in a different order to alleviate any issues with the components not being in the optimal or desired order;
(2) there were a finite number of identified, predictable potential solutions to the recognized need or problem, which would include rearranging components in the encoding order; and
(3) Dubuisson indicates that encoding in different orders was within the abilities of one of ordinary skill in the art before the earliest priority date to find the optimal or desired order.
Therefore, claim 9 is prima facie obvious.
Regarding claim 12, E2AP teaches: wherein the version information indicating the version of the E2AP and the interface type information for indicating the E2 interface are included in an E2 node component configuration addition list information element (IE) of the E2 setup request message (p. 78/94 ln. 40-42, E2AP-IEs {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 53148 e2(1) version2 (2) e2ap(1) e2ap-IEs (2)}).
E2AP does not explicitly teach: wherein the version information indicating the version of the E2AP is encoded subsequent to the information for indicating the E2 interface.
However, in the same field of endeavor, Dubuisson teaches: wherein the version information indicating the version of the E2AP is encoded subsequent to the information for indicating the E2 interface (p. 254/590 In this case, the application can provide the components to the encoder in the best order for it. Moreover, the encoder may also send these components in a different order as we shall see in Part III on the encoding rules. Dubuisson also provides for version indications and backward compatibility (p. 76/590)).
That is, Dubuisson indicates that encoding the version of the E2AP subsequent to the information indicating the E2 interface—to the extent not disclosed in NPL E2AP—is obvious to try. Whether the “information indicating the version of the E2AP is encoded subsequent to the information for indicating the E2 interface” or vice versa. That is, according to MPEP § 2143(I)(E) the claim is obvious to try because:
(1) it was known before the earliest priority date, that there is a best order for the encoder and the components may be encoded in a different order to alleviate any issues with the components not being in the optimal or desired order;
(2) there were a finite number of identified, predictable potential solutions to the recognized need or problem, which would include rearranging components in the encoding order; and
(3) Dubuisson indicates that encoding in different orders was within the abilities of one of ordinary skill in the art before the earliest priority date to find the optimal or desired order.
Therefore, claim 12 is prima facie obvious.
Regarding claim 13, E2AP teaches: wherein the information for indicating the E2 interface is included in an E2 node component configuration addition list information element (IE) of the E2 setup request message (p. 78/94 ln. 40-42, E2AP-IEs {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 53148 e2(1) version2 (2) e2ap(1) e2ap-IEs (2)}).
E2AP does not explicitly teach: wherein the version information indicating the version of the E2AP is encoded at the end of the E2 setup request message.
However, in the same field of endeavor, Dubuisson teaches: wherein the version information indicating the version of the E2AP is encoded at the end of the E2 setup request message (p. 254/590 In this case, the application can provide the components to the encoder in the best order for it. Moreover, the encoder may also send these components in a different order as we shall see in Part III on the encoding rules. Dubuisson also provides for version indications and backward compatibility (p. 76/590)).
That is, Dubuisson indicates that encoding the version of the E2AP at the end of the E2 setup request message—to the extent not disclosed in NPL E2AP—is obvious to try. Whether the “information indicating the version of the E2AP is encoded at the end of the E2 setup request message” or otherwise. That is, according to MPEP § 2143(I)(E) the claim is obvious to try because:
(1) it was known before the earliest priority date, that there is a best order for the encoder and the components may be encoded in a different order to alleviate any issues with the components not being in the optimal or desired order;
(2) there were a finite number of identified, predictable potential solutions to the recognized need or problem, which would include rearranging components in the encoding order; and
(3) Dubuisson indicates that encoding in different orders was within the abilities of one of ordinary skill in the art before the earliest priority date to find the optimal or desired order.
Therefore, claim 13 is prima facie obvious.
Regarding claim 14, E2AP teaches: wherein the E2 setup request message further comprises a message type of the E2 setup request message, a transaction identifier (ID) of the E2 setup request message (p. 59/94 9.2.33 Transaction ID 5 The Transaction ID IE uniquely identifies a procedure among all ongoing parallel procedures of the same type initiated 6 by the same protocol peer. Messages belonging to the same procedure shall use the same Transaction ID. The 7 Transaction ID is determined by the initiating peer of a procedure. 8 IE/Group Name Presence Range IE type and reference Semantics description Transaction ID M INTEGER (0..255, …)), and a global ID of the E2 node (p. 10/94Global E2 Node ID: Global identifier of an E2 Node. Defined as the global eNB or gNB identifier and an optional 20 local identifier of an CU-UP or DU which is required when and if an individual DU or CU-UP supports a direct E2 21 interface.)
E2AP does not explicitly teach: wherein the version information indicating the version of the E2AP is encoded subsequent to the global ID of the E2 node.
However, in the same field of endeavor, Dubuisson teaches: wherein the version information indicating the version of the E2AP is encoded subsequent to the global ID of the E2 node (p. 254/590 In this case, the application can provide the components to the encoder in the best order for it. Moreover, the encoder may also send these components in a different order as we shall see in Part III on the encoding rules. Dubuisson also provides for version indications and backward compatibility (p. 76/590)).
That is, Dubuisson indicates that encoding the version information indicating the version of the E2AP subsequent to the global ID of the E2 node —to the extent not disclosed in NPL E2AP—is obvious to try. Whether the “information indicating the version of the E2AP is encoded at the end of the E2 setup request message” or otherwise. That is, according to MPEP § 2143(I)(E) the claim is obvious to try because:
(1) it was known before the earliest priority date, that there is a best order for the encoder and the components may be encoded in a different order to alleviate any issues with the components not being in the optimal or desired order;
(2) there were a finite number of identified, predictable potential solutions to the recognized need or problem, which would include rearranging components in the encoding order; and
(3) Dubuisson indicates that encoding in different orders was within the abilities of one of ordinary skill in the art before the earliest priority date to find the optimal or desired order.
Therefore, claim 14 is prima facie obvious.
Regarding claim 17, E2AP teaches: wherein the version information indicating the version of the E2AP and the interface type information for indicating the E2 interface are included in an E2 node component configuration addition list information element (IE) of the E2 setup request message (p. 78/94 ln. 40-42, E2AP-IEs {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 53148 e2(1) version2 (2) e2ap(1) e2ap-IEs (2)}).
E2AP does not explicitly teach: wherein the version information indicating the version of the E2AP is encoded subsequent to the information for indicating the E2 interface.
However, in the same field of endeavor, Dubuisson teaches: wherein the version information indicating the version of the E2AP is encoded subsequent to the information for indicating the E2 interface (p. 254/590 In this case, the application can provide the components to the encoder in the best order for it. Moreover, the encoder may also send these components in a different order as we shall see in Part III on the encoding rules. Dubuisson also provides for version indications and backward compatibility (p. 76/590)).
That is, Dubuisson indicates that encoding the version of the E2AP subsequent to the information indicating the E2 interface—to the extent not disclosed in NPL E2AP—is obvious to try. Whether the “information indicating the version of the E2AP is encoded subsequent to the information for indicating the E2 interface” or vice versa. That is, according to MPEP § 2143(I)(E) the claim is obvious to try because:
(1) it was known before the earliest priority date, that there is a best order for the encoder and the components may be encoded in a different order to alleviate any issues with the components not being in the optimal or desired order;
(2) there were a finite number of identified, predictable potential solutions to the recognized need or problem, which would include rearranging components in the encoding order; and
(3) Dubuisson indicates that encoding in different orders was within the abilities of one of ordinary skill in the art before the earliest priority date to find the optimal or desired order.
Therefore, claim 17 is prima facie obvious.
Regarding claim 18, E2AP teaches: wherein the information for indicating the E2 interface is included in an E2 node component configuration addition list information element (IE) of the E2 setup request message (p. 78/94 ln. 40-42, E2AP-IEs {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 53148 e2(1) version2 (2) e2ap(1) e2ap-IEs (2)}).
E2AP does not explicitly teach: wherein the version information indicating the version of the E2AP is encoded at the end of the E2 setup request message.
However, in the same field of endeavor, Dubuisson teaches: wherein the version information indicating the version of the E2AP is encoded at the end of the E2 setup request message (p. 254/590 In this case, the application can provide the components to the encoder in the best order for it. Moreover, the encoder may also send these components in a different order as we shall see in Part III on the encoding rules. Dubuisson also provides for version indications and backward compatibility (p. 76/590)).
That is, Dubuisson indicates that encoding the version of the E2AP at the end of the E2 setup request message—to the extent not disclosed in NPL E2AP—is obvious to try. Whether the “information indicating the version of the E2AP is encoded at the end of the E2 setup request message” or otherwise. That is, according to MPEP § 2143(I)(E) the claim is obvious to try because:
(1) it was known before the earliest priority date, that there is a best order for the encoder and the components may be encoded in a different order to alleviate any issues with the components not being in the optimal or desired order;
(2) there were a finite number of identified, predictable potential solutions to the recognized need or problem, which would include rearranging components in the encoding order; and
(3) Dubuisson indicates that encoding in different orders was within the abilities of one of ordinary skill in the art before the earliest priority date to find the optimal or desired order.
Therefore, claim 18 is prima facie obvious.
Regarding claim 19, E2AP teaches: wherein the E2 setup request message further comprises a message type of the E2 setup request message, a transaction identifier (ID) of the E2 setup request message (p. 59/94 9.2.33 Transaction ID 5 The Transaction ID IE uniquely identifies a procedure among all ongoing parallel procedures of the same type initiated 6 by the same protocol peer. Messages belonging to the same procedure shall use the same Transaction ID. The 7 Transaction ID is determined by the initiating peer of a procedure. 8 IE/Group Name Presence Range IE type and reference Semantics description Transaction ID M INTEGER (0..255, …)), and a global ID of the E2 node (p. 10/94Global E2 Node ID: Global identifier of an E2 Node. Defined as the global eNB or gNB identifier and an optional 20 local identifier of an CU-UP or DU which is required when and if an individual DU or CU-UP supports a direct E2 21 interface.)
E2AP does not explicitly teach: wherein the version information indicating the version of the E2AP is encoded subsequent to the global ID of the E2 node.
However, in the same field of endeavor, Dubuisson teaches: wherein the version information indicating the version of the E2AP is encoded subsequent to the global ID of the E2 node (p. 254/590 In this case, the application can provide the components to the encoder in the best order for it. Moreover, the encoder may also send these components in a different order as we shall see in Part III on the encoding rules. Dubuisson also provides for version indications and backward compatibility (p. 76/590)).
That is, Dubuisson indicates that encoding the version information indicating the version of the E2AP subsequent to the global ID of the E2 node —to the extent not disclosed in NPL E2AP—is obvious to try. Whether the “information indicating the version of the E2AP is encoded at the end of the E2 setup request message” or otherwise. That is, according to MPEP § 2143(I)(E) the claim is obvious to try because:
(1) it was known before the earliest priority date, that there is a best order for the encoder and the components may be encoded in a different order to alleviate any issues with the components not being in the optimal or desired order;
(2) there were a finite number of identified, predictable potential solutions to the recognized need or problem, which would include rearranging components in the encoding order; and
(3) Dubuisson indicates that encoding in different orders was within the abilities of one of ordinary skill in the art before the earliest priority date to find the optimal or desired order.
Therefore, claim 19 is prima facie obvious.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Non-patent literature entitled, “Information technology – ASN.1 encoding rules: Specification of Packed Encoding Rules (PER)” ITU-T (2002)
U.S. Publication No. 2024/0193021 (Pateromichelakis) related to platform independent application programming interface configuration
U.S. Publication No. 2024/0243984 (Soldati) related to a method for monitoring performance of an artificial intelligence (AI)/machine learning (ML) model or algorithm
U.S. Publication No. 2022/0232452 (Sivaraj) related to a method and apparatus for unique identification of individual users in the radio access network (RAN) intelligent controller
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUSTIN BARRY whose telephone number is (571)272-0201. The examiner can normally be reached 8:00am EST to 5:00pm EST.
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, Jinsong HU can be reached at (571) 272-3965. 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.
/JAB/ Examiner, Art Unit 2643
/JINSONG HU/ Supervisory Patent Examiner, Art Unit 2643