Application enabler layer support for vertical federated learning

Abstract

Methods are described herein for enabling VFL within mobile networks. VFL is a complex machine learning process that allows for learning with datasets from different data domains while preserving data privacy. This approach to federated learning allows for extracting potential insights and relationships that may exist between / among disparate data. However, dataset alignment between data from different domain presents an issue that needs to be managed to preserve privacy. An application enablement server, serving as a trusted third party, may be able to enable vertical federated learning within mobile networks.

Description

APPLICATION ENABLER LAYER SUPPORT FORVERTICAL FEDERATED LEARNINGCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 575,426, filed April 5, 2024, which is hereby incorporated by reference in its entirety.BACKGROUND

[0002] Vertical federated learning (VFL) is a complex machine learning process that allows for learning with datasets from different data domains while preserving data privacy. This approach to federated learning allows for extracting potential insights and relationships that may exist between / among disparate data. However, dataset alignment between data from different domain presents an issue that needs to be managed to preserve privacy. Accordingly, there is a need to support techniques for preserving data privacy in application enabler layers.SUMMARY

[0003] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that solve any or all disadvantages noted in any part of this disclosure.

[0004] Methods are described herein for enabling VFL within mobile networks. VFL is a complex machine learning process that allows for learning with datasets from different data domains while preserving data privacy. This approach to federated learning allows for extracting potential insights and relationships that may exist between / among disparate data. However, dataset alignment between data from different domain presents an issue that needs to be managed to preserve privacy. An application enablement server, serving as a trusted third party, may be able to enable vertical federated learning within mobile networks.

[0005] In one example, the system may receive, from a vertical application layer (VAL) server, a request for VFL. The system may determine one or more clients for VFL basedon artificial intelligence / machine learning (AIML) client information and a list of required features. The system may send a response to the VAL server. The system may configure VFL parameters with a selection of the one or more clients. The system may perform one or more VFL operations with the selected clients. The system may receive and process completed results from the selected clients. The system may send a notification of processed VFL results.BRIEF DESCRIPTION OF THE DRAWINGS

[0006] In order to facilitate a more robust understanding of the application, reference is now made to the accompanying drawings, in which like elements are referenced wi th like numerals. These drawings should not be construed to limit the application and are intended only to be illustrative.

[0007] FIG. 1 is a system diagram of an example machine-to-machine (M2M), Internet of Things (loT), or Web of Things (WoT) communication system in which one or more disclosed embodiments may be implemented;

[0008] FIG. 2 is a system diagram of an example architecture that may be used within the M2M / IoT / W oT communications system illustrated in FIG. 1 ;

[0009] FIG. 3 is a system diagram of an example communication network node, such as an M2M / IoT / WoT device, gateway, or server that may be used within the communications system illustrated in FIGs. 1 and 2;

[0010] FIG. 4 is a block diagram of an example computing system in which a node of the communication system of FIG. 1 and 2 may be embodied;

[0011] FIG. 5 shows an example application layer architecture model;

[0012] FIG. 6 shows an example generic on-network SEAL functional model;

[0013] FIG. 7 shows an example of horizontal and vertical federated learning datasets;

[0014] FIG. 8 shows an example of Vertical Federated Learning;

[0015] FIG. 9 shows an example VFL request procedure;

[0016] FIG. 10 shows an example of VFL data alignment; and

[0017] FIG. 11 shows an example GUI for VFL configuration.DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0018] Methods are described herein for enabling VFL within mobile networks.

[0019] The following abbreviations are described herein:Table 1 - Abbreviations

[0020] FIG. 1 is a diagram of an example machine-to machine (M2M), Internet of Things (loT), or Web of Things (WoT) communication system 100 in which one or more disclosed embodiments may be implemented. Generally. M2M technologies provide building blocks for the IOT / WOT, and any M2M device, M2M gateway, M2M server, or M2M service platform may be a component or node of the IoT / WoT as well as an IoT / WoT Sendee Layer, etc. Any of the client, proxy, or server devices illustrated in any of FIGs. 5-11 may comprise a node of a communication system, such as the ones illustrated in FIGs. 5-11.

[0021] The service layer may be a functional layer within a network service architecture. Sendee layers are typically situated above the application protocol layer such as HTTP, CoAP or MQTT and provide value added services to client applications. The service layer also provides an interface to core networks at a lower resource layer, such as for example, a control layer and transport / access layer. The service layer supports multiple categories of (service) capabilities or functionalities including a service definition, service runtime enablement, policy management, access control, and service clustering. Recently, severalindustry standards bodies, e.g., oneM2M, have been developing M2M service layers to address the challenges associated with the integration of M2M types of devices and applications into deployments such as the Intemet / Web, cellular, enterprise, and home networks. A M2M service layer can provide applications and / or various devices with access to a collection of or a set of the above mentioned capabilities or functionalities, supported by the service layer, which can be referred to as a CSE or SCL. A few examples include but are not limited to security, charging, data management, device management, discovery’, provisioning, and connectivity management which can be commonly used by various applications. These capabilities or functionalities are made available to such various applications via APIs which make use of message formats, resource structures and resource representations defined by the M2M service layer. The CSE or SCL is a functional entity that may be implemented by hardware and / or software and that provides (service) capabilities or functionalities exposed to various applications and / or devices (i.e. , functional interfaces between such functional entities) in order for them to use such capabilities or functionalities.

[0022] As shown in FIG. 1, the M2M / IOT / WOT communication system 100 includes a communication network 12. The communication network 12 may be a fixed network (e.g., Ethernet, Fiber, ISDN, PLC, or the like) or a wireless network (e.g., WLAN, cellular, or the like) or a netw ork of heterogeneous netw orks. For example, the communication network 12 may be comprised of multiple access networks that provide content such as voice, data, video, messaging, broadcast, or the like to multiple users. For example, the communication network 12 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency^ division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like. Further, the communication network 12 may comprise other networks such as a core netw ork, the Internet, a sensor network, an industrial control network, a personal area network, a fused personal network, a satellite network, a home network, or an enterprise network for example.

[0023] As shown in FIG. 1, the M2M / IoT / WoT communication system 100 may include the Infrastructure Domain and the Field Domain. The Infrastructure Domain refers to the network side of the end-to-end M2M deployment, and the Field Domain refers to the area networks, usually behind an M2M gateway. The Field Domain and Infrastructure Domain may both comprise a variety of different nodes (e.g., servers, gateways, device, and the like) of the network. For example, the Field Domain may include M2M gateways 14 and devices 18. Itwill be appreciated that any number of M2M gateway devices 14 and M2M devices 18 may be included in the M2M / I0T / W0T communication system 100 as desired. Each of the M2M gateway devices 14 and M2M devices 18 are configured to transmit and receive signals, using communications circuitry, via the communication network 12 or direct radio link. A M2M gateway 14 allows wireless M2M devices (e.g., cellular and non-cellular) as well as fixed network M2M devices (e.g., PLC) to communicate either through operator networks, such as the communication network 12 or direct radio link. For example, the M2M devices 18 may collect data and send the data, via the communication network 12 or direct radio link, to an M2M application 20 or other M2M devices 18. The M2M devices 18 may also receive data from the M2M application 20 or an M2M device 18. Further, data and signals may be sent to and received from the M2M application 20 via an M2M Service Layer 22, as described below. M2M devices 18 and gateways 14 may communicate via various networks including, cellular, WLAN, WPAN (e.g., Zigbee, 6L0WPAN, Bluetooth), direct radio link, and wireline for example. Exemplary’ M2M devices include, but are not limited to, tablets, smart phones, medical devices, temperature and weather monitors, connected cars, smart meters, game consoles, personal digital assistants, health and fitness monitors, lights, thermostats, appliances, garage doors and other actuator-based devices, security devices, and smart outlets.

[0024] Referring to FIG. 2, the example architecture 200 shows an M2M Sendee Layer 22 in the field domain that provides services for the M2M application 20, M2M gateways 14, and M2M devices 18 and the communication network 12. It will be understood that the M2M Service Layer 22 may communicate with any number of M2M applications, M2M gateways 14, M2M devices 18, and communication networks 12 as desired. The M2M Service Layer 22 may be implemented by one or more nodes of the network, which may comprise servers, computers, devices, or the like. The M2M Service Layer 22 provides service capabilities that apply to M2M devices 18. M2M gateways 14, and M2M applications 20. The functions of the M2M Sen ice Layer 22 may be implemented in a variety of ways, for example as a web server, in the cellular core network, in the cloud, etc.

[0025] Similar to the illustrated M2M Senice Layer 22, there is the M2M Sen ice Layer 22’ in the Infrastructure Domain. M2M Service Layer 22’ provides services for the M2M application 20’ and the underlying communication network 12 in the infrastructure domain. M2M Service Layer 22’ also provides services for the M2M gateways 14 and M2M devices 18 in the field domain. It will be understood that the M2M Sendee Layer 22' maycommunicate with any number of M2M applications, M2M gateways and M2M devices. The M2M Service Layer 22’ may interact with a Service Layer by a different service provider. The M2M Service Layer 22' may be implemented by one or more nodes of the network, which may comprise servers, computers, devices, virtual machines (e.g., cloud computing / storage farms, etc.) or the like.

[0026] Referring also to FIG. 2, the M2M Service Layers 22 and 22’ provide a core set of service delivery capabilities that diverse applications and verticals may leverage. These service capabilities enable M2M applications 20 and 20’ to interact with devices and perform functions such as data collection, data analysis, device management, security, billing, service / device discovery, etc. Essentially, these service capabilities free the applications of the burden of implementing these functionalities, thus simplifying application development and reducing cost and time to market. The Service Layers 22 and 22’ also enable M2M applications 20 and 20’ to communicate through various networks such as network 12 in connection with the services that the Sen-ice Layers 22 and 22’ provide.

[0027] The M2M applications 20 and 20’ may include applications in various industries such as. without limitation, transportation, health and wellness, connected home, energy management, asset tracking, and security and surveillance. As mentioned above, the M2M Service Layer, running across the devices, gateways, servers and other nodes of the system, supports functions such as, for example, data collection, device management, security, billing, location tracking / geofencing, device / service discovery , and legacy systems integration, and provides these functions as services to the M2M applications 20 and 20’.

[0028] Generally, a Service Layer, such as the Service Layers 22 and 22’ illustrated in FIG. 2, defines a software middleware layer that supports value-added service capabilities through a set of Application Programming Interfaces (APIs) and underlying networking interfaces. Both the ETSI M2M and oneM2M architectures define a Service Layer. ETSI M2M’s Service Layer is referred to as the Service Capability’ Layer (SCL). The SCL may be implemented in a variety of different nodes of the ETSI M2M architecture. For example, an instance of the Serv ice Layer may be implemented within an M2M device (where it is referred to as a device SCL (DSCL)), a gateway (where it is referred to as a gateway SCL (GSCL)) and / or a network node (where it is referred to as a network SCL (NSCL)). The oneM2M Service Layer supports a set of Common Serv ice Functions (CSFs) (i.e., service capabilities). An instantiation of a set of one or more particular types of CSFs is referred to as a CommonServices Entity (CSE) which may be hosted on different types of network nodes (e.g., infrastructure node, middle node, application-specific node). The Third Generation Partnership Project (3GPP) has also defined an architecture for machine-type communications (MTC). In that architecture, the Service Layer, and the service capabilities it provides, are implemented as part of a Service Capability Server (SCS). Whether embodied in a DSCL, GSCL, or NSCL of the ETSI M2M architecture, in a Service Capability Server (SCS) of the 3GPP MTC architecture, in a CSF or CSE of the oneM2M architecture, or in some other node of a network, an instance of the Service Layer may be implemented as a logical entity (e.g., software, computer-executable instructions, and the like) executing either on one or more standalone nodes in the network, including servers, computers, and other computing devices or nodes, or as part of one or more existing nodes. As an example, an instance of a Service Layer or component thereof may be implemented in the form of software running on a network node (e.g., server, computer, gateway, device or the like) having the general architecture illustrated in FIG. 3 or FIG. 4 described below.

[0029] Further, the methods and functionalities described herein may be implemented as part of an M2M network that uses a Service Oriented Architecture (SOA) and / or a Resource- Oriented Architecture (ROA) to access services.

[0030] FIG. 3 is a block diagram of an example hardware / software architecture 300 of a node of a network, such as one of the clients, serv ers, or proxies illustrated in FIGs. 5-11, which may operate as an M2M serv er, gateway, device, or other node in an M2M network such as that illustrated in FIGs. 5-11. As shown in FIG. 3, the node 30 may include a processor 32, non-removable memory 44, removable memory 46, a speaker / microphone 38, a keypad 40, a display, touchpad, and / or indicators 42, a power source 48, a global positioning system (GPS) chipset 50, and other peripherals 52. The node 30 may also include communication circuitry, such as a transceiver 34 and a transmit / receive element 36. It will be appreciated that the node 30 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. This node may be a node that implements the methods described herein, e.g., in relation to the methods described in reference to FIGs. 5-11 or the data structures of FIGs. 5-11, Tables 1-9, or in a claim.

[0031] The processor 32 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, amicrocontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. In general, the processor 32 may execute computer-executable instructions stored in the memory (e.g., memory 44 and / or memory 46) of the node in order to perform the various required functions of the node. For example, the processor 32 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the node 30 to operate in a wireless or wired environment. The processor 32 may run application-layer programs (e.g., browsers) and / or radio access-layer (RAN) programs and / or other communications programs. The processor 32 may also perform security operations such as authentication, security key agreement, and / or cry ptographic operations, such as at the access-layer and / or application layer for example.

[0032] As shown in FIG. 3. the processor 32 is coupled to its communication circuitry (e.g., transceiver 34 and transmit / receive element 36). The processor 32, through the execution of computer executable instructions, may control the communication circuitry' in order to cause the node 30 to communicate with other nodes via the network to which it is connected. In particular, the processor 32 may control the communication circuitry in order to perform the methods described herein, e.g., in relation to FIGs. 5-13, or in a claim. While FIG. 3 depicts the processor 32 and the transceiver 34 as separate components, it will be appreciated that the processor 32 and the transceiver 34 may be integrated together in an electronic package or chip.

[0033] The transmit / receive element 36 may be configured to transmit signals to, or receive signals from, other nodes, including M2M servers, gateways, device, and the like. For example, in an embodiment, the transmit / receive element 36 may be an antenna configured to transmit and / or receive RF signals. The transmit / receive element 36 may support various networks and air interfaces, such as WLAN, WPAN, cellular, and the like. In an embodiment, the transmit / receive element 36 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 36 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit / receive element 36 may be configured to transmit and / or receive any combination of wireless or wired signals.

[0034] In addition, although the transmit / receive element 36 is depicted in FIG. 3 as a single element, the node 30 may include any number of transmit / receive elements 36. More specifically, the node 30 may employ MIMO technology7. Thus, in an embodiment, the node30 may include two or more transmit / receive elements 36 (e.g., multiple antennas) for transmitting and receiving wireless signals.

[0035] The transceiver 34 may be configured to modulate the signals that are to be transmitted by the transmit / receive element 36 and to demodulate the signals that are received by the transmit / receive element 36. As noted above, the node 30 may have multi-mode capabilities. Thus, the transceiver 34 may include multiple transceivers for enabling the node 30 to communicate via multiple RATs, such as UTRA and IEEE 802. 11, for example.

[0036] The processor 32 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 44 and / or the removable memory 46. For example, the processor 32 may store session context in its memory’, as described above. The non-removable memory 44 may include random-access memory' (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identity' module (SIM) card, a memory stick, a secure digital (SD) memory’ card, and the like. In other embodiments, the processor 32 may access information from, and store data in, memory that is not physically located on the node 30. such as on a server or a home computer. The processor 32 may be configured to control lighting patterns, images, or colors on the display or indicators 42.

[0037] The processor 32 may receive power from the power source 48, and may be configured to distribute and / or control the power to the other components in the node 30. The power source 48 may be any suitable device for powering the node 30. For example, the power source 48 may include one or more dry cell batteries (e.g.. nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc ), solar cells, fuel cells, and the like.

[0038] The processor 32 may also be coupled to the GPS chipset 50, which is configured to provide location information (e.g., longitude and latitude) regarding the current location of the node 30. It will be appreciated that the node 30 may acquire location information by’ way of any’ suitable location-determination method w hile remaining consistent with an embodiment.

[0039] The processor 32 may further be coupled to other peripherals 52, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 52 may include various sensors such as an accelerometer, biometrics (e.g., finger print) sensors, an e-compass, a satellite transceiver, a sensor, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0040] The node 30 may be embodied in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane. The node 30 may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 52.

[0041] FIG. 4 is a block diagram of an exemplary computing system 400 which may also be used to implement one or more nodes of a network, such as the clients, servers, or proxies illustrated in FIGs. 5-11, which may operate as an M2M server, gateway, device, or other node in an M2M network such as that illustrated in FIGs. 5-11.

[0042] Computing system 400 may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever, or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within a processor, such as central processing unit (CPU) 91, to cause computing system 400 to do work. In many known workstations, servers, and personal computers, central processing unit 91 is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit 91 may comprise multiple processors. Coprocessor 81 is an optional processor, distinct from main CPU 91, that performs additional functions or assists CPU 91. CPU 91 and / or coprocessor 81 may receive, generate, and process data related to the disclosed systems and methods for E2E M2M Service Layer sessions, such as receiving session credentials or authenticating based on session credentials.

[0043] In operation, CPU 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer’s main data-transfer path, system bus 80. Such a system bus connects the components in computing system 400 and defines the medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and foroperating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0044] Memories coupled to system bus 80 include random access memory (RAM) 82 and read only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally contain stored data that cannot easily be modified. Data stored in RAM 82 may be read or changed by CPU 91 or other hardware devices. Access to RAM 82 and / or ROM 93 may be controlled by memory controller 92. Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode may access only memory mapped by its own process virtual address space; it cannot access memory within another process’s virtual address space unless memory' sharing between the processes has been set up.

[0045] In addition, computing system 400 may contain peripherals controller 83 responsible for communicating instructions from CPU 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.

[0046] Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 400. Such visual output may include text, graphics, animated graphics, and video. Display 86 may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86.

[0047] Further, computing system 400 may contain communication circuitry', such as for example a network adaptor 97, that may be used to connect computing system 400 to an external communications network, such as network 12 of FIGs. 1-4, to enable the computing system 400 to communicate with other nodes of the network.

[0048] Applications are becoming increasingly more complex and various mechanisms have been designed to assist with quicker development of the applications. One such mechanism is the introduction of different functional layers within (or adjacent to) the application layer to separate functions that may' be accessed via application programming interfaces or APIs.

[0049] FIG. 5 shows an example of a generalized application layer architecture 500 that separates application development into three distinct layers: application-specific, vertical application enabler, and (common) service layers. At the bottom of the application stack is the (common) service layer, which provides common or horizontal services to all applications. The services may include location management, group management, configuration management, and security aspects for application development. Above the service layer is the vertical application enabler layer, which is a layer that manages services for a specific vertical application such as autonomous vehicles, drones, loT, gaming, etc. At the top of the application stack is the application-specific layer which serves specific applications within a vertical application. This layer contains custom or business logic for a particular application and may be provided by various service providers in a vertical application domain. One goal of this three-layered approach is to abstract common services for all applications to the vertical application enabler and service layers to simplify application development for faster deployments of the applications.

[0050] The architecture 500 shown in FIG. 5 is based on a client-server communication model. One or more client applications on devices may communicate with one or more server applications on application servers. Note that server applications may reside in one or more application servers. The client application and server application of each layer communicate with each other between the devices and application servers. The applicationspecific client and server may communicate with client and server applications at any of the lower layers, respectively. For example, an application-specific client may communicate with the client application at either the vertical application enabler or service layers. A network between the client and server applications provides the medium for communication. The network may be a cellular netw ork such as a mobile operator netw ork or the network may be a broadband service provider network providing access to the internet for client and server applications.

[0051] It is worth noting that the architecture 500 shown in FIG. 5 may also apply to publish-subscribe and subscription-notification communication models. It is also worth noting that for decentralized deployments in which devices communicate directly with other devices, server functionality may reside on a device rather than on the application servers. For this case, devices may communicate with one another such that one device may function as a client and another device may function as a server.

[0052] In 3GPP, the Sendee Enabler Architecture Layer for Verticals (SEAL) provides horizontal functionality to all applications similar to the common service layer shown in FIG. 5. Some of the common services offered by SEAL are location management, group management, configuration management, identity management, key management, and network resource management. These sendees may be available to all applications as the services are agnostic to vertical industries. Each of the services offered may be associated with a corresponding management server, e.g. a group management server offering group services and a location management server offering location services.

[0053] FIG. 6 shows the on-network functional model of SEAL 600 from 3GPP TS 23.434 V19.0.0.

[0054] Machine Learning (ML) is a complex process in which mathematical algorithms are trained with curated data to generalize predictions of future data. Training data are collected, processed, and engineered in a centralized manner to ensure the resulting dataset is representative of the desired machine learning application. As a result, data is exposed to data scientists, engineers, and others involved in preparing the training data. The exposure of data raises privacy concerns with centralized machine learning.

[0055] To preserve data privacy, federated learning was devised to enable clients to collect, process, engineer, and train ML models locally and then upload model parameters or intermediate training results to an aggregation server, where the results are aggregated together with results from other clients. This form of training is referred to as Federated Learning (FL) and consists of multiple FL clients generating training results for aggregation at an FL server. Horizontal and vertical federated learning exist in which the main difference is in how the training dataset is constructed and trained.

[0056] FIG. 7 shows an example of the difference between horizontal and vertical federated learning datasets 700. In horizontal federated learning (HFL). FL clients train ML models with datasets sharing common features. For vertical federated learning (VFL), FL clients train ML models with datasets from different data domains where the datasets share one or more common features as shown by the shaded region in FIG. 7. The dataset in either HFL or VFL may be provided by different FL clients. For example, datasets 1, 2. and n may be provided by different clients for HFL and datasets Al , B 1 , A2. B2. An. and Bn may be provided by different clients for VFL.

[0057] In addition, the ML models used between HFL and VFL are different. In HFL, FL clients use the same ML model to train datasets with the same features. As a result, model parameters can be aggregated after each training round and updated for the next training round. In VFL, the ML model is split between FL server and FL clients. FL clients may have different ML models as well since the data use to train the client ML models have different features and come from different data domain. During VFL training, FL clients send intermediate results rather than model parameters to the FL server to continue training at the server ML model.

[0058] FIG. 8 shows an example of VFL with two FL clients and an FL server 800. Individual client ML models and associated model parameters are configured for each FL client and a server ML model aggregates intermediate results from each of the FL clients to generate the desired output(s). Two data domains A and B provide datasets and features different from each other. The FL server may optionally provide data from a third domain. For supervised learning, labels or ground truth data may be available as part of the server ML model training. Arrows are draw n between the client ML models and the server ML model to represent forward propagation (FP) of intermediate training results to the FL server and backward propagation (BP) of gradients for client artificial intelligence / machine learning (AIML) model parameter updates to the FL clients.

[0059] VFL provides enhancements to centralized machine learning and horizontal federated learning by enabling machine learning with datasets of different data domains while preserving data privacy. The ability to train with data from different domains affords deeper learning and may generate a better overall model. However, the enhancements and deeper learning also require careful consideration for dataset alignment and split AIML model interw orking in order to achieve proper learning outcomes.

[0060] 3GPP cellular systems provide an abundance of mobile devices that may assist with vertical federated learning. Application enablement layers are designed to simplify the usage of features available within the mobile operator networks. Thus far, application enablement layers do not support vertical federated learning such that proper learning outcomes can be achieved. Specifically, application enablement layers currently lack support for dataset alignment required for VFL as well as the management of the VFL process, including the discovery of suitable VFL clients, the processing of intermediate training results, and the model parameter updates of split ML models between client and server ML models.

[0061] VFL is a complex machine learning process that allows for learning with datasets from different data domains while preserving data privacy. This approach to federated learning allows for extracting potential insights and relationships that may exist between / among disparate data. However, dataset alignment between data from different domain presents an issue that needs to be managed to preserve privacy. An application enablement server, serving as a trusted third party, may be able to enable vertical federated learning within mobile networks.

[0062] A method for an AIML server to:

[0063] (1) Receive a request for vertical federated learning from a VAL server. The request may include one or more of a request identifier, a requestor identifier, an indication for vertical federated learning, AIML model and model parameters, a list of required features, aggregation strategies, a dataset alignment profile, a minimum number of data samples, a minimum number of AIML clients, temporal constraints, data labels, and an optimization function.

[0064] (2) Determine clients for VFL based on AIML client information and list of one or more required features.

[0065] (3) Send a response to the VAL server with one or more of a status to the request, an identifier for the request, a total number of AIML clients, and a number of discovered AIML clients for each data domain with a list of features for the associate data domain.

[0066] (4) Configure VFL parameters with the selected AIML clients. VFL parameters may include one or more of VFL operation to perform, AIML model and model parameters, a list of features required for the dataset, a dataset alignment profile for each AIML client, a number of samples required for the VFL operation, and an optimization function.

[0067] (5) Perform VFL operation with AIML clients. VFL operation may include one or more of aligning datasets from different data domains with data labels, update results of AIML model managed by the AIML server, compute errors and generate gradients for model updates.

[0068] (6) Receive and process completed results from AIML clients. The processing of completed results may include one or more of updating model parameters of the AIML model managed by the AIML server and aggregating intermediate results of client AIML models.

[0069] (7) Send notification of processed VFL results. The notification may include one or more of: a status, an identifier to associate with a VFL request, a completion percentage, outputs and model parameters of the AIML model managed by the AIML server, aggregated AIML client model parameters for each data domain, a number of data samples from each data domain, and a timestamp.

[0070] Within application enabler layers, AIML enablement clients and servers may be realized to provide functionality required for supporting vertical federated learning. Note that the terms AIML client / server may be used in place of AIML enablement client / server in this disclosure for brevity. An AIML server may be able to assist with discovering and selecting AIML clients for VFL, perform dataset alignment with data from different domains, and managing the VFL process to ensure successful training and / or inferencing. Managing the VFL process may include the communications of exploratory data analysis requests to assist with dataset alignment, the configuration of VFL parameters, the processing of intermediate results, the conveyance of gradients for client AIML model parameter updates, and other functionalities to support vertical federated learning.

[0071] In an example, an AIML server may receive, from a VAL server, a request for VFL. The request may indicate one or more requirements for VFL operations, an artificial intelligence / machine learning (AIML) model, one or more AIML model parameters, a minimum number of data samples, a minimum number of AIML clients, or a temporal constraint. The AIML server may select, based on AIML client information and the request, one or more clients for VFL. The one or more clients may share one or more common dataset features indicated by the request. The AIML server may send, to the one or more clients, one or more queries. The one or more queries may comprise a notification of selection for VFL operations, AIML model information, and the one or more requirements for VFL operations. The AIML server may send, to the one or more clients and based on one or more responses to the one or more queries from the one or more clients, one or more VFL configuration parameters. The one or more configuration parameters may cause each client of the one or more clients to train a client AIML model with local data. The training may comprise generating intermediate results to send to the AIML server. The AIML server may receive, from the one or more clients, the intermediate results indicating results of the training. The AIML server may process, based on the intermediate results, one or more updates to the AIML model managed by the apparatus and may generate gradients for client AIML model updates.

[0072] FIG. 9 shows an example VFL procedure 900 in which an AIML server may receive a VFL request and manages the VFL operations on behalf of the VAL sen- er. At step 1, AIML clients may register their AIML capabilities to an AIML server. Specifically, the AIML capabilities may indicate the AIML clients are capable of supporting vertical federated learning. As part of the registration, the AIML clients may indicate supported AIML models, dataset availability, a list of supported dataset features, and the number of data samples for each available dataset. The AIML client may also include a dataset alignment profile that may have been provisioned to the AIML client, e.g. as part of configuring the client for VFL. Additionally and / or alternatively, the AIML server may be locally configured and / or provisioned policies by external entities (e.g. an 0AM or application server) about AIML clients and their capabilities.

[0073] At step 2, an AIML application is defined in which datasets from different domains are identified for vertical federated learning. A VAL server may determine the AIML application can be implemented with vertical federated learning. The VAL server may perform one or more AIML client discovery' requests to evaluate the features that may be available from different data domains and the number of AIML clients that support the required features. Note that this step may be executed as a standalone step or combined with step 3 into a single request as an optimization.

[0074] At step 3, the VAL server may send a VFL request to an AIML server. The request may include requirements for VFL operations such as AIML models and model parameters, common and domain specific feature requirements, minimum number of data samples, minimum number of AIML clients, temporal constraints, data labels, optimization functions for client AIML model parameter updates, etc. Table 1 lists information elements that may be included in the VFL request. If known a priori, a dataset alignment profile may also be included in the request to specify how datasets from different domains can be combined together for VFL. If multiple AIML clients for the same data domain will be used during VFL operation, an aggregation strategy may be included to inform the AIML server how to aggregate ML model parameters from the AIML clients. Note that instead of a VFL specific request, the request may be a generic AIML request with a VFL indicator to inform the AIML server the request is for vertical federated learning.Table 2 - VFL request parameters

[0075] Note that in Table 2, common features and data domain features are separated as individual information elements. The separation between common and data domain features may be made available to accommodate cases in which the VAL server knows of the different data domains a priori. However, in certain other cases, the VAL server may not know of the data domains that may be available. In those cases, the VAL server may only provide required features (e.g. one or more of the common features listed in Table 1) and only data domain A features to the AIML server. In yet another case, the VAL server may only provide required features and no data domain features for the AIML server to find as many data domains as possible for VFL. For this case, the common features and data domain features may be combined together as a required features information element. One skilled in the art wouldrecognize that other combinations of common features and data domain features may be provided.

[0076] Note that the VAL server may have applied the same technique during step 2 to find as many data domains as possible. As an alternative, the VAL server may skip step 2 and let the AIML server perform the discover}7with the provided required features, whether with or without data domain features.

[0077] At step 4, the AIML server uses the common and domain specific features to discover and select AIML clients that can support the requirements for vertical federated learning. The common features specify required features that link data from different domains and the domain specific features specify features that are unique to each data domain. Using information of AIML capabilities (e.g. dataset availability and dataset features) associated with AIML clients (e.g. via registration or provisioned policy), whether stored locally or on another AIML server, a list of AIML clients may be determined as candidates for VFL. Note that if required feature(s) are provided, the AIML server may use the required feature(s) as common feature(s) and search for AIML clients with datasets that contain the indicated feature(s).

[0078] The list of AIML clients may have datasets that share common (or required) features while also having unique features. For example, a common feature may be a UE identifier, a user identifier, an AIML identifier, or a group identifier. The AIML server may use the common feature to discover all AIML clients whose dataset contains the specified feature. If more than one common feature is specified, the AIML server may attempt to discover datasets that contain all the common features.

[0079] When determining AIML clients suitable for VFL, the AIML server may be able to identify7AIML clients whose dataset may only include a partial list of required features (e.g. common and data domain features) and other AIML clients whose dataset may contain the missing features that when combined, the aggregate features meet the list of required features. As a simple example, an AIML client A may have a dataset with features A, B, and C while another AIML client B may have a dataset with features A, D, and E. The required features may be A, B, C, D, and E. Therefore, the datasets from AIML clients A and B may be combined together for use in VFL.

[0080] Additionally, the AIML server may also query the 5G network to obtain a list of UEs with AIML capabilities (e.g. FL member selection). Combining the list of AIML clientswith the common and domain specific features, the AIML server may be able to determine suitable and minimum number of AIML clients for VFL.

[0081] At step 5, the AIML server may send a response to the VAL server, the response may include a status and identifier for the VFL request and the number of AIML clients that were discovered for VFL. The number of discovered AIML clients may be categorized according to the data domain of the corresponding datasets as shown in Table 3. A list of features available for the corresponding data domain may also be included in the response. As an alternative, the VFL response may be sent after the VFL operations complete, e.g. as part of step 11. In that alternative, the information elements of step 5 and 11 may be combined together.Table 3 - VFL response parameters

[0082] At step 6, the AIML server may send requests to each of the selected AIML clients to inform them of their selection for VFL operations as part of dataset alignment queries. The request may include VFL operation (e.g. participation in VFL), AIML model information(e.g. model type, model ID), feature set requirements (e.g. common and domain specific features), and a requirement for minimum number of data samples for the dataset.

[0083] Each AIML client may send a response to indicate whether the client accepts the selection for the indicated VFL operation. The response may also include a dataset availability indicator to indicate whether the dataset is available or the dataset needs to be generated (e.g. collected and processed).

[0084] A dataset alignment profile may be available at the AIML server to perform dataset alignment queries. The dataset alignment profile may contain supported mechanisms for aligning data samples between / among datasets such as private set intersection (PSI) algorithm, privacy -preserving record linkage (PPRL) algorithm, or other privacy-preserving algorithms. An AIML server may be considered as a trusted third party and be able to perform encoding of common features to allow for the transmission of intermediate results between AIML clients and the AIML server during VFL operations while preserving data privacy. The AIML server may use a privacy-preserving algorithm to encode the common feature(s) and provide the algorithm to the AIML clients for encoding the common feature(s) during VFL operation.

[0085] The V AL server may be involved with the data alignment queries by providing data labels if they were not already provided in the VFL request. A sample test may be performed where data samples of common features and the associated data labels are encoded and compared to ensure data alignment. Various privacy-preserving algorithms may be tested and one may be selected as the preferred algorithm to use for data alignment. The sample test may be performed on synthetic data generated by the AIML server and provided to both AIML clients and the VAL server. The AIML clients and VAL server then use the selected privacypreserving algorithm to encode the synthetic data and send the output to the AIML server for comparison. The process may repeat for a small sampling of data to ensure the data alignment mechanism is working properly.

[0086] During and / or after the sample test, the AIML server may provide mapping information of the common features between the AIML clients and the VAL server. The mapping information may be provided as part of the data alignment profile or separately. This information provides further decoupling of the training data with the label data. For example, the values of user identifiers in training data may be mapped to enumerated values to anonymize the users from the VAL server. The AIML server may provide the same or differentenumerations of the user identifiers when providing the mapping information to the VAL server. If different enumerations are provided to the VAL server, the AIML server may perform translation of intermediate results and information provided to the VAL server.

[0087] The dataset alignment profile may also contain a list of required features for each AIML client with an indication of common and data domain features. The list of required features may be different for AIML clients with data from different domains. In addition, for AIML clients found in step 4 with partial feature sets, the AIML server may configure the clients accordingly with an extra indicator to provide a link between / among clients with feature sets that when aggregated together would meet the requirement for the required features. If the AIML clients are able to combine their datasets without privacy concerns (e.g. due to providing consent), then the AIML server may initiate the datasets to be combined by one of the AIML clients. As part of combining the datasets, the selected AIML client may align the data between / among the datasets according to the common features. Note that combining the datasets may also be performed as part of data collection described in step 8.

[0088] At step 7, the AIML server may send VFL configuration parameters to each of the selected AIML clients in the form of a subscription request. The sending of the requests may be based on the information received from the dataset alignment queries in which the dataset alignment profile was generated for each AIML client and for the VAL server. The request may include the VFL operation to perform, the AIML model and model parameters, mapping information for the common features, a list of features required for the dataset including both common and domain specific features, a dataset alignment profile for each AIML client, a number of samples required for the VFL operation, and an optimization function that may be used to update model parameters on the client AIML model. The AIML server may use the minimum number of AIML clients provided by the VAL server to configure and / or schedule the appropriate number of AIML clients for the VFL operation. Note that steps 6 and 7 may be performed separately or be combined together into a sequence of interactions between the AIML server and AIML clients and involving the VAL server when necessary. The dataset alignment profiles may be provided to the AIML clients as a separate step or as part of the VFL parameter configuration. The configuration request may trigger the start of VFL operations or alternatively, a separate request may be sent.

[0089] At step 8, after receiving VFL parameters from the AIML server, each AIML client may begin VFL operations. An AIML client may first download the configured AIMLmodel and associated model parameters. If data is not already available, the AIML client may start data collection, either internally or externally from a data source. The AIML client may ensure that the parameters for the features list and a minimum number of samples are met either for the readily available dataset or for the new generated dataset.

[0090] Once the AIML client have the available dataset properly prepared, VFL training and / or inferencing may commence using the dataset alignment profile. AIML clients associate with each data domain train the individual client AIML model with local data and generate intermediate results. The AIML clients may then send the intermediate results to the AIML server for continued processing in the server AIML model. This may be performed on a per data sample basis, a mini-batch basis, or a complete batch basis. If encoding of common features was specified, the intermediate results may include the encoded common features based on any mapping information that may have been provided. The encoded common feature may be used to link data from the different data domains and may be correlated with the data labels provided by the VAL server. The AIML server may perform translation of encoded common features according to the mapping information determined in step 6. The translation output may then be provided to the VAL server when completed results are sent. The data labels may also be encoded to allow for the alignment of the datasets. The intermediate results may be encrypted with a cryptographic function to secure the communication and preserve data privacy between AIML clients and the AIML server. The AIML server may even be able to process the encrypted data without decry pting the intermediate results.

[0091] At the appropriate times, errors may be computed at the server AIML model outputs using the provided data labels. The optimization function may be used to compute the errors and generate gradients for model parameter update. The gradients may be propagated to the AIML clients to update the parameters of the client AIML models. The propagation of the gradients may be encoded and / or encrypted to ensure privacy. The AIML clients may use the optimization function provided in the VFL parameters to update their model parameters. Alternatively, the optimization functions may be included within the AIML model.

[0092] At step 9, after all the data samples have been processed by each AIML client, a completed result may be generated by the AIML clients and a notification may be generated and sent to the AIML server. The notification may include a status for the VFL operation, the completed results, a list of common features, the number of data samples, and the ML model parameters.

[0093] At step 10, the AIML server may process the completed results from each of the AIML clients. The completed results may further be applied to the AIML model that is managed by the AIML server and the model parameters may be updated. The generated model parameters from the AIML clients within each data domain may be aggregated together according to the configured aggregation strategy and be used as initial values for the next round of VFL operations. The information received from each of the AIML clients may be saved within a local context maintained by the AIML server for the VFL request. The local context may include mapping information of the common features. Note that AIML client privacy is preserved since the AIML server is considered a trusted third-party based on established trust relationships between AIML clients and the AIML server.

[0094] At step 11, once the AIML server has processed the completed results received from all the AIML clients, a notification may be generated and sent to the VAL sen- er to provide a status of the VFL request. The notification may include a status for the VFL operation, an identifier for the VFL request, a completion percentage, the server AIML model output(s), updated model parameters of the server AIML model, aggregated client AIML model parameters for each of the data domains, a number of data samples per data domain, and a timestamp.

[0095] The data alignment queries performed in step 6 of FIG. 9 is an important step for vertical federated learning. The queries allow for the generation of data alignment profiles that may be used when performing VFL operations in step 8. In step 8, data from different domains are matched up with each other and when data labels are available, alignment becomes even more important to correlate the desired outcome with the various inputs for successful training of the AIML model. The encoding of the common features as well as the mapping information of the common features provide an additional layer of privacy between the AIML clients and the VAL server.

[0096] Note the availability of a data alignment profile in different steps of the procedure shown by FIG. 9 may be to account for various deployment scenarios. The need to perform VFL may be determined a priori and AIML clients may be provisioned with a data alignment profile in step 1. Subsequently, a request may be made to the AIML server to manage the VFL processing with the provisioned AIML clients.

[0097] A VAL server may initiate a VFL request and provide a data alignment policy to specify the requirements for data alignment based on results from discovery requests. TheVAL server may have performed EDA requests to gain insights into the available datasets (e.g. from different data domains) and determine VFL can be performed.

[0098] A third deployment scenario may be that a data alignment profile is determined interactively during step 6 in which data alignment is tested with sample data. The VAL server may perform EDA requests to gain insights into the data and determine how to align data from the different domains. A data alignment profile may then be generated.

[0099] FIG. 10 shows an example of the data alignment 1000 that may be performed by the AIML server to correlate data from domain A. domain B. and the data labels provided for the AIML application. A data alignment profile, which is represented as the document icon in FIG. 10, is shown in the figure to assist with the data alignment process. In this example, the common features are encoded based on mapping information and included with the intermediate results sent by the AIML clients. The data alignment component may use the encoded common features that are provided in the intermediate results and the mapping information to align with the data labels appropriately. The data labels may also be encoded in order to properly align the labels with the intermediate results. Note that different mapping information may be provided to AIML clients in different data domains and to the VAL server. The common features are encoded at each AIML client and the data labels are encoded by the AIML server.

[0100] A graphical user interface (GUI) may be provided on a VAL server to configure information for triggering vertical federated learning.

[0101] FIG. 11 shows an example of such a GUI 1100. Information such as the AIML model information (e g. AIML model and model parameters), common and domain specific features, and other information listed in Table 1 may be present in the GUI for the user to input. The user may then press the submit button to trigger the sending of the VFL request to the AIML server.

Claims

What is claimed:

1. An apparatus comprising one or more processors and memory storing instructions which, when executed by the one or more processors, cause the apparatus to: receive, from a vertical application layer (VAL) server, a request for vertical federated learning (VFL), wherein the request indicates one or more requirements for VFL operations, an artificial intelligence / machine learning (AIML) model, one or more AIML model parameters, a minimum number of data samples, a minimum number of AIML clients, or a temporal constraint; select, based on AIML client information and the request, one or more clients for VFL, wherein the one or more clients share one or more common dataset features indicated by the request; send, to the one or more clients, one or more queries, wherein the one or more queries comprises a notification of selection for VFL operations, AIML model information, and the one or more requirements for VFL operations; send, to the one or more clients and based on one or more responses to the one or more queries from the one or more clients, one or more VFL configuration parameters, wherein the one or more configuration parameters cause each client of the one or more clients to train a client AIML model with local data, wherein the training comprises generating intermediate results to send to the apparatus; receive, from the one or more clients, the intermediate results indicating results of the training; and process, based on the intermediate results, one or more updates to the AIML model managed by the apparatus and generate gradients for client AIML model updates.

2. The apparatus of claim 1 , wherein the instructions, when executed by the one or more processors, further cause the apparatus to: send, to the VAL server, a notification indicating status of the request for VFL.

3. The apparatus of claim 1, wherein the request further indicates one or more common features used for dataset alignment among datasets from different data domains, and data domain features, wherein the data domain features comprise a list of one or more features required for each data domain.

4. The apparatus of claim 3, wherein the one or more features indicated by the request and shared by the one or more clients comprise a portion of the common features and a portion of the data domain features.

5. The apparatus of claim 1, wherein the selecting comprises discovering whether a dataset of a client includes the one or more features indicated by the request.

6. The apparatus of claim 1 , wherein the request further indicates a user equipment (UE) identifier, a user identifier, an AIML client identifier, a group identifier, a VAL sendee identifier, an area of interest, a VAL service area, or a date and time.

7. The apparatus of claim 1, wherein the one or more queries comprise data alignment with data labels indicating a value of a common feature indicated by the request.

8. The apparatus of claim 1, wherein the apparatus comprises an AIML server.

9. A method comprising: receiving, from a vertical application layer (VAL) server, a request for vertical federated learning (VFL), wherein the request indicates one or more requirements for VFL operations, an artificial intelligence / machine learning (AIML) model, one or more AIML model parameters, a minimum number of data samples, a minimum number of AIML clients, or a temporal constraint; selecting, based on AIML client information and the request, one or more clients for VFL. wherein the one or more clients share one or more common dataset features indicated by the request; sending, to the one or more clients, one or more queries, wherein the one or more queries comprises a notification of selection for VFL operations, AIML model information, and the one or more requirements for VFL operations; sending, to the one or more clients and based on one or more responses to the one or more queries from the one or more clients, one or more VFL configuration parameters, wherein the one or more configuration parameters cause each client of the one or more clients to traina client AIML model with local data, wherein the training comprises generating intermediate results to send to the apparatus; receiving, from the one or more clients, the intermediate results indicating results of the training; and processing, based on the intermediate results, one or more updates to the AIML model managed by the apparatus and generate gradients for client AIML model updates.

10. The method of claim 9. further comprising: sending, to the VAL sen- er, a notification indicating status of the request for VFL.

11. The method of claim 9, wherein the request further indicates one or more common features used for dataset alignment among datasets from different data domains, and data domain features, wherein the data domain features comprise a list of one or more features required for each data domain.

12. The method of claim 11, wherein the one or more features indicated by the request and shared by the one or more clients comprise a portion of the common features and a portion of the data domain features.

13. The method of claim 9, wherein the selecting comprises discovering whether a dataset of a client includes the one or more features indicated by the request.

14. The method of claim 9, wherein the request further indicates a user equipment (UE) identifier, a user identifier, an AIML client identifier, a group identifier, a VAL sendee identifier, an area of interest, a VAL service area, or a date and time.

15. The method of claim 9, wherein the one or more queries comprise data alignment with data labels indicating a value of a common feature indicated by the request.

16. The method of claim 9. wherein the method is performed by an AIML server.

17. An apparatus comprising one or more processors and memory' storing instructions which, when executed by the one or more processors, cause the apparatus to: receive, from an artificial intelligence / machine learning (AIML) server and based on a request from a vertical application layer (VAL) server for vertical federated learning (VFL), one or more queries, wherein the one or more queries comprises at least one of: a notification of selection for VFL, AIML model information, or one or more requirements for vertical federated learning (VFL) operations; send, to the AIML server, one or more responses to the one or more queries; receive, from the AIML server and based on the one or more responses to the one or more queries, one or more VFL configuration parameters; based on the VFL configuration parameters, train a client AIML model with local data, wherein the training comprises generating intermediate results; and send, to the AIML server, the intermediate results indicating results of the training to cause processing, by the AIML server and based on the results, of one or more gradients for client AIML model updates.

18. The apparatus of claim 17, wherein the request further indicates one or more common features used for dataset alignment among datasets from different data domains, and data domain features, wherein the data domain features comprise a list of one or more features required for each data domain.

19. The apparatus of claim 17, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: receive, from the AIML server, gradients for client AIML model updates.

20. The apparatus of claim 17, wherein the one or more queries comprise data alignment with data labels indicating a value of a common feature indicated by the request.

Images