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 .
This office correspondence is in response to “Amendment and Response under 37 C.F.R. 1.111 filed on August 6, 2026 in response to a non-final office action issued by the office on May 8, 2026.
Claims 1 – 4, 6 – 11, 13 -17, and 51 – 53 are pending.
Claims 1, 2, 4, 7, 9 -11, 13, 15, and 16 are amended.
Claims 5, 12, and 18 – 50 are cancelled.
Claims 1 – 4, 6 – 11, 13 -17, and 51 – 53 are rejected.
Applicant’s arguments filed on 8/6/2026 has been fully considered:
In regards to the objection to the specification, the applicant has adequately amended the title of the invention and the objection is withdrawn.
In regards to claims 51 – 53 which were rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, for being indefinite, the applicant states:
“ . . . . Although claims 51-53 are phrased as communication-device claims, each claim expressly refers to, and further limits, a corresponding preceding method claim, namely, claim 1, claim 9, or claim 11. Specifically, each of claims 51-53 recites a communication device comprising a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor is configured to execute the program to implement the steps of the respective referenced method claim. Thus, claims 51-53 provide further limitations of their respective referenced claims, and the dependency relationship and scope of protection are clear and definite to a person of ordinary skill in the art. Claims 51-53 therefore particularly point out and distinctly claim the subject matter regarded as the invention in accordance with 35 U.S.C. § 112(b), and further comply with the requirements for dependent claims under 35 U.S.C. § 112(d). Accordingly, Applicant respectfully submits that claims 51-53 are definite and requests withdrawal of the rejection. . . “ (Applicant remarks pages 9 – 10)
In response to the applicant’s argument:
In accordance with MPEP 806, a claim may still be independent when it references another claim and the claims are in a different category (e.g. apparatus verses process) and the claim states essential technical features and subject matter. In the case of claims 51 – 53, the claims recite a communication device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor wherein the processor is configured to execute the program to implement the steps of a specified independent claim’s method. Under this standard, claims 51 – 53 are not indefinite and the rejections under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph are withdrawn. However, claims 51 – 53 will now be interpreted under 35 U.S.C. 112(f):or pre-AIA 35 U.S.C. 112, sixth paragraph. The applicant is referenced to the Claim Interpretation section below.
In regard to claims 1 -5, 8 – 12, 15, 17, and 51 – 53 the applicant argues the prior art Gao fails to anticipate, disclose or teach:
receiving, by a first network function, first information from a first function, wherein the first information is information related to network congestion control;
generating, by the first network function, policy information at least based on the first information, and sending, by the first network function, the policy information to another network function and/or User Equipment (UE);
“wherein the first network function is a Policy Control Function (PCF), the first function is an Application Function (AF);
the first information comprises congestion information;
the congestion information in the first information indicates that an access network device adds congestion information to a data packet when network congestion occurs; or indicates that a UPF adds congestion information to a data packet when network congestion occurs; or indicates that an access network device notifies a UPF to add congestion information to a data packet when network congestion occurs.” (as recited in claim 1 and substantially replicated in claims 9 and 11)
The applicant states:
“ . . . Gao does not disclose or suggest "receiving, by a first network function, first information from a first function, wherein the first information is information related to network congestion control," as recited in claim 1. In particular, paragraph [0006] of Gao describes an access network device itself performing congestion detection on a first data flow and based on its own congestion-detection result, transmitting a data packet carrying congestion information to a UPF or UE. Thus, the congestion information in Gao is locally detected, generated, or determined by the access network device itself. Gao does not disclose that the access network device, as an alleged "first network function," receives from another "first function" any first information related to network congestion control.
The Office Action's mapping of "congestion detection on a first data flow" to the claimed "first function" is improper. Congestion detection in Gao is merely a processing operation performed by the access network device; it is not a separate functional entity that provides information to the access network device, nor is it a source from which the access network device receives the claimed first information. Moreover, the information transmission disclosed in paragraph [0006] of Gao is from the access network device to the UPF or UE, whereas claim 1 requires a transmission in the opposite relevant direction, namely, receipt by the first network function of first information from the first function. Accordingly, Gao fails to disclose or suggest this cited limitation of claim 1.
In addition, Gao also does not disclose or suggest "generating, by the first network function, policy information at least based on the first information, and sending, by the first network function, the policy information to another network function and/or User Equipment (UE) the first information comprises congestion information," as recited in claim 1. In particular, paragraph [0024] of Gao merely states that the first data flow may be a QoS flow in a PDU session that is bound to a congestion-detection policy and charging-control ("PCC") rule. At most, this passage indicates the existence of a preconfigured or previously associated PCC rule. It does not disclose that the access network device, as the alleged first network function, generates any policy information at least based on congestion-related first information. In particular, Gao does not teach or suggest that the access network device formulates, updates, or otherwise produces
policy information based on congestion information received or obtained by the access network device.
Further, paragraph [0006] of Gao discloses that the access network device, based on its
own congestion-detection result, sends to a UPF or UE a data packet whose GTP-U header or SDAP layer carries congestion information, so that a server may adjust a sending rate of the first
data flow. Such congestion information merely represents a congestion-detection result, e.g., status or parameter information. It is not policy information generated by the access network device. Nor does Gao disclose that the access network device sends policy information that it has generated to another network function and/or UE. Accordingly, Gao fails to disclose or suggest the claimed limitation of generating policy information at least based on the first information comprising congestion information and sending the policy information to another network function and/or UE.
In addition, Gao also does not disclose or suggest "the first network function is a Policy
Control Function (PCF), the first function is an Application Function (AF)", as recited in claim 1. The Office Action appears to equate Gao's access network device with the claimed first network function. However, amended claim 1 expressly and further limits the first network function to a PCF. A PCF is a control-plane network function in the 5G Core (5GC), and is not an access network device. Gao's access network device therefore cannot reasonably correspond to the claimed PCF.
Moreover, as discussed above, Gao does not disclose the claimed "first function" from
which the PCF receives first information related to network congestion control. Still less does Gao disclose that such a first function is an AF. Gao instead describes an access network device locally performing congestion detection and transmitting congestion information to a UPF or UE. It neither teaches an AF nor any communication from an AF to a PCF. Accordingly, Gao fails to disclose or suggest the claimed limitation that the first network function is a PCF and that the first function is an AF.
In addition, Gao also does not disclose or suggest "the congestion information in the first information indicates that an access network device adds congestion information to a data packet when network congestion occurs," as recited in claim 1. Paragraph [0048] of Gao merely describes a UE receiving a data packet in which first congestion information is already carried in a GTP-U header or an SDAP layer, and sending second congestion information to a server based on the first congestion information. This passage concerns the UE's receipt of pre-existing congestion information and its subsequent transmission of second congestion information. It does not disclose that the congestion information has any meaning of indicating or controlling an operation to be performed by an access network device.
In contrast, amended claim 1 expressly requires that the congestion information in the first information indicates that an access network device is to add congestion information to a data packet when network congestion occurs. In other words, the claimed congestion information is information indicating the access network device's congestion-triggered packet- marking operation. Paragraph [0048] of Gao neither discloses that an access network device receives or uses such indication information nor teaches that the access network device, in response to such information, adds congestion information to a data packet upon occurrence of network congestion. Accordingly, Gao also fails to disclose or suggest this limitation of claim 1.
In addition, Gao also does not disclose or suggest "the congestion information in the first information indicates that a UPF adds congestion information to a data packet when network congestion occurs," as recited in claim 1. Paragraph [0038] of Gao merely states that a UPF may transmit congestion information through a downlink data packet, thereby providing greater flexibility in implementing a feedback mechanism. This disclosure concerns, at most, a path for transmitting congestion information. It does not disclose an operation in which the UPF adds congestion information to a data packet, much less that such an adding operation is performed when network congestion occurs.
Moreover, amended claim 1 requires that the congestion information in the first information has an indicative function, namely, it indicates that the UPF is to add congestion information to a data packet upon occurrence of network congestion. Paragraph [0038] of Gao does not disclose or suggest any such indication provided by congestion information in the first information to the UPF, nor does it disclose or suggest that the UPF responds to such an indication by adding congestion information to a data packet. Accordingly, Gao also fails to disclose or suggest this limitation of claim 1.
In addition, Gao also does not disclose or suggest "the congestion information in the first information indicates that an access network device notifies a UPF to add congestion information to a data packet when network congestion occurs," as recited in claim 1. Paragraph [0155] of Gao merely describes an access network device separately calculating congestion- detection results between the UPF and the RAN and between the RAN and the UE, based on GTP- U packet receiving and sending timestamps. This passage concerns detecting or calculating congestion status; it does not disclose any notification interaction between the access network device and the UPF.
In contrast, amended claim 1 expressly requires that the congestion information in the first information has an indicative function, namely, it indicates that, upon occurrence of network congestion, the access network device is to notify the UPF to add congestion information to a data packet. Paragraph [0155] of Gao neither discloses congestion information in first information having such an indicative meaning nor teaches that the access network device notifies the UPF when network congestion occurs. Nor does it disclose that any such notification requests, directs, or causes the UPF to add congestion information to a data packet. Accordingly, Gao also fails to disclose or suggest this limitation of claim 1.
In addition, Kim relates to a method and apparatus for an NG-RAN to determine and notify whether Alternative QoS Profiles are guaranteed even after notifying that a QoS profile was not guaranteed; However, Kim does not remedy the deficiencies of Gao with respect to claim 1
.
Therefore, independent claim 1 should be allowable for at least these reasons.. . . “ (Applicant’s remarks pages 11 – 14)
In response to the applicant’s arguments:
The applicant’s amendments substantially changed the scope of the independent claims and triggered a new search and consideration of the amended claims to find new grounds of rejection under 35 USC 103 as being unpatentable over Gao et al. (U.S. 2025/0023823 A1; herein referred to as Gao) in view of Pan et al. (U.S. 2025/0048176 A1; herein referred to as Pan). The new prior art Pan is analogous art directed to a method and system comprising a user plane network element obtains network status information of a to-be-monitored service flow. The network status information is used to determine a ratio of a quantity of data packets carrying a congestion experienced (CE) mark in at least one data packet of the to-be-monitored service flow to a quantity of the at least one data packet of the to-be-monitored service flow. The user plane network element adds, based on the network status information, the CE mark in the at least one data packet of the to-be-monitored service flow, and sends the at least one data packet in the to-be-monitored service flow to a terminal device. The applicant is directed to the rejections that are described below.
The examiner recommends that the applicant review the specification for disclosure that if integrated into the independent claims would distinguish the amended claims from the cited prior art. The applicant is invited to contact the examiner for an interview to discuss how to move the prosecution forward.
Authorization for Internet Communications
The applicant has filed PTO/SB/439 on February 10, 2025 which is an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Priority
This application is the U.S. national phase of PCT Application No. PCT/CN2023/107026 filed on Jul. 12, 2023, which is based on, and claims the priority of, the Chinese Patent Application No. 202210957823.8 filed on Aug. 10, 2022. The applicant has provided certified priority documents and the applicant is entitled to priority date of August 10, 2022.
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 limitation(s) 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 limitation(s) is/are:
“ first network function” a first function” in claim 51 (referencing claim 1), claim 52 (referencing claim 9), claim 53 (referencing claim 11).
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
The structure is described in the instant specification Fig. 5 ¶¶ [0207-0213]
If applicant does not intend to have this/these limitation(s) 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 limitation(s) recite(s) 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.
35 USC § 101 Analysis – Judicial Exception
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
The claimed invention is directed to statutory subject matter and are not rejected under 35 USC 101 because of a judicial exception.. The claimed subject matter is integrated into a practical application under prong 2 of the Step 2A analysis as documented in MPEP 2016.04(d). The claims are directed to non-abstract improvements in computer related technology. A claim is non-statutory when it is directed to a judicial exception (e.g. either one of mathematical concepts, mental processes, or certain methods of organizing human activity) without significantly more. The claimed invention is not directed to a judicial exception. Instead, the claimed invention is directed to a technological improvement to a congestion control scheme deployed on method and system embodiments applied in communications between a network device and a terminal (UE) device, where a communication algorithm includes step 101: receiving, by a first network function, first information from a first function, wherein the first information is information related to network congestion control; generating, by the first network function, policy information at least based on the first information, and sending, by the first network function, the policy information to another network function and/or UE. In the embodiments as presented, the first network function is a network element with policy provision capability. For example, the first network function may be a Policy Control Function (PCF) in a 5G system; or may be other network elements with policy provision capability in a 6G and subsequent systems, which are not specifically limited herein. The first function may be, for example, an Application Function (AF) or an Application Server (AS) in a 5G system. In the case that the first function is the AF, the first network function may receive the first information from the AF through a Network Exposure Function (NEF). A claimed embodiment also includes sending, by a first function, first information to a first network function, wherein the first information is information related to network congestion control, and the first information is used to generate corresponding policy information. The first function may be, for example, an AF or an Application Server (AS) in a 5G system. In the case that the first function is the AF, the AF may send the first information to the first network function through the NEF. A claimed embodiment also includes receiving, by a communication device, congestion information and sending, by the communication device, first notification information, wherein the first notification information is used to notify that a network is currently in a congested state. The communication device may be a UE or a network side device (such as AS). The ordered steps of the claim language impose meaningful limits on the scope of the claims, and provides a useful improvement for the notification and recovery of a network congestion state. Therein the claimed invention is statutory under 35 USC 101.
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 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 of this title, 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.
Claims 1 – 5, 6, 7 – 11, 13, 15, 17 and 51- 53 are rejected under 35 U.S.C. 103 as being un-patentable over Gao et al. (U.S. 2025/0023823 A1; herein referred to as Gao) in view of Pan et al. (U.S. 2025/0048176 A1; herein referred to as Pan).
In regard to claim 1, Gao teaches A communication method (see abstract : . . Embodiments of this application provide a communication method. . . .”), comprising:
receiving, by a first network function (e.g. PCF), first information (e.g. congestion information) from a first function (e.g. AF) wherein the first information is information related to network congestion control (see Gao Fig. 3 ¶ ¶ [0194-0195]” . . . An AF/AS sends a message #1 to a PCF/an NEF. Specifically, the message #1 includes a congestion information notification message, and the congestion information notification message indicates a reporting manner of reporting congestion information to the AF/AS. It may be understood that the congestion information notification message may alternatively be named after another message name, or this may be understood as that the congestion information notification message is a logical summary of one or more pieces of information that indicates a reporting manner of reporting the congestion information to the AF/AS. . . “);
generating, by the first network function (e.g. PCF) policy information (e.g. PCC rule #A) at least based on the first information (e.g. message #1) (see Gao Fig. 3 ¶ ¶ [0200-0203]” . . . The PCF generates a PCC rule #A based on the message #1. Specifically, the PCF obtains a QoS parameter of a corresponding QoS flow based on the flow description included in the message #1, and generates, based on the QoS parameter, the PCC rule #A used for congestion detection. S330: An SMF binds the PCC rule #A to the QoS flow. The PCC rule #A may include information about a data flow #A (in other words, the PCC rule #A defines the data flow #A). . . .”), and sending, by the first network function, the policy information to another network function and/or User Equipment (UE) (see Gao Fig. 3 ¶ ¶ [0204-0209]” . . . The SMF may bind the PCC rule #A to a part or all of existing QoS flows that are in a PDU session, to use the bound QoS flow as a data flow on which congestion detection is to be performed. The bound QoS flow may use a QFI that is before the binding. When the PCC rule #A includes a QFI, the bound data flow may use the QFI that is in the PCC rule #A. The SMF may alternatively create a new QoS flow based on the PCC rule #A, and the QoS flow may be used to transmit data on which congestion detection needs to be performed and that is in the PDU session. An identifier of the QoS flow may be the QFI that is in the PCC rule #A. S340 (a1): The SMF sends a message #2 to a UPF. Specifically, the message #2 includes congestion detection information, and the congestion detection information may include a QFI #A and a congestion identifier, and may further include one or more of information, for example, the flow description or reporting time of the congestion information. For example, the message #2 may be an N4 setup request message, or may be an N4 modification request message. In a possible embodiment, the SMF specifically extends, via an N4 message, a context message by parameter information related to congestion detection. S340 (a2): The UPF sends a data packet #A to an access network device . . . . “);
wherein the first network function is a Policy Control Function (PCF), the first function is an Application Function (AF) (see Gao Fig. 1 ¶ [0116] “ . . . As shown in FIG. 1, a 5G system (the 5th generation system, 5GS) is used as an example of the network architecture. The network architecture may include but is not limited to: a network slice selection function (NSSF), an authentication server function (AUSF), unified data management (UDM), a network exposure function (NEF), a network repository function (NRF), a policy control function (PCF), an application function (AF), an access and mobility management function (AMF), a session management function (SMF), user equipment (UE), a radio access network device, a user plane function (UPF), and a data network (DN) . . .”) ;
the first information comprises congestion information (see Gao ¶ [0007] “ . . . the congestion information includes information about a data transmission status determined after a network device performs congestion detection on a data flow, where the information is, for example, a queue delay value, a quantity of lost packets or a packet loss rate, a buffer size or buffer proportion information, a reporting periodicity, a congestion level, and a rate reduction proportion. The congestion information may alternatively be information indicating a data transmission status, or may be related information indicating whether congestion occurs or a congestion level. This is not limited in embodiments of this application . . .”);
Gao fails to explicitly teaches,
However Pan teaches
the congestion information in the first information indicates that an access network device adds congestion information to a data packet when network congestion occurs (see Pan ¶ [0009] “ . . . an access network device may send the network status information of the to-be-monitored service flow to the user plane network element, and then the user plane network element exposes the network status information to the application server by using a transport layer. Compared with a manner in which the access network device exposes the network status information by adding an explicit congestion notification (ECN) mark to an internet protocol (IP) header of an uplink/downlink data packet, this application provides higher security because the access network device does not need to parse the IP header of the downlink data packet. In addition, the network status information does not need to be sent to the terminal device, and then is sent by the terminal device to an application server side. In this way, the network status information can be fed back more quickly. . . .”); or indicates that a UPF adds congestion information to a data packet when network congestion occurs (see Pan¶ ¶ [0301-0304] “ . . . The UPF generates, based on the network status information of the to-be-monitored service flow, the information indicating the network status. The information indicating the network status includes at least one of the following: a quantity of data packets carrying a CE mark, a quantity of payload octets of the data packets carrying the CE mark, a quantity of payload octets of data packets carrying an ECT1 mark, or a quantity of payload octets of data packets carrying an ECT0 mark. Specifically, the information that is generated by the UPF and that indicates the network status meets the following condition: A ratio of the quantity that is of data packets carrying the CE mark and that is determined based on the information indicating the network status to a quantity of the at least one data packet is for representing the network status of the to-be-monitored service flow. The network status of the to-be-monitored service flow is determined based on the network status information of the to-be-monitored service flow. For example, if it is determined, based on the network status information of the to-be-monitored service flow, that a congestion degree of the to-be-monitored service flow is 60%, the information that is generated by the UPF and that indicates the network status meets the following condition: The ratio of the quantity that is of data packets carrying the CE mark and that is determined based on the information indicating the network status to a quantity of the at least one data packet is 60%. . . .”) ; or indicates that an access network device notifies a UPF to add congestion information to a data packet when network congestion occurs (see Pan Fig. 4 ¶ [0277] “ . . . As shown in (b) in FIG. 4, a TCP header of the TCP connection establishment message #1 includes the following fields: a header length, a reserved field, an AE, CWR, ECE, a URG flag, an ACK flag, a PSH flag, an RST flag, a SYN flag, and a FIN flag. The SYN flag is set to “1”. According to the schematic diagram of the TCP header of the TCP connection establishment message shown in (b) in FIG. 4, if a SYN flag in a TCP header of a packet received by the UPF from the UE is set to “1”, the packet is the TCP connection establishment message #1. . . .”).
It would have been obvious to one skilled in the art, before the effective filing date of the applicant’s claimed invention to incorporate a method and system comprising a user plane network element obtains network status information of a to-be-monitored service flow. The network status information is used to determine a ratio of a quantity of data packets carrying a congestion experienced (CE) mark in at least one data packet of the to-be-monitored service flow to a quantity of the at least one data packet of the to-be-monitored service flow. The user plane network element adds, based on the network status information, the CE mark in the at least one data packet of the to-be-monitored service flow, and sends the at least one data packet in the to-be-monitored service flow to a terminal device, as taught by Pan, into a method and system for wireless communications that detects congestion conditions where congestion information is added to the data packet to communicate the network conditions, as taught by Gao. Such incorporation provides for different devices to process the congestion information in the packet.
In regard to claim 2, the combination of Gao and Pan teaches wherein the first information (e.g. congestion detection on a first data flow) further comprises at least one of the following:
service information (see Gao ¶ [0006] “ . . . a service data adaptation protocol SDAP layer of the first data packet . . .”) ;
a Quality of Service (QoS) requirement corresponding to service information (see Gao ¶ [0024] “ . . . the first data flow is a quality of service QoS flow that is in a protocol data unit session and that is bound to a congestion detection policy and charging control PCC rule. . . .”);
a marking frequency or duration or time interval of congestion information (see Gao ¶ [0034] “ . . . after receiving the first data packet from the access network device and obtaining the congestion information from the GTP-U header, the user plane function may mark a data packet, and then send the data packet to the server. .. .”);
notification information (see Gao ¶ [0195] “ . . . the message #1 includes a congestion information notification message, and the congestion information notification message indicates a reporting manner of reporting congestion information to the AF/AS. It may be understood that the congestion information notification message may alternatively be named after another message name, or this may be understood as that the congestion information notification message is a logical summary of one or more pieces of information that indicates a reporting manner of reporting the congestion information to the AF/AS . . .”) ; or
a QoS requirement corresponding to notification information (see Gao ¶¶ [0199-0201] “ . . . the PCF/NEF sends a subscription request message to the AF/AS. The subscription request message is used by the AF/AS to send a notification message related to the congestion information to the PCF/NEF. Correspondingly, the AS/AS receives the subscription request message. S320: The PCF generates a PCC rule #A based on the message #1. Specifically, the PCF obtains a QoS parameter of a corresponding QoS flow based on the flow description included in the message #1, and generates, based on the QoS parameter, the PCC rule #A used for congestion detection. . ..”).
In regard to claim 3, the combination of Gao and Pan teaches wherein the sending the policy information to the other network function and/or UE (see Gao ¶ [0006] as described for the rejection of claim 1 and is incorporated herein) comprises at least one of the following:
sending, by the first network function, the policy information to a Session Management Function (SMF) (see Gao ¶ [0133] “ . . . PCF: is mainly configured to guide a unified policy framework for network behavior, and provide policy rule information and the like for a control plane network element (for example, an AMF or an SMF). . . .”);
sending, by the first network function, the policy information to a User Plane Function (UPF) through a SMF (see Gao ¶¶ [0131-0132] “ . . . UPF: is mainly used for receiving and forwarding of user plane data. For example, the UPF may receive user plane data from a DN, and send the user plane data to a terminal device through an AN device. The UPF may further receive user plane data from the terminal device through the AN device, and forward the user plane data to the DN. . NEF: is mainly configured to securely expose, to the outside, a service, a capability, and the like that are provided by a 3GPP network function . . .”);
sending, by the first network function, the policy information to an access network device through an Access and Mobility Management Function (AMF) (see Gao ¶ [0140] “ . . . In the network architecture shown in FIG. 1, network elements may communicate with each other through interfaces. For example, a UE 2 is connected to the AN device via a radio resource control (RRC) protocol, and the UE and the AN device communicate with each other through a Uu interface. A UE 1 and a UE 2 communicate with each other through a PC5 interface. The PC5 interface may be used for mutual discovery between the UEs and data and signaling transmission between the UEs. In addition, in FIG. 1, N1 is an interface between the UE 2 and an AMF, N2 is an interface between the (R)AN and the AMF, and is used to send a NAS message and the like; N3 is an interface between the RAN and the UPF, and is used to transmit user plane data and the like; and N4 is an interface between the SMF and the UPF, and is used to transmit information, for example, tunnel identification information of an N3 connection, data buffer indication information, and a downlink data notification message. An N6 interface is an interface between a UPF and a DN, and is configured to transmit user plane data and the like. An N11 interface is an interface between an AMF and an SMF . . .”) ; or
sending, by the first network function, the policy information to the UE through an AMF and an access network device (see Gao ¶ [0166] “ . . . the access network device receives congestion detection information from an SMF network element. The congestion detection information includes the data flow identifier, and may further include the congestion identifier. . . .”).
In regard to claim 4, the combination of Gao and Pan teaches wherein, the service information and the QoS requirement corresponding to the service information in the first information are at least used by the UE and/or a UPF to identify data and perform QoS guarantee (see Gao ¶ [0155] “ . . . the access network device separately calculates detection results of congestion between a RAN and UE and between a UPF and the RAN based on GTP-U packet receiving and sending timestamps. For a case in which the access network device detects a congestion status between the UPF and the RAN, refer to related content of QoS monitoring in the 3GPP standard TS 23.501. This is not limited in embodiments of this application. For a case in which the access network device detects a congestion status between the RAN and the UE, refer to content in the 3GPP standard TS 38.314. This is not limited in embodiments of this application . . . “).
In regard to claim 6, the combination of Gao and Pan teaches wherein, a marking frequency, duration or time interval of the congestion information in the first information (see Gao ¶ [0034] “ . . . a GTP-U header of a data packet received by the user plane function from the access network device includes the congestion information. Protocol stacks of the access network device and the user plane function include a GTP-U layer, and the access network device and the user plane function may perform transmission of the data packet via the protocol stacks. However, an uplink transmission protocol stack of the user plane function does not include a GTP-U layer. Therefore, after receiving the first data packet from the access network device and obtaining the congestion information from the GTP-U header, the user plane function may mark a data packet, and then send the data packet to the server. . . .”) indicates a policy of adding congestion information to a data packet by an access network device or a UPF (see Gao ¶¶ [0170-0171] “ . . . A GPRS tunneling protocol (GTP) is a group of IP-based higher-layer protocols (refer to the 3GPP standard protocol 29.281) and is located above a TCP/IP protocol and a UDP/IP protocol. A user plane part of GTP (GTP-U) is a tunneling protocol based on the IP/UDP, and allows establishment of a plurality of tunnels between GTP-U entities (protocol entities). In the GTP-U, original service data sent by the UE is referred to as a transport protocol data unit (T-PDU). A T-PDU encapsulated with a GTP-U header in the GTP-U entity is referred to as a GTP encapsulated user plane data unit (G-PDU). A service data adaptation protocol (SDAP) layer is a newly added protocol layer in NR (for details, refer to the 3GPP standard protocol 37.324). Main functions of the SDAP layer include mapping between a QoS flow and a data radio bearer and a marking QoS flow ID (QFI) in downlink and uplink packets. . .”).
In regard to claim 8, the combination of Geo and Pan teaches wherein the generating, by the first network function, the policy information based on the first information (see Gao ¶ [0024] as described for the rejection of claim1 and is incorporated herein), comprising:
during a session establishment process or a session modification process (see Gao ¶ [0130] “ . . . SMF: is mainly used for user plane network element selection, user plane network element redirection, internet protocol (IP) address allocation for a terminal device, session establishment, modification, and release, and QoS control. . . .”), generating, by the first network function, the policy information based on the first information (see Gao ¶ [0320] “ . . . Optionally, the first data flow is a data flow that is in a congestion detection policy and charging control PCC rule and that is bound to a quality of service QoS flow . . .”).
In regard to claim 9, Gao teaches A communication method (see abstract : . . Embodiments of this application provide a communication method. . . .”), comprising:
sending, by a first function (e.g. AF) first information (e.g. congestion information) to a first network function (e.g. AF) wherein the first information is information related to network congestion control (see Gao Fig. 3 ¶ ¶ [0194-0195]” . . . An AF/AS sends a message #1 to a PCF/an NEF. Specifically, the message #1 includes a congestion information notification message, and the congestion information notification message indicates a reporting manner of reporting congestion information to the AF/AS. It may be understood that the congestion information notification message may alternatively be named after another message name, or this may be understood as that the congestion information notification message is a logical summary of one or more pieces of information that indicates a reporting manner of reporting the congestion information to the AF/AS. . . “), and the first information (e.g. message #1) is used to generate corresponding policy information (e.g. message #1) (see Gao Fig. 3 ¶ ¶ [0200-0209]” . . . The PCF generates a PCC rule #A based on the message #1. Specifically, the PCF obtains a QoS parameter of a corresponding QoS flow based on the flow description included in the message #1, and generates, based on the QoS parameter, the PCC rule #A used for congestion detection. S330: An SMF binds the PCC rule #A to the QoS flow. The PCC rule #A may include information about a data flow #A (in other words, the PCC rule #A defines the data flow #A. The SMF may bind the PCC rule #A to a part or all of existing QoS flows that are in a PDU session, to use the bound QoS flow as a data flow on which congestion detection is to be performed. The bound QoS flow may use a QFI that is before the binding. When the PCC rule #A includes a QFI, the bound data flow may use the QFI that is in the PCC rule #A. The SMF may alternatively create a new QoS flow based on the PCC rule #A, and the QoS flow may be used to transmit data on which congestion detection needs to be performed and that is in the PDU session. An identifier of the QoS flow may be the QFI that is in the PCC rule #A. S340 (a1): The SMF sends a message #2 to a UPF. Specifically, the message #2 includes congestion detection information, and the congestion detection information may include a QFI #A and a congestion identifier, and may further include one or more of information, for example, the flow description or reporting time of the congestion information. For example, the message #2 may be an N4 setup request message, or may be an N4 modification request message. In a possible embodiment, the SMF specifically extends, via an N4 message, a context message by parameter information related to congestion detection. S340 (a2): The UPF sends a data packet #A to an access network device . . . . “)
wherein the first network function is a Policy Control Function (PCF), the first function is an Application Function (AF) (see Gao Fig. 1 ¶ [0116] “ . . . As shown in FIG. 1, a 5G system (the 5th generation system, 5GS) is used as an example of the network architecture. The network architecture may include but is not limited to: a network slice selection function (NSSF), an authentication server function (AUSF), unified data management (UDM), a network exposure function (NEF), a network repository function (NRF), a policy control function (PCF), an application function (AF), an access and mobility management function (AMF), a session management function (SMF), user equipment (UE), a radio access network device, a user plane function (UPF), and a data network (DN) . . .”) ;
the first information comprises congestion information (see Gao ¶ [0007] “ . . . the congestion information includes information about a data transmission status determined after a network device performs congestion detection on a data flow, where the information is, for example, a queue delay value, a quantity of lost packets or a packet loss rate, a buffer size or buffer proportion information, a reporting periodicity, a congestion level, and a rate reduction proportion. The congestion information may alternatively be information indicating a data transmission status, or may be related information indicating whether congestion occurs or a congestion level. This is not limited in embodiments of this application . . .”);
Gao fails to explicitly teaches,
However Pan teaches
the congestion information in the first information indicates that an access network device adds congestion information to a data packet when network congestion occurs (see Pan ¶ [0009] “ . . . an access network device may send the network status information of the to-be-monitored service flow to the user plane network element, and then the user plane network element exposes the network status information to the application server by using a transport layer. Compared with a manner in which the access network device exposes the network status information by adding an explicit congestion notification (ECN) mark to an internet protocol (IP) header of an uplink/downlink data packet, this application provides higher security because the access network device does not need to parse the IP header of the downlink data packet. In addition, the network status information does not need to be sent to the terminal device, and then is sent by the terminal device to an application server side. In this way, the network status information can be fed back more quickly. . . .”); or indicates that a UPF adds congestion information to a data packet when network congestion occurs (see Pan¶ ¶ [0301-0304] “ . . . The UPF generates, based on the network status information of the to-be-monitored service flow, the information indicating the network status. The information indicating the network status includes at least one of the following: a quantity of data packets carrying a CE mark, a quantity of payload octets of the data packets carrying the CE mark, a quantity of payload octets of data packets carrying an ECT1 mark, or a quantity of payload octets of data packets carrying an ECT0 mark. Specifically, the information that is generated by the UPF and that indicates the network status meets the following condition: A ratio of the quantity that is of data packets carrying the CE mark and that is determined based on the information indicating the network status to a quantity of the at least one data packet is for representing the network status of the to-be-monitored service flow. The network status of the to-be-monitored service flow is determined based on the network status information of the to-be-monitored service flow. For example, if it is determined, based on the network status information of the to-be-monitored service flow, that a congestion degree of the to-be-monitored service flow is 60%, the information that is generated by the UPF and that indicates the network status meets the following condition: The ratio of the quantity that is of data packets carrying the CE mark and that is determined based on the information indicating the network status to a quantity of the at least one data packet is 60%. . . .”) ; or indicates that an access network device notifies a UPF to add congestion information to a data packet when network congestion occurs (see Pan Fig. 4 ¶ [0277] “ . . . As shown in (b) in FIG. 4, a TCP header of the TCP connection establishment message #1 includes the following fields: a header length, a reserved field, an AE, CWR, ECE, a URG flag, an ACK flag, a PSH flag, an RST flag, a SYN flag, and a FIN flag. The SYN flag is set to “1”. According to the schematic diagram of the TCP header of the TCP connection establishment message shown in (b) in FIG. 4, if a SYN flag in a TCP header of a packet received by the UPF from the UE is set to “1”, the packet is the TCP connection establishment message #1. . . .”).
The motivation to combine Pan with Gao is described for the rejection of claim 1 and is incorporated herein.
In regard to claim 10, the combination of Gao and Pan teaches wherein the first information (e.g. congestion detection on a first data flow) further comprises at least one of the following:
service information (see Gao ¶ [0006] “ . . . a service data adaptation protocol SDAP layer of the first data packet . . .”) ;
a Quality of Service (QoS) requirement corresponding to service information; (see Gao ¶ [0024] “ . . . the first data flow is a quality of service QoS flow that is in a protocol data unit session and that is bound to a congestion detection policy and charging control PCC rule. . . .”) ;
a marking frequency or duration or time interval of congestion information (see Gao ¶ [0034] “ . . . after receiving the first data packet from the access network device and obtaining the congestion information from the GTP-U header, the user plane function may mark a data packet, and then send the data packet to the server. .. .”);
notification information (see Gao ¶ [0195] “ . . . the message #1 includes a congestion information notification message, and the congestion information notification message indicates a reporting manner of reporting congestion information to the AF/AS. It may be understood that the congestion information notification message may alternatively be named after another message name, or this may be understood as that the congestion information notification message is a logical summary of one or more pieces of information that indicates a reporting manner of reporting the congestion information to the AF/AS . . .”) ; or
a QoS requirement corresponding to notification information (see Gao ¶¶ [0199-0201] “ . . . the PCF/NEF sends a subscription request message to the AF/AS. The subscription request message is used by the AF/AS to send a notification message related to the congestion information to the PCF/NEF. Correspondingly, the AS/AS receives the subscription request message. S320: The PCF generates a PCC rule #A based on the message #1. Specifically, the PCF obtains a QoS parameter of a corresponding QoS flow based on the flow description included in the message #1, and generates, based on the QoS parameter, the PCC rule #A used for congestion detection. . ..”)
In regard to claim 11, Gao teaches A communication method (see abstract : . . Embodiments of this application provide a communication method. . . .”), comprising:
receiving, by a communication device (e.g. UE or UPE) , congestion information (see ¶ [0008] “ . . . the access network device performs congestion detection on a data packet, to sense a congestion status on a network side. This avoids a problem that an algorithm is inaccurate because network congestion is detected and determined only on a device side and a server side. In addition, the access network device sends the congestion information to the UPF via the GTP-U header of the data packet based on the congestion detection result, or sends the congestion information to the UE via the SDAP layer, so that the congestion information can be flexibly and quickly fed back to a server end via the UPF or the UE. .. .”) , and sending, by the communication device, first notification information (see ¶ [0195] “ . . . the message #1 includes a congestion information notification message, and the congestion information notification message indicates a reporting manner of reporting congestion information to the AF/AS . . . “) , wherein the first notification information is used to notify that it is currently in a state of network congestion (see ¶¶ [0195-0196] “ . . . It may be understood that the congestion information notification message may alternatively be named after another message name, or this may be understood as that the congestion information notification message is a logical summary of one or more pieces of information that indicates a reporting manner of reporting the congestion information to the AF/AS. For example, the congestion information notification message may include notification periodicity information (aperiodicity of reporting the congestion information to the AF/AS), notification time indication information (time of reporting the congestion information to the AF/AS), and notification manner information (a specific manner of reporting the congestion information to the AF/AS). . . .”);
receiving by the communication device, policy information (e.g. PCC rule #A) from a first network function (e.g. PCF) , wherein the policy information is generated at least based on first information(e.g. message #1) (see Gao Fig. 3 ¶ ¶ [0200-0203]” . . . The PCF generates a PCC rule #A based on the message #1. Specifically, the PCF obtains a QoS parameter of a corresponding QoS flow based on the flow description included in the message #1, and generates, based on the QoS parameter, the PCC rule #A used for congestion detection. S330: An SMF binds the PCC rule #A to the QoS flow. The PCC rule #A may include information about a data flow #A (in other words, the PCC rule #A defines the data flow #A). . . .”) , the first information is information related to network congestion control, the communication device comprises a network device and/or a User Equipment (UE) (see Gao Fig. 3 ¶ ¶ [0204-0209]” . . . The SMF may bind the PCC rule #A to a part or all of existing QoS flows that are in a PDU session, to use the bound QoS flow as a data flow on which congestion detection is to be performed. The bound QoS flow may use a QFI that is before the binding. When the PCC rule #A includes a QFI, the bound data flow may use the QFI that is in the PCC rule #A. The SMF may alternatively create a new QoS flow based on the PCC rule #A, and the QoS flow may be used to transmit data on which congestion detection needs to be performed and that is in the PDU session. An identifier of the QoS flow may be the QFI that is in the PCC rule #A. S340 (a1): The SMF sends a message #2 to a UPF. Specifically, the message #2 includes congestion detection information, and the congestion detection information may include a QFI #A and a congestion identifier, and may further include one or more of information, for example, the flow description or reporting time of the congestion information. For example, the message #2 may be an N4 setup request message, or may be an N4 modification request message. In a possible embodiment, the SMF specifically extends, via an N4 message, a context message by parameter information related to congestion detection. S340 (a2): The UPF sends a data packet #A to an access network device . . . . “) ;
wherein the first network function is a Policy Control Function (PCF) (see Gao Fig. 1 ¶ [0116] “ . . . As shown in FIG. 1, a 5G system (the 5th generation system, 5GS) is used as an example of the network architecture. The network architecture may include but is not limited to: a network slice selection function (NSSF), an authentication server function (AUSF), unified data management (UDM), a network exposure function (NEF), a network repository function (NRF), a policy control function (PCF), an application function (AF), an access and mobility management function (AMF), a session management function (SMF), user equipment (UE), a radio access network device, a user plane function (UPF), and a data network (DN) . . .”) ;
the first information comprises congestion information (see Gao ¶ [0007] “ . . . the congestion information includes information about a data transmission status determined after a network device performs congestion detection on a data flow, where the information is, for example, a queue delay value, a quantity of lost packets or a packet loss rate, a buffer size or buffer proportion information, a reporting periodicity, a congestion level, and a rate reduction proportion. The congestion information may alternatively be information indicating a data transmission status, or may be related information indicating whether congestion occurs or a congestion level. This is not limited in embodiments of this application . . .”);
Gao fails to explicitly teaches,
However Pan teaches
the congestion information in the first information indicates that an access network device adds congestion information to a data packet when network congestion occurs (see Pan ¶ [0009] “ . . . an access network device may send the network status information of the to-be-monitored service flow to the user plane network element, and then the user plane network element exposes the network status information to the application server by using a transport layer. Compared with a manner in which the access network device exposes the network status information by adding an explicit congestion notification (ECN) mark to an internet protocol (IP) header of an uplink/downlink data packet, this application provides higher security because the access network device does not need to parse the IP header of the downlink data packet. In addition, the network status information does not need to be sent to the terminal device, and then is sent by the terminal device to an application server side. In this way, the network status information can be fed back more quickly. . . .”); or indicates that a UPF adds congestion information to a data packet when network congestion occurs (see Pan¶ ¶ [0301-0304] “ . . . The UPF generates, based on the network status information of the to-be-monitored service flow, the information indicating the network status. The information indicating the network status includes at least one of the following: a quantity of data packets carrying a CE mark, a quantity of payload octets of the data packets carrying the CE mark, a quantity of payload octets of data packets carrying an ECT1 mark, or a quantity of payload octets of data packets carrying an ECT0 mark. Specifically, the information that is generated by the UPF and that indicates the network status meets the following condition: A ratio of the quantity that is of data packets carrying the CE mark and that is determined based on the information indicating the network status to a quantity of the at least one data packet is for representing the network status of the to-be-monitored service flow. The network status of the to-be-monitored service flow is determined based on the network status information of the to-be-monitored service flow. For example, if it is determined, based on the network status information of the to-be-monitored service flow, that a congestion degree of the to-be-monitored service flow is 60%, the information that is generated by the UPF and that indicates the network status meets the following condition: The ratio of the quantity that is of data packets carrying the CE mark and that is determined based on the information indicating the network status to a quantity of the at least one data packet is 60%. . . .”) ; or indicates that an access network device notifies a UPF to add congestion information to a data packet when network congestion occurs (see Pan Fig. 4 ¶ [0277] “ . . . As shown in (b) in FIG. 4, a TCP header of the TCP connection establishment message #1 includes the following fields: a header length, a reserved field, an AE, CWR, ECE, a URG flag, an ACK flag, a PSH flag, an RST flag, a SYN flag, and a FIN flag. The SYN flag is set to “1”. According to the schematic diagram of the TCP header of the TCP connection establishment message shown in (b) in FIG. 4, if a SYN flag in a TCP header of a packet received by the UPF from the UE is set to “1”, the packet is the TCP connection establishment message #1. . . .”).
It would have been obvious to one skilled in the art, before the effective filing date of the applicant’s claimed invention to incorporate a method and system comprising a user plane network element obtains network status information of a to-be-monitored service flow. The network status information is used to determine a ratio of a quantity of data packets carrying a congestion experienced (CE) mark in at least one data packet of the to-be-monitored service flow to a quantity of the at least one data packet of the to-be-monitored service flow. The user plane network element adds, based on the network status information, the CE mark in the at least one data packet of the to-be-monitored service flow, and sends the at least one data packet in the to-be-monitored service flow to a terminal device, as taught by Pan, into a method and system for wireless communications that detects congestion conditions where congestion information is added to the data packet to communicate the network conditions, as taught by Gao. Such incorporation provides for different devices to process the congestion information in the packet.
In regard to claim 13, the combination of Gao and Pan teaches wherein the first information (e.g. congestion detection on a first data flow) further comprises at least one of the following:
service information (see Gao ¶ [0006] “ . . . a service data adaptation protocol SDAP layer of the first data packet . . .”) ;
a Quality of Service (QoS) requirement corresponding to service information (see Gao ¶ [0024] “ . . . the first data flow is a quality of service QoS flow that is in a protocol data unit session and that is bound to a congestion detection policy and charging control PCC rule. . . .”) ;
a marking frequency or duration or time interval of congestion information (see Gao ¶ [0034] “ . . . after receiving the first data packet from the access network device and obtaining the congestion information from the GTP-U header, the user plane function may mark a data packet, and then send the data packet to the server. .. .”);
notification information (see Gao ¶ [0195] “ . . . the message #1 includes a congestion information notification message, and the congestion information notification message indicates a reporting manner of reporting congestion information to the AF/AS. It may be understood that the congestion information notification message may alternatively be named after another message name, or this may be understood as that the congestion information notification message is a logical summary of one or more pieces of information that indicates a reporting manner of reporting the congestion information to the AF/AS . . .”) ; or
a QoS requirement corresponding to notification information (see Gao ¶¶ [0199-0201] “ . . . the PCF/NEF sends a subscription request message to the AF/AS. The subscription request message is used by the AF/AS to send a notification message related to the congestion information to the PCF/NEF. Correspondingly, the AS/AS receives the subscription request message. S320: The PCF generates a PCC rule #A based on the message #1. Specifically, the PCF obtains a QoS parameter of a corresponding QoS flow based on the flow description included in the message #1, and generates, based on the QoS parameter, the PCC rule #A used for congestion detection. . ..”).
In regard to claim 15, the combination of Gao and Pan teaches wherein the communication device comprises the UE (see Gao ¶ [0119] “ . . . . UE: may be referred to as a terminal device, an access terminal, a subscriber unit, a subscriber station, a mobile station, a remote station, a remote terminal, a mobile device, a user terminal, a terminal, a wireless communication device, a user agent, or a user apparatus. . . .”) ;
the service information and the QoS requirement corresponding to the service information in the first information are at least used by the UE to identify data and perform QoS guarantee (see Gao ¶ [0155] “ . . . the access network device separately calculates detection results of congestion between a RAN and UE and between a UPF and the RAN based on GTP-U packet receiving and sending timestamps. For a case in which the access network device detects a congestion status between the UPF and the RAN, refer to related content of QoS monitoring in the 3GPP standard TS 23.501. This is not limited in embodiments of this application. For a case in which the access network device detects a congestion status between the RAN and the UE, refer to content in the 3GPP standard TS 38.314. This is not limited in embodiments of this application . . . “).
In regard to claim 17, the combination of Gao and Pan teaches wherein in the case that the communication device comprises a UE (see Gao ¶ [0119] “ . . . UE: may be referred to as a terminal device, an access terminal, a subscriber unit, a subscriber station, a mobile station, a remote station, a remote terminal, a mobile device, a user terminal, a terminal, a wireless communication device, a user agent, or a user apparatus. . . .”) , the method further comprises:
sending, by the UE, capability indication information, wherein the capability indication information indicates that the UE supports network congestion control (see Gao ¶ [0048] “ . . . The method includes: A terminal device UE receives a first data packet, where a GTP-U header of the first data packet includes first congestion information, or a SDAP layer of the first data packet includes first congestion information, where the first congestion information is used by a server to adjust a rate of sending a data flow. The UE sends second congestion information to the server based on the first congestion information. . . . “)
In regard to claim 51,the combination of Gao and Pan teaches A communication device (e.g. Gao Fig. 7 apparatus) comprising a memory, a processor and a computer program stored in the memory and executable on the processor (see Gao ¶ [0346] “ . . . The apparatus 700 includes a processor 710. The processor 710 is coupled to a memory 720. The memory 720 is configured to store a computer program or instructions and/or data. The processor 710 is configured to execute the computer program or the instructions stored in the memory 720, or read data stored in the memory 720, to perform the methods in the foregoing method embodiments . . . “) , wherein the processor is configured to execute the program to implement the steps of the method (see Gao ¶ [0350] “ . . . In a solution, the apparatus 700 is configured to implement the operations performed by the access network device and the UPF network element in the foregoing method embodiments . . .”) according to claim 1 (see citations for the combination of Gao and Pan as described for the rejection of claim 1 and is incorporated herein).
In regard to claim 52, the combination of Gao and Pan teaches A communication device(e.g. Gao Fig. 7 apparatus) comprising a memory, a processor and a computer program stored in the memory and executable on the processor(see Gao ¶ [0346] “ . . . The apparatus 700 includes a processor 710. The processor 710 is coupled to a memory 720. The memory 720 is configured to store a computer program or instructions and/or data. The processor 710 is configured to execute the computer program or the instructions stored in the memory 720, or read data stored in the memory 720, to perform the methods in the foregoing method embodiments . . . “), wherein the processor is configured to execute the program to implement the steps of the method (see Gao ¶ [0351] “ . . . the processor 710 is configured to execute the computer program or the instructions stored in the memory 720, to implement related operations of the access network device in the foregoing method embodiments. For example, the method is performed by the access network device in embodiments shown in FIG. 3, FIG. 4A and FIG. 4B, and FIG. 5. . . .”) according to claim 9 (see citations for the combination of Gao and Pan as described for the rejection of claim 9 and is incorporated herein).
In regard to claim 53, the combination of Gao and Pan teaches A communication device comprising a memory, a processor and a computer program stored in the memory and executable on the processor (see Gao ¶ [0346] “ . . . The apparatus 700 includes a processor 710. The processor 710 is coupled to a memory 720. The memory 720 is configured to store a computer program or instructions and/or data. The processor 710 is configured to execute the computer program or the instructions stored in the memory 720, or read data stored in the memory 720, to perform the methods in the foregoing method embodiments . . . “), wherein the processor is configured to execute the program to implement the steps of the method (see Gao ¶ [0352] “ . . . the processor 710 is configured to execute the computer program or the instructions stored in the memory 720, to implement related operations of the terminal device in the foregoing method embodiments. For example, the method performed by the UPF network element in embodiments shown in FIG. 3, FIG. 4A and FIG. 4B, and FIG. 5. . . .”).according to claim 11. (see citations for the combination of Gao and Pan as described for the rejection of claim 11 and is incorporated herein).
Claims 7, 14 and 16 are rejected under 35 U.S.C. 103 as being un-patentable over Gao et al. (U.S. 2025/0023823 A1; herein referred to as Gao) in view of Pan et al. (U.S. 2025/0048176 A1; herein referred to as Pan) as applied to claims 1 – 5, 6, 7 – 11, 13, 15, 17 and 51- 53, in further view of Kim et al. (U.S. 2022/0312509 A1; herein referred to as Kim).
In regard to claim 7, the combination of Gao and Pan fails to explicitly teach,
However Kim teaches
wherein the QoS requirement corresponding to the notification information is at least used to perform corresponding QoS guarantee for the notification information (see ¶ [0017] “ . . . the method including receiving a PDU session related message including a QoS profile related to a QoS flow and two or more Alternative QoS Profiles by the NG-RAN, determining whether to guarantee the QoS profile for the QoS flow by the NG-RAN, transmitting a first notification indicating that the QoS profile is not guaranteed for the QoS flow to an SMF by the NG-RAN, determining whether the two or more Alternative QoS Profiles can be guaranteed for the QoS flow by the NG-RAN, and transmitting a second notification indicating that the Alternative QoS Profile is guaranteed for the QoS flow, wherein the second notification may include information on the Alternative QoS Profile capable of guaranteeing the QoS flow among the two or more Alternative QoS Profiles . . .”) .
It would have been obvious to one skilled in the art, before the effective filing date of the applicant’s claimed invention to incorporate a method and system for wireless communications that determine whether QOS profiles are guaranteed for specific conditions such as network congestion and providing notifications of the guarantee, as taught by Kim, into a method and system for wireless communications that detects congestion conditions where congestion information is added to the data packet to communicate the network conditions, wherein comprising a user plane network element obtains network status information of a to-be-monitored service flow. The network status information is used to determine a ratio of a quantity of data packets carrying a congestion experienced (CE) mark in at least one data packet of the to-be-monitored service flow to a quantity of the at least one data packet of the to-be-monitored service flow. The user plane network element adds, based on the network status information, the CE mark in the at least one data packet of the to-be-monitored service flow, and sends the at least one data packet in the to-be-monitored service flow to a terminal device as taught by the combination of Gao and Pan. Such incorporation provides that the network communications devices have downstream information regarding congestion.
In regard to claim 14, the combination of Gao, Pan, and Kim teaches wherein the sending the first notification information (see Gao ¶¶ [0195-0196] as described for the rejection of claim 11 and is incorporated herein) comprises:
adding, by the communication device, the first notification information to an in-band message, wherein the in-band message is used to perform QoS guarantee based on the QoS requirement corresponding to the first notification information (see Kim ¶ [0017] “ . . . the method including receiving a PDU session related message including a QoS profile related to a QoS flow and two or more Alternative QoS Profiles by the NG-RAN, determining whether to guarantee the QoS profile for the QoS flow by the NG-RAN, transmitting a first notification indicating that the QoS profile is not guaranteed for the QoS flow to an SMF by the NG-RAN, determining whether the two or more Alternative QoS Profiles can be guaranteed for the QoS flow by the NG-RAN, and transmitting a second notification indicating that the Alternative QoS Profile is guaranteed for the QoS flow, wherein the second notification may include information on the Alternative QoS Profile capable of guaranteeing the QoS flow among the two or more Alternative QoS Profiles . . .”); or
constructing, by the communication device, a message, and sending, by the communication device, the first notification information in the constructed message (see Kim ¶¶ [0132-0133] “ . . . an NG-RAN may receive a PDU session related message including a QoS profile related to a QoS flow and two or more Alternative QoS Profiles and determine whether to guarantee (or fulfill) the QoS profile (i.e., such a QoS indicated by the QoS profile as GFBR, PDB, PER, etc.) for the QoS flow. If the NG-RAN determines that it is unable to guarantee (or fulfill) the QoS profile, it may determine which one of the Alternative QoS Profiles can be guaranteed (or fulfilled). As a result, the NG-RAN may send a first notification indicating that the QoS profile is not guaranteed (or fulfilled) for the QoS flow to the SMF. When the notification is sent, information on a guaranteed (fulfilled) Alternative QoS Profile (i.e., currently supportable QoS information) may be provided to the SMF . . .”), and the constructed message is used to perform QoS guarantee based on the QoS requirement corresponding to the first notification information (see Kim ¶ [0134] “ . . . Thereafter, the NG-RAN may determine whether it can guarantee (or fulfill) the two or more Alternative QoS Profiles (i.e., Such QoS indicated by the Alternative QoS Profiles as GFBR, PDB, PER, etc.) for the QoS flow. This may be regarded as a case that the NG-RAN can support a better/higher QoS after the first notification. As a result of the determination, a second notification indicating that the Alternative QoS Profile is guaranteed (or fulfilled) for the QoS flow may be transmitted to the SMF. Here, the second notification may include information on the Alternative QoS Profile that can guarantee (or fulfill) the QoS flow among the two or more Alternative QoS Profiles. . . .”).
The motivation to combine Kim with the combination of Gao and Pan is described for the rejection of claim 7. Additionally, Kim provides to pass the QOS guarantee through messages between the devices.
In regard to claim 16, the combination of Gao, Pan, and Kim teaches wherein the QoS requirement corresponding to the notification information in the first information is at least used to perform corresponding QoS guarantee for the notification information (see Kim ¶ [0017] “ . . . the method including receiving a PDU session related message including a QoS profile related to a QoS flow and two or more Alternative QoS Profiles by the NG-RAN, determining whether to guarantee the QoS profile for the QoS flow by the NG-RAN, transmitting a first notification indicating that the QoS profile is not guaranteed for the QoS flow to an SMF by the NG-RAN, determining whether the two or more Alternative QoS Profiles can be guaranteed for the QoS flow by the NG-RAN, and transmitting a second notification indicating that the Alternative QoS Profile is guaranteed for the QoS flow, wherein the second notification may include information on the Alternative QoS Profile capable of guaranteeing the QoS flow among the two or more Alternative QoS Profiles . . .”) .
The motivation to combine Kim with combination of Gao and Pan is described for the rejection of claim 7.
Conclusion
There are prior art made of record which are not relied upon but are considered pertinent to applicant’s disclosure. They are listed on the PTO-892 accompanying this action
Applicant's amendments 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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES N FIORILLO whose telephone number is (571)272-9909. The examiner can normally be reached on 7:30 - 5 PM Mon - Fri..
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, John A. Follansbee can be reached on 571-272-3964. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JAMES N FIORILLO/Primary Examiner, Art Unit 2444
