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 action is in response to the Remarks filed on 03/19/2026.
Claims 1-3, 5-8, 12-14, 16-19 and 25-30 are presented for examination.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5-8, 12-14, 16-19 and 25-30 are rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al. (US 2018/0337849 A1), in view of Munoz De La Torre Alonso et al. (US 2024/0244501 A1).
As to claim 1, Sharma discloses the invention as claimed, including a method, implemented by a wireless transmit/receive unit (WTRU) (Fig. 1, 102) collocated with a switch component (Fig. 1, 106), the method comprising:
installing, on the switch component (Fig. 1, 106), a network program instance based on a network program configured to process data packets associated with mobile network information elements (¶0019, “(iv) operating the SDN controller to identify one or more SDN programmable switches on which to install the instructions for the media micro flow service; and (v) operating the SDN controller to install the instructions for the media micro flow service on one or more of the identified SDN programmable switches”; ¶0060, “The SDN controller 112 determines how to apply these rules and depending on the implementation may translate the rules into lower level primitives and install them into the programmable network switches, e.g., SDN OpenFlow switches”; ¶0081, “the programmable switch provides one or more of the following media relay services 214 by implementing programming instructions installed or caused to be installed by the SBC via the SDN controller: bandwidth policing based on the negotiated codec or using the Session Description Protocol (SDP) b line or local policy determined by the SBC”; ¶0093, “sending instructions, commands and/or information to the SDN controller which in turn programs, i.e., installs instructions for execution into the programmable switches to implement the policies and instructions provided by the SBC”; ¶0130, “installing flow rules on communications switches 1 1512, 2 1514, 3 1516, . . . N 1518 which for example are SDN-enabled Open Flow switches”);
receiving a data packet from a network node (Fig. 7; Fig. 15; ¶0015, “media packets received by the first programmable switch”; ¶0060, “The signaling plane of the SBC 134 receives the signaling packets and uses this to determine what type of session (or other traffic) they relate to”; ¶0125, “information to the SDN controller to configure one or more SDN switches of the SDN network that receive packet”; ¶0134);
based on the traffic rule:
(i) associating the mobile network information elements with the data packet
(Fig. 4; Fig. 23; ¶0054, “uses this information to dictate how the Internet Protocol (IP) packets for media pass through its data plane. And by virtue of this interaction the SBC is able to police, control, modify and otherwise impact on the packets that are specifically routed through it”; ¶0060, “The signaling plane of the SBC 134 receives the signaling packets and uses this to determine what type of session (or other traffic) they relate to”; ¶0083, “the instructions include matching a packet to a flow based on the contents of the IPv4 or IPv6 packet header and modifying the IP address, before forwarding”; ¶0056; ¶0087); and
(ii) transmitting the data packet and the associated mobile network information elements toward the network program instance (¶0012, “a protocol type to be used for sending media packets of the first media packet flow from the flow origination device to the flow destination device”; ¶0056; ¶0061; ¶0081, “bandwidth policing based on the negotiated codec or using the Session Description Protocol (SDP) b line or local policy determined by the SBC during establishment of the media session, source address filtering, modifying the IP 5-tuple information of the packets in the micro flow for example for IPv6/IPv4 interworking to forward the media flow to the destination”);
processing, on the switch component, by the network program instance, the data packet and the mobile network information elements (¶0056, “programming flow forwarding rules (typically via a controller) in SDN switches (e.g., programmable switches such as Open Flow (OF) enabled switches, the SBC can adjust the flow behavior of packets dynamically across the network. In other words, media forwarding rules can be applied at programmable switches directly”; ¶0060, “determines how to apply these rules and depending on the implementation may translate the rules into lower level primitives and install them into the programmable network switches, e.g., SDN OpenFlow switches”; ¶0134, “The SDN switch one is programmed to identify received packets belonging to the media packet flow sent by device A to device B”); and
transmitting the processed data packet to another network node according to the processed mobile network information elements (¶0218, “the redirection to another SDN switch would be done when media micro flow service does require an action in which rewriting and/or redirection to a media interworking device is required”; ¶0228, “said second mode of operation includes operating the SBC to: i) generate instructions to implement a media micro flow service on the second programmable switch of the software defined network through which the second media packet flow passes; and ii) send said instructions to the software defined network (SDN) controller which controls said second network programmable switch”).
Although Sharma discloses installing, a traffic rule associated with the network program instance (¶0019; ¶0058, “As box 182 shows the SDN controller dynamically sends policy enforcement instructions to the devices of the SDN network, e.g., SDN programmable switches, to enforce the policies”; ¶0060; ¶0067; ¶0136), Sharma does not specifically disclose installing, on the WTRU, a traffic rule associated with the network program instance.
However, Munoz De La Torre Alonso discloses installing, on the WTRU, a traffic rule associated with the network program instance (¶0030, “The network (PCF) installs URSP rules in the UE. A URSP rule includes a traffic descriptor and a list of route selection descriptors as specified in 3GPP TS 23.503”; ¶0053, “At step 217, the UE receives and installs the tethering policy”; ¶0064; ¶0065, “enforcement of the tethering policies at the UE 101 when a tethering device 401 connects to the hotspot of the UE or sends tethering traffic to the UE. Prior to the execution of this procedure, the procedure described in FIG. 2 or FIG. 3 shall have taken place and the UE shall have the tethering policies installed”). It would have been obvious ton one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Sharma to include installing, on the WTRU, a traffic rule associated with the network program instance, as taught by Munoz De La Torre Alonso because it would overall network efficiency and reduce unnecessary overhead in the main network, thereby enhancing quality of service (Munoz De La Torre Alonso; ¶0058; ¶0067; ¶0136).
As to claim 2, Sharma discloses the method of claim 1, wherein the network program instance is configured via external parameter provisioning (¶0058, “As box 182 shows the SDN controller dynamically sends policy enforcement instructions to the devices of the SDN network, e.g., SDN programmable switches, to enforce the policies”; ¶0136, “The TAG01 table entry rule/instruction provides a micro flow bypass service for a type-1 media packet flow where the endpoint devices (devices A and B) of the media packet flow having layer 1 (data link layer connectivity)”).
As to claim 3, Sharma discloses the method of claim 1, wherein the switch component is a virtual switch on the WTRU (Fig. 1, 106; ¶0019, “(iv) operating the SDN controller to identify one or more SDN programmable switches on which to install the instructions for the media micro flow service; and (v) operating the SDN controller to install the instructions for the media micro flow service on one or more of the identified SDN programmable switches”; ¶0060, “The SDN controller 112 determines how to apply these rules and depending on the implementation may translate the rules into lower level primitives and install them into the programmable network switches, e.g., SDN OpenFlow switches”).
As to claim 5, Sharma discloses the method of claim 1, wherein the mobile network information elements associated with the data packet include packet data unit (PDU) session related information elements (¶0004, “handles call signaling (Session Initiation Protocol), and specifies how the Internet Protocol (IP) packets for media pass through its data plane”; ¶0006, “control processing capabilities (SIP capabilities) as well as it media resources capabilities”).
As to claim 6, Sharma discloses the method of claim 5, wherein the PDU session related information elements include any of a single network slice selection assistance information, an application identifier, a PDU session type, a data network name, domain descriptors, a PDU session identifier, a mobile network level of service (¶0004, “handles call signaling (Session Initiation Protocol), and specifies how the Internet Protocol (IP) packets for media pass through its data plane”; ¶0006, “control processing capabilities (SIP capabilities) as well as it media resources capabilities”; ¶0009, “(4) provides end-to-end Service Level Agreement (SLA) control”; ¶0123, “The SDP message which includes the session description generally includes the following information the session name and purpose, time(s) the session is active, the media comprising the session and information needed to receive the media such as for example, addresses, ports, and formats”).
As to claim 7, Sharma discloses the method of claim 1, wherein the processing, by the network program instance, of the data packet is based on the mobile network information elements associated with the data packet (Fig. 4; ¶0054, “uses this information to dictate how the Internet Protocol (IP) packets for media pass through its data plane. And by virtue of this interaction the SBC is able to police, control, modify and otherwise impact on the packets that are specifically routed through it”; ¶0083, “the instructions include matching a packet to a flow based on the contents of the IPv4 or IPv6 packet header and modifying the IP address, before forwarding”; ¶0056; ¶0087).
As to claim 8, Sharma discloses the method of claim 1, wherein the mobile network information elements comprise metadata mobile network information elements of the network (Fig. 4; ¶0054, “uses this information to dictate how the Internet Protocol (IP) packets for media pass through its data plane. And by virtue of this interaction the SBC is able to police, control, modify and otherwise impact on the packets that are specifically routed through it”; ¶0083, “the instructions include matching a packet to a flow based on the contents of the IPv4 or IPv6 packet header and modifying the IP address, before forwarding”; ¶0056; ¶0087).
As to claim 12, it is rejected for the same reasons set forth in claim 1 above. In addition, Sharma discloses an apparatus, including any of a processor and memory (Fig. 3; Fig. 22; ¶0022; ¶0057).
As to claims 13-14, they are rejected for the same reasons set forth in claims 2-3 above, respectively.
As to claims 16-19, they are rejected for the same reasons set forth in claims 5-8 above, respectively.
As to claim 25, Sharma discloses the method of claim 1, wherein the processed mobile network information elements comprise information indicating any of a selection of a traffic rule or a traffic rule action (¶0060, “The signaling plane of the SBC 134 receives the signaling packets and uses this to determine what type of session (or other traffic) they relate to…Having determined the appropriate action(s) to take, the SBC 134 then uses the SDN control plan interface to communicate one or more rules that the SBC 134 wants propagated into the network. The SDN controller 112 determines how to apply these rules and depending on the implementation may translate the rules into lower level primitives and install them into the programmable network switches”; ¶0081, “bandwidth policing based on the negotiated codec or using the Session Description Protocol (SDP) b line or local policy determined by the SBC during establishment of the media session, source address filtering, modifying the IP 5-tuple information of the packets”).
As to claim 26, Sharma discloses the e method of claim 1, wherein processing the data packet and the mobile network information elements comprises determining the value of any mobile network information elements (¶0058, “able to provide instructions to the SDN Controller regarding policy flow instructions, 5-tuple information (source transport number, source Internet Protocol address, destination transport number, destination Internet Protocol address, and Protocol type (e.g., UDP or TCP)), bandwidth, DSCP marking, and Network Address and Port Translation”; ¶0060; ¶0081).
As to claim 27, Sharma discloses the method of claim 1, wherein the processed mobile network information elements associated with the processed data packet include packet data unit (PDU) session related information elements (¶0004, “handles call signaling (Session Initiation Protocol), and specifies how the Internet Protocol (IP) packets for media pass through its data plane”; ¶0006, “control processing capabilities (SIP capabilities) as well as it media resources capabilities”; ¶0009, “(4) provides end-to-end Service Level Agreement (SLA) control”; ¶0123, “The SDP message which includes the session description generally includes the following information the session name and purpose, time(s) the session is active, the media comprising the session and information needed to receive the media such as for example, addresses, ports, and formats”).
As to claims 28-30, they are rejected for the same reasons set forth in claims 25-27 above, respectively.
Applicant's arguments filed on 03/19/2026 have been fully considered but they are not persuasive.
Applicant asserts on page 7 of Remarks that “Sharma fails to teach the claimed
limitations of a (1) "WTRU collocated with a switch component" and (2) "installing, on the switch component, a network program instance."
(1) Examiner respectfully disagrees. Applicant’s arguments rely on language solely recited in preamble recitations in claim 1. When reading the preamble in the context of the entire claim, the recitation "WTRU collocated with a switch component" is not limiting because the body of the claim describes a complete invention and the language recited solely in the preamble does not provide any distinct definition of any of the claimed invention’s limitations. Thus, the preamble of the claim(s) is not considered a limitation and is of no significance to claim construction. See Pitney Bowes, Inc. v. Hewlett-Packard Co., 182 F.3d 1298, 1305, 51 USPQ2d 1161, 1165 (Fed. Cir. 1999). See MPEP § 2111.02.
In addition, Figure 4 of instant application shows that the “WTRU/UPF” is connected to “Switch” through a connection, indicating that the WTRU/UPF and the switch are separate network entities linked via an interface.
PNG
media_image1.png
629
897
media_image1.png
Greyscale
Specification, paragraph [0120] states in part that:
[0120] FIG. 4 is a sequence diagram illustrating an example of an operation of a user network program collocated with a WTRU or UPF. The example operation may be carried out by a WTRU or a UPF and various elements of a communications system, such as the communications system 100 of FIGS. 1A-1D. The various elements may include a source, a destination, a hardware or a software switch component, a (e.g., SDN) controller, and a NEF and/or SMF. The hardware or software switch component may be a part of the WTRU/UPF or may be a network function external from the WTRU/UPF (emphasis added).
Figure 7 of instant application further shows that the “WTRU1” or “WTRU3/AF
(i.e., SDN Controller)”.
PNG
media_image2.png
641
897
media_image2.png
Greyscale
Based on the paragraph [0120] and Figures 4 and 7 of the specification, the application discloses both embodiments in which the switch component is part of the WTRU/UFP and embodiments in which the switch component is external from the WTRU or UPF.
Sharma discloses in Figure 22 and paragraph [0226], a configuration in which the switch component (i.e., SDN controller; Fig. 22, 2200) is part of the WTRU (i.e., I/O interface, transmitter, receiver; Fig. 22, 242, 2230, 2232, 2234, 2236, 2240) (¶0226). In addition, Sharma discloses in Figure 19 and paragraph [0182] that a software or hardware switch (1512-1518) is connected to a WTRU (1980-1986).
PNG
media_image3.png
637
610
media_image3.png
Greyscale
(2) Sharma discloses "installing, on the switch component (i.e., SDN controller), a network program instance” (¶0019, “(iv) operating the SDN controller to identify one or more SDN programmable switches on which to install the instructions for the media micro flow service; and (v) operating the SDN controller to install the instructions for the media micro flow service on one or more of the identified SDN programmable switches”; ¶0060, “The SDN controller 112 determines how to apply these rules and depending on the implementation may translate the rules into lower level primitives and install them into the programmable network switches, e.g., SDN OpenFlow switches”; ¶0081, “the programmable switch provides one or more of the following media relay services 214 by implementing programming instructions installed or caused to be installed by the SBC via the SDN controller: bandwidth policing based on the negotiated codec or using the Session Description Protocol (SDP) b line or local policy determined by the SBC”; ¶0093, “sending instructions, commands and/or information to the SDN controller which in turn programs, i.e., installs instructions for execution into the programmable switches to implement the policies and instructions provided by the SBC”; ¶0130, “installing flow rules on communications switches 1 1512, 2 1514, 3 1516, . . . N 1518 which for example are SDN-enabled Open Flow switches”; ¶0173, “installing all of the rules in one or more switches of the SDN network it also allows the SDN controller”).
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUNGWON CHANG whose telephone number is (571)272-3960. The examiner can normally be reached 9AM-5:30PM.
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, GLENTON BURGESS can be reached at (571)272-3949. 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.
/JUNGWON CHANG/Primary Examiner, Art Unit 2454 May 28, 2026
Prosecution Insights