DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office correspondence is in response to “Amendment and Response under 37 C.F.R. 1.111 filed on January 26, 1926 in response to a non-final office action issued on December 3, 2025
Claims 1 – 5 and 7 – 21 are pending.
Claims 1, 7, and 16 are amended.
Claim 21 is added.
Claim 6 is cancelled.
Claims 3, 9, and 18 are objected to.
Claims 1 – 2, 4 – 5, 7 – 8, 10 – 17, and 19 – 21 are rejected.
Response to Arguments
Applicant’s arguments filed on 1/26/2026 have been fully considered:
In regards to claims 1 – 9, 14 – 18, and 20 which were rejected under 35 U.S.C. 102 (a) (2) and in regard to claims 10 – 13 and 19 which were rejected under 35 U.S.C. 103 at least one argument is persuasive to the rejection of claims from the last office action and said rejections are withdrawn, but applicant’s amendment necessitated a new search and consideration resulting in a new grounds of rejections for claims 1 – 2, 4 – 5, 7 – 8, 10 – 17, and 19 – 21 under 35 U.S.C. 103, as applicant also added claim 21. The examiner here now responds to each argument. Underlined text indicates claim language that was amended since the last office action.
In regard to claims 1 – 5, 7 – 9, 14 – 18, and 20 the applicant argues the prior aet Zhu fails to anticipate, disclose or teach:
“wherein the client device is a fifth generation (5G) cable residential gateway (5G-CRG) and the wireline connection is associated with data over cable service interface specification (DOCSIS) protocol;”. (as recited in claim 1 and is substantially replicated in claims 7 and 16)
The applicant states:
“ . . . Claim[s] 1-9, 14-18, and 20 stand rejected under 35 U.S.C. § 102 as allegedly being
unpatentable over ZHU (U.S. Patent Publication No. 2024/0056885). Applicant respectfully traverses the rejection
.
For at least the reasons presented in the interview and without acquiescing in the
Examiner's rejection, the cited sections of the applied reference[s], whether taken alone or in any reasonable combination, do[es] not disclose at least "wherein the client device is a fifth generation (5G) cable residential gateway (5G-CRG) and the wireline connection is associated with data over cable service interface specification (DOCSIS) protocol," as recited in claim 1, as amended. Independent claims 7 and 16, as amended, recite similar features. Therefore, independent claims 1, 7, and 16, and the claims that depend thereon, are patentable over the cited sections of the applied references.
Accordingly, Applicant respectfully requests that the Examiner reconsider and withdraw
the rejection of claims 1-9, 14-18, and 20 under 35 U.S.C. § 102 based on ZHU. . . “(Applicant’s remarks pages 9-10)
In response to the applicant’s argument:
The applicant’s amendments substantially changed the scope of the independent claims by further indicating that the client device is a fifth generation (5G) cable residential gateway (5G-CRG) and the wireline connection is associated with data over cable service interface specification (DOCSIS) protocol. The applicant’s argument is persuasive as Zhu does not have that specificity of client device. As such the rejections under 35 U.S.C. 102 (a) (2) and 35 USC 103 are withdrawn, but a search and consideration of the amended claims discovered new grounds of rejection under 35 USC 103, and said claims are therein rejected as being unpatentable over Zhu et al. (U.S. 2024/0056885 A1; herein referred to as Zhu) in view of Gant et al. (U.S. 2023/0326307 A1; herein referred to as Gant) in further view of Garrett et al. (U.S. 2002/0038419 A1; herein referred to as Garrett). The new prior art references of Gant and Garrett is analogous art that in combination with Zhu teach the amended limitations. Therein claims 1-2, 4 – 5, 7 – 8, 14 – 17, and 20 – 21 are rejected using the new grounds of rejection found under 35 U.S.C. 103 over Zhu, Gant, and Garrett, and claims 10 – 13, and 19 are rejected using the new grounds of rejection found under 35 U.S.C. 103 over Zhu, Gant, Garrett, and Patel. Claims 3, 9, and 18 are objected to for having allowable subject matter but are dependent on rejected claims 1, 7, and 16, respectively. The applicant is referred to the objections and rejections of all the claims found below.
The examiner recommends that the applicant review the specification for disclosure that if integrated into the independent claims would distinguish the amended claims from the cited prior art. The applicant may want to integrate dependent claim 3 into independent claim 1, dependent claim 9 into independent claim 7, and dependent claim 18 into independent claim 16 to advance prosecution. The applicant is invited to contact the examiner for an interview to discuss how to move the prosecution forward.
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55. The instant application claims priority to Indian Patent Application No. 2023410805 10, filed on November 28, 2023, and entitled “NON-ACCESS STRATUM TRANSPORT FOR CLIENT DEVICES IN CABLE NETWORKS” and to Indian Patent Application No. 202341080529 filed on November 28, 2023, and entitled “TRANSPORT FOR CLIENT DEVICE DATA PACKETS IN CABLE NETWORKS.” Therein the applicant is entitled to a priority date of 11/28/2023.
35 USC § 101 Analysis
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1 – 5, and 6 -21 are directed to statutory subject matter and are not rejected under 35 USC 101 because of a judicial exception. The claimed subject matter is integrated into a practical application under Prong 2 of the Step 2A analysis described in MPEP 2016.04(d). The claims are directed to non-abstract improvements in computer related technology. A claim is non-statutory when it is directed to a judicial exception (e.g. either one of mathematical concepts, mental processes, or certain methods of organizing human activity) without significantly more. The claimed invention is not directed to a judicial exception. Instead, the claimed invention is directed to a technological improvement for the communication of data packets between a client device such as a cable modem of a cable network via a wireline connection to a 5G core network by providing a transport protocol between the client device (5G-SRG) and an access gateway function (AGF) device associated with the core network, where the client device is connected to the AGF device via a wireline connection (e.g., a cable network connection). The transport protocol may utilize IP and user datagram protocol (UDP) (e.g., to allow communication between the client device and the AGF device), and may also utilize an IP tunnel, such as a general packet radio service (GPRS) tunneling protocol (GTP) for user data (GTP-U) tunnel, to secure communications between the client device and the AGF device. The ordered steps of the claim language impose meaningful limits on the scope of the claims and provides a specific improvement via a solution for a transport protocol to allow communication of data packets via a wireline connection (e.g. that is associated with a cable network). Therein the claim is statutory under 35 U.S.C. 101.
Allowable Subject Matter
Claim 3, 9, and 18 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.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 – 2, 4 – 5, 7 – 8, 14 – 17, and 20 -21 are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (U.S. 2024/0056885 A1; herein referred to as Zhu) in view of Gant et al. (U.S. 2023/0326307 A1; herein referred to as Gant) in further view of Garrett et al. (U.S. 2002/0038419 A1; herein referred to as Garrett).
In regard to claim 1, Zhu teaches A method (see ¶ ¶ [0244-0245] “ . . . methods disclosed herein are provided below. An embodiment of the devices, systems, and methods may include any one or more, and any combination of, the examples described below. Example 1 includes one or more examples, and includes an apparatus that includes: a network device comprising: at least one network interface and circuitry to transmit one or more packets for Integrated Access Backhaul (IAB) via a 3rd Generation Partnership Project (3GPP)-consistent wireless network and transmit one or more other packets for IAB to Multi Access Management Services (MAMS) over Generic Multi-Access (GMA) over a second network, comprising:
sending, by a client device (e.g. MX client 101), to an access gateway function (AGF) device (e.g. Fixed AN Node 111), and via a wireline connection (see Fig. 1B ¶ ¶ [0040-0042] “ . . . MAMS server 140 runs in an edge computing system/platform/network and/or a cloud computing system/service/platform, and can deliver traffic between client server over multiple connections or paths. In some examples, the edge compute nodes comprise(s) a MEC host (or MEC server). Additionally or alternatively, the MX server 140 may include one or more MEC applications (apps) operated by a MEC server/host (see e.g., “[MEC]”). Various aspects of MEC hosts and MAMS servers are discussed in more detail infra. The MX UE 101 (or “multi-radio UE 101”) accesses or otherwise communicates with a data network (DN) 175 or local service 170 (also referred to as a local DN 170) via one or more (radio) access networks (“(R)ANs”) 110 and the server 140. Each (R)AN 110 is a segment in a network that delivers user data packets to the client 101 and/or server 140 via access link(s) 105, which may be a wired connection (e.g., Ethernet, DSL, Coax, USB, and/or the like) or a wireless (radio) connection (e.g., WiFi airlink, 5G/NR airlink, LTE airlink, and/or the like). One or more of the (R)ANs 110 implement an access technology (“AT”), which is the underlying mechanism(s) used to access a corresponding network. In some examples, the AT is a fixed access (wired) technology such as Ethernet, digital subscriber line technologies (DSL or xDSL); G.hn; coaxial cable access (“coax”) such as Multimedia over Coax Alliance (MoCA), Data Over Cable Service Interface Specification (DOCSIS), and/or the like; powerline communication (“PLC” or “powerline”) such as high definition (HD)-PLC and/or the like; Fiber to the x (FTTX; also referred to as “fiber in the loop”); Passive Optical Network (PON); and/or the like. Here, (R)AN node 111 may be a broadband modem (e.g., cable modem, DSL modem, an Optical Network Terminal (ONT) or an Optical Network Unit (ONU), G.hn semiconductor device, etc.), which may be used in combination with customer premises equipment (e.g., home/enterprise router(s), residential/enterprise gateway(s), mesh network device(s), WiFi access point(s), etc.). Fixed AN node 111 can connect the client 101 to access network 110 via an access connection 105 that operates according to an access protocol (e.g., Ethernet, V.35, Universal Serial Bus (USB) and/or Ethernet over USB, Point-to-Point Protocol over Ethernet (PPPoE), Internet Protocol over Ethernet (IPoE), G.hn, DOCSIS, and/or the like). Here, the access connection 105 may include one or more wires (e.g., telephone wiring, coax, power lines, plastic and/or glass optical fibers, and/or the like), and the particular wires used may depend on the underlying AT and/or infrastructure .. ..”), one or more first encapsulated Internet protocol (IP) transport data packets (see ¶ [0005] “ . . . Generic Multi-Access (GMA) Encapsulation Protocol (e.g., Zhu et al., Generic Multi-Access (GMA) Convergence Encapsulation Protocols, IETF, RFC 9188, ISSN: 2070-1721 (February 2022) (“[RFC9188]”)) convergence protocol has been proposed to support multi-path management by adding additional control information for multi-path management (e.g., sequence number into internet protocol (IP) data packet). . . .” see ¶ [0178] “ . . . GMA protocol can be used to manage traffic steering, splitting, and duplicating across multiple connections and per-packet priority marking. GMA protocol can be used to determine packet priority based on the SID and/or TID from the RTP header, and store packet priority in a GMA header. GMA sends encapsulated IP packets to a target network and an underlying access network (e.g., LTE, Wi-Fi, etc.) manages traffic based on the priority value in the GMA header. An access network can include LTE, 5G, Wi-Fi, DSL, and/or other networks. In some examples, an access network supports per-packet priority-based traffic management (e.g., based on packet priority marking). . . .”),
; and
receiving, by the client device, from the AGF device, and via the wireline connection (e.g. described for both directions) (see (see Fig. 1B ¶ ¶ [0045-0046] “ . . . In the example of FIG. 1B, (R)AN 110A is a 3GPP-based access network such as an LTE E-UTRAN where one or more (R)AN nodes 111A are evolved NodeBs (eNBs) or a next generation RAN (NG-RAN) where the one or more (R)AN nodes 111 are Next Generation NodeBs (gNBs) and/or NG Evolved Node-Bs (NG-eNBs). Additionally, in the example of FIG. 1B, the (R)AN 110A is a WiFi-based access network where the (R)AN nodes 111B are WiFi Access Points (APs). APs may be, for example, wireless routers, roadside ITS stations or roadside units, gateway appliances, central hubs, or the like. The multi-radio UE 101 is capable of establishing a 3GPP access link 105A with eNB/gNB 111A (e.g., Uu interface or the like), and capable of establishing a WiFi access link 105B with AP 111B. eNB/gNB 111A communicates with the server 140 via a 3GPP backhaul link 106A and the AP 111B communicates with the server 140 via a WiFi backhaul link 106B. The 3GPP backhaul link 106A and the WiFi backhaul link 106B may be a suitable wired connection such as Ethernet, USB, Data Highway Plus (DH+), PROFINET, or the like. Furthermore, the MX server 140 is also communicatively coupled with a core network 150A via backhaul interface 107A and communicatively coupled with a Fixed Access (FA) gateway (GW) and/or FA-Core network 150B via backhaul link 107B. Core network 150A may be a 3GPP core network such as a 5G core network (5GC) or an LTE Evolved Packet Core (EPC). Additionally or alternatively, the FA-GW may be a broadband network gateway (BNG) and/or the FA-Core may be broadband core that provides transport, and various resources provide content (provider data center, video head end, and so on). Additionally or alternatively, the FA-GW/Core may be a residential gateway (RG), a 5G-RG, a Fixed Network (FN) RG (FN-RG), an FN Broadband RG (FN-BRG), an FN Cable RG (FN-CRG), a Wireline 5G Access Network (W-5GAN), a Wireline 5G Cable Access Network (W-5GCAN), a Wireline Access Gateway Function (W-AGF), and/or some other suitable element/entity. Individual links 105, 106, or 107 may be referred to as access network connections (ANCs) or access network paths (ANPs). For example, an ANC or ANP may comprise a radio link 105 between client 101 and (R)AN node 111 in one or both directions. Additionally or alternatively, an ANC or ANP may refer to a combination of a link 105 and link 106 between client 101 and MX server 140 in one or both directions. Additionally or alternatively, an ANC or ANP may refer to a combination of a of links/paths 105, 106 and 107 between client 101 and local service 170 or data network 175 in one or both directions. Unless stated otherwise, the terms ANC, ANP, “link,” “channel,” “path,” “connection,” and the like may be used interchangeably throughout the present disclosure. . . “) , one or more second encapsulated IP transport data packets (see ¶ [0005], ¶ [0178] as described above)
Zhu fails to explicitly teach,
However Gant teaches wherein the client device (see gateway assembly) is a fifth generation (5G) cable residential gateway (5G-CRG) and the wireline connection is associated with data over cable service(see Gant Fig. 1, Fig. 2 ¶¶ [0024-0025] “ . . . The first notifier 108 further includes a transceiver module 208 for transmitting/receiving signals from the gateway assembly 106. For instance, the transceiver module 208 may transmit the trigger signal, the identification signal, and any other signal to the gateway assembly 106 (such as through or more antennas, not labeled). Further, the transceiver module 208 may receive at least one control signal from the gateway assembly 106, such as for triggering the notification assembly 206 or for providing system registration data to the identification assembly 204. Of course, the first gateway transceiver module 302 may be configured as a transceiver or as a separate notifier and receiver. The transceiver module 208 may be configured to transmit/receive wireless signals and/or signals sent via wired means (e.g., a cable or optical fiber systems) to/from the gateway assembly 106. The signals associated with the transceiver module 208 may include wireless communication signals such as radio frequency, electromagnetics, local area network (LAN), wide area network (WAN), virtual private network (VPN), wireless network (using 802.11, for example), 245 MHz, Z-WAVE®, MQTT, Zigbee, cellular network (using 2G, LTE and/or 5G, for example), and/or other signals. The transceiver module 208 (including any antennas) may include or be related to, but are not limited to, WWAN (GSM, CDMA, and WCDMA), WLAN (including BLUETOOTH® and Wi-Fi), WMAN (WiMAX), antennas for mobile communications, antennas for Wireless Personal Area Network (WPAN) applications (including RFID and UWB). In some embodiments, an antenna of the transceiver module 208 may receive signals or information specific and/or exclusive to itself. In some embodiments, the signals associated with the transceiver module 208 may include various wired connections. . . .”) ;
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate systems and methods for maintaining an in-building device connected for both 5G and wired cable communications in a security platform into systems and methods for providing flexible selection of network paths in a multi-connection (access) communication environment, for example a wireline connection for transport in a cellular network, as taught by Zhu. Such incorporation integrates residential wired traffic into a 5G cellular network.
The combination of Zhu and Gant fails to explicitly teach,
However Garrett teaches interface specification (DOCSIS) protocol (see Garrett ¶ [0015] “ . . . As described in further detail herein, tunneling can be accomplished in different layers of the protocol stack. In one embodiment of the present invention, the technique of IP encapsulation can be utilized-so that the different IP-based services offered by the different service networks 151 and 152 utilize shared layer one and layer two resources in the access network infrastructure 120. FIG. 2A shows an exemplary access architecture for practicing this embodiment based on a hybrid fiber coaxial (HFC) access network. As is known in the art, each network interface device 201 . . . 202 is either connected to or integrated with a cable modem 211 which enables communication through the HFC network 221. In accordance with the Data Over Cable Service interface Specification (DOCSIS), . . .”).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate systems and methods for multiple service delivery over an access, as taught by Garrett, into systems and methods for providing flexible selection of network paths in a multi-connection (access) communication environment, for example a wireline connection for transport in a cellular network, and encapsulation with IP over a 5G cellular network, as taught by the combination of Zhu and Gant. Such incorporation enables use of the DOCSIS protocol.
In regard to claim 2, the combination of Zhu, Gant and Garrett teaches wherein each encapsulated IP transport data packet of the one or more first encapsulated IP transport data packets and the one or more second encapsulated IP transport data packets includes a general packet radio service (GPRS) tunneling protocol (GTP) for user data (GTP-U) header (see Zhu ¶ [0094] “ . . . IAB-Node can be assigned three IP addresses for IP #1, #2, and #3, respectively. IAB-Donor can also be assigned three IP addresses for IP #1, #2, and #3, respectively. IAB-Node and IAB-Donor can be assigned different interfaces for IP #1 and IP #2 and a virtual interface for IP #3. For example, for communication between IAB-Node and IAB-Donor, UDP over IP (UDP/IP) tunnels can be utilized based on each of IP address #1 and IP address #2. IP address #3 can be used for backhaul traffic (e.g., Stream Control Transmission Protocol (SCTP), GPRS Tunnelling Protocol User Plane (GTP-U), etc.) . . .”; see Zhu ¶ [0248] “ . . . Example 4 includes one or more examples, wherein the traffic transmitted over the second network comprises a multi-access (MX) uplink (UL) user-plane (UP) Transport Layer (TNL) information element (IE) for the IAB BAP layer specifies offset from end of UDP field to beginning of GTP-u header field. . . .”).
In regard to claim 4, Zhu teaches wherein:
each first encapsulated IP transport data packet of the one or more first encapsulated IP transport data packets includes a first header (see Zhu, ¶ [0099] “ . . . MX-IAB donor can send GTP-U or/and F1-AP packets using GMA, and mark the Connection ID field in GMA header accordingly to identify the GMA payload type, e.g., IP, GTP-U, or F1-AP. An application can cause transmission of backhaul traffic, e.g., GTP-U or F1-AP, over a virtual IP anchor connection. In this case, GMA client/server can detect use of GTP-U or F1-AP based on the F1 IP parameters information in the MX UP Setup Config and Confirm message and remove the UDP/IP (or SCTP/IP) header in backhaul traffic before transmission over a physical connection . . .”) with a first tunnel endpoint identifier (TEID) associated with the AGF device (see Zhu ¶ [0100] “ . . . As specified in TS 38.340 (2022) and TS 38.473 (2022), the UL (Uplink) UP (User-Plane) Transport Layer (TNL) information element (IE) can be used to identify F1-U packets at the BAP (Backhaul Adaptation Protocol) layer in IAB donor and node. The IE can include one or more of the following parameters: Transport Layer Address and GTP-TEID. Transport Layer Address and GTP-TEID can be used to identify F1-U packets at the BAP layer in IAB donor and node. . . .”) ; and
each second encapsulated IP transport data packet of the one or more second encapsulated IP transport data packets includes a second header (see Zhu Fig. 7, ¶¶ [0101-0102] “ . . . FIG. 7 depicts an example of Multi-Access (MX) BAP Service Data Unit (SDU) formats. In format 700, the GTP header offset is “0” for the legacy BAP SDU based on 3GPP standard TS 38.340 (2022). However, where a GMA header is inserted before a GTP-u header field, a location of a GTP tunnel endpoint ID in an SDU 700 may not be properly specified or determined by the receiver. In some examples, an enhanced MX UL UP TNL information element (IE) (not shown) can include parameter GTP header offset 706 that can indicate where the GTP-u header begins, after an end of the UDP header field. IAB Node (e.g., GMA client and CCM of FIG. 3) can send the IE to IAB Donor. An IE can send a GTP header offset out of band from SDU. Various examples of an IE can be consistent at least with TS 38.340 (2022) and TS 38.473 (2022). In format 702, a starting position of GTP-u header field after an end of the UDP header field (e.g., the GTP header offset) can be based on GTP header offset 706 (e.g., a sum of UDP header length, IP header length, and GMA header length). In format 704, the GTP header offset from end of UDP header field to start of GTP-u header can be based on length of the GMA header specified by GTP header offset field 706 . . .”) with a second TEID associated with the client device (see Zhu ¶ [0100] as described above)
In regard to claim 5, Zhu teaches wherein each encapsulated IP transport data packet of the one or more first encapsulated IP transport data packets and the one or more second encapsulated IP transport data packets includes a header that includes quality of service (QoS) information (see Zhu ¶¶ [0119-0121] “ . . . n scenarios where multiple wireless or wireline networks (e.g., coaxial, fiber, cable, wired) are available, it may be desirable to distribute traffic over multiple networks. However, a second network may not provide a sufficient level of quality of service (QoS) for the traffic. If transmission of a flow using one network to a second network is to occur, a determination can be made as to whether a QoS for a flow is expected to be met where traffic is transmitted over the second network. For example, a QoS for the flow can specify a 100 milliseconds delay or 10.sup.−3 loss rate. If packets of the flow are sent over a cellular (e.g., 5G network) and a Wi-Fi network (e.g., IEEE 802.11) or other network is available, before moving packets of the flow to the Wi-Fi network or other network, a determination can be made of whether the Wi-Fi network or other network can meet the QoS for the flow. Various examples provide multi-access traffic steering with a check to determine if QoS requirements of the traffic flow are met prior to changing to use of the second network. For example, various examples of QoS testing can apply at least to changing from transmitting one or more packets for Integrated Access Backhaul (IAB) via a 3rd Generation Partnership Project (3GPP)-consistent wireless network to transmitting one or more other packets for IAB to Multi Access Management Services (MAMS) over Generic Multi-Access (GMA) over a second network. For example, various examples of QoS testing can apply at least to changing from transmitting via a network between GMA client and GMA server to use of a GMA relay or changing from use of a GMA relay to transmitting via a network between GMA client and GMA server. A flow can be a sequence of packets being transferred between two endpoints, generally representing a single session using a known protocol. Accordingly, a flow can be identified by a set of defined tuples and, for routing purpose, a flow is identified by the two tuples that identify the endpoints, e.g., the source and destination addresses. For content-based services (e.g., load balancer, firewall, intrusion detection system, etc.), flows can be differentiated at a finer granularity by using N-tuples (e.g., source address, destination address, IP protocol, transport layer source port, and destination port). A packet in a flow is expected to have the same set of tuples in the packet header. A packet flow to be controlled can be identified by a combination of tuples (e.g., Ethernet type field, source and/or destination IP address, source and/or destination User Datagram Protocol (UDP) ports, source/destination TCP ports, or any other header field) and a unique source and destination queue pair (QP) number or identifier. A packet may be used herein to refer to various formatted collections of bits that may be sent across a network, such as Ethernet frames, IP packets, TCP segments, UDP datagrams, etc. Also, as used in this document, references to L2, L3, L4, and L7 layers (layer 2, layer 3, layer 4, and layer 7) are references respectively to the second data link layer, the third network layer, the fourth transport layer, and the seventh application layer of the OSI (Open System Interconnection) layer model . . .”)
In regard to claim 7, Zhu teaches An access gateway function (AGF) device (see Fig. 1B Fixed AN node 111, and Fig. 26), comprising:
one or more memories (see ¶ [0225] “ . . . Memory subsystem 2620 represents the main memory of system 2600 and provides storage for code to be executed by processor 2610, or data values to be used in executing a routine. Memory subsystem 2620 can include one or more memory devices 2630 such as read-only memory (ROM), flash memory, one or more varieties of random access memory (RAM) such as DRAM, or other memory devices, or a combination of such devices. Memory 2630 stores and hosts, among other things, operating system (OS) 2632 to provide a software platform for execution of instructions in system 2600. . . .”) ; and
one or more processors (see ¶ [0222] “ . . . FIG. 26 depicts an example system. Components of system 2600 (e.g., processor 2610, accelerators 2642, network interface 2650, memory 2630, storage 2684, and so forth) can be configured to transmit IAB traffic using one or more networks (e.g., relay device), test QoS of another network, or perform congestion management and congestion signaling, as described herein. System 2600 includes processor 2610, which provides processing, operation management, and execution of instructions for system 2600. Processor 2610 can include any type of microprocessor, central processing unit (CPU), graphics processing unit (GPU), processing core, or other processing hardware to provide processing for system 2600, or a combination of processors. Processor 2610 controls the overall operation of system 2600, and can be or include, one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), or the like, or a combination of such devices. . . .”) to:
receive, from a client device (e.g. MX client 101) and via a wireline connection (see Fig. 1B ¶ ¶ [0040-0042] as described for the rejection of claim 1 and is incorporated herein) , one or more first encapsulated Internet protocol (IP) transport data packets (see ¶ [0005], ¶ [0178] as described for the rejection of claim 1 and is incorporated herein) ;
; and
send, to the client device, via the wireline connection (e.g. described for both directions) (see (see Fig. 1B ¶ ¶ [0045-0046] as described for the rejection of claim 1 and is incorporated herein) , one or more second encapsulated IP transport data packets (see ¶ [0005], ¶ [0178] as described for the rejection of claim 1 and is incorporated herein).
Zhu fails to explicitly teach,
However Gant teaches wherein the client device (see gateway assembly) is a fifth generation (5G) cable residential gateway (5G-CRG) and the wireline connection is associated with data over cable service(see Gant Fig. 1, Fig. 2 ¶¶ [0024-0025] as described for the rejection of claim 1 and is incorporated herein).
The motivation to combine Gant with Zhu is described for the rejection of claim 1 and is incorporated herein.
The combination of Zhu and Gant fails to explicitly teach,
However Garrett teaches interface specification (DOCSIS) protocol (see Garrett ¶ [0015] as described for the rejection of claim 1 and is incorporated herein)
The motivation to combine Garrett with the combination of Zhu and Gant is described for the rejection of claim 1 and is incorporated herein.
In regard to claim 8, the combination of Zhu, Gant, and Garrett teaches wherein each encapsulated IP transport data packet of the one or more first encapsulated IP transport data packets and the one or more second encapsulated IP transport data packets includes a general packet radio service (GPRS) tunneling protocol (GTP) for user data (GTP-U) header (see Zhu ¶ [0094], ¶ [0248] as described for the rejection of claim 2 and is incorporated herein).
In regard to claim 14, the combination of Zhu, Gant, and Garrett teaches wherein:
each first encapsulated IP transport data packet of the one or more first encapsulated IP transport data packets includes a first header (see Zhu, ¶ [0099] as described for the rejection of claim 4 and is incorporated herein) with a first tunnel endpoint identifier (TEID) associated with the AGF device (see Zhu ¶ [0100] as described for the rejection of claim 4 and is incorporated herein) ; and
each second encapsulated IP transport data packet of the one or more second encapsulated IP transport data packets includes a second header(see Zhu Fig. 7, ¶¶ [0101-0102] as described for the rejection of claim 4 and is incorporated herein) with a second TEID associated with the client device (see Zhu ¶ [0100] as described for the rejection of claim 4 and is incorporated herein).
In regard to claim 15, the combination of Zhu, Gant, and Garrett teaches wherein each encapsulated IP transport data packet of the one or more first encapsulated IP transport data packets and the one or more second encapsulated IP transport data packets includes a header that includes quality of service (QoS) information (see Zhu ¶¶ [0119-0121] as described for the rejection of claim 4 and is incorporated herein).
In regard to claim 16, Zhu teaches A non-transitory computer-readable medium storing a set of instructions, the set of instructions (see ¶ [0237] “ . . . Some examples may be implemented using or as an article of manufacture or at least one computer-readable medium. A computer-readable medium may include a non-transitory storage medium to store logic. In some examples, the non-transitory storage medium may include one or more types of computer-readable storage media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. In some examples, the logic may include various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, API, instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof . . . “) comprising:
one or more instructions that, when executed by one or more processors (see ¶ [0222] “ . . . FIG. 26 depicts an example system. Components of system 2600 (e.g., processor 2610, accelerators 2642, network interface 2650, memory 2630, storage 2684, and so forth) can be configured to transmit IAB traffic using one or more networks (e.g., relay device), test QoS of another network, or perform congestion management and congestion signaling, as described herein. System 2600 includes processor 2610, which provides processing, operation management, and execution of instructions for system 2600. Processor 2610 can include any type of microprocessor, central processing unit (CPU), graphics processing unit (GPU), processing core, or other processing hardware to provide processing for system 2600, or a combination of processors. Processor 2610 controls the overall operation of system 2600, and can be or include, one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), or the like, or a combination of such devices. . . .”) of an access gateway function (AGF) device see Fig. 1B Fixed AN node 111, and Fig. 26) , cause the AGF device to:
receive, from a client device (e.g. MX client 101) and via a wireline connection (see Fig. 1B ¶ ¶ [0040-0042] as described for the rejection of claim 1 and is incorporated herein) , one or more first encapsulated Internet protocol (IP) transport data packets (see ¶ [0005], ¶ [0178] as described for the rejection of claim 1 and is incorporated herein)
; and
send, to a user plane function (UPF) device (e.g. user devices in the network in both directions) (see Fig. 1B ¶ ¶ [0045-0046] as described for the rejection of claim 1 and is incorporated herein), based on the one or more first encapsulated IP transport data packets, one or more second encapsulated IP transport data packets (see ¶ [0005], ¶ [0178] as described for the rejection of claim 1 and is incorporated herein)
Zhu fails to explicitly teach,
However Gant teaches wherein the client device (see gateway assembly) is a fifth generation (5G) cable residential gateway (5G-CRG) and the wireline connection is associated with data over cable service(see Gant Fig. 1, Fig. 2 ¶¶ [0024-0025] as described for the rejection of claim 1 and is incorporated herein).
The motivation to combine Gant with Zhu is described for the rejection of claim 1 and is incorporated herein.
The combination of Zhu and Gant fails to explicitly teach,
However Garrett teaches interface specification (DOCSIS) protocol (see Garrett ¶ [0015] as described for the rejection of claim 1 and is incorporated herein)
The motivation to combine Garrett with the combination of Zhu and Gant is described for the rejection of claim 1 and is incorporated herein.
In regard to claim 17, the combination of Zhu, Gant, and Garrett teaches wherein each first encapsulated IP transport data packet, of the one or more first encapsulated IP transport data packets, includes a general packet radio service (GPRS) tunneling protocol (GTP) for user data (GTP-U) header (see Zhu ¶ [0094], ¶ [0248] as described for the rejection of claim 2 and is incorporated herein).
In regard to claim 20, the combination of Zhu, Gant, and Garrett teaches wherein each encapsulated IP transport data packet of the one or more first encapsulated IP transport data packets includes a header that includes quality of service (QoS) information (see Zhu ¶¶ [0119-0121] as described for the rejection of claim 5 and is incorporated herein).
In regard to claim 21, the combination of Zhu, Gant, and Garrett teaches wherein the first encapsulated IP transport data packets are sent via a cable modem termination system (CMTS) of a cable network (see Garrett ¶ [0015] “ . . . a Cable Modem Termination System (CMTS), shown as 225 in FIG. 2A, communicates with the cable modems 211 and manages access to both upstream and downstream cable capacity on the HFC networks 221. See, e.g., "Data-Over-Cable Service Interface Specifications: Cable Modem Termination System--Network Side Interface Specification," Cable Television Laboratories, Inc., SP-CMTS-NSI-I01-960702; "Data-Over-Cable Service Interface Specifications: Cable Modem to Customer Premise Equipment Interface Specification," Cable Television Laboratories, Inc., SP-CMCI-C02C-991015; "Data-Over-Cable Service Interface Specifications: Baseline Privacy Plus Interface Specifications," Cable Television Laboratories, Inc., SP-BPI+-I06-001215, which are incorporated by reference herein. The CMTS 225 manages the scheduling of both upstream and downstream transmission and allocates cable capacity to individual customers identified by a Service ID (SID). The CMTS 225 can have an integrated router 228 or can be a separate device 226 that bridges to a fast Ethernet switch 227 which connects to the router 228. The IP router 228 provides connectivity to an IP network 222 which interfaces to IP routers 241 and 242 in service networks 251 and 252, respectively. Accordingly, the HFC network 221, the CMTS 225, and the IP network 222 correspond to the access network infrastructure 120 shown in FIG. 1. FIG. 2B shows a conceptual diagram of the end-to-end communication protocol stack from a network access device 201 (101) to a router 241 (141) in service provider's network 251 (151) where IP encapsulation is being utilized. As is known in the art, the lowest layer deals with the physical layer (PL) of the protocol stack, e.g. the Ethernet physical media device (PMD) layer; the second layer deals with the data link layer, e.g. the Ethernet Media Access Control (MAC) layer; while the third layer in the protocol stack deals with the network layer, e.g. the IP layer. As shown in the network layer of the protocol stack in FIG. 2B, IP traffic between the network access device 201 and the router 241 in the service network 251 is encapsulated within another IP layer. . . .”)
The motivation to combine Garrett with the combination of Zhu and Gant is described for the rejection of claim 1 and is incorporated herein. Additionally, Garrett enables traffic to be encapsulated on the access connection.
Claims 10 – 13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (U.S. 2024/0056885 A1; herein referred to as Zhu) in view of Gant et al. (U.S. 2023/0326307 A1; herein referred to as Gant) in further view of Garrett et al. (U.S. 2002/0038419 A1; herein referred to as Garrett) as applied to claims1 – 2, 4 – 5, 7 – 8, 14 – 17, and 20 -21 in view of Patel et al. (U.S. 2022/0345972 A1; herein referred to as Patel).
In regard to claim 10, the combination of Zhu, Gant, and Garrett fails to explicitly teach,
However Patel teaches wherein the one or more processors are further to:
decapsulate the one or more first encapsulated IP transport data packets (see Patel Fig. 2 ¶ ¶ [0034-0037] “ . . .“Direct inbound packets” may be those passing through the gNodeB 106 that are not redirected, such as packets moving from left to right along the path 204 in FIG. 2. The direct inbound packets are transmitted from UE 102 to gNodeB. As received by gNodeB, the direct inbound packets may be D-type packets, e.g., IPv4 or IPv6. As output by the gNodeB 106, the direct inbound packets may be A-type packets transmitted by the gNodeB 106 to the translation module 208. In particular, the A-type packet may be a GTP packet encapsulating the IP packet received from the UE 102. The translation module 208 converts the A-type direct inbound packets to B-type packets and transmits the B-type direct inbound packets over the network 210 to the UPF 112 using information included in the outer IP header of the A-type direct inbound packets. As noted above, information from the GTP field of an A-type packet may be included in the SRH′ field of the B-type packet obtained from it in order to enable translation back into an A-type packet. However, the B-type packet itself may be an SRv6 packet rather than a GTP packet. The B-type packet further includes the inner IP header and payload data from the A-type packet. The B-type direct inbound packets may be routed to the translation module 212, which converts the direct inbound packets from B-type packets back into A-type packets using information stored in the SRH′ of the B-type packets. In particular, the data in the SRH′ field of a B-type packet is used to generate a GTP header of a GTP packet including the inner IP field and payload data of the B-type packet, the GTP packet being the A-type direct inbound packet for the B-type direct inbound packet. After conversion by translation module 212, the A-type direct inbound packets are transmitted to the UPF 112. The UPF 112 may then decapsulate the direct inbound packet to obtain the inner IP packet (e.g., a D-type packet received from UE 102) and forward the D-type direct inbound packets to the MEC server 116 . . . “).;
generate, based on the decapsulated one or more first encapsulated IP transport data packets, one or more third encapsulated IP transport data packets (see Patel ¶ ¶ [0055-0057] “ . .. The data plane 302 of the packet radio portion 304 may include such components as: [0056] gNodeB 106 or other hardware component that communicates directly with the UE 102 by way of an antenna and which encapsulates packets from the UE 102 into GTP packets and may also implement user plane control protocols. [0057] The translation module 208 for converting packets back and forth between GTP and SRv6 when traversing between the packet radio portion 304 and the IP portion 306. . . .”) ; and
send the one or more third encapsulated IP transport data packets to a user plane function (UPF) device (see Patel ¶ [0058] “ . . . The control plane 300 of the IP portion 306 may include such components as: [0059] A packet forwarding control protocol (PFCP) proxy 322 described in greater detail below. [0060] A border gateway protocol (BGP) module 324 or other component for receiving and/or transmitting routing paths to other components shown in FIG. 3 and/or other devices of any of the networks described herein. [0061] The user plane function control module (UPF N4) 326 or other component for terminating GTP connections and managing transmission of packets between a packet radio network and an internet protocol network. UPF N4 326 facilitates setting up sessions with the UPF 112. . . .”).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate systems and methods for routing packets to and from a 5G cellular data communication network and using the encapsulating of IP packets for redirecting traffic within the cellular network for delivery to/from the user device, as taught by Patel, into systems and methods for providing flexible selection of network paths in a multi-connection (access) communication environment, for example a wireline connection for transport in a cellular network, and encapsulation with IP over a 5G cellular network, using the DOCSIS protocol, as taught by the combination of Zhu, Gant, and Garrett. Such incorporation provides a process to encapsulate and decapsulate IP transport traffic for delivery to devices that require a wired connection.
In regard to claim 11, the combination of Zhu, Gant, Garrett and Patel teaches wherein the one or more processors, to send the one or more third encapsulated IP transport data packets (see Patel ¶ [0083] “ . . . For responses received from the external network 214 or external MEC 118 and directed to the UE 102, the routing module 216 may encapsulate the response packet (an IP packet, such as IPv4 or IPv6) into SRv6 packets. At this time, the routing module 216 may use the special service SID which was provided by BGP 324. This SID contains the required GTP information that can be included in the SRH′ header. Hence, the translation module 208 can translates SRv6 packets to GTP packets and send the resulting GTP packets to the gNodeB 106. . . “) , are to send the one or more third encapsulated IP transport data packets in accordance with quality of service (QoS) information included in a header of the one or more first encapsulated IP transport data packets (see Zhu ¶¶ [0119-0121] as described for the rejection of claim 5 and is incorporated herein).
The motivation to combine Patel with the combination of Zhu, Gant and Garrett is described for the rejection of claim 10 and is incorporated herein. Additionally, Patel teaches the user device receiving an encapsulated packet including SRH header.
In regard to claim 12, the combination of Zhu, Gant, Garrett and Patel teaches wherein the one or more processors are further to:
receive, from a user plane function (UPF) device (see Patel ¶¶ [0044-0045] “ . . . , user plane message are those used to establish and maintain a session between the UPF 112 and the UE 102. User plane messages may also include those transmitted by the UPF 112 to dictate routing of packets to and from the UE 102 and the MEC server 116 or redirection of packets to an external network 214. User plane messages may also convey 5G user plane message like echo request, echo reply, error indication, or other user plane messages. Inbound user plane messages may be routed as direct inbound packets. User plane messages transmitted from the UPF 112 may be treated as direct outbound packets in every instance. Where redirection occurs as instructed by the UPF 112, subsequent inbound data packets, i.e. non-user plane messages packets, may be routed by the translation module 208 as redirected inbound packets in bypass of the UPF 112. The translation module 208 may identify user plane messages by performing deep packet inspection of the inbound packets. , one or more third encapsulated IP transport data packets (see Patel ¶ [0043] “ . . . The translation module 208 converts the B-type redirected outbound packets to A-type packets and transmits the A-type redirected outbound packets to the gNodeB 106. Translation from a B-type to A-type may include using information stored in the SRH′ of the B-type packets. This may include converting an SRv6 packet into a GTP packet encapsulating the inner IP header and payload data of the B-type packet and including the data from the SRH′ field in the GTP header. ;
decapsulate the one or more third encapsulated IP transport data packets (see Patel ¶ [0043] “ . . . The gNodeB 106 may then decapsulate a D-type redirected outbound packet (inner IP header and payload data) from the B-type redirected outbound packet and transmit the D-type redirected outbound packet to the UE 102. ; and
generate, based on the decapsulated one or more third encapsulated IP transport data packets, the one or more second encapsulated IP transport data packets (see Patel ¶¶ [0055-0057] “ . . .. The data plane 302 of the packet radio portion 304 may include such components as: gNodeB 106 or other hardware component that communicates directly with the UE 102 by way of an antenna and which encapsulates packets from the UE 102 into GTP packets and may also implement user plane control protocols. The translation module 208 for converting packets back and forth between GTP and SRv6 when traversing between the packet radio portion 304 and the IP portion 306. . “).
The motivation to combine Patel with the combination of Zhu, Gant and Garrett is described for the rejection of claim 10 and is incorporated herein. Additionally, Patel teaches the user device transferring an encapsulated packet including SRH header.
In regard to claim 13, the combination of Zhu, Gant, Garrett, and Patel teaches wherein the one or more processors, to send the one or more second encapsulated IP transport data packets, (see Patel ¶ [0083] “ . . . For responses received from the external network 214 or external MEC 118 and directed to the UE 102, the routing module 216 may encapsulate the response packet (an IP packet, such as IPv4 or IPv6) into SRv6 packets. At this time, the routing module 216 may use the special service SID which was provided by BGP 324. This SID contains the required GTP information that can be included in the SRH′ header. Hence, the translation module 208 can translates SRv6 packets to GTP packets and send the resulting GTP packets to the gNodeB 106. . . “) are to send the one or more second encapsulated IP transport data packets in accordance with quality of service (QoS) information included in a header of the one or more third encapsulated IP transport data packets(see Zhu ¶¶ [0119-0121] as described for the rejection of claim 5 and is incorporated herein).
The motivation to combine Patel with the combination of Zhu, Gant, Garrett, and Patel is described for the rejection of claim 10 and is incorporated herein. Additionally, Patel teaches the user device for receiving and transferring an encapsulated packet including SRH header, including decapsulation of the IP packets..
In regard to claim 19, the combination of Zhu Gant, Garrett, and Patel teaches wherein the one or more instructions, that cause the AGF device to send the one or more second encapsulated IP transport data packets(see Patel ¶ [0058] “ . . . The control plane 300 of the IP portion 306 may include such components as: [0059] A packet forwarding control protocol (PFCP) proxy 322 described in greater detail below. [0060] A border gateway protocol (BGP) module 324 or other component for receiving and/or transmitting routing paths to other components shown in FIG. 3 and/or other devices of any of the networks described herein. [0061] The user plane function control module (UPF N4) 326 or other component for terminating GTP connections and managing transmission of packets between a packet radio network and an internet protocol network. UPF N4 326 facilitates setting up sessions with the UPF 112. . . .”). , cause the AGF device to:
decapsulate the one or more first encapsulated IP transport data packets(see Patel ¶ [0043] “ . . . The gNodeB 106 may then decapsulate a D-type redirected outbound packet (inner IP header and payload data) from the B-type redirected outbound packet and transmit the D-type redirected outbound packet to the UE 102. . . .”); and
generate, based on the decapsulated one or more first encapsulated IP transport data packets, the one or more second encapsulated IP transport data packets (see Patel ¶ ¶ [0055-0057] “ . .. The data plane 302 of the packet radio portion 304 may include such components as: [0056] gNodeB 106 or other hardware component that communicates directly with the UE 102 by way of an antenna and which encapsulates packets from the UE 102 into GTP packets and may also implement user plane control protocols. [0057] The translation module 208 for converting packets back and forth between GTP and SRv6 when traversing between the packet radio portion 304 and the IP portion 306. . . .”)
The motivation to combine Patel with the combination of Zhu, Gant, and Garrett is described for the rejection of claim 10 and is incorporated herein. Additionally, Patel teaches decapsulation of the IP packet by the access device.
Conclusion
There are prior art made of record which are not relied upon but are considered pertinent to applicant’s disclosure. They are listed on the PTO-892 accompanying this action
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES N FIORILLO whose telephone number is (571)272-9909. The examiner can normally be reached on 7:30 - 5 PM Mon - Fri..
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John A. Follansbee can be reached on 571-272-3964. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JAMES N FIORILLO/Primary Examiner, Art Unit 2444
Prosecution Insights