Methods and apparatus for ambient computing

Abstract

A device management engine operable to perform a machine learning task in an ambient computing environment comprises a transceiver element operable to send and receive messages over a network fabric o

Description

The present technology relates to data processing and data processing apparatuses and systems. As will be clear to one of ordinary skill in the art, this is merely one example of the possibilities in ambient computing, and many other examples will be immediately apparent. The present technology relates to the control of client devices and the potential responders to intelligent agents in an ambient computing environment. According to a first implementation of the present technology, there is provided a device management engine operable to perform a machine learning task in an ambient computing environment and comprising: a transceiver element operable to send and receive messages over a network fabric of the ambient computing environment; and an intelligent machine learning element operable to: responsive to a scenario prompt, define an overall objective comprising one or more subtasks; determine available agent devices in the ambient computing environment; determine capabilities of the available agent devices; identify available capable agent devices configured to perform at least one of the one or more subtasks; distribute first subtask function data to at least one available capable agent device to perform at least one subtask of the one or more subtasks. According to a second implementation of the present technology, there is provided a method of performing a machine learning task in an ambient computing environment having a transceiver element operable to send and receive messages over a network fabric of the ambient computing environment; and an intelligent machine learning element, the method comprising: defining, responsive to a scenario prompt an overall objective comprising one or more subtasks; determining available agent devices in the ambient computing environment; determining capabilities of the available agent devices; identifying available capable agent devices configured to perform at least one of the one or more subtasks; distributing a first subtask function data to at least one available capable agent device to perform at least one subtask of the one or more subtasks. In a further implementation, there may be provided a computer program comprising computer program code to, when loaded into a processor and executed thereon, cause the processor to perform the method according to an implementation of the present technology. The computer program may be embodied as a non-transitory computer-readable medium comprising computer program instructions to when loaded into a processor and executed thereon, cause the processor to perform the method according to an implementation of the present technology. In a variant, there may be provided a computer program operable to adapt a host processing system to provide an execution environment permitting operation of non-native processor instructions to perform the steps of the method according to an implementation of the present technology. Implementations of the present technology are diagrammatically illustrated, by way of example, in the accompanying drawings, in which: Figure 1 schematically shows a simplified block diagram of computing environment comprising a device management arrangement according to an implementation of the present technology; Figure 2 schematically shows in more detail the computing environment comprising a device management arrangement according to an implementation of the present technology; Figure 3 illustratively shows a flow diagram of the operation of a device management arrangement according to an implementation of the present technology. In Figure 1, the computing environment 1 according to the present technology comprises a device management engine 2 which is operable to communicate with one or more data processor devices 4i - 4n (where 'n' is an integer). Some or all of the devices 4i - 4n may be termed a "fleet" of data processor devices, where the fleet of devices may be controlled to perform subtasks on behalf of the device management engine 2 to achieve an overall objective and signal an overall outcome. The device management engine 2 comprises one or more elements to provide the functionality in accordance with the present techniques. Figure 1 illustratively shows a block diagram of the component elements of a device management engine 2 according to an implementation of the present technology. The device management engine 2 comprises elements including: task fusing engine 6, hierarchical encoder 7, analysis engine 8, query scheduler 10, pool model manager 12, model extraction manager 14 and model deployment engine 16. These elements will be described in detail below. The functions of the one or more elements including any functional elements described herein as a "block," "module" or "processor", may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read-only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage. Other hardware, conventional and / or custom, may also be included. Software modules, or simply modules which are implied to be software, may be represented herein as any combination of flowchart elements or other elements indicating performance of process steps and / or textual description. Such modules may be executed by hardware that is expressly or implicitly shown. The device management engine 2 and the one or more data processor devices 4i - 4n may operate responsive to the hardware and / or software elements thereof, where a device may operate using function data (such as instructions, ML models, etc.) to process operational data (e.g. image data, audio data, chemical analysis data) dependent on the particular operation thereof. As will be clear to one of skill in the art, the term "ML models" is here intended to refer to the models used in intelligent model-based learning and inferencing systems. These models may be managed and operated using any of the known forms of intelligent machine learning elements to achieve the technical function of the present technology. For example, an exemplary data processor device may comprise circuitry 5 including, for example, processing circuitry coupled to storage circuitry, communication circuitry and input / output (I / O) circuitry. The processing circuitry may be provided to carry out instructions of a program by performing the basic arithmetic, logical, control and input / output (I / O) operations specified by the instructions. The storage circuitry may comprise volatile (V) memory (e.g. RAM) and non-volatile (NV) memory (e.g. flash memory or ROM). The storage circuitry may store function data such as the programs executed by the processing element (or the models used for machine learning and inferencing tasks), and operational data used or generated by the devices 4i - 4n may also be stored in the storage circuitry for processing by the processor circuitry. The term "operational data" is used here to mean any data payload that is taken in as input to be processed for a user, is currently being processed, or that is output in the form of a result. The term is also used to mean any metadata such as control parameters, timing control data, and the like, that may need to be passed to the processing element. The term "operational data" is thus intended to be distinguished from "function data" that comprises the data and metadata that is used for performing subordinate functions on behalf of a higher-level task - for example, machine learning model data for performing model-based machine learning tasks. One example of function data is a classification model for classifying the objects detected in an image into their classes - for example human, animal, vehicle, building - according to the learned characteristics embodied in the classification model by way of a feature extraction process. The storage circuity may also store one or more machine learning model(s) or neural network(s) (hereafter "model"), where the model is executed on stimuli, such as data generated by the I / O circuitry to generate an output(s). In one example, a neural network comprising a classification neural network (CNN) is executed to analyse image data from camera circuitry to provide an output to determine whether a particular object to be classified is present in the image data. In this example, an element of an image may be individuated (selected as distinguished from background elements by inclusion in, for example, a bounding box) analysed to determine characterising features, and compared with a library of characterising features (derived by a learning process from a corpus of data) to classify the element in the image as belonging to a particular class of entities -a pedestrian, a moving car, a traffic light, a street lamp, etc. In a concrete example, an element of an image may be identified as a human face by comparison of its characterising features with the features of faces learned from a corpus of images of human faces. The storage circuity may also store credential data. Such credential data may include shared secret(s), for example, a cryptographic key which corresponds to a cryptographic key on a remote resource for authentication / encryption of communications comprising one or more packets of data transmitted therebetween. Communication circuitry, such as a transceiver element, in the one or more data processor devices 4i - 4n enables communication with remote devices, such as the device management engine, also provided with communication circuitry. The communication circuitry is operable over electronic communications means, wired and unwired, forming an ambient computing network fabric. The communication circuitry may use wireless communication over one or more channels, such as, for example, wireless local area network (e.g. Wi-Fi), short range communication such as radio frequency identification (RFID), near field communication (NFC), or communications channels used in wireless sensor networks such as ZigBee, Thread, Bluetooth and / or Bluetooth Low energy (BLE). Additionally, or alternatively, the communication circuitry may use a cellular network such as 3G, 4G, 5G etc. The communication circuitry may also use wired communication such a fibre optic or metal cable (e.g. Universal Serial Bus) via a physical data port, whereby a device reads and / or writes data from / to the storage circuitry. The communication circuitry could also use two or more different forms of wireless or wired communication, such as several of the examples given above in combination. Any of these communication means may in this way combine to form an ambient computing environment wherein transceiver elements at the devices register their presence in the environment and in which the network fabric permits the passing of messages among or between devices. The I / O circuitry may comprise sensing circuitry to sense inputs from the surrounding environment, (e.g. vibrations, temperatures, smells, sounds, chemical analysis (e.g. to detect smells or sounds) and / or to provide an output to a user e.g. using screen or speaker. The device management engine 2 and the one or more data processor devices 4i - 4n may each also comprise a power source, which may be a battery (e.g. a lithium coin cell), although any suitable power source may be used (e.g. an AC or DC mains power supply; solar power, wind power etc.). It will be appreciated that the device management engine 2 and the one or more data processor devices 4i - 4n may comprise other hardware / software components not described herein depending on the specific functionality of the devices. It will also be appreciated that the hardware (e.g. circuitry) and / or the software (OS, applications) of a particular device 4n may be taken to define the characteristics of that device and, in turn it may be possible to determine the capabilities of a device by determining one or more characteristics thereof. As an illustrative example, a characteristic of the device may include: a software version currently active on the device or active for a component of the device; the class of device or the class of a component(s) thereon; the vendor of the device or a component(s) thereon; the manufacturer of the device or a component(s) thereon; the current geographic location thereof; the security capabilities and / or requirements for the device or a component(s) thereon; the communications capabilities of the device or a component(s) thereof; a schedule specifying when the device (or a component thereon) is active or asleep, the speed of the processor; the size of memory. It will be appreciated that the list of characteristics is exemplary only. In some examples, the circuitry may comprise secure parts depicted as feature 5a in Figure 2, where applications may run in a more secure or trusted portion of the circuitry. Such security may be provided by hardware and / or software. In embodiments, one or more of devices 4i to 4n may be provisioned with function data (e.g. instruction data, parameters, or ML models) to cause them to perform various processing operations and functions. In embodiments, such data may be provisioned by the device management engine 2. Additionally, or alternatively, the devices 4i to 4n may receive, process and send data (e.g. operational data or other requested data, such as control metadata, function data or machine-learning model data) to the device management engine 2. For the device management engine 2 to provision data on a particular device 4n there may a pre-existing relationship between that particular device 4n and device management engine 2. For example, in embodiments a user or owner of the particular device 4n may register the particular device 4n with the device management engine 2 via a web application. In other embodiments, the device management engine 2 may broadcast a request to access all devices 4i to 4n receiving the broadcast, and a device 4 receiving the broadcast may present the request to a user (e.g. via a screen). On accepting the request, the device management engine 2 may then exchange data with the device 4n. In other embodiments, the device management engine 2 may broadcast instruction data to be provisioned on all devices 4i to 4n receiving the broadcast, and a device receiving the broadcast may present the request to a user, where on accepting the request, the device may process the instruction data and take one or more actions in accordance with the instruction data. The device may be, for example, a mobile (cellular) phone, laptop, smartwatch, smart speaker although these are examples only and the claims are not limited in this respect. For a better understanding of the environments within which the present technology may be implemented, Figure 2 shows in more detail than Figure 1, one possible example of computing environment 1. In the computing environment 1, device management engine 2 is in communication with the fleet of data processor devices 4i to 4n. As described above, a particular device 4n may be configured to operate responsive to, for example, the hardware elements (e.g. circuitry thereof) and / or the software elements thereof (e.g. operating system, firmware, or one or more application software programs) in storage circuitry and to generate operational data (e.g. image data, audio data, chemical analysis data) responsive to executing such software. In embodiments, the device management engine 2 receives a scenario prompt instruction or request (hereafter "scenario prompt"). The scenario prompt may be generated by the device management engine 2 or may be issued by, for example, a user via a device in communication with device management engine 2. A "scenario prompt" may be envisaged as the means by which a device "becomes aware" of a situation in its various aspects. A scenario may, for example, comprise a geographical element, such as "Device is at location x,y,z in a representation of a building", in combination with instruction data to cause the device to interrogate nearby devices to determine an ambient temperature at the device's location and to activate a machine-learning model trained to detect anomalous building temperature data and alert a user to the possibility of a fire in the vicinity. The scenario prompt may further comprise learned knowledge, such as, for example, user intention analysis based on previous behaviour patterns, direction, location, and rate of travel, gaze analysis, and the like. As will be clear to one of skill in the art, a user's device may, depending upon the use cases in operation, be in receipt of streams of scenario prompts over the course of a day, and each scenario prompt may cause further action as described hereinbelow. A scenario prompt may comprise information about the environment in which a user (e.g. as determined by detecting the user by a camera) or the user's device (e.g. as determined by location data from the user's device) is located or about another relevant environment within which the user requires the device management engine 2 to take one or more actions. Such an action may be a monitoring action to monitor the environment or the user for some specific indicator, or it may take the form of an immediate triggerfor performing an action. As will be clear to one of skill in the art, the scenario prompt may comprise further elements according to the prior training of the machine-learning model and the situations envisaged for processing. Responsive to the scenario prompt, the device management engine 2 determines one or more objectives based on or in response to the scenario prompt. As an illustrative example, a device (mobile phone or smartwatch etc.) of a particular user in communication with the device management engine 2 (directly or indirectly (e.g. via one or more nodes (e.g. Wi-Fi routers or gateways)) is determined to move from a television room in a house to a kitchen area of the house. Such a determination may be made responsive to location data (e.g. derived using local positioning techniques (e.g. via Bluetooth, Ultra-wideband (UWB), Light detection and ranging (Lidar)) and / or derived using global positioning techniques (e.g. global positioning system (GPS)) received from a device (e.g. a smart watch) associated with the user or from one or more cameras that detected the user in the kitchen. In the present illustrative example, the determination that the user is in the kitchen area is a scenario prompt, and an objective is to determine what the user is doing in the kitchen area. Such a determination may be made, for example, using ML models to determine what the user is doing in the kitchen. A different ML model(s) may then be used in response to a determination of what activity the user is performing in the kitchen, and using operational data from various devices in the kitchen as inputs to the ML model(s) as required for the objective forthat particular scenario. For example, when it is determined that the user is preparing to cook a meal, the objective may be to monitor for a fire event and the device management engine 2 may execute a ML model(s) to monitor for smoke (e.g. by using operational data from a smoke detector) or heat (e.g. using operational data received from a thermal imaging camera), and forewarn the user a potential fire event. As a further illustrative example, a device of the user (e.g. mobile phone or smartwatch etc.) in communication with the device management engine 2 is determined to be in a shopping center (or shopping mall) and is determined to move from a first shop to a second shop. Such a determination may be made responsive to location data received from a device (e.g. a smart watch) associated with the user or from one or more cameras in the shopping center that detected the user. In the present illustrative example, the determination that the user is walking to the second shop may be a scenario prompt, and an objective is to determine why the user is then in the second shop. Such a determination may be made by using ML models to determine what the user is doing in the second shop, using, for example, movement analysis, eye tracking gaze analysis or handheld device scanning of bar and QR codes to seek prices and discounts, and the like. A different ML model(s) may then be used responsive to a determination of what activity the user is performing in the second shop, and using operational data from various devices in the second shop as inputs to the ML model(s) as required for the objective for that particular scenario. For example, the objective may be to monitor for a purchase event and the device management engine 2 may execute a ML model(s) to monitor for a first purchase by using operational data from a camera device on a first aisle of the second shop or using operational data from a camera device on a second aisle warn the user that they already purchased that item or to warn the user that the item they are looking at (e.g. based on a determination that a user picked up the item) is less expensive in a third shop. In the illustrative examples above, the various devices 4ito 4n perform the functions that they are configured to perform (e.g. the cameras provide image data; the smoke detector provides smoke detection data; the thermal imaging camera provides thermal imaging operational data). However, in some cases the device management engine 2 may determine that devices immediately and directly available to the device management engine 2 may not be sufficient (in number or in their capabilities) to achieve a particular objective. The present techniques address this gap in available capability to achieve a particular objective. In the present techniques the computing environment 1 comprises an ambient computing environment, where device management engine 2 receives data (e.g. operational data, request data, function data, such as ML model data, and the like) from the one or more devicesand where device management engine 2 can send data (e.g. command data, function data (e.g. a ML model)) to one or more devices 4i-4n. In ambient scenarios, the device management engine 2 may orchestrate the functionalities of devices it can communicate with, in order to control the functionality of such devices to create a personalized ambient experience for a user. To provide such an ambient experience, the device management engine 2 determines an objective, determines the available resources (e.g. devices 4i-4n and respective capabilities thereof) to perform one or more tasks to achieve that objective; and identifies any gaps in the capabilities of the available resources. In the present illustrative embodiments, data processor devices 4ito 4n used by the device management engine 2 to solve an objective is hereafter referred to as an "agent device." Once a gap in the available capabilities to solve the objective (hereafter "gap") have been identified, the device management engine 2 determines how any such gap(s) may be addressed, and then provisions data (e.g. function data) on the one or more agent devices 4i-4nto address the gap(s). The function data may, for example, be provisioned on an agent device to cause the agent device to operate in a way they are not presently configured or not designed to operate. Additionally, or alternatively, the function data may be provisioned on a group of heterogeneous agent devices to cause the group of agent devices to operate in a coordinated or cooperative manner to achieve the (common) objective. Such functionality provides for a dynamic time and context sensitive personalised function creation. As described above, in an embodiment the device management engine 2 comprises elements including: task fusing engine 6, hierarchical encoder 7, analysis engine 8, query scheduler 10, pool model manager 12, model extraction manager 14 and model deployment engine 16. These resources are operable for their various functions when a process commences, as initiated by a scenario prompt, which may comprise, for example, a "triggering" set of circumstances that are sensed by the device under control of the device management engine 2, a specific user or other request received by the device, or a combination of these, possibly in conjunction with other environmental factors. On obtaining a scenario prompt, which may be derived responsive to the data (e.g. obtained from one or more devices (e.g. agent device) in an environment) i.e. where the devices are thus contributing to the Intent / Context, the task fusing engine 6 may perform global task understanding by combining (in an informative way) inputs from the one or more agent devices 4i - 4n that are available. In this way, an initial "rough" scenario prompt may be refined by the incorporation of knowledge that is only available to the agent devices in the environment, and it is in this way that a device management engine's initial understanding of the scenario, and thus the required structure of subtasks needed to achieve the overall objective and the overall outcome can be correctly structured. Such inputs may, for example, be operational data, location data, intention data or the like. The scenario prompt may thus define a complete representation of a situation that may require multiple tasks of information gathering, analysis, machine understanding, and probabilistic outcome determination. In an example, a user with an associated wearable device enters a shop, uses the device to scan bar codes of shoes to determine prices and is determined (e.g. from execution of an ML model) to be seeking lower priced shoes, but gaze analysis shows that the user is drawn to looking at high-fashion, higher-priced shoes. The scenario prompt may thus comprise instructions to create a model to determine a crossover point between desirable characteristics of shoes in stock at this store or at nearby stores and some estimate of an acceptable price point to suit the user. The model may than be deployed to select and alert the user to those shoes that are most likely to meet the criteria, whichever store they may be located in. To achieve these scenario requirements as expressed in the scenario prompt, the user device may need to request assistance from other devices - for example, store cameras for image data needed to model the user's gaze, multiple store stock control systems to locate goods meeting the criteria, and so on. The task fusing engine 6 may thus need to define sub-objectives for a fleet of devices with heterogenous capabilities, so that by action of the various devices each performing its respective sub-objective(s), the fleet of devices together cooperate to perform a global objective. Hierarchical encoder 7, which may provide optional functionality to create a higher level representation of parts of the input data to facilitate multi-modality. For example, the set of lower-level detail data relating to the user's gaze may need to be analyzed and generalized to determine a broad description of the classes of object that the user's gaze lingers on or returns to - thus the lower-level detail data, of limited usefulness in its raw form, can be rendered more useful when aggregated and generalized to provide input to a model of the user's view of desirable characteristics. Device management engine 2 further comprises analysis engine 8. The analysis engine 8 may identify missing data or insights to infer context, or otherwise to enable the delivery of the required ambient experience. The analysis engine 8 does this by, for example, examining first the scenario prompt to determine the ultimate target outcome, and then, second, the sub-objectives to be achieved by the fleet of data processor agent devices, and thus to develop a representation of the entire operation to achieve the outcome in the form of a network of sub-tasks (each to meet a sub-objective). The network of sub-tasks can then be considered in terms of the functionality available across the fleet of devices as currently constituted. In a first example case, the fleet of devices has no gaps - that is, each device in the fleet of devices is capable of meeting its subobjective using the facilities (such as program functions, models, data structures, and the like) that are already installed and operational. In a second example case, at least one of the fleet of devices is not capable of meeting its sub-objective and cannot be made so by installing additional function - for example, where a device does not have sufficient memory to contain the in-process data, or sufficient processing power to perform the required processing. In a third example case, at least one device in the fleet of devices is not, as currently configured, capable of meeting its sub-objective, but it may be made so capable by virtue of, for example, having additional program code functions installed, or having a suitable sub-model installed, or the like extension of functionality. The analysis engine 8 may then identify relevant nearest neighbour agent device(s), which, for example, when reprogrammed with an appropriate ML model, can fill any gaps in the need to process the operational data. Such agent devices which can be modified or augmented to perform the work is hereafter referred to as an "adjusted device". In embodiments, the analysis engine 8 determines which agent devices are available to communicate with. Such a determination may be made by transmitting a broadcast message to cause any agent device receiving the broadcast message to respond, and monitoring the responses. The analysis engine 8 may determine one or more characteristics of the devices that responded to the broadcast signal to, in turn, understand what capabilities each agent device has (e.g. storage type / size; processor type; I / O capabilities(s) available (e.g. video, audio, pressure sensor, smoke sensor, heat sensor etc.). The characteristics may also include the location of the agent device (e.g. via location data); manufacturer of the agent device (e.g. via identifier data (e.g. a IIUID)); model or type of device (e.g. via identifier data). The analysis engine 8 may then create a data matrix comprising the characteristics of all available agent devices 4ito 4n. Query scheduler 10 may be used to query a large AI model, and / or a model zoo or collection to identify one or more key models for the one or more agent devices 4ito 4n to perform the overall set objective. Additionally or alternatively, the query scheduler 10 may also generate device specific AI models suitable (in terms of, for example, model size and processing complexity) for downloading to respective agent devices of the one or more agent devices 4ito 4n so as to enable them to perform subtasks to meet the sub-objectives that are to be aggregated to produce the overall outcome. Additionally or alternatively, the query scheduler may deploy the respective device specific AI models to the fleet of devices in the current context, so that they can perform their subtasks in pursuit of the common objective. The pool model manager 12 manages a stored pool comprising various task specific ML expert models 13ito 13n, where each expert model may comprise one or more model teachers. The pool may contain large models suitable for achieving overall objectives where sufficient storage and processing resource is available, and may also contain smaller, less resource-hungry models suitable for deployment to devices having more limited capabilities. The models in the pool may further be suitable for modification and customization according to the facilities available at the various devices in the fleet of data processor agent devices. There may thus be provided the means for existing artificial intelligence machine learning models to operate to create further artificial intelligence machine learning models for specific purposes and to add to and improve the pool of machine learning models available for future use. The extraction engine 14 is operable to select appropriate function data (for example, program instructions, constant data sets, data structures and ML models) for each agent device, according to the functionality determined to be available. In implementations, the provisioning or distribution of function data may further comprise generating function data (e.g. instruction data, parameters, or ML models), by an intelligent machine learning element in the device management engine 2, using a machine learning and inferencing method. In implementations, the generating may comprise, for example, using an existing machine learning model from a pool of models, and adapting the existing model to make it operable on one or more of the devices 4i to 4n.Thus, the device management engine may dynamically generate the function data (e.g. ML models) specific for each agent device 4i to 4n to perform one or more subtasks as required. Deployment engine 16 is then operable to provision the selected function data on the respective agent devices 4i to 4n via a communication channel in the network fabric. Deployment engine 16 may further be operable to supply operational data to the respective agent devices 4i to 4n via the same or a different communication channel in the network fabric. In operation, an agent device 4n receiving the function data (e.g. ML model) from the device management engine 2 processes the function data to perform one more actions in accordance with the function data. For example, when the function data comprises an ML model the agent device may execute the ML model using the operational data generated thereat as an input to the ML model. As a further example, the function data may cause the device to provide operational data to the device management engine 2. The device management engine 2 can then use the operational data received from the device as inputs to an ML model as part of the objective. Additionally or alternatively, the function data may cause the agent device to operate in a particular manner. For example, the function data may comprise firmware or instructions to cause an agent device to, for example, enable circuitry that may otherwise be disabled on the agent device in normal use. For example, a device may have a microphone that is disabled in normal use, but which is enabled in response to the received function data. Thus, the adjusted agent device that is not normally enabled to detect sounds can detect sounds in response to the function data. As a further example, a device that has a camera but is not enabled to perform classification operations (e.g. facial recognition) may be provided with an ML model which when executed using the camera data as an input can perform classification operations such that the device is reconfigured to operate as an adjusted device. Responsive to the scenario prompt, the device management engine 2 determines one or more objectives based on or in response to the scenario prompt. For the purposes of an explanation, in an illustrative example, the scenario prompt is provided to the device management engine 2 responsive to the device management engine 2 receiving an input from an associated user device (hereafter "user device") indicating that a child of the user is lost. In embodiments the input may be an active user input, where the user may request (e.g. via an input device (e.g. a camera, microphone, keyboard etc.) that the device management engine 2 perform a particular action. In another example, the user input may be a passive input, where the device management engine determines a scenario prompt based on an indicator of an intention of a user (e.g. what the user or a device associated with that user is doing at a particular moment in time). For example, the device management engine 2 may obtain audio data from the user device between a user and a friend of the user comprising the user saying, "Where's Jane?." The device management engine 2 may also receive, from the user device, location data and determine that the user device is in a shopping center and may be aware from previous interactions with the user that Jane is a child. Responsive to the scenario prompt, the device management engine 2 determines one or more objectives based on or in response to the scenario prompt, where in the present illustrative example the objective is to 'Find Jane in the shopping mall'. In an embodiment, a device management engine 2 (e.g. using fusing engine 6) is operable to generate one or more vector(s) Vsi to Vsm of a subtask (where 'm' is an integer). Such a vector of a subtask may be a task determined as required to be performed to contribute to achieving the overall objective. As described above, each subtask is structured to provide a portion of the solution that contributes to meeting the overall objective. An example of a vector of subtasks for the present illustrative embodiment may be: Vsi =child face recognition inside the mall VS2 = face recognition outside the mall VS3 =detect child without adult inside-outside the mall VS4 = detect crying child Vss = display alert missing child on screen(s) VSn = query people on their registered / connected devices In an embodiment the device management engine 2 (e.g. using fusing engine 6) is operable to create a matrix Ws of subtask requirements, where the matrix Ws defines the capability requirements to perform each of the respective subtasks (hereafter "capability matrix"). As described above, each subtask represents a portion of the solution that will contribute to meeting the overall objective, and each subtask is operable to be deployed to a device in the available fleet of devices. For each subtask, the capability matrix defines the device / sensor requirements as well as any function capability characteristics (such as the capacity to implement an ML model, the storage capacity available to store in-process data, and the like). An example of a capability matrix Ws for the present illustrative embodiment may be: Vsi =child face recognition inside the mall - sensor / device = camera ; model = face recognition ; HW = minima Cortex A ; Memory = minima 2GB ; ... VS2 = face recognition outside the mall - sensor / device = video camera model = face recognition model , ... VS3 =detect child without adult inside-outside the mall - sensor =video camera ; model = posture and association recognition model ; ... VS4 = detect crying child - sensor =microphone model = crying recognition model ; ... VS5 = display alert missing child on TVs - sensor / device = TV display, mobile phone displays ... ; model = none Vsn = query people on their registered / connected devices - sensor / device = mobile devices of people in the mall with camera ; model = child and face recognition; ... In an embodiment the device management engine 2 (e.g. using fusing engine 6) is operable to create a matrix MD of resources available to the device management engine 2, (hereafter "resource matrix"). An example of a resource matrix MD for the present illustrative embodiment may be: MD I, j + l= device / sensor type = e.g. camera ; MD I, j+2 = model = # of pedestrian in the vision field ; etc.... data type, CPU, memory, ... The device management engine 2 (e.g. using fusing engine 6) may optionally generate one or more variable links AlphaP (where 'p' is an integer) to the context (leveraging the scenario prompt). The variable link AlphaP may be defined by multiplying vector Vs or matrix Ws with an efficiency / cost value. For example: Alphai = 1 / d, d being distance to the localization of the source of the request (this factor can be used to suppress recruitment of agent device(s) from the fleet of devices that are not local enough, for example, those that are too far away to be useful in the lost child in the mall use case). In other cases, the value may allow global access (e.g. e-tag Apple); Alphaz = Energy availability / effectiveness of the different devices available - this value can be used to suppress recruitment of devices that would exceed their available energy supply in performing subtasks; Alphas = max / min number of devices which are required to fulfill an objective (whether accessed locally or through the internet like virtual sensors, remote webcams, and the like that may be available through a device management platform). Thus, in accordance with the present techniques, the device management engine 2, for example using the fusing engine 6, outputs: 1. vector Vs of subtask; 2. matrix Ws of subtask requirement; 3. matrix MD of available resource; 4. Alpha vector of weights for context based optimization. The device management engine 2 then, for example using analysis engine 8, uses the output from the fusing engine 6, and creates a matrix (MDS) of the resources available vs the capability requirements to perform each of the respective subtasks. In the MDS matrix: M Dx,Sy = +1, 0, or -1 That is, the match value for a device is set at one of the three values: 1, 0, or -1 based on, for example, sensor type matching, model matching, etc.... The match value M is set to 1 when the available resources provide the capability requirements. It is set to -1 when the available resources do not provide the capability requirements but can be modified or adjusted (e.g. using function data) to provide the capability requirements. It is set to 0 when the available resources do not provide the capability requirements and cannot be modified or adjusted to provide the capability requirements). Updating the MDS matrix could be as simple as a function of Vsx and MDx e.g Vsx i = MDx i or Vsx i MDx i ("has a microphone" requirement matches with "has a microphone" ; "has a microphone" requirement is not an exact match with "has a videocamera"). In an illustrative example, when M Dx,Sy = -1, when trying to detect a crying child, the device management engine 2 may determine that there is an agent device having a microphone (e.g. a microphone at an order station of a restaurant) which is a direct speaker or natural language processing augmented device, and then provision an ML model on that agent device to execute the ML model to determine if a crying child is detected. In a further illustrative example, the device management engine 2 may determine that there is an agent device having a camera (e.g. a robotic cleaning device) in the shopping center and provision an ML model on that agent device to execute the ML model to determine if a lone child is detected in its camera field of view. Thus the device management engine 2 can leverage a dedicated data type or matter protocol to learn about device capabilities and / or use a Large language models (LLM) matching model to understand device semantics (e.g. mini LLM, or IFTTT like function). In embodiments, only extracting or relying on agent devices falling into MDS = +1 into a matrix, and only using agent devices in the MDS = +1 matrix to meet the objectives enables the device management engine 2 to determine the optimized user experience available. The device management engine 2 may want to reduce the dimensionality by, for example, returning to vector VD+1 to create the vector of N available ready to use devices , or it may simplify the modalities by using matrix encoding. As will be clear to one of skill in the art, any of the available means of reducing the matrix structure in this way can be used to provide a simple list of available devices that are already configured with adequate resources to achieve the subtask objectives. In one example, the device management engine 2 may calculate a probability of meeting the objective based on the MDS = +1 device matrix. Such a calculation may be provided by defining the output format (vector scenarios) and create a reward model which will be application dependent - using, for example, a multi-cost optimization algorithm. The device management engine 2 may run for each task or subtask, for example, a multi-objective optimization genetic algorithm, and based on the result (e.g. a threshold) may determine the action to be taken - use the available devices at MDS = +1, fall back to upgrading devices at MDS = -1, or return failure and reset the scenario, for example. The device management engine 2 may approach the problem by rendering the cost algorithm in the form of a combinatorial graph suitable for consideration as a symmetric traveling salesman optimization problem where the device management engine 2 may set up the distance pairs for each device from its current state to the targeted device state. This optimization of the device fleet selection can be achieved by using MDS-1 matrix multiplication by an Alpha vector. For each device a distance d(VD-l I, VD-1 to+1 i) is calculated from sensor type, model type, CPU capability, memory capability, model zoo model size and availability leveraging MDS-1 (line vector dot product with a D vector of distance setup to reflect the importance of one or another of the criteria - e.g. for some functions a larger memory size (above a basic threshold value) may not be as important as the presence of a particular sensor, and may thus not yield the same distance on a notional scale of utility for the subtask in hand. To perform the manipulations required to manage and select the devices to form the fleet of devices to be used to perform the subtasks that contribute to the overall task, the device management engine 2 may make use of a matrix encoding neural network capable of encoding and manipulating the matrix-style relationship data found in many combinatorial optimization problems, (e.g. MatNet). The output from the analysis engine 8 is then provided to the query scheduler engine 10 where, as above, query scheduler 10 is operable to query a large AI model, and / or a model zoo or collection to identify the necessary function data (e.g. a portion of the large AI model or a member of the model zoo) for the one or more agent devices 4i to 4n to, responsive to the function data, perform one or more subtasks to achieve the overall objective. As set out above, an intelligent machine learning element in the device management engine 2 may, using a machine learning and inferencing method, dynamically generate the function data (e.g. ML models) for the one or more each agent device 4i to 4n to perform one or more subtasks as required. Figure 3 illustratively shows an exemplary method 200 to achieve an objective in a computing environment having a device management engine to control one or more agent devices to perform one or more functions to contribute to the achievement of an overall objective. At 202 the method starts. At 204 the device management engine obtains a scenario prompt, which may be issued by, for example, an active input e.g. from a user via a device in communication with device management engine, or, for example, a passive input (e.g. an indicator of an intention of a user) by way of an automated response to a detected situation. At 206, responsive to the scenario prompt, the device management engine determines one or more objectives based on or in response to the scenario prompt. At 208, the device management engine determines the available agent resources available to perform the tasks. For example, the device management engine determines which agent devices are available with which to communicate and at 210 determines the characteristics of such available agent devices, creating a matrix representation of the characteristics. At 212, the device management engine creates vectors describing one or more sub-tasks required to be performed to achieve the one or more overall objectives. As in the example described above, an overall objective may be to find a child in a shopping mall, and the subtasks may involve searching of image data by devices equipped with visual processing means, detecting relevant sounds using devices equipped with sound detection and analysis means, or the like. At 214, the device management engine creates a capability matrix as described above - that is, for each subtask, the capability matrix defines the device / sensor requirements as well as any function capability characteristics (such as the capacity to implement an ML model, the storage capacity available to store in-process data, and the like). At 216, a per-device process begins, whereby each device's capabilities are compared against the requirements for performing a proposed subtask, and this process is operable to iterate until (a) there is a sufficient fleet of devices available, or (b) there are no further available devices even when modified or augmented, and the subtasks cannot be completed. For each device, then, at 216, comparison and categorization are performed, and at 218 the categorization yields and MDS value as described above. The MDS values are MDS = +1, MDS = 0, and MDS = -1. For devices categorized as MDS = 0, at 220, the device details are discarded from the matrix of possible devices to enter the fleet. For devices categorized as MDS = +1, the device is added to the fleet at 224. For devices categorized as MDS =-1, the device management engine determines how the one or more resources could be configured to operate to achieve the one or more objectives. The device management engine at 222 determines and performs the necessary actions to adjust (modify or augment) the device capabilities to enable it to perform a subtask. In some cases, this may involve installing additional software, function data or the like, such that the device can, for example, operate an ML model to complete the subtask. In other cases, the action may involve reconfiguring elements of the device that are already in place in the device's available functions. As an illustrative example, the device management engine may determine that a particular agent device has circuitry (e.g. a microphone) that is not currently enabled but which could be used to achieve a particular objective is within range. The device management engine may then provide instruction data to cause the agent device to enable the circuitry required to achieve the one or more objectives. Thus, the device management engine can address any gaps in the resource capabilities by reconfiguring the one or more agent devices (e.g. responsive to instruction data) to be adjusted devices. Thus, when the device management engine determines, at 222, that there are sufficient resources to achieve the one or more objectives or when the agent device reconfigures or augments an agent device to address a capability gap, the device management engine provides function data to the agent device operate in a particular manner to perform a sub-task to achieve the overall objective. For example, the function data may comprise an ML model which when executed (e.g. using operational data from certain circuitry (e.g. a particular sensor) provides an output (e.g. classification data) which is used to achieve the one or more objectives. In this manner, when a device that was categorized as MDS = -1 has been modified or augmented at 222, the device is added to the fleet at 224. At 226, the device management engine tests whether the fleet is complete - that is, are all the devices necessary to achieve the subtasks ready to operate or not? If the fleet is complete, the process continues at 232. If the fleet is not complete at 226, and there are more devices, the process iterates from 216 to compare, categorize and further process additional devices until the fleet is complete at 226 or no further devices are available at 228. In the latter case, that is, there are no more devices to be considered and the fleet is incomplete, the process has failed and ends at 230 END FAILURE. As will be clear to one of ordinary skill in the art, END FAILURE may be signaled to a user or processed using any of the known and appropriate failure processing methods. If, the fleet is determined to be complete at 226, the operations of the subtasks can begin at 232. In some cases, as will be clear to one of skill in the art, it may be possible to commence some subtasks in advance of this determination, allowing for provisional completion of some subtasks, which may then be abandoned in due course if the remainder of the fleet cannot be assembled. Assuming, for this example case, that the fleet has been appropriately mustered, when the subtasks are all complete, the subtask outcomes may be aggregated at 234. At 236, the overall result may be signaled in any appropriate manner, according to the present use case. For example, the completion signal at 236 may be, in our lost child example, a message "lost child now found" to all devices, along with an instruction to cease searching, delete all residual in-process data and resume a prior state, such as a ready state to free the devices for other processing as required. The process completes at 238 END SUCCESS. As will be immediately clear to one of skill in the art, the device management operation 200 described here represents a single iteration, and in any real world setting, many and varied iterations, with adjustment to particular use cases, may be performed. As will be clear to one of skill in the art, not all cases are a simple as that defined above. For example, in the case where a scenario prompt is received and the method begins, but the real-world situation changes, it may be necessary to stop the method at any point (e.g. responsive to one or more scenario prompts), and to reset any changes begun at any of the completed steps. Thus, there may be a continuous stream of scenario prompts as a user goes about their day. In such cases, also, it may be advantageous to retain some advantage from any of the steps that may have completed - for example, if a new or adjusted model has been created during the process, it may be advantageous not to merely discard it and thus waste the resource consumed in its creation, but to save it to the model zoo for possible future use. Thus, such functionality may be viewed as using artificial intelligence (AI) to create AI in accordance with the present techniques. In some cases also, additional information may come to light in the course of processing that may make it useful to stop the method and restart with the benefit of e.g. an improved scenario prompt, or an improved model for deployment. These minor variations are envisaged and allowed for within the implementations of the present technology. As described above, the function data may comprise a ML model, which when executed at the agent device, provides an output that is used to achieve the one or more objectives defined by the original scenario prompt. In embodiments the agent devices can perform tasks locally by executing the function data (e.g. ML model) thereon and providing the result of the analysis to the device management engine 2. Such functionality provides privacy and reduces network traffic where all the analysis tasks are performed locally on the agent devices and only a result of a processing operation is provided to the device management engine. Additionally, or alternatively, the agent devices can, responsive to function data, provide operational data where the device management engine 2 may process the operational data to achieve an objective. Such functionality may reduce the processing and storage resources on the agent device. In accordance with the present techniques there is provided an ambient system where, responsive to a scenario prompt, a device management engine can interrogate devices that are available in the ambient environment to determine whether there are devices that can immediately and without additional work, perform the necessary subtasks. If, on the other hand, there are no, or insufficient numbers of, devices that could perform the work unchanged, the device management engine can determine which devices could be adjusted (modified or augmented) to perform the work. It may also be able to perform a cost estimate (the cost being in processing or other resource use) of the work required to adjust any particular device, and can then make a selection of devices to adjust, based on that cost estimate. The device management engine can then generate function data that can be deployed to agent devices to perform the subtasks to achieve a specific objective. Such functionality means that an agent device can join the fleet of devices to perform local processing of the function data to provide a particular function even when that agent device may not be designed or may not be configured to perform that function. In embodiments the function data comprises an ML model, where an agent device will execute the ML model (e.g. using operational data received by I / O circuitry at the agent device as an input to the ML model), and then provide the output from the ML model to the device management engine. The device management engine thus determines what agent devices are available to communicate with and the capabilities of those agent devices. The device management engine sends, function data to the respective agent devices to perform a function to achieve an objective. The device management engine can select an agent device based on its capabilities (not necessarily what it necessarily currently configured for). In ambient computing arrangements having a device management engine and the one or more data processor devices according to the present technology, many variant and additional features may be found. As will be appreciated by one skilled in the art, the present technique may be embodied as a system, method or computer program product. Accordingly, the present technique may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Where the word "component" is used, it will be understood by one of ordinary skill in the art to refer to any portion of any of the above embodiments. The functions of the various elements shown in the figures, including any functional elements labelled as a "block," "component," "module" or "processor", may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read-only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage. Other hardware, conventional and / or custom, may also be included. Software modules, or simply modules which are implied to be software, may be represented herein as any combination of flowchart elements or other elements indicating performance of process steps and / or textual description. Such modules may be executed by hardware that is expressly or implicitly shown. Reference throughout this document to "one embodiment," "certain embodiments," "an embodiment," "implementation(s)," "aspect(s)," or similar terms means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of such phrases or in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments without limitation. The term "or," as used herein, is to be interpreted as an inclusive or meaning any one or any combination. Therefore, "A, B or C" means "any of the following: A; B; C; A and B; A and C; B and C; A, B and C." An exception to this definition will occur only when a combination of elements, functions, steps or acts are in some way inherently mutually exclusive. As used herein, the term "configured to," when applied to an element, means that the element may be designed or constructed to perform a designated function, or has the required structure to enable it to be reconfigured or adapted to perform that function. Numerous details have been set forth to provide an understanding of the embodiments described herein. The embodiments may be practiced without these details. In other instances, well-known methods, procedures, and components have not been described in detail to avoid obscuring the embodiments described. The disclosure is not to be considered as limited to the scope of the embodiments described herein. Furthermore, the present technique may take the form of a computer program product embodied in a non-transitory computer readable medium having computer readable program code embodied thereon. The computer readable medium may be a computer readable storage medium. A computer readable medium may be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. Computer program code for carrying out operations of the present techniques may be written in any combination of one or more programming languages, including object-oriented programming languages and conventional procedural programming languages. The program code may execute entirely on the user's computer, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network. Code components may be embodied as procedures, methods or the like, and may comprise sub-components which may take the form of instructions or sequences of instructions at any of the levels of abstraction, from the direct machine instructions of a native instruction-set to high-level compiled or interpreted language constructs. It will also be clear to one of skill in the art that all or part of a logical method according to embodiments of the present techniques may suitably be embodied in a logic apparatus comprising logic elements to perform the steps of the method, and that such logic elements may comprise components such as logic gates in, for example a programmable logic array or application-specific integrated circuit. Such a logic arrangement may further be embodied in enabling elements for temporarily or permanently establishing logic structures in such an array or circuit using, for example, a virtual hardware descriptor language, which may be stored using fixed carrier media. In one alternative, an embodiment of the present techniques may be realized in the form of a computer implemented method of deploying a service comprising steps of deploying computer program code operable to, when deployed into a computer infrastructure or network and executed thereon, cause said computer system or network to perform all the steps of the method. In a further alternative, an embodiment of the present technique may be realized in the form of a data carrier having functional data thereon, said functional data comprising functional computer data structures to, when loaded into a computer system or network and operated upon thereby, enable said computer system to perform all the steps of the method. Those skilled in the art will recognize that the present disclosure has been described by means of examples. The present disclosure could be implemented using hardware component equivalents such as special purpose hardware and / or dedicated processors which are equivalents to the present disclosure as described and claimed. The techniques further provide processor control code to implement the above-described systems and methods, for example on a general-purpose computer system, on a digital signal processor (DSP), on a graphics processing unit (GPU), on a Neural Processing Unit (NPU), or the like. The techniques also provide a carrier carrying processor control code to, when running, implement any of the above methods, in particular on a non-transitory data carrier - such as a disk, microprocessor, CD- or DVD-ROM, programmed memory such as read-only memory (firmware), or on a data carrier such as an optical or electrical signal carrier. The code may be provided on a carrier such as a disk, a microprocessor, CD- or DVD-ROM, programmed memory such as non-volatile memory (e.g., Flash) or read-only memory (firmware). Code (and / or data) to implement embodiments of the techniques may comprise source, object or executable code in a conventional programming language (interpreted or compiled) such as C, or assembly code, code for setting up or controlling an ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array), or code for a hardware description language such as Verilog™, VHDL (Very high speed integrated circuit Hardware Description Language) or SystemVerilog hardware description and hardware verification language. As the skilled person will appreciate, such code and / or data may be distributed between a plurality of coupled components in communication with one another. The techniques may comprise a controller which includes a microprocessor, working memory and program memory coupled to one or more of the components of the system. The various representative embodiments, which have been described in detail herein, have been presented by way of example and not by way of limitation. It will be understood by those skilled in the art that various changes may be made in the form and details of the described embodiments resulting in equivalent embodiments that remain within the scope of the appended items.

Claims

1) A device management engine operable to perform a machine learning task in an ambient computing environment and comprising:a transceiver element operable to send and receive messages over a network fabric of the ambient computing environment; andan intelligent machine learning element operable to:responsive to a scenario prompt, define an overall objective comprising one or more subtasks;determine available agent devices in the ambient computing environment;determine capabilities of the available agent devices;identify available capable agent devices configured to perform at least one of the one or more subtasks;distribute first subtask function data to at least one available capable agent device to perform at least one subtask of the one or more subtasks.2) The device management engine of claim 1, further configured to: receive individual outputs from the available capable devices; and aggregate the individual outputs to create an overall outcome in relation to the overall objective.3) The device management engine according to claim 1 or claim 2, wherein the intelligent machine learning element is further operable to:identify available agent devices capable of performing at least one of the subtasks when adjusted;adjust at least one device of the available agent devices capable of performing at least one of the subtasks when adjusted, to provide an adjusted device;responsively distribute at least subtask function data to the adjusted device;activate the adjusted device to perform the at least one of the subtasks.4) The device management engine according to claim 3 further operable to: receive individual outputs from the at least one adjusted device; aggregate the individual outputs to create the overall outcome in relation to the overall objective; andsignal the overall outcome by means of the transceiver element.5) The device management engine of any preceding claim, further configured to determine, responsive to the individual outputs, whether the overall outcome is complete.6) The device management engine according to any preceding claim, wherein the scenario prompt comprises a signal indicating the entry of a mobile device having the intelligent machine learning element installed into an ambient computing zone.7) The device management engine according to any preceding claim, wherein the scenario prompt is obtained responsive to an active input and / or a passive input.8) The device management engine according to any preceding claim, wherein the passive input comprises an indicator of an intention of a user.9) The device management engine according to any preceding claim wherein the intelligent machine learning element responsively distributing at least subtask function data comprises distributing one or more of: instruction code and a machine learning model.10) The device management engine according to any preceding claim wherein the intelligent machine learning element responsively distributing at least subtask function data further comprises distributing operational data.11) The device management engine according to any one of claims 3 to 10, wherein adjusting at least one device comprises one of enabling an installed device function and installing a device function.12) The device management engine of any preceding claim, wherein the intelligent machine learning element is operable to generate the subtask function data using a machine learning and inferencing method.13) The device management engine according to any preceding claim, further comprising selecting an available capable agent device or a device of the available agent devices capable of performing at least one of the subtasks when adjusted by performing comparisons of subtask requirements and device capabilities.14) The device management engine according to claim 13, wherein selecting comprises performing matrix manipulations on matrices representing device capabilities and subtask requirements.15) The device management engine according to claim 13 or claim 14, wherein selecting a device of the available agent devices capable of performing at least one of the subtasks when adjusted comprises estimating a resource cost of adjusting the device and selecting device having a lowest resource cost of the devices considered.16) The device management engine of any preceding claim operable to receive operational data and to perform additional processing to complete the subtask.17) The device management engine of any preceding claim operable to update function data in a store based on analysis of subtask performance monitoring data.18) A method of performing a machine learning task in an ambient computing environment having a transceiver element operable to send and receive messages over a network fabric of the ambient computing environment; and an intelligent machine learning element, the method comprising:defining, responsive to a scenario prompt an overall objective comprising one or more subtasks;determining available agent devices in the ambient computing environment;determining capabilities of the available agent devices;identifying available capable agent devices configured to perform at least one of the one or more subtasks;distributing a first subtask function data to at least one available capable agent device to perform at least one subtask of the one or more subtasks.19) The method of claim 18, further comprising:identifying available agent devices capable of performing at least one of the subtasks when adjusted;adjusting at least one device of the available agent devices capable of performing at least one of the subtasks when adjusted, to provide an adjusted device;responsively distributing at least subtask function data to the adjusted device;activating the adjusted device to perform the at least one of the subtasks.20) A computer program comprising computer program code to, when loaded into a processor and executed thereon, cause the processor to perform the method of any of claims 18 or 19.

Images