JP2018528701A - Data transmission via mesh network topology - Google Patents

Abstract

The present disclosure teaches providing a wireless communication module. The wireless communication module includes a wireless communication interface configured to operate in different communication relationships as a master device and as a slave device at different times using the same communication protocol. The interface is also configured to switch between a master device mode and a slave device mode.

Description

  The present disclosure relates to a connection form (topology), and more specifically, relates to a method for connecting an electronic device in a mesh-type connection form, that is, a PICONET connection form, but is not limited thereto.

  In traditional wireless communication schemes such as Bluetooth® and Bluetooth® Low Energy (also known as Bluetooth® Smart Technology), individual devices act as masters or slaves in specific communication relationships. Can act as a fulfilling node. Thus, each node assumes a master role or a slave role. Therefore, in a certain communication pair, one node operates as a master and the other operates as a slave. In the context of Bluetooth® Low Energy, the master is sometimes called the central device and the slave is sometimes called the peripheral device. One master (or central) node can be a master for several slaves (the exact number is often limited by the implementation of individual chipsets), and some nodes can have multiple It can be registered as a slave (or peripheral) to the master, but can only operate as a slave to one master at a time.

  Bluetooth (R) and Bluetooth (R) Low Energy are other low speed wireless personal area networks (LR-) such as Zigbee (R) and Thread (R) that are both based on the IEEE 802.15.4 radio protocol. The operation is fundamentally different from WPAN).

  The following patent document 1, the following patent document 2, and the following patent document 3 describe examples of electronic cigarettes having a communication function.

  Several specific aspects and embodiments are set forth in the appended claims.

  According to a first aspect, there is provided a wireless communication module including a wireless communication interface configured to operate as a master device and a slave device in different communication relationships at different times using the same communication protocol. The interface can be configured to switch between a master device mode and a slave device mode. This wireless communication module can then form a mesh with other similarly configured modules, and using a time division scheme, different modules in the mesh can take on different personalities in the mesh at different times. I am doing so.

  According to another aspect, a wireless communication network comprising first and second wireless communication modules can be provided, wherein the first module operating in slave device mode is a data token to be transmitted across the network. The second module operating in the master device mode receives the advertising data transmitted by the first module, thereby transmitting the advertising (sending information necessary for network management periodically) The second module that receives the data token and operates in the slave device mode transmits advertising data representing the data token to be transmitted across the network, and the first module that operates in the master device mode is the second. Advertised sent by other modules Receive ring data, thereby receiving the data token. Thereby, a meshing scheme for inter-module communication can be achieved.

  According to a further aspect, there can be provided a method for transmitting data over a mesh network, wherein the method includes a data token in the advertising data of the first node transmitted by the first node. Adopting the advertising state in the first node of the mesh network and the standby state in which the advertising data of the first node is received by the second node are within the wireless communication range of the first node. At the same time as at least part of the period of the advertising state at the first node, and the data token received in the advertising data of the first node is transmitted by the second node. Advertisements included in the advertising data of node 2 The grayed state, in the second node, after receiving the advertising data of the first node, and a step of adopting, a. Thereby, it is possible to provide communication between nodes in the network using a time division meshing scheme.

  According to another aspect, passing the data token from the first wirelessly connectable device to the second wirelessly connectable device and controlling this aspect of operation of the third wirelessly connectable device. Using a token. The third wirelessly connectable device has established a communication relationship with the second wirelessly connectable device. Thereby, interactions between independent devices can be used to influence the behavior of the future interaction between one of these devices and the third device.

  According to the further aspect, the following operation | movement methods and aerosol supply apparatuses can be provided. The method includes operating a wireless communication interface of the device in a standby mode, receiving a data token from a wireless communication interface of another aerosol supply device during operation in the standby mode, and an aerosol supply device. Storing the received data token and providing the stored data token to the application operating device to control aspects of the operation of the application operating device. Thereby, the aerosol delivery device can be configured such that tokens affecting the interaction to be transmitted between them are passed to the application device.

  According to another aspect, the following aerosol delivery device can be provided. The aerosol delivery device includes a wireless communication interface operable in a standby mode to receive a data token from a wireless communication interface of another aerosol supply device, a data store operable to store the received data token, The wireless communication interface is further operable to transmit received data tokens to the application operating device operatively associated with the aerosol delivery device to control aspects of operation of the application operating device. . Thereby, the aerosol delivery device can receive and store data packets that affect the behavior, and behave in response at least in part to the data packets that are later provided to the application device and affect this behavior. The application can be executed.

  According to another aspect, requesting a token stored in the connected device from a wirelessly connected device as a result of device-to-device interaction between the connected device and another device; Receiving a requested token from a wirelessly connected device; providing the token to a remote service; receiving a profile from the remote service; and relating the received profile to the wirelessly connected device. Performing a comparison or interaction with the profile. Thereby, one device can execute an application function corresponding at least in part to a token stored by the connected device based on previous interaction between the connected device and another device.

  Embodiments of the present teachings will be described, by way of example only, with reference to the accompanying drawings.

It is a figure which shows an advertising protocol roughly. FIG. 2 schematically illustrates an example device environment. It is a figure which shows the functional component of a node roughly. FIG. 3 schematically illustrates a protocol stack. It is a figure which shows a scan response timing schematically. It is a figure which shows mode scheduling roughly. It is a figure which shows the mesh of a node roughly. It is a figure which shows the mesh of a node roughly. It is a figure which shows roughly the example of mounting of a mesh type node connection form. It is a figure which shows roughly the structural example for the interaction between apparatuses using a meshing system. It is a figure which shows an advertising interaction roughly. It is a figure which shows an advertising interaction roughly. FIG. 5 schematically illustrates interactions based on data exchanged via advertising in a meshing manner. FIG. 5 schematically illustrates interactions based on data exchanged via advertising in a meshing manner.

  While the presently described scheme is susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and are described in detail herein. However, the drawings and detailed description thereof are not intended to limit the scope of the invention to the particular forms disclosed, but rather, the scope of the invention is defined by the appended claims. Needless to say, all modifications, equivalents, and alternatives falling within the spirit and scope of the invention are included.

  The present disclosure relates to a modified form of wireless communication behavior. In accordance with the present teachings, a device can be configured to use a Bluetooth® or Bluetooth®-like communication protocol, and using a communication protocol for communicating with the device. It may be transparent to other devices and can operate as both a master / central device and a slave / peripheral device in different communication relationships at the same time based on time division.

  In some examples, the device is an aerosol delivery device such as a so-called “electronic cigarette”, sometimes known as an electronic nicotine delivery device (END device), with electronic equipment that allows it to communicate with other communication devices. possible. In other examples, the device may include an electronic business card or other portable device, which has functions related to the ability to interact in a mesh-like manner between multiple of those devices. Sometimes.

  In this example, the device uses Bluetooth® Low Energy (“BTLE”), but other Bluetooth® protocols or protocols similar to Bluetooth® utilize this teaching. be able to. Bluetooth® is a wireless technology standard for short-range communication between properly enabled devices. BTLE is a variation of the original Bluetooth® system designed to save more power when in use for extended battery life and / or small battery applications. Both Bluetooth and BTLE operate in the 2.4 to 2.485 GHz UHF Wireless Industrial Scientific and Medical (ISM) band, so-called wireless personal areas for interconnecting devices over short distances Designed to create a network (PAN). BTLE uses a modified version of the Bluetooth stack for communication, and as a result, unless one device implements both protocols, BTLE devices and conventional Bluetooth devices Are not directly compatible. Both the Bluetooth® standard and the BTLE standard are maintained by the Bluetooth® Special Interest Group (SIG). The present disclosure is provided in the context of implementing BTLE using portions of the Bluetooth v4 specification related to BTLE. However, those skilled in the art will appreciate that the present teachings can be applied to other Bluetooth® systems such as the so-called Classic Bluetooth® definition, also described in the Bluetooth® v4 specification. You will understand. Also, it should be understood that the present teachings can be applied to technologies that are not compliant with the overall Bluetooth® specification, but still behave in a manner similar to Bluetooth®.

  For example, a non-Bluetooth system that still uses an advertising configuration based on Bluetooth® Low Energy Generic Access Profile (GAP) and thus substantially has an advertising structure as shown in FIG. can do. FIG. 1 shows an advertising structure, in which a peripheral (or slave, remote, or secondary) device is connected to a peripheral (or slave, remote, or secondary) device during the advertisement period. The advertisement period is advertised, and the advertisement period is separated by the advertisement interval. The advertisement may include data for transmission, indication that there is data for transmission, or no data reference at all. To receive the advertisement, the central (or primary, or control) device looks for and scans for advertisements during the scan window. Multiple scan windows are separated by scan intervals. The relative duration of the scan interval and the advertisement interval is altered by the decision that the interval in one device type is constant and the other is changing, or both are changed, which is determined by the advertising protocol. Can be set by a standard or rule set for implementing. By providing this relative variation in the scan interval and advertisement interval, even after several advertisement intervals and scan intervals, even if the initial advertisement period does not overlap with the initial scan window, An advertisement period that overlaps with the scan window will occur, so that a connection can be initiated between the central device and the peripheral device.

  A first example of a device environment 1 that can utilize the present teachings is shown in FIG. In this example, a plurality of nodes 2 a to 2 e exist in the device environment 1. Some of the nodes 2 are interconnected via radio links indicated by dotted lines 4. However, not all nodes 2 are directly interconnected with each other's nodes. Rather, nodes 2 are interconnected in a mesh pattern with scatternet data flow. Thus, if a message is passed from node 2a to node 2d, it will be seen that the message is passed through nodes 2b and 2c (and possibly 2e as well) to reach node 2d. . From some perspectives, it may be appropriate to describe these interactions as PICONET as an alternative to using meshing or mesh-like interaction descriptions. For ease of reading, the term mesh is used throughout this specification.

  In order to achieve such a mesh communication structure, a device consistent with the present teachings can assume more than one persona and can therefore belong to more than one BTLE communication relationship, and A device can operate as a central or peripheral device in one BTLE communication relationship and can operate as a peripheral device in another BTLE communication relationship. In order to manage the simultaneity of these different personas, the apparatus of the present teachings can operate to switch between two personas so that only one persona is employed at a time. Switching between personas is done frequently enough that the devices that form the communication relationship maintain each communication relationship without concluding that the device is no longer available and closing those communication relationships. Is called.

  Switching between personas within a given device occurs on a time scale that meets the requirements from a particular application for that device. As illustrated with respect to FIG. 1 above, there are random elements in this switching. However, the time range over which this random element can operate is set according to application requirements. For example, to provide high-speed data transmission through the device mesh, persona switching occurs relatively frequently. For example, in an implementation based on interaction with devices associated with users in a transient location (devices are electronic business cards in network conferences, or END devices in a social setting, etc.) It may be configured to switch roles every time. On the other hand, for higher power efficiency, and when the data transmission rate through the mesh is less important, relatively infrequent persona switching can be used, possibly once per hour. The situation is appropriate to switch roles only twice. Also, the relative duration of the peripheral and central roles can be changed according to factors that apply to the implementation environment. Thus, while the central persona is active, the device transmits data as part of the advertising packet, and while the peripheral persona is active, the device waits for other devices to advertise the data packet.

  Furthermore, a device according to the present teachings can have multiple central personas that can be used to communicate on different meshes or increase the total number of peripheral devices, The devices of the present teachings can maintain multiple coupling relationships with these peripheral devices at once, beyond the limitations imposed by the particular Bluetooth chipset being used. These multiple central personas can be implemented using the persona switching scheme outlined above or by implementing multiple BTLE MCUs.

  By using such a technique, for example, the interconnection between the nodes 2 can be performed in a form in which the node 2a operates as a central node and the node 2b operates as a peripheral node in the first BTLE relationship. it can. The node 2b can also operate as a central node in a second BTLE relationship that specifically treats the node 2c as a peripheral node. Node 2c can then be a central node in a third BTLE relationship that includes nodes 2d and 2e as peripheral nodes. Furthermore, the node 2d can be a central node in the fourth BTLE relationship including the node 2e as a peripheral node. Of course, other orderings can be implemented as to which nodes function as central and peripheral nodes in various possible node relationships. For example, the connectivity shown in FIG. 1 allows the node 2b to function as a central node in a BTLE relationship in which the nodes 2a and 2c are peripheral nodes, and the node 2d to be the central in a relationship in which the node 2c is a peripheral node. It can be realized alternatively by causing the node 2e to function as a central node in a relationship in which the nodes 2c and 2d are peripheral nodes. As can be seen from the following discussion, the arrangement of relationships for configuring the mesh can be determined on an ad hoc basis depending on which node becomes the central node as a result of the relationship establishment process.

  The mesh scheme described in this disclosure allows small data packets or tokens to be exchanged between nodes without having to establish a complete BTLE coupling relationship between the nodes. Thus, such tokens are arbitrary based on a transient or non-persistent node-to-node relationship where the peripheral node-to-central node relationship lasts only long enough to send and receive tokens. May overflow in a mesh composed of two or more nodes. This scheme does not prevent some or all of the nodes in the mesh from establishing a connection relationship (also known as pairing). Such a coupling-based scheme can be used, for example, in situations where a larger data capacity needs to be transmitted between nodes in the mesh than can be accommodated using tokens.

  As shown in FIG. 2, an additional node 6 may be provided. Node 6 need not have any knowledge or capability regarding node 2's meshable interconnectivity, but instead implements a conventional communication protocol. Thus, in this example, node 6 implements a conventional BTLE interface, and therefore with one of meshable nodes 2 such that node 6 acts as a central node and node 2 acts as a peripheral node. Connection 6 can be established.

  Thus, it can be seen that the scheme of the present teachings allows a Bluetooth or BTLE based mesh to be established without a controller providing a core node for a star topology. Meshes can interact with non-mesh devices, but this interaction can be continuous or intermittent, and non-mesh devices can establish, control, or There is no need to have any role to set.

  Therefore, by establishing such a mesh network, various nodes 2 can communicate with each other, and information can be passed to other nodes within range using existing communication protocols such as BTLE. it can. However, as can be seen from the discussion, the node is a modified version of the Bluetooth hardware implementation that uses the Generic Attribute Profile (GATT) Notification to achieve this ad hoc meshable behavior. Is used. As can be appreciated from the present teachings, this modification also includes additional functionality that conforms in many respects to standard communication protocols but is provided, for example, using scripts to achieve device-to-device interaction as described herein. By using a control circuit implementation, this can be accomplished by implementing a modified hardware, firmware, or software implementation of the protocol. Additional functionality can be introduced using modified hardware, which requires the use of non-standard hardware, but this modified hardware shares personas in a time-sharing fashion. It is possible to provide both modes on a full-time basis without having to The control circuit may be a hardware circuit having the functionality provided by its configuration, such as an application specific integrated circuit (ASIC), or a programmable that operates under the control of firmware and / or software. It may be a microprocessor (μP) or a microcontroller (MCU).

  FIG. 3 schematically shows functional components of each node 2. Each node 2 has an antenna 10 for transmitting and receiving a BTLE signal. The antenna 10 is connected to a BTLE control circuit 12 such as a BTLE MCU. The control circuit 12 receives data for transmission from the device core function processor 14 and provides received data to the device core function processor 14, which operates with, for example, the memory 16 and / or the I / O element 18. Then, the core calculation function of the node 2 is executed. In FIG. 3, the functional components of node 2 are shown to interact directly on a link basis, but since FIG. 3 is essentially schematic, this description is based on, for example, the functionality on a bus interconnection basis. Of course, alternative arrangements of components are also included. Of course, one or more of the functional components shown may be provided by a single physical component, and a functional component may be provided by multiple physical components. is there.

  Of course, with respect to the functional components related to the core computing function of node 2, the nature and use of these components may vary depending on the nature of the device itself. In the example of a device that corresponds to a particular node that is an electronic business card, the core computing function can store, display, and transmit control options for business card information, send and receive such information (this includes control circuit 12 and antennas). In addition to being performed). In the example of the device corresponding to node 2 which is an END device, the core computing function is responsible for the exchange of information tokens between END devices, monitoring and reporting of device charge level and / or nicotine fluid level, interaction of loss and discovery As well as usage records. Thus, it will be appreciated that the core calculation function may be different from the core function of the device as perceived by the user. For example, in the case of an END device, the core function perceived by the user seems to be an aerosol generation function for delivering nicotine, and the calculation function is an additional, supplemental to the core function perceived by the user. Or secondary.

  FIG. 4 schematically shows the protocol structure implemented by the control circuit of each node 2. The protocol structure shown in FIG. 4 corresponds to a Bluetooth (registered trademark) stack, and this Bluetooth (registered trademark) stack is GATT (generic attribute protocol), GAP (generic access protocol), SM (service manager protocol). , GATT / ATT (low energy attribute protocol), L2CAP (logical link control and adaptation layer) and link layer. In this example, the link layer operates on a low energy radio frequency (LERF) basis. As shown in FIG. 4, this protocol stack can be conceptually divided between the so-called host layer and controller layer. The controller part constitutes the lower layer required for physical layer packets and associated timing. The controller portion of the stack can be implemented in the form of an integrated circuit, such as a SoC (system-on-a-chip) package with an integrated Bluetooth® radio.

  Layer implementations relevant to understanding the present teachings include link layer, L2CAP, GAP, and low energy attribute protocol.

  The link layer controller is responsible for low level communication via the physical interface. The link layer control device manages the sequence and timing of transmission / reception frames, and communicates with other nodes regarding connection parameters and data flow control using a link layer protocol. The link layer controller also processes frames transmitted and received while the device is in advertising mode or scanner mode. The link layer controller also provides a gatekeeping function to limit exposure and data exchange with other devices. If filtering is set, the link layer controller maintains a “white list” of authorized devices and ignores all requests for data exchange or advertising information from other devices. In addition to providing security features, this can also help manage power consumption. The link layer controller communicates with the upper layers of the stack using a host, controller, and interface (HCI) if the layer implementation is not co-located.

  The logical link control and adaptation layer protocol (L2CAP) component provides data services to higher layer protocols such as security manager protocol and attribute protocol. The L2CAP component is responsible for the protocol that multiplexes the protocol and divides the data into sufficiently small packets for the link layer controller and, conversely, the demultiplexing and restructuring operations. L2CAP has a back-end interface for GAP, which defines a comprehensive procedure related to the discovery of BTLE devices and the link management aspect of connections with other BTLE devices. GAP provides an interface for applications to set and enable different modes of operation such as advertising or scanning, and to initiate, establish and manage connections with other devices. Accordingly, GAP is used to control Bluetooth (registered trademark) connection and advertising. GAP controls the visibility of devices and determines how the two devices can (or cannot) interact with each other.

  ATT (low energy attribute protocol) is optimized for the small packet size used in Bluetooth® low energy, and attribute servers are associated with attributes and attributes for attribute clients. It is possible to publish a set of values. These attributes can be discovered, read and written by the peer device. GATT provides a framework for using ATT.

  As is apparent from the above discussion, the present teachings facilitate the mesh-type interaction of multiple devices using an advertising process, for example, unlimited for the purpose of spreading data over distance and time. Information can be spread among a number of devices.

  In the context of this example, an application running on a device that communicates via the mesh-type structure described herein can receive a specific scan response payload (in the packet) that responds to the scan response sent by that device. Data body) can be requested or awaited. This scheme is used in conventional Bluetooth® implementations to send device name and other identification details. However, in this scheme, this scan response is defined as a 31-byte data packet, also called a token, but this scan response is an ID associated with a variable that triggers a particular response or action when read by the application. Used to share information. The timing of such a request is shown in FIG. As can be seen, the scan response request is sent by the central device during the advertising interval and the scan response data is provided by the peripheral device before the next advertising interval begins.

  By implementing the method of the present teaching, data exchanged through the physical layer is indistinguishable from normal BTLE traffic at that level. Also, higher layers are modified to accept this device meshable interaction, but non-mesh applications are enabled via BTLE using devices that match this teaching. Can communicate.

  Also, a device that uses only a conventional BTLE stack (such as node 6 shown in FIG. 2 above) can communicate with a device 2 that uses the meshable scheme of the present teachings. At this time, the conventional BTLE device can receive data from the meshable device 2 without the BTLE stack in the conventional BTLE device having any knowledge about the mesh-type interaction of the device 2. The data received by the conventional BTLE device may have been transmitted from the directly connected device 2 or another device previously connected to the directly connected device 2 via the mesh The data may have been stored or cached in the meshable device 2. The source of such mesh transfer data may be another mesh-type device 2, or may be another conventional BTLE device that is connected to or connected to the mesh-type device.

  FIG. 6 schematically illustrates the behavior of each node 2 in connection with managing the dual persona nature of each node 2 to establish a connection as both a central node and a peripheral node. Since BTLE provides two modes of operation in the presentation layer, one mode of operation still corresponds to each of the central and peripheral roles, but in this example node 2 An advertiser that alternates between and broadcasts to advertise its capabilities as a peripheral node, and an observer activity to look for other potential peripheral nodes that the node can connect to as a central node Realize both. While operating as an observer, the node operates on the received broadcaster advertisements and follows normal BTLE behavior, for example as described in BTLE GAP (Generic Access Profile). The connection can be established as a central node. While performing the advertiser's broadcasting, the node can establish a connection as a peripheral node with an observing node that responds to become the central node. As discussed above, this time division between the central and peripheral personas continues after the connection between the devices is established. This allows a single device to operate in both modes on a continuous basis despite being time multiplexed based on a single BTLE MCU in the device.

  Thus, a device (node) that is configured to provide this example meshable interaction uses a standard BTLE GATT (Generic Attribute Profile) specification in combination with a modified GAP. Two modes of operation related to the double persona nature are employed. As discussed below, this node alternates between advertising as a peripheral node and listening as a central node so that it can easily connect to other nodes in both central and peripheral modes. Typically, a device may be pre-programmed to use a specific UUID associated with a specific device mesh that the device intends to join (in BTLE terms "service"). And already has an indication of the identification information of the mesh. For example, all electronic business card devices may be programmed to use the same UUID, and similarly, all END devices from a particular brand, type, or manufacturer will use the same UUID. May be programmed. In this context, to identify an active persona or mode, a node uses a node ID code that uniquely identifies the node in the mesh. Node ID and UUID (essentially mesh ID or group ID) codes are kept in the firmware of the device and are inserted into the advertising packet along with the data making up the token, and between and between devices It may also be referenced in scan response requests and scan response messages as part of advertising under GAP interaction.

  While operating as a central node, a node can adopt scanner, initiator, and master states, and while operating as a peripheral node, a node can employ advertiser and slave states.

  FIG. 6 also shows the relative advertising time and observation time of multiple nodes. The illustrated scheme tends to avoid (but not necessarily eliminate) multiple nodes within range of each other from broadcasting simultaneously. In this example, the observation duration is controlled to be in the range of 0.01 ms to 5 s, and the advertising period is a fixed duration that may be in the range of 0.5 s to 10 s. In other examples, the advertising duration may be variable and the observation duration may be in a different range, overlapping range, or subset than the exemplary range given above. Such time offset can be adjusted by adjusting the length of the interval, such as by adjusting between nodes, or by each node providing an irregular time interval between each mode transition, etc. Can be achieved in any way. Such interval length adjustment can be done by selecting one of several possible interval lengths for each interval or using some form of interval duration random number generator.

  If a node is observing for the purpose of establishing its role as a central node in the mesh, this node is considered as a node with no meshing capability when waiting for advertisements from potential neighboring nodes. Works exactly the same. Thus, a node operating in this mode can also be a central node for a conventional BTLE device without the meshing capabilities of the present teachings.

If a node is advertising in the mesh for the purpose of establishing its role as a peripheral node, this node advertises using a structure based on BTLE GAP data. However, the BTLE GAP structure has been modified to include mesh-specific information that can be recognized by a meshable device that receives the advertisement. The mesh-specific information can include the following fields:
-The node ID of the advertising node.
– The packet sequence number of the packet waiting for transmission from that node. This is used to avoid duplication depending on the application. This can simply be a packet sequence of packets sent from that node (eg, if the application only requires flooding the payload or token from the advertising node to other nodes), but the application May be unique for a given mesh (group ID), time window, and / or other uniqueness range.
The source node identifier of the packet with that packet sequence number. To reflect that the token currently being passed may have been sent from a different node than the node currently passing it.
The destination node identifier for the packet with that packet sequence number. Depending on the implementation, this may be a single node (corresponding to some form of routed behavior) or “all” nodes (corresponding to flood type behavior).
The group ID of the source node for the packet with that sequence number. This is used to allow multiple mesh networks to coexist in the same physical space (as mentioned above, this group ID typically uses a BTLE UUID, but can be Group ID field can be defined and used).
The lifetime or expiration time of the packet with that sequence number.
-Payload. Data specific to a particular application—for example, data related to an electronic business card or END device application.

  According to the BTLE data processing scheme, if a given application payload item is too large to be a single packet, the payload item is split and distributed among multiple packets, and then reconstructed at the (each) destination node Is done. In such an application, a coupling may be established between the nodes to provide better transmission management for this large data capacity.

  FIG. 7 schematically shows the connectivity pattern between several nodes N1, N2, N3 and N4. In this figure, node N1 is outside the range of direct communication with node N4. Different operation modes of the nodes are represented by respective element control chips (CC) 22 and mesh chips (MC) 24 of nodes N1 to N4. The control chip represents a node MCU that operates to communicate with a conventional BTLE device, such as device 6 shown in FIG. A mesh chip represents a node MCU that operates in both central and peripheral modes to communicate through the mesh.

  In the example of FIG. 7, node N1 has a set of bits in the advertisement data field indicating that this node has data to transmit. Depending on the advertising and observation schedule at each node, node N2 becomes the first node in direct communication range with N1 and waits as the central node following node N1 with the advertisement data field set. Therefore, when the node N2 is in the central mode, the node N2 receives the advertising data that is advertised while the N1 is in the peripheral mode. This advertising data received by N2 may be used by N2 in connection with applications running on N2 or otherwise associated with N2. In addition or alternatively, node N2 may be prepared to cache advertising data and send it forward as advertising data at a future opportunity for node N2 to adopt a peripheral persona. Thereby, the advertising data transmitted from N1 can be passed forward as advertising data from N2, and the advertising data is then sent to node N3 when N2 is advertised as a peripheral node and N3 is waiting as a central node. Received by. The advertising data sent from N1 can then be used and / or passed by N3 and finally arrives at N4 in the same way.

  Note that in this implementation, advertising data effectively floods the entire mesh. Therefore, if N1 happens to wait as a central node at the same time as N2 advertises as a peripheral node, the advertising data returns to N1 and is passed forward to N3 through the mesh. In this situation, either node N1 or any application running on or associated with N1 may simply discard the returned advertising data. Depending on the implementation, the node or application may utilize the returned advertising data in some way, such as using the time between transmission and reception as some form of random interval generator, or Or mesh diagnosis.

  As explained above, transmission over the mesh can be in a more structured format using the coupling established between the nodes. In such a situation, each pair of nodes interacts through an established binding, and a persona switch at each node causes the data received in the binding of which one persona is a member, Use member bindings to enable forward transmission.

  Control over whether data is sent to all nodes (flooding) or data is sent only to selected nodes (routing) can be achieved in several ways. If data is to be automatically communicated to all nodes indefinitely, this can be the default state set for the node. If data is to be sent only to the node that is currently active in the mesh, this can be accomplished either as a default behavior setting on the node or as an application specific setting. In an application specific setting, the application recognizes the mesh and provides control information to the communication stack to indicate the data transmission range. If the data is to be sent only to a specific node, this can be achieved with an application specific setting, where the application is aware of the mesh and enters the communication stack. Provides control information to indicate the data transmission range. This example is configured to operate on a flooding scheme so that data is automatically transferred to all currently meshed devices.

  FIG. 8 provides further explanation of the meshing behavior between nodes. In this example, there are a large number of nodes N11 to N19. The diagram of FIG. 8 represents a given snapshot over time, and shows that different of these nodes currently employ different personas of their respective peripheral and central personas. Has been. At the time shown in FIG. 8, three nodes are configured to be in the central mode, these are nodes N12, N16, and N19, and the remaining nodes are configured to be in the peripheral mode. As can be seen from the above discussion, if any given instance of the same node is present at the same location, the exact number of nodes configured to be in central mode and the identifying information is determined by each node's advertising / It depends on factors such as the scheduling of the observation period and the relative position of each node compared to any other node already configured as either central or peripheral mode. The exchange of data tokens is indicated by the presence of a flag in the figure, and the flag is sent to N12 waiting in the central mode that will receive the advertising data from N11 that includes this data token in the advertising data and transmits it. Passed. This token will be included in the advertising data from N12 when N12 adopts the peripheral persona later. Thereby, the token is passed forward through the mesh and finally can reach each node in the mesh at least once.

  As can be seen from the above discussion, the mesh can change dynamically based on changes in the number and location of nodes in the mesh. For example, if some nodes move away from the rest of the mesh, they eventually lose contact with all the nodes in the mesh and leave the mesh. Similarly, a node that is not active or is in a power saving non-radio mode will lose contact with other nodes in the mesh and leave the mesh. In addition, new nodes that were not previously part of the mesh may join the mesh when they come within the range of nodes in the mesh or when powered on within the range of nodes in the mesh. it can. Also, as can be seen from the above discussion of persona switching, a node that is already in the mesh and operates as a peripheral node in the mesh also operates as a central node in the mesh at different times. In implementations where the mesh employs a join relationship such that a particular node has a role defined as the central node in some joins and a peripheral node in other joins, If a position is changed for a node in the mesh, that node may substantially leave the mesh because all established connections may stop the range operation for the new position. Such a node then resumes attempting both observation and advertising until it establishes one or more new connection relationships with other nodes of the mesh connected by the connection.

  As will be appreciated by those skilled in the art, Bluetooth® and BTLE provide security for inter-node communication coupling. This is not true for the transmission of purely advertising-based tokens in the form of advertising data, unless such transmission of tokens leads to the establishment of a binding relationship. In this example, even if a join relationship is used, the node should establish such a join without requiring user input to verify reliability between different nodes or devices. Can be configured. Rather, in this example, a particular type of device or node may be configured to pre-trust all other devices or nodes of that particular type. For example, if the device is an electronic business card, each electronic business card is identified as an electronic business card from a given manufacturer, manufacturer group, brand, brand group, model, model group, or given All other devices identified as being compliant with an electronic business card standard or group of standards can be configured to be trusted. In the case where the node is an END device, each END device is identified as an END device from a given manufacturer, group of manufacturers, brand, brand group, model, model group, or a given END All other devices identified as compliant with a device standard or group of standards can be configured to be trusted.

  Such a trust pattern can be supplemented with inherent control over the amount of personal data that the device is allowed to store / transmit. For example, the END device can be configured by the owner not to retain any information identifying the owner or to prevent sharing information. This does not prevent the END device from interacting with other END devices to exchange information that can be used for the loss / discovery function, and the END device has information about itself. Does not prevent the realization of group interactions between END devices of the same brand or model, for example as discussed below. In the example of an electronic business card, the user retains or shares only information that is publicly discoverable in other ways, such as name and business contact details or the user's social mobile platform address The device can be restricted to allow The social mobile platform address can take the form of a link to a user's profile on a social networking platform, such as LinkedIn ™ or other business social networking platform. Electronic business card users can also choose to activate the device only at selected times, such as when attending professional educational events or social gatherings, so that the electronic business card can be Information can be prevented from being shared with any compatible electronic business card that may be present at other locations, such as other public transportation.

  In other examples, trust may be an explicit function for the user, and the user may be required to actively accept or request to establish a communication connection with another node.

  For example, when a particular node or device is configured by the user to communicate with the user's conventional BTLE device, such as a smartphone, a fablet or a tablet device, the user's meshable device and the conventional BTLE device Can be secured in the same manner as other conventional BTLE pairings to establish a communication connection.

  Therefore, by using the method of the present teaching, by adopting the double persona structure, it is possible to provide a device capable of mesh-type interaction with other similar devices. In structure, the device can operate on a time-sharing basis as both a master (central device) and a slave (peripheral device) to communicate with other similar devices, while the conventional one without dual persona capability Of course, the device can also operate as a slave / peripheral device.

  This scheme can be used to facilitate device-to-device interaction between a range of devices for a range of purposes. As described above, examples of devices that can provide such device-to-device interaction using the mesh type or PICONET topology of the above example include electronic business card and electronic nicotine sending device (END device). Can be mentioned.

  With reference to FIG. 9, consider a first example of a system implemented using the meshing apparatus scheme of the present teachings. As shown in FIG. 9, the user device 42 such as a smartphone, a fablet, or a tablet has a communication relationship (indicated by a dotted line 43) with the electronic business card device 44. The electronic business card device 44 may include one or more visible representations on the device to identify the device as an electronic business card and / or details 46 written in the letters of the user of the electronic business card and / or Alternatively, photographic details 48 can be provided. In some examples, the electronic business card device 44 may include an electronic display unit that selectively displays visible representations depending on the operating parameters or power status of the electronic business card device 44. May be.

  The electronic business card device 44 also has a wireless communication function for mesh-type interaction between nodes, consistent with the teachings described above. Therefore, in this example, the electronic business card device 44 has a BTLE function capable of communicating with both the conventional BTLE device and the mesh-compatible BTLE device.

  The user device 42 in this example has a conventional BTLE function, and as a result, the user device 42 and the electronic business card device 44 can establish a BTLE pair combined communication relationship as the communication relationship 43. The user of the user device 42 can change data and / or operating parameters of the electronic business card device 44 via the communication relationship 43. Therefore, the user of the user device 42 can set the electronic business card device 44 and store the user's business contact information. Such business contact information may include any one or more of name, company name, business area, contact details, and user profile links / addresses on social media platforms. it can. Examples of social media platforms that can be referenced by such links or addresses include professional networking-oriented social media platforms such as LinkedIn (TM) or ReseachGate (TM), and Facebook (TM), Instagram General purpose social media platforms such as (trademark), Twitter (TM), VK (TM), or Qzone (TM).

  In this example, the electronic business card device 44 is programmed with a user name, the user's company name, and a link to the user's social media profile. Also, the user's electronic business card device 44 is programmed to communicate with other electronic business card devices only when in the active state. The active state can be triggered by either or both a physical switch on the electronic business card device 44 or a command sent from the user device 42 to the electronic business card device 44 via the communication relationship 43. The electronic business card device 44 can operate in an active state regardless of whether or not the communication relationship 43 is active. Accordingly, the user can turn off the BTLE function of the user device 42 or disconnect the user device 42 from the electronic business card device 44 without affecting the ability of the electronic business card device 44 to operate.

  If the electronic business card device 44 is within the BTLE communication range of other trusted electronic business card devices while in the active state, the electronic business card device 44 will mesh to communicate with those other electronic business card devices. The communication relationship can be established using the network function. This is illustrated in FIG. 9 by additional electronic business card devices 50a-50d. The establishment of roles within the mesh of electronic business card devices 44 and 50a-d depends on the relative advertising schedule of the individual devices. However, depending on the combination, the electronic business card devices 44 and 50a-d can establish mesh communication between them and exchange data according to the business card function of the application programmed in the electronic business card device.

  Accordingly, through the operation of the electronic business card application function, the electronic business card device 44 can transmit the business data of the user to the other electronic business card devices 50a to 50d, and from each of the other electronic business card devices 50a to 50d. The business data of each user can be received. This received user business data can be stored by the electronic business card device 44 until the electronic business card device 44 next activates the communication relationship 43 with the user device 42.

  Once the electronic business card device 44 communicates with the user device 22 and stores the user business data stored in the user device, the data can be viewed using the business data receiving application of the user device 22. In this example, if the stored business data includes each link to the user's social media profile that the user's business card provided the data, the business data receiving application may follow the link to another device. 42 users may be able to view other users' profiles and optionally invite other users to connect using their social media platform.

  Thus, the meshing techniques discussed herein can have several uses to facilitate communication with other mesh-type devices, while smartphones, fablets, tablets, laptops, Of course, it is also possible to directly communicate with a user device having no meshing function such as a computer, a netbook computer, or a desktop computer.

  With reference to FIGS. 10-14, another example of a scheme for utilizing a system implemented using the meshing device scheme of the present teachings will be described. In this example, an END device is used.

  The device-to-device interaction in this example is based on the communication of tokens between any given number of END devices 61, 62 for the purpose of identifying consumers C1, C2, and consumers C1, C2 participates in END device interaction with END devices of other END device consumers via smartphones 65, 66, which can be configured for communication 63, 64 with END devices, for example using BTLE I agree or choose to participate. In this example, a smartphone is considered, but it goes without saying that another user device having a calculation function and a wireless communication function for communicating with the END device can be used. Suitable examples include smart phones, fablets, tablets, laptop computers and netbook computers.

  Therefore, this method can connect the END device 61 of the first consumer C1 to the consumer interaction, and further anonymize this consumer interaction, so that one consumer can Will know nothing other than owning an END device that can communicate with their END device. The END device 61 allows this interaction through an application 69 running on the consumer's smartphone 65, and the smartphone interacts with other consumer's END devices or applications without the END device. There is no ability.

  Once enabled, the END device interaction is based on proximity to other compatible END devices. When two or more compatible END devices come within range of each other, they interact using the device-to-device mesh interaction described above.

  Thus, this enables the operation of applications that are based on or connect consumers that share the same social circle 60. In this context, the social circle is defined by entering the proximity of each other, and the proximity is defined by the wireless communication range of the mesh-type device interaction according to the above example. In some examples, this range may be on the order of 50 feet (about 15 meters), but it will be appreciated that this may vary based on signal propagation conditions in the vicinity of the END device. This can facilitate, for example, application functions based on multiple proximity interactions with other END devices 62, or application functions based on information related to the geographic region in which the device interaction occurs. . The application 69 can change the behavior of the smartphone application 69 using selection settings for the application 69 and / or the END device 61.

  An example of device interaction between such an application and the associated END device will be described.

  As described above, in order for an application to perform any processing related to consumer interaction, it is necessary that the device interaction of the END device is enabled.

  The example application 69 allows an avatar associated with a consumer's END device 61 to compete in a virtual contest with an avatar associated with another consumer's END device 62. Such virtual competition between avatars allows avatars to develop and / or acquire new virtual abilities that can be used with avatars of other consumer END devices. This avatar can be used in future virtual competitions. Successful such virtual competition can earn rewards and achievement badges within the application.

  In this example application 69, 70, each consumer C 1, C 2 has a set of variables for setting the initial state of the avatar associated with the END devices 61, 62 through the interaction 67, 68 with the application 69, 70. Is provided.

  Then, depending on how consumers C1, C2 set up and use their END devices 61, 62, applications 69, 70 adjust their avatars to customize their competitive capabilities. In this example, the competition may take the form of a virtual competition between avatars, so that the avatar profile may include one or more attacks and / or defensive capabilities or characteristics. In this example, the applications 69 and 70 adjust the avatar ability according to the usage characteristics of the END devices 61 and 62. These usage characteristics have been previously recorded by power settings and applications 69, 70 that can be adjusted to affect the amount of scent present in the aerosol generated by the activation of each device, The number of device activations from the END devices 61 and 62 can be included. How the usage characteristics are adjusted can be based on usage choices in the applications 69, 70 set by the consumers C1, C2. For example, a consumer with a personal purpose of limiting nicotine intake can set a target maximum number of times to activate the device on a daily basis, and the application responds and the target is exceeded. If it is, the avatar's competitive ability can be penalized, while if the goal is not exceeded, the avatar can be rewarded.

  The END device can then be used to access the application's avatar competition feature. If a consumer's END device 61 establishes a mesh-type connection with another consumer's compatible END device 62 within proximity range 60 and validates such a connection, then END device 61 An option may be provided to interact with the END device 62 and the consumer's smartphone 65 to challenge an avatar associated with the other consumer's END device 62 via the application 69. Similarly, another consumer's END device 62 that interconnects with the first consumer's END device 61 provides other consumer options via the smartphone application 70 to challenge the first consumer's avatar. Can be provided.

  In order for such a challenge to be made and accepted, the two consumers need not have any knowledge about each other, nor do they need to interact directly in the real world.

  Both consumers can then decide independently of the other consumers whether to take the challenge that has become feasible via the applications 69, 70, and if such a challenge occurs, Competition between avatars is settled. In the context of this example battle challenge, the avatar associated with the consumer who offered the challenge is the attacker and the avatar associated with the other consumer is the defender. Thus, if both consumers decide to challenge in response to the options indicated by their respective smartphone applications 69, 70, a competition between the two avatars will result, each based on each challenge. The challenger of that competition becomes the attacker.

  The actual avatar interaction is not processed through the device interaction between the END devices 61 and 62 in this example. Rather, once the END devices 61, 62 interact, such as to allow each application 69, 70 to provide a challenge option, each application has sufficient avatar description information associated with the avatar to be challenged. Thus, challenge interactions are handled through separate data services.

  In this example, the application obtains the profile information of the avatar to be challenged necessary for performing the challenge interaction via the cloud service 73. In this example, the cloud service 73 is implemented using an MBass (mobile backend as a service) structure. Based on the information exchange between END devices, the application knows enough information to obtain a challenge avatar profile from the cloud service 73, and then the application can settle the outcome of the competition.

  In this example, the competition result is used by the application to record the winning or losing result for that avatar. The competition result is also provided to the cloud service 73 so that the win / loss result is passed to the challenged avatar application by the cloud service 73 and can be noted in the win / loss result for the challenged avatar. In other examples, the outcome of the win / loss may be recorded only for the challenged avatar, and the outcome of the challenged avatar is not affected by this challenge outcome. In a further example, the challenge interaction to determine the competition outcome may be performed within the cloud service 73, where the outcome is either the challenged avatar and the challenged avatar application or Provided for both.

  The various steps performed by the END device to provide device-to-device interactions that support application performance are shown in FIGS.

  FIG. 11 illustrates the process of passing user and application identifier tokens from the first consumer END device 61 to the second consumer END device 62. As shown in FIG. 11, the first END device 61 advertises using data in step S11-1 in accordance with BTLE GAP during the window period operating in the advertising persona. It is in the form of a token including a user identifier and an application identifier, i.e. 1 UID / 1 APPID. This advertisement is received by the second END device 62 in step S11-3. When the second END device 62 receives this advertisement while in the window operating in the observation persona, the second END device is the center (master) of the first END device in step S11-5. It becomes the role of the peripheral (slave) to the role of. Accordingly, the second END device 62 can process the data in the advertising token, and the second END device 62 stores the received data token 1UID / 1APPID in the storage device of the device itself.

  As can be seen from the above discussion of devices operable to operate in a mesh-type configuration, each of the first and second END devices 61 and 62 employs both an advertising persona and a standby persona at different times. To do. Therefore, in addition to the method shown in FIG. 11 for transferring the data token from the first END device 61 to the second END device 62, the opposite process occurs when the opposite personas match. This is illustrated in FIG.

  As described above, the usage of the END device can be used to change the profile of the associated user's avatar. This process is illustrated in FIG. This process may be followed to update the avatar at appropriate intervals and may be defined by rules governing the performance of the competition. In some examples, avatar updates may occur once a day, once a week, multiple times a day, or multiple times a week. The update frequency may be user configurable and / or may be related to the nature of one or more usage goals.

  In the following discussion, this process is described with respect to the first END device 61 interacting with the application 69 of the first smartphone 65. It goes without saying that the same method can be used for communication between the second END device 62 and the second application 70 of the second smartphone 66.

  This update process starts in step S13-1, and the application 69 transmits a request for the END device 61 to provide usage data to the END device 61. When this request is received by the END device 61 in step S13-3, the END device 61 then provides this usage data to the application 69 in step S13-5. Application 69 receives the usage data at step S13-7 and then uses this data to calculate any changes to the avatar's profile derived from this usage data. For example, in the context of this example where competition between avatars is a form of virtual combat based on attack and defense characteristics, failure to satisfy a specified usage goal will result in the attack and defense characteristics of the avatar's profile May lead to a decline in one or both. Alternatively, or in addition, the attack and / or defense capabilities or benefits may be reduced or disabled. On the other hand, if the usage goal is achieved, one or both of the attack characteristics and the defense characteristics of the avatar profile may increase. Alternatively or additionally, an attack and / or defense capability or privilege may be increased or enabled.

  Once the avatar update is determined, the updated avatar profile is stored in step S13-11. After this process, for example, at the next connection between the application and the cloud service, or as the final step of the process of FIG. 13 (not shown), the application can update the avatar profile for storage by the cloud service. Can be sent to the cloud service. The cloud service can then provide the latest avatar profile to another instance of the application for use in defense against challenges from that user's avatar.

  After any END device interaction described with reference to FIGS. 11 and 12 above, each END device can pass any received advertising tokens to the application on the respective user's smartphone. This process is illustrated in FIG. In the following discussion, this process is described with respect to the first END device 61 interacting with the application 69 of the first smartphone 65. It goes without saying that the same method can be used for communication between the second END device 62 and the second application 70 of the second smartphone 66.

  Referring to FIG. 14, in step S <b> 14-1, the application 69 transmits an inquiry about the token stored in the first END device 61. The END device 61 receives this inquiry in step S14-3, and then provides the token stored in step S14-5 to the application. The application 69 receives a token from the END device 61 in step S14-7, and in step S14-9, identifies an application related to the application from the received token.

  As an alternative, instead of an avatar that retrieves a token from the END device and an application related to the challenge activity, the smartphone's END device management application retrieves a token for the END device, and then associates the associated token with the avatar and challenge activity. Can be made available to the selected application.

  Having identified at least one related token received from the END device 61, then in step S14-11, the application 69 requests an avatar profile associated with those tokens from the cloud service 73. In step S14-13, the cloud service receives the request, and then provides the associated avatar profile to the application in step S14-15. In step S14-17, once application 69 receives a profile corresponding to at least one token, then in step S14-19, application 69 determines the outcome of the competition.

  The competition result is determined according to the challenge rules defined in application 69. As described above, in this example, the competition can take the form of a virtual battle between avatars based on their attack and defense capabilities or characteristics. Thus, for example, a battle can be calculated according to a comparison of the attack characteristics of the avatar to be challenged with the defense characteristics of the avatar to be challenged. In order to add a chance factor to the battle calculation, for example, a modifier determined randomly within the range of 1-20% or 1-15% can be applied to the value of each characteristic. Instead, the avatar can have privilege capabilities or benefits that are given based on usage information used to modify the profile as described above. By way of example, if the use of a goal is achieved, the privilege ability to double the avatar's random elements or halve the hostile avatar's random elements can be used.

  When the competition result is determined, the competition result is stored by the application 69 in step S14-21. The competition results are also reported to the cloud service in step S14-23, and the report is received by the cloud service for association with the respective avatar profile in step S14-25.

  Thus, each application 69, 70 can interact with the cloud service to initiate a competition challenge and receive the result of the competition challenge, whether it was initiated by or against the avatar. , Related to the owner or user of the smartphone on which the application is running.

  Accordingly, the outcome of the competition is calculated by the user application of the challenge based on the avatar profile for the challenged avatar provided by the cloud service in response to a request based on the challenged avatar token. The outcome of the competition depends on the ability and / or characteristics of the avatar combined with one or more random or partially random elements.

  The result of the competition between the two avatars can be viewed by the user associated with each avatar by accessing the result data stored in the cloud service.

  In addition to improving the avatar profile and / or benefits (and penalties) resulting from the use of the END device, the avatar profile may change over time as a result of competition between the avatars. Winning results may be rewarded with points, which are avatars that update the avatar's ability to compete and / or the appearance of the avatar when displayed on the smartphone screen by related applications. Can be exchanged with other customizations.

  The avatar's win / loss record can also result in an authorization token or badge earned by the avatar. For example, approval may be given for consecutive wins or other win patterns. Such an approval badge may be displayed as part of the avatar's public profile via a cloud service and / or may be made visible to any potential challenger .

  As can be seen from the above discussion, the interaction occurs in real time so that the competition is settled as soon as the END token is exchanged by the END device, while at a later point in time convenient for the user and / or It is also possible to settle the challenge on a fixed time scale, for example, all exchanged tokens from a particular day will be challenged once a day (or at other suitable time intervals) Processed in a batch process and / or managed to settle the challenge using time based on order.

  The various embodiments described herein are presented only to assist in understanding and teaching the claimed features. These embodiments are provided merely as representative examples of embodiments and are not exhaustive and / or exclusive. The advantages, embodiments, examples, functions, features, structures, and / or other aspects described herein are limited to the disclosure scope defined by the claims, or are equivalent to the claims. It should be understood that other embodiments can be used and changes can be made without departing from the scope and / or spirit of the claims.

Additional examples consistent with the present teachings are described in the numbered clauses below.
[Clause 1] The process of passing a data token from the first wirelessly connectable electronic nicotine transmission (END) device to the second wirelessly connectable END device and the operation of the third wirelessly connectable device are controlled. Using the token to establish a communication relationship between the third wirelessly connectable device and the second wirelessly connectable END device.
[Clause 2] The step of using a token to control the mode of operation of the third wirelessly connectable device uses this token as an input to an application running on the third wirelessly connectable device. The method of clause 1, comprising the step of:
[Claim 3] The method according to Clause 1 or 2, wherein the first and second wirelessly connectable END devices exchange tokens using a communication protocol based on a Bluetooth (registered trademark) operation standard.
[Clause 4] The first wirelessly connectable END device adopts the advertising mode, and the token is second wirelessly connectable by the first wirelessly connectable END device including the token in the advertising data. 4. A method according to any one of clauses 1 to 3, wherein the second wirelessly connectable END device is in a standby mode capable of receiving advertising data while being passed to the device.
[Clause 5] The method according to any one of Clauses 1 to 4, wherein the first and second wirelessly connectable END devices include an aerosol delivery device.
[Item 6] The method of any one of Items 1-5, further comprising establishing a benefit that the third wirelessly connectable device will receive by the user as a result of receiving the token.
[Clause 7] Establishing the benefit includes sending a message to the remote service and receiving a response from the remote service in response to receiving the token, the response being used to determine the benefit. The method of clause 6, providing information.
[Clause 8] The method of clause 7, wherein the information for determining the benefit includes a description of the benefit.
[Clause 9] The information for determining the benefit includes further data for controlling the operation aspect of the third wirelessly connectable device, and the controlled operation aspect includes the benefit calculation process. The method described in 1.
[Claim 10] The method according to any one of Clauses 6 to 9, wherein the benefit is a change to non-currency consideration in the user account.
[Item 11] The method according to any one of Items 1 to 10, wherein the operation aspect of the third wirelessly connectable device includes user-to-user interaction of data related to the user account.
[Clause 12] The method of clause 11, wherein the user interaction is a competitive interaction, and the result of the interaction depends in part on the token.
[Clause 13] The method of clause 12, wherein benefits affect input to competitive interactions.
[Clause 14] A method of operating a nicotine aerosol supply device, wherein the wireless communication interface of another aerosol supply device is operated between the step of operating the wireless communication interface of the device in a standby mode and the operation in the standby mode. Receiving the data token; storing the received data token in the aerosol supply device; providing the stored data token to the application operating device to control an aspect of the operation of the application operating device; , Including methods.
[Claim 15] The method further includes: operating the device interface in advertising mode; and transmitting a data token from the interface during the advertising mode operation, the data token associated with another aerosol delivery device. 15. The method of clause 14, operable to control aspects of operation of the application operating device.
[Clause 16] A nicotine aerosol delivery device that operates in a standby mode to receive a data token from a wireless communication interface of another aerosol supply device and operates to store the received data token The wireless communication interface is configured to transmit the received data token to the application operating device operatively associated with the aerosol delivery device to control aspects of the operation of the application operating device. A nicotine aerosol delivery device operable further.
[Clause 17] From a wirelessly connected electronic nicotine delivery (END) device, a token stored in the connected END device is obtained as a result of device-to-device interaction between the connected device and another END device. Requesting, receiving the requested token from a wirelessly connected END device, providing the token to a remote service, receiving a profile from the remote service, and the received profile and wireless connection Performing a comparison or interaction with a profile associated with the rendered END device.
[Clause 18] After receiving the requested token from the wirelessly connected END device, providing a user notification associated with the received token and user input regarding whether to perform the comparison or interaction 18. The method of clause 17, further comprising: requesting.
Clause 19 The method of clause 17 or 18, further comprising providing a request for user input to define a profile associated with the wirelessly connected END device.
[Clause 20] The method according to any one of clauses 17 to 19, wherein the wirelessly connected END device is wirelessly connected via a personal area network protocol.
[Clause 21] The token is stored in the connected END device as a result of the device-to-device interaction between the wirelessly connected END device and another END device, and this master / slave. In the protocol, each of the wirelessly connected END device and another END device wireless is configured to operate as a master device and a slave device at different times in separate communication interactions using the same communication protocol. 21. The method of any one of clauses 17-20, wherein each of the wirelessly connected END device and another END device is configured to switch between a master device mode and a slave device mode.
[Claim 22] The method of any one of clauses 17 to 21, wherein performing the comparison or interaction further comprises applying one or more change factors to one of the profiles.
[Claim 23] The method of any one of clauses 17-22, wherein the step of performing the comparison or interaction comprises performing a competitive analysis between the profiles to determine a success result.
[Claim 24] The method of any one of clauses 17 to 23, further comprising providing a result of the comparison or interaction to the remote service.
[Clause 25] Inquiring about the usage information from the wirelessly connected END device, receiving the usage information from the wirelessly connected END device, and relating to the wirelessly connected END device according to the received usage information 25. The method of any one of clauses 17 to 24, further comprising: modifying the profile obtained.
[Claim 26] The clause 25, further comprising: comparing the received usage information with a usage target; and modifying a virtual avatar profile associated with the wirelessly connected END device according to the comparison result. the method of.

  Various embodiments of the claimed claims suitably include appropriate combinations of the disclosed elements, components, features, parts, steps, means, etc., other than those specifically described herein. Consist of or consist essentially of. Further, the present disclosure may include other concepts that are not currently claimed, which may be claimed in the future in combination with or separately from the currently claimed features.

US 2013/284192 U.S. Patent No. 2014/174459 US Patent No. 2011/265806

Claims (24)

  Including a wireless communication interface configured to operate in different communication relationships as a master device and as a slave device at different times using the same communication protocol, the interface being switched between master device mode and slave device mode. A wireless communication module configured to be replaced.   The wireless communication module of claim 1, wherein the wireless communication interface is configured to operate a personal area network protocol. The wireless communication interface is
Waiting in the master device mode for advertising data transmitted from another wireless communication module operating in the slave device mode during the standby period;
Transmitting advertising data in the slave device mode during the advertising period to transfer to another wireless communication module operating in the master device mode during the advertising period;
The wireless communication module according to claim 1, wherein the wireless communication module is configured to employ a communication schedule including   The interface is configured to switch between the master device mode and the slave device mode at a variable switching speed so that it follows at least one of the master device mode and the slave device mode The wireless communication module according to any one of claims 1 to 3, wherein an interval between the standby periods changes.   The wireless communication module according to any one of claims 1 to 4, wherein the wireless communication interface is configured to operate in a radio frequency band of 2.4 to 2.485 GHz.   The wireless communication module according to claim 1, wherein the wireless communication interface is a Bluetooth (registered trademark) communication interface.   The wireless communication module according to claim 1, wherein the wireless communication interface is a Bluetooth (registered trademark) low energy communication interface.   The Bluetooth (registered trademark) low energy communication interface is configured to operate as a central device when operating as a master device and to operate as a peripheral device when operating as a slave device. Wireless communication module.   9. The wireless communication interface is configured to alternately arrange a period for advertising as a potential master device and a period for observing as a potential slave device. The wireless communication module according to 1. A first wireless communication module according to any one of claims 1 to 9;
A wireless communication network including the second wireless communication module according to any one of claims 1 to 9,
The first module operating in the slave device mode transmits advertising data representing data tokens to be transmitted across the network, and the second module operating in the master device mode includes the first module Receiving the advertising data sent by the module, thereby receiving the data token;
The second module operating in the slave device mode transmits advertising data representing a data token to be transmitted across the network, and the first module operating in the master device mode includes the second module A wireless communication network that receives the advertising data sent by a module and thereby receives the data token. Further comprising a third wireless communication module according to any one of claims 1 to 9,
The third module operating in the slave mode transmits advertising data indicating a data token to be transmitted across the network, and the first and second modules operating in the master device mode are Receiving the advertising data sent by the third module, thereby receiving the data token;
The third module operating in the master device mode receives a data token to be transmitted across the network, transmitted by the first module and / or the second module operating in the master device mode. The wireless communication network of claim 10, receiving advertising data representing, thereby receiving the data token.   The wireless communication network according to claim 10 or 11, wherein the first module and the second module establish a coupling relationship for transmitting data other than the data token between them.   The first module additionally participates in a coupling relationship with a further wireless communication module using the communication protocol, the further module being configured as a master device of the coupling relationship, the first module The wireless communication network according to claim 10, wherein the wireless communication network is configured as a slave device having the connection relation. A method for transmitting data over a mesh network,
Adopting, in the first node of the mesh network, an advertising state in which a data token is included in the advertising data of the first node transmitted by the first node;
In the second node within the wireless communication range of the first node, the advertising data of the first node is the second node simultaneously with at least a part of the duration of the advertising state in the first node. Adopting a standby state received by a node of
After receiving the advertising data of the first node at the second node, the data token received in the advertising data of the first node is transmitted by the second node. Adopting an advertising state included in the advertising data of the node.   In the third node within the wireless communication range of the second node, the advertising data of the second node is simultaneously transmitted to the third node at the same time as at least part of the duration of the advertising state in the second node. 15. The method of claim 14, further comprising adopting a standby state received by a plurality of nodes.   The method of claim 15, wherein the first and third nodes are different nodes.   The method according to any one of claims 14 to 16, wherein the second node switches between the advertising state and the standby state.   The method of claim 17, wherein the duration of at least one of the advertising state and the standby state changes between subsequent adoptions of the state.   The standby state corresponds to Bluetooth (registered trademark) master mode or Bluetooth (registered trademark) low energy central mode, and the advertising state corresponds to Bluetooth (registered trademark) slave mode or Bluetooth (registered trademark) low energy peripheral mode. 19. A method according to any one of claims 14 to 18, characterized by:   The method according to any one of claims 14 to 19, wherein the standby state has a duration of 0.01 ms to 5 s.   21. A method according to any one of claims 14 to 20, further comprising establishing a coupling relationship between the first node and the second node.   The method according to any one of claims 14 to 21, wherein at least one node comprises the wireless communication module according to any one of claims 1 to 9.   A networking method substantially as described above with reference to any of the accompanying drawings.   An apparatus for a mesh network substantially as described above with reference to any of the accompanying drawings.

Images