TWI552554B - Methods, apparatus and computer-readable storage media for discovering, configuring, and leveraging relationships in internet of things (lot) networks - Google Patents

Description

Method, apparatus and computer readable storage medium for detecting, configuring and balancing relationships in an Internet of Things (IoT) network Cross-reference to related applications

This patent application claims the provisional application No. 61/769,130, filed on February 25, 2013, entitled "AN IMPLICIT METHOD FOR CREATING RELATIONSHIPS BETWEEN INTERNET OF THINGS (IOT) DEVICE", filed on February 25, 2013 Provisional Patent Application No. 61/769,145, entitled "AUTOMATIC AND CONFIGURABLE INTERNET OF THINGS NETWORK SUB-DIVISION", titled "METHOD TO DISCOVER ASYMMETRIC RELATIONSHIPS AMONG INTERNET OF THINGS (IOT) DEVICES" The provisional application No. 61/910, 203, entitled "AN IMPLICIT METHOD FOR CREATING RELATIONSHIPS BETWEEN INTERNET OF THINGS (IOT) DEVICES", is filed in the Provisional Patent Application No. 61/901,844, filed on Nov. 29, 2013. Each of these applications is hereby incorporated by reference in its entirety in its entirety in its entirety herein in its entirety in its entirety in its entirety.

The various embodiments described herein are generally related to detecting, configuring, and balancing relationships in an Internet of Things (IoT) network.

The Internet is a global system of interconnected computers and computer networks that communicate with each other using standard Internet Protocol suites (eg, Transmission Control Protocol (TCP) and Internet Protocol (IP)). The Internet of Things (IoT) is based on everyday objects (not just computers and computer networks) that are readable, identifiable, and configurable via an IoT communication network (eg, a special system or the Internet). Addressable and controllable concepts.

Numerous market trends are driving the development of IoT devices. For example, increased energy costs are driving the government to strategically invest in smart grids and support future consumption, such as for electric vehicles and utility charging stations. Increased health care costs and population aging are driving the development of remote/connected health care and fitness services. Technological innovations at home are driving the development of new "smart" services, including unified marketing of "N" activities (eg, data, voice, video, security, energy management, etc.) and extended home networks by service providers. Buildings become smarter and more convenient as a component of reducing the operating costs of an enterprise facility.

There are several important applications for IoT. For example, in the smart grid and energy management arena, utility companies can optimize energy delivery to homes and businesses, while customers can better manage energy usage. In the field of home and building automation, smart homes and buildings can centrally control virtually any device or system in the home or office, from home appliances to plug-in electric vehicle (PEV) safety systems. In the area of asset tracking, companies, hospitals, factories, and other large organizations can accurately track the location of high-value devices, patients, vehicles, and more. In the health and wellness arena, doctors can monitor the health of patients at the same time, while people can track the progress of the fitness program.

A simplified summary of one or more aspects and/or embodiments disclosed herein is presented below. Therefore, the following summary should not be considered as a broad overview of all contemplated aspects and/or embodiments, nor should the following review be regarded as identifying important or critical elements of all the desired aspects and/or embodiments, or The categories associated with any particular aspect and/or embodiment are depicted. Therefore, the following review has a detailed description of the present description presented below. The sole purpose of the disclosure of one or more aspects and /

In accordance with an illustrative aspect, the present invention is directed to a mechanism that can be used to automatically create configurable sub-divisions in an Internet of Things (IoT) network that includes various devices and/or other physical objects. For example, in various embodiments, devices and/or other physical objects in an IoT network may include, inter alia, one or more IoT devices having communication capabilities, non-IoT devices with communication capabilities, and/or no communication. Other physical objects of competence. In one embodiment, in response to detecting the device and/or other physical objects and registering the devices and/or other physical objects into the IoT network, the supervisor device can be configured to monitor the associated interactions therewith. And use, and create one or more groups associated with the IoT network. For example, one or more groups may generally define one or more sub-networks within an IoT network that organize registered devices and/or other physical objects into certain sub-networks. In one embodiment, one or more groups associated with the IoT network can then be presented via a user interface (eg, on a supervisor device), the user interface can allow the user to provide one or more commands to Control or otherwise configure the IoT network. For example, in one embodiment, one or more commands may be used to customize the group associated with the IoT network and control certain groups, subsets, or other subnets associated with the IoT network. Access to the road.

According to another exemplary aspect, the present invention is directed to a mechanism that can be used to implicitly create relationships between IoT devices. In one aspect, the first IoT device belonging to the first user can detect the current interaction with the second IoT device belonging to the second user, and then determine whether to update and the second based on the attributes associated with the current interaction. The relationship associated with the IoT device is in place. Additionally, in response to determining that one or more previous interactions have occurred between the first IoT device and the second IoT device, the first IoT device can be associated with previous interactions between the IoT devices based on attributes associated with the current interaction. One or more attributes further determine whether to update the relationship order associated with the second IoT device. In addition, in response to the first IoT device decision should The relationship order associated with the second IoT device is updated, and then the first IoT device can update the relationship order accordingly (eg, escalating the relationship from a friend to a family member, downgrading the relationship from a friend to an acquaintance, etc.). In one embodiment, the first IoT device can further determine whether the second IoT device requests access to an IoT device belonging to the first user (eg, the first IoT device or some other IoT device belonging to the first user), Wherein if the second IoT device requests access, the first IoT device can determine whether to grant or reject the requested access based on the relationship assigned to the second IoT device.

According to another exemplary aspect, the present invention is directed to a mechanism that can be used to implicitly assign a relationship between users in an IoT network, wherein the first IoT device belonging to the first user can be detected and belong to the second use Interaction between the second IoT devices (eg, when the first IoT device and the second IoT device are positioned close to each other). Thus, in one embodiment, the first IoT device can then store information about the interactions in the local interaction table and based, at least in part, on the IoT device associated with the interaction and/or with the first user (eg, The first IoT device and/or other IoT device belonging to the first user) is associated with one or more IoT devices of the second user (eg, the second IoT device and/or other IoT belonging to the second user) The stored information of one or more previous interactions between the devices) assigns the relationship identifier to the second user associated with the second IoT device. Moreover, in one embodiment, the server can detect an interaction between the first IoT device and the second IoT device based on the location information about the interaction, and the server can receive the first IoT device and/or the second IoT device. Location information, wherein the interactions used to assign relationship identifiers may include interactions occurring during a threshold period of time, substantially simultaneously and/or at substantially the same location; having a duration of duration, threshold frequency, and/or substance Interactions of the same type; or interactions that meet other appropriate criteria.

In accordance with another illustrative aspect, the present invention is directed to mechanisms that can be used to track locations and interactions associated with various IoT devices in order to detect user-specific and potentially asymmetric relationships between IoT devices. In particular, relationships are often complex, and coincidences (eg, in certain locations, at certain times, etc.) may not always indicate actual closures between different users. system. For example, two people can interact with each other frequently but still not friends. In addition, some relationships may be asymmetric, with some of the relationships between users being classified differently from each other. Thus, the location, interaction, usage, and other relevant state data associated with various IoT devices can be tracked to derive asymmetric relationships between different users that can be used to control subsequent interactions between IoT devices. Moreover, in one embodiment, tracking users who have a location where a particular interaction occurs can be used to derive additional information about relationships between different users. For example, in one embodiment, various registered IoT devices can send information about the location and interaction associated with them to the server, and the server can track the location associated with the IoT device and the interaction between the IoT devices. And continuously process the tracked locations and interactive data received from each IoT device at certain time intervals to identify similar and/or different usage patterns, location coincidences, or to provide knowledge and/or other insights to various Other related relationships between users are similar and/or different. The location and interaction data received during the current tracking period can be pre-processed to identify similar patterns or positional overlaps between various IoT devices (eg, daily or according to another periodic time interval), the location tracked during any particular time period and The interactive data thereby progressively relies on the location and interactive data tracked in one or more previous tracking cycles. In addition, in order to avoid acting as outdated material and placing newer locations and newer interactions of greater importance, location and interaction data from previous tracking periods may be limited to certain time periods (eg, within the last month). Location and interactive information. The server can then use the pre-processed location and interactive data from the current tracking period (and/or any previously processed location and interaction data from previous tracking cycles) to cluster the location and interactive data into a primary group based on appropriate statistical techniques. The clustered relationship data can then be analyzed to derive a user-specific cluster representation that can be used to assign a user-specific relationship identifier between the tracked IoT device (and the user associated with it). For example, in one embodiment, the location associated with each input can be plotted on the derived x-axis and y-axis, and the user-specific cluster representation can be plotted using a suitable drawing tool for viewing and analysis. This suitable drawing tool to help learn and classify the IoT devices being tracked and The relationship between associated users, including any asymmetry between them.

Other objects and advantages associated with the aspects and embodiments disclosed herein will be apparent to those skilled in the <RTIgt;

100A‧‧‧Wireless communication system

100B‧‧‧Wireless communication system

100C‧‧‧Wireless communication system

100D‧‧‧Wireless Communication System

100E‧‧‧Wireless communication system

105‧‧‧ Passive Internet of Things (IoT) devices

108‧‧‧Intermediate mediation

109‧‧‧Direct wired connection

110‧‧‧TV/Internet of Things (IoT) devices

112‧‧‧Outdoor Air Conditioning Unit/Internet of Things (IoT) device

114‧‧‧ Thermostat/Internet of Things (IoT) devices

116‧‧‧Fast/Internet of Things (IoT) devices

116A‧‧‧Internet of Things (IoT) devices

116B‧‧‧Internet of Things (IoT) devices

118‧‧‧Washing Machines and Dryers/Internet of Things (IoT) Devices

120‧‧‧Computer/Internet of Things (IoT) devices

122A‧‧‧Internet of Things (IoT) devices

122B‧‧‧Internet of Things (IoT) devices

124A‧‧‧Internet of Things (IoT) devices

124B‧‧‧Internet of Things (IoT) devices

125‧‧‧ access point

130‧‧‧Supervisor device

140‧‧‧Internet of Things (IoT) Super Agent

140A‧‧‧Internet of Things (IoT) Super Agent

140B‧‧‧Internet of Things (IoT) Super Agent

145‧‧‧Mental device functionality

152‧‧‧Application layer

154‧‧Common Messaging Protocol (CMP) layer

156‧‧‧Transport layer

158‧‧‧ physical layer

160‧‧‧Internet of Things (IoT) device group

160A‧‧‧Internet of Things (IoT) device group

160B‧‧‧Internet of Things (IoT) device group

170‧‧‧Internet of Things (IoT) server

175‧‧‧Internet

180‧‧‧ Resources

200A‧‧‧Internet of Things (IoT) devices

200B‧‧‧ Passive Internet of Things (IoT) devices

202‧‧‧ platform

206‧‧‧Transceiver

208‧‧‧ processor

212‧‧‧ memory

214‧‧‧Input/Output (I/O) interface

222‧‧‧Power button

224A‧‧‧ control button

224B‧‧‧ control button

226‧‧‧ display

300‧‧‧Communication devices

305‧‧‧ Logic configured to receive and/or transmit information

310‧‧‧ Logic configured to process information

315‧‧‧ Logic configured to store information

320‧‧‧ Logic configured to present information

325‧‧‧ Logic configured to receive local user input

400‧‧‧Server

401‧‧‧ processor

402‧‧‧ volatile memory

403‧‧‧Disk machine

404‧‧‧Network access

406‧‧‧DVD player

407‧‧‧Network

500‧‧‧Wireless communication network or WAN

510a‧‧‧Base Station

510b‧‧‧Base Station

510c‧‧‧Base Station

520‧‧‧Devices

520a‧‧‧Device

520b‧‧‧Device

520c‧‧‧ devices

520d‧‧‧ devices

520e‧‧‧Device

520f‧‧‧ devices

520g‧‧‧ devices

520h‧‧‧ devices

520i‧‧‧ devices

530‧‧‧Network Controller

540‧‧‧Dynamic Host Configuration Protocol (DHCP) server

610‧‧‧ first device

612‧‧‧Distributed bus node

614‧‧‧Local Endpoint

625‧‧‧Distributed busbar

630‧‧‧second device

632‧‧‧Distributed bus node

634‧‧‧Local Endpoint

640‧‧‧ third device

642‧‧‧Distributed bus node

644‧‧‧Local Endpoint

710‧‧‧First device ("Device A")

712‧‧‧ Bus node

714‧‧‧Local Endpoint

730‧‧‧Second device ("Device B")

732‧‧‧ bus node

734‧‧‧Local Endpoint

754‧‧‧Message sequence steps

756‧‧‧Message sequence steps

758‧‧‧Message sequence steps

760‧‧‧Message sequence steps

762‧‧‧Message sequence steps

764‧‧‧Message sequence steps

766‧‧‧Message sequence steps

800‧‧‧ method

900‧‧‧ method

1000‧‧‧Curve

1100A‧‧‧ method

1100B‧‧‧ method

1200‧‧‧ architecture

1210‧‧‧P2P platform

1215‧‧‧Security Module

1215A‧‧‧Security settings

1215b‧‧‧Security settings

1215c‧‧‧Security settings

1220‧‧‧Trust model

1224‧‧‧ relationship graph

1228‧‧‧Adaptive Behavior Module

1230‧‧‧Function access application

1235‧‧‧Device Driver

1310‧‧‧ commissioned controller device

1312‧‧‧Regional bus node

1314‧‧‧Application

1320‧‧‧Trust model

1322‧‧‧GetFamily( ) method

1324‧‧‧GetProfiles( ) method

1330‧‧‧Access controller device

1332‧‧‧Regional bus node

1334‧‧‧Application

1340‧‧‧Controlled device

1342‧‧‧Regional bus node

1344‧‧‧Application

1350‧‧‧Safety Bridge

1360‧‧‧identified entities

The detailed description with reference to the accompanying drawings, which are to be considered as And wherein: Figures 1A-1E illustrate an exemplary high level system architecture for a wireless communication system in accordance with various aspects of the present invention.

2A illustrates an exemplary Internet of Things (IoT) device in accordance with various aspects of the present invention, and FIG. 2B illustrates an exemplary passive IoT device in accordance with various aspects of the present invention.

3 illustrates an exemplary communication device in accordance with various aspects of the present invention, the communication device including logic configured to perform functionality.

4 illustrates an exemplary server in accordance with various aspects of the present invention.

Figure 5 illustrates a wireless communication network that supports detectable inter-stage (P2P) services in accordance with an aspect of the present invention.

6 illustrates an exemplary environment in accordance with an aspect of the present invention in which a detectable P2P service can be used to establish a close-range, decentralized bus, via which various devices can communicate via a close-range, decentralized bus.

7 illustrates an exemplary sequence of messages in accordance with an aspect of the present invention in which a detectable P2P service can be used to establish a close-range, decentralized bus, via which various devices can communicate via a close-range, decentralized bus.

8 illustrates an exemplary method for automatic and configurable sub-segmentation in an IoT network including various IoT devices in accordance with various aspects of the present invention.

Figure 9 illustrates an exemplary method of implicitly creating relationships between IoT devices in accordance with an aspect of the present invention.

Figure 10 illustrates a graph of an exemplary sinusoidal function that can be used in the context of creating relationships between IoT devices in accordance with various aspects of the present invention.

Figure 11A illustrates an exemplary method of implicitly creating relationships between IoT devices in accordance with various aspects of the present invention.

11B illustrates an exemplary method of tracking locations and interactions associated with various IoT devices to detect potential asymmetric user-specific relationships in accordance with various aspects of the present invention.

Figure 12A illustrates an exemplary architecture that can be used to detect, configure, and balance relationships in an IoT network, while Figure 12B illustrates an exemplary interaction between components of the architecture shown in Figure 12A in accordance with various aspects of the present invention.

13A-13C illustrate illustrative interactions of relationships in a tunable IoT network in accordance with various aspects of the present invention.

Various aspects are disclosed in the following description and related drawings. Alternative aspects can be devised without departing from the scope of the invention. In other instances, well-known elements of the present invention are not described in detail or are omitted so as not to obscure the details of the invention.

The word "exemplary" and/or "instance" is used herein to mean "serving as an instance, instance or description." It is not necessary to interpret any aspect described herein as "exemplary" and/or "example" as being preferred or advantageous over other aspects. Similarly, the term "the aspect of the invention" does not require that all aspects of the invention include the features, advantages or modes of operation discussed.

Moreover, many aspects are described in terms of sequences of actions to be performed by, for example, the elements of the computing device. It will be appreciated that the various actions described herein can be performed by a particular circuit (e.g., an application specific integrated circuit (ASIC)), by program instructions executed by one or more processors, or by a combination of the two. carried out. In addition, it is contemplated that such sequences of actions described herein are fully embodied in any form of computer readable storage medium stored in a computer readable storage medium that, when executed, will cause an associated processor to perform the process. Described A corresponding set of functional computer instructions. The various aspects of the invention may be embodied in a variety of different forms, all of which are contemplated within the scope of the claimed subject matter. In addition, for each of the aspects described herein, a corresponding form of any such aspect may be described herein as, for example, "logic configured to perform the described acts."

As used herein, the term "Internet of Things (IoT) device" is used to refer to having an addressable interface (eg, Internet Protocol (IP) address, Bluetooth identifier (ID), Near Field Communication (NFC). ID, etc.) and can transmit information to any of one or more other devices (eg, appliances, sensors, etc.) via a wired or wireless connection. An IoT device can have a passive communication interface (such as a fast response (QR) code, a radio frequency identification (RFID) tag, an NFC tag, or the like), or an active communication interface (such as a data machine, transceiver, transmitter-receiver, or It's similar). The IoT device can be embedded in a central processing unit (CPU), microprocessor, ASIC or the like and/or controlled/monitored by a CPU, microprocessor, ASIC or the like and configured for connection to A set of specific attributes of the IoT network (such as the local end network or the Internet) (for example, device status or status (such as whether the IoT device is on or off, on or off, idle or active, available for Task execution is still busy, etc.), cooling or heating function, environmental monitoring or recording function, lighting function, sounding function, etc.). For example, IoT devices can include, but are not limited to, refrigerators, ovens, ovens, microwave ovens, freezers, dishwashers, dishes, hand tools, washing machines, clothes dryers, stoves, air conditioners, thermostats, TVs, electric lamps, vacuum cleaners, sprinklers, fuel gauges, gas meters, etc., as long as the device is equipped with an addressable communication interface for communicating with the IoT network. IoT devices can also include cellular phones, desktop computers, laptops, tablets, personal digital assistants (PDAs), and the like. Therefore, in addition to devices that typically do not have Internet connectivity (eg, dishwashers, etc.), IoT networks can also include "legacy" Internet accessible devices (eg, laptop or desk) A combination of a computer, a cellular phone, etc.).

1A illustrates a high-order system shelf of a wireless communication system 100A in accordance with aspects of the present invention. Structure. The wireless communication system 100A includes a plurality of IoT devices including a television 110, an outdoor air conditioning unit 112, a thermostat 114, a refrigerator 116, and a washer and dryer 118.

Referring to FIG. 1A, IoT devices 110-118 are configured to communicate with an access network (e.g., access point 125) via a physical communication interface or layer (shown as empty interfacing 108 and direct wired connection 109 in FIG. 1A). The empty intermediation plane 108 can comply with Wireless Internet Protocol (IP), such as IEEE 802.11. Although FIG. 1A illustrates IoT devices 110-118 communicating via null interfacing 108 and IoT devices 118 communicating via direct wired connection 109, each IoT device can communicate via a wired or wireless connection or both.

Internet 175 includes several routing agents and processing agents (not shown in Figure 1A for simplicity). Internet 175 is a global system of interconnected computers and computer networks that communicate over discrete devices/networks using standard Internet Protocol suites (eg, Transmission Control Protocol (TCP) and IP). TCP/IP provides end-to-end connectivity that specifies how data should be formatted, addressed, transmitted, routed, and received at the destination.

In FIG. 1A, a computer 120, such as a desktop or personal computer (PC), is shown as being directly connected to the Internet 175 (eg, via an Ethernet connection or a Wi-Fi or 802.11 based network). . The computer 120 can have a wired connection to the Internet 175 (such as a direct connection to a modem or router), which in the example can correspond to the access point 125 itself (eg, for both wired and wireless connectivity) Wi-Fi router). Alternatively, computer 120 may be connected to access point 125 via empty interfacing surface 108 or another wireless interface and accessing Internet 175 via empty interfacing surface 108, rather than connecting to access point 125 and Internet 175 via a wired connection. Although illustrated as a desktop computer, the computer 120 can be a laptop, tablet, PDA, smart phone, or the like. Computer 120 may be an IoT device and/or contain functionality to manage IoT networks/groups, such as networks/groups of IoT devices 110-118.

Access point 125 can be connected to Internet 175 via, for example, an optical communication system such as FiOS, a cable modem, a Digital Subscriber Line (DSL) modem, or the like. access Point 125 can communicate with IoT devices 110-120 and Internet 175 using standard Internet protocols (eg, TCP/IP).

Referring to FIG. 1A, IoT server 170 is shown coupled to Internet 175. The IoT server 170 can be implemented as a plurality of structurally separated servers or can correspond to a single server. In one aspect, IoT server 170 is optional (as indicated by dotted lines) and the group of IoT devices 110-120 can be a peer-to-peer (P2P) network. In this case, IoT devices 110-120 can communicate directly with each other via empty interposer 108 and/or direct wired connection 109. Alternatively or additionally, some or all of IoT devices 110-120 may be configured with a communication interface that is independent of empty interposer 108 and direct wired connection 109. For example, if the empty interposer 108 corresponds to a Wi-Fi interface, one or more of the IoT devices 110-120 may have Bluetooth or NFC for direct communication with each other or with other Bluetooth or NFC capable devices. interface.

In a peer-to-peer network, the service detection scheme can multicast the presence of nodes, their capabilities, and group membership. Inter-level devices can be associated and subsequently interacted based on this information.

In accordance with aspects of the present invention, FIG. 1B illustrates a high level architecture of another wireless communication system 100B that includes a plurality of IoT devices. In general, the wireless communication system 100B shown in FIG. 1B can include various components (eg, various IoT devices, that are identical and/or substantially similar to the wireless communication system 100A shown in FIG. 1A described in greater detail above. A television 110, an outdoor air conditioning unit 112, a thermostat 114, a refrigerator 116, and a washer and dryer 118 configured to communicate with the access point 125 via an empty interfacing surface 108 and/or a direct wired connection 109 are included; directly connected to the Internet Path 175 and/or computer 120 connected to Internet 175 via access point 125; and IoT server 170 accessible via Internet 175, etc.). Thus, for the sake of brevity and easiness of description, some of the wireless communication systems 100B shown in FIG. 1B have been provided with respect to the same or similar details as previously described with respect to the wireless communication system 100A illustrated in FIG. 1A. Various details of the components can be omitted.

Referring to FIG. 1B, the wireless communication system 100B can include a supervisor device 130, the supervisor The device may alternatively be referred to as IoT manager 130 or IoT manager device 130. Thus, where the term "supervisor device" 130 is used in the following description, those skilled in the art will appreciate that any reference to an IoT manager, group owner or similar term may refer to the supervisor device 130 or provide the same or Another entity or logical component that is substantially similar in functionality.

In one embodiment, supervisor device 130 can generally observe, monitor, control, or otherwise manage various other components in wireless communication system 100B. For example, supervisor device 130 can communicate with an access network (e.g., access point 125) via null interfacing surface 108 and/or direct wired connection 109 to monitor or manage various IoT devices 110 in wireless communication system 100B. To 120 associated attributes, activities, or other status. The supervisor device 130 can have a wired or wireless connection to the Internet 175 and optionally to the IoT server 170 (shown as a dotted line). Supervisor device 130 may obtain information from Internet 175 and/or IoT server 170 that may be used to further monitor or manage the attributes, activities, and other status associated with various IoT devices 110-120. The supervisor device 130 can be a standalone device or one of the IoT devices 110-120, such as the computer 120. The supervisor device 130 can be a physical device or a software application executing on a physical device. The supervisor device 130 can include a user interface that can output information about the monitored attributes, activities, or other status associated with the IoT devices 110-120 and receive input information to control or otherwise manage The associated attribute, activity, or other status. Thus, supervisor device 130 can generally include various components and support various wired and wireless communication interfaces to observe, monitor, control, or otherwise manage various components in wireless communication system 100B.

The wireless communication system 100B shown in FIG. 1B can include one or more passive IoT devices 105 (in contrast to active IoT devices 110-120) that can be coupled or otherwise formed It is part of the wireless communication system 100B. In general, the passive IoT device 105 can include a bar code device, a Bluetooth device, a radio frequency (RF) device, an RFID tag device, an infrared (IR) device, an NFC tag device, or can be identifiable when queried via a small range interface. Attributes are provided to any other suitable device of another device Pieces. Active IoT devices detect, store, communicate, and act on (and/or similar to) changes in the properties of passive IoT devices.

For example, passive IoT device 105 can include a coffee cup and orange juice container each having an RFID tag or barcode. The cabinet IoT device and the refrigerator IoT device 116 can each have a suitable scanner or reader that can read an RFID tag or barcode to detect when to add or remove a coffee cup and/or orange juice container passive IoT Device 105. In response to the cabinet IoT device detecting the removal of the coffee cup passive IoT device 105 and the refrigerator IoT device 116 detecting the removal of the orange juice container passive IoT device, the supervisor device 130 can receive the IoT device and the refrigerator IoT device 116 in the cabinet. The detected activity is related to one or more signals. The supervisor device 130 can then infer that the user is drinking orange juice from the coffee cup and/or the like to drink orange juice from the coffee cup.

Although the passive IoT device 105 has been described above as having some form of RFID tag or bar code communication interface, the passive IoT device 105 can include one or more devices or other physical objects that do not have such communication capabilities. For example, some IoT devices may have suitable scanner or reader mechanisms that can detect the shape, size, color, and/or other observable features associated with the passive IoT device 105 to identify the passive IoT device 105. In this manner, any suitable physical object can convey its identity and attributes and become part of the wireless communication system 100B and be observed, monitored, controlled, or otherwise managed by the supervisor device 130. Moreover, passive IoT device 105 can be coupled or otherwise formed as part of wireless communication system 100A in FIG. 1A and viewed, monitored, controlled, or otherwise managed in a substantially similar manner.

In accordance with another aspect of the present invention, FIG. 1C illustrates a high level architecture of another wireless communication system 100C that includes a plurality of IoT devices. In general, the wireless communication system 100C shown in FIG. 1C can include various components that are identical and/or substantially similar to the wireless communication systems 100A and 100B illustrated in FIGS. 1A and 1B, respectively, described in greater detail above. . Therefore, for the sake of brevity and easiness of description, it has been described above with respect to FIGS. 1A and 1B, respectively. The various details of certain components in the wireless communication system 100C shown in FIG. 1C may be omitted in connection with the wireless communication systems 100A and 100B providing the same or similar details.

Communication system 100C, shown in FIG. 1C, illustrates exemplary inter-level communication between IoT devices 110-118 and supervisor device 130. As shown in FIG. 1C, supervisor device 130 communicates with each of IoT devices 110-118 via an IoT supervisor interface. In addition, IoT devices 110 and 114, IoT devices 112, 114, and 116, and IoT devices 116 and 118 are in direct communication with each other.

IoT devices 110 through 118 form an IoT group 160. The IoT device group 160 is a group of IoT devices connected to the local end, such as an IoT device connected to the user's home network. Although not shown, a plurality of IoT device groups can be connected to each other and/or to each other via an IoT Super Agent 140 connected to the Internet 175. At the high level, the supervisor device 130 manages intra-group communication, while the IoT super agent 140 can manage inter-group communication. Although shown as a separate device, supervisor device 130 and IoT super-proxy 140 can be the same device or reside on the same device (eg, a stand-alone device or an IoT device, such as computer 120 in FIG. 1A). Alternatively, IoT Super Agent 140 may correspond to or include the functionality of access point 125. As yet another alternative, the IoT super-proxy 140 may correspond to or include the functionality of an IoT server, such as the IoT server 170. The IoT Super Agent 140 can encapsulate the gateway functionality 145.

Each IoT device 110-118 can treat the supervisor device 130 as a peer and transmit an attribute/structural description update to the supervisor device 130. When an IoT device needs to communicate with another IoT device, it can request an indicator to the IoT device from the supervisor device 130 and then communicate with the target IoT device in the same level. The IoT devices 110-118 communicate with one another via a peer-to-peer communication network using a Common Messaging Protocol (CMP). As long as the two IoT devices have CMP capability and are connected via a common communication transport, the two IoT devices can communicate with each other. In the protocol stack, the CMP layer 154 is below the application layer 152 and above the transport layer 156 and the physical layer 158.

In accordance with another aspect of the present invention, FIG. 1D illustrates a high level architecture of another wireless communication system 100D that includes a plurality of IoT devices. In general, the wireless communication system shown in Figure 1D The system 100D may include various components that are identical and/or substantially similar to the wireless communication systems 100A-100C illustrated in Figures 1A-1C, respectively, described in greater detail above. Therefore, for the sake of brevity and easiness of description, the wireless communication systems 100A to 100C illustrated in FIGS. 1A through 1C have been provided with the same or similar details, respectively, with respect to the wireless communication shown in FIG. 1D. Various details of certain components in system 100D may be omitted.

Internet 175 is a "resource" that can be adjusted using the concept of IoT. However, Internet 175 is only one example of a conditioned resource and the concept of IoT can be used to tune any resources. Other resources that may be adjusted include, but are not limited to, electricity, gas, storage, security, and the like. The IoT device can be connected to a resource and thereby adjust the resource, or can adjust resources via the Internet 175. FIG. 1D illustrates a number of resources 180, such as natural gas, gasoline, hot water, and electricity, wherein resources 180 are adjustable in addition to and/or via the Internet 175.

IoT devices can communicate with one another to adjust their use of resource 180. For example, IoT devices, such as ovens, computers, and hair dryers, can communicate with one another via a Bluetooth communication interface to regulate their use of electricity (resources 180). As another example, IoT devices, such as desktops, phones, and tablets, can communicate via a Wi-Fi communication interface to regulate their access to the Internet 175 (resources 180). As yet another example, IoT devices, such as stoves, dryers, and water heaters, can communicate via a Wi-Fi communication interface to regulate their use of gas. Alternatively or additionally, each IoT device can be coupled to an IoT server, such as IoT server 170, which has logic to adjust its use of resource 180 based on information received from the IoT device.

In accordance with another aspect of the present invention, FIG. 1E illustrates a high level architecture of another wireless communication system 100E that includes a plurality of IoT devices. In general, the wireless communication system 100E illustrated in FIG. 1E can include various components that are identical and/or substantially similar to the wireless communication systems 100A-100D illustrated in FIGS. 1A-1D, respectively, described in greater detail above. . Therefore, for the sake of brevity and easiness of description, it has been described above with respect to FIGS. 1A through 1D, respectively. Various details regarding certain components in the wireless communication system 100E shown in FIG. 1E may be omitted for the wireless communication systems 100A-100D providing the same or similar details.

Communication system 100E includes two IoT device groups 160A and 160B. Multiple IoT device groups can be connected to each other and/or to each other via an IoT SuperAgent connected to the Internet 175. At the high level, the IoT Super Agent manages inter-group communication between IoT device groups. For example, in FIG. 1E, IoT device group 160A includes IoT devices 116A, 122A, and 124A and IoT super-proxy 140A, while IoT device group 160B includes IoT devices 116B, 122B, and 124B and IoT super-proxy 140B. Thus, IoT super-proxies 140A and 140B can be connected to the Internet 175 and communicate with one another via the Internet 175 and/or directly with one another to facilitate communication between the IoT device groups 160A and 160B. In addition, although FIG. 1E illustrates that two IoT device groups 160A and 160B communicate with one another via IoT super-proxies 140A and 140B, those skilled in the art will appreciate that any number of IoT device groups can suitably communicate with one another using IoT super-agents. .

2A illustrates a high level example of an IoT device 200A in accordance with aspects of the present invention. While the appearance and/or internal components can vary significantly between IoT devices, most IoT devices will have some kind of user interface that can include a display and components for user input. IoT devices that do not have a user interface can communicate remotely via a wired or wireless network, such as the null mediator 108 in Figures 1A-1B.

As shown in FIG. 2A, in an example configuration for IoT device 200A, the housing of IoT device 200A can be configured with display 226, power button 222 and two control buttons 224A and 224B, among other components, in such a technique. Known. Display 226 can be a touch screen display, in which case control buttons 224A and 224B may not be necessary. Although not explicitly shown as part of the IoT device 200A, the IoT device 200A may include one or more external antennas and/or one or more integrated antennas built into the housing, including, but not limited to, Wi-Fi Antennas, cellular antennas, satellite positioning system (SPS) antennas (eg, global positioning system (GPS) antennas), and the like.

While the internal components of an IoT device such as IoT device 200A can be embedded with different hardware configurations, the basic high-level configuration for internal hardware components is shown in FIG. 2A as platform 202. The platform 202 can receive and execute software applications, materials, and/or commands that are transmitted via a network interface, such as the empty mediation surface 108 and/or the wired interface of FIGS. 1A-1B. The platform 202 can also execute the application stored locally. Platform 202 can include operatively coupled to one or more processors 208 (such as a microcontroller, a microprocessor, a special application integrated circuit, a digital signal processor (DSP), a programmable logic circuit, or typically One or more transceivers 206 (eg, other data processing devices of processor 208) (eg, Wi-Fi transceivers, Bluetooth transceivers, cellular transceivers, satellite transceivers, GPS or SPS receivers, etc.) The one or more transceivers are configured for wired and/or wireless communication. Processor 208 can execute application programming instructions within memory 212 of the IoT device. Memory 212 may include read only memory (ROM), random access memory (RAM), electrically erasable programmable ROM (EEPROM), flash card, or any memory commonly found in computer platforms. One or more. One or more input/output (I/O) interfaces 214 may be configured to allow processor 208 to communicate with and control various I/O devices, such as display 226, power button 222, as illustrated, control buttons 224A and 224B and any other devices, such as sensors, actuators, repeaters, valves, switches, and the like associated with IoT device 200A.

Thus, aspects of the invention may include an IoT device (eg, IoT device 200A) that includes the ability to perform the functions described herein. As will be appreciated by those skilled in the art, various logic components can be embodied in discrete components, software modules executed on a processor (eg, processor 208), or any combination of software and hardware to achieve the disclosure herein. Feature. For example, transceiver 206, processor 208, memory 212, and I/O interface 214 can all be used to cooperatively load, store, and execute the various functions disclosed herein, and thus the logic to perform such functions. Can be dispersed on various components. Alternatively, functionality can be incorporated into a discrete component. Therefore, the features of the IoT device 200A in Figure 2A will only be considered illustrative. The invention is not limited to the features or arrangements described.

Figure 2B illustrates a high level example of a passive IoT device 200B in accordance with aspects of the present invention. In general, the passive IoT device 200B shown in FIG. 2B can include various components that are identical and/or substantially similar to the IoT device 200A shown in FIG. 2A described in greater detail above. Thus, for the sake of brevity and ease of description, some of the components of the passive IoT device 200B shown in FIG. 2B are provided in terms of the same or similar details that have been provided above with respect to the IoT device 200A illustrated in FIG. 2A. Various details can be omitted.

The passive IoT device 200B shown in FIG. 2B differs from the IoT device 200A shown in FIG. 2A in that the passive IoT device 200B may not have a processor, internal memory, or some other component. Alternatively, in one embodiment, passive IoT device 200B may include only I/O interface 214 or other suitable means to allow observation, monitoring, control, management, or otherwise knowing passive IoT device 200B within a controlled IoT network. mechanism. For example, in one embodiment, the I/O interface 214 associated with the passive IoT device 200B can include a barcode, a Bluetooth interface, a radio frequency (RF) interface, an RFID tag, an IR interface, an NFC interface, or can be small The range interface query provides identifiers and attributes associated with the passive IoT device 200B to any other suitable I/O interface of another device (eg, an active IoT device such as the IoT device 200A that can detect, store, Communicating, acting on, or otherwise processing information about attributes associated with passive IoT device 200B).

Although the passive IoT device 200B has been described above as having some form of RF, barcode or other I/O interface 214, the passive IoT device 200B may include devices or other physical objects that do not have this I/O interface 214. For example, some IoT devices may have a suitable scanner or reader mechanism that can detect the shape, size, color, and/or other observable features associated with the passive IoT device 200B to identify the passive IoT device 200B. In this manner, any suitable physical object can convey its identity and attributes and be observed, monitored, controlled, or otherwise managed within the controlled IoT network.

FIG. 3 illustrates a communication device 300 that includes logic configured to perform functionality. Communication Device 300 may correspond to any of the communication devices noted above, including, but not limited to, IoT devices 110-120, IoT device 200A, any component coupled to Internet 175 (eg, IoT server) 170) Wait. Accordingly, communication device 300 may correspond to any electronic device configured to communicate (or facilitate communication) with one or more other entities via wireless communication systems 100A-100B of FIGS. 1A-1B.

Referring to FIG. 3, communication device 300 includes logic 305 configured to receive and/or transmit information. In an example, if communication device 300 corresponds to a wireless communication device (eg, IoT device 200A and/or passive IoT device 200B), logic 305 configured to receive and/or transmit information can include a wireless communication interface (eg, blue) Bud, Wi-Fi, Wi-Fi Direct, Long Term Evolution (LTE) Direct, etc., such as wireless transceivers and associated hardware (eg, RF antennas, modems, modulators, and/or demodulators) . In another example, logic 305 configured to receive and/or transmit information may correspond to a wired communication interface (eg, serial connection, USB or Firewire connection, Ethernet connection to accessible Internet 175, etc.) . Thus, if communication device 300 corresponds to a type of network-based server (eg, application 170), logic 305 configured to receive and/or transmit information may correspond to an Ethernet card in an example. The Ethernet card connects the network-based server to other communicating entities via the Ethernet protocol. In another example, logic 305 configured to receive and/or transmit information can include sensing or measuring hardware, and communication device 300 can monitor its native environment by the sensing or measuring hardware (eg, Accelerometer, temperature sensor, light sensor, antenna for monitoring the local RF signal, etc.). Logic 305 configured to receive and/or transmit information may also include software that, when executed, permits the associated hardware of logic 305 configured to receive and/or transmit information to perform its receiving and/or transmitting functions. However, logic 305 configured to receive and/or transmit information corresponds not only to software, but logic 305 configured to receive and/or transmit information depends at least in part on hardware to achieve its functionality.

Referring to FIG. 3, communication device 300 further includes logic 310 configured to process information. In an example, logic 310 configured to process information can include at least a processor. can Example implementations of types of processing performed by logic 310 configured to process information include, but are not limited to, performing decisions, establishing connections, making selections between different information options, performing evaluations on data, and coupling to communication devices 300 performs the sensor interaction of the measurement operation, converting the information from one format to another (eg, between different protocols, such as .wmv to .avi, etc.), and the like. For example, a processor included in logic 310 configured to process information may correspond to a general purpose processor, DSP, ASIC, field programmable gate array (FPGA) or designed to perform the functions described herein or Other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor can also be implemented as a combination of computing devices (eg, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessor cores in conjunction with a DSP core, or any other such configuration). The logic 310 configured to process information may also include software that, when executed, permits the associated hardware of the logic 310 configured to process the information to perform its processing functions. However, logic 310 configured to process information corresponds not only to software, but logic 310 configured to process information depends, at least in part, on hardware to achieve its functionality.

Referring to FIG. 3, communication device 300 further includes logic 315 configured to store information. In an example, logic 315 configured to store information may include at least non-transitory memory and associated hardware (eg, a memory controller, etc.). For example, the non-transitory memory included in the logic 315 configured to store information may correspond to RAM, flash memory, ROM, erasable programmable ROM (EPROM), EEPROM, scratchpad, A hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. Logic 315 configured to store information may also include software that, when executed, permits the associated hardware of logic 315 configured to store information to perform its storage function. However, the logic 315 configured to store information corresponds not only to the software, but the logic 315 configured to store the information depends, at least in part, on the hardware to achieve its functionality.

Referring to FIG. 3, communication device 300 further includes logic 320 configured to present information, as appropriate. In an example, logic 320 configured to present information can include at least an output device and associated hardware. For example, the output device may include a video output device (eg, a display screen, portable video information such as USB, HDMI, etc.), an audio output device (eg, a speaker, portable audio information, such as a microphone) The jacks, USB, HDMI, etc., the vibrating device and/or information may be formatted for output or any other device that is actually output by the user or operator of the communication device 300. For example, if communication device 300 corresponds to IoT device 200A as shown in FIG. 2A and/or passive IoT device 200B as shown in FIG. 2B, logic 320 configured to present information may include display 226. In another example, logic 320 configured to present information may be omitted for certain communication devices, such as network communication devices that do not have a local user (eg, a network switch or router, a remote end) Server, etc.). The logic 320 configured to present information may also include software that, when executed, permits the associated hardware of the logic 320 configured to present information to perform its rendering function. However, logic 320 configured to present information not only corresponds to software, but logic 320 configured to present information depends, at least in part, on the hardware to achieve its functionality.

Referring to FIG. 3, communication device 300 further includes logic 325 configured to receive local user input, as appropriate. In an example, logic 325 configured to receive local user input can include at least a user input device and associated hardware. For example, the user input device may include a button, a touch screen display, a keyboard, a camera, an audio input device (eg, a microphone or a portable audio information such as a microphone jack, etc.), and/or information may be Any other device received by the user or operator of the communication device 300. For example, if communication device 300 corresponds to IoT device 200A as shown in FIG. 2A and/or passive IoT device 200B as shown in FIG. 2B, logic 325 configured to receive local user input may include Buttons 222, 224A and 224B, display 226 (if touch screen), and the like. In another example, the configuration may be omitted for some communication devices The local user inputs logic 325, such as a network communication device (eg, a network switch or router, a remote server, etc.) that does not have a local user. The logic 325 configured to receive local user input may also include software that, when executed, permits the associated hardware configured to receive the logic 325 of the local user input to perform its input receiving function. However, the logic 325 configured to receive local user input corresponds not only to the software, but the logic 325 configured to receive the native user input is at least partially dependent on the hardware to achieve its functionality.

Referring to FIG. 3, although the configured logics 305 through 325 are shown in FIG. 3 as separate or distinct blocks, it will be appreciated that the logic of the respective configurations performs their functional hardware and/or software may partially overlap. For example, any software that facilitates the functionality of the configured logic 305 through 325 can be stored in non-transitory memory associated with logic 315 configured to store information such that the configured logic 305 through 325 are each The functionality is performed based at least in part on the operation of the software stored by logic 315 configured to store information (ie, in this case, software execution). Likewise, hardware directly associated with one of the configured logics can often be borrowed or used by other configured logic. For example, a processor configured to process information logic 310 can format the data into an appropriate format prior to transmission by logic 305 configured to receive and/or transmit information such that it is configured to receive and/or transmit information. The logic 305 performs its functionality (i.e., in this case, the transfer of data) based at least in part on the operation of the hardware (i.e., the processor) associated with the logic 310 configured to process the information.

In general, the phrase "configured to perform a certain operation of logic" as used throughout the present invention is intended to invoke an aspect that is at least partially implemented by hardware, and is not intended to be mapped, unless otherwise explicitly stated. A software-independent implementation that is independent of the hardware. Moreover, it will be understood that the logic of the configuration in the various blocks or the "logic that is configured to perform an operation" is not limited to a particular logic gate or component, but generally refers to the ability to perform the functionality described herein (via Hard or a combination of hardware and software). So despite the shared words "Logic", but the logic of the configuration as described in the various blocks or the "logic configured to perform an operation" is not necessarily implemented as a logic gate or logic element. Other interactions or cooperation between the logic in the various blocks will become apparent to those skilled in the art by reviewing the aspects described in greater detail below.

Various embodiments may be implemented on any of a variety of commercially available server devices, such as server 400 illustrated in FIG. In an example, server 400 may correspond to one example configuration of IoT server 170 described above. In FIG. 4, the server 400 includes a processor 401 coupled to a volatile memory 402 and a bulk non-volatile memory such as a disk drive 403. The server 400 can also include a floppy disk drive, compact disk (CD) or DVD player 406 coupled to the processor 401. The server 400 can also include a network access port 404 coupled to the processor 401 for establishing and connecting to the network 407 (such as being coupled to other broadcast system computers and servers or coupled to the Internet) The data connection of the network area network). In the context of FIG. 3, server 400 of FIG. 4 will be described to illustrate one implementation of communication device 300 whereby logic 305 configured to transmit and/or receive information corresponds to being used by server 400 to interface with the network. 407 communication network access point 404, logic 310 configured to process information corresponds to processor 401, and logic 315 configuration for storing information corresponds to volatile memory 402, disk drive 403, and/or disk drive Any combination of 406. The optional logic configured to present information 320 and the optional logic configured to receive local user input 325 are not explicitly shown in FIG. 4 and may or may not be included therein. Thus, Figure 4 helps to demonstrate that communication device 300 can be implemented as a server in addition to the IoT device implementation as in Figure 2A.

IP-based technologies and services are becoming more mature, driving down costs and increasing the availability of IP. This situation allows Internet connectivity to be added to more and more everyday electronic objects. IoT is based on everyday electronic objects (not just computers and computer networks) that are readable, identifiable, addressable, addressable and controllable via the Internet. In general, with the development and popularity of IoT, there are many different types of heterogeneous IoT devices and other physical objects that perform different activities (eg, lamps, printers, ice). Boxes, air conditioners, etc.) can interact with one another in many different ways and in many different ways. Thus, due to the potentially large number of heterogeneous IoT devices and other physical objects that can be used in a controlled IoT device, a well-defined and reliable communication interface can often be required to enable various heterogeneous IoT devices to communicate with each other and exchange information. Accordingly, the following description with respect to FIGS. 5-7 generally outlines an exemplary communication framework in accordance with various aspects and embodiments disclosed herein that can support peer-to-peer (P2P) services to enable inter-IOT devices. Communication.

In general, user equipment (UE) such as phones, tablets, laptops and desktops, certain vehicles, etc., can be configured to be locally (eg, Bluetooth, local Wi-Fi, etc.) or Remotely connected to each other (e.g., via a cellular network, via the Internet, etc.). In addition, some UEs may also support proximity-based peer-to-peer (P2P) communications using certain wireless network connectivity technologies (eg, Wi-Fi, Bluetooth, Wi-Fi Direct, etc.) for wireless network connectivity. The technology enables the device to be connected one-to-one or simultaneously to a group comprising several devices to communicate directly with each other. To this end, Figure 5 illustrates an exemplary wireless communication network or WAN 500 that can support detectable P2P services. For example, in one embodiment, wireless communication network 500 can include an LTE network including various base stations 510 and other network entities or another suitable WAN. For simplicity, only three base stations 510a, 510b, and 510c, one network controller 530, and one dynamic host configuration protocol (DHCP) server 540 are shown in FIG. Base station 510 can be an entity that communicates with device 520 and can also be referred to as a Node B, an evolved Node B (eNB), an access point, and the like. Each base station 510 can provide communication coverage for a particular geographic area and can support communication of devices 520 located within the coverage area. To improve network capacity, the total coverage area of base station 510 can be divided into multiple (eg, three) smaller areas, each of which can be servoed by a respective base station 510. In 3GPP, the term "cell" may refer to the coverage area of base station 510 and/or base station subsystem 510 that serves this coverage area depending on the context in which the term is used. In 3GPP2, the term "sector" or "cell sector" may refer to a coverage area of base station 510 and/or a base that serves this coverage area. Desk subsystem 510. For the sake of clarity, the 3GPP concept "cell" can be used in the description herein.

Base station 510 can provide communication coverage for jumbo cells, micro cells, pico cells, and/or other cell types. A jumbo cell may cover a relatively large geographic area (e.g., a few kilometers in radius) and may allow unrestricted access by device 520 in the case of service subscriptions. The microcell may cover a relatively small geographic area and may allow unrestricted access by device 520 in the case of service subscriptions. A femto cell may encompass a relatively small geographic area (e.g., a home) and may allow restricted access by a device 520 (e.g., device 520 in a closed subscriber group (CSG)) associated with the femto cell. In the example shown in FIG. 5, wireless network 500 includes jumbo base stations 510a, 510b, and 510c for jumbo cells. Wireless network 500 may also include a micro base station 510 for a micro cell and/or a home base station 510 (not shown in FIG. 5) for a pico cell.

Network controller 530 can be coupled to a collection of base stations 510 and can provide coordination and control for such base stations 510. Network controller 530 can be a collection of single network entities or network entities that can communicate with the base station via a backhaul. The base station can also communicate with each other, for example, directly or indirectly via a wireless or wired backhaul. DHCP server 540 can support P2P communication as described below. DHCP server 540 can be part of wireless network 500, external to wireless network 500, via Internet Connection Sharing (ICS), or any suitable combination thereof. DHCP server 540 can be a separate entity (e.g., as shown in FIG. 5), or can be part of base station 510, network controller 530, or some other entity. In any event, DHCP server 540 can be reached by device 520 that desires to communicate between peers.

Device 520 can be dispersed throughout wireless network 500, and each device 520 can be fixed or mobile. Device 520 may also be referred to as a node, user equipment (UE), station, mobile station, terminal, access terminal, subscriber unit, and the like. Device 520 can be a cellular telephone, a personal digital assistant (PDA), a wireless data modem, a wireless communication device, a handheld device, a laptop, a wireless telephone, a wireless area loop (WLL) station, a smart phone, a mini pen Recording computers, smart notebooks, tablets, etc. Device 520 can communicate with base station 510 in wireless network 500 and can further communicate with other devices 520 in the same level. For example, as shown in FIG. 5, devices 520a and 520b can communicate with each other, devices 520c and 520d can communicate with each other, devices 520e and 520f can communicate with each other, and devices 520g, 520h, and 520i can communicate with each other. The remaining device 520 can be in communication with the base station 510. As further shown in FIG. 5, devices 520a, 520d, 520f, and 520h may also communicate with base station 500, for example, while not busy with P2P communication or possibly concurrent with P2P communication.

In the description herein, WAN communication may refer to communication between device 520 and base station 510 in wireless network 500, such as for a call by a remote entity such as another device 520. The WAN device is a device 520 that is interested in WAN communication or busy with WAN communication. P2P communication refers to direct communication between two or more devices 520 without going through any base station 510. The P2P device is a device 520 that is interested in P2P communication or is busy with P2P communication, such as device 520 having traffic information for another device 520 within the close proximity of the P2P device. Two devices can be considered to be within close proximity of one another, such as where each device 520 can detect another device 520. In general, device 520 can communicate with another device 520 either directly (for P2P communication) or via at least one base station 510 (for WAN communication).

In one embodiment, direct communication between P2P devices 520 can be organized into P2P groups. More specifically, a P2P group generally refers to a group of two or more devices 520 that are interested in P2P communication or busy with P2P communication, and a P2P link refers to a communication link for a P2P group. Moreover, in one embodiment, the P2P group can include one device 520 representing a P2P group owner (or P2P server) and one or more devices 520 representing P2P clients served by the P2P group owner. The P2P group owner can perform certain management functions, such as signaling with the WAN, coordinating data transmission between the P2P group owner and the P2P client. For example, as shown in FIG. 5, the first P2P group includes devices 520a and 520b within the coverage of the base station 510a, and the second P2P group is included in the coverage of the base station 510b. In the range of devices 520c and 520d, the third P2P group includes devices 520e and 520f within the coverage of different base stations 510b and 510c, and the fourth P2P group includes devices 520g within the coverage of base station 510c, 520h and 520i. Devices 520a, 520d, 520f, and 520h may be P2P group owners for their respective P2P groups, and devices 520b, 520c, 520e, 520g, and 520i may be P2P clients in their respective P2P groups. Other devices 520 in Figure 5 can be busy with WAN communications.

In one embodiment, P2P communication may occur only within a P2P group, and may further occur only between the P2P group owner and the P2P client associated therewith. For example, if two P2P clients (eg, devices 520g and 520i) within the same P2P group desire to exchange information, one of the P2P clients can send information to the P2P group owner (eg, device) 520h), and the P2P group owner can then relay the transmission to other P2P clients. In one embodiment, the particular device 520 may belong to multiple P2P groups and may be represented as a P2P group owner or a P2P client in each P2P group. Moreover, in one embodiment, a particular P2P client may belong to only one P2P group or belong to multiple P2P groups and communicate with P2P device 520 in any of a plurality of P2P groups at any particular time. In general, communication can be facilitated via transmissions on the downlink and uplink. For WAN communication, the downlink (or forward link) refers to the communication link from base station 510 to device 520, and the uplink (or reverse link) refers to the communication from device 520 to base station 510. link. For P2P communication, the P2P downlink refers to the communication link from the P2P group owner to the P2P client, and the P2P uplink refers to the communication link from the P2P client to the P2P group owner. In some embodiments, two or more devices may form a smaller P2P group and use P2P communication over a wireless local area network (WLAN) using techniques such as Wi-Fi, Bluetooth, or Wi-Fi Direct. Instead of using WAN technology for P2P communication. For example, P2P communication using Wi-Fi, Bluetooth, Wi-Fi Direct, or other WLAN technologies may enable two or more mobile phones, game consoles, laptops, or other suitable communication entities. P2P communication is performed between.

In accordance with an aspect of the present invention, FIG. 6 illustrates an exemplary environment 600 in which a detectable P2P service can be used to establish a close-range decentralized bus, via which various devices 610, 630, 640 can be distributed via a close-range Row communication. For example, in one embodiment, communication between applications and their like on a single platform may be facilitated via a decentralized bus 625 using an inter-program communication protocol (IPC) framework, which may be A software bus that enables application-to-application communication in a network-connected computing environment, where the application registers with the decentralized bus 625 to provide services to other applications, and other applications are dispersed Bus 625 queries for information about registered applications. This protocol may provide asynchronous notifications and remote procedure calls (RPCs), where signal messages (eg, notifications) may be peer-to-peer or broadcast, and method call messages (eg, RPC) may be synchronous or non-synchronous, and A decentralized bus 625 (eg, a "sprite assist program" bus program) can handle message routing between various devices 610, 630, 640.

In one embodiment, the decentralized bus 625 can be supported by a variety of transport protocols (eg, Bluetooth, TCP/IP, Wi-Fi, CDMA, GPRS, UMTS, etc.). For example, according to one aspect, the first device 610 can include a decentralized bus node 612 and one or more local endpoints 614, wherein the decentralized bus node 612 can facilitate association with the first device 610 The local end point 614 is connected to the local end points 634 and 644 associated with the second device 630 and the third device 640 via the decentralized bus bar 625 (eg, via the second device 630 and the third device 640). Communication of decentralized busbar nodes 632 and 642). As will be described in greater detail below with respect to FIG. 7, decentralized bus 625 can support a symmetric multi-device network topology and can provide robust operation in the presence of device exits. Thus, a virtual decentralized bus 625, which can generally be independent of any underlying transport protocol (eg, Bluetooth, TCP/IP, Wi-Fi, etc.), can be allowed to be self-secure (eg, open) to secure (eg, authenticated) And encryption) various security options in which security options can be used while facilitating the first device 610, the second device 630, and the third device while the various devices 610, 630, 640 are in or near each other. 640 spontaneous connections without interference.

In accordance with an aspect of the present invention, FIG. 7 illustrates an exemplary sequence of messages 700 in which a detectable P2P service can be used to establish a close-range decentralized bus, a first device ("Device A") 710 and a second device (" Device B") 730 can communicate via the proximity-based decentralized bus. In general, device A 710 can request to communicate with device B 730, where device A 710 can include a local endpoint 714 (eg, a local application, service, etc.) that can make a communication request, plus this can help facilitate this. The bus node 712 of the communication. In addition, device B 730 can include a local end 734 that local end 714 can attempt to communicate with, which can help facilitate local end 714 on device A 710 and local end 734 on device B 730. The bus node 732 of the communication.

In one embodiment, bus nodes 712 and 732 can perform a suitable detection mechanism at message sequence step 754. For example, a mechanism for detecting connections supported by Bluetooth, TCP/IP, UNIX, or the like can be used. At message sequence step 756, the local endpoint 714 on device A 710 can request to connect to an entity, service, endpoint, etc., available via bus node 712. In one embodiment, the request may include a request and response procedure between the local endpoint 714 and the bus node 712. At message sequence step 758, a decentralized message bus can be formed to connect bus node 712 to bus node 732 and thereby establish a P2P connection between device A 710 and device B 730. In one embodiment, the communication used to form the decentralized busbar between busbar nodes 712 and 732 can be facilitated using a suitable proximity-based P2P protocol (eg, designed to enable the connected product and between different manufacturers of software applications communicate to dynamically generate the web and facilitate proximal end of the proximal AllJoyn ^TM software framework of a P2P communication). Alternatively, in one embodiment, a server (not shown) may facilitate the connection between busbar nodes 712 and 732. Moreover, in one embodiment, a suitable authentication mechanism can be used prior to forming a connection between bus nodes 712 and 732 (eg, the client can send an authentication command to initiate SASL authentication of the authentication session). Again, during message sequence step 758, bus nodes 712 and 732 can exchange information about other available endpoints (e.g., local endpoint 644 on device C 640 in FIG. 6). In these embodiments, each of the end endpoints maintained by the bus node can be advertised to other bus nodes, where the advertisements can include unique endpoint names, delivery types, connection parameters, or other suitable information.

In one embodiment, at message sequence step 760, bus node 712 and bus node 732 can use the information obtained in association with endpoints 734 and 714, respectively, to generate real that can be expressed via various bus nodes. The virtual endpoint of the obtained endpoint. In one embodiment, the routing of messages on the bus node 712 can deliver messages using real and virtual endpoints. In addition, there may be one local virtual endpoint for each endpoint present on the remote device (eg, device A 710). Again, such virtual endpoints may be multiplexed and/or demultiplexed via a decentralized bus (eg, a connection between bus node 712 and bus node 732). In one aspect, the virtual endpoint can receive messages from the regional bus node 712 or 732, just like a real endpoint, and can deliver messages via a decentralized bus. Thus, the virtual endpoint can deliver messages from the endpoint multiplex decentralized bus connection to the regional bus nodes 712 and 732. Moreover, in one embodiment, virtual endpoints corresponding to virtual endpoints on the remote device can be reconnected at any time to accommodate the desired topology for a particular delivery type. In this aspect, a UNIX-based virtual endpoint can be considered local, and thus may not be considered a candidate for reconnection. In addition, TCP-based virtual endpoints may be optimal for one hop route (eg, each bus node 712 and 732 may be directly connected to each other). Also, Bluetooth-based virtual endpoints are optimal for a single piconet (eg, a master and n slaves), where the Bluetooth-based master can be a local master node The same bus node.

At message sequence step 762, bus node 712 and bus node 732 can exchange bus status information to merge the bus instances and enable communication via the decentralized bus. For example, in one embodiment, bus status information may include well-known to unique endpoint name mappings, matching rules, routing groups, or other suitable information. In one implementation For example, using the interface with the local endpoints 714 and 734 (using the local name based on the decentralized busbar to communicate with it), status information can be communicated between the busbar node 712 and the busbar node 732 instances. In another aspect, each of the bus node 712 and the bus node 732 can maintain a regional bus controller that is responsible for providing feedback to the decentralized bus, wherein the bus controller can implement the global method , arguments, signals, and other information are translated into standards associated with decentralized busses. At message sequence step 764, bus node 712 and bus node 732 can communicate (e.g., broadcast) signals to inform respective local endpoints 714 and 734 about being introduced during a bus node connection such as described above. Any change. In one embodiment, the new and/or removed global and/or translated names may be indicated by a name owner change signal. In addition, the global name that can be lost at the local end (eg, due to a name conflict) can be indicated by a name loss signal. Also, the global name transferred due to the name conflict may be indicated by the name owner change signal, and if and/or when the bus node 712 and the bus node 732 become disconnected, the unique name can be changed by the name owner. To indicate.

As used above, well-known names can be used to uniquely describe the local endpoints 714 and 734. In one embodiment, when communication occurs between device A 710 and device B 730, different well-known name types can be used. For example, the device local name may only exist on the bus node 712 associated with device A 710 to which bus bar node 712 is directly attached. In another example, a global domain name may exist on all known busbar nodes 712 and 732, where only one owner of the name may exist on all busbar segments. In other words, when the bus node 712 and the bus node 732 are engaged and any conflict occurs, one of the owners may lose the global name. In yet another example, the translated name may be used when the client connects to other bus nodes associated with the virtual bus. In this aspect, the translated name may include an additional end (eg, the local end point 714 with the well-known name "org.foo" connected to the decentralized bus with the global unique identifier "1234" can be considered "G1234.org.foo").

At message sequence step 766, bus node 712 and bus node 732 can communicate (e.g., broadcast) signals to inform other bus nodes about changes in the endpoint bus topology. Thereafter, the traffic from the local endpoint 714 can move through the virtual endpoint to the intended native endpoint 734 on device B 730. Moreover, in operation, communication between the local endpoint 714 and the native endpoint 734 can use a routing group. In one aspect, a routing group enables an endpoint to receive signals, method calls, or other suitable information from a subset of the endpoints. Thus, the routing name can be determined by the application connected to bus node 712 or 732. For example, a P2P application can use a unique, well-known routing group name built into the application. In addition, bus nodes 712 and 732 can support registration and/or deregistration of local endpoints 714 and 734 to routing groups. In one embodiment, the continuity of the routing group may not exceed the current bus instance. In another aspect, the application can register its preferred routing group each time the application connects to the decentralized bus. Also, the group can be open (eg, any endpoint can join) or closed (eg, only the creator of the group can modify the group). Again, bus node 712 or 732 can send a signal to inform other remote bus nodes of additions, removals, or other changes to the routing group endpoints. In such embodiments, whenever a group adds a member and/or removes a member from the group, the bus node 712 or 732 can send a routing group change signal to other group members. In addition, bus node 712 or 732 can send a routing group change signal to the endpoint that is disconnected from the decentralized bus, rather than first removing itself from the routing group.

In accordance with various aspects of the present invention, FIG. 8 illustrates an exemplary method 800 that can be used to automatically create configurable sub-segments within an IoT network, and thereby manage various heterogeneous IoT devices and can have different types and perform different activities (eg, , lights, printers, refrigerators, air conditioners, etc.) and other physical objects with different interactions and usage patterns. In particular, due to the potentially large number of heterogeneous IoT devices and other physical objects that are available in the controlled IoT network, coordinate the interactions and uses associated with them to implement the desired functions or otherwise control the IoT network. It can be difficult to meet user needs and needs. For example, visitors to other people’s homes can expect to be heard in the house. Play a song on the device. However, the visitor may not be able to copy the song (eg, because the song has digital rights management embedded in it), Bluetooth pairing to another device may be difficult, or other conditions may interfere with smooth playback on the indoor speaker The ability of the song. In addition, due to the potentially large number of devices and other physical objects that are available in the controlled IoT network, users searching for available devices can be overwhelmed by options that are as high as the search results may actually be useless. Thus, as described in greater detail herein, the method 800 illustrated in FIG. 8 can be used to automatically organize or otherwise group various heterogeneous IoT devices and other physical objects (eg, non-IoT devices with communication capabilities and/or without Other physical objects of communication capabilities) that enable automatic and configurable control of the IoT network to enable heterogeneous IoT devices and other physical objects deployed in the network to work together more efficiently and optimally Communication and information sharing, and often improve overall effectiveness and user experience.

More specifically, in accordance with various aspects of the present invention, the method 800 illustrated in FIG. 8 may initially include detecting various devices and/or other physical objects at block 810 and registering various devices and/or other physical objects. In the IoT network, the supervisor device associated with the IoT network can detect and register one or more IoT devices, one or more non-IoT devices, and/or be coupled in block 810, among other ways Used for other suitable physical objects in a controlled IoT network. In one embodiment, the IoT device detected and registered in the IoT network at block 810 can include an embed device that can be embedded in the supervisor device, viewed by the supervisor device, monitored by the supervisor device, and monitored by the supervisor device. Any suitable electronic device that controls or otherwise manages certain attributes and status information by the supervisor device and is connected to the IoT network (eg, appliances, sensors, refrigerators, ovens, ovens, microwave ovens, freezers, washes) Dishwashers, washing machines, clothes dryers, stoves, air conditioners, thermostats, televisions, electric lamps, vacuum cleaners, fuel gauges, gas meters, honeycomb phones, desktop computers, laptops, tablets, etc.) . In one embodiment, the attributes associated with the IoT device can be expressed using a generic vocabulary that provides versatility, adaptability, and can define any suitable aspect related to the interaction and use associated with the IoT device. Scalable structural description (for example, structure The description values can be based on the evolution of the surrounding environment and the interaction between the detection and IoT devices or otherwise adapted, and new structure description elements can be added to augment the existing IoT device vocabulary). For example, in one embodiment, a generic vocabulary may express attributes associated with a particular IoT device based on a structure description element, which may include, inter alia, global unique identifiers, constructs, models, types, and version attributes, supported Input (eg, voltage, amperage, gallon, BTU, etc.), supported outputs (eg, watts, temperature, area units, volume units, speed, etc.), supported capabilities (eg, start, stop, shutdown, hibernate, wait Use, reset, introduce, etc. and supported communication methods (eg, Bluetooth, Wi-Fi, Infrared, Near Field Communication, Shortwave Radio, etc.). In addition, the status information associated with the IoT device can indicate whether the IoT device is on or off, on or off, idle or active, and can be used for task execution or busy or any other suitable information related to the conditions associated with the IoT device. .

Moreover, in one embodiment, the non-IoT device detected and registered in the IoT network at block 810 may include a bar code device, a Bluetooth device, an RF device, an RFID tag device, an IR device, or may be via a small range interface. (eg, an empty interfacing) Any other suitable device that the communication and supervisor devices can observe, monitor, control, or otherwise manage. In addition, other physical objects that can be detected and registered to the IoT network can include non-IoT devices that do not have communication capabilities. For example, a supervisor device or other IoT device can have an appropriate scanner or reader mechanism that can detect the shape, size, color, or other associated with a non-communicating physical object. Observing the features, the non-communicating physical objects can then be registered in the IoT network. In addition, in response to the user providing a command to add the device and/or object to the IoT network to the supervisor device or based on other automatic detection capabilities (eg, in response to the user placing an online order to purchase a particular item and subsequently determining the object) Already delivered to the home, certain IoT devices, communication non-IoT devices, and/or non-communicating physical objects may be explicitly registered in the IoT network at block 810. In this manner, any suitable physical object can be detected and registered in response to block 810 (eg, via supervision) Device) becomes part of the IoT network.

In one embodiment, at block 820, the supervisor device can then monitor the interaction and use associated with the device and/or other objects detected and registered at block 810, wherein the monitored interactions and uses are followed. One or more groups, sub-networks, subsets, or other suitable sub-segments within the IoT network can be created at block 830. For example, in one embodiment, each device or object registered at block 810 can include a globally unique identifier, and each IoT device can further include a local repository that stores and stores Information about an encounter or other interaction with another device or object in the IoT network (eg, a globally unique identifier corresponding to other devices or objects associated with the interaction, an interaction-related timestamp, or other time context , interactions or other interaction-related functions, locations where interactions occur, or other appropriate contexts related to interactions, such as when the owner is present or away from the IoT network when an interaction occurs.

Thus, in one embodiment, the IoT device can communicate information relating to each encounter or other interaction stored in the local repository to the supervisor device, which can further maintain storage and IoT networks. A local repository of information about each encounter or other interaction to monitor interaction and use at block 820. Moreover, in one embodiment, the supervisor device can observe or otherwise monitor other interactions and uses occurring in the IoT network at block 820 to further populate the local repository. For example, in one embodiment, a non-IoT device can include a coffee cup having an RFID tag or barcode, wherein the cabinet IoT device can have a suitable scanner or reader that can read the RFID tag Or a barcode to detect when the coffee cup is placed in or removed from the cabinet. In another example, the refrigerator IoT device can be equipped with a similar scanner or reader mechanism that can read RFID tags on items added by the refrigerator IoT device or removed from the refrigerator IoT device. Or bar code, and/or detecting a shape, size, color, or other observable feature associated with a non-communicating physical object added or removed therefrom to identify a non-communicating physical object (eg, a refrigerator IoT device can be aware of lime and Lemon has a defined solid shape And size, and based on whether the object is green or yellow, the object with the addition or removal of the shape and size of the entity is lime or lemon). In yet another example, the refrigerator IoT device can reside in the kitchen such that the refrigerator IoT device can record and access when a visitor to a home associated with the IoT network enters the kitchen and is within proximity of the refrigerator IoT device The encounter of the person and/or any other individual present in the kitchen.

In one embodiment, as noted above, the supervisor device may thereby create one or more groups, sub-networks within the IoT network based on the interaction and usage monitored at block 820 at block 830, A subset or other suitable sub-segment, wherein the interactions monitored at block 820 are typically available in various IoT devices, IoT devices and communication non-IoT devices, IoT devices and non-communication entities, communication non-IoT devices, and non-communication entities, A plurality of non-communicating physical objects or any suitable combination thereof occurs, and monitoring usage at block 820 can typically be with one or more IoT devices, one or more communication non-IoT devices, one or more non-communicating physical objects Or any suitable combination thereof. In particular, the IoT device can communicate relevant information related to any interactions associated with and associated with the IoT device to the supervisor device, which can then fill in the local database using the communicated information. . However, because communication non-IoT devices and non-communicating physical objects may not store all information related to their interaction and use, the supervisor device may derive relevant information based on other signals communicated within the IoT network (eg, supervisor) The device may derive information relating to the interaction and use associated with communicating non-IoT devices from: a globally unique identifier that is transmitted by the non-IoT device to the supervisor device, when the unique identifier is received, may indicate an interaction or The location information used, etc., and the supervisor device can similarly derive any relevant information from the IoT device and/or the communication non-IoT device to the supervisor device to derive information related to the interaction and use associated with the non-communicating entity object) .

In one embodiment, to subsequently create one or more groups, sub-networks, subsets, or other suitable sub-segments within the IoT network at block 830, the supervisor device can be based on the records in the local database. The monitored interaction and usage decisions are registered to various devices in the IoT network Explicit, implicit, predefined, dynamic, or other suitable relationship between the piece and the object. More specifically, certain devices or objects may be pre-programmed to have an explicit relationship with another device or object (eg, the refrigerator may be located in a person with a refrigerator and in an IoT network (such as a primary refrigerator permanently) Located in the kitchen, and the secondary refrigerator is permanently located in the garage) with an explicit relationship). In addition, an implicit relationship between the visitor and the owner can be automatically derived to add the visitor to the trusted group of friends in response to the interaction and usage of the monitored visitor entering the kitchen while the owner is present. For example, a supervisor device can organize people who access or otherwise access the IoT network into a hierarchy (eg, family, friends, acquaintances, etc.). Thus, in response to the monitored interaction indicating the first meeting with a particular individual, the supervisor device can add the individual to the acquaintance group at block 830. Further, in response to a subsequent monitored interaction indicating an additional meeting with the individual during a certain time period, the supervisor device may upgrade the individual self-acquaintance group to the group of friends at block 830. Also, if additional meetings occur within the home associated with the IoT network or at certain times (eg, indicating that the owner and other individuals frequently spend the evening together), the supervisor device can be at block 830. Upgrade an individual to a family group.

Moreover, in one embodiment, the various groups created at block 830 can similarly create sub-segments associated with physical devices and other objects registered in the IoT network. In particular, based on how physical devices and other objects are used and interacted within the IoT network, physical devices and other objects can be segmented into media devices, home office devices, and the like. For example, if the interactive and usage instructions use a camera to capture images, use a computer to download images from a camera, load an application onto a computer to edit images or share images online and share images with certain individuals. For example, the group created at block 830 can include an image group having a number of members including a camera, a computer, a computer application, an individual sharing the image, and the downloaded image itself. In another example, if the interactions monitored during use of the projection instrument and the lights in the usage indication chamber are always off or dim, then the group created at block 830 can include a suitable child with several members. Segmentation, such members include Projection instruments, lights, and rooms where the projector and lights are dim or off.

Thus, various groups created at block 830 can be dynamically formed using machine learning algorithms (eg, performed by the supervisor device) based on actual usage and interactions observed or otherwise monitored in the IoT network. In this manner, groups can be created independently of any predefined semantic structure or language at block 830, rather than in a dynamic and special manner (which learns the context in a manner that reflects user preferences and real-world activities). Group structure.

Moreover, in one embodiment, the user may have the ability to customize the group structure created at block 830 and thereby adjust the context of the automated learning to better reflect user preferences and real-world activities and to improve the supervisor device. The ability to interact and use the learning context. For example, in one embodiment, various groups created at block 830 may be presented at block 840 via a user interface (eg, on a supervisor device), and the supervisor device may then be in the block At 850, it is determined whether a user command is received. Thus, in response to determining that no user command was received at block 850, the supervisor device can repeatedly monitor the interaction and usage in the IoT network (ie, return to block 820 and subsequent blocks), and assume The criteria in the machine learning algorithm accurately reflect the group, subset, subnet, or other suitable sub-segment within the IoT network with the user preferences and real-world activities previously used to create the group.

On the other hand, in response to determining that a user command was received at block 850, the supervisor device can then process the command at block 860. For example, in one embodiment, commands can be used to modify the group created at block 830 and/or create a new group, in which case the supervisor device can appropriately adapt based on the command at block 860. Edit groups and/or create new ones. In addition, commands can be used to control access to certain locations within the IoT network (eg, subnetworks including certain devices and/or other objects). For example, in one embodiment, the command can be used to provide full access to everything in the IoT network to any of the family groups, providing the person in a group of restricted accesses To the IoT network (for example, allowing any of the friends group to use the Wi-Fi subnet within the entire IoT network, The person in the customer service group accesses the refrigerator to feed the pet when the owner can vacation or access the miscellaneous room to service the failed device, etc., or otherwise finer-grained access control Provided to an IoT network (eg, controlling a particular subnet accessible to a guest, controlling how devices and/or other objects in the IoT network can interact or use with each other, etc.). Additionally, in response to processing the command appropriately at block 860, the supervisor device can repeatedly monitor the interaction and usage in the IoT network in a manner similar to that in the absence of the command (ie, returning to block 820). And subsequent blocks), in addition to the supervisory device, which can improve the criteria used in machine learning algorithms to create or modify groups, subsets, subnetworks, or other suitable subdivisions within the IoT network to more accurately reflect In addition to the user preferences and real world activities indicated in the command processed by block 860.

Although the foregoing description of the method 800 illustrated in FIG. 8 may appear to indicate that the supervisor device represents a device separate from the device and/or other physical objects in the controlled IoT network, those skilled in the art will appreciate that The particular IoT device in the controlled IoT network can be a supervisor device, the supervisor device can be incorporated into a particular IoT device in a controlled IoT network, or any other suitable configuration or arrangement can be used. For example, in one embodiment, the supervisor device can correspond to a computer or cellular phone that performs device control or management operations, plus the use of local properties to perform certain functions (eg, a computer can The supervisor device coordinates the illumination effects of the projection screen while separately adjusting the cross-talk transmission to the projector for outputting the contrast ratio of the video to accommodate coordinated illumination effects, etc.). Thus, the foregoing description indicates the exchange of certain signals or other information between the supervisor device and the devices and other objects that form the controlled IoT network. Those skilled in the art will appreciate that the supervisor device corresponds to a controlled IoT network. In the case of a particular IoT device, certain signals or messages may be omitted.

The above background has been provided regarding certain mechanisms that can be used to create related sub-segments within an IoT network based on the monitored interactions in the IoT network, and the following description details the use of IoT technology to detect devices (and related locations) Relationship between the user of the device) DEK checks and balances the detected relationships to control the interaction between devices (for example, if the visitor and homeowner have a known relationship, allowing the visitor to play songs on the speakers in the house quickly and smoothly). More specifically, as noted above, various IoT devices can be detected and registered with a server or other suitable supervisor device and associated with various attributes that can be expressed using a common vocabulary. For example, attributes typically describe the location, interaction, usage, or other relevant status data associated with an IoT device. In addition, each IoT device can be assigned a unique identifier and has a local repository to store each interaction of the IoT device with other IoT devices, including other user-owned IoT devices. Thus, the more the IoT device interacts with the IoT device associated with another user, the stronger the relationship that can be implied or otherwise inferred between the IoT device and thus the user having the IoT device. Moreover, the strength and/or type associated with the relationship may be further implied or otherwise inferred based on the type of interaction with the IoT device interacting with each other, the location at which the interaction occurred, the time at which the interaction occurred, or other suitable factors.

In one embodiment, the relationship between the IoT device and its associated user may be explicit, implicit, predefined, dynamic, or other suitable type, and the relationship may be further hierarchically organized (eg, based on acquaintances, Friends, close friends, family, etc.). Alternatively (or in addition), the relationship may be numbered or assigned another suitable order (eg, from one to five or one to ten, one of which is the weakest relationship and five or ten is the strongest relationship). In one embodiment, when two IoT devices interact with each other for the first time, the relationship between the two IoT devices can be assigned the lowest order, and the order associated with the relationship can be based on further interaction between the IoT devices over time. increase. For example, at the first interaction between two different users, the individual IoT devices owned by the user can record interactions and assign acquaintance relationships to the user. After additional interaction between users, and possibly within a certain period of time or at certain locations, the IoT device can upgrade the relationship between users to friends. If interaction occurs at home and at a certain time (for example, every night), the relationship between users can be further upgraded to family members and the like.

In one embodiment, the type and/or location associated with a particular IoT device can be balanced to imply a relationship between two users. In this context, the location associated with an IoT device does not necessarily refer to a geographic location, but may refer to a room or other personal space in which an IoT device can be placed, which can be inferred from the type associated with the device. For example, if the refrigerator IoT device detects an IoT device associated with a visitor, it can be inferred that the visitor is in the kitchen because the refrigerator will typically be located in the kitchen, thereby inferring that the visitor and the homeowner have a friend relationship or A higher relationship, because first-time acquaintances usually do not enter the human kitchen. In another example, if the IoT device knows that the user associated with it is working, any interaction with other IoT devices may not necessarily increase the order of other IoT devices, even if interaction occurs frequently. Rather, the relationship can remain at the acquaintance level. However, if the IoT device detects a working IoT device associated with another user at a non-working location (eg, in another user's home), the relationship between the users may increase because the location indication Users are interacting in a social context.

Moreover, in one embodiment, the time at which the IoT device associated with the first user interacts with the IoT device associated with another user can be counterbalanced to imply a relationship between the users. For example, if the IoT device associated with the first user detects a particular IoT device associated with another user at a specified time each month, the IoT device associated with the first user can determine another A user is not a very important user and therefore assigns a low order to the relationship. However, if the IoT device associated with the first user detects an IoT device associated with another user every night, the IoT device associated with the first user can determine that this is an important user, And therefore assign a higher order to the relationship. To make the strongest or most accurate relationship determination, the IoT device can balance any relevant determinable factors associated with the interaction (eg, frequency, location, time associated with the interaction, type associated with the IoT device interacting with each other, etc.) . In addition, the relationship can be appropriately reduced based on the detected interaction between the IoT device and/or the associated user. For example, if frequent interactions are detected between IoT devices associated with different users, and the interaction then stops For a long period of time, an inference can be made and the relationship between users has ended. In another example, if the IoT device associated with the first user frequently detects an IoT device associated with a particular visitor within the first user's premises, and then periodically accesses the stop, the user The relationship can be reduced to a less important relationship.

In one embodiment, each level of the relationship hierarchy may be assigned an access level to one or more IoT devices and/or IoT device groups. For example, an IoT device associated with a user having an acquaintance relationship can be granted low level access, while an IoT device associated with a family-related user can be granted a higher level or full access (eg, Depends on parental controls or other factors). In another example, an IoT device associated with a user having a friend relationship may be permitted to access an entertainment system, a local wireless network, a home appliance or other suitable IoT device and/or IoT device group, and is prohibited from re- Programmatically or otherwise modify an IoT device that is permitted to access. In addition, IoT devices associated with users with close ties can be granted access to more IoT devices and/or IoT device groups and/or greater control over the IoT devices that are permitted to access, with family relationships. The user-associated IoT device has access to and full control of all IoT devices.

Referring now to Figure 9, an exemplary method 900 for implicitly creating relationships between IoT devices can involve the interaction of IoT devices associated with various different users with IoT devices and the inference of IoT devices. The relationship-related information is sent to the management entity (for example, the supervisor device 130 shown in FIGS. 1B to 1D, the IoT server 170 shown in FIGS. 1A to 1B and FIGS. 1D to 1E, and the like). The management entity can then collate the interactive data received from the various IoT devices and use the proofreading interactive data to further infer the relationship between the IoT device and the user associated with the IoT device. For example, if the management entity determines that the particular relationship should have a different order based on the collated interaction data, the management entity may instruct the appropriate IoT device to update the relationship order stored in the local repository associated with it. Alternatively, in one embodiment, the IoT device may store only information about interactions with other IoT devices and transmit the interactive data to the management entity, which in turn may infer the relationship and notify the IoT device about The inferred relationship is such that the IoT device can use the relationships inferred by the management entity to control the granted access associated with other IoT devices.

Thus, in one embodiment, the method 900 shown in FIG. 9 may be performed at a particular IoT device, or the management entity may alternatively (or additionally) perform the method 900. In addition, the aspects described herein are further applicable to management entities because the management entity can include an IoT device that can detect and interact with other IoT devices, assign or otherwise rank with other IoT devices. The device-associated relationship, and based on the relationship, determines the permitted access of other IoT devices.

In one embodiment, at block 910, the IoT device associated with the first user can detect interaction with an IoT device belonging to another user and obtain sufficient information from other IoT devices to at least uniquely identify Other IoT devices. Thus, the IoT device can determine that other IoT devices are not the same user in response to determining that the user identifier associated with the other IoT device is different from the user identifier associated with the IoT device that is detecting the interaction. Alternatively, the IoT device can store the identifier associated with each IoT device owned by the first user in the registry, and if the other IoT device does not have the identifier present in the registry, then the other IoT device is determined. Not belonging to the same user.

In one embodiment, at block 920, the IoT device associated with the first user can record any decidable attribute associated with interaction of other IoT devices and with other IoT devices. For example, the attributes recorded may include, inter alia, identifiers associated with other IoT devices, types associated with other IoT devices, time of interaction, location of interaction, or personal space (eg, at the first user) In the workplace, outside the workplace, at the workplace, in the first user's house, in the indoor room, etc.). Additionally, the attributes associated with the interaction may indicate whether other IoT devices have requested access to the IoT device or another IoT device associated with the first user, what the IoT device has requested to access, and the like. Moreover, if the IoT device is different from the management entity, the IoT device can suitably transfer the attributes recorded at block 920 to the management device.

In one embodiment, at block 930, the IoT device can determine whether to update the relationship rankings associated with other IoT devices based on attributes associated with previously recorded interactions and/or attributes of the records associated with the current interaction. For example, if the current number of interactions increases or the frequency of interaction with other IoT devices is above a threshold, the IoT device can increase the relationship with other IoT devices at block 940. In another example, if the current interaction corresponds to the first interaction in the first user's home, the IoT device may also increase the relationship rank associated with other IoT devices at block 940. In yet another example, if the current interaction corresponds to a first interaction in a time period that exceeds a certain threshold, the IoT device can reduce the relationship rank associated with other IoT devices at block 940. Thus, if the IoT device determines at block 930 that the relationship associated with other IoT devices should be updated, the IoT device can update the relationship order appropriately at block 940.

In one embodiment, at block 950, the IoT device can determine whether the other IoT device has requested access to the IoT device or another IoT device associated with the first user (eg, based on the record at block 920). Attribute, which indicates that a request to access a message has been received from another IoT device. In response to determining that another IoT device has requested access to the IoT device or another IoT device associated with the first user, the IoT device can be at block 960 based on the rank control associated with the relationship assigned to the other IoT device with the other IoT device-associated access (eg, granting full access, granting restricted access, dismissing access, etc.).

In one embodiment, at block 970, if the IoT device does not correspond to a management entity, the IoT device then transmits the data related to the detected interaction to the management entity as appropriate. For example, the interactive material transmitted to the management entity may include attributes of records associated with other IoT devices and interactions, any updates or other changes to relationships associated with other IoT devices, and whether access is requested and/or Grant or dismiss instructions relating to the extent of any access, etc.

In accordance with one aspect of the present invention, because there are many IoT users, each of which may have potentially different personality and behavioral patterns, the following detailed description may advantageously determine that The classification will apply to various mechanisms of the measure of the relationship of as many feasible users as possible. For example, aspects associated with user personality and interaction strength may be considered in classifying relationships, where the relationship may be based on a percentage of user interaction rather than a specified number of users applied to the entire line. In particular, each IoT device can be assigned a unique identifier and has a local repository that stores information related to each interaction of the IoT device with other IoT devices. Alternatively, a centralized server, proxy, or other suitable entity can store information related to interactions between IoT devices. For example, in the home, the oven can store all interactions between the home residents and the light switch.

In general, the more times a particular IoT device associated with a first user interacts with one or more IoT devices associated with another user, the stronger the implicit relationship between users. The relationship can also be weakened. For example, if the IoT device detects frequent conferences between two users and then their conferences are stopped for a relatively long period of time, the IoT device can conclude that the relationship between the users has ended. In another example, if the IoT device frequently detects a particular visitor within the user's premises and then their periodic access stops, the IoT device can determine that the relationship has changed to a less important relationship. However, not all interactions between two IoT devices stop or become less frequent should result in a reduced relationship. Rather, historical interactions can make the interactions that are less repetitive in the future more relevant. For example, two users may be neighbors and good friends, but one neighbor may move away, resulting in a reduced number of interactions between users (and possibly a change in the type of interaction). At some future time, one of the users can move to another user again. In this scenario, it is possible that the user will find each other and re-establish or continue their previous intimacy. Therefore, if the order was previously lowered, the relationship should be given a higher order again. In any event, the strength and/or type of relationship may also be based on the type and/or location of the IoT device, and/or the number of interactions. Based on these factors, the IoT device can determine the implicit relationship between users. In one embodiment, the interaction between IoT devices can be proximity detection, text messaging, multimedia messaging, phone calls, email, and the like. Proximity detection can include close-up inspections (such as listening positions) LILO close-up check, Bluetooth pairing, communication via the same local wireless network, or any other interaction between two UEs indicating their proximity to each other. Alternatively or additionally, the server can determine that two or more IoT devices are close to each other based on the location of the IoT device stored at the server. For example, an IoT device can periodically transmit its location to a server (eg, every few minutes, several hours, etc.), which can compare the received locations to determine which IoT devices are on each other. Within the limit distance. The threshold may be a few meters or indicate that the IoT device may be some other threshold for the user interacting with each other.

In one embodiment, the IoT device interaction can be stored in one or more of the interactive tables at the IoT device and periodically (eg, every few hours, once a day, etc.) or uploaded to the server as required. Alternatively, the interaction can be uploaded to the server when it appears instantly and added to the interactive table on the server. In this case, there is no need for an interactive table on the IoT device. Each user can decide how they wish to store their user interaction form. For example, some users may wish to store it on their IoT device and have the server request it, or only the necessary entries, when needed, while other users may wish to simply upload their interaction to the store. Remote interaction table on the server. The interactive table can be organized by the identifier of its corresponding IoT device. The interactive table can store the identifier of the user, the identifier of the user's IoT device, the identifier of another user, the identifier of the IoT device of another user, the type of interaction (eg, close-up, email, text) Messages, phone calls, etc.), interactive location (if available), and the time and/or length of the interaction (eg, the start/end time of the interaction). A user can be associated with several IoT devices. The interactive table can store all interactions or only a certain number of interactions for each IoT device that occurs during the lifetime of the IoT device (ie, the time the IoT device is used by the same user), such as last year's interaction or the last 1000 interactions. .

In one embodiment, an appropriate time period for analyzing the data in the interactive table can be determined. For example, if a cycle period is used, the IoT device or server can analyze interactions within a 24-hour period, a one-month period, a one-year period, and the like. Also, if a cycle period (such as 24 hours) is used, the IoT device or server must ensure that hour 23 transitions to hour 0. All possible time configurations can be used to search for location patterns. For example, assume that the user is in the mall at 11:00 am to 3:00 pm every Sunday, or at his/her office every day from 9:00 am to 5:00 pm. As a first solution, the IoT device or server can build a transition table and use the transition distances in the transition table to compare data inputs with cluster analysis based on the transition distances in the transition table (eg, according to November 2013) The technique described in U.S. Provisional Patent Application Serial No. 61/901,822, the entire disclosure of which is incorporated herein in The way is explicitly incorporated). In another solution, the IoT device or server can create a cyclic relationship of time using a sinusoidal function, where each sinusoidal function can be re-established based on the current 24-hour clock time. For example, the function y=sin(x/7.5+j/12) creates a cyclic relationship that reflects a 24-hour clock, where x = one input time, j = second input time, and y = between two times distance. Figure 10 illustrates a graph 1000 of the function y = sin (x / 7.5 + j / 12).

In one embodiment, using the stored interactive table, the IoT device can assign the relationship values listed by the user in their interaction table to each other. Alternatively, if the server stores an interactive table, the server can assign a relationship value. Thus, various aspects of the present invention may take into account the user's personality and the intensity of the interaction in classifying relationships, rather than simply assigning relationships based on the number of interactions between users. For example, the relationship may be based on a percentage of user interaction, rather than a specified number of users applied to the entire line. That is, when the user interaction of the threshold percentage is for the same other user, the percentage of the threshold value occurs when the interaction of the threshold percentage occurs at a certain position (for example, in the user's home) When the interaction has a given type (eg, proximity detection), the family relationship is assigned at a certain time (eg, at night or not) when the interaction of the threshold percentage occurs. In addition, the relationship hierarchy can be assigned to IoT device users (eg, acquaintances, colleagues, golf friends, friends, close friends, family members, etc.). Alternatively, the relationship can be numbered from one to five or from one to ten, examples of which If one is the weakest, and five or ten is the strongest. At the first conference between the two IoT devices, the relationship can be assigned the lowest order. Over time, IoT devices or servers can add implicit relationships based on further interaction between IoT devices.

In one embodiment, the close interaction, the location at which it appears, the frequency of its occurrence, the time at which it occurred, and possibly its length are specifically related when determining the relationship. In order to make the strongest or most accurate relationship determination, the IoT device can balance all determinable factors of interaction. For example, users who are frequently together (ie, close to each other) at a particular location may be friends or family members (eg, two users who frequently shop together may be considered close friends). The IoT device or server can determine that two users are shopping together by detecting that two users are in a shopping mall at a threshold close to each other for a threshold period. IoT devices can initially assign a friend relationship to a user and then upgrade to a close friend after a limited number of shopping trips or other such interactions (eg, going to restaurants, nightclubs, social events, etc.).

In one embodiment, the time during which the user's IoT device interacts with another IoT device can be balanced to imply a relationship between the users. For example, if a user's IoT device detects a particular IoT device at a specified time each month, the IoT device can determine that this is not a very important relationship and assign a low order to the relationship. However, if the IoT device detects other IoT devices every night, the IoT device can determine this as an important relationship and assign a higher order to the relationship. For example, if two or more users frequently get together in the same room at approximately the same time each night for approximately the same amount of time (greater than a certain threshold), then the users may eat together Dinner and can be considered a family member. Similarly, if another user occasionally joins the user group at this time, the user may be a close friend or family member and his or her relationship status may be upgraded accordingly. On the other hand, users who are frequently together in other types of locations (even for relatively long periods of time) may not be friends or family members. For example, if the user's IoT device knows that the user is working, then any conference with other IoT devices, even if it occurs frequently, may not necessarily increase the order assigned to the relationship. Rather, the relationship can remain at the acquaintance level. However, if the user's IoT device is in a non-working position When the working IoT device is detected, the relationship between the users can be increased. For example, if a working IoT device is detected in the user's home, the relationship between the users can be increased to a friend.

In one embodiment, the type and/or location of the two IoT devices can also be balanced to imply a relationship between their two users. The location of the IoT device does not necessarily refer to its geographic location, but rather to the type of room in which it is located. This can be inferred from, for example, the type of device. For example, the refrigerator is usually located in the kitchen. Therefore, if the IoT device of the refrigerator detects an IoT device of a different user (eg, a visitor), meaning that the visitor is in the kitchen, the refrigerator IoT device may imply that the visitor has a friend or higher relationship with the homeowner because An acquaintance usually does not enter the human kitchen. Therefore, because the IoT device is interacting every day, the relationship group can be derived based on the context of the device, where the context is defined by the group and the group is defined by an implicit relationship. In some cases, more than one relationship (eg, friends and golf friends) may be assigned to the same user. By identifying and subsequently isolating such groups in time and space, the system can become more valuable to the user. Therefore, the user and his or her corresponding interactions are not necessarily defined in isolation. Rather, each user can be defined in their context. For example, a person can be two users: user A father and user B husband. When a person acts as a father in the context of User A, the interpretation of his interaction may be different from the interpretation of that person when User B is acting as a husband below.

In accordance with various aspects of the present invention, FIG. 11A illustrates an exemplary method 1100A that can implicitly create relationships between IoT devices. The method 1100A illustrated in FIG. 11A may be performed by an IoT device, such as an IoT device 110, 112, 114, 116, 118, 120, 200, or 300. Alternatively, the method 1100A illustrated in FIG. 11A may be performed by a supervisor device (such as supervisor device 130) or a server (such as IoT server 170). The aspects described herein are also applicable to supervisor devices because the supervisor device can detect and interact with the visitor IoT device, assign a relationship to it, and grant access based on the relationship.

In one embodiment, at block 1110, an interaction between the first user device and the second user device is detected. The first user device can be an IoT device that performs the method 1100A shown in FIG. The detecting can include detecting that the first user device is in proximity to the second user device. The first user device can detect that it is close to the second user device, or if the method 1100A is being executed by the server, the server can detect the location information received from the first user device and the second user device. The first user device is proximate to the second user device.

In one embodiment, at block 1120, information related to the interaction is stored in a first interaction table associated with the first user device. The interactive table can be stored on the first user device or on the server if the server is performing the method 1100A shown in Figure 11A. The information may include one or more of: an interaction type, an interaction location, an interaction time, an interaction duration, an interaction frequency, an identifier of the first user device, an identifier of a user of the first user device, The identifier of the second user device or the identifier of the user of the second user device. The type of interaction may include one of: proximity detection, a messaging service (SMS) message, a multimedia messaging service (MMS) message, a phone call, or an email.

In one embodiment, at block 1130, a relationship identifier is assigned to a user of the second user device based at least in part on the information related to the interaction. A relationship identifier can be added to the entry in the first interaction table of the user of the second user device. Assignment occurring at block 1130 can include assigning a relationship identifier to a user of the second user device based on a plurality of interactions with one or more user devices belonging to the user of the second user device. Information about a plurality of interactions can be stored in the first interaction table. The plurality of interactions may include a plurality of interactions occurring within a threshold period, occurring at the same time, occurring at the same location, having a duration of duration, having a threshold frequency, and/or having the same type of interaction. Additionally, in one embodiment, the assignment occurring at block 1130 can include updating the relationship identifier of the user of the second user device.

In accordance with another aspect of the present invention, FIG. 11B illustrates an exemplary method 1100B that can be used to track locations and interactions associated with various IoT devices and to detect user-specific and potentially asymmetric relationships between IoT devices. In particular, the method 1100A shown in FIG. 11A and described in greater detail below can implicitly create relationships between IoT devices based on interactions between IoT devices, but the relationships are often complex and coincident (eg, In some locations, at certain times, etc.) may not always indicate the actual relationship between different users. For example, two people can interact with each other frequently but still not friends. In addition, some relationships may be asymmetric, with the first person (David) treating another person (John) as a good friend, but John only sees David as an acquaintance. Thus, as will be described in greater detail herein, the method 1100B shown in FIG. 11B can be used to derive a relationship between different users based on location, interaction, usage, and other relevant state data associated with various IoT devices. Symmetry, this asymmetry can prove useful in determining or otherwise controlling how different IoT devices interact with each other. For example, in the case given above, tracking location, interaction, usage, and other relevant status data may actually indicate that David does not like John very much, and can balance his knowledge to control the IoT owned by David and John. Subsequent interaction between devices. In addition, tracking users who have a specific interaction location can be used to derive other relationship information. For example, if John frequently goes to David's cluster space but David rarely appears in John's cluster space, he can use his asymmetry to learn other information about the relationship between David and John.

More specifically, at block 1150, various registered IoT devices can transmit data related to their location and interaction to the server, which can track the location and IoT device associated with the IoT device. The interaction between the location and interactive data received from each IoT device and the location and interaction data received from other IoT devices to determine the user-specific relationship. In one embodiment, the location and interactive data tracked and stored at the server may be processed at certain time intervals (eg, daily) to identify certain similarities (eg, in usage patterns, location coincidence, etc.). Therefore, the server can determine the current tracking week. Whether the period has ended at block 1155, and then processing the tracked location and interactive data in response to determining that the current tracking period has ended. Otherwise, the server may continue to receive location and interaction data from the registered IoT device at block 1150 until the end of the current tracking period.

In one embodiment, in response to determining that the current tracking period has ended, the server may pre-process the location and interaction data that has been received in the most recent tracking period at block 1160 to identify similar patterns or positional overlaps between various IoT devices. . In particular, the server can typically process the tracked location and interactive data based on new locations and interactive data received during the most recent tracking period, either daily or at another periodic time interval. Therefore, the location and interactive data tracked in any particular tracking cycle can be incrementally built into the location and interactive data tracked in the previous tracking cycle.

In one embodiment, the pre-processing that occurs at block 1160 may include all locations and interactions reported from each IoT device during the most recent tracking period and, if applicable, all previously processed locations and interactive data. Stored in a directory associated with each specific IoT device. In one embodiment, the location and interaction data from a particular tracking cycle can then be retrieved and filtered to remove any material that does not have the appropriate format. The pre-processing that occurs at block 1160 can further include establishing a transition table associated with each IoT device to define any associated state changes (eg, a change relationship between two IoT devices). In addition, at block 1160, the server can store the location and interaction data associated with all of the tracked IoT devices in a common directory or other suitable repository and create a list of devices identifying each tracked IoT device. The pre-processed location and interaction data from the current tracking cycle can then be stored with other previously processed locations and interactive data associated with each IoT device.

In one embodiment, in response to pre-processing the location and interaction data from the current tracking period, the server may determine at block 1165 whether the location and interaction data were previously analyzed to determine the relationship. If so, the recently determined relationship cluster can be retrieved at block 1170 and used to update or otherwise determine the relationship in the current iteration. Otherwise, if previously If the location and interactive data are not analyzed (i.e., currently overriding the first iteration), block 1170 may be skipped because there may be no previously determined relationship clusters to be retrieved. Moreover, to avoid acting as outdated material and placing newer locations and newer interactions of greater importance, the cluster of relationships retrieved at block 1170 can be limited to determining within a particular time period (eg, within the last month) The relationship cluster.

In one embodiment, at block 1175, the server can then set any relevant configuration parameters and use the pre-processed location and interaction data from the current tracking period (and/or may have been retrieved at block 1170) Any previously determined relationship clusters) cluster location and interactive data into a primary group based on appropriate statistical techniques. The relationship data clustered into the primary group can then be analyzed at block 1180 to derive a user-specific cluster representation, where the user-specific cluster representation can then be used to assign (and correlate with) the tracked IoT device at block 1185. User-specific relationship identifier between the associated users). For example, in one embodiment, the location associated with each input can be plotted on the derived x-axis and y-axis and can be plotted at block 1180 using a suitable drawing tool (eg, gnuplot). The derived user-specific cluster representation can view and analyze the appropriate drawing tool to aid in learning and classifying the relationship between the tracked IoT device and its associated user, including any asymmetry therebetween.

In accordance with various aspects of the present invention, FIG. 12A illustrates an exemplary architecture 1200 that can be used to detect, configure, and balance relationships in an IoT network, while FIG. 12B illustrates an exemplary interaction between components of architecture 1200 shown in FIG. 12A. In particular, the architecture 1200 shown in FIG. 12A can generally be implemented in a suitable IoT device, and includes, inter alia, a peer-to-peer (P2P) platform 1210 that can support near-based P2P communication and include in an IoT network. A security module 1215 that detects, configures, and balances relationships; a trust model 1220, which can include a relationship graph 1224 that can represent relationships that can be checked and balanced in the IoT network, plus some of the definable permissions that are represented in the relationship graph 1224. An adaptive behavior module 1228 for the user to perform any action or other behavior; a function access application 1230 that can be used to control assignment to the relationship graph 1224 The rights of some users or groups of users represented in the user and thereby based on the trust level sharing information or access device derived from the relationship graph 1224; and the device driver 1235, which may support certain mechanisms according to the mechanism Core operations (for example, device drivers 1235 available from original equipment manufacturers (OEMs)).

In one embodiment, as noted above, the trust model 1220 can generally include a relationship graph 1224 to define one or more users or groups of users that can have a certain level of trust, and further define one or more uses. Relationship between users or groups of users. In addition, the adaptive behavior model 1228 can define what the user or group of users defined in the relationship graph 1224 trust "what", whereby the trust model 1220 can automatically identify users associated with interaction with the device of the controlled device. (or person) and the relationship between behavioral patterns. For example, referring to FIG. 12B, a relationship graph 1224 associated with an "owner" user can include various nodes to represent a user or group of users having a certain level of trust, wherein the relationship shown in FIG. 12B The graph 1224 includes nodes to represent users whose names are "Jill", "John", "Jim", "Mary", "Jack", "Susan". In this context, "Jack" and "Susan" can be considered as family members based on the interaction patterns that occur over time, and are therefore included in the "Family" group, where the function access application 1230 This includes defining a set of permissions that different users can have access to the television and air conditioning unit. For example, a set of television rights may associate all users with a trust profile that grants permission to control the television, while only family members may be associated with a trust profile that grants permission to use the television to record the program. In a similar aspect, the set of air conditioning permissions may associate a user in the family member with a winter and summer trust profile, the winter and summer trust profile grant authority to set the cavity adjustment unit to heat or cool and air The fan on the adjustment is set to high and low, and the user in the friend group can only be associated with the heating trust profile, the heating trust profile grants permission to set the air conditioning to heating without granting any permission. To set the fan speed. Thus, the set of permissions defined using the function access application 1230 can be mapped to individual security settings 1215A through 1215C, such security settings. The user is translated to different access levels based on the relationships defined in the trust model 1220 and the globally unique identifiers (GUIDs) associated with the respective users.

In accordance with various aspects of the present invention, FIGS. 13A-13C illustrate illustrative interactions that can balance the relationships in an IoT network (eg, using exemplary interactions between components 1200 and components in architecture 1200 shown in FIG. 12A, As shown in Figure 12B). In particular, the interaction shown in Figure 13A can generally balance the relationship in the IoT network independently of the trust model 1220 shown in Figure 12A, while the interactions shown in Figures 13B and 13C can be balanced using the trust model 1220. relationship.

For example, referring to FIG. 13A, assume that Jill has a delegate controller device 1310 and further has a slave device 1340, and Jan has an access controller device 1330. In one embodiment, the secure bridge 1350 can broadcast a profile declaration associated with the slave device 1340, which can include a profile profile and cause the zone bus node 1342 (eg, corresponding to FIG. 6 to The area bus node shown in FIG. 7 broadcasts the application of the profile declaration 1344 (for example, corresponding to the local end point as shown in FIGS. 6 to 7). Thus, Jill's application 1314 on the controller device 1310 can detect the profile statement in a similar manner so that Jill's delegate controller device 1310 can find the target controller and can be in the area of Jill's trusted controller device 1310. A secure session is established between the bus node 1312 and the regional bus node 1342 on the slave device 1340 (eg, between the respective GUIDs associated therewith). If Jill decides to grant Jan access to the slave device 1340, then the application 1314 on Jill's delegate controller device 1310 can then request a list of permissions and roles from the slave device 1340, and the slave device 1340 can then The list of permissions and roles is passed back to the application 1314 on Jill's delegate controller device 1310. The application 1314 on Jill's delegate controller device 1310 can then prompt Jill to select a privilege or role to grant Jan and notify the controller device 1340 of the privilege or role that Jill granted to Jan. The slave device 1340 can then record the grant under the GUI associated with Jan and pass the reply back to the application 1314 on Jill's delegate controller device 1310.

In one embodiment, then between the regional bus node 1332 on Jan's access controller device 1330 and the regional bus node 1342 on the slave device 1340 (eg, in the respective GUID associated with it) A secure dialog is established in which Jan can attempt to access the slave device 1340 via a secure connection. Thus, the slave device 1340 can determine whether Jan's GUID has been verified, and in the event that Jan's GUID has not been previously verified, the message can be sent via the area bus node 1342 to the application 1334 on Jan's access controller device 1330. In response to a request to verify Jan's GUID, one or more authentication steps may be performed between the application 1334 on Jan's access controller device 1330 and the authentication entity 1360 (eg, an OpenID provider). Thus, Jan's GUID can be authenticated, and Jan can then use her access to the application 1334 on the controller device 1330 to initiate a secure call to change the temperature (eg, where the slave device 1340 corresponds to a thermostat, air conditioning unit, or Other temperature control devices). The slave device 1340 can then check if Jan has permission to change the temperature and pass the unauthorized condition back to Jan's access controller device 1330 if the previously recorded grant does not include permission to change the temperature. Application 1334. Otherwise, if the previously recorded grant does not include permission to change the temperature, the zone bus node 1342 on the slave device 1340 can communicate with the appropriate application 1344 to perform the temperature change method call, and then respond and any appropriate The return value is sent to the application 1334 on Jan's access controller device 1330.

Referring now to Figure 13B, the interaction shown therein can generally be similar to the interaction described above with respect to Figure 13A, except that the trust model 1320 can be counterbalanced to apply known or learned knowledge between Jill and Jack included in the family group. Outside the relationship. Thus, Jill can use her feature access application 1330 to call the GetFamily( ) method 1322 and request a GUID associated with each member of the family group instead of selecting a permission or role to grant individual users, Jill A permission or role can be selected to grant a family group, and thereby selecting a permission or role grants a GUID associated with each member of the family group. Similarly, the slave device 1340 can record the grant under the GUID associated with each family member, rather than recording it with Granted under the GUID associated with the user. In this manner, Jill can use the feature access application 1330 to identify family members and unify the various possible functionalities to be available to all members of the family group and/or subsequently become members of the family group. The preferred setting profile associated with the user.

For example, referring now to Figure 13C, the interaction shown therein can generally be similar to the interaction described above with respect to Figure 13B, except that the GetProfiles( ) method 1324 can be further used in the trust model 1320 to simplify various functionalities. The cultural functionality of learning (which may be associated with the current member and/or all users who may subsequently become members of a particular group). For example, after extracting the GUID associated with each member of the family group, Jill can use the function access application 1330 to retrieve the caller device 1340 using the call to the GetProfiles( ) method 1324. The cultural function of the joint learning. Thus, Jill may choose to culturally grant a family group, and thereby grant various unified functionality to the GUID associated with each member of the family group, and the controller device 1340 may similarly Cultural functionality is granted under the GUID associated with family members. Thus, when the slave device 1340 receives a request from a particular user to initiate a particular method call, the slave device 1340 can query GetProfiles( ) 1324 to the self-trust model 1320 (eg, as shown in FIG. 12B). The action definition defines the translation and thereby determines the appropriate method call to be invoked. For example, if Jack initiates a secure call to change temperature, the controller device 1340 can query GetProfiles( ) 1324 to translate the summer profile into an action definition (this action defines the air conditioning unit to set the cooling and fan speed) Set to high) and then perform an action defined call.

Those skilled in the art will appreciate that information and signals may be represented using any of a variety of different technologies and techniques. For example, the data, instructions, commands, information, signals, bits, symbols, and codes referenced by the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or magnetic particles, light fields or light particles, or any combination thereof. sheet.

In addition, those skilled in the art should understand that, in conjunction with the aspects disclosed herein The various illustrative logical blocks, modules, circuits, and algorithm steps described can be implemented as an electronic hardware, a computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of functionality. This functionality is implemented as hardware or software depending on the particular application and design constraints imposed on the overall system. The described functionality may be implemented in varying ways for each particular application, and such implementation decisions are not to be construed as a departure from the scope of the invention.

Universal processor, digital signal processor (DSP), special application integrated circuit (ASIC), field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hard The body components, or any combination thereof, designed to perform the functions described herein, implement or perform various illustrative logic blocks, modules, and circuits described in connection with the embodiments disclosed herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessor cores, or any other configuration.

The methods, sequences and/or algorithms described in connection with the embodiments disclosed herein may be embodied directly in a hardware, in a software module executed by a processor, or in a combination of the two. The software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, scratchpad, hard disk, removable disk, CD-ROM, or any of the techniques known in the art. Other forms of storage media. An exemplary storage medium is coupled to the processor such that the processor can read information from the storage medium and write the information to the storage medium. In the alternative, the storage medium can be integrated into the processor. The processor and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal (eg, a UE). In the alternative, the processor and the storage medium may reside as discrete components in the user terminal.

In one or more exemplary embodiments, it may be in hardware, software, firmware or any of them The functions described are implemented in combination. If implemented in software, the functions may be stored as one or more instructions or code on a computer readable medium or transmitted via a computer readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transmission of the computer program from one location to another. The storage medium can be any available media that can be accessed by a computer. By way of example and not limitation, such computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage or other magnetic storage device or may be used to carry or store an instruction or data structure. Any other medium in the form of a program code that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if you use coaxial cable, fiber optic cable, twisted pair cable, digital subscriber line (DSL), or wireless technology (such as infrared, radio, and microwave) to transfer software from a website, server, or other remote source, then coaxial cable, Fiber optic cable, twisted pair, DSL or wireless technologies such as infrared, radio and microwave are included in the definition of the media. As used herein, disks and discs include compact discs (CDs), laser discs, compact discs, digital audio and video discs (DVDs), flexible disks, and Blu-ray discs, where the discs are typically magnetically reproduced while the disc is being used. The material is optically reproduced by laser. Combinations of the above should also be included in the context of computer readable media.

While the foregoing disclosure shows illustrative aspects of the present invention, it should be understood that various changes and modifications may be made herein without departing from the scope of the invention as defined by the appended claims. The functions, steps, and/or actions of the method claims in accordance with the aspects of the invention described herein are not required in any particular order. In addition, although the elements of the present invention may be described or claimed in the singular, the plural forms are intended to be limited to the singular.

800‧‧‧ method

Claims (56)

A method for detecting, configuring, and balancing a relationship in an Internet of Things (IoT) network, the method comprising: registering one or more objects into an IoT network; and associating with the one or more registered objects Forming the one or more registered items into one or more IoT groups using the interaction between the one or more registered items, wherein the one or more registered items include at least one non-communicating entity object And at least one communication IoT device, wherein the at least one communication IoT device stores information related to the use and the interaction associated with the IoT device in a local repository; the at least one communication IoT device receives and is associated with The information relating to the use and the interaction; and the interaction in response to the communication IoT device comprising determining at least one interaction between the communication IoT device and the non-communicating entity object, based on The information received by the at least one communication IoT device derives information related to the use and the interaction associated with the non-communicating entity object. The method of claim 1, further comprising: receiving one or more user commands that control access to the one or more IoT groups. The method of claim 2, further comprising: the one or more IoT groups based on the usage associated with the one or more registered items and the interaction between the one or more registered items Split into one or more subsets. The method of claim 3, further comprising: receiving one or more user commands that control access to the one or more subsets. The method of claim 1, further comprising: receiving one or more user commands to customize the one or more IoT groups. A method for detecting, configuring, and balancing a relationship in an Internet of Things (IoT) network, the method comprising: registering one or more objects into an IoT network; and associating with the one or more registered objects Forming the one or more registered items into one or more IoT groups using the interaction between the one or more registered items, wherein the interaction between the one or more registered items includes a At least one interaction between the first IoT device and a second IoT device; a rank based on one or more attributes associated with the at least one interaction and associated with one or more attributes of the second IoT device Assigning a relationship between the first IoT device and the second IoT device; and determining whether to grant the second IoT based on the rank assigned to the relationship between the first IoT device and the second IoT device The device accesses the first IoT device. The method of claim 6, further comprising: responsive to determining that one or more previous interactions have occurred between the first IoT device and the second IoT device, determining whether to update the assignment to the first IoT device and the This order of the relationship between the two IoT devices. The method of claim 7, further comprising: based on the one or more attributes associated with the at least one interaction, the one or more attributes associated with the second IoT device, and associated with the one or more The one of the previous interactions is updated to update the rank assigned to the relationship between the first IoT device and the second IoT device. The method of claim 6, wherein the first IoT device belongs to a first user and the second IoT device belongs to a second user. The method of claim 9, further comprising: Determining whether to grant access by the second IoT device to another IoT device belonging to the first user based on the rank assigned to the relationship between the first IoT device and the second IoT device. A method for detecting, configuring, and balancing a relationship in an Internet of Things (IoT) network, the method comprising: registering one or more objects into an IoT network; and associating with the one or more registered objects Forming the one or more registered items into one or more IoT groups using the interaction between the one or more registered items, wherein the interaction between the one or more registered items includes At least one interaction between the first IoT device of one of the first users and the second IoT device belonging to one of the second users; storing information related to the at least one interaction in association with the first IoT device And assigning a relationship identifier to the second user associated with the second IoT device based at least in part on the information stored in the first interaction table. The method of claim 11, wherein the at least one interaction occurs when the first IoT device and the second IoT device are positioned close to each other. The method of claim 12, wherein the first IoT device detects the at least one interaction in response to detecting the second IoT device proximate thereto. The method of claim 12, wherein the server detects the at least one interaction based on location information related to the at least one interaction that the server receives from the first IoT device and the second IoT device. The method of claim 11, further comprising: adding the relationship identifier to an entry in the first interaction table associated with the second user. The method of claim 11, wherein the relationship identifier reflects an associated first use Multiple interactions between one or more IoT devices and one or more IoT devices associated with the second user. The method of claim 16, wherein the plurality of interactions comprise one or more of: interactions occurring during a threshold period of time, interactions occurring at substantially the same time, substantially the same location Interactions that occur, interactions with a threshold duration, interactions with a threshold frequency, or interactions of substantially the same type. A method for detecting, configuring, and balancing a relationship in an Internet of Things (IoT) network, the method comprising: registering one or more objects into an IoT network; and associating with the one or more registered objects Forming the one or more registered items into one or more IoT groups using the interaction between the one or more registered items; tracking interactions between the plurality of IoT devices and the tracking of the interactions occurring a location, wherein the plurality of IoT devices are associated with at least one first user and a second user, and the tracked interactions comprise between the one or more registered objects in the IoT network At least one of the interactions; and detecting at least one asymmetric relationship between the first user and the second user based on the tracked interactions and the locations associated therewith. The method of claim 18, wherein the asymmetric relationship indicates that the first user has a first relationship with one of the second users that is different from the second relationship that the second user has with the first user. . The method of claim 18, wherein the tracked locations indicate that the tracked interaction occurs at a person space owned by the first user or at a person space owned by the second user. The method of claim 20, wherein the tracked locations further indicate the first The user appears in the personal space owned by the second user at a first frequency, and the second user appears in the personal possession of the first user at a second frequency different from the first frequency In space. The method of claim 18, wherein detecting the at least one asymmetric relationship between the first user and the second user comprises: processing the associated interactions occurring during a predefined time period Information. The method of claim 22, wherein detecting the at least one asymmetric relationship between the first user and the second user further comprises: processing in conjunction with the tracked interactions occurring during the predefined time period Information relating to one or more previous determinations between the first user and the second user. The method of claim 18, wherein detecting the at least one asymmetric relationship between the first user and the second user comprises: correlating the interactions tracked by the tracks and the interactions tracked by the tracks The data of the locations is clustered into one or more primary groups; a cluster representation specific to the first user and a cluster representation specific to the second user are derived from the one or more primary groups; And determining the at least one asymmetric relationship based on a similarity or dissimilarity between the cluster representation specific to the first user and the cluster representation specific to the second user. The method of claim 18, wherein detecting the at least one asymmetric relationship between the first user and the second user further comprises: displaying an association based on the locations at which the tracked interactions occur The cluster representation specific to the first user and the data specific to the cluster representation of the second user. The method of claim 18, wherein a server tracks the interaction between the plurality of IoT devices and the locations at which the tracked interactions occur to detect the first user and the second user The at least one asymmetric relationship between the two. An apparatus for detecting, configuring, and balancing a relationship in an Internet of Things (IoT) network, comprising: means for registering one or more objects in an IoT network; for correlating with the one or Forming, by the use of the plurality of registered items and the interaction between the one or more registered items, the one or more registered items as a component of one or more IoT groups; for using the one or more ???the at least one first IoT device having communication capability between the registered objects receives a component related to the usage and interaction associated with the first IoT device; and responsive to the associated associated with the first IoT device The interaction includes one of at least one interaction between the first IoT device and the at least one second IoT device having no communication capability between the one or more registered objects, based on the receipt from the first IoT device The information is derived from the components associated with the usage and interaction associated with the second IoT device. The apparatus of claim 27, further comprising: for the one or more IoTs based on the use of the one or more registered items and the interaction between the one or more registered items A group is divided into components of one or more subsets. The apparatus of claim 28, further comprising: means for receiving one or more user commands for controlling access to the one or more IoT groups and the one or more subsets associated therewith And means for receiving one or more user commands to customize the one or more IoT groups and the one or more subsets associated therewith. An apparatus for detecting, configuring, and balancing a relationship in an Internet of Things (IoT) network, comprising: means for registering one or more objects in an IoT network; for correlating with the one or Forming the one or more registered items as a component of one or more IoT groups, wherein the one or more registered items are used by the plurality of registered items and the interaction between the one or more registered items The interaction between the first IoT device and a second IoT device is based on being associated with one or more attributes associated with the at least one interaction and associated with the second IoT device One or more attributes that assign a rank to a member of a relationship between the first IoT device and the second IoT device; and for assigning between the first IoT device and the second IoT device The order of the relationship determines whether the second IoT device is granted access to the first IoT device. The device of claim 30, further comprising: for the one or more attributes associated with the at least one interaction, the one or more attributes associated with the second IoT device, and associated with Updating the one of the relationship between the first IoT device and the second IoT device by updating one or more attributes of one or more previous interactions between the first IoT device and the second IoT device The components. The device of claim 30, wherein the first IoT device belongs to a first user and the second IoT device belongs to a second user, and wherein the component for determining whether to grant access to the second IoT device Further configured to determine whether to grant the second IoT device access to a third IoT device belonging to the first user based on the order assigned to the relationship between the first IoT device and the second IoT device . A device for detecting, configuring, and balancing a relationship in an Internet of Things (IoT) network, comprising: a means for registering one or more items in an IoT network; for arranging the one based on the use of the one or more registered items and the interaction between the one or more registered items Or the plurality of registered objects are formed as a component of one or more IoT groups, wherein the interaction between the one or more registered objects includes a first IoT device belonging to a first user and belonging to a second At least one interaction between the second IoT device of the user; storing information related to the at least one interaction on a component associated with the first interaction table of one of the first IoT devices; and for at least A relationship identifier is assigned to the member of the second user associated with the second IoT device based in part on the information stored in the first interaction table. The device of claim 33, wherein the relationship identifier reflects a plurality of interactions between one or more IoT devices associated with the first user and one or more IoT devices associated with the second user . An apparatus for detecting, configuring, and balancing a relationship in an Internet of Things (IoT) network, comprising: means for registering one or more objects in an IoT network; for correlating with the one or Forming the one or more registered objects as a component of one or more IoT groups by using the plurality of registered objects and the interaction between the one or more registered objects; for tracking between the plurality of IoT devices And means for interacting with the location at which the tracked interaction occurs, wherein the plurality of IoT devices are associated with at least a first user and a second user, and the tracked interactions comprise the IoT network Detecting at least one of the interactions between the one or more registered items; and detecting the first user and the second based on the tracked interactions and associated locations thereof At least one asymmetric relationship between users Pieces. The device of claim 35, wherein the asymmetric relationship indicates that the first user has a first relationship with one of the second users that is different from the second relationship that the second user has with the first user . The device of claim 36, wherein the tracked position indicates that the first user appears in a person space owned by the second user at a first frequency, and the second user is different from the first user One of the frequencies, the second frequency, appears in a person space owned by the first user. The apparatus of claim 35, wherein the at least one asymmetric relationship between the first user and the second user is based on information associated with the tracked interactions occurring during a predefined time period And detection. The device of claim 38, wherein the at least one asymmetric relationship between the first user and the second user is based on one or more previous determinations between the first user and the second user The relationship is further detected in conjunction with the tracked interactions that occurred during the predefined time period. The device of claim 35, wherein the means for detecting the at least one asymmetric relationship between the first user and the second user comprises: for correlating the tracked interactions with the The data of the locations at which the tracked interaction occurs is clustered into one or more primary group components; for deriving a cluster representation and specific to the first user from the one or more primary groups And means for clustering the representation of the second user; and for determining a similarity or dissimilarity between the cluster representation specific to the first user and the cluster representation specific to the second user The component of the at least one asymmetric relationship. The apparatus of claim 35, further comprising: for displaying a correlation based on the locations at which the tracked interactions occur And a component associated with the cluster representation specific to the first user and the data representative of the cluster representation of the second user. A computer readable storage medium having computer executable instructions recorded thereon, wherein the computer executable instructions are executed on one or more processors to cause the one or more processors to register one or more objects In an Internet of Things (IoT) network; forming one or more registered items as one based on the use of the one or more registered items and the interaction between the one or more registered items Or a plurality of IoT groups; receiving, from the at least one first IoT device having communication capability between the one or more registered objects, information related to the use and interaction associated with the first IoT device; and responding to The interaction associated with the first IoT device includes one of at least one interaction between the first IoT device and the at least one second IoT device having no communication capability between the one or more registered objects, Information relating to the use and interaction associated with the second IoT device is derived based on the information received from the first IoT device. The computer readable storage medium of claim 42, wherein the executing the computer executable instructions on the one or more processors further causes the one or more processors to: associate with the one or more registered objects The use and the interaction between the one or more registered objects divide the one or more IoT groups into one or more subsets. The computer readable storage medium of claim 43, wherein executing the computer executable instructions on the one or more processors further causes the one or more processors to: receive control of the one or more IoT groups and One or more user commands for accessing the one or more subsets associated therewith; and One or more user commands are received to customize the one or more IoT groups and the one or more subsets associated therewith. A computer readable storage medium having computer executable instructions recorded thereon, wherein the computer executable instructions are executed on one or more processors to cause the one or more processors to register one or more objects In an Internet of Things (IoT) network; forming one or more registered items as one based on the use of the one or more registered items and the interaction between the one or more registered items Or a plurality of IoT groups, wherein the interaction between the one or more registered objects includes at least one interaction between a first IoT device and a second IoT device; based on one of the at least one interactions associated with Or a plurality of attributes and associated with one or more attributes of the second IoT device to assign a rank to a relationship between the first IoT device and the second IoT device; and based on assigning to the first IoT The order of the relationship between the device and the second IoT device determines whether the second IoT device is granted access to the first IoT device. The computer readable storage medium of claim 45, wherein the executing the computer executable instructions on the one or more processors further causes the one or more processors to: based on the one or more associated with the at least one interaction a plurality of attributes, the one or more attributes associated with the second IoT device, and one or more of one or more previous interactions that have occurred between the first IoT device and the second IoT device The attribute is updated to the rank assigned to the relationship between the first IoT device and the second IoT device. The computer readable storage medium of claim 45, wherein the first IoT device belongs to a first user and the second IoT device belongs to a second user, and wherein the performing on the one or more processors Computer executable instructions further causing the one or more processors to be based on the relationship assigned between the first IoT device and the second IoT device The sequence determines whether the second IoT device is granted access to a third IoT device belonging to the first user. A computer readable storage medium having computer executable instructions recorded thereon, wherein the computer executable instructions are executed on one or more processors to cause the one or more processors to register one or more objects In an Internet of Things (IoT) network; forming one or more registered items as one based on the use of the one or more registered items and the interaction between the one or more registered items Or a plurality of IoT groups, wherein the interaction between the one or more registered objects includes a first IoT device belonging to one of the first users and a second IoT device belonging to one of the second users At least one interaction; storing information related to the at least one interaction in a first interaction table associated with the first IoT device; and at least partially based on the information stored in the first interaction table A relationship identifier is assigned to the second user associated with the second IoT device. The computer readable storage medium of claim 48, wherein the relationship identifier reflects an association between one or more IoT devices associated with the first user and one or more IoT devices associated with the second user Multiple interactions. A computer readable storage medium having computer executable instructions recorded thereon, wherein the computer executable instructions are executed on one or more processors to cause the one or more processors to register one or more objects In an Internet of Things (IoT) network; forming one or more registered items as one based on the use of the one or more registered items and the interaction between the one or more registered items Or multiple IoT groups; track interactions between multiple IoT devices and where the interactions tracked occur The plurality of IoT devices are associated with at least one first user and a second user, and the tracked interactions include the one or more registered items in the IoT network At least one of the interactions; and detecting at least one asymmetric relationship between the first user and the second user based on the tracked interactions and the locations associated therewith. The computer readable storage medium of claim 50, wherein the asymmetric relationship indicates that the first user has a first relationship with one of the second users that is different from the first user and the first user A second relationship. The computer readable storage medium of claim 51, wherein the tracked location indicates that the first user appears in a first space owned by the second user, and the second user is different A second frequency at one of the first frequencies occurs in a person space owned by the first user. The computer readable storage medium of claim 50, wherein the at least one asymmetric relationship between the first user and the second user is based on the tracking associated with occurring during a predefined time period Detected by the interactive data. The computer readable storage medium of claim 53, wherein the at least one asymmetric relationship between the first user and the second user is based on an or between the first user and the second user The plurality of previously determined relationships are further detected in conjunction with the tracked interactions that occurred during the predefined time period. The computer readable storage medium of claim 50, wherein the executing the computer executable instructions on the one or more processors further causes the one or more processors to: correlate the interactions tracked by the And arranging the data of the locations where the tracked interactions occur into one or more primary groups; exporting from the one or more primary groups a cluster representation specific to the first user and being specific to the second a cluster representation of the user; and based on the cluster representation specific to the first user and specific to the second use The at least one asymmetric relationship is determined by the similarity or dissimilarity between the cluster representations. The computer readable storage medium of claim 50, wherein the executing the computer executable instructions on the one or more processors further causes the one or more processors to: be based on the occurrence of the tracked interactions The location displays information associated with the cluster representation specific to the first user and the cluster representation specific to the second user.