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 .
Response to Arguments
Claim Objections
The previously raised objections to claims 1, 6-8, 11, 16 and 20 have been overcome by Applicant’s amendment and are therefore withdrawn.
Claim Rejections - 35 USC § 101
The previously raised rejections under 35 U.S.C. § 101 to claims 1-15 have been overcome by Applicant’s amendment and are therefore withdrawn.
Claim Rejections - 35 USC § 102 and 103
Applicant's arguments filed on 10/06/2025 have been fully considered but they are not persuasive. Specifically, Applicant argues the following: “the applied references fail to teach or render obvious ‘extract meta information associated with the session using the agent executed on the network element in the core mobile network, wherein the meta information includes subscriber information, equipment information, network slice information, and other meta data, wherein the subscriber information includes one or more of the following: subscriber-ID, International Mobile Subscriber Identity (IMSI), and/or Subscription Permanent Identifier (SUPI), wherein the equipment information includes one or more of the following: equipment-ID, International Mobile Equipment Identity (IMEI), and/or Permanent Equipment Identifier (PEI), wherein the network slice information includes network slice-ID, and wherein the other meta data includes two or more of the following: Radio Access Technology (RAT) Type, Access Point Name (APN), User IP, Data Network Name (DNN), Tracking Area Information (TAI), User Location Information (ULI), user-ID, a syslog message, Mobility Restrictions, Protocol Data Unit (PDU) Session ID, Subscription Concealed Identifier (SUCI), UE (Aggregate Maximum Bit Rate) AMBR, Subscription Permanent Identifier (SUPI), Radio Access Technology (RAT) Type, and/or Globally Unique Temporary Identity (GUTI); and send the extracted meta information to a security platform located outside of the core mobile network, wherein the security platform is configured to: enforce a security policy on the session at the security platform based on the extracted meta information to apply granular security in the core mobile network based on the security policy,’ as recited in claim 1 and similarly recited in claims 16 and 20.” (see Remarks, pages 2, last ¶ and page 3, ¶ 1)
The Examiner respectfully responds: the cited reference Feldmann (US 11,317,292) clearly teaches extract meta information associated with the session using the agent executed on the network element in the core mobile network (see col. 3, lines 62-col. 4, line 1 and Fig. 1: “network 103 may include and/or may be communicatively coupled to one or more location determination facilities comprising devices or systems such as mobility devices or systems, or the like, such as an MME or an AMF. As also noted above, such devices or systems of network 103 may monitor (at 102) a geographical location of UE 101”. And see col. 7, lines 10-19: “Network 103 may continue to monitor (at 212) the location of UE 101, and may provide (at 214) UE location information (e.g., indicating that UE 101 is located within region 100) to GTACS 105.”), wherein the meta information includes subscriber information, equipment information (see col. 9, lines 14-21 and Fig. 5: “GTACS 105 may receive a UE or user identifier associated with UE 101-1 along with location information associated with UE 101-1, based on which GTACS 105 may determine that UE 101-1 is presently located within a geographical region specified by policy 107, and may further determine that UE 101-1 is authorized to access the one or more applications, services, etc., specified in policy 107 when located within geographical region 500.” The Examiner interprets a “user identifier” as wherein the meta information includes subscriber information. The Examiner further interprets a “UE …identifier” as wherein the meta information includes …equipment information), network slice information (see col. 12, line 54-col. 13, line 4: “GTACS 105 may determine that a particular policy 107 is associated with access to a particular “slice” of a 5G network, where a slice corresponds to a “network slice” as implemented according to Third Generation Partnership Project (3GPP) specifications, and includes instances of one or more network functions. … In such situations, GTACS 105 may provide indications to a network element managing network access control and/or slice access control …, which may allow or block UE 101 to connect to a particular slice of the core network.” And see col. 17, line 62-col. 18, line 14: “GTACS 105 may receive and/or maintain one or more policies 107, monitor and/or otherwise receive location information associated with one or more UEs 101, determine (e.g., based on the monitored location) whether criteria associated with one or more policies 107 are met, and selectively grant and/or deny access by UE 101 to certain resources (e.g., applications, services, devices, etc.) based on whether such policies 107 are met. …GTACS 105 may communicate with RAN 910 and/or RAN 912 (e.g., gNB 911, eNB 913, and/or one or more other devices or systems), AMF 915, MME 916, and/or one or more other devices or systems to indicate access parameters associated with one or more UEs 101. As discussed above, UE 101 may be permitted to access (or denied access to) RAN 910, RAN 912, and/or one or more network slices based on the access parameters.” Feldmann inherently teaches extracting network slice information because GTACS 105 cannot determine whether criteria associated with a policy 107 associated with access to a network slice are met without extracted network slice information.), and other meta data (see col. 9, lines 14-21 and Fig. 5: “GTACS 105 may receive a UE or user identifier associated with UE 101-1 along with location information associated with UE 101-1, based on which GTACS 105 may determine that UE 101-1 is presently located within a geographical region specified by policy 107, and may further determine that UE 101-1 is authorized to access the one or more applications, services, etc., specified in policy 107 when located within geographical region 500.” And see col. 8, lines 53-60: “a particular policy 107 may include identifiers of one or more UEs, such as … Internet Protocol (“IP”) addresses, and/or other suitable identifiers.” The Examiner interprets “location information associated with UE 101-1” and “Internet Protocol (“IP”) addresses “as wherein the meta information includes … other meta data. Therefore, the Examiner interprets “a UE or user identifier associated with UE 101-1 along with location information associated with UE 101-1”, network slice information and “Internet Protocol (“IP”) addresses” as meta information.),
wherein the subscriber information includes one or more of the following: subscriber-ID, International Mobile Subscriber Identity (IMSI), and/or Subscription Permanent Identifier (SUPI) (see col. 8, lines 51-58 and Fig. 1: “the same policy 107 may apply to certain UEs or users, or groups of UEs or users. For example, a particular policy 107 may include identifiers of one or more UEs, such as International Mobile Subscriber Identity (“IMSI”) values, International Mobile Station Equipment Identity (“IMEI”) values, Globally Unique Temporary Identifier (“GUTI”) values, Subscription Permanent Identifier (“SUPI”) vales”),
wherein the equipment information includes one or more of the following: equipment-ID, International Mobile Equipment Identity (IMEI), and/or Permanent Equipment Identifier (PEI) (see col. 8, lines 51-58 and Fig. 1: “the same policy 107 may apply to certain UEs or users, or groups of UEs or users. For example, a particular policy 107 may include identifiers of one or more UEs, such as International Mobile Subscriber Identity (“IMSI”) values, International Mobile Station Equipment Identity (“IMEI”) values, Globally Unique Temporary Identifier (“GUTI”) values, Subscription Permanent Identifier (“SUPI”) vales”), and
wherein the other meta data includes two or more of the following: Radio Access Technology (RAT) Type, Access Point Name (APN), User IP (see col. 8, lines 53-60: “a particular policy 107 may include identifiers of one or more UEs, such as … Internet Protocol (“IP”) addresses, and/or other suitable identifiers.”), Data Network Name (DNN), Tracking Area Information (TAI), User Location Information (ULI) (see col. 9, lines 14-21 and Fig. 5: “GTACS 105 may receive a UE or user identifier associated with UE 101-1 along with location information associated with UE 101-1, based on which GTACS 105 may determine that UE 101-1 is presently located within a geographical region specified by policy 107, and may further determine that UE 101-1 is authorized to access the one or more applications, services, etc., specified in policy 107 when located within geographical region 500.”), user-ID, a syslog message, Mobility Restrictions, Protocol Data Unit (PDU) Session ID, Subscription Concealed Identifier (SUCI), UE (Aggregate Maximum Bit Rate) AMBR, Subscription Permanent Identifier (SUPI), Radio Access Technology (RAT) Type, and/or Globally Unique Temporary Identity (GUTI); and
send the extracted meta information to a security platform located outside of the core mobile network (see Col. 4, lines 22-27 and Fig. 1: “GTACS 105 may be communicatively coupled to a Service Capability Exposure Function (“SCEF”), a Network Exposure Function (“NEF”), and/or some other device or system that provides an API or other interface via which GTACS 105 may receive the location information from a location determination facility”. And see col. 7, lines 10-19 and Figs. 1, 2: “Network 103 may continue to monitor (at 212) the location of UE 101, and may provide (at 214) UE location information (e.g., indicating that UE 101 is located within region 100) to GTACS 105”. And see col. 9, lines 14-21 and Fig. 5: “GTACS 105 may receive a UE or user identifier associated with UE 101-1 along with location information associated with UE 101-1”. The Examiner interprets the Geographic- and/or Time-based Access Control System (“GTACS”) 105 located outside of the mobile network 103 as a security platform located outside of the core mobile network.),
wherein the security platform is configured to: enforce a security policy on the session at the security platform based on the extracted meta information to apply granular security (see col. 2, lines 17-32: “one or more other factors may be used in the location-based authentication techniques of some embodiments, such as policies associated with particular UEs or users”. And see col. 4, lines 49-58 and Fig. 1: “GTACS 105 may maintain a set of access policies 107 (referred to herein in plural as “policies 107” or singularly as “policy 107”) that specify location-based restrictions on how UE 101 is able to interact with certain applications, services, devices, networks, etc. For example, a policy 107 may specify that certain applications, services or devices are blocked (e.g. not visible, not discoverable, not launchable, etc.) when UE 101 is outside of region 100, and/or that such applications, services or devices are not blocked when UE 101 is within region 100”. And see col. 9, lines 14-27: “GTACS 105 may receive a UE or user identifier associated with UE 101-1 along with location information associated with UE 101-1, based on which GTACS 105 may determine that UE 101-1 is presently located within a geographical region specified by policy 107, and may further determine that UE 101-1 is authorized to access the one or more applications, services, etc., specified in policy 107 when located within geographical region 500. On the other hand, GTACS 105 may provide indication (at 504) that UE 101-2 has restricted access to such applications, services, etc., based on UE 101-2 not being identified as an authorized UE by policy 107, even though UE 101-2 is reported as located within region 500 specified by policy 107.”) in the core mobile network based on the security policy (see col. 12, line 50-col. 13, line 4: “allowing or restricting access (such as described in the examples above) may include allowing or restricting access to one or more networks, such as one or more RANs, core networks, or portions thereof. For example, GTACS 105 may determine that a particular policy 107 is associated with access to a particular “slice” of a 5G network, where a slice corresponds to a “network slice” as implemented according to Third Generation Partnership Project (3GPP) specifications, and includes instances of one or more network functions. … In such situations, GTACS 105 may provide indications to a network element managing network access control and/or slice access control (e.g., a base station to which UE 101 is communicatively coupled, an AMF, a Session Management Function (“SMF”), a Unified Data Management function (“UDM”), a Network Slice Selection Function (“NSSF”) or some other element), which may allow or block UE 101 to connect to a particular slice of the core network.” Also see col. 18, lines 6-14: “GTACS 105 may communicate with RAN 910 and/or RAN 912 (e.g., gNB 911, eNB 913, and/or one or more other devices or systems), AMF 915, MME 916, and/or one or more other devices or systems to indicate access parameters associated with one or more UEs 101. As discussed above, UE 101 may be permitted to access (or denied access to) RAN 910, RAN 912, and/or one or more network slices based on the access parameters.”).
Feldmann differs from amended claim 1 in that it fails to disclose wherein the network slice information includes network slice-ID.
However, the cited reference Kunz (US 2019/0141081) discloses wherein the network slice information includes network slice-ID (see [0132]- [0134]: “An authentication method for a mobile network system including a security device as part of a network device, the method comprising: storing slice security requirements which are different for each slice ID, the slice ID indicating a network slice in a core network; and selecting, based on the slice security requirements, a security algorithm for the network slice.”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to let the network slice information taught by Feldmann include network slice- ID as taught by Kunz. It would have been obvious because doing so predictably achieves the commonly understood benefit of uniquely identifying a network slice so that the particular policy 107 associated with access to a particular “slice” of a 5G network taught by Feldmann can be evaluated based on the identified network slice.
Claim Objections
Claims 1, 16 and 20 are objected to because of the following informalities: the limitation “Radio Access Technology (RAT) Type” are recited twice as “the other meta data”. Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 9, 12, 14-16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Feldmann (US 11,317,292), and further in view of Kunz (US 2019/0141081).
Regarding claims 1, 16 and 20, Feldmann teaches A system (Geographic- and/or Time-based Access Control System (“GTACS”) 105, see col. 4, lines 17-18 and Fig. 1), comprising:
a processor (processor 1220, see col. 20, line 45 and Fig. 12) configured to:
monitor network traffic in a core mobile network using an agent executed on a network element in the core mobile network (see col. 3, lines 15-34: “The RAN and/or a core network (e.g., an Evolved Packet Core (“EPC”), a 5G Core (“5GC”), and/or some other type of core network) to which the RAN is communicatively coupled may include a network-based location determination facility comprising one or more devices or systems that may monitor or otherwise determine the location of UEs communicatively coupled to the RAN. Such devices or systems may include, for example, a mobility management system (e.g., a Mobility Management Entity (“MME”), an Access and Mobility Management Function (“AMF”), and/or some other device or system that performs operations related to intra-RAN or inter-RAN mobility for one or more UEs), a RAN base station (e.g., an evolved Node B (“eNB”), a Next Generation Node B (“gNB”), or some other type of base station), or some other suitable device or system. The location of the UE may be determined by the network (e.g., by the MME, AMF, base station, other network element, etc.) based on cell triangulation techniques, real-time kinematic (“RTK”) techniques, and/or other suitable techniques.” And see col. 3, lines 62-col. 4, line 1 and Fig. 1: “network 103 may include and/or may be communicatively coupled to one or more location determination facilities comprising devices or systems such as mobility devices or systems, or the like, such as an MME or an AMF. As also noted above, such devices or systems of network 103 may monitor (at 102) a geographical location of UE 101”. And see col. 7, lines 10-19: “Network 103 may continue to monitor (at 212) the location of UE 101, and may provide (at 214) UE location information (e.g., indicating that UE 101 is located within region 100) to GTACS 105.” And see col. 9, lines 14-21 and Fig. 5: “GTACS 105 may receive a UE or user identifier associated with UE 101-1 along with location information associated with UE 101-1, based on which GTACS 105 may determine that UE 101-1 is presently located within a geographical region specified by policy 107, and may further determine that UE 101-1 is authorized to access the one or more applications, services, etc., specified in policy 107 when located within geographical region 500.” The Examiner interprets a Mobility Management Entity (“MME”) or an Access and Mobility Management Function (“AMF”) as a network element in the core mobile network. The Examiner further interprets the entity on a Mobility Management Entity (“MME”) or an Access and Mobility Management Function (“AMF”) determining the location of UEs communicatively coupled to the RAN as an agent executed on a network element in the core mobile network. Feldmann inherently teaches “monitor[ing] network traffic in a core mobile network using an agent executed on a network element in the core mobile network” because the MME or the AMF cannot determine the location of UEs communicatively coupled to the RAN without monitoring network traffic.) to identify a session associated with a User Equipment (UE) that attached to the core mobile network for mobile network communications (see col. 16, lines 52-56 and Fig. 9: “AMF 915 may include one or more devices, systems, Virtualized Network Functions (“VNFs”), etc., that perform operations to register UE 101 with the 5G network, to establish bearer channels associated with a session with UE 101”. And see col. 16, lines 64-67 and Fig. 9: “MME 916 may include one or more devices, systems, VNFs, etc., that perform operations to register UE 101 with the EPC, to establish bearer channels associated with a session with UE 101”);
extract meta information associated with the session using the agent executed on the network element in the core mobile network (see col. 3, lines 62-col. 4, line 1 and Fig. 1: “network 103 may include and/or may be communicatively coupled to one or more location determination facilities comprising devices or systems such as mobility devices or systems, or the like, such as an MME or an AMF. As also noted above, such devices or systems of network 103 may monitor (at 102) a geographical location of UE 101”. And see col. 7, lines 10-19: “Network 103 may continue to monitor (at 212) the location of UE 101, and may provide (at 214) UE location information (e.g., indicating that UE 101 is located within region 100) to GTACS 105.”), wherein the meta information includes subscriber information, equipment information (see col. 9, lines 14-21 and Fig. 5: “GTACS 105 may receive a UE or user identifier associated with UE 101-1 along with location information associated with UE 101-1, based on which GTACS 105 may determine that UE 101-1 is presently located within a geographical region specified by policy 107, and may further determine that UE 101-1 is authorized to access the one or more applications, services, etc., specified in policy 107 when located within geographical region 500.” The Examiner interprets a “user identifier” as wherein the meta information includes subscriber information. The Examiner further interprets a “UE …identifier” as wherein the meta information includes …equipment information), network slice information (see col. 12, line 54-col. 13, line 4: “GTACS 105 may determine that a particular policy 107 is associated with access to a particular “slice” of a 5G network, where a slice corresponds to a “network slice” as implemented according to Third Generation Partnership Project (3GPP) specifications, and includes instances of one or more network functions. … In such situations, GTACS 105 may provide indications to a network element managing network access control and/or slice access control …, which may allow or block UE 101 to connect to a particular slice of the core network.” And see col. 17, line 62-col. 18, line 14: “GTACS 105 may receive and/or maintain one or more policies 107, monitor and/or otherwise receive location information associated with one or more UEs 101, determine (e.g., based on the monitored location) whether criteria associated with one or more policies 107 are met, and selectively grant and/or deny access by UE 101 to certain resources (e.g., applications, services, devices, etc.) based on whether such policies 107 are met. …GTACS 105 may communicate with RAN 910 and/or RAN 912 (e.g., gNB 911, eNB 913, and/or one or more other devices or systems), AMF 915, MME 916, and/or one or more other devices or systems to indicate access parameters associated with one or more UEs 101. As discussed above, UE 101 may be permitted to access (or denied access to) RAN 910, RAN 912, and/or one or more network slices based on the access parameters.” Feldmann inherently teaches extracting network slice information because GTACS 105 cannot determine whether criteria associated with a policy 107 associated with access to a network slice are met without extracted network slice information.), and other meta data (see col. 9, lines 14-21 and Fig. 5: “GTACS 105 may receive a UE or user identifier associated with UE 101-1 along with location information associated with UE 101-1, based on which GTACS 105 may determine that UE 101-1 is presently located within a geographical region specified by policy 107, and may further determine that UE 101-1 is authorized to access the one or more applications, services, etc., specified in policy 107 when located within geographical region 500.” And see col. 8, lines 53-60: “a particular policy 107 may include identifiers of one or more UEs, such as … Internet Protocol (“IP”) addresses, and/or other suitable identifiers.” The Examiner interprets “location information associated with UE 101-1” and “Internet Protocol (“IP”) addresses “as wherein the meta information includes … other meta data. Therefore, the Examiner interprets “a UE or user identifier associated with UE 101-1 along with location information associated with UE 101-1”, network slice information and “Internet Protocol (“IP”) addresses” as meta information.),
wherein the subscriber information includes one or more of the following: subscriber-ID, International Mobile Subscriber Identity (IMSI), and/or Subscription Permanent Identifier (SUPI) (see col. 8, lines 51-58 and Fig. 1: “the same policy 107 may apply to certain UEs or users, or groups of UEs or users. For example, a particular policy 107 may include identifiers of one or more UEs, such as International Mobile Subscriber Identity (“IMSI”) values, International Mobile Station Equipment Identity (“IMEI”) values, Globally Unique Temporary Identifier (“GUTI”) values, Subscription Permanent Identifier (“SUPI”) vales”),
wherein the equipment information includes one or more of the following: equipment-ID, International Mobile Equipment Identity (IMEI), and/or Permanent Equipment Identifier (PEI) (see col. 8, lines 51-58 and Fig. 1: “the same policy 107 may apply to certain UEs or users, or groups of UEs or users. For example, a particular policy 107 may include identifiers of one or more UEs, such as International Mobile Subscriber Identity (“IMSI”) values, International Mobile Station Equipment Identity (“IMEI”) values, Globally Unique Temporary Identifier (“GUTI”) values, Subscription Permanent Identifier (“SUPI”) vales”), and
wherein the other meta data includes two or more of the following: Radio Access Technology (RAT) Type, Access Point Name (APN), User IP (see col. 8, lines 53-60: “a particular policy 107 may include identifiers of one or more UEs, such as … Internet Protocol (“IP”) addresses, and/or other suitable identifiers.”), Data Network Name (DNN), Tracking Area Information (TAI), User Location Information (ULI) (see col. 9, lines 14-21 and Fig. 5: “GTACS 105 may receive a UE or user identifier associated with UE 101-1 along with location information associated with UE 101-1, based on which GTACS 105 may determine that UE 101-1 is presently located within a geographical region specified by policy 107, and may further determine that UE 101-1 is authorized to access the one or more applications, services, etc., specified in policy 107 when located within geographical region 500.”), user-ID, a syslog message, Mobility Restrictions, Protocol Data Unit (PDU) Session ID, Subscription Concealed Identifier (SUCI), UE (Aggregate Maximum Bit Rate) AMBR, Subscription Permanent Identifier (SUPI), Radio Access Technology (RAT) Type, and/or Globally Unique Temporary Identity (GUTI); and
send the extracted meta information to a security platform located outside of the core mobile network (see Col. 4, lines 22-27 and Fig. 1: “GTACS 105 may be communicatively coupled to a Service Capability Exposure Function (“SCEF”), a Network Exposure Function (“NEF”), and/or some other device or system that provides an API or other interface via which GTACS 105 may receive the location information from a location determination facility”. And see col. 7, lines 10-19 and Figs. 1, 2: “Network 103 may continue to monitor (at 212) the location of UE 101, and may provide (at 214) UE location information (e.g., indicating that UE 101 is located within region 100) to GTACS 105”. And see col. 9, lines 14-21 and Fig. 5: “GTACS 105 may receive a UE or user identifier associated with UE 101-1 along with location information associated with UE 101-1”. The Examiner interprets the Geographic- and/or Time-based Access Control System (“GTACS”) 105 located outside of the mobile network 103 as a security platform located outside of the core mobile network.),
wherein the security platform is configured to: enforce a security policy on the session at the security platform based on the extracted meta information to apply granular security (see col. 2, lines 17-32: “one or more other factors may be used in the location-based authentication techniques of some embodiments, such as policies associated with particular UEs or users”. And see col. 4, lines 49-58 and Fig. 1: “GTACS 105 may maintain a set of access policies 107 (referred to herein in plural as “policies 107” or singularly as “policy 107”) that specify location-based restrictions on how UE 101 is able to interact with certain applications, services, devices, networks, etc. For example, a policy 107 may specify that certain applications, services or devices are blocked (e.g. not visible, not discoverable, not launchable, etc.) when UE 101 is outside of region 100, and/or that such applications, services or devices are not blocked when UE 101 is within region 100”. And see col. 9, lines 14-27: “GTACS 105 may receive a UE or user identifier associated with UE 101-1 along with location information associated with UE 101-1, based on which GTACS 105 may determine that UE 101-1 is presently located within a geographical region specified by policy 107, and may further determine that UE 101-1 is authorized to access the one or more applications, services, etc., specified in policy 107 when located within geographical region 500. On the other hand, GTACS 105 may provide indication (at 504) that UE 101-2 has restricted access to such applications, services, etc., based on UE 101-2 not being identified as an authorized UE by policy 107, even though UE 101-2 is reported as located within region 500 specified by policy 107.”) in the core mobile network based on the security policy (see col. 12, line 50-col. 13, line 4: “allowing or restricting access (such as described in the examples above) may include allowing or restricting access to one or more networks, such as one or more RANs, core networks, or portions thereof. For example, GTACS 105 may determine that a particular policy 107 is associated with access to a particular “slice” of a 5G network, where a slice corresponds to a “network slice” as implemented according to Third Generation Partnership Project (3GPP) specifications, and includes instances of one or more network functions. … In such situations, GTACS 105 may provide indications to a network element managing network access control and/or slice access control (e.g., a base station to which UE 101 is communicatively coupled, an AMF, a Session Management Function (“SMF”), a Unified Data Management function (“UDM”), a Network Slice Selection Function (“NSSF”) or some other element), which may allow or block UE 101 to connect to a particular slice of the core network.” Also see col. 18, lines 6-14: “GTACS 105 may communicate with RAN 910 and/or RAN 912 (e.g., gNB 911, eNB 913, and/or one or more other devices or systems), AMF 915, MME 916, and/or one or more other devices or systems to indicate access parameters associated with one or more UEs 101. As discussed above, UE 101 may be permitted to access (or denied access to) RAN 910, RAN 912, and/or one or more network slices based on the access parameters.”); and
a memory coupled to the processor and configured to provide the processor with instructions (see col. 20, line 45 and Fig. 12: memory 1230).
Feldmann differs from claims 1, 16 and 20 in that it fails to disclose wherein the network slice information includes network slice-ID.
However, Kunz discloses wherein the network slice information includes network slice-ID (see [0132]- [0134]: “An authentication method for a mobile network system including a security device as part of a network device, the method comprising: storing slice security requirements which are different for each slice ID, the slice ID indicating a network slice in a core network; and selecting, based on the slice security requirements, a security algorithm for the network slice.”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to let the network slice information taught by Feldmann include network slice- ID as taught by Kunz. It would have been obvious because doing so predictably achieves the commonly understood benefit of uniquely identifying a network slice so that the particular policy 107 associated with access to a particular “slice” of a 5G network taught by Feldmann can be evaluated based on the identified network slice.
Regarding claim 9, Feldmann further teaches wherein the security platform is configured with a plurality of security policies to apply subscriber-ID based security, equipment-ID based security, and/or network slice-ID based security (see col. 8, lines 51-58 and Fig. 1: “the same policy 107 may apply to certain UEs or users, or groups of UEs or users. For example, a particular policy 107 may include identifiers of one or more UEs, such as International Mobile Subscriber Identity (“IMSI”) values, International Mobile Station Equipment Identity (“IMEI”) values, Globally Unique Temporary Identifier (“GUTI”) values, Subscription Permanent Identifier (“SUPI”) vales”) in the core mobile network (see col. 12, line 50-col. 13, line 4: “allowing or restricting access (such as described in the examples above) may include allowing or restricting access to one or more networks, such as one or more RANs, core networks, or portions thereof. For example, GTACS 105 may determine that a particular policy 107 is associated with access to a particular “slice” of a 5G network, where a slice corresponds to a “network slice” as implemented according to Third Generation Partnership Project (3GPP) specifications, and includes instances of one or more network functions. … In such situations, GTACS 105 may provide indications to a network element managing network access control and/or slice access control (e.g., a base station to which UE 101 is communicatively coupled, an AMF, a Session Management Function (“SMF”), a Unified Data Management function (“UDM”), a Network Slice Selection Function (“NSSF”) or some other element), which may allow or block UE 101 to connect to a particular slice of the core network.” Also see col. 18, lines 6-14: “GTACS 105 may communicate with RAN 910 and/or RAN 912 (e.g., gNB 911, eNB 913, and/or one or more other devices or systems), AMF 915, MME 916, and/or one or more other devices or systems to indicate access parameters associated with one or more UEs 101. As discussed above, UE 101 may be permitted to access (or denied access to) RAN 910, RAN 912, and/or one or more network slices based on the access parameters.”).
Regarding claim 12, Feldmann further teaches wherein the processor is further configured to: perform application identification and control in the core mobile network (see col. 10, lines 19-35 and Fig. 7: “GUI 701 may further include a set of icons that are represented in a manner that indicates that applications associated with the icons are unavailable and/or are available with limited functionality. … In some embodiments, other types of representation of unavailable or limited functionality may be provided via UE 701, such as an “X” or other overlay over respective icons, notification 703, and/or other representations. Notification 703 may be displayed, for example, when a user selects an icon associated with an application that is presently unavailable due to one or more policies 107.” And see col. 10, lines 57-60 and Fig. 7: “GUI 705 may include notification 707, which may indicate that applications that were previously unavailable are now available (e.g., based on the access received (at 702) from GTACS 105).”).
Regarding claim 14, Feldmann further teaches wherein the processor is further configured to: block the session from accessing a resource based on the security policy (see col. 6, lines 23-36: “GTACS 105 may provide restriction information to applications, services, devices, etc., that are specified in policies 107, such that access attempts by UE 101 may be blocked or degraded. For example, a system (e.g., an application, service, device, network, etc) may receive a request to use the system from UE 101. The request may be an initial request (e.g., to start, launch, connect, etc.) or part of an existing series of interactions with the system. Upon receipt of restriction information 108 indicating that access by UE 101 should be restricted, the system may block or degrade access to the system by the UE 101—for example, by preventing/terminating execution of an application, service or portion of either, by preventing/terminating interaction with a device or a portion of a device, etc.”).
Regarding claim 15, Feldmann further teaches wherein the processor is further configured to: allow the session to access a resource based on the security policy (see col. 7, lines 10-19: “Based on the received location information, GTACS 105 may determine (at 216) that UE 101 is located within region 100 as specified by policy 107, and may provide restriction information that indicates UE 101 is allowed access to those applications, services, devices, etc., specified by policy 107 (at 218) while UE 101 is located within region 100”).
Claims 2, 4, 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Feldmann (US 11,317,292), further in view of Kunz (US 2019/0141081), and further in view of a non-patent literature entitled “Run-Time Adaptive In-Kernel BPF/XDP Solution for 5G UPF” by Navarro do Amaral et al. (hereafter “Navarro do Amaral”, provided in the IDS dated 9/19/2023).
Regarding claims 2 and 17, Feldmann modified in view of Kunz fails to disclose wherein the agent executed on the network element in the core mobile network comprises an extended Berkeley Packet Filter (eBPF) agent.
In the same field of endeavor, Navarro do Amaral teaches wherein the agent executed on the network element in the core mobile network (see page 5, section 2.4.2, ¶ 1: “One of the main user plane components for NGC is the UPF.” And see Abstract: “The project proposes an in-kernel solution based on BPF and eXpress Data Path (XDP) for 5G User Plane Function (UPF) implementations.” The Examiner interprets the User Plane Function (UPF) as the network element in the core mobile network.) comprises an extended Berkeley Packet Filter (eBPF) agent (see page 2, section 2.1. ¶ 1: “BPF [9], well known as eBPF, is a general purpose engine that allows you to execute instructions in the Linux kernel itself with two main goals: (i) to deliver negligible overhead when mapping these instructions to native instructions, and (ii) to guarantee that the program is safe at load time.”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to let the agent executed on the network element in the core mobile network taught by Feldmann modified in view of Kunz comprise an extended Berkeley Packet Filter (eBPF) agent, as taught by Navarro do Amaral. It would have been obvious because Navarro do Amaral teaches that eBPF has the following benefit: being a general purpose engine allowing executing instructions in the Linux kernel itself with two main goals: (i) to deliver negligible overhead when mapping these instructions to native instructions, and (ii) to guarantee that the program is safe at load time (see Navarro do Amaral, page 2, section 2.1. ¶ 1).
Regarding claims 4 and 19, Feldmann modified in view of Kunz fails to disclose wherein the agent executed on the network element in the core mobile network comprises an extended Berkeley Packet Filter (eBPF) agent that provides access to the network traffic at an interface of the network element.
In the same field of endeavor, Navarro do Amaral teaches wherein the agent executed on the network element in the core mobile network (see page 5, section 2.4.2, ¶ 1: “One of the main user plane components for NGC is the UPF.” And see Abstract: “The project proposes an in-kernel solution based on BPF and eXpress Data Path (XDP) for 5G User Plane Function (UPF) implementations.” The Examiner interprets the User Plane Function (UPF) as the network element in the core mobile network.) comprises an extended Berkeley Packet Filter (eBPF) agent (see page 2, section 2.1. ¶ 1: “BPF [9], well known as eBPF, is a general purpose engine that allows you to execute instructions in the Linux kernel itself with two main goals: (i) to deliver negligible overhead when mapping these instructions to native instructions, and (ii) to guarantee that the program is safe at load time.”) that provides access to the network traffic at an interface of the network element (see page 8, ¶ 1: “The Parser parses the ingress traffic to check if it is a uplink (GTPu) or a downlink (UDP) flow. If it is an uplink/downlink flow, the TEID/UE IP address key is used to get the PFCP session context. Then, the packet is passed to the PFCP session context represented by a BPF program via tail calls.”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to let the agent executed on the network element in the core mobile network taught by Feldmann modified in view of Kunz comprise an extended Berkeley Packet Filter (eBPF) agent that provides access to the network traffic at an interface of the network element, as taught by Navarro do Amaral. It would have been obvious because Navarro do Amaral teaches that eBPF has the following benefit: being a general purpose engine allowing executing instructions in the Linux kernel itself with two main goals: (i) to deliver negligible overhead when mapping these instructions to native instructions, and (ii) to guarantee that the program is safe at load time (see Navarro do Amaral, page 2, section 2.1. ¶ 1).
Claims 3 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Feldmann (US 11,317,292), further in view of Kunz (US 2019/0141081), further in view of a non-patent literature entitled “Run-Time Adaptive In-Kernel BPF/XDP Solution for 5G UPF” by Navarro do Amaral et al. (hereafter “Navarro do Amaral”, provided in the IDS dated 9/19/2023), and further in view of Wang (CN 116506189 A).
Regarding claims 3 and 18, Feldmann modified in view of Kunz fails to disclose wherein the agent executed on the network element in the core mobile network comprises an extended Berkeley Packet Filter (eBPF) agent.
In the same field of endeavor, Navarro do Amaral teaches wherein the agent executed on the network element in the core mobile network (see page 5, section 2.4.2, ¶ 1: “One of the main user plane components for NGC is the UPF.” And see Abstract: “The project proposes an in-kernel solution based on BPF and eXpress Data Path (XDP) for 5G User Plane Function (UPF) implementations.” The Examiner interprets the User Plane Function (UPF) as the network element in the core mobile network.) comprises an extended Berkeley Packet Filter (eBPF) agent (see page 2, section 2.1. ¶ 1: “BPF [9], well known as eBPF, is a general purpose engine that allows you to execute instructions in the Linux kernel itself with two main goals: (i) to deliver negligible overhead when mapping these instructions to native instructions, and (ii) to guarantee that the program is safe at load time.”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to let the agent executed on the network element in the core mobile network taught by Feldmann modified in view of Kunz comprise an extended Berkeley Packet Filter (eBPF) agent, as taught by Navarro do Amaral. It would have been obvious because Navarro do Amaral teaches that eBPF has the following benefit: being a general purpose engine allowing executing instructions in the Linux kernel itself with two main goals: (i) to deliver negligible overhead when mapping these instructions to native instructions, and (ii) to guarantee that the program is safe at load time (see Navarro do Amaral, page 2, section 2.1. ¶ 1).
Feldmann modified in view of Kunz and Navarro do Amaral fails to disclose that the extended Berkeley Packet Filter (eBPF) agent provides access to the network traffic at a kernel level of the network element prior to encryption of the network traffic.
However, Wang teaches an extended Berkeley Packet Filter (eBPF) agent that provides access to the network traffic at a kernel level of the network element prior to encryption of the network traffic (see Machine Translation, page 6, [n0046]: “Through the present invention, without modifying the application code and without a CA certificate, the SSL_write and SSL_read calling functions of the OpenSSL encryption shared library are detected with the help of an eBPF-based tracer, and the tracing code is injected into the calling function. When the program runs to the corresponding function, a soft interrupt is triggered to fall into the kernel, and the injected tracing code is executed to capture the traffic before encryption, which is continuously stored in the BPF ring buffer and finally summarized and displayed in the analysis page”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to let the extended Berkeley Packet Filter (eBPF) agent taught by Feldmann modified in view of Kunz and Navarro do Amaral provide access to the network traffic at a kernel level of the network element prior to encryption of the network traffic, as taught by Wang. It would have been obvious because Wang explicitly teaches that doing so achieves the following benefit: “When the program runs to the corresponding function, a soft interrupt is triggered to fall into the kernel, and the injected tracing code is executed to capture the traffic before encryption, which is continuously stored in the BPF ring buffer and finally summarized and displayed in the analysis page, so as to facilitate and quickly perform problem troubleshooting and network security audits. This not only simplifies the user's operation steps, but also reduces the difficulty of capturing and decrypting traffic, greatly saves manpower and time costs, and has high application value.” (see the Machine Translation of Wang, page 6, [n0046]).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Feldmann (US 11,317,292), further in view of Kunz (US 2019/0141081), and further in view of Thiebaut (US 2023/0300104).
Regarding claim 5, Feldmann further teaches wherein the agent sends the extracted meta information to the security platform located outside of the core mobile network using an application programming interface (API) (see col. 4, lines 22-27: “GTACS 105 may be communicatively coupled to a Service Capability Exposure Function (“SCEF”), a Network Exposure Function (“NEF”), and/or some other device or system that provides an API or other interface via which GTACS 105 may receive the location information from a location determination facility”) .
Feldmann modified in view of Kunz differs from claim 5 in that it fails to disclose that the agent executed on a network element in the core mobile network sends data to push a mapping of a mobile identifier-to-IP address associated with the session (emphasis added).
In the same field of endeavor, Thiebaut teaches that an agent executed on a network element in the core mobile network sends data to push a mapping of a mobile identifier-to-IP address associated with the session (see [0230]: “Current NEF influence API (Nnef_TrafficInfluence) defined in 3GPP Release 15 provides an authorized AF with a mapping between a UE (source) internet protocol (IP) address allocated/used by the 5GC and a UE subscriber identifier allocated by the 5GC, such as a subscriber permanent identifier (SUPI).”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to let the agent executed on a network element in the core mobile network taught by Feldmann modified in view of Kunz send data to push a mapping of a mobile identifier-to-IP address associated with the session as disclosed by Thiebaut. It would have been obvious because doing so predictably achieves the commonly understood benefit of converting a mobile identifier to an IP address used on the Internet so that an interaction of the User Equipment with the Internet can be managed.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Feldmann (US 11,317,292), further in view of Kunz (US 2019/0141081), and further in view of Howe (US 2022/0408255).
Regarding claim 10, Feldmann further teaches wherein the security platform is configured with a plurality of security policies (see col. 8, lines 51-58 and Fig. 1: “the same policy 107 may apply to certain UEs or users, or groups of UEs or users. For example, a particular policy 107 may include identifiers of one or more UEs, such as International Mobile Subscriber Identity (“IMSI”) values, International Mobile Station Equipment Identity (“IMEI”) values, Globally Unique Temporary Identifier (“GUTI”) values, Subscription Permanent Identifier (“SUPI”) vales”), equipment-ID based security, and/or network slice-ID based security in the core mobile network that includes a 5G mobile network (see col. 12, lines 54-56: “GTACS 105 may determine that a particular policy 107 is associated with access to a particular “slice” of a 5G network”).
Feldmann modified in view of Kunz differs from claim 10 in that it fails to disclose that the security platform is configured with a plurality of security policies to apply zero trust security (emphasis added).
In the same field of endeavor, Howe teaches that the security platform is configured … to apply zero trust security (see [0167]: “T