Methodology for applying federated machine learning to customer profile insights generation 5 and distribution

Abstract

The present patent provides a network edge distributed system for generating customer profile insights. With this approach, user data is maintained at the network edge, as well as the ML models responsible for generating customer insights. The insights produced by the ML models deployed at the edge are maintained at the edge and replicated at the central system to guarantee an in-time delivery to the consumers. To increase the Distributed Cognitive User Profiling system are used deployment density criteria of local systems at the network edge, as well as the users' assignment to each local edge system.

Description

[0001] DESCRIPTION

[0002] METHODOLOGY FOR APPLYING FEDERATED MACHINE LEARNING TO CUSTOMER PROFILE INSIGHTS GENERATION AND DISTRIBUTION

[0003] FIELD OF THE INVENTION

[0004] The present invention is enclosed in the field of Distributed Cognitive User Profiling (DCUP) systems. In particular, the present invention relates to a group of methods for applying federated Machine Learning (ML) to user profile insights generation and distribution.

[0005] PRIOR ART

[0006] The mechanisms for generating insights through ML techniques are totally dependent on the existence of data. Currently, these techniques are used to generate customer profile insights centrally, i.e., in the core of a telecommunications operator's network. Therefore, for ML models to be generated, customer data must also flow into the network core. In this way, we are dealing with a centralized ML paradigm, where models and data live in the core of the network.

[0007] From a functional point of view, the first step is the centralized training of ML models. Here, data from millions of users of the Digital Service Provider (DSP) is transported to the core of the operator's network and persisted. The ML model is then trained using the user data that has been collected. Once the user profile insights model has been generated, it is deployed centrally in the network core.

[0008] At this point we move forward to the second step, which consists of the ML model generating customer profile insights using the customers data that is centrally collected. The insights generated by the ML model are also stored on a central storage server, such as the users' raw data.

[0009] Finally, once the ML model has been trained and the insights have been generated, we move to the third step, which consists of consuming the insights generated by the ML models. The applications / platforms that consume the insights resulting from the ML models can be located at the core network or on its peripheries. If these platforms are at the core network, the process of consuming ML insights is straightforward and fast. Otherwise, since the request must travel from the edge to the core of the network, obtaining the insights will take considerably longer. PROBLEM TO BE SOLVED

[0010] The traditional approach based on a centralized deployment of the Cognitive User Profiling (CUP) services platform in a digital service provider's architecture raises critical challenges that may jeopardize its use and, above all, the expected impact on the business value-chain. The following paragraphs depict the three main impacts that a centralized deployment of this platform poses.

[0011] The first impact, and certainly one of the most relevant, is the impact on the communications network of the DSP. CUP services platform core is based on ML profiling models, which require a large amount of input data to be executed and produce the expected profiling insights. Additionally, it is expected that the ML-based profiling models will have to be executed with high frequency to update and optimize the customer profile dimensions that are being inferred. Therefore, huge amounts of data will have to circulate from the customer devices or from the access network systems towards the CUP services platform located in the core network, putting a lot of pressure on the operator's network and, ultimately, even compromising other services that are being provided.

[0012] The second impact identified is related to the real-time generation of customer profiling insights. Transporting the required input data towards the ML-based profiling models running on the CUP services platform, located in the core network, is very time-consuming. Therefore, in scenarios that require real-time predictions and / or recommendations generation, this delay can compromise the use of the insight and may impact the quality of the user experience. An example is the TV content viewing recommendations. In this case, whenever a customer finish viewing a content, a personalized viewing recommendation must be delivered in real-time. This means that a viewing recommendation request must reach the CUP services platform and, subsequently, the ML-based model is executed and produces the recommendation. This must be achieved in real-time, which is very hard to reach with a centralized platform.

[0013] The third impact identified is related to security violation risk. The CUP services platform contains very sensitive customer data that must be carefully protected. Centralizing all the customer profiling information in a single location can be very risky, constituting a threat in terms of data confidentiality and integrity. Even ensuring adequate technical measures to protect data, in case of a successful cyber-attack to the platform, the probability of compromising the profiling data of all Customer base that is centralized is very high. SUMMARY OF THE INVENTION

[0014] Cognitive User Profiling (CUP) services are currently being designed and developed to provide an advanced and unified customer profile data foundation, thus allowing the exploration of business scenarios. These services, agnostic to the vertical industries and areas, can run production-ready ML Models or analytical processes and expose a set of profiling insights to other (consumer) systems. For example, marketing automation platforms will consume the CUP services to incentivize customers with fully personalized marketing campaigns. Another example is customer care platforms, which will be able to use the advanced customer knowledge provided by CUP services to improve the customer experience in call centers. Nevertheless, the CUP services are being prepared and executed centrally at the core network. This poses challenges related to the data transport across the network, security risks and real-time insights availability.

[0015] The present invention mitigates the identified challenges by distributing the CUP services in the network edge, herein named as Distributed Cognitive User Profiling (DCUP) system. In particular, the present invention relates to a group of methods for applying federated Machine Learning (ML) to user profile insights generation and distribution. This paradigm disrupts the current approach that transports the users' data up to the centralized ML models. Instead, the presented invention keeps the users' data at the network edge and transports the ML models to these data localities. Therefore, the data persistence and processing procedures are handled at the network edge, including the datasets creation for training the ML algorithms and generating the ML models. Moreover, the trained ML models execution for generating customers insights is also ran at the network edges, as well as the persistence of their outcomes. If necessary, the customer insights might also be persisted in the central systems, therefore enabling their consumption in real-time by platforms that are deployed in distinct geographies.

[0016] The decentralization of the CUP services requires a close cooperation between the central and the local systems in all phases of the system lifecycle. The central subsystem behaves as an orchestrator of the local subsystems. For example, the initial decision on where to deploy the local subsystems is governed by the central subsystem and is highly dependent on the amount of predicted produced data by the users. Additionally, the users' assignment to a specific local subsystem is also managed by the central subsystem. This decision is made when the user subscribes a DSP offer, as well as continuously during the users' lifecycle. Since the user data production profile might vary with time, the local subsystem assignment might also have to be modified according to the updated user data production profile. This continuous procedure is described in this patent.

[0017] The central subsystem is also the one that decides in which local subsystems the ML models should be distributed for training and execution. This depends on the ML models user data requirements, as well as on the local subsystems resources availability. After distributed for training and execution, the ML models resulting parameters are delivered to the central subsystem, allowing the latter to calibrate the ML models training parameters. In the end, the updated ML model parameters are redistributed by the central subsystem to the local subsystems for optimized training and execution of the models.

[0018] DESCRIPTION OF FIGURES

[0019] Figure 1 illustrates the distributed CUP services solution in the operator's network according to the present invention. The reference signs represent:

[0020] 100 - Core Network;

[0021] 105 - DCUP Central Subsystem (CS) - located at the DSP core network area;

[0022] 110 - DCUP Local Subsystem (LS) - located at the DSP access network area;

[0023] 120 - Access Network Node;

[0024] Figure 2 illustrates the Distributed Cognitive User Profiling (DCUP) System high-level concept according to the present invention. The reference signs represent:

[0025] 200 - Distributed Cognitive User Profiling (DCUP) System;

[0026] 105 - DCUP Central Subsystem (CS) - located at the DSP core network area;

[0027] 110 - DCUP Local Subsystem (LS) - located at the DSP access network area;

[0028] 205 - User Data System;

[0029] Figure 3 illustrates the DCUP CS and LSs according to the present invention. The reference signs represent:

[0030] 200 - Distributed Cognitive User Profiling (DCUP) System;

[0031] 105 - DCUP Central Subsystem (CS) - located at the DSP core network area;

[0032] 110 - DCUP Local Subsystem (LS) - located at the DSP access network area;

[0033] 205 - User Data System;

[0034] 300 - User Assignment Module;

[0035] 305 - ML Models Central Coordinator Module; 310 - User Profile Insights Central Data Module;

[0036] 315 - User Local Data Module;

[0037] 320 - ML Models Local Coordinator Module;

[0038] 325 - User Profile Insights Local Data Module.

[0039] Figure 4 illustrates the DCUP LSs resources announcement according to the present invention.

[0040] The reference signs represent:

[0041] 200 - Distributed Cognitive User Profiling (DCUP) System;

[0042] 105 - DCUP Central Subsystem (CS) - located at the DSP core network area;

[0043] 110 - DCUP Local Subsystem (LS) - located at the DSP access network area;

[0044] 205 - User Data System;

[0045] 300 - User Assignment Module;

[0046] 305 - ML Models Central Coordinator Module;

[0047] 310 - User Profile Insights Central Data Module;

[0048] 315 - User Local Data Module;

[0049] 320 - ML Models Local Coordinator Module;

[0050] 325 - User Profile Insights Local Data Module.

[0051] 400 - DCUP LS Available Resources.

[0052] Figure 5 illustrates the users' assignment to the Home DCUP LS according to the present invention. The reference signs represent:

[0053] 200 - Distributed Cognitive User Profiling (DCUP) System;

[0054] 105 - DCUP Central Subsystem (CS) - located at the DSP core network area;

[0055] 110 - DCUP Local Subsystem (LS) - located at the DSP access network area;

[0056] 205 - User Data System;

[0057] 300 - User Assignment Module;

[0058] 305 - ML Models Central Coordinator Module;

[0059] 310 - User Profile Insights Central Data Module;

[0060] 315 - User Local Data Module;

[0061] 320 - ML Models Local Coordinator Module;

[0062] 325 - User Profile Insights Local Data Module.

[0063] 500 - User Home DCUP LS Assignment. Figure 6 illustrates the user profiling ML models distribution and update according to the present invention. The reference signs represent:

[0064] 200 - Distributed Cognitive User Profiling (DCUP) System;

[0065] 105 - DCUP Central Subsystem (CS) - located at the DSP core network area;

[0066] 110 - DCUP Local Subsystem (LS) - located at the DSP access network area;

[0067] 205 - User Data System;

[0068] 300 - User Assignment Module;

[0069] 305 - ML Models Central Coordinator Module;

[0070] 310 - User Profile Insights Central Data Module;

[0071] 315 - User Local Data Module;

[0072] 320 - ML Models Local Coordinator Module;

[0073] 325 - User Profile Insights Local Data Module.

[0074] 600 - Initial ML Model delivery to DCUP LS;

[0075] 605 - ML Model parameters sharing with DCUP CS;

[0076] 610 - Calibrated ML Model delivery to DCUP LS;

[0077] 615 - User information delivery to DCUP LS.

[0078] Figure 7 illustrates the user profiling ML models insights according to the present invention. The reference signs represent:

[0079] 200 - Distributed Cognitive User Profiling (DCUP) System;

[0080] 105 - DCUP Central Subsystem (CS) - located at the DSP core network area;

[0081] 110 - DCUP Local Subsystem (LS) - located at the DSP access network area;

[0082] 205 - User Data System;

[0083] 300 - User Assignment Module;

[0084] 305 - ML Models Central Coordinator Module;

[0085] 310 - User Profile Insights Central Data Module;

[0086] 315 - User Local Data Module;

[0087] 320 - ML Models Local Coordinator Module;

[0088] 325 - User Profile Insights Local Data Module.

[0089] 700 - User profiling ML Model outputs (insights) sharing with DCUP CS.

[0090] Figure 8 illustrates the DCUP system according to the present invention. The reference signs represent:

[0091] 200 - Distributed Cognitive User Profiling (DCUP) System; 105 - DCUP Central Subsystem (CS) - located at the DSP core network area;

[0092] 110 - DCUP Local Subsystem (LS) - located at the DSP access network area;

[0093] 300 - User Assignment Module;

[0094] 305 - ML Models Central Coordinator Module;

[0095] 310 - User Profile Insights Central Data Module;

[0096] 315 - User Local Data Module;

[0097] 320 - ML Models Local Coordinator Module;

[0098] 325 - User Profile Insights Local Data Module.

[0099] 800 - User provision information;

[0100] 805 - User profiling ML Models information;

[0101] 810 - user behaviour information;

[0102] 815 - user profile insights information;

[0103] 820 - DCUP management information.

[0104] Figure 9 depicts a flow chart describing a method for the DCUP LSs deployment according to the present invention. The reference signs represent:

[0105] S900 - Orchestrating DCUP LSs deployment;

[0106] S905 - Generating DCUP LSs deployment recommendation ML insight;

[0107] S910 - Evaluating the DCUP LSs deployment update necessity.

[0108] Figure 10 depicts a flow chart describing a method for the DCUP LSs resources announcement according to the present invention. The reference signs represent:

[0109] S1000 - DCUP LS deployment announced to DCUP CS;

[0110] S1005 - Evaluating if the DCUP LS resources are below the preconfigured threshold;

[0111] S1010 - DCUP LS notifies DCUP CS about its resources availability;

[0112] S1015 - Evaluating if the DCUP LS resources verification period is completed.

[0113] Figure 11 depicts a flow chart describing a method for the DCUP LSs resources announcement according to the present invention. The reference signs represent:

[0114] SHOO - New user provisioned in DCUP CS;

[0115] S1105 - Evaluate if user address is available;

[0116] S1110 - Assign the user to the DCUP LS associated with the user home address;

[0117] S1115 - Assign the user to the DCUP LS in which initial traffic was originated;

[0118] S1120 - Generate user data production prediction insight at Home DCUP LS; S1125 - Select the top-3 user data producers DCUP LSs as Candidate Home DCUP LSs;

[0119] S1130 - Evaluate if the data produced at the Candidate DCUP LSs is higher than the data produced at the Home DCUP LS;

[0120] S1135 - Higher data production Candidate DCUP LSs sent to DCUP CS;

[0121] S1140 - User Home DCUP LS is not updated;

[0122] S1145 - Evaluate if any of the selected Candidate DCUP LSs is available to receive the user data;

[0123] S1150 - Candidate DCUP LS is elected as the new Home CCP LS;

[0124] S1155 - DCUP CS notifies the new Home DCUP LS.

[0125] Figure 12 depicts a flow chart describing a method for the user data flow according to the present invention. The reference signs represent:

[0126] S1200 - New user data produced;

[0127] S1205- User data persisted in Home DCUP LS.

[0128] Figure 13 depicts a flow chart describing a method for the user profiling ML model distribution for training according to the present invention. The reference signs represent:

[0129] S1300 - New ML model requested to DCUP CS (105);

[0130] S1305 - DCUP CS (105) selects the DCUP LSs (110)in which the model should be trained;

[0131] S1310 - Evaluate if Candidate DCUP LSs have sufficient available resources;

[0132] S1315 - Deliver initial ML model to DCUP LS;

[0133] S1320 - Decide on fallback plan to train the ML model (Figure 13);

[0134] S1325 - DCUP LS starts training the ML model locally.

[0135] Figure 14 depicts a flow chart describing a method for the ML model distribution fallback according to the present invention. The reference signs represent:

[0136] S1400 - Evaluate if it is possible to schedule the ML model training in another moment at the DCUP LS;

[0137] S1405 - Wait for scheduler opportunity;

[0138] S1410 - Evaluate if it is possible to increase the DCUP LS resources;

[0139] S1415 - Increase DCUP LS resources;

[0140] S1420 - Evaluate if it is possible to review the ML model training priority;

[0141] S1425 - Review ML models priority list;

[0142] S1430 - Wait until resources are available;

[0143] S1435 - Deliver ML model for training. Figure 15 depicts a flow chart describing a method for the ML model training in federative mode at the DCUP LS according to the present invention. The reference signs represent:

[0144] S1500 - ML model delivered to DCUP LS;

[0145] S1505 - Evaluate if user data is already available;

[0146] S1510 - Train the ML model;

[0147] S1515 - Wait for data to be collected;

[0148] S1520 - Evaluate if the updated ML model parameters are different from the previous one;

[0149] S1525 - Share updated ML model parameters with the DCUP CS.

[0150] Figure 16 depicts a flow chart describing a method for the DCUP CS involvement in the ML model training in federative mode according to the present invention. The reference signs represent: S1600 - Updated ML model parameters received from DCUP LSs;

[0151] S1605 - DCUP CS creates an updated ML model based on the received ML models parameters;

[0152] S1610 - Evaluate if the updated ML Model parameters differ from the previous ones sent by DCUP CS;

[0153] S1615 - Persist updated ML model parameters;

[0154] S1620 - DCUP CS distributes the updated ML model to the DCUP LSs.

[0155] Figure 17 depicts a flow chart describing a method for the ML models execution at DCUP LS according to the present invention. The reference signs represent:

[0156] S1700 - (Initial or updated) ML model available at DCUP LS;

[0157] S1705 - Execute ML model (either scheduled based or data-triggered based);

[0158] S1710 - Persist ML model outputs (insights) in DCUP LS.

[0159] Figure 18 depicts a flow chart describing a method for sharing the ML models insights with the DCUP CS according to the present invention. The reference signs represent:

[0160] S1800 - ML model insights persisted in DCUP LS;

[0161] S1805 - Evaluate if the user has a mobility profile pattern;

[0162] S1810 - Evaluate if the ML model insights consumption propensity in DCUP LSs is higher than the configured threshold;

[0163] S1815 - Share ML model insights with DCUP CS. Figure 19 depicts a flow chart describing a method for consuming the ML models insights at the DCUP CS according to the present invention. The reference signs represent:

[0164] S1900 - Consumer at DCUP CS requires user insights;

[0165] S1905 - Evaluate if the required user insights are available at DCUP CS;

[0166] S1910 - Consume user insights from the user Home DCUP LS;

[0167] S1915 - Consume user insights from DCUP CS.

[0168] Figure 20 depicts a flow chart describing a method for consuming the ML models insights at the DCUP LS according to the present invention. The reference signs represent:

[0169] S2000 - Consumer at DCUP LS requires user insights;

[0170] S2005 - Evaluate if the consumer is at Home DCUP LS;

[0171] S2010 - Consume user insights directly from the DCUP LS;

[0172] S2015 - Request user insights from DCUP CS;

[0173] S2020 - Evaluate if user insights are available at DCUP CS;

[0174] S2025 - Consume user insights from DCUP CS;

[0175] S2030 - DCUP CS informs DCUP LS with the Home DCUP LS to obtain user insights;

[0176] S2035 - Consume user insights from Home DCUP LS.

[0177] DETAILED DESCRIPTION

[0178] The main objective of this invention is to overcome the issues presented above and related to a centralized CUP services platform approach. For this purpose, a solution with distributed CUP services across the edge of the operator's network, herein named as Distributed Cognitive User Profiling (DCUP) system, is proposed.

[0179] The operator network is segmented into two major areas:

[0180] 1. Access network nodes through which end users obtain connectivity (fixed and / or mobile);

[0181] 2. Core network in which the service platforms, network management platforms and network control platforms are deployed.

[0182] The strategy described in this patent is to distribute the CUP services in the network edge nodes. As illustrated in Figure 1, CUP services are no longer centralized in the operator's network (100) core but distributed throughout the network edge. In Figure 1, as an example, is depicted one DCUP instance deployed in the core network, named as DCUP Central Subsystem (CS) (105), and DCUP instances located in the access network nodes (fixed and mobile) named as DCUP Local Subsystems (LSs) (110).

[0183] Distributing the CUP services across the network edge will allow the profiling services to be consumed from these instances without having to reach the instance centrally deployed at the core network. Thus, it will not be necessary to transport the data to the central CUP instance, and consequently, the data traffic flowing through the network will decrease considerably.

[0184] Besides reducing the network pressure as described in the previous paragraph, deploying the CUP services platform in the edge enables real-time scenarios. Given the proximity of the CUP services and the profiling consuming information platform (e.g., TV content platforms), it is expected that the request / response interactions with the CUP services platform are faster and therefore enable the exploitation of real-time business scenarios.

[0185] Finally, distributing the customer profile information across the various network nodes will reduce the cyber-attacks impact on sensitive profiling data. That is, if the data of one CUP instance located at the edge is compromised, the profiling data of the other instances will remain safeguarded.

[0186] As illustrated in Figure 2, the DCUP System (200) consists of a central subsystem (DCUP CS) (105) at the core of the network and several local subsystems (DCUP LSs) (110) at the edge of the network. Users (205) are associated with a single DCUP LS at each moment, according to a set of criteria that will be described in the following paragraphs.

[0187] Thus, each DCUP LS (110) will have to store the user's data associated with it (User Local Data Module) (315), without it ever being transferred to the Central Server. This data is used locally to train customer profiling ML models (ML Models Local Coordinator Module) (320). The insights generated by the ML models are stored locally (User Profile Insights Local Data Module) (325), and are also partially shared with DCUP CS (105), according to a set of criteria and methodology that will be thoroughly discussed later. Figure 3 illustrates the CCP distributed system internal architecture.

[0188] From the DCUP CS (105) point of view, its main function is to coordinate the federated training of ML models (305), i.e., to deliver an initial ML model that is subsequently optimized based on the feedback generated in each DCUP LS. In addition, the DCUP CS (105) also includes, albeit only partially and according to needs, the insights generated by the ML models (310) in the DCUP LSs (110).

[0189] In short, the aim is always to keep raw customer data, train the ML models and persist the insights in the DCUP LSs (110). The DCUP CS (105) will essentially be responsible for coordinating the ML models federated network, as well as persisting some of the insights generated locally.

[0190] One of the main reasons for distributing CUP nodes along the edge of the network is to avoid data being transported to the core of the network, i.e., to keep the data as close to the end user as possible. Because of the persistence of the data at the edge of the network, the training of the ML models for customer profiling insights will also have to run on the local nodes (and not on the central node). Furthermore, the nodes at the edge of the network will also persist the insights produced by the models themselves to be consumed by the client applications / platforms.

[0191] Thus, the decision on the best place to deploy DCUP LSs, as well as their size, depends on all the factors mentioned above (amount of raw data produced by the end-users, ML model load and amount of insights produced). Given the complexity inherent in this decision, it is necessary to create an ML model to recommend the edge placement and sizing of each of the DCUP LSs (110), as illustrated in Figure 4. This model will take as input the amount and type of data generated by users, the nature of the ML models that will be trained and run, as well as the amount and type of insights that will be stored.

[0192] Once the DCUP LS deploy is completed, it announces itself to the DCUP CS (105), indicating its available infrastructural resources (400). From the DCUP CS (105) point of view, it is essential to know the available resources in each DCUP LS (110) to take decisions about which one should receive the ML models. DCUP LSs periodically check and announce the available resources (400) to the central node of the federated network (DCUP CS (105)). This ensures that the DCUP CS has information about the available resources in each one of the DCUP LSs in the federated network. This is illustrated in Figure 4.

[0193] The main motivation for distributing CUP across local systems located at the network edge is to persist user data as close to them as possible. This will save network resources, guarantee greater security / privacy and speed up the delivery of profiling insights to the consumer platforms that need this information. Thus, the criteria for assigning a user to a specific DCUP LS is the location where the user produces the greatest amount of raw data, such as at home, at work or on the move.

[0194] Initially, i.e., when the user subscribes the service, since there is still no information on where the user will produce more data, the criteria for assigning the DCUP LS (110) depends on the service subscription / billing address, if available. If this information is not available, the user is assigned to the DCUP LS (110) in which its initial traffic was originated.

[0195] Having knowledge about the service subscription / billing address depends on the type of subscribed service. Generally, the subscribed service can be classified in two main categories:

[0196] • Post-paid: the customer subscribes to the service and is charged after using it, usually at the end of the month. The information provided in the subscription process is, among other things, the billing address. Typical examples of post-paid services are High Speed Internet (HSI), fixed telephone, mobile telephone and television service (IPTV);

[0197] • Pre-paid: the customer pays for the service in advance and only after that starts using it. In this case, depending on the legal requirements defined by the country in which the service is being subscribed to, it may not be necessary to provide any personal information. An example of a prepaid service is the mobile service. In this case, the customer can buy a mobile service card with a predefined balance and start using it whenever they want. The first use of the card can even take place in a geography that is substantially different from the place where the prepaid card was purchased. In this case, information about the user's address is not provided.

[0198] Therefore, the DCUP LS assignment criteria is as follows:

[0199] • Post-paid service: the user is associated with the DCUP LS containing their service subscription address;

[0200] • Pre-paid service: the user is associated with the DCUP LS from which the initial traffic originated.

[0201] The initial DCUP LS assigned to a specific user is named as Home DCUP LS (500). The user assignment process is illustrated in Figure 5.

[0202] Once the user is consuming services from the DSP, it starts producing data and, in parallel, move along the available access networks. During this process, it will traverse several DCUP LSs (110), named as Foreign DCUP LSs. After a certain period, depending on the user mobility and data production patterns, the assigned Home DCUP LS of the user is revisited and, if necessary, the user is assigned to a different Home DCUP LS. To achieve this, an ML-based model will be trained and executed on the Home DCUP LS to generate an insight about which DCUP LS is the most appropriate to assign to the user. Figure 5 illustrates this behaviour.

[0203] This ML model uses as input information, among other parameters, the amount of data produced by the user in each DCUP LS (Home and / or Foreign), as well as user mobility information across the various DCUP LSs. This will make it possible to identify in which DCUP LS the user is most likely to be producing more data during a given period.

[0204] This insight is produced in the user's Home DCUP LS. If the most likely DCUP LS in which the user will produce more data is the same as the Home DCUP LS, then the assignment remains identical. If the inferred DCUP LS is different from the Home DCUP LS, then this insight is sent to the DCUP CS. The continuous DCUP LS assignment to a specific user is always to optimize the flow of raw data through the network.

[0205] From the moment the user subscribes to an operator's service, information will start being produced. In other words, data related to the user begins to be produced and stored in the DCUP LSs (615).

[0206] The user can be within the geographical scope of the Home DCUP LS or be visiting a Foreign DCUP LS. In both scenarios, the data produced by the user will be stored in the Home DCUP LS (615). However, even though the data resides in the Home DCUP LS, in the first case (user @Home DCUP LS), given the proximity to the Home DCUP LS, the journey of the data will be short, with little impact on the network. In the second case, on the other hand, the data is being produced in a Foreign DCUP LS area and its transfer to the Home DCUP LS will have a significant impact on the network, pressurizing it with a large amount of traffic.

[0207] Therefore, and as mentioned above, instead of crystallizing the definition of the Home DCUP LS at the initial moment, its selection should be continually re-evaluated through ML mechanisms so that the Home DCUP LS is most of the time the local node where the user produces the greatest amount of raw data.

[0208] When DCUP LS nodes connect, they announce themselves to the DCUP CS and become associated with the DCUP system. For each ML model to be distributed by the DCUP CS for training and execution in the federated network, the first decision to be made is to which local node(s) (DCUP LSs) the ML model should be delivered. This decision depends on the existence of input data required by the ML model at the DCUP LS, as well as the probability of the generated output (insights) to be consumed in the DCUP LS geography. The DCUP CS includes the algorithm needed to decide which DCUP LSs a given model should be trained and run on.

[0209] Once the candidate DCUP LSs have been selected for training the ML models, the next step is to check if they have sufficient resources for this purpose. As the DCUP CS is continuously receiving information about the resources available in each DCUP LS, it decides on whether there is infrastructural capacity or not. If resources are available, an initial version of the ML model is delivered (600) to the DCUP LS for training. This scenario is illustrated in Figure 6.

[0210] The DCUP LS receives the initial ML model (600) and starts training it using the user data that has been stored so far. Once trained, the resulting model is analyzed, in particular the resulting parameterizations. If these are different from the initial model shared by the DCUP CS, they are shared with the central node (605), as illustrated in Figure 5. This process is repeated for all the LSs that train this ML model. Based on the parameterizations received from all the DCUP LSs for this model, the DCUP CS will calibrate the parameterizations and share these with the local federated nodes (6 10) so that they can re-train the model. This process is continuously repeated.

[0211] If infrastructural resources are not available in the DCUP LS to train the ML model, the DCUP CS must apply a fallback strategy. Firstly, it checks whether it is possible to schedule the ML model training for later, for example when other models have completed their tasks and freed up resources. If the first mitigation action is not possible, the second step is to request an increase in computing resources on the local node. Finally, if none of the previous actions work, the DCUP CS will have to review the prioritization list of the ML models being trained on the local nodes. If one or more of these ML models have a lower priority, then they should be removed, thus freeing up the resources needed for the new ML model to train on the local node. If the ML models running on the nodes have higher priority, then this ML model will have to wait until resources are available. This decision mechanism is made on a model-by-model basis by the DCUP CS.

[0212] Once trained, the models are run in the DCUP LS and generate customer profiling insights. The insights are always stored in the local nodes (DCUP LS). Whether the insights generated are shared with the central node depends on whether they need to be consumed outside the DCUP LS in which they were generated. To decide which insights are shared with the central node, the user mobility profile must be considered. Users who move around frequently will also consume the insights when they are on the move, outside the radius of action of the Home DCUP LS, and in this situation, the insights should be shared with the central node (350). Figure 6 illustrates this scenario.

[0213] Regarding the consumption of insights, if they are requested by platforms / applications / users that fall within the scope of the Home DCUP LS, it will be relatively fast and simple. As the insights are always stored locally (DCUP LS), their consumption will be quick.

[0214] On the other hand, if the insights are being requested by consumers outside the scope of the Home DCUP LS, then it will have to be consumed directly from the DCUP CS. Remember that at an earlier stage, i.e., when the insights were produced, they were stored locally and those that were more likely to be consumed outside the Home DCUP LS were also stored centrally. Therefore, in principle, the insights should be available in DCUP CS when the user is in a Foreign DCUP LS. However, in some situations, for example if the user does not have a mobility profile, the insights might not be replicated in the central node, but only exist in the Home DCUP LS. In this scenario, the DCUP CS will inform the Foreign DCUP LS that it does not have the data centrally and that it should be collected directly from the Home DCUP LS. This scenario is more time-consuming to obtain insights because of the signaling exchange that must take place between the Foreign DCUP LS and the DCUP CS and because the data must be fetched directly from the Home DCUP LS. However, this scenario is less likely to happen.

[0215] DESCRIPTION OF THE EMBODIMENTS

[0216] In the following an embodiment of the present invention being related to a distributed cognitive customer profiling system apparatus will be described with respect to Figure 8.

[0217] Figure 8 shows a distributed cognitive customer profiling system (200) to obtain customer profiling insights information at each moment. The system receives the following input information:

[0218] 1. User Behaviour Information (810): mobile phone usage events (calls, SMS, Data), location updates, online / digital shopping, mobile top-ups, live and non-live IP TV visualizations, etc. 2. User Provision Information (800): digital service provider pre-paid and / or post-paid services subscription, add-ons subscription, etc.

[0219] 3. User Profiling ML Models (805): user profiling ML models that should be created and executed at the DCUP system.

[0220] Within the Distributed Cognitive User Profiling (DCUP) system (200), two subsystems are defined - the DCUP Central Subsystem (CS) (105) and the DCUP Local Subsystem (LS) (110).

[0221] The DCUP CS (105) main responsibility is to coordinate the overall distributed system integrity and coherence across the several DCUP LSs. The following inner modules are defined:

[0222] 1. User Assignment Module (300): responsible for continuously allocating the end-users to a specific DCUP LS;

[0223] 2. ML Models Central Coordinator Module (305): responsible for initial ML models generation, as well as its allocation and distribution to the DCUP LSs (110). It is also responsible for the continuous calibration of the running user profiling ML models at the DCUP LSs (110);

[0224] 3. User Profile Insights Central Data Module (310): responsible for persisting the users profile insights that need to be centrally available;

[0225] The DCUP LSs (110) main responsibility is to locally train and execute the allocated user profiling ML models with the persisted user data. The following inner modules are defined:

[0226] 1. User Local Data Module (315): persists the user raw data locally;

[0227] 2. ML Models Local Coordinator Module (320): responsible for user profiling ML models training and execution. It is also responsible for continuously sharing the ML models parameters with the DCUP CS;

[0228] 3. User Profile Insights Local Data Module (325): responsible for persisting the local users profile insights;

[0229] In the following, an embodiment of the present invention being related to the DCUP LSs deployment method will be described with respect to Figure 9.

[0230] Figure 9 shows a flow chart describing a method for the DCUP LSs (110) deployment according to this invention. The following steps are described in this method: • Initial step S900 - Orchestrate the DCUP LSs (110) deployment according to the population density;

[0231] • Step S905 - Generate a recommendation insight for the DCUP LSs (110) deployment (assuming the required ML model was previously trained);

[0232] • Step S910 - Evaluate if an update to the DCUP LSs (110) deployment is required. If required, return to step S900, else return back to step S905.

[0233] In the following, an embodiment of the present invention being related to the DCUP LSs resources management method will be described with respect to Figure 10.

[0234] Figure 10 shows a flow chart describing a method for the DCUP LSs resources management according to this invention. The following steps are described in this method:

[0235] • Initial step S1000 - Announce the DCUP LS (110) deployment to DCUP CS (105), including the available resources;

[0236] • Step S1005 - Evaluate if the DCUP LS (110) available resources are lower than a preconfigured threshold. If lower, continue to step S1010 else continue to the step S1015;

[0237] • Step S1010 - DCUP LS notifies the DCUP CS (105) about the resources availability;

[0238] • Step S1015 - Evaluate if the DCUP LS (110) resources verification period is completed. If completed, return to step S1010 else return back to step S1005.

[0239] In the following, an embodiment of the present invention being related to the DCUP LS user assignment method will be described with respect to Figure 11.

[0240] Figure 11 shows a flow chart describing a method for the DCUP LS user assignment according to this invention. The following steps are described in this method:

[0241] • Initial step SHOO - A new user is provisioned in the DCUP CS;

[0242] • Step S1105 - Evaluate if the provisioned user address is available. If available, continue to step (S1110) else continue to step (S1115);

[0243] • Step S1115 - Assign the user to the DCUP LS in which the initial traffic was originated;

[0244] • Step S1110 - Assign the user to the DCUP LS associated with the user home / billing address;

[0245] • Step S1120 - Generate user data production prediction insight at Home DCUP LS; • Step S1125 - Elect the top-3 DCUP LSs in which the user data production probability is higher as Candidate Home DCUP LSs;

[0246] • Step S1130 - Evaluate if data production at the Candidate DCUP LSs is higher than the data production at Home DCUP LS. If higher, continue to step (S1135) else continue to step (S1140);

[0247] • Step S1135 - Notify the DCUP CS with the higher data production Candidate DCUP LSs;

[0248] • Step S1140 - If data production at Candidate Home DCUP LSs it lower, the user Home DCUP LS is not updated;

[0249] • Step S1145 - Evaluate if Candidate Home DCUP LSs are available to receive the user. If available, continue to step (S1150), else return to step (S1120);

[0250] • Step S1150 - Candidate DCUP LS is elected as the new Home CCP LS;

[0251] • Step S1155 - DCUP CS notifies the new Home DCUP LS.

[0252] In the following, an embodiment of the present invention being related to the user data flow method will be described with respect to Figure 12.

[0253] Figure 12 shows a flow chart describing a method for the user data flow according to this invention. The following steps are described in this method:

[0254] • Initial step S1200 - New user-related data is produced by the user;

[0255] • Step S1205 - Produced user data stored at Home DCUP LS.

[0256] In the following, an embodiment of the present invention being related to the user profiling ML model distribution for training method will be described with respect to Figure 13.

[0257] Figure 13 shows a flow chart describing a method for the user profiling ML model distribution for training according to this invention. The following steps are described in this method:

[0258] • Initial step S1300 - New ML model requested to DCUP CS;

[0259] • Step S1305 - DCUP CS selects the DCUP LSs in which the model should be trained;

[0260] • Step S1310 - Evaluate if the Candidate DCUP LSs have sufficient available resources to train the ML model. If sufficient, continue to step (S1315) else continue to step (S1320);

[0261] • Step S1315 - Deliver initial ML model to DCUP LSs;

[0262] • Step S1320 - Decide on fallback plan to train the ML model;

[0263] • Step S1325 - DCUP LS starts training the ML model locally. In the following, an embodiment of the present invention being related to the user profiling ML model distribution for training method will be described with respect to Figure 14.

[0264] Figure 14 shows a flow chart describing a method for the user profiling ML model distribution fallback according to this invention. The following steps are described in this method:

[0265] • Initial step S1400 - Evaluate if DCUP LS ML model can be scheduled for later training. If can be scheduled, continue to step (S1405) else continue to step (S1410);

[0266] • Step S1405 - Wait for scheduling opportunity;

[0267] • Step S1410 - Evaluate if DCUP LS resources can be increased. If can be increased, continue to step (S1415) else continue to step (S1420);

[0268] • Step S1415 - Increase resources in the DCUP LS;

[0269] • Step S1420 - Evaluate if DCUP ML models list priority can be modified. If can be modified, continue to step (S1425) else continue to step (S1430);

[0270] • Step S1425 - Modify DCUP LS ML models priority list;

[0271] • Step S1430 - Wait until DCUP LS resources are available;

[0272] • Step S1435 - Deliver ML model for training.

[0273] In the following, an embodiment of the present invention being related to the ML model training method in federative mode at DCUP LS will be described with respect to Figure 15.

[0274] Figure 15 shows a flow chart describing a method for the ML model training in federative mode at DCUP LS according to this invention. The following steps are described in this method:

[0275] • Initial step S1500 - Initial user profiling ML model delivered to DCUP LS;

[0276] • Step S1505 - Evaluate if user data is available at DCUP LS. If available, continue to step (S1510) else continue to step (S1515);

[0277] • Step S1510 - Train the ML model with the available user data;

[0278] • Step S1515 - Wait for data to be available at the DCUP LS;

[0279] • Step S1520 - Evaluate if the trained ML model resulting parameters differ from the previous training iteration. If differ, continue to step (S1525) else return to step (S1510);

[0280] • Step S1525 - Share the updated ML model parameters with the DCUP CS.

[0281] In the following, an embodiment of the present invention being related to the ML model training method in federative mode at DCUP CS will be described with respect to Figure 16. Figure 16 shows a flow chart describing a method for the ML model training in federative mode at DCUP CS according to this invention. The following steps are described in this method:

[0282] • Initial step S1600 - Updated ML model parameters received from DCUP LSs;

[0283] • Step S1605 - DCUP CS creates an updated ML model based on the received parameters from the several DCUP LSs that are running this ML model;

[0284] • Step S1610 - Evaluate if the updated / calibrated ML model parameters differ from the previous one sent by DCUP CS. If differ, continue to step (S1615) else stop;

[0285] • Step S1615 - Persist the updated ML model parameters;

[0286] • Step S1620 - DCUP CS distributes the updated / calibrated ML Model to the DCUP LSs.

[0287] In the following, an embodiment of the present invention being related to the ML model execution method in federative mode at DCUP LS will be described with respect to Figure 17.

[0288] Figure 17 shows a flow chart describing a method for the ML model execution in federative mode at DCUP LS according to this invention. The following steps are described in this method:

[0289] • Initial step S1700 - Initial or updated ML model available at DCUP LS;

[0290] • Step S1705 - Execute ML model, which can be scheduled based or data-triggered based, depending on the ML model configurations;

[0291] • Step S1710 - Persist ML model outputs (insights) in DCUP LS.

[0292] In the following, an embodiment of the present invention being related to the ML model insights sharing method with the DCUP CS will be described with respect to Figure 18.

[0293] Figure 18 shows a flow chart describing a method for the ML model insights sharing with the DCUP CS according to this invention. The following steps are described in this method:

[0294] • Initial step S1800 - ML model insights persisted in DCUP LS;

[0295] • Step S1805 - Evaluate if user has a mobility profile pattern. If it has, continue to step (S1810) else stop;

[0296] • Step S1810 - Evaluate if ML model insights consumption propensity in DCUP LSs is higher than the configured threshold. If higher, continue to step (S1815) else stop;

[0297] • Step S1815 - Share ML model insights with DCUP CS. In the following, an embodiment of the present invention being related to the ML model insights consumption method at the DCUP CS will be described with respect to Figure 19.

[0298] Figure 19 shows a flow chart describing a method for the ML model insights consumption at the DCUP CS according to this invention. The following steps are described in this method:

[0299] • Initial step S1900 - Consumer at DCUP CS requires user insights;

[0300] • Step S1905 - Evaluate if the requested user insights are available at DCUP CS. If available, continue to step (S1915) else continue to step (S1910);

[0301] • Step S1910 - Consume user insights directly from the DCUP CS;

[0302] • Step S1915 - Consume user insights from the user Home DCUP LS.

[0303] In the following, an embodiment of the present invention being related to the ML model insights consumption method at the DCUP LS will be described with respect to Figure 20.

[0304] Figure 20 shows a flow chart describing a method for the ML model insights consumption at the DCUP LS according to this invention. The following steps are described in this method:

[0305] • Initial step S2000 - Consumer at DCUP LS requires user insights;

[0306] • Step S2005 - Evaluate if consumer is at user Home DCUP LS. If is at Home DUCP LS, continue to step (S2010) else continue to step (S2015);

[0307] • Step S2010 - Consume user insights directly from the DCUP LS;

[0308] • Step S2015 - Request user insights from DCUP CS;

[0309] • Step S2020 - Evaluate if user insights are available at DCUP CS (. If available, continue to step (S2025) else continue to step (S2030);

[0310] • Step S2025 - Consume user insights from DCUP CS;

[0311] • Step S2030 - DCUP informs DCUP LS with the user Home DCUP LS, from which it should obtain user insights;

[0312] • Step S2035 - Consume user insights from home DCUP LS.

Claims

CLAIMS1- A distributed system (200) configured to obtain user profiling insights information at real-time, comprising: several Local Subsystems (LS) (110) comprising processing means for training and executing the allocated Machine Learning (ML) models, persisting the user data, and comprising communication means for receiving information of ML models, user behaviour and registration information, and, wherein an LS is characterized by comprising: a user local data module (315) for persisting user raw data locally; a ML models local coordinator module (320) for training and executing user profiling ML models and sharing their parameters with the CS; and a user profile insights local data module (325) for persisting local user profile insights; a Central Subsystem (CS) (105) comprising processing means to coordinate the overall distributed system integrity and coherence across the several LSs and comprising communication means to receive user registration information, ML models parameters and LSs resources information, and, wherein a LS is characterized by comprising: a user assignment module (300) to continuously allocate users to a specific LS; a ML models central coordinator module (305) to generate initial ML models and to allocate, distribute and continuously calibrate user profiling ML models running on the LSs; and a user profile insights central data module (310) to persist users profile insights centrally.2- A distributed system (200) according to claim 1, wherein the DCUP LS (110) calculates its own infrastructural resources capacity periodically and publishes it to the DCUP CS (105).3- Method for the DCUP Local Subsystem (LS) (110) deployment management, using the distributed system (200) of claims 1 to 2, and comprising the following steps:i. an ML model in DCUP CS (105) analyses information such as the amount of raw data produced by end users, ML model load, and amount of insights produced, in order to generate a recommendation for deploying DCUP LSs (110) on the edge nodes of the network; ii. after generating the recommendation, the DCUP LS (110) deployment orchestration begins and is terminated upon receipt of notification of the completion of the DCUP LS (110) deployment; ill. upon receiving notifications of low DCUP LS (110) resources, the need to update the corresponding DCUP LS (110) is analysed; iv. if it is necessary to update a DCUP LS (110), the DCUP LS (110) update orchestration is performed.4- Method for assigning the DCUP LS (110) to the end user using, using the distributed system (200) of claims 1 to 2, and comprising the following steps: i. new end-user provision information is received and analysed to identify the initial DCUP LS assigned to the end user, known as Home DCUP LS (500); ii. determining whether the end user address is available, in the event the address is available, assign the end user to the DCUP LS associated with the end user address, and in the other case, assign the end user to the DCUP LS on which the initial traffic was originated; ill. a ML model running on the Home DCUP LS (500) generates insights, over a given period, about which DCUP LS (Candidate Home DCUP LS) is the most appropriate to assign to the end user; iv. each Candidate Home DCUP LS with greater data production than the Home DCUP LS is notified to DCUP CS (105) for determining whether a Candidate Home DCUP LS is elected to be the new Home DCUP LS; v. in the event of a new Home DCUP LS is elected, the DCUP CS notifies the respective DCUP LS.5- Method for the user profiling ML model distribution for training, using the distributed system (200) of claims 1 to 2, and comprising the following steps: i. new ML model needs to be distributed for training and execution in the federated network, DCUP CS determines the DCUP LS on which it should be trained and evaluates whether it has available resources;ii. in the event resources are available, the initial ML model is delivered to the respective DCUP LS and training begins locally; ill. in the case there are no resources available, a fallback strategy is applied by scheduling the ML model training for later; iv. in the case it is not possible to schedule for later, resources are increased for starting the ML model training; v. in the event it is not possible to increase resources it modifies ML models running priorities; vi. in the case it is not possible to modify priorities, it waits until resources are available for starting the ML model training.6- Method for the ML model training in federative mode, using the distributed system (200) of claims 1 to 2, and comprising the following steps: i. when user data is available locally in the DCUP LS (110), the ML model is trained with the available user data; ii. in the event the trained ML model resulting parameters are different from the previous training iteration, the updated ML model parameters are sent to DCUP CS; ill. DCUP CS maintains an updated ML model based on parameters received from the various DCUP LSs that are running this ML model; iv. when the parameters of the updated ML model differ from the previous stored base, DCUP CS updated the ML model for the DCUP LSs.7- Method for the ML model insights sharing and consumption at the DCUP CS (105), using the distributed system (200) of claims 1 to 2, and comprising the following steps: i. DCUP LS executes the ML model according with predefined policies and locally persists the generated insights; ii. in the case the end-user has a mobility profile pattern and the propensity to consume insights from the ML model exceeds a defined threshold, the end user's insights must be sent to DCUP CS; ill. in the event of an insights consumer is at the DCUP CS, end-user consumes insights from DCUP CS; iv. in the case of an insights consumer is at the DCUP CS and end user insights are not available there, end user insights must be consumed from Home DCUP LS;v. in the event of an insights consumer is at the Home DCUP LS, it consumes end user insights directly from there; vi. in the case of an insights consumer is at another DCUP LS it consumes end-user insights from the DCUP CS; vii. in the case of an insights consumer is at another DCUP LS and the end user's insights are not available in the DCUP CS, the DCUP CS indicates which is the Home DCUP LS and the consumer consumes the insights from there.

Images