DETAILED ACTION
The amendments and remarks filed 9/30/2025 were received.
PRIOR ART
1. (4/12/2022 IDS) 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 29.244 version 16.5.0 Release 16 (29.244), titled “LTE; 5G; Interface between the Control Plane and the User Plane nodes,” is prior art under 35 U.S.C. 102(a)(1) as it was published in November, 2020. 29.244.
2. (4/12/2022 IDS) 3GPP TS 23.214 version 14.2.0 Release 14 (23.214), titled “Universal Mobile Telecommunications System (UMTS); LTE; Architecture enhancements for control and user plane separation of EPC nodes,” is prior art under 35 U.S.C. 102(a)(1) as it was published in May 2017.
3. (3/31/2025 PTO-892) CR507 labeled C4-211088 titled “Rule activation failure” is a change request (“CR 507”) to 3GPP 29.244 and is prior art under 35 U.S.C. 102(a)(1) since it is dated 2021-01-15.
CLAIM REJECTIONS — 35 U.S.C. 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:
Conditions for patentability; non-obvious subject matter.
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
CLAIMS 1-16
Claims 1-16 are rejected under 35 U.S.C. 103 as being unpatentable over 29.244 in view of 23.214 and CR507 labeled C4-211088 and titled “Rule activation failure”.
Claim 1
As discussed in detail below, claim 1 is obvious because a teaching, suggestion, or motivation in the prior art would have led one of ordinary skill to modify the prior art reference or to combine prior art reference teachings to arrive at the claimed invention. See MPEP 2143(I)(G).
Scope and contents of the prior art.
Generally, 29.244 [p16] taught about the Packet Forwarding Control Protocol (PFCP) used on the interface between the control plane (CP) and the user plane (UP) function. In the packet forwarding model of 29.244 [p23], the CP controls packet processing in the UP using various rules per PFCP session. The UP function receives a PFCP Session Establishment (or Modification) Request message and applies the rules. If at least one rule failed, an appropriate error response is returned. Of particular relevance are 29.244’s teachings in section 7.2.3.3 [p108-109] of “grouped” information elements (IEs) and its teaching in section 7.2.3.4 [p109] that when several IEs with the same type are included in a PFCP message they represent a list for that IE name.
With respect to claim 1, 29.244 taught or suggested:
A method for operating a wireless network device including a User Plane (UP) and a Control Plane (CP) in communication with the UP (29.244 [title page] taught methods for “LTE; 5G; Interface between the Control Plane and the User Plane nodes.” The Examiner finds that within 3GPP, the UP and CP architecture necessarily include a wireless network device as discussed in 3GPP TS 23.2141),
comprising: receiving, from the CP, at least one configuration message for recording multiple rules in the UP (29.244 [p100] taught that the CP function initiates the PFCP Session Establishment procedure to create a PFCP session; The CP function shall send the PFCP Session Establishment Request message with a new PFCP F-SEID together with Rules to be created; When the UP function receives a PFCP Session Establishment Request message it shall store and apply the rules received in the request. The Examiner finds that the PFCP Session Establishment Request message reads on the claimed “configuration message for recording rules in the UP” since it includes rules for the UP to store (i.e., recording) and apply);
identifying, by the UP, multiple failed rule Identifiers (IDs) for multiple failed rules; (29.244 [p25] taught that Rule ID used for PDR, FAR, BAR, QER, URR or MAR is uniquely identifying a rule of the corresponding rule type within a session. [p100] taught that when the UP function receives a PFCP Session Establishment Request message it shall store and apply the rules [plural] received in the request. [p101] Otherwise, if at least one rule failed to be stored or applied, return an appropriate error cause. The Examiner finds that the UP determining that a rule, having its own Rule ID, failed reads on identifying, by the UP, a failed rule ID. The Examiner finds that since 29.244 explicitly taught applying multiple rules and explicitly taught that at least one rule could fail to be stored or applied, then 29.244 suggested identifying, by the UP, multiple failed rule IDs which failed to be stored or applied.);
and supplying, in a single Packet Forwarding Control Protocol (PFCP) response message from the UP to the CP, a failed rule ID, the PCFP response message being capable of including multiple Information Elements (IE) without specific limitation on the type of IE, the Cause IE being a type of IE, the Cause IE including the failed rule ID, the failed rule ID for determining, by the CP, an action to be taken based on the failed rule ID (29.244 [p100] taught that when the CP function receives a PFCP Session Establishment Response with cause success, the CP function shall continue with the procedure which triggered the PFCP Session Establishment procedure. [p100-101] taught the UP function… send a PFCP Session Establishment Response with cause “success,” if all rules in the PFCP Session Establishment Request are stored and applied; Otherwise, if at least one rule failed to be stored or applied, return an appropriate error cause value with the Rule ID of the Rule causing the first error. [p109] taught if several IEs with the same Type are included in a PFCP message or Grouped IE, they represent a list for the corresponding IE name. [p152-153] taught the PFCP Session Establishment Response shall be sent… as a reply to the PFCP Session Establishment Request; and Failed Rule ID shall be included if the Cause IE indicates a rejection due to a rule creation or modification failure. [p248] taught that Failed Rule ID shall identify the Rule which failed to be created or modified and it includes “Rule ID value.” The Examiner finds that the PFCP response message includes at least the Rule ID of the Rule causing the first error and may also include the Rule IDs of the other failed rules causing errors other than the first error. The Examiner finds that the PFCP response message is capable of including multiple IEs using a Grouped IE, where groups IEs are not limited to certain types of IEs, specifically, the Cause IE which includes a failed rule ID, not being excluded from capability of working as a grouped IE, where multiple Cause IEs grouped as a grouped IE in a PCFP would achieve supplying a single Packet Forwarding Control Protocol (PFCP) response message the multiple failed rule IDs, as claimed. The Examiner finds that the action to be taken based on the failed rule is to abort the Session Establishment procedure. This involves sending a response message which is discussed in 23.214.).
With respect to claim 1, 23.214 taught or suggested:
determining, by the CP, further action to be taken based on the failed rule ID (23.214 [p36] taught the UP function responds with a session establishment response message containing any information that the UP function has to provide to the CP function in response to the control information received. The CP function interacts with the network entity which triggered this procedure (e.g. a peer CP function, an MME or a PCRF). The Examiner notes that the session establishment response message reports the failed rule as discussed above).
With respect to claim 1, CR 507 (C4-211088) taught or suggested:
supplying, in a Packet Forwarding Control Protocol (PFCP) message, the multiple failed rule IDs for determining, by the CP, an action to be taken based on a plurality of the multiple failed rule IDs (On page 1, the CR 507 labeled C4-211088 states that it is a CR for technical specification 29.244. On page 1, CR507 states If the PCRF/PCF tries to install a PCC rule or activate a pre-defined PCC rule, but the rule cannot be installed or activated e.g. because no corresponding pre-defined rule exists in the PCEF, the PGW-C/SMF marks that rule as inactive and sends a rule report back to the PCRF/PCF to flag the problem. On page 2 C4-211088 states A new Partial Success feature is defined to enable the UP function to report a successful establishment or modification of a PFCP session even when the UP function cannot apply some rules. The response identifies the rules that could not be activated. As with 29.244 cited above, this change request states (see page 4) that “at least one rule failed to be stored or applied… return an appropriate error cause value with the Rule ID of the Rule causing the first error” but then it adds an alternative: “alternatively, if the CP function indicated support of the PSUCC feature (see clause 8.2.58) during the PFCP association setup or update procedure, and if this feature is also supported by the UP function, the UP function should accept the request partially, if possible, and return a response indicating a partial acceptance of the request as specified in clause 5.2.x.” On page 3, CR507 states Upon receipt of a PFCP session establishment or modification response indicating a partial acceptance of the request, the CP function shall consider that not all rules were successfully activated in the UP function and determine those which failed to be activated based on the Partial Failure Information IE in the response. On page 4, CR 507 stated If the CP function indicated support of the PSUCC feature (see clause 8.2.58) during the PFCP association setup or update procedure, and if the cause in the response indicates "Request partially accepted", the CP function shall behave as specified in clause 5.2.x. On page 6, regarding the PFCP Session Establishment Response, CR 507 CR-211088 suggests a “Partial Failure Information” IE where “This IE shall be present if the Cause IE indicates partial acceptance of the request to provide failure information related to a failed rule. See Table 7.5.3.1-2. Several IEs within the same IE type may be present to report failures to apply multiple rules.” Accordingly, the Examiner finds that CR 507 CR-211088 taught supplying, in a Packet Forwarding Control Protocol (PFCP) message, the multiple failed rule IDs (i.e., several IEs to report plural failures to apply multiple/plural rules) for determining, by the CP (i.e., the CP function), an action to be taken based on a plurality of the multiple failed rule IDs (i.e., the action being flagging the problem and/or determining those rules which failed to be activated based on the Partial Failure Information IE in the response.))
Differences between the prior art and the claim
The only difference between the prior art and the claimed invention is that while 29.244 taught that PFCP session response messages are capable of including multiple Failed Rule IDs, 29.244 only explicitly taught supplying a PFCP response message with the Rule ID of the Rule causing the first error, rather than multiple failed rule IDs, and taking action based on that Rule ID. However, 23.214 described further action to be taken based on the failed rule ID and CR507 C4-211088, a change request for 29.244, specifically taught that PFCP response messages include indicate multiple Failed Rules.
Level of ordinary skill in the pertinent art.
The pertinent art is that of devising LTE/5G network devices with a separate user plane and control plane. The Examiner finds that a person of ordinary skill in the pertinent art would have been familiar with relevant industry standards, especially 29.244 and 23.214 and the other 3GPP standards mentioned therein, as well as other relevant standards. The Examiner also finds that a person of ordinary skill in the pertinent art would be intimately familiar with the fundamentals of computer networking, including the problem of unwanted “overhead,” as described in Networking Fundamentals2, TCP/IP Illustrated3, and elsewhere. Overhead refers to excess computation time, memory, bandwidth, or other resources that are required to perform a specific task. For instance, the amount of data sent over a network is equal to the sum of the underlying data (payload) and the overhead (headers). Unwanted overhead is the overhead that goes beyond the amount needed to perform the task. From knowledge of this fundamental networking concept, the Examiner finds that one of ordinary skill in the art of devising LTE/5G network devices would immediately recognize the problem of unwanted overhead and would undoubtedly know to avoid it by not sending multiple packets, each with their own header as overhead, when the information can fit within a single packet.
Objective evidence of nonobviousness
The Examiner notes that no objective evidence of nonobviousness was provided with this application. Such evidence, if available, may be submitted in a timely filed affidavit or declaration as described in MPEP 716.01.
Conclusion of obviousness
The Examiner finds that the differences (described above) 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 because some teaching, suggestion, or motivation in the prior art would have led one of ordinary skill to modify the prior art reference or to combine prior art reference teachings to arrive at the claimed invention. See MPEP 2143(I)(G).
(1) The Examiner finds that a person of ordinary skill in the pertinent art would be motivated to combine the teachings of 23.214 with 29.244 because 29.244 suggests and instructs them to use 23.214. For example, 29.244 [p16] taught PFCP shall be used over the Sxa, Sxb, Sxc and the combined Sxa/Sxb reference points specified in 3GPP TS 23.214. In addition, a person of ordinary skill in the pertinent art would be motivated to combine CR507 C4-211088 with 29.244 since CR507 is specifically a change request to change 29.244 as shown on page 1.
(2) The Examiner further finds that 29.244 taught that PFCP response messages are capable of including multiple Failed Rule IEs given that (a) a single PFCP message can include several IEs of the same type; (b) Failed Rule ID is one of the IEs listed in for PFCP session response messages in Table 7.5.3.1-1; and (c) including several Failed Rule ID IEs in a PFCP is not prohibited. Accordingly, there was a reasonable expectation of success in implementing this technique. Furthermore, providing “several IEs within the same IE type may be present to report failures to apply multiple rules” was specifically suggested by CR507 C4-211088. 29.244 already provides a Cause IE with a failed rule ID for identifying a failed rule. And 29.244 provides the functionality of using Grouped IEs in order to send a message with multiple IEs of the same type. Accordingly, there would be a reasonable expectation of success in combining the teachings of the prior art to achieve the claimed invention because doing so merely involves implementing existing functionality according to its intended purpose.
(3) In addition to the above reasoning, the Examiner further finds that a person of ordinary skill in the pertinent art would immediately recognize that sending multiple IEs in different messages would cause the problem of unwanted overhead and they would undoubtedly be motivated to combine the IEs in the manner provided by 29.244. Accordingly, the Examiner concludes that it would be obvious to a person of ordinary skill in the art to include multiple Failed Rule ID IEs in the same PFCP Session Establishment (or Modification) Response message and take action based on the multiple IDs, thereby achieving the claimed invention. In addition, a similar technique of providing “several IEs within the same IE type may be present to report failures to apply multiple rules” was specifically suggested by CR507 C4-211088.
In addition to the conclusion of obviousness above, as further evidence of the obviousness the Examiner points to C4-211088, which is a change request to 3GPP 29.244 which on page 2 suggests to report a successful establishment or modification of a PFCP session even when the UP function cannot apply some rules. The response identifies the rules that could not be activated. As with 29.244 cited in the rejection, this change request states (see page 4) that “at least one rule failed to be stored or applied… return an appropriate error cause value with the Rule ID of the Rule causing the first error” but then it adds an alternative: “alternatively, if the CP function indicated support of the PSUCC feature (see clause 8.2.58) during the PFCP association setup or update procedure, and if this feature is also supported by the UP function, the UP function should accept the request partially, if possible, and return a response indicating a partial acceptance of the request as specified in clause 5.2.x.” On page 6, regarding the PFCP Session Establishment Response, CR-211088 suggests a “Partial Failure Information” IE where “This IE shall be present if the Cause IE indicates partial acceptance of the request to provide failure information related to a failed rule. See Table 7.5.3.1-2. Several IEs within the same IE type may be present to report failures to apply multiple rules.” Accordingly, CR-211088 specifically suggests “identifying, by the UP, multiple failed rule Identifiers (IDs) for multiple failed rules; and supplying, in a single Packet Forwarding Control Protocol (PFCP) response message from the UP to the CP, the multiple failed rule IDs for determining, by the CP, further an action to be taken based on the multiple failed rules- rule IDs.”
Claim 2
With respect to claim 2, 29.244 in view of 23.214 and CR507 taught or suggested the method of claim 1 (see above).
With respect to claim 2, 29.244 taught or suggested:
further comprising sending the PFCP response message via an Sx interface for a 4G wireless network. (29.244 [p16] taught PFCP shall be used over: the Sxa, Sxb, Sxc and the combined Sxa/Sxb reference points specified in 3GPP TS 23.214).
Claim 3
With respect to claim 3, 29.244 in view of 23.214 and CR507 taught the method of claim 1 (see above).
With respect to claim 3, 29.244 taught or suggested:
further comprising sending the PFCP response message via an N4 interface for a 5G wireless network (29.244 [p16] taught the N4 interface specified in 3GPP TS 23.501 [28] and 3GPP TS 23.502 [29]).
Claim 4
With respect to claim 4, 29.244 in view of 23.214 and CR507 taught or suggested the method of claim 1 (see above).
With respect to claim 4, 29.244 taught or suggested:
further comprising using a failed Rule ID IE type to identify, by the UP in the single PFCP response message, a failed rule with failure occurring at creation time (29.244 [p152-153] taught that the PFCP Session Establishment Response shall be sent over the Sxa, Sxb, Sxc and N4 interface by the UP function to the CP function as a reply to the PFCP Session Establishment Request. Table 7.5.3.1-1 taught Information Elements in a PFCP Session Establishment Response including Failed Rule ID - This IE shall be included if the Cause IE indicates a rejection due to a rule creation or modification failure. [p248] taught the Failed Rule ID IE type shall be encoded as shown in Figure 8.2.80-1. It shall identify the Rule which failed to be created or modified).
Claim 5
With respect to claim 5, 29.244 in view of 23.214 and CR507 taught or suggested the method of claim 1 (see above).
With respect to claim 5, 29.244 taught or suggested:
further comprising using a failed Rule ID IE type to identify, by the UP in the single PFCP response message, a failed rule with failure occurring at modification time (29.244 [p152-153] taught that the PFCP Session Establishment Response shall be sent over the Sxa, Sxb, Sxc and N4 interface by the UP function to the CP function as a reply to the PFCP Session Establishment Request. Table 7.5.3.1-1 taught Information Elements in a PFCP Session Establishment Response including Failed Rule ID - This IE shall be included if the Cause IE indicates a rejection due to a rule creation or modification failure. [p248] taught the Failed Rule ID IE type shall be encoded as shown in Figure 8.2.80-1. It shall identify the Rule which failed to be created or modified).
Claim 6
With respect to claim 6, 29.244 in view of 23.214 and CR507 taught or suggested the method of claim 1 (see above).
With respect to claim 6, 23.214 taught or suggested:
further comprising the CP reporting at least one failed rule based on the failed rule IDs to at least one of a Policy and Charging Rules Function (PCRF), an Online Charging System (OCS), and an Offline Charging System (OFCS) (23.214 [p36] taught the UP function responds with an Sx session establishment response message containing any information that the UP function has to provide to the CP function in response to the control information received. The CP function interacts with the network entity which triggered this procedure (e.g. a peer CP function, an MME or a PCRF). The Examiner interprets the CP function “interacting” with the network entity (i.e., PCRF) as reading on the claimed “reporting” given that the interaction is response to the triggered procedure).
While 23.214 taught the limitations above it did not explicitly teach reporting “multiple” failed rule IDs. However, the Examiner notes that the session establishment response message would contain the multiple failed rule IDs as discussed above with respect to claim 1.
The Examiner finds that the difference between the prior art and 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 because a person of ordinary skill in the pertinent art would have been motivated to combine the teachings of 23.214 with 29.244 because 29.244 instructs them to use 23.214. For example, 29.244 [p16] taught PFCP shall be used over the Sxa, Sxb, Sxc and the combined Sxa/Sxb reference points specified in 3GPP TS 23.214.
Claim 7
With respect to claim 7, 29.244 in view of 23.214 and CR507 taught or suggested the method of claim 1 (see above).
With respect to claim 7, 23.214 taught or suggested:
further comprising deciding by at least one of the PCRF, OCS, and OFCS an action to take based on the at least one of the failed rule (23.214 [p36] taught the UP function responds with a session establishment response message containing any information that the UP function has to provide to the CP function in response to the control information received. The CP function interacts with the network entity which triggered this procedure (e.g. a peer CP function, an MME or a PCRF). The Examiner notes that the session establishment response message could contain the failed rules as discussed above with respect to claim 1. The Examiner interprets the “interaction” of the CP with the PCRF in 23.214 as reading on the claimed “deciding” of “further action to take” because these interactions with the CP are actions that the PCRF decided to take).
While 23.214 taught the limitations above it did not explicitly teach action based on “multiple” failed rule IDs. However, the Examiner notes that the session establishment response message would contain the multiple failed rule IDs as discussed above with respect to claim 1 and so action would be taken based upon multiple failed rule IDs.
The Examiner finds 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 because a person of ordinary skill in the pertinent art would have been motivated to combine the teachings of 23.214 with 29.244 because 29.244 instructs them to use 23.214. For example, 29.244 [p16] taught PFCP shall be used over the Sxa, Sxb, Sxc and the combined Sxa/Sxb reference points specified in 3GPP TS 23.214.
Claim 8
With respect to claim 8, 29.244 in view of 23.214 and CR507 taught or suggested the method of claim 1 (see above).
With respect to claim 8, 29.244 taught or suggested:
further comprising deciding, by the CP, a further action to take based on the at least one of the failed rule (29.244 [p202] taught the Cause value shall be included in a response message. In a response message, the Cause value indicates the acceptance or the rejection of the corresponding request message. The Cause value indicates the explicit reason for the rejection… Rule creation/modification Failure; This cause shall be used by the UP function if a received Rule failed to be stored and be applied in the UP function. [p100-101] taught that when the CP function receives a PFCP Session Establishment Response with cause success, the CP function shall continue with the procedure which triggered the PFCP Session Establishment procedure. The Examiner finds, given the context, that when the CP function receives a PFCP Session Establishment Response message with cause failure, the CP function decides to not continue with the procedure which triggered the PFCP Session Establishment procedure. The further action being aborting the procedure).
While 29.244 taught the limitations above it did not explicitly teach further action based on “multiple” failed rule IDs. However, the Examiner notes that the session establishment response message would contain the multiple failed rule IDs as discussed above with respect to claim 1 and so the further action would be taken based upon multiple failed rule IDs.
Claim 9
Claim 9 recites limitations similar to claim 1 and additionally recites “non-transitory computer-readable medium containing instructions.” Performing the step of claim 9 with instructions contained in a “non-transitory computer-readable medium” was well within ordinary skill in the art, as evidenced by [0010] of US 2021/0051564 A1 (Muley), previously cited on 07/24/2024 in the PTO-892. Claim 9 is rejected for this reason along with the reasons give above for claim 1.
Claim 10
Claim 10 recites limitations similar to claim 2 and is rejected by the same reasoning.
Claim 11
Claim 11 recites limitations similar to claim 3 and is rejected by the same reasoning.
Claim 12
Claim 12 recites limitations similar to claim 4 and is rejected by the same reasoning.
Claim 13
Claim 13 recites limitations similar to claim 5 and is rejected by the same reasoning.
Claim 15
Claim 15 recites limitations similar to claim 7 and is rejected by the same reasoning.
Claim 14
Claim 14 recites limitations similar to claim 6 and is rejected by the same reasoning.
Claim 16
Claims 16 recites limitations similar to claim 8 and is rejected by the same reasoning.
RESPONSE TO ARGUMENTS
The Examiner responds below to Applicant’s arguments in the Remarks filed 9/30/2025.
Response to arguments regarding rejections under §103
Applicant’s arguments, see p. 1-4, regarding the rejections under §103 have been fully considered but they are not persuasive.
On page 1, Applicant argued:
According to the Office Action at page 5, "The Examiner finds that the PFCP response message of 3GPP TS 29.244 "includes at least the Rule ID of the Rule causing the first error and may also include the Rule IDs of the other failed rules causing errors other than the first error." The relevant citation is apparently to page 248 of TS 29.244, "§ 8.2.80 Failed Rule ID." However, the cited section is silent regarding "includ[ing] the Rule IDs of the other failed rules causing errors other than the first error," as shown below …
Applicant considered p. 248, which the Examiner did cite, but they should have been looking at [p 109], cited on p. 5 of the Final Rejection dated 3/31/2025, which taught “if several I Es with the same Type are included in a PFCP message or Grouped IE, they represent a list for the corresponding IE name.” On page 5 of that Final Rejection the Examiner already explained how 29.244 suggested “the PCFP response message being capable of including multiple failed rule IDs.” In particular, the Examiner stated, on page 5 of the Final Rejection, “The Examiner finds that the PFCP response message is capable of including multiple failed rule IDs using a Grouped IE.” The ability to use grouped IEs means that a PFCP message can include multiple IEs. 29.244 does not provide any limitation on which IEs are capable be grouped as Groped IEs. Although some IEs may not be grouped according to the specification, they are still capable of being grouped. The Cause IE is an IE and because it is an IE is capable of being grouped using the Grouped IE technique. Accordingly, the PFCP message in 29.244 is capable of “includ[ing] the Rule IDs of the other failed rules causing errors other than the first error.”
On page 2 Applicant argued:
It is unclear whether the Examiner is taking official notice of the above fact, or finding the above-identified limitation inherent in the cited prior art.
The Examiner was not taking official notice. The capability of using Grouped IE functionality is described in 29.244.
On page 3 Applicant states:
Applicant traverses this assertion as not properly officially noticed or not properly based upon common knowledge. The Examiner is requested to support this finding with adequate evidence.
Again, the Examiner was not taking official notice. The support is in 29.244 in the sections discussing the Grouped IE functionality, including p. 109 cited in the previous rejection but also p.108 which provides context for the following discussion on p. 109. Also, p. 194 shows the IE format including “IE specific data or content of a grouped IE.”
On page 3, Applicant argued:
As discussed above, the following assertions are made regarding the prior art that are not expressly found within the prior art and therefore should be properly supported with respect to a finding of inherency: ''The Examiner finds that the PFCP response message of 3GPP TS 29.244 "includes at least the Rule ID of the Rule causing the first error and may also include the Rule IDs of the other failed rules causing errors other than the first error," and "[t]he Examiner finds that the PFCP response message is capable of including multiple failed rule IDs using a Grouped IE.
To clarify, the Examiner meant the similar things by these two statements. The PFCP response message is capable of including multiple failed rule IDs using a Grouped IE, which means that the message may also include the Rule IDs of the other failed rules causing errors other than the first error, because of this capability. The Examiner never argued that the reference explicitly disclosed doing so. The Examiner merely presented the technological capabilities of the existing functionality provided by 29.244. As already discussed above, there is no limitation in 29.244 on which IEs can be Grouped IEs. The Cause IE including the Failed Rule IE is an IE and it is not excluded from being capable of a Grouped IE. It is capable it just isn’t explicitly disclosed to be used in that way. Nevertheless, CR507 C4-211088, a change request for 29.244, describes suppling multiple failed rule IDs as discussed above. Existing Grouped IE functionality in 29.244 could and would be used according to its intended purpose to achieve the claimed invention with a reasonable expectation of success. There is no need to develop new functionality.
On page 4, Applicant argued:
Neither 3GPP TS 29.244 nor 3GPP TS 23.214, alone or in combination, teach or suggest at least "supplying, in a single Packet Forwarding Control Protocol (PFCP) response message from the UP to the CP, the multiple failed rule IDs for determining, by the CP, an action to be taken based on a plurality of the multiple failed rule IDs," as recited by claims 1 and 9.
The rejection above relies on CR507 C4-211088 in teaching this limitation along with 29.244. Specifically, CR507 describes partial success in applying rules where multiple successful rules are reported back and those rules can be used to determine which rules failed, as discussed further above.
CONCLUSION
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Christopher Davis whose telephone number is 703-756-1832. The examiner can normally be reached Mon-Fri from 11AM to 7PM ET. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ayaz Sheikh, can be reached at telephone number 571-272-3795. 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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). Examiner interviews are available via a variety of formats see MPEP § 713.01. To schedule an interview, use the Request Form at https://www.uspto.gov/InterviewPractice.
/C.R.D./ Examiner, Art Unit 2476
/AYAZ R SHEIKH/ Supervisory Patent Examiner, Art Unit 2476
1 3GPP TS 23.214 version 14.2.0 Release 14 (2017-05)
2 Davies, Gordon, Networking Fundamentals, (Packt Publishing: Dec. 2019),
retrieved from https://learning.oreilly.com/library/view/-/9781838643508/
3 Fall, Kevin, TCP/IP Illustrated, Volume 1, (Addison-Wesley Professional: Nov. 2011)
retrieved from https://learning.oreilly.com/library/view/tcp-ip-illustrated-
volume/9780132808200/