6.2.2. Capabilities

Capabilities are keys to enable specific agent API functions like migration. A capability consists of a service port, a rights bit field, and an encrypted protection field generated with a random port known by the server (node) only and the rights field. The rights field enables specific rights. e.g., the right to negotiate a higher privilege level. A capability is created by the respective service (e.g., the platform itself) by encoding the rights field in a secure port using a private port and a one-way function, shown in Figure 7. Major issues are the secret handling of capabilities on agent migration (requiring secured channels) and passing the right capability to an agent. A broker server is commonly required to distribute and pass capabilities to agents based on classical authorisation and authentication.

**Figure 7.** (**Top**) Capability format. (**a**) Capability creation by encoding private security port and new rights field. (**b**) Capability checking by encoding requested rights field and private security port and comparison with provided security port.

Capabilities enable fine-grained control of operations that can be performed by agents and allow loosely coupled self-organising systems, e.g., participation in chats. In self-organising systems, the identity of agents is not of primary interest. Instead the actions they can perform are of primary interest.

### *6.3. Chat Bots as Mobile Agents in Both Worlds*

Mobile agents are used in this work for distributed data processing and data mining in the real and virtual simulation world seamlessly. It is assumed that the real-world environments consist of communication access points (i.e., beacons, e.g., using WLAN and WWAN communication technologies) and mobile devices (smartphones, IoT devices). Commonly there are no globally visible organisational and network structure, i.e., agents cannot rely on a network world model to reach and identify specific devices. Each *JAM* node provides connectivity information, i.e., a list of all connected *JAM* nodes. Commonly, *JAM* nodes are connected peer-to-peer in mesh-like networks via TCP/HTTP or UDP connections.

Agents can communicate with each other either by exchanging tuples via a tuple space database or by using signals (lightweight messages) that can be propagated remotely along agent migration paths. Tuple space access is generative communication, i.e., the lifetime of tuples can exceed the lifetime of the generating agent. Additionally, tuple space communication is data-driven and anonymously (sender and receiver need no knowledge about each other).

Mobile agents, e.g., chat bots, can be used to carry information from one location to another. Moreover, mobile devices carrying mobile agents can be used to collect, carry, and distribute data within large regions via tuple spaces, shown in principle in Figure 8. The virtual simulation world is just another region in the mobility regions of agents, and chat bots performing crowd sensing can migrate between real and virtual worlds seamlessly.

**Figure 8.** Virtual simulator world connected to spatially distributed non-mobile beacons, mobile devices connected temporarily to beacons (cellular or local WIFI networks), and mobile agents (crowd sensing and chat bots) used for wide-range interaction.

### *6.4. Chat Bots and Human–Agent Interaction*

Mobile agents can migrate between different devices. The main goal of explorer agents is to collect crowd and social data. This data can be retrieved by device sensors (including aggregated virtual sensors) and information provided by users. Privacy and security have to be addressed. Among device sensor data like position, velocity, and ambient light, which can be collected by mobile explorer agents automatically, user data can be gained by a human–agent dialogue chat via a WEB Browser or Android/iOS App (see Figure 9). Therefore, an explorer agent is capable of interacting with humans by performing textual dialogues (question–answer surveys). Due to the distributed and parallel processing of loosely coupled agents filtering and scheduling of agent dialogue request has to be performed. On each device participating in crowd sensing there is a mediator agent that manages and assesses interaction requests from incoming (explorer) agents. Passed requests are forwarded to a user–bot chat dialogue. Responses to questions (requests) are passed back to the requesting explorer agents.

**Figure 9.** (**Bottom**) Chat dialogue of the JAM App showing messages and questions from chat bot agents and principle mediator agent behaviour scheduling the user chat (**Top**).

Each agent migrating to a device operated by humans (i.e., smartphones, navigation computer, or fixed terminals) can ask questions via the APP tuple space by inserting a question tuple, which is handled by the node mediator agent. The tuple space enables data-driven communication between agents that have different roots, a situation arising in opportunistic crowd sensing. See [35] for details on tuple-space communication.

A question request tuple is evaluated by the mediator agent performing security and privacy checks, finally passing the question to the chat blog waiting for human participation. The answer (if any within a defined timeout) is passed back to the original requesting agent by an answer tuple, again previously checking privacy and security concerns.

The principle communication format via the tuple space is shown in Algorithm 1. The dialogues can be composed of dialogue trees, i.e., questions and messages that can be dynamic and can depend on previously answered questions or environmental perception (sensors).


**Algorithm 1:** Communication of remote chat bot agents with user dialogue mediator agents via an

In doubt, the question or answer is discarded or modified (e.g., filtered or annotated with additional warnings). The mediator agent performs question request scheduling to satisfy agent requests and human interaction capabilities (high question rates will decrease the user interest and motivation to answer questions). Additionally, the mediator agent has to monitor chat bot dialogues by using natural language processing (NLP).

A typical chat dialogue is shown in Figure 9. It consists of question–answer snippets processed and controlled by the mediator agent operating on each device with user interaction. This chat dialogue is embedded in a *JAM* platform application software (*JAMapp*). *JAMapp* is available for smartphones or as a WEB-page that can be processed by any *JavaScript* capable WEB browser.

The mediator agent can pass questions (or just stand-alone messages) to the user chat via a simple platform API providing a question text, possible answers or input fields, and a callback function handling the result, shown in Algorithm 2.


The following Definition 1 describes the dialogue script passed to a chat bot agent that is used to perform the crowd sensing on mobile devices by the chat bot agents. The question dialogue is dynamic: (1) Some questions are only presented based on answers of previous questions → *cond* function, and (2) some question texts are updated based on previous answers → *eval* function replacing text variables \$ in the question text with values returned by an array. The optional *param* function can be used to change a default value or a choices list (returning an array of alternatives). Among user dialogues, device sensors (e.g., light intensity or position) can be requested within the dialogue script, too.

**Definition 1.** *Survey job type definition.*

```
type dialog = message|question|sensor 
type message = { message:string } 
type question = { 
 question:string, 
 choices?:string [] | number [], 
 value?:number|string, 
 eval? : function (script) -> string [], 
 param? : function (script) -> string|string [], 
 cond? : function (script) -> boolean, 
 tag : string, 
 answer?: string 
} 
type sensor = { sensor:string, default?:*, answer?:* } 
type script = dialog [] 
type job = {script:dialog [], action: function}
```