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 .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-17 and 32-59 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
For Claim 1 (lines 6 and 11), it is not clear what is included in “one of: one or more of:”, especially where items after the second colon are conjoined with both “and” and “or”.
For Claim 1 (line 7), “the at least one ongoing PDU session” lacks antecedent basis in the claim.
For Claim 1 (line 11), “the multiple traffic flows” lacks antecedent basis in the claim.
For Claim 5 (line 3), it is not clear what is included in “one of: one or more of:”, especially where items after the second colon are conjoined with both “and” and “or”.
For Claim 5 (line 4) “one of the ongoing PDU session of the UE” may have antecedent basis in the claim.
For Claim 7 (line 8), it is not clear what is included in “one of: one or more of:”, especially where items after the second colon are conjoined with both “and” and “or”.
For Claim 7 (line 9), “the at least one ongoing PDU session” lacks antecedent basis in the claim.
For Claim 16 (line 3), it is not clear what is included in “one of: one or more of:”, especially where items after the second colon are conjoined with both “and” and “or”.
For Claim 16 (line 4) “one of the ongoing PDU session of the UE” may have antecedent basis in the claim.
For Claim 32 (line 3), “at least one set” has antecedent basis in the claim.
For Claim 32 (lines 7-8), it is not clear what is included in “one or more of: at least one traffic route and one of: at least one traffic filter or at least one ethernet traffic filter”.
For Claim 34, “at least one set” has antecedent basis in the claim.
For Claim 36, it is not clear what is included in “one of: the at least one traffic filter or the at least one ethernet traffic filter identifies a traffic flow of one of: one or more of: at least one future PDU session and at least one ongoing PDU session of at least one UE, or one of ongoing protocol data unit (PDU) session of a user equipment (UE)” (emphasis added).
For Claim 38 (line 5), “at least one set” has antecedent basis in the claim.
For Claim 44, “the first request” probably has antecedent basis in “a first update request”.
For Claim 45, it is not clear what is included in “one of: one or more of:”, especially where items after the second colon are conjoined with both “and” and “or”.
For Claim 47 (line 3), “the map” lacks antecedent basis in the claim.
For Claim 47 (line 4), “a map comprising at least one set” should probably be corrected to ---the map comprises at least one set---.
For Claim 47 (line 5), “at least one set” has antecedent basis in the claim.
For Claim 50, “at least one set” has antecedent basis in the claim.
For Claim 54 (line 3), “and;” should be corrected to ---and---.
For Claim 54 (line 5), “at least one set” has antecedent basis in the claim.
For Claim 56, “at least one set” has antecedent basis in the claim.
Remaining claims are rejected as depending from a rejected claim.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 18-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Tang et al. (US 2023/0028216).
For Claim 18, Tang teaches a method for storing multiple traffic influencing requests in a communication network comprising:
receiving, by a unified data repository (UDR), a second request from a network exposure function (NEF) comprising a map (see paragraphs 35, 44, 46),
wherein the map comprises a plurality of sets (see paragraphs 30-32),
wherein a set, in the plurality of sets comprises at least a set identification number (SID), at least one traffic route, and one of: at least one traffic filter or at least one ethernet traffic filter as attributes (see paragraphs 30, 69, 79); and
storing, by the UDR, in a database, the attributes received in the second request (see paragraphs 44, 46: storage in UDR).
For Claim 19, Tang teaches the method, wherein the second request is for one or more of: at least one future PDU session and at least one ongoing PDU session without a corresponding UE address (see paragraphs 35-36, 51, 68).
For Claim 20, Tang teaches the method, further comprising: sending, by the UDR, a notification comprising the map, to a policy control function (PCF) of a core network that has subscribed to the UDR to receive the notification (see paragraphs 35, 46).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1 and 7-12, as understood in light of rejections under 35 USC 112, is/are rejected under 35 U.S.C. 103 as being unpatentable over Tang et al. (US 2023/0028216) in view of Wu et al. (WO2024/000445, citing the translation provided herewith).
For Claim 1, Tang teaches a method of multiple traffic influencing in a communication network, the method comprising:
generating, by an application function (AF), a map comprising a plurality of sets (see paragraphs 30-32),
wherein a set, in the plurality of sets, comprises at least a set identification number (SID), at least one traffic route, and one of: at least one traffic filter or at least one ethernet traffic filter as attributes (see paragraphs 30, 69, 79);
determining, by the AF, influencing one of: one or more of: at least one future PDU session, and the at least one ongoing PDU session of at least one UE without the corresponding UE address, or one of an ongoing protocol data unit (PDU) session of a user equipment (UE) with a corresponding UE address (see paragraphs 32, 35); and
sending, by the AF, a first request comprising the map to a core network through a network exposure function (NEF) to influence the multiple traffic flows of one of: one or more of: the at least one future PDU session and the at least one ongoing PDU session of the at least one UE or one of the ongoing protocol data unit (PDU) session of the UE (see paragraphs 37, 32, 35).
Tang as applied above is not explicit as to, but Wu teaches an untrusted application function (uAF) (see underlined portion on p. 6).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to allow for the interaction with a uAF as in Wu when enabling an AF to request traffic influencing as in Tang. The motivation would be to allow for external application functions to optimize QoS.
For Claim 7, Tang teaches a method of multiple traffic influencing in a communication network comprising:
receiving, by a network exposure function (NEF), a first request from an application function (AF) comprising a map (see paragraphs 37, 32, 35),
wherein the map comprises a plurality of sets (see paragraphs 30-32),
wherein a set, in the plurality of sets, comprises at least a set identification number (SID), at least one traffic route, and one of: at least one traffic filter or at least one ethernet traffic filter as attributes (see paragraphs 30, 69, 79);
determining, by the NEF, whether the first request is for one of: one or more of: at least one future PDU session (see paragraphs 35, 39), and the at least one ongoing PDU session of at least one UE without the corresponding UE address, or one of an ongoing protocol data unit (PDU) session of a user equipment (UE) with a corresponding UE address (see paragraphs 32, 35); and
sending, by the NEF, a second request to one of a unified data repository (UDR) or a policy control function (PCF) based on the determination (see paragraphs 35, 44, 46: UDR; paragraphs 29, 34: PCF).
Tang as applied above is not explicit as to, but Wu teaches an untrusted application function (uAF) (see underlined portion on p. 6).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to allow for the interaction with a uAF as in Wu when enabling an AF to request traffic influencing as in Tang. The motivation would be to allow for external application functions to optimize QoS.
For Claim 8, Tang further teaches the method, wherein the second request is sent to the UDR based on the determination that the first request is for one or more of: the at least one future PDU session and the at least one ongoing PDU session of the at least one UE without corresponding UE address (see paragraphs 35-36, 51, 68).
For Claim 9, Tang further teaches the method, wherein the second request is sent to the PCF based on the determination that the first request is for one of the ongoing PDU sessions of the UE with the corresponding UE address (see paragraphs 34-35).
For Claim 10, Tang further teaches the method, wherein the second request comprises one of: the map or an interpretation of the map by the NEF (see paragraphs 33, 39, 43, 48).
For Claim 11, Tang further teaches the method, wherein the second request comprising the map is sent to the UDR (see paragraphs 35-36, 51, 68).
For Claim 12, Tang further teaches the method, wherein
analyzing, by the NEF, each entry in the map to interpret the map (see paragraphs 30, 34, 39, 46);
generating, by the NEF, the second request based on the analysis (see paragraphs 30, 34, 39, 46); and
sending, by the NEF, the second request to the PCF comprises the interpretation of the map (see paragraphs 30, 34, 39, 46).
Claim(s) 5-6 and 16-17, as understood in light of rejections under 35 USC 112, is/are rejected under 35 U.S.C. 103 as being unpatentable over Tang et al. (US 2023/0028216) and Wu et al. (W(2024/000445, citing the translation provided herewith) as applied to claims 1 and 7 above, and further in view of Xiong (US 2022/0224646).
For Claims 5 and 16, Tang further teaches the method, wherein
one of: the at least one traffic filter or the at least one ethernet traffic filter identifies the traffic flow of one of: one or more of: the at least one future PDU session and the at least one ongoing PDU session of the at least one UE, or one of the ongoing PDU session of the UE (see paragraph 30).
The references as applied above are not explicit as to, but Xiong teaches that one of: the at least one traffic filter is represented using the attribute “trafficFilters” or the at least one ethernet traffic filter is represented using the attribute “ethTrafficFilters” in a payload of the first request (see Table 1), and the attributes “trafficFilters” and “ethTrafficFilters” are of datatype array (see Table 1).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to use the attributes as in Xiong when implementing the method of Tang. The motivation would be to maintain compatibility with systems already in use.
For Claims 6 and 17, Tang further teaches the method, wherein the at least one traffic route is represented using an attribute “trafficRoutes” in the request payload (see paragraph 69).
The references as applied above are not explicit as to, but Xiong teaches the at least one traffic route identifying at least one application server address (see paragraphs 7, abstract), and the attribute “trafficRoutes” being of datatype array (see table 1: known data types).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to use the attributes as in Xiong when implementing the method of Tang. The motivation would be to maintain compatibility with systems already in use.
Claim(s) 24-25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tang et al. (US 2023/0028216) as applied to claim 18 above, and further in view of Xiong (US 2022/0224646).
For Claim 24, Tang further teaches the method, wherein one of: the at least one traffic filter or the at least one ethernet traffic filter identifies the traffic flow of one or more of: the at least one future PDU session and the at least one ongoing PDU session of the at least one UE (see paragraph 30).
The references as applied above are not explicit as to, but Xiong teaches that one of: the at least one traffic filter is represented using the attribute “trafficFilters” or the at least one ethernet traffic filter is represented using the attribute “ethTrafficFilters” in a payload of the second request (see Table 1), and the attributes “trafficFilters” and “ethTrafficFilters” are of datatype array (see Table 1).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to use the attributes as in Xiong when implementing the method of Tang. The motivation would be to maintain compatibility with systems already in use.
For Claim 25, Tang further teaches the method, wherein the at least one traffic route is represented using an attribute “trafficRoutes” in a payload of the second request (see paragraph 69)
The references as applied above are not explicit as to, but Xiong teaches that the at least one traffic route identifies at least one application server address (see paragraph 7, abstract), and
the attribute “trafficRoutes” is of datatype array (see Table 1: known data types).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to use the attributes as in Xiong when implementing the method of Tang. The motivation would be to maintain compatibility with systems already in use.
Claim(s) 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tang et al. (US 2023/0028216) in view of John et al. (US 2023/00096469).
For Claim 26, Tang teaches a method of multiple traffic influencing in a communication network comprising:
receiving, by a policy control function (PCF) from a unified data repository (UDR), a notification comprising a map (see paragraphs 46, 35),
wherein the map comprises a plurality of sets (see paragraphs 30-32),
wherein a set, in the plurality of sets, comprises at least a set identification number (SID), at least one traffic route, and one of: at least one traffic filter or at least one ethernet traffic filter as attributes (see paragraphs 30, 69, 79).
Tang as applied above is not explicit as to, but John teaches interpreting, by the PCF, each set in the map identified by the SID, having a mapping of one of: the at least one traffic filter with the at least one traffic route or the at least one ethernet traffic filter with the at least one traffic route (see abstract, paragraphs 95-96, 158); and
providing, by the PCF, information related to the interpretation of the map to session management function (SMF) of the core network for implementing the multiple traffic influencing in an ongoing PDU sessions traffic flow (see abstract, paragraphs 95-96, 158).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to have the PCF process the traffic information as in John when implementing the method of Tang. The motivation would be to appropriately route traffic associated with the application server.
Claim(s) 30-31 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tang et al. (US 2023/0028216) and John et al. (US 2023/00096469) as applied to claim 26 above, and further in view of Xiong (US 2022/0224646).
For Claim 30, Tang further teaches the method, wherein one of: the at least one traffic filter or the at least one ethernet traffic filter identifies the traffic flow of one or more of: the at least one future PDU session and the at least one ongoing PDU session of the at least one UE (see paragraph 30).
The references as applied above are not explicit as to, but Xiong teaches that one of: the at least one traffic filter is represented using the attribute “trafficFilters” or the at least one ethernet traffic filter is represented using the attribute “ethTrafficFilters” in a payload of the notification (see Table 1), and the attributes “trafficFilters” and “ethTrafficFilters” are of datatype array (see Table 1).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to use the attributes as in Xiong when implementing the method of Tang. The motivation would be to maintain compatibility with systems already in use.
For Claim 31, Tang further teaches the method, wherein the at least one traffic route is represented using an attribute “trafficRoutes” in a payload of the notification (see paragraph 69)
The references as applied above are not explicit as to, but Xiong teaches that the at least one traffic route identifies at least one application server address (see paragraph 7, abstract), the attribute “trafficRoutes” is of datatype array (see Table 1).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to use the attributes as in Xiong when implementing the method of Tang. The motivation would be to maintain compatibility with systems already in use.
Claim(s) 32 and 38-41, as understood in light of rejections under 35 USC 112, is/are rejected under 35 U.S.C. 103 as being unpatentable over Tang et al. (US 2023/0028216) in view of Zhu et al. (US 2022/0225441) and Wu et al. (WO 2024/000445, citing the translation provided herewith).
For Claim 32, Tang teaches a method of multiple traffic influencing in a communication network, the method comprising:
generating, by an application function (AF), a map comprising at least one set (see paragraphs 30-32),
wherein a set, in at least one set, comprises at least a set identification number (SID) and optional attributes (see paragraphs 30, 69, 79),
wherein the optional attributes comprises one or more of: at least one traffic route and one of: at least one traffic filter or at least one ethernet traffic filter (see paragraphs 30, 69, 79); and
sending, by the AF, a first request comprising the map to a core network through a network exposure function (NEF) to adjust the influence of the multiple traffic flows (see paragraphs 37, 32, 35).
Tang as applied above is not explicit as to, but Zhu teaches that the optional attributes are removable attributes defined as an ‘Open: API nullable true property’ in the map (see Table 5.4.2-1), and the request being an update request (see paragraphs 62-63, Table 5.4.2-1)
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to employ attributes as in Zhu when implementing the method of Tang. The motivation would be to maintain compatibility with existing systems by identifying attributes in a known manner.
The references as applied above are not explicit as to, but Wu teaches an untrusted application function (uAF) (see underlined portion on p. 6).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to allow for the interaction with a uAF as in Wu when enabling an AF to request traffic influencing as in Tang. The motivation would be to allow for external application functions to optimize QoS.
For Claim 38, Tang teaches a method of multiple traffic influencing in a communication network comprising:
receiving, by a network exposure function (NEF) from an Authentication Function (AF), a first request comprising a map (see paragraphs 37, 32, 35),
wherein the map comprises at least one set (see paragraphs 30-32);
wherein a set, in at least one set, comprises at least a set identification number (SID), and optional attributes (see paragraphs 30, 69, 79),
wherein the optional attributes comprises one or more of: of at least one traffic route and one of: at least one traffic filter or at least one ethernet traffic filter (see paragraphs 30, 69, 79);
determining, by the NEF, based on the first request, a next entity to send a second request, wherein the next entity includes one of a unified data repository (UDR) or a policy control function (PCF) (see paragraphs 35, 44, 46: UDR; paragraphs 29, 34: PCF); and
sending, by the NEF, a second update request to one of the UDR or the PCF based on the determination of next entity to send (see paragraphs 35, 44, 46: UDR; paragraphs 29, 34: PCF).
Tang as applied above is not explicit as to, but Zhu teaches that the optional attributes are removable attributes defined as an ‘Open: API nullable true property’ in the map (see Table 5.4.2-1), and the request being an update request (see paragraphs 62-63, Table 5.4.2-1)
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to employ attributes as in Zhu when implementing the method of Tang. The motivation would be to maintain compatibility with existing systems by identifying attributes in a known manner.
The references as applied above are not explicit as to, but Wu teaches an untrusted application function (uAF) (see underlined portion on p. 6).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to allow for the interaction with a uAF as in Wu when enabling an AF to request traffic influencing as in Tang. The motivation would be to allow for external application functions to optimize QoS.
For Claim 39, Tang as modified above further teaches the method, wherein the second update request comprises one of: the map or an interpretation of the map (see paragraphs 33, 39, 43, 48).
For Claim 40, as modified above Tang further teaches the method, wherein the second update request, comprising the map, is sent to the UDR based on the determination of the next entity being the UDR (see paragraphs 35, 36, 51, 68).
For Claim 41, Tang as modified above further teaches the method, further comprising:
analyzing, by the NEF, each entry in the map to interpret the map in the first update request (see paragraphs 30, 34, 39, 46);
forming the second update request having the interpretation of the map based on the analysis (see paragraphs 30, 34, 39, 46); and
sending, by the NEF, the second update request to the PCF comprising the interpretation of the map (see paragraphs 30, 34, 39, 46).
Claim(s) 36-37 and 45-46, as understood in light of rejections under 35 USC 112, is/are rejected under 35 U.S.C. 103 as being unpatentable over Tang et al. (US 2023/0028216), Zhu et al. (US 2022/0225441), and Wu et al. (W(2024/000445, citing the translation provided herewith) as applied to claims 32 and 38 above, and further in view of Xiong (US 2022/0224646).
For Claims 36 and 45, Tang further teaches the method, wherein one of: the at least one traffic filter or the at least one ethernet traffic filter identifies a traffic flow of one of: one or more of: at least one future PDU session and at least one ongoing PDU session of at least one UE, or one of ongoing protocol data unit (PDU) session of a user equipment (UE) (see paragraph 30).
The references as applied above are not explicit as to, but Xiong teaches that one of: the at least one traffic filter is represented using the attribute “trafficFilters” or the at least one ethernet traffic filter is represented using the attribute “ethTrafficFilters” in a payload of the first update request (see Table 1), and the attributes “trafficFilters” and “ethTrafficFilters” are of datatype array (see Table 1).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to use the attributes as in Xiong when implementing the method of Tang. The motivation would be to maintain compatibility with systems already in use.
For Claims 37 and 46, Tang further teaches the method, the at least one traffic route is represented using an attribute “trafficRoutes” in a payload of the first request (see paragraph 69)
The references as applied above are not explicit as to, but Xiong teaches the at least one traffic route identifying at least one application server address (see paragraphs 7, abstract), and the attribute “trafficRoutes” being of datatype array (see table 1: known data types).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to use the attributes as in Xiong when implementing the method of Tang. The motivation would be to maintain compatibility with systems already in use.
Claim(s) 47-48, as understood in light of rejections under 35 USC 112, is/are rejected under 35 U.S.C. 103 as being unpatentable over Tang et al. (US 2023/0028216) in view of Zhu et al. (US 2022/0225441) and Kunz et al. (US 2020/0053083).
For Claim 47, Tang teaches a method for storing multiple traffic influencing requests in a communication network comprising:
receiving, by a unified data repository (UDR), a second request comprising the map,
wherein a map comprising at least one set,
wherein a set, in at least one set, comprises at least a set identification number (SID) and optional attributes,
wherein the optional attributes comprises one or more of: at least one traffic route and one of: at least one traffic filter or at least one ethernet traffic filter;
Tang as applied above is not explicit as to, but Zhu teaches that the optional attributes are removable attributes defined as an ‘Open: API nullable true property’ in the map (see Table 5.4.2-1), and the request being an update request (see paragraphs 62-63, Table 5.4.2-1)
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to employ attributes as in Zhu when implementing the method of Tang. The motivation would be to maintain compatibility with existing systems by identifying attributes in a known manner.
The references as applied above are not explicit as to, but Kunz teaches analyzing, by the UDR, each entry in the map received in the second update request and a stored map, to generate an updated map (see paragraphs 87, 89-90); and
updating, by UDR, a database with the updated map along with an interpretation of other attributes received in the second update request (see paragraphs 90-92).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to have the UDR update the map as in Kunz when implementing the method of Tang. The motivation would be to maintain the UDR with current information.
For Claim 48, Tang as modified above further teaches the method, further comprising: sending, by the UDR, a notification comprising the updated map, to the policy control function (PCF) of a core network that has subscribed to the UDR to receive the notification (see paragraphs 46, 35).
Claim(s) 52-53, as understood in light of rejections under 35 USC 112, is/are rejected under 35 U.S.C. 103 as being unpatentable over Tang et al. (US 2023/0028216), Zhu et al. (US 2022/0225441), and Kunz et al. (US 2020/0053083) as applied to claim 47 above, and further in view of Xiong (US 2022/0224646).
For Claim 52, Tang further teaches the method, wherein one of: the at least one traffic filter or the at least one ethernet traffic filter identifies the traffic flow of one or more of: the at least one future PDU session and the at least one ongoing PDU session of the at least one UE (see paragraph 30).
The references as applied above are not explicit as to, but Xiong teaches that one of: the at least one traffic filter is represented using the attribute “trafficFilters” or the at least one ethernet traffic filter is represented using the attribute “ethTrafficFilters” in a payload of the second update request (see Table 1), and the attributes “trafficFilters” and “ethTrafficFilters” are of datatype array (see Table 1).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to use the attributes as in Xiong when implementing the method of Tang. The motivation would be to maintain compatibility with systems already in use.
For Claim 53, Tang as modified further teaches the method, wherein the at least one traffic route is represented using an attribute “trafficRoutes” in a payload of the second update request (see paragraph 69).
The references as applied above are not explicit as to, but Xiong teaches the at least one traffic route identifying at least one application server address (see paragraphs 7, abstract), and the attribute “trafficRoutes” being of datatype array (see table 1: known data types).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to use the attributes as in Xiong when implementing the method of Tang. The motivation would be to maintain compatibility with systems already in use.
Claim(s) 54, as understood in light of rejections under 35 USC 112, is/are rejected under 35 U.S.C. 103 as being unpatentable over Tang et al. (US 2023/0028216) in view of Zhu et al. (US 2022/0225441) and John et al. (US 2023/00096469).
For Claim 54, Tang teaches a method of multiple traffic influencing in a communication network comprising:
receiving, by a policy control function (PCF) from a unified data repository (UDR), a notification comprising an map (see paragraphs 46, 35), and;
wherein the map comprises at least one set (see paragraphs 30-32),
wherein a set, in at least one set, comprises at least a set identification number (SID) and an optional attributes (see paragraphs 30, 69, 79),
wherein the optional attributes comprises one or more of: at least one traffic route and one of: at least one traffic filter or at least one ethernet traffic filter (see paragraphs 30, 69, 79).
Tang as applied above is not explicit as to, but Zhu teaches that the optional attributes are removable attributes defined as an ‘Open: API nullable true property’ in the map (see Table 5.4.2-1), and the request and map being updates (see paragraphs 62-63, Table 5.4.2-1)
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to employ attributes as in Zhu when implementing the method of Tang. The motivation would be to maintain compatibility with existing systems by identifying attributes in a known manner.
The references as applied above are not explicit as to, but John teaches interpreting, by the PCF, each set in the updated map identified by the SID, having a mapping of one of: the at least one traffic filter with the at least one traffic route or the at least one ethernet traffic filter with the at least one traffic route (see abstract, paragraphs 95-96, 158); and
providing, by the PCF, information related to the interpretation of the map to session management function (SMF) of a core network for updating the multiple traffic influencing in an ongoing protocol data unit (PDU) sessions traffic flow (see abstract, paragraphs 95-96, 158).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to have the PCF process the traffic information as in John when implementing the method of Tang. The motivation would be to appropriately route traffic associated with the application server.
Claim(s) 58-59, as understood in light of rejections under 35 USC 112, is/are rejected under 35 U.S.C. 103 as being unpatentable over Tang et al. (US 2023/0028216), Zhu et al. (US 2022/0225441), and John et al. (US 2023/00096469) as applied to claim 54 above, and further in view of Xiong (US 2022/0224646).
For Claim 58, Tang as modified above further teaches the method, wherein
one of: the at least one traffic filter or the at least one ethernet traffic filter identifies the traffic flow of one or more of: the at least one future PDU session and the at least one ongoing PDU session of the at least one UE (see paragraph 30).
The references as applied above are not explicit as to, but Xiong teaches that one of: the at least one traffic filter is represented using the attribute “trafficFilters” or the at least one ethernet traffic filter is represented using the attribute “ethTrafficFilters” in a payload of the second update request (see Table 1), and the attributes “trafficFilters” and “ethTrafficFilters” are of datatype array (see Table 1).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to use the attributes as in Xiong when implementing the method of Tang. The motivation would be to maintain compatibility with systems already in use.
For Claim 59, Tang as modified above further teaches the method, wherein the at least one traffic route is represented using an attribute “trafficRoutes” in a payload of the second update request (see paragraph 69).
The references as applied above are not explicit as to, but Xiong teaches that the at least one traffic route identifies at least one application server address (see paragraphs 7, abstract), and the attribute “trafficRoutes” is of datatype array (see table 1: known data types).
Thus it would have been obvious to one of ordinary skill in the art at the time the application was filed to use the attributes as in Xiong when implementing the method of Tang. The motivation would be to maintain compatibility with systems already in use.
Allowable Subject Matter
Claims 21-23 and 27-29 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claims 2-4, 13-15, 33-35, 42-44, 49-51, and 55-57 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Munoz De La Torre Alonso et al. (US 2022/0377645) teaches a system for influencing traffic by request from an application function. Li et al. (US 2018/0192471) teaches traffic steering by a PCF using information from an AF. Dao et al. (US 2019/0191330) teaches interactions between core network functions to modify aggregated tunnels. Dannebro et al. (US 2021/0112478) teaches a PCF providing routing rules to an SMF.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CASSANDRA L DECKER whose telephone number is (571)270-3946. The examiner can normally be reached 7:30 am - 4:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Faruk Hamza can be reached at 571-272-7969. 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.
/CASSANDRA L DECKER/Examiner, Art Unit 2466 5/15/2026
/FARUK HAMZA/Supervisory Patent Examiner, Art Unit 2466
Prosecution Insights