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 .
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.
Claim(s) 1-4 and 8-10 are rejected under 35 U.S.C. 103 as being unpatentable over Sivanesan et al. (US 2023/0188982 A1), hereinafter referred to as D1, in view of Villa et al. (US 8832790 B1), hereinafter referred to as D3.
Regarding claims 1, 8, D1 discloses an adaptive and hierarchical network authentication framework, which comprises:
receiving, by a device, a request (Referring to Figures 5-8, At operation 826, the PSF 810 communicates a request (request) to the base station 804 (device). The request is for the base station to start the PHY-based security process. The request can further include a request for the base station to start the collection of signal samples from the UE (e.g., IQ samples) for training. At operation 828, base station 804 communicates confirmation of the PHY-based security process to the PSF 810. The base station can also communicate the requested signal samples (e.g., IQ data) to the PSF 810. See paragraphs 0127-0133.);
processing, by the device, the request, with a machine learning model, to determine whether the connection is secure (Referring to Figures 5-8, At operation 842, PSE 810 generates an RF signature of the UE 802 based on the received training samples. At operation 843, PSF 810 communicates the RF signature to other network nodes (e.g., base station 804) (device) for subsequent use in a PHY-based security process. Alternatively, PSF 810 trains a machine learning model based on the received signal samples. For example, the machine learning model is trained to associate a specific device (UE) with the corresponding signal samples received from the device. The machine learning model can be trained to associate multiple devices with corresponding signal samples received from such devices. In some embodiments, PSF 810 generates the RF signature based on the received signal samples and trains a machine learning model to associate the device to the determined RF signature. In this regard, after the machine learning model is shared with other network nodes (e.g., base station 804), the other network nodes can perform a PHY-based security process (to determine whether the request is secure) using the shared machine learning model (e.g., signal samples can be used as input to the model, and the model can indicate the device the signal samples correspond or can indicate whether the device whose samples are entered as input is the correct/authenticated device). See paragraphs 0127-0133.); and
permitting, by the device, the connection based on the machine learning model determining that the request is legitimate and secure (Referring to figures 5-8, At operations 832, 834, 836, and 838, periodic PHY-based security (e.g., authentication-related) processes (permitting the request based on the machine learning model determining that the request is legitimate and secure) are performed based on the RF signature by the base station 804 (device). The PHY-based security processes can be configured and performed with a periodicity of T2 840. See paragraphs 0130-0132. The Examiner interprets the claim as permitting an authentication request based on the machine learning model determining the authentication is legitimate and secure.)
D1 does not disclose a network attach/RRC request; processing the network attach/RRC request with a machine learning model; perming the network attach/RRC request based on the machine learning model.
D3 teaches an adaptive authentication system 13 which includes a database 16 having a set of entries with each entry of the set of entries including an identifier and previous user data in connection with previous authentication requests. Request for a VPN connection (a network attach request) determined by the adaptive authentication system. See column 64 to column 8, line 22. It should also be understood that the adaptive authentication system 13 will be constructed and arranged to perform an adaptive authentication operation on the authentication request 11. For example, the risk engine 8 in the adaptive authentication device 14 can perform the adaptive authentication operation. Additionally, it should be further understood the adaptive authentication system 13 will be constructed and arranged to perform an unsupervised machine learning operation on the authentication request 11. For example, the machine learning engine 7 in the adaptive authentication device 14 can perform the unsupervised machine learning operation (processing the network attach request with a machine learning model). At step 105, the method will receive the authentication request 11 at the adaptive authentication system 13. The request 11 will comprise a user identifier and user data. It should be understood that a user identifier can be any entity participating in the event such as a user or an IP; such an entity contains, for example, sub entities with which the entity interacts (e.g., payees, devices, IP addresses, etc.). The user data will include facts and/or attributes in connection with the request. For example, such attributes can include geo-location, time, etc. It should be understood that the adaptive authentication system 13 can also receive another authentication request having a user identifier which is distinct from the user identifier of the authentication request. When performing the adaptive authentication operation on the other authentication request, the operation will match an entry having an identifier which matches the user identifier of the other authentication request but which is distinct from the particular entry. At step 110, the method will perform the adaptive authentication operation on the authentication request 11. The operation performed by the risk engine 8 will include matching the user identifier of the authentication request 11 with an identifier of a particular entry of the database. It should be appreciated from the foregoing that the database 16 comprises a set of entries with each entry comprising a user identifier and corresponding user data. In some cases, the database 16 can comprise one or more entries for a user. For example, the database can have entries corresponding to time intervals. Therefore, the database 16 can in some embodiments have one entry for each time interval. The adaptive authentication operation performed 110 by the risk engine 8 also includes generating an authentication result based on the analysis. The risk engine 8 will generate the authentication result 17 based on a set of Bayesian weights, each of which corresponds to an attribute associated with the current user data of the authentication request 11. It should be further understood that the authentication result 17 will also be sent by the adaptive authentication device 14 to the authentication requestor 18. The result 17 can dictate whether the user authentication is approved or rejected (permitting the network attach request based on the machine learning model). See column 5, line 29 to column 6, line 51.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the well-known technique of connection request authentication via a machine learning model of D3 in the well-known wireless system of D1. One of ordinary skill in the art before the effective filing date of the invention would have implemented the well-known technique in the well-known system to improve authentication speed and security for conventional key-based authentication mechanisms for high-end devices with enough capacity and compute capability.
Regarding claims 2, further regarding claim 8, D1 does not disclose denying, by the device, the network attach or the radio resource control request based on the machine learning model determining that the network attach or the radio resource control request is unsecure.
D3 teaches an adaptive authentication system 13 which includes a database 16 having a set of entries with each entry of the set of entries including an identifier and previous user data in connection with previous authentication requests. Request for a VPN connection (a network attach request) determined by the adaptive authentication system. See column 64 to column 8, line 22. It should also be understood that the adaptive authentication system 13 will be constructed and arranged to perform an adaptive authentication operation on the authentication request 11. For example, the risk engine 8 in the adaptive authentication device 14 can perform the adaptive authentication operation. Additionally, it should be further understood the adaptive authentication system 13 will be constructed and arranged to perform an unsupervised machine learning operation on the authentication request 11. For example, the machine learning engine 7 in the adaptive authentication device 14 can perform the unsupervised machine learning operation (processing the network attach request with a machine learning model). At step 105, the method will receive the authentication request 11 at the adaptive authentication system 13. The request 11 will comprise a user identifier and user data. It should be understood that a user identifier can be any entity participating in the event such as a user or an IP; such an entity contains, for example, sub entities with which the entity interacts (e.g., payees, devices, IP addresses, etc.). The user data will include facts and/or attributes in connection with the request. For example, such attributes can include geo-location, time, etc. It should be understood that the adaptive authentication system 13 can also receive another authentication request having a user identifier which is distinct from the user identifier of the authentication request. When performing the adaptive authentication operation on the other authentication request, the operation will match an entry having an identifier which matches the user identifier of the other authentication request but which is distinct from the particular entry. At step 110, the method will perform the adaptive authentication operation on the authentication request 11. The operation performed by the risk engine 8 will include matching the user identifier of the authentication request 11 with an identifier of a particular entry of the database. It should be appreciated from the foregoing that the database 16 comprises a set of entries with each entry comprising a user identifier and corresponding user data. In some cases, the database 16 can comprise one or more entries for a user. For example, the database can have entries corresponding to time intervals. Therefore, the database 16 can in some embodiments have one entry for each time interval. The adaptive authentication operation performed 110 by the risk engine 8 also includes generating an authentication result based on the analysis. The risk engine 8 will generate the authentication result 17 based on a set of Bayesian weights, each of which corresponds to an attribute associated with the current user data of the authentication request 11. It should be further understood that the authentication result 17 will also be sent by the adaptive authentication device 14 to the authentication requestor 18. The result 17 can dictate whether the user authentication is approved or rejected (permitting/denying the network attach request based on the machine learning model). See column 5, line 29 to column 6, line 51.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the well-known technique of connection request authentication via a machine learning model of D3 in the well-known wireless system of D1. One of ordinary skill in the art before the effective filing date of the invention would have implemented the well-known technique in the well-known system to improve authentication speed and security for conventional key-based authentication mechanisms for high-end devices with enough capacity and compute capability.
Regarding claim 3, D1 discloses receiving another network attach request or another radio resource control request; processing the other network attach request or the other radio resource control request, with the machine learning model, to determine whether the other network attach request or the other radio resource control request is secure; and permitting the other network attach request or the other radio resource control request based on the machine learning model determining that the other network attach request or the other radio resource control request is secure.
D3 teaches an adaptive authentication system 13 which includes a database 16 having a set of entries with each entry of the set of entries including an identifier and previous user data in connection with previous authentication requests. Request for a VPN connection, multiple requests contemplated (other network attach request), determined by the adaptive authentication system. See column 64 to column 8, line 22. It should also be understood that the adaptive authentication system 13 will be constructed and arranged to perform an adaptive authentication operation on the authentication request 11. For example, the risk engine 8 in the adaptive authentication device 14 can perform the adaptive authentication operation. Additionally, it should be further understood the adaptive authentication system 13 will be constructed and arranged to perform an unsupervised machine learning operation on the authentication request 11. For example, the machine learning engine 7 in the adaptive authentication device 14 can perform the unsupervised machine learning operation (processing the other network attach request with a machine learning model). At step 105, the method will receive the authentication request 11 at the adaptive authentication system 13. The request 11 will comprise a user identifier and user data. It should be understood that a user identifier can be any entity participating in the event such as a user or an IP; such an entity contains, for example, sub entities with which the entity interacts (e.g., payees, devices, IP addresses, etc.). The user data will include facts and/or attributes in connection with the request. For example, such attributes can include geo-location, time, etc. It should be understood that the adaptive authentication system 13 can also receive another authentication request having a user identifier which is distinct from the user identifier of the authentication request. When performing the adaptive authentication operation on the other authentication request, the operation will match an entry having an identifier which matches the user identifier of the other authentication request but which is distinct from the particular entry. At step 110, the method will perform the adaptive authentication operation on the authentication request 11. The operation performed by the risk engine 8 will include matching the user identifier of the authentication request 11 with an identifier of a particular entry of the database. It should be appreciated from the foregoing that the database 16 comprises a set of entries with each entry comprising a user identifier and corresponding user data. In some cases, the database 16 can comprise one or more entries for a user. For example, the database can have entries corresponding to time intervals. Therefore, the database 16 can in some embodiments have one entry for each time interval. The adaptive authentication operation performed 110 by the risk engine 8 also includes generating an authentication result based on the analysis. The risk engine 8 will generate the authentication result 17 based on a set of Bayesian weights, each of which corresponds to an attribute associated with the current user data of the authentication request 11. It should be further understood that the authentication result 17 will also be sent by the adaptive authentication device 14 to the authentication requestor 18. The result 17 can dictate whether the user authentication is approved or rejected (permitting/denying the other network attach request based on the machine learning model). See column 5, line 29 to column 6, line 51.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the well-known technique of connection request authentication via a machine learning model of D3 in the well-known wireless system of D1. One of ordinary skill in the art before the effective filing date of the invention would have implemented the well-known technique in the well-known system to improve authentication speed and security for conventional key-based authentication mechanisms for high-end devices with enough capacity and compute capability.
Regarding claim 4, D1 does not disclose denying the other network attach request or the other radio resource control request based on the machine learning model determining that the other network attach request or the other radio resource control request is unsecure.
D3 teaches an adaptive authentication system 13 which includes a database 16 having a set of entries with each entry of the set of entries including an identifier and previous user data in connection with previous authentication requests. Request for a VPN connection, multiple requests contemplated (other network attach request), determined by the adaptive authentication system. See column 64 to column 8, line 22. It should also be understood that the adaptive authentication system 13 will be constructed and arranged to perform an adaptive authentication operation on the authentication request 11. For example, the risk engine 8 in the adaptive authentication device 14 can perform the adaptive authentication operation. Additionally, it should be further understood the adaptive authentication system 13 will be constructed and arranged to perform an unsupervised machine learning operation on the authentication request 11. For example, the machine learning engine 7 in the adaptive authentication device 14 can perform the unsupervised machine learning operation (processing the other network attach request with a machine learning model). At step 105, the method will receive the authentication request 11 at the adaptive authentication system 13. The request 11 will comprise a user identifier and user data. It should be understood that a user identifier can be any entity participating in the event such as a user or an IP; such an entity contains, for example, sub entities with which the entity interacts (e.g., payees, devices, IP addresses, etc.). The user data will include facts and/or attributes in connection with the request. For example, such attributes can include geo-location, time, etc. It should be understood that the adaptive authentication system 13 can also receive another authentication request having a user identifier which is distinct from the user identifier of the authentication request. When performing the adaptive authentication operation on the other authentication request, the operation will match an entry having an identifier which matches the user identifier of the other authentication request but which is distinct from the particular entry. At step 110, the method will perform the adaptive authentication operation on the authentication request 11. The operation performed by the risk engine 8 will include matching the user identifier of the authentication request 11 with an identifier of a particular entry of the database. It should be appreciated from the foregoing that the database 16 comprises a set of entries with each entry comprising a user identifier and corresponding user data. In some cases, the database 16 can comprise one or more entries for a user. For example, the database can have entries corresponding to time intervals. Therefore, the database 16 can in some embodiments have one entry for each time interval. The adaptive authentication operation performed 110 by the risk engine 8 also includes generating an authentication result based on the analysis. The risk engine 8 will generate the authentication result 17 based on a set of Bayesian weights, each of which corresponds to an attribute associated with the current user data of the authentication request 11. It should be further understood that the authentication result 17 will also be sent by the adaptive authentication device 14 to the authentication requestor 18. The result 17 can dictate whether the user authentication is approved or rejected (permitting/denying the other network attach request based on the machine learning model). See column 5, line 29 to column 6, line 51.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the well-known technique of connection request authentication via a machine learning model of D3 in the well-known wireless system of D1. One of ordinary skill in the art before the effective filing date of the invention would have implemented the well-known technique in the well-known system to improve authentication speed and security for conventional key-based authentication mechanisms for high-end devices with enough capacity and compute capability.
Regarding claims 9, the primary reference further teaches wherein the machine learning model is a pattern recognition mode (Referring to Figures 5-8, The term “machine learning” or “ML” refers to the use of computer systems implementing algorithms and/or statistical models to perform a specific tasks) without using explicit instructions but instead relying on patterns and inferences. ML algorithms build or estimate mathematical model(s) (referred to as “ML models” or the like) based on sample data (referred to as “training data,” “model training information,” or the like) to make predictions or decisions without being explicitly programmed to perform such tasks. See paragraph 0094.)
Regarding claim 10, the primary reference further teaches wherein the one or more processors are further configured to: provide a registration request to attach to a core network; receive a message indicating that the registration request is authenticated; generate a protocol data unit (PDU) registration request based on receiving the message indicating that the registration request is authenticated; establish a PDU session with the core network based on the PDU registration request; provide a radio access network (RAN) identifier to the core network; receive, from the core network and based on the RAN identifier, cell identifiers around the RAN; and store the cell identifiers (Referring to Figures 5-8, the prior art teaches when a device enters the network, the authentication process is performed before connection is performed comprising the successful RACH (Random Access Channel) Message3, RRC connection request, and the RRC connection complete. Per the 3GPP LTE and 5G standards, the registration request is to attach to the core, authentication is performed via the crypto-based or physical layer security authentication before the request, PDU messages are generated, a PDU session with the CORE based on registration is performed, RAN ID is provided to the CORE and cell identifiers are received and stored. See paragraphs 0096-0098.)
Claim(s) 5-7, 11, 12, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over D1 in view of D3 in further view of Futaki et al. (US 2024/0414565 A1A1), hereinafter referred to as D2.
Regarding claims 5, 15, and 16, see rejection of claim 1 for additional limitations taught by D1 in view of D3, D1 further teaches receiving historical network data identifying authentications and identifiers of a plurality of user equipment, and historical behavior data identifying behaviors of the plurality of user equipment; training the machine learning model with the historical network data; and implementing the machine learning model in the plurality of user equipment or a radio access network associated with the plurality of user equipment (Referring to Figures 5-8, At operation 842, PSE 810 generates an RF signature of the UE 802 based on the received training samples. At operation 843, PSF 810 communicates the RF signature to other network nodes (e.g., base station 804) (device) for subsequent use in a PHY-based security process. Alternatively, PSF 810 trains a machine learning model based on the received signal samples. For example, the machine learning model is trained to associate a specific device (UE) (identifiers of a plurality of user equipment) with the corresponding signal samples received from the device (historical data identifying authentications/behaviors of the plurality of user equipment). The machine learning model can be trained to associate multiple devices with corresponding signal samples received from such devices. In some embodiments, PSF 810 generates the RF signature based on the received signal samples and trains a machine learning model to associate the device to the determined RF signature. In this regard, after the machine learning model is shared with other network nodes (e.g., base station 804), the other network nodes can perform a PHY-based security process (implementing the machine learning model in the plurality of user equipment or a RAN associated with the plurality of user equipment) using the shared machine learning model (e.g., signal samples can be used as input to the model, and the model can indicate the device the signal samples correspond or can indicate whether the device whose samples are entered as input is the correct/authenticated device). See paragraphs 0127-0133.)
D1 does not disclose receiving historical network data identifying radio resource control requests and historical behavior data identifying locations of the plurality of user equipment.
D2 teaches collecting network information to train machine learning utilizing statistical data indicates a subset of historical data of a given event, extracted by filtering the historical data by one or more conditions. The historical data may indicate a history of success or failure of mobility or beam selection by the UE 1. The historical data may indicate a history of beam management. The historical data may include one or more of a Beam Failure Detection (BFD) history, a Beam Failure Recovery (BFR) history, and a Radio Link Failure (RLF) history. In other words, the given event may be mobility or beam selection (or beam management) of the UE 1. As described above, the mobility may be mobility in RRC_CONNECTED (e.g., handover, conditional handover, primary cell changes in the MCG, and conditional primary cell change in the MCG) (RRC requests). Additionally or alternatively, the mobility may be mobility (i.e., cell reselection) in RRC_IDLE or RRC_INACTIVE. The one or more conditions for filtering the historical data may include one or more conditions related to one or more of the location, movement speed, serving beam, serving cell, and serving frequency band of the UE 1. More specifically, the one or more conditions for filtering the historical data may include one or more conditions relating to a mobility pattern of the UE 1. The UE 1 may extract from the recorded (or archived) historical data a subset of historical data corresponding to the same or similar mobility patterns as those specified in the condition(s). The mobility pattern may indicate one or any combination of a pair of source and target cells, a pair of source and target cell frequency bands, UE position (locations), UE speed, and a downlink beam. Additionally or alternatively, the one or more conditions for filtering the historical data may include one or more conditions relating to a network slice used by the UE 1. The UE 1 may extract from the recorded (or archived) historical data a subset of historical data corresponding to the same or similar network slice, slice group, or slice type as that specified in the condition(s). Additionally or alternatively, the one or more conditions for filtering the historical data may include one or more conditions relating to a radio configuration of the UE 1. The UE 1 may extract from the recorded (or archived) historical data a subset of historical data corresponding to the same or similar radio configuration as specified in the condition(s). For example, the radio configuration may be a mobility related parameter. More specifically, the radio configuration may be a particular value of a particular offset, a particular frequency priority, or a particular execution condition for conditional mobility. See paragraphs 0043-0048.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the machine learning of D2 in the system of D1 and D3. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to improve mobility service through optimization.
Regarding claims 6 and 18, D1 does not disclose wherein the historical network data identifies frequencies of the radio resource control requests, network device changes by the plurality of user equipment, and duplicate cell identifiers associated with the plurality of user equipment.
D2 teaches collecting network information to train machine learning utilizing statistical data indicates a subset of historical data of a given event, extracted by filtering the historical data by one or more conditions. The historical data may indicate a history of success or failure of mobility or beam selection by the UE 1. The historical data may indicate a history of beam management. The historical data may include one or more of a Beam Failure Detection (BFD) history, a Beam Failure Recovery (BFR) history, and a Radio Link Failure (RLF) history. In other words, the given event may be mobility or beam selection (or beam management) of the UE 1. As described above, the mobility may be mobility in RRC_CONNECTED (e.g., handover, conditional handover, primary cell changes in the MCG, and conditional primary cell change in the MCG) (RRC requests/ network device changes). Additionally or alternatively, the mobility may be mobility (i.e., cell reselection) in RRC_IDLE or RRC_INACTIVE. The one or more conditions for filtering the historical data may include one or more conditions related to one or more of the location, movement speed, serving beam, serving cell, and serving frequency band (frequencies of the RRC requests) of the UE 1. More specifically, the one or more conditions for filtering the historical data may include one or more conditions relating to a mobility pattern of the UE 1. The UE 1 may extract from the recorded (or archived) historical data a subset of historical data corresponding to the same or similar mobility patterns as those specified in the condition(s). The mobility pattern may indicate one or any combination of a pair of source and target cells (duplicate cell identifiers associated with the plurality of user equipment), a pair of source and target cell frequency bands, UE position (locations), UE speed, and a downlink beam. Additionally or alternatively, the one or more conditions for filtering the historical data may include one or more conditions relating to a network slice used by the UE 1. The UE 1 may extract from the recorded (or archived) historical data a subset of historical data corresponding to the same or similar network slice, slice group, or slice type as that specified in the condition(s). Additionally or alternatively, the one or more conditions for filtering the historical data may include one or more conditions relating to a radio configuration of the UE 1. The UE 1 may extract from the recorded (or archived) historical data a subset of historical data corresponding to the same or similar radio configuration as specified in the condition(s). For example, the radio configuration may be a mobility related parameter. More specifically, the radio configuration may be a particular value of a particular offset, a particular frequency priority, or a particular execution condition for conditional mobility. See paragraphs 0043-0048.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the machine learning of D2 in the system of D1 and D3. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to improve mobility service through optimization.
Regarding claims 7 and 19, D1 does not disclose wherein the historical behavior data identifies last known locations and times associated with the plurality of user equipment, identifiers of wireless access points utilized by the plurality of user equipment, and locations of the wireless access points utilized by the plurality of user equipment.
D2 teaches collecting network information to train machine learning utilizing statistical data indicates a subset of historical data of a given event, extracted by filtering the historical data by one or more conditions. The historical data may indicate a history of success or failure of mobility or beam selection by the UE 1. The historical data may indicate a history of beam management. The historical data may include one or more of a Beam Failure Detection (BFD) history, a Beam Failure Recovery (BFR) history, and a Radio Link Failure (RLF) history. In other words, the given event may be mobility or beam selection (or beam management) of the UE 1. As described above, the mobility may be mobility in RRC_CONNECTED (e.g., handover, conditional handover, primary cell changes in the MCG, and conditional primary cell change in the MCG). Additionally or alternatively, the mobility may be mobility (i.e., cell reselection) in RRC_IDLE or RRC_INACTIVE. The one or more conditions for filtering the historical data may include one or more conditions related to one or more of the location (last known locations), movement speed, serving beam, serving cell, and serving frequency band of the UE 1. More specifically, the one or more conditions for filtering the historical data may include one or more conditions relating to a mobility pattern of the UE 1. The UE 1 may extract from the recorded (or archived) historical data a subset of historical data corresponding to the same or similar mobility patterns as those specified in the condition(s). The mobility pattern may indicate one or any combination of a pair of source and target cells (identifiers of wireless access points utilized by the plurality of user equipment), a pair of source and target cell frequency bands, UE position (locations), UE speed, and a downlink beam. Additionally or alternatively, the one or more conditions for filtering the historical data may include one or more conditions relating to a network slice used by the UE 1. The UE 1 may extract from the recorded (or archived) historical data a subset of historical data corresponding to the same or similar network slice, slice group, or slice type as that specified in the condition(s). Additionally or alternatively, the one or more conditions for filtering the historical data may include one or more conditions relating to a radio configuration of the UE 1. The UE 1 may extract from the recorded (or archived) historical data a subset of historical data corresponding to the same or similar radio configuration as specified in the condition(s). For example, the radio configuration may be a mobility related parameter. More specifically, the radio configuration may be a particular value of a particular offset, a particular frequency priority, or a particular execution condition for conditional mobility. See paragraphs 0043-0048. Time of events are collected (time associated with UEs). The condition may allow the UE 1 to collect or report predicted data based on AI/ML inference results if a given failure is repeatedly detected under the same or similar circumstances (e.g., location (location of wireless access point), cell, cell pair, time, frequency band, time). The given failure may be, for example, a handover failure or a beam failure. The circumstances can be at least one of location, cell, cell pair, time, frequency band, or time. See paragraphs 0057-0060.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the machine learning of D2 in the system of D1 and D3. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to improve mobility service through optimization.
Regarding claim 11, D1 does not disclose wherein the one or more processors are further configured to: process the cell identifiers, with the machine learning model, to verify the cell identifiers.
D2 teaches collecting network information to train machine learning utilizing statistical data indicates a subset of historical data of a given event, extracted by filtering the historical data by one or more conditions. The historical data may indicate a history of success or failure of mobility or beam selection by the UE 1. The historical data may indicate a history of beam management. The historical data may include one or more of a Beam Failure Detection (BFD) history, a Beam Failure Recovery (BFR) history, and a Radio Link Failure (RLF) history. In other words, the given event may be mobility or beam selection (or beam management) of the UE 1. As described above, the mobility may be mobility in RRC_CONNECTED (e.g., handover, conditional handover, primary cell changes in the MCG, and conditional primary cell change in the MCG). Additionally or alternatively, the mobility may be mobility (i.e., cell reselection) in RRC_IDLE or RRC_INACTIVE. The one or more conditions for filtering the historical data may include one or more conditions related to one or more of the location (last known locations), movement speed, serving beam, serving cell, and serving frequency band of the UE 1. More specifically, the one or more conditions for filtering the historical data may include one or more conditions relating to a mobility pattern of the UE 1. The UE 1 may extract from the recorded (or archived) historical data a subset of historical data corresponding to the same or similar mobility patterns as those specified in the condition(s). The mobility pattern may indicate one or any combination of a pair of source and target cells (process the cell IDs to verify the cell IDs), a pair of source and target cell frequency bands, UE position (locations), UE speed, and a downlink beam. Additionally or alternatively, the one or more conditions for filtering the historical data may include one or more conditions relating to a network slice used by the UE 1. The UE 1 may extract from the recorded (or archived) historical data a subset of historical data corresponding to the same or similar network slice, slice group, or slice type as that specified in the condition(s). Additionally or alternatively, the one or more conditions for filtering the historical data may include one or more conditions relating to a radio configuration of the UE 1. The UE 1 may extract from the recorded (or archived) historical data a subset of historical data corresponding to the same or similar radio configuration as specified in the condition(s). For example, the radio configuration may be a mobility related parameter. More specifically, the radio configuration may be a particular value of a particular offset, a particular frequency priority, or a particular execution condition for conditional mobility. See paragraphs 0043-0048. Time of events are collected. The condition may allow the UE 1 to collect or report predicted data based on AI/ML inference results if a given failure is repeatedly detected under the same or similar circumstances (e.g., location, cell, cell pair, time, frequency band, time). The given failure may be, for example, a handover failure or a beam failure. The circumstances can be at least one of location, cell, cell pair, time, frequency band, or time. See paragraphs 0057-0060.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the machine learning of D2 in the system of D1 and D3. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to improve mobility service through optimization.
Regarding claim 12, D1 does not disclose wherein the one or more processors, to store the cell identifiers, are configured to: store the cell identifiers in the device or in a cloud-based device.
D2 teaches collecting network information to train machine learning utilizing statistical data indicates a subset of historical data of a given event, extracted by filtering the historical data by one or more conditions. The historical data may indicate a history of success or failure of mobility or beam selection by the UE 1. The historical data may indicate a history of beam management. The historical data may include one or more of a Beam Failure Detection (BFD) history, a Beam Failure Recovery (BFR) history, and a Radio Link Failure (RLF) history. In other words, the given event may be mobility or beam selection (or beam management) of the UE 1. As described above, the mobility may be mobility in RRC_CONNECTED (e.g., handover, conditional handover, primary cell changes in the MCG, and conditional primary cell change in the MCG). Additionally or alternatively, the mobility may be mobility (i.e., cell reselection) in RRC_IDLE or RRC_INACTIVE. The one or more conditions for filtering the historical data may include one or more conditions related to one or more of the location (last known locations), movement speed, serving beam, serving cell, and serving frequency band of the UE 1. More specifically, the one or more conditions for filtering the historical data may include one or more conditions relating to a mobility pattern of the UE 1. The UE 1 may extract from the recorded (or archived) historical data a subset of historical data corresponding to the same or similar mobility patterns as those specified in the condition(s). The mobility pattern may indicate one or any combination of a pair of source and target cells (process the cell IDs to verify the cell IDs, store the cell IDs in the device), a pair of source and target cell frequency bands, UE position (locations), UE speed, and a downlink beam. Additionally or alternatively, the one or more conditions for filtering the historical data may include one or more conditions relating to a network slice used by the UE 1. The UE 1 may extract from the recorded (or archived) historical data a subset of historical data corresponding to the same or similar network slice, slice group, or slice type as that specified in the condition(s). Additionally or alternatively, the one or more conditions for filtering the historical data may include one or more conditions relating to a radio configuration of the UE 1. The UE 1 may extract from the recorded (or archived) historical data a subset of historical data corresponding to the same or similar radio configuration as specified in the condition(s). For example, the radio configuration may be a mobility related parameter. More specifically, the radio configuration may be a particular value of a particular offset, a particular frequency priority, or a particular execution condition for conditional mobility. See paragraphs 0043-0048. Time of events are collected. The condition may allow the UE 1 to collect or report predicted data based on AI/ML inference results if a given failure is repeatedly detected under the same or similar circumstances (e.g., location, cell, cell pair, time, frequency band, time). The given failure may be, for example, a handover failure or a beam failure. The circumstances can be at least one of location, cell, cell pair, time, frequency band, or time. See paragraphs 0057-0060.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the machine learning of D2 in the system of D1 and D3. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to improve mobility service through optimization.
Regarding claim 17, D1 does not disclose receive a network attach request or another radio resource control request; process the network attach request or the other radio resource control request, with the trained machine learning model, to determine whether the network attach request or the other radio resource control request is secure; and selectively: permit the network attach request or the other radio resource control request based on the trained machine learning model determining that the network attach request or the other radio resource control request is secure; or deny the network attach request or the other radio resource control request based on the trained machine learning model determining that the network attach request or the other radio resource control request is unsecure.
D3 teaches an adaptive authentication system 13 which includes a database 16 having a set of entries with each entry of the set of entries including an identifier and previous user data in connection with previous authentication requests. Request for a VPN connection, multiple requests contemplated (other network attach request), determined by the adaptive authentication system. See column 64 to column 8, line 22. It should also be understood that the adaptive authentication system 13 will be constructed and arranged to perform an adaptive authentication operation on the authentication request 11. For example, the risk engine 8 in the adaptive authentication device 14 can perform the adaptive authentication operation. Additionally, it should be further understood the adaptive authentication system 13 will be constructed and arranged to perform an unsupervised machine learning operation on the authentication request 11. For example, the machine learning engine 7 in the adaptive authentication device 14 can perform the unsupervised machine learning operation (processing the other network attach request with a machine learning model). At step 105, the method will receive the authentication request 11 at the adaptive authentication system 13. The request 11 will comprise a user identifier and user data. It should be understood that a user identifier can be any entity participating in the event such as a user or an IP; such an entity contains, for example, sub entities with which the entity interacts (e.g., payees, devices, IP addresses, etc.). The user data will include facts and/or attributes in connection with the request. For example, such attributes can include geo-location, time, etc. It should be understood that the adaptive authentication system 13 can also receive another authentication request having a user identifier which is distinct from the user identifier of the authentication request. When performing the adaptive authentication operation on the other authentication request, the operation will match an entry having an identifier which matches the user identifier of the other authentication request but which is distinct from the particular entry. At step 110, the method will perform the adaptive authentication operation on the authentication request 11. The operation performed by the risk engine 8 will include matching the user identifier of the authentication request 11 with an identifier of a particular entry of the database. It should be appreciated from the foregoing that the database 16 comprises a set of entries with each entry comprising a user identifier and corresponding user data. In some cases, the database 16 can comprise one or more entries for a user. For example, the database can have entries corresponding to time intervals. Therefore, the database 16 can in some embodiments have one entry for each time interval. The adaptive authentication operation performed 110 by the risk engine 8 also includes generating an authentication result based on the analysis. The risk engine 8 will generate the authentication result 17 based on a set of Bayesian weights, each of which corresponds to an attribute associated with the current user data of the authentication request 11. It should be further understood that the authentication result 17 will also be sent by the adaptive authentication device 14 to the authentication requestor 18. The result 17 can dictate whether the user authentication is approved or rejected (permitting/denying the other network attach request based on the machine learning model). See column 5, line 29 to column 6, line 51.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the well-known technique of connection request authentication via a machine learning model of D3 in the well-known wireless system of D1. One of ordinary skill in the art before the effective filing date of the invention would have implemented the well-known technique in the well-known system to improve authentication speed and security for conventional key-based authentication mechanisms for high-end devices with enough capacity and compute capability.
Regarding claim 20, the primary reference further teaches wherein the machine learning model is a pattern recognition mode (Referring to Figures 5-8, The term “machine learning” or “ML” refers to the use of computer systems implementing algorithms and/or statistical models to perform a specific tasks) without using explicit instructions but instead relying on patterns and inferences. ML algorithms build or estimate mathematical model(s) (referred to as “ML models” or the like) based on sample data (referred to as “training data,” “model training information,” or the like) to make predictions or decisions without being explicitly programmed to perform such tasks. See paragraph 0094.)
Allowable Subject Matter
Claims 13 and 14 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant's arguments filed 20 January 2026 have been fully considered but they are not persuasive.
On page 10 of the remarks, regarding claim 1, the applicant argues D1 and D2 do not teach permitting, by the device, the network attach request or the radio resource control request based on the machine learning model determining that the network attach request or the radio resource control request is legitimate and secure. The Examiner respectfully disagrees. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). The claimed invention is unpatentable over D1 in view of D3. D3 teaches the application of a machine learning model based upon a network attach request and determining whether the network attach request is secure. D3 teaches a request for a VPN connection (a network attach request) determined by the adaptive authentication system. See column 64 to column 8, line 22. The adaptive authentication system 13 will be constructed and arranged to perform an unsupervised machine learning operation on the authentication request 11. For example, the machine learning engine 7 in the adaptive authentication device 14 can perform the unsupervised machine learning operation (processing the network attach request with a machine learning model). At step 105, the method will receive the authentication request 11 at the adaptive authentication system 13. The request 11 will comprise a user identifier and user data. It should be understood that a user identifier can be any entity participating in the event such as a user or an IP; such an entity contains, for example, sub entities with which the entity interacts (e.g., payees, devices, IP addresses, etc.). At step 110, the method will perform the adaptive authentication operation on the authentication request 11. The operation performed by the risk engine 8 will include matching the user identifier of the authentication request 11 with an identifier of a particular entry of the database. The risk engine 8 will generate the authentication result 17 based on a set of Bayesian weights, each of which corresponds to an attribute associated with the current user data of the authentication request 11. It should be further understood that the authentication result 17 will also be sent by the adaptive authentication device 14 to the authentication requestor 18. The result 17 can dictate whether the user authentication is approved or rejected (permitting the network attach request based on the machine learning model/the request is legitimate and secure). See column 5, line 29 to column 6, line 51. D3 teaches the adaptive authentication system 13 will be constructed and arranged to perform an unsupervised machine learning operation on the authentication request 11. In this manner, D3 teaches processing the request with a machine learning model to determine whether the network request is secure and permitting the request when it is legitimate and secure. On page 12 of the remarks, regarding claims 5-7, 11, 12, and 15-20 the Applicant argues the prior art does not teach the claimed invention for the same reasons stated above. The Examiner disagrees for the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Mueck (US 2022/0038902 A1) - Technologies for cyber security and radio equipment supporting certain features ensuring protection from fraud, and testing interfaces related to reconfigurable radio equipment. Other embodiments may be described and/or claimed.
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 DONALD L MILLS whose telephone number is (571)272-3094. The examiner can normally be reached Monday through Friday from 9-5 PM EST.
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, Yemane Mesfin can be reached at 571-272-3927. 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.
DONALD L. MILLS
Primary Examiner
Art Unit 2462
/Donald L Mills/ Primary Examiner, Art Unit 2462
Prosecution Insights