DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, anycorrection of the statutory basis for the rejection will not be considered a new ground ofrejection if the prior art relied upon, and the rationale supporting the rejection, would bethe same under either status.
Response to Amendment
The proposed reply filed on June 22nd, 2026 has been entered. Claims 1, 3-4, 6, 14, and 17 have been amended. Claims 2, 5 and 16 have been canceled. Claims 1, 3-4, 6-15 and 17-20 are pending in the application.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claim(s) 1, 3-4, 9-15 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shi et al. (US 12, 231, 885 B2) in view of Dao et al. (US 10,736,155 B2) and Sharma et al. (US 2020/0374205 A1).
Regarding claim 1, Shi et al. teach a session establishment method for an Internet of Things device (Figs. 1 and 6, [col 4 ln 20-38], communications system 100 may include wireless transmit/receive units (WTRUs) 102 a, 102 b, 102 c, 102 d, a RAN 104/113, a CN 106/115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102 a, 102 b, 102 c, 102 d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102 a, 102 b, 102 c, 102 d, any of which may be referred to as a “station” and/or a “STA”, may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device),
Shi et al. teach comprising: obtaining, by a terminal (Figs. 1 and 6, [col 21 in 9-11], a PDU session establishment between a remote WTRU and a core network via a ProSe WTRU-to-network relay. (Note: the remote WTRU, for establishing the PDU session, will exchange data via the ProSe WTRU-to-network relay. Wherein the remote WTRU is the Internet of Things (IoT) device)),
Shi et al. teach an Internet of Things device group policy, wherein the Internet of Things device group policy indicates the terminal to establish a session channel on a per Internet of Things device group basis (Fig. 6, [col 21 ln 52-43], the WTRU-to-network relay may send a routing policy request message to the core network (e.g., to the AMF of the core network). The routing policy request message may include one or more ID associated with one or more of remote WTRUs. At 606, the WTRU-to-network relay may receive a routing policy response message from the core network (e.g., from the AMF of the core network). The routing policy response message received by the WTRU-to-network relay may include one or more PDU session parameters for the remote WTRUs. (Note: the response message for routing policy, received by the WTRU-to-network relay, is the IoT device group policy because it is for set of remote WTRUs, rather than individual unit),
Shi et al. teach and establishing, by the terminal according to the Internet of Things device group policy, a target session channel for a target Internet of Things device going to access the terminal (Fig. 6, [col 21 ln 53-63], at 608, the WTRU-to-network relay may send a PDU session establishment request message, for example, if no existing PDU session is found for this remote WTRU. The PDU session establishment request message may include PDU session parameters associated with the remote WTRU. At 609, the WTRU-to-network relay may receive a PDU session establishment response message from the core network (e.g., from the SMF of the core network). At 610, the remote WTRU may obtain an IP address/prefix and the WTRU-to-network relay may start relaying traffic between the remote WTRU and the core network).
Shi et al. teach wherein the Internet of Things device group policy is used to describe at least one of the following information: that the terminal establishes one session channel for all Internet of Things devices going to access the terminal; or that the terminal establishes one session channel for Internet of Things devices of a same type going to access the terminal (Figs. 1 and 6, [col 20 ln 32-40], a first remote WTRU may be associated with PDU session parameters for a S-NSSAI and a second remote WTRU may have the same PDU session parameters. The traffic of both the WTRUs may be associated with the same PDU session. The WTRU-to-network relay may modify the PDU session based on the QoS requirements received from the remote WTRU, for example, if the WTRU-to-network relay uses the same PDU session for both the WTRUs. Further, Different dedicated PDU sessions may be established by the WTRU-to-network relay for the same remote WTRU that may use different application/service types with different PDU Session requirements (e.g., S-NSSAI, DNN)).
Shi et al. teach wherein the type comprises at least one of the following: a type of Internet of Things service or a type of Internet of Things device (Fig. 1A, [Col 4 ln 27-38], Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and/or a “STA”, may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device).
Regarding claim 3, Shi et al. teach wherein the establishing, by the terminal according to the Internet of Things device group policy, a target session channel for a target Internet of Things device going to access the terminal comprises: obtaining, by the terminal, a target type of the target Internet of Things device; and establishing a target session channel for the target Internet of Things device according to the Internet of Things device group policy (Fig. 6, [col 21 ln 25-32], at 603, the remote WTRU may execute its discovery procedure to discover a WTRU-to-network relay. At 604, the remote WTRU and the discovered WTRU-to-network relay may establish a PC5 connection. If no PDU session parameters associated with the remote WTRU are known to the WTRU-to-network relay (e.g., if the WTRU-to-network relay did not request PDU session parameters during its registration with the core network), at 605, the WTRU-to-network relay may send a routing policy request message to the core network (e.g., to the AMF of the core network).
Regarding claim 4, Shi et al. teach wherein the establishing, according to the Internet of Things device group policy, a target session channel corresponding to the target type for the target Internet of Things device comprises: establishing a target session channel for the target Internet of Things device in a case that no target session channel corresponding to the target type has been established (Fig. 6, [col 21 ln 53-60], At 608, the WTRU-to-network relay may send a PDU session establishment request message, for example, if no existing PDU session is found for this remote WTRU. The PDU session establishment request message may include PDU session parameters associated with the remote WTRU. At 609, the WTRU-to-network relay may receive a PDU session establishment response message from the core network, from the session management function (SMF) of the core network. (Note: in other words if no PDU session channel is available, the target session channel is established based on PDU session parameters, included in the PDU session establishment request, associated with the remote WTRU)).
Regarding claim 9, Shi et al. teach wherein the obtaining, by a terminal, an Internet of Things device group policy comprises: obtaining, by the terminal, the Internet of Things device group policy from a network-side device (Fig. 6, [col 21 ln 52-43], the WTRU-to-network relay may send a routing policy request message to the core network (e.g., to the AMF of the core network). The routing policy request message may include one or more ID associated with one or more of remote WTRUs. At 606, the WTRU-to-network relay may receive a routing policy response message from the core network (e.g., from the AMF of the core network). The routing policy response message received by the WTRU-to-network relay may include one or more PDU session parameters for the remote WTRUs. (Note: Mobility Management Function (AMF) is one of the elements of the core network. The AMF. Network-side device, sends the Internet of Things device group policy).
Regarding claim 10, Shi et al. teach wherein before the obtaining, by the terminal, the Internet of Things device group policy from a network-side device, the method further comprises: sending, by the terminal, Internet of Things device access capability information to the network-side device, wherein the Internet of Things device access capability information is used to indicate that the terminal is capable of accessing an Internet of Things device to a communication network (Fig. 7, [col 24 ln 50-58], relay access WTRU may detect a broadcast message over PC5 from the relay. The broadcast message may include a WTRU-to-network relay capability indication, one or more service type(s) supported by the relay, the WTRU-to-network relay allowed CAG IDs, the supported CAG IDs (e.g. from the cell the relay is currently connected to or camping on), the WTRU-to-network relay CAG only indication (e.g. specifying whether the relay is allowed to access the network via CAG cells)).
Regarding claim 11, Shi et al. teach wherein the Internet of Things device access capability information comprises at least one of the following: a type of Internet of Things device supported by the terminal; an identifier of a third party to which the terminal belongs; an identifier of the terminal; or an Internet of Things device data transmission mode supported by the terminal (Fig. 7, [col 2 ln 60-67, col 24 ln 50-58], remote WTRU may perform discovery and selection of a WTRU-to-network relay based on relay broadcast of service type associated with control access group (CAG) IDs, for example during provisioning (e.g., implicit CAG based selection) or based on relay broadcast of CAG information including one or more of the following: current CAG cell supported CAG IDs, relay allowed CAG IDs, or CAG only indication (e.g., explicit CAG based selection). The supported CAG IDs (e.g. from the cell the relay is currently connected to or camping on), the WTRU-to-network relay CAG only indication).
Regarding claim 12, Shi et al. teach wherein the Internet of Things device data transmission mode comprises at least one of the following: uplink data transmission of the Internet of Things device; downlink data transmission of the Internet of Things device; data transmission of the Internet of Things device; the terminal acting as a relay for uplink data of the Internet of Things device; the terminal acting as a relay for downlink data of the Internet of Things device; the terminal acting as a relay for data transmission of the Internet of Things device; transmitting Internet of Things device data in a per group manner; or the terminal acting as a relay for transmitting the Internet of Things device data in a per group manner Figs. 1 and 6, [col 4 ln 20-38, col 21 ln 9-15], the WTRUs 102 a, 102 b, 102 c, 102 d, any of which may be referred to as a “station” and/or a “STA”, may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device). Fig. 6 illustrates an example of a PDU session establishment between a remote WTRU and a core network via a ProSe WTRU-to-network relay. At 601, the WTRU-to-network relay sends a registration request message to a core network node (e.g., comprising an AMF). The registration request message may include a WTRU-to-network relay indication).
Regarding claim 13, Shi et al. teach wherein the network-side device comprises an access and mobility management function (AMF) and/or a session management function (SMF) (Fig. 1D, [col 12 ln 48-55], core network (CN) 115 may include at least one AMF 182a, 182b, at least one UPF 184a,184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b).
Shi et al. is teaching of establishing a target session channel for a target IoT device. Shi et al., however, fail to expressly disclose obtaining an IoT device group policy indicating to establish a session channel, and type of IOT service or device. (Emphasis added).
Regarding claim 1, Dao et al. teach obtaining, by a terminal an Internet of Things device group policy, wherein the Internet of Things device group policy indicates the terminal to establish a session channel on a per Internet of Things device group basis (Figs. 11-12, [col 19 ln 31-32, col 21 ln 52-56, col 22 ln 28-41], the UEs 1252 may be cellular IoT (CIoT) devices. The establishment of a shared PDU session corresponding to UEs 1252 of a given UE group may be initiated by the NMF 1100 sending 1110 UE group policies corresponding to the UE group to the PCF 100 and receiving a response thereto. The AMF 90 requests 1125 the selected PCF 100 to provide the UE group policies corresponding to the UE group ID specified in the request and receives the UE group policy information therefrom. From the UE group policy information, the AMF 92 may create policies to be applied to all UEs 1252 of the UE group and/or policies to be applied to individual UEs 1252. By way of non-limiting example, the UE group policies may include access and mobility, which may include an allowed area in which the UEs 1252 of a UE group can send and receive data. The individual UE policies to be sent to UEs 1252 may include, by way of non-limiting example, a UE route selection policy (URSP)).
It would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Shi et al. by incorporating the features as taught by Dao et al. in order to provide a more effective and efficient system that is capable of obtaining, by a terminal an Internet of Things device group policy, wherein the Internet of Things device group policy indicates the terminal to establish a session channel on a per Internet of Things device group basis. The motivation is to support an improved method to be used as hubs and cradles in mesh networks and for packet data unit (PDU) session management (see [col 1 ln 15-16]).
Shi et al. and Dao et al. are teaching of establishing a target session channel for a target IoT device. Shi et al., however, fail to expressly disclose type of IOT service or device. (Emphasis added).
Regarding claim 1, Sharma et al. teach wherein the type comprises at least one of the following: a type of Internet of Things service or a type of Internet of Things device (Figs. 5 and 8, [0150], parameters, policies, rules, etc. that may be used by one or more cradles 500 to control and/or monitor various IoT devices 504, as well as share data generated by the IoT devices 504. The description may indicate relevant information to be implemented by one or more cradles 500 and/or integrated into one or more IoT devices 504. For example, the description may indicate information to be implemented in or by specific types of IoT devices 504, implemented in or by cradles 500 or IoT devices 504 deployed at specific locations, and/or the like).
It would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Shi et al. with Dao et al. by incorporating the features as taught by Sharma et al. in order to provide a more effective and efficient system that is capable of comprising a type of Internet of Things device. The motivation is to support an improved method to be used as hubs and cradles in mesh networks and for computing systems while providing IoT device interoperability capabilities (see [0001]).
Regarding claim 14, Shi et al. teach a session establishment method for an Internet of Things device, comprising (Figs. 1 and 6, [col 4 ln 20-38], communications system 100 may include wireless transmit/receive units (WTRUs) 102 a, 102 b, 102 c, 102 d, a RAN 104/113, a CN 106/115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102 a, 102 b, 102 c, 102 d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102 a, 102 b, 102 c, 102 d, any of which may be referred to as a “station” and/or a “STA”, may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device),
Shi et al. teach obtaining, by a first network-side device, a first Internet of Things device group policy (Fig. 6, [col 21 ln 38-43], at 606, the WTRU-to-network relay may receive a routing policy response message from the core network (e.g., from the AMF of the core network). The routing policy response message received by the WTRU-to-network relay may include one or more PDU session parameters for the remote WTRUs),
Shi et al. teach wherein the first Internet of Things device group policy indicates that a session channel is established on a per Internet of Things device group basis (Fig. 6, [col 21 ln 52-43], the WTRU-to-network relay may send a routing policy request message to the core network (e.g., to the AMF of the core network). The routing policy request message may include one or more ID associated with one or more of remote WTRUs. At 606, the WTRU-to-network relay may receive a routing policy response message from the core network (e.g., from the AMF of the core network). The routing policy response message received by the WTRU-to-network relay may include one or more PDU session parameters for the remote WTRUs. (Note: the response message for routing policy, received by the WTRU-to-network relay, is the IoT device group policy because it is for set of remote WTRUs, rather than individual unit),
Shi et al. teach receiving, by a second network-side device from a first network-side device, a request for obtaining an Internet of Things device group policy (Fig. 6, [col 21 in 32-37], at 605, the WTRU-to-network relay (i.e. first network-side device) may send a routing policy request message to the core network (e.g., to the AMF of the core network) (i.e. the second network-side device). The routing policy request message may include one or more ID associated with one or more of remote WTRUs. The request may include a ProSe service type/service id),
Shi et al. teach wherein the terminal has an Internet of Things device access capability (Fig. 7, [col 2 ln 60-67, col 24 ln 50-58], remote WTRU may perform discovery and selection of a WTRU-to-network relay based on relay broadcast of service type associated with control access group (CAG) IDs, for example during provisioning (e.g., implicit CAG based selection) or based on relay broadcast of CAG information including one or more of the following: current CAG cell supported CAG IDs, relay allowed CAG IDs, or CAG only indication (e.g., explicit CAG based selection). The supported CAG IDs (e.g. from the cell the relay is currently connected to or camping on), the WTRU-to-network relay CAG only indication),
Shi et al. teach and the second Internet of Things device group policy indicates the terminal to establish a target session channel for a target Internet of Things device going to access the terminal, on a per Internet of Things device group basis (Fig. 6, [col 21 ln 53-63], at 608, the WTRU-to-network relay may send a PDU session establishment request message, for example, if no existing PDU session is found for this remote WTRU. The PDU session establishment request message may include PDU session parameters associated with the remote WTRU. At 609, the WTRU-to-network relay may receive a PDU session establishment response message from the core network (e.g., from the SMF of the core network). At 610, the remote WTRU may obtain an IP address/prefix and the WTRU-to-network relay may start relaying traffic between the remote WTRU and the core network).
Shi et al. teach wherein the Internet of Things device group policy is used to describe at least one of the following information: that the terminal establishes one session channel for all Internet of Things devices going to access the terminal; or that the terminal establishes one session channel for Internet of Things devices of a same type going to access the terminal (Figs. 1 and 6, [col 20 ln 32-40], a first remote WTRU may be associated with PDU session parameters for a S-NSSAI and a second remote WTRU may have the same PDU session parameters. The traffic of both the WTRUs may be associated with the same PDU session. The WTRU-to-network relay may modify the PDU session based on the QoS requirements received from the remote WTRU, for example, if the WTRU-to-network relay uses the same PDU session for both the WTRUs. Further, Different dedicated PDU sessions may be established by the WTRU-to-network relay for the same remote WTRU that may use different application/service types with different PDU Session requirements (e.g., S-NSSAI, DNN)).
Shi et al. teach wherein the type comprises at least one of the following: a type of Internet of Things service or a type of Internet of Things device (Fig. 1A, [Col 4 ln 27-38], Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and/or a “STA”, may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device).
Regarding claim 15, Shi et al. teach wherein before the obtaining, by a first network-side device, a first Internet of Things device group policy, the method further comprises: obtaining, by the first network-side device, Internet of Things device access capability information of the terminal, wherein the Internet of Things device access capability information is used to indicate that the Internet of Things device is capable of being accessed to the terminal (Fig. 7, [col 24 ln 50-58], relay access WTRU may detect a broadcast message over PC5 from the relay. The broadcast message may include a WTRU-to-network relay capability indication, one or more service type(s) supported by the relay, the WTRU-to-network relay allowed CAG IDs, the supported CAG IDs (e.g. from the cell the relay is currently connected to or camping on), the WTRU-to-network relay CAG only indication (e.g. specifying whether the relay is allowed to access the network via CAG cells)).
Shi et al. is teaching of establishing a target session channel for a target IoT device. Shi et al., however, fail to expressly disclose obtaining an IoT device group policy indicating to establish a session channel, and type of IOT service or device. (Emphasis added).
Regarding claim 14, Dao et al. teach obtaining, by a first network-side device, a first Internet of Things device group policy, wherein the first Internet of Things device group policy indicates that a session channel is established on a per Internet of Things device group basis (Figs. 11-12, [col 19 ln 31-32, col 21 ln 52-56, col 22 ln 28-41], the UEs 1252 may be cellular IoT (CIoT) devices. The establishment of a shared PDU session corresponding to UEs 1252 of a given UE group may be initiated by the NMF 1100 sending 1110 UE group policies corresponding to the UE group to the PCF 100 and receiving a response thereto. The AMF 90 requests 1125 the selected PCF 100 to provide the UE group policies corresponding to the UE group ID specified in the request and receives the UE group policy information therefrom. From the UE group policy information, the AMF 92 may create policies to be applied to all UEs 1252 of the UE group and/or policies to be applied to individual UEs 1252. By way of non-limiting example, the UE group policies may include access and mobility, which may include an allowed area in which the UEs 1252 of a UE group can send and receive data. The individual UE policies to be sent to UEs 1252 may include, by way of non-limiting example, a UE route selection policy (URSP)).
It would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Shi et al. by incorporating the features as taught by Dao et al. in order to provide a more effective and efficient system that is capable of obtaining, by a first network-side device, a first Internet of Things device group policy, wherein the first Internet of Things device group policy indicates that a session channel is established on a per Internet of Things device group basis. The motivation is to support an improved method to be used as hubs and cradles in mesh networks and for packet data unit (PDU) session management (see [col 1 ln 15-16]).
Shi et al. and Dao et al. are teaching of establishing a target session channel for a target IoT device. Shi et al., however, fail to expressly disclose type of IOT service or device. (Emphasis added).
Regarding claim 14, Sharma et al. teach wherein the type comprises at least one of the following: a type of Internet of Things service or a type of Internet of Things device (Figs. 5 and 8, [0150], parameters, policies, rules, etc. that may be used by one or more cradles 500 to control and/or monitor various IoT devices 504, as well as share data generated by the IoT devices 504. The description may indicate relevant information to be implemented by one or more cradles 500 and/or integrated into one or more IoT devices 504. For example, the description may indicate information to be implemented in or by specific types of IoT devices 504, implemented in or by cradles 500 or IoT devices 504 deployed at specific locations, and/or the like).
It would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Shi et al. with Dao et al. by incorporating the features as taught by Sharma et al. in order to provide a more effective and efficient system that is capable of comprising a type of Internet of Things device. The motivation is to support an improved method to be used as hubs and cradles in mesh networks and for computing systems while providing IoT device interoperability capabilities (see [0001]).
Regarding claim 17, Shi et al. teach a session establishment method for an Internet of Things device comprising (Figs. 1 and 6, [col 4 ln 20-38], communications system 100 may include wireless transmit/receive units (WTRUs) 102 a, 102 b, 102 c, 102 d, a RAN 104/113, a CN 106/115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102 a, 102 b, 102 c, 102 d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102 a, 102 b, 102 c, 102 d, any of which may be referred to as a “station” and/or a “STA”, may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device),
Shi et al. teach receiving, by a second network-side device from a first network-side device, a request for obtaining an Internet of Things device group policy (Fig. 6, [col 21 in 32-37], at 605, the WTRU-to-network relay (i.e. first network-side device) may send a routing policy request message to the core network (e.g., to the AMF of the core network) (i.e. the second network-side device). The routing policy request message may include one or more ID associated with one or more of remote WTRUs. The request may include a ProSe service type/service id),
Shi et al. teach and sending, by the second network-side device, a first Internet of Things device group policy to the first network-side device (Fig. 6, [col 21 ln 38-43], at 606, the WTRU-to-network relay may receive a routing policy response message from the core network (e.g., from the AMF of the core network). The routing policy response message received by the WTRU-to-network relay may include one or more PDU session parameters for the remote WTRUs),
Shi et al. teach wherein the first Internet of Things device group policy indicates that a session channel is established on a per Internet of Things device group basis (Fig. 6, [col 21 ln 52-43], the WTRU-to-network relay may send a routing policy request message to the core network (e.g., to the AMF of the core network). The routing policy request message may include one or more ID associated with one or more of remote WTRUs. At 606, the WTRU-to-network relay may receive a routing policy response message from the core network (e.g., from the AMF of the core network). The routing policy response message received by the WTRU-to-network relay may include one or more PDU session parameters for the remote WTRUs. (Note: the response message for routing policy, received by the WTRU-to-network relay, is the IoT device group policy because it is for set of remote WTRUs, rather than individual unit),
Shi et al. teach wherein the Internet of Things device group policy is used to describe at least one of the following information: that the terminal establishes one session channel for all Internet of Things devices going to access the terminal; or that the terminal establishes one session channel for Internet of Things devices of a same type going to access the terminal (Figs. 1 and 6, [col 20 ln 32-40], a first remote WTRU may be associated with PDU session parameters for a S-NSSAI and a second remote WTRU may have the same PDU session parameters. The traffic of both the WTRUs may be associated with the same PDU session. The WTRU-to-network relay may modify the PDU session based on the QoS requirements received from the remote WTRU, for example, if the WTRU-to-network relay uses the same PDU session for both the WTRUs. Further, Different dedicated PDU sessions may be established by the WTRU-to-network relay for the same remote WTRU that may use different application/service types with different PDU Session requirements (e.g., S-NSSAI, DNN)).
Shi et al. teach wherein the type comprises at least one of the following: a type of Internet of Things service or a type of Internet of Things device (Fig. 1A, [Col 4 ln 27-38], Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and/or a “STA”, may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device)).
Shi et al. is teaching of establishing a target session channel for a target IoT device. Shi et al., however, fail to expressly disclose obtaining an IoT device group policy indicating to establish a session channel, and type of IOT service or device. (Emphasis added).
Regarding claim 17, Dao et al. teach receiving, by a second network-side device from a first network-side device, a request for obtaining an Internet of Things device group policy (Figs. 11-12, [col 19 ln 31-32, col 21 ln 52-56, col 22 ln 28-41], the UEs 1252 may be cellular IoT (CIoT) devices. The establishment of a shared PDU session corresponding to UEs 1252 of a given UE group may be initiated by the NMF 1100 sending 1110 UE group policies corresponding to the UE group to the PCF 100 and receiving a response thereto. The AMF 90 requests 1125 the selected PCF 100 to provide the UE group policies corresponding to the UE group ID specified in the request and receives the UE group policy information therefrom. From the UE group policy information, the AMF 92 may create policies to be applied to all UEs 1252 of the UE group and/or policies to be applied to individual UEs 1252. By way of non-limiting example, the UE group policies may include access and mobility, which may include an allowed area in which the UEs 1252 of a UE group can send and receive data. The individual UE policies to be sent to UEs 1252 may include, by way of non-limiting example, a UE route selection policy (URSP)).
It would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Shi et al. by incorporating the features as taught by Dao et al. in order to provide a more effective and efficient system that is capable of obtaining, by a first network-side device, a first Internet of Things device group policy, wherein the first Internet of Things device group policy indicates that a session channel is established on a per Internet of Things device group basis. The motivation is to support an improved method to be used as hubs and cradles in mesh networks and for packet data unit (PDU) session management (see [col 1 ln 15-16]).
Shi et al. and Dao et al. are teaching of establishing a target session channel for a target IoT device. Shi et al., however, fail to expressly disclose type of IOT service or device. (Emphasis added).
Regarding claim 17, Sharma et al. teach wherein the type comprises at least one of the following: a type of Internet of Things service or a type of Internet of Things device (Figs. 5 and 8, [0150], parameters, policies, rules, etc. that may be used by one or more cradles 500 to control and/or monitor various IoT devices 504, as well as share data generated by the IoT devices 504. The description may indicate relevant information to be implemented by one or more cradles 500 and/or integrated into one or more IoT devices 504. For example, the description may indicate information to be implemented in or by specific types of IoT devices 504, implemented in or by cradles 500 or IoT devices 504 deployed at specific locations, and/or the like).
It would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Shi et al. with Dao et al. by incorporating the features as taught by Sharma et al. in order to provide a more effective and efficient system that is capable of comprising a type of Internet of Things device. The motivation is to support an improved method to be used as hubs and cradles in mesh networks and for computing systems while providing IoT device interoperability capabilities (see [0001]).
Claim(s) 6-7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shi et al. (US 12, 231, 885 B2) in view of Dao et al. (US 10,736,155 B2) and Sharma et al. (US 2020/0374205 A1) as applied to claim 1 above, and further in view of Sharma et al. (US 2020/0374205 A1).
Shi et al., Dao et al. and Sharma et al. teach the claimed limitations as described in paragraph 5 above.
Regarding claim 7, Shi et al. teach wherein the Internet of Things device group policy further comprises an establishment parameter for the target session channel (Fig. 1D, [col 13 ln 11-21], the SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like).
Shi et al., Dao et al. and Sharma et al. do expressly disclose the following features: regarding claim 6, wherein the type of the Internet of Things service comprises at least one of the following: environmental measurement, tag tracking, or material management; and/or the type of the Internet of Things device comprises at least one of the following: sensor or tag.
Regarding claim 6, Sharma et al. teach wherein the type of the Internet of Things service comprises at least one of the following: environmental measurement, tag tracking, or material management; and/or the type of the Internet of Things device comprises at least one of the following: sensor or tag (Figs. 6 and 8, [0156], the policies 803 may indicate, for individual IoT devices 504, which types of data (e.g., IoT data or HSD, or certain portions of IoT data or HSD) may be shared with various types of IoT devices 504) (e.g., a type of sensor 620 or type of EMC 622) and/or specific IoT devices 504 (e.g., IoT devices 504 deployed at a specified location and the like).
It would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Shi et al. with Dao et al. and Sharma et al. by incorporating the features as taught by Sharma et al. in order to provide a more effective and efficient system that is capable of comprising the type of the Internet of Things device comprises a sensor. The motivation is to support an improved method to be used as hubs and cradles in mesh networks and for computing systems while providing IoT device interoperability capabilities (see [0001]).
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shi et al. (US 12, 231, 885 B2) in view of Dao et al. (US 10,736,155 B2) and Sharma et al. (US 2020/0374205 A1) as applied to claim 1 above, and further in view of Shi et al. (US 2023/0023639 A1) (Shi’639 hereinafter).
Shi et al., Dao et al. and Sharma et al. teach the claimed limitations as described in paragraph 5 above. Shi et al., Dao et al. and Sharma et al. do not expressly disclose the following features: regarding claim 8, wherein the establishment parameter for the target session channel comprises at least one of the following: first indication information, wherein the first indication information is used to indicate that the target session channel is of IP type; second indication information, wherein the second indication information is used to indicate that the target session channel is of Ethernet type; third indication information, wherein the third indication information is used to indicate a service continuity mode of the target session channel; fourth indication information, wherein the fourth indication information is used to indicate that the target session channel is a control plane channel; or fifth indication information, wherein the fifth indication information is used to indicate that the target session channel is a user plane channel.
Regarding claim 8, Shi’639 teaches wherein the establishment parameter for the target session channel comprises at least one of the following: first indication information, wherein the first indication information is used to indicate that the target session channel is of IP type; second indication information, wherein the second indication information is used to indicate that the target session channel is of Ethernet type; third indication information, wherein the third indication information is used to indicate a service continuity mode of the target session channel; fourth indication information, wherein the fourth indication information is used to indicate that the target session channel is a control plane channel; or fifth indication information, wherein the fifth indication information is used to indicate that the target session channel is a user plane channel (Fig. 1, [0112], the WTRU-to-network relay may create a dedicated PDU session for a remote WTRU. PDU session parameters (e.g., the route selection policy) may include one or more of following parameters: S-NSSAI, DNN, PDU Session Type, session and service continuity (SSC) mode, etc. In an example, the WTRU-to-network relay may request PDU session parameters from the core network for each of the remote WTRUs associated with the WTRU-to-network relay).
It would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Shi et al. with Dao et al. and Sharma et al. by incorporating the features as taught by Shi’639 in order to provide a more effective and efficient system that is capable of indicating information a service continuity mode of the target session channel in establishment parameter for the target session channel. The motivation is to support an improved method for creating a dedicated PDU session for a remote WTRU. PDU session parameters (see [0112]).
Claim(s) 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shi et al. (US 12, 231, 885 B2) in view of Dao et al. (US 10,736,155 B2) and Sharma et al. (US 2020/0374205 A1) as applied to claim 1 above, and further in view of Liao et al. (US 2019/0387401 A1).
Shi et al., Dao et al. and Sharma et al. teach the claimed limitations as described in paragraph 5 above. Shi et al., Dao et al. and Sharma et al. do not expressly disclose the following features: regarding claim 18, a terminal, comprising a processor and a memory, wherein the memory stores a program or instructions executable on the processor, and when the program or instructions are executed by the processor, the steps of the session establishment method for an Internet of Things device according to claim 1 are implemented; regarding claim 19, network-side device, comprising a processor and a memory, wherein the memory stores a program or instructions executable on the processor, and when the program or instructions are executed by the processor, the steps of the session establishment method for an Internet of Things device according to claim 14 are implemented; regarding claim 20, network-side device, comprising a processor and a memory, wherein the memory stores a program or instructions executable on the processor, and when the program or instructions are executed by the processor, the steps of the session establishment method for an Internet of Things device according to claim 17 are implemented.
Regarding claim 18, Liao et al. teach a terminal, comprising a processor and a memory, wherein the memory stores a program or instructions executable on the processor, and when the program or instructions are executed by the processor, the steps of the session establishment method for an Internet of Things device according to claim 1 are implemented (Figs. 12 and 22, [0214, 0402-0403], user plane data transmission procedure 1230 allows for efficient transmission of data traffic using group-based UP data transmission session when IoT-UEs transition from an IDLE/INACTIVE state to a CONNECTED state, leveraging keys and security contexts established using the group enrollment and security control procedure 1220.
components of a device 2200 in accordance with some embodiments. In some embodiments, the device 2200 may include application circuitry 2202, baseband circuitry 2204, Radio Frequency (RF) circuitry 2206, front-end module (FEM) circuitry 2208, one or more antennas 2210, and power management circuitry (PMC) 2212 coupled together at least as shown. The components of the illustrated device 2200 may be included in a UE or a RAN node. The processors may be coupled with or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the device 2200).
Regarding claim 19, Liao et al. teach network-side device, comprising a processor and a memory, wherein the memory stores a program or instructions executable on the processor, and when the program or instructions are executed by the processor, the steps of the session establishment method for an Internet of Things device according to claim 14 are implemented (Figs. 12 and 22, [0214, 0402-0403], user plane data transmission procedure 1230 allows for efficient transmission of data traffic using group-based UP data transmission session when IoT-UEs transition from an IDLE/INACTIVE state to a CONNECTED state, leveraging keys and security contexts established using the group enrollment and security control procedure 1220.
components of a device 2200 in accordance with some embodiments. In some embodiments, the device 2200 may include application circuitry 2202, baseband circuitry 2204, Radio Frequency (RF) circuitry 2206, front-end module (FEM) circuitry 2208, one or more antennas 2210, and power management circuitry (PMC) 2212 coupled together at least as shown. The components of the illustrated device 2200 may be included in a UE or a RAN node. The processors may be coupled with or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the device 2200).
Regarding claim 20, Liao et al. teach network-side device, comprising a processor and a memory, wherein the memory stores a program or instructions executable on the processor, and when the program or instructions are executed by the processor, the steps of the session establishment method for an Internet of Things device according to claim 17 are implemented (Figs. 12 and 22, [0214, 0402-0403], user plane data transmission procedure 1230 allows for efficient transmission of data traffic using group-based UP data transmission session when IoT-UEs transition from an IDLE/INACTIVE state to a CONNECTED state, leveraging keys and security contexts established using the group enrollment and security control procedure 1220.
components of a device 2200 in accordance with some embodiments. In some embodiments, the device 2200 may include application circuitry 2202, baseband circuitry 2204, Radio Frequency (RF) circuitry 2206, front-end module (FEM) circuitry 2208, one or more antennas 2210, and power management circuitry (PMC) 2212 coupled together at least as shown. The components of the illustrated device 2200 may be included in a UE or a RAN node. The processors may be coupled with or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the device 2200).
It would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Shi et al. with Dao et al. and Sharma et al. by incorporating the features as taught by Liao et al. in order to provide a more effective and efficient system that is capable of executing by the processor, the steps of the session establishment method for an Internet of Things device. The motivation is to support an improved method for efficiently serve massive IoT devices in a group basis without generating overwhelmed signaling overheads (see [0041]).
Response to Arguments
Applicant's arguments filed 06/22/2026 have been fully considered but they are not persuasive. Regarding features (a) of claim 1 reciting “obtaining, by a terminal, an Internet of Things device group policy, wherein the Internet of Things device group policy indicates the terminal to establish a session channel on a per Internet of Things device group basis”, applicant states in remarks that “Dao does not disclose or imply that the UE group policies indicate the establishment of session channels, let alone indicating that a terminal should establish a session channel on a per Internet of Things device group basis”.
Examiner respectfully disagrees. The office action on page 5 describes that “Shi et al. is teaching of establishing a target session channel for a target loT device. Shi et al., however, fail to expressly disclose obtaining an loT device group policy indicating to establish a session channel. (Emphasis added).” To overcome the deficiency, the teachings of Dao are combined with teachings of Shi for rendering obvious rejection. Dao clearly teaches that the UE group policy indicates the establishment of session channels. The prior art describes that the establishing of a shared PDU session, corresponding to UEs of a given UE group, may be initiated by the NMF (Network Management Functions) sending UE group policies corresponding to the UE group to the PCF (Policy Control Function). The UE group policies may include access and mobility, which may include an allowed area in which the UEs of a UE group can send and receive data. The individual UE policies to be sent to UEs may include a UE route selection policy (see col 21 In 52-56, col 22 In 28-41).
The applicant states in the remark “ It can be seen that in the scheme of Dao, it is the AMF that requests the SMF to establish a PDU session. However, in Shi, it is the relay WTRU that requests the SMF to establish a PDU session. The architectures of Shi and Dao are different. Combining Dao to Shi would disrupt Shi's original system architecture and functionality”.
The examiner respectfully disagrees. As explained above that Dao does disclose that the UE group policies indicate the establishment of session channels with the indication that a terminal should establish a session channel on a per Internet of Things device group basis. In both cases, (a) UE Requesting SMF or (b) AMF Requesting SMF, combining the teachings of Dao with Shi is proper. As the 5G network architecture adopts a service-based approach, where network functions are decoupled and organized as modular services. The AMF function is to route information to the SMF. The SMF is a core control-plane component that creates, modifies, and terminates Protocol Data Unit (PDU) sessions for user devices. It assigns IP addresses, selects user-plane data routers, and enforces quality-of-service rules for the UE without handling user data traffic directly.
Regarding features (b), added from claims 2 and 5 to the claim 1 recites “ ( from claim 2), wherein the Internet of Things device group policy is used to describe at least one of the following information: that the terminal establishes one session channel for all Internet of Things devices going to access the terminal; or that the terminal establishes one session channel for Internet of Things devices of a same type going to access the terminal, ( from claim5), wherein the type comprises at least one of the following: a type of Internet of Things service or a type of Internet of Things device”. The applicant states “For the first branch, Shi discloses re-using an existing PDU session instead of establishing a new one if an existing PDU session fulfills the PDU session requirements of the remote WTRU. Shi also discloses that the same PDU session can be associated with traffic of two WTRUs that have the same PDU session parameters for a S-NSSAI. In other words, if an existing PDU session does not fulfill the PDU session requirements of the remote WTRU, or two WTRUs do not have the same PDU session parameters for a S-NSSAI, more than one PDU sessions are required for remote WTRUs in Shi. This is obviously different from a policy such that the terminal establishes one session channel for all Internet of Things devices planning to access the terminal in amended claim 1”.
The examiner respectfully disagrees. In the remarks above, the applicant mentioned “the first branch” which is taken, by the examiner, as referring the features of the claim 2 incorporated into the claim 1. The prior art Shi is teaching the claimed limitations “wherein the Internet of Things device group policy is used to describe at least one of the following information: that the terminal establishes one session channel for all Internet of Things devices going to access the terminal; or that the terminal establishes one session channel for Internet of Things devices of a same type going to access the terminal”. The prior art teaches that one session channel is established for all IoT devices for access. In case if of QoS parameter requirement received from the remote WTRU, the session is modified to keep one session for all (see col 20 line 32-40).
The applicant states in the remarks “for the second branch, Sharma discloses that "the description may indicate information to be implemented in or by specific types of IoT devices 504, implemented in or by cradles 500 or IoT devices 504 deployed at specific locations, and/or the like." (See Para. [0150]) As can be seen, Sharma only mentions the type of IoT device, but does not teach or suggest its relationship with "establishing a session channel".
The examiner respectfully disagrees. In the remarks above, the applicant mentioned “the second branch” which is taken, by the examiner, as referring the features of the claim 5 incorporated into the claim 1. The prior art Sharma is teaching the claimed limitations. Sharma is mentioning the type of IoT devices and teaching their relationship with parameters, policies, rules, type of flow etc. For establishing a flow for protocol data units (PDUs) of the HSD or the IoT data; assign flow parameters to the established flow based on a data type of the flow, wherein the data type indicates whether packets of the flow convey the HSD or the IoT data, and wherein the flow parameters comprise a flow category of the flow, a flow priority of the flow, quality of service (QoS) parameters for the HSD or IoT data (see [150, 216].
The applicant states in the remarks “for at least the reasons discussed above, Shi, Dao, and Sharma fail to disclose, teach, or suggest the features a) and b) of independent claim 1. As such, the rejections under 35 U.S.C. §103 are not supported and independent claim 1 is in condition for allowance”.
The examiner respectfully disagrees. As explained above Shi Dao and Sharma are teaching the above features a) and b) and , therefore, the rejection of the claim 1 is maintained.
The applicant states in the remarks “independent claims 14 and 17 are patentable for similar reasons as independent claim 1”.
The examiner respectfully disagrees. Since the rejection of the claim 1 is maintained the similar claims 14 and 17 will also be remained rejected.
The applicant states in the remarks “likewise, dependent claims 3, 4, 6-13, 15, and 18-20 are patentable over the cited prior art of record at least due to their ultimate dependency on independent claims 1, 14 or 17. Based on the foregoing, it is respectfully submitted that each of the pending claims 3, 4, 6-13, 15, and 18-20 are allowable. Accordingly, it is respectfully requested that the rejections under 35 U.S.C. §103 should be withdrawn”.
The examiner respectfully disagrees. Since the rejections of the independent claims 1, 14 and 17 are maintained, their dependent claims 3, 4, 6-13, 15, and 18-20 will remain rejected. Therefore, the rejections under 35 U.S.C. §103 will not be withdrawn.
Conclusion
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 SYED M BOKHARI whose telephone number is (571)270-3115. The examiner can normally be reached Monday through Friday.
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, Kwang B Yao can be reached at 5712723182. 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.
/SYED M BOKHARI/Examiner, Art Unit 2473 8/18/2026
/KWANG B YAO/Supervisory Patent Examiner, Art Unit 2473
Prosecution Insights